From xen-devel-bounces@lists.xenproject.org Wed Jan 01 14:36:21 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Jan 2025 14:36:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863699.1275069 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tSzpM-0004Az-Vp; Wed, 01 Jan 2025 14:36:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863699.1275069; Wed, 01 Jan 2025 14:36:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tSzpM-0004Ah-Qk; Wed, 01 Jan 2025 14:36:04 +0000
Received: by outflank-mailman (input) for mailman id 863699;
 Wed, 01 Jan 2025 14:36:03 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=kJje=TZ=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tSzpL-0004Ab-Jj
 for xen-devel@lists.xenproject.org; Wed, 01 Jan 2025 14:36:03 +0000
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com
 [2a00:1450:4864:20::331])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b8c685a0-c84d-11ef-a0db-8be0dac302b0;
 Wed, 01 Jan 2025 15:36:01 +0100 (CET)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-4363dc916ceso68574035e9.0
 for <xen-devel@lists.xenproject.org>; Wed, 01 Jan 2025 06:36:01 -0800 (PST)
Received: from [192.168.86.29] ([83.105.36.37])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-43656b119d7sm454685025e9.20.2025.01.01.06.35.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 01 Jan 2025 06:35:59 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b8c685a0-c84d-11ef-a0db-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1735742160; x=1736346960; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=R/82tL1c/sWjbeXwr5bYXdKAwElFeI4Aa+GF0KAKptQ=;
        b=oIHBBj22Ar64QGeyh8FTQpCIscZzZqbtoN6zV5gcsA+fCZOkU6vqvtmIG2e1f1DnXg
         +6/SGmmmW8oE7fXrL7JcfTGvBNfBcvuDM5tpblwWyAHFu/pzMVigdZ+l3Es+4BGFHVsU
         uOzN042KhSzY21DlHTZGLn7n2iM5rfOEQN9Vs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735742160; x=1736346960;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=R/82tL1c/sWjbeXwr5bYXdKAwElFeI4Aa+GF0KAKptQ=;
        b=FHoCZMjDUaszx5jrvVlGBjOo3a7Ahn63NHXomUCDET1M1AJRD8A4U2zhIKp1YvSOId
         DI7/Kt+b7Ncjwd6HL7gS28yRsdbo4NbKtHbv4oi3El6za2ILm5rICWF1ilSL5+TDG/8e
         mcV5YjlD3+MD4KXppgkVBBXvKTodtx11CwP7ximglxgdliszw4v9qriqasvNXJ5Cvq/f
         Eg6kxfwAYMmlrSMIEhQs/kIJx+zi+cj4dohq99jzZvQZs84oRL3kuDgjLRCnDBcaUHLJ
         nQmIpGjJxdq3s6QNgPlKoF8WLYGnQLXU7gDzn0zHC3XFaEe6IDzHr2ZbDnDsG3exy/Y7
         vvvQ==
X-Gm-Message-State: AOJu0YxMixDG5kZIAD2lAf13rXcPF+ln5CSpsvoq0m2nyqmA0jQIpnx/
	qte1s2JP0/GF+3Th6UesYojZSZWccsjwwxN0OySmhaR/GNRDY02vlRB73DFD51c=
X-Gm-Gg: ASbGnctNqpzPNQDfbP73BXsR6m+anuZUtvwVyjV5oDxFQCGiVPpjUQfgxnt8wsxokHu
	e/el5d1HnPydpfutIkAWpHlBNsE14XlswsLC9qgjLGFGh/DGQYofSSYGdZj1vYuKxSQoucTyBlh
	IyoBjCh1FRBrdqaLyxdvAS9Wa/SlCg/bVe55jpfJuN5swulKGBrzMT8WEd3uL8Qn2ghBRQ2Sdlk
	EQlgTl/Qq0LMhs+cFD78cz7XTQ1zXsVLPE7rnDZkrHp8qDjmHDPXaCT2jHnL5OoN5w=
X-Google-Smtp-Source: AGHT+IHkvSk6kJxA3d22XbQHvCweZ8xaEF+ADNkxSg5uGBHeB7goQWulrd+4S8H1OIkjzBZ6UUrGKA==
X-Received: by 2002:a7b:c3d9:0:b0:434:ea1a:e30c with SMTP id 5b1f17b1804b1-4365c79aa7dmr403915285e9.13.1735742160528;
        Wed, 01 Jan 2025 06:36:00 -0800 (PST)
Message-ID: <c2ef70ce-af2f-4001-8dd4-d8930c9f8952@citrix.com>
Date: Wed, 1 Jan 2025 14:35:59 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20] x86/traps: Rework LER initialisation and support
 Zen5/Diamond Rapids
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>
Cc: Xen-devel <xen-devel@lists.xenproject.org>,
 Jan Beulich <JBeulich@suse.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Oleksii Kurochko <oleksii.kurochko@gmail.com>
References: <20241231192002.1753737-1-andrew.cooper3@citrix.com>
 <Z3RvWJvdB68sVhqZ@mail-itl>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <Z3RvWJvdB68sVhqZ@mail-itl>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 31/12/2024 10:25 pm, Marek Marczykowski-Górecki wrote:
> On Tue, Dec 31, 2024 at 07:20:02PM +0000, Andrew Cooper wrote:
>> AMD have always used the architectural MSRs for LER.  As the first processor
>> to support LER was the K7 (which was 32bit), we can assume it's presence
>> unconditionally in 64bit mode.
>>
>> Intel are about to run out of space in Family 6 and start using 19.  It is
>> only the Pentium 4 which uses non-architectural LER MSRs.
>>
>> percpu_traps_init(), which runs on every CPU, contains a lot of code which
>> should be init-only, and is the only reason why opt_ler can't be in initdata.
>>
>> Write a brand new init_ler() which expects all future Intel and AMD CPUs to
>> continue using the architectural MSRs, and does all setup together.  Call it
>> from trap_init(), and remove the setup logic percpu_traps_init() except for
>> the single path configuring MSR_IA32_DEBUGCTLMSR.
>>
>> Leave behind a warning if the user asked for LER and Xen couldn't enable it.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> ---
>> CC: Jan Beulich <JBeulich@suse.com>
>> CC: Roger Pau Monné <roger.pau@citrix.com>
>> CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
>>
>> For 4.20.  This is needed for Zen5 CPUs (already available) as well as Intel
>> CPUs coming shortly.  It also moves some non-init logic to being init-only.
>> ---
> ...
>
>> @@ -2201,6 +2155,42 @@ void __init init_idt_traps(void)
>>          this_cpu(compat_gdt) = boot_compat_gdt;
>>  }
>>  
>> +static void __init init_ler(void)
>> +{
>> +    unsigned int msr = 0;
>> +
>> +    if ( !opt_ler )
>> +        return;
>> +
>> +    /*
>> +     * Intel Pentium 4 is the only known CPU to not use the architectural MSR
>> +     * indicies.
>> +     */
>> +    switch ( boot_cpu_data.x86_vendor )
>> +    {
>> +    case X86_VENDOR_INTEL:
>> +        if ( boot_cpu_data.x86 == 0xf )
>> +        {
>> +            ler_msr = MSR_P4_LER_FROM_LIP;
> msr = 
>
> and ...
>
>> +            break;
>> +        }
>> +        fallthrough;
>> +    case X86_VENDOR_AMD:
>> +    case X86_VENDOR_HYGON:
>> +        ler_msr = MSR_IA32_LASTINTFROMIP;
> ... here?

Yes.  Serves me right for a last minute refactor.

> But also, why temporary variable?

Code gen (ler_msr is a global so checking it at the end needs to come
from memory), and defence in depth (it introduces a path through the
function where we failed to find the MSR but still turned LER on anyway
if there was an unexpected value there already).

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Jan 01 19:04:05 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Jan 2025 19:04:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863711.1275078 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tT40F-00089d-0a; Wed, 01 Jan 2025 19:03:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863711.1275078; Wed, 01 Jan 2025 19:03:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tT40E-00089W-Tz; Wed, 01 Jan 2025 19:03:34 +0000
Received: by outflank-mailman (input) for mailman id 863711;
 Wed, 01 Jan 2025 19:03:33 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=zuMM=TZ=daemonizer.de=maxi@srs-se1.protection.inumbo.net>)
 id 1tT40C-00089Q-I6
 for xen-devel@lists.xenproject.org; Wed, 01 Jan 2025 19:03:33 +0000
Received: from mx1.somlen.de (breeze.somlen.de [2a00:1828:a019::100:0])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 169e2887-c873-11ef-99a4-01e77a169b0f;
 Wed, 01 Jan 2025 20:03:30 +0100 (CET)
Received: by mx1.somlen.de with ESMTPSA id E1CF75030DC;
 Wed,  1 Jan 2025 20:03:27 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 169e2887-c873-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=daemonizer.de;
	s=202303; t=1735758208;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=dV5f7xGWQ9o/HfViHTfrfAk4k7xWqSdLVSvPueziWWU=;
	b=N0zsG1ZPthpG2uh4DbzQOpmvBwp9fwsKGPijLb+FocJMEIT7cY4b4ZQrDgca6cMgI7y2NB
	CjqjN8rAh96C2cxpMkdD7DD0RkpF2x727yx29rFz0FWLXXgq2X2iL0CRCCdXOfMp2cc854
	EVf8q9TeOhrlrGzmENZPSxXzotmvyr0/Uqa/wbXWXYH9W2hJjoFimmpGX0EdxzzDbxPwAC
	KtLNBZFT6d71KtONOQFghr/tIfG92LQLtPapSQejgINOKGFNDvJ0nzJYMBAui8I2stYK+t
	onGjTxm49rkQZYLsWs+OT9mcCQWvcLK4I3EB8oemYSbsuKFjlV7fZneAycAfBg==
From: Maximilian Engelhardt <maxi@daemonizer.de>
To: xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Anthony PERARD <anthony.perard@vates.tech>
Subject: Re: [XEN PATCH 2/5] docs: set DATE to SOURCE_DATE_EPOCH if available
Date: Wed, 01 Jan 2025 20:03:24 +0100
Message-ID: <23136765.EfDdHjke4D@localhost>
In-Reply-To: <2637960.Lt9SDvczpP@localhost>
References:
 <cover.1735585600.git.maxi@daemonizer.de>
 <25f9fabf-1239-4465-92c9-484fc24fc4f7@citrix.com>
 <2637960.Lt9SDvczpP@localhost>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart4443138.kQq0lBPeGt";
 micalg="pgp-sha512"; protocol="application/pgp-signature"

--nextPart4443138.kQq0lBPeGt
Content-Type: multipart/mixed; boundary="nextPart8343371.EvYhyI6sBW";
 protected-headers="v1"
Content-Transfer-Encoding: 7Bit
From: Maximilian Engelhardt <maxi@daemonizer.de>
Cc: Anthony PERARD <anthony.perard@vates.tech>
Date: Wed, 01 Jan 2025 20:03:24 +0100
Message-ID: <23136765.EfDdHjke4D@localhost>
In-Reply-To: <2637960.Lt9SDvczpP@localhost>
MIME-Version: 1.0

This is a multi-part message in MIME format.

--nextPart8343371.EvYhyI6sBW
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

On Montag, 30. Dezember 2024 23:28:42 CET Maximilian Engelhardt wrote:
> On Montag, 30. Dezember 2024 22:38:24 CET Andrew Cooper wrote:
> > On 30/12/2024 9:00 pm, Maximilian Engelhardt wrote:
> > > Use the solution described in [1] to replace the call to the 'date'
> > > command with a version that uses SOURCE_DATE_EPOCH if available. This
> > > is needed for reproducible builds.
> > > 
> > > The -d "@..." syntax was introduced in GNU date about 2005 (but only
> > > added to the docuemntation in 2011), so I assume a version supporting
> > > this syntax is available, if SOURCE_DATE_EPOCH is defined. If
> > > SOURCE_DATE_EPOCH is not defined, nothing changes with respect to the
> > > current behavior.
> > > 
> > > [1] https://reproducible-builds.org/docs/source-date-epoch/
> > > 
> > > Signed-off-by: Maximilian Engelhardt <maxi@daemonizer.de>
> > > ---
> > > 
> > >  docs/Makefile | 8 +++++++-
> > >  1 file changed, 7 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/docs/Makefile b/docs/Makefile
> > > index b30cc619f8..beba02a94f 100644
> > > --- a/docs/Makefile
> > > +++ b/docs/Makefile
> > > @@ -3,7 +3,13 @@ include $(XEN_ROOT)/Config.mk
> > > 
> > >  -include $(XEN_ROOT)/config/Docs.mk
> > >  
> > >  VERSION		:= $(shell $(MAKE) -C $(XEN_ROOT)/xen --no-print-
directory
> > >  xenversion)>
> > > 
> > > -DATE		:= $(shell date +%Y-%m-%d)
> > > +
> > > +DATE_FMT	:= +%Y-%m-%d
> > > +ifdef SOURCE_DATE_EPOCH
> > > +DATE		:= $(shell date -u -d "@$(SOURCE_DATE_EPOCH)" "$(DATE_FMT)"
> > > 2>/dev/null || date -u -r "$(SOURCE_DATE_EPOCH)" "$(DATE_FMT)"
> > > 2>/dev/null || date -u "$(DATE_FMT)") +else
> > > +DATE		:= $(shell date "$(DATE_FMT)")
> > > +endif
> > > 
> > >  DOC_ARCHES      := arm x86_32 x86_64
> > >  MAN_SECTIONS    := 1 5 7 8
> > 
> > While this looks fine for docs, there's another (identical) use of date
> > in tools/firmware/hvmloader/Makefile, as well as some differing uses to
> > construct XEN_BUILD_{DATE,TIME}.  INSTALL talks about VGABIOS_REL_DATE
> > too.
> > 
> > Does something like this work for you?  It seems to DTRT for SMBIOS.  It
> > needs adapting a bit more for vgabios and Xen, but I think having one
> > common $(date) is going to be better than ad-hoc ones over the tree.
> > 
> > ~Andrew
> 
> Hi Andrew,
> 
> Thanks for your quick reply. Your patch looks fine to me. You can add my
> Tested-by.
> 
> We currently use "export XEN_BUILD_{DATE,TIME}=...", "export
> SMBIOS_REL_DATE=..." and "export VGABIOS_REL_DATE=..." for building xen in
> Debian, so we did not run into reproducibility problems with these. But
> having them combined to all use SOURCE_DATE_EPOCH if available sounds like
> a good idea and would also benefit other downstream users.
> 
> Maxi

Hi Andrew,

I extended your patch to also cover the other uses of date. Please check if 
this look reasonable as I'm not an expert in makefiles. It seems to DTRT in 
the cases I tested.

What I changed compared to your patch:

* Add LC_ALL=C to all date commands. This was also missing in my original 
patch, but I think it's a good thing to do and XEN_BUILD_{DATE,TIME} already 
do it.

* Change the quoting to allow calling the date command without any additional 
(formatting) arguments.

* Add an include of Config.mk to tools/firmware/vgabios/Makefile and moved the 
definition of XEN_BUILD_{DATE,TIME} further down in xen/Makefile to have the 
newly defined date wrapper available.

Does this look reasonable or are there parts that should be done differently?

Thanks,
Maxi
--nextPart8343371.EvYhyI6sBW
Content-Disposition: attachment; filename="SOURCE_DATE_EPOCH_full.patch"
Content-Transfer-Encoding: 7Bit
Content-Type: text/x-patch; charset="unicode-2-0-utf-8";
 name="SOURCE_DATE_EPOCH_full.patch"

diff --git a/Config.mk b/Config.mk
index fa0414055b..9188fc9053 100644
--- a/Config.mk
+++ b/Config.mk
@@ -141,6 +141,14 @@ export XEN_HAS_BUILD_ID=y
 build_id_linker := --build-id=sha1
 endif
 
+# Wrap date(1) to use SOURCE_DATE_EPOCH if set the environment.
+# See https://reproducible-builds.org/docs/source-date-epoch/
+ifdef SOURCE_DATE_EPOCH
+date = $(shell LC_ALL=C date -u -d "@$(SOURCE_DATE_EPOCH)" $(1) 2>/dev/null || LC_ALL=C date -u -r "$(SOURCE_DATE_EPOCH)" $(1) 2>/dev/null || LC_ALL=C date -u $(1))
+else
+date = $(shell LC_ALL=C date $(1))
+endif
+
 define buildmakevars2shellvars
     export PREFIX="$(prefix)";                                            \
     export XEN_SCRIPT_DIR="$(XEN_SCRIPT_DIR)";                            \
diff --git a/docs/Makefile b/docs/Makefile
index b30cc619f8..ca9fd726d3 100644
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -3,7 +3,7 @@ include $(XEN_ROOT)/Config.mk
 -include $(XEN_ROOT)/config/Docs.mk
 
 VERSION		:= $(shell $(MAKE) -C $(XEN_ROOT)/xen --no-print-directory xenversion)
-DATE		:= $(shell date +%Y-%m-%d)
+DATE		:= $(call date,"+%Y-%m-%d")
 
 DOC_ARCHES      := arm x86_32 x86_64
 MAN_SECTIONS    := 1 5 7 8
diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
index c7bc400657..cc5dc00498 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -23,7 +23,7 @@ include $(XEN_ROOT)/tools/firmware/Rules.mk
 ld-option = $(shell if $(LD) -v $(1) >/dev/null 2>&1; then echo y; else echo n; fi)
 
 # SMBIOS spec requires format mm/dd/yyyy
-SMBIOS_REL_DATE ?= $(shell date +%m/%d/%Y)
+SMBIOS_REL_DATE ?= $(call date,"+%m/%d/%Y")
 
 CFLAGS += $(CFLAGS_xeninclude) -fno-pic -mregparm=3
 
diff --git a/tools/firmware/vgabios/Makefile b/tools/firmware/vgabios/Makefile
index 3284812fde..db5a2624be 100644
--- a/tools/firmware/vgabios/Makefile
+++ b/tools/firmware/vgabios/Makefile
@@ -1,3 +1,6 @@
+XEN_ROOT = $(CURDIR)/../../..
+include $(XEN_ROOT)/Config.mk
+
 CC      = gcc
 
 GCC = gcc
@@ -5,7 +8,7 @@ BCC = bcc
 AS86 = as86
 
 RELEASE = `pwd | sed "s-.*/--"`
-VGABIOS_REL_DATE ?= `date '+%d %b %Y'`
+VGABIOS_REL_DATE ?= $(call date,"+%d %b %Y")
 RELVERS = `pwd | sed "s-.*/--" | sed "s/vgabios//" | sed "s/-//"`
 
 VGABIOS_DATE = "-DVGABIOS_DATE=\"$(VGABIOS_REL_DATE)\""
diff --git a/xen/Makefile b/xen/Makefile
index 2e1a925c84..a2d0795cde 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -14,15 +14,11 @@ export XEN_WHOAMI	?= $(USER)
 ifeq ($(origin XEN_DOMAIN), undefined)
 export XEN_DOMAIN	:= $(shell ([ -x /bin/dnsdomainname ] && /bin/dnsdomainname) || ([ -x /bin/domainname ] && /bin/domainname || echo [unknown]))
 endif
-ifeq ($(origin XEN_BUILD_DATE), undefined)
-export XEN_BUILD_DATE	:= $(shell LC_ALL=C date)
-endif
-ifeq ($(origin XEN_BUILD_TIME), undefined)
-export XEN_BUILD_TIME	:= $(shell LC_ALL=C date +%T)
-endif
 ifeq ($(origin XEN_BUILD_HOST), undefined)
 export XEN_BUILD_HOST	:= $(shell hostname)
 endif
+# XEN_BUILD_DATE and XEN_BUILD_TIME are set further down, as they depend on
+# Config.mk for SOURCE_DATE_EPOCH handling.
 
 # Best effort attempt to find a python interpreter, defaulting to Python 3 if
 # available.  Fall back to just `python`.
@@ -250,6 +246,13 @@ SRCARCH := $(shell echo $(ARCH) | \
         -e 's/riscv.*/riscv/g' -e 's/ppc.*/ppc/g')
 export ARCH SRCARCH
 
+ifeq ($(origin XEN_BUILD_DATE), undefined)
+export XEN_BUILD_DATE	:= $(call date)
+endif
+ifeq ($(origin XEN_BUILD_TIME), undefined)
+export XEN_BUILD_TIME	:= $(call date,"+%T")
+endif
+
 export CONFIG_SHELL := $(SHELL)
 export CC CXX LD NM OBJCOPY OBJDUMP ADDR2LINE
 export YACC = $(if $(BISON),$(BISON),bison)

--nextPart8343371.EvYhyI6sBW--

--nextPart4443138.kQq0lBPeGt
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

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

iQIzBAABCgAdFiEEQ8gZ7vwsPje0uPkIgepkfSQr0hUFAmd1kXwACgkQgepkfSQr
0hULZBAAvHqM+nMbdEAx417gDxIL1+CqjwOtIN6gF/UMpSycSGNhGVpNwCXJSRUk
1W61ct1PO5nyTIPaFCxFd45YnHzoWmEHcvWw+guSWGY5e+c9lZfr1qpXY/740rUh
aiRlYa+5Dia52fKotws4sJW65vje363tp7ZCHSQKU87V5pjiVo2Zb8mXog0q7IkZ
ClGwlpaWtyBPdlKnUayGmZ0Bm0NdZ5PYNtJtDCBxpJ+80XziVm6CCLxZb2pXljnD
SYa6IKTeSucZZYvXbdX/RnsWwQpLx6m44fXWjEkGJT6RRy8WdQtwfSehq/pWnqX4
F8ebMqYLl41Tb6W1Rd7nLxGBFkIP/vN7T14ILO4pUzrftLr4CDu3UDkXDekIIvKa
SbKQwxW+2S6Qy/gaF2A5Rca3d6GlcBei5tZEYYR4pbat+tlSSqlktC/afw2ApQgP
6sEPhs7neK7AXSRWQnEnco+WJxa43Vh6BRJoZiJJOqS6rdE74UGVkefS0Vc+UexK
4OOaSfAdHkmLhSuH7oakjmiQ4WUspQgjml9GHZ96u8IqEex5Ycz0NaQbORvlbeLC
cKhkkVGXbcPgGOaYk6j2VSVMHjcEdk33aOF9a1mivRs7rPXXPd+Tmp5pMHroboME
MCKm2RzSLb84BzwP6Sl6G1FNuNFcTTts4wXQ/19t/dP88HXcgw8=
=IFG8
-----END PGP SIGNATURE-----

--nextPart4443138.kQq0lBPeGt--





From xen-devel-bounces@lists.xenproject.org Thu Jan 02 08:45:55 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 08:45:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863731.1275102 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTGpu-000548-NI; Thu, 02 Jan 2025 08:45:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863731.1275102; Thu, 02 Jan 2025 08:45:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTGpu-00051D-IA; Thu, 02 Jan 2025 08:45:46 +0000
Received: by outflank-mailman (input) for mailman id 863731;
 Thu, 02 Jan 2025 08:45: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
 <SRS0=hHMo=T2=bounce.vates.tech=bounce-md_30504962.67765235.v1-b25bb21507ab41e49a5a6432f490ffb0@srs-se1.protection.inumbo.net>)
 id 1tTGpt-0004rF-LT
 for xen-devel@lists.xenproject.org; Thu, 02 Jan 2025 08:45:45 +0000
Received: from mail180-43.suw31.mandrillapp.com
 (mail180-43.suw31.mandrillapp.com [198.2.180.43])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f428e5d7-c8e5-11ef-a0db-8be0dac302b0;
 Thu, 02 Jan 2025 09:45:44 +0100 (CET)
Received: from pmta11.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail180-43.suw31.mandrillapp.com (Mailchimp) with ESMTP id
 4YP0fG01BLzLfHFtk
 for <xen-devel@lists.xenproject.org>; Thu,  2 Jan 2025 08:45:42 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 b25bb21507ab41e49a5a6432f490ffb0; Thu, 02 Jan 2025 08:45:41 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f428e5d7-c8e5-11ef-a0db-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1735807542; x=1736068042;
	bh=hkByZLzlrTXwHXqACXZ3W4ofBw/54TO6ZVkDh0SDWck=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=qRjX6uuvQTFN+E3Sz5ngLDXYHs9Z28eGHZ8DJ70l8b/Qt8hpcemSQzFlptMBR9fR0
	 OOdXrAD2TEMxMBo4gRjFfs+ZKVVu7Wx6zOjBYE2vNrsvaCug7kirYYyIiJxGOSZVHG
	 kRtgv9YWNVxs2k4CTsZVX/BBgLQw2ph4kk0W0qhqaNtRUs2yOrzQQGHsZt+0y3lwJs
	 ySLAoGn3Yupc20xqxruRxifHCNEPrR2OVu32yYbonSiVYrsQRHydXykHzbb+KNdycg
	 U9wOg6X9T1d4FIDNPUmXV7cF5DVCivj5ZnshQ6Xhm86jPvOjCkfAWM+XUHroF8KH4k
	 CosZhzl/WsRxg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1735807542; x=1736068042; i=ngoc-tu.dinh@vates.tech;
	bh=hkByZLzlrTXwHXqACXZ3W4ofBw/54TO6ZVkDh0SDWck=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=mNtI0Y832PLwvUSKMU4hCF3CVP7UH5Q/mOWj1qd4RyIGz+HstL1n501TS2eP3hDJK
	 meQau9ifxLlKgfYBYvCSutQNpWetuvvPbi+Mc2ZPWPfudylxlKuq8+iiRTu5Oja0Ln
	 oFYQJVfJ78UhE5WGTfts2scVqA2oh19jEexrfLIjdBBlWx0EjSY/bgMbhBcplp03y1
	 rD7WachW9uaCtQwuFkTexe4xfF0f48EEcfYH5yCe6i5V/wM3zdmx59EO4CwXxrtQgF
	 TqS7D0/NuE4yis+/0rmcVPdLS2ASWgDgglpxaZTxJ0Wj0Qp+qkNg6HnHCEoiNyggza
	 ACoMbO8oYybmg==
From: "Tu Dinh" <ngoc-tu.dinh@vates.tech>
Subject: =?utf-8?Q?[RFC=20PATCH=20v2=2010/10]=20x86/hvm:=20Enable=20XSAVES=20LBR=20save/restore?=
X-Mailer: git-send-email 2.43.0
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1735807541149
To: xen-devel@lists.xenproject.org
Cc: "Tu Dinh" <ngoc-tu.dinh@vates.tech>, "Anthony PERARD" <anthony.perard@vates.tech>, "Juergen Gross" <jgross@suse.com>, "Jan Beulich" <jbeulich@suse.com>, "Andrew Cooper" <andrew.cooper3@citrix.com>, "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>
Message-Id: <20250102084413.102-11-ngoc-tu.dinh@vates.tech>
In-Reply-To: <20250102084413.102-1-ngoc-tu.dinh@vates.tech>
References: <20250102084413.102-1-ngoc-tu.dinh@vates.tech>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.b25bb21507ab41e49a5a6432f490ffb0?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250102:md
Date: Thu, 02 Jan 2025 08:45:41 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Add a new save code type CPU_XSAVES_CODE containing a compressed XSAVES
image.

Signed-off-by: Tu Dinh <ngoc-tu.dinh@vates.tech>
---
 xen/arch/x86/hvm/hvm.c                 | 67 +++++++++++++++++++++-----
 xen/arch/x86/xstate.c                  |  3 +-
 xen/include/public/arch-x86/hvm/save.h |  4 +-
 3 files changed, 60 insertions(+), 14 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index c7b93c7d91..e5a50d9fca 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1238,6 +1238,36 @@ static int cf_check hvm_save_cpu_xsave_states(
     return 0;
 }
 
+#define HVM_CPU_XSAVES_SIZE(xcr0) (offsetof(struct hvm_hw_cpu_xsave, \
+                                            save_area) + \
+                                   xstate_compressed_size(xcr0))
+
+static int cf_check hvm_save_cpu_xsaves_states(
+    struct vcpu *v, hvm_domain_context_t *h)
+{
+    struct hvm_hw_cpu_xsave *ctxt;
+    unsigned int size;
+    int err;
+
+    if ( !xsave_enabled(v) )
+        return 0;   /* do nothing */
+
+    size = HVM_CPU_XSAVES_SIZE(v->arch.xcr0_accum);
+    err = _hvm_init_entry(h, CPU_XSAVES_CODE, v->vcpu_id, size);
+    if ( err )
+        return err;
+
+    ctxt = (struct hvm_hw_cpu_xsave *)&h->data[h->cur];
+    h->cur += size;
+    ctxt->xfeature_mask = xfeature_mask;
+    ctxt->xcr0 = v->arch.xcr0;
+    ctxt->xcr0_accum = v->arch.xcr0_accum;
+
+    memcpy(&ctxt->save_area, v->arch.xsave_area, size);
+
+    return 0;
+}
+
 /*
  * Structure layout conformity checks, documenting correctness of the cast in
  * the invocation of validate_xstate() below.
@@ -1311,6 +1341,10 @@ static int cf_check hvm_load_cpu_xsave_states(
     ctxt = (struct hvm_hw_cpu_xsave *)&h->data[h->cur];
     h->cur += desc->length;
 
+    if ( !cpu_has_xsaves &&
+         xsave_area_compressed((const void *)&ctxt->save_area) )
+        return -EOPNOTSUPP;
+
     err = validate_xstate(d, ctxt->xcr0, ctxt->xcr0_accum,
                           (const void *)&ctxt->save_area.xsave_hdr);
     if ( err )
@@ -1322,7 +1356,10 @@ static int cf_check hvm_load_cpu_xsave_states(
                ctxt->xcr0, ctxt->save_area.xsave_hdr.xstate_bv, err);
         return err;
     }
-    size = HVM_CPU_XSAVE_SIZE(ctxt->xcr0_accum);
+    if ( xsave_area_compressed((const void *)&ctxt->save_area) )
+        size = HVM_CPU_XSAVES_SIZE(ctxt->xcr0_accum);
+    else
+        size = HVM_CPU_XSAVE_SIZE(ctxt->xcr0_accum);
     desc_length = desc->length;
     if ( desc_length > size )
     {
@@ -1348,14 +1385,7 @@ static int cf_check hvm_load_cpu_xsave_states(
         desc_length = size;
     }
 
-    if ( xsave_area_compressed((const void *)&ctxt->save_area) )
-    {
-        printk(XENLOG_G_WARNING
-               "HVM%d.%u restore: compressed xsave state not supported\n",
-               d->domain_id, vcpuid);
-        return -EOPNOTSUPP;
-    }
-    else if ( desc_length != size )
+    if ( desc_length != size )
     {
         printk(XENLOG_G_WARNING
                "HVM%d.%u restore mismatch: xsave length %#x != %#x\n",
@@ -1367,8 +1397,13 @@ static int cf_check hvm_load_cpu_xsave_states(
     v->arch.xcr0 = ctxt->xcr0;
     v->arch.xcr0_accum = ctxt->xcr0_accum;
     v->arch.nonlazy_xstate_used = ctxt->xcr0_accum & XSTATE_NONLAZY;
-    compress_xsave_states(v, &ctxt->save_area,
-                          size - offsetof(struct hvm_hw_cpu_xsave, save_area));
+    if ( xsave_area_compressed((const void *)&ctxt->save_area) )
+        memcpy(v->arch.xsave_area, &ctxt->save_area,
+               size - offsetof(struct hvm_hw_cpu_xsave, save_area));
+    else
+        compress_xsave_states(v, &ctxt->save_area,
+                              size - offsetof(struct hvm_hw_cpu_xsave,
+                                              save_area));
 
     return 0;
 }
@@ -1385,6 +1420,7 @@ static const uint32_t msrs_to_send[] = {
     MSR_AMD64_DR1_ADDRESS_MASK,
     MSR_AMD64_DR2_ADDRESS_MASK,
     MSR_AMD64_DR3_ADDRESS_MASK,
+    MSR_LBR_DEPTH,
 };
 
 static int cf_check hvm_save_cpu_msrs(struct vcpu *v, hvm_domain_context_t *h)
@@ -1572,6 +1608,15 @@ static int __init cf_check hvm_register_CPU_save_and_restore(void)
                             sizeof(struct hvm_save_descriptor),
                         HVMSR_PER_VCPU);
 
+    hvm_register_savevm(CPU_XSAVES_CODE,
+                        "CPU_XSAVES",
+                        hvm_save_cpu_xsaves_states,
+                        NULL,
+                        hvm_load_cpu_xsave_states,
+                        HVM_CPU_XSAVES_SIZE(xfeature_mask) +
+                            sizeof(struct hvm_save_descriptor),
+                        HVMSR_PER_VCPU);
+
     hvm_register_savevm(CPU_MSR_CODE,
                         "CPU_MSR",
                         hvm_save_cpu_msrs,
diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c
index 607bf9c8a5..1c7a39e778 100644
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86/xstate.c
@@ -946,8 +946,7 @@ int validate_xstate(const struct domain *d, uint64_t xcr0, uint64_t xcr0_accum,
          !valid_xcr0(xcr0_accum) )
         return -EINVAL;
 
-    if ( (xcr0_accum & ~xfeature_mask) ||
-         hdr->xcomp_bv )
+    if ( xcr0_accum & ~xfeature_mask )
         return -EOPNOTSUPP;
 
     for ( i = 0; i < ARRAY_SIZE(hdr->reserved); ++i )
diff --git a/xen/include/public/arch-x86/hvm/save.h b/xen/include/public/arch-x86/hvm/save.h
index 7ecacadde1..89651f3dd3 100644
--- a/xen/include/public/arch-x86/hvm/save.h
+++ b/xen/include/public/arch-x86/hvm/save.h
@@ -624,12 +624,14 @@ struct hvm_msr {
 
 #define CPU_MSR_CODE  20
 
+#define CPU_XSAVES_CODE 21
+
 /* Range 22 - 34 (inclusive) reserved for Amazon */
 
 /*
  * Largest type-code in use
  */
-#define HVM_SAVE_CODE_MAX 20
+#define HVM_SAVE_CODE_MAX 21
 
 #endif /* __XEN_PUBLIC_HVM_SAVE_X86_H__ */
 
-- 
2.43.0



Ngoc Tu Dinh | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


From xen-devel-bounces@lists.xenproject.org Thu Jan 02 08:45:55 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 08:45:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863735.1275139 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTGpx-0005tN-DZ; Thu, 02 Jan 2025 08:45:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863735.1275139; Thu, 02 Jan 2025 08:45:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTGpx-0005pv-5B; Thu, 02 Jan 2025 08:45:49 +0000
Received: by outflank-mailman (input) for mailman id 863735;
 Thu, 02 Jan 2025 08:45: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
 <SRS0=oHwR=T2=bounce.vates.tech=bounce-md_30504962.67765234.v1-82f3a02c5edd4500b772e324054fe213@srs-se1.protection.inumbo.net>)
 id 1tTGpv-0004rS-Th
 for xen-devel@lists.xenproject.org; Thu, 02 Jan 2025 08:45:47 +0000
Received: from mail180-50.suw31.mandrillapp.com
 (mail180-50.suw31.mandrillapp.com [198.2.180.50])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f48e5d1a-c8e5-11ef-99a4-01e77a169b0f;
 Thu, 02 Jan 2025 09:45:44 +0100 (CET)
Received: from pmta11.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail180-50.suw31.mandrillapp.com (Mailchimp) with ESMTP id
 4YP0fD3qg1zCfD7NJ
 for <xen-devel@lists.xenproject.org>; Thu,  2 Jan 2025 08:45:40 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 82f3a02c5edd4500b772e324054fe213; Thu, 02 Jan 2025 08:45:40 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f48e5d1a-c8e5-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1735807540; x=1736068040;
	bh=lteVOQO/826dQJiMQ3UsqhNPnk1VKMnXNeukA1WaOSo=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=A6bso6XOHwrewVbQ+GskSObYNPGIX1Z4vhv/ffgdUazMyxQSZsEEaPk0tuSGHrq/F
	 KYgQCzfwX0m5g/4AVJehlT1kJzGpXcUgETl0kHVv8aK1NpKDtShWDszEtWijRe+zhV
	 cxKDotiNCCNYhL3hCpGErxUnTkGhBQs05o0SmRlNIQpHr2AsrjP984+UZyIJoGBUpH
	 OMlT1szBwBRh4qM/VTzbHtG0B/ZEMCNUHKfo5dwdDFMSrxvtDDlQKIE/JNI386Y/E1
	 KJj/SXclW1/ha0rF9iIiQ+2V4tHqTxkU2c2XAoFEVl+/bucBAnFeacesc+Bai+6asa
	 W8WNAuglkrvOQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1735807540; x=1736068040; i=ngoc-tu.dinh@vates.tech;
	bh=lteVOQO/826dQJiMQ3UsqhNPnk1VKMnXNeukA1WaOSo=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=UfzJS6fJ8E+WavFGOSGkBzZTURV4Gl+aOiYx+VuffqxzhyZWj3xr5tQAgiogajDYK
	 LuY4Us1eph/9dB0X8QxdP7KYNI+SqK5sXjzGPsH2XGjnN5j7cPb+fKjdFZhd9n0C8f
	 ZW0MyY0IP82iB+Z6lgdGg5J73x1Q5+SYD0PhNpnFBNeR4nj0KI089j6o8nSidVLkqN
	 WBJ+gyyL6n8i+mBxN1CRErFBE0wkFa/cpshmwfcEH7m8Ee0H/rFbKBeHcm8VrGk+WV
	 4TIzgUQcVJIEZiPNa6p19D9v2hNmiC4KzrFPa0xNfp+BCTO65QjEITQbBXmYsK4+JJ
	 onHUjurDqe5Kw==
From: "Tu Dinh" <ngoc-tu.dinh@vates.tech>
Subject: =?utf-8?Q?[RFC=20PATCH=20v2=2004/10]=20x86:=20Calculate=20arch=20LBR=20CPUID=20policies?=
X-Mailer: git-send-email 2.43.0
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1735807539667
To: xen-devel@lists.xenproject.org
Cc: "Tu Dinh" <ngoc-tu.dinh@vates.tech>, "Anthony PERARD" <anthony.perard@vates.tech>, "Juergen Gross" <jgross@suse.com>, "Jan Beulich" <jbeulich@suse.com>, "Andrew Cooper" <andrew.cooper3@citrix.com>, "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>
Message-Id: <20250102084413.102-5-ngoc-tu.dinh@vates.tech>
In-Reply-To: <20250102084413.102-1-ngoc-tu.dinh@vates.tech>
References: <20250102084413.102-1-ngoc-tu.dinh@vates.tech>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.82f3a02c5edd4500b772e324054fe213?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250102:md
Date: Thu, 02 Jan 2025 08:45:40 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Ensure that the arch LBR feature and its dependents are disabled if any
prerequisites are not available.

Signed-off-by: Tu Dinh <ngoc-tu.dinh@vates.tech>
---
 xen/arch/x86/cpu-policy.c | 28 ++++++++++++++++++++++++++++
 xen/arch/x86/cpu/common.c |  7 +++++++
 2 files changed, 35 insertions(+)

diff --git a/xen/arch/x86/cpu-policy.c b/xen/arch/x86/cpu-policy.c
index 78bc9872b0..b1398b2e3c 100644
--- a/xen/arch/x86/cpu-policy.c
+++ b/xen/arch/x86/cpu-policy.c
@@ -190,6 +190,16 @@ static void sanitise_featureset(uint32_t *fs)
     }
 }
 
+static void recalculate_arch_lbr(struct cpu_policy *p)
+{
+    if ( p->basic.max_leaf < 0x1c ||
+         !(cpu_policy_xstates(&host_cpu_policy) & X86_XSS_LBR) ||
+         p->basic.lbr_1Ca.supported_depths == 0)
+        p->feat.arch_lbr = 0;
+    if ( !p->feat.arch_lbr )
+        p->basic.raw[0x1c] = EMPTY_LEAF;
+}
+
 static void recalculate_xstate(struct cpu_policy *p)
 {
     uint64_t xstates = XSTATE_FP_SSE;
@@ -219,6 +229,9 @@ static void recalculate_xstate(struct cpu_policy *p)
     if ( p->feat.amx_tile )
         xstates |= X86_XCR0_TILE_CFG | X86_XCR0_TILE_DATA;
 
+    if ( p->feat.arch_lbr )
+        xstates |= X86_XSS_LBR;
+
     /* Subleaf 0 */
     p->xstate.max_size =
         xstate_uncompressed_size(xstates & ~XSTATE_XSAVES_ONLY);
@@ -271,6 +284,8 @@ static void recalculate_misc(struct cpu_policy *p)
 
     p->basic.raw[0xc] = EMPTY_LEAF;
 
+    zero_leaves(p->basic.raw, 0xe, 0x1b);
+
     p->extd.e1d &= ~CPUID_COMMON_1D_FEATURES;
 
     /* Most of Power/RAS hidden from guests. */
@@ -630,6 +645,7 @@ static void __init calculate_pv_max_policy(void)
 
     sanitise_featureset(fs);
     x86_cpu_featureset_to_policy(fs, p);
+    recalculate_arch_lbr(p);
     recalculate_xstate(p);
 
     p->extd.raw[0xa] = EMPTY_LEAF; /* No SVM for PV guests. */
@@ -670,6 +686,7 @@ static void __init calculate_pv_def_policy(void)
     }
 
     x86_cpu_featureset_to_policy(fs, p);
+    recalculate_arch_lbr(p);
     recalculate_xstate(p);
 }
 
@@ -755,6 +772,14 @@ static void __init calculate_hvm_max_policy(void)
 
         if ( !cpu_has_vmx_xsaves )
             __clear_bit(X86_FEATURE_XSAVES, fs);
+
+        /*
+         * VMX bitmap is needed for passing through LBR info MSRs.
+         * Require it for virtual arch LBR.
+         */
+        if ( !cpu_has_vmx_guest_lbr_ctl || !cpu_has_vmx_msr_bitmap ||
+             !cpu_has_vmx_xsaves )
+            __clear_bit(X86_FEATURE_ARCH_LBR, fs);
     }
 
     /*
@@ -787,6 +812,7 @@ static void __init calculate_hvm_max_policy(void)
 
     sanitise_featureset(fs);
     x86_cpu_featureset_to_policy(fs, p);
+    recalculate_arch_lbr(p);
     recalculate_xstate(p);
 
     /* It's always possible to emulate CPUID faulting for HVM guests */
@@ -839,6 +865,7 @@ static void __init calculate_hvm_def_policy(void)
     }
 
     x86_cpu_featureset_to_policy(fs, p);
+    recalculate_arch_lbr(p);
     recalculate_xstate(p);
 }
 
@@ -971,6 +998,7 @@ void recalculate_cpuid_policy(struct domain *d)
 
     p->extd.maxlinaddr = p->extd.lm ? 48 : 32;
 
+    recalculate_arch_lbr(p);
     recalculate_xstate(p);
     recalculate_misc(p);
 
diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index 067d855bad..0056b55457 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -505,6 +505,13 @@ static void generic_identify(struct cpuinfo_x86 *c)
 			    &c->x86_capability[FEATURESET_Da1],
 			    &tmp, &tmp, &tmp);
 
+	if (c->cpuid_level >= 0x1c)
+		cpuid(0x1c,
+		      &c->x86_capability[FEATURESET_1Ca],
+		      &c->x86_capability[FEATURESET_1Cb],
+		      &c->x86_capability[FEATURESET_1Cc],
+		      &tmp);
+
 	if (test_bit(X86_FEATURE_ARCH_CAPS, c->x86_capability))
 		rdmsr(MSR_ARCH_CAPABILITIES,
 		      c->x86_capability[FEATURESET_m10Al],
-- 
2.43.0



Ngoc Tu Dinh | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


From xen-devel-bounces@lists.xenproject.org Thu Jan 02 08:45:55 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 08:45:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863729.1275089 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTGpu-0004rf-1C; Thu, 02 Jan 2025 08:45:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863729.1275089; Thu, 02 Jan 2025 08:45:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTGpt-0004rY-TG; Thu, 02 Jan 2025 08:45:45 +0000
Received: by outflank-mailman (input) for mailman id 863729;
 Thu, 02 Jan 2025 08:45: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
 <SRS0=W3rD=T2=bounce.vates.tech=bounce-md_30504962.67765233.v1-df1be6e558d14edfa793741efcf07dff@srs-se1.protection.inumbo.net>)
 id 1tTGps-0004rF-0c
 for xen-devel@lists.xenproject.org; Thu, 02 Jan 2025 08:45:44 +0000
Received: from mail180-50.suw31.mandrillapp.com
 (mail180-50.suw31.mandrillapp.com [198.2.180.50])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f1f4674c-c8e5-11ef-a0db-8be0dac302b0;
 Thu, 02 Jan 2025 09:45:41 +0100 (CET)
Received: from pmta11.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail180-50.suw31.mandrillapp.com (Mailchimp) with ESMTP id
 4YP0fC5pWxzCf9LdN
 for <xen-devel@lists.xenproject.org>; Thu,  2 Jan 2025 08:45:39 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 df1be6e558d14edfa793741efcf07dff; Thu, 02 Jan 2025 08:45:39 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f1f4674c-c8e5-11ef-a0db-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1735807539; x=1736068039;
	bh=BJl20UXfBA4BW0v81Q6NN4eicGukuW4vkuA5YVw5iK4=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=R2HyN6daFUx7f/DGci4uyqP1DGfmGBFXYvMbr7UXaGvdwtiwsTbHFHiZsr0+GOXuF
	 A3D6aWyivUX/ukCkeRQ0FDzYPC4dgm7HP7TDgC3BLj0U1RU6tSMnItZV0xaOmrZu/Z
	 YWcYyW8EGIDmVz3kbo7y8YsEzvDH+kZzUmT8azr+mtYNcLOLSLbO/9lZ9ELTmiXNtn
	 tg5q8HyAr9KvN3rApou2nfV9Ao0jijvI27vuqqX0wv9MS6bAItYjpnBvPyLzZTEP4M
	 BSXHZq5VDWkkO3dinfIfbMwjqeFvGcwKJ5q6u2r+/pZ2PjfgPB903j5GRCzh06iUQF
	 kWIlfcmPg7IcQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1735807539; x=1736068039; i=ngoc-tu.dinh@vates.tech;
	bh=BJl20UXfBA4BW0v81Q6NN4eicGukuW4vkuA5YVw5iK4=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=hEV/1FEFqKFnyK7Vu6MLCMxGqVFzDgIr9pq9Urh6J5V1TmqGYD5eipLawoj0SOstN
	 zMso3m0sQ6O+yWz697lo+CiTrHrXGmUxXGdkrvop3jB/2BIgwrXEvjSl+DqOVBbYHI
	 k7uWaUDxb9J1WZpn1s38hL0TsYwIYONUBW21dhfIE+cu+Z/4oD3IelqwCgbz23JMkw
	 US36Xt4nip40aaUwDtp4VTmHVkPRbcpuxVAbYR4iUyukz1SbERhDqJQ0qqy+SMyjf8
	 xQsQYvnQ2x72D3Pim1X+EzwWIFX2n0MkPLEhH1LcK2ABFuMeTKBJJuCkuaW7MjF3Q5
	 zu5h9TexRgPYA==
From: "Tu Dinh" <ngoc-tu.dinh@vates.tech>
Subject: =?utf-8?Q?[RFC=20PATCH=20v2=2001/10]=20x86:=20Add=20architectural=20LBR=20definitions?=
X-Mailer: git-send-email 2.43.0
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1735807538677
To: xen-devel@lists.xenproject.org
Cc: "Tu Dinh" <ngoc-tu.dinh@vates.tech>, "Anthony PERARD" <anthony.perard@vates.tech>, "Juergen Gross" <jgross@suse.com>, "Jan Beulich" <jbeulich@suse.com>, "Andrew Cooper" <andrew.cooper3@citrix.com>, "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>
Message-Id: <20250102084413.102-2-ngoc-tu.dinh@vates.tech>
In-Reply-To: <20250102084413.102-1-ngoc-tu.dinh@vates.tech>
References: <20250102084413.102-1-ngoc-tu.dinh@vates.tech>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.df1be6e558d14edfa793741efcf07dff?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250102:md
Date: Thu, 02 Jan 2025 08:45:39 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Signed-off-by: Tu Dinh <ngoc-tu.dinh@vates.tech>
---
 xen/arch/x86/include/asm/msr-index.h | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/xen/arch/x86/include/asm/msr-index.h b/xen/arch/x86/include/asm/msr-index.h
index 9cdb5b2625..97df740b04 100644
--- a/xen/arch/x86/include/asm/msr-index.h
+++ b/xen/arch/x86/include/asm/msr-index.h
@@ -112,6 +112,8 @@
 #define  MCU_OPT_CTRL_GDS_MIT_DIS           (_AC(1, ULL) <<  4)
 #define  MCU_OPT_CTRL_GDS_MIT_LOCK          (_AC(1, ULL) <<  5)
 
+#define MSR_LER_INFO                        0x000001e0
+
 #define MSR_RTIT_OUTPUT_BASE                0x00000560
 #define MSR_RTIT_OUTPUT_MASK                0x00000561
 #define MSR_RTIT_CTL                        0x00000570
@@ -193,6 +195,16 @@
 #define MSR_UARCH_MISC_CTRL                 0x00001b01
 #define  UARCH_CTRL_DOITM                   (_AC(1, ULL) <<  0)
 
+/* Architectural LBR state MSRs */
+#define MSR_LBR_INFO(n)                     (0x00001200 + (n))
+#define MSR_LBR_CTL                         0x000014ce
+#define  LBR_CTL_VALID                      _AC(0x7f000f, ULL)
+#define MSR_LBR_DEPTH                       0x000014cf
+#define MSR_LBR_FROM_IP(n)                  (0x00001500 + (n))
+#define MSR_LBR_TO_IP(n)                    (0x00001600 + (n))
+/* Must be updated along with XSTATE LBR state size */
+#define NUM_MSR_ARCH_LBR_FROM_TO            32
+
 #define MSR_EFER                            _AC(0xc0000080, U) /* Extended Feature Enable Register */
 #define  EFER_SCE                           (_AC(1, ULL) <<  0) /* SYSCALL Enable */
 #define  EFER_LME                           (_AC(1, ULL) <<  8) /* Long Mode Enable */
-- 
2.43.0



Ngoc Tu Dinh | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


From xen-devel-bounces@lists.xenproject.org Thu Jan 02 08:45:55 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 08:45:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863737.1275165 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTGpz-0006X4-5D; Thu, 02 Jan 2025 08:45:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863737.1275165; Thu, 02 Jan 2025 08:45:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTGpy-0006W9-Sk; Thu, 02 Jan 2025 08:45:50 +0000
Received: by outflank-mailman (input) for mailman id 863737;
 Thu, 02 Jan 2025 08:45:50 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=LCcj=T2=bounce.vates.tech=bounce-md_30504962.67765234.v1-18bc4adf6c0c4943a835c5bc80ce84cb@srs-se1.protection.inumbo.net>)
 id 1tTGpx-0004rS-UK
 for xen-devel@lists.xenproject.org; Thu, 02 Jan 2025 08:45:49 +0000
Received: from mail180-50.suw31.mandrillapp.com
 (mail180-50.suw31.mandrillapp.com [198.2.180.50])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f5908fed-c8e5-11ef-99a4-01e77a169b0f;
 Thu, 02 Jan 2025 09:45:46 +0100 (CET)
Received: from pmta11.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail180-50.suw31.mandrillapp.com (Mailchimp) with ESMTP id
 4YP0fD5n5HzCf9M37
 for <xen-devel@lists.xenproject.org>; Thu,  2 Jan 2025 08:45:40 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 18bc4adf6c0c4943a835c5bc80ce84cb; Thu, 02 Jan 2025 08:45:40 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f5908fed-c8e5-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1735807540; x=1736068040;
	bh=mzhXuh0ndyjVjpzrrKA3CLzzrom7CZG1ilSX478/eBg=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=oDCE65nLyW+4kZGft2uh059FpwIwEueCaNkKPOqR4qKgZ9asIUVyLSu9WliVX/lFt
	 HjW7vUdQvjKPQ+Z5vsIT+NDkW3B5f4NuFGyaZn7ebPHat+5nJY9k3j4OcCDBeT8Hf5
	 SuzhFE6e0ZBcTcjCt6nvUoSIRhlKXHU/gBLgd69GiYaQTg7DdMk0rjrtn9mhNww5J/
	 i8T6DkNcuzuie6/zz8hj0LRvcf+SurMdLTj7slyVyXsZeGFyRJnYDJi4Svu0qy8ekQ
	 HCztn4N6idpPsqlKxpb34fOVZAZN9aWPKRf1nbBNNt4IPi8joto40BELFQ3eNQjxw+
	 HrWVGMELfkFzQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1735807540; x=1736068040; i=ngoc-tu.dinh@vates.tech;
	bh=mzhXuh0ndyjVjpzrrKA3CLzzrom7CZG1ilSX478/eBg=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=O+r6NcYohpfHx1h+H0YjkdzcWSY9atwvPggh+iuatsHlmcnivPBokfNhI88D02J7C
	 avhzxVYyQM7mFbxrG1Tax4w2HEdM63sEWtui4MOwGev9O2POXZFC0gzfG1vevkNgI4
	 D5odIRyCKRLqNb8ZHiCkzr6UFykXnhdo7mlog4CJgBXGBB1GbaCWuHCGEGw/Z9FlwC
	 o8+gAo9DIHkq1QDWKRwJH1tbkKTwRY9Ef0IRs8fbg8RPuA78jTIRH83e6dlm9W4Sz4
	 ZVgScCgL+8YNyam/yi7Bslp9G4jjgjym9OWSpUWh/8Cdr0pq9Wsf+hgnMzt5Jcr947
	 91P/BmnQ1CICA==
From: "Tu Dinh" <ngoc-tu.dinh@vates.tech>
Subject: =?utf-8?Q?[RFC=20PATCH=20v2=2005/10]=20x86:=20Keep=20a=20copy=20of=20XSAVE=20area=20size?=
X-Mailer: git-send-email 2.43.0
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1735807539875
To: xen-devel@lists.xenproject.org
Cc: "Tu Dinh" <ngoc-tu.dinh@vates.tech>, "Anthony PERARD" <anthony.perard@vates.tech>, "Juergen Gross" <jgross@suse.com>, "Jan Beulich" <jbeulich@suse.com>, "Andrew Cooper" <andrew.cooper3@citrix.com>, "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>
Message-Id: <20250102084413.102-6-ngoc-tu.dinh@vates.tech>
In-Reply-To: <20250102084413.102-1-ngoc-tu.dinh@vates.tech>
References: <20250102084413.102-1-ngoc-tu.dinh@vates.tech>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.18bc4adf6c0c4943a835c5bc80ce84cb?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250102:md
Date: Thu, 02 Jan 2025 08:45:40 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Signed-off-by: Tu Dinh <ngoc-tu.dinh@vates.tech>
---
 xen/arch/x86/include/asm/domain.h | 1 +
 xen/arch/x86/xstate.c             | 1 +
 2 files changed, 2 insertions(+)

diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h
index b79d6badd7..d3f2695c20 100644
--- a/xen/arch/x86/include/asm/domain.h
+++ b/xen/arch/x86/include/asm/domain.h
@@ -638,6 +638,7 @@ struct arch_vcpu
      * #NM handler, we XRSTOR the states we XSAVE-ed;
      */
     struct xsave_struct *xsave_area;
+    unsigned int xsave_area_size;
     uint64_t xcr0;
     /* Accumulated eXtended features mask for using XSAVE/XRESTORE by Xen
      * itself, as we can never know whether guest OS depends on content
diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c
index af9e345a7a..baae8e1a13 100644
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86/xstate.c
@@ -550,6 +550,7 @@ int xstate_alloc_save_area(struct vcpu *v)
     save_area->fpu_sse.mxcsr = MXCSR_DEFAULT;
 
     v->arch.xsave_area = save_area;
+    v->arch.xsave_area_size = size;
     v->arch.xcr0 = 0;
     v->arch.xcr0_accum = 0;
 
-- 
2.43.0



Ngoc Tu Dinh | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


From xen-devel-bounces@lists.xenproject.org Thu Jan 02 08:45:55 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 08:45:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863738.1275178 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTGq0-0006yX-J9; Thu, 02 Jan 2025 08:45:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863738.1275178; Thu, 02 Jan 2025 08:45:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTGq0-0006yI-Dq; Thu, 02 Jan 2025 08:45:52 +0000
Received: by outflank-mailman (input) for mailman id 863738;
 Thu, 02 Jan 2025 08:45:51 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Aw1p=T2=bounce.vates.tech=bounce-md_30504962.67765234.v1-90040212465a4a738ee55cacd36524b5@srs-se1.protection.inumbo.net>)
 id 1tTGpy-0004rS-Uf
 for xen-devel@lists.xenproject.org; Thu, 02 Jan 2025 08:45:50 +0000
Received: from mail180-50.suw31.mandrillapp.com
 (mail180-50.suw31.mandrillapp.com [198.2.180.50])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f6180e64-c8e5-11ef-99a4-01e77a169b0f;
 Thu, 02 Jan 2025 09:45:47 +0100 (CET)
Received: from pmta11.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail180-50.suw31.mandrillapp.com (Mailchimp) with ESMTP id
 4YP0fF0HDGzCf9PP7
 for <xen-devel@lists.xenproject.org>; Thu,  2 Jan 2025 08:45:41 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 90040212465a4a738ee55cacd36524b5; Thu, 02 Jan 2025 08:45:41 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f6180e64-c8e5-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1735807541; x=1736068041;
	bh=TpWqF+7FFQ/hg2SGplPXaNKTXRGvQnA48A/EDvktoFg=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=wZggbVYg/0D2l7QYN02MOgR+27vLGOqgHk9ISz2Iroxf9JE31GrQS6PkvY8ZsFMNB
	 xicMvz7ofdHZR/srTQRrHMmMp4xgEJOpLbyuNlHCoT3tHBDNDaIFeei6IzcOLjaQJ2
	 hjq08RoeD0Rl1D/p3XyLhXeVXch6pquZD7nqDAhUPEpJf37fvPDlQcigSffPqAFIDV
	 GymYotau6IfIdlh2W3xg6RAF4Mc1pIDkf1FVtWmsU1acoMQQd8pAcjOs3dCLwwYbi9
	 dR2ef/aAbMt3UOstha+F5ezga3Dr+/GDNExeQeUwX8NiSi1isGwRLwSCsMkTVgj+Y5
	 EIopVjjhQsidw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1735807541; x=1736068041; i=ngoc-tu.dinh@vates.tech;
	bh=TpWqF+7FFQ/hg2SGplPXaNKTXRGvQnA48A/EDvktoFg=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=Hn3NVoe1PhkrToobEUFCMSDliQow30HntEDnILD8wUomW/r1LuP7eFIHor5R/Tqok
	 8pzaAqs/uICRumoYKyo7dutEciIN/RkC1xPPjhPppKiDcsDZGkHOAoYTeCPwIzuxHU
	 5BF1KDf35bywQWK7oQY4t9lFuoZOSF0tM4L8k45HIHq7MfNrmUmf+eWSCONPXi11YL
	 DRq8NXmjpcs3wpDLCX+oKuZS68XF3SzGASf6gT4eOde52Ai1CVZRv3dVsOAfmxV4UC
	 TFgUpq+w5eRn1o60yXZYZtpuvyAtqBCJtS40nl11CylMTubfDoBv/22Tihr+5oha3f
	 oc3pi+tABpkLQ==
From: "Tu Dinh" <ngoc-tu.dinh@vates.tech>
Subject: =?utf-8?Q?[RFC=20PATCH=20v2=2006/10]=20x86:=20Enable=20XSTATE=20save/restore=20for=20arch=20LBR?=
X-Mailer: git-send-email 2.43.0
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1735807540083
To: xen-devel@lists.xenproject.org
Cc: "Tu Dinh" <ngoc-tu.dinh@vates.tech>, "Anthony PERARD" <anthony.perard@vates.tech>, "Juergen Gross" <jgross@suse.com>, "Jan Beulich" <jbeulich@suse.com>, "Andrew Cooper" <andrew.cooper3@citrix.com>, "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>
Message-Id: <20250102084413.102-7-ngoc-tu.dinh@vates.tech>
In-Reply-To: <20250102084413.102-1-ngoc-tu.dinh@vates.tech>
References: <20250102084413.102-1-ngoc-tu.dinh@vates.tech>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.90040212465a4a738ee55cacd36524b5?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250102:md
Date: Thu, 02 Jan 2025 08:45:41 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Add a function get_xstate_component_comp() to allow fetching a specific
XSTATE component from a compressed image.

Also add LBR state declarations in xstate.h.

Signed-off-by: Tu Dinh <ngoc-tu.dinh@vates.tech>
---
 xen/arch/x86/include/asm/xstate.h | 22 ++++++++-
 xen/arch/x86/msr.c                |  3 +-
 xen/arch/x86/xstate.c             | 79 +++++++++++++++++++++++--------
 3 files changed, 79 insertions(+), 25 deletions(-)

diff --git a/xen/arch/x86/include/asm/xstate.h b/xen/arch/x86/include/asm/xstate.h
index 07017cc4ed..cc77f599d7 100644
--- a/xen/arch/x86/include/asm/xstate.h
+++ b/xen/arch/x86/include/asm/xstate.h
@@ -33,13 +33,13 @@ extern uint32_t mxcsr_mask;
 #define XSTATE_FP_SSE  (X86_XCR0_X87 | X86_XCR0_SSE)
 #define XCNTXT_MASK    (X86_XCR0_X87 | X86_XCR0_SSE | X86_XCR0_YMM | \
                         X86_XCR0_OPMASK | X86_XCR0_ZMM | X86_XCR0_HI_ZMM | \
-                        XSTATE_NONLAZY)
+                        XSTATE_NONLAZY | XSTATE_XSAVES_ONLY)
 
 #define XSTATE_ALL     (~(1ULL << 63))
 #define XSTATE_NONLAZY (X86_XCR0_BNDREGS | X86_XCR0_BNDCSR | X86_XCR0_PKRU | \
                         X86_XCR0_TILE_CFG | X86_XCR0_TILE_DATA)
 #define XSTATE_LAZY    (XSTATE_ALL & ~XSTATE_NONLAZY)
-#define XSTATE_XSAVES_ONLY         0
+#define XSTATE_XSAVES_ONLY         (X86_XSS_LBR)
 #define XSTATE_COMPACTION_ENABLED  (1ULL << 63)
 
 #define XSTATE_XSS     (1U << 0)
@@ -91,6 +91,21 @@ struct xstate_bndcsr {
     uint64_t bndstatus;
 };
 
+struct xstate_lbr_entry {
+    uint64_t lbr_from_ip;
+    uint64_t lbr_to_ip;
+    uint64_t lbr_info;
+};
+
+struct xstate_lbr {
+	uint64_t lbr_ctl;
+	uint64_t lbr_depth;
+	uint64_t ler_from_ip;
+	uint64_t ler_to_ip;
+	uint64_t ler_info;
+	struct xstate_lbr_entry entries[32];
+};
+
 /* extended state operations */
 bool __must_check set_xcr0(u64 xfeatures);
 uint64_t get_xcr0(void);
@@ -114,6 +129,9 @@ int xstate_alloc_save_area(struct vcpu *v);
 void xstate_init(struct cpuinfo_x86 *c);
 unsigned int xstate_uncompressed_size(uint64_t xcr0);
 unsigned int xstate_compressed_size(uint64_t xstates);
+void *get_xstate_component_comp(struct xsave_struct *xstate,
+                                unsigned int size,
+                                uint64_t component);
 
 static inline uint64_t xgetbv(unsigned int index)
 {
diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
index 289cf10b78..68a419ac8e 100644
--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -522,8 +522,7 @@ int guest_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val)
         if ( !cp->xstate.xsaves )
             goto gp_fault;
 
-        /* No XSS features currently supported for guests */
-        if ( val != 0 )
+        if ( val & ~(uint64_t)XSTATE_XSAVES_ONLY )
             goto gp_fault;
 
         msrs->xss.raw = val;
diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c
index baae8e1a13..607bf9c8a5 100644
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86/xstate.c
@@ -18,13 +18,16 @@
 #include <asm/asm_defns.h>
 
 /*
- * Maximum size (in byte) of the XSAVE/XRSTOR save area required by all
+ * Maximum size (in byte) of the XSAVE(S)/XRSTOR(S) save area required by all
  * the supported and enabled features on the processor, including the
  * XSAVE.HEADER. We only enable XCNTXT_MASK that we have known.
  */
 static u32 __read_mostly xsave_cntxt_size;
 
-/* A 64-bit bitmask of the XSAVE/XRSTOR features supported by processor. */
+/*
+ * A 64-bit bitmask of the XSAVE(S)/XRSTOR(S) features supported by
+ * processor.
+ */
 u64 __read_mostly xfeature_mask;
 
 unsigned int *__read_mostly xstate_offsets;
@@ -126,7 +129,8 @@ static int setup_xstate_features(bool bsp)
             cpuid_count(XSTATE_CPUID, leaf, &eax,
                         &ebx, &ecx, &edx);
             BUG_ON(eax != xstate_sizes[leaf]);
-            BUG_ON(ebx != xstate_offsets[leaf]);
+            if ( (1ul << leaf) & X86_XCR0_STATES )
+                BUG_ON(ebx != xstate_offsets[leaf]);
             BUG_ON(!(ecx & XSTATE_ALIGN64) != !test_bit(leaf, &xstate_align));
         }
     }
@@ -210,7 +214,7 @@ void expand_xsave_states(const struct vcpu *v, void *dest, unsigned int size)
      * non-compacted offset.
      */
     src = xstate;
-    valid = xstate_bv & ~XSTATE_FP_SSE;
+    valid = xstate_bv & ~XSTATE_FP_SSE & ~X86_XSS_STATES;
     while ( valid )
     {
         u64 feature = valid & -valid;
@@ -276,7 +280,7 @@ void compress_xsave_states(struct vcpu *v, const void *src, unsigned int size)
      * possibly compacted offset.
      */
     dest = xstate;
-    valid = xstate_bv & ~XSTATE_FP_SSE;
+    valid = xstate_bv & ~XSTATE_FP_SSE & ~X86_XSS_STATES;
     while ( valid )
     {
         u64 feature = valid & -valid;
@@ -516,7 +520,7 @@ int xstate_alloc_save_area(struct vcpu *v)
          */
         size = XSTATE_AREA_MIN_SIZE;
     }
-    else if ( !is_idle_vcpu(v) || !cpu_has_xsavec )
+    else if ( !is_idle_vcpu(v) || (!cpu_has_xsavec && !cpu_has_xsaves) )
     {
         size = xsave_cntxt_size;
         BUG_ON(size < XSTATE_AREA_MIN_SIZE);
@@ -678,12 +682,9 @@ static void __init check_new_xstate(struct xcheck_state *s, uint64_t new)
            (new & X86_XSS_STATES)); /* User or supervisor, not both. */
 
     s->states |= new;
-    if ( new & X86_XCR0_STATES )
-    {
-        if ( !set_xcr0(s->states & X86_XCR0_STATES) )
-            BUG();
-    }
-    else
+    if ( !set_xcr0(s->states & X86_XCR0_STATES) )
+        BUG();
+    if ( cpu_has_xsaves )
         set_msr_xss(s->states & X86_XSS_STATES);
 
     /*
@@ -850,8 +851,8 @@ void xstate_init(struct cpuinfo_x86 *c)
     boolean_param("xsave", use_xsave);
 
     bool bsp = c == &boot_cpu_data;
-    u32 eax, ebx, ecx, edx;
-    u64 feature_mask;
+    uint32_t eax, ebx, ecx, edx;
+    uint64_t feature_mask, supervisor_feature_mask = 0;
 
     if ( bsp )
     {
@@ -874,7 +875,8 @@ void xstate_init(struct cpuinfo_x86 *c)
     }
 
     cpuid_count(XSTATE_CPUID, 0, &eax, &ebx, &ecx, &edx);
-    feature_mask = (((u64)edx << 32) | eax) & XCNTXT_MASK;
+    feature_mask = (((u64)edx << 32) | eax) &
+                   (XCNTXT_MASK & ~X86_XSS_STATES);
     BUG_ON(!valid_xcr0(feature_mask));
     BUG_ON(!(feature_mask & X86_XCR0_SSE));
 
@@ -892,25 +894,36 @@ void xstate_init(struct cpuinfo_x86 *c)
         BUG();
     if ( cpu_has_xsaves )
     {
+        cpuid_count(XSTATE_CPUID, 1, &eax, &ebx, &ecx, &edx);
+        supervisor_feature_mask = (((uint64_t)edx << 32) | ecx) & XCNTXT_MASK;
+
         this_cpu(xss) = ~0;
-        set_msr_xss(0);
+        set_msr_xss(supervisor_feature_mask);
     }
 
     if ( bsp )
     {
-        xfeature_mask = feature_mask;
+        xfeature_mask = feature_mask | supervisor_feature_mask;
         /*
          * xsave_cntxt_size is the max size required by enabled features.
          * We know FP/SSE and YMM about eax, and nothing about edx at present.
          */
         xsave_cntxt_size = cpuid_count_ebx(0xd, 0);
-        printk("xstate: size: %#x and states: %#"PRIx64"\n",
-               xsave_cntxt_size, xfeature_mask);
+        if ( cpu_has_xsaves )
+            xsave_cntxt_size = max(xsave_cntxt_size, cpuid_count_ebx(0xd, 1));
+        printk("xstate: size: %#x, states: %#"PRIx64
+               ", supervisor states: %#"PRIx64"\n",
+               xsave_cntxt_size, feature_mask, supervisor_feature_mask);
     }
     else
     {
-        BUG_ON(xfeature_mask != feature_mask);
-        BUG_ON(xsave_cntxt_size != cpuid_count_ebx(0xd, 0));
+        uint32_t ap_xsave_cntxt_size;
+
+        BUG_ON(xfeature_mask != (feature_mask | supervisor_feature_mask));
+        ap_xsave_cntxt_size = cpuid_count_ebx(0xd, 0);
+        if ( cpu_has(&current_cpu_data, X86_FEATURE_XSAVES) )
+            ap_xsave_cntxt_size = max(ap_xsave_cntxt_size, cpuid_count_ebx(0xd, 1));
+        BUG_ON(xsave_cntxt_size != ap_xsave_cntxt_size);
     }
 
     if ( setup_xstate_features(bsp) && bsp )
@@ -1072,6 +1085,30 @@ void xstate_set_init(uint64_t mask)
         BUG();
 }
 
+void *get_xstate_component_comp(struct xsave_struct *xstate,
+                                unsigned int size,
+                                uint64_t component)
+{
+    uint16_t comp_offsets[sizeof(xfeature_mask) * 8];
+    uint16_t offset;
+    unsigned int i = ilog2(component);
+
+    ASSERT(generic_hweightl(component) == 1);
+
+    if ( !(xstate->xsave_hdr.xcomp_bv & XSTATE_COMPACTION_ENABLED) ||
+         i >= xstate_features ||
+         xstate_sizes[i] == 0 ||
+         !(xstate->xsave_hdr.xcomp_bv & component) )
+        return NULL;
+
+    setup_xstate_comp(comp_offsets, xstate->xsave_hdr.xcomp_bv);
+    offset = comp_offsets[i];
+    if ( xstate_sizes[i] + offset > size )
+        return NULL;
+
+    return (void *)xstate + offset;
+}
+
 /*
  * Local variables:
  * mode: C
-- 
2.43.0



Ngoc Tu Dinh | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


From xen-devel-bounces@lists.xenproject.org Thu Jan 02 08:45:55 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 08:45:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863733.1275124 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTGpw-0005aD-Bs; Thu, 02 Jan 2025 08:45:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863733.1275124; Thu, 02 Jan 2025 08:45:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTGpw-0005ZF-4k; Thu, 02 Jan 2025 08:45:48 +0000
Received: by outflank-mailman (input) for mailman id 863733;
 Thu, 02 Jan 2025 08:45:46 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=u0qU=T2=bounce.vates.tech=bounce-md_30504962.67765235.v1-68aac7873e55466da24a0637d6e85abf@srs-se1.protection.inumbo.net>)
 id 1tTGpu-0004rS-A6
 for xen-devel@lists.xenproject.org; Thu, 02 Jan 2025 08:45:46 +0000
Received: from mail180-43.suw31.mandrillapp.com
 (mail180-43.suw31.mandrillapp.com [198.2.180.43])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f2f0b31b-c8e5-11ef-99a4-01e77a169b0f;
 Thu, 02 Jan 2025 09:45:42 +0100 (CET)
Received: from pmta11.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail180-43.suw31.mandrillapp.com (Mailchimp) with ESMTP id
 4YP0fF660tzLfHCqL
 for <xen-devel@lists.xenproject.org>; Thu,  2 Jan 2025 08:45:41 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 68aac7873e55466da24a0637d6e85abf; Thu, 02 Jan 2025 08:45:41 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f2f0b31b-c8e5-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1735807541; x=1736068041;
	bh=bzh0Fm9xRWi5sdSCui/eX3MkuuuaQvZQ4zYj+fK0gX8=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=uMkU/I3HMgS2qZGZSO21pzx6J2vDfpojCPFRvo48ZMp+qtHL366nMvfZiUiodET6M
	 219uHx3eq4dNDpR0/Xxe51wM9AJwPlbCIq6CpRFeyh4tS+Y4Xw4i91N9viKENyD2Fx
	 TRKHg4wtmFTv3Hybe5/l+1opTsgP4onGoAsm4TLjXymY8QuAEDr3Fn7K2bNRoLxT/u
	 skA4Ai2EpdZlizGVZsxAnGWK2ftbrQPxBQ49QVvDt/GE+0h+vc36Jyq5OixO+rUhJ5
	 BHyxyLUyQ8xwAL5HOFTidAdp+Dmpv89nyKVh6xEe8stYGbz1yF1Dp0p8xKEr4nfwQr
	 aJkiQvFK+PS8w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1735807541; x=1736068041; i=ngoc-tu.dinh@vates.tech;
	bh=bzh0Fm9xRWi5sdSCui/eX3MkuuuaQvZQ4zYj+fK0gX8=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=soK6Agw0aE8t92BfDTToFSRLwzXj7Bg2MKx/bNYyVtyUu8eODd49fpS9RqBYvbeaZ
	 8IOuZemgOsEXgYlI9P2oms/DzRhoMqU07bSK3Lxub4R4qk0DRplHCiS3lf1bA12738
	 6FyQGbvdOyXi3bDF/zSi+zQlm3mNZiEfxnaUzKeYeFXH30uvJjbK3flXIC1liS7cKX
	 zKIF1D6dtU90dK+KCxzy19BjYhv+1fiSPtUVtYAj2krjfo4DHLRzU7OTUuJCmXeDLv
	 ATOCqgetCGEMyWmw3Wyxk5PGI6AjP+JVk5xun0+CIdqormyoRzIq6SEl9YlPgz55BF
	 bj8b9S6flXZyQ==
From: "Tu Dinh" <ngoc-tu.dinh@vates.tech>
Subject: =?utf-8?Q?[RFC=20PATCH=20v2=2009/10]=20x86/vmx:=20Implement=20arch=20LBR?=
X-Mailer: git-send-email 2.43.0
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1735807540946
To: xen-devel@lists.xenproject.org
Cc: "Tu Dinh" <ngoc-tu.dinh@vates.tech>, "Anthony PERARD" <anthony.perard@vates.tech>, "Juergen Gross" <jgross@suse.com>, "Jan Beulich" <jbeulich@suse.com>, "Andrew Cooper" <andrew.cooper3@citrix.com>, "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>
Message-Id: <20250102084413.102-10-ngoc-tu.dinh@vates.tech>
In-Reply-To: <20250102084413.102-1-ngoc-tu.dinh@vates.tech>
References: <20250102084413.102-1-ngoc-tu.dinh@vates.tech>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.68aac7873e55466da24a0637d6e85abf?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250102:md
Date: Thu, 02 Jan 2025 08:45:41 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Use guest LBR_CTL in VMCS to limit LBR operation per guest.

Use MSR bitmap to disable interception of arch LBR MSRs. Reconfigure
bitmap on each valid LBR depth write.

Signed-off-by: Tu Dinh <ngoc-tu.dinh@vates.tech>
---
 xen/arch/x86/domain.c                   |   7 +
 xen/arch/x86/hvm/vmx/vmcs.c             |  11 +-
 xen/arch/x86/hvm/vmx/vmx.c              | 203 ++++++++++++++++++++++--
 xen/arch/x86/include/asm/hvm/vmx/vmcs.h |  11 ++
 xen/arch/x86/include/asm/msr.h          |   5 +
 xen/arch/x86/msr.c                      |  86 ++++++++++
 6 files changed, 307 insertions(+), 16 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 78a13e6812..8ed35cbbc8 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -2021,6 +2021,13 @@ static void __context_switch(void)
             if ( cpu_has_xsaves && is_hvm_vcpu(n) )
                 set_msr_xss(n->arch.msrs->xss.raw);
         }
+#ifdef CONFIG_HVM
+        /* XRSTORS LBR state behavior depends on MSR_LBR_DEPTH */
+        if ( using_vmx() &&
+             is_hvm_vcpu(n) &&
+             n->domain->arch.cpu_policy->feat.arch_lbr )
+            wrmsrl(MSR_LBR_DEPTH, n->arch.msrs->lbr_depth.raw);
+#endif
         vcpu_restore_fpu_nonlazy(n, false);
         nd->arch.ctxt_switch->to(n);
     }
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 147e998371..a16daad78a 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -203,6 +203,7 @@ static void __init vmx_display_features(void)
     P(cpu_has_vmx_bus_lock_detection, "Bus Lock Detection");
     P(cpu_has_vmx_notify_vm_exiting, "Notify VM Exit");
     P(cpu_has_vmx_virt_spec_ctrl, "Virtualize SPEC_CTRL");
+    P(cpu_has_vmx_guest_lbr_ctl, "Architectural LBR virtualization");
 #undef P
 
     if ( !printed )
@@ -448,7 +449,8 @@ static int vmx_init_vmcs_config(bool bsp)
 
     min = VM_EXIT_ACK_INTR_ON_EXIT;
     opt = (VM_EXIT_SAVE_GUEST_PAT | VM_EXIT_LOAD_HOST_PAT |
-           VM_EXIT_LOAD_HOST_EFER | VM_EXIT_CLEAR_BNDCFGS);
+           VM_EXIT_LOAD_HOST_EFER | VM_EXIT_CLEAR_BNDCFGS |
+           VM_EXIT_CLEAR_GUEST_LBR_CTL);
     min |= VM_EXIT_IA32E_MODE;
     _vmx_vmexit_control = adjust_vmx_controls(
         "VMExit Control", min, opt, MSR_IA32_VMX_EXIT_CTLS, &mismatch);
@@ -489,7 +491,7 @@ static int vmx_init_vmcs_config(bool bsp)
 
     min = 0;
     opt = (VM_ENTRY_LOAD_GUEST_PAT | VM_ENTRY_LOAD_GUEST_EFER |
-           VM_ENTRY_LOAD_BNDCFGS);
+           VM_ENTRY_LOAD_BNDCFGS | VM_ENTRY_LOAD_GUEST_LBR_CTL);
     _vmx_vmentry_control = adjust_vmx_controls(
         "VMEntry Control", min, opt, MSR_IA32_VMX_ENTRY_CTLS, &mismatch);
 
@@ -1329,6 +1331,9 @@ static int construct_vmcs(struct vcpu *v)
               | (paging_mode_hap(d) ? 0 : (1U << X86_EXC_PF))
               | (v->arch.fully_eager_fpu ? 0 : (1U << X86_EXC_NM));
 
+    if ( cpu_has_vmx_guest_lbr_ctl )
+        __vmwrite(GUEST_LBR_CTL, 0);
+
     if ( cpu_has_vmx_notify_vm_exiting )
         __vmwrite(NOTIFY_WINDOW, vm_notify_window);
 
@@ -2087,6 +2092,8 @@ void vmcs_dump_vcpu(struct vcpu *v)
            vmr32(GUEST_PREEMPTION_TIMER), vmr32(GUEST_SMBASE));
     printk("DebugCtl = 0x%016lx  DebugExceptions = 0x%016lx\n",
            vmr(GUEST_IA32_DEBUGCTL), vmr(GUEST_PENDING_DBG_EXCEPTIONS));
+    if ( vmentry_ctl & VM_ENTRY_LOAD_GUEST_LBR_CTL )
+        printk("LbrCtl = 0x%016lx\n", vmr(GUEST_LBR_CTL));
     if ( vmentry_ctl & (VM_ENTRY_LOAD_PERF_GLOBAL_CTRL | VM_ENTRY_LOAD_BNDCFGS) )
         printk("PerfGlobCtl = 0x%016lx  BndCfgS = 0x%016lx\n",
                vmr(GUEST_PERF_GLOBAL_CTRL), vmr(GUEST_BNDCFGS));
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 9f1e9d515f..c706f01d79 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -48,6 +48,7 @@
 #include <asm/monitor.h>
 #include <asm/prot-key.h>
 #include <asm/spec_ctrl.h>
+#include <asm/xstate.h>
 #include <public/arch-x86/cpuid.h>
 
 static bool __initdata opt_force_ept;
@@ -773,6 +774,67 @@ void vmx_update_exception_bitmap(struct vcpu *v)
         __vmwrite(EXCEPTION_BITMAP, bitmap);
 }
 
+static void cf_check vmx_set_lbr_depth(struct vcpu *v,
+                                       uint32_t depth)
+{
+    struct cpu_policy *cp = v->domain->arch.cpu_policy;
+    bool host_lip, guest_lip;
+    uint32_t i;
+
+    if ( !cp->feat.arch_lbr )
+        return;
+
+    ASSERT(depth != 0 &&
+           depth <= NUM_MSR_ARCH_LBR_FROM_TO &&
+           depth % 8 == 0);
+    ASSERT(cp->basic.lbr_1Ca.supported_depths & ((1u << (depth / 8)) - 1));
+
+    host_lip = current_cpu_has_lbr_lip;
+    guest_lip = !!cp->basic.lbr_1Ca.ip_contains_lip;
+
+    if ( v->arch.msrs->lbr_depth.raw == depth &&
+         v->arch.hvm.vmx.last_host_lip == host_lip )
+        return;
+
+    if ( host_lip != guest_lip )
+    {
+        for ( i = 0; i < depth; i++ )
+        {
+            vmx_set_msr_intercept(v, MSR_LBR_FROM_IP(i), VMX_MSR_RW);
+            vmx_set_msr_intercept(v, MSR_LBR_TO_IP(i), VMX_MSR_RW);
+        }
+        vmx_set_msr_intercept(v, MSR_IA32_LASTINTFROMIP, VMX_MSR_RW);
+        vmx_set_msr_intercept(v, MSR_IA32_LASTINTTOIP, VMX_MSR_RW);
+    }
+    else
+    {
+        for ( i = 0; i < depth; i++ )
+        {
+            vmx_clear_msr_intercept(v, MSR_LBR_FROM_IP(i), VMX_MSR_RW);
+            vmx_clear_msr_intercept(v, MSR_LBR_TO_IP(i), VMX_MSR_RW);
+        }
+        vmx_clear_msr_intercept(v, MSR_IA32_LASTINTFROMIP, VMX_MSR_RW);
+        vmx_clear_msr_intercept(v, MSR_IA32_LASTINTTOIP, VMX_MSR_RW);
+    }
+
+    /* MSR_{LBR,LER}_INFO don't need translating */
+    for ( i = 0; i < depth; i++ )
+        vmx_clear_msr_intercept(v, MSR_LBR_INFO(i), VMX_MSR_RW);
+    vmx_clear_msr_intercept(v, MSR_LER_INFO, VMX_MSR_RW);
+    /* MSRs beyond LBR_DEPTH always need #GP */
+    for ( i = depth; i < NUM_MSR_ARCH_LBR_FROM_TO; i++ )
+    {
+        vmx_set_msr_intercept(v, MSR_LBR_INFO(i), VMX_MSR_RW);
+        vmx_set_msr_intercept(v, MSR_LBR_FROM_IP(i), VMX_MSR_RW);
+        vmx_set_msr_intercept(v, MSR_LBR_TO_IP(i), VMX_MSR_RW);
+    }
+
+    __vmwrite(XSS_EXIT_BITMAP, host_lip == guest_lip ? 0 : X86_XSS_LBR);
+
+    v->arch.msrs->lbr_depth.raw = depth;
+    v->arch.hvm.vmx.last_host_lip = host_lip;
+}
+
 static void cf_check vmx_cpuid_policy_changed(struct vcpu *v)
 {
     const struct cpu_policy *cp = v->domain->arch.cpu_policy;
@@ -871,6 +933,16 @@ static void cf_check vmx_cpuid_policy_changed(struct vcpu *v)
     else
         vmx_set_msr_intercept(v, MSR_PKRS, VMX_MSR_RW);
 
+    if ( cp->feat.arch_lbr && v->arch.msrs->lbr_depth.raw == 0 )
+    {
+        uint32_t max_depth;
+
+        ASSERT(cp->basic.lbr_1Ca.supported_depths > 0);
+        max_depth = fls(cp->basic.lbr_1Ca.supported_depths) * 8;
+
+        vmx_set_lbr_depth(v, max_depth);
+    }
+
  out:
     vmx_vmcs_exit(v);
 
@@ -2635,6 +2707,7 @@ static uint64_t cf_check vmx_get_reg(struct vcpu *v, unsigned int reg)
 {
     const struct vcpu *curr = current;
     struct domain *d = v->domain;
+    const struct cpu_policy *cp = d->arch.cpu_policy;
     const struct vcpu_msrs *msrs = v->arch.msrs;
     uint64_t val = 0;
     int rc;
@@ -2679,6 +2752,48 @@ static uint64_t cf_check vmx_get_reg(struct vcpu *v, unsigned int reg)
         __vmread(GUEST_BNDCFGS, &val);
         break;
 
+    case MSR_LBR_CTL:
+        __vmread(GUEST_LBR_CTL, &val);
+        break;
+
+    case MSR_LBR_DEPTH:
+        val = v->arch.msrs->lbr_depth.raw;
+        break;
+
+    case MSR_LER_INFO:
+    case MSR_LBR_INFO(0)...MSR_LBR_INFO(NUM_MSR_ARCH_LBR_FROM_TO - 1):
+        if ( v != curr )
+        {
+            val = 0;
+            break;
+        }
+        rdmsrl(reg, val);
+        break;
+
+    case MSR_IA32_LASTINTFROMIP:
+    case MSR_IA32_LASTINTTOIP:
+    case MSR_LBR_FROM_IP(0)...MSR_LBR_FROM_IP(NUM_MSR_ARCH_LBR_FROM_TO - 1):
+    case MSR_LBR_TO_IP(0)...MSR_LBR_TO_IP(NUM_MSR_ARCH_LBR_FROM_TO - 1):
+    {
+        struct segment_register cs;
+        int mode_64bit;
+        uint64_t offset;
+
+        if ( v != curr )
+        {
+            val = 0;
+            break;
+        }
+
+        mode_64bit = vmx_guest_x86_mode(v) == X86_MODE_64BIT;
+        hvm_get_segment_register(v, x86_seg_cs, &cs);
+        offset = x86_get_lbr_cs_offset(cp, mode_64bit, &cs, true);
+
+        rdmsrl(reg, val);
+        val += offset;
+        break;
+    }
+
     default:
         printk(XENLOG_G_ERR "%s(%pv, 0x%08x) Bad register\n",
                __func__, v, reg);
@@ -2695,6 +2810,7 @@ static void cf_check vmx_set_reg(struct vcpu *v, unsigned int reg, uint64_t val)
     const struct vcpu *curr = current;
     struct vcpu_msrs *msrs = v->arch.msrs;
     struct domain *d = v->domain;
+    const struct cpu_policy *cp = d->arch.cpu_policy;
     int rc;
 
     /* Logic which doesn't require remote VMCS acquisition. */
@@ -2734,6 +2850,43 @@ static void cf_check vmx_set_reg(struct vcpu *v, unsigned int reg, uint64_t val)
         __vmwrite(GUEST_BNDCFGS, val);
         break;
 
+    case MSR_LBR_CTL:
+        __vmwrite(GUEST_LBR_CTL, val);
+        break;
+
+    case MSR_LBR_DEPTH:
+        if ( v == curr )
+            wrmsrl(MSR_LBR_DEPTH, val);
+        vmx_set_lbr_depth(v, val);
+        break;
+
+    case MSR_LER_INFO:
+    case MSR_LBR_INFO(0)...MSR_LBR_INFO(NUM_MSR_ARCH_LBR_FROM_TO - 1):
+        if ( v == curr )
+            wrmsrl(reg, val);
+        break;
+
+    case MSR_IA32_LASTINTFROMIP:
+    case MSR_IA32_LASTINTTOIP:
+    case MSR_LBR_FROM_IP(0)...MSR_LBR_FROM_IP(NUM_MSR_ARCH_LBR_FROM_TO - 1):
+    case MSR_LBR_TO_IP(0)...MSR_LBR_TO_IP(NUM_MSR_ARCH_LBR_FROM_TO - 1):
+    {
+        struct segment_register cs;
+        bool mode_64bit;
+        uint64_t offset;
+
+        if ( v != curr )
+            break;
+
+        mode_64bit = vmx_guest_x86_mode(v) == X86_MODE_64BIT;
+        hvm_get_segment_register(v, x86_seg_cs, &cs);
+        offset = x86_get_lbr_cs_offset(cp, mode_64bit, &cs, false);
+
+        val += offset;
+        wrmsrl(reg, val);
+        break;
+    }
+
     default:
         printk(XENLOG_G_ERR "%s(%pv, 0x%08x, 0x%016"PRIx64") Bad register\n",
                __func__, v, reg, val);
@@ -2805,6 +2958,7 @@ static struct hvm_function_table __initdata_cf_clobber vmx_function_table = {
     .vmtrace_set_option = vmtrace_set_option,
     .vmtrace_get_option = vmtrace_get_option,
     .vmtrace_reset = vmtrace_reset,
+    .set_lbr_depth        = vmx_set_lbr_depth,
 
     .get_reg = vmx_get_reg,
     .set_reg = vmx_set_reg,
@@ -3997,18 +4151,6 @@ static void vmx_idtv_reinject(unsigned long idtv_info)
     }
 }
 
-static void vmx_handle_xsaves(void)
-{
-    gdprintk(XENLOG_ERR, "xsaves should not cause vmexit\n");
-    domain_crash(current->domain);
-}
-
-static void vmx_handle_xrstors(void)
-{
-    gdprintk(XENLOG_ERR, "xrstors should not cause vmexit\n");
-    domain_crash(current->domain);
-}
-
 static void vmx_handle_descriptor_access(uint32_t exit_reason)
 {
     uint64_t instr_info;
@@ -4055,6 +4197,36 @@ static void undo_nmis_unblocked_by_iret(void)
               guest_info | VMX_INTR_SHADOW_NMI);
 }
 
+static void vmx_handle_xsaves_xrstors(bool saving)
+{
+    struct hvm_emulate_ctxt ctxt;
+    int rc;
+
+    if ( saving )
+        hvm_emulate_init_once(&ctxt, x86_insn_is_xsaves, guest_cpu_user_regs());
+    else
+        hvm_emulate_init_once(&ctxt, x86_insn_is_xrstors, guest_cpu_user_regs());
+
+    switch ( rc = hvm_emulate_one(&ctxt, VIO_no_completion) )
+    {
+    case X86EMUL_UNHANDLEABLE:
+        hvm_dump_emulation_state(XENLOG_G_WARNING, "XSAVES/XRSTORS", &ctxt, rc);
+        hvm_inject_hw_exception(X86_EXC_UD, 0);
+        return;
+
+    case X86EMUL_UNRECOGNIZED:
+        hvm_dump_emulation_state(XENLOG_G_WARNING, "XSAVES/XRSTORS", &ctxt, rc);
+        hvm_inject_hw_exception(X86_EXC_UD, X86_EVENT_NO_EC);
+        break;
+
+    case X86EMUL_EXCEPTION:
+        hvm_inject_event(&ctxt.ctxt.event);
+        break;
+    }
+
+    hvm_emulate_writeback(&ctxt);
+}
+
 void asmlinkage vmx_vmexit_handler(struct cpu_user_regs *regs)
 {
     unsigned long exit_qualification, exit_reason, idtv_info, intr_info = 0;
@@ -4695,11 +4867,11 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_regs *regs)
         break;
 
     case EXIT_REASON_XSAVES:
-        vmx_handle_xsaves();
+        vmx_handle_xsaves_xrstors(true);
         break;
 
     case EXIT_REASON_XRSTORS:
-        vmx_handle_xrstors();
+        vmx_handle_xsaves_xrstors(false);
         break;
 
     case EXIT_REASON_ACCESS_GDTR_OR_IDTR:
@@ -4818,6 +4990,9 @@ bool asmlinkage vmx_vmenter_helper(const struct cpu_user_regs *regs)
     if ( curr->domain->arch.hvm.pi_ops.vcpu_block )
         vmx_pi_do_resume(curr);
 
+    /* Update the XSS exiting bitmap in case of vCPU migration. */
+    vmx_set_lbr_depth(curr, curr->arch.msrs->lbr_depth.raw);
+
     if ( !cpu_has_vmx_vpid )
         goto out;
     if ( nestedhvm_vcpu_in_guestmode(curr) )
diff --git a/xen/arch/x86/include/asm/hvm/vmx/vmcs.h b/xen/arch/x86/include/asm/hvm/vmx/vmcs.h
index 939b87eb50..da7e0b4103 100644
--- a/xen/arch/x86/include/asm/hvm/vmx/vmcs.h
+++ b/xen/arch/x86/include/asm/hvm/vmx/vmcs.h
@@ -154,6 +154,9 @@ struct vmx_vcpu {
     /* Are we emulating rather than VMENTERing? */
     uint8_t              vmx_emulate;
 
+    /* If the vCPU last ran on a host CPU with XEN_X86_FEATURE_LBR_LIP */
+    bool                 last_host_lip;
+    /* For legacy LBR only */
     uint8_t              lbr_flags;
 
     /* Bitmask of segments that we can't safely use in virtual 8086 mode */
@@ -229,6 +232,7 @@ extern u32 vmx_pin_based_exec_control;
 #define VM_EXIT_LOAD_HOST_EFER          0x00200000
 #define VM_EXIT_SAVE_PREEMPT_TIMER      0x00400000
 #define VM_EXIT_CLEAR_BNDCFGS           0x00800000
+#define VM_EXIT_CLEAR_GUEST_LBR_CTL     0x04000000
 extern u32 vmx_vmexit_control;
 
 #define VM_ENTRY_IA32E_MODE             0x00000200
@@ -238,6 +242,7 @@ extern u32 vmx_vmexit_control;
 #define VM_ENTRY_LOAD_GUEST_PAT         0x00004000
 #define VM_ENTRY_LOAD_GUEST_EFER        0x00008000
 #define VM_ENTRY_LOAD_BNDCFGS           0x00010000
+#define VM_ENTRY_LOAD_GUEST_LBR_CTL     0x00200000
 extern u32 vmx_vmentry_control;
 
 #define SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES 0x00000001U
@@ -391,6 +396,10 @@ extern u64 vmx_ept_vpid_cap;
 #define cpu_has_vmx_notify_vm_exiting \
     (IS_ENABLED(CONFIG_INTEL_VMX) && \
      vmx_secondary_exec_control & SECONDARY_EXEC_NOTIFY_VM_EXITING)
+#define cpu_has_vmx_guest_lbr_ctl \
+    (IS_ENABLED(CONFIG_INTEL_VMX) && \
+     (vmx_vmexit_control & VM_EXIT_CLEAR_GUEST_LBR_CTL) && \
+     (vmx_vmentry_control & VM_ENTRY_LOAD_GUEST_LBR_CTL))
 
 #define VMCS_RID_TYPE_MASK              0x80000000U
 
@@ -480,6 +489,8 @@ enum vmcs_field {
     GUEST_PDPTE0                    = 0x0000280a,
 #define GUEST_PDPTE(n) (GUEST_PDPTE0 + (n) * 2) /* n = 0...3 */
     GUEST_BNDCFGS                   = 0x00002812,
+    GUEST_RTIT_CTL                  = 0x00002814,
+    GUEST_LBR_CTL                   = 0x00002816,
     HOST_PAT                        = 0x00002c00,
     HOST_EFER                       = 0x00002c02,
     HOST_PERF_GLOBAL_CTRL           = 0x00002c04,
diff --git a/xen/arch/x86/include/asm/msr.h b/xen/arch/x86/include/asm/msr.h
index 7b00a4db5d..d7578d8cab 100644
--- a/xen/arch/x86/include/asm/msr.h
+++ b/xen/arch/x86/include/asm/msr.h
@@ -389,6 +389,11 @@ struct vcpu_msrs
         uint64_t raw;
     } xss;
 
+    /* 0x000014cf - MSR_LBR_DEPTH */
+    struct {
+        uint64_t raw;
+    } lbr_depth;
+
     /*
      * 0xc0000103 - MSR_TSC_AUX
      *
diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
index 68a419ac8e..6c72728f81 100644
--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -193,6 +193,38 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val)
             goto gp_fault;
         goto get_reg;
 
+    case MSR_LBR_CTL:
+    case MSR_LBR_DEPTH:
+    case MSR_LER_INFO:
+        if ( !cp->feat.arch_lbr )
+            goto gp_fault;
+
+        goto get_reg;
+
+    case MSR_LBR_INFO(0)...MSR_LBR_INFO(NUM_MSR_ARCH_LBR_FROM_TO - 1):
+        if ( !cp->feat.arch_lbr )
+            goto gp_fault;
+
+        if ( msr - MSR_LBR_INFO(0) >= msrs->lbr_depth.raw )
+            goto gp_fault;
+
+        goto get_reg;
+
+    case MSR_IA32_LASTINTFROMIP:
+    case MSR_IA32_LASTINTTOIP:
+    case MSR_LBR_FROM_IP(0)...MSR_LBR_FROM_IP(NUM_MSR_ARCH_LBR_FROM_TO - 1):
+    case MSR_LBR_TO_IP(0)...MSR_LBR_TO_IP(NUM_MSR_ARCH_LBR_FROM_TO - 1):
+        if ( !cp->feat.arch_lbr )
+            goto gp_fault;
+
+        if ( (msr >= MSR_LBR_FROM_IP(msrs->lbr_depth.raw) &&
+              msr <= MSR_LBR_FROM_IP(NUM_MSR_ARCH_LBR_FROM_TO - 1)) ||
+             (msr >= MSR_LBR_TO_IP(msrs->lbr_depth.raw) &&
+              msr <= MSR_LBR_TO_IP(NUM_MSR_ARCH_LBR_FROM_TO - 1)) )
+            goto gp_fault;
+
+        goto get_reg;
+
     case MSR_IA32_XSS:
         if ( !cp->xstate.xsaves )
             goto gp_fault;
@@ -516,6 +548,60 @@ int guest_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val)
         }
 
         goto set_reg;
+
+    case MSR_LBR_CTL:
+        if ( !cp->feat.arch_lbr )
+            goto gp_fault;
+
+        if ( val & ~LBR_CTL_VALID )
+            goto gp_fault;
+
+        goto set_reg;
+
+    case MSR_LBR_DEPTH:
+        if ( !cp->feat.arch_lbr )
+            goto gp_fault;
+
+        if ( val == 0 ||
+             val > NUM_MSR_ARCH_LBR_FROM_TO ||
+             val % 8 != 0 )
+            goto gp_fault;
+
+        if ( !(cp->basic.lbr_1Ca.supported_depths &
+               ((1u << (val / 8)) - 1)) )
+            goto gp_fault;
+
+        goto set_reg;
+
+    case MSR_LER_INFO:
+        if ( !cp->feat.arch_lbr )
+            goto gp_fault;
+
+        goto set_reg;
+
+    case MSR_LBR_INFO(0)...MSR_LBR_INFO(NUM_MSR_ARCH_LBR_FROM_TO - 1):
+        if ( !cp->feat.arch_lbr )
+            goto gp_fault;
+
+        if ( msr - MSR_LBR_INFO(0) >= v->arch.msrs->lbr_depth.raw )
+            goto gp_fault;
+
+        goto set_reg;
+
+    case MSR_IA32_LASTINTFROMIP:
+    case MSR_IA32_LASTINTTOIP:
+    case MSR_LBR_FROM_IP(0)...MSR_LBR_FROM_IP(NUM_MSR_ARCH_LBR_FROM_TO - 1):
+    case MSR_LBR_TO_IP(0)...MSR_LBR_TO_IP(NUM_MSR_ARCH_LBR_FROM_TO - 1):
+        if ( !cp->feat.arch_lbr )
+            goto gp_fault;
+
+        if ( (msr >= MSR_LBR_FROM_IP(v->arch.msrs->lbr_depth.raw) &&
+              msr <= MSR_LBR_FROM_IP(NUM_MSR_ARCH_LBR_FROM_TO - 1)) ||
+             (msr >= MSR_LBR_TO_IP(v->arch.msrs->lbr_depth.raw) &&
+              msr <= MSR_LBR_TO_IP(NUM_MSR_ARCH_LBR_FROM_TO - 1)) )
+            goto gp_fault;
+
+        goto set_reg;
 #endif /* CONFIG_HVM */
 
     case MSR_IA32_XSS:
-- 
2.43.0



Ngoc Tu Dinh | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


From xen-devel-bounces@lists.xenproject.org Thu Jan 02 08:45:55 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 08:45:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863732.1275120 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTGpw-0005XR-3R; Thu, 02 Jan 2025 08:45:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863732.1275120; Thu, 02 Jan 2025 08:45:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTGpv-0005WT-Sr; Thu, 02 Jan 2025 08:45:47 +0000
Received: by outflank-mailman (input) for mailman id 863732;
 Thu, 02 Jan 2025 08:45:46 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=XVIC=T2=bounce.vates.tech=bounce-md_30504962.67765234.v1-8f8814d4b30a41adb33ecc6a9e833b61@srs-se1.protection.inumbo.net>)
 id 1tTGpu-0004rS-39
 for xen-devel@lists.xenproject.org; Thu, 02 Jan 2025 08:45:46 +0000
Received: from mail180-50.suw31.mandrillapp.com
 (mail180-50.suw31.mandrillapp.com [198.2.180.50])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f31ba6ce-c8e5-11ef-99a4-01e77a169b0f;
 Thu, 02 Jan 2025 09:45:43 +0100 (CET)
Received: from pmta11.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail180-50.suw31.mandrillapp.com (Mailchimp) with ESMTP id
 4YP0fD21KZzCfD7Mc
 for <xen-devel@lists.xenproject.org>; Thu,  2 Jan 2025 08:45:40 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 8f8814d4b30a41adb33ecc6a9e833b61; Thu, 02 Jan 2025 08:45:40 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f31ba6ce-c8e5-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1735807540; x=1736068040;
	bh=pAHxWdtF5F+VmVe6AG5QRFQ7htoBqzkaXnBayvRsH38=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=sCGaJGcFBppRgs03cEtlCOCLOHlzZKqwDj4/K/CHee3G4z7HS3zIxXzCNS6U4wvmL
	 fH2QJw5ie5V0aiFoRNWQ0NgWWg/CqYT/kdcoKtM24AUHkXR/hSq6AHTXBDBMLD6P23
	 FdTgDZQce6mZybN3ZUWUqlgLxjiOMkyAtTi6D+YU8pXo/F3AxLUBbXBPnVRdCEBfDK
	 5QQJJqHLCYUz1FRrqnEOgKEts5s/n94/cBn42guFOJ8Us6kRTiGiyLTUBO0udj2+AK
	 pIhcMq3GeqyLKuFdD7cAmtBO/YeCx94iMO0wRekz4Qb1/4/oINWOieNoUfdhyU0bs5
	 e5ind8mh0o73g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1735807540; x=1736068040; i=ngoc-tu.dinh@vates.tech;
	bh=pAHxWdtF5F+VmVe6AG5QRFQ7htoBqzkaXnBayvRsH38=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=wKVy2yAvNOjQbLmYOqN5D9dTy5JW3Hcmw4706h6l5wzpo78PK4184mbr2qyVcNWr0
	 0DahWdqVMf+l8fHJtJ/+a8chQgLF+DksU0fbZBvMYnbobPd/flZMa6vS1dyLbXf8rU
	 i68vgWz10wVPucpBPDbimnP68jzdimdurL8oeU7OmalPubBI7sviN2VIySQZZ6uZz1
	 ebU0Cci3u5Qp8p2hHs7Wy5eHBJZbkIJ60pUE5KuE7IdI3nEMYDzw9xWZKqwysNhlfC
	 y72QZBp1h7qhFYxZX6nS5EuIfQl8Yc9RsziZRgRHbnYESgbB5ye58zARaQMA8ik2vY
	 xvZuaZOpQPByg==
From: "Tu Dinh" <ngoc-tu.dinh@vates.tech>
Subject: =?utf-8?Q?[RFC=20PATCH=20v2=2003/10]=20tools:=20Add=20arch=20LBR=20feature=20bits?=
X-Mailer: git-send-email 2.43.0
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1735807539448
To: xen-devel@lists.xenproject.org
Cc: "Tu Dinh" <ngoc-tu.dinh@vates.tech>, "Anthony PERARD" <anthony.perard@vates.tech>, "Juergen Gross" <jgross@suse.com>, "Jan Beulich" <jbeulich@suse.com>, "Andrew Cooper" <andrew.cooper3@citrix.com>, "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>
Message-Id: <20250102084413.102-4-ngoc-tu.dinh@vates.tech>
In-Reply-To: <20250102084413.102-1-ngoc-tu.dinh@vates.tech>
References: <20250102084413.102-1-ngoc-tu.dinh@vates.tech>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.8f8814d4b30a41adb33ecc6a9e833b61?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250102:md
Date: Thu, 02 Jan 2025 08:45:40 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Signed-off-by: Tu Dinh <ngoc-tu.dinh@vates.tech>
---
 tools/libs/light/libxl_cpuid.c | 3 +++
 tools/misc/xen-cpuid.c         | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/tools/libs/light/libxl_cpuid.c b/tools/libs/light/libxl_cpuid.c
index 063fe86eb7..05be36f258 100644
--- a/tools/libs/light/libxl_cpuid.c
+++ b/tools/libs/light/libxl_cpuid.c
@@ -342,6 +342,9 @@ int libxl_cpuid_parse_config(libxl_cpuid_policy_list *policy, const char* str)
         CPUID_ENTRY(0x00000007,  1, CPUID_REG_EDX),
         MSR_ENTRY(0x10a, CPUID_REG_EAX),
         MSR_ENTRY(0x10a, CPUID_REG_EDX),
+        CPUID_ENTRY(0x0000001C, NA, CPUID_REG_EAX),
+        CPUID_ENTRY(0x0000001C, NA, CPUID_REG_EBX),
+        CPUID_ENTRY(0x0000001C, NA, CPUID_REG_ECX),
 #undef MSR_ENTRY
 #undef CPUID_ENTRY
     };
diff --git a/tools/misc/xen-cpuid.c b/tools/misc/xen-cpuid.c
index 4c4593528d..4f0fb0a6ea 100644
--- a/tools/misc/xen-cpuid.c
+++ b/tools/misc/xen-cpuid.c
@@ -37,6 +37,9 @@ static const struct {
     { "CPUID 0x00000007:1.edx",     "7d1" },
     { "MSR_ARCH_CAPS.lo",         "m10Al" },
     { "MSR_ARCH_CAPS.hi",         "m10Ah" },
+    { "CPUID 0x0000001c.eax",       "1Ca" },
+    { "CPUID 0x0000001c.ebx",       "1Cb" },
+    { "CPUID 0x0000001c.ecx",       "1Cc" },
 };
 
 #define COL_ALIGN "24"
-- 
2.43.0



Ngoc Tu Dinh | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


From xen-devel-bounces@lists.xenproject.org Thu Jan 02 08:45:55 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 08:45:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863734.1275130 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTGpw-0005eB-Nb; Thu, 02 Jan 2025 08:45:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863734.1275130; Thu, 02 Jan 2025 08:45:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTGpw-0005c9-Fr; Thu, 02 Jan 2025 08:45:48 +0000
Received: by outflank-mailman (input) for mailman id 863734;
 Thu, 02 Jan 2025 08:45:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=pG5F=T2=bounce.vates.tech=bounce-md_30504962.67765234.v1-943f3a70b64046b588551a553066481c@srs-se1.protection.inumbo.net>)
 id 1tTGpu-0004rS-TN
 for xen-devel@lists.xenproject.org; Thu, 02 Jan 2025 08:45:46 +0000
Received: from mail180-50.suw31.mandrillapp.com
 (mail180-50.suw31.mandrillapp.com [198.2.180.50])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f31ee457-c8e5-11ef-99a4-01e77a169b0f;
 Thu, 02 Jan 2025 09:45:43 +0100 (CET)
Received: from pmta11.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail180-50.suw31.mandrillapp.com (Mailchimp) with ESMTP id
 4YP0fD0pbvzCf9NcD
 for <xen-devel@lists.xenproject.org>; Thu,  2 Jan 2025 08:45:40 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 943f3a70b64046b588551a553066481c; Thu, 02 Jan 2025 08:45:40 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f31ee457-c8e5-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1735807540; x=1736068040;
	bh=dELO6CDglzR9hmFa5QjoLHtaiu13YDfJwfi0OKMMoQA=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=oEwTlY8uDgrvRWkS0Z9vdf4fv80hy5wYUCl1bQAtxZCXy+a1QHf/+Vw7ewex8sn5K
	 eUK4EyMLCAQH1cjCUXtH0wJGSGshlpGLnLY57S9VlGn6b981Hvj+1ygavAvbAs8tKm
	 TZgAXisAojhQk4K12Lnumis/aZ1DVZTnfa/5ZH7H7VfqLD+hTQMZI6dFIVDAnQwgwv
	 eQ9CokXO2brU/+Z9Nf5T6X/SBqElPw+EyFw7MAlCbiOeiI5+u67nlQU2lxXg5GD+/u
	 yiI0k2qrpnu44FvhZUsmGJNv/6T/sNQRWSBJ8J6oNrliD6oqnrhFzxtHhzan62Ilys
	 zmaABvDOSWDVw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1735807540; x=1736068040; i=ngoc-tu.dinh@vates.tech;
	bh=dELO6CDglzR9hmFa5QjoLHtaiu13YDfJwfi0OKMMoQA=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=iGqymsuQXVhCzxCuEXFwK58EpGs985GZ3J9HGbTPgDBnKcVcrAO8BnTT+G50b4VpG
	 sBlw1IVDxfuwXMLzfVGCyMPFqvBl5osJzNzX+cA0nS6xt4e2Q2lrJ6vT/GwQyhIyHC
	 62Iax0x43PeL/aG8sCh5EsSV2ygK5lCPMQx3N5j5wn+0qQu0xp6oPgnCtjiIFNitDV
	 z3YQEsZQl0jKlLJdrL2AlvNwCOtk5RtQIixkoF828XmGwi1BCmAtNjPmzfvFs91CND
	 vW3e1HKYEEHaJYvdGIH+XRXIeDCjnQTVtQLJAgzXjgaXqBXgDEccYclf9mSeqD8iHG
	 kHJfqoEnTTFbw==
From: "Tu Dinh" <ngoc-tu.dinh@vates.tech>
Subject: =?utf-8?Q?[RFC=20PATCH=20v2=2002/10]=20x86:=20Define=20arch=20LBR=20feature=20bits?=
X-Mailer: git-send-email 2.43.0
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1735807539234
To: xen-devel@lists.xenproject.org
Cc: "Tu Dinh" <ngoc-tu.dinh@vates.tech>, "Anthony PERARD" <anthony.perard@vates.tech>, "Juergen Gross" <jgross@suse.com>, "Jan Beulich" <jbeulich@suse.com>, "Andrew Cooper" <andrew.cooper3@citrix.com>, "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>
Message-Id: <20250102084413.102-3-ngoc-tu.dinh@vates.tech>
In-Reply-To: <20250102084413.102-1-ngoc-tu.dinh@vates.tech>
References: <20250102084413.102-1-ngoc-tu.dinh@vates.tech>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.943f3a70b64046b588551a553066481c?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250102:md
Date: Thu, 02 Jan 2025 08:45:40 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Add three featureset words corresponding to the 3 CPUID words in leaf
0x1c.

Intel SDM states that CPUID may indicate a LBR depth of up to 64.
However, since XSAVE LBR state only goes up to 32 LBRs, don't expose the
other CPUID depth bits for now.

Signed-off-by: Tu Dinh <ngoc-tu.dinh@vates.tech>
---
 xen/arch/x86/include/asm/cpufeature.h       |  5 ++
 xen/include/public/arch-x86/cpufeatureset.h | 28 ++++++++++-
 xen/include/xen/lib/x86/cpu-policy.h        | 51 ++++++++++++++++++++-
 xen/lib/x86/cpuid.c                         |  6 +++
 4 files changed, 88 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/include/asm/cpufeature.h b/xen/arch/x86/include/asm/cpufeature.h
index 3a06b6f297..4323ffb8cb 100644
--- a/xen/arch/x86/include/asm/cpufeature.h
+++ b/xen/arch/x86/include/asm/cpufeature.h
@@ -219,6 +219,11 @@ static inline bool boot_cpu_has(unsigned int feat)
 #define cpu_has_rfds_no         boot_cpu_has(X86_FEATURE_RFDS_NO)
 #define cpu_has_rfds_clear      boot_cpu_has(X86_FEATURE_RFDS_CLEAR)
 
+/* CPUID level 0x0000001c.eax */
+
+#define current_cpu_has_lbr_lip cpu_has(&current_cpu_data, \
+                                        X86_FEATURE_LBR_LIP);
+
 /* Synthesized. */
 #define cpu_has_arch_perfmon    boot_cpu_has(X86_FEATURE_ARCH_PERFMON)
 #define cpu_has_cpuid_faulting  boot_cpu_has(X86_FEATURE_CPUID_FAULTING)
diff --git a/xen/include/public/arch-x86/cpufeatureset.h b/xen/include/public/arch-x86/cpufeatureset.h
index 8fa3fb711a..86d3e61438 100644
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -284,7 +284,7 @@ XEN_CPUFEATURE(SERIALIZE,     9*32+14) /*A  SERIALIZE insn */
 XEN_CPUFEATURE(HYBRID,        9*32+15) /*   Heterogeneous platform */
 XEN_CPUFEATURE(TSXLDTRK,      9*32+16) /*a  TSX load tracking suspend/resume insns */
 XEN_CPUFEATURE(PCONFIG,       9*32+18) /*   PCONFIG instruction */
-XEN_CPUFEATURE(ARCH_LBR,      9*32+19) /*   Architectural Last Branch Record */
+XEN_CPUFEATURE(ARCH_LBR,      9*32+19) /*s  Architectural Last Branch Record */
 XEN_CPUFEATURE(CET_IBT,       9*32+20) /*   CET - Indirect Branch Tracking */
 XEN_CPUFEATURE(AMX_BF16,      9*32+22) /*   AMX BFloat16 instruction */
 XEN_CPUFEATURE(AVX512_FP16,   9*32+23) /*A  AVX512 FP16 instructions */
@@ -379,6 +379,32 @@ XEN_CPUFEATURE(RFDS_CLEAR,         16*32+28) /*!A| Register File(s) cleared by V
 
 /* Intel-defined CPU features, MSR_ARCH_CAPS 0x10a.edx, word 17 */
 
+/* Intel-defined CPU features, CPUID level 0x0000001c.eax, word 18 */
+XEN_CPUFEATURE(LBR_DEPTH_8,        18*32+ 0) /*s  Depth 8 */
+XEN_CPUFEATURE(LBR_DEPTH_16,       18*32+ 1) /*s  Depth 16 */
+XEN_CPUFEATURE(LBR_DEPTH_24,       18*32+ 2) /*s  Depth 24 */
+XEN_CPUFEATURE(LBR_DEPTH_32,       18*32+ 3) /*s  Depth 32 */
+XEN_CPUFEATURE(LBR_DEPTH_40,       18*32+ 4) /*   Depth 40 */
+XEN_CPUFEATURE(LBR_DEPTH_48,       18*32+ 5) /*   Depth 48 */
+XEN_CPUFEATURE(LBR_DEPTH_56,       18*32+ 6) /*   Depth 56 */
+XEN_CPUFEATURE(LBR_DEPTH_64,       18*32+ 7) /*   Depth 64 */
+XEN_CPUFEATURE(LBR_DCST_RST,       18*32+30) /*s  Deep C-state reset */
+XEN_CPUFEATURE(LBR_LIP,            18*32+31) /*!  IP is linear IP */
+
+/* Intel-defined CPU features, CPUID level 0x0000001c.ebx, word 19 */
+XEN_CPUFEATURE(LBR_CPL_FILTER,     19*32+ 0) /*s  CPL filtering */
+XEN_CPUFEATURE(LBR_BR_FILTER,      19*32+ 1) /*s  Branch filtering */
+XEN_CPUFEATURE(LBR_CALL_STACK,     19*32+ 2) /*s  Call stack mode */
+
+/* Intel-defined CPU features, CPUID level 0x0000001c.ecx, word 20 */
+XEN_CPUFEATURE(LBR_MISPRED,        20*32+ 0) /*s  Mispredict mode */
+XEN_CPUFEATURE(LBR_TIMED,          20*32+ 1) /*s  Timed mode */
+XEN_CPUFEATURE(LBR_BR_TYPE,        20*32+ 2) /*s  Branch type */
+XEN_CPUFEATURE(LBR_EVENT_LOG_0,    20*32+16) /*s  Event logging for counter 0 */
+XEN_CPUFEATURE(LBR_EVENT_LOG_1,    20*32+17) /*s  Event logging for counter 1 */
+XEN_CPUFEATURE(LBR_EVENT_LOG_2,    20*32+18) /*s  Event logging for counter 2 */
+XEN_CPUFEATURE(LBR_EVENT_LOG_3,    20*32+19) /*s  Event logging for counter 3 */
+
 #endif /* XEN_CPUFEATURE */
 
 /* Clean up from a default include.  Close the enum (for C). */
diff --git a/xen/include/xen/lib/x86/cpu-policy.h b/xen/include/xen/lib/x86/cpu-policy.h
index f43e1a3b21..f3b331f36c 100644
--- a/xen/include/xen/lib/x86/cpu-policy.h
+++ b/xen/include/xen/lib/x86/cpu-policy.h
@@ -22,6 +22,9 @@
 #define FEATURESET_7d1       15 /* 0x00000007:1.edx    */
 #define FEATURESET_m10Al     16 /* 0x0000010a.eax      */
 #define FEATURESET_m10Ah     17 /* 0x0000010a.edx      */
+#define FEATURESET_1Ca       18 /* 0x0000001c.eax      */
+#define FEATURESET_1Cb       19 /* 0x0000001c.ebx      */
+#define FEATURESET_1Cc       20 /* 0x0000001c.ecx      */
 
 struct cpuid_leaf
 {
@@ -85,7 +88,7 @@ unsigned int x86_cpuid_lookup_vendor(uint32_t ebx, uint32_t ecx, uint32_t edx);
  */
 const char *x86_cpuid_vendor_to_str(unsigned int vendor);
 
-#define CPUID_GUEST_NR_BASIC      (0xdu + 1)
+#define CPUID_GUEST_NR_BASIC      (0x1cu + 1)
 #define CPUID_GUEST_NR_CACHE      (5u + 1)
 #define CPUID_GUEST_NR_FEAT       (2u + 1)
 #define CPUID_GUEST_NR_TOPO       (1u + 1)
@@ -158,6 +161,52 @@ struct cpu_policy
             uint64_t :64, :64; /* Leaf 0xb - Topology. */
             uint64_t :64, :64; /* Leaf 0xc - rsvd */
             uint64_t :64, :64; /* Leaf 0xd - XSTATE. */
+
+            uint64_t :64, :64; /* Leaf 0xe - rsvd */
+            uint64_t :64, :64; /* Leaf 0xf - rsvd */
+            uint64_t :64, :64; /* Leaf 0x10 - rsvd */
+            uint64_t :64, :64; /* Leaf 0x11 - rsvd */
+            uint64_t :64, :64; /* Leaf 0x12 - rsvd */
+            uint64_t :64, :64; /* Leaf 0x13 - rsvd */
+            uint64_t :64, :64; /* Leaf 0x14 - rsvd */
+            uint64_t :64, :64; /* Leaf 0x15 - rsvd */
+            uint64_t :64, :64; /* Leaf 0x16 - rsvd */
+            uint64_t :64, :64; /* Leaf 0x17 - rsvd */
+            uint64_t :64, :64; /* Leaf 0x18 - rsvd */
+            uint64_t :64, :64; /* Leaf 0x19 - rsvd */
+            uint64_t :64, :64; /* Leaf 0x1a - rsvd */
+            uint64_t :64, :64; /* Leaf 0x1b - rsvd */
+
+            union {
+                uint32_t _1Ca;
+                struct {
+                    uint32_t supported_depths:8;
+                    uint32_t :22;
+                    uint32_t deep_cstate_reset:1;
+                    uint32_t ip_contains_lip:1;
+                } lbr_1Ca;
+            };
+            union {
+                uint32_t _1Cb;
+                struct {
+                    uint32_t cpl_filter:1;
+                    uint32_t br_filter:1;
+                    uint32_t call_stack:1;
+                } lbr_1Cb;
+            };
+            union {
+                uint32_t _1Cc;
+                struct {
+                    uint32_t mispred:1;
+                    uint32_t timed:1;
+                    uint32_t br_type:1;
+                    uint32_t :13;
+                    uint32_t event_log_0:1;
+                    uint32_t event_log_1:1;
+                    uint32_t event_log_2:1;
+                    uint32_t event_log_3:1;
+                } lbr_1Cc;
+            };
         };
     } basic;
 
diff --git a/xen/lib/x86/cpuid.c b/xen/lib/x86/cpuid.c
index eb7698dc73..4d19349b17 100644
--- a/xen/lib/x86/cpuid.c
+++ b/xen/lib/x86/cpuid.c
@@ -81,6 +81,9 @@ void x86_cpu_policy_to_featureset(
     fs[FEATURESET_7d1]       = p->feat._7d1;
     fs[FEATURESET_m10Al]     = p->arch_caps.lo;
     fs[FEATURESET_m10Ah]     = p->arch_caps.hi;
+    fs[FEATURESET_1Ca]       = p->basic._1Ca;
+    fs[FEATURESET_1Cb]       = p->basic._1Cb;
+    fs[FEATURESET_1Cc]       = p->basic._1Cc;
 }
 
 void x86_cpu_featureset_to_policy(
@@ -104,6 +107,9 @@ void x86_cpu_featureset_to_policy(
     p->feat._7d1             = fs[FEATURESET_7d1];
     p->arch_caps.lo          = fs[FEATURESET_m10Al];
     p->arch_caps.hi          = fs[FEATURESET_m10Ah];
+    p->basic._1Ca            = fs[FEATURESET_1Ca];
+    p->basic._1Cb            = fs[FEATURESET_1Cb];
+    p->basic._1Cc            = fs[FEATURESET_1Cc];
 }
 
 void x86_cpu_policy_recalc_synth(struct cpu_policy *p)
-- 
2.43.0



Ngoc Tu Dinh | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


From xen-devel-bounces@lists.xenproject.org Thu Jan 02 08:45:55 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 08:45:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863736.1275144 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTGpx-0005yz-PQ; Thu, 02 Jan 2025 08:45:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863736.1275144; Thu, 02 Jan 2025 08:45:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTGpx-0005wG-Gl; Thu, 02 Jan 2025 08:45:49 +0000
Received: by outflank-mailman (input) for mailman id 863736;
 Thu, 02 Jan 2025 08:45: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
 <SRS0=M3RT=T2=bounce.vates.tech=bounce-md_30504962.67765234.v1-1b49e4c8739a434284ff6632279899b6@srs-se1.protection.inumbo.net>)
 id 1tTGpw-0004rS-U2
 for xen-devel@lists.xenproject.org; Thu, 02 Jan 2025 08:45:48 +0000
Received: from mail180-50.suw31.mandrillapp.com
 (mail180-50.suw31.mandrillapp.com [198.2.180.50])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f4b2d03b-c8e5-11ef-99a4-01e77a169b0f;
 Thu, 02 Jan 2025 09:45:45 +0100 (CET)
Received: from pmta11.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail180-50.suw31.mandrillapp.com (Mailchimp) with ESMTP id
 4YP0fD4yH2zCf9LfB
 for <xen-devel@lists.xenproject.org>; Thu,  2 Jan 2025 08:45:40 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 1b49e4c8739a434284ff6632279899b6; Thu, 02 Jan 2025 08:45:40 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f4b2d03b-c8e5-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1735807540; x=1736068040;
	bh=K9neGUeA0LQSacXkzSY79Yfv3A+07pQNOtWsOKGXlJQ=;
	h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version:
	 Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From;
	b=h0fdNRxBPHbQiEHR6YhD/L52oY1Z8+TW/7f0EVeUcQWXvCqcGRN4Ok4Ht8JHopEzT
	 TwYhcShUWIg7UnSJ8r5YZfbVIwh/WDm9NyfP7DhJIXQ8AeFn4QFkRzDgiIaJdt96jL
	 ohVeIu9kfhKdH6BqgHxK1PntqpfeIR9MlUlWFupCdgyM+piAV7c5Y6N8okKzbpjHto
	 0Myznh1ClDP1OUczfH5Oc/KduRpmwW1B0vc2zWqUnTgXaK76sDOcvb+Ci6tokRLPaW
	 QctohNo7fZJ3hE0+dxmA88/6lJVHIQd1D6DmtERB6wxqoDzW/01uZKX0HBEMUCWBs2
	 2HYRMOv58cJFg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1735807540; x=1736068040; i=ngoc-tu.dinh@vates.tech;
	bh=K9neGUeA0LQSacXkzSY79Yfv3A+07pQNOtWsOKGXlJQ=;
	h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version:
	 Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From;
	b=09Dmq86DkHrQZ0zHCgfLTErCy0FG84uRw4+xIVYsVDeytEUkxL5JSW+y1jIsL+7lj
	 9K3W0sRb6O4IPX9w64wktcOiJALOY62i4PrzegV6z+RMHk8CizBdtzraE+yKida7U0
	 W5+xnFVZHcKC+oP+/T+5tdrX4UZ6L5j1+DivJk3l+iHEUcmxOtZx1q8YSP+3t5/xfp
	 4oNkg7iVU3tvO3CW9pFKVIi9aCDSWnCZ8h4VhOCviFmQhaxbtlY+rJtAzq9T4OYxFd
	 n3KcHTSmqz7K6u1OhTQKD1+3QApdcc0wOt8zBFUb6zL6IZpRSu87/w25ZE9qIhDsyP
	 1P2KGUEdDCe+w==
From: "Tu Dinh" <ngoc-tu.dinh@vates.tech>
Subject: =?utf-8?Q?[RFC=20PATCH=20v2=2000/10]=20Virtualize=20architectural=20LBRs?=
X-Mailer: git-send-email 2.43.0
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1735807538103
To: xen-devel@lists.xenproject.org
Cc: "Tu Dinh" <ngoc-tu.dinh@vates.tech>, "Anthony PERARD" <anthony.perard@vates.tech>, "Juergen Gross" <jgross@suse.com>, "Jan Beulich" <jbeulich@suse.com>, "Andrew Cooper" <andrew.cooper3@citrix.com>, "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>
Message-Id: <20250102084413.102-1-ngoc-tu.dinh@vates.tech>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.1b49e4c8739a434284ff6632279899b6?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250102:md
Date: Thu, 02 Jan 2025 08:45:40 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Intel model-specific last branch records (LBRs) were replaced by
architectural LBRs (see Chapter 20 of Intel SDM volume 3B). This
patchset implements virtual LBRs for HVM guests using Intel's "load
guest IA32_LBR_CTL" and "clear IA32_LBR_CTL" VMX controls. It
dynamically intercepts accesses to LBR state to translate between linear
and effective IP depending on the current host CPU core type.

The v2 patchset implements LBR state support in Xen's xstate handling.
Additionally, it adds XSAVES/XRSTORS support to the x86 emulator.
Finally, migration is handled by adding a new HVM save code
CPU_XSAVES_CODE containing a vCPU's compacted xstates as written by
XSAVES.

I'm looking for feedback on emulator handling of XSAVES/XRSTORS,
especially concerning FPU bits as it's not clear to me what should be
done in these cases.

Tu Dinh (10):
  x86: Add architectural LBR definitions
  x86: Define arch LBR feature bits
  tools: Add arch LBR feature bits
  x86: Calculate arch LBR CPUID policies
  x86: Keep a copy of XSAVE area size
  x86: Enable XSTATE save/restore for arch LBR
  x86/hvm: Don't count XSS bits in XSAVE size
  x86/emulate: Implement XSAVES/XRSTORS for arch LBR
  x86/vmx: Implement arch LBR
  x86/hvm: Enable XSAVES LBR save/restore

 tools/libs/light/libxl_cpuid.c              |   3 +
 tools/misc/xen-cpuid.c                      |   3 +
 tools/tests/x86_emulator/x86-emulate.h      |   2 +
 xen/arch/x86/cpu-policy.c                   |  28 +++
 xen/arch/x86/cpu/common.c                   |   7 +
 xen/arch/x86/domain.c                       |   7 +
 xen/arch/x86/hvm/emulate.c                  |  11 +
 xen/arch/x86/hvm/hvm.c                      |  70 +++++-
 xen/arch/x86/hvm/vmx/vmcs.c                 |  11 +-
 xen/arch/x86/hvm/vmx/vmx.c                  | 203 +++++++++++++--
 xen/arch/x86/include/asm/cpufeature.h       |   5 +
 xen/arch/x86/include/asm/domain.h           |   1 +
 xen/arch/x86/include/asm/hvm/hvm.h          |   3 +
 xen/arch/x86/include/asm/hvm/vmx/vmcs.h     |  11 +
 xen/arch/x86/include/asm/msr-index.h        |  12 +
 xen/arch/x86/include/asm/msr.h              |   5 +
 xen/arch/x86/include/asm/xstate.h           |  22 +-
 xen/arch/x86/msr.c                          |  89 ++++++-
 xen/arch/x86/x86_emulate/0fc7.c             | 260 ++++++++++++++------
 xen/arch/x86/x86_emulate/blk.c              | 142 +++++++++++
 xen/arch/x86/x86_emulate/private.h          |   8 +
 xen/arch/x86/x86_emulate/util-xen.c         |  14 ++
 xen/arch/x86/x86_emulate/x86_emulate.c      |  19 ++
 xen/arch/x86/x86_emulate/x86_emulate.h      |  33 +++
 xen/arch/x86/xstate.c                       |  83 +++++--
 xen/include/public/arch-x86/cpufeatureset.h |  28 ++-
 xen/include/public/arch-x86/hvm/save.h      |   4 +-
 xen/include/xen/lib/x86/cpu-policy.h        |  51 +++-
 xen/lib/x86/cpuid.c                         |   6 +
 29 files changed, 1013 insertions(+), 128 deletions(-)

-- 
2.43.0



Ngoc Tu Dinh | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


From xen-devel-bounces@lists.xenproject.org Thu Jan 02 08:45:55 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 08:45:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863730.1275094 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTGpu-0004tg-9Y; Thu, 02 Jan 2025 08:45:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863730.1275094; Thu, 02 Jan 2025 08:45:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTGpu-0004se-3f; Thu, 02 Jan 2025 08:45:46 +0000
Received: by outflank-mailman (input) for mailman id 863730;
 Thu, 02 Jan 2025 08:45: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
 <SRS0=BpyQ=T2=bounce.vates.tech=bounce-md_30504962.67765235.v1-d628a30899f042d695a6c136380c8c92@srs-se1.protection.inumbo.net>)
 id 1tTGps-0004rF-EC
 for xen-devel@lists.xenproject.org; Thu, 02 Jan 2025 08:45:44 +0000
Received: from mail180-43.suw31.mandrillapp.com
 (mail180-43.suw31.mandrillapp.com [198.2.180.43])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f2e07578-c8e5-11ef-a0db-8be0dac302b0;
 Thu, 02 Jan 2025 09:45:42 +0100 (CET)
Received: from pmta11.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail180-43.suw31.mandrillapp.com (Mailchimp) with ESMTP id
 4YP0fF5Mh3zLfHBGS
 for <xen-devel@lists.xenproject.org>; Thu,  2 Jan 2025 08:45:41 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 d628a30899f042d695a6c136380c8c92; Thu, 02 Jan 2025 08:45:41 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f2e07578-c8e5-11ef-a0db-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1735807541; x=1736068041;
	bh=R32ivPZ8JUTitnv8cnvvzU3Su0yCpWPGxSwsBLOjoMQ=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=FOZPufxURTOJy7jIkSOWuXuzFjoTT6HtVVRLQZXjWLU2rGd4rxAKTsQK1RH1aKLBP
	 OCZQVmacuF27CIiKezl1StZeWVwSBHy6Y2AFrO5rs2HVWEk4azJg3gxxNZBwdnga9c
	 XQssrH2yJxpiYUaVlpWJfMSB8Pi6ng7oTU3DnJ0zcnNTMAJurlfS+6cf2yyu0dmDp4
	 ks/BJUcjyqrZoslDwUKUeYlbdWcf3N5gzCiVjqoHtNqZm6+6azL8tHKK8mkoydWw2o
	 h5clkv9woQ/CPdcyRJ1TR/JQqehG+NPbXictUbGLw3TLbCemVp/vnjLZt81Vof35fm
	 wS/xMw1b6vcig==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1735807541; x=1736068041; i=ngoc-tu.dinh@vates.tech;
	bh=R32ivPZ8JUTitnv8cnvvzU3Su0yCpWPGxSwsBLOjoMQ=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=TeEufgR2NQZPge6us8mIOYWSDG5iDl4P3Bz+153exU8Ee8nbhAfzDljnr6veMuVCM
	 A3xg/8RWs34txfq9KsxIiPhC2//5iF6xizgYg9AKWxdiuzdyt4GkmBfWWQpFdDYgq5
	 Q3PAkqeQQOX6DqvRkjlsp8CqHhannave30oTYkBUu2osvm5hhPWR0PBV83fWanyKt9
	 Mhehk3xJIQo8hXbaWTOpX9PzSdPGbldVdhgzhjVt9FJzECNnM1IvLAO1b8KlfQe/r4
	 JyKZSk0oZ4keEGrj/i6/d6LkCZR/79U8jTSdf8CyL7EW6z1fTFNygLxtxe8fCQd5af
	 v9m8S5NFaBs3g==
From: "Tu Dinh" <ngoc-tu.dinh@vates.tech>
Subject: =?utf-8?Q?[RFC=20PATCH=20v2=2008/10]=20x86/emulate:=20Implement=20XSAVES/XRSTORS=20for=20arch=20LBR?=
X-Mailer: git-send-email 2.43.0
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1735807540507
To: xen-devel@lists.xenproject.org
Cc: "Tu Dinh" <ngoc-tu.dinh@vates.tech>, "Anthony PERARD" <anthony.perard@vates.tech>, "Juergen Gross" <jgross@suse.com>, "Jan Beulich" <jbeulich@suse.com>, "Andrew Cooper" <andrew.cooper3@citrix.com>, "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>
Message-Id: <20250102084413.102-9-ngoc-tu.dinh@vates.tech>
In-Reply-To: <20250102084413.102-1-ngoc-tu.dinh@vates.tech>
References: <20250102084413.102-1-ngoc-tu.dinh@vates.tech>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.d628a30899f042d695a6c136380c8c92?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250102:md
Date: Thu, 02 Jan 2025 08:45:41 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Add new set_lbr_depth HVM function and emulate ops to support LBR
XSAVES/XRSTORS emulation.

Add the appropriate instruction hooks to 0fc7.c. Translate LBR registers
using cs.base within a large block emulator operation.

Signed-off-by: Tu Dinh <ngoc-tu.dinh@vates.tech>
---
 tools/tests/x86_emulator/x86-emulate.h |   2 +
 xen/arch/x86/hvm/emulate.c             |  11 ++
 xen/arch/x86/include/asm/hvm/hvm.h     |   3 +
 xen/arch/x86/x86_emulate/0fc7.c        | 260 ++++++++++++++++++-------
 xen/arch/x86/x86_emulate/blk.c         | 142 ++++++++++++++
 xen/arch/x86/x86_emulate/private.h     |   8 +
 xen/arch/x86/x86_emulate/util-xen.c    |  14 ++
 xen/arch/x86/x86_emulate/x86_emulate.c |  19 ++
 xen/arch/x86/x86_emulate/x86_emulate.h |  33 ++++
 9 files changed, 422 insertions(+), 70 deletions(-)

diff --git a/tools/tests/x86_emulator/x86-emulate.h b/tools/tests/x86_emulator/x86-emulate.h
index 929c1a72ae..75a9a65ae7 100644
--- a/tools/tests/x86_emulator/x86-emulate.h
+++ b/tools/tests/x86_emulator/x86-emulate.h
@@ -218,6 +218,8 @@ void wrpkru(unsigned int val);
 #define cpu_has_fma4                (cpu_policy.extd.fma4 && xcr0_mask(6))
 #define cpu_has_tbm                  cpu_policy.extd.tbm
 
+#define current_cpu_has_lbr_lip      cpu_policy.basic.lbr_1Ca.ip_contains_lip
+
 int emul_test_cpuid(
     uint32_t leaf,
     uint32_t subleaf,
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index a1935a1748..c3b0bd4cbe 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -2562,6 +2562,16 @@ static int cf_check hvmemul_vmfunc(
     return rc;
 }
 
+static int cf_check hvmemul_set_lbr_depth(
+    uint32_t depth,
+    struct x86_emulate_ctxt *ctxt)
+{
+    if ( !hvm_funcs.set_lbr_depth )
+        return X86EMUL_UNHANDLEABLE;
+    alternative_vcall(hvm_funcs.set_lbr_depth, current, depth);
+    return X86EMUL_OKAY;
+}
+
 static const struct x86_emulate_ops hvm_emulate_ops = {
     .read          = hvmemul_read,
     .insn_fetch    = hvmemul_insn_fetch,
@@ -2590,6 +2600,7 @@ static const struct x86_emulate_ops hvm_emulate_ops = {
     .get_fpu       = hvmemul_get_fpu,
     .put_fpu       = hvmemul_put_fpu,
     .vmfunc        = hvmemul_vmfunc,
+    .set_lbr_depth = hvmemul_set_lbr_depth,
 };
 
 static const struct x86_emulate_ops hvm_emulate_ops_no_write = {
diff --git a/xen/arch/x86/include/asm/hvm/hvm.h b/xen/arch/x86/include/asm/hvm/hvm.h
index cad3a94278..bfce78952f 100644
--- a/xen/arch/x86/include/asm/hvm/hvm.h
+++ b/xen/arch/x86/include/asm/hvm/hvm.h
@@ -238,6 +238,9 @@ struct hvm_function_table {
     int (*vmtrace_get_option)(struct vcpu *v, uint64_t key, uint64_t *value);
     int (*vmtrace_reset)(struct vcpu *v);
 
+    /* Arch LBR */
+    void (*set_lbr_depth)(struct vcpu *v, uint32_t depth);
+
     uint64_t (*get_reg)(struct vcpu *v, unsigned int reg);
     void (*set_reg)(struct vcpu *v, unsigned int reg, uint64_t val);
 
diff --git a/xen/arch/x86/x86_emulate/0fc7.c b/xen/arch/x86/x86_emulate/0fc7.c
index 5268d5cafd..bb2b308afe 100644
--- a/xen/arch/x86/x86_emulate/0fc7.c
+++ b/xen/arch/x86/x86_emulate/0fc7.c
@@ -10,6 +10,10 @@
 
 #include "private.h"
 
+#if defined(__XEN__) && !defined(X86EMUL_NO_FPU)
+# include <asm/xstate.h>
+#endif
+
 /* Avoid namespace pollution. */
 #undef cmpxchg
 
@@ -107,87 +111,203 @@ int x86emul_0fc7(struct x86_emulate_state *s,
     }
     else
     {
-        union {
-            uint32_t u32[2];
-            uint64_t u64[2];
-        } *old, *aux;
-
-        /* cmpxchg8b/cmpxchg16b */
-        generate_exception_if((s->modrm_reg & 7) != 1, X86_EXC_UD);
-        fail_if(!ops->cmpxchg);
-        if ( s->rex_prefix & REX_W )
-        {
-            host_and_vcpu_must_have(cx16);
-            generate_exception_if(!is_aligned(s->ea.mem.seg, s->ea.mem.off, 16,
-                                              ctxt, ops),
-                                  X86_EXC_GP, 0);
-            s->op_bytes = 16;
-        }
-        else
+        switch ( s->modrm_reg & 7 )
         {
-            vcpu_must_have(cx8);
-            s->op_bytes = 8;
-        }
+            default:
+                return X86EMUL_UNRECOGNIZED;
 
-        old = container_of(&mmvalp->ymm[0], typeof(*old), u64[0]);
-        aux = container_of(&mmvalp->ymm[2], typeof(*aux), u64[0]);
+            case 1: /* cmpxchg8b/cmpxchg16b */
+            {
+                union {
+                    uint32_t u32[2];
+                    uint64_t u64[2];
+                } *old, *aux;
 
-        /* Get actual old value. */
-        if ( (rc = ops->read(s->ea.mem.seg, s->ea.mem.off, old, s->op_bytes,
-                             ctxt)) != X86EMUL_OKAY )
-            goto done;
+                fail_if(!ops->cmpxchg);
+                if ( s->rex_prefix & REX_W )
+                {
+                    host_and_vcpu_must_have(cx16);
+                    generate_exception_if(!is_aligned(s->ea.mem.seg, s->ea.mem.off, 16,
+                                                      ctxt, ops),
+                                          X86_EXC_GP, 0);
+                    s->op_bytes = 16;
+                }
+                else
+                {
+                    vcpu_must_have(cx8);
+                    s->op_bytes = 8;
+                }
 
-        /* Get expected value. */
-        if ( s->op_bytes == 8 )
-        {
-            aux->u32[0] = regs->eax;
-            aux->u32[1] = regs->edx;
-        }
-        else
-        {
-            aux->u64[0] = regs->r(ax);
-            aux->u64[1] = regs->r(dx);
-        }
+                old = container_of(&mmvalp->ymm[0], typeof(*old), u64[0]);
+                aux = container_of(&mmvalp->ymm[2], typeof(*aux), u64[0]);
 
-        if ( memcmp(old, aux, s->op_bytes) )
-        {
-        cmpxchgNb_failed:
-            /* Expected != actual: store actual to rDX:rAX and clear ZF. */
-            regs->r(ax) = s->op_bytes == 8 ? old->u32[0] : old->u64[0];
-            regs->r(dx) = s->op_bytes == 8 ? old->u32[1] : old->u64[1];
-            regs->eflags &= ~X86_EFLAGS_ZF;
-        }
-        else
-        {
-            /*
-             * Expected == actual: Get proposed value, attempt atomic cmpxchg
-             * and set ZF if successful.
-             */
-            if ( s->op_bytes == 8 )
-            {
-                aux->u32[0] = regs->ebx;
-                aux->u32[1] = regs->ecx;
-            }
-            else
-            {
-                aux->u64[0] = regs->r(bx);
-                aux->u64[1] = regs->r(cx);
+                /* Get actual old value. */
+                if ( (rc = ops->read(s->ea.mem.seg, s->ea.mem.off, old, s->op_bytes,
+                                     ctxt)) != X86EMUL_OKAY )
+                    goto done;
+
+                /* Get expected value. */
+                if ( s->op_bytes == 8 )
+                {
+                    aux->u32[0] = regs->eax;
+                    aux->u32[1] = regs->edx;
+                }
+                else
+                {
+                    aux->u64[0] = regs->r(ax);
+                    aux->u64[1] = regs->r(dx);
+                }
+
+                if ( memcmp(old, aux, s->op_bytes) )
+                {
+                cmpxchgNb_failed:
+                    /* Expected != actual: store actual to rDX:rAX and clear ZF. */
+                    regs->r(ax) = s->op_bytes == 8 ? old->u32[0] : old->u64[0];
+                    regs->r(dx) = s->op_bytes == 8 ? old->u32[1] : old->u64[1];
+                    regs->eflags &= ~X86_EFLAGS_ZF;
+                }
+                else
+                {
+                    /*
+                    * Expected == actual: Get proposed value, attempt atomic cmpxchg
+                    * and set ZF if successful.
+                    */
+                    if ( s->op_bytes == 8 )
+                    {
+                        aux->u32[0] = regs->ebx;
+                        aux->u32[1] = regs->ecx;
+                    }
+                    else
+                    {
+                        aux->u64[0] = regs->r(bx);
+                        aux->u64[1] = regs->r(cx);
+                    }
+
+                    switch ( rc = ops->cmpxchg(s->ea.mem.seg, s->ea.mem.off, old, aux,
+                                               s->op_bytes, s->lock_prefix, ctxt) )
+                    {
+                    case X86EMUL_OKAY:
+                        regs->eflags |= X86_EFLAGS_ZF;
+                        break;
+
+                    case X86EMUL_CMPXCHG_FAILED:
+                        rc = X86EMUL_OKAY;
+                        goto cmpxchgNb_failed;
+
+                    default:
+                        goto done;
+                    }
+                }
+                break;
             }
 
-            switch ( rc = ops->cmpxchg(s->ea.mem.seg, s->ea.mem.off, old, aux,
-                                       s->op_bytes, s->lock_prefix, ctxt) )
+#if defined(__XEN__) && !defined(X86EMUL_NO_FPU)
+            case 3: /* xrstors */
+            case 5: /* xsaves */
             {
-            case X86EMUL_OKAY:
-                regs->eflags |= X86_EFLAGS_ZF;
-                break;
+                unsigned long cr0, cr4;
+                unsigned long xcr0, xss;
+                struct segment_register cs;
 
-            case X86EMUL_CMPXCHG_FAILED:
-                rc = X86EMUL_OKAY;
-                goto cmpxchgNb_failed;
+                generate_exception_if(s->vex.pfx, X86_EXC_UD);
+                host_and_vcpu_must_have(xsaves);
+                generate_exception_if(s->ea.type != OP_MEM, X86_EXC_UD);
+                generate_exception_if(!is_aligned(s->ea.mem.seg, s->ea.mem.off,
+                                                  64, ctxt, ops),
+                                      X86_EXC_GP, 0);
+                fail_if(!ops->blk || !ops->read_cr || !ops->read_xcr ||
+                        !ops->read_msr || !ops->write_msr ||
+                        !ops->read_segment);
+                fail_if(vcpu_has_arch_lbr() && !ops->set_lbr_depth);
 
-            default:
-                goto done;
+                if ( ops->read_cr(4, &cr4, ctxt) != X86EMUL_OKAY ||
+                     ops->read_cr(0, &cr0, ctxt) != X86EMUL_OKAY )
+                     cr0 = cr4 = 0;
+                generate_exception_if(!(cr4 & X86_CR4_OSXSAVE), X86_EXC_UD);
+                generate_exception_if(cr0 & X86_CR0_TS, X86_EXC_NM);
+                generate_exception_if(!mode_ring0(), X86_EXC_GP, 0);
+
+                if ( (rc = ops->read_segment(x86_seg_cs,
+                                             &cs, ctxt)) != X86EMUL_OKAY ||
+                     (rc = ops->read_xcr(0, &xcr0, ctxt)) != X86EMUL_OKAY ||
+                     (rc = ops->read_msr(MSR_IA32_XSS,
+                                         &xss, ctxt)) != X86EMUL_OKAY )
+                    goto done;
+
+                if ( vcpu_has_arch_lbr() &&
+                     ((rc = ops->read_msr(MSR_LBR_CTL, &ctxt->xsaves.lbr_ctl,
+                                          ctxt)) != X86EMUL_OKAY ||
+                      (rc = ops->read_msr(MSR_LBR_DEPTH, &ctxt->xsaves.lbr_depth,
+                                          ctxt)) != X86EMUL_OKAY) )
+                    goto done;
+
+                s->blk = (s->modrm_reg & 7) == 3 ? blk_xrstors : blk_xsaves;
+                ctxt->xsaves.rfbm = ((uint64_t)regs->edx << 32) | regs->eax;
+                ctxt->xsaves.rfbm &= xcr0 | xss;
+
+                if ( s->blk == blk_xrstors )
+                {
+                    struct xsave_struct hdr;
+                    int i;
+
+                    if ( (rc = ops->read(s->ea.mem.seg, s->ea.mem.off, &hdr,
+                                         sizeof(hdr), ctxt)) != X86EMUL_OKAY )
+                        goto done;
+                    /*
+                     * We must validate xcomp_bv at this stage to get a
+                     * stable XSAVE area size.
+                     */
+                    generate_exception_if(!xsave_area_compressed(&hdr),
+                                          X86_EXC_GP, 0);
+                    generate_exception_if(hdr.xsave_hdr.xcomp_bv &
+                                          ~XSTATE_COMPACTION_ENABLED &
+                                          ~(xcr0 | xss),
+                                          X86_EXC_GP, 0);
+                    generate_exception_if(hdr.xsave_hdr.xstate_bv &
+                                          ~hdr.xsave_hdr.xcomp_bv,
+                                          X86_EXC_GP, 0);
+                    for ( i = 0; i < ARRAY_SIZE(hdr.xsave_hdr.reserved); i++ )
+                        generate_exception_if(hdr.xsave_hdr.reserved[i],
+                                              X86_EXC_GP, 0);
+                    ctxt->xsaves.size = xstate_compressed_size(
+                            hdr.xsave_hdr.xcomp_bv &
+                            ~XSTATE_COMPACTION_ENABLED);
+                }
+                else
+                {
+                    ctxt->xsaves.size =
+                            xstate_compressed_size(ctxt->xsaves.rfbm);
+                }
+
+                if ( (rc = ops->blk(s->ea.mem.seg, s->ea.mem.off, NULL,
+                                    ctxt->xsaves.size, &regs->eflags,
+                                    s, ctxt)) != X86EMUL_OKAY )
+                    goto done;
+
+                if ( s->blk == blk_xrstors && vcpu_has_arch_lbr() )
+                {
+                    if ( (rc = ops->write_msr(MSR_LBR_CTL,
+                                              ctxt->xsaves.lbr_ctl,
+                                              ctxt)) != X86EMUL_OKAY ||
+                         (rc = ops->set_lbr_depth(ctxt->xsaves.lbr_depth,
+                                                  ctxt)) != X86EMUL_OKAY )
+                        goto done;
+                    /*
+                     * Even if xstate_bv[LBR]=0, XRSTORS will still clear
+                     * LBR/LER MSRs.
+                     */
+                    if ( !(ctxt->xsaves.xstate_bv & X86_XSS_LBR) &&
+                         ((rc = ops->write_msr(MSR_IA32_LASTINTFROMIP, 0,
+                                               ctxt)) != X86EMUL_OKAY ||
+                          (rc = ops->write_msr(MSR_IA32_LASTINTTOIP, 0,
+                                               ctxt)) != X86EMUL_OKAY ||
+                          (rc = ops->write_msr(MSR_LER_INFO, 0,
+                                               ctxt)) != X86EMUL_OKAY) )
+                        goto done;
+                }
+                break;
             }
+#endif /* __XEN__ && X86EMUL_NO_FPU */
         }
     }
 
diff --git a/xen/arch/x86/x86_emulate/blk.c b/xen/arch/x86/x86_emulate/blk.c
index 08a05f8453..ed85a58f30 100644
--- a/xen/arch/x86/x86_emulate/blk.c
+++ b/xen/arch/x86/x86_emulate/blk.c
@@ -17,6 +17,29 @@
 # endif
 #endif
 
+#if defined(__XEN__) && !defined(X86EMUL_NO_FPU)
+static struct xstate_lbr *
+x86_translate_lbr(struct x86_emulate_state *s,
+                  struct x86_emulate_ctxt *ctxt,
+                  const struct segment_register *cs,
+                  bool saving,
+                  struct xstate_lbr *lbr)
+{
+    uint64_t cs_offset;
+    uint32_t i;
+    
+    cs_offset = x86_get_lbr_cs_offset(ctxt->cpuid, mode_64bit(), cs, saving);
+    lbr->ler_from_ip += cs_offset;
+    lbr->ler_to_ip += cs_offset;
+    for ( i = 0; i < ctxt->xsaves.lbr_depth; i++ )
+    {
+        lbr->entries[i].lbr_from_ip += cs_offset;
+        lbr->entries[i].lbr_to_ip += cs_offset;
+    }
+    return lbr;
+}
+#endif
+
 int x86_emul_blk(
     void *ptr,
     void *data,
@@ -373,6 +396,125 @@ int x86_emul_blk(
         }
         break;
 
+/*
+ * XSAVES/XRSTORS emulation uses the host's XSS instructions and therefore
+ * can't be used in an usermode emulator.
+ */
+#if defined(__XEN__) && !defined(X86EMUL_NO_FPU)
+
+#define _xrstors(pfx, mem, eax, edx, faulted) \
+        asm volatile ( "1: .byte " pfx "0x0f,0xc7,0x1f\n" \
+                       "3:\n" \
+                       "   .section .fixup,\"ax\"\n" \
+                       "2: incl %[faulted]\n" \
+                       "   jmp 3b\n" \
+                       "   .previous\n" \
+                       _ASM_EXTABLE(1b, 2b) \
+                       : "+m" (*mem), [faulted] "+g" (faulted) \
+                       : "a" (eax), "d" (edx), "D" (mem) )
+#define _xsaves(pfx, mem, eax, edx, faulted) \
+        asm volatile ( "1: .byte " pfx "0x0f,0xc7,0x2f\n" \
+                       "3:\n" \
+                       "   .section .fixup,\"ax\"\n" \
+                       "2: incl %[faulted]\n" \
+                       "   jmp 3b\n" \
+                       "   .previous\n" \
+                       _ASM_EXTABLE(1b, 2b) \
+                       : "+m" (*mem), [faulted] "+g" (faulted) \
+                       : "a" (eax), "d" (edx), "D" (mem) )
+
+    case blk_xrstors:
+    {
+        struct xsave_struct *xstate = ptr;
+        unsigned int faulted;
+
+        ASSERT(!data);
+
+        if ( ctxt->xsaves.rfbm & xstate->xsave_hdr.xcomp_bv & X86_XSS_LBR )
+        {
+            struct xstate_lbr *lbr;
+
+            lbr = get_xstate_component_comp(xstate, bytes, X86_XSS_LBR);
+            generate_exception_if(!lbr, X86_EXC_GP, 0);
+            if ( xstate->xsave_hdr.xstate_bv & X86_XSS_LBR )
+            {
+                generate_exception_if(lbr->lbr_ctl & ~LBR_CTL_VALID,
+                                      X86_EXC_GP, 0);
+                generate_exception_if(lbr->lbr_depth == 0 ||
+                                      lbr->lbr_depth >
+                                       NUM_MSR_ARCH_LBR_FROM_TO ||
+                                      lbr->lbr_depth % 8 != 0,
+                                      X86_EXC_GP, 0);
+
+                if ( !mode_64bit() )
+                    x86_translate_lbr(s, ctxt, data, false, lbr);
+                ctxt->xsaves.lbr_ctl = lbr->lbr_ctl;
+                ctxt->xsaves.lbr_depth = lbr->lbr_depth;
+                lbr->lbr_ctl = 0;
+            }
+            else
+            {
+                ctxt->xsaves.lbr_ctl = 0;
+                /* Don't touch the previous LBR depth */
+            }
+        }
+
+        faulted = 0;
+        if ( s->rex_prefix & REX_W )
+            _xrstors("0x48,", xstate, ctxt->xsaves.rfbm & UINT32_MAX,
+                     ctxt->xsaves.rfbm >> 32, faulted);
+        else
+            _xrstors("", xstate, ctxt->xsaves.rfbm & UINT32_MAX,
+                     ctxt->xsaves.rfbm >> 32, faulted);
+        generate_exception_if(faulted, X86_EXC_GP, 0);
+
+        ctxt->xsaves.xstate_bv = xstate->xsave_hdr.xstate_bv;
+
+        break;
+    }
+
+    case blk_xsaves:
+    {
+        struct xsave_struct *xstate = ptr;
+        unsigned int faulted;
+
+        ASSERT(!data);
+
+        /* Defeat XSAVES modified optimization using XRSTORS with EDX=EAX=0 */
+        memset(xstate, 0, sizeof(*xstate));
+        xstate->xsave_hdr.xcomp_bv = XSTATE_COMPACTION_ENABLED;
+        faulted = 0;
+        _xrstors("", xstate, 0, 0, faulted);
+        generate_exception_if(faulted, X86_EXC_GP, 0);
+
+        faulted = 0;
+        if ( s->rex_prefix & REX_W )
+            _xsaves("0x48,", xstate, ctxt->xsaves.rfbm & UINT32_MAX,
+                    ctxt->xsaves.rfbm >> 32, faulted);
+        else
+            _xsaves("", xstate, ctxt->xsaves.rfbm & UINT32_MAX,
+                    ctxt->xsaves.rfbm >> 32, faulted);
+        generate_exception_if(faulted, X86_EXC_GP, 0);
+
+        if ( ctxt->xsaves.rfbm & xstate->xsave_hdr.xcomp_bv & X86_XSS_LBR )
+        {
+            struct xstate_lbr *lbr;
+
+            lbr = get_xstate_component_comp(xstate, bytes, X86_XSS_LBR);
+            generate_exception_if(!lbr, X86_EXC_GP, 0);
+            if ( !mode_64bit() && (xstate->xsave_hdr.xstate_bv & X86_XSS_LBR) )
+                x86_translate_lbr(s, ctxt, data, true, lbr);
+            lbr->lbr_ctl = ctxt->xsaves.lbr_ctl;
+            lbr->lbr_depth = ctxt->xsaves.lbr_depth;
+        }
+
+        break;
+    }
+#undef _xsaves
+#undef _xrstors
+
+#endif /* __XEN__ && X86EMUL_NO_FPU */
+
     default:
         ASSERT_UNREACHABLE();
         return X86EMUL_UNHANDLEABLE;
diff --git a/xen/arch/x86/x86_emulate/private.h b/xen/arch/x86/x86_emulate/private.h
index ef4745f56e..a48d647df7 100644
--- a/xen/arch/x86/x86_emulate/private.h
+++ b/xen/arch/x86/x86_emulate/private.h
@@ -295,6 +295,10 @@ struct x86_emulate_state {
         blk_fxsave,
 #endif
         blk_movdir,
+#ifndef X86EMUL_NO_FPU
+        blk_xrstors,
+        blk_xsaves,
+#endif
     } blk;
     uint8_t modrm, modrm_mod, modrm_reg, modrm_rm;
     uint8_t sib_index, sib_scale;
@@ -537,6 +541,7 @@ amd_like(const struct x86_emulate_ctxt *ctxt)
 #define vcpu_has_avx()         (ctxt->cpuid->basic.avx)
 #define vcpu_has_f16c()        (ctxt->cpuid->basic.f16c)
 #define vcpu_has_rdrand()      (ctxt->cpuid->basic.rdrand)
+#define vcpu_has_lbr_lip()     (ctxt->cpuid->basic.lbr_1Ca.ip_contains_lip)
 
 #define vcpu_has_mmxext()      (ctxt->cpuid->extd.mmxext || vcpu_has_sse())
 #define vcpu_has_3dnow_ext()   (ctxt->cpuid->extd._3dnowext)
@@ -587,6 +592,7 @@ amd_like(const struct x86_emulate_ctxt *ctxt)
 #define vcpu_has_avx512_vp2intersect() (ctxt->cpuid->feat.avx512_vp2intersect)
 #define vcpu_has_serialize()   (ctxt->cpuid->feat.serialize)
 #define vcpu_has_tsxldtrk()    (ctxt->cpuid->feat.tsxldtrk)
+#define vcpu_has_arch_lbr()    (ctxt->cpuid->feat.arch_lbr)
 #define vcpu_has_avx512_fp16() (ctxt->cpuid->feat.avx512_fp16)
 #define vcpu_has_sha512()      (ctxt->cpuid->feat.sha512)
 #define vcpu_has_sm3()         (ctxt->cpuid->feat.sm3)
@@ -600,6 +606,8 @@ amd_like(const struct x86_emulate_ctxt *ctxt)
 #define vcpu_has_avx_ne_convert() (ctxt->cpuid->feat.avx_ne_convert)
 #define vcpu_has_avx_vnni_int16() (ctxt->cpuid->feat.avx_vnni_int16)
 
+#define vcpu_has_xsaves()       (ctxt->cpuid->xstate.xsaves)
+
 #define vcpu_must_have(feat) \
     generate_exception_if(!vcpu_has_##feat(), X86_EXC_UD)
 
diff --git a/xen/arch/x86/x86_emulate/util-xen.c b/xen/arch/x86/x86_emulate/util-xen.c
index 5e90818010..e5c34b5b42 100644
--- a/xen/arch/x86/x86_emulate/util-xen.c
+++ b/xen/arch/x86/x86_emulate/util-xen.c
@@ -96,6 +96,20 @@ bool cf_check x86_insn_is_cr_access(const struct x86_emulate_state *s,
     return false;
 }
 
+bool cf_check x86_insn_is_xsaves(const struct x86_emulate_state *s,
+                                 const struct x86_emulate_ctxt *ctxt)
+{
+    return ctxt->opcode == X86EMUL_OPC(0x0f, 0xc7) && s->ea.type == OP_MEM &&
+           (s->modrm_reg & 7) == 5;
+}
+
+bool cf_check x86_insn_is_xrstors(const struct x86_emulate_state *s,
+                                  const struct x86_emulate_ctxt *ctxt)
+{
+    return ctxt->opcode == X86EMUL_OPC(0x0f, 0xc7) && s->ea.type == OP_MEM &&
+           (s->modrm_reg & 7) == 3;
+}
+
 unsigned long x86_insn_immediate(const struct x86_emulate_state *s,
                                  unsigned int nr)
 {
diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c b/xen/arch/x86/x86_emulate/x86_emulate.c
index b89d440133..92c23006e5 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -8592,6 +8592,25 @@ int x86_emul_rmw(
 }
 #undef stub_exn
 
+uint64_t x86_get_lbr_cs_offset(const struct cpu_policy *cp,
+                               bool is_long_mode,
+                               const struct segment_register *cs,
+                               bool saving)
+{
+    bool host_lip, guest_lip;
+    
+    host_lip = current_cpu_has_lbr_lip;
+    guest_lip = !!cp->basic.lbr_1Ca.ip_contains_lip;
+
+    if ( host_lip == guest_lip || is_long_mode )
+        return 0;
+    else if ( (host_lip && !guest_lip && saving) ||
+              (!host_lip && guest_lip && !saving) )
+        return -cs->base;
+    else
+        return cs->base;
+}
+
 static void __init __maybe_unused build_assertions(void)
 {
     /* Check the values against SReg3 encoding in opcode/ModRM bytes. */
diff --git a/xen/arch/x86/x86_emulate/x86_emulate.h b/xen/arch/x86/x86_emulate/x86_emulate.h
index d75658eba0..cc86ec3cee 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.h
+++ b/xen/arch/x86/x86_emulate/x86_emulate.h
@@ -534,6 +534,10 @@ struct x86_emulate_ops
     /* vmfunc: Emulate VMFUNC via given set of EAX ECX inputs */
     int (*vmfunc)(
         struct x86_emulate_ctxt *ctxt);
+
+    int (*set_lbr_depth)(
+        uint32_t depth,
+        struct x86_emulate_ctxt *ctxt);
 };
 
 struct cpu_user_regs;
@@ -572,6 +576,22 @@ struct x86_emulate_ctxt
     /* Long mode active? */
     bool lma;
 
+    struct {
+        /* In */
+        uint64_t rfbm;
+        unsigned int size;
+        /* Inout */
+        /*
+         * MSR_LBR_{CTL,DEPTH} don't match guest state, so we need to pass
+         * them to the emulator.
+         */
+        uint64_t lbr_ctl;
+        uint64_t lbr_depth;
+        /* Out */
+        /* XRSTORS */
+        uint64_t xstate_bv;
+    } xsaves;
+
     /*
      * Output-only state:
      */
@@ -763,6 +783,14 @@ bool cf_check
 x86_insn_is_cr_access(const struct x86_emulate_state *s,
                       const struct x86_emulate_ctxt *ctxt);
 
+bool cf_check
+x86_insn_is_xsaves(const struct x86_emulate_state *s,
+                   const struct x86_emulate_ctxt *ctxt);
+
+bool cf_check
+x86_insn_is_xrstors(const struct x86_emulate_state *s,
+                    const struct x86_emulate_ctxt *ctxt);
+
 #if !defined(__XEN__) || defined(NDEBUG)
 static inline void x86_emulate_free_state(struct x86_emulate_state *s) {}
 #else
@@ -802,6 +830,11 @@ x86_emul_blk(
     struct x86_emulate_state *s,
     struct x86_emulate_ctxt *ctxt);
 
+uint64_t x86_get_lbr_cs_offset(const struct cpu_policy *cp,
+                               bool is_long_mode,
+                               const struct segment_register *cs,
+                               bool reading);
+
 static inline void x86_emul_hw_exception(
     unsigned int vector, int error_code, struct x86_emulate_ctxt *ctxt)
 {
-- 
2.43.0



Ngoc Tu Dinh | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


From xen-devel-bounces@lists.xenproject.org Thu Jan 02 08:45:55 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 08:45:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863739.1275188 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTGq1-0007HM-Sy; Thu, 02 Jan 2025 08:45:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863739.1275188; Thu, 02 Jan 2025 08:45:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTGq1-0007GF-OA; Thu, 02 Jan 2025 08:45:53 +0000
Received: by outflank-mailman (input) for mailman id 863739;
 Thu, 02 Jan 2025 08:45:52 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=ANLz=T2=bounce.vates.tech=bounce-md_30504962.67765235.v1-b133c83311a14cd3872070929731beea@srs-se1.protection.inumbo.net>)
 id 1tTGpz-0004rS-V4
 for xen-devel@lists.xenproject.org; Thu, 02 Jan 2025 08:45:51 +0000
Received: from mail180-50.suw31.mandrillapp.com
 (mail180-50.suw31.mandrillapp.com [198.2.180.50])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f692b2ef-c8e5-11ef-99a4-01e77a169b0f;
 Thu, 02 Jan 2025 09:45:48 +0100 (CET)
Received: from pmta11.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail180-50.suw31.mandrillapp.com (Mailchimp) with ESMTP id
 4YP0fF1C1JzCfD7NC
 for <xen-devel@lists.xenproject.org>; Thu,  2 Jan 2025 08:45:41 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 b133c83311a14cd3872070929731beea; Thu, 02 Jan 2025 08:45:41 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f692b2ef-c8e5-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1735807541; x=1736068041;
	bh=QFIxqPt7/jeUPPpwBYw+2ueBPIx3z09csJHPFtv383Y=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=0RUiMycPuccrGYEQh6/0epojJrlT9+8TcXJXNq0kLcAZXp+/4ZXOnYdFppzmha5ju
	 Gf6/c5/OJugVYnrxJQQfGiqUmZ/V7m4lVMdQzR4+3GmWLyR3qto6TH9Wcv1FXPNnP/
	 cob4hZrFNiLHKfF5F7N/hlI3bsoC5tjPRu0DKjMtX91XaXigUXNRkyIZtNbGwZonx+
	 phD6Ay1TMRnfjgQaKrizq3rkNMiqD3j1Y4fUWEDl8KVj9ZSa+TRWZJ1gXoOJ1d5/Cp
	 Y2IipbICa0c2IfWL/2bSgUSUtRdElI0LL2ba2mVgb0pdF6nWT1HEja6H6XTsnDOUc0
	 WbKyAF07GMwMg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1735807541; x=1736068041; i=ngoc-tu.dinh@vates.tech;
	bh=QFIxqPt7/jeUPPpwBYw+2ueBPIx3z09csJHPFtv383Y=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=UQewD+KVlhDdl1+IdAMse4OdZYUZ5geILHQ/MlXHjP83PXH8QiqU+XvdCQdxxRB6k
	 iBf6RSVtEwnaW8xDO+8ZtgAfd6zhlOvQ20ZmVu4zeTd0GxDUcDyWk5kJ0u+qDplSoo
	 1w/nW76hofiNowGgrDilqv9p1gWx1HC+4K1m3odOPiZFJPP/+e2mn0jsq2LV3OMBeK
	 Vn484RFCoD4XkMFlPv8MViv5uMvJc3E16qSDU/qUhA3xpwvGlUISCB8701r1VywA+L
	 ahCy/rnA8oHkjRzpeGY4kDyrnPcSCf6s59Xz0rv0hiGl7AZUmtneIHYBS5s0lQPH5f
	 c5qvNS8CXlL/A==
From: "Tu Dinh" <ngoc-tu.dinh@vates.tech>
Subject: =?utf-8?Q?[RFC=20PATCH=20v2=2007/10]=20x86/hvm:=20Don't=20count=20XSS=20bits=20in=20XSAVE=20size?=
X-Mailer: git-send-email 2.43.0
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1735807540297
To: xen-devel@lists.xenproject.org
Cc: "Tu Dinh" <ngoc-tu.dinh@vates.tech>, "Anthony PERARD" <anthony.perard@vates.tech>, "Juergen Gross" <jgross@suse.com>, "Jan Beulich" <jbeulich@suse.com>, "Andrew Cooper" <andrew.cooper3@citrix.com>, "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>
Message-Id: <20250102084413.102-8-ngoc-tu.dinh@vates.tech>
In-Reply-To: <20250102084413.102-1-ngoc-tu.dinh@vates.tech>
References: <20250102084413.102-1-ngoc-tu.dinh@vates.tech>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.b133c83311a14cd3872070929731beea?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250102:md
Date: Thu, 02 Jan 2025 08:45:41 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

HVM vCPU state images are uncompressed and therefore can't contain XSS
states.

Signed-off-by: Tu Dinh <ngoc-tu.dinh@vates.tech>
---
 xen/arch/x86/hvm/hvm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 922c9b3af6..c7b93c7d91 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1208,7 +1208,8 @@ HVM_REGISTER_SAVE_RESTORE(CPU, hvm_save_cpu_ctxt, NULL, hvm_load_cpu_ctxt, 1,
 
 #define HVM_CPU_XSAVE_SIZE(xcr0) (offsetof(struct hvm_hw_cpu_xsave, \
                                            save_area) + \
-                                  xstate_uncompressed_size(xcr0))
+                                  xstate_uncompressed_size(xcr0 & \
+                                                           ~X86_XSS_STATES))
 
 static int cf_check hvm_save_cpu_xsave_states(
     struct vcpu *v, hvm_domain_context_t *h)
-- 
2.43.0



Ngoc Tu Dinh | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


From xen-devel-bounces@lists.xenproject.org Thu Jan 02 10:20:54 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 10:20:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863827.1275198 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTIJh-0007F8-Ag; Thu, 02 Jan 2025 10:20:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863827.1275198; Thu, 02 Jan 2025 10:20:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTIJh-0007F0-82; Thu, 02 Jan 2025 10:20:37 +0000
Received: by outflank-mailman (input) for mailman id 863827;
 Thu, 02 Jan 2025 10:20:36 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=RDYY=T2=suse.com=jgross@srs-se1.protection.inumbo.net>)
 id 1tTIJg-0007Et-FP
 for xen-devel@lists.xenproject.org; Thu, 02 Jan 2025 10:20:36 +0000
Received: from mail-ed1-x544.google.com (mail-ed1-x544.google.com
 [2a00:1450:4864:20::544])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 33d61b89-c8f3-11ef-a0db-8be0dac302b0;
 Thu, 02 Jan 2025 11:20:34 +0100 (CET)
Received: by mail-ed1-x544.google.com with SMTP id
 4fb4d7f45d1cf-5d8c1950da7so7125124a12.3
 for <xen-devel@lists.xenproject.org>; Thu, 02 Jan 2025 02:20:34 -0800 (PST)
Received: from ?IPV6:2003:e5:8731:2800:842d:42a0:5992:3595?
 (p200300e587312800842d42a059923595.dip0.t-ipconnect.de.
 [2003:e5:8731:2800:842d:42a0:5992:3595])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d80676f3f9sm18151725a12.23.2025.01.02.02.20.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 02 Jan 2025 02:20:33 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 33d61b89-c8f3-11ef-a0db-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1735813234; x=1736418034; darn=lists.xenproject.org;
        h=in-reply-to:autocrypt:from:content-language:references:to:subject
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=sqdjTliz8x0JI3A+pL7Jh6qth4xpjv9uL/9jYPDsECU=;
        b=RzyNz8WPve3vWBWm9Gxkz2jMSQmm4kib4j1hvyx5ACXg14Zgen2Hf2VEYLFdAUheig
         CqYMTJ2TjSMLvUPlKc9+e+7xMLTEz8bdaKH/ChBAySv4HaPNLQ597j8F37zmZpNsmXb1
         XtNdX4xmKVVpaLUXlGf9gIMa5tC+6KMNQYyLk6UDRghVDRkk9rLCGK8GGoOzIjgr3fR0
         X0qGvS5ID9ePDA+pIXioE47gEaqqT1d5xcZFTfj2zP+wkjeEzF8qsd1fri/v1KcYUMbo
         RRIuWncrBAecZ2L5FF9Fmboqfokbw/ilTn15yUI3+kRYD8ymExyFdN/hryjNJMPUysAW
         umWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735813234; x=1736418034;
        h=in-reply-to:autocrypt:from:content-language:references:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=sqdjTliz8x0JI3A+pL7Jh6qth4xpjv9uL/9jYPDsECU=;
        b=vSUAItO4FZVNidiLyZOj7gCEacrWqN+cYsfp+PcdJ0GZXAiNBnem8JbU1l3YbdiGRM
         LJF/wj3Dj16tt3uIj2ewkHNVRBqMf9DjtbZpWQUX5H68Md/wdBT0QENhHT4vV9hOqiQD
         pFlcfCuP4XL8GuC8MeuGKFVcqNNrJbXp06Uyjdfj16CS+EAzwLBUdBgnEOB3af6w+D2s
         9LE/PsMyNP1svZiscAiKdLEQRrhSRUVK2AcUVPWAnxdI69I+YxMQhg8xdWisBBnxSJaL
         EWGKhv2ym1gbk3KLrT9AxbVXOtavlhg+z7rrC/d67yB1DnUugA2JaC+2/pVq8AbQjhzv
         nBeQ==
X-Forwarded-Encrypted: i=1; AJvYcCWlOiGO7Z3/Kzt9obgURD651NxST9K5fDJ9rKL7/EmD+9EzzftzHBRFnfwiKG6skgEpAyUgCXb/j3U=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyUa29vKhsYYdhQRrrHCB5UmbVortkWQbVELfTjRqcHQhKtdzcW
	5fw2J7yYE15T6ALZXldJpuQBdBs/0ieqLmMSdJ29bmXtWptLfHrsVCFxlhoPxok=
X-Gm-Gg: ASbGncv8mheQFYkrnV/9viFKq7xQERnuvNp/qNfnyk04hABZ+8h4v/7ID84BN5ckkvV
	QhTp8QsJcnr87sYzanRoxAnt4SCFSSAXH5TRlFOJakpmkQ/R2DMiCPLIiM3YEUM/SsGnNRNlOce
	VMhQUWqJuPevJN3R+Q4vydHH7sYmlfP90KtEJGNsNAEjwZpk+Rd8VYgLbW1MPC95/gtpBEyxw+f
	BtQX0zdGsrltVe2jeju70uJStow3Gb3i1wIhqYVT5Yx6gi20tbWrGj5DcS+qR+sGl3ZVJP0CfFS
	KPpeTX32IWCMF7hqdVIyujhGyaAESaiTyefTklu5uKEFYCIq+8cYp7jVb26ut611AohyyudRS8f
	mu2NvHA==
X-Google-Smtp-Source: AGHT+IGOWn7PGjKu5Yn+MqKdOPzsT9+UWzhIl5aKvGCaWrw7hnGYDX/oGmBqQBULIqsJTPh9dznG0A==
X-Received: by 2002:a05:6402:43cf:b0:5d3:e79b:3b4c with SMTP id 4fb4d7f45d1cf-5d81de38c50mr37442495a12.31.1735813233856;
        Thu, 02 Jan 2025 02:20:33 -0800 (PST)
Message-ID: <ab9c27d5-f3f2-4b8a-960d-f880ec136199@suse.com>
Date: Thu, 2 Jan 2025 11:20:32 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Linux 6.13-rc3 many different panics in Xen PV dom0
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, xen-devel <xen-devel@lists.xenproject.org>
References: <Z2RGfpJkO0z_nKV6@mail-itl>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <Z2RGfpJkO0z_nKV6@mail-itl>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------ZkX4YxmtK5HygRFUTkc1C7v6"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------ZkX4YxmtK5HygRFUTkc1C7v6
Content-Type: multipart/mixed; boundary="------------yuBunEU0GVh5ayJqrIURRbiN";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, xen-devel <xen-devel@lists.xenproject.org>
Message-ID: <ab9c27d5-f3f2-4b8a-960d-f880ec136199@suse.com>
Subject: Re: Linux 6.13-rc3 many different panics in Xen PV dom0
References: <Z2RGfpJkO0z_nKV6@mail-itl>
In-Reply-To: <Z2RGfpJkO0z_nKV6@mail-itl>

--------------yuBunEU0GVh5ayJqrIURRbiN
Content-Type: multipart/mixed; boundary="------------0REdhiNXmo7DuFBjcIssxewK"

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

T24gMTkuMTIuMjQgMTc6MTQsIE1hcmVrIE1hcmN6eWtvd3NraS1Hw7NyZWNraSB3cm90ZToN
Cj4gSGksDQo+IA0KPiBJdCBjcmFzaGVzIG9uIGJvb3QgbGlrZSBiZWxvdywgbW9zdCBvZiB0
aGUgdGltZXMuIEJ1dCBzb21ldGltZXMgKHJhcmVseSkNCj4gaXQgbWFuYWdlcyB0byBzdGF5
IGFsaXZlLiBCZWxvdyBJJ20gcGFzdGluZyBmZXcgb2YgdGhlIGNyYXNoZXMgdGhhdCBsb29r
DQo+IGRpc3RpbmN0bHkgZGlmZmVyZW50LCBpZiB5b3UgZm9sbG93IHRoZSBsaW5rcywgeW91
IGNhbiBmaW5kIG1vcmUgb2YNCj4gdGhlbS4gSU1ITyBpdCBsb29rcyBsaWtlIHNvbWUgbWVt
b3J5IGNvcnJ1cHRpb24gYnVnIHNvbWV3aGVyZS4gSSB0ZXN0ZWQNCj4gYWxzbyBMaW51eCA2
LjEzLXJjMiBiZWZvcmUsIGFuZCBpdCBoYWQgdmVyeSBzaW1pbGFyIGlzc3VlLg0KDQouLi4N
Cg0KPiANCj4gRnVsbCBsb2c6DQo+IGh0dHBzOi8vb3BlbnFhLnF1YmVzLW9zLm9yZy90ZXN0
cy8xMjI4NzkvbG9nZmlsZT9maWxlbmFtZT1zZXJpYWwwLnR4dA0KDQpJIGNhbiByZXByb2R1
Y2UgYSBjcmFzaCB3aXRoIDYuMTMtcmM1IFBWIGRvbTAuDQoNCldoYXQgaXMgcmVhbGx5IGlu
dGVyZXN0aW5nIGluIHRoZSBsb2dzOiBtb3N0IGNyYXNoZXMgc2VlbSB0byBoYXBwZW4gcmln
aHQNCmFmdGVyIGEgbW9kdWxlIGJlaW5nIGxvYWRlZCAoaW4gbXkgcmVwcm9kdWNlciBpdCB3
YXMgcmlnaHQgYWZ0ZXIgbG9hZGluZw0KdGhlIGZpcnN0IG1vZHVsZSkuDQoNCkkgbmVlZCB0
byBnbyB0aHJvdWdoIHRoZSA2LjEzIGNvbW1pdHMsIGJ1dCBJIHRoaW5rIEkgcmVtZW1iZXIg
aGF2aW5nIHNlZW4NCmEgcGF0Y2ggb3B0aW1pemluZyBtb2R1bGUgbG9hZGluZyBieSB1c2lu
ZyBsYXJnZSBwYWdlcyBmb3IgYWRkcmVzc2luZyB0aGUNCmxvYWRlZCBtb2R1bGVzLiBNYXli
ZSB0aGUgY2FzZSBvZiBubyBsYXJnZSBwYWdlcyBiZWluZyBhdmFpbGFibGUgaXNuJ3QNCmhh
bmRsZWQgcHJvcGVybHkuDQoNCg0KSnVlcmdlbg0K
--------------0REdhiNXmo7DuFBjcIssxewK
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

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

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

--------------0REdhiNXmo7DuFBjcIssxewK--

--------------yuBunEU0GVh5ayJqrIURRbiN--

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

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

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmd2aHEFAwAAAAAACgkQsN6d1ii/Ey/U
Twf/WwTf7BYpogEIyx/Ef91ONjfUyvMKTdeOSRlgTy+TaknGRXSqBGRRPiWqGh4CO8swlvkWRia/
KinUPQgCgemylAdqAnNp2dhri3mK5dtN5Zzy+PS8HtY6Z02UKTunOMTlASEp/LYYz00ksIhI8CMW
IRf9AKypPDDhAMvA1OuLCDMIUEvDJckAzh2DbjAKEHxvy/iG/Ju3C0kCVaZ+/nAuOnH+idnbaehd
YOWQNirsvBOTiBUsNIlfzP0JUJ0cNUNK7zmrxYbl18hLbgcf/DRdueWIG5Z84G5xYP8/ULHsU9Sc
cbI4e9cyC6L4vaHEDzduLJjfpxz3GkJ+0feR0YgCAQ==
=v6B9
-----END PGP SIGNATURE-----

--------------ZkX4YxmtK5HygRFUTkc1C7v6--


From xen-devel-bounces@lists.xenproject.org Thu Jan 02 11:30:33 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 11:30:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863838.1275208 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTJP4-00077Z-BA; Thu, 02 Jan 2025 11:30:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863838.1275208; Thu, 02 Jan 2025 11:30:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTJP4-00077S-8b; Thu, 02 Jan 2025 11:30:14 +0000
Received: by outflank-mailman (input) for mailman id 863838;
 Thu, 02 Jan 2025 11:30:13 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=RDYY=T2=suse.com=jgross@srs-se1.protection.inumbo.net>)
 id 1tTJP3-00077M-ST
 for xen-devel@lists.xenproject.org; Thu, 02 Jan 2025 11:30:13 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id edd7cbac-c8fc-11ef-a0db-8be0dac302b0;
 Thu, 02 Jan 2025 12:30:12 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id 7594B21137;
 Thu,  2 Jan 2025 11:30:11 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 59FC8132EA;
 Thu,  2 Jan 2025 11:30:11 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id 6JAPFMN4dmcJaQAAD6G6ig
 (envelope-from <jgross@suse.com>); Thu, 02 Jan 2025 11:30:11 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: edd7cbac-c8fc-11ef-a0db-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1735817411; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=xyUio7lSk1U6AN0CWOCnh5MTHrtv8WAb4hH4TxOzFMY=;
	b=bz5xvm47c4wpoCQbCQQ9AvxmMgHIDIUDMHLL5x+S2KUfuTztOOHwSwf6tTn0x0n1d+bgds
	O+jg9wcaT+1JXF4M/RAPBcDY1rGqItJKisp+nBRLFIu72FA6sf/SCHwJJTH/h58mmdxZX+
	7lsvzLMYmg0q0voVaUdEqYN9h5HmHio=
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=bz5xvm47
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1735817411; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=xyUio7lSk1U6AN0CWOCnh5MTHrtv8WAb4hH4TxOzFMY=;
	b=bz5xvm47c4wpoCQbCQQ9AvxmMgHIDIUDMHLL5x+S2KUfuTztOOHwSwf6tTn0x0n1d+bgds
	O+jg9wcaT+1JXF4M/RAPBcDY1rGqItJKisp+nBRLFIu72FA6sf/SCHwJJTH/h58mmdxZX+
	7lsvzLMYmg0q0voVaUdEqYN9h5HmHio=
Message-ID: <6bb03333-74ca-4c2c-85a8-72549b85a5b4@suse.com>
Date: Thu, 2 Jan 2025 12:30:10 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Linux 6.13-rc3 many different panics in Xen PV dom0
From: Juergen Gross <jgross@suse.com>
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, xen-devel <xen-devel@lists.xenproject.org>
References: <Z2RGfpJkO0z_nKV6@mail-itl>
 <ab9c27d5-f3f2-4b8a-960d-f880ec136199@suse.com>
Content-Language: en-US
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <ab9c27d5-f3f2-4b8a-960d-f880ec136199@suse.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------yGxS3TVPBwNB5uOZcFX5nauL"
X-Rspamd-Queue-Id: 7594B21137
X-Spam-Level: 
X-Spamd-Result: default: False [-6.41 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SIGNED_PGP(-2.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain];
	R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_BASE64_TEXT(0.10)[];
	MIME_UNKNOWN(0.10)[application/pgp-keys];
	MX_GOOD(-0.01)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ASN(0.00)[asn:25478, ipnet:::/0, country:RU];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~];
	DKIM_TRACE(0.00)[suse.com:+];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	MID_RHS_MATCH_FROM(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_DN_ALL(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	HAS_ATTACHMENT(0.00)[]
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Rspamd-Action: no action
X-Spam-Score: -6.41
X-Spam-Flag: NO

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------yGxS3TVPBwNB5uOZcFX5nauL
Content-Type: multipart/mixed; boundary="------------h2fdSkqB4zp6tCOCDgoUle7n";
 protected-headers="v1"
From: Juergen Gross <jgross@suse.com>
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, xen-devel <xen-devel@lists.xenproject.org>
Message-ID: <6bb03333-74ca-4c2c-85a8-72549b85a5b4@suse.com>
Subject: Re: Linux 6.13-rc3 many different panics in Xen PV dom0
References: <Z2RGfpJkO0z_nKV6@mail-itl>
 <ab9c27d5-f3f2-4b8a-960d-f880ec136199@suse.com>
In-Reply-To: <ab9c27d5-f3f2-4b8a-960d-f880ec136199@suse.com>

--------------h2fdSkqB4zp6tCOCDgoUle7n
Content-Type: multipart/mixed; boundary="------------NaGY6z04VntU0UMIrtOt4oCn"

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

T24gMDIuMDEuMjUgMTE6MjAsIErDvHJnZW4gR3Jvw58gd3JvdGU6DQo+IE9uIDE5LjEyLjI0
IDE3OjE0LCBNYXJlayBNYXJjenlrb3dza2ktR8OzcmVja2kgd3JvdGU6DQo+PiBIaSwNCj4+
DQo+PiBJdCBjcmFzaGVzIG9uIGJvb3QgbGlrZSBiZWxvdywgbW9zdCBvZiB0aGUgdGltZXMu
IEJ1dCBzb21ldGltZXMgKHJhcmVseSkNCj4+IGl0IG1hbmFnZXMgdG8gc3RheSBhbGl2ZS4g
QmVsb3cgSSdtIHBhc3RpbmcgZmV3IG9mIHRoZSBjcmFzaGVzIHRoYXQgbG9vaw0KPj4gZGlz
dGluY3RseSBkaWZmZXJlbnQsIGlmIHlvdSBmb2xsb3cgdGhlIGxpbmtzLCB5b3UgY2FuIGZp
bmQgbW9yZSBvZg0KPj4gdGhlbS4gSU1ITyBpdCBsb29rcyBsaWtlIHNvbWUgbWVtb3J5IGNv
cnJ1cHRpb24gYnVnIHNvbWV3aGVyZS4gSSB0ZXN0ZWQNCj4+IGFsc28gTGludXggNi4xMy1y
YzIgYmVmb3JlLCBhbmQgaXQgaGFkIHZlcnkgc2ltaWxhciBpc3N1ZS4NCj4gDQo+IC4uLg0K
PiANCj4+DQo+PiBGdWxsIGxvZzoNCj4+IGh0dHBzOi8vb3BlbnFhLnF1YmVzLW9zLm9yZy90
ZXN0cy8xMjI4NzkvbG9nZmlsZT9maWxlbmFtZT1zZXJpYWwwLnR4dA0KPiANCj4gSSBjYW4g
cmVwcm9kdWNlIGEgY3Jhc2ggd2l0aCA2LjEzLXJjNSBQViBkb20wLg0KPiANCj4gV2hhdCBp
cyByZWFsbHkgaW50ZXJlc3RpbmcgaW4gdGhlIGxvZ3M6IG1vc3QgY3Jhc2hlcyBzZWVtIHRv
IGhhcHBlbiByaWdodA0KPiBhZnRlciBhIG1vZHVsZSBiZWluZyBsb2FkZWQgKGluIG15IHJl
cHJvZHVjZXIgaXQgd2FzIHJpZ2h0IGFmdGVyIGxvYWRpbmcNCj4gdGhlIGZpcnN0IG1vZHVs
ZSkuDQo+IA0KPiBJIG5lZWQgdG8gZ28gdGhyb3VnaCB0aGUgNi4xMyBjb21taXRzLCBidXQg
SSB0aGluayBJIHJlbWVtYmVyIGhhdmluZyBzZWVuDQo+IGEgcGF0Y2ggb3B0aW1pemluZyBt
b2R1bGUgbG9hZGluZyBieSB1c2luZyBsYXJnZSBwYWdlcyBmb3IgYWRkcmVzc2luZyB0aGUN
Cj4gbG9hZGVkIG1vZHVsZXMuIE1heWJlIHRoZSBjYXNlIG9mIG5vIGxhcmdlIHBhZ2VzIGJl
aW5nIGF2YWlsYWJsZSBpc24ndA0KPiBoYW5kbGVkIHByb3Blcmx5Lg0KDQpTZWVtcyBJIHdh
cyByaWdodC4NCg0KRm9yIG1lIHRoZSBmb2xsb3dpbmcgZGlmZiBmaXhlcyB0aGUgaXNzdWUu
IE1hcmVrLCBjYW4geW91IHBsZWFzZSBjb25maXJtDQppdCBmaXhlcyB5b3VyIGNyYXNoZXMs
IHRvbz8NCg0KZGlmZiAtLWdpdCBhL2FyY2gveDg2L21tL2luaXQuYyBiL2FyY2gveDg2L21t
L2luaXQuYw0KaW5kZXggYzZkMjlmMjgzMDAxLi5iNWI3OTY0YjM0YjAgMTAwNjQ0DQotLS0g
YS9hcmNoL3g4Ni9tbS9pbml0LmMNCisrKyBiL2FyY2gveDg2L21tL2luaXQuYw0KQEAgLTEw
ODAsNyArMTA4MCw3IEBAIHN0cnVjdCBleGVjbWVtX2luZm8gX19pbml0ICpleGVjbWVtX2Fy
Y2hfc2V0dXAodm9pZCkNCg0KICAgICAgICAgc3RhcnQgPSBNT0RVTEVTX1ZBRERSICsgb2Zm
c2V0Ow0KDQotICAgICAgIGlmIChJU19FTkFCTEVEKENPTkZJR19BUkNIX0hBU19FWEVDTUVN
X1JPWCkpIHsNCisgICAgICAgaWYgKElTX0VOQUJMRUQoQ09ORklHX0FSQ0hfSEFTX0VYRUNN
RU1fUk9YKSAmJiANCmNwdV9mZWF0dXJlX2VuYWJsZWQoWDg2X0ZFQVRVUkVfUFNFKSkgew0K
ICAgICAgICAgICAgICAgICBwZ3Byb3QgPSBQQUdFX0tFUk5FTF9ST1g7DQogICAgICAgICAg
ICAgICAgIGZsYWdzID0gRVhFQ01FTV9LQVNBTl9TSEFET1cgfCBFWEVDTUVNX1JPWF9DQUNI
RTsNCiAgICAgICAgIH0gZWxzZSB7DQoNCg0KSnVlcmdlbg0K
--------------NaGY6z04VntU0UMIrtOt4oCn
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

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

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

--------------NaGY6z04VntU0UMIrtOt4oCn--

--------------h2fdSkqB4zp6tCOCDgoUle7n--

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

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

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmd2eMIFAwAAAAAACgkQsN6d1ii/Ey+8
pQf8DCTYKUxyaoIRjC55vU+DBj+EQgnhQ0JuRyjUeBcitWLWLDppodrSOUBAFvkI6Vr05+QoaUPv
3HR5JSrZhHE4YXC25CBoIrhtg6WW93QZnGjWN8Wj2tjKcaRlvDn3xhRVHpo0m0UUlzZUawxjSFot
W3o/MFJ9XJkqMWUQjYe7dUcVqPMhWTJ55kIS0C29kwEZKgv248ocpukZIVSKt0qmnef0jZpMwcbz
qVtqEn/jH+CBcIPc47jIVJcusJwUXPX8BtR0s+LWQeQZrmtUGtj84xD2r82dLYcAPiMNh/XMj/t/
uHHIfpw8T1Ir0+Vs54kAbFt7wvSwzuaT9e07aAh7ow==
=ON5l
-----END PGP SIGNATURE-----

--------------yGxS3TVPBwNB5uOZcFX5nauL--


From xen-devel-bounces@lists.xenproject.org Thu Jan 02 12:08:08 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 12:08:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863849.1275219 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTJzc-0002rN-1r; Thu, 02 Jan 2025 12:08:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863849.1275219; Thu, 02 Jan 2025 12:08:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTJzb-0002rF-Tx; Thu, 02 Jan 2025 12:07:59 +0000
Received: by outflank-mailman (input) for mailman id 863849;
 Thu, 02 Jan 2025 12:07: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 <SRS0=RDYY=T2=suse.com=jgross@srs-se1.protection.inumbo.net>)
 id 1tTJzb-0002r4-9q
 for xen-devel@lists.xen.org; Thu, 02 Jan 2025 12:07:59 +0000
Received: from mail-ed1-x544.google.com (mail-ed1-x544.google.com
 [2a00:1450:4864:20::544])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 34008577-c902-11ef-99a4-01e77a169b0f;
 Thu, 02 Jan 2025 13:07:57 +0100 (CET)
Received: by mail-ed1-x544.google.com with SMTP id
 4fb4d7f45d1cf-5d3f65844deso18542641a12.0
 for <xen-devel@lists.xen.org>; Thu, 02 Jan 2025 04:07:57 -0800 (PST)
Received: from ?IPV6:2003:e5:8731:2800:842d:42a0:5992:3595?
 (p200300e587312800842d42a059923595.dip0.t-ipconnect.de.
 [2003:e5:8731:2800:842d:42a0:5992:3595])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d806fedc68sm18777651a12.66.2025.01.02.04.07.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 02 Jan 2025 04:07:56 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 34008577-c902-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1735819677; x=1736424477; darn=lists.xen.org;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=pTdwL/KCe5Pn5t5XFHub7/aoY3sfOr8iS3jCq36ZaYs=;
        b=RLRjSRaEqsmzMR8/V92+aNritVFne3F+tScVh/UCUnvo2oD93oZzsVOJ+kiBYFdWGq
         TxRvDTb16VwCnyIBXZ+nDLM4xXzARrChAjy7jKxrH3ji2zVsMS9xYgcNSfBRdJ2IdVWJ
         IoebQg7EukOOvsYpU+M1J5Wmva77Ppa25fFV3PL4GAQBCUUDfF10/xiEev9SINg3sEeg
         Ft6V+c237u5XBxRYcW40Sphb6Jr7/B/zSdPV2j2Xrv3EbOkhzNdZCjA4wXwA4X4lS40o
         DmxUX2BpAP9Q78+A34qcbdkbfWpYwmer37V/lNq7ByH0hbhjvuPL6LSQHnN5JL0mRwQj
         +ZlA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735819677; x=1736424477;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=pTdwL/KCe5Pn5t5XFHub7/aoY3sfOr8iS3jCq36ZaYs=;
        b=ZExvME3+XSzBwxWl19wPMN5SdiBm53Bb6yoWsuxXhiubOLmNL7EkS0JpNFqnpk+ZgY
         2iNU/rmrtetXyihwhmvboDIoYKmt+L5pxzohdUgcKnomELJNStQ7hZ2B65vtk7NGEg17
         3d1XD2/u68ztJ7VtKP/2A4GPtDg7MKaebpDrNhGd/RCmLzuVrhq0+hwxx3y/48Xla1Z6
         MDFVUkPQ1FXI5xx/uerU32ry18h/2X8NQu0xVq2vvr7ND9FnJd+gHvatwe1n8EN0tyI6
         OVDiORg+h+UgMrurjUsxCURg9czqUwDJUK6z8lHrKGSxicJWYucLB/yrtGZ0es1PGqLX
         LEGw==
X-Forwarded-Encrypted: i=1; AJvYcCXv/Uag/9tDjcdjQjMrLbUTFdNU+S3IIoM692ZChaRJdR2C0ohMpQizKF8tYZpvrVtOWyz8hMqzjFg=@lists.xen.org
X-Gm-Message-State: AOJu0YymTQz2keg4Qmjt04C2Uf+5YctUAs5h8bGskZL1RkEFh1+7HWRB
	7P+TTjqmK/ucbZzNLqhC/RQX3LjTrxOo5aC9Hux08qzi2/H6q4ycgv6joHwftIc=
X-Gm-Gg: ASbGncvE6jS+ZFrU3sF0wttDoNSA9DLyIC5AM/zfa5UQD9xUDJbUm4Lfp65KQx545Xi
	NZBuG/PhzSDYwFGxd1cQQ/mpq3L9xrskceNEREPHMO3pYmS55k3qujeIhPS/7B1c9Yp9Id6AK1c
	A7n5JTc0+oYUqkv1B6KdGlrc1uzcVfDNXuVMHvCEiXjXkHxBQHg3GwUYN+lvE66NZVIgHHWJg6f
	YdRecj4MYhIHfns0wKIIpUCl2fiI9bTagpYsdoQi9UXfzS9trrdsxq8vNvDTNtGewLBLQtsrvDx
	jTa8y/2zMTDD0YWxUXzFPeuZI68BEKORHiyrrZfU1JJCY75cOql+bp31itxh4NNvuIa5iIimTBx
	7tqW/2Q==
X-Google-Smtp-Source: AGHT+IHL12MxRnBiagIn4NAHb2yoVccPRle7YHvncCvPEC7pBBtxAGV2hQpGMNzf7ulAq1dVAYiKkQ==
X-Received: by 2002:a50:cc04:0:b0:5d8:a46f:110b with SMTP id 4fb4d7f45d1cf-5d8a46f1123mr17548310a12.17.1735819676532;
        Thu, 02 Jan 2025 04:07:56 -0800 (PST)
Message-ID: <a3031e7d-fe9d-4db8-8ccd-923165c9af72@suse.com>
Date: Thu, 2 Jan 2025 13:07:55 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Xen Security Advisory 466 v3 (CVE-2024-53241) - Xen hypercall
 page unsafe against speculative attacks
To: David Woodhouse <dwmw2@infradead.org>,
 "Xen.org security team" <security@xen.org>, xen-announce@lists.xen.org,
 xen-devel@lists.xen.org, xen-users@lists.xen.org,
 oss-security@lists.openwall.com
Cc: "Xen.org security team" <security-team-members@xen.org>
References: <E1tNWXG-00E268-2p@xenbits.xenproject.org>
 <54c892eded2b4ebdda8ee1085c383178f44414ad.camel@infradead.org>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <54c892eded2b4ebdda8ee1085c383178f44414ad.camel@infradead.org>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------d5C5ixIhUlO7wPMZWJ3AvT0M"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------d5C5ixIhUlO7wPMZWJ3AvT0M
Content-Type: multipart/mixed; boundary="------------3DtLA5VgbWMlh1ZUA0LYmvrT";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: David Woodhouse <dwmw2@infradead.org>,
 "Xen.org security team" <security@xen.org>, xen-announce@lists.xen.org,
 xen-devel@lists.xen.org, xen-users@lists.xen.org,
 oss-security@lists.openwall.com
Cc: "Xen.org security team" <security-team-members@xen.org>
Message-ID: <a3031e7d-fe9d-4db8-8ccd-923165c9af72@suse.com>
Subject: Re: Xen Security Advisory 466 v3 (CVE-2024-53241) - Xen hypercall
 page unsafe against speculative attacks
References: <E1tNWXG-00E268-2p@xenbits.xenproject.org>
 <54c892eded2b4ebdda8ee1085c383178f44414ad.camel@infradead.org>
In-Reply-To: <54c892eded2b4ebdda8ee1085c383178f44414ad.camel@infradead.org>
Autocrypt-Gossip: addr=security@xen.org; keydata=
 xsBNBE+hNqgBCADYua5OFR0/Jeu0rByk+Obk6+SewIeGej1FAcjo+Cvpcr1dfnLBAhmmhbfM
 b++qr6SG6Ek+cUQogYAFvZcEcusbRPy4MIzJkqoPSyOUhCxZoxWNWUfhDdt0TWA3Hs1vYmFO
 e+2jvlL3h7yAsGMYO8jo6ow8ceBEOmf8Q5BLq2OPkNpGcaHEhbSv0VZ3mdHM30ynY6GubIws
 c68LZ5hTORTSjKaj2WVCe4OorBMZte5Im+6MOEUbCjynqPJSU9KNFhIhUuyXp1vn0gZ2N5QS
 pkghpzBJLzeBNEI6ecV3Q0p+/pq8EvEAuUSNLUEbIZ/NSLqyTVMc9HZxnPu59im8wB9rABEB
 AAHNK1hlbi5vcmcgKGluY29taW5nIGVtYWlsKSA8c2VjdXJpdHlAeGVuLm9yZz7CwHgEEwEC
 ACIFAk+hNqgCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEHQ6P8qC06lk1y0H/2Pj
 jQyPDZVS4zIVnR4xQOQ1KphPCdSTPlhj+VVrjZZNXWGCUKvJShL84XIONH62fIgQE/6CTWXJ
 tx6i4u1oAtFH4+8HayFjg609lxx9frJ4tJkJitw5TT6VEGAambchIG5QaP9hepgyrVXjQ0X2
 ot0jgpwL6G3sx0L1gewiMALXtGT6oTqLjXius/nv69yRe26wxU1GX80oWWH/5p585xt54C1X
 nhDEVzp0S9UW7VAAVDCWuSefSrihh3jZi4QE1fnGRwO0RfeLh1sXeuMn9uFIz0CmaCbAp5Pe
 UyNb6wgG60h4JLCDyhJntoHfq8pQLEJ8G9nvjDfw8BLvkBKYNvbOwE0ET6E2qAEIALqWNlGF
 d3uIj+DXZ40/i7fsoPb+HaYaG6Y+7+ZWxMxUeQDTLBnTYiAa+EGVutc4v52BXH8RZc9I/NH9
 lBT2/AwaEVSomxLicbixXUGoFC9kMp/VP1xwWJ+gm+ZEnQzY+2AFJGMvqEsGocQA7yLw121J
 UOrorny3CqpHykPUF3fqp4n/GL47VTaKxlsoV8o2JgZZ62NJlkBtnbA4ODzhWr6cA21smWFg
 sfFJ+EkXb1NEeYLs8CWtTn2EiQXlZTQ8OgBPahfvLZ+AJ4sM/Raoi2c3UIQrlCsg9BoojKMk
 Li8XUrywr8HEJYjhBYObCgbmaeIEfmrw5XJqOKlMg40XY+MAEQEAAcLAXwQYAQIACQUCT6E2
 qAIbDAAKCRB0Oj/KgtOpZDhJB/0XtxrlVuRttpjK1PEYK/A/9h47VH9p0UvVYCH+ZS2a+sTg
 sapx0zp4uni8wtytkvGw/EM06D4ZoaWAUcjXILNKGdi62q/z+WAfdEY/WrONxAbr2Dtv/LT0
 0/2nifYU9O1vGYS1Kx/B3D8fU0w+2Sjv+hYjbGDWn619etC8dNEIxczH6V/cVOZf0D2KhoBf
 MCHUoKeuAfaIKDMxOZjb7sajfUW70cxFFWYqH96Py01oxDroOKzy0x62iVdsYFGB3FvcD9tD
 WsxVWwGHA8DKEfKMuNPiuapzdxdrNm5AQilSUlfD65KK9d3kQdoOUPdPWoIQnz8GnHMPDe99
 7SuwxWGb

--------------3DtLA5VgbWMlh1ZUA0LYmvrT
Content-Type: multipart/mixed; boundary="------------0eWtS0PUDjsTPP5cJ7jLipMV"

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

T24gMjMuMTIuMjQgMTU6MjQsIERhdmlkIFdvb2Rob3VzZSB3cm90ZToNCj4gT24gVHVlLCAy
MDI0LTEyLTE3IGF0IDEyOjE4ICswMDAwLCBYZW4ub3JnIHNlY3VyaXR5IHRlYW0gd3JvdGU6
DQo+PiAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFhlbiBTZWN1cml0eSBBZHZpc29yeSBD
VkUtMjAyNC01MzI0MSAvIFhTQS00NjYNCj4+ICDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB2ZXJzaW9uIDMNCj4+DQo+
PiAgwqDCoMKgwqDCoMKgwqDCoCBYZW4gaHlwZXJjYWxsIHBhZ2UgdW5zYWZlIGFnYWluc3Qg
c3BlY3VsYXRpdmUgYXR0YWNrcw0KPj4NCj4+IFVQREFURVMgSU4gVkVSU0lPTiAzDQo+PiA9
PT09PT09PT09PT09PT09PT09PQ0KPj4NCj4+IFVwZGF0ZSBvZiBwYXRjaCA1LCBwdWJsaWMg
cmVsZWFzZS4NCj4gDQo+IENhbid0IHdlIGV2ZW4gdXNlIHRoZSBoeXBlcmNhbGwgcGFnZSBl
YXJseSBpbiBib290PyBTdXJlbHkgd2UgaGF2ZSB0bw0KPiBrbm93IHdoZXRoZXIgd2UncmUg
cnVubmluZyBvbiBhbiBJbnRlbCBvciBBTUQgQ1BVIGJlZm9yZSB3ZSBnZXQgdG8gdGhlDQo+
IHBvaW50IHdoZXJlIHdlIGNhbiBlbmFibGUgYW55IG9mIHRoZSBuZXcgY29udHJvbC1mbG93
IGludGVncml0eQ0KPiBzdXBwb3J0PyBEbyB3ZSBuZWVkIHRvIGp1bXAgdGhyb3VnaCB0aG9z
ZSBob29wcyBkbyBkbyB0aGF0IGVhcmx5DQo+IGRldGVjdGlvbiBhbmQgc2V0dXA/DQoNClRo
ZSBkb3duc2lkZSBvZiB0aGlzIGFwcHJvYWNoIHdvdWxkIGJlIHRvIGhhdmUgYW5vdGhlciB2
YXJpYW50IHRvIGRvDQpoeXBlcmNhbGxzLiBTbyB5b3UnZCBoYXZlIHRvIHJlcGxhY2UgdGhl
IHZhcmlhbnQgYmVpbmcgYWJsZSB0byB1c2UgQU1EDQpvciBJTlRFTCBzcGVjaWZpYyBpbnN0
cnVjdGlvbnMgd2l0aCBhIGZ1bmN0aW9uIGRvaW5nIHRoZSBoeXBlcmNhbGwgdmlhDQp0aGUg
aHlwZXJjYWxsIHBhZ2UuDQoNCkknbSBwbGFubmluZyB0byBzZW5kIHBhdGNoZXMgZm9yIFhl
biBhbmQgdGhlIGtlcm5lbCB0byBhZGQgQ1BVSUQgZmVhdHVyZQ0KYml0cyBpbmRpY2F0aW5n
IHdoaWNoIGluc3RydWN0aW9uIHRvIHVzZS4gVGhpcyB3aWxsIG1ha2UgbGlmZSBtdWNoIGVh
c2llci4NCg0KPiBFbmFibGluZyB0aGUgaHlwZXJjYWxsIHBhZ2UgaXMgYWxzbyBvbmUgb2Yg
dGhlIHR3byBwb2ludHMgd2hlcmUgWGVuDQo+IHdpbGwgJ2xhdGNoJyB0aGF0IHRoZSBndWVz
dCBpcyA2NC1iaXQsIHdoaWNoIGFmZmVjdHMgdGhlIGxheW91dCBvZiB0aGUNCj4gc2hhcmVk
X2luZm8sIHZjcHVfaW5mbyBhbmQgcnVuc3RhdGUgc3RydWN0dXJlcy4NCj4gDQo+IFRoZSBv
dGhlciBzdWNoIGxhdGNoaW5nIHBvaW50IGlzIHdoZW4gdGhlIGd1ZXN0IHNldHMNCj4gSFZN
X1BBUkFNX0NBTExCQUNLX0lSUSwgYW5kIEkgKnRoaW5rKiB0aGF0IHNob3VsZCB3b3JrIGlu
IGFsbA0KPiBpbXBsZW1lbnRhdGlvbnMgb2YgdGhlIFhlbiBBQkkgKGluY2x1ZGluZyBRRU1V
L0tWTSBhbmQgRUMyKS4gQnV0IHdvdWxkDQo+IHdhbnQgdG8gdGVzdC4NCj4gDQo+IEJ1dCBw
ZXJoYXBzIGl0IHdvdWxkbid0IGh1cnQgZm9yIG1heGltYWwgY29tcGF0aWJpbGl0eSBmb3Ig
TGludXggdG8gc2V0DQo+IHRoZSBoeXBlcmNhbGwgcGFnZSAqYW55d2F5KiwgZXZlbiBpZiBM
aW51eCBkb2Vzbid0IHRoZW4gdXNlIGl0IOKAlCBvcg0KPiBvbmx5IHVzZXMgaXQgZHVyaW5n
IGVhcmx5IGJvb3Q/DQoNCkknbSBzZWVpbmcgcG90ZW50aWFsIHByb2JsZW1zIHdpdGggdGhh
dCBhcHByb2FjaCB3aGVuIHNvbWVvbmUgaXMgdXNpbmcNCmFuIG91dC1vZi10cmVlIG1vZHVs
ZSBkb2luZyBoeXBlcmNhbGxzLg0KDQpXaXRoIGhhdmluZyB0aGUgaHlwZXJjYWxsIHBhZ2Ug
cHJlc2VudCBzdWNoIGEgbW9kdWxlIHdvdWxkIGFkZCBhIHdheSB0byBkbw0Kc3BlY3VsYXRp
dmUgYXR0YWNrcywgd2hpbGUgZGVsZXRpbmcgdGhlIGh5cGVyY2FsbCBwYWdlIHdvdWxkIHJl
c3VsdCBpbiBhDQpmYWlsdXJlIHRyeWluZyB0byBsb2FkIHN1Y2ggYSBtb2R1bGUuDQoNCg0K
SnVlcmdlbg0K
--------------0eWtS0PUDjsTPP5cJ7jLipMV
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

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

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

--------------0eWtS0PUDjsTPP5cJ7jLipMV--

--------------3DtLA5VgbWMlh1ZUA0LYmvrT--

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

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

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmd2gZsFAwAAAAAACgkQsN6d1ii/Ey9B
3Af/fsSbEMj2KVLFyk4HNbmstc4UiK+Ynscvf/qTeZbNJCG2tJWv26stp7HDD/Croie6W4Uxts+K
Cs84SZd3pJZmjZOuar8/BIcV1ZigCSPVYIORTXNLwjQ/oFIEWbbbArYDiwKAGGX32Z6o5965NP/9
JvSyMj1ATMEFvkxv6vgT6PtV0VKQBPOU6Ponk/RBtTaWgiP5PeKrRMtb7IArVXfZ84s9UtOkPfk9
e4JFjJT+Vk2GRVUp1pnP9LzLik88z7ZWoYgGnmhK8kXLbOuEZcmkseRnmdNWpHW59T2Z61/LqQJU
UzafsAbbu1Jk+eHVmIC1nmT7Rq1Wt0+T+xz6d8TpvA==
=M+/n
-----END PGP SIGNATURE-----

--------------d5C5ixIhUlO7wPMZWJ3AvT0M--


From xen-devel-bounces@lists.xenproject.org Thu Jan 02 12:24:37 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 12:24:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863905.1275257 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTKFZ-0007tE-Oo; Thu, 02 Jan 2025 12:24:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863905.1275257; Thu, 02 Jan 2025 12:24:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTKFZ-0007t7-Lk; Thu, 02 Jan 2025 12:24:29 +0000
Received: by outflank-mailman (input) for mailman id 863905;
 Thu, 02 Jan 2025 12:24:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=4GO/=T2=invisiblethingslab.com=marmarek@srs-se1.protection.inumbo.net>)
 id 1tTKFY-0007t1-IE
 for xen-devel@lists.xenproject.org; Thu, 02 Jan 2025 12:24:28 +0000
Received: from fhigh-a7-smtp.messagingengine.com
 (fhigh-a7-smtp.messagingengine.com [103.168.172.158])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 811da116-c904-11ef-a0db-8be0dac302b0;
 Thu, 02 Jan 2025 13:24:26 +0100 (CET)
Received: from phl-compute-04.internal (phl-compute-04.phl.internal
 [10.202.2.44])
 by mailfhigh.phl.internal (Postfix) with ESMTP id E38CF11400BC;
 Thu,  2 Jan 2025 07:24:24 -0500 (EST)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-04.internal (MEProxy); Thu, 02 Jan 2025 07:24:24 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 2 Jan 2025 07:24:24 -0500 (EST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 811da116-c904-11ef-a0db-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm2; t=1735820664;
	 x=1735907064; bh=sT6GYu4RKbwEh2Bxw3mOGQTmqoX/hrid1Bfzn7Q27fc=; b=
	qHrUvl8h+qx7NT9jBEJzr6Tb5szhtW2oZoyomt7jGEO0GSgv5p2rNXZuiNRMUnWa
	G46ylVLe+YXkwK3OGTTQuhpGPhzapvealxWj1Jbq/6EabbieI0RNdfZwlhhmDHXy
	NyM9mWQai56hd3RFJwz9wdvfNQ9arhrztE+pWcV0bHURDz0893t4CRvx8xCfBLcV
	yREOpb7m2eG49q6wD9eIppHQIHOj9+qrojJV9LitfqpMkXkPXEhMXH7+xi/4KC1E
	suWeFfrOPs4ddpGk8dHqluLZcxOqMVoq5sBVVmkHSlhjdhF5Zd7Bc1zgVOrF28N7
	PlrTZufp4jBy5l3nBiUQ7A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:subject:subject:to
	:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=
	1735820664; x=1735907064; bh=sT6GYu4RKbwEh2Bxw3mOGQTmqoX/hrid1Bf
	zn7Q27fc=; b=fuDfWONm+zD7qGZ+MEFr2X6L7+dtQ0kiWgqBxfFAB0T5Hi46q4L
	X0r8lt7nXwMMQ+jwxeRy7e7TaUEvYYwvjZi11pOiFZfS6jcFESGHg4h8j3TRe8uD
	GF9+E7RHdkot+091UzFJIrXAMcGOdgD9Uvb0/SJo2+dYY91duExY3KsMvidSK22U
	ZhI1NN2KUpwx7cgSmVeY4EqGxKD325b8VkquTJMaeq5C1QT+IMkuKRNjX2bYEhxK
	Fly94VCOOvzb6TT/sVVlPZdY4o1r7eZkN5eULgUlES9/ANDFJDZvuVXwMicCYXfr
	+6r5Gk3NVeqVkJOrv2VarsN4l35UjITOLYA==
X-ME-Sender: <xms:eIV2Z64pFV1ufUXfQQELpslxlDCVp3fxUgNJKRDzgKQ6y7Bs3Dh9zQ>
    <xme:eIV2Zz4v0z0CpAFUnGAZvz8af1JnLqU2sktvN4Zl2O7c8mXWhQ707m8wfRD0v2pks
    AGyFshL9pW6tw>
X-ME-Received: <xmr:eIV2Z5cp5Ve_xS7xsTGXItBCjM8bv-P7NmOfkxdrYLRB1IhWzzEEe7YYfIQ9FsbJAht5t2_JH4lRTuHaPW5Wt62FqRWz9iCLOg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrudefvddggeduucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
    rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
    htshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtjeen
    ucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomh
    grrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggft
    rfgrthhtvghrnhepjeejgfekudegheeivdeiffdvffegteektdfhudeljeeikefhteefke
    efgffgieegnecuffhomhgrihhnpehquhgsvghsqdhoshdrohhrghdpghhithhhuhgsrdgt
    ohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmh
    grrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnhgspghr
    tghpthhtohepvddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepjhhgrhhoshhsse
    hsuhhsvgdrtghomhdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghn
    phhrohhjvggtthdrohhrgh
X-ME-Proxy: <xmx:eIV2Z3LLB97IY1kNM4tf-LyXhx052Lxm1j2US8sJkOsj7YseUgXHXQ>
    <xmx:eIV2Z-LPdS8z7EQhby8PnaAX71W6RVjocIMz5OZmCg_pNmSCWFysJg>
    <xmx:eIV2Z4wrLS_XqptbkSjXoSaMGbkbOROZaYn9myJSz6r8gzTMEnnCRA>
    <xmx:eIV2ZyLkCKtRq466o-Sc0ILQzJ5SG_mnsFPPk62DTlaZywxeHd-_ww>
    <xmx:eIV2Z1U3wnDXHGEKcfNSRgMA2QKioAVCoOx3uTO5mRYkVVV_dr4mfwNc>
Feedback-ID: i1568416f:Fastmail
Date: Thu, 2 Jan 2025 13:24:21 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Juergen Gross <jgross@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: Linux 6.13-rc3 many different panics in Xen PV dom0
Message-ID: <Z3aFdrygLF9yK2EK@mail-itl>
References: <Z2RGfpJkO0z_nKV6@mail-itl>
 <ab9c27d5-f3f2-4b8a-960d-f880ec136199@suse.com>
 <6bb03333-74ca-4c2c-85a8-72549b85a5b4@suse.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="E+iv+cIVVBOtIZKv"
Content-Disposition: inline
In-Reply-To: <6bb03333-74ca-4c2c-85a8-72549b85a5b4@suse.com>


--E+iv+cIVVBOtIZKv
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Thu, 2 Jan 2025 13:24:21 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Juergen Gross <jgross@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: Linux 6.13-rc3 many different panics in Xen PV dom0

On Thu, Jan 02, 2025 at 12:30:10PM +0100, Juergen Gross wrote:
> On 02.01.25 11:20, J=C3=BCrgen Gro=C3=9F wrote:
> > On 19.12.24 17:14, Marek Marczykowski-G=C3=B3recki wrote:
> > > Hi,
> > >=20
> > > It crashes on boot like below, most of the times. But sometimes (rare=
ly)
> > > it manages to stay alive. Below I'm pasting few of the crashes that l=
ook
> > > distinctly different, if you follow the links, you can find more of
> > > them. IMHO it looks like some memory corruption bug somewhere. I test=
ed
> > > also Linux 6.13-rc2 before, and it had very similar issue.
> >=20
> > ...
> >=20
> > >=20
> > > Full log:
> > > https://openqa.qubes-os.org/tests/122879/logfile?filename=3Dserial0.t=
xt
> >=20
> > I can reproduce a crash with 6.13-rc5 PV dom0.
> >=20
> > What is really interesting in the logs: most crashes seem to happen rig=
ht
> > after a module being loaded (in my reproducer it was right after loading
> > the first module).
> >=20
> > I need to go through the 6.13 commits, but I think I remember having se=
en
> > a patch optimizing module loading by using large pages for addressing t=
he
> > loaded modules. Maybe the case of no large pages being available isn't
> > handled properly.
>=20
> Seems I was right.
>=20
> For me the following diff fixes the issue. Marek, can you please confirm
> it fixes your crashes, too?

Thanks for looking into it!
Will do, I've pushed it to
https://github.com/QubesOS/qubes-linux-kernel/pull/662, CI will build it
and then I'll post it to openQA.

> diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
> index c6d29f283001..b5b7964b34b0 100644
> --- a/arch/x86/mm/init.c
> +++ b/arch/x86/mm/init.c
> @@ -1080,7 +1080,7 @@ struct execmem_info __init *execmem_arch_setup(void)
>=20
>         start =3D MODULES_VADDR + offset;
>=20
> -       if (IS_ENABLED(CONFIG_ARCH_HAS_EXECMEM_ROX)) {
> +       if (IS_ENABLED(CONFIG_ARCH_HAS_EXECMEM_ROX) &&
> cpu_feature_enabled(X86_FEATURE_PSE)) {
>                 pgprot =3D PAGE_KERNEL_ROX;
>                 flags =3D EXECMEM_KASAN_SHADOW | EXECMEM_ROX_CACHE;
>         } else {
>=20
>=20
> Juergen






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

--E+iv+cIVVBOtIZKv
Content-Type: application/pgp-signature; name="signature.asc"

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmd2hXYACgkQ24/THMrX
1yyDCgf8C8BVaZuF0fbcizTHlH7K7trka2LD7itMGWdEEXSBUh22Lx+Z1FRPMhrB
Z3Al4qq+PT1W4NFAnylj0mt80NQqUQEk/KfJDbZhdmmBNniD6IFdwFejc3jIUufb
V2ziJKwrFUAD3D3O1UBSrE44NUfYhD7LRnOo4esvfk5wcru4bhV6u/fl37IA/p2E
c2+Bx8uaUnm8WNhl1U6ijgtc+H540KnuI8mJJSGha6Vp809cykByERGNVJDwWxBi
yLgTR1xjNnNtvEVHUX3uy/JxbiLHVYk+THFfvY9lAg38bQb6yg0/oiH5LFizVH65
qAfFBpR9glHGTUEqbMrd/zbSrbvmow==
=TATy
-----END PGP SIGNATURE-----

--E+iv+cIVVBOtIZKv--


From xen-devel-bounces@lists.xenproject.org Thu Jan 02 12:54:21 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 12:54:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863914.1275267 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTKiF-0004AL-TU; Thu, 02 Jan 2025 12:54:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863914.1275267; Thu, 02 Jan 2025 12:54:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTKiF-0004AE-PT; Thu, 02 Jan 2025 12:54:07 +0000
Received: by outflank-mailman (input) for mailman id 863914;
 Thu, 02 Jan 2025 12:54:06 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=bpvf=T2=casper.srs.infradead.org=BATV+b36269e03d8020e3a9b7+7802+infradead.org+dwmw2@srs-se1.protection.inumbo.net>)
 id 1tTKiE-00049y-3k
 for xen-devel@lists.xen.org; Thu, 02 Jan 2025 12:54:06 +0000
Received: from casper.infradead.org (casper.infradead.org
 [2001:8b0:10b:1236::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a09d703d-c908-11ef-99a4-01e77a169b0f;
 Thu, 02 Jan 2025 13:53:58 +0100 (CET)
Received: from [172.31.31.240] (helo=u09cd745991455d.lumleys.internal)
 by casper.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux))
 id 1tTKi3-0000000GnvV-1wAs; Thu, 02 Jan 2025 12:53:55 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a09d703d-c908-11ef-99a4-01e77a169b0f
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:Cc:To:From:Subject:Message-ID:Sender:Reply-To:
	Content-Transfer-Encoding:Content-ID:Content-Description;
	bh=XZ81UvAGd1gMdPsuFBogIKjWzzjjX39O8QCH69uF1IE=; b=e2GCSAV3Y+7tAGGt5wOLBGPm7p
	+KYBmWfxQd9L5E/CIN3qwYXhQvyDVNE4Td7T+gqcEkE00inK/LkG5OkAG8C/pcx5HQz1UXW1uWunP
	YBd7DsHEYsAEi0bDn0t4XgkJwwJNcz8cfY7d9PdFIiSJGa6t5QnvlpI1W+oF8QuEs4AgQ4Rzlxbus
	mile0+V4qCfu1r3ovifnR8NWQA9Y13xLOYBZwb9keyWbb8S7eQHUHAw0W1faPECIlj9wqY6qhOT4g
	XTPn/UTRKnc+dxQW24QAxu6OygqkTAlsmzC5CE5oNCjeqG+fvoG9iQQlX3n6bnxeplN/FGiqaXqCG
	2Vp6hfkQ==;
Message-ID: <fc4c45ea86567ef0c46d7e5a20e8abffa75cc4ec.camel@infradead.org>
Subject: Re: Xen Security Advisory 466 v3 (CVE-2024-53241) - Xen hypercall
 page unsafe against speculative attacks
From: David Woodhouse <dwmw2@infradead.org>
To: =?ISO-8859-1?Q?J=FCrgen_Gro=DF?= <jgross@suse.com>, "Xen.org security
 team" <security@xen.org>, xen-announce@lists.xen.org,
 xen-devel@lists.xen.org,  xen-users@lists.xen.org,
 oss-security@lists.openwall.com
Cc: "Xen.org security team" <security-team-members@xen.org>
Date: Thu, 02 Jan 2025 12:53:55 +0000
In-Reply-To: <a3031e7d-fe9d-4db8-8ccd-923165c9af72@suse.com>
References: <E1tNWXG-00E268-2p@xenbits.xenproject.org>
	 <54c892eded2b4ebdda8ee1085c383178f44414ad.camel@infradead.org>
	 <a3031e7d-fe9d-4db8-8ccd-923165c9af72@suse.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-QRj7QDtiHxIVtxynuJ+J"
User-Agent: Evolution 3.52.3-0ubuntu1 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html


--=-QRj7QDtiHxIVtxynuJ+J
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2025-01-02 at 13:07 +0100, J=C3=BCrgen Gro=C3=9F wrote:
> On 23.12.24 15:24, David Woodhouse wrote:
> > On Tue, 2024-12-17 at 12:18 +0000, Xen.org security team wrote:
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 Xen Security Advisory CVE-2024-53241 / XSA-466
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 version 3
> > >=20
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Xen hypercall =
page unsafe against speculative attacks
> > >=20
> > > UPDATES IN VERSION 3
> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > >=20
> > > Update of patch 5, public release.
> >=20
> > Can't we even use the hypercall page early in boot? Surely we have to
> > know whether we're running on an Intel or AMD CPU before we get to the
> > point where we can enable any of the new control-flow integrity
> > support? Do we need to jump through those hoops do do that early
> > detection and setup?
>=20
> The downside of this approach would be to have another variant to do
> hypercalls. So you'd have to replace the variant being able to use AMD
> or INTEL specific instructions with a function doing the hypercall via
> the hypercall page.

You'd probably start with the hypercall function just jumping directly
into the temporary hypercall page during early boot, and then you'd
update them to use the natively prepared vmcall/vmmcall version later.

All the complexity of patching and CPU detection in early boot seems to
be somewhat gratuitous and even counter-productive given the change it
introduces to 64-bit latching.

And even if the 64-bit latch does happen when HVM_PARAM_CALLBACK_IRQ is
set, isn't that potentially a lot later in boot? Xen will be treating
this guest as 32-bit until then, so won't all the vcpu_info and
runstate structures be wrong even as the secondary CPUs are already up
and running?

> I'm planning to send patches for Xen and the kernel to add CPUID feature
> bits indicating which instruction to use. This will make life much easier=
.
>=20
> > Enabling the hypercall page is also one of the two points where Xen
> > will 'latch' that the guest is 64-bit, which affects the layout of the
> > shared_info, vcpu_info and runstate structures.
> >=20
> > The other such latching point is when the guest sets
> > HVM_PARAM_CALLBACK_IRQ, and I *think* that should work in all
> > implementations of the Xen ABI (including QEMU/KVM and EC2). But would
> > want to test.
> >=20
> > But perhaps it wouldn't hurt for maximal compatibility for Linux to set
> > the hypercall page *anyway*, even if Linux doesn't then use it =E2=80=
=94 or
> > only uses it during early boot?
>=20
> I'm seeing potential problems with that approach when someone is using
> an out-of-tree module doing hypercalls.
>=20
> With having the hypercall page present such a module would add a way to d=
o
> speculative attacks, while deleting the hypercall page would result in a
> failure trying to load such a module.

Is that a response to the original patch series, or to my suggestion?

If we temporarily ask Xen to populate a hypercall page which is used
during early boot (or even if it's *not* used, and only used to make
sure Xen latches 64-bit mode early)... I don't see why that makes any
difference to modules. I wasn't suggesting we keep it around and
*export* it.


--=-QRj7QDtiHxIVtxynuJ+J
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD9Aw
ggSOMIIDdqADAgECAhAOmiw0ECVD4cWj5DqVrT9PMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0yNDAxMzAwMDAwMDBaFw0zMTEx
MDkyMzU5NTlaMEExCzAJBgNVBAYTAkFVMRAwDgYDVQQKEwdWZXJva2V5MSAwHgYDVQQDExdWZXJv
a2V5IFNlY3VyZSBFbWFpbCBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMjvgLKj
jfhCFqxYyRiW8g3cNFAvltDbK5AzcOaR7yVzVGadr4YcCVxjKrEJOgi7WEOH8rUgCNB5cTD8N/Et
GfZI+LGqSv0YtNa54T9D1AWJy08ZKkWvfGGIXN9UFAPMJ6OLLH/UUEgFa+7KlrEvMUupDFGnnR06
aDJAwtycb8yXtILj+TvfhLFhafxroXrflspavejQkEiHjNjtHnwbZ+o43g0/yxjwnarGI3kgcak7
nnI9/8Lqpq79tLHYwLajotwLiGTB71AGN5xK+tzB+D4eN9lXayrjcszgbOv2ZCgzExQUAIt98mre
8EggKs9mwtEuKAhYBIP/0K6WsoMnQCcCAwEAAaOCAVwwggFYMBIGA1UdEwEB/wQIMAYBAf8CAQAw
HQYDVR0OBBYEFIlICOogTndrhuWByNfhjWSEf/xwMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6en
IZ3zbcgPMA4GA1UdDwEB/wQEAwIBhjAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIweQYI
KwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYIKwYB
BQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RD
QS5jcnQwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0
QXNzdXJlZElEUm9vdENBLmNybDARBgNVHSAECjAIMAYGBFUdIAAwDQYJKoZIhvcNAQELBQADggEB
ACiagCqvNVxOfSd0uYfJMiZsOEBXAKIR/kpqRp2YCfrP4Tz7fJogYN4fxNAw7iy/bPZcvpVCfe/H
/CCcp3alXL0I8M/rnEnRlv8ItY4MEF+2T/MkdXI3u1vHy3ua8SxBM8eT9LBQokHZxGUX51cE0kwa
uEOZ+PonVIOnMjuLp29kcNOVnzf8DGKiek+cT51FvGRjV6LbaxXOm2P47/aiaXrDD5O0RF5SiPo6
xD1/ClkCETyyEAE5LRJlXtx288R598koyFcwCSXijeVcRvBB1cNOLEbg7RMSw1AGq14fNe2cH1HG
W7xyduY/ydQt6gv5r21mDOQ5SaZSWC/ZRfLDuEYwggWbMIIEg6ADAgECAhAH5JEPagNRXYDiRPdl
c1vgMA0GCSqGSIb3DQEBCwUAMEExCzAJBgNVBAYTAkFVMRAwDgYDVQQKEwdWZXJva2V5MSAwHgYD
VQQDExdWZXJva2V5IFNlY3VyZSBFbWFpbCBHMjAeFw0yNDEyMzAwMDAwMDBaFw0yODAxMDQyMzU5
NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqGSIb3DQEBAQUAA4IC
DwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZeYAS/SRV6zmfXlXaZ
sNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2zkC9S7/yHDYnqegqt
w4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qGpgFdZEk2/c//ZvUN
i12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41vav1RhZJzYan4a1gU0
kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0cvnO8FM6PTqsnSbcc
0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PWPU6zfQTOMZ9uLQRR
ci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXtREF5lLXxp+CJ6KKS
blPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQrlR0gO3lBzuyPPArV
hvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7IqaAovAX0d+f1YjbmC
VsAwjhLmveFjNwIDAQABo4IBsDCCAawwHwYDVR0jBBgwFoAUiUgI6iBOd2uG5YHI1+GNZIR//HAw
HQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3bXcyQGluZnJhZGVh
ZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEBMA4GA1UdDwEB/wQE
AwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwewYDVR0fBHQwcjA3oDWgM4YxaHR0
cDovL2NybDMuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNybDA3oDWgM4YxaHR0
cDovL2NybDQuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNybDB2BggrBgEFBQcB
AQRqMGgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBABggrBgEFBQcwAoY0
aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNydDANBgkq
hkiG9w0BAQsFAAOCAQEAQXc4FPiPLRnTDvmOABEzkIumojfZAe5SlnuQoeFUfi+LsWCKiB8Uextv
iBAvboKhLuN6eG/NC6WOzOCppn4mkQxRkOdLNThwMHW0d19jrZFEKtEG/epZ/hw/DdScTuZ2m7im
8ppItAT6GXD3aPhXkXnJpC/zTs85uNSQR64cEcBFjjoQDuSsTeJ5DAWf8EMyhMuD8pcbqx5kRvyt
JPsWBQzv1Dsdv2LDPLNd/JUKhHSgr7nbUr4+aAP2PHTXGcEBh8lTeYea9p4d5k969pe0OHYMV5aL
xERqTagmSetuIwolkAuBCzA9vulg8Y49Nz2zrpUGfKGOD0FMqenYxdJHgDCCBZswggSDoAMCAQIC
EAfkkQ9qA1FdgOJE92VzW+AwDQYJKoZIhvcNAQELBQAwQTELMAkGA1UEBhMCQVUxEDAOBgNVBAoT
B1Zlcm9rZXkxIDAeBgNVBAMTF1Zlcm9rZXkgU2VjdXJlIEVtYWlsIEcyMB4XDTI0MTIzMDAwMDAw
MFoXDTI4MDEwNDIzNTk1OVowHjEcMBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzCCAiIwDQYJ
KoZIhvcNAQEBBQADggIPADCCAgoCggIBANqWLse95HW2F7FhfH9bugyT/danKmmXrbMnz5GZNAfj
Jl5gBL9JFXrOZ9eVdpmw04Tp6aDxZctFLoEDvSWKi367Q7Sg+ci+fH4KwwfQ8Pi0IpIKx2n5emEg
nbOQL1Lv/IcNiep6Cq3DiyaSpSp/RZf+CAfUNySHS8eWmhLU6jGpSD6hxTpYKye7PmrmvMWwfGEP
WoamAV1kSTb9z/9m9Q2LXa89aKmTxNwnAfD3Ohn9mtU3JukwILRMewn9QRXK7KzM+01h5hkCE4nj
W9q/VGFknNhqfhrWBTSQoE9CSVylASGrjzCgS7XmKy/BaH3/7mOOHQv5g1o3Qj/+cdKnpT0I5Qb1
nRy+c7wUzo9OqydJtxzSP4ZyHA4dELto/a3m/ay1XHcpum1pgTOLgxAfGb/T4dCkwRUstSKLMmpL
g9Y9TrN9BM4xn24tBFFyL5znGG0wQGzOVAM68RBzIQb6Fz758fjsr4yZnPbVsU1+gHEs/puNHrG0
9e1EQXmUtfGn4InoopJuU8p5VGD9S3Ikd4UoBlc7xl5yjtNlQxUeYrRlnUSmdlucCEoTX1n4UmtA
9CuVHSA7eUHO7I88CtWG9bGOU7tLgOZoSEvNqtaL/N7sQbBZK4jZ4Rr/zNTQg1SwYjjLB7u96lDP
sipoCi8BfR35/ViNuYJWwDCOEua94WM3AgMBAAGjggGwMIIBrDAfBgNVHSMEGDAWgBSJSAjqIE53
a4blgcjX4Y1khH/8cDAdBgNVHQ4EFgQUXGIam3Bs59Y60yTmWgfDu6pZQ6cwMAYDVR0RBCkwJ4ET
ZHdtdzJAaW5mcmFkZWFkLm9yZ4EQZGF2aWRAd29vZGhvdS5zZTAUBgNVHSAEDTALMAkGB2eBDAEF
AQEwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDB7BgNVHR8E
dDByMDegNaAzhjFodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVtYWlsRzIu
Y3JsMDegNaAzhjFodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVtYWlsRzIu
Y3JsMHYGCCsGAQUFBwEBBGowaDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29t
MEAGCCsGAQUFBzAChjRodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVt
YWlsRzIuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQBBdzgU+I8tGdMO+Y4AETOQi6aiN9kB7lKWe5Ch
4VR+L4uxYIqIHxR7G2+IEC9ugqEu43p4b80LpY7M4KmmfiaRDFGQ50s1OHAwdbR3X2OtkUQq0Qb9
6ln+HD8N1JxO5nabuKbymki0BPoZcPdo+FeRecmkL/NOzzm41JBHrhwRwEWOOhAO5KxN4nkMBZ/w
QzKEy4PylxurHmRG/K0k+xYFDO/UOx2/YsM8s138lQqEdKCvudtSvj5oA/Y8dNcZwQGHyVN5h5r2
nh3mT3r2l7Q4dgxXlovERGpNqCZJ624jCiWQC4ELMD2+6WDxjj03PbOulQZ8oY4PQUyp6djF0keA
MYIDuzCCA7cCAQEwVTBBMQswCQYDVQQGEwJBVTEQMA4GA1UEChMHVmVyb2tleTEgMB4GA1UEAxMX
VmVyb2tleSBTZWN1cmUgRW1haWwgRzICEAfkkQ9qA1FdgOJE92VzW+AwDQYJYIZIAWUDBAIBBQCg
ggE3MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTI1MDEwMjEyNTM1
NVowLwYJKoZIhvcNAQkEMSIEICiOF/hVtoVI2BtS03l+r0Nuf9cXq7ucjVMKQh1HXWPNMGQGCSsG
AQQBgjcQBDFXMFUwQTELMAkGA1UEBhMCQVUxEDAOBgNVBAoTB1Zlcm9rZXkxIDAeBgNVBAMTF1Zl
cm9rZXkgU2VjdXJlIEVtYWlsIEcyAhAH5JEPagNRXYDiRPdlc1vgMGYGCyqGSIb3DQEJEAILMVeg
VTBBMQswCQYDVQQGEwJBVTEQMA4GA1UEChMHVmVyb2tleTEgMB4GA1UEAxMXVmVyb2tleSBTZWN1
cmUgRW1haWwgRzICEAfkkQ9qA1FdgOJE92VzW+AwDQYJKoZIhvcNAQEBBQAEggIApvYvG36Cpjmm
F5IbExAuqSQK2B9rsdivMkDAxU7nqtTqsYFEo5rete0oODwnkI8acMoe+BBnZrqpxGMDKjCKUaCE
duf+l6Td3jcCi0gty7HyB0rh57BobK57YOpPgaaYDj3P+oshtZgO4VteObkF9AT9mz7y1zSrIVTg
XVRyXg/bHFwM7EgCnaHvF4keVVBzF3r6QLco4ZSCpoTxa5hURY4aSvlzKcd6YWknt8QUfGZJlrx4
Gr1/xRsYqwBvCRyELnYK6JXaDsKiXcZHjO/0DMSct19EEqA5dqxyT9H3Ayh8CwfiTBtGt/6HSIk3
qLa4u9jbBIx2zVAZkjWWIJgx4djoYgv3MIO6fFh97rx+8vaHrqfvzqXl7YEF3HGvim1oGKytUcL6
N4c4Y7MCx9cm0o3W591Hle/BunCRadwAgfuMsl7IRZCQ6y7PlPPH2g7UOJKsmX0unVHEEuQuZCUd
r0wK+TE7lvf3eyfLMaTWdEN/6biYz9duEbmTIBBkZ5Ia1FmSvl3RM0iUamHPMJVDWrEaQ4GPE2Qh
UUnmg0NKrSs9dsUDjAGmjCyo7vwGEhnId6GE/hFbZcwMiFS8BShXvKnENiIVJYi4K3+S2Ipq+GVR
8ah45zAUrXOW1TOsgX8J9YtO4qaRCXF4J9qxWfvyVXNndsTj+ZLSoHoGStZV9ygAAAAAAAA=


--=-QRj7QDtiHxIVtxynuJ+J--


From xen-devel-bounces@lists.xenproject.org Thu Jan 02 13:39:01 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 13:39:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863930.1275297 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTLPa-0001xN-1G; Thu, 02 Jan 2025 13:38:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863930.1275297; Thu, 02 Jan 2025 13:38:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTLPZ-0001wg-QE; Thu, 02 Jan 2025 13:38:53 +0000
Received: by outflank-mailman (input) for mailman id 863930;
 Thu, 02 Jan 2025 13:38:52 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=RDYY=T2=suse.com=jgross@srs-se1.protection.inumbo.net>)
 id 1tTLPY-0001av-Df
 for xen-devel@lists.xen.org; Thu, 02 Jan 2025 13:38:52 +0000
Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com
 [2a00:1450:4864:20::443])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e5a010c0-c90e-11ef-99a4-01e77a169b0f;
 Thu, 02 Jan 2025 14:38:49 +0100 (CET)
Received: by mail-wr1-x443.google.com with SMTP id
 ffacd0b85a97d-385ef8b64b3so8970529f8f.0
 for <xen-devel@lists.xen.org>; Thu, 02 Jan 2025 05:38:49 -0800 (PST)
Received: from ?IPV6:2003:e5:8731:2800:842d:42a0:5992:3595?
 (p200300e587312800842d42a059923595.dip0.t-ipconnect.de.
 [2003:e5:8731:2800:842d:42a0:5992:3595])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c8acb17sm37661535f8f.97.2025.01.02.05.38.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 02 Jan 2025 05:38:48 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e5a010c0-c90e-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1735825129; x=1736429929; darn=lists.xen.org;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=w8tNcqAfbc/w5Y825OEalan1QasEQ19JbuEFRiq05JU=;
        b=ExNgCf6meqw1vc9QbG5Ikrk/Rwx31qwO+eR2T7WfQAKxX/GHa+BFUWoGAgMdSTqeMM
         vY/NC75RhlYBIp/QM+u+mEEcC9k7VjtDBFjeHAzCkU/h51x4CPCgHWbeGORogpGTlVmY
         9m3TV0BU+gr3wd2VNIE27a83bkWghgsU2Fz+KDNPO6x0idyJDcr5FX4wS6hUJd8rL+sH
         hS2m8PHdc0ro0WjUbE/RY5xwx4XMdiwdv3TbEvQR9HkG4ml99/Fx4kOH5kBbkbULg8i3
         NGOVmeobk5i+P5U9DMsFDrvYUiyquoaehJNW4MmcLqGNz1XDELIalaFByHqqgCNUEcNg
         cBnw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735825129; x=1736429929;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=w8tNcqAfbc/w5Y825OEalan1QasEQ19JbuEFRiq05JU=;
        b=FPqguJustIaIRll8Oj315rBFhxqrwyODTDTjko6D9d1somzShmh+q9l5YJc2XXQVns
         b+i3krtPYSGm+S8jcAM/QbPKT0Y1VQzT/vLVZddIEYgKeJECUvUEC+0LbpW2VS3U64/V
         IJDirD7mOOcOp3QYPgQGHT+l2iCVsptTq2TYfEfdrZKCQBz8L/fR99APooCRl8PGREqb
         0Fk+ePxOZwK9YnHHxG2jaOEINMmfIhxzPq5qkcSu5rHrmJ/I0JgUrrSuj9UR8ksNwxRW
         bi77rUKKO5HKDoPeTX0G/8uKd5pofVLP6ubLOh2gUkxwy6IpKTDKpsytubqPDFbRMMZj
         h0UA==
X-Forwarded-Encrypted: i=1; AJvYcCWbwXo9Sl6To0jKjqqZsMh4uJWvFPcbshd4P0l5tjzdJ6Hy1SChB9yo+L3CiIm4zd5QtNHXBcjF+cM=@lists.xen.org
X-Gm-Message-State: AOJu0YyVSVZ8tXBvDC/els95ZI1KJYMFxAzetVoqoNI0eRF+ZR3T1f3S
	d4MKlYcdM//YBcFn8/w561/8CZhotx7Pxw+sW8NMq0B0oJ4XAlmya3SgSNxruos=
X-Gm-Gg: ASbGncs320GwtjWCXOb8sB4gv3QoUufwBCUUDdqPUe6wJMGEE1LCI5GAgycj9VzDA6K
	xYPc/cI755j+tIIXTHN0QRP7u7XE9r23nqa9q39V6m6no8P/YMaeisQ2PSd4BFlK3sDqTbdtKQZ
	rtvyOyoDxVOsEwEzpdSKlkjH7A9q5S+iw+z/xHX+qrGtOUuCDYqLUU1fXGcitgtt+MdHKZ0grtk
	Y6OpV2vkjuOKRp1ZqHlOPJsFdwvLJ5bRbHK7ps5abk3wmE1GnMUUOqD9RoOgB2JeiHzGeloShWf
	IvXobIAokvmfnKn5QrIC0EfuexJZmnUmPAjf2tP2L3QiSotP01BGuvgHBMEAuuEMszwWHczjVgm
	LDlNUgg==
X-Google-Smtp-Source: AGHT+IFwxrHoXgEDeadsm/UfKKeIqGBAu4U/ADiNz/gMWkKvoECR8nDq/a9C1LS0cLCmscJQPfiYKQ==
X-Received: by 2002:a5d:6486:0:b0:38a:4575:5ffd with SMTP id ffacd0b85a97d-38a45756035mr20097305f8f.45.1735825128579;
        Thu, 02 Jan 2025 05:38:48 -0800 (PST)
Message-ID: <fd993f8d-280f-439a-a6a0-506e2815f281@suse.com>
Date: Thu, 2 Jan 2025 14:38:47 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Xen Security Advisory 466 v3 (CVE-2024-53241) - Xen hypercall
 page unsafe against speculative attacks
To: David Woodhouse <dwmw2@infradead.org>,
 "Xen.org security team" <security@xen.org>, xen-announce@lists.xen.org,
 xen-devel@lists.xen.org, xen-users@lists.xen.org,
 oss-security@lists.openwall.com
Cc: "Xen.org security team" <security-team-members@xen.org>
References: <E1tNWXG-00E268-2p@xenbits.xenproject.org>
 <54c892eded2b4ebdda8ee1085c383178f44414ad.camel@infradead.org>
 <a3031e7d-fe9d-4db8-8ccd-923165c9af72@suse.com>
 <fc4c45ea86567ef0c46d7e5a20e8abffa75cc4ec.camel@infradead.org>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <fc4c45ea86567ef0c46d7e5a20e8abffa75cc4ec.camel@infradead.org>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------0uxjyXf9Ftc0bjwaQOQdIpii"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------0uxjyXf9Ftc0bjwaQOQdIpii
Content-Type: multipart/mixed; boundary="------------xcT6P0TDFNtkkbHlvsbrcSgE";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: David Woodhouse <dwmw2@infradead.org>,
 "Xen.org security team" <security@xen.org>, xen-announce@lists.xen.org,
 xen-devel@lists.xen.org, xen-users@lists.xen.org,
 oss-security@lists.openwall.com
Cc: "Xen.org security team" <security-team-members@xen.org>
Message-ID: <fd993f8d-280f-439a-a6a0-506e2815f281@suse.com>
Subject: Re: Xen Security Advisory 466 v3 (CVE-2024-53241) - Xen hypercall
 page unsafe against speculative attacks
References: <E1tNWXG-00E268-2p@xenbits.xenproject.org>
 <54c892eded2b4ebdda8ee1085c383178f44414ad.camel@infradead.org>
 <a3031e7d-fe9d-4db8-8ccd-923165c9af72@suse.com>
 <fc4c45ea86567ef0c46d7e5a20e8abffa75cc4ec.camel@infradead.org>
In-Reply-To: <fc4c45ea86567ef0c46d7e5a20e8abffa75cc4ec.camel@infradead.org>
Autocrypt-Gossip: addr=security@xen.org; keydata=
 xsBNBE+hNqgBCADYua5OFR0/Jeu0rByk+Obk6+SewIeGej1FAcjo+Cvpcr1dfnLBAhmmhbfM
 b++qr6SG6Ek+cUQogYAFvZcEcusbRPy4MIzJkqoPSyOUhCxZoxWNWUfhDdt0TWA3Hs1vYmFO
 e+2jvlL3h7yAsGMYO8jo6ow8ceBEOmf8Q5BLq2OPkNpGcaHEhbSv0VZ3mdHM30ynY6GubIws
 c68LZ5hTORTSjKaj2WVCe4OorBMZte5Im+6MOEUbCjynqPJSU9KNFhIhUuyXp1vn0gZ2N5QS
 pkghpzBJLzeBNEI6ecV3Q0p+/pq8EvEAuUSNLUEbIZ/NSLqyTVMc9HZxnPu59im8wB9rABEB
 AAHNK1hlbi5vcmcgKGluY29taW5nIGVtYWlsKSA8c2VjdXJpdHlAeGVuLm9yZz7CwHgEEwEC
 ACIFAk+hNqgCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEHQ6P8qC06lk1y0H/2Pj
 jQyPDZVS4zIVnR4xQOQ1KphPCdSTPlhj+VVrjZZNXWGCUKvJShL84XIONH62fIgQE/6CTWXJ
 tx6i4u1oAtFH4+8HayFjg609lxx9frJ4tJkJitw5TT6VEGAambchIG5QaP9hepgyrVXjQ0X2
 ot0jgpwL6G3sx0L1gewiMALXtGT6oTqLjXius/nv69yRe26wxU1GX80oWWH/5p585xt54C1X
 nhDEVzp0S9UW7VAAVDCWuSefSrihh3jZi4QE1fnGRwO0RfeLh1sXeuMn9uFIz0CmaCbAp5Pe
 UyNb6wgG60h4JLCDyhJntoHfq8pQLEJ8G9nvjDfw8BLvkBKYNvbOwE0ET6E2qAEIALqWNlGF
 d3uIj+DXZ40/i7fsoPb+HaYaG6Y+7+ZWxMxUeQDTLBnTYiAa+EGVutc4v52BXH8RZc9I/NH9
 lBT2/AwaEVSomxLicbixXUGoFC9kMp/VP1xwWJ+gm+ZEnQzY+2AFJGMvqEsGocQA7yLw121J
 UOrorny3CqpHykPUF3fqp4n/GL47VTaKxlsoV8o2JgZZ62NJlkBtnbA4ODzhWr6cA21smWFg
 sfFJ+EkXb1NEeYLs8CWtTn2EiQXlZTQ8OgBPahfvLZ+AJ4sM/Raoi2c3UIQrlCsg9BoojKMk
 Li8XUrywr8HEJYjhBYObCgbmaeIEfmrw5XJqOKlMg40XY+MAEQEAAcLAXwQYAQIACQUCT6E2
 qAIbDAAKCRB0Oj/KgtOpZDhJB/0XtxrlVuRttpjK1PEYK/A/9h47VH9p0UvVYCH+ZS2a+sTg
 sapx0zp4uni8wtytkvGw/EM06D4ZoaWAUcjXILNKGdi62q/z+WAfdEY/WrONxAbr2Dtv/LT0
 0/2nifYU9O1vGYS1Kx/B3D8fU0w+2Sjv+hYjbGDWn619etC8dNEIxczH6V/cVOZf0D2KhoBf
 MCHUoKeuAfaIKDMxOZjb7sajfUW70cxFFWYqH96Py01oxDroOKzy0x62iVdsYFGB3FvcD9tD
 WsxVWwGHA8DKEfKMuNPiuapzdxdrNm5AQilSUlfD65KK9d3kQdoOUPdPWoIQnz8GnHMPDe99
 7SuwxWGb

--------------xcT6P0TDFNtkkbHlvsbrcSgE
Content-Type: multipart/mixed; boundary="------------gPCxleBjg0dVyFbMrKZisqpt"

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

T24gMDIuMDEuMjUgMTM6NTMsIERhdmlkIFdvb2Rob3VzZSB3cm90ZToNCj4gT24gVGh1LCAy
MDI1LTAxLTAyIGF0IDEzOjA3ICswMTAwLCBKw7xyZ2VuIEdyb8OfIHdyb3RlOg0KPj4gT24g
MjMuMTIuMjQgMTU6MjQsIERhdmlkIFdvb2Rob3VzZSB3cm90ZToNCj4+PiBPbiBUdWUsIDIw
MjQtMTItMTcgYXQgMTI6MTggKzAwMDAsIFhlbi5vcmcgc2VjdXJpdHkgdGVhbSB3cm90ZToN
Cj4+Pj4gIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFhlbiBTZWN1cml0eSBBZHZpc29y
eSBDVkUtMjAyNC01MzI0MSAvIFhTQS00NjYNCj4+Pj4gIMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgdmVyc2lvbiAz
DQo+Pj4+DQo+Pj4+ICDCoMKgwqDCoMKgwqDCoMKgwqAgWGVuIGh5cGVyY2FsbCBwYWdlIHVu
c2FmZSBhZ2FpbnN0IHNwZWN1bGF0aXZlIGF0dGFja3MNCj4+Pj4NCj4+Pj4gVVBEQVRFUyBJ
TiBWRVJTSU9OIDMNCj4+Pj4gPT09PT09PT09PT09PT09PT09PT0NCj4+Pj4NCj4+Pj4gVXBk
YXRlIG9mIHBhdGNoIDUsIHB1YmxpYyByZWxlYXNlLg0KPj4+DQo+Pj4gQ2FuJ3Qgd2UgZXZl
biB1c2UgdGhlIGh5cGVyY2FsbCBwYWdlIGVhcmx5IGluIGJvb3Q/IFN1cmVseSB3ZSBoYXZl
IHRvDQo+Pj4ga25vdyB3aGV0aGVyIHdlJ3JlIHJ1bm5pbmcgb24gYW4gSW50ZWwgb3IgQU1E
IENQVSBiZWZvcmUgd2UgZ2V0IHRvIHRoZQ0KPj4+IHBvaW50IHdoZXJlIHdlIGNhbiBlbmFi
bGUgYW55IG9mIHRoZSBuZXcgY29udHJvbC1mbG93IGludGVncml0eQ0KPj4+IHN1cHBvcnQ/
IERvIHdlIG5lZWQgdG8ganVtcCB0aHJvdWdoIHRob3NlIGhvb3BzIGRvIGRvIHRoYXQgZWFy
bHkNCj4+PiBkZXRlY3Rpb24gYW5kIHNldHVwPw0KPj4NCj4+IFRoZSBkb3duc2lkZSBvZiB0
aGlzIGFwcHJvYWNoIHdvdWxkIGJlIHRvIGhhdmUgYW5vdGhlciB2YXJpYW50IHRvIGRvDQo+
PiBoeXBlcmNhbGxzLiBTbyB5b3UnZCBoYXZlIHRvIHJlcGxhY2UgdGhlIHZhcmlhbnQgYmVp
bmcgYWJsZSB0byB1c2UgQU1EDQo+PiBvciBJTlRFTCBzcGVjaWZpYyBpbnN0cnVjdGlvbnMg
d2l0aCBhIGZ1bmN0aW9uIGRvaW5nIHRoZSBoeXBlcmNhbGwgdmlhDQo+PiB0aGUgaHlwZXJj
YWxsIHBhZ2UuDQo+IA0KPiBZb3UnZCBwcm9iYWJseSBzdGFydCB3aXRoIHRoZSBoeXBlcmNh
bGwgZnVuY3Rpb24ganVzdCBqdW1waW5nIGRpcmVjdGx5DQo+IGludG8gdGhlIHRlbXBvcmFy
eSBoeXBlcmNhbGwgcGFnZSBkdXJpbmcgZWFybHkgYm9vdCwgYW5kIHRoZW4geW91J2QNCj4g
dXBkYXRlIHRoZW0gdG8gdXNlIHRoZSBuYXRpdmVseSBwcmVwYXJlZCB2bWNhbGwvdm1tY2Fs
bCB2ZXJzaW9uIGxhdGVyLg0KPiANCj4gQWxsIHRoZSBjb21wbGV4aXR5IG9mIHBhdGNoaW5n
IGFuZCBDUFUgZGV0ZWN0aW9uIGluIGVhcmx5IGJvb3Qgc2VlbXMgdG8NCj4gYmUgc29tZXdo
YXQgZ3JhdHVpdG91cyBhbmQgZXZlbiBjb3VudGVyLXByb2R1Y3RpdmUgZ2l2ZW4gdGhlIGNo
YW5nZSBpdA0KPiBpbnRyb2R1Y2VzIHRvIDY0LWJpdCBsYXRjaGluZy4NCj4gDQo+IEFuZCBl
dmVuIGlmIHRoZSA2NC1iaXQgbGF0Y2ggZG9lcyBoYXBwZW4gd2hlbiBIVk1fUEFSQU1fQ0FM
TEJBQ0tfSVJRIGlzDQo+IHNldCwgaXNuJ3QgdGhhdCBwb3RlbnRpYWxseSBhIGxvdCBsYXRl
ciBpbiBib290PyBYZW4gd2lsbCBiZSB0cmVhdGluZw0KPiB0aGlzIGd1ZXN0IGFzIDMyLWJp
dCB1bnRpbCB0aGVuLCBzbyB3b24ndCBhbGwgdGhlIHZjcHVfaW5mbyBhbmQNCj4gcnVuc3Rh
dGUgc3RydWN0dXJlcyBiZSB3cm9uZyBldmVuIGFzIHRoZSBzZWNvbmRhcnkgQ1BVcyBhcmUg
YWxyZWFkeSB1cA0KPiBhbmQgcnVubmluZz8NCg0KV2hhdCBJIGRvbid0IGdldCBpcyB3aHkg
dGhpcyBsYXRjaGluZyBpc24ndCBkb25lIHdoZW4gdGhlIHNoYXJlZCBpbmZvDQpwYWdlIGlz
IG1hcHBlZCBpbnRvIHRoZSBndWVzdCB2aWEgdGhlIFhFTk1BUFNQQUNFX3NoYXJlZF9pbmZv
IGh5cGVyY2FsbA0Kb3IgbWF5YmUgYWRkaXRpb25hbGx5IHdoZW4gVkNQVU9QX3JlZ2lzdGVy
X3J1bnN0YXRlX21lbW9yeV9hcmVhIGlzIGJlaW5nDQp1c2VkIGJ5IHRoZSBndWVzdC4NCg0K
VGhlc2UgYXJlIHRoZSBlYXJsaWVzdCBwb3NzaWJsZSBjYXNlcyB3aGVyZSB0aGUgZ3Vlc3Qg
aXMgYWJsZSB0byBhY2Nlc3MNCnRoaXMgZGF0YS4NCg0KPiANCj4+IEknbSBwbGFubmluZyB0
byBzZW5kIHBhdGNoZXMgZm9yIFhlbiBhbmQgdGhlIGtlcm5lbCB0byBhZGQgQ1BVSUQgZmVh
dHVyZQ0KPj4gYml0cyBpbmRpY2F0aW5nIHdoaWNoIGluc3RydWN0aW9uIHRvIHVzZS4gVGhp
cyB3aWxsIG1ha2UgbGlmZSBtdWNoIGVhc2llci4NCj4+DQo+Pj4gRW5hYmxpbmcgdGhlIGh5
cGVyY2FsbCBwYWdlIGlzIGFsc28gb25lIG9mIHRoZSB0d28gcG9pbnRzIHdoZXJlIFhlbg0K
Pj4+IHdpbGwgJ2xhdGNoJyB0aGF0IHRoZSBndWVzdCBpcyA2NC1iaXQsIHdoaWNoIGFmZmVj
dHMgdGhlIGxheW91dCBvZiB0aGUNCj4+PiBzaGFyZWRfaW5mbywgdmNwdV9pbmZvIGFuZCBy
dW5zdGF0ZSBzdHJ1Y3R1cmVzLg0KPj4+DQo+Pj4gVGhlIG90aGVyIHN1Y2ggbGF0Y2hpbmcg
cG9pbnQgaXMgd2hlbiB0aGUgZ3Vlc3Qgc2V0cw0KPj4+IEhWTV9QQVJBTV9DQUxMQkFDS19J
UlEsIGFuZCBJICp0aGluayogdGhhdCBzaG91bGQgd29yayBpbiBhbGwNCj4+PiBpbXBsZW1l
bnRhdGlvbnMgb2YgdGhlIFhlbiBBQkkgKGluY2x1ZGluZyBRRU1VL0tWTSBhbmQgRUMyKS4g
QnV0IHdvdWxkDQo+Pj4gd2FudCB0byB0ZXN0Lg0KPj4+DQo+Pj4gQnV0IHBlcmhhcHMgaXQg
d291bGRuJ3QgaHVydCBmb3IgbWF4aW1hbCBjb21wYXRpYmlsaXR5IGZvciBMaW51eCB0byBz
ZXQNCj4+PiB0aGUgaHlwZXJjYWxsIHBhZ2UgKmFueXdheSosIGV2ZW4gaWYgTGludXggZG9l
c24ndCB0aGVuIHVzZSBpdCDigJQgb3INCj4+PiBvbmx5IHVzZXMgaXQgZHVyaW5nIGVhcmx5
IGJvb3Q/DQo+Pg0KPj4gSSdtIHNlZWluZyBwb3RlbnRpYWwgcHJvYmxlbXMgd2l0aCB0aGF0
IGFwcHJvYWNoIHdoZW4gc29tZW9uZSBpcyB1c2luZw0KPj4gYW4gb3V0LW9mLXRyZWUgbW9k
dWxlIGRvaW5nIGh5cGVyY2FsbHMuDQo+Pg0KPj4gV2l0aCBoYXZpbmcgdGhlIGh5cGVyY2Fs
bCBwYWdlIHByZXNlbnQgc3VjaCBhIG1vZHVsZSB3b3VsZCBhZGQgYSB3YXkgdG8gZG8NCj4+
IHNwZWN1bGF0aXZlIGF0dGFja3MsIHdoaWxlIGRlbGV0aW5nIHRoZSBoeXBlcmNhbGwgcGFn
ZSB3b3VsZCByZXN1bHQgaW4gYQ0KPj4gZmFpbHVyZSB0cnlpbmcgdG8gbG9hZCBzdWNoIGEg
bW9kdWxlLg0KPiANCj4gSXMgdGhhdCBhIHJlc3BvbnNlIHRvIHRoZSBvcmlnaW5hbCBwYXRj
aCBzZXJpZXMsIG9yIHRvIG15IHN1Z2dlc3Rpb24/DQo+IA0KPiBJZiB3ZSB0ZW1wb3Jhcmls
eSBhc2sgWGVuIHRvIHBvcHVsYXRlIGEgaHlwZXJjYWxsIHBhZ2Ugd2hpY2ggaXMgdXNlZA0K
PiBkdXJpbmcgZWFybHkgYm9vdCAob3IgZXZlbiBpZiBpdCdzICpub3QqIHVzZWQsIGFuZCBv
bmx5IHVzZWQgdG8gbWFrZQ0KPiBzdXJlIFhlbiBsYXRjaGVzIDY0LWJpdCBtb2RlIGVhcmx5
KS4uLiBJIGRvbid0IHNlZSB3aHkgdGhhdCBtYWtlcyBhbnkNCj4gZGlmZmVyZW5jZSB0byBt
b2R1bGVzLiBJIHdhc24ndCBzdWdnZXN0aW5nIHdlIGtlZXAgaXQgYXJvdW5kIGFuZA0KPiAq
ZXhwb3J0KiBpdC4NCg0KQWgsIEkgZGlkbid0IHJlYWQgeW91ciBzdWdnZXN0aW9uIHRoYXQg
d2F5Lg0KDQpTdGlsbCBJIGJlbGlldmUgdXNpbmcgdGhlIGh5cGVyY2FsbCBwYWdlIGlzIG5v
dCBhIGdvb2QgaWRlYSwgZXNwZWNpYWxseSBhcw0Kd2UnZCBhZGQgYSBoYXJkIGRlcGVuZGVu
Y3kgb24gdGhlIGFiaWxpdHkgdG8gZW5hYmxlIENGSSBpbiB0aGUga2VybmVsIHJlbGF0ZWQN
CnRvIHRoZSBzd2l0Y2ggZnJvbSB0aGUgaHlwZXJjYWxsIHBhZ2UgdG8gdGhlIG5ldyBkaXJl
Y3QgaHlwZXJjYWxsIGZ1bmN0aW9ucy4NCg0KDQpKdWVyZ2VuDQo=
--------------gPCxleBjg0dVyFbMrKZisqpt
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

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

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

--------------gPCxleBjg0dVyFbMrKZisqpt--

--------------xcT6P0TDFNtkkbHlvsbrcSgE--

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

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

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmd2lucFAwAAAAAACgkQsN6d1ii/Ey9f
LAgAkYLiDHc3xv4gBMFKWXZr4io5FgmuhYLEBB+ggxjb/cuRtPlAbWzdzPod7+xApbYxsIE9UkCa
dlJ3MFqwl1yyhdjw+R7P4fh86NDcNjShCZtq6Vsz50XA81zgLpvNh84kz4ASzl/Vm8/x0Y5KNZnf
bvfK1bMqSv7hloyXdmS/X5skBNypUapnMOxSdR3A8yaDLKJtBNpupV+ZJMcPdSOVcSHT3LlAVTNN
384nEh5rLq79Ec401GJW121gjuxKY46pH9DLEcXTQt+KaSjpxKsVi57YuQOZcLPV9KmAS87gABLO
Nm0fQHR8Eb/1YAV5WULAfGwiZbErdMTkW/J3VxkcHw==
=e/Wa
-----END PGP SIGNATURE-----

--------------0uxjyXf9Ftc0bjwaQOQdIpii--


From xen-devel-bounces@lists.xenproject.org Thu Jan 02 13:41:00 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 13:41:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863972.1275314 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTLRW-0004yy-8y; Thu, 02 Jan 2025 13:40:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863972.1275314; Thu, 02 Jan 2025 13:40:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTLRW-0004yr-5e; Thu, 02 Jan 2025 13:40:54 +0000
Received: by outflank-mailman (input) for mailman id 863972;
 Thu, 02 Jan 2025 13:40:52 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=bpvf=T2=casper.srs.infradead.org=BATV+b36269e03d8020e3a9b7+7802+infradead.org+dwmw2@srs-se1.protection.inumbo.net>)
 id 1tTLRU-0004x6-Sl
 for xen-devel@lists.xen.org; Thu, 02 Jan 2025 13:40:52 +0000
Received: from casper.infradead.org (casper.infradead.org
 [2001:8b0:10b:1236::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2a9b6222-c90f-11ef-99a4-01e77a169b0f;
 Thu, 02 Jan 2025 14:40:45 +0100 (CET)
Received: from [172.31.31.240] (helo=u09cd745991455d.lumleys.internal)
 by casper.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux))
 id 1tTLRM-0000000Gqm4-0q3O; Thu, 02 Jan 2025 13:40:44 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2a9b6222-c90f-11ef-99a4-01e77a169b0f
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:Cc:To:From:Subject:Message-ID:Sender:Reply-To:
	Content-Transfer-Encoding:Content-ID:Content-Description;
	bh=tpjCVnQPWoH/XipcBZOPQWI/gdmv2UjGTw2vyAbwl2w=; b=EaHzxMq7uuhnkLqUBvni9OO22B
	qaQmZsA/wOadKIGzCdd9ftFkZ56tCnaQ79roo/m4wPvJYR5HY97+KPvNVGUYm01ZBmZVO5OXOtcos
	jOGPgdp+tPkdM4Donae8Bh/LMBnfl3kpR50Wa+k5Ik3N8XUk8BU1NbVx0/aDrcRXwdfFNZPtMRYqR
	SHiXEccOfrTZz5d2sekBUPOZ8JjyeCVmbgynqsdYVeQPzwBZz9vaXuJDAIj6ZAtMHaklQI5zR1gxU
	K9GBbzVQhzZz5BEbekoLvBBbDHblDVHtNR8zGc/246/K+zV8mwEtuYClALdtXPRjnygae2MG3cc1c
	FXz8ARLQ==;
Message-ID: <b7323a9fa5239443b9b6f3daa423196de1051748.camel@infradead.org>
Subject: Re: Xen Security Advisory 466 v3 (CVE-2024-53241) - Xen hypercall
 page unsafe against speculative attacks
From: David Woodhouse <dwmw2@infradead.org>
To: =?ISO-8859-1?Q?J=FCrgen_Gro=DF?= <jgross@suse.com>, "Xen.org security
 team" <security@xen.org>, xen-announce@lists.xen.org,
 xen-devel@lists.xen.org,  xen-users@lists.xen.org,
 oss-security@lists.openwall.com
Cc: "Xen.org security team" <security-team-members@xen.org>
Date: Thu, 02 Jan 2025 13:40:44 +0000
In-Reply-To: <fd993f8d-280f-439a-a6a0-506e2815f281@suse.com>
References: <E1tNWXG-00E268-2p@xenbits.xenproject.org>
	 <54c892eded2b4ebdda8ee1085c383178f44414ad.camel@infradead.org>
	 <a3031e7d-fe9d-4db8-8ccd-923165c9af72@suse.com>
	 <fc4c45ea86567ef0c46d7e5a20e8abffa75cc4ec.camel@infradead.org>
	 <fd993f8d-280f-439a-a6a0-506e2815f281@suse.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-ZSqhNB+07rLVAUqGo4d1"
User-Agent: Evolution 3.52.3-0ubuntu1 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html


--=-ZSqhNB+07rLVAUqGo4d1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2025-01-02 at 14:38 +0100, J=C3=BCrgen Gro=C3=9F wrote:
> On 02.01.25 13:53, David Woodhouse wrote:
> > On Thu, 2025-01-02 at 13:07 +0100, J=C3=BCrgen Gro=C3=9F wrote:
> > > On 23.12.24 15:24, David Woodhouse wrote:
> > > > On Tue, 2024-12-17 at 12:18 +0000, Xen.org security team wrote:
> > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 Xen Security Advisory CVE-2024-53241 / XSA-466
> > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 version 3
> > > > >=20
> > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Xen =
hypercall page unsafe against speculative attacks
> > > > >=20
> > > > > UPDATES IN VERSION 3
> > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > > >=20
> > > > > Update of patch 5, public release.
> > > >=20
> > > > Can't we even use the hypercall page early in boot? Surely we have =
to
> > > > know whether we're running on an Intel or AMD CPU before we get to =
the
> > > > point where we can enable any of the new control-flow integrity
> > > > support? Do we need to jump through those hoops do do that early
> > > > detection and setup?
> > >=20
> > > The downside of this approach would be to have another variant to do
> > > hypercalls. So you'd have to replace the variant being able to use AM=
D
> > > or INTEL specific instructions with a function doing the hypercall vi=
a
> > > the hypercall page.
> >=20
> > You'd probably start with the hypercall function just jumping directly
> > into the temporary hypercall page during early boot, and then you'd
> > update them to use the natively prepared vmcall/vmmcall version later.
> >=20
> > All the complexity of patching and CPU detection in early boot seems to
> > be somewhat gratuitous and even counter-productive given the change it
> > introduces to 64-bit latching.
> >=20
> > And even if the 64-bit latch does happen when HVM_PARAM_CALLBACK_IRQ is
> > set, isn't that potentially a lot later in boot? Xen will be treating
> > this guest as 32-bit until then, so won't all the vcpu_info and
> > runstate structures be wrong even as the secondary CPUs are already up
> > and running?
>=20
> What I don't get is why this latching isn't done when the shared info
> page is mapped into the guest via the XENMAPSPACE_shared_info hypercall
> or maybe additionally when VCPUOP_register_runstate_memory_area is being
> used by the guest.
>=20
> These are the earliest possible cases where the guest is able to access
> this data.

Well, that's a great idea. Got a time machine? If you have, I have some
comments on the MSI=E2=86=92PIRQ mapping nonsense too... :)

> >=20
> > > I'm planning to send patches for Xen and the kernel to add CPUID feat=
ure
> > > bits indicating which instruction to use. This will make life much ea=
sier.
> > >=20
> > > > Enabling the hypercall page is also one of the two points where Xen
> > > > will 'latch' that the guest is 64-bit, which affects the layout of =
the
> > > > shared_info, vcpu_info and runstate structures.
> > > >=20
> > > > The other such latching point is when the guest sets
> > > > HVM_PARAM_CALLBACK_IRQ, and I *think* that should work in all
> > > > implementations of the Xen ABI (including QEMU/KVM and EC2). But wo=
uld
> > > > want to test.
> > > >=20
> > > > But perhaps it wouldn't hurt for maximal compatibility for Linux to=
 set
> > > > the hypercall page *anyway*, even if Linux doesn't then use it =E2=
=80=94 or
> > > > only uses it during early boot?
> > >=20
> > > I'm seeing potential problems with that approach when someone is usin=
g
> > > an out-of-tree module doing hypercalls.
> > >=20
> > > With having the hypercall page present such a module would add a way =
to do
> > > speculative attacks, while deleting the hypercall page would result i=
n a
> > > failure trying to load such a module.
> >=20
> > Is that a response to the original patch series, or to my suggestion?
> >=20
> > If we temporarily ask Xen to populate a hypercall page which is used
> > during early boot (or even if it's *not* used, and only used to make
> > sure Xen latches 64-bit mode early)... I don't see why that makes any
> > difference to modules. I wasn't suggesting we keep it around and
> > *export* it.
>=20
> Ah, I didn't read your suggestion that way.
>=20
> Still I believe using the hypercall page is not a good idea, especially a=
s
> we'd add a hard dependency on the ability to enable CFI in the kernel rel=
ated
> to the switch from the hypercall page to the new direct hypercall functio=
ns.

Are you suggesting that you're able to enable the CPU-specific CFI
protections before you even know whether it's an Intel or AMD CPU?

--=-ZSqhNB+07rLVAUqGo4d1
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD9Aw
ggSOMIIDdqADAgECAhAOmiw0ECVD4cWj5DqVrT9PMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0yNDAxMzAwMDAwMDBaFw0zMTEx
MDkyMzU5NTlaMEExCzAJBgNVBAYTAkFVMRAwDgYDVQQKEwdWZXJva2V5MSAwHgYDVQQDExdWZXJv
a2V5IFNlY3VyZSBFbWFpbCBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMjvgLKj
jfhCFqxYyRiW8g3cNFAvltDbK5AzcOaR7yVzVGadr4YcCVxjKrEJOgi7WEOH8rUgCNB5cTD8N/Et
GfZI+LGqSv0YtNa54T9D1AWJy08ZKkWvfGGIXN9UFAPMJ6OLLH/UUEgFa+7KlrEvMUupDFGnnR06
aDJAwtycb8yXtILj+TvfhLFhafxroXrflspavejQkEiHjNjtHnwbZ+o43g0/yxjwnarGI3kgcak7
nnI9/8Lqpq79tLHYwLajotwLiGTB71AGN5xK+tzB+D4eN9lXayrjcszgbOv2ZCgzExQUAIt98mre
8EggKs9mwtEuKAhYBIP/0K6WsoMnQCcCAwEAAaOCAVwwggFYMBIGA1UdEwEB/wQIMAYBAf8CAQAw
HQYDVR0OBBYEFIlICOogTndrhuWByNfhjWSEf/xwMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6en
IZ3zbcgPMA4GA1UdDwEB/wQEAwIBhjAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIweQYI
KwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYIKwYB
BQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RD
QS5jcnQwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0
QXNzdXJlZElEUm9vdENBLmNybDARBgNVHSAECjAIMAYGBFUdIAAwDQYJKoZIhvcNAQELBQADggEB
ACiagCqvNVxOfSd0uYfJMiZsOEBXAKIR/kpqRp2YCfrP4Tz7fJogYN4fxNAw7iy/bPZcvpVCfe/H
/CCcp3alXL0I8M/rnEnRlv8ItY4MEF+2T/MkdXI3u1vHy3ua8SxBM8eT9LBQokHZxGUX51cE0kwa
uEOZ+PonVIOnMjuLp29kcNOVnzf8DGKiek+cT51FvGRjV6LbaxXOm2P47/aiaXrDD5O0RF5SiPo6
xD1/ClkCETyyEAE5LRJlXtx288R598koyFcwCSXijeVcRvBB1cNOLEbg7RMSw1AGq14fNe2cH1HG
W7xyduY/ydQt6gv5r21mDOQ5SaZSWC/ZRfLDuEYwggWbMIIEg6ADAgECAhAH5JEPagNRXYDiRPdl
c1vgMA0GCSqGSIb3DQEBCwUAMEExCzAJBgNVBAYTAkFVMRAwDgYDVQQKEwdWZXJva2V5MSAwHgYD
VQQDExdWZXJva2V5IFNlY3VyZSBFbWFpbCBHMjAeFw0yNDEyMzAwMDAwMDBaFw0yODAxMDQyMzU5
NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqGSIb3DQEBAQUAA4IC
DwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZeYAS/SRV6zmfXlXaZ
sNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2zkC9S7/yHDYnqegqt
w4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qGpgFdZEk2/c//ZvUN
i12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41vav1RhZJzYan4a1gU0
kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0cvnO8FM6PTqsnSbcc
0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PWPU6zfQTOMZ9uLQRR
ci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXtREF5lLXxp+CJ6KKS
blPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQrlR0gO3lBzuyPPArV
hvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7IqaAovAX0d+f1YjbmC
VsAwjhLmveFjNwIDAQABo4IBsDCCAawwHwYDVR0jBBgwFoAUiUgI6iBOd2uG5YHI1+GNZIR//HAw
HQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3bXcyQGluZnJhZGVh
ZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEBMA4GA1UdDwEB/wQE
AwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwewYDVR0fBHQwcjA3oDWgM4YxaHR0
cDovL2NybDMuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNybDA3oDWgM4YxaHR0
cDovL2NybDQuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNybDB2BggrBgEFBQcB
AQRqMGgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBABggrBgEFBQcwAoY0
aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNydDANBgkq
hkiG9w0BAQsFAAOCAQEAQXc4FPiPLRnTDvmOABEzkIumojfZAe5SlnuQoeFUfi+LsWCKiB8Uextv
iBAvboKhLuN6eG/NC6WOzOCppn4mkQxRkOdLNThwMHW0d19jrZFEKtEG/epZ/hw/DdScTuZ2m7im
8ppItAT6GXD3aPhXkXnJpC/zTs85uNSQR64cEcBFjjoQDuSsTeJ5DAWf8EMyhMuD8pcbqx5kRvyt
JPsWBQzv1Dsdv2LDPLNd/JUKhHSgr7nbUr4+aAP2PHTXGcEBh8lTeYea9p4d5k969pe0OHYMV5aL
xERqTagmSetuIwolkAuBCzA9vulg8Y49Nz2zrpUGfKGOD0FMqenYxdJHgDCCBZswggSDoAMCAQIC
EAfkkQ9qA1FdgOJE92VzW+AwDQYJKoZIhvcNAQELBQAwQTELMAkGA1UEBhMCQVUxEDAOBgNVBAoT
B1Zlcm9rZXkxIDAeBgNVBAMTF1Zlcm9rZXkgU2VjdXJlIEVtYWlsIEcyMB4XDTI0MTIzMDAwMDAw
MFoXDTI4MDEwNDIzNTk1OVowHjEcMBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzCCAiIwDQYJ
KoZIhvcNAQEBBQADggIPADCCAgoCggIBANqWLse95HW2F7FhfH9bugyT/danKmmXrbMnz5GZNAfj
Jl5gBL9JFXrOZ9eVdpmw04Tp6aDxZctFLoEDvSWKi367Q7Sg+ci+fH4KwwfQ8Pi0IpIKx2n5emEg
nbOQL1Lv/IcNiep6Cq3DiyaSpSp/RZf+CAfUNySHS8eWmhLU6jGpSD6hxTpYKye7PmrmvMWwfGEP
WoamAV1kSTb9z/9m9Q2LXa89aKmTxNwnAfD3Ohn9mtU3JukwILRMewn9QRXK7KzM+01h5hkCE4nj
W9q/VGFknNhqfhrWBTSQoE9CSVylASGrjzCgS7XmKy/BaH3/7mOOHQv5g1o3Qj/+cdKnpT0I5Qb1
nRy+c7wUzo9OqydJtxzSP4ZyHA4dELto/a3m/ay1XHcpum1pgTOLgxAfGb/T4dCkwRUstSKLMmpL
g9Y9TrN9BM4xn24tBFFyL5znGG0wQGzOVAM68RBzIQb6Fz758fjsr4yZnPbVsU1+gHEs/puNHrG0
9e1EQXmUtfGn4InoopJuU8p5VGD9S3Ikd4UoBlc7xl5yjtNlQxUeYrRlnUSmdlucCEoTX1n4UmtA
9CuVHSA7eUHO7I88CtWG9bGOU7tLgOZoSEvNqtaL/N7sQbBZK4jZ4Rr/zNTQg1SwYjjLB7u96lDP
sipoCi8BfR35/ViNuYJWwDCOEua94WM3AgMBAAGjggGwMIIBrDAfBgNVHSMEGDAWgBSJSAjqIE53
a4blgcjX4Y1khH/8cDAdBgNVHQ4EFgQUXGIam3Bs59Y60yTmWgfDu6pZQ6cwMAYDVR0RBCkwJ4ET
ZHdtdzJAaW5mcmFkZWFkLm9yZ4EQZGF2aWRAd29vZGhvdS5zZTAUBgNVHSAEDTALMAkGB2eBDAEF
AQEwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDB7BgNVHR8E
dDByMDegNaAzhjFodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVtYWlsRzIu
Y3JsMDegNaAzhjFodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVtYWlsRzIu
Y3JsMHYGCCsGAQUFBwEBBGowaDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29t
MEAGCCsGAQUFBzAChjRodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVt
YWlsRzIuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQBBdzgU+I8tGdMO+Y4AETOQi6aiN9kB7lKWe5Ch
4VR+L4uxYIqIHxR7G2+IEC9ugqEu43p4b80LpY7M4KmmfiaRDFGQ50s1OHAwdbR3X2OtkUQq0Qb9
6ln+HD8N1JxO5nabuKbymki0BPoZcPdo+FeRecmkL/NOzzm41JBHrhwRwEWOOhAO5KxN4nkMBZ/w
QzKEy4PylxurHmRG/K0k+xYFDO/UOx2/YsM8s138lQqEdKCvudtSvj5oA/Y8dNcZwQGHyVN5h5r2
nh3mT3r2l7Q4dgxXlovERGpNqCZJ624jCiWQC4ELMD2+6WDxjj03PbOulQZ8oY4PQUyp6djF0keA
MYIDuzCCA7cCAQEwVTBBMQswCQYDVQQGEwJBVTEQMA4GA1UEChMHVmVyb2tleTEgMB4GA1UEAxMX
VmVyb2tleSBTZWN1cmUgRW1haWwgRzICEAfkkQ9qA1FdgOJE92VzW+AwDQYJYIZIAWUDBAIBBQCg
ggE3MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTI1MDEwMjEzNDA0
NFowLwYJKoZIhvcNAQkEMSIEIDUwqzfQxPc+HaOfqtpRWO5Rf/HauguEWk83YSkakwpOMGQGCSsG
AQQBgjcQBDFXMFUwQTELMAkGA1UEBhMCQVUxEDAOBgNVBAoTB1Zlcm9rZXkxIDAeBgNVBAMTF1Zl
cm9rZXkgU2VjdXJlIEVtYWlsIEcyAhAH5JEPagNRXYDiRPdlc1vgMGYGCyqGSIb3DQEJEAILMVeg
VTBBMQswCQYDVQQGEwJBVTEQMA4GA1UEChMHVmVyb2tleTEgMB4GA1UEAxMXVmVyb2tleSBTZWN1
cmUgRW1haWwgRzICEAfkkQ9qA1FdgOJE92VzW+AwDQYJKoZIhvcNAQEBBQAEggIAr4S7rxlagx1c
9wh0lNoVXvLKYFaoAwFADYW/JRzu9XcwebnGA6Zb0xlAQjh0T/wFMAcbXqpIGMvtzJimKPVkSZgi
azWY5K1BJf+0NwALOpH1NrVrGolTt6V3B6Rcoihdlnge8/QNizeggzTqi8FEy4C+BjtRNXU7tOUS
SgAkUt2qegRlqOL64DLdcanZDTM8EDcxpSEth2H+5hOis297dYHdwMHioBbaaJVjjb8j28ngOYrg
afNoYOaV1Hez4OL82fwmI6YYA5YKPdhlqzUvNG7GbvC4SIUO82AV4f+v2qpg40dvCg61KM4SdqPA
J1VZCDd8eMJk1wweZasJRgLvVg8AGVAjR+frG8gwkuVuetez6InWO/L369pc/Qs11s2BaqQ4tz1N
SUiX6Auf48efCyUwVNhjHu3oGSmb08tzIi7UgVQCAgdEoCNanGQreUIygCX8UkfpxZCKuz9iqrEr
rwwr+A65GPp3WPgdR/cXEAaW6GklQDjk4hoTBgjn09dcf7hKp9PiyE6XGvLU9/DnsIXLY8QXvdDn
3NESrkzOnrTKhUE/bD29dDxKYZ3cvt/Thqa+J4NB+X17MSwOaw8pL4ji6UBksk6GBF/cw26kXQK2
Pg7kQ+ervXyOEkztp11rJujCeCze3RSYxfMwCYU8UuXqDBFbjgF5DjuPRZR8pU4AAAAAAAA=


--=-ZSqhNB+07rLVAUqGo4d1--


From xen-devel-bounces@lists.xenproject.org Thu Jan 02 14:03:03 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 14:03:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864004.1275324 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTLmo-0000KF-AL; Thu, 02 Jan 2025 14:02:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864004.1275324; Thu, 02 Jan 2025 14:02:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTLmo-0000K8-7g; Thu, 02 Jan 2025 14:02:54 +0000
Received: by outflank-mailman (input) for mailman id 864004;
 Thu, 02 Jan 2025 14:02:52 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=RDYY=T2=suse.com=jgross@srs-se1.protection.inumbo.net>)
 id 1tTLmm-0000Jn-NG
 for xen-devel@lists.xen.org; Thu, 02 Jan 2025 14:02:52 +0000
Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com
 [2a00:1450:4864:20::442])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4122488e-c912-11ef-a0db-8be0dac302b0;
 Thu, 02 Jan 2025 15:02:51 +0100 (CET)
Received: by mail-wr1-x442.google.com with SMTP id
 ffacd0b85a97d-385de9f789cso8529670f8f.2
 for <xen-devel@lists.xen.org>; Thu, 02 Jan 2025 06:02:51 -0800 (PST)
Received: from ?IPV6:2003:e5:8731:2800:842d:42a0:5992:3595?
 (p200300e587312800842d42a059923595.dip0.t-ipconnect.de.
 [2003:e5:8731:2800:842d:42a0:5992:3595])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c89e43dsm38856245f8f.70.2025.01.02.06.02.49
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 02 Jan 2025 06:02:50 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 4122488e-c912-11ef-a0db-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1735826571; x=1736431371; darn=lists.xen.org;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=nNcuJtlhJ5LXl9Cmsw41uL7uAoRkzt7QZeZpVDDbcsw=;
        b=AFT69sUexFz7xZYE6GFlO7Hm97TJbActl6ME2pdx0iPOKIVqBZ2mSpmxPpJygOhKA8
         g47bnBc+ueiNZW85euOIfhyjOE15B96Sjl+wROYjR4rspi7ZQRz028ozFwecK7QFM/uH
         HS7NNt6ptXmK/4BRN16nR8G6cbTo+JBCQjE1tX3B60xOU7gxhvjvTUaTECjTsUrKm89D
         nqZFs17eEZCLy2K83+cclTKWwBfQbWxs/2DpAxlVIES9XsA/C2KUwFVrTTqu5iKBwl4S
         DCNQlZ13+QrWIgq7n/QiXJhsMOklk9O26OwniVFQ8BNZjHiXmeRMv1pOaqNQpdE1nzLu
         fDRg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735826571; x=1736431371;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=nNcuJtlhJ5LXl9Cmsw41uL7uAoRkzt7QZeZpVDDbcsw=;
        b=pG7cKoGhgWMfrZlIn+f+RgrOsYcMg+gd7I4TPXJwn5tnSxe8ZbHETtao2FzXB/OBuu
         MJ8FKAP+R6Q7gntwFqMUu8phhdZH7bA6LuGClgekYm35hDtCMfI6niJUXUcjigjB5HfE
         JjeL9jJOMt5JDFIldwvBPB3P7/i9GJvl3LTF/PumqjQJV3dFoBttyddyR3M4+aNlYyZP
         k4cxXr4+T+4z47QKU3zyS0k5mNJ8w/E3/zLsSQmQIIMj9DbVua98TWAiCPqWV/1qIC3l
         m9L0X64uVBQgApgoHLNfaXtfMj7M461eW+3dfPv32hddOLxulo8tfkpLJKmmsl+dhu5u
         X7dw==
X-Forwarded-Encrypted: i=1; AJvYcCVEYl8SjidwnG5VtH+gORMAitvrJhRxV3gDDnRafZIPqhUKLDo4+OXgD4FiV1pJpzSKw71M84VEVFU=@lists.xen.org
X-Gm-Message-State: AOJu0YxHr7iB0gOaCciSrpQUMmRwMXs4tgT/FVEROubUsjqPRAX0m5gv
	gj/z5R7ros/Cber3KYq8xBNp0/4R7gBAzPIGj6/gD2FI9PoJIooZmYM+2Bc+Eno=
X-Gm-Gg: ASbGnctQ2oZrnip1p2hwcNa0BZZZ6qessIRbBMkvx4b5rhicVUaK2sX3NzBkmTO20Mx
	xyB9XxIwyMpc6jQFbjeQ3cd4wu6+8/o1uW9Llej9u8WCIzy7Zn4WMvRowozAIRuvHb+jt0EROSx
	7d3ob7Bil2g1lEGkZBhUcKJXLfPIPPLlX0XWHOuO0XW/0EjtvemqaublntPcdoqOJP+rdpFgEqf
	kh/W+2jI/IFxi0WPmw1ZPxQ3Id9aFTlLzzFsEUgR1n7wKXjyfyk69xRZS4HZX18yzTpzkzOYCSe
	mN/ShDyN/m6xFc7MI4UawhsdamW3dq0UEqKxcc+UTvqqewoGtwglYMiNnWTBW+ElkoPFHzUYBTX
	CENP4+Q==
X-Google-Smtp-Source: AGHT+IEqSRq0MK9Ua8bDWNn1H6Gi2bH5zZD+tGEIW8t1h5a8bIxlP2waBjVSvv0f6ptGyK4wTSCR0g==
X-Received: by 2002:a5d:64cf:0:b0:382:3c7b:9ae with SMTP id ffacd0b85a97d-38a221f6746mr41364282f8f.16.1735826570525;
        Thu, 02 Jan 2025 06:02:50 -0800 (PST)
Message-ID: <40734e79-fb55-4712-aae1-3ef350af4f3c@suse.com>
Date: Thu, 2 Jan 2025 15:02:49 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Xen Security Advisory 466 v3 (CVE-2024-53241) - Xen hypercall
 page unsafe against speculative attacks
To: David Woodhouse <dwmw2@infradead.org>,
 "Xen.org security team" <security@xen.org>, xen-announce@lists.xen.org,
 xen-devel@lists.xen.org, xen-users@lists.xen.org,
 oss-security@lists.openwall.com
Cc: "Xen.org security team" <security-team-members@xen.org>
References: <E1tNWXG-00E268-2p@xenbits.xenproject.org>
 <54c892eded2b4ebdda8ee1085c383178f44414ad.camel@infradead.org>
 <a3031e7d-fe9d-4db8-8ccd-923165c9af72@suse.com>
 <fc4c45ea86567ef0c46d7e5a20e8abffa75cc4ec.camel@infradead.org>
 <fd993f8d-280f-439a-a6a0-506e2815f281@suse.com>
 <b7323a9fa5239443b9b6f3daa423196de1051748.camel@infradead.org>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <b7323a9fa5239443b9b6f3daa423196de1051748.camel@infradead.org>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------c0M9FqHxUp1Rk3Wzjq3QJQBR"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------c0M9FqHxUp1Rk3Wzjq3QJQBR
Content-Type: multipart/mixed; boundary="------------9vpxaHT0z3Ue0SWjxQFPzTkK";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: David Woodhouse <dwmw2@infradead.org>,
 "Xen.org security team" <security@xen.org>, xen-announce@lists.xen.org,
 xen-devel@lists.xen.org, xen-users@lists.xen.org,
 oss-security@lists.openwall.com
Cc: "Xen.org security team" <security-team-members@xen.org>
Message-ID: <40734e79-fb55-4712-aae1-3ef350af4f3c@suse.com>
Subject: Re: Xen Security Advisory 466 v3 (CVE-2024-53241) - Xen hypercall
 page unsafe against speculative attacks
References: <E1tNWXG-00E268-2p@xenbits.xenproject.org>
 <54c892eded2b4ebdda8ee1085c383178f44414ad.camel@infradead.org>
 <a3031e7d-fe9d-4db8-8ccd-923165c9af72@suse.com>
 <fc4c45ea86567ef0c46d7e5a20e8abffa75cc4ec.camel@infradead.org>
 <fd993f8d-280f-439a-a6a0-506e2815f281@suse.com>
 <b7323a9fa5239443b9b6f3daa423196de1051748.camel@infradead.org>
In-Reply-To: <b7323a9fa5239443b9b6f3daa423196de1051748.camel@infradead.org>
Autocrypt-Gossip: addr=security@xen.org; keydata=
 xsBNBE+hNqgBCADYua5OFR0/Jeu0rByk+Obk6+SewIeGej1FAcjo+Cvpcr1dfnLBAhmmhbfM
 b++qr6SG6Ek+cUQogYAFvZcEcusbRPy4MIzJkqoPSyOUhCxZoxWNWUfhDdt0TWA3Hs1vYmFO
 e+2jvlL3h7yAsGMYO8jo6ow8ceBEOmf8Q5BLq2OPkNpGcaHEhbSv0VZ3mdHM30ynY6GubIws
 c68LZ5hTORTSjKaj2WVCe4OorBMZte5Im+6MOEUbCjynqPJSU9KNFhIhUuyXp1vn0gZ2N5QS
 pkghpzBJLzeBNEI6ecV3Q0p+/pq8EvEAuUSNLUEbIZ/NSLqyTVMc9HZxnPu59im8wB9rABEB
 AAHNK1hlbi5vcmcgKGluY29taW5nIGVtYWlsKSA8c2VjdXJpdHlAeGVuLm9yZz7CwHgEEwEC
 ACIFAk+hNqgCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEHQ6P8qC06lk1y0H/2Pj
 jQyPDZVS4zIVnR4xQOQ1KphPCdSTPlhj+VVrjZZNXWGCUKvJShL84XIONH62fIgQE/6CTWXJ
 tx6i4u1oAtFH4+8HayFjg609lxx9frJ4tJkJitw5TT6VEGAambchIG5QaP9hepgyrVXjQ0X2
 ot0jgpwL6G3sx0L1gewiMALXtGT6oTqLjXius/nv69yRe26wxU1GX80oWWH/5p585xt54C1X
 nhDEVzp0S9UW7VAAVDCWuSefSrihh3jZi4QE1fnGRwO0RfeLh1sXeuMn9uFIz0CmaCbAp5Pe
 UyNb6wgG60h4JLCDyhJntoHfq8pQLEJ8G9nvjDfw8BLvkBKYNvbOwE0ET6E2qAEIALqWNlGF
 d3uIj+DXZ40/i7fsoPb+HaYaG6Y+7+ZWxMxUeQDTLBnTYiAa+EGVutc4v52BXH8RZc9I/NH9
 lBT2/AwaEVSomxLicbixXUGoFC9kMp/VP1xwWJ+gm+ZEnQzY+2AFJGMvqEsGocQA7yLw121J
 UOrorny3CqpHykPUF3fqp4n/GL47VTaKxlsoV8o2JgZZ62NJlkBtnbA4ODzhWr6cA21smWFg
 sfFJ+EkXb1NEeYLs8CWtTn2EiQXlZTQ8OgBPahfvLZ+AJ4sM/Raoi2c3UIQrlCsg9BoojKMk
 Li8XUrywr8HEJYjhBYObCgbmaeIEfmrw5XJqOKlMg40XY+MAEQEAAcLAXwQYAQIACQUCT6E2
 qAIbDAAKCRB0Oj/KgtOpZDhJB/0XtxrlVuRttpjK1PEYK/A/9h47VH9p0UvVYCH+ZS2a+sTg
 sapx0zp4uni8wtytkvGw/EM06D4ZoaWAUcjXILNKGdi62q/z+WAfdEY/WrONxAbr2Dtv/LT0
 0/2nifYU9O1vGYS1Kx/B3D8fU0w+2Sjv+hYjbGDWn619etC8dNEIxczH6V/cVOZf0D2KhoBf
 MCHUoKeuAfaIKDMxOZjb7sajfUW70cxFFWYqH96Py01oxDroOKzy0x62iVdsYFGB3FvcD9tD
 WsxVWwGHA8DKEfKMuNPiuapzdxdrNm5AQilSUlfD65KK9d3kQdoOUPdPWoIQnz8GnHMPDe99
 7SuwxWGb

--------------9vpxaHT0z3Ue0SWjxQFPzTkK
Content-Type: multipart/mixed; boundary="------------IRz9aSAd8Ft6qHNXUM0HpvSP"

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

T24gMDIuMDEuMjUgMTQ6NDAsIERhdmlkIFdvb2Rob3VzZSB3cm90ZToNCj4gT24gVGh1LCAy
MDI1LTAxLTAyIGF0IDE0OjM4ICswMTAwLCBKw7xyZ2VuIEdyb8OfIHdyb3RlOg0KPj4gT24g
MDIuMDEuMjUgMTM6NTMsIERhdmlkIFdvb2Rob3VzZSB3cm90ZToNCj4+PiBPbiBUaHUsIDIw
MjUtMDEtMDIgYXQgMTM6MDcgKzAxMDAsIErDvHJnZW4gR3Jvw58gd3JvdGU6DQo+Pj4+IE9u
IDIzLjEyLjI0IDE1OjI0LCBEYXZpZCBXb29kaG91c2Ugd3JvdGU6DQo+Pj4+PiBPbiBUdWUs
IDIwMjQtMTItMTcgYXQgMTI6MTggKzAwMDAsIFhlbi5vcmcgc2VjdXJpdHkgdGVhbSB3cm90
ZToNCj4+Pj4+PiAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBYZW4gU2VjdXJpdHkg
QWR2aXNvcnkgQ1ZFLTIwMjQtNTMyNDEgLyBYU0EtNDY2DQo+Pj4+Pj4gIMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oCB2ZXJzaW9uIDMNCj4+Pj4+Pg0KPj4+Pj4+ICDCoMKgwqDCoMKgwqDCoMKgwqDCoCBYZW4g
aHlwZXJjYWxsIHBhZ2UgdW5zYWZlIGFnYWluc3Qgc3BlY3VsYXRpdmUgYXR0YWNrcw0KPj4+
Pj4+DQo+Pj4+Pj4gVVBEQVRFUyBJTiBWRVJTSU9OIDMNCj4+Pj4+PiA9PT09PT09PT09PT09
PT09PT09PQ0KPj4+Pj4+DQo+Pj4+Pj4gVXBkYXRlIG9mIHBhdGNoIDUsIHB1YmxpYyByZWxl
YXNlLg0KPj4+Pj4NCj4+Pj4+IENhbid0IHdlIGV2ZW4gdXNlIHRoZSBoeXBlcmNhbGwgcGFn
ZSBlYXJseSBpbiBib290PyBTdXJlbHkgd2UgaGF2ZSB0bw0KPj4+Pj4ga25vdyB3aGV0aGVy
IHdlJ3JlIHJ1bm5pbmcgb24gYW4gSW50ZWwgb3IgQU1EIENQVSBiZWZvcmUgd2UgZ2V0IHRv
IHRoZQ0KPj4+Pj4gcG9pbnQgd2hlcmUgd2UgY2FuIGVuYWJsZSBhbnkgb2YgdGhlIG5ldyBj
b250cm9sLWZsb3cgaW50ZWdyaXR5DQo+Pj4+PiBzdXBwb3J0PyBEbyB3ZSBuZWVkIHRvIGp1
bXAgdGhyb3VnaCB0aG9zZSBob29wcyBkbyBkbyB0aGF0IGVhcmx5DQo+Pj4+PiBkZXRlY3Rp
b24gYW5kIHNldHVwPw0KPj4+Pg0KPj4+PiBUaGUgZG93bnNpZGUgb2YgdGhpcyBhcHByb2Fj
aCB3b3VsZCBiZSB0byBoYXZlIGFub3RoZXIgdmFyaWFudCB0byBkbw0KPj4+PiBoeXBlcmNh
bGxzLiBTbyB5b3UnZCBoYXZlIHRvIHJlcGxhY2UgdGhlIHZhcmlhbnQgYmVpbmcgYWJsZSB0
byB1c2UgQU1EDQo+Pj4+IG9yIElOVEVMIHNwZWNpZmljIGluc3RydWN0aW9ucyB3aXRoIGEg
ZnVuY3Rpb24gZG9pbmcgdGhlIGh5cGVyY2FsbCB2aWENCj4+Pj4gdGhlIGh5cGVyY2FsbCBw
YWdlLg0KPj4+DQo+Pj4gWW91J2QgcHJvYmFibHkgc3RhcnQgd2l0aCB0aGUgaHlwZXJjYWxs
IGZ1bmN0aW9uIGp1c3QganVtcGluZyBkaXJlY3RseQ0KPj4+IGludG8gdGhlIHRlbXBvcmFy
eSBoeXBlcmNhbGwgcGFnZSBkdXJpbmcgZWFybHkgYm9vdCwgYW5kIHRoZW4geW91J2QNCj4+
PiB1cGRhdGUgdGhlbSB0byB1c2UgdGhlIG5hdGl2ZWx5IHByZXBhcmVkIHZtY2FsbC92bW1j
YWxsIHZlcnNpb24gbGF0ZXIuDQo+Pj4NCj4+PiBBbGwgdGhlIGNvbXBsZXhpdHkgb2YgcGF0
Y2hpbmcgYW5kIENQVSBkZXRlY3Rpb24gaW4gZWFybHkgYm9vdCBzZWVtcyB0bw0KPj4+IGJl
IHNvbWV3aGF0IGdyYXR1aXRvdXMgYW5kIGV2ZW4gY291bnRlci1wcm9kdWN0aXZlIGdpdmVu
IHRoZSBjaGFuZ2UgaXQNCj4+PiBpbnRyb2R1Y2VzIHRvIDY0LWJpdCBsYXRjaGluZy4NCj4+
Pg0KPj4+IEFuZCBldmVuIGlmIHRoZSA2NC1iaXQgbGF0Y2ggZG9lcyBoYXBwZW4gd2hlbiBI
Vk1fUEFSQU1fQ0FMTEJBQ0tfSVJRIGlzDQo+Pj4gc2V0LCBpc24ndCB0aGF0IHBvdGVudGlh
bGx5IGEgbG90IGxhdGVyIGluIGJvb3Q/IFhlbiB3aWxsIGJlIHRyZWF0aW5nDQo+Pj4gdGhp
cyBndWVzdCBhcyAzMi1iaXQgdW50aWwgdGhlbiwgc28gd29uJ3QgYWxsIHRoZSB2Y3B1X2lu
Zm8gYW5kDQo+Pj4gcnVuc3RhdGUgc3RydWN0dXJlcyBiZSB3cm9uZyBldmVuIGFzIHRoZSBz
ZWNvbmRhcnkgQ1BVcyBhcmUgYWxyZWFkeSB1cA0KPj4+IGFuZCBydW5uaW5nPw0KPj4NCj4+
IFdoYXQgSSBkb24ndCBnZXQgaXMgd2h5IHRoaXMgbGF0Y2hpbmcgaXNuJ3QgZG9uZSB3aGVu
IHRoZSBzaGFyZWQgaW5mbw0KPj4gcGFnZSBpcyBtYXBwZWQgaW50byB0aGUgZ3Vlc3Qgdmlh
IHRoZSBYRU5NQVBTUEFDRV9zaGFyZWRfaW5mbyBoeXBlcmNhbGwNCj4+IG9yIG1heWJlIGFk
ZGl0aW9uYWxseSB3aGVuIFZDUFVPUF9yZWdpc3Rlcl9ydW5zdGF0ZV9tZW1vcnlfYXJlYSBp
cyBiZWluZw0KPj4gdXNlZCBieSB0aGUgZ3Vlc3QuDQo+Pg0KPj4gVGhlc2UgYXJlIHRoZSBl
YXJsaWVzdCBwb3NzaWJsZSBjYXNlcyB3aGVyZSB0aGUgZ3Vlc3QgaXMgYWJsZSB0byBhY2Nl
c3MNCj4+IHRoaXMgZGF0YS4NCj4gDQo+IFdlbGwsIHRoYXQncyBhIGdyZWF0IGlkZWEuIEdv
dCBhIHRpbWUgbWFjaGluZT8gSWYgeW91IGhhdmUsIEkgaGF2ZSBzb21lDQo+IGNvbW1lbnRz
IG9uIHRoZSBNU0nihpJQSVJRIG1hcHBpbmcgbm9uc2Vuc2UgdG9vLi4uIDopDQo+IA0KPj4+
DQo+Pj4+IEknbSBwbGFubmluZyB0byBzZW5kIHBhdGNoZXMgZm9yIFhlbiBhbmQgdGhlIGtl
cm5lbCB0byBhZGQgQ1BVSUQgZmVhdHVyZQ0KPj4+PiBiaXRzIGluZGljYXRpbmcgd2hpY2gg
aW5zdHJ1Y3Rpb24gdG8gdXNlLiBUaGlzIHdpbGwgbWFrZSBsaWZlIG11Y2ggZWFzaWVyLg0K
Pj4+Pg0KPj4+Pj4gRW5hYmxpbmcgdGhlIGh5cGVyY2FsbCBwYWdlIGlzIGFsc28gb25lIG9m
IHRoZSB0d28gcG9pbnRzIHdoZXJlIFhlbg0KPj4+Pj4gd2lsbCAnbGF0Y2gnIHRoYXQgdGhl
IGd1ZXN0IGlzIDY0LWJpdCwgd2hpY2ggYWZmZWN0cyB0aGUgbGF5b3V0IG9mIHRoZQ0KPj4+
Pj4gc2hhcmVkX2luZm8sIHZjcHVfaW5mbyBhbmQgcnVuc3RhdGUgc3RydWN0dXJlcy4NCj4+
Pj4+DQo+Pj4+PiBUaGUgb3RoZXIgc3VjaCBsYXRjaGluZyBwb2ludCBpcyB3aGVuIHRoZSBn
dWVzdCBzZXRzDQo+Pj4+PiBIVk1fUEFSQU1fQ0FMTEJBQ0tfSVJRLCBhbmQgSSAqdGhpbmsq
IHRoYXQgc2hvdWxkIHdvcmsgaW4gYWxsDQo+Pj4+PiBpbXBsZW1lbnRhdGlvbnMgb2YgdGhl
IFhlbiBBQkkgKGluY2x1ZGluZyBRRU1VL0tWTSBhbmQgRUMyKS4gQnV0IHdvdWxkDQo+Pj4+
PiB3YW50IHRvIHRlc3QuDQo+Pj4+Pg0KPj4+Pj4gQnV0IHBlcmhhcHMgaXQgd291bGRuJ3Qg
aHVydCBmb3IgbWF4aW1hbCBjb21wYXRpYmlsaXR5IGZvciBMaW51eCB0byBzZXQNCj4+Pj4+
IHRoZSBoeXBlcmNhbGwgcGFnZSAqYW55d2F5KiwgZXZlbiBpZiBMaW51eCBkb2Vzbid0IHRo
ZW4gdXNlIGl0IOKAlCBvcg0KPj4+Pj4gb25seSB1c2VzIGl0IGR1cmluZyBlYXJseSBib290
Pw0KPj4+Pg0KPj4+PiBJJ20gc2VlaW5nIHBvdGVudGlhbCBwcm9ibGVtcyB3aXRoIHRoYXQg
YXBwcm9hY2ggd2hlbiBzb21lb25lIGlzIHVzaW5nDQo+Pj4+IGFuIG91dC1vZi10cmVlIG1v
ZHVsZSBkb2luZyBoeXBlcmNhbGxzLg0KPj4+Pg0KPj4+PiBXaXRoIGhhdmluZyB0aGUgaHlw
ZXJjYWxsIHBhZ2UgcHJlc2VudCBzdWNoIGEgbW9kdWxlIHdvdWxkIGFkZCBhIHdheSB0byBk
bw0KPj4+PiBzcGVjdWxhdGl2ZSBhdHRhY2tzLCB3aGlsZSBkZWxldGluZyB0aGUgaHlwZXJj
YWxsIHBhZ2Ugd291bGQgcmVzdWx0IGluIGENCj4+Pj4gZmFpbHVyZSB0cnlpbmcgdG8gbG9h
ZCBzdWNoIGEgbW9kdWxlLg0KPj4+DQo+Pj4gSXMgdGhhdCBhIHJlc3BvbnNlIHRvIHRoZSBv
cmlnaW5hbCBwYXRjaCBzZXJpZXMsIG9yIHRvIG15IHN1Z2dlc3Rpb24/DQo+Pj4NCj4+PiBJ
ZiB3ZSB0ZW1wb3JhcmlseSBhc2sgWGVuIHRvIHBvcHVsYXRlIGEgaHlwZXJjYWxsIHBhZ2Ug
d2hpY2ggaXMgdXNlZA0KPj4+IGR1cmluZyBlYXJseSBib290IChvciBldmVuIGlmIGl0J3Mg
Km5vdCogdXNlZCwgYW5kIG9ubHkgdXNlZCB0byBtYWtlDQo+Pj4gc3VyZSBYZW4gbGF0Y2hl
cyA2NC1iaXQgbW9kZSBlYXJseSkuLi4gSSBkb24ndCBzZWUgd2h5IHRoYXQgbWFrZXMgYW55
DQo+Pj4gZGlmZmVyZW5jZSB0byBtb2R1bGVzLiBJIHdhc24ndCBzdWdnZXN0aW5nIHdlIGtl
ZXAgaXQgYXJvdW5kIGFuZA0KPj4+ICpleHBvcnQqIGl0Lg0KPj4NCj4+IEFoLCBJIGRpZG4n
dCByZWFkIHlvdXIgc3VnZ2VzdGlvbiB0aGF0IHdheS4NCj4+DQo+PiBTdGlsbCBJIGJlbGll
dmUgdXNpbmcgdGhlIGh5cGVyY2FsbCBwYWdlIGlzIG5vdCBhIGdvb2QgaWRlYSwgZXNwZWNp
YWxseSBhcw0KPj4gd2UnZCBhZGQgYSBoYXJkIGRlcGVuZGVuY3kgb24gdGhlIGFiaWxpdHkg
dG8gZW5hYmxlIENGSSBpbiB0aGUga2VybmVsIHJlbGF0ZWQNCj4+IHRvIHRoZSBzd2l0Y2gg
ZnJvbSB0aGUgaHlwZXJjYWxsIHBhZ2UgdG8gdGhlIG5ldyBkaXJlY3QgaHlwZXJjYWxsIGZ1
bmN0aW9ucy4NCj4gDQo+IEFyZSB5b3Ugc3VnZ2VzdGluZyB0aGF0IHlvdSdyZSBhYmxlIHRv
IGVuYWJsZSB0aGUgQ1BVLXNwZWNpZmljIENGSQ0KPiBwcm90ZWN0aW9ucyBiZWZvcmUgeW91
IGV2ZW4ga25vdyB3aGV0aGVyIGl0J3MgYW4gSW50ZWwgb3IgQU1EIENQVT8NCg0KTm90IGJl
Zm9yZSB0aGF0LCBidXQgbWF5YmUgcmF0aGVyIHNvb24gYWZ0ZXJ3YXJkcy4gQW5kIHRoZSBo
eXBlcmNhbGwgcGFnZQ0KbmVlZHMgdG8gYmUgZGVjb21taXNzaW9uZWQgYmVmb3JlIHRoZSBu
ZXh0IGh5cGVyY2FsbCBpcyBoYXBwZW5pbmcuIFRoZSBxdWVzdGlvbg0KaXMgd2hldGhlciB3
ZSBoYXZlIGEgaG9vayBpbiBwbGFjZSB0byBkbyB0aGF0IHN3aXRjaCBiZXR3ZWVuIGNwdSBp
ZGVudGlmaWNhdGlvbg0KYW5kIENGSSBlbmFibGluZy4NCg0KDQpKdWVyZ2VuDQo=
--------------IRz9aSAd8Ft6qHNXUM0HpvSP
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

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

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

--------------IRz9aSAd8Ft6qHNXUM0HpvSP--

--------------9vpxaHT0z3Ue0SWjxQFPzTkK--

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

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

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmd2nIkFAwAAAAAACgkQsN6d1ii/Ey8/
YAf+NTjlgpdITaqL7CKla5/NUdN0w0oO9s7TPJhcIz4/6ixNURetEnGKrgPs6qOlVEjdEaV0zRbx
Zy8hwcp6x4m5f7BjIjYOHFYAxZBf/o03sRfML4LJw+QwGlube3JrkF/GJN4yo6Cq2Iv50hGKxi4a
ctHxknrM23dyuBucH6/AuvlZKOK6UJxDy0HMYkP7vUMb6HjQ29q2iBcZeyHILWr+85AvTjevZnIx
QtE097oXwsAR7UhPDVModvclg/eS6j6/gml+cZ+ycjK7WtooZ6A/aytLMD1OciCNvWIKRxIilUMh
PN5fo+L540eV/pGrZHF98hfI2OdQhe3mXmFL1H/W8Q==
=sTLL
-----END PGP SIGNATURE-----

--------------c0M9FqHxUp1Rk3Wzjq3QJQBR--


From xen-devel-bounces@lists.xenproject.org Thu Jan 02 14:06:50 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 14:06:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864039.1275363 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTLqY-0002hb-Fo; Thu, 02 Jan 2025 14:06:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864039.1275363; Thu, 02 Jan 2025 14:06:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTLqY-0002hU-Cq; Thu, 02 Jan 2025 14:06:46 +0000
Received: by outflank-mailman (input) for mailman id 864039;
 Thu, 02 Jan 2025 14:06:45 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=bpvf=T2=casper.srs.infradead.org=BATV+b36269e03d8020e3a9b7+7802+infradead.org+dwmw2@srs-se1.protection.inumbo.net>)
 id 1tTLqX-0002gt-Mo
 for xen-devel@lists.xen.org; Thu, 02 Jan 2025 14:06:45 +0000
Received: from casper.infradead.org (casper.infradead.org
 [2001:8b0:10b:1236::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ca274900-c912-11ef-a0db-8be0dac302b0;
 Thu, 02 Jan 2025 15:06:43 +0100 (CET)
Received: from [172.31.31.240] (helo=u09cd745991455d.lumleys.internal)
 by casper.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux))
 id 1tTLqR-0000000GsRi-1xwd; Thu, 02 Jan 2025 14:06:40 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ca274900-c912-11ef-a0db-8be0dac302b0
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:Cc:To:From:Subject:Message-ID:Sender:Reply-To:
	Content-Transfer-Encoding:Content-ID:Content-Description;
	bh=yOer4qYFK47iZZsxbNRWsSp++7OtcFQMfvjcn6Vy0Uk=; b=PWPZUyceGURrIBl77LFth4MM5b
	XHLpqCJrGG9xPm2G96Qw0fKXlCEqVlvrGWSCuQW3wUUexatjaXJ1lHUg6ea+NMNza2WZDyMimKcLZ
	zULVWJ4M9+HjYrp2NyuHdHGMTzD3DqASPwLsIdyCbheSSXwOHsj+Q5NE8GiBBQAevqk00btVoBU1R
	vmxd9czNAZQuGKXHWwlckOf8KiotbsETHONHHyoeG7KkfFichhpz7fXvjdusFgRpwkjTOS3bURMwE
	SW2ijF1FzPN+UZh7lVFF0sXVCGQjZ7oaMTiBavbw7JW0LRvWZ5S1ANefSgdi4cRdjZ1ZdCUi+wVj+
	vFzje7fg==;
Message-ID: <f9b4ae8af70b8b5136b59237c7925f57220b3d5b.camel@infradead.org>
Subject: Re: Xen Security Advisory 466 v3 (CVE-2024-53241) - Xen hypercall
 page unsafe against speculative attacks
From: David Woodhouse <dwmw2@infradead.org>
To: =?ISO-8859-1?Q?J=FCrgen_Gro=DF?= <jgross@suse.com>, "Xen.org security
 team" <security@xen.org>, xen-announce@lists.xen.org,
 xen-devel@lists.xen.org,  xen-users@lists.xen.org,
 oss-security@lists.openwall.com
Cc: "Xen.org security team" <security-team-members@xen.org>
Date: Thu, 02 Jan 2025 14:06:39 +0000
In-Reply-To: <40734e79-fb55-4712-aae1-3ef350af4f3c@suse.com>
References: <E1tNWXG-00E268-2p@xenbits.xenproject.org>
	 <54c892eded2b4ebdda8ee1085c383178f44414ad.camel@infradead.org>
	 <a3031e7d-fe9d-4db8-8ccd-923165c9af72@suse.com>
	 <fc4c45ea86567ef0c46d7e5a20e8abffa75cc4ec.camel@infradead.org>
	 <fd993f8d-280f-439a-a6a0-506e2815f281@suse.com>
	 <b7323a9fa5239443b9b6f3daa423196de1051748.camel@infradead.org>
	 <40734e79-fb55-4712-aae1-3ef350af4f3c@suse.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-VOv0DzH4hgFWVt0+wCe5"
User-Agent: Evolution 3.52.3-0ubuntu1 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html


--=-VOv0DzH4hgFWVt0+wCe5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2025-01-02 at 15:02 +0100, J=C3=BCrgen Gro=C3=9F wrote:
> > Are you suggesting that you're able to enable the CPU-specific CFI
> > protections before you even know whether it's an Intel or AMD CPU?
>=20
> Not before that, but maybe rather soon afterwards. And the hypercall page
> needs to be decommissioned before the next hypercall is happening. The qu=
estion
> is whether we have a hook in place to do that switch between cpu identifi=
cation
> and CFI enabling.

Not sure that's how I'd phrase it. Even if we have to add a hook at the
right time to switch from the Xen-populated hypercall page to the one
filled in by Linux, the question is whether adding that hook is simpler
than all this early static_call stuff that's been thrown together, and
the open questions about the 64-bit latching.

--=-VOv0DzH4hgFWVt0+wCe5
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD9Aw
ggSOMIIDdqADAgECAhAOmiw0ECVD4cWj5DqVrT9PMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0yNDAxMzAwMDAwMDBaFw0zMTEx
MDkyMzU5NTlaMEExCzAJBgNVBAYTAkFVMRAwDgYDVQQKEwdWZXJva2V5MSAwHgYDVQQDExdWZXJv
a2V5IFNlY3VyZSBFbWFpbCBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMjvgLKj
jfhCFqxYyRiW8g3cNFAvltDbK5AzcOaR7yVzVGadr4YcCVxjKrEJOgi7WEOH8rUgCNB5cTD8N/Et
GfZI+LGqSv0YtNa54T9D1AWJy08ZKkWvfGGIXN9UFAPMJ6OLLH/UUEgFa+7KlrEvMUupDFGnnR06
aDJAwtycb8yXtILj+TvfhLFhafxroXrflspavejQkEiHjNjtHnwbZ+o43g0/yxjwnarGI3kgcak7
nnI9/8Lqpq79tLHYwLajotwLiGTB71AGN5xK+tzB+D4eN9lXayrjcszgbOv2ZCgzExQUAIt98mre
8EggKs9mwtEuKAhYBIP/0K6WsoMnQCcCAwEAAaOCAVwwggFYMBIGA1UdEwEB/wQIMAYBAf8CAQAw
HQYDVR0OBBYEFIlICOogTndrhuWByNfhjWSEf/xwMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6en
IZ3zbcgPMA4GA1UdDwEB/wQEAwIBhjAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIweQYI
KwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYIKwYB
BQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RD
QS5jcnQwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0
QXNzdXJlZElEUm9vdENBLmNybDARBgNVHSAECjAIMAYGBFUdIAAwDQYJKoZIhvcNAQELBQADggEB
ACiagCqvNVxOfSd0uYfJMiZsOEBXAKIR/kpqRp2YCfrP4Tz7fJogYN4fxNAw7iy/bPZcvpVCfe/H
/CCcp3alXL0I8M/rnEnRlv8ItY4MEF+2T/MkdXI3u1vHy3ua8SxBM8eT9LBQokHZxGUX51cE0kwa
uEOZ+PonVIOnMjuLp29kcNOVnzf8DGKiek+cT51FvGRjV6LbaxXOm2P47/aiaXrDD5O0RF5SiPo6
xD1/ClkCETyyEAE5LRJlXtx288R598koyFcwCSXijeVcRvBB1cNOLEbg7RMSw1AGq14fNe2cH1HG
W7xyduY/ydQt6gv5r21mDOQ5SaZSWC/ZRfLDuEYwggWbMIIEg6ADAgECAhAH5JEPagNRXYDiRPdl
c1vgMA0GCSqGSIb3DQEBCwUAMEExCzAJBgNVBAYTAkFVMRAwDgYDVQQKEwdWZXJva2V5MSAwHgYD
VQQDExdWZXJva2V5IFNlY3VyZSBFbWFpbCBHMjAeFw0yNDEyMzAwMDAwMDBaFw0yODAxMDQyMzU5
NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqGSIb3DQEBAQUAA4IC
DwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZeYAS/SRV6zmfXlXaZ
sNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2zkC9S7/yHDYnqegqt
w4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qGpgFdZEk2/c//ZvUN
i12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41vav1RhZJzYan4a1gU0
kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0cvnO8FM6PTqsnSbcc
0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PWPU6zfQTOMZ9uLQRR
ci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXtREF5lLXxp+CJ6KKS
blPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQrlR0gO3lBzuyPPArV
hvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7IqaAovAX0d+f1YjbmC
VsAwjhLmveFjNwIDAQABo4IBsDCCAawwHwYDVR0jBBgwFoAUiUgI6iBOd2uG5YHI1+GNZIR//HAw
HQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3bXcyQGluZnJhZGVh
ZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEBMA4GA1UdDwEB/wQE
AwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwewYDVR0fBHQwcjA3oDWgM4YxaHR0
cDovL2NybDMuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNybDA3oDWgM4YxaHR0
cDovL2NybDQuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNybDB2BggrBgEFBQcB
AQRqMGgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBABggrBgEFBQcwAoY0
aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNydDANBgkq
hkiG9w0BAQsFAAOCAQEAQXc4FPiPLRnTDvmOABEzkIumojfZAe5SlnuQoeFUfi+LsWCKiB8Uextv
iBAvboKhLuN6eG/NC6WOzOCppn4mkQxRkOdLNThwMHW0d19jrZFEKtEG/epZ/hw/DdScTuZ2m7im
8ppItAT6GXD3aPhXkXnJpC/zTs85uNSQR64cEcBFjjoQDuSsTeJ5DAWf8EMyhMuD8pcbqx5kRvyt
JPsWBQzv1Dsdv2LDPLNd/JUKhHSgr7nbUr4+aAP2PHTXGcEBh8lTeYea9p4d5k969pe0OHYMV5aL
xERqTagmSetuIwolkAuBCzA9vulg8Y49Nz2zrpUGfKGOD0FMqenYxdJHgDCCBZswggSDoAMCAQIC
EAfkkQ9qA1FdgOJE92VzW+AwDQYJKoZIhvcNAQELBQAwQTELMAkGA1UEBhMCQVUxEDAOBgNVBAoT
B1Zlcm9rZXkxIDAeBgNVBAMTF1Zlcm9rZXkgU2VjdXJlIEVtYWlsIEcyMB4XDTI0MTIzMDAwMDAw
MFoXDTI4MDEwNDIzNTk1OVowHjEcMBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzCCAiIwDQYJ
KoZIhvcNAQEBBQADggIPADCCAgoCggIBANqWLse95HW2F7FhfH9bugyT/danKmmXrbMnz5GZNAfj
Jl5gBL9JFXrOZ9eVdpmw04Tp6aDxZctFLoEDvSWKi367Q7Sg+ci+fH4KwwfQ8Pi0IpIKx2n5emEg
nbOQL1Lv/IcNiep6Cq3DiyaSpSp/RZf+CAfUNySHS8eWmhLU6jGpSD6hxTpYKye7PmrmvMWwfGEP
WoamAV1kSTb9z/9m9Q2LXa89aKmTxNwnAfD3Ohn9mtU3JukwILRMewn9QRXK7KzM+01h5hkCE4nj
W9q/VGFknNhqfhrWBTSQoE9CSVylASGrjzCgS7XmKy/BaH3/7mOOHQv5g1o3Qj/+cdKnpT0I5Qb1
nRy+c7wUzo9OqydJtxzSP4ZyHA4dELto/a3m/ay1XHcpum1pgTOLgxAfGb/T4dCkwRUstSKLMmpL
g9Y9TrN9BM4xn24tBFFyL5znGG0wQGzOVAM68RBzIQb6Fz758fjsr4yZnPbVsU1+gHEs/puNHrG0
9e1EQXmUtfGn4InoopJuU8p5VGD9S3Ikd4UoBlc7xl5yjtNlQxUeYrRlnUSmdlucCEoTX1n4UmtA
9CuVHSA7eUHO7I88CtWG9bGOU7tLgOZoSEvNqtaL/N7sQbBZK4jZ4Rr/zNTQg1SwYjjLB7u96lDP
sipoCi8BfR35/ViNuYJWwDCOEua94WM3AgMBAAGjggGwMIIBrDAfBgNVHSMEGDAWgBSJSAjqIE53
a4blgcjX4Y1khH/8cDAdBgNVHQ4EFgQUXGIam3Bs59Y60yTmWgfDu6pZQ6cwMAYDVR0RBCkwJ4ET
ZHdtdzJAaW5mcmFkZWFkLm9yZ4EQZGF2aWRAd29vZGhvdS5zZTAUBgNVHSAEDTALMAkGB2eBDAEF
AQEwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDB7BgNVHR8E
dDByMDegNaAzhjFodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVtYWlsRzIu
Y3JsMDegNaAzhjFodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVtYWlsRzIu
Y3JsMHYGCCsGAQUFBwEBBGowaDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29t
MEAGCCsGAQUFBzAChjRodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVt
YWlsRzIuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQBBdzgU+I8tGdMO+Y4AETOQi6aiN9kB7lKWe5Ch
4VR+L4uxYIqIHxR7G2+IEC9ugqEu43p4b80LpY7M4KmmfiaRDFGQ50s1OHAwdbR3X2OtkUQq0Qb9
6ln+HD8N1JxO5nabuKbymki0BPoZcPdo+FeRecmkL/NOzzm41JBHrhwRwEWOOhAO5KxN4nkMBZ/w
QzKEy4PylxurHmRG/K0k+xYFDO/UOx2/YsM8s138lQqEdKCvudtSvj5oA/Y8dNcZwQGHyVN5h5r2
nh3mT3r2l7Q4dgxXlovERGpNqCZJ624jCiWQC4ELMD2+6WDxjj03PbOulQZ8oY4PQUyp6djF0keA
MYIDuzCCA7cCAQEwVTBBMQswCQYDVQQGEwJBVTEQMA4GA1UEChMHVmVyb2tleTEgMB4GA1UEAxMX
VmVyb2tleSBTZWN1cmUgRW1haWwgRzICEAfkkQ9qA1FdgOJE92VzW+AwDQYJYIZIAWUDBAIBBQCg
ggE3MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTI1MDEwMjE0MDYz
OVowLwYJKoZIhvcNAQkEMSIEIMX1tduAKyt+6XmzoGE2//NM0AN6mSTExk8McWhg42d5MGQGCSsG
AQQBgjcQBDFXMFUwQTELMAkGA1UEBhMCQVUxEDAOBgNVBAoTB1Zlcm9rZXkxIDAeBgNVBAMTF1Zl
cm9rZXkgU2VjdXJlIEVtYWlsIEcyAhAH5JEPagNRXYDiRPdlc1vgMGYGCyqGSIb3DQEJEAILMVeg
VTBBMQswCQYDVQQGEwJBVTEQMA4GA1UEChMHVmVyb2tleTEgMB4GA1UEAxMXVmVyb2tleSBTZWN1
cmUgRW1haWwgRzICEAfkkQ9qA1FdgOJE92VzW+AwDQYJKoZIhvcNAQEBBQAEggIAN10+vDSuz8NV
21URdTIqqUmlGBqCJEPwyuja2vDivGHk1w9CGgmy455DirFzfj00en6Qsw1p9f124SK9fWddDMgh
UWArZKDGL1pF6sYgZ0rbH4ZP3qaYa7Hjxg+PmDoMYx1J3TCRc68UnXTWUtR0JMlRhgsONurXNZQ3
gQei4bv40eKY4NvnPK07+iDNuJ3T81iXEZhMgFSYDA3f7o3zBtEygP3nKrJOv4hW3ruNO2ZmSksf
xuSvA1hPiqpqr91RcdliC2iO9fWArVSroZ1eLPuaP6Etige45dFPjrMz7oxGlTM9NqgtO7DQy8L0
6Ko/lWOCepOZ5Rd7FfY/Gr8MVOPOd8MDkrSwGbS0nY9/QCg+APALv0Vsm+QUdaXf9fC2oVeYen+o
acJDz4WVTWNP4UBaR7aPZsOmMlmmGGdGFc9/8FSbRSXkw68FYZO5CQEgyANaS8KQDhdWOiW7a01i
1igY+Vp+jl5IhZ+DU6X49+Gnm6e3zaJ+H3IV43dvwBKR9ieAjk+rhaHOGeYWqCruXI3pOQbLKB3s
EF4ywirCx4oacuVkzqIe/bd/xbRKdsPwVcW7DDTV/Wr9tkLwfFLy4URHd8eGNM0Uu/dLailv932J
S0qWvHJaq2HHkAcfrq34/noIBeFdG4TX93zS4bTfdDviDxe6zMomMCVSQ7hpMQEAAAAAAAA=


--=-VOv0DzH4hgFWVt0+wCe5--


From xen-devel-bounces@lists.xenproject.org Thu Jan 02 14:16:53 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 14:16:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864077.1275378 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTM0F-0005Ag-Pa; Thu, 02 Jan 2025 14:16:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864077.1275378; Thu, 02 Jan 2025 14:16:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTM0F-0005AY-Mn; Thu, 02 Jan 2025 14:16:47 +0000
Received: by outflank-mailman (input) for mailman id 864077;
 Thu, 02 Jan 2025 14:16: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 <SRS0=RDYY=T2=suse.com=jgross@srs-se1.protection.inumbo.net>)
 id 1tTM0E-00056n-Ha
 for xen-devel@lists.xen.org; Thu, 02 Jan 2025 14:16:46 +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 31e7b54f-c914-11ef-a0db-8be0dac302b0;
 Thu, 02 Jan 2025 15:16:45 +0100 (CET)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-43618283dedso113701675e9.3
 for <xen-devel@lists.xen.org>; Thu, 02 Jan 2025 06:16:45 -0800 (PST)
Received: from ?IPV6:2003:e5:8731:2800:842d:42a0:5992:3595?
 (p200300e587312800842d42a059923595.dip0.t-ipconnect.de.
 [2003:e5:8731:2800:842d:42a0:5992:3595])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-43661289d3dsm459020945e9.41.2025.01.02.06.16.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 02 Jan 2025 06:16:43 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 31e7b54f-c914-11ef-a0db-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1735827404; x=1736432204; darn=lists.xen.org;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=79l1iDs8UjX35qRld3NaX+5rfISg1qYZwL/Mg3McJOc=;
        b=LX/cn8NdGxh5QeJY+yrwMzDq2E+xBmWw+4FnbfLN46cVoZSQK7C9sd7pXEDaq+Ys1j
         GJ3ijaLmKAimTWhaJ+kkl+MwF4gXwBWOLhZfqAR4QKfdFfQfibtDxBSI90dgCHQpM+h+
         MwAtHGwr0OwjBxyVva4bBjqf8ndBMEuFRY2yxZil45aXE+FA8RqeYXpkk+D2dAYMEjd6
         g3XpkktWs02T0ZU9P6NhDkgMZS6FD2uxeDM3Qg6/MbR04XICWIUeopDZH8rYsmD3+7IK
         NoP6raQYzVTI/6oELrum/QZYA5ZOh4Dly2t5AbHyDfi9Kro8ub4eHJrWKZ6Owjn5mAry
         CKHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735827404; x=1736432204;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=79l1iDs8UjX35qRld3NaX+5rfISg1qYZwL/Mg3McJOc=;
        b=I/NDLoUAEIJ1k717Mu7mjbTAZn+Nyw04OAsA5BAhJ93vAdIWld+lL+vGvjDXIL1kUH
         A1Fv+09GiLt87GUieHgR4sfzsXiSwj3dLmgcXY7PRJD9lbgxV576fHf+5N+DFPx0T/iD
         4HVcBzxiCoI5S/+5zuP9nGstFe9WRt/5XT/azCkA7EPb5vIhPxVFSn312pTeFeGRqtg9
         dZaB6q0KWu4KB+FczAc+V5Fn8oLyPRrMubyPg8wgnBAyvgepKOL8F7HTPbGgBueVrMp3
         38VFUFpgsF2V7bk0PZp/hArnCE4uMa7bn8TZ/wG+11GTrXRDVQClI7p172vgRH9TSreJ
         Z/HA==
X-Forwarded-Encrypted: i=1; AJvYcCWIToeGPAvn1/XE3+J3LeMqjXZpjxDZZhyPtKa/bOaV8wsV3u4V2srPr6fmPdkq/EQjoipqoT0jesY=@lists.xen.org
X-Gm-Message-State: AOJu0Yz4IckD8CF2NOMJf844JLYttXyzeccKp3UIwewPWX/VpAFvvED+
	rWXdeFsqsWWZf/3XhHSJ6uYQOMIwTp5y0LSVm0bd2jBL+Gn6xiuH1KRhBLETksk=
X-Gm-Gg: ASbGncsfK9It5z2e6P0wyAbb1mLbsJ9/TI8gJTdJa8++pItroSyS1hSF4RRUEfu+wcd
	OBNv1U0j2Bmf56BYaKaVm/MNNuszSLN0z5XeCbvbLaFBLUGE/D6XA00wBtRJcsSqPVgDsqLl5rJ
	F39jsapZLZcu3f/8o0bzaSJu6Ub7aJJmBAtkCKVs3HdUwZIcdwy0tI1Dq81sU8zHJYTLYcDgK5X
	sfjLgOOd0Sd1wbpUyWaCL3cit3L+Vqvq7FCQCWtFjtFP4hlfmRMrAyXdEbd94sAOdltoX91wui7
	pU129QQKaJtH37FKaW+I0n1rEVimYvErJGLQ3xg7lUrO8kHE/psNl90AlohXT711txBKl7DbTL0
	d6BbMSg==
X-Google-Smtp-Source: AGHT+IH4ELbhJH8tlMr2DSrSrQ4349PE/c3Zdoc7amFsop0uLPb4fwaDJuKCxXlniLHkvVavLQIt/Q==
X-Received: by 2002:a05:600c:a0a:b0:434:fe62:28c1 with SMTP id 5b1f17b1804b1-43668645ffdmr416988425e9.18.1735827404087;
        Thu, 02 Jan 2025 06:16:44 -0800 (PST)
Message-ID: <fc4170ed-d238-4e1c-817e-3695a7112d9d@suse.com>
Date: Thu, 2 Jan 2025 15:16:42 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Xen Security Advisory 466 v3 (CVE-2024-53241) - Xen hypercall
 page unsafe against speculative attacks
To: David Woodhouse <dwmw2@infradead.org>,
 "Xen.org security team" <security@xen.org>, xen-announce@lists.xen.org,
 xen-devel@lists.xen.org, xen-users@lists.xen.org,
 oss-security@lists.openwall.com
Cc: "Xen.org security team" <security-team-members@xen.org>
References: <E1tNWXG-00E268-2p@xenbits.xenproject.org>
 <54c892eded2b4ebdda8ee1085c383178f44414ad.camel@infradead.org>
 <a3031e7d-fe9d-4db8-8ccd-923165c9af72@suse.com>
 <fc4c45ea86567ef0c46d7e5a20e8abffa75cc4ec.camel@infradead.org>
 <fd993f8d-280f-439a-a6a0-506e2815f281@suse.com>
 <b7323a9fa5239443b9b6f3daa423196de1051748.camel@infradead.org>
 <40734e79-fb55-4712-aae1-3ef350af4f3c@suse.com>
 <f9b4ae8af70b8b5136b59237c7925f57220b3d5b.camel@infradead.org>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <f9b4ae8af70b8b5136b59237c7925f57220b3d5b.camel@infradead.org>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------wp0qlsW66f4Ym0lcgmYGpqv0"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------wp0qlsW66f4Ym0lcgmYGpqv0
Content-Type: multipart/mixed; boundary="------------XZSu9UgLyITEawqz3bzsrt5z";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: David Woodhouse <dwmw2@infradead.org>,
 "Xen.org security team" <security@xen.org>, xen-announce@lists.xen.org,
 xen-devel@lists.xen.org, xen-users@lists.xen.org,
 oss-security@lists.openwall.com
Cc: "Xen.org security team" <security-team-members@xen.org>
Message-ID: <fc4170ed-d238-4e1c-817e-3695a7112d9d@suse.com>
Subject: Re: Xen Security Advisory 466 v3 (CVE-2024-53241) - Xen hypercall
 page unsafe against speculative attacks
References: <E1tNWXG-00E268-2p@xenbits.xenproject.org>
 <54c892eded2b4ebdda8ee1085c383178f44414ad.camel@infradead.org>
 <a3031e7d-fe9d-4db8-8ccd-923165c9af72@suse.com>
 <fc4c45ea86567ef0c46d7e5a20e8abffa75cc4ec.camel@infradead.org>
 <fd993f8d-280f-439a-a6a0-506e2815f281@suse.com>
 <b7323a9fa5239443b9b6f3daa423196de1051748.camel@infradead.org>
 <40734e79-fb55-4712-aae1-3ef350af4f3c@suse.com>
 <f9b4ae8af70b8b5136b59237c7925f57220b3d5b.camel@infradead.org>
In-Reply-To: <f9b4ae8af70b8b5136b59237c7925f57220b3d5b.camel@infradead.org>
Autocrypt-Gossip: addr=security@xen.org; keydata=
 xsBNBE+hNqgBCADYua5OFR0/Jeu0rByk+Obk6+SewIeGej1FAcjo+Cvpcr1dfnLBAhmmhbfM
 b++qr6SG6Ek+cUQogYAFvZcEcusbRPy4MIzJkqoPSyOUhCxZoxWNWUfhDdt0TWA3Hs1vYmFO
 e+2jvlL3h7yAsGMYO8jo6ow8ceBEOmf8Q5BLq2OPkNpGcaHEhbSv0VZ3mdHM30ynY6GubIws
 c68LZ5hTORTSjKaj2WVCe4OorBMZte5Im+6MOEUbCjynqPJSU9KNFhIhUuyXp1vn0gZ2N5QS
 pkghpzBJLzeBNEI6ecV3Q0p+/pq8EvEAuUSNLUEbIZ/NSLqyTVMc9HZxnPu59im8wB9rABEB
 AAHNK1hlbi5vcmcgKGluY29taW5nIGVtYWlsKSA8c2VjdXJpdHlAeGVuLm9yZz7CwHgEEwEC
 ACIFAk+hNqgCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEHQ6P8qC06lk1y0H/2Pj
 jQyPDZVS4zIVnR4xQOQ1KphPCdSTPlhj+VVrjZZNXWGCUKvJShL84XIONH62fIgQE/6CTWXJ
 tx6i4u1oAtFH4+8HayFjg609lxx9frJ4tJkJitw5TT6VEGAambchIG5QaP9hepgyrVXjQ0X2
 ot0jgpwL6G3sx0L1gewiMALXtGT6oTqLjXius/nv69yRe26wxU1GX80oWWH/5p585xt54C1X
 nhDEVzp0S9UW7VAAVDCWuSefSrihh3jZi4QE1fnGRwO0RfeLh1sXeuMn9uFIz0CmaCbAp5Pe
 UyNb6wgG60h4JLCDyhJntoHfq8pQLEJ8G9nvjDfw8BLvkBKYNvbOwE0ET6E2qAEIALqWNlGF
 d3uIj+DXZ40/i7fsoPb+HaYaG6Y+7+ZWxMxUeQDTLBnTYiAa+EGVutc4v52BXH8RZc9I/NH9
 lBT2/AwaEVSomxLicbixXUGoFC9kMp/VP1xwWJ+gm+ZEnQzY+2AFJGMvqEsGocQA7yLw121J
 UOrorny3CqpHykPUF3fqp4n/GL47VTaKxlsoV8o2JgZZ62NJlkBtnbA4ODzhWr6cA21smWFg
 sfFJ+EkXb1NEeYLs8CWtTn2EiQXlZTQ8OgBPahfvLZ+AJ4sM/Raoi2c3UIQrlCsg9BoojKMk
 Li8XUrywr8HEJYjhBYObCgbmaeIEfmrw5XJqOKlMg40XY+MAEQEAAcLAXwQYAQIACQUCT6E2
 qAIbDAAKCRB0Oj/KgtOpZDhJB/0XtxrlVuRttpjK1PEYK/A/9h47VH9p0UvVYCH+ZS2a+sTg
 sapx0zp4uni8wtytkvGw/EM06D4ZoaWAUcjXILNKGdi62q/z+WAfdEY/WrONxAbr2Dtv/LT0
 0/2nifYU9O1vGYS1Kx/B3D8fU0w+2Sjv+hYjbGDWn619etC8dNEIxczH6V/cVOZf0D2KhoBf
 MCHUoKeuAfaIKDMxOZjb7sajfUW70cxFFWYqH96Py01oxDroOKzy0x62iVdsYFGB3FvcD9tD
 WsxVWwGHA8DKEfKMuNPiuapzdxdrNm5AQilSUlfD65KK9d3kQdoOUPdPWoIQnz8GnHMPDe99
 7SuwxWGb

--------------XZSu9UgLyITEawqz3bzsrt5z
Content-Type: multipart/mixed; boundary="------------Kd70v4fuM69COeWUhTNOl0ty"

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

T24gMDIuMDEuMjUgMTU6MDYsIERhdmlkIFdvb2Rob3VzZSB3cm90ZToNCj4gT24gVGh1LCAy
MDI1LTAxLTAyIGF0IDE1OjAyICswMTAwLCBKw7xyZ2VuIEdyb8OfIHdyb3RlOg0KPj4+IEFy
ZSB5b3Ugc3VnZ2VzdGluZyB0aGF0IHlvdSdyZSBhYmxlIHRvIGVuYWJsZSB0aGUgQ1BVLXNw
ZWNpZmljIENGSQ0KPj4+IHByb3RlY3Rpb25zIGJlZm9yZSB5b3UgZXZlbiBrbm93IHdoZXRo
ZXIgaXQncyBhbiBJbnRlbCBvciBBTUQgQ1BVPw0KPj4NCj4+IE5vdCBiZWZvcmUgdGhhdCwg
YnV0IG1heWJlIHJhdGhlciBzb29uIGFmdGVyd2FyZHMuIEFuZCB0aGUgaHlwZXJjYWxsIHBh
Z2UNCj4+IG5lZWRzIHRvIGJlIGRlY29tbWlzc2lvbmVkIGJlZm9yZSB0aGUgbmV4dCBoeXBl
cmNhbGwgaXMgaGFwcGVuaW5nLiBUaGUgcXVlc3Rpb24NCj4+IGlzIHdoZXRoZXIgd2UgaGF2
ZSBhIGhvb2sgaW4gcGxhY2UgdG8gZG8gdGhhdCBzd2l0Y2ggYmV0d2VlbiBjcHUgaWRlbnRp
ZmljYXRpb24NCj4+IGFuZCBDRkkgZW5hYmxpbmcuDQo+IA0KPiBOb3Qgc3VyZSB0aGF0J3Mg
aG93IEknZCBwaHJhc2UgaXQuIEV2ZW4gaWYgd2UgaGF2ZSB0byBhZGQgYSBob29rIGF0IHRo
ZQ0KPiByaWdodCB0aW1lIHRvIHN3aXRjaCBmcm9tIHRoZSBYZW4tcG9wdWxhdGVkIGh5cGVy
Y2FsbCBwYWdlIHRvIHRoZSBvbmUNCj4gZmlsbGVkIGluIGJ5IExpbnV4LCB0aGUgcXVlc3Rp
b24gaXMgd2hldGhlciBhZGRpbmcgdGhhdCBob29rIGlzIHNpbXBsZXINCj4gdGhhbiBhbGwg
dGhpcyBlYXJseSBzdGF0aWNfY2FsbCBzdHVmZiB0aGF0J3MgYmVlbiB0aHJvd24gdG9nZXRo
ZXIsIGFuZA0KPiB0aGUgb3BlbiBxdWVzdGlvbnMgYWJvdXQgdGhlIDY0LWJpdCBsYXRjaGlu
Zy4NCg0KVGhpcyBpcyBhIHZhbGlkIHF1ZXN0aW9uLCB5ZXMuIE15IGZpcnN0IHZlcnNpb24g
b2YgdGhlc2UgcGF0Y2hlcyBkaWRuJ3QNCndvcmsgd2l0aCBzdGF0aWNfY2FsbCwgYnV0IHVz
ZWQgdGhlIHBhcmF2aXJ0IGNhbGwgcGF0Y2hpbmcgbWVjaGFuaXNtDQpyZXBsYWNpbmcgYW4g
aW5kaXJlY3QgY2FsbCB3aXRoIGEgZGlyZWN0IG9uZSB2aWEgQUxURVJOQVRJVkVzLiBUaGF0
DQp2ZXJzaW9uIHdhcyBkaXNsaWtlZCBieSBzb21lIGludm9sdmVkIHg4NiBtYWludGFpbmVy
cywgcmVzdWx0aW5nIGluIHRoZQ0KYWRkaXRpb24gb2YgdGhlIGVhcmx5IHN0YXRpY19jYWxs
IHVwZGF0ZSBtZWNoYW5pc20uDQoNCk9uZSB0aGluZyB0byBtZW50aW9uIHJlZ2FyZGluZyB0
aGUgNjQtYml0IGxhdGNoaW5nOiB3aGF0IHdvdWxkIHlvdSBkbw0Kd2l0aCBIVk0gZG9tYWlu
cz8gVGhvc2UgYXJlIHNldHRpbmcgdXAgdGhlIGh5cGVyY2FsbCBwYWdlIHJhdGhlciBsYXRl
Lg0KSW4gY2FzZSB0aGUga2VybmVsIHdvdWxkIHVzZSBDRkksIGVuYWJsaW5nIHdvdWxkIGhh
cHBlbiB3YXkgYmVmb3JlIHRoZQ0KZ3Vlc3Qgd291bGQgaXNzdWUgYW55IGh5cGVyY2FsbCwg
c28gSSBndWVzcyB0aGUgbGF0Y2hpbmcgbmVlZHMgdG8gaGFwcGVuDQpieSBvdGhlciBtZWFu
cyBhbnl3YXkuIE9yIHdvdWxkIHlvdSB3YW50IHRvIHJlZ2lzdGVyIHRoZSBoeXBlcmNhbGwg
cGFnZQ0Kd2l0aG91dCBldmVyIGludGVuZGluZyB0byB1c2UgaXQ/DQoNCg0KSnVlcmdlbg0K

--------------Kd70v4fuM69COeWUhTNOl0ty
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

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

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

--------------Kd70v4fuM69COeWUhTNOl0ty--

--------------XZSu9UgLyITEawqz3bzsrt5z--

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

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

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmd2n8sFAwAAAAAACgkQsN6d1ii/Ey+L
lAgAn+fIhEjUYurkgBAivjBO694YEf7TyDEK+2OkOJzVZHnswXXgeFXAPcC8ztKTHperiCVkHumW
9AYeT+viZlCYlspgSGSdSKnhOrZ999iC0NxD3qUZDcKbH/ZGHdEnwZNEVh71BYeAANE+40h654zy
fk9jGOsveaakcdj2TpNu4I1PoePszaI7PjNPmVa4/pOuJD9cqF9GERP4aqRW35YxRwERd+GPcBd3
jYQySoR41YFKrT4t3b4SzSqb16Whf3YpP7xRYxm3AqLGDsPgaXdKhiRYMOfn4Vc84dL+1E0FEaMY
1RPwI9+7tSIiwIfsoWq2FcxUPmSMsuAXmqIKZH+G4w==
=PsMF
-----END PGP SIGNATURE-----

--------------wp0qlsW66f4Ym0lcgmYGpqv0--


From xen-devel-bounces@lists.xenproject.org Thu Jan 02 14:36:08 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 14:36:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864135.1275411 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTMIo-000383-St; Thu, 02 Jan 2025 14:35:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864135.1275411; Thu, 02 Jan 2025 14:35:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTMIo-00037w-P5; Thu, 02 Jan 2025 14:35:58 +0000
Received: by outflank-mailman (input) for mailman id 864135;
 Thu, 02 Jan 2025 14:35: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
 <SRS0=bpvf=T2=casper.srs.infradead.org=BATV+b36269e03d8020e3a9b7+7802+infradead.org+dwmw2@srs-se1.protection.inumbo.net>)
 id 1tTMIn-00037i-9U
 for xen-devel@lists.xen.org; Thu, 02 Jan 2025 14:35:58 +0000
Received: from casper.infradead.org (casper.infradead.org
 [2001:8b0:10b:1236::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id dfeac556-c916-11ef-a0db-8be0dac302b0;
 Thu, 02 Jan 2025 15:35:55 +0100 (CET)
Received: from [172.31.31.240] (helo=u09cd745991455d.lumleys.internal)
 by casper.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux))
 id 1tTMIk-0000000GuOY-3Qf6; Thu, 02 Jan 2025 14:35:55 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: dfeac556-c916-11ef-a0db-8be0dac302b0
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:Cc:To:From:Subject:Message-ID:Sender:Reply-To:
	Content-Transfer-Encoding:Content-ID:Content-Description;
	bh=KG5IkzKeosI7+4oEJDlmtguBz0CAnrqYVIWD81ZrtUk=; b=sl/WCXzsbWLCVkgvYXp5vSbt4B
	TXD1MkId/G/5F7jmWRCLOpwtlWBJ8VWFJzfpuBV6gbOiqx1LMX35sqlrhT00l4yFNqAQ+OxmBb8Rv
	4iyFYBI5MGS46yivzU2dPsk6tAjEpclAaR2azPubi8BKBtPreXXmjSqKLHfhxLzH+AbAQ8CXB+suH
	EL+UOZy8+wayiowpNhRsf4DRdHMcvefTr7z8KINDUhQQMvIC7KSTH16QNuRDufgDhWeTxH9TW9azd
	jChERMbHuygbWLz508DQPRBrqmogVDwCeUrd0iNLVGFFSRkquFkFZ75/+w9FjTyV5+cIq9okFtnT9
	msaJrDFQ==;
Message-ID: <f1c251654b483475044ca4be35d4c19047034540.camel@infradead.org>
Subject: Re: Xen Security Advisory 466 v3 (CVE-2024-53241) - Xen hypercall
 page unsafe against speculative attacks
From: David Woodhouse <dwmw2@infradead.org>
To: =?ISO-8859-1?Q?J=FCrgen_Gro=DF?= <jgross@suse.com>, "Xen.org security
 team" <security@xen.org>, xen-announce@lists.xen.org,
 xen-devel@lists.xen.org,  xen-users@lists.xen.org,
 oss-security@lists.openwall.com
Cc: "Xen.org security team" <security-team-members@xen.org>
Date: Thu, 02 Jan 2025 14:35:54 +0000
In-Reply-To: <fc4170ed-d238-4e1c-817e-3695a7112d9d@suse.com>
References: <E1tNWXG-00E268-2p@xenbits.xenproject.org>
	 <54c892eded2b4ebdda8ee1085c383178f44414ad.camel@infradead.org>
	 <a3031e7d-fe9d-4db8-8ccd-923165c9af72@suse.com>
	 <fc4c45ea86567ef0c46d7e5a20e8abffa75cc4ec.camel@infradead.org>
	 <fd993f8d-280f-439a-a6a0-506e2815f281@suse.com>
	 <b7323a9fa5239443b9b6f3daa423196de1051748.camel@infradead.org>
	 <40734e79-fb55-4712-aae1-3ef350af4f3c@suse.com>
	 <f9b4ae8af70b8b5136b59237c7925f57220b3d5b.camel@infradead.org>
	 <fc4170ed-d238-4e1c-817e-3695a7112d9d@suse.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-jQbH6hBcOV8IEXh9/WzY"
User-Agent: Evolution 3.52.3-0ubuntu1 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html


--=-jQbH6hBcOV8IEXh9/WzY
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2025-01-02 at 15:16 +0100, J=C3=BCrgen Gro=C3=9F wrote:
> On 02.01.25 15:06, David Woodhouse wrote:
> > On Thu, 2025-01-02 at 15:02 +0100, J=C3=BCrgen Gro=C3=9F wrote:
> > > > Are you suggesting that you're able to enable the CPU-specific CFI
> > > > protections before you even know whether it's an Intel or AMD CPU?
> > >=20
> > > Not before that, but maybe rather soon afterwards. And the hypercall =
page
> > > needs to be decommissioned before the next hypercall is happening. Th=
e question
> > > is whether we have a hook in place to do that switch between cpu iden=
tification
> > > and CFI enabling.
> >=20
> > Not sure that's how I'd phrase it. Even if we have to add a hook at the
> > right time to switch from the Xen-populated hypercall page to the one
> > filled in by Linux, the question is whether adding that hook is simpler
> > than all this early static_call stuff that's been thrown together, and
> > the open questions about the 64-bit latching.
>=20
> This is a valid question, yes. My first version of these patches didn't
> work with static_call, but used the paravirt call patching mechanism
> replacing an indirect call with a direct one via ALTERNATIVEs. That
> version was disliked by some involved x86 maintainers, resulting in the
> addition of the early static_call update mechanism.
>=20
> One thing to mention regarding the 64-bit latching: what would you do
> with HVM domains? Those are setting up the hypercall page rather late.

In the HVM case it's from init_hypervisor_platform which is called from
slightly later in setup_arch(), so it's after static_call_init(). But
still long before HVM_PARAM_CALLBACK_IRQ is set in some cases, I think.

> In case the kernel would use CFI, enabling would happen way before the
> guest would issue any hypercall, so I guess the latching needs to happen
> by other means anyway. Or would you want to register the hypercall page
> without ever intending to use it?

I'd be tempted to do so without using it, yes. You only need to
allocate a 4KiB page, ask Xen to populate it, then free it immediately.
Or maybe just set HVM_PARAM_CALLBACK_IRQ instead, to make sure it's
done? When xen_set_upcall_vector() is called for CPU0 it does that:

        /* Trick toolstack to think we are enlightened. */
        if (!cpu)
                rc =3D xen_set_callback_via(1);

Maybe we just lift that out and do it somewhere unconditional, earlier?

But for PVH I'd still be inclined to set up a hypercall page early and
use it until we are able to switch.

--=-jQbH6hBcOV8IEXh9/WzY
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD9Aw
ggSOMIIDdqADAgECAhAOmiw0ECVD4cWj5DqVrT9PMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0yNDAxMzAwMDAwMDBaFw0zMTEx
MDkyMzU5NTlaMEExCzAJBgNVBAYTAkFVMRAwDgYDVQQKEwdWZXJva2V5MSAwHgYDVQQDExdWZXJv
a2V5IFNlY3VyZSBFbWFpbCBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMjvgLKj
jfhCFqxYyRiW8g3cNFAvltDbK5AzcOaR7yVzVGadr4YcCVxjKrEJOgi7WEOH8rUgCNB5cTD8N/Et
GfZI+LGqSv0YtNa54T9D1AWJy08ZKkWvfGGIXN9UFAPMJ6OLLH/UUEgFa+7KlrEvMUupDFGnnR06
aDJAwtycb8yXtILj+TvfhLFhafxroXrflspavejQkEiHjNjtHnwbZ+o43g0/yxjwnarGI3kgcak7
nnI9/8Lqpq79tLHYwLajotwLiGTB71AGN5xK+tzB+D4eN9lXayrjcszgbOv2ZCgzExQUAIt98mre
8EggKs9mwtEuKAhYBIP/0K6WsoMnQCcCAwEAAaOCAVwwggFYMBIGA1UdEwEB/wQIMAYBAf8CAQAw
HQYDVR0OBBYEFIlICOogTndrhuWByNfhjWSEf/xwMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6en
IZ3zbcgPMA4GA1UdDwEB/wQEAwIBhjAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIweQYI
KwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYIKwYB
BQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RD
QS5jcnQwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0
QXNzdXJlZElEUm9vdENBLmNybDARBgNVHSAECjAIMAYGBFUdIAAwDQYJKoZIhvcNAQELBQADggEB
ACiagCqvNVxOfSd0uYfJMiZsOEBXAKIR/kpqRp2YCfrP4Tz7fJogYN4fxNAw7iy/bPZcvpVCfe/H
/CCcp3alXL0I8M/rnEnRlv8ItY4MEF+2T/MkdXI3u1vHy3ua8SxBM8eT9LBQokHZxGUX51cE0kwa
uEOZ+PonVIOnMjuLp29kcNOVnzf8DGKiek+cT51FvGRjV6LbaxXOm2P47/aiaXrDD5O0RF5SiPo6
xD1/ClkCETyyEAE5LRJlXtx288R598koyFcwCSXijeVcRvBB1cNOLEbg7RMSw1AGq14fNe2cH1HG
W7xyduY/ydQt6gv5r21mDOQ5SaZSWC/ZRfLDuEYwggWbMIIEg6ADAgECAhAH5JEPagNRXYDiRPdl
c1vgMA0GCSqGSIb3DQEBCwUAMEExCzAJBgNVBAYTAkFVMRAwDgYDVQQKEwdWZXJva2V5MSAwHgYD
VQQDExdWZXJva2V5IFNlY3VyZSBFbWFpbCBHMjAeFw0yNDEyMzAwMDAwMDBaFw0yODAxMDQyMzU5
NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqGSIb3DQEBAQUAA4IC
DwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZeYAS/SRV6zmfXlXaZ
sNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2zkC9S7/yHDYnqegqt
w4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qGpgFdZEk2/c//ZvUN
i12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41vav1RhZJzYan4a1gU0
kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0cvnO8FM6PTqsnSbcc
0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PWPU6zfQTOMZ9uLQRR
ci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXtREF5lLXxp+CJ6KKS
blPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQrlR0gO3lBzuyPPArV
hvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7IqaAovAX0d+f1YjbmC
VsAwjhLmveFjNwIDAQABo4IBsDCCAawwHwYDVR0jBBgwFoAUiUgI6iBOd2uG5YHI1+GNZIR//HAw
HQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3bXcyQGluZnJhZGVh
ZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEBMA4GA1UdDwEB/wQE
AwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwewYDVR0fBHQwcjA3oDWgM4YxaHR0
cDovL2NybDMuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNybDA3oDWgM4YxaHR0
cDovL2NybDQuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNybDB2BggrBgEFBQcB
AQRqMGgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBABggrBgEFBQcwAoY0
aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNydDANBgkq
hkiG9w0BAQsFAAOCAQEAQXc4FPiPLRnTDvmOABEzkIumojfZAe5SlnuQoeFUfi+LsWCKiB8Uextv
iBAvboKhLuN6eG/NC6WOzOCppn4mkQxRkOdLNThwMHW0d19jrZFEKtEG/epZ/hw/DdScTuZ2m7im
8ppItAT6GXD3aPhXkXnJpC/zTs85uNSQR64cEcBFjjoQDuSsTeJ5DAWf8EMyhMuD8pcbqx5kRvyt
JPsWBQzv1Dsdv2LDPLNd/JUKhHSgr7nbUr4+aAP2PHTXGcEBh8lTeYea9p4d5k969pe0OHYMV5aL
xERqTagmSetuIwolkAuBCzA9vulg8Y49Nz2zrpUGfKGOD0FMqenYxdJHgDCCBZswggSDoAMCAQIC
EAfkkQ9qA1FdgOJE92VzW+AwDQYJKoZIhvcNAQELBQAwQTELMAkGA1UEBhMCQVUxEDAOBgNVBAoT
B1Zlcm9rZXkxIDAeBgNVBAMTF1Zlcm9rZXkgU2VjdXJlIEVtYWlsIEcyMB4XDTI0MTIzMDAwMDAw
MFoXDTI4MDEwNDIzNTk1OVowHjEcMBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzCCAiIwDQYJ
KoZIhvcNAQEBBQADggIPADCCAgoCggIBANqWLse95HW2F7FhfH9bugyT/danKmmXrbMnz5GZNAfj
Jl5gBL9JFXrOZ9eVdpmw04Tp6aDxZctFLoEDvSWKi367Q7Sg+ci+fH4KwwfQ8Pi0IpIKx2n5emEg
nbOQL1Lv/IcNiep6Cq3DiyaSpSp/RZf+CAfUNySHS8eWmhLU6jGpSD6hxTpYKye7PmrmvMWwfGEP
WoamAV1kSTb9z/9m9Q2LXa89aKmTxNwnAfD3Ohn9mtU3JukwILRMewn9QRXK7KzM+01h5hkCE4nj
W9q/VGFknNhqfhrWBTSQoE9CSVylASGrjzCgS7XmKy/BaH3/7mOOHQv5g1o3Qj/+cdKnpT0I5Qb1
nRy+c7wUzo9OqydJtxzSP4ZyHA4dELto/a3m/ay1XHcpum1pgTOLgxAfGb/T4dCkwRUstSKLMmpL
g9Y9TrN9BM4xn24tBFFyL5znGG0wQGzOVAM68RBzIQb6Fz758fjsr4yZnPbVsU1+gHEs/puNHrG0
9e1EQXmUtfGn4InoopJuU8p5VGD9S3Ikd4UoBlc7xl5yjtNlQxUeYrRlnUSmdlucCEoTX1n4UmtA
9CuVHSA7eUHO7I88CtWG9bGOU7tLgOZoSEvNqtaL/N7sQbBZK4jZ4Rr/zNTQg1SwYjjLB7u96lDP
sipoCi8BfR35/ViNuYJWwDCOEua94WM3AgMBAAGjggGwMIIBrDAfBgNVHSMEGDAWgBSJSAjqIE53
a4blgcjX4Y1khH/8cDAdBgNVHQ4EFgQUXGIam3Bs59Y60yTmWgfDu6pZQ6cwMAYDVR0RBCkwJ4ET
ZHdtdzJAaW5mcmFkZWFkLm9yZ4EQZGF2aWRAd29vZGhvdS5zZTAUBgNVHSAEDTALMAkGB2eBDAEF
AQEwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDB7BgNVHR8E
dDByMDegNaAzhjFodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVtYWlsRzIu
Y3JsMDegNaAzhjFodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVtYWlsRzIu
Y3JsMHYGCCsGAQUFBwEBBGowaDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29t
MEAGCCsGAQUFBzAChjRodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVt
YWlsRzIuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQBBdzgU+I8tGdMO+Y4AETOQi6aiN9kB7lKWe5Ch
4VR+L4uxYIqIHxR7G2+IEC9ugqEu43p4b80LpY7M4KmmfiaRDFGQ50s1OHAwdbR3X2OtkUQq0Qb9
6ln+HD8N1JxO5nabuKbymki0BPoZcPdo+FeRecmkL/NOzzm41JBHrhwRwEWOOhAO5KxN4nkMBZ/w
QzKEy4PylxurHmRG/K0k+xYFDO/UOx2/YsM8s138lQqEdKCvudtSvj5oA/Y8dNcZwQGHyVN5h5r2
nh3mT3r2l7Q4dgxXlovERGpNqCZJ624jCiWQC4ELMD2+6WDxjj03PbOulQZ8oY4PQUyp6djF0keA
MYIDuzCCA7cCAQEwVTBBMQswCQYDVQQGEwJBVTEQMA4GA1UEChMHVmVyb2tleTEgMB4GA1UEAxMX
VmVyb2tleSBTZWN1cmUgRW1haWwgRzICEAfkkQ9qA1FdgOJE92VzW+AwDQYJYIZIAWUDBAIBBQCg
ggE3MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTI1MDEwMjE0MzU1
NFowLwYJKoZIhvcNAQkEMSIEIHr0ATZiMVbFtLlW6OK0osB/u4X2Qk5hSCUYyszQ9ABoMGQGCSsG
AQQBgjcQBDFXMFUwQTELMAkGA1UEBhMCQVUxEDAOBgNVBAoTB1Zlcm9rZXkxIDAeBgNVBAMTF1Zl
cm9rZXkgU2VjdXJlIEVtYWlsIEcyAhAH5JEPagNRXYDiRPdlc1vgMGYGCyqGSIb3DQEJEAILMVeg
VTBBMQswCQYDVQQGEwJBVTEQMA4GA1UEChMHVmVyb2tleTEgMB4GA1UEAxMXVmVyb2tleSBTZWN1
cmUgRW1haWwgRzICEAfkkQ9qA1FdgOJE92VzW+AwDQYJKoZIhvcNAQEBBQAEggIAk1YKq9J7TaTp
xGq1X6MU1fu38hfFs1xX2rIN09VDXHJR8ZSu4RB3NlCcdQZGtbsRrNs36xz5SlBrVgzLgmtGRB0+
8CMVAEjSyUr5nQizEq9Hne+uMo5yRE2iTvq83LEM9NJDljVqzrhi5DqjzbBSWXRBAEHOkqv/2tLa
aZR5rdGPWiOtJ0RiXSGL7xC9tBOj0NNidocaTJJ/2crQ0IdgAFTs0b3AmCrJYhmw3tce3uiTMchM
wZ9bsFL8BERaJo4IWfDM19CF97ALRRusfayZQc1kEhW6aY7WpCDiARSV8ABdwu8eBUaWhgaUIQtq
Lg/eS+oTechxAZ0a5QRNwBbAPTmM+ta1efjISqpnTXj9eQus7dbwECduMBRRqG+rE0R/fHt2VgGn
heH4f5M3Uecj+8mCFYdSnHYdSJTSvEpiuMJF77ZmEx781TUMI2EoGxKbgOMsMLCIyYeBScXRysRY
kA95KqmlpdUKOUQ3rE7Lsab5xW2cdVtqgO3KAI6eVq/9uU1f9jnqTQi0PnNGRwQoBVbNwgwqCs56
RwTh1ilr3HtH4nNZfc4gvlJ5aSnbTciVrCEVQbwig16Jdk+6rf0qfMODatRAgTrZ4EV6F4pH96jA
qXg4oK6Ws8SkwuiclBB4asZFaYezRpE1LtFPLp2aihlArV1Djjc4+jhxLPdzM5kAAAAAAAA=


--=-jQbH6hBcOV8IEXh9/WzY--


From xen-devel-bounces@lists.xenproject.org Thu Jan 02 15:32:11 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 15:32:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864150.1275421 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTNB1-0006aq-TU; Thu, 02 Jan 2025 15:31:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864150.1275421; Thu, 02 Jan 2025 15:31:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTNB1-0006aj-PX; Thu, 02 Jan 2025 15:31:59 +0000
Received: by outflank-mailman (input) for mailman id 864150;
 Thu, 02 Jan 2025 15:31:58 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=11hu=T2=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tTNB0-0006aK-LW
 for xen-devel@lists.xenproject.org; Thu, 02 Jan 2025 15:31:58 +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 b35feaee-c91e-11ef-a0db-8be0dac302b0;
 Thu, 02 Jan 2025 16:31:56 +0100 (CET)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-5d3f28881d6so16512634a12.1
 for <xen-devel@lists.xenproject.org>; Thu, 02 Jan 2025 07:31:56 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0e82f56csm1808981966b.24.2025.01.02.07.31.54
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 02 Jan 2025 07:31:54 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b35feaee-c91e-11ef-a0db-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1735831916; x=1736436716; 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=Mi4l6mQiox6EMT1JrUAeL7uMkXcXkD+Z0FQnXiNFgRY=;
        b=Q/BHfE63qJ/OHs7nwCZiqHxsw3B2tKyCAsq0OODpHoof4/5i3vRXJX5iYtgCLR3lp9
         K212SYfqvTZM2dsrjtXSxRj3B4fyedU1ja0mPEZZvpymC4dVcNfBVQhdqKxmpgGT/xQy
         CGbrUVaY6nAh0eEHKWsH3+XrPpKQij4cc3gzc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735831916; x=1736436716;
        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=Mi4l6mQiox6EMT1JrUAeL7uMkXcXkD+Z0FQnXiNFgRY=;
        b=a47EzMO1X0LtgFoXi1kCJEaLE50vUGHtsgAH8K9xdKHAyhnMJFr87YWHlvknR6vzS8
         V/sKaWOJHZ3hJOI+rg+XTSqZFwTukAP3aI4j6CvCCRnB/rqa9pygQgTuavNOOwvosmIp
         Z3JENxXBFVjQAl+Jv2AS2iO7iuryQCc/n/IYKZ14YD28qsCYPXyrQ/YXXaWH+EFMJoBl
         wgR2H5yR6gh86N8K+fM+HZ87IKKT9lfGsyJU4zqPPQLe/emtZaWLACbK6asYSDBPr2l9
         /zRgknPEJY4f5fP2+OqElTfhXvnHgTCCN4LC+O2JTARSECPqw3Bp5pQKqQqq/Lk9eUMk
         6F+A==
X-Gm-Message-State: AOJu0YxWlFqg+8tUVW4vedtmQeQpa6ShjiIygfwKGAH+CbmBHJxlfqEJ
	o6NmNbhPtBGx0elliaB33l4FiNdDoYaj8g+5uZeXdyC3593FC8moSeBziqysqi4=
X-Gm-Gg: ASbGnctUYKUawNaiQerL46Ef3LozoOmM/hbKTA+h8kB3qLfku/Jjh1xlVsK/h4YHlFK
	uj1pHh9HM8zjJaA+SXis7Q0B+oFsuXS2wQe9KfCbVZpIuHWluCokR0E3DhIRfQCFHoNOlKYejDO
	d2URiURT2mmPnq/NViKZrG92soDHIqKkPDpxDmFymocFJW0eTYiqaMMN/g03iLbGM1qeZ0HYa/P
	5JZxMv2zphHP5/GLZ6m86yPM2uesJeIfQ9kKH5ed0RvbbXjFALnstLfrlBlIg==
X-Google-Smtp-Source: AGHT+IGuR1kQgNPc4pmoSDtxhw/xf1G+uSKr5Flpnta6qR7wyICGxjfydGQRvve1uqApDTnsGJZ9Bw==
X-Received: by 2002:a05:6402:3604:b0:5d9:d58:bcfa with SMTP id 4fb4d7f45d1cf-5d90d58c161mr2173921a12.27.1735831914831;
        Thu, 02 Jan 2025 07:31:54 -0800 (PST)
Date: Thu, 2 Jan 2025 16:31:53 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Xen-devel <xen-devel@lists.xenproject.org>,
	Jan Beulich <JBeulich@suse.com>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>
Subject: Re: [PATCH v3] x86/spec-ctrl: Support for SRSO_U/S_NO and
 SRSO_MSR_FIX
Message-ID: <Z3axaRUXroc9SyzC@macbook.local>
References: <20241220193424.470994-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20241220193424.470994-1-andrew.cooper3@citrix.com>

On Fri, Dec 20, 2024 at 07:34:24PM +0000, Andrew Cooper wrote:
> AMD have updated the SRSO whitepaper[1] with further information.  These
> features exist on AMD Zen5 CPUs and are necessary for Xen to use.
> 
> The two features are in principle unrelated:
> 
>  * SRSO_U/S_NO is an enumeration saying that SRSO attacks can't cross the
>    User(CPL3) / Supervisor(CPL<3) boundary.  i.e. Xen don't need to use
>    IBPB-on-entry for PV64.  PV32 guests are explicitly unsupported for
>    speculative issues, and excluded from consideration for simplicity.
> 
>  * SRSO_MSR_FIX is an enumeration identifying that the BP_SPEC_REDUCE bit is
>    available in MSR_BP_CFG.  When set, SRSO attacks can't cross the host/guest
>    boundary.  i.e. Xen don't need to use IBPB-on-entry for HVM.
> 
> Extend ibpb_calculations() to account for these when calculating
> opt_ibpb_entry_{pv,hvm} defaults.  Add a `bp-spec-reduce=<bool>` option to
> control the use of BP_SPEC_REDUCE, with it active by default.
> 
> Because MSR_BP_CFG is core-scoped with a race condition updating it, repurpose
> amd_check_erratum_1485() into amd_check_bp_cfg() and calculate all updates at
> once.
> 
> Xen also needs to to advertise SRSO_U/S_NO to guests to allow the guest kernel
> to skip SRSO mitigations too:
> 
>  * This is trivial for HVM guests.  It is also is accurate for PV32 guests
>    too, but we have already excluded them from consideration, and do so again
>    here to simplify the policy logic.
> 
>  * As written, SRSO_U/S_NO does not help for the PV64 user->kernel boundary.
>    However, after discussing with AMD, an implementation detail of having
>    BP_SPEC_REDUCE active causes the PV64 user->kernel boundary to have the
>    property described by SRSO_U/S_NO, so we can advertise SRSO_U/S_NO to
>    guests when the BP_SPEC_REDUCE precondition is met.
> 
> Finally, fix a typo in the SRSO_NO's comment.
> 
> [1] https://www.amd.com/content/dam/amd/en/documents/corporate/cr/speculative-return-stack-overflow-whitepaper.pdf
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

FTAOD, my RB tag stands given the changes in v3.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jan 02 16:26:42 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 16:26:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864304.1275495 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTO1p-0003O3-I0; Thu, 02 Jan 2025 16:26:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864304.1275495; Thu, 02 Jan 2025 16:26:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTO1p-0003Nw-Ez; Thu, 02 Jan 2025 16:26:33 +0000
Received: by outflank-mailman (input) for mailman id 864304;
 Thu, 02 Jan 2025 16:26:32 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=xoa/=T2=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tTO1o-0003Nq-H2
 for xen-devel@lists.xenproject.org; Thu, 02 Jan 2025 16:26:32 +0000
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com
 [2a00:1450:4864:20::32b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 52a18910-c926-11ef-99a4-01e77a169b0f;
 Thu, 02 Jan 2025 17:26:30 +0100 (CET)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-4364a37a1d7so121668825e9.3
 for <xen-devel@lists.xenproject.org>; Thu, 02 Jan 2025 08:26:30 -0800 (PST)
Received: from [192.168.86.29] ([83.105.36.37])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436611ea3d5sm461379615e9.5.2025.01.02.08.26.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 02 Jan 2025 08:26:28 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 52a18910-c926-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1735835189; x=1736439989; 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=OS3A3dIMPTMuvov4aIRV5Thj198Bn/2r1Hb/Uku8GWQ=;
        b=E2SQVXPdVu9dOMbYtk1zsueMd1EOqMaYn5riF6SpJ1tsOgmzumr2jHsvnpfD4LE7yX
         BdE7pJa0pKjZ8a5tReZpRbNR2E3lYgeIslZouQZtcFtnwUYeGMbAvKhjf7LvNdzHTnpe
         KVKp/jDO3H3Feh4ll9RA15XBh5JAnHQ8xJ4kc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735835189; x=1736439989;
        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=OS3A3dIMPTMuvov4aIRV5Thj198Bn/2r1Hb/Uku8GWQ=;
        b=slNpnI+LwFcqz224e7cG6w9mrKcDHgaMfH4urbfWzNFY92EnaLAxm3Wt2s33PJ4F1g
         pl3oidlGFKhcE/dKK97VFlrxElUyl64XVja3zzXDNv8L8QapU/1D6P7uzcGsm8TZRESJ
         phbPv3Z0p6ypuSgKCGBmIKrs0KIbSVmFuGl/p0l/jfaBcFLaCX4FukDKZNmCMD0AOgA6
         B02XBiiwrQcAsvK4tiSO8wfp6yKH4m1PbLFPZ4+AsfMoiI5MMKhMhvLYaVbMfHUrc2I8
         s0W9Ie/Vf9WDNRxpGeylWW4qKH6mEzAqy8UMCfFZw9WCnkUfyFcW68lWSBskOIcFywG0
         kWwg==
X-Gm-Message-State: AOJu0YzT8qncaHW8bbpvlaE4cas/elwVG8oU+bFiW8flDgUWiJvsji7l
	LmDh9LIYz7lbOhOodrjOSqpFi0SrOK/xQmegQcenQzrPWyT3HDyJ90Bl1OLZw5h14+x68+9oQ4U
	Zbttnfg==
X-Gm-Gg: ASbGncuUzNNyV0hSDIl9Qt8VdqbAWCivLePLHisVPGs5XZZlXmVQmRfqz1jtQl9Yma3
	BnWj19+cLV+ex8JD9LvByVnb0/eeyHCqhO8s+coXt8ZaIpFvAGYMjJnvic+e//CvXlD69yeIVPS
	+HRv1K/E9IfSEsb5TMEGcMhw5JUIpsdr3pQoV2RVWa8Jsf8cou08ZBu07PJAudJ9vmDZ3yV5dw4
	njrmeO7y2M8XA4uLXit5AzevOlERudi24KEbWhJpsYETsWdoGF7B7pRWqmhZzNNSHc=
X-Google-Smtp-Source: AGHT+IHT4NvASYx3MBl7Exgd3QflQQksVGSRgAU5M8NG9i3cI2Jq5Ea666IF3i+ZNypLs3k0KC4fcw==
X-Received: by 2002:a05:6000:2c8:b0:385:fb2c:6034 with SMTP id ffacd0b85a97d-38a223f830dmr38647465f8f.47.1735835189058;
        Thu, 02 Jan 2025 08:26:29 -0800 (PST)
Message-ID: <0b4d4fa4-7d8e-444e-a4a0-f2dc677178a5@citrix.com>
Date: Thu, 2 Jan 2025 16:26:28 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-GB
To: xen-devel <xen-devel@lists.xenproject.org>
Cc: Jan Beulich <jbeulich@suse.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>,
 Daniel Smith <dpsmith@apertussolutions.com>,
 Frediano Ziglio <frediano.ziglio@cloud.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Xen.efi "must be loaded below 4Gb"
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==
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Hello,

Forwarding a bug report from IRC from before Christmas:

---
bit of a random question, but: has anyone had any luck booting efi
builds of Xen? over the last year or so I've tried 4.18 and 4.19, Alpine
and Fedora builds, and on a Dell PowerEdge R430 and an Optiplex 7010
Plus, and in every case received an error that "Xen must be loaded below
4Gb"
---

The Xen.efi path does expect to be loaded below 4G, and does give up
rather than relocating itself.

Right now, I'm aware of at least one blocker to xen.efi being able to
relocate itself, and that is because it populates the MB1 metadata with
physical pointers into the ebmalloc[] region, which is in .bss.  Fallout
related to this was the subject of c/s 0fe607b2a1 "x86/boot: Fix PVH
boot during boot_info transition period" and a protective ASSERT() included.

The ProperFix(tm) is to remove ebmalloc(), and the scratch space in the
trampoline, and instead have a range in initdata to stash the bootloader
metadata, and use virtual pointers rather than physical.  This also
avoids us double/triple handling the bootloader metadata, simplifying
all aspects of the startup logic.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Jan 02 16:30:15 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 16:30:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864312.1275505 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTO5P-0004rT-0k; Thu, 02 Jan 2025 16:30:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864312.1275505; Thu, 02 Jan 2025 16:30:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTO5O-0004rM-TI; Thu, 02 Jan 2025 16:30:14 +0000
Received: by outflank-mailman (input) for mailman id 864312;
 Thu, 02 Jan 2025 16:30: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
 <SRS0=4GO/=T2=invisiblethingslab.com=marmarek@srs-se1.protection.inumbo.net>)
 id 1tTO5N-0004rG-L3
 for xen-devel@lists.xenproject.org; Thu, 02 Jan 2025 16:30:13 +0000
Received: from fhigh-a2-smtp.messagingengine.com
 (fhigh-a2-smtp.messagingengine.com [103.168.172.153])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d559bc4a-c926-11ef-99a4-01e77a169b0f;
 Thu, 02 Jan 2025 17:30:10 +0100 (CET)
Received: from phl-compute-11.internal (phl-compute-11.phl.internal
 [10.202.2.51])
 by mailfhigh.phl.internal (Postfix) with ESMTP id 43B4A11401BA;
 Thu,  2 Jan 2025 11:30:09 -0500 (EST)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-11.internal (MEProxy); Thu, 02 Jan 2025 11:30:09 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 2 Jan 2025 11:30:07 -0500 (EST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: d559bc4a-c926-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm2; t=1735835409;
	 x=1735921809; bh=EnrVZtCyc86uul8va4wbIgI4fjfehn1muYnUorBvgcQ=; b=
	KXtHBMHKf5I3s5LpxAmqOR85PAM55L1/7VkQUFmYufcHa8e+x1PlDbLchRc70+bK
	miYLPZW7MPbJxvt/IlzsIPod/svMsIk7zXf9grwXE7Bkg/8zHyA4gJY83jws7Goi
	hACiknQKUThukACEXpWFM7vY+Q06Kg0YY/suwMhGU9P+roYPPCXFT8hB9bvNrOV3
	L2zzxYfNBIdP9zG+8sChxQfl0Zyg4/RwJiqc36Jt+Oq5GGsIMA6gtg+5nyzqypgS
	LrUGkp5nyGNC89CXhZmg1qOiwJIjfmCWlzBbcou6WOo7ccFhsBEmT/m66tG3KU/n
	M2T7AYuCE67j9yd0vmKMaw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:subject:subject:to
	:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=
	1735835409; x=1735921809; bh=EnrVZtCyc86uul8va4wbIgI4fjfehn1muYn
	UorBvgcQ=; b=itTOLTB6hKv5vmKW3nGXv+wue+sNo/OWibquZyjkC/RxVJPK0sL
	Phjfa2LK+GT3YN9HkS/dfYOCSC2z259HfcsFShZsJm3BknrVaFaaAIBI24FfDto7
	GKOk/L5yk+HGJLwlk1hFn/OwRUJFff7UAxrKycMJ/mPzod3uBI4DZqVuI5qi96xp
	GSFLrTAO9SFd3GZXOgmSrMa0B2HFArsBaE1iNob0SAXCXP98EYM/HNwbuXIgbCn3
	qGHsr2fgrICuS69Jb+SFvrXTGu6gDMIVV/el+i8nt1LtYO3M6M/ZWSJ7BxKejvs9
	05tGpVCA5msaz/+mRnvoCOpGQTnV6LW1FLg==
X-ME-Sender: <xms:EL92Z-3bd0ttsl8-f7aK8426pz1yYxBOCP-H2yrQrDP48lN97Z-BAQ>
    <xme:EL92ZxGuEV4qrIWkuqadN8VYZZhKm8zUeGDrXWIAd2-vGuDIbgSbfYxtAbIWo7pPX
    ihq1pQAVmXxhA>
X-ME-Received: <xmr:EL92Z2679hzlJWHFkHHPq-vfsgACODMqCiXhaRpdQ-epl2nm9_YicnOxMsCFKNzz0-LZJqNPBx4FcyKoiNBy-g1tBN27Fj3jEQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrudefvddgkeelucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
    rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
    htshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtjeen
    ucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomh
    grrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggft
    rfgrthhtvghrnhepgfduleetfeevhfefheeiteeliefhjefhleduveetteekveettddvge
    euteefjedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhho
    mhepmhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnh
    gspghrtghpthhtohepiedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtoheprghnughr
    vgifrdgtohhophgvrhefsegtihhtrhhigidrtghomhdprhgtphhtthhopeigvghnqdguvg
    hvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdprhgtphhtthhopehjsggv
    uhhlihgthhesshhushgvrdgtohhmpdhrtghpthhtoheprhhoghgvrhdrphgruhestghith
    hrihigrdgtohhmpdhrtghpthhtohepughpshhmihhthhesrghpvghrthhushhsohhluhht
    ihhonhhsrdgtohhmpdhrtghpthhtohepfhhrvgguihgrnhhordiiihhglhhiohestghloh
    huugdrtghomh
X-ME-Proxy: <xmx:EL92Z_0NvnOqltVMOjr2rXd0ZV_dSY-GuGErqeCJyut0zAmgZ2vI2w>
    <xmx:EL92ZxEH_Y9HrPRZi5Smht4za9uLc51TllfhjKiUBGrvTNSPuX8CWw>
    <xmx:EL92Z4_kp2WlE9V8s9_qoyDfiugUwCKOmvksa6V1R3-hzSmSW7lQhg>
    <xmx:EL92Z2lcRkhiRP61Sh6LFoaiTBb5V4O_TWV5lfn47lT8EFQ_ASJlXw>
    <xmx:Eb92Z24W-EuJ85O_g6xiZHiGahaD6WrmGfiLZfxf9CQtD3RROffsroQC>
Feedback-ID: i1568416f:Fastmail
Date: Thu, 2 Jan 2025 17:30:02 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Jan Beulich <jbeulich@suse.com>,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>,
	Daniel Smith <dpsmith@apertussolutions.com>,
	Frediano Ziglio <frediano.ziglio@cloud.com>
Subject: Re: Xen.efi "must be loaded below 4Gb"
Message-ID: <Z3a_Civ7ZZHO0uxH@mail-itl>
References: <0b4d4fa4-7d8e-444e-a4a0-f2dc677178a5@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="CJh7mYvvqb/9K28Z"
Content-Disposition: inline
In-Reply-To: <0b4d4fa4-7d8e-444e-a4a0-f2dc677178a5@citrix.com>


--CJh7mYvvqb/9K28Z
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Thu, 2 Jan 2025 17:30:02 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Jan Beulich <jbeulich@suse.com>,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>,
	Daniel Smith <dpsmith@apertussolutions.com>,
	Frediano Ziglio <frediano.ziglio@cloud.com>
Subject: Re: Xen.efi "must be loaded below 4Gb"

On Thu, Jan 02, 2025 at 04:26:28PM +0000, Andrew Cooper wrote:
> Hello,
>=20
> Forwarding a bug report from IRC from before Christmas:
>=20
> ---
> bit of a random question, but: has anyone had any luck booting efi
> builds of Xen? over the last year or so I've tried 4.18 and 4.19, Alpine
> and Fedora builds, and on a Dell PowerEdge R430 and an Optiplex 7010
> Plus, and in every case received an error that "Xen must be loaded below
> 4Gb"
> ---
>=20
> The Xen.efi path does expect to be loaded below 4G, and does give up
> rather than relocating itself.
>=20
> Right now, I'm aware of at least one blocker to xen.efi being able to
> relocate itself, and that is because it populates the MB1 metadata with
> physical pointers into the ebmalloc[] region, which is in .bss.=C2=A0=20

What about not touching anything MB1-related in the EFI boot path? MB1
can't possibly work on EFI, right?

> Fallout
> related to this was the subject of c/s 0fe607b2a1 "x86/boot: Fix PVH
> boot during boot_info transition period" and a protective ASSERT() includ=
ed.
>=20
> The ProperFix(tm) is to remove ebmalloc(), and the scratch space in the
> trampoline, and instead have a range in initdata to stash the bootloader
> metadata, and use virtual pointers rather than physical.=C2=A0 This also
> avoids us double/triple handling the bootloader metadata, simplifying
> all aspects of the startup logic.

This obviously would be better

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

--CJh7mYvvqb/9K28Z
Content-Type: application/pgp-signature; name="signature.asc"

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmd2vwoACgkQ24/THMrX
1yw8Twf8C8F8IzhFGE7yb84icLNoKHKmXtMYXkbBiz2RTT08HsxCvy1/L2p7HUX1
qa6qz9Ki3+ZHOwBCUL3dQsm3jgyiEsfb2MFVMi1CssJAY75ssyrx/Aa+utT2dp1D
cTpMQ3aUWjlGczfj0UpZ+A2Hs1TF/Y2q313EOC8oQrSSiHrZrlXMOROWkJiFYb16
85I5Pej/sXTely6JecEGCeuQAZWPrfVycKCds6oy13WMI/xKy4Lq8W2z0f2Zsvxs
ib9PBARTZlgsK1+QYPxYPdxuTvp70ccrD0i2SX6r+318YMj/1QqFAKqXMYC14xnV
s7j/DP8AawkztUjLQrZal7odBcxBGQ==
=8wzu
-----END PGP SIGNATURE-----

--CJh7mYvvqb/9K28Z--


From xen-devel-bounces@lists.xenproject.org Thu Jan 02 16:41:55 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 16:41:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864321.1275514 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTOGU-0007TA-Vc; Thu, 02 Jan 2025 16:41:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864321.1275514; Thu, 02 Jan 2025 16:41:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTOGU-0007T3-T2; Thu, 02 Jan 2025 16:41:42 +0000
Received: by outflank-mailman (input) for mailman id 864321;
 Thu, 02 Jan 2025 16:41:41 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=xoa/=T2=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tTOGT-0007RV-7Y
 for xen-devel@lists.xenproject.org; Thu, 02 Jan 2025 16:41:41 +0000
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com
 [2a00:1450:4864:20::335])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6fa4ecf5-c928-11ef-99a4-01e77a169b0f;
 Thu, 02 Jan 2025 17:41:38 +0100 (CET)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-435f8f29f8aso83899345e9.2
 for <xen-devel@lists.xenproject.org>; Thu, 02 Jan 2025 08:41:38 -0800 (PST)
Received: from [192.168.86.29] ([83.105.36.37])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-43656b3b271sm489515685e9.34.2025.01.02.08.41.36
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 02 Jan 2025 08:41:37 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 6fa4ecf5-c928-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1735836097; x=1736440897; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=5HmnMZn0M/FKUnDLXHc9luI7h2dmGrU5jF9kHBTZesw=;
        b=PBnSEeTjkRdUCR0S4NjXFsjmKl255CXk2GVzw/mQ30gYNPw5/6AevcRL61sd9/9JGk
         JVC/7b4N/eB/G84p6EDS5QvWABSlDX+Rws8Xje+Bdk61XJ/ES7UftWCl7P87M6srqSi3
         /J7ETMaCEqzHkOuTjq5Brh6Egkq3S94zP6P7k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735836097; x=1736440897;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=5HmnMZn0M/FKUnDLXHc9luI7h2dmGrU5jF9kHBTZesw=;
        b=anvw0ntWtaneB/eDF2/iq3y21r6cSm6+4hI5NdxJqCXaHJVDBHK706O78SynqaXAFl
         YtoYHwC4aC6xX0AQRZKKHOKFDoNHzflvky6bP5htTnWF9dFzL68K33A+p4IFuMBc52zw
         YkxJdFhvSfnXzc3CGWR88BR/2ywXGFaK7/QSCrRDll3vjW45b251sc+UzmvpfaE8ND/e
         vi6uaMGGNlP9ri06cgr8G1oyw1ZRqPvf1SF0mkW3DQE0d4DQuF5zo+EHx6hAePnpeyfr
         hlU60kfw1KFW0ugfa/ClxC5PS0EHlZeFNlC2RGArBlsLx79DWMjX99waTpAUYM708nPD
         klgA==
X-Gm-Message-State: AOJu0YxJix7iUNw0WWmVHxyNorsrJHWtR6lRuJkZZ94qHOkR3rCGtnMt
	UC5MfZ3XJsM1UM1elVteBuETYKpQK+w/4tYjD5WQ6Mj6kriFLUPFy9lZPdpxsIs=
X-Gm-Gg: ASbGncuCtJ0z840UZ/NXERUJvybSdlpidW0pGUnIv1Di9MFQwJPJZyPGdpA9ElqLDa1
	AGbhSxWN/MwpSPcU+B0OUQPnAjD+qd7aeAbOcsAtlMm2ThRQF7AzHSXn+6rRpP7ykruGrBbryOO
	yf7YqZK/qkUJnIrDw6rtnxa2t72DyGLIXNWhmA8o6KRaIcjZSsp6GzQ9Meno7YF9yT7GRr2s1Sz
	mo1MBLSBBng54Wa7ZZQ8q8YIrivnUiv3F4ftx0ZS3MnnLEXFSk7to9cUWaakJ32i8s=
X-Google-Smtp-Source: AGHT+IGi7bcb7hkyb+/EEwVJzkCJYKAKvkBrH7iqz17+HOgYEOp7acm7PCC5Py7fwXbO1hkZeP0b2A==
X-Received: by 2002:a05:600c:4588:b0:42c:b16e:7a22 with SMTP id 5b1f17b1804b1-43668643348mr414630515e9.12.1735836097581;
        Thu, 02 Jan 2025 08:41:37 -0800 (PST)
Message-ID: <d0a4ac1b-3afd-400e-8ad7-3b0e2c6f19f2@citrix.com>
Date: Thu, 2 Jan 2025 16:41:36 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Xen.efi "must be loaded below 4Gb"
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
 Jan Beulich <jbeulich@suse.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Daniel Smith <dpsmith@apertussolutions.com>,
 Frediano Ziglio <frediano.ziglio@cloud.com>
References: <0b4d4fa4-7d8e-444e-a4a0-f2dc677178a5@citrix.com>
 <Z3a_Civ7ZZHO0uxH@mail-itl>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <Z3a_Civ7ZZHO0uxH@mail-itl>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 02/01/2025 4:30 pm, Marek Marczykowski-Górecki wrote:
> On Thu, Jan 02, 2025 at 04:26:28PM +0000, Andrew Cooper wrote:
>> Hello,
>>
>> Forwarding a bug report from IRC from before Christmas:
>>
>> ---
>> bit of a random question, but: has anyone had any luck booting efi
>> builds of Xen? over the last year or so I've tried 4.18 and 4.19, Alpine
>> and Fedora builds, and on a Dell PowerEdge R430 and an Optiplex 7010
>> Plus, and in every case received an error that "Xen must be loaded below
>> 4Gb"
>> ---
>>
>> The Xen.efi path does expect to be loaded below 4G, and does give up
>> rather than relocating itself.
>>
>> Right now, I'm aware of at least one blocker to xen.efi being able to
>> relocate itself, and that is because it populates the MB1 metadata with
>> physical pointers into the ebmalloc[] region, which is in .bss.  
> What about not touching anything MB1-related in the EFI boot path? MB1
> can't possibly work on EFI, right?

All paths in Xen currently convert bootloader data in MB1 format to
__start_xen().

Then (as of the start of the Hyperlaunch series), __start_xen()
transforms it into struct boot_info.

While it might not sound like it, this was the right course of action
(IMO) for the Hyperlaunch series; there was simply too many things
needing untangling in the boot path to do it all in one go.

>> Fallout
>> related to this was the subject of c/s 0fe607b2a1 "x86/boot: Fix PVH
>> boot during boot_info transition period" and a protective ASSERT() included.
>>
>> The ProperFix(tm) is to remove ebmalloc(), and the scratch space in the
>> trampoline, and instead have a range in initdata to stash the bootloader
>> metadata, and use virtual pointers rather than physical.  This also
>> avoids us double/triple handling the bootloader metadata, simplifying
>> all aspects of the startup logic.
> This obviously would be better
>

The end goal IMO is to have each boot path fill in struct boot_info
directly, but they need somewhere to stash the metadata, and preferably
not in the trampoline.

A 64k region in initdata ought to be sufficient, and anyone needing to
be more fancy can see about stea^W borrowing the BRK infrastructure from
Linux.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Jan 02 16:50:00 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 16:50:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864333.1275525 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTOOS-0008AV-QD; Thu, 02 Jan 2025 16:49:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864333.1275525; Thu, 02 Jan 2025 16:49:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTOOS-0008AO-Nf; Thu, 02 Jan 2025 16:49:56 +0000
Received: by outflank-mailman (input) for mailman id 864333;
 Thu, 02 Jan 2025 16:49: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
 <SRS0=MJ+e=T2=amd.com=Jason.Andryuk@srs-se1.protection.inumbo.net>)
 id 1tTOOS-0008AI-4U
 for xen-devel@lists.xenproject.org; Thu, 02 Jan 2025 16:49:56 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20602.outbound.protection.outlook.com
 [2a01:111:f403:2417::602])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 96d3291c-c929-11ef-a0db-8be0dac302b0;
 Thu, 02 Jan 2025 17:49:54 +0100 (CET)
Received: from MW4PR03CA0185.namprd03.prod.outlook.com (2603:10b6:303:b8::10)
 by CYXPR12MB9426.namprd12.prod.outlook.com (2603:10b6:930:e3::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8314.12; Thu, 2 Jan
 2025 16:49:46 +0000
Received: from CO1PEPF000066E6.namprd05.prod.outlook.com
 (2603:10b6:303:b8:cafe::5d) by MW4PR03CA0185.outlook.office365.com
 (2603:10b6:303:b8::10) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8314.12 via Frontend Transport; Thu,
 2 Jan 2025 16:49:46 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CO1PEPF000066E6.mail.protection.outlook.com (10.167.249.4) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8314.11 via Frontend Transport; Thu, 2 Jan 2025 16:49:45 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 2 Jan
 2025 10:49:45 -0600
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 2 Jan
 2025 10:49:44 -0600
Received: from [172.30.159.138] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Thu, 2 Jan 2025 10:49:44 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 96d3291c-c929-11ef-a0db-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=PKMSFT9ayQ8iRmwM9IiWe5J1rgcMOOfKPMB5/zLICI1JK/2135p/NC+ZPNfW5LVtWYdqWHwAlgbr3iWUwHaf5tP996kl1vTXmy0qug6GQc60GvKU2EKGuIa6Tj7KP9/bBoKRNB7hJiu9ZfJFJ1mnlBUFZJO7Ee0q0+FxHD8IdR58Cs1Qhl+Ewt4pV5McJvEDGHd5Sx8l8/p6t/C0/K1271Krs6JM6EOgkzHvPzXEgQgzGUVobh72Ha0d6wRPTf86fbfVz4efa8WHSHg+VsSzRQYRe8ZRSBGWTqswcgLjOTsiRJt1VxVu6xifZbxpwyto/EN+k+c/7V1/4PWRbwTQtA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=lfGjee9kPrFZtrE6ncOKqMxGcUHSneHAi3J0TWa9F4A=;
 b=w96Nu1Aqxd6iF4GX/qtOBeqAxhQQyB1yEhGkxKsp5tSL3VH7mfX3kM25qixvSIB1ias868iCzGg7iRGeL0ZG2z9vNuhHYUFcKDp4NNKmfVWuP3i29MPnQhXCZzfp436rbOPx/CGdZ5cBNz/YkCdgQjjOgSSULq305rhipp9KZAfc2NBY5SevTPt1k21eXblxK/ddopipNmwyivkz0R0HS6+4i/v2VaCBlmH0Xu1OzHIUqUR/JEGZ4WnLVyH4EBURUv6xTMkjrlCvBIN54vxKUhklL//NZzSV6AMoA3Q9WCDbACYwE/y0Q2fYzIxZsQw4YhkzQUX6UMNqevaQzLFpzA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=xen.org smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=lfGjee9kPrFZtrE6ncOKqMxGcUHSneHAi3J0TWa9F4A=;
 b=aA6BANxinb/+KW63Ae4tPROw6FK0teHPqcscwUDA324tEupj4DjD274dkQSTXVcnOhG/kGyCKrAj2mLdWZV7PN0MBWu+pMWmX8ou4bxBt4qM7rEfE9+kIL/hah9h7UkG9lkgqPbvsHf3omVJEIYkZkijCcTTubXLnuedh5DH9YE=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <1a3abd82-d3dc-4c0a-8328-a746e0b789f7@amd.com>
Date: Thu, 2 Jan 2025 11:49:38 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH] xen/kconfig: allow LATE_HWDOM config for ARM
To: Julien Grall <julien@xen.org>, Sergiy Kibrik <sergiy_kibrik@epam.com>,
	<xen-devel@lists.xenproject.org>
CC: Andrew Cooper <andrew.cooper3@citrix.com>, Anthony PERARD
	<anthony.perard@vates.tech>, Michal Orzel <michal.orzel@amd.com>, Jan Beulich
	<jbeulich@suse.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>, "Daniel P. Smith"
	<dpsmith@apertussolutions.com>
References: <20241217114719.2870676-1-Sergiy_Kibrik@epam.com>
 <4e437c60-4fee-40ed-9d2a-789bac0b36d9@xen.org>
 <5246aa98-d23c-41d5-ba14-c12b0a2ee9af@epam.com>
 <baac9d61-f4bf-4de9-a58c-b354111e3c0c@xen.org>
 <16694707-ce8b-4c4e-a6ec-2190b8124735@epam.com>
 <12f210d1-e117-4b72-a168-1acf47c99a6d@xen.org>
Content-Language: en-US
From: Jason Andryuk <jason.andryuk@amd.com>
In-Reply-To: <12f210d1-e117-4b72-a168-1acf47c99a6d@xen.org>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB05.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CO1PEPF000066E6:EE_|CYXPR12MB9426:EE_
X-MS-Office365-Filtering-Correlation-Id: c77a0ae4-6a78-4f5e-771b-08dd2b4d76ac
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|82310400026|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?bVdBQkpub3hjN1Fta1lNcEI5b1dNWXQxcmZnMnZvWWZwK3V0MEc1ZEp0MzYw?=
 =?utf-8?B?KzN1MkN1b29RaUpsZjN5cFNXcDAwZ0RZazlONW05c2doa0pFb2hwRC9ZKzYw?=
 =?utf-8?B?M21MeHl2dlZ5NDdtNDBsVUUzRFVNc3BmRk1jekEwMFhCMzRrRTJ2K1lndUVv?=
 =?utf-8?B?L3BXSXE1WWNBQ3ZTUVpCMXliMkFrODNQdWNKUUEvL0lObWc0VWs0cVRXNVlo?=
 =?utf-8?B?UWhGSUNOanV2WGdjeUJWd051NUZvOExIdXBERmlkdFRoWmJtOEdMS0pEdlpZ?=
 =?utf-8?B?Y21RNHVwTElkWFFLZnZSYll0MENuRXdiTGxBYjFCbmdSd3FnR3VweDcvYVRa?=
 =?utf-8?B?dHIyK2MvUE4yK0VlWUxGbUdPU1ptOExhUmxLdFVBZmN2eElVaENsT2RraEJQ?=
 =?utf-8?B?SmZWRW5sTUtRd20xaWIveHNCR0VKM1ZyZnZhZnkrbVk4SHh4WmZ2d082aHYx?=
 =?utf-8?B?VXBuUTQzbGJnU3NTZW9iZFVnY2hENHlaSWVhWHlXZGlhblpyN3J1WFhNZ0hC?=
 =?utf-8?B?MkxLS2NqdXpYaUR2b0Z3NVpQTTd3TGtjbE82QS9kZUNkQ25jNUtCdWZRNm5s?=
 =?utf-8?B?M2FpNXBaQlF4Ui8zZEhXVTZsa0tnT0FBY2NlMUVZVjFITHdLbE5oU1FSTGk3?=
 =?utf-8?B?RmhSN1RseUVqRWJZc0REQjNCQmRpSUlNUG9JV3lCT1V3TnUxNDNlQU9QRmJY?=
 =?utf-8?B?REEwUDIvYUQxZ1BuMkJnWXFLWm50RiszK05hcmxDMUJNRVNRMjRiQmRwRytC?=
 =?utf-8?B?dHZvM3FKZk1nRTdqbFBzSzdzemxKZWZJUTlscnpMcGRmeDNHd0VabXRrd0JO?=
 =?utf-8?B?cnFoWUdlSFJ1U2hBSVRqTzlXQno5Zk4xQkowdDM0cElWWnZXczQrZW4rbTRJ?=
 =?utf-8?B?dzVZYjhlVGJJRjl1MGtGZHNobEZjcHh2enZOeDhXbmFSTWVvb09pNjRESlZV?=
 =?utf-8?B?NHNJbEdxU2h2V0taczRqMVRZa2Q3Wmx1MjY0OVBLL0lLTWhuWXp4Nzk5TnZF?=
 =?utf-8?B?WkV1Z0NvWnhJQndFbStpMEJhU3hUZFdkckUrdzE0VnNHMG5DbVo3Z3FEQVla?=
 =?utf-8?B?K0lBRUduYSs0cC92RHZVOVZ0UDd4cTE1TkcwSDFjOUVlTHhHUEE5RVF6S0RH?=
 =?utf-8?B?TE9adjVZU2FmV0pJOHZ2UkR1Zyt1elFGUnFsbVJRSDhQN1lIcUFjcjR6am1o?=
 =?utf-8?B?KzZyNzd6V1FCRW84VkQvQkhkNHlkam5qeWJYeXlpSWFsTVlzY1Z2TEV5UmZz?=
 =?utf-8?B?TkVLQ0FvVnJsdTRkVjBFOUdQMFdLWXNCZ3B5ZHZkdWw5OGFJSmY1TjZaOXF4?=
 =?utf-8?B?akNpOHB4ZnpEdzFlM2pDMlVOS3QrSFUvdEpoWkxqYTVZNmxTYll2cEUrM2Zh?=
 =?utf-8?B?c2hveWRlUXBmVGZNUmIwdHhSbmMweDJEc21zNW9rWWI3S1ZvdkY2VDQ3RURU?=
 =?utf-8?B?enRsakdiTUhMNWlKWGpZdSsxK0tJbzhyU0x2aUZFTnpIRFlGZ2pFemFmY0xZ?=
 =?utf-8?B?MWltYkNVcm1qTnZXNUE0Zk83MHdoZTAwaVE1UEFCMCt0USttYUp6QUsxVlls?=
 =?utf-8?B?dHJHZDNteitNT2o5Z0J2SHVMR0g0dEdXTUQ4cVB3bHIvZDlURE9VVXNnWHkv?=
 =?utf-8?B?QmVKWEdpM0VwUXh3Y0l1UjVqR01McW5qN0hhZXFsS2kvZUR1a2ZyWlgzZVNC?=
 =?utf-8?B?MzV1RUlKUmFSNS9Ibzl1U1BiYkZRSHcvWUFKYnlIaUVlZFJWTUsyR3I1ekZM?=
 =?utf-8?B?NnQvZ3diVWl4YjdwMk1PRWM3cFFteS9WSXNlRVk4UlJpbXVQU25LaFYrZ2hv?=
 =?utf-8?B?bmZYelZCMnpLVXhHOWlhUDFvZWJhRzJFOE5jby94dyt1RWk1TFlnVVVpYWpl?=
 =?utf-8?B?S1YrLzFrUzFFc293cnlnSEI4aG9KQWM2eE9oTUFkN2hrR3JVMXM2TlIyZGlK?=
 =?utf-8?B?SDJidEROdjYvSElxWWttTHlqNFcxMlFiNCtMaW9qWlBSTm5lTVpQY1Rpc01h?=
 =?utf-8?Q?q64yDa1pkv4rQ0eRzEYqUjns8LpTw4=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(82310400026)(1800799024)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Jan 2025 16:49:45.8250
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c77a0ae4-6a78-4f5e-771b-08dd2b4d76ac
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CO1PEPF000066E6.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CYXPR12MB9426

On 2024-12-24 08:54, Julien Grall wrote:
> Hi,
> 
> Replying your last two replies in the same thread.
> 
> 
> On 24/12/2024 03:41, Sergiy Kibrik wrote:
>> 18.12.24 12:05, Julien Grall:
> 
>  > yes, I had to assign devices to hardware domain manually.
> 
> I think it would be easier for the user to say "This is my hardware 
> domain" and let Xen assign all the devices, generate the device-tree & co.
> 
>>>>> On 17/12/2024 11:47, Sergiy Kibrik wrote:
>>>>>> Allow to build ARM configuration with support for initializing 
>>>>>> hardware domain.
>>>>>> On ARM it is only possible to start hardware domain in multiboot 
>>>>>> mode, so
>>>>>> dom0less support is required. This is reflected by dependency on 
>>>>>> DOM0LESS_BOOT
>>>>>> instead of directly depending on ARM config option.
>>>>>
>>>>> I am a bit confused with the explanation. We already have an 
>>>>> hardware domain on Arm. It is dom0. So what are you trying to 
>>>>> achieve? Is this remove some permissions from the hardware domain?
>>>>
>>>> I agree, it should have better description.
>>>> This is to split dom0 permissions into control-only and hardware- 
>>>> only domains, much like it can be done in x86.
>>>
>>> I don't believe you need the late_hwdom feature to do that on Arm. In 
>>> the case of dom0less, you are creating the domains at boot, so at the 
>>> point you can decide who does what.
>>
>> I'm not sure which mechanism to use for this. Can it be done by XSM 
>> policy management?
> 
> For hyperlaunch, Christopher and Daniel proposed to specify the domain 
> permissions (e.g. control domain, hardware domain) in the device-tree. I 
> think we could re-use a similar approach. See docs/designs/launch/ 
> hyperlaunch-devicetree.rst for more details.

This document is not in sync with Dan's latest work ...

>> Indeed, in my case it works only because there's single domain 
>> description in DT.
>> If there're many domains in DT, we can't be sure which domain ID each 
>> of them would receive at boot, right?
> 
> Correct. We don't (and should not) make any guarantee on the ordering. 
> If the domid matters, then we would need to introduce a new property 
> specifying the domain.

... a more up to date one is here (though it could still change):
https://gitlab.com/xen-project/people/dpsmith/xen/-/commit/4387d0cdc9e0c667a764043fd1474687ee626fca

It includes:

"""
domid
::

   Identifies the domid requested to assign to the domain, Optional.

   Value is an integer.

capabilities
::

   This identifies what system capabilities a domain will fulfill. 
Optional, with the default being none.

   Value is a bit field, currently defined bits are:
     1 - Control domain
     2 - Hardware domain
     3 - Xenstore domain

.. note::  All three bits must be set to have a domain function as a 
traditional dom0. If no domain has the Xenstore domain bit set, then 
none of the domains constructed will have a Xenstore event channel and 
ring buffer allocated. The domain with the Hardware domain bit set will 
be the domain that all domains constructed will have their console event 
channel as the destination domain.
"""

These are not parsed by Xen's dom0less code, but they seem 
straightforward to implement and would provide the needed configuration.

Hmmm, looking at the text, the bits are wrong.  The code uses:
#define BUILD_CAPS_NONE          (0)
#define BUILD_CAPS_CONTROL       (1 << 0)
#define BUILD_CAPS_HARDWARE      (1 << 1)
#define BUILD_CAPS_XENSTORE      (1 << 2)

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Thu Jan 02 17:05:33 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 17:05:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864341.1275535 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTOdS-0003Rx-0v; Thu, 02 Jan 2025 17:05:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864341.1275535; Thu, 02 Jan 2025 17:05:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTOdR-0003Rq-U7; Thu, 02 Jan 2025 17:05:25 +0000
Received: by outflank-mailman (input) for mailman id 864341;
 Thu, 02 Jan 2025 17:05:24 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=AqxF=T2=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tTOdQ-0003Rk-CV
 for xen-devel@lists.xenproject.org; Thu, 02 Jan 2025 17:05:24 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org
 [2604:1380:45d1:ec00::3])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c0163c36-c92b-11ef-a0db-8be0dac302b0;
 Thu, 02 Jan 2025 18:05:22 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id C2486A4124B;
 Thu,  2 Jan 2025 17:03:31 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 89764C4CED0;
 Thu,  2 Jan 2025 17:05:18 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c0163c36-c92b-11ef-a0db-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1735837520;
	bh=tD3X7qmk6X5VY3ilQmZOPe49SWy3E0Pbl7DlfgonAmI=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=CbPb5Fbe0IFEk/ewqT6OBZmQ3MCesIFXr5nFks0kCiVEV+b0Gbgm+8SnhIVmUh3SR
	 whBDtk+/mfIcT/nPXnmdddmdPIapZJA6Rzfuaz5t3IgnHmERCcZh6KYbZd7eHl3nln
	 I6zwJtHi4KJEcB5+m+21FNghCHR/GftXPnfgONJQYfvWX3ES30oMeUcKE0/3UJBSBN
	 idtUwRYK/BPsOfc5bkwvyOPhxIvpB+OyEzxaAX5QinY9c8V0D6MovYospgInCkxovi
	 G7NPdft+GFZrbq6njYYKcjv0kJ27ujV/LJHkIH3jo6omd13KK8wlToAHIn7uA4A0LW
	 MLpa8iWW4/zZA==
Date: Thu, 2 Jan 2025 09:05:16 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich <jbeulich@suse.com>
cc: Nicola Vetrini <nicola.vetrini@bugseng.com>, 
    Alessandro Zucchelli <alessandro.zucchelli@bugseng.com>, 
    consulting@bugseng.com, Simone Ballarin <simone.ballarin@bugseng.com>, 
    Doug Goldstein <cardoe@cardoe.com>, xen-devel@lists.xenproject.org, 
    Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, 
    Stefano Stabellini <sstabellini@kernel.org>, 
    Anthony PERARD <anthony.perard@vates.tech>, 
    Michal Orzel <michal.orzel@amd.com>, 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Subject: Re: [PATCH v2] misra: add deviation for MISRA C Rule R11.8.
In-Reply-To: <d9beec69-a167-4768-9bce-5067ab18f0ad@suse.com>
Message-ID: <alpine.DEB.2.22.394.2501020904270.16425@ubuntu-linux-20-04-desktop>
References: <7e4f836606d72769a80299c5451f6f7241471d8a.1734530952.git.alessandro.zucchelli@bugseng.com> <d312a46a-238a-4fa3-84d7-4836c610c8ea@suse.com> <58439457588e585b08b48931e94754b2@bugseng.com> <d9beec69-a167-4768-9bce-5067ab18f0ad@suse.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Thu, 19 Dec 2024, Jan Beulich wrote:
> On 19.12.2024 09:58, Nicola Vetrini wrote:
> > On 2024-12-19 09:49, Jan Beulich wrote:
> >> On 18.12.2024 15:25, Alessandro Zucchelli wrote:
> >>> Rule 11.8 states as following: "A cast shall not remove any `const' or
> >>> `volatile' qualification from the type pointed to by a pointer".
> >>>
> >>> Function `__hvm_copy' in `xen/arch/x86/hvm/hvm.c' is a double-use
> >>> function, where the parameter needs to not be const because it can be
> >>> set for write or not. As it was decided a new const-only function will
> >>> lead to more developer confusion than it's worth, this violation is
> >>> addressed by deviating the function.
> >>> All cases of casting away const-ness are accompanied with a comment
> >>> explaining why it is safe given the other flags passed in; such 
> >>> comment is used
> >>> by the deviation in order to match the appropriate function call.
> >>>
> >>> No functional change.
> >>>
> >>> Signed-off-by: Alessandro Zucchelli <alessandro.zucchelli@bugseng.com>
> >>> ---
> > 
> >>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> >>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> >>> @@ -393,6 +393,12 @@ Fixing this violation would require to increase 
> >>> code complexity and lower readab
> >>>  
> >>> -config=MC3R1.R11.8,reports+={safe,"any_area(any_loc(any_exp(macro(^container_of$))))"}
> >>>  -doc_end
> >>>
> >>> +-doc_begin="Function __hvm_copy in xen/arch/x86/hvm/hvm.c is a 
> >>> double-use
> >>> +function, where the parameter needs to not be const because it can be 
> >>> set for
> >>> +write or not"
> >>> +-config=MC3A2.R11.8,reports+={safe,"any_area(any_loc(text(^.*__hvm_copy.*HVMCOPY_to_guest 
> >>> doesn't modify.*$)))"}
> >>
> >> This is probably good enough for now, yet still: It constrains 
> >> re-formatting
> >> that we may want to do on such function calls. Personally I'd consider 
> >> it
> >> entirely unexpected if I ended up (re)introducing a violation just by 
> >> re-
> >> formatting one of those function calls to
> >>
> >>     return __hvm_copy(
> >>                (void *)buf /* HVMCOPY_to_guest doesn't modify */,
> >>                addr, size, current, HVMCOPY_to_guest | HVMCOPY_linear,
> >>                PFEC_page_present | PFEC_write_access | pfec, pfinfo);
> >>
> >> yet aiui the pattern above would have this effect (I don't think .* 
> >> matches
> >> newlines; instead I expect such regex-es to be applied to individual 
> >> lines
> >> only). Thoughts anyone?
> > 
> > we can simply drop the "__hvm_copy" part from the regex. The regex can 
> > be made multiline, or alternatively we can apply the search to a range 
> > of lines. By default it searches on the same location mentioned by the 
> > report, which in this case is the line containing __hvm_copy (range 
> > defaults to 0..0). However I would leave it either as is or without the 
> > __hvm_copy prefix.
> 
> Omitting the __hvm_copy part would again widen it too much for my taste.

I am also OK with the change as it is. However, I would ask that we also
update docs/misra/deviations.rst with the same


From xen-devel-bounces@lists.xenproject.org Thu Jan 02 17:09:04 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 17:09:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864348.1275544 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTOgw-00041I-EM; Thu, 02 Jan 2025 17:09:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864348.1275544; Thu, 02 Jan 2025 17:09:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTOgw-00041B-Bl; Thu, 02 Jan 2025 17:09:02 +0000
Received: by outflank-mailman (input) for mailman id 864348;
 Thu, 02 Jan 2025 17:09:01 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=AqxF=T2=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tTOgv-000415-Oa
 for xen-devel@lists.xenproject.org; Thu, 02 Jan 2025 17:09:01 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org
 [2604:1380:4641:c500::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4240655d-c92c-11ef-a0db-8be0dac302b0;
 Thu, 02 Jan 2025 18:09:00 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id D0A885C61AB;
 Thu,  2 Jan 2025 17:08:17 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 77676C4CED0;
 Thu,  2 Jan 2025 17:08:57 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 4240655d-c92c-11ef-a0db-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1735837738;
	bh=swDL28UCiug+6IkstA4ntZ9DhdKTiK1toqspmjC/cTM=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=UZZkcxP8XX2eJiFGZIggU23kwQkH9alXoTBctyeSvMi9O/HNUCdQz2efhLX0Buap7
	 oIFjCHlQC5J44ovB09OeZqDx7UJDRtFnk5dB++7XOLP0efYbKkr6XngeF4irMnOch2
	 SsmZNmJuXgzpfwDmhq5c/e8sZ+m0MZA5jn4xr6g76MrbasLANrmG7JR1yxGkZXghYH
	 /tRa4jNUgEgx+bi29I9VjelBRW1AU/dkDfWnmbOUFukrKPbze+OypxBR0f6GtuzrjR
	 rqqARi8E8AGlEKOfeldq/35U2QjeVuQcOfa7e/Pw4v7KXweRkQ8DojHHU5fc/Fl0fR
	 F0gasGI6KMuww==
Date: Thu, 2 Jan 2025 09:08:55 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Ariel Otilibili <Ariel.Otilibili-Anieli@eurecom.fr>
cc: xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, 
    Anthony PERARD <anthony.perard@vates.tech>, 
    Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>, 
    Julien Grall <julien@xen.org>, 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
    Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH 1/1] xen/common: Remove dead code
In-Reply-To: <20241218233659.573195-3-Ariel.Otilibili-Anieli@eurecom.fr>
Message-ID: <alpine.DEB.2.22.394.2501020908160.16425@ubuntu-linux-20-04-desktop>
References: <20241218233659.573195-2-Ariel.Otilibili-Anieli@eurecom.fr> <20241218233659.573195-3-Ariel.Otilibili-Anieli@eurecom.fr>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-65381810-1735837738=:16425"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-65381810-1735837738=:16425
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Thu, 19 Dec 2024, Ariel Otilibili wrote:
> The if-statement tests `res` is non-zero; meaning the case zero is never reached.
> 
> Coverity-ID: 1055253
> Fixes: e2b1ebf4de ("x86: Support booting a bzImage format domain 0 kernel.")
> Signed-off-by: Ariel Otilibili <Ariel.Otilibili-Anieli@eurecom.fr>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


> --
> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
> Cc: Anthony PERARD <anthony.perard@vates.tech>
> Cc: Michal Orzel <michal.orzel@amd.com>
> Cc: Jan Beulich <jbeulich@suse.com>
> Cc: Julien Grall <julien@xen.org>
> Cc: "Roger Pau Monné" <roger.pau@citrix.com>
> Cc: Stefano Stabellini <sstabellini@kernel.org>
> ---
>  xen/common/gzip/inflate.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/xen/common/gzip/inflate.c b/xen/common/gzip/inflate.c
> index b9a2d7a23a..cb146555c8 100644
> --- a/xen/common/gzip/inflate.c
> +++ b/xen/common/gzip/inflate.c
> @@ -1164,8 +1164,6 @@ static int __init gunzip(struct gunzip_state *s)
>      if ( (res = inflate(s)) )
>      {
>          switch (res) {
> -        case 0:
> -            break;
>          case 1:
>              error("invalid compressed format (err=1)");
>              break;
> -- 
> 2.47.1
> 
--8323329-65381810-1735837738=:16425--


From xen-devel-bounces@lists.xenproject.org Thu Jan 02 17:13:40 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 17:13:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864355.1275565 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTOlO-0006KL-8i; Thu, 02 Jan 2025 17:13:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864355.1275565; Thu, 02 Jan 2025 17:13:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTOlO-0006KE-5m; Thu, 02 Jan 2025 17:13:38 +0000
Received: by outflank-mailman (input) for mailman id 864355;
 Thu, 02 Jan 2025 17:13:36 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=NS6K=T2=gmail.com=w1benny@srs-se1.protection.inumbo.net>)
 id 1tTOlM-00065f-6X
 for xen-devel@lists.xenproject.org; Thu, 02 Jan 2025 17:13:36 +0000
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com
 [2a00:1450:4864:20::42b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e5b8eba2-c92c-11ef-99a4-01e77a169b0f;
 Thu, 02 Jan 2025 18:13:34 +0100 (CET)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-385e0d47720so734557f8f.0
 for <xen-devel@lists.xenproject.org>; Thu, 02 Jan 2025 09:13:34 -0800 (PST)
Received: from lab.home
 (dynamic-2a00-1028-83a4-4bca-c0bb-96ff-feed-9d50.ipv6.o2.cz.
 [2a00:1028:83a4:4bca:c0bb:96ff:feed:9d50])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1fa2bdfbsm37802386f8f.102.2025.01.02.09.13.32
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 02 Jan 2025 09:13:32 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e5b8eba2-c92c-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1735838013; x=1736442813; 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=2pCkGEsGgCE2RUpUM015/qmwQ+iljMTVTTCfZJTPvFk=;
        b=E0mSIvTeiW4NXIBAaudPGbmqOPiS8VAALpC/xpWSbwBjjG4gYtR0bsxe7SJH7Vl9ZH
         PTr1/ryEbYjlZP86k7VgnQ9BJNR5yp3i2uigjt/Yy8WBbeNKDL2eBGXA7Ab05SzFjIO9
         MaC6RTgMHLZh1llH9mXpPSdqdNhj599HQJ4luEw5jscpiDiHImU84/Vdr3MOTXF9omvz
         kCwHb777CY73AZNtFLr3Pc2XF4EC7fN0TEn6zFzxGTYfo1GQA7GecxK5JW6D/Ynm6hOq
         K63r6vNCytxR5Y83ul3SGgWxXsaCeEWnBSLXQlgmO9Rvss8Vu+7Cd+hT57bPVK1+eWjJ
         vcmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735838013; x=1736442813;
        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=2pCkGEsGgCE2RUpUM015/qmwQ+iljMTVTTCfZJTPvFk=;
        b=StOIiwT0pFsg/qRIWRDRUUeDX0iaIvoEx5ysRRJbICr45Ov0VlHTHXFlYGi9uZ3p64
         RLczwQFlTCW5RkkPHKL1EZnS1e7cBuf5vSpK9ndlPK9MOVia1TkipnD4kBSddeDqOC3v
         MGiVi+E0BiJA6JqqxLyq7tSEUvKDvCb0ynAvp2f0khziV+DnIWHbnHd0CWC3sddkUF2y
         jxSlQqERoPOmSkvdxGeVRdgFYcAPcfzsokhM2HKvLc8nPZ/xZKvdP4tto6rl6mOB3oXy
         KtVvhexBuT2AebrKP1r7ER4njlBFzEPFZlMsOOV8Z0e1qOHgyOnz5scuWcavAW0tpNhk
         jsWw==
X-Gm-Message-State: AOJu0YyyPv7Pe9s+jHkIqyA+o0XfagtMMFpnD/0hHC71bn+l7WGNrIYV
	oJA8tH96vp3y39jHfspnYhYkQOMFP3J1lhkyDtF5Bar4HeA5pphlvX67TA==
X-Gm-Gg: ASbGncvmUeyQfq410jdjuwV+E4nxyzLnEBp91f+RKrS+v9zncDb472rK+CU7To+JDE2
	9FifGDDtEQLrL5ciICxyycBQidUMLMRv2HjCjXR91WNHvwtSN+4dBHQNLGZ9MZ3AjvvorUSiSqd
	6r7j8Mmdmxmm04z9bsuTntZvFsIIAicz+FnmCt86RgwOjQ9MewGdo8oK7TCpwKt5id1Rd8EYJeP
	Pk9PE5A3mUU/kFjDtkC4swDq9UkNZ062FduOiU/9Yh7smab/uj69RTSzK6A08jsNbL54Kq6H0Ql
	yOz+89DQj9bJyyUWLmAtcSs3nI3ESB3mYahVGTPjkw9FgMwxqUA5BWjW
X-Google-Smtp-Source: AGHT+IGYDpkSNkvHtFM2qH5s7Fu+H5ZZzcNWv6CQkRXAJ3ra1stNszeMpLBpXgsgkabfufbTUswc8g==
X-Received: by 2002:a05:6000:2c3:b0:385:f1bc:7644 with SMTP id ffacd0b85a97d-38a221f9f85mr16921092f8f.6.1735838013338;
        Thu, 02 Jan 2025 09:13:33 -0800 (PST)
From: "=?UTF-8?q?Petr=20Bene=C5=A1?=" <w1benny@gmail.com>
X-Google-Original-From: =?UTF-8?q?Petr=20Bene=C5=A1?= <petr.benes@gendigital.com>
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Petr=20Bene=C5=A1?= <w1benny@gmail.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Tamas K Lengyel <tamas@tklengyel.com>
Subject: [PATCH v3 1/2] x86: Rename _rsvd field to pw and move it to the bit 58
Date: Thu,  2 Jan 2025 17:13:27 +0000
Message-Id: <525e1ef971f06e8f2ef196e52a150820d155a5c0.1735837806.git.w1benny@gmail.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <cover.1735837806.git.w1benny@gmail.com>
References: <cover.1735837806.git.w1benny@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: Petr Beneš <w1benny@gmail.com>

The EPT Paging-write feature (when enabled by the TERTIARY_EXEC_EPT_PAGING_WRITE bit) uses bit 58 of the EPT entry to indicate that guest paging may update the page, even if the W access is not set.

This patch is a preparation for the EPT Paging-write feature.

Signed-off-by: Petr Beneš <w1benny@gmail.com>
Acked-by: Tamas K Lengyel <tamas@tklengyel.com>
---
 xen/arch/x86/include/asm/hvm/vmx/vmx.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/include/asm/hvm/vmx/vmx.h b/xen/arch/x86/include/asm/hvm/vmx/vmx.h
index f0ec459622..d920de96b7 100644
--- a/xen/arch/x86/include/asm/hvm/vmx/vmx.h
+++ b/xen/arch/x86/include/asm/hvm/vmx/vmx.h
@@ -34,8 +34,8 @@ typedef union {
                                EPT/VT-d usage */
         mfn         :   40, /* bits 51:12 - Machine physical frame number */
         sa_p2mt     :   6,  /* bits 57:52 - Software available 2 */
-        access      :   4,  /* bits 61:58 - p2m_access_t */
-        _rsvd       :   1,  /* bit 62 - reserved */
+        pw          :   1,  /* bit 58 - Paging-write access */
+        access      :   4,  /* bits 62:59 - p2m_access_t */
         suppress_ve :   1;  /* bit 63 - suppress #VE */
     };
     u64 epte;
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 02 17:13:40 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 17:13:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864354.1275555 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTOlL-00065i-Vn; Thu, 02 Jan 2025 17:13:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864354.1275555; Thu, 02 Jan 2025 17:13:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTOlL-00065a-Rs; Thu, 02 Jan 2025 17:13:35 +0000
Received: by outflank-mailman (input) for mailman id 864354;
 Thu, 02 Jan 2025 17:13: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 <SRS0=NS6K=T2=gmail.com=w1benny@srs-se1.protection.inumbo.net>)
 id 1tTOlK-00065U-Ig
 for xen-devel@lists.xenproject.org; Thu, 02 Jan 2025 17:13:34 +0000
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com
 [2a00:1450:4864:20::334])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e53634cf-c92c-11ef-a0db-8be0dac302b0;
 Thu, 02 Jan 2025 18:13:33 +0100 (CET)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-43616c12d72so18815925e9.2
 for <xen-devel@lists.xenproject.org>; Thu, 02 Jan 2025 09:13:33 -0800 (PST)
Received: from lab.home
 (dynamic-2a00-1028-83a4-4bca-c0bb-96ff-feed-9d50.ipv6.o2.cz.
 [2a00:1028:83a4:4bca:c0bb:96ff:feed:9d50])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1fa2bdfbsm37802386f8f.102.2025.01.02.09.13.31
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 02 Jan 2025 09:13:32 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e53634cf-c92c-11ef-a0db-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1735838013; x=1736442813; 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=gEGTOObaKb2ABfYop/If2AgLey7bmu/+IKvPngcCyjY=;
        b=mc7JgaJU5A9ZYBw3HvHqWrgnYXC8iu7SgMR1dMDYYoJrDwoFjdR9wwH681Vu51hGE9
         Jk9Sx4n6okn/anZnTQUY8rA7nQSDqmAIKSKQHBPHxLnAYaUDDVq/9elDwj5XPBUJLXsQ
         7KSZaehtTYOSgdyv03XLB7TFNuK1xS9NSePdEzMlvaY2eIaQXz/g2A2KYe6nVEwF7fTN
         3fR6vrZDcpSnUHfJnymiAC5jpu+V6GPTGRbn4E1+LAOTRCb5weIDAhqq1QqnMa1VuiZu
         uh3ORyonjtFgNgMiiQhs6ee9rj/kEOiO7btkxCjRUtUuLzUnD3mUBhQtrqAXIRahTTv1
         i+gA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735838013; x=1736442813;
        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=gEGTOObaKb2ABfYop/If2AgLey7bmu/+IKvPngcCyjY=;
        b=ZCSYjrvhejctaAI8hjrEI4GNe479Hsc3ETEMvXQb4tiJqIL1ezJPgESPhFxjA3tfXZ
         sffGccxdYzp6kiivmVE9VX2ZRMWLLEhHXhX963vWnqbZIewcdwxzG90zti9l51Yx3g2h
         W/abN8LJpNaWpeZrH+jaGwmN9hE/94IU5+d0h5DHpC8Cs+cTh7iZamt5vE+AUkqcZVrP
         P70M2NqRwUgFdDWdcwz2R/LrOHEz7JEow0FLocFzlYQbBPZ/JD3IJainijA2EU3wDPY6
         m7iowP9KjR+4vVkTjzpUps6QHsiTCr+2HFFzWZNH1/DAGqsRzTSksT0MNIW4R3+Hyq9z
         xOhQ==
X-Gm-Message-State: AOJu0Yzr59xidsFcG6gKXV35WKSQrnt/EJYZUYWxBCai3DdokqE92mI/
	1GX4Lon2Rl+67zhzv+nMZnCrkC8w18IUObSK7XvRG7KmYrJ4IISCx9DOew==
X-Gm-Gg: ASbGncuiaNRtuAeCsitKjbBzirSdlaXezEGUUC8iqUvKb9BSz4gmbK0uFNi/ko0m809
	V4kiSrruVk+Fzx7IJZW9/gNl2j6EXjt3Jk0JdbsYOZeBwxUjvena/sDnoMCwNFQeH7W0ycHBwID
	aNuo86wW2tQRLPgJTIl9Qz9pIpQD35smaGDX1r3qtogc3D5IUIN7SXN2dvP4aX/DMU9ygqkIZW8
	47jgGGPLIsYsi5M88TImFV5UKxujfXY/emAvo+toWin07Kls8fc6ukffbcRwuf42FkX5IDWsnP5
	vW2RcmeqFt7M5lVKUG8C39Rg9F7/4twHeMYsX5lDhqETa1+tzqDsfAW7
X-Google-Smtp-Source: AGHT+IHiBo23c2/HncGH60cLyniCt1mAm03RZWryPtKM1mt4uAemgLdWrYQt6BoNPW+CEFkJGMo55Q==
X-Received: by 2002:a5d:6da2:0:b0:386:36e7:f447 with SMTP id ffacd0b85a97d-38a223f64b0mr14435702f8f.13.1735838012381;
        Thu, 02 Jan 2025 09:13:32 -0800 (PST)
From: "=?UTF-8?q?Petr=20Bene=C5=A1?=" <w1benny@gmail.com>
X-Google-Original-From: =?UTF-8?q?Petr=20Bene=C5=A1?= <petr.benes@gendigital.com>
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Petr=20Bene=C5=A1?= <w1benny@gmail.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Tamas K Lengyel <tamas@tklengyel.com>,
	Alexandru Isaila <aisaila@bitdefender.com>,
	Petre Pircalabu <ppircalabu@bitdefender.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Anthony PERARD <anthony.perard@vates.tech>
Subject: [PATCH v3 0/2] x86: Add Support for Paging-Write Feature
Date: Thu,  2 Jan 2025 17:13:26 +0000
Message-Id: <cover.1735837806.git.w1benny@gmail.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: Petr Beneš <w1benny@gmail.com>

Changes since v2:
- Reset entry->pw in all cases in p2m_set_entry, except for p2m_access_r_pw

Changes since v1:
- Added signed-off-by tags

This patch introduces a new XENMEM_access_r_pw permission. Functionally, it is similar to XENMEM_access_r, but for processors with TERTIARY_EXEC_EPT_PAGING_WRITE support (Intel 12th Gen/Alder Lake and later), it also permits the CPU to write to the page during guest page-table walks (e.g., updating A/D bits) without triggering an EPT violation.

This behavior works by both enabling the EPT paging-write feature and setting the EPT paging-write flag in the EPT leaf entry.

This feature provides a significant performance boost for introspection tools that monitor guest page-table updates. Previously, every page-table modification by the guest—including routine updates like setting A/D bits—triggered an EPT violation, adding unnecessary overhead. The new XENMEM_access_r_pw permission allows these "uninteresting" updates to occur without EPT violations, improving efficiency.

Additionally, this feature simplifies the handling of race conditions in scenarios where an introspection tool:

- Sets an "invisible breakpoint" in the altp2m view for a function F
- Monitors guest page-table updates to track whether the page containing F is paged out
- Encounters a cleared Access (A) bit on the page containing F while the guest is about to execute the breakpoint

In the current implementation:

- If xc_monitor_inguest_pagefault() is enabled, the introspection tool must emulate both the breakpoint and the setting of the Access bit.
- If xc_monitor_inguest_pagefault() is disabled, Xen handles the EPT violation without notifying the introspection tool, setting the Access bit and emulating the instruction. However, Xen fetches the instruction from the default view instead of the altp2m view, potentially causing the breakpoint to be missed.

With this patch, setting XENMEM_access_r_pw for monitored guest page-tables prevents EPT violations in these cases. This change enhances performance and reduces complexity for introspection tools, ensuring seamless breakpoint handling while tracking guest page-table updates.


Petr Beneš (2):
  x86: Rename _rsvd field to pw and move it to the bit 58
  x86: Add Support for Paging-Write Feature

 xen/arch/arm/mem_access.c               |  4 ++++
 xen/arch/arm/mmu/p2m.c                  |  1 +
 xen/arch/x86/hvm/hvm.c                  |  1 +
 xen/arch/x86/hvm/monitor.c              |  1 +
 xen/arch/x86/hvm/vmx/vmcs.c             |  4 +++-
 xen/arch/x86/include/asm/hvm/vmx/vmcs.h |  3 +++
 xen/arch/x86/include/asm/hvm/vmx/vmx.h  |  4 ++--
 xen/arch/x86/include/asm/p2m.h          |  1 +
 xen/arch/x86/mm/hap/nested_hap.c        |  3 +++
 xen/arch/x86/mm/mem_access.c            |  3 +++
 xen/arch/x86/mm/p2m-ept.c               | 12 ++++++++++++
 xen/include/public/memory.h             |  9 +++++++++
 xen/include/xen/mem_access.h            |  6 ++++++
 13 files changed, 49 insertions(+), 3 deletions(-)

-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 02 17:13:40 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 17:13:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864356.1275575 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTOlP-0006Z8-G5; Thu, 02 Jan 2025 17:13:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864356.1275575; Thu, 02 Jan 2025 17:13:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTOlP-0006Z1-CQ; Thu, 02 Jan 2025 17:13:39 +0000
Received: by outflank-mailman (input) for mailman id 864356;
 Thu, 02 Jan 2025 17:13:37 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=NS6K=T2=gmail.com=w1benny@srs-se1.protection.inumbo.net>)
 id 1tTOlN-00065f-96
 for xen-devel@lists.xenproject.org; Thu, 02 Jan 2025 17:13:37 +0000
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com
 [2a00:1450:4864:20::32e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e67f25ec-c92c-11ef-99a4-01e77a169b0f;
 Thu, 02 Jan 2025 18:13:35 +0100 (CET)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-43616c12d72so18815985e9.2
 for <xen-devel@lists.xenproject.org>; Thu, 02 Jan 2025 09:13:35 -0800 (PST)
Received: from lab.home
 (dynamic-2a00-1028-83a4-4bca-c0bb-96ff-feed-9d50.ipv6.o2.cz.
 [2a00:1028:83a4:4bca:c0bb:96ff:feed:9d50])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1fa2bdfbsm37802386f8f.102.2025.01.02.09.13.33
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 02 Jan 2025 09:13:34 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e67f25ec-c92c-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1735838015; x=1736442815; 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=qZmapqMoGLloUwPRwoQur8mb/AeXVr22gKUne+UpgLE=;
        b=kD0GD4wD5uc+ZI0uuOQXuYI+kft3IYCx+ZRFXaUfwYVg/9ZciS0+yEfW7dobgZYcvC
         P5o7h0YrBMLAJU43GXXwXyHGQ0V0Cq9Vu+fgsh5zW6jnddZVO1c+eJ1f16QQ8Odzkiur
         yB054zaz5evqb48AFkz94Y76KJNbgKVDK0EPlhtHC9fXStXBw9N1St5NTAfdq4gvZMht
         Xps0i+ZZYblGSW5OxYQKLRlQzvJLuN+RC/RZ+5D4SA9DaKhEnsVGX/jSyBBNcO0F6ZdZ
         CrADL056VSwZk/Pm6eySwIT/t9w1nKWxgc94waWSra5NFhhNeGybOSz1oRc8I5fYG7AG
         644w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735838015; x=1736442815;
        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=qZmapqMoGLloUwPRwoQur8mb/AeXVr22gKUne+UpgLE=;
        b=QGjoIIA3ck1bZ+FcEYd1aIOe1gRiiLpZpEtw0N1N+A+jy6i2PLecoIDSrIRV+VkDWe
         HzhjhONXz8hGDHIzu3GbLfMifrLZan4sA0tTNlwoQSzmzJj0x+nRmDUn7vDj5Wo5PgVS
         8XviM3ovzJTiIUTJlo+9NzTm4hkzk/tEb/DyqY5TlaFzDxMc8HspVNNNGh8xiFHRDMkU
         kLiDi3JFCUdir/SJYQw0goGnlRZ5SKdlovce7e+lFT/rEE+Ek1EPCD5yXaduzWMMIZgb
         n/c7CPrvDYfEoZih35vcjbPrzgxRjo2C1Q3Epq/8z7ka86w4Q0SQQCEqsr40PGaGNO+B
         gOZQ==
X-Gm-Message-State: AOJu0YyNW5OvZp+eqCTJI1P4ch7IOhybSsS2Bz5aM7xr7YX1FgAGWeUR
	siY6R2W4IIdE8/Ww4xKhKTS1rCsKfOkS/NnSzP7rdJ7O6nF9zAv1V4ildw==
X-Gm-Gg: ASbGncvvTAlheCaeXvJjKPMXbLK67scPrZmylzFt4KyTOcILTs5YqB6/MGzXs3uiQtg
	GMg4uB41ybK/Ful8Ld4TtGFZVsYnA5+8R0TuUzgw1AltoRT23/en0AK4aN4fSj80Oubeje9jfBz
	heaV9og8+iWXNIlMFxVx4q+VgQPfGCyIBFqk9izlUR2O8UC6n7Y6BIRUZ8iHApQaER7tm3dLHDp
	mcfNMgpoEUZ7FweTLZ+a9ftl5+h8ldnKFH9zgJPYAkB1Y16Nlti/3HMQTDIGh6d1Dx9ldwkyJfq
	/Q5aQ7YGFUV5BQSfiFH4rcDu5Y2oWtJqAgVe934yNh1mMFmuZAweXL7K
X-Google-Smtp-Source: AGHT+IEyxKl68tY70kJNfiYI4dF55u9PI6OOX0+Kb8GQNZuhXHV3Wvm2yf9RxblVe5S78pL4PXwy2g==
X-Received: by 2002:a5d:6487:0:b0:386:1cd3:8a06 with SMTP id ffacd0b85a97d-38a22206907mr16222366f8f.9.1735838014467;
        Thu, 02 Jan 2025 09:13:34 -0800 (PST)
From: "=?UTF-8?q?Petr=20Bene=C5=A1?=" <w1benny@gmail.com>
X-Google-Original-From: =?UTF-8?q?Petr=20Bene=C5=A1?= <petr.benes@gendigital.com>
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Petr=20Bene=C5=A1?= <w1benny@gmail.com>,
	Tamas K Lengyel <tamas@tklengyel.com>,
	Alexandru Isaila <aisaila@bitdefender.com>,
	Petre Pircalabu <ppircalabu@bitdefender.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PATCH v3 2/2] x86: Add Support for Paging-Write Feature
Date: Thu,  2 Jan 2025 17:13:28 +0000
Message-Id: <31a1ff2d5d1e17bb73231e008f1e47c501bb3ce8.1735837806.git.w1benny@gmail.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <cover.1735837806.git.w1benny@gmail.com>
References: <cover.1735837806.git.w1benny@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: Petr Beneš <w1benny@gmail.com>

This patch introduces a new XENMEM_access_r_pw permission. Functionally, it is similar to XENMEM_access_r, but for processors with TERTIARY_EXEC_EPT_PAGING_WRITE support (Intel 12th Gen/Alder Lake and later), it also permits the CPU to write to the page during guest page-table walks (e.g., updating A/D bits) without triggering an EPT violation.

This behavior works by both enabling the EPT paging-write feature and setting the EPT paging-write flag in the EPT leaf entry.

This feature provides a significant performance boost for introspection tools that monitor guest page-table updates. Previously, every page-table modification by the guest—including routine updates like setting A/D bits—triggered an EPT violation, adding unnecessary overhead. The new XENMEM_access_r_pw permission allows these "uninteresting" updates to occur without EPT violations, improving efficiency.

Additionally, this feature simplifies the handling of race conditions in scenarios where an introspection tool:

- Sets an "invisible breakpoint" in the altp2m view for a function F
- Monitors guest page-table updates to track whether the page containing F is paged out
- Encounters a cleared Access (A) bit on the page containing F while the guest is about to execute the breakpoint

In the current implementation:

- If xc_monitor_inguest_pagefault() is enabled, the introspection tool must emulate both the breakpoint and the setting of the Access bit.
- If xc_monitor_inguest_pagefault() is disabled, Xen handles the EPT violation without notifying the introspection tool, setting the Access bit and emulating the instruction. However, Xen fetches the instruction from the default view instead of the altp2m view, potentially causing the breakpoint to be missed.

With this patch, setting XENMEM_access_r_pw for monitored guest page-tables prevents EPT violations in these cases. This change enhances performance and reduces complexity for introspection tools, ensuring seamless breakpoint handling while tracking guest page-table updates.

Signed-off-by: Petr Beneš <w1benny@gmail.com>
Acked-by: Tamas K Lengyel <tamas@tklengyel.com>
---
 xen/arch/arm/mem_access.c               |  4 ++++
 xen/arch/arm/mmu/p2m.c                  |  1 +
 xen/arch/x86/hvm/hvm.c                  |  1 +
 xen/arch/x86/hvm/monitor.c              |  1 +
 xen/arch/x86/hvm/vmx/vmcs.c             |  4 +++-
 xen/arch/x86/include/asm/hvm/vmx/vmcs.h |  3 +++
 xen/arch/x86/include/asm/p2m.h          |  1 +
 xen/arch/x86/mm/hap/nested_hap.c        |  3 +++
 xen/arch/x86/mm/mem_access.c            |  3 +++
 xen/arch/x86/mm/p2m-ept.c               | 12 ++++++++++++
 xen/include/public/memory.h             |  9 +++++++++
 xen/include/xen/mem_access.h            |  6 ++++++
 12 files changed, 47 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/mem_access.c b/xen/arch/arm/mem_access.c
index 0ec3462364..2af92bb402 100644
--- a/xen/arch/arm/mem_access.c
+++ b/xen/arch/arm/mem_access.c
@@ -32,6 +32,7 @@ static int __p2m_get_mem_access(struct domain *d, gfn_t gfn,
             ACCESS(rwx),
             ACCESS(rx2rw),
             ACCESS(n2rwx),
+            ACCESS(r_pw),
 #undef ACCESS
     };
 
@@ -172,6 +173,7 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned long flag,
             break;
         else
             goto err;
+    case XENMEM_access_r_pw:
     case XENMEM_access_rx2rw:
     case XENMEM_access_rx:
     case XENMEM_access_r:
@@ -253,6 +255,7 @@ bool p2m_mem_access_check(paddr_t gpa, vaddr_t gla, const struct npfec npfec)
         violation = npfec.read_access || npfec.insn_fetch;
         break;
     case XENMEM_access_r:
+    case XENMEM_access_r_pw:
         violation = npfec.write_access || npfec.insn_fetch;
         break;
     default:
@@ -361,6 +364,7 @@ long p2m_set_mem_access(struct domain *d, gfn_t gfn, uint32_t nr,
         ACCESS(rwx),
         ACCESS(rx2rw),
         ACCESS(n2rwx),
+        ACCESS(r_pw),
 #undef ACCESS
     };
 
diff --git a/xen/arch/arm/mmu/p2m.c b/xen/arch/arm/mmu/p2m.c
index 28df6e5d03..7642dbc7c5 100644
--- a/xen/arch/arm/mmu/p2m.c
+++ b/xen/arch/arm/mmu/p2m.c
@@ -597,6 +597,7 @@ static void p2m_set_permission(lpae_t *e, p2m_type_t t, p2m_access_t a)
         e->p2m.read = 0;
         break;
     case p2m_access_r:
+    case p2m_access_r_pw:
         e->p2m.write = 0;
         e->p2m.xn = 1;
         break;
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 74e58c653e..495c8290ca 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1897,6 +1897,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long gla,
             violation = npfec.read_access || npfec.write_access || npfec.insn_fetch;
             break;
         case p2m_access_r:
+        case p2m_access_r_pw:
             violation = npfec.write_access || npfec.insn_fetch;
             break;
         case p2m_access_w:
diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
index 74621000b2..523586ca98 100644
--- a/xen/arch/x86/hvm/monitor.c
+++ b/xen/arch/x86/hvm/monitor.c
@@ -295,6 +295,7 @@ bool hvm_monitor_check_p2m(unsigned long gla, gfn_t gfn, uint32_t pfec,
 
     case XENMEM_access_r:
     case XENMEM_access_n:
+    case XENMEM_access_r_pw:
         if ( pfec & PFEC_write_access )
             req.u.mem_access.flags |= MEM_ACCESS_R | MEM_ACCESS_W;
         if ( pfec & PFEC_insn_fetch )
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 147e998371..8c0ea789c1 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -203,6 +203,7 @@ static void __init vmx_display_features(void)
     P(cpu_has_vmx_bus_lock_detection, "Bus Lock Detection");
     P(cpu_has_vmx_notify_vm_exiting, "Notify VM Exit");
     P(cpu_has_vmx_virt_spec_ctrl, "Virtualize SPEC_CTRL");
+    P(cpu_has_vmx_ept_paging_write, "EPT Paging-Write");
 #undef P
 
     if ( !printed )
@@ -366,7 +367,8 @@ static int vmx_init_vmcs_config(bool bsp)
 
     if ( _vmx_cpu_based_exec_control & CPU_BASED_ACTIVATE_TERTIARY_CONTROLS )
     {
-        uint64_t opt = TERTIARY_EXEC_VIRT_SPEC_CTRL;
+        uint64_t opt = (TERTIARY_EXEC_VIRT_SPEC_CTRL |
+                        TERTIARY_EXEC_EPT_PAGING_WRITE);
 
         _vmx_tertiary_exec_control = adjust_vmx_controls2(
             "Tertiary Exec Control", 0, opt,
diff --git a/xen/arch/x86/include/asm/hvm/vmx/vmcs.h b/xen/arch/x86/include/asm/hvm/vmx/vmcs.h
index 939b87eb50..e1d3398141 100644
--- a/xen/arch/x86/include/asm/hvm/vmx/vmcs.h
+++ b/xen/arch/x86/include/asm/hvm/vmx/vmcs.h
@@ -273,6 +273,9 @@ extern uint64_t vmx_tertiary_exec_control;
 #define cpu_has_vmx_virt_spec_ctrl \
      (vmx_tertiary_exec_control & TERTIARY_EXEC_VIRT_SPEC_CTRL)
 
+#define cpu_has_vmx_ept_paging_write \
+     (vmx_tertiary_exec_control & TERTIARY_EXEC_EPT_PAGING_WRITE)
+
 #define VMX_EPT_EXEC_ONLY_SUPPORTED                         0x00000001
 #define VMX_EPT_WALK_LENGTH_4_SUPPORTED                     0x00000040
 #define VMX_EPT_MEMORY_TYPE_UC                              0x00000100
diff --git a/xen/arch/x86/include/asm/p2m.h b/xen/arch/x86/include/asm/p2m.h
index e6de37f108..aa1bf7c9d0 100644
--- a/xen/arch/x86/include/asm/p2m.h
+++ b/xen/arch/x86/include/asm/p2m.h
@@ -980,6 +980,7 @@ static inline unsigned int p2m_access_to_iommu_flags(p2m_access_t p2ma)
     case p2m_access_r:
     case p2m_access_rx:
     case p2m_access_rx2rw:
+    case p2m_access_r_pw:
         return IOMMUF_readable;
 
     case p2m_access_w:
diff --git a/xen/arch/x86/mm/hap/nested_hap.c b/xen/arch/x86/mm/hap/nested_hap.c
index cc7bc6e5ea..255fba7e1c 100644
--- a/xen/arch/x86/mm/hap/nested_hap.c
+++ b/xen/arch/x86/mm/hap/nested_hap.c
@@ -213,6 +213,9 @@ int nestedhvm_hap_nested_page_fault(
     case p2m_access_n2rwx:
         p2ma_10 = p2m_access_n;
         break;
+    case p2m_access_r_pw:
+        p2ma_10 = p2m_access_r;
+        break;
     default:
         p2ma_10 = p2m_access_n;
         /* For safety, remove all permissions. */
diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
index 60a0cce68a..21b5b7ecda 100644
--- a/xen/arch/x86/mm/mem_access.c
+++ b/xen/arch/x86/mm/mem_access.c
@@ -45,6 +45,7 @@ static int _p2m_get_mem_access(struct p2m_domain *p2m, gfn_t gfn,
             ACCESS(rwx),
             ACCESS(rx2rw),
             ACCESS(n2rwx),
+            ACCESS(r_pw),
 #undef ACCESS
     };
 
@@ -94,6 +95,7 @@ bool p2m_mem_access_emulate_check(struct vcpu *v,
             break;
 
         case XENMEM_access_r:
+        case XENMEM_access_r_pw:
             violation = data->flags & MEM_ACCESS_WX;
             break;
 
@@ -312,6 +314,7 @@ bool xenmem_access_to_p2m_access(const struct p2m_domain *p2m,
         ACCESS(rwx),
         ACCESS(rx2rw),
         ACCESS(n2rwx),
+        ACCESS(r_pw),
 #undef ACCESS
     };
 
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 21728397f9..7ce8f3a1ca 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -154,27 +154,39 @@ static void ept_p2m_type_to_flags(const struct p2m_domain *p2m,
         case p2m_access_n:
         case p2m_access_n2rwx:
             entry->r = entry->w = entry->x = 0;
+            entry->pw = 0;
             break;
         case p2m_access_r:
             entry->w = entry->x = 0;
+            entry->pw = 0;
             break;
         case p2m_access_w:
             entry->r = entry->x = 0;
+            entry->pw = 0;
             break;
         case p2m_access_x:
             entry->r = entry->w = 0;
+            entry->pw = 0;
             break;
         case p2m_access_rx:
         case p2m_access_rx2rw:
             entry->w = 0;
+            entry->pw = 0;
             break;
         case p2m_access_wx:
             entry->r = 0;
+            entry->pw = 0;
             break;
         case p2m_access_rw:
             entry->x = 0;
+            entry->pw = 0;
             break;           
         case p2m_access_rwx:
+            entry->pw = 0;
+            break;
+        case p2m_access_r_pw:
+            entry->w = entry->x = 0;
+            entry->pw = !!cpu_has_vmx_ept_paging_write;
             break;
     }
     
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index 5e545ae9a4..bd9fc37b52 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -426,6 +426,15 @@ typedef enum {
      * pausing the vcpu
      */
     XENMEM_access_n2rwx,
+
+    /*
+     * Same as XENMEM_access_r, but on processors with
+     * the TERTIARY_EXEC_EPT_PAGING_WRITE support,
+     * CPU-initiated page-table walks can still
+     * write to it (e.g., update A/D bits)
+     */
+    XENMEM_access_r_pw,
+
     /* Take the domain default */
     XENMEM_access_default
 } xenmem_access_t;
diff --git a/xen/include/xen/mem_access.h b/xen/include/xen/mem_access.h
index 87d93b31f6..2231341b5d 100644
--- a/xen/include/xen/mem_access.h
+++ b/xen/include/xen/mem_access.h
@@ -64,6 +64,12 @@ typedef enum {
                            * generates an event but does not pause the
                            * vcpu */
 
+    p2m_access_r_pw = 10, /* Special: same as R, but on processors with
+                           * the TERTIARY_EXEC_EPT_PAGING_WRITE support,
+                           * CPU-initiated page-table walks can still
+                           * write to it (e.g., update A/D bits)
+                           */
+
     /* NOTE: Assumed to be only 4 bits right now on x86. */
 } p2m_access_t;
 
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 02 17:21:27 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 17:21:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864382.1275584 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTOsq-0000yv-76; Thu, 02 Jan 2025 17:21:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864382.1275584; Thu, 02 Jan 2025 17:21:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTOsq-0000yo-3h; Thu, 02 Jan 2025 17:21:20 +0000
Received: by outflank-mailman (input) for mailman id 864382;
 Thu, 02 Jan 2025 17:21:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=AqxF=T2=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tTOsp-0000yi-Aq
 for xen-devel@lists.xenproject.org; Thu, 02 Jan 2025 17:21:19 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f95b8350-c92d-11ef-99a4-01e77a169b0f;
 Thu, 02 Jan 2025 18:21:17 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id E6BBAA412AB;
 Thu,  2 Jan 2025 17:19:26 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 075D5C4CED0;
 Thu,  2 Jan 2025 17:21:14 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f95b8350-c92d-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1735838475;
	bh=z8HTro/qnAZhMN539b9dSCa2YFw7xXY0tQAFhhDnXv4=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=DnJiqVMsCGDNrJZrGp4/aWJhXEzNnJ37EgfeN0C0r1iOtgdSvrTEZPvnVGKUuYHeS
	 cecqQXpD33KL/Sfg/2BrEHxQuZl5NOTzpr1q9gUslkdPjmqH7cT1gXgHuvpXcba+M9
	 9LTIwjJOcYXjMjx6iehLkDPQ/vaTq4iIMv8QKdjDl9njUjXwtntTOHXFQNR/63UTnt
	 n1ZrcE+6g+ftD6aHCAMGRyG9PDNjwupXsdHHDxDircmE+6S2FJSBWGfJNUq+ffBLXd
	 FNGTinNY3K78vwpzL/WofPwD0i1vqzq6RpQMvqoUczQx/iG8lxmZQjbnAOhbRmFodk
	 fRg7PfN8s/LdA==
Date: Thu, 2 Jan 2025 09:21:13 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Ayan Kumar Halder <ayankuma@amd.com>
cc: Jason Andryuk <jason.andryuk@amd.com>, xen-devel@lists.xenproject.org, 
    Stefano Stabellini <stefano.stabellini@amd.com>, 
    Michal Orzel <michal.orzel@amd.com>
Subject: Re: [ImageBuilder] Add zstd compression support
In-Reply-To: <662dff5a-f494-4aaf-a2cd-5e95bf0e310b@amd.com>
Message-ID: <alpine.DEB.2.22.394.2501020916200.16425@ubuntu-linux-20-04-desktop>
References: <20241217211903.5945-1-jason.andryuk@amd.com> <662dff5a-f494-4aaf-a2cd-5e95bf0e310b@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 30 Dec 2024, Ayan Kumar Halder wrote:
> Hi Jason
> 
> On 17/12/2024 21:19, Jason Andryuk wrote:
> > uboot-script-gen fails to process a zstd-compressed initramdisk, exiting
> > with:
> > Wrong file type initrd.img. It should be cpio archive, exiting.
> > 
> > Extend the existing approach to also check zstd.
> > 
> > Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
> > ---
> >   scripts/uboot-script-gen | 11 ++++++++---
> >   1 file changed, 8 insertions(+), 3 deletions(-)
> > 
> > diff --git a/scripts/uboot-script-gen b/scripts/uboot-script-gen
> > index fc63702..db2c011 100755
> > --- a/scripts/uboot-script-gen
> > +++ b/scripts/uboot-script-gen
> > @@ -567,6 +567,7 @@ function check_compressed_file_type()
> >   {
> >       local filename=$1
> >       local type="$2"
> > +    local file_type
> >         if [ ! -f $filename ]
> >       then
> > @@ -574,13 +575,17 @@ function check_compressed_file_type()
> >           cleanup_and_return_err
> >       fi
> >   -    file -L $filename | grep "gzip compressed data" &> /dev/null
> > -    if test $? == 0
> > -    then
> > +    file_type=$( file -L $filename )
> > +    if echo "$file_type" | grep -q "gzip compressed data" ; then
> >           local tmp=`mktemp`
> >           tmp_files+=($tmp)
> >           cat $filename | gunzip > $tmp
> >           filename=$tmp
> > +    elif echo "$file_type" | grep -q "Zstandard compressed data" ; then
> > +        local tmp=`mktemp`
> > +        tmp_files+=($tmp)
> > +        zstdcat $filename > $tmp
> 
> I think you need to list zstd in |prog_req
> |
> 
> |See
> https://gitlab.com/xen-project/imagebuilder/-/blob/master/scripts/uboot-script-gen?ref_type=heads#L5|
> 
> |Also you need to include this as a part of the dockerfiles like|
> 
> |https://gitlab.com/xen-project/xen/-/blob/staging/automation/tests-artifacts/qemu-system-aarch64/6.0.0-arm64v8.dockerfile?ref_type=heads|
> 
> |https://gitlab.com/xen-project/xen/-/blob/staging/automation/tests-artifacts/alpine/3.18-arm64v8.dockerfile?ref_type=heads

Ayan makes a good point. Given that zstdcat is only used if images are
provided in zstd format, and given that we have been using ImageBuilder
without zstd for years now, I am tempted to consider zstd optional,
rather than required. We could leave it out of prog_req. If we add it to
prog_req, ImageBuilder will refuse to start if zstd is not installed,
and, like Ayan wrote, we would have to add zstd to the Dockerfiles.

So in conclusion I think it is best to go with this patch as is:

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


From xen-devel-bounces@lists.xenproject.org Thu Jan 02 18:34:14 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 18:34:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864390.1275595 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTQ1A-0002q2-2v; Thu, 02 Jan 2025 18:34:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864390.1275595; Thu, 02 Jan 2025 18:34:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTQ19-0002pv-Vo; Thu, 02 Jan 2025 18:33:59 +0000
Received: by outflank-mailman (input) for mailman id 864390;
 Thu, 02 Jan 2025 18:33: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
 <SRS0=AqxF=T2=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tTQ19-0002pl-7O
 for xen-devel@lists.xenproject.org; Thu, 02 Jan 2025 18:33:59 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1f066569-c938-11ef-99a4-01e77a169b0f;
 Thu, 02 Jan 2025 19:33:55 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id CEDB25C5DD0;
 Thu,  2 Jan 2025 18:33:12 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0C7A7C4CED0;
 Thu,  2 Jan 2025 18:33:51 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1f066569-c938-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1735842833;
	bh=aNNAO+e1hIDqXmbnqnM3cUCzuV82ejnk910HtDQjsLs=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=Q2uUrM0uyGH/nC1oJao/VZFjU4VJjHnoHkEF3bKiqGzCnw1A229eGMYlso+Yc4Spg
	 tn/oM1ZV86vpsE7LCz5fwVMAXjiG/GAi67GOjzjaQ/q3Y6V6hDZG1/uu5hx4+M1Tz2
	 mKhKRl84w3SUpBJIu7mO0QHIfzQhl4xFXZdkp7ms5pNDTwRJqbwbnxn++jvXwUO5Ye
	 g6QTM4EoXpj+b901MrVfkqFA5ARVY0xfclOQwpd3X82Fnbdd1d/qu79zlWWpc/zmmO
	 FWnh53KqP9ssMQjavedqFPc0Y+MnqD5HqOaPDuj7DijyL2WtLNrcHJzR1bu0IwV9av
	 VkQTge48BcTBA==
Date: Thu, 2 Jan 2025 10:33:50 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich <jbeulich@suse.com>
cc: Sergiy Kibrik <Sergiy_Kibrik@epam.com>, 
    Stefano Stabellini <stefano.stabellini@amd.com>, 
    Julien Grall <julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>, 
    Michal Orzel <michal.orzel@amd.com>, 
    Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>, 
    Anthony PERARD <anthony.perard@vates.tech>, 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
    Stefano Stabellini <sstabellini@kernel.org>, 
    Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [XEN PATCH v2] xen: introduce kconfig options to disable
 hypercalls
In-Reply-To: <735f8d30-5f42-4fa6-acb0-f82b5b759183@suse.com>
Message-ID: <alpine.DEB.2.22.394.2501021033440.16425@ubuntu-linux-20-04-desktop>
References: <20241219092917.3006174-1-Sergiy_Kibrik@epam.com> <735f8d30-5f42-4fa6-acb0-f82b5b759183@suse.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 27 Dec 2024, Jan Beulich wrote:
> On 19.12.2024 10:29, Sergiy Kibrik wrote:
> > --- a/xen/arch/x86/Makefile
> > +++ b/xen/arch/x86/Makefile
> > @@ -74,12 +74,12 @@ obj-y += hpet.o
> >  obj-y += vm_event.o
> >  obj-y += xstate.o
> >  
> > -ifneq ($(CONFIG_PV_SHIM_EXCLUSIVE),y)
> > -obj-y += domctl.o
> > +obj-$(CONFIG_DOMCTL) += domctl.o
> > +ifeq ($(CONFIG_PLATFORM_OP),y)
> >  obj-y += platform_hypercall.o
> >  obj-$(CONFIG_COMPAT) += x86_64/platform_hypercall.o
> > -obj-y += sysctl.o
> >  endif
> 
> Personally I'd prefer if we avoided ifeq here:
> 
> obj-$(CONFIG_PLATFORM_OP) += platform_hypercall.o
> obj-$(filter $(CONFIG_COMPAT),$(CONFIG_PLATFORM_OP)) += x86_64/platform_hypercall.o
> 
> Yet I realize this (once again) may be contentious.
> 
> > --- a/xen/common/Kconfig
> > +++ b/xen/common/Kconfig
> > @@ -516,4 +516,33 @@ config TRACEBUFFER
> >  	  to be collected at run time for debugging or performance analysis.
> >  	  Memory and execution overhead when not active is minimal.
> >  
> > +menu "Supported hypercall interfaces"
> > +	visible if DOM0LESS_BOOT && EXPERT
> > +
> > +config SYSCTL
> > +	bool "Enable sysctl hypercall"
> > +	depends on !PV_SHIM_EXCLUSIVE
> > +	default y
> > +
> > +config DOMCTL
> > +	bool "Enable domctl hypercalls"
> > +	depends on !PV_SHIM_EXCLUSIVE
> > +	default y
> > +
> > +config HVM_OP
> > +	bool "Enable HVM hypercalls"
> > +	depends on HVM
> > +	default y
> > +
> > +config PLATFORM_OP
> > +	bool "Enable platform hypercalls"
> > +	depends on !PV_SHIM_EXCLUSIVE
> > +	default y
> 
> Just to re-iterate an earlier comment: Andrew (imo validly) raised concern of
> such negative dependencies. As said before, imo we'd better resolve that before
> extending the issue (whether by the patch I once sent or something else is then
> secondary).

How would you express the !PV_SHIM_EXCLUSIVE dependency without using
negative dependencies?


> > --- a/xen/common/Makefile
> > +++ b/xen/common/Makefile
> > @@ -66,10 +66,10 @@ obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma lzo unlzo un
> >  obj-$(CONFIG_COMPAT) += $(addprefix compat/,domain.o memory.o multicall.o xlat.o)
> >  
> >  ifneq ($(CONFIG_PV_SHIM_EXCLUSIVE),y)
> > -obj-y += domctl.o
> >  obj-y += monitor.o
> > -obj-y += sysctl.o
> >  endif
> > +obj-$(CONFIG_DOMCTL) += domctl.o
> > +obj-$(CONFIG_SYSCTL) += sysctl.o
> 
> These two then want to move back up into their normal slots.
> 
> Jan
> 


From xen-devel-bounces@lists.xenproject.org Thu Jan 02 18:55:05 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 18:55:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864401.1275605 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTQLS-0005rf-Qb; Thu, 02 Jan 2025 18:54:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864401.1275605; Thu, 02 Jan 2025 18:54:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTQLS-0005rY-Mc; Thu, 02 Jan 2025 18:54:58 +0000
Received: by outflank-mailman (input) for mailman id 864401;
 Thu, 02 Jan 2025 18:54:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=4GO/=T2=invisiblethingslab.com=marmarek@srs-se1.protection.inumbo.net>)
 id 1tTQLR-0005rS-O5
 for xen-devel@lists.xenproject.org; Thu, 02 Jan 2025 18:54:57 +0000
Received: from fout-a7-smtp.messagingengine.com
 (fout-a7-smtp.messagingengine.com [103.168.172.150])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0da0035f-c93b-11ef-99a4-01e77a169b0f;
 Thu, 02 Jan 2025 19:54:54 +0100 (CET)
Received: from phl-compute-03.internal (phl-compute-03.phl.internal
 [10.202.2.43])
 by mailfout.phl.internal (Postfix) with ESMTP id 8691613801E6;
 Thu,  2 Jan 2025 13:54:53 -0500 (EST)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-03.internal (MEProxy); Thu, 02 Jan 2025 13:54:53 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 2 Jan 2025 13:54:52 -0500 (EST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 0da0035f-c93b-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm2; t=1735844093;
	 x=1735930493; bh=py7bMEXCkmOwoyNrLMBn3B5MiAvMSOofM6suwigFQBg=; b=
	2bvWa9uS+3AJCZLJQNfVXLvvrFsqllZ7JVLfBePWN9DXmnnB7e+zR5vFh28JD9L5
	tBov6ZIVUQZ08VRdfPrpWvUq5dXbeZ2tYpsekklN5jW8wJP4CfJ7sG00+U3VFETr
	KZq6Widgrir2tBSG0JzfiADCg8Q9gVlUldlJaFITBwQ8oVKA1tfUpzR1u65Omn74
	7zgGuKiLX549VxKXGyxjauYZeey8OICLaom1T+jHsW5l+Ycs5kR5svfmZVJhCszX
	E+r4nBGQ6zVnx9nbW2+5vtXa/3eKyUmkNk4ov/+Schjzqplz6DuCtTDYqgOT8EF2
	CtSBte/TKkZ30wTBzoc/6A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:subject:subject:to
	:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=
	1735844093; x=1735930493; bh=py7bMEXCkmOwoyNrLMBn3B5MiAvMSOofM6s
	uwigFQBg=; b=bcJrh/yC13PAMJeaW2pTGQS/iiYsRjKCb78EqucA/QDZE8Mfrn8
	i4gQK5tcsm38ovib3xtU2p4A7dL7uMltT5BVwKHxLmNA5xyDec6OlauWBk/KYUDz
	BiiWN0J9CilOPMg8FGSUrDvO4wc97F5Fq41+oGkrMb2fafZDOL8NVGPQ3IovUGUD
	ZhQTSWlnBmG7s04sbi24i9v85KzcYtQHpBqbgGsZdOs/g08xNm+1Rohr3PlPTEVn
	o8VlsPyvzzAYpX1twMWrzhJYdaefxvzYn99nNzALihe2EEgrRI9ZQzgKUmHoAqu7
	SBVqdA4Qt0SZheo56mKDZRvKEvtpWJzUvrw==
X-ME-Sender: <xms:_eB2Z97DLM8MgxjhcQWMBaJoHAK5bMeopH-iICtoelv6XgL9OgDR8g>
    <xme:_eB2Z671psqlXZi_Ow-dHNL93VtfFn0DLrugDbTOKc__FYm66c_B8QnTg2c06cjHK
    5nv9Wcz-EGJIQ>
X-ME-Received: <xmr:_eB2Z0dHmaGH-W7wyxyWr4DZGb9oYySBGup9AAKdRu5-nHzHIkuaamswn97jZDQOUrXq91yeLTksjUnXKxnsguOLGdbDH2tHUw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrudefvddguddulecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp
    uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg
    hnthhsucdlqddutddtmdenucfjughrpeffhffvvefukfhfgggtuggjsehgtderredttdej
    necuhfhrohhmpeforghrvghkucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoe
    hmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucgg
    tffrrghtthgvrhhnpeejjefgkedugeehiedvieffvdffgeetkedthfduleejieekhfetfe
    ekfefggfeigeenucffohhmrghinhepqhhusggvshdqohhsrdhorhhgpdhgihhthhhusgdr
    tghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe
    hmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggp
    rhgtphhtthhopedvpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehjghhrohhssh
    esshhushgvrdgtohhmpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigv
    nhhprhhojhgvtghtrdhorhhg
X-ME-Proxy: <xmx:_eB2Z2KPpBDpEeHpOS_2nWOaKu85X1x6dmSqhEoo2AuO8uCz7nhpIQ>
    <xmx:_eB2ZxLdflU3k2HSopZEg7G3x-zI7hYnh_DTCCnXp2JY1b7doRVnAg>
    <xmx:_eB2Z_zoIEsx0CHhrJM1TAG_Fz5YPu6HE9eRkdRBdxwit7seUfuG8A>
    <xmx:_eB2Z9IsQ1FPffIBTtYkFNOZkayzJvyPfKI6aIGsW8ifJqINwpirWA>
    <xmx:_eB2Z4W6Da_e-zETSAcRPv7KXchLROHbhsuKBbyovUNjfHibDLHYORLL>
Feedback-ID: i1568416f:Fastmail
Date: Thu, 2 Jan 2025 19:54:50 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Juergen Gross <jgross@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: Linux 6.13-rc3 many different panics in Xen PV dom0
Message-ID: <Z3bg-gvaBEdSIuRW@mail-itl>
References: <Z2RGfpJkO0z_nKV6@mail-itl>
 <ab9c27d5-f3f2-4b8a-960d-f880ec136199@suse.com>
 <6bb03333-74ca-4c2c-85a8-72549b85a5b4@suse.com>
 <Z3aFdrygLF9yK2EK@mail-itl>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="fRL8aTYga7dpRTxH"
Content-Disposition: inline
In-Reply-To: <Z3aFdrygLF9yK2EK@mail-itl>


--fRL8aTYga7dpRTxH
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Thu, 2 Jan 2025 19:54:50 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Juergen Gross <jgross@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: Linux 6.13-rc3 many different panics in Xen PV dom0

On Thu, Jan 02, 2025 at 01:24:21PM +0100, Marek Marczykowski-G=C3=B3recki w=
rote:
> On Thu, Jan 02, 2025 at 12:30:10PM +0100, Juergen Gross wrote:
> > On 02.01.25 11:20, J=C3=BCrgen Gro=C3=9F wrote:
> > > On 19.12.24 17:14, Marek Marczykowski-G=C3=B3recki wrote:
> > > > Hi,
> > > >=20
> > > > It crashes on boot like below, most of the times. But sometimes (ra=
rely)
> > > > it manages to stay alive. Below I'm pasting few of the crashes that=
 look
> > > > distinctly different, if you follow the links, you can find more of
> > > > them. IMHO it looks like some memory corruption bug somewhere. I te=
sted
> > > > also Linux 6.13-rc2 before, and it had very similar issue.
> > >=20
> > > ...
> > >=20
> > > >=20
> > > > Full log:
> > > > https://openqa.qubes-os.org/tests/122879/logfile?filename=3Dserial0=
=2Etxt
> > >=20
> > > I can reproduce a crash with 6.13-rc5 PV dom0.
> > >=20
> > > What is really interesting in the logs: most crashes seem to happen r=
ight
> > > after a module being loaded (in my reproducer it was right after load=
ing
> > > the first module).
> > >=20
> > > I need to go through the 6.13 commits, but I think I remember having =
seen
> > > a patch optimizing module loading by using large pages for addressing=
 the
> > > loaded modules. Maybe the case of no large pages being available isn't
> > > handled properly.
> >=20
> > Seems I was right.
> >=20
> > For me the following diff fixes the issue. Marek, can you please confirm
> > it fixes your crashes, too?
>=20
> Thanks for looking into it!
> Will do, I've pushed it to
> https://github.com/QubesOS/qubes-linux-kernel/pull/662, CI will build it
> and then I'll post it to openQA.

It is much better!

Tests are still running, but I already see that many are green. There is
one issue (likely unrelated to this change) - sys-usb (HVM domU with USB
controllers passed through) crashes on a system with Raptor Lake CPU
(only, others, including ADL and MTL look fine):

[   75.770849] Bluetooth: Core ver 2.22
[   75.770866] Oops: general protection fault, probably for non-canonical a=
ddress 0xc9d2315bc82c3bbd: 0000 [#1] PREEMPT SMP NOPTI
[   75.770880] CPU: 0 UID: 0 PID: 923 Comm: (udev-worker) Not tainted 6.13.=
0-0.rc5.2.qubes.1.fc41.x86_64 #1
[   75.770890] Hardware name: Xen HVM domU, BIOS 4.19.0 01/02/2025
[   75.770897] RIP: 0010:msft_monitor_device_del+0x93/0x170 [bluetooth]
[   75.770924] Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0 65 21 <26=
> 2b 8b ad 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   75.770943] RSP: 0000:ffffad644108fa40 EFLAGS: 00010246
[   75.770950] RAX: ffff93da8a149600 RBX: c9d2315bc82c3810 RCX: 00000001000=
00000
[   75.770958] RDX: 0000000000000001 RSI: ffff93da905e9180 RDI: ffff93da814=
04598
[   75.770967] RBP: ffffad644108fa58 R08: 0000000000000064 R09: 00000000000=
012ab
[   75.770975] R10: ffff93da81207000 R11: 0000000000000286 R12: ffffad64410=
8fb00
[   75.770983] R13: ffffad644108fa68 R14: ffff93da9089b840 R15: ffff93da8c2=
65100
[   75.770991] FS:  000078fa4cec4bc0(0000) GS:ffff93da97000000(0000) knlGS:=
0000000000000000
[   75.771000] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   75.771007] CR2: 000074fa64aadc08 CR3: 00000000105d2006 CR4: 00000000007=
70ef0
[   75.771016] PKRU: 55555554
[   75.771019] Call Trace:
[   75.771024]  <TASK>
[   75.771028]  ? show_trace_log_lvl+0x1b0/0x2f0
[   75.771036]  ? show_trace_log_lvl+0x1b0/0x2f0
[   75.771042]  ? do_one_initcall+0x58/0x310
[   75.771048]  ? __die_body.cold+0x8/0x12
[   75.771053]  ? die_addr+0x3c/0x60
[   75.771059]  ? exc_general_protection+0x17d/0x400
[   75.771066]  ? asm_exc_general_protection+0x26/0x30
[   75.771074]  ? msft_monitor_device_del+0x93/0x170 [bluetooth]
[   75.771095]  ? bt_init+0x54/0x1d0 [bluetooth]
[   75.771114]  ? __pfx_bt_init+0x10/0x10 [bluetooth]
[   75.771131]  ? do_one_initcall+0x58/0x310
[   75.771137]  ? do_init_module+0x90/0x250
[   75.771142]  ? init_module_from_file+0x86/0xc0
[   75.771149]  ? idempotent_init_module+0x115/0x310
[   75.771156]  ? __x64_sys_finit_module+0x65/0xc0
[   75.771163]  ? do_syscall_64+0x82/0x160
[   75.771168]  ? backing_file_read_iter+0x156/0x1f0
[   75.771176]  ? ovl_read_iter+0x94/0xa0 [overlay]
[   75.771189]  ? __pfx_ovl_file_accessed+0x10/0x10 [overlay]
[   75.771199]  ? rseq_get_rseq_cs+0x1d/0x220
[   75.771205]  ? rseq_ip_fixup+0x8d/0x1d0
[   75.771210]  ? __seccomp_filter+0x303/0x520
[   75.771216]  ? syscall_exit_to_user_mode_prepare+0x15e/0x1a0
[   75.771224]  ? syscall_exit_to_user_mode+0x10/0x210
[   75.771231]  ? do_syscall_64+0x8e/0x160
[   75.771236]  ? do_sys_openat2+0x9c/0xe0
[   75.771241]  ? syscall_exit_to_user_mode_prepare+0x15e/0x1a0
[   75.771249]  ? syscall_exit_to_user_mode+0x10/0x210
[   75.771255]  ? do_syscall_64+0x8e/0x160
[   75.771260]  ? do_user_addr_fault+0x1ec/0x7b0
[   75.771267]  ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
[   75.771274]  </TASK>
[   75.771277] Modules linked in: bluetooth(+) rfkill snd_seq_dummy snd_hrt=
imer snd_seq snd_seq_device snd_timer snd soundcore nft_reject_ipv6 nf_reje=
ct_ipv6 nft_reject_ipv4 nf_reject_ipv4 nft_reject intel_rapl_msr intel_rapl=
_common nft_ct intel_uncore_frequency_common intel_pmc_core intel_vsec joyd=
ev nft_masq pmt_telemetry pmt_class nft_chain_nat nf_nat nf_conntrack nf_de=
frag_ipv6 nf_defrag_ipv4 crct10dif_pclmul crc32_pclmul crc32c_intel polyval=
_clmulni xhci_pci polyval_generic ghash_clmulni_intel xhci_hcd sha512_ssse3=
 sha256_ssse3 nf_tables sha1_ssse3 ehci_pci mei_me ehci_hcd pcspkr mei ata_=
generic pata_acpi i2c_piix4 i2c_smbus serio_raw xen_scsiback target_core_mo=
d xen_netback xen_privcmd xen_gntdev xen_gntalloc xen_blkback xen_evtchn lo=
op fuse nfnetlink overlay xen_blkfront
[   75.771370] ---[ end trace 0000000000000000 ]---
[   75.771376] RIP: 0010:msft_monitor_device_del+0x93/0x170 [bluetooth]
[   75.771397] Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0 65 21 <26=
> 2b 8b ad 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   75.771416] RSP: 0000:ffffad644108fa40 EFLAGS: 00010246
[   75.771422] RAX: ffff93da8a149600 RBX: c9d2315bc82c3810 RCX: 00000001000=
00000
[   75.771431] RDX: 0000000000000001 RSI: ffff93da905e9180 RDI: ffff93da814=
04598
[   75.771439] RBP: ffffad644108fa58 R08: 0000000000000064 R09: 00000000000=
012ab
[   75.771446] R10: ffff93da81207000 R11: 0000000000000286 R12: ffffad64410=
8fb00
[   75.771454] R13: ffffad644108fa68 R14: ffff93da9089b840 R15: ffff93da8c2=
65100
[   75.771463] FS:  000078fa4cec4bc0(0000) GS:ffff93da97000000(0000) knlGS:=
0000000000000000
[   75.771471] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   75.771477] CR2: 000074fa64aadc08 CR3: 00000000105d2006 CR4: 00000000007=
70ef0
[   75.771485] PKRU: 55555554
[   75.771488] Kernel panic - not syncing: Fatal exception
[   75.771519] Kernel Offset: 0x3b800000 from 0xffffffff80200000 (relocatio=
n range: 0xffffffff80000000-0xffffffffbfffffff)

Full log inside
https://openqa.qubes-os.org/tests/124736/file/usbvm-var_log.tar.gz
(log/xen/console/guest-sys-usb.log)

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

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

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmd24PoACgkQ24/THMrX
1ywTjAf/aSTmAu0wt8aelLNPGqdFCFbUTw1bM8CNyuob4Ui1b4ntin9ClHjj+mXX
EPa+J2ub7hqw8l5QjPDEIgsW2TDNR0bGahlzr+FBqEngx1/Nopudj2tCvzPu1tkU
4w/wL4EOFTbTRSzOy0Gi1Jx54xRk4JM6/xAtDmjPDHGs1SRozQJfwIAfO8KO5lCi
KT1eRfYvUNiPoiKhR7ARKWglfSr/o4518VimKumbpIvGDZl9eSb059gMKoTTqfZd
0+jZXsgMUsbcj4lqejQpL/c4k8vEy1cUXh8dFkQwk07CN7kpE7magJj9iwrUsixZ
Jh0w2Pc7EBaN/LFEme5BarkhqQBuxw==
=3yxV
-----END PGP SIGNATURE-----

--fRL8aTYga7dpRTxH--


From xen-devel-bounces@lists.xenproject.org Thu Jan 02 19:04:31 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 19:04:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864409.1275615 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTQUa-0007bT-Kg; Thu, 02 Jan 2025 19:04:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864409.1275615; Thu, 02 Jan 2025 19:04:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTQUa-0007bM-HS; Thu, 02 Jan 2025 19:04:24 +0000
Received: by outflank-mailman (input) for mailman id 864409;
 Thu, 02 Jan 2025 19:04:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=xoa/=T2=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tTQUZ-0007bG-JG
 for xen-devel@lists.xenproject.org; Thu, 02 Jan 2025 19:04:23 +0000
Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com
 [2a00:1450:4864:20::443])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5fcc4ff4-c93c-11ef-99a4-01e77a169b0f;
 Thu, 02 Jan 2025 20:04:21 +0100 (CET)
Received: by mail-wr1-x443.google.com with SMTP id
 ffacd0b85a97d-385e2880606so8566968f8f.3
 for <xen-devel@lists.xenproject.org>; Thu, 02 Jan 2025 11:04:21 -0800 (PST)
Received: from [192.168.86.29] ([83.105.36.37])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c828e7asm38426846f8f.21.2025.01.02.11.04.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 02 Jan 2025 11:04:20 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5fcc4ff4-c93c-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1735844661; x=1736449461; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=rb7FfLHcicmvieSspHR+ItqMa2mcY65KCqVAS5Vopqg=;
        b=st1ijp+zhAW31MJOkJXKoEaKNUiKiDCyJcg6J0ykC8qm93EMvgDtykFtAev1tJgp39
         152SVyv5qjIJ2fNX1EDYJK7SRO9xh9JflddD0x5KXfpV4nkzuntZTcOjaah5m5e+8JTm
         46vHDeWXrVf+MgruRNdGEx8gmR224CRpRjD90=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735844661; x=1736449461;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=rb7FfLHcicmvieSspHR+ItqMa2mcY65KCqVAS5Vopqg=;
        b=QMkW/SDbfNiDKqDz5e38V5RQF2YWx5pm6P4y9mWK5dgkuggqGDpri9KnW6HZbBWGnT
         QObbeHq4O8inNuthgBox4cDd1/eGY0mu85Yn6DP8f91tlmq3LTPEN/+mhFPPI8TqTptb
         Z531Jn0yIF0kolmtHdcrSrhLZCb6Fov2wp3hrRI7L8odRxVI3+2JDCysFDMfZqQULShH
         f+ABZqjh1dgxyghy85QRA771nbwDu5J6SmlzAQyHGLgUI0tGKoH4zdvdwcJB59uJ2qfV
         SQE1AamMoRVnL00YH7kCVw1Qk7JfhCJx69IYWpNaWcifWYv1nTSEtRxcc02XjZxQ13ts
         4fgA==
X-Gm-Message-State: AOJu0YwB3wnALUCbpG6g9eh+86GLxbb6D6vwr8ijxtlT7OtAzQUUQ4dx
	WjvTkB9151BJxNt3i9RIU05N1Rq7oCMRYyAngrwcDOMtLIqhRBmOeG+2O0EUjPo=
X-Gm-Gg: ASbGncsXTsy8ZHvGpYwNDBZ4HLnqLxQ8Lzdj594I+MIJcPg5jECERMKNaLxNam/lIgu
	R5Fu0IJXHDufYnkSxXkr/yHFhk2Xo/eFPFThNu6kr3EQsN/4XASXirAjK2M37dU+u+I2rItF2nz
	aQMEaowiiD4eguq94BAmqBSGHnqAa72fRN/DZI/2F7lB/pz6X+oiAt0P8RxEv3foWzcckJ8ILQ3
	jm2fmijjgo3AobHgZaNSNmH/djWBLB4fdQWqar8MCUtjS2x8jPyN8jVIRHcoD/GxYI=
X-Google-Smtp-Source: AGHT+IH019NJVRQMl8Gfpoo7RZvFdOINb0JTiHAUWV4JYtNxuTFwlzsz3joV82Pu42P06ZPwslMC+w==
X-Received: by 2002:a5d:6d84:0:b0:385:f66a:4271 with SMTP id ffacd0b85a97d-38a221e24f4mr39188851f8f.4.1735844660806;
        Thu, 02 Jan 2025 11:04:20 -0800 (PST)
Message-ID: <0be813be-b964-4ee7-b1c4-0d7da06d690a@citrix.com>
Date: Thu, 2 Jan 2025 19:04:19 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Linux 6.13-rc3 many different panics in Xen PV dom0
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, Juergen Gross <jgross@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>
References: <Z2RGfpJkO0z_nKV6@mail-itl>
 <ab9c27d5-f3f2-4b8a-960d-f880ec136199@suse.com>
 <6bb03333-74ca-4c2c-85a8-72549b85a5b4@suse.com> <Z3aFdrygLF9yK2EK@mail-itl>
 <Z3bg-gvaBEdSIuRW@mail-itl>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <Z3bg-gvaBEdSIuRW@mail-itl>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 02/01/2025 6:54 pm, Marek Marczykowski-Górecki wrote:
> On Thu, Jan 02, 2025 at 01:24:21PM +0100, Marek Marczykowski-Górecki wrote:
>> On Thu, Jan 02, 2025 at 12:30:10PM +0100, Juergen Gross wrote:
>>> On 02.01.25 11:20, Jürgen Groß wrote:
>>>> On 19.12.24 17:14, Marek Marczykowski-Górecki wrote:
>>>>> Hi,
>>>>>
>>>>> It crashes on boot like below, most of the times. But sometimes (rarely)
>>>>> it manages to stay alive. Below I'm pasting few of the crashes that look
>>>>> distinctly different, if you follow the links, you can find more of
>>>>> them. IMHO it looks like some memory corruption bug somewhere. I tested
>>>>> also Linux 6.13-rc2 before, and it had very similar issue.
>>>> ...
>>>>
>>>>> Full log:
>>>>> https://openqa.qubes-os.org/tests/122879/logfile?filename=serial0.txt
>>>> I can reproduce a crash with 6.13-rc5 PV dom0.
>>>>
>>>> What is really interesting in the logs: most crashes seem to happen right
>>>> after a module being loaded (in my reproducer it was right after loading
>>>> the first module).
>>>>
>>>> I need to go through the 6.13 commits, but I think I remember having seen
>>>> a patch optimizing module loading by using large pages for addressing the
>>>> loaded modules. Maybe the case of no large pages being available isn't
>>>> handled properly.
>>> Seems I was right.
>>>
>>> For me the following diff fixes the issue. Marek, can you please confirm
>>> it fixes your crashes, too?
>> Thanks for looking into it!
>> Will do, I've pushed it to
>> https://github.com/QubesOS/qubes-linux-kernel/pull/662, CI will build it
>> and then I'll post it to openQA.
> It is much better!
>
> Tests are still running, but I already see that many are green. There is
> one issue (likely unrelated to this change) - sys-usb (HVM domU with USB
> controllers passed through) crashes on a system with Raptor Lake CPU
> (only, others, including ADL and MTL look fine):
>
> [   75.770849] Bluetooth: Core ver 2.22
> [   75.770866] Oops: general protection fault, probably for non-canonical address 0xc9d2315bc82c3bbd: 0000 [#1] PREEMPT SMP NOPTI
> [   75.770880] CPU: 0 UID: 0 PID: 923 Comm: (udev-worker) Not tainted 6.13.0-0.rc5.2.qubes.1.fc41.x86_64 #1
> [   75.770890] Hardware name: Xen HVM domU, BIOS 4.19.0 01/02/2025
> [   75.770897] RIP: 0010:msft_monitor_device_del+0x93/0x170 [bluetooth]
> [   75.770924] Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0 65 21 <26> 2b 8b ad 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

es sub 0x3ad(%rbx),%ecx

I highly doubt that's an instruction that the compiler really put out
for this function.

The preceding bytes are "shlb 0x21(%rbp)" which isn't completely
implausible, but the surrounding 0's very much are.

This looks very fishy, and either looks like DMA hitting .text, or
module handling getting it's regions wrong.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Jan 02 19:17:13 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 19:17:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864418.1275629 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTQgs-00010J-O3; Thu, 02 Jan 2025 19:17:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864418.1275629; Thu, 02 Jan 2025 19:17:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTQgs-00010C-Kw; Thu, 02 Jan 2025 19:17:06 +0000
Received: by outflank-mailman (input) for mailman id 864418;
 Thu, 02 Jan 2025 19:17:05 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=RDYY=T2=suse.com=jgross@srs-se1.protection.inumbo.net>)
 id 1tTQgq-000106-Tn
 for xen-devel@lists.xenproject.org; Thu, 02 Jan 2025 19:17:05 +0000
Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com
 [2a00:1450:4864:20::444])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 255bd48b-c93e-11ef-99a4-01e77a169b0f;
 Thu, 02 Jan 2025 20:17:02 +0100 (CET)
Received: by mail-wr1-x444.google.com with SMTP id
 ffacd0b85a97d-385ddcfc97bso9932725f8f.1
 for <xen-devel@lists.xenproject.org>; Thu, 02 Jan 2025 11:17:02 -0800 (PST)
Received: from ?IPV6:2003:e5:8731:2800:842d:42a0:5992:3595?
 (p200300e587312800842d42a059923595.dip0.t-ipconnect.de.
 [2003:e5:8731:2800:842d:42a0:5992:3595])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4366120088esm459018085e9.13.2025.01.02.11.17.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 02 Jan 2025 11:17:01 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 255bd48b-c93e-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1735845422; x=1736450222; darn=lists.xenproject.org;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=xi33YWZb7gTFzqJZwD4Ljdni+Ik4s3NO3PKoz6UqPjc=;
        b=Ckoyl3HCRM8kvsKAShqKRik2mA6C05tHdeDe9LsZQKYRd7KL8B24OCeOeey0z3rwO0
         pFQ57tUsgDUwKZewTeLL5kbtYLqTXs00xWuUFkYo4ayacHQyimqTk0IXPwelTHDIBEN/
         AoH4rMR9SaJ3VeIMCKdQCD4uwum8dH7JkfgG3wXI2Q74fmY4XrlIVclDzJkU7XXB0nmi
         vtN0tVCTAIUzoF+UhdA2j6bPeVhrj+6C7yGHaKIJhLGBLFn8NBRYDPmYEYsAT7MSJBXp
         WB/4FRb/XbPzdxH4HzzgHe+ahKC4zPd+M//WoYTGcztWo+EdatQpRBsUOWURnPM/ZNlc
         PwzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735845422; x=1736450222;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=xi33YWZb7gTFzqJZwD4Ljdni+Ik4s3NO3PKoz6UqPjc=;
        b=l2DzEpRMzx2rGsjEvN84FmATW7tOgPeB2/m7ENqUu69B2Y9CZ+ZpoUCqJop4p3iKVq
         49axyaZPt0PtQAvHeYQTpc+8VFsYuyAM3XmqN4gQ52Pt6T0IzhgfMT+xHV1ltV/1UO1k
         ZquawrVf3cVdFmzdx5Dk+gviGqog8Pa7udTDrlpC8NK5Kwlx/AfTDcdWJOYbr75/0/HJ
         e6DNfo6xi3yc0KqpW+NUNFneQXSDFsC0L9IDVpLPLSrhhVXhf8+Sa1FBRXEb24Go+A9k
         PfBaghO1mPF/CgtK1JO++7kwfntFd6s2hbG3wOJ/Cwij4E9V9qEjsDEIp3fJT7tkgqpQ
         W+rg==
X-Gm-Message-State: AOJu0YxNtYqVnRD1nBwldUrauhTgJ5iGbd8He/YFe4U7hsEkBB79v4k+
	4C9VNd+XD4NF6uC7YG89i+c6AvZNHK6KsUZNvQVuphqDHqZI8rSmS+B/seNzlyy1zVy+rQlt0z1
	lij6Ekg==
X-Gm-Gg: ASbGncvsETxKOW/P4c6g+4YqZrY10dLjmQxMUum41XIDLID09l8hUS3tdwp81Iq08P4
	zNAdHpfAW9ZAb9b85EwXQl/gvjOJ8VC1+TF8NuHF0Uu4mr1TmiAWx1Br+UtMnwT3HHWq70ZcCva
	i28PUA1FBQQYd31J6e5xn0LaMrh+vy80VdX3R4DuesIcX+Uskh52rDbOYg7WIgNxMby0WYSFdxC
	5/bfVnPAJbt0Ft+xSnabRPYK5tBvkZVmr2DODh+jwf90lJxSOqVdqhVG1fiWqr2tG3GJrtwCsMl
	EDzIg7tXWvDkAsYWzDMCqfVMA42cjJTqlE1ydGrow+AZLxer7LApAUT9CMK60o8W7LsToPpDl/7
	ZVW1J8g==
X-Google-Smtp-Source: AGHT+IFCLbVDowy9NajEpuZjU4iUbIsaT49WqTiCeFW7G5mo/pHpX1rRdyH8yHd0n+WICPw+AXWReA==
X-Received: by 2002:a05:6000:4012:b0:385:f7d9:99f5 with SMTP id ffacd0b85a97d-38a224087b8mr37735102f8f.51.1735845421680;
        Thu, 02 Jan 2025 11:17:01 -0800 (PST)
Message-ID: <08f9604b-df23-4766-a290-ef9daa506f8d@suse.com>
Date: Thu, 2 Jan 2025 20:17:00 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Linux 6.13-rc3 many different panics in Xen PV dom0
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>
References: <Z2RGfpJkO0z_nKV6@mail-itl>
 <ab9c27d5-f3f2-4b8a-960d-f880ec136199@suse.com>
 <6bb03333-74ca-4c2c-85a8-72549b85a5b4@suse.com> <Z3aFdrygLF9yK2EK@mail-itl>
 <Z3bg-gvaBEdSIuRW@mail-itl>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <Z3bg-gvaBEdSIuRW@mail-itl>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------W512nT36UmdTJlmwF9PEG7Wf"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------W512nT36UmdTJlmwF9PEG7Wf
Content-Type: multipart/mixed; boundary="------------OnuG2lIn3uDHSCcnHKEJfbF3";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>
Message-ID: <08f9604b-df23-4766-a290-ef9daa506f8d@suse.com>
Subject: Re: Linux 6.13-rc3 many different panics in Xen PV dom0
References: <Z2RGfpJkO0z_nKV6@mail-itl>
 <ab9c27d5-f3f2-4b8a-960d-f880ec136199@suse.com>
 <6bb03333-74ca-4c2c-85a8-72549b85a5b4@suse.com> <Z3aFdrygLF9yK2EK@mail-itl>
 <Z3bg-gvaBEdSIuRW@mail-itl>
In-Reply-To: <Z3bg-gvaBEdSIuRW@mail-itl>

--------------OnuG2lIn3uDHSCcnHKEJfbF3
Content-Type: multipart/mixed; boundary="------------C1tWsHDrPBoySZFp4ltYncuc"

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

T24gMDIuMDEuMjUgMTk6NTQsIE1hcmVrIE1hcmN6eWtvd3NraS1Hw7NyZWNraSB3cm90ZToN
Cj4gT24gVGh1LCBKYW4gMDIsIDIwMjUgYXQgMDE6MjQ6MjFQTSArMDEwMCwgTWFyZWsgTWFy
Y3p5a293c2tpLUfDs3JlY2tpIHdyb3RlOg0KPj4gT24gVGh1LCBKYW4gMDIsIDIwMjUgYXQg
MTI6MzA6MTBQTSArMDEwMCwgSnVlcmdlbiBHcm9zcyB3cm90ZToNCj4+PiBPbiAwMi4wMS4y
NSAxMToyMCwgSsO8cmdlbiBHcm/DnyB3cm90ZToNCj4+Pj4gT24gMTkuMTIuMjQgMTc6MTQs
IE1hcmVrIE1hcmN6eWtvd3NraS1Hw7NyZWNraSB3cm90ZToNCj4+Pj4+IEhpLA0KPj4+Pj4N
Cj4+Pj4+IEl0IGNyYXNoZXMgb24gYm9vdCBsaWtlIGJlbG93LCBtb3N0IG9mIHRoZSB0aW1l
cy4gQnV0IHNvbWV0aW1lcyAocmFyZWx5KQ0KPj4+Pj4gaXQgbWFuYWdlcyB0byBzdGF5IGFs
aXZlLiBCZWxvdyBJJ20gcGFzdGluZyBmZXcgb2YgdGhlIGNyYXNoZXMgdGhhdCBsb29rDQo+
Pj4+PiBkaXN0aW5jdGx5IGRpZmZlcmVudCwgaWYgeW91IGZvbGxvdyB0aGUgbGlua3MsIHlv
dSBjYW4gZmluZCBtb3JlIG9mDQo+Pj4+PiB0aGVtLiBJTUhPIGl0IGxvb2tzIGxpa2Ugc29t
ZSBtZW1vcnkgY29ycnVwdGlvbiBidWcgc29tZXdoZXJlLiBJIHRlc3RlZA0KPj4+Pj4gYWxz
byBMaW51eCA2LjEzLXJjMiBiZWZvcmUsIGFuZCBpdCBoYWQgdmVyeSBzaW1pbGFyIGlzc3Vl
Lg0KPj4+Pg0KPj4+PiAuLi4NCj4+Pj4NCj4+Pj4+DQo+Pj4+PiBGdWxsIGxvZzoNCj4+Pj4+
IGh0dHBzOi8vb3BlbnFhLnF1YmVzLW9zLm9yZy90ZXN0cy8xMjI4NzkvbG9nZmlsZT9maWxl
bmFtZT1zZXJpYWwwLnR4dA0KPj4+Pg0KPj4+PiBJIGNhbiByZXByb2R1Y2UgYSBjcmFzaCB3
aXRoIDYuMTMtcmM1IFBWIGRvbTAuDQo+Pj4+DQo+Pj4+IFdoYXQgaXMgcmVhbGx5IGludGVy
ZXN0aW5nIGluIHRoZSBsb2dzOiBtb3N0IGNyYXNoZXMgc2VlbSB0byBoYXBwZW4gcmlnaHQN
Cj4+Pj4gYWZ0ZXIgYSBtb2R1bGUgYmVpbmcgbG9hZGVkIChpbiBteSByZXByb2R1Y2VyIGl0
IHdhcyByaWdodCBhZnRlciBsb2FkaW5nDQo+Pj4+IHRoZSBmaXJzdCBtb2R1bGUpLg0KPj4+
Pg0KPj4+PiBJIG5lZWQgdG8gZ28gdGhyb3VnaCB0aGUgNi4xMyBjb21taXRzLCBidXQgSSB0
aGluayBJIHJlbWVtYmVyIGhhdmluZyBzZWVuDQo+Pj4+IGEgcGF0Y2ggb3B0aW1pemluZyBt
b2R1bGUgbG9hZGluZyBieSB1c2luZyBsYXJnZSBwYWdlcyBmb3IgYWRkcmVzc2luZyB0aGUN
Cj4+Pj4gbG9hZGVkIG1vZHVsZXMuIE1heWJlIHRoZSBjYXNlIG9mIG5vIGxhcmdlIHBhZ2Vz
IGJlaW5nIGF2YWlsYWJsZSBpc24ndA0KPj4+PiBoYW5kbGVkIHByb3Blcmx5Lg0KPj4+DQo+
Pj4gU2VlbXMgSSB3YXMgcmlnaHQuDQo+Pj4NCj4+PiBGb3IgbWUgdGhlIGZvbGxvd2luZyBk
aWZmIGZpeGVzIHRoZSBpc3N1ZS4gTWFyZWssIGNhbiB5b3UgcGxlYXNlIGNvbmZpcm0NCj4+
PiBpdCBmaXhlcyB5b3VyIGNyYXNoZXMsIHRvbz8NCj4+DQo+PiBUaGFua3MgZm9yIGxvb2tp
bmcgaW50byBpdCENCj4+IFdpbGwgZG8sIEkndmUgcHVzaGVkIGl0IHRvDQo+PiBodHRwczov
L2dpdGh1Yi5jb20vUXViZXNPUy9xdWJlcy1saW51eC1rZXJuZWwvcHVsbC82NjIsIENJIHdp
bGwgYnVpbGQgaXQNCj4+IGFuZCB0aGVuIEknbGwgcG9zdCBpdCB0byBvcGVuUUEuDQo+IA0K
PiBJdCBpcyBtdWNoIGJldHRlciENCj4gDQo+IFRlc3RzIGFyZSBzdGlsbCBydW5uaW5nLCBi
dXQgSSBhbHJlYWR5IHNlZSB0aGF0IG1hbnkgYXJlIGdyZWVuLg0KDQpTbyBhcmUgeW91IGZp
bmUgd2l0aCBtZSBhZGRpbmcgeW91ciAiVGVzdGVkLWJ5OiI/DQoNCj4gVGhlcmUgaXMNCj4g
b25lIGlzc3VlIChsaWtlbHkgdW5yZWxhdGVkIHRvIHRoaXMgY2hhbmdlKSAtIHN5cy11c2Ig
KEhWTSBkb21VIHdpdGggVVNCDQo+IGNvbnRyb2xsZXJzIHBhc3NlZCB0aHJvdWdoKSBjcmFz
aGVzIG9uIGEgc3lzdGVtIHdpdGggUmFwdG9yIExha2UgQ1BVDQo+IChvbmx5LCBvdGhlcnMs
IGluY2x1ZGluZyBBREwgYW5kIE1UTCBsb29rIGZpbmUpOg0KPiANCj4gWyAgIDc1Ljc3MDg0
OV0gQmx1ZXRvb3RoOiBDb3JlIHZlciAyLjIyDQo+IFsgICA3NS43NzA4NjZdIE9vcHM6IGdl
bmVyYWwgcHJvdGVjdGlvbiBmYXVsdCwgcHJvYmFibHkgZm9yIG5vbi1jYW5vbmljYWwgYWRk
cmVzcyAweGM5ZDIzMTViYzgyYzNiYmQ6IDAwMDAgWyMxXSBQUkVFTVBUIFNNUCBOT1BUSQ0K
PiBbICAgNzUuNzcwODgwXSBDUFU6IDAgVUlEOiAwIFBJRDogOTIzIENvbW06ICh1ZGV2LXdv
cmtlcikgTm90IHRhaW50ZWQgNi4xMy4wLTAucmM1LjIucXViZXMuMS5mYzQxLng4Nl82NCAj
MQ0KPiBbICAgNzUuNzcwODkwXSBIYXJkd2FyZSBuYW1lOiBYZW4gSFZNIGRvbVUsIEJJT1Mg
NC4xOS4wIDAxLzAyLzIwMjUNCj4gWyAgIDc1Ljc3MDg5N10gUklQOiAwMDEwOm1zZnRfbW9u
aXRvcl9kZXZpY2VfZGVsKzB4OTMvMHgxNzAgW2JsdWV0b290aF0NCj4gWyAgIDc1Ljc3MDky
NF0gQ29kZTogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg
MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg
MDAgMDAgMDAgMDAgMDAgMDAgZDAgNjUgMjEgPDI2PiAyYiA4YiBhZCAwMyAwMCAwMCAwMCAw
MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMA0KDQpUaGlzIGNvZGUg
aXMgbG9va2luZyBzdXNwaWNpb3VzLiBMYXJnZSBhcmVhcyBvZiBiaW5hcnkgMCBpbiBhIG5v
cm1hbCBmdW5jdGlvbj8NCkFuZCB0aGUgY29kZSBpdHNlbGYgaXMgbm9uc2Vuc2UsIGFzIGl0
IGlzIHVzaW5nIGEgbWVtb3J5IGFjY2VzcyB2aWEgRVM6LCB3aGljaA0KZG9lc24ndCBtYWtl
IGFueSBzZW5zZSBpbiA2NC1iaXQga2VybmVsLg0KDQoNCkp1ZXJnZW4NCg0KDQo+IFsgICA3
NS43NzA5NDNdIFJTUDogMDAwMDpmZmZmYWQ2NDQxMDhmYTQwIEVGTEFHUzogMDAwMTAyNDYN
Cj4gWyAgIDc1Ljc3MDk1MF0gUkFYOiBmZmZmOTNkYThhMTQ5NjAwIFJCWDogYzlkMjMxNWJj
ODJjMzgxMCBSQ1g6IDAwMDAwMDAxMDAwMDAwMDANCj4gWyAgIDc1Ljc3MDk1OF0gUkRYOiAw
MDAwMDAwMDAwMDAwMDAxIFJTSTogZmZmZjkzZGE5MDVlOTE4MCBSREk6IGZmZmY5M2RhODE0
MDQ1OTgNCj4gWyAgIDc1Ljc3MDk2N10gUkJQOiBmZmZmYWQ2NDQxMDhmYTU4IFIwODogMDAw
MDAwMDAwMDAwMDA2NCBSMDk6IDAwMDAwMDAwMDAwMDEyYWINCj4gWyAgIDc1Ljc3MDk3NV0g
UjEwOiBmZmZmOTNkYTgxMjA3MDAwIFIxMTogMDAwMDAwMDAwMDAwMDI4NiBSMTI6IGZmZmZh
ZDY0NDEwOGZiMDANCj4gWyAgIDc1Ljc3MDk4M10gUjEzOiBmZmZmYWQ2NDQxMDhmYTY4IFIx
NDogZmZmZjkzZGE5MDg5Yjg0MCBSMTU6IGZmZmY5M2RhOGMyNjUxMDANCj4gWyAgIDc1Ljc3
MDk5MV0gRlM6ICAwMDAwNzhmYTRjZWM0YmMwKDAwMDApIEdTOmZmZmY5M2RhOTcwMDAwMDAo
MDAwMCkga25sR1M6MDAwMDAwMDAwMDAwMDAwMA0KPiBbICAgNzUuNzcxMDAwXSBDUzogIDAw
MTAgRFM6IDAwMDAgRVM6IDAwMDAgQ1IwOiAwMDAwMDAwMDgwMDUwMDMzDQo+IFsgICA3NS43
NzEwMDddIENSMjogMDAwMDc0ZmE2NGFhZGMwOCBDUjM6IDAwMDAwMDAwMTA1ZDIwMDYgQ1I0
OiAwMDAwMDAwMDAwNzcwZWYwDQo+IFsgICA3NS43NzEwMTZdIFBLUlU6IDU1NTU1NTU0DQo+
IFsgICA3NS43NzEwMTldIENhbGwgVHJhY2U6DQo+IFsgICA3NS43NzEwMjRdICA8VEFTSz4N
Cj4gWyAgIDc1Ljc3MTAyOF0gID8gc2hvd190cmFjZV9sb2dfbHZsKzB4MWIwLzB4MmYwDQo+
IFsgICA3NS43NzEwMzZdICA/IHNob3dfdHJhY2VfbG9nX2x2bCsweDFiMC8weDJmMA0KPiBb
ICAgNzUuNzcxMDQyXSAgPyBkb19vbmVfaW5pdGNhbGwrMHg1OC8weDMxMA0KPiBbICAgNzUu
NzcxMDQ4XSAgPyBfX2RpZV9ib2R5LmNvbGQrMHg4LzB4MTINCj4gWyAgIDc1Ljc3MTA1M10g
ID8gZGllX2FkZHIrMHgzYy8weDYwDQo+IFsgICA3NS43NzEwNTldICA/IGV4Y19nZW5lcmFs
X3Byb3RlY3Rpb24rMHgxN2QvMHg0MDANCj4gWyAgIDc1Ljc3MTA2Nl0gID8gYXNtX2V4Y19n
ZW5lcmFsX3Byb3RlY3Rpb24rMHgyNi8weDMwDQo+IFsgICA3NS43NzEwNzRdICA/IG1zZnRf
bW9uaXRvcl9kZXZpY2VfZGVsKzB4OTMvMHgxNzAgW2JsdWV0b290aF0NCj4gWyAgIDc1Ljc3
MTA5NV0gID8gYnRfaW5pdCsweDU0LzB4MWQwIFtibHVldG9vdGhdDQo+IFsgICA3NS43NzEx
MTRdICA/IF9fcGZ4X2J0X2luaXQrMHgxMC8weDEwIFtibHVldG9vdGhdDQo+IFsgICA3NS43
NzExMzFdICA/IGRvX29uZV9pbml0Y2FsbCsweDU4LzB4MzEwDQo+IFsgICA3NS43NzExMzdd
ICA/IGRvX2luaXRfbW9kdWxlKzB4OTAvMHgyNTANCj4gWyAgIDc1Ljc3MTE0Ml0gID8gaW5p
dF9tb2R1bGVfZnJvbV9maWxlKzB4ODYvMHhjMA0KPiBbICAgNzUuNzcxMTQ5XSAgPyBpZGVt
cG90ZW50X2luaXRfbW9kdWxlKzB4MTE1LzB4MzEwDQo+IFsgICA3NS43NzExNTZdICA/IF9f
eDY0X3N5c19maW5pdF9tb2R1bGUrMHg2NS8weGMwDQo+IFsgICA3NS43NzExNjNdICA/IGRv
X3N5c2NhbGxfNjQrMHg4Mi8weDE2MA0KPiBbICAgNzUuNzcxMTY4XSAgPyBiYWNraW5nX2Zp
bGVfcmVhZF9pdGVyKzB4MTU2LzB4MWYwDQo+IFsgICA3NS43NzExNzZdICA/IG92bF9yZWFk
X2l0ZXIrMHg5NC8weGEwIFtvdmVybGF5XQ0KPiBbICAgNzUuNzcxMTg5XSAgPyBfX3BmeF9v
dmxfZmlsZV9hY2Nlc3NlZCsweDEwLzB4MTAgW292ZXJsYXldDQo+IFsgICA3NS43NzExOTld
ICA/IHJzZXFfZ2V0X3JzZXFfY3MrMHgxZC8weDIyMA0KPiBbICAgNzUuNzcxMjA1XSAgPyBy
c2VxX2lwX2ZpeHVwKzB4OGQvMHgxZDANCj4gWyAgIDc1Ljc3MTIxMF0gID8gX19zZWNjb21w
X2ZpbHRlcisweDMwMy8weDUyMA0KPiBbICAgNzUuNzcxMjE2XSAgPyBzeXNjYWxsX2V4aXRf
dG9fdXNlcl9tb2RlX3ByZXBhcmUrMHgxNWUvMHgxYTANCj4gWyAgIDc1Ljc3MTIyNF0gID8g
c3lzY2FsbF9leGl0X3RvX3VzZXJfbW9kZSsweDEwLzB4MjEwDQo+IFsgICA3NS43NzEyMzFd
ICA/IGRvX3N5c2NhbGxfNjQrMHg4ZS8weDE2MA0KPiBbICAgNzUuNzcxMjM2XSAgPyBkb19z
eXNfb3BlbmF0MisweDljLzB4ZTANCj4gWyAgIDc1Ljc3MTI0MV0gID8gc3lzY2FsbF9leGl0
X3RvX3VzZXJfbW9kZV9wcmVwYXJlKzB4MTVlLzB4MWEwDQo+IFsgICA3NS43NzEyNDldICA/
IHN5c2NhbGxfZXhpdF90b191c2VyX21vZGUrMHgxMC8weDIxMA0KPiBbICAgNzUuNzcxMjU1
XSAgPyBkb19zeXNjYWxsXzY0KzB4OGUvMHgxNjANCj4gWyAgIDc1Ljc3MTI2MF0gID8gZG9f
dXNlcl9hZGRyX2ZhdWx0KzB4MWVjLzB4N2IwDQo+IFsgICA3NS43NzEyNjddICA/IGVudHJ5
X1NZU0NBTExfNjRfYWZ0ZXJfaHdmcmFtZSsweDc2LzB4N2UNCj4gWyAgIDc1Ljc3MTI3NF0g
IDwvVEFTSz4NCj4gWyAgIDc1Ljc3MTI3N10gTW9kdWxlcyBsaW5rZWQgaW46IGJsdWV0b290
aCgrKSByZmtpbGwgc25kX3NlcV9kdW1teSBzbmRfaHJ0aW1lciBzbmRfc2VxIHNuZF9zZXFf
ZGV2aWNlIHNuZF90aW1lciBzbmQgc291bmRjb3JlIG5mdF9yZWplY3RfaXB2NiBuZl9yZWpl
Y3RfaXB2NiBuZnRfcmVqZWN0X2lwdjQgbmZfcmVqZWN0X2lwdjQgbmZ0X3JlamVjdCBpbnRl
bF9yYXBsX21zciBpbnRlbF9yYXBsX2NvbW1vbiBuZnRfY3QgaW50ZWxfdW5jb3JlX2ZyZXF1
ZW5jeV9jb21tb24gaW50ZWxfcG1jX2NvcmUgaW50ZWxfdnNlYyBqb3lkZXYgbmZ0X21hc3Eg
cG10X3RlbGVtZXRyeSBwbXRfY2xhc3MgbmZ0X2NoYWluX25hdCBuZl9uYXQgbmZfY29ubnRy
YWNrIG5mX2RlZnJhZ19pcHY2IG5mX2RlZnJhZ19pcHY0IGNyY3QxMGRpZl9wY2xtdWwgY3Jj
MzJfcGNsbXVsIGNyYzMyY19pbnRlbCBwb2x5dmFsX2NsbXVsbmkgeGhjaV9wY2kgcG9seXZh
bF9nZW5lcmljIGdoYXNoX2NsbXVsbmlfaW50ZWwgeGhjaV9oY2Qgc2hhNTEyX3Nzc2UzIHNo
YTI1Nl9zc3NlMyBuZl90YWJsZXMgc2hhMV9zc3NlMyBlaGNpX3BjaSBtZWlfbWUgZWhjaV9o
Y2QgcGNzcGtyIG1laSBhdGFfZ2VuZXJpYyBwYXRhX2FjcGkgaTJjX3BpaXg0IGkyY19zbWJ1
cyBzZXJpb19yYXcgeGVuX3Njc2liYWNrIHRhcmdldF9jb3JlX21vZCB4ZW5fbmV0YmFjayB4
ZW5fcHJpdmNtZCB4ZW5fZ250ZGV2IHhlbl9nbnRhbGxvYyB4ZW5fYmxrYmFjayB4ZW5fZXZ0
Y2huIGxvb3AgZnVzZSBuZm5ldGxpbmsgb3ZlcmxheSB4ZW5fYmxrZnJvbnQNCj4gWyAgIDc1
Ljc3MTM3MF0gLS0tWyBlbmQgdHJhY2UgMDAwMDAwMDAwMDAwMDAwMCBdLS0tDQo+IFsgICA3
NS43NzEzNzZdIFJJUDogMDAxMDptc2Z0X21vbml0b3JfZGV2aWNlX2RlbCsweDkzLzB4MTcw
IFtibHVldG9vdGhdDQo+IFsgICA3NS43NzEzOTddIENvZGU6IDAwIDAwIDAwIDAwIDAwIDAw
IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw
IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIGQwIDY1IDIx
IDwyNj4gMmIgOGIgYWQgMDMgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg
MDAgMDAgMDAgMDAgMDANCj4gWyAgIDc1Ljc3MTQxNl0gUlNQOiAwMDAwOmZmZmZhZDY0NDEw
OGZhNDAgRUZMQUdTOiAwMDAxMDI0Ng0KPiBbICAgNzUuNzcxNDIyXSBSQVg6IGZmZmY5M2Rh
OGExNDk2MDAgUkJYOiBjOWQyMzE1YmM4MmMzODEwIFJDWDogMDAwMDAwMDEwMDAwMDAwMA0K
PiBbICAgNzUuNzcxNDMxXSBSRFg6IDAwMDAwMDAwMDAwMDAwMDEgUlNJOiBmZmZmOTNkYTkw
NWU5MTgwIFJESTogZmZmZjkzZGE4MTQwNDU5OA0KPiBbICAgNzUuNzcxNDM5XSBSQlA6IGZm
ZmZhZDY0NDEwOGZhNTggUjA4OiAwMDAwMDAwMDAwMDAwMDY0IFIwOTogMDAwMDAwMDAwMDAw
MTJhYg0KPiBbICAgNzUuNzcxNDQ2XSBSMTA6IGZmZmY5M2RhODEyMDcwMDAgUjExOiAwMDAw
MDAwMDAwMDAwMjg2IFIxMjogZmZmZmFkNjQ0MTA4ZmIwMA0KPiBbICAgNzUuNzcxNDU0XSBS
MTM6IGZmZmZhZDY0NDEwOGZhNjggUjE0OiBmZmZmOTNkYTkwODliODQwIFIxNTogZmZmZjkz
ZGE4YzI2NTEwMA0KPiBbICAgNzUuNzcxNDYzXSBGUzogIDAwMDA3OGZhNGNlYzRiYzAoMDAw
MCkgR1M6ZmZmZjkzZGE5NzAwMDAwMCgwMDAwKSBrbmxHUzowMDAwMDAwMDAwMDAwMDAwDQo+
IFsgICA3NS43NzE0NzFdIENTOiAgMDAxMCBEUzogMDAwMCBFUzogMDAwMCBDUjA6IDAwMDAw
MDAwODAwNTAwMzMNCj4gWyAgIDc1Ljc3MTQ3N10gQ1IyOiAwMDAwNzRmYTY0YWFkYzA4IENS
MzogMDAwMDAwMDAxMDVkMjAwNiBDUjQ6IDAwMDAwMDAwMDA3NzBlZjANCj4gWyAgIDc1Ljc3
MTQ4NV0gUEtSVTogNTU1NTU1NTQNCj4gWyAgIDc1Ljc3MTQ4OF0gS2VybmVsIHBhbmljIC0g
bm90IHN5bmNpbmc6IEZhdGFsIGV4Y2VwdGlvbg0KPiBbICAgNzUuNzcxNTE5XSBLZXJuZWwg
T2Zmc2V0OiAweDNiODAwMDAwIGZyb20gMHhmZmZmZmZmZjgwMjAwMDAwIChyZWxvY2F0aW9u
IHJhbmdlOiAweGZmZmZmZmZmODAwMDAwMDAtMHhmZmZmZmZmZmJmZmZmZmZmKQ0KPiANCj4g
RnVsbCBsb2cgaW5zaWRlDQo+IGh0dHBzOi8vb3BlbnFhLnF1YmVzLW9zLm9yZy90ZXN0cy8x
MjQ3MzYvZmlsZS91c2J2bS12YXJfbG9nLnRhci5neg0KPiAobG9nL3hlbi9jb25zb2xlL2d1
ZXN0LXN5cy11c2IubG9nKQ0KPiANCg0K
--------------C1tWsHDrPBoySZFp4ltYncuc
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

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

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

--------------C1tWsHDrPBoySZFp4ltYncuc--

--------------OnuG2lIn3uDHSCcnHKEJfbF3--

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

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

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmd25iwFAwAAAAAACgkQsN6d1ii/Ey8H
mQf+PtuUiYRWcKjJ3H+jL/L6kwE8fo9NcbCGUgIcXMY/nkT9xl7Pt/liZJMzSM63AAuXP3dRIqvU
ySfMYVmTld048bGCvMhM0a+6j1AC/qY6GtWmiIJWuGfXB8l/ad8LxuGBY/q6u8nXIROESty6am4m
1tU9bqnRBoXQ9VMnGRz9xYxBU2+9D0tz/RamTX0advb7g0pAP5V1XxBmwhBZjBBjex3C3wCFbllj
i9Q4XJmYVPsXi6Irj/YRqyXxomc6j9LIv6BKTwf5Z819V1/8li/nP96w3NBrqNkNc5Y9WTkkVsfD
NsBcH3iF2CIxWPy4ZVPu4XHKSklW08jyflW7YosjLA==
=mihI
-----END PGP SIGNATURE-----

--------------W512nT36UmdTJlmwF9PEG7Wf--


From xen-devel-bounces@lists.xenproject.org Thu Jan 02 19:25:18 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 19:25:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864431.1275659 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTQon-0003JA-4t; Thu, 02 Jan 2025 19:25:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864431.1275659; Thu, 02 Jan 2025 19:25:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTQon-0003Iz-1Z; Thu, 02 Jan 2025 19:25:17 +0000
Received: by outflank-mailman (input) for mailman id 864431;
 Thu, 02 Jan 2025 19:25: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
 <SRS0=xoa/=T2=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tTQol-00030j-L2
 for xen-devel@lists.xenproject.org; Thu, 02 Jan 2025 19:25:15 +0000
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com
 [2a00:1450:4864:20::429])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4abc98d2-c93f-11ef-a0dc-8be0dac302b0;
 Thu, 02 Jan 2025 20:25:14 +0100 (CET)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-3863494591bso6151745f8f.1
 for <xen-devel@lists.xenproject.org>; Thu, 02 Jan 2025 11:25:14 -0800 (PST)
Received: from andrewcoop.lan ([83.105.36.37])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c6ad3e3sm40212825f8f.0.2025.01.02.11.25.12
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 02 Jan 2025 11:25:12 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 4abc98d2-c93f-11ef-a0dc-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1735845914; x=1736450714; 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=gNg/xL5jgFrtg8KGSp8+PUC646w5vHXUt7CvxvruBYw=;
        b=rupzvsGwV4T7VztuA5Fdvu9Ta8kQbO5qUMTpWHE5p5lDU+NTaLKWERUkqZBuCNlkEI
         hPHHSSEwxkUsfamWRL5ZtgiptdWLEsYh0NyKQeb/cEi67jNEhsu3CXTarg9+EeqJGmqU
         QTs5hL9Mn9eTxBfnxlE8ejVRpiQS7Aeo05oJA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735845914; x=1736450714;
        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=gNg/xL5jgFrtg8KGSp8+PUC646w5vHXUt7CvxvruBYw=;
        b=VUBYIRoB6n1gGrc/+tbxu83WiH+ENxO4hspAPZKD0b9SsVTKDacw+H+roA85eYC0nU
         E5Ct7DgqDWTuep6C9urfsJGuSaxvh9OhZqZCPGIRagW8ostD9jhOuSsdhoI6tcoOvRMg
         c76OhPIlFdsqymRNW5Lu5gbknb+OtAUKKKVgOTcvAfmRCNa0zaeCvX72AYouUl0MQoFw
         PIEyw2Pr3q+d1R85vStDG7nvDd6F12h2jaaeWxDgNO77hJwTr3MeO4sqyjk2y3JrX45P
         0XxVHU6184f3g9Qr99qkm9qbL6Kb4JnmgpLGjQ8Q35hjR8MDx6I+7x/50qvjSoOZL6AV
         d4BQ==
X-Gm-Message-State: AOJu0YxqHECluwZlmCyQ6nw3cdPUiNQfgiNE4kQxxKr3q44lJSJYy6+e
	liMnSB3YqIame/Jv2yWC/XSeLeb5J6zSfu3picI2fpY5nMmq6xOm4Y+68CfXTaAGpT0jpk412Bj
	I/gKvDg==
X-Gm-Gg: ASbGnctx3uPO0BwGxuFB3BRIHcm9SEMZakZR61FRhygDaTxax4OZPiXPokPC1CSGSlT
	yuiCzGFcbni/WBj5jrFrl4rZc/SWdUjmIL6tj+FzmHt9TpQjtkdbf3UW548WETfsv6XQ/ooNk9k
	ZAJy7x3a6V/XanbFMeiStDTVwUXIEAJJNcETJjPolbOgEyFvDcK8FyHZyiof7biDNx7QGc5jLB0
	iiO+VGGTs6UdAf8CgUg3ljBKSfUNDAl3f1ihrblzR5icWvv0GXgMo1aoNy0oLAgWw==
X-Google-Smtp-Source: AGHT+IEO0jFa1wsTom2pBAvfDBImQ+92OtAvCK8OHQn98ont8h1Zd3voDTpF+kkLcK3kGKcB23SwrQ==
X-Received: by 2002:a05:6000:18ae:b0:385:e5d6:130c with SMTP id ffacd0b85a97d-38a22408dcfmr33328269f8f.51.1735845913749;
        Thu, 02 Jan 2025 11:25:13 -0800 (PST)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Shawn Anastasio <sanastasio@raptorengineering.com>
Subject: [PATCH 2/5] xen/perfc: Add perfc_defn.h to asm-generic
Date: Thu,  2 Jan 2025 19:25:05 +0000
Message-Id: <20250102192508.2405687-3-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250102192508.2405687-1-andrew.cooper3@citrix.com>
References: <20250102192508.2405687-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

... and hook it up for RISC-V and PPC.

On RISC-V at least, no combination of headers pulls in errno.h, so include it
explicitly.

Guard the hypercalls array declaration based on NR_hypercalls existing.  This
is sufficient to get PERF_COUNTERS fully working on RISC-V and PPC, so drop
the randconfig override.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Roger Pau Monné <roger.pau@citrix.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Julien Grall <julien@xen.org>
CC: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
CC: Bertrand Marquis <bertrand.marquis@arm.com>
CC: Michal Orzel <michal.orzel@amd.com>
CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
CC: Shawn Anastasio <sanastasio@raptorengineering.com>
---
 automation/gitlab-ci/build.yaml      | 1 -
 xen/arch/ppc/include/asm/Makefile    | 1 +
 xen/arch/riscv/include/asm/Makefile  | 1 +
 xen/common/perfc.c                   | 1 +
 xen/include/asm-generic/perfc_defn.h | 5 +++++
 xen/include/xen/perfc_defn.h         | 2 ++
 6 files changed, 10 insertions(+), 1 deletion(-)
 create mode 100644 xen/include/asm-generic/perfc_defn.h

diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
index 1b884cc81cdb..41f17ed45641 100644
--- a/automation/gitlab-ci/build.yaml
+++ b/automation/gitlab-ci/build.yaml
@@ -734,7 +734,6 @@ debian-12-riscv64-gcc:
       CONFIG_GRANT_TABLE=n
       CONFIG_LIVEPATCH=n
       CONFIG_MEM_ACCESS=n
-      CONFIG_PERF_COUNTERS=n
       CONFIG_QEMU_PLATFORM=y
       CONFIG_XSM=n
 
diff --git a/xen/arch/ppc/include/asm/Makefile b/xen/arch/ppc/include/asm/Makefile
index ced02e26ed13..c989a7f89b34 100644
--- a/xen/arch/ppc/include/asm/Makefile
+++ b/xen/arch/ppc/include/asm/Makefile
@@ -7,6 +7,7 @@ generic-y += hypercall.h
 generic-y += iocap.h
 generic-y += paging.h
 generic-y += percpu.h
+generic-y += perfc_defn.h
 generic-y += random.h
 generic-y += softirq.h
 generic-y += vm_event.h
diff --git a/xen/arch/riscv/include/asm/Makefile b/xen/arch/riscv/include/asm/Makefile
index ced02e26ed13..c989a7f89b34 100644
--- a/xen/arch/riscv/include/asm/Makefile
+++ b/xen/arch/riscv/include/asm/Makefile
@@ -7,6 +7,7 @@ generic-y += hypercall.h
 generic-y += iocap.h
 generic-y += paging.h
 generic-y += percpu.h
+generic-y += perfc_defn.h
 generic-y += random.h
 generic-y += softirq.h
 generic-y += vm_event.h
diff --git a/xen/common/perfc.c b/xen/common/perfc.c
index ed4dba36f1bc..8c967ab900f9 100644
--- a/xen/common/perfc.c
+++ b/xen/common/perfc.c
@@ -1,4 +1,5 @@
 
+#include <xen/errno.h>
 #include <xen/lib.h>
 #include <xen/smp.h>
 #include <xen/time.h>
diff --git a/xen/include/asm-generic/perfc_defn.h b/xen/include/asm-generic/perfc_defn.h
new file mode 100644
index 000000000000..8237636d83fb
--- /dev/null
+++ b/xen/include/asm-generic/perfc_defn.h
@@ -0,0 +1,5 @@
+/* This file is legitimately included multiple times. */
+/* #ifndef ASM_GENERIC_PERFC_DEFN_H */
+/* #define ASM_GENERIC_PERFC_DEFN_H */
+
+/* #endif ASM_GENERIC_PERFC_DEFN_H */
diff --git a/xen/include/xen/perfc_defn.h b/xen/include/xen/perfc_defn.h
index 0027d95a60bc..a987d80dd6f1 100644
--- a/xen/include/xen/perfc_defn.h
+++ b/xen/include/xen/perfc_defn.h
@@ -4,7 +4,9 @@
 
 #include <asm/perfc_defn.h>
 
+#ifdef NR_hypercalls
 PERFCOUNTER_ARRAY(hypercalls,           "hypercalls", NR_hypercalls)
+#endif
 
 PERFCOUNTER(calls_from_multicall,       "calls from multicall")
 
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Thu Jan 02 19:25:18 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 19:25:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864429.1275640 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTQok-0002qD-OR; Thu, 02 Jan 2025 19:25:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864429.1275640; Thu, 02 Jan 2025 19:25:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTQok-0002q6-JU; Thu, 02 Jan 2025 19:25:14 +0000
Received: by outflank-mailman (input) for mailman id 864429;
 Thu, 02 Jan 2025 19:25: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
 <SRS0=xoa/=T2=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tTQoj-0002q0-B9
 for xen-devel@lists.xenproject.org; Thu, 02 Jan 2025 19:25:13 +0000
Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com
 [2a00:1450:4864:20::443])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 48be1429-c93f-11ef-99a4-01e77a169b0f;
 Thu, 02 Jan 2025 20:25:11 +0100 (CET)
Received: by mail-wr1-x443.google.com with SMTP id
 ffacd0b85a97d-385deda28b3so8047505f8f.0
 for <xen-devel@lists.xenproject.org>; Thu, 02 Jan 2025 11:25:11 -0800 (PST)
Received: from andrewcoop.lan ([83.105.36.37])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c6ad3e3sm40212825f8f.0.2025.01.02.11.25.09
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 02 Jan 2025 11:25:09 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 48be1429-c93f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1735845910; x=1736450710; 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=1hD0trAxzjEWjoFFReJetxCC4U5WDabNle+KAwR5/R8=;
        b=Hic9JS5FwprFDoKAKZeTs7HiM0x6+3R+sfk3Zay/71iyNTlwKrRk4bbCbyOoPjBLxB
         Nn/cksrhQCtvNGYDWLuAckRtRClQMTj3RTSS9qYo3/ODk1CMOaNcGIOAzXett/AbCOb4
         f7A6mJHqc2KioBHjDrvu+uV9p5OcOESOiKkXQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735845910; x=1736450710;
        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=1hD0trAxzjEWjoFFReJetxCC4U5WDabNle+KAwR5/R8=;
        b=hqp476p8xPjkoANPeuZ2l+vNlyBZ4pkGH8TaFS2c5nVGaaBrDpwZ5XoRSERHkgzLsP
         WGnWCVJpukjRE2ZurYW3sB7Evvus8Qrd7l4/Is4iNm30CHa9HI7UtUa3h0RvmElL6cmf
         uCMt6Vrcp35zQ8+x6agDd/6wUKQyMqOix0mI7y+qiiOdHzodldwEd57/hVbpqTps6gX4
         ZRjIzz84hOWM4P3NgFVMAzxp+RaeFPdR1WMMgz6RSFenVJJ8npyQo4o06EfFLRCLihOV
         iOsW1gnV/ztVpNnGJKN0qaGhkgqK5Njkmz6RUx6AQpe8RMxSoKJzbwWTeyAG3iYv7Iiz
         uu9Q==
X-Gm-Message-State: AOJu0YxTgroWiw/GwjlnW/QgHBYa2mUGHJ6PrtFEiTPw1tDdDu6CJZZ1
	A6ZgxTH6epDReM79qODB2qedS73awwoXoWJEf3GHucCfDQoHnuLV+OyPLQW2jPvuNRcshiVVLg/
	3PPPQgFAx
X-Gm-Gg: ASbGncvhmTW04DXvyT88fwZmZ1RiwqS/xA3Ul7voFuhiW5uDKr+tPAz7O9UdadMOMSR
	qX26i5UYzEi+goEsMzQdhF7XguZKkxeKkbEGd6ppbj19ZtW8nZaS3ZybHAStrFbziAnTFev86HD
	3ea7tGtAs0+SW1Rl3lyNAJ40HESOewopx1xCMhrlj+tRTHeL2VK4v0gLRJ4XTK1qSzs2P6BSAOW
	sUye4ZhuzZo/QGUsLq/oKRepj36RKorrDmNQsNaSNVRMcX3E/LFyJQb7LlqE3FNCw==
X-Google-Smtp-Source: AGHT+IHDcr/WeXOUI6UXgcRLT/uCfdFcrSv8UmjTWhziOGUv5tHJtF8vtYcQgbw7+zF4VJOp3s6kHw==
X-Received: by 2002:a5d:5f82:0:b0:385:ee59:4510 with SMTP id ffacd0b85a97d-38a221e17d0mr35340168f8f.9.1735845910401;
        Thu, 02 Jan 2025 11:25:10 -0800 (PST)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Shawn Anastasio <sanastasio@raptorengineering.com>
Subject: [PATCH for-4.20? 0/5] xen/perfc: Cleanup, and wire up for RISCV/PPC
Date: Thu,  2 Jan 2025 19:25:03 +0000
Message-Id: <20250102192508.2405687-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This started as just patch 3 fixing a header tangle with FRED on x86, but grew
somewhat.

It's simple, straight forward, and gets perf counters working uniformly on all
architectures, and a net reduction in code.

It's low risk, and should be considered for 4.20 at this juncture.

https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/1609450793

Andrew Cooper (5):
  xen/perfc: Drop arch_perfc_{gather,reset}()
  xen/perfc: Add perfc_defn.h to asm-generic
  xen/perfc: Trim includes
  xen/perfc: Cleanup
  xen/perfc: COMPILE TEST

 automation/gitlab-ci/build.yaml      |  1 -
 xen/Kconfig.debug                    | 14 ++++----------
 xen/arch/arm/include/asm/perfc.h     | 21 ---------------------
 xen/arch/ppc/include/asm/Makefile    |  1 +
 xen/arch/riscv/include/asm/Makefile  |  1 +
 xen/arch/x86/include/asm/perfc.h     | 12 ------------
 xen/common/perfc.c                   | 26 ++++++++++----------------
 xen/include/asm-generic/perfc_defn.h |  5 +++++
 xen/include/xen/perfc.h              | 26 ++++++++++++--------------
 xen/include/xen/perfc_defn.h         |  2 ++
 10 files changed, 35 insertions(+), 74 deletions(-)
 delete mode 100644 xen/arch/arm/include/asm/perfc.h
 delete mode 100644 xen/arch/x86/include/asm/perfc.h
 create mode 100644 xen/include/asm-generic/perfc_defn.h


base-commit: a1746cd4434dd27ca2da8430dfb10edc76264bb3
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Thu Jan 02 19:25:18 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 19:25:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864430.1275649 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTQol-00034O-Tt; Thu, 02 Jan 2025 19:25:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864430.1275649; Thu, 02 Jan 2025 19:25:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTQol-00034E-Qf; Thu, 02 Jan 2025 19:25:15 +0000
Received: by outflank-mailman (input) for mailman id 864430;
 Thu, 02 Jan 2025 19:25: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
 <SRS0=xoa/=T2=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tTQol-0002q0-0B
 for xen-devel@lists.xenproject.org; Thu, 02 Jan 2025 19:25:15 +0000
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com
 [2a00:1450:4864:20::42f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4a01602b-c93f-11ef-99a4-01e77a169b0f;
 Thu, 02 Jan 2025 20:25:13 +0100 (CET)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-385ef8b64b3so9172202f8f.0
 for <xen-devel@lists.xenproject.org>; Thu, 02 Jan 2025 11:25:13 -0800 (PST)
Received: from andrewcoop.lan ([83.105.36.37])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c6ad3e3sm40212825f8f.0.2025.01.02.11.25.10
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 02 Jan 2025 11:25:10 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 4a01602b-c93f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1735845912; x=1736450712; 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=sf4IwgriP6BBrdUD4Z6hthsNRYM6SLFzNyUPek/Qf+o=;
        b=TB2ewHkUfsUh1a0Q720toiTxnoRyPtAU6p1DZjNSs416GDH264j6y3umA/+v+tBHr5
         XoKL5eL76bJBSYMMPbvhc6pXrmETNnZJCjQgwGc3G4yfzOEt1ZxIV3lgKfoGX1LsAw02
         tSoRIHSexUTVPMJt7OZWqA5KG38b/wiuIZljQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735845912; x=1736450712;
        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=sf4IwgriP6BBrdUD4Z6hthsNRYM6SLFzNyUPek/Qf+o=;
        b=AFu9ckD8w/trugSflzzjcftf5GLKplhJmek2vX9l+1YFA8k3BRzo8GQM78es2tH40J
         5Dbr/oN8LrSALWHDCwugK/lfCwT5cSq9NkNoudgxCF0oM/sfXE2Ud24iWfGYlf62encA
         A4LIh5N9LCEUXstj8rUo5bKeS2S9rWUWAXH3GaiHTWJHiaerlPccckrQBo+szrdZTQdU
         +jpki8HsxrqIXsoWduIuHrmxT/omHiU7zVK6twe6t74kEI/XY2xRRDhXllRfiyrkyUyi
         ozvsuuzse0vekzFtCEZGLS79dMbskrkvrrxX4szEPR/+KBb7wHnDsKk/DrUwilVybHxV
         8Lkw==
X-Gm-Message-State: AOJu0YzH6L18CwLBc194qA/aabafoeMkiEb5jcbBuSJnjqkyxGeP/YOH
	jeTKkcesLOPChwKtoW7hQcdOerKLhVm/CJ83sP6pAuZwyZS3IhaZi9Gy/GGvnTjnyDYghWdbyjZ
	csRulGQ==
X-Gm-Gg: ASbGncuqFAa6p4mfYc4LsiAg4d6QA+1ydZ7BxTvfd555Tn9PcSakfswUU6kc4EVfmPg
	N1H+E4eIrQlF5WSBrGFFGR8ManxfRa4WSlzQI/5IXPlyjuvrsQs2f7hiIw5lJ12RzVsZ/dpkmyA
	EI93pK+6FEQFXitcJ60HkA2xde0yOVkmLnUcRnHWl6YrwMFgIqizjWJXh3nWGL8otygsdy6j4O3
	pRgOZfW5DEZiv5eIjvyMGQrTf/5qzT/R4HOLOEMlXd/W4pqZTUxCZMRCKhAmotihw==
X-Google-Smtp-Source: AGHT+IHZhaE5JRGQspuEbLzfCClbF7B1+c9HuqyKBXGcb8aEPjkff/W0gZNFUTorLh2/u8rhtbfKhw==
X-Received: by 2002:a5d:598f:0:b0:385:ed20:3be6 with SMTP id ffacd0b85a97d-38a221fa7f9mr40602449f8f.22.1735845912190;
        Thu, 02 Jan 2025 11:25:12 -0800 (PST)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Shawn Anastasio <sanastasio@raptorengineering.com>
Subject: [PATCH 1/5] xen/perfc: Drop arch_perfc_{gather,reset}()
Date: Thu,  2 Jan 2025 19:25:04 +0000
Message-Id: <20250102192508.2405687-2-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250102192508.2405687-1-andrew.cooper3@citrix.com>
References: <20250102192508.2405687-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

These were only ever used by the IA64 port, which was droped in commit
570c311ca2c7 ("remove ia64").

Remove them, and clean up the arm/x86 stub headers.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Roger Pau Monné <roger.pau@citrix.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Julien Grall <julien@xen.org>
CC: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
CC: Bertrand Marquis <bertrand.marquis@arm.com>
CC: Michal Orzel <michal.orzel@amd.com>
CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
CC: Shawn Anastasio <sanastasio@raptorengineering.com>
---
 xen/arch/arm/include/asm/perfc.h | 21 ---------------------
 xen/arch/x86/include/asm/perfc.h | 12 ------------
 xen/common/perfc.c               |  6 ------
 3 files changed, 39 deletions(-)
 delete mode 100644 xen/arch/arm/include/asm/perfc.h
 delete mode 100644 xen/arch/x86/include/asm/perfc.h

diff --git a/xen/arch/arm/include/asm/perfc.h b/xen/arch/arm/include/asm/perfc.h
deleted file mode 100644
index 95c4b2b6b7bf..000000000000
--- a/xen/arch/arm/include/asm/perfc.h
+++ /dev/null
@@ -1,21 +0,0 @@
-#ifndef __ASM_PERFC_H__
-#define __ASM_PERFC_H__
-
-static inline void arch_perfc_reset(void)
-{
-}
-
-static inline void arch_perfc_gather(void)
-{
-}
-
-#endif
-
-/*
- * Local variables:
- * mode: C
- * c-file-style: "BSD"
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/xen/arch/x86/include/asm/perfc.h b/xen/arch/x86/include/asm/perfc.h
deleted file mode 100644
index a1a591e803a6..000000000000
--- a/xen/arch/x86/include/asm/perfc.h
+++ /dev/null
@@ -1,12 +0,0 @@
-#ifndef __ASM_PERFC_H__
-#define __ASM_PERFC_H__
-
-static inline void arch_perfc_reset(void)
-{
-}
-
-static inline void arch_perfc_gather(void)
-{
-}
-
-#endif
diff --git a/xen/common/perfc.c b/xen/common/perfc.c
index 80480aa7766d..ed4dba36f1bc 100644
--- a/xen/common/perfc.c
+++ b/xen/common/perfc.c
@@ -8,7 +8,6 @@
 #include <xen/mm.h>
 #include <xen/guest_access.h>
 #include <public/sysctl.h>
-#include <asm/perfc.h>
 
 #define PERFCOUNTER( var, name )              { name, TYPE_SINGLE, 0 },
 #define PERFCOUNTER_ARRAY( var, name, size )  { name, TYPE_ARRAY,  size },
@@ -148,8 +147,6 @@ void cf_check perfc_reset(unsigned char key)
             break;
         }
     }
-
-    arch_perfc_reset();
 }
 
 static struct xen_sysctl_perfc_desc perfc_d[NR_PERFCTRS];
@@ -199,9 +196,6 @@ static int perfc_copy_info(XEN_GUEST_HANDLE_64(xen_sysctl_perfc_desc_t) desc,
     if ( perfc_vals == NULL )
         return -ENOMEM;
 
-    /* Architecture may fill counters from hardware.  */
-    arch_perfc_gather();
-
     /* We gather the counts together every time. */
     for ( i = j = v = 0; i < NR_PERFCTRS; i++ )
     {
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Thu Jan 02 19:25:19 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 19:25:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864432.1275668 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTQop-0003aG-Bc; Thu, 02 Jan 2025 19:25:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864432.1275668; Thu, 02 Jan 2025 19:25:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTQop-0003a9-8E; Thu, 02 Jan 2025 19:25:19 +0000
Received: by outflank-mailman (input) for mailman id 864432;
 Thu, 02 Jan 2025 19:25: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
 <SRS0=xoa/=T2=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tTQon-0002q0-Ej
 for xen-devel@lists.xenproject.org; Thu, 02 Jan 2025 19:25:17 +0000
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com
 [2a00:1450:4864:20::42e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4b766a05-c93f-11ef-99a4-01e77a169b0f;
 Thu, 02 Jan 2025 20:25:16 +0100 (CET)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-385e3621518so5505301f8f.1
 for <xen-devel@lists.xenproject.org>; Thu, 02 Jan 2025 11:25:15 -0800 (PST)
Received: from andrewcoop.lan ([83.105.36.37])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c6ad3e3sm40212825f8f.0.2025.01.02.11.25.13
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 02 Jan 2025 11:25:14 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 4b766a05-c93f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1735845915; x=1736450715; 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=QOJMLCrP3OxQrYrq1pK05nXAC3sNtvIsyQUyYuMkfEc=;
        b=JIj0LDUqMpjzd5mfR1ADoZ8pU+SIIkbuw0S5ASNS4acjsvZyLa7XaJlcjdyq3Mm1Zu
         5J0xeblIPYuDdYgr15lbhIPYgdPYBf0tjG3zqOgcW27sv57ZyesUucGoQyBGti+nUFZn
         zl+1BmrkHJyAGfl69n5eFtqgHq8lXwUy3Z+Mw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735845915; x=1736450715;
        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=QOJMLCrP3OxQrYrq1pK05nXAC3sNtvIsyQUyYuMkfEc=;
        b=xTFbZ7DgOUL6TzS8pQi2RJlwgFLEncDyX28aCiyVjpctcx3FcqzWE6x72WXjfj5bNM
         FfQ6UY2qyzS6cjyRVfBDHF6unbjij7HIghb3c2cP6JOVQ8Sy0Z+PIqwYHNuArVIBBpHe
         GxDK4Vca61Pa9aD53GJeYge0YTw2sCs/FATRtgjtft6hnIu7Rc5L/vtbW8SYdQR4WxfH
         cbQNZmNpI0EzP+6aNpjKR/UXFVIk+2s9WrX/+OlP67bWCdxiuzfIgz/EFYAobZ/VvZdu
         Kp1VjC1xjeaDz1+SK5NuMkyQ61LofjtfUPrxnRBsAn/0fOJO3pC9/J2rjXVYkzSxaM6O
         3B8A==
X-Gm-Message-State: AOJu0YypTTAjPTnQzOpStHtDdNf3FZ3T4l27gmE6G3LlPY+nUiUjVaFs
	YKYTVkloM9qPea1hL/btWSGqv6UBi2yT3Ya9TraxR28sZ7x8JizdnGYaqbFiHAPE0lxL1jRgF+U
	Y1CedDg==
X-Gm-Gg: ASbGnctbWnswGHpVXV6CsPvBViyMOGlAVfyvryyjAfIxmkmSPMYAB0RvVmhQivbOCZ2
	EAoC/BMZL42FQ489OwYQ5DglD/6VrzcMHSgJu0fBNYXeptEjPYdDz+LsBrYs8FGcNAnNkuTuHjS
	laaZqhPpt5UfNox7VhZ6aW2w10mIOYAzXZWR4DcCd/bbLdBmIWUHZtkY2vtAlS4UEbYw7zHz5dp
	yTo1srzJAyfuFK8GFV8ko0c2pblY+tKeWw8kPoLVk5rWUGQ9lH4h7h8G1emg824OQ==
X-Google-Smtp-Source: AGHT+IHT9RzM80xIxWi0z1qXFPQzXCeUKPAus090TwvbQSXMA9JxibnloWnNEkPsjtqGXIRtz1evYg==
X-Received: by 2002:a5d:6da1:0:b0:385:f631:612 with SMTP id ffacd0b85a97d-38a221ea944mr37003027f8f.17.1735845914949;
        Thu, 02 Jan 2025 11:25:14 -0800 (PST)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Shawn Anastasio <sanastasio@raptorengineering.com>
Subject: [PATCH 3/5] xen/perfc: Trim includes
Date: Thu,  2 Jan 2025 19:25:06 +0000
Message-Id: <20250102192508.2405687-4-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250102192508.2405687-1-andrew.cooper3@citrix.com>
References: <20250102192508.2405687-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This is mostly for the removal of xen/lib.h and xen/smp.h from perfc.h.  All
that is needed is xen/macros.h.

Trim and sort the includes for perfc.c too.  There's no need for smp.h,
keyhandler.h or mm.h, but cpumask.h is needed.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Roger Pau Monné <roger.pau@citrix.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Julien Grall <julien@xen.org>
CC: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
CC: Bertrand Marquis <bertrand.marquis@arm.com>
CC: Michal Orzel <michal.orzel@amd.com>
CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
CC: Shawn Anastasio <sanastasio@raptorengineering.com>
---
 xen/common/perfc.c      | 9 ++++-----
 xen/include/xen/perfc.h | 3 +--
 2 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/xen/common/perfc.c b/xen/common/perfc.c
index 8c967ab900f9..b748c8af855b 100644
--- a/xen/common/perfc.c
+++ b/xen/common/perfc.c
@@ -1,13 +1,12 @@
 
+#include <xen/cpumask.h>
 #include <xen/errno.h>
+#include <xen/guest_access.h>
 #include <xen/lib.h>
-#include <xen/smp.h>
-#include <xen/time.h>
 #include <xen/perfc.h>
-#include <xen/keyhandler.h> 
 #include <xen/spinlock.h>
-#include <xen/mm.h>
-#include <xen/guest_access.h>
+#include <xen/time.h>
+
 #include <public/sysctl.h>
 
 #define PERFCOUNTER( var, name )              { name, TYPE_SINGLE, 0 },
diff --git a/xen/include/xen/perfc.h b/xen/include/xen/perfc.h
index f9009dc388de..324b47665573 100644
--- a/xen/include/xen/perfc.h
+++ b/xen/include/xen/perfc.h
@@ -3,8 +3,7 @@
 
 #ifdef CONFIG_PERF_COUNTERS
 
-#include <xen/lib.h>
-#include <xen/smp.h>
+#include <xen/macros.h>
 #include <xen/percpu.h>
 
 /*
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Thu Jan 02 19:25:19 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 19:25:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864433.1275675 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTQop-0003dn-Ny; Thu, 02 Jan 2025 19:25:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864433.1275675; Thu, 02 Jan 2025 19:25:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTQop-0003d5-Gj; Thu, 02 Jan 2025 19:25:19 +0000
Received: by outflank-mailman (input) for mailman id 864433;
 Thu, 02 Jan 2025 19:25: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
 <SRS0=xoa/=T2=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tTQoo-0002q0-RD
 for xen-devel@lists.xenproject.org; Thu, 02 Jan 2025 19:25:18 +0000
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com
 [2a00:1450:4864:20::335])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4c3f7cac-c93f-11ef-99a4-01e77a169b0f;
 Thu, 02 Jan 2025 20:25:17 +0100 (CET)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-436a39e4891so28728715e9.1
 for <xen-devel@lists.xenproject.org>; Thu, 02 Jan 2025 11:25:17 -0800 (PST)
Received: from andrewcoop.lan ([83.105.36.37])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c6ad3e3sm40212825f8f.0.2025.01.02.11.25.15
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 02 Jan 2025 11:25:15 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 4c3f7cac-c93f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1735845916; x=1736450716; 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=edPTs5r2WJDCVGRT6f4/sc4UPJKROdeZIxE7m/aVPP0=;
        b=r4WSOnwTnXrykGyuCZynr4fY7npndJUt8wv+OjTcQ+k7zS2eOc64atuMRk/+lX6sks
         yxHRqXDIsVfmWw5qdf63/vvj4ql7C31X48bJ0qn9pAm8ACkYrjcz6eE83u11C9/qXlup
         07Gqx6sY+TXGv1bUYo7EsOq21BRZ8F4/SKp3w=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735845916; x=1736450716;
        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=edPTs5r2WJDCVGRT6f4/sc4UPJKROdeZIxE7m/aVPP0=;
        b=UOawGydv+CJKp9lnBVgFlvce2TKHQgprLDY1CmnRLQrykgtNEAkTCeRovi07sSnV6G
         k1Dk50ZNT1QF5vaCrOuOLGMLcLUIcBwgqusdAQDznysNl6hruvpryDvOYsbcRMmBbBxt
         S5cy2KMS10k8JQ2jXa5b4jZPpPyjy0gkog/XpNQ+DydFyLiDPO8tdP5Dhb0scmrqoSJM
         R+2TP8DpXfQRuNPWcvBiyFe5BqxigFiV5EF6S1Yni0lfnPcatqKIeCs9QBT465g2m8ve
         jlUSxFWSr+7IvspLLnAKdygOojTVS6cnzOnqlNYrCm2srBsmApMcR8c9viN9LEzmp57k
         trug==
X-Gm-Message-State: AOJu0YzwVpXBM2xl7Et8/H6xYEm1oqV/RB3CJeMMiIslxxmCS71gXyaK
	pKtQ78xv/tjnkxK/I/98svRUw5Ae56La9CRLYqQnmMPEOTUZgFGEcwngpWvOIuV8y03S6hrde2n
	oDKM8Tw==
X-Gm-Gg: ASbGnctWEJUacmgPhQPbnM10iQc65/PP+WYeX3vUVf4tE7CSRSaQyfki3w1mWst7wRa
	o/QsJaoQv6sxJiraOkoGZE3AOrzaLJ5poo/rZbmL3wjKnEDpzjb4pyW+J1MlR+tYoC6VgSJxk3x
	/kGxTvI58orqhyQeotOed3NslQkViktCPReaFPv3xsViA8djaqeEr6B197kTU6z8hvpcQfqwcLd
	vHTbwN+074AOu6VNzyDaV7N7Bu58G1jgDBbtGk1oiaybl6mZAapeE5HQnXpAi5T0w==
X-Google-Smtp-Source: AGHT+IHmGwLlaLgCcyaeWZID5RvfAd2XbtkcpcMbIkQLTV2v/kVVGKNpAQ/U5CkC4f4tvIrMym4x1g==
X-Received: by 2002:a05:600c:35cc:b0:434:f925:f5c9 with SMTP id 5b1f17b1804b1-43668547fd1mr365041085e9.6.1735845916238;
        Thu, 02 Jan 2025 11:25:16 -0800 (PST)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Shawn Anastasio <sanastasio@raptorengineering.com>
Subject: [PATCH 4/5] xen/perfc: Cleanup
Date: Thu,  2 Jan 2025 19:25:07 +0000
Message-Id: <20250102192508.2405687-5-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250102192508.2405687-1-andrew.cooper3@citrix.com>
References: <20250102192508.2405687-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

 * Strip trailing whitspace.
 * Remove PRIperfc.  It has never been used and isn't useful.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Roger Pau Monné <roger.pau@citrix.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Julien Grall <julien@xen.org>
CC: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
CC: Bertrand Marquis <bertrand.marquis@arm.com>
CC: Michal Orzel <michal.orzel@amd.com>
CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
CC: Shawn Anastasio <sanastasio@raptorengineering.com>
---
 xen/common/perfc.c      | 10 +++++-----
 xen/include/xen/perfc.h | 23 +++++++++++------------
 2 files changed, 16 insertions(+), 17 deletions(-)

diff --git a/xen/common/perfc.c b/xen/common/perfc.c
index b748c8af855b..8302b7cf6db1 100644
--- a/xen/common/perfc.c
+++ b/xen/common/perfc.c
@@ -46,7 +46,7 @@ void cf_check perfc_printall(unsigned char key)
         case TYPE_S_SINGLE:
             for_each_online_cpu ( cpu )
                 sum += per_cpu(perfcounters, cpu)[j];
-            if ( perfc_info[i].type == TYPE_S_SINGLE ) 
+            if ( perfc_info[i].type == TYPE_S_SINGLE )
                 sum = (perfc_t) sum;
             printk("TOTAL[%12Lu]", sum);
             if ( sum )
@@ -56,7 +56,7 @@ void cf_check perfc_printall(unsigned char key)
                 {
                     if ( k > 0 && (k % 4) == 0 )
                         printk("\n%53s", "");
-                    printk("  CPU%02u[%10"PRIperfc"u]", cpu, per_cpu(perfcounters, cpu)[j]);
+                    printk("  CPU%02u[%10u]", cpu, per_cpu(perfcounters, cpu)[j]);
                     ++k;
                 }
             }
@@ -71,7 +71,7 @@ void cf_check perfc_printall(unsigned char key)
                 for ( k = 0; k < perfc_info[i].nr_elements; k++ )
                     sum += counters[k];
             }
-            if ( perfc_info[i].type == TYPE_S_ARRAY ) 
+            if ( perfc_info[i].type == TYPE_S_ARRAY )
                 sum = (perfc_t) sum;
             printk("TOTAL[%12Lu]", sum);
             if (sum)
@@ -82,7 +82,7 @@ void cf_check perfc_printall(unsigned char key)
                     sum = 0;
                     for_each_online_cpu ( cpu )
                         sum += per_cpu(perfcounters, cpu)[j + k];
-                    if ( perfc_info[i].type == TYPE_S_ARRAY ) 
+                    if ( perfc_info[i].type == TYPE_S_ARRAY )
                         sum = (perfc_t) sum;
                     if ( (k % 4) == 0 )
                         printk("\n%16s", "");
@@ -98,7 +98,7 @@ void cf_check perfc_printall(unsigned char key)
                     sum = 0;
                     for ( n = 0; n < perfc_info[i].nr_elements; n++ )
                         sum += counters[n];
-                    if ( perfc_info[i].type == TYPE_S_ARRAY ) 
+                    if ( perfc_info[i].type == TYPE_S_ARRAY )
                         sum = (perfc_t) sum;
                     if ( k > 0 && (k % 4) == 0 )
                         printk("\n%53s", "");
diff --git a/xen/include/xen/perfc.h b/xen/include/xen/perfc.h
index 324b47665573..bf0eb032f7a9 100644
--- a/xen/include/xen/perfc.h
+++ b/xen/include/xen/perfc.h
@@ -8,24 +8,24 @@
 
 /*
  * NOTE: new counters must be defined in perfc_defn.h
- * 
+ *
  * Counter declarations:
  * PERFCOUNTER (counter, string)              define a new performance counter
  * PERFCOUNTER_ARRAY (counter, string, size)  define an array of counters
- * 
+ *
  * Unlike counters, status variables do not reset:
  * PERFSTATUS (counter, string)               define a new performance stauts
  * PERFSTATUS_ARRAY (counter, string, size)   define an array of status vars
- * 
- * unsigned long perfc_value  (counter)        get value of a counter  
+ *
+ * unsigned long perfc_value  (counter)        get value of a counter
  * unsigned long perfc_valuea (counter, index) get value of an array counter
- * unsigned long perfc_set  (counter, val)     set value of a counter  
+ * unsigned long perfc_set  (counter, val)     set value of a counter
  * unsigned long perfc_seta (counter, index, val) set value of an array counter
- * void perfc_incr  (counter)                  increment a counter          
+ * void perfc_incr  (counter)                  increment a counter
  * void perfc_decr  (counter)                  decrement a status
- * void perfc_incra (counter, index)           increment an array counter   
- * void perfc_add   (counter, value)           add a value to a counter     
- * void perfc_adda  (counter, index, value)    add a value to array counter 
+ * void perfc_incra (counter, index)           increment an array counter
+ * void perfc_add   (counter, value)           add a value to a counter
+ * void perfc_adda  (counter, index, value)    add a value to array counter
  * void perfc_print (counter)                  print out the counter
  */
 
@@ -49,7 +49,6 @@ enum {
 #undef PERFSTATUS_ARRAY
 
 typedef unsigned int perfc_t;
-#define PRIperfc ""
 
 DECLARE_PER_CPU(perfc_t[NUM_PERFCOUNTERS], perfcounters);
 
@@ -72,7 +71,7 @@ DECLARE_PER_CPU(perfc_t[NUM_PERFCOUNTERS], perfcounters);
 	 this_cpu(perfcounters)[PERFC_ ## x + (y)] = (v) : (v) )
 
 /*
- * Histogram: special treatment for 0 and 1 count. After that equally spaced 
+ * Histogram: special treatment for 0 and 1 count. After that equally spaced
  * with last bucket taking the rest.
  */
 #ifdef CONFIG_PERF_ARRAYS
@@ -98,7 +97,7 @@ int perfc_control(struct xen_sysctl_perfc_op *pc);
 extern void cf_check perfc_printall(unsigned char key);
 extern void cf_check perfc_reset(unsigned char key);
 
-    
+
 #else /* CONFIG_PERF_COUNTERS */
 
 #define perfc_value(x)    (0)
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Thu Jan 02 19:25:21 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 19:25:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864434.1275689 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTQor-00045e-2X; Thu, 02 Jan 2025 19:25:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864434.1275689; Thu, 02 Jan 2025 19:25:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTQoq-00045N-UC; Thu, 02 Jan 2025 19:25:20 +0000
Received: by outflank-mailman (input) for mailman id 864434;
 Thu, 02 Jan 2025 19:25: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
 <SRS0=xoa/=T2=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tTQoq-0002q0-7z
 for xen-devel@lists.xenproject.org; Thu, 02 Jan 2025 19:25:20 +0000
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com
 [2a00:1450:4864:20::431])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4d1df72f-c93f-11ef-99a4-01e77a169b0f;
 Thu, 02 Jan 2025 20:25:18 +0100 (CET)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-385e27c75f4so8304170f8f.2
 for <xen-devel@lists.xenproject.org>; Thu, 02 Jan 2025 11:25:18 -0800 (PST)
Received: from andrewcoop.lan ([83.105.36.37])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c6ad3e3sm40212825f8f.0.2025.01.02.11.25.16
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 02 Jan 2025 11:25:16 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 4d1df72f-c93f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1735845917; x=1736450717; 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=oZLrD2169y0WiqxGQqlgUiS8PafeeieTdE5/BAHflvs=;
        b=TZXc16wvXbyRAA4Yv4freQfdq27uDadvylYsP22S34kH9CTtRBJivst7gO2iSUYiG/
         7P6FVXDUVwU9iMKqcGXRAsOMFgaI2A6bZYxF23iSSEQ88Ot5/s35IscD2o1sUUJD8yvu
         SufsVL9Cj4m2EQ5tQ+VzBIyRSwlylfkHT4QYs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735845917; x=1736450717;
        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=oZLrD2169y0WiqxGQqlgUiS8PafeeieTdE5/BAHflvs=;
        b=L5RflT07VZsqJPkwWcmy61MvZV4KlC2COu5p9giokZmDY8GKTugPo6CfryjDPFSgx0
         TLMxjSNHBi/Dt83HLa/yEJgvHqKp0hU8GabrWIAtfV/AcCSwxYLlGqyAOjJf7/ut5UgM
         tlPZlFEVlox2beK+avGuEsCwtioxGn+JOXeVmZjs4qWQGWy0asIfnMSMQMz8VOqrNDKG
         4Xh73qRmD10mLr7NaZ0lqryGjiDV4iAk66myymc032F186MJcX+PPIvLyj2Kc/y6NolV
         SF3ZIEd1xyNceC5qJ8l+8cj2NXjdipA2Q+Pb6bl56eBMpD5HpNDWHX20qq0mVlnClg70
         yEIw==
X-Gm-Message-State: AOJu0Yy1n7LCpPfA/5XLTH8yquKv4dxkT3fkMAFsBoLy+O3fODm2jr0w
	fCeXW6XDqEtLzyCwOM9T/h21u+my0TPxexq1QiU6YQv4i1IA1MCjQOqs5byw0mlIef0d3jmA7F7
	LRNYFIw==
X-Gm-Gg: ASbGncsFzwLktojJGTKrFXg379rjKvpeR9nBBXs8eo8A9ZOAxwy2yBLI2clKEHCF6MG
	vZzGSNM+Q6dk1F9tA3wIUvpOHULZIloih07UyUF95ScRb/jTwBMo4x+7F/ZzPSsPFw1bIvgZnS5
	/c5BbiuCAhe+KUStUyz69Ap2xgQOqOKi0JQeACle/a7226N8y9QrTcUJef/akUIrmEpKMxe/RcT
	lVoxK+Rb0U6FPWBWRSXdPoFdaiJHp2wHLQdHAro8Wj6eGUiJZb8hWAZkAdolXN5qQ==
X-Google-Smtp-Source: AGHT+IGtGn+pb2aQvViqmRl5HdkbgQA0Wu/uDMVIbBVk/klXZ0Ms+zL+XT5rY3cwHrsVqMdi45a+ag==
X-Received: by 2002:a5d:6da3:0:b0:388:c61d:43e0 with SMTP id ffacd0b85a97d-38a223feb92mr34043638f8f.48.1735845917637;
        Thu, 02 Jan 2025 11:25:17 -0800 (PST)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: [PATCH 5/5] xen/perfc: COMPILE TEST
Date: Thu,  2 Jan 2025 19:25:08 +0000
Message-Id: <20250102192508.2405687-6-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250102192508.2405687-1-andrew.cooper3@citrix.com>
References: <20250102192508.2405687-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

---
 xen/Kconfig.debug | 14 ++++----------
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index c4a8d86912e0..9bc4eb2df353 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -60,18 +60,12 @@ config DEBUG_LOCKS
 	  checks will be performed when acquiring and releasing locks.
 
 config PERF_COUNTERS
-	bool "Performance Counters"
-	help
-	  Enables software performance counters that allows you to analyze
-	  bottlenecks in the system.  To access this data you can use serial
-	  console to print (and reset) using 'p' and 'P' respectively, or
-	  the 'xenperf' tool.
+	bool
+	default y
 
 config PERF_ARRAYS
-	bool "Performance Counter Array Histograms"
-	depends on PERF_COUNTERS
-	help
-	  Enables software performance counter array histograms.
+	bool
+	default y
 
 
 config VERBOSE_DEBUG
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Thu Jan 02 19:34:34 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 19:34:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864478.1275703 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTQxS-0007dt-RH; Thu, 02 Jan 2025 19:34:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864478.1275703; Thu, 02 Jan 2025 19:34:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTQxS-0007dm-OU; Thu, 02 Jan 2025 19:34:14 +0000
Received: by outflank-mailman (input) for mailman id 864478;
 Thu, 02 Jan 2025 19:34:13 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=AqxF=T2=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tTQxR-0007dg-AV
 for xen-devel@lists.xenproject.org; Thu, 02 Jan 2025 19:34:13 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org
 [2604:1380:4641:c500::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8975ca64-c940-11ef-99a4-01e77a169b0f;
 Thu, 02 Jan 2025 20:34:10 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 319155C61D0;
 Thu,  2 Jan 2025 19:33:27 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id DB3F1C4CED0;
 Thu,  2 Jan 2025 19:34:05 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8975ca64-c940-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1735846448;
	bh=vZq1cqN+aNzRmgLqQrKagZQ0ckejVp8p4duY8J+lGEs=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=gvpl54sfsmhAY+BFYS8BCSQVjlY6fTTCG2jd/HSJwPWoDeELH47G8VjMuUioV5rS/
	 pIjHM8NfplTERGm01tK2QJtrH1zDGs+5UlvI/jPcfBhQ4BPAHiKjKBfJ5TSvRE9cIZ
	 0FpQu0ozx1BN/nOOrNlRIl8o+hZsmHmLJDYqFTIM9zBPcYpNW4n5obwPU2hWhomQlG
	 cADO80obzfutDUJubexfoggnnSDn1Vzu8a5OaL1IMOJoLqdhmddNSaH656e02XVGrg
	 Yly2OKK2fLywvd8bbIVnbDViFGj7KJnkWz8NzONNQ6BFK5BFssWElnZl3iSDOpHHru
	 0G2wbfDHwR1sQ==
Date: Thu, 2 Jan 2025 11:34:04 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
cc: xen-devel@lists.xenproject.org, 
    Stefano Stabellini <stefano.stabellini@amd.com>, 
    Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, 
    Bertrand Marquis <bertrand.marquis@arm.com>, 
    Michal Orzel <michal.orzel@amd.com>, 
    Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>, 
    Andrew Cooper <andrew.cooper3@citrix.com>, 
    Anthony PERARD <anthony.perard@vates.tech>, 
    Jan Beulich <jbeulich@suse.com>, 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
    Tamas K Lengyel <tamas@tklengyel.com>, 
    Alexandru Isaila <aisaila@bitdefender.com>, 
    Petre Pircalabu <ppircalabu@bitdefender.com>
Subject: Re: [XEN PATCH v1] xen: mem_access: conditionally compile vm_event.c
 & monitor.c
In-Reply-To: <20241230063051.3332332-1-Sergiy_Kibrik@epam.com>
Message-ID: <alpine.DEB.2.22.394.2501021133050.16425@ubuntu-linux-20-04-desktop>
References: <20241230063051.3332332-1-Sergiy_Kibrik@epam.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 30 Dec 2024, Sergiy Kibrik wrote:
> From: Stefano Stabellini <stefano.stabellini@amd.com>
> 
> Extend coverage of CONFIG_MEM_ACCESS option and make the build of VM events
> and monitoring support optional.
> This is to reduce code size on Arm when this option isn't enabled.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
> Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>

I would add my reviewed-by but I wrote an early draft of this patch...

That said, it looks OK to me.

> ---
>  xen/arch/arm/Makefile      |  4 ++--
>  xen/arch/arm/vsmc.c        |  3 ++-
>  xen/common/Makefile        |  4 ++--
>  xen/include/xen/monitor.h  |  9 +++++++++
>  xen/include/xen/vm_event.h | 14 +++++++++++---
>  5 files changed, 26 insertions(+), 8 deletions(-)
> 
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index 43ab5e8f25..8903eb0bf2 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -39,7 +39,7 @@ obj-$(CONFIG_LIVEPATCH) += livepatch.o
>  obj-$(CONFIG_LLC_COLORING) += llc-coloring.o
>  obj-$(CONFIG_MEM_ACCESS) += mem_access.o
>  obj-y += mm.o
> -obj-y += monitor.o
> +obj-$(CONFIG_MEM_ACCESS) += monitor.o
>  obj-y += p2m.o
>  obj-y += platform.o
>  obj-y += platform_hypercall.o
> @@ -65,7 +65,7 @@ obj-$(CONFIG_VGICV2) += vgic-v2.o
>  obj-$(CONFIG_GICV3) += vgic-v3.o
>  obj-$(CONFIG_HAS_ITS) += vgic-v3-its.o
>  endif
> -obj-y += vm_event.o
> +obj-$(CONFIG_MEM_ACCESS) += vm_event.o
>  obj-y += vtimer.o
>  obj-$(CONFIG_SBSA_VUART_CONSOLE) += vpl011.o
>  obj-y += vsmc.o
> diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
> index 62d8117a12..1c13326bdf 100644
> --- a/xen/arch/arm/vsmc.c
> +++ b/xen/arch/arm/vsmc.c
> @@ -330,7 +330,8 @@ void do_trap_smc(struct cpu_user_regs *regs, const union hsr hsr)
>      }
>  
>      /* If monitor is enabled, let it handle the call. */
> -    if ( current->domain->arch.monitor.privileged_call_enabled )
> +    if ( IS_ENABLED(CONFIG_MEM_ACCESS) &&
> +         current->domain->arch.monitor.privileged_call_enabled )
>          rc = monitor_smc();
>  
>      if ( rc == 1 )
> diff --git a/xen/common/Makefile b/xen/common/Makefile
> index cba3b32733..e3c6a857ab 100644
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -54,7 +54,7 @@ obj-y += timer.o
>  obj-$(CONFIG_TRACEBUFFER) += trace.o
>  obj-y += version.o
>  obj-y += virtual_region.o
> -obj-y += vm_event.o
> +obj-$(CONFIG_MEM_ACCESS) += vm_event.o
>  obj-$(CONFIG_HAS_VMAP) += vmap.o
>  obj-y += vsprintf.o
>  obj-y += wait.o
> @@ -68,7 +68,7 @@ obj-$(CONFIG_COMPAT) += $(addprefix compat/,domain.o memory.o multicall.o xlat.o
>  
>  ifneq ($(CONFIG_PV_SHIM_EXCLUSIVE),y)
>  obj-y += domctl.o
> -obj-y += monitor.o
> +obj-$(CONFIG_MEM_ACCESS) += monitor.o
>  obj-y += sysctl.o
>  endif
>  
> diff --git a/xen/include/xen/monitor.h b/xen/include/xen/monitor.h
> index 713d54f7c1..f1359abb94 100644
> --- a/xen/include/xen/monitor.h
> +++ b/xen/include/xen/monitor.h
> @@ -27,8 +27,17 @@
>  struct domain;
>  struct xen_domctl_monitor_op;
>  
> +#ifdef CONFIG_MEM_ACCESS
>  int monitor_domctl(struct domain *d, struct xen_domctl_monitor_op *mop);
>  void monitor_guest_request(void);
> +#else
> +static inline int monitor_domctl(struct domain *d,
> +                                 struct xen_domctl_monitor_op *mop)
> +{
> +    return -EINVAL;
> +}
> +static inline void monitor_guest_request(void) {}
> +#endif
>  
>  int monitor_traps(struct vcpu *v, bool sync, vm_event_request_t *req);
>  
> diff --git a/xen/include/xen/vm_event.h b/xen/include/xen/vm_event.h
> index 9a86358b42..72e720e378 100644
> --- a/xen/include/xen/vm_event.h
> +++ b/xen/include/xen/vm_event.h
> @@ -50,9 +50,6 @@ struct vm_event_domain
>      unsigned int last_vcpu_wake_up;
>  };
>  
> -/* Clean up on domain destruction */
> -void vm_event_cleanup(struct domain *d);
> -
>  /* Returns whether a ring has been set up */
>  bool vm_event_check_ring(struct vm_event_domain *ved);
>  
> @@ -88,7 +85,18 @@ void vm_event_cancel_slot(struct domain *d, struct vm_event_domain *ved);
>  void vm_event_put_request(struct domain *d, struct vm_event_domain *ved,
>                            vm_event_request_t *req);
>  
> +#ifdef CONFIG_MEM_ACCESS
> +/* Clean up on domain destruction */
> +void vm_event_cleanup(struct domain *d);
>  int vm_event_domctl(struct domain *d, struct xen_domctl_vm_event_op *vec);
> +#else
> +static inline void vm_event_cleanup(struct domain *d) {}
> +static inline int vm_event_domctl(struct domain *d,
> +                                  struct xen_domctl_vm_event_op *vec)
> +{
> +    return -EINVAL;
> +}
> +#endif
>  
>  void vm_event_vcpu_pause(struct vcpu *v);
>  void vm_event_vcpu_unpause(struct vcpu *v);
> -- 
> 2.25.1
> 


From xen-devel-bounces@lists.xenproject.org Thu Jan 02 19:37:05 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 19:37:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864486.1275712 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTR0C-0008BJ-7B; Thu, 02 Jan 2025 19:37:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864486.1275712; Thu, 02 Jan 2025 19:37:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTR0C-0008BC-4g; Thu, 02 Jan 2025 19:37:04 +0000
Received: by outflank-mailman (input) for mailman id 864486;
 Thu, 02 Jan 2025 19:37:03 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=AqxF=T2=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tTR0B-0008B4-51
 for xen-devel@lists.xenproject.org; Thu, 02 Jan 2025 19:37:03 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org
 [2604:1380:45d1:ec00::3])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id efaacd54-c940-11ef-a0dc-8be0dac302b0;
 Thu, 02 Jan 2025 20:37:02 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id EF050A411CE;
 Thu,  2 Jan 2025 19:35:10 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 450FBC4CED6;
 Thu,  2 Jan 2025 19:36:57 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: efaacd54-c940-11ef-a0dc-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1735846620;
	bh=yoJEu+fgU8+FCvlj6nDDstyl/wVqK7ew3HsdnhojhNU=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=AuoHrFZsi+AFPcJ4u2DVKWyFidfqc3JnhPkBm3UQE2zHdUkGC3B/IOVp+YnnESjmU
	 ZLhZRZcYyv4Jp+az0hyP8k9UHCxuLLhITX4jhUAX5xZG7s/YuKXpFVtUDd1qAQ31xM
	 4q8QKnHxX/2CPrQ44MjpYhuiOr9q9t0vV6ZPnPaAoahl30Qo0WYl91Id/KkSYI43DV
	 7qNGa2fN+Qc2A6lQ/9F5bsz1nORgHhwEtpdmqv6+GQxv/nxzP3IURG04zLCRh3D2A/
	 PkybrQPLxXd71k/shQBCvOXscTsMHS0/H0h+Hi5MQEevszi0XNpCtQtRKkvXdzlG4a
	 7hZACeiRSxEAA==
Date: Thu, 2 Jan 2025 11:36:55 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
cc: xen-devel@lists.xenproject.org, Jan Beulich <jbeulich@suse.com>, 
    Andrew Cooper <andrew.cooper3@citrix.com>, 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
    Anthony PERARD <anthony.perard@vates.tech>, 
    Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>, 
    Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [XEN PATCH v1] ioreq: allow arch_vcpu_ioreq_completion() to
 signal an error
In-Reply-To: <20241220093514.3094521-1-Sergiy_Kibrik@epam.com>
Message-ID: <alpine.DEB.2.22.394.2501021136490.16425@ubuntu-linux-20-04-desktop>
References: <20241220093514.3094521-1-Sergiy_Kibrik@epam.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 20 Dec 2024, Sergiy Kibrik wrote:
> Return false from arch_vcpu_ioreq_completion() when completion is not handled.
> According to coding-best-practices.pandoc an error should be propagated to
> caller, if caller is expecting to handle it, which seems to the case for
> callers of arch_vcpu_ioreq_completion().
> 
> Suggested-by: Jan Beulich <jbeulich@suse.com>
> Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
> This change has been suggested by Jan some time ago during review of another
> series, here's link to discussion:
> https://lore.kernel.org/xen-devel/952701cd-83d8-4c1f-9f38-ee63ba582d66@suse.com/
> ---
>  xen/arch/x86/hvm/ioreq.c | 2 +-
>  xen/include/xen/ioreq.h  | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
> index 5c3d0c69aa..9b1592d505 100644
> --- a/xen/arch/x86/hvm/ioreq.c
> +++ b/xen/arch/x86/hvm/ioreq.c
> @@ -47,7 +47,7 @@ bool arch_vcpu_ioreq_completion(enum vio_completion completion)
>  
>      default:
>          ASSERT_UNREACHABLE();
> -        break;
> +        return false;
>      }
>  
>      return true;
> diff --git a/xen/include/xen/ioreq.h b/xen/include/xen/ioreq.h
> index 29a17e8ff5..2583eca0d5 100644
> --- a/xen/include/xen/ioreq.h
> +++ b/xen/include/xen/ioreq.h
> @@ -118,7 +118,7 @@ bool arch_vcpu_ioreq_completion(enum vio_completion completion);
>  static inline bool arch_vcpu_ioreq_completion(enum vio_completion completion)
>  {
>      ASSERT_UNREACHABLE();
> -    return true;
> +    return false;
>  }
>  #endif
>  
> -- 
> 2.25.1
> 


From xen-devel-bounces@lists.xenproject.org Thu Jan 02 19:39:26 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 19:39:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864493.1275723 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTR2S-0000gp-Iw; Thu, 02 Jan 2025 19:39:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864493.1275723; Thu, 02 Jan 2025 19:39:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTR2S-0000gi-Ft; Thu, 02 Jan 2025 19:39:24 +0000
Received: by outflank-mailman (input) for mailman id 864493;
 Thu, 02 Jan 2025 19:39:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=4GO/=T2=invisiblethingslab.com=marmarek@srs-se1.protection.inumbo.net>)
 id 1tTR2R-0000gG-4V
 for xen-devel@lists.xenproject.org; Thu, 02 Jan 2025 19:39:23 +0000
Received: from fout-a8-smtp.messagingengine.com
 (fout-a8-smtp.messagingengine.com [103.168.172.151])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 42c0fda3-c941-11ef-99a4-01e77a169b0f;
 Thu, 02 Jan 2025 20:39:21 +0100 (CET)
Received: from phl-compute-03.internal (phl-compute-03.phl.internal
 [10.202.2.43])
 by mailfout.phl.internal (Postfix) with ESMTP id C2795138025C;
 Thu,  2 Jan 2025 14:39:19 -0500 (EST)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-03.internal (MEProxy); Thu, 02 Jan 2025 14:39:19 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 2 Jan 2025 14:39:18 -0500 (EST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 42c0fda3-c941-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm2; t=1735846759;
	 x=1735933159; bh=AOJKkoWdqLRCfxD4AzfEHgkJlNyrpBNHvppGXkCF0gY=; b=
	jzIIzNeBd9bCxPcGju5Jy+XQf/3cHa6Uj23e6qiJoJDo7+MTT6z8P3IlvbFDamUe
	D97B5fbXdG9f7/aVyA7TbQiykVeZ6Hd2zL2HVXLO6jAMyLlVN5v4ANDybp13juQI
	uJtz15D98J2XkxMeJ+G09M/gs0/Udv15h2yQHIOjvSe4mltvRsr5QbCAhjh0dqlg
	7mskOd1X6NnDCYv9Sfn21ZEOzOFlcWluMSWyGODtF2DpWlVkfGJtq+pmWGe4fwmM
	JdG4Mc/fmDcr8rlexePpKZPlU4Aw+i3DU5ji2qayUQfxEAi43HRlKLP0VRBI31jK
	mDzCubE3m4XGSmBM/bS8Ug==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:subject:subject:to
	:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=
	1735846759; x=1735933159; bh=AOJKkoWdqLRCfxD4AzfEHgkJlNyrpBNHvpp
	GXkCF0gY=; b=l0TXYLb/9OzXd2FhMHBfuTGAPc0Rym9g3qdxsj4EyaSndUwWGkH
	sjNNrigACsbumH2jIlGxz3ZdwWRVBZS3vxefS2qYABIl32U2CE8Azy82V/0mUNwB
	jcjPao2c3VlK5lwJzHDVBChJ5mW/a1oWJ0OI9GwXRQVgR8OQXFZt6TQfk302YB35
	fT+sLrFjrFLJqvZN6OnGWiHpoVq56IoJmQF5pmHFH/umK6UnaUyHqAdZCzfAmtl1
	PxmneV1kvaOeiQq2IrS7VxzZjuj5LtcltPcg74EcphpXb2hRDn2lPqyUtxE0LiPx
	giddIWI4oiR5s9AwWh8/PvLlzSKxGqP21wg==
X-ME-Sender: <xms:Z-t2Z1hjVsy1MyCBUrBIkmSQYPkTJJTF0AI0m-jivTou8nfKN7SNUw>
    <xme:Z-t2Z6B4H8sS1ZBqPeyC3BV3w-ZlXb8D8_gCppgnqWAjJyEpKpEifM9zdsdPnjP7r
    ouV_ggfhiBwng>
X-ME-Received: <xmr:Z-t2Z1F0pq3JSrm43yt5tu-H2lAoJMjLHOhXlRJvTKMkMTrBanozLqyZkneSnhbUYUPdVu77_VsGjWJZFa-mVztJuGaiyYQBSw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrudefvddguddvkecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp
    uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvf
    evuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepofgrrhgvkhcuofgrrhgtiiih
    khhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvihhsihgslhgvth
    hhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepjeejgfekudegheeivdei
    ffdvffegteektdfhudeljeeikefhteefkeefgffgieegnecuffhomhgrihhnpehquhgsvg
    hsqdhoshdrohhrghdpghhithhhuhgsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptden
    ucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehinhhvihhsihgslhgvth
    hhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohepvddpmhhouggvpehsmhhtphho
    uhhtpdhrtghpthhtohepjhhgrhhoshhssehsuhhsvgdrtghomhdprhgtphhtthhopeigvg
    hnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrgh
X-ME-Proxy: <xmx:Z-t2Z6S47zk6ntDpRQNVcQ3Af0tbi1q83fEnbgYqUdAP42-6Pw9A4g>
    <xmx:Z-t2Zyy6aLahAk0gA4k1ogNxQPdiFqO7qSLO1NARH6Me4uMjR4MM3w>
    <xmx:Z-t2Zw5pUQsxENhM9Vkt3PvdKh10Q7oKYRy6TB3MXPVWyn65he_hAA>
    <xmx:Z-t2Z3zgkWUyb5k66RaUPWcfyeRPGjWf9nnN-Cb28d8KpIdis_xg4g>
    <xmx:Z-t2Z99gSIgj2dLwBJqPT7uBRsSTYmRX70QWDPZkJoOu_S2LR8EPsEJP>
Feedback-ID: i1568416f:Fastmail
Date: Thu, 2 Jan 2025 20:39:16 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: Linux 6.13-rc3 many different panics in Xen PV dom0
Message-ID: <Z3brZQmYhx-QTnga@mail-itl>
References: <Z2RGfpJkO0z_nKV6@mail-itl>
 <ab9c27d5-f3f2-4b8a-960d-f880ec136199@suse.com>
 <6bb03333-74ca-4c2c-85a8-72549b85a5b4@suse.com>
 <Z3aFdrygLF9yK2EK@mail-itl>
 <Z3bg-gvaBEdSIuRW@mail-itl>
 <08f9604b-df23-4766-a290-ef9daa506f8d@suse.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="Y+Pros9Mh0d2c3u3"
Content-Disposition: inline
In-Reply-To: <08f9604b-df23-4766-a290-ef9daa506f8d@suse.com>


--Y+Pros9Mh0d2c3u3
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Thu, 2 Jan 2025 20:39:16 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: Linux 6.13-rc3 many different panics in Xen PV dom0

On Thu, Jan 02, 2025 at 08:17:00PM +0100, J=C3=BCrgen Gro=C3=9F wrote:
> On 02.01.25 19:54, Marek Marczykowski-G=C3=B3recki wrote:
> > On Thu, Jan 02, 2025 at 01:24:21PM +0100, Marek Marczykowski-G=C3=B3rec=
ki wrote:
> > > On Thu, Jan 02, 2025 at 12:30:10PM +0100, Juergen Gross wrote:
> > > > On 02.01.25 11:20, J=C3=BCrgen Gro=C3=9F wrote:
> > > > > On 19.12.24 17:14, Marek Marczykowski-G=C3=B3recki wrote:
> > > > > > Hi,
> > > > > >=20
> > > > > > It crashes on boot like below, most of the times. But sometimes=
 (rarely)
> > > > > > it manages to stay alive. Below I'm pasting few of the crashes =
that look
> > > > > > distinctly different, if you follow the links, you can find mor=
e of
> > > > > > them. IMHO it looks like some memory corruption bug somewhere. =
I tested
> > > > > > also Linux 6.13-rc2 before, and it had very similar issue.
> > > > >=20
> > > > > ...
> > > > >=20
> > > > > >=20
> > > > > > Full log:
> > > > > > https://openqa.qubes-os.org/tests/122879/logfile?filename=3Dser=
ial0.txt
> > > > >=20
> > > > > I can reproduce a crash with 6.13-rc5 PV dom0.
> > > > >=20
> > > > > What is really interesting in the logs: most crashes seem to happ=
en right
> > > > > after a module being loaded (in my reproducer it was right after =
loading
> > > > > the first module).
> > > > >=20
> > > > > I need to go through the 6.13 commits, but I think I remember hav=
ing seen
> > > > > a patch optimizing module loading by using large pages for addres=
sing the
> > > > > loaded modules. Maybe the case of no large pages being available =
isn't
> > > > > handled properly.
> > > >=20
> > > > Seems I was right.
> > > >=20
> > > > For me the following diff fixes the issue. Marek, can you please co=
nfirm
> > > > it fixes your crashes, too?
> > >=20
> > > Thanks for looking into it!
> > > Will do, I've pushed it to
> > > https://github.com/QubesOS/qubes-linux-kernel/pull/662, CI will build=
 it
> > > and then I'll post it to openQA.
> >=20
> > It is much better!
> >=20
> > Tests are still running, but I already see that many are green.
>=20
> So are you fine with me adding your "Tested-by:"?

Yes.

> > There is
> > one issue (likely unrelated to this change) - sys-usb (HVM domU with USB
> > controllers passed through) crashes on a system with Raptor Lake CPU
> > (only, others, including ADL and MTL look fine):
> >=20
> > [   75.770849] Bluetooth: Core ver 2.22
> > [   75.770866] Oops: general protection fault, probably for non-canonic=
al address 0xc9d2315bc82c3bbd: 0000 [#1] PREEMPT SMP NOPTI
> > [   75.770880] CPU: 0 UID: 0 PID: 923 Comm: (udev-worker) Not tainted 6=
=2E13.0-0.rc5.2.qubes.1.fc41.x86_64 #1
> > [   75.770890] Hardware name: Xen HVM domU, BIOS 4.19.0 01/02/2025
> > [   75.770897] RIP: 0010:msft_monitor_device_del+0x93/0x170 [bluetooth]
> > [   75.770924] Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00=
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0 65 21=
 <26> 2b 8b ad 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>=20
> This code is looking suspicious. Large areas of binary 0 in a normal func=
tion?
> And the code itself is nonsense, as it is using a memory access via ES:, =
which
> doesn't make any sense in 64-bit kernel.

Could it be still something related to modules layout in memory?
It seems it's not 100% reliable crash, I see in at least one instance
sys-usb remained running (unfortunately I don't have collected full
sys-usb console log from successful test...).

I just checked again that this crash didn't happen with any 6.12 or 6.11
kernels.

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

--Y+Pros9Mh0d2c3u3
Content-Type: application/pgp-signature; name="signature.asc"

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmd262QACgkQ24/THMrX
1yx0NQf+LajgMA2io7pgUJDZmPQOSOoVUHUFuATAfRxIEH9QeRXe6LvOAOotInFb
rUuo9RM5S8GNfPhArFr7Penz3J8V+u4t/xz2NheCGhaZFSENkOi6fiW83BVLmmGu
oR+c0homnK9dqV9FaqNLPjSiM7Ej7NcKuzVtceSPAuRihhq+OnNxKI0Bue0DXIP7
1vTK8Uj08KFfdJMJ2rGCr2aGFRbYe0BchRSRVH7zX6Op4SInYYUBE5vxQ5ViktHI
UEfQ3Z1eiBJAObp67ewWk4KbrMmXktJazdtiX2bw25MeN1LhLabVGobYknlkSqvi
3ng6g6tlWeIGvnGiEsa4N2zaYqwFMg==
=Pnj/
-----END PGP SIGNATURE-----

--Y+Pros9Mh0d2c3u3--


From xen-devel-bounces@lists.xenproject.org Thu Jan 02 19:55:23 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Jan 2025 19:55:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864502.1275732 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTRHp-0004XW-QD; Thu, 02 Jan 2025 19:55:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864502.1275732; Thu, 02 Jan 2025 19:55:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTRHp-0004XP-Nl; Thu, 02 Jan 2025 19:55:17 +0000
Received: by outflank-mailman (input) for mailman id 864502;
 Thu, 02 Jan 2025 19:55:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=xoa/=T2=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tTRHo-0004XJ-My
 for xen-devel@lists.xenproject.org; Thu, 02 Jan 2025 19:55:16 +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 7bfeb9d1-c943-11ef-a0dc-8be0dac302b0;
 Thu, 02 Jan 2025 20:55:15 +0100 (CET)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-4361b6f9faeso70825855e9.1
 for <xen-devel@lists.xenproject.org>; Thu, 02 Jan 2025 11:55:15 -0800 (PST)
Received: from andrewcoop.lan ([83.105.36.37])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-43661218f43sm464573605e9.19.2025.01.02.11.55.13
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 02 Jan 2025 11:55:13 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 7bfeb9d1-c943-11ef-a0dc-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1735847714; x=1736452514; 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=c5n8WWdcErArPqimG8AinQbYQjSFsYmY7A9DbyTjRXI=;
        b=OEo5c32YEwIfbOexo+d5gAZlkjw99sjNw0yWX/83b2qojulpzJuD2cW0Zrxc3DJ+FP
         bCl8IDvuLouE+ZrOb5Zrg7wpIPmORhrgnHfZ7xMEY6DI7+3KSnLAVRdPvuR16fj0HaOA
         CGqraygo6Y1A62h0mLM091DttOYWoUkWdOsp8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735847714; x=1736452514;
        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=c5n8WWdcErArPqimG8AinQbYQjSFsYmY7A9DbyTjRXI=;
        b=YHDYUNJ+IIOnHKcqODUU09iQBYhdo6A7CCLkMB/gooPaIIZUQONGPFd4YzXt0H6ADx
         LLdj4bVGw9z5jssWfCJ1rPYdKs9Ut6XAdiDv0J+3bnJRMgNH8uCYu5+WhGgDduIiKEZW
         Wn2rWLSmQMjYG1SldA7FjiHCgVFoo6zwYTEdLigRQZ3uIQ/0s/rI+9oYKH/gnSUdIo7g
         uDOtIzNsf2g4uLm6JiDxFOS6WGI+mUZl4mMpPHNHGQe5mVSJeWUJ8cXc5zNtIwGni/zv
         LnDQO36h7DcH63erB24Sa0q6l5Ni2FlWAv/K+ub1IQ19RWvERzM7/OiVbCYVhqsJtqHZ
         JkVg==
X-Gm-Message-State: AOJu0Yxxae7GHJvLv9lggKI6fDXfAaSzo/CWoFGths6QXGPFP+13+ZYF
	AxHg92nmTl196QosbPN6sBgaLRVIIYyL6las4X3YHp8VLCqiS2mHt+YSiQEy9YCV7lun7iG5aYM
	cSvqLGQ==
X-Gm-Gg: ASbGncsiVcLtgrAQXE5dFkQDDTxcBGfAWSFYyxa4v5Ssp+IqfqY2gcaoZh5k7nVcdQX
	yEArbG8NkOnxnmWzNW6pJMoOw37cVpKRqt+YV5lZSd0xHr6J7GxYYPdTixqOjpqBhEQDxwTAIod
	Fhk3f2IPOtarA7MDfZ5tlIxcoWFDtyuORtNMHZpuxPq7Mg3zUwVYqY38VoLd9l+9T0pqd6Q01WQ
	wb0T3Ya+24c7EKpb19vr7IzCZRFXvTm7qsXD4EtIxjUjf/DkywdeajFAVjnEFG7kg==
X-Google-Smtp-Source: AGHT+IGr9aynI0zhfp6KT+M7K4PloFwF5SoM95V/wrrXsOI2+JT1UJZiJWIn9qDjYAkJtiCxRMj3Ew==
X-Received: by 2002:a05:600c:6d3:b0:436:199e:8458 with SMTP id 5b1f17b1804b1-4365c79ad57mr418822375e9.14.1735847714411;
        Thu, 02 Jan 2025 11:55:14 -0800 (PST)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PATCH 6/4] x86/pv: Fix build with Clang and CONFIG_PERF_COUNTERS
Date: Thu,  2 Jan 2025 19:55:12 +0000
Message-Id: <20250102195512.2406928-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250102192508.2405687-1-andrew.cooper3@citrix.com>
References: <20250102192508.2405687-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Clang, of at least verion 17 complains:

  arch/x86/pv/hypercall.c:30:10: error: variable 'eax' is used uninitialized
  whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
     30 |     if ( !compat )
        |          ^~~~~~~
  arch/x86/pv/hypercall.c:87:29: note: uninitialized use occurs here
     87 |     perfc_incra(hypercalls, eax);
        |                             ^~~

This function is forced always_inline to cause compat to be
constant-propagated through, but that is only a heuristic to try and get the
compiler to do what we want, not a gurantee that it does.

Clang doesn't appear to be able to see that the only case where compat is
true (and therefore the if() is false) is when there's an else clause on the
end which sets eax too.

Initialise eax to -1, which ought to be optimised out, but if for whatever
reason it happens not to be, then perfc_incra() will fail it's bounds check
and do nothing.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/arch/x86/pv/hypercall.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/pv/hypercall.c b/xen/arch/x86/pv/hypercall.c
index 2febade44b73..17581d232e19 100644
--- a/xen/arch/x86/pv/hypercall.c
+++ b/xen/arch/x86/pv/hypercall.c
@@ -21,7 +21,7 @@ static void always_inline
 _pv_hypercall(struct cpu_user_regs *regs, bool compat)
 {
     struct vcpu *curr = current;
-    unsigned long eax;
+    unsigned long eax = -1; /* Clang -Wsometimes-uninitialized */
 
     ASSERT(guest_kernel_mode(curr, regs));
 

base-commit: a1746cd4434dd27ca2da8430dfb10edc76264bb3
prerequisite-patch-id: c0c647c3d465fc11e039b5de751da060f2599fff
prerequisite-patch-id: 675a622887bb1721684e574fc7755af79463f67b
prerequisite-patch-id: 4bc07a7aa6e0f769ed7c89dc56db25091d810760
prerequisite-patch-id: b23c07e16495387ee6cb70edcbcb13f6b42246ac
prerequisite-patch-id: fe09857284f3a17ff116de1f0a20d3916e8dda90
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Fri Jan 03 00:19:16 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Jan 2025 00:19:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864517.1275744 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTVP1-0001XK-5T; Fri, 03 Jan 2025 00:18:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864517.1275744; Fri, 03 Jan 2025 00:18:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTVP1-0001XD-1R; Fri, 03 Jan 2025 00:18:59 +0000
Received: by outflank-mailman (input) for mailman id 864517;
 Fri, 03 Jan 2025 00:18:57 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=LdeY=T3=invisiblethingslab.com=marmarek@srs-se1.protection.inumbo.net>)
 id 1tTVOz-0001X6-2f
 for xen-devel@lists.xenproject.org; Fri, 03 Jan 2025 00:18:57 +0000
Received: from fhigh-b7-smtp.messagingengine.com
 (fhigh-b7-smtp.messagingengine.com [202.12.124.158])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 504f3cbc-c968-11ef-a0dc-8be0dac302b0;
 Fri, 03 Jan 2025 01:18:54 +0100 (CET)
Received: from phl-compute-06.internal (phl-compute-06.phl.internal
 [10.202.2.46])
 by mailfhigh.stl.internal (Postfix) with ESMTP id A96B92540127;
 Thu,  2 Jan 2025 19:18:52 -0500 (EST)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-06.internal (MEProxy); Thu, 02 Jan 2025 19:18:52 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 2 Jan 2025 19:18:51 -0500 (EST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 504f3cbc-c968-11ef-a0dc-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm2; t=1735863532;
	 x=1735949932; bh=jQ+2lcS+cegYt/fHnf05rCvZ1YXLp0Bl8E1QQdiIZ9o=; b=
	Rnai7dOclW8cWynmVnRgXRoqIBSswvBOSLwdASZBiexWuNUjMpWmGR4vMCp53ow4
	nN9fuXu9w7F4PKdvlIqKsP9HSknx2m6H+ushUWbqroE1bUhEA6ST9Wi0KXsVMPok
	fk2yhuJQr0b3UWP7qTE4M285fXbygs7BP0HBkbfNyEdtljobFWmeHoFakK8E4SvZ
	bSAqKyijP7O8HCEHcTzY8PSH4LDpRg/oqtSakkvJJ+fIbr2KmXg+q1hdE7DqziLC
	V3biEOYcgjK5jk7bmyBlQMRQmgY587ah1vwnPjEXhSj/5JAdRhVeH7mEvVN9IKtZ
	J2NMN9hNRX93SgnKgJ6pWg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:subject:subject:to
	:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=
	1735863532; x=1735949932; bh=jQ+2lcS+cegYt/fHnf05rCvZ1YXLp0Bl8E1
	QQdiIZ9o=; b=kpvaoR4jWTfoVwxPU2Ct9sPMa+h7omRBq9gbFSuReoXx3VHqKUa
	03FzY+WzkYZvcI3ORos80M0vF8pJU76jWcBufeC2C0lMqol4eQ6zO611ajq4Ih8S
	oYkSdqoILo1im5ECvndz+1w2nHc4CuhS78or0ZYxcpgWyVMqH7T9Cn/0XDlhM/pf
	4iGc3LN1CC1q5yP2hhT4T+XIRGJJntdMM7sd4VWOhyRM8UntnWuViR3A0qY2t1Jg
	ZIIusC0t5QMpPvkqOCjF1GGGuzp+RXkLv7++L/qj4qUjUEndlhCPS/HStxVn+Kx7
	TKW3JFJwGoZKvF7QKEub3YFRBAaau6hE5xQ==
X-ME-Sender: <xms:7Cx3Z6gAmSHYimSKMj3mCdOdC4yNg5nP1YS1SH_kXJF2nHgmQa-FkA>
    <xme:7Cx3Z7BTklc6tv3KhWXf7_hjijIX5b5RLK-3xtcpnlUe3egq7bTQ1Onj1qD1Q8qFT
    ehjzpccfE_YAg>
X-ME-Received: <xmr:7Cx3ZyEaHn7ZtGoFo8wtl2EJCAeXabQlLj7z2OWGr0yaWvROENlxy_c>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrudeffedgvdduucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
    rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
    htshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtjeen
    ucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomh
    grrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggft
    rfgrthhtvghrnhepjeejgfekudegheeivdeiffdvffegteektdfhudeljeeikefhteefke
    efgffgieegnecuffhomhgrihhnpehquhgsvghsqdhoshdrohhrghdpghhithhhuhgsrdgt
    ohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmh
    grrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnhgspghr
    tghpthhtohepfedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepjhhgrhhoshhsse
    hsuhhsvgdrtghomhdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghn
    phhrohhjvggtthdrohhrghdprhgtphhtthhopegrnhgurhgvfidrtghoohhpvghrfeestg
    hithhrihigrdgtohhm
X-ME-Proxy: <xmx:7Cx3ZzQymrci3Er0owFL0EMt6A95NHUF6GJtVDw3JEtIW-JhsxBd4w>
    <xmx:7Cx3Z3zc9VHzuNBawe94Xpy2TouycD1lrz1BOpWTIeEpQPn9c-_TFA>
    <xmx:7Cx3Zx7l_BQBH-H67LYUepsV7poIdK8UWoBHAwV6Dlt7HNrqnN0ngA>
    <xmx:7Cx3Z0wTzNNiRdmhRBOARbTQaaRUOkeNg2Nt7AA69XP5QGa1AkjDLQ>
    <xmx:7Cx3Z3-Q5WsBusL4ZjUL-cYgyhkY80YadhRySJVHKOnp9pcuMlXLpYEv>
Feedback-ID: i1568416f:Fastmail
Date: Fri, 3 Jan 2025 01:18:31 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: Linux 6.13-rc3 many different panics in Xen PV dom0
Message-ID: <Z3cs1-wG5WJ9FrAR@mail-itl>
References: <Z2RGfpJkO0z_nKV6@mail-itl>
 <ab9c27d5-f3f2-4b8a-960d-f880ec136199@suse.com>
 <6bb03333-74ca-4c2c-85a8-72549b85a5b4@suse.com>
 <Z3aFdrygLF9yK2EK@mail-itl>
 <Z3bg-gvaBEdSIuRW@mail-itl>
 <08f9604b-df23-4766-a290-ef9daa506f8d@suse.com>
 <Z3brZQmYhx-QTnga@mail-itl>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="ohVQ3jw0K38kRcl+"
Content-Disposition: inline
In-Reply-To: <Z3brZQmYhx-QTnga@mail-itl>


--ohVQ3jw0K38kRcl+
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Fri, 3 Jan 2025 01:18:31 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: Linux 6.13-rc3 many different panics in Xen PV dom0

On Thu, Jan 02, 2025 at 08:39:16PM +0100, Marek Marczykowski-G=C3=B3recki w=
rote:
> On Thu, Jan 02, 2025 at 08:17:00PM +0100, J=C3=BCrgen Gro=C3=9F wrote:
> > On 02.01.25 19:54, Marek Marczykowski-G=C3=B3recki wrote:
> > > On Thu, Jan 02, 2025 at 01:24:21PM +0100, Marek Marczykowski-G=C3=B3r=
ecki wrote:
> > > > On Thu, Jan 02, 2025 at 12:30:10PM +0100, Juergen Gross wrote:
> > > > > On 02.01.25 11:20, J=C3=BCrgen Gro=C3=9F wrote:
> > > > > > On 19.12.24 17:14, Marek Marczykowski-G=C3=B3recki wrote:
> > > > > > > Hi,
> > > > > > >=20
> > > > > > > It crashes on boot like below, most of the times. But sometim=
es (rarely)
> > > > > > > it manages to stay alive. Below I'm pasting few of the crashe=
s that look
> > > > > > > distinctly different, if you follow the links, you can find m=
ore of
> > > > > > > them. IMHO it looks like some memory corruption bug somewhere=
=2E I tested
> > > > > > > also Linux 6.13-rc2 before, and it had very similar issue.
> > > > > >=20
> > > > > > ...
> > > > > >=20
> > > > > > >=20
> > > > > > > Full log:
> > > > > > > https://openqa.qubes-os.org/tests/122879/logfile?filename=3Ds=
erial0.txt
> > > > > >=20
> > > > > > I can reproduce a crash with 6.13-rc5 PV dom0.
> > > > > >=20
> > > > > > What is really interesting in the logs: most crashes seem to ha=
ppen right
> > > > > > after a module being loaded (in my reproducer it was right afte=
r loading
> > > > > > the first module).
> > > > > >=20
> > > > > > I need to go through the 6.13 commits, but I think I remember h=
aving seen
> > > > > > a patch optimizing module loading by using large pages for addr=
essing the
> > > > > > loaded modules. Maybe the case of no large pages being availabl=
e isn't
> > > > > > handled properly.
> > > > >=20
> > > > > Seems I was right.
> > > > >=20
> > > > > For me the following diff fixes the issue. Marek, can you please =
confirm
> > > > > it fixes your crashes, too?
> > > >=20
> > > > Thanks for looking into it!
> > > > Will do, I've pushed it to
> > > > https://github.com/QubesOS/qubes-linux-kernel/pull/662, CI will bui=
ld it
> > > > and then I'll post it to openQA.
> > >=20
> > > It is much better!
> > >=20
> > > Tests are still running, but I already see that many are green.
> >=20
> > So are you fine with me adding your "Tested-by:"?
>=20
> Yes.
>=20
> > > There is
> > > one issue (likely unrelated to this change) - sys-usb (HVM domU with =
USB
> > > controllers passed through) crashes on a system with Raptor Lake CPU
> > > (only, others, including ADL and MTL look fine):

Correction, it does happen on some others too, just got the crash on the ADL
system, although looks a bit different ("Corrupted page table at ..."):

sys-usb login: [2025-01-02 23:44:58] [    7.295556] Bluetooth: hci0: Waitin=
g for firmware download to complete
[    7.296996] Bluetooth: hci0: Firmware loaded in 2882606 usecs
[    7.297276] Bluetooth: hci0: Waiting for device to boot
[    7.313074] Bluetooth: hci0: Device booted in 15473 usecs
[    7.318447] Bluetooth: hci0: Found Intel DDC parameters: intel/ibt-1040-=
0041.ddc
[    7.321060] Bluetooth: hci0: Applying Intel DDC parameters completed
[    7.322057] Bluetooth: hci0: No support for BT device in ACPI firmware
[    7.324037] Bluetooth: hci0: Firmware timestamp 2024.33 buildtype 1 buil=
d 81755
[    7.324085] Bluetooth: hci0: Firmware SHA1: 0xd028ffe4
[    7.327995] Bluetooth: hci0: Fseq status: Success (0x00)
[    7.328017] Bluetooth: hci0: Fseq executed: 00.00.02.41
[    7.328032] Bluetooth: hci0: Fseq BT Top: 00.00.02.41
[    7.396950] Bluetooth: MGMT ver 1.23
[    9.352650] kauditd_printk_skb: 82 callbacks suppressed
[    9.352655] audit: type=3D1131 audit(1735861500.506:81): pid=3D1 uid=3D0=
 auid=3D4294967295 ses=3D4294967295 subj=3Dsystem_u:system_r:init_t:s0 msg=
=3D'unit=3Dsystemd-rfkill comm=3D"systemd" exe=3D"/usr/lib/systemd/systemd"=
 hostname=3D? addr=3D? terminal=3D? res=3Dsuccess'
[   15.808157] audit: type=3D1100 audit(1735861506.961:82): pid=3D867 uid=
=3D0 auid=3D4294967295 ses=3D4294967295 subj=3Dsystem_u:system_r:xdm_t:s0-s=
0:c0.c1023 msg=3D'op=3DPAM:authentication grantors=3Dpam_rootok acct=3D"use=
r" exe=3D"/usr/bin/qubes-gui-runuser" hostname=3Dsys-usb addr=3D? terminal=
=3D/dev/tty7 res=3Dsuccess'
[   15.808860] audit: type=3D1100 audit(1735861506.962:83): pid=3D866 uid=
=3D0 auid=3D4294967295 ses=3D4294967295 subj=3Dsystem_u:system_r:local_logi=
n_t:s0-s0:c0.c1023 msg=3D'op=3DPAM:authentication grantors=3Dpam_rootok acc=
t=3D"user" exe=3D"/usr/lib/qubes/qrexec-agent" hostname=3D? addr=3D? termin=
al=3D? res=3Dsuccess'
[   15.814137] audit: type=3D1103 audit(1735861506.967:84): pid=3D867 uid=
=3D0 auid=3D4294967295 ses=3D4294967295 subj=3Dsystem_u:system_r:xdm_t:s0-s=
0:c0.c1023 msg=3D'op=3DPAM:setcred grantors=3Dpam_rootok acct=3D"user" exe=
=3D"/usr/bin/qubes-gui-runuser" hostname=3Dsys-usb addr=3D? terminal=3D/dev=
/tty7 res=3Dsuccess'
[   15.814816] audit: type=3D1006 audit(1735861506.968:85): pid=3D867 uid=
=3D0 subj=3Dsystem_u:system_r:xdm_t:s0-s0:c0.c1023 old-auid=3D4294967295 au=
id=3D1000 tty=3Dtty7 old-ses=3D4294967295 ses=3D1 res=3D1
[   15.815078] audit: type=3D1300 audit(1735861506.968:85): arch=3Dc000003e=
 syscall=3D1 success=3Dyes exit=3D4 a0=3D3 a1=3D7ffe29c03a70 a2=3D4 a3=3D0 =
items=3D0 ppid=3D712 pid=3D867 auid=3D1000 uid=3D0 gid=3D0 euid=3D0 suid=3D=
0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3Dtty7 ses=3D1 comm=3D"qubes-gu=
i-runus" exe=3D"/usr/bin/qubes-gui-runuser" subj=3Dsystem_u:system_r:xdm_t:=
s0-s0:c0.c1023 key=3D(null)
[   15.815164] audit: type=3D1327 audit(1735861506.968:85): proctitle=3D2F7=
573722F62696E2F71756265732D6775692D72756E757365720075736572002F62696E2F7368=
002D6C002D630065786563202F7573722F62696E2F78696E6974202F6574632F5831312F786=
96E69742F78696E69747263202D2D202F7573722F6C69622F71756265732F71756265732D78=
6F72672D77726170706572203A30
[   15.815420] audit: type=3D1103 audit(1735861506.969:86): pid=3D866 uid=
=3D0 auid=3D4294967295 ses=3D4294967295 subj=3Dsystem_u:system_r:local_logi=
n_t:s0-s0:c0.c1023 msg=3D'op=3DPAM:setcred grantors=3Dpam_rootok acct=3D"us=
er" exe=3D"/usr/lib/qubes/qrexec-agent" hostname=3D? addr=3D? terminal=3D? =
res=3Dsuccess'
[   15.816039] audit: type=3D1006 audit(1735861506.969:87): pid=3D866 uid=
=3D0 subj=3Dsystem_u:system_r:local_login_t:s0-s0:c0.c1023 old-auid=3D42949=
67295 auid=3D1000 tty=3D(none) old-ses=3D4294967295 ses=3D2 res=3D1
[   15.817029] audit: type=3D1300 audit(1735861506.969:87): arch=3Dc000003e=
 syscall=3D1 success=3Dyes exit=3D4 a0=3D3 a1=3D7ffe550c1c30 a2=3D4 a3=3D0 =
items=3D0 ppid=3D864 pid=3D866 auid=3D1000 uid=3D0 gid=3D0 euid=3D0 suid=3D=
0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D2 comm=3D"qrexec=
-agent" exe=3D"/usr/lib/qubes/qrexec-agent" subj=3Dsystem_u:system_r:local_=
login_t:s0-s0:c0.c1023 key=3D(null)
[   15.817160] audit: type=3D1327 audit(1735861506.969:87): proctitle=3D"/u=
sr/lib/qubes/qrexec-agent"
[   16.111133] systemd-journald[366]: Time jumped backwards, rotating.
th: RFCOMM TTY layer initialized
[   18.286026] Bluetooth: RFCOMM socket layer initialized
[   18.286035] Bluetooth: RFCOMM ver 1.11
[   18.469074] abrt-dump-journ: Corrupted page table at address 78c64b600010
[   18.469096] PGD 14980067 P4D 14980067 PUD 14981067 PMD 38c8047 PTE 243c8=
b48ffffff57
[   18.469117] Oops: Bad pagetable: 000d [#1] PREEMPT SMP NOPTI
[   18.469132] CPU: 1 UID: 0 PID: 657 Comm: abrt-dump-journ Not tainted 6.1=
3.0-0.rc5.2.qubes.1.fc41.x86_64 #1
[   18.469152] Hardware name: Xen HVM domU, BIOS 4.19.0 01/02/2025
[   18.469165] RIP: 0033:0x78c64e1bc9a0
[   18.469177] Code: 86 f5 01 00 00 49 8b 7c 24 38 48 85 ff 0f 84 08 03 00 =
00 48 8d 0d 40 e6 ff ff ba 18 00 00 00 e8 46 c7 fa ff e9 d1 01 00 00 90 <0f=
> b6 50 10 38 96 c8 01 00 00 0f 85 63 fd ff ff 80 fa 02 0f 84 4c
[   18.469211] RSP: 002b:00007ffcdc67a8b0 EFLAGS: 00010246
[   18.469223] RAX: 000078c64b600000 RBX: 00006045c444c890 RCX: 00000000000=
00048
[   18.469238] RDX: 0000000000000000 RSI: 00006045c444c890 RDI: 00006045c44=
4f040
[   18.469253] RBP: 00007ffcdc67a930 R08: 00006045c43a1010 R09: 00000000000=
00001
[   18.469268] R10: 00006045c44098b0 R11: 0000000000000246 R12: 00006045c44=
4f040
[   18.469284] R13: 00006045c4409890 R14: 00006045c444c890 R15: 00000000000=
00000
[   18.469299] FS:  000078c64d675400 GS:  0000000000000000
[   18.469310] Modules linked in: snd_seq_dummy snd_hrtimer snd_seq snd_seq=
_device snd_timer snd soundcore rfcomm bnep btusb btrtl btintel btbcm btmtk=
 bluetooth rfkill nft_reject_ipv6 nf_reject_ipv6 nft_reject_ipv4 nf_reject_=
ipv4 nft_reject nft_ct nft_masq nft_chain_nat nf_nat nf_conntrack nf_defrag=
_ipv6 nf_defrag_ipv4 joydev nf_tables intel_rapl_msr intel_rapl_common inte=
l_uncore_frequency_common intel_pmc_core intel_vsec pmt_telemetry pmt_class=
 crct10dif_pclmul crc32_pclmul crc32c_intel polyval_clmulni polyval_generic=
 ghash_clmulni_intel sha512_ssse3 sha256_ssse3 sha1_ssse3 xhci_pci ehci_pci=
 xhci_hcd ehci_hcd pcspkr i2c_piix4 i2c_smbus ata_generic pata_acpi serio_r=
aw xen_scsiback target_core_mod xen_netback xen_privcmd xen_gntdev xen_gnta=
lloc xen_blkback xen_evtchn loop fuse nfnetlink overlay xen_blkfront
[   18.469484] ---[ end trace 0000000000000000 ]---
[   18.469495] RIP: 0033:0x78c64e1bc9a0
[   18.469504] RSP: 002b:00007ffcdc67a8b0 EFLAGS: 00010246
[   18.469516] RAX: 000078c64b600000 RBX: 00006045c444c890 RCX: 00000000000=
00048
[   18.469531] RDX: 0000000000000000 RSI: 00006045c444c890 RDI: 00006045c44=
4f040
[   18.469547] RBP: 00007ffcdc67a930 R08: 00006045c43a1010 R09: 00000000000=
00001
[   18.469562] R10: 00006045c44098b0 R11: 0000000000000246 R12: 00006045c44=
4f040
[   18.469577] R13: 00006045c4409890 R14: 00006045c444c890 R15: 00000000000=
00000
[   18.469593] FS:  000078c64d675400(0000) GS:ffff9de397100000(0000) knlGS:=
0000000000000000
[   18.469609] CS:  0033 DS: 0000 ES: 0000 CR0: 0000000080050033
[   18.469623] CR2: 000078c64b600010 CR3: 0000000000164004 CR4: 00000000007=
70ef0
[   18.469640] PKRU: 55555554
[   18.469646] Kernel panic - not syncing: Fatal exception
[   18.469706] Kernel Offset: 0x2ec00000 from 0xffffffff80200000 (relocatio=
n range: 0xffffffff80000000-0xffffffffbfffffff)


> > > [   75.770849] Bluetooth: Core ver 2.22
> > > [   75.770866] Oops: general protection fault, probably for non-canon=
ical address 0xc9d2315bc82c3bbd: 0000 [#1] PREEMPT SMP NOPTI
> > > [   75.770880] CPU: 0 UID: 0 PID: 923 Comm: (udev-worker) Not tainted=
 6.13.0-0.rc5.2.qubes.1.fc41.x86_64 #1
> > > [   75.770890] Hardware name: Xen HVM domU, BIOS 4.19.0 01/02/2025
> > > [   75.770897] RIP: 0010:msft_monitor_device_del+0x93/0x170 [bluetoot=
h]
> > > [   75.770924] Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0 65 =
21 <26> 2b 8b ad 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >=20
> > This code is looking suspicious. Large areas of binary 0 in a normal fu=
nction?
> > And the code itself is nonsense, as it is using a memory access via ES:=
, which
> > doesn't make any sense in 64-bit kernel.
>=20
> Could it be still something related to modules layout in memory?
> It seems it's not 100% reliable crash, I see in at least one instance
> sys-usb remained running (unfortunately I don't have collected full
> sys-usb console log from successful test...).
>=20
> I just checked again that this crash didn't happen with any 6.12 or 6.11
> kernels.
>=20
> --=20
> Best Regards,
> Marek Marczykowski-G=C3=B3recki
> Invisible Things Lab



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

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

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmd3LNcACgkQ24/THMrX
1yxjcwf/fRzQ8G7wDeafC62DK1dxDy7fqJnQQSDHrcAHfLamZlKhRiLHIHKUa5Qb
O5RbtFPEYe+ePqJerBZo1G68QzLr0VZ0P+o5MLD+bD8dkSdDHGc1g83YLG4P8qqF
ph710nW54m4GBoqYDId+BlJ2deoH6BYM1P5IxfHHFJk3UT4eHeS6HwJMJrW8YAlD
GRsFFsKpbhgwFQBQQYQiUes+Ah0+pDcdtB2LeqzxeWnNwbbq8VX8wh3zLJolz6Ra
kphj9HPmnSzRJDKtU/73QJ9g67JKSzl7b/i3spNmfD3PKwD7Vvw+dPtXCAge1aQK
PTLkVQLgh2o1kOP8x/qmxhSyxSNU/w==
=SVp+
-----END PGP SIGNATURE-----

--ohVQ3jw0K38kRcl+--


From xen-devel-bounces@lists.xenproject.org Fri Jan 03 00:43:01 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Jan 2025 00:43:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864525.1275754 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTVm9-0005Jg-VW; Fri, 03 Jan 2025 00:42:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864525.1275754; Fri, 03 Jan 2025 00:42:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTVm9-0005JZ-QZ; Fri, 03 Jan 2025 00:42:53 +0000
Received: by outflank-mailman (input) for mailman id 864525;
 Fri, 03 Jan 2025 00:42:52 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=LdeY=T3=invisiblethingslab.com=marmarek@srs-se1.protection.inumbo.net>)
 id 1tTVm8-0005JR-Mh
 for xen-devel@lists.xenproject.org; Fri, 03 Jan 2025 00:42:52 +0000
Received: from fout-b7-smtp.messagingengine.com
 (fout-b7-smtp.messagingengine.com [202.12.124.150])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a815de86-c96b-11ef-99a4-01e77a169b0f;
 Fri, 03 Jan 2025 01:42:50 +0100 (CET)
Received: from phl-compute-11.internal (phl-compute-11.phl.internal
 [10.202.2.51])
 by mailfout.stl.internal (Postfix) with ESMTP id 8DDF211401F2;
 Thu,  2 Jan 2025 19:42:48 -0500 (EST)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-11.internal (MEProxy); Thu, 02 Jan 2025 19:42:48 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 2 Jan 2025 19:42:47 -0500 (EST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a815de86-c96b-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm2; t=1735864968;
	 x=1735951368; bh=cK2Plcfq49ZpIYB8enI2B4pjJnZHgchMCUL51EwqCcc=; b=
	dX97Ezy4O6p8x5jtGgNz//gukK0dIryLWpw/0IdKeQOhE1wvfV1KTfLGKv4W0j0m
	ExxNOeeIJ4Z1IpB2mPOblZkl7RSdLHrkvJZxo0ZHhzz+eRtVmx9p+gI3eU9NrD9t
	iZkBSC7Zpy+9vyrBjsCOV0+UhQrJfrR8wijBmR97t/lVeBYQ92ncTqNOtiTcLL6J
	12Q9UZJQ99C8sNz+D1tgmvLwu71XOZI4mzlqgC4s5vyT8qbuKRois363JWqhvAUY
	BlU4Lk0WA9zssBrkws7eJUlwXU1kWpqS+xN91MCUofoeHKH5B6HXfrMVZcPu9N12
	TwGbJEcWPt6ZVOwa1FAyTw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:subject:subject:to
	:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=
	1735864968; x=1735951368; bh=cK2Plcfq49ZpIYB8enI2B4pjJnZHgchMCUL
	51EwqCcc=; b=Z5AXODBxLBIoiq85UpMmTbt9oyRewkTICL0hhTClW4AvmdtJrsz
	BMdHvnko2X2wnSpm14C91Er5pzznTIyud9G2mjkDzJUZG+rMfYozwBhqmFos5CoB
	IHwMKpttvpSEtfkq4BoyhVPpqZZ9J2J/ixjvK0JjYwbzx5urm+XCOcHQhjoac6CM
	z2a9hBArRzG7h5pB+8+SrVkaAKrJZ7hySzeRhzQ2O8pTb7yMMR1Yjq//N2H6V7/L
	bHEyjjZgKgVj09mJFwxbOHnHD4tHWWXOlVDWPEU4jorskg5Ob4dYUmpY4mgMFc3R
	VXwj5nLgbOCBg3RSr7R1yiLHyvuZr3OFy7Q==
X-ME-Sender: <xms:iDJ3Z1SKjEC8uivenJamJtwyfl93kPOtTucPpaaPqM4Bt-ncmF7Jmg>
    <xme:iDJ3Z-x5hGVFmTnIknLFg_WLJ2LGDA9Kfa3ng902DAjJAr_Nj5BaflR2Ohsjn3Z7Q
    kgvs8itq50PDg>
X-ME-Received: <xmr:iDJ3Z61J4kPLt1URZ493Y1ID8_kMn6F0u_4Hnnwjq1TfxNpt51RUvzuBGkgR45T12bKk7dxpGrbGbul5arIuZgKoa81dUSlxxg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrudeffedgvdeiucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
    rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
    htshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtjeen
    ucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomh
    grrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggft
    rfgrthhtvghrnhepjeejgfekudegheeivdeiffdvffegteektdfhudeljeeikefhteefke
    efgffgieegnecuffhomhgrihhnpehquhgsvghsqdhoshdrohhrghdpghhithhhuhgsrdgt
    ohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmh
    grrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnhgspghr
    tghpthhtohepfedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepjhhgrhhoshhsse
    hsuhhsvgdrtghomhdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghn
    phhrohhjvggtthdrohhrghdprhgtphhtthhopegrnhgurhgvfidrtghoohhpvghrfeestg
    hithhrihigrdgtohhm
X-ME-Proxy: <xmx:iDJ3Z9A46msdADfAL09nAl37dT-uI7rz10mM97bdxtVqfj3z2-L95g>
    <xmx:iDJ3Z-jUyF14bd1tVAeUC9zucZ8Xjs1Vyx6NOFZNCF0L680Wwe5TGg>
    <xmx:iDJ3ZxqzkVT3m-x555rrq8AqMonHsGh4NdN34g4aVLa08BlRg4k2JQ>
    <xmx:iDJ3Z5gviAMeESHwiMXHicbEDXzM3YAZSXP7GUs8U8ztUqEwrf4gyw>
    <xmx:iDJ3Z_uhb1PwZcehBGNZoOeNc2daP1QYzXskpkmkxl47cBfHkzmE25VO>
Feedback-ID: i1568416f:Fastmail
Date: Fri, 3 Jan 2025 01:42:45 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: Linux 6.13-rc3 many different panics in Xen PV dom0
Message-ID: <Z3cyhdKu6M1vdBe_@mail-itl>
References: <Z2RGfpJkO0z_nKV6@mail-itl>
 <ab9c27d5-f3f2-4b8a-960d-f880ec136199@suse.com>
 <6bb03333-74ca-4c2c-85a8-72549b85a5b4@suse.com>
 <Z3aFdrygLF9yK2EK@mail-itl>
 <Z3bg-gvaBEdSIuRW@mail-itl>
 <08f9604b-df23-4766-a290-ef9daa506f8d@suse.com>
 <Z3brZQmYhx-QTnga@mail-itl>
 <Z3cs1-wG5WJ9FrAR@mail-itl>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="9rr+QR6SemhkxG7w"
Content-Disposition: inline
In-Reply-To: <Z3cs1-wG5WJ9FrAR@mail-itl>


--9rr+QR6SemhkxG7w
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Fri, 3 Jan 2025 01:42:45 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: Linux 6.13-rc3 many different panics in Xen PV dom0

On Fri, Jan 03, 2025 at 01:18:31AM +0100, Marek Marczykowski-G=C3=B3recki w=
rote:
> On Thu, Jan 02, 2025 at 08:39:16PM +0100, Marek Marczykowski-G=C3=B3recki=
 wrote:
> > On Thu, Jan 02, 2025 at 08:17:00PM +0100, J=C3=BCrgen Gro=C3=9F wrote:
> > > On 02.01.25 19:54, Marek Marczykowski-G=C3=B3recki wrote:
> > > > On Thu, Jan 02, 2025 at 01:24:21PM +0100, Marek Marczykowski-G=C3=
=B3recki wrote:
> > > > > On Thu, Jan 02, 2025 at 12:30:10PM +0100, Juergen Gross wrote:
> > > > > > On 02.01.25 11:20, J=C3=BCrgen Gro=C3=9F wrote:
> > > > > > > On 19.12.24 17:14, Marek Marczykowski-G=C3=B3recki wrote:
> > > > > > > > Hi,
> > > > > > > >=20
> > > > > > > > It crashes on boot like below, most of the times. But somet=
imes (rarely)
> > > > > > > > it manages to stay alive. Below I'm pasting few of the cras=
hes that look
> > > > > > > > distinctly different, if you follow the links, you can find=
 more of
> > > > > > > > them. IMHO it looks like some memory corruption bug somewhe=
re. I tested
> > > > > > > > also Linux 6.13-rc2 before, and it had very similar issue.
> > > > > > >=20
> > > > > > > ...
> > > > > > >=20
> > > > > > > >=20
> > > > > > > > Full log:
> > > > > > > > https://openqa.qubes-os.org/tests/122879/logfile?filename=
=3Dserial0.txt
> > > > > > >=20
> > > > > > > I can reproduce a crash with 6.13-rc5 PV dom0.
> > > > > > >=20
> > > > > > > What is really interesting in the logs: most crashes seem to =
happen right
> > > > > > > after a module being loaded (in my reproducer it was right af=
ter loading
> > > > > > > the first module).
> > > > > > >=20
> > > > > > > I need to go through the 6.13 commits, but I think I remember=
 having seen
> > > > > > > a patch optimizing module loading by using large pages for ad=
dressing the
> > > > > > > loaded modules. Maybe the case of no large pages being availa=
ble isn't
> > > > > > > handled properly.
> > > > > >=20
> > > > > > Seems I was right.
> > > > > >=20
> > > > > > For me the following diff fixes the issue. Marek, can you pleas=
e confirm
> > > > > > it fixes your crashes, too?
> > > > >=20
> > > > > Thanks for looking into it!
> > > > > Will do, I've pushed it to
> > > > > https://github.com/QubesOS/qubes-linux-kernel/pull/662, CI will b=
uild it
> > > > > and then I'll post it to openQA.
> > > >=20
> > > > It is much better!
> > > >=20
> > > > Tests are still running, but I already see that many are green.
> > >=20
> > > So are you fine with me adding your "Tested-by:"?
> >=20
> > Yes.
> >=20
> > > > There is
> > > > one issue (likely unrelated to this change) - sys-usb (HVM domU wit=
h USB
> > > > controllers passed through) crashes on a system with Raptor Lake CPU
> > > > (only, others, including ADL and MTL look fine):
>=20
> Correction, it does happen on some others too, just got the crash on the =
ADL
> system, although looks a bit different ("Corrupted page table at ..."):

I've collected some more of them at https://github.com/QubesOS/qubes-issues=
/issues/9681

Should I start new thread for this? On one hand, it's a different domain
type (HVM), but on the other hand, many of the crashes are around
loading modules too.

> > > > [   75.770849] Bluetooth: Core ver 2.22
> > > > [   75.770866] Oops: general protection fault, probably for non-can=
onical address 0xc9d2315bc82c3bbd: 0000 [#1] PREEMPT SMP NOPTI
> > > > [   75.770880] CPU: 0 UID: 0 PID: 923 Comm: (udev-worker) Not taint=
ed 6.13.0-0.rc5.2.qubes.1.fc41.x86_64 #1
> > > > [   75.770890] Hardware name: Xen HVM domU, BIOS 4.19.0 01/02/2025
> > > > [   75.770897] RIP: 0010:msft_monitor_device_del+0x93/0x170 [blueto=
oth]
> > > > [   75.770924] Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0=
0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0 6=
5 21 <26> 2b 8b ad 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > >=20
> > > This code is looking suspicious. Large areas of binary 0 in a normal =
function?
> > > And the code itself is nonsense, as it is using a memory access via E=
S:, which
> > > doesn't make any sense in 64-bit kernel.
> >=20
> > Could it be still something related to modules layout in memory?
> > It seems it's not 100% reliable crash, I see in at least one instance
> > sys-usb remained running (unfortunately I don't have collected full
> > sys-usb console log from successful test...).
> >=20
> > I just checked again that this crash didn't happen with any 6.12 or 6.11
> > kernels.
> >=20
> > --=20
> > Best Regards,
> > Marek Marczykowski-G=C3=B3recki
> > Invisible Things Lab
>=20
>=20
>=20
> --=20
> Best Regards,
> Marek Marczykowski-G=C3=B3recki
> Invisible Things Lab



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

--9rr+QR6SemhkxG7w
Content-Type: application/pgp-signature; name="signature.asc"

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmd3MoUACgkQ24/THMrX
1ywetwf/QgxgN60A7zYRYpRF1vnTepqX3Juvr11mC4Ek9Lasl7cp59PTiNZArPmZ
RbtWL14u85wlyXLlZx49QfotkEolF+6uq+PlpcTHSNto32I68NO07yUiK9m7K4x5
sz+3x0j1Js6QF+Ip9VyUCNHMeHzeYucPZ3iP4MWf1HZXCzJVFLiudtgGiJA486wl
bMQh1IAUI5P2zF+cupWhnL4clXarlghCl16Qr87mmcE0mminyxIoWaqApVW51MbD
3H3NgxY06PdUQffOb4b/GAX8+E7RE+Xw1JLR7D9fdAdCfyKBr9IUnGmKZeG4x45S
4v1dzU8qRU5MIBiIXTVVDiEEniXtUw==
=7XeS
-----END PGP SIGNATURE-----

--9rr+QR6SemhkxG7w--


From xen-devel-bounces@lists.xenproject.org Fri Jan 03 02:00:51 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Jan 2025 02:00:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864534.1275767 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTWzK-0005zO-C6; Fri, 03 Jan 2025 02:00:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864534.1275767; Fri, 03 Jan 2025 02:00:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTWzK-0005zG-8C; Fri, 03 Jan 2025 02:00:34 +0000
Received: by outflank-mailman (input) for mailman id 864534;
 Fri, 03 Jan 2025 02:00:32 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=/LDK=T3=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tTWzI-0005zA-Oe
 for xen-devel@lists.xenproject.org; Fri, 03 Jan 2025 02:00:32 +0000
Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com
 [2a00:1450:4864:20::341])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8236f17e-c976-11ef-99a4-01e77a169b0f;
 Fri, 03 Jan 2025 03:00:30 +0100 (CET)
Received: by mail-wm1-x341.google.com with SMTP id
 5b1f17b1804b1-43624b2d453so122899705e9.2
 for <xen-devel@lists.xenproject.org>; Thu, 02 Jan 2025 18:00:30 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c8acb17sm38987351f8f.97.2025.01.02.18.00.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 02 Jan 2025 18:00:29 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8236f17e-c976-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1735869629; x=1736474429; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=7zuOjVXgnkPwQMP7MR7TKO6LRc7j4GDa+39am5cyxng=;
        b=vb7GEz2ZQ33EzDjoWm5DJOt0IGihSiLQ1PdsLPfv2gzy915QaYbuB7gTG6YQk363lt
         7p5AUODXgthJLuNC5vN5TuJPLV7qFtGhDI3YWD2zgR7knmcAyQIA5urOF0E6Wx2BcCP7
         La2n/OwYMfl/vU3fIX4vGZWbaa8uD3SZMsg90=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735869629; x=1736474429;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=7zuOjVXgnkPwQMP7MR7TKO6LRc7j4GDa+39am5cyxng=;
        b=CLHpcBjR5EU6GDmSCehZ5wUOUHhGN+zeunPWACH4KOZmATj0lFgoejveH9NL7DrkwX
         Ei4bG+ivcWscovGhI0MxjPhKV6nddCvLHZBWenr/SkctlrFIkG71MiOlMLmuwD5RW6jA
         f23j+6d2iDFu8Oieph3HDtyftk4tGb0cK69IHPIvlIzS8RgogwpXXF7mzfYiPvIWOzqu
         mQok7CFMSR0PSrhs49nVRdW125foOs3kOIJ2cA9do6PJmrrCNGpVxS4smYQ8SpPyWERN
         wXoydcgPO/iamEAilGazChrBm+FPTRPSFeDOCk9eN5GHcaq1nRnAVDTu+dXYMbIQebN2
         qx+Q==
X-Gm-Message-State: AOJu0YwfUqmTj6w0wxluBliM1SZ/8V5tgyIH7Tz6XjBhktWCB66XPFhf
	AAFmofgiheNMF5t3quNNFlw9u5vWmr3tecw4wClyX4QkKJtjuKPtd6SquWY4gv0=
X-Gm-Gg: ASbGnctmmwLuUrZSLFvcMZrFSN5L0P+7HL3hccey9VQlA0CIIO1CCTVGjHrwxL5CKeI
	risDICFwq9ZD9Ce0oqVPkfAuW+wI9N7WXUJMfx5Cu1i/r/Pas2h5TneYFufEy2gQcy1GIluBmHh
	46ASwmq6K1qV6vUGEmHrXRa1DmDNI7rvY4JQnSoT1fQgE61x8khg6+64JeAkdod4CyUnEekKlg2
	de82JfnMeRVWZy07AHMtP+sx2A7ayvH+w8IlJhmfVAycWjI/qH3D/nXzi7DD2DBVnC+LaMk97TG
	nT/Afy36qMTh3geAWhFA
X-Google-Smtp-Source: AGHT+IEgfwFHdWLdolAtzV3QVe5gYBtDXjFdMTGRAetAtySdB6+2/1XtCqj3FLZT9QaksDRM0zE+5w==
X-Received: by 2002:a05:600c:3146:b0:434:f817:4492 with SMTP id 5b1f17b1804b1-43668b5f887mr441204145e9.31.1735869629493;
        Thu, 02 Jan 2025 18:00:29 -0800 (PST)
Message-ID: <b4b2229f-a139-4cfe-9cb1-e218b7123c08@citrix.com>
Date: Fri, 3 Jan 2025 02:00:28 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Linux 6.13-rc3 many different panics in Xen PV dom0
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?=
 <jgross@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>
References: <Z2RGfpJkO0z_nKV6@mail-itl>
 <ab9c27d5-f3f2-4b8a-960d-f880ec136199@suse.com>
 <6bb03333-74ca-4c2c-85a8-72549b85a5b4@suse.com> <Z3aFdrygLF9yK2EK@mail-itl>
 <Z3bg-gvaBEdSIuRW@mail-itl> <08f9604b-df23-4766-a290-ef9daa506f8d@suse.com>
 <Z3brZQmYhx-QTnga@mail-itl> <Z3cs1-wG5WJ9FrAR@mail-itl>
 <Z3cyhdKu6M1vdBe_@mail-itl>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <Z3cyhdKu6M1vdBe_@mail-itl>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 03/01/2025 12:42 am, Marek Marczykowski-Górecki wrote:
> On Fri, Jan 03, 2025 at 01:18:31AM +0100, Marek Marczykowski-Górecki wrote:
>> On Thu, Jan 02, 2025 at 08:39:16PM +0100, Marek Marczykowski-Górecki wrote:
>>> On Thu, Jan 02, 2025 at 08:17:00PM +0100, Jürgen Groß wrote:
>>>> On 02.01.25 19:54, Marek Marczykowski-Górecki wrote:
>>>>> On Thu, Jan 02, 2025 at 01:24:21PM +0100, Marek Marczykowski-Górecki wrote:
>>>>>> On Thu, Jan 02, 2025 at 12:30:10PM +0100, Juergen Gross wrote:
>>>>>>> On 02.01.25 11:20, Jürgen Groß wrote:
>>>>>>>> On 19.12.24 17:14, Marek Marczykowski-Górecki wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> It crashes on boot like below, most of the times. But sometimes (rarely)
>>>>>>>>> it manages to stay alive. Below I'm pasting few of the crashes that look
>>>>>>>>> distinctly different, if you follow the links, you can find more of
>>>>>>>>> them. IMHO it looks like some memory corruption bug somewhere. I tested
>>>>>>>>> also Linux 6.13-rc2 before, and it had very similar issue.
>>>>>>>> ...
>>>>>>>>
>>>>>>>>> Full log:
>>>>>>>>> https://openqa.qubes-os.org/tests/122879/logfile?filename=serial0.txt
>>>>>>>> I can reproduce a crash with 6.13-rc5 PV dom0.
>>>>>>>>
>>>>>>>> What is really interesting in the logs: most crashes seem to happen right
>>>>>>>> after a module being loaded (in my reproducer it was right after loading
>>>>>>>> the first module).
>>>>>>>>
>>>>>>>> I need to go through the 6.13 commits, but I think I remember having seen
>>>>>>>> a patch optimizing module loading by using large pages for addressing the
>>>>>>>> loaded modules. Maybe the case of no large pages being available isn't
>>>>>>>> handled properly.
>>>>>>> Seems I was right.
>>>>>>>
>>>>>>> For me the following diff fixes the issue. Marek, can you please confirm
>>>>>>> it fixes your crashes, too?
>>>>>> Thanks for looking into it!
>>>>>> Will do, I've pushed it to
>>>>>> https://github.com/QubesOS/qubes-linux-kernel/pull/662, CI will build it
>>>>>> and then I'll post it to openQA.
>>>>> It is much better!
>>>>>
>>>>> Tests are still running, but I already see that many are green.
>>>> So are you fine with me adding your "Tested-by:"?
>>> Yes.
>>>
>>>>> There is
>>>>> one issue (likely unrelated to this change) - sys-usb (HVM domU with USB
>>>>> controllers passed through) crashes on a system with Raptor Lake CPU
>>>>> (only, others, including ADL and MTL look fine):
>> Correction, it does happen on some others too, just got the crash on the ADL
>> system, although looks a bit different ("Corrupted page table at ..."):
> I've collected some more of them at https://github.com/QubesOS/qubes-issues/issues/9681
>
> Should I start new thread for this? On one hand, it's a different domain
> type (HVM), but on the other hand, many of the crashes are around
> loading modules too.

https://lore.kernel.org/lkml/20241227072825.1288491-1-rppt@kernel.org/T/#t
looks relevant.  Probably worth following up.

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri Jan 03 10:05:54 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Jan 2025 10:05:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864550.1275777 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTeYj-0002W2-VX; Fri, 03 Jan 2025 10:05:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864550.1275777; Fri, 03 Jan 2025 10:05:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTeYj-0002Vv-SE; Fri, 03 Jan 2025 10:05:37 +0000
Received: by outflank-mailman (input) for mailman id 864550;
 Fri, 03 Jan 2025 10:05: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
 <SRS0=kEjL=T3=amd.com=ayan.kumar.halder@srs-se1.protection.inumbo.net>)
 id 1tTeYi-0002Vo-BX
 for xen-devel@lists.xenproject.org; Fri, 03 Jan 2025 10:05:36 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on2060b.outbound.protection.outlook.com
 [2a01:111:f403:2417::60b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4475d542-c9ba-11ef-99a4-01e77a169b0f;
 Fri, 03 Jan 2025 11:05:33 +0100 (CET)
Received: from PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7)
 by SA1PR12MB7199.namprd12.prod.outlook.com (2603:10b6:806:2bc::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8314.12; Fri, 3 Jan
 2025 10:05:26 +0000
Received: from PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264]) by PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264%6]) with mapi id 15.20.8314.013; Fri, 3 Jan 2025
 10:05:26 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 4475d542-c9ba-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=f/VuztrSaeeW5Rw58P6J+wnC/moNXTF71LAYyyG9Ou9mKISPvtmjCJ0IL8lvwZYG9bCbpX5DaJGDqcKAjxzTYFMBoTPzg16JEFcU+xB1tiPg0sj50IH4/D0oNohS66Cc/yRok/L6X2QllkIo9polaOgjsvkP1pmAdMIUfN/Nzr6MFPyIAhEAyB85/EgHN+MnoPm03l6iZfEH+8YDImiNpGkqEm8lG46cgBqHuxA/EKQbj3uoku9Ecg5IF94mywMczPjOUDcfUhUN82Fx1S7Orve4U7m25QWce9D+vKn7UShMHkoKt8ns2bVWudGq2HAqHX2BRDblizLX9jYiguQHyw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=3f2EOb0fsLW1LW7sBLDEv7XLMSjTm//Reskx8TQXWOU=;
 b=Q3Koi6D6xFa/3vMZQyQrga4xD6fumEeq+uhdOFof/Nxfjzq42IS5i2PoLQRFtUtCp8mMEjKwz4ZTYImWcCkMLF+djDeu+PUZoVmOLRyxSLLhvE5hczxzzJQglq28EnLmLOhvE8ieDkGcwqqLO7a9Mk2v4XBT4wa5SDM+MZ7XF31DyO5iAtLDW829cR0dWjhH8JGUJ/cUiZBLtVMKAKJX18hU6xrqLjubgmvQHC3Q6IiRcwsTTXVDmjdMyV64R9TfF36oZOWJXPE60sR5nNr9tZSd9jcWfmUAh0wifGmvzDHo7Bf07J2QECaEcInqUvBkyF30xfiLHa21WxoImIk+vg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=3f2EOb0fsLW1LW7sBLDEv7XLMSjTm//Reskx8TQXWOU=;
 b=pQSxU4+ciTHMJ169NlhPWiSVax0xCUBVA/kJYFjOFzVWRR7oDSm8lQnMcOBCipZVFSBWsV5rszrC9I5ExovL76KfcoAPsPSllXqfQjDWD/F/euJmb4yJHeHbavFTcFXNbgaPcqtPiaICEND74YyMQgWhQkt33XsP8bHlJ2q7uuw=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <88726324-89dd-426e-ba7a-fc3e5b12733e@amd.com>
Date: Fri, 3 Jan 2025 10:05:19 +0000
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v1] xen: mem_access: conditionally compile vm_event.c
 & monitor.c
To: Stefano Stabellini <sstabellini@kernel.org>,
 Sergiy Kibrik <Sergiy_Kibrik@epam.com>
Cc: xen-devel@lists.xenproject.org,
 Stefano Stabellini <stefano.stabellini@amd.com>,
 Julien Grall <julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Tamas K Lengyel <tamas@tklengyel.com>,
 Alexandru Isaila <aisaila@bitdefender.com>,
 Petre Pircalabu <ppircalabu@bitdefender.com>
References: <20241230063051.3332332-1-Sergiy_Kibrik@epam.com>
 <alpine.DEB.2.22.394.2501021133050.16425@ubuntu-linux-20-04-desktop>
Content-Language: en-GB
From: Ayan Kumar Halder <ayankuma@amd.com>
In-Reply-To: <alpine.DEB.2.22.394.2501021133050.16425@ubuntu-linux-20-04-desktop>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: AS9PR01CA0033.eurprd01.prod.exchangelabs.com
 (2603:10a6:20b:542::19) To PH8PR12MB7326.namprd12.prod.outlook.com
 (2603:10b6:510:216::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH8PR12MB7326:EE_|SA1PR12MB7199:EE_
X-MS-Office365-Filtering-Correlation-Id: 973d469e-e09e-4eae-0e35-08dd2bde24ea
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|7416014|376014|366016;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?MGtXZEVLK3lTVkJRVU93SVVYNWIvWi9ZSS9EelFOTXd2TUFVSGpIMktpb1Vl?=
 =?utf-8?B?UzhPUDl4SmpaYVVBNnNkZTV0VlRWYTdEWjRuS2NqSXUwcVUybTY2dENOcTNv?=
 =?utf-8?B?S1VuQ1haWWUzR2FTWmYwb1I0czhlY2IvRUIvSmQwNW9VYXJleitRZ2g4blRi?=
 =?utf-8?B?eGR2SkQ3cVJuZ2J0K1FDNDdZQjVYNytBeisvS1YrMjJZVy9abUpTYUdUQU9a?=
 =?utf-8?B?NXFrc01NdjcrajJ1anZPK205YzJxaE5JNERVWkV4anpEa1M4UkxYbzdBRElK?=
 =?utf-8?B?WWFjdFJ2b1FwUnJ2YkdlWEtHU3hsOWFHOWVxM2F2eGtML09EcFl2WXdQazBh?=
 =?utf-8?B?ZDhjRTQ1NG5MczhvL3VZWTJwVmpFaHJ3cWE4WFZqaGEwekNuUHlrcFAvYXh0?=
 =?utf-8?B?aHV4TEU0d3RSbnd3ZnBNN0Z5aE53OC8zd0ZCMkpQcU9CZVVJcFZXcC9wbHBt?=
 =?utf-8?B?RHhwbm9sdjJTVVF5UHQyVmRSSUt0eWw2SklKUGt6bWpJRTM1MjBUTVZtb1lL?=
 =?utf-8?B?YktnM3RxTk8yWENWL3BqL00zL0VGZmlFN1dkdlNLeFJqcHZtNjJyNWpnQUhw?=
 =?utf-8?B?ZG5SUm9GVnkyakM1a3ZOd1JNdXozUktYWllsRnd6b2RyUkFrd0Q1YXg5ZEFy?=
 =?utf-8?B?REoyY0JNeFJKYkt2Szd1RU4yNzB4MjluM29KVUFMYnFGTURpMS9iQWU3cTJK?=
 =?utf-8?B?ZEQxYmdVcmw3dWo5MkhUK1FORy91ZVJWbjFvV0NZY0I0TGphOHlBQ3ZaS3ZB?=
 =?utf-8?B?N2V6a3dVVGkxV1UzQ2MwdG9kWXU2YXBhbXIzc0RmMHJtSjM3Vm53dWRjZ0Q0?=
 =?utf-8?B?K1M5NXJjemM4bE9tZTN4YXJRWnNwTzV4UFQxanI1djJIQUl0Wm8xU0prcm15?=
 =?utf-8?B?UDU5Z2N6RERxMWdFb1EyZy9RYTZZRS9xbldTZDFUQ2J0TlZ4YlJOUlorRmcy?=
 =?utf-8?B?TTdvR1BoYVA1OEtSbkd6VVhLRm9MS2kwOFV1MkZORGtjd3J4RmdCYjFJQllw?=
 =?utf-8?B?cFEvSjBZU2hJZkQwbVNxSUFvNSt0SzNuTkJwZ1E3WEw1VGV6YzFOZUdWL01y?=
 =?utf-8?B?WlZBNVF1WDlOa3l2R1ZWbnNJaHgyUHZtY2VrVkJVSmQ3SGhwOXRMbmk5dnZE?=
 =?utf-8?B?alpWUkU0MnlrTWxwRWVmNjF1SElKU0JJSE83SW5RQ0I3ZnZhSjZkcndIQVhO?=
 =?utf-8?B?T2lqL09KbFY5clVNZWFJcVNXQXY3NmlWREdNNXFxQ0p3SWxFMXZxUzRaNmN4?=
 =?utf-8?B?YkVvaTVhWVpvT1Q5aXY4MjkvNFRqa2tzendHS3lydG1GOEFiVTBUVmVIY3k4?=
 =?utf-8?B?a0YvZHE0a1pla2d3TndxVUxvaVJyM01GcDRhVzFtaHNPYkMzNXM3aC9tbm84?=
 =?utf-8?B?SDVOZTZQYmZoM1EzZVJuN0gwMk0wWDlpTXZhVllIMzFBUyt3ZStXM05iNlZZ?=
 =?utf-8?B?UzN1RmE3VnVoVUJLTHJCNTRqZGlBRHl2QkFJTS95MWUyYWlXQ2t5Mmp0S2JR?=
 =?utf-8?B?eEhYL1o2M3orZjRTWDI1dVVCNXdMblB2bFVDM2FncTRVd2lxTmJaejlMbUE3?=
 =?utf-8?B?N1E4dWkrNnJac3J3QTJlMkJEUnZ2TXdzV0lTRExURGFVMDhMODhPWTBMMEt1?=
 =?utf-8?B?dXFxUDVEY0tqSVFQN3ltdmdQMVJDUzRNdVJXcHdKY1ZXVzZlRVk4YTRzNWtm?=
 =?utf-8?B?QkFSVlpkaEtwWGNhblJCR0ZxZytUK0FaTXZYTklJdUlGR3U4dUV0SnpsUVJN?=
 =?utf-8?B?YjA1Sk93U1I4djJFZzcyUTBJUzhoVlBJVFFEcGpPVWF2RnBZY1llN3FQU21W?=
 =?utf-8?B?RjdKRE14UW4yTzdHaE1XOXpkQ0NKa1dVQVBxMTVFbkpuTmM2Tm1OR2F0cjdo?=
 =?utf-8?Q?niSrAoAORNRaK?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH8PR12MB7326.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(7416014)(376014)(366016);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?dHgyOFlveWZUNjd2VDQwNlRIVUVvRWhlbnZGaFdFVWRzbXh2NnlhendvTEli?=
 =?utf-8?B?b2YvMC84VHhNYTAxZ2JTVU9aR2ppc1FVQlhGeStKZ3V5ajdpclVEVEhORkdB?=
 =?utf-8?B?OVBmUUVoYW84NDh1MFpYZ0RFNzkwV2JzcHgvb09tVlkrajlQRy85aEgveW80?=
 =?utf-8?B?S0JTNGx6TGx5eVdyU2xLUURlQ3kxa3RZUEZYU01WcGtQdnl5clJ0dk9UdVFB?=
 =?utf-8?B?T1pJckNsR1hsNC9LbVppemc4Z3Y3aVlDLzFWMGtTcjhZQzFBejhlMmRzdGpq?=
 =?utf-8?B?TTZ0Z0VUb1JYUU5pMU9kVkt5SlZSWk84L2tlRmNTVXV0dGxtRnVpSmxncy9Z?=
 =?utf-8?B?NXdiQWVFVVZzQjJOaFcwTUZMNFhyN2VCejAvYmFMcVRsSG9Ud3ZZT0lLUVp4?=
 =?utf-8?B?VldhU0I3SlBpRy9aT092ZWV6MGNlQXR4UXB4ZUFxbWFuR1NrMDgyNExOT2hv?=
 =?utf-8?B?UnZMWTV5c0ROWFZEQzZlM2pPREhRRHAydmJSMEgyVE9VVTd5NlZsYy94TzNr?=
 =?utf-8?B?cWQ0aWY5NTMrUTBKckZqSnc4U3VWbXlNeHBZSDhmTWR5ekY4dkdZb1ladHpH?=
 =?utf-8?B?dTRRVE4rNjRnaDR1di9rRDJoK0ZFa1VBYXlIQlNyaVkyUTJvS0tsSGJHeTQ0?=
 =?utf-8?B?aEhMemdXSUFhSHd6MlpLSHI2MGhFRlh0djFPTytlZjgxVloxVmk4T1lkS2ZZ?=
 =?utf-8?B?UERxZEx2NTFXS1JGSlZ0NzJvL0xFcVFERUs2bGlQRy9zeEVBSGJIUWRIOFEz?=
 =?utf-8?B?NmVDV3VYb09NSTM2dHVJVEtKVkRlbEdqSzZLSGhSaGRFQWV6M0lDc1hmSEJ4?=
 =?utf-8?B?MGlTRDI4U0oyVUJrOWI3aTBlYmZ5dmNwR1pSU0pjZmlTTEdqaFAxQ1pWaDIx?=
 =?utf-8?B?REFuY0Y1WXdJY1FBUUZjd0hYUXFjQ3lZWFQvU2NMTkU2YmlTcUpIUk5JVC9u?=
 =?utf-8?B?Ym1ocWxielg1VFdRMkxuWGluQUh2TEJsb2Z3K1YxdGhmUDRuMEVFWitZZm8x?=
 =?utf-8?B?Z2RWM2hTSUF2UXRSMnJzeHV3SGdmT043ZlZHT3NVYVVudEZhOWU0N1ErK0Z0?=
 =?utf-8?B?Q0VUaVZpSHZRUmczNWl1T0x5V0RMMSt1aWNMZUNkc3NJM1owUlJTTnlnTzEr?=
 =?utf-8?B?Z3NLWGgyT0MyRkc5ZEV0VDBuUUJ1VjFHWWFFT2t6KzZ2Y1UvZStQRnREa2lu?=
 =?utf-8?B?REhsN2VycnlMQmhrQVlkd1MxYTJnQzkvcVJPMGhja24zZnhiVDhWVWxtWk1J?=
 =?utf-8?B?UmJvM0MzMUJ0NEdQQUlYZThmWnZjWTBkMjFJSFNseGJZaXdnR2J1NWUxcU9W?=
 =?utf-8?B?a3c3eGFpSnJLdk00bW5OeXB2V3FMTXVEWjlQSHJjU0c0QnZ3SWlJcWJFSzJ1?=
 =?utf-8?B?VEl3MDdtbnoxUDB2NldMRnFDRUJ1cFNDT29oamd5eFBTWjhkcFJTb2xkRkU3?=
 =?utf-8?B?U255MnZQV1ZvMC91WW56OHBqRldhOU1RZG5LeEhpNDFYT3p5Q1YzeGMvbmNt?=
 =?utf-8?B?OVU4alJsazAwaHZ1VlEvMiszbS92VCtTSTVUM2tIZ1FCd0tSVzN0bGxnWmtx?=
 =?utf-8?B?L2c4Rit0VkxpZE8ya1lQNlJiRGVOQXlDNEp1TklBQmpwbFN0SE0rM2twMFND?=
 =?utf-8?B?QlNvb1BUUy9VYUQxdUhnRUdTSFBaenlQNTR6TnlBbFZWNVNQT3puVHVKeEZ0?=
 =?utf-8?B?K0pmZlZCOSt5TXdmZ2cwUll5V1pySnFUcVZOcXNIdTdQT3lhWmpwWDgvZEhl?=
 =?utf-8?B?Qzd6MmhWWkR0Z09ad29MMk9yUlBIeUZhVEkzZWtMT3Y3dS9hdjNxMWJDV0Fz?=
 =?utf-8?B?aGtCR0hJRkVDUndQWGpjTU9MYU1uN0t0cW1PM0JHblY4enZJVmlEK01WM1pW?=
 =?utf-8?B?NkxZZ0JHRFNlTTdLVUN2Snc5YXZLdlBHeFFDZWt4MlJoZUNTT01mQVBlZWpa?=
 =?utf-8?B?ODhYK25SYld2MCtaT1hhQXNPNnhzdklvTWkyRWx6WStpbzNwQ25SQ2QvRjcw?=
 =?utf-8?B?c213Ykp6RlZISkdzOUtGM0dwZEZ1ZE1UMXRMUjJybFpOcVJGT0RyTEs0QnRw?=
 =?utf-8?B?czA1MHdneFp4U2VaUEdBVkQ1MVdwUDUrTVFQK2dUT2UwemVQcllsSHZ5dXJZ?=
 =?utf-8?Q?fOy48x17aGTLBaMJw54cZF9Zw?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 973d469e-e09e-4eae-0e35-08dd2bde24ea
X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7326.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jan 2025 10:05:25.9935
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: d6rG8e1WbHzpwTV6CB9ECetf2SPzM1659EOfkZP3mzhL7yaZ5M/Jj9khYaJ7R+CWSNk5C4JR55NejmtFWNthiA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB7199


On 02/01/2025 19:34, Stefano Stabellini wrote:
> CAUTION: This message has originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email.
>
>
> On Mon, 30 Dec 2024, Sergiy Kibrik wrote:
>> From: Stefano Stabellini <stefano.stabellini@amd.com>
>>
>> Extend coverage of CONFIG_MEM_ACCESS option and make the build of VM events
>> and monitoring support optional.
>> This is to reduce code size on Arm when this option isn't enabled.
>>
>> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
>> Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>

Reviewed-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>

- Ayan



From xen-devel-bounces@lists.xenproject.org Fri Jan 03 14:26:05 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Jan 2025 14:26:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864580.1275786 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTicX-000740-RI; Fri, 03 Jan 2025 14:25:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864580.1275786; Fri, 03 Jan 2025 14:25:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTicX-00073t-OQ; Fri, 03 Jan 2025 14:25:49 +0000
Received: by outflank-mailman (input) for mailman id 864580;
 Fri, 03 Jan 2025 14:25:49 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=o5mg=T3=inria.fr=fonyuy-asheri.caleb@srs-se1.protection.inumbo.net>)
 id 1tTicX-00073n-1m
 for xen-devel@lists.xenproject.org; Fri, 03 Jan 2025 14:25:49 +0000
Received: from mail2-relais-roc.national.inria.fr
 (mail2-relais-roc.national.inria.fr [192.134.164.83])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9f6e58ca-c9de-11ef-a0de-8be0dac302b0;
 Fri, 03 Jan 2025 15:25:47 +0100 (CET)
Received: from zcs2-store8.inria.fr ([128.93.142.6])
 by mail2-relais-roc.national.inria.fr with ESMTP; 03 Jan 2025 15:25:46 +0100
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9f6e58ca-c9de-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=inria.fr; s=dc;
  h=date:from:to:cc:message-id:subject:mime-version;
  bh=kt4M98Cy6jOnI51rllLEbPqEFW6bHVmTXKIBCBhaFSw=;
  b=dt8YoZtU3gEqPq4u7t1lMfBmf3bj7K6PdnjKzE3ZSQw/IZrKmNWQcOx2
   oeEYwDOBs0k3ljGs0f7R1yP0l6coLO90T3IypSL1s4/hlKKdz/8eSZtRM
   Wfr8kPLQXOxhZfiInjHw7crjuoK8cTVwbBhIQR/6TMrRyhgCSzxBMfjMP
   E=;
Authentication-Results: mail2-relais-roc.national.inria.fr; dkim=none (message not signed) header.i=none; spf=Pass smtp.mailfrom=fonyuy-asheri.caleb@inria.fr; spf=None smtp.helo=postmaster@zcs2-store8.inria.fr
Received-SPF: Pass (mail2-relais-roc.national.inria.fr: domain of
  fonyuy-asheri.caleb@inria.fr designates 128.93.142.6 as
  permitted sender) identity=mailfrom; client-ip=128.93.142.6;
  receiver=mail2-relais-roc.national.inria.fr;
  envelope-from="fonyuy-asheri.caleb@inria.fr";
  x-sender="fonyuy-asheri.caleb@inria.fr";
  x-conformance=spf_only; x-record-type="v=spf1";
  x-record-text="v=spf1 include:mailout.safebrands.com
  a:basic-mail.safebrands.com a:basic-mail01.safebrands.com
  a:basic-mail02.safebrands.com ip4:128.93.142.0/24
  ip4:192.134.164.0/24 ip4:128.93.162.160 ip4:128.93.162.3
  ip4:128.93.162.88 ip4:89.107.174.7 mx ~all"
Received-SPF: None (mail2-relais-roc.national.inria.fr: no sender
  authenticity information available from domain of
  postmaster@zcs2-store8.inria.fr) identity=helo;
  client-ip=128.93.142.6;
  receiver=mail2-relais-roc.national.inria.fr;
  envelope-from="fonyuy-asheri.caleb@inria.fr";
  x-sender="postmaster@zcs2-store8.inria.fr";
  x-conformance=spf_only
X-IronPort-AV: E=Sophos;i="6.12,286,1728943200"; 
   d="scan'208,217";a="201340769"
X-MGA-submission: =?us-ascii?q?MDEckorXfVwRa+NVnxExk2KhM5sE//nkGUPG9B?=
 =?us-ascii?q?nV9gtLTczUfcAZUWsDdOmJ3+p1YUVaC+RhsJJKLgByboxMq0a/SR0cHE?=
 =?us-ascii?q?PHwLE8hOSRU5u9+wUVsWWYsniPk9O3YlaPK6oc4c2/zus2HIxTFe+GpI?=
 =?us-ascii?q?1LXP8XwhJZPml8Be34gw89uQ=3D=3D?=
Date: Fri, 3 Jan 2025 15:25:46 +0100 (CET)
From: Fonyuy-Asheri Caleb <fonyuy-asheri.caleb@inria.fr>
To: xen-devel <xen-devel@lists.xenproject.org>
Cc: Jan Beulich <jbeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <944938302.6053932.1735914346495.JavaMail.zimbra@inria.fr>
Subject: Help With Identifying CPUID faulting logic in Xen code
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="=_87ed86ca-dcae-4c7f-b4d9-51ed8a12c060"
X-Originating-IP: [176.180.88.57]
X-Mailer: Zimbra 10.1.3_GA_4699 (ZimbraWebClient - GC131 (Linux)/10.1.3_GA_4703)
Thread-Index: /woCOpHH4VcfB1CDYgx0B/Ta9wD+cA==
Thread-Topic: Help With Identifying CPUID faulting logic in Xen code

--=_87ed86ca-dcae-4c7f-b4d9-51ed8a12c060
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hello, 

I am interested in finding understanding how xen handles CPUID faulting and 
VM exits in general. Please can someone indicate to me the concerned files? 

I want to know how xen detects the execution of the CPUID instruction and 
ensures a guest only gets the features defined in cpuid-autogen.h file 
depending on the guest type. 

I started looking at the file xen/arch/x86/cpuid.c but don't really know which other 
files to check next. 

Thanks 

Caleb 

--=_87ed86ca-dcae-4c7f-b4d9-51ed8a12c060
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<html><body><div style=3D"font-family: arial, helvetica, sans-serif; font-s=
ize: 12pt; color: #000000"><div style=3D"color: #000000; font-family: arial=
, helvetica, sans-serif; font-size: 16px; font-style: normal; font-variant-=
ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spac=
ing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transfor=
m: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; whit=
e-space: normal; background-color: #fdfcfa; text-decoration-thickness: init=
ial; text-decoration-style: initial; text-decoration-color: initial;" data-=
mce-style=3D"color: #000000; font-family: arial, helvetica, sans-serif; fon=
t-size: 16px; font-style: normal; font-variant-ligatures: normal; font-vari=
ant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; tex=
t-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spa=
cing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; background-=
color: #fdfcfa; text-decoration-thickness: initial; text-decoration-style: =
initial; text-decoration-color: initial;">Hello,</div><div style=3D"color: =
#000000; font-family: arial, helvetica, sans-serif; font-size: 16px; font-s=
tyle: normal; font-variant-ligatures: normal; font-variant-caps: normal; fo=
nt-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text=
-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-t=
ext-stroke-width: 0px; white-space: normal; background-color: #fdfcfa; text=
-decoration-thickness: initial; text-decoration-style: initial; text-decora=
tion-color: initial;" data-mce-style=3D"color: #000000; font-family: arial,=
 helvetica, sans-serif; font-size: 16px; font-style: normal; font-variant-l=
igatures: normal; font-variant-caps: normal; font-weight: 400; letter-spaci=
ng: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform=
: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white=
-space: normal; background-color: #fdfcfa; text-decoration-thickness: initi=
al; text-decoration-style: initial; text-decoration-color: initial;"><br></=
div><div style=3D"color: #000000; font-family: arial, helvetica, sans-serif=
; font-size: 16px; font-style: normal; font-variant-ligatures: normal; font=
-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2=
; text-align: start; text-indent: 0px; text-transform: none; widows: 2; wor=
d-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; backgr=
ound-color: #fdfcfa; text-decoration-thickness: initial; text-decoration-st=
yle: initial; text-decoration-color: initial;" data-mce-style=3D"color: #00=
0000; font-family: arial, helvetica, sans-serif; font-size: 16px; font-styl=
e: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-=
weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-in=
dent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text=
-stroke-width: 0px; white-space: normal; background-color: #fdfcfa; text-de=
coration-thickness: initial; text-decoration-style: initial; text-decoratio=
n-color: initial;">I am interested in finding understanding how xen handles=
 CPUID faulting and&nbsp;</div><div style=3D"color: #000000; font-family: a=
rial, helvetica, sans-serif; font-size: 16px; font-style: normal; font-vari=
ant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-=
spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-tran=
sform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
white-space: normal; background-color: #fdfcfa; text-decoration-thickness: =
initial; text-decoration-style: initial; text-decoration-color: initial;" d=
ata-mce-style=3D"color: #000000; font-family: arial, helvetica, sans-serif;=
 font-size: 16px; font-style: normal; font-variant-ligatures: normal; font-=
variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2;=
 text-align: start; text-indent: 0px; text-transform: none; widows: 2; word=
-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; backgro=
und-color: #fdfcfa; text-decoration-thickness: initial; text-decoration-sty=
le: initial; text-decoration-color: initial;">VM exits in general. Please c=
an someone indicate to me the concerned files?&nbsp;</div><div style=3D"col=
or: #000000; font-family: arial, helvetica, sans-serif; font-size: 16px; fo=
nt-style: normal; font-variant-ligatures: normal; font-variant-caps: normal=
; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; =
text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webk=
it-text-stroke-width: 0px; white-space: normal; background-color: #fdfcfa; =
text-decoration-thickness: initial; text-decoration-style: initial; text-de=
coration-color: initial;" data-mce-style=3D"color: #000000; font-family: ar=
ial, helvetica, sans-serif; font-size: 16px; font-style: normal; font-varia=
nt-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-s=
pacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-trans=
form: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; w=
hite-space: normal; background-color: #fdfcfa; text-decoration-thickness: i=
nitial; text-decoration-style: initial; text-decoration-color: initial;"><b=
r></div><div style=3D"color: #000000; font-family: arial, helvetica, sans-s=
erif; font-size: 16px; font-style: normal; font-variant-ligatures: normal; =
font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphan=
s: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2;=
 word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; ba=
ckground-color: #fdfcfa; text-decoration-thickness: initial; text-decoratio=
n-style: initial; text-decoration-color: initial;" data-mce-style=3D"color:=
 #000000; font-family: arial, helvetica, sans-serif; font-size: 16px; font-=
style: normal; font-variant-ligatures: normal; font-variant-caps: normal; f=
ont-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; tex=
t-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-=
text-stroke-width: 0px; white-space: normal; background-color: #fdfcfa; tex=
t-decoration-thickness: initial; text-decoration-style: initial; text-decor=
ation-color: initial;">I want to know how xen detects the execution of the =
CPUID instruction and&nbsp;</div><div style=3D"color: #000000; font-family:=
 arial, helvetica, sans-serif; font-size: 16px; font-style: normal; font-va=
riant-ligatures: normal; font-variant-caps: normal; font-weight: 400; lette=
r-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-tr=
ansform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px=
; white-space: normal; background-color: #fdfcfa; text-decoration-thickness=
: initial; text-decoration-style: initial; text-decoration-color: initial;"=
 data-mce-style=3D"color: #000000; font-family: arial, helvetica, sans-seri=
f; font-size: 16px; font-style: normal; font-variant-ligatures: normal; fon=
t-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: =
2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; wo=
rd-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; backg=
round-color: #fdfcfa; text-decoration-thickness: initial; text-decoration-s=
tyle: initial; text-decoration-color: initial;">ensures a guest only gets t=
he features defined in cpuid-autogen.h file&nbsp;</div><div style=3D"color:=
 #000000; font-family: arial, helvetica, sans-serif; font-size: 16px; font-=
style: normal; font-variant-ligatures: normal; font-variant-caps: normal; f=
ont-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; tex=
t-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-=
text-stroke-width: 0px; white-space: normal; background-color: #fdfcfa; tex=
t-decoration-thickness: initial; text-decoration-style: initial; text-decor=
ation-color: initial;" data-mce-style=3D"color: #000000; font-family: arial=
, helvetica, sans-serif; font-size: 16px; font-style: normal; font-variant-=
ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spac=
ing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transfor=
m: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; whit=
e-space: normal; background-color: #fdfcfa; text-decoration-thickness: init=
ial; text-decoration-style: initial; text-decoration-color: initial;">depen=
ding on the guest type.&nbsp;</div><div style=3D"color: #000000; font-famil=
y: arial, helvetica, sans-serif; font-size: 16px; font-style: normal; font-=
variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; let=
ter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-=
transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0=
px; white-space: normal; background-color: #fdfcfa; text-decoration-thickne=
ss: initial; text-decoration-style: initial; text-decoration-color: initial=
;" data-mce-style=3D"color: #000000; font-family: arial, helvetica, sans-se=
rif; font-size: 16px; font-style: normal; font-variant-ligatures: normal; f=
ont-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans=
: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; bac=
kground-color: #fdfcfa; text-decoration-thickness: initial; text-decoration=
-style: initial; text-decoration-color: initial;"><br></div><div style=3D"c=
olor: #000000; font-family: arial, helvetica, sans-serif; font-size: 16px; =
font-style: normal; font-variant-ligatures: normal; font-variant-caps: norm=
al; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start=
; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -we=
bkit-text-stroke-width: 0px; white-space: normal; background-color: #fdfcfa=
; text-decoration-thickness: initial; text-decoration-style: initial; text-=
decoration-color: initial;" data-mce-style=3D"color: #000000; font-family: =
arial, helvetica, sans-serif; font-size: 16px; font-style: normal; font-var=
iant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter=
-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-tra=
nsform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px;=
 white-space: normal; background-color: #fdfcfa; text-decoration-thickness:=
 initial; text-decoration-style: initial; text-decoration-color: initial;">=
I started looking at the file xen/arch/x86/cpuid.c but don't really know wh=
ich other&nbsp;</div><div style=3D"color: #000000; font-family: arial, helv=
etica, sans-serif; font-size: 16px; font-style: normal; font-variant-ligatu=
res: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: n=
ormal; orphans: 2; text-align: start; text-indent: 0px; text-transform: non=
e; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-spac=
e: normal; background-color: #fdfcfa; text-decoration-thickness: initial; t=
ext-decoration-style: initial; text-decoration-color: initial;" data-mce-st=
yle=3D"color: #000000; font-family: arial, helvetica, sans-serif; font-size=
: 16px; font-style: normal; font-variant-ligatures: normal; font-variant-ca=
ps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-alig=
n: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: =
0px; -webkit-text-stroke-width: 0px; white-space: normal; background-color:=
 #fdfcfa; text-decoration-thickness: initial; text-decoration-style: initia=
l; text-decoration-color: initial;">files to check next.&nbsp;</div><div st=
yle=3D"color: #000000; font-family: arial, helvetica, sans-serif; font-size=
: 16px; font-style: normal; font-variant-ligatures: normal; font-variant-ca=
ps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-alig=
n: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: =
0px; -webkit-text-stroke-width: 0px; white-space: normal; background-color:=
 #fdfcfa; text-decoration-thickness: initial; text-decoration-style: initia=
l; text-decoration-color: initial;" data-mce-style=3D"color: #000000; font-=
family: arial, helvetica, sans-serif; font-size: 16px; font-style: normal; =
font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400=
; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; =
text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-wid=
th: 0px; white-space: normal; background-color: #fdfcfa; text-decoration-th=
ickness: initial; text-decoration-style: initial; text-decoration-color: in=
itial;"><br></div><div style=3D"color: #000000; font-family: arial, helveti=
ca, sans-serif; font-size: 16px; font-style: normal; font-variant-ligatures=
: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: norm=
al; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; =
widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: =
normal; background-color: #fdfcfa; text-decoration-thickness: initial; text=
-decoration-style: initial; text-decoration-color: initial;" data-mce-style=
=3D"color: #000000; font-family: arial, helvetica, sans-serif; font-size: 1=
6px; font-style: normal; font-variant-ligatures: normal; font-variant-caps:=
 normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: =
start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px=
; -webkit-text-stroke-width: 0px; white-space: normal; background-color: #f=
dfcfa; text-decoration-thickness: initial; text-decoration-style: initial; =
text-decoration-color: initial;">Thanks</div><div style=3D"color: #000000; =
font-family: arial, helvetica, sans-serif; font-size: 16px; font-style: nor=
mal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight=
: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: =
0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-strok=
e-width: 0px; white-space: normal; background-color: #fdfcfa; text-decorati=
on-thickness: initial; text-decoration-style: initial; text-decoration-colo=
r: initial;" data-mce-style=3D"color: #000000; font-family: arial, helvetic=
a, sans-serif; font-size: 16px; font-style: normal; font-variant-ligatures:=
 normal; font-variant-caps: normal; font-weight: 400; letter-spacing: norma=
l; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; w=
idows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: n=
ormal; background-color: #fdfcfa; text-decoration-thickness: initial; text-=
decoration-style: initial; text-decoration-color: initial;"><br></div><div =
style=3D"color: #000000; font-family: arial, helvetica, sans-serif; font-si=
ze: 16px; font-style: normal; font-variant-ligatures: normal; font-variant-=
caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-al=
ign: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing=
: 0px; -webkit-text-stroke-width: 0px; white-space: normal; background-colo=
r: #fdfcfa; text-decoration-thickness: initial; text-decoration-style: init=
ial; text-decoration-color: initial;" data-mce-style=3D"color: #000000; fon=
t-family: arial, helvetica, sans-serif; font-size: 16px; font-style: normal=
; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 4=
00; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px=
; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-w=
idth: 0px; white-space: normal; background-color: #fdfcfa; text-decoration-=
thickness: initial; text-decoration-style: initial; text-decoration-color: =
initial;">Caleb</div></div></body></html>
--=_87ed86ca-dcae-4c7f-b4d9-51ed8a12c060--


From xen-devel-bounces@lists.xenproject.org Fri Jan 03 14:35:53 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Jan 2025 14:35:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864588.1275797 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTimC-0000G8-Nh; Fri, 03 Jan 2025 14:35:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864588.1275797; Fri, 03 Jan 2025 14:35:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTimC-0000G1-K0; Fri, 03 Jan 2025 14:35:48 +0000
Received: by outflank-mailman (input) for mailman id 864588;
 Fri, 03 Jan 2025 14:35:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=/LDK=T3=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tTimB-0000Fv-RK
 for xen-devel@lists.xenproject.org; Fri, 03 Jan 2025 14:35:47 +0000
Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com
 [2a00:1450:4864:20::442])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 044d1d15-c9e0-11ef-99a4-01e77a169b0f;
 Fri, 03 Jan 2025 15:35:45 +0100 (CET)
Received: by mail-wr1-x442.google.com with SMTP id
 ffacd0b85a97d-3862f32a33eso5656472f8f.3
 for <xen-devel@lists.xenproject.org>; Fri, 03 Jan 2025 06:35:45 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c89e1cesm40194122f8f.64.2025.01.03.06.35.44
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 03 Jan 2025 06:35:44 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 044d1d15-c9e0-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1735914945; x=1736519745; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=AESKNlhnzuZs4LmrZTXcE21Egr7lFwXw0Psiio56vM8=;
        b=QqNox/NO/X4+ftmU5J4hkJ3WxfyWFNGhFMBg+kwQkQ9sN7tkxdnuJtFSoV9SQUQ+tu
         J9d4wZtJvh76xFDF698qabmhRyjmOcyOySlIWoq8GZpXvD0dZqX7rYpGF22zf/aqIFdU
         XSfhFXHGfrCKJH5ZjpjPC5VM870K4IU2EvmiE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735914945; x=1736519745;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=AESKNlhnzuZs4LmrZTXcE21Egr7lFwXw0Psiio56vM8=;
        b=L1W12GKzpbjEbUwwbMa5QOSBtY9Qi7yB4Bfv07kLRtuZpjxqH68JdcLoZlWmOHSFGN
         YnmziNyIYO3IsXfZbwqC8ZqmcfjZsd87ogKzog+JJ9bq2VLtH78cx09xZXh9lSMAuVe9
         tsdzOtHPkQb0scFMF/CQHaUuft/87ALgk68+S2phXskF+YkGxDnmDvncZJ3Bk4ReoHav
         0O6AFyyXMILcXK0GIzykpajCYJhdn637LIqaexJ8dxGkqxWUomVs26jBJn8zsirh4y7b
         El2Nhzcvk5IaBpGD1RqkH/fE/FC/5UrULS2CI0sSTi3sEmaxgTzyG+YxptYHFOS4t+PM
         ibjA==
X-Forwarded-Encrypted: i=1; AJvYcCV5oGmx0E/EGlAXxvfBbFGNvb0sVs0fNX9AiyDgiLnQkLNLDD69xwxilEDbaNGik+Nl6K73HOLTSd4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyQrJA7cLbBWvNSGVOCtMamqYkRtwl1pnf2SvOHyS169LfDd5P6
	L8h7caP9MFOwfgPUP3EXoHKCiXz6kGpq4g9VUM/7iaYxXXp1Kqll5tYBpoHIzsw=
X-Gm-Gg: ASbGncthtXsH7PT+C4DyJlhZdD4J1sWvkwNUM3a2bNARaSLRXEiDWhOCrdkz/I2kOIa
	ML+nOV2wkXzh2cks+ZRw8c6M0vxHTm7yrZ+6pDF9s5lmiDdYGMP9tI5wi2YUTHSVmxMXIuBDVIX
	KC+OxrSArwZPf9cygNMclYrF9DVEbCJXBe7RqrWfvk154XGTdSz2Yfly0Zcnx5rTRWXW/dS6tGk
	4jtd3wugpwHK2G2vMuUm+zVvHohN8AKdx8RtFj8qRs4Dlr/4QHGcwJhdWVB16VdgQ7pkD+1Zc75
	qAoRfA/TyNWTHniZtMwo
X-Google-Smtp-Source: AGHT+IF9qgjnG6Kldw5MGD8jbzpXY7807DEMYQfQW/zRCl3P1sZOw22sEHsiDKxQIvTLPFL8/5lmXQ==
X-Received: by 2002:adf:ab0a:0:b0:38a:50fa:d582 with SMTP id ffacd0b85a97d-38a50faf3cemr14748653f8f.59.1735914944918;
        Fri, 03 Jan 2025 06:35:44 -0800 (PST)
Message-ID: <41b0f409-6bb3-4338-86b5-0d91dc82294e@citrix.com>
Date: Fri, 3 Jan 2025 14:35:43 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Help With Identifying CPUID faulting logic in Xen code
To: Fonyuy-Asheri Caleb <fonyuy-asheri.caleb@inria.fr>,
 xen-devel <xen-devel@lists.xenproject.org>
Cc: Jan Beulich <jbeulich@suse.com>
References: <944938302.6053932.1735914346495.JavaMail.zimbra@inria.fr>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <944938302.6053932.1735914346495.JavaMail.zimbra@inria.fr>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 03/01/2025 2:25 pm, Fonyuy-Asheri Caleb wrote:
> Hello,
>
> I am interested in finding understanding how xen handles CPUID
> faulting and 
> VM exits in general. Please can someone indicate to me the concerned
> files? 
>
> I want to know how xen detects the execution of the CPUID instruction and 
> ensures a guest only gets the features defined in cpuid-autogen.h file 
> depending on the guest type. 
>
> I started looking at the file xen/arch/x86/cpuid.c but don't really
> know which other 
> files to check next.

https://xenbits.xen.org/docs/unstable/features/feature-levelling.html

has a reasonable introduction.  Being nearly a decade old, it's slightly
stale.  AMD now have CPUID Faulting capability too, new in Zen4 CPUs IIRC.

LCAP_faulting specifically is the constant you're looking for, in the
Xen code.

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri Jan 03 14:54:51 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Jan 2025 14:54:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864596.1275806 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTj4S-0003Cb-68; Fri, 03 Jan 2025 14:54:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864596.1275806; Fri, 03 Jan 2025 14:54:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTj4S-0003CU-3G; Fri, 03 Jan 2025 14:54:40 +0000
Received: by outflank-mailman (input) for mailman id 864596;
 Fri, 03 Jan 2025 14:54: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
 <SRS0=o5mg=T3=inria.fr=fonyuy-asheri.caleb@srs-se1.protection.inumbo.net>)
 id 1tTj4R-0003CO-3U
 for xen-devel@lists.xenproject.org; Fri, 03 Jan 2025 14:54:39 +0000
Received: from mail2-relais-roc.national.inria.fr
 (mail2-relais-roc.national.inria.fr [192.134.164.83])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a71144c2-c9e2-11ef-a0de-8be0dac302b0;
 Fri, 03 Jan 2025 15:54:37 +0100 (CET)
Received: from zcs2-store8.inria.fr ([128.93.142.6])
 by mail2-relais-roc.national.inria.fr with ESMTP; 03 Jan 2025 15:54:37 +0100
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a71144c2-c9e2-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=inria.fr; s=dc;
  h=date:from:to:cc:message-id:in-reply-to:references:
   subject:mime-version:content-transfer-encoding;
  bh=Bu869Luex93ZoeuFnvK8aXOZYRKKj35Bd+lBf6FveB8=;
  b=DiayYoe659NYrMqJCIpm8zrEC7Y4KIUr9bwodVTFn6a8tJP6I/gJT3k/
   eLDPWHt3QQaM9BBOch/CxS1tww8KlxLbanafNNa8reVdxuJJ+SQeZbZB3
   URnlgfyegy/2e8JH9mk/XlO1G5fZicTsXPfZWOcNJntUF+2PbqZH0BBg/
   M=;
Authentication-Results: mail2-relais-roc.national.inria.fr; dkim=none (message not signed) header.i=none; spf=Pass smtp.mailfrom=fonyuy-asheri.caleb@inria.fr; spf=None smtp.helo=postmaster@zcs2-store8.inria.fr
Received-SPF: Pass (mail2-relais-roc.national.inria.fr: domain of
  fonyuy-asheri.caleb@inria.fr designates 128.93.142.6 as
  permitted sender) identity=mailfrom; client-ip=128.93.142.6;
  receiver=mail2-relais-roc.national.inria.fr;
  envelope-from="fonyuy-asheri.caleb@inria.fr";
  x-sender="fonyuy-asheri.caleb@inria.fr";
  x-conformance=spf_only; x-record-type="v=spf1";
  x-record-text="v=spf1 include:mailout.safebrands.com
  a:basic-mail.safebrands.com a:basic-mail01.safebrands.com
  a:basic-mail02.safebrands.com ip4:128.93.142.0/24
  ip4:192.134.164.0/24 ip4:128.93.162.160 ip4:128.93.162.3
  ip4:128.93.162.88 ip4:89.107.174.7 mx ~all"
Received-SPF: None (mail2-relais-roc.national.inria.fr: no sender
  authenticity information available from domain of
  postmaster@zcs2-store8.inria.fr) identity=helo;
  client-ip=128.93.142.6;
  receiver=mail2-relais-roc.national.inria.fr;
  envelope-from="fonyuy-asheri.caleb@inria.fr";
  x-sender="postmaster@zcs2-store8.inria.fr";
  x-conformance=spf_only
X-IronPort-AV: E=Sophos;i="6.12,286,1728943200"; 
   d="scan'208";a="201343816"
X-MGA-submission: =?us-ascii?q?MDElzuM4PrhzS2CJFIM9ZGhE6T6c51W+nIwVpu?=
 =?us-ascii?q?6HTW7IXVLUzcKTCnBHi/5gnp93PzBbAIx88T7DwQRr/UMb4Z5p8GAVBL?=
 =?us-ascii?q?U7uEmiOfGGR26CQaVsAoYXZLT81z/1I3bogKUXsR4NmrUxiKhcWx9Hjd?=
 =?us-ascii?q?xpanalxVWwXbe2U1F/qCe/tg=3D=3D?=
Date: Fri, 3 Jan 2025 15:54:36 +0100 (CET)
From: Fonyuy-Asheri Caleb <fonyuy-asheri.caleb@inria.fr>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>, Jan Beulich <jbeulich@suse.com>
Message-ID: <708460948.6067319.1735916076826.JavaMail.zimbra@inria.fr>
In-Reply-To: <41b0f409-6bb3-4338-86b5-0d91dc82294e@citrix.com>
References: <944938302.6053932.1735914346495.JavaMail.zimbra@inria.fr> <41b0f409-6bb3-4338-86b5-0d91dc82294e@citrix.com>
Subject: Re: Help With Identifying CPUID faulting logic in Xen code
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [176.180.88.57]
X-Mailer: Zimbra 10.1.3_GA_4699 (ZimbraWebClient - GC131 (Linux)/10.1.3_GA_4703)
Thread-Topic: Help With Identifying CPUID faulting logic in Xen code
Thread-Index: 4vCuNNMKP2rZVnEZw6zI2pCjBVj3Aw==

Thank you

Caleb

----- Original Message -----
> From: "Andrew Cooper" <andrew.cooper3@citrix.com>
> To: "Fonyuy-Asheri Caleb" <fonyuy-asheri.caleb@inria.fr>, "xen-devel" <xe=
n-devel@lists.xenproject.org>
> Cc: "Jan Beulich" <jbeulich@suse.com>
> Sent: Friday, January 3, 2025 3:35:43 PM
> Subject: Re: Help With Identifying CPUID faulting logic in Xen code

> On 03/01/2025 2:25 pm, Fonyuy-Asheri Caleb wrote:
>> Hello,
>>
>> I am interested in finding understanding how xen handles CPUID
>> faulting and
>> VM exits in general. Please can someone indicate to me the concerned
>> files?
>>
>> I want to know how xen detects the execution of the CPUID instruction an=
d
>> ensures a guest only gets the features defined in cpuid-autogen.h file
>> depending on the guest type.
>>
>> I started looking at the file xen/arch/x86/cpuid.c but don't really
>> know which other
>> files to check next.
>=20
> https://xenbits.xen.org/docs/unstable/features/feature-levelling.html
>=20
> has a reasonable introduction.=A0 Being nearly a decade old, it's slightl=
y
> stale.=A0 AMD now have CPUID Faulting capability too, new in Zen4 CPUs II=
RC.
>=20
> LCAP_faulting specifically is the constant you're looking for, in the
> Xen code.
>=20
> ~Andrew


From xen-devel-bounces@lists.xenproject.org Fri Jan 03 18:10:38 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Jan 2025 18:10:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864611.1275816 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTm7j-0002jc-ME; Fri, 03 Jan 2025 18:10:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864611.1275816; Fri, 03 Jan 2025 18:10:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTm7j-0002jV-JT; Fri, 03 Jan 2025 18:10:15 +0000
Received: by outflank-mailman (input) for mailman id 864611;
 Fri, 03 Jan 2025 18:10: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
 <SRS0=LdeY=T3=invisiblethingslab.com=marmarek@srs-se1.protection.inumbo.net>)
 id 1tTm7h-0002jP-PH
 for xen-devel@lists.xenproject.org; Fri, 03 Jan 2025 18:10:13 +0000
Received: from flow-b2-smtp.messagingengine.com
 (flow-b2-smtp.messagingengine.com [202.12.124.137])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f6f54335-c9fd-11ef-99a4-01e77a169b0f;
 Fri, 03 Jan 2025 19:10:08 +0100 (CET)
Received: from phl-compute-12.internal (phl-compute-12.phl.internal
 [10.202.2.52])
 by mailflow.stl.internal (Postfix) with ESMTP id 115A61D40989;
 Fri,  3 Jan 2025 13:10:06 -0500 (EST)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-12.internal (MEProxy); Fri, 03 Jan 2025 13:10:07 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri,
 3 Jan 2025 13:09:54 -0500 (EST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f6f54335-c9fd-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm2; t=1735927805;
	 x=1735935005; bh=hJC8t2zQcYbMlocgzOTCoo+YKCbPjNASrYrXMiYm4gQ=; b=
	nWR4vMgAWYHOnuUE+AJAAZLXtSrvbQMw7WdfA5d1lmXvuzGrotvbi2D6WFzT51WL
	kDyRgLgVWqG/xDKKq24hyZSosMxxFT9fjKN6txsx69kzyJgOZg+WsycpXhkWa2EC
	SsiXQkhL+10tHMA0qZujbB0C/JdpeF813Ll/qnqbhzqMOVTDQv5gJ3J6NLPD4r9N
	z22r9QMRv4WXpcPE/P8sNOG/01eVD9m8xXrWZ8u9+pwLeqY6nyfn2dODvCZGIvax
	Jd65aAIBAv4CFKI+vmwBV99zunvBXT095w2r8nOzzzG1Aix80V2EdfRJAkaz6+Pb
	doPZUYwJMntgn0Nw4jSXYg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:subject:subject:to
	:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=
	1735927805; x=1735935005; bh=hJC8t2zQcYbMlocgzOTCoo+YKCbPjNASrYr
	XMiYm4gQ=; b=FVX/4JQ6/hDpukqzLVB498nsl+dAQ2hqMzxVbYbfyLFf6pNmHZ0
	Qm1v2Qioq7eKVnu2jU4qiUKnHjpR7PcbeC1WDiFE5Hcp/pUiWadCIFdG9rVqU17S
	eKT3iX8Al4xlCnx33EgxkueGOiYIvdth/mVHxr36KgBJaotUCu9CYx3Yg2nZDvsi
	05o0268nkfqSf9dtIqnFru/poM8ZBsa4Fp7aXOMEGY5mqpcBJ0yAB30dWD1IJqYW
	cQYPzILQBy3vNCQhyOOquXf8mym8Iqqeacsi7BL/3L2AgKUAle9pmWgqOHs0Pgov
	CuqvCsos84/aKgqEQxq0uwx+EaFYo0x7mJg==
X-ME-Sender: <xms:-Cd4Z15f1xIQfpPO0smZv12rLJjQS_EJRWUhK3qEWlneckwrq87Cnw>
    <xme:-Cd4Zy4rADzaOmrLPBTrEpukg6Vhr7QI_MPFmZ_TlR1FNuufELYnFn6mhMmAaSGIU
    H-fFHm7vFYzOg>
X-ME-Received: <xmr:-Cd4Z8cOplyiW2PNOcLdmR4VdYeWrdlpzdfxJhUJ90cWnJpIcq2_DiGKBHYod49XrLkFXpm-yn1NKJ85FTQPSDz0gIAtCf3Lug>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrudefgedguddtlecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp
    uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg
    hnthhsucdlqddutddtmdenucfjughrpeffhffvvefukfhfgggtuggjsehgtderredttdej
    necuhfhrohhmpeforghrvghkucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoe
    hmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucgg
    tffrrghtthgvrhhnpedvieegfefgieejuedutefhffehjeegjeevuedtgeduteeujeetve
    evudevieffkeenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhkvghrnhgvlhdrohhr
    ghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrg
    hrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgt
    phhtthhopeegiedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtoheprghnughrvgifrd
    gtohhophgvrhefsegtihhtrhhigidrtghomhdprhgtphhtthhopehjghhrohhsshesshhu
    shgvrdgtohhmpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprh
    hojhgvtghtrdhorhhgpdhrtghpthhtoheprhhpphhtsehkvghrnhgvlhdrohhrghdprhgt
    phhtthhopehmtghgrhhofheskhgvrhhnvghlrdhorhhgpdhrtghpthhtoheprghnughrvg
    grshesghgrihhslhgvrhdrtghomhdprhgtphhtthhopehluhhtoheskhgvrhhnvghlrdho
    rhhgpdhrtghpthhtoheprghruggssehkvghrnhgvlhdrohhrghdprhgtphhtthhopegrrh
    hnugesrghrnhgusgdruggv
X-ME-Proxy: <xmx:-Sd4Z-KAUhq2X0L9XNWyJO9uVkNjB2r6gPlGFNkS7Tf5e769w0xX_g>
    <xmx:-Sd4Z5Kwh13Y2kBuLklSyhuIJz97TKYw5o86myQHtXPYLYrfheT8pg>
    <xmx:-Sd4Z3z2554qiJNt6-bnTDrDhXLJfOmjP0nn_AitLPo6WwVlExi4pQ>
    <xmx:-Sd4Z1LsJEVr8F-etn214vHiFYfpBfE6lOsMiuAIWgYxt9o2EW57jA>
    <xmx:_Sd4ZzU53v6VA8DAcu73R1QFsItRDYKJpR6qP544GLh_e7jeuEDZbfVJ>
Feedback-ID: i1568416f:Fastmail
Date: Fri, 3 Jan 2025 19:09:52 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Mike Rapoport <rppt@kernel.org>,	Luis Chamberlain <mcgrof@kernel.org>,
	Andreas Larsson <andreas@gaisler.com>,	Andy Lutomirski <luto@kernel.org>,
 Ard Biesheuvel <ardb@kernel.org>,	Arnd Bergmann <arnd@arndb.de>,
 Borislav Petkov <bp@alien8.de>,	Brian Cain <bcain@quicinc.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Christophe Leroy <christophe.leroy@csgroup.eu>,
	Christoph Hellwig <hch@lst.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Dinh Nguyen <dinguyen@kernel.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,	Guo Ren <guoren@kernel.org>,
 Helge Deller <deller@gmx.de>,	Huacai Chen <chenhuacai@kernel.org>,
 Ingo Molnar <mingo@redhat.com>,
	Johannes Berg <johannes@sipsolutions.net>,
	John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
	Kent Overstreet <kent.overstreet@linux.dev>,
	"Liam R. Howlett" <Liam.Howlett@oracle.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Masami Hiramatsu <mhiramat@kernel.org>,	Matt Turner <mattst88@gmail.com>,
 Max Filippov <jcmvbkbc@gmail.com>,	Michael Ellerman <mpe@ellerman.id.au>,
	Michal Simek <monstr@monstr.eu>, Oleg Nesterov <oleg@redhat.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Richard Weinberger <richard@nod.at>,
	Russell King <linux@armlinux.org.uk>, Song Liu <song@kernel.org>,
	Stafford Horne <shorne@gmail.com>,	Steven Rostedt <rostedt@goodmis.org>,
	Suren Baghdasaryan <surenb@google.com>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	Uladzislau Rezki <urezki@gmail.com>,	Vineet Gupta <vgupta@kernel.org>,
 Will Deacon <will@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: Linux 6.13-rc5 Xen HVM with PCI passthrough (USB controller)
 crash
Message-ID: <Z3gn8OD6a5weneAM@mail-itl>
References: <Z2RGfpJkO0z_nKV6@mail-itl>
 <ab9c27d5-f3f2-4b8a-960d-f880ec136199@suse.com>
 <6bb03333-74ca-4c2c-85a8-72549b85a5b4@suse.com>
 <Z3aFdrygLF9yK2EK@mail-itl>
 <Z3bg-gvaBEdSIuRW@mail-itl>
 <08f9604b-df23-4766-a290-ef9daa506f8d@suse.com>
 <Z3brZQmYhx-QTnga@mail-itl>
 <Z3cs1-wG5WJ9FrAR@mail-itl>
 <Z3cyhdKu6M1vdBe_@mail-itl>
 <b4b2229f-a139-4cfe-9cb1-e218b7123c08@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="1kggHxHjQ/xzifQq"
Content-Disposition: inline
In-Reply-To: <b4b2229f-a139-4cfe-9cb1-e218b7123c08@citrix.com>


--1kggHxHjQ/xzifQq
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Fri, 3 Jan 2025 19:09:52 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Mike Rapoport <rppt@kernel.org>,	Luis Chamberlain <mcgrof@kernel.org>,
	Andreas Larsson <andreas@gaisler.com>,	Andy Lutomirski <luto@kernel.org>,
 Ard Biesheuvel <ardb@kernel.org>,	Arnd Bergmann <arnd@arndb.de>,
 Borislav Petkov <bp@alien8.de>,	Brian Cain <bcain@quicinc.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Christophe Leroy <christophe.leroy@csgroup.eu>,
	Christoph Hellwig <hch@lst.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Dinh Nguyen <dinguyen@kernel.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,	Guo Ren <guoren@kernel.org>,
 Helge Deller <deller@gmx.de>,	Huacai Chen <chenhuacai@kernel.org>,
 Ingo Molnar <mingo@redhat.com>,
	Johannes Berg <johannes@sipsolutions.net>,
	John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
	Kent Overstreet <kent.overstreet@linux.dev>,
	"Liam R. Howlett" <Liam.Howlett@oracle.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Masami Hiramatsu <mhiramat@kernel.org>,	Matt Turner <mattst88@gmail.com>,
 Max Filippov <jcmvbkbc@gmail.com>,	Michael Ellerman <mpe@ellerman.id.au>,
	Michal Simek <monstr@monstr.eu>, Oleg Nesterov <oleg@redhat.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Richard Weinberger <richard@nod.at>,
	Russell King <linux@armlinux.org.uk>, Song Liu <song@kernel.org>,
	Stafford Horne <shorne@gmail.com>,	Steven Rostedt <rostedt@goodmis.org>,
	Suren Baghdasaryan <surenb@google.com>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	Uladzislau Rezki <urezki@gmail.com>,	Vineet Gupta <vgupta@kernel.org>,
 Will Deacon <will@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: Linux 6.13-rc5 Xen HVM with PCI passthrough (USB controller)
 crash

On Fri, Jan 03, 2025 at 02:00:28AM +0000, Andrew Cooper wrote:
> On 03/01/2025 12:42 am, Marek Marczykowski-G=C3=B3recki wrote:
> > On Fri, Jan 03, 2025 at 01:18:31AM +0100, Marek Marczykowski-G=C3=B3rec=
ki wrote:
> >> On Thu, Jan 02, 2025 at 08:39:16PM +0100, Marek Marczykowski-G=C3=B3re=
cki wrote:
> >>> On Thu, Jan 02, 2025 at 08:17:00PM +0100, J=C3=BCrgen Gro=C3=9F wrote:
> >>>> On 02.01.25 19:54, Marek Marczykowski-G=C3=B3recki wrote:
> >>>>> There is
> >>>>> one issue (likely unrelated to this change) - sys-usb (HVM domU wit=
h USB
> >>>>> controllers passed through) crashes on a system with Raptor Lake CPU
> >>>>> (only, others, including ADL and MTL look fine):
> >> Correction, it does happen on some others too, just got the crash on t=
he ADL
> >> system, although looks a bit different ("Corrupted page table at ..."):
> > I've collected some more of them at https://github.com/QubesOS/qubes-is=
sues/issues/9681
> >
> > Should I start new thread for this? On one hand, it's a different domain
> > type (HVM), but on the other hand, many of the crashes are around
> > loading modules too.
>=20
> https://lore.kernel.org/lkml/20241227072825.1288491-1-rppt@kernel.org/T/#t
> looks relevant.=C2=A0 Probably worth following up.

As responded there, I don't think so, as that series is not part of
6.13-rc5. But in the meantime, I bisected it and got this commit:

5185e7f9f3bd754ab60680814afd714e2673ef88 is the first bad commit
commit 5185e7f9f3bd754ab60680814afd714e2673ef88
Author: Mike Rapoport (Microsoft) <rppt@kernel.org>
Date:   Wed Oct 23 19:27:11 2024 +0300

    x86/module: enable ROX caches for module text on 64 bit
   =20
    Enable execmem's cache of PMD_SIZE'ed pages mapped as ROX for module te=
xt
    allocations on 64 bit.
   =20
    Link: https://lkml.kernel.org/r/20241023162711.2579610-9-rppt@kernel.org
    Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
    Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
    Tested-by: kdevops <kdevops@lists.linux.dev>
    Cc: Andreas Larsson <andreas@gaisler.com>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Ard Biesheuvel <ardb@kernel.org>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Borislav Petkov (AMD) <bp@alien8.de>
    Cc: Brian Cain <bcain@quicinc.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: Dinh Nguyen <dinguyen@kernel.org>
    Cc: Geert Uytterhoeven <geert@linux-m68k.org>
    Cc: Guo Ren <guoren@kernel.org>
    Cc: Helge Deller <deller@gmx.de>
    Cc: Huacai Chen <chenhuacai@kernel.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Johannes Berg <johannes@sipsolutions.net>
    Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
    Cc: Kent Overstreet <kent.overstreet@linux.dev>
    Cc: Liam R. Howlett <Liam.Howlett@Oracle.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Cc: Matt Turner <mattst88@gmail.com>
    Cc: Max Filippov <jcmvbkbc@gmail.com>
    Cc: Michael Ellerman <mpe@ellerman.id.au>
    Cc: Michal Simek <monstr@monstr.eu>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Palmer Dabbelt <palmer@dabbelt.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Richard Weinberger <richard@nod.at>
    Cc: Russell King <linux@armlinux.org.uk>
    Cc: Song Liu <song@kernel.org>
    Cc: Stafford Horne <shorne@gmail.com>
    Cc: Steven Rostedt (Google) <rostedt@goodmis.org>
    Cc: Suren Baghdasaryan <surenb@google.com>
    Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Uladzislau Rezki (Sony) <urezki@gmail.com>
    Cc: Vineet Gupta <vgupta@kernel.org>
    Cc: Will Deacon <will@kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

 arch/x86/Kconfig   |  1 +
 arch/x86/mm/init.c | 37 ++++++++++++++++++++++++++++++++++++-
 2 files changed, 37 insertions(+), 1 deletion(-)

I'm extending CC...

See initial quoted part for the issue description, and link to collected
crash messages.

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

--1kggHxHjQ/xzifQq
Content-Type: application/pgp-signature; name="signature.asc"

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmd4J/AACgkQ24/THMrX
1yy8hwf/dh/cbJsxOpO9qk6DZ9yCsUt8k6TENfOX9GsohEU1usjUmLGQ2+oTrjbY
uzuEzz1XEhogb/Q298CxIKqn3QD6txnFZG/ppKTBPcoS1jLHWdc+9qpzvr5+OhEO
+ejbdThVXlZEOXrtqdXXGNpNX288uHnkzKDulw/itqj0zemqvZMJIg4wFU1ROYGI
5Utd1eULz1xWeuV0xaSAud0aVG5VSF+pCL+nOd77FRh2uuM5N2sitnpJX89bTCmy
Elb5t8eh4PN7Dv1SWzhWWMgZq6ecD3KijinnDORKZucJIILB0/GGozyRpbMzDE/y
7YgaU2WrACxmNxsW1MIgAThYFnfeGQ==
=d/90
-----END PGP SIGNATURE-----

--1kggHxHjQ/xzifQq--


From xen-devel-bounces@lists.xenproject.org Fri Jan 03 18:33:10 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Jan 2025 18:33:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864620.1275826 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTmTn-0005nZ-EH; Fri, 03 Jan 2025 18:33:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864620.1275826; Fri, 03 Jan 2025 18:33:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTmTn-0005nS-Be; Fri, 03 Jan 2025 18:33:03 +0000
Received: by outflank-mailman (input) for mailman id 864620;
 Fri, 03 Jan 2025 18:33:02 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=ayzF=T3=gmail.com=geert.uytterhoeven@srs-se1.protection.inumbo.net>)
 id 1tTmTm-0005nM-QG
 for xen-devel@lists.xenproject.org; Fri, 03 Jan 2025 18:33:02 +0000
Received: from mail-vs1-f54.google.com (mail-vs1-f54.google.com
 [209.85.217.54]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 28cc483f-ca01-11ef-99a4-01e77a169b0f;
 Fri, 03 Jan 2025 19:33:00 +0100 (CET)
Received: by mail-vs1-f54.google.com with SMTP id
 ada2fe7eead31-4afe6a8d2e1so6618044137.1
 for <xen-devel@lists.xenproject.org>; Fri, 03 Jan 2025 10:33:00 -0800 (PST)
Received: from mail-vs1-f52.google.com (mail-vs1-f52.google.com.
 [209.85.217.52]) by smtp.gmail.com with ESMTPSA id
 ada2fe7eead31-4b2bf98ee73sm5781514137.1.2025.01.03.10.32.55
 for <xen-devel@lists.xenproject.org>
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 03 Jan 2025 10:32:56 -0800 (PST)
Received: by mail-vs1-f52.google.com with SMTP id
 ada2fe7eead31-4aff1c57377so6704892137.0
 for <xen-devel@lists.xenproject.org>; Fri, 03 Jan 2025 10:32:55 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 28cc483f-ca01-11ef-99a4-01e77a169b0f
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735929178; x=1736533978;
        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=puPJTtoESUJcppwT4hmEcdnIo/YZOWUajNX8x0J/UiA=;
        b=LYyoG0HVHOiU+3LRQhANvPHD1A7RhU7AVVqi6TZh7SfhutSYiKJXfTnSTdOU4iw3Ws
         akdtLO/AKGiAQFCA456YBDwHVvxSoBPd95alwXOvlbTaKZqHVZx4GXJSeIJPKHyB2258
         NHJV248x9xj2alsIooKChCj9kOPpvtFJ9b/w6bh5bLt24jXi6YTnt12HjrD6PrjjcFpw
         mVH4ddrX3V6t4fMOh3Qoga1VIL16k0g7QjwevIOXYCqgJjrOTrk0RV07luvDRP/p/WtS
         NVSnKrY8r6ez4rJsCDNstRBHZPMUIQDfykc9gBHqJz3D4ly2X1TzyR+mJXqgkFrYs8tF
         tmVA==
X-Forwarded-Encrypted: i=1; AJvYcCU6+O/wLtUXl/ix2HVJNDCXw6JHiKjdPUPhCfwWiH2PipNg0PN1cs+5JzIDHPmogJ30Gi+807H1IFk=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxim0HztQMy+UYr1uYTwOLJmo2jp3whj7MXpamP4YpcBnnitRoW
	bb24Soz84V94WKo/wOYeRaEP5GNisPlLoQpvpRIENG2e9K6TkXF1A6OfSzmLosQ=
X-Gm-Gg: ASbGncvee3g5pyn50KGfZtiEU2aJOR6sMigEbsgDSgBCuZFrQwFGVyFhzvIj1WihmFs
	yHx7k+iRCcPxQTusw94iKdJDeRENK3VQictPq/AbkUnIGSsanVaO3Vrj80Pl8KyDfWefimHTAK3
	q1N4efRtpW1louOb2++OeW6BjgD5VpF9vBPW9fePHOKzMrGANWqfips0OdP/ZEbZlLkpUneLkmR
	9y047G84evXPnlagDYpo5U6iLyCl9pGsLectfOuDxU1ZIYJsHBMSleIxVtpkJe1aKJN9npN0e28
	zzTal+D0EMAIeR8oChs=
X-Google-Smtp-Source: AGHT+IH6+HqCh6UllxGrBtNLZz6FDQlusgUozrspl2LTSH5UTXbcXg5fOQKXCue3hKqlpAuwzeEO7Q==
X-Received: by 2002:a05:6102:26cf:b0:4af:cb0c:390b with SMTP id ada2fe7eead31-4b2cd718373mr41873162137.7.1735929178101;
        Fri, 03 Jan 2025 10:32:58 -0800 (PST)
X-Forwarded-Encrypted: i=1; AJvYcCU6hb/Gn6WcD4voUwkvP8wopDrkievfGB6qagZ8w4r2wB3KpkEq63rKhD2CAvFJP85BLZ9fGht5xno=@lists.xenproject.org
X-Received: by 2002:a05:6102:589b:b0:4b2:5c4b:b32a with SMTP id
 ada2fe7eead31-4b2bc1258a6mr38271366137.12.1735929174831; Fri, 03 Jan 2025
 10:32:54 -0800 (PST)
MIME-Version: 1.0
References: <Z2RGfpJkO0z_nKV6@mail-itl> <ab9c27d5-f3f2-4b8a-960d-f880ec136199@suse.com>
 <6bb03333-74ca-4c2c-85a8-72549b85a5b4@suse.com> <Z3aFdrygLF9yK2EK@mail-itl>
 <Z3bg-gvaBEdSIuRW@mail-itl> <08f9604b-df23-4766-a290-ef9daa506f8d@suse.com>
 <Z3brZQmYhx-QTnga@mail-itl> <Z3cs1-wG5WJ9FrAR@mail-itl> <Z3cyhdKu6M1vdBe_@mail-itl>
 <b4b2229f-a139-4cfe-9cb1-e218b7123c08@citrix.com> <Z3gn8OD6a5weneAM@mail-itl>
In-Reply-To: <Z3gn8OD6a5weneAM@mail-itl>
From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: Fri, 3 Jan 2025 19:32:43 +0100
X-Gmail-Original-Message-ID: <CAMuHMdX-iMzh+R0-tquz5Jb0Q0dhSOd-f3NmrOzUy_k4xiq_hA@mail.gmail.com>
X-Gm-Features: AbW1kvZZaP-dmLLikfdz34d5LDNGV7YpoF8SIsL5yKm6srCyil7MkqMAFaogJr0
Message-ID: <CAMuHMdX-iMzh+R0-tquz5Jb0Q0dhSOd-f3NmrOzUy_k4xiq_hA@mail.gmail.com>
Subject: Re: Linux 6.13-rc5 Xen HVM with PCI passthrough (USB controller) crash
To: =?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= <marmarek@invisiblethingslab.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>, 
	xen-devel <xen-devel@lists.xenproject.org>, Mike Rapoport <rppt@kernel.org>, 
	Luis Chamberlain <mcgrof@kernel.org>, Andreas Larsson <andreas@gaisler.com>, 
	Andy Lutomirski <luto@kernel.org>, Ard Biesheuvel <ardb@kernel.org>, Arnd Bergmann <arnd@arndb.de>, 
	Borislav Petkov <bp@alien8.de>, Brian Cain <bcain@quicinc.com>, 
	Catalin Marinas <catalin.marinas@arm.com>, Christophe Leroy <christophe.leroy@csgroup.eu>, 
	Christoph Hellwig <hch@lst.de>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Dinh Nguyen <dinguyen@kernel.org>, Guo Ren <guoren@kernel.org>, Helge Deller <deller@gmx.de>, 
	Huacai Chen <chenhuacai@kernel.org>, Ingo Molnar <mingo@redhat.com>, 
	Johannes Berg <johannes@sipsolutions.net>, 
	John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>, Kent Overstreet <kent.overstreet@linux.dev>, 
	"Liam R. Howlett" <Liam.Howlett@oracle.com>, Mark Rutland <mark.rutland@arm.com>, 
	Masami Hiramatsu <mhiramat@kernel.org>, Matt Turner <mattst88@gmail.com>, 
	Max Filippov <jcmvbkbc@gmail.com>, Michael Ellerman <mpe@ellerman.id.au>, Michal Simek <monstr@monstr.eu>, 
	Oleg Nesterov <oleg@redhat.com>, Palmer Dabbelt <palmer@dabbelt.com>, 
	Peter Zijlstra <peterz@infradead.org>, Richard Weinberger <richard@nod.at>, 
	Russell King <linux@armlinux.org.uk>, Song Liu <song@kernel.org>, 
	Stafford Horne <shorne@gmail.com>, Steven Rostedt <rostedt@goodmis.org>, 
	Suren Baghdasaryan <surenb@google.com>, Thomas Bogendoerfer <tsbogend@alpha.franken.de>, 
	Thomas Gleixner <tglx@linutronix.de>, Uladzislau Rezki <urezki@gmail.com>, Vineet Gupta <vgupta@kernel.org>, 
	Will Deacon <will@kernel.org>, Andrew Morton <akpm@linux-foundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Marek,

On Fri, Jan 3, 2025 at 7:10=E2=80=AFPM Marek Marczykowski-G=C3=B3recki
<marmarek@invisiblethingslab.com> wrote:
> On Fri, Jan 03, 2025 at 02:00:28AM +0000, Andrew Cooper wrote:
> > On 03/01/2025 12:42 am, Marek Marczykowski-G=C3=B3recki wrote:
> > > On Fri, Jan 03, 2025 at 01:18:31AM +0100, Marek Marczykowski-G=C3=B3r=
ecki wrote:
> > >> On Thu, Jan 02, 2025 at 08:39:16PM +0100, Marek Marczykowski-G=C3=B3=
recki wrote:
> > >>> On Thu, Jan 02, 2025 at 08:17:00PM +0100, J=C3=BCrgen Gro=C3=9F wro=
te:
> > >>>> On 02.01.25 19:54, Marek Marczykowski-G=C3=B3recki wrote:
> > >>>>> There is
> > >>>>> one issue (likely unrelated to this change) - sys-usb (HVM domU w=
ith USB
> > >>>>> controllers passed through) crashes on a system with Raptor Lake =
CPU
> > >>>>> (only, others, including ADL and MTL look fine):
> > >> Correction, it does happen on some others too, just got the crash on=
 the ADL
> > >> system, although looks a bit different ("Corrupted page table at ...=
"):
> > > I've collected some more of them at https://github.com/QubesOS/qubes-=
issues/issues/9681
> > >
> > > Should I start new thread for this? On one hand, it's a different dom=
ain
> > > type (HVM), but on the other hand, many of the crashes are around
> > > loading modules too.
> >
> > https://lore.kernel.org/lkml/20241227072825.1288491-1-rppt@kernel.org/T=
/#t
> > looks relevant.  Probably worth following up.
>
> As responded there, I don't think so, as that series is not part of
> 6.13-rc5. But in the meantime, I bisected it and got this commit:
>
> 5185e7f9f3bd754ab60680814afd714e2673ef88 is the first bad commit
> commit 5185e7f9f3bd754ab60680814afd714e2673ef88
> Author: Mike Rapoport (Microsoft) <rppt@kernel.org>
> Date:   Wed Oct 23 19:27:11 2024 +0300
>
>     x86/module: enable ROX caches for module text on 64 bit
>
>     Enable execmem's cache of PMD_SIZE'ed pages mapped as ROX for module =
text
>     allocations on 64 bit.
>
>     Link: https://lkml.kernel.org/r/20241023162711.2579610-9-rppt@kernel.=
org
>     Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
>     Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
>     Tested-by: kdevops <kdevops@lists.linux.dev>
>     Cc: Andreas Larsson <andreas@gaisler.com>
>     Cc: Andy Lutomirski <luto@kernel.org>
>     Cc: Ard Biesheuvel <ardb@kernel.org>
>     Cc: Arnd Bergmann <arnd@arndb.de>
>     Cc: Borislav Petkov (AMD) <bp@alien8.de>
>     Cc: Brian Cain <bcain@quicinc.com>
>     Cc: Catalin Marinas <catalin.marinas@arm.com>
>     Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
>     Cc: Christoph Hellwig <hch@lst.de>
>     Cc: Dave Hansen <dave.hansen@linux.intel.com>
>     Cc: Dinh Nguyen <dinguyen@kernel.org>
>     Cc: Geert Uytterhoeven <geert@linux-m68k.org>
>     Cc: Guo Ren <guoren@kernel.org>
>     Cc: Helge Deller <deller@gmx.de>
>     Cc: Huacai Chen <chenhuacai@kernel.org>
>     Cc: Ingo Molnar <mingo@redhat.com>
>     Cc: Johannes Berg <johannes@sipsolutions.net>
>     Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
>     Cc: Kent Overstreet <kent.overstreet@linux.dev>
>     Cc: Liam R. Howlett <Liam.Howlett@Oracle.com>
>     Cc: Mark Rutland <mark.rutland@arm.com>
>     Cc: Masami Hiramatsu (Google) <mhiramat@kernel.org>
>     Cc: Matt Turner <mattst88@gmail.com>
>     Cc: Max Filippov <jcmvbkbc@gmail.com>
>     Cc: Michael Ellerman <mpe@ellerman.id.au>
>     Cc: Michal Simek <monstr@monstr.eu>
>     Cc: Oleg Nesterov <oleg@redhat.com>
>     Cc: Palmer Dabbelt <palmer@dabbelt.com>
>     Cc: Peter Zijlstra <peterz@infradead.org>
>     Cc: Richard Weinberger <richard@nod.at>
>     Cc: Russell King <linux@armlinux.org.uk>
>     Cc: Song Liu <song@kernel.org>
>     Cc: Stafford Horne <shorne@gmail.com>
>     Cc: Steven Rostedt (Google) <rostedt@goodmis.org>
>     Cc: Suren Baghdasaryan <surenb@google.com>
>     Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
>     Cc: Thomas Gleixner <tglx@linutronix.de>
>     Cc: Uladzislau Rezki (Sony) <urezki@gmail.com>
>     Cc: Vineet Gupta <vgupta@kernel.org>
>     Cc: Will Deacon <will@kernel.org>
>     Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>
>  arch/x86/Kconfig   |  1 +
>  arch/x86/mm/init.c | 37 ++++++++++++++++++++++++++++++++++++-
>  2 files changed, 37 insertions(+), 1 deletion(-)
>
> I'm extending CC...

Do you really think adding all non-Intel maintainers will help fixing
an Intel-specific problem? Please do not do that.
Thanks!

Gr{oetje,eeting}s,

                        Geert

--=20
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k=
.org

In personal conversations with technical people, I call myself a hacker. Bu=
t
when I'm talking to journalists I just say "programmer" or something like t=
hat.
                                -- Linus Torvalds


From xen-devel-bounces@lists.xenproject.org Fri Jan 03 20:47:32 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Jan 2025 20:47:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864633.1275840 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tToZb-0005FB-MC; Fri, 03 Jan 2025 20:47:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864633.1275840; Fri, 03 Jan 2025 20:47:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tToZb-0005F4-Je; Fri, 03 Jan 2025 20:47:11 +0000
Received: by outflank-mailman (input) for mailman id 864633;
 Fri, 03 Jan 2025 20:47: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
 <SRS0=/LDK=T3=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tToZa-0005Ey-JG
 for xen-devel@lists.xenproject.org; Fri, 03 Jan 2025 20:47:10 +0000
Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com
 [2a00:1450:4864:20::344])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e55104ec-ca13-11ef-99a4-01e77a169b0f;
 Fri, 03 Jan 2025 21:47:07 +0100 (CET)
Received: by mail-wm1-x344.google.com with SMTP id
 5b1f17b1804b1-43635796b48so76477765e9.0
 for <xen-devel@lists.xenproject.org>; Fri, 03 Jan 2025 12:47:07 -0800 (PST)
Received: from andrewcoop.eng.citrite.net (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4366127c4bbsm490042155e9.32.2025.01.03.12.47.05
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 03 Jan 2025 12:47:05 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e55104ec-ca13-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1735937226; x=1736542026; 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=exBLFrtWNgnHmKhXoK3LAaqFBTryX24sTmnjfI19g6s=;
        b=Gto0/XbhRneZVvw6V6db9aOfveeLpUnEKtqVHIUyX2bAJbyQvdgVCGvXaJWSySFnG8
         bFxqnozpYZObwNmupnFPL1o3e/T5Pt6lySELnW6g4OvXotfinU3JujXtHp/BRh31OAxl
         jJGyDj0WS5UYxMQzypfUy4GiWdJDSU9wEWPSg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735937226; x=1736542026;
        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=exBLFrtWNgnHmKhXoK3LAaqFBTryX24sTmnjfI19g6s=;
        b=Yn0to3zfVHPwnM4zVs5yYwWxSORSBwV1Nr6Q5PytVyiNVdcxMXJ7EFV3jPXgwSTGIz
         gS4OY+Ed7k1fM6+RiQLoi0eLzscLn54Mupv8kL+p+2kEaXOcaszFgJRB7pR9h2HH9iXV
         VrVNoADilAIjzM8IBVT1BeIpzA4Tj9ecPrxYeScPHksYgpfy/lEogRq0Tejcc01yJf0W
         8dQIfyXd6LeqcmW5q9Q/8bzctK0D3+HNo2Jkl5TLKM0EmZ476OTB3fGd2hwGKWQ3wAB+
         VI1vWnqL+sa10WxQy8ZobNAp1eBywN7qAejbVp94WXhXe6/rDbUVizpEoOrQymPzhOZD
         7gUw==
X-Gm-Message-State: AOJu0YypcHxw/GMIMs8CxGSkIcdpFC7nmortouV5pDLi5TufK5a1Aqsj
	f6zHN4JiJ3++JCzTx2WPq362uFIiPSSh2W562FH6Y1Yj/viyB3gvv2CqdyTAyLi0qzTiIE0KzU/
	SywGHpMeX
X-Gm-Gg: ASbGncsdXgYBxPFgw3JBp6R0+uFmeoRLS6iIGSoelfMmoXw3SaR21Hmb05rmPeoJufq
	Q/k9WoOtL84OSU1UzE672GBhC8DNR3ZDhrJMqrVSRi9rhIIuewsc9ZAaPMaePGVZTH/Xnt4CqkJ
	VHPaD5Qn4dMbWkXXCw9Z/0DCcursaFddFxHCplw/0+X0HniBFR6H/QHdeHjcttsbqzVe858hSut
	KZFN6GCPwnT5xMfIH8KiEcPivI+Jd2MWV7GHV31CdvQLeAphzMdX19Bwlmqw1EVEgODlw0uUg4d
	5yjzex3b/xu8VwDHAtv61uCNdmx5HkjX1oHx
X-Google-Smtp-Source: AGHT+IGzmXkGFpP9d4v99nzTz4sJohR4wCiA1u3VOBebeRCL6m4hLRxWyw7L2qr1kDQk4q34NKk/kA==
X-Received: by 2002:a05:600c:4302:b0:435:edb0:5d27 with SMTP id 5b1f17b1804b1-4365c775131mr425183595e9.9.1735937226225;
        Fri, 03 Jan 2025 12:47:06 -0800 (PST)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [RFC] docs: FRED support in Xen
Date: Fri,  3 Jan 2025 20:47:04 +0000
Message-Id: <20250103204704.84067-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Roger Pau Monné <roger.pau@citrix.com>

An initial RFC discussion and plan.  Open TODOs are at the end.

This can be viewed online at:
  https://andrewcoop-xen.readthedocs.io/en/docs-devel/hypervisor-guide/x86/fred.html

I've got an 8-patch series doing the cpu_user_regs disentangling vs the public
API.  That's in pretty good shape now.

FRED itself is orders and orders of magnitude more simple than IDT, both in
terms of setup and operation, but I'm in the middle of a very large
cleanup (35 patches and count) to setup.c and trap.c in order to make FRED
able to be cleanly integrated into Xen, and that's still before any of the GS
changes to keep PV guests functioning correctly.
---
 docs/glossary.rst                   |   7 +
 docs/hypervisor-guide/x86/fred.rst  | 215 ++++++++++++++++++++++++++++
 docs/hypervisor-guide/x86/index.rst |   1 +
 3 files changed, 223 insertions(+)
 create mode 100644 docs/hypervisor-guide/x86/fred.rst

diff --git a/docs/glossary.rst b/docs/glossary.rst
index 6adeec77e14c..18502c0474f7 100644
--- a/docs/glossary.rst
+++ b/docs/glossary.rst
@@ -43,6 +43,13 @@ Glossary
      Sapphire Rapids (Server, 2023) CPUs.  AMD support only CET-SS, starting
      with Zen3 (Both client and server, 2020) CPUs.
 
+   FRED
+     Flexible Return and Event Delivery is a facility in x86 CPUs which
+     overhauls how system calls, interrupt and exception handling works.
+
+     Intel support for FRED is slated for Panther Lake (Client) and Diamond
+     Rapids (Server).
+
    guest
      The term 'guest' has two different meanings, depending on context, and
      should not be confused with :term:`domain`.
diff --git a/docs/hypervisor-guide/x86/fred.rst b/docs/hypervisor-guide/x86/fred.rst
new file mode 100644
index 000000000000..68146b79bdfc
--- /dev/null
+++ b/docs/hypervisor-guide/x86/fred.rst
@@ -0,0 +1,215 @@
+.. SPDX-License-Identifier: CC-BY-4.0
+
+FRED: Flexible Return and Event Delivery
+========================================
+
+Overview
+--------
+
+FRED was originally intended to improve performance (reading and parsing the
+IDT, GDT/LDT and possibly the TSS is a bottleneck) and to provide an
+extensible mechanism to overcome other limitations in the future (e.g. support
+for more than 256 interrupt vectors).  During development, FRED was adjusted
+substantially to also fix lots of technical debt that had accumulated in the
+x86 architecture for the past 40 years, most of which is a fertile source of
+crashes and privilege escalation bugs.
+
+FRED is primarily concerned with establishing a new context when an event is
+recognised, and restoring the old context when the event is handled.  This
+includes events previously delivered through the IDT (exceptions and
+interrupts), as well as ``SYSCALL`` and ``SYSENTER`` instructions which
+avoided the IDT in the past for performance reasons.
+
+FRED strives to achieve that event delivery always establishes a good CPL0
+stack (and shadow stack if CET is active), that doesn't clobber still-active
+state from an outer nested context, and with the CPL0 GSBASE.
+
+Technical details
+-----------------
+
+When FRED is active, Rings 1 and 2 cannot be entered at all, Ring0
+compatibility mode cant be entered (i.e. Ring0 is strictly 64bit), and
+``IRET`` can no longer change privilege.  Call Gates no longer exist.
+
+A single entrypoint is registered in ``MSR_FRED_CONFIG``.  Entries from Ring3
+start at this address, while entries from Ring0 start at +256.  All
+interrupts, exceptions and syscalls route these.  VMExits do not, and retain
+their prior behaviour.
+
+There are 4 Stack Levels, SL 0 thru 3 and a notion of Current Stack Level,
+replacing the prior IST mechanism.  All stack pointers, and shadow stack
+pointers when CET-SS is active, are registered in ``MSR_{R,S}SP_SL{0..3}``.
+Supervisor Shadow Stack tokens no longer exist, and are replaced with an
+alternative mechanism.
+
+The IDT is no longer used.  The TSS is no longer used used to hold stack
+pointers, nor ``MSR_ISST`` if CET Shadow Stacks are active.  ``MSR_{L,C}STAR``
+as well as all SYSENTER MSRs are no longer used.  Under FRED, ``MSR_STAR`` and
+``MSR_FMASK`` are used with their previous behaviour extended to all event
+deliveries, not just syscalls.
+
+The instructions ``SWAPGS``, ``CLRSSBSY``, ``SETSSBSY``, ``SYSEXIT`` and
+``SYSRET`` unconditionally ``#UD``.  Establishing an initial SSP should use
+``RSTORSSP``.  GS maintenance can use the new ``LKGS`` instruction.
+
+Implementation considerations
+-----------------------------
+
+PV32 guests
+"""""""""""
+
+FRED formally removes the ability to use Rings 1 and 2, which prohibits the
+use of PV32 guests.  PV32 guests are already disabled by default in the
+presence of CET owing to the difficulty of using Ring 1 with CET active.
+Compatibility for PV32 guests is provided by PVShim, which takes care not to
+use CET in order to be able to run PV32 guests.  FRED can use the same
+approach.
+
+Initialisation
+""""""""""""""
+
+Exception handling is initialised right at the beginning of ``__start_xen()``
+prior to parsing the command line.  Having exception cover this early is
+important and wants to remain.
+
+The determination of whether to use FRED or not needs to account for the
+``fred`` and ``pvshim`` command line options, the ``FRED`` and ``LKGS`` CPUID
+bits.
+
+Therefore for simplicity, early exception handling will still use IDT
+delivery, and later setup can switch to FRED instead.
+
+cpu_user_regs vs vm86 segments
+""""""""""""""""""""""""""""""
+
+``struct cpu_user_regs`` exists in the public interface, and is embedded
+inside ``struct vcpu_guest_context``.  From an ABI perspective, the layout
+needs to remain.  ``struct cpu_user_regs`` is also a common name in Xen,
+covering the event information (pushed by hardware and software) and the GPRs
+(pushed by software).  From an API perspective, the name needs to remain.
+
+The data selectors (ds, es, fs, gs) are a vestigial remnant of vm86 mode.
+Hardware did push them on exit from vm86 mode, and ``IRET`` would consume them
+on the way back in.
+
+However, vm86 mode isn't usable in Long mode, and these selectors oughtn't to
+have survived into the PV64 ABI.  Under FRED, hardware pushes different
+information here, which needs accounting for in Xen's view of ``struct
+cpu_user_regs``.
+
+Therefore, the only option is to have the public API provide a struct by a
+different name, and provide a compatibility define for the ``!__XEN__`` case,
+freeing us up to have a similar but not identical ``struct cpu_user_regs``
+which Xen operates on.
+
+There are several uses of the vm86 fields in Xen:
+
+ #. ``struct vcpu`` embeds a ``struct cpu_user_regs`` to hold GPRs/etc when
+    the vCPU is scheduled out.  The vm86 fields are used by the PV logic only
+    (``{save,load}_segments()``) and can be moved into separate fields in
+    ``struct pv_vcpu``.  PV's ``dom0_construct()`` sets these fields directly,
+    and needs a matching adjustment.
+
+ #. As part of ``arch_{get,set}_info_guest()`` during hypercalls.  The
+    guest side needs to remain as-is, but the Xen side can rearranged to use
+    the new fields from above.
+
+ #. As part of vCPU diagnostics (``show_registers()`` etc).  The ``#DF`` path
+    uses the fields as scratch storage for the current register values, while
+    the other diagnostics are simply accessing the state of a scheduled-out
+    vCPU.
+
+ #. In HVM's ``hvm_sanitize_regs_fields()``, to poison the fields and make
+    them more obvious if used anywhere in HVM context.  This can simply be
+    deleted.
+
+ #. In x86_emulate.c's ``put_fpu()``.  As far as I can tell, this is
+    completely buggy; the values will be poisoned for HVM guests, and stale
+    from the prior context switch for PV guests.
+
+Stack layout
+""""""""""""
+
+Xen's CPU stacks are 8-page (8-page aligned), arranged as::
+
+  7 - Primary stack (with a struct cpu_info at the top)
+  6 - Primary stack
+  5 - Primary Shadow Stack (read-only)
+  4 - #DF IST stack
+  3 - #DB IST stack
+  2 - NMI IST stack
+  1 - #MC IST stack
+  0 - IST Shadow Stacks (4x 1k, read-only)
+
+which needs mapping into FREDs Stack Levels.
+
+FRED Stack Levels replace IST.  Most events from Ring3 enter Ring0 at SL0,
+including interrupts, and even exceptions with a non-zero Stack Level
+configured.  Nested exceptions originate from Ring0 even if they were trying
+to push a Ring3 event frame onto the stack, so do follow the Ring0 CSL rules.
+
+Within Ring0, a stack switch occurs on event delivery if the event has a
+higher configured Stack Level (exceptions in ``MSR_FRED_STK_LVLS``, interrupts
+in ``MSR_FRED_CONFIG``).  Otherwise, the new event is delivered on the current
+stack.
+
+Under FRED, most sources of ``#DF`` are gone; failure to push a new event
+frame onto a stack is the main remaining one, so ``#DF`` needs to be the
+highest stack level (SL3) to catch errors at all other stack levels.
+
+Also, FRED removes the "syscall gap", removing the primary need for ``NMI``,
+``#DB`` and ``#MC`` to need separate stacks.
+
+Therefore, Xen has no need for SL1 or SL2.  Under IDT delivery, we poison the
+unused stack pointers with a non-canonical address, but we cannot do that
+under FRED; they're held in MSRs and checked at WRMSR time.  Instead, we can
+point the SL pairs (RSP + SSP) at each others (regular and shadow stack) guard
+pages such that any use of an unused SL will escalate to ``#DF``.
+
+FRED event delivery also realigns the stack to a 64-byte boundary (increased
+from 16-byte in 64bit IDT delivery), which has an effect on the layout of
+``struct cpu_info``.  By coincidence, the top-of-stack block is already 64
+bytes before the start of the FRED-adjusted ``struct cpu_user_regs``, so no
+changes beyond a stricter alignment check are needed right now.
+
+In principle we could disconnect ``struct cpu_user_regs`` from ``struct
+cpu_info``.  Some future extensions to FRED might even require it.  However,
+right now, ``SPEC_CTRL_COND_VERW`` on exit to guest needs to access
+``CPUINFO_scf`` and ``CPUINFO_verw_sel`` as absolute displacements from
+``%rsp``.  This is easiest to achieve if ``struct cpu_user_regs`` is fixed and
+compatible with both IDT and FRED delivery.
+
+
+Still TBD
+---------
+
+Issues/areas I'm aware of, but haven't got a firm plan yet.
+
+Call Gates
+""""""""""
+
+FRED removes Call Gates, yielding ``#GP[sel]`` instead.  This is how we
+emulate call gates for PV32, but emulation is genuinely only wired up for PV32
+guests, not for PV64.
+
+PV64 guests do seem to be able to write Call Gates into their LDT/GDT, but
+have the DPL 0'd in common with PV32.  Given the absence of emulation, I think
+PV64 can't actually use Call Gates, but given the existing logic this also
+seems to be by accident rather than design.
+
+GS handling
+"""""""""""
+
+Xen does not use GS as a per-cpu pointer, but FRED is tied to the common OS
+usage.  Therefore, when FRED is active, ``v->arch.pv.gs_base_{user,kernel}``
+are logically the opposite way around when running in Xen context.
+
+Furthermore we cannot use ``SWAPGS`` as part of context switching, and there's
+no ``wrgsshadow`` instruction.  All guest GS handling within Xen needs to be
+altered.
+
+Kexec
+"""""
+
+NMI shootdown for kexec plays with IST settings carefully to keep the
+non-kexecing CPUs safely contained.  This will need changing completely.
diff --git a/docs/hypervisor-guide/x86/index.rst b/docs/hypervisor-guide/x86/index.rst
index c10cd1d7c0bd..64f9b4b2ccd4 100644
--- a/docs/hypervisor-guide/x86/index.rst
+++ b/docs/hypervisor-guide/x86/index.rst
@@ -7,3 +7,4 @@ x86
    :maxdepth: 2
 
    how-xen-boots
+   fred

base-commit: a1746cd4434dd27ca2da8430dfb10edc76264bb3
prerequisite-patch-id: a7f7bbaaec1c02d055eb07a630f2f4dc28b1e70b
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Fri Jan 03 22:21:01 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Jan 2025 22:21:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864643.1275850 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTq25-0000kj-9D; Fri, 03 Jan 2025 22:20:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864643.1275850; Fri, 03 Jan 2025 22:20:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTq25-0000kc-66; Fri, 03 Jan 2025 22:20:41 +0000
Received: by outflank-mailman (input) for mailman id 864643;
 Fri, 03 Jan 2025 22:20:39 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=79/6=T3=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tTq23-0000kW-M7
 for xen-devel@lists.xenproject.org; Fri, 03 Jan 2025 22:20:39 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org
 [2604:1380:45d1:ec00::3])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f4669f01-ca20-11ef-99a4-01e77a169b0f;
 Fri, 03 Jan 2025 23:20:36 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 3F1B4A41156;
 Fri,  3 Jan 2025 22:18:46 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 73681C4CEDD;
 Fri,  3 Jan 2025 22:20:33 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f4669f01-ca20-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1735942835;
	bh=p/eLISc/V9aJBvfaAAX1bFiNJGOl/ufjTpecSDi4AbA=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=VQrBzx0g4HGqCiC5ws///thw5yneJdK5Sl9Q1XVXam1BFYhzv5WUw5SAyMg4iqSSL
	 v2STf+UGuhUVbL3SG75M7N58n8lIA5ep44V7NYUy7YXdzvNl7RBn7nTnWCp0jDAAIJ
	 s6VDsjVpYVlrVmGAnxKMOBTMwN2Fe/4ewBH4/3qNeNXRFq020aO2XE/ihyqzAWegFS
	 /8sFzRHHmsBUPTgnVdnzoVHsAl0HiButeIJIxAzZxPa06FWzFOgdqUDbdyEyYdUGLQ
	 F8A+ndVt5PK5YUBUF4FngtwXm8F14AwNnnbY47V93GueVBTNFwr6K8hwY8y+aI9miv
	 YADkYRrfMm+Zw==
Date: Fri, 3 Jan 2025 14:20:31 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Nicola Vetrini <nicola.vetrini@bugseng.com>
cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org, 
    michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, 
    consulting@bugseng.com, Simone Ballarin <simone.ballarin@bugseng.com>, 
    Doug Goldstein <cardoe@cardoe.com>, 
    Andrew Cooper3 <andrew.cooper3@citrix.com>
Subject: Re: [XEN PATCH v2] eclair-analysis: tidy toolchain.ecl configuration
 and mark Rule 1.1 clean
In-Reply-To: <01be894f3c24aa1d7aba528bd5d6f0a1d5a97504.1734876081.git.nicola.vetrini@bugseng.com>
Message-ID: <alpine.DEB.2.22.394.2501031318250.16425@ubuntu-linux-20-04-desktop>
References: <01be894f3c24aa1d7aba528bd5d6f0a1d5a97504.1734876081.git.nicola.vetrini@bugseng.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Sun, 22 Dec 2024, Nicola Vetrini wrote:
> Reformat the list of GNU extensions and non-standard tokens used by Xen
> in the ECLAIR configuration to make it easier to review any changes to it.
> 
> The extension "ext_missing_varargs_arg", which captures the GNU extension that
> allows variadic functions and macros not to require at least one named parameter
> before C23 has been renamed to "ext_c_missing_varargs_arg" in the current version
> of ECLAIR used in CI, therefore this resolves regressions on MISRA C Rule 1.1:
> 
> "The program shall contain no violations of the standard C syntax and constraints,
> and shall not exceed the implementation's translation limits."
> 
> As a result, Rule 1.1 now has no violations and is tagged as such.
> 
> Remove two unused configurations, that were already commented out.
> 
> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
> Fixes: 631f535a3d4f ("xen: update ECLAIR service identifiers from MC3R1 to MC3A2.")

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
> The __inline token is added to the list of accepted non-standard keywords
> on arm64 to reduce verbosity (in this way, a single macher can be defined since
> the sets of non-standard tokens were identical except for this one).
> 
> This change is a candidate for backporting into the 4.18 and 4.19 trees.
> 
> Changes in v2:
> - drop the old name for the extension
> - format the list of extensions and non-standard tokens to be on multiple
>   lines, and sort the list
> - remove unused, commmented-out, configurations
> - tag R1.1 clean
> ---
>  automation/eclair_analysis/ECLAIR/tagging.ecl |  1 +
>  .../eclair_analysis/ECLAIR/toolchain.ecl      | 93 +++++++++++++++----
>  2 files changed, 74 insertions(+), 20 deletions(-)
> 
> diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl b/automation/eclair_analysis/ECLAIR/tagging.ecl
> index 982f506cc7b6..4a1d3b3a9898 100644
> --- a/automation/eclair_analysis/ECLAIR/tagging.ecl
> +++ b/automation/eclair_analysis/ECLAIR/tagging.ecl
> @@ -25,6 +25,7 @@ MC3A2.D2.1||
>  MC3A2.D4.1||
>  MC3A2.D4.11||
>  MC3A2.D4.14||
> +MC3A2.R1.1||
>  MC3A2.R1.3||
>  MC3A2.R1.4||
>  MC3A2.R2.6||
> diff --git a/automation/eclair_analysis/ECLAIR/toolchain.ecl b/automation/eclair_analysis/ECLAIR/toolchain.ecl
> index 86e9a79b5231..8ebf9f132cf2 100644
> --- a/automation/eclair_analysis/ECLAIR/toolchain.ecl
> +++ b/automation/eclair_analysis/ECLAIR/toolchain.ecl
> @@ -12,25 +12,47 @@
>  -setq=C99_STD,"ISO/IEC 9899:1999"
>  
>  -doc_begin="
> -    _Static_assert: see Section \"2.1 C Language\" of "GCC_MANUAL".
> -    asm, __asm__: see Sections \"6.48 Alternate Keywords\" and \"6.47 How to Use Inline Assembly Language in C Code\" of "GCC_MANUAL".
> -    __volatile__: see Sections \"6.48 Alternate Keywords\" and \"6.47.2.1 Volatile\" of "GCC_MANUAL".
> -    __const__ : see Section \"6.48 Alternate Keywords\" of "GCC_MANUAL".
> -    typeof, __typeof__: see Section \"6.7 Referring to a Type with typeof\" of "GCC_MANUAL".
>      __alignof__, __alignof: see Sections \"6.48 Alternate Keywords\" and \"6.44 Determining the Alignment of Functions, Types or Variables\" of "GCC_MANUAL".
> +    asm, __asm__: see Sections \"6.48 Alternate Keywords\" and \"6.47 How to Use Inline Assembly Language in C Code\" of "GCC_MANUAL".
>      __attribute__: see Section \"6.39 Attribute Syntax\" of "GCC_MANUAL".
> +    __builtin_offsetof: see Section \"6.53 Support for offsetof\" of "GCC_MANUAL".
>      __builtin_types_compatible_p: see Section \"6.59 Other Built-in Functions Provided by GCC\" of "GCC_MANUAL".
>      __builtin_va_arg: non-documented GCC extension.
> -    __builtin_offsetof: see Section \"6.53 Support for offsetof\" of "GCC_MANUAL".
> +    __const__, __inline__, __inline: see Section \"6.48 Alternate Keywords\" of "GCC_MANUAL".
> +    _Static_assert: see Section \"2.1 C Language\" of "GCC_MANUAL".
> +    typeof, __typeof__: see Section \"6.7 Referring to a Type with typeof\" of "GCC_MANUAL".
> +    __volatile__: see Sections \"6.48 Alternate Keywords\" and \"6.47.2.1 Volatile\" of "GCC_MANUAL".
>  "
> --config=STD.tokenext,behavior+={c99, GCC_ARM64, "^(_Static_assert|asm|__asm__|__volatile__|__const__|typeof|__typeof__|__alignof__|__attribute__|__builtin_types_compatible_p|__builtin_va_arg|__builtin_offsetof)$"}
> --config=STD.tokenext,behavior+={c99, GCC_X86_64, "^(_Static_assert|asm|__asm__|__volatile__|__const__|typeof|__typeof__|__alignof__|__alignof|__attribute__|__builtin_types_compatible_p|__builtin_va_arg|__builtin_offsetof)$"}
> +-name_selector+={alignof, "^(__alignof__|__alignof)$"}
> +-name_selector+={asm, "^(__asm__|asm)$"}
> +-name_selector+={attribute, "^__attribute__$"}
> +-name_selector+={builtin_offsetof, "^__builtin_offsetof$"}
> +-name_selector+={builtin_types_p, "^__builtin_types_compatible_p$"}
> +-name_selector+={builtin_va_arg, "^__builtin_va_arg$"}
> +-name_selector+={const, "^__const__$"}
> +-name_selector+={inline, "^(__inline__|__inline)$"}
> +-name_selector+={static_assert, "^_Static_assert$"}
> +-name_selector+={typeof, "^(__typeof__|typeof)$"}
> +-name_selector+={volatile, "^__volatile__$"}
> +
> +-config=STD.tokenext,behavior+={c99, GCC_ARM64||GCC_X86_64,
> +"alignof||
> +asm||
> +attribute||
> +builtin_offsetof||
> +builtin_types_p||
> +builtin_va_arg||
> +const||
> +inline||
> +static_assert||
> +typeof||
> +volatile"
> +}
>  -doc_end
>  
>  -doc_begin="Non-documented GCC extension."
>  -config=STD.emptinit,behavior+={c99,GCC_ARM64,specified}
>  -config=STD.emptinit,behavior+={c99,GCC_X86_64,specified}
> -#-config=STD.emptinit,behavior+={c18,GCC_X86_64,specified}
>  -doc_end
>  
>  -doc_begin="See Section \"6.24 Arithmetic on void- and Function-Pointers\" of "GCC_MANUAL"."
> @@ -80,7 +102,6 @@
>  -doc_begin="Non-documented GCC extension."
>  -config=STD.pteincmp,behavior+={c99,GCC_ARM64,specified}
>  -config=STD.pteincmp,behavior+={c99,GCC_X86_64,specified}
> -#-config=STD.pteincmp,behavior+={c18,GCC_X86_64,specified}
>  -doc_end
>  
>  -doc_begin="Non-documented GCC extension."
> @@ -88,20 +109,52 @@
>  -doc_end
>  
>  -doc_begin="
> -    ext_paste_comma: see Section \"6.21 Macros with a Variable Number of Arguments\" of "GCC_MANUAL".
> -    ext_missing_varargs_arg: see Section \"6.21 Macros with a Variable Number of Arguments\" of "GCC_MANUAL".
> +    ext_c_missing_varargs_arg: see Section \"6.21 Macros with a Variable Number of Arguments\" of "GCC_MANUAL".
> +    ext_enum_value_not_int: non-documented GCC extension.
> +    ext_flexible_array_in_array: see Section \"6.18 Arrays of Length Zero\" of "GCC_MANUAL".
> +    ext_flexible_array_in_struct: see Section \"6.18 Arrays of Length Zero\" of "GCC_MANUAL".
> +    ext_forward_ref_enum_def: see Section \"6.49 Incomplete enum Types\" of "GCC_MANUAL".
> +    ext_gnu_array_range: see Section \"6.29 Designated Initializers\" of "GCC_MANUAL".
> +    ext_gnu_statement_expr_macro: see Section \"6.1 Statements and Declarations in Expressions\" of "GCC_MANUAL".
>      ext_named_variadic_macro: see Section \"6.21 Macros with a Variable Number of Arguments\" of "GCC_MANUAL".
> +    ext_paste_comma: see Section \"6.21 Macros with a Variable Number of Arguments\" of "GCC_MANUAL".
>      ext_return_has_void_expr: see the documentation for -Wreturn-type in Section \"3.8 Options to Request or Suppress Warnings\" of "GCC_MANUAL".
> -    ext_gnu_statement_expr_macro: see Section \"6.1 Statements and Declarations in Expressions\" of "GCC_MANUAL".
>      ext_sizeof_alignof_void_type: see Section \"6.24 Arithmetic on void- and Function-Pointers\" of "GCC_MANUAL".
> -    ext_forward_ref_enum_def: see Section \"6.49 Incomplete enum Types\" of "GCC_MANUAL".
> -    ext_flexible_array_in_struct: see Section \"6.18 Arrays of Length Zero\" of "GCC_MANUAL".
> -    ext_flexible_array_in_array: see Section \"6.18 Arrays of Length Zero\" of "GCC_MANUAL".
> -    ext_enum_value_not_int: non-documented GCC extension.
> -    ext_gnu_array_range: see Section \"6.29 Designated Initializers\" of "GCC_MANUAL".
>  "
> --config=STD.diag,behavior+={c99,GCC_ARM64,"^(ext_paste_comma|ext_missing_varargs_arg|ext_named_variadic_macro|ext_return_has_void_expr|ext_gnu_statement_expr_macro|ext_sizeof_alignof_void_type|ext_forward_ref_enum_def|ext_gnu_array_range)$"}
> --config=STD.diag,behavior+={c99,GCC_X86_64,"^(ext_paste_comma|ext_missing_varargs_arg|ext_named_variadic_macro|ext_return_has_void_expr|ext_gnu_statement_expr_macro|ext_sizeof_alignof_void_type|ext_flexible_array_in_struct|ext_flexible_array_in_array|ext_enum_value_not_int|ext_gnu_array_range)$"}
> +-name_selector+={ext_c_missing_varargs_arg, "^ext_c_missing_varargs_arg$"}
> +-name_selector+={ext_enum_value_not_int, "^ext_enum_value_not_int$"}
> +-name_selector+={ext_flexible_array_in_array, "^ext_flexible_array_in_array$"}
> +-name_selector+={ext_flexible_array_in_struct, "^ext_flexible_array_in_struct$"}
> +-name_selector+={ext_forward_ref_enum_def, "^ext_forward_ref_enum_def$"}
> +-name_selector+={ext_gnu_array_range, "^ext_gnu_array_range$"}
> +-name_selector+={ext_gnu_statement_expr_macro, "^ext_gnu_statement_expr_macro$"}
> +-name_selector+={ext_named_variadic_macro, "^ext_named_variadic_macro$"}
> +-name_selector+={ext_paste_comma, "^ext_paste_comma$"}
> +-name_selector+={ext_return_has_void_expr, "^ext_return_has_void_expr$"}
> +-name_selector+={ext_sizeof_alignof_void_type, "^ext_sizeof_alignof_void_type$"}
> +
> +-config=STD.diag,behavior+={c99,GCC_ARM64,
> +"ext_c_missing_varargs_arg||
> +ext_forward_ref_enum_def||
> +ext_gnu_array_range||
> +ext_gnu_statement_expr_macro||
> +ext_named_variadic_macro||
> +ext_paste_comma||
> +ext_return_has_void_expr||
> +ext_sizeof_alignof_void_type"
> +}
> +-config=STD.diag,behavior+={c99,GCC_X86_64,
> +"ext_c_missing_varargs_arg||
> +ext_enum_value_not_int||
> +ext_flexible_array_in_array||
> +ext_flexible_array_in_struct||
> +ext_gnu_array_range||
> +ext_gnu_statement_expr_macro||
> +ext_named_variadic_macro||
> +ext_paste_comma||
> +ext_return_has_void_expr||
> +ext_sizeof_alignof_void_type"
> +}
>  -doc_end
>  
>  -doc_begin="The maximum size of an object is defined in the MAX_SIZE macro, and for a 32 bit architecture is 8MB.
> -- 
> 2.43.0
> 


From xen-devel-bounces@lists.xenproject.org Fri Jan 03 23:03:15 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Jan 2025 23:03:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864651.1275865 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTqh9-00066c-Cy; Fri, 03 Jan 2025 23:03:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864651.1275865; Fri, 03 Jan 2025 23:03:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTqh9-00066V-AT; Fri, 03 Jan 2025 23:03:07 +0000
Received: by outflank-mailman (input) for mailman id 864651;
 Fri, 03 Jan 2025 23:03:06 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=79/6=T3=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tTqh8-00066P-72
 for xen-devel@lists.xenproject.org; Fri, 03 Jan 2025 23:03:06 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e25f51bd-ca26-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 00:03:03 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id ABDAD5C60E1;
 Fri,  3 Jan 2025 23:02:20 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 03A26C4CEDD;
 Fri,  3 Jan 2025 23:03:00 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e25f51bd-ca26-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1735945381;
	bh=oGgHVA7oDmbhDnB8E00B6FTmhfAf4WxQop48Lc/8JVw=;
	h=Date:From:To:cc:Subject:From;
	b=S8Ut1KYc76gfDpje+0swVU3gDGagTOzFSGlqWBLzU/eoI8RVZ1qlQ9XIe1dnM8B9p
	 XDPSzcqKhJ6kxd6N/9EWdHX8zh/UK9jGurd9vwcxZqbmig4EfCWqI8hBUdY1rlEFsp
	 N++EwxDn11QiAjZE3bk4k9FNvyazZL9Xb27Wb0npJx3eKA5a+ppEXFQhPs+1Qp/QMT
	 G575vQGy0+beSRZpuWhTz8+7DiECQYAsA913yE8EbclslVXotrnOQtmwc/wwFw9QdN
	 rjBSaZlRDVPgPAFgJOYMtlVnzhn4HAGu1k3cdZhrkqGhhzx5Y9ipyBRRkWeWXBgoaQ
	 WLE+umt3QQfMw==
Date: Fri, 3 Jan 2025 15:02:59 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: linux-kernel@vger.kernel.org
cc: sstabellini@kernel.org, jgross@suse.com, xen-devel@lists.xenproject.org
Subject: [PATCH] xen: update pvcalls_front_accept prototype
Message-ID: <alpine.DEB.2.22.394.2501031501420.16425@ubuntu-linux-20-04-desktop>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
---
 drivers/xen/pvcalls-front.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/pvcalls-front.h b/drivers/xen/pvcalls-front.h
index f694ad77379f..881ef14660bc 100644
--- a/drivers/xen/pvcalls-front.h
+++ b/drivers/xen/pvcalls-front.h
@@ -12,7 +12,7 @@ int pvcalls_front_bind(struct socket *sock,
 int pvcalls_front_listen(struct socket *sock, int backlog);
 int pvcalls_front_accept(struct socket *sock,
 			 struct socket *newsock,
-			 int flags);
+			 struct proto_accept_arg *arg);
 int pvcalls_front_sendmsg(struct socket *sock,
 			  struct msghdr *msg,
 			  size_t len);
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Fri Jan 03 23:21:44 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Jan 2025 23:21:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864659.1275875 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTqyr-0000b2-T3; Fri, 03 Jan 2025 23:21:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864659.1275875; Fri, 03 Jan 2025 23:21:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTqyr-0000av-PL; Fri, 03 Jan 2025 23:21:25 +0000
Received: by outflank-mailman (input) for mailman id 864659;
 Fri, 03 Jan 2025 23:21:25 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=79/6=T3=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tTqyr-0000ap-6f
 for xen-devel@lists.xenproject.org; Fri, 03 Jan 2025 23:21:25 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 713e79bf-ca29-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 00:21:22 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 8B7945C634C;
 Fri,  3 Jan 2025 23:20:39 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id C1CA5C4CEDD;
 Fri,  3 Jan 2025 23:21:18 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 713e79bf-ca29-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1735946480;
	bh=dIjuQpPWOFQi6NC/w3MIRRxFT6bdrilHLk10vxsvem8=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=dMTJsBhAFeVM6m7N0HuCLdC/Q5GnF0ACksgfsEMspAMpnLxc1nAHUzLal+psZyGyW
	 9HovhBS4xVt2icxKbg00lFTmZNpe8Lq909fCYlUZPnERM4SJ++Iih6dE4A5E2hS4ro
	 SIwx9lFlHORppm2eLA1yvy0wjgASXHB4eXr+ee5PYp18+ehRk/hDYHT7OU7W8r/Sjk
	 YmYY7ufrS4RnaOWRtiMhmyXIlijJqkz3Yf2Lu026tTMvsX68zn37d9QuTheVg0TK1n
	 qCQ1QNLWuKTQzgvZ3quyT7P0uNLO0PsTxzSFD4Y5FtjDvN4uGvYjaFuM1Mjs8iNeyv
	 vLE1Q0WaWpVfg==
Date: Fri, 3 Jan 2025 15:21:16 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Andrew Cooper <andrew.cooper3@citrix.com>
cc: Xen-devel <xen-devel@lists.xenproject.org>, 
    Jan Beulich <JBeulich@suse.com>, 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
    Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, 
    Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>, 
    Bertrand Marquis <bertrand.marquis@arm.com>, 
    Michal Orzel <michal.orzel@amd.com>, 
    Oleksii Kurochko <oleksii.kurochko@gmail.com>, 
    Shawn Anastasio <sanastasio@raptorengineering.com>
Subject: Re: [PATCH 1/5] xen/perfc: Drop arch_perfc_{gather,reset}()
In-Reply-To: <20250102192508.2405687-2-andrew.cooper3@citrix.com>
Message-ID: <alpine.DEB.2.22.394.2501031521100.16425@ubuntu-linux-20-04-desktop>
References: <20250102192508.2405687-1-andrew.cooper3@citrix.com> <20250102192508.2405687-2-andrew.cooper3@citrix.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-515934889-1735946480=:16425"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-515934889-1735946480=:16425
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Thu, 2 Jan 2025, Andrew Cooper wrote:
> These were only ever used by the IA64 port, which was droped in commit
> 570c311ca2c7 ("remove ia64").
> 
> Remove them, and clean up the arm/x86 stub headers.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
> CC: Jan Beulich <JBeulich@suse.com>
> CC: Roger Pau Monné <roger.pau@citrix.com>
> CC: Stefano Stabellini <sstabellini@kernel.org>
> CC: Julien Grall <julien@xen.org>
> CC: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
> CC: Bertrand Marquis <bertrand.marquis@arm.com>
> CC: Michal Orzel <michal.orzel@amd.com>
> CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> CC: Shawn Anastasio <sanastasio@raptorengineering.com>
> ---
>  xen/arch/arm/include/asm/perfc.h | 21 ---------------------
>  xen/arch/x86/include/asm/perfc.h | 12 ------------
>  xen/common/perfc.c               |  6 ------
>  3 files changed, 39 deletions(-)
>  delete mode 100644 xen/arch/arm/include/asm/perfc.h
>  delete mode 100644 xen/arch/x86/include/asm/perfc.h
> 
> diff --git a/xen/arch/arm/include/asm/perfc.h b/xen/arch/arm/include/asm/perfc.h
> deleted file mode 100644
> index 95c4b2b6b7bf..000000000000
> --- a/xen/arch/arm/include/asm/perfc.h
> +++ /dev/null
> @@ -1,21 +0,0 @@
> -#ifndef __ASM_PERFC_H__
> -#define __ASM_PERFC_H__
> -
> -static inline void arch_perfc_reset(void)
> -{
> -}
> -
> -static inline void arch_perfc_gather(void)
> -{
> -}
> -
> -#endif
> -
> -/*
> - * Local variables:
> - * mode: C
> - * c-file-style: "BSD"
> - * c-basic-offset: 4
> - * indent-tabs-mode: nil
> - * End:
> - */
> diff --git a/xen/arch/x86/include/asm/perfc.h b/xen/arch/x86/include/asm/perfc.h
> deleted file mode 100644
> index a1a591e803a6..000000000000
> --- a/xen/arch/x86/include/asm/perfc.h
> +++ /dev/null
> @@ -1,12 +0,0 @@
> -#ifndef __ASM_PERFC_H__
> -#define __ASM_PERFC_H__
> -
> -static inline void arch_perfc_reset(void)
> -{
> -}
> -
> -static inline void arch_perfc_gather(void)
> -{
> -}
> -
> -#endif
> diff --git a/xen/common/perfc.c b/xen/common/perfc.c
> index 80480aa7766d..ed4dba36f1bc 100644
> --- a/xen/common/perfc.c
> +++ b/xen/common/perfc.c
> @@ -8,7 +8,6 @@
>  #include <xen/mm.h>
>  #include <xen/guest_access.h>
>  #include <public/sysctl.h>
> -#include <asm/perfc.h>
>  
>  #define PERFCOUNTER( var, name )              { name, TYPE_SINGLE, 0 },
>  #define PERFCOUNTER_ARRAY( var, name, size )  { name, TYPE_ARRAY,  size },
> @@ -148,8 +147,6 @@ void cf_check perfc_reset(unsigned char key)
>              break;
>          }
>      }
> -
> -    arch_perfc_reset();
>  }
>  
>  static struct xen_sysctl_perfc_desc perfc_d[NR_PERFCTRS];
> @@ -199,9 +196,6 @@ static int perfc_copy_info(XEN_GUEST_HANDLE_64(xen_sysctl_perfc_desc_t) desc,
>      if ( perfc_vals == NULL )
>          return -ENOMEM;
>  
> -    /* Architecture may fill counters from hardware.  */
> -    arch_perfc_gather();
> -
>      /* We gather the counts together every time. */
>      for ( i = j = v = 0; i < NR_PERFCTRS; i++ )
>      {
> -- 
> 2.39.5
> 
--8323329-515934889-1735946480=:16425--


From xen-devel-bounces@lists.xenproject.org Fri Jan 03 23:29:24 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Jan 2025 23:29:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864667.1275885 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTr6V-0001Jp-KL; Fri, 03 Jan 2025 23:29:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864667.1275885; Fri, 03 Jan 2025 23:29:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTr6V-0001Ji-HS; Fri, 03 Jan 2025 23:29:19 +0000
Received: by outflank-mailman (input) for mailman id 864667;
 Fri, 03 Jan 2025 23:29: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
 <SRS0=79/6=T3=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tTr6U-0001Jc-Is
 for xen-devel@lists.xenproject.org; Fri, 03 Jan 2025 23:29:18 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8bf14b1b-ca2a-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 00:29:16 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 1F8BEA41189;
 Fri,  3 Jan 2025 23:27:26 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3F820C4CEDD;
 Fri,  3 Jan 2025 23:29:13 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8bf14b1b-ca2a-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1735946954;
	bh=hc7q+WryTt942r3uQCeUK51Kjvlaohg5KXYEpHUpdoo=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=HZTnvg2hqv1NGd6JmwmtQidZCbvSbQD1KpB6lcAaEpinV9DkgnL5xbIKvBCAyYY3x
	 DBYmkmbUexiSaDii4xuxkI52m36bKjyKtb6pAPLQUK468oL4w07cTOSAanNxSlgOyv
	 kmzDskTwfeqOv1rCMt/1OZzOLDx10ryVepG3gVW+7/HoflHe/dxxjkbkmdw2nvO2PJ
	 8aSamR71Wu9z5BEd23aQWyxMbZSK6a6kYOQAvUe4P/HuH34qIDDf838RpTjjf6i9YS
	 N3nEW6lba729QMtHi+5ECuB1jEb/0+t3npFUbFMvd3g/XNJZMFE3ODOa46T3Ox4Esr
	 FV0E+nXkoQx0g==
Date: Fri, 3 Jan 2025 15:29:10 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Andrew Cooper <andrew.cooper3@citrix.com>
cc: Xen-devel <xen-devel@lists.xenproject.org>, 
    Jan Beulich <JBeulich@suse.com>, 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
    Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, 
    Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>, 
    Bertrand Marquis <bertrand.marquis@arm.com>, 
    Michal Orzel <michal.orzel@amd.com>, 
    Oleksii Kurochko <oleksii.kurochko@gmail.com>, 
    Shawn Anastasio <sanastasio@raptorengineering.com>
Subject: Re: [PATCH 2/5] xen/perfc: Add perfc_defn.h to asm-generic
In-Reply-To: <20250102192508.2405687-3-andrew.cooper3@citrix.com>
Message-ID: <alpine.DEB.2.22.394.2501031525580.16425@ubuntu-linux-20-04-desktop>
References: <20250102192508.2405687-1-andrew.cooper3@citrix.com> <20250102192508.2405687-3-andrew.cooper3@citrix.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-813812359-1735946954=:16425"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-813812359-1735946954=:16425
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Thu, 2 Jan 2025, Andrew Cooper wrote:
> ... and hook it up for RISC-V and PPC.
> 
> On RISC-V at least, no combination of headers pulls in errno.h, so include it
> explicitly.
> 
> Guard the hypercalls array declaration based on NR_hypercalls existing.  This
> is sufficient to get PERF_COUNTERS fully working on RISC-V and PPC, so drop
> the randconfig override.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> CC: Jan Beulich <JBeulich@suse.com>
> CC: Roger Pau Monné <roger.pau@citrix.com>
> CC: Stefano Stabellini <sstabellini@kernel.org>
> CC: Julien Grall <julien@xen.org>
> CC: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
> CC: Bertrand Marquis <bertrand.marquis@arm.com>
> CC: Michal Orzel <michal.orzel@amd.com>
> CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> CC: Shawn Anastasio <sanastasio@raptorengineering.com>
> ---
>  automation/gitlab-ci/build.yaml      | 1 -
>  xen/arch/ppc/include/asm/Makefile    | 1 +
>  xen/arch/riscv/include/asm/Makefile  | 1 +
>  xen/common/perfc.c                   | 1 +
>  xen/include/asm-generic/perfc_defn.h | 5 +++++
>  xen/include/xen/perfc_defn.h         | 2 ++
>  6 files changed, 10 insertions(+), 1 deletion(-)
>  create mode 100644 xen/include/asm-generic/perfc_defn.h
> 
> diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
> index 1b884cc81cdb..41f17ed45641 100644
> --- a/automation/gitlab-ci/build.yaml
> +++ b/automation/gitlab-ci/build.yaml
> @@ -734,7 +734,6 @@ debian-12-riscv64-gcc:
>        CONFIG_GRANT_TABLE=n
>        CONFIG_LIVEPATCH=n
>        CONFIG_MEM_ACCESS=n
> -      CONFIG_PERF_COUNTERS=n
>        CONFIG_QEMU_PLATFORM=y
>        CONFIG_XSM=n
>  
> diff --git a/xen/arch/ppc/include/asm/Makefile b/xen/arch/ppc/include/asm/Makefile
> index ced02e26ed13..c989a7f89b34 100644
> --- a/xen/arch/ppc/include/asm/Makefile
> +++ b/xen/arch/ppc/include/asm/Makefile
> @@ -7,6 +7,7 @@ generic-y += hypercall.h
>  generic-y += iocap.h
>  generic-y += paging.h
>  generic-y += percpu.h
> +generic-y += perfc_defn.h
>  generic-y += random.h
>  generic-y += softirq.h
>  generic-y += vm_event.h
> diff --git a/xen/arch/riscv/include/asm/Makefile b/xen/arch/riscv/include/asm/Makefile
> index ced02e26ed13..c989a7f89b34 100644
> --- a/xen/arch/riscv/include/asm/Makefile
> +++ b/xen/arch/riscv/include/asm/Makefile
> @@ -7,6 +7,7 @@ generic-y += hypercall.h
>  generic-y += iocap.h
>  generic-y += paging.h
>  generic-y += percpu.h
> +generic-y += perfc_defn.h
>  generic-y += random.h
>  generic-y += softirq.h
>  generic-y += vm_event.h
> diff --git a/xen/common/perfc.c b/xen/common/perfc.c
> index ed4dba36f1bc..8c967ab900f9 100644
> --- a/xen/common/perfc.c
> +++ b/xen/common/perfc.c
> @@ -1,4 +1,5 @@
>  
> +#include <xen/errno.h>
>  #include <xen/lib.h>
>  #include <xen/smp.h>
>  #include <xen/time.h>
> diff --git a/xen/include/asm-generic/perfc_defn.h b/xen/include/asm-generic/perfc_defn.h
> new file mode 100644
> index 000000000000..8237636d83fb
> --- /dev/null
> +++ b/xen/include/asm-generic/perfc_defn.h
> @@ -0,0 +1,5 @@
> +/* This file is legitimately included multiple times. */

It is a good idea to add comment here to explain. This is effectively
the same as a deviation of MISRA D4.10. SAF-8-safe is defined as
"Headers that deliberatively leave the responsability of their correct
inclusion to the caller are allowed". I think it applies, please add
SAF-8-safe to this comment and also the other perfc_defn.h, e.g.:

/* SAF-8-safe This file is legitimately included multiple times. */


> +/* #ifndef ASM_GENERIC_PERFC_DEFN_H */
> +/* #define ASM_GENERIC_PERFC_DEFN_H */
> +
> +/* #endif ASM_GENERIC_PERFC_DEFN_H */
> diff --git a/xen/include/xen/perfc_defn.h b/xen/include/xen/perfc_defn.h
> index 0027d95a60bc..a987d80dd6f1 100644
> --- a/xen/include/xen/perfc_defn.h
> +++ b/xen/include/xen/perfc_defn.h
> @@ -4,7 +4,9 @@
>  
>  #include <asm/perfc_defn.h>
>  
> +#ifdef NR_hypercalls
>  PERFCOUNTER_ARRAY(hypercalls,           "hypercalls", NR_hypercalls)
> +#endif
>  
>  PERFCOUNTER(calls_from_multicall,       "calls from multicall")
>  
> -- 
> 2.39.5
> 
--8323329-813812359-1735946954=:16425--


From xen-devel-bounces@lists.xenproject.org Fri Jan 03 23:35:49 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Jan 2025 23:35:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864678.1275899 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTrCi-0003Db-Da; Fri, 03 Jan 2025 23:35:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864678.1275899; Fri, 03 Jan 2025 23:35:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTrCi-0003DU-Ak; Fri, 03 Jan 2025 23:35:44 +0000
Received: by outflank-mailman (input) for mailman id 864678;
 Fri, 03 Jan 2025 23:35: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
 <SRS0=79/6=T3=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tTrCh-0003DO-33
 for xen-devel@lists.xenproject.org; Fri, 03 Jan 2025 23:35:43 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 70e3ea78-ca2b-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 00:35:40 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id ECBE55C60E1;
 Fri,  3 Jan 2025 23:34:57 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 06F0EC4CEDD;
 Fri,  3 Jan 2025 23:35:36 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 70e3ea78-ca2b-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1735947338;
	bh=FNLs91gebbCJP/YijGqKRSCbaSDrxjRRVLBXS/RllCY=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=o1id1a0zy0Gsg6Ep96QetJXw1ngDZF3rYyvoKdQDEvB4uPlncjtQ5Cy+cwm4ygNic
	 ah198OJUWGjAWWoP7W+N7R/j/vFxljBG3w4qfGLrQzNOUT7p8kw+TOdptLCFpEWpwU
	 +ybL7X1ppivg0MtkNGcyvc1sP3LJcWlmpKOwJDcz17/FIdjmNZQVjJj40yK9nIVFel
	 CxFv45bRmjla0MaK261WvctpeQfZetx9iqQ/kP9NZ1U+iIkcsiIlURi+el82EHBY/v
	 UoHX4DvPaw453JWL/6TU/nzb76HjI5oHBzMJZjvttvQe4gwFkNZ8MhkELL77ECF5T3
	 pjuceuZnkT9Kg==
Date: Fri, 3 Jan 2025 15:35:34 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Andrew Cooper <andrew.cooper3@citrix.com>
cc: Xen-devel <xen-devel@lists.xenproject.org>, 
    Jan Beulich <JBeulich@suse.com>, 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
    Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, 
    Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>, 
    Bertrand Marquis <bertrand.marquis@arm.com>, 
    Michal Orzel <michal.orzel@amd.com>, 
    Oleksii Kurochko <oleksii.kurochko@gmail.com>, 
    Shawn Anastasio <sanastasio@raptorengineering.com>
Subject: Re: [PATCH 3/5] xen/perfc: Trim includes
In-Reply-To: <20250102192508.2405687-4-andrew.cooper3@citrix.com>
Message-ID: <alpine.DEB.2.22.394.2501031535290.16425@ubuntu-linux-20-04-desktop>
References: <20250102192508.2405687-1-andrew.cooper3@citrix.com> <20250102192508.2405687-4-andrew.cooper3@citrix.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1489689879-1735947338=:16425"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-1489689879-1735947338=:16425
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Thu, 2 Jan 2025, Andrew Cooper wrote:
> This is mostly for the removal of xen/lib.h and xen/smp.h from perfc.h.  All
> that is needed is xen/macros.h.
> 
> Trim and sort the includes for perfc.c too.  There's no need for smp.h,
> keyhandler.h or mm.h, but cpumask.h is needed.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
> CC: Jan Beulich <JBeulich@suse.com>
> CC: Roger Pau Monné <roger.pau@citrix.com>
> CC: Stefano Stabellini <sstabellini@kernel.org>
> CC: Julien Grall <julien@xen.org>
> CC: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
> CC: Bertrand Marquis <bertrand.marquis@arm.com>
> CC: Michal Orzel <michal.orzel@amd.com>
> CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> CC: Shawn Anastasio <sanastasio@raptorengineering.com>
> ---
>  xen/common/perfc.c      | 9 ++++-----
>  xen/include/xen/perfc.h | 3 +--
>  2 files changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/xen/common/perfc.c b/xen/common/perfc.c
> index 8c967ab900f9..b748c8af855b 100644
> --- a/xen/common/perfc.c
> +++ b/xen/common/perfc.c
> @@ -1,13 +1,12 @@
>  
> +#include <xen/cpumask.h>
>  #include <xen/errno.h>
> +#include <xen/guest_access.h>
>  #include <xen/lib.h>
> -#include <xen/smp.h>
> -#include <xen/time.h>
>  #include <xen/perfc.h>
> -#include <xen/keyhandler.h> 
>  #include <xen/spinlock.h>
> -#include <xen/mm.h>
> -#include <xen/guest_access.h>
> +#include <xen/time.h>
> +
>  #include <public/sysctl.h>
>  
>  #define PERFCOUNTER( var, name )              { name, TYPE_SINGLE, 0 },
> diff --git a/xen/include/xen/perfc.h b/xen/include/xen/perfc.h
> index f9009dc388de..324b47665573 100644
> --- a/xen/include/xen/perfc.h
> +++ b/xen/include/xen/perfc.h
> @@ -3,8 +3,7 @@
>  
>  #ifdef CONFIG_PERF_COUNTERS
>  
> -#include <xen/lib.h>
> -#include <xen/smp.h>
> +#include <xen/macros.h>
>  #include <xen/percpu.h>
>  
>  /*
> -- 
> 2.39.5
> 
--8323329-1489689879-1735947338=:16425--


From xen-devel-bounces@lists.xenproject.org Fri Jan 03 23:36:36 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Jan 2025 23:36:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864686.1275908 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTrDY-0003iN-M3; Fri, 03 Jan 2025 23:36:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864686.1275908; Fri, 03 Jan 2025 23:36:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTrDY-0003iG-JO; Fri, 03 Jan 2025 23:36:36 +0000
Received: by outflank-mailman (input) for mailman id 864686;
 Fri, 03 Jan 2025 23:36: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
 <SRS0=79/6=T3=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tTrDW-0003hr-Kv
 for xen-devel@lists.xenproject.org; Fri, 03 Jan 2025 23:36:34 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9042c07b-ca2b-11ef-a0de-8be0dac302b0;
 Sat, 04 Jan 2025 00:36:33 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id EE163A409EC;
 Fri,  3 Jan 2025 23:34:42 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0C6A9C4CEDD;
 Fri,  3 Jan 2025 23:36:29 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9042c07b-ca2b-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1735947391;
	bh=a9nOPusxtPFWkaIJaF6kGeuTmu+Olo0EOeybaF8ecdk=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=h2u5UKs3gX4otiTE/Dc1wL5H2nCKK6xOLLfvS+AD9idITOXEq4jcLE3ftr036BL4n
	 zx7sB0nHBDPguESJSBM+ZV2jNEs8RJZ8e6lluY07jMPZI8ynIpq7Fg8HRRJOYyHyMd
	 +iUQkMODA6QjuqnOIGMwFurP/PfihDrr9w+WlSD5mK5bDQaNp1R2S6Ai57Nxj5SOat
	 o2lobrSa/fWmrLb6PG0JgSuiebhOP0De9oxpJN2FxLqwE3BHQCRXn8hQKgAAqH8iGl
	 K82VEOhklpL4LEneJFdfzzxwVUUfJHqnRxNXXpKpHYC8fC0Jqp+0SorB9HSNttDqkQ
	 ikBmaueV66nBw==
Date: Fri, 3 Jan 2025 15:36:28 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Andrew Cooper <andrew.cooper3@citrix.com>
cc: Xen-devel <xen-devel@lists.xenproject.org>, 
    Jan Beulich <JBeulich@suse.com>, 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
    Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, 
    Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>, 
    Bertrand Marquis <bertrand.marquis@arm.com>, 
    Michal Orzel <michal.orzel@amd.com>, 
    Oleksii Kurochko <oleksii.kurochko@gmail.com>, 
    Shawn Anastasio <sanastasio@raptorengineering.com>
Subject: Re: [PATCH 4/5] xen/perfc: Cleanup
In-Reply-To: <20250102192508.2405687-5-andrew.cooper3@citrix.com>
Message-ID: <alpine.DEB.2.22.394.2501031536220.16425@ubuntu-linux-20-04-desktop>
References: <20250102192508.2405687-1-andrew.cooper3@citrix.com> <20250102192508.2405687-5-andrew.cooper3@citrix.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-892678208-1735947391=:16425"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-892678208-1735947391=:16425
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Thu, 2 Jan 2025, Andrew Cooper wrote:
>  * Strip trailing whitspace.
>  * Remove PRIperfc.  It has never been used and isn't useful.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
> CC: Jan Beulich <JBeulich@suse.com>
> CC: Roger Pau Monné <roger.pau@citrix.com>
> CC: Stefano Stabellini <sstabellini@kernel.org>
> CC: Julien Grall <julien@xen.org>
> CC: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
> CC: Bertrand Marquis <bertrand.marquis@arm.com>
> CC: Michal Orzel <michal.orzel@amd.com>
> CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> CC: Shawn Anastasio <sanastasio@raptorengineering.com>
> ---
>  xen/common/perfc.c      | 10 +++++-----
>  xen/include/xen/perfc.h | 23 +++++++++++------------
>  2 files changed, 16 insertions(+), 17 deletions(-)
> 
> diff --git a/xen/common/perfc.c b/xen/common/perfc.c
> index b748c8af855b..8302b7cf6db1 100644
> --- a/xen/common/perfc.c
> +++ b/xen/common/perfc.c
> @@ -46,7 +46,7 @@ void cf_check perfc_printall(unsigned char key)
>          case TYPE_S_SINGLE:
>              for_each_online_cpu ( cpu )
>                  sum += per_cpu(perfcounters, cpu)[j];
> -            if ( perfc_info[i].type == TYPE_S_SINGLE ) 
> +            if ( perfc_info[i].type == TYPE_S_SINGLE )
>                  sum = (perfc_t) sum;
>              printk("TOTAL[%12Lu]", sum);
>              if ( sum )
> @@ -56,7 +56,7 @@ void cf_check perfc_printall(unsigned char key)
>                  {
>                      if ( k > 0 && (k % 4) == 0 )
>                          printk("\n%53s", "");
> -                    printk("  CPU%02u[%10"PRIperfc"u]", cpu, per_cpu(perfcounters, cpu)[j]);
> +                    printk("  CPU%02u[%10u]", cpu, per_cpu(perfcounters, cpu)[j]);
>                      ++k;
>                  }
>              }
> @@ -71,7 +71,7 @@ void cf_check perfc_printall(unsigned char key)
>                  for ( k = 0; k < perfc_info[i].nr_elements; k++ )
>                      sum += counters[k];
>              }
> -            if ( perfc_info[i].type == TYPE_S_ARRAY ) 
> +            if ( perfc_info[i].type == TYPE_S_ARRAY )
>                  sum = (perfc_t) sum;
>              printk("TOTAL[%12Lu]", sum);
>              if (sum)
> @@ -82,7 +82,7 @@ void cf_check perfc_printall(unsigned char key)
>                      sum = 0;
>                      for_each_online_cpu ( cpu )
>                          sum += per_cpu(perfcounters, cpu)[j + k];
> -                    if ( perfc_info[i].type == TYPE_S_ARRAY ) 
> +                    if ( perfc_info[i].type == TYPE_S_ARRAY )
>                          sum = (perfc_t) sum;
>                      if ( (k % 4) == 0 )
>                          printk("\n%16s", "");
> @@ -98,7 +98,7 @@ void cf_check perfc_printall(unsigned char key)
>                      sum = 0;
>                      for ( n = 0; n < perfc_info[i].nr_elements; n++ )
>                          sum += counters[n];
> -                    if ( perfc_info[i].type == TYPE_S_ARRAY ) 
> +                    if ( perfc_info[i].type == TYPE_S_ARRAY )
>                          sum = (perfc_t) sum;
>                      if ( k > 0 && (k % 4) == 0 )
>                          printk("\n%53s", "");
> diff --git a/xen/include/xen/perfc.h b/xen/include/xen/perfc.h
> index 324b47665573..bf0eb032f7a9 100644
> --- a/xen/include/xen/perfc.h
> +++ b/xen/include/xen/perfc.h
> @@ -8,24 +8,24 @@
>  
>  /*
>   * NOTE: new counters must be defined in perfc_defn.h
> - * 
> + *
>   * Counter declarations:
>   * PERFCOUNTER (counter, string)              define a new performance counter
>   * PERFCOUNTER_ARRAY (counter, string, size)  define an array of counters
> - * 
> + *
>   * Unlike counters, status variables do not reset:
>   * PERFSTATUS (counter, string)               define a new performance stauts
>   * PERFSTATUS_ARRAY (counter, string, size)   define an array of status vars
> - * 
> - * unsigned long perfc_value  (counter)        get value of a counter  
> + *
> + * unsigned long perfc_value  (counter)        get value of a counter
>   * unsigned long perfc_valuea (counter, index) get value of an array counter
> - * unsigned long perfc_set  (counter, val)     set value of a counter  
> + * unsigned long perfc_set  (counter, val)     set value of a counter
>   * unsigned long perfc_seta (counter, index, val) set value of an array counter
> - * void perfc_incr  (counter)                  increment a counter          
> + * void perfc_incr  (counter)                  increment a counter
>   * void perfc_decr  (counter)                  decrement a status
> - * void perfc_incra (counter, index)           increment an array counter   
> - * void perfc_add   (counter, value)           add a value to a counter     
> - * void perfc_adda  (counter, index, value)    add a value to array counter 
> + * void perfc_incra (counter, index)           increment an array counter
> + * void perfc_add   (counter, value)           add a value to a counter
> + * void perfc_adda  (counter, index, value)    add a value to array counter
>   * void perfc_print (counter)                  print out the counter
>   */
>  
> @@ -49,7 +49,6 @@ enum {
>  #undef PERFSTATUS_ARRAY
>  
>  typedef unsigned int perfc_t;
> -#define PRIperfc ""
>  
>  DECLARE_PER_CPU(perfc_t[NUM_PERFCOUNTERS], perfcounters);
>  
> @@ -72,7 +71,7 @@ DECLARE_PER_CPU(perfc_t[NUM_PERFCOUNTERS], perfcounters);
>  	 this_cpu(perfcounters)[PERFC_ ## x + (y)] = (v) : (v) )
>  
>  /*
> - * Histogram: special treatment for 0 and 1 count. After that equally spaced 
> + * Histogram: special treatment for 0 and 1 count. After that equally spaced
>   * with last bucket taking the rest.
>   */
>  #ifdef CONFIG_PERF_ARRAYS
> @@ -98,7 +97,7 @@ int perfc_control(struct xen_sysctl_perfc_op *pc);
>  extern void cf_check perfc_printall(unsigned char key);
>  extern void cf_check perfc_reset(unsigned char key);
>  
> -    
> +
>  #else /* CONFIG_PERF_COUNTERS */
>  
>  #define perfc_value(x)    (0)
> -- 
> 2.39.5
> 
--8323329-892678208-1735947391=:16425--


From xen-devel-bounces@lists.xenproject.org Sat Jan 04 00:21:08 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 00:21:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864695.1275919 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTruX-00031R-D4; Sat, 04 Jan 2025 00:21:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864695.1275919; Sat, 04 Jan 2025 00:21:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTruX-00031K-9Q; Sat, 04 Jan 2025 00:21:01 +0000
Received: by outflank-mailman (input) for mailman id 864695;
 Sat, 04 Jan 2025 00:20: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
 <SRS0=MbXJ=T4=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tTruV-00031D-BE
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 00:20:59 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c4038695-ca31-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 01:20:57 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id AE367A4109D;
 Sat,  4 Jan 2025 00:19:06 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 63EF2C4CEDD;
 Sat,  4 Jan 2025 00:20:54 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c4038695-ca31-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1735950055;
	bh=d2gXTBle0r2rC3VZD8twpKsd0+v0LbFWXpI1d0H/QK8=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=EWSKzH+IWtdilP56Jf902jlgQg8YrQtVfcekqGJz7ezkZTFiZtbkNomEY8f63Nij8
	 pBf+2C9QsMCRY4uDawvxa+BAtbeqPO6XSpTR1qT7Hk2zuQ9Zg3vSDC+F6P4jKPBhOy
	 trXmr9sduQhoNlzHVrLOXHznoOF+L9RqokhUuiyseQE1R8/++WnAKo08LDrWC2O/uA
	 k9nyZGCnpabLCKXNINVNSXDGvgmebLwsOKbyBZDH5hW2zSP1rqO+XREdRvZ09ZTWa7
	 9YcxYenk5TY48ZjLwakINHvqwqL+7R39qbD2EoLBXVY3CMTaV5DJZ9TWD3L33G9H1N
	 NJwsIrBhGoUaQ==
Date: Fri, 3 Jan 2025 16:20:52 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Nicola Vetrini <nicola.vetrini@bugseng.com>
cc: Jan Beulich <jbeulich@suse.com>, Roger Pau Monne <roger.pau@citrix.com>, 
    Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xenproject.org, 
    Stefano Stabellini <sstabellini@kernel.org>, consulting@bugseng.com
Subject: Re: [PATCH v2 1/2] x86/uaccess: rework user access speculative harden
 guards
In-Reply-To: <e3ec3dad28dc94436c0b330b2f995120@bugseng.com>
Message-ID: <alpine.DEB.2.22.394.2501031617280.16425@ubuntu-linux-20-04-desktop>
References: <20241126093508.6966-1-roger.pau@citrix.com> <20241126093508.6966-2-roger.pau@citrix.com> <cf1f87d1-f616-4944-94fa-69a777249072@suse.com> <e3ec3dad28dc94436c0b330b2f995120@bugseng.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

Hi Nicola, one question below

On Wed, 27 Nov 2024, Nicola Vetrini wrote:
> > #define AMD_OSVW_ERRATUM(osvw_id, ...)  osvw_id, __VA_ARGS__, 0
> > 
> > where we're using the C99 form rather than the GNU extension, and where
> > hence __VA_ARGS__ would - by extrapolation of the Misra rule - need
> > parenthesizing, when it isn't and can't be.
> > 
> > Isn't it rather the case that variable argument macros need a more general
> > deviation, if not an adjustment to the Misra rule? Extending the Cc list
> > some ...

Nicola, if you look at the original patch:
https://marc.info/?l=xen-devel&m=173261356716876

"The current guards to select whether user accesses should be speculative
hardened violate Misra rule 20.7, as the UA_KEEP() macro doesn't (and can't)
parenthesize the 'args' argument."

And the very first change in the patch is:

diff --git a/xen/arch/x86/include/asm/uaccess.h b/xen/arch/x86/include/asm/uaccess.h
index 2d01669b96..6b8150ac22 100644
--- a/xen/arch/x86/include/asm/uaccess.h
+++ b/xen/arch/x86/include/asm/uaccess.h
@@ -24,9 +24,6 @@ unsigned int copy_from_unsafe_ll(void *to, const void *from, unsigned int n);
 void noreturn __get_user_bad(void);
 void noreturn __put_user_bad(void);
 
-#define UA_KEEP(args...) args
-#define UA_DROP(args...)
-
 /**
  * get_guest: - Get a simple variable from guest space.
  * @x:   Variable to store result.
 

Do you think there is any way we could configure Eclair, with or without
a deviation, not to detect every use of UA_KEEP as violations?


From xen-devel-bounces@lists.xenproject.org Sat Jan 04 01:58:28 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 01:58:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864709.1275983 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtQm-0006FD-A1; Sat, 04 Jan 2025 01:58:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864709.1275983; Sat, 04 Jan 2025 01:58:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtQl-0006Ct-SM; Sat, 04 Jan 2025 01:58:23 +0000
Received: by outflank-mailman (input) for mailman id 864709;
 Sat, 04 Jan 2025 01:58:21 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=AhC6=T4=kernel.org=devnull+dmukhin.ford.com@srs-se1.protection.inumbo.net>)
 id 1tTtQj-0005Ay-Gq
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 01:58:21 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5c7b8b6b-ca3f-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 02:58:16 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 8F53E5C6009;
 Sat,  4 Jan 2025 01:57:33 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPS id 9F0E4C4CED6;
 Sat,  4 Jan 2025 01:58:14 +0000 (UTC)
Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org
 (localhost.localdomain [127.0.0.1])
 by smtp.lore.kernel.org (Postfix) with ESMTP id 8BB62E77188;
 Sat,  4 Jan 2025 01:58:14 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5c7b8b6b-ca3f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1735955894;
	bh=1HQw4baaGqIA4Q4VIxDGGIV5uTvw8beKaHffthhNRSs=;
	h=From:Subject:Date:To:Cc:Reply-To:From;
	b=ktgD9ioY/Z9BoGCJD9pBEQT8YQHZ8NRHqKgs9CtlAAS0aZuO05QARNBA3UgfjcHVk
	 hVj7DuCm7oHa6KvGPBjl4I+9egxt7Kb2xrNdJwyMiDhorLLM8nHLBgfZe54YiJ7aZj
	 VFpxp8Cs2n+mYtjeJQmrDJvpWZ5GPftchlCt9+lrPBySRzpSdsuUm0PJ9yiTWxZ21i
	 Y8SXugn/+IduPMYM3KrnV8EGhqUpXxtU9MwUQChqkqqdjJmAhWVQPbR6s8CpztJLBY
	 Iw8k6fm7gVyU1D3pk+sitpJpIV5d8FxRQiZLp2op7/6xg1ni99EfuRuoa30jGc0Jys
	 /JW/dZyQcsjmw==
From: Denis Mukhin via B4 Relay <devnull+dmukhin.ford.com@kernel.org>
Subject: [PATCH v3 00/24] x86: introduce NS16550-compatible UART emulator
Date: Fri, 03 Jan 2025 17:58:06 -0800
Message-Id: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-B4-Tracking: v=1; b=H4sIAK+VeGcC/x3MQQqAIBBA0avIrBtwlDC6SrSQGms2FloShHdPW
 r7F/y9kTsIZRvVC4iJZjthAnYJl93FjlLUZjDa9Jm2x3D5dGPPQjMViGJiItHMuMLTqTBzk+Y8
 TFAtzrR/CAUqbZQAAAA==
X-Change-ID: 20250103-vuart-ns8250-v3-f8e1110777fe
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>, 
 Julien Grall <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, Jan Beulich <jbeulich@suse.com>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
 Denis Mukhin <dmukhin@ford.com>
X-Mailer: b4 0.14.2
X-Developer-Signature: v=1; a=ed25519-sha256; t=1735955892; l=9222;
 i=dmukhin@ford.com; s=20241125; h=from:subject:message-id;
 bh=1HQw4baaGqIA4Q4VIxDGGIV5uTvw8beKaHffthhNRSs=;
 b=fkDafXWa43fpq2gRtrfNjRvLOzfCHdAEdZg4Ae1fWU5Q36l4DhEJsA4pzz2lXgYR4pH/a+Q90
 EaLxVy/2LdFALar/4HQfBr773t0jIui/Uy/5xfvDBim/oZDzPZGytyh
X-Developer-Key: i=dmukhin@ford.com; a=ed25519;
 pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U=
X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with
 auth_id=287
X-Original-From: Denis Mukhin <dmukhin@ford.com>
Reply-To: dmukhin@ford.com

x86 port of Xen lacks vUART facility similar to Arm's vpl011 to support x86
guest OS bring up in the embedded setups.

This patch series introduces initial in-hypervisor emulator for
NS8250/NS16x50-compatible UARTs under CONFIG_VUART_NS16550.

In parallel domain creation scenario (hyperlaunch), NS16550 emulator helps
early guest firmware and OS bringup debugging, because it eliminates dependency
on the external emulator (qemu) being operational by the time domains are
created.

The emulator also allows to forward the physical console input to the x86
domain which is useful when a system has only one physical UART for early
debugging and this UART is owned by Xen.

By default, CONFIG_VUART_NS16550 enables emulation of NS16550 at I/O port
0x3f8, IRQ#4 in guest OS (legacy COM1).

Legacy COM resources can be selected at built-time and cannot be configured
per-domain yet.

The NS16550 emulator is disabled by default.

Series
======
- patches 1-17: preparation patches. That covers existing UART emulators
  cleanup, UART emulation framework, console driver cleanups and fixes.

- patches 18-24: initial NS16550 emulator. That adds the I/O port emulator
  for legacy PC COM UARTs, Kconfig option and enabling emulator for HVM
  domains globally and build-time.

Limitations
===========
- Only x86;
- Only HVM domains support (build-time), PVH domains are not supported yet;
- Only legacy COM{1,2,3,4} resources via Kconfig, custom I/O ports/IRQs
  are not supported;
- Only Xen console as a backend, no inter-domain communication (similar to
  vpl011 on Arm);
- Only 8n1 emulation (8-bit data, no parity, 1 stop bit);
- No toolstack integration;
- No baud rate emulation (reports 115200 baud to the guest OS);
- No FIFO-less mode emulation;
- No RX FIFO interrupt moderation (FCR) emulation;
- No integration w/ VM snapshotting (HVM_REGISTER_SAVE_RESTORE() and
  friends);
- No ISA IRQ sharing allowed;
- No MMIO-based UART emulation.

Testing
=======

Gitlab CI
  https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/1610989357

Manual Testing
  I tested boot of HVM linux guest w/ OVMF as the virtual firmware.

  The emulator, if enabled via CONFIG_VUART_NS16550=y, will use COM1
  (0x3f8) resources by default.

  To test w/ virtual COM1, the guest kernel parameters should contain
    earlycon=uart,io,0x3f8,115200n8 console=uart,io,0x3f8,115200n8

  Xen is able to forward physical console input to the domain w/ virtual
  NS16550. To switch the console focus press Ctrl+aaa. If console= is given to
  the HVM kernel, then the user shall be able to see the login prompt on xen
  console once console focus is switched to the HVM guest.

---
Changes in v3:
- renamed emulator s/NS8250/NS16550/g
- reduced the patch series after addressing v2 feedback
- introduced driver framework for UART emulators
- unified guest OS printouts across all available UART emulators
- Link to v2: https://lore.kernel.org/xen-devel/20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com/

Changes in v2:
- dropped kmalloc/kfree aliases
- fixed ECLAIR jobs (thanks Andrew Cooper)
- addressed console forwarding on arm32 and arm64 (thanks to Luca Fancellu)
- moved NS8250 debugging stubs into its own patch
- added fix for https://gitlab.com/xen-project/xen/-/issues/184
- Link to v1: https://lore.kernel.org/r/20241126-vuart-ns8250-v1-v1-0-87b9a8375b7a@ford.com
---

Signed-off-by: Denis Mukhin <dmukhin@ford.com>

---
Denis Mukhin (24):
      xen/ctype: introduce is_console_printable()
      arm/vuart: move vpl011-related code to vpl011 emulator
      arm/vuart: add hwdom prefix to UART emulator
      xen/console: introduce console_{get,put}_domain()
      xen/console: introduce consoled_is_enabled()
      xen/domain: introduce hardware emulation flags
      xen/console: introduce framework for UART emulators
      xen/console: rename switch_serial_input() to console_switch_input()
      xen/console: rename console_rx to console_owner
      xen/console: introduce use of 'is_console' flag
      xen/domain: move get_initial_domain_id() to arch-independent header
      xen/console: introduce console_{get,set}_owner()
      xen/console: introduce hwdom_crashconsole=
      xen/console: simplify console owner switch hint
      xen/console: make console buffer size configurable
      xen/console: introduce console_write()
      xen/console: flush console ring to physical console
      xen/include: introduce resource.h
      xen/8250-uart: add missing definitions
      x86/hvm: add HVM-specific Kconfig
      x86/hvm: introduce NS16550-compatible UART emulator
      x86/hvm: enable NS16550-compatible UART emulator
      docs/misc: update console documentation
      xen/console: unify printout behavior for UART emulators

 automation/eclair_analysis/ECLAIR/deviations.ecl |   1 +
 docs/misc/console.txt                            |  50 +-
 docs/misc/xen-command-line.pandoc                |  21 +-
 tools/helpers/init-xenstore-domain.c             |   1 +
 tools/libs/light/libxl_x86.c                     |   5 +-
 tools/ocaml/libs/xc/xenctrl.ml                   |   1 +
 tools/ocaml/libs/xc/xenctrl.mli                  |   1 +
 tools/ocaml/libs/xc/xenctrl_stubs.c              |   1 +
 tools/python/xen/lowlevel/xc/xc.c                |   5 +-
 tools/tests/paging-mempool/test-paging-mempool.c |   1 +
 tools/tests/resource/test-resource.c             |   1 +
 tools/tests/tsx/test-tsx.c                       |   1 +
 xen/arch/arm/Kconfig                             |   1 +
 xen/arch/arm/dom0less-build.c                    |  11 +-
 xen/arch/arm/domain.c                            |   6 +-
 xen/arch/arm/domain_build.c                      |   7 +-
 xen/arch/arm/domctl.c                            |  11 +-
 xen/arch/arm/include/asm/domain.h                |   2 +
 xen/arch/arm/include/asm/setup.h                 |   2 -
 xen/arch/arm/include/asm/vpl011.h                |  21 +-
 xen/arch/arm/setup.c                             |   2 -
 xen/arch/arm/vpl011.c                            |  57 +-
 xen/arch/arm/vuart.c                             |  49 +-
 xen/arch/arm/vuart.h                             |   8 +-
 xen/arch/arm/xen.lds.S                           |   1 +
 xen/arch/ppc/include/asm/domain.h                |   2 +
 xen/arch/ppc/include/asm/setup.h                 |   2 -
 xen/arch/ppc/xen.lds.S                           |   1 +
 xen/arch/riscv/include/asm/domain.h              |   2 +
 xen/arch/riscv/include/asm/setup.h               |   2 -
 xen/arch/riscv/xen.lds.S                         |   1 +
 xen/arch/x86/Kconfig                             |  76 +-
 xen/arch/x86/dom0_build.c                        |   2 +
 xen/arch/x86/domain.c                            |  21 +-
 xen/arch/x86/hvm/Kconfig                         | 122 +++
 xen/arch/x86/hvm/Makefile                        |   1 +
 xen/arch/x86/hvm/hvm.c                           |  14 +-
 xen/arch/x86/hvm/vuart-ns16550.c                 | 931 +++++++++++++++++++++++
 xen/arch/x86/include/asm/domain.h                |   8 +-
 xen/arch/x86/include/asm/hvm/domain.h            |   4 +
 xen/arch/x86/include/asm/pv/shim.h               |   5 +-
 xen/arch/x86/include/asm/setup.h                 |   2 -
 xen/arch/x86/pv/shim.c                           |   7 +-
 xen/arch/x86/xen.lds.S                           |   1 +
 xen/common/device-tree/device-tree.c             |  21 +-
 xen/common/domain.c                              |  31 +-
 xen/common/domctl.c                              |  11 +-
 xen/common/kernel.c                              |   8 +
 xen/common/keyhandler.c                          |   4 +
 xen/drivers/Kconfig                              |   5 +
 xen/drivers/Makefile                             |   1 +
 xen/drivers/char/Kconfig                         |  11 +
 xen/drivers/char/console.c                       | 377 +++++----
 xen/drivers/char/consoled.c                      |  17 +-
 xen/drivers/char/ns16550.c                       |   6 +-
 xen/drivers/passthrough/arm/smmu.c               |  15 +-
 xen/drivers/virtdev-uart.c                       |  68 ++
 xen/include/Makefile                             |   1 +
 xen/include/public/arch-x86/xen.h                |  30 +-
 xen/include/public/virtdev.h                     |  64 ++
 xen/include/xen/8250-uart.h                      |  78 +-
 xen/include/xen/console.h                        |   3 +-
 xen/include/xen/consoled.h                       |  32 +-
 xen/include/xen/ctype.h                          |   7 +
 xen/include/xen/domain.h                         |   9 +
 xen/include/xen/lib.h                            |   3 +
 xen/include/xen/resource.h                       |  37 +
 xen/include/xen/virtdev-uart.h                   |  72 ++
 xen/include/xen/xen.lds.h                        |  10 +
 69 files changed, 1913 insertions(+), 479 deletions(-)
---
base-commit: 7e6edeaee38c66266a941bfa66d17eeeeb492fbe
change-id: 20250103-vuart-ns8250-v3-f8e1110777fe

Best regards,
-- 
Denis Mukhin <dmukhin@ford.com>




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 01:58:28 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 01:58:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864710.1275991 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtQm-0006JW-PI; Sat, 04 Jan 2025 01:58:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864710.1275991; Sat, 04 Jan 2025 01:58:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtQm-0006Hf-7z; Sat, 04 Jan 2025 01:58:24 +0000
Received: by outflank-mailman (input) for mailman id 864710;
 Sat, 04 Jan 2025 01:58:21 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=AhC6=T4=kernel.org=devnull+dmukhin.ford.com@srs-se1.protection.inumbo.net>)
 id 1tTtQj-0005Ax-Q6
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 01:58:21 +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 5dd06576-ca3f-11ef-a0de-8be0dac302b0;
 Sat, 04 Jan 2025 02:58:18 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 1F7205C61A0;
 Sat,  4 Jan 2025 01:57:34 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPS id 2F862C4CEDF;
 Sat,  4 Jan 2025 01:58:15 +0000 (UTC)
Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org
 (localhost.localdomain [127.0.0.1])
 by smtp.lore.kernel.org (Postfix) with ESMTP id 258D1E7719A;
 Sat,  4 Jan 2025 01:58:15 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5dd06576-ca3f-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1735955895;
	bh=WkgpINAi4NmXbCPyfSBPSjKkxNTDWSdwSg5wm9hn06Q=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From;
	b=H9zfqAfx2RSRbi2EMUVSUK5A5YOdctvF9wzXgaRtutupZJbIU2q2d8AbEzvPTLyQ3
	 xBtuOwtfuHSO9BCbRcpqL13I5m3lIuSKDBhhcvRQ61SFzRTB3A5Z4lGOsmLXX2PyrK
	 A5mHdUnmnJVhFcx9Nw7Zh+ApfuGjWuwrdafH0q3tGQsrtLyCXZKJ+clySk3PJOdmDq
	 jyyCEvxnykvwyU4Ja+BNljO44nCTjVLnUyuduJK2oQLVUyVFZ9Gvbp85ObWGdR3k5t
	 X9XfdkHs1SuM2shblGWjSiiX6XsDLSjifDP6GUwcasEMmBJaNpFdh7ZsH/Kf4mCBeu
	 wDa82EC6J8jlQ==
From: Denis Mukhin via B4 Relay <devnull+dmukhin.ford.com@kernel.org>
Date: Fri, 03 Jan 2025 17:58:14 -0800
Subject: [PATCH v3 08/24] xen/console: rename switch_serial_input() to
 console_switch_input()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20250103-vuart-ns8250-v3-v1-8-c5d36b31d66c@ford.com>
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
In-Reply-To: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>, 
 Julien Grall <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, Jan Beulich <jbeulich@suse.com>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
 Denis Mukhin <dmukhin@ford.com>
X-Mailer: b4 0.14.2
X-Developer-Signature: v=1; a=ed25519-sha256; t=1735955892; l=1473;
 i=dmukhin@ford.com; s=20241125; h=from:subject:message-id;
 bh=VlrDmVYSUYYEG2sJ1u5nbMuy01Nt/S2plh2q6DJ+BIw=;
 b=S1s8vEh//WnTsVDQMRNzdQ8IrNEV/vZqF5vI012/k7AeJFUsj7kHlwgXqm6tbP8iH+pQoIZMm
 eh6s4rBUInzDHPPpwvMdJSQgTovGbPH5QGbGKna4mP/7Vse5daRUn15
X-Developer-Key: i=dmukhin@ford.com; a=ed25519;
 pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U=
X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with
 auth_id=287
X-Original-From: Denis Mukhin <dmukhin@ford.com>
Reply-To: dmukhin@ford.com

From: Denis Mukhin <dmukhin@ford.com>

Updated the name to highlight the physical console input selection logic:
existing code does not switch only serial console, it also switches debugging
console (debug I/O port and console hypercall).

Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
 xen/drivers/char/console.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 0927c0564a67098c70dab576ebeda3825fadfb61..48866cf47beda39e48a7774277238273566382b1 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -486,7 +486,7 @@ void console_put_domain(struct domain *d)
         rcu_unlock_domain(d);
 }
 
-static void switch_serial_input(void)
+static void console_switch_input(void)
 {
     unsigned int next_rx = console_rx;
 
@@ -577,7 +577,7 @@ static void cf_check serial_rx(char c)
         /* We eat CTRL-<switch_char> in groups of 3 to switch console input. */
         if ( ++switch_code_count == 3 )
         {
-            switch_serial_input();
+            console_switch_input();
             switch_code_count = 0;
         }
         return;
@@ -1117,7 +1117,7 @@ void __init console_endboot(void)
                             "toggle host/guest log level adjustment", 0);
 
     /* Serial input is directed to DOM0 by default. */
-    switch_serial_input();
+    console_switch_input();
 }
 
 int __init console_has(const char *device)

-- 
2.34.1




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 01:58:28 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 01:58:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864711.1275998 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtQn-0006dY-M9; Sat, 04 Jan 2025 01:58:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864711.1275998; Sat, 04 Jan 2025 01:58:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtQn-0006b6-BJ; Sat, 04 Jan 2025 01:58:25 +0000
Received: by outflank-mailman (input) for mailman id 864711;
 Sat, 04 Jan 2025 01:58: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
 <SRS0=AhC6=T4=kernel.org=devnull+dmukhin.ford.com@srs-se1.protection.inumbo.net>)
 id 1tTtQk-0005Ay-Gz
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 01:58:22 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5d120322-ca3f-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 02:58:17 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id AB401A411CE;
 Sat,  4 Jan 2025 01:56:26 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPS id 9937EC4CEE6;
 Sat,  4 Jan 2025 01:58:15 +0000 (UTC)
Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org
 (localhost.localdomain [127.0.0.1])
 by smtp.lore.kernel.org (Postfix) with ESMTP id 9332FE77198;
 Sat,  4 Jan 2025 01:58:15 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5d120322-ca3f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1735955895;
	bh=J1IQdeQ98d0vl6JdSs/gueZbYb4U6ovRO5LjK7ff2wk=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From;
	b=XQAZPVJ0qTKM/gXH+OPM9HCQu5UK1W10JCYvPHJREPMm+iwdwKPdyLjrd7mwZnDJ+
	 tXPEJ/sCMvOJ32DH5fK46DnIokHK4hHcNe+bgrH+ihb9KBV8EJuL6XvAITd8TqHMS6
	 EhyKA+gJbQ2R+wOSMrAP85FRIvzMWg8Yamp05s2iF5S+xZkWNkLO2zue0XNpqgcJG0
	 kV/jDoguwyMmw+JCvBmoEpsIdEc28fbXmiBrIO6PHZ+2V+LEf8ZOOYlsR5GoIV2Gwf
	 UlOT1QpwsJf0U4LvMbaaYZYXhoIJZndOXwx4/Gvs36HIen6H9EzUADxTZmPm4byDE0
	 tZkP8R9bBDm4A==
From: Denis Mukhin via B4 Relay <devnull+dmukhin.ford.com@kernel.org>
Date: Fri, 03 Jan 2025 17:58:22 -0800
Subject: [PATCH v3 16/24] xen/console: introduce console_write()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20250103-vuart-ns8250-v3-v1-16-c5d36b31d66c@ford.com>
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
In-Reply-To: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>, 
 Julien Grall <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, Jan Beulich <jbeulich@suse.com>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
 Denis Mukhin <dmukhin@ford.com>
X-Mailer: b4 0.14.2
X-Developer-Signature: v=1; a=ed25519-sha256; t=1735955892; l=4614;
 i=dmukhin@ford.com; s=20241125; h=from:subject:message-id;
 bh=DQVskSH09OmedMdoHofKReknLx5qPNl8KeCzK1S41sE=;
 b=JfKZBsVOthWu4FvX+ORA18fOi5NiAdEjNH8Vtw0QxvRj8s+KeCXrvayD9yOs3vC+Koqfp1eeD
 kFqogSxq7OtC3pAsXmZfIeTbMvdrO3vcUFADurPkJJ2GGhzt05pytia
X-Developer-Key: i=dmukhin@ford.com; a=ed25519;
 pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U=
X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with
 auth_id=287
X-Original-From: Denis Mukhin <dmukhin@ford.com>
Reply-To: dmukhin@ford.com

From: Denis Mukhin <dmukhin@ford.com>

PV Linux kernel uses HYPERVISOR_console_io hypercall for early console which
ends up being handled by Xen's console driver's guest_console_write().

guest_console_write() duplicates the code from __putstr(), elimitate code
duplication.

Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
 xen/drivers/char/console.c | 103 ++++++++++++++++++++++++---------------------
 1 file changed, 55 insertions(+), 48 deletions(-)

diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index a33132b8fad95a1ad7e0aab4aef3fa3e46a5c03a..2f776b2f07cb15fae8060f3574db73234a38727a 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -40,6 +40,11 @@
 #include <asm/guest.h>
 #endif
 
+/* Console flags. */
+enum {
+    CONSOLE_RING    = BIT(0, U),
+};
+
 /* console: comma-separated list of console outputs. */
 static char __initdata opt_console[30] = OPT_CONSOLE_STR;
 string_param("console", opt_console);
@@ -636,6 +641,16 @@ static void cf_check notify_dom0_con_ring(void *unused)
 static DECLARE_SOFTIRQ_TASKLET(notify_dom0_con_ring_tasklet,
                                notify_dom0_con_ring, NULL);
 
+static bool console_locks_busted;
+
+static void conring_write(const char *str, size_t len)
+{
+    conring_puts(str, len);
+
+    if ( !console_locks_busted )
+        tasklet_schedule(&notify_dom0_con_ring_tasklet);
+}
+
 #ifdef CONFIG_X86
 static inline void xen_console_write_debug_port(const char *buf, size_t len)
 {
@@ -644,8 +659,47 @@ static inline void xen_console_write_debug_port(const char *buf, size_t len)
                    : "=&S" (tmp), "=&c" (tmp)
                    : "0" (buf), "1" (len), "d" (XEN_HVM_DEBUGCONS_IOPORT) );
 }
+
+static void xen_console_write(const char *str, size_t len)
+{
+    if ( xen_guest )
+        xen_hypercall_console_write(str, len);
+    else
+        xen_console_write_debug_port(str, len);
+}
 #endif
 
+/*
+ * Write characters to console.
+ *
+ * That will handle all possible scenarios working w/ console
+ * - serial console;
+ * - VGA console (x86 only);
+ * - __HYPERVISOR_console_io hypercall (x86 only);
+ * - debug I/O port (x86 only);
+ * - PV console.
+ */
+static void console_write(const char *str, size_t len, unsigned int flags)
+{
+    ASSERT(rspin_is_locked(&console_lock));
+
+    console_serial_puts(str, len);
+    video_puts(str, len);
+
+#ifdef CONFIG_X86
+    if ( opt_console_xen )
+        xen_console_write(str, len);
+#endif
+
+    if ( flags & CONSOLE_RING )
+        conring_write(str, len);
+}
+
+static inline void __putstr(const char *str)
+{
+    console_write(str, strlen(str), CONSOLE_RING);
+}
+
 static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer,
                                 unsigned int count)
 {
@@ -666,28 +720,8 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer,
 
         if ( is_hardware_domain(cd) )
         {
-            /* Use direct console output as it could be interactive */
             nrspin_lock_irq(&console_lock);
-
-            console_serial_puts(kbuf, kcount);
-            video_puts(kbuf, kcount);
-
-#ifdef CONFIG_X86
-            if ( opt_console_xen )
-            {
-                if ( xen_guest )
-                    xen_hypercall_console_write(kbuf, kcount);
-                else
-                    xen_console_write_debug_port(kbuf, kcount);
-            }
-#endif
-
-            if ( opt_console_to_ring )
-            {
-                conring_puts(kbuf, kcount);
-                tasklet_schedule(&notify_dom0_con_ring_tasklet);
-            }
-
+            console_write(kbuf, kcount, !!opt_console_to_ring);
             nrspin_unlock_irq(&console_lock);
         }
         else
@@ -788,33 +822,6 @@ long do_console_io(
  * *****************************************************
  */
 
-static bool console_locks_busted;
-
-static void __putstr(const char *str)
-{
-    size_t len = strlen(str);
-
-    ASSERT(rspin_is_locked(&console_lock));
-
-    console_serial_puts(str, len);
-    video_puts(str, len);
-
-#ifdef CONFIG_X86
-    if ( opt_console_xen )
-    {
-        if ( xen_guest )
-            xen_hypercall_console_write(str, len);
-        else
-            xen_console_write_debug_port(str, len);
-    }
-#endif
-
-    conring_puts(str, len);
-
-    if ( !console_locks_busted )
-        tasklet_schedule(&notify_dom0_con_ring_tasklet);
-}
-
 static int printk_prefix_check(char *p, char **pp)
 {
     int loglvl = -1;

-- 
2.34.1




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 01:58:28 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 01:58:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864705.1275952 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtQk-0005fg-31; Sat, 04 Jan 2025 01:58:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864705.1275952; Sat, 04 Jan 2025 01:58:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtQj-0005ew-UU; Sat, 04 Jan 2025 01:58:21 +0000
Received: by outflank-mailman (input) for mailman id 864705;
 Sat, 04 Jan 2025 01:58: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
 <SRS0=AhC6=T4=kernel.org=devnull+dmukhin.ford.com@srs-se1.protection.inumbo.net>)
 id 1tTtQi-0005Ay-5U
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 01:58:20 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5c89f58e-ca3f-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 02:58:16 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id D3CDFA411A1;
 Sat,  4 Jan 2025 01:56:25 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPS id BA0E6C4CEDF;
 Sat,  4 Jan 2025 01:58:14 +0000 (UTC)
Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org
 (localhost.localdomain [127.0.0.1])
 by smtp.lore.kernel.org (Postfix) with ESMTP id AD68FE77199;
 Sat,  4 Jan 2025 01:58:14 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5c89f58e-ca3f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1735955894;
	bh=rMk6e8dP6iduBbKYzKwM0zuq90kaxVjD4waV73BrMWU=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From;
	b=rAG3wWpo3Wao5hFXTgJFLK2wbqRt51cycoWp3/srRpFpZr8cV7o6O0ptiI/gmpUq3
	 p9H8OPAnjH5YUckkHYcS3nSClDmSFCX1Yw8q1hFmEUbM/NLIWDCntJeMo9EREFu06d
	 JxLfAom7YBjEtyTcLkbhczYn/m3oOC2d1ahDpzGGy96pDuWzzIXushtgLuURFpbqSa
	 dsUhtELuRG7X2uaClomEvu5pyrDles2hgHfiiMx+f9DwuLJ2wH4FWe+WRiClpguqkp
	 0S9G8xARuASgtijd+jokt+pmlpOd1T48VXQ4uxsvRJq25f9ei7q9Cgrd0e8WOJT94T
	 AsH+WDKCd9I1A==
From: Denis Mukhin via B4 Relay <devnull+dmukhin.ford.com@kernel.org>
Date: Fri, 03 Jan 2025 17:58:08 -0800
Subject: [PATCH v3 02/24] arm/vuart: move vpl011-related code to vpl011
 emulator
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20250103-vuart-ns8250-v3-v1-2-c5d36b31d66c@ford.com>
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
In-Reply-To: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>, 
 Julien Grall <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, Jan Beulich <jbeulich@suse.com>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
 Denis Mukhin <dmukhin@ford.com>
X-Mailer: b4 0.14.2
X-Developer-Signature: v=1; a=ed25519-sha256; t=1735955892; l=4317;
 i=dmukhin@ford.com; s=20241125; h=from:subject:message-id;
 bh=WBvO8bA+8Nj2y5g4Kr43LtifU20Luw0hJhjCrT4qixs=;
 b=HFI194W9aVN9+Fxa7KERSNI5ADEY+BH7XLcU4u6tM3rnmm0dWvu6LsM9uIa17987zZ2YYl9bn
 F+CVVTwcpKgDkOE0n0HGlCmYRbIhuuvizU+fBvDJOd7E/Zi9Ocism8K
X-Developer-Key: i=dmukhin@ford.com; a=ed25519;
 pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U=
X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with
 auth_id=287
X-Original-From: Denis Mukhin <dmukhin@ford.com>
Reply-To: dmukhin@ford.com

From: Denis Mukhin <dmukhin@ford.com>

Xen console driver has vpl011-related logic which shall belong vpl011 emulator
code (Arm port). Move vpl011-related code from arch-independent console driver
to Arm's vpl011.c.

Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
 xen/arch/arm/include/asm/vpl011.h |  2 +-
 xen/arch/arm/vpl011.c             | 15 +++++++++++----
 xen/drivers/char/console.c        | 23 +++++++++--------------
 3 files changed, 21 insertions(+), 19 deletions(-)

diff --git a/xen/arch/arm/include/asm/vpl011.h b/xen/arch/arm/include/asm/vpl011.h
index c09abcd7a9b3356d0809743517934adae00087f5..cc838682815c0d049ba33d3bf9966a64b2e527dd 100644
--- a/xen/arch/arm/include/asm/vpl011.h
+++ b/xen/arch/arm/include/asm/vpl011.h
@@ -69,7 +69,7 @@ struct vpl011_init_info {
 int domain_vpl011_init(struct domain *d,
                        struct vpl011_init_info *info);
 void domain_vpl011_deinit(struct domain *d);
-void vpl011_rx_char_xen(struct domain *d, char c);
+int vpl011_rx_char_xen(struct domain *d, char c);
 #else
 static inline int domain_vpl011_init(struct domain *d,
                                      struct vpl011_init_info *info)
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index 1fc3114cce9ddb48cf199834c8e9abe8cfba92b5..c72f3778bfedf9434f9d1a0cd7fa33852563112d 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -567,16 +567,21 @@ static void vpl011_data_avail(struct domain *d,
 
 /*
  * vpl011_rx_char_xen adds a char to a domain's vpl011 receive buffer.
- * It is only used when the vpl011 backend is in Xen.
  */
-void vpl011_rx_char_xen(struct domain *d, char c)
+int vpl011_rx_char_xen(struct domain *d, char c)
 {
     unsigned long flags;
     struct vpl011 *vpl011 = &d->arch.vpl011;
     struct vpl011_xen_backend *intf = vpl011->backend.xen;
     XENCONS_RING_IDX in_cons, in_prod, in_fifo_level;
 
-    ASSERT(!vpl011->backend_in_domain);
+    /* Forward input iff the vpl011 backend is in Xen. */
+    if ( vpl011->backend_in_domain )
+        return -ENODEV;
+
+    if ( intf == NULL )
+        return -ENODEV;
+
     VPL011_LOCK(d, flags);
 
     in_cons = intf->in_cons;
@@ -584,7 +589,7 @@ void vpl011_rx_char_xen(struct domain *d, char c)
     if ( xencons_queued(in_prod, in_cons, sizeof(intf->in)) == sizeof(intf->in) )
     {
         VPL011_UNLOCK(d, flags);
-        return;
+        return -ENOSPC;
     }
 
     intf->in[xencons_mask(in_prod, sizeof(intf->in))] = c;
@@ -596,6 +601,8 @@ void vpl011_rx_char_xen(struct domain *d, char c)
 
     vpl011_data_avail(d, in_fifo_level, sizeof(intf->in), 0, SBSA_UART_FIFO_SIZE);
     VPL011_UNLOCK(d, flags);
+
+    return 0;
 }
 
 static void vpl011_notification(struct vcpu *v, unsigned int port)
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 4cb397116b44935214801c496b30e44c9399c59a..1411c991977b5fb26ee5709e523b7bc32b612808 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -529,6 +529,8 @@ static void switch_serial_input(void)
 
 static void __serial_rx(char c)
 {
+    int rc = 0;
+
     switch ( console_rx )
     {
     case 0:
@@ -554,21 +556,11 @@ static void __serial_rx(char c)
     {
         struct domain *d = rcu_lock_domain_by_id(console_rx - 1);
 
-        /*
-         * If we have a properly initialized vpl011 console for the
-         * domain, without a full PV ring to Dom0 (in that case input
-         * comes from the PV ring), then send the character to it.
-         */
-        if ( d != NULL &&
-             !d->arch.vpl011.backend_in_domain &&
-             d->arch.vpl011.backend.xen != NULL )
-            vpl011_rx_char_xen(d, c);
-        else
-            printk("Cannot send chars to Dom%d: no UART available\n",
-                   console_rx - 1);
-
-        if ( d != NULL )
+        if ( d )
+        {
+            rc = vpl011_rx_char_xen(d, c);
             rcu_unlock_domain(d);
+        }
 
         break;
     }
@@ -579,6 +571,9 @@ static void __serial_rx(char c)
     if ( pv_shim && pv_console )
         consoled_guest_tx(c);
 #endif
+
+    if ( rc )
+        printk(KERN_ERR "d%pd: failed to process console input: %d\n", d, rc);
 }
 
 static void cf_check serial_rx(char c)

-- 
2.34.1




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 01:58:28 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 01:58:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864707.1275965 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtQk-0005uk-VL; Sat, 04 Jan 2025 01:58:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864707.1275965; Sat, 04 Jan 2025 01:58:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtQk-0005ro-O0; Sat, 04 Jan 2025 01:58:22 +0000
Received: by outflank-mailman (input) for mailman id 864707;
 Sat, 04 Jan 2025 01:58: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
 <SRS0=AhC6=T4=kernel.org=devnull+dmukhin.ford.com@srs-se1.protection.inumbo.net>)
 id 1tTtQi-0005Ay-JH
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 01:58:20 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5c7b92d9-ca3f-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 02:58:16 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id A04E95C60A3;
 Sat,  4 Jan 2025 01:57:33 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPS id AD788C4CEDD;
 Sat,  4 Jan 2025 01:58:14 +0000 (UTC)
Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org
 (localhost.localdomain [127.0.0.1])
 by smtp.lore.kernel.org (Postfix) with ESMTP id 9E522E7718F;
 Sat,  4 Jan 2025 01:58:14 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5c7b92d9-ca3f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1735955894;
	bh=ixkyuOkiW6UUd6nXZHVzHXwPEUcrn1ATQ8PMz6yYQZU=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From;
	b=PyyNaLDwe45fuLGzbHvRdggvoPjqnc7oOABO9umAdq0YHmlF9F9p4ZNEwbf9DhaK2
	 XkFz6dmSio1o49I3tdRoBz5QxHLgeix9rOWX5w99edorcTW6d0QIRG47jiq8tedHTo
	 RArzjnB04YlJgCcqf46zII7c1w4ZzncDLjn/anpVQenDj0kQ2de6VeFcXHQ2sWqbgH
	 MD86vHuP6vl9LK4OvupzyFzI3Uhjc8ohjvYyVNUNTaxAaC8hkvTvsvO/SOQ6flZEJ+
	 O80Hm+RhOiZvehVcZh+a2VmX+KEq3AEMTl9em3hCOa/jZfRdE31gL8D8OxUIFTmEpT
	 fpRlULRfg2Fiw==
From: Denis Mukhin via B4 Relay <devnull+dmukhin.ford.com@kernel.org>
Date: Fri, 03 Jan 2025 17:58:07 -0800
Subject: [PATCH v3 01/24] xen/ctype: introduce is_console_printable()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20250103-vuart-ns8250-v3-v1-1-c5d36b31d66c@ford.com>
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
In-Reply-To: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>, 
 Julien Grall <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, Jan Beulich <jbeulich@suse.com>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
 Denis Mukhin <dmukhin@ford.com>
X-Mailer: b4 0.14.2
X-Developer-Signature: v=1; a=ed25519-sha256; t=1735955892; l=3106;
 i=dmukhin@ford.com; s=20241125; h=from:subject:message-id;
 bh=4D7ZxUDiCpTccpWinTY9R2Ndh2vzcucBN6SjTgn7Gmg=;
 b=jP4F9CwTPqrv4KtNpzI3kEeh+CKX6i8UdW4ulFgALmAvuDR3hVY/Dlkoa+ubfgC6Air3Fk8m4
 YNzBwH/RNhJD6N4BnvvXA+FuT+K+yoRLo5vUGCDpHTrVfTycZTs7/aS
X-Developer-Key: i=dmukhin@ford.com; a=ed25519;
 pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U=
X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with
 auth_id=287
X-Original-From: Denis Mukhin <dmukhin@ford.com>
Reply-To: dmukhin@ford.com

From: Denis Mukhin <dmukhin@ford.com>

There are several console drivers which have same checks w.r.t. printable
characters. The check is moved to new is_console_printable() function and
re-used in the UART emulation / guest logging code.

Also, MISRA rule 21.13 for ctype.h has been exploited while working on
the code change, reference the rule from ctype.h for future engineers.

Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
 xen/arch/arm/vuart.c       | 3 +--
 xen/arch/x86/hvm/hvm.c     | 3 +--
 xen/drivers/char/console.c | 2 +-
 xen/include/xen/ctype.h    | 7 +++++++
 4 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/vuart.c b/xen/arch/arm/vuart.c
index d5ba483f1e63245e545346ad5045098152b8c152..98a65b99385a2a119725bab8634ed7cf9d926d68 100644
--- a/xen/arch/arm/vuart.c
+++ b/xen/arch/arm/vuart.c
@@ -79,8 +79,7 @@ static void vuart_print_char(struct vcpu *v, char c)
     struct domain *d = v->domain;
     struct vuart *uart = &d->arch.vuart;
 
-    /* Accept only printable characters, newline, and horizontal tab. */
-    if ( !isprint(c) && (c != '\n') && (c != '\t') )
+    if ( !is_console_printable(c) )
         return ;
 
     spin_lock(&uart->lock);
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 922c9b3af64d9132022d37627c54af092275e9cf..c4f1df248c1a7b2b3e5c45cef154e7ca80018dfc 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -561,8 +561,7 @@ static int cf_check hvm_print_line(
     if ( dir != IOREQ_WRITE )
         return X86EMUL_UNHANDLEABLE;
 
-    /* Accept only printable characters, newline, and horizontal tab. */
-    if ( !isprint(c) && (c != '\n') && (c != '\t') )
+    if ( !is_console_printable(c) )
         return X86EMUL_OKAY;
 
     spin_lock(&cd->pbuf_lock);
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 7da8c5296f3b62c6c45131c58fe5cf0e393e9ef3..4cb397116b44935214801c496b30e44c9399c59a 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -674,7 +674,7 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer,
                 c = *kin++;
                 if ( c == '\n' )
                     break;
-                if ( isprint(c) || c == '\t' )
+                if ( is_console_printable(c) )
                     *kout++ = c;
             } while ( --kcount > 0 );
 
diff --git a/xen/include/xen/ctype.h b/xen/include/xen/ctype.h
index 773ac27aa44ac65e76e87cdec960450804310249..ceb8f028ddc80b3b688f13422c0362199a03ba9e 100644
--- a/xen/include/xen/ctype.h
+++ b/xen/include/xen/ctype.h
@@ -4,6 +4,8 @@
 /*
  * NOTE! This ctype does not handle EOF like the standard C
  * library is required to.
+ *
+ * See Rule 21.13 in docs/misra/rules.rst.
  */
 
 #define _U	0x01	/* upper */
@@ -51,4 +53,9 @@ static inline unsigned char __toupper(unsigned char c)
 #define tolower(c) ((char)__tolower(c))
 #define toupper(c) ((char)__toupper(c))
 
+static inline unsigned is_console_printable(unsigned char c)
+{
+	return isprint(c) || c == '\n' || c == '\t';
+}
+
 #endif

-- 
2.34.1




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 01:58:28 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 01:58:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864703.1275931 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtQi-0005De-F7; Sat, 04 Jan 2025 01:58:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864703.1275931; Sat, 04 Jan 2025 01:58:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtQi-0005Ci-B6; Sat, 04 Jan 2025 01:58:20 +0000
Received: by outflank-mailman (input) for mailman id 864703;
 Sat, 04 Jan 2025 01:58:19 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=AhC6=T4=kernel.org=devnull+dmukhin.ford.com@srs-se1.protection.inumbo.net>)
 id 1tTtQh-0005Ax-Cc
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 01:58:19 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5ceb498d-ca3f-11ef-a0de-8be0dac302b0;
 Sat, 04 Jan 2025 02:58:16 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 922D5A411CC;
 Sat,  4 Jan 2025 01:56:26 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPS id 7FC86C4CEE1;
 Sat,  4 Jan 2025 01:58:15 +0000 (UTC)
Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org
 (localhost.localdomain [127.0.0.1])
 by smtp.lore.kernel.org (Postfix) with ESMTP id 78E9EE77199;
 Sat,  4 Jan 2025 01:58:15 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5ceb498d-ca3f-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1735955895;
	bh=l5CaQI1poeUeBhWKU19UCrMQ4g4rX0YNIDC4pnEb90I=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From;
	b=E9oQQTd5LujcPgVUdEcB2UZB99M9Snlv5YHhTBLda8b+uM9O3bCrGkpcfWKPiOKPV
	 HdT+JfFaJCdGXFElA2IxlT5teosXI3PU33DFQE0GPMd3s0ZmWrQSybRJoomY2tHOXl
	 JlNw4fAz52BbVAE1wt1RYF90QePRggzFjahrOPay5YglUG2Awkdr7exH90vsysxzT7
	 +iXc2Jq/bEK5M43IHQnKVTH9ibaxUrcv8kXbZ36WF+FYGEnFjpOlVlH3dVWv6w3ROv
	 Euq2c3x5bJUj6UbDPkhwOCUy/CAgWJRc4uRiITJoajQu9CDtQeJpsJbg+dPNfRsJP7
	 x3gMUyg7U1EHQ==
From: Denis Mukhin via B4 Relay <devnull+dmukhin.ford.com@kernel.org>
Date: Fri, 03 Jan 2025 17:58:20 -0800
Subject: [PATCH v3 14/24] xen/console: simplify console owner switch hint
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20250103-vuart-ns8250-v3-v1-14-c5d36b31d66c@ford.com>
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
In-Reply-To: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>, 
 Julien Grall <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, Jan Beulich <jbeulich@suse.com>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
 Denis Mukhin <dmukhin@ford.com>
X-Mailer: b4 0.14.2
X-Developer-Signature: v=1; a=ed25519-sha256; t=1735955892; l=896;
 i=dmukhin@ford.com; s=20241125; h=from:subject:message-id;
 bh=WzdT/Oy8WMU/I7irURWT2SUpInPaVWdH8Z0/y7n+8AQ=;
 b=0j4lA25445KHzzpLVNgHBUI7bv00MN0Fqcvm5irJlwmNd4cGdfAKratJveXfG1O5lhSWXgwHE
 Y4tyt3EKNmYC05cRxLpm0AvVDCaAFO7SHVx7/Fypjcnz0cJJZjLKzPO
X-Developer-Key: i=dmukhin@ford.com; a=ed25519;
 pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U=
X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with
 auth_id=287
X-Original-From: Denis Mukhin <dmukhin@ford.com>
Reply-To: dmukhin@ford.com

From: Denis Mukhin <dmukhin@ford.com>

Update the hint with the combination of keys to press for the physical console
focus switch between the domains.

Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
 xen/drivers/char/console.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index f5ff3ebd830d631fa5d8fb5db1cf68adafcd02b4..1308236403df8a0f87aeb7e2c00a036c2d8433a7 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -518,8 +518,8 @@ int console_set_owner(domid_t domid)
     console_owner = domid;
 
     if ( switch_code )
-        printk(" (type 'CTRL-%c' three times to switch input)",
-               opt_conswitch[0]);
+        printk(" (type 'CTRL-%c%c%c' to switch input)",
+               opt_conswitch[0], opt_conswitch[0], opt_conswitch[0]);
     printk("\n");
 
     return 0;

-- 
2.34.1




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 01:58:28 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 01:58:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864714.1276024 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtQq-00076n-5N; Sat, 04 Jan 2025 01:58:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864714.1276024; Sat, 04 Jan 2025 01:58:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtQp-000740-Et; Sat, 04 Jan 2025 01:58:27 +0000
Received: by outflank-mailman (input) for mailman id 864714;
 Sat, 04 Jan 2025 01:58:24 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=AhC6=T4=kernel.org=devnull+dmukhin.ford.com@srs-se1.protection.inumbo.net>)
 id 1tTtQl-0005Ax-Qi
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 01:58:23 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5dd063cb-ca3f-11ef-a0de-8be0dac302b0;
 Sat, 04 Jan 2025 02:58:18 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 08B4B5C613E;
 Sat,  4 Jan 2025 01:57:34 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPS id EB6A4C4CED6;
 Sat,  4 Jan 2025 01:58:14 +0000 (UTC)
Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org
 (localhost.localdomain [127.0.0.1])
 by smtp.lore.kernel.org (Postfix) with ESMTP id E2F05E77198;
 Sat,  4 Jan 2025 01:58:14 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5dd063cb-ca3f-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1735955895;
	bh=AA7+mFgdv/CLreA2xkAbjLNCRVAgqmaEv1ja2uxK2AE=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From;
	b=kIWEW/eRK6fqXTa7M+eKyUBgFAU6g0f4xk5l5oE99ZnF0P1X0cWwRnuDgYGKYj6hc
	 MIncbo7zBD1qIRsMYWCiYlmw7UAxjoHbCe08EEqxpQzX8uuCGAgySBCGBPuKb6WLIS
	 OjUd4CKhK1BFxt/OpBtsmUKre/E+9ezEn6cbx5JwlxPeTWlNxOmxMjUkWLKHvItOEE
	 tDuEwpinIHXawJOr104bGNSab64JRwi3g8jQjty0IlyrOvivNYa5ygUjA7zigC/E8Z
	 k1RCWGsxcFTx3I8cSs3FgPAJygzY3zuCUvLP2VzTE9d6nICd+1zMTgOqxazXKaVtAP
	 0aA++obj1Ul3A==
From: Denis Mukhin via B4 Relay <devnull+dmukhin.ford.com@kernel.org>
Date: Fri, 03 Jan 2025 17:58:11 -0800
Subject: [PATCH v3 05/24] xen/console: introduce consoled_is_enabled()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20250103-vuart-ns8250-v3-v1-5-c5d36b31d66c@ford.com>
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
In-Reply-To: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>, 
 Julien Grall <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, Jan Beulich <jbeulich@suse.com>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
 Denis Mukhin <dmukhin@ford.com>
X-Mailer: b4 0.14.2
X-Developer-Signature: v=1; a=ed25519-sha256; t=1735955892; l=4404;
 i=dmukhin@ford.com; s=20241125; h=from:subject:message-id;
 bh=n4Aqa3ybnKIx5xmfT+5F0wUDK/FeirbGr0o6DW85ymA=;
 b=C4K8KLpFn1MjYhJMBZQMxhbcwkSQbMQPkN60/GkOpUDva4wrnJU3OI1jMwq1OYrhFKd3FJAbL
 pLO5JKF6+JdBYum8mrIHzPA5dZ7qRLqRtkU0jOY0jQiRbsCifK3SU4j
X-Developer-Key: i=dmukhin@ford.com; a=ed25519;
 pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U=
X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with
 auth_id=287
X-Original-From: Denis Mukhin <dmukhin@ford.com>
Reply-To: dmukhin@ford.com

From: Denis Mukhin <dmukhin@ford.com>

There are few places which check pv_shim console under CONFIG_PV_SHIM in xen
console driver. Instead of #ifdef-ing, use new consoled_is_enabled() to
customize the logic.

Header file now can be included w/o CONFIG_X86.

Signature of consoled_guest_{rx,tx} has changed so the error can be logged.

Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
 xen/drivers/char/console.c  | 13 +++++--------
 xen/drivers/char/consoled.c | 17 +++++++++++++----
 xen/include/xen/consoled.h  | 32 +++++++++++++++++++++++++++-----
 3 files changed, 45 insertions(+), 17 deletions(-)

diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 4785f0e93a17e3ecba79a7813d2928f946abab8f..2d20a9d7531e069803eaf30ce79354b998c4a52f 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -33,9 +33,9 @@
 #include <xen/pv_console.h>
 #include <asm/setup.h>
 #include <xen/sections.h>
+#include <xen/consoled.h>
 
 #ifdef CONFIG_X86
-#include <xen/consoled.h>
 #include <asm/guest.h>
 #endif
 #ifdef CONFIG_SBSA_VUART_CONSOLE
@@ -508,11 +508,9 @@ static void switch_serial_input(void)
             break;
         }
 
-#ifdef CONFIG_PV_SHIM
-        if ( next_rx == 1 )
+        if ( consoled_is_enabled() && next_rx == 1 )
             domid = get_initial_domain_id();
         else
-#endif
             domid = next_rx - 1;
         d = rcu_lock_domain_by_id(domid);
         if ( d )
@@ -563,10 +561,9 @@ static void __serial_rx(char c)
         rc = vpl011_rx_char_xen(d, c);
 #endif
 
-#ifdef CONFIG_X86
-    if ( pv_shim && pv_console )
-        consoled_guest_tx(c);
-#endif
+    if ( consoled_is_enabled() )
+        /* Deliver input to the PV shim console. */
+        rc = consoled_guest_tx(c);
 
     if ( rc )
         printk(KERN_ERR "d%pd: failed to process console input: %d\n", d, rc);
diff --git a/xen/drivers/char/consoled.c b/xen/drivers/char/consoled.c
index b415b632cecc0a80e161b701d7b70ba4f3cc5fb8..8704ec251eb19e9c1cdc5927f896aeb20cc5af1e 100644
--- a/xen/drivers/char/consoled.c
+++ b/xen/drivers/char/consoled.c
@@ -43,13 +43,13 @@ struct xencons_interface *consoled_get_ring_addr(void)
 static char buf[BUF_SZ + 1];
 
 /* Receives characters from a domain's PV console */
-void consoled_guest_rx(void)
+int consoled_guest_rx(void)
 {
     size_t idx = 0;
     XENCONS_RING_IDX cons, prod;
 
     if ( !cons_ring )
-        return;
+        return -ENODEV;
 
     spin_lock(&rx_lock);
 
@@ -91,15 +91,17 @@ void consoled_guest_rx(void)
 
  out:
     spin_unlock(&rx_lock);
+
+    return 0;
 }
 
 /* Sends a character into a domain's PV console */
-void consoled_guest_tx(char c)
+int consoled_guest_tx(char c)
 {
     XENCONS_RING_IDX cons, prod;
 
     if ( !cons_ring )
-        return;
+        return -ENODEV;
 
     cons = ACCESS_ONCE(cons_ring->in_cons);
     prod = cons_ring->in_prod;
@@ -125,6 +127,13 @@ void consoled_guest_tx(char c)
  notify:
     /* Always notify the guest: prevents receive path from getting stuck. */
     pv_shim_inject_evtchn(pv_console_evtchn());
+
+    return 0;
+}
+
+bool consoled_is_enabled(void)
+{
+    return pv_shim && pv_console;
 }
 
 /*
diff --git a/xen/include/xen/consoled.h b/xen/include/xen/consoled.h
index bd7ab6329ee8a7c466484021247241ded8ed03c7..14e5e3284a86201919f0f70a8c2785609f35b15f 100644
--- a/xen/include/xen/consoled.h
+++ b/xen/include/xen/consoled.h
@@ -1,14 +1,36 @@
-#ifndef __XEN_CONSOLED_H__
-#define __XEN_CONSOLED_H__
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef XEN__CONSOLED_H
+#define XEN__CONSOLED_H
 
 #include <public/io/console.h>
 
+#ifdef CONFIG_PV_SHIM
+
 void consoled_set_ring_addr(struct xencons_interface *ring);
 struct xencons_interface *consoled_get_ring_addr(void);
-void consoled_guest_rx(void);
-void consoled_guest_tx(char c);
+int consoled_guest_rx(void);
+int consoled_guest_tx(char c);
+bool consoled_is_enabled(void);
 
-#endif /* __XEN_CONSOLED_H__ */
+#else
+
+static inline int consoled_guest_rx(void)
+{
+    ASSERT_UNREACHABLE();
+    return 0;
+}
+
+static inline int consoled_guest_tx(char c)
+{
+    ASSERT_UNREACHABLE();
+    return 0;
+}
+
+#define consoled_is_enabled() ( false )
+
+#endif /* CONFIG_PV_SHIM */
+
+#endif /* XEN__CONSOLED_H */
 /*
  * Local variables:
  * mode: C

-- 
2.34.1




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 01:58:28 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 01:58:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864702.1275929 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtQi-0005BO-8T; Sat, 04 Jan 2025 01:58:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864702.1275929; Sat, 04 Jan 2025 01:58:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtQi-0005BF-4G; Sat, 04 Jan 2025 01:58:20 +0000
Received: by outflank-mailman (input) for mailman id 864702;
 Sat, 04 Jan 2025 01:58:19 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=AhC6=T4=kernel.org=devnull+dmukhin.ford.com@srs-se1.protection.inumbo.net>)
 id 1tTtQh-0005Ax-4U
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 01:58:19 +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 5c87a119-ca3f-11ef-a0de-8be0dac302b0;
 Sat, 04 Jan 2025 02:58:16 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id BBEAA5C60DF;
 Sat,  4 Jan 2025 01:57:33 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPS id C8C30C4CEE1;
 Sat,  4 Jan 2025 01:58:14 +0000 (UTC)
Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org
 (localhost.localdomain [127.0.0.1])
 by smtp.lore.kernel.org (Postfix) with ESMTP id C0D91E77198;
 Sat,  4 Jan 2025 01:58:14 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5c87a119-ca3f-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1735955894;
	bh=tVS12C3USoReyjZxz4AVM9AHh6CImFwneSMxcZyOSa8=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From;
	b=t56hCG20y/WyCEIkZGqGRW9p2xOe7f+eCta5fx4HRyrE17LlXUl8aHToFHApOj7xW
	 GN0FmA2K7qJUVED7ztlLhErSloOzjSnXrMUiMu+sNIHlQQ79FBYYt7YwHaPWnUXd8h
	 Rx+dNAIljirHypcYcZ1g5yutC+/Ep+ccS7EWXPw8BDmdVwhwlU+oxnPuQyz70iDeYW
	 X54LoNVrGaQDWHTLX4PT1BG2wRbcLvhsUyRHaTYxIVPNrTClrp8SpMJILY7/k2vbsF
	 yp3gzSVIkzrViYCs5PJXz5wNOKz0TgWw0skhOGq++CsKqMASvHzP4NYSHTzYSAh4Ok
	 yMwikRbXEvwgw==
From: Denis Mukhin via B4 Relay <devnull+dmukhin.ford.com@kernel.org>
Date: Fri, 03 Jan 2025 17:58:09 -0800
Subject: [PATCH v3 03/24] arm/vuart: add hwdom prefix to UART emulator
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20250103-vuart-ns8250-v3-v1-3-c5d36b31d66c@ford.com>
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
In-Reply-To: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>, 
 Julien Grall <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, Jan Beulich <jbeulich@suse.com>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
 Denis Mukhin <dmukhin@ford.com>
X-Mailer: b4 0.14.2
X-Developer-Signature: v=1; a=ed25519-sha256; t=1735955892; l=5463;
 i=dmukhin@ford.com; s=20241125; h=from:subject:message-id;
 bh=40dwRBx75DrBuSFfvZFLHZmEe2vsPE5uifchSIh7mKk=;
 b=O03Oul5Yz2t/R10EGb36YwgTtsEtmTIUs7q1wxPKjY2LshZm6JN+BWIF22uZs0UHVoxm1LCD0
 6jxn7KWnS68CDKjU4ybD+6OapE+CUUrGstgWybDjSOqQT5C1IeLg9Zq
X-Developer-Key: i=dmukhin@ford.com; a=ed25519;
 pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U=
X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with
 auth_id=287
X-Original-From: Denis Mukhin <dmukhin@ford.com>
Reply-To: dmukhin@ford.com

From: Denis Mukhin <dmukhin@ford.com>

Using "vuart" in UART emulator designed for hardware domain debugging
is confusing in generic Arm code (e.g. vpl011 is also "vuart").
Fix that by adding hwdom prefix to all symbols in arm/vuart.c.

Also, remove domain_has_vuart() from arm/vuart.c since it is not needed.

Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
 xen/arch/arm/domain.c |  4 ++--
 xen/arch/arm/vuart.c  | 35 +++++++++++++++--------------------
 xen/arch/arm/vuart.h  |  8 ++++----
 3 files changed, 21 insertions(+), 26 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 3ba959f866338d2e7f7dc0e301cd79c10fbc4549..7ef1a95c290752d5a0167806e298aacc834ea640 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -775,7 +775,7 @@ int arch_domain_create(struct domain *d,
      * Only use it for the hardware domain because the linux kernel may not
      * support multi-platform.
      */
-    if ( is_hardware_domain(d) && (rc = domain_vuart_init(d)) )
+    if ( is_hardware_domain(d) && (rc = hwdom_vuart_init(d)) )
         goto fail;
 
     if ( (rc = domain_vpci_init(d)) != 0 )
@@ -844,7 +844,7 @@ void arch_domain_destroy(struct domain *d)
     iommu_domain_destroy(d);
     p2m_final_teardown(d);
     domain_vgic_free(d);
-    domain_vuart_free(d);
+    hwdom_vuart_free(d);
     free_xenheap_page(d->shared_info);
 #ifdef CONFIG_ACPI
     free_xenheap_pages(d->arch.efi_acpi_table,
diff --git a/xen/arch/arm/vuart.c b/xen/arch/arm/vuart.c
index 98a65b99385a2a119725bab8634ed7cf9d926d68..23e05dba3a5617863f6c08f085c358f2cf32a292 100644
--- a/xen/arch/arm/vuart.c
+++ b/xen/arch/arm/vuart.c
@@ -31,19 +31,17 @@
 
 #include "vuart.h"
 
-#define domain_has_vuart(d) ((d)->arch.vuart.info != NULL)
+static int hwdom_vuart_mmio_read(struct vcpu *v, mmio_info_t *info,
+                                 register_t *r, void *priv);
+static int hwdom_vuart_mmio_write(struct vcpu *v, mmio_info_t *info,
+                                  register_t r, void *priv);
 
-static int vuart_mmio_read(struct vcpu *v, mmio_info_t *info,
-                           register_t *r, void *priv);
-static int vuart_mmio_write(struct vcpu *v, mmio_info_t *info,
-                            register_t r, void *priv);
-
-static const struct mmio_handler_ops vuart_mmio_handler = {
-    .read  = vuart_mmio_read,
-    .write = vuart_mmio_write,
+static const struct mmio_handler_ops hwdom_vuart_mmio_handler = {
+    .read  = hwdom_vuart_mmio_read,
+    .write = hwdom_vuart_mmio_write,
 };
 
-int domain_vuart_init(struct domain *d)
+int hwdom_vuart_init(struct domain *d)
 {
     ASSERT( is_hardware_domain(d) );
 
@@ -58,7 +56,7 @@ int domain_vuart_init(struct domain *d)
     if ( !d->arch.vuart.buf )
         return -ENOMEM;
 
-    register_mmio_handler(d, &vuart_mmio_handler,
+    register_mmio_handler(d, &hwdom_vuart_mmio_handler,
                           d->arch.vuart.info->base_addr,
                           d->arch.vuart.info->size,
                           NULL);
@@ -66,15 +64,12 @@ int domain_vuart_init(struct domain *d)
     return 0;
 }
 
-void domain_vuart_free(struct domain *d)
+void hwdom_vuart_free(struct domain *d)
 {
-    if ( !domain_has_vuart(d) )
-        return;
-
-    xfree(d->arch.vuart.buf);
+    XFREE(d->arch.vuart.buf);
 }
 
-static void vuart_print_char(struct vcpu *v, char c)
+static void hwdom_vuart_print_char(struct vcpu *v, char c)
 {
     struct domain *d = v->domain;
     struct vuart *uart = &d->arch.vuart;
@@ -95,7 +90,7 @@ static void vuart_print_char(struct vcpu *v, char c)
     spin_unlock(&uart->lock);
 }
 
-static int vuart_mmio_read(struct vcpu *v, mmio_info_t *info,
+static int hwdom_vuart_mmio_read(struct vcpu *v, mmio_info_t *info,
                            register_t *r, void *priv)
 {
     struct domain *d = v->domain;
@@ -113,7 +108,7 @@ static int vuart_mmio_read(struct vcpu *v, mmio_info_t *info,
     return 1;
 }
 
-static int vuart_mmio_write(struct vcpu *v, mmio_info_t *info,
+static int hwdom_vuart_mmio_write(struct vcpu *v, mmio_info_t *info,
                             register_t r, void *priv)
 {
     struct domain *d = v->domain;
@@ -123,7 +118,7 @@ static int vuart_mmio_write(struct vcpu *v, mmio_info_t *info,
 
     if ( offset == d->arch.vuart.info->data_off )
         /* ignore any status bits */
-        vuart_print_char(v, r & 0xFF);
+        hwdom_vuart_print_char(v, r & 0xFF);
 
     return 1;
 }
diff --git a/xen/arch/arm/vuart.h b/xen/arch/arm/vuart.h
index e90d84c6eddbb9d9089845c80062940eab997339..e6ca5582726736668765f5928b5c75e821db8aac 100644
--- a/xen/arch/arm/vuart.h
+++ b/xen/arch/arm/vuart.h
@@ -24,12 +24,12 @@ struct domain;
 
 #ifdef CONFIG_HWDOM_VUART
 
-int domain_vuart_init(struct domain *d);
-void domain_vuart_free(struct domain *d);
+int hwdom_vuart_init(struct domain *d);
+void hwdom_vuart_free(struct domain *d);
 
 #else
 
-static inline int domain_vuart_init(struct domain *d)
+static inline int hwdom_vuart_init(struct domain *d)
 {
     /*
      * The vUART is unconditionally inialized for the hw domain. So we
@@ -38,7 +38,7 @@ static inline int domain_vuart_init(struct domain *d)
     return 0;
 }
 
-static inline void domain_vuart_free(struct domain *d) {};
+static inline void hwdom_vuart_free(struct domain *d) {};
 
 #endif /* CONFIG_HWDOM_VUART */
 

-- 
2.34.1




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 01:58:28 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 01:58:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864708.1275973 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtQl-0005yG-FL; Sat, 04 Jan 2025 01:58:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864708.1275973; Sat, 04 Jan 2025 01:58:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtQl-0005wf-1u; Sat, 04 Jan 2025 01:58:23 +0000
Received: by outflank-mailman (input) for mailman id 864708;
 Sat, 04 Jan 2025 01:58:20 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=AhC6=T4=kernel.org=devnull+dmukhin.ford.com@srs-se1.protection.inumbo.net>)
 id 1tTtQi-0005Ax-QA
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 01:58:20 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5ca73fa4-ca3f-11ef-a0de-8be0dac302b0;
 Sat, 04 Jan 2025 02:58:16 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id E33BF5C60ED;
 Sat,  4 Jan 2025 01:57:33 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPS id D71FBC4CEE2;
 Sat,  4 Jan 2025 01:58:14 +0000 (UTC)
Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org
 (localhost.localdomain [127.0.0.1])
 by smtp.lore.kernel.org (Postfix) with ESMTP id CF2FCE77188;
 Sat,  4 Jan 2025 01:58:14 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5ca73fa4-ca3f-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1735955894;
	bh=+3lCSi+uoUjLrXI5KsViTk7A/iJtn55QaL5KYfpM3dY=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From;
	b=VtKbMyAsDxs/eyxr7xdavPZ/ZX8Cz0NvMrqSJFth6/byn76U9CHyJ4UFMd2mM7tlY
	 mupTUqBtSA8RRG8PsQz1Ge2aCj9LMffCfedtw2fktoQxfEJXiv8FiIbI6p8yRhWSRI
	 u+yI4HgeZKfSbx6Pv8r5JhF5SEDSJDISEsXCoxp2npdZSp6RRuqOFQysZ9PxoEbAqu
	 5E7fkgS98rnm+pB4ROJeykD+r3/D/WymT0Bw3jWnEnzhs5SX2MuancdfEzFpSRJQGm
	 MH8xKVnACypKZoTV7lvcmv0uukCf7QYSjGoAnWkjD6nHDzHCwkLwgMpdDw/Ob9ezCL
	 7U8CzPUPEx8Mg==
From: Denis Mukhin via B4 Relay <devnull+dmukhin.ford.com@kernel.org>
Date: Fri, 03 Jan 2025 17:58:10 -0800
Subject: [PATCH v3 04/24] xen/console: introduce console_{get,put}_domain()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20250103-vuart-ns8250-v3-v1-4-c5d36b31d66c@ford.com>
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
In-Reply-To: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>, 
 Julien Grall <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, Jan Beulich <jbeulich@suse.com>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
 Denis Mukhin <dmukhin@ford.com>
X-Mailer: b4 0.14.2
X-Developer-Signature: v=1; a=ed25519-sha256; t=1735955892; l=4310;
 i=dmukhin@ford.com; s=20241125; h=from:subject:message-id;
 bh=R8dApJ/XiKqchnt0Y9PJCOHsEWibqS36Kuatzu/KWu8=;
 b=rK9fr+LsEaTbokvlrCZ5xF8dd1MfNZorXXzg3xb4JWUj/zpaTVp8S/Q0xZx0mVKdNRQp0oBC1
 1zCgsNnNpYABQvoEcda1xy4WpELmdyQjZUv036bWzaLNEjynD9w9v9J
X-Developer-Key: i=dmukhin@ford.com; a=ed25519;
 pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U=
X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with
 auth_id=287
X-Original-From: Denis Mukhin <dmukhin@ford.com>
Reply-To: dmukhin@ford.com

From: Denis Mukhin <dmukhin@ford.com>

console_input_domain() takes an RCU lock to protect domain structure.
That implies call to rcu_unlock_domain() after use.

Introduce a pair of console_get_domain() / console_put_domain() to highlight
the correct use of the call within the code interacting with Xen console
driver.

Also, use new calls in the console driver in __serial_rx(). That prepares
the code for the follow-on console driver cleanup series.

Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
 xen/arch/arm/vpl011.c      |  6 +++---
 xen/drivers/char/console.c | 44 +++++++++++++++++++++-----------------------
 xen/include/xen/console.h  |  3 ++-
 3 files changed, 26 insertions(+), 27 deletions(-)

diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index c72f3778bfedf9434f9d1a0cd7fa33852563112d..66047bf33cedb930a6bd7c96577913cd1ae08f05 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -78,7 +78,7 @@ static void vpl011_write_data_xen(struct domain *d, uint8_t data)
     unsigned long flags;
     struct vpl011 *vpl011 = &d->arch.vpl011;
     struct vpl011_xen_backend *intf = vpl011->backend.xen;
-    struct domain *input = console_input_domain();
+    struct domain *input = console_get_domain();
 
     VPL011_LOCK(d, flags);
 
@@ -123,8 +123,8 @@ static void vpl011_write_data_xen(struct domain *d, uint8_t data)
     vpl011_update_interrupt_status(d);
 
     VPL011_UNLOCK(d, flags);
-    if ( input != NULL )
-        rcu_unlock_domain(input);
+
+    console_put_domain(input);
 }
 
 /*
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 1411c991977b5fb26ee5709e523b7bc32b612808..4785f0e93a17e3ecba79a7813d2928f946abab8f 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -475,15 +475,18 @@ static unsigned int __read_mostly console_rx = 0;
 
 #define max_console_rx (max_init_domid + 1)
 
-#ifdef CONFIG_SBSA_VUART_CONSOLE
-/* Make sure to rcu_unlock_domain after use */
-struct domain *console_input_domain(void)
+struct domain *console_get_domain(void)
 {
     if ( console_rx == 0 )
             return NULL;
     return rcu_lock_domain_by_id(console_rx - 1);
 }
-#endif
+
+void console_put_domain(struct domain *d)
+{
+    if ( d )
+        rcu_unlock_domain(d);
+}
 
 static void switch_serial_input(void)
 {
@@ -529,14 +532,18 @@ static void switch_serial_input(void)
 
 static void __serial_rx(char c)
 {
+    struct domain *d;
     int rc = 0;
 
-    switch ( console_rx )
-    {
-    case 0:
+    if ( console_rx == 0 )
         return handle_keypress(c, false);
 
-    case 1:
+    d = console_get_domain();
+    if ( !d )
+        return;
+
+    if ( is_hardware_domain(d) )
+    {
         /*
          * Deliver input to the hardware domain buffer, unless it is
          * already full.
@@ -549,23 +556,12 @@ static void __serial_rx(char c)
          * getting stuck.
          */
         send_global_virq(VIRQ_CONSOLE);
-        break;
-
+    }
 #ifdef CONFIG_SBSA_VUART_CONSOLE
-    default:
-    {
-        struct domain *d = rcu_lock_domain_by_id(console_rx - 1);
-
-        if ( d )
-        {
-            rc = vpl011_rx_char_xen(d, c);
-            rcu_unlock_domain(d);
-        }
-
-        break;
-    }
+    else
+        /* Deliver input to the emulated UART. */
+        rc = vpl011_rx_char_xen(d, c);
 #endif
-    }
 
 #ifdef CONFIG_X86
     if ( pv_shim && pv_console )
@@ -574,6 +570,8 @@ static void __serial_rx(char c)
 
     if ( rc )
         printk(KERN_ERR "d%pd: failed to process console input: %d\n", d, rc);
+
+    console_put_domain(d);
 }
 
 static void cf_check serial_rx(char c)
diff --git a/xen/include/xen/console.h b/xen/include/xen/console.h
index 6dfbade3ece36352c74f1124305da945b210f2a7..8631fd279bfe1aba42b61d76fbdb45016c2859f9 100644
--- a/xen/include/xen/console.h
+++ b/xen/include/xen/console.h
@@ -31,7 +31,8 @@ void console_end_sync(void);
 void console_start_log_everything(void);
 void console_end_log_everything(void);
 
-struct domain *console_input_domain(void);
+struct domain *console_get_domain(void);
+void console_put_domain(struct domain *d);
 
 /*
  * Steal output from the console. Returns +ve identifier, else -ve error.

-- 
2.34.1




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 01:58:28 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 01:58:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864712.1276007 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtQo-0006kd-I2; Sat, 04 Jan 2025 01:58:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864712.1276007; Sat, 04 Jan 2025 01:58:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtQn-0006iI-Sr; Sat, 04 Jan 2025 01:58:25 +0000
Received: by outflank-mailman (input) for mailman id 864712;
 Sat, 04 Jan 2025 01:58: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
 <SRS0=AhC6=T4=kernel.org=devnull+dmukhin.ford.com@srs-se1.protection.inumbo.net>)
 id 1tTtQk-0005Ax-QO
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 01:58:22 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5df4cd6d-ca3f-11ef-a0de-8be0dac302b0;
 Sat, 04 Jan 2025 02:58:18 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 3C02AA411F0;
 Sat,  4 Jan 2025 01:56:27 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPS id 2BCF9C4CEDD;
 Sat,  4 Jan 2025 01:58:16 +0000 (UTC)
Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org
 (localhost.localdomain [127.0.0.1])
 by smtp.lore.kernel.org (Postfix) with ESMTP id 25896E7719A;
 Sat,  4 Jan 2025 01:58:16 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5df4cd6d-ca3f-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1735955896;
	bh=2mHkPjXf6NjW+LO0bsnwT2e081y81crKinFFDfZUM/8=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From;
	b=b6CWmi2eXFjuj3dBJUQGQi2DY7mfzc2/rU/a5xqRt0c1R2D80+nzRD06J9oxLgaph
	 fb20RRMaWbnKCm+6gMinN79bcDsQ2RteEJmXcDS0oehGj6G50iWSsFypAlBqnHYUeF
	 ApZBfLLD8uDKdB2evAiGjWcfeWPBY6XRP2lTBPivxGMEcijxN/MUone536Dp6pb0Ir
	 /43eUjBlMg/Dc/GA6Wy6UmByKg0YvnnRglOizjUOhi5b7CZqLY9ooyV7vPmPM8n077
	 tamcnloB59wF4hNhiu17UeeST4W7OuSO+/VhoNJKtFt9zVMVhJdVz7DKTZc3B4N9fm
	 S6GtCSn6tx2mA==
From: Denis Mukhin via B4 Relay <devnull+dmukhin.ford.com@kernel.org>
Date: Fri, 03 Jan 2025 17:58:30 -0800
Subject: [PATCH v3 24/24] xen/console: unify printout behavior for UART
 emulators
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20250103-vuart-ns8250-v3-v1-24-c5d36b31d66c@ford.com>
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
In-Reply-To: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>, 
 Julien Grall <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, Jan Beulich <jbeulich@suse.com>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
 Denis Mukhin <dmukhin@ford.com>
X-Mailer: b4 0.14.2
X-Developer-Signature: v=1; a=ed25519-sha256; t=1735955892; l=6584;
 i=dmukhin@ford.com; s=20241125; h=from:subject:message-id;
 bh=ht6Wazj1keo9tj+WEpSpwlWS9w1mUW+HbPE+9o8P0XA=;
 b=a9v2A+pEGC73S64duP7Evt85PvPWNZaAkUU7eN+j8YqqbMH0bZXfZJ28pMx0ePRJsPx1uTi6w
 Bw2REOs04J5AizYVsUfSAOcGa9KX2lR3rudN3+aJ/KzFXDA+5IQITHi
X-Developer-Key: i=dmukhin@ford.com; a=ed25519;
 pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U=
X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with
 auth_id=287
X-Original-From: Denis Mukhin <dmukhin@ford.com>
Reply-To: dmukhin@ford.com

From: Denis Mukhin <dmukhin@ford.com>

If virtual UART prints on the physical console, the behavior is updated to:
- no prefix for Dom0 output;
- DOM$NUM for DomUs when not in focus, otherwise no prefix.

Introduce printk_noprefix() for convenient printouts which skip '(XEN)'
prefix on the physical console. This is needed for the case when physical
console is owned by a domain with in-hypervisor UART emulation enabled.

Add printk_noprefix() to exception into ECLAIR deviations list for
rule MC3A2.R17.1.

Use guest_printk() in all current in-hypervisor UART emulators. That aligns
behavior with debug I/O port 0xe9 handler in x86 port and slightly improves the
logging since guest_printk() already prints the domain ID.

Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
 automation/eclair_analysis/ECLAIR/deviations.ecl | 1 +
 xen/arch/arm/vpl011.c                            | 6 +++---
 xen/arch/arm/vuart.c                             | 8 +++++++-
 xen/arch/x86/hvm/vuart-ns16550.c                 | 7 +++++--
 xen/drivers/char/console.c                       | 8 ++++++++
 xen/include/xen/lib.h                            | 3 +++
 6 files changed, 27 insertions(+), 6 deletions(-)

diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
index ae25eeb76ac938588d16c9b4f9f116ddcaf97956..d94a8bc59d0b562cc285bb236dbac41a151042ac 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -523,6 +523,7 @@ safe."
 -config=MC3A2.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(panic)&&kind(function))))"}
 -config=MC3A2.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(elf_call_log_callback)&&kind(function))))"}
 -config=MC3A2.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(vprintk_common)&&kind(function))))"}
+-config=MC3A2.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(printk_noprefix)&&kind(function))))"}
 -config=MC3A2.R17.1,macros+={hide , "^va_(arg|start|copy|end)$"}
 -doc_end
 
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index efe77c13007716d0e0d70ab5ccf5f94268d5b693..ab85893174e76c5ec4350931a030760c9e0331b0 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -89,7 +89,7 @@ static void vpl011_write_data_xen(struct domain *d, uint8_t data)
     {
         if ( intf->out_prod == 1 )
         {
-            printk("%c", data);
+            printk_noprefix("%c", data);
             intf->out_prod = 0;
         }
         else
@@ -97,7 +97,7 @@ static void vpl011_write_data_xen(struct domain *d, uint8_t data)
             if ( data != '\n' )
                 intf->out[intf->out_prod++] = '\n';
             intf->out[intf->out_prod++] = '\0';
-            printk("%s", intf->out);
+            printk_noprefix("%s", intf->out);
             intf->out_prod = 0;
         }
     }
@@ -109,7 +109,7 @@ static void vpl011_write_data_xen(struct domain *d, uint8_t data)
             if ( data != '\n' )
                 intf->out[intf->out_prod++] = '\n';
             intf->out[intf->out_prod++] = '\0';
-            printk("DOM%u: %s", d->domain_id, intf->out);
+            guest_printk(d, "%s", intf->out);
             intf->out_prod = 0;
         }
     }
diff --git a/xen/arch/arm/vuart.c b/xen/arch/arm/vuart.c
index 03366da17a604502f6e0afb45e8824c9d7cfa3dd..0e0fba344b68760463e894dc43133121bccbd960 100644
--- a/xen/arch/arm/vuart.c
+++ b/xen/arch/arm/vuart.c
@@ -31,6 +31,7 @@
 #include <xen/serial.h>
 #include <asm/mmio.h>
 #include <xen/perfc.h>
+#include <xen/console.h>
 
 #include "vuart.h"
 
@@ -87,7 +88,12 @@ static void hwdom_vuart_print_char(struct vcpu *v, char c)
         if ( c != '\n' )
             uart->buf[uart->idx++] = '\n';
         uart->buf[uart->idx] = '\0';
-        printk(XENLOG_G_DEBUG "DOM%u: %s", d->domain_id, uart->buf);
+
+        if ( d->domain_id == console_get_owner() )
+            printk_noprefix("%s", uart->buf);
+        else
+            guest_printk(d, "%s", uart->buf);
+
         uart->idx = 0;
     }
     spin_unlock(&uart->lock);
diff --git a/xen/arch/x86/hvm/vuart-ns16550.c b/xen/arch/x86/hvm/vuart-ns16550.c
index d0c19f53399bd8241f54d2fe2716e62046b8e59d..67cc7e9acc396a2f4346aebeef85d4b96c0d0e3f 100644
--- a/xen/arch/x86/hvm/vuart-ns16550.c
+++ b/xen/arch/x86/hvm/vuart-ns16550.c
@@ -35,6 +35,7 @@
 #include <asm/setup.h>   /* max_init_domid */
 #include <public/io/console.h>
 #include <xen/8250-uart.h>
+#include <xen/console.h>
 #include <xen/ctype.h>
 #include <xen/ioreq.h>
 #include <xen/resource.h>
@@ -899,10 +900,12 @@ static int cf_check ns16550_putchar(struct domain *d, char ch)
         regs[UART_LSR] |= UART_LSR_DR | val;
 
         /*
-         * Echo the user input on Xen console.
+         * Echo the user input on Xen console iff Xen console input is owned
+         * by NS16550 domain.
          * NB: use 'console_timestamps=none' to disable Xen timestamps.
          */
-        printk("%c", ch);
+        if ( d->domain_id == console_get_owner() )
+            printk_noprefix("%c", ch);
 
         /* FIXME: check FCR when to fire an interrupt */
         ns16550_irq_check(vdev);
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 96375067164980a138b1a93161712c0758f4f7fe..64abde479305910d1a962e68d5c1f0c25000cb3d 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -1026,6 +1026,14 @@ void printk(const char *fmt, ...)
     va_end(args);
 }
 
+void printk_noprefix(const char *fmt, ...)
+{
+    va_list args;
+    va_start(args, fmt);
+    vprintk_common("", fmt, args);
+    va_end(args);
+}
+
 void guest_printk(const struct domain *d, const char *fmt, ...)
 {
     va_list args;
diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index 81b722ea3e801e9089aaf8758249feb3a758c4f7..e55b8fac8d4d121262a56948638d83f1146e5a06 100644
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -61,6 +61,9 @@ debugtrace_printk(const char *fmt, ...) {}
 extern void printk(const char *fmt, ...)
     __attribute__ ((format (printf, 1, 2), cold));
 
+extern void printk_noprefix(const char *fmt, ...)
+    __attribute__ ((format (printf, 1, 2), cold));
+
 #define printk_once(fmt, args...)               \
 ({                                              \
     static bool __read_mostly once_;            \

-- 
2.34.1




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 01:58:28 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 01:58:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864713.1276015 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtQp-0006tt-Bc; Sat, 04 Jan 2025 01:58:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864713.1276015; Sat, 04 Jan 2025 01:58:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtQo-0006ra-Jw; Sat, 04 Jan 2025 01:58:26 +0000
Received: by outflank-mailman (input) for mailman id 864713;
 Sat, 04 Jan 2025 01:58:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=AhC6=T4=kernel.org=devnull+dmukhin.ford.com@srs-se1.protection.inumbo.net>)
 id 1tTtQl-0005Ay-Gz
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 01:58:23 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5cc6243e-ca3f-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 02:58:16 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 01CB25C612B;
 Sat,  4 Jan 2025 01:57:34 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPS id 0EABBC4CEDD;
 Sat,  4 Jan 2025 01:58:15 +0000 (UTC)
Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org
 (localhost.localdomain [127.0.0.1])
 by smtp.lore.kernel.org (Postfix) with ESMTP id 030C4E77199;
 Sat,  4 Jan 2025 01:58:15 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5cc6243e-ca3f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1735955895;
	bh=/WKmnea3yLIQ6a+oMKt9n2ogwwKjvRERH5nesO0D+A4=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From;
	b=OD1jaknYEc0PCdD3OGrHIkODdou0AzX4vUcJI3flns1hwehOL4P9JPmQ+aIBQ3rjO
	 TlXCBDsEUh607FqwLg9hFiPQ1arJIvoapsVLxOOOJhK7UelCoK9g5Ekh7KUW6XlxmR
	 tZmk/OttAQ+CyW9kjMH+dI5+Nr1BpekQcf867RiFQMYMRI858D/o1aR/U6SZFZvwD+
	 nPdDRd0Xv3glrDZHpSk6XGfx13nk28lmho4FtZud1tlqgL8JVEPQ17R30KZK5a4nfO
	 lwi0tE5syOpK2BS8cQTH1JNEqljMIMkZUPZUAKTiOYgR8PdEyVBpki+0nC9xbqN1eH
	 q5cW6TtWwSGJg==
From: Denis Mukhin via B4 Relay <devnull+dmukhin.ford.com@kernel.org>
Date: Fri, 03 Jan 2025 17:58:12 -0800
Subject: [PATCH v3 06/24] xen/domain: introduce hardware emulation flags
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20250103-vuart-ns8250-v3-v1-6-c5d36b31d66c@ford.com>
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
In-Reply-To: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>, 
 Julien Grall <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, Jan Beulich <jbeulich@suse.com>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
 Denis Mukhin <dmukhin@ford.com>
X-Mailer: b4 0.14.2
X-Developer-Signature: v=1; a=ed25519-sha256; t=1735955892; l=15422;
 i=dmukhin@ford.com; s=20241125; h=from:subject:message-id;
 bh=yo4lK/WoRy/gFaXrqWR73G8aid7G29/FsP8hJ1ebvNs=;
 b=x65w53tEdhJNfnDQwDvwDCI6NghHC/63VP4zaLKnVqk0fUWNCWc/gcP61ZPVZC8xu1iwsvXGW
 mUlDZIBx7S4CbRDiYShFkvq1zTtTTSOVcQNRv5cCqQCg228IdGqqj2/
X-Developer-Key: i=dmukhin@ford.com; a=ed25519;
 pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U=
X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with
 auth_id=287
X-Original-From: Denis Mukhin <dmukhin@ford.com>
Reply-To: dmukhin@ford.com

From: Denis Mukhin <dmukhin@ford.com>

Define an architecture-independent location for describing hardware emulation
flags for configuring in-hypervisor emulators.

Print d->arch.emulation_flags from 'q' keyhandler for better traceability while
debugging in-hypervisor hardware emulators.

Also, expanded the error message in arch_domain_create() in x86 case when
user-defined domain emulation_flags are incompatible w/ platform supported
emulation_flags.

Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
 tools/helpers/init-xenstore-domain.c             |  1 +
 tools/libs/light/libxl_x86.c                     |  5 +-
 tools/ocaml/libs/xc/xenctrl_stubs.c              |  1 +
 tools/python/xen/lowlevel/xc/xc.c                |  5 +-
 tools/tests/paging-mempool/test-paging-mempool.c |  1 +
 tools/tests/resource/test-resource.c             |  1 +
 tools/tests/tsx/test-tsx.c                       |  1 +
 xen/arch/arm/include/asm/domain.h                |  2 +
 xen/arch/ppc/include/asm/domain.h                |  2 +
 xen/arch/riscv/include/asm/domain.h              |  2 +
 xen/arch/x86/domain.c                            | 11 +++--
 xen/arch/x86/include/asm/domain.h                |  3 +-
 xen/common/keyhandler.c                          |  1 +
 xen/include/Makefile                             |  1 +
 xen/include/public/arch-x86/xen.h                | 30 +-----------
 xen/include/public/virtdev.h                     | 61 ++++++++++++++++++++++++
 xen/include/xen/domain.h                         |  1 +
 17 files changed, 90 insertions(+), 39 deletions(-)

diff --git a/tools/helpers/init-xenstore-domain.c b/tools/helpers/init-xenstore-domain.c
index 01ca667d25d15032e9acaff025e83b80aefd2ecb..4b64a417def59c92b8bfb828468591d00d16c105 100644
--- a/tools/helpers/init-xenstore-domain.c
+++ b/tools/helpers/init-xenstore-domain.c
@@ -16,6 +16,7 @@
 #include <xen-tools/common-macros.h>
 #include <xen-xsm/flask/flask.h>
 #include <xen/io/xenbus.h>
+#include <xen/virtdev.h>
 
 #include "init-dom-json.h"
 
diff --git a/tools/libs/light/libxl_x86.c b/tools/libs/light/libxl_x86.c
index a3164a3077fec7e1b81a34074894dc646954a49a..80a8a4f17a9a2d7f84f94382e110d511b76604a2 100644
--- a/tools/libs/light/libxl_x86.c
+++ b/tools/libs/light/libxl_x86.c
@@ -1,5 +1,6 @@
 #include "libxl_internal.h"
 #include "libxl_arch.h"
+#include <xen/virtdev.h>
 #include <xen/arch-x86/cpuid.h>
 
 int libxl__arch_domain_prepare_config(libxl__gc *gc,
@@ -8,7 +9,9 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
 {
     switch(d_config->c_info.type) {
     case LIBXL_DOMAIN_TYPE_HVM:
-        config->arch.emulation_flags = (XEN_X86_EMU_ALL & ~XEN_X86_EMU_VPCI);
+        config->arch.emulation_flags = XEN_X86_EMU_ALL;
+        config->arch.emulation_flags &= ~XEN_X86_EMU_VPCI;
+
         if (!libxl_defbool_val(d_config->b_info.u.hvm.pirq))
             config->arch.emulation_flags &= ~XEN_X86_EMU_USE_PIRQ;
         break;
diff --git a/tools/ocaml/libs/xc/xenctrl_stubs.c b/tools/ocaml/libs/xc/xenctrl_stubs.c
index 863ab3c778cd19637d8c52ec67dac7623be848b5..b693f3458629fb956d543d7491348cf953c67d6f 100644
--- a/tools/ocaml/libs/xc/xenctrl_stubs.c
+++ b/tools/ocaml/libs/xc/xenctrl_stubs.c
@@ -35,6 +35,7 @@
 #define XC_WANT_COMPAT_MAP_FOREIGN_API
 #include <xenctrl.h>
 #include <xenguest.h>
+#include <xen/virtdev.h>
 #include <xen-tools/common-macros.h>
 
 #include "mmap_stubs.h"
diff --git a/tools/python/xen/lowlevel/xc/xc.c b/tools/python/xen/lowlevel/xc/xc.c
index 9feb12ae2b16e48cb5d0c3c45044ae226f152f2d..d064e9e7af2fcc09dbd6485e8b9ef648b8068d00 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -18,6 +18,7 @@
 #include <netdb.h>
 #include <arpa/inet.h>
 
+#include <xen/virtdev.h>
 #include <xen/elfnote.h>
 #include <xen/hvm/hvm_info_table.h>
 #include <xen/hvm/params.h>
@@ -159,9 +160,7 @@ static PyObject *pyxc_domain_create(XcObject *self,
 
 #if defined (__i386) || defined(__x86_64__)
     if ( config.flags & XEN_DOMCTL_CDF_hvm )
-        config.arch.emulation_flags = XEN_X86_EMU_ALL &
-                                      ~(XEN_X86_EMU_VPCI |
-                                        XEN_X86_EMU_USE_PIRQ);
+        config.arch.emulation_flags = XEN_X86_EMU_BASELINE;
 #elif defined (__arm__) || defined(__aarch64__)
     config.arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE;
 #else
diff --git a/tools/tests/paging-mempool/test-paging-mempool.c b/tools/tests/paging-mempool/test-paging-mempool.c
index 1ebc13455ac263b8d2067f3676ba324da61abb83..121ffdcd376ddb324130a441352bf2a53d69b1e9 100644
--- a/tools/tests/paging-mempool/test-paging-mempool.c
+++ b/tools/tests/paging-mempool/test-paging-mempool.c
@@ -9,6 +9,7 @@
 #include <xenforeignmemory.h>
 #include <xengnttab.h>
 #include <xen-tools/common-macros.h>
+#include <xen/virtdev.h>
 
 static unsigned int nr_failures;
 #define fail(fmt, ...)                          \
diff --git a/tools/tests/resource/test-resource.c b/tools/tests/resource/test-resource.c
index 1b10be16a6b43f8448a6f4ccf8fd093b6556b915..e388bfeec57b1f16a6ccd9ede8ff1c02c0448393 100644
--- a/tools/tests/resource/test-resource.c
+++ b/tools/tests/resource/test-resource.c
@@ -8,6 +8,7 @@
 #include <xenforeignmemory.h>
 #include <xengnttab.h>
 #include <xen-tools/common-macros.h>
+#include <xen/virtdev.h>
 
 static unsigned int nr_failures;
 #define fail(fmt, ...)                          \
diff --git a/tools/tests/tsx/test-tsx.c b/tools/tests/tsx/test-tsx.c
index 5af04953f340febcf56da9b041338237b71617cb..5681b3c846715e913169277ee4a11ca087013fb6 100644
--- a/tools/tests/tsx/test-tsx.c
+++ b/tools/tests/tsx/test-tsx.c
@@ -29,6 +29,7 @@
 #include <xenctrl.h>
 #include <xenguest.h>
 #include <xen-tools/common-macros.h>
+#include <xen/virtdev.h>
 
 #include "xg_private.h"
 
diff --git a/xen/arch/arm/include/asm/domain.h b/xen/arch/arm/include/asm/domain.h
index f1d72c6e48dfeba347b4cd091ca33603c368b7c0..3dedf758bbd1f142debbc7c2460398e1bea822d7 100644
--- a/xen/arch/arm/include/asm/domain.h
+++ b/xen/arch/arm/include/asm/domain.h
@@ -119,6 +119,8 @@ struct arch_domain
     void *tee;
 #endif
 
+    /* Hardware emulation flags. */
+    uint32_t emulation_flags;
 }  __cacheline_aligned;
 
 struct arch_vcpu
diff --git a/xen/arch/ppc/include/asm/domain.h b/xen/arch/ppc/include/asm/domain.h
index 3a447272c6f28586bf0d610929adbf228579e13f..8aa7b4a6ac0d0850542e94cb28e58c62c3a4b156 100644
--- a/xen/arch/ppc/include/asm/domain.h
+++ b/xen/arch/ppc/include/asm/domain.h
@@ -21,6 +21,8 @@ struct arch_vcpu {
 
 struct arch_domain {
     struct hvm_domain hvm;
+    /* Hardware emulation flags. */
+    uint32_t emulation_flags;
 };
 
 #include <xen/sched.h>
diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/asm/domain.h
index c3d965a559b6ce3661bf17166d0c51853ff295a2..b561e6f4f868e1f4a6670b11111eb8cfe84ca385 100644
--- a/xen/arch/riscv/include/asm/domain.h
+++ b/xen/arch/riscv/include/asm/domain.h
@@ -18,6 +18,8 @@ struct arch_vcpu {
 
 struct arch_domain {
     struct hvm_domain hvm;
+    /* Hardware emulation flags. */
+    uint32_t emulation_flags;
 };
 
 #include <xen/sched.h>
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 78a13e6812c9120901d0a70fb3bc1bd6a8b6917d..9669886ac95cbee27c9eb72b16386705b470e7b1 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -753,9 +753,7 @@ static bool emulation_flags_ok(const struct domain *d, uint32_t emflags)
              emflags != (X86_EMU_VPCI | X86_EMU_LAPIC | X86_EMU_IOAPIC) )
             return false;
         if ( !is_hardware_domain(d) &&
-             /* HVM PIRQ feature is user-selectable. */
-             (emflags & ~X86_EMU_USE_PIRQ) !=
-             (X86_EMU_ALL & ~(X86_EMU_VPCI | X86_EMU_USE_PIRQ)) &&
+             xen_emflags_allowable(emflags) != XEN_X86_EMU_BASELINE &&
              emflags != X86_EMU_LAPIC )
             return false;
     }
@@ -818,9 +816,12 @@ int arch_domain_create(struct domain *d,
 
     if ( !emulation_flags_ok(d, emflags) )
     {
-        printk(XENLOG_G_ERR "d%d: Xen does not allow %s domain creation "
+        printk(XENLOG_G_ERR "%pd: Xen does not allow %s %sdomain creation "
                "with the current selection of emulators: %#x\n",
-               d->domain_id, is_hvm_domain(d) ? "HVM" : "PV", emflags);
+               d,
+               is_hvm_domain(d) ? "HVM" : "PV",
+               is_hardware_domain(d) ? "(hardware) " : "",
+               emflags);
         return -EOPNOTSUPP;
     }
     d->arch.emulation_flags = emflags;
diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h
index b79d6badd71c4d96279555df62fad75fe817a2b6..2532616bca015d0aad9abc35e14948937ab39b8f 100644
--- a/xen/arch/x86/include/asm/domain.h
+++ b/xen/arch/x86/include/asm/domain.h
@@ -9,6 +9,7 @@
 #include <asm/mce.h>
 #include <asm/vpmu.h>
 #include <asm/x86_emulate.h>
+#include <public/virtdev.h>
 #include <public/vcpu.h>
 #include <public/hvm/hvm_info_table.h>
 
@@ -456,7 +457,7 @@ struct arch_domain
     /* Don't unconditionally inject #GP for unhandled MSRs. */
     bool msr_relaxed;
 
-    /* Emulated devices enabled bitmap. */
+    /* Hardware emulation flags. */
     uint32_t emulation_flags;
 } __cacheline_aligned;
 
diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
index 6ea54838d434f9788e309c79119f1dab92fba6e3..7c331bc17bf279d4dd95ec5bbb540a70657cc1d1 100644
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -302,6 +302,7 @@ static void cf_check dump_domains(unsigned char key)
             if ( test_bit(i, &d->watchdog_inuse_map) )
                 printk("    watchdog %d expires in %d seconds\n",
                        i, (u32)((d->watchdog_timer[i].expires - NOW()) >> 30));
+        printk("    emulation_flags %#x\n", d->arch.emulation_flags);
 
         arch_dump_domain_info(d);
 
diff --git a/xen/include/Makefile b/xen/include/Makefile
index 058b0a566b8b97305554add529ede6ba9ac53a7e..a7820e0e99763fbad36c52ba4f95290798e34893 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -15,6 +15,7 @@ headers-y := \
     compat/sched.h \
     compat/vcpu.h \
     compat/version.h \
+    compat/virtdev.h \
     compat/xen.h \
     compat/xlat.h
 headers-$(CONFIG_X86)     += compat/arch-x86/pmu.h
diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-x86/xen.h
index fc2487986642a7694578ab9d2f5f16d09761bff8..fdf05875f26e63d7bcce34a1ad4e931ce22dbdc5 100644
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -261,35 +261,7 @@ typedef struct arch_shared_info arch_shared_info_t;
  * XEN_DOMCTL_INTERFACE_VERSION.
  */
 struct xen_arch_domainconfig {
-#define _XEN_X86_EMU_LAPIC          0
-#define XEN_X86_EMU_LAPIC           (1U<<_XEN_X86_EMU_LAPIC)
-#define _XEN_X86_EMU_HPET           1
-#define XEN_X86_EMU_HPET            (1U<<_XEN_X86_EMU_HPET)
-#define _XEN_X86_EMU_PM             2
-#define XEN_X86_EMU_PM              (1U<<_XEN_X86_EMU_PM)
-#define _XEN_X86_EMU_RTC            3
-#define XEN_X86_EMU_RTC             (1U<<_XEN_X86_EMU_RTC)
-#define _XEN_X86_EMU_IOAPIC         4
-#define XEN_X86_EMU_IOAPIC          (1U<<_XEN_X86_EMU_IOAPIC)
-#define _XEN_X86_EMU_PIC            5
-#define XEN_X86_EMU_PIC             (1U<<_XEN_X86_EMU_PIC)
-#define _XEN_X86_EMU_VGA            6
-#define XEN_X86_EMU_VGA             (1U<<_XEN_X86_EMU_VGA)
-#define _XEN_X86_EMU_IOMMU          7
-#define XEN_X86_EMU_IOMMU           (1U<<_XEN_X86_EMU_IOMMU)
-#define _XEN_X86_EMU_PIT            8
-#define XEN_X86_EMU_PIT             (1U<<_XEN_X86_EMU_PIT)
-#define _XEN_X86_EMU_USE_PIRQ       9
-#define XEN_X86_EMU_USE_PIRQ        (1U<<_XEN_X86_EMU_USE_PIRQ)
-#define _XEN_X86_EMU_VPCI           10
-#define XEN_X86_EMU_VPCI            (1U<<_XEN_X86_EMU_VPCI)
-
-#define XEN_X86_EMU_ALL             (XEN_X86_EMU_LAPIC | XEN_X86_EMU_HPET |  \
-                                     XEN_X86_EMU_PM | XEN_X86_EMU_RTC |      \
-                                     XEN_X86_EMU_IOAPIC | XEN_X86_EMU_PIC |  \
-                                     XEN_X86_EMU_VGA | XEN_X86_EMU_IOMMU |   \
-                                     XEN_X86_EMU_PIT | XEN_X86_EMU_USE_PIRQ |\
-                                     XEN_X86_EMU_VPCI)
+    /* Hardware emulation flags. */
     uint32_t emulation_flags;
 
 /*
diff --git a/xen/include/public/virtdev.h b/xen/include/public/virtdev.h
new file mode 100644
index 0000000000000000000000000000000000000000..27434377ecacfe069a91dea3768d14b0c14e08b4
--- /dev/null
+++ b/xen/include/public/virtdev.h
@@ -0,0 +1,61 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef XEN__PUBLIC_VIRTDEV_H
+#define XEN__PUBLIC_VIRTDEV_H
+
+/*
+ * Domain hardware emulation flags.
+ */
+enum {
+    VIRTDEV_LAPIC      = 1U << 0,
+    VIRTDEV_HPET       = 1U << 1,
+    VIRTDEV_PM         = 1U << 2,
+    VIRTDEV_RTC        = 1U << 3,
+    VIRTDEV_IOAPIC     = 1U << 4,
+    VIRTDEV_PIC        = 1U << 5,
+    VIRTDEV_VGA        = 1U << 6,
+    VIRTDEV_IOMMU      = 1U << 7,
+    VIRTDEV_PIT        = 1U << 8,
+    VIRTDEV_PIRQ       = 1U << 9,
+    VIRTDEV_PCI        = 1U << 10,
+};
+
+#if defined(__i386__) || defined(__x86_64__)
+#define XEN_X86_EMU_LAPIC           VIRTDEV_LAPIC
+#define XEN_X86_EMU_HPET            VIRTDEV_HPET
+#define XEN_X86_EMU_PM              VIRTDEV_PM
+#define XEN_X86_EMU_RTC             VIRTDEV_RTC
+#define XEN_X86_EMU_IOAPIC          VIRTDEV_IOAPIC
+#define XEN_X86_EMU_PIC             VIRTDEV_PIC
+#define XEN_X86_EMU_VGA             VIRTDEV_VGA
+#define XEN_X86_EMU_IOMMU           VIRTDEV_IOMMU
+#define XEN_X86_EMU_PIT             VIRTDEV_PIT
+#define XEN_X86_EMU_USE_PIRQ        VIRTDEV_PIRQ
+#define XEN_X86_EMU_VPCI            VIRTDEV_PCI
+
+#define XEN_X86_EMU_ALL             (XEN_X86_EMU_LAPIC | XEN_X86_EMU_HPET |  \
+                                     XEN_X86_EMU_PM | XEN_X86_EMU_RTC |      \
+                                     XEN_X86_EMU_IOAPIC | XEN_X86_EMU_PIC |  \
+                                     XEN_X86_EMU_VGA | XEN_X86_EMU_IOMMU |   \
+                                     XEN_X86_EMU_PIT | XEN_X86_EMU_USE_PIRQ |\
+                                     XEN_X86_EMU_VPCI)
+
+/* PIRQ (HVM) feature is user-selectable (libxl). */
+#define XEN_X86_EMU_OPTIONAL        (XEN_X86_EMU_VPCI | \
+                                     XEN_X86_EMU_USE_PIRQ)
+
+#define XEN_X86_EMU_BASELINE        xen_emflags_allowable(XEN_X86_EMU_ALL)
+
+#define xen_emflags_allowable(x)    ( (x) & ~XEN_X86_EMU_OPTIONAL )
+#endif /* #if defined(__i386__) || defined(__x86_64__) */
+
+#endif /* XEN__PUBLIC_VIRTDEV_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index 3de56352911347a54cce310f0211bcc213d8a08d..eec093e9e167c14a536383422d280ed5ee56f698 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -5,6 +5,7 @@
 #include <xen/numa.h>
 #include <xen/types.h>
 
+#include <public/virtdev.h>
 #include <public/xen.h>
 
 struct guest_area {

-- 
2.34.1




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 01:58:28 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 01:58:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864704.1275949 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtQj-0005dd-Qx; Sat, 04 Jan 2025 01:58:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864704.1275949; Sat, 04 Jan 2025 01:58:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtQj-0005dW-NP; Sat, 04 Jan 2025 01:58:21 +0000
Received: by outflank-mailman (input) for mailman id 864704;
 Sat, 04 Jan 2025 01:58:19 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=AhC6=T4=kernel.org=devnull+dmukhin.ford.com@srs-se1.protection.inumbo.net>)
 id 1tTtQh-0005Ax-Po
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 01:58:19 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5c98c525-ca3f-11ef-a0de-8be0dac302b0;
 Sat, 04 Jan 2025 02:58:16 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 38D1BA406B3;
 Sat,  4 Jan 2025 01:56:26 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPS id 1FBE0C4CEDE;
 Sat,  4 Jan 2025 01:58:15 +0000 (UTC)
Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org
 (localhost.localdomain [127.0.0.1])
 by smtp.lore.kernel.org (Postfix) with ESMTP id 17060E77198;
 Sat,  4 Jan 2025 01:58:15 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5c98c525-ca3f-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1735955895;
	bh=ozuAIUEC9kYvZPh1viwAiXRxK6v41KulMiHqosxlddk=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From;
	b=Xt0TQgCWoK3CpeiNu3J2IHjIb9Pe+2HhWLjz2kE+qpVzBgDSDENK+vJF8/HtkP/Rt
	 QkLRRKIqqnt1VAvifCIfCqY0jXM7jMplW2U/0ewocCTu1jpRstsB8eXydVJ1/SfzGy
	 4/01jch0vTR3bUlV9OfQ0KMDETjanQZbMXrnsK0fcgZTSXWSbNWxaHnDLKM+UIkRIH
	 mtatQRWfVxHdI6UQMyjiVbb/beOnh82IQKY53mU9gkFcMbpa8QPGBFPAKsW269CiEd
	 OgC7KA+62rrfb49gPDJlqsKHH0xTm4/FwIESevxBoxj0WuY2aPfU0eE6fju7xyuURY
	 Qs3sMALrx36Qw==
From: Denis Mukhin via B4 Relay <devnull+dmukhin.ford.com@kernel.org>
Date: Fri, 03 Jan 2025 17:58:13 -0800
Subject: [PATCH v3 07/24] xen/console: introduce framework for UART
 emulators
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20250103-vuart-ns8250-v3-v1-7-c5d36b31d66c@ford.com>
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
In-Reply-To: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>, 
 Julien Grall <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, Jan Beulich <jbeulich@suse.com>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
 Denis Mukhin <dmukhin@ford.com>
X-Mailer: b4 0.14.2
X-Developer-Signature: v=1; a=ed25519-sha256; t=1735955892; l=20565;
 i=dmukhin@ford.com; s=20241125; h=from:subject:message-id;
 bh=+qDoty7zETfSP7cDTtaMjm20Q4Ar3xPkCT1pAjGNRBA=;
 b=NjNytDgX7I98JX0c3E/AXYpE2iJB+eZjNeTD482lBrp1oS+c9OEztAjDd1s0mETykULeJ1WF/
 q4187w3hOq7DQwmy7jv/TiTBlxPe4QoiOYQwlPfPTOZNuOGwTkDDjcy
X-Developer-Key: i=dmukhin@ford.com; a=ed25519;
 pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U=
X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with
 auth_id=287
X-Original-From: Denis Mukhin <dmukhin@ford.com>
Reply-To: dmukhin@ford.com

From: Denis Mukhin <dmukhin@ford.com>

Introduce a driver framework to abstract UART emulators in the hypervisor.

That allows for architecture-independent handling of virtual UARTs from Xen
console driver and simplifies enabling new architecture-dependent UART
emulators.

The framework is built under CONFIG_HAS_VUART, which is automatically enabled
once the user selects a specific UART emulator.

All domains w/ enabled vUART will have VIRTDEV_UART bit set in
d->arch.emulation_flags.

Current implementation supports maximum of one vUART per domain, excluding
emulators for hardware domains.

Use domain_has_vuart() in Xen console driver code to check whether the
domain can own the physical console focus.

Note, arm/vuart.c emulator is not hooked to virtdev-uart framework because the
emulator is limited to the hardware domains only and was not designed to own
the physical console input. Updated arm/vuart.c APIs to have 'hwdom_' prefix
instead of generic 'domain_' to avoid possible confusion.

Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
 xen/arch/arm/Kconfig              |  1 +
 xen/arch/arm/dom0less-build.c     |  4 +--
 xen/arch/arm/domain.c             |  2 +-
 xen/arch/arm/domctl.c             | 11 +++---
 xen/arch/arm/include/asm/vpl011.h | 21 +-----------
 xen/arch/arm/vpl011.c             | 33 ++++++++++++------
 xen/arch/arm/vuart.c              |  3 ++
 xen/arch/arm/xen.lds.S            |  1 +
 xen/arch/ppc/xen.lds.S            |  1 +
 xen/arch/riscv/xen.lds.S          |  1 +
 xen/arch/x86/hvm/hvm.c            |  1 +
 xen/arch/x86/xen.lds.S            |  1 +
 xen/common/keyhandler.c           |  3 ++
 xen/drivers/Kconfig               |  5 +++
 xen/drivers/Makefile              |  1 +
 xen/drivers/char/console.c        | 11 +++---
 xen/drivers/virtdev-uart.c        | 60 ++++++++++++++++++++++++++++++++
 xen/include/public/virtdev.h      |  1 +
 xen/include/xen/domain.h          |  3 ++
 xen/include/xen/virtdev-uart.h    | 72 +++++++++++++++++++++++++++++++++++++++
 xen/include/xen/xen.lds.h         | 10 ++++++
 21 files changed, 200 insertions(+), 46 deletions(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index a26d3e11827cfe030d36400e322aa9b65502674c..8af4538bec2df3c3b15fa42b054bda658d9edad0 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -175,6 +175,7 @@ config NEW_VGIC
 config SBSA_VUART_CONSOLE
 	bool "Emulated SBSA UART console support"
 	default y
+	select HAS_VUART
 	help
 	  Allows a guest to use SBSA Generic UART as a console. The
 	  SBSA Generic UART implements a subset of ARM PL011 UART.
diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index 49d1f14d659b28a906b498157e93ce544465d89e..78fba18b6aa80278207f920145c5aab4fecc6d18 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -785,7 +785,7 @@ static int __init construct_domU(struct domain *d,
      */
     if ( kinfo.vpl011 )
     {
-        rc = domain_vpl011_init(d, NULL);
+        rc = virtdev_uart_init(d, NULL);
         if ( rc < 0 )
             return rc;
     }
@@ -891,7 +891,7 @@ void __init create_domUs(void)
              * d->arch.vpl011.irq. So the logic to find the vIRQ has to
              * be hardcoded.
              * The logic here shall be consistent with the one in
-             * domain_vpl011_init().
+             * vpl011_init().
              */
             if ( flags & CDF_directmap )
             {
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 7ef1a95c290752d5a0167806e298aacc834ea640..dbc5bae6217b141b0f89f3e7fd2792ebd9c7a456 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -1067,7 +1067,7 @@ int domain_relinquish_resources(struct domain *d)
          * Release the resources allocated for vpl011 which were
          * allocated via a DOMCTL call XEN_DOMCTL_vuart_op.
          */
-        domain_vpl011_deinit(d);
+        virtdev_uart_exit(d);
 
 #ifdef CONFIG_IOREQ_SERVER
         ioreq_server_destroy_all(d);
diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
index 9d047065ba13ffe003d2565879cd073e78f76893..53c57b092d28f7a6dd7b8bf280d1d6fd0d27f54b 100644
--- a/xen/arch/arm/domctl.c
+++ b/xen/arch/arm/domctl.c
@@ -14,6 +14,7 @@
 #include <xen/mm.h>
 #include <xen/sched.h>
 #include <xen/types.h>
+#include <xen/virtdev-uart.h>
 #include <xsm/xsm.h>
 #include <public/domctl.h>
 
@@ -30,10 +31,7 @@ static int handle_vuart_init(struct domain *d,
                              struct xen_domctl_vuart_op *vuart_op)
 {
     int rc;
-    struct vpl011_init_info info;
-
-    info.console_domid = vuart_op->console_domid;
-    info.gfn = _gfn(vuart_op->gfn);
+    struct virtdev_uart_params info;
 
     if ( d->creation_finished )
         return -EPERM;
@@ -41,8 +39,11 @@ static int handle_vuart_init(struct domain *d,
     if ( vuart_op->type != XEN_DOMCTL_VUART_TYPE_VPL011 )
         return -EOPNOTSUPP;
 
-    rc = domain_vpl011_init(d, &info);
+    info.console_domid = vuart_op->console_domid;
+    info.gfn = _gfn(vuart_op->gfn);
+    info.evtchn = (evtchn_port_t)-1;
 
+    rc = virtdev_uart_init(d, &info);
     if ( !rc )
         vuart_op->evtchn = info.evtchn;
 
diff --git a/xen/arch/arm/include/asm/vpl011.h b/xen/arch/arm/include/asm/vpl011.h
index cc838682815c0d049ba33d3bf9966a64b2e527dd..89937ce60a41d739e1efa5af5da86e1ee23621c6 100644
--- a/xen/arch/arm/include/asm/vpl011.h
+++ b/xen/arch/arm/include/asm/vpl011.h
@@ -23,6 +23,7 @@
 #include <public/io/ring.h>
 #include <public/io/console.h>
 #include <xen/mm.h>
+#include <xen/virtdev-uart.h>
 
 /* helper macros */
 #define VPL011_LOCK(d,flags) spin_lock_irqsave(&(d)->arch.vpl011.lock, flags)
@@ -59,26 +60,6 @@ struct vpl011 {
     evtchn_port_t evtchn;
 };
 
-struct vpl011_init_info {
-    domid_t console_domid;
-    gfn_t gfn;
-    evtchn_port_t evtchn;
-};
-
-#ifdef CONFIG_SBSA_VUART_CONSOLE
-int domain_vpl011_init(struct domain *d,
-                       struct vpl011_init_info *info);
-void domain_vpl011_deinit(struct domain *d);
-int vpl011_rx_char_xen(struct domain *d, char c);
-#else
-static inline int domain_vpl011_init(struct domain *d,
-                                     struct vpl011_init_info *info)
-{
-    return -ENOSYS;
-}
-
-static inline void domain_vpl011_deinit(struct domain *d) { }
-#endif
 #endif  /* _VPL011_H_ */
 
 /*
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index 66047bf33cedb930a6bd7c96577913cd1ae08f05..236fd70d0847f375070dfff314bb8dd08d6ad166 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -19,6 +19,7 @@
 #include <xen/sched.h>
 #include <xen/console.h>
 #include <xen/serial.h>
+#include <xen/virtdev-uart.h>
 #include <public/domctl.h>
 #include <public/io/console.h>
 #include <asm/pl011-uart.h>
@@ -26,6 +27,8 @@
 #include <asm/vpl011.h>
 #include <asm/vreg.h>
 
+static void cf_check vpl011_exit(struct domain *d);
+
 /*
  * Since pl011 registers are 32-bit registers, all registers
  * are handled similarly allowing 8-bit, 16-bit and 32-bit
@@ -566,9 +569,9 @@ static void vpl011_data_avail(struct domain *d,
 }
 
 /*
- * vpl011_rx_char_xen adds a char to a domain's vpl011 receive buffer.
+ * vpl011_putchar adds a char to a domain's vpl011 receive buffer.
  */
-int vpl011_rx_char_xen(struct domain *d, char c)
+static int cf_check vpl011_putchar(struct domain *d, char c)
 {
     unsigned long flags;
     struct vpl011 *vpl011 = &d->arch.vpl011;
@@ -637,7 +640,8 @@ static void vpl011_notification(struct vcpu *v, unsigned int port)
     VPL011_UNLOCK(d, flags);
 }
 
-int domain_vpl011_init(struct domain *d, struct vpl011_init_info *info)
+static int cf_check vpl011_init(struct domain *d,
+                                struct virtdev_uart_params *params)
 {
     int rc;
     struct vpl011 *vpl011 = &d->arch.vpl011;
@@ -689,27 +693,28 @@ int domain_vpl011_init(struct domain *d, struct vpl011_init_info *info)
     }
 
     /*
-     * info is NULL when the backend is in Xen.
-     * info is != NULL when the backend is in a domain.
+     * params is NULL when the backend is in Xen.
+     * params is != NULL when the backend is in a domain.
      */
-    if ( info != NULL )
+    if ( params )
     {
         vpl011->backend_in_domain = true;
 
         /* Map the guest PFN to Xen address space. */
         rc =  prepare_ring_for_helper(d,
-                                      gfn_x(info->gfn),
+                                      gfn_x(params->gfn),
                                       &vpl011->backend.dom.ring_page,
                                       &vpl011->backend.dom.ring_buf);
         if ( rc < 0 )
             goto out;
 
-        rc = alloc_unbound_xen_event_channel(d, 0, info->console_domid,
+        rc = alloc_unbound_xen_event_channel(d, 0, params->console_domid,
                                              vpl011_notification);
         if ( rc < 0 )
             goto out1;
 
-        vpl011->evtchn = info->evtchn = rc;
+        params->evtchn = rc;
+        vpl011->evtchn = rc;
     }
     else
     {
@@ -740,13 +745,13 @@ int domain_vpl011_init(struct domain *d, struct vpl011_init_info *info)
     return 0;
 
 out1:
-    domain_vpl011_deinit(d);
+    vpl011_exit(d);
 
 out:
     return rc;
 }
 
-void domain_vpl011_deinit(struct domain *d)
+static void cf_check vpl011_exit(struct domain *d)
 {
     struct vpl011 *vpl011 = &d->arch.vpl011;
 
@@ -783,6 +788,12 @@ void domain_vpl011_deinit(struct domain *d)
         XFREE(vpl011->backend.xen);
 }
 
+static void cf_check vpl011_dump(struct domain *d)
+{
+}
+
+VIRTDEV_UART_REGISTER(vpl011);
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/vuart.c b/xen/arch/arm/vuart.c
index 23e05dba3a5617863f6c08f085c358f2cf32a292..03366da17a604502f6e0afb45e8824c9d7cfa3dd 100644
--- a/xen/arch/arm/vuart.c
+++ b/xen/arch/arm/vuart.c
@@ -17,6 +17,9 @@
  * /!\ This device is not intended to be enumerable or exposed to the OS
  * (e.g. via Device Tree).
  *
+ * Not hooked into virtdev-uart framework because this emulator is limited
+ * to hardware domains only and cannot own physical console input.
+ *
  * Julien Grall <julien.grall@linaro.org>
  * Ian Campbell <ian.campbell@citrix.com>
  * Copyright (c) 2012 Citrix Systems.
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index bbccff1a0350ef7ce7099c4756be12a7232d8de5..dd68dadccd7c873ddc98240c66b5af5896e9f04a 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -69,6 +69,7 @@ SECTIONS
        __proc_info_end = .;
 
        VPCI_ARRAY
+       VIRTDEV_UART_SECTION
   } :text
 
 #if defined(BUILD_ID)
diff --git a/xen/arch/ppc/xen.lds.S b/xen/arch/ppc/xen.lds.S
index 3f2a7676ec96f6d773825f2d3ecb90ab2f604e9f..419b8c472de03bd7db76a3ecc5c87080500e1870 100644
--- a/xen/arch/ppc/xen.lds.S
+++ b/xen/arch/ppc/xen.lds.S
@@ -56,6 +56,7 @@ SECTIONS
         *(.data.rel.ro.*)
 
         VPCI_ARRAY
+        VIRTDEV_UART_SECTION
 
         . = ALIGN(POINTER_ALIGN);
     } :text
diff --git a/xen/arch/riscv/xen.lds.S b/xen/arch/riscv/xen.lds.S
index dffc6ae11913fa52d556ee6639bbbd4abb5f44f9..3a2cde3b7de55395f3fba1ead0db91f35b362107 100644
--- a/xen/arch/riscv/xen.lds.S
+++ b/xen/arch/riscv/xen.lds.S
@@ -51,6 +51,7 @@ SECTIONS
         *(.data.rel.ro.*)
 
         VPCI_ARRAY
+        VIRTDEV_UART_SECTION
 
         . = ALIGN(POINTER_ALIGN);
     } :text
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index c4f1df248c1a7b2b3e5c45cef154e7ca80018dfc..ce21f5884b554f27991f19d9953731a9e8241e90 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -30,6 +30,7 @@
 #include <xen/vpci.h>
 #include <xen/nospec.h>
 #include <xen/vm_event.h>
+#include <xen/virtdev-uart.h>
 #include <asm/shadow.h>
 #include <asm/hap.h>
 #include <asm/current.h>
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 42217eaf2485ebc221749c1cf12794af8a153616..42e15ab2cf078d0cf5d870c7bc5c5d3e327d9f5f 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -146,6 +146,7 @@ SECTIONS
        __note_gnu_build_id_end = .;
 #endif
        VPCI_ARRAY
+       VIRTDEV_UART_SECTION
   } PHDR(text)
 
 #if defined(CONFIG_PVH_GUEST) && !defined(EFI)
diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
index 7c331bc17bf279d4dd95ec5bbb540a70657cc1d1..1040eda5a15f24fdf9324072b8524289969bad47 100644
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -22,6 +22,7 @@
 #include <xen/mm.h>
 #include <xen/watchdog.h>
 #include <xen/init.h>
+#include <xen/virtdev-uart.h>
 #include <asm/div64.h>
 
 static unsigned char keypress_key;
@@ -350,6 +351,8 @@ static void cf_check dump_domains(unsigned char key)
                            v->periodic_period / 1000000);
             }
         }
+
+        virtdev_uart_dump(d);
     }
 
     for_each_domain ( d )
diff --git a/xen/drivers/Kconfig b/xen/drivers/Kconfig
index 20050e9bb8b32bd16c2da76c2c3e0f68dab89394..355719c3af67683c153a4f7a35dad4944992846e 100644
--- a/xen/drivers/Kconfig
+++ b/xen/drivers/Kconfig
@@ -19,4 +19,9 @@ config HAS_VPCI_GUEST_SUPPORT
 	bool
 	select HAS_VPCI
 
+config HAS_VUART
+	bool "UART emulation framework"
+	help
+	  This selects UART emulation framework.
+
 endmenu
diff --git a/xen/drivers/Makefile b/xen/drivers/Makefile
index 2a1ae8ad130a2e62bf391528be669d07c056fece..6593e2118e8e2d65778af96c9f2c066a705b0186 100644
--- a/xen/drivers/Makefile
+++ b/xen/drivers/Makefile
@@ -5,3 +5,4 @@ obj-$(CONFIG_HAS_VPCI) += vpci/
 obj-$(CONFIG_HAS_PASSTHROUGH) += passthrough/
 obj-$(CONFIG_ACPI) += acpi/
 obj-$(CONFIG_VIDEO) += video/
+obj-$(CONFIG_HAS_VUART) += virtdev-uart.o
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 2d20a9d7531e069803eaf30ce79354b998c4a52f..0927c0564a67098c70dab576ebeda3825fadfb61 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -34,13 +34,11 @@
 #include <asm/setup.h>
 #include <xen/sections.h>
 #include <xen/consoled.h>
+#include <xen/virtdev-uart.h>
 
 #ifdef CONFIG_X86
 #include <asm/guest.h>
 #endif
-#ifdef CONFIG_SBSA_VUART_CONSOLE
-#include <asm/vpl011.h>
-#endif
 
 /* console: comma-separated list of console outputs. */
 static char __initdata opt_console[30] = OPT_CONSOLE_STR;
@@ -545,6 +543,7 @@ static void __serial_rx(char c)
         /*
          * Deliver input to the hardware domain buffer, unless it is
          * already full.
+         * NB: must be the first check: hardware domain may have emulated UART.
          */
         if ( (serial_rx_prod - serial_rx_cons) != SERIAL_RX_SIZE )
             serial_rx_ring[SERIAL_RX_MASK(serial_rx_prod++)] = c;
@@ -555,11 +554,9 @@ static void __serial_rx(char c)
          */
         send_global_virq(VIRQ_CONSOLE);
     }
-#ifdef CONFIG_SBSA_VUART_CONSOLE
-    else
+    else if ( domain_has_vuart(d) )
         /* Deliver input to the emulated UART. */
-        rc = vpl011_rx_char_xen(d, c);
-#endif
+        rc = virtdev_uart_putchar(d, c);
 
     if ( consoled_is_enabled() )
         /* Deliver input to the PV shim console. */
diff --git a/xen/drivers/virtdev-uart.c b/xen/drivers/virtdev-uart.c
new file mode 100644
index 0000000000000000000000000000000000000000..d238ef369c6b94429eaad9f33c79b63ba325b7c6
--- /dev/null
+++ b/xen/drivers/virtdev-uart.c
@@ -0,0 +1,60 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#include <xen/errno.h>
+#include <xen/event.h>
+#include <xen/virtdev-uart.h>
+#include <public/virtdev.h>
+
+extern const struct virtdev_uart *__start_virtdev_uart;
+
+int virtdev_uart_init(struct domain *d, struct virtdev_uart_params *params)
+{
+    int rc;
+
+    ASSERT(__start_virtdev_uart);
+
+    rc = __start_virtdev_uart->init(d, params);
+    if ( rc )
+        return rc;
+
+#if !defined(__i386__) && !defined(__x86_64__)
+    d->arch.emulation_flags |= VIRTDEV_UART;
+#endif
+
+    return 0;
+}
+
+void virtdev_uart_exit(struct domain *d)
+{
+    ASSERT(__start_virtdev_uart);
+
+    __start_virtdev_uart->exit(d);
+
+#if !defined(__i386__) && !defined(__x86_64__)
+    d->arch.emulation_flags &= ~VIRTDEV_UART;
+#endif
+}
+
+int virtdev_uart_putchar(struct domain *d, char c)
+{
+    ASSERT(__start_virtdev_uart);
+    ASSERT(d->arch.emulation_flags & VIRTDEV_UART);
+
+    return __start_virtdev_uart->putchar(d, c);
+}
+
+void virtdev_uart_dump(struct domain *d)
+{
+    ASSERT(__start_virtdev_uart);
+
+    __start_virtdev_uart->dump(d);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/public/virtdev.h b/xen/include/public/virtdev.h
index 27434377ecacfe069a91dea3768d14b0c14e08b4..36931e0d679cedadd4212f34142d7c3f00cd3389 100644
--- a/xen/include/public/virtdev.h
+++ b/xen/include/public/virtdev.h
@@ -17,6 +17,7 @@ enum {
     VIRTDEV_PIT        = 1U << 8,
     VIRTDEV_PIRQ       = 1U << 9,
     VIRTDEV_PCI        = 1U << 10,
+    VIRTDEV_UART       = 1U << 11,
 };
 
 #if defined(__i386__) || defined(__x86_64__)
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index eec093e9e167c14a536383422d280ed5ee56f698..4ae5def08eda40db58b6506b60a9393c82ba9aa7 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -54,6 +54,9 @@ void arch_get_domain_info(const struct domain *d,
 
 #define is_domain_direct_mapped(d) ((d)->cdf & CDF_directmap)
 #define is_domain_using_staticmem(d) ((d)->cdf & CDF_staticmem)
+#define domain_has_vuart(d) \
+    ( IS_ENABLED(CONFIG_HAS_VUART) && \
+      (d)->arch.emulation_flags & VIRTDEV_UART )
 
 /*
  * Arch-specifics.
diff --git a/xen/include/xen/virtdev-uart.h b/xen/include/xen/virtdev-uart.h
new file mode 100644
index 0000000000000000000000000000000000000000..fbe48e513996404d793d011747b3f40c236a6a57
--- /dev/null
+++ b/xen/include/xen/virtdev-uart.h
@@ -0,0 +1,72 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef XEN__VIRTDEV_UART_H
+#define XEN__VIRTDEV_UART_H
+
+#include <public/xen.h>
+#include <public/event_channel.h>
+#include <xen/types.h>
+
+struct virtdev_uart_params {
+    domid_t console_domid;
+    gfn_t gfn;
+    evtchn_port_t evtchn;
+};
+
+struct virtdev_uart {
+    int (*putchar)(struct domain *d, char c);
+    int (*init)(struct domain *d, struct virtdev_uart_params *params);
+    void (*exit)(struct domain *d);
+    void (*dump)(struct domain *d);
+};
+
+#define VIRTDEV_UART_REGISTER(x) \
+    static const struct virtdev_uart *x##_entry \
+           __used_section(".data.virtdev.uart") = \
+    &(const struct virtdev_uart){ \
+        .init    = x ## _init, \
+        .exit    = x ## _exit, \
+        .dump    = x ## _dump, \
+        .putchar = x ## _putchar, \
+    }
+
+#ifdef CONFIG_HAS_VUART
+
+int virtdev_uart_putchar(struct domain *d, char c);
+int virtdev_uart_init(struct domain *d, struct virtdev_uart_params *params);
+void virtdev_uart_exit(struct domain *d);
+void virtdev_uart_dump(struct domain *d);
+
+#else
+
+static inline int virtdev_uart_putchar(struct domain *d, char c)
+{
+    ASSERT_UNREACHABLE();
+    return -ENODEV;
+}
+
+static inline int virtdev_uart_init(struct domain *d,
+                                    struct virtdev_uart_params *params)
+{
+    return 0;
+}
+
+static inline void virtdev_uart_exit(struct domain *d)
+{
+}
+
+static inline void virtdev_uart_dump(struct domain *d)
+{
+}
+
+#endif /* CONFIG_HAS_VUART */
+
+#endif /* XEN__VIRTDEV_UART_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/xen/xen.lds.h b/xen/include/xen/xen.lds.h
index 16a9b1ba03db4861c3a8dbfe38e73335cc90a55e..c19d82a73f4c19a02082c8a6cf920002353b1e09 100644
--- a/xen/include/xen/xen.lds.h
+++ b/xen/include/xen/xen.lds.h
@@ -193,4 +193,14 @@
 #define VPCI_ARRAY
 #endif
 
+#ifdef CONFIG_HAS_VUART
+#define VIRTDEV_UART_SECTION \
+       . = ALIGN(POINTER_ALIGN); \
+       __start_virtdev_uart = .; \
+       *(.data.virtdev.uart) \
+       __end_virtdev_uart = .;
+#else
+#define VIRTDEV_UART_SECTION
+#endif
+
 #endif /* __XEN_LDS_H__ */

-- 
2.34.1




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 01:58:29 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 01:58:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864706.1275960 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtQk-0005nW-Ia; Sat, 04 Jan 2025 01:58:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864706.1275960; Sat, 04 Jan 2025 01:58:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtQk-0005mw-DF; Sat, 04 Jan 2025 01:58:22 +0000
Received: by outflank-mailman (input) for mailman id 864706;
 Sat, 04 Jan 2025 01:58: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
 <SRS0=AhC6=T4=kernel.org=devnull+dmukhin.ford.com@srs-se1.protection.inumbo.net>)
 id 1tTtQi-0005Ay-CN
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 01:58:20 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5cc997fe-ca3f-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 02:58:16 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 5D055A411CA;
 Sat,  4 Jan 2025 01:56:26 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPS id 3D46CC4CEE3;
 Sat,  4 Jan 2025 01:58:15 +0000 (UTC)
Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org
 (localhost.localdomain [127.0.0.1])
 by smtp.lore.kernel.org (Postfix) with ESMTP id 34815E77199;
 Sat,  4 Jan 2025 01:58:15 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5cc997fe-ca3f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1735955895;
	bh=xXcYmPnyoaBYwuvwmwzq65u8a7zL6rzG/+EY8Xv8xGE=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From;
	b=AcM7Vtoksl9NuXsBkmaV+MfZOCMRt2zDfmJPK3Gs9ieXp0syisbEcIaH8QlLJrQLB
	 SK0JUVGW11+9hKqDLS/5CnS9gX1lCP7TNMpbehJo5pxrkbCx1f2XwD+X12QgNzweK+
	 Kb0Bv6pRUw5UCFQesSfHU1uyrbXWwfuLw5clv5jqeXIy2xJOBtvkCKQXYBnIWMBFUH
	 v+dwRYvU2VEzOAf76MQFuSxW3ENllWV659LJ2nnv23vaVsVyct31+F9WFpxkQYkwjB
	 N0uaqRTn0UuVjJlMTbLz3BClt0PGRnuixH/tRLyRcau00SCMZHzxykwgSEub+mg/9o
	 nqii0jYMZ8Hog==
From: Denis Mukhin via B4 Relay <devnull+dmukhin.ford.com@kernel.org>
Date: Fri, 03 Jan 2025 17:58:15 -0800
Subject: [PATCH v3 09/24] xen/console: rename console_rx to console_owner
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20250103-vuart-ns8250-v3-v1-9-c5d36b31d66c@ford.com>
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
In-Reply-To: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>, 
 Julien Grall <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, Jan Beulich <jbeulich@suse.com>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
 Denis Mukhin <dmukhin@ford.com>
X-Mailer: b4 0.14.2
X-Developer-Signature: v=1; a=ed25519-sha256; t=1735955892; l=2836;
 i=dmukhin@ford.com; s=20241125; h=from:subject:message-id;
 bh=hlHBU29TJ6azKlgJxKuwT5okumjd5Gkw0PPbKZ55oxg=;
 b=8gj6SDYe8BztlUQL/hKRBIYVD38Gp7CgTWQrnGT86srkbF/wCLOJPeSHzvZRRElqsEEVQAoxG
 SSRoin1gwJzBzBL2tPOlDVb3Ajj9sx2b2fV9mk90Edf+KMiLPBHdtvO
X-Developer-Key: i=dmukhin@ford.com; a=ed25519;
 pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U=
X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with
 auth_id=287
X-Original-From: Denis Mukhin <dmukhin@ford.com>
Reply-To: dmukhin@ford.com

From: Denis Mukhin <dmukhin@ford.com>

Update the symbol name to prepare for the follow on semantic change of console
owner identifier.

Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
 xen/drivers/char/console.c | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 48866cf47beda39e48a7774277238273566382b1..33da5ff7933ea2186245763e07940c17d74bf40f 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -465,19 +465,19 @@ static void cf_check dump_console_ring_key(unsigned char key)
  */
 #define switch_code (opt_conswitch[0]-'a'+1)
 /*
- * console_rx=0 => input to xen
- * console_rx=1 => input to dom0 (or the sole shim domain)
- * console_rx=N => input to dom(N-1)
+ * console_owner=0 => input to xen
+ * console_owner=1 => input to dom0 (or the sole shim domain)
+ * console_owner=N => input to dom(N-1)
  */
-static unsigned int __read_mostly console_rx = 0;
+static unsigned int __read_mostly console_owner = 0;
 
 #define max_console_rx (max_init_domid + 1)
 
 struct domain *console_get_domain(void)
 {
-    if ( console_rx == 0 )
+    if ( console_owner == 0 )
             return NULL;
-    return rcu_lock_domain_by_id(console_rx - 1);
+    return rcu_lock_domain_by_id(console_owner - 1);
 }
 
 void console_put_domain(struct domain *d)
@@ -488,7 +488,7 @@ void console_put_domain(struct domain *d)
 
 static void console_switch_input(void)
 {
-    unsigned int next_rx = console_rx;
+    unsigned int next_rx = console_owner;
 
     /*
      * Rotate among Xen, dom0 and boot-time created domUs while skipping
@@ -501,7 +501,7 @@ static void console_switch_input(void)
 
         if ( next_rx++ >= max_console_rx )
         {
-            console_rx = 0;
+            console_owner = 0;
             printk("*** Serial input to Xen");
             break;
         }
@@ -514,7 +514,7 @@ static void console_switch_input(void)
         if ( d )
         {
             rcu_unlock_domain(d);
-            console_rx = next_rx;
+            console_owner = next_rx;
             printk("*** Serial input to DOM%u", domid);
             break;
         }
@@ -531,7 +531,7 @@ static void __serial_rx(char c)
     struct domain *d;
     int rc = 0;
 
-    if ( console_rx == 0 )
+    if ( console_owner == 0 )
         return handle_keypress(c, false);
 
     d = console_get_domain();
@@ -1105,7 +1105,7 @@ void __init console_endboot(void)
      * a useful 'how to switch' message.
      */
     if ( opt_conswitch[1] == 'x' )
-        console_rx = max_console_rx;
+        console_owner = max_console_rx;
 
     register_keyhandler('w', dump_console_ring_key,
                         "synchronously dump console ring buffer (dmesg)", 0);

-- 
2.34.1




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 01:58:29 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 01:58:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864715.1276030 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtQr-0007WK-Dj; Sat, 04 Jan 2025 01:58:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864715.1276030; Sat, 04 Jan 2025 01:58:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtQq-0007Sv-Qx; Sat, 04 Jan 2025 01:58:28 +0000
Received: by outflank-mailman (input) for mailman id 864715;
 Sat, 04 Jan 2025 01:58:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=AhC6=T4=kernel.org=devnull+dmukhin.ford.com@srs-se1.protection.inumbo.net>)
 id 1tTtQm-0005Ay-H0
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 01:58:24 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5e464a18-ca3f-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 02:58:19 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 558515C621C;
 Sat,  4 Jan 2025 01:57:34 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPS id 685DEC4CED6;
 Sat,  4 Jan 2025 01:58:15 +0000 (UTC)
Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org
 (localhost.localdomain [127.0.0.1])
 by smtp.lore.kernel.org (Postfix) with ESMTP id 60503E77198;
 Sat,  4 Jan 2025 01:58:15 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5e464a18-ca3f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1735955895;
	bh=Rhvc2dHX6LX7A5kB7XT3TmoF43oLjWAyucIlq8aPWO8=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From;
	b=h2vKd6wjlvtWJTSnq7BBIP2DCCk2KFcQqFErMa/vesz4YGrktaXvv4236nShvJaQ2
	 BL3Xn8zDsLKDdPMn81wGwk0mAcNA+csvfKZjlUD9xiRCw8jXFroWRFLbYVe5hlaxwi
	 GUG7bgXf95/92/3fc7uM954c9QFwi8C20Cfjum4IO6orVb4Fk1z1E7pT/ruYVD+0C6
	 NqpZhwbSWDvQdz7BE1Icob/7S6yprAHHpZlTE+fjgj5PNWDDt+aGxgOP4rkZ7n/RRZ
	 sQqMBU6anmn0KoYbbePqLNitnerGWE76Wi1lHt9yxxbhD/aNiCm9onCkV7VmBUYZwi
	 40En2jjmuwEOg==
From: Denis Mukhin via B4 Relay <devnull+dmukhin.ford.com@kernel.org>
Date: Fri, 03 Jan 2025 17:58:18 -0800
Subject: [PATCH v3 12/24] xen/console: introduce console_{get,set}_owner()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20250103-vuart-ns8250-v3-v1-12-c5d36b31d66c@ford.com>
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
In-Reply-To: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>, 
 Julien Grall <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, Jan Beulich <jbeulich@suse.com>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
 Denis Mukhin <dmukhin@ford.com>
X-Mailer: b4 0.14.2
X-Developer-Signature: v=1; a=ed25519-sha256; t=1735955892; l=7114;
 i=dmukhin@ford.com; s=20241125; h=from:subject:message-id;
 bh=dr4GoJ7mVh1JpOj1gtOyvwWAVMZqjbpSzztsCiE4+kM=;
 b=NnZnovgXXftfgxnQ8N3SMkVR+YZGMDuiEyNDqeNhX+V6VEW4Rut+uGiOeM4I+9pLYD39Hew8k
 qhwTi5Hgm+ID3jXYVkTApbFFLLhx6yrBx7PQS8JOF7VMJcO1ml6LApw
X-Developer-Key: i=dmukhin@ford.com; a=ed25519;
 pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U=
X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with
 auth_id=287
X-Original-From: Denis Mukhin <dmukhin@ford.com>
Reply-To: dmukhin@ford.com

From: Denis Mukhin <dmukhin@ford.com>

Switch console_owner address spaces from integers mapped to domain IDs to
straight domain IDs, which simplifies console focus handling code.

console_set_owner() is introduced for setting the new console owner. This is a
public API to Xen console driver (it will be used in the follow on code
change).

console_get_owner() is another public API used for retrieving current console
owner domain ID.

After the change, console_{get,put}_domain() do not need to be public console
APIs.

Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
 xen/arch/arm/vpl011.c      |   5 +--
 xen/drivers/char/console.c | 101 +++++++++++++++++++++------------------------
 xen/include/xen/console.h  |   4 +-
 3 files changed, 51 insertions(+), 59 deletions(-)

diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index 236fd70d0847f375070dfff314bb8dd08d6ad166..efe77c13007716d0e0d70ab5ccf5f94268d5b693 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -81,12 +81,11 @@ static void vpl011_write_data_xen(struct domain *d, uint8_t data)
     unsigned long flags;
     struct vpl011 *vpl011 = &d->arch.vpl011;
     struct vpl011_xen_backend *intf = vpl011->backend.xen;
-    struct domain *input = console_get_domain();
 
     VPL011_LOCK(d, flags);
 
     intf->out[intf->out_prod++] = data;
-    if ( d == input )
+    if ( d->domain_id == console_get_owner() )
     {
         if ( intf->out_prod == 1 )
         {
@@ -126,8 +125,6 @@ static void vpl011_write_data_xen(struct domain *d, uint8_t data)
     vpl011_update_interrupt_status(d);
 
     VPL011_UNLOCK(d, flags);
-
-    console_put_domain(input);
 }
 
 /*
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 8d68116991ba9e2c5a36840b4d973f8cafe95488..f5ff3ebd830d631fa5d8fb5db1cf68adafcd02b4 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -461,17 +461,15 @@ static void cf_check dump_console_ring_key(unsigned char key)
 
 /*
  * CTRL-<switch_char> changes input direction, rotating among Xen, Dom0,
- * and the DomUs started from Xen at boot.
+ * and the DomUs.
  */
 #define switch_code (opt_conswitch[0]-'a'+1)
-/*
- * console_owner=0 => input to xen
- * console_owner=1 => input to dom0 (or the sole shim domain)
- * console_owner=N => input to dom(N-1)
- */
-static unsigned int __read_mostly console_owner = 0;
 
-#define max_console_rx (max_init_domid + 1)
+/*
+ * Current console owner domain ID: either Xen or domain w/ d->is_console ==
+ * true.
+ */
+static domid_t __read_mostly console_owner = DOMID_XEN;
 
 static struct domain *console_get_domain_by_id(domid_t domid)
 {
@@ -488,14 +486,12 @@ static struct domain *console_get_domain_by_id(domid_t domid)
     return NULL;
 }
 
-struct domain *console_get_domain(void)
+static struct domain *console_get_domain(void)
 {
-    if ( console_owner == 0 )
-            return NULL;
-    return console_get_domain_by_id(console_owner - 1);
+    return console_get_domain_by_id(console_owner);
 }
 
-void console_put_domain(struct domain *d)
+static void console_put_domain(struct domain *d)
 {
     if ( d )
         rcu_unlock_domain(d);
@@ -510,42 +506,49 @@ static bool console_owner_possible(domid_t domid)
     return !!d;
 }
 
-static void console_switch_input(void)
+int console_set_owner(domid_t domid)
 {
-    unsigned int next_rx = console_owner;
+    if ( domid == DOMID_XEN )
+        printk("*** Serial input to Xen");
+    else if ( console_owner_possible(domid) )
+        printk("*** Serial input to DOM%u", domid);
+    else
+        return -ENOENT;
 
-    /*
-     * Rotate among Xen, dom0 and boot-time created domUs while skipping
-     * switching serial input to non existing domains.
-     */
-    for ( ; ; )
-    {
-        domid_t domid;
-
-        if ( next_rx++ >= max_console_rx )
-        {
-            console_owner = 0;
-            printk("*** Serial input to Xen");
-            break;
-        }
-
-        if ( consoled_is_enabled() && next_rx == 1 )
-            domid = get_initial_domain_id();
-        else
-            domid = next_rx - 1;
-
-        if ( console_owner_possible(domid) )
-        {
-            console_owner = next_rx;
-            printk("*** Serial input to DOM%u", domid);
-            break;
-        }
-    }
+    console_owner = domid;
 
     if ( switch_code )
         printk(" (type 'CTRL-%c' three times to switch input)",
                opt_conswitch[0]);
     printk("\n");
+
+    return 0;
+}
+
+domid_t console_get_owner(void)
+{
+    return console_owner;
+}
+
+/*
+ * Switch console input focus.
+ * Rotates input focus among Xen, dom0 and boot-time created domUs while
+ * skipping switching serial input to non existing domains.
+ */
+static void console_switch_input(void)
+{
+    domid_t i, n = max_init_domid + 1;
+
+    if ( console_owner == DOMID_XEN )
+        i = get_initial_domain_id();
+    else
+        i = console_owner + 1;
+
+    for ( ; i < n; i++ )
+        if ( !console_set_owner(i) )
+            break;
+    if ( i == n )
+        console_set_owner(DOMID_XEN);
 }
 
 static void __serial_rx(char c)
@@ -553,7 +556,7 @@ static void __serial_rx(char c)
     struct domain *d;
     int rc = 0;
 
-    if ( console_owner == 0 )
+    if ( console_owner == DOMID_XEN )
         return handle_keypress(c, false);
 
     d = console_get_domain();
@@ -1132,14 +1135,6 @@ void __init console_endboot(void)
 
     video_endboot();
 
-    /*
-     * If user specifies so, we fool the switch routine to redirect input
-     * straight back to Xen. I use this convoluted method so we still print
-     * a useful 'how to switch' message.
-     */
-    if ( opt_conswitch[1] == 'x' )
-        console_owner = max_console_rx;
-
     register_keyhandler('w', dump_console_ring_key,
                         "synchronously dump console ring buffer (dmesg)", 0);
     register_irq_keyhandler('+', &do_inc_thresh,
@@ -1149,8 +1144,8 @@ void __init console_endboot(void)
     register_irq_keyhandler('G', &do_toggle_guest,
                             "toggle host/guest log level adjustment", 0);
 
-    /* Serial input is directed to DOM0 by default. */
-    console_switch_input();
+    if ( opt_conswitch[1] != 'x' )
+        console_set_owner( get_initial_domain_id() );
 }
 
 int __init console_has(const char *device)
diff --git a/xen/include/xen/console.h b/xen/include/xen/console.h
index 8631fd279bfe1aba42b61d76fbdb45016c2859f9..c03028ad690fa6359105a174ecc77a30f2731948 100644
--- a/xen/include/xen/console.h
+++ b/xen/include/xen/console.h
@@ -31,8 +31,8 @@ void console_end_sync(void);
 void console_start_log_everything(void);
 void console_end_log_everything(void);
 
-struct domain *console_get_domain(void);
-void console_put_domain(struct domain *d);
+int console_set_owner(domid_t domid);
+domid_t console_get_owner(void);
 
 /*
  * Steal output from the console. Returns +ve identifier, else -ve error.

-- 
2.34.1




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 01:58:31 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 01:58:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864716.1276044 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtQs-0007kJ-Vw; Sat, 04 Jan 2025 01:58:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864716.1276044; Sat, 04 Jan 2025 01:58:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtQr-0007gA-Sx; Sat, 04 Jan 2025 01:58:29 +0000
Received: by outflank-mailman (input) for mailman id 864716;
 Sat, 04 Jan 2025 01:58: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
 <SRS0=AhC6=T4=kernel.org=devnull+dmukhin.ford.com@srs-se1.protection.inumbo.net>)
 id 1tTtQm-0005Ax-R2
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 01:58:24 +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 5e0b0c0b-ca3f-11ef-a0de-8be0dac302b0;
 Sat, 04 Jan 2025 02:58:19 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 362555C61E7;
 Sat,  4 Jan 2025 01:57:34 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPS id 4A394C4CEE5;
 Sat,  4 Jan 2025 01:58:15 +0000 (UTC)
Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org
 (localhost.localdomain [127.0.0.1])
 by smtp.lore.kernel.org (Postfix) with ESMTP id 43699E77188;
 Sat,  4 Jan 2025 01:58:15 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5e0b0c0b-ca3f-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1735955895;
	bh=AcdrW3O8H43kz0elqqoeILzh7ZG+wA08lKxXLcP1yPI=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From;
	b=qFWPcMge1P3Kadc0hgvWN/ZI1ulugOzHad0WyuquIw4VVVdq6ItD5M50Lc6lfgaKG
	 1EBNGneBMz9XFuzlvtmTOoG0WI9b4vVyJSJ01ZFp3Ph2LmE/OalHSlwLMyL8BCZsg2
	 IS+ixF1AKwNQpjIcCX2hDbV/gM9Gp6/YiTmN0iaZooPj/3QcJIOIW1tfK3FKO6JV9Y
	 scEqgbuw0rjTQgx6Koe0PnecrMxIJymYkHwESt+hUmEcj1j3EU2zfUxT9tfNy/Hu6n
	 ugZYH8hL6KTz3KN2vv6T9G44xee1roMqN0UrG/N0bAUdoSZS6+Vf2eYBw18xAfRw4o
	 2xFJ8T+FMuZBw==
From: Denis Mukhin via B4 Relay <devnull+dmukhin.ford.com@kernel.org>
Date: Fri, 03 Jan 2025 17:58:16 -0800
Subject: [PATCH v3 10/24] xen/console: introduce use of 'is_console' flag
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20250103-vuart-ns8250-v3-v1-10-c5d36b31d66c@ford.com>
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
In-Reply-To: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>, 
 Julien Grall <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, Jan Beulich <jbeulich@suse.com>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
 Denis Mukhin <dmukhin@ford.com>
X-Mailer: b4 0.14.2
X-Developer-Signature: v=1; a=ed25519-sha256; t=1735955892; l=6019;
 i=dmukhin@ford.com; s=20241125; h=from:subject:message-id;
 bh=HwgHil59vq9EKv+z5DPAShRIPOKHguO2oiS7uAA2fgM=;
 b=THBoqR6cFXYEpRta1DnD8ynIu+e0N3IIpv1WCUSL8mxTJf0v4ahgyFVw22S7EsevQiO/aNfdQ
 gTOEUQZPWe1AgSSXG5v76XgncIw7A76rvEW6HZzdSMPo6zNHBbixHgu
X-Developer-Key: i=dmukhin@ford.com; a=ed25519;
 pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U=
X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with
 auth_id=287
X-Original-From: Denis Mukhin <dmukhin@ford.com>
Reply-To: dmukhin@ford.com

From: Denis Mukhin <dmukhin@ford.com>

The code inspects d->is_console flag to decide whether the console focus
should move to the domain with console after administrator uses <Ctrl+aaa>
key combination to switch the console focus.

Console owner switch logic updated accordingly.

Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
 xen/arch/arm/dom0less-build.c |  1 -
 xen/arch/x86/pv/shim.c        |  2 ++
 xen/common/domain.c           |  2 ++
 xen/drivers/char/console.c    | 53 +++++++++++++++++++++++++++++++++++--------
 xen/drivers/virtdev-uart.c    |  2 ++
 5 files changed, 49 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index 78fba18b6aa80278207f920145c5aab4fecc6d18..818e693222059a5e99a44831be62644ac442392b 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -985,7 +985,6 @@ void __init create_domUs(void)
             panic("Error initializing LLC coloring for domain %s (rc = %d)\n",
                   dt_node_name(node), rc);
 
-        d->is_console = true;
         dt_device_set_used_by(node, d->domain_id);
 
         rc = construct_domU(d, node);
diff --git a/xen/arch/x86/pv/shim.c b/xen/arch/x86/pv/shim.c
index 81e4a0516d18b359561f471f1d96e38977661ca7..9eb120258aeaf7068eae88d1e7d1b95ea7a00f31 100644
--- a/xen/arch/x86/pv/shim.c
+++ b/xen/arch/x86/pv/shim.c
@@ -238,6 +238,8 @@ void __init pv_shim_setup_dom(struct domain *d, l4_pgentry_t *l4start,
      * guest from depleting the shim memory pool.
      */
     d->max_pages = domain_tot_pages(d);
+
+    d->is_console = true;
 }
 
 static void write_start_info(struct domain *d)
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 0c4cc771115509afe3bb457b8002961a73f5a8e7..711ec3bf3b7845a6c295575421c252193ccbc0ae 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -706,6 +706,8 @@ struct domain *domain_create(domid_t domid,
 
         old_hwdom = hardware_domain;
         hardware_domain = d;
+
+        d->is_console = true;
     }
 
     TRACE_TIME(TRC_DOM0_DOM_ADD, d->domain_id);
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 33da5ff7933ea2186245763e07940c17d74bf40f..8d68116991ba9e2c5a36840b4d973f8cafe95488 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -1,8 +1,8 @@
 /******************************************************************************
  * console.c
- * 
+ *
  * Emergency console I/O for Xen and the domain-0 guest OS.
- * 
+ *
  * Copyright (c) 2002-2004, K A Fraser.
  *
  * Added printf_ratelimit
@@ -473,11 +473,26 @@ static unsigned int __read_mostly console_owner = 0;
 
 #define max_console_rx (max_init_domid + 1)
 
+static struct domain *console_get_domain_by_id(domid_t domid)
+{
+    struct domain *d = rcu_lock_domain_by_id(domid);
+
+    if ( !d )
+        return NULL;
+
+    if ( d->is_console )
+        return d;
+
+    rcu_unlock_domain(d);
+
+    return NULL;
+}
+
 struct domain *console_get_domain(void)
 {
     if ( console_owner == 0 )
             return NULL;
-    return rcu_lock_domain_by_id(console_owner - 1);
+    return console_get_domain_by_id(console_owner - 1);
 }
 
 void console_put_domain(struct domain *d)
@@ -486,6 +501,15 @@ void console_put_domain(struct domain *d)
         rcu_unlock_domain(d);
 }
 
+static bool console_owner_possible(domid_t domid)
+{
+    struct domain *d = console_get_domain_by_id(domid);
+
+    console_put_domain(d);
+
+    return !!d;
+}
+
 static void console_switch_input(void)
 {
     unsigned int next_rx = console_owner;
@@ -497,7 +521,6 @@ static void console_switch_input(void)
     for ( ; ; )
     {
         domid_t domid;
-        struct domain *d;
 
         if ( next_rx++ >= max_console_rx )
         {
@@ -510,10 +533,9 @@ static void console_switch_input(void)
             domid = get_initial_domain_id();
         else
             domid = next_rx - 1;
-        d = rcu_lock_domain_by_id(domid);
-        if ( d )
+
+        if ( console_owner_possible(domid) )
         {
-            rcu_unlock_domain(d);
             console_owner = next_rx;
             printk("*** Serial input to DOM%u", domid);
             break;
@@ -562,8 +584,19 @@ static void __serial_rx(char c)
         /* Deliver input to the PV shim console. */
         rc = consoled_guest_tx(c);
 
-    if ( rc )
-        printk(KERN_ERR "d%pd: failed to process console input: %d\n", d, rc);
+    switch ( rc )
+    {
+    case 0:
+        break;
+    case -EBUSY:    /* Loopback mode */
+    case -ENOSPC:   /* FIFO is full */
+        printk(KERN_WARNING "d%pd: failed to process console input: %d\n", d, rc);
+        break;
+    default:
+        d->is_console = false;
+        printk(KERN_ERR "d%pd: disabled console forwarding: %d\n", d, rc);
+        break;
+    }
 
     console_put_domain(d);
 }
@@ -807,7 +840,7 @@ static int printk_prefix_check(char *p, char **pp)
     return ((atomic_read(&print_everything) != 0) ||
             (loglvl < lower_thresh) ||
             ((loglvl < upper_thresh) && printk_ratelimit()));
-} 
+}
 
 static int cf_check parse_console_timestamps(const char *s)
 {
diff --git a/xen/drivers/virtdev-uart.c b/xen/drivers/virtdev-uart.c
index d238ef369c6b94429eaad9f33c79b63ba325b7c6..fe119e3e6e938957613b182cbef0a29bf67230d2 100644
--- a/xen/drivers/virtdev-uart.c
+++ b/xen/drivers/virtdev-uart.c
@@ -20,6 +20,7 @@ int virtdev_uart_init(struct domain *d, struct virtdev_uart_params *params)
 #if !defined(__i386__) && !defined(__x86_64__)
     d->arch.emulation_flags |= VIRTDEV_UART;
 #endif
+    d->is_console = true;
 
     return 0;
 }
@@ -33,6 +34,7 @@ void virtdev_uart_exit(struct domain *d)
 #if !defined(__i386__) && !defined(__x86_64__)
     d->arch.emulation_flags &= ~VIRTDEV_UART;
 #endif
+    d->is_console = false;
 }
 
 int virtdev_uart_putchar(struct domain *d, char c)

-- 
2.34.1




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 01:58:32 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 01:58:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864718.1276052 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtQu-0007yX-2O; Sat, 04 Jan 2025 01:58:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864718.1276052; Sat, 04 Jan 2025 01:58:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtQt-0007vR-1e; Sat, 04 Jan 2025 01:58:31 +0000
Received: by outflank-mailman (input) for mailman id 864718;
 Sat, 04 Jan 2025 01:58:26 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=AhC6=T4=kernel.org=devnull+dmukhin.ford.com@srs-se1.protection.inumbo.net>)
 id 1tTtQn-0005Ax-RK
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 01:58:25 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5e419805-ca3f-11ef-a0de-8be0dac302b0;
 Sat, 04 Jan 2025 02:58:19 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 623155C625F;
 Sat,  4 Jan 2025 01:57:34 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPS id 7516CC4CEE9;
 Sat,  4 Jan 2025 01:58:15 +0000 (UTC)
Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org
 (localhost.localdomain [127.0.0.1])
 by smtp.lore.kernel.org (Postfix) with ESMTP id 6DB20E77188;
 Sat,  4 Jan 2025 01:58:15 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5e419805-ca3f-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1735955895;
	bh=mGCIEroumybSgb30DA3BBd6J1k+0FYicVpy3E9PFeTI=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From;
	b=ctBvz2h2HiFmbfQEBBl/oM8bOYWI3JupZjsJ8yg3yzx4HrpURZoMLCGmL0HErBCEj
	 l/d8+CrJq4eoYsqUdldJQzyD5QfTht0Fu1VaTOVzoio0+LvKNh5ykkK+sANJ1m2lgO
	 akmQejRoJASXz5PxdQbDgGKBnLxXTtMTHQqCiy45Avo/5lBnEK0pDmA3Hl66bZi4v/
	 gCA4tkbcFEISStiJi+VETTv9b8yD1DNIjEeG7C5c3DEl5XJ0pfB9AbpeF+OdCrVCCG
	 SZld4vH5YGZWA8dSZnR0O8M2eHJGaeBuUYDnYSx+Pgn2QX4jY0ixsXlrzoBTsNsoy2
	 ygICIRleHsEhQ==
From: Denis Mukhin via B4 Relay <devnull+dmukhin.ford.com@kernel.org>
Date: Fri, 03 Jan 2025 17:58:19 -0800
Subject: [PATCH v3 13/24] xen/console: introduce hwdom_crashconsole=
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20250103-vuart-ns8250-v3-v1-13-c5d36b31d66c@ford.com>
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
In-Reply-To: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>, 
 Julien Grall <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, Jan Beulich <jbeulich@suse.com>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
 Denis Mukhin <dmukhin@ford.com>
X-Mailer: b4 0.14.2
X-Developer-Signature: v=1; a=ed25519-sha256; t=1735955892; l=4542;
 i=dmukhin@ford.com; s=20241125; h=from:subject:message-id;
 bh=o12/OmA+RZtrOIYv5yea9Nc3i1rLnoZ0MtCOdADxSJE=;
 b=laDqlcBt7fXWKuNapo74tNzV0R3dtuySyU/fhDACTJj1HAdDb8hOd7TOnz2417TA0/aAgePzE
 m0fCgZPTNWVByduJodUh8Sxjnn3YP8OAQ5WwPrZV3Nq4hI/A+AC6YeP
X-Developer-Key: i=dmukhin@ford.com; a=ed25519;
 pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U=
X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with
 auth_id=287
X-Original-From: Denis Mukhin <dmukhin@ford.com>
Reply-To: dmukhin@ford.com

From: Denis Mukhin <dmukhin@ford.com>

The new command line switch `hwdom_crashconsole=BOOL` allows to switch serial
console input focus to xen for machine state inspection using keyhandler
mechanism after the hardware domain crashes.

The new command line switch is aliased via `dom0=...,crashconsole` knob.

Such functionality can be useful while debugging dom0 bringup.

Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
 docs/misc/xen-command-line.pandoc | 14 ++++++++++++++
 xen/arch/x86/dom0_build.c         |  2 ++
 xen/common/domain.c               | 14 +++++++++++++-
 xen/include/xen/domain.h          |  1 +
 4 files changed, 30 insertions(+), 1 deletion(-)

diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index 08b0053f9ced7a5c44318a3414f927c31fe4c876..1a5ee3c91c5cc8bf653e5054211035b5d1bd560f 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -822,6 +822,7 @@ Specify the bit width of the DMA heap.
 
 ### dom0
     = List of [ pv | pvh, shadow=<bool>, verbose=<bool>,
+                crashconsole=<bool>,
                 cpuid-faulting=<bool>, msr-relaxed=<bool> ] (x86)
 
     = List of [ sve=<integer> ] (Arm64)
@@ -855,6 +856,10 @@ Controls for how dom0 is constructed on x86 systems.
     information during the dom0 build.  It defaults to the compile time choice
     of `CONFIG_VERBOSE_DEBUG`.
 
+*   The `crashconsole` boolean instructs Xen to switch input console focus to
+    the hypervisor when dom0 shuts down and avoid performing dom0 domain
+    destruction.  Should only be used for debugging purposes.
+
 *   The `cpuid-faulting` boolean is an interim option, is only applicable to
     PV dom0, and defaults to true.
 
@@ -1491,6 +1496,15 @@ Specify whether guests are to be given access to physical port 80
 (often used for debugging purposes), to override the DMI based
 detection of systems known to misbehave upon accesses to that port.
 
+### hwdom_crashconsole
+> `= <boolean>`
+
+> Default: `false`
+
+The `hwdom_crashconsole` boolean instructs Xen to switch input console focus to
+the hypervisor when dom0 shuts down and avoid performing dom0 domain
+destruction.  Should only be used for debugging purposes.
+
 ### idle_latency_factor (x86)
 > `= <integer>`
 
diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index e8f5bf5447bc47a6daa3d95787106a4c11e80d31..706aeec0ecbb565a415edbfb33ca2fd72967c560 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -286,6 +286,8 @@ int __init parse_arch_dom0_param(const char *s, const char *e)
         opt_dom0_cpuid_faulting = val;
     else if ( (val = parse_boolean("msr-relaxed", s, e)) >= 0 )
         opt_dom0_msr_relaxed = val;
+    else if ( (val = parse_boolean("crashconsole", s, e)) >= 0 )
+        opt_hwdom_crashconsole = !!val;
     else
         return -EINVAL;
 
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 61e0890052eb0c7ff7c19cc2fbdbfb9af512a545..1063463789224818017f7c893312e819acc0714c 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -59,6 +59,13 @@ unsigned int xen_processor_pmbits = XEN_PROCESSOR_PM_PX;
 bool opt_dom0_vcpus_pin;
 boolean_param("dom0_vcpus_pin", opt_dom0_vcpus_pin);
 
+/*
+ * Hardware domain crash handler: if true, do not halt machine, but switch to
+ * Xen console for debugging.
+ */
+bool __ro_after_init opt_hwdom_crashconsole;
+boolean_param("hwdom_crashconsole", opt_hwdom_crashconsole);
+
 /* Protect updates/reads (resp.) of domain_list and domain_hash. */
 DEFINE_SPINLOCK(domlist_update_lock);
 DEFINE_RCU_READ_LOCK(domlist_read_lock);
@@ -1162,7 +1169,12 @@ int domain_shutdown(struct domain *d, u8 reason)
     reason = d->shutdown_code;
 
     if ( is_hardware_domain(d) )
-        hwdom_shutdown(reason);
+    {
+        if ( opt_hwdom_crashconsole )
+            console_set_owner(DOMID_XEN);
+        else
+            hwdom_shutdown(reason);
+    }
 
     if ( d->is_shutting_down )
     {
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index eef36bafd3574c97d2f1f5c1fc93b4b7b46b78ba..1edebdce3754861244f23f6b884dd07d63958881 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -154,6 +154,7 @@ extern unsigned int xen_processor_pmbits;
 extern bool opt_dom0_vcpus_pin;
 extern cpumask_t dom0_cpus;
 extern bool dom0_affinity_relaxed;
+extern bool opt_hwdom_crashconsole;
 
 /* vnuma topology per domain. */
 struct vnuma_info {

-- 
2.34.1




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 01:58:33 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 01:58:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864717.1276054 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtQu-0008CD-Rj; Sat, 04 Jan 2025 01:58:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864717.1276054; Sat, 04 Jan 2025 01:58:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtQt-00085l-UB; Sat, 04 Jan 2025 01:58:31 +0000
Received: by outflank-mailman (input) for mailman id 864717;
 Sat, 04 Jan 2025 01:58:25 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=AhC6=T4=kernel.org=devnull+dmukhin.ford.com@srs-se1.protection.inumbo.net>)
 id 1tTtQn-0005Ay-HM
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 01:58:25 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5e86857b-ca3f-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 02:58:19 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id BCBD75C6381;
 Sat,  4 Jan 2025 01:57:34 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPS id CCE25C4CEDD;
 Sat,  4 Jan 2025 01:58:15 +0000 (UTC)
Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org
 (localhost.localdomain [127.0.0.1])
 by smtp.lore.kernel.org (Postfix) with ESMTP id C54DCE77198;
 Sat,  4 Jan 2025 01:58:15 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5e86857b-ca3f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1735955895;
	bh=c/sQchAB2th2WIR91b/A5zvJkudq54ZcORx3s/2AFYc=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From;
	b=O3wpE11lMn4BMs9NE6jG7Q1a7wgxfshSnVuXaS7yZUJX8gSJrEUhFJPrZKeEPDjZf
	 gQUE2PfMxP/McKgUaPCwcq236fLhwJnZHoekBjERHLzjTRYdkIdw3RN9h1MO7q2WCW
	 +SYMuvCqHb2SsndAIQfD4FjgQfIB8oQN5BGoEd8L9GOsRpORKara7MJMu/UeOyYt7+
	 2d1vHWZUV5P9CFWxmHYUylm6v5SYjuBO1bOFQl5ZVM7EGrkrPaxLUcFRALcYXL8HPc
	 ESggfeSIh7sj08XUDmqZdyt0CVVOIQj8zDUaPg3ZjozYURGo0caiMU37m5gPOqH8Ym
	 /hwyXTB2HrdnA==
From: Denis Mukhin via B4 Relay <devnull+dmukhin.ford.com@kernel.org>
Date: Fri, 03 Jan 2025 17:58:25 -0800
Subject: [PATCH v3 19/24] xen/8250-uart: add missing definitions
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20250103-vuart-ns8250-v3-v1-19-c5d36b31d66c@ford.com>
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
In-Reply-To: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>, 
 Julien Grall <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, Jan Beulich <jbeulich@suse.com>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
 Denis Mukhin <dmukhin@ford.com>
X-Mailer: b4 0.14.2
X-Developer-Signature: v=1; a=ed25519-sha256; t=1735955892; l=7808;
 i=dmukhin@ford.com; s=20241125; h=from:subject:message-id;
 bh=T+cbSUlwhOiYz+Afz3lMbHpJVwMTNzMdAT/z7b8cRYc=;
 b=Seh7LR0DR3fCTrjLnw3IFzcTtD9s+yB1Dw9zGVcAIVgBH0T14IQCAi2JaSEmb3Itsmxz5kRJD
 fDh0gHaKhV9BZJqddjdkPR5d3OBSGRt1Jm6ts0V00OayTEtEPw4C1Re
X-Developer-Key: i=dmukhin@ford.com; a=ed25519;
 pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U=
X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with
 auth_id=287
X-Original-From: Denis Mukhin <dmukhin@ford.com>
Reply-To: dmukhin@ford.com

From: Denis Mukhin <dmukhin@ford.com>

Added missing definitions needed for NS8250 UART emulator.

Re-used newly introduced MSR definitions in the existing ns16550 driver.

Also, fixed indentation in a comment for FCR register.

Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
 xen/drivers/char/ns16550.c  |  6 ++--
 xen/include/xen/8250-uart.h | 78 +++++++++++++++++++++++++++++++++------------
 2 files changed, 60 insertions(+), 24 deletions(-)

diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
index eaeb0e09d01ea70f865b8aee4f34ab7a0d4c5cf9..025ba5819d46ea567d41cea512b5f166969fb95f 100644
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -721,9 +721,9 @@ static int __init check_existence(struct ns16550 *uart)
      * Check to see if a UART is really there.
      * Use loopback test mode.
      */
-    ns_write_reg(uart, UART_MCR, UART_MCR_LOOP | 0x0A);
-    status = ns_read_reg(uart, UART_MSR) & 0xF0;
-    return (status == 0x90);
+    ns_write_reg(uart, UART_MCR, UART_MCR_LOOP | UART_MCR_RTS | UART_MCR_OUT2);
+    status = ns_read_reg(uart, UART_MSR) & UART_MSR_STATUS;
+    return (status == (UART_MSR_CTS | UART_MSR_DCD));
 }
 
 #ifdef CONFIG_HAS_PCI
diff --git a/xen/include/xen/8250-uart.h b/xen/include/xen/8250-uart.h
index d13352940c13c50bac17d4cdf2f3bf584380776a..6d1af31d582a3dd674a401d7f649e28c889cdc3e 100644
--- a/xen/include/xen/8250-uart.h
+++ b/xen/include/xen/8250-uart.h
@@ -32,6 +32,7 @@
 #define UART_MCR          0x04    /* Modem control        */
 #define UART_LSR          0x05    /* line status          */
 #define UART_MSR          0x06    /* Modem status         */
+#define UART_SCR          0x07    /* Scratch pad          */
 #define UART_USR          0x1f    /* Status register (DW) */
 #define UART_DLL          0x00    /* divisor latch (ls) (DLAB=1) */
 #define UART_DLM          0x01    /* divisor latch (ms) (DLAB=1) */
@@ -42,6 +43,8 @@
 #define UART_IER_ETHREI   0x02    /* tx reg. empty        */
 #define UART_IER_ELSI     0x04    /* rx line status       */
 #define UART_IER_EMSI     0x08    /* MODEM status         */
+#define UART_IER_MASK \
+    (UART_IER_ERDAI | UART_IER_ETHREI | UART_IER_ELSI | UART_IER_EMSI)
 
 /* Interrupt Identification Register */
 #define UART_IIR_NOINT    0x01    /* no interrupt pending */
@@ -51,12 +54,19 @@
 #define UART_IIR_THR      0x02    /*  - tx reg. empty     */
 #define UART_IIR_MSI      0x00    /*  - MODEM status      */
 #define UART_IIR_BSY      0x07    /*  - busy detect (DW) */
+#define UART_IIR_FE       0xC0    /* FIFO enabled (2 bits) */
 
 /* FIFO Control Register */
-#define UART_FCR_ENABLE   0x01    /* enable FIFO          */
-#define UART_FCR_CLRX     0x02    /* clear Rx FIFO        */
-#define UART_FCR_CLTX     0x04    /* clear Tx FIFO        */
-#define UART_FCR_DMA      0x10    /* enter DMA mode       */
+#define UART_FCR_ENABLE     BIT(0, U)   /* enable FIFO          */
+#define UART_FCR_CLRX       BIT(1, U)   /* clear Rx FIFO        */
+#define UART_FCR_CLTX       BIT(2, U)   /* clear Tx FIFO        */
+#define UART_FCR_DMA        BIT(3, U)   /* enter DMA mode       */
+#define UART_FCR_RESERVED0  BIT(4, U)   /* reserved; always 0   */
+#define UART_FCR_RESERVED1  BIT(5, U)   /* reserved; always 0   */
+#define UART_FCR_RTB0       BIT(6, U)   /* receiver trigger bit #0 */
+#define UART_FCR_RTB1       BIT(7, U)   /* receiver trigger bit #1 */
+#define UART_FCR_TRG_MASK   (UART_FCR_RTB0 | UART_FCR_RTB1)
+
 #define UART_FCR_TRG1     0x00    /* Rx FIFO trig lev 1   */
 #define UART_FCR_TRG4     0x40    /* Rx FIFO trig lev 4   */
 #define UART_FCR_TRG8     0x80    /* Rx FIFO trig lev 8   */
@@ -64,17 +74,17 @@
 
 /*
  * Note: The FIFO trigger levels are chip specific:
- *	RX:76 = 00  01  10  11	TX:54 = 00  01  10  11
- * PC16550D:	 1   4   8  14		xx  xx  xx  xx
- * TI16C550A:	 1   4   8  14          xx  xx  xx  xx
- * TI16C550C:	 1   4   8  14          xx  xx  xx  xx
- * ST16C550:	 1   4   8  14		xx  xx  xx  xx
- * ST16C650:	 8  16  24  28		16   8  24  30	PORT_16650V2
- * NS16C552:	 1   4   8  14		xx  xx  xx  xx
- * ST16C654:	 8  16  56  60		 8  16  32  56	PORT_16654
- * TI16C750:	 1  16  32  56		xx  xx  xx  xx	PORT_16750
- * TI16C752:	 8  16  56  60		 8  16  32  56
- * Tegra:	 1   4   8  14		16   8   4   1	PORT_TEGRA
+ *  RX:76 = 00  01  10  11  TX:54 = 00  01  10  11
+ * PC16550D:     1   4   8  14      xx  xx  xx  xx
+ * TI16C550A:    1   4   8  14      xx  xx  xx  xx
+ * TI16C550C:    1   4   8  14      xx  xx  xx  xx
+ * ST16C550:     1   4   8  14      xx  xx  xx  xx
+ * ST16C650:     8  16  24  28      16   8  24  30  PORT_16650V2
+ * NS16C552:     1   4   8  14      xx  xx  xx  xx
+ * ST16C654:     8  16  56  60       8  16  32  56  PORT_16654
+ * TI16C750:     1  16  32  56      xx  xx  xx  xx  PORT_16750
+ * TI16C752:     8  16  56  60       8  16  32  56
+ * Tegra:        1   4   8  14      16   8   4   1  PORT_TEGRA
  */
 #define UART_FCR_R_TRIG_00 0x00
 #define UART_FCR_R_TRIG_01 0x40
@@ -96,11 +106,33 @@
 #define UART_LCR_CONF_MODE_B	0xBF		/* Configuration mode B */
 
 /* Modem Control Register */
-#define UART_MCR_DTR      0x01    /* Data Terminal Ready  */
-#define UART_MCR_RTS      0x02    /* Request to Send      */
-#define UART_MCR_OUT2     0x08    /* OUT2: interrupt mask */
-#define UART_MCR_LOOP     0x10    /* Enable loopback test mode */
-#define UART_MCR_TCRTLR   0x40    /* Access TCR/TLR (TI16C752, EFR[4]=1) */
+#define UART_MCR_DTR            BIT(0, U)   /* Data Terminal Ready  */
+#define UART_MCR_RTS            BIT(1, U)   /* Request to Send      */
+#define UART_MCR_OUT1           BIT(2, U)   /* OUT1: interrupt mask */
+#define UART_MCR_OUT2           BIT(3, U)   /* OUT2: interrupt mask */
+#define UART_MCR_LOOP           BIT(4, U)   /* Enable loopback test mode */
+#define UART_MCR_RESERVED0      BIT(5, U)   /* Reserved #0 */
+#define UART_MCR_RESERVED1      BIT(6, U)   /* Reserved #1 */
+#define UART_MCR_TCRTLR         BIT(6, U)   /* Access TCR/TLR (TI16C752, EFR[4]=1) */
+#define UART_MCR_RESERVED2      BIT(7, U)   /* Reserved #2 */
+#define UART_MCR_MASK \
+    (UART_MCR_DTR | UART_MCR_RTS | \
+     UART_MCR_OUT1 | UART_MCR_OUT2 | \
+     UART_MCR_LOOP)
+
+/* Modem Status Register */
+#define UART_MSR_DCTS           BIT(0, U)   /* Change in CTS */
+#define UART_MSR_DDSR           BIT(1, U)   /* Change in DSR */
+#define UART_MSR_TERI           BIT(2, U)   /* Change in RI */
+#define UART_MSR_DDCD           BIT(3, U)   /* Change in CTS */
+#define UART_MSR_CTS            BIT(4, U)
+#define UART_MSR_DSR            BIT(5, U)
+#define UART_MSR_RI             BIT(6, U)
+#define UART_MSR_DCD            BIT(7, U)
+#define UART_MSR_CHANGE \
+    (UART_MSR_DCTS | UART_MSR_DDSR | UART_MSR_TERI | UART_MSR_DDCD)
+#define UART_MSR_STATUS \
+    (UART_MSR_CTS | UART_MSR_DSR | UART_MSR_RI | UART_MSR_DCD)
 
 /* Line Status Register */
 #define UART_LSR_DR       0x01    /* Data ready           */
@@ -111,6 +143,7 @@
 #define UART_LSR_THRE     0x20    /* Xmit hold reg empty  */
 #define UART_LSR_TEMT     0x40    /* Xmitter empty        */
 #define UART_LSR_ERR      0x80    /* Error                */
+#define UART_LSR_MASK     (UART_LSR_OE | UART_LSR_BI)
 
 /* These parity settings can be ORed directly into the LCR. */
 #define UART_PARITY_NONE  (0<<3)
@@ -119,7 +152,10 @@
 #define UART_PARITY_MARK  (5<<3)
 #define UART_PARITY_SPACE (7<<3)
 
-/* Frequency of external clock source. This definition assumes PC platform. */
+/*
+ * Frequency of external UART clock source.
+ * Same as IBM PC master input clock frequency.
+ */
 #define UART_CLOCK_HZ     1843200
 
 /* Bits in Exar specific UART_XR_EFR register */

-- 
2.34.1




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 01:58:35 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 01:58:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864720.1276067 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtQw-00006f-NH; Sat, 04 Jan 2025 01:58:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864720.1276067; Sat, 04 Jan 2025 01:58:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtQv-0008TL-I8; Sat, 04 Jan 2025 01:58:33 +0000
Received: by outflank-mailman (input) for mailman id 864720;
 Sat, 04 Jan 2025 01:58:27 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=AhC6=T4=kernel.org=devnull+dmukhin.ford.com@srs-se1.protection.inumbo.net>)
 id 1tTtQo-0005Ax-RK
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 01:58:26 +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 5eac8ac3-ca3f-11ef-a0de-8be0dac302b0;
 Sat, 04 Jan 2025 02:58:19 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id CAA915C639F;
 Sat,  4 Jan 2025 01:57:34 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPS id E0C8BC4CEE1;
 Sat,  4 Jan 2025 01:58:15 +0000 (UTC)
Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org
 (localhost.localdomain [127.0.0.1])
 by smtp.lore.kernel.org (Postfix) with ESMTP id D810FE77188;
 Sat,  4 Jan 2025 01:58:15 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5eac8ac3-ca3f-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1735955895;
	bh=nSRwKS/LlYYRVpg8RD3W+jOmXH2WKIn1w6/k5ce46cI=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From;
	b=Q0oJSytHpCJ18yKH3eU+0eiIoBhxu4aXsWcv+wQbyrAfsK0SblMhDqc8Fj1GH3zu2
	 nAf5Z5qhTjoWRdPUfQc/qQQ5l931UhCoSjHGrXHEdRLLq6OHFrVaFRrIa2ieieLdRx
	 w3vsgK6F+lM3H9NanKEtv0Z8M+iF3kdHTChk+kfR5Qcg9EZJiCHfQoq5RiT1DvTUxY
	 ALoMaAw8vW3JS7Q/43Ub3x0BASTI5iYMsJB7zLWmvipHHzhBcOm9XsVC7/1u9ZHpM/
	 SaVL8zlWrj76w0m4PS/A+WFPodEyvhNvou0kMp53iI2ODr5Nig3LNNaWhM+FLWL5ce
	 OYi7DEg46BXug==
From: Denis Mukhin via B4 Relay <devnull+dmukhin.ford.com@kernel.org>
Date: Fri, 03 Jan 2025 17:58:26 -0800
Subject: [PATCH v3 20/24] x86/hvm: add HVM-specific Kconfig
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20250103-vuart-ns8250-v3-v1-20-c5d36b31d66c@ford.com>
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
In-Reply-To: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>, 
 Julien Grall <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, Jan Beulich <jbeulich@suse.com>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
 Denis Mukhin <dmukhin@ford.com>
X-Mailer: b4 0.14.2
X-Developer-Signature: v=1; a=ed25519-sha256; t=1735955892; l=5996;
 i=dmukhin@ford.com; s=20241125; h=from:subject:message-id;
 bh=ZuTYcfV9biFH1je7dgKxHOvxFrMn/uUk/GeyiLFF3sY=;
 b=Ku3PacZpewsitaaL+kvBF+lfGyiiPlFVCVhhsjjgR1C+JMZqsYY5+po+CuFLwLCorvFrQSYaU
 tUP9VKEu1XVD7+pNk0pEDd3kjb5KXYHvZukXa/aIu2dExvh5lytJzrv
X-Developer-Key: i=dmukhin@ford.com; a=ed25519;
 pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U=
X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with
 auth_id=287
X-Original-From: Denis Mukhin <dmukhin@ford.com>
Reply-To: dmukhin@ford.com

From: Denis Mukhin <dmukhin@ford.com>

Add separate menu for configuring HVM build-time settings to help organizing
HVM-specific options.

Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
 xen/arch/x86/Kconfig     | 76 +-----------------------------------------------
 xen/arch/x86/hvm/Kconfig | 74 ++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 75 insertions(+), 75 deletions(-)

diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 9cdd04721afa1916c7edd8fdf7d606858c73ce88..37362c205dc664a1e809322c2cfe9f45394e30df 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -30,7 +30,6 @@ config X86
 	select HAS_SCHED_GRANULARITY
 	select HAS_UBSAN
 	select HAS_VMAP
-	select HAS_VPCI if HVM
 	select NEEDS_LIBELF
 
 config ARCH_DEFCONFIG
@@ -107,42 +106,7 @@ config PV_LINEAR_PT
 
          If unsure, say Y.
 
-config HVM
-	bool "HVM support"
-	depends on !PV_SHIM_EXCLUSIVE
-	default !PV_SHIM
-	select COMPAT
-	select IOREQ_SERVER
-	select MEM_ACCESS_ALWAYS_ON
-	help
-	  Interfaces to support HVM domains.  HVM domains require hardware
-	  virtualisation extensions (e.g. Intel VT-x, AMD SVM), but can boot
-	  guests which have no specific Xen knowledge.
-
-	  This option is needed if you want to run HVM or PVH domains.
-
-	  If unsure, say Y.
-
-config AMD_SVM
-	bool "AMD-V" if EXPERT
-	depends on HVM
-	default y
-	help
-	  Enables virtual machine extensions on platforms that implement the
-	  AMD Virtualization Technology (AMD-V).
-	  If your system includes a processor with AMD-V support, say Y.
-	  If in doubt, say Y.
-
-config INTEL_VMX
-	bool "Intel VT-x" if EXPERT
-	depends on HVM
-	default y
-	select ARCH_VCPU_IOREQ_COMPLETION
-	help
-	  Enables virtual machine extensions on platforms that implement the
-	  Intel Virtualization Technology (Intel VT-x).
-	  If your system includes a processor with Intel VT-x support, say Y.
-	  If in doubt, say Y.
+source "arch/x86/hvm/Kconfig"
 
 config XEN_SHSTK
 	bool "Supervisor Shadow Stacks"
@@ -201,25 +165,6 @@ config BIGMEM
 
 	  If unsure, say N.
 
-config HVM_FEP
-	bool "HVM Forced Emulation Prefix support (UNSUPPORTED)" if UNSUPPORTED
-	default DEBUG
-	depends on HVM
-	help
-
-	  Compiles in a feature that allows HVM guest to arbitrarily
-	  exercise the instruction emulator.
-
-	  This feature can only be enabled during boot time with
-	  appropriate hypervisor command line option. Please read
-	  hypervisor command line documentation before trying to use
-	  this feature.
-
-	  This is strictly for testing purposes, and not appropriate
-	  for use in production.
-
-	  If unsure, say N.
-
 config TBOOT
 	bool "Xen tboot support (UNSUPPORTED)"
 	depends on INTEL && UNSUPPORTED
@@ -348,14 +293,6 @@ config HYPERV_GUEST
 
 endif
 
-config MEM_PAGING
-	bool "Xen memory paging support (UNSUPPORTED)" if UNSUPPORTED
-	depends on HVM
-
-config MEM_SHARING
-	bool "Xen memory sharing support (UNSUPPORTED)" if UNSUPPORTED
-	depends on HVM
-
 config REQUIRE_NX
 	bool "Require NX (No eXecute) support"
 	help
@@ -372,17 +309,6 @@ config REQUIRE_NX
 	  was unavailable. However, if enabled, Xen will no longer boot on
 	  any CPU which is lacking NX support.
 
-config ALTP2M
-	bool "Alternate P2M support" if EXPERT
-	depends on INTEL_VMX
-	default y
-	help
-	  Alternate-p2m allows a guest to manage multiple p2m guest physical
-	  "memory views" (as opposed to a single p2m).
-	  Useful for memory introspection.
-
-	  If unsure, stay with defaults.
-
 endmenu
 
 source "common/Kconfig"
diff --git a/xen/arch/x86/hvm/Kconfig b/xen/arch/x86/hvm/Kconfig
new file mode 100644
index 0000000000000000000000000000000000000000..fdfa9f80d30347ac9c34e52f5ba829bc11916dc0
--- /dev/null
+++ b/xen/arch/x86/hvm/Kconfig
@@ -0,0 +1,74 @@
+menuconfig HVM
+	bool "HVM support"
+	depends on !PV_SHIM_EXCLUSIVE
+	default !PV_SHIM
+	select COMPAT
+	select IOREQ_SERVER
+	select MEM_ACCESS_ALWAYS_ON
+	select HAS_VPCI
+	help
+	  Interfaces to support HVM domains.  HVM domains require hardware
+	  virtualisation extensions (e.g. Intel VT-x, AMD SVM), but can boot
+	  guests which have no specific Xen knowledge.
+
+	  This option is needed if you want to run HVM or PVH domains.
+
+	  If unsure, say Y.
+
+if HVM
+
+config AMD_SVM
+	bool "AMD-V" if EXPERT
+	default y
+	help
+	  Enables virtual machine extensions on platforms that implement the
+	  AMD Virtualization Technology (AMD-V).
+	  If your system includes a processor with AMD-V support, say Y.
+	  If in doubt, say Y.
+
+config INTEL_VMX
+	bool "Intel VT-x" if EXPERT
+	default y
+	select ARCH_VCPU_IOREQ_COMPLETION
+	help
+	  Enables virtual machine extensions on platforms that implement the
+	  Intel Virtualization Technology (Intel VT-x).
+	  If your system includes a processor with Intel VT-x support, say Y.
+	  If in doubt, say Y.
+
+config ALTP2M
+	bool "Alternate P2M support" if EXPERT
+	depends on INTEL_VMX
+	default y
+	help
+	  Alternate-p2m allows a guest to manage multiple p2m guest physical
+	  "memory views" (as opposed to a single p2m).
+	  Useful for memory introspection.
+
+	  If unsure, stay with defaults.
+
+config MEM_PAGING
+	bool "Xen memory paging support (UNSUPPORTED)" if UNSUPPORTED
+
+config MEM_SHARING
+	bool "Xen memory sharing support (UNSUPPORTED)" if UNSUPPORTED
+
+config HVM_FEP
+	bool "HVM Forced Emulation Prefix support (UNSUPPORTED)" if UNSUPPORTED
+	default DEBUG
+	help
+
+	  Compiles in a feature that allows HVM guest to arbitrarily
+	  exercise the instruction emulator.
+
+	  This feature can only be enabled during boot time with
+	  appropriate hypervisor command line option. Please read
+	  hypervisor command line documentation before trying to use
+	  this feature.
+
+	  This is strictly for testing purposes, and not appropriate
+	  for use in production.
+
+	  If unsure, say N.
+
+endif

-- 
2.34.1




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 01:58:36 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 01:58:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864719.1276078 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtQy-0000OV-9j; Sat, 04 Jan 2025 01:58:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864719.1276078; Sat, 04 Jan 2025 01:58:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtQw-0000JU-Pt; Sat, 04 Jan 2025 01:58:34 +0000
Received: by outflank-mailman (input) for mailman id 864719;
 Sat, 04 Jan 2025 01:58:27 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=AhC6=T4=kernel.org=devnull+dmukhin.ford.com@srs-se1.protection.inumbo.net>)
 id 1tTtQo-0005Ay-Hd
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 01:58:26 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5ec58b77-ca3f-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 02:58:20 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id E209E5C63D5;
 Sat,  4 Jan 2025 01:57:34 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPS id 035ACC4CEE3;
 Sat,  4 Jan 2025 01:58:16 +0000 (UTC)
Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org
 (localhost.localdomain [127.0.0.1])
 by smtp.lore.kernel.org (Postfix) with ESMTP id F03C5E77199;
 Sat,  4 Jan 2025 01:58:15 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5ec58b77-ca3f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1735955896;
	bh=ard5UX4ASLQLjRYgt3OZQKzVUpMmaZiWJf8THwt2c1U=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From;
	b=pjT2u1B9stcTye2oZXoJSsok8YnbeR7APOvvZFDRY0fe6gy/gUN7cnm1CQxp1BcRu
	 7wi2S1ioJ3dRXU0weq+015+gHH8TUEY5boJIqgPwa/1FfSqbIJnjvCMemyLLVgt0tF
	 +fX1ORtEjRWQpMsYqrJipU/tdibJlndU5Wo1oh9jyqnbrl7Zjpkre6Tdbt5XCjyGhC
	 w1dseJbChMBv/79CvAMfypfZ6iOYcAtxpzGJHrrH0i1khL3kPVutT5Wm97jgGz4T6B
	 z7ME3lylYuKs644SevAIRaNwbHWLHl/TjBwq+bUz7cjPLfCmadEYC7XVIsQQ0d8350
	 9iLCM4gcg3Rtg==
From: Denis Mukhin via B4 Relay <devnull+dmukhin.ford.com@kernel.org>
Date: Fri, 03 Jan 2025 17:58:27 -0800
Subject: [PATCH v3 21/24] x86/hvm: introduce NS16550-compatible UART
 emulator
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20250103-vuart-ns8250-v3-v1-21-c5d36b31d66c@ford.com>
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
In-Reply-To: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>, 
 Julien Grall <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, Jan Beulich <jbeulich@suse.com>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
 Denis Mukhin <dmukhin@ford.com>
X-Mailer: b4 0.14.2
X-Developer-Signature: v=1; a=ed25519-sha256; t=1735955892; l=33000;
 i=dmukhin@ford.com; s=20241125; h=from:subject:message-id;
 bh=JY8NnZN8J5h06Ci6rDls8X8bQvMTHJfCNc/lld0E2cs=;
 b=2L8iKGD6AUVIWHDKbg1Szk28hZQ7CfLJIVQJjGAYiGG79anmV/wrsZvPM0l5Hnhq0mnMfWHzd
 xCxAPAR0ODWAHGiqBl8VFqx9dgImRsResgUdqpT4oyCEr7K/CMEP7x/
X-Developer-Key: i=dmukhin@ford.com; a=ed25519;
 pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U=
X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with
 auth_id=287
X-Original-From: Denis Mukhin <dmukhin@ford.com>
Reply-To: dmukhin@ford.com

From: Denis Mukhin <dmukhin@ford.com>

Add initial in-hypervisor emulator for NS8250/NS16x50-compatible UARTs under
CONFIG_VUART_NS16550.

x86 port of Xen lacks vUART facility similar to Arm's vpl011 to support x86
guest OS bring up in the embedded setups.

In parallel domain creation scenario (hyperlaunch), NS16550 emulator helps
early guest firmware and OS bringup debugging, because it eliminates dependency
on the external emulator (qemu) being operational by the time domains are
created.

The emulator also allows to forward the physical console input to the x86
domain which is useful when a system has only one physical UART for early
debugging and this UART is owned by Xen.

By default, CONFIG_VUART_NS16550 enables emulation of NS16550 at I/O port
0x3f8, IRQ#4 in guest OS (legacy COM1).

Legacy COM resources can be selected at built-time and cannot be configured
per-domain yet.

Please refer to the NS16550 emulator code for limitations.

Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
 xen/arch/x86/hvm/Kconfig              |  48 ++
 xen/arch/x86/hvm/Makefile             |   1 +
 xen/arch/x86/hvm/hvm.c                |  10 +
 xen/arch/x86/hvm/vuart-ns16550.c      | 928 ++++++++++++++++++++++++++++++++++
 xen/arch/x86/include/asm/hvm/domain.h |   4 +
 xen/drivers/virtdev-uart.c            |   6 +
 xen/include/xen/resource.h            |   3 +
 7 files changed, 1000 insertions(+)

diff --git a/xen/arch/x86/hvm/Kconfig b/xen/arch/x86/hvm/Kconfig
index fdfa9f80d30347ac9c34e52f5ba829bc11916dc0..29de48c147d8362be8bf4f07a3dc0302a0547497 100644
--- a/xen/arch/x86/hvm/Kconfig
+++ b/xen/arch/x86/hvm/Kconfig
@@ -71,4 +71,52 @@ config HVM_FEP
 
 	  If unsure, say N.
 
+config VUART_NS16550
+	bool "NS16550-compatible UART Emulation" if EXPERT
+	depends on HAS_IOPORTS
+	select HAS_VUART
+	help
+	  In-hypervisor NS16550/NS16x50 UART emulation.
+
+	  Only legacy PC I/O ports are emulated.
+
+	  This is strictly for testing purposes (such as early HVM guest console),
+	  and not appropriate for use in production.
+
+choice VUART_NS16550_PC
+	prompt "IBM PC COM resources"
+	depends on VUART_NS16550
+	default VUART_NS16550_PC_COM1
+	help
+	  Default emulated NS16550 resources.
+
+config VUART_NS16550_PC_COM1
+	bool "COM1 (I/O port 0x3f8, IRQ#4)"
+
+config VUART_NS16550_PC_COM2
+	bool "COM2 (I/O port 0x2f8, IRQ#3)"
+
+config VUART_NS16550_PC_COM3
+	bool "COM3 (I/O port 0x3e8, IRQ#4)"
+
+config VUART_NS16550_PC_COM4
+	bool "COM4 (I/O port 0x2e8, IRQ#3)"
+
+endchoice
+
+config VUART_NS16550_LOG_LEVEL
+	int "UART emulator verbosity level"
+	range 0 3
+	default "1"
+	depends on VUART_NS16550
+	help
+	  Set the default log level of UART emulator.
+	  See include/xen/config.h for more details.
+
+config VUART_NS16550_DEBUG
+	bool "UART emulator development debugging"
+	depends on VUART_NS16550
+	help
+	  Enable development debugging.
+
 endif
diff --git a/xen/arch/x86/hvm/Makefile b/xen/arch/x86/hvm/Makefile
index 4c1fa5c6c2bf75d336b39f343241bfced5b91b09..ba2baa850183c31b199e4d080aa549e59947ddc1 100644
--- a/xen/arch/x86/hvm/Makefile
+++ b/xen/arch/x86/hvm/Makefile
@@ -29,3 +29,4 @@ obj-y += vm_event.o
 obj-y += vmsi.o
 obj-y += vpic.o
 obj-y += vpt.o
+obj-$(CONFIG_VUART_NS16550) += vuart-ns16550.o
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index ce21f5884b554f27991f19d9953731a9e8241e90..cf610c8e01974df012a93c60657218ae96ca36d9 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -680,6 +680,13 @@ int hvm_domain_initialise(struct domain *d,
     if ( rc != 0 )
         goto fail1;
 
+    if ( domain_has_vuart(d) )
+    {
+        rc = virtdev_uart_init(d, NULL);
+        if ( rc != 0 )
+            goto out_vioapic_deinit;
+    }
+
     stdvga_init(d);
 
     rtc_init(d);
@@ -700,6 +707,9 @@ int hvm_domain_initialise(struct domain *d,
     return 0;
 
  fail2:
+    if ( domain_has_vuart(d) )
+        virtdev_uart_exit(d);
+ out_vioapic_deinit:
     vioapic_deinit(d);
  fail1:
     if ( is_hardware_domain(d) )
diff --git a/xen/arch/x86/hvm/vuart-ns16550.c b/xen/arch/x86/hvm/vuart-ns16550.c
new file mode 100644
index 0000000000000000000000000000000000000000..d0c19f53399bd8241f54d2fe2716e62046b8e59d
--- /dev/null
+++ b/xen/arch/x86/hvm/vuart-ns16550.c
@@ -0,0 +1,928 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * NS16550-compatible UART Emulator.
+ *
+ * See:
+ * - Serial and UART Tutorial:
+ *     https://download.freebsd.org/doc/en/articles/serial-uart/serial-uart_en.pdf
+ * - UART w/ 16 byte FIFO:
+ *     https://www.ti.com/lit/ds/symlink/tl16c550c.pdf
+ * - UART w/ 64 byte FIFO:
+ *     https://www.ti.com/lit/ds/symlink/tl16c750.pdf
+ *
+ * Limitations:
+ * - Only x86;
+ * - Only HVM domains support (build-time), PVH domains are not supported yet;
+ * - Only legacy COM{1,2,3,4} resources via Kconfig, custom I/O ports/IRQs
+ *   are not supported;
+ * - Only Xen console as a backend, no inter-domain communication (similar to
+ *   vpl011 on Arm);
+ * - Only 8n1 emulation (8-bit data, no parity, 1 stop bit);
+ * - No toolstack integration;
+ * - No baud rate emulation (reports 115200 baud to the guest OS);
+ * - No FIFO-less mode emulation;
+ * - No RX FIFO interrupt moderation (FCR) emulation;
+ * - No integration w/ VM snapshotting (HVM_REGISTER_SAVE_RESTORE() and
+ *   friends);
+ * - No ISA IRQ sharing allowed;
+ * - No MMIO-based UART emulation.
+ */
+
+#define pr_prefix               "ns16550"
+#define pr_fmt(fmt)             pr_prefix ": " fmt
+#define pr_log_level            CONFIG_VUART_NS16550_LOG_LEVEL
+
+#include <asm/setup.h>   /* max_init_domid */
+#include <public/io/console.h>
+#include <xen/8250-uart.h>
+#include <xen/ctype.h>
+#include <xen/ioreq.h>
+#include <xen/resource.h>
+#include <xen/virtdev-uart.h>
+#include <xen/xvmalloc.h>
+
+#define pr_err(fmt, args...) do { \
+    gprintk(KERN_ERR, pr_fmt(fmt), ## args); \
+} while (0)
+
+#define pr_warn(fmt, args...) do { \
+    if ( pr_log_level >= 1) \
+        gprintk(KERN_WARNING, pr_fmt(fmt), ## args); \
+} while (0)
+
+#define pr_info(fmt, args...) do { \
+    if ( pr_log_level >= 2 ) \
+        gprintk(KERN_INFO, pr_fmt(fmt), ## args); \
+} while (0)
+
+#define pr_debug(fmt, args...) do { \
+    if ( pr_log_level >= 3 ) \
+        gprintk(KERN_DEBUG, pr_fmt(fmt), ## args); \
+} while (0)
+
+#if defined(CONFIG_VUART_NS16550_PC_COM1)
+#define X86_PC_UART_IDX         0
+#elif defined(CONFIG_VUART_NS16550_PC_COM2)
+#define X86_PC_UART_IDX         1
+#elif defined(CONFIG_VUART_NS16550_PC_COM3)
+#define X86_PC_UART_IDX         2
+#elif defined(CONFIG_VUART_NS16550_PC_COM4)
+#define X86_PC_UART_IDX         3
+#else
+#error "Unsupported I/O port"
+#endif
+
+/*
+ * Number of supported registers in the UART.
+ */
+#define NS16550_REGS_NUM        ( UART_SCR + 1 )
+
+/*
+ * Number of emulated registers.
+ *
+ * - Emulated registers [0..NS16550_REGS_NUM] are R/W registers for DLAB=0.
+ * - DLAB=1, R/W, DLL            = NS16550_REGS_NUM + 0
+ * - DLAB=1, R/W, DLM            = NS16550_REGS_NUM + 1
+ * -         R/O, IIR (IIR_THR)  = NS16550_REGS_NUM + 2
+ */
+#define NS16550_EMU_REGS_NUM    ( NS16550_REGS_NUM + 3 )
+
+/*
+ * Virtual NS16550 device state.
+ */
+struct vuart_ns16550 {
+    struct xencons_interface cons;      /* Emulated RX/TX FIFOs */
+    uint8_t regs[NS16550_EMU_REGS_NUM]; /* Emulated registers */
+    unsigned int irq;                   /* Emulated IRQ# */
+    uint64_t io_addr;                   /* Emulated I/O region base address */
+    uint64_t io_size;                   /* Emulated I/O region size */
+    const char *name;                   /* Device name */
+    struct domain *owner;               /* Owner domain */
+    spinlock_t lock;                    /* Protection */
+};
+
+/*
+ * Virtual device description.
+ */
+struct virtdev_desc {
+    const char *name;
+    const struct resource *res;
+};
+
+/*
+ * Legacy IBM PC NS16550 resources.
+ * There are only 4 I/O port ranges, hardcoding all of them here.
+ */
+static const struct virtdev_desc x86_pc_uarts[4] = {
+    [0] = {
+        .name = "COM1",
+        .res = (const struct resource[]){
+            { .type = IORESOURCE_IO,  .addr = 0x3F8, .size = NS16550_REGS_NUM },
+            { .type = IORESOURCE_IRQ, .addr = 4,     .size = 1 },
+            { .type = IORESOURCE_UNKNOWN },
+        },
+    },
+    [1] = {
+        .name = "COM2",
+        .res = (const struct resource[]){
+            { .type = IORESOURCE_IO,  .addr = 0x2F8, .size = NS16550_REGS_NUM },
+            { .type = IORESOURCE_IRQ, .addr = 3,     .size = 1 },
+            { .type = IORESOURCE_UNKNOWN },
+        },
+    },
+    [2] = {
+        .name = "COM3",
+        .res = (const struct resource[]){
+            { .type = IORESOURCE_IO,  .addr = 0x3E8, .size = NS16550_REGS_NUM },
+            { .type = IORESOURCE_IRQ, .addr = 4,     .size = 1 },
+            { .type = IORESOURCE_UNKNOWN },
+        },
+    },
+    [3] = {
+        .name = "COM4",
+        .res = (const struct resource[]){
+            { .type = IORESOURCE_IO,  .addr = 0x2E8, .size = NS16550_REGS_NUM },
+            { .type = IORESOURCE_IRQ, .addr = 3,     .size = 1 },
+            { .type = IORESOURCE_UNKNOWN },
+        },
+    },
+};
+
+static bool ns16550_fifo_rx_empty(const struct vuart_ns16550 *vdev)
+{
+    const struct xencons_interface *cons = &vdev->cons;
+
+    return cons->in_prod == cons->in_cons;
+}
+
+static bool ns16550_fifo_rx_full(const struct vuart_ns16550 *vdev)
+{
+    const struct xencons_interface *cons = &vdev->cons;
+
+    return cons->in_prod - cons->in_cons == ARRAY_SIZE(cons->in);
+}
+
+static void ns16550_fifo_rx_reset(struct vuart_ns16550 *vdev)
+{
+    struct xencons_interface *cons = &vdev->cons;
+
+    cons->in_cons = cons->in_prod;
+}
+
+static int ns16550_fifo_rx_getchar(struct vuart_ns16550 *vdev)
+{
+    struct xencons_interface *cons = &vdev->cons;
+    int rc;
+
+    if ( ns16550_fifo_rx_empty(vdev) )
+    {
+        pr_debug("%s: RX FIFO empty\n", vdev->name);
+        rc = -ENODATA;
+    }
+    else
+    {
+        rc = cons->in[MASK_XENCONS_IDX(cons->in_cons, cons->in)];
+        cons->in_cons++;
+    }
+
+    return rc;
+}
+
+static int ns16550_fifo_rx_putchar(struct vuart_ns16550 *vdev, char c)
+{
+    struct xencons_interface *cons = &vdev->cons;
+    int rc;
+
+    /*
+     * FIFO-less 8250/16450 UARTs: newly arrived word overwrites the contents
+     * of the THR.
+     */
+    if ( ns16550_fifo_rx_full(vdev) )
+    {
+        pr_debug("%s: RX FIFO full; resetting\n", vdev->name);
+        ns16550_fifo_rx_reset(vdev);
+        rc = -ENOSPC;
+    }
+    else
+        rc = 0;
+
+    cons->in[MASK_XENCONS_IDX(cons->in_prod, cons->in)] = c;
+    cons->in_prod++;
+
+    return rc;
+}
+
+static bool ns16550_fifo_tx_empty(const struct vuart_ns16550 *vdev)
+{
+    const struct xencons_interface *cons = &vdev->cons;
+
+    return cons->out_prod == cons->out_cons;
+}
+
+static void ns16550_fifo_tx_reset(struct vuart_ns16550 *vdev)
+{
+    struct xencons_interface *cons = &vdev->cons;
+
+    cons->out_prod = 0;
+    ASSERT(cons->out_cons == cons->out_prod);
+}
+
+/*
+ * Flush cached output to Xen console.
+ */
+static void ns16550_fifo_tx_flush(struct vuart_ns16550 *vdev)
+{
+    struct xencons_interface *cons = &vdev->cons;
+
+    if ( ns16550_fifo_tx_empty(vdev) )
+        return;
+
+    ASSERT(cons->out_prod < ARRAY_SIZE(cons->out));
+    cons->out[cons->out_prod] = '\0';
+    cons->out_prod++;
+
+    guest_printk(vdev->owner, "%s", cons->out);
+
+    ns16550_fifo_tx_reset(vdev);
+}
+
+/*
+ * Accumulate guest OS output before sending to Xen console.
+ */
+static void ns16550_fifo_tx_putchar(struct vuart_ns16550 *vdev, char ch)
+{
+    struct xencons_interface *cons = &vdev->cons;
+
+    if ( !is_console_printable(ch) )
+        return;
+
+    if ( ch != '\0' )
+    {
+        cons->out[cons->out_prod] = ch;
+        cons->out_prod++;
+    }
+
+    if ( cons->out_prod == ARRAY_SIZE(cons->out) - 1 ||
+         ch == '\n' || ch == '\0' )
+        ns16550_fifo_tx_flush(vdev);
+}
+
+static inline uint8_t cf_check ns16550_dlab_get(const struct vuart_ns16550 *vdev)
+{
+    return vdev->regs[UART_LCR] & UART_LCR_DLAB ? 1 : 0;
+}
+
+static bool cf_check ns16550_iir_check_lsi(const struct vuart_ns16550 *vdev)
+{
+    return !!(vdev->regs[UART_LSR] & UART_LSR_MASK);
+}
+
+static bool cf_check ns16550_iir_check_rda(const struct vuart_ns16550 *vdev)
+{
+    return !ns16550_fifo_rx_empty(vdev);
+}
+
+static bool cf_check ns16550_iir_check_thr(const struct vuart_ns16550 *vdev)
+{
+    return !!(vdev->regs[NS16550_REGS_NUM + UART_IIR] & UART_IIR_THR);
+}
+
+static bool cf_check ns16550_iir_check_msi(const struct vuart_ns16550 *vdev)
+{
+    return !!(vdev->regs[UART_MSR] & UART_MSR_CHANGE);
+}
+
+/*
+ * Get the interrupt identity reason.
+ *
+ * IIR is re-calculated once called, because NS16550 always reports high
+ * priority events first.
+ * regs[NS16550_REGS_NUM + UART_IIR] is used to store THR reason only.
+ */
+static uint8_t ns16550_iir_get(const struct vuart_ns16550 *vdev)
+{
+    /*
+     * Interrupt identity reasons by priority.
+     * NB: high priority are at lower indexes below.
+     */
+    static const struct {
+        bool (*check)(const struct vuart_ns16550 *vdev);
+        uint8_t ier;
+        uint8_t iir;
+    } iir_by_prio[] = {
+        [0] = { ns16550_iir_check_lsi, UART_IER_ELSI,   UART_IIR_LSI },
+        [1] = { ns16550_iir_check_rda, UART_IER_ERDAI,  UART_IIR_RDA },
+        [2] = { ns16550_iir_check_thr, UART_IER_ETHREI, UART_IIR_THR },
+        [3] = { ns16550_iir_check_msi, UART_IER_EMSI,   UART_IIR_MSI },
+    };
+    const uint8_t *regs = vdev->regs;
+    uint8_t iir = 0;
+    unsigned int i;
+
+    /*
+     * NB: every interaction w/ NS16550 registers (except DLAB=1) goes
+     * through that call.
+     */
+    ASSERT(spin_is_locked(&vdev->lock));
+
+    for ( i = 0; i < ARRAY_SIZE(iir_by_prio); i++ )
+    {
+        if ( (regs[UART_IER] & iir_by_prio[i].ier) &&
+             iir_by_prio[i].check(vdev) )
+            break;
+
+    }
+    if ( i == ARRAY_SIZE(iir_by_prio) )
+        iir |= UART_IIR_NOINT;
+    else
+        iir |= iir_by_prio[i].iir;
+
+    if ( regs[UART_FCR] & UART_FCR_ENABLE )
+        iir |= UART_IIR_FE;
+
+    return iir;
+}
+
+/*
+ * Assert/deassert virtual NS16550 interrupt line.
+ */
+static void ns16550_irq_check(const struct vuart_ns16550 *vdev)
+{
+    uint8_t iir = ns16550_iir_get(vdev);
+
+    if ( iir & UART_IIR_NOINT )
+        hvm_isa_irq_assert(vdev->owner, vdev->irq, NULL);
+    else
+        hvm_isa_irq_deassert(vdev->owner, vdev->irq);
+
+    pr_debug("%s: IRQ#%d %x %s\n", vdev->name, vdev->irq, iir,
+             (iir & UART_IIR_NOINT) ? "deassert" : "assert");
+}
+
+/*
+ * Emulate 8-bit write access to NS16550 register.
+ */
+static int ns16550_io_write8(
+    struct vuart_ns16550 *vdev, uint32_t reg, uint8_t *data)
+{
+    uint8_t *regs = vdev->regs;
+    uint8_t val = *data;
+    int rc = 0;
+
+    if ( ns16550_dlab_get(vdev) && (reg == UART_DLL || reg == UART_DLM) )
+        regs[NS16550_REGS_NUM + reg] = val;
+    else
+    {
+        switch ( reg )
+        {
+        case UART_THR:
+            if ( regs[UART_MCR] & UART_MCR_LOOP )
+            {
+                (void)ns16550_fifo_rx_putchar(vdev, val);
+                regs[UART_LSR] |= UART_LSR_OE;
+            }
+            else
+                ns16550_fifo_tx_putchar(vdev, val);
+
+            regs[NS16550_REGS_NUM + UART_IIR] |= UART_IIR_THR;
+
+            break;
+
+        case UART_IER:
+            /*
+             * NB: Make sure THR interrupt is re-triggered once guest OS
+             * re-enabled ETHREI in EIR.
+             */
+            if ( val & regs[UART_IER] & UART_IER_ETHREI )
+                regs[NS16550_REGS_NUM + UART_IIR] |= UART_IIR_THR;
+
+            regs[UART_IER] = val & UART_IER_MASK;
+
+            break;
+
+        case UART_FCR: /* WO */
+            if ( val & UART_FCR_RESERVED0 )
+                pr_warn("%s: FCR: attempt to set reserved bit: %x\n",
+                        vdev->name, UART_FCR_RESERVED0);
+
+            if ( val & UART_FCR_RESERVED1 )
+                pr_warn("%s: FCR: attempt to set reserved bit: %x\n",
+                        vdev->name, UART_FCR_RESERVED1);
+
+            if ( val & UART_FCR_CLRX )
+                ns16550_fifo_rx_reset(vdev);
+
+            if ( val & UART_FCR_CLTX )
+                ns16550_fifo_tx_flush(vdev);
+
+            if ( val & UART_FCR_ENABLE )
+                val &= UART_FCR_ENABLE | UART_FCR_DMA | UART_FCR_TRG_MASK;
+            else
+                val = 0;
+
+            regs[UART_FCR] = val;
+
+            break;
+
+        case UART_LCR:
+            regs[UART_LCR] = val;
+            break;
+
+        case UART_MCR: {
+            uint8_t msr_curr, msr_next, msr_delta;
+
+            msr_curr = regs[UART_MSR];
+            msr_next = 0;
+            msr_delta = 0;
+
+            if ( val & UART_MCR_RESERVED0 )
+                pr_warn("%s: MCR: attempt to set reserved bit: %x\n",
+                        vdev->name, UART_MCR_RESERVED0);
+
+            if ( val & UART_MCR_RESERVED1 )
+                pr_warn("%s: MCR: attempt to set reserved bit: %x\n",
+                        vdev->name, UART_MCR_RESERVED1);
+
+            if ( val & UART_MCR_RESERVED2 )
+                pr_warn("%s: MCR: attempt to set reserved bit: %x\n",
+                        vdev->name, UART_MCR_RESERVED2);
+
+            /* Set modem status */
+            if ( val & UART_MCR_LOOP )
+            {
+                if ( val & UART_MCR_DTR )
+                    msr_next |= UART_MSR_DSR;
+                if ( val & UART_MCR_RTS )
+                    msr_next |= UART_MSR_CTS;
+                if ( val & UART_MCR_OUT1 )
+                    msr_next |= UART_MSR_RI;
+                if ( val & UART_MCR_OUT2 )
+                    msr_next |= UART_MSR_DCD;
+            }
+            else
+                msr_next |= UART_MSR_DCD | UART_MSR_DSR | UART_MSR_CTS;
+
+            /* Calculate changes in modem status */
+            if ( (msr_curr & UART_MSR_CTS) ^ (msr_next & UART_MSR_CTS) )
+                msr_delta |= UART_MSR_DCTS;
+            if ( (msr_curr & UART_MCR_RTS) ^ (msr_next & UART_MCR_RTS) )
+                msr_delta |= UART_MSR_DDSR;
+            if ( (msr_curr & UART_MSR_RI)  & (msr_next & UART_MSR_RI) )
+                msr_delta |= UART_MSR_TERI;
+            if ( (msr_curr & UART_MSR_DCD) ^ (msr_next & UART_MSR_DCD) )
+                msr_delta |= UART_MSR_DDCD;
+
+            regs[UART_MCR] = val & UART_MCR_MASK;
+            regs[UART_MSR] = msr_next | msr_delta;
+
+            break;
+        }
+
+        /* NB: Firmware (e.g. OVMF) may rely on SCR presence. */
+        case UART_SCR:
+            regs[UART_SCR] = val;
+            break;
+
+        case UART_LSR: /* RO */
+        case UART_MSR: /* RO */
+        default:
+            rc = -EINVAL;
+            break;
+        }
+
+        ns16550_irq_check(vdev);
+    }
+
+    return rc;
+}
+
+/*
+ * Emulate 16-bit write access to NS16550 register.
+ * NB: some guest OSes use outw() to access UART_DLL.
+ */
+static int ns16550_io_write16(
+    struct vuart_ns16550 *vdev, uint32_t reg, uint16_t *data)
+{
+    uint16_t val = *data;
+    int rc;
+
+    if ( ns16550_dlab_get(vdev) && reg == UART_DLL )
+    {
+        vdev->regs[NS16550_REGS_NUM + UART_DLL] = val & 0xFF;
+        vdev->regs[NS16550_REGS_NUM + UART_DLM] = (val >> 8) & 0xFF;
+        rc = 0;
+    }
+    else
+        rc = -EINVAL;
+
+    return rc;
+}
+
+/*
+ * Emulate write access to NS16550 register.
+ */
+static int ns16550_io_write(
+    struct vuart_ns16550 *vdev, uint8_t reg, uint32_t size, uint32_t *data)
+{
+    int rc;
+
+    switch ( size )
+    {
+    case 1:
+        rc = ns16550_io_write8(vdev, reg, (uint8_t *)data);
+        break;
+
+    case 2:
+        rc = ns16550_io_write16(vdev, reg, (uint16_t *)data);
+        break;
+
+    default:
+        rc = -EINVAL;
+        break;
+    }
+
+    return rc;
+}
+
+/*
+ * Emulate 8-bit read access to NS16550 register.
+ */
+static int ns16550_io_read8(
+    struct vuart_ns16550 *vdev, uint32_t reg, uint8_t *data)
+{
+    uint8_t *regs = vdev->regs;
+    uint8_t val = 0xFFU;
+    int rc = 0;
+
+    if ( ns16550_dlab_get(vdev) && (reg == UART_DLL || reg == UART_DLM) )
+        val = regs[NS16550_REGS_NUM + reg];
+    else {
+        switch ( reg )
+        {
+        case UART_RBR:
+            /* NB: do not forget to clear overrun condition */
+            regs[UART_LSR] &= ~UART_LSR_OE;
+
+            rc = ns16550_fifo_rx_getchar(vdev);
+            if ( rc >= 0 )
+                val = (uint8_t)rc;
+
+            break;
+
+        case UART_IER:
+            val = regs[UART_IER];
+            break;
+
+        case UART_IIR: /* RO */
+            val = ns16550_iir_get(vdev);
+
+            /* NB: clear IIR scratch location */
+            if ( val & UART_IIR_THR )
+                regs[NS16550_REGS_NUM + UART_IIR] &= ~UART_IIR_THR;
+
+            break;
+
+        case UART_LCR:
+            val = regs[UART_LCR];
+            break;
+
+        case UART_MCR:
+            val = regs[UART_MCR];
+            break;
+
+        case UART_LSR:
+            val = regs[UART_LSR] | UART_LSR_THRE | UART_LSR_TEMT;
+            if ( ns16550_fifo_rx_empty(vdev) )
+                val &= ~UART_LSR_DR;
+            else
+                val |= UART_LSR_DR;
+
+            regs[UART_LSR] = val & ~UART_LSR_MASK;
+
+            break;
+
+        case UART_MSR:
+            val = regs[UART_MSR];
+            regs[UART_MSR] &= ~UART_MSR_CHANGE;
+            break;
+
+        case UART_SCR:
+            val = regs[UART_SCR];
+            break;
+
+        default:
+            rc = -EINVAL;
+            break;
+        }
+
+        ns16550_irq_check(vdev);
+    }
+
+    *data = val;
+
+    return rc;
+}
+
+/*
+ * Emulate 16-bit read access to NS16550 register.
+ */
+static int ns16550_io_read16(
+    struct vuart_ns16550 *vdev, uint32_t reg, uint16_t *data)
+{
+    uint16_t val = 0xFFFFU;
+    int rc = -EINVAL;
+
+    if ( ns16550_dlab_get(vdev) && reg == UART_DLL )
+    {
+        val = vdev->regs[NS16550_REGS_NUM + UART_DLM] << 8 |
+              vdev->regs[NS16550_REGS_NUM + UART_DLL];
+        rc = 0;
+    }
+
+    *data = val;
+
+    return rc;
+}
+
+/*
+ * Emulate read access to NS16550 register.
+ */
+static int ns16550_io_read(
+    struct vuart_ns16550 *vdev, uint8_t reg, uint32_t size, uint32_t *data)
+{
+    int rc;
+
+    switch ( size )
+    {
+    case 1:
+        rc = ns16550_io_read8(vdev, reg, (uint8_t *)data);
+        break;
+
+    case 2:
+        rc = ns16550_io_read16(vdev, reg, (uint16_t *)data);
+        break;
+
+    default:
+        *data = 0xFFFFFFFFU;
+        rc = -EINVAL;
+        break;
+    }
+
+    return rc;
+}
+
+static void cf_check ns16550_dump(struct domain *d)
+{
+    struct vuart_ns16550 *vdev = d->arch.hvm.vuart;
+    const struct xencons_interface *cons;
+    const uint8_t *regs;
+
+    if ( !vdev )
+        return;
+
+    /* Allow printing state in case of a deadlock. */
+    if ( !spin_trylock(&vdev->lock) )
+        return;
+
+    cons = &vdev->cons;
+    regs = &vdev->regs[0];
+
+    printk("Virtual " pr_prefix " (%s) I/O port 0x%04"PRIx64" IRQ#%d owner %pd\n",
+            vdev->name, vdev->io_addr, vdev->irq, vdev->owner);
+
+    printk("  RX FIFO size %ld in_prod %d in_cons %d used %d\n",
+            ARRAY_SIZE(cons->in), cons->in_prod, cons->in_cons,
+            cons->in_prod - cons->in_cons);
+
+    printk("  TX FIFO size %ld out_prod %d out_cons %d used %d\n",
+            ARRAY_SIZE(cons->out), cons->out_prod, cons->out_cons,
+            cons->out_prod - cons->out_cons);
+
+    printk("  %02"PRIx8" RBR %02"PRIx8" THR %02"PRIx8" DLL %02"PRIx8" DLM %02"PRIx8"\n",
+            UART_RBR,
+            cons->in[MASK_XENCONS_IDX(cons->in_prod, cons)],
+            cons->out[MASK_XENCONS_IDX(cons->out_prod, cons)],
+            regs[NS16550_REGS_NUM + UART_DLL],
+            regs[NS16550_REGS_NUM + UART_DLM]);
+
+    printk("  %02"PRIx8" IER %02"PRIx8"\n", UART_IER, regs[UART_IER]);
+
+    printk("  %02"PRIx8" FCR %02"PRIx8" IIR %02"PRIx8"\n",
+            UART_FCR, regs[UART_FCR], ns16550_iir_get(vdev));
+
+    printk("  %02"PRIx8" LCR %02"PRIx8"\n", UART_LCR, regs[UART_LCR]);
+    printk("  %02"PRIx8" MCR %02"PRIx8"\n", UART_MCR, regs[UART_MCR]);
+    printk("  %02"PRIx8" LSR %02"PRIx8"\n", UART_LSR, regs[UART_LSR]);
+    printk("  %02"PRIx8" MSR %02"PRIx8"\n", UART_MSR, regs[UART_MSR]);
+    printk("  %02"PRIx8" SCR %02"PRIx8"\n", UART_SCR, regs[UART_SCR]);
+
+    spin_unlock(&vdev->lock);
+}
+
+/*
+ * Emulate I/O access to NS16550 register.
+ * Note, emulation always returns X86EMUL_OKAY, once I/O port trap is enabled.
+ */
+static int cf_check ns16550_io_handle(
+    int dir, unsigned int addr, unsigned int size, uint32_t *data)
+{
+#define op(dir)     (((dir) == IOREQ_WRITE) ? 'W' : 'R')
+    struct domain *d = rcu_lock_current_domain();
+    struct vuart_ns16550 *vdev = d->arch.hvm.vuart;
+    uint32_t reg;
+    unsigned dlab;
+    int rc;
+
+    if ( !vdev )
+    {
+        pr_err("%s: %c io 0x%04x %d: not initialized\n",
+                vdev->name, op(dir), addr, size);
+
+        ASSERT_UNREACHABLE();
+        goto out;
+    }
+
+    if ( d != vdev->owner )
+    {
+        pr_err("%s: %c io 0x%04x %d: does not match current domain %pv\n",
+                vdev->name, op(dir), addr, size, d);
+
+        ASSERT_UNREACHABLE();
+        goto out;
+    }
+
+    reg = addr - vdev->io_addr;
+    if ( !IS_ALIGNED(reg, size) )
+    {
+        pr_err("%s: %c 0x%04x %d: unaligned access\n",
+                vdev->name, op(dir), addr, size);
+        goto out;
+    }
+
+    dlab = ns16550_dlab_get(vdev);
+    if ( reg >= NS16550_REGS_NUM )
+    {
+        pr_err("%s: %c io 0x%04x %d: DLAB=%d %02"PRIx32" 0x%08"PRIx32": not implemented\n",
+                vdev->name, op(dir), addr, size,
+                dlab, reg, *data);
+        goto out;
+    }
+
+    spin_lock(&vdev->lock);
+
+    if ( dir == IOREQ_WRITE )
+    {
+        pr_debug("%s: %c 0x%04x %d: DLAB=%d %02"PRIx32" 0x%08"PRIx32"\n",
+                 vdev->name, op(dir), addr, size,
+                 dlab, reg, *data);
+        rc = ns16550_io_write(vdev, reg, size, data);
+    }
+    else
+    {
+        rc = ns16550_io_read(vdev, reg, size, data);
+        pr_debug("%s: %c 0x%04x %d: DLAB=%d %02"PRIx32" 0x%08"PRIx32"\n",
+                 vdev->name, op(dir), addr, size,
+                 dlab, reg, *data);
+    }
+    if ( rc < 0 )
+        pr_err("%s: %c 0x%04x %d: DLAB=%d %02"PRIx32" x%08"PRIx32": unsupported access\n",
+               vdev->name, op(dir), addr, size,
+               dlab, reg, *data);
+
+    spin_unlock(&vdev->lock);
+#ifdef CONFIG_VUART_NS16550_DEBUG
+    ns16550_dump(d);
+#endif
+
+out:
+    rcu_unlock_domain(d);
+
+    return X86EMUL_OKAY;
+#undef op
+}
+
+static int cf_check ns16550_init(struct domain *d,
+                                struct virtdev_uart_params *params)
+{
+    const struct virtdev_desc *desc = &x86_pc_uarts[X86_PC_UART_IDX];
+    const struct resource *r = desc->res;
+    const uint16_t divisor = (UART_CLOCK_HZ / 115200) >> 4;
+    struct vuart_ns16550 *vdev;
+
+    BUG_ON(d->arch.hvm.vuart);
+
+    vdev = xvzalloc(typeof(*vdev));
+    if ( !vdev )
+        return -ENOMEM;
+
+    for_each_resource(r)
+    {
+        if ( r->type & IORESOURCE_IO )
+        {
+            register_portio_handler(d, r->addr, r->size, ns16550_io_handle);
+
+            /* Used to assert I/O port handler */
+            vdev->io_addr = r->addr;
+            vdev->io_size = r->size;
+        }
+        else if ( r->type & IORESOURCE_IRQ )
+            /* "Claim" virtual IRQ; assumes no ISA-device IRQ sharing */
+            vdev->irq = r->addr;
+        else
+            ASSERT_UNREACHABLE();
+    }
+
+    vdev->owner = d;
+    vdev->name = desc->name;
+
+    /* NB: report 115200 baud rate */
+    vdev->regs[NS16550_REGS_NUM + UART_DLL] = divisor & 0xFFU;
+    vdev->regs[NS16550_REGS_NUM + UART_DLM] = (divisor >> 8) & 0xFFU;
+
+    spin_lock_init(&vdev->lock);
+    hvm_isa_irq_deassert(vdev->owner, vdev->irq);
+
+    d->arch.hvm.vuart = vdev;
+
+    return 0;
+}
+
+static void cf_check ns16550_exit(struct domain *d)
+{
+    struct vuart_ns16550 *vdev = d->arch.hvm.vuart;
+
+    if ( vdev )
+    {
+        spin_lock(&vdev->lock);
+        ns16550_fifo_tx_flush(vdev);
+        spin_unlock(&vdev->lock);
+    }
+
+    XFREE(d->arch.hvm.vuart);
+}
+
+static int cf_check ns16550_putchar(struct domain *d, char ch)
+{
+    struct vuart_ns16550 *vdev = d->arch.hvm.vuart;
+    uint8_t *regs;
+    uint8_t dlab;
+    int rc;
+
+    ASSERT(d == vdev->owner);
+    if ( !vdev )
+        return -ENODEV;
+
+    spin_lock(&vdev->lock);
+
+    dlab = ns16550_dlab_get(vdev);
+    regs = vdev->regs;
+
+    if ( dlab )
+    {
+        pr_debug("%s: THR/RBR access disabled: DLAB=1\n", vdev->name);
+        rc = -EBUSY;
+    }
+    else if ( regs[UART_MCR] & UART_MCR_LOOP )
+    {
+        pr_debug("%s: THR/RBR access disabled: loopback mode\n", vdev->name);
+        rc = -EBUSY;
+    }
+    else
+    {
+        uint8_t val = 0;
+
+        rc = ns16550_fifo_rx_putchar(vdev, ch);
+        if ( rc == -ENOSPC )
+            val |= UART_LSR_OE;
+
+        /* NB: UART_LSR_DR is also set when UART_LSR is accessed. */
+        regs[UART_LSR] |= UART_LSR_DR | val;
+
+        /*
+         * Echo the user input on Xen console.
+         * NB: use 'console_timestamps=none' to disable Xen timestamps.
+         */
+        printk("%c", ch);
+
+        /* FIXME: check FCR when to fire an interrupt */
+        ns16550_irq_check(vdev);
+    }
+
+    spin_unlock(&vdev->lock);
+#ifdef CONFIG_VUART_NS16550_DEBUG
+    ns16550_dump(d);
+#endif
+
+    return rc;
+}
+
+VIRTDEV_UART_REGISTER(ns16550);
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/x86/include/asm/hvm/domain.h b/xen/arch/x86/include/asm/hvm/domain.h
index 333501d5f2ac01676646b9b277b551f06d43c3a5..61f3c5ceec3b6753db657ce0027e89472dc52e1e 100644
--- a/xen/arch/x86/include/asm/hvm/domain.h
+++ b/xen/arch/x86/include/asm/hvm/domain.h
@@ -149,6 +149,10 @@ struct hvm_domain {
 #ifdef CONFIG_MEM_SHARING
     struct mem_sharing_domain mem_sharing;
 #endif
+
+#ifdef CONFIG_HAS_VUART
+    void *vuart; /* Virtual UART handle. */
+#endif
 };
 
 #endif /* __ASM_X86_HVM_DOMAIN_H__ */
diff --git a/xen/drivers/virtdev-uart.c b/xen/drivers/virtdev-uart.c
index fe119e3e6e938957613b182cbef0a29bf67230d2..7011f7b5afa26ac93a71249a3b700eb9a385cccf 100644
--- a/xen/drivers/virtdev-uart.c
+++ b/xen/drivers/virtdev-uart.c
@@ -12,6 +12,9 @@ int virtdev_uart_init(struct domain *d, struct virtdev_uart_params *params)
     int rc;
 
     ASSERT(__start_virtdev_uart);
+#if defined(__i386__) || defined(__x86_64__)
+    ASSERT(d->arch.emulation_flags & VIRTDEV_UART);
+#endif
 
     rc = __start_virtdev_uart->init(d, params);
     if ( rc )
@@ -28,6 +31,9 @@ int virtdev_uart_init(struct domain *d, struct virtdev_uart_params *params)
 void virtdev_uart_exit(struct domain *d)
 {
     ASSERT(__start_virtdev_uart);
+#if defined(__i386__) || defined(__x86_64__)
+    ASSERT(d->arch.emulation_flags & VIRTDEV_UART);
+#endif
 
     __start_virtdev_uart->exit(d);
 
diff --git a/xen/include/xen/resource.h b/xen/include/xen/resource.h
index 4512658133defe8dc62d87192ffd19ad94b63c3b..bdd9df4ded632082c8db929787455bc1aea96e9f 100644
--- a/xen/include/xen/resource.h
+++ b/xen/include/xen/resource.h
@@ -31,4 +31,7 @@ struct resource {
 
 #define resource_size(res)      ( (res)->size )
 
+#define for_each_resource(res) \
+    for ( ; (res) && (res)->type != IORESOURCE_UNKNOWN; (res)++ )
+
 #endif /* XEN__RESOURCE_H */

-- 
2.34.1




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 02:00:33 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 02:00:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864803.1276123 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtSq-0008Lw-Qa; Sat, 04 Jan 2025 02:00:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864803.1276123; Sat, 04 Jan 2025 02:00:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtSq-0008Kq-Mo; Sat, 04 Jan 2025 02:00:32 +0000
Received: by outflank-mailman (input) for mailman id 864803;
 Sat, 04 Jan 2025 02:00:31 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=AhC6=T4=kernel.org=devnull+dmukhin.ford.com@srs-se1.protection.inumbo.net>)
 id 1tTtQq-0005Ax-Rr
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 01:58:28 +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 5ecc83d6-ca3f-11ef-a0de-8be0dac302b0;
 Sat, 04 Jan 2025 02:58:19 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id EF89D5C63FD;
 Sat,  4 Jan 2025 01:57:34 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPS id 10C16C4CEDF;
 Sat,  4 Jan 2025 01:58:16 +0000 (UTC)
Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org
 (localhost.localdomain [127.0.0.1])
 by smtp.lore.kernel.org (Postfix) with ESMTP id 0A1DEE77198;
 Sat,  4 Jan 2025 01:58:16 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5ecc83d6-ca3f-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1735955896;
	bh=QazlpyV6psPVJxq90As+1tifoHdIpFVbG/2MHr8OLBw=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From;
	b=rrUY+R9cOymfLlpHjaW/5WWuCxfD+kpXYC19m42ZvsRMQZ2tbFy+4fYSjh5nSqOnF
	 MDzhLmOF4r2vJ7RDUNmGK6VtIPT/hg4KdPr88fIMBe856PpMni/SavUUC54S3nkJBs
	 97FS/wNUVRx2tgQ1vGcEYa94L/MBlToRq/UBPie/kp0o1+MbhbziOfNzyw/ZGh1nbt
	 JOYbyxh1Nd4J0vJdOyqnbN4DXALfEvFVeNk5zmBuE1GQ78H1amMI58APMUcbsvA9i3
	 L3BTJnHJ51Kt69qXsCFuWptoqB+r5EH9bPDjgq+9kesmPxxoW1k1JLeYnILzGBHpNH
	 msPk4KNQTq6Yw==
From: Denis Mukhin via B4 Relay <devnull+dmukhin.ford.com@kernel.org>
Date: Fri, 03 Jan 2025 17:58:28 -0800
Subject: [PATCH v3 22/24] x86/hvm: enable NS16550-compatible UART emulator
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20250103-vuart-ns8250-v3-v1-22-c5d36b31d66c@ford.com>
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
In-Reply-To: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>, 
 Julien Grall <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, Jan Beulich <jbeulich@suse.com>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
 Denis Mukhin <dmukhin@ford.com>
X-Mailer: b4 0.14.2
X-Developer-Signature: v=1; a=ed25519-sha256; t=1735955892; l=5808;
 i=dmukhin@ford.com; s=20241125; h=from:subject:message-id;
 bh=oTdotR5rgkOxF28AQvVxnepnVm1tE7cePzIJQgwAwTE=;
 b=++NBrOXcXTVJ8AvbN0dFDKCaPX+KTiZWc6kqg1YW8cHeVU5lsUi46ifTL7rphNL0TvW1CYQXH
 XrobXLlc2ALALwgiWl1M0BltoYkrxIKgEelLgp8WFdBQIdlCQDKzw1V
X-Developer-Key: i=dmukhin@ford.com; a=ed25519;
 pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U=
X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with
 auth_id=287
X-Original-From: Denis Mukhin <dmukhin@ford.com>
Reply-To: dmukhin@ford.com

From: Denis Mukhin <dmukhin@ford.com>

Introduce new emulation flag for virtual UART on x86 and plumb it through
domain creation code so NS16550 emulator is enabled properly.

Virtual UART facility is enabled for HVM domains only. Enabling it for PVH
domains requires some work, as vPIC is not enabled in PVH.

Also, since feature is currently for debugging only, vUART facility is
controlled build-time only and globally for all HVM domains.

The toolstack cannot configure virtual UART yet.

Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
In PVH case, vUART asserts on vpic_irq_positive_edge() call while firing a
virtual IRQ to the guest OS:
[[
...
Assertion 'has_vpic(d)' failed at arch/x86/hvm/vpic.c:525
(XEN) [   28.984923] ----[ Xen-4.20-unstable  x86_64  debug=y  Not tainted ]----
(XEN) [   28.984925] CPU:    3
(XEN) [   28.984926] RIP:    e008:[<ffff82d0402d201a>] vpic_irq_positive_edge+0x98/0xc0
...
]]
---
---
 tools/ocaml/libs/xc/xenctrl.ml    |  1 +
 tools/ocaml/libs/xc/xenctrl.mli   |  1 +
 xen/arch/x86/domain.c             | 10 ++++++++++
 xen/arch/x86/include/asm/domain.h |  5 +++--
 xen/include/public/virtdev.h      |  6 ++++--
 5 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl.ml
index 2690f9a92316b812ad3d3ff0e1c36823070adb4a..647239b3e55e88b00eb8e9773a5267894cbbae54 100644
--- a/tools/ocaml/libs/xc/xenctrl.ml
+++ b/tools/ocaml/libs/xc/xenctrl.ml
@@ -47,6 +47,7 @@ type x86_arch_emulation_flags =
   | X86_EMU_PIT
   | X86_EMU_USE_PIRQ
   | X86_EMU_VPCI
+  | X86_EMU_VUART
 
 type x86_arch_misc_flags =
   | X86_MSR_RELAXED
diff --git a/tools/ocaml/libs/xc/xenctrl.mli b/tools/ocaml/libs/xc/xenctrl.mli
index febbe1f6ae3f10c5abe45eaa3c06a8a67d9ba268..4f5f64c786e83e8a0c3dd3cdb0460f7095de4a62 100644
--- a/tools/ocaml/libs/xc/xenctrl.mli
+++ b/tools/ocaml/libs/xc/xenctrl.mli
@@ -41,6 +41,7 @@ type x86_arch_emulation_flags =
   | X86_EMU_PIT
   | X86_EMU_USE_PIRQ
   | X86_EMU_VPCI
+  | X86_EMU_VUART
 
 type x86_arch_misc_flags =
   | X86_MSR_RELAXED
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 9669886ac95cbee27c9eb72b16386705b470e7b1..c1b15ddf664269ba63d0bcd8a974491a4ab3524f 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -752,6 +752,10 @@ static bool emulation_flags_ok(const struct domain *d, uint32_t emflags)
         if ( is_hardware_domain(d) &&
              emflags != (X86_EMU_VPCI | X86_EMU_LAPIC | X86_EMU_IOAPIC) )
             return false;
+
+        /* FIXME: remove once virtual UART is configurable via xl */
+        emflags &= ~XEN_X86_EMU_VUART;
+
         if ( !is_hardware_domain(d) &&
              xen_emflags_allowable(emflags) != XEN_X86_EMU_BASELINE &&
              emflags != X86_EMU_LAPIC )
@@ -804,6 +808,12 @@ int arch_domain_create(struct domain *d,
 
     emflags = config->arch.emulation_flags;
 
+    /* FIXME: enable virtual UART for all HVMs; must be configurable via xl */
+    if ( IS_ENABLED(CONFIG_HAS_VUART) && is_hvm_domain(d) )
+        emflags |= XEN_X86_EMU_VUART;
+    else
+        emflags &= ~XEN_X86_EMU_VUART;
+
     if ( is_hardware_domain(d) && is_pv_domain(d) )
         emflags |= XEN_X86_EMU_PIT;
 
diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h
index 2532616bca015d0aad9abc35e14948937ab39b8f..53d14881d94f888e72f7443159c1c278d15d05cb 100644
--- a/xen/arch/x86/include/asm/domain.h
+++ b/xen/arch/x86/include/asm/domain.h
@@ -485,7 +485,8 @@ struct arch_domain
 #define X86_EMU_VPCI     0
 #endif
 
-#define X86_EMU_PIT     XEN_X86_EMU_PIT
+#define X86_EMU_PIT      XEN_X86_EMU_PIT
+#define X86_EMU_VUART    XEN_X86_EMU_VUART
 
 /* This must match XEN_X86_EMU_ALL in xen.h */
 #define X86_EMU_ALL             (X86_EMU_LAPIC | X86_EMU_HPET |         \
@@ -493,7 +494,7 @@ struct arch_domain
                                  X86_EMU_IOAPIC | X86_EMU_PIC |         \
                                  X86_EMU_VGA | X86_EMU_IOMMU |          \
                                  X86_EMU_PIT | X86_EMU_USE_PIRQ |       \
-                                 X86_EMU_VPCI)
+                                 X86_EMU_VPCI | X86_EMU_VUART)
 
 #define has_vlapic(d)      (!!((d)->arch.emulation_flags & X86_EMU_LAPIC))
 #define has_vhpet(d)       (!!((d)->arch.emulation_flags & X86_EMU_HPET))
diff --git a/xen/include/public/virtdev.h b/xen/include/public/virtdev.h
index 36931e0d679cedadd4212f34142d7c3f00cd3389..bcc71b519310e58d6094fadded14a3e0ee6bfd7e 100644
--- a/xen/include/public/virtdev.h
+++ b/xen/include/public/virtdev.h
@@ -32,17 +32,19 @@ enum {
 #define XEN_X86_EMU_PIT             VIRTDEV_PIT
 #define XEN_X86_EMU_USE_PIRQ        VIRTDEV_PIRQ
 #define XEN_X86_EMU_VPCI            VIRTDEV_PCI
+#define XEN_X86_EMU_VUART           VIRTDEV_UART
 
 #define XEN_X86_EMU_ALL             (XEN_X86_EMU_LAPIC | XEN_X86_EMU_HPET |  \
                                      XEN_X86_EMU_PM | XEN_X86_EMU_RTC |      \
                                      XEN_X86_EMU_IOAPIC | XEN_X86_EMU_PIC |  \
                                      XEN_X86_EMU_VGA | XEN_X86_EMU_IOMMU |   \
                                      XEN_X86_EMU_PIT | XEN_X86_EMU_USE_PIRQ |\
-                                     XEN_X86_EMU_VPCI)
+                                     XEN_X86_EMU_VPCI | XEN_X86_EMU_VUART)
 
 /* PIRQ (HVM) feature is user-selectable (libxl). */
 #define XEN_X86_EMU_OPTIONAL        (XEN_X86_EMU_VPCI | \
-                                     XEN_X86_EMU_USE_PIRQ)
+                                     XEN_X86_EMU_USE_PIRQ | \
+                                     XEN_X86_EMU_VUART)
 
 #define XEN_X86_EMU_BASELINE        xen_emflags_allowable(XEN_X86_EMU_ALL)
 

-- 
2.34.1




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 02:00:33 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 02:00:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864798.1276119 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtSq-0008J0-JS; Sat, 04 Jan 2025 02:00:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864798.1276119; Sat, 04 Jan 2025 02:00:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtSq-0008Io-FX; Sat, 04 Jan 2025 02:00:32 +0000
Received: by outflank-mailman (input) for mailman id 864798;
 Sat, 04 Jan 2025 02:00:30 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=AhC6=T4=kernel.org=devnull+dmukhin.ford.com@srs-se1.protection.inumbo.net>)
 id 1tTtQp-0005Ax-Rb
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 01:58:27 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org
 [2604:1380:4641:c500::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5e44909b-ca3f-11ef-a0de-8be0dac302b0;
 Sat, 04 Jan 2025 02:58:19 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 9AA415C6371;
 Sat,  4 Jan 2025 01:57:34 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPS id AEADEC4CEE5;
 Sat,  4 Jan 2025 01:58:15 +0000 (UTC)
Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org
 (localhost.localdomain [127.0.0.1])
 by smtp.lore.kernel.org (Postfix) with ESMTP id A7971E77188;
 Sat,  4 Jan 2025 01:58:15 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5e44909b-ca3f-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1735955895;
	bh=tKaGED9IpwVKbHVz8RwtOyv0k9Wjw6x6RHqz6c7KSyQ=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From;
	b=B52T+kAO6qLDz7zq6gWE1B2qhOvFcxghKxzXb/+ZETwqeaoLAnm2fy1psS4c7gWup
	 SMYJuQfE5ali3eGp8ZbC9qzE0n48Jk3JMvFWEEy3ERpR6Hy1htQFqAHGQLm1+JzblA
	 0yZvgojt2Jb7agXNEAlyiia4KaTSsi4mOcWhv3lktvk/OCpM0HNp6rEXxP3GHP9BR5
	 0XsQEU+BhsCv4uI1USP24C3viwYHPXg+40xZNxmVasK/UI7ZuboNzIk98/cufTs6GB
	 t8PZ+i8iF1yalGYKL1LI2dqOEdr8rP6pqFuS+cOLri5SglU18CmuWpOKCQbtgaCzkV
	 m9cQYK6B4L95g==
From: Denis Mukhin via B4 Relay <devnull+dmukhin.ford.com@kernel.org>
Date: Fri, 03 Jan 2025 17:58:23 -0800
Subject: [PATCH v3 17/24] xen/console: flush console ring to physical
 console
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20250103-vuart-ns8250-v3-v1-17-c5d36b31d66c@ford.com>
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
In-Reply-To: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>, 
 Julien Grall <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, Jan Beulich <jbeulich@suse.com>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
 Denis Mukhin <dmukhin@ford.com>
X-Mailer: b4 0.14.2
X-Developer-Signature: v=1; a=ed25519-sha256; t=1735955892; l=3242;
 i=dmukhin@ford.com; s=20241125; h=from:subject:message-id;
 bh=HNsOcWLWQbY0cAiixdwe0nN3gebiJS/e1uoFMNrsBDM=;
 b=Xv6GoU4z4xrDCRW2Ui109tIiHZ591VBeCDEtWzc4OIBnOqGgb9g8t7eqHfMNJFf2HQfO9eUm7
 +pxGVDJPNseDBbL6hz7cc71DJfD4v3daXwBkgrVfs/J93tGqVYRXDfK
X-Developer-Key: i=dmukhin@ford.com; a=ed25519;
 pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U=
X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with
 auth_id=287
X-Original-From: Denis Mukhin <dmukhin@ford.com>
Reply-To: dmukhin@ford.com

From: Denis Mukhin <dmukhin@ford.com>

Internal console ring is used to hold Xen messages before external consoles
(serial, VGA) consoles are fully initialized.

Ensure all messages are sent to all external consoles after their
initialization is completed.

Link: https://gitlab.com/xen-project/xen/-/issues/184
Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
 xen/drivers/char/console.c | 56 +++++++++++++++++++++++++++++++++-------------
 1 file changed, 41 insertions(+), 15 deletions(-)

diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 2f776b2f07cb15fae8060f3574db73234a38727a..96375067164980a138b1a93161712c0758f4f7fe 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -430,23 +430,36 @@ void console_serial_puts(const char *s, size_t nr)
     pv_console_puts(s, nr);
 }
 
-static void cf_check dump_console_ring_key(unsigned char key)
+/*
+ * Write characters to physical console(s).
+ * That covers:
+ * - serial console;
+ * - video output.
+ */
+static void console_puts(const char *str, size_t len)
+{
+    ASSERT(rspin_is_locked(&console_lock));
+
+    console_serial_puts(str, len);
+    video_puts(str, len);
+}
+
+/*
+ * Flush contents of the conring to the physical console devices.
+ */
+static int console_flush(void)
 {
     uint32_t idx, len, sofar, c;
     unsigned int order;
     char *buf;
 
-    printk("'%c' pressed -> dumping console ring buffer (dmesg)\n", key);
-
-    /* create a buffer in which we'll copy the ring in the correct
-       order and NUL terminate */
     order = get_order_from_bytes(conring_size + 1);
     buf = alloc_xenheap_pages(order, 0);
     if ( buf == NULL )
-    {
-        printk("unable to allocate memory!\n");
-        return;
-    }
+        return -ENOMEM;
+
+
+    nrspin_lock(&console_lock);
 
     c = conringc;
     sofar = 0;
@@ -461,10 +474,23 @@ static void cf_check dump_console_ring_key(unsigned char key)
         c += len;
     }
 
-    console_serial_puts(buf, sofar);
-    video_puts(buf, sofar);
+    console_puts(buf, sofar);
+
+    nrspin_unlock(&console_lock);
 
     free_xenheap_pages(buf, order);
+
+    return 0;
+}
+
+static void cf_check dump_console_ring_key(unsigned char key)
+{
+    int rc;
+
+    printk("'%c' pressed -> dumping console ring buffer (dmesg)\n", key);
+    rc = console_flush();
+    if ( rc )
+        printk("failed to dump console ring buffer: %d\n", rc);
 }
 
 /*
@@ -681,10 +707,7 @@ static void xen_console_write(const char *str, size_t len)
  */
 static void console_write(const char *str, size_t len, unsigned int flags)
 {
-    ASSERT(rspin_is_locked(&console_lock));
-
-    console_serial_puts(str, len);
-    video_puts(str, len);
+    console_puts(str, len);
 
 #ifdef CONFIG_X86
     if ( opt_console_xen )
@@ -1061,6 +1084,9 @@ void __init console_init_preirq(void)
     serial_set_rx_handler(sercon_handle, serial_rx);
     pv_console_set_rx_handler(serial_rx);
 
+    /* NB: send conring contents to all enabled physical consoles, if any */
+    console_flush();
+
     /* HELLO WORLD --- start-of-day banner text. */
     nrspin_lock(&console_lock);
     __putstr(xen_banner());

-- 
2.34.1




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 02:00:51 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 02:00:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864838.1276139 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtT9-0001Xg-7S; Sat, 04 Jan 2025 02:00:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864838.1276139; Sat, 04 Jan 2025 02:00:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtT9-0001WW-1R; Sat, 04 Jan 2025 02:00:51 +0000
Received: by outflank-mailman (input) for mailman id 864838;
 Sat, 04 Jan 2025 02:00:49 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=AhC6=T4=kernel.org=devnull+dmukhin.ford.com@srs-se1.protection.inumbo.net>)
 id 1tTtQs-0005Ax-Sa
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 01:58:30 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org
 [2604:1380:4641:c500::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5e44473d-ca3f-11ef-a0de-8be0dac302b0;
 Sat, 04 Jan 2025 02:58:19 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 770E95C62A5;
 Sat,  4 Jan 2025 01:57:34 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPS id 8C669C4CEE4;
 Sat,  4 Jan 2025 01:58:15 +0000 (UTC)
Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org
 (localhost.localdomain [127.0.0.1])
 by smtp.lore.kernel.org (Postfix) with ESMTP id 86F8EE7719A;
 Sat,  4 Jan 2025 01:58:15 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5e44473d-ca3f-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1735955895;
	bh=Xgs2bv4JXXqvUy90eTrxGWRi5qSOMQjEKlvhtNuvWD0=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From;
	b=gKVBWj1Q+WmEWJaWD7QxNZIudKk6SS4SvjEWEBLSsydcYHDXbuq+CkgIWhkKkYsyc
	 7WeIyRELjzVkDHwj15LTI350khFx9qlnLOokWC84cM6HB5z5hVOChWSsnWQW6Ji1Ir
	 omJTU6H1Egx9q8641wHVq8dtX6X3z/bqXX8gIPZ73a+bt0DlaDUYL99K+0zTNG8WF8
	 ZZ/YumZ5NXWnlnJMUIpNiPmFSAjZY35bI0zSNc1CgLXSUhXUYfgPAhsolJSqtsg4w/
	 gep+XQ6Eqs4vcfxNMlaCHFenrwxgjOfTQ6Aho0t3aG/hbiBIl5c7+f6DJClIUBcNXW
	 4pthH1KzgUtEg==
From: Denis Mukhin via B4 Relay <devnull+dmukhin.ford.com@kernel.org>
Date: Fri, 03 Jan 2025 17:58:21 -0800
Subject: [PATCH v3 15/24] xen/console: make console buffer size
 configurable
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20250103-vuart-ns8250-v3-v1-15-c5d36b31d66c@ford.com>
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
In-Reply-To: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>, 
 Julien Grall <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, Jan Beulich <jbeulich@suse.com>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
 Denis Mukhin <dmukhin@ford.com>
X-Mailer: b4 0.14.2
X-Developer-Signature: v=1; a=ed25519-sha256; t=1735955892; l=3361;
 i=dmukhin@ford.com; s=20241125; h=from:subject:message-id;
 bh=Q9U/5BpyrJDws6KsGm2DI3/vHtnpVBTCL+jo+AixI4I=;
 b=hMkW/p8d9e8YlW1EjCatE/+J+TNOaD3M7w+4q9v/uuzLx8LRbhrHqNYhHbNPSDhfpAOt9c3kG
 jcKW3DW1vu0Cbj1R7uk77E9E7hi4M5hw7d3a21DBA5Atm3hRvg/QUs8
X-Developer-Key: i=dmukhin@ford.com; a=ed25519;
 pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U=
X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with
 auth_id=287
X-Original-From: Denis Mukhin <dmukhin@ford.com>
Reply-To: dmukhin@ford.com

From: Denis Mukhin <dmukhin@ford.com>

Add new CONRING_SIZE Kconfig parameter to specify the boot console buffer size
in bytes. The value is rounded to the nearest power of 2 to match existing
conring_size= behavior.

The supported range is [16KiB..128MiB].

Bump default size to 32 KiB.

Link: https://gitlab.com/xen-project/xen/-/issues/185
Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
 docs/misc/xen-command-line.pandoc |  7 +++++--
 xen/drivers/char/Kconfig          | 11 +++++++++++
 xen/drivers/char/console.c        |  9 ++++++---
 3 files changed, 22 insertions(+), 5 deletions(-)

diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index 1a5ee3c91c5cc8bf653e5054211035b5d1bd560f..aeaee482f61aab41438a44eda470902e1e0806f8 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -423,12 +423,15 @@ The following are examples of correct specifications:
     com1=baud=115200,parity=n,stop-bits=1,io-base=0x3f8,reg-width=4
 
 ### conring_size
-> `= <size>`
+> `= <size-in-bytes>`
 
-> Default: `conring_size=16k`
+> Default: `conring_size=32k`
 
 Specify the size of the console ring buffer.
 
+The console ring buffer size can be selected at build time via
+CONFIG_CONRING_SIZE.
+
 ### console
 > `= List of [ vga | com1[H,L] | com2[H,L] | pv | dbgp | ehci | xhci | none ]`
 
diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index e6e12bb4139717f9319031f51f5d20155d2caee2..f7e193e29e2d9ac7c1b878e13f3fb1ce444f31b5 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -96,6 +96,17 @@ config SERIAL_TX_BUFSIZE
 
 	  Default value is 32768 (32KiB).
 
+config CONRING_SIZE
+	int "Console buffer size"
+	default 32768
+	help
+	  Select the boot console buffer size (in bytes).
+	  Note, the value provided will be rounded down to the nearest power of 2.
+	  Run-time console buffer size is the same as the boot console size,
+	  unless enforced via 'conring_size=' boot parameter.
+
+	  Default value is 32768 (32KiB). The supported range is [16KiB..128MiB].
+
 config XHCI
 	bool "XHCI DbC UART driver"
 	depends on X86
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 1308236403df8a0f87aeb7e2c00a036c2d8433a7..a33132b8fad95a1ad7e0aab4aef3fa3e46a5c03a 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -100,12 +100,15 @@ static int cf_check parse_console_timestamps(const char *s);
 custom_runtime_param("console_timestamps", parse_console_timestamps,
                      con_timestamp_mode_upd);
 
-/* conring_size: allows a large console ring than default (16kB). */
+/* conring_size: allows a large console ring than default (32 KiB). */
 static uint32_t __initdata opt_conring_size;
 size_param("conring_size", opt_conring_size);
 
-#define _CONRING_SIZE 16384
-#define CONRING_IDX_MASK(i) ((i)&(conring_size-1))
+#define _CONRING_SIZE       (1UL << (31 - __builtin_clz(CONFIG_CONRING_SIZE)))
+_Static_assert(_CONRING_SIZE >= 4096 && _CONRING_SIZE <= MB(128),
+    "CONFIG_CONRING_SIZE must be in [4K..128M] range");
+
+#define CONRING_IDX_MASK(i) ( (i) & (conring_size - 1) )
 static char __initdata _conring[_CONRING_SIZE];
 static char *__read_mostly conring = _conring;
 static uint32_t __read_mostly conring_size = _CONRING_SIZE;

-- 
2.34.1




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 02:00:52 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 02:00:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864845.1276149 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtTA-0001ts-Er; Sat, 04 Jan 2025 02:00:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864845.1276149; Sat, 04 Jan 2025 02:00:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtTA-0001sW-9q; Sat, 04 Jan 2025 02:00:52 +0000
Received: by outflank-mailman (input) for mailman id 864845;
 Sat, 04 Jan 2025 02:00: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
 <SRS0=AhC6=T4=kernel.org=devnull+dmukhin.ford.com@srs-se1.protection.inumbo.net>)
 id 1tTtQr-0005Ax-SB
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 01:58:29 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org
 [2604:1380:4641:c500::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5e0b4e27-ca3f-11ef-a0de-8be0dac302b0;
 Sat, 04 Jan 2025 02:58:19 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 477C45C61FB;
 Sat,  4 Jan 2025 01:57:34 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPS id 5750FC4CEE7;
 Sat,  4 Jan 2025 01:58:15 +0000 (UTC)
Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org
 (localhost.localdomain [127.0.0.1])
 by smtp.lore.kernel.org (Postfix) with ESMTP id 525B5E7719A;
 Sat,  4 Jan 2025 01:58:15 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5e0b4e27-ca3f-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1735955895;
	bh=0RiCLC0xOzoXE8zM6GuJsL0mR/n/aR+zKy5BKY4AmRI=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From;
	b=Cc+SrVU8OiRGBxa/MQxYepNdpwn1YwuBa8DTaKdhhiesGN00s8ObKq73IJpqjMV+q
	 NqC+aGc0snCvnnlXnutTjAjzUEKx/xSEkpqDlKS3PdI5Sn40BUE4DRTorkB5BJMpv/
	 KzQuWptl2wNWjsOz2vIfRESQUKIt1sf3nXyqyztc8RVwZ0w1tnsa5M4OgY2U1wRiRw
	 wDbCwZPFnD1xla36YaMWcRekbujrSHyQKy6pK8lk//fdBuyki2ScSBciBDH8/uhoXb
	 FzOt7PwJLnG/7uoF1Ssb880YEFHIrYiStrgPDMaeainhDywtTs8EO00YlX1o6akHIh
	 6sjiHFj4lOdJg==
From: Denis Mukhin via B4 Relay <devnull+dmukhin.ford.com@kernel.org>
Date: Fri, 03 Jan 2025 17:58:17 -0800
Subject: [PATCH v3 11/24] xen/domain: move get_initial_domain_id() to
 arch-independent header
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20250103-vuart-ns8250-v3-v1-11-c5d36b31d66c@ford.com>
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
In-Reply-To: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>, 
 Julien Grall <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, Jan Beulich <jbeulich@suse.com>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
 Denis Mukhin <dmukhin@ford.com>
X-Mailer: b4 0.14.2
X-Developer-Signature: v=1; a=ed25519-sha256; t=1735955892; l=10763;
 i=dmukhin@ford.com; s=20241125; h=from:subject:message-id;
 bh=KSx1P0KAHxW1DtHrVs4w4BNN0t0xYk4+xwM0DZycLC0=;
 b=XY8kJ57Z4bAPPueW7p5ElCjXAaQkou+MZAejExcnaHDRFAST3sVyhGy8HHUaFQ/I3HOrYvOr9
 kG+gPZ8+uGPBzexLC9uHJVRrvnzrJyKzRcZMyLj3faeCcwACnOdKPfS
X-Developer-Key: i=dmukhin@ford.com; a=ed25519;
 pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U=
X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with
 auth_id=287
X-Original-From: Denis Mukhin <dmukhin@ford.com>
Reply-To: dmukhin@ford.com

From: Denis Mukhin <dmukhin@ford.com>

Honor 'hardware_domid=' parameter across all architectures and update
max_init_domid correctly so that toolstack and, subsequently, console driver
could iterate across known domains more efficiently.

Also, move max_init_domid to arch-independent location.

Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
 xen/arch/arm/dom0less-build.c      |  6 +++---
 xen/arch/arm/domain_build.c        |  7 ++++---
 xen/arch/arm/include/asm/setup.h   |  2 --
 xen/arch/arm/setup.c               |  2 --
 xen/arch/ppc/include/asm/setup.h   |  2 --
 xen/arch/riscv/include/asm/setup.h |  2 --
 xen/arch/x86/include/asm/pv/shim.h |  5 +++--
 xen/arch/x86/include/asm/setup.h   |  2 --
 xen/arch/x86/pv/shim.c             |  5 +----
 xen/common/domain.c                | 15 +++++++++++++++
 xen/common/domctl.c                | 11 +++++------
 xen/common/kernel.c                |  8 ++++++++
 xen/include/xen/domain.h           |  4 ++++
 13 files changed, 43 insertions(+), 28 deletions(-)

diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index 818e693222059a5e99a44831be62644ac442392b..b0c6c0b5c7762439dc74025333be092687c191e5 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -971,9 +971,9 @@ void __init create_domUs(void)
             panic("'llc-colors' found, but LLC coloring is disabled\n");
 
         /*
-         * The variable max_init_domid is initialized with zero, so here it's
-         * very important to use the pre-increment operator to call
-         * domain_create() with a domid > 0. (domid == 0 is reserved for Dom0)
+         * NB: it's very important to use the pre-increment operator to call
+         * domain_create() with a domid > get_initial_domain_id().
+         * domid == get_initial_domain_id() is reserved for Dom0.
          */
         d = domain_create(++max_init_domid, &d_cfg, flags);
         if ( IS_ERR(d) )
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index b072a16249feaab3eabe214040e4331e208ffae4..5fe2f397c8b1f7088b08c3435bc75a1acb8742b3 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2357,6 +2357,7 @@ void __init create_dom0(void)
         .grant_opts = XEN_DOMCTL_GRANT_version(opt_gnttab_max_version),
     };
     unsigned int flags = CDF_privileged;
+    domid_t domid = get_initial_domain_id();
     int rc;
 
     /* The vGIC for DOM0 is exactly emulating the hardware GIC */
@@ -2387,15 +2388,15 @@ void __init create_dom0(void)
     if ( !llc_coloring_enabled )
         flags |= CDF_directmap;
 
-    dom0 = domain_create(0, &dom0_cfg, flags);
+    dom0 = domain_create(domid, &dom0_cfg, CDF_privileged | CDF_directmap);
     if ( IS_ERR(dom0) )
-        panic("Error creating domain 0 (rc = %ld)\n", PTR_ERR(dom0));
+        panic("Error creating domain %d (rc = %ld)\n", domid, PTR_ERR(dom0));
 
     if ( llc_coloring_enabled && (rc = dom0_set_llc_colors(dom0)) )
         panic("Error initializing LLC coloring for domain 0 (rc = %d)\n", rc);
 
     if ( alloc_dom0_vcpu0(dom0) == NULL )
-        panic("Error creating domain 0 vcpu0\n");
+        panic("Error creating domain %d vcpu0\n", domid);
 
     rc = construct_dom0(dom0);
     if ( rc )
diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
index 6cf272c160ef2443cb50bfa4ae2d2591c52e043d..f107e8eebb4904a4455167e8792a66994a093d86 100644
--- a/xen/arch/arm/include/asm/setup.h
+++ b/xen/arch/arm/include/asm/setup.h
@@ -25,8 +25,6 @@ struct map_range_data
     struct rangeset *irq_ranges;
 };
 
-extern domid_t max_init_domid;
-
 void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
 
 size_t estimate_efi_size(unsigned int mem_nr_banks);
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index c1f2d1b89d4317224bb1011e0db3a7372df807e2..47d80fcd43289ebbd751007f02eab2def60bebad 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -60,8 +60,6 @@ struct cpuinfo_arm __read_mostly system_cpuinfo;
 bool __read_mostly acpi_disabled;
 #endif
 
-domid_t __read_mostly max_init_domid;
-
 static __used void init_done(void)
 {
     int rc;
diff --git a/xen/arch/ppc/include/asm/setup.h b/xen/arch/ppc/include/asm/setup.h
index e4f64879b68ca5aac24bd9544255143e6ef693f3..956fa6985adb23375bd41d3e5d34d9d5f0712bd5 100644
--- a/xen/arch/ppc/include/asm/setup.h
+++ b/xen/arch/ppc/include/asm/setup.h
@@ -1,6 +1,4 @@
 #ifndef __ASM_PPC_SETUP_H__
 #define __ASM_PPC_SETUP_H__
 
-#define max_init_domid (0)
-
 #endif /* __ASM_PPC_SETUP_H__ */
diff --git a/xen/arch/riscv/include/asm/setup.h b/xen/arch/riscv/include/asm/setup.h
index c9d69cdf51666c0ec31196411b52e9b39439ba5f..d1fc64b673ab618d9ad7a78c0a8b32b70a2daae6 100644
--- a/xen/arch/riscv/include/asm/setup.h
+++ b/xen/arch/riscv/include/asm/setup.h
@@ -5,8 +5,6 @@
 
 #include <xen/types.h>
 
-#define max_init_domid (0)
-
 void setup_mm(void);
 
 void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
diff --git a/xen/arch/x86/include/asm/pv/shim.h b/xen/arch/x86/include/asm/pv/shim.h
index 6153e27005986881ad87e9db0b555b30edc59fc0..27053d4f6fb93a619edba2d34d92ea5e5cd27303 100644
--- a/xen/arch/x86/include/asm/pv/shim.h
+++ b/xen/arch/x86/include/asm/pv/shim.h
@@ -31,7 +31,7 @@ long cf_check pv_shim_cpu_up(void *data);
 long cf_check pv_shim_cpu_down(void *data);
 void pv_shim_online_memory(unsigned int nr, unsigned int order);
 void pv_shim_offline_memory(unsigned int nr, unsigned int order);
-domid_t get_initial_domain_id(void);
+domid_t pv_shim_get_initial_domain_id(void);
 uint64_t pv_shim_mem(uint64_t avail);
 void pv_shim_fixup_e820(void);
 const struct platform_bad_page *pv_shim_reserved_pages(unsigned int *size);
@@ -76,8 +76,9 @@ static inline void pv_shim_offline_memory(unsigned int nr, unsigned int order)
 {
     ASSERT_UNREACHABLE();
 }
-static inline domid_t get_initial_domain_id(void)
+static inline domid_t pv_shim_get_initial_domain_id(void)
 {
+    ASSERT_UNREACHABLE();
     return 0;
 }
 static inline uint64_t pv_shim_mem(uint64_t avail)
diff --git a/xen/arch/x86/include/asm/setup.h b/xen/arch/x86/include/asm/setup.h
index 5c2391a8684b66efdf4b092409ed33935db6b40c..296348655b9d146c73acc305cc9edd5fd46f7d47 100644
--- a/xen/arch/x86/include/asm/setup.h
+++ b/xen/arch/x86/include/asm/setup.h
@@ -69,6 +69,4 @@ extern bool opt_dom0_verbose;
 extern bool opt_dom0_cpuid_faulting;
 extern bool opt_dom0_msr_relaxed;
 
-#define max_init_domid (0)
-
 #endif
diff --git a/xen/arch/x86/pv/shim.c b/xen/arch/x86/pv/shim.c
index 9eb120258aeaf7068eae88d1e7d1b95ea7a00f31..8435f347ce31aed49309e942f9692a2307bcd93f 100644
--- a/xen/arch/x86/pv/shim.c
+++ b/xen/arch/x86/pv/shim.c
@@ -1018,13 +1018,10 @@ void pv_shim_offline_memory(unsigned int nr, unsigned int order)
     }
 }
 
-domid_t get_initial_domain_id(void)
+domid_t pv_shim_get_initial_domain_id(void)
 {
     uint32_t eax, ebx, ecx, edx;
 
-    if ( !pv_shim )
-        return 0;
-
     cpuid(xen_cpuid_base + 4, &eax, &ebx, &ecx, &edx);
 
     return (eax & XEN_HVM_CPUID_DOMID_PRESENT) ? ecx : 1;
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 711ec3bf3b7845a6c295575421c252193ccbc0ae..61e0890052eb0c7ff7c19cc2fbdbfb9af512a545 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -43,6 +43,9 @@
 #include <xsm/xsm.h>
 #include <xen/trace.h>
 #include <asm/setup.h>
+#ifdef CONFIG_PV_SHIM
+#include <asm/pv/shim.h>
+#endif
 
 #ifdef CONFIG_X86
 #include <asm/guest.h>
@@ -65,6 +68,9 @@ DEFINE_RCU_READ_LOCK(domlist_read_lock);
 static struct domain *domain_hash[DOMAIN_HASH_SIZE];
 struct domain *domain_list;
 
+/* Last known non-system domain ID. */
+domid_t __read_mostly max_init_domid;
+
 /*
  * Insert a domain into the domlist/hash.  This allows the domain to be looked
  * up by domid, and therefore to be the subject of hypercalls/etc.
@@ -2261,6 +2267,15 @@ int continue_hypercall_on_cpu(
     return 0;
 }
 
+domid_t get_initial_domain_id(void)
+{
+#ifdef CONFIG_PV_SHIM
+    if ( pv_shim )
+        return pv_shim_get_initial_domain_id();
+#endif
+    return hardware_domid;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 05abb581a03d9c4deaea432a8d5e65d6906f70b4..498bffe56e1fac217c868a0ed79a14db98cb025d 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -415,10 +415,9 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
     case XEN_DOMCTL_createdomain:
     {
         domid_t        dom;
-        static domid_t rover = 0;
 
         dom = op->domain;
-        if ( (dom > 0) && (dom < DOMID_FIRST_RESERVED) )
+        if ( (dom > max_init_domid) && (dom < DOMID_FIRST_RESERVED) )
         {
             ret = -EEXIST;
             if ( !is_free_domid(dom) )
@@ -426,19 +425,19 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
         }
         else
         {
-            for ( dom = rover + 1; dom != rover; dom++ )
+            for ( dom = max_init_domid + 1; dom != max_init_domid; dom++ )
             {
                 if ( dom == DOMID_FIRST_RESERVED )
-                    dom = 1;
+                    dom = max_init_domid + 1;
                 if ( is_free_domid(dom) )
                     break;
             }
 
             ret = -ENOMEM;
-            if ( dom == rover )
+            if ( dom == max_init_domid )
                 break;
 
-            rover = dom;
+            max_init_domid = dom;
         }
 
         d = domain_create(dom, &op->u.createdomain, false);
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 8b63ca55f14fb81b6b803a8f28d487dd954ef862..1a079c9bddcb705dad256b0be1673122d77f4dd7 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -568,6 +568,14 @@ static long xenver_varbuf_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
     return sz;
 }
 
+static int __init cf_check globals_init(void)
+{
+    max_init_domid = get_initial_domain_id();
+
+    return 0;
+}
+__initcall(globals_init);
+
 long do_xen_version(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     bool deny = xsm_xen_version(XSM_OTHER, cmd);
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index 4ae5def08eda40db58b6506b60a9393c82ba9aa7..eef36bafd3574c97d2f1f5c1fc93b4b7b46b78ba 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -175,4 +175,8 @@ extern bool vmtrace_available;
 
 extern bool vpmu_is_available;
 
+extern domid_t max_init_domid;
+
+domid_t get_initial_domain_id(void);
+
 #endif /* __XEN_DOMAIN_H__ */

-- 
2.34.1




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 02:01:04 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 02:01:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864878.1276158 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtTL-0002vV-UQ; Sat, 04 Jan 2025 02:01:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864878.1276158; Sat, 04 Jan 2025 02:01:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtTL-0002vL-QM; Sat, 04 Jan 2025 02:01:03 +0000
Received: by outflank-mailman (input) for mailman id 864878;
 Sat, 04 Jan 2025 02:01:03 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=AhC6=T4=kernel.org=devnull+dmukhin.ford.com@srs-se1.protection.inumbo.net>)
 id 1tTtQu-0005Ax-T7
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 01:58:32 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org
 [2604:1380:4641:c500::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5ee09da4-ca3f-11ef-a0de-8be0dac302b0;
 Sat, 04 Jan 2025 02:58:20 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 0898E5C6411;
 Sat,  4 Jan 2025 01:57:35 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPS id 1E314C4CEE4;
 Sat,  4 Jan 2025 01:58:16 +0000 (UTC)
Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org
 (localhost.localdomain [127.0.0.1])
 by smtp.lore.kernel.org (Postfix) with ESMTP id 16F74E77188;
 Sat,  4 Jan 2025 01:58:16 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5ee09da4-ca3f-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1735955896;
	bh=C4I0w8+5EC1wc6Fr7dK8Qf/iMDwJkx3ZOmN4HyH2Ud0=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From;
	b=QJCbct/KweF+9rRQW1qw0dCoTySabWk30VD93NOmGRcJwjxOs/qU3zDrrI5flFa8Y
	 Mz1yRRiByk6k8UEepfCk2mtYwrCdkTBl/+XWqMulhJJG1SRjz/JE1xZo6t40bg6ieS
	 H/Kq+OVSlY1B/Kx579lbK2SNFu/1KVUVpYe6DePm4lgkx3xbsGXs1I8+ywepXNJ3L1
	 9k9EDZ4sTu/+x/vpKaw/UW2jpGC4krcycctf/ZEXwqzqK/pSbWGsgz/YGuc8DMYx6v
	 efXgKkn7P0Onq9JciB8/ijAsIs6rLSTGIprOCKN+JG0eMN7BkVvUNFhnzSnKdwdOy6
	 H9p+9Z/fl0m+g==
From: Denis Mukhin via B4 Relay <devnull+dmukhin.ford.com@kernel.org>
Date: Fri, 03 Jan 2025 17:58:29 -0800
Subject: [PATCH v3 23/24] docs/misc: update console documentation
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20250103-vuart-ns8250-v3-v1-23-c5d36b31d66c@ford.com>
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
In-Reply-To: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>, 
 Julien Grall <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, Jan Beulich <jbeulich@suse.com>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
 Denis Mukhin <dmukhin@ford.com>
X-Mailer: b4 0.14.2
X-Developer-Signature: v=1; a=ed25519-sha256; t=1735955892; l=5686;
 i=dmukhin@ford.com; s=20241125; h=from:subject:message-id;
 bh=APQcmog0xQYM3EBoFVE5ETu0ersksioDS4x/FBTt9bk=;
 b=oqKShhLqX/avc2rWyyCrDQH9JFfddXKvzHL7pbNhO2CYyq/vCCa+kigFa1VIsi9tjZPicHGI0
 qLaOcxQIb1yCMyyC3wkHVL1ZUfcbYFYPKIe6Rd7bLRYo4ErAcm2Phtz
X-Developer-Key: i=dmukhin@ford.com; a=ed25519;
 pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U=
X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with
 auth_id=287
X-Original-From: Denis Mukhin <dmukhin@ford.com>
Reply-To: dmukhin@ford.com

From: Denis Mukhin <dmukhin@ford.com>

Minor update related to virtual UART support.

Also:
 s/pv/PV/g
 s/hvm/HVM/g

Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
 docs/misc/console.txt | 50 ++++++++++++++++++++++++++------------------------
 1 file changed, 26 insertions(+), 24 deletions(-)

diff --git a/docs/misc/console.txt b/docs/misc/console.txt
index 4e180f88ba1312d8fcc47d27622ec347d387ce12..7840729b0c95d9c4ea5295f17ce77c04177f48a5 100644
--- a/docs/misc/console.txt
+++ b/docs/misc/console.txt
@@ -4,11 +4,11 @@ Xen PV Console notes
                                         stefano.stabellini@eu.citrix.com
 
 
-Xen traditionally provided a single pv console to pv guests, storing the
+Xen traditionally provided a single PV console to PV guests, storing the
 relevant information in xenstore under /local/domain/$DOMID/console.
 
-Now many years after the introduction of the pv console we have
-multiple pv consoles support for pv and hvm guests; multiple pv
+Now many years after the introduction of the PV console we have
+multiple PV consoles support for PV and HVM guests; multiple PV
 console backends (qemu and xenconsoled, see limitations below) and
 emulated serial cards too.
 
@@ -103,48 +103,50 @@ The supported values are only xenconsoled or ioemu; xenconsoled has
 several limitations: it can only be used for the first PV or virtual UART
 console and it can only connect to a pty.
 
-Emulated serials are provided by qemu-dm only to hvm guests; the number
-of emulated serials depends on how many "-serial" command line options
-are given to qemu. The output of a serial is specified as argument to
-the -serial command line option to qemu. Qemu writes the tty name to
-xenstore in the following path:
+Emulated serials are provided to HVM guests by qemu-dm or in-hypervisor UART
+emulator (Xen needs to be re-compiled).
+
+In qemu-dm case, the number of emulated serials depends on how many "-serial"
+command line options are given to qemu. The output of a serial is specified as
+argument to the -serial command line option to qemu. Qemu writes the tty name
+to xenstore in the following path:
 
 /local/domain/$DOMID/serial/$SERIAL_NUM/tty
 
 xenconsole is the tool to connect to a PV or virtual UART console or an
 emulated serial that has a pty as output. Xenconsole takes a domid as
-parameter plus an optional console type (pv for PV consoles, vuart for
-virtual UART or serial for emulated serials) and console number.
+parameter plus an optional console type ('pv' for PV consoles, 'vuart' for
+virtual UART or 'serial' for emulated serials) and console number.
 Depending on the type and console number, xenconsole will look for the tty
 node in different xenstore paths, as described above.  If the user doesn't
-specify the console type xenconsole will try to guess: if the guest is a pv
-guest it defaults to PV console, if the guest is an hvm guest it defaults to
+specify the console type xenconsole will try to guess: if the guest is a PV
+guest it defaults to PV console, if the guest is an HVM guest it defaults to
 emulated serial.
 
-By default xl creates a pv console for hvm guests, plus an emulated
+By default xl creates a PV console for HVM guests, plus an emulated
 serial if the user specified 'serial = "pty"' in the VM config file.
-Considering that xenconsole defaults to emulated serials for hvm guests,
+Considering that xenconsole defaults to emulated serials for HVM guests,
 executing xl create -c "domain" causes xenconsole to attach to the
 emulated serial tty. This is most probably what the user wanted because
-currently no bootloaders support xen pv consoles so the only way to
+currently no bootloaders support xen PV consoles so the only way to
 interact with a bootloader like grub over a console is to use the
 emulated serial.
-However the pv console is still easy to use with Linux PV on HVM guests:
+However the PV console is still easy to use with Linux PV on HVM guests:
 the user just need to pass "console=hvc0" to the kernel command line and
 then execute "xl console -t pv <domain>" to connect to it.
 
 When using stubdoms the serial cards are still emulated by qemu (this
 time running in the stubdom), the number of serial cards and where the
 output goes is still specified using qemu command line options.
-The difference is that for each emulated serial card there must be a pv
+The difference is that for each emulated serial card there must be a PV
 console connection between the stubdom and dom0 to export the serial
-output from the stubdom to dom0. The pv console backend for stubdom's pv
-consoles is always ioemu because multiple pv consoles support is a
-requirement in this case, considering that minios has its own pv console
-too. In order to simplify the setup when using stubdoms the hvm guest
-can only have one pv console with xenstored as backend (the stubdom
-could provide pv console backends to the hvm guest but then it would
-need another pv console connection for each console backend to export
+output from the stubdom to dom0. The PV console backend for stubdom's PV
+consoles is always ioemu because multiple PV consoles support is a
+requirement in this case, considering that minios has its own PV console
+too. In order to simplify the setup when using stubdoms the HVM guest
+can only have one PV console with xenstored as backend (the stubdom
+could provide PV console backends to the HVM guest but then it would
+need another PV console connection for each console backend to export
 the pty to dom0).
 
 The xenconsole program supports a very simple protocol to notify parent about

-- 
2.34.1




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 02:01:05 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 02:01:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864882.1276169 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtTN-0003KE-6t; Sat, 04 Jan 2025 02:01:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864882.1276169; Sat, 04 Jan 2025 02:01:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtTN-0003JN-2u; Sat, 04 Jan 2025 02:01:05 +0000
Received: by outflank-mailman (input) for mailman id 864882;
 Sat, 04 Jan 2025 02:01:03 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=AhC6=T4=kernel.org=devnull+dmukhin.ford.com@srs-se1.protection.inumbo.net>)
 id 1tTtQt-0005Ax-Sy
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 01:58:31 +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 5e823437-ca3f-11ef-a0de-8be0dac302b0;
 Sat, 04 Jan 2025 02:58:19 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id A5B9F5C6378;
 Sat,  4 Jan 2025 01:57:34 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPS id BC5DAC4CEDE;
 Sat,  4 Jan 2025 01:58:15 +0000 (UTC)
Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org
 (localhost.localdomain [127.0.0.1])
 by smtp.lore.kernel.org (Postfix) with ESMTP id B72ABE77199;
 Sat,  4 Jan 2025 01:58:15 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5e823437-ca3f-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1735955895;
	bh=pZ5j5wlBPTG0Ro4TQWWchJcQ0lQWJtDiDgixm3j4y6w=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From;
	b=sb8BufUAfvJHF+HrR1YXHs6FJn2FKtHyqwvGAO49pNVSOb0IEFVaKR1y6va1Rly1U
	 E/skfQ/W9Enf/posXj8Bnq/Bmgywh3KWM0CwDIQZBM4+CO5tNEFfSaTUaqsCR0+Ysr
	 RHKLAvZuMvInx1xqFKhj1mi7MZwtgdx0RtMRiCsEQNGQAOWThAysUULKCbZOrMFmSM
	 I0tPlQr2U1x6DCoYakTWNxEA9NTWi3elpMpbfNnxYMB8f4cKKBe/twOGsws5KvTjhr
	 dA9WdxhyLULlI0Lt3NdDjEoj31sUM8h3+mfMOYSlQtlKdOXpYxo6ULIljvRrNO+TLO
	 t45fQV88ThCeg==
From: Denis Mukhin via B4 Relay <devnull+dmukhin.ford.com@kernel.org>
Date: Fri, 03 Jan 2025 17:58:24 -0800
Subject: [PATCH v3 18/24] xen/include: introduce resource.h
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20250103-vuart-ns8250-v3-v1-18-c5d36b31d66c@ford.com>
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
In-Reply-To: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>, 
 Julien Grall <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, Jan Beulich <jbeulich@suse.com>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
 Denis Mukhin <dmukhin@ford.com>
X-Mailer: b4 0.14.2
X-Developer-Signature: v=1; a=ed25519-sha256; t=1735955892; l=4529;
 i=dmukhin@ford.com; s=20241125; h=from:subject:message-id;
 bh=/P+5vP8U8ti5w5xPLZtVwxfiABIGoHWoOC2zq7CuRN4=;
 b=FQXcMfLgv4oy0lSh4nZAJJfZwlJFq4kmqFTwWUf1GKQJhh19eTVM2pPOzhN85YG6ZA/bi410l
 y/VJ3oanYN0A5a4cG4PypCJds9z7yDwWwR35ly14MCgXf/rH3H7TbzZ
X-Developer-Key: i=dmukhin@ford.com; a=ed25519;
 pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U=
X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with
 auth_id=287
X-Original-From: Denis Mukhin <dmukhin@ford.com>
Reply-To: dmukhin@ford.com

From: Denis Mukhin <dmukhin@ford.com>

Move common resource definitions to a new architecture-agnostic shared header
file.

Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
It will be used in follow on NS8250 emulator code to describe legacy
PC COM resources.
---
---
 xen/common/device-tree/device-tree.c | 21 +--------------------
 xen/drivers/passthrough/arm/smmu.c   | 15 +--------------
 xen/include/xen/resource.h           | 34 ++++++++++++++++++++++++++++++++++
 3 files changed, 36 insertions(+), 34 deletions(-)

diff --git a/xen/common/device-tree/device-tree.c b/xen/common/device-tree/device-tree.c
index d0528c5825651f7cc9ebca0c949229c9083063c6..e8f810b2fe10890c033ed3a9d4ca627010ad019b 100644
--- a/xen/common/device-tree/device-tree.c
+++ b/xen/common/device-tree/device-tree.c
@@ -24,6 +24,7 @@
 #include <xen/ctype.h>
 #include <asm/setup.h>
 #include <xen/err.h>
+#include <xen/resource.h>
 
 const void *device_tree_flattened;
 dt_irq_xlate_func dt_irq_xlate;
@@ -535,26 +536,6 @@ int dt_child_n_size_cells(const struct dt_device_node *parent)
     return __dt_n_size_cells(parent, true);
 }
 
-/*
- * These are defined in Linux where much of this code comes from, but
- * are currently unused outside this file in the context of Xen.
- */
-#define IORESOURCE_BITS         0x000000ff      /* Bus-specific bits */
-
-#define IORESOURCE_TYPE_BITS    0x00001f00      /* Resource type */
-#define IORESOURCE_IO           0x00000100      /* PCI/ISA I/O ports */
-#define IORESOURCE_MEM          0x00000200
-#define IORESOURCE_REG          0x00000300      /* Register offsets */
-#define IORESOURCE_IRQ          0x00000400
-#define IORESOURCE_DMA          0x00000800
-#define IORESOURCE_BUS          0x00001000
-
-#define IORESOURCE_PREFETCH     0x00002000      /* No side effects */
-#define IORESOURCE_READONLY     0x00004000
-#define IORESOURCE_CACHEABLE    0x00008000
-#define IORESOURCE_RANGELENGTH  0x00010000
-#define IORESOURCE_SHADOWABLE   0x00020000
-
 /*
  * Default translator (generic bus)
  */
diff --git a/xen/drivers/passthrough/arm/smmu.c b/xen/drivers/passthrough/arm/smmu.c
index 03d22bce1e497e41834c273f9048b98dcbd48a54..aa6a968b574dce7cc753e8070fad3a6e585cd9e7 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -50,6 +50,7 @@
 #include <xen/rbtree.h>
 #include <xen/sched.h>
 #include <xen/sizes.h>
+#include <xen/resource.h>
 #include <asm/atomic.h>
 #include <asm/device.h>
 #include <asm/io.h>
@@ -70,22 +71,8 @@
 #define of_property_read_u32(np, pname, out) (!dt_property_read_u32(np, pname, out))
 #define of_property_read_bool dt_property_read_bool
 #define of_parse_phandle_with_args dt_parse_phandle_with_args
-
-/* Xen: Helpers to get device MMIO and IRQs */
-struct resource
-{
-	paddr_t addr;
-	paddr_t size;
-	unsigned int type;
-};
-
-#define resource_size(res) (res)->size;
-
 #define platform_device dt_device_node
 
-#define IORESOURCE_MEM 0
-#define IORESOURCE_IRQ 1
-
 static struct resource *platform_get_resource(struct platform_device *pdev,
 					      unsigned int type,
 					      unsigned int num)
diff --git a/xen/include/xen/resource.h b/xen/include/xen/resource.h
new file mode 100644
index 0000000000000000000000000000000000000000..4512658133defe8dc62d87192ffd19ad94b63c3b
--- /dev/null
+++ b/xen/include/xen/resource.h
@@ -0,0 +1,34 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * System resource description.
+ */
+#ifndef XEN__RESOURCE_H
+#define XEN__RESOURCE_H
+
+#define IORESOURCE_BITS         0x000000FFU      /* Bus-specific bits */
+
+#define IORESOURCE_TYPE_BITS    0x00001F00U      /* Resource type */
+#define IORESOURCE_IO           0x00000100U      /* PCI/ISA I/O ports */
+#define IORESOURCE_MEM          0x00000200U
+#define IORESOURCE_REG          0x00000300U      /* Register offsets */
+#define IORESOURCE_IRQ          0x00000400U
+#define IORESOURCE_DMA          0x00000800U
+#define IORESOURCE_BUS          0x00001000U
+
+#define IORESOURCE_PREFETCH     0x00002000U      /* No side effects */
+#define IORESOURCE_READONLY     0x00004000U
+#define IORESOURCE_CACHEABLE    0x00008000U
+#define IORESOURCE_RANGELENGTH  0x00010000U
+#define IORESOURCE_SHADOWABLE   0x00020000U
+
+#define IORESOURCE_UNKNOWN      ( ~0U )
+
+struct resource {
+    paddr_t addr;
+    paddr_t size;
+    unsigned int type;
+};
+
+#define resource_size(res)      ( (res)->size )
+
+#endif /* XEN__RESOURCE_H */

-- 
2.34.1




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 02:24:10 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 02:24:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864918.1276180 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtpc-0002Pv-WE; Sat, 04 Jan 2025 02:24:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864918.1276180; Sat, 04 Jan 2025 02:24:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtpc-0002Po-SE; Sat, 04 Jan 2025 02:24:04 +0000
Received: by outflank-mailman (input) for mailman id 864918;
 Sat, 04 Jan 2025 02:24:03 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTtpa-0002OU-S0
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 02:24:03 +0000
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f50cbf7d-ca42-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 03:24:00 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f50cbf7d-ca42-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1735957437; x=1736216637;
	bh=KRsMOD7cWh6r4AKjDf2Nvy/9Dgh4BquvQEdy8dgQi2s=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=W6nOml9r54O5arICTMjQ/XgKWNc6Fzdm1LeHXzW+b8Py9PGMJCo0GuafRik3wkEw4
	 QeM/TVfMaMDhSytt5OIHBHnvhtSfulxKCGDjdHlvF4nlWzpXihSrpjlDEOED8NIU1y
	 DUJtn7RVgjmAZGCLMbkBT+zMThhMq48dqKP2VzRob8mqL2LOilrgu/nP6VvYAHhubm
	 8EIQXx+XEWdL/E5Rpx3hJOSi/QlquX+tRCBLZx/XqoN9g5i3ybocjnkT8n1wwbeurr
	 Tubefhxa7jOpJgbFTB+yo+g2JuCJiE5DujQEkM/BqvkpylYdfYDg23NIM/+qcqWZ6M
	 gFa3T2ZLx8dpw==
Date: Sat, 04 Jan 2025 02:23:53 +0000
To: Jan Beulich <jbeulich@suse.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 01/35] xen: introduce resource.h
Message-ID: <AwhNFJq_zvjM-hNjnnwObYwKHMsEosrv3QRiGvw14turAtLTNHYYoJJCO8RegKITzlX0iAgzt0muh_2ndPr9uavCA6__ysmRZzAh87hEJlA=@proton.me>
In-Reply-To: <a6442bb6-ac06-47e4-a981-512314c8c8b9@suse.com>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-1-e9aa923127eb@ford.com> <a6442bb6-ac06-47e4-a981-512314c8c8b9@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 06013afdbe706550e0de627ccce4cf775196f41e
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tuesday, December 10th, 2024 at 5:13 AM, Jan Beulich <jbeulich@suse.com>=
 wrote:

>
>
> On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
>
> > --- /dev/null
> > +++ b/xen/include/xen/resource.h
> > @@ -0,0 +1,40 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
>
>
> GPL-2.0-only

Fixed.

>
> > +/*
> > + * System resource description.
> > + *
> > + * Reference:
> > + * include/linux/ioport.h
>
>
> I'm unsure of the usefulness of such a reference.

These definitions are taken from Linux'es
  include/linux/ioport.h

I think reference to the original code may help developers to borrow more
missing declarations in the future.

But sure, removed.

>
> > + */
> > +#if !defined(XEN__RESOURCE_H)
>
>
> Nit: #ifdef / #ifndef please whenever possible (as long as not inconsiste=
nt
> with adjacent code).

Sure.

>
> > +#define XEN__RESOURCE_H
> > +
> > +#define IORESOURCE_BITS 0x000000FFU /* Bus-specific bits /
> > +
> > +#define IORESOURCE_TYPE_BITS 0x00001F00U / Resource type /
> > +#define IORESOURCE_IO 0x00000100U / PCI/ISA I/O ports /
> > +#define IORESOURCE_MEM 0x00000200U
> > +#define IORESOURCE_REG 0x00000300U / Register offsets /
> > +#define IORESOURCE_IRQ 0x00000400U
> > +#define IORESOURCE_DMA 0x00000800U
> > +#define IORESOURCE_BUS 0x00001000U
> > +
> > +#define IORESOURCE_PREFETCH 0x00002000U / No side effects */
> > +#define IORESOURCE_READONLY 0x00004000U
> > +#define IORESOURCE_CACHEABLE 0x00008000U
> > +#define IORESOURCE_RANGELENGTH 0x00010000U
> > +#define IORESOURCE_SHADOWABLE 0x00020000U
> > +
> > +#define IORESOURCE_UNKNOWN (~0U)
> > +
> > +struct resource {
> > + paddr_t addr;
> > + paddr_t size;
> > + unsigned int type;
> > +};
> > +
> > +#define resource_size(res) (res)->size;
>
>
> The semicolon surely was wrong before and is wrong now. Plus Misra
> demands that such macro expansions be parenthesized, I think.

Fixed.

>
> > +#define foreach_resource(res) \
> > + for (; res && res->type !=3D IORESOURCE_UNKNOWN; res++)
>
>
> This one isn't being moved, but is being added. It's not used here,
> which makes it difficult to judge its correctness. Perhaps better to
> introduce this when its first needed, and then right away with the
> required parentheses around uses of the macro parameter.

I moved that hunk into the place where it is first used (the emulator
patch).

>
> > +#endif /* #if !defined(XEN__RESOURCE_H) */
>
>
> Just the guard identifier in the comment please.

Done.

>
> Jan




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 02:26:25 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 02:26:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864926.1276189 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtrs-0002yT-Am; Sat, 04 Jan 2025 02:26:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864926.1276189; Sat, 04 Jan 2025 02:26:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtrs-0002yM-7t; Sat, 04 Jan 2025 02:26:24 +0000
Received: by outflank-mailman (input) for mailman id 864926;
 Sat, 04 Jan 2025 02:26:22 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=aU+0=T4=protonmail.com=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTtrq-0002xv-62
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 02:26:22 +0000
Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch
 [185.70.40.133]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 48647e94-ca43-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 03:26:20 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 48647e94-ca43-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
	s=protonmail3; t=1735957579; x=1736216779;
	bh=bh4G4YrgCb/dcG3W18aZhLL1Si1Y7bPZ4HcCJfJK1Ec=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=qh1nrk6zMzL/vKZaaA3cMwrWnaRQbI+H9vaoc319zHVwJbiftwsW48Z1cVWidP786
	 Sc5Lg0MVsbhxdLwl3GT4PNsmrrF/rfkCLDVGZuc5deQpGgSBzfEkf2Kmdru9m8co4i
	 nUwwvXcv5H1FZ7cs7+tl0F2PnSuMxCZcu5z0507Q9LYpvApoyeR91XUtX55CmPuvyt
	 GZMDiZTjdVeB2t1aEGG+LaSPmjvduk/KBGJ85ksoc7QMVE91cPnyc7hiHnNoxxwFkU
	 kJeMJZeW8Y8LV3+QJ8C/GSnIBtywSYAAo/63VtxB3LwQ5xD//Ik4zLRvitDRohnjK+
	 eOA03+RaLw51Q==
Date: Sat, 04 Jan 2025 02:26:14 +0000
To: Jan Beulich <jbeulich@suse.com>
From: Denis Mukhin <dmkhn@protonmail.com>
Cc: dmukhin@ford.com, Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 02/35] xen/irq: introduce NO_IRQ
Message-ID: <g0IDot1fT8OuQkpEBIvMUILvlHuWbyck4OjI6F5ug0ArThpoEYddhOWYbYEHn9XGKXftqmGL-yGJ8t8yOaoNzMBy5QTj_OYbdwPymWWz760=@protonmail.com>
In-Reply-To: <8c7daeda-2a00-476a-9a86-806139035cd0@suse.com>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-2-e9aa923127eb@ford.com> <8c7daeda-2a00-476a-9a86-806139035cd0@suse.com>
Feedback-ID: 33633869:user:proton
X-Pm-Message-ID: 8a0170ffd4619e198a7447bfb166e45d39345d5d
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


On Tuesday, December 10th, 2024 at 5:17 AM, Jan Beulich <jbeulich@suse.com>=
 wrote:

>
>
> On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
>
> > From: Denis Mukhin dmukhin@ford.com
> >
> > Introduce definition for IRQ resource checks.
>
>
> How does this fit ...
>
> > --- a/xen/include/xen/irq.h
> > +++ b/xen/include/xen/irq.h
> > @@ -53,6 +53,7 @@ struct irqaction {
> > #define AUTO_ASSIGN_IRQ (-1)
> > #define NEVER_ASSIGN_IRQ (-2)
> > #define FREE_TO_ASSIGN_IRQ (-3)
> > +#define NO_IRQ (-4)
>
>
> ... the grouping here? The constants in context aren't used anywhere,
> so it's hard to see whether / how the new one fits here (and doesn't
> instead belong into the new resource.h you introduce in patch 1). Once
> again likely best to have this in the patch where it's first needed,
> thus providing at least some context.

I ended up dropping this change.

>
> Jan


From xen-devel-bounces@lists.xenproject.org Sat Jan 04 02:31:59 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 02:31:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864936.1276198 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtxC-00050a-Ti; Sat, 04 Jan 2025 02:31:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864936.1276198; Sat, 04 Jan 2025 02:31:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtxC-00050T-QB; Sat, 04 Jan 2025 02:31:54 +0000
Received: by outflank-mailman (input) for mailman id 864936;
 Sat, 04 Jan 2025 02:31:52 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTtxA-00050L-Ok
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 02:31:52 +0000
Received: from mail-10630.protonmail.ch (mail-10630.protonmail.ch
 [79.135.106.30]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0dc8ab74-ca44-11ef-a0de-8be0dac302b0;
 Sat, 04 Jan 2025 03:31:51 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 0dc8ab74-ca44-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1735957909; x=1736217109;
	bh=1tqwHz25lWDpgaQ6da/femUGwrWz4CR6GLbAiMYv97o=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=Qe0ZwYvbGGUEoey10uIryXU9KBiUhS1z0l3R9RJARuYC6tIcra9NoK6iih9bsG/nY
	 01RSJKqFVNJGQFaX/WKJ2ClncrqI2696Lujga624gbFla8tdnR6flaHZCf9c3KVEzy
	 IY1C/4u9X1uAV+jV4pgYtbdZ7dstNDQAIlX2tU6piZYpWQq+AXVsuRCt6qYBtlND/r
	 k1JDiTjFqohKecF4FPQh+ga+9dZiwPOBSb8gWywKcVMHLtQ3DE6HtDzLf9AEir/nAS
	 ntSr51gnn6QPoKTLVOYcfRCcQ7unR1T3LH2p1H1LAnqjIZm8795cPQ0ZVFBYa8jD9E
	 hKBtCcahuClmQ==
Date: Sat, 04 Jan 2025 02:31:43 +0000
To: Jan Beulich <jbeulich@suse.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 03/35] xen/ctype: introduce isconsole()
Message-ID: <UxuSYzSmEVywRqZ_UFKaoIq1qJIu3HJsDIFnih7hfMmjZ7m935H9ODPtxpe4NxWRFKBsiQL_j42X6U_1LdeSoI2Eflge05xsI5YUClj0HFc=@proton.me>
In-Reply-To: <b3afb61f-0a82-4a66-ae9c-42c1106a5399@suse.com>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-3-e9aa923127eb@ford.com> <b3afb61f-0a82-4a66-ae9c-42c1106a5399@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: b92b037ffb07bb54b6dcc59890d075344aa4e3d8
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tuesday, December 10th, 2024 at 5:22 AM, Jan Beulich <jbeulich@suse.com>=
 wrote:

>
>
> On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
>
> > There are several console drivers which have same checks w.r.t. printab=
le
> > characters. The check is moved to new isconsole() macro and re-used in
> > the console drivers.
>
>
> Something named isconsole() imo can't be expected to do what is checked f=
or

I tried to follow the "short" naming notation in ctype.h.
I agree; changed the name to is_console_printable() as per below suggestion=
.

> ...
>
> > --- a/xen/arch/arm/vuart.c
> > +++ b/xen/arch/arm/vuart.c
> > @@ -79,8 +79,7 @@ static void vuart_print_char(struct vcpu *v, char c)
> > struct domain *d =3D v->domain;
> > struct vuart *uart =3D &d->arch.vuart;
> >
> > - /* Accept only printable characters, newline, and horizontal tab. */
> > - if ( !isprint(c) && (c !=3D '\n') && (c !=3D '\t') )
> > + if ( !isconsole(c) )
> > return ;
>
>
> ... e.g. here. If we really want such a further abstraction (of which I'm
> unconvinced), then maybe isprintable() or (getting ling-ish)
> is_console_printable().

Reworked to is_console_printable()

>
> > --- a/xen/include/xen/ctype.h
> > +++ b/xen/include/xen/ctype.h
> > @@ -4,6 +4,8 @@
> > /*
> > * NOTE! This ctype does not handle EOF like the standard C
> > * library is required to.
> > + *
> > + * See Rule 21.13 in docs/misra/rules.rst.
> > */
>
>
> How's this change related to the purpose of the patch?

Only because the very first version of the macro was failing
an ECLAIR job for me because of Rule 21.13 violation.

Updated the commit message (v3).

>
> > @@ -30,6 +32,7 @@ extern const unsigned char _ctype[];
> > #define isspace(c) ((__ismask(c)&(_S)) !=3D 0)
> > #define isupper(c) ((__ismask(c)&(_U)) !=3D 0)
> > #define isxdigit(c) ((__ismask(c)&(_D|_X)) !=3D 0)
> > +#define isconsole(c) (isprint(c) || (c) =3D=3D '\n' || (c) =3D=3D '\t'=
)
>
>
> In a pretty general purpose macro like this one I'm afraid I view it as
> risky to evaluate the parameter more than once.

Fixed.

>
> Jan




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 02:34:23 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 02:34:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864947.1276208 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtzZ-00068o-Cj; Sat, 04 Jan 2025 02:34:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864947.1276208; Sat, 04 Jan 2025 02:34:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTtzZ-00068h-A6; Sat, 04 Jan 2025 02:34:21 +0000
Received: by outflank-mailman (input) for mailman id 864947;
 Sat, 04 Jan 2025 02:34: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 <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTtzY-00068b-C9
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 02:34:20 +0000
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 65906ec3-ca44-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 03:34:18 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 65906ec3-ca44-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1735958057; x=1736217257;
	bh=lHkOmA0yYDIjlgV+mQbw5gE30el3xGN7L6flZv0Zdd0=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=l6NkwFXXrLZ8YCrTLg8QRC6fHibWtaO/ek4NAj9yQguRDD0FuSlhsKR6YORV8oZLi
	 UJYwrTyaazCV1a97GvqzqVmFSB9LEQ+ElsSxmsKjmabs1NmOkGISfwIcnyC5iLFVEc
	 uXTQIcH6EiY/TSULpzCgEowXLvmSvcK2OC+WVg//7FF3cTNJL4Nt0Y5QJFD5YqMNdd
	 WJ0cfX+Yzggy+OkPfBmmFmhBW8L3P5Ir2ttPoYnoEw2NexNpVpx3EHb+1keOF0v9Q5
	 P2AGEINqkE/ysizKLGoD/CtnEBkZbNIG9ADnDjxzDARxsGz4pBm5mpEP15sLVhFs3g
	 NhceLGtxIpHSQ==
Date: Sat, 04 Jan 2025 02:34:15 +0000
To: Jan Beulich <jbeulich@suse.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 08/35] x86/domain: introduce domain_has_vuart()
Message-ID: <cvClvfXy_PbmJgxV0HBPZmRmUmwX2tt_D_kUN9cLEMAMZvSEvEPZ0pJb8tSvwaDzA-0PRkcW0S_kcKFKVJ5-gHvJVzX58hP3UVnZIe6ODfQ=@proton.me>
In-Reply-To: <904a209f-a917-4767-baf4-333b1cf8c084@suse.com>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-8-e9aa923127eb@ford.com> <904a209f-a917-4767-baf4-333b1cf8c084@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 8f5da005741f0c22ed523d62336b8fb6c3d14fbf
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


On Tuesday, December 10th, 2024 at 5:26 AM, Jan Beulich <jbeulich@suse.com>=
 wrote:

>
>
> On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
>
> > --- a/xen/arch/x86/include/asm/domain.h
> > +++ b/xen/arch/x86/include/asm/domain.h
> > @@ -506,6 +506,9 @@ struct arch_domain
> > #define has_pirq(d) (!!((d)->arch.emulation_flags & X86_EMU_USE_PIRQ))
> > #define has_vpci(d) (!!((d)->arch.emulation_flags & X86_EMU_VPCI))
> >
> > +/* NB: same symbol as in Arm port */
> > +#define domain_has_vuart(d) false
>
>
> This being the 3rd effectively identical patch, perhaps instead we want
> to default domain_has_vuart() to false unless an arch provides its own
> definition? Much like we do for a few other such items?

Ideally, domain_has_vuart() should depend on build flags and d->arch.emulat=
ion_flags
only. I have reworked the code, so that domain_has_vuart() is defined for a=
ll
architectures uniformly.
To do that, I plumbed d->arch.emulation_flags to all arch domain structures
and made arch-independent emulation flags declarations in v3.

>
> Jan




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 02:47:23 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 02:47:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864957.1276218 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTuC5-0001bL-Ca; Sat, 04 Jan 2025 02:47:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864957.1276218; Sat, 04 Jan 2025 02:47:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTuC5-0001bE-A3; Sat, 04 Jan 2025 02:47:17 +0000
Received: by outflank-mailman (input) for mailman id 864957;
 Sat, 04 Jan 2025 02:47:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTuC3-0001b8-0x
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 02:47:16 +0000
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 33816763-ca46-11ef-a0de-8be0dac302b0;
 Sat, 04 Jan 2025 03:47:13 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 33816763-ca46-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1735958832; x=1736218032;
	bh=v0dZXYl3I8TdMVIKNgDz74hwFkHaf02jvjOPF4zphk0=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=EKwYgyBc3Cum37TJevh+FBjldyBUu4OrXeWmdkMD9F59vzU2HIcS7FUmzuQzghVNh
	 Kzq8L8VpTo4Aghbgb0Y3MqfKBlH2FgV5cCF8mop2kB5WrB4KGRFmD4SusZpS4FJl7X
	 9BEALHEXHvuu66yPOOXu+0pHCvO94KUFiuwV3BhPWGRMxotfHvzj+teiCg3tHE8QZ5
	 wZDouBxs6HtyybQlINROUPiBiR/jraJbEENg9RO4uAj2zPAhrsslIy4PLLnyHhiQx0
	 SDfe5OvaxFbKnyMGMShRHDr/l0w/PQD8EX1TmrUwohRvdNJNcaheDx3XELYgzbHlfF
	 BLwEhcUVPd7lg==
Date: Sat, 04 Jan 2025 02:47:08 +0000
To: oleksii.kurochko@gmail.com
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH 09/36] riscv/domain: introduce domain_has_vuart()
Message-ID: <eI9HkQxhCvgWZi_5mg7CqB3OZuwbBaPRvpzmgYemCVuUrNoIIlzMyg3hHGF3XDDPiQvOxw2_M2fsDgIO_wd6KNQFRe3grJYTUjc6LJ3m8gE=@proton.me>
In-Reply-To: <YlPh-dsRQR3lCD7Xxdhp1kfF24QMKuu8nCzvXkDQAClIhEHlmLvwSxIMLjX6pPpQ_Nup0UJsD4TmPPSUzJUk3wSmsXx2IsZMzxNiqEJJT70=@proton.me>
References: <20241126-vuart-ns8250-v1-v1-0-87b9a8375b7a@ford.com> <20241126-vuart-ns8250-v1-v1-9-87b9a8375b7a@ford.com> <bc3136303d0e88017a5e3da21f97f9da28213acf.camel@gmail.com> <YlPh-dsRQR3lCD7Xxdhp1kfF24QMKuu8nCzvXkDQAClIhEHlmLvwSxIMLjX6pPpQ_Nup0UJsD4TmPPSUzJUk3wSmsXx2IsZMzxNiqEJJT70=@proton.me>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 70c6f9aff06a10cde2bb7c4739230a63222d2878
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


On Friday, December 6th, 2024 at 1:32 PM, Denis Mukhin <dmkhn@proton.me> wr=
ote:

>=20
>=20
>=20
> On Wednesday, November 27th, 2024 at 5:02 AM, oleksii.kurochko@gmail.com =
oleksii.kurochko@gmail.com wrote:
>=20
> > On Tue, 2024-11-26 at 15:21 -0800, Denis Mukhin via B4 Relay wrote:
> >=20
> > > From: Denis Mukhin dmukhin@ford.com
> > >=20
> > > Introduce domain_has_vuart() for RISC-V port to be used in the
> > > console driver.
> > >=20
> > > Signed-off-by: Denis Mukhin dmukhin@ford.com
> > > ---
> > > xen/arch/riscv/include/asm/domain.h | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >=20
> > > diff --git a/xen/arch/riscv/include/asm/domain.h
> > > b/xen/arch/riscv/include/asm/domain.h
> > > index
> > > c3d965a559b6ce3661bf17166d0c51853ff295a2..efbc4f1ea2619a187fe30ede17d
> > > 96de01e599220 100644
> > > --- a/xen/arch/riscv/include/asm/domain.h
> > > +++ b/xen/arch/riscv/include/asm/domain.h
> > > @@ -10,6 +10,8 @@ struct hvm_domain
> > > uint64_t params[HVM_NR_PARAMS];
> > > };
> > >=20
> > > +#define domain_has_vuart(d) false
> > > +
> > > struct arch_vcpu_io {
> > > };
> >=20
> > LGTM: Reviewed-by: Oleksii Kurochko oleksii.kurochko@gmail.com
>=20
>=20
> Thanks!
>=20
> > Probably it would be nice instead of having stub ( #define
> > domain_has_vuart(d) false ) in arch specific code, just ifdef-ing it
> > and put somewhere in
> > <xen/domain.h> to not introduce this definition for each architecture
> >=20
> > which doesn't support vuart now.
>=20
>=20
> Actually, my thought was adding arch-independent vuart layer which can
> call into vpl011, duart or ns8250.
> This way, domain_has_vuart() will move there, along w/ APIs which
> hooked into Xen console driver (e.g. ns8250's vuart_putchar()) will be
> all there as well.
> I kept this stub as is for now (in the follow on v2).

I ended up w/ domain_has_vuart() defined in xen/domain.h in v3:
   https://lore.kernel.org/xen-devel/20250103-vuart-ns8250-v3-v1-6-c5d36b31=
d66c@ford.com/

>=20
> > Thanks.
> >=20
> > ~ Oleksii


From xen-devel-bounces@lists.xenproject.org Sat Jan 04 02:49:31 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 02:49:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864965.1276229 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTuED-0002A3-Oa; Sat, 04 Jan 2025 02:49:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864965.1276229; Sat, 04 Jan 2025 02:49:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTuED-00029w-Ln; Sat, 04 Jan 2025 02:49:29 +0000
Received: by outflank-mailman (input) for mailman id 864965;
 Sat, 04 Jan 2025 02:49:28 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=aU+0=T4=protonmail.com=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTuEB-00029m-RP
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 02:49:28 +0000
Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 825323c3-ca46-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 03:49:25 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 825323c3-ca46-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
	s=protonmail3; t=1735958964; x=1736218164;
	bh=6ngrASUQxIp4Qsgrox320tZHgYlM3fZX3kGH+4ZHzvs=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=YVHymixHQG9nIxI/rQHnDWP3UyvaRl2eznAfa4LqnHZidW0HDMdVtogy/CQqHu5et
	 Ze/t5DANTBRur77BnO+D5xP/tGGZpmbvnJKqbPKDXHgBNctlLhBXaUzw6qevWAdd5M
	 /skAgrq4ne3sBGozx4rfyyaBAQ+ePhGLrORPhJrF26G+mRMSKj5CO+1g2XnTnEJUUe
	 CUH45p74nyecIKHg0DQOu+l+RlzZMZxuqSEB98I3mSnOlNT5M96R/aHmjfECqAnHUO
	 RczfXLtuTKr5zRHyulM6SaaI+6C03VmkcXG8vuCzDaHeE55dzY2A7mNSeqzK7jnNGo
	 ClqzhbauFBdgg==
Date: Sat, 04 Jan 2025 02:49:17 +0000
To: Jan Beulich <jbeulich@suse.com>
From: Denis Mukhin <dmkhn@protonmail.com>
Cc: dmukhin@ford.com, Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 12/35] xen/console: move vpl011-related code to vpl011 emulator
Message-ID: <nYIZUZ8P8_11UqKc4051P3o20npdWRNgy90-oNXkEj1y6AVPkUWM2-ARVJ7XLcdeah8qhATCd9U6-hdT0OxBKFTwpHh0hyxgA-nTGXNFRsk=@protonmail.com>
In-Reply-To: <ad47f490-c2a2-4a61-b9ed-a5830d93c3a4@suse.com>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-12-e9aa923127eb@ford.com> <ad47f490-c2a2-4a61-b9ed-a5830d93c3a4@suse.com>
Feedback-ID: 33633869:user:proton
X-Pm-Message-ID: daf682176c56f00bc9ebcb148926af85f6848ba0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tuesday, December 10th, 2024 at 5:33 AM, Jan Beulich <jbeulich@suse.com>=
 wrote:

>
>
> On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
>
> > --- a/xen/arch/arm/include/asm/vpl011.h
> > +++ b/xen/arch/arm/include/asm/vpl011.h
> > @@ -69,7 +69,7 @@ struct vpl011_init_info {
> > int domain_vpl011_init(struct domain *d,
> > struct vpl011_init_info *info);
> > void domain_vpl011_deinit(struct domain *d);
> > -void vpl011_rx_char_xen(struct domain *d, char c);
> > +int vpl011_rx_char_xen(struct domain *d, char c);
>
>
> If you make the function return an error indicator, ...
>
> > --- a/xen/drivers/char/console.c
> > +++ b/xen/drivers/char/console.c
> > @@ -559,9 +559,7 @@ static void __serial_rx(char c)
> > * domain, without a full PV ring to Dom0 (in that case input
> > * comes from the PV ring), then send the character to it.
> > */
> > - if ( d !=3D NULL &&
> > - !d->arch.vpl011.backend_in_domain &&
> > - d->arch.vpl011.backend.xen !=3D NULL )
> > + if ( d !=3D NULL )
> > vpl011_rx_char_xen(d, c);
> > else
> > printk("Cannot send chars to Dom%d: no UART available\n",
>
>
> ... how come that return value then isn't used anywhere?

That I overlooked; fixed.

>
> Jan


From xen-devel-bounces@lists.xenproject.org Sat Jan 04 02:50:11 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 02:50:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864973.1276239 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTuEs-0003YN-Vh; Sat, 04 Jan 2025 02:50:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864973.1276239; Sat, 04 Jan 2025 02:50:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTuEs-0003YG-T0; Sat, 04 Jan 2025 02:50:10 +0000
Received: by outflank-mailman (input) for mailman id 864973;
 Sat, 04 Jan 2025 02:50:10 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTuEs-0003Y4-28
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 02:50:10 +0000
Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9be0c8d5-ca46-11ef-a0de-8be0dac302b0;
 Sat, 04 Jan 2025 03:50:08 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9be0c8d5-ca46-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1735959008; x=1736218208;
	bh=W7J6i5x/8Ek+dqAE7fl5KSCrApZ7gxyKuVWCeMHtz6Q=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=QFtnOOkQsj8uAFCHDj5cW+sy7z6ujk5JpY5fvdo2uqwDsJH8lLWdMAClVwQxbtc2E
	 OBmXUBJLFgIywjIiga6wx4W4b/BQ4S0fiNMZcZsdEPKryFuCTv1omJaeH2Cfyl1DD7
	 2Aia51NBFBO8aUUKxVQQeRRkPq2FKZZtAKHPr2hY2M0LUK1Ye03ulZeuDawjK2K6pf
	 zLrozT5YeSp8OIhKNurdj71zZ32ixfo/shKypsbBgW8DSRxJRKVpBbw52bWj4HP+nj
	 0UDSD5Sw6GX8+Q2dkmYmBA6XO4sr007N2ZWqVKNtixCkOKehn6WNmCSmGxKgpYO4K0
	 OCL4Ct2uIYY4A==
Date: Sat, 04 Jan 2025 02:50:04 +0000
To: Jan Beulich <jbeulich@suse.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 10/35] xen/domain: add get_initial_domain_id()
Message-ID: <xFirAmBGiUy3kGF6yY5yOXOiymKw0LP81JxwOFPYwKTDOSrF8vRWwg8nQ2X11tyDlLwt9bVrWHp0_MDmBi7Ujaq9v5f-dloBxeXlRjqoxVQ=@proton.me>
In-Reply-To: <d3280b62-1bd5-4684-bf8c-be0d6d4ee842@suse.com>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-10-e9aa923127eb@ford.com> <d3280b62-1bd5-4684-bf8c-be0d6d4ee842@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 6f5540a4639ab86268e368440f78a22bcbe25081
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tuesday, December 10th, 2024 at 5:50 AM, Jan Beulich <jbeulich@suse.com>=
 wrote:

>
>
> On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
>
> > Move get_initial_domain_id() to a public API and enable for all archite=
ctures.
> > That is pre-requisite change for console focus switch logic cleanup.
>
>
> Yet then how does this fit with dom0less, let alone hyperlaunch,
> where multiple domains may be created right when Xen starts?

I see it now, thanks; fixed in v3.

>
> Plus, if you make this generic, shouldn't Arm also be adjusted to
> use this function (if nothing else then to avoid things going out
> of sync later on)?

Yes, Arm port should have been adjusted; thanks a lot!
Addressed.

>
> > @@ -2229,6 +2230,15 @@ int continue_hypercall_on_cpu(
> > return 0;
> > }
> >
> > +domid_t get_initial_domain_id(void)
> > +{
> > +#ifdef CONFIG_X86
> > + return pv_shim_initial_domain_id();
> > +#else
> > + return 0;
> > +#endif
> > +}
>
>
> Imo this either wants to use CONFIG_PV_SHIM instead, eliminating the
> need for the pv_shim_initial_domain_id() stub.

Fixed.

>
> Jan




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 02:51:16 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 02:51:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864981.1276250 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTuFv-0004aE-8H; Sat, 04 Jan 2025 02:51:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864981.1276250; Sat, 04 Jan 2025 02:51:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTuFv-0004a7-4T; Sat, 04 Jan 2025 02:51:15 +0000
Received: by outflank-mailman (input) for mailman id 864981;
 Sat, 04 Jan 2025 02:51: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 <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTuFu-0004Zz-3T
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 02:51:14 +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 c24c0521-ca46-11ef-a0de-8be0dac302b0;
 Sat, 04 Jan 2025 03:51:13 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c24c0521-ca46-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1735959071; x=1736218271;
	bh=bFgZsvN8ug6qv0E64JqLve9OtjkDvHUNjUVERtYWc3g=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=j1qJ9rhCfFS0KSHqhjv460f1Yx601WxqF7xqaV70k8IJ370hpuDvab+2mJnnH/gkO
	 SJOBVfoprCKmwyuZqmV/G4BjdPyp+0bhFgbngneRhoGiLrRQcvLNK9M4bh6MlAz7XR
	 EIJNH1sxHMis1FQuxwziDGegxGNG0h4tpZy3ClP9+5/Hl6J9B8mVPZhsWyEn4X9iU7
	 kU6hazyL5TAYIO5Rh+BCDUppPa1fFQbmBQkzNckFRq1/u18Lg4DGoaRKZ2f70NKPTO
	 MQH/PEE+HUzm0Pg/NAZzUb+Wkq4PEYl3ePVf6rJTQ9rfDTq9YvXIs2nOXQCt3L3/QY
	 t8GZOMuqRnNoA==
Date: Sat, 04 Jan 2025 02:51:06 +0000
To: Jan Beulich <jbeulich@suse.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 11/35] xen/domain: enable max_init_domid for all architectures
Message-ID: <7Hq9DTz8CArNygIvQfu-X4WS2kGp0GovCOriynZ8hXfYkwZdCO8isiX1UG_6y7XkxZAWDa84hO27pYRwLogcRTG1wk7p9mQFGzMdFruZk5Y=@proton.me>
In-Reply-To: <32065c58-ca83-4a18-8831-6044da2377e9@suse.com>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-11-e9aa923127eb@ford.com> <32065c58-ca83-4a18-8831-6044da2377e9@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 73aefb83cb254b9fa0adbac377501f3cd1ef1f8a
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tuesday, December 10th, 2024 at 5:57 AM, Jan Beulich <jbeulich@suse.com>=
 wrote:

>
>
> On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
>
> > --- a/xen/common/domain.c
> > +++ b/xen/common/domain.c
> > @@ -65,6 +65,9 @@ DEFINE_RCU_READ_LOCK(domlist_read_lock);
> > static struct domain *domain_hash[DOMAIN_HASH_SIZE];
> > struct domain *domain_list;
> >
> > +/* Last known non-system domain ID. /
> > +domid_t __read_mostly max_init_domid;
> > +
> > /
> > * Insert a domain into the domlist/hash. This allows the domain to be l=
ooked
> > * up by domid, and therefore to be the subject of hypercalls/etc.
> > @@ -815,6 +818,12 @@ struct domain *domain_create(domid_t domid,
> >
> > memcpy(d->handle, config->handle, sizeof(d->handle));
> >
> > + /*
> > + * Housekeeping for physical console forwarding to the domain.
> > + */
> > + if ( !is_system_domain(d) && max_init_domid < domid )
> > + max_init_domid =3D domid;
>
>
> Yet this affects all domains, not just init ones. Either the variable
> name is wrong then, or the updating logic needs adjustment. The comment
> in the earlier hunk suggests the former, yet then this is a behavioral
> change for Arm, correctness of which needs explaining.

Thanks, I have reworked that part.

>
> Jan




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 02:53:29 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 02:53:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.864990.1276258 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTuI0-000641-Hd; Sat, 04 Jan 2025 02:53:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 864990.1276258; Sat, 04 Jan 2025 02:53:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTuI0-00063u-F6; Sat, 04 Jan 2025 02:53:24 +0000
Received: by outflank-mailman (input) for mailman id 864990;
 Sat, 04 Jan 2025 02:53: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 <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTuHz-00063X-6u
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 02:53:23 +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 0f5aec5a-ca47-11ef-a0de-8be0dac302b0;
 Sat, 04 Jan 2025 03:53:22 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 0f5aec5a-ca47-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1735959201; x=1736218401;
	bh=3d4Wsut02P5KYlq1G0hgh3SC/fqXiajwkExK340YX0I=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=NBdwEoK8J+fhYFkimaWQf+shWMun2aL2umovKhq+6/DwW7+Igo/yla/1qas6lyWqm
	 GV9cUHOEDF2VIIkOIlzn5ph7WuH4r9L+BoQJkWKDDzoZF0T9ORuIc8ZOnmW1PlnX3N
	 JekiUQbBelSdInu4HkeLsvMOq7L0P8rTi87pMAFZaMP/6EW0bXZD1YVypzYCdreegx
	 Oa4LLxt8tMxQD1pwWCRu8Mw2pC3hoHPiW7Rfk1gfHtvW5U1LrfgUNrcdjItnEElLUw
	 ZRwLhHuPYvtOroC1jobiJKG5BwvTX6/WxULdMKZuVgo2tGwDvNKRs6wqwTve8guI8J
	 AdGKwUJa+OYgg==
Date: Sat, 04 Jan 2025 02:53:16 +0000
To: Jan Beulich <jbeulich@suse.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 13/35] xen/console: rename console_input_domain
Message-ID: <me5SVEwY-C-nKgeVQAhd3qDdCZw13e3N13_1dk4kdIyIJUwbnV1RBAlpILxCX3LFIodVmtS3Dz5GDZ5yX5aVayE-dYINkMh44ZRggf9juK4=@proton.me>
In-Reply-To: <16b43ca4-d56d-4c1c-b43e-1e3bd4919857@suse.com>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-13-e9aa923127eb@ford.com> <16b43ca4-d56d-4c1c-b43e-1e3bd4919857@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: ad5143812a365f510af47846d03b7192b1c4f224
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tuesday, December 10th, 2024 at 6:01 AM, Jan Beulich <jbeulich@suse.com>=
 wrote:

>
>
> On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
>
> > console_input_domain() takes an RCU lock to protect domain structure.
> > That implies call to rcu_unlock_domain() after use.
> >
> > Rename console_input_domain() to rcu_lock_domain_console_owner() to
> > highlight the need of calling rcu_unlock_domain().
>
>
> While I can see where you're coming from, ...
>
> > --- a/xen/drivers/char/console.c
> > +++ b/xen/drivers/char/console.c
> > @@ -477,7 +477,7 @@ static unsigned int __read_mostly console_rx =3D 0;
> >
> > #ifdef CONFIG_SBSA_VUART_CONSOLE
> > /* Make sure to rcu_unlock_domain after use */
> > -struct domain *console_input_domain(void)
> > +struct domain *rcu_lock_domain_console_owner(void)
> > {
> > if ( console_rx =3D=3D 0 )
> > return NULL;
>
>
> ... the new name no longer expresses that a domain pointer is being retur=
ned
> (out of thin air). I'm uncertain this is an improvement.

I introduced console_{get,put}_domain() in v3 as per Roger's suggestion.

>
> Jan




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 02:54:18 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 02:54:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865000.1276269 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTuIr-0006b5-RX; Sat, 04 Jan 2025 02:54:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865000.1276269; Sat, 04 Jan 2025 02:54:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTuIr-0006ay-OJ; Sat, 04 Jan 2025 02:54:17 +0000
Received: by outflank-mailman (input) for mailman id 865000;
 Sat, 04 Jan 2025 02:54:16 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTuIq-0006ai-OR
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 02:54:16 +0000
Received: from mail-10628.protonmail.ch (mail-10628.protonmail.ch
 [79.135.106.28]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2ea3acc1-ca47-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 03:54:14 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2ea3acc1-ca47-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1735959253; x=1736218453;
	bh=ieijF41JW5XbidMsvo3le8DzS9ZniHQdg2RpsvTEbF4=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=mTAT5LYGBM8+jsDRAAHbkrw4mTw1Aroc3LcmhnheSthS5+nv7tpauiBrGvCdh844W
	 TL0NFtytooud3TTJPO8RRMF8Y63FUIE9DQmFzzrQbfGHFiVimP2OUutzG28BC8Mqt1
	 BO8AqTrUaniW2XA4HX0h3wsQhIQW7aCPDWThqF6ys2zK0DdUXILhSavvScDhV5Z6vD
	 jUkqSuZTNwLW9PcOrYO61hVZx/mRFR92hdgAMUOS1Y5IeHdgqNrZfImmNupX7h8ClA
	 Di1J6DLQ1JwWYao+8jWPSbuO1sUnIdZDI2O3S9/KPKVEHpWeop4MUQCzo2DWj9/JBK
	 odZUkN6zFNuaQ==
Date: Sat, 04 Jan 2025 02:54:09 +0000
To: Jan Beulich <jbeulich@suse.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 14/35] xen/console: rename switch_serial_input() to console_find_owner()
Message-ID: <jm9J6dVwIhRA-3cxYQhsRTVd2KB4a_EoRUvLKCf2z1bIPf5WK3HcKGLiJO1fPa4v_h9EW64y0W67LUu-WzidIduKoVzMV2RCykHx3S4MfSM=@proton.me>
In-Reply-To: <eb9246cc-059d-4dca-aca8-e75976537206@suse.com>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-14-e9aa923127eb@ford.com> <eb9246cc-059d-4dca-aca8-e75976537206@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 975a7d3318596125c56970c2fc86670c2caaef4a
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tuesday, December 10th, 2024 at 6:13 AM, Jan Beulich <jbeulich@suse.com>=
 wrote:

>
>
> On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
>
> > From: Denis Mukhin dmukhin@ford.com
> >
> > Updated the name to highlight the logic of selection the physical conso=
le
> > owner: existing code does not switch only serial console, it also switc=
hes
> > video console and debugging console (debug I/O port and console hyperca=
ll).
>
>
> I'm especially surprised you mention "video console" here. Afaics all of
> this is only about console input, and no input comes from a video device.
> Arguably "serial" in the original name is too narrow now. Yet "input"
> continues to be quite appropriate.

Yes, sorry, the explanation is wrong.
Fixed.

>
> Jan




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 02:58:03 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 02:58:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865008.1276279 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTuMT-0007CR-Ac; Sat, 04 Jan 2025 02:58:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865008.1276279; Sat, 04 Jan 2025 02:58:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTuMT-0007CK-7N; Sat, 04 Jan 2025 02:58:01 +0000
Received: by outflank-mailman (input) for mailman id 865008;
 Sat, 04 Jan 2025 02:58:00 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTuMS-0007CE-My
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 02:58:00 +0000
Received: from mail-10630.protonmail.ch (mail-10630.protonmail.ch
 [79.135.106.30]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b4ac9c89-ca47-11ef-a0de-8be0dac302b0;
 Sat, 04 Jan 2025 03:57:59 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b4ac9c89-ca47-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1735959478; x=1736218678;
	bh=E4Ia3cd3hJv6108BJqK6DAfB/eDvahoG2f548nG4GjI=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=Ow+TF6rCmjL5xsDEM9iMYq/qWsy+nV0qaxMs1JKnkcVKkIVXPH88YMWH4o2NaRpTk
	 1d2IWcPr9ue4bH41+vnTW+5QzYpuji4Od2VyXrBMJKBzSStFvrsSuxP5JF66Zqy/dd
	 YFiQyqBHkCsLsbxLzYLAW2BbNKbgt2HrXE/yGYJ2NA72SSz5YwEh9rR+Mno4ObpL1A
	 WQlIA5boO85o3ULZ9rCt4ugyvaVcq98somMfoGgeoFM1VQ3LImCmzgPX8i5iu1Tccq
	 J3+ghsjrcIAvxblWHALp8lxDl7Yd4xqbSV1btO2+ysrVL97dklrfNvA6C/HntXSVc9
	 HNTEr3bUYORTQ==
Date: Sat, 04 Jan 2025 02:57:54 +0000
To: Jan Beulich <jbeulich@suse.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 16/35] xen/console: introduce printk_common()
Message-ID: <hYzpsKcLLQl-hDLJQHJZSrZtcT5PVx6qx3aKoTyDtH-EYxMtYA9XKavqTvfukRQshSpt9ffdH0MyiqSdglLWtNTSPGduWBOnUbb4DLfityc=@proton.me>
In-Reply-To: <9c9120f6-6291-43d1-93ac-deebdc222f3e@suse.com>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-16-e9aa923127eb@ford.com> <9c9120f6-6291-43d1-93ac-deebdc222f3e@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: ac4611139d91b031976d6bbd9d77977a5b45677d
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tuesday, December 10th, 2024 at 6:27 AM, Jan Beulich <jbeulich@suse.com>=
 wrote:

>
>
> On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
>
> > Introduce new printk() variant for convenient printouts which skip '(XE=
N)'
> > prefix on xen console. This is needed for the case when physical consol=
e is
> > owned by a domain w/ in-hypervisor UART emulation enabled.
>
>
> Imo it should still be guest_printk() which is then used from there.

I ended up w/ printk_noprefix(): vprintk_common() expects user-defined pref=
ix,
while original printk_common() does not expect prefix. Such inconsistency
may be confusing because both functions are named xxx_common().

>
> > --- a/xen/include/xen/lib.h
> > +++ b/xen/include/xen/lib.h
> > @@ -61,6 +61,9 @@ debugtrace_printk(const char *fmt, ...) {}
> > extern void printk(const char *fmt, ...)
> > attribute ((format (printf, 1, 2), cold));
> >
> > +extern void printk_common(const char *fmt, ...)
> > + attribute ((format (printf, 1, 2)));
>
>
> No "cold" attribute, compared to printk()?

Thanks, fixed.

>
> Jan




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 03:00:48 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 03:00:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865019.1276289 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTuOy-0000QJ-Ob; Sat, 04 Jan 2025 03:00:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865019.1276289; Sat, 04 Jan 2025 03:00:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTuOy-0000QC-LZ; Sat, 04 Jan 2025 03:00:36 +0000
Received: by outflank-mailman (input) for mailman id 865019;
 Sat, 04 Jan 2025 03:00:35 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTuOx-0000JL-7M
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 03:00:35 +0000
Received: from mail-10628.protonmail.ch (mail-10628.protonmail.ch
 [79.135.106.28]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 10eddb6b-ca48-11ef-a0de-8be0dac302b0;
 Sat, 04 Jan 2025 04:00:34 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 10eddb6b-ca48-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1735959633; x=1736218833;
	bh=wb6okQq/hzkDRz9Y13fWObj06Tss0gNPxgVdOiymwHU=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=JZ4ajQ/l/y8TfQyikbzNH+M+MiiGeKPRyq6rR+ZBogL+ZhKG651aYqJp12cvpc48I
	 nb7mdtBFxwHhZMdApr977NAlfOYVC/12FrIg+aeXbGDQg3NRYkDN93VQp4yMpBpBy7
	 8nuPmqoEJIWaEUc4ItOJt5Yih4KzjX+H5l4jxmmSQWhoOo87Jbc5cD09irAzoxNPiX
	 w8qAsPx+XQTckyoAdzEBYxIsH5m6oy+ftwPd9AzcSLH4SUelkpmpxQm+AfGovFpZ2M
	 gqsm24FKQTe7OrQIUNzUr0IEU9rk17lXBAt6eSJWiXQRhxOHHK4sQ8t1bJC7e9jCX+
	 LTtoca0PkgWuw==
Date: Sat, 04 Jan 2025 03:00:30 +0000
To: Jan Beulich <jbeulich@suse.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 17/35] xen/console: introduce consoled_is_enabled()
Message-ID: <dbgW8XOq7JPdwZfOVtTFNzR4sEKb8gtxLEa1gygWzrm3gtGw28Rh4rxtwROJZ63-oMBOdfrzck3uET7uXNAjd3DW_NNRcgU_WbsCaFTmC0g=@proton.me>
In-Reply-To: <1968c658-595d-4d36-8558-8f178f8ed531@suse.com>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-17-e9aa923127eb@ford.com> <1968c658-595d-4d36-8558-8f178f8ed531@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: b52792a9315fd4d8f807dfab8d20d7d9ccb0a8a1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tuesday, December 10th, 2024 at 6:31 AM, Jan Beulich <jbeulich@suse.com>=
 wrote:

>
>
> On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
>
> > --- a/xen/drivers/char/consoled.c
> > +++ b/xen/drivers/char/consoled.c
> > @@ -43,13 +43,13 @@ struct xencons_interface *consoled_get_ring_addr(vo=
id)
> > static char buf[BUF_SZ + 1];
> >
> > /* Receives characters from a domain's PV console */
> > -void consoled_guest_rx(void)
> > +int consoled_guest_rx(void)
> > {
> > size_t idx =3D 0;
> > XENCONS_RING_IDX cons, prod;
> >
> > if ( !cons_ring )
> > - return;
> > + return 0;
> >
> > spin_lock(&rx_lock);
> >
> > @@ -91,15 +91,17 @@ void consoled_guest_rx(void)
> >
> > out:
> > spin_unlock(&rx_lock);
> > +
> > + return 0;
> > }
> >
> > /* Sends a character into a domain's PV console */
> > -void consoled_guest_tx(char c)
> > +int consoled_guest_tx(char c)
> > {
> > XENCONS_RING_IDX cons, prod;
> >
> > if ( !cons_ring )
> > - return;
> > + return 0;
> >
> > cons =3D ACCESS_ONCE(cons_ring->in_cons);
> > prod =3D cons_ring->in_prod;
> > @@ -118,6 +120,7 @@ void consoled_guest_tx(char c)
> >
> > cons_ring->in[MASK_XENCONS_IDX(prod++, cons_ring->in)] =3D c;
> >
> > +
> > /* Write to the ring before updating the pointer */
>
>
> No excess blank lines please.

Fixed.

>
> > @@ -125,6 +128,13 @@ void consoled_guest_tx(char c)
> > notify:
> > /* Always notify the guest: prevents receive path from getting stuck. *=
/
> > pv_shim_inject_evtchn(pv_console_evtchn());
> > +
> > + return 0;
> > +}
>
>
> For both of the functions - what use is it to make the functions return
> a value, when all they'd ever return is zero (and callers don't care)?

Fixed.

> I'm also having a hard time seeing how this adjustment is related to ...
>
> > +bool consoled_is_enabled(void)
> > +{
> > + return pv_shim && pv_console;
> > }
>
>
> ... the introduction of this function (which by itself is probably fine).

That will be a cleanup in console driver on the code path I touched wrt con=
sole
focus switch.

>
> Jan




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 03:05:30 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 03:05:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865030.1276299 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTuTg-0002Bv-8W; Sat, 04 Jan 2025 03:05:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865030.1276299; Sat, 04 Jan 2025 03:05:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTuTg-0002Bo-5x; Sat, 04 Jan 2025 03:05:28 +0000
Received: by outflank-mailman (input) for mailman id 865030;
 Sat, 04 Jan 2025 03:05:26 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTuTe-0002Bi-QF
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 03:05:26 +0000
Received: from mail-10631.protonmail.ch (mail-10631.protonmail.ch
 [79.135.106.31]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id be38529b-ca48-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 04:05:25 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: be38529b-ca48-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1735959924; x=1736219124;
	bh=5oKx6WeDf6Un5PibySC+vB5JLbGbDqax3sVCR+8XQo0=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=fM5ScKQlwIBp9+3urliuLc+URhmXXt6kU+ecgArd72oMIIWlwTZhIuU0opi9RhWzY
	 Kdx0vcqx4dbyNh5uYxut5AUr97+IdYHS8PwmsMtYeRv9SGHLBzMwaNsKaqDUm8QHi8
	 7rNvXLyRYGvaH6WFo/KYSweapVO4+H794RVjTlnCEpgCrKCLhhKVTLMiy72bzbrngY
	 Y5MaVPAcG+fJVkBLHa44WHMDh26M0I8wkSkkgPrTeAeDlvgLoWiE9vZfL7QiBkRX4N
	 yYRB5b2xqpy3GPZ/hVQa4d422MU4sqqAOGs8DRPH++ap8o5eftHZeaBwIaif68JMFP
	 9I0/pfMw0ZcvQ==
Date: Sat, 04 Jan 2025 03:05:20 +0000
To: Jan Beulich <jbeulich@suse.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 18/35] xen/console: introduce use of 'is_console' flag
Message-ID: <HSEMyFF-F-Nf0DSu-ZTw0qEJf4AcjdWfg1rsri8NcLZMZVkFzp1rMeLMOd7ywC-6C22XUjW_4ssLdrht2SfZljxXgfUEjTKYOCjs5Zddjpk=@proton.me>
In-Reply-To: <7ab4786b-15fa-4504-9694-f63b0f71c5a2@suse.com>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-18-e9aa923127eb@ford.com> <7ab4786b-15fa-4504-9694-f63b0f71c5a2@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 4f2a294a9f13b23a56a86c609a45c2a919cf02c4
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


On Tuesday, December 10th, 2024 at 6:52 AM, Jan Beulich <jbeulich@suse.com>=
 wrote:

>
>
> On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
>
> > From: Denis Mukhin dmukhin@ford.com
> >
> > The code now inspects d->is_console flag to decide whether the console =
focus
> > should move to the domain w/ console after administrator presses <Ctrl+=
aaa>.
> >
> > Console owner domain switch logic updated accordingly.
> >
> > Signed-off-by: Denis Mukhin dmukhin@ford.com
>
>
> Just as a remark, as it's a pre-existing problem: I'm unconvinced that
> "is_console" is a good name here.

I think it should be called something like console_perm.
I kept name as is for now, but I can make a change.

>
> > @@ -509,14 +509,20 @@ static void console_find_owner(void)
> > domid =3D get_initial_domain_id();
> > else
> > domid =3D next_rx - 1;
> > +
> > d =3D rcu_lock_domain_by_id(domid);
> > - if ( d )
> > + if ( d =3D=3D NULL )
>
>
> Seeing the original code, the more "natural" transformation would be to
> !d (as we use elsewhere as well, to keep code short).

Fixed.

>
> Jan




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 03:07:40 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 03:07:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865037.1276308 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTuVj-0002km-JY; Sat, 04 Jan 2025 03:07:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865037.1276308; Sat, 04 Jan 2025 03:07:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTuVj-0002kf-H4; Sat, 04 Jan 2025 03:07:35 +0000
Received: by outflank-mailman (input) for mailman id 865037;
 Sat, 04 Jan 2025 03:07:34 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTuVh-0002kY-8i
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 03:07:34 +0000
Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch
 [185.70.40.133]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0968b806-ca49-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 04:07:31 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 0968b806-ca49-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1735960050; x=1736219250;
	bh=NZmhaIpPiqVY6052EGTTGgHuFFSYbWuqrzKj7qwJpLQ=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=VwY+8A+1b2zCvRbxYSBz66RSoObZyl5aXdNvrtpJ+Pf3nIkvj1dZEuMfLHIql/a/F
	 jX8qULkFFFYsf2wGumeKcYl2yLxOVu25DhKGFOp7tF1FKM4KKg/GF6GM7ENJm8CaVK
	 TytBTNSsWD2tDbZf+WId5YDJVgxb6laxXp/R++PZAA1K2e5JmioVmiA3o+AOB/pF9X
	 eB3ahIj5OSOJHidmHfiGTGIJ8hZuxvi7ZzNxWWn74Rq2idjrVwhtlRUrnmMfkbUZd1
	 81i+Nqvr0e2mMq5LciQ9daYhPiWrreTRLoVDKd5StJF3vZthXgfGocegQ3Pubd5xAh
	 CQey3nVLlFKcQ==
Date: Sat, 04 Jan 2025 03:07:23 +0000
To: Jan Beulich <jbeulich@suse.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 19/35] xen/console: introduce console_set_owner()
Message-ID: <CA3mSmUEpURgjpQUifNWDKDNS2HBsE68ad-RudxX4F45CCn2JL1wLo63_ZYcA7qx4nkD23GvE3BVlMjV0oz75Mssd0A5wQQ6zKlcWRLfhyM=@proton.me>
In-Reply-To: <d9c8e9bf-7eac-48f7-a347-b78e97a16f8f@suse.com>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-19-e9aa923127eb@ford.com> <d9c8e9bf-7eac-48f7-a347-b78e97a16f8f@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 7c489c6c56dde900b90bd11d92bcaa3203dd2700
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tuesday, December 10th, 2024 at 7:02 AM, Jan Beulich <jbeulich@suse.com>=
 wrote:

>
>
> On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
>
> > --- a/xen/drivers/char/console.c
> > +++ b/xen/drivers/char/console.c
> > @@ -463,82 +463,100 @@ static void cf_check dump_console_ring_key(unsig=
ned char key)
> >
> > /*
> > * CTRL-<switch_char> changes input direction, rotating among Xen, Dom0,
> > - * and the DomUs started from Xen at boot.
> > + * and the DomUs.
> > /
> > #define switch_code (opt_conswitch[0]-'a'+1)
> > +
> > /
> > - * console_owner=3D0 =3D> input to xen
> > - * console_owner=3D1 =3D> input to dom0 (or the sole shim domain)
> > - * console_owner=3DN =3D> input to dom(N-1)
> > + * Current console owner domain ID: either Xen or domain w/ d->is_cons=
ole =3D=3D
> > + * true.
>
>
> The switching of number space may better have been a separate patch.
> Albeit maybe I'm just not seeing why it wants combining with the
> introduction of console_set_owner().

This is the part I tried in different variations and finally
ended up w/ plumbing new console owner IDs "address space"
here: console_set_owner() takes domid_t and I decided against intermediate
patch, since it is not a big (in term of lines of code) change.

>
> Actually, is this switching actually complete? What about late hwdom,
> which has a non-zero domain ID?

I did reworks for max_init_domid in v3, I believe it should address late
hwdom scenario.

>
> > + * Initialized in console_endboot().
> > */
> > -static unsigned int __read_mostly console_owner =3D 0;
> > +static domid_t __read_mostly console_owner;
> >
> > -#define max_console_rx (max_init_domid + 1)
> > +static struct domain *rcu_lock_domain_console_by_id(domid_t domid)
>
>
> I think "domain" and "console" want switching in the name, as it's a
> domain you're locking, not a console.

Renamed to "console_get_domain_by_id".

>
> > +int console_set_owner(domid_t domid)
>
>
> static? Iirc Misra doesn't like non-static functions which aren't called
> from any other CU.

Yes, but there's a follow on patch which will undo static - hwdom_crashcons=
ole=3D
patch - to drop the user to xen console once dom0 has crashed.
So since there's a need in globally visible symbol, I decided to get rid of=
 static
right away.

>
> Jan




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 03:09:00 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 03:09:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865045.1276319 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTuX3-0003JY-TT; Sat, 04 Jan 2025 03:08:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865045.1276319; Sat, 04 Jan 2025 03:08:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTuX3-0003JR-QL; Sat, 04 Jan 2025 03:08:57 +0000
Received: by outflank-mailman (input) for mailman id 865045;
 Sat, 04 Jan 2025 03:08: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 <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTuX2-0003JC-0R
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 03:08:56 +0000
Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch
 [185.70.40.134]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3afbe7e0-ca49-11ef-a0de-8be0dac302b0;
 Sat, 04 Jan 2025 04:08:54 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 3afbe7e0-ca49-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1735960133; x=1736219333;
	bh=IA9U2t+VkT9DYeTlIFJe3qSW2L52y3P/FN4ATfk6UWI=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=JGxh6sn/gZiwHqa5ABTHT5KnpH6R+jjsYncMTkpBVcDhmkJUm+JOykW6H5zOIaLb1
	 RHlAwGX12QgHd1g5l+iyLix+CYOCrvwC9LTGSskCgyWPoLTncXHuSicEGUJnDh8O1S
	 l7JoH0lkXVHQUlLkUcAe3i57z8OdX7+47A42kRtOes6fjSYpPb9c/fm0JgtxCHrozr
	 qKNIUJpq9os/3pxDn3R2xVgvIHfVXiFPNP3uAcK6Z+p7o0wsq/nz3b0U23xKufQmp5
	 o047vdv1CxjRewACJH15MTzeZ9yG+La001+Ob8lCGEONjKVKwnHCj9gQZEJj67ZVv+
	 /MYSdrIW07eXw==
Date: Sat, 04 Jan 2025 03:08:47 +0000
To: Jason Andryuk <jason.andryuk@amd.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2 34/35] xen/console: enable console owners w/ emulated NS8250
Message-ID: <2uZS3QjicwLbB66ako72z5LY6tjKh61sLtGHXFt5t9kx9oSH82sCl5Xzv1MrvqXu7sHefhodIM-MAh-ue_mfwe7YQZcleh8qCN3M4_rVHE0=@proton.me>
In-Reply-To: <1b55c7eb-3e39-43d1-80d2-2d4caf6a0c76@amd.com>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-34-e9aa923127eb@ford.com> <1b55c7eb-3e39-43d1-80d2-2d4caf6a0c76@amd.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: ee7f8bd31dcf0ddde8d44a71ae8230d6c3262657
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


On Tuesday, December 10th, 2024 at 2:46 PM, Jason Andryuk <jason.andryuk@am=
d.com> wrote:

>
>
> On 2024-12-05 23:42, Denis Mukhin via B4 Relay wrote:
>
> > From: Denis Mukhin dmukhin@ford.com
> >
> > Enable console focus for domains w/ virtual NS8250.
> >
> > Code change allows to capture the output from the guest OS now and send=
 it to
> > the physical console device.
> >
> > Signed-off-by: Denis Mukhin dmukhin@ford.com
> > ---
> > xen/drivers/char/console.c | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> > index a26daee9c4c4b1134d0ae3d105ffdb656340b6df..798dfdf3412a2feef35e729=
46d6c59bee59a9251 100644
> > --- a/xen/drivers/char/console.c
> > +++ b/xen/drivers/char/console.c
> > @@ -41,6 +41,9 @@
> > #ifdef CONFIG_SBSA_VUART_CONSOLE
> > #include <asm/vpl011.h>
> > #endif
> > +#if defined(CONFIG_HAS_VUART_NS8250)
> > +#include <asm/hvm/vuart_ns8250.h>
> > +#endif
> >
> > /* console: comma-separated list of console outputs. */
> > static char __initdata opt_console[30] =3D OPT_CONSOLE_STR;
> > @@ -627,6 +630,8 @@ static void handle_keypress_in_domain(struct domain=
 *d, char c)
> > {
> > #if defined(CONFIG_SBSA_VUART_CONSOLE)
> > rc =3D vpl011_rx_char_xen(d, c);
> > +#elif defined(CONFIG_HAS_VUART_NS8250)
> > + rc =3D vuart_putchar(&d->arch.hvm.vuart, c);
> > #endif
>
>
> I think it would be nicer to just use a single name and avoid ifdef-ery.
> vuart_putchar() is generic and matches domain_has_vuart(), so that
> seems good.
>
> You can then have a default stub that returns -ENODEV for when an
> implementation is not built. (This goes along with Jan's suggestion of
> a common, default domain_has_vuart().) Something like:
>
> #ifndef vuart_putchar
> static inline int vuart_putchar(struct domain *d, char c) {
> return -ENODEV;
> }
> #define vuart_putchar vuart_putchar
> #endif
>
> and ARM can do:
> #define vuart_putchar vpl011_rx_char_xen
>
> x86 would need to change its arguments, but that should be straight forwa=
rd.
>
> What do you think?

I think this is a good suggestion, I had same plans for this code, TBH.
I only planned to do that later, but now addressed in v3.
I solved it by adding arch-independent virtdev-uart.c shim, each vUART
implementation should register itself in this shim.

Fixed.

>
> Regards,
> Jason




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 03:10:32 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 03:10:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865055.1276329 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTuYZ-0004kj-83; Sat, 04 Jan 2025 03:10:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865055.1276329; Sat, 04 Jan 2025 03:10:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTuYZ-0004kc-49; Sat, 04 Jan 2025 03:10:31 +0000
Received: by outflank-mailman (input) for mailman id 865055;
 Sat, 04 Jan 2025 03:10:30 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTuYY-0004kW-Em
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 03:10:30 +0000
Received: from mail-10629.protonmail.ch (mail-10629.protonmail.ch
 [79.135.106.29]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 72f3b4f7-ca49-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 04:10:28 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 72f3b4f7-ca49-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=7fyxwhh2cnbqlkje3owrtbtyky.protonmail; t=1735960227; x=1736219427;
	bh=Ea91WjPHt+jk6cnJKHcgpo0936/C1rZ6OzNv1WJGFiU=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=FvmLdtcfl8YQGYMnQ+zsndugtbsJOb83nVxThRDA42OKpv3RqoqipG0uoBzb/9qPG
	 GF6NuVKl6UqLGWiEh+1mpItbmzEbMH4HH0cDFlz0dLUhygGqoqyCDKzfvGNqiVm4uw
	 l3aVzvG37Ehzerokg25rJWY2zxY9cZA2+ZAaXerqRJqZYq2F/hS/k/C6K9G3kvzmZV
	 QxmoWaRnpRbIK9oracpAIv9r0Y29o4SjTmg3fyh7n7oH9FVcu/mwk+3fO03jDkRbIp
	 86XrTry0rVwDcLVGPLKD6sFe7i7J7kdCpTMK5e2HdlmUrecfyS+jq5j1GW4XNNXT4j
	 pYMgrxNZtFT9g==
Date: Sat, 04 Jan 2025 03:10:24 +0000
To: =?utf-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2 01/35] xen: introduce resource.h
Message-ID: <eActpA9Scg88OPQSbzmFvok9nWeuF4gL0VTil8vAKEyhXpkeR7WrgNaXvV5GG4-IJ16_e59X6Bdoe0zae61sMkERLgdWzZki0EtDmWBjYCk=@proton.me>
In-Reply-To: <Z1lxIlvZs449Pq5-@macbook.local>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-1-e9aa923127eb@ford.com> <Z1lxIlvZs449Pq5-@macbook.local>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 439b9c49ac7b0fe448f5c10be997e2c3f5427d0e
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


On Wednesday, December 11th, 2024 at 3:01 AM, Roger Pau Monn=C3=A9 <roger.p=
au@citrix.com> wrote:

>
>
> On Thu, Dec 05, 2024 at 08:41:31PM -0800, Denis Mukhin via B4 Relay wrote=
:
>
> > From: Denis Mukhin dmukhin@ford.com
> >
> > Move resource definitions to a new architecture-agnostic shared header =
file.
> >
> > It will be used in follow on NS8250 emulator code to describe legacy
> > PC COM resources.
> >
> > Signed-off-by: Denis Mukhin dmukhin@ford.com
> > ---
> > xen/common/device-tree/device-tree.c | 21 +------------------
> > xen/drivers/passthrough/arm/smmu.c | 15 +-------------
> > xen/include/xen/resource.h | 40 ++++++++++++++++++++++++++++++++++++
> > 3 files changed, 42 insertions(+), 34 deletions(-)
> >
> > diff --git a/xen/common/device-tree/device-tree.c b/xen/common/device-t=
ree/device-tree.c
> > index d0528c5825651f7cc9ebca0c949229c9083063c6..e8f810b2fe10890c033ed3a=
9d4ca627010ad019b 100644
> > --- a/xen/common/device-tree/device-tree.c
> > +++ b/xen/common/device-tree/device-tree.c
> > @@ -24,6 +24,7 @@
> > #include <xen/ctype.h>
> > #include <asm/setup.h>
> > #include <xen/err.h>
> > +#include <xen/resource.h>
> >
> > const void *device_tree_flattened;
> > dt_irq_xlate_func dt_irq_xlate;
> > @@ -535,26 +536,6 @@ int dt_child_n_size_cells(const struct dt_device_n=
ode *parent)
> > return __dt_n_size_cells(parent, true);
> > }
> >
> > -/*
> > - * These are defined in Linux where much of this code comes from, but
> > - * are currently unused outside this file in the context of Xen.
> > - /
> > -#define IORESOURCE_BITS 0x000000ff / Bus-specific bits /
> > -
> > -#define IORESOURCE_TYPE_BITS 0x00001f00 / Resource type /
> > -#define IORESOURCE_IO 0x00000100 / PCI/ISA I/O ports /
> > -#define IORESOURCE_MEM 0x00000200
> > -#define IORESOURCE_REG 0x00000300 / Register offsets /
> > -#define IORESOURCE_IRQ 0x00000400
> > -#define IORESOURCE_DMA 0x00000800
> > -#define IORESOURCE_BUS 0x00001000
> > -
> > -#define IORESOURCE_PREFETCH 0x00002000 / No side effects /
> > -#define IORESOURCE_READONLY 0x00004000
> > -#define IORESOURCE_CACHEABLE 0x00008000
> > -#define IORESOURCE_RANGELENGTH 0x00010000
> > -#define IORESOURCE_SHADOWABLE 0x00020000
> > -
> > /
> > * Default translator (generic bus)
> > /
> > diff --git a/xen/drivers/passthrough/arm/smmu.c b/xen/drivers/passthrou=
gh/arm/smmu.c
> > index 03d22bce1e497e41834c273f9048b98dcbd48a54..aa6a968b574dce7cc753e80=
70fad3a6e585cd9e7 100644
> > --- a/xen/drivers/passthrough/arm/smmu.c
> > +++ b/xen/drivers/passthrough/arm/smmu.c
> > @@ -50,6 +50,7 @@
> > #include <xen/rbtree.h>
> > #include <xen/sched.h>
> > #include <xen/sizes.h>
> > +#include <xen/resource.h>
> > #include <asm/atomic.h>
> > #include <asm/device.h>
> > #include <asm/io.h>
> > @@ -70,22 +71,8 @@
> > #define of_property_read_u32(np, pname, out) (!dt_property_read_u32(np,=
 pname, out))
> > #define of_property_read_bool dt_property_read_bool
> > #define of_parse_phandle_with_args dt_parse_phandle_with_args
> > -
> > -/ Xen: Helpers to get device MMIO and IRQs */
> > -struct resource
> > -{
> > - paddr_t addr;
> > - paddr_t size;
> > - unsigned int type;
> > -};
> > -
> > -#define resource_size(res) (res)->size;
> > -
> > #define platform_device dt_device_node
> >
> > -#define IORESOURCE_MEM 0
> > -#define IORESOURCE_IRQ 1
> > -
> > static struct resource *platform_get_resource(struct platform_device pd=
ev,
> > unsigned int type,
> > unsigned int num)
> > diff --git a/xen/include/xen/resource.h b/xen/include/xen/resource.h
> > new file mode 100644
> > index 0000000000000000000000000000000000000000..4962e17da8387b7f3243174=
82b19cc9fe71433fc
> > --- /dev/null
> > +++ b/xen/include/xen/resource.h
> > @@ -0,0 +1,40 @@
> > +/ SPDX-License-Identifier: GPL-2.0 /
> > +/
> > + * System resource description.
> > + *
> > + * Reference:
> > + * include/linux/ioport.h
> > + /
> > +#if !defined(XEN__RESOURCE_H)
> > +#define XEN__RESOURCE_H
> > +
> > +#define IORESOURCE_BITS 0x000000FFU / Bus-specific bits /
> > +
> > +#define IORESOURCE_TYPE_BITS 0x00001F00U / Resource type /
> > +#define IORESOURCE_IO 0x00000100U / PCI/ISA I/O ports /
> > +#define IORESOURCE_MEM 0x00000200U
> > +#define IORESOURCE_REG 0x00000300U / Register offsets /
> > +#define IORESOURCE_IRQ 0x00000400U
> > +#define IORESOURCE_DMA 0x00000800U
> > +#define IORESOURCE_BUS 0x00001000U
> > +
> > +#define IORESOURCE_PREFETCH 0x00002000U / No side effects */
> > +#define IORESOURCE_READONLY 0x00004000U
> > +#define IORESOURCE_CACHEABLE 0x00008000U
> > +#define IORESOURCE_RANGELENGTH 0x00010000U
> > +#define IORESOURCE_SHADOWABLE 0x00020000U
> > +
> > +#define IORESOURCE_UNKNOWN (~0U)
> > +
> > +struct resource {
> > + paddr_t addr;
> > + paddr_t size;
> > + unsigned int type;
> > +};
> > +
> > +#define resource_size(res) (res)->size;
> > +
> > +#define foreach_resource(res) \
>
>
> Nit: we usually name those for_each_foo instead of foreach_foo.

Fixed.

>
> > + for (; res && res->type !=3D IORESOURCE_UNKNOWN; res++)
>
>
> Missing spaces between parentheses:
>
> for ( ; res && res->type !=3D IORESOURCE_UNKNOWN; res++ )

Fixed.

>
>
> Note that this macro will modify (advance) the res pointer, which is
> maybe unexpected by the caller?

For my use case I rely on res pointer advance.

>
> Also, the current logic forces the array of resources to always have a
> trailing IORESOURCE_UNKNOWN element in order to break the loop, it
> might be better to pass an explicit number of elements to iterate
> against if possible?

Current use is pretty simple, I think I will keep it as is for now.

>
> As Jan said, it would be helpful to have an example usage of the
> macro.

I moved this definition into the patch where it is first used in v3 (UART e=
mulator
patch).

>
> Thanks, Roger.




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 03:11:56 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 03:11:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865064.1276338 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTuZv-0005mQ-GJ; Sat, 04 Jan 2025 03:11:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865064.1276338; Sat, 04 Jan 2025 03:11:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTuZv-0005mJ-Dk; Sat, 04 Jan 2025 03:11:55 +0000
Received: by outflank-mailman (input) for mailman id 865064;
 Sat, 04 Jan 2025 03:11: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 <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTuZu-0005ks-Rw
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 03:11:54 +0000
Received: from mail-10630.protonmail.ch (mail-10630.protonmail.ch
 [79.135.106.30]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a60d187e-ca49-11ef-a0de-8be0dac302b0;
 Sat, 04 Jan 2025 04:11:53 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a60d187e-ca49-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1735960313; x=1736219513;
	bh=XhSfTK5A/gSSmG2o1IDtwcC/PT50mAZS/JpJ6dBm8GQ=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=UME6PSQ/KtnntOOksgHzXx5gh6azPmzVQP96edfG9xxjNg3GjCy8VmKrj2D/hORpx
	 ELL8+QU7wU3mv2m7ZlHQRt4xW8APR5EZTnXdvcVQ7fF/VVyGPcKnkdUf7Gw3tJ/mTs
	 FAWVN1njmeFBxibK3FWOdpJ6fl2FLcqWpNMvD8mSPcO+pzG9BE1RPubW7YfKhHdeSd
	 7Ksm3BooOxUQnn27bUUd1pMy5D8aLUd6MaU1//+uh3sTLs0EUcKVquc48S9QdQaVT3
	 OoqxM6IqLzCHFyPMQMCpktyXpvXbZ4NgxZNJhFd4D+0kAeJMLhlhLXcUxC0fnlxeM9
	 2c5B6TRyrTYzw==
Date: Sat, 04 Jan 2025 03:11:48 +0000
To: =?utf-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2 08/35] x86/domain: introduce domain_has_vuart()
Message-ID: <74eWstUP8IuaVVwOsb-PJlp1VQeT060VGHyjzVvq2Ph5pT3bwt_CDD4lXgeMPzJglsZpl6WA22vAnFtQaiyJiW52NrfP4lJfkDCVhjbm7Ok=@proton.me>
In-Reply-To: <Z1msGHspF2_bi3fF@macbook.local>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-8-e9aa923127eb@ford.com> <Z1msGHspF2_bi3fF@macbook.local>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 175d749523fefe69caec89d7fe10101f3b9c730d
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


On Wednesday, December 11th, 2024 at 7:13 AM, Roger Pau Monn=C3=A9 <roger.p=
au@citrix.com> wrote:

>
>
> On Thu, Dec 05, 2024 at 08:41:38PM -0800, Denis Mukhin via B4 Relay wrote=
:
>
> > From: Denis Mukhin dmukhin@ford.com
> >
> > Introduce domain_has_vuart() for x86 port to be used in the console dri=
ver.
> >
> > Signed-off-by: Denis Mukhin dmukhin@ford.com
> > ---
> > xen/arch/x86/include/asm/domain.h | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/a=
sm/domain.h
> > index b79d6badd71c4d96279555df62fad75fe817a2b6..c1d0d1f47324e8cc678a4c7=
6c43f86820a89e7b3 100644
> > --- a/xen/arch/x86/include/asm/domain.h
> > +++ b/xen/arch/x86/include/asm/domain.h
> > @@ -506,6 +506,9 @@ struct arch_domain
> > #define has_pirq(d) (!!((d)->arch.emulation_flags & X86_EMU_USE_PIRQ))
> > #define has_vpci(d) (!!((d)->arch.emulation_flags & X86_EMU_VPCI))
> >
> > +/* NB: same symbol as in Arm port */
> > +#define domain_has_vuart(d) false
>
>
> Don't you need to consume d in the macro, ie:
>
> #define domain_has_vuart(d) ((void)(d), false)

I reworked that code and merged per-arch domain_has_vuart() patches
into one arch-independent domain_has_vuart().

>
> Thanks, Roger.




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 03:12:46 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 03:12:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865074.1276349 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTuah-0006a8-Tk; Sat, 04 Jan 2025 03:12:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865074.1276349; Sat, 04 Jan 2025 03:12:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTuah-0006a1-R0; Sat, 04 Jan 2025 03:12:43 +0000
Received: by outflank-mailman (input) for mailman id 865074;
 Sat, 04 Jan 2025 03:12:42 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTuag-0006HA-Om
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 03:12:42 +0000
Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c221f18f-ca49-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 04:12:41 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c221f18f-ca49-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=btgmlqzb4baivnx3wyeuej6bpe.protonmail; t=1735960360; x=1736219560;
	bh=dAFLcwW7G2P2kfaBwRkFuIoy8ZXnlGnuB5gxMkmN+Iw=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=AfKnrYIeYvScpQmDGw41prjxFGD3+OpnZLHRf4NfoLFbvO1ITsrx9RBUS4+tocDCs
	 1eMSe/gCECFrJDechfSzCHQqMf3v3Q555nWg4mFL8AE/sV7ZtBUOF7TBTu9GtzVRZ4
	 7AzWshBcTfEelaXsJtUKC1OJIPQxBBHslNhEI5MPcfEXmYKUkwZ8G8UGpm7zC65Eur
	 +tUM0sDImYwrnRGRhkq6ykmAzSBu6Mj2braw94idyzuqHeXqKF9tKlxTKlc9vZLt1v
	 yqyLxtJmcyg+atGqERc7V7LMBgGxWlJR3DAHvdt2f2rTVorhWat/hIm17VKrRd09VZ
	 dHTyrHhINPnEQ==
Date: Sat, 04 Jan 2025 03:12:36 +0000
To: Jan Beulich <jbeulich@suse.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: Jason Andryuk <jason.andryuk@amd.com>, dmukhin@ford.com, Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 34/35] xen/console: enable console owners w/ emulated NS8250
Message-ID: <vxCKYk5B5GYFsMxpFSY4eE2gvUrxp0_7T4_z_YpwfuOHZQ4wnBJxEfDjrP_IKUSz9fQyKG9BCmO-V568UTnzSiF0OGzrCSeDpZAdYromYTg=@proton.me>
In-Reply-To: <9fbe795c-f580-4084-9ab4-dede708cd777@suse.com>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-34-e9aa923127eb@ford.com> <1b55c7eb-3e39-43d1-80d2-2d4caf6a0c76@amd.com> <9fbe795c-f580-4084-9ab4-dede708cd777@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: e0ccbc4846f3e492c9bc2bf13c7172af6462e607
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


On Tuesday, December 10th, 2024 at 11:38 PM, Jan Beulich <jbeulich@suse.com=
> wrote:

>
>
> On 10.12.2024 23:46, Jason Andryuk wrote:
>
> > On 2024-12-05 23:42, Denis Mukhin via B4 Relay wrote:
> >
> > > From: Denis Mukhin dmukhin@ford.com
> > >
> > > Enable console focus for domains w/ virtual NS8250.
> > >
> > > Code change allows to capture the output from the guest OS now and se=
nd it to
> > > the physical console device.
> > >
> > > Signed-off-by: Denis Mukhin dmukhin@ford.com
> > > ---
> > > xen/drivers/char/console.c | 5 +++++
> > > 1 file changed, 5 insertions(+)
> > >
> > > diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> > > index a26daee9c4c4b1134d0ae3d105ffdb656340b6df..798dfdf3412a2feef35e7=
2946d6c59bee59a9251 100644
> > > --- a/xen/drivers/char/console.c
> > > +++ b/xen/drivers/char/console.c
> > > @@ -41,6 +41,9 @@
> > > #ifdef CONFIG_SBSA_VUART_CONSOLE
> > > #include <asm/vpl011.h>
> > > #endif
> > > +#if defined(CONFIG_HAS_VUART_NS8250)
> > > +#include <asm/hvm/vuart_ns8250.h>
> > > +#endif
> > >
> > > /* console: comma-separated list of console outputs. */
> > > static char __initdata opt_console[30] =3D OPT_CONSOLE_STR;
> > > @@ -627,6 +630,8 @@ static void handle_keypress_in_domain(struct doma=
in *d, char c)
> > > {
> > > #if defined(CONFIG_SBSA_VUART_CONSOLE)
> > > rc =3D vpl011_rx_char_xen(d, c);
> > > +#elif defined(CONFIG_HAS_VUART_NS8250)
> > > + rc =3D vuart_putchar(&d->arch.hvm.vuart, c);
> > > #endif
> >
> > I think it would be nicer to just use a single name and avoid ifdef-ery=
.
> > vuart_putchar() is generic and matches domain_has_vuart(), so that
> > seems good.
> >
> > You can then have a default stub that returns -ENODEV for when an
> > implementation is not built. (This goes along with Jan's suggestion of
> > a common, default domain_has_vuart().) Something like:
> >
> > #ifndef vuart_putchar
> > static inline int vuart_putchar(struct domain *d, char c) {
> > return -ENODEV;
> > }
> > #define vuart_putchar vuart_putchar
> > #endif
> >
> > and ARM can do:
> > #define vuart_putchar vpl011_rx_char_xen
> >
> > x86 would need to change its arguments, but that should be straight for=
ward.
>
>
> Actually, I don't even see a need for the stub:
>
> {
> #ifdef vuart_putchar
> rc =3D vuart_putchar(d, c);
> #endif
> }
>
> This way behavior won't change from what there is now, when vuart_putchar=
()
> isn't defined.

I solved it by adding some arch-independent code for "virtual UARTs" in v3,=
 which,
IMO, looks a cleaner solution.

>
> Jan




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 03:13:26 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 03:13:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865083.1276359 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTubO-0007Ik-68; Sat, 04 Jan 2025 03:13:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865083.1276359; Sat, 04 Jan 2025 03:13:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTubO-0007Id-2T; Sat, 04 Jan 2025 03:13:26 +0000
Received: by outflank-mailman (input) for mailman id 865083;
 Sat, 04 Jan 2025 03:13:24 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTubM-0006ss-T7
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 03:13:24 +0000
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id dbb9883e-ca49-11ef-a0de-8be0dac302b0;
 Sat, 04 Jan 2025 04:13:24 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: dbb9883e-ca49-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1735960403; x=1736219603;
	bh=eZ5XN1Od9jDl3bzrn4IBqWAaoVUHMZflED0a42ZDhpw=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=gcE+QFvRS3KBetsl2LtnKMwL6w91aGzDLoowvbRj8HuIxYLOw0VAetI7x5jd8yjRR
	 azxFwGBKNrMb4uIRtwlbNrHrNn1I8PpzFhd+P79/mjxEzL7JIlNv/9rJgUsTLzWTWM
	 6rec6R7G6khsDYUmPyWSaT70yry+6hhblRYVavJnsg6SnFmu+4hZlIYJ8VXtg+v3eD
	 SuAMnvpSSfKQF6LPCK7sFPYvPFJux73BV4q4d5f4+V8MzTXj+yDAPvWaDMEcUYwJN3
	 NWUrNdyLtUUuQEUcYB2ve6Hd3VWRWD24UhE4pIvzAlSRU0PAEZ4QvrckvO8gXT9VMt
	 +CZBvFgrOb4WQ==
Date: Sat, 04 Jan 2025 03:13:19 +0000
To: =?utf-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2 11/35] xen/domain: enable max_init_domid for all architectures
Message-ID: <K9tt8q37d5lEHovaX8-DkjNQQYtsdSqhaSH2z6vIRPVH405-iADFg7dMGSmv9ggLiQ189BZPdIUetijriVQH68FjIGMhpzChE1QQXzxV2uM=@proton.me>
In-Reply-To: <Z1nFPw5889vC_MLX@macbook.local>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-11-e9aa923127eb@ford.com> <Z1nFPw5889vC_MLX@macbook.local>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 4b9ae78126a7d37c62ebbdd1a6788db13647493d
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Wednesday, December 11th, 2024 at 9:00 AM, Roger Pau Monn=C3=A9 <roger.p=
au@citrix.com> wrote:

>
>
> On Thu, Dec 05, 2024 at 08:41:41PM -0800, Denis Mukhin via B4 Relay wrote=
:
>
> > From: Denis Mukhin dmukhin@ford.com
> >
> > Move max_init_domid to a public API and enable for all architectures.
> > That is pre-requisite change for console focus switch logic cleanup.
> >
> > max_init_domid is updated in domain_create().
> >
> > Signed-off-by: Denis Mukhin dmukhin@ford.com
> > ---
> > xen/arch/arm/include/asm/setup.h | 2 --
> > xen/arch/arm/setup.c | 2 --
> > xen/arch/ppc/include/asm/setup.h | 2 --
> > xen/arch/riscv/include/asm/setup.h | 2 --
> > xen/arch/x86/include/asm/setup.h | 2 --
> > xen/common/domain.c | 9 +++++++++
> > xen/include/xen/domain.h | 2 ++
> > 7 files changed, 11 insertions(+), 10 deletions(-)
> >
> > diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/as=
m/setup.h
> > index 64c227d171fc7b92e5b62d9fd42e5662871bd12b..d4e1670cd69cdd4475b2a5e=
b316d2c0601090ed7 100644
> > --- a/xen/arch/arm/include/asm/setup.h
> > +++ b/xen/arch/arm/include/asm/setup.h
> > @@ -19,8 +19,6 @@ struct map_range_data
> > struct rangeset *irq_ranges;
> > };
> >
> > -extern domid_t max_init_domid;
> > -
> > void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
> >
> > size_t estimate_efi_size(unsigned int mem_nr_banks);
> > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> > index 2e27af4560a504bf57daef572d4a768bd886145b..cb218fe3eb36f2cdda47cfa=
092fa99ee1ca4a14c 100644
> > --- a/xen/arch/arm/setup.c
> > +++ b/xen/arch/arm/setup.c
> > @@ -58,8 +58,6 @@ struct cpuinfo_arm __read_mostly system_cpuinfo;
> > bool __read_mostly acpi_disabled;
> > #endif
> >
> > -domid_t __read_mostly max_init_domid;
> > -
> > static __used void init_done(void)
> > {
> > int rc;
> > diff --git a/xen/arch/ppc/include/asm/setup.h b/xen/arch/ppc/include/as=
m/setup.h
> > index e4f64879b68ca5aac24bd9544255143e6ef693f3..956fa6985adb23375bd41d3=
e5d34d9d5f0712bd5 100644
> > --- a/xen/arch/ppc/include/asm/setup.h
> > +++ b/xen/arch/ppc/include/asm/setup.h
> > @@ -1,6 +1,4 @@
> > #ifndef ASM_PPC_SETUP_H
> > #define ASM_PPC_SETUP_H
> >
> > -#define max_init_domid (0)
> > -
> > #endif /* ASM_PPC_SETUP_H */
> > diff --git a/xen/arch/riscv/include/asm/setup.h b/xen/arch/riscv/includ=
e/asm/setup.h
> > index 844a2f0ef1d762b3a9bc90b61a336a23f1693cc9..978cad71d3df484e80ba19a=
cc0e37b9278e941f0 100644
> > --- a/xen/arch/riscv/include/asm/setup.h
> > +++ b/xen/arch/riscv/include/asm/setup.h
> > @@ -3,8 +3,6 @@
> > #ifndef ASM__RISCV__SETUP_H
> > #define ASM__RISCV__SETUP_H
> >
> > -#define max_init_domid (0)
> > -
> > void setup_mm(void);
> >
> > #endif /* ASM__RISCV__SETUP_H */
> > diff --git a/xen/arch/x86/include/asm/setup.h b/xen/arch/x86/include/as=
m/setup.h
> > index 5c2391a8684b66efdf4b092409ed33935db6b40c..296348655b9d146c73acc30=
5cc9edd5fd46f7d47 100644
> > --- a/xen/arch/x86/include/asm/setup.h
> > +++ b/xen/arch/x86/include/asm/setup.h
> > @@ -69,6 +69,4 @@ extern bool opt_dom0_verbose;
> > extern bool opt_dom0_cpuid_faulting;
> > extern bool opt_dom0_msr_relaxed;
> >
> > -#define max_init_domid (0)
> > -
> > #endif
> > diff --git a/xen/common/domain.c b/xen/common/domain.c
> > index 2f67aa06ed50e69c27cedc8d7f6eb0b469fe81cd..9e57dd4122a726e2fb42efe=
9c029e775202be0e6 100644
> > --- a/xen/common/domain.c
> > +++ b/xen/common/domain.c
> > @@ -65,6 +65,9 @@ DEFINE_RCU_READ_LOCK(domlist_read_lock);
> > static struct domain *domain_hash[DOMAIN_HASH_SIZE];
> > struct domain *domain_list;
> >
> > +/* Last known non-system domain ID. */
> > +domid_t __read_mostly max_init_domid;
>
>
> The comment (and implementation below) seems to differ from what Arm
> dom0less code currently uses the variable for.

Yep, thanks.
I realized that after receiving Jan's feedback.

Reworked.

>
> > +
> > /*
> > * Insert a domain into the domlist/hash. This allows the domain to be l=
ooked
> > * up by domid, and therefore to be the subject of hypercalls/etc.
> > @@ -815,6 +818,12 @@ struct domain *domain_create(domid_t domid,
> >
> > memcpy(d->handle, config->handle, sizeof(d->handle));
> >
> > + /*
> > + * Housekeeping for physical console forwarding to the domain.
> > + */
> > + if ( !is_system_domain(d) && max_init_domid < domid )
> > + max_init_domid =3D domid;
>
>
> Don't you need to adjust the ARM dom0-less logic that deal with
> increasing max_init_domid in create_domUs().
>
> Also max_init_domid likely only wants to be updated for domains
> created before the control domain is started, and hence could be
> __ro_after_init instead of __read_mostly?

I addressed that in v3, thanks!

>
> Thanks, Roger.




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 03:13:57 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 03:13:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865089.1276369 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTubt-0007wf-E9; Sat, 04 Jan 2025 03:13:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865089.1276369; Sat, 04 Jan 2025 03:13:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTubt-0007wY-A6; Sat, 04 Jan 2025 03:13:57 +0000
Received: by outflank-mailman (input) for mailman id 865089;
 Sat, 04 Jan 2025 03:13:55 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTubr-0007hm-LX
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 03:13:55 +0000
Received: from mail-10630.protonmail.ch (mail-10630.protonmail.ch
 [79.135.106.30]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id edb86ef0-ca49-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 04:13:54 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: edb86ef0-ca49-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1735960433; x=1736219633;
	bh=z2slTAQFzwI3MM+uvLyfM4Vn8np/AtB0nRN7UsNFGOo=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=Il2tFOYIBj4m+LWwgBi7ApKM9DrBjAITOUQK4kdvdzuPL5mkAt/aK5G2DpSB1O/vx
	 Gv6/Lqpp9HvYhTAneFwGuWF8fMBij8TUKz6EYq4swAbadXdYKYCWjW5B3mXqCqafWs
	 RC42oTs0ktzSednXSupAAgMTNgOifXJ/19r+85yl0KwfvPjZdfnd4s4yMmkwoOKFgN
	 gz1JcgvcAcjp477JRC7W/rsvEwozKCACBg8vOljhBUvpZLqM7uHxm2ICrlzVphej8D
	 W7BBm6Qc3W9PLdZePfOILy2Rw86k/XG0POnjwInGvnQJc+MciJKO7R1NDMkxyh3Ivp
	 rs6Cz1jCl1Ngg==
Date: Sat, 04 Jan 2025 03:13:51 +0000
To: =?utf-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2 13/35] xen/console: rename console_input_domain
Message-ID: <FSdDLvEuYjM9G8HzVbm6G-r6N8J2RSPq455KkZRRnsbYdTG7NvirNs8ya79yKaDQ0g5hyBMxQqsnkGl0JxrWUY3ditIW9R_lNQXwE5Hc4pk=@proton.me>
In-Reply-To: <Z1nJNqfqAgYd0pJ7@macbook.local>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-13-e9aa923127eb@ford.com> <Z1nJNqfqAgYd0pJ7@macbook.local>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 9b62e47d2776b2a1c939c3392fb41aec756f9189
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Wednesday, December 11th, 2024 at 9:17 AM, Roger Pau Monn=C3=A9 <roger.p=
au@citrix.com> wrote:

>
>
> On Thu, Dec 05, 2024 at 08:41:43PM -0800, Denis Mukhin via B4 Relay wrote=
:
>
> > From: Denis Mukhin dmukhin@ford.com
> >
> > console_input_domain() takes an RCU lock to protect domain structure.
> > That implies call to rcu_unlock_domain() after use.
> >
> > Rename console_input_domain() to rcu_lock_domain_console_owner() to
> > highlight the need of calling rcu_unlock_domain().
> >
> > Signed-off-by: Denis Mukhin dmukhin@ford.com
> > ---
> > xen/arch/arm/vpl011.c | 2 +-
> > xen/drivers/char/console.c | 2 +-
> > xen/include/xen/console.h | 2 +-
> > 3 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
> > index fe36fe2bd1529a4114884580ded6d6fa55a22f0e..4d682e98553303b4a12f5cd=
7e5e67ab096cd7cc2 100644
> > --- a/xen/arch/arm/vpl011.c
> > +++ b/xen/arch/arm/vpl011.c
> > @@ -78,7 +78,7 @@ static void vpl011_write_data_xen(struct domain *d, u=
int8_t data)
> > unsigned long flags;
> > struct vpl011 *vpl011 =3D &d->arch.vpl011;
> > struct vpl011_xen_backend *intf =3D vpl011->backend.xen;
> > - struct domain *input =3D console_input_domain();
> > + struct domain *input =3D rcu_lock_domain_console_owner();
>
>
> May I suggest console_get_domain() and then introducing a
> console_put_domain() which is just a wrapper around
> rcu_unlock_domain()?

Agreed, that looks even better! Thanks.

Fixed.

>
> Thanks, Roger.




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 03:14:45 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 03:14:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865099.1276379 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTuce-0008Vn-LD; Sat, 04 Jan 2025 03:14:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865099.1276379; Sat, 04 Jan 2025 03:14:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTuce-0008Vd-IL; Sat, 04 Jan 2025 03:14:44 +0000
Received: by outflank-mailman (input) for mailman id 865099;
 Sat, 04 Jan 2025 03:14: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 <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTuce-0008Th-1O
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 03:14:44 +0000
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0b0ed275-ca4a-11ef-a0de-8be0dac302b0;
 Sat, 04 Jan 2025 04:14:43 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 0b0ed275-ca4a-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1735960481; x=1736219681;
	bh=D1ssMuDmIJSpNwfMTnSXVzZ5KkJWdueZcgrK5R+JnHQ=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=JlJ9mL+JMb3A/gW7qO1y738KYQ799+nUqTEa5m6lypGsXKRWPbsxYbp6YYTnFNYWO
	 xbdtD4nJdJpjq5vvKPM93FAEmSmJwBk+Rhq3ewR5lgiMcA6Y/hr6UiOnzW0ZlMtcdr
	 2puE6KsBoYpzsyQuQhrkPhqMRfSD+nhPcKapxUsm29KWBU45q32vxcp174SoMamUb8
	 pkxsq7gxTSKCl8LkzRqUAaHexqD2z+J7PojHCnWw5PUMyVA0u6bQ4FseaQST3i4MHp
	 dwBzMRDaT3DEfOqX7xLTHqXoHetClC/vmDRu4Z3uHfIcGYa+pEJHqzAIiQD4S2zjRh
	 85zwaIM6gh17w==
Date: Sat, 04 Jan 2025 03:14:36 +0000
To: =?utf-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: Jan Beulich <jbeulich@suse.com>, dmukhin@ford.com, Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 14/35] xen/console: rename switch_serial_input() to console_find_owner()
Message-ID: <VUeBPTQ1ejbYSp84LPJEtoNjpaXuZQ_G9ohq4bPJGkMIpbzQ_NbcvvlpFwK9iwUd8-HrNGqLp9sqpMAqFfUPtUfZGPEpI-9CmzVw-R9DZlI=@proton.me>
In-Reply-To: <Z1nKX2oK6-nIh2XH@macbook.local>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-14-e9aa923127eb@ford.com> <eb9246cc-059d-4dca-aca8-e75976537206@suse.com> <Z1nKX2oK6-nIh2XH@macbook.local>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 2caaa00d7ce899463471de875c35e85f46402aaf
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Wednesday, December 11th, 2024 at 9:22 AM, Roger Pau Monn=C3=A9 <roger.p=
au@citrix.com> wrote:

>
>
> On Tue, Dec 10, 2024 at 03:13:20PM +0100, Jan Beulich wrote:
>
> > On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
> >
> > > From: Denis Mukhin dmukhin@ford.com
> > >
> > > Updated the name to highlight the logic of selection the physical con=
sole
> > > owner: existing code does not switch only serial console, it also swi=
tches
> > > video console and debugging console (debug I/O port and console hyper=
call).
> >
> > I'm especially surprised you mention "video console" here. Afaics all o=
f
> > this is only about console input, and no input comes from a video devic=
e.
> > Arguably "serial" in the original name is too narrow now. Yet "input"
> > continues to be quite appropriate.
>
>
> switch_console_input() maybe? switch_console_input_target() even?
>
> I think the switch is also relevant, as it shuffles the input around,
> console_find_owner() doesn't seem to convey that meaning.

Renamed to console_switch_input() in v3

>
> Thanks, Roger.




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 03:20:28 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 03:20:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865111.1276389 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTui7-0001eW-8e; Sat, 04 Jan 2025 03:20:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865111.1276389; Sat, 04 Jan 2025 03:20:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTui7-0001eP-4t; Sat, 04 Jan 2025 03:20:23 +0000
Received: by outflank-mailman (input) for mailman id 865111;
 Sat, 04 Jan 2025 03:20:22 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTui6-0001eJ-1Z
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 03:20:22 +0000
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d3a5fefa-ca4a-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 04:20:20 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: d3a5fefa-ca4a-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=kafcvoyzdvfdxbldp7omazadba.protonmail; t=1735960819; x=1736220019;
	bh=ihGJ95yurdl3a7kTBGElK3kbwYrkKC1BWLX+mbqQQQY=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=U8FECD9EwUBBzXTiiIfvxLPT6Unme+ZXf16q4+ZmpbQZIEOIUYw9rgZ4CBO/ihO+q
	 /U+aMG29p5khuY9uikTBmiJ3/RGf4Rdfi7ZECSH/7wFUzqwcLUxxn1Tm0+Yg+L3G9H
	 edymumO5Cft8gTfYKSthT5z/Kv7GpGKfSw3hArBEnIh6pOhZmbyBhPZvSChAQq5dmx
	 z7QiS5lKC9zmOD/Oqh24XXYqN0picRL7/YC83cwrdLfzYy5zINvTDcu/0x693UeI31
	 fRgpr8ln8t+ENu5FNvSBVumEVFZOLtzqusz98CjwcnsWk+5FyBbspev0uX1hRcnuL3
	 0ZdOyxt/+1V8A==
Date: Sat, 04 Jan 2025 03:20:14 +0000
To: =?utf-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2 15/35] xen/console: rename console_rx to console_owner
Message-ID: <HnZWfX88Uh_W5-10yEQRV4vfLrfLW6URZX7Yl7cKAh3XQIBrY-3UJR57dErrwKOJYdN57thD_lawLrY-cq4hZvL0F4t41bQQLk00Lxr-n0Q=@proton.me>
In-Reply-To: <Z1qlt5YLzxwawXq_@macbook.local>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-15-e9aa923127eb@ford.com> <Z1qlt5YLzxwawXq_@macbook.local>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 7057af3659e9bbea3e7b19401a03b7c67a52600f
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Thursday, December 12th, 2024 at 12:58 AM, Roger Pau Monn=C3=A9 <roger.p=
au@citrix.com> wrote:

>
>
> On Thu, Dec 05, 2024 at 08:41:45PM -0800, Denis Mukhin via B4 Relay wrote=
:
>
> > From: Denis Mukhin dmukhin@ford.com
> >
> > Preparation for the follow on change to switch console_owner to
> > domid_t address space.
>
>
> I'm a bit confused, is the plan to assign the console (so both RX and
> TX) exclusively to a domain?

The name change is because semantics of console_rx will be changed.
It will be pointing to domain ID instead of an integer number mapped
to domain ID.
I think "console owner" should be easier to follow.

>
> Otherwise this would better be named console_input_target or similar,
> if you think console_rx is not clear enough (FWIW, I'm OK with the
> name given the current usage).
>
> Thanks, Roger.




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 03:21:30 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 03:21:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865118.1276398 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTujB-0002ZC-GV; Sat, 04 Jan 2025 03:21:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865118.1276398; Sat, 04 Jan 2025 03:21:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTujB-0002Z5-Dp; Sat, 04 Jan 2025 03:21:29 +0000
Received: by outflank-mailman (input) for mailman id 865118;
 Sat, 04 Jan 2025 03:21:28 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTujA-0002Xk-5B
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 03:21:28 +0000
Received: from mail-10630.protonmail.ch (mail-10630.protonmail.ch
 [79.135.106.30]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id fafda4a3-ca4a-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 04:21:26 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: fafda4a3-ca4a-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=i5ncakhrgjdddmshelq34qb43q.protonmail; t=1735960884; x=1736220084;
	bh=853xcxLbwv8zMwLmBBcwy0rSep7ENCS0+2oSbM3itU4=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=X6j0fcQJNhiqmYHKL9VZMMNZDPSRNA+kafjAIHnrbB2NRQudy9AlvXMNBIEFwUP7b
	 Vgutt58T9awgfdpbuE9nWW+Ru1PAhFYTrh6Eia8JDBHIVm0tvt1aRYcBLNi3dD6adb
	 ahCVJAra8+PJ3rMsxuY5iE9UnTAxX3tMV3cWz5M7YXm4dlzBNJS2csQKkk7qFgQQPr
	 BQGNP2gv9UBJb5la8v9iUSd6C8tWi9Acwno3tscqPObNN1bhf+1ma3yU1eOs01pIvj
	 VWUU8DyfBOHxIQPeLYw/4W4ViUit0a56wO299SCFXshe94QD4KH+bBvVnQkws9eHkm
	 VPDmB+uOvlxrw==
Date: Sat, 04 Jan 2025 03:21:21 +0000
To: =?utf-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2 17/35] xen/console: introduce consoled_is_enabled()
Message-ID: <SMjSlxoJE3GxrhEztgVjKv27aQPczVxoIdqROw1ZHGd_pI6XGFC7aSGiBIAT73u5AnGNgDYHRBVZAivetgmknoKYz1KP8KHyf0K_qMwzxag=@proton.me>
In-Reply-To: <Z1qtYO9Kr-9bzwEh@macbook.local>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-17-e9aa923127eb@ford.com> <Z1qtYO9Kr-9bzwEh@macbook.local>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 008483f02403bf4544509fa4674efc9c8d12f6f0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Thursday, December 12th, 2024 at 1:31 AM, Roger Pau Monn=C3=A9 <roger.pa=
u@citrix.com> wrote:

>
>
> On Thu, Dec 05, 2024 at 08:41:47PM -0800, Denis Mukhin via B4 Relay wrote=
:
>
> > From: Denis Mukhin dmukhin@ford.com
> >
> > There are few places which check pv_shim console under CONFIG_PV_SHIM i=
n xen
> > console driver. Instead of #ifdef-ing, use new consoled_is_enabled() to
> > customize the logic.
> >
> > Header file now can be included w/o CONFIG_X86.
> >
> > Signature of consoled_guest_{rx,tx} has changed to account for follow-o=
n
> > console switch logic cleanup.
> >
> > Signed-off-by: Denis Mukhin dmukhin@ford.com
> > ---
> > xen/drivers/char/console.c | 10 +++-------
> > xen/drivers/char/consoled.c | 18 ++++++++++++++----
> > xen/include/xen/consoled.h | 35 +++++++++++++++++++++++++++++++++--
> > 3 files changed, 50 insertions(+), 13 deletions(-)
> >
> > diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> > index f034ce5aab3f3bf59b0df9fa583ee9ce32dbf665..60c055396b697869b04b913=
2b0dcfa832fabe932 100644
> > --- a/xen/drivers/char/console.c
> > +++ b/xen/drivers/char/console.c
> > @@ -33,9 +33,9 @@
> > #include <xen/pv_console.h>
> > #include <asm/setup.h>
> > #include <xen/sections.h>
> > +#include <xen/consoled.h>
> >
> > #ifdef CONFIG_X86
> > -#include <xen/consoled.h>
> > #include <asm/guest.h>
> > #endif
> > #ifdef CONFIG_SBSA_VUART_CONSOLE
> > @@ -505,11 +505,9 @@ static void console_find_owner(void)
> > break;
> > }
> >
> > -#ifdef CONFIG_PV_SHIM
> > - if ( next_rx =3D=3D 1 )
> > + if ( consoled_is_enabled() && next_rx =3D=3D 1 )
> > domid =3D get_initial_domain_id();
> > else
> > -#endif
> > domid =3D next_rx - 1;
> > d =3D rcu_lock_domain_by_id(domid);
> > if ( d )
> > @@ -573,10 +571,8 @@ static void __serial_rx(char c)
> > #endif
> > }
> >
> > -#ifdef CONFIG_X86
> > - if ( pv_shim && pv_console )
> > + if ( consoled_is_enabled() )
> > consoled_guest_tx(c);
> > -#endif
> > }
> >
> > static void cf_check serial_rx(char c)
> > diff --git a/xen/drivers/char/consoled.c b/xen/drivers/char/consoled.c
> > index b415b632cecc0a80e161b701d7b70ba4f3cc5fb8..d6624e7697f56e1a1959b0e=
fa5dca104f34af002 100644
> > --- a/xen/drivers/char/consoled.c
> > +++ b/xen/drivers/char/consoled.c
> > @@ -43,13 +43,13 @@ struct xencons_interface *consoled_get_ring_addr(vo=
id)
> > static char buf[BUF_SZ + 1];
> >
> > /* Receives characters from a domain's PV console */
> > -void consoled_guest_rx(void)
> > +int consoled_guest_rx(void)
> > {
> > size_t idx =3D 0;
> > XENCONS_RING_IDX cons, prod;
> >
> > if ( !cons_ring )
> > - return;
> > + return 0;
> >
> > spin_lock(&rx_lock);
> >
> > @@ -91,15 +91,17 @@ void consoled_guest_rx(void)
> >
> > out:
> > spin_unlock(&rx_lock);
> > +
> > + return 0;
> > }
> >
> > /* Sends a character into a domain's PV console */
> > -void consoled_guest_tx(char c)
> > +int consoled_guest_tx(char c)
> > {
> > XENCONS_RING_IDX cons, prod;
> >
> > if ( !cons_ring )
> > - return;
> > + return 0;
> >
> > cons =3D ACCESS_ONCE(cons_ring->in_cons);
> > prod =3D cons_ring->in_prod;
> > @@ -118,6 +120,7 @@ void consoled_guest_tx(char c)
> >
> > cons_ring->in[MASK_XENCONS_IDX(prod++, cons_ring->in)] =3D c;
> >
> > +
> > /* Write to the ring before updating the pointer /
> > smp_wmb();
> > ACCESS_ONCE(cons_ring->in_prod) =3D prod;
> > @@ -125,6 +128,13 @@ void consoled_guest_tx(char c)
> > notify:
> > / Always notify the guest: prevents receive path from getting stuck. */
> > pv_shim_inject_evtchn(pv_console_evtchn());
> > +
> > + return 0;
> > +}
> > +
> > +bool consoled_is_enabled(void)
> > +{
> > + return pv_shim && pv_console;
> > }
> >
> > /*
> > diff --git a/xen/include/xen/consoled.h b/xen/include/xen/consoled.h
> > index bd7ab6329ee8a7c466484021247241ded8ed03c7..696677fa5a3be458a0ec933=
60e08376c3471f95b 100644
> > --- a/xen/include/xen/consoled.h
> > +++ b/xen/include/xen/consoled.h
> > @@ -3,10 +3,41 @@
> >
> > #include <public/io/console.h>
> >
> > +#if defined(CONFIG_PV_SHIM)
> > +
> > void consoled_set_ring_addr(struct xencons_interface *ring);
> > struct xencons_interface *consoled_get_ring_addr(void);
> > -void consoled_guest_rx(void);
> > -void consoled_guest_tx(char c);
> > +int consoled_guest_rx(void);
> > +int consoled_guest_tx(char c);
> > +bool consoled_is_enabled(void);
> > +
> > +#else
> > +
> > +static inline void consoled_set_ring_addr(struct xencons_interface *ri=
ng)
> > +{
> > +}
> > +
> > +static inline struct xencons_interface *consoled_get_ring_addr(void)
> > +{
> > + return NULL;
> > +}
> > +
> > +static inline int consoled_guest_rx(void)
> > +{
> > + return 0;
> > +}
>
>
> You don't need to provide dummy implementations of
> consoled_{set,get}_ring_addr() and consoled_guest_rx(), they are only
> called from code that's build when CONFIG_PV_SHIM is selected.

Thanks; fixed.

>
> > +static inline int consoled_guest_tx(char c)
> > +{
> > + return 0;
>
>
> For consoled_guest_tx() you want to add an ASSERT_UNREACHABLE(), as
> it should never be called if !CONFIG_PV_SHIM?

Fixed.

>
> Thanks, Roger.




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 03:22:14 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 03:22:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865126.1276409 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTujt-0003VX-TC; Sat, 04 Jan 2025 03:22:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865126.1276409; Sat, 04 Jan 2025 03:22:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTujt-0003VQ-PZ; Sat, 04 Jan 2025 03:22:13 +0000
Received: by outflank-mailman (input) for mailman id 865126;
 Sat, 04 Jan 2025 03:22:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTujr-0003TY-SN
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 03:22:11 +0000
Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch
 [185.70.40.134]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 15bfe244-ca4b-11ef-a0de-8be0dac302b0;
 Sat, 04 Jan 2025 04:22:10 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 15bfe244-ca4b-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1735960930; x=1736220130;
	bh=60b7b8pCQscBiiojU0VCIPvXex4KqmvkFey65uK8Zws=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=hKAkmtpGxYStlExWAS36v9F/wxb/zPlW2XRH5cWPRFS22Ys4t00X6FrgeBlSwJN32
	 6jMuHzhZVfDVWFaECWNL5eVVF/QOrNESQKUlaRFyPMxhl4PfQG4/WmNnqFR9QXm/ho
	 RhRuMLBZzsupAb15Fs2mQwS8ejphijbtEvLMDC9VrjJ7KJxNjgoLB9g8EjB4DXX6mO
	 JyReBU857RvpmO4QeKHUIQs6wpM4hv/cz/IyEhyc7sYdW3RVKvOIIoJSEYjGFi0daI
	 eaZJqv83+SZlxeZEgLll0P8tCXuuFc2Piay8Ka7MiSblc8PWAnpldVtd/oPsIRckVv
	 LOU7ixSpM3w9g==
Date: Sat, 04 Jan 2025 03:22:05 +0000
To: Jan Beulich <jbeulich@suse.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 21/35] xen/console: introduce console_init_owner()
Message-ID: <Ak6C4enLcSkraItT-41clT-s3Z5GNRGNF7B55ZrJiaS6pND0bt1PLihHZ1ENb2hgJCVJWDOgrlxhlXcJ6ErP7EfhcOeUzbczPwfUBLC6_lM=@proton.me>
In-Reply-To: <be92d586-0185-4753-8f30-2c7fd92f01dd@suse.com>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-21-e9aa923127eb@ford.com> <be92d586-0185-4753-8f30-2c7fd92f01dd@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 347feed7118373b4e9c4b6134901ee8573de8c19
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


On Tuesday, December 10th, 2024 at 11:31 PM, Jan Beulich <jbeulich@suse.com=
> wrote:

>
>
> On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
>
> > --- a/xen/drivers/char/console.c
> > +++ b/xen/drivers/char/console.c
> > @@ -554,6 +554,22 @@ static void console_find_owner(void)
> > console_set_owner(DOMID_XEN);
> > }
> >
> > +static void console_init_owner(void)
> > +{
> > + domid_t domid;
> > +
> > + /*
> > + * If user specifies so, we fool the switch routine to redirect input
> > + * straight back to Xen.
> > + */
> > + if ( opt_conswitch[1] =3D=3D 'x' )
> > + domid =3D DOMID_XEN;
> > + else
> > + domid =3D get_initial_domain_id();
> > +
> > + console_set_owner(domid);
> > +}
>
>
> Is this function meant to gain a 2nd user? If not, what exactly is the go=
al
> of introducing this new function?

I cannot foresee the second user.
My rationale was moving all console ownership initialization into one place
so the code is better localized.

>
> If the function's addition is warranted, it wants to be __init, matching =
...

I ended up dropping the patch in v3.

>
> > @@ -1160,8 +1168,7 @@ void __init console_endboot(void)
> > register_irq_keyhandler('G', &do_toggle_guest,
> > "toggle host/guest log level adjustment", 0);
> >
> > - /* Serial input is directed to DOM0 by default. */
> > - console_find_owner();
> > + console_init_owner();
> > }
>
>
> ... sole caller.
>
> Jan




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 03:23:37 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 03:23:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865136.1276418 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTulE-0004Gc-5i; Sat, 04 Jan 2025 03:23:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865136.1276418; Sat, 04 Jan 2025 03:23:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTulE-0004GV-3A; Sat, 04 Jan 2025 03:23:36 +0000
Received: by outflank-mailman (input) for mailman id 865136;
 Sat, 04 Jan 2025 03:23:34 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTulC-0004GJ-1j
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 03:23:34 +0000
Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch
 [185.70.40.134]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 46299bfb-ca4b-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 04:23:32 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 46299bfb-ca4b-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1735961011; x=1736220211;
	bh=wSlvcvz7YaxKsrcRmxXl53lexT/W3qQfPGAYeSHaIFI=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=TbNdSfFfKaiY51TITzaMKnnDs7pf0w1XcZ0yHTP7rmIp8McFaKss7DBAJoVSVPPS0
	 tq+2CKQ8ipcca/MKDscChxp/FTx0s9ymEsTrBLk6eBStOo9+Mw64/YWlXzQDDoOqT0
	 VDkvR+UZanoxd4I1JJbv3Dt0YwqhxOYo6GQxuJFQWlJCm9ze4MK+T6v3fEJEtOX3Wt
	 P2sA3/zG/ork0iTOv2b6RFJYyZ+M8Z5rI26pvTawmocsOdr/jrrSLuaziJEcoDBSji
	 S1qSTHSrJxGALnmA7KijJRllDozhZBGyB7tkp9T+BFcFwW5DNCbIfhggosHb39vFY/
	 OqUcA1KwljItA==
Date: Sat, 04 Jan 2025 03:23:24 +0000
To: =?utf-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2 21/35] xen/console: introduce console_init_owner()
Message-ID: <lMx7K935PGMAY1vvXEQXe2hhN_55g1m_0VBZngzoddGl2zVl9uvxh2BSZgSAkE5n6gmtBVXWs_r42k69E1cTf6kDj_1Tx-ndx3N_H01w40Y=@proton.me>
In-Reply-To: <Z1q5v3XkBo1VxT4p@macbook.local>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-21-e9aa923127eb@ford.com> <Z1q5v3XkBo1VxT4p@macbook.local>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 8797bec7533a5505a073afdaffee2b8ce230457e
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Thursday, December 12th, 2024 at 2:23 AM, Roger Pau Monn=C3=A9 <roger.pa=
u@citrix.com> wrote:

>
>
> On Thu, Dec 05, 2024 at 08:41:51PM -0800, Denis Mukhin via B4 Relay wrote=
:
>
> > From: Denis Mukhin dmukhin@ford.com
> >
> > console_init_owner() is introduced for selecting the boot-time console =
owner.
> >
> > Signed-off-by: Denis Mukhin dmukhin@ford.com
> > ---
> > xen/drivers/char/console.c | 27 +++++++++++++++++----------
> > 1 file changed, 17 insertions(+), 10 deletions(-)
> >
> > diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> > index a8ab5c2bcb98e4cadf9ad2c9ad28d297977d0557..6261bdb5a2ac1075bc89fa4=
08c0fd6cfef380ae6 100644
> > --- a/xen/drivers/char/console.c
> > +++ b/xen/drivers/char/console.c
> > @@ -554,6 +554,22 @@ static void console_find_owner(void)
> > console_set_owner(DOMID_XEN);
> > }
> >
> > +static void console_init_owner(void)
>
>
> __init attribute missing (given current call context), but see below.
>
> > +{
> > + domid_t domid;
> > +
> > + /*
> > + * If user specifies so, we fool the switch routine to redirect input
> > + * straight back to Xen.
> > + */
> > + if ( opt_conswitch[1] =3D=3D 'x' )
> > + domid =3D DOMID_XEN;
> > + else
> > + domid =3D get_initial_domain_id();
> > +
> > + console_set_owner(domid);
> > +}
> > +
> > static void __serial_rx(char c)
> > {
> > switch ( console_owner )
> > @@ -1143,14 +1159,6 @@ void __init console_endboot(void)
> >
> > video_endboot();
> >
> > - /*
> > - * If user specifies so, we fool the switch routine to redirect input
> > - * straight back to Xen. I use this convoluted method so we still prin=
t
> > - * a useful 'how to switch' message.
> > - */
> > - if ( opt_conswitch[1] =3D=3D 'x' )
> > - console_owner =3D DOMID_XEN;
> > -
> > register_keyhandler('w', dump_console_ring_key,
> > "synchronously dump console ring buffer (dmesg)", 0);
> > register_irq_keyhandler('+', &do_inc_thresh,
> > @@ -1160,8 +1168,7 @@ void __init console_endboot(void)
> > register_irq_keyhandler('G', &do_toggle_guest,
> > "toggle host/guest log level adjustment", 0);
> >
> > - /* Serial input is directed to DOM0 by default. */
> > - console_find_owner();
> > + console_init_owner();
>
>
> Oh, so this is what fixes the regression introduced in patch 19/35.
> THB I'm not sure it's worth introducing the console_init_owner()
> helper if it's just for this usage. You could do:
>
> console_set_owner(opt_conswitch[1] =3D=3D 'x' ? DOMID_XEN
> : get_initial_domain_id());

Right, thank you.
Addressed in v3.

>
> Thanks, Roger.




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 03:25:58 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 03:25:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865145.1276429 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTunS-0004pU-HJ; Sat, 04 Jan 2025 03:25:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865145.1276429; Sat, 04 Jan 2025 03:25:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTunS-0004pN-E9; Sat, 04 Jan 2025 03:25:54 +0000
Received: by outflank-mailman (input) for mailman id 865145;
 Sat, 04 Jan 2025 03:25: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 <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTunR-0004pH-6y
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 03:25:53 +0000
Received: from mail-10630.protonmail.ch (mail-10630.protonmail.ch
 [79.135.106.30]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9916942e-ca4b-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 04:25:51 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9916942e-ca4b-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1735961150; x=1736220350;
	bh=ZqvdAzQRVUdyXekI041PtKo/lVVHva43F0eF5q4Wf+s=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=VtkZYuhbMLaF23mOgP3h9AuEIrDmaoMM8iHawXRNsyh12OB/HtVoAbJFkseDew/dP
	 dhW3Wlby93ut+DCffGmmOfCd7WvoXRE7jhAsrKMYbMiSyTu+YITJo1fTNQGr8LYLa8
	 4RvKpuJ6lG66YE/QO+CYH8yDv1q7Wk0fkhBnFoPPvPZ6e29rcFBLd3bMyc7PW1Rmjo
	 JXErW9Wsh3qgry4775Dehv/cyLSdv5l6RfJdT9VUYIYx6pW0hwNjbamxQtiWp1NZVU
	 JqVe7hYASTq1v1b7Vx79JpLkbRmFl98d28Ng7OnxyvJZXtQv9GyM2vG5evUFVO4qPS
	 xRsGrauhgAJ+g==
Date: Sat, 04 Jan 2025 03:25:44 +0000
To: =?utf-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2 22/35] xen/console: introduce handle_keypress_in_domain()
Message-ID: <l_g6VhEL4IeDKa54dVzpLQ6e3hPk5jyvFhPfFOnplJFSy3OT-kFvfSqa6PuRJIr1HL58WfNomF7u6Rlzuoz2pwwm-1q_7eU8GHh_qeOh17I=@proton.me>
In-Reply-To: <Z1rAJwSJvD-6rtM7@macbook.local>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-22-e9aa923127eb@ford.com> <Z1rAJwSJvD-6rtM7@macbook.local>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 31f05cccb46846b28f406896ad0e5c3cb02f4dba
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Thursday, December 12th, 2024 at 2:51 AM, Roger Pau Monn=C3=A9 <roger.pa=
u@citrix.com> wrote:

>
>
> On Thu, Dec 05, 2024 at 08:41:52PM -0800, Denis Mukhin via B4 Relay wrote=
:
>
> > From: Denis Mukhin dmukhin@ford.com
> >
> > With introduction of NS8250 emulator for x86, the logic of switching co=
nsole
> > focus gets more convoluted: HVM domain w/ NS8205 must be able to receiv=
e the
> > physical console input for guest VM debugging.
> >
> > Also, existing code does not honor `hardware_dom=3D` xen command line p=
arameter
> > (hardware domain ID does not necessarily starts from 0).
> >
> > Introduce handle_keypress_in_domain() to account for all scenarios of c=
onsole
> > input forwarding.
> >
> > Signed-off-by: Denis Mukhin dmukhin@ford.com
> > ---
> > xen/drivers/char/console.c | 72 +++++++++++++++++++++++++++------------=
-------
> > 1 file changed, 42 insertions(+), 30 deletions(-)
> >
> > diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> > index 6261bdb5a2ac1075bc89fa408c0fd6cfef380ae6..ce3639a4cdcda00ea63e3bf=
119bc3b242cbfdf6a 100644
> > --- a/xen/drivers/char/console.c
> > +++ b/xen/drivers/char/console.c
> > @@ -570,14 +570,16 @@ static void console_init_owner(void)
> > console_set_owner(domid);
> > }
> >
> > -static void __serial_rx(char c)
> > +static void handle_keypress_in_domain(struct domain *d, char c)
> > {
> > - switch ( console_owner )
> > - {
> > - case DOMID_XEN:
> > - return handle_keypress(c, false);
> > + int rc =3D 0;
> >
> > - case 0:
> > + /*
> > + * Deliver input to the hardware domain buffer.
> > + * NB: must be the first check: hardware domain may have emulated UART=
.
> > + */
> > + if ( d =3D=3D hardware_domain )
>
>
> is_hardware_domain(d)

Fixed.

>
> > + {
> > /*
> > * Deliver input to the hardware domain buffer, unless it is
> > * already full.
> > @@ -590,34 +592,44 @@ static void __serial_rx(char c)
> > * getting stuck.
> > */
> > send_global_virq(VIRQ_CONSOLE);
> > - break;
> > -
> > -#ifdef CONFIG_SBSA_VUART_CONSOLE
> > - default:
> > - {
> > - struct domain d =3D rcu_lock_domain_by_id(console_owner);
> > -
> > - /
> > - * If we have a properly initialized vpl011 console for the
> > - * domain, without a full PV ring to Dom0 (in that case input
> > - * comes from the PV ring), then send the character to it.
> > - /
> > - if ( d !=3D NULL )
> > - vpl011_rx_char_xen(d, c);
> > - else
> > - printk("Cannot send chars to Dom%d: no UART available\n",
> > - console_owner);
> > -
> > - if ( d !=3D NULL )
> > - rcu_unlock_domain(d);
> > -
> > - break;
> > }
> > + /
> > + * Deliver input to the emulated UART.
> > + */
>
>
> For one-line comments you can use:
> /* Deliver input to the emulated UART. */

Fixed.

>
> I would however place the comment inside the `if` body.

Sure, no problem. Fixed.

>
> > + else if ( domain_has_vuart(d) )
> > + {
> > +#if defined(CONFIG_SBSA_VUART_CONSOLE)
> > + rc =3D vpl011_rx_char_xen(d, c);
> > #endif
>
>
> You can possibly make the preprocessor conditional also contain the
> if condition itself? As otherwise the if condition is dead code.

I removed the ifdef in v3 and reworked domain_has_vuart()
so that it checks build flag and d->arch.emulated_flags under the hood.

>
> > }
> > -
> > + /*
> > + * Deliver input to the PV shim console.
> > + */
> > if ( consoled_is_enabled() )
> > - consoled_guest_tx(c);
> > + rc =3D consoled_guest_tx(c);
> > +
> > + if ( rc && rc !=3D -ENODEV )
> > + printk(KERN_WARNING "console input domain %d: not ready: %d\n",
> > + d->domain_id, rc);
>
>
> XENLOG_ERR instead of KERN_WARNING, and use %pd to print domains, ie:

Addressed.

>
> printk(XENLOG_ERR "%pd: delivery of console input failed: %d\n",
> d, rc);
>
> And I wonder whether this should be printed just once per domain,
> or whether the domain should be marked as not having a console
> (is_console =3D false) after delivery of input keys failed.
>
> Otherwise you could spam the console with such error messages on every
> serial key press.

Thanks; fixed.

>
> > +}
> > +
> > +static void __serial_rx(char c)
> > +{
> > + struct domain *d;
> > +
> > + if ( console_owner =3D=3D DOMID_XEN )
> > + {
> > + handle_keypress(c, false);
> > + return;
> > + }
> > +
> > + d =3D rcu_lock_domain_console_owner();
> > + if ( d =3D=3D NULL )
> > + return;
> > +
> > + handle_keypress_in_domain(d, c);
>
>
> Is __serial_rx() the only caller of handle_keypress_in_domain() after
> the series? If so, I'm not sure it's worth placing this logic in a
> separate function.

Yep, that is the only caller; fixed.

>
> Thanks, Roger.




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 03:30:52 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 03:30:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865154.1276438 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTusE-0006S3-1m; Sat, 04 Jan 2025 03:30:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865154.1276438; Sat, 04 Jan 2025 03:30:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTusD-0006Rw-VG; Sat, 04 Jan 2025 03:30:49 +0000
Received: by outflank-mailman (input) for mailman id 865154;
 Sat, 04 Jan 2025 03:30:49 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTusC-0006KV-2m
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 03:30:49 +0000
Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch
 [185.70.40.133]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 48f80ef8-ca4c-11ef-a0de-8be0dac302b0;
 Sat, 04 Jan 2025 04:30:46 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 48f80ef8-ca4c-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=s7ibhm7tszfylmv2bzkghwvaqi.protonmail; t=1735961444; x=1736220644;
	bh=7sJpwoc7SabuRRSJdzdClF0vEc0inNR6LdstjmlKaUs=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=MrRZKslsSgFSW4Jn0QBhCw2A1OOK8v07M7YbjntdYI+tliupGm1FdcvlIABzA4jko
	 lz4UZAkvj97Wkj5vAwHRR/v25vfGrPYcaVBsDB/0nv6LNW4/CB36fe7Xkb1srIgSuW
	 wGZc2+jJQgAwmtcyH+ElufLII37Y8lFYh7czydxLuGs+6qkSYNzByQFmLMIp3w67v2
	 gQigJEbTH+Y6tLu+dMtVjM3E7c3U5S7SZNpXuZmE1kjhcoLeUuKSORNMI7oD/vreTK
	 sD+2DZjhEBgbTcEKp6gLe/U77jtPyQPHPaDeHBmc9OlWXMsYb0moQEZFPH9uvCYZYD
	 8622WU2Zs62/w==
Date: Sat, 04 Jan 2025 03:30:40 +0000
To: =?utf-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2 19/35] xen/console: introduce console_set_owner()
Message-ID: <Nzs8m4tgOs8mh44axM9sAfsp2GGMk34p5Oi0dtXh8rLbKzHXmMtMXK_d_AJy-gSQuGRygaZbsvhy9QFvsCc0yyMiqzXslUNID1os1CCzNrA=@proton.me>
In-Reply-To: <Z1q3COsFN3J9G60E@macbook.local>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-19-e9aa923127eb@ford.com> <Z1q3COsFN3J9G60E@macbook.local>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: d86023204dae09867087e1731bfec1b25d222f43
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Thursday, December 12th, 2024 at 2:12 AM, Roger Pau Monn=C3=A9 <roger.pa=
u@citrix.com> wrote:

>
>
> On Thu, Dec 05, 2024 at 08:41:49PM -0800, Denis Mukhin via B4 Relay wrote=
:
>
> > From: Denis Mukhin dmukhin@ford.com
> >
> > console_set_owner() is introduced for setting the new console owner.
> >
> > Switches console owner to domain ID vs range of integer numbers mapped =
to
> > domain IDs.
> >
> > This a public API to console driver, will be used in the follow on code=
 change.
> >
> > Signed-off-by: Denis Mukhin dmukhin@ford.com
> > ---
> > xen/drivers/char/console.c | 122 ++++++++++++++++++++++++++------------=
-------
> > xen/include/xen/console.h | 1 +
> > 2 files changed, 71 insertions(+), 52 deletions(-)
> >
> > diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> > index 8cbac54c66044ae8581e486a782102b75c8bfaa9..52cf64dbf6fd18d599cb888=
35d03501a23b3e3c4 100644
> > --- a/xen/drivers/char/console.c
> > +++ b/xen/drivers/char/console.c
> > @@ -463,82 +463,100 @@ static void cf_check dump_console_ring_key(unsig=
ned char key)
> >
> > /*
> > * CTRL-<switch_char> changes input direction, rotating among Xen, Dom0,
> > - * and the DomUs started from Xen at boot.
> > + * and the DomUs.
> > /
> > #define switch_code (opt_conswitch[0]-'a'+1)
> > +
> > /
> > - * console_owner=3D0 =3D> input to xen
> > - * console_owner=3D1 =3D> input to dom0 (or the sole shim domain)
> > - * console_owner=3DN =3D> input to dom(N-1)
> > + * Current console owner domain ID: either Xen or domain w/ d->is_cons=
ole =3D=3D
> > + * true.
> > + *
> > + * Initialized in console_endboot().
> > */
> > -static unsigned int __read_mostly console_owner =3D 0;
> > +static domid_t __read_mostly console_owner;
>
>
> Should this be initialized to DOMID_XEN? I assume it doesn't make
> much difference because the variable is not checked before
> console_endboot() anyway, but it might be safer to initialize to a
> value that assigns the console to Xen.

Fixed.

>
> > -#define max_console_rx (max_init_domid + 1)
> > +static struct domain *rcu_lock_domain_console_by_id(domid_t domid)
> > +{
> > + struct domain *d;
> > +
> > + d =3D rcu_lock_domain_by_id(domid);
> > +
>
>
> Nit: I would remove this newline.

Fixed.

>
> > + if ( d =3D=3D NULL )
> > + return NULL;
> > +
> > + if ( d->is_console )
> > + return d;
> > +
> > + rcu_unlock_domain(d);
> > +
> > + return NULL;
> > +}
> >
> > -#ifdef CONFIG_SBSA_VUART_CONSOLE
> > /* Make sure to rcu_unlock_domain after use */
> > struct domain *rcu_lock_domain_console_owner(void)
> > {
> > - if ( console_owner =3D=3D 0 )
> > - return NULL;
> > - return rcu_lock_domain_by_id(console_owner - 1);
> > + return rcu_lock_domain_console_by_id(console_owner);
> > }
> > -#endif
> >
> > -static void console_find_owner(void)
> > +static bool console_owner_possible(domid_t domid)
> > {
> > - unsigned int next_rx =3D console_owner;
> > -
> > - /*
> > - * Rotate among Xen, dom0 and boot-time created domUs while skipping
> > - * switching serial input to non existing domains.
> > - /
> > - for ( ; ; )
> > - {
> > - domid_t domid;
> > - struct domain d;
> > -
> > - if ( next_rx++ >=3D max_console_rx )
> > - {
> > - console_owner =3D 0;
> > - printk("* Serial input to Xen");
> > - break;
> > - }
> > -
> > - if ( consoled_is_enabled() && next_rx =3D=3D 1 )
> > - domid =3D get_initial_domain_id();
> > - else
> > - domid =3D next_rx - 1;
> > -
> > - d =3D rcu_lock_domain_by_id(domid);
> > - if ( d =3D=3D NULL )
> > - continue;
> > -
> > - if ( d->is_console )
> > - {
> > - rcu_unlock_domain(d);
> > - console_owner =3D next_rx;
> > - printk("*** Serial input to DOM%u", domid);
> > - break;
> > - }
> > + struct domain *d;
> >
> > + d =3D rcu_lock_domain_console_by_id(domid);
> > + if ( d !=3D NULL )
> > rcu_unlock_domain(d);
> > - }
> > +
> > + return d !=3D NULL;
> > +}
> > +
> > +int console_set_owner(domid_t domid)
> > +{
> > + if ( domid =3D=3D DOMID_XEN )
> > + printk("*** Serial input to Xen");
> > + else if ( console_owner_possible(domid) )
> > + printk("*** Serial input to DOM%u", domid);
> > + else
> > + return -ENOENT;
> > +
> > + console_owner =3D domid;
> >
> > if ( switch_code )
> > printk(" (type 'CTRL-%c' three times to switch input)",
> > opt_conswitch[0]);
> > printk("\n");
> > +
> > + return 0;
> > +}
> > +
> > +/*
> > + * Switch console input focus.
> > + * Rotates input focus among Xen, dom0 and boot-time created domUs whi=
le
> > + * skipping switching serial input to non existing domains.
> > + */
> > +static void console_find_owner(void)
> > +{
> > + domid_t i, n =3D max_init_domid + 1;
>
>
> n can be made const, I would even rename to nr for clarity, but that's
> personal taste.

`max_init_domid` can change at run-time actually (e.g. after `xl create`).
I kept `n` as is.

>
> > +
> > + if ( console_owner =3D=3D DOMID_XEN )
> > + i =3D get_initial_domain_id();
> > + else
> > + i =3D console_owner + 1;
> > +
> > + for ( ; i < n; i++ )
> > + if ( !console_set_owner(i) )
> > + break;
>
>
> Hm, that could be a non-trivial amount of iteration if max_init_domid
> is bumped for every domain created as you have it in patch 11/35
> (albeit I'm not sure that was intended?)

Yes, `max_init_domid` is advanced on each domain creation (v3).

>
> > + if ( i =3D=3D n )
> > + console_set_owner(DOMID_XEN);
> > }
> >
> > static void __serial_rx(char c)
> > {
> > switch ( console_owner )
> > {
> > - case 0:
> > + case DOMID_XEN:
> > return handle_keypress(c, false);
> >
> > - case 1:
> > + case 0:
>
>
> If console_owner now strictly contains a domid you cannot assume that
> domid 0 is the hardware domain, you will need to handle this
> differently and check whether the domain pointed by console_owner
> passes the is_hardware_domain() check.

Fixed.

>
> > /*
> > * Deliver input to the hardware domain buffer, unless it is
> > * already full.
> > @@ -556,7 +574,7 @@ static void __serial_rx(char c)
> > #ifdef CONFIG_SBSA_VUART_CONSOLE
> > default:
> > {
> > - struct domain *d =3D rcu_lock_domain_by_id(console_owner - 1);
> > + struct domain *d =3D rcu_lock_domain_by_id(console_owner);
> >
> > /*
> > * If we have a properly initialized vpl011 console for the
> > @@ -567,7 +585,7 @@ static void __serial_rx(char c)
> > vpl011_rx_char_xen(d, c);
> > else
> > printk("Cannot send chars to Dom%d: no UART available\n",
> > - console_owner - 1);
> > + console_owner);
> >
> > if ( d !=3D NULL )
> > rcu_unlock_domain(d);
> > @@ -1126,7 +1144,7 @@ void __init console_endboot(void)
> > * a useful 'how to switch' message.
> > */
> > if ( opt_conswitch[1] =3D=3D 'x' )
> > - console_owner =3D max_console_rx;
> > + console_owner =3D DOMID_XEN;
>
>
> Hm, are you sure this still works as expected? Setting console_owner
> =3D=3D DOMID_XEN will cause the call to switch_serial_input() below to
> switch the console back to the first domain in the system. Also
> initializing console_owner to 0 by default would also cause the call
> to switch_serial_input() to possibly switch it to the first domain
> after domid 0 (or back to Xen).

TBH, I did not test w/ conswitch=3Dx originally, but after addressing
your other feedback that is now fixed.
Thank you.

>
> Thanks, Roger.




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 03:31:19 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 03:31:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865160.1276449 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTuse-000738-Bt; Sat, 04 Jan 2025 03:31:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865160.1276449; Sat, 04 Jan 2025 03:31:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTuse-000731-7T; Sat, 04 Jan 2025 03:31:16 +0000
Received: by outflank-mailman (input) for mailman id 865160;
 Sat, 04 Jan 2025 03:31: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 <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTusc-0006nz-Nl
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 03:31:14 +0000
Received: from mail-10628.protonmail.ch (mail-10628.protonmail.ch
 [79.135.106.28]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 58f3724c-ca4c-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 04:31:13 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 58f3724c-ca4c-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1735961472; x=1736220672;
	bh=TfPSx5ToGr+1+gRSVRuQXLSfHDgwTqVOv5KcTZJnjy0=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=Lp2NmLRJkns/gBV790oE+iQ/clqOxT9Ie/ujpn06zUUrrXLYbPYm5C8mroRC/ikpo
	 c3p0zDsuBTaas57ar68MzawnFjB4XIYLLTKyq+VEGhO2fPAi4WDzUw7xhO34mgDOE1
	 1/czknU7KzWkuHd64ZdZ05UU+s334/mD+82WFAxsXKxvt/nXIvJEPLGtzzIVWIwdLe
	 4XoPfS7RFMcBoC0l+cMbA9eQYfqnlZ9mFFx6kNbYLuyNP7s3RsPQ2aEFtZNPT5XOZM
	 yR95+lkBO3Fd5WysfpgWacuMwzaKkQlSQj8cJe6OcxMG82JbtORhyCENCoC1xsGd/8
	 fjE3ZCYYKsn0Q==
Date: Sat, 04 Jan 2025 03:31:08 +0000
To: Jan Beulich <jbeulich@suse.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: =?utf-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, dmukhin@ford.com, xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2 19/35] xen/console: introduce console_set_owner()
Message-ID: <JnsgSWx03iGL2Y2dOfX0jA5b-MEkVTsIDcFAGjL55U9kZf4icDMolB42jqTNEiYtKHE05iN2gsohoHN2aA8sS_j2NdRh1onXjNxOahpx91o=@proton.me>
In-Reply-To: <1e36f66b-a423-428c-9b22-8fd58450f119@suse.com>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-19-e9aa923127eb@ford.com> <Z1q3COsFN3J9G60E@macbook.local> <1e36f66b-a423-428c-9b22-8fd58450f119@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: b2eba51675b0283a0c00e449f3838b172397dc16
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Thursday, December 12th, 2024 at 3:59 AM, Jan Beulich <jbeulich@suse.com=
> wrote:

>
>
> On 12.12.2024 11:12, Roger Pau Monn=C3=A9 wrote:
>
> > On Thu, Dec 05, 2024 at 08:41:49PM -0800, Denis Mukhin via B4 Relay wro=
te:
> >
> > > +static struct domain *rcu_lock_domain_console_by_id(domid_t domid)
> > > +{
> > > + struct domain *d;
> > > +
> > > + d =3D rcu_lock_domain_by_id(domid);
> > > +
> >
> > Nit: I would remove this newline.
>
>
> Or even better make the function call the variable's initializer.

Fixed.

>
> Jan




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 03:51:08 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 03:51:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865174.1276458 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTvBl-0002l9-2o; Sat, 04 Jan 2025 03:51:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865174.1276458; Sat, 04 Jan 2025 03:51:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTvBk-0002kF-W3; Sat, 04 Jan 2025 03:51:00 +0000
Received: by outflank-mailman (input) for mailman id 865174;
 Sat, 04 Jan 2025 03:50:59 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTvBi-0002k4-By
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 03:50:59 +0000
Received: from mail-40131.protonmail.ch (mail-40131.protonmail.ch
 [185.70.40.131]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 19c9950a-ca4f-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 04:50:55 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 19c9950a-ca4f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1735962654; x=1736221854;
	bh=whCBYl2yJcM1+Tm9Zub/cKAhE1c0VZkIoUrRKzkJ82Q=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=AnIDC+kg7x3GmMHofzLehRlHczL80n7zvDdlYg5zT7RDCuxqmXedFbhJ0aD0awP7r
	 DkdPsOFEADihiUHEXJzdDjG1n4uZQw+7HF2WAbiVgH9Xzs4AK0wYPzt1SIVhryvrqR
	 KmuoeDrwJfjv/TZ7U9rYpZWJGkcxcFlsWCCQsFQIvbTL2H5x4/3CwCCZwTNgUtdN+o
	 RbvBUvoWBQDtmJ50GpFjMJH6F78KL74QD6CrU+ulnnG1eSYJJkXT6bFmYgjF4gtKbO
	 ujZ3AfZwpE9XFLgmn/+kBTyDmcgjBtbqDMyj5wpgZJ7dkAGqVx29DxucgvfrtIgvI/
	 wStFI85LsnOhA==
Date: Sat, 04 Jan 2025 03:50:51 +0000
To: =?utf-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2 23/35] xen/console: introduce console_write()
Message-ID: <EqrIYfurxlsHxbvi0NaMYW6XGmmy8x1xXk1tWeOsLqb5FriS8i2hCnxP_vNKFspMZ_dRf_Yb2_JpYsfGC9isPk_2t4L4Xj4sHBc-GkXwQUk=@proton.me>
In-Reply-To: <Z1rRWAWzC1pnD3PW@macbook.local>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-23-e9aa923127eb@ford.com> <Z1rRWAWzC1pnD3PW@macbook.local>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 2cd02ada5ff27473fa3e9c47e2a77f6d6ddb43df
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Thursday, December 12th, 2024 at 4:04 AM, Roger Pau Monn=C3=A9 <roger.pa=
u@citrix.com> wrote:

>
>
> On Thu, Dec 05, 2024 at 08:41:53PM -0800, Denis Mukhin via B4 Relay wrote=
:
>
> > From: Denis Mukhin dmukhin@ford.com
> >
> > PV Linux kernel uses HYPERVISOR_console_io hypercall for early console =
which
> > ends up being handled by Xen's console driver's guest_console_write().
> >
> > guest_console_write() duplicates the code from __putstr(), elimitate co=
de
> > duplication.
>
>
> It might be better to split the code that unifies
> guest_console_write() and __putstr() as a non-functional change.
> While the introduction of use_conring is likely a functional change.

Actually `use_conring` is not needed.
guest_console_write() depends on `opt_console_to_ring` to call
conring_puts() while __putstr() has unconditional call to conring_puts().
I solved this by adding another parameter to console_write().

>
> > Signed-off-by: Denis Mukhin dmukhin@ford.com
> > ---
> > xen/drivers/char/console.c | 97 +++++++++++++++++++++++++--------------=
-------
> > 1 file changed, 53 insertions(+), 44 deletions(-)
> >
> > diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> > index ce3639a4cdcda00ea63e3bf119bc3b242cbfdf6a..115967d179998cba4a81578=
caba09db4e4aca7f7 100644
> > --- a/xen/drivers/char/console.c
> > +++ b/xen/drivers/char/console.c
> > @@ -63,6 +63,8 @@ static const char __initconst warning_sync_console[] =
=3D
> > "However it can introduce SIGNIFICANT latencies and affect\n"
> > "timekeeping. It is NOT recommended for production use!\n";
> >
> > +/* Flag: use conring for early console; switches to opt_console_to_rin=
g */
> > +static bool __read_mostly use_conring =3D true;
>
>
> __ro_after_init instead of __read_mostly.

I dropped use_conring.

>
> > /* console_to_ring: send guest (incl. dom 0) console data to console ri=
ng. */
> > static bool __read_mostly opt_console_to_ring;
> > boolean_param("console_to_ring", opt_console_to_ring);
> > @@ -661,6 +663,16 @@ static void cf_check notify_dom0_con_ring(void *un=
used)
> > static DECLARE_SOFTIRQ_TASKLET(notify_dom0_con_ring_tasklet,
> > notify_dom0_con_ring, NULL);
> >
> > +static bool console_locks_busted;
> > +
> > +static void conring_write(const char *str, size_t len)
> > +{
> > + conring_puts(str, len);
> > +
> > + if ( !console_locks_busted )
> > + tasklet_schedule(&notify_dom0_con_ring_tasklet);
> > +}
> > +
> > #ifdef CONFIG_X86
> > static inline void xen_console_write_debug_port(const char *buf, size_t=
 len)
> > {
> > @@ -669,8 +681,44 @@ static inline void xen_console_write_debug_port(co=
nst char *buf, size_t len)
> > : "=3D&S" (tmp), "=3D&c" (tmp)
> > : "0" (buf), "1" (len), "d" (XEN_HVM_DEBUGCONS_IOPORT) );
> > }
> > +
> > +static void xen_console_write(const char *str, size_t len)
> > +{
> > + if ( xen_guest )
> > + xen_hypercall_console_write(str, len);
> > + else
> > + xen_console_write_debug_port(str, len);
> > +}
> > +#else
> > +static inline void xen_console_write(const char *str, size_t len)
> > +{
>
>
> opt_console_xen would only be set on x86 with the current command line
> parsing done in console_init_preirq(), so you could add an
> ASSERT_UNREACHABLE() here.

I re-arranged the code, `static inline` variant is not needed.

>
> > +}
> > #endif
> >
> > +/*
> > + * Write characters to console.
> > + *
> > + * That will handle all possible scenarios working w/ console
> > + * - serial console;
> > + * - video output;
> > + * - __HYPERVISOR_console_io hypercall (x86 only);
> > + * - debug I/O port (x86 only);
> > + * - forward to Xen event channel.
>
>
> "Xen event channel" is not the correct term. I would use "PV
> console". The event channel is just used to send the notification.

Thank you; fixed.

>
> > + */
> > +static void console_write(const char *str, size_t len)
> > +{
> > + ASSERT(rspin_is_locked(&console_lock));
> > +
> > + console_serial_puts(str, len);
> > + video_puts(str, len);
> > +
> > + if ( opt_console_xen )
> > + xen_console_write(str, len);
>
>
> Are you sure this builds? opt_console_xen is only defined on x86, and
> AFAICT console_write() is generic. AFAICT you need to keep the X86
> preprocessor guards, or alternatively do something like:

This is strange; CI did pass on that:
   https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/1576164352
Fixed.

>
> #define opt_console_xen false
>
> For non-x86 arches in xen/console.h
>
> > +
> > + if ( use_conring )
> > + conring_write(str, len);
> > +}
> > +
> > static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer,
> > unsigned int count)
> > {
> > @@ -691,28 +739,8 @@ static long guest_console_write(XEN_GUEST_HANDLE_P=
ARAM(char) buffer,
> >
> > if ( is_hardware_domain(cd) )
> > {
> > - /* Use direct console output as it could be interactive */
> > nrspin_lock_irq(&console_lock);
> > -
> > - console_serial_puts(kbuf, kcount);
> > - video_puts(kbuf, kcount);
> > -
> > -#ifdef CONFIG_X86
> > - if ( opt_console_xen )
> > - {
> > - if ( xen_guest )
> > - xen_hypercall_console_write(kbuf, kcount);
> > - else
> > - xen_console_write_debug_port(kbuf, kcount);
> > - }
> > -#endif
> > -
> > - if ( opt_console_to_ring )
> > - {
> > - conring_puts(kbuf, kcount);
> > - tasklet_schedule(&notify_dom0_con_ring_tasklet);
> > - }
> > -
> > + console_write(kbuf, kcount);
> > nrspin_unlock_irq(&console_lock);
> > }
> > else
> > @@ -813,31 +841,9 @@ long do_console_io(
> > * *****************************************************
> > */
> >
> > -static bool console_locks_busted;
> > -
> > static void __putstr(const char *str)
> > {
> > - size_t len =3D strlen(str);
> > -
> > - ASSERT(rspin_is_locked(&console_lock));
> > -
> > - console_serial_puts(str, len);
> > - video_puts(str, len);
> > -
> > -#ifdef CONFIG_X86
> > - if ( opt_console_xen )
> > - {
> > - if ( xen_guest )
> > - xen_hypercall_console_write(str, len);
> > - else
> > - xen_console_write_debug_port(str, len);
> > - }
> > -#endif
> > -
> > - conring_puts(str, len);
> > -
> > - if ( !console_locks_busted )
> > - tasklet_schedule(&notify_dom0_con_ring_tasklet);
> > + console_write(str, strlen(str));
> > }
> >
> > static int printk_prefix_check(char *p, char **pp)
> > @@ -1171,6 +1177,9 @@ void __init console_endboot(void)
> >
> > video_endboot();
> >
> > + use_conring =3D opt_console_to_ring;
> > + smp_wmb();
>
>
> Do you really need the barrier? If so it would need a comment
> describing exactly why it's needed. I don't think it's possible for
> the write to be reordered past the return of the function, which would
> be enough to ensure correctness?

I see where I got confused: the right place to add this initialization was
console_init_postirq(). I dropped the barrier and of `use_conring` altogeth=
er.

>
> Thanks, Roger.




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 03:53:05 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 03:53:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865182.1276469 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTvDk-0003bu-E9; Sat, 04 Jan 2025 03:53:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865182.1276469; Sat, 04 Jan 2025 03:53:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTvDk-0003bn-BN; Sat, 04 Jan 2025 03:53:04 +0000
Received: by outflank-mailman (input) for mailman id 865182;
 Sat, 04 Jan 2025 03:53:03 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTvDj-0003bh-K9
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 03:53:03 +0000
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 64df3f91-ca4f-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 04:53:01 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 64df3f91-ca4f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1735962780; x=1736221980;
	bh=B2gwmZyTNt9tyjaUiAL4BHtCtvcyHNUIsJnOypJw97A=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=FmIT5gPIbhTzSBybpMwbGoC7B5xNy/8pi09pBBhyl3134iEg8c9Z7PUkq3WFCwHTE
	 1rRR6bNYPVV3z11oNeMKAG3sKIeMTcAaaAsgNJRzBqevaLRx8CykVJ6uiNC7uEKmU0
	 zA90gfHSKeYY6Z1GDkWd3WbC/T/oaXJ7f3FQJkzvGkOe64RMPGHNHcHO8ZsxevVY6s
	 Z+PFOtYUmf3i8hH54MgBdrtzMa8brpi91/hyjF1axPLyrGN9eQqRakpr95mBf6P3Z8
	 PN45ysHrOEQag/FTHBa+JsV2t3sPUjTRcvi+TPFdcnYg8cO4DP3hxotYFmo28iQt7W
	 LWGeXjORpPlaw==
Date: Sat, 04 Jan 2025 03:52:56 +0000
To: =?utf-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2 26/35] xen/console: make console buffer size configurable
Message-ID: <JLKNDjLF5s0cdPbzZ2z-sJuRrVgd0dxSpuJ5hL3lk29_wW0afRZIhQuGeV10w3dlLhoKk8GwLcUBpkuyVbH779_PjZsLoMEu8Ev4I2SCK-M=@proton.me>
In-Reply-To: <Z1rbUfLQolFdMoi6@macbook.local>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-26-e9aa923127eb@ford.com> <Z1rbUfLQolFdMoi6@macbook.local>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 8545cfebbef9543a4b28c35d67b61325da6591dd
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Thursday, December 12th, 2024 at 4:47 AM, Roger Pau Monn=C3=A9 <roger.pa=
u@citrix.com> wrote:

>
>
> On Thu, Dec 05, 2024 at 08:41:56PM -0800, Denis Mukhin via B4 Relay wrote=
:
>
> > From: Denis Mukhin dmukhin@ford.com
> >
> > Add new CONRING_LOG_SHIFT Kconfig parameter to specify the boot console=
 buffer
> > size as a power of 2.
> >
> > Bump default size to 32 KiB.
> >
> > Link: https://gitlab.com/xen-project/xen/-/issues/185
> > Signed-off-by: Denis Mukhin dmukhin@ford.com
>
>
> Thanks for taking care of this.
>
> > ---
> > xen/drivers/char/Kconfig | 23 +++++++++++++++++++++++
> > xen/drivers/char/console.c | 4 ++--
> > 2 files changed, 25 insertions(+), 2 deletions(-)
> >
> > diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
> > index e6e12bb4139717f9319031f51f5d20155d2caee2..3bc892fc38d8cdeb3c76ea4=
4d747f712a8d0d372 100644
> > --- a/xen/drivers/char/Kconfig
> > +++ b/xen/drivers/char/Kconfig
> > @@ -96,6 +96,29 @@ config SERIAL_TX_BUFSIZE
> >
> > Default value is 32768 (32KiB).
> >
> > +config CONRING_LOG_SHIFT
> > + int "Console buffer size"
> > + range 14 25
> > + default 15
> > + help
> > + Select the boot console buffer size as a power of 2.
> > + Run-time console buffer size is the same as the boot console size,
> > + unless enforced via 'conring_size=3D' boot parameter.
> > +
> > + Examples:
> > + 25 =3D> 32 MiB
> > + 24 =3D> 16 MiB
> > + 23 =3D> 8 MiB
> > + 22 =3D> 4 MiB
> > + 21 =3D> 2 MiB
> > + 20 =3D> 1 MiB
> > + 19 =3D> 512 KiB
> > + 18 =3D> 256 KiB
> > + 17 =3D> 128 KiB
> > + 16 =3D> 64 KiB
> > + 15 =3D> 32 KiB
> > + 14 =3D> 16 KiB
>
>
> It might be better to do something similar to what we do in
> SERIAL_TX_BUFSIZE, that the user provides a value in KiB which is
> rounded down to the nearest power of 2?

TBH, I do not think there should be a way for the user to allow reserving h=
uge
amounts of RAM for the console ring. Plus, using logarithmic scale may avoi=
d
confusion, w/o it user-defined CONFIG_CONRING_SIZE will not necessarily
match the real _CONRING_SIZE value.

But I see your point: Kconfig should match existing conring_size=3D spec wh=
ich
defines number of bytes.

>
> > +
> > config XHCI
> > bool "XHCI DbC UART driver"
> > depends on X86
> > diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> > index d22fb4a253af26f9b51d91bd408e1dbf4bb5a7c1..581ee22b85302a54db5b9d5=
d28e8b2d689d31403 100644
> > --- a/xen/drivers/char/console.c
> > +++ b/xen/drivers/char/console.c
> > @@ -104,11 +104,11 @@ static int cf_check parse_console_timestamps(cons=
t char *s);
> > custom_runtime_param("console_timestamps", parse_console_timestamps,
> > con_timestamp_mode_upd);
> >
> > -/* conring_size: allows a large console ring than default (16kB). /
> > +/ conring_size: allows a large console ring than default (32 KiB). */
> > static uint32_t __initdata opt_conring_size;
> > size_param("conring_size", opt_conring_size);
>
>
> You also need to update xen-command-line.pandoc to mention the default
> size is now set in Kconfig. And here I would mention
> CONFIG_CONRING_SIZE rather than explicit 32 KiB, because that's just
> the default in Kconfig, but might not be the default in the build
> itself.

Done.

>
> FWIW, you could define:
>
> #define _CONRING_SIZE (CONFIG_CONRING_SIZE & (CONFIG_CONRING_SIZE - 1))

Done.

>
> Thanks, Roger.




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 03:55:43 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 03:55:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865192.1276479 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTvGI-0004D6-R9; Sat, 04 Jan 2025 03:55:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865192.1276479; Sat, 04 Jan 2025 03:55:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTvGI-0004Cz-OH; Sat, 04 Jan 2025 03:55:42 +0000
Received: by outflank-mailman (input) for mailman id 865192;
 Sat, 04 Jan 2025 03:55:41 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTvGH-0004Ct-LZ
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 03:55:41 +0000
Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c37ac730-ca4f-11ef-a0de-8be0dac302b0;
 Sat, 04 Jan 2025 04:55:40 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c37ac730-ca4f-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1735962939; x=1736222139;
	bh=2NT8pp05G/zcayAYEzlqfKma0fASg5Tomhj1OaplymI=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=M8Ae0MUPGqAjN7t3f4n1nGhWcL8sJftHihBzQRDf+VerKBcbtlyhSF2rBxQZocyyu
	 oNfe9CwqINzZWF6BrOL5QKmfrAX4P85XBlY/NzvoXkgkIee7p3fOiNwNpfYxOyHDy0
	 KKao8MUHBdIDXsVPXNRkgCRlc+ciWeuDjOTY2RwhuniDNe+OxrYN21O2wDguhatvai
	 LmuTh6M8+isi7/Zr8K+17NoLvudCQXZDE2Dkv+stefbiX9LtHy0eR0rVVveWnVM+AC
	 Ez4b/2vLgtyRK7m9szP2vO44xeZQUhGcAmJHFGnd1m/AjRwTSUMq+ks7i2PHxKh56U
	 j8t2+F6j577PQ==
Date: Sat, 04 Jan 2025 03:55:36 +0000
To: Jan Beulich <jbeulich@suse.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 09/35] x86/domain: print emulation_flags
Message-ID: <cJwn8RzlboPNq5c-CSjWNhInbzNFsT2y6W8102sBz09ev7aAbiRmjubWmdus-2XbUaDEP41X2Yfk9nX0qE3i7IFxTJvPpU9u9dJc2Tl5HiE=@proton.me>
In-Reply-To: <d64d0e24-6e88-44d5-a5c8-36f4296489bf@suse.com>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-9-e9aa923127eb@ford.com> <d64d0e24-6e88-44d5-a5c8-36f4296489bf@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: debc92c920df0fdcd072ca875caf3ac8303be71d
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


On Tuesday, December 10th, 2024 at 5:30 AM, Jan Beulich <jbeulich@suse.com>=
 wrote:

>
>
> On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
>
> > Print d->arch.emulation_flags on the console for better traceability wh=
ile
> > debugging in-hypervisor hardware emulators.
>
>
> Personally I disagree with such extra printing. And that would in this ca=
se

I plumbed this printout into 'q' keyhandler which looks much better place
to host this printout.

> even apply if you used dprintk() or gdprintk(). However, if others suppor=
t
> the idea, I don't mean to stand in the way. Just that ...
>
> > --- a/xen/arch/x86/domain.c
> > +++ b/xen/arch/x86/domain.c
> > @@ -818,11 +818,15 @@ int arch_domain_create(struct domain *d,
> >
> > if ( !emulation_flags_ok(d, emflags) )
> > {
> > - printk(XENLOG_G_ERR "d%d: Xen does not allow %s domain creation "
> > + printk(XENLOG_G_ERR "d%d: Xen does not allow %s %sdomain creation "
> > "with the current selection of emulators: %#x\n",
> > - d->domain_id, is_hvm_domain(d) ? "HVM" : "PV", emflags);
> > + d->domain_id,
>
>
> ... if already you touch this, please switch to %pd and also ...
>
> > + is_hvm_domain(d) ? "HVM" : "PV",
> > + is_hardware_domain(d) ? "(hardware) " : "",
> > + emflags);
> > return -EOPNOTSUPP;
> > }
> > + printk(XENLOG_G_INFO "d%d: emulation_flags %#x\n", d->domain_id, emfl=
ags);
>
>
> .. use that here.

Oh, that's nice! Thank you.
Fixed.

>
> Jan




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 03:56:44 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 03:56:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865200.1276489 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTvHF-0004ix-2s; Sat, 04 Jan 2025 03:56:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865200.1276489; Sat, 04 Jan 2025 03:56:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTvHF-0004iq-0A; Sat, 04 Jan 2025 03:56:41 +0000
Received: by outflank-mailman (input) for mailman id 865200;
 Sat, 04 Jan 2025 03:56:39 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTvHD-0004gB-SZ
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 03:56:39 +0000
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e60edd08-ca4f-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 04:56:38 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e60edd08-ca4f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1735962997; x=1736222197;
	bh=OW3mpVxgA5P0XA8d7fgN/ejoe4Kv6q6qpvueYgRNz88=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=M9nMosIj0vPXpCd0ocd0IDmMvElBDsenW7ewKNXLrfcXv9MmnUKJyYUo4NBk7D1Ui
	 PJS2dh3MLsG0qCx7VpZT0EFaC67pnaarbIWvs8m7vHibb+xsyjO7afwS3XF1su8t89
	 6lUlWqDHOCiSYrtoQcC9QdwVdxtVsqxmjDaNsrlxbLEffzoKMIwcUBTF/YDasXaHFZ
	 S5p+xJ2kNukvqCcTq+nW2Q6T1i0GKpfO7p+z1yiHD4LjZT4m91T9yFgTUUuMcXuyjQ
	 S1zbqV1AXH7dx3m8e7QbnjVkI9p+I4OMxfeb2MvFhB8EvVGfYCTtrrxMmfTkTjOH9p
	 UnMUqMsqkEmTA==
Date: Sat, 04 Jan 2025 03:56:31 +0000
To: =?utf-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2 09/35] x86/domain: print emulation_flags
Message-ID: <G87oAGpbL2OPT38kjS-Ja1fei-pmN1WYmfJMWCu-P_Qj-N8hbBEx0UCCELxZvWQTdK5T028HMxmtfRzdiQPDsUMpEOfoBmBFDy4b8N7NvP0=@proton.me>
In-Reply-To: <Z1mtigiI-5wkgzhK@macbook.local>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-9-e9aa923127eb@ford.com> <Z1mtigiI-5wkgzhK@macbook.local>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 52e0835f2729680d59acc7872130ff488a77c438
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


On Wednesday, December 11th, 2024 at 7:19 AM, Roger Pau Monn=C3=A9 <roger.p=
au@citrix.com> wrote:

>
>
> On Thu, Dec 05, 2024 at 08:41:39PM -0800, Denis Mukhin via B4 Relay wrote=
:
>
> > From: Denis Mukhin dmukhin@ford.com
> >
> > Print d->arch.emulation_flags on the console for better traceability wh=
ile
> > debugging in-hypervisor hardware emulators.
> >
> > Signed-off-by: Denis Mukhin dmukhin@ford.com
> > ---
> > xen/arch/x86/domain.c | 8 ++++++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> > index 78a13e6812c9120901d0a70fb3bc1bd6a8b6917d..c88d422a64544531c1e1058=
fa484364bb4277d1e 100644
> > --- a/xen/arch/x86/domain.c
> > +++ b/xen/arch/x86/domain.c
> > @@ -818,11 +818,15 @@ int arch_domain_create(struct domain *d,
> >
> > if ( !emulation_flags_ok(d, emflags) )
> > {
> > - printk(XENLOG_G_ERR "d%d: Xen does not allow %s domain creation "
> > + printk(XENLOG_G_ERR "d%d: Xen does not allow %s %sdomain creation "
>
>
> gprintk(XENLOG_ERR, "...
>
> Might be more natural now that we have the macro (together with Jan's
> suggestion to use %pd (same below).
>
> > "with the current selection of emulators: %#x\n",
> > - d->domain_id, is_hvm_domain(d) ? "HVM" : "PV", emflags);
> > + d->domain_id,
> > + is_hvm_domain(d) ? "HVM" : "PV",
> > + is_hardware_domain(d) ? "(hardware) " : "",
> > + emflags);
> > return -EOPNOTSUPP;
> > }
> > + printk(XENLOG_G_INFO "d%d: emulation_flags %#x\n", d->domain_id, emfl=
ags);
>
>
> This would need to be a dprintk at least, and the log level should be
> XENLOG_DEBUG.

I moved emulation_flags printout to 'q' handler.

>
> Maybe it would be better if you could print this information as part
> of some debug key, for not having to print it for every guest
> creation. Maybe as part of the 'q' debug key?

Thank you for suggestion!
Fixed.

>
> Thanks, Roger.




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 03:57:08 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 03:57:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865205.1276498 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTvHf-0005B9-Ak; Sat, 04 Jan 2025 03:57:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865205.1276498; Sat, 04 Jan 2025 03:57:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTvHf-0005B2-84; Sat, 04 Jan 2025 03:57:07 +0000
Received: by outflank-mailman (input) for mailman id 865205;
 Sat, 04 Jan 2025 03:57: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 <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTvHd-0004gB-Qc
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 03:57:05 +0000
Received: from mail-10631.protonmail.ch (mail-10631.protonmail.ch
 [79.135.106.31]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f54666a8-ca4f-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 04:57:04 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f54666a8-ca4f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1735963022; x=1736222222;
	bh=0xCrTmqSGdZK91yhbegSZQuG87yaWMwjDCGfXp/h/6o=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=bqLgCNogNUdF5Jf685cQpS6yXerXO3szRpouK6BxWNimM6rXm4B9PyO6X2E5Jd2rC
	 adPgyNoT4A2+lsP+l8OEYdvgC2Z+9Ha5wd9DlPF4zcbomo4uF2dol4DtXhkM/Ajo2L
	 gtVU1xVpbSYR3/JFeDtu6aCGj9KVVOtGzKof4GhdQTlxuVF8/k/2Rj+q+va3wN57rz
	 I0kKWzDuYoZ25dfF8aDOXfxXpVufax1t/8jtdE01RCST2bqhlj1j+CgfvM1KGNPBq1
	 7R2n7aqpPlFTJnw2ft3eg/abjRxt8BzeGDJk3JxtwhwOmW08jIjS6UQL/WECtDbM6l
	 X3fVC3qZhSiTg==
Date: Sat, 04 Jan 2025 03:56:57 +0000
To: =?utf-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2 27/35] xen/console: flush console ring to physical console
Message-ID: <IKbFL_PYBasA9J8ETcYRY47L6fcBAyfZYY1aGiC7plAQ0d0I920_WIysrhHrd-q6U_SbLKEjGdZqfh51TZaGmSNjwQoOLOx9tSfy7pkxkBQ=@proton.me>
In-Reply-To: <Z1rxWJtUGsUsMn91@macbook.local>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-27-e9aa923127eb@ford.com> <Z1rxWJtUGsUsMn91@macbook.local>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: e6ff59a3c0c57259cfed49fe8bdd469137a35858
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Thursday, December 12th, 2024 at 6:21 AM, Roger Pau Monn=C3=A9 <roger.pa=
u@citrix.com> wrote:

>
>
> On Thu, Dec 05, 2024 at 08:41:57PM -0800, Denis Mukhin via B4 Relay wrote=
:
>
> > From: Denis Mukhin dmukhin@ford.com
> >
> > Messages printed before the serial and VGA consoles are initialized end=
 up in
> > the internal console buffer (conring). Flush contents of conring to all
> > external consoles after external consoles are fully initialied.
> >
> > Link: https://gitlab.com/xen-project/xen/-/issues/184
> > Signed-off-by: Denis Mukhin dmukhin@ford.com
> > ---
> > xen/drivers/char/console.c | 54 +++++++++++++++++++++++++++++++++------=
-------
> > 1 file changed, 39 insertions(+), 15 deletions(-)
> >
> > diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> > index 581ee22b85302a54db5b9d5d28e8b2d689d31403..a26daee9c4c4b1134d0ae3d=
105ffdb656340b6df 100644
> > --- a/xen/drivers/char/console.c
> > +++ b/xen/drivers/char/console.c
> > @@ -426,23 +426,35 @@ void console_serial_puts(const char *s, size_t nr=
)
> > pv_console_puts(s, nr);
> > }
> >
> > -static void cf_check dump_console_ring_key(unsigned char key)
> > +/*
> > + * Write characters to physical console(s).
> > + * That covers:
> > + * - serial console;
> > + * - video output.
> > + */
> > +static void console_puts(const char str, size_t len)
> > +{
> > + ASSERT(rspin_is_locked(&console_lock));
> > +
> > + console_serial_puts(str, len);
> > + video_puts(str, len);
> > +}
> > +
> > +/
> > + * Flush contents of the conring to the physical console devices.
> > + */
> > +static int console_flush(void)
> > {
> > uint32_t idx, len, sofar, c;
> > unsigned int order;
> > char *buf;
> >
> > - printk("'%c' pressed -> dumping console ring buffer (dmesg)\n", key);
> > -
> > - /* create a buffer in which we'll copy the ring in the correct
> > - order and NUL terminate */
> > order =3D get_order_from_bytes(conring_size + 1);
> > buf =3D alloc_xenheap_pages(order, 0);
> > if ( buf =3D=3D NULL )
> > - {
> > - printk("unable to allocate memory!\n");
> > - return;
> > - }
> > + return -ENOMEM;
> > +
> > + nrspin_lock_irq(&console_lock);
> >
> > c =3D conringc;
> > sofar =3D 0;
> > @@ -457,10 +469,23 @@ static void cf_check dump_console_ring_key(unsign=
ed char key)
> > c +=3D len;
> > }
> >
> > - console_serial_puts(buf, sofar);
> > - video_puts(buf, sofar);
> > + console_puts(buf, sofar);
> > +
> > + nrspin_unlock_irq(&console_lock);
> >
> > free_xenheap_pages(buf, order);
> > +
> > + return 0;
> > +}
> > +
> > +static void cf_check dump_console_ring_key(unsigned char key)
> > +{
> > + int rc;
> > +
> > + printk("'%c' pressed -> dumping console ring buffer (dmesg)\n", key);
> > + rc =3D console_flush();
> > + if ( rc )
> > + printk("failed to dump console ring buffer: %d\n", rc);
> > }
> >
> > /*
> > @@ -707,10 +732,7 @@ static inline void xen_console_write(const char *s=
tr, size_t len)
> > */
> > static void console_write(const char *str, size_t len)
> > {
> > - ASSERT(rspin_is_locked(&console_lock));
> > -
> > - console_serial_puts(str, len);
> > - video_puts(str, len);
> > + console_puts(str, len);
> >
> > if ( opt_console_xen )
> > xen_console_write(str, len);
> > @@ -1177,6 +1199,8 @@ void __init console_endboot(void)
> >
> > video_endboot();
> >
> > + /* NB: send conring contents to all enabled physical consoles, if any=
 */
> > + console_flush();
>
>
> This is way too late: at this point Xen has already finished booting,
> and is about to handover execution to dom0. Flushing here will result
> in duplicating almost all Xen output already printed?

Yes, indeed; fixed.

>
> The flush needs to be done inside of console_init_preirq(), just
> before printing xen_banner() I think. This sequentially after the
> console has been initialized. Otherwise you are just duplicating
> messages.

Fixed.

>
> Thanks, Roger.




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 03:58:29 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 03:58:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865220.1276509 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTvIy-0005sO-OD; Sat, 04 Jan 2025 03:58:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865220.1276509; Sat, 04 Jan 2025 03:58:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTvIy-0005sH-LR; Sat, 04 Jan 2025 03:58:28 +0000
Received: by outflank-mailman (input) for mailman id 865220;
 Sat, 04 Jan 2025 03:58:26 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTvIw-0005qY-SE
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 03:58:26 +0000
Received: from mail-10628.protonmail.ch (mail-10628.protonmail.ch
 [79.135.106.28]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 263eff94-ca50-11ef-a0de-8be0dac302b0;
 Sat, 04 Jan 2025 04:58:26 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 263eff94-ca50-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1735963105; x=1736222305;
	bh=i8SweO/7+CrvITbcSVv379HteG9ln8/znTvZd8thGgg=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=ABVLxjGucb9kGtzcHVpw7wJzFOAItSCjjlexevaH3fbEFAmd3Gq/RORCdkixWDbcM
	 oiUAR7QNjdiq7/M+zST3Lt5rMS7jt0p7SK7MbQHqkwUFK2nl0JNyA27r1rVuRomnIE
	 d6q9xwq2fRgrYh6KAVj2ojrXxz/oeyfqOPhkUVRQKSnxoGmCKhVzWLE/7SgqB+fN+3
	 CyiJz3mmb7XuEpQC5pciGXzE71lf5MsFM5Tk15Kqq/bz0vab3hwX+Tmh4DTQke4I4+
	 ahXZZToVUuFiLk1PUQ1Kovuf8Xpe6DI2dL+J/rO/OQDN0sVXMcVGOOeH1yHm/PxZZV
	 QyzgHo5lShy7w==
Date: Sat, 04 Jan 2025 03:58:23 +0000
To: =?utf-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2 29/35] x86/hvm: add HVM-specific Kconfig
Message-ID: <JYnExqPNvYs3nAbLXqEQ3RLA2A1Llei-IsJzlJ16Ws1wB3e2deXBvY3TjDxM2FhHU2fRc2HG3MFXOfQC_aGEaMr2A3gB9ZGPX_Z-VFAhsq8=@proton.me>
In-Reply-To: <Z1r8DWGh6sujHZss@macbook.local>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-29-e9aa923127eb@ford.com> <Z1r8DWGh6sujHZss@macbook.local>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: e7bd6cc39660f432b300ad6d519e7c79f535c1ea
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Thursday, December 12th, 2024 at 7:06 AM, Roger Pau Monn=C3=A9 <roger.pa=
u@citrix.com> wrote:

>
>
> On Thu, Dec 05, 2024 at 08:41:59PM -0800, Denis Mukhin via B4 Relay wrote=
:
>
> > From: Denis Mukhin dmukhin@ford.com
> >
> > Add separate menu for configuring HVM build-time settings.
> > That will help organizing HVM-specific options under a separate menu.
>
>
> Instead of being a separate menu, which feels a bit odd under default
> settings because there's just an "HVM support" option inside, could
> you make it look like the PV support menu, that indents PV specific
> options:
>
> [] PV support
> [ ] Support for 32bit PV guests
> [] Support for PV linear pagetables

My rationale is that code base at arch/x86/hvm deserves its own Kconfig bec=
ause
there a bunch of configuration options just for arch/x86/hvm.
I think that will also help managing configuration since they all in dedica=
ted
location.

I enabled "HVM menu" using correct Kconfig syntax in v3.

>
> Thanks, Roger.




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 04:01:19 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 04:01:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865230.1276518 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTvLY-0007fK-3s; Sat, 04 Jan 2025 04:01:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865230.1276518; Sat, 04 Jan 2025 04:01:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTvLY-0007fD-13; Sat, 04 Jan 2025 04:01:08 +0000
Received: by outflank-mailman (input) for mailman id 865230;
 Sat, 04 Jan 2025 04:01:06 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTvLW-0007dh-6S
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 04:01:06 +0000
Received: from mail-10630.protonmail.ch (mail-10630.protonmail.ch
 [79.135.106.30]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 840b3a62-ca50-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 05:01:03 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 840b3a62-ca50-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1735963262; x=1736222462;
	bh=/5vzlfGpgvgVcegUJVZmXeoXDeL04N9KoKlstkZ9pQ8=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=cOe7Fl/yu+IvoAIHjv9iUuOLK6Whn52QMTPPxIvv/XymJ2LNs1XSF0dXcxl3j9BoQ
	 HEI7+2fslQWLd5LFx1qEiSvrwdO542SNFjkUvY8+wT82DxXYz87HuuTv6njQjBeeB1
	 9G6/5SZGXelL1DkOANE8hspNIXScTNsuDNvi2iwBHV7V4G7DDqs9Rm1+1CMy7CYTCS
	 tWHxV8TehIphclziMLpI/rG4LQ/dS+topiKK6apGi7Z3JTNX6fmMBpSesG78gkTxO7
	 xPH7RjAaWC/SJS79EGCf0b1Wb6ZqOgOdzslOsoEdHmhirUuxTqeGvTCqhZQ+Z0YhLT
	 ZzpXr04PO7crQ==
Date: Sat, 04 Jan 2025 04:00:57 +0000
To: Jan Beulich <jbeulich@suse.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 28/35] xen/8250-uart: add missing definitions
Message-ID: <45RKKdB9RUdYD5cKt4CA7xiWf9u4U98uW4WmLEAbAUVc57bEKFDm7_Kk_Q0sw_XoYaCUeBugXIBZC28kksNoEgII8eh-IDpiBIsZpYz1djg=@proton.me>
In-Reply-To: <e10255e4-c5e5-4cc7-9665-6852252e93cc@suse.com>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-28-e9aa923127eb@ford.com> <e10255e4-c5e5-4cc7-9665-6852252e93cc@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: f6940d0e88ed7a935ee98040bb050fa53e57c817
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Thursday, December 12th, 2024 at 7:07 AM, Jan Beulich <jbeulich@suse.com=
> wrote:

>
>
> On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
>
> > --- a/xen/include/xen/8250-uart.h
> > +++ b/xen/include/xen/8250-uart.h
> > @@ -32,16 +32,22 @@
> > #define UART_MCR 0x04 /* Modem control /
> > #define UART_LSR 0x05 / line status /
> > #define UART_MSR 0x06 / Modem status /
> > +#define UART_SCR 0x07 / Scratch pad /
> > #define UART_USR 0x1f / Status register (DW) /
> > #define UART_DLL 0x00 / divisor latch (ls) (DLAB=3D1) /
> > #define UART_DLM 0x01 / divisor latch (ms) (DLAB=3D1) /
> > #define UART_XR_EFR 0x09 / Enhanced function register (Exar) */
> >
> > +/* ns8250 emulator: range of emulated registers [0..UART_MAX-1] */
> > +#define UART_MAX (UART_SCR + 1)
>
>
> There are two issues here: "max" means "highest within range", yet
> you define it as "first invalid", i.e. something we'd normally call
> "_NR" or "NUM". And then, as the comment says, this is a limit the
> emulation is going to expose, not something generally applicable to
> UARTs of this kind. Hence the UART prefix alone isn't quite correct
> either.

I did renaming and moved declaration to the UART emulator code.

>
> > @@ -51,12 +57,21 @@
> > #define UART_IIR_THR 0x02 /* - tx reg. empty /
> > #define UART_IIR_MSI 0x00 / - MODEM status /
> > #define UART_IIR_BSY 0x07 / - busy detect (DW) /
> > +#define UART_IIR_FE0 BIT(6, U) / FIFO enable #0 /
> > +#define UART_IIR_FE1 BIT(7, U) / FIFO enable #1 */
> > +#define UART_IIR_FE_MASK (UART_IIR_FE0 | UART_IIR_FE1)
>
>
> Much like BSY is a 3-bit field, aiui this is a 2-bit one.

Updated to 2-bit mask.

>
> > /* FIFO Control Register /
> > -#define UART_FCR_ENABLE 0x01 / enable FIFO /
> > -#define UART_FCR_CLRX 0x02 / clear Rx FIFO /
> > -#define UART_FCR_CLTX 0x04 / clear Tx FIFO /
> > -#define UART_FCR_DMA 0x10 / enter DMA mode /
> > +#define UART_FCR_ENABLE BIT(0, U) / enable FIFO /
> > +#define UART_FCR_CLRX BIT(1, U) / clear Rx FIFO /
> > +#define UART_FCR_CLTX BIT(2, U) / clear Tx FIFO /
> > +#define UART_FCR_DMA BIT(3, U) / enter DMA mode /
> > +#define UART_FCR_RESERVED0 BIT(4, U) / reserved; always 0 /
> > +#define UART_FCR_RESERVED1 BIT(5, U) / reserved; always 0 /
> > +#define UART_FCR_RTB0 BIT(6, U) / receiver trigger bit #0 /
> > +#define UART_FCR_RTB1 BIT(7, U) / receiver trigger bit #1 */
> > +#define UART_FCR_TRG_MASK (UART_FCR_RTB0 | UART_FCR_RTB1)
>
>
> Much like the top two bits here are, and - as Roger has said - the
> reserved bits probably also should be.

I kept reserved bits as is.
I think that will help to avoid confusion whether support for those bits
is missing in the driver code or those are reserved.

There are other examples, e.g. PCI_PM_CAP_RESERVED when reserved bits
declared and not necessarily used in the code base.

>
> > @@ -64,17 +79,17 @@
> >
> > /*
> > * Note: The FIFO trigger levels are chip specific:
> > - * RX:76 =3D 00 01 10 11 TX:54 =3D 00 01 10 11
> > - * PC16550D: 1 4 8 14 xx xx xx xx
> > - * TI16C550A: 1 4 8 14 xx xx xx xx
> > - * TI16C550C: 1 4 8 14 xx xx xx xx
> > - * ST16C550: 1 4 8 14 xx xx xx xx
> > - * ST16C650: 8 16 24 28 16 8 24 30 PORT_16650V2
> > - * NS16C552: 1 4 8 14 xx xx xx xx
> > - * ST16C654: 8 16 56 60 8 16 32 56 PORT_16654
> > - * TI16C750: 1 16 32 56 xx xx xx xx PORT_16750
> > - * TI16C752: 8 16 56 60 8 16 32 56
> > - * Tegra: 1 4 8 14 16 8 4 1 PORT_TEGRA
> > + * RX:76 =3D 00 01 10 11 TX:54 =3D 00 01 10 11
> > + * PC16550D: 1 4 8 14 xx xx xx xx
> > + * TI16C550A: 1 4 8 14 xx xx xx xx
> > + * TI16C550C: 1 4 8 14 xx xx xx xx
> > + * ST16C550: 1 4 8 14 xx xx xx xx
> > + * ST16C650: 8 16 24 28 16 8 24 30 PORT_16650V2
> > + * NS16C552: 1 4 8 14 xx xx xx xx
> > + * ST16C654: 8 16 56 60 8 16 32 56 PORT_16654
> > + * TI16C750: 1 16 32 56 xx xx xx xx PORT_16750
> > + * TI16C752: 8 16 56 60 8 16 32 56
> > + * Tegra: 1 4 8 14 16 8 4 1 PORT_TEGRA
> > */
>
>
> While perhaps okay, the adjustment of this table still looks unrelated.
> It wants at least mentioning in the description, to clarify it's an
> intentional change (as opposed to e.g. being an effect of how your
> editor is configured).

Thanks, I updated the commit message.

>
> > @@ -96,11 +111,31 @@
> > #define UART_LCR_CONF_MODE_B 0xBF /* Configuration mode B */
> >
> > /* Modem Control Register /
> > -#define UART_MCR_DTR 0x01 / Data Terminal Ready /
> > -#define UART_MCR_RTS 0x02 / Request to Send /
> > -#define UART_MCR_OUT2 0x08 / OUT2: interrupt mask /
> > -#define UART_MCR_LOOP 0x10 / Enable loopback test mode /
> > -#define UART_MCR_TCRTLR 0x40 / Access TCR/TLR (TI16C752, EFR[4]=3D1) /
> > +#define UART_MCR_DTR BIT(0, U) / Data Terminal Ready /
> > +#define UART_MCR_RTS BIT(1, U) / Request to Send /
> > +#define UART_MCR_OUT1 BIT(2, U) / OUT1: interrupt mask /
> > +#define UART_MCR_OUT2 BIT(3, U) / OUT2: interrupt mask /
> > +#define UART_MCR_LOOP BIT(4, U) / Enable loopback test mode /
> > +#define UART_MCR_RESERVED0 BIT(5, U) / Reserved #0 /
> > +#define UART_MCR_RESERVED1 BIT(6, U) / Reserved #1 /
> > +#define UART_MCR_TCRTLR BIT(6, U) / Access TCR/TLR (TI16C752, EFR[4]=
=3D1) /
> > +#define UART_MCR_RESERVED2 BIT(7, U) / Reserved #2 /
> > +#define UART_MCR_MASK \
> > + (UART_MCR_DTR | UART_MCR_RTS | \
> > + UART_MCR_OUT1 | UART_MCR_OUT2 | \
> > + UART_MCR_LOOP)
> > +
> > +/ Modem Status Register /
> > +#define UART_MSR_DCTS BIT(0, U) / Change in CTS /
> > +#define UART_MSR_DDSR BIT(1, U) / Change in DSR /
> > +#define UART_MSR_TERI BIT(2, U) / Change in RI /
> > +#define UART_MSR_DDCD BIT(3, U) / Change in CTS */
> > +#define UART_MSR_CTS BIT(4, U)
> > +#define UART_MSR_DSR BIT(5, U)
> > +#define UART_MSR_RI BIT(6, U)
> > +#define UART_MSR_DCD BIT(7, U)
>
>
> As you introduce these constants, I think you also want to switch the sol=
e
> MSR read we have to actually use them.

Sure, no problem; fixed.

>
> Jan




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 04:01:56 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 04:01:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865237.1276528 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTvMH-0008HA-Bh; Sat, 04 Jan 2025 04:01:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865237.1276528; Sat, 04 Jan 2025 04:01:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTvMH-0008H3-94; Sat, 04 Jan 2025 04:01:53 +0000
Received: by outflank-mailman (input) for mailman id 865237;
 Sat, 04 Jan 2025 04:01:52 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTvMG-0007dh-Me
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 04:01:52 +0000
Received: from mail-10628.protonmail.ch (mail-10628.protonmail.ch
 [79.135.106.28]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a07d562c-ca50-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 05:01:51 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a07d562c-ca50-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=usqe2dgy7ne2dkl2qbugtq35ku.protonmail; t=1735963310; x=1736222510;
	bh=P2bG0zD4+qRHcNJXAcSZ4NMKsu13DoyVaZxfv2bwnpI=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=TE+KAdfz1LJZmbRrsQf8ObDEvKA/nSpnOMtG6VLjnGiZxHcC8+6SPkRRayEfk2rz0
	 5SsSEJ3AAyXVcaNnStpUeTioRTxedAK7B+X2SwHg05pYgLsRg/DPgGZO0Ahn7pgx1X
	 BQM6eG2hqD5zDA5zapN7i2oTJPGlSFSA4dCnN3tm3usRdMJblve+daNhGFvCTgGOAS
	 wfbHOON88FcAIZicLiZ33Vd8ZZN9KlFd88SCGItlGs1Y0BxtG5KRm1exDaUTDS2qsK
	 jN3LYyKn+X2tRUN9++HeYx+PrGpzZd/zUO0nz18E//GQKYuIrLKhe5TLbrTsCocUv9
	 vv90BA8vdDKuA==
Date: Sat, 04 Jan 2025 04:01:44 +0000
To: =?utf-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2 28/35] xen/8250-uart: add missing definitions
Message-ID: <TQpr0M1IH2DHO5zjeVbaVXHpUewfpSil_xElIa1ViXBELJsOUqipFNZdwZ3o02cOmGN-AvPJ2Iq2oibUEeopmehU26tBylu_eGQxa3Xtc9A=@proton.me>
In-Reply-To: <Z1rzZGef5SusIkN-@macbook.local>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-28-e9aa923127eb@ford.com> <Z1rzZGef5SusIkN-@macbook.local>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 31422d13bbdcb1690c3ba75d4517bbac163335d9
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Thursday, December 12th, 2024 at 6:29 AM, Roger Pau Monn=C3=A9 <roger.pa=
u@citrix.com> wrote:

>
>
> On Thu, Dec 05, 2024 at 08:41:58PM -0800, Denis Mukhin via B4 Relay wrote=
:
>
> > From: Denis Mukhin dmukhin@ford.com
> >
> > Added missing definitions needed for NS8250 UART emulator.
> >
> > Signed-off-by: Denis Mukhin dmukhin@ford.com
> > ---
> > xen/include/xen/8250-uart.h | 81 +++++++++++++++++++++++++++++++++-----=
-------
> > 1 file changed, 60 insertions(+), 21 deletions(-)
> >
> > diff --git a/xen/include/xen/8250-uart.h b/xen/include/xen/8250-uart.h
> > index d13352940c13c50bac17d4cdf2f3bf584380776a..4a69b2b225140efda287bdf=
96fa0caa4aa70074f 100644
> > --- a/xen/include/xen/8250-uart.h
> > +++ b/xen/include/xen/8250-uart.h
> > @@ -32,16 +32,22 @@
> > #define UART_MCR 0x04 /* Modem control /
> > #define UART_LSR 0x05 / line status /
> > #define UART_MSR 0x06 / Modem status /
> > +#define UART_SCR 0x07 / Scratch pad /
> > #define UART_USR 0x1f / Status register (DW) /
> > #define UART_DLL 0x00 / divisor latch (ls) (DLAB=3D1) /
> > #define UART_DLM 0x01 / divisor latch (ms) (DLAB=3D1) /
> > #define UART_XR_EFR 0x09 / Enhanced function register (Exar) */
> >
> > +/* ns8250 emulator: range of emulated registers [0..UART_MAX-1] /
> > +#define UART_MAX (UART_SCR + 1)
> > +
> > / Interrupt Enable Register /
> > #define UART_IER_ERDAI 0x01 / rx data recv'd /
> > #define UART_IER_ETHREI 0x02 / tx reg. empty /
> > #define UART_IER_ELSI 0x04 / rx line status /
> > #define UART_IER_EMSI 0x08 / MODEM status */
> > +#define UART_IER_MASK \
> > + (UART_IER_ERDAI | UART_IER_ETHREI | UART_IER_ELSI | UART_IER_EMSI)
> >
> > /* Interrupt Identification Register /
> > #define UART_IIR_NOINT 0x01 / no interrupt pending /
> > @@ -51,12 +57,21 @@
> > #define UART_IIR_THR 0x02 / - tx reg. empty /
> > #define UART_IIR_MSI 0x00 / - MODEM status /
> > #define UART_IIR_BSY 0x07 / - busy detect (DW) /
> > +#define UART_IIR_FE0 BIT(6, U) / FIFO enable #0 /
> > +#define UART_IIR_FE1 BIT(7, U) / FIFO enable #1 */
> > +#define UART_IIR_FE_MASK (UART_IIR_FE0 | UART_IIR_FE1)
> >
> > /* FIFO Control Register /
> > -#define UART_FCR_ENABLE 0x01 / enable FIFO /
> > -#define UART_FCR_CLRX 0x02 / clear Rx FIFO /
> > -#define UART_FCR_CLTX 0x04 / clear Tx FIFO /
> > -#define UART_FCR_DMA 0x10 / enter DMA mode /
> > +#define UART_FCR_ENABLE BIT(0, U) / enable FIFO /
> > +#define UART_FCR_CLRX BIT(1, U) / clear Rx FIFO /
> > +#define UART_FCR_CLTX BIT(2, U) / clear Tx FIFO /
> > +#define UART_FCR_DMA BIT(3, U) / enter DMA mode /
> > +#define UART_FCR_RESERVED0 BIT(4, U) / reserved; always 0 /
> > +#define UART_FCR_RESERVED1 BIT(5, U) / reserved; always 0 */
>
>
> We don't usually define reserved bits I think, as I assume those won't
> be used by the code?

I found examples of reserved bits being defined and not used in the
code base, e.g. PCI_PM_CAP_RESERVED.

IMO marking reserved bits in the code will immediately explain
readers the purpose of those bits.

>
> Maybe a reserved mask for the hole register, to ensure the access to
> the register doesn't attempt to set reserved bits? But even then the
> best we can do when emulating is print a warning message.

Added warning messages in the emulator code (v3).

>
> Thanks, Roger.




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 04:02:45 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 04:02:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865246.1276538 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTvN6-0000Nz-LC; Sat, 04 Jan 2025 04:02:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865246.1276538; Sat, 04 Jan 2025 04:02:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTvN6-0000Ns-IL; Sat, 04 Jan 2025 04:02:44 +0000
Received: by outflank-mailman (input) for mailman id 865246;
 Sat, 04 Jan 2025 04:02: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 <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTvN5-0008H2-OA
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 04:02:43 +0000
Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bf6868dd-ca50-11ef-a0de-8be0dac302b0;
 Sat, 04 Jan 2025 05:02:43 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: bf6868dd-ca50-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1735963359; x=1736222559;
	bh=Veu6p8QFmCe8xyZECYGH33Aw1h+i1nxVtHvFtIHC3tc=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=XrpoeL+EyGV3u30rnJY4NuLBj8zmB1ftPoZ9K0KkPX7v04mB/AB315PDTgC5URyGW
	 XhDCOoaNdmx9IGoGQvvp9TyHDxo4F1ipc0lyvNGRQOamjTsObRvrO9kqp2Ct5hMAHO
	 svfmRHWfsGcZkFpQLJFGIRWKj43qe1ZcXTfL6IEW7noApdwquSMY0UCL2T6otttUDC
	 wi4A+XXJbzWvGR3p7iXOrBnXDYb8M4pi6HNEAdWcDS60BdXo/vb8ZVY3B5oToUb2uR
	 BT8odotgkcxEAr8o0d9oKhktxyf8Gc/SmTOFQ+rUXcZiCSY6siuJAk/BdeWr+A41BQ
	 qSe+6KM/4ehVw==
Date: Sat, 04 Jan 2025 04:02:34 +0000
To: =?utf-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2 30/35] x86/hvm: add helpers for raising guest IRQs
Message-ID: <WWGpizlEZm2Dqz0GKYb_U37t6JwX_DZkJt4e1N7NZ1_yuS3MfjtWQnFfZycFODrnYEKrO7_SekjWjjhpwQFoWJjx8GyeK9c7W4D4gH_Kkso=@proton.me>
In-Reply-To: <Z1sM4pri0oJRyMPJ@macbook.local>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-30-e9aa923127eb@ford.com> <Z1sM4pri0oJRyMPJ@macbook.local>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 005f7634b28dd13ef2e0ecd1bb5f2c47648996a5
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Thursday, December 12th, 2024 at 8:18 AM, Roger Pau Monn=C3=A9 <roger.pa=
u@citrix.com> wrote:

>
>
> On Thu, Dec 05, 2024 at 08:42:00PM -0800, Denis Mukhin via B4 Relay wrote=
:
>
> > From: Denis Mukhin dmukhin@ford.com
> >
> > Added convenience wrappers for asserting/de-asserting interrupts in the
> > hardware emulation code.
> >
> > That will be used for PCI-based NS8250 emulator.
>
>
> Strictly speaking the ns8250 uart should only generate ISA interrupts
> as I understand it, as it only uses IRQs 3 and 4? IOW from that code
> you should only need to use hvm_isa_irq_assert().

Correct, current code uses IRQ#3 and IRQ#4 only.
I dropped the patch from the series for now.

>
> > Signed-off-by: Denis Mukhin dmukhin@ford.com
> > ---
> > xen/arch/x86/hvm/irq.c | 24 ++++++++++++++++++++++++
> > xen/arch/x86/include/asm/hvm/irq.h | 3 +++
> > 2 files changed, 27 insertions(+)
> >
> > diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c
> > index 1eab44defca4c82ec35769617c66c380cc07d1b6..9e3a50d21dcf281c1015116=
094e47795c51ed5d0 100644
> > --- a/xen/arch/x86/hvm/irq.c
> > +++ b/xen/arch/x86/hvm/irq.c
> > @@ -242,6 +242,30 @@ void hvm_isa_irq_deassert(
> > spin_unlock(&d->arch.hvm.irq_lock);
> > }
> >
> > +void hvm_irq_raise(struct domain *d, unsigned int irq)
> > +{
> > + if ( irq < NR_ISAIRQS )
> > + {
> > + hvm_isa_irq_assert(d, irq, NULL);
> > + }
> > + else
> > + {
> > + hvm_gsi_assert(d, irq);
> > + }
> > +}
> > +
> > +void hvm_irq_lower(struct domain *d, unsigned int irq)
>
>
> It would be better to use the assert/deassert nomenclature, like it's
> used for the functions that are called.
>
> > +{
> > + if ( irq < NR_ISAIRQS )
> > + {
> > + hvm_isa_irq_deassert(d, irq);
> > + }
> > + else
> > + {
> > + hvm_gsi_deassert(d, irq);
> > + }
> > +}
>
>
> The parameter to thins function is kind of fuzzy, as I understand it,
> if the parameter is < NR_ISAIRQS it's an ISA IRQ, while if it's >=3D
>
> NR_ISAIRQS it's a GSI?

Yes, agree, mixing two address spaces is at least confusing.
I dropped the patch from the series.

>
> It would also be helpul to mention that hvm_isa_irq_deassert() will
> already do the ISA IRQ -> GSI conversion in case there are any source
>
> overrides.
>
> Thanks, Roger.




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 04:11:38 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 04:11:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865257.1276549 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTvVd-0002MQ-EP; Sat, 04 Jan 2025 04:11:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865257.1276549; Sat, 04 Jan 2025 04:11:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTvVd-0002MJ-BG; Sat, 04 Jan 2025 04:11:33 +0000
Received: by outflank-mailman (input) for mailman id 865257;
 Sat, 04 Jan 2025 04:11:32 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTvVb-0002MB-5o
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 04:11:32 +0000
Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f8cc286c-ca51-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 05:11:28 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f8cc286c-ca51-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1735963887; x=1736223087;
	bh=yzwIUDE2mf7bE1y6V1xydGKJ3GLYX5tWjDmcbyR+z5Y=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=BXvSmlnG/9yDrQXr6UDtvIOuLYd2zxWlK6/tt1SXHned6bu3Fh+EEqXbhf+Qq5wC4
	 rXzHiwKWpM+fL1V+21ik6OZx7d1jN9pHLSCiZ8c0N//2PBeKRUF/z2++iPjTRtDujq
	 EUA2XVfD1mRoelLUS5N1zniQRQ8n0aW+mYnGhJpeYqw85XGX0Zw0LCHy8sqkrgXfQ/
	 Gw4eH+i+YjIAYht8BUGVAjrZnAsQffLaXOdmvB9s1sjx2KoR1epb1GEJxE5wHSx2SS
	 BHy4dCi1ELm/yShRmDUCFYA8eNC0j9iPl0d8f+JLOZwd/fG7Dqn9aJ2+faRqJ4+gk2
	 pvsFWSyQejM3Q==
Date: Sat, 04 Jan 2025 04:11:23 +0000
To: =?utf-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2 20/35] xen/console: introduce console_owner_domid()
Message-ID: <EFbe2P8_qOWpR_7V8U-UwFYC3tuQ0VySWlxIp7aUhqoHGCnmS7ARrYZKyz7jJFWzmDi6Awt-Fhxr2VGhZkOF5nUzIV0W_0teswRX07dGr9k=@proton.me>
In-Reply-To: <Z1q4fPHY_0BzvGT6@macbook.local>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-20-e9aa923127eb@ford.com> <Z1q4fPHY_0BzvGT6@macbook.local>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 01a8615830e2e37424e697a1cb48aa6ee29379e2
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


On Thursday, December 12th, 2024 at 2:18 AM, Roger Pau Monn=C3=A9 <roger.pa=
u@citrix.com> wrote:

>
>
> On Thu, Dec 05, 2024 at 08:41:50PM -0800, Denis Mukhin via B4 Relay wrote=
:
>
> > From: Denis Mukhin dmukhin@ford.com
> >
> > console_owner_domid() is introduced to obtain the "console owner" domai=
n ID.
> >
> > The call is used in NS8250 emulator to identify the case when physical =
xen
> > console focus is owned by the domain w/ NS8250 emulator, in which case,
> > messages from guest OS are formatted w/o '(XEN)' prefix.
>
>
> Nit: it would be better to not use abbreviations such as w/ or w/o in
> commit messages.

Muscle memory; cleaned up in v3.

>
> > Signed-off-by: Denis Mukhin dmukhin@ford.com
> > ---
> > xen/drivers/char/console.c | 5 +++++
> > xen/include/xen/console.h | 1 +
> > 2 files changed, 6 insertions(+)
> >
> > diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> > index 52cf64dbf6fd18d599cb88835d03501a23b3e3c4..a8ab5c2bcb98e4cadf9ad2c=
9ad28d297977d0557 100644
> > --- a/xen/drivers/char/console.c
> > +++ b/xen/drivers/char/console.c
> > @@ -498,6 +498,11 @@ struct domain *rcu_lock_domain_console_owner(void)
> > return rcu_lock_domain_console_by_id(console_owner);
> > }
> >
> > +domid_t console_owner_domid(void)
> > +{
> > + return console_owner;
> > +}
> > +
> > static bool console_owner_possible(domid_t domid)
> > {
> > struct domain *d;
> > diff --git a/xen/include/xen/console.h b/xen/include/xen/console.h
> > index 57c482cfbf2da15b011e64841ea086e779f4588d..83be5794aff6630beaad46f=
910fcc0fc6d833808 100644
> > --- a/xen/include/xen/console.h
> > +++ b/xen/include/xen/console.h
> > @@ -33,6 +33,7 @@ void console_end_log_everything(void);
> >
> > struct domain *rcu_lock_domain_console_owner(void);
> > int console_set_owner(domid_t);
> > +domid_t console_owner_domid(void);
>
>
> I would expect that either the caller already has a domain locked, or
> uses rcu_lock_domain_console_owner() to obtain the domain and then get
> the domid? (d->domain_id?)

If the console focus in the guest, there's no need to prefix each guest OS
printout w/ "(XEN)" and a timestamp. To identify that current ns8250 emulat=
or
is the one who's printing to the physical UART, I introduced this call.

I think ideally, domain should have a flag saying "currently has console
focus" which is set by the console focus switch logic in console driver.

>
>
> It's hard to tell why you need such way to get the console input
> target domid in such a way without seeing a caller to the function.

Sorry for that, addressed in v3.
I ended up dropping the patch after addressing all the feedback.

>
> Thanks, Roger.




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 04:12:06 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 04:12:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865262.1276559 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTvWA-0002p2-M1; Sat, 04 Jan 2025 04:12:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865262.1276559; Sat, 04 Jan 2025 04:12:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTvWA-0002ov-IU; Sat, 04 Jan 2025 04:12:06 +0000
Received: by outflank-mailman (input) for mailman id 865262;
 Sat, 04 Jan 2025 04:12:05 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTvW9-0002c5-JX
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 04:12:05 +0000
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0e56f030-ca52-11ef-a0de-8be0dac302b0;
 Sat, 04 Jan 2025 05:12:05 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 0e56f030-ca52-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1735963924; x=1736223124;
	bh=wpzqJ1gQpT4llUTwdbiCzzk5W799nCBrenThzsDWhe0=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=Iib4yioTpjklgIj0REC/et5vzchO9ru+nl4iVDfiK6bNmyj5EJSYse0sBPPJlbKkM
	 4IugCzKkJ8E7PcLsmUCIsETXkQ0Q7v/8s2YG/ujD8gVzCkKSlEWEsWXjud/mrtldIw
	 ZHpMDw1MyMSsZT+SHeGdagH4AiRM3Upl7a7hG2f2HYgAZGbeSm2vkOi9RGbaC73aDb
	 irH9VsG7zF/JeulHZ45qs2WZyFpRAhnirUrS4AUtecOrV4c9TtiGOaTen9sa2Q29Sp
	 bVWgWOEniJDf0VkLCctZA+yNldYwQOEO4FCj0DGWB8aSxTLiFX9hM1cfr44fwmawGt
	 4WQKYLBuPUQUQ==
Date: Sat, 04 Jan 2025 04:11:59 +0000
To: Stefano Stabellini <sstabellini@kernel.org>
From: Denis Mukhin <dmkhn@proton.me>
Cc: Jan Beulich <jbeulich@suse.com>, =?utf-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, dmukhin@ford.com, xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>
Subject: Re: [PATCH v2 16/35] xen/console: introduce printk_common()
Message-ID: <lAo-0zG42GARrpwwdvnIdtEbA4w5dT6-CV4DAZIwVn5Psvau0FhgY5Q4Zp4FgbD6SX2O6zL5Arkn-4voo7uRWZuiwIY4LLuAYrfaeracpr8=@proton.me>
In-Reply-To: <alpine.DEB.2.22.394.2412121655360.463523@ubuntu-linux-20-04-desktop>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-16-e9aa923127eb@ford.com> <Z1qpk55qKBywx26R@macbook.local> <8e5ce2dd-f888-42a3-937f-98ed1269c66c@suse.com> <Z1rT3lsr9B0dy-Jr@macbook.local> <9dad24ea-178f-48c8-a93b-5823c44b56ee@suse.com> <alpine.DEB.2.22.394.2412121655360.463523@ubuntu-linux-20-04-desktop>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 744c4105966ce7cb2ffc083108948da70e8f37dc
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


On Thursday, December 12th, 2024 at 5:03 PM, Stefano Stabellini <sstabellin=
i@kernel.org> wrote:

>
>
> On Thu, 12 Dec 2024, Jan Beulich wrote:
>
> > On 12.12.2024 13:15, Roger Pau Monn=C3=A9 wrote:
> >
> > > On Thu, Dec 12, 2024 at 12:57:25PM +0100, Jan Beulich wrote:
> > >
> > > > On 12.12.2024 10:14, Roger Pau Monn=C3=A9 wrote:
> > > >
> > > > > On Thu, Dec 05, 2024 at 08:41:46PM -0800, Denis Mukhin via B4 Rel=
ay wrote:
> > > > >
> > > > > > From: Denis Mukhin dmukhin@ford.com
> > > > > >
> > > > > > Introduce new printk() variant for convenient printouts which s=
kip '(XEN)'
> > > > > > prefix on xen console. This is needed for the case when physica=
l console is
> > > > > > owned by a domain w/ in-hypervisor UART emulation enabled.
> > > > >
> > > > > IIRC the ns8250 can only send or receive one byte (character) at =
a
> > > > > time, so you should likely put that on the console as soon as it'=
s
> > > > > received?
> > > > >
> > > > > For the hardware domain we explicitly don't buffer writes to the
> > > > > console (see guest_console_write() hardware domain special handli=
ng).
> > > > >
> > > > > I wonder however how you deal with domains that don't have the co=
nsole
> > > > > focus (ie: !=3D console_rx), as for those I think you still want =
to use
> > > > > the (d<domid>) prefix?
> > > >
> > > > Imo no matter what domain has the focus, the (d<domid>) prefix shou=
ld
> > > > always be logged. Just to avoid possible confusion.
> > >
> > > WE don't do that currently for the hardware domain, because we avoid
> > > doing any kind of line processing, as characters from the hardware
> > > domain are send straight to the console without waiting for the
> > > newline terminator (like we do for other domains).
> >
> > Right, and that's kind of special, and aiui intentionally so. These are
> > the only un-prefixed lines logged.
>
>
> I think we should provide a consistent behavior across architectures.
> The current behavior with vpl011 and dom0less on ARM is the following:
>
> - no prefix for Dom0 output
> - DOM$NUM for DomUs when not in focus, otherwise no prefix
>
> It is OK to change this behavior, but in that case I would ask that we
> change it consistently also for ARM.

Addressed in v3.

>
> > > Are you suggesting that in case of the console input being shared
> > > between multiple domains they should all be treated as plain domUs an=
d
> > > thus lines should be buffered?
> >
> > No, I'm actually not suggesting anything here beyond perhaps reducing
> > the scope of this series to just what the equivalent of vpl011 would be
> > for the 8250 / 16550 case.
>
>
> I agree with this




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 04:12:29 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 04:12:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865272.1276569 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTvWX-0003N2-0o; Sat, 04 Jan 2025 04:12:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865272.1276569; Sat, 04 Jan 2025 04:12:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTvWW-0003Mu-Tz; Sat, 04 Jan 2025 04:12:28 +0000
Received: by outflank-mailman (input) for mailman id 865272;
 Sat, 04 Jan 2025 04:12:27 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTvWV-0003LJ-NR
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 04:12:27 +0000
Received: from mail-40131.protonmail.ch (mail-40131.protonmail.ch
 [185.70.40.131]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1a8aec5b-ca52-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 05:12:25 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1a8aec5b-ca52-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1735963944; x=1736223144;
	bh=uhZP8p6QYcQZ1ODbjID9SHBqhQ44S4apHNuz3it1H24=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=AVCm7OaZbiqkDz18L3MkTF+dYUUQXjjDzaYVDm6CvdRDQChXPMRXz7H1oqYRRXTxf
	 XPKk49vEjlvJ6VH+PB6ANAzhEygvT5R1qoUTn70Nf22Mvis0JZx6kDbT8qhWesOIH7
	 4rVrze3riFaMeeIi0n+hxbq7HG3nFyKRwQx1qMrkEQ7seGGtH1U4w1tzMLaLNCrmRL
	 B6G7FvN0VrbdL88xy45syn3M3mju3/ev/R/5oCXvF6gs0NcicI5E6DEjJvsTOEvHSJ
	 D1LSN8vvOi83lvZT4GbKkP4GFZD+EIgvBmswMIlCBbhurjHPoKbYnDPMRuHFvmQo4k
	 5nnZQ3/xFER+Q==
Date: Sat, 04 Jan 2025 04:12:19 +0000
To: Jason Andryuk <jason.andryuk@amd.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2 20/35] xen/console: introduce console_owner_domid()
Message-ID: <8dyLROo-eYubZyVWoTtQTNgDkO85q0PqjHBAGAWSquyJ-zg9nI-Pw45WN4158F96EaWBkF1cqKp6s85l2MrWkZZLALuuWUoiffMcx-Fju9E=@proton.me>
In-Reply-To: <9be0addc-d4cf-47c4-937d-e1937898c010@amd.com>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-20-e9aa923127eb@ford.com> <9be0addc-d4cf-47c4-937d-e1937898c010@amd.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 471d34a585c22ae654f0ea8c41bbcbae951c9e07
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


On Tuesday, December 10th, 2024 at 2:11 PM, Jason Andryuk <jason.andryuk@am=
d.com> wrote:

>
>
> On 2024-12-05 23:41, Denis Mukhin via B4 Relay wrote:
>
> > From: Denis Mukhin dmukhin@ford.com
> >
> > console_owner_domid() is introduced to obtain the "console owner" domai=
n ID.
> >
> > The call is used in NS8250 emulator to identify the case when physical =
xen
> > console focus is owned by the domain w/ NS8250 emulator, in which case,
> > messages from guest OS are formatted w/o '(XEN)' prefix.
> >
> > Signed-off-by: Denis Mukhin dmukhin@ford.com
>
>
> Reviewed-by: Jason Andryuk jason.andryuk@amd.com
>
>
> I expected this to be used immediately by patch 21, but it is not. You
> might want to re-order it directly before its first use is introduced.
> I haven't gotten far enough to know when that is.

Yeah, sorry for that.
I ended up dropping this patch from the series.

>
> Regards,
> Jason




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 04:15:45 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 04:15:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865286.1276578 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTvZf-00043C-Eb; Sat, 04 Jan 2025 04:15:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865286.1276578; Sat, 04 Jan 2025 04:15:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTvZf-000435-Br; Sat, 04 Jan 2025 04:15:43 +0000
Received: by outflank-mailman (input) for mailman id 865286;
 Sat, 04 Jan 2025 04:15: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 <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTvZe-000428-1G
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 04:15:42 +0000
Received: from mail-10629.protonmail.ch (mail-10629.protonmail.ch
 [79.135.106.29]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8f6bda59-ca52-11ef-a0de-8be0dac302b0;
 Sat, 04 Jan 2025 05:15:41 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8f6bda59-ca52-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=gt27evmqyrdrde547uucra7x34.protonmail; t=1735964140; x=1736223340;
	bh=onIM3lIsd21cJHm00Zd1RBK7g5C0E2/fBTfTWrr//HU=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=ELafeY9Ls1Ipvp/9TLa3d7TqQdIOahnAW7n7XUbc9GHyPlCGmIBF5oMibTIcg0t5I
	 JTE4HJN4UrNdlAkNuVuwcWTCWeClPs/tmk2htFzsT9U5999aaXWMK+HOEQjjD5kW0R
	 JknWEm4A6Qs32XqtV041NKs0UF1EA1v3qhRHI74uq6mqBlr+fdqMOBNQAUxCnW8xrH
	 WMT4gyEHxBK4pJbO8Wi4uOXRBo5WyhpvQwzX/K3/xiv+I+ESeNJwHw4fpSCqRfNimx
	 YrICQf6FI0gYMh3NIqR0/JR4NFT9AbMXDKpOtfEhCs9TJevsl36e60LA6tBPKi4IVM
	 KAc0udmNiZEvg==
Date: Sat, 04 Jan 2025 04:15:36 +0000
To: Jan Beulich <jbeulich@suse.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2 20/35] xen/console: introduce console_owner_domid()
Message-ID: <VJ9ivpkbNlqfKhBlb5dL6OuoPAXK9wqD4mhgO9Qt4f0qgmuow22qFv1C7L8DlbKYo7ytdKWeV1bLaYJvTAc2Yt7sEd06XREerWER5RPx4No=@proton.me>
In-Reply-To: <d55bf6a6-5861-4b72-88b5-2aaa28ae0290@suse.com>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-20-e9aa923127eb@ford.com> <d55bf6a6-5861-4b72-88b5-2aaa28ae0290@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 40ae3ea743449f53b34ca2c8e78067b0e599500f
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


On Tuesday, December 10th, 2024 at 11:28 PM, Jan Beulich <jbeulich@suse.com=
> wrote:

>
>
> On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
>
> > From: Denis Mukhin dmukhin@ford.com
> >
> > console_owner_domid() is introduced to obtain the "console owner" domai=
n ID.
> >
> > The call is used in NS8250 emulator to identify the case when physical =
xen
> > console focus is owned by the domain w/ NS8250 emulator, in which case,
> > messages from guest OS are formatted w/o '(XEN)' prefix.
>
>
> Such messages ought to be processed through guest_printk(), which wants a
> domain pointer, not a domid_t anyway. Plus isn't that going to be
> current->domain anyway at the callsite, eliminating the need for such a
>
> helper altogether?

If the current domain is owning the physical console and printing, say, Lin=
ux
login prompt, there's no need to add "(XEN)" for every printout; adding tim=
estamps
can be disabled from Xen command line.

>
> Jan




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 04:16:08 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 04:16:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865291.1276588 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTva4-0004WH-ME; Sat, 04 Jan 2025 04:16:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865291.1276588; Sat, 04 Jan 2025 04:16:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTva4-0004WA-JK; Sat, 04 Jan 2025 04:16:08 +0000
Received: by outflank-mailman (input) for mailman id 865291;
 Sat, 04 Jan 2025 04:16:07 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTva3-0004PJ-An
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 04:16:07 +0000
Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch
 [185.70.40.133]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9dba050d-ca52-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 05:16:05 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9dba050d-ca52-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1735964164; x=1736223364;
	bh=soPD0FB9QjUSoBvYQ6OZyNdhJldQ4HFb+DqU2P123mc=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=dMNpj63stWDnMyGqP5VhbSwJ5B+Gu8UYAYNsu+98VqIBhkdxCRRM+iUky0sGgY4JD
	 9yrv+SygVRiux/oVOE3DaYiOHvOzCpNj0c+8Q4qZVvqFd2JXqvMoxvkIKIL/WgG3cp
	 A2onNzcCr2KelWpaWKNC2Ukc4SOEf3i3I7/RRl3km7FXJSfkwRVpka4GuCokfXIF+M
	 YhOTv7/D/25hXvcpCcsISQJye5++ZsFAAz97Rq2XVH9orRov8DaOolhwJ9Qb0FAlzL
	 fSbDouEMI0ImNeDD/12YjvRvDSlaKBKmdkd3MssNrtPnPWMGZqhbx+9EjGecZdjQ5g
	 1KimsUCQCHRbg==
Date: Sat, 04 Jan 2025 04:16:00 +0000
To: Jan Beulich <jbeulich@suse.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: Jason Andryuk <jason.andryuk@amd.com>, dmukhin@ford.com, Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 20/35] xen/console: introduce console_owner_domid()
Message-ID: <8Zv1e7iWdEMFJlcI1f56hKoWS6X5bS9rGnlrz4eWzol8VRYj0E9ZZqkqHtdNeRXdbwmpDGdSXk3J9JpgESSFJlCxOF8kkUA_TVrj2sW8cTQ=@proton.me>
In-Reply-To: <b0b92749-f795-4e8e-b6fd-5c02e14aa83b@suse.com>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-20-e9aa923127eb@ford.com> <9be0addc-d4cf-47c4-937d-e1937898c010@amd.com> <b0b92749-f795-4e8e-b6fd-5c02e14aa83b@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 2292f6b6c80c54d99047a538cd2d90595e460958
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


On Tuesday, December 10th, 2024 at 11:33 PM, Jan Beulich <jbeulich@suse.com=
> wrote:

>
>
> On 10.12.2024 23:11, Jason Andryuk wrote:
>
> > On 2024-12-05 23:41, Denis Mukhin via B4 Relay wrote:
> >
> > > From: Denis Mukhin dmukhin@ford.com
> > >
> > > console_owner_domid() is introduced to obtain the "console owner" dom=
ain ID.
> > >
> > > The call is used in NS8250 emulator to identify the case when physica=
l xen
> > > console focus is owned by the domain w/ NS8250 emulator, in which cas=
e,
> > > messages from guest OS are formatted w/o '(XEN)' prefix.
> > >
> > > Signed-off-by: Denis Mukhin dmukhin@ford.com
> >
> > Reviewed-by: Jason Andryuk jason.andryuk@amd.com
> >
> > I expected this to be used immediately by patch 21, but it is not. You
> > might want to re-order it directly before its first use is introduced.
> > I haven't gotten far enough to know when that is.
>
>
> Plus, no matter how far in the future it is, there'll be a window where t=
he
> Misra rule of not having unreachable code in the project is violated. New
> functions now really need introducing when their first caller appears.

I see, thank you for the explanation.

>
> Jan




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 04:27:18 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 04:27:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865304.1276598 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTvkm-0006YS-Ku; Sat, 04 Jan 2025 04:27:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865304.1276598; Sat, 04 Jan 2025 04:27:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTvkm-0006YL-IG; Sat, 04 Jan 2025 04:27:12 +0000
Received: by outflank-mailman (input) for mailman id 865304;
 Sat, 04 Jan 2025 04:27:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTvkl-0006YE-8l
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 04:27:11 +0000
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2991004e-ca54-11ef-a0de-8be0dac302b0;
 Sat, 04 Jan 2025 05:27:09 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2991004e-ca54-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1735964828; x=1736224028;
	bh=UQ4kxnUOPixt2ADCDMF9wnRjUKZuuclJXSknr+DdF/E=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=SCsEi2sG4hUS/jhPfKhNlU+XPDjCzT5TfWjI2lmpzGSZJ2ecCBL/cUoVzWKJ+Ako9
	 yU9EnRepK/CBaKo1+qCrckuvMbIuS3fCZU6CYb5bfwW0K3hPSSYCr7DebHAg5KNpNl
	 vMiyVNNxpDEWEGItkbD9ac30lDfWcPVuwEY6S6SuvY1/eyzOdhG66kLWxVvdHl9S5i
	 rt0ZqMlxH0MWq5ZC09Pd807tGLnLVsdZtc3c410jw+tNCUXKB2JiDhiFgVBpII46Gf
	 ACECMwkkI9P1gI8joNkBGg8z6yXl08Tf8pWwCZj17SWF6F0jdWY4HbEDXYU2pbHZUa
	 i+F+wMJK6kG5w==
Date: Sat, 04 Jan 2025 04:27:05 +0000
To: =?utf-8?Q?Marek_Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>, Oleksii Kurochko <oleksii.kurochko@gmail.com>
Subject: Re: [PATCH v2 00/35] Introduce NS8250 UART emulator
Message-ID: <g8DY-fhruWr6rKYFNI3VVCryQD6E1Rgq9PTBag0G3UgykgZa4N72EU_Dlha21r3lADmxuxlx3IKOViOgUCc1cU5O_tyIlYv_YZg4aXlEFR8=@proton.me>
In-Reply-To: <Z13I2xEJpkMouslw@mail-itl>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <Z13I2xEJpkMouslw@mail-itl>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 003881b63e3ba29e399273905cd45b9ac62db106
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Saturday, December 14th, 2024 at 10:05 AM, Marek Marczykowski-G=C3=B3rec=
ki <marmarek@invisiblethingslab.com> wrote:

>
>
> On Thu, Dec 05, 2024 at 08:41:30PM -0800, Denis Mukhin via B4 Relay wrote=
:
>
> > The patch series introduces initial in-hypervisor emulator for
> > NS8250/NS16x50-compatible UARTs under CONFIG_HAS_VUART_NS8250.
> >
> > In parallel domain creation scenario (hyperlaunch), NS8520 emulator hel=
ps
> > early guest OS bringup debugging, because it eliminates dependency on t=
he
> > external emulator being operational by the time domains are created. Al=
so,
> > there's no early console facility similar to vpl011 to support x86 gues=
t OS
> > bring up.
> >
> > The NS8250 emulator is disabled by default.
>
>
> On a high level, why the mechanism used by earlyprintk=3Dxen (IIUC i/o
> port 0xe9) isn't enough?

I/O port 0xe9 needs some knowledge about Xen and potentially re-building/pa=
tching
guest OSes. The latter is not always possible right away. So using legacy
COM ports makes debugging a bit easier for engineers trying to bring up
Xen configuration.

> Hyperlaunch can't start full (Xen-unaware) HVM domains anyway, so
> a requirement to use a Xen-specific interface for the console shouldn't b=
e
> an issue, no?

With hyperlaunch virtual firmware (e.g. OVMF) in HVM case will execute
in parallel, which means all serial output from virtual firmware can be
easily captured, i.e. debugging on a new hardware should be a bit easier.

My understanding that not all firmware support debug I/O port 0xe9.
Rebuilding a firmware may be a quest in itself, which can be skipped if x86
port of Xen has legacy COM UART emulation in hypervisor.

Also, my understanding (please correct me if I'm wrong) it should be
theoretically possible to craft a hyperlaunch configuration where each
non-hardware domain is headless and has its own physical block device
controller passed-through and has no dependency on hardware domain.

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




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 04:28:31 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 04:28:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865311.1276609 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTvm2-00075W-Va; Sat, 04 Jan 2025 04:28:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865311.1276609; Sat, 04 Jan 2025 04:28:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTvm2-00075P-Rm; Sat, 04 Jan 2025 04:28:30 +0000
Received: by outflank-mailman (input) for mailman id 865311;
 Sat, 04 Jan 2025 04:28:29 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTvm1-00075J-50
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 04:28:29 +0000
Received: from mail-40131.protonmail.ch (mail-40131.protonmail.ch
 [185.70.40.131]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 57bd2422-ca54-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 05:28:27 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 57bd2422-ca54-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1735964906; x=1736224106;
	bh=1u3pc9FA23xPVpS/7KMUlXEQM05gM/Fe3CmWxYn9coU=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=Tvc+mMLxaVUdrn2NGCDaj6GMcvIxG+XfjgkfPkzuswtFo/fx+y9OXJEinRURGgGa1
	 ICiE0GbVnUxAArjCjozK65Y3dk5/pTkgH6sclDe6p8inPcKN7CTw4SvN7lmNa0sUBI
	 RTS2uU21SKuzNN7iEggqLIutc359rvebHGkQ3j08a9nMMP5HZNH6nQyJvmKU7w0zub
	 O4Ulv0Fv92sCKZEGYdmjM0sPuTLTrh4MsfFTM/mv+LuabRJz/OUvgtsFODOEi/L5LD
	 whzMO7GTKvXIXZp5B0IsNPC8iP6nYHjmVoAVXZob1aPAXnBxaXQUFcxucuk2/f5GSK
	 x8axijAudTADQ==
Date: Sat, 04 Jan 2025 04:28:23 +0000
To: =?utf-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: =?utf-8?Q?Marek_Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>, dmukhin@ford.com, xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>, Oleksii Kurochko <oleksii.kurochko@gmail.com>
Subject: Re: [PATCH v2 00/35] Introduce NS8250 UART emulator
Message-ID: <YluBQMXfj1n5smogSyHCXGrYZlIpVVBGlPj-76ExLx1A31fxYjumHRuhYgxdKoZnIw8Qf6SoENCSHBx_SCnpmrdUWwZhw-kNl5XyTpmaJEA=@proton.me>
In-Reply-To: <Z1_tNLSg2vla6kY6@macbook.local>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <Z13I2xEJpkMouslw@mail-itl> <Z1_tNLSg2vla6kY6@macbook.local>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: b43fadfb1da0a084f9554482c54c172664e2eb69
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Monday, December 16th, 2024 at 1:04 AM, Roger Pau Monn=C3=A9 <roger.pau@=
citrix.com> wrote:

>
>
> On Sat, Dec 14, 2024 at 07:05:15PM +0100, Marek Marczykowski-G=C3=B3recki=
 wrote:
>
> > On Thu, Dec 05, 2024 at 08:41:30PM -0800, Denis Mukhin via B4 Relay wro=
te:
> >
> > > The patch series introduces initial in-hypervisor emulator for
> > > NS8250/NS16x50-compatible UARTs under CONFIG_HAS_VUART_NS8250.
> > >
> > > In parallel domain creation scenario (hyperlaunch), NS8520 emulator h=
elps
> > > early guest OS bringup debugging, because it eliminates dependency on=
 the
> > > external emulator being operational by the time domains are created. =
Also,
> > > there's no early console facility similar to vpl011 to support x86 gu=
est OS
> > > bring up.
> > >
> > > The NS8250 emulator is disabled by default.
> >
> > On a high level, why the mechanism used by earlyprintk=3Dxen (IIUC i/o
> > port 0xe9) isn't enough?
> > Hyperlaunch can't start full (Xen-unaware) HVM domains anyway, so
> > a requirement to use a Xen-specific interface for the console shouldn't=
 be
> > an issue, no?
>
>
> I assume the point is to provide a minimal set of non-Xen specific
> interfaces so that a guest could work if made to use only those
> interfaces. The 0xE9 hack is quite common for emergency printing, but
> it doesn't allow for input, which the ns8250 does.

Yes, my major objective was providing a simpler debugging facility under Xe=
n
w/o modifying guest OS software.

>
> Thanks, Roger.




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 04:31:26 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 04:31:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865320.1276618 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTvor-0000T6-Ax; Sat, 04 Jan 2025 04:31:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865320.1276618; Sat, 04 Jan 2025 04:31:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTvor-0000Sz-8I; Sat, 04 Jan 2025 04:31:25 +0000
Received: by outflank-mailman (input) for mailman id 865320;
 Sat, 04 Jan 2025 04:31:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTvop-0000Sd-6Y
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 04:31:23 +0000
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bf601e63-ca54-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 05:31:21 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: bf601e63-ca54-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=ahxuqxx4vzb3jct33gzt7x6wcq.protonmail; t=1735965080; x=1736224280;
	bh=Bo1HadBP70eWkjK2yccWreSwH+geo2mF8t0X/GoIaUI=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=QTxfd5foq5LUfUOXvmS/GsVv+hRpowQw0s0hmcTcEhJwYVZcFTjGudycmVD0WL6vw
	 W+zAyV6YWjVC0Rfu8Y54c4m4waShVBc4ebu8RapK+7ZyhFF3zU35ZMmnIzRRGvH2fq
	 SjGra4DnnlMgz8+3CcQjJCqzVV0+vGHWr9vvol6hwgqfx1vtwxQa00TEUcJdhVcOgJ
	 F9JUTJYgKWlZ4L4vhFjN/K/279XLh92Hg5DUyjtzYtLwx61NiS9tMs5TQXgMQnlrWr
	 VLEE1LMr5z9mwnSkiWPuL8D/i7y6N0Ji7JEL5pr7dseoyuVbMSpWYFGvEoUEzr/WH2
	 IoNmRDR2D7Olw==
Date: Sat, 04 Jan 2025 04:31:17 +0000
To: =?utf-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2 32/35] x86/hvm: add debugging facility to NS8250 UART emulator
Message-ID: <AP865H1eMMvbQMRqHoG6NtVVnkco1kGbKQW2PYsdJg4mwTpxS8sxNcin5c5ds1T7kktlprU3D2e6RB8wPmQtZAOJ6yyFt-No-pYuKO1whXk=@proton.me>
In-Reply-To: <Z1wjt-JR95YoJBMs@macbook.local>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-32-e9aa923127eb@ford.com> <Z1wjt-JR95YoJBMs@macbook.local>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: fc81cecb0a26ff36da474daf4fd8de2ca08b8b6c
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Friday, December 13th, 2024 at 4:08 AM, Roger Pau Monn=C3=A9 <roger.pau@=
citrix.com> wrote:

>
>
> On Thu, Dec 05, 2024 at 08:42:02PM -0800, Denis Mukhin via B4 Relay wrote=
:
>
> > From: Denis Mukhin dmukhin@ford.com
> >
> > Enable keyhandler mechanism for dumping state of emulated NS8250 on the
> > console.
> >
> > Signed-off-by: Denis Mukhin dmukhin@ford.com
> > ---
> > xen/arch/x86/hvm/vuart_ns8250.c | 122 +++++++++++++++++++++++++++++++++=
+++++++
> > 1 file changed, 122 insertions(+)
> >
> > diff --git a/xen/arch/x86/hvm/vuart_ns8250.c b/xen/arch/x86/hvm/vuart_n=
s8250.c
> > index 779dbd80d7be4e070ea9df3ae736ecdc662a527a..c8c75afaf2b2419d1dae999=
da1d1e400fd367791 100644
> > --- a/xen/arch/x86/hvm/vuart_ns8250.c
> > +++ b/xen/arch/x86/hvm/vuart_ns8250.c
> > @@ -25,6 +25,7 @@
> >
> > /* Development debugging */
> > #define NS8250_LOG_LEVEL 0
> > +#undef NS8250_DEBUG
> >
> > #include <xen/types.h>
> > #include <xen/event.h>
> > @@ -35,6 +36,9 @@
> > #include <xen/resource.h>
> > #include <xen/ctype.h>
> > #include <xen/param.h>
> > +#if defined(NS8250_DEBUG)
> > +#include <xen/keyhandler.h>
> > +#endif
> > #include <xen/console.h> /* console_input_domid() /
> > #include <asm/setup.h> / max_init_domid */
> > #include <asm/iocap.h>
> > @@ -625,6 +629,121 @@ static const char *ns8250_regname(
> > return reg_names[reg][dir];
> > }
> >
> > +#if defined(NS8250_DEBUG)
>
>
> I don't think the keyhandler should be gated on NS8250_DEBUG, it
> should always be present if Xen is built with vUART support.
>
> > +static void ns8250_dump(struct vuart_ns8250 *vdev)
> > +{
> > + struct xencons_interface *cons =3D vdev->cons;
>
>
> const for both.

Fixed.

>
> > + uint8_t val;
> > +
> > + printk("I/O port %02"PRIx64" IRQ %d flags %"PRIx32" owner %d\n",
>
>
> I think you want 04 for the io_addr field width? So that the width is
> always fixed, and %pd for owner.

Fixed.

>
> > + vdev->io_addr, vdev->irq,
> > + vdev->flags, vdev->owner->domain_id);
> > +
> > + printk("RX size %ld in_prod %d in_cons %d used %d\n",
> > + sizeof(cons->in),
> > + cons->in_prod, cons->in_cons,
> > + cons->in_prod - cons->in_cons);
> > +
> > + printk("TX size %ld out_prod %d out_cons %d used %d\n",
> > + sizeof(cons->out),
> > + cons->out_prod, cons->out_cons,
> > + cons->out_prod - cons->out_cons);
> > +
> > + printk("%02x RBR [ %c ] THR [ %c ] DLL %02x DLM %02x\n",
> > + UART_RBR,
> > + cons->in[MASK_XENCONS_IDX(cons->in_prod, cons)],
> > + cons->out[MASK_XENCONS_IDX(cons->out_prod, cons)],
> > + vdev->dl & 0xFFU, vdev->dl >> 8);
> > +
> > + printk("%02"PRIx8" IER %02"PRIx8"\n", UART_IER, vdev->regs[UART_IER])=
;
> > +
> > + val =3D (vdev->regs[UART_FCR] & UART_FCR_ENABLE) ? UART_IIR_FE_MASK :=
 0;
> > + val |=3D ns8250_irq_reason(vdev);
> > + printk("%02"PRIx8" FCR %02"PRIx8" IIR %02"PRIx8"\n",
> > + UART_FCR, vdev->regs[UART_FCR], val);
> > +
> > + printk("%02"PRIx8" LCR %02"PRIx8"\n", UART_LCR, vdev->regs[UART_LCR])=
;
> > + printk("%02"PRIx8" MCR %02"PRIx8"\n", UART_MCR, vdev->regs[UART_MCR])=
;
> > + printk("%02"PRIx8" LSR %02"PRIx8"\n", UART_LSR, vdev->regs[UART_LSR])=
;
> > + printk("%02"PRIx8" MSR %02"PRIx8"\n", UART_MSR, vdev->regs[UART_MSR])=
;
> > +}
> > +
> > +static struct domain *rcu_find_first_domain_with_vuart(void)
> > +{
> > + struct domain *d =3D NULL;
> > + domid_t i;
> > +
> > + for ( i =3D 0; i < max_init_domid + 1; i++ )
> > + {
> > + d =3D rcu_lock_domain_by_id(i);
> > + if ( d =3D=3D NULL )
> > + continue;
> > +
> > + if ( domain_has_vuart(d) )
> > + break;
> > +
> > + rcu_unlock_domain(d);
> > + }
> > +
> > + return d;
> > +}
> > +
> > +static void cf_check ns8250_keyhandler_show(unsigned char key)
> > +{
> > + struct vuart_ns8250 *vdev;
> > + struct domain *d;
> > +
> > + d =3D rcu_find_first_domain_with_vuart();
> > + if ( d =3D=3D NULL )
> > + return;
>
>
> I wonder whether you should dump the state of all domains with a
> vUART, rather than just a single domain?

Looks like 'q' handler is a better place for such printout.

>
> > +
> > + printk("'%c' pressed -> dumping virtual NS8250 state (d%d)\n",
> > + key, d->domain_id);
> > +
> > + vdev =3D &d->arch.hvm.vuart;
> > + spin_lock(&vdev->lock);
>
>
> This should likely be a trylock, so that you can still print the
> console state in case of a deadlock.

Fixed.

>
> > + ns8250_dump(vdev);
> > + spin_unlock(&vdev->lock);
> > +
> > + rcu_unlock_domain(d);
> > +}
> > +
> > +static void cf_check ns8250_keyhandler_irq(unsigned char key)
> > +{
> > + struct vuart_ns8250 *vdev;
> > + struct domain *d;
> > +
> > + d =3D rcu_find_first_domain_with_vuart();
> > + if ( d =3D=3D NULL )
> > + return;
> > +
> > + printk("'%c' pressed -> triggering IRQ on virtual NS8250 (d%d)\n",
> > + key, d->domain_id);
> > +
> > + vdev =3D &d->arch.hvm.vuart;
> > + spin_lock(&vdev->lock);
> > + ns8250_irq_assert(vdev);
> > + spin_unlock(&vdev->lock);
> > +
> > + rcu_unlock_domain(d);
> > +}
> > +
> > +static void ns8250_keyhandler_init(void)
> > +{
> > + register_keyhandler('1', ns8250_keyhandler_show,
> > + "dump virtual NS8250 state", 0);
> > + register_keyhandler('2', ns8250_keyhandler_irq,
> > + "trigger IRQ from virtual NS8250", 0);
> > +}
> > +#else
> > +static inline void ns8250_keyhandler_init(void)
> > +{
> > +}
> > +static inline void ns8250_dump(struct vuart_ns8250 vdev)
> > +{
> > +}
> > +#endif / #if defined(NS8250_DEBUG) /
> > +
> > /
> > * Emulate I/O access to NS8250 register.
> > */
> > @@ -688,6 +807,7 @@ static int cf_check ns8250_io_handle(
> > rc =3D X86EMUL_OKAY;
> >
> > out:
> > + ns8250_dump(vdev);
>
>
> Likely a remaining of some debugging? Printing the state for every
> access is too verbose.

That was actually helpful for debugging.
Those calls will be compiled-out in default build w/ emulator.

>
> > spin_unlock(&vdev->lock);
> >
> > return rc;
> > @@ -786,6 +906,7 @@ static int ns8250_init(struct domain *d, const stru=
ct resource *r)
> > }
> >
> > spin_lock_init(&vdev->lock);
> > + ns8250_keyhandler_init();
>
>
> The keyhandler init should be in a __initcall(), otherwise you are
> calling it for each domain creation that has a vUART.

Thank you.
I nuked vUART keyhandlers altogether in v3.

>
> Thanks, Roger.




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 04:37:26 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 04:37:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865331.1276629 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTvua-00018j-3b; Sat, 04 Jan 2025 04:37:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865331.1276629; Sat, 04 Jan 2025 04:37:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTvua-00018c-0H; Sat, 04 Jan 2025 04:37:20 +0000
Received: by outflank-mailman (input) for mailman id 865331;
 Sat, 04 Jan 2025 04:37: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 <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTvuX-00018S-T9
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 04:37:18 +0000
Received: from mail-10629.protonmail.ch (mail-10629.protonmail.ch
 [79.135.106.29]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9353c6e4-ca55-11ef-a0de-8be0dac302b0;
 Sat, 04 Jan 2025 05:37:16 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9353c6e4-ca55-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1735965435; x=1736224635;
	bh=esT0z8LBblkh1BbXHcW4EWgIxuuwWhHvlOOa3shTeWo=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=YAqgYI1fV6FYX55eG9DYRfEQ5uQKroA38h6TbR5+qoImonlZlgpqTXaLdzttkOisB
	 xR1A+v41KzWxjy46yJ0JfMV5tj1Sx2zo/Lq9ZssoPE6ZmbQF+zX75bBuocWQBRIXvn
	 ZJkSSEMk762JBk6pcXgLwRu/g9MM3b2wgbzSLUkNBFFNbHyto8LOBrdqCeJSHEzp8V
	 1jMcIt16Ai0AjQ7SLEniSBTGiFnuR1lwv98hd+JRYoxP8Geq/BCLgK032Z5I+X85Zl
	 8dgB4QXPZV9qT5vuFvhgQnpp/meCJ9TqgTlDH7sOBTEeNP0wy4rl9e1S85ozDub1dI
	 nEOGATHVdP8sg==
Date: Sat, 04 Jan 2025 04:37:09 +0000
To: Jan Beulich <jbeulich@suse.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 32/35] x86/hvm: add debugging facility to NS8250 UART emulator
Message-ID: <zsRVKo1fv9LnJ4lyhC-H5wDBGVje41HRtB-u2CK0-zFh1g-RwvW-q-tTdvt9tfu1BJbHwhTJu-s25MsnjEv1h8lhaZuIAG4AAhJpw6kmsx4=@proton.me>
In-Reply-To: <d6ffc431-34f4-46b9-b0ad-0071439ed3c6@suse.com>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-32-e9aa923127eb@ford.com> <d6ffc431-34f4-46b9-b0ad-0071439ed3c6@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 741208ac6294debe4d4fea9be74ae5a4624c22f6
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Monday, December 16th, 2024 at 7:08 AM, Jan Beulich <jbeulich@suse.com> =
wrote:

>
>
> On 06.12.2024 05:42, Denis Mukhin via B4 Relay wrote:
>
> > +static void ns8250_keyhandler_init(void)
> > +{
> > + register_keyhandler('1', ns8250_keyhandler_show,
> > + "dump virtual NS8250 state", 0);
> > + register_keyhandler('2', ns8250_keyhandler_irq,
> > + "trigger IRQ from virtual NS8250", 0);
>
>
> Characters for key handlers are a pretty scarce resource. I'm afraid I
> wouldn't want to see this committed, even if it may be helpful during
> (initial) debugging. Even more so when both handlers only ever act on
> a single domain. Imo both want to be domctl-s instead.

re: keyhandler resource: yes, thank you, I understand that.
I did not know better way to add dev debugging; I hooked to 'q' handler
in v3. Triggering vUART interrupts - dropped.

So no keyhandlers in v3.

>
> Jan




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 04:44:32 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 04:44:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865340.1276639 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTw1S-0003A2-Q1; Sat, 04 Jan 2025 04:44:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865340.1276639; Sat, 04 Jan 2025 04:44:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTw1S-00039v-MK; Sat, 04 Jan 2025 04:44:26 +0000
Received: by outflank-mailman (input) for mailman id 865340;
 Sat, 04 Jan 2025 04:44:25 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTw1R-00039p-ND
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 04:44:25 +0000
Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch
 [185.70.40.133]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 91c2bf67-ca56-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 05:44:23 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 91c2bf67-ca56-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1735965862; x=1736225062;
	bh=UZkMmFCa5yyf/U7eDUX/GoWclC//EYYi0LViPvL9q7g=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=VwMJTFx7qnvYwmEjoaKRXLrA/Rp0r/XWG4KzQQKcUAgHGfk38yMJy2ggmaEC9Z26s
	 ibJPjrlHHNJvt5OjT8DFYRwETfMXp1eLBgHr7xe1Tap2AoBDAb5MF1+3gNPbQJvZ8q
	 arcukhQu8qFhGWI4fkfUjW90vBtntv876ldIa6bJ2K8B4nK+cRQ8m5GImvuOTDEUze
	 ODpJhcAxBL1Jignllz3Yc8xlGO/1D7VIW8CCB30I9NdKa+uJ1Mxy5sjV/LCAAhqivA
	 tsEHsT8q+m6ePhbtK2SN5vAhZ0Q3fhuxy535kol8rT0Hs1+5w7Ydvy+xstGTQVNjRM
	 NcTPFRms68lMw==
Date: Sat, 04 Jan 2025 04:44:16 +0000
To: =?utf-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2 10/35] xen/domain: add get_initial_domain_id()
Message-ID: <H6Vup7H-_2Ni5ibGAsMGk8MQ_XSxov20lw5KMSjKZ0WKdHNucw6QcpqE2a_nDY1rscZ2SGNf-bdpVnn54bQW7eR4dyhL4eTq-U7YLyX9y4E=@proton.me>
In-Reply-To: <Z1nCyXhCErGBCozN@macbook.local>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-10-e9aa923127eb@ford.com> <Z1nCyXhCErGBCozN@macbook.local>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 5da3f4c7ac3ee346c994cd87f4849c6ce6d2d1ea
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


On Wednesday, December 11th, 2024 at 8:50 AM, Roger Pau Monn=C3=A9 <roger.p=
au@citrix.com> wrote:

>
>
> On Thu, Dec 05, 2024 at 08:41:40PM -0800, Denis Mukhin via B4 Relay wrote=
:
>
> > From: Denis Mukhin dmukhin@ford.com
> >
> > Move get_initial_domain_id() to a public API and enable for all archite=
ctures.
> > That is pre-requisite change for console focus switch logic cleanup.
> >
> > Signed-off-by: Denis Mukhin dmukhin@ford.com
> > ---
> > xen/arch/x86/include/asm/pv/shim.h | 4 ++--
> > xen/arch/x86/pv/shim.c | 4 ++--
> > xen/common/domain.c | 10 ++++++++++
> > xen/include/xen/domain.h | 2 ++
> > 4 files changed, 16 insertions(+), 4 deletions(-)
> >
> > diff --git a/xen/arch/x86/include/asm/pv/shim.h b/xen/arch/x86/include/=
asm/pv/shim.h
> > index 6153e27005986881ad87e9db0b555b30edc59fc0..1515ad1b0680aa11ab91a15=
2a1944fc1bb477a79 100644
> > --- a/xen/arch/x86/include/asm/pv/shim.h
> > +++ b/xen/arch/x86/include/asm/pv/shim.h
> > @@ -31,7 +31,7 @@ long cf_check pv_shim_cpu_up(void *data);
> > long cf_check pv_shim_cpu_down(void *data);
> > void pv_shim_online_memory(unsigned int nr, unsigned int order);
> > void pv_shim_offline_memory(unsigned int nr, unsigned int order);
> > -domid_t get_initial_domain_id(void);
> > +domid_t pv_shim_initial_domain_id(void);
> > uint64_t pv_shim_mem(uint64_t avail);
> > void pv_shim_fixup_e820(void);
> > const struct platform_bad_page *pv_shim_reserved_pages(unsigned int *si=
ze);
> > @@ -76,7 +76,7 @@ static inline void pv_shim_offline_memory(unsigned in=
t nr, unsigned int order)
> > {
> > ASSERT_UNREACHABLE();
> > }
> > -static inline domid_t get_initial_domain_id(void)
> > +static inline domid_t pv_shim_initial_domain_id(void)
> > {
> > return 0;
> > }
> > diff --git a/xen/arch/x86/pv/shim.c b/xen/arch/x86/pv/shim.c
> > index 81e4a0516d18b359561f471f1d96e38977661ca7..17cb30620290c76cf42251f=
70cfa4199c0e165d1 100644
> > --- a/xen/arch/x86/pv/shim.c
> > +++ b/xen/arch/x86/pv/shim.c
> > @@ -328,7 +328,7 @@ int pv_shim_shutdown(uint8_t reason)
> > }
> >
> > /* Update domain id. */
> > - d->domain_id =3D get_initial_domain_id();
> > + d->domain_id =3D pv_shim_initial_domain_id();
>
>
> Can't you leave this instance using get_initial_domain_id(), it should
> DTRT when running in pv-shim mode.

Reverted.

>
> > /* Clean the iomem range. */
> > BUG_ON(iomem_deny_access(d, 0, ~0UL));
> > @@ -1016,7 +1016,7 @@ void pv_shim_offline_memory(unsigned int nr, unsi=
gned int order)
> > }
> > }
> >
> > -domid_t get_initial_domain_id(void)
> > +domid_t pv_shim_initial_domain_id(void)
> > {
> > uint32_t eax, ebx, ecx, edx;
> >
> > diff --git a/xen/common/domain.c b/xen/common/domain.c
> > index 92263a4fbdc57159b4a32d9d4ee038f9f37804ed..2f67aa06ed50e69c27cedc8=
d7f6eb0b469fe81cd 100644
> > --- a/xen/common/domain.c
> > +++ b/xen/common/domain.c
> > @@ -45,6 +45,7 @@
> >
> > #ifdef CONFIG_X86
> > #include <asm/guest.h>
> > +#include <asm/pv/shim.h>
> > #endif
> >
> > /* Linux config option: propageted to domain0 */
> > @@ -2229,6 +2230,15 @@ int continue_hypercall_on_cpu(
> > return 0;
> > }
> >
> > +domid_t get_initial_domain_id(void)
> > +{
> > +#ifdef CONFIG_X86
> > + return pv_shim_initial_domain_id();
> > +#else
> > + return 0;
> > +#endif
> > +}
>
>
> Maybe there are further changes that make this a not suitable option,
> but won't it be better to maybe do something like:
>
> #ifndef HAS_ARCH_INITIAL_DOMID
> static inline domid_t get_initial_domain_id(void) { return 0; }
> #else
> domid_t get_initial_domain_id(void);
> #endif
>
> In a generic header, and then in an x86 header you just
>
> #define HAS_ARCH_INITIAL_DOMID
>
> The ifdefary in get_initial_domain_id() if other arches need different
> implementations seems undesirable.

IMO, existing implementation of get_initial_domain_id() looks like
a layering violation: global get_initial_domain_id() does not belong to PV
shim layer.

The current equivalent of HAS_ARCH_INITIAL_DOMID is CONFIG_PV_SHIM, so I th=
ink
there's no need to define another config flag.

After addressing Jan's feedback and then moving the code around,
I kept pv_shim_get_initial_domain_id() in PV shim and #ifdefs
in common/domain.c (similar to domain_shutdown()).

Also, I switched to using hardware_domid instead of open-coded 0.

>
> Thanks, Roger.




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 04:48:42 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 04:48:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865349.1276648 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTw5Y-0003ml-8f; Sat, 04 Jan 2025 04:48:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865349.1276648; Sat, 04 Jan 2025 04:48:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTw5Y-0003me-5z; Sat, 04 Jan 2025 04:48:40 +0000
Received: by outflank-mailman (input) for mailman id 865349;
 Sat, 04 Jan 2025 04:48:39 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTw5X-0003mY-B2
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 04:48:39 +0000
Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch
 [185.70.40.133]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 290bbc07-ca57-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 05:48:37 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 290bbc07-ca57-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1735966116; x=1736225316;
	bh=P6uwmuIvQV7K8UAC+yyJsz5cBd/6YK3hUCy+0rjhRdo=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=cqfwOpMuZorFJMrhOrA35XJES0Y5uFJiE3xXnotT2oe43Fe9E6Ozh7yGXX1hCve96
	 sxSNAduqb6Yav8RMUKJSvEgT6cF2QoRVnRArOY6YA248mYgcsYjWvtqu2j0TqY9Ay7
	 UqaxU3mQrPJYfCvDtGTHI5OdwZh3f5WkI+dWfwOe02nHSdzhLg3Eo+KvGUJ3IA5uJx
	 zoaqjh+zV5wLNRfoDfHpfLEIGdlwROTiqlhlJU0eBCBWnHzurS9mif/fZOtStZtoUq
	 j/9iwaEXfJ02YejKeyg7Yyph2uTgdt/UeXss+DB9eM7nFpihkkPyTx8Uwn8gVg2Rbw
	 hB+55XnuDaFyQ==
Date: Sat, 04 Jan 2025 04:48:31 +0000
To: =?utf-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2 24/35] xen/console: introduce hwdom_crashconsole=
Message-ID: <f1ydmZYqXWIwEzxitfa-ISv4hUrzb_m_9QLywWnzjbqsIlLdIaGdiev8lh5_UPZ8MsmOm_DebjAZ8EoYmyzpptaPj3uUtZHWjDfcjZB8ih8=@proton.me>
In-Reply-To: <Z1rXEtHPjjjEPKw3@macbook.local>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-24-e9aa923127eb@ford.com> <Z1rXEtHPjjjEPKw3@macbook.local>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 467dc90b3fcb019879975b1c07f1e30b5f29c3c2
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Thursday, December 12th, 2024 at 4:29 AM, Roger Pau Monn=C3=A9 <roger.pa=
u@citrix.com> wrote:

>
>
> On Thu, Dec 05, 2024 at 08:41:54PM -0800, Denis Mukhin via B4 Relay wrote=
:
>
> > From: Denis Mukhin dmukhin@ford.com
> >
> > The new command line switch `hwdom_crashconsole=3DBOOL` allows to switc=
h serial
> > console input focus to xen for machine state inspection using keyhandle=
r
> > mechanism after the hardware domain crashes.
> >
> > The new command line switch is aliased via `dom0=3D...,crashconsole` kn=
ob.
> >
> > Such functionality can be useful while debugging dom0 bringup.
> >
> > Signed-off-by: Denis Mukhin dmukhin@ford.com
> > ---
> > docs/misc/xen-command-line.pandoc | 5 +++++
> > xen/arch/x86/dom0_build.c | 2 ++
> > xen/common/domain.c | 14 +++++++++++++-
> > xen/include/xen/domain.h | 1 +
> > 4 files changed, 21 insertions(+), 1 deletion(-)
> >
> > diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-=
line.pandoc
> > index 293dbc1a957ba6e668fd4d55d58e84f643822126..fb77d7dca1ea517f79d6713=
aa6909422f31e7724 100644
> > --- a/docs/misc/xen-command-line.pandoc
> > +++ b/docs/misc/xen-command-line.pandoc
> > @@ -806,6 +806,7 @@ Specify the bit width of the DMA heap.
> >
> > ### dom0
> > =3D List of [ pv | pvh, shadow=3D<bool>, verbose=3D<bool>,
> > + crashconsole=3D<bool>,
> > cpuid-faulting=3D<bool>, msr-relaxed=3D<bool> ] (x86)
> >
> > =3D List of [ sve=3D<integer> ] (Arm64)
> > @@ -839,6 +840,10 @@ Controls for how dom0 is constructed on x86 system=
s.
> > information during the dom0 build. It defaults to the compile time choi=
ce
> > of `CONFIG_VERBOSE_DEBUG`.
> >
> > +* The `crashconsole` boolean instructs Xen to drop into emergency cons=
ole
> > + in case of dom0 crash. May be useful for dom0 bringup on a custom
>
>
> I think the 'a' is unneeded -> "on custom hardware."

Yep. Thank you.

>
>
> I think however this would be clearer as:
>
> "The `crashconsole` boolean instructs Xen to switch input console
> focus to the hypervisor when dom0 shuts down and avoid performing
> dom0 domain destruction. Should only be used for debugging
> purposes."

Fixed.

>
> It's IMO not clear what "instructs Xen to drop into emergency console"
> implies for Xen.
>
> > + hardware.
> > +
> > * The `cpuid-faulting` boolean is an interim option, is only applicable=
 to
> > PV dom0, and defaults to true.
> >
> > diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
> > index e8f5bf5447bc47a6daa3d95787106a4c11e80d31..706aeec0ecbb565a415edbf=
b33ca2fd72967c560 100644
> > --- a/xen/arch/x86/dom0_build.c
> > +++ b/xen/arch/x86/dom0_build.c
> > @@ -286,6 +286,8 @@ int __init parse_arch_dom0_param(const char *s, con=
st char *e)
> > opt_dom0_cpuid_faulting =3D val;
> > else if ( (val =3D parse_boolean("msr-relaxed", s, e)) >=3D 0 )
> > opt_dom0_msr_relaxed =3D val;
> > + else if ( (val =3D parse_boolean("crashconsole", s, e)) >=3D 0 )
> > + opt_hwdom_crashconsole =3D !!val;
> > else
> > return -EINVAL;
> >
> > diff --git a/xen/common/domain.c b/xen/common/domain.c
> > index aab546c0a8535e4f007cbbc9c5c552bcf66b5807..4fe69f294158dda7b2e0b9d=
98d49c34e04131cb8 100644
> > --- a/xen/common/domain.c
> > +++ b/xen/common/domain.c
> > @@ -56,6 +56,13 @@ unsigned int xen_processor_pmbits =3D XEN_PROCESSOR_=
PM_PX;
> > bool opt_dom0_vcpus_pin;
> > boolean_param("dom0_vcpus_pin", opt_dom0_vcpus_pin);
> >
> > +/*
> > + * Hardware domain crash handler: if true, do not halt machine, but sw=
itch to
> > + * Xen console for debugging.
> > + */
> > +bool opt_hwdom_crashconsole;
>
>
> __ro_after_init.

Done.

>
> > +boolean_param("hwdom_crashconsole", opt_hwdom_crashconsole);
>
>
> This option doesn't seem to be documented at all in
> xen-command-line.pandoc?

Thanks; fixed.

>
> > +
> > /* Protect updates/reads (resp.) of domain_list and domain_hash. */
> > DEFINE_SPINLOCK(domlist_update_lock);
> > DEFINE_RCU_READ_LOCK(domlist_read_lock);
> > @@ -1138,7 +1145,12 @@ int domain_shutdown(struct domain *d, u8 reason)
> > reason =3D d->shutdown_code;
> >
> > if ( is_hardware_domain(d) )
> > - hwdom_shutdown(reason);
> > + {
> > + if ( opt_hwdom_crashconsole )
> > + console_set_owner(DOMID_XEN);
>
>
> Don't you need to pause all domain vCPUs and return early here to
> avoid executing the rest of the function, that will likely destroy the
> domain?
>
> Maybe there's something I'm missing that prevents the hardware domain
> destruction.

The point of this change is to drop the user to Xen console on crash instea=
d
of unconditional system restart. TBH, I did not plan for "freezing" the dom=
ain
state. I also tested w/ non-hyperlaunch PV dom0 only (I used kexec to
start PV dom0 which was crashing).

My understanding, if I followed the code correctly, all is fine.
domain_destroy() is not called because asm_domain_crash_synchronous(), whic=
h
handles the crash, just spins around do_softirq():

void asm_domain_crash_synchronous(unsigned long addr)
{
...

    __domain_crash(current->domain); // that will call domain_crash()

    for ( ; ; )
        do_softirq();
}

>
> Thanks, Roger.




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 05:19:33 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 05:19:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865358.1276658 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTwZB-00007r-Fx; Sat, 04 Jan 2025 05:19:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865358.1276658; Sat, 04 Jan 2025 05:19:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTwZB-00007k-DO; Sat, 04 Jan 2025 05:19:17 +0000
Received: by outflank-mailman (input) for mailman id 865358;
 Sat, 04 Jan 2025 05:19: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 <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTwZ8-00006g-Tm
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 05:19:15 +0000
Received: from mail-10631.protonmail.ch (mail-10631.protonmail.ch
 [79.135.106.31]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6ed65d01-ca5b-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 06:19:12 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 6ed65d01-ca5b-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1735967950; x=1736227150;
	bh=/UYjyA+oK7mFTIA5K+v6KxEop26cmT9VoQMQK6vunsM=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=QrHgtOhAiKvT1iLwrgpsfo+XMRV/Gl3wAyo8aeAu7hxReg4AuhxyG29KHRZHwwZQm
	 SLHbM48ZbR1tspPc30z2ejjBd6M9y+8luMVHKoRj1De6Z6aU25ipQprxlMx2/+pcQe
	 frmdrwU70Lyyfd8FXqfRZ8VIMUAv+X9V+CIMhypLWVYyjtmm1u8Tq+iJirTIV0DXDy
	 LryCYjvrcORbB1iYLXTigZriL0OKhgOCgjGS2DuSp7gQYH6+FLOvZAq9lHhqgFjJ3a
	 kU29ge9KWDKjo+sYXQHsHyqDRBaxEvur3NgNuzyXFH1AJURUllbB+jV26Mk6dIocA8
	 RUmVBQRJzpiFg==
Date: Sat, 04 Jan 2025 05:19:07 +0000
To: =?utf-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2 33/35] x86/domain: implement domain_has_vuart()
Message-ID: <Tz4Idf7hUa85arksVC6UYYRNbhinY-0wHXqxIInbLCWGNiGZSEIvGNGLmICNLmHK5o7m6MUMhnUlrJX10WO1XHhyRSgCX7Gknz0xBGZJiD8=@proton.me>
In-Reply-To: <Z1wnUzDCPDzHKr6o@macbook.local>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-33-e9aa923127eb@ford.com> <Z1wnUzDCPDzHKr6o@macbook.local>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 6517eb9cb37cd4c7de575d4ebbdb7dfb4f0b593e
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Friday, December 13th, 2024 at 4:23 AM, Roger Pau Monn=C3=A9 <roger.pau@=
citrix.com> wrote:

>
>
> On Thu, Dec 05, 2024 at 08:42:03PM -0800, Denis Mukhin via B4 Relay wrote=
:
>
> > From: Denis Mukhin dmukhin@ford.com
> >
> > Add new emulation flag for virtual UART on x86 and plumb it through the=
 stack.
> >
> > This change enables NS8250 emulator initialization.
> >
> > Signed-off-by: Denis Mukhin dmukhin@ford.com
> > ---
> > tools/libs/light/libxl_x86.c | 6 +++++-
> > tools/ocaml/libs/xc/xenctrl.ml | 1 +
> > tools/ocaml/libs/xc/xenctrl.mli | 1 +
> > tools/python/xen/lowlevel/xc/xc.c | 4 +---
> > xen/arch/x86/domain.c | 8 +++++---
> > xen/arch/x86/include/asm/domain.h | 7 ++++---
> > xen/include/public/arch-x86/xen.h | 14 +++++++++++++-
> > 7 files changed, 30 insertions(+), 11 deletions(-)
> >
> > diff --git a/tools/libs/light/libxl_x86.c b/tools/libs/light/libxl_x86.=
c
> > index a3164a3077fec7e1b81a34074894dc646954a49a..de5f05e18cb0671bb031b10=
1b9a7159eb0fe0178 100644
> > --- a/tools/libs/light/libxl_x86.c
> > +++ b/tools/libs/light/libxl_x86.c
> > @@ -8,7 +8,11 @@ int libxl__arch_domain_prepare_config(libxl__gc gc,
> > {
> > switch(d_config->c_info.type) {
> > case LIBXL_DOMAIN_TYPE_HVM:
> > - config->arch.emulation_flags =3D (XEN_X86_EMU_ALL & ~XEN_X86_EMU_VPCI=
);
> > + config->arch.emulation_flags =3D XEN_X86_EMU_ALL;
> > + config->arch.emulation_flags &=3D ~XEN_X86_EMU_VPCI;
> > + / Virtual UART is selected at Xen build time */
> > + config->arch.emulation_flags &=3D ~XEN_X86_EMU_VUART;
> > +
> > if (!libxl_defbool_val(d_config->b_info.u.hvm.pirq))
> > config->arch.emulation_flags &=3D ~XEN_X86_EMU_USE_PIRQ;
> > break;
> > diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenct=
rl.ml
> > index 2690f9a92316b812ad3d3ff0e1c36823070adb4a..647239b3e55e88b00eb8e97=
73a5267894cbbae54 100644
> > --- a/tools/ocaml/libs/xc/xenctrl.ml
> > +++ b/tools/ocaml/libs/xc/xenctrl.ml
> > @@ -47,6 +47,7 @@ type x86_arch_emulation_flags =3D
> > | X86_EMU_PIT
> > | X86_EMU_USE_PIRQ
> > | X86_EMU_VPCI
> > + | X86_EMU_VUART
> >
> > type x86_arch_misc_flags =3D
> > | X86_MSR_RELAXED
> > diff --git a/tools/ocaml/libs/xc/xenctrl.mli b/tools/ocaml/libs/xc/xenc=
trl.mli
> > index febbe1f6ae3f10c5abe45eaa3c06a8a67d9ba268..4f5f64c786e83e8a0c3dd3c=
db0460f7095de4a62 100644
> > --- a/tools/ocaml/libs/xc/xenctrl.mli
> > +++ b/tools/ocaml/libs/xc/xenctrl.mli
> > @@ -41,6 +41,7 @@ type x86_arch_emulation_flags =3D
> > | X86_EMU_PIT
> > | X86_EMU_USE_PIRQ
> > | X86_EMU_VPCI
> > + | X86_EMU_VUART
> >
> > type x86_arch_misc_flags =3D
> > | X86_MSR_RELAXED
> > diff --git a/tools/python/xen/lowlevel/xc/xc.c b/tools/python/xen/lowle=
vel/xc/xc.c
> > index 9feb12ae2b16e48cb5d0c3c45044ae226f152f2d..e54308956efc7061d58d216=
6ec9a95bc1dcd1781 100644
> > --- a/tools/python/xen/lowlevel/xc/xc.c
> > +++ b/tools/python/xen/lowlevel/xc/xc.c
> > @@ -159,9 +159,7 @@ static PyObject *pyxc_domain_create(XcObject *self,
> >
> > #if defined (__i386) || defined(x86_64)
> > if ( config.flags & XEN_DOMCTL_CDF_hvm )
> > - config.arch.emulation_flags =3D XEN_X86_EMU_ALL &
> > - ~(XEN_X86_EMU_VPCI |
> > - XEN_X86_EMU_USE_PIRQ);
> > + config.arch.emulation_flags =3D XEN_X86_EMU_HVM_ALLOWABLE;
> > #elif defined (arm) || defined(aarch64)
> > config.arch.gic_version =3D XEN_DOMCTL_CONFIG_GIC_NATIVE;
> > #else
> > diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> > index c88d422a64544531c1e1058fa484364bb4277d1e..439da7adc92a3a8eb481075=
bf834da5f9670dd54 100644
> > --- a/xen/arch/x86/domain.c
> > +++ b/xen/arch/x86/domain.c
> > @@ -752,10 +752,10 @@ static bool emulation_flags_ok(const struct domai=
n *d, uint32_t emflags)
> > if ( is_hardware_domain(d) &&
> > emflags !=3D (X86_EMU_VPCI | X86_EMU_LAPIC | X86_EMU_IOAPIC) )
> > return false;
> > +
> > + emflags &=3D ~X86_EMU_VUART;
>
>
> I think you want to allow X86_EMU_VUART only for domains created by
> Xen itself, so X86_EMU_VUART can only be valid if system_state <
> SYS_STATE_active.

I think vUART should be configurable for domains created via toolstack
as well as for domains created by Xen.

But, TBH, I did not plan for toolstack integration in this series.

For Xen-created domains enabling emulator for HVM domains only and enabling
it globally (since that's debugging/bringup only) seemed enough for the
initial change.

>
> > if ( !is_hardware_domain(d) &&
> > - /* HVM PIRQ feature is user-selectable. */
> > - (emflags & ~X86_EMU_USE_PIRQ) !=3D
> > - (X86_EMU_ALL & ~(X86_EMU_VPCI | X86_EMU_USE_PIRQ)) &&
> > + xen_emflags_allowable(emflags) !=3D XEN_X86_EMU_HVM_ALLOWABLE &&
> > emflags !=3D X86_EMU_LAPIC )
> > return false;
> > }
> > @@ -806,6 +806,8 @@ int arch_domain_create(struct domain *d,
> >
> > emflags =3D config->arch.emulation_flags;
> >
> > + if ( IS_ENABLED(CONFIG_HAS_VUART_NS8250) && is_hvm_domain(d) )
> > + emflags |=3D XEN_X86_EMU_VUART;
>
>
> Doesn't this need to be limited to domains created by Xen itself, as
> otherwise it's the toolstack that should specify the XEN_X86_EMU_VUART
> flag, and even then the recommendation would be to use the vUART from
> QEMU?

re: toolstack: I agree, toolstack should support vUART configuration.
I plan to address it in the follow on series.

>
> > if ( is_hardware_domain(d) && is_pv_domain(d) )
> > emflags |=3D XEN_X86_EMU_PIT;
> >
> > diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/a=
sm/domain.h
> > index c1d0d1f47324e8cc678a4c76c43f86820a89e7b3..dacea6e1aad46e9f8710b22=
02bb81203c5e92807 100644
> > --- a/xen/arch/x86/include/asm/domain.h
> > +++ b/xen/arch/x86/include/asm/domain.h
> > @@ -484,7 +484,8 @@ struct arch_domain
> > #define X86_EMU_VPCI 0
> > #endif
> >
> > -#define X86_EMU_PIT XEN_X86_EMU_PIT
> > +#define X86_EMU_PIT XEN_X86_EMU_PIT
>
>
> Unintended indentation change?

Actually, this change was intentional: it fixes the alignment against
previous #ifdefs.

>
> > +#define X86_EMU_VUART XEN_X86_EMU_VUART
> >
> > /* This must match XEN_X86_EMU_ALL in xen.h */
> > #define X86_EMU_ALL (X86_EMU_LAPIC | X86_EMU_HPET | \
> > @@ -492,7 +493,7 @@ struct arch_domain
> > X86_EMU_IOAPIC | X86_EMU_PIC | \
> > X86_EMU_VGA | X86_EMU_IOMMU | \
> > X86_EMU_PIT | X86_EMU_USE_PIRQ | \
> > - X86_EMU_VPCI)
> > + X86_EMU_VPCI | X86_EMU_VUART)
> >
> > #define has_vlapic(d) (!!((d)->arch.emulation_flags & X86_EMU_LAPIC))
> > #define has_vhpet(d) (!!((d)->arch.emulation_flags & X86_EMU_HPET))
> > @@ -507,7 +508,7 @@ struct arch_domain
> > #define has_vpci(d) (!!((d)->arch.emulation_flags & X86_EMU_VPCI))
> >
> > /* NB: same symbol as in Arm port */
> > -#define domain_has_vuart(d) false
> > +#define domain_has_vuart(d) (!!((d)->arch.emulation_flags & X86_EMU_VU=
ART))
> >
> > #define gdt_ldt_pt_idx(v) \
> > ((v)->vcpu_id >> (PAGETABLE_ORDER - GDT_LDT_VCPU_SHIFT))
> > diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arc=
h-x86/xen.h
> > index fc2487986642a7694578ab9d2f5f16d09761bff8..e7922e3f9ddc1742a464d22=
8807279839df31e52 100644
> > --- a/xen/include/public/arch-x86/xen.h
> > +++ b/xen/include/public/arch-x86/xen.h
> > @@ -283,13 +283,25 @@ struct xen_arch_domainconfig {
> > #define XEN_X86_EMU_USE_PIRQ (1U<<_XEN_X86_EMU_USE_PIRQ)
> > #define _XEN_X86_EMU_VPCI 10
> > #define XEN_X86_EMU_VPCI (1U<<_XEN_X86_EMU_VPCI)
> > +#define _XEN_X86_EMU_VUART 11
> > +#define XEN_X86_EMU_VUART (1U<<_XEN_X86_EMU_VUART)
> >
> > #define XEN_X86_EMU_ALL (XEN_X86_EMU_LAPIC | XEN_X86_EMU_HPET | \
> > XEN_X86_EMU_PM | XEN_X86_EMU_RTC | \
> > XEN_X86_EMU_IOAPIC | XEN_X86_EMU_PIC | \
> > XEN_X86_EMU_VGA | XEN_X86_EMU_IOMMU | \
> > XEN_X86_EMU_PIT | XEN_X86_EMU_USE_PIRQ |\
> > - XEN_X86_EMU_VPCI)
> > + XEN_X86_EMU_VPCI | XEN_X86_EMU_VUART)
> > +
> > +/* HVM PIRQ feature is user-selectable (libxl). */
> > +#define XEN_X86_EMU_HVM_SELECTABLE (XEN_X86_EMU_VPCI | \
> > + XEN_X86_EMU_USE_PIRQ | \
> > + XEN_X86_EMU_VUART)
>
>
> XEN_X86_EMU_HVM_OPTIONAL is maybe clearer?

Looks like it, thanks for suggestion!
Fixed.

>
> Albeit PVH is kind of HVM.

PVH does not have vPIC so there's some more work to enable vUART
for PVH on x86: emulator currently supports only ISA IRQs.

>
> > +
> > +#define xen_emflags_allowable(x) ((x) & ~XEN_X86_EMU_HVM_SELECTABLE)
> > +
> > +#define XEN_X86_EMU_HVM_ALLOWABLE xen_emflags_allowable(XEN_X86_EMU_AL=
L)
>
>
> XEN_X86_EMU_HVM_BASELINE I think would also be better?

Fixed.

>
> Thanks, Roger.




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 05:26:12 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 05:26:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865367.1276668 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTwfo-0001t1-6X; Sat, 04 Jan 2025 05:26:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865367.1276668; Sat, 04 Jan 2025 05:26:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTwfo-0001su-3b; Sat, 04 Jan 2025 05:26:08 +0000
Received: by outflank-mailman (input) for mailman id 865367;
 Sat, 04 Jan 2025 05:26:06 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTwfm-0001so-9J
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 05:26:06 +0000
Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch
 [185.70.40.134]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 64e2f647-ca5c-11ef-a0de-8be0dac302b0;
 Sat, 04 Jan 2025 06:26:05 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 64e2f647-ca5c-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1735968364; x=1736227564;
	bh=6O2TyodfIn+2B+Sx2boWvlNccNa0ciWTQzitCKF/U4E=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=GrqeVho4mVruNVlEcr/EM3T9yoVb8QmGwoz1wELYhnt/ewIRNfSJSxQgv7Ce0qK2T
	 Szy/lHO7oKS/qj0nwrDF2xAmflJzCatgWHuaaKk0TZ7FQEFr3kQPLLqF8scGYEBA/a
	 I+YTggRRbRQMbCBp5qNFP7djiM2t5p5EGQxNsg9nAmLr5AQd1mMyo7pM07693IzYTo
	 0/UD4epfyBgHze5SF6fI/VFI4QY7PhtcwuyuWn3HpDyn+/3phl8itL0IaUkDJCyVf1
	 YVA3f+sww51dbwhSs7ob0zObg8Mi38+akJRf4CBB/1LjAM8YGfllrInhRaehW577Ts
	 F/1VnUogw5TFA==
Date: Sat, 04 Jan 2025 05:26:01 +0000
To: Jan Beulich <jbeulich@suse.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 33/35] x86/domain: implement domain_has_vuart()
Message-ID: <naBtNUtu9na6gqKutYIswJRWPfnix56y6duz-hNxtz1R3od6xMldtUGGrhRDi43js60XIEjV7H7g1v8E-qDBPACT5ISccOaJz2jYuylB8Pk=@proton.me>
In-Reply-To: <e344d00e-4cd5-4a11-9d6a-046fa135fd80@suse.com>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-33-e9aa923127eb@ford.com> <e344d00e-4cd5-4a11-9d6a-046fa135fd80@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 03e756ec86211a1376ee33933b5c4b05e042c7f5
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Monday, December 16th, 2024 at 7:11 AM, Jan Beulich <jbeulich@suse.com> =
wrote:

>
>
> On 06.12.2024 05:42, Denis Mukhin via B4 Relay wrote:
>
> > --- a/tools/libs/light/libxl_x86.c
> > +++ b/tools/libs/light/libxl_x86.c
> > @@ -8,7 +8,11 @@ int libxl__arch_domain_prepare_config(libxl__gc gc,
> > {
> > switch(d_config->c_info.type) {
> > case LIBXL_DOMAIN_TYPE_HVM:
> > - config->arch.emulation_flags =3D (XEN_X86_EMU_ALL & ~XEN_X86_EMU_VPCI=
);
> > + config->arch.emulation_flags =3D XEN_X86_EMU_ALL;
> > + config->arch.emulation_flags &=3D ~XEN_X86_EMU_VPCI;
> > + / Virtual UART is selected at Xen build time */
> > + config->arch.emulation_flags &=3D ~XEN_X86_EMU_VUART;
>
>
> That is all domains, even post-boot created ones, only ever get the same
> setting?

Toolstack cannot control vUART configuration yet. vUART can be enabled for
HVM domains only at this point and only globally, which seemed enough for t=
he
initial implementation.
PVH needs some more work because PVH does not have vPIC.

I did not plan to enable per-domain configuration in this patch series (pla=
n
to address in the follow on series). The emulator is disabled in default Xe=
n
configuration, so it should not affect the existing default behavior.

>
> Jan




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 05:26:44 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 05:26:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865374.1276679 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTwgO-0002Ql-Kd; Sat, 04 Jan 2025 05:26:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865374.1276679; Sat, 04 Jan 2025 05:26:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTwgO-0002Qe-G1; Sat, 04 Jan 2025 05:26:44 +0000
Received: by outflank-mailman (input) for mailman id 865374;
 Sat, 04 Jan 2025 05:26:43 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTwgN-0001so-KV
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 05:26:43 +0000
Received: from mail-10631.protonmail.ch (mail-10631.protonmail.ch
 [79.135.106.31]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7b6ae491-ca5c-11ef-a0de-8be0dac302b0;
 Sat, 04 Jan 2025 06:26:42 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 7b6ae491-ca5c-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1735968401; x=1736227601;
	bh=Fzjy7R4ZFUGFhDTFtaOf688KQhnM2jDDlws+2C47Wno=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=T/xBDYDhnMx2KUr5JiOTiljXx/DiT8CuPF1WesH6B3nf/hDAtOocgsHjR9tjtoM/S
	 frCwBCEPJvbly3PdTbROUSjDV7K6JHCKzun/ygGkqHGNsgkdz90p5outfxH2vhnZNV
	 pYvwoMN6oMXS2gZjNpfwVkpQLU2PkaPwogHLeQ/SLMhBJSIJHMZhV3mwIs+xN/uyRo
	 OnkIsYDaaY4CNSMugsEANi61kEb2Db/ElnO80MLuNszjUyaTykk67L5KV7djXrNPOQ
	 maCEn7Wj5LVdAILwB5YT+1oJWqb5c8agii1vh9arQsg27b51L0ooTY9i/3aCodOlYX
	 MM54FjUjHbIUw==
Date: Sat, 04 Jan 2025 05:26:37 +0000
To: Stefano Stabellini <sstabellini@kernel.org>
From: Denis Mukhin <dmkhn@proton.me>
Cc: =?utf-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, dmukhin@ford.com, xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>
Subject: Re: [PATCH v2 33/35] x86/domain: implement domain_has_vuart()
Message-ID: <2f5Un81oSi9Cg2nylEVS3nbS-KczBOwkCPFt_7QE_fhVLa_-H-xLIwpsNnO2Oe_T0LCBq8jfqCeWg8CrrYj7wou0M_0rpvK8T3I58Rd2lEk=@proton.me>
In-Reply-To: <alpine.DEB.2.22.394.2412131245300.463523@ubuntu-linux-20-04-desktop>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-33-e9aa923127eb@ford.com> <Z1wnUzDCPDzHKr6o@macbook.local> <alpine.DEB.2.22.394.2412131245300.463523@ubuntu-linux-20-04-desktop>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: f4aa9c7dd8a4cc57d73f5760d243223b2ab90040
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Friday, December 13th, 2024 at 12:45 PM, Stefano Stabellini <sstabellini=
@kernel.org> wrote:

>
>
> On Fri, 13 Dec 2024, Roger Pau Monn=C3=A9 wrote:
>
> > On Thu, Dec 05, 2024 at 08:42:03PM -0800, Denis Mukhin via B4 Relay wro=
te:
> >
> > > From: Denis Mukhin dmukhin@ford.com
> > >
> > > Add new emulation flag for virtual UART on x86 and plumb it through t=
he stack.
> > >
> > > This change enables NS8250 emulator initialization.
> > >
> > > Signed-off-by: Denis Mukhin dmukhin@ford.com
> > > ---
> > > tools/libs/light/libxl_x86.c | 6 +++++-
> > > tools/ocaml/libs/xc/xenctrl.ml | 1 +
> > > tools/ocaml/libs/xc/xenctrl.mli | 1 +
> > > tools/python/xen/lowlevel/xc/xc.c | 4 +---
> > > xen/arch/x86/domain.c | 8 +++++---
> > > xen/arch/x86/include/asm/domain.h | 7 ++++---
> > > xen/include/public/arch-x86/xen.h | 14 +++++++++++++-
> > > 7 files changed, 30 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/tools/libs/light/libxl_x86.c b/tools/libs/light/libxl_x8=
6.c
> > > index a3164a3077fec7e1b81a34074894dc646954a49a..de5f05e18cb0671bb031b=
101b9a7159eb0fe0178 100644
> > > --- a/tools/libs/light/libxl_x86.c
> > > +++ b/tools/libs/light/libxl_x86.c
> > > @@ -8,7 +8,11 @@ int libxl__arch_domain_prepare_config(libxl__gc gc,
> > > {
> > > switch(d_config->c_info.type) {
> > > case LIBXL_DOMAIN_TYPE_HVM:
> > > - config->arch.emulation_flags =3D (XEN_X86_EMU_ALL & ~XEN_X86_EMU_VP=
CI);
> > > + config->arch.emulation_flags =3D XEN_X86_EMU_ALL;
> > > + config->arch.emulation_flags &=3D ~XEN_X86_EMU_VPCI;
> > > + / Virtual UART is selected at Xen build time */
> > > + config->arch.emulation_flags &=3D ~XEN_X86_EMU_VUART;
> > > +
> > > if (!libxl_defbool_val(d_config->b_info.u.hvm.pirq))
> > > config->arch.emulation_flags &=3D ~XEN_X86_EMU_USE_PIRQ;
> > > break;
> > > diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xen=
ctrl.ml
> > > index 2690f9a92316b812ad3d3ff0e1c36823070adb4a..647239b3e55e88b00eb8e=
9773a5267894cbbae54 100644
> > > --- a/tools/ocaml/libs/xc/xenctrl.ml
> > > +++ b/tools/ocaml/libs/xc/xenctrl.ml
> > > @@ -47,6 +47,7 @@ type x86_arch_emulation_flags =3D
> > > | X86_EMU_PIT
> > > | X86_EMU_USE_PIRQ
> > > | X86_EMU_VPCI
> > > + | X86_EMU_VUART
> > >
> > > type x86_arch_misc_flags =3D
> > > | X86_MSR_RELAXED
> > > diff --git a/tools/ocaml/libs/xc/xenctrl.mli b/tools/ocaml/libs/xc/xe=
nctrl.mli
> > > index febbe1f6ae3f10c5abe45eaa3c06a8a67d9ba268..4f5f64c786e83e8a0c3dd=
3cdb0460f7095de4a62 100644
> > > --- a/tools/ocaml/libs/xc/xenctrl.mli
> > > +++ b/tools/ocaml/libs/xc/xenctrl.mli
> > > @@ -41,6 +41,7 @@ type x86_arch_emulation_flags =3D
> > > | X86_EMU_PIT
> > > | X86_EMU_USE_PIRQ
> > > | X86_EMU_VPCI
> > > + | X86_EMU_VUART
> > >
> > > type x86_arch_misc_flags =3D
> > > | X86_MSR_RELAXED
> > > diff --git a/tools/python/xen/lowlevel/xc/xc.c b/tools/python/xen/low=
level/xc/xc.c
> > > index 9feb12ae2b16e48cb5d0c3c45044ae226f152f2d..e54308956efc7061d58d2=
166ec9a95bc1dcd1781 100644
> > > --- a/tools/python/xen/lowlevel/xc/xc.c
> > > +++ b/tools/python/xen/lowlevel/xc/xc.c
> > > @@ -159,9 +159,7 @@ static PyObject *pyxc_domain_create(XcObject *sel=
f,
> > >
> > > #if defined (__i386) || defined(x86_64)
> > > if ( config.flags & XEN_DOMCTL_CDF_hvm )
> > > - config.arch.emulation_flags =3D XEN_X86_EMU_ALL &
> > > - ~(XEN_X86_EMU_VPCI |
> > > - XEN_X86_EMU_USE_PIRQ);
> > > + config.arch.emulation_flags =3D XEN_X86_EMU_HVM_ALLOWABLE;
> > > #elif defined (arm) || defined(aarch64)
> > > config.arch.gic_version =3D XEN_DOMCTL_CONFIG_GIC_NATIVE;
> > > #else
> > > diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> > > index c88d422a64544531c1e1058fa484364bb4277d1e..439da7adc92a3a8eb4810=
75bf834da5f9670dd54 100644
> > > --- a/xen/arch/x86/domain.c
> > > +++ b/xen/arch/x86/domain.c
> > > @@ -752,10 +752,10 @@ static bool emulation_flags_ok(const struct dom=
ain *d, uint32_t emflags)
> > > if ( is_hardware_domain(d) &&
> > > emflags !=3D (X86_EMU_VPCI | X86_EMU_LAPIC | X86_EMU_IOAPIC) )
> > > return false;
> > > +
> > > + emflags &=3D ~X86_EMU_VUART;
> >
> > I think you want to allow X86_EMU_VUART only for domains created by
> > Xen itself, so X86_EMU_VUART can only be valid if system_state <
> > SYS_STATE_active.
> >
> > > if ( !is_hardware_domain(d) &&
> > > - /* HVM PIRQ feature is user-selectable. */
> > > - (emflags & ~X86_EMU_USE_PIRQ) !=3D
> > > - (X86_EMU_ALL & ~(X86_EMU_VPCI | X86_EMU_USE_PIRQ)) &&
> > > + xen_emflags_allowable(emflags) !=3D XEN_X86_EMU_HVM_ALLOWABLE &&
> > > emflags !=3D X86_EMU_LAPIC )
> > > return false;
> > > }
> > > @@ -806,6 +806,8 @@ int arch_domain_create(struct domain *d,
> > >
> > > emflags =3D config->arch.emulation_flags;
> > >
> > > + if ( IS_ENABLED(CONFIG_HAS_VUART_NS8250) && is_hvm_domain(d) )
> > > + emflags |=3D XEN_X86_EMU_VUART;
> >
> > Doesn't this need to be limited to domains created by Xen itself, as
> > otherwise it's the toolstack that should specify the XEN_X86_EMU_VUART
> > flag, and even then the recommendation would be to use the vUART from
> > QEMU?
>
>
> While I agree with you that this feature is really useful mostly for the
> domains created by Xen, as for those there is no other way to get early
> output, I think Denis has been also testing successfully this feature
> with PVH or HVM domains created by the toolstack.

I tested w/ HVM only for now.
PVH needs some more work as it does not have vPIC.

>
> I'll let you decide whether you want to expose the feature to xl created
> domains, but yes my understanding is that they already work with this
> series. One benefit would be that for PVH domains you could get early
> output without having to start QEMU, but I'll leave this to you.

TBH, I planned to enable xl support in the follow on series.




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 05:31:41 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 05:31:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865386.1276688 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTwl7-0004Br-3G; Sat, 04 Jan 2025 05:31:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865386.1276688; Sat, 04 Jan 2025 05:31:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTwl7-0004Bk-0W; Sat, 04 Jan 2025 05:31:37 +0000
Received: by outflank-mailman (input) for mailman id 865386;
 Sat, 04 Jan 2025 05:31: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 <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTwl6-0004Az-0g
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 05:31:36 +0000
Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch
 [185.70.40.134]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 28ead655-ca5d-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 06:31:34 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 28ead655-ca5d-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1735968692; x=1736227892;
	bh=Y2QpLaztw8EV5eJ5IwUGXHfhnelAt9fPr0RSiVmbtoA=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=gvLHYAfZl+PUQ5gStsEjOfsWcclPZ7nMpQI/nFFUvdJvxeDVC33m/dgZkUn14dayQ
	 q6pP/GV816GjcJ2oK/kkU9/j4guMWG/BVJBaolsNIh9jmaYQLYrkJc0i9DFT5QnVPY
	 qVLOJOKoZMzhWPKY8ZfPT2jXeb+cRWCZdszU0cy0HccKFxnJmhIHjTIH13HhiGxs6d
	 9Ui4ipqOa0Bvl+M3W2oeBALpDpEsOFlrXMy7bloCpE2FCYbBIJlZSG4PdIeIXiNEuW
	 Ff4kCy70v0yY+vGSeAEWYx9Jp51GKAxMyB1uxMQ6Fn9MmSAi3FmnPQikd/uodtc6wM
	 mmQNThPDYLXhQ==
Date: Sat, 04 Jan 2025 05:31:26 +0000
To: Jan Beulich <jbeulich@suse.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 31/35] x86/hvm: introduce NS8250 UART emulator
Message-ID: <DJo9IkTvGXsao_hA4njnkX9OVYVR6tXdo95AeBiT8wGtbPb7UKQjLCqqIset3bJ3JbLqogcIb4wPqNXJ-2GFwyrW_UIvRg5Nt9QhpG0hfyo=@proton.me>
In-Reply-To: <3be247cc-900b-48f3-98f3-0d97532ede76@suse.com>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-31-e9aa923127eb@ford.com> <3be247cc-900b-48f3-98f3-0d97532ede76@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 0e628c91d7ef6a2ab55ce30b3d720dc93b297c51
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


On Monday, December 16th, 2024 at 7:04 AM, Jan Beulich <jbeulich@suse.com> =
wrote:

>
>
> On 06.12.2024 05:42, Denis Mukhin via B4 Relay wrote:
>
> > From: Denis Mukhin dmukhin@ford.com
> >
> > Add initial in-hypervisor emulator for NS8250/NS16x50-compatible UARTs =
under
> > CONFIG_HAS_VUART_NS8250.
> >
> > In parallel domain creation scenario (hyperlaunch), NS8520 emulator hel=
ps
> > early guest OS bringup debugging, because it eliminates dependency on t=
he
> > external emulator being operational by the time domains are created. Al=
so,
> > there's no early console facility similar to vpl011 to support x86 gues=
t OS
> > bring up.
> >
> > By default, CONFIG_HAS_VUART_NS8250 enables emulatio of NS8250 at I/O p=
ort
> > 0x3f8, IRQ#4 in guest OS.
> >
> > Limitations:
> > - Only x86;
> > - Only Linux guest tested so far;
> > - Only legacy COM{1,2,3,4} resources, no customization;
> > - Only Xen console as a backend, no inter-domain communication (similar=
 to
> > vpl011 on Arm);
> > - Only 8-bit characters;
> > - Baud rate is not emulated;
> > - FIFO-less mode is not emulated properly;
>
>
> With in particular this, why would it be called 8250 emulation in the fir=
st
> place? The driver Xen uses for itself is in ns16550.c; I'd suggest to cal=
l
> the child here ns16550 emulation right away, using vns16550.c as the file
> name.

NS8250 is the predecessor of NS16550, registers are defined in 8250-uart.h,
hence I used vuart_ns8250.c.

I do not have a strong opinion on this naming. 16550 makes sense because
all UARTs have a FIFO now.

Renamed to vuart-ns16550.c.

>
> > --- a/xen/arch/x86/hvm/Kconfig
> > +++ b/xen/arch/x86/hvm/Kconfig
> > @@ -61,3 +61,17 @@ config HVM_FEP
> > for use in production.
> >
> > If unsure, say N.
> > +
> > +config HAS_VUART_NS8250
> > + bool "NS8250-compatible UART Emulation"
>
>
> HAS_* options may not have prompts; they merely declare something to the
> rest of the build system.

There are examples in the code using HAS_xxx configuration exactly the way
I used it. Specifically, all physical UART drivers are declared under HAS_x=
xx
(drivers/char/Kconfig).

I reworked that part.

>
> > + depends on HVM && HAS_IOPORTS
>
>
> Why HAS_IOPORTS?

It is meant to highlight the fact that MMIO-based UART is not supported.
It is not currently possible to enable the emulator for, say, Arm platforms=
.

>
> > + default n
>
>
> No need for this.

Fixed.

>
> > --- a/xen/arch/x86/hvm/Makefile
> > +++ b/xen/arch/x86/hvm/Makefile
> > @@ -29,3 +29,4 @@ obj-y +=3D vm_event.o
> > obj-y +=3D vmsi.o
> > obj-y +=3D vpic.o
> > obj-y +=3D vpt.o
> > +obj-$(CONFIG_HAS_VUART_NS8250) +=3D vuart_ns8250.o
>
>
> If the vuart name pretix is to remain, then please avoid underscores in
> the names of new files, in favor of dashes.

I've seen such request few times on the mailing list and it seems the
recommendation is not followed all the time in the code base.

It's just all files in xen/arch/x86/hvm have underscores instead of
dashes.

IMO, this rule needs an explicit documentation in the coding style
guide. I'm happy to follow either dash- or underscore-way.

Addressed.

>
> > --- /dev/null
> > +++ b/xen/arch/x86/hvm/vuart_ns8250.c
> > @@ -0,0 +1,886 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only /
> > +/
> > + * NS8250-compatible UART Emulator.
> > + *
> > + * Limitations:
> > + * - Only x86;
> > + * - Only Linux guest tested so far;
> > + * - Only legacy COM{1,2,3,4} resources, no customization;
> > + * - Only Xen console as a backend, no inter-domain communication (sim=
ilar to
> > + * vpl011 on Arm);
> > + * - Only 8-bit characters;
> > + * - Baud rate is not emulated;
> > + * - FIFO-less mode is not emulated properly;
> > + * - RX FIFO interrupt moderation (FCR) is not emulated properly, TL16=
C750
> > + * has special FCR handling;
> > + * - No integration w/ VM snapshotting (HVM_REGISTER_SAVE_RESTORE() an=
d
> > + * friends);
> > + * - Assumes no ISA-device IRQ sharing;
> > + * - MMIO-based UART is not supported;
> > + * - PCI UART is not supported.
> > + /
> > +
> > +#define pr_fmt(fmt) "ns8250: " fmt
> > +#define pr_log_level hvm_ns8250_log_level
> > +
> > +/ Development debugging /
> > +#define NS8250_LOG_LEVEL 0
> > +
> > +#include <xen/types.h>
> > +#include <xen/event.h>
> > +#include <xen/lib.h>
> > +#include <xen/errno.h>
> > +#include <xen/sched.h>
> > +#include <xen/trace.h>
> > +#include <xen/resource.h>
> > +#include <xen/ctype.h>
> > +#include <xen/param.h>
> > +#include <xen/console.h> / console_input_domid() /
> > +#include <asm/setup.h> / max_init_domid */
> > +#include <asm/iocap.h>
> > +#include <asm/hvm/hvm.h>
> > +#include <asm/hvm/io.h>
> > +#include <asm/hvm/vuart_ns8250.h>
> > +
> > +#if !defined(pr_fmt)
> > +#define pr_fmt(fmt) fmt
> > +#endif
> > +
> > +#if !defined(pr_log_level)
> > +#define pr_log_level 0
> > +#endif
> > +
> > +#define pr_err(fmt, args...) \
> > + gprintk(KERN_ERR, pr_fmt(fmt), ## args)
> > +#define pr_warn(fmt, args...) \
> > + if (pr_log_level) gprintk(KERN_WARNING, pr_fmt(fmt), ## args)
> > +#define pr_info(fmt, args...) \
> > + if (pr_log_level) gprintk(KERN_INFO, pr_fmt(fmt), ## args)
> > +#define pr_debug(fmt, args...) \
> > + if (pr_log_level) gprintk(KERN_DEBUG, pr_fmt(fmt), ## args)
>
>
> On top of Roger's remark here: If you use such wrapper macros, then
> please arrange for them to be usable in arbitrary context. Think of
>
> if ( condition )
> pr_info(...);
> else
> ...

Done.

>
> > +/*
> > + * NS8250 emulator state machine logging (development only)
> > + * FIXME: use similar to parse_guest_loglvl()
> > + */
> > +static unsigned int __read_mostly hvm_ns8250_log_level =3D NS8250_LOG_=
LEVEL;
> > +integer_param("hvm.ns8250.log_level", hvm_ns8250_log_level);
>
>
> How can this be a command line option, when there may be many domains
> making use of the in-Xen driver? This and ...

TBH, I did not plan for configuring vUARTs per-domain. In its current shape=
,
the emulator is strictly for debugging purposes and not ready to be enabled
in production setup. Which means global configuration is fine, IMO. But the=
n
I decided that it's trivial to allow selecton of any of x86 legacy UARTs.

Such global configuration was hooked into the command line parsing because
it allows to test xen + dom0 w/o rebuild.

Reworked to Kconfig setting.

>
> > +/*
> > + * Default emulated NS8250 resources.
> > + * If not specified, COM1 (I/O port 0x3f8, IRQ#4) is emulated.
> > + * FIXME: follow Linux'es console=3D syntax or re-use
> > + * ns16550_parse_port_config().
> > + */
> > +static char __read_mostly hvm_ns8250_console[64];
> > +string_param("hvm.ns8250.console", hvm_ns8250_console);
>
>
> ... this need to be per-domain settings; a command line option may be
> applicable to Dom0 alone.
>
> > +/* I/O access mask */
> > +static const uint32_t io_access_mask[] =3D {
> > + [0] =3D 0X00000000U,
> > + [1] =3D 0X000000FFU,
> > + [2] =3D 0X0000FFFFU,
> > + [4] =3D 0XFFFFFFFFU,
> > +};
>
>
> I don't think this is needed; we're doing similar port I/O emulation in
> various other places, without resorting to such arrays.

Dropped.

>
> > +/*
> > + * Legacy IBM PC NS8250 resources.
> > + * There are only 4 I/O port ranges, hardcoding all of them here.
> > + */
> > +static const struct {
> > + const char *name;
> > + const struct resource *res;
> > +} ns8250_x86_legacy_uarts[4] =3D {
> > + [0] =3D {
> > + .name =3D "com1",
> > + .res =3D (const struct resource[]){
> > + { .type =3D IORESOURCE_IO, .addr =3D 0x3F8, .size =3D UART_MAX },
>
>
> Considering this, ...
>
> > +static int ns8250_io_write8(
> > + struct vuart_ns8250 *vdev, uint32_t reg, uint8_t *data)
> > +{
> > + uint8_t val;
> > + int rc =3D 0;
> > +
> > + val =3D data;
> > +
> > + switch ( reg )
> > + {
> > + / DLAB=3D0 /
> > + case UART_THR:
> > + if ( vdev->regs[UART_MCR] & UART_MCR_LOOP )
> > + {
> > + ns8250_fifo_rx_putchar(vdev, val);
> > + vdev->regs[UART_LSR] |=3D UART_LSR_OE;
> > + }
> > + else
> > + ns8250_fifo_tx_putchar(vdev, val);
> > +
> > + vdev->flags |=3D NS8250_IRQ_THRE_PENDING;
> > +
> > + break;
> > +
> > + case UART_IER:
> > + if ( val & vdev->regs[UART_IER] & UART_IER_ETHREI )
> > + vdev->flags |=3D NS8250_IRQ_THRE_PENDING;
> > +
> > + vdev->regs[UART_IER] =3D val & UART_IER_MASK;
> > +
> > + break;
> > +
> > + case UART_FCR: / WO /
> > + if ( val & UART_FCR_CLRX )
> > + ns8250_fifo_rx_reset(vdev);
> > +
> > + if ( val & UART_FCR_CLTX )
> > + ns8250_fifo_tx_reset(vdev);
> > +
> > + if ( !(val & UART_FCR_ENABLE) )
> > + val =3D 0;
> > +
> > + vdev->regs[UART_FCR] =3D val & (UART_FCR_ENABLE |
> > + UART_FCR_DMA |
> > + UART_FCR_TRG_MASK);
> > +
> > + break;
> > +
> > + case UART_LCR:
> > + vdev->regs[UART_LCR] =3D val;
> > + break;
> > +
> > + case UART_MCR: {
> > + uint8_t msr_curr, msr_next, msr_delta;
> > +
> > + msr_curr =3D vdev->regs[UART_MSR];
> > + msr_next =3D 0;
> > + msr_delta =3D 0;
> > +
> > + / Set modem status /
> > + if ( val & UART_MCR_LOOP )
> > + {
> > + if ( val & UART_MCR_DTR )
> > + msr_next |=3D UART_MSR_DSR;
> > + if ( val & UART_MCR_RTS )
> > + msr_next |=3D UART_MSR_CTS;
> > + if ( val & UART_MCR_OUT1 )
> > + msr_next |=3D UART_MSR_RI;
> > + if ( val & UART_MCR_OUT2 )
> > + msr_next |=3D UART_MSR_DCD;
> > + }
> > + else
> > + msr_next |=3D UART_MSR_DCD | UART_MSR_DSR | UART_MSR_CTS;
> > +
> > + / Calculate changes in modem status /
> > + if ( (msr_curr & UART_MSR_CTS) ^ (msr_next & UART_MSR_CTS) )
> > + msr_delta |=3D UART_MSR_DCTS;
> > + if ( (msr_curr & UART_MCR_RTS) ^ (msr_next & UART_MCR_RTS) )
> > + msr_delta |=3D UART_MSR_DDSR;
> > + if ( (msr_curr & UART_MSR_RI) & (msr_next & UART_MSR_RI) )
> > + msr_delta |=3D UART_MSR_TERI;
> > + if ( (msr_curr & UART_MSR_DCD) ^ (msr_next & UART_MSR_DCD) )
> > + msr_delta |=3D UART_MSR_DDCD;
> > +
> > + vdev->regs[UART_MCR] =3D val & UART_MCR_MASK;
> > + vdev->regs[UART_MSR] =3D msr_next | msr_delta;
> > +
> > + break;
> > + }
> > +
> > + case UART_LSR: / RO /
> > + case UART_MSR: / RO /
> > + rc =3D -EINVAL;
> > + break;
> > +
> > + /
> > + * NB: Firmware like OVMF rely on SCR presence to initialize the ns825=
0
> > + * driver.
> > + /
> > + case UART_SCR:
> > + vdev->regs[UART_SCR] =3D val;
> > + break;
> > +
> > + / DLAB=3D1 */
> > + case UART_MAX + UART_DLL:
>
>
> ... how can you go at or past UART_MAX here and ...
>
> > + vdev->dl =3D (vdev->dl & 0xFF00U) | val;
> > + break;
> > +
> > + case UART_MAX + UART_DLM:
>
>
> ... here? I notice a caller up the tree sets things up like this, but thi=
s
> feels pretty fragile. How would one easily spot all producers and consume=
rs
> without also hitting all other uses of UART_MAX?

The idea was to flatten the register address space regardless DLAB.
I also agree with your point: having all register handling stated explicitl=
y
makes the code more understandable.

Reworked.

>
> > +static int cf_check ns8250_io_handle(
> > + int dir, unsigned int addr, unsigned int size, uint32_t *data)
> > +{
> > +#define op(dir) (((dir) =3D=3D IOREQ_WRITE) ? 'W' : 'R')
> > + struct domain *d =3D rcu_lock_current_domain();
> > + struct vuart_ns8250 *vdev =3D &d->arch.hvm.vuart;
> > + uint32_t offset, reg;
> > + int rc;
> > +
> > + spin_lock(&vdev->lock);
> > +
> > + BUG_ON( vdev->owner !=3D d );
> > +
> > + if ( !(vdev->flags & NS8250_READY) )
> > + {
> > + pr_err("%c io 0x%04x %d 0x%08"PRIx32": propagate to external I/O emul=
ator\n",
> > + op(dir), addr, size, *data);
> > + rc =3D X86EMUL_UNHANDLEABLE;
> > + goto out;
> > + }
> > +
> > + reg =3D addr - vdev->io_addr;
> > + BUG_ON( reg >=3D UART_MAX );
> > + if ( reg % size !=3D 0 )
> > + {
> > + pr_err("%c 0x%04x %d 0x%08"PRIx32": unaligned access\n",
> > + op(dir), addr, size, data & io_access_mask[size]);
> > + rc =3D X86EMUL_OKAY;
> > + goto out;
> > + }
> > +
> > + / Redirect access to divisor latch registers */
> > + if ( !!(vdev->regs[UART_LCR] & UART_LCR_DLAB)
> > + && (reg =3D=3D UART_DLL || reg =3D=3D UART_DLM) )
> > + offset =3D UART_MAX + reg;
> > + else
> > + offset =3D reg;
> > +
> > + if ( dir =3D=3D IOREQ_WRITE )
> > + {
> > + pr_debug("%c 0x%04x %d 0x%08"PRIx32" %s[0x%02"PRIx32"]\n",
> > + op(dir), addr, size,
> > + *data & io_access_mask[size],
> > + ns8250_regname(vdev, offset, dir), reg);
> > + rc =3D ns8250_io_write(vdev, offset, size, data);
> > + }
> > + else
> > + {
> > + rc =3D ns8250_io_read(vdev, offset, size, data);
> > + pr_debug("%c 0x%04x %d 0x%08"PRIx32" %s[0x%02"PRIx32"]\n",
> > + op(dir), addr, size,
> > + *data & io_access_mask[size],
> > + ns8250_regname(vdev, offset, dir), reg);
> > + }
> > + if ( rc )
> > + pr_err("%c 0x%04x %d 0x%08"PRIx32": unsupported access\n",
> > + op(dir), addr, size, *data & io_access_mask[size]);
> > + rc =3D X86EMUL_OKAY;
> > +
> > +out:
>
>
> Nit: Missing indentation (see ./CODING_STYLE). Also elsewhere.

Fixed.

>
> > --- /dev/null
> > +++ b/xen/arch/x86/include/asm/hvm/vuart_ns8250.h
> > @@ -0,0 +1,75 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only /
> > +/
> > + * NS8250-compatible UART Emulator.
> > + /
> > +#if !defined(HVM__VUART_NS8250_H)
> > +#define HVM__VUART_NS8250_H
> > +
> > +#include <xen/spinlock.h>
> > +#include <xen/8250-uart.h>
> > +#include <public/io/console.h> / xencons_interface */
>
>
> I assume you mean ...
>
> > +/*
> > + * NS8250 emulator operational flags.
> > + /
> > +enum {
> > + / Emulator is ready /
> > + NS8250_READY =3D BIT(0, U),
> > + / Trigger re-delivery of THRE interrupt /
> > + NS8250_IRQ_THRE_PENDING =3D BIT(1, U),
> > +};
> > +
> > +/
> > + * Virtual NS8250 device state.
> > + /
> > +struct vuart_ns8250 {
> > + uint16_t dl; / Divisor Latch /
> > + uint8_t regs[UART_MAX]; / Registers /
> > + uint32_t flags; / Virtual device flags /
> > + uint64_t io_addr; / Guest I/O region base address /
> > + uint64_t io_size; / Guest I/O region size /
> > + int irq; / Guest IRQ# */
> > + struct xencons_interface cons; / Emulated RX/TX FIFOs */
>
>
> ... this use, but that doesn't even require a forward decl of the struct
> in C (in C++ such a forward decl would be all that's needed).

I declared vUART handler as `void *` in hvm_domain and moved all the data
types to .c, so there's no need in header file at all.

>
> Jan




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 06:28:48 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 06:28:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865395.1276698 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTxeB-0002kn-50; Sat, 04 Jan 2025 06:28:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865395.1276698; Sat, 04 Jan 2025 06:28:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTxeB-0002kg-2E; Sat, 04 Jan 2025 06:28:31 +0000
Received: by outflank-mailman (input) for mailman id 865395;
 Sat, 04 Jan 2025 06:28:29 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=EL/b=T4=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tTxe8-0002k1-98
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 06:28:29 +0000
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 19a735e2-ca65-11ef-a0de-8be0dac302b0;
 Sat, 04 Jan 2025 07:28:24 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 19a735e2-ca65-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=7lcxlqtw2rakhomkj4gh3fuu44.protonmail; t=1735972102; x=1736231302;
	bh=5Rr9Hy5aGEbnz3kOGNY8spsmTkT2Iv5Y1dKdOmEiBU4=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=mPMIg/aR268UQJzQKHLDJT3cILZBdV+nn6DLR0/wh/ScBzCivSMC4F97/u8I5JV3B
	 NgTkjfXb/UndX0VYdjw+ndCqmZsWn5CQwAwKT1/Ll3H7WmSGa1H97N+X5PvgXiIaIK
	 VxkRR4LX3YejgGnNr2KBoj4cX7eHnxrZ6tAqd/IZ0xxWsSq5Uq3Iy/xWE80aghhwKB
	 LLdCQwogNVNkpTlsCTPonU9UXBM1j8MdEQMJb0Ypp50iJnhxmEO/1AqHh3lmR4krqS
	 O7zCN2EqJccth4omg0Qcl5H2I4uUGnI95kJcT4Emq0KLa0BPZF6ULtdXjfiThzcmNZ
	 7IavNkyyzNTNw==
Date: Sat, 04 Jan 2025 06:28:18 +0000
To: =?utf-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2 31/35] x86/hvm: introduce NS8250 UART emulator
Message-ID: <7BvSh3ExOh8GocRqFUZc15WZsR9O1EngfdYF_PZrkIyjYdaNMEfS4yDIVDxnn1VtusTm65wl16SpanH2esD3iChDTutkhsdRGeGEtgIuxU0=@proton.me>
In-Reply-To: <Z1wd4iAmVzv1ISPZ@macbook.local>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-31-e9aa923127eb@ford.com> <Z1wd4iAmVzv1ISPZ@macbook.local>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 17968b6e9da562268a7c4be88f56f511cf8f04d0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Friday, December 13th, 2024 at 3:43 AM, Roger Pau Monn=C3=A9 <roger.pau@=
citrix.com> wrote:

>
>
> On Thu, Dec 05, 2024 at 08:42:01PM -0800, Denis Mukhin via B4 Relay wrote=
:
>
> > From: Denis Mukhin dmukhin@ford.com
> >
> > Add initial in-hypervisor emulator for NS8250/NS16x50-compatible UARTs =
under
> > CONFIG_HAS_VUART_NS8250.
> >
> > In parallel domain creation scenario (hyperlaunch), NS8520 emulator hel=
ps
> > early guest OS bringup debugging, because it eliminates dependency on t=
he
> > external emulator being operational by the time domains are created. Al=
so,
> > there's no early console facility similar to vpl011 to support x86 gues=
t OS
> > bring up.
> >
> > By default, CONFIG_HAS_VUART_NS8250 enables emulatio of NS8250 at I/O p=
ort
>
>
> emulatio -> emulation

Fixed.

>
> > 0x3f8, IRQ#4 in guest OS.
> >
> > Limitations:
> > - Only x86;
> > - Only Linux guest tested so far;
> > - Only legacy COM{1,2,3,4} resources, no customization;
> > - Only Xen console as a backend, no inter-domain communication (similar=
 to
> > vpl011 on Arm);
> > - Only 8-bit characters;
> > - Baud rate is not emulated;
> > - FIFO-less mode is not emulated properly;
> > - RX FIFO interrupt moderation (FCR) is not emulated properly, TL16C750
> > has special FCR handling;
> > - No integration w/ VM snapshotting (HVM_REGISTER_SAVE_RESTORE() and
> > friends);
> > - Assumes no ISA-device IRQ sharing;
> > - MMIO-based UART is not supported.
>
>
> Do you have a reference to the specification you have used to
> implement the driver?

I used these two (added links in the code comment):
  - https://download.freebsd.org/doc/en/articles/serial-uart/serial-uart_en=
.pdf
  - https://www.ti.com/lit/ds/symlink/tl16c550c.pdf

>
> Most of the comments below are quite generic, I haven't really looked
> into the implementation details of the ns8520 emulated registers.

Thanks a lot for the review!

>
> > Signed-off-by: Denis Mukhin dmukhin@ford.com
> > ---
> > xen/arch/x86/hvm/Kconfig | 14 +
> > xen/arch/x86/hvm/Makefile | 1 +
> > xen/arch/x86/hvm/hvm.c | 13 +
> > xen/arch/x86/hvm/vuart_ns8250.c | 886 ++++++++++++++++++++++++++++
> > xen/arch/x86/include/asm/hvm/domain.h | 5 +
> > xen/arch/x86/include/asm/hvm/vuart_ns8250.h | 75 +++
> > 6 files changed, 994 insertions(+)
> >
> > diff --git a/xen/arch/x86/hvm/Kconfig b/xen/arch/x86/hvm/Kconfig
> > index 361bb6572e633f3cf0fc972a3b391e8341c33361..af6e698b8be0d82af94b00c=
0cfdaf9a2bc24b154 100644
> > --- a/xen/arch/x86/hvm/Kconfig
> > +++ b/xen/arch/x86/hvm/Kconfig
> > @@ -61,3 +61,17 @@ config HVM_FEP
> > for use in production.
> >
> > If unsure, say N.
> > +
> > +config HAS_VUART_NS8250
> > + bool "NS8250-compatible UART Emulation"
> > + depends on HVM && HAS_IOPORTS
> > + default n
> > + help
> > + In-hypervisor NS8250/NS16x50 UART emulation.
> > +
> > + Only legacy PC I/O ports are emulated.
> > +
> > + This is strictly for testing purposes (early HVM guest console), and =
not
> > + appropriate for use in production.
>
>
> If it's strictly speaking for debug purposes, then it might be helpful
> to tie it to CONFIG_DEBUG, or if maybe that's too broad, make it tied
> to CONFIG_EXPERT, so that it's clear builds wit the option enabled
> won't be security supported.

I made it dependent on CONFIG_EXPERT.

>
> > +
> > + If unsure, say N.
> > diff --git a/xen/arch/x86/hvm/Makefile b/xen/arch/x86/hvm/Makefile
> > index 4c1fa5c6c2bf75d336b39f343241bfced5b91b09..14761435e0694109f815da6=
3289666c0f1cbf0ce 100644
> > --- a/xen/arch/x86/hvm/Makefile
> > +++ b/xen/arch/x86/hvm/Makefile
> > @@ -29,3 +29,4 @@ obj-y +=3D vm_event.o
> > obj-y +=3D vmsi.o
> > obj-y +=3D vpic.o
> > obj-y +=3D vpt.o
> > +obj-$(CONFIG_HAS_VUART_NS8250) +=3D vuart_ns8250.o
> > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> > index 493b699c708949b2109c26573a107565543f5d45..db61af7defc5f5da795b7a6=
13fe4d32fbff7d93e 100644
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -55,6 +55,7 @@
> > #include <asm/hvm/monitor.h>
> > #include <asm/hvm/viridian.h>
> > #include <asm/hvm/vm_event.h>
> > +#include <asm/hvm/vuart_ns8250.h>
> > #include <asm/altp2m.h>
> > #include <asm/mtrr.h>
> > #include <asm/apic.h>
> > @@ -679,6 +680,15 @@ int hvm_domain_initialise(struct domain *d,
> > if ( rc !=3D 0 )
> > goto fail1;
> >
> > + if ( domain_has_vuart(d) )
> > + {
> > + rc =3D domain_vuart_init(d);
> > + if ( rc =3D=3D 0 )
> > + d->is_console =3D true;
> > + else if ( rc !=3D -ENODEV )
> > + goto out_vioapic_deinit;
>
>
> Why do you shallow the ENODEV error? If a user has asked for a vUART,
> and there's no support in Xen it should error hard IMO, rather than
> ignoring it and continue building the domain.

re: shallowing error: my thought was - since this emulator is for debugging
purposes at this point, it is better to proceed w/ domain creation, rather
than disallowing domain creation.

Fixed.

>
> IMO emulation_flags_ok() should prevent hvm_domain_initialise() from
> being called with vUART when there's no support built-in.

Fixed.

>
> > + }
> > +
> > stdvga_init(d);
> >
> > rtc_init(d);
> > @@ -699,6 +709,9 @@ int hvm_domain_initialise(struct domain *d,
> > return 0;
> >
> > fail2:
> > + if ( domain_has_vuart(d) )
> > + domain_vuart_free(d);
> > + out_vioapic_deinit:
> > vioapic_deinit(d);
> > fail1:
> > if ( is_hardware_domain(d) )
> > diff --git a/xen/arch/x86/hvm/vuart_ns8250.c b/xen/arch/x86/hvm/vuart_n=
s8250.c
> > new file mode 100644
> > index 0000000000000000000000000000000000000000..779dbd80d7be4e070ea9df3=
ae736ecdc662a527a
> > --- /dev/null
> > +++ b/xen/arch/x86/hvm/vuart_ns8250.c
> > @@ -0,0 +1,886 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only /
> > +/
> > + * NS8250-compatible UART Emulator.
> > + *
> > + * Limitations:
> > + * - Only x86;
> > + * - Only Linux guest tested so far;
> > + * - Only legacy COM{1,2,3,4} resources, no customization;
> > + * - Only Xen console as a backend, no inter-domain communication (sim=
ilar to
> > + * vpl011 on Arm);
> > + * - Only 8-bit characters;
> > + * - Baud rate is not emulated;
> > + * - FIFO-less mode is not emulated properly;
> > + * - RX FIFO interrupt moderation (FCR) is not emulated properly, TL16=
C750
> > + * has special FCR handling;
> > + * - No integration w/ VM snapshotting (HVM_REGISTER_SAVE_RESTORE() an=
d
> > + * friends);
> > + * - Assumes no ISA-device IRQ sharing;
> > + * - MMIO-based UART is not supported;
> > + * - PCI UART is not supported.
>
>
> IMO putting the limitations here is likely to make them go out of
> sync, noting in the commit message should be enough.

I cleaned up commit message and kept those limitations in the source
code only.

>
> > + /
> > +
> > +#define pr_fmt(fmt) "ns8250: " fmt
> > +#define pr_log_level hvm_ns8250_log_level
> > +
> > +/ Development debugging /
> > +#define NS8250_LOG_LEVEL 0
> > +
> > +#include <xen/types.h>
> > +#include <xen/event.h>
> > +#include <xen/lib.h>
> > +#include <xen/errno.h>
> > +#include <xen/sched.h>
> > +#include <xen/trace.h>
> > +#include <xen/resource.h>
> > +#include <xen/ctype.h>
> > +#include <xen/param.h>
> > +#include <xen/console.h> / console_input_domid() */
>
>
> Includes would be better sorted alphabetically if possible.

Done.

>
> > +#include <asm/setup.h> /* max_init_domid */
> > +#include <asm/iocap.h>
> > +#include <asm/hvm/hvm.h>
> > +#include <asm/hvm/io.h>
> > +#include <asm/hvm/vuart_ns8250.h>
> > +
> > +#if !defined(pr_fmt)
> > +#define pr_fmt(fmt) fmt
> > +#endif
> > +
> > +#if !defined(pr_log_level)
> > +#define pr_log_level 0
> > +#endif
> > +
> > +#define pr_err(fmt, args...) \
> > + gprintk(KERN_ERR, pr_fmt(fmt), ## args)
> > +#define pr_warn(fmt, args...) \
> > + if (pr_log_level) gprintk(KERN_WARNING, pr_fmt(fmt), ## args)
> > +#define pr_info(fmt, args...) \
> > + if (pr_log_level) gprintk(KERN_INFO, pr_fmt(fmt), ## args)
> > +#define pr_debug(fmt, args...) \
> > + if (pr_log_level) gprintk(KERN_DEBUG, pr_fmt(fmt), ## args)
>
>
> Is there any reason you cannot directly use gprintk() and need those
> wrappers?

Yes, I need to control emulator's printouts w/o changing global setting so
I can debug it; I plan for MMIO-based UART which will need more debugging.

>
> If the code has been imported from another project it would be good to
> have a reference, so that we can pickup updates in the future.

I looked at QEMU, bhyve and ACRN emulators as hints.

>
> > +
> > +/*
> > + * NS8250 emulator state machine logging (development only)
> > + * FIXME: use similar to parse_guest_loglvl()
> > + */
> > +static unsigned int __read_mostly hvm_ns8250_log_level =3D NS8250_LOG_=
LEVEL;
> > +integer_param("hvm.ns8250.log_level", hvm_ns8250_log_level);
>
>
> WE don't have any existing instances of command line options with
> dots, and also the documentation addition to xen-command-line.pandoc
> seems to be missing from this patch.

I reworked these options to Kconfig for now. Kconfig looks a better
alternative to control settings globally.

>
> My recommendation would be that the code here just uses normal logs
> levels, users can adjust the minimum log level of pritned messages.
> Adding ad-hoc log level settings for each subsystem just causes
> confusion.

I think I want to stick to having a way to control the verbosity of that
emulator independently of the rest of Xen subsystems. That helps debugging
this code. Initially, I looked into re-using HVM_DBG_LOG() facility, but
then decided against using it because it does not have a fine grain control
over debugging and it will be harder to port this emulator for other
architectures in the future.

>
> > +
> > +/*
> > + * Default emulated NS8250 resources.
> > + * If not specified, COM1 (I/O port 0x3f8, IRQ#4) is emulated.
> > + * FIXME: follow Linux'es console=3D syntax or re-use
> > + * ns16550_parse_port_config().
> > + */
> > +static char __read_mostly hvm_ns8250_console[64];
> > +string_param("hvm.ns8250.console", hvm_ns8250_console);
>
>
> Same here, there seems to be no documentation about this option. And
> you likely want this to be a custom_param so you can do the parsing
> directly instead of storing into a buffer for later parsing.
>
> > +
> > +/* I/O access mask */
> > +static const uint32_t io_access_mask[] =3D {
> > + [0] =3D 0X00000000U,
> > + [1] =3D 0X000000FFU,
> > + [2] =3D 0X0000FFFFU,
> > + [4] =3D 0XFFFFFFFFU,
>
>
> lowercase x please.

Fixed.

>
> > +};
> > +
> > +/*
> > + * Legacy IBM PC NS8250 resources.
> > + * There are only 4 I/O port ranges, hardcoding all of them here.
> > + */
> > +static const struct {
> > + const char *name;
> > + const struct resource *res;
> > +} ns8250_x86_legacy_uarts[4] =3D {
> > + [0] =3D {
> > + .name =3D "com1",
> > + .res =3D (const struct resource[]){
> > + { .type =3D IORESOURCE_IO, .addr =3D 0x3F8, .size =3D UART_MAX },
> > + { .type =3D IORESOURCE_IRQ, .addr =3D 4, .size =3D 1 },
> > + { .type =3D IORESOURCE_UNKNOWN },
> > + },
> > + },
> > + [1] =3D {
> > + .name =3D "com2",
> > + .res =3D (const struct resource[]){
> > + { .type =3D IORESOURCE_IO, .addr =3D 0x2F8, .size =3D UART_MAX },
> > + { .type =3D IORESOURCE_IRQ, .addr =3D 3, .size =3D 1 },
> > + { .type =3D IORESOURCE_UNKNOWN },
> > + },
> > + },
> > + [2] =3D {
> > + .name =3D "com3",
> > + .res =3D (const struct resource[]){
> > + { .type =3D IORESOURCE_IO, .addr =3D 0x3E8, .size =3D UART_MAX },
> > + { .type =3D IORESOURCE_IRQ, .addr =3D 4, .size =3D 1 },
> > + { .type =3D IORESOURCE_UNKNOWN },
> > + },
> > + },
> > + [3] =3D {
> > + .name =3D "com4",
> > + .res =3D (const struct resource[]){
> > + { .type =3D IORESOURCE_IO, .addr =3D 0x2E8, .size =3D UART_MAX },
> > + { .type =3D IORESOURCE_IRQ, .addr =3D 3, .size =3D 1 },
> > + { .type =3D IORESOURCE_UNKNOWN },
> > + },
> > + },
> > +};
> > +
> > +static bool ns8250_fifo_rx_empty(struct vuart_ns8250 *vdev)
> > +{
> > + struct xencons_interface *cons =3D vdev->cons;
>
>
> const here and in the function parameter.

Done.

>
> > +
> > + return cons->in_prod =3D=3D cons->in_cons;
> > +}
> > +
> > +static bool ns8250_fifo_rx_full(struct vuart_ns8250 *vdev)
> > +{
> > + struct xencons_interface *cons =3D vdev->cons;
>
>
> const here and in the function parameter.

Done.

>
> > +
> > + return cons->in_prod - cons->in_cons =3D=3D sizeof(cons->in);
> > +}
> > +
> > +static void ns8250_fifo_rx_reset(struct vuart_ns8250 *vdev)
> > +{
> > + struct xencons_interface *cons =3D vdev->cons;
> > +
> > + cons->in_cons =3D cons->in_prod;
> > +}
> > +
> > +static int ns8250_fifo_rx_getchar(struct vuart_ns8250 *vdev)
> > +{
> > + struct xencons_interface *cons =3D vdev->cons;
> > + int rc =3D -1;
>
>
> -ENOENT maybe instead of -1?

With -1 I do not have to filter out the error codes, the value can be direc=
tly
returned to the guest, 0xff will be eventually interpreted as a break signa=
l
in the guest OS.
Changed to -ENODATA and plumbed error checking where necessary.

>
> > +
> > + if ( !ns8250_fifo_rx_empty(vdev) )
> > + {
> > + rc =3D cons->in[MASK_XENCONS_IDX(cons->in_cons, cons->in)];
> > + cons->in_cons++;
> > + }
> > +
> > + return rc;
> > +}
> > +
> > +static int ns8250_fifo_rx_putchar(struct vuart_ns8250 *vdev, char c)
> > +{
> > + struct xencons_interface cons =3D vdev->cons;
> > + int rc =3D 0;
> > +
> > + /
> > + * FIFO-less 8250/16450 UARTs: newly arrived word overwrites the conte=
nts
> > + * of the THR.
> > + /
> > + if ( ns8250_fifo_rx_full(vdev) )
> > + {
> > + ns8250_fifo_rx_reset(vdev);
> > + rc =3D -ENOSPC;
> > + }
> > +
> > + cons->in[MASK_XENCONS_IDX(cons->in_prod, cons->in)] =3D c;
> > + cons->in_prod++;
> > +
> > + return rc;
> > +}
> > +
> > +/
> > + * Flush cached output to Xen console.
> > + * Can be called from ns8250_exit().
> > + */
> > +static void ns8250_fifo_tx_reset(struct vuart_ns8250 *vdev)
> > +{
> > + struct xencons_interface *cons =3D vdev->cons;
> > +
> > + if ( cons->out_prod =3D=3D 0 )
>
>
> Don't you need to check that cons->out_prod =3D=3D cons->out_cons instead=
?

xencons_interface usage here is a bit awkward.

The reason for that is I want to print messages on the physical console w/o
fragmenting them w/ "(XEN)" and timestamps, etc. prefixes -
NS16550-compatible UART FIFO is only 16 characters.

The idea is to collect the guest OS output until '\n' or until the
`size - 1` condition and then send the collected output all at once
to the physical console followed by resetting out_prod to 0.
This works fine for the debugging purposes (the main goal of the
emulator) and the baud rate is not emulated anyway (one of the limitations
of the emulator) - i.e. there's no timer for draining TX buffer.

With that, checking for 0 was enough.

Fixed.

>
> > + return;
> > +
> > + cons->out[cons->out_prod++] =3D '\0';
>
>
> You need to use MASK_XENCONS_IDX() otherwise this could result in a
> buffer overflow?
>
> If you expect (because of checks in other places) out_prod to always
> be < ring size - 1, please add an assert to that extent here. But see
> below about the usage of the ring indexes.

Added assertions.

>
> Also, no need for the trailing increment, you will unconditionally
> reset out_prod to 0 just below.

Fixed.

>
> > +
> > + /*
> > + * NB: do not show domain ID if the domain owning the virtual UART als=
o
> > + * owns Xen input console.
> > + */
> > + if ( vdev->owner->domain_id =3D=3D console_owner_domid() )
> > + printk_common("%s", cons->out);
> > + else
> > + guest_printk(vdev->owner, "%s", cons->out);
> > +
> > + cons->out_prod =3D 0;
>
>
> You should rather do cons->out_cons =3D cons->out_prod?
>
>
> Wait, you seem to use the out buffer differently than the input one,
> and only advance out_prod but not out_cons?
>
> It seems weird to drive the 'in' ring using both indexes, while the
> 'out' ring is just using one index.

Correct, the awkward way is because I need to accumulate long guest
output until '\n' before sending it all at once to Xen console.

>
> > +}
> > +
> > +/*
> > + * Send a character to Xen console.
> > + */
> > +static void ns8250_fifo_tx_putchar(struct vuart_ns8250 *vdev, char ch)
> > +{
> > + struct xencons_interface *cons =3D vdev->cons;
> > +
> > + if ( !isconsole(ch) )
> > + return;
> > +
> > + cons->out[cons->out_prod] =3D ch;
> > + cons->out_prod++;
> > +
> > + if ( cons->out_prod =3D=3D ARRAY_SIZE(cons->out) - 1
> > + || ch =3D=3D '\n' || ch =3D=3D '\0' )
>
>
> Bad indentation, should be:
>
> if ( cons->out_prod =3D=3D ARRAY_SIZE(cons->out) - 1 ||
>
> ch =3D=3D '\n' || ch =3D=3D '\0' )

Fixed.

>
> Albeit I'm not sure you need the '\0' check, as isconsole('\0') will
> already return false?
>
> > + ns8250_fifo_tx_reset(vdev);
> > +}
> > +
> > +static bool cf_check ns8250_iir_check_lsi(struct vuart_ns8250 *vdev)
>
>
> vdev should be const.

Done.

>
> > +{
> > + return !!( vdev->regs[UART_LSR] & UART_LSR_MASK );
>
>
> Extra spaces around the parentheses.

Done.

>
> > +}
> > +
> > +static bool cf_check ns8250_iir_check_rda(struct vuart_ns8250 *vdev)
> > +{
> > + return !ns8250_fifo_rx_empty(vdev);
> > +}
> > +
> > +static bool cf_check ns8250_iir_check_thr(struct vuart_ns8250 *vdev)
> > +{
> > + return !!( vdev->flags & NS8250_IRQ_THRE_PENDING );
> > +}
> > +
> > +static bool cf_check ns8250_iir_check_msi(struct vuart_ns8250 *vdev)
>
>
> const for all the 3 vdev parameters above.

Yep, missed those. Done.

>
> > +{
> > + return !!( vdev->regs[UART_MSR] & UART_MSR_DELTA );
>
>
> Extra spaces around the parentheses.

Done.

>
> > +}
> > +
> > +/*
> > + * Interrupt identity reasons by priority.
> > + * NB: highest priority are at lower indexes.
> > + */
> > +static const struct {
> > + uint8_t ier_mask;
> > + uint8_t iir_mask;
> > + bool (*iir_check)(struct vuart_ns8250 *vdev);
> > +} iir_by_prio[] =3D {
> > + [0] =3D { UART_IER_ELSI, UART_IIR_LSI, ns8250_iir_check_lsi },
> > + [1] =3D { UART_IER_ERDAI, UART_IIR_RDA, ns8250_iir_check_rda },
> > + [2] =3D { UART_IER_ETHREI, UART_IIR_THR, ns8250_iir_check_thr },
> > + [3] =3D { UART_IER_EMSI, UART_IIR_MSI, ns8250_iir_check_msi },
>
>
> You don't need the explicit array indexes (at least with the ones you
> are specifying here).
>
> I think those interrupt reasons are not likely to change, and the
> checker for each reason is a one line function. It would be better to
> open-code the checking in ns8250_irq_reason(), as that will avoid the
> indirect function call.
>
> Otherwise iir_by_prio array should be declared in the scope of
> ns8250_irq_reason(), as that's the only function where it's used.

Moved iir_by_prio in scope of xxx_irq_reason()

>
> > +};
> > +
> > +/*
> > + * Define the interrupt identity reason.
> > + * NB: NS8250 always reports high priority events first.
> > + */
> > +static uint8_t ns8250_irq_reason(struct vuart_ns8250 *vdev)
> > +{
> > + int i;
>
>
> unsigned int.

Done.

>
> > +
> > + ASSERT( spin_is_locked(&vdev->lock) );
>
>
> Extra spaces around the parentheses.

Done.

>
> > + for ( i =3D 0; i < ARRAY_SIZE(iir_by_prio); i++ )
> > + {
> > + if ( (vdev->regs[UART_IER] & iir_by_prio[i].ier_mask)
> > + && iir_by_prio[i].iir_check(vdev) )
>
>
> Wrong placement of the &&, plus indentation.

Sorry, muscle memory; fixed.

>
> > + return iir_by_prio[i].iir_mask;
> > + }
> > +
> > + return UART_IIR_NOINT;
> > +}
> > +
> > +/*
> > + * Assert virtual NS8250 interrupt line.
> > + */
> > +static void ns8250_irq_assert(struct vuart_ns8250 *vdev)
> > +{
> > + uint8_t iir;
> > +
> > + iir =3D ns8250_irq_reason(vdev);
> > + if (iir & UART_IIR_NOINT)
>
>
> Missing spaces around the parentheses.

Fixed.

>
> > + hvm_irq_lower(vdev->owner, vdev->irq);
> > + else
> > + hvm_irq_raise(vdev->owner, vdev->irq);
>
>
> I think you should use hvm_isa_irq_{,de}assert(), as the interrupt
> will unconditionally be < 16?

Switched to hvm_isa_irq_{,de}assert().

>
> > +
> > + pr_debug("IRQ#%d %x %s\n", vdev->irq, iir,
> > + !!(iir & UART_IIR_NOINT) ? "lower" : "raise");
>
>
> hm, this will get very verbose. While it might have been helpful
> during development, I don't think it would be appropriate to print at
> any debug level.

That is one of the reasons why I have local pr_xxx() macros. These verbose
messages will be compiled out in the default vUART build.

>
> > +}
> > +
> > +/*
> > + * Emulate 8-bit write access to NS8250 register.
> > + */
> > +static int ns8250_io_write8(
> > + struct vuart_ns8250 *vdev, uint32_t reg, uint8_t *data)
> > +{
> > + uint8_t val;
> > + int rc =3D 0;
> > +
> > + val =3D *data;
>
>
> You can init val at declaration.

Sure; fixed.

>
> > +
> > + switch ( reg )
> > + {
> > + /* DLAB=3D0 /
> > + case UART_THR:
> > + if ( vdev->regs[UART_MCR] & UART_MCR_LOOP )
> > + {
> > + ns8250_fifo_rx_putchar(vdev, val);
> > + vdev->regs[UART_LSR] |=3D UART_LSR_OE;
> > + }
> > + else
> > + ns8250_fifo_tx_putchar(vdev, val);
> > +
> > + vdev->flags |=3D NS8250_IRQ_THRE_PENDING;
> > +
> > + break;
> > +
> > + case UART_IER:
> > + if ( val & vdev->regs[UART_IER] & UART_IER_ETHREI )
> > + vdev->flags |=3D NS8250_IRQ_THRE_PENDING;
> > +
> > + vdev->regs[UART_IER] =3D val & UART_IER_MASK;
> > +
> > + break;
> > +
> > + case UART_FCR: / WO /
> > + if ( val & UART_FCR_CLRX )
> > + ns8250_fifo_rx_reset(vdev);
> > +
> > + if ( val & UART_FCR_CLTX )
> > + ns8250_fifo_tx_reset(vdev);
> > +
> > + if ( !(val & UART_FCR_ENABLE) )
> > + val =3D 0;
> > +
> > + vdev->regs[UART_FCR] =3D val & (UART_FCR_ENABLE |
> > + UART_FCR_DMA |
> > + UART_FCR_TRG_MASK);
> > +
> > + break;
> > +
> > + case UART_LCR:
> > + vdev->regs[UART_LCR] =3D val;
> > + break;
> > +
> > + case UART_MCR: {
> > + uint8_t msr_curr, msr_next, msr_delta;
> > +
> > + msr_curr =3D vdev->regs[UART_MSR];
> > + msr_next =3D 0;
> > + msr_delta =3D 0;
> > +
> > + / Set modem status /
> > + if ( val & UART_MCR_LOOP )
> > + {
> > + if ( val & UART_MCR_DTR )
> > + msr_next |=3D UART_MSR_DSR;
> > + if ( val & UART_MCR_RTS )
> > + msr_next |=3D UART_MSR_CTS;
> > + if ( val & UART_MCR_OUT1 )
> > + msr_next |=3D UART_MSR_RI;
> > + if ( val & UART_MCR_OUT2 )
> > + msr_next |=3D UART_MSR_DCD;
> > + }
> > + else
> > + msr_next |=3D UART_MSR_DCD | UART_MSR_DSR | UART_MSR_CTS;
> > +
> > + / Calculate changes in modem status /
> > + if ( (msr_curr & UART_MSR_CTS) ^ (msr_next & UART_MSR_CTS) )
> > + msr_delta |=3D UART_MSR_DCTS;
> > + if ( (msr_curr & UART_MCR_RTS) ^ (msr_next & UART_MCR_RTS) )
> > + msr_delta |=3D UART_MSR_DDSR;
> > + if ( (msr_curr & UART_MSR_RI) & (msr_next & UART_MSR_RI) )
> > + msr_delta |=3D UART_MSR_TERI;
> > + if ( (msr_curr & UART_MSR_DCD) ^ (msr_next & UART_MSR_DCD) )
> > + msr_delta |=3D UART_MSR_DDCD;
> > +
> > + vdev->regs[UART_MCR] =3D val & UART_MCR_MASK;
> > + vdev->regs[UART_MSR] =3D msr_next | msr_delta;
> > +
> > + break;
> > + }
> > +
> > + case UART_LSR: / RO /
> > + case UART_MSR: / RO */
> > + rc =3D -EINVAL;
> > + break;
>
>
> Why are those not handled by the default case below? Is there any
> reason to explicitly mention those cases?

Yes: the intent was to be deliberately explicit so it is easier to
understand this code in the future.

>
> > +
> > + /*
> > + * NB: Firmware like OVMF rely on SCR presence to initialize the ns825=
0
> > + * driver.
> > + /
> > + case UART_SCR:
> > + vdev->regs[UART_SCR] =3D val;
> > + break;
> > +
> > + / DLAB=3D1 */
> > + case UART_MAX + UART_DLL:
> > + vdev->dl =3D (vdev->dl & 0xFF00U) | val;
> > + break;
> > +
> > + case UART_MAX + UART_DLM:
> > + vdev->dl =3D (val << 8) | (vdev->dl & 0x00FFU);
> > + break;
> > +
> > + default:
> > + rc =3D -EINVAL;
> > + break;
>
>
> Returning -EINVAL here is not correct I think, as the error gets
> propagated into the return of the IO handler. Those handlers expect
> to return a code in the range of X86EMUL_OKAY (see x86_emulate.h).
>
> But most importantly, what do you expect the caller to do with such
> error code? The access must be handled by the console driver, as it
> belongs to it's range of IO ports. What would hardware do in this
> case, ignore the write and continue operation?

This I overlooked while doing self-review, thanks.

The initial idea was to assert the virtual IRQ only if no "errors" returned
from the register I/O access emulation code. But then I forgot to clean
that up.

Fixed.

>
> If so, there's no point in returning any error from
> ns8250_io_write8(), the best would be to log a debug message in case
> of ignored accesses. This likely applies to all the handlers
> implemented below.

Yep, agree; fixed.

>
> > + }
> > +
> > + return rc;
> > +}
> > +
> > +/*
> > + * Emulate 16-bit write access to NS8250 register.
> > + * NB: some guest OSes use outw() to access UART_DLL.
> > + */
> > +static int ns8250_io_write16(
> > + struct vuart_ns8250 *vdev, uint32_t reg, uint16_t *data)
> > +{
> > + int rc;
> > +
> > + switch ( reg )
> > + {
> > + case UART_MAX + UART_DLL:
> > + vdev->dl =3D data;
> > + rc =3D 0;
> > + break;
> > +
> > + default:
> > + rc =3D -EINVAL;
> > + break;
> > + }
> > +
> > + return rc;
> > +}
> > +
> > +/
> > + * Emulate write access to NS8250 register.
> > + */
> > +static int ns8250_io_write(
> > + struct vuart_ns8250 *vdev, uint8_t reg, uint32_t size, uint32_t *data=
)
> > +{
> > + int rc =3D -EINVAL;
> > +
> > + switch ( size )
> > + {
> > + case 1:
> > + rc =3D ns8250_io_write8(vdev, reg, (uint8_t *)data);
> > + break;
> > +
> > + case 2:
> > + rc =3D ns8250_io_write16(vdev, reg, (uint16_t )data);
> > + break;
> > +
> > + default:
> > + break;
> > + }
> > +
> > + ns8250_irq_assert(vdev);
> > +
> > + return rc;
> > +}
> > +
> > +/
> > + * Emulate 8-bit read access to NS8250 register.
> > + */
> > +static int ns8250_io_read8(
> > + struct vuart_ns8250 *vdev, uint32_t reg, uint8_t *data)
> > +{
> > + int rc =3D 0;
> > + uint8_t val;
>
>
> In order to avoid unintentionally leaking stack contents, it would be
> best to initialize val at declaration:

Done.

>
> uint8_t val =3D ~0;
>
> > +
> > + switch ( reg )
> > + {
> > + /* DLAB=3D0 */
> > + case UART_RBR:
> > + val =3D (uint8_t)ns8250_fifo_rx_getchar(vdev);
>
>
> You seem to ignore that ns8250_fifo_rx_getchar() can return an error,
> is it intended to just propagate the error to the caller then?

The idea here is that UART_RBR read will emulate 0xff in case of RX FIFO
is empty which should be treated as a break signal by the guest OS.

I reworked that part so the code is followed easily.

>
> > + /* NB: do not forget to clear overrun condition /
> > + vdev->regs[UART_LSR] &=3D ~UART_LSR_OE;
> > + break;
> > +
> > + case UART_IER: / RO /
> > + val =3D vdev->regs[UART_IER];
> > + break;
> > +
> > + case UART_IIR:
> > + val =3D ns8250_irq_reason(vdev);
> > + if ( val & UART_IIR_THR )
> > + vdev->flags &=3D ~NS8250_IRQ_THRE_PENDING;
> > +
> > + if ( vdev->regs[UART_FCR] & UART_FCR_ENABLE )
> > + val |=3D UART_IIR_FE_MASK;
> > +
> > + break;
> > +
> > + case UART_LCR:
> > + val =3D vdev->regs[UART_LCR];
> > + break;
> > +
> > + case UART_MCR:
> > + val =3D vdev->regs[UART_MCR];
> > + break;
> > +
> > + case UART_LSR:
> > + val =3D vdev->regs[UART_LSR] | UART_LSR_THRE | UART_LSR_TEMT;
> > + if ( ns8250_fifo_rx_empty(vdev) )
> > + val &=3D ~UART_LSR_DR;
> > + else
> > + val |=3D UART_LSR_DR;
> > +
> > + vdev->regs[UART_LSR] =3D val & ~UART_LSR_MASK;
> > +
> > + break;
> > +
> > + case UART_MSR:
> > + val =3D vdev->regs[UART_MSR];
> > + vdev->regs[UART_MSR] &=3D ~UART_MSR_DELTA;
> > + break;
> > +
> > + case UART_SCR:
> > + val =3D vdev->regs[UART_SCR];
> > + break;
> > +
> > + / DLAB=3D1 */
> > + case UART_MAX + UART_DLL:
> > + val =3D vdev->dl & 0xFFU;
> > + break;
> > +
> > + case UART_MAX + UART_DLM:
> > + val =3D vdev->dl >> 8;
> > + break;
> > +
> > + default:
> > + val =3D (uint8_t)io_access_mask[1];
>
>
> Hm, not sure why you need this mask, isn't it OK to just do val =3D ~0;?

Dropped the mask.

>
> However see comment above about initializing at definition.
>
> > + rc =3D -EINVAL;
> > + break;
> > + }
> > +
> > + data =3D val;
> > +
> > + return rc;
> > +}
> > +
> > +/
> > + * Emulate 16-bit read access to NS8250 register.
> > + */
> > +static int ns8250_io_read16(
> > + struct vuart_ns8250 *vdev, uint32_t reg, uint16_t *data)
> > +{
> > + uint16_t val;
>
>
> Same comment as ns8250_io_read8() about initializing val at definition
> and not using io_access_mask.

Done.

>
> > + int rc;
> > +
> > + switch ( reg )
> > + {
> > + case UART_MAX + UART_DLL:
> > + val =3D vdev->dl;
> > + rc =3D 0;
> > + break;
> > +
> > + default:
> > + val =3D (uint16_t)io_access_mask[2];
> > + rc =3D -EINVAL;
> > + break;
> > + }
> > +
> > + data =3D val;
> > +
> > + return rc;
> > +}
> > +
> > +/
> > + * Emulate read access to NS8250 register.
> > + */
> > +static int ns8250_io_read(
> > + struct vuart_ns8250 *vdev, uint8_t reg, uint32_t size, uint32_t *data=
)
> > +{
> > + int rc;
> > +
> > + switch ( size )
> > + {
> > + case 1:
> > + rc =3D ns8250_io_read8(vdev, reg, (uint8_t *)data);
> > + break;
> > +
> > + case 2:
> > + rc =3D ns8250_io_read16(vdev, reg, (uint16_t *)data);
>
>
> I get the feeling you could handle both 1 and 2 byte accesses in the
> same function, as there's just a single register that allows 2 byte
> accesses.

I think it is possible to merge 1 and 2 bytes accesses. I wrote it this
way because it was easy to follow what's emulated. I kept this code as is
for now.

>
> Is the split done because further (to be implemented) features will
> require addition 2 byte accesses?

It does not seem there will be special 2 byte accesses involved for
MMIO-based UARTs.

>
> > + break;
> > +
> > + default:
> > + *data =3D io_access_mask[size];
> > + rc =3D -EINVAL;
> > + break;
> > + }
> > +
> > + ns8250_irq_assert(vdev);
> > +
> > + return rc;
> > +}
> > +
> > +static const char *ns8250_regname(
> > + const struct vuart_ns8250 *vdev, uint32_t reg, int dir)
> > +{
> > + static const char reg_names[UART_MAX + 2][2] =3D {
> > + / register W R */
> > + [UART_RBR] =3D { "THR", "RBR" },
> > + [UART_IER] =3D { "IER", "IER" },
> > + [UART_IIR] =3D { "FCR", "IIR" },
> > + [UART_LCR] =3D { "LCR", "LCR" },
> > + [UART_MCR] =3D { "MCR", "MCR" },
> > + [UART_LSR] =3D { "LSR", "LSR" },
> > + [UART_MSR] =3D { "MSR", "MSR" },
> > + [UART_SCR] =3D { "SCR", "SCR" },
> > + [UART_MAX + UART_DLL] =3D { "DLL", "DLL" },
> > + [UART_MAX + UART_DLM] =3D { "DLM", "DLM" },
> > + };
> > +
>
>
> To be in the safe saide I would assert that 'reg' and 'dir' are
> between the array bounds.

I dropped this function entirely.

>
> > + return reg_names[reg][dir];
> > +}
> > +
> > +/*
> > + * Emulate I/O access to NS8250 register.
> > + */
> > +static int cf_check ns8250_io_handle(
> > + int dir, unsigned int addr, unsigned int size, uint32_t *data)
> > +{
> > +#define op(dir) (((dir) =3D=3D IOREQ_WRITE) ? 'W' : 'R')
> > + struct domain *d =3D rcu_lock_current_domain();
> > + struct vuart_ns8250 *vdev =3D &d->arch.hvm.vuart;
> > + uint32_t offset, reg;
> > + int rc;
> > +
> > + spin_lock(&vdev->lock);
> > +
> > + BUG_ON( vdev->owner !=3D d );
>
>
> Extra spaces around the parentheses.

Done.

>
> However I would rather use:
>
> if ( vdev->owner !=3D d )
>
> {
> gprintk(XENLOG_ERR, "vUART owner %pd doesn't match current domain\n",
> vdev->owner);
>
> ASSERT_UNREACHABLE();
> rcu_unlock_domain(d);
> return X86EMU_OKAY;
> }
>
> And place it before the spin_lock() call.

Thank you.

>
> > +
> > + if ( !(vdev->flags & NS8250_READY) )
> > + {
> > + pr_err("%c io 0x%04x %d 0x%08"PRIx32": propagate to external I/O emul=
ator\n",
> > + op(dir), addr, size, *data);
> > + rc =3D X86EMUL_UNHANDLEABLE;
>
>
> I think you need to unconditionally return X86EMU_OKAY and just ignore
> the access. I assume there's no point in attempting to forward this
> access to any other handler, as it must be handled by the vuart
> driver.

Agreed, that is "the user has configured vUART" case, so all accesses
shall be trapped by the emulator.

Fixed.

>
> > + goto out;
> > + }
> > +
> > + reg =3D addr - vdev->io_addr;
> > + BUG_ON( reg >=3D UART_MAX );
>
>
> If possible, might be best to use a construct similar to the one
> proposed above with ASSERT_UNREACHABLE().

Done.

>
> > + if ( reg % size !=3D 0 )
>
>
> IS_ALIGNED(reg, size) might be clearer.

Done.

>
> > + {
> > + pr_err("%c 0x%04x %d 0x%08"PRIx32": unaligned access\n",
> > + op(dir), addr, size, data & io_access_mask[size]);
> > + rc =3D X86EMUL_OKAY;
> > + goto out;
> > + }
> > +
> > + / Redirect access to divisor latch registers */
> > + if ( !!(vdev->regs[UART_LCR] & UART_LCR_DLAB)
> > + && (reg =3D=3D UART_DLL || reg =3D=3D UART_DLM) )
>
>
> Indentation plus placement of the &&.

Fixed.

>
> > + offset =3D UART_MAX + reg;
> > + else
> > + offset =3D reg;
> > +
> > + if ( dir =3D=3D IOREQ_WRITE )
> > + {
> > + pr_debug("%c 0x%04x %d 0x%08"PRIx32" %s[0x%02"PRIx32"]\n",
> > + op(dir), addr, size,
> > + *data & io_access_mask[size],
> > + ns8250_regname(vdev, offset, dir), reg);
> > + rc =3D ns8250_io_write(vdev, offset, size, data);
> > + }
> > + else
> > + {
> > + rc =3D ns8250_io_read(vdev, offset, size, data);
> > + pr_debug("%c 0x%04x %d 0x%08"PRIx32" %s[0x%02"PRIx32"]\n",
> > + op(dir), addr, size,
> > + *data & io_access_mask[size],
> > + ns8250_regname(vdev, offset, dir), reg);
>
>
> The pr_debug() are likely too verbose.

Yes, those are verbose if enabled.

>
> > + }
> > + if ( rc )
> > + pr_err("%c 0x%04x %d 0x%08"PRIx32": unsupported access\n",
> > + op(dir), addr, size, *data & io_access_mask[size]);
> > + rc =3D X86EMUL_OKAY;
> > +
> > +out:
> > + spin_unlock(&vdev->lock);
>
>
> You seem to have forgotten a rcu_unlock_domain() call here? (even if
> it's a no-op).

I did not add it exactly because it is a no-op.
Fixed.

>
> > +
> > + return rc;
> > +#undef op
> > +}
> > +
> > +/*
> > + * Parse virtual NS8250 configuration.
> > + * hvm.ns8250.console=3D[com1|com2|com3|com4]
> > + */
> > +static const struct resource ns8250_parse(void)
> > +{
> > + int i;
> > +
> > + for ( i =3D 0; i < ARRAY_SIZE(ns8250_x86_legacy_uarts); i++ )
> > + if ( !strcasecmp(hvm_ns8250_console, ns8250_x86_legacy_uarts[i].name)=
 )
> > + return ns8250_x86_legacy_uarts[i].res;
> > +
> > + return ns8250_x86_legacy_uarts[0].res;
> > +}
> > +
> > +/
> > + * Claim virtual NS8250 resources to domain.
> > + */
> > +static int ns8250_claim(
> > + struct vuart_ns8250 *vdev, const struct resource *r, struct domain *d=
)
> > +{
> > + unsigned long size;
> > + unsigned long start;
> > + unsigned long end;
> > +
> > + vdev->irq =3D NO_IRQ;
> > + vdev->io_addr =3D IORESOURCE_UNKNOWN;
> > + vdev->io_size =3D IORESOURCE_UNKNOWN;
> > +
> > + foreach_resource(r)
> > + {
> > + if ( r->type & IORESOURCE_IO )
> > + {
> > + size =3D r->size;
> > + start =3D r->addr;
> > + end =3D r->addr + r->size - 1;
> > +
> > + if ( !ioports_access_permitted(d, start, end) )
> > + ioports_permit_access(d, start, end);
>
>
> Are you sure this is intended? By using ioports_permit_access() you
> are giving the domain access to the hardware (host) IO ports, and thus
> possibly avoiding the trapping into the IO handlers.
>
> However this is not very well-wired in HVM, because there's still an
> extra guest IO port -> host IO port translation that you are not
>
> adding.
>
> You shouldn't need the ioports_permit_access() for using the emulated
> vUART.

I see it now.

I understood it exactly the opposite way: ioports_permit_access() will
*lead* to trap on access.

Fixed.

Thanks a lot!

>
> > +
> > + register_portio_handler(d, start, size, ns8250_io_handle);
> > +
> > + /* Used to assert I/O port handler /
> > + vdev->io_addr =3D start;
> > + vdev->io_size =3D size;
> > + }
> > + else if ( r->type & IORESOURCE_IRQ )
> > + / "Claim" virtual IRQ; assumes no ISA-device IRQ sharing /
> > + vdev->irq =3D r->addr;
> > + else
> > + return -EINVAL;
> > + }
> > +
> > + if ( vdev->irq =3D=3D NO_IRQ
> > + || vdev->io_addr =3D=3D IORESOURCE_UNKNOWN
> > + || vdev->io_size =3D=3D IORESOURCE_UNKNOWN )
> > + return -ENODEV;
> > +
> > + return 0;
> > +}
> > +
> > +/
> > + * Unclaim virtual NS8250 resources.
> > + */
> > +static void ns8250_unclaim(struct vuart_ns8250 *vdev, struct domain *d=
)
> > +{
> > + unsigned long size =3D vdev->io_size;
> > + unsigned long start =3D vdev->io_addr;
> > + unsigned long end =3D start + size - 1;
> > +
> > + if ( ioports_access_permitted(d, start, end) )
> > + ioports_deny_access(d, start, size);
> > +}
> > +
> > +static int ns8250_init(struct domain *d, const struct resource *r)
> > +{
> > + struct vuart_ns8250 *vdev =3D &d->arch.hvm.vuart;
> > + struct xencons_interface *cons;
> > + int rc;
> > +
> > + cons =3D _xzalloc(sizeof(*vdev->cons), sizeof(void *));
>
>
> xvzalloc(typeof(*vdev->cons));

Done.

>
> > + if ( cons =3D=3D NULL )
> > + return -ENOMEM;
> > +
> > + rc =3D ns8250_claim(vdev, r, d);
> > + if ( rc )
> > + {
> > + xfree(cons);
> > + return rc;
> > + }
> > +
> > + spin_lock_init(&vdev->lock);
> > + hvm_irq_lower(d, vdev->irq);
> > +
> > + vdev->dl =3D (UART_CLOCK_HZ / 115200) >> 4; /* Report 115200 baud rat=
e */
> > + vdev->cons =3D cons;
> > + vdev->owner =3D d;
> > + vdev->flags =3D NS8250_READY | NS8250_IRQ_THRE_PENDING;
> > +
> > + return 0;
> > +}
> > +
> > +static void ns8250_exit(struct domain *d)
> > +{
> > + struct vuart_ns8250 *vdev =3D &d->arch.hvm.vuart;
> > +
> > + spin_lock(&vdev->lock);
> > +
> > + if ( !(vdev->flags & NS8250_READY) )
> > + goto out;
> > +
> > + ns8250_unclaim(vdev, d);
> > + ns8250_fifo_tx_reset(vdev);
> > + xfree(vdev->cons);
> > +
> > + vdev->cons =3D NULL;
> > + vdev->owner =3D NULL;
> > + vdev->flags =3D 0;
> > +
> > +out:
> > + spin_unlock(&vdev->lock);
> > +}
> > +
> > +int vuart_putchar(struct vuart_ns8250 vdev, char ch)
> > +{
> > + int rc;
> > +
> > + spin_lock(&vdev->lock);
> > +
> > + if ( !(vdev->flags & NS8250_READY) )
> > + {
> > + rc =3D -ENODEV;
> > + goto out;
> > + }
> > +
> > + / Echo the user input on the console */
> > + printk("%c", ch);
>
>
> FWIW, I would move the printk() after the error checks, so that the
> character is only echoed if handled.

Done.

>
> > +
> > + /*
> > + * Device is in loopback mode; do nothing.
> > + /
> > + if ( vdev->regs[UART_MCR] & UART_MCR_LOOP )
> > + {
> > + rc =3D -EBUSY;
> > + goto out;
> > + }
> > +
> > + rc =3D ns8250_fifo_rx_putchar(vdev, ch);
> > + if ( rc =3D=3D -ENOSPC )
> > + vdev->regs[UART_LSR] |=3D UART_LSR_OE | UART_LSR_DR;
> > + else
> > + / NB: UART_LSR_DR is also set when UART_LSR is accessed. /
> > + vdev->regs[UART_LSR] |=3D UART_LSR_DR;
> > +
> > + / FIXME: check FCR when to fire an interrupt */
> > + ns8250_irq_assert(vdev);
> > +
> > +out:
> > + spin_unlock(&vdev->lock);
> > +
> > + return rc;
> > +}
> > +
> > +int domain_vuart_init(struct domain *d)
> > +{
> > + struct vuart_ns8250 *vdev =3D &d->arch.hvm.vuart;
> > + const struct resource *r;
> > +
> > + memset(vdev, 0, sizeof(*vdev));
> > +
> > + r =3D ns8250_parse();
> > + if ( r !=3D NULL )
> > + return ns8250_init(d, r);
> > +
> > + return -ENODEV;
> > +}
> > +
> > +void domain_vuart_free(struct domain d)
> > +{
> > + ns8250_exit(d);
> > +}
> > +
> > +/
> > + * Local variables:
> > + * mode: C
> > + * c-file-style: "BSD"
> > + * c-basic-offset: 4
> > + * indent-tabs-mode: nil
> > + * End:
> > + */
> > diff --git a/xen/arch/x86/include/asm/hvm/domain.h b/xen/arch/x86/inclu=
de/asm/hvm/domain.h
> > index 333501d5f2ac01676646b9b277b551f06d43c3a5..d4ce25896259fc9763477e8=
8d56bacbe4f78af5b 100644
> > --- a/xen/arch/x86/include/asm/hvm/domain.h
> > +++ b/xen/arch/x86/include/asm/hvm/domain.h
> > @@ -16,6 +16,7 @@
> > #include <asm/hvm/io.h>
> > #include <asm/hvm/vmx/vmcs.h>
> > #include <asm/hvm/svm/vmcb.h>
> > +#include <asm/hvm/vuart_ns8250.h>
> >
> > #ifdef CONFIG_MEM_SHARING
> > struct mem_sharing_domain
> > @@ -73,6 +74,10 @@ struct hvm_domain {
> > struct hvm_vioapic **vioapic;
> > unsigned int nr_vioapics;
> >
> > +#if defined(CONFIG_HAS_VUART_NS8250)
> > + struct vuart_ns8250 vuart;
>
>
> Since this is supposed to possibly be used by just a small amount of
> domain on the system, I would rather make this a pointer:
>
> struct vuart_ns8250 *vuart;
>
> And embed the xencons_ring inside of it directly, so that you just
> have to allocate vuart_ns8250.

Fixed.

I ended up having just
    void *vuart;
in hvm_domain after addressing Jan's feedback.

That will also eliminate the need for NS8250_READY flag.

>
> > +#endif
> > +
> > /*
> > * hvm_hw_pmtimer is a publicly-visible name. We will defer renaming
> > * it to the more appropriate hvm_hw_acpi until the expected
> > diff --git a/xen/arch/x86/include/asm/hvm/vuart_ns8250.h b/xen/arch/x86=
/include/asm/hvm/vuart_ns8250.h
> > new file mode 100644
> > index 0000000000000000000000000000000000000000..e1013751f955441a9089ea3=
8c96c4605a7f4cb75
> > --- /dev/null
> > +++ b/xen/arch/x86/include/asm/hvm/vuart_ns8250.h
> > @@ -0,0 +1,75 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only /
> > +/
> > + * NS8250-compatible UART Emulator.
> > + */
> > +#if !defined(HVM__VUART_NS8250_H)
>
>
> As commented by Jan, better use #ifndef.

Done.

>
> > +#define HVM__VUART_NS8250_H
> > +
> > +#include <xen/spinlock.h>
> > +#include <xen/8250-uart.h>
> > +#include <public/io/console.h> /* xencons_interface /
> > +
> > +/
> > + * NS8250 emulator operational flags.
> > + /
> > +enum {
> > + / Emulator is ready /
> > + NS8250_READY =3D BIT(0, U),
> > + / Trigger re-delivery of THRE interrupt */
> > + NS8250_IRQ_THRE_PENDING =3D BIT(1, U),
>
>
> I'm unsure the unnamed enum buys you much here if you end up assigning
> values anyway. You might as well do:
>
> #define NS8250_READY BIT(0, U)
> #define NS8250_IRQ_THRE_PENDING BIT(1, U)

re: why enum: muscle memory.

NS8250_READY is gone now that initialization code is reworked.
I also dropped the other flag and dropped enum.

>
> It would be good if you could integrate this with the flags field
> being declared using DECLARE_BITMAP(). Otherwise you might need some
> build-time check to ensure max defined flag fits in the struct flags
> field.

Dropped flags field.

>
> > +};
> > +
> > +/*
> > + * Virtual NS8250 device state.
> > + /
> > +struct vuart_ns8250 {
> > + uint16_t dl; / Divisor Latch /
> > + uint8_t regs[UART_MAX]; / Registers */
>
>
> Doesn't regs already account for the divisor latch register?

No, in this version `regs` registers are for DLAB=3D0.
Registers are accessed differently in NS16550 depending on type of
access (R/W) and LCR contents (DLAB=3D{0,1}).

I added some more comments; register emulation is updated in v3.

>
> > + uint32_t flags; /* Virtual device flags */
>
>
> See comment above about using DECLARE_BITMAP().
>
> > + uint64_t io_addr; /* Guest I/O region base address */
>
>
> IO space is limited to 16bits, hence there's no need to use a uint64_t
> to store the address. Either uint16_t, or just a plain unsigned int
> will suffice. Same for size below.

It is uint64_t for the follow on MMIO-based UART.

>
> > + uint64_t io_size; /* Guest I/O region size /
> > + int irq; / Guest IRQ# */
> > + struct xencons_interface cons; / Emulated RX/TX FIFOs */
>
>
> Any reason you re-use the xencons interface? And any reason it's a
> pointer instead of being part of vuart_ns8250 itself?

re: why re-use xencons: few reasons.
I decided to re-use something which is already invented in the code
base, rather then inventing my own buffering.
My understanding is that xencons will be needed for inter-domain
communication: xencons has pretty large buffers which may help
in case of slow domain. And I wanted to avoid guest OS printouts
"fragmentation" w/ prefixes printk injects into the each log message,
so large buffers should work around fragmenting messages.

re: why its a pointer: I did not think that d->arch.hvm can actually
contain just a pointer to vuart_ns16550 (I reworked it to `void *`).
That is pretty-much cut-n-paste from Arm's vpl011 design.

>
> > + struct domain owner; / Owner domain /
> > + spinlock_t lock; / Protection */
> > +};
> > +
> > +#if defined(CONFIG_HAS_VUART_NS8250)
> > +
> > +int vuart_putchar(struct vuart_ns8250 vdev, char ch);
> > +
> > +/
> > + * Match the names w/ arch/arm/vuart.h
> > + * FIXME: move to common vuart.h
> > + */
> > +int domain_vuart_init(struct domain *d);
> > +void domain_vuart_free(struct domain *d);
> > +
> > +#else
> > +
> > +static inline int vuart_putchar(struct vuart_ns8250 *vdev, char ch)
> > +{
>
>
> Hard to tell as there are no users of vuart_putchar() in this patch,
> but it seems you might want an ASSERT_UNREACHABLE() here.

Addressed in v3.

>
> > + return -1;
> > +}
> > +
> > +static inline int domain_vuart_init(struct domain *d)
> > +{
> > + return -ENODEV;
> > +}
> > +
> > +static inline void domain_vuart_free(struct domain *d)
> > +{
>
>
> Both init and free calls are gated with domain_has_vuart(), so you
> might want to also add ASSERT_UNREACHABLE() here.

Done.

>
> Thanks, Roger.




From xen-devel-bounces@lists.xenproject.org Sat Jan 04 08:47:00 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 08:47:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865410.1276708 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTznw-0004Wk-Qp; Sat, 04 Jan 2025 08:46:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865410.1276708; Sat, 04 Jan 2025 08:46:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tTznw-0004Wd-O3; Sat, 04 Jan 2025 08:46:44 +0000
Received: by outflank-mailman (input) for mailman id 865410;
 Sat, 04 Jan 2025 08:46: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
 <SRS0=Q/3D=T4=bugseng.com=nicola.vetrini@srs-se1.protection.inumbo.net>)
 id 1tTznv-0004WX-HW
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 08:46:44 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6a1c3a29-ca78-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 09:46:41 +0100 (CET)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 by support.bugseng.com (Postfix) with ESMTPA id 4D6204EE073C;
 Sat,  4 Jan 2025 09:46:38 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 6a1c3a29-ca78-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1735980398; bh=jWYZyytIpN3NwbzaTyrBU5KRbte3Mc1u4qctDdTMWNA=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=M2R/LfDUh/DDS5p0tcpmQUB1FP0ZAmt+UsTj6XK+HPqX/ziyIQ2VNBqpMSeLY+Ufp
	 2jmdDyifOKesXGeJM8cd3Bqr2yRij5+7rqzUbdw9o0Z7H1s5XI0c6bAGaFRzwpRBMv
	 j4/FcYy35LeJMMCqvf9EuWTQ9FIYsSSxPI1N6/DQfKlaLzCmGJcZS2/zKjhQelT0Ab
	 7J3PzI3ZLZsnf6lijcSpBR/Hs3sMai/kDoJu1sfCB69FCfFWIpk2FU+L4i4J6NQvQo
	 MOKXQ/nnSa94TW7QjdF071T67OKI986wfaHmXSC3HKWpfVINjGSTe2sUTMEvPBvLaH
	 l7+/FlJ3REqJA==
MIME-Version: 1.0
Date: Sat, 04 Jan 2025 09:46:38 +0100
From: Nicola Vetrini <nicola.vetrini@bugseng.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Xen-devel
 <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, Julien Grall
 <julien@xen.org>, Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>, Bertrand
 Marquis <bertrand.marquis@arm.com>, Michal Orzel <michal.orzel@amd.com>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>, Shawn Anastasio
 <sanastasio@raptorengineering.com>
Subject: Re: [PATCH 2/5] xen/perfc: Add perfc_defn.h to asm-generic
In-Reply-To: <alpine.DEB.2.22.394.2501031525580.16425@ubuntu-linux-20-04-desktop>
References: <20250102192508.2405687-1-andrew.cooper3@citrix.com>
 <20250102192508.2405687-3-andrew.cooper3@citrix.com>
 <alpine.DEB.2.22.394.2501031525580.16425@ubuntu-linux-20-04-desktop>
Message-ID: <de2fb1d4daddcfb2a9de18fb7911c603@bugseng.com>
X-Sender: nicola.vetrini@bugseng.com
Organization: BUGSENG s.r.l.
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit

On 2025-01-04 00:29, Stefano Stabellini wrote:
> On Thu, 2 Jan 2025, Andrew Cooper wrote:
>> ... and hook it up for RISC-V and PPC.
>> 
>> On RISC-V at least, no combination of headers pulls in errno.h, so 
>> include it
>> explicitly.
>> 
>> Guard the hypercalls array declaration based on NR_hypercalls 
>> existing.  This
>> is sufficient to get PERF_COUNTERS fully working on RISC-V and PPC, so 
>> drop
>> the randconfig override.
>> 
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> ---
>> CC: Jan Beulich <JBeulich@suse.com>
>> CC: Roger Pau Monné <roger.pau@citrix.com>
>> CC: Stefano Stabellini <sstabellini@kernel.org>
>> CC: Julien Grall <julien@xen.org>
>> CC: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
>> CC: Bertrand Marquis <bertrand.marquis@arm.com>
>> CC: Michal Orzel <michal.orzel@amd.com>
>> CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
>> CC: Shawn Anastasio <sanastasio@raptorengineering.com>
>> ---
>>  automation/gitlab-ci/build.yaml      | 1 -
>>  xen/arch/ppc/include/asm/Makefile    | 1 +
>>  xen/arch/riscv/include/asm/Makefile  | 1 +
>>  xen/common/perfc.c                   | 1 +
>>  xen/include/asm-generic/perfc_defn.h | 5 +++++
>>  xen/include/xen/perfc_defn.h         | 2 ++
>>  6 files changed, 10 insertions(+), 1 deletion(-)
>>  create mode 100644 xen/include/asm-generic/perfc_defn.h
>> 

>> diff --git a/xen/include/asm-generic/perfc_defn.h 
>> b/xen/include/asm-generic/perfc_defn.h
>> new file mode 100644
>> index 000000000000..8237636d83fb
>> --- /dev/null
>> +++ b/xen/include/asm-generic/perfc_defn.h
>> @@ -0,0 +1,5 @@
>> +/* This file is legitimately included multiple times. */
> 
> It is a good idea to add comment here to explain. This is effectively
> the same as a deviation of MISRA D4.10. SAF-8-safe is defined as
> "Headers that deliberatively leave the responsability of their correct
> inclusion to the caller are allowed". I think it applies, please add
> SAF-8-safe to this comment and also the other perfc_defn.h, e.g.:
> 
> /* SAF-8-safe This file is legitimately included multiple times. */
> 

There is already a deviation in place for this kind of files, so I think 
that's good as is, no need for a SAF tag.

-doc_begin="Files that are intended to be included more than once do not 
need to
conform to the directive."
-config=MC3A2.D4.10,reports+={safe, "first_area(text(^/\\* This file is 
legitimately included multiple times\\. \\*/$, begin-4))"}

> 
>> +/* #ifndef ASM_GENERIC_PERFC_DEFN_H */
>> +/* #define ASM_GENERIC_PERFC_DEFN_H */
>> +
>> +/* #endif ASM_GENERIC_PERFC_DEFN_H */
>> diff --git a/xen/include/xen/perfc_defn.h 
>> b/xen/include/xen/perfc_defn.h
>> index 0027d95a60bc..a987d80dd6f1 100644
>> --- a/xen/include/xen/perfc_defn.h
>> +++ b/xen/include/xen/perfc_defn.h
>> @@ -4,7 +4,9 @@
>> 
>>  #include <asm/perfc_defn.h>
>> 
>> +#ifdef NR_hypercalls
>>  PERFCOUNTER_ARRAY(hypercalls,           "hypercalls", NR_hypercalls)
>> +#endif
>> 
>>  PERFCOUNTER(calls_from_multicall,       "calls from multicall")
>> 
>> --
>> 2.39.5
>> 

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253


From xen-devel-bounces@lists.xenproject.org Sat Jan 04 11:14:39 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 11:14:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865420.1276719 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tU26k-00075k-VZ; Sat, 04 Jan 2025 11:14:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865420.1276719; Sat, 04 Jan 2025 11:14:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tU26k-00075d-Se; Sat, 04 Jan 2025 11:14:18 +0000
Received: by outflank-mailman (input) for mailman id 865420;
 Sat, 04 Jan 2025 11:11:26 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=YaCs=T4=zju.edu.cn=banmengtao@srs-se1.protection.inumbo.net>)
 id 1tU23y-00071M-Eo
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 11:11:26 +0000
Received: from azure-sdnproxy.icoremail.net (azure-sdnproxy.icoremail.net
 [52.237.72.81]) by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id a0179830-ca8c-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 12:11:21 +0100 (CET)
Received: from ban.. (unknown [39.173.141.67])
 by mail-app2 (Coremail) with SMTP id by_KCgC3VpJNF3ln0WAaAQ--.32270S2;
 Sat, 04 Jan 2025 19:11:12 +0800 (CST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a0179830-ca8c-11ef-99a4-01e77a169b0f
From: banmengtao <banmengtao@zju.edu.cn>
To: xen-devel@lists.xenproject.org
Cc: banmengtao <jiuxie@outlook.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PATCH] x86/cpu: Support Hygon architecture CPU during NMI initialization.
Date: Sat,  4 Jan 2025 19:11:09 +0800
Message-Id: <20250104111109.2726-1-banmengtao@zju.edu.cn>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-CM-TRANSID:by_KCgC3VpJNF3ln0WAaAQ--.32270S2
X-Coremail-Antispam: 1UD129KBjvdXoWrZFW8ZF4xtw4rZFWDZr4fZrb_yoWkJFX_Z3
	s0g34kX34Svay8AF1ktw4rZF1I93yF9FW3Gw1FgryYgr10vr1UJr43KFyFvF4xGayxJrWU
	Kay7GrWq9Fy7JjkaLaAFLSUrUUUUjb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT
	9fnUUIcSsGvfJTRUUUbI8YjsxI4VWkKwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I
	6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2
	8CjxkF64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVWDJVCq3wA2z4x0Y4vE2Ix0
	cI8IcVCY1x0267AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I
	8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI
	64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1Y6r17McIj6I8E87Iv67AKxVWUJVW8Jw
	Am72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lc7CjxVAaw2AFwI0_JF0_Jw1l
	c2xSY4AK67AK6r4kMxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I
	0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWU
	AVWUtwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcV
	CY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF4lIxAIcVC2z280aVAF
	wI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyTuYvj
	xUy3r4UUUUU
X-CM-SenderInfo: 5edqzv5qjwt0o62m3hxhgxhubq/

From: banmengtao <jiuxie@outlook.com>

When I installed Xen on Ubuntu 22.04 and rebooted into the kernel, it kept freezing and threw an exception: "Unsupported processor. Unknown vendor 16."
This patch fixes the issue where the Hygon CPU could not be recognized when entering the Xen kernel.

Signed-off-by: banmengtao <jiuxie@outlook.com>
---
 xen/arch/x86/oprofile/nmi_int.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/xen/arch/x86/oprofile/nmi_int.c b/xen/arch/x86/oprofile/nmi_int.c
index fa3071d977..ef7c7b8f69 100644
--- a/xen/arch/x86/oprofile/nmi_int.c
+++ b/xen/arch/x86/oprofile/nmi_int.c
@@ -398,6 +398,7 @@ static int __init cf_check nmi_init(void)
 
 	switch (vendor) {
 		case X86_VENDOR_AMD:
+		case X86_VENDOR_HYGON:
 			/* Needs to be at least an Athlon (or hammer in 32bit mode) */
 
 			switch (family) {
@@ -435,6 +436,11 @@ static int __init cf_check nmi_init(void)
 				model = &op_athlon_spec;
 				cpu_type = "x86-64/family16h";
 				break;
+			case 0x18:
+				model = &op_athlon_spec;
+				cpu_type = "x86-64/family18h";
+				break;
+
 			}
 			break;
 
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Sat Jan 04 18:12:42 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 18:12:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865433.1276728 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tU8dI-000072-N8; Sat, 04 Jan 2025 18:12:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865433.1276728; Sat, 04 Jan 2025 18:12:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tU8dI-00006v-KF; Sat, 04 Jan 2025 18:12:20 +0000
Received: by outflank-mailman (input) for mailman id 865433;
 Sat, 04 Jan 2025 18:12: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 <SRS0=DJS+=T4=intel.com=lkp@srs-se1.protection.inumbo.net>)
 id 1tU8dH-00006n-KX
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 18:12:19 +0000
Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.8])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6b4c2b29-cac7-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 19:12:13 +0100 (CET)
Received: from fmviesa004.fm.intel.com ([10.60.135.144])
 by fmvoesa102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 04 Jan 2025 10:12:11 -0800
Received: from lkp-server01.sh.intel.com (HELO d63d4d77d921) ([10.239.97.150])
 by fmviesa004.fm.intel.com with ESMTP; 04 Jan 2025 10:12:09 -0800
Received: from kbuild by d63d4d77d921 with local (Exim 4.96)
 (envelope-from <lkp@intel.com>) id 1tU8d4-000B7X-2c;
 Sat, 04 Jan 2025 18:12:06 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 6b4c2b29-cac7-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=intel.com; i=@intel.com; q=dns/txt; s=Intel;
  t=1736014334; x=1767550334;
  h=date:from:to:cc:subject:message-id:references:
   mime-version:in-reply-to;
  bh=bEdEZDsKvjKvYISSsqUWqDonU9gW1hZc1LD8ZT7VxKw=;
  b=Jfm5G2YhzjACzQ41ANim96C7FvRh6ostiuKZE1T/FEPnTOF7LZvBhW9C
   qYNkegiFcf1QcvNxdx2P/I3R8TJQMRoqU13NFDAMDO/EYcRTNAFdY0PC8
   CA4AIH/sbQ34Jpz//Hh5u6l/o3EgBuH2vgNtvqABVGO4cFWLaGjfG6kDi
   QFhbDup7ZzSvNXvtBjvx/y5/P/7sEmzI4GhAG1DDgy0grE/OAEAE0EsJ+
   +Epv6aqXzTyZNFtwC401hxl24rSYIzGqMj+3HZaDqTNHkFMhBvFgjRd3A
   7rpEcpw0AEsuI3G70XQyDWiYzgnrnzNhi/fO/AVUfe4OjXsJ5bVrDy5eC
   A==;
X-CSE-ConnectionGUID: iIUC2n0gTYmkpQQtomP5Fg==
X-CSE-MsgGUID: nKIVMJ7vS1GLAQ72vGN1qA==
X-IronPort-AV: E=McAfee;i="6700,10204,11305"; a="53765791"
X-IronPort-AV: E=Sophos;i="6.12,288,1728975600"; 
   d="scan'208";a="53765791"
X-CSE-ConnectionGUID: PWYoHdEfS5yRDNe49Nrr8Q==
X-CSE-MsgGUID: dbnoRSxiQbWPWUzn2BL7tw==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="6.12,288,1728975600"; 
   d="scan'208";a="106907870"
Date: Sun, 5 Jan 2025 02:11:26 +0800
From: kernel test robot <lkp@intel.com>
To: Stefano Stabellini <sstabellini@kernel.org>,
	linux-kernel@vger.kernel.org
Cc: llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev,
	sstabellini@kernel.org, jgross@suse.com,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH] xen: update pvcalls_front_accept prototype
Message-ID: <202501050103.LVGxLcNl-lkp@intel.com>
References: <alpine.DEB.2.22.394.2501031501420.16425@ubuntu-linux-20-04-desktop>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.22.394.2501031501420.16425@ubuntu-linux-20-04-desktop>

Hi Stefano,

kernel test robot noticed the following build errors:

[auto build test ERROR on xen-tip/linux-next]
[also build test ERROR on linus/master v6.13-rc5 next-20241220]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Stefano-Stabellini/xen-update-pvcalls_front_accept-prototype/20250104-070503
base:   https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git linux-next
patch link:    https://lore.kernel.org/r/alpine.DEB.2.22.394.2501031501420.16425%40ubuntu-linux-20-04-desktop
patch subject: [PATCH] xen: update pvcalls_front_accept prototype
config: x86_64-buildonly-randconfig-005-20250104 (https://download.01.org/0day-ci/archive/20250105/202501050103.LVGxLcNl-lkp@intel.com/config)
compiler: clang version 19.1.3 (https://github.com/llvm/llvm-project ab51eccf88f5321e7c60591c5546b254b6afab99)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250105/202501050103.LVGxLcNl-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202501050103.LVGxLcNl-lkp@intel.com/

All errors (new ones prefixed by >>):

   In file included from drivers/xen/pvcalls-front.c:7:
   In file included from include/linux/net.h:24:
   In file included from include/linux/mm.h:2223:
   include/linux/vmstat.h:518:36: warning: arithmetic between different enumeration types ('enum node_stat_item' and 'enum lru_list') [-Wenum-enum-conversion]
     518 |         return node_stat_name(NR_LRU_BASE + lru) + 3; // skip "nr_"
         |                               ~~~~~~~~~~~ ^ ~~~
>> drivers/xen/pvcalls-front.c:772:5: error: conflicting types for 'pvcalls_front_accept'
     772 | int pvcalls_front_accept(struct socket *sock, struct socket *newsock, int flags)
         |     ^
   drivers/xen/pvcalls-front.h:13:5: note: previous declaration is here
      13 | int pvcalls_front_accept(struct socket *sock,
         |     ^
   1 warning and 1 error generated.


vim +/pvcalls_front_accept +772 drivers/xen/pvcalls-front.c

1853f11d72ed46 Stefano Stabellini 2017-10-30  771  
9774c6cca26610 Stefano Stabellini 2017-10-30 @772  int pvcalls_front_accept(struct socket *sock, struct socket *newsock, int flags)
9774c6cca26610 Stefano Stabellini 2017-10-30  773  {
9774c6cca26610 Stefano Stabellini 2017-10-30  774  	struct pvcalls_bedata *bedata;
9774c6cca26610 Stefano Stabellini 2017-10-30  775  	struct sock_mapping *map;
9774c6cca26610 Stefano Stabellini 2017-10-30  776  	struct sock_mapping *map2 = NULL;
9774c6cca26610 Stefano Stabellini 2017-10-30  777  	struct xen_pvcalls_request *req;
0102e4efda76d0 Yan Yankovskyi     2020-03-23  778  	int notify, req_id, ret, nonblock;
0102e4efda76d0 Yan Yankovskyi     2020-03-23  779  	evtchn_port_t evtchn;
9774c6cca26610 Stefano Stabellini 2017-10-30  780  
64d6871827b1e2 Stefano Stabellini 2018-02-14  781  	map = pvcalls_enter_sock(sock);
64d6871827b1e2 Stefano Stabellini 2018-02-14  782  	if (IS_ERR(map))
64d6871827b1e2 Stefano Stabellini 2018-02-14  783  		return PTR_ERR(map);
9774c6cca26610 Stefano Stabellini 2017-10-30  784  	bedata = dev_get_drvdata(&pvcalls_front_dev->dev);
9774c6cca26610 Stefano Stabellini 2017-10-30  785  
9774c6cca26610 Stefano Stabellini 2017-10-30  786  	if (map->passive.status != PVCALLS_STATUS_LISTEN) {
64d6871827b1e2 Stefano Stabellini 2018-02-14  787  		pvcalls_exit_sock(sock);
9774c6cca26610 Stefano Stabellini 2017-10-30  788  		return -EINVAL;
9774c6cca26610 Stefano Stabellini 2017-10-30  789  	}
9774c6cca26610 Stefano Stabellini 2017-10-30  790  
9774c6cca26610 Stefano Stabellini 2017-10-30  791  	nonblock = flags & SOCK_NONBLOCK;
9774c6cca26610 Stefano Stabellini 2017-10-30  792  	/*
9774c6cca26610 Stefano Stabellini 2017-10-30  793  	 * Backend only supports 1 inflight accept request, will return
9774c6cca26610 Stefano Stabellini 2017-10-30  794  	 * errors for the others
9774c6cca26610 Stefano Stabellini 2017-10-30  795  	 */
9774c6cca26610 Stefano Stabellini 2017-10-30  796  	if (test_and_set_bit(PVCALLS_FLAG_ACCEPT_INFLIGHT,
9774c6cca26610 Stefano Stabellini 2017-10-30  797  			     (void *)&map->passive.flags)) {
9774c6cca26610 Stefano Stabellini 2017-10-30  798  		req_id = READ_ONCE(map->passive.inflight_req_id);
9774c6cca26610 Stefano Stabellini 2017-10-30  799  		if (req_id != PVCALLS_INVALID_ID &&
9774c6cca26610 Stefano Stabellini 2017-10-30  800  		    READ_ONCE(bedata->rsp[req_id].req_id) == req_id) {
9774c6cca26610 Stefano Stabellini 2017-10-30  801  			map2 = map->passive.accept_map;
9774c6cca26610 Stefano Stabellini 2017-10-30  802  			goto received;
9774c6cca26610 Stefano Stabellini 2017-10-30  803  		}
9774c6cca26610 Stefano Stabellini 2017-10-30  804  		if (nonblock) {
64d6871827b1e2 Stefano Stabellini 2018-02-14  805  			pvcalls_exit_sock(sock);
9774c6cca26610 Stefano Stabellini 2017-10-30  806  			return -EAGAIN;
9774c6cca26610 Stefano Stabellini 2017-10-30  807  		}
9774c6cca26610 Stefano Stabellini 2017-10-30  808  		if (wait_event_interruptible(map->passive.inflight_accept_req,
9774c6cca26610 Stefano Stabellini 2017-10-30  809  			!test_and_set_bit(PVCALLS_FLAG_ACCEPT_INFLIGHT,
9774c6cca26610 Stefano Stabellini 2017-10-30  810  					  (void *)&map->passive.flags))) {
64d6871827b1e2 Stefano Stabellini 2018-02-14  811  			pvcalls_exit_sock(sock);
9774c6cca26610 Stefano Stabellini 2017-10-30  812  			return -EINTR;
9774c6cca26610 Stefano Stabellini 2017-10-30  813  		}
9774c6cca26610 Stefano Stabellini 2017-10-30  814  	}
9774c6cca26610 Stefano Stabellini 2017-10-30  815  
9f51c05dc41a6d Wen Yang           2018-12-05  816  	map2 = kzalloc(sizeof(*map2), GFP_KERNEL);
9f51c05dc41a6d Wen Yang           2018-12-05  817  	if (map2 == NULL) {
9f51c05dc41a6d Wen Yang           2018-12-05  818  		clear_bit(PVCALLS_FLAG_ACCEPT_INFLIGHT,
9f51c05dc41a6d Wen Yang           2018-12-05  819  			  (void *)&map->passive.flags);
9f51c05dc41a6d Wen Yang           2018-12-05  820  		pvcalls_exit_sock(sock);
9f51c05dc41a6d Wen Yang           2018-12-05  821  		return -ENOMEM;
9f51c05dc41a6d Wen Yang           2018-12-05  822  	}
9f51c05dc41a6d Wen Yang           2018-12-05  823  	ret = alloc_active_ring(map2);
9774c6cca26610 Stefano Stabellini 2017-10-30  824  	if (ret < 0) {
9774c6cca26610 Stefano Stabellini 2017-10-30  825  		clear_bit(PVCALLS_FLAG_ACCEPT_INFLIGHT,
9774c6cca26610 Stefano Stabellini 2017-10-30  826  				(void *)&map->passive.flags);
9f51c05dc41a6d Wen Yang           2018-12-05  827  		kfree(map2);
64d6871827b1e2 Stefano Stabellini 2018-02-14  828  		pvcalls_exit_sock(sock);
9774c6cca26610 Stefano Stabellini 2017-10-30  829  		return ret;
9774c6cca26610 Stefano Stabellini 2017-10-30  830  	}
c66bb48edd58c3 Juergen Gross      2023-04-03  831  	ret = create_active(map2, &evtchn);
9f51c05dc41a6d Wen Yang           2018-12-05  832  	if (ret < 0) {
9f51c05dc41a6d Wen Yang           2018-12-05  833  		free_active_ring(map2);
9f51c05dc41a6d Wen Yang           2018-12-05  834  		kfree(map2);
c66bb48edd58c3 Juergen Gross      2023-04-03  835  		clear_bit(PVCALLS_FLAG_ACCEPT_INFLIGHT,
c66bb48edd58c3 Juergen Gross      2023-04-03  836  			  (void *)&map->passive.flags);
64d6871827b1e2 Stefano Stabellini 2018-02-14  837  		pvcalls_exit_sock(sock);
9f51c05dc41a6d Wen Yang           2018-12-05  838  		return ret;
9774c6cca26610 Stefano Stabellini 2017-10-30  839  	}
9f51c05dc41a6d Wen Yang           2018-12-05  840  
c66bb48edd58c3 Juergen Gross      2023-04-03  841  	spin_lock(&bedata->socket_lock);
c66bb48edd58c3 Juergen Gross      2023-04-03  842  	ret = get_request(bedata, &req_id);
9774c6cca26610 Stefano Stabellini 2017-10-30  843  	if (ret < 0) {
9774c6cca26610 Stefano Stabellini 2017-10-30  844  		clear_bit(PVCALLS_FLAG_ACCEPT_INFLIGHT,
9774c6cca26610 Stefano Stabellini 2017-10-30  845  			  (void *)&map->passive.flags);
9774c6cca26610 Stefano Stabellini 2017-10-30  846  		spin_unlock(&bedata->socket_lock);
c66bb48edd58c3 Juergen Gross      2023-04-03  847  		pvcalls_front_free_map(bedata, map2);
64d6871827b1e2 Stefano Stabellini 2018-02-14  848  		pvcalls_exit_sock(sock);
9774c6cca26610 Stefano Stabellini 2017-10-30  849  		return ret;
9774c6cca26610 Stefano Stabellini 2017-10-30  850  	}
c66bb48edd58c3 Juergen Gross      2023-04-03  851  
9774c6cca26610 Stefano Stabellini 2017-10-30  852  	list_add_tail(&map2->list, &bedata->socket_mappings);
9774c6cca26610 Stefano Stabellini 2017-10-30  853  
9774c6cca26610 Stefano Stabellini 2017-10-30  854  	req = RING_GET_REQUEST(&bedata->ring, req_id);
9774c6cca26610 Stefano Stabellini 2017-10-30  855  	req->req_id = req_id;
9774c6cca26610 Stefano Stabellini 2017-10-30  856  	req->cmd = PVCALLS_ACCEPT;
9774c6cca26610 Stefano Stabellini 2017-10-30  857  	req->u.accept.id = (uintptr_t) map;
9774c6cca26610 Stefano Stabellini 2017-10-30  858  	req->u.accept.ref = map2->active.ref;
9774c6cca26610 Stefano Stabellini 2017-10-30  859  	req->u.accept.id_new = (uintptr_t) map2;
9774c6cca26610 Stefano Stabellini 2017-10-30  860  	req->u.accept.evtchn = evtchn;
9774c6cca26610 Stefano Stabellini 2017-10-30  861  	map->passive.accept_map = map2;
9774c6cca26610 Stefano Stabellini 2017-10-30  862  
9774c6cca26610 Stefano Stabellini 2017-10-30  863  	bedata->ring.req_prod_pvt++;
9774c6cca26610 Stefano Stabellini 2017-10-30  864  	RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(&bedata->ring, notify);
9774c6cca26610 Stefano Stabellini 2017-10-30  865  	spin_unlock(&bedata->socket_lock);
9774c6cca26610 Stefano Stabellini 2017-10-30  866  	if (notify)
9774c6cca26610 Stefano Stabellini 2017-10-30  867  		notify_remote_via_irq(bedata->irq);
9774c6cca26610 Stefano Stabellini 2017-10-30  868  	/* We could check if we have received a response before returning. */
9774c6cca26610 Stefano Stabellini 2017-10-30  869  	if (nonblock) {
9774c6cca26610 Stefano Stabellini 2017-10-30  870  		WRITE_ONCE(map->passive.inflight_req_id, req_id);
64d6871827b1e2 Stefano Stabellini 2018-02-14  871  		pvcalls_exit_sock(sock);
9774c6cca26610 Stefano Stabellini 2017-10-30  872  		return -EAGAIN;
9774c6cca26610 Stefano Stabellini 2017-10-30  873  	}
9774c6cca26610 Stefano Stabellini 2017-10-30  874  
9774c6cca26610 Stefano Stabellini 2017-10-30  875  	if (wait_event_interruptible(bedata->inflight_req,
9774c6cca26610 Stefano Stabellini 2017-10-30  876  		READ_ONCE(bedata->rsp[req_id].req_id) == req_id)) {
64d6871827b1e2 Stefano Stabellini 2018-02-14  877  		pvcalls_exit_sock(sock);
9774c6cca26610 Stefano Stabellini 2017-10-30  878  		return -EINTR;
9774c6cca26610 Stefano Stabellini 2017-10-30  879  	}
9774c6cca26610 Stefano Stabellini 2017-10-30  880  	/* read req_id, then the content */
9774c6cca26610 Stefano Stabellini 2017-10-30  881  	smp_rmb();
9774c6cca26610 Stefano Stabellini 2017-10-30  882  
9774c6cca26610 Stefano Stabellini 2017-10-30  883  received:
9774c6cca26610 Stefano Stabellini 2017-10-30  884  	map2->sock = newsock;
beee1fbe8f7d57 Stefano Stabellini 2018-12-21  885  	newsock->sk = sk_alloc(sock_net(sock->sk), PF_INET, GFP_KERNEL, &pvcalls_proto, false);
9774c6cca26610 Stefano Stabellini 2017-10-30  886  	if (!newsock->sk) {
9774c6cca26610 Stefano Stabellini 2017-10-30  887  		bedata->rsp[req_id].req_id = PVCALLS_INVALID_ID;
9774c6cca26610 Stefano Stabellini 2017-10-30  888  		map->passive.inflight_req_id = PVCALLS_INVALID_ID;
9774c6cca26610 Stefano Stabellini 2017-10-30  889  		clear_bit(PVCALLS_FLAG_ACCEPT_INFLIGHT,
9774c6cca26610 Stefano Stabellini 2017-10-30  890  			  (void *)&map->passive.flags);
9774c6cca26610 Stefano Stabellini 2017-10-30  891  		pvcalls_front_free_map(bedata, map2);
64d6871827b1e2 Stefano Stabellini 2018-02-14  892  		pvcalls_exit_sock(sock);
9774c6cca26610 Stefano Stabellini 2017-10-30  893  		return -ENOMEM;
9774c6cca26610 Stefano Stabellini 2017-10-30  894  	}
9774c6cca26610 Stefano Stabellini 2017-10-30  895  	newsock->sk->sk_send_head = (void *)map2;
9774c6cca26610 Stefano Stabellini 2017-10-30  896  
9774c6cca26610 Stefano Stabellini 2017-10-30  897  	ret = bedata->rsp[req_id].ret;
9774c6cca26610 Stefano Stabellini 2017-10-30  898  	bedata->rsp[req_id].req_id = PVCALLS_INVALID_ID;
9774c6cca26610 Stefano Stabellini 2017-10-30  899  	map->passive.inflight_req_id = PVCALLS_INVALID_ID;
9774c6cca26610 Stefano Stabellini 2017-10-30  900  
9774c6cca26610 Stefano Stabellini 2017-10-30  901  	clear_bit(PVCALLS_FLAG_ACCEPT_INFLIGHT, (void *)&map->passive.flags);
9774c6cca26610 Stefano Stabellini 2017-10-30  902  	wake_up(&map->passive.inflight_accept_req);
9774c6cca26610 Stefano Stabellini 2017-10-30  903  
64d6871827b1e2 Stefano Stabellini 2018-02-14  904  	pvcalls_exit_sock(sock);
9774c6cca26610 Stefano Stabellini 2017-10-30  905  	return ret;
9774c6cca26610 Stefano Stabellini 2017-10-30  906  }
9774c6cca26610 Stefano Stabellini 2017-10-30  907  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From xen-devel-bounces@lists.xenproject.org Sat Jan 04 18:33:26 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 18:33:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865441.1276739 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tU8xb-0003ID-61; Sat, 04 Jan 2025 18:33:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865441.1276739; Sat, 04 Jan 2025 18:33:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tU8xb-0003I6-2n; Sat, 04 Jan 2025 18:33:19 +0000
Received: by outflank-mailman (input) for mailman id 865441;
 Sat, 04 Jan 2025 18:33: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 <SRS0=DJS+=T4=intel.com=lkp@srs-se1.protection.inumbo.net>)
 id 1tU8xa-0003I0-3k
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 18:33:18 +0000
Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5b32bba9-caca-11ef-99a4-01e77a169b0f;
 Sat, 04 Jan 2025 19:33:15 +0100 (CET)
Received: from orviesa005.jf.intel.com ([10.64.159.145])
 by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 04 Jan 2025 10:33:12 -0800
Received: from lkp-server01.sh.intel.com (HELO d63d4d77d921) ([10.239.97.150])
 by orviesa005.jf.intel.com with ESMTP; 04 Jan 2025 10:33:10 -0800
Received: from kbuild by d63d4d77d921 with local (Exim 4.96)
 (envelope-from <lkp@intel.com>) id 1tU8xQ-000B8N-1h;
 Sat, 04 Jan 2025 18:33:08 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5b32bba9-caca-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=intel.com; i=@intel.com; q=dns/txt; s=Intel;
  t=1736015595; x=1767551595;
  h=date:from:to:cc:subject:message-id:references:
   mime-version:in-reply-to;
  bh=5Zxqc5izWZcqv++Qn3LTRHW/mpIz46TucxWfDkg9PUs=;
  b=FwDI/HSB0GHzoQeXGlPVShMntkgyhvUoeuEdJk77RDhFLGgcki9FcLdy
   BQyEE6Z5LOldLbMzURyk0zN+dmwQGgD4x75WXo0RPoJt8gjRbiOEm3Pds
   VQlJXwSjzBWgc2BJAbvaMcytB+lImO0LMNzGO50p/RVBbttnzQeh6/IMf
   /Oa/MraJNxEk6bROTvdLzIcyrgJxWfnayNKosoOWRMZqIpfkoxekasNvn
   SUOskSTTCp9W6AR30aL+w8otTSPibRufPKGQ6eQow0gfTbSseLQbukvNb
   yaxYRPoElWu70OJTAd5OW0uNvw+FwWHBIyLOxyLmnF0z7J5fnvcP9VqQy
   A==;
X-CSE-ConnectionGUID: mpjkV3QJQyCBgSXaSTRH5Q==
X-CSE-MsgGUID: +5RjqubrQWWG6TbwrqqPLQ==
X-IronPort-AV: E=McAfee;i="6700,10204,11305"; a="36381334"
X-IronPort-AV: E=Sophos;i="6.12,288,1728975600"; 
   d="scan'208";a="36381334"
X-CSE-ConnectionGUID: /3uRxK37RgasfXozjtkmKg==
X-CSE-MsgGUID: kwfhmatiSymtaMqT+/+OnQ==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="6.12,224,1728975600"; 
   d="scan'208";a="107106643"
Date: Sun, 5 Jan 2025 02:32:10 +0800
From: kernel test robot <lkp@intel.com>
To: Stefano Stabellini <sstabellini@kernel.org>,
	linux-kernel@vger.kernel.org
Cc: oe-kbuild-all@lists.linux.dev, sstabellini@kernel.org, jgross@suse.com,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH] xen: update pvcalls_front_accept prototype
Message-ID: <202501050224.Z3WcNxIQ-lkp@intel.com>
References: <alpine.DEB.2.22.394.2501031501420.16425@ubuntu-linux-20-04-desktop>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.22.394.2501031501420.16425@ubuntu-linux-20-04-desktop>

Hi Stefano,

kernel test robot noticed the following build errors:

[auto build test ERROR on xen-tip/linux-next]
[also build test ERROR on linus/master v6.13-rc5 next-20241220]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Stefano-Stabellini/xen-update-pvcalls_front_accept-prototype/20250104-070503
base:   https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git linux-next
patch link:    https://lore.kernel.org/r/alpine.DEB.2.22.394.2501031501420.16425%40ubuntu-linux-20-04-desktop
patch subject: [PATCH] xen: update pvcalls_front_accept prototype
config: i386-allmodconfig (https://download.01.org/0day-ci/archive/20250105/202501050224.Z3WcNxIQ-lkp@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250105/202501050224.Z3WcNxIQ-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202501050224.Z3WcNxIQ-lkp@intel.com/

All errors (new ones prefixed by >>):

>> drivers/xen/pvcalls-front.c:772:5: error: conflicting types for 'pvcalls_front_accept'; have 'int(struct socket *, struct socket *, int)'
     772 | int pvcalls_front_accept(struct socket *sock, struct socket *newsock, int flags)
         |     ^~~~~~~~~~~~~~~~~~~~
   In file included from drivers/xen/pvcalls-front.c:18:
   drivers/xen/pvcalls-front.h:13:5: note: previous declaration of 'pvcalls_front_accept' with type 'int(struct socket *, struct socket *, struct proto_accept_arg *)'
      13 | int pvcalls_front_accept(struct socket *sock,
         |     ^~~~~~~~~~~~~~~~~~~~


vim +772 drivers/xen/pvcalls-front.c

1853f11d72ed46 Stefano Stabellini 2017-10-30  771  
9774c6cca26610 Stefano Stabellini 2017-10-30 @772  int pvcalls_front_accept(struct socket *sock, struct socket *newsock, int flags)
9774c6cca26610 Stefano Stabellini 2017-10-30  773  {
9774c6cca26610 Stefano Stabellini 2017-10-30  774  	struct pvcalls_bedata *bedata;
9774c6cca26610 Stefano Stabellini 2017-10-30  775  	struct sock_mapping *map;
9774c6cca26610 Stefano Stabellini 2017-10-30  776  	struct sock_mapping *map2 = NULL;
9774c6cca26610 Stefano Stabellini 2017-10-30  777  	struct xen_pvcalls_request *req;
0102e4efda76d0 Yan Yankovskyi     2020-03-23  778  	int notify, req_id, ret, nonblock;
0102e4efda76d0 Yan Yankovskyi     2020-03-23  779  	evtchn_port_t evtchn;
9774c6cca26610 Stefano Stabellini 2017-10-30  780  
64d6871827b1e2 Stefano Stabellini 2018-02-14  781  	map = pvcalls_enter_sock(sock);
64d6871827b1e2 Stefano Stabellini 2018-02-14  782  	if (IS_ERR(map))
64d6871827b1e2 Stefano Stabellini 2018-02-14  783  		return PTR_ERR(map);
9774c6cca26610 Stefano Stabellini 2017-10-30  784  	bedata = dev_get_drvdata(&pvcalls_front_dev->dev);
9774c6cca26610 Stefano Stabellini 2017-10-30  785  
9774c6cca26610 Stefano Stabellini 2017-10-30  786  	if (map->passive.status != PVCALLS_STATUS_LISTEN) {
64d6871827b1e2 Stefano Stabellini 2018-02-14  787  		pvcalls_exit_sock(sock);
9774c6cca26610 Stefano Stabellini 2017-10-30  788  		return -EINVAL;
9774c6cca26610 Stefano Stabellini 2017-10-30  789  	}
9774c6cca26610 Stefano Stabellini 2017-10-30  790  
9774c6cca26610 Stefano Stabellini 2017-10-30  791  	nonblock = flags & SOCK_NONBLOCK;
9774c6cca26610 Stefano Stabellini 2017-10-30  792  	/*
9774c6cca26610 Stefano Stabellini 2017-10-30  793  	 * Backend only supports 1 inflight accept request, will return
9774c6cca26610 Stefano Stabellini 2017-10-30  794  	 * errors for the others
9774c6cca26610 Stefano Stabellini 2017-10-30  795  	 */
9774c6cca26610 Stefano Stabellini 2017-10-30  796  	if (test_and_set_bit(PVCALLS_FLAG_ACCEPT_INFLIGHT,
9774c6cca26610 Stefano Stabellini 2017-10-30  797  			     (void *)&map->passive.flags)) {
9774c6cca26610 Stefano Stabellini 2017-10-30  798  		req_id = READ_ONCE(map->passive.inflight_req_id);
9774c6cca26610 Stefano Stabellini 2017-10-30  799  		if (req_id != PVCALLS_INVALID_ID &&
9774c6cca26610 Stefano Stabellini 2017-10-30  800  		    READ_ONCE(bedata->rsp[req_id].req_id) == req_id) {
9774c6cca26610 Stefano Stabellini 2017-10-30  801  			map2 = map->passive.accept_map;
9774c6cca26610 Stefano Stabellini 2017-10-30  802  			goto received;
9774c6cca26610 Stefano Stabellini 2017-10-30  803  		}
9774c6cca26610 Stefano Stabellini 2017-10-30  804  		if (nonblock) {
64d6871827b1e2 Stefano Stabellini 2018-02-14  805  			pvcalls_exit_sock(sock);
9774c6cca26610 Stefano Stabellini 2017-10-30  806  			return -EAGAIN;
9774c6cca26610 Stefano Stabellini 2017-10-30  807  		}
9774c6cca26610 Stefano Stabellini 2017-10-30  808  		if (wait_event_interruptible(map->passive.inflight_accept_req,
9774c6cca26610 Stefano Stabellini 2017-10-30  809  			!test_and_set_bit(PVCALLS_FLAG_ACCEPT_INFLIGHT,
9774c6cca26610 Stefano Stabellini 2017-10-30  810  					  (void *)&map->passive.flags))) {
64d6871827b1e2 Stefano Stabellini 2018-02-14  811  			pvcalls_exit_sock(sock);
9774c6cca26610 Stefano Stabellini 2017-10-30  812  			return -EINTR;
9774c6cca26610 Stefano Stabellini 2017-10-30  813  		}
9774c6cca26610 Stefano Stabellini 2017-10-30  814  	}
9774c6cca26610 Stefano Stabellini 2017-10-30  815  
9f51c05dc41a6d Wen Yang           2018-12-05  816  	map2 = kzalloc(sizeof(*map2), GFP_KERNEL);
9f51c05dc41a6d Wen Yang           2018-12-05  817  	if (map2 == NULL) {
9f51c05dc41a6d Wen Yang           2018-12-05  818  		clear_bit(PVCALLS_FLAG_ACCEPT_INFLIGHT,
9f51c05dc41a6d Wen Yang           2018-12-05  819  			  (void *)&map->passive.flags);
9f51c05dc41a6d Wen Yang           2018-12-05  820  		pvcalls_exit_sock(sock);
9f51c05dc41a6d Wen Yang           2018-12-05  821  		return -ENOMEM;
9f51c05dc41a6d Wen Yang           2018-12-05  822  	}
9f51c05dc41a6d Wen Yang           2018-12-05  823  	ret = alloc_active_ring(map2);
9774c6cca26610 Stefano Stabellini 2017-10-30  824  	if (ret < 0) {
9774c6cca26610 Stefano Stabellini 2017-10-30  825  		clear_bit(PVCALLS_FLAG_ACCEPT_INFLIGHT,
9774c6cca26610 Stefano Stabellini 2017-10-30  826  				(void *)&map->passive.flags);
9f51c05dc41a6d Wen Yang           2018-12-05  827  		kfree(map2);
64d6871827b1e2 Stefano Stabellini 2018-02-14  828  		pvcalls_exit_sock(sock);
9774c6cca26610 Stefano Stabellini 2017-10-30  829  		return ret;
9774c6cca26610 Stefano Stabellini 2017-10-30  830  	}
c66bb48edd58c3 Juergen Gross      2023-04-03  831  	ret = create_active(map2, &evtchn);
9f51c05dc41a6d Wen Yang           2018-12-05  832  	if (ret < 0) {
9f51c05dc41a6d Wen Yang           2018-12-05  833  		free_active_ring(map2);
9f51c05dc41a6d Wen Yang           2018-12-05  834  		kfree(map2);
c66bb48edd58c3 Juergen Gross      2023-04-03  835  		clear_bit(PVCALLS_FLAG_ACCEPT_INFLIGHT,
c66bb48edd58c3 Juergen Gross      2023-04-03  836  			  (void *)&map->passive.flags);
64d6871827b1e2 Stefano Stabellini 2018-02-14  837  		pvcalls_exit_sock(sock);
9f51c05dc41a6d Wen Yang           2018-12-05  838  		return ret;
9774c6cca26610 Stefano Stabellini 2017-10-30  839  	}
9f51c05dc41a6d Wen Yang           2018-12-05  840  
c66bb48edd58c3 Juergen Gross      2023-04-03  841  	spin_lock(&bedata->socket_lock);
c66bb48edd58c3 Juergen Gross      2023-04-03  842  	ret = get_request(bedata, &req_id);
9774c6cca26610 Stefano Stabellini 2017-10-30  843  	if (ret < 0) {
9774c6cca26610 Stefano Stabellini 2017-10-30  844  		clear_bit(PVCALLS_FLAG_ACCEPT_INFLIGHT,
9774c6cca26610 Stefano Stabellini 2017-10-30  845  			  (void *)&map->passive.flags);
9774c6cca26610 Stefano Stabellini 2017-10-30  846  		spin_unlock(&bedata->socket_lock);
c66bb48edd58c3 Juergen Gross      2023-04-03  847  		pvcalls_front_free_map(bedata, map2);
64d6871827b1e2 Stefano Stabellini 2018-02-14  848  		pvcalls_exit_sock(sock);
9774c6cca26610 Stefano Stabellini 2017-10-30  849  		return ret;
9774c6cca26610 Stefano Stabellini 2017-10-30  850  	}
c66bb48edd58c3 Juergen Gross      2023-04-03  851  
9774c6cca26610 Stefano Stabellini 2017-10-30  852  	list_add_tail(&map2->list, &bedata->socket_mappings);
9774c6cca26610 Stefano Stabellini 2017-10-30  853  
9774c6cca26610 Stefano Stabellini 2017-10-30  854  	req = RING_GET_REQUEST(&bedata->ring, req_id);
9774c6cca26610 Stefano Stabellini 2017-10-30  855  	req->req_id = req_id;
9774c6cca26610 Stefano Stabellini 2017-10-30  856  	req->cmd = PVCALLS_ACCEPT;
9774c6cca26610 Stefano Stabellini 2017-10-30  857  	req->u.accept.id = (uintptr_t) map;
9774c6cca26610 Stefano Stabellini 2017-10-30  858  	req->u.accept.ref = map2->active.ref;
9774c6cca26610 Stefano Stabellini 2017-10-30  859  	req->u.accept.id_new = (uintptr_t) map2;
9774c6cca26610 Stefano Stabellini 2017-10-30  860  	req->u.accept.evtchn = evtchn;
9774c6cca26610 Stefano Stabellini 2017-10-30  861  	map->passive.accept_map = map2;
9774c6cca26610 Stefano Stabellini 2017-10-30  862  
9774c6cca26610 Stefano Stabellini 2017-10-30  863  	bedata->ring.req_prod_pvt++;
9774c6cca26610 Stefano Stabellini 2017-10-30  864  	RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(&bedata->ring, notify);
9774c6cca26610 Stefano Stabellini 2017-10-30  865  	spin_unlock(&bedata->socket_lock);
9774c6cca26610 Stefano Stabellini 2017-10-30  866  	if (notify)
9774c6cca26610 Stefano Stabellini 2017-10-30  867  		notify_remote_via_irq(bedata->irq);
9774c6cca26610 Stefano Stabellini 2017-10-30  868  	/* We could check if we have received a response before returning. */
9774c6cca26610 Stefano Stabellini 2017-10-30  869  	if (nonblock) {
9774c6cca26610 Stefano Stabellini 2017-10-30  870  		WRITE_ONCE(map->passive.inflight_req_id, req_id);
64d6871827b1e2 Stefano Stabellini 2018-02-14  871  		pvcalls_exit_sock(sock);
9774c6cca26610 Stefano Stabellini 2017-10-30  872  		return -EAGAIN;
9774c6cca26610 Stefano Stabellini 2017-10-30  873  	}
9774c6cca26610 Stefano Stabellini 2017-10-30  874  
9774c6cca26610 Stefano Stabellini 2017-10-30  875  	if (wait_event_interruptible(bedata->inflight_req,
9774c6cca26610 Stefano Stabellini 2017-10-30  876  		READ_ONCE(bedata->rsp[req_id].req_id) == req_id)) {
64d6871827b1e2 Stefano Stabellini 2018-02-14  877  		pvcalls_exit_sock(sock);
9774c6cca26610 Stefano Stabellini 2017-10-30  878  		return -EINTR;
9774c6cca26610 Stefano Stabellini 2017-10-30  879  	}
9774c6cca26610 Stefano Stabellini 2017-10-30  880  	/* read req_id, then the content */
9774c6cca26610 Stefano Stabellini 2017-10-30  881  	smp_rmb();
9774c6cca26610 Stefano Stabellini 2017-10-30  882  
9774c6cca26610 Stefano Stabellini 2017-10-30  883  received:
9774c6cca26610 Stefano Stabellini 2017-10-30  884  	map2->sock = newsock;
beee1fbe8f7d57 Stefano Stabellini 2018-12-21  885  	newsock->sk = sk_alloc(sock_net(sock->sk), PF_INET, GFP_KERNEL, &pvcalls_proto, false);
9774c6cca26610 Stefano Stabellini 2017-10-30  886  	if (!newsock->sk) {
9774c6cca26610 Stefano Stabellini 2017-10-30  887  		bedata->rsp[req_id].req_id = PVCALLS_INVALID_ID;
9774c6cca26610 Stefano Stabellini 2017-10-30  888  		map->passive.inflight_req_id = PVCALLS_INVALID_ID;
9774c6cca26610 Stefano Stabellini 2017-10-30  889  		clear_bit(PVCALLS_FLAG_ACCEPT_INFLIGHT,
9774c6cca26610 Stefano Stabellini 2017-10-30  890  			  (void *)&map->passive.flags);
9774c6cca26610 Stefano Stabellini 2017-10-30  891  		pvcalls_front_free_map(bedata, map2);
64d6871827b1e2 Stefano Stabellini 2018-02-14  892  		pvcalls_exit_sock(sock);
9774c6cca26610 Stefano Stabellini 2017-10-30  893  		return -ENOMEM;
9774c6cca26610 Stefano Stabellini 2017-10-30  894  	}
9774c6cca26610 Stefano Stabellini 2017-10-30  895  	newsock->sk->sk_send_head = (void *)map2;
9774c6cca26610 Stefano Stabellini 2017-10-30  896  
9774c6cca26610 Stefano Stabellini 2017-10-30  897  	ret = bedata->rsp[req_id].ret;
9774c6cca26610 Stefano Stabellini 2017-10-30  898  	bedata->rsp[req_id].req_id = PVCALLS_INVALID_ID;
9774c6cca26610 Stefano Stabellini 2017-10-30  899  	map->passive.inflight_req_id = PVCALLS_INVALID_ID;
9774c6cca26610 Stefano Stabellini 2017-10-30  900  
9774c6cca26610 Stefano Stabellini 2017-10-30  901  	clear_bit(PVCALLS_FLAG_ACCEPT_INFLIGHT, (void *)&map->passive.flags);
9774c6cca26610 Stefano Stabellini 2017-10-30  902  	wake_up(&map->passive.inflight_accept_req);
9774c6cca26610 Stefano Stabellini 2017-10-30  903  
64d6871827b1e2 Stefano Stabellini 2018-02-14  904  	pvcalls_exit_sock(sock);
9774c6cca26610 Stefano Stabellini 2017-10-30  905  	return ret;
9774c6cca26610 Stefano Stabellini 2017-10-30  906  }
9774c6cca26610 Stefano Stabellini 2017-10-30  907  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From xen-devel-bounces@lists.xenproject.org Sat Jan 04 18:50:16 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Jan 2025 18:50:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865454.1276749 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tU9Ds-0006Eu-MU; Sat, 04 Jan 2025 18:50:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865454.1276749; Sat, 04 Jan 2025 18:50:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tU9Ds-0006En-JM; Sat, 04 Jan 2025 18:50:08 +0000
Received: by outflank-mailman (input) for mailman id 865454;
 Sat, 04 Jan 2025 18:50:07 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=31/0=T4=suse.com=jgross@srs-se1.protection.inumbo.net>)
 id 1tU9Dr-0006Eh-AZ
 for xen-devel@lists.xenproject.org; Sat, 04 Jan 2025 18:50:07 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b68f7070-cacc-11ef-a0de-8be0dac302b0;
 Sat, 04 Jan 2025 19:50:06 +0100 (CET)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-5d0d32cd31aso19361529a12.0
 for <xen-devel@lists.xenproject.org>; Sat, 04 Jan 2025 10:50:06 -0800 (PST)
Received: from ?IPV6:2003:e5:8731:2800:842d:42a0:5992:3595?
 (p200300e587312800842d42a059923595.dip0.t-ipconnect.de.
 [2003:e5:8731:2800:842d:42a0:5992:3595])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0eae4338sm2016788266b.86.2025.01.04.10.50.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sat, 04 Jan 2025 10:50:04 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b68f7070-cacc-11ef-a0de-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736016605; x=1736621405; darn=lists.xenproject.org;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=4xbqskmVl9LMF5WLmG6RtwR0GbsoUMiWmwvC3Jcln1s=;
        b=eRkYy93lHxMW51k8sCNnTtGyb3gGTUKkO3xIOp4+GXD03UP0AsPtN/vF2EZJ4exEeh
         WHX5JMCx9Xa1u2jbLrnajpwMwBS3CQOUykgsEHgtdjtYA3jK3BpzPjFNGxh3B80IE16g
         YPOd01Eftd1TrS4xQnP/SXF2Xv9QU7IabLt00iaQod2u+3XtKRwR3FhlDqe94yRhNuNW
         BfeYTfH+ZIA76T2Xrrp5W68E4J5z5yM8fDcWII+7xiXCto4otvsPq9VXUxdFSXY1DwQh
         ZR4vj8BaeEdCeBv9VVJok9wlq+xm68u2Vd7YbQ7dhjiH4lClkP9SXviCPZzfyYlAK3Kk
         erDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736016605; x=1736621405;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=4xbqskmVl9LMF5WLmG6RtwR0GbsoUMiWmwvC3Jcln1s=;
        b=qOhYxzJxAWsZjqMwngmEMW77UZYCBN2VTH666WZfkC4+VarTnT195u0N+6WhKqaETA
         3t5erglK9oOg/21i3BWfwgko8ufIBNgAqvmd+sqtFOp/lMWxoK4PmGizKsNVtNQuPUe+
         9l2d2gFL10LA7yE3dlIanF9bTFTkUAXZXWFbjstHggQApvLcqmc0QumfcR+JlntlQZ9N
         JrL3d+NmpNdPzUkkMI2tsXQ9huajGLQqBPSdJNv3kMG9rrN/jJRHVGfXCL0bhA+OSCVc
         ssPe14tGmWFMV6r/LbMph+oOaTVsBzp/TxmtpOSIQPk66ExKzdH4yKpYeIipKcCm7NWS
         rU2w==
X-Forwarded-Encrypted: i=1; AJvYcCVDJR6z48eP9qflMp8kUz5HkF0dMDTg8/jlJU8ynwVmp1WYlmfGc5fzUPDUpkEFCn6RwNU5lfVzhRk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxwANgspdR57FC+LpcR3savxdOVJt1nM4ajL5f6eKQm65FxfR2t
	s0efCP74lJMM30t0wGRcKBEWjsIAC99PGUBhwk7XgkfrLF8Dt2SJzOxmCMM0C0QqVx79TZptJQL
	HgWU=
X-Gm-Gg: ASbGncscopSE//zC8M1QEHbniz4bmWyAjiYKP3uMJnA9wujlQSxyK0iXqE2wclC0y1X
	bvJyhHid1nFdHbIcaoWmK5o9cDrflWxOhgpyr8d2aCzRoxN86CFcgSecFXevzZfGxsjoKwEVow3
	p2I9scugUyeTIMQA9d8wGIf2lm75nMYMTweYhYmyLuFkIQTLSaNAv4+3AhaZzKY17GO2BVj6jMY
	QgCEBvgpF/ekxO1gBAtG6O0zrvi5mveX+KyR+mVPKW8WVYzcnr1N1M1mz5SSqYKdecu+4gyfOy8
	kyXEZoZ8KRA+7ObkT1se/OLVto86CM+TKNjG4fwq0WtKHLtadjFoQsuFzsqDpY7jj2bReKFWqMk
	su8l1rA==
X-Google-Smtp-Source: AGHT+IH6JqlEdi4eLZUiMOVkc2LD7qe+olNkIH27IhakMmYwimzE1m1ZagTWYMDIG85xxLcbUnZIYw==
X-Received: by 2002:a05:6402:4403:b0:5d0:d2ed:ebb with SMTP id 4fb4d7f45d1cf-5d81dd83a72mr134588379a12.3.1736016605025;
        Sat, 04 Jan 2025 10:50:05 -0800 (PST)
Message-ID: <28947d4f-ab32-4a57-8dbb-e37fa4183a69@suse.com>
Date: Sat, 4 Jan 2025 19:50:03 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/xen/mmu: Increase MAX_CONTIG_ORDER
To: Jan Beulich <jbeulich@suse.com>
Cc: sstabellini@kernel.org, oleksandr_tyshchenko@epam.com,
 xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
 Thierry Escande <thierry.escande@vates.tech>
References: <20241204171346.458105-1-thierry.escande@vates.tech>
 <ccb28ccc-531c-4ead-9a27-76cc430f8c35@suse.com>
 <cc61bdce-47af-45ea-8ace-173adef9ae41@vates.tech>
 <cbc389e4-3b69-4681-ad66-6102b0ed0cae@suse.com>
 <8fb77778-b821-4e38-a835-54883ba14e4b@suse.com>
 <ed764807-a58b-473c-911d-b52f013f89b2@vates.tech>
 <733e95a6-dd33-422a-a25b-9f08cef5860e@suse.com>
 <781a2f80-9ca6-4875-9b4a-ecef7694ae2e@suse.com>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <781a2f80-9ca6-4875-9b4a-ecef7694ae2e@suse.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------yAX3fS0apYGCcAvBCMjz1MzQ"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------yAX3fS0apYGCcAvBCMjz1MzQ
Content-Type: multipart/mixed; boundary="------------nF0PLdcdO0lDs4cED1rJUuCH";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: sstabellini@kernel.org, oleksandr_tyshchenko@epam.com,
 xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
 Thierry Escande <thierry.escande@vates.tech>
Message-ID: <28947d4f-ab32-4a57-8dbb-e37fa4183a69@suse.com>
Subject: Re: [PATCH] x86/xen/mmu: Increase MAX_CONTIG_ORDER
References: <20241204171346.458105-1-thierry.escande@vates.tech>
 <ccb28ccc-531c-4ead-9a27-76cc430f8c35@suse.com>
 <cc61bdce-47af-45ea-8ace-173adef9ae41@vates.tech>
 <cbc389e4-3b69-4681-ad66-6102b0ed0cae@suse.com>
 <8fb77778-b821-4e38-a835-54883ba14e4b@suse.com>
 <ed764807-a58b-473c-911d-b52f013f89b2@vates.tech>
 <733e95a6-dd33-422a-a25b-9f08cef5860e@suse.com>
 <781a2f80-9ca6-4875-9b4a-ecef7694ae2e@suse.com>
In-Reply-To: <781a2f80-9ca6-4875-9b4a-ecef7694ae2e@suse.com>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------nF0PLdcdO0lDs4cED1rJUuCH
Content-Type: multipart/mixed; boundary="------------F0xkLDiSGwSCfzoa0qysJ23k"

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

T24gMTkuMTIuMjQgMDg6MTIsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAxOC4xMi4yMDI0
IDEyOjI0LCBKw7xyZ2VuIEdyb8OfIHdyb3RlOg0KPj4gT24gMTguMTIuMjQgMTI6MTEsIFRo
aWVycnkgRXNjYW5kZSB3cm90ZToNCj4+Pg0KPj4+DQo+Pj4gT24gMTIvMTIvMjAyNCAxMjow
OSwgSnVlcmdlbiBHcm9zcyB3cm90ZToNCj4+Pj4gT24gMTIuMTIuMjQgMTE6MjIsIEphbiBC
ZXVsaWNoIHdyb3RlOg0KPj4+Pj4gT24gMTEuMTIuMjAyNCAxOToyMCwgVGhpZXJyeSBFc2Nh
bmRlIHdyb3RlOg0KPj4+Pj4+IEhpIEphbiwNCj4+Pj4+Pg0KPj4+Pj4+IE9uIDA5LzEyLzIw
MjQgMTE6MDQsIEphbiBCZXVsaWNoIHdyb3RlOg0KPj4+Pj4+PiBPbiAwNC4xMi4yMDI0IDE4
OjE0LCBUaGllcnJ5IEVzY2FuZGUgd3JvdGU6DQo+Pj4+Pj4+PiBXaXRoIGNoYW5nZSA5ZjQw
ZWM4NGE3OTcgKHhlbi9zd2lvdGxiOiBhZGQgYWxpZ25tZW50IGNoZWNrIGZvciBkbWENCj4+
Pj4+Pj4+IGJ1ZmZlcnMpLCB0aGUgZHJpdmVyIG1wdDNzYXMgZmFpbHMgdG8gbG9hZCBiZWNh
dXNlIGl0IGNhbm5vdCBhbGxvY2F0ZQ0KPj4+Pj4+Pj4gaXRzIERNQSBwb29sIGZvciBhbiBh
bGxvY2F0aW9uIHNpemUgb2YgfjIsMyBNQnl0ZXMuIFRoaXMgaXMgYmVjYXVzZQ0KPj4+Pj4+
Pj4gdGhlDQo+Pj4+Pj4+PiBhbGlnbmVtZW50IGNoZWNrIGFkZGVkIGJ5IDlmNDBlYzg0YTc5
NyBmYWlscyBhbmQNCj4+Pj4+Pj4+IHhlbl9zd2lvdGxiX2FsbG9jX2NvaGVyZW50KCkgZW5k
cyB1cCBjYWxsaW5nDQo+Pj4+Pj4+PiB4ZW5fY3JlYXRlX2NvbnRpZ3VvdXNfcmVnaW9uKCkg
d2l0aCBhIHNpemUgb3JkZXIgb2YgMTAgd2hpY2ggaXMgdG9vDQo+Pj4+Pj4+PiBoaWdoDQo+
Pj4+Pj4+PiBmb3IgdGhlIGN1cnJlbnQgbWF4IHZhbHVlLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+
IFRoaXMgcGF0Y2ggaW5jcmVhc2VzIHRoZSBNQVhfQ09OVElHX09SREVSIGZyb20gOSB0byAx
MCAoNE1CKSB0byBhbGxvdw0KPj4+Pj4+Pj4gc3VjaCBhbGxvY2F0aW9ucy4NCj4+Pj4+Pj4+
DQo+Pj4+Pj4+PiBTaWduZWQtb2ZmLWJ5OiBUaGllcnJ5IEVzY2FuZGUgPHRoaWVycnkuZXNj
YW5kZUB2YXRlcy50ZWNoPg0KPj4+Pj4+Pj4gLS0tDQo+Pj4+Pj4+PiAgIMKgIGFyY2gveDg2
L3hlbi9tbXVfcHYuYyB8IDIgKy0NCj4+Pj4+Pj4+ICAgwqAgMSBmaWxlIGNoYW5nZWQsIDEg
aW5zZXJ0aW9uKCspLCAxIGRlbGV0aW9uKC0pDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gZGlmZiAt
LWdpdCBhL2FyY2gveDg2L3hlbi9tbXVfcHYuYyBiL2FyY2gveDg2L3hlbi9tbXVfcHYuYw0K
Pj4+Pj4+Pj4gaW5kZXggNTVhNDk5NmQwYzA0Li43ZjExMDc0MGUxYTIgMTAwNjQ0DQo+Pj4+
Pj4+PiAtLS0gYS9hcmNoL3g4Ni94ZW4vbW11X3B2LmMNCj4+Pj4+Pj4+ICsrKyBiL2FyY2gv
eDg2L3hlbi9tbXVfcHYuYw0KPj4+Pj4+Pj4gQEAgLTIyMDAsNyArMjIwMCw3IEBAIHZvaWQg
X19pbml0IHhlbl9pbml0X21tdV9vcHModm9pZCkNCj4+Pj4+Pj4+ICAgwqAgfQ0KPj4+Pj4+
Pj4gICDCoCDCoCAvKiBQcm90ZWN0ZWQgYnkgeGVuX3Jlc2VydmF0aW9uX2xvY2suICovDQo+
Pj4+Pj4+PiAtI2RlZmluZSBNQVhfQ09OVElHX09SREVSIDkgLyogMk1CICovDQo+Pj4+Pj4+
PiArI2RlZmluZSBNQVhfQ09OVElHX09SREVSIDEwIC8qIDRNQiAqLw0KPj4+Pj4+Pj4gICDC
oCBzdGF0aWMgdW5zaWduZWQgbG9uZyBkaXNjb250aWdfZnJhbWVzWzE8PE1BWF9DT05USUdf
T1JERVJdOw0KPj4+Pj4+Pg0KPj4+Pj4+PiBXaGlsZSBsYWNraW5nIHJlc3BlY3RpdmUgY29t
bWVudGFyeSwgYnVtcGluZyB0aGlzIHZhbHVlIGltbyBhbHNvDQo+Pj4+Pj4+IG5lZWRzIHRv
DQo+Pj4+Pj4+IHRha2UgaW50byBhY2NvdW50IFhlbiBpdHNlbGYsIGF0IGxlYXN0IGNvbW1p
dC1tZXNzYWdlLXdpc2UuIFRoZQ0KPj4+Pj4+PiBidW1waW5nIGlzDQo+Pj4+Pj4+IGZpbmUg
Zm9yIERvbTAgaW4gYW55IGV2ZW50LiBJdCBpcyBhbHNvIGZpbmUgZm9yIERvbVUtcyB3aXRo
IHRoZQ0KPj4+Pj4+PiBkZWZhdWx0cw0KPj4+Pj4+PiBidWlsdCBpbnRvIHRoZSBoeXBlcnZp
c29yIChvcmRlcnMgMTIgYW5kIDEwIHJlc3BlY3RpdmVseSBmb3IgeDg2IGFuZA0KPj4+Pj4+
PiBBcm0pLA0KPj4+Pj4+PiB5ZXQgZXNwZWNpYWxseSBmb3IgQXJtIChhbmQgaW4gdGhlIGZ1
dHVyZSBQUEMgYW5kIFJJU0MtVikgYW55IGZ1cnRoZXINCj4+Pj4+Pj4gYnVtcGluZyB3b3Vs
ZCBiZSBsZXNzIHN0cmFpZ2h0Zm9yd2FyZC4NCj4+Pj4+Pg0KPj4+Pj4+IFRoYW5rcyBmb3Ig
cG9pbnRpbmcgdGhpcyBvdXQuIE9uIHRoZSBYZW4gc2lkZSwgQ09ORklHX0NUTERPTV9NQVhf
T1JERVINCj4+Pj4+PiBhbmQgQ09ORklHX0hXRE9NX01BWF9PUkRFUiBzZWVtIGJpZyBlbm91
Z2ggb24gYWxsIGFyY2hpdGVjdHVyZXMuIEJ1dCBJDQo+Pj4+Pj4gc2VlIENPTkZJR19ET01V
X01BWF9PUkRFUiBzZXQgdG8gOSAoYWxzbyBhbGwgYXJjaHMpLiBXb24ndCB0aGF0IGJlIGEN
Cj4+Pj4+PiBwcm9ibGVtIGZvciBkcml2ZXJzIHRyeWluZyB0byBhbGxvY2F0ZSBtb3JlIHRo
YW4gdGhhdCBmcm9tIGEgZG9tVSA/DQo+Pj4+Pg0KPj4+Pj4gQSBkcml2ZXIgYXNzdW1lcyBh
IChwaHlzaWNhbCkgZGV2aWNlIHRvIGJlIGluIHRoZSBEb21VLCBhdCB3aGljaCBwb2ludCBp
dA0KPj4+Pj4gaXMgQ09ORklHX1BURE9NX01BWF9PUkRFUiB3aGljaCBhcHBsaWVzIChQVCBz
dGFuZGluZyBmb3IgcGFzcy10aHJvdWdoKS4NCj4+Pj4+DQo+Pj4+Pj4+IEhvd2V2ZXIgLSBk
b2VzIHRoZSBkcml2ZXIgcmVhbGx5IG5lZWQgdGhpcyBiaWcgYSBjb250aWd1b3VzIGNodW5r
PyBJdA0KPj4+Pj4+PiB3b3VsZCBzZWVtIGZhciBtb3JlIGRlc2lyYWJsZSB0byBtZSB0byBi
cmVhayB0aGF0IHVwIHNvbWUsIGlmIHBvc3NpYmxlLg0KPj4+Pj4+DQo+Pj4+Pj4gU2luY2Ug
dGhpcyB3b3JrcyBvbiBiYXJlIG1ldGFsIEknbSBhZnJhaWQgdGhlIGRyaXZlciBtYWludGFp
bmVyIChtcHQNCj4+Pj4+PiBmdXNpb24gZHJpdmVyKSB3aWxsIGp1c3QgdGVsbCBtZSB0byBm
aXggWGVuLg0KPj4+Pj4NCj4+Pj4+IFdlbGwuIFRoZSBiaWdnZXIgc3VjaCBhbGxvY2F0aW9u
cywgdGhlIGxhcmdlciB0aGUgcmlzayB0aGF0IG9uIHN5c3RlbXMNCj4+Pj4+IHRoYXQgaGF2
ZSBiZWVuIHVwIGZvciBhIHdoaWxlIHN1Y2ggYWxsb2NhdGlvbnMgY2FuJ3QgYmUgZnVsZmls
bGVkIGFueW1vcmUNCj4+Pj4+IGV2ZW4gaW4gdGhlIGJhcmUgbWV0YWwgY2FzZS4NCj4+Pj4N
Cj4+Pj4gWWVzLiBJIGRvbid0IHRoaW5rIHdlIHNob3VsZCBqdXN0IHdvcmsgYXJvdW5kIHRo
aXMgaXNzdWUgd2l0aG91dCBoYXZpbmcNCj4+Pj4gZXZlbiB0cmllZCB0byBnZXQgdGhlIGRy
aXZlciBmaXhlZC4gSW4gY2FzZSB0aGV5IHJlZnVzZSB0byBjaGFuZ2UgaXQsIHdlDQo+Pj4+
IGNhbiBzdGlsbCBpbmNyZWFzZSBNQVhfQ09OVElHX09SREVSLg0KPj4+DQo+Pj4gVGhhbmtz
IGZvciB0aGUgZmVlZGJhY2suIEknbGwgdHJ5IHRvIGhhdmUgYSBsb29rIGF0IHRoZSBkcml2
ZXIgaWYgSSBoYXZlDQo+Pj4gdGltZSB0byBkbyBzby4NCj4+DQo+PiBBbm90aGVyIHRob3Vn
aHQgd291bGQgYmUgdG8gY2hhbmdlIHRoZSBnZW5lcmljIERNQSBhbGxvY2F0aW9uIHRvIG5v
dCByZXF1aXJlDQo+PiBhbGlnbm1lbnQgYmFzZWQgb24gdGhlIHJvdW5kZWQgdXAgc2l6ZSwg
YnV0IG9uIHRoZSBsYXJnZXN0IHBvd2VyLW9mLTIgY2h1bmsNCj4+IGZpdHRpbmcgaW50byB0
aGUgcmVxdWVzdGVkIHNpemUuDQo+Pg0KPj4gSSBkb24ndCBzZWUgd2h5IGEgMi4zIE1CIG1l
bW9yeSBhbGxvY2F0aW9uIHdvdWxkIG5lZWQgdG8gYmUgNCBNQiBhbGlnbmVkLiBJdA0KPj4g
c2hvdWxkIGJlIHBlcmZlY3RseSBmaW5lIHRvIGFsaWduIGl0IHRvIDIgTUIgb25seS4NCj4g
DQo+IFlldCB0aGF0IHdvdWxkbid0IG1ha2UgYSBkaWZmZXJlbmNlIGhlcmUsIHdvdWxkIGl0
PyBXZSdkIHN0aWxsIG5lZWQgYSA0TQ0KPiBjaHVuayBvZiBjb250aWd1b3VzIHNwYWNlLCBq
dXN0IHdpdGggbGVzcyBhbGlnbm1lbnQuDQoNClRoaWVycnkgc3RhdGVkIHRoYXQgdGhlIGRy
aXZlciBmYWlsZWQgdG8gbG9hZCBkdWUgdG8gdGhlIGFkZGVkIGFsaWdubWVudA0KY2hlY2sg
aW50cm9kdWNlZCB3aXRoIGNvbW1pdCA5ZjQwZWM4NGE3OTcuIEkgd2FzIHRhcmdldGluZyB0
aGlzIHJlYXNvbmluZw0Kd2l0aCBteSByZW1hcmsuDQoNCg0KSnVlcmdlbg0K
--------------F0xkLDiSGwSCfzoa0qysJ23k
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

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

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

--------------F0xkLDiSGwSCfzoa0qysJ23k--

--------------nF0PLdcdO0lDs4cED1rJUuCH--

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

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

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmd5gtsFAwAAAAAACgkQsN6d1ii/Ey+x
vAf9EpuElybnNEEe9MbecnRp1rVysKEEOKEdT6yJK0gKIFkGQc8iinyH+wdQmf1hu1ptTgbLOnzh
jGPw3CpYCrtsXFe7e/lkLJ3ayyon2EOfExt/SH/v6jyqI8Fz1N0fip718VQe/qeVyrMjB+Bq3kTI
G1Ot3yeQOYYYQ3kSICfpbSnVfsPWexTaUWdbioIMmBBHOqbLs1NIsvWQV+B4aDoXtD5I7wVS4MwP
d8rp5NFN0oftNuJceYAWQBYugdNj/icH4BTn2CPXag3KmUYSY2YrrXurtxZ9VHzMJZwiYeZmkAnr
KFtQ+FLGxCtt3wk4lz8e6v6dqsXYCNeWmZmG0mTFzg==
=cyGI
-----END PGP SIGNATURE-----

--------------yAX3fS0apYGCcAvBCMjz1MzQ--


From xen-devel-bounces@lists.xenproject.org Mon Jan 06 08:16:01 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 08:16:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865534.1276763 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUiGw-0003j2-90; Mon, 06 Jan 2025 08:15:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865534.1276763; Mon, 06 Jan 2025 08:15:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUiGw-0003iv-5q; Mon, 06 Jan 2025 08:15:38 +0000
Received: by outflank-mailman (input) for mailman id 865534;
 Mon, 06 Jan 2025 08:15:36 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=9khw=T6=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tUiGu-0003io-FQ
 for xen-devel@lists.xen.org; Mon, 06 Jan 2025 08:15:36 +0000
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com
 [2a00:1450:4864:20::430])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 65e5c8b5-cc06-11ef-99a4-01e77a169b0f;
 Mon, 06 Jan 2025 09:15:32 +0100 (CET)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-38a34e8410bso4563653f8f.2
 for <xen-devel@lists.xen.org>; Mon, 06 Jan 2025 00:15:32 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c89e1acsm47369895f8f.68.2025.01.06.00.15.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 06 Jan 2025 00:15:31 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 65e5c8b5-cc06-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736151332; x=1736756132; darn=lists.xen.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=rSYdRm/a7jNFsYtQqLFAh2uV/OUwD/apSXYr7PyQd3I=;
        b=CMru65QhHVdJLd5X7aPeHsde+vUo2Eg8Akom8HqIU/6r7RorDqN+/nfw0DQYl5z1kE
         KG1WxgrjswK2FFnfUrLPANJeCq3UC7zzrI4I60ctrV3CTPlOpL3zNYvIVCyRIMtiZiaz
         yK8POYDUB9qAue+0e/4foztkEtg7zuDipX8iza6ZHPZOagEvBqK77+zslBltm9kxJGa7
         qwAymx8veQFhfvLug3WAZkVIWShYZFNe/Z/Tvu22oQH13Acw751xAH/czhukIfSTOm1A
         z1f+F/ZrJyv9ljMctXJz8VqZaWeAwzZlSqwP3uOgeYyeAIZ42LfWIiAIqlSU1Jzq+AeC
         cJhw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736151332; x=1736756132;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=rSYdRm/a7jNFsYtQqLFAh2uV/OUwD/apSXYr7PyQd3I=;
        b=XstVln+knxOpDesmEwisZpyBNUyWflKK8hG7A0aQH1xjhEtrWzAt+p9zbaasdlcn3n
         ViKTIwF7Rh0sEhfv+pwOxyQDUYpRVuLYsyjCUyX6evt/bVgvYiOqy3aYsrXPieXaJV2w
         ExFXzOrN1Lk2RWMaEXaNYqiAhfJjXyW43e/eLlsskMAiwjjK0Lmn118z3V8A8E957Qxh
         RX7nY4twxdBkAtb50VADqFGj1dRPPBlQsnXvWu9mKPvQXPMm26dBle7SfS3EEl8fucy1
         tvGbsPgvnKgSV+2zeryzfyCAEBEpCSdx/iOTN6sy3sIbllaPOt7U/EAbeHq41OIixBuZ
         6a3Q==
X-Forwarded-Encrypted: i=1; AJvYcCVon6OrJS+CNjFKWecDszyA/bBSjB7s4nqcEVlZDrUjQaJuWJqivyBY/kL9d7h2NEazFF5pTrMy2m0=@lists.xen.org
X-Gm-Message-State: AOJu0YyorVJxDrpC1KO+nudZ7oRmSVy0V5HsQ7mL2GahUkOcryj23hxR
	NWvGICtMc4Atc6seuyBdOiPDlYWu2IUva681uw5F3eY3o6h3pA3mfYTjdd913Q==
X-Gm-Gg: ASbGncsvhjnuXXlFqH11Tjw2i02eh2IP9OBuaHyENCqT2UrwngWdH370V5AsDPdQNWC
	0xWmUq/YdjMnZElq97rlvcFjwxSkOep7to+C/K48OHrXcuesScMf8gzpcAL+oya57yffw+ANdlB
	xWAxRQFY+feEakFy52Ciim5g4EjjquCCzaCTIum2uaDhsat6U/+GYhJ8tk/OriRfmrkSq5/t5vt
	u4ch4pEs2c/lz3ewOkyvjSGXE3qGQ1cwPZLYOHd8I051tDBQBH+wEGeqC6KlA9iPziObwcIiOar
	1rK2KyX6bXvXkWV7V2PQbYk08UlLBqq56hOuLWHMRA==
X-Google-Smtp-Source: AGHT+IH2becdfDFGpDsUA06tng4ArRB6Mr9/OA4UN3771rx3JmTQbijQYW8zStIhyyUy9cj9odCb1w==
X-Received: by 2002:a05:6000:3cd:b0:386:1cd3:8a03 with SMTP id ffacd0b85a97d-38a222009camr41124699f8f.32.1736151331769;
        Mon, 06 Jan 2025 00:15:31 -0800 (PST)
Message-ID: <2f33b1fc-e527-4e42-b197-058b1a9f7870@suse.com>
Date: Mon, 6 Jan 2025 09:15:38 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Xen Security Advisory 466 v3 (CVE-2024-53241) - Xen hypercall
 page unsafe against speculative attacks
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Cc: David Woodhouse <dwmw2@infradead.org>, xen-devel@lists.xen.org
References: <E1tNWXG-00E268-2p@xenbits.xenproject.org>
 <54c892eded2b4ebdda8ee1085c383178f44414ad.camel@infradead.org>
 <a3031e7d-fe9d-4db8-8ccd-923165c9af72@suse.com>
 <fc4c45ea86567ef0c46d7e5a20e8abffa75cc4ec.camel@infradead.org>
 <fd993f8d-280f-439a-a6a0-506e2815f281@suse.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <fd993f8d-280f-439a-a6a0-506e2815f281@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 02.01.2025 14:38, Jürgen Groß wrote:
> On 02.01.25 13:53, David Woodhouse wrote:
>> On Thu, 2025-01-02 at 13:07 +0100, Jürgen Groß wrote:
>>> On 23.12.24 15:24, David Woodhouse wrote:
>>>> On Tue, 2024-12-17 at 12:18 +0000, Xen.org security team wrote:
>>>>>                Xen Security Advisory CVE-2024-53241 / XSA-466
>>>>>                                   version 3
>>>>>
>>>>>            Xen hypercall page unsafe against speculative attacks
>>>>>
>>>>> UPDATES IN VERSION 3
>>>>> ====================
>>>>>
>>>>> Update of patch 5, public release.
>>>>
>>>> Can't we even use the hypercall page early in boot? Surely we have to
>>>> know whether we're running on an Intel or AMD CPU before we get to the
>>>> point where we can enable any of the new control-flow integrity
>>>> support? Do we need to jump through those hoops do do that early
>>>> detection and setup?
>>>
>>> The downside of this approach would be to have another variant to do
>>> hypercalls. So you'd have to replace the variant being able to use AMD
>>> or INTEL specific instructions with a function doing the hypercall via
>>> the hypercall page.
>>
>> You'd probably start with the hypercall function just jumping directly
>> into the temporary hypercall page during early boot, and then you'd
>> update them to use the natively prepared vmcall/vmmcall version later.
>>
>> All the complexity of patching and CPU detection in early boot seems to
>> be somewhat gratuitous and even counter-productive given the change it
>> introduces to 64-bit latching.
>>
>> And even if the 64-bit latch does happen when HVM_PARAM_CALLBACK_IRQ is
>> set, isn't that potentially a lot later in boot? Xen will be treating
>> this guest as 32-bit until then, so won't all the vcpu_info and
>> runstate structures be wrong even as the secondary CPUs are already up
>> and running?
> 
> What I don't get is why this latching isn't done when the shared info
> page is mapped into the guest via the XENMAPSPACE_shared_info hypercall
> or maybe additionally when VCPUOP_register_runstate_memory_area is being
> used by the guest.

The respective commit (6c13b7b80f02) lacking details, my guess is that
because at that point both operations you mention didn't have HVM-specific
logic (yet), the first HVM-specific operation used by the PV ("unmodified")
drivers was selected. pv-ops (having a different init sequence) appeared
only later, and was then (seemingly) sufficiently covered by the latching
done when the hypercall page was initialized (which was added a few months
after said commit).

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 06 08:48:00 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 08:48:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865543.1276774 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUim8-0007Wn-MR; Mon, 06 Jan 2025 08:47:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865543.1276774; Mon, 06 Jan 2025 08:47:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUim8-0007Wg-Ie; Mon, 06 Jan 2025 08:47:52 +0000
Received: by outflank-mailman (input) for mailman id 865543;
 Mon, 06 Jan 2025 08:47:50 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=9khw=T6=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tUim6-0007Wa-KZ
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 08:47:50 +0000
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com
 [2a00:1450:4864:20::434])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e7d85adf-cc0a-11ef-99a4-01e77a169b0f;
 Mon, 06 Jan 2025 09:47:48 +0100 (CET)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-385dece873cso5170280f8f.0
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 00:47:48 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c89e126sm46590530f8f.65.2025.01.06.00.47.46
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 06 Jan 2025 00:47:47 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e7d85adf-cc0a-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736153268; x=1736758068; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=LUGroKBaUx3fvIycUYkuYkxWRhR2kZInh1iJCXyuhpI=;
        b=cku2H+yZZ/uCsVO6iyyGGu2K8GC9cvfMRtweD777Mv3bQWC/PMgqnAYC8HVdYZblwE
         hvDSSrbZyJOOyUMGITRLdTzMKtqqlfJSLh7sd7AQOiBB7+HXDulmUf6Dy49jYxvAXi7C
         JB9bD+WFmjTMvF5HRaPga24Zs7BAHCj05KpWO/kHAfB4PqXNnXP8KZ8UxoSFfgf2CfLK
         ZXpWpEQzP4D4HtGjlf5bkXH4kSi1r/coFII6SbRiL5PIWOjP1JyHU3w7JQp+7yxHZlwF
         wOIOABVGhpOScNeqNuIlxL5A/I0Ma6As1Qx5gzkXQLtcAhm+w5m37VjEoW1A3QVjZwWt
         mAog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736153268; x=1736758068;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=LUGroKBaUx3fvIycUYkuYkxWRhR2kZInh1iJCXyuhpI=;
        b=ASaHkjZcRzSi2w3xn/lV1WpfjRWy5M7iPbh02Gv5HuhVCGiEIxOGQbrX/KPYwJJqlf
         2WkxxTTM5kUtiCIkFkTrEHkIkx9AdJGekODkfmwA4xTRf138wffurEx9qU2PmihJme9C
         f/yq5247zgB3fRQtMMzaG1Q0dxsRf4xNqz50SQX+ZHYjgQ4KGaLNDCOoKlIcD7wZ3CvN
         VJYetEORKxLPbSENhxCG/Wasb4Q8O5TA27pQllQTBCKvo0NlowWYOKv4ooE0orJdeOOL
         KjsOXWVxjED0YR7yMeLWqTIb1MWp3e3s/4WOZRhrWqSTGZlWQJ8QdC1IEvQmwMt0wQDN
         OK0A==
X-Forwarded-Encrypted: i=1; AJvYcCXL+T7272D7xs+dmxeMm8UGsOZP0mVY+tmN0+NvyMQes4aBVyjhprndiv//nC6eNzzMrB/bj76ev0A=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxd+Q8jaBvK9Xb8OXOiUJr2RYONvvjKCHGn3+pbgaWCS3YSPSii
	qWLfeheFQKCwS1w8a8T/4TD378zc4e3EEv+rUQmn4rWwdKzPQys/uags7YVuqg==
X-Gm-Gg: ASbGncuXBKkAxJrAU1fxgwU3NCo6XP1gXfYAE+SDJ6LyUKF55/GUw5qplMik/ugO7H8
	qdqs6e156qnmzyihiZQ/eSXb17gqgyiF3TgOeD25x8oNNrfS8wVZE1c8GuJFz7Swwkt9jD+Yt+x
	VNX0zwTjMexZKjzWN/In0WTZ3uXvHGdm4GFRZmYripo+sBWPUUOUezv0CH32pWmukOP8CxoItvg
	0CFz7MAyoUvU17bTOuzBaiII5zGsQX6pCO+jMTqfVDNuJLI+1SXbbH5l007qllfRPAlzjSJp6CP
	1PCwKcb0BY++yUgxi//f+10nHoQPMTt/LX57jZoeMQ==
X-Google-Smtp-Source: AGHT+IGKGRBfsPyXyVmDmchBix5jmtQnAiG4xE0y+lEW61nfYMWevzWLr0j4N8YtsOkP1ZSL29a95Q==
X-Received: by 2002:a05:6000:70a:b0:385:e0d6:fb48 with SMTP id ffacd0b85a97d-38a221f109amr48478778f8f.7.1736153267885;
        Mon, 06 Jan 2025 00:47:47 -0800 (PST)
Message-ID: <324509b4-a38e-4c83-9774-d7f560192c6d@suse.com>
Date: Mon, 6 Jan 2025 09:47:54 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v2] xen: introduce kconfig options to disable
 hypercalls
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: Sergiy Kibrik <Sergiy_Kibrik@epam.com>,
 Stefano Stabellini <stefano.stabellini@amd.com>,
 Julien Grall <julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xenproject.org
References: <20241219092917.3006174-1-Sergiy_Kibrik@epam.com>
 <735f8d30-5f42-4fa6-acb0-f82b5b759183@suse.com>
 <alpine.DEB.2.22.394.2501021033440.16425@ubuntu-linux-20-04-desktop>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <alpine.DEB.2.22.394.2501021033440.16425@ubuntu-linux-20-04-desktop>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 02.01.2025 19:33, Stefano Stabellini wrote:
> On Fri, 27 Dec 2024, Jan Beulich wrote:
>> On 19.12.2024 10:29, Sergiy Kibrik wrote:
>>> --- a/xen/common/Kconfig
>>> +++ b/xen/common/Kconfig
>>> @@ -516,4 +516,33 @@ config TRACEBUFFER
>>>  	  to be collected at run time for debugging or performance analysis.
>>>  	  Memory and execution overhead when not active is minimal.
>>>  
>>> +menu "Supported hypercall interfaces"
>>> +	visible if DOM0LESS_BOOT && EXPERT
>>> +
>>> +config SYSCTL
>>> +	bool "Enable sysctl hypercall"
>>> +	depends on !PV_SHIM_EXCLUSIVE
>>> +	default y
>>> +
>>> +config DOMCTL
>>> +	bool "Enable domctl hypercalls"
>>> +	depends on !PV_SHIM_EXCLUSIVE
>>> +	default y
>>> +
>>> +config HVM_OP
>>> +	bool "Enable HVM hypercalls"
>>> +	depends on HVM
>>> +	default y
>>> +
>>> +config PLATFORM_OP
>>> +	bool "Enable platform hypercalls"
>>> +	depends on !PV_SHIM_EXCLUSIVE
>>> +	default y
>>
>> Just to re-iterate an earlier comment: Andrew (imo validly) raised concern of
>> such negative dependencies. As said before, imo we'd better resolve that before
>> extending the issue (whether by the patch I once sent or something else is then
>> secondary).
> 
> How would you express the !PV_SHIM_EXCLUSIVE dependency without using
> negative dependencies?

By inverting the sense of the option (and renaming it), as (to a 1st approximation)
requested by Andrew long ago, and as proposed in [1], which I think I pointed
Sergiy at, and which continues to be lacking feedback.

Jan

[1] https://lists.xen.org/archives/html/xen-devel/2023-03/msg00040.html


From xen-devel-bounces@lists.xenproject.org Mon Jan 06 08:55:26 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 08:55:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865551.1276783 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUitO-0000il-C2; Mon, 06 Jan 2025 08:55:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865551.1276783; Mon, 06 Jan 2025 08:55:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUitO-0000ie-9T; Mon, 06 Jan 2025 08:55:22 +0000
Received: by outflank-mailman (input) for mailman id 865551;
 Mon, 06 Jan 2025 08:55:20 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=9khw=T6=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tUitM-0000iY-6I
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 08:55:20 +0000
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com
 [2a00:1450:4864:20::335])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f46f6352-cc0b-11ef-a0df-8be0dac302b0;
 Mon, 06 Jan 2025 09:55:19 +0100 (CET)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-436326dcb1cso93515915e9.0
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 00:55:19 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-43656af6cbbsm595118285e9.3.2025.01.06.00.55.18
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 06 Jan 2025 00:55:18 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f46f6352-cc0b-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736153718; x=1736758518; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=HNHP5KHMf27LdU0KeBedMufdxZs5vEsqAMcYSe5Zu0E=;
        b=fBCbKvnOYnm310kNskQOte0M5oAeHTl5DGXkNRnG3bAaAAHOtZfDzShoUjC65FmLBg
         1HwoVGCt+KaVZkXaBhwKhFbzD2rT+4BWDDbOWnGAt4XL2VTHedGc+cbYhKR3XIvPKcPE
         Opj1lNd4ZGfBnnry2HdP5Rz5dQTkrw1ooWmJf58NJ+4UZDkE5bGTY12nxPmT2eoD9CXK
         cHkK7P14J4t4c91TfMf7WQbM2HcLId67LxlJ7s76aWq3sU5J0TH/to3LQWQOMNjFP7Rn
         p9Mml58fiyq0TwQ2O+hZcKZiBVJIy3rWavvs0EtLFfFN2yUAJ1SxYgxb93bF9cG3AZ8M
         TV9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736153718; x=1736758518;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=HNHP5KHMf27LdU0KeBedMufdxZs5vEsqAMcYSe5Zu0E=;
        b=ssCswrRPkjr5D0uKqb1hlUNWwVEwrGXLvJmVVr96JbPjI3dNJZirodfULPzW1bHJB5
         RVqFAZnpWjk5UJVfKjRnCRXmegkTEQqmkEJme6ahIP2XUWFi2BrwfhRNeE/ddE1Z14sS
         xG/uOZWWBBQm3xdR9tZb1+S2DtyS8ssXW0VbBFzcUn/InJ8MUQWD4JEES6A3mi51wfsr
         1l+lCmjbj3Ik7ptJPXTR/899mKmkY4Ma+nXzQF+gKcX2FYoaHAAfBOU2Wse0qVuN8vJl
         ZluIT3IWPIDVrlPVUg8bkx6ICnP0LQ/3TV2O2qZGWG57TE1XFsbu8vHFTpakVtwcyGne
         2pTw==
X-Forwarded-Encrypted: i=1; AJvYcCUGghtBs6j4bKPWAntJ616gI7UKGZPlFohbtH2OzwuPjlQHYeOZoHGcRHQwNcVDBnQfMA5SH1ob7Os=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwW4ereGMCWB/KifNvcW993HJbaBQBqAWktV6nRcfCL7GUnIFEW
	JR1ZBDuYIVtUuihDi7hdvqywh1UgcFmWaU7kpB78TfkfVktNwdWwp7nKd81+6Q==
X-Gm-Gg: ASbGnct5jvfLXeSdudtxlw9Sh6HoOdN6TB3LZlmCW9aFLOm9AdXdX2WCxrsbg4yO6FK
	Yv5Jt0U/lT4CzvVIEsI3dVEs24hqbVYAX+qOOKMz25obg/hg8QjFM70oQkKgI2mpT9bhSRBz3QU
	9Gb7y9PFn1cSf6oal2YvByx4MUevudpoooYywQjfoJ7HZjGeyuPTcFkQX/jkycxixU08vD8LMxg
	aJMveswYbs5iM2Mgha1/ryOZhAcJqMEdf1P6uBi11QXP4fnFJjvenWURkR76QFhGAY4s34NYTVv
	QJITtlPKPDrnjP37l6380ldU5OJc9eff+iqHUIvbyQ==
X-Google-Smtp-Source: AGHT+IFoeHyuk4EieHn3bvrcLDmDb2PF2X7gBEvCSrQ3jQjUQUhC1e952KbdU8pVSUUwIFpHsFwp0w==
X-Received: by 2002:a05:600c:3ca4:b0:434:fe4b:be18 with SMTP id 5b1f17b1804b1-436686468fcmr521538215e9.18.1736153718543;
        Mon, 06 Jan 2025 00:55:18 -0800 (PST)
Message-ID: <180fb50d-37c8-439e-9fc2-883e75895a8f@suse.com>
Date: Mon, 6 Jan 2025 09:55:25 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 03/35] xen/ctype: introduce isconsole()
To: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, Andrew Cooper <andrew.cooper3@citrix.com>,
 Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>,
 xen-devel@lists.xenproject.org
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-3-e9aa923127eb@ford.com>
 <b3afb61f-0a82-4a66-ae9c-42c1106a5399@suse.com>
 <UxuSYzSmEVywRqZ_UFKaoIq1qJIu3HJsDIFnih7hfMmjZ7m935H9ODPtxpe4NxWRFKBsiQL_j42X6U_1LdeSoI2Eflge05xsI5YUClj0HFc=@proton.me>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <UxuSYzSmEVywRqZ_UFKaoIq1qJIu3HJsDIFnih7hfMmjZ7m935H9ODPtxpe4NxWRFKBsiQL_j42X6U_1LdeSoI2Eflge05xsI5YUClj0HFc=@proton.me>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04.01.2025 03:31, Denis Mukhin wrote:
> On Tuesday, December 10th, 2024 at 5:22 AM, Jan Beulich <jbeulich@suse.com> wrote:
>> On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
>>> --- a/xen/include/xen/ctype.h
>>> +++ b/xen/include/xen/ctype.h
>>> @@ -4,6 +4,8 @@
>>> /*
>>> * NOTE! This ctype does not handle EOF like the standard C
>>> * library is required to.
>>> + *
>>> + * See Rule 21.13 in docs/misra/rules.rst.
>>> */
>>
>>
>> How's this change related to the purpose of the patch?
> 
> Only because the very first version of the macro was failing
> an ECLAIR job for me because of Rule 21.13 violation.
> 
> Updated the commit message (v3).

Well, no, in such an event please drop this comment change. Or else we end
up with Misra related comments about everywhere. After all _all_ Misra
rules need to be follow everywhere anyway.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 06 09:04:03 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 09:04:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865558.1276793 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUj1h-0002TF-6I; Mon, 06 Jan 2025 09:03:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865558.1276793; Mon, 06 Jan 2025 09:03:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUj1h-0002T8-3l; Mon, 06 Jan 2025 09:03:57 +0000
Received: by outflank-mailman (input) for mailman id 865558;
 Mon, 06 Jan 2025 09:03:56 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=9khw=T6=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tUj1g-0002T1-5R
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 09:03:56 +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 27ffda73-cc0d-11ef-a0df-8be0dac302b0;
 Mon, 06 Jan 2025 10:03:55 +0100 (CET)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-385df53e559so11115446f8f.3
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 01:03: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
 ffacd0b85a97d-38a1c8330d4sm46833903f8f.29.2025.01.06.01.03.53
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 06 Jan 2025 01:03:54 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 27ffda73-cc0d-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736154234; x=1736759034; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=0l7vRPBfuuguFIUIDZW5bUWbIXANs8SJ8zLqvL4irD8=;
        b=ZVnIHANhyYNTqHQIGKRS9lDwEmm05Eer8yV3RoV6BW5fPCroOWzl6EsgrHlmQSe7fr
         IqYVQO+AQpH4dE5wdZ5aHMf4hX3oz/Ok4NCmJuzMb0oiNeVTBLTyE/KcyCAdDxt4KBRg
         ig8iv9JUnHRmOF+w0sgcnteJxS8ZngzWBccON6rI3tF9rI1f5NVEWUclfoTVD5J5klYn
         ib6HqAVDURQcUNSNj1MqMpssb0Sun1SyNijp5H6xXLT0UfGHNm1H84WCQdCJrUsULz+x
         lcAnOvao1jcBIf0zyr2NJORygZX10/OPPztEMby42mXfBpLQwx5+UwwStcn5JnN65bYu
         +wwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736154234; x=1736759034;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=0l7vRPBfuuguFIUIDZW5bUWbIXANs8SJ8zLqvL4irD8=;
        b=onADGGWqogElNMch68XFjOMAImhY13Gw2kLvtmSoZd+c/RDA9dtTP6+u2JfVHliJbI
         jfCLYAoP/2zSulsmz8hI5CXBgCG8xQADmwgu5VtWJmr5MRAwPrr9IsVzUYjD6/YX376C
         22AsMQvVLleFTAQs+4KeGcvD7BNtCHLNZHUIIAQaDid4+knzWGgFajjVogy52qJZo36J
         tGEdWXzX4QM6z39Zb1ugWnP04W5JoxGqQgPHSSjC82IhgoFQYkJYsJ5U0Rvh6tiqvFLt
         yNuqwusCytT3KTvVfJ1oKS2Lgcc3xRInNgl0uZnjwqLm3pTmcNCNZYu6a+TDodqhwFuv
         3EfA==
X-Forwarded-Encrypted: i=1; AJvYcCVtUOSMbS08nZuwkZlhI1Zz8j0ILTc3ixqZP3vaR0oTS5GqnwudluIFcRMw6VzJYNxM5pfQn7/Mhc8=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw8s85VPa8lOnZhhIGvzC+xMdFA1yyIUfEt8YGFvamqLoNcja45
	ziqR67tP9OQbL5zfp5lVr7zuS0KiHktFERGRZcEN33sjC9vVTPDnApq3Yza2Gw==
X-Gm-Gg: ASbGncukIMTRDmuowWiWKjwNoui6WcXYtWeHKPtQa3pPeHGui5SCbBPMI7/u5G2JNPl
	UT1wuYn5dOlqT7mVGd9kyPqAiFGvmwIMhae/L0ALxQ6BrfslpwvyFBAZbfG7AWNRiLn3xr5wD2g
	u/TVfboE09PUhsE37uJRjkE7oVnGWroJmiyjnaAhpQjG+8b7YLwDWngS+okHwqqZFlPUJwuJ5qn
	YfGaLIQY4ew5QTzYPVtWQk5BnlyyNOO7A+1DOK6cW+QgNKRYqtF3K0+EaBqA+njQvzRs7ZTVAyN
	4/4M1mqgB1wkqg/xEg0/jxidemIX3Et20WOXqHJLpA==
X-Google-Smtp-Source: AGHT+IFBBRYXv6HlVP8XxQEH/siKXNMJDfILmPd20jLAFltvKjg3gcMSdTIKeJARbKpRJHNa+c45Gw==
X-Received: by 2002:a5d:5f83:0:b0:385:ec6e:e87a with SMTP id ffacd0b85a97d-38a223ffaf7mr42931000f8f.43.1736154234559;
        Mon, 06 Jan 2025 01:03:54 -0800 (PST)
Message-ID: <5335a9be-4fdd-4b9a-a941-5ab8d3c0829e@suse.com>
Date: Mon, 6 Jan 2025 10:04:01 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 16/35] xen/console: introduce printk_common()
To: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, Andrew Cooper <andrew.cooper3@citrix.com>,
 Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>,
 xen-devel@lists.xenproject.org
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-16-e9aa923127eb@ford.com>
 <9c9120f6-6291-43d1-93ac-deebdc222f3e@suse.com>
 <hYzpsKcLLQl-hDLJQHJZSrZtcT5PVx6qx3aKoTyDtH-EYxMtYA9XKavqTvfukRQshSpt9ffdH0MyiqSdglLWtNTSPGduWBOnUbb4DLfityc=@proton.me>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <hYzpsKcLLQl-hDLJQHJZSrZtcT5PVx6qx3aKoTyDtH-EYxMtYA9XKavqTvfukRQshSpt9ffdH0MyiqSdglLWtNTSPGduWBOnUbb4DLfityc=@proton.me>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04.01.2025 03:57, Denis Mukhin wrote:
> On Tuesday, December 10th, 2024 at 6:27 AM, Jan Beulich <jbeulich@suse.com> wrote:
>> On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
>>
>>> Introduce new printk() variant for convenient printouts which skip '(XEN)'
>>> prefix on xen console. This is needed for the case when physical console is
>>> owned by a domain w/ in-hypervisor UART emulation enabled.
>>
>>
>> Imo it should still be guest_printk() which is then used from there.
> 
> I ended up w/ printk_noprefix(): vprintk_common() expects user-defined prefix,
> while original printk_common() does not expect prefix. Such inconsistency
> may be confusing because both functions are named xxx_common().

Your reply at best partly addresses my comment: I didn't suggest a new name for
the new function, but I rather suggested that you use an existing one instead.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 06 09:05:00 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 09:05:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865567.1276803 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUj2i-000333-IV; Mon, 06 Jan 2025 09:05:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865567.1276803; Mon, 06 Jan 2025 09:05:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUj2i-00032w-Fk; Mon, 06 Jan 2025 09:05:00 +0000
Received: by outflank-mailman (input) for mailman id 865567;
 Mon, 06 Jan 2025 09:04: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 <SRS0=9khw=T6=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tUj2g-00031p-UA
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 09:04:58 +0000
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com
 [2a00:1450:4864:20::32a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4dbc2e1e-cc0d-11ef-a0df-8be0dac302b0;
 Mon, 06 Jan 2025 10:04:58 +0100 (CET)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-43624b2d453so146013385e9.2
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 01:04:58 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-43656b3b214sm602532695e9.28.2025.01.06.01.04.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 06 Jan 2025 01:04:57 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 4dbc2e1e-cc0d-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736154298; x=1736759098; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=xKdz5ZfmiRbMkL0bHona89NxxSVkAQIEzmDNyelosa8=;
        b=W7dB3BBZQUgZD35FenAZFQqMrb0QGe39zN4SlpYvcw5tLbW4tiPz2DOhLlCQNjRlfu
         Vti7zaWGPWb1MxnzOUzMXxK9iHgfFyZ5htmvrL5sflYKntwc0M3gBTSQx0CBDzghDuzo
         bntK+afZLGT99QNrzyAcife77zJ8DQCLi6TuwWs1LjNQm6ZP1ir90NRjD21WpYpIuK89
         PyY/L7sBLThNmmpb1yFF91xyr59MOA9D8xbgn6WBnyHcIVgirXHBn+HMsRCLDAj9mCEs
         pI6ZogimMNZ9eZqwpnZ1CmB6nFIhhWw37WlCgrkGheknG6/RoJwC/acya0p1dafEj5xr
         w1FA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736154298; x=1736759098;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=xKdz5ZfmiRbMkL0bHona89NxxSVkAQIEzmDNyelosa8=;
        b=elfdsc2WGadqO9MZr9gEvbu0gdWCeJUsrHppoeqvt0pXLLn0UoRcaX374tQTcb/+vk
         cNywFF3Zec2MPDiVTIRjXi2Z+R1uWWG67cZqvb42R0bfHPIIsd74JXNGWsjOAinrE8sp
         XWF65SaWIOvMAMlYjhP1McylyHKLaYrRNuQovuYUnDuirSfm9qxs54JgGlwD0ZUa5HVo
         U7lSmvRY6uHrWWotGT8I05zWWJxqvEzQHNtWjPWjKvGluazgaugq0BWZpCD4ZUqJNppq
         uaAV48x+SLNwYUsJTgAw2wkXC8A8tAHZ7wvkTBfFR1y20NqcAVwj13WVAmKg1xeCFRcp
         B2KQ==
X-Forwarded-Encrypted: i=1; AJvYcCVdbE4+kmlKASCvOn3AhEp4n0OfUPOchh/wRT0q/0njnNPIgtEwef/pqufG+PaJkILLzTeCm3YBKl4=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxwf4YLEBgbSNM7SNjPnMFJMb4z0SX4FDXJBc5Wx0cpv35kaw3F
	uS2MTd9g3W0roUC4s89N1lNasZ3bJxyhaOiPDK2zZbanw6Hg1EYqTUtv04xZaQ==
X-Gm-Gg: ASbGncvEaLsnQzNOiiCTPP3Rko1JojxXhS/9Qbc4Ws82OQPJqZpfS8tAjZHwxote0nU
	WySvd6U9bZPDU37Wi3On37Sq8d7iJB1IaS9iVW/8EnrcvIyHX5ZHVCaJraPbOH09YQd7U0j3xJf
	sUf0Ts3N7BnYtrbw9dSw2IegS7a0l8cnD7MpMEuPDLsJKbUShgOvVuhqS32Rf+XKZa2FvgiW4qY
	oPPLHlXhWoOmlKBfh9oVc0O0YpzOmhoQ65hXUslUa6quwKUUZZl3jvHff0xqxHpNEe5xeHSIKEK
	d8tHN3bHoPHauHpa16gtTUyezxAfLAH2yjFj1hJm0g==
X-Google-Smtp-Source: AGHT+IGzOlRD+xy41OVyHw/+lix+/OkWZVTntIKcBq44C2zyFJD52W57hsDVmvgTwVspEVp9lLV8pg==
X-Received: by 2002:a05:600c:3b86:b0:434:f0df:9fd with SMTP id 5b1f17b1804b1-4366835c187mr451917285e9.2.1736154297780;
        Mon, 06 Jan 2025 01:04:57 -0800 (PST)
Message-ID: <be09172b-5351-4ac0-af6a-1c78318c1bb3@suse.com>
Date: Mon, 6 Jan 2025 10:05:05 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 17/35] xen/console: introduce consoled_is_enabled()
To: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, Andrew Cooper <andrew.cooper3@citrix.com>,
 Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>,
 xen-devel@lists.xenproject.org
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-17-e9aa923127eb@ford.com>
 <1968c658-595d-4d36-8558-8f178f8ed531@suse.com>
 <dbgW8XOq7JPdwZfOVtTFNzR4sEKb8gtxLEa1gygWzrm3gtGw28Rh4rxtwROJZ63-oMBOdfrzck3uET7uXNAjd3DW_NNRcgU_WbsCaFTmC0g=@proton.me>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <dbgW8XOq7JPdwZfOVtTFNzR4sEKb8gtxLEa1gygWzrm3gtGw28Rh4rxtwROJZ63-oMBOdfrzck3uET7uXNAjd3DW_NNRcgU_WbsCaFTmC0g=@proton.me>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04.01.2025 04:00, Denis Mukhin wrote:
> On Tuesday, December 10th, 2024 at 6:31 AM, Jan Beulich <jbeulich@suse.com> wrote:
> 
>>
>>
>> On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
>>
>>> --- a/xen/drivers/char/consoled.c
>>> +++ b/xen/drivers/char/consoled.c
>>> @@ -43,13 +43,13 @@ struct xencons_interface *consoled_get_ring_addr(void)
>>> static char buf[BUF_SZ + 1];
>>>
>>> /* Receives characters from a domain's PV console */
>>> -void consoled_guest_rx(void)
>>> +int consoled_guest_rx(void)
>>> {
>>> size_t idx = 0;
>>> XENCONS_RING_IDX cons, prod;
>>>
>>> if ( !cons_ring )
>>> - return;
>>> + return 0;
>>>
>>> spin_lock(&rx_lock);
>>>
>>> @@ -91,15 +91,17 @@ void consoled_guest_rx(void)
>>>
>>> out:
>>> spin_unlock(&rx_lock);
>>> +
>>> + return 0;
>>> }
>>>
>>> /* Sends a character into a domain's PV console */
>>> -void consoled_guest_tx(char c)
>>> +int consoled_guest_tx(char c)
>>> {
>>> XENCONS_RING_IDX cons, prod;
>>>
>>> if ( !cons_ring )
>>> - return;
>>> + return 0;
>>>
>>> cons = ACCESS_ONCE(cons_ring->in_cons);
>>> prod = cons_ring->in_prod;
>>> @@ -118,6 +120,7 @@ void consoled_guest_tx(char c)
>>>
>>> cons_ring->in[MASK_XENCONS_IDX(prod++, cons_ring->in)] = c;
>>>
>>> +
>>> /* Write to the ring before updating the pointer */
>>
>>
>> No excess blank lines please.
> 
> Fixed.
> 
>>
>>> @@ -125,6 +128,13 @@ void consoled_guest_tx(char c)
>>> notify:
>>> /* Always notify the guest: prevents receive path from getting stuck. */
>>> pv_shim_inject_evtchn(pv_console_evtchn());
>>> +
>>> + return 0;
>>> +}
>>
>>
>> For both of the functions - what use is it to make the functions return
>> a value, when all they'd ever return is zero (and callers don't care)?
> 
> Fixed.
> 
>> I'm also having a hard time seeing how this adjustment is related to ...
>>
>>> +bool consoled_is_enabled(void)
>>> +{
>>> + return pv_shim && pv_console;
>>> }
>>
>>
>> ... the introduction of this function (which by itself is probably fine).
> 
> That will be a cleanup in console driver on the code path I touched wrt console
> focus switch.

Yet then please don't mix entirely independent things in a single patch.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 06 09:08:01 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 09:08:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865575.1276813 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUj5b-0003cP-WE; Mon, 06 Jan 2025 09:08:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865575.1276813; Mon, 06 Jan 2025 09:07:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUj5b-0003cI-T8; Mon, 06 Jan 2025 09:07:59 +0000
Received: by outflank-mailman (input) for mailman id 865575;
 Mon, 06 Jan 2025 09:07:58 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=9khw=T6=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tUj5a-0003bw-CR
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 09:07:58 +0000
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com
 [2a00:1450:4864:20::431])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b85ff077-cc0d-11ef-a0df-8be0dac302b0;
 Mon, 06 Jan 2025 10:07:57 +0100 (CET)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-38637614567so6377969f8f.3
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 01:07: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
 ffacd0b85a97d-38a28f17315sm41944822f8f.108.2025.01.06.01.07.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 06 Jan 2025 01:07:56 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b85ff077-cc0d-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736154477; x=1736759277; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=USpGyjrA+JrNjT+NfIaQhGg7WBh5lnUT4kfannP2Jhw=;
        b=czLSgaN28zXl1+d5O8JHiKvqJQdXeHJMdh/zRa9ARp15fTml7ElTBR9x2NMfhEXyWO
         QSw1KpeTAagD+qN7iuFti9Vl+iOeNiVN01Rrm5PrDCoqjx1AO1n7KrToNs1GpTgHukBi
         rE+O4885ej90S7pUK71kT2yYBz0UQszhIwnF4YhSv1Yxm/ocb3oqjESUN6fzavC6L625
         NBGmVm9UfV8GTMhmCfdhG5mURr7E+nyXQuaObCxhxzb9cbmkcBFqnz61mWDSb/xIMS5i
         2Six/DpJU2egRkhaivbvuEuIgvRSMPikzZ3uVhwqpKJTFX3NpmeXd2qEkvaugVSbOljj
         k2Gg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736154477; x=1736759277;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=USpGyjrA+JrNjT+NfIaQhGg7WBh5lnUT4kfannP2Jhw=;
        b=xBEytRfM2dDyx6Ij8ZfBn3d9KZTKGqPygMRVnZzV4mB70OxcfZTBQ4/LvkmAAxFLUJ
         0+jrhm+c+PD5qy3Lq69bVmO8vGsrdCWRvAo8dQt2PyGdrFaRLyzHJDUziQnqgt/OmZTp
         prhh0foqHAmNbKz6VqIJQ0wbNTanjE0Wo6PzcD1qzbc+9IV3ZUzg1eJP+BMQnBSWy2I2
         3vgVNPoCZRJuDLTNE4sLrKWIVLLzuhtVxyJy4DqXfZiaE8Z3LaA/XyoqUVig00UoLDqW
         zxRLuFHfp5Aeo1Gl6XNfV3rBO4yEfKMbWEC7bSTKtffkci97y/FgOkJ2AOl8AtbAnNN+
         G8Xg==
X-Forwarded-Encrypted: i=1; AJvYcCWoEwbht8pr7SPPQoPDotaiZsXI09hGtRAx6TqfL8rAQKKQYpVNXXfK6WyojrV4cx2htYueO4y14UY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzgX0XjEIYTkraJO/yJnvxLJtUaDUPv+g9jfR7TtvpplLKHUVjJ
	mt0TG47+RQ3Lx84Q+fJ2ATzB3YQ/trwzJZl5oy/sIe1dl5LTyTRNSNVxEPsNTA==
X-Gm-Gg: ASbGnct3sSI6fbIEsfwYac/bcBcDyc0BLM1lzAgfHAgfaNj7Yjw5x1qdLzAuKRyKeQv
	gWS32RSlqGdMzv27dQPYnAdlPu/VnDB4FqxHKg9es9PR4Ri3rkH/046gLiCQDGRLJ/Mm9nI/OCP
	JGXSbeRMiB3vqeKAfhuGf3D1+tz3JdN+5hESh9zV0ix6+N4XzjeMyFcLiysNqJ/8v5xZGeQPgpE
	/pirPlvrFPZuZulU67Z07V5UgKB9FTlimJ66FZySmck7GWKjbWqNglLbAWNqTxzj00E/teEskJx
	5usPHmKlaujGM/AxvRhuqOkzmN7V0aGpQsiDa+InFA==
X-Google-Smtp-Source: AGHT+IFO88iORJObK8PzgZyJivBj38Z36lAxRvVm1XyweSU86HhFkFeU1UHHr5Uc3kLMWUM1SNcS6g==
X-Received: by 2002:a5d:64c9:0:b0:385:f17b:de54 with SMTP id ffacd0b85a97d-38a221f11f9mr53624643f8f.5.1736154476767;
        Mon, 06 Jan 2025 01:07:56 -0800 (PST)
Message-ID: <bb1ea738-8abe-42a2-a959-504c980d55ef@suse.com>
Date: Mon, 6 Jan 2025 10:08:03 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 19/35] xen/console: introduce console_set_owner()
To: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, Andrew Cooper <andrew.cooper3@citrix.com>,
 Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>,
 xen-devel@lists.xenproject.org
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-19-e9aa923127eb@ford.com>
 <d9c8e9bf-7eac-48f7-a347-b78e97a16f8f@suse.com>
 <CA3mSmUEpURgjpQUifNWDKDNS2HBsE68ad-RudxX4F45CCn2JL1wLo63_ZYcA7qx4nkD23GvE3BVlMjV0oz75Mssd0A5wQQ6zKlcWRLfhyM=@proton.me>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <CA3mSmUEpURgjpQUifNWDKDNS2HBsE68ad-RudxX4F45CCn2JL1wLo63_ZYcA7qx4nkD23GvE3BVlMjV0oz75Mssd0A5wQQ6zKlcWRLfhyM=@proton.me>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04.01.2025 04:07, Denis Mukhin wrote:
> On Tuesday, December 10th, 2024 at 7:02 AM, Jan Beulich <jbeulich@suse.com> wrote:
>> On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
>>> +int console_set_owner(domid_t domid)
>>
>>
>> static? Iirc Misra doesn't like non-static functions which aren't called
>> from any other CU.
> 
> Yes, but there's a follow on patch which will undo static - hwdom_crashconsole=
> patch - to drop the user to xen console once dom0 has crashed.
> So since there's a need in globally visible symbol, I decided to get rid of static
> right away.

Yet you realize that any series may go in piecemeal, and therefore no Misra rule
may be violated at any patch boundary?

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 06 09:14:52 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 09:14:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865582.1276824 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUjCB-0005Ps-K1; Mon, 06 Jan 2025 09:14:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865582.1276824; Mon, 06 Jan 2025 09:14:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUjCB-0005Pl-HL; Mon, 06 Jan 2025 09:14:47 +0000
Received: by outflank-mailman (input) for mailman id 865582;
 Mon, 06 Jan 2025 09:14: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 <SRS0=9khw=T6=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tUjCA-0005Pf-E2
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 09:14:46 +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 ab9eed1e-cc0e-11ef-a0df-8be0dac302b0;
 Mon, 06 Jan 2025 10:14:45 +0100 (CET)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-3862b364538so8066010f8f.1
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 01:14: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
 ffacd0b85a97d-38a1c89e26csm48139528f8f.78.2025.01.06.01.14.44
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 06 Jan 2025 01:14:44 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ab9eed1e-cc0e-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736154885; x=1736759685; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=lcIB1/Aes+G+TFzjE4b4guP9041iQn9WQdg+/V0MOoI=;
        b=Q/dCIScAdkHvho/J9svvKVv7zraCwjAXzBgF0sWfgawBNg2oZ9ISmJM+kec0YLWvky
         yVuZO6IEpE3r+anNmGmu02U5RLgf4ie9XeWZEt54jptgoIYImQDP7kT/jYzRk2FsQSrH
         u0IqljtpQgyzVvvR1VcxDfnZaSVCyhuWDa92NeLdjl7qiI2/6G6lDw+eQfASBS9AswIo
         YHqDC9VE+QKXwpKIA3txr4CQsviWFjyb+CYc0h03cTrWWKrs4BZIUTAVtQ2sPID1K7Za
         xOuXaQcn3N2biR7UuACHRycS3LDTZ61bk6sgNx8au2fK7xndeRjsOZsfkiyxn1dv9zkm
         7awA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736154885; x=1736759685;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=lcIB1/Aes+G+TFzjE4b4guP9041iQn9WQdg+/V0MOoI=;
        b=pwtlhcNfTlx1SQPmzBcXQuojJmZqaarxkPVsI66AIjPVsUSX4oG3fbFrg1FdRlfQa2
         g4/xFIf03J9iZEwxppSt0YjTpyyMOxcen6bqMKi49qNlD6a3dVeMpqk6xU3WXo6dAvVk
         Zc107iI+YBpBecLTNUUewXXjOMseyjziU5y/tpIxYbHwrOmHYJlNZ4UnjJnWJz5nEGJl
         mG0TeRkZ70nE/EQsdczaaXwy3ONQwCuJ8pvpvb340U2beA8AsedZ658v1RylvU5NkJYQ
         cV0+BRW3LTn2Fz4WlQDN17fpXtN3ozFrT4YjCxvNBrKXTPqB4trA4IAe2HfqZJSRKEvb
         79Jw==
X-Forwarded-Encrypted: i=1; AJvYcCWmAqhUL1e6C64S+m8YdqAq/s/Nl7//Vu9kne/dvlZlnsEI+N491iZx2HRz0yj9oVijvKoUthmWatE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxtZgvmXpisra6I/EMrHHWJMRmuHIPqCix3/YGAOxutX8V9Nsz5
	dUHAnhqN1Snt+TLuIEM4MNDJZcEQdqfYYC2QvcAFuYAaAWzOzksHRUMfTyio3w==
X-Gm-Gg: ASbGncs8jYJSp7cKm+c8np8bRNsDx5YD709EGRbmIcZ2k4T3LY7P3wbYa4iKeymIldk
	q/wjkgxTBpYnOyv/TTYsuQV+NiFhkaTsk/xI6wQjHha49C6K3EnzffDnHV8ildc7kbk+ybAIJuj
	wvb2suSL7aKR6WshNm1WqBvVLLZ+01ZN9bl+Izu1Vo7VkahbKm9ycFRz/WV853P6JfE0OUJPTxV
	gGfqZbN23a/OnF0WB1AgmZPdZ2VhIlZXmiRESRnNmBC9N+xAMbHFsWTrGlIkPLrpTRO6BpqhQ8H
	5oUWVDLHd0svEmWBaiRXVbtGbom3lRFVbItd9/WEKg==
X-Google-Smtp-Source: AGHT+IHNLLCEacBdVXsMUYVBmB6e33MgvIYzVZDlOMoDsFZKrLBDzA0tFaFqtdzw2EemZKQq8rbWqw==
X-Received: by 2002:a05:6000:1569:b0:386:3327:4f21 with SMTP id ffacd0b85a97d-38a22a648f7mr43021611f8f.27.1736154884856;
        Mon, 06 Jan 2025 01:14:44 -0800 (PST)
Message-ID: <8a5a5a0f-72b0-4336-b0d2-142254319242@suse.com>
Date: Mon, 6 Jan 2025 10:14:52 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 20/35] xen/console: introduce console_owner_domid()
To: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-20-e9aa923127eb@ford.com>
 <d55bf6a6-5861-4b72-88b5-2aaa28ae0290@suse.com>
 <VJ9ivpkbNlqfKhBlb5dL6OuoPAXK9wqD4mhgO9Qt4f0qgmuow22qFv1C7L8DlbKYo7ytdKWeV1bLaYJvTAc2Yt7sEd06XREerWER5RPx4No=@proton.me>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <VJ9ivpkbNlqfKhBlb5dL6OuoPAXK9wqD4mhgO9Qt4f0qgmuow22qFv1C7L8DlbKYo7ytdKWeV1bLaYJvTAc2Yt7sEd06XREerWER5RPx4No=@proton.me>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04.01.2025 05:15, Denis Mukhin wrote:
> 
> On Tuesday, December 10th, 2024 at 11:28 PM, Jan Beulich <jbeulich@suse.com> wrote:
> 
>>
>>
>> On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
>>
>>> From: Denis Mukhin dmukhin@ford.com
>>>
>>> console_owner_domid() is introduced to obtain the "console owner" domain ID.
>>>
>>> The call is used in NS8250 emulator to identify the case when physical xen
>>> console focus is owned by the domain w/ NS8250 emulator, in which case,
>>> messages from guest OS are formatted w/o '(XEN)' prefix.
>>
>>
>> Such messages ought to be processed through guest_printk(), which wants a
>> domain pointer, not a domid_t anyway. Plus isn't that going to be
>> current->domain anyway at the callsite, eliminating the need for such a
>>
>> helper altogether?
> 
> If the current domain is owning the physical console and printing, say, Linux
> login prompt, there's no need to add "(XEN)" for every printout; adding timestamps
> can be disabled from Xen command line.

Surely there shouldn't be (XEN), but without (d<N>) it'll be ambiguous in a log
which domain a message came from. As long as only Dom0 messages are left un-
prefixed, that's likely fine. Yet as soon as multiple domains can issue such
messages (and have console "focus") I think the prefix needs to be there.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 06 09:20:05 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 09:20:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865590.1276834 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUjH4-00060h-5F; Mon, 06 Jan 2025 09:19:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865590.1276834; Mon, 06 Jan 2025 09:19:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUjH4-00060a-2D; Mon, 06 Jan 2025 09:19:50 +0000
Received: by outflank-mailman (input) for mailman id 865590;
 Mon, 06 Jan 2025 09:19: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 <SRS0=9khw=T6=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tUjH2-00060S-7F
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 09:19:48 +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 5f290541-cc0f-11ef-a0df-8be0dac302b0;
 Mon, 06 Jan 2025 10:19:46 +0100 (CET)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-4362f61757fso140815855e9.2
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 01:19: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
 5b1f17b1804b1-4366e210cecsm526734825e9.2.2025.01.06.01.19.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 06 Jan 2025 01:19:45 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5f290541-cc0f-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736155186; x=1736759986; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=HQ+h3jmlTLYJDjcZJ5AvWxwIB0eFHQfXJkXX/CkHaVU=;
        b=cJUGVbFNDHFlsbEMtlaU8poMW6LD8UxzKTFz3l5fLRMt/svBQOwm6Lp63ePogkoOom
         q75NSdpJ+XhqTOPiroND/aKD++n+o+GSO9w/KAIUHCpYOv+VI5ytKQsOhzDqnC8CTcMk
         4Acgz1EOswquS3U6YKzJFgR5XTp4UGhdYd/9WgVrteIlhVOyAPW9liz/ayR29SMAWeKu
         1GsZUPBHL7HXUb4608Ho9Ows4zjSzzjJAN0rjh+xInHGg/RjFxI+V/Z8CIOjCKGiTmal
         F050awpYLUxxGE0O5/eseRdRKBv4dtXHtQ04OhX8isYrHMtt/YvUAnLJ0/ov9Yrslpsw
         Tebw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736155186; x=1736759986;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=HQ+h3jmlTLYJDjcZJ5AvWxwIB0eFHQfXJkXX/CkHaVU=;
        b=aOhtY01ITryAsa8NxSJowgOrjS6ajFCdnA2i4J/QrYuY1GDc9DeLAhQi8alBm2cIam
         aS3lNt3Xy8YfNQDG5Xbo1OOSyQdx3OkYq5XXmO0htcHkQwZRwp9T/jRj73ma3kXv1p4A
         emwAeOZgGQkEZ8Pc93IxXvvtzbbRBdyN9erVn9srCOAL8LZMp7A+uOMvtBBlbSf1oygK
         z9GfsBNa6q2n4iws3+xbBpsAjgUgWGq6x+Rp0jZuzFPvo2+DjXfcHbeNjfbnJ72Bx6Pj
         AIHxPUqJkp+Go2X0RojXsHUdAJgOG9XDCMNX+CfSSlunJHbrYKWynXLgzbrPfXxdz+Oa
         oOjw==
X-Forwarded-Encrypted: i=1; AJvYcCVwMDvqOeFkQehx7qyrTaueKeJ6JCNr/z+8nnutUQtQnm/29vkWeT6zFrRohtERDaKTltRBDxNPyss=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzttnO2R++P2IWML5sGkk8m2iNOtMaCQu9wFTXio92D8k9b3gH7
	vMythecw0zsLU8nr1Ay5KcTQtC4awq1eVaaimS+ozVJKJr+ykd7A2T0peg1atg==
X-Gm-Gg: ASbGncu0shICnY4AeeIHHpL5L7QUd/mwJbij5IVnzGtiTDpAUVo8Xw/8uUV6CiqD1+G
	pfSVyTOFbCvb5NY2THWAAN/+xNZE6gCLcjeAPFHpu7JQeCIWIlrOmdOgySJKqZqifkwQwQorTvV
	SFU6I7BCHe+HWSCinS3ggIOPubiUhJdZp+/J/SUAR74KFVr/bQzdVGoSioJq6r2PQNBx8gNQEj5
	ahedxmhEuRXgEqjHuT8udonl8uVlOxf+U7huGFMPNleDZ3xZ7CN5plui3JWWVrmG3EeRZ3CVmT3
	MY8i5AACVCJXtnI2vZd5coOmY/3Tcb1XGF4IH3/KKw==
X-Google-Smtp-Source: AGHT+IEv2C0VwV2IYdPQdFmPKd6CuOgJWQQmjpptM3HA061h1BG+IDfgbQqGuQU0LUE75NLBjvB/6A==
X-Received: by 2002:a05:600c:45cf:b0:434:a781:f5e2 with SMTP id 5b1f17b1804b1-43668642289mr456868325e9.8.1736155186038;
        Mon, 06 Jan 2025 01:19:46 -0800 (PST)
Message-ID: <5e4fb323-0dd1-4eb9-9e83-245ab516be06@suse.com>
Date: Mon, 6 Jan 2025 10:19:53 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 31/35] x86/hvm: introduce NS8250 UART emulator
To: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, Andrew Cooper <andrew.cooper3@citrix.com>,
 Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>,
 xen-devel@lists.xenproject.org
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-31-e9aa923127eb@ford.com>
 <3be247cc-900b-48f3-98f3-0d97532ede76@suse.com>
 <DJo9IkTvGXsao_hA4njnkX9OVYVR6tXdo95AeBiT8wGtbPb7UKQjLCqqIset3bJ3JbLqogcIb4wPqNXJ-2GFwyrW_UIvRg5Nt9QhpG0hfyo=@proton.me>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <DJo9IkTvGXsao_hA4njnkX9OVYVR6tXdo95AeBiT8wGtbPb7UKQjLCqqIset3bJ3JbLqogcIb4wPqNXJ-2GFwyrW_UIvRg5Nt9QhpG0hfyo=@proton.me>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04.01.2025 06:31, Denis Mukhin wrote:
> On Monday, December 16th, 2024 at 7:04 AM, Jan Beulich <jbeulich@suse.com> wrote:
>> On 06.12.2024 05:42, Denis Mukhin via B4 Relay wrote:
>>> + depends on HVM && HAS_IOPORTS
>>
>>
>> Why HAS_IOPORTS?
> 
> It is meant to highlight the fact that MMIO-based UART is not supported.
> It is not currently possible to enable the emulator for, say, Arm platforms.

That I guessed, yet you realize that HAS_IOPORTS describes a host property,
not (so much) a guest one?

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 06 09:34:58 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 09:34:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865600.1276844 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUjVc-0000wL-F0; Mon, 06 Jan 2025 09:34:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865600.1276844; Mon, 06 Jan 2025 09:34:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUjVc-0000wE-Bm; Mon, 06 Jan 2025 09:34:52 +0000
Received: by outflank-mailman (input) for mailman id 865600;
 Mon, 06 Jan 2025 09:34: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 <SRS0=3b0o=T6=suse.com=jgross@srs-se1.protection.inumbo.net>)
 id 1tUjVa-0000w8-Ta
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 09:34:51 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7944839e-cc11-11ef-a0df-8be0dac302b0;
 Mon, 06 Jan 2025 10:34:49 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id F2E3821134;
 Mon,  6 Jan 2025 09:34:47 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 99827139AB;
 Mon,  6 Jan 2025 09:34:47 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id +EH3I7eje2ezcAAAD6G6ig
 (envelope-from <jgross@suse.com>); Mon, 06 Jan 2025 09:34:47 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 7944839e-cc11-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1736156089; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=MG/WE0bNwqU/fq3Z02wnYCpQ3/FN4nGp5XO5g8vqcao=;
	b=TDtGtv+j2Gl+TwTFnb1wlaIqdboWaeE63PZB0v+lRhF1i8fJ3Y36gunUOhz0jv6j+3HP0K
	ya3V+6BiQhb0Xlqlf3b2/ap6M337liWNtug5yF1voH32aezjJCrUTzK2L1W3jeSCdkOLDJ
	xxiEi4GB0t1TDzwuzOYg7mtCLADypUk=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1736156088; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=MG/WE0bNwqU/fq3Z02wnYCpQ3/FN4nGp5XO5g8vqcao=;
	b=Twj8r40wubnZ4B8mJUAwNjWkxwaFExbLNIwADqo6VpLHlGjj3TUGxNH2+l43Q7bxVrm5EJ
	xAOxBboPRP2JRkMynB+VDu1qckGIHBcIoWvbnzXUB0jYvmvFqoMUQ4KLpxhb7OOR/EEjqV
	yweHeepE4Wv90gPOWCdky9Xv19xDkoE=
Message-ID: <a4235e7d-9a46-4001-85d5-807f33031386@suse.com>
Date: Mon, 6 Jan 2025 10:34:46 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 2/5] xen: add bitmap to indicate per-domain state
 changes
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <20241217142218.24129-1-jgross@suse.com>
 <20241217142218.24129-3-jgross@suse.com>
 <ce327545-c23b-4272-a290-ce950b4c27f5@suse.com>
 <b7738421-5802-4179-8b6b-1ec18b8abd8a@suse.com>
 <be77e290-086e-4393-ac68-13a9cddc3f98@suse.com>
 <2fa06b11-e7a0-4f57-9af0-af432d35820a@suse.com>
 <37d13114-91eb-4d0f-9404-e5fd6cfca256@suse.com>
Content-Language: en-US
From: Juergen Gross <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <37d13114-91eb-4d0f-9404-e5fd6cfca256@suse.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------kNY3hHPPUvlMx11L17Wimi7r"
X-Spam-Level: 
X-Spamd-Result: default: False [-6.20 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SIGNED_PGP(-2.00)[];
	NEURAL_HAM_LONG(-1.00)[-0.998];
	MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain];
	NEURAL_HAM_SHORT(-0.20)[-0.998];
	MIME_UNKNOWN(0.10)[application/pgp-keys];
	MIME_BASE64_TEXT(0.10)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~];
	ARC_NA(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	HAS_ATTACHMENT(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_SEVEN(0.00)[8];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,imap1.dmz-prg2.suse.org:helo]
X-Spam-Score: -6.20
X-Spam-Flag: NO

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------kNY3hHPPUvlMx11L17Wimi7r
Content-Type: multipart/mixed; boundary="------------FGqVUd63xmq700LXPIz5FeaD";
 protected-headers="v1"
From: Juergen Gross <jgross@suse.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
Message-ID: <a4235e7d-9a46-4001-85d5-807f33031386@suse.com>
Subject: Re: [PATCH v5 2/5] xen: add bitmap to indicate per-domain state
 changes
References: <20241217142218.24129-1-jgross@suse.com>
 <20241217142218.24129-3-jgross@suse.com>
 <ce327545-c23b-4272-a290-ce950b4c27f5@suse.com>
 <b7738421-5802-4179-8b6b-1ec18b8abd8a@suse.com>
 <be77e290-086e-4393-ac68-13a9cddc3f98@suse.com>
 <2fa06b11-e7a0-4f57-9af0-af432d35820a@suse.com>
 <37d13114-91eb-4d0f-9404-e5fd6cfca256@suse.com>
In-Reply-To: <37d13114-91eb-4d0f-9404-e5fd6cfca256@suse.com>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------FGqVUd63xmq700LXPIz5FeaD
Content-Type: multipart/mixed; boundary="------------lwUnZmugrvvLL3V6cnFyGcjp"

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

T24gMTkuMTIuMjQgMDk6MDEsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAxOC4xMi4yMDI0
IDA4OjE1LCBKw7xyZ2VuIEdyb8OfIHdyb3RlOg0KPj4gT24gMTcuMTIuMjQgMTc6MTIsIEph
biBCZXVsaWNoIHdyb3RlOg0KPj4+IE9uIDE3LjEyLjIwMjQgMTY6NTUsIErDvHJnZW4gR3Jv
w58gd3JvdGU6DQo+Pj4+IE9uIDE3LjEyLjI0IDE2OjE5LCBKYW4gQmV1bGljaCB3cm90ZToN
Cj4+Pj4+IE9uIDE3LjEyLjIwMjQgMTU6MjIsIEp1ZXJnZW4gR3Jvc3Mgd3JvdGU6DQo+Pj4+
Pj4gQWRkIGEgYml0bWFwIHdpdGggb25lIGJpdCBwZXIgcG9zc2libGUgZG9taWQgaW5kaWNh
dGluZyB0aGUgcmVzcGVjdGl2ZQ0KPj4+Pj4+IGRvbWFpbiBoYXMgY2hhbmdlZCBpdHMgc3Rh
dGUgKGNyZWF0ZWQsIGRlbGV0ZWQsIGR5aW5nLCBjcmFzaGVkLA0KPj4+Pj4+IHNodXRkb3du
KS4NCj4+Pj4+Pg0KPj4+Pj4+IFJlZ2lzdGVyaW5nIHRoZSBWSVJRX0RPTV9FWEMgZXZlbnQg
d2lsbCByZXN1bHQgaW4gc2V0dGluZyB0aGUgYml0cyBmb3INCj4+Pj4+PiBhbGwgZXhpc3Rp
bmcgZG9tYWlucyBhbmQgcmVzZXR0aW5nIGFsbCBvdGhlciBiaXRzLg0KPj4+Pj4+DQo+Pj4+
Pj4gQXMgdGhlIHVzYWdlIG9mIHRoaXMgYml0bWFwIGlzIHRpZ2h0bHkgY291cGxlZCB3aXRo
IHRoZSBWSVJRX0RPTV9FWEMNCj4+Pj4+PiBldmVudCwgaXQgaXMgbWVhbnQgdG8gYmUgdXNl
ZCBvbmx5IGJ5IGEgc2luZ2xlIGNvbnN1bWVyIGluIHRoZSBzeXN0ZW0sDQo+Pj4+Pj4ganVz
dCBsaWtlIHRoZSBWSVJRX0RPTV9FWEMgZXZlbnQuDQo+Pj4+Pg0KPj4+Pj4gSSdtIHNvcnJ5
LCBidXQgSSBuZWVkIHRvIGNvbWUgYmFjayB0byB0aGlzLiBJIHRob3VnaHQgSSBoYWQgZ290
IGNvbnZpbmNlZA0KPj4+Pj4gdGhhdCBvbmx5IGEgc2luZ2xlIGVudGl0eSBpbiB0aGUgc3lz
dGVtIGNhbiBiaW5kIHRoaXMgdklSUS4gWWV0IHVwb24NCj4+Pj4+IGNoZWNraW5nIEkgY2Fu
J3Qgc2VlbSB0byBmaW5kIHdoYXQgd291bGQgZ3VhcmFudGVlIHRoaXMuIEluIHBhcnRpY3Vs
YXINCj4+Pj4+IGJpbmRpbmcgYSB2SVJRIGRvZXNuJ3QgaW52b2x2ZSBhbnkgWFNNIGNoZWNr
LiBIZW5jZSBhbiB1bnByaXZpbGVnZWQgZW50aXR5DQo+Pj4+PiBjb3VsZCwgb24gdGhlIGFz
c3VtcHRpb24gdGhhdCB0aGUgaW50ZXJlc3RlZCBwcml2aWxlZ2VkIGVudGl0eSAoeGVuc3Rv
cmUpDQo+Pj4+PiBpcyBhbHJlYWR5IHVwIGFuZCBydW5uaW5nLCBiaW5kIGFuZCB1bmJpbmQg
dGhpcyB2SVJRLCBqdXN0IHRvIGhhdmUgdGhlDQo+Pj4+PiBnbG9iYWwgbWFwIGZyZWVkLiBX
aGF0IGFtIEkgb3Zlcmxvb2tpbmcgKHdoaWNoIHdvdWxkIGxpa2VseSB3YW50IHN0YXRpbmcN
Cj4+Pj4+IGhlcmUpPw0KPj4+Pg0KPj4+PiBJIHRoaW5rIHlvdSBhcmUgbm90IG92ZXJsb29r
aW5nIGFueXRoaW5nLg0KPj4+Pg0KPj4+PiBJIGd1ZXNzIHRoaXMgY2FuIGVhc2lseSBiZSBo
YW5kbGVkIGJ5IGNoZWNraW5nIHRoYXQgdGhlIFZJUlFfRE9NX0VYQyBoYW5kbGluZw0KPj4+
PiBkb21haW4gaXMgdGhlIGNhbGxpbmcgb25lIGluIGRvbWFpbl9bZGVdaW5pdF9zdGF0ZXMo
KS4gTm90ZSB0aGF0IGdsb2JhbCB2aXJxcw0KPj4+PiBhcmUgb25seSBldmVyIHNlbnQgdG8g
dmNwdVswXSBvZiB0aGUgaGFuZGxpbmcgZG9tYWluLCBzbyByZWJpbmRpbmcgdGhlIGV2ZW50
DQo+Pj4+IHRvIGFub3RoZXIgdmNwdSBpcyBwb3NzaWJsZSwgYnV0IGRvZXNuJ3QgbWFrZSBz
ZW5zZS4NCj4+Pg0KPj4+IE5vLCB0aGF0J3MgcHJlY2x1ZGVkIGJ5DQo+Pj4NCj4+PiAgICAg
ICBpZiAoIHZpcnFfaXNfZ2xvYmFsKHZpcnEpICYmICh2Y3B1ICE9IDApICkNCj4+PiAgICAg
ICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+Pj4NCj4+PiBhZmFpY3QuIFRoYXQgZG9lc24ndCwg
aG93ZXZlciwgcHJlY2x1ZGUgbXVsdGlwbGUgdkNQVS1zIGZyb20gdHJ5aW5nIHRvIGJpbmQN
Cj4+PiB0aGUgdklSUSB0byB2Q1BVIDAuDQo+Pg0KPj4gSSBsZXQgbXlzZWxmIGZvb2wgYnkg
dGhlIGFiaWxpdHkgdG8gdXNlIEVWVENITk9QX2JpbmRfdmNwdSBmb3IgYSBnbG9iYWwNCj4+
IHZpcnEuIFdoaWxlIGl0IGlzIHBvc3NpYmxlIHRvIHNlbmQgdGhlIGV2ZW50IHRvIGFub3Ro
ZXIgdmNwdSwgaXQgaXMgc3RpbGwNCj4+IHZjcHVbMF0gd2hpY2ggaXMgdXNlZCBmb3IgdGhl
IGJvb2trZWVwaW5nLg0KPj4NCj4+Pg0KPj4+Pj4+IFY1Og0KPj4+Pj4+IC0gZG9tYWluX2lu
aXRfc3RhdGVzKCkgbWF5IGJlIGNhbGxlZCBvbmx5IGlmIGV2dGNobl9iaW5kX3ZpcnEoKSBo
YXMgYmVlbg0KPj4+Pj4+ICAgICAgY2FsbGVkIHZhbGlkbHkgKEphbiBCZXVsaWNoKQ0KPj4+
Pj4NCj4+Pj4+IEkgbm93IHJlY2FsbCB3aHkgSSBoYWQgZmlyc3Qgc3VnZ2VzdGVkIHRoZSBw
bGFjZW1lbnQgbGF0ZXIgaW4gdGhlIGhhbmRsaW5nOg0KPj4+Pj4gWW91J3JlIG5vdyBkb2lu
ZyB0aGUgYWxsb2NhdGlvbiB3aXRoIHlldCBhbm90aGVyIGxvY2sgaGVsZC4gSXQncyBsaWtl
bHkgbm90DQo+Pj4+PiB0aGUgZW5kIG9mIHRoZSB3b3JsZCwgYnV0IC4uLg0KPj4+Pj4NCj4+
Pj4+PiBAQCAtMTM4LDYgKzEzOSw2MCBAQCBib29sIF9fcmVhZF9tb3N0bHkgdm10cmFjZV9h
dmFpbGFibGU7DQo+Pj4+Pj4gICAgIA0KPj4+Pj4+ICAgICBib29sIF9fcmVhZF9tb3N0bHkg
dnBtdV9pc19hdmFpbGFibGU7DQo+Pj4+Pj4gICAgIA0KPj4+Pj4+ICtzdGF0aWMgREVGSU5F
X1NQSU5MT0NLKGRvbV9zdGF0ZV9jaGFuZ2VkX2xvY2spOw0KPj4+Pj4+ICtzdGF0aWMgdW5z
aWduZWQgbG9uZyAqX19yZWFkX21vc3RseSBkb21fc3RhdGVfY2hhbmdlZDsNCj4+Pj4+PiAr
DQo+Pj4+Pj4gK2ludCBkb21haW5faW5pdF9zdGF0ZXModm9pZCkNCj4+Pj4+PiArew0KPj4+
Pj4+ICsgICAgY29uc3Qgc3RydWN0IGRvbWFpbiAqZDsNCj4+Pj4+PiArICAgIGludCByYyA9
IC1FTk9NRU07DQo+Pj4+Pj4gKw0KPj4+Pj4+ICsgICAgc3Bpbl9sb2NrKCZkb21fc3RhdGVf
Y2hhbmdlZF9sb2NrKTsNCj4+Pj4+PiArDQo+Pj4+Pj4gKyAgICBpZiAoIGRvbV9zdGF0ZV9j
aGFuZ2VkICkNCj4+Pj4+PiArICAgICAgICBiaXRtYXBfemVybyhkb21fc3RhdGVfY2hhbmdl
ZCwgRE9NSURfRklSU1RfUkVTRVJWRUQpOw0KPj4+Pj4+ICsgICAgZWxzZQ0KPj4+Pj4+ICsg
ICAgew0KPj4+Pj4+ICsgICAgICAgIGRvbV9zdGF0ZV9jaGFuZ2VkID0geHZ6YWxsb2NfYXJy
YXkodW5zaWduZWQgbG9uZywNCj4+Pj4+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIEJJVFNfVE9fTE9OR1MoRE9NSURfRklSU1RfUkVTRVJWRUQpKTsN
Cj4+Pj4+DQo+Pj4+PiAuLi4gYWxyZWFkeSB0aGlzIGFsb25lIHdhc24ndCBuaWNlLCBhbmQg
Y291bGQgYmUgYXZvaWRlZCAoYnkgZG9pbmcgdGhlDQo+Pj4+PiBhbGxvY2F0aW9uIHByaW9y
IHRvIGFjcXVpcmluZyB0aGUgbG9jaywgd2hpY2ggb2YgY291cnNlIGNvbXBsaWNhdGVzIHRo
ZQ0KPj4+Pj4gbG9naWMgc29tZSkuDQo+Pj4+Pg0KPj4+Pj4gV2hhdCdzIHBlcmhhcHMgbGVz
cyBkZXNpcmFibGUgaXMgdGhhdCAuLi4NCj4+Pj4+DQo+Pj4+Pj4gQEAgLTQ5NCw2ICs0OTUs
MTUgQEAgaW50IGV2dGNobl9iaW5kX3ZpcnEoZXZ0Y2huX2JpbmRfdmlycV90ICpiaW5kLCBl
dnRjaG5fcG9ydF90IHBvcnQpDQo+Pj4+Pj4gICAgICAgICAgICAgZ290byBvdXQ7DQo+Pj4+
Pj4gICAgICAgICB9DQo+Pj4+Pj4gICAgIA0KPj4+Pj4+ICsgICAgaWYgKCB2aXJxID09IFZJ
UlFfRE9NX0VYQyApDQo+Pj4+Pj4gKyAgICB7DQo+Pj4+Pj4gKyAgICAgICAgcmMgPSBkb21h
aW5faW5pdF9zdGF0ZXMoKTsNCj4+Pj4+PiArICAgICAgICBpZiAoIHJjICkNCj4+Pj4+PiAr
ICAgICAgICAgICAgZ290byBvdXQ7DQo+Pj4+Pj4gKw0KPj4+Pj4+ICsgICAgICAgIGRlaW5p
dF9pZl9lcnIgPSB0cnVlOw0KPj4+Pj4+ICsgICAgfQ0KPj4+Pj4+ICsNCj4+Pj4+PiAgICAg
ICAgIHBvcnQgPSByYyA9IGV2dGNobl9nZXRfcG9ydChkLCBwb3J0KTsNCj4+Pj4+PiAgICAg
ICAgIGlmICggcmMgPCAwICkNCj4+Pj4+PiAgICAgICAgIHsNCj4+Pj4+DQo+Pj4+PiAuLi4g
dGhlIHBsYWNlbWVudCBoZXJlIGFkZGl0aW9uYWxseSBpbnRyb2R1Y2VzIGxvY2sgbmVzdGlu
ZyB3aGVuIHJlYWxseQ0KPj4+Pj4gdGhlIHR3byBsb2NrcyBzaG91bGRuJ3QgaGF2ZSBhbnkg
cmVsYXRpb25zaGlwLg0KPj4+Pj4NCj4+Pj4+IEhvdyBhYm91dCBnaXZpbmcgZG9tYWluX2lu
aXRfc3RhdGVzKCkgYSBib29sZWFuIHBhcmFtZXRlciwgc3VjaCB0aGF0IGl0DQo+Pj4+PiBj
YW4gYmUgY2FsbGVkIHR3aWNlLCB3aXRoIHRoZSBmaXJzdCBpbnZvY2F0aW9uIG1vdmVkIGJh
Y2sgdXAgd2hlcmUgaXQNCj4+Pj4+IHdhcywgYW5kIHRoZSBzZWNvbmQgb25lIHB1dCAuLi4N
Cj4+Pj4+DQo+Pj4+Pj4gQEAgLTUyNyw2ICs1MzcsOSBAQCBpbnQgZXZ0Y2huX2JpbmRfdmly
cShldnRjaG5fYmluZF92aXJxX3QgKmJpbmQsIGV2dGNobl9wb3J0X3QgcG9ydCkNCj4+Pj4+
PiAgICAgIG91dDoNCj4+Pj4+PiAgICAgICAgIHdyaXRlX3VubG9jaygmZC0+ZXZlbnRfbG9j
ayk7DQo+Pj4+Pj4gICAgIA0KPj4+Pj4+ICsgICAgaWYgKCByYyAmJiBkZWluaXRfaWZfZXJy
ICkNCj4+Pj4+PiArICAgICAgICBkb21haW5fZGVpbml0X3N0YXRlcygpOw0KPj4+Pj4+ICsN
Cj4+Pj4+PiAgICAgICAgIHJldHVybiByYzsNCj4+Pj4+PiAgICAgfQ0KPj4+Pj4NCj4+Pj4+
IC4uLiBkb3duIGhlcmUsIG5vdCBkb2luZyBhbnkgYWxsb2NhdGlvbiBhdCBhbGwgKG9ubHkg
dGhlIGNsZWFyaW5nKSwgYW5kDQo+Pj4+PiBoZW5jZSBlbGltaW5hdGluZyB0aGUgbmVlZCB0
byBkZWFsIHdpdGggaXRzIGZhaWx1cmU/IChBbHRlcm5hdGl2ZWx5DQo+Pj4+PiB0aGVyZSBj
b3VsZCBvZiBjb3Vyc2UgYmUgYSBzcGxpdCBpbnRvIGFuIGluaXQgYW5kIGEgcmVzZXQgZnVu
Y3Rpb24uKQ0KPj4+Pj4NCj4+Pj4+IFRoZXJlIG9mIGNvdXJzZSBpcyB0aGUgY2hhbmNlIG9m
IHJhY2VzIHdpdGggc3VjaCBhbiBhcHByb2FjaC4gSSdkIGxpa2UNCj4+Pj4+IHRvIG5vdGUg
dGhvdWdoIHRoYXQgd2l0aCB0aGUgcGxhY2VtZW50IG9mIHRoZSBjYWxsIGluIHRoZSBodW5r
IGFib3ZlDQo+Pj4+PiB0aGVyZSdzIGEgbWlub3IgcmFjZSwgdG9vIChhZ2FpbnN0IC4uLg0K
Pj4+Pj4NCj4+Pj4+PiBAQCAtNzMwLDYgKzc0Myw5IEBAIGludCBldnRjaG5fY2xvc2Uoc3Ry
dWN0IGRvbWFpbiAqZDEsIGludCBwb3J0MSwgYm9vbCBndWVzdCkNCj4+Pj4+PiAgICAgICAg
ICAgICBzdHJ1Y3QgdmNwdSAqdjsNCj4+Pj4+PiAgICAgICAgICAgICB1bnNpZ25lZCBsb25n
IGZsYWdzOw0KPj4+Pj4+ICAgICANCj4+Pj4+PiArICAgICAgICBpZiAoIGNobjEtPnUudmly
cSA9PSBWSVJRX0RPTV9FWEMgKQ0KPj4+Pj4+ICsgICAgICAgICAgICBkb21haW5fZGVpbml0
X3N0YXRlcygpOw0KPj4+Pj4NCj4+Pj4+IC4uLiB0aGlzIGFuZCB0aGUgc2FtZSByZW1vdGUg
dkNQVSB0aGVuIGltbWVkaWF0ZWx5IGJpbmRpbmcgdGhlIHZJUlENCj4+Pj4+IGFnYWluKS4g
SGVuY2UgeWV0IGFub3RoZXIgYWx0ZXJuYXRpdmUgd291bGQgYXBwZWFyIHRvIGJlIHRvIGRy
b3AgdGhlDQo+Pj4+PiBuZXcgZ2xvYmFsIGxvY2sgYW5kIHVzZSBkLT5ldmVudF9sb2NrIGZv
ciBzeW5jaHJvbml6YXRpb24gaW5zdGVhZA0KPj4+Pj4gKHByb3ZpZGVkIC0gc2VlIGFib3Zl
IC0gdGhhdCBvbmx5IGEgc2luZ2xlIGVudGl0eSBjYW4gYWN0dWFsbHkgc2V0IHVwDQo+Pj4+
PiBhbGwgb2YgdGhpcykuIFRoYXQgd291bGQgcHJldHR5IG11Y2ggd2FudCB0byBoYXZlIHRo
ZSBhbGxvY2F0aW9uIGtlcHQNCj4+Pj4+IHdpdGggdGhlIGxvY2sgYWxyZWFkeSBoZWxkICh3
aGljaCBpc24ndCBuaWNlLCBidXQgYXMgc2FpZCBpcyBwZXJoYXBzDQo+Pj4+PiB0b2xlcmFi
bGUpLCBidXQgd291bGQgYXQgbGVhc3QgZWxpbWluYXRlIHRoZSB1bmRlc2lyYWJsZSBsb2Nr
IG5lc3RpbmcuDQo+Pj4+Pg0KPj4+Pj4gUmUtdXNlIG9mIHRoZSBkb21haW4ncyBldmVudCBs
b2NrIGlzIGF0IGxlYXN0IHNvbWV3aGF0IGp1c3RpZmllZCBieQ0KPj4+Pj4gdGhlIGJpdCBh
cnJheSBiZWluZyB0aWVkIHRvIFZJUlFfRE9NX0VYRUMuDQo+Pj4+Pg0KPj4+Pj4gVGhvdWdo
dHM/DQo+Pj4+DQo+Pj4+IFdpdGggbXkgc3VnZ2VzdGlvbiBhYm92ZSBJIHRoaW5rIHRoZXJl
IGlzIG5vIHJhY2UsIGFzIG9ubHkgdGhlIGRvbWFpbiBoYW5kbGluZw0KPj4+PiBWSVJRX0RP
TV9FWEMgY291bGQgYWxsb2MvZGVhbGxvYyBkb21fc3RhdGVfY2hhbmdlZC4NCj4+Pg0KPj4+
IFlldCBzdGlsbCBpdCBjb3VsZCBiZSBtdWx0aXBsZSB2Q1BVLXMgdGhlcmVpbiB0byB0cnkg
dG8gaW4gcGFyYWxsZWwuDQo+Pg0KPj4gQnV0IGlzbid0IHRoaXMgYWdhaW4gdGhlIG5lZWQg
Zm9yIHRydXN0aW5nIG90aGVyIHByb2Nlc3NlcyB3aXRoaW4gdGhlIGRvbWFpbg0KPj4gaGF2
aW5nIHRoZSByaWdodCB0byBjb25zdW1lIHRoZSB2aXJxPw0KPj4NCj4+IEluIHRoZSBlbmQg
aXQgZG9lc24ndCBtYXR0ZXIgd2hldGhlciB0aGVyZSBpcyBzdWNoIGEgcmFjZSBvciBub3Qu
IFNvbWUNCj4+IHByb2Nlc3MgaW4gdGhhdCBkb21haW4gaGF2aW5nIHRoZSBwb3dlciB0byBk
byBldmVudCBjaGFubmVsIG9wZXJhdGlvbnMgY291bGQNCj4+IHNpbXBseSBjbG9zZSB0aGUg
ZXZlbnQgY2hhbm5lbC4gU28gaXQgSVMgcmVhbGx5IGFib3V0IHRydXN0Lg0KPiANCj4gV2Vs
bC4gV2hhdCB3ZSBkbyBpbiBYZW4gc2hvdWxkIGJlIGNvcnJlY3Qgd2l0aG91dCByZWdhcmQg
dG8gd2hhdCBhIGd1ZXN0IG1pZ2h0DQo+IGJlIGRvaW5nLiBBbmQgaXQgc2hvdWxkIGJlIHNh
ZmUgYWdhaW5zdCBhbnkgbm90LWZ1bGx5LXByaXZpbGVnZWQgZW50aXR5IGluIHRoZQ0KPiBz
eXN0ZW0uIEhlbmNlIHdoeSBJIHRoaW5rIHN1Y2ggYSByYWNlIG5lZWRzIGRlYWxpbmcgd2l0
aCBjb3JyZWN0bHksIG5vIG1hdHRlcg0KPiB0aGF0IGl0J3Mgbm90IGEgc2FuZSB0aGluZyB0
byBkbyBmb3IgYSBndWVzdC4NCg0KSSB0aGluayBJIGhhdmUgbm93IGZvdW5kIGEgc29sdXRp
b24gY292ZXJpbmcgYWxsIHlvdXIgcmVtYXJrczoNCg0KLSBJJ3ZlIGFkZGVkIDIgcGF0Y2hl
cyBtYWtpbmcgc3VyZSB0aGF0IG9ubHkgYSBzaW5nbGUgY29uc3VtZXIgb2YgYSBnbG9iYWwN
CiAgIHZpcnEgaXMgYWJsZSB0byBiaW5kIHRvIHRoYXQgdmlycSwgd2hpbGUgZW5zdXJpbmcg
dGhhdCBpdCBpc24ndCBwb3NzaWJsZQ0KICAgdG8gc3dpdGNoIHRoZSBoYW5kbGluZyBkb21h
aW4gd2hpbGUgYSB2aXJxIGlzIGJvdW5kIGJ5IGEgZG9tYWluLiBUaGlzIHdpbGwNCiAgIGVs
aW1pbmF0ZSBhbGwgdGhlIHJhY2VzLg0KDQotIEknbGwgc3dpdGNoIHRvIHVzZSB0aGUgZC0+
ZXZlbnRfbG9jayBmb3IgcHJvdGVjdGluZyB0aGUgYml0bWFwLg0KDQotIEknbSBkcm9wcGlu
ZyB0aGUgY2FzZSB3aGVyZSB0aGUgYml0bWFwIGlzIGFscmVhZHkgYWxsb2NhdGVkIHdoZW4g
ZG9pbmcgdGhlDQogICBiaW5kLiBBZnRlciBhbGwgdGhpcyBzaG91bGRuJ3QgYmUgcG9zc2li
bGUgYW55IGxvbmdlciwgYXMgdGhlIGJpdG1hcCB3aWxsIGJlDQogICBmcmVlZCB3aGVuIGNs
b3NpbmcgdGhlIGV2ZW50IGNoYW5uZWwuIFRoaXMgYWdhaW4gd2lsbCByZW1vdmUgdGhlIGNh
c2Ugd2hlcmUNCiAgIGJpbmRpbmcgd291bGQgcG90ZW50aWFsbHkgY2hhbmdlIHRoZSBiaXRt
YXAgd2l0aG91dCBvd25pbmcgaXQuDQoNCg0KSnVlcmdlbg0K
--------------lwUnZmugrvvLL3V6cnFyGcjp
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

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

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

--------------lwUnZmugrvvLL3V6cnFyGcjp--

--------------FGqVUd63xmq700LXPIz5FeaD--

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

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

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmd7o7cFAwAAAAAACgkQsN6d1ii/Ey+G
1Qf/S3rf8VxjRLBEf5a0mxetnRrXzjx7WtCa8pAuJOLTsKFct33HTAVPyaGpndbocvadLVQr3e/5
vlRILs0JXUWGsaYePqXf41c9VuYGPZ47VJ8yZE7ZEQ/RhBnmOBTSnlrRRwkP6e39ehy7CQc6QpTY
cFefyB9gvCE3Ne3Ws8u/o+na85OqJ1JMOUlCillgvkCMeIuH6aFCNqvOebBSdJnQBAQEyNowP/tg
6rE1N937bvaGha13ceb9iSthwebBH67lLUYOojukzhfc78NEpKsBKemjEz29Otd5Gc3jiRAxwcF/
GqZhUnBuDz7LENQ60vlsIFxRVNwfTymZTmQK0MK80g==
=8+JC
-----END PGP SIGNATURE-----

--------------kNY3hHPPUvlMx11L17Wimi7r--


From xen-devel-bounces@lists.xenproject.org Mon Jan 06 09:52:27 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 09:52:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865615.1276860 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUjmW-0004Id-Rb; Mon, 06 Jan 2025 09:52:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865615.1276860; Mon, 06 Jan 2025 09:52:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUjmW-0004IW-Na; Mon, 06 Jan 2025 09:52:20 +0000
Received: by outflank-mailman (input) for mailman id 865615;
 Mon, 06 Jan 2025 09:52:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=9khw=T6=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tUjmV-0004IO-Px
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 09:52:19 +0000
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com
 [2a00:1450:4864:20::335])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ea2ee72b-cc13-11ef-99a4-01e77a169b0f;
 Mon, 06 Jan 2025 10:52:17 +0100 (CET)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-43634b570c1so101289935e9.0
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 01:52:17 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436611ea3d5sm568174355e9.5.2025.01.06.01.52.16
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 06 Jan 2025 01:52:16 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ea2ee72b-cc13-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736157137; x=1736761937; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=CqQDs2dvlWLyQTrS9K1D1IjW7NfezeJIlWnG4VSQiQI=;
        b=RoRpM63ArSubnEWidRk9RtcbRgPStJUN4KIHOyIt1b68hEDDoS5k96U88iE8DSibC6
         ZvX2vTpGc4VRCJztV3Dbb/0kOjaofDyeJKQcgbrpUwv37j6Bo4jwnYPHc/QOZ/magXDg
         gjUA5e7LfKY286kPAlBb1LJCOcILfegFwWQg9oxvrdafyz+gb3BMQAG/ikjKi8YxHMid
         Ul+4syqRDuAvteK9cR3XDL6WW1S5iowfA1+pdjpTutr4+unKEszfOykIKL7RCl4pi+uS
         jNWV/FumNTL1sdgd4qBCTByXX6tnapClOP+DgOdMExB6qu5/LTIgqUnYH2thCyezVbIw
         RtPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736157137; x=1736761937;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=CqQDs2dvlWLyQTrS9K1D1IjW7NfezeJIlWnG4VSQiQI=;
        b=SvA+BxOu550xJltzmASAXzzmywroQP51cUPpojWJ4oqBSt/q8qerIQ0veyab5JqaQS
         z8ZwlqhBQf/T+T1KXzL9Twt2QXJIC+kcBxmGxO5ZwxM7v1xbDPFPePe1oOBWEQHuVL5/
         RQCzAjdi/L+4I15g1MSym7Th267eAYIuU4a6gKMm4cDtdkhIf39f6WJiTpeM+TTaMFcF
         615v492quj+ZQT8uhLoGs9u/aceHfl+o7IO6gWad8HTeApDorfg8rV525FxQLhBLbghf
         579UQLlW+upmEEKrY2PYUT/JADLacynIrloHVOSSgQ5FwBJGRS0U18TIvFsWepRzMHfJ
         Ei7w==
X-Gm-Message-State: AOJu0YwrbpfQ/5Bm8Jde4OaH05jkzeNZnfP/RFBz3NkcPj0GQ9vOWf8i
	7UR7PJBkVM79QJC3kMWCuhXmTg4KM46BM5cBKG8zFEbFFJhvD6FQE2uEj53anw==
X-Gm-Gg: ASbGncvgF3XgGsQwJOaV9UVzVkiPgES4HvSfDvvt/OpSuy5yt8YCm+Usl3ccaeSjxDA
	rtJZIrdNlBDwEcXsv7TY8urEiXBgiJfHBcbUg9ckUSVjbCn8NkPMQX1R41AzoXxmKCL0zxMrcj+
	w+Y9AWECsUQVsl1RsklIuJIEhn5BTDc2soZg2btnCDzgIHNAwBOSAIfZV2Y8FKsJxSoEZpBR/oI
	Jdi8H2ZM2z/LCg8Jv/Hq5OqX4BG8Iv/yzDcB8WCOL8Salc0mR37PSDl851aHZ393YH3D84PahFz
	6ZUK+9X8fKYgNXQ0coPIP9ELXSi1Z/p4aexoSMIvfQ==
X-Google-Smtp-Source: AGHT+IGn42AMHI+smmC9KNk473yZgcZmbQlZKy2/GG1YCkYA6Hcwyxru8AU++K3zMLKcFuNa/RA0oQ==
X-Received: by 2002:a05:600c:6b09:b0:434:eb86:aeca with SMTP id 5b1f17b1804b1-43675cb208bmr553078535e9.10.1736157137316;
        Mon, 06 Jan 2025 01:52:17 -0800 (PST)
Message-ID: <ed73733f-d667-45e3-84cb-dd3527156923@suse.com>
Date: Mon, 6 Jan 2025 10:52:24 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v1] ioreq: allow arch_vcpu_ioreq_completion() to
 signal an error
To: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
Cc: xen-devel@lists.xenproject.org, Andrew Cooper
 <andrew.cooper3@citrix.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>
References: <20241220093514.3094521-1-Sergiy_Kibrik@epam.com>
 <alpine.DEB.2.22.394.2501021136490.16425@ubuntu-linux-20-04-desktop>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <alpine.DEB.2.22.394.2501021136490.16425@ubuntu-linux-20-04-desktop>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 02.01.2025 20:36, Stefano Stabellini wrote:
> On Fri, 20 Dec 2024, Sergiy Kibrik wrote:
>> Return false from arch_vcpu_ioreq_completion() when completion is not handled.
>> According to coding-best-practices.pandoc an error should be propagated to
>> caller, if caller is expecting to handle it, which seems to the case for
>> callers of arch_vcpu_ioreq_completion().
>>
>> Suggested-by: Jan Beulich <jbeulich@suse.com>
>> Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
> 
> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>

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




From xen-devel-bounces@lists.xenproject.org Mon Jan 06 09:58:24 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 09:58:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865624.1276869 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUjsK-00051K-H8; Mon, 06 Jan 2025 09:58:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865624.1276869; Mon, 06 Jan 2025 09:58:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUjsK-00051D-EO; Mon, 06 Jan 2025 09:58:20 +0000
Received: by outflank-mailman (input) for mailman id 865624;
 Mon, 06 Jan 2025 09:58:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=9khw=T6=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tUjsJ-000515-Dy
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 09:58:19 +0000
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com
 [2a00:1450:4864:20::335])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c0964890-cc14-11ef-99a4-01e77a169b0f;
 Mon, 06 Jan 2025 10:58:17 +0100 (CET)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-43635796b48so85292025e9.0
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 01:58:17 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c832e53sm47233216f8f.27.2025.01.06.01.58.16
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 06 Jan 2025 01:58:16 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c0964890-cc14-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736157497; x=1736762297; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=YFR5XrTJw5dYAKEH2bpp5Y5GfW32/ArmHpb8Y9iaWBw=;
        b=LBvXykIObFrWv0wqcQKndVy2xAyFcw4VA3s+kIWD5LLpRFltRw3BT07sK7T4bq89XL
         307rUpbtb59rO5+v6dTRTuP6/oYO5DOu6bSbyAUhHMByoLEV3aAeRcJvvxiCIH0M+OLY
         Cn5X8+e6efdNXAwnqvRZTpfYBFFjchMLj4FqYKE6Vc2UgWWss37g4X1buSpIKMQjpJh4
         t5cQiCqKQ61Hu6OgVsk2KNLbSxb5jIi9Xwl1wTFUpVDu5hZ3+WJJXrW9zV93S501dXvJ
         IUEqGApdwEDuHz1b8RHPMMaC0zYxw+BkF01IjwYH4lbbo91IiDFmQdp+9YsxRerM2Tas
         O6fA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736157497; x=1736762297;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=YFR5XrTJw5dYAKEH2bpp5Y5GfW32/ArmHpb8Y9iaWBw=;
        b=hUjeYUi9RDL/9ECWVqxME8uWx/NuzDz1xmOVUzqRJAxPwBcfEFDGkZQbsrtYEJrtCu
         WKq4rFVLPrhl/3OSOAUEZLmsIXQ7G6fiumwgfxE7CMEz3aMf8R9GH/HM6q9p6uIINaXW
         l7rSckUweGJ2pxt4gTgmWkUvT64edoi2odsO9SDpLVwMtFUKUs8VTpVsvi6uT8iT5q0Q
         MRwgocT66qNwnhBGLIPt3P7OwdOfCsWs23phYNSmnINp+WfNGfsFUH1d2u1YiY7BCnje
         jvx+C7sc+dPFOtjfmeuWDh3XZbc6dt1lpiJYFaLxOkA8Uc4FhNsOqgvg64gvg+Mn73xx
         7lQw==
X-Forwarded-Encrypted: i=1; AJvYcCU8ChNHM2sF88f9RWLEuyD6meJyR9RjsV0Uaxh5UuFYQ/4afivUrSzK/mQtmC2PPMG04lmdvamGQH8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwtyXHiKLAsYhTrj0rUY7MKpBkj7K+QO6X84d1igm30ic5pYV1k
	ZfwhU7X9CJZUq9GsT4Bto5VtLGkVKsP+ecratUrXteCUUug/IajjX+qiRCC5Aw==
X-Gm-Gg: ASbGncti9TARRJVXMaZMqQ64bfIWPpOo8MCB8qZfRXFsvtNGNeez+aAfy8+sr6RKv9i
	QyErw2TlSjJ9eLOyy4xk9MmSqq/QkcNUV/2W9RrJGrcnFXv1TY4yOmtJwB0QcLnJlkwZd6MHuaB
	FQyw4fYkF7pxHQs+Kybxt+2p1OVKCoN2ThpmNWJnFHx4C7rycSvQny8rTBX9V433q2WfYtJZs7l
	IROp/bEy9ajmKdZTXwohx/YXSyJ50geyWRJRoce60IiUUBWoc2vA/W2wZzk8uEA62qtwk9BRNXT
	pcCKeOq/vUojsJcCw8ycx4CjprWltIFyHJWncXEd2w==
X-Google-Smtp-Source: AGHT+IFET3J/uyDf+rD2KZLDszy8WWR+VFqyCRSQLrhgqzJ892PYZQCd3pVqHgQkkjFGH+rI+Edu/w==
X-Received: by 2002:a05:600c:474f:b0:434:ff08:202e with SMTP id 5b1f17b1804b1-43682a402ecmr357824765e9.8.1736157496897;
        Mon, 06 Jan 2025 01:58:16 -0800 (PST)
Message-ID: <3b9635bc-e196-4a7e-95ea-277172ae052a@suse.com>
Date: Mon, 6 Jan 2025 10:58:23 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 19/35] xen/console: introduce console_set_owner()
To: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-19-e9aa923127eb@ford.com>
 <Z1q3COsFN3J9G60E@macbook.local>
 <Nzs8m4tgOs8mh44axM9sAfsp2GGMk34p5Oi0dtXh8rLbKzHXmMtMXK_d_AJy-gSQuGRygaZbsvhy9QFvsCc0yyMiqzXslUNID1os1CCzNrA=@proton.me>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <Nzs8m4tgOs8mh44axM9sAfsp2GGMk34p5Oi0dtXh8rLbKzHXmMtMXK_d_AJy-gSQuGRygaZbsvhy9QFvsCc0yyMiqzXslUNID1os1CCzNrA=@proton.me>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 04.01.2025 04:30, Denis Mukhin wrote:
> On Thursday, December 12th, 2024 at 2:12 AM, Roger Pau Monné <roger.pau@citrix.com> wrote:
>> On Thu, Dec 05, 2024 at 08:41:49PM -0800, Denis Mukhin via B4 Relay wrote:
>>> --- a/xen/drivers/char/console.c
>>> +++ b/xen/drivers/char/console.c
>>> @@ -463,82 +463,100 @@ static void cf_check dump_console_ring_key(unsigned char key)
>>>
>>> /*
>>> * CTRL-<switch_char> changes input direction, rotating among Xen, Dom0,
>>> - * and the DomUs started from Xen at boot.
>>> + * and the DomUs.
>>> /
>>> #define switch_code (opt_conswitch[0]-'a'+1)
>>> +
>>> /
>>> - * console_owner=0 => input to xen
>>> - * console_owner=1 => input to dom0 (or the sole shim domain)
>>> - * console_owner=N => input to dom(N-1)
>>> + * Current console owner domain ID: either Xen or domain w/ d->is_console ==
>>> + * true.
>>> + *
>>> + * Initialized in console_endboot().
>>> */
>>> -static unsigned int __read_mostly console_owner = 0;
>>> +static domid_t __read_mostly console_owner;
>>
>>
>> Should this be initialized to DOMID_XEN? I assume it doesn't make
>> much difference because the variable is not checked before
>> console_endboot() anyway, but it might be safer to initialize to a
>> value that assigns the console to Xen.
> 
> Fixed.
> 
>>
>>> -#define max_console_rx (max_init_domid + 1)
>>> +static struct domain *rcu_lock_domain_console_by_id(domid_t domid)
>>> +{
>>> + struct domain *d;
>>> +
>>> + d = rcu_lock_domain_by_id(domid);
>>> +
>>
>>
>> Nit: I would remove this newline.
> 
> Fixed.
> 
>>
>>> + if ( d == NULL )
>>> + return NULL;
>>> +
>>> + if ( d->is_console )
>>> + return d;
>>> +
>>> + rcu_unlock_domain(d);
>>> +
>>> + return NULL;
>>> +}
>>>
>>> -#ifdef CONFIG_SBSA_VUART_CONSOLE
>>> /* Make sure to rcu_unlock_domain after use */
>>> struct domain *rcu_lock_domain_console_owner(void)
>>> {
>>> - if ( console_owner == 0 )
>>> - return NULL;
>>> - return rcu_lock_domain_by_id(console_owner - 1);
>>> + return rcu_lock_domain_console_by_id(console_owner);
>>> }
>>> -#endif
>>>
>>> -static void console_find_owner(void)
>>> +static bool console_owner_possible(domid_t domid)
>>> {
>>> - unsigned int next_rx = console_owner;
>>> -
>>> - /*
>>> - * Rotate among Xen, dom0 and boot-time created domUs while skipping
>>> - * switching serial input to non existing domains.
>>> - /
>>> - for ( ; ; )
>>> - {
>>> - domid_t domid;
>>> - struct domain d;
>>> -
>>> - if ( next_rx++ >= max_console_rx )
>>> - {
>>> - console_owner = 0;
>>> - printk("* Serial input to Xen");
>>> - break;
>>> - }
>>> -
>>> - if ( consoled_is_enabled() && next_rx == 1 )
>>> - domid = get_initial_domain_id();
>>> - else
>>> - domid = next_rx - 1;
>>> -
>>> - d = rcu_lock_domain_by_id(domid);
>>> - if ( d == NULL )
>>> - continue;
>>> -
>>> - if ( d->is_console )
>>> - {
>>> - rcu_unlock_domain(d);
>>> - console_owner = next_rx;
>>> - printk("*** Serial input to DOM%u", domid);
>>> - break;
>>> - }
>>> + struct domain *d;
>>>
>>> + d = rcu_lock_domain_console_by_id(domid);
>>> + if ( d != NULL )
>>> rcu_unlock_domain(d);
>>> - }
>>> +
>>> + return d != NULL;
>>> +}
>>> +
>>> +int console_set_owner(domid_t domid)
>>> +{
>>> + if ( domid == DOMID_XEN )
>>> + printk("*** Serial input to Xen");
>>> + else if ( console_owner_possible(domid) )
>>> + printk("*** Serial input to DOM%u", domid);
>>> + else
>>> + return -ENOENT;
>>> +
>>> + console_owner = domid;
>>>
>>> if ( switch_code )
>>> printk(" (type 'CTRL-%c' three times to switch input)",
>>> opt_conswitch[0]);
>>> printk("\n");
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +/*
>>> + * Switch console input focus.
>>> + * Rotates input focus among Xen, dom0 and boot-time created domUs while
>>> + * skipping switching serial input to non existing domains.
>>> + */
>>> +static void console_find_owner(void)
>>> +{
>>> + domid_t i, n = max_init_domid + 1;
>>
>>
>> n can be made const, I would even rename to nr for clarity, but that's
>> personal taste.
> 
> `max_init_domid` can change at run-time actually (e.g. after `xl create`).
> I kept `n` as is.

How does max_init_domid potentially changing affect (possible) const-ness of n?

However it changing, ...

>>> +
>>> + if ( console_owner == DOMID_XEN )
>>> + i = get_initial_domain_id();
>>> + else
>>> + i = console_owner + 1;
>>> +
>>> + for ( ; i < n; i++ )
>>> + if ( !console_set_owner(i) )
>>> + break;
>>
>>
>> Hm, that could be a non-trivial amount of iteration if max_init_domid
>> is bumped for every domain created as you have it in patch 11/35
>> (albeit I'm not sure that was intended?)
> 
> Yes, `max_init_domid` is advanced on each domain creation (v3).

... as you confirm here, undermines what it's used for right now (if I'm
not mistaken), and would render the variable misnamed.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 06 10:16:39 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 10:16:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865632.1276878 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUk9v-0008NR-VV; Mon, 06 Jan 2025 10:16:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865632.1276878; Mon, 06 Jan 2025 10:16:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUk9v-0008NK-Sk; Mon, 06 Jan 2025 10:16:31 +0000
Received: by outflank-mailman (input) for mailman id 865632;
 Mon, 06 Jan 2025 10:16:30 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=9khw=T6=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tUk9u-0008NE-L9
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 10:16:30 +0000
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com
 [2a00:1450:4864:20::32e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4ad7ead3-cc17-11ef-99a4-01e77a169b0f;
 Mon, 06 Jan 2025 11:16:28 +0100 (CET)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-4361e89b6daso97168775e9.3
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 02:16:28 -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
 5b1f17b1804b1-436604e9c2csm564212475e9.43.2025.01.06.02.16.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 06 Jan 2025 02:16:27 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 4ad7ead3-cc17-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736158588; x=1736763388; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=4EhysA5vxf8/t+mhDzBIb4/H2MJ8QdQgnYT2PRiwSS0=;
        b=D+CbkFnA65xDvd0ecvra0Q7oTxq+IbxiRCSyTZwYkFkyO9zYmLIvLr0noTbk7w9nVE
         q8BKBqi5aqC1jfx3ZXbpllkcfIovgq1N9B0dwUXwr3i3wtBNNP9Ip8KMKanREN0GVb/g
         3LhgzuT7U7FZSuBienxV9jgwoMi8XmuTYU/5YRbkWPrV+n28gzlIGa+ZdzMeMdFVSpdW
         Bzs5gOv/2dBfr/Eg6REnrleuJRbRIXRJ/XNHHfQaJFqO3eKavIi4KomTLl4IMA5cAHKc
         PI8DQOmuINq0XS3zWdkbekfjyHkO03vxmMmS/EnHD6i1Ng/7BRK7bYNwpWdyrsiw2XTC
         SNSw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736158588; x=1736763388;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=4EhysA5vxf8/t+mhDzBIb4/H2MJ8QdQgnYT2PRiwSS0=;
        b=nfyDGZBvmO+DfoCtULNmOtSqQqDz98B/zJVWxV8t1RijEG41U8G2SenH/M3iTKg/pz
         pk4nDaOGWOH3dDsn4JUFGeL6GhxIQkGhifXVtyz/U6kkgion76BI3IzjmFK0CFFi7Weh
         Bv9Aql3QRn/rlZn6f0qBaVUF35H8kI5gbMZowbkQZl7tdFkwaVtSW14X9olQGOi/fbt2
         nL1vN4tMqJkaXSxfhb+GMNq214jfJWWe1ZzcDSbWRbpMV36f0FfSHt8Esh0NGR9eQiQj
         RT/t1GV3WlfY7V6QkBQXdH6yZ5yaMvWddDc+fcuh1SR1ew6zOBU/50sHBlRgU9LEOMLr
         Ynnw==
X-Forwarded-Encrypted: i=1; AJvYcCXikb8st4FBRNmUiwr9YG4Rmw0nonCyKkKgkp1LKGyxtysBqzG2TNggTe4wBE2xFAoQGNZ832iDso4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyBbcoYRMZljsg6EActh49mZqvtnSS33HUeiqJGa7bBYhcW6QCE
	WwVZVdU63vGJXkdYn2jB/5PJgn7z3Ny1Pse6l9g1efKpV+ewSBdS8pMfoKWI0A==
X-Gm-Gg: ASbGnctsTc8E5WKfHkPr+mQPOlP5Nbu8PX0aQAkTY3MjPzHEdFYPtOR/uGmmVv1KpbN
	feiQ5Iy6WloPybzmUeawFtlo2aydM0z/pCB78E/+2UTkBTBeSkF7B5bkeNDsZ+k2IqQoDgyxMuT
	03jufAMRFV40dc8TKkdrb6koDGoPiDE/u6pBk0efj4wfmxWF/f6OsiZSzAoB4IAaDA/asFCi0Sr
	YEdvU7PgFFDXW/tP64I6xJvG1v5GlLWZBD1stXlXaNSy/0N+P82EtonnY4ueSv3Y54BXduUwVFs
	NW4nWP/51Opx/EhSXrGJLq7QWjTX0bbcHISLfc5OaQ==
X-Google-Smtp-Source: AGHT+IFegCytHadH/Bsuu9OAOKvDO/4OPXNOv27Rj0veS0i7+S9KRm4NriSbJAoYV5LdQNlcVtPDRA==
X-Received: by 2002:a05:600c:5246:b0:42c:bb96:340e with SMTP id 5b1f17b1804b1-43668b7857amr529670425e9.31.1736158587859;
        Mon, 06 Jan 2025 02:16:27 -0800 (PST)
Message-ID: <c8684340-33f9-41d3-94e4-77ee3bc18306@suse.com>
Date: Mon, 6 Jan 2025 11:16:33 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v1] xen: mem_access: conditionally compile vm_event.c
 & monitor.c
To: Sergiy Kibrik <Sergiy_Kibrik@epam.com>,
 Tamas K Lengyel <tamas@tklengyel.com>,
 Stefano Stabellini <stefano.stabellini@amd.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
 <julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Alexandru Isaila <aisaila@bitdefender.com>,
 Petre Pircalabu <ppircalabu@bitdefender.com>, xen-devel@lists.xenproject.org
References: <20241230063051.3332332-1-Sergiy_Kibrik@epam.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20241230063051.3332332-1-Sergiy_Kibrik@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 30.12.2024 07:30, Sergiy Kibrik wrote:
> From: Stefano Stabellini <stefano.stabellini@amd.com>
> 
> Extend coverage of CONFIG_MEM_ACCESS option and make the build of VM events
> and monitoring support optional.

Yet doesn't this end up in things becoming misleading? Don't we rather need a
2nd Kconfig option, with a dependency between the two? Or alternatively a
rename of the existing option (to describe the higher-level feature rather
than the lower level one)? Tamas, I'm particularly interested in knowing your
view here as well.

Jan

> This is to reduce code size on Arm when this option isn't enabled.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
> Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
> ---
>  xen/arch/arm/Makefile      |  4 ++--
>  xen/arch/arm/vsmc.c        |  3 ++-
>  xen/common/Makefile        |  4 ++--
>  xen/include/xen/monitor.h  |  9 +++++++++
>  xen/include/xen/vm_event.h | 14 +++++++++++---
>  5 files changed, 26 insertions(+), 8 deletions(-)
> 
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index 43ab5e8f25..8903eb0bf2 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -39,7 +39,7 @@ obj-$(CONFIG_LIVEPATCH) += livepatch.o
>  obj-$(CONFIG_LLC_COLORING) += llc-coloring.o
>  obj-$(CONFIG_MEM_ACCESS) += mem_access.o
>  obj-y += mm.o
> -obj-y += monitor.o
> +obj-$(CONFIG_MEM_ACCESS) += monitor.o
>  obj-y += p2m.o
>  obj-y += platform.o
>  obj-y += platform_hypercall.o
> @@ -65,7 +65,7 @@ obj-$(CONFIG_VGICV2) += vgic-v2.o
>  obj-$(CONFIG_GICV3) += vgic-v3.o
>  obj-$(CONFIG_HAS_ITS) += vgic-v3-its.o
>  endif
> -obj-y += vm_event.o
> +obj-$(CONFIG_MEM_ACCESS) += vm_event.o
>  obj-y += vtimer.o
>  obj-$(CONFIG_SBSA_VUART_CONSOLE) += vpl011.o
>  obj-y += vsmc.o
> diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
> index 62d8117a12..1c13326bdf 100644
> --- a/xen/arch/arm/vsmc.c
> +++ b/xen/arch/arm/vsmc.c
> @@ -330,7 +330,8 @@ void do_trap_smc(struct cpu_user_regs *regs, const union hsr hsr)
>      }
>  
>      /* If monitor is enabled, let it handle the call. */
> -    if ( current->domain->arch.monitor.privileged_call_enabled )
> +    if ( IS_ENABLED(CONFIG_MEM_ACCESS) &&
> +         current->domain->arch.monitor.privileged_call_enabled )
>          rc = monitor_smc();
>  
>      if ( rc == 1 )
> diff --git a/xen/common/Makefile b/xen/common/Makefile
> index cba3b32733..e3c6a857ab 100644
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -54,7 +54,7 @@ obj-y += timer.o
>  obj-$(CONFIG_TRACEBUFFER) += trace.o
>  obj-y += version.o
>  obj-y += virtual_region.o
> -obj-y += vm_event.o
> +obj-$(CONFIG_MEM_ACCESS) += vm_event.o
>  obj-$(CONFIG_HAS_VMAP) += vmap.o
>  obj-y += vsprintf.o
>  obj-y += wait.o
> @@ -68,7 +68,7 @@ obj-$(CONFIG_COMPAT) += $(addprefix compat/,domain.o memory.o multicall.o xlat.o
>  
>  ifneq ($(CONFIG_PV_SHIM_EXCLUSIVE),y)
>  obj-y += domctl.o
> -obj-y += monitor.o
> +obj-$(CONFIG_MEM_ACCESS) += monitor.o
>  obj-y += sysctl.o
>  endif
>  
> diff --git a/xen/include/xen/monitor.h b/xen/include/xen/monitor.h
> index 713d54f7c1..f1359abb94 100644
> --- a/xen/include/xen/monitor.h
> +++ b/xen/include/xen/monitor.h
> @@ -27,8 +27,17 @@
>  struct domain;
>  struct xen_domctl_monitor_op;
>  
> +#ifdef CONFIG_MEM_ACCESS
>  int monitor_domctl(struct domain *d, struct xen_domctl_monitor_op *mop);
>  void monitor_guest_request(void);
> +#else
> +static inline int monitor_domctl(struct domain *d,
> +                                 struct xen_domctl_monitor_op *mop)
> +{
> +    return -EINVAL;
> +}
> +static inline void monitor_guest_request(void) {}
> +#endif
>  
>  int monitor_traps(struct vcpu *v, bool sync, vm_event_request_t *req);
>  
> diff --git a/xen/include/xen/vm_event.h b/xen/include/xen/vm_event.h
> index 9a86358b42..72e720e378 100644
> --- a/xen/include/xen/vm_event.h
> +++ b/xen/include/xen/vm_event.h
> @@ -50,9 +50,6 @@ struct vm_event_domain
>      unsigned int last_vcpu_wake_up;
>  };
>  
> -/* Clean up on domain destruction */
> -void vm_event_cleanup(struct domain *d);
> -
>  /* Returns whether a ring has been set up */
>  bool vm_event_check_ring(struct vm_event_domain *ved);
>  
> @@ -88,7 +85,18 @@ void vm_event_cancel_slot(struct domain *d, struct vm_event_domain *ved);
>  void vm_event_put_request(struct domain *d, struct vm_event_domain *ved,
>                            vm_event_request_t *req);
>  
> +#ifdef CONFIG_MEM_ACCESS
> +/* Clean up on domain destruction */
> +void vm_event_cleanup(struct domain *d);
>  int vm_event_domctl(struct domain *d, struct xen_domctl_vm_event_op *vec);
> +#else
> +static inline void vm_event_cleanup(struct domain *d) {}
> +static inline int vm_event_domctl(struct domain *d,
> +                                  struct xen_domctl_vm_event_op *vec)
> +{
> +    return -EINVAL;
> +}
> +#endif
>  
>  void vm_event_vcpu_pause(struct vcpu *v);
>  void vm_event_vcpu_unpause(struct vcpu *v);



From xen-devel-bounces@lists.xenproject.org Mon Jan 06 10:20:40 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 10:20:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865640.1276889 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUkDi-0001RL-EG; Mon, 06 Jan 2025 10:20:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865640.1276889; Mon, 06 Jan 2025 10:20:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUkDi-0001RE-Bf; Mon, 06 Jan 2025 10:20:26 +0000
Received: by outflank-mailman (input) for mailman id 865640;
 Mon, 06 Jan 2025 10:20:26 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=9khw=T6=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tUkDi-0001R8-2l
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 10:20:26 +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 d76735f4-cc17-11ef-a0df-8be0dac302b0;
 Mon, 06 Jan 2025 11:20:24 +0100 (CET)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-436637e8c8dso144353535e9.1
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 02:20:24 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4366a093cbfsm539374875e9.22.2025.01.06.02.20.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 06 Jan 2025 02:20:23 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: d76735f4-cc17-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736158824; x=1736763624; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=bFyQuwIqv4EbMtPoPGmZSdTwN9m/YTeWqwZFZdjXaGg=;
        b=baJLAP8vjhI808hX/wUB+LasTAcp7mXltFZYakZ3Q+lsGCxKMlt8gVSF15yEX2G/1J
         razzimHE1Nmwi4XbnYEwCXBI1vPLX09H/gSbLzedomvhF/64yAqp3nnDIu5866+rHxq0
         eEEo15zvp2OB/Mepg0r/qkSewG4kc14a+f82HTf1b1//XMLwOoJSFlRJfXGf4T7JbJq0
         Varr1VEkAIHmJPalLVmzeDRjkirqErOD8FkR8KjHephxNfs8gjEtepTL0woOZgpuzJgx
         joRqBUEqIWWUonj8GgHJe9WmqGmntNbkOLGYKMtZiIFo+3k3/ASayJcVp+4Ekce8oEZU
         X+GA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736158824; x=1736763624;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=bFyQuwIqv4EbMtPoPGmZSdTwN9m/YTeWqwZFZdjXaGg=;
        b=t22pc9soOff5OIb5B4H5foVFwdkKwNl+e8gRvZ6KgnpMC5LRkDmqovHzKAG9taxL7p
         /YqDlH3CY1y3w94OpsyqEi4Pc0/8kOgon+/l05isiveDdYEu0KU6fwQdz154Uhybpeg1
         8aIQaxBv96Z4QyijSlLq4QwJVU6iu0hYExm/hZGgwi2zHFsO9fYvL6c5uvAAxJl2NBe9
         T5qNGWgpbwE8R02K4inUlbzOXhvMS/U+rtE0tv3gHc2hy8gb7zbRfNZ6Lw6H9ICA5vGU
         CXFh7lxThk33+4zwHeZIlK+JDwea9LC9K/2vp2uMVl6DlQXE+EHqpi/Ti5ZZEiiZlzLj
         DPxg==
X-Forwarded-Encrypted: i=1; AJvYcCWYmWfqiWCvXC7c+2krGGRx6NX7C6B1y3+RA6KmG1MU1vQzrhCRTY8PqdQMmMxjbPzTOz2i7yqtQRQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxWeOf+tps0nunThrPniJi4ocSLkjCxqfxomyep5rOjKBlUU2yN
	o2rdIHiDKQvG7+slyfO+MkgNafvZgt+3N1Z6vOmGmY8iL05+S4c04ntLSzrfiQ==
X-Gm-Gg: ASbGncvgPSo6kQ5BH801deviwZ70gY1AT/x/CJMxlABUPLM8sctobxgZxULNp5oqFvA
	eFb4JrYsua1se4pjQu6g6zWmS8jM+eokHdXNdvz236iju2qX4zdMUeFhF1vHx9Edl3skpHqsFs6
	0cSnyBU9fOrJgNFJ0eAYPSS+WXY+rdc3CvByHuHbihBsOCv79kavxCEaUT0shWzLcXvgwUYf/Ll
	KkckhsW7/ZQOvPlI+LeccAeXSRcLGSOELf9Y2OD1ytjNJnr0a7nIBAYnbYp9WxDs9Dx7LGt3luT
	6ddT/RXyOdW6+v8MgYh/JQdXBfTwXNLBknKE296oxg==
X-Google-Smtp-Source: AGHT+IG8KMgcQv6bJNIHFWgbD6cQqqbpttQ1x/PH0JHK55khFrE2WIxQf4pWUpPMGv6F3p0W/w+D/w==
X-Received: by 2002:a05:600c:294c:b0:436:51bb:7a53 with SMTP id 5b1f17b1804b1-43668643ba9mr512716245e9.12.1736158823734;
        Mon, 06 Jan 2025 02:20:23 -0800 (PST)
Message-ID: <10d1330d-45c9-4433-9ba3-b5498999cda5@suse.com>
Date: Mon, 6 Jan 2025 11:20:30 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 3/5] xen/arch/x86: make objdump output user locale
 agnostic
To: Maximilian Engelhardt <maxi@daemonizer.de>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <cover.1735585600.git.maxi@daemonizer.de>
 <c86ce036f829a9e626c8d1dfc595c6caf6c48212.1735585600.git.maxi@daemonizer.de>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <c86ce036f829a9e626c8d1dfc595c6caf6c48212.1735585600.git.maxi@daemonizer.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 30.12.2024 22:00, Maximilian Engelhardt wrote:
> The objdump output is fed to grep, so make sure it doesn't change with
> different user locales and break the grep parsing.
> This problem was identified while updating xen in Debian and the fix is
> needed for generating reproducible builds in varying environments.

It required me to check objdump (really: libbfd) source code to figure that
it's ...

> --- a/xen/arch/x86/arch.mk
> +++ b/xen/arch/x86/arch.mk
> @@ -109,7 +109,7 @@ endif
>  ifeq ($(XEN_BUILD_PE),y)
>  
>  # Check if the linker produces fixups in PE by default
> -efi-nr-fixups := $(shell $(OBJDUMP) -p $(efi-check).efi | grep '^[[:blank:]]*reloc[[:blank:]]*[0-9][[:blank:]].*DIR64$$' | wc -l)
> +efi-nr-fixups := $(shell LC_ALL=C $(OBJDUMP) -p $(efi-check).efi | grep '^[[:blank:]]*reloc[[:blank:]]*[0-9][[:blank:]].*DIR64$$' | wc -l)

... the "reloc" in here which (oddly enough) may be subject to translation.
Would have been nice if such a relevant detail had been added to the
description.

Jan



From xen-devel-bounces@lists.xenproject.org Mon Jan 06 10:29:24 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 10:29:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865651.1276899 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUkMJ-0002TR-9T; Mon, 06 Jan 2025 10:29:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865651.1276899; Mon, 06 Jan 2025 10:29:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUkMJ-0002TK-6q; Mon, 06 Jan 2025 10:29:19 +0000
Received: by outflank-mailman (input) for mailman id 865651;
 Mon, 06 Jan 2025 10:29: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 <SRS0=9khw=T6=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tUkMI-0002TE-G8
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 10:29:18 +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 14fa6a07-cc19-11ef-a0df-8be0dac302b0;
 Mon, 06 Jan 2025 11:29:17 +0100 (CET)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-385f07cd1a4so9338368f8f.1
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 02:29:17 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a457584bcsm30289443f8f.89.2025.01.06.02.29.15
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 06 Jan 2025 02:29:16 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 14fa6a07-cc19-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736159356; x=1736764156; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=fxfnN7CdCR0nQJIFy5YImJRGZNHu/ZD0fBmXIdkSJRg=;
        b=WpIBLpbSjqTO046eu3xNeBH4R+pi9TEGEI/g/2YOgK81fO9t0dDarfYm63dwy5OVPS
         CbjlDis+2O4/0G4LJldQ+sYIWqbZV2nQohdlR3kRohbH/Tn03DcNED2q6nflvKo0xgFg
         dzoiiLmWXnbj2HgvZsAkpypTocsmN3Grckwxg1LBY/G+ScVrOc22Kgu3hvry05oyjCmr
         nhm7MBwAGxo2z5vMbuIJy/6DXIzhD/28bmegcUF/Msyei+xV69qAXRV/1l8ahd1igTgu
         O/h8M6UBeEHSlZLgtIEAPui/N7kRfuR5oNtUcz4Gk0V5pUmBAy81xohL3YisGHMzROJb
         tCIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736159356; x=1736764156;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=fxfnN7CdCR0nQJIFy5YImJRGZNHu/ZD0fBmXIdkSJRg=;
        b=eQpXi4SzHDLsCzwLggK8ILHLc1xboGStDqD5jPoevnNN2IE4u0pROSojPxIesWHFtq
         DVGoiOkqTTCRAYTFqHKPnoaje5tkEQV+QsMmfiqFE4J2y++nBKW82hpVO6KFOgJB9Uu+
         KHtGYJ2vs1A0crzyBeWVmSXzf25GYsH0YIEuUc4KaUd4zHGB0DTnfZ/OqdJnl8INAZwZ
         Fog/W0dc7FOpZPvanpgU3u8zdMmvbPlI1PQRfkXN7eQwOBabZB3PRWZzOz93PegcEfsH
         IenqFtM73j+T6H7LDs5q/rMmjXMnuro9OprwkzmnTnoIehefyflNEKDBXUxfqZIwBJ7A
         TDZA==
X-Forwarded-Encrypted: i=1; AJvYcCVjnlQX2fahQvV3A86+wTM1wVdbB8aa2HCn7HwyjG8ovreOEwCPkvA2I04WjYEBncBrEQAW+awRpLc=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz4pCWVFYXVye721vrvb95stNU9QADNnXn2lCMuhSu9TJ1ns72o
	cbXr965JdZOxeQOs0SoazDP8B9HfZ6dNR/3E0sKACAOR9gYAiDyz97svY08opQ==
X-Gm-Gg: ASbGncthUVS8HqMkyAU3u6+NV5ILuGP/1UoOTUNBMVYIxsRfI5HcliIwmZVSESkhCHr
	WPCbrGMkR+4LAgIEa9vwDqLjadPcj6kyD12lYjhBv5OjNedfdSfGTsKjM5T3KGGYSYUVR+iuEvA
	S5760+XxivEzVmapUO5fq+JwbDMUQPCPCYRi0kzWmToNff78IeNeGvSt2o8MwTLD0bZUMl0Ii95
	7PyG6Nekf2ePo/a91447gCH8Qbc+6hfvkktsgHSYTZ2eq9kwewHlIo5kzw5XexEeF2aObPjPNFR
	H+jjM3rpRIrF8jnQIJC6o4xGJSkWK43rEqEh7YbeAQ==
X-Google-Smtp-Source: AGHT+IEqBEnJpM87IDIi90dtOMIshDN8Z9UhS/RLNcWG3gebi+GG1S0LQIgj5pBmuYDGqz9jjep6dA==
X-Received: by 2002:a05:6000:18a8:b0:385:f7d2:7e29 with SMTP id ffacd0b85a97d-38a221ea539mr47606151f8f.15.1736159356595;
        Mon, 06 Jan 2025 02:29:16 -0800 (PST)
Message-ID: <fc0b1bfd-9673-4ceb-9689-b7d4b7838d79@suse.com>
Date: Mon, 6 Jan 2025 11:29:23 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/5] xen/perfc: Add perfc_defn.h to asm-generic
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>,
 Shawn Anastasio <sanastasio@raptorengineering.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20250102192508.2405687-1-andrew.cooper3@citrix.com>
 <20250102192508.2405687-3-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250102192508.2405687-3-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 02.01.2025 20:25, Andrew Cooper wrote:
> ... and hook it up for RISC-V and PPC.
> 
> On RISC-V at least, no combination of headers pulls in errno.h, so include it
> explicitly.
> 
> Guard the hypercalls array declaration based on NR_hypercalls existing.  This
> is sufficient to get PERF_COUNTERS fully working on RISC-V and PPC, so drop
> the randconfig override.

And then perhaps also that from riscv64_defconfig?

> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Preferably with the added change:
Reviewed-by: Jan Beulich <jbeulich@suse.com>

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 06 10:32:48 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 10:32:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865658.1276909 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUkPe-0004Ha-PG; Mon, 06 Jan 2025 10:32:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865658.1276909; Mon, 06 Jan 2025 10:32:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUkPe-0004HT-LQ; Mon, 06 Jan 2025 10:32:46 +0000
Received: by outflank-mailman (input) for mailman id 865658;
 Mon, 06 Jan 2025 10:32: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 <SRS0=9khw=T6=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tUkPd-0004HN-7j
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 10:32:45 +0000
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com
 [2a00:1450:4864:20::432])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8fb8fdba-cc19-11ef-99a4-01e77a169b0f;
 Mon, 06 Jan 2025 11:32:43 +0100 (CET)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-385eed29d17so6689328f8f.0
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 02:32:43 -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
 ffacd0b85a97d-38a1c89e43dsm48316262f8f.70.2025.01.06.02.32.41
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 06 Jan 2025 02:32:42 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8fb8fdba-cc19-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736159562; x=1736764362; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=b000T26MrIM2i9K9ongnpnfhmN/t2W9V0DgkR7Eu9A8=;
        b=KBaXG+q9hK+akFMK4EZ4C7n74FclIY7ACIJr0AG8wDtApvTRYNVdzGuCPj+Sgev4z5
         YsmhCqsCTcK+q00rWj5S7K5IN9Q3wtdMxFzgK0gm6bIALPuxFX0LpHkKe+EFoUy2EE0o
         KMRtKCWpHvj7LZ0UifRuEXjRUr/l52h459iM8lWOo9w6wl/rv0IS+lNE0Vd29szP0rRo
         TyBUUxLUckNcJyuuFMUFy9EtWaEmK4x+HU9DMkmSovCkvSAjphr7O2jXnfhVAM7rZ8ac
         OP1Ps7kwziG1QdBpw1WxBffIHYJNxy7ZND8/KVrHCuGmTvIaw7/YeszTndJCd72SZ59s
         RR2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736159562; x=1736764362;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=b000T26MrIM2i9K9ongnpnfhmN/t2W9V0DgkR7Eu9A8=;
        b=hTTXQodhOCo6YYO8FJnKspF+VAQWfeOXGCGr3+Q2Mvv/eAXxRV7Kbv/ysfWG8jnwql
         7cFruJxETUNZfPXgFgjp9+3CauJO8KX+gK2Sb7FiCXdqNKwwn5TU11gMzCAb69rjVmLb
         nMk0jyiwV9sy7yD56TJLXOQMwD6umsvCoYJITH8EQoJS+3Ji8Q45+QE1n2hyXdMR1XjF
         40uPjgwbVaA65v00dR8POfV76VwpC5eedZA/MDsxHQYpKsRQNJ5JLR4cgsP3KWPh36HH
         xGo+XGRPgVgq4KcJFukr0DaNhGQRv1eE24hu6/JcAJskRHQFbFu3dhVwG6ZO9g7wBNYA
         QMVQ==
X-Forwarded-Encrypted: i=1; AJvYcCU7aTZE6gtWVU4drM0PljUy00PDg9EJYZ8euGo6wjo/XIUmy1Qg+GkahmCynR6nZOfHjzh7i/apW7c=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyRshEzepnnL0EjrgqVW5o1P6XUxe7g/QEq876jBtkSXP7Sxfgo
	/mpV27U24YTijeaQBQjklEtABpBhahb/iJXKbTl3Oj/bCCx+2wrV6HfC3e80Dg==
X-Gm-Gg: ASbGncvRUYWMryrH8bav0EpkttpANoo0HYEew1M28eZok51ZfHAFoi3HrPKzLTCpunG
	cGkQ13PuHDV9e2yErXTd38I664AY8+ydSagWhIsMj5Qe7uOSOqGHvzmwr71OhaijjyNeWcwqFro
	3gqOd6TPzK7fsRDJ3nq4si4AE/3FBF9VUjs6dSL1+gZFU/sWlJZpRLJrLEDO+vTEzlDba9Fxsxu
	2n5CkDv2HSONGLpg/5ALpJ6y0xNtXmi+oel80vmnI1Jkv3I0FMvF0iyJmH2rJx9Qu7up2wl89eL
	84TGJaM72h4DO28I41Fhty02/grdliEQvEHRz3lD4g==
X-Google-Smtp-Source: AGHT+IFG+TcUIS8tmhSFsHZqKub2NXNyRBahLa5Wx8ykMpugXutDTzbpKBsk5buWF15Tv6BF2mv16w==
X-Received: by 2002:a5d:6c6e:0:b0:385:f9db:3c4c with SMTP id ffacd0b85a97d-38a221e2e0amr44465852f8f.9.1736159562355;
        Mon, 06 Jan 2025 02:32:42 -0800 (PST)
Message-ID: <398b7216-1564-424e-ad5c-8952795317ea@suse.com>
Date: Mon, 6 Jan 2025 11:32:49 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 6/4] x86/pv: Fix build with Clang and CONFIG_PERF_COUNTERS
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20250102192508.2405687-1-andrew.cooper3@citrix.com>
 <20250102195512.2406928-1-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250102195512.2406928-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 02.01.2025 20:55, Andrew Cooper wrote:
> Clang, of at least verion 17 complains:
> 
>   arch/x86/pv/hypercall.c:30:10: error: variable 'eax' is used uninitialized
>   whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
>      30 |     if ( !compat )
>         |          ^~~~~~~
>   arch/x86/pv/hypercall.c:87:29: note: uninitialized use occurs here
>      87 |     perfc_incra(hypercalls, eax);
>         |                             ^~~
> 
> This function is forced always_inline to cause compat to be
> constant-propagated through, but that is only a heuristic to try and get the
> compiler to do what we want, not a gurantee that it does.
> 
> Clang doesn't appear to be able to see that the only case where compat is
> true (and therefore the if() is false) is when there's an else clause on the
> end which sets eax too.
> 
> Initialise eax to -1, which ought to be optimised out, but if for whatever
> reason it happens not to be, then perfc_incra() will fail it's bounds check
> and do nothing.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

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




From xen-devel-bounces@lists.xenproject.org Mon Jan 06 10:44:36 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 10:44:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865664.1276918 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUkaz-0006D2-Nj; Mon, 06 Jan 2025 10:44:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865664.1276918; Mon, 06 Jan 2025 10:44:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUkaz-0006Cv-LC; Mon, 06 Jan 2025 10:44:29 +0000
Received: by outflank-mailman (input) for mailman id 865664;
 Mon, 06 Jan 2025 10:44:28 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=9khw=T6=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tUkay-0006Cp-0X
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 10:44:28 +0000
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com
 [2a00:1450:4864:20::42f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 32932585-cc1b-11ef-99a4-01e77a169b0f;
 Mon, 06 Jan 2025 11:44:25 +0100 (CET)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-385deda28b3so9392983f8f.0
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 02:44:25 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a2311b3c8sm44686921f8f.25.2025.01.06.02.44.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 06 Jan 2025 02:44:24 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 32932585-cc1b-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736160265; x=1736765065; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=mswuAOaTptRJ1crxo+RlLbD7enNxKMhGQJYvvHeQevU=;
        b=ekPvVCxJPIKMJjswpRCHX1liupyZuS7EgpgTBVH+NSZTqURxd8m7dbBSnC/h8641Zq
         VpTsQSDHhpjNUa7haEGIWUjAn5F7hosuXI+uP75XOzeCGJBqxhEZAxgctpyrJD1hLzsP
         dGqJy1dnJkXBjU7tDZSULnJUKQ6e2AHWxVtM9K9Ob4zqZFyZLqjgzVHy1X53jIeuYYL+
         RrZ5c+yPkbmCLtAfCyAIzLy17QTTXRpCabe7wZAtGTdKro5fqQdHoqBx1SEI98E14mTh
         NApb2pAciG0vJjUmqwJKh/xJCdlokDStEqx0uMxd4t4FUbRAmwVjlREspqA+H3EdrC4f
         Ji7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736160265; x=1736765065;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=mswuAOaTptRJ1crxo+RlLbD7enNxKMhGQJYvvHeQevU=;
        b=qgp3mkicqevgAChcgbkwaJYRrBLR/CpWm7sQMZhb7ipzL4Cnca8taL1vZywn+ow4EA
         /jvUp7JJNRoDqAR/+L3A8So8/hGu8p8M3IibR+A1dqsnIb9HXEQxTf0dKlLCYOLNLgNe
         sJXO+9zIdujs0eD8pyqvUfvPzT2ukKcNOgsf1VisYxKvJd7lkBmGNIwx/eibhXVuiTA+
         aTsodKDNm/H2NMebtzSwireA9mbFHJa0HQHei7D4wS0q73u/bu1d8VUkNpHakIt9BKSf
         P6A2MOZXQJjIwoDMjoXQIgoNj23LAf94wkX4tpplo9MatFdpuSn98ubaIZgEL9VFeZGj
         BN2A==
X-Gm-Message-State: AOJu0YxI4v+BJdjU9N/J/MBM0m60E3ZicLIzv8in1/oiGSGmh2nDOaRe
	PDGwo45vD2rsXBWMhFwDv4Y5ErVAdlma8U71J5bE7CjdmQ04uPgpnBZYZsTHyg==
X-Gm-Gg: ASbGncsaoMSiPMepozs99Gr7g4ce4kDV3IIp4MoZkOMKdSWr0b+mQgEhagS/921YWfw
	TZcjJyjkHwQnLd9cJ4tbKVcoUKv+iq2eanrwVnV8pM1wAsVlovil8FCAGEX87WBOK8vE8aj5+KI
	LFy/3K4kRIb3oQ0qULImzO1ARTfIVaWT0Gx25y0Lztw4Ujt3uhJFpTa076yDctExwDpavMvpNBB
	pWsIXXrxb/M8xIZcao0sKDBbVyzju6qn8YSOwQMxv5XEiBEsJhGJDejWZ9j/OzIAwucPjTzRudG
	DWAXX74E3CNfX4ze2ZT7KEIqCTKlyh2YEoGmgxdbcw==
X-Google-Smtp-Source: AGHT+IGFOVRCUhPBiC//lOHyvO4E1U/h3piY+Mjg/Jx5LPFCaAQVDId10M6zkGt8Pzi+ixD9+p0tDw==
X-Received: by 2002:a5d:5f56:0:b0:386:1cd3:8a00 with SMTP id ffacd0b85a97d-38a223f5b41mr55937069f8f.40.1736160265127;
        Mon, 06 Jan 2025 02:44:25 -0800 (PST)
Message-ID: <79b2a77c-a41b-4a10-90b5-ecdb35baba49@suse.com>
Date: Mon, 6 Jan 2025 11:44:32 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20] x86/traps: Rework LER initialisation and support
 Zen5/Diamond Rapids
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Xen-devel <xen-devel@lists.xenproject.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
References: <20241231192002.1753737-1-andrew.cooper3@citrix.com>
 <Z3RvWJvdB68sVhqZ@mail-itl>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <Z3RvWJvdB68sVhqZ@mail-itl>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 31.12.2024 23:25, Marek Marczykowski-Górecki wrote:
> On Tue, Dec 31, 2024 at 07:20:02PM +0000, Andrew Cooper wrote:
>> @@ -2201,6 +2155,42 @@ void __init init_idt_traps(void)
>>          this_cpu(compat_gdt) = boot_compat_gdt;
>>  }
>>  
>> +static void __init init_ler(void)
>> +{
>> +    unsigned int msr = 0;
>> +
>> +    if ( !opt_ler )
>> +        return;
>> +
>> +    /*
>> +     * Intel Pentium 4 is the only known CPU to not use the architectural MSR
>> +     * indicies.
>> +     */
>> +    switch ( boot_cpu_data.x86_vendor )
>> +    {
>> +    case X86_VENDOR_INTEL:
>> +        if ( boot_cpu_data.x86 == 0xf )
>> +        {
>> +            ler_msr = MSR_P4_LER_FROM_LIP;
> 
> msr = 
> 
> and ...
> 
>> +            break;
>> +        }
>> +        fallthrough;
>> +    case X86_VENDOR_AMD:
>> +    case X86_VENDOR_HYGON:
>> +        ler_msr = MSR_IA32_LASTINTFROMIP;
> 
> ... here?

And then
Reviewed-by: Jan Beulich <jbeulich@suse.com>
preferably with ...

>> +        break;
>> +    }
>> +
>> +    if ( msr == 0 )
>> +    {
>> +        printk(XENLOG_WARNING "LER disabled: failed to identy MSRs\n");

... (nit) s/identy/identify/ as well.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 06 11:04:43 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 11:04:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865672.1276928 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUkuR-00016C-98; Mon, 06 Jan 2025 11:04:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865672.1276928; Mon, 06 Jan 2025 11:04:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUkuR-000165-6Z; Mon, 06 Jan 2025 11:04:35 +0000
Received: by outflank-mailman (input) for mailman id 865672;
 Mon, 06 Jan 2025 11:04:34 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=9khw=T6=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tUkuQ-00015z-3H
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 11:04:34 +0000
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com
 [2a00:1450:4864:20::32f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0200e545-cc1e-11ef-a0df-8be0dac302b0;
 Mon, 06 Jan 2025 12:04:32 +0100 (CET)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-4361fe642ddso149304655e9.2
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 03:04:32 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4366128a353sm565190235e9.42.2025.01.06.03.04.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 06 Jan 2025 03:04:31 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 0200e545-cc1e-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736161472; x=1736766272; 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=ttEH5lhxbSnavTd+NJ0m9e8hXilbr/zh/1Y9/lrJRLE=;
        b=JXRoCtLzG+ejD4H/QDwRj7D8M8Scl1k0PHln2YspLgpaFCZLk3j3PCzfXXut89fppz
         JIBEKrjBL3o6a1c232Kq+A+gmbxgY4DHzp2iwwu9VqoZZmwRRYTsQEZewv8Wse2aBZ15
         OineTLw6pahDjWY7Z7vO1KsIfJd/m5NfPvNxHIK2nguTJAYo1/gX7fp3Xsdrhgv68Vpo
         M0b2lU51dxWX/i70CC9wsheU3y5/3LwG675eEC5J2+rITLjpFZCD6zSDBE+ZNSdFguqE
         kbdwq7KH5RFiCUZBPhKOFycuPPC8l4duNDqDL27rlue6acD5vVZ6K5d5fkm3H4Jx1EPV
         JNXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736161472; x=1736766272;
        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=ttEH5lhxbSnavTd+NJ0m9e8hXilbr/zh/1Y9/lrJRLE=;
        b=aF2+wL9QfMNS0Iwk/i4pDcd2IqzEO6ohp7xl64SukeMvurW6sPwFBLdlFFsKXzNocR
         mKb/NAvWZFotoAJ8CqAzf0OXB+/pPbf7s31CWA4frQ8OggyDWkWayF9GSFegoEyLzNOe
         Mu0UnzHc4C8DoesoUAhMOotkBul2rZGFGyIpQMS9KDP+Jjnu0RszYx8CLsmjRbSqdS4w
         4n4/8EI+cpQ9bb0gHHmbbj1p9yZCoEA3PDr6dMr56plM0lvMjCLsPahTapgdHjDF+tzQ
         wE4xrOLXUjQtLYxYnWYyS5PovA7Q7I872v9/5rchXrtJtqCPJFjMNeD2yctqdTtyP8pC
         jImQ==
X-Gm-Message-State: AOJu0YzbrNeOqam+aDilwX6P8uwal5SC2rA+D4aITaZbL33lurlXkkcQ
	ZhwXQQTA042Obm0Y0RujsmVcjkhz9c9L5W7xA/Qyqm36dwZ6ndBPusi5VcWh64zniECuBp391yo
	=
X-Gm-Gg: ASbGncsXzxVSo5xrw0USedowY54peQj1JgQCrRMDUXWJ4X1dbVezCItNtq8H3zJfzG8
	DJH/snyaYZ4umzcD3qf199iJVbeNC+N9VFqUQsYBO/waBME4ucNy9G3CrWtTSYdvx8zwi//shhf
	/vNRUEHWvmrP1XM/A/nIWwhx54p0cld0EdLbNpzbD7sS6ghjb2qaNBPZudLE0weLon9aX/o9IzY
	wfVA8vbO9uDMahsomHaU/XoertHa8Zv4hWqpQ/vI6iF4kbpQXE222q74EGMqzWqXJwQlIT7Ql+f
	rtQgQv7qC5v5K3nTkrfLPojlsWJcY+1ZVWE1Zr2hFg==
X-Google-Smtp-Source: AGHT+IH2JHZ3VccqwpKA7vKY0BuIwOKL3LyE2qJtdhrSvQo9/1tv5QlUV0vMDuQ8Pc0AQsShVDE1mQ==
X-Received: by 2002:a05:600c:1388:b0:434:f871:1bbc with SMTP id 5b1f17b1804b1-43668643aaamr615866015e9.10.1736161472230;
        Mon, 06 Jan 2025 03:04:32 -0800 (PST)
Message-ID: <bf8cc342-52aa-44ee-8bce-ce2be6406904@suse.com>
Date: Mon, 6 Jan 2025 12:04:39 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Oleksii Kurochko <oleksii.kurochko@gmail.com>
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH for-4.20] public/version: soften wording for deprecated
 sub-ops
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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

These interfaces were - afaict - originally introduced this way on the
firm assumption that the used array sizes would be good virtually
forever.  While this assumption turned out to not be true for at least
some of them, this still doesn't really render them "broken": They still
fit their original purpose, and they are still usable for a fair subset
of environments.  Re-word the comments accordingly.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
Despite having looked at the series back when it was posted / discussed,
I'm (now) somewhat puzzled that XENVER_compile_info didn't gain a non-
truncating replacement sub-op. The commit's description doesn't say
anything in this regard; it rather gives the impression that all sub-ops
with limitations would gain unrestricted counterparts.

--- a/xen/include/public/version.h
+++ b/xen/include/public/version.h
@@ -22,7 +22,8 @@
 /*
  * arg == xen_extraversion_t.
  *
- * This API/ABI is broken.  Use XENVER_extraversion2 where possible.
+ * This API/ABI is deprecated, for its size limitation.  Use
+ * XENVER_extraversion2 where possible.
  */
 #define XENVER_extraversion 1
 typedef char xen_extraversion_t[16];
@@ -31,7 +32,8 @@ typedef char xen_extraversion_t[16];
 /*
  * arg == xen_compile_info_t.
  *
- * This API/ABI is broken and truncates data.
+ * This API/ABI is deprecated, for its size limitations.  It may in particular
+ * silently truncate data.
  */
 #define XENVER_compile_info 2
 struct xen_compile_info {
@@ -45,7 +47,8 @@ typedef struct xen_compile_info xen_comp
 /*
  * arg == xen_capabilities_info_t.
  *
- * This API/ABI is broken.  Use XENVER_capabilities2 where possible.
+ * This API/ABI is deprecated, for its size limitation.  Use
+ * XENVER_capabilities2 where possible.
  */
 #define XENVER_capabilities 3
 typedef char xen_capabilities_info_t[1024];
@@ -54,7 +57,8 @@ typedef char xen_capabilities_info_t[102
 /*
  * arg == xen_changeset_info_t.
  *
- * This API/ABI is broken.  Use XENVER_changeset2 where possible.
+ * This API/ABI is deprecated, for its size limitation.  Use
+ * XENVER_changeset2 where possible.
  */
 #define XENVER_changeset 4
 typedef char xen_changeset_info_t[64];
@@ -116,7 +120,8 @@ typedef struct xen_feature_info xen_feat
 /*
  * arg == xen_commandline_t.
  *
- * This API/ABI is broken.  Use XENVER_commandline2 where possible.
+ * This API/ABI is deprecated, for its size limitation.  Use
+ * XENVER_commandline2 where possible.
  */
 #define XENVER_commandline 9
 typedef char xen_commandline_t[1024];


From xen-devel-bounces@lists.xenproject.org Mon Jan 06 11:08:25 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 11:08:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865683.1276939 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUky8-0001jb-RF; Mon, 06 Jan 2025 11:08:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865683.1276939; Mon, 06 Jan 2025 11:08:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUky8-0001jU-OD; Mon, 06 Jan 2025 11:08:24 +0000
Received: by outflank-mailman (input) for mailman id 865683;
 Mon, 06 Jan 2025 11:08:24 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=bFJS=T6=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tUky7-0001jO-V3
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 11:08:23 +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 8b2a3108-cc1e-11ef-a0df-8be0dac302b0;
 Mon, 06 Jan 2025 12:08:22 +0100 (CET)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-4361fe642ddso149338765e9.2
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 03:08:22 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436604e9c2csm565421165e9.43.2025.01.06.03.08.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 06 Jan 2025 03:08:21 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8b2a3108-cc1e-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736161702; x=1736766502; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=QA+6CnC7STNLyxWzKdvUbKMKyonkRY/6cNTKgnECjIs=;
        b=Ai3r+r1FOZg0g7t7Pwa1irhFDrcOhyDNGI/V08JAepj9bUQP2vhqw3nEReftfsw85D
         enoxgVPWwEH96nXm/UGzW1AFc0uzg2QnQkrcJQaW50NcTTjMJNUp/pFltxGgO9/HAEtI
         cgY3VjMha1s3ab2SoOE8zaVdMJp4OGhDibLsM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736161702; x=1736766502;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=QA+6CnC7STNLyxWzKdvUbKMKyonkRY/6cNTKgnECjIs=;
        b=THjYMt9gMsWZ20tDDtdtVWH8aXoLp9Jst0rizV8d0J+K4Ho2HRkNPxFkawitcQ0Uem
         I6DaKQ6uQZhOkW+Ru853xgw+0pkR+PXLh1zxJ4KLg6l8QlsLy0BVC/8c72J8Dj7LVq6E
         FrP2clo8OgsS9I+j9//2iqKvKUzI2I9CuYLP7ySNZADMMWpZOZOTC+xx2bkfc8UApAeH
         aKZYAk/808fGYJ21BGsXVGwc4VCaMKcWl4ucQs33r1GXvgAVJY4FBm2qoUgCqPa3E4pk
         tLUqdMqfHyT0DyAfzqqFx4aPmu2e7veX4ENolxgEK6mBpcN3sYoZBdFTRFYQs/cC3rgY
         kqHQ==
X-Forwarded-Encrypted: i=1; AJvYcCWugzMNp+SSXHShTJlMfyLmuAXUCLt/bA3ujWvbMIh3YAtRTuGBQATXXD3eeFNQJoBrZqoDffTkcfY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyPmEOjdB7mV5DcXutqxv/FwhhT5+/PzQi+quEynn+dY2QT61Jh
	3Qci3waj+M3CkU+La88LpPebhx8zUiroriNLtUGP+/AbLWA9RGOCx2cRNdqLWkk=
X-Gm-Gg: ASbGncvouspCGAxoGSLJJl4uNoBIJ6u/HkTCWunrqprXYcLlGkvK/dKN2GvlBw/s42J
	MwixB0s23OT9C+0DouIou6WROfOysmCcox1xewcBq4CkHZkyXZHw70xCakXWyTZpGVHFRlv7QZa
	aB502kap6oF4JX0lC9mexntIeVG6ZeMG6MeUGvOutxwjSCDWGGHVfPnQVFDuewPBcLO/zyaN/WG
	jtNWalqRB6xDw+0Ez7InGaieRTvhwi/y7BT+K7lwqPQt8NOvelLsHE3C0F9zVNwn4R0p4WPanMv
	Ax0e9eGG9UGHlHa0XGDT
X-Google-Smtp-Source: AGHT+IHoV+3p3Died5QrJSWa/v+pbt6YKZduD2HMzmgv2QB4df1jM15W7R+pluyBOKowrLMjzvRMGQ==
X-Received: by 2002:a05:600c:524f:b0:434:a0bf:98ea with SMTP id 5b1f17b1804b1-43668643bb4mr508898465e9.9.1736161702390;
        Mon, 06 Jan 2025 03:08:22 -0800 (PST)
Message-ID: <0c8a13d0-04d7-4ed6-a8d8-a4423867fa3f@citrix.com>
Date: Mon, 6 Jan 2025 11:08:21 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20] public/version: soften wording for deprecated
 sub-ops
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Julien Grall <julien@xen.org>, Stefano Stabellini
 <sstabellini@kernel.org>, Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Oleksii Kurochko <oleksii.kurochko@gmail.com>
References: <bf8cc342-52aa-44ee-8bce-ce2be6406904@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <bf8cc342-52aa-44ee-8bce-ce2be6406904@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06/01/2025 11:04 am, Jan Beulich wrote:
> These interfaces were - afaict - originally introduced this way on the
> firm assumption that the used array sizes would be good virtually
> forever.  While this assumption turned out to not be true for at least
> some of them, this still doesn't really render them "broken": They still
> fit their original purpose, and they are still usable for a fair subset
> of environments.  Re-word the comments accordingly.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

No.

The community voted and rejected this opinion.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Jan 06 11:13:44 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 11:13:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865690.1276949 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUl3D-0003Xp-FD; Mon, 06 Jan 2025 11:13:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865690.1276949; Mon, 06 Jan 2025 11:13:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUl3D-0003Xi-Bq; Mon, 06 Jan 2025 11:13:39 +0000
Received: by outflank-mailman (input) for mailman id 865690;
 Mon, 06 Jan 2025 11:13:38 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=9khw=T6=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tUl3C-0003Xc-MH
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 11:13:38 +0000
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com
 [2a00:1450:4864:20::32d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 463f14ef-cc1f-11ef-99a4-01e77a169b0f;
 Mon, 06 Jan 2025 12:13:36 +0100 (CET)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-436249df846so98361935e9.3
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 03:13:36 -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
 5b1f17b1804b1-4366127c4fcsm572046255e9.29.2025.01.06.03.13.35
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 06 Jan 2025 03:13:35 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 463f14ef-cc1f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736162016; x=1736766816; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=yxK4eK/LTPWWtZpfHaKPY+k8HLzEAnBAn7x/lb5fQGM=;
        b=LG4NzzZaqoc+Fz9thiPIsCMdsb0k9uYDi1DeIlAMHTIu12vLyr0wSt7pP13/f/srU/
         pXjqkJZDvly+3+7jIsuxGj0bspndhDt4o6SWsTSI1oJauNiFhlkKdX5bHvICXqHUoAi/
         nbVKASAzvoXJYgwfFGHgSfwrRcCyRJoY50yDpHpTFqOVIsV8yNsmzFU8F3SVhbJxKYk6
         hAqBOngrTcOZ2VpNoxvFLuoP3ZDpT2lEiOaQm5W1d4PfdE+QnWS9gRBYn4HEAVqcTQZI
         s2hAiTQjtAkos40eG9cXhCoe9NTs6Ijb+fvuTXJAI2u4UE6wuVG7Q6pwtOJpV+jRqyeV
         kToA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736162016; x=1736766816;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=yxK4eK/LTPWWtZpfHaKPY+k8HLzEAnBAn7x/lb5fQGM=;
        b=cWFKjU6KR91tbWSvPYSU7h3TH09giVENqKDu8yB4h/iZs4VYOLJXDGV5TsAgksMWF6
         EdCGJm8TklOxxUchEU2pQrpIxBUMh7WOarQxrxwDwozjo6q16uOmd+mOrmEt3i3fiEv1
         H/mJL0fV6Ics7UG5ZGB2Ychp2zchyElW1I6w8kNCFx3+f4of3OoYNbmTFd0ZoDu9WuTA
         Lonfq7AHGqgsK+tDc/Jg0+XX3qjIvMsuY/VkfXGmExjC7jIIaUAUlAD8CVpd+gS3Np8e
         NlkwxB30PvHTP08CM48GDvQgUB8viLuOzwDKYSrnqKawMnLfQSzddYFs7uBafDGnTMHu
         r2pQ==
X-Forwarded-Encrypted: i=1; AJvYcCVVhfdODQurib780wIbDvmEzZHgz+PJ0bBwn3cvVi0kN4HbGwtmFqXAgdUbl/lXm/Ps6UlQl/yMCok=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy6B/JZFzGppRy6ALzBjMT0obWC65iGVBIvx7eOybGS/MhxkhUQ
	wVVXveafhSst6BoC76R0NeCqVeCMA+9yJScWRy25A/qmQuRMYNGxhcq27HV+HQ==
X-Gm-Gg: ASbGncu2X2ogFBwsKm17rsX6TC4gaYWI/RvuLqho672U8ytnyrj655f8fBjXDoJlJW4
	GP0mQR/oiQm6rfuNsHq7HlkN+KWb/7Iu6vYUYGNXKXRwnfFHrxFZW+T7m/wnYr1darEZF5RQZIA
	5CFF2ODE6usn7FmEFx0XwsVsNkRKd9lMOMtcjrizW0xYZiW4kmpdjQ3nI1sXH7SNFdLYF++U3Ay
	/rWHrF/aIsmlZMTH0s5hLPYLXfGhOJ9HoYPvW7dZOQx80YjoySOghSCx+WaWr1nyhUszYhftJoV
	xNuraE06ldbP6uskKWn6KnXVbUDTtG1W41TDmDwkcQ==
X-Google-Smtp-Source: AGHT+IEVAaXKFcdJsNBb5se6jF7ScFLfcpH0wbMn1yUoPBHAGuDxKP4udoEYDL7UC2dN93hkRuTQXA==
X-Received: by 2002:a05:6000:3cd:b0:386:33e8:20f4 with SMTP id ffacd0b85a97d-38a2240f11fmr47812511f8f.59.1736162016195;
        Mon, 06 Jan 2025 03:13:36 -0800 (PST)
Message-ID: <8ca8ac20-a19f-49ef-9631-08cdcef854d2@suse.com>
Date: Mon, 6 Jan 2025 12:13:43 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20] public/version: soften wording for deprecated
 sub-ops
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Julien Grall <julien@xen.org>, Stefano Stabellini
 <sstabellini@kernel.org>, Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Oleksii Kurochko <oleksii.kurochko@gmail.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <bf8cc342-52aa-44ee-8bce-ce2be6406904@suse.com>
 <0c8a13d0-04d7-4ed6-a8d8-a4423867fa3f@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <0c8a13d0-04d7-4ed6-a8d8-a4423867fa3f@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.01.2025 12:08, Andrew Cooper wrote:
> On 06/01/2025 11:04 am, Jan Beulich wrote:
>> These interfaces were - afaict - originally introduced this way on the
>> firm assumption that the used array sizes would be good virtually
>> forever.  While this assumption turned out to not be true for at least
>> some of them, this still doesn't really render them "broken": They still
>> fit their original purpose, and they are still usable for a fair subset
>> of environments.  Re-word the comments accordingly.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> No.
> 
> The community voted and rejected this opinion.

That's not my recollection of what was voted on, and with the vote results
not being available referring to them is unhelpful anyway.

My (admittedly vague) recollection is that it was decided to leave enough
room for wording choice by submitters. That would cover your original
patch, and it would equally cover mine.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 06 11:27:24 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 11:27:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865696.1276959 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUlGF-0005QW-I8; Mon, 06 Jan 2025 11:27:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865696.1276959; Mon, 06 Jan 2025 11:27:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUlGF-0005QP-FT; Mon, 06 Jan 2025 11:27:07 +0000
Received: by outflank-mailman (input) for mailman id 865696;
 Mon, 06 Jan 2025 11:27:06 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=bFJS=T6=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tUlGE-0005Pz-Im
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 11:27:06 +0000
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com
 [2a00:1450:4864:20::331])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2268b738-cc21-11ef-99a4-01e77a169b0f;
 Mon, 06 Jan 2025 12:26:55 +0100 (CET)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-4361e89b6daso97690145e9.3
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 03:26:55 -0800 (PST)
Received: from andrewcoop.eng.citrite.net (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c89e528sm48242271f8f.83.2025.01.06.03.26.54
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 06 Jan 2025 03:26:54 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2268b738-cc21-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736162815; x=1736767615; 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=A7OP8fAG/F5Kp1fylhgwCJW5UrsQ9AfjRS2QwrkoD2Q=;
        b=Y8zKB689A9bDXO+xTonjH1qCc4wgaQ9sk0g06mZ7C9M99Dvan5+Xv8IQw32eqW9AEO
         6hn9BwP3MtfCP7EjRrnHAlZu5/84CRM0LXdV4gDwp/L1S5seKeOleN2tm42RrBG9pjmH
         my9aixmPilvWGRjm/CAabFJRYAZelVj5cffzc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736162815; x=1736767615;
        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=A7OP8fAG/F5Kp1fylhgwCJW5UrsQ9AfjRS2QwrkoD2Q=;
        b=b3X3QF2/XePeOUbwIhCtCae/uV8WVoxs1bmui1Q4ebXnni8S7T/XYm+6SAAHGHZv9X
         RmgPp2V+2AR/sF3IeOIW8q4ipdIIQg2srNrpo7N4wDBhAk+as+EKayi6tVffEr1KvVIt
         eLC6ZAj5F1g/A2PbprqrZZKbGAkyYsUyA8BqgCNaITTGG+D1zVVFoOr/7w6AOWB2lPUK
         s+T5p1SgurgQqWwle5Esh+XBKiXdhPVPdQyPEMLFvPf7K88julumtHYJDUuDmOWKo07w
         59WgC/zh7OKBSi+GN6IMAMEjIh8yPmkyhUbJxERa3DcdBUZXlvRFY9L7zDGdF5AyFQ3p
         5l5A==
X-Gm-Message-State: AOJu0YyAvWzwTvqwrWTE2wFR2oyORoo2h6ccZnp7zsxD6DWzD4WH+1hS
	d35OcZIUwH9vB8KfwjKQsfNqh1UVyx4mD/K2Y1k9iZ6aAGvJEqSJfCJAbGGmN6l+UeMHZU1bgZ1
	wM0qSDQ==
X-Gm-Gg: ASbGncsDyV8JwT/MzXPpP4rbK70hRnsU6+pdBm+ABg2pEfDq/ITd/lZbaAuiHi6sDBI
	XDfRw6Hu4EkQxzrRF4neimTyZdKEicWUU1TScG2X27CsLycx/2vf4pJFpb5GgMgEAdnAj7HUvsq
	hCemXgrDI8fFbD996X3Q1Hta411ZIPUlLdrdFNDqWDrgZa2JmphXDmWs1ma7tQrn4YP1NZN8u0x
	yGBepU1l78EelGKuyH5MaPQCBqMPHdLi63QNK4CnL/w+ByscZrfOXUkk3tCyTyNwnevLwUpbV4O
	Qfo2aVxLLv+RZyWFicYU3NUwg1R8p9mjyeEU
X-Google-Smtp-Source: AGHT+IEI8bQVed9DJiAHzMMIk5oad9Up6bbs99zf9kGUmgKuzBsFhh610ODfVmpqfdf7KcFI21KT9Q==
X-Received: by 2002:a05:6000:18ab:b0:386:1cd3:8a05 with SMTP id ffacd0b85a97d-38a223fd47fmr54971460f8f.54.1736162814616;
        Mon, 06 Jan 2025 03:26:54 -0800 (PST)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PATCH] x86/boot: Fix zap_low_mappings() to map less of the trampoline
Date: Mon,  6 Jan 2025 11:26:52 +0000
Message-Id: <20250106112652.579310-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Regular data access into the trampoline is via the directmap.

As now discussed quite extensively in asm/trampoline.h, the trampoline is
arranged so that only the AP and S3 paths need an identity mapping, and that
they fit within a single page.

Right now, PFN_UP(trampoline_end - trampoline_start) is 2, causing more than
expected of the trampoline to be mapped.  Cut it down just the single page it
ought to be.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Roger Pau Monné <roger.pau@citrix.com>

There's not an obvious candidate for a Fixes tag.
---
 xen/arch/x86/x86_64/mm.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index 389d813ebe63..d4e6a9c0a2e0 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -718,14 +718,16 @@ void __init zap_low_mappings(void)
 {
     BUG_ON(num_online_cpus() != 1);
 
-    /* Remove aliased mapping of first 1:1 PML4 entry. */
+    /* Stop using l?_bootmap[] mappings. */
     l4e_write(&idle_pg_table[0], l4e_empty());
     flush_local(FLUSH_TLB_GLOBAL);
 
-    /* Replace with mapping of the boot trampoline only. */
+    /*
+     * Insert an identity mapping of the AP/S3 part of the trampoline, which
+     * is arranged to fit in a single page.
+     */
     map_pages_to_xen(trampoline_phys, maddr_to_mfn(trampoline_phys),
-                     PFN_UP(trampoline_end - trampoline_start),
-                     __PAGE_HYPERVISOR_RX);
+                     1, __PAGE_HYPERVISOR_RX);
 }
 
 int setup_compat_arg_xlat(struct vcpu *v)
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon Jan 06 11:54:26 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 11:54:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865704.1276969 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUlgZ-0001St-IO; Mon, 06 Jan 2025 11:54:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865704.1276969; Mon, 06 Jan 2025 11:54:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUlgZ-0001Sm-Fj; Mon, 06 Jan 2025 11:54:19 +0000
Received: by outflank-mailman (input) for mailman id 865704;
 Mon, 06 Jan 2025 11:54: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 <SRS0=9khw=T6=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tUlgY-0001Sg-Bh
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 11:54:18 +0000
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com
 [2a00:1450:4864:20::32a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f42bc31c-cc24-11ef-99a4-01e77a169b0f;
 Mon, 06 Jan 2025 12:54:16 +0100 (CET)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-43625c4a50dso98009055e9.0
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 03:54:16 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c89e2d2sm48443139f8f.71.2025.01.06.03.54.15
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 06 Jan 2025 03:54:15 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f42bc31c-cc24-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736164455; x=1736769255; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=0+hZ1BOukFZ5v2thZFP+3hZWfCcfkSquV9mVtf4N4oM=;
        b=XwNqF7NBQfdrPFD+te8XZbUV6gnSk5zz70P+KupuYJ+R7Sfi16dSt4+YlFucWwMDGh
         rmpOnd3lelz9l1JjVQgI2ozhGhPOnyHnmnzYfgPQBJ+6P50HDhs8+a2IdNSpJzGcPta/
         lOPyyB1HZxy5msh5Cq6w8s74Mkgy0D0F86969VWdcKirkrHQMXqtqb6lqGNXkHUug4O7
         H06G7SOQxqb6jjm1WyOKPh+/7FUGQHCBzlB+H5A21I/r8QyN4QqE7wWoVSnE+wBzfICC
         Pil2fiVJ+5A+kIOh2DlBrgKdCzdg+FLhlwsVXtx3DzZGvAjr6z/tYGp7mQlYa3cvGtd+
         Psjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736164455; x=1736769255;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=0+hZ1BOukFZ5v2thZFP+3hZWfCcfkSquV9mVtf4N4oM=;
        b=DtqeA/Cj0Z2ZcmAOrmtyZLObq6hNvhNkkwNEBkAgIb890L/11eCRBiNeJj4SNrhNBF
         ES7YJteZo529/180GWO2MGgMYqKcY5sIyV8p78u9efzYW3oq/Zsrv8EI1ixruapcZLWe
         QI3mLxI89IvlOcYHjmT4oZLBZ2xmgqDsx9PWOIounBg++ffho59pmizJi2V6OigqV2cn
         IYV6HcR4Wb6ZTsZv1iJRywaMW/1KoktGSAWLRlWlqPYFtk0JQeJLjVBlh02EEQhXkQMN
         yKu8LNvWZmuIxH9ueiMXgwtMtGhuOfcETU8Xcen7VIMYcW4EaH3LOWXMbQyMfq4IntV+
         j+og==
X-Forwarded-Encrypted: i=1; AJvYcCW4T1uL9EJZD91X9E/HLmEtIDAl2M2WIp175/FrdV3fspgDfUat65HijhfBL6IZ2uUjfKTfF70u0hg=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx4egq+Ld/nWC3bzwIfX3h1vDRO1RraagGtst3dJAfscprxrs+k
	rKEP8cDB6qygsEnA4QFN6ZWSqhperD6wWhkbN2rYkxckrbG1+I1Rp7APZPcSHQ==
X-Gm-Gg: ASbGnctMWPJre2YU5dL5KKNFZ4tKhCbJuvubd46LXKATuHTInyGY7zoMHWPd+UCXfcx
	0yjsyAaiT6cQtLERbN53l+NSLRmwDveFWIOGwHpoC34UjOcSEWMXTBps4L8qi8u8l+kg9pNm0n3
	x2X60S8rJbQ7ntnYVc7rf1zc2rxoP+fdbzPqLRqYacctCQQQTwv3znQuejzZ9x9hGAIoTPRb3yd
	sRtRLaeqV54ejGqDc+kiRmsF0bAO5kA93HAkykCoASxKgDDJq0CR5tEW5IthwR9uhcpncJmjs+L
	kyMKrNFeoVytm4gMqakg3HvtEgAjNvGOeFGJGcWvyw==
X-Google-Smtp-Source: AGHT+IEIl83+DuTV+m8YLZo3JjHB50VJsxkVmB/XIxVsPBpi7iEQFp2HZbxB+tvkIeJyTXGIFbHstw==
X-Received: by 2002:a05:600c:1c87:b0:434:a10f:c3 with SMTP id 5b1f17b1804b1-4366864320emr513679105e9.9.1736164455521;
        Mon, 06 Jan 2025 03:54:15 -0800 (PST)
Message-ID: <2f12f38e-9629-40fd-b532-6b6f82ecfe1f@suse.com>
Date: Mon, 6 Jan 2025 12:54:14 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/boot: Fix zap_low_mappings() to map less of the
 trampoline
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20250106112652.579310-1-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250106112652.579310-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.01.2025 12:26, Andrew Cooper wrote:
> Regular data access into the trampoline is via the directmap.
> 
> As now discussed quite extensively in asm/trampoline.h, the trampoline is
> arranged so that only the AP and S3 paths need an identity mapping, and that
> they fit within a single page.
> 
> Right now, PFN_UP(trampoline_end - trampoline_start) is 2, causing more than
> expected of the trampoline to be mapped.  Cut it down just the single page it
> ought to be.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Acked-by: Jan Beulich <jbeulich@suse.com>
on the basis that this improves things. However, ...

> --- a/xen/arch/x86/x86_64/mm.c
> +++ b/xen/arch/x86/x86_64/mm.c
> @@ -718,14 +718,16 @@ void __init zap_low_mappings(void)
>  {
>      BUG_ON(num_online_cpus() != 1);
>  
> -    /* Remove aliased mapping of first 1:1 PML4 entry. */
> +    /* Stop using l?_bootmap[] mappings. */
>      l4e_write(&idle_pg_table[0], l4e_empty());
>      flush_local(FLUSH_TLB_GLOBAL);
>  
> -    /* Replace with mapping of the boot trampoline only. */
> +    /*
> +     * Insert an identity mapping of the AP/S3 part of the trampoline, which
> +     * is arranged to fit in a single page.
> +     */
>      map_pages_to_xen(trampoline_phys, maddr_to_mfn(trampoline_phys),
> -                     PFN_UP(trampoline_end - trampoline_start),
> -                     __PAGE_HYPERVISOR_RX);
> +                     1, __PAGE_HYPERVISOR_RX);

... literal numbers like this - however well they are commented - are
potentially problematic to locate in case something changes significantly.
The 1 here really would want connecting with the .equ establishing
wakeup_stack.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 06 12:43:11 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 12:43:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865720.1276978 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUmRT-0007yZ-QY; Mon, 06 Jan 2025 12:42:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865720.1276978; Mon, 06 Jan 2025 12:42:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUmRT-0007yS-Nz; Mon, 06 Jan 2025 12:42:47 +0000
Received: by outflank-mailman (input) for mailman id 865720;
 Mon, 06 Jan 2025 12:42:46 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=bFJS=T6=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tUmRR-0007yG-Uz
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 12:42:46 +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 b8418694-cc2b-11ef-99a4-01e77a169b0f;
 Mon, 06 Jan 2025 13:42:42 +0100 (CET)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-4363dc916ceso88997065e9.0
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 04:42:42 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-43656b4274csm603387275e9.38.2025.01.06.04.42.40
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 06 Jan 2025 04:42:40 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b8418694-cc2b-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736167361; x=1736772161; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=53UK6OT68eMyeWXhHkWkgkO62tPci66NaJhkx6Hu9U4=;
        b=S7a7IZCIUdak6grx6T0SPMn73waUVtQbqwDvrXZXE1QAZEYKxPv1pTeKmnBUia0Gc+
         +FuH+negpRUEANoP/B/0MC3AJ3ZrQW9p9w9M1ZPqQwp0qf++uluJDFCHopl63tqg7yMe
         GKzstPmI8RwaV1dVqdoQXjZV/hzqgBPzmtO9Q=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736167361; x=1736772161;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=53UK6OT68eMyeWXhHkWkgkO62tPci66NaJhkx6Hu9U4=;
        b=wQYAuIFlBya/P3ly5Maaa6OaivvDeMKZtlzykV04CwArPvO36SxZ5NX4KLVn/rKXAC
         tTjjaDkby9VIrF/SDgA8m/XZQyMK6v10T0pp2Nz6C9+FwFrbz/XcwsPmklJappCMZUC8
         OI6gWOOPU2m6U0WHP+5MsFsm/e8kn/9cdTDQaKko5BjFwTpkRgCc5pb9vuWvIKHjWUUN
         jPXtkuLDjAMof5atUHu1y4fkAIyxTOI2P0RKOq4kvoPrEYS1KjR7oL1p1U4ivL5ZESMp
         ulRytc6pEHG0CMI61QPwgc/q7vbL9KbVDgqgab1E9DEFsqTYLn88yu2pacYDDFrDudNL
         vyow==
X-Forwarded-Encrypted: i=1; AJvYcCWn12mdwqLivCrREu4N66TQKVf6LyOHUaBeTa+OlhA8vQxCoFLriGa+DcoS7dxAT9duj+lnZCKGPnI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwPY1Fsln3JFsvfr7Z6rJ/ScH3ytB9JiVza0U667tusyRVzZtMS
	Eebkp9pmoa5sWCfVsb5pbf5wPhbY3Xo0T3/+UAQ70zGMm87bFGhS7pmhsS5MJlo=
X-Gm-Gg: ASbGncuMEqZHVQbD1hQFKl5JYa72qdmTQq/d2OF/BkfJkm9ejX8epQSm8CQP6h5V1y6
	7GdURApOVmRxXR5JSi6+QJJp/WlKVOdk1b6s7BXaSt1I6dA+rNIg2gBohOFl71+CVv2Yu6/32ER
	sY32I42o98I7dFvdIiL8sa5PkdTEeI2WN2u16xcsKNiakprrY101VrLah+VdzqN/MhRMB2sqZVJ
	Ey6pd+afYsyLSjz/H7oGZXdAJPgQWDe33a/SOOUwTjftQ7vbAZBxXh54EzElG5FN4rFme1jWfok
	tgA1/kJL3d061DTq1cUe
X-Google-Smtp-Source: AGHT+IF6R6FdHiaLo74wE1X6jX1NCiCEtExp9Ls/pKKKMUs7druasMl3HtpeC8xDX1WdOEXUiFLiQQ==
X-Received: by 2002:a05:600c:3147:b0:436:1b86:f05 with SMTP id 5b1f17b1804b1-43669a22df3mr470004165e9.11.1736167361462;
        Mon, 06 Jan 2025 04:42:41 -0800 (PST)
Message-ID: <1383b39a-6ca1-4ee5-9e8f-1e6e381f73db@citrix.com>
Date: Mon, 6 Jan 2025 12:42:39 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/5] xen/perfc: Add perfc_defn.h to asm-generic
To: Jan Beulich <jbeulich@suse.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>,
 Shawn Anastasio <sanastasio@raptorengineering.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20250102192508.2405687-1-andrew.cooper3@citrix.com>
 <20250102192508.2405687-3-andrew.cooper3@citrix.com>
 <fc0b1bfd-9673-4ceb-9689-b7d4b7838d79@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <fc0b1bfd-9673-4ceb-9689-b7d4b7838d79@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06/01/2025 10:29 am, Jan Beulich wrote:
> On 02.01.2025 20:25, Andrew Cooper wrote:
>> ... and hook it up for RISC-V and PPC.
>>
>> On RISC-V at least, no combination of headers pulls in errno.h, so include it
>> explicitly.
>>
>> Guard the hypercalls array declaration based on NR_hypercalls existing.  This
>> is sufficient to get PERF_COUNTERS fully working on RISC-V and PPC, so drop
>> the randconfig override.
> And then perhaps also that from riscv64_defconfig?

Oh, quite possibly.

I'm not entirely sure what the point of negatives like that are in the
defconfig.

>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Preferably with the added change:
> Reviewed-by: Jan Beulich <jbeulich@suse.com>

Thanks.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Jan 06 14:06:58 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 14:06:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865733.1276996 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUnka-0000tC-NJ; Mon, 06 Jan 2025 14:06:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865733.1276996; Mon, 06 Jan 2025 14:06:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUnka-0000t5-KT; Mon, 06 Jan 2025 14:06:36 +0000
Received: by outflank-mailman (input) for mailman id 865733;
 Mon, 06 Jan 2025 14:06:36 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=EjtY=T6=tklengyel.com=tamas@srs-se1.protection.inumbo.net>)
 id 1tUnka-0000sz-0e
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 14:06:36 +0000
Received: from sender4-op-o12.zoho.com (sender4-op-o12.zoho.com
 [136.143.188.12]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6e6dd7d4-cc37-11ef-a0df-8be0dac302b0;
 Mon, 06 Jan 2025 15:06:33 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1736172385275416.690204826991;
 Mon, 6 Jan 2025 06:06:25 -0800 (PST)
Received: by mail-yb1-f178.google.com with SMTP id
 3f1490d57ef6-e4930eca0d4so18545385276.3
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 06:06:25 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 6e6dd7d4-cc37-11ef-a0df-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1736172387; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=YPkFt/7PDx3cqA4v6bHgb/pfnBK29wGdQ8d2Jf+8dGpRZbW4HlT6Eo0f6Sl/dvasQ3pRp3xZvuhzG+Z6M0XtDQvGo8sFqjI9nE8JoKmmwHfvncxINNYEmSy+z9nd/NDgwT3a+fQKzcNyaYVWt6hrVQHPKZXvPl+VDjvummWs6bw=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1736172387; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=iOAJ9XTmoSmFUoSI3CJNLNTF1VjywRN9i2HM85jxsQ0=; 
	b=kZJZVHkhAa/pmld1O/fPEMvTuhXGEdyA6JXhoxC7sFiS1TBdoxO3DqO9XzTAPI7us3F0NZIv53eZz4hHA+A4O+dIcLSIKMXxzFb7pf2ZXxr9Vik2cmBDQABfTNbziOB0jNCQxX67nQjG9UdR1Pgp4wFCmTibqxrAzyN1GItrSxM=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=tklengyel.com;
	spf=pass  smtp.mailfrom=tamas@tklengyel.com;
	dmarc=pass header.from=<tamas@tklengyel.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1736172387;
	s=zmail; d=tklengyel.com; i=tamas@tklengyel.com;
	h=MIME-Version:References:In-Reply-To:From:From:Date:Date:Message-ID:Subject:Subject:To:To:Cc:Cc:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=iOAJ9XTmoSmFUoSI3CJNLNTF1VjywRN9i2HM85jxsQ0=;
	b=LzCUN/piEX1bErvaSVo8jTUtLWbg4/NKLxp/RIHz8AL30IV/og/ZA+IFlv6pqlFX
	rxUIYNUa5Qnry0h3spZEbEhPcgVOmxMQRut+gNuMUJw1Lr0Ztl+7HOoe/nyr7R08Tgk
	Wbn1hLuiFWk2qKoGrAPhTwE2EHpjVgwHivkCGHYc=
X-Forwarded-Encrypted: i=1; AJvYcCWLf4mnSFSxxu2PTv6NAUnoOwzykxDWEYmCmDKvCf9Vkos/d5emO5HZ+gGVcMuq/gpXIw2YBJ2FFp0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxbAGL7Q1qNV2bxrUlqfvAPNtVVudqp0d2F8X62Zweaoh1amnMZ
	Flao+bZWJtcfZLjBs1Lk965odTy05X46S7nkkfftbeFck/G7CB7dI1wiIFtUsEXimQ1iIMlCRwG
	xxzlZhiULcZ0qS0Fr0fT2SpnGa1o=
X-Google-Smtp-Source: AGHT+IGpf7wXqQirs9MgAr3vMUBOYkIAUr4WCy9X5GIzDUHEHtiMQqtoKkdocTJSY6GinKpHtMW9ChFEW8GTJ2gAKBI=
X-Received: by 2002:a05:690c:680b:b0:6ee:5cf9:f898 with SMTP id
 00721157ae682-6f3f820bb3dmr391218307b3.33.1736172384437; Mon, 06 Jan 2025
 06:06:24 -0800 (PST)
MIME-Version: 1.0
References: <20241230063051.3332332-1-Sergiy_Kibrik@epam.com> <c8684340-33f9-41d3-94e4-77ee3bc18306@suse.com>
In-Reply-To: <c8684340-33f9-41d3-94e4-77ee3bc18306@suse.com>
From: Tamas K Lengyel <tamas@tklengyel.com>
Date: Mon, 6 Jan 2025 09:05:48 -0500
X-Gmail-Original-Message-ID: <CABfawhk4pzA9bSMzJDX7ZwaYC50dfn_ntCnk=bePmiKCpDnN3w@mail.gmail.com>
Message-ID: <CABfawhk4pzA9bSMzJDX7ZwaYC50dfn_ntCnk=bePmiKCpDnN3w@mail.gmail.com>
Subject: Re: [XEN PATCH v1] xen: mem_access: conditionally compile vm_event.c
 & monitor.c
To: Jan Beulich <jbeulich@suse.com>
Cc: Sergiy Kibrik <Sergiy_Kibrik@epam.com>, Stefano Stabellini <stefano.stabellini@amd.com>, 
	Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, 
	Bertrand Marquis <bertrand.marquis@arm.com>, Michal Orzel <michal.orzel@amd.com>, 
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>, Andrew Cooper <andrew.cooper3@citrix.com>, 
	Anthony PERARD <anthony.perard@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
	Alexandru Isaila <aisaila@bitdefender.com>, Petre Pircalabu <ppircalabu@bitdefender.com>, 
	xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jan 6, 2025 at 5:16=E2=80=AFAM Jan Beulich <jbeulich@suse.com> wrot=
e:
>
> On 30.12.2024 07:30, Sergiy Kibrik wrote:
> > From: Stefano Stabellini <stefano.stabellini@amd.com>
> >
> > Extend coverage of CONFIG_MEM_ACCESS option and make the build of VM ev=
ents
> > and monitoring support optional.
>
> Yet doesn't this end up in things becoming misleading? Don't we rather ne=
ed a
> 2nd Kconfig option, with a dependency between the two? Or alternatively a
> rename of the existing option (to describe the higher-level feature rathe=
r
> than the lower level one)? Tamas, I'm particularly interested in knowing =
your
> view here as well.

Thanks Jan, I was thinking the same thing. The dependency of these
subsystems is mem_access -> monitor -> vm_event. If the goal here is
to disable all three levels the ideal way would be to have separate
kconfig options for each level. It may be a bit too fine-grained
though on ARM since there are only two types of events for monitor
(SMC & mem_access) and only the monitor uses the vm_event channel (no
mem-sharing/paging on ARM). So if doing separate kconfig for each
individual feature is an overkill I would suggest using
CONFIG_VM_EVENT that disables all three levels, including both
mem_access & smc monitor hooks.

Tamas


From xen-devel-bounces@lists.xenproject.org Mon Jan 06 14:19:48 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 14:19:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865744.1277006 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUnx8-0002YC-OV; Mon, 06 Jan 2025 14:19:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865744.1277006; Mon, 06 Jan 2025 14:19:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUnx8-0002Y5-Lw; Mon, 06 Jan 2025 14:19:34 +0000
Received: by outflank-mailman (input) for mailman id 865744;
 Mon, 06 Jan 2025 14:19: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
 <SRS0=bFJS=T6=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tUnx7-0002Xz-RZ
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 14:19:33 +0000
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com
 [2a00:1450:4864:20::52d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3f57aebe-cc39-11ef-a0df-8be0dac302b0;
 Mon, 06 Jan 2025 15:19:32 +0100 (CET)
Received: by mail-ed1-x52d.google.com with SMTP id
 4fb4d7f45d1cf-5d3e6274015so25694990a12.0
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 06:19:32 -0800 (PST)
Received: from andrewcoop.eng.citrite.net (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d806fedbbasm23858386a12.71.2025.01.06.06.19.30
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 06 Jan 2025 06:19:30 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 3f57aebe-cc39-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736173171; x=1736777971; 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=quqjyLr5Tr/6kOvkiYP1aB0V6P6CHKH+j3lDEcV0jY4=;
        b=KOEbmCv0GKPK3yI/mJIk88+lR1Cqr1GOixs4yBHTnlh8mMuHYxy2C0ByXP/NWPgHCb
         GPvmyyr7ah0mwuSv/jLuLaoPWQT0ESq/mPF44VVYvlH+GN5MSY1ZL9LmWtgk5lQ3VJwO
         tvMktuGNC4y8MMrhiBGIiwlnF6ARiMeijvMw4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736173171; x=1736777971;
        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=quqjyLr5Tr/6kOvkiYP1aB0V6P6CHKH+j3lDEcV0jY4=;
        b=vSYUBdh0wMpg/zIfOSyLql54o76ZJYcTORlwGvXpihBA1plN3kOrWnQJ4S4F3MNSeX
         3kgK2rPR/huL0y061PY5bm2k/6aou2yRUvV6BYKJ0ICgWwHcNS8YrAXcimanFIl3lDCl
         rPU3fHGSdKimhA/8gOxbuIrQsYJWDT0yYitJ2SmUZiCHddfTSJsZuwXR9pl8jUkrGR2/
         ++J2v5r/+XnR+c+s9ZQWt1ixkIDJ9iv85ShVSP9gIsu9keHKbFMOamGNEkUmNygvVbun
         CJHbmfbEOAZl48vWiUnvplW99GdACfTOMryTOTVzdVBDfXD9n0mBWz6S+3TljLyaqQya
         +arQ==
X-Gm-Message-State: AOJu0YwPEGpieyTfIsMDxs0SpeUOp14fMSNuAlkRwmh0Y5MZ+bDjtEFr
	eCC0Z+fobPDV8oJnKcY19sGKmdIj6kt5WH9AWEhG3A3RZ4ZehB/ls+O3UDwFBkmaHeqHtob+fcU
	+Rsw4qw==
X-Gm-Gg: ASbGncu1+NXJ4S9ai4wOuA4s/DzTC1KJGKJjASD00Ov34K5w1fPtGUGO8O/7YczCwKC
	7WosrEFkrZvfBEtQF2dyk7/NImtEh+IDs0iDEY9+uOAIaoiWk9BKZpyDh81QP6gmZ+0YeHAvUiy
	lE1yqJgnBoDSu14zAOrKJgl4vj7NR5uhXzZ5VhpA5DmfMm2ijmQZTKft1HJJxtOlFdFGW5rt2OH
	klNMamJJqnkxZIxxuoTs41rKVDBn0e4t4ItpYuHxLOwkzH9rF8lluZBGDghN26NO39NNa96zkGc
	my9ZSCJiPMJgT/3k76Zru0+lz0mo4EjCzbIz
X-Google-Smtp-Source: AGHT+IFNv/YOaDo8oGxz02LHgC1r3uGaI95476rT5I0jgnWKaO1P/HtaHO0GS0IR0adAIxYLl1fabw==
X-Received: by 2002:a05:6402:3486:b0:5d0:e73c:b7f6 with SMTP id 4fb4d7f45d1cf-5d81de2dd01mr47689558a12.31.1736173171025;
        Mon, 06 Jan 2025 06:19:31 -0800 (PST)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PATCH for-4.20] x86/amd: Misc setup for Fam1Ah processors
Date: Mon,  6 Jan 2025 14:19:29 +0000
Message-Id: <20250106141929.615831-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Fam1Ah is similar to Fam19h in these regards.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Roger Pau Monné <roger.pau@citrix.com>

With this patch, I think we're in an ok position to declare support on Zen5
CPUs.  I'm very disappointed that AMD don't have any documetation about ERAPS,
but to the best of my (backchannel) knowledge, Xen should behave safely.
---
 xen/arch/x86/acpi/cpu_idle.c     | 1 +
 xen/arch/x86/cpu/microcode/amd.c | 4 ++++
 xen/arch/x86/cpu/vpmu_amd.c      | 1 +
 3 files changed, 6 insertions(+)

diff --git a/xen/arch/x86/acpi/cpu_idle.c b/xen/arch/x86/acpi/cpu_idle.c
index 876317fad059..420198406def 100644
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -1417,6 +1417,7 @@ static void amd_cpuidle_init(struct acpi_processor_power *power)
 
     switch ( c->x86 )
     {
+    case 0x1a:
     case 0x19:
     case 0x18:
         if ( boot_cpu_data.x86_vendor != X86_VENDOR_HYGON )
diff --git a/xen/arch/x86/cpu/microcode/amd.c b/xen/arch/x86/cpu/microcode/amd.c
index ba7668a94670..58568f9aa024 100644
--- a/xen/arch/x86/cpu/microcode/amd.c
+++ b/xen/arch/x86/cpu/microcode/amd.c
@@ -114,6 +114,7 @@ static bool verify_patch_size(uint32_t patch_size)
 #define F16H_MPB_MAX_SIZE 3458
 #define F17H_MPB_MAX_SIZE 3200
 #define F19H_MPB_MAX_SIZE 5568
+#define F1AH_MPB_MAX_SIZE 14368
 
     switch ( boot_cpu_data.x86 )
     {
@@ -132,6 +133,9 @@ static bool verify_patch_size(uint32_t patch_size)
     case 0x19:
         max_size = F19H_MPB_MAX_SIZE;
         break;
+    case 0x1a:
+        max_size = F1AH_MPB_MAX_SIZE;
+        break;
     default:
         max_size = F1XH_MPB_MAX_SIZE;
         break;
diff --git a/xen/arch/x86/cpu/vpmu_amd.c b/xen/arch/x86/cpu/vpmu_amd.c
index a082450e923a..a6117dfebf2a 100644
--- a/xen/arch/x86/cpu/vpmu_amd.c
+++ b/xen/arch/x86/cpu/vpmu_amd.c
@@ -568,6 +568,7 @@ const struct arch_vpmu_ops *__init amd_vpmu_init(void)
     case 0x15:
     case 0x17:
     case 0x19:
+    case 0x1a:
         num_counters = F15H_NUM_COUNTERS;
         counters = AMD_F15H_COUNTERS;
         ctrls = AMD_F15H_CTRLS;
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon Jan 06 14:29:15 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 14:29:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865758.1277025 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUo6L-0004He-Ms; Mon, 06 Jan 2025 14:29:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865758.1277025; Mon, 06 Jan 2025 14:29:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUo6L-0004HX-K9; Mon, 06 Jan 2025 14:29:05 +0000
Received: by outflank-mailman (input) for mailman id 865758;
 Mon, 06 Jan 2025 14:29:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=9khw=T6=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tUo6K-0004HR-Kr
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 14:29:04 +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 933d4223-cc3a-11ef-99a4-01e77a169b0f;
 Mon, 06 Jan 2025 15:29:02 +0100 (CET)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-4363dc916ceso89776975e9.0
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 06:29:02 -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
 ffacd0b85a97d-38a1c828e3fsm48576267f8f.5.2025.01.06.06.29.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 06 Jan 2025 06:29:00 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 933d4223-cc3a-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736173742; x=1736778542; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=qQgCJk2SRXr/4wYxbeX321RmhPVw63jVd1cZ+I36fVU=;
        b=DYCorf1ko+U5oU8dDLsV5YeZgHuPn8k9BxQ3ZfTqezxL7fLlTZnyb6ulBmsEd4+U4F
         Yk3L2f9SzTURObmmOyPlrjTr4RlWsRAsoNFvCu0JgUwt9CnuyEKqdybuxyXfT3pu54py
         GFJZpTYRfs1lTwqCEL/qqAm5tIcGEHSkGmFYgJ0Hc57jhKPZOnDgN0y4bf7DWps+4H5J
         chUlOAaec6/QDC4VnbxAnyBmbxUNaZ7FOkPi468LTQ5H7WRsBDgCyXetCUA4EWrueph1
         Hx4mcg9EjAGt20u/nnbVmNCsvcL/7kYZqSjCG3esv3Wn8FdG/myXbZSaEPnGcyqk+xXk
         WxlA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736173742; x=1736778542;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=qQgCJk2SRXr/4wYxbeX321RmhPVw63jVd1cZ+I36fVU=;
        b=cakBzZk4vMAgMEoMd+oIdxy0NKGeg4BiAB0Milbwisww70syd3+jqruqhpMO1jiZQY
         H8zmVanQDJzfXUH3eL8JDKKZq6x0X5diNzAQpLi2+M4eH7PwkJS/8Oghi966y7zE0Mkz
         xQeWCGKPR01rbExGNYKytd87BSnTVHfSsu0kthY9cKKqKSZisELgqoGxex+Aei/K7SGm
         khurt3SyVZ2sBTQ2+4G0ClgT7e7uSdUIMjoMpPcsgN8zueU0smX0pH9Ta9gowmVYYvQY
         KDioefMd6veEYiEMT9cabQ+CoUxCnzZ9draQq33aELhlPchbZAklp+wdimf7Oyr1tOuR
         9UUg==
X-Forwarded-Encrypted: i=1; AJvYcCUlgY4NmW+T+1LAAIcJ7cI+Barn7T3I7m9vMbeN5YUlVVxXRB4hAhDZZ8Ly8HX6mp7Y+sgwW/3OD/M=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxRFviJ5ES6rVL4QRxgcVfPy/c2mZWdlCmH1oFkR+h3sh+CwcFx
	eZN7/1uHe5H8vuuzDalBMTiKQTwcC99A1VTB1j2qTmQC/dkO/HGKIVo1lSRGdQ==
X-Gm-Gg: ASbGncuj25w2gIRPCj4O3ODfaUk8c+rbLm7gFZuElkoYfl67Hk/uLsRkOKa9PrBcyBw
	7uQyl8OZYIY8h9FEyQYzGugR2B14CV7b50pFU5bNobDmivPGVUaHzUAJoPHL/FSzJ9kNXqGoTTu
	Q8wLw/BiupzoXIYzni5t0Pt4zKEN9xRk8VBk0cmJQkv6lwJPCP9d0YWPm1Px6MT1jg2LtzDJV5H
	7Aflk65w7YZD9KjTyCdNHYqkObOxoUlN1EtMmGkAWAmg8orfkTCtonpguK5UBHPYVRBI50xyfxz
	ucAADvmG1gFpNrjMwck55cx0XrUPm7QNM/p410OQ1A==
X-Google-Smtp-Source: AGHT+IFs2MQsvnb7skBIq5LUbnTe82FsNuoDB+JWIDrE6vpiI2bjUbPaCGXAEATedToUj2EBKJyhGg==
X-Received: by 2002:a05:6000:1864:b0:388:c61d:4415 with SMTP id ffacd0b85a97d-38a22a2d914mr44976156f8f.18.1736173741281;
        Mon, 06 Jan 2025 06:29:01 -0800 (PST)
Message-ID: <3ff59df0-69f8-426a-ab44-d2cd9b5bf8ea@suse.com>
Date: Mon, 6 Jan 2025 15:28:59 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC] docs: FRED support in Xen
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20250103204704.84067-1-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250103204704.84067-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 03.01.2025 21:47, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> CC: Jan Beulich <JBeulich@suse.com>
> CC: Roger Pau Monné <roger.pau@citrix.com>
> 
> An initial RFC discussion and plan.  Open TODOs are at the end.
> 
> This can be viewed online at:
>   https://andrewcoop-xen.readthedocs.io/en/docs-devel/hypervisor-guide/x86/fred.html
> 
> I've got an 8-patch series doing the cpu_user_regs disentangling vs the public
> API.  That's in pretty good shape now.
> 
> FRED itself is orders and orders of magnitude more simple than IDT, both in
> terms of setup and operation, but I'm in the middle of a very large
> cleanup (35 patches and count) to setup.c and trap.c in order to make FRED
> able to be cleanly integrated into Xen, and that's still before any of the GS
> changes to keep PV guests functioning correctly.
> ---
>  docs/glossary.rst                   |   7 +
>  docs/hypervisor-guide/x86/fred.rst  | 215 ++++++++++++++++++++++++++++
>  docs/hypervisor-guide/x86/index.rst |   1 +
>  3 files changed, 223 insertions(+)
>  create mode 100644 docs/hypervisor-guide/x86/fred.rst
> 
> diff --git a/docs/glossary.rst b/docs/glossary.rst
> index 6adeec77e14c..18502c0474f7 100644
> --- a/docs/glossary.rst
> +++ b/docs/glossary.rst
> @@ -43,6 +43,13 @@ Glossary
>       Sapphire Rapids (Server, 2023) CPUs.  AMD support only CET-SS, starting
>       with Zen3 (Both client and server, 2020) CPUs.
>  
> +   FRED
> +     Flexible Return and Event Delivery is a facility in x86 CPUs which
> +     overhauls how system calls, interrupt and exception handling works.
> +
> +     Intel support for FRED is slated for Panther Lake (Client) and Diamond
> +     Rapids (Server).
> +
>     guest
>       The term 'guest' has two different meanings, depending on context, and
>       should not be confused with :term:`domain`.
> diff --git a/docs/hypervisor-guide/x86/fred.rst b/docs/hypervisor-guide/x86/fred.rst
> new file mode 100644
> index 000000000000..68146b79bdfc
> --- /dev/null
> +++ b/docs/hypervisor-guide/x86/fred.rst
> @@ -0,0 +1,215 @@
> +.. SPDX-License-Identifier: CC-BY-4.0
> +
> +FRED: Flexible Return and Event Delivery
> +========================================
> +
> +Overview
> +--------
> +
> +FRED was originally intended to improve performance (reading and parsing the
> +IDT, GDT/LDT and possibly the TSS is a bottleneck) and to provide an
> +extensible mechanism to overcome other limitations in the future (e.g. support
> +for more than 256 interrupt vectors).  During development, FRED was adjusted
> +substantially to also fix lots of technical debt that had accumulated in the
> +x86 architecture for the past 40 years, most of which is a fertile source of
> +crashes and privilege escalation bugs.
> +
> +FRED is primarily concerned with establishing a new context when an event is
> +recognised, and restoring the old context when the event is handled.  This
> +includes events previously delivered through the IDT (exceptions and
> +interrupts), as well as ``SYSCALL`` and ``SYSENTER`` instructions which
> +avoided the IDT in the past for performance reasons.
> +
> +FRED strives to achieve that event delivery always establishes a good CPL0
> +stack (and shadow stack if CET is active), that doesn't clobber still-active
> +state from an outer nested context, and with the CPL0 GSBASE.
> +
> +Technical details
> +-----------------
> +
> +When FRED is active, Rings 1 and 2 cannot be entered at all, Ring0
> +compatibility mode cant be entered (i.e. Ring0 is strictly 64bit), and
> +``IRET`` can no longer change privilege.  Call Gates no longer exist.
> +
> +A single entrypoint is registered in ``MSR_FRED_CONFIG``.  Entries from Ring3
> +start at this address, while entries from Ring0 start at +256.  All
> +interrupts, exceptions and syscalls route these.  VMExits do not, and retain
> +their prior behaviour.
> +
> +There are 4 Stack Levels, SL 0 thru 3 and a notion of Current Stack Level,
> +replacing the prior IST mechanism.  All stack pointers, and shadow stack
> +pointers when CET-SS is active, are registered in ``MSR_{R,S}SP_SL{0..3}``.
> +Supervisor Shadow Stack tokens no longer exist, and are replaced with an
> +alternative mechanism.
> +
> +The IDT is no longer used.  The TSS is no longer used used to hold stack
> +pointers, nor ``MSR_ISST`` if CET Shadow Stacks are active.  ``MSR_{L,C}STAR``
> +as well as all SYSENTER MSRs are no longer used.  Under FRED, ``MSR_STAR`` and
> +``MSR_FMASK`` are used with their previous behaviour extended to all event
> +deliveries, not just syscalls.
> +
> +The instructions ``SWAPGS``, ``CLRSSBSY``, ``SETSSBSY``, ``SYSEXIT`` and
> +``SYSRET`` unconditionally ``#UD``.  Establishing an initial SSP should use
> +``RSTORSSP``.  GS maintenance can use the new ``LKGS`` instruction.
> +
> +Implementation considerations
> +-----------------------------
> +
> +PV32 guests
> +"""""""""""
> +
> +FRED formally removes the ability to use Rings 1 and 2, which prohibits the
> +use of PV32 guests.  PV32 guests are already disabled by default in the
> +presence of CET owing to the difficulty of using Ring 1 with CET active.
> +Compatibility for PV32 guests is provided by PVShim, which takes care not to
> +use CET in order to be able to run PV32 guests.  FRED can use the same
> +approach.
> +
> +Initialisation
> +""""""""""""""
> +
> +Exception handling is initialised right at the beginning of ``__start_xen()``
> +prior to parsing the command line.  Having exception cover this early is
> +important and wants to remain.
> +
> +The determination of whether to use FRED or not needs to account for the
> +``fred`` and ``pvshim`` command line options, the ``FRED`` and ``LKGS`` CPUID
> +bits.
> +
> +Therefore for simplicity, early exception handling will still use IDT
> +delivery, and later setup can switch to FRED instead.
> +
> +cpu_user_regs vs vm86 segments
> +""""""""""""""""""""""""""""""
> +
> +``struct cpu_user_regs`` exists in the public interface, and is embedded
> +inside ``struct vcpu_guest_context``.  From an ABI perspective, the layout
> +needs to remain.  ``struct cpu_user_regs`` is also a common name in Xen,
> +covering the event information (pushed by hardware and software) and the GPRs
> +(pushed by software).  From an API perspective, the name needs to remain.
> +
> +The data selectors (ds, es, fs, gs) are a vestigial remnant of vm86 mode.
> +Hardware did push them on exit from vm86 mode, and ``IRET`` would consume them
> +on the way back in.
> +
> +However, vm86 mode isn't usable in Long mode, and these selectors oughtn't to
> +have survived into the PV64 ABI.  Under FRED, hardware pushes different
> +information here, which needs accounting for in Xen's view of ``struct
> +cpu_user_regs``.
> +
> +Therefore, the only option is to have the public API provide a struct by a
> +different name, and provide a compatibility define for the ``!__XEN__`` case,
> +freeing us up to have a similar but not identical ``struct cpu_user_regs``
> +which Xen operates on.
> +
> +There are several uses of the vm86 fields in Xen:
> +
> + #. ``struct vcpu`` embeds a ``struct cpu_user_regs`` to hold GPRs/etc when
> +    the vCPU is scheduled out.  The vm86 fields are used by the PV logic only
> +    (``{save,load}_segments()``) and can be moved into separate fields in
> +    ``struct pv_vcpu``.  PV's ``dom0_construct()`` sets these fields directly,
> +    and needs a matching adjustment.
> +
> + #. As part of ``arch_{get,set}_info_guest()`` during hypercalls.  The
> +    guest side needs to remain as-is, but the Xen side can rearranged to use
> +    the new fields from above.
> +
> + #. As part of vCPU diagnostics (``show_registers()`` etc).  The ``#DF`` path
> +    uses the fields as scratch storage for the current register values, while
> +    the other diagnostics are simply accessing the state of a scheduled-out
> +    vCPU.

Unlike for the former 2 points and for the one immediately below, but like for
the final one below you don't mention what you intend to do. Here I assume it'll
be reasonably straightforward to use scratch space elsewhere.

> + #. In HVM's ``hvm_sanitize_regs_fields()``, to poison the fields and make
> +    them more obvious if used anywhere in HVM context.  This can simply be
> +    deleted.
> +
> + #. In x86_emulate.c's ``put_fpu()``.  As far as I can tell, this is
> +    completely buggy; the values will be poisoned for HVM guests, and stale
> +    from the prior context switch for PV guests.

For HVM guests the ->read_segment() hook will be populated, so the path isn't
taken (leaving aside the odd case of the hook failing). For PV guests I don't
see any staleness concern: When the vCPU was switched in, the fields were set
(restored), weren't they?

For the purpose of FRED this doesn't matter much - wherever the values are to
be held, they'll be taken from by put_fpu().

> +Stack layout
> +""""""""""""
> +
> +Xen's CPU stacks are 8-page (8-page aligned), arranged as::
> +
> +  7 - Primary stack (with a struct cpu_info at the top)
> +  6 - Primary stack
> +  5 - Primary Shadow Stack (read-only)
> +  4 - #DF IST stack
> +  3 - #DB IST stack
> +  2 - NMI IST stack
> +  1 - #MC IST stack
> +  0 - IST Shadow Stacks (4x 1k, read-only)
> +
> +which needs mapping into FREDs Stack Levels.
> +
> +FRED Stack Levels replace IST.  Most events from Ring3 enter Ring0 at SL0,
> +including interrupts, and even exceptions with a non-zero Stack Level
> +configured.  Nested exceptions originate from Ring0 even if they were trying
> +to push a Ring3 event frame onto the stack, so do follow the Ring0 CSL rules.
> +
> +Within Ring0, a stack switch occurs on event delivery if the event has a
> +higher configured Stack Level (exceptions in ``MSR_FRED_STK_LVLS``, interrupts
> +in ``MSR_FRED_CONFIG``).  Otherwise, the new event is delivered on the current
> +stack.
> +
> +Under FRED, most sources of ``#DF`` are gone; failure to push a new event
> +frame onto a stack is the main remaining one, so ``#DF`` needs to be the
> +highest stack level (SL3) to catch errors at all other stack levels.
> +
> +Also, FRED removes the "syscall gap", removing the primary need for ``NMI``,
> +``#DB`` and ``#MC`` to need separate stacks.
> +
> +Therefore, Xen has no need for SL1 or SL2.  Under IDT delivery, we poison the
> +unused stack pointers with a non-canonical address, but we cannot do that
> +under FRED; they're held in MSRs and checked at WRMSR time.  Instead, we can
> +point the SL pairs (RSP + SSP) at each others (regular and shadow stack) guard
> +pages such that any use of an unused SL will escalate to ``#DF``.

I may have a language issue here: "each others" reads wrong to me; do you perhaps
mean "each ones"?

Further, mainly to double check my own understanding: Almost half of the stack
area then isn't used anymore when FRED is active: 2 pages for the primary stack,
1 page for the primary shadow stack, 1 page for the SL3 stack, and (somewhat
wastefully) 1 more for the SL3 shadow stack. There'll be 3 unused pages, and
hence space again to have true guard pages, e.g.

  7 - Primary stack (with a struct cpu_info at the top)
  6 - Primary stack
  5 - Guard page
  4 - Primary Shadow Stack (read-only)
  3 - Guard page
  2 - #DF stack
  1 - #DF Shadow Stack (read-only)
  0 - Guard page

Having reached the bottom of the section, there's one special IST aspect that
I'm missing, special enough imo to warrant mentioning even if only to state that
it's (hopefully) going to be irrelevant (i.e. not require replacing by another
similar hack): {dis,en}able_each_ist() as used by SVM (on the assumption that
sooner or later AMD is likely to also implement FRED, and that you may already
know of details of their respective VMCB integration).

> +Still TBD
> +---------
> +
> +Issues/areas I'm aware of, but haven't got a firm plan yet.
> +
> +Call Gates
> +""""""""""
> +
> +FRED removes Call Gates, yielding ``#GP[sel]`` instead.  This is how we
> +emulate call gates for PV32, but emulation is genuinely only wired up for PV32
> +guests, not for PV64.
> +
> +PV64 guests do seem to be able to write Call Gates into their LDT/GDT, but
> +have the DPL 0'd in common with PV32.  Given the absence of emulation, I think
> +PV64 can't actually use Call Gates, but given the existing logic this also
> +seems to be by accident rather than design.

A partial patch I have to start doing that emulation has a timestamp of 2007.
Quoting my note there (which I may have posted at some point): "The main issue
to be resolved is how to distinguish whether a referenced code segment is a
kernel or user segment, so that the code can know whether to switch the guest
to kernel mode. Perhaps this can be done by setting _SEGMENT_EC on all user
segments and clearing it on all kernel ones (in check_descriptor())."

In any event - since no real-world need has surfaced in all this time, I don't
think the case needs worrying about for FRED.

> +GS handling
> +"""""""""""
> +
> +Xen does not use GS as a per-cpu pointer, but FRED is tied to the common OS
> +usage.  Therefore, when FRED is active, ``v->arch.pv.gs_base_{user,kernel}``
> +are logically the opposite way around when running in Xen context.

But these are our own fields. I think we'd better keep their names in line
with what they hold. It's the use of the fields which ...

> +Furthermore we cannot use ``SWAPGS`` as part of context switching, and there's
> +no ``wrgsshadow`` instruction.  All guest GS handling within Xen needs to be
> +altered.

... needs altering then, along with the other adjustments you allude to here.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 06 14:42:09 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 14:42:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865770.1277034 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUoIi-00075z-Qo; Mon, 06 Jan 2025 14:41:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865770.1277034; Mon, 06 Jan 2025 14:41:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUoIi-00075s-Nw; Mon, 06 Jan 2025 14:41:52 +0000
Received: by outflank-mailman (input) for mailman id 865770;
 Mon, 06 Jan 2025 14:41: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 <SRS0=9khw=T6=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tUoIg-00075h-Qi
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 14:41:50 +0000
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com
 [2a00:1450:4864:20::42e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5ca1eac2-cc3c-11ef-a0df-8be0dac302b0;
 Mon, 06 Jan 2025 15:41:49 +0100 (CET)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-3862b40a6e0so7947357f8f.0
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 06:41:49 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c8ac97fsm47415069f8f.92.2025.01.06.06.41.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 06 Jan 2025 06:41:48 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5ca1eac2-cc3c-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736174509; x=1736779309; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=fzPSGaSXvLw8O5qFfodSX1BVmEDbqzNhsRiBtQfmk/0=;
        b=Fe4ARf/ZN691Amm1ayxFrPH0xAkBMO35e2oQvygpQIHwLlWe1kCyk0HcRP7N9kwpbD
         ZfbsjAoz35jJh4qV6jD1hCU+EuvH7Mm0KCwliXarUcygBz43iJ6hoatQjxCr/1G7LEWX
         QUxQYyZBggvcCtQkUFmQCoLRgF79Cir1tHBTt4jop+uiAPEm4VwE3EWHQmdFo4Vp4d2S
         d3PV8xoKtos+RtUO7KztcPi5oEXXj7Bd5jcven0pbxr3DLPcz/+U7nnjkdK/fZ6i2HI+
         MmYaJlNJ2T1w18wCW8HTaP/w2aaQgertYUHJCfngp7lFZBrR87+OnQOAquhjUSwmqbZ6
         YZMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736174509; x=1736779309;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=fzPSGaSXvLw8O5qFfodSX1BVmEDbqzNhsRiBtQfmk/0=;
        b=ZFMld5J71P95ea889+uui5MGfymKyBOfchI/NCkQ1HllOPXFXYDuk4BnG1aO/SiSNi
         7iB1lL5gh8JIRpi+d6pXRFE8MToMAzJu+C8CKjTEaf8V22UDmx1Gu0k9OS76FXf4hQ57
         bfuj6us7qgybx6KRVe84DW41frzNVDc8Pky9CiDwRTVednwkUZPhxZisPt28fPRqQkBK
         ib+COmRyJilBk2riju484kXwPzTzFKQwg+N4aGD4R8DVqGVN6b8/fcucEj88estOhyq0
         v7xyLse2azrUDMq87zGI752W7r+3lykSglSHV2WikHqJnE78JIACNyuuNtqlumyRyTYB
         Aecg==
X-Forwarded-Encrypted: i=1; AJvYcCXvYg/3KeAg4vVEA0Un2edTj54OXOhkHU5dGlmoNJRYSpHN20cIj+f9zItwOdB75DfH36PpLOdGTEg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YySlKLeGj1wlkorKrCdxU4dDD+e7/171NyAF4jTLW3F7DsqkW5Y
	v80fphonxrZgoimAkxshiF000dqUeWzF8bAUJyGA94jfzttfA9oTjt6cU/Wnqw==
X-Gm-Gg: ASbGncvHOuSos+yg5BOyfiAcdylfpUg/s/ReAwVA2+O4bEpWM8gIUcHn6PM+LGHg+4P
	lgQbf12mNFpHu8mJYWPTOvqHLsp9eiesh4jiS1OgIr2doLJUrJ7W7xB6QaK3nK4zXfHgTDb4M1v
	HMx14PlAE74OwgqncxE1JpREcHuE0yvMJoz7M1+d7/6K0WUx/9pnY6Dzd2XkctqGy3OAsusPilT
	dTLgPKDaPj87X2ziZdR9U8hIhA7IKjUnzEzwkxyKWSdwWoM44UEHufQjfELVhgnL/ZEQ3hyzIT9
	NH2F0QoHUZRAZVjRVSv6r13Xbsx39A6ExVcVD0iBFg==
X-Google-Smtp-Source: AGHT+IEorWSFPcmGSKPtJJ/om9Eo0dDS1m5aUQn0ClBGDB3yFozC7WapaVadzS5CFYJRtSK1GrxUBA==
X-Received: by 2002:adf:a342:0:b0:38a:624b:e37b with SMTP id ffacd0b85a97d-38a624be4e4mr13741297f8f.53.1736174508663;
        Mon, 06 Jan 2025 06:41:48 -0800 (PST)
Message-ID: <614a8615-7448-4601-92ff-04217f77a38f@suse.com>
Date: Mon, 6 Jan 2025 15:41:47 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20] x86/amd: Misc setup for Fam1Ah processors
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20250106141929.615831-1-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250106141929.615831-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 06.01.2025 15:19, Andrew Cooper wrote:
> Fam1Ah is similar to Fam19h in these regards.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> CC: Jan Beulich <JBeulich@suse.com>
> CC: Roger Pau Monné <roger.pau@citrix.com>
> 
> With this patch, I think we're in an ok position to declare support on Zen5
> CPUs.

What about amd_log_freq(), where the 0x19 upper bound may need bumping?

> --- a/xen/arch/x86/cpu/microcode/amd.c
> +++ b/xen/arch/x86/cpu/microcode/amd.c
> @@ -114,6 +114,7 @@ static bool verify_patch_size(uint32_t patch_size)
>  #define F16H_MPB_MAX_SIZE 3458
>  #define F17H_MPB_MAX_SIZE 3200
>  #define F19H_MPB_MAX_SIZE 5568
> +#define F1AH_MPB_MAX_SIZE 14368

Yet another pretty odd number. Are these actually documented anywhere?
And what has come of their plan to make ucode size available via CPUID
(for which I even sent a patch quite a long while ago)?

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 06 14:59:02 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 14:59:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865776.1277045 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUoZ5-0000ZU-4L; Mon, 06 Jan 2025 14:58:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865776.1277045; Mon, 06 Jan 2025 14:58:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUoZ5-0000ZN-1d; Mon, 06 Jan 2025 14:58:47 +0000
Received: by outflank-mailman (input) for mailman id 865776;
 Mon, 06 Jan 2025 14:58:46 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=9khw=T6=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tUoZ4-0000ZH-AN
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 14:58:46 +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 b92ddc59-cc3e-11ef-99a4-01e77a169b0f;
 Mon, 06 Jan 2025 15:58:44 +0100 (CET)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-4368a293339so111885385e9.3
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 06:58:44 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436611ea487sm567419575e9.8.2025.01.06.06.58.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 06 Jan 2025 06:58:43 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b92ddc59-cc3e-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736175523; x=1736780323; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=YhFIIEkr/GJ4M5GxwXcyKkBtEuR/1xAwnhwUUHRhLvs=;
        b=fUoYN2J48EV1F9dYVfsiIAIPWM49x2118x8zgfLuJGvhdjODX0T9QV5p7eZT8NFBvI
         ZvzD7t9M+ep95KrTo7cBQB5fSeXNaAx5Y6mspZ9NWOs79ek7IIHOAj0qNTZUMsiz6tyZ
         YP6fMBQarDGXy/UrnCGkabtML9fW5edsuWUJyCiOJZw+VFv70Cv14jeKjb8Op+woNTl3
         osU9ULeVM0jkF7sFlh/fdVNG7kT8CYmFM0iRI0qEHxXNz7AMJYduVNxb3bPnW/sGe88X
         N7ZFuiFSkAd9LcNHEbErEiFNxTNl+rET57LgHIn6plrW/4xcyo5QUC/X9EDaoztqB2+U
         ggEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736175523; x=1736780323;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=YhFIIEkr/GJ4M5GxwXcyKkBtEuR/1xAwnhwUUHRhLvs=;
        b=vwJzReLiQ4Fwc8NrxEaIVuLoNLrW3DaH3z7Wo+NoQecqIH3Y1w5uQBddvEu+MD+l1l
         5jrhZjQsMvMVIEKflq2ujUAPLBRmj0nM/ueG2RdBtLQd2m8StRd1rAfJ5aIVZyv5eSqa
         K8+kVYOHFfp6kIhDoezNeH6ofLb/pMjL7Kmnr8xtAaOx9iLYTXMt2MftHRwF3L0Bg3q1
         zDsg2Ys3sHECBnwJON85v2hPPbZ2+D0NBAOWlV2L8w4+frG0pIhJDr1gHKAMVKjCzRHC
         HD0WEoUATbrQunxAIHs/+7mdwYxxduzGyo1dwKB0CuPIbGZaA6ARrLdKoReL6AJyTsoq
         TVhw==
X-Forwarded-Encrypted: i=1; AJvYcCUZHNVfdFwcB7T8F8GpH0lP8dYebto+kzYDMyy6BSYKFXsoqgKyxE2cbi3rxnLH3yjHtFQtqRjO8ng=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxrs3+K65TnkMT/zOMoO66+lUBXvnDAfq7m+dOJKWeZ+0ApfePx
	SFCWfnHc6LnXD4JunuSUf+QLyx017fpHlbnexk9J2gu6hjIbaCvGxhc3iQfoBQ==
X-Gm-Gg: ASbGncuPc+QGUhYzTynZefzUyihl5cA3Gw7yhuAKfkMkYr5ne6p6mLyaykx2G2HAyCY
	6m9eODfnaKfXK1yHTUdjLhcOaMJ8eOnRRTxQfx/mNVg/OvDHAb2r3wQkYps31yRgkdEs/1NKjrI
	p7+z2OUL7LJPnkDSof3T8C2Ac7csnQhSgsp60hzG3vle84Tim3igwA6dC3wYArsw5G+bPLqDus6
	zgCXE0suMX77+gs73q56zfd0q4aP9QILdjWQi3mCy1HRprm2wRVJneabs8/ENhNhZhQPC2OrUc6
	R1lvI4Zim2dCkdz+bSPAcA8E7u3VZaKYYAE+J1HZMQ==
X-Google-Smtp-Source: AGHT+IHLybgUg1D9p5Nly5aMT4acGCVC2qeQavhuwBUTIHlTBqfVB6Hoi9/i/5hL/Wm4No06mIwnvw==
X-Received: by 2002:a05:600c:a0a:b0:434:a781:f5d5 with SMTP id 5b1f17b1804b1-43668b93ca2mr518166105e9.30.1736175523347;
        Mon, 06 Jan 2025 06:58:43 -0800 (PST)
Message-ID: <8fc662a1-4c74-4f97-a116-3bc5a0b71cf1@suse.com>
Date: Mon, 6 Jan 2025 15:58:41 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v1] xen: mem_access: conditionally compile vm_event.c
 & monitor.c
To: Tamas K Lengyel <tamas@tklengyel.com>
Cc: Sergiy Kibrik <Sergiy_Kibrik@epam.com>,
 Stefano Stabellini <stefano.stabellini@amd.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Alexandru Isaila <aisaila@bitdefender.com>,
 Petre Pircalabu <ppircalabu@bitdefender.com>, xen-devel@lists.xenproject.org
References: <20241230063051.3332332-1-Sergiy_Kibrik@epam.com>
 <c8684340-33f9-41d3-94e4-77ee3bc18306@suse.com>
 <CABfawhk4pzA9bSMzJDX7ZwaYC50dfn_ntCnk=bePmiKCpDnN3w@mail.gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <CABfawhk4pzA9bSMzJDX7ZwaYC50dfn_ntCnk=bePmiKCpDnN3w@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 06.01.2025 15:05, Tamas K Lengyel wrote:
> On Mon, Jan 6, 2025 at 5:16 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 30.12.2024 07:30, Sergiy Kibrik wrote:
>>> From: Stefano Stabellini <stefano.stabellini@amd.com>
>>>
>>> Extend coverage of CONFIG_MEM_ACCESS option and make the build of VM events
>>> and monitoring support optional.
>>
>> Yet doesn't this end up in things becoming misleading? Don't we rather need a
>> 2nd Kconfig option, with a dependency between the two? Or alternatively a
>> rename of the existing option (to describe the higher-level feature rather
>> than the lower level one)? Tamas, I'm particularly interested in knowing your
>> view here as well.
> 
> Thanks Jan, I was thinking the same thing. The dependency of these
> subsystems is mem_access -> monitor -> vm_event. If the goal here is
> to disable all three levels the ideal way would be to have separate
> kconfig options for each level. It may be a bit too fine-grained
> though on ARM since there are only two types of events for monitor
> (SMC & mem_access) and only the monitor uses the vm_event channel (no
> mem-sharing/paging on ARM). So if doing separate kconfig for each
> individual feature is an overkill I would suggest using
> CONFIG_VM_EVENT that disables all three levels, including both
> mem_access & smc monitor hooks.

Except that "disables all three levels" doesn't work, unless the other
option(s) are promptless (and selected). I'd have expected VM_EVENT to
maybe have a "depends on MEM_ACCESS", whereas a "select MEM_ACCESS"
wouldn't make much sense as long as MEM_ACCESS can be enabled
individually (with it being unclear to me whether such a configuration
is actually useful in any way).

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 06 15:12:39 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 15:12:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865784.1277055 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUomB-0003U6-96; Mon, 06 Jan 2025 15:12:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865784.1277055; Mon, 06 Jan 2025 15:12:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUomB-0003Tz-4o; Mon, 06 Jan 2025 15:12:19 +0000
Received: by outflank-mailman (input) for mailman id 865784;
 Mon, 06 Jan 2025 15:12: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
 <SRS0=bFJS=T6=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tUomA-0003Tt-2A
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 15:12:18 +0000
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com
 [2a00:1450:4864:20::333])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9c88e11a-cc40-11ef-99a4-01e77a169b0f;
 Mon, 06 Jan 2025 16:12:15 +0100 (CET)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-4361dc6322fso96435575e9.3
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 07:12:14 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-43656b441bbsm601761155e9.40.2025.01.06.07.12.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 06 Jan 2025 07:12:13 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9c88e11a-cc40-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736176334; x=1736781134; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=g6R7nBfdPYOAfqn6J6sPZHBRG7XPQaze5bNkfLa/gVA=;
        b=gS80TpRQkTS+s14rj6sOMNmv9En+DfpcjDtNxgP3FVkSVUvzRFiHOMstNFM3z3dDEK
         nK+CrY2G8UselrB474R8nT4YxMtF2LrmozER0K5cWl+GXqd9eoYLe88Ba2neabRsFPp8
         XqXHkYOdxvhEFYSdeU9TuG8thtBQX/ibGTGQk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736176334; x=1736781134;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=g6R7nBfdPYOAfqn6J6sPZHBRG7XPQaze5bNkfLa/gVA=;
        b=kUJQPgSM3qvWiR8c3ZxR0QAnylPmismHpVXEsJXeTH3gtjRGzSOYdNYp8k2sdUICce
         TD3BqyiDPMlose+nmgWpwKD070d15gY9k+UutsdMRRe5485SdniGTEqbuU4+lTjrdrsv
         pBuZq9jke+hY/u/pKTqXhlT7cOvL3N7N7GecfT8SSbSC6GOk3HaO1lUrwvse6XaU4BWN
         mkAnJx+BSNMy+GbVT/ibAXuVjcoRJqqSLl7T/PX5nrArESJNgj/nygRpMEM5PUQL2ggr
         bLsrzAt8lucQ/ljkneDpmUaEWHN8fDZUQ4Du4Y4K1dHe1p0Zf+5xuT1kl8s8i2OkieMk
         OqVg==
X-Forwarded-Encrypted: i=1; AJvYcCWi9aBBgXEaZ1K9Aaxu8JwYkTuO33YK2jklF0mEfgSqm+VwrFbVxE2WvlDLadxN2g7NeY+hJUXow6Q=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzVCRzbjhWIJUhEtyJxlTlBnAk7q6U8kp266FLnsrBK5hum3sbF
	UE+8t43HA8/LTJlBJRT4MKQanm+vDp4s6sLgM7IoAqieYtGhKqk3OWG1ids6R4Q=
X-Gm-Gg: ASbGncsvwnw9wA1kkq02PF4T0MkkOZ/kT4BJEO9L7ZT/ymBFUIrPhjpLBsLJOKBCeq9
	8iIf631PL7WFWX4kwOnRGd9zIVCuXA0hIAnFqzWOQGcvca6FILwL9A4rU20KW1oNCy5U7KWwpnU
	oXndg2x5ufVRSDNMQipYbDAFMnFBOEMpUT9EK4ygU/tA67NmpovZvsq22f0ZuxI9ZZQialT1s/2
	aro8BW/fvhylAiyMl9w8PzxYnLwX4mQLtM8Capxh9iMqbSJzdRG/qXCO+BQOxT8BhoWlWL6FEcm
	CCccbqyV1W12+ZZOvzhb
X-Google-Smtp-Source: AGHT+IGYTdtvd1bfoW8N1SfsdyVHOgxtZgK81pwpUXrArepWF1zv7CuFpabBQam2QOR5nFzaSaPldQ==
X-Received: by 2002:a05:600c:1987:b0:434:fbcd:1382 with SMTP id 5b1f17b1804b1-43668643a39mr470570865e9.11.1736176334393;
        Mon, 06 Jan 2025 07:12:14 -0800 (PST)
Message-ID: <b9e16f7f-9af5-4faf-b4f2-88913cb35910@citrix.com>
Date: Mon, 6 Jan 2025 15:12:13 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20] x86/amd: Misc setup for Fam1Ah processors
To: Jan Beulich <jbeulich@suse.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20250106141929.615831-1-andrew.cooper3@citrix.com>
 <614a8615-7448-4601-92ff-04217f77a38f@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <614a8615-7448-4601-92ff-04217f77a38f@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 06/01/2025 2:41 pm, Jan Beulich wrote:
> On 06.01.2025 15:19, Andrew Cooper wrote:
>> Fam1Ah is similar to Fam19h in these regards.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> ---
>> CC: Jan Beulich <JBeulich@suse.com>
>> CC: Roger Pau Monné <roger.pau@citrix.com>
>>
>> With this patch, I think we're in an ok position to declare support on Zen5
>> CPUs.
> What about amd_log_freq(), where the 0x19 upper bound may need bumping?

Ah, that's new since I did Fam19.  I'll adjust.

>
>> --- a/xen/arch/x86/cpu/microcode/amd.c
>> +++ b/xen/arch/x86/cpu/microcode/amd.c
>> @@ -114,6 +114,7 @@ static bool verify_patch_size(uint32_t patch_size)
>>  #define F16H_MPB_MAX_SIZE 3458
>>  #define F17H_MPB_MAX_SIZE 3200
>>  #define F19H_MPB_MAX_SIZE 5568
>> +#define F1AH_MPB_MAX_SIZE 14368
> Yet another pretty odd number. Are these actually documented anywhere?

In the PPRs.

> And what has come of their plan to make ucode size available via CPUID
> (for which I even sent a patch quite a long while ago)?

This check in this function need to work for any microcode we find in
the container.  Knowing the size of the current CPU doesn't help parsing
others.

And talking of, I've just found another Fam1Ah processor with an even
larger patch size.  This limit needs bumping to 15296.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Jan 06 15:18:05 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 15:18:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865791.1277064 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUorU-000459-R0; Mon, 06 Jan 2025 15:17:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865791.1277064; Mon, 06 Jan 2025 15:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUorU-000452-OJ; Mon, 06 Jan 2025 15:17:48 +0000
Received: by outflank-mailman (input) for mailman id 865791;
 Mon, 06 Jan 2025 15:17:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=9khw=T6=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tUorT-00044u-6q
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 15:17:47 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6138e45e-cc41-11ef-99a4-01e77a169b0f;
 Mon, 06 Jan 2025 16:17:44 +0100 (CET)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-aa684b6d9c7so2407416666b.2
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 07:17:44 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0e8961a6sm2251358266b.57.2025.01.06.07.17.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 06 Jan 2025 07:17:43 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 6138e45e-cc41-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736176664; x=1736781464; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=PBENscGXSssOQsfLgY+dJ8hJ1pHLNpMtvOl6CjSIo0U=;
        b=M+PYcmKSVkYGTTtb3qiWJ37usquail5bDRjkMC+g4VP4oF9kXlyAek0Ir23Z+mAw5b
         JtQGtr30Z9F/W40N5wC4hoG7mzLmRxK7d3jytlRYnROBALIQaLCelfGHNRm+M9JUsHNz
         zxW5MkjvUkNBV+j7VOGCSgx1iAv99NxkD7bWRB7tof3Yi/whSeBcaaW+9+geTgHiaTVL
         WvnCjCQAAmNWdgyqfMzsYhEQ4kmq/vgkU+MnaePYd7d85uuZmibPpGrW5K6OAbSHEZ1P
         0JOdSG62NvcJ2LZwYW9X9Byt51S/GJOjrwL/4wKJWdLpDUQ2GiohFNAMZCKzysZk5dQ5
         J5lQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736176664; x=1736781464;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=PBENscGXSssOQsfLgY+dJ8hJ1pHLNpMtvOl6CjSIo0U=;
        b=Cy7sKIDT5k4LujkaLGun3mD/D5GRiMxURBV/d+GfUcqdvMQYPi0pAdSXL3JQtpEDp6
         3lF1Ahni/RjTRTXteW0/JOQt22IrWK1wX7A+ljqnK2DwH4Ko5GIv6oLcFe6g01Mbp8gc
         +Z52VqlVGYWw9vD8fvpTnrPe8tf/2WquUTGGnqb34s6nwm3bULumMFdPiB2x4jvfJFdY
         c+eIIcqE2mrKj7ggTx3dvghaMSKowSFdoB5cX9lPYaoTvmvZwK6artBwYh3qkCtU7Z7d
         UTIe1iphE6XnCQIJM2Z+yUQ9PGwZ/HYmaY9OfV548Og8g1XgUw1jaajgzQ82d+UpW0VC
         1QCw==
X-Forwarded-Encrypted: i=1; AJvYcCVnfP9dP3/mQ1M7DSNDaoIW7isdNDKo6+NBuKBxYXCBg8uASeIe0DYSLIqhnpjY+nIhC0kuehIFysM=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw+rBS6YFtX6TtzJYeQmYwIVeX93OQHkMrFOxhd9pUn8vC5dA+f
	dIqs0Aul7yTmQsXU9vb/EZl/2XmJc32Cqe8CHbPlf0DA6QdVikemC22FBMTWxg==
X-Gm-Gg: ASbGncuPW+0nLAakSbvfhXR4xQaEi5iI0f32x0xLVcF0+Ly3HxkdPhKuqmYRlaT2xDV
	l9ojSY4LacXj4j5pCXES9TZQykDEFoF1AtScvM7e1BC8WQ8gt1j1rltjIYlA23l0sTOVTe7Osks
	1nQH7bTuFxaF+rg7no6E/Fho/232pAXeounY9fyggSJYWZ+LE+MGWmu2ga4t8Zj17gctdvizdi3
	j4z1I2cNXM9S/s6Kn5xDHuNJ5Ftj+KZwX+xXxnEKzzIG9rrT8au2rMTvBZii2PS7XRDa+HgMr6Q
	s4NgOmHqSVtMZ7NlDMvKVKzo/s1Mj5y1dN9uyx2MXA==
X-Google-Smtp-Source: AGHT+IHdFVJV3PZH1UqE+6TGo5Bya59SuVPvdx8+n3OWbhtYhD0xSLPIOT6yb9W9+FIOY1Hwk7nWJg==
X-Received: by 2002:a17:907:940c:b0:aa6:82ea:69d6 with SMTP id a640c23a62f3a-aac2ad9e63dmr6481165166b.18.1736176664296;
        Mon, 06 Jan 2025 07:17:44 -0800 (PST)
Message-ID: <1a64a0a8-1f03-439c-8979-37315e147f2f@suse.com>
Date: Mon, 6 Jan 2025 16:17:43 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20] x86/amd: Misc setup for Fam1Ah processors
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20250106141929.615831-1-andrew.cooper3@citrix.com>
 <614a8615-7448-4601-92ff-04217f77a38f@suse.com>
 <b9e16f7f-9af5-4faf-b4f2-88913cb35910@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <b9e16f7f-9af5-4faf-b4f2-88913cb35910@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 06.01.2025 16:12, Andrew Cooper wrote:
> On 06/01/2025 2:41 pm, Jan Beulich wrote:
>> On 06.01.2025 15:19, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/cpu/microcode/amd.c
>>> +++ b/xen/arch/x86/cpu/microcode/amd.c
>>> @@ -114,6 +114,7 @@ static bool verify_patch_size(uint32_t patch_size)
>>>  #define F16H_MPB_MAX_SIZE 3458
>>>  #define F17H_MPB_MAX_SIZE 3200
>>>  #define F19H_MPB_MAX_SIZE 5568
>>> +#define F1AH_MPB_MAX_SIZE 14368
>> Yet another pretty odd number. Are these actually documented anywhere?
> 
> In the PPRs.

So to find the number to use it's really ...

>> And what has come of their plan to make ucode size available via CPUID
>> (for which I even sent a patch quite a long while ago)?
> 
> This check in this function need to work for any microcode we find in
> the container.  Knowing the size of the current CPU doesn't help parsing
> others.
> 
> And talking of, I've just found another Fam1Ah processor with an even
> larger patch size.  This limit needs bumping to 15296.

... digging through the PPRs (and hoping no later model will have yet
larger size).

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 06 15:21:17 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 15:21:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865800.1277076 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUoul-0005pL-Ch; Mon, 06 Jan 2025 15:21:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865800.1277076; Mon, 06 Jan 2025 15:21:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUoul-0005pE-89; Mon, 06 Jan 2025 15:21:11 +0000
Received: by outflank-mailman (input) for mailman id 865800;
 Mon, 06 Jan 2025 15:21:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=bFJS=T6=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tUouj-0005p8-Dv
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 15:21:09 +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 da78fa6a-cc41-11ef-a0df-8be0dac302b0;
 Mon, 06 Jan 2025 16:21:08 +0100 (CET)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-4368a293339so112177325e9.3
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 07:21:08 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4366127c4d7sm570158885e9.34.2025.01.06.07.21.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 06 Jan 2025 07:21:07 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: da78fa6a-cc41-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736176868; x=1736781668; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=EH1shQVRc07v2WniIk/ZX+xJdmK7Hf6LR7Uk8d7Kc7U=;
        b=FVe8JomsESXUcA4Oa9/EtLO3vd6hS3Gh94HlN8hMsBAmT8MiZM8Vovd9Y2y4seRdGa
         lPGMlOFxP37OxnnUifIlaT3UYmHvrnnqvid8nOaK/twnD2YcsBa9WvP2Nn4yW+O87aFG
         BlylrfEtNM2B2u/KBayuzjfyLpTgYb5wzVk3I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736176868; x=1736781668;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=EH1shQVRc07v2WniIk/ZX+xJdmK7Hf6LR7Uk8d7Kc7U=;
        b=dI32cKTvHiQYc7FXmWijYALx5rg4ml0TcrD3nq+JVSh1QRsBhjfloiiIGOAGvhszU2
         zkx/UZP8wa3uh+nSXCGWrnSPPj5NcEojzlL7011MehCHhVI/lXYpBAdaQ6CTGPjh2AC+
         OTrj1MVWq9IQhyi2TXDklHDXMT6EPoefBF8QbmgcQpxzZdzQkEnpkrpKnu+guujACAcp
         X0UNCRGnEpwMlRSIFSAcYQ84h5RKtuUwF6iO2xNGo1AT1wmhuyeS3yl+UAVbFtTIgvM0
         l7gEpzNkkr0q3rB6NlsA6ovzyKSYxwCosxNUF+NPuJ3p6TQKER9rhJ0nXvlgpQuZXIWZ
         X2Vw==
X-Forwarded-Encrypted: i=1; AJvYcCV9ePRbo6GUoDhVergsY00tjxgTLtxCMUJaYdq31Lf5rFjcw0J4ftw7JJh3hjANawlr9MvXicS0jmI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxvU/IUyPRonBnhsmK5EXP5ibaYC/SBL6FjR4xwL29qtQyFhsrz
	JhFObYVatJnGVWVnJxz6hFHoFDyLzyApO+/PfPmADnD9JGinnwZC0wvvRWRZsvs=
X-Gm-Gg: ASbGnctB6ZgBtc3fpoIgXRG+vw7eh/d4jf8pFoyCScBYd2WLeUSBaG0++cCJteAjIgf
	CewT49d1T8j7s5HEPXyo3vD+STbFVIcolfuB7NY+MD51hMRTAuz5a9Kjt8RaYjrq1rxt6+l5z61
	TEuAzaAxLOAjcCzVJS0X1PkeQVyDu1Z97LOkFbtP/y9Td93GA3Gpb9G1kVxzfnSatiZt65Mu0al
	0lW6Zvt0YHq4TlWrGSeSJsI0/llfIH/MqWim6NBOP3Ips7/oVTG1D+Dwqk1wclBd02j66p3owbO
	cShVPAAU8eJwqNfOEdV8
X-Google-Smtp-Source: AGHT+IEWmmRpu+OwIoAHpSZXUorjqcEk2hSxGjFlqUe3wZe0T2C/XXKv3340bwqzejDpH4NcIj0Kbg==
X-Received: by 2002:a05:600c:4e4b:b0:434:fa61:fdfb with SMTP id 5b1f17b1804b1-4368d6941femr393044025e9.18.1736176867787;
        Mon, 06 Jan 2025 07:21:07 -0800 (PST)
Message-ID: <0c9fbbc9-7276-4ffb-8f48-521ba68d1508@citrix.com>
Date: Mon, 6 Jan 2025 15:21:06 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20] x86/amd: Misc setup for Fam1Ah processors
To: Jan Beulich <jbeulich@suse.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20250106141929.615831-1-andrew.cooper3@citrix.com>
 <614a8615-7448-4601-92ff-04217f77a38f@suse.com>
 <b9e16f7f-9af5-4faf-b4f2-88913cb35910@citrix.com>
 <1a64a0a8-1f03-439c-8979-37315e147f2f@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <1a64a0a8-1f03-439c-8979-37315e147f2f@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 06/01/2025 3:17 pm, Jan Beulich wrote:
> On 06.01.2025 16:12, Andrew Cooper wrote:
>> On 06/01/2025 2:41 pm, Jan Beulich wrote:
>>> On 06.01.2025 15:19, Andrew Cooper wrote:
>>>> --- a/xen/arch/x86/cpu/microcode/amd.c
>>>> +++ b/xen/arch/x86/cpu/microcode/amd.c
>>>> @@ -114,6 +114,7 @@ static bool verify_patch_size(uint32_t patch_size)
>>>>  #define F16H_MPB_MAX_SIZE 3458
>>>>  #define F17H_MPB_MAX_SIZE 3200
>>>>  #define F19H_MPB_MAX_SIZE 5568
>>>> +#define F1AH_MPB_MAX_SIZE 14368
>>> Yet another pretty odd number. Are these actually documented anywhere?
>> In the PPRs.
> So to find the number to use it's really ...
>
>>> And what has come of their plan to make ucode size available via CPUID
>>> (for which I even sent a patch quite a long while ago)?
>> This check in this function need to work for any microcode we find in
>> the container.  Knowing the size of the current CPU doesn't help parsing
>> others.
>>
>> And talking of, I've just found another Fam1Ah processor with an even
>> larger patch size.  This limit needs bumping to 15296.
> ... digging through the PPRs (and hoping no later model will have yet
> larger size).

Correct.  I'd prefer a better approach, but alas.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Jan 06 16:06:19 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 16:06:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865808.1277084 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUpcK-0003LK-EL; Mon, 06 Jan 2025 16:06:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865808.1277084; Mon, 06 Jan 2025 16:06:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUpcK-0003LD-Be; Mon, 06 Jan 2025 16:06:12 +0000
Received: by outflank-mailman (input) for mailman id 865808;
 Mon, 06 Jan 2025 16:06: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
 <SRS0=bFJS=T6=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tUpcI-0003L7-Ei
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 16:06:10 +0000
Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com
 [2a00:1450:4864:20::342])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2384500f-cc48-11ef-99a4-01e77a169b0f;
 Mon, 06 Jan 2025 17:06:07 +0100 (CET)
Received: by mail-wm1-x342.google.com with SMTP id
 5b1f17b1804b1-4361e89b6daso100139375e9.3
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 08:06:07 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436611ea3d5sm577248235e9.5.2025.01.06.08.06.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 06 Jan 2025 08:06:06 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2384500f-cc48-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736179567; x=1736784367; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=sqtUllqRRSjtiO3bV61StOV77JG434AGCX4IEmWprCk=;
        b=qzThdz303nQvbUVJ8LMWNj6S46AggtzmT5Uxe6ftJtDzkIUpsajd59bbjLMHBFkF07
         lWlaKJvRQSYbA+CL88ffCI+fI7P72aTB8EXsYCISkhn+49KPOeVkzqpcHc0so0nDIBcW
         XvbZSpI5jgcTzxfGj97krLeJjUFhHFd1ZqIQw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736179567; x=1736784367;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=sqtUllqRRSjtiO3bV61StOV77JG434AGCX4IEmWprCk=;
        b=rv9SBSv2IEfYPv4G2uZ8gndm60QRQeHWqZ3Qc/hfADpqaCMLMB2Z5uzsu46/MrW1hd
         RWMmGMeY0dr3wL8bGsZ03oE5pxe4YVKLC9z6JM6PICsw+hA5rg3yf5O1Q2NQf+nFPZ4P
         fm7O/dzAMUAl5BrMqZTRlIASm+LYNuUZp7yBTHnuVCpSVtgnvF0OYA5tE1BcPJQk3hFL
         ApBb6sMkZftBrvXEkGRicVO4kKUzjnmWQfuwV9hVtLHiyWtBqKO1CG4ekq7ZikVMKNin
         xqwoBKSDkcyo2uFVH8wwvxY+TZNFRlIEo+AIB53KJ9C7PD4gYSPveRENQJxkzb1hEKW8
         ihwA==
X-Forwarded-Encrypted: i=1; AJvYcCXY7fcOUI0Bqk+v8xJaW0OBqkFW3nCbGPbfcim+DPeSM5C+Af68+aY1QHPqfnsMQECKZuhyzn7TTMQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyvzMxN3BA8ESR+uacH5aYKC6rHxMAMMslkEkR6MD31Pnfb2tFR
	o0r6kGJP5mBLmU0zYHKR2dwhm3dvm8U/4AG6HqSWi4Nkp5H12IVaHVsFGgyz94A=
X-Gm-Gg: ASbGncttpfBO9HS4u3bSwjg+bS/kdEKOUwiMl38gxcjx6jTDgENpeNz+S/VLrLPbSJg
	W4ejYlnrtVGPrn93RsBwzYNfZlvwnXGDhMJG6JayvKivFYmh1W4MVeQqIK22XFEdoabYu1oLhba
	vgXWcnpuScaEFxCo65hpfPBRBjPZLpqNNUoR9AUp6+15t4bYhs+uUqXrLQ7X1y7fefHhUqxq9IG
	ZW7Ie/cjnQGUys6A7kJ/UkfwThXTsKZkVakm0cpCWpbeATmYM0S3YPez1h3VXxWKDW0EFsCYuOr
	W0mEne5lfvP3YV3KeUd/
X-Google-Smtp-Source: AGHT+IGfr/CLnuBkL/5R0DWvKX8MLzs+iMSzfkJWSkM5xskM+SrfO2rkBWV7QdQdah2YI7JScVO5aw==
X-Received: by 2002:a05:600c:1c87:b0:434:a10f:c3 with SMTP id 5b1f17b1804b1-4366864320emr522028595e9.9.1736179566966;
        Mon, 06 Jan 2025 08:06:06 -0800 (PST)
Message-ID: <0a780f2d-1e49-47bd-8c66-babbc2dd8f63@citrix.com>
Date: Mon, 6 Jan 2025 16:06:05 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC] docs: FRED support in Xen
To: Jan Beulich <jbeulich@suse.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20250103204704.84067-1-andrew.cooper3@citrix.com>
 <3ff59df0-69f8-426a-ab44-d2cd9b5bf8ea@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <3ff59df0-69f8-426a-ab44-d2cd9b5bf8ea@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 06/01/2025 2:28 pm, Jan Beulich wrote:
> On 03.01.2025 21:47, Andrew Cooper wrote:
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> ---
>> CC: Jan Beulich <JBeulich@suse.com>
>> CC: Roger Pau Monné <roger.pau@citrix.com>
>>
>> An initial RFC discussion and plan.  Open TODOs are at the end.
>>
>> This can be viewed online at:
>>   https://andrewcoop-xen.readthedocs.io/en/docs-devel/hypervisor-guide/x86/fred.html
>>
>> I've got an 8-patch series doing the cpu_user_regs disentangling vs the public
>> API.  That's in pretty good shape now.
>>
>> FRED itself is orders and orders of magnitude more simple than IDT, both in
>> terms of setup and operation, but I'm in the middle of a very large
>> cleanup (35 patches and count) to setup.c and trap.c in order to make FRED
>> able to be cleanly integrated into Xen, and that's still before any of the GS
>> changes to keep PV guests functioning correctly.
>> ---
>>  docs/glossary.rst                   |   7 +
>>  docs/hypervisor-guide/x86/fred.rst  | 215 ++++++++++++++++++++++++++++
>>  docs/hypervisor-guide/x86/index.rst |   1 +
>>  3 files changed, 223 insertions(+)
>>  create mode 100644 docs/hypervisor-guide/x86/fred.rst
>>
>> diff --git a/docs/glossary.rst b/docs/glossary.rst
>> index 6adeec77e14c..18502c0474f7 100644
>> --- a/docs/glossary.rst
>> +++ b/docs/glossary.rst
>> @@ -43,6 +43,13 @@ Glossary
>>       Sapphire Rapids (Server, 2023) CPUs.  AMD support only CET-SS, starting
>>       with Zen3 (Both client and server, 2020) CPUs.
>>  
>> +   FRED
>> +     Flexible Return and Event Delivery is a facility in x86 CPUs which
>> +     overhauls how system calls, interrupt and exception handling works.
>> +
>> +     Intel support for FRED is slated for Panther Lake (Client) and Diamond
>> +     Rapids (Server).
>> +
>>     guest
>>       The term 'guest' has two different meanings, depending on context, and
>>       should not be confused with :term:`domain`.
>> diff --git a/docs/hypervisor-guide/x86/fred.rst b/docs/hypervisor-guide/x86/fred.rst
>> new file mode 100644
>> index 000000000000..68146b79bdfc
>> --- /dev/null
>> +++ b/docs/hypervisor-guide/x86/fred.rst
>> @@ -0,0 +1,215 @@
>> +.. SPDX-License-Identifier: CC-BY-4.0
>> +
>> +FRED: Flexible Return and Event Delivery
>> +========================================
>> +
>> +Overview
>> +--------
>> +
>> +FRED was originally intended to improve performance (reading and parsing the
>> +IDT, GDT/LDT and possibly the TSS is a bottleneck) and to provide an
>> +extensible mechanism to overcome other limitations in the future (e.g. support
>> +for more than 256 interrupt vectors).  During development, FRED was adjusted
>> +substantially to also fix lots of technical debt that had accumulated in the
>> +x86 architecture for the past 40 years, most of which is a fertile source of
>> +crashes and privilege escalation bugs.
>> +
>> +FRED is primarily concerned with establishing a new context when an event is
>> +recognised, and restoring the old context when the event is handled.  This
>> +includes events previously delivered through the IDT (exceptions and
>> +interrupts), as well as ``SYSCALL`` and ``SYSENTER`` instructions which
>> +avoided the IDT in the past for performance reasons.
>> +
>> +FRED strives to achieve that event delivery always establishes a good CPL0
>> +stack (and shadow stack if CET is active), that doesn't clobber still-active
>> +state from an outer nested context, and with the CPL0 GSBASE.
>> +
>> +Technical details
>> +-----------------
>> +
>> +When FRED is active, Rings 1 and 2 cannot be entered at all, Ring0
>> +compatibility mode cant be entered (i.e. Ring0 is strictly 64bit), and
>> +``IRET`` can no longer change privilege.  Call Gates no longer exist.
>> +
>> +A single entrypoint is registered in ``MSR_FRED_CONFIG``.  Entries from Ring3
>> +start at this address, while entries from Ring0 start at +256.  All
>> +interrupts, exceptions and syscalls route these.  VMExits do not, and retain
>> +their prior behaviour.
>> +
>> +There are 4 Stack Levels, SL 0 thru 3 and a notion of Current Stack Level,
>> +replacing the prior IST mechanism.  All stack pointers, and shadow stack
>> +pointers when CET-SS is active, are registered in ``MSR_{R,S}SP_SL{0..3}``.
>> +Supervisor Shadow Stack tokens no longer exist, and are replaced with an
>> +alternative mechanism.
>> +
>> +The IDT is no longer used.  The TSS is no longer used used to hold stack
>> +pointers, nor ``MSR_ISST`` if CET Shadow Stacks are active.  ``MSR_{L,C}STAR``
>> +as well as all SYSENTER MSRs are no longer used.  Under FRED, ``MSR_STAR`` and
>> +``MSR_FMASK`` are used with their previous behaviour extended to all event
>> +deliveries, not just syscalls.
>> +
>> +The instructions ``SWAPGS``, ``CLRSSBSY``, ``SETSSBSY``, ``SYSEXIT`` and
>> +``SYSRET`` unconditionally ``#UD``.  Establishing an initial SSP should use
>> +``RSTORSSP``.  GS maintenance can use the new ``LKGS`` instruction.
>> +
>> +Implementation considerations
>> +-----------------------------
>> +
>> +PV32 guests
>> +"""""""""""
>> +
>> +FRED formally removes the ability to use Rings 1 and 2, which prohibits the
>> +use of PV32 guests.  PV32 guests are already disabled by default in the
>> +presence of CET owing to the difficulty of using Ring 1 with CET active.
>> +Compatibility for PV32 guests is provided by PVShim, which takes care not to
>> +use CET in order to be able to run PV32 guests.  FRED can use the same
>> +approach.
>> +
>> +Initialisation
>> +""""""""""""""
>> +
>> +Exception handling is initialised right at the beginning of ``__start_xen()``
>> +prior to parsing the command line.  Having exception cover this early is
>> +important and wants to remain.
>> +
>> +The determination of whether to use FRED or not needs to account for the
>> +``fred`` and ``pvshim`` command line options, the ``FRED`` and ``LKGS`` CPUID
>> +bits.
>> +
>> +Therefore for simplicity, early exception handling will still use IDT
>> +delivery, and later setup can switch to FRED instead.
>> +
>> +cpu_user_regs vs vm86 segments
>> +""""""""""""""""""""""""""""""
>> +
>> +``struct cpu_user_regs`` exists in the public interface, and is embedded
>> +inside ``struct vcpu_guest_context``.  From an ABI perspective, the layout
>> +needs to remain.  ``struct cpu_user_regs`` is also a common name in Xen,
>> +covering the event information (pushed by hardware and software) and the GPRs
>> +(pushed by software).  From an API perspective, the name needs to remain.
>> +
>> +The data selectors (ds, es, fs, gs) are a vestigial remnant of vm86 mode.
>> +Hardware did push them on exit from vm86 mode, and ``IRET`` would consume them
>> +on the way back in.
>> +
>> +However, vm86 mode isn't usable in Long mode, and these selectors oughtn't to
>> +have survived into the PV64 ABI.  Under FRED, hardware pushes different
>> +information here, which needs accounting for in Xen's view of ``struct
>> +cpu_user_regs``.
>> +
>> +Therefore, the only option is to have the public API provide a struct by a
>> +different name, and provide a compatibility define for the ``!__XEN__`` case,
>> +freeing us up to have a similar but not identical ``struct cpu_user_regs``
>> +which Xen operates on.
>> +
>> +There are several uses of the vm86 fields in Xen:
>> +
>> + #. ``struct vcpu`` embeds a ``struct cpu_user_regs`` to hold GPRs/etc when
>> +    the vCPU is scheduled out.  The vm86 fields are used by the PV logic only
>> +    (``{save,load}_segments()``) and can be moved into separate fields in
>> +    ``struct pv_vcpu``.  PV's ``dom0_construct()`` sets these fields directly,
>> +    and needs a matching adjustment.
>> +
>> + #. As part of ``arch_{get,set}_info_guest()`` during hypercalls.  The
>> +    guest side needs to remain as-is, but the Xen side can rearranged to use
>> +    the new fields from above.
>> +
>> + #. As part of vCPU diagnostics (``show_registers()`` etc).  The ``#DF`` path
>> +    uses the fields as scratch storage for the current register values, while
>> +    the other diagnostics are simply accessing the state of a scheduled-out
>> +    vCPU.
> Unlike for the former 2 points and for the one immediately below, but like for
> the final one below you don't mention what you intend to do. Here I assume it'll
> be reasonably straightforward to use scratch space elsewhere.

https://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=shortlog;h=refs/heads/xen-fred
is my working branch if you want to peek at things.

The diagnostics are handled by:

1) "x86/traps: Rework register state printing to use an extra_state struct"
2) "x86/traps: Avoid OoB accesses to print the data selectors"
3) "Revert "x86/traps: 'Fix' safety of read_registers() in #DF path""


Something else you might want to proactively look at.  "x86/idt:
Generate bsp_idt[] at build time".  I figured out how to construct the
IDT at build time, without using an external tool to format the table,
and only some slightly disgusting linker script hackery.

>
>> + #. In HVM's ``hvm_sanitize_regs_fields()``, to poison the fields and make
>> +    them more obvious if used anywhere in HVM context.  This can simply be
>> +    deleted.
>> +
>> + #. In x86_emulate.c's ``put_fpu()``.  As far as I can tell, this is
>> +    completely buggy; the values will be poisoned for HVM guests, and stale
>> +    from the prior context switch for PV guests.
> For HVM guests the ->read_segment() hook will be populated, so the path isn't
> taken (leaving aside the odd case of the hook failing). For PV guests I don't
> see any staleness concern: When the vCPU was switched in, the fields were set
> (restored), weren't they?

There is up to 30ms of guest runtime between the last schedule in and
this emulation, and segment loads don't generally trap for PV guests.

> For the purpose of FRED this doesn't matter much - wherever the values are to
> be held, they'll be taken from by put_fpu().

I maybe wasn't clear.  To support FRED, I need to delete the vm86 fields.

@@ -54,10 +54,6 @@ struct cpu_user_regs
     DECL_REG_LO16(flags); /* rflags.IF == !saved_upcall_mask */
     DECL_REG_LO8(sp);
     uint16_t ss, _pad2[3];
-    uint16_t es, _pad3[3];
-    uint16_t ds, _pad4[3];
-    uint16_t fs, _pad5[3];
-    uint16_t gs, _pad6[3];
+    uint64_t edata, _rsvd;
 };
 
 #undef DECL_REG_HI

es and it's pad overlay FRED's event_data field (CR2, DR6, XFD_ERR).

While I could in principle union es and ds to make this work, there's
also a 64byte alignment requirement for the FRED frame on the stack, so
I do need to make fs/gs disappear some how.

However, these vm86 fields are also the reason why we've had out of
bounds accesses, and I'm looking to make such bugs impossible.

I'm not actually inserting edata quite like that, to avoid swapping one
OoB problem for another.

>
>> +Stack layout
>> +""""""""""""
>> +
>> +Xen's CPU stacks are 8-page (8-page aligned), arranged as::
>> +
>> +  7 - Primary stack (with a struct cpu_info at the top)
>> +  6 - Primary stack
>> +  5 - Primary Shadow Stack (read-only)
>> +  4 - #DF IST stack
>> +  3 - #DB IST stack
>> +  2 - NMI IST stack
>> +  1 - #MC IST stack
>> +  0 - IST Shadow Stacks (4x 1k, read-only)
>> +
>> +which needs mapping into FREDs Stack Levels.
>> +
>> +FRED Stack Levels replace IST.  Most events from Ring3 enter Ring0 at SL0,
>> +including interrupts, and even exceptions with a non-zero Stack Level
>> +configured.  Nested exceptions originate from Ring0 even if they were trying
>> +to push a Ring3 event frame onto the stack, so do follow the Ring0 CSL rules.
>> +
>> +Within Ring0, a stack switch occurs on event delivery if the event has a
>> +higher configured Stack Level (exceptions in ``MSR_FRED_STK_LVLS``, interrupts
>> +in ``MSR_FRED_CONFIG``).  Otherwise, the new event is delivered on the current
>> +stack.
>> +
>> +Under FRED, most sources of ``#DF`` are gone; failure to push a new event
>> +frame onto a stack is the main remaining one, so ``#DF`` needs to be the
>> +highest stack level (SL3) to catch errors at all other stack levels.
>> +
>> +Also, FRED removes the "syscall gap", removing the primary need for ``NMI``,
>> +``#DB`` and ``#MC`` to need separate stacks.
>> +
>> +Therefore, Xen has no need for SL1 or SL2.  Under IDT delivery, we poison the
>> +unused stack pointers with a non-canonical address, but we cannot do that
>> +under FRED; they're held in MSRs and checked at WRMSR time.  Instead, we can
>> +point the SL pairs (RSP + SSP) at each others (regular and shadow stack) guard
>> +pages such that any use of an unused SL will escalate to ``#DF``.
> I may have a language issue here: "each others" reads wrong to me; do you perhaps
> mean "each ones"?

It's poor grammar, but not wrong per say.  I'll try to find a different
way to phrase it.

>
> Further, mainly to double check my own understanding: Almost half of the stack
> area then isn't used anymore when FRED is active: 2 pages for the primary stack,
> 1 page for the primary shadow stack, 1 page for the SL3 stack, and (somewhat
> wastefully) 1 more for the SL3 shadow stack.

This matches my understanding (on the proviso that I've still not wired
up the stack handling yet.  Still cleaning up the initialisation paths.)

>  There'll be 3 unused pages, and
> hence space again to have true guard pages, e.g.
>
>   7 - Primary stack (with a struct cpu_info at the top)
>   6 - Primary stack
>   5 - Guard page
>   4 - Primary Shadow Stack (read-only)
>   3 - Guard page
>   2 - #DF stack
>   1 - #DF Shadow Stack (read-only)
>   0 - Guard page

Shadow stack frames are perfectly good guard pages for regular stacks,
and vice versa.  That's why I set them up as shadow stack pages even
when CET isn't active.

And yes, we could rearrange the stack.  But, there's also a good reason
not to.  Our code has to cope with both IDT and FRED layouts, which is
much easier if they're the same.


> Having reached the bottom of the section, there's one special IST aspect that
> I'm missing, special enough imo to warrant mentioning even if only to state that
> it's (hopefully) going to be irrelevant (i.e. not require replacing by another
> similar hack): {dis,en}able_each_ist() as used by SVM (on the assumption that
> sooner or later AMD is likely to also implement FRED, and that you may already
> know of details of their respective VMCB integration).

AMD haven't said anything about FRED yet, despite a very large number of
software partners asking about it.

However, If AMD were to do FRED, I'd expect it to work just like CET
does today, seeing as there's a proper host/guest split of CR4, and
everything else is in MSRs the guest can't touch.
>> +Still TBD
>> +---------
>> +
>> +Issues/areas I'm aware of, but haven't got a firm plan yet.
>> +
>> +Call Gates
>> +""""""""""
>> +
>> +FRED removes Call Gates, yielding ``#GP[sel]`` instead.  This is how we
>> +emulate call gates for PV32, but emulation is genuinely only wired up for PV32
>> +guests, not for PV64.
>> +
>> +PV64 guests do seem to be able to write Call Gates into their LDT/GDT, but
>> +have the DPL 0'd in common with PV32.  Given the absence of emulation, I think
>> +PV64 can't actually use Call Gates, but given the existing logic this also
>> +seems to be by accident rather than design.
> A partial patch I have to start doing that emulation has a timestamp of 2007.
> Quoting my note there (which I may have posted at some point): "The main issue
> to be resolved is how to distinguish whether a referenced code segment is a
> kernel or user segment, so that the code can know whether to switch the guest
> to kernel mode. Perhaps this can be done by setting _SEGMENT_EC on all user
> segments and clearing it on all kernel ones (in check_descriptor())."
>
> In any event - since no real-world need has surfaced in all this time, I don't
> think the case needs worrying about for FRED.

Ok.  I'll see if I can find a suitable place to state that call gates
don't work for PV64 and that this is unlikely to change.

>
>> +GS handling
>> +"""""""""""
>> +
>> +Xen does not use GS as a per-cpu pointer, but FRED is tied to the common OS
>> +usage.  Therefore, when FRED is active, ``v->arch.pv.gs_base_{user,kernel}``
>> +are logically the opposite way around when running in Xen context.
> But these are our own fields. I think we'd better keep their names in line
> with what they hold. It's the use of the fields which ...
>
>> +Furthermore we cannot use ``SWAPGS`` as part of context switching, and there's
>> +no ``wrgsshadow`` instruction.  All guest GS handling within Xen needs to be
>> +altered.
> ... needs altering then, along with the other adjustments you allude to here.

Yeah, I wasn't very clear.

When in FRED mode, GS_BASE and GS_SHADOW are the opposite way around
(because hardware auto-swapgs's for us), so the way we handle everything
to do with GS needs to change.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Jan 06 16:38:01 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 16:38:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865831.1277094 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUq6p-0007Wd-M2; Mon, 06 Jan 2025 16:37:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865831.1277094; Mon, 06 Jan 2025 16:37:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUq6p-0007WW-JP; Mon, 06 Jan 2025 16:37:43 +0000
Received: by outflank-mailman (input) for mailman id 865831;
 Mon, 06 Jan 2025 16:37: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
 <SRS0=bFJS=T6=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tUq6o-0007WQ-Vl
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 16:37:43 +0000
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com
 [2a00:1450:4864:20::32e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 884be297-cc4c-11ef-99a4-01e77a169b0f;
 Mon, 06 Jan 2025 17:37:35 +0100 (CET)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-435f8f29f8aso105585745e9.2
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 08:37:34 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c832a90sm47699194f8f.28.2025.01.06.08.37.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 06 Jan 2025 08:37:33 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 884be297-cc4c-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736181454; x=1736786254; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=IcvkX/5ZL+kPSoX1BuigmpSqK7fJqYkWuQNOCL2eGKY=;
        b=oJbrHnMVH1Qy+Nkuo9joEJ+n/H6+HMC1yguZinXDbP5Mq/lBoOLSsknOnj4D9duMeo
         w1rCbOQpfeCNL51C9ZDgffFnoBhobqwysMBodkZuJZpDFga03NSBPRDMMIO+Wvc5ZcSj
         G0S4JXOObl76Kbq8En7O73DW3P88UOsV2blsE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736181454; x=1736786254;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=IcvkX/5ZL+kPSoX1BuigmpSqK7fJqYkWuQNOCL2eGKY=;
        b=vwznwxWFJRCCL/7gP2ozf218VF69i1b5wptsZEM5dmX/4mdQtfllcKHiJI9ztSAPvn
         5A1bQIDk9Pxe+YSIPGycLSr5OvN36UBKHk3otYy+MmGkh5KJM6haArMWGdIchiev+fGx
         NwvAbzCuALWpl6Kky3zsaazP5jQ70HBkvdMVHZcL2Fql/cVyWsFqTOEXU8QgvSciJbKf
         cSVB0bXKc1nUTwh5rIDHYod+zpJKpC3FOWyi9P/+QMPjnQTqUwC3gaRsR+gHEn2vUq0I
         Rw8mqcs99dGh2qdcSqYBEmL4F3tcngKFw/n8P9Obiqz/VyI8O2ZkQdd9aHLY/QpHqqaF
         EERg==
X-Forwarded-Encrypted: i=1; AJvYcCWotO9kCxov6MzqQLipGzZD0C+6lKiGrW01kucT4gBihpxW3JTtzqu4XpvcM6//59WvSAA1VbPZosM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YybhSzPPL+35z7l4ltt1YxcergqSNmV+ll9OZeS4LYOmi+CkJmC
	+MGwJxTOcjzSxVEKTwo+TB5LdD9Ry0Y0S/Ib7rax8Mkp3LYqVe8kIMMYw1zh3go=
X-Gm-Gg: ASbGncubXdM5yQIym3iC6Y56iSCVJ/i77wM5DpmV3ywoT2xFL5NohHc54ozvAKM8F/e
	tOGN+0jr3/CdlUT5/OLWNvTBuFcx5RSWMNQJl7C3zZexGjVTZjhcVmbTZQx5lgBFVBB4yb2Aq9Y
	UKurYpRJpMOwAalbW8Qjy2voS96OUi/sdH3DzHzvNFx22UhRDY4tUqabswbAp0PwxXz5KOmMx7f
	7RVDvAjB4lIhDU+5LyROc1Zv7g5LXRdrvE5OqgN2Shn/GxsFMPp4mPkharx+yCDYeDgz1XYKmpZ
	tO+9wAzTu/qlnM44YPps
X-Google-Smtp-Source: AGHT+IGLN4j2L5U5eqiIrAWpJz/FuCb9BJVF7DOB39Nbj0B7waFunuwjUKBeRb7p8k7f/XzIUR7T5g==
X-Received: by 2002:a05:600c:350c:b0:434:a1d3:a30f with SMTP id 5b1f17b1804b1-43668547554mr458996925e9.6.1736181454399;
        Mon, 06 Jan 2025 08:37:34 -0800 (PST)
Message-ID: <03d356de-d3ba-4cb9-acd6-408bde58e77b@citrix.com>
Date: Mon, 6 Jan 2025 16:37:33 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20] x86/amd: Misc setup for Fam1Ah processors
To: Jan Beulich <jbeulich@suse.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20250106141929.615831-1-andrew.cooper3@citrix.com>
 <614a8615-7448-4601-92ff-04217f77a38f@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <614a8615-7448-4601-92ff-04217f77a38f@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 06/01/2025 2:41 pm, Jan Beulich wrote:
> On 06.01.2025 15:19, Andrew Cooper wrote:
>> Fam1Ah is similar to Fam19h in these regards.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> ---
>> CC: Jan Beulich <JBeulich@suse.com>
>> CC: Roger Pau Monné <roger.pau@citrix.com>
>>
>> With this patch, I think we're in an ok position to declare support on Zen5
>> CPUs.
> What about amd_log_freq(), where the 0x19 upper bound may need bumping?

The Pstate MSRs are still there, but their layout is quite different. 
FID is 12 bits, and Vid is 9 bits in two split fields.

As this is only informational for now, I think I'll leave it.  This
needs a bigger rework to make the code tractable.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Jan 06 16:41:31 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 16:41:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865838.1277104 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUqAU-0000gl-4h; Mon, 06 Jan 2025 16:41:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865838.1277104; Mon, 06 Jan 2025 16:41:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUqAU-0000ge-1l; Mon, 06 Jan 2025 16:41:30 +0000
Received: by outflank-mailman (input) for mailman id 865838;
 Mon, 06 Jan 2025 16:41:29 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=bFJS=T6=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tUqAT-0000gY-2S
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 16:41:29 +0000
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
 [2a00:1450:4864:20::52e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 12bf8ffb-cc4d-11ef-99a4-01e77a169b0f;
 Mon, 06 Jan 2025 17:41:27 +0100 (CET)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-5d34030ebb2so9489440a12.1
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 08:41:27 -0800 (PST)
Received: from andrewcoop.eng.citrite.net (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d80676f496sm23267140a12.34.2025.01.06.08.41.25
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 06 Jan 2025 08:41:25 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 12bf8ffb-cc4d-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736181686; x=1736786486; 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=1Bu1qdeQ8htGAhO8BhpqxLGX5bJRujvB81kYlK6uEgI=;
        b=DQbvs5F06Oi8DkZKJi8eC1UonzezZ2GHN0OPJxdQZe6G76yxk1AcEggQdNhc5cGvP/
         dHhXKLbuxPnf+YgjWipbmLP+5zXgzR41zHZLwwMxI4dcvMvWqhXXYh9S6BMYV9U327je
         wP9yjyREW3fRxBaMtb8/jrZgGIlbeKlLtzvbU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736181686; x=1736786486;
        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=1Bu1qdeQ8htGAhO8BhpqxLGX5bJRujvB81kYlK6uEgI=;
        b=H/oA/NhLTFBV3tfuD5fswQSCt9lWD68tNSYMLah2mfkNjshQ4WekobqOQTLM4FVEBZ
         mQ4GfK4wy7eYDluMpxHW8ZbFRWlWXoMQHgkp7ZsoKIIuBtPyxcdpWS0wJgAihM3st0Ef
         UBc4GQbS/hfM9y4kQbugZtdh1zm+HvPtJLh0fg5jX9OzeaU9/pDL3SLNmDiXef1FFA52
         xbmWw5GGk/S1suNh8F34pxIJxT6bZecDJ7Ner+duEA4wkBDz/ZM6pI+EnJM7R5GbI0eK
         DDxyzSSS9y/tGkasAqBDWdJkUZY+6I+QPM9VsflBNhvln5g3ouHCpC6dFl5Zft1cadm1
         HrWQ==
X-Gm-Message-State: AOJu0Yxj+3OlOQEpHfuBLa7Ai7UX9tQgcADyslDBAvjm7QxLafFw+Oqr
	Sc7ZVxMGuJPahVHREtv7YOM2yELfy8So0uzRxdT8s0kxNXY4G6JSWhS/Z83zBdM5Hg/HAAcG0N/
	q5UkgFA==
X-Gm-Gg: ASbGnctPJc6wT9R/CvvBMURIr8svaHuGS/qTd3ZY19Vwt5aJlSo81ggkO6mKC6OsrSi
	avJxGlBnoIe3iuTAFAny34S85rarUB93LC7vh+BHkuxnSKV/XhRjDjb/w6Dgb26wZv1PiBrRgRP
	e/MBlz56/njqa/JJfBjgy8v21oAm/q/QBfGmx4pdp1g381O4TuDOUM79feEQrwtnIhJSurTYGbC
	n6Mo1PPa8vIW98EWSUdpzI3aj9GAKM6/LLaVvPi10bHo48FijoxHFjzYWlcFaDunL+xoaFU7/vt
	qD4k5QLLrf5+O7RhJeMs13x75oXnNzjqpjAh
X-Google-Smtp-Source: AGHT+IG/A14ES5hpSkLUN8HO9fYBY5rlRi/+8BeGrsHVDqB95AMu092Luhvkl704d+CKNOFu3HLSWA==
X-Received: by 2002:a05:6402:270d:b0:5d2:73b0:81e8 with SMTP id 4fb4d7f45d1cf-5d81dd820admr50512155a12.9.1736181686289;
        Mon, 06 Jan 2025 08:41:26 -0800 (PST)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PATCH for-4.20 v2] x86/amd: Misc setup for Fam1Ah processors
Date: Mon,  6 Jan 2025 16:41:24 +0000
Message-Id: <20250106164124.620662-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Fam1Ah is similar to Fam19h in these regards.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Roger Pau Monné <roger.pau@citrix.com>

v2:
 * Update microcode size, based on the largest value I can find in the PPRs.

Defer updating amd_log_freq() for now.  The MSR layout is different and rather
more complicated to parse.

With this patch, I think we're in an ok position to declare support on Zen5
CPUs.  I'm very disappointed that AMD don't have any documetation about ERAPS,
but to the best of my (backchannel) knowledge, Xen should behave safely.
---
 xen/arch/x86/acpi/cpu_idle.c     | 1 +
 xen/arch/x86/cpu/microcode/amd.c | 4 ++++
 xen/arch/x86/cpu/vpmu_amd.c      | 1 +
 3 files changed, 6 insertions(+)

diff --git a/xen/arch/x86/acpi/cpu_idle.c b/xen/arch/x86/acpi/cpu_idle.c
index 876317fad059..420198406def 100644
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -1417,6 +1417,7 @@ static void amd_cpuidle_init(struct acpi_processor_power *power)
 
     switch ( c->x86 )
     {
+    case 0x1a:
     case 0x19:
     case 0x18:
         if ( boot_cpu_data.x86_vendor != X86_VENDOR_HYGON )
diff --git a/xen/arch/x86/cpu/microcode/amd.c b/xen/arch/x86/cpu/microcode/amd.c
index ba7668a94670..210736f5804a 100644
--- a/xen/arch/x86/cpu/microcode/amd.c
+++ b/xen/arch/x86/cpu/microcode/amd.c
@@ -114,6 +114,7 @@ static bool verify_patch_size(uint32_t patch_size)
 #define F16H_MPB_MAX_SIZE 3458
 #define F17H_MPB_MAX_SIZE 3200
 #define F19H_MPB_MAX_SIZE 5568
+#define F1AH_MPB_MAX_SIZE 15296
 
     switch ( boot_cpu_data.x86 )
     {
@@ -132,6 +133,9 @@ static bool verify_patch_size(uint32_t patch_size)
     case 0x19:
         max_size = F19H_MPB_MAX_SIZE;
         break;
+    case 0x1a:
+        max_size = F1AH_MPB_MAX_SIZE;
+        break;
     default:
         max_size = F1XH_MPB_MAX_SIZE;
         break;
diff --git a/xen/arch/x86/cpu/vpmu_amd.c b/xen/arch/x86/cpu/vpmu_amd.c
index a082450e923a..a6117dfebf2a 100644
--- a/xen/arch/x86/cpu/vpmu_amd.c
+++ b/xen/arch/x86/cpu/vpmu_amd.c
@@ -568,6 +568,7 @@ const struct arch_vpmu_ops *__init amd_vpmu_init(void)
     case 0x15:
     case 0x17:
     case 0x19:
+    case 0x1a:
         num_counters = F15H_NUM_COUNTERS;
         counters = AMD_F15H_COUNTERS;
         ctrls = AMD_F15H_CTRLS;
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon Jan 06 16:49:33 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 16:49:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865848.1277115 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUqIC-0001KH-S1; Mon, 06 Jan 2025 16:49:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865848.1277115; Mon, 06 Jan 2025 16:49:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUqIC-0001KA-Oe; Mon, 06 Jan 2025 16:49:28 +0000
Received: by outflank-mailman (input) for mailman id 865848;
 Mon, 06 Jan 2025 16:49:27 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=9khw=T6=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tUqIB-0001K4-AL
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 16:49:27 +0000
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com
 [2a00:1450:4864:20::32a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2f997d3e-cc4e-11ef-99a4-01e77a169b0f;
 Mon, 06 Jan 2025 17:49:25 +0100 (CET)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-4361c705434so105667685e9.3
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 08:49:25 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c828bd3sm47601120f8f.10.2025.01.06.08.49.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 06 Jan 2025 08:49:24 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2f997d3e-cc4e-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736182164; x=1736786964; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=oo3N0ACOin0EaGOAKGJtbFhWYpUk8Cnbo9KMVud7ZtY=;
        b=DPlBS9rrcqgv3xA09TWtabMgXp6QjvWosztXGelQkoBmXJoKrAWDZticx9mzyiUpeU
         VjTX1NF3jbSppHQyGY0T4GS13+HqtV3jw1bkfv5/0oFv0QsoL+0yphOxp5g7HwhFZOWi
         rEsoeYA9vEdZG+l5WiBqlV6TfmnIm4LtrIGA4jnKCbtoTRUXWV7Omi+tZ85DMIhhbrwc
         v1r6Ta4KEO/a7L1fMSQs76JTKl4vQNeCSS9M5XJBYk1aJmE0n3VfTJywVwNHV1Lzresr
         AGsj96VWrb6o/QMysXR/5GVpVaxu4O7oCI8aNaJBtyCBpRGjxOLbmq+8tzxPuU3GJazr
         d9YA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736182164; x=1736786964;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=oo3N0ACOin0EaGOAKGJtbFhWYpUk8Cnbo9KMVud7ZtY=;
        b=Lz2JAuLJe7nqbU6cSeTfAEwyt8LRh7rRRzs9gcAwlVGnNkC3EBqruVvvVwUrjpCnUE
         O/djLMs/qrvWApdJSWj4vthexVh2ynAIQ3U7pV08K++FP7zSNYvNu2fYNUB32Ba/1FHA
         cX47Oln5fEZYFPz99zbcNlaj8LZs6GQ6xcw4i2zCBvo/csinqa3jdJFswZdmxg+Y8hkh
         Em1VG/yNdTvFSbn3EaDy1yTst2JQHWOJYmPvgRTnBynmfp7tOTGV+HsjlWN2VmCVlGri
         Iqb0w/hVfo+uOvlZONtVWs/ZfGsLngW9j1HtmYUymKHFU50O9tQsWh/z0DyYw+Zb2vxn
         rbOw==
X-Forwarded-Encrypted: i=1; AJvYcCXyNcByZpkd761NbDai/wuRallhgvjJXuXB7L1w8GB0g/vAsX6v17p9sV/x/Tm39hvLTZUxUQ2BmBo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwAdcTGzv40DR+Tj65EaePKKhhtr8UikrstR4wGMiFY0eW5Yn7j
	hOXEz2y590V6a9f2r5NheqpcKKJOQUPu7eIwaTvDwl06X6NMS0hgSn499xQm6Q==
X-Gm-Gg: ASbGnctlSAcvsqoESaA5vzKlIFMzhvGLz3hlfmiKPQR6ZHVT5MRzIiGwxU6KkUN5VSt
	U151/yDIeqnwNsUFN43vbHAm1ZFJm0iSsmpdZSMGiLfSnkLmbpHDk8CvrERi13CfuoVQkK62/3i
	zu2nz2d5FwYr/IvhVv+7flWVIXigggx9Op+RsWkyAmyJ9CciEn4FpheuyR/rAJAGFEaUi1Onm7M
	pqXfn5Z3TfejIzlAxkmRHNlhiII0lZSxgkP7BQ3aK+7Nl0rireIm1MGKBRZWj6/YHcb1OjxSR0H
	VM+aIPyQVFbwCyWKaqdVEucdUvgcUP3gOTnhWFDs6w==
X-Google-Smtp-Source: AGHT+IFS8Z6aK1ppVG5fMNbCPIE8ir8rD/4kNJPr4/Mp4eKOHo+b7C6sKLrOQC+ySBjExKn7DoX4VQ==
X-Received: by 2002:a05:600c:35d2:b0:434:a929:42bb with SMTP id 5b1f17b1804b1-436686464cemr537404185e9.18.1736182164582;
        Mon, 06 Jan 2025 08:49:24 -0800 (PST)
Message-ID: <eab6cc64-bbc9-4b7e-8f80-3bba69cfd1fd@suse.com>
Date: Mon, 6 Jan 2025 17:49:23 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20] x86/amd: Misc setup for Fam1Ah processors
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20250106141929.615831-1-andrew.cooper3@citrix.com>
 <614a8615-7448-4601-92ff-04217f77a38f@suse.com>
 <03d356de-d3ba-4cb9-acd6-408bde58e77b@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <03d356de-d3ba-4cb9-acd6-408bde58e77b@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 06.01.2025 17:37, Andrew Cooper wrote:
> On 06/01/2025 2:41 pm, Jan Beulich wrote:
>> On 06.01.2025 15:19, Andrew Cooper wrote:
>>> Fam1Ah is similar to Fam19h in these regards.
>>>
>>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>> ---
>>> CC: Jan Beulich <JBeulich@suse.com>
>>> CC: Roger Pau Monné <roger.pau@citrix.com>
>>>
>>> With this patch, I think we're in an ok position to declare support on Zen5
>>> CPUs.
>> What about amd_log_freq(), where the 0x19 upper bound may need bumping?
> 
> The Pstate MSRs are still there, but their layout is quite different. 
> FID is 12 bits, and Vid is 9 bits in two split fields.

Oh, okay.

> As this is only informational for now, I think I'll leave it.  This
> needs a bigger rework to make the code tractable.

Fair enough then. And with the adjusted ucode size:
Acked-by: Jan Beulich <jbeulich@suse.com>

Jan



From xen-devel-bounces@lists.xenproject.org Mon Jan 06 16:50:42 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 16:50:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865855.1277125 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUqJO-0002ni-4o; Mon, 06 Jan 2025 16:50:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865855.1277125; Mon, 06 Jan 2025 16:50:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUqJO-0002nb-27; Mon, 06 Jan 2025 16:50:42 +0000
Received: by outflank-mailman (input) for mailman id 865855;
 Mon, 06 Jan 2025 16:50:41 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=9khw=T6=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tUqJN-0002mM-4k
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 16:50:41 +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 5c389d48-cc4e-11ef-a0df-8be0dac302b0;
 Mon, 06 Jan 2025 17:50:40 +0100 (CET)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-436a03197b2so52461365e9.2
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 08:50:40 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-43656b42757sm614166555e9.39.2025.01.06.08.50.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 06 Jan 2025 08:50:39 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5c389d48-cc4e-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736182239; x=1736787039; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=P+7X1XXH/xaXHFEjaZPe9altewNzGcSF4ccQVfsvT6Q=;
        b=BzbmhZooqI+s9HxLsSH8Gya2Cc6Q9XN+XudX3uLt4dq7RZbIPVCQXd68AlldS4qWcT
         H9IT4c2CJcZYHNkcN0YTkNYe6iojtP9+7HzPHBtmN18/wKix7GBBNW3rPPVBoCH/X0d0
         itZzFMizi0Snh1vMgQJ/ksBafUU62jPH8zPecX7dOWvYXSFt7CKeBzEBXT65wA++oLrT
         ZnhVd33einUx5SHerpR/TTObYTdIuk3lVnuETAdDFgedP+AF3LMM5WlEOJ5eCrRQILmV
         h6pBrj7FB1Itk2GeI4uCJVhVyC53lNN9eUiou/w09Gduhsf62gFB8VOh5PmmYnd9fZAN
         NwIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736182239; x=1736787039;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=P+7X1XXH/xaXHFEjaZPe9altewNzGcSF4ccQVfsvT6Q=;
        b=a829L3u3ouVujnKEQAQL2FtsqLFNk6VDuldt0V72+BgtLBp4ohg3Ah7qJiw88wLsoK
         bIwNOlsQQRXCeXNuZRoL982EoFy5jDivOYxpRQdjRm3qr6H2C0b87R623k0Pp3Le2ytg
         d/6xZV185BGOSVX9yJimit5jgJA4YVKp/ZrMjLDILcxPvfU8Um528PakT3dq9uusI2oH
         Sk5QGhIObzkdC8Co2NLNPjyApUZAyKVgSbWH+eBmSEfiemC4hbMZN6lttmaSVXFvNg21
         iu25lwzfCWsa/Ilh0Xw+w6WCE1UyKRzx+3Q47BwPUT5/bj7hUprC7C0h09azAGHgog7e
         pwYw==
X-Forwarded-Encrypted: i=1; AJvYcCVc0XIr0f+43vSHyugqG17x1H4MoVxkttfdcSZ02LNc2frMGSU9i7pwlFric5CFaWbDiKTx0pQBnIg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzQRz5SCR5/9f0kX4u022fV00B7u7O4EXzZ02FXk1UFIEj/y+zG
	4bX3NN3JT3jc4nL/LUDVunXAXxGVAgjgpmlZGD7i9tZ9g+WVLLrCcMAHDrbiaE7NB9HQzuM8mCc
	=
X-Gm-Gg: ASbGncvEw8NijH5QWNvybmWkRF6IntfqwRPWXWEjhV8rUHQ90BBjoFhuuac2nhkazh6
	mPfFXRTavWqJzdgaL/P2ZnCNebqZgVKbou+0u3eKpfjNzo5On6VyAvS6PxY525OgJblbJdJilT8
	Adi0pC9FAwr8p+SHy1r/FpSwDyRB56mV8+rit/4XMFxvIBxQGTiG3RmkNL0mofUQwvQQifQezPK
	e28c1eyB7o/WyfJdXusawBZ2P8JCcVAzQUbWtDNAvcWHGVrvUGKlEd/yurXSKRQD43lB487jxer
	csF7c9MUowEkhaTlwObJZe23k7cmaHUCN+gnset2Bg==
X-Google-Smtp-Source: AGHT+IHh99JI5qGA8vI7lsPXvquv6H1lSmJ+tHE/WjaLbBtC5NxjfwH15Gl5+JrGdcvLjGoMtDtMSA==
X-Received: by 2002:a05:600c:350b:b0:434:ffd7:6fca with SMTP id 5b1f17b1804b1-436685488b2mr457006855e9.2.1736182239425;
        Mon, 06 Jan 2025 08:50:39 -0800 (PST)
Message-ID: <0968cf4a-b641-471e-ae28-dc2da4752110@suse.com>
Date: Mon, 6 Jan 2025 17:50:38 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20 v2] x86/amd: Misc setup for Fam1Ah processors
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20250106164124.620662-1-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250106164124.620662-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.01.2025 17:41, Andrew Cooper wrote:
> Fam1Ah is similar to Fam19h in these regards.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Oh, noticed too late that you sent a v2. So here as well:
Acked-by: Jan Beulich <jbeulich@suse.com>

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 06 17:19:57 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 17:19:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865862.1277134 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUqlX-00068w-49; Mon, 06 Jan 2025 17:19:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865862.1277134; Mon, 06 Jan 2025 17:19:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUqlX-00068p-1a; Mon, 06 Jan 2025 17:19:47 +0000
Received: by outflank-mailman (input) for mailman id 865862;
 Mon, 06 Jan 2025 17:19:45 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=3utI=T6=casper.srs.infradead.org=BATV+fbe2d98d58a1bf71468b+7806+infradead.org+dwmw2@srs-se1.protection.inumbo.net>)
 id 1tUqlU-00068j-OT
 for xen-devel@lists.xen.org; Mon, 06 Jan 2025 17:19:45 +0000
Received: from casper.infradead.org (casper.infradead.org
 [2001:8b0:10b:1236::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 69f65af5-cc52-11ef-a0df-8be0dac302b0;
 Mon, 06 Jan 2025 18:19:42 +0100 (CET)
Received: from 54-240-197-239.amazon.com ([54.240.197.239]
 helo=u09cd745991455d.ant.amazon.com)
 by casper.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux))
 id 1tUqlP-0000000Gn1A-3r11; Mon, 06 Jan 2025 17:19:40 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 69f65af5-cc52-11ef-a0df-8be0dac302b0
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=FjviZlZXKT8dfKbK95GfyNs+ay4VMJjTPeM7gJNLVac=; b=U8MVOdoA+1dNeHMqrFYwjptwkw
	7SsSyWMC6TWQ/Ca6hOAnkj6sYGudtykzzSF9DS83q7u/zNDRdDj6QHBUWU5WpxOYcZViOEcdZAm14
	1fnEjVv6fhVzVjulYVZWMR3OomrYYhI+RDLM1KErKg6rgUE6m3wAnwv5P+QTdTZNim7j016pCBD4g
	z6gADLSzP8gedJslLBJefTsnfi3bfrD916dnMMjGqer+F9gdzM6LIfPMHo1UdUXIvYk4xQWxP3i8J
	ft5332iJqGhUBTjd3lOw3717hGibmQXLmc0dExjhTWeFzYj6qQypVKaihWBAQQTYBy1P7qJdJWx5g
	FzdSXylw==;
Message-ID: <ffea2b8edd4455b8d04a3c25afaaffc98ed40540.camel@infradead.org>
Subject: Re: Xen Security Advisory 466 v3 (CVE-2024-53241) - Xen hypercall
 page unsafe against speculative attacks
From: David Woodhouse <dwmw2@infradead.org>
To: =?ISO-8859-1?Q?J=FCrgen_Gro=DF?= <jgross@suse.com>, "Xen.org security
 team" <security@xen.org>, xen-devel@lists.xen.org
Date: Mon, 06 Jan 2025 17:19:39 +0000
In-Reply-To: <fc4170ed-d238-4e1c-817e-3695a7112d9d@suse.com>
References: <E1tNWXG-00E268-2p@xenbits.xenproject.org>
	 <54c892eded2b4ebdda8ee1085c383178f44414ad.camel@infradead.org>
	 <a3031e7d-fe9d-4db8-8ccd-923165c9af72@suse.com>
	 <fc4c45ea86567ef0c46d7e5a20e8abffa75cc4ec.camel@infradead.org>
	 <fd993f8d-280f-439a-a6a0-506e2815f281@suse.com>
	 <b7323a9fa5239443b9b6f3daa423196de1051748.camel@infradead.org>
	 <40734e79-fb55-4712-aae1-3ef350af4f3c@suse.com>
	 <f9b4ae8af70b8b5136b59237c7925f57220b3d5b.camel@infradead.org>
	 <fc4170ed-d238-4e1c-817e-3695a7112d9d@suse.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-/WS719eLD5TDhjNdeM/Z"
User-Agent: Evolution 3.52.3-0ubuntu1 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html


--=-/WS719eLD5TDhjNdeM/Z
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2025-01-02 at 15:16 +0100, J=C3=BCrgen Gro=C3=9F wrote:
> On 02.01.25 15:06, David Woodhouse wrote:
> > On Thu, 2025-01-02 at 15:02 +0100, J=C3=BCrgen Gro=C3=9F wrote:
> > > > Are you suggesting that you're able to enable the CPU-specific CFI
> > > > protections before you even know whether it's an Intel or AMD CPU?
> > >=20
> > > Not before that, but maybe rather soon afterwards. And the hypercall =
page
> > > needs to be decommissioned before the next hypercall is happening. Th=
e question
> > > is whether we have a hook in place to do that switch between cpu iden=
tification
> > > and CFI enabling.
> >=20
> > Not sure that's how I'd phrase it. Even if we have to add a hook at the
> > right time to switch from the Xen-populated hypercall page to the one
> > filled in by Linux, the question is whether adding that hook is simpler
> > than all this early static_call stuff that's been thrown together, and
> > the open questions about the 64-bit latching.
>=20
> This is a valid question, yes. My first version of these patches didn't
> work with static_call, but used the paravirt call patching mechanism
> replacing an indirect call with a direct one via ALTERNATIVEs. That
> version was disliked by some involved x86 maintainers, resulting in the
> addition of the early static_call update mechanism.
>=20
> One thing to mention regarding the 64-bit latching: what would you do
> with HVM domains? Those are setting up the hypercall page rather late.
> In case the kernel would use CFI, enabling would happen way before the
> guest would issue any hypercall, so I guess the latching needs to happen
> by other means anyway. Or would you want to register the hypercall page
> without ever intending to use it?

With xen_no_vector_callback on the command line, the hypervisor doesn't
realise that the guest is 64-bit until long after all the CPUs are
brought up.

It does boot (and hey, QEMU does get this right!) but I'm still
concerned that all those shared structures are 32-bit for that long. I
do think the guest kernel should either set the hypercall page, or
HVM_PARAM_CALLBACK_IRQ, as early as possible.

 $ ./qemu-system-x86_64 -display none -vga none  -serial mon:stdio   -accel=
 kvm,xen-version=3D0x4000a,kernel-irqchip=3Dsplit -smp 2 -kernel ~/git/linu=
x-2.6/arch/x86/boot/bzImage  -append 'root=3D/dev/xvda1 console=3DttyS0 xen=
_no_vector_callback earlyprintk=3Dserial' -drive file=3D/var/lib/libvirt/im=
ages/fedora28.qcow2,if=3Dxen  -trace kvm_xen\* -m 2g
kvm_xen_soft_reset=20
kvm_xen_set_vcpu_attr vcpu attr cpu 0 type 0 gpa 0xffffffffffffffff
kvm_xen_set_vcpu_attr vcpu attr cpu 0 type 1 gpa 0xffffffffffffffff
kvm_xen_set_vcpu_attr vcpu attr cpu 0 type 2 gpa 0xffffffffffffffff
kvm_xen_set_vcpu_callback callback vcpu 0 vector 0
kvm_xen_set_vcpu_attr vcpu attr cpu 1 type 0 gpa 0xffffffffffffffff
kvm_xen_set_vcpu_attr vcpu attr cpu 1 type 1 gpa 0xffffffffffffffff
kvm_xen_set_vcpu_attr vcpu attr cpu 1 type 2 gpa 0xffffffffffffffff
kvm_xen_set_vcpu_callback callback vcpu 1 vector 0
Probing EDD (edd=3Doff to disable)... ok
[    0.000000] Linux version 6.13.0-rc2+ (dwoodhou@i7.infradead.org) (gcc (=
GCC) 14.2.1 20240912 (Red Hat 14.2.1-3), GNU ld version 2.43.1-2.fc41) #221=
0 SMP PREEMPT_DYNAMIC Mon Jan  6 17:10:02 GMT 2025
[    0.000000] Command line: root=3D/dev/xvda1 console=3DttyS0 xen_no_vecto=
r_callback earlyprintk=3Dserial
[    0.000000] BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usabl=
e
[    0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reser=
ved
[    0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reser=
ved
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000007ffdffff] usabl=
e
[    0.000000] BIOS-e820: [mem 0x000000007ffe0000-0x000000007fffffff] reser=
ved
[    0.000000] BIOS-e820: [mem 0x00000000feff8000-0x00000000feffffff] reser=
ved
[    0.000000] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reser=
ved
[    0.000000] printk: legacy bootconsole [earlyser0] enabled
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] APIC: Static calls initialized
[    0.000000] SMBIOS 2.8 present.
[    0.000000] DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3=
-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
[    0.000000] DMI: Memory slots populated: 1/1
[    0.000000] Hypervisor detected: Xen HVM
[    0.000000] Xen version 4.10.
kvm_xen_hypercall xen_hypercall: cpu 0 cpl 0 input 17 a0 0x6 a1 0xffffffff8=
a003e30 a2 0x0 ret 0x0
kvm_xen_set_shared_info shared info at gfn 0x10
kvm_xen_hypercall xen_hypercall: cpu 0 cpl 0 input 12 a0 0x7 a1 0xffffffff8=
a003e30 a2 0x8000000000000163 ret 0x0
kvm_xen_set_vcpu_attr vcpu attr cpu 0 type 0 gpa 0x10000
kvm_xen_set_vcpu_attr vcpu attr cpu 1 type 0 gpa 0x10040
[    0.000000] platform_pci_unplug: Netfront and the Xen platform PCI drive=
r have been compiled for this kernel: unplug emulated NICs.
[    0.000000] platform_pci_unplug: Blkfront and the Xen platform PCI drive=
r have been compiled for this kernel: unplug emulated disks.
[    0.000000] You might have to change the root device
[    0.000000] from /dev/hd[a-d] to /dev/xvd[a-d]
[    0.000000] in your root=3D kernel command line option
kvm_xen_hypercall xen_hypercall: cpu 0 cpl 0 input 34 a0 0x9 a1 0xffffffff8=
a003e38 a2 0x0 ret 0xffffffffffffffda
[    0.000000] last_pfn =3D 0x7ffe0 max_arch_pfn =3D 0x400000000
[    0.000000] MTRR map: 4 entries (3 fixed + 1 variable; max 19), built fr=
om 8 variable MTRRs
[    0.000000] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT=
 =20
Memory KASLR using RDTSC...
[    0.000000] found SMP MP-table at [mem 0x000f5480-0x000f548f]
[    0.000000] ACPI: Early table checksum verification disabled
[    0.000000] ACPI: RSDP 0x00000000000F52A0 000014 (v00 BOCHS )
[    0.000000] ACPI: RSDT 0x000000007FFE2379 000034 (v01 BOCHS  BXPC     00=
000001 BXPC 00000001)
[    0.000000] ACPI: FACP 0x000000007FFE2225 000074 (v01 BOCHS  BXPC     00=
000001 BXPC 00000001)
[    0.000000] ACPI: DSDT 0x000000007FFE0040 0021E5 (v01 BOCHS  BXPC     00=
000001 BXPC 00000001)
[    0.000000] ACPI: FACS 0x000000007FFE0000 000040
[    0.000000] ACPI: APIC 0x000000007FFE2299 000080 (v03 BOCHS  BXPC     00=
000001 BXPC 00000001)
[    0.000000] ACPI: HPET 0x000000007FFE2319 000038 (v01 BOCHS  BXPC     00=
000001 BXPC 00000001)
[    0.000000] ACPI: WAET 0x000000007FFE2351 000028 (v01 BOCHS  BXPC     00=
000001 BXPC 00000001)
[    0.000000] ACPI: Reserving FACP table memory at [mem 0x7ffe2225-0x7ffe2=
298]
[    0.000000] ACPI: Reserving DSDT table memory at [mem 0x7ffe0040-0x7ffe2=
224]
[    0.000000] ACPI: Reserving FACS table memory at [mem 0x7ffe0000-0x7ffe0=
03f]
[    0.000000] ACPI: Reserving APIC table memory at [mem 0x7ffe2299-0x7ffe2=
318]
[    0.000000] ACPI: Reserving HPET table memory at [mem 0x7ffe2319-0x7ffe2=
350]
[    0.000000] ACPI: Reserving WAET table memory at [mem 0x7ffe2351-0x7ffe2=
378]
[    0.000000] No NUMA configuration found
[    0.000000] Faking a node at [mem 0x0000000000000000-0x000000007ffdffff]
[    0.000000] NODE_DATA(0) allocated [mem 0x7ffb4c00-0x7ffdffff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000000001000-0x0000000000ffffff]
[    0.000000]   DMA32    [mem 0x0000000001000000-0x000000007ffdffff]
[    0.000000]   Normal   empty
[    0.000000]   Device   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000001000-0x000000000009efff]
[    0.000000]   node   0: [mem 0x0000000000100000-0x000000007ffdffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000000001000-0x000000007ffdf=
fff]
[    0.000000] On node 0, zone DMA: 1 pages in unavailable ranges
[    0.000000] On node 0, zone DMA: 97 pages in unavailable ranges
[    0.000000] On node 0, zone DMA32: 32 pages in unavailable ranges
[    0.000000] ACPI: PM-Timer IO Port: 0x608
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])
[    0.000000] IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-=
23
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 high level)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 high level=
)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level=
)
[    0.000000] ACPI: Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000
[    0.000000] CPU topo: Max. logical packages:   1
[    0.000000] CPU topo: Max. logical dies:       1
[    0.000000] CPU topo: Max. dies per package:   1
[    0.000000] CPU topo: Max. threads per core:   1
[    0.000000] CPU topo: Num. cores per package:     2
[    0.000000] CPU topo: Num. threads per package:   2
[    0.000000] CPU topo: Allowing 2 present CPUs plus 0 hotplug CPUs
[    0.000000] PM: hibernation: Registered nosave memory: [mem 0x00000000-0=
x00000fff]
[    0.000000] PM: hibernation: Registered nosave memory: [mem 0x0009f000-0=
x0009ffff]
[    0.000000] PM: hibernation: Registered nosave memory: [mem 0x000a0000-0=
x000effff]
[    0.000000] PM: hibernation: Registered nosave memory: [mem 0x000f0000-0=
x000fffff]
[    0.000000] [mem 0x80000000-0xfeff7fff] available for PCI devices
[    0.000000] Booting paravirtualized kernel on Xen HVM
[    0.000000] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0=
xffffffff, max_idle_ns: 1910969940391419 ns
[    0.000000] setup_percpu: NR_CPUS:8192 nr_cpumask_bits:2 nr_cpu_ids:2 nr=
_node_ids:1
[    0.000000] percpu: Embedded 69 pages/cpu s245760 r8192 d28672 u1048576
kvm_xen_hypercall xen_hypercall: cpu 0 cpl 0 input 24 a0 0xa a1 0x0 a2 0xff=
ffffff8a003e90 ret 0x0
kvm_xen_set_vcpu_attr vcpu attr cpu 0 type 0 gpa 0x7dc37c40
[    0.000000] Kernel command line: root=3D/dev/xvda1 console=3DttyS0 xen_n=
o_vector_callback earlyprintk=3Dserial
[    0.000000] printk: log buffer data + meta data: 262144 + 917504 =3D 117=
9648 bytes
[    0.000000] Dentry cache hash table entries: 262144 (order: 9, 2097152 b=
ytes, linear)
[    0.000000] Inode-cache hash table entries: 131072 (order: 8, 1048576 by=
tes, linear)
[    0.000000] Fallback order for Node 0: 0=20
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 52415=
8
[    0.000000] Policy zone: DMA32
[    0.000000] mem auto-init: stack:all(zero), heap alloc:on, heap free:off
[    0.000000] SLUB: HWalign=3D64, Order=3D0-3, MinObjects=3D0, CPUs=3D2, N=
odes=3D1
[    0.000000] Kernel/User page tables isolation: enabled
Poking KASLR using RDTSC...
[    0.000000] ftrace: allocating 57063 entries in 223 pages
[    0.000000] ftrace: allocated 223 pages with 7 groups
[    0.000000] Dynamic Preempt: voluntary
[    0.000000] Running RCU self tests
[    0.000000] Running RCU synchronous self tests
[    0.000000] rcu: Preemptible hierarchical RCU implementation.
[    0.000000] rcu: 	RCU lockdep checking is enabled.
[    0.000000] rcu: 	RCU restricting CPUs from NR_CPUS=3D8192 to nr_cpu_ids=
=3D2.
[    0.000000] 	Trampoline variant of Tasks RCU enabled.
[    0.000000] 	Rude variant of Tasks RCU enabled.
[    0.000000] 	Tracing variant of Tasks RCU enabled.
[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 1=
00 jiffies.
[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=3D16, nr_cpu_ids=
=3D2
[    0.000000] Running RCU synchronous self tests
[    0.000000] RCU Tasks: Setting shift to 1 and lim to 1 rcu_task_cb_adjus=
t=3D1 rcu_task_cpu_ids=3D2.
[    0.000000] RCU Tasks Rude: Setting shift to 1 and lim to 1 rcu_task_cb_=
adjust=3D1 rcu_task_cpu_ids=3D2.
[    0.000000] RCU Tasks Trace: Setting shift to 1 and lim to 1 rcu_task_cb=
_adjust=3D1 rcu_task_cpu_ids=3D2.
[    0.000000] NR_IRQS: 524544, nr_irqs: 440, preallocated irqs: 16
kvm_xen_hypercall xen_hypercall: cpu 0 cpl 0 input 32 a0 0xb a1 0xffffffff8=
a003e10 a2 0x0 ret 0xffffffffffffffda
[    0.000000] xen:events: Using 2-level ABI
[    0.000000] rcu: srcu_init: Setting srcu_struct sizes based on contentio=
n.
[    0.000000] kfence: initialized - using 2097152 bytes for 255 objects at=
 0x(____ptrval____)-0x(____ptrval____)
[    0.000000] Console: colour *CGA 80x25
kvm_xen_hypercall xen_hypercall: cpu 0 cpl 0 input 34 a0 0x1 a1 0xffffffff8=
a003e90 a2 0x7ff0 ret 0xffffffffffffffea
[    0.000000] Cannot get hvm parameter CONSOLE_EVTCHN (18): -22!
[    0.000000] printk: legacy console [ttyS0] enabled
[    0.000000] printk: legacy console [ttyS0] enabled
[    0.000000] printk: legacy bootconsole [earlyser0] disabled
[    0.000000] printk: legacy bootconsole [earlyser0] disabled
[    0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc.,=
 Ingo Molnar
[    0.000000] ... MAX_LOCKDEP_SUBCLASSES:  8
[    0.000000] ... MAX_LOCK_DEPTH:          48
[    0.000000] ... MAX_LOCKDEP_KEYS:        8192
[    0.000000] ... CLASSHASH_SIZE:          4096
[    0.000000] ... MAX_LOCKDEP_ENTRIES:     32768
[    0.000000] ... MAX_LOCKDEP_CHAINS:      65536
[    0.000000] ... CHAINHASH_SIZE:          32768
[    0.000000]  memory used by lock dependency info: 6429 kB
[    0.000000]  memory used for stack traces: 4224 kB
[    0.000000]  per task-struct memory footprint: 1920 bytes
[    0.000000] ACPI: Core revision 20240827
[    0.000000] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, =
max_idle_ns: 19112604467 ns
[    0.001000] APIC: Switch to symmetric I/O mode setup
[    0.002000] x2apic enabled
[    0.004000] APIC: Switched APIC routing to: physical x2apic
[    0.004000] ..TIMER: vector=3D0x30 apic1=3D0 pin1=3D2 apic2=3D-1 pin2=3D=
-1
[    0.012000] tsc: Unable to calibrate against PIT
[    0.013000] tsc: using HPET reference calibration
[    0.013000] tsc: Detected 2592.897 MHz processor
[    0.000012] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles:=
 0x2560065444d, max_idle_ns: 440795301426 ns
[    0.001491] Calibrating delay loop (skipped), value calculated using tim=
er frequency.. 5185.79 BogoMIPS (lpj=3D2592897)
[    0.002655] Last level iTLB entries: 4KB 0, 2MB 0, 4MB 0
[    0.003489] Last level dTLB entries: 4KB 0, 2MB 0, 4MB 0, 1GB 0
[    0.004222] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user=
 pointer sanitization
[    0.004490] Spectre V2 : Mitigation: Retpolines
[    0.005070] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB=
 on context switch
[    0.005489] Spectre V2 : Spectre v2 / SpectreRSB : Filling RSB on VMEXIT
[    0.006489] Speculative Store Bypass: Vulnerable
[    0.007489] MDS: Vulnerable: Clear CPU buffers attempted, no microcode
[    0.008489] MMIO Stale Data: Unknown: No mitigations
[    0.009133] x86/fpu: x87 FPU will use FXSAVE
[    0.038149] Freeing SMP alternatives memory: 48K
[    0.038496] pid_max: default: 32768 minimum: 301
[    0.039991] LSM: initializing lsm=3Dlockdown,capability,yama,selinux,bpf=
,landlock,ima,evm
[    0.040774] Yama: becoming mindful.
[    0.041533] SELinux:  Initializing.
[    0.044715] LSM support for eBPF active
[    0.045317] landlock: Up and running.
[    0.045832] Mount-cache hash table entries: 4096 (order: 3, 32768 bytes,=
 linear)
[    0.046494] Mountpoint-cache hash table entries: 4096 (order: 3, 32768 b=
ytes, linear)
[    0.049687] Running RCU synchronous self tests
[    0.050288] Running RCU synchronous self tests
[    0.153191] smpboot: CPU0: Intel QEMU Virtual CPU version 2.5+ (family: =
0xf, model: 0x6b, stepping: 0x1)
[    0.154918] Running RCU Tasks wait API self tests
[    0.258712] Running RCU Tasks Rude wait API self tests
[    0.259499] Running RCU Tasks Trace wait API self tests
[    0.260607] Performance Events: unsupported Netburst CPU model 107 no PM=
U driver, software events only.
[    0.261553] signal: max sigframe size: 1440
[    0.262654] rcu: Hierarchical SRCU implementation.
[    0.263493] rcu: 	Max phase no-delay instances is 400.
[    0.264678] Timer migration: 1 hierarchy levels; 8 children per group; 1=
 crossnode level
[    0.266509] Callback from call_rcu_tasks_trace() invoked.
[    0.267676] NMI watchdog: Perf NMI watchdog permanently disabled
[    0.268688] smp: Bringing up secondary CPUs ...
kvm_xen_hypercall xen_hypercall: cpu 0 cpl 0 input 24 a0 0xa a1 0x1 a2 0xff=
ffa662c0013c90 ret 0x0
kvm_xen_set_vcpu_attr vcpu attr cpu 1 type 0 gpa 0x7dd37c40
[    0.270151] smpboot: x86: Booting SMP configuration:
[    0.270501] .... node  #0, CPUs:      #1
[    0.283862] smp: Brought up 1 node, 2 CPUs
[    0.285133] smpboot: Total of 2 processors activated (10371.58 BogoMIPS)
[    0.286883] Memory: 1985476K/2096632K available (22528K kernel code, 496=
7K rwdata, 10120K rodata, 5116K init, 16104K bss, 105184K reserved, 0K cma-=
reserved)
[    0.289089] devtmpfs: initialized
[    0.290565] x86/mm: Memory block size: 128MB
[    0.295795] Running RCU synchronous self tests
[    0.296526] Running RCU synchronous self tests
[    0.298579] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xfffffff=
f, max_idle_ns: 1911260446275000 ns
[    0.300510] futex hash table entries: 512 (order: 4, 65536 bytes, linear=
)
[    0.303381] pinctrl core: initialized pinctrl subsystem
[    0.304923] PM: RTC time: 17:13:37, date: 2025-01-06
[    0.307951] NET: Registered PF_NETLINK/PF_ROUTE protocol family
[    0.310030] DMA: preallocated 256 KiB GFP_KERNEL pool for atomic allocat=
ions
[    0.310667] DMA: preallocated 256 KiB GFP_KERNEL|GFP_DMA pool for atomic=
 allocations
[    0.312515] DMA: preallocated 256 KiB GFP_KERNEL|GFP_DMA32 pool for atom=
ic allocations
[    0.313836] audit: initializing netlink subsys (disabled)
kvm_xen_hypercall xen_hypercall: cpu 0 cpl 0 input 34 a0 0x1 a1 0xffffa662c=
0013d90 a2 0x0 ret 0x0
kvm_xen_hypercall xen_hypercall: cpu 0 cpl 0 input 34 a0 0x1 a1 0xffffa662c=
0013d90 a2 0x0 ret 0x0
[    0.314652] audit: type=3D2000 audit(1736183617.328:1): state=3Dinitiali=
zed audit_enabled=3D0 res=3D1
[    0.315932] thermal_sys: Registered thermal governor 'fair_share'
[    0.316492] thermal_sys: Registered thermal governor 'bang_bang'
[    0.317508] thermal_sys: Registered thermal governor 'step_wise'
[    0.319506] thermal_sys: Registered thermal governor 'user_space'
[    0.321642] cpuidle: using governor menu
[    0.325622] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[    0.329027] PCI: Using configuration type 1 for base access
[    0.330824] kprobes: kprobe jump-optimization is enabled. All kprobes ar=
e optimized if possible.
[    0.339561] HugeTLB: registered 2.00 MiB page size, pre-allocated 0 page=
s
[    0.340495] HugeTLB: 28 KiB vmemmap can be freed for a 2.00 MiB page
[    0.363514] cryptd: max_cpu_qlen set to 1000
[    0.365598] raid6: skipped pq benchmark and selected sse2x4
[    0.366469] raid6: using intx1 recovery algorithm
[    0.368039] ACPI: Added _OSI(Module Device)
[    0.368493] ACPI: Added _OSI(Processor Device)
[    0.369190] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.369492] ACPI: Added _OSI(Processor Aggregator Device)
[    0.373105] ACPI: 1 ACPI AML tables successfully acquired and loaded
[    0.376550] ACPI: Interpreter enabled
[    0.377182] ACPI: PM: (supports S0 S3 S4 S5)
[    0.377507] ACPI: Using IOAPIC for interrupt routing
[    0.378972] PCI: Using host bridge windows from ACPI; if necessary, use =
"pci=3Dnocrs" and report a bug
[    0.379491] PCI: Using E820 reservations for host bridge windows
[    0.381586] ACPI: Enabled 2 GPEs in block 00 to 0F
[    0.390118] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[    0.390499] acpi PNP0A03:00: _OSC: OS supports [ASPM ClockPM Segments MS=
I EDR HPX-Type3]
[    0.391493] acpi PNP0A03:00: _OSC: not requesting OS control; OS require=
s [ExtendedConfig ASPM ClockPM MSI]
[    0.393553] acpi PNP0A03:00: fail to add MMCONFIG information, can't acc=
ess extended configuration space under this bridge
[    0.397001] acpiphp: Slot [2] registered
[    0.397539] acpiphp: Slot [3] registered
[    0.398194] acpiphp: Slot [4] registered
[    0.398530] acpiphp: Slot [5] registered
[    0.399528] acpiphp: Slot [6] registered
[    0.400150] acpiphp: Slot [7] registered
[    0.400534] acpiphp: Slot [8] registered
[    0.401144] acpiphp: Slot [9] registered
[    0.401530] acpiphp: Slot [10] registered
[    0.402528] acpiphp: Slot [11] registered
[    0.403185] acpiphp: Slot [12] registered
[    0.403530] acpiphp: Slot [13] registered
[    0.404534] acpiphp: Slot [14] registered
[    0.405193] acpiphp: Slot [15] registered
[    0.405528] acpiphp: Slot [16] registered
[    0.406534] acpiphp: Slot [17] registered
[    0.407208] acpiphp: Slot [18] registered
[    0.407535] acpiphp: Slot [19] registered
[    0.408533] acpiphp: Slot [20] registered
[    0.409175] acpiphp: Slot [21] registered
[    0.409528] acpiphp: Slot [22] registered
[    0.410531] acpiphp: Slot [23] registered
[    0.411183] acpiphp: Slot [24] registered
[    0.411528] acpiphp: Slot [25] registered
[    0.412494] acpiphp: Slot [26] registered
[    0.413150] acpiphp: Slot [27] registered
[    0.413528] acpiphp: Slot [28] registered
[    0.414197] acpiphp: Slot [29] registered
[    0.414529] acpiphp: Slot [30] registered
[    0.415536] acpiphp: Slot [31] registered
[    0.416192] PCI host bridge to bus 0000:00
[    0.416499] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7 window=
]
[    0.417492] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff window=
]
[    0.418491] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bfff=
f window]
[    0.419492] pci_bus 0000:00: root bus resource [mem 0x80000000-0xfebffff=
f window]
[    0.420491] pci_bus 0000:00: root bus resource [mem 0x100000000-0x17ffff=
fff window]
[    0.422492] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.423427] pci 0000:00:00.0: [8086:1237] type 00 class 0x060000 convent=
ional PCI endpoint
[    0.425569] pci 0000:00:01.0: [8086:7000] type 00 class 0x060100 convent=
ional PCI endpoint
[    0.428423] pci 0000:00:01.1: [8086:7010] type 00 class 0x010180 convent=
ional PCI endpoint
[    0.433418] pci 0000:00:01.1: BAR 4 [io  0xc100-0xc10f]
[    0.436000] pci 0000:00:01.1: BAR 0 [io  0x01f0-0x01f7]: legacy IDE quir=
k
[    0.436493] pci 0000:00:01.1: BAR 1 [io  0x03f6]: legacy IDE quirk
[    0.437492] pci 0000:00:01.1: BAR 2 [io  0x0170-0x0177]: legacy IDE quir=
k
[    0.438491] pci 0000:00:01.1: BAR 3 [io  0x0376]: legacy IDE quirk
[    0.440728] pci 0000:00:01.3: [8086:7113] type 00 class 0x068000 convent=
ional PCI endpoint
[    0.442546] pci 0000:00:01.3: quirk: [io  0x0600-0x063f] claimed by PIIX=
4 ACPI
[    0.443503] pci 0000:00:01.3: quirk: [io  0x0700-0x070f] claimed by PIIX=
4 SMB
[    0.444900] pci 0000:00:02.0: [5853:0001] type 00 class 0xff8000 convent=
ional PCI endpoint
[    0.446744] pci 0000:00:02.0: BAR 0 [io  0xc000-0xc0ff]
[    0.447993] pci 0000:00:02.0: BAR 1 [mem 0xfd000000-0xfdffffff pref]
[    0.455675] ACPI: PCI: Interrupt link LNKA configured for IRQ 10
[    0.456685] ACPI: PCI: Interrupt link LNKB configured for IRQ 10
[    0.459712] ACPI: PCI: Interrupt link LNKC configured for IRQ 11
[    0.460680] ACPI: PCI: Interrupt link LNKD configured for IRQ 11
[    0.461576] ACPI: PCI: Interrupt link LNKS configured for IRQ 9
[    0.463986] xen:balloon: Initialising balloon driver
[    0.465678] iommu: Default domain type: Translated
[    0.466501] iommu: DMA domain TLB invalidation policy: lazy mode
[    0.468566] Callback from call_rcu_tasks() invoked.
[    0.469004] SCSI subsystem initialized
[    0.470795] ACPI: bus type USB registered
[    0.472546] usbcore: registered new interface driver usbfs
[    0.473436] usbcore: registered new interface driver hub
[    0.473525] usbcore: registered new device driver usb
[    0.474597] pps_core: LinuxPPS API ver. 1 registered
[    0.475493] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo =
Giometti <giometti@linux.it>
[    0.476501] PTP clock support registered
[    0.477636] EDAC MC: Ver: 3.0.0
[    0.481290] NetLabel: Initializing
[    0.481501] NetLabel:  domain hash size =3D 128
[    0.482500] NetLabel:  protocols =3D UNLABELED CIPSOv4 CALIPSO
[    0.483585] NetLabel:  unlabeled traffic allowed by default
[    0.484524] mctp: management component transport protocol core
[    0.485492] NET: Registered PF_MCTP protocol family
[    0.486540] PCI: Using ACPI for IRQ routing
[    0.487795] vgaarb: loaded
[    0.488698] hpet: 3 channels of 0 reserved for per-cpu timers
[    0.489549] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
[    0.490496] hpet0: 3 comparators, 64-bit 100.000000 MHz counter
[    0.494755] clocksource: Switched to clocksource tsc-early
[    0.501201] VFS: Disk quotas dquot_6.6.0
[    0.501853] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 byte=
s)
[    0.503199] pnp: PnP ACPI init
[    0.504524] pnp: PnP ACPI: found 6 devices
[    0.519976] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, m=
ax_idle_ns: 2085701024 ns
[    0.521639] NET: Registered PF_INET protocol family
[    0.522542] IP idents hash table entries: 32768 (order: 6, 262144 bytes,=
 linear)
[    0.524887] tcp_listen_portaddr_hash hash table entries: 1024 (order: 4,=
 73728 bytes, linear)
[    0.526620] Table-perturb hash table entries: 65536 (order: 6, 262144 by=
tes, linear)
[    0.528105] TCP established hash table entries: 16384 (order: 5, 131072 =
bytes, linear)
[    0.532557] TCP bind hash table entries: 16384 (order: 9, 2359296 bytes,=
 linear)
[    0.536739] TCP: Hash tables configured (established 16384 bind 16384)
[    0.539128] MPTCP token hash table entries: 2048 (order: 5, 180224 bytes=
, linear)
[    0.540371] UDP hash table entries: 1024 (order: 6, 262144 bytes, linear=
)
[    0.541517] UDP-Lite hash table entries: 1024 (order: 6, 262144 bytes, l=
inear)
[    0.542936] NET: Registered PF_UNIX/PF_LOCAL protocol family
[    0.543851] NET: Registered PF_XDP protocol family
[    0.544592] pci_bus 0000:00: resource 4 [io  0x0000-0x0cf7 window]
[    0.545510] pci_bus 0000:00: resource 5 [io  0x0d00-0xffff window]
[    0.546432] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff windo=
w]
[    0.547435] pci_bus 0000:00: resource 7 [mem 0x80000000-0xfebfffff windo=
w]
[    0.548457] pci_bus 0000:00: resource 8 [mem 0x100000000-0x17fffffff win=
dow]
[    0.549597] pci 0000:00:01.0: PIIX3: Enabling Passive Release
[    0.550482] pci 0000:00:00.0: Limiting direct PCI/PCI transfers
[    0.551425] PCI: CLS 0 bytes, default 64
[    0.554908] Initialise system trusted keyrings
[    0.556537] Key type blacklist registered
[    0.558226] workingset: timestamp_bits=3D36 max_order=3D19 bucket_order=
=3D0
[    0.560381] zbud: loaded
[    0.566463] integrity: Platform Keyring initialized
[    0.590614] NET: Registered PF_ALG protocol family
[    0.591432] xor: measuring software checksum speed
[    0.592372]    prefetch64-sse  : 22503 MB/sec
[    0.593475]    generic_sse     : 15243 MB/sec
[    0.594241] xor: using function: prefetch64-sse (22503 MB/sec)
[    0.595246] Key type asymmetric registered
[    0.595958] Asymmetric key parser 'x509' registered
[    0.599978] Block layer SCSI generic (bsg) driver version 0.4 loaded (ma=
jor 245)
[    0.602692] io scheduler mq-deadline registered
[    0.603828] io scheduler kyber registered
[    0.604967] io scheduler bfq registered
[    0.610614] atomic64_test: passed for x86-64 platform with CX8 and with =
SSE
[    0.612803] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[    0.614863] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/inpu=
t/input0
[    0.617292] ACPI: button: Power Button [PWRF]
[    0.622286] ACPI: \_SB_.LNKB: Enabled at IRQ 10
Set long mode 1
kvm_xen_hypercall xen_hypercall: cpu 0 cpl 0 input 34 a0 0x0 a1 0xffffa662c=
0013c10 a2 0x0 ret 0x0
kvm_xen_hypercall xen_hypercall: cpu 1 cpl 0 input 20 a0 0x6 a1 0xffffa662c=
0013c18 a2 0x1 ret 0x0
kvm_xen_hypercall xen_hypercall: cpu 1 cpl 0 input 20 a0 0x6 a1 0xffffa662c=
0013c18 a2 0x1 ret 0x0
kvm_xen_hypercall xen_hypercall: cpu 1 cpl 0 input 20 a0 0x6 a1 0xffffa662c=
0013c00 a2 0x1 ret 0x0
kvm_xen_hypercall xen_hypercall: cpu 1 cpl 0 input 20 a0 0x8 a1 0xffffa662c=
0013ba8 a2 0x1 ret 0x0
[    0.628919] xen:grant_table: Grant tables using version 1 layout
kvm_xen_hypercall xen_hypercall: cpu 1 cpl 0 input 20 a0 0x6 a1 0xffffa662c=
0013be0 a2 0x1 ret 0x0
kvm_xen_hypercall xen_hypercall: cpu 1 cpl 0 input 20 a0 0x6 a1 0xffffa662c=
0013bd8 a2 0x1 ret 0x0
kvm_xen_hypercall xen_hypercall: cpu 1 cpl 0 input 12 a0 0x7 a1 0xffffa662c=
0013bc0 a2 0x7ff0 ret 0x0
[    0.631024] Grant table initialized
kvm_xen_hypercall xen_hypercall: cpu 1 cpl 0 input 34 a0 0x1 a1 0xffffa662c=
0013da0 a2 0x7ff0 ret 0xffffffffffffffea



--=-/WS719eLD5TDhjNdeM/Z
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD9Aw
ggSOMIIDdqADAgECAhAOmiw0ECVD4cWj5DqVrT9PMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0yNDAxMzAwMDAwMDBaFw0zMTEx
MDkyMzU5NTlaMEExCzAJBgNVBAYTAkFVMRAwDgYDVQQKEwdWZXJva2V5MSAwHgYDVQQDExdWZXJv
a2V5IFNlY3VyZSBFbWFpbCBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMjvgLKj
jfhCFqxYyRiW8g3cNFAvltDbK5AzcOaR7yVzVGadr4YcCVxjKrEJOgi7WEOH8rUgCNB5cTD8N/Et
GfZI+LGqSv0YtNa54T9D1AWJy08ZKkWvfGGIXN9UFAPMJ6OLLH/UUEgFa+7KlrEvMUupDFGnnR06
aDJAwtycb8yXtILj+TvfhLFhafxroXrflspavejQkEiHjNjtHnwbZ+o43g0/yxjwnarGI3kgcak7
nnI9/8Lqpq79tLHYwLajotwLiGTB71AGN5xK+tzB+D4eN9lXayrjcszgbOv2ZCgzExQUAIt98mre
8EggKs9mwtEuKAhYBIP/0K6WsoMnQCcCAwEAAaOCAVwwggFYMBIGA1UdEwEB/wQIMAYBAf8CAQAw
HQYDVR0OBBYEFIlICOogTndrhuWByNfhjWSEf/xwMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6en
IZ3zbcgPMA4GA1UdDwEB/wQEAwIBhjAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIweQYI
KwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYIKwYB
BQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RD
QS5jcnQwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0
QXNzdXJlZElEUm9vdENBLmNybDARBgNVHSAECjAIMAYGBFUdIAAwDQYJKoZIhvcNAQELBQADggEB
ACiagCqvNVxOfSd0uYfJMiZsOEBXAKIR/kpqRp2YCfrP4Tz7fJogYN4fxNAw7iy/bPZcvpVCfe/H
/CCcp3alXL0I8M/rnEnRlv8ItY4MEF+2T/MkdXI3u1vHy3ua8SxBM8eT9LBQokHZxGUX51cE0kwa
uEOZ+PonVIOnMjuLp29kcNOVnzf8DGKiek+cT51FvGRjV6LbaxXOm2P47/aiaXrDD5O0RF5SiPo6
xD1/ClkCETyyEAE5LRJlXtx288R598koyFcwCSXijeVcRvBB1cNOLEbg7RMSw1AGq14fNe2cH1HG
W7xyduY/ydQt6gv5r21mDOQ5SaZSWC/ZRfLDuEYwggWbMIIEg6ADAgECAhAH5JEPagNRXYDiRPdl
c1vgMA0GCSqGSIb3DQEBCwUAMEExCzAJBgNVBAYTAkFVMRAwDgYDVQQKEwdWZXJva2V5MSAwHgYD
VQQDExdWZXJva2V5IFNlY3VyZSBFbWFpbCBHMjAeFw0yNDEyMzAwMDAwMDBaFw0yODAxMDQyMzU5
NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqGSIb3DQEBAQUAA4IC
DwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZeYAS/SRV6zmfXlXaZ
sNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2zkC9S7/yHDYnqegqt
w4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qGpgFdZEk2/c//ZvUN
i12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41vav1RhZJzYan4a1gU0
kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0cvnO8FM6PTqsnSbcc
0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PWPU6zfQTOMZ9uLQRR
ci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXtREF5lLXxp+CJ6KKS
blPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQrlR0gO3lBzuyPPArV
hvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7IqaAovAX0d+f1YjbmC
VsAwjhLmveFjNwIDAQABo4IBsDCCAawwHwYDVR0jBBgwFoAUiUgI6iBOd2uG5YHI1+GNZIR//HAw
HQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3bXcyQGluZnJhZGVh
ZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEBMA4GA1UdDwEB/wQE
AwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwewYDVR0fBHQwcjA3oDWgM4YxaHR0
cDovL2NybDMuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNybDA3oDWgM4YxaHR0
cDovL2NybDQuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNybDB2BggrBgEFBQcB
AQRqMGgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBABggrBgEFBQcwAoY0
aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNydDANBgkq
hkiG9w0BAQsFAAOCAQEAQXc4FPiPLRnTDvmOABEzkIumojfZAe5SlnuQoeFUfi+LsWCKiB8Uextv
iBAvboKhLuN6eG/NC6WOzOCppn4mkQxRkOdLNThwMHW0d19jrZFEKtEG/epZ/hw/DdScTuZ2m7im
8ppItAT6GXD3aPhXkXnJpC/zTs85uNSQR64cEcBFjjoQDuSsTeJ5DAWf8EMyhMuD8pcbqx5kRvyt
JPsWBQzv1Dsdv2LDPLNd/JUKhHSgr7nbUr4+aAP2PHTXGcEBh8lTeYea9p4d5k969pe0OHYMV5aL
xERqTagmSetuIwolkAuBCzA9vulg8Y49Nz2zrpUGfKGOD0FMqenYxdJHgDCCBZswggSDoAMCAQIC
EAfkkQ9qA1FdgOJE92VzW+AwDQYJKoZIhvcNAQELBQAwQTELMAkGA1UEBhMCQVUxEDAOBgNVBAoT
B1Zlcm9rZXkxIDAeBgNVBAMTF1Zlcm9rZXkgU2VjdXJlIEVtYWlsIEcyMB4XDTI0MTIzMDAwMDAw
MFoXDTI4MDEwNDIzNTk1OVowHjEcMBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzCCAiIwDQYJ
KoZIhvcNAQEBBQADggIPADCCAgoCggIBANqWLse95HW2F7FhfH9bugyT/danKmmXrbMnz5GZNAfj
Jl5gBL9JFXrOZ9eVdpmw04Tp6aDxZctFLoEDvSWKi367Q7Sg+ci+fH4KwwfQ8Pi0IpIKx2n5emEg
nbOQL1Lv/IcNiep6Cq3DiyaSpSp/RZf+CAfUNySHS8eWmhLU6jGpSD6hxTpYKye7PmrmvMWwfGEP
WoamAV1kSTb9z/9m9Q2LXa89aKmTxNwnAfD3Ohn9mtU3JukwILRMewn9QRXK7KzM+01h5hkCE4nj
W9q/VGFknNhqfhrWBTSQoE9CSVylASGrjzCgS7XmKy/BaH3/7mOOHQv5g1o3Qj/+cdKnpT0I5Qb1
nRy+c7wUzo9OqydJtxzSP4ZyHA4dELto/a3m/ay1XHcpum1pgTOLgxAfGb/T4dCkwRUstSKLMmpL
g9Y9TrN9BM4xn24tBFFyL5znGG0wQGzOVAM68RBzIQb6Fz758fjsr4yZnPbVsU1+gHEs/puNHrG0
9e1EQXmUtfGn4InoopJuU8p5VGD9S3Ikd4UoBlc7xl5yjtNlQxUeYrRlnUSmdlucCEoTX1n4UmtA
9CuVHSA7eUHO7I88CtWG9bGOU7tLgOZoSEvNqtaL/N7sQbBZK4jZ4Rr/zNTQg1SwYjjLB7u96lDP
sipoCi8BfR35/ViNuYJWwDCOEua94WM3AgMBAAGjggGwMIIBrDAfBgNVHSMEGDAWgBSJSAjqIE53
a4blgcjX4Y1khH/8cDAdBgNVHQ4EFgQUXGIam3Bs59Y60yTmWgfDu6pZQ6cwMAYDVR0RBCkwJ4ET
ZHdtdzJAaW5mcmFkZWFkLm9yZ4EQZGF2aWRAd29vZGhvdS5zZTAUBgNVHSAEDTALMAkGB2eBDAEF
AQEwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDB7BgNVHR8E
dDByMDegNaAzhjFodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVtYWlsRzIu
Y3JsMDegNaAzhjFodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVtYWlsRzIu
Y3JsMHYGCCsGAQUFBwEBBGowaDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29t
MEAGCCsGAQUFBzAChjRodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVt
YWlsRzIuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQBBdzgU+I8tGdMO+Y4AETOQi6aiN9kB7lKWe5Ch
4VR+L4uxYIqIHxR7G2+IEC9ugqEu43p4b80LpY7M4KmmfiaRDFGQ50s1OHAwdbR3X2OtkUQq0Qb9
6ln+HD8N1JxO5nabuKbymki0BPoZcPdo+FeRecmkL/NOzzm41JBHrhwRwEWOOhAO5KxN4nkMBZ/w
QzKEy4PylxurHmRG/K0k+xYFDO/UOx2/YsM8s138lQqEdKCvudtSvj5oA/Y8dNcZwQGHyVN5h5r2
nh3mT3r2l7Q4dgxXlovERGpNqCZJ624jCiWQC4ELMD2+6WDxjj03PbOulQZ8oY4PQUyp6djF0keA
MYIDuzCCA7cCAQEwVTBBMQswCQYDVQQGEwJBVTEQMA4GA1UEChMHVmVyb2tleTEgMB4GA1UEAxMX
VmVyb2tleSBTZWN1cmUgRW1haWwgRzICEAfkkQ9qA1FdgOJE92VzW+AwDQYJYIZIAWUDBAIBBQCg
ggE3MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTI1MDEwNjE3MTkz
OVowLwYJKoZIhvcNAQkEMSIEIKXVfo3OPQw7JO9wvbRRUI5Lxm3+x8pq3q/nE/wre7xbMGQGCSsG
AQQBgjcQBDFXMFUwQTELMAkGA1UEBhMCQVUxEDAOBgNVBAoTB1Zlcm9rZXkxIDAeBgNVBAMTF1Zl
cm9rZXkgU2VjdXJlIEVtYWlsIEcyAhAH5JEPagNRXYDiRPdlc1vgMGYGCyqGSIb3DQEJEAILMVeg
VTBBMQswCQYDVQQGEwJBVTEQMA4GA1UEChMHVmVyb2tleTEgMB4GA1UEAxMXVmVyb2tleSBTZWN1
cmUgRW1haWwgRzICEAfkkQ9qA1FdgOJE92VzW+AwDQYJKoZIhvcNAQEBBQAEggIAWloFitSkPdKM
gQe82h36CgQaPhUyS9rSOGuTO4Tjm0luT2sGXEj4jHPOTH5k4bKQmFoGqK7CNCbFJBcXFNTAbW4M
NMhRrxD43kAtrw8cJJajBSBbJFNiew6jKmANoZuCb6MI0zI8qa8Jvmb1FLVbgfaAJJqB7effPtP9
oGqvX4YNhMGvT87psWlXgXgbYX+Etj7PrbP71eHsOQ1BoCNAuHa/CpkfHBZKKf39rfJ/gSiLGN18
QIWfQnqe7omd692HZSfH/1y+u1rrtE+TGTsyrwzxm0nIzLX8pjIU/tkann/PVcq2UxSr0+rj0Mjc
OjliIKIM+DlxzgP2b4LTEhIfR2DweX+JV7BQItB7rcIRvzPCNGU68eqfg8d2WDPq7pGJJnf+ftwd
cLl6lMNXxsKa5Y7EhEKdu6m1qPcSB1PG6ZdQrz3+5JGYtQSGxTWG1a7EuWtcspivUtgF+lm+/vVZ
pZxEBvkpl6DOHO+j9VgxvoLM3iatBunrIb81GHOYUXr5ff7EKX5fE1reqmmdmL8GAaE3O1DotTlH
ddcPQrLAvxwWbD9Fhk12xuXRck9KSfntA3Wa/1jtwm1ItPqpN37uj9WtH8BFlbAYAwLikKsERRLY
NbfzJ78T0UD9Gjo82sKGarLTkTtD/gSmGFMXXfgnLmIpgZ/LmyBPTeTE/6RcF1cAAAAAAAA=


--=-/WS719eLD5TDhjNdeM/Z--


From xen-devel-bounces@lists.xenproject.org Mon Jan 06 18:10:41 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 18:10:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865872.1277145 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUrYX-00053G-SI; Mon, 06 Jan 2025 18:10:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865872.1277145; Mon, 06 Jan 2025 18:10:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUrYX-000539-Ph; Mon, 06 Jan 2025 18:10:25 +0000
Received: by outflank-mailman (input) for mailman id 865872;
 Mon, 06 Jan 2025 18:10:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=EjtY=T6=tklengyel.com=tamas@srs-se1.protection.inumbo.net>)
 id 1tUrYW-00052z-BP
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 18:10:24 +0000
Received: from sender4-op-o12.zoho.com (sender4-op-o12.zoho.com
 [136.143.188.12]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7ca00015-cc59-11ef-99a4-01e77a169b0f;
 Mon, 06 Jan 2025 19:10:20 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1736187015314858.5463644416154;
 Mon, 6 Jan 2025 10:10:15 -0800 (PST)
Received: by mail-yb1-f174.google.com with SMTP id
 3f1490d57ef6-e3983426f80so20202503276.1
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 10:10:15 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 7ca00015-cc59-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; t=1736187016; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=nKHh58UsdU5y3OU/9vi0k5sxiTChv/mU4KV/Emh13jiaaTA7bGT8YuA+oEcaMBvWGHudLYPc+f5LdS3brCAeX7xMN2+XhaRBLQog9doY0xdNf81wLa0CncihM0a/ZXcfANuMhTCvmsK9SEBGUxIqjhjKAGoHn4IysCq+gW+7WO0=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1736187016; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=jpeCgrGjWlU8QiIed+qj0vczdYbXeFagU1jWDbDt79c=; 
	b=Mf05+dj5Ev4YShYAR/qui1hVVt80++0sCTAEYVxVSqB4eyh7FIwV3qOPXwu3DrsHQjTRbwYi18Mz5eeng7a9tGpt0Jx8ZlwE1RZFmzc4abFnvpHlDPFa8LwfPQ/uLqIaFxTDXKg+vkFCVYMfKj5l/hrphWeg7hnihDI5mDghy80=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=tklengyel.com;
	spf=pass  smtp.mailfrom=tamas@tklengyel.com;
	dmarc=pass header.from=<tamas@tklengyel.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1736187016;
	s=zmail; d=tklengyel.com; i=tamas@tklengyel.com;
	h=MIME-Version:References:In-Reply-To:From:From:Date:Date:Message-ID:Subject:Subject:To:To:Cc:Cc:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=jpeCgrGjWlU8QiIed+qj0vczdYbXeFagU1jWDbDt79c=;
	b=SrQKs8lpgEyRiEjcxhXygYCOx2ZBkOH4jbra8vMBWR5YQ65neRyHCsBW718TMw8s
	Atg+n6rofvt+QgiqbmvcE63Yu+xHGxuovzRIywSfvdqIOAGNjzZm4jc+9oOL5+/r2Cz
	z7sefYcgitnmaMt55ZMhp8N0Fgy9F7INdE73Gm7w=
X-Forwarded-Encrypted: i=1; AJvYcCWHf7r1by6roU/sutrYluXEvcWQVUx2gQMQiWl77g8C3ilRGqB13JTTiVBs0PfFz/EwbbTJF9t+bHs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwsE9aD+zJWzw726bitHV3LnuzJcaaEeG4YIWF8MX9Rm5P4hBkF
	2nWNZXVsOKNy685ob+wXZ5cEsjjhnfULzhniggt093NvDM5p1kj/hlK8uj3Ka+5WqD6H9d33YmG
	kC1vRAQgcCR9cdNHG7U4LcXUSQ0k=
X-Google-Smtp-Source: AGHT+IFZOhuMxsQs3gfXimRXJ/LFsbQ6jkv+p4pvlLrFDS3kWWkQyU1TJy6cueJ6/k68uQrveewv/Q53eERsXMabtb0=
X-Received: by 2002:a05:690c:6408:b0:6ef:4fba:8142 with SMTP id
 00721157ae682-6f3f80d7ff6mr426640677b3.6.1736187014508; Mon, 06 Jan 2025
 10:10:14 -0800 (PST)
MIME-Version: 1.0
References: <20241230063051.3332332-1-Sergiy_Kibrik@epam.com>
 <c8684340-33f9-41d3-94e4-77ee3bc18306@suse.com> <CABfawhk4pzA9bSMzJDX7ZwaYC50dfn_ntCnk=bePmiKCpDnN3w@mail.gmail.com>
 <8fc662a1-4c74-4f97-a116-3bc5a0b71cf1@suse.com>
In-Reply-To: <8fc662a1-4c74-4f97-a116-3bc5a0b71cf1@suse.com>
From: Tamas K Lengyel <tamas@tklengyel.com>
Date: Mon, 6 Jan 2025 13:09:38 -0500
X-Gmail-Original-Message-ID: <CABfawhkyg+TVB-uc04OefDhOXEfeQyQypW6gL4qsYO3ZrDxYfQ@mail.gmail.com>
Message-ID: <CABfawhkyg+TVB-uc04OefDhOXEfeQyQypW6gL4qsYO3ZrDxYfQ@mail.gmail.com>
Subject: Re: [XEN PATCH v1] xen: mem_access: conditionally compile vm_event.c
 & monitor.c
To: Jan Beulich <jbeulich@suse.com>
Cc: Sergiy Kibrik <Sergiy_Kibrik@epam.com>, Stefano Stabellini <stefano.stabellini@amd.com>, 
	Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, 
	Bertrand Marquis <bertrand.marquis@arm.com>, Michal Orzel <michal.orzel@amd.com>, 
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>, Andrew Cooper <andrew.cooper3@citrix.com>, 
	Anthony PERARD <anthony.perard@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
	Alexandru Isaila <aisaila@bitdefender.com>, Petre Pircalabu <ppircalabu@bitdefender.com>, 
	xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jan 6, 2025 at 10:10=E2=80=AFAM Jan Beulich <jbeulich@suse.com> wro=
te:
>
> On 06.01.2025 15:05, Tamas K Lengyel wrote:
> > On Mon, Jan 6, 2025 at 5:16=E2=80=AFAM Jan Beulich <jbeulich@suse.com> =
wrote:
> >>
> >> On 30.12.2024 07:30, Sergiy Kibrik wrote:
> >>> From: Stefano Stabellini <stefano.stabellini@amd.com>
> >>>
> >>> Extend coverage of CONFIG_MEM_ACCESS option and make the build of VM =
events
> >>> and monitoring support optional.
> >>
> >> Yet doesn't this end up in things becoming misleading? Don't we rather=
 need a
> >> 2nd Kconfig option, with a dependency between the two? Or alternativel=
y a
> >> rename of the existing option (to describe the higher-level feature ra=
ther
> >> than the lower level one)? Tamas, I'm particularly interested in knowi=
ng your
> >> view here as well.
> >
> > Thanks Jan, I was thinking the same thing. The dependency of these
> > subsystems is mem_access -> monitor -> vm_event. If the goal here is
> > to disable all three levels the ideal way would be to have separate
> > kconfig options for each level. It may be a bit too fine-grained
> > though on ARM since there are only two types of events for monitor
> > (SMC & mem_access) and only the monitor uses the vm_event channel (no
> > mem-sharing/paging on ARM). So if doing separate kconfig for each
> > individual feature is an overkill I would suggest using
> > CONFIG_VM_EVENT that disables all three levels, including both
> > mem_access & smc monitor hooks.
>
> Except that "disables all three levels" doesn't work, unless the other
> option(s) are promptless (and selected). I'd have expected VM_EVENT to
> maybe have a "depends on MEM_ACCESS", whereas a "select MEM_ACCESS"
> wouldn't make much sense as long as MEM_ACCESS can be enabled
> individually (with it being unclear to me whether such a configuration
> is actually useful in any way).

Not sure I follow. None of these systems make sense to enable
individually. Without vm_event monitor/mem_access are useless, that's
why I would pick CONFIG_VM_EVENT as the option on ARM to disable all
three levels if we don't want to start splitting it into multiple
kconfig options (which I think may be an overkill here).

Tamas


From xen-devel-bounces@lists.xenproject.org Mon Jan 06 18:43:36 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 18:43:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865882.1277158 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUs4V-0000gJ-Cl; Mon, 06 Jan 2025 18:43:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865882.1277158; Mon, 06 Jan 2025 18:43:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUs4V-0000gC-9H; Mon, 06 Jan 2025 18:43:27 +0000
Received: by outflank-mailman (input) for mailman id 865882;
 Mon, 06 Jan 2025 18:43:25 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=T/Ld=T6=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tUs4T-0000fL-OW
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 18:43:25 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org
 [2604:1380:45d1:ec00::3])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1b3a7664-cc5e-11ef-99a4-01e77a169b0f;
 Mon, 06 Jan 2025 19:43:23 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 5FE6BA41BDA;
 Mon,  6 Jan 2025 18:41:33 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6499EC4CED6;
 Mon,  6 Jan 2025 18:43:20 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1b3a7664-cc5e-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1736189001;
	bh=14MEyWRNSFX0IA/wocvzdjWMOg7YPH0VVd6GhgzZZC0=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=HtNMLdSDpqs+CvqRws1WtE+1iITuDh94nw2qj9X1ZHn3Po0rM1CyxVfz55i0TEfcj
	 MMEesBo7cVIzm0dCwMSf/R7SbOLkjWZ9+mTQRZitGeaFfVSPyDbt3tkSJENkqL4gTG
	 gOioa7CXKlvlb46SdSQPiBTMmLCTurkjxnvM7++vHR87NfLmGX2AE3R4DuxFpTXdb/
	 SfbefUbmeSy+3Sllf6g+WQnGsbqKCc3W4K6B/A62YLfDp1GOO2qR4trbL1NMpFRSob
	 4tfz/45GgGKM4XfFUO21XjK1ngfo4lnMayMdfaUvZ3ic9gIUvTh8MaqxvpyBwQS1kX
	 49dRm8M4cRMJg==
Date: Mon, 6 Jan 2025 10:43:09 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Nicola Vetrini <nicola.vetrini@bugseng.com>
cc: Stefano Stabellini <sstabellini@kernel.org>, 
    Andrew Cooper <andrew.cooper3@citrix.com>, 
    Xen-devel <xen-devel@lists.xenproject.org>, 
    Jan Beulich <JBeulich@suse.com>, 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
    Julien Grall <julien@xen.org>, 
    Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>, 
    Bertrand Marquis <bertrand.marquis@arm.com>, 
    Michal Orzel <michal.orzel@amd.com>, 
    Oleksii Kurochko <oleksii.kurochko@gmail.com>, 
    Shawn Anastasio <sanastasio@raptorengineering.com>
Subject: Re: [PATCH 2/5] xen/perfc: Add perfc_defn.h to asm-generic
In-Reply-To: <de2fb1d4daddcfb2a9de18fb7911c603@bugseng.com>
Message-ID: <alpine.DEB.2.22.394.2501061042590.133435@ubuntu-linux-20-04-desktop>
References: <20250102192508.2405687-1-andrew.cooper3@citrix.com> <20250102192508.2405687-3-andrew.cooper3@citrix.com> <alpine.DEB.2.22.394.2501031525580.16425@ubuntu-linux-20-04-desktop> <de2fb1d4daddcfb2a9de18fb7911c603@bugseng.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-375353694-1736189001=:133435"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-375353694-1736189001=:133435
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Sat, 4 Jan 2025, Nicola Vetrini wrote:
> On 2025-01-04 00:29, Stefano Stabellini wrote:
> > On Thu, 2 Jan 2025, Andrew Cooper wrote:
> > > ... and hook it up for RISC-V and PPC.
> > > 
> > > On RISC-V at least, no combination of headers pulls in errno.h, so include
> > > it
> > > explicitly.
> > > 
> > > Guard the hypercalls array declaration based on NR_hypercalls existing.
> > > This
> > > is sufficient to get PERF_COUNTERS fully working on RISC-V and PPC, so
> > > drop
> > > the randconfig override.
> > > 
> > > Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> > > ---
> > > CC: Jan Beulich <JBeulich@suse.com>
> > > CC: Roger Pau Monné <roger.pau@citrix.com>
> > > CC: Stefano Stabellini <sstabellini@kernel.org>
> > > CC: Julien Grall <julien@xen.org>
> > > CC: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
> > > CC: Bertrand Marquis <bertrand.marquis@arm.com>
> > > CC: Michal Orzel <michal.orzel@amd.com>
> > > CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> > > CC: Shawn Anastasio <sanastasio@raptorengineering.com>
> > > ---
> > >  automation/gitlab-ci/build.yaml      | 1 -
> > >  xen/arch/ppc/include/asm/Makefile    | 1 +
> > >  xen/arch/riscv/include/asm/Makefile  | 1 +
> > >  xen/common/perfc.c                   | 1 +
> > >  xen/include/asm-generic/perfc_defn.h | 5 +++++
> > >  xen/include/xen/perfc_defn.h         | 2 ++
> > >  6 files changed, 10 insertions(+), 1 deletion(-)
> > >  create mode 100644 xen/include/asm-generic/perfc_defn.h
> > > 
> 
> > > diff --git a/xen/include/asm-generic/perfc_defn.h
> > > b/xen/include/asm-generic/perfc_defn.h
> > > new file mode 100644
> > > index 000000000000..8237636d83fb
> > > --- /dev/null
> > > +++ b/xen/include/asm-generic/perfc_defn.h
> > > @@ -0,0 +1,5 @@
> > > +/* This file is legitimately included multiple times. */
> > 
> > It is a good idea to add comment here to explain. This is effectively
> > the same as a deviation of MISRA D4.10. SAF-8-safe is defined as
> > "Headers that deliberatively leave the responsability of their correct
> > inclusion to the caller are allowed". I think it applies, please add
> > SAF-8-safe to this comment and also the other perfc_defn.h, e.g.:
> > 
> > /* SAF-8-safe This file is legitimately included multiple times. */
> > 
> 
> There is already a deviation in place for this kind of files, so I think
> that's good as is, no need for a SAF tag.
> 
> -doc_begin="Files that are intended to be included more than once do not need
> to
> conform to the directive."
> -config=MC3A2.D4.10,reports+={safe, "first_area(text(^/\\* This file is
> legitimately included multiple times\\. \\*/$, begin-4))"}

Thanks Nicola, I didn't realize that.

In that case:

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>

--8323329-375353694-1736189001=:133435--


From xen-devel-bounces@lists.xenproject.org Mon Jan 06 18:48:24 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 18:48:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865890.1277169 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUs9G-0001FI-Tk; Mon, 06 Jan 2025 18:48:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865890.1277169; Mon, 06 Jan 2025 18:48:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUs9G-0001FB-QT; Mon, 06 Jan 2025 18:48:22 +0000
Received: by outflank-mailman (input) for mailman id 865890;
 Mon, 06 Jan 2025 18:48:21 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=T/Ld=T6=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tUs9F-0001F5-MR
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 18:48:21 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id cbb75cc7-cc5e-11ef-99a4-01e77a169b0f;
 Mon, 06 Jan 2025 19:48:19 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 03FB15C5CCD;
 Mon,  6 Jan 2025 18:47:37 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id E3887C4CED2;
 Mon,  6 Jan 2025 18:48:16 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: cbb75cc7-cc5e-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1736189297;
	bh=StKZKILXt9SnW45gvGVYlW2CAXTja7eetln+MZhsxkk=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=vPyPn+tNwaZ0SwvP01a0SL4o37rrr8ARIGdkyHuhiXJzCzr7th07cA8SMjvKiblqq
	 zKPuG6S6NOsF60sD/bq1q2c7NXzhiNlXuUDz3aM3CeAe9jgAR1dDAGHc5iwFETfEgW
	 evHZecugjpo4ZZ3ltqLBUvUlN1OIfbJrylxT9/ZE85GU0btfgsLB8l2Q8tTXvW7T8Q
	 nbVjdO35xQ0Lc4ZSt1ry0j/QS83Uuih6pkz0PelVQTsj1NQ2bS8xDjqSdWSfvBwqLQ
	 CqjCO7G6EqWu+kV9uh9hQlkcVr5JC0Fif6Ogg0mTpsgM1V3JrCA1BRxlpLFI80zuyU
	 GF/GFUvW91s2A==
Date: Mon, 6 Jan 2025 10:48:15 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich <jbeulich@suse.com>
cc: Denis Mukhin <dmkhn@proton.me>, dmukhin@ford.com, 
    xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, 
    Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2 20/35] xen/console: introduce console_owner_domid()
In-Reply-To: <8a5a5a0f-72b0-4336-b0d2-142254319242@suse.com>
Message-ID: <alpine.DEB.2.22.394.2501061046060.133435@ubuntu-linux-20-04-desktop>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-20-e9aa923127eb@ford.com> <d55bf6a6-5861-4b72-88b5-2aaa28ae0290@suse.com> <VJ9ivpkbNlqfKhBlb5dL6OuoPAXK9wqD4mhgO9Qt4f0qgmuow22qFv1C7L8DlbKYo7ytdKWeV1bLaYJvTAc2Yt7sEd06XREerWER5RPx4No=@proton.me>
 <8a5a5a0f-72b0-4336-b0d2-142254319242@suse.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 6 Jan 2025, Jan Beulich wrote:
> On 04.01.2025 05:15, Denis Mukhin wrote:
> > 
> > On Tuesday, December 10th, 2024 at 11:28 PM, Jan Beulich <jbeulich@suse.com> wrote:
> > 
> >>
> >>
> >> On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
> >>
> >>> From: Denis Mukhin dmukhin@ford.com
> >>>
> >>> console_owner_domid() is introduced to obtain the "console owner" domain ID.
> >>>
> >>> The call is used in NS8250 emulator to identify the case when physical xen
> >>> console focus is owned by the domain w/ NS8250 emulator, in which case,
> >>> messages from guest OS are formatted w/o '(XEN)' prefix.
> >>
> >>
> >> Such messages ought to be processed through guest_printk(), which wants a
> >> domain pointer, not a domid_t anyway. Plus isn't that going to be
> >> current->domain anyway at the callsite, eliminating the need for such a
> >>
> >> helper altogether?
> > 
> > If the current domain is owning the physical console and printing, say, Linux
> > login prompt, there's no need to add "(XEN)" for every printout; adding timestamps
> > can be disabled from Xen command line.
> 
> Surely there shouldn't be (XEN), but without (d<N>) it'll be ambiguous in a log
> which domain a message came from. As long as only Dom0 messages are left un-
> prefixed, that's likely fine. Yet as soon as multiple domains can issue such
> messages (and have console "focus") I think the prefix needs to be there.

Hi Jan,

It looks like we are aligned on the desired behavior, but for clarity,
see https://marc.info/?l=xen-devel&m=173405161613716, also copy/pasted
here:

I think we should provide a consistent behavior across architectures.
The current behavior with vpl011 and dom0less on ARM is the following:

- no prefix for Dom0 output
- DOM$NUM for DomUs when not in focus, otherwise no prefix

It is OK to change this behavior, but in that case I would ask that we
change it consistently also for ARM.


From xen-devel-bounces@lists.xenproject.org Mon Jan 06 20:03:20 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 20:03:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865899.1277183 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUtJc-0002eJ-31; Mon, 06 Jan 2025 20:03:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865899.1277183; Mon, 06 Jan 2025 20:03:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUtJc-0002eC-0S; Mon, 06 Jan 2025 20:03:08 +0000
Received: by outflank-mailman (input) for mailman id 865899;
 Mon, 06 Jan 2025 20:03:07 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=iH3c=T6=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tUtJb-0002e6-ES
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 20:03:07 +0000
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com
 [2a00:1450:4864:20::32c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3d0314b3-cc69-11ef-99a4-01e77a169b0f;
 Mon, 06 Jan 2025 21:03:04 +0100 (CET)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-436202dd730so105999775e9.2
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 12:03:04 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-43656b3b2a4sm611962245e9.27.2025.01.06.12.02.59
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 06 Jan 2025 12:03:01 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 3d0314b3-cc69-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1736193783; x=1736798583; 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=IVQDyU0aZGqnbGo58WYklNw0MeL8aFrKkG5Vri/XHzI=;
        b=K4ceTbOG2KX/ZFEBwDxgjCIH0T+7OzmE+FLxEy7KrSV4eusCt6SaJDhluG7/oj2TUD
         CeQkQ8VVXIQa32VR0Cc2g/35ZeDljR6EnqtALffXfDaj/jRqq3fHghtVWjrQTdHqsCr3
         pdy7DeCcQeRfKYZItU7TtuixJkaSvXyP6xVud1pY4Yi6Sbgtpf1icP2Ulr0XEiBq16nd
         9zQxYrpbJusIEetuJhHj0gdmvEnPiiDA7FWfHAjxs9wKiUH1qSkbooDaVfuhrhSlaD9b
         GLYq3bImjWBlybjECnqvSxDcrtsVq9/PN6Ul+78Z0oxLGgQFlLtzFK1YDIVeOpCCVV53
         eqqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736193783; x=1736798583;
        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=IVQDyU0aZGqnbGo58WYklNw0MeL8aFrKkG5Vri/XHzI=;
        b=fi3nidnxVBJCET1rsWAKB1NqA8Jc8V+0cMaZ87udw3ql1PzEGYivjEajRA8nlevR94
         f3I7wFyFE103t3lPeWcOeTKq/ihYKHaUZ+s3hrib5OLfO5MaeXvIg0+je1cNRc5QP060
         PuFJiyTyhZVZCZthZIK3xVi82bfNguIHArEdOto/AxtUdHqhkOq49SHTH1/zrxlxRQQW
         XsRjwDH8h7xYvIvX4q2jQaSIh1NVUsTIjK2rjnnoJp1iH5DMT7bWmMu2nOb4+CAi5may
         GJyD+Q0xWhzurZ4niGh4k0wB4U/nH8PkB+LMu6/E78gYJ0rjc5CEAiSDbrueBX46UwOo
         beGQ==
X-Forwarded-Encrypted: i=1; AJvYcCVXCbA6APnFwncDYzspKK023VPBLN8xe3elEga/tfsop+R42zc1IXPyPD52RAmbKR3rL2hzdgnr+7k=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz22jsmjExWKqcgGr7LcHntZrBL9dk92yxwmGRDNEWOUqX1bFqO
	LhQr4FBtbqJKtUFwcmDD5RIOPHMfTMn0ipDln6A7cbHWLvnxJ0Ikz4WgVeEo6xk=
X-Gm-Gg: ASbGncunNMXsIeGd0MHSYTHa/rFSvft8xn7Q7S/EbvJPW3PGhFN8k5KvtXyxHVd0nVy
	XBCyegzSYn2nbTQsn4MBE7HzQu6VnpA8AbUlZZmGTBNYV8sgAhxpwDXBGmbFWD6mwHW9IYMBGy0
	7y08in0BCAlBISvvXQ48+2O7Di8q71eHHQkP0wj7oCTctJcAacEWEUvtxE3qQVulUMCbhIIRoP2
	Mc+HfKuEoqGpJoPU1I071ZxGxSy95TLfbYFKAdGw/W3CM5qNJXAsUUkfBo/emVdRTWoIJ7BaJH6
	FbQjXg8rNmrjkNg+PiEQJQgdFm8o4To=
X-Google-Smtp-Source: AGHT+IEvY1dOIYQWFga9MrJsSFG0JoKzIh1x57mMzgTfD/hBdAZ0c+WqLtNl81G5solsww92cOjYAA==
X-Received: by 2002:a05:600c:450f:b0:434:fb65:ebbb with SMTP id 5b1f17b1804b1-436686461cbmr539399575e9.17.1736193783280;
        Mon, 06 Jan 2025 12:03:03 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: Daniel Henrique Barboza <dbarboza@ventanamicro.com>,
	=?UTF-8?q?Fr=C3=A9d=C3=A9ric=20Barrat?= <fbarrat@linux.ibm.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Ilya Leoshkevich <iii@linux.ibm.com>,
	Cameron Esfahani <dirty@apple.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	kvm@vger.kernel.org,
	Alexander Graf <agraf@csgraf.de>,
	Paul Durrant <paul@xen.org>,
	David Hildenbrand <david@redhat.com>,
	Halil Pasic <pasic@linux.ibm.com>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
	xen-devel@lists.xenproject.org,
	qemu-arm@nongnu.org,
	=?UTF-8?q?C=C3=A9dric=20Le=20Goater?= <clg@redhat.com>,
	Yanan Wang <wangyanan55@huawei.com>,
	Reinoud Zandijk <reinoud@netbsd.org>,
	Peter Maydell <peter.maydell@linaro.org>,
	qemu-s390x@nongnu.org,
	Riku Voipio <riku.voipio@iki.fi>,
	Anthony PERARD <anthony@xenproject.org>,
	Alistair Francis <alistair.francis@wdc.com>,
	Sunil Muthuswamy <sunilmut@microsoft.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	Nicholas Piggin <npiggin@gmail.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Thomas Huth <thuth@redhat.com>,
	Roman Bolshakov <rbolshakov@ddn.com>,
	"Edgar E . Iglesias" <edgar.iglesias@amd.com>,
	Zhao Liu <zhao1.liu@intel.com>,
	Phil Dennis-Jordan <phil@philjordan.eu>,
	David Woodhouse <dwmw2@infradead.org>,
	Harsh Prateek Bora <harshpb@linux.ibm.com>,
	Nina Schoetterl-Glausch <nsg@linux.ibm.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Eduardo Habkost <eduardo@habkost.net>,
	qemu-ppc@nongnu.org,
	Daniel Henrique Barboza <danielhb413@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Anton Johansson <anjo@rev.ng>
Subject: [RFC PATCH 0/7] accel: Add per-accelerator vCPUs queue
Date: Mon,  6 Jan 2025 21:02:51 +0100
Message-ID: <20250106200258.37008-1-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Hi,

Currently we register all vCPUs to the global 'cpus_queue' queue,
however we can not discriminate per accelerator or per target
architecture (which might happen in a soon future).

This series tries to add an accelerator discriminator, so
accelerator specific code can iterate on its own vCPUs. This
is required to run a pair of HW + SW accelerators like the
(HVF, TCG) or (KVM, TCG) combinations. Otherwise, i.e. the
HVF core code could iterate on TCG vCPUs...
To keep it simple and not refactor heavily the code base,
we introduce the CPU_FOREACH_TCG/HVF/KVM() macros, only
defined for each accelerator.

This is just a RFC to get some thoughts whether this is
heading in the correct direction or not ;)

Regards,

Phil.

Philippe Mathieu-Daudé (7):
  cpus: Restrict CPU_FOREACH_SAFE() to user emulation
  cpus: Introduce AccelOpsClass::get_cpus_queue()
  accel/tcg: Implement tcg_get_cpus_queue()
  accel/tcg: Use CPU_FOREACH_TCG()
  accel/hw: Implement hw_accel_get_cpus_queue()
  accel/hvf: Use CPU_FOREACH_HVF()
  accel/kvm: Use CPU_FOREACH_KVM()

 accel/tcg/tcg-accel-ops.h         | 10 ++++++++++
 include/hw/core/cpu.h             | 11 +++++++++++
 include/system/accel-ops.h        |  6 ++++++
 include/system/hvf_int.h          |  4 ++++
 include/system/hw_accel.h         |  9 +++++++++
 include/system/kvm_int.h          |  3 +++
 accel/accel-system.c              |  8 ++++++++
 accel/hvf/hvf-accel-ops.c         |  9 +++++----
 accel/kvm/kvm-accel-ops.c         |  1 +
 accel/kvm/kvm-all.c               | 14 +++++++-------
 accel/tcg/cputlb.c                |  7 ++++---
 accel/tcg/monitor.c               |  3 ++-
 accel/tcg/tb-maint.c              |  7 ++++---
 accel/tcg/tcg-accel-ops-rr.c      | 10 +++++-----
 accel/tcg/tcg-accel-ops.c         | 16 ++++++++++++----
 accel/tcg/user-exec-stub.c        |  5 +++++
 accel/xen/xen-all.c               |  1 +
 cpu-common.c                      | 10 ++++++++++
 hw/i386/kvm/clock.c               |  3 ++-
 hw/intc/spapr_xive_kvm.c          |  5 +++--
 hw/intc/xics_kvm.c                |  5 +++--
 system/cpus.c                     |  5 +++++
 target/arm/hvf/hvf.c              |  4 ++--
 target/i386/kvm/kvm.c             |  4 ++--
 target/i386/kvm/xen-emu.c         |  2 +-
 target/i386/nvmm/nvmm-accel-ops.c |  1 +
 target/i386/whpx/whpx-accel-ops.c |  1 +
 target/s390x/kvm/kvm.c            |  2 +-
 target/s390x/kvm/stsi-topology.c  |  3 ++-
 29 files changed, 130 insertions(+), 39 deletions(-)

-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Mon Jan 06 20:03:20 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 20:03:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865902.1277203 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUtJn-0003Bq-Ke; Mon, 06 Jan 2025 20:03:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865902.1277203; Mon, 06 Jan 2025 20:03:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUtJn-0003Bd-HJ; Mon, 06 Jan 2025 20:03:19 +0000
Received: by outflank-mailman (input) for mailman id 865902;
 Mon, 06 Jan 2025 20:03: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 <SRS0=iH3c=T6=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tUtJl-0002e6-QF
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 20:03:17 +0000
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com
 [2a00:1450:4864:20::329])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 443e5027-cc69-11ef-99a4-01e77a169b0f;
 Mon, 06 Jan 2025 21:03:16 +0100 (CET)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-43635796b48so89318005e9.0
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 12:03:16 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4366128a353sm577748615e9.42.2025.01.06.12.03.12
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 06 Jan 2025 12:03:15 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 443e5027-cc69-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1736193795; x=1736798595; 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=xubr80DdDK1TQnuEw657hT2ILmCSL1Bi/K/I0ME5hpI=;
        b=Z4/zdLcV/crESVhVabhQYBni+lmsiCCndmM88y5yJ7hPu4aaG2wSoyGhbEMxbpk7bv
         zEE2kpVpJ86cOf+1uUEaKotVnwcu2M7+GlgzUbj9JU1D9h9me+Waw+rMona96fEcvFL/
         EtSyKviN0YTJ+CIwKQqEmaIC8xQFCEVFEZxVQ2FgRBTXFYwzhKRtG1VMh5ySR0ThV8J2
         6Ap2ZJEDXsx3LetuLd5o5PfmQow3lusntyt3ku55vRWFI47XibE1Mt4ukwp8lSGpKXH8
         c8MaK875hig5itxqrhB3Av4tZC8D0QRAVk6BPYdEmkXuMu+tU4dbaJr3P0y4Bbc6QjUr
         hHOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736193795; x=1736798595;
        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=xubr80DdDK1TQnuEw657hT2ILmCSL1Bi/K/I0ME5hpI=;
        b=n0jfWCwazboGTCtrEOQkNjZGVPu1bKEYy9ISmsiIFZxS6DIsmRWjN/PPW7FuZU8uTh
         LTGqdWyDu+/ykwrr1k9wiJIAsDfb0FVCI+bzxNV+BuLhY7VnkbjqViJl/OAe+9KhUBNF
         WeuKsi+EN2eybn7mmQEVOgDpEuqUZLY44h5n+WirB2fm3GLUpjb76bock1+emLL+RZoO
         2B4vche5B/IgRB1UEBT1ywGoDLWA4RvXzjPYZouBZ1sCroIR8XtPZOfie7MXzOku/ntK
         mjg2ppRuuKPUnZ6jJge522e0i5L5EarrGRP/Azn84Fp4pAUx0raEvETIZ2PmI+I68bdp
         LPtg==
X-Forwarded-Encrypted: i=1; AJvYcCX/UModMtUrRF/D/9YkghwB/k2PaaE9aP0GAqrHaT5BcHh482B85TI4DKs4W1m4Fhq5MfgSz3Edp+U=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yze56e0eCoxQNwGXUKVDXSRqcEWj0CvDUCSlqCaY9v9zzk5THq7
	GCyLG4u5T85aeJl8r0RoDR9NdjJhJK5+UKBzWR5Ab1Xy8SSQBmAfybluUNjq/MA=
X-Gm-Gg: ASbGncvvXgWxcVVDcPuPAjGDsWx3z2hGM/G2NLBbqhDKAPcwUR3FrJBTpljIuY4cHkk
	pmfNqR52f4Jp765SFXmEqznHUFQXq6iHoxpV1M716BYY8lTWbOAOBKH1kL77SdN/p2a6Rv87fgc
	J9fKEo6utw+XnqtDAa8TY4TZaRqBcP7KnVWRB6afWXONMUSsZTabVVX3Wo/lgLZ0c1Fd0qrimWw
	efYH1lnt3NrJvQzFTs8MvrRLOsN1B8ixlwursEHjJ84ccjpjAR8E+bcKoyPLlY7xxG8k0bJ/Blh
	sUyNbPlogzB07G7NYXAHNAv924CCAfs=
X-Google-Smtp-Source: AGHT+IG6hn6gQ1rEDpo0RUo5rK6HsOddWfOpcS85mXtVNMxlfkCCUdnnKaA6rQB2Q6OTZ5JLDkEevw==
X-Received: by 2002:a05:600c:1d12:b0:436:1b86:f05 with SMTP id 5b1f17b1804b1-436dc20b0c1mr4405765e9.11.1736193795597;
        Mon, 06 Jan 2025 12:03:15 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: Daniel Henrique Barboza <dbarboza@ventanamicro.com>,
	=?UTF-8?q?Fr=C3=A9d=C3=A9ric=20Barrat?= <fbarrat@linux.ibm.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Ilya Leoshkevich <iii@linux.ibm.com>,
	Cameron Esfahani <dirty@apple.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	kvm@vger.kernel.org,
	Alexander Graf <agraf@csgraf.de>,
	Paul Durrant <paul@xen.org>,
	David Hildenbrand <david@redhat.com>,
	Halil Pasic <pasic@linux.ibm.com>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
	xen-devel@lists.xenproject.org,
	qemu-arm@nongnu.org,
	=?UTF-8?q?C=C3=A9dric=20Le=20Goater?= <clg@redhat.com>,
	Yanan Wang <wangyanan55@huawei.com>,
	Reinoud Zandijk <reinoud@netbsd.org>,
	Peter Maydell <peter.maydell@linaro.org>,
	qemu-s390x@nongnu.org,
	Riku Voipio <riku.voipio@iki.fi>,
	Anthony PERARD <anthony@xenproject.org>,
	Alistair Francis <alistair.francis@wdc.com>,
	Sunil Muthuswamy <sunilmut@microsoft.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	Nicholas Piggin <npiggin@gmail.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Thomas Huth <thuth@redhat.com>,
	Roman Bolshakov <rbolshakov@ddn.com>,
	"Edgar E . Iglesias" <edgar.iglesias@amd.com>,
	Zhao Liu <zhao1.liu@intel.com>,
	Phil Dennis-Jordan <phil@philjordan.eu>,
	David Woodhouse <dwmw2@infradead.org>,
	Harsh Prateek Bora <harshpb@linux.ibm.com>,
	Nina Schoetterl-Glausch <nsg@linux.ibm.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Eduardo Habkost <eduardo@habkost.net>,
	qemu-ppc@nongnu.org,
	Daniel Henrique Barboza <danielhb413@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Anton Johansson <anjo@rev.ng>
Subject: [RFC PATCH 2/7] cpus: Introduce AccelOpsClass::get_cpus_queue()
Date: Mon,  6 Jan 2025 21:02:53 +0100
Message-ID: <20250106200258.37008-3-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250106200258.37008-1-philmd@linaro.org>
References: <20250106200258.37008-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

We want the ability to iterate over vCPUs of a specific
accelerator.  Introduce cpus_get_accel_cpus_queue() to
be used by accelerator common code, and expose the
get_cpus_queue() in AccelOpsClass, so each accelerator
can register its own queue of vCPUs.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 include/hw/core/cpu.h      |  8 ++++++++
 include/system/accel-ops.h |  6 ++++++
 accel/tcg/user-exec-stub.c |  5 +++++
 cpu-common.c               | 10 ++++++++++
 system/cpus.c              |  5 +++++
 5 files changed, 34 insertions(+)

diff --git a/include/hw/core/cpu.h b/include/hw/core/cpu.h
index 48d90f50a71..5ae9bb64d6e 100644
--- a/include/hw/core/cpu.h
+++ b/include/hw/core/cpu.h
@@ -591,6 +591,14 @@ static inline CPUArchState *cpu_env(CPUState *cpu)
 typedef QTAILQ_HEAD(CPUTailQ, CPUState) CPUTailQ;
 extern CPUTailQ cpus_queue;
 
+/**
+ * cpus_get_accel_cpus_queue:
+ * @cpu: The vCPU to get the accelerator #CPUTailQ.
+ *
+ * Returns the #CPUTailQ associated with the accelerator of the vCPU.
+ */
+CPUTailQ *cpus_get_accel_cpus_queue(CPUState *cpu);
+
 #define first_cpu        QTAILQ_FIRST_RCU(&cpus_queue)
 #define CPU_NEXT(cpu)    QTAILQ_NEXT_RCU(cpu, node)
 #define CPU_FOREACH(cpu) QTAILQ_FOREACH_RCU(cpu, &cpus_queue, node)
diff --git a/include/system/accel-ops.h b/include/system/accel-ops.h
index 137fb96d444..fe59f728bfc 100644
--- a/include/system/accel-ops.h
+++ b/include/system/accel-ops.h
@@ -12,6 +12,7 @@
 
 #include "exec/vaddr.h"
 #include "qom/object.h"
+#include "hw/core/cpu.h"
 
 #define ACCEL_OPS_SUFFIX "-ops"
 #define TYPE_ACCEL_OPS "accel" ACCEL_OPS_SUFFIX
@@ -37,6 +38,11 @@ struct AccelOpsClass {
     bool (*cpus_are_resettable)(void);
     void (*cpu_reset_hold)(CPUState *cpu);
 
+    /**
+     * get_cpus_queue:
+     * Returns the #CPUTailQ maintained by this accelerator.
+     */
+    CPUTailQ *(*get_cpus_queue)(void);
     void (*create_vcpu_thread)(CPUState *cpu); /* MANDATORY NON-NULL */
     void (*kick_vcpu_thread)(CPUState *cpu);
     bool (*cpu_thread_is_idle)(CPUState *cpu);
diff --git a/accel/tcg/user-exec-stub.c b/accel/tcg/user-exec-stub.c
index 4fbe2dbdc88..cb76cec76be 100644
--- a/accel/tcg/user-exec-stub.c
+++ b/accel/tcg/user-exec-stub.c
@@ -18,6 +18,11 @@ void cpu_exec_reset_hold(CPUState *cpu)
 {
 }
 
+CPUTailQ *cpus_get_accel_cpus_queue(CPUState *cpu)
+{
+    return NULL;
+}
+
 /* User mode emulation does not support record/replay yet.  */
 
 bool replay_exception(void)
diff --git a/cpu-common.c b/cpu-common.c
index 4248b2d727e..ff8db9c7f9d 100644
--- a/cpu-common.c
+++ b/cpu-common.c
@@ -82,6 +82,7 @@ unsigned int cpu_list_generation_id_get(void)
 void cpu_list_add(CPUState *cpu)
 {
     static bool cpu_index_auto_assigned;
+    CPUTailQ *accel_cpus_queue = cpus_get_accel_cpus_queue(cpu);
 
     QEMU_LOCK_GUARD(&qemu_cpu_list_lock);
     if (cpu->cpu_index == UNASSIGNED_CPU_INDEX) {
@@ -92,17 +93,26 @@ void cpu_list_add(CPUState *cpu)
         assert(!cpu_index_auto_assigned);
     }
     QTAILQ_INSERT_TAIL_RCU(&cpus_queue, cpu, node);
+    if (accel_cpus_queue) {
+        QTAILQ_INSERT_TAIL_RCU(accel_cpus_queue, cpu, node);
+    }
+
     cpu_list_generation_id++;
 }
 
 void cpu_list_remove(CPUState *cpu)
 {
+    CPUTailQ *accel_cpus_queue = cpus_get_accel_cpus_queue(cpu);
+
     QEMU_LOCK_GUARD(&qemu_cpu_list_lock);
     if (!QTAILQ_IN_USE(cpu, node)) {
         /* there is nothing to undo since cpu_exec_init() hasn't been called */
         return;
     }
 
+    if (accel_cpus_queue) {
+        QTAILQ_REMOVE_RCU(accel_cpus_queue, cpu, node);
+    }
     QTAILQ_REMOVE_RCU(&cpus_queue, cpu, node);
     cpu->cpu_index = UNASSIGNED_CPU_INDEX;
     cpu_list_generation_id++;
diff --git a/system/cpus.c b/system/cpus.c
index 99f83806c16..972df6ab061 100644
--- a/system/cpus.c
+++ b/system/cpus.c
@@ -209,6 +209,11 @@ void cpu_exec_reset_hold(CPUState *cpu)
     }
 }
 
+CPUTailQ *cpus_get_accel_cpus_queue(CPUState *cpu)
+{
+    return cpus_accel ? cpus_accel->get_cpus_queue() : NULL;
+}
+
 int64_t cpus_get_virtual_clock(void)
 {
     /*
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Mon Jan 06 20:03:20 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 20:03:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865900.1277193 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUtJg-0002sn-AN; Mon, 06 Jan 2025 20:03:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865900.1277193; Mon, 06 Jan 2025 20:03:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUtJg-0002sg-7M; Mon, 06 Jan 2025 20:03:12 +0000
Received: by outflank-mailman (input) for mailman id 865900;
 Mon, 06 Jan 2025 20:03:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=iH3c=T6=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tUtJe-0002s4-VR
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 20:03:10 +0000
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com
 [2a00:1450:4864:20::429])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 40584bf3-cc69-11ef-a0df-8be0dac302b0;
 Mon, 06 Jan 2025 21:03:09 +0100 (CET)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-3862d16b4f5so9136527f8f.0
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 12:03:09 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-43665cd9c29sm559552815e9.14.2025.01.06.12.03.07
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 06 Jan 2025 12:03:08 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 40584bf3-cc69-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1736193789; x=1736798589; 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=Gw/8miEe/PnaBFePSWTnOg3qI2ZvVUjrjdrVrAxgzBI=;
        b=GpJJjrGhEDpawdBPjjACmpCUFkHH8FrwXHA1FDOcG1DfCYoQvJ7sd7OsxDyLC/NOCK
         3i0AtcqPDWHQffFFaTDxmmcMhaTVQfarHruEW5tZAtVGovP6qy9tHMnFWTvgmgiJlSND
         F82UOzjdOC3Ugdj+m13ayr5SG2HkwEmkXyk8e24A8umZBLfFWIQ0ZDermyxMet+HuAhV
         cqc7sWecdDJ5SSkt5njszm8OMzvRR+fbajtxA1Ehi54RCG27B9IZ2EeRR5vq7K9ndoeR
         F+yQaD2DEpSFLbv+fa8Mb5RVhZeWEmrW+LeIVbRwceig6c8CzdxsJMScDsW+plcNcHuZ
         /lWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736193789; x=1736798589;
        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=Gw/8miEe/PnaBFePSWTnOg3qI2ZvVUjrjdrVrAxgzBI=;
        b=rmE8ZhVvPQgif4MkjHcddxr5N26o/JNL6PP0fiGKtyMjQujAUM8n2asEI00EmOwU4m
         d6V/8JG/2BYagCp2Ze99ix0FOOmZKAOjJp2sOkb+evhMTrCpyVZvwK9Z2doC33Q+1Esm
         Dqc4yoYSlpU4j6W950SbDRf7lGUhQv2FdazkgkDXuC2TFM2TRavcFMa+/9ID2mO6p3WH
         zgQaMdNuDL7nLOH9pOwICpb+GrzLBqT56BOSx5PJTFMdT+Q2LKxmKbO3Jur7cKd3QAor
         6OaNo2pCQ9EujXWn7AWPnoVmq03IonUFNXuwV0bWUort1my9wTaEMFJSdfMI1d93K9PH
         m4Jw==
X-Forwarded-Encrypted: i=1; AJvYcCVdD9R58Aaq0lgng7AFlXgOKVr6U6nQgqmx9OUd4nHzo49RrrqzAqgdl2wjCwufutH6bwlJ9sYQ+Ow=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzvaU9FywNO88ub3tWHClZIxecD9wKJYoZIRizxOINaOz1BiDko
	0wkOFaW76dqtiK6unDEwfA4gvsVVfsTjj96nqsQKLvt8zv2mU3wNs2Stct7CCkc=
X-Gm-Gg: ASbGncvUgxOsbFNz4qUnfRVLXqMiH2ja6u7aEFSnYpAMk797Au2U2Xo7gBCQIeXOsLy
	D9iorM633cnwXMqGO9Q7QgOGmPLBOlf2AzPGGlpqxJ2xuLLzTDUagwYTa0OgxEclf0EUfyDxvkv
	LXm+sRwoNK8OkCRw7DH5qi6iytixU19htgn08D6I61xwuluo0UpYzUtEgKuEIwsX0Z899fQJv36
	n2nHXH8TaFxaXx6niqSbkvdcogNNK7SMR72MJ4HCnYsby11oI36YDbL6hAA9weX+9/NEHU4Nx4V
	LUVz3w4Onj5B/hsxRoPmRgptkbNbUoU=
X-Google-Smtp-Source: AGHT+IE81N1RplBD8FCsdoj95sqyVSqitqWpe38bLlQuumoNL1lLDdZMOpwBwgd43Npz//MFxfo/tw==
X-Received: by 2002:a5d:64ac:0:b0:38a:4df5:a08 with SMTP id ffacd0b85a97d-38a7923b959mr440924f8f.22.1736193788891;
        Mon, 06 Jan 2025 12:03:08 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: Daniel Henrique Barboza <dbarboza@ventanamicro.com>,
	=?UTF-8?q?Fr=C3=A9d=C3=A9ric=20Barrat?= <fbarrat@linux.ibm.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Ilya Leoshkevich <iii@linux.ibm.com>,
	Cameron Esfahani <dirty@apple.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	kvm@vger.kernel.org,
	Alexander Graf <agraf@csgraf.de>,
	Paul Durrant <paul@xen.org>,
	David Hildenbrand <david@redhat.com>,
	Halil Pasic <pasic@linux.ibm.com>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
	xen-devel@lists.xenproject.org,
	qemu-arm@nongnu.org,
	=?UTF-8?q?C=C3=A9dric=20Le=20Goater?= <clg@redhat.com>,
	Yanan Wang <wangyanan55@huawei.com>,
	Reinoud Zandijk <reinoud@netbsd.org>,
	Peter Maydell <peter.maydell@linaro.org>,
	qemu-s390x@nongnu.org,
	Riku Voipio <riku.voipio@iki.fi>,
	Anthony PERARD <anthony@xenproject.org>,
	Alistair Francis <alistair.francis@wdc.com>,
	Sunil Muthuswamy <sunilmut@microsoft.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	Nicholas Piggin <npiggin@gmail.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Thomas Huth <thuth@redhat.com>,
	Roman Bolshakov <rbolshakov@ddn.com>,
	"Edgar E . Iglesias" <edgar.iglesias@amd.com>,
	Zhao Liu <zhao1.liu@intel.com>,
	Phil Dennis-Jordan <phil@philjordan.eu>,
	David Woodhouse <dwmw2@infradead.org>,
	Harsh Prateek Bora <harshpb@linux.ibm.com>,
	Nina Schoetterl-Glausch <nsg@linux.ibm.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Eduardo Habkost <eduardo@habkost.net>,
	qemu-ppc@nongnu.org,
	Daniel Henrique Barboza <danielhb413@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Anton Johansson <anjo@rev.ng>
Subject: [RFC PATCH 1/7] cpus: Restrict CPU_FOREACH_SAFE() to user emulation
Date: Mon,  6 Jan 2025 21:02:52 +0100
Message-ID: <20250106200258.37008-2-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250106200258.37008-1-philmd@linaro.org>
References: <20250106200258.37008-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 include/hw/core/cpu.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/hw/core/cpu.h b/include/hw/core/cpu.h
index c3ca0babcb3..48d90f50a71 100644
--- a/include/hw/core/cpu.h
+++ b/include/hw/core/cpu.h
@@ -594,8 +594,11 @@ extern CPUTailQ cpus_queue;
 #define first_cpu        QTAILQ_FIRST_RCU(&cpus_queue)
 #define CPU_NEXT(cpu)    QTAILQ_NEXT_RCU(cpu, node)
 #define CPU_FOREACH(cpu) QTAILQ_FOREACH_RCU(cpu, &cpus_queue, node)
+
+#if defined(CONFIG_USER_ONLY)
 #define CPU_FOREACH_SAFE(cpu, next_cpu) \
     QTAILQ_FOREACH_SAFE_RCU(cpu, &cpus_queue, node, next_cpu)
+#endif
 
 extern __thread CPUState *current_cpu;
 
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Mon Jan 06 20:03:27 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 20:03:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865905.1277213 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUtJu-0003bp-Su; Mon, 06 Jan 2025 20:03:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865905.1277213; Mon, 06 Jan 2025 20:03:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUtJu-0003bS-Pa; Mon, 06 Jan 2025 20:03:26 +0000
Received: by outflank-mailman (input) for mailman id 865905;
 Mon, 06 Jan 2025 20:03:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=iH3c=T6=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tUtJs-0002e6-Rz
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 20:03:24 +0000
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com
 [2a00:1450:4864:20::32a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 48821c5b-cc69-11ef-99a4-01e77a169b0f;
 Mon, 06 Jan 2025 21:03:23 +0100 (CET)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-436281c8a38so105991955e9.3
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 12:03:23 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4365c08afcbsm586765365e9.21.2025.01.06.12.03.19
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 06 Jan 2025 12:03:20 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 48821c5b-cc69-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1736193803; x=1736798603; 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=FEstRp4e2Qb00qEl2/J4TP29Zm1C+ONgiSLe4ofc5Fw=;
        b=FFy6RLjh7TTri8MMMVzmUwJljPN7BpxZ8zdqOvSf5LoMWpP/tH8oL1Z5lJQHBIgwhM
         XTGAZFf6CyM8Tnd53E4pxXZsGpy+nN6ZTB1SLsi3Z/4fyF+oJvG+3RevFuCHgaO09CMX
         C3JR6qOYy5aueOMC1xywlNWDdtsrBGD8Lqp9xwfSuOftmQHYbXJKzGoZSkFF3yS/7Y2Y
         fGGdM/ddjrrh8h+422wnOrC2ZyX++35SUn644FyKUY+cYYmpZOeonm4uzCQwsUjBAyAh
         2RErF9PpcsQZcv70kpXarc3Ab588DYOEurLbm6P9tS6sATkOX1xXdYFv6xny2h9h0i9G
         DCFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736193803; x=1736798603;
        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=FEstRp4e2Qb00qEl2/J4TP29Zm1C+ONgiSLe4ofc5Fw=;
        b=jGW+IFInjnUL40cFpLrI20PRPbD9D2DYlZnKVkogu5CVWJzjTKjfENl3VXiNGK0MeM
         VBrfd7Fwvh3iPlCTLJsdNCvT6z19Jeq4evnybwbMn8r6flAmXtk+p6SmZFDmkK8PZmPN
         hUnYl2fIDqHiJ9QpOBFIMkET02MijIUI47SyjuoksC/CrbHeavKcTKaBYB4V9Z6Zwt+Y
         dvef4q7ArC11ODfSoZ42HK63i3sPwvIglJIBM+jc+zIPJGevFOCO4AINhlPWusyz0Ulm
         C2X3eaxSnKqsYQem3io9jBa3/KBUrCVl+xIjNzpItQtlgwsmNRkEe/kduoaqGS/zvUSE
         LjMA==
X-Forwarded-Encrypted: i=1; AJvYcCWw1gHom9BynyB4uZBkt1Np8iOWdrifhlbMfaise8EY5GZkaQnrkuOTVE46D6qYqctpAOVufRidGnk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxVv9sRkqK7PoxdGCp9qP4N3fcTqoNRtJRKSdZ06THGxXRL4K2V
	h7zQNbA+FHU0c5/dd9E+f+yoU0zQjygIi5UZjxKsDkKHYjdB7CbdZahtNEGU9NM=
X-Gm-Gg: ASbGncv/u+iS0y5up9jjzLP8+lFZrO2VrJz8AXqdlfAbauxxFlRWD78KKD8xQOrwC3o
	+2EawwYwBHv75nIJr6BB/GrjyWYR+tD1jxyQw6UE/7xN/PBGnXdx3ET+JuVneZNvE0nU//pvhi+
	dRFYq3q0saYB3sXP8JTHwNSRX2TiTlA9x+QSskxF8HwFywRK/TIUMwdtYV4T8100UZOLKgS+Vhc
	q7lLIEyp8Qw/4Eq+ibso4RWJC8Fr3G+7n8HtzYPcvqXXBj/mF7nJ5mX1ZcSY8E58dBtVeAXlKKJ
	xhYW1OuVsp5lwrtPR9i1TyZNBI0MiLg=
X-Google-Smtp-Source: AGHT+IHMet/slV/sVRHbkbSGWWghuJnC++0pCmETj2WxsmX+/fk8W7s4g7KNnMtjYH7DDkOzwohlVQ==
X-Received: by 2002:a05:600c:4f84:b0:434:fec5:4ef5 with SMTP id 5b1f17b1804b1-43668643743mr497181795e9.14.1736193801273;
        Mon, 06 Jan 2025 12:03:21 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: Daniel Henrique Barboza <dbarboza@ventanamicro.com>,
	=?UTF-8?q?Fr=C3=A9d=C3=A9ric=20Barrat?= <fbarrat@linux.ibm.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Ilya Leoshkevich <iii@linux.ibm.com>,
	Cameron Esfahani <dirty@apple.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	kvm@vger.kernel.org,
	Alexander Graf <agraf@csgraf.de>,
	Paul Durrant <paul@xen.org>,
	David Hildenbrand <david@redhat.com>,
	Halil Pasic <pasic@linux.ibm.com>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
	xen-devel@lists.xenproject.org,
	qemu-arm@nongnu.org,
	=?UTF-8?q?C=C3=A9dric=20Le=20Goater?= <clg@redhat.com>,
	Yanan Wang <wangyanan55@huawei.com>,
	Reinoud Zandijk <reinoud@netbsd.org>,
	Peter Maydell <peter.maydell@linaro.org>,
	qemu-s390x@nongnu.org,
	Riku Voipio <riku.voipio@iki.fi>,
	Anthony PERARD <anthony@xenproject.org>,
	Alistair Francis <alistair.francis@wdc.com>,
	Sunil Muthuswamy <sunilmut@microsoft.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	Nicholas Piggin <npiggin@gmail.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Thomas Huth <thuth@redhat.com>,
	Roman Bolshakov <rbolshakov@ddn.com>,
	"Edgar E . Iglesias" <edgar.iglesias@amd.com>,
	Zhao Liu <zhao1.liu@intel.com>,
	Phil Dennis-Jordan <phil@philjordan.eu>,
	David Woodhouse <dwmw2@infradead.org>,
	Harsh Prateek Bora <harshpb@linux.ibm.com>,
	Nina Schoetterl-Glausch <nsg@linux.ibm.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Eduardo Habkost <eduardo@habkost.net>,
	qemu-ppc@nongnu.org,
	Daniel Henrique Barboza <danielhb413@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Anton Johansson <anjo@rev.ng>
Subject: [RFC PATCH 3/7] accel/tcg: Implement tcg_get_cpus_queue()
Date: Mon,  6 Jan 2025 21:02:54 +0100
Message-ID: <20250106200258.37008-4-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250106200258.37008-1-philmd@linaro.org>
References: <20250106200258.37008-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Use a specific vCPUs queue for our unique software accelerator.
Register the AccelOpsClass::get_cpus_queue() handler.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 accel/tcg/tcg-accel-ops.h | 10 ++++++++++
 accel/tcg/tcg-accel-ops.c |  8 ++++++++
 2 files changed, 18 insertions(+)

diff --git a/accel/tcg/tcg-accel-ops.h b/accel/tcg/tcg-accel-ops.h
index 6feeb3f3e9b..7b1d6288742 100644
--- a/accel/tcg/tcg-accel-ops.h
+++ b/accel/tcg/tcg-accel-ops.h
@@ -13,10 +13,20 @@
 #define TCG_ACCEL_OPS_H
 
 #include "system/cpus.h"
+#include "hw/core/cpu.h"
 
 void tcg_cpu_destroy(CPUState *cpu);
 int tcg_cpu_exec(CPUState *cpu);
 void tcg_handle_interrupt(CPUState *cpu, int mask);
 void tcg_cpu_init_cflags(CPUState *cpu, bool parallel);
 
+#ifdef CONFIG_USER_ONLY
+#define tcg_cpus_queue cpus_queue
+#else
+/* Guard with qemu_cpu_list_lock */
+extern CPUTailQ tcg_cpus_queue;
+#endif
+
+#define CPU_FOREACH_TCG(cpu) QTAILQ_FOREACH_RCU(cpu, &tcg_cpus_queue, node)
+
 #endif /* TCG_ACCEL_OPS_H */
diff --git a/accel/tcg/tcg-accel-ops.c b/accel/tcg/tcg-accel-ops.c
index 6e3f1fa92b2..1fb077f7b38 100644
--- a/accel/tcg/tcg-accel-ops.c
+++ b/accel/tcg/tcg-accel-ops.c
@@ -47,6 +47,13 @@
 
 /* common functionality among all TCG variants */
 
+CPUTailQ tcg_cpus_queue = QTAILQ_HEAD_INITIALIZER(tcg_cpus_queue);
+
+static CPUTailQ *tcg_get_cpus_queue(void)
+{
+    return &tcg_cpus_queue;
+}
+
 void tcg_cpu_init_cflags(CPUState *cpu, bool parallel)
 {
     uint32_t cflags;
@@ -199,6 +206,7 @@ static inline void tcg_remove_all_breakpoints(CPUState *cpu)
 
 static void tcg_accel_ops_init(AccelOpsClass *ops)
 {
+    ops->get_cpus_queue = tcg_get_cpus_queue;
     if (qemu_tcg_mttcg_enabled()) {
         ops->create_vcpu_thread = mttcg_start_vcpu_thread;
         ops->kick_vcpu_thread = mttcg_kick_vcpu_thread;
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Mon Jan 06 20:03:30 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 20:03:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865908.1277222 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUtJy-0003z4-2j; Mon, 06 Jan 2025 20:03:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865908.1277222; Mon, 06 Jan 2025 20:03:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUtJx-0003yK-WA; Mon, 06 Jan 2025 20:03:29 +0000
Received: by outflank-mailman (input) for mailman id 865908;
 Mon, 06 Jan 2025 20:03:29 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=iH3c=T6=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tUtJw-0002s4-Va
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 20:03:28 +0000
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com
 [2a00:1450:4864:20::331])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4b78297d-cc69-11ef-a0df-8be0dac302b0;
 Mon, 06 Jan 2025 21:03:28 +0100 (CET)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-43618283d48so106994775e9.1
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 12:03:28 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-43656af6cbbsm610646205e9.3.2025.01.06.12.03.25
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 06 Jan 2025 12:03:26 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 4b78297d-cc69-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1736193808; x=1736798608; 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=CfaBEiOdRjHzzwUS3kiFtedqZxggxEJ4hucj9YdleWw=;
        b=MIXQ1pKaADARQyYOVuz1GkgifJqEgVR4a03UIQuYi3Y88GMHUCxON0rTzcTyTKA7qc
         ekFXUoqq2XzCX79+rxFhq3PJEHqtgU476Vyn+Yx8bi833Oex+GIM0cr6wJXJxOgbuRKh
         VZaYAWO6hdQkGTOm7SUTZXKRH7IvHgUWUefNbvz2jRNJbHGUAuEVUOKhl5Q54H7llzSd
         4AP2FfRsPUGjB/S0pVWGsJLZul/CdWy4HVZawdps6SDnrhP9rmQYOhNFqmxWFHj3jNZh
         hd1njrEuygFdFat46h31mx2i1RCyMQumguSinYTrIz0ZOwcmOYevIJ1MygR7CsLKZP9m
         oEIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736193808; x=1736798608;
        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=CfaBEiOdRjHzzwUS3kiFtedqZxggxEJ4hucj9YdleWw=;
        b=vHzCwfqJ0f6cE8Nqe4+0MP9bnrUTnyBVo32QwxvtKtDKSZnrRi3Wcgd4aYFB61NEx/
         Ct9wYEdhxoL/L1SICDnRQFVazsMhBf7Wb843JOFViRckZYhHi4SjsobGpoBwyqcFunyw
         JBfzaYVISulvx7rAJQpAj2CYCMcrttCNqqlqRSoUBSD39gPxq7FJvEBRvBjLKOLQunyD
         I3/ZGSCAUO5wkc04juBxMIoFO3NKmvDoAnoR8OMTR7fUVcOyhdzy+IhvL1rJVF7pa6tb
         dWbRNjZw4iSvJajMpy4Zn2Ass0h7Tfm8f5atKq9JB0lF2MdUdQ/bRhCvLakc4Kt7i/OK
         RJog==
X-Forwarded-Encrypted: i=1; AJvYcCUXoKfnmuo8udwCkm/b1/gC6QYZG+rVn8xtSxmRYRzH1dHe7/I987li7EJeMu3MJ/OVx9oONobew4M=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyzOfB9xcCWVaaQuVYtJjRXfeEGJ2lFSIMQQDmbfj6q+90D7ucZ
	Epy0TdAc+EhLkq1GDf/7EpiSSl4RQC9Q7o/EEcOGI8QtMBHMzBVgahuedomkSVI=
X-Gm-Gg: ASbGncuVF/s9xaeLkHh70blFvtNIWcOrQTxnQjY6rQRg6ldckAn4zHgx2yUKlvXqtRk
	ngUhcf7kPeAS+1pNCOz3aXp6tXJ8TheKCL3tgOgZGlShGwy9Mp076mZ3LF/x7T5awITEJFZjY9V
	gUcCzoQ6PJX5BdO+vskTgGGCXb/nN/llctSlGIanQ6Hpl98VeH/dhHPvKoSMz5dieR1uES2O+ub
	jfkLS5WJ6VBdVSNraEBi8wQUDruyXNO3b8XQvfviJjYN7+HIcV3iMKXY/pZX7D0LDCW55rWZDc7
	qq9sd7YT/rwylPg0EiVolSshrkxtOyU=
X-Google-Smtp-Source: AGHT+IF3+buEkSMAzhBuTtka5TQV/I34nAgDx1rHh3g80/cDyG64W7K1EH4+aemix37pseTOETajew==
X-Received: by 2002:a05:600c:4f94:b0:434:f871:1b96 with SMTP id 5b1f17b1804b1-43668b7a1dfmr474821135e9.29.1736193807616;
        Mon, 06 Jan 2025 12:03:27 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: Daniel Henrique Barboza <dbarboza@ventanamicro.com>,
	=?UTF-8?q?Fr=C3=A9d=C3=A9ric=20Barrat?= <fbarrat@linux.ibm.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Ilya Leoshkevich <iii@linux.ibm.com>,
	Cameron Esfahani <dirty@apple.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	kvm@vger.kernel.org,
	Alexander Graf <agraf@csgraf.de>,
	Paul Durrant <paul@xen.org>,
	David Hildenbrand <david@redhat.com>,
	Halil Pasic <pasic@linux.ibm.com>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
	xen-devel@lists.xenproject.org,
	qemu-arm@nongnu.org,
	=?UTF-8?q?C=C3=A9dric=20Le=20Goater?= <clg@redhat.com>,
	Yanan Wang <wangyanan55@huawei.com>,
	Reinoud Zandijk <reinoud@netbsd.org>,
	Peter Maydell <peter.maydell@linaro.org>,
	qemu-s390x@nongnu.org,
	Riku Voipio <riku.voipio@iki.fi>,
	Anthony PERARD <anthony@xenproject.org>,
	Alistair Francis <alistair.francis@wdc.com>,
	Sunil Muthuswamy <sunilmut@microsoft.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	Nicholas Piggin <npiggin@gmail.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Thomas Huth <thuth@redhat.com>,
	Roman Bolshakov <rbolshakov@ddn.com>,
	"Edgar E . Iglesias" <edgar.iglesias@amd.com>,
	Zhao Liu <zhao1.liu@intel.com>,
	Phil Dennis-Jordan <phil@philjordan.eu>,
	David Woodhouse <dwmw2@infradead.org>,
	Harsh Prateek Bora <harshpb@linux.ibm.com>,
	Nina Schoetterl-Glausch <nsg@linux.ibm.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Eduardo Habkost <eduardo@habkost.net>,
	qemu-ppc@nongnu.org,
	Daniel Henrique Barboza <danielhb413@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Anton Johansson <anjo@rev.ng>
Subject: [RFC PATCH 4/7] accel/tcg: Use CPU_FOREACH_TCG()
Date: Mon,  6 Jan 2025 21:02:55 +0100
Message-ID: <20250106200258.37008-5-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250106200258.37008-1-philmd@linaro.org>
References: <20250106200258.37008-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Only iterate over TCG vCPUs when running TCG specific code.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 accel/tcg/cputlb.c           |  7 ++++---
 accel/tcg/monitor.c          |  3 ++-
 accel/tcg/tb-maint.c         |  7 ++++---
 accel/tcg/tcg-accel-ops-rr.c | 10 +++++-----
 accel/tcg/tcg-accel-ops.c    |  8 ++++----
 5 files changed, 19 insertions(+), 16 deletions(-)

diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
index b4ccf0cdcb7..06f34df808b 100644
--- a/accel/tcg/cputlb.c
+++ b/accel/tcg/cputlb.c
@@ -48,6 +48,7 @@
 #endif
 #include "tcg/tcg-ldst.h"
 #include "tcg/oversized-guest.h"
+#include "tcg-accel-ops.h"
 
 /* DEBUG defines, enable DEBUG_TLB_LOG to log to the CPU_LOG_MMU target */
 /* #define DEBUG_TLB */
@@ -368,7 +369,7 @@ static void flush_all_helper(CPUState *src, run_on_cpu_func fn,
 {
     CPUState *cpu;
 
-    CPU_FOREACH(cpu) {
+    CPU_FOREACH_TCG(cpu) {
         if (cpu != src) {
             async_run_on_cpu(cpu, fn, d);
         }
@@ -646,7 +647,7 @@ void tlb_flush_page_by_mmuidx_all_cpus_synced(CPUState *src_cpu,
         TLBFlushPageByMMUIdxData *d;
 
         /* Allocate a separate data block for each destination cpu.  */
-        CPU_FOREACH(dst_cpu) {
+        CPU_FOREACH_TCG(dst_cpu) {
             if (dst_cpu != src_cpu) {
                 d = g_new(TLBFlushPageByMMUIdxData, 1);
                 d->addr = addr;
@@ -839,7 +840,7 @@ void tlb_flush_range_by_mmuidx_all_cpus_synced(CPUState *src_cpu,
     d.bits = bits;
 
     /* Allocate a separate data block for each destination cpu.  */
-    CPU_FOREACH(dst_cpu) {
+    CPU_FOREACH_TCG(dst_cpu) {
         if (dst_cpu != src_cpu) {
             p = g_memdup(&d, sizeof(d));
             async_run_on_cpu(dst_cpu, tlb_flush_range_by_mmuidx_async_1,
diff --git a/accel/tcg/monitor.c b/accel/tcg/monitor.c
index ae1dbeb79f8..98bd937ae20 100644
--- a/accel/tcg/monitor.c
+++ b/accel/tcg/monitor.c
@@ -19,6 +19,7 @@
 #include "tcg/tcg.h"
 #include "internal-common.h"
 #include "tb-context.h"
+#include "tcg-accel-ops.h"
 
 
 static void dump_drift_info(GString *buf)
@@ -131,7 +132,7 @@ static void tlb_flush_counts(size_t *pfull, size_t *ppart, size_t *pelide)
     CPUState *cpu;
     size_t full = 0, part = 0, elide = 0;
 
-    CPU_FOREACH(cpu) {
+    CPU_FOREACH_TCG(cpu) {
         full += qatomic_read(&cpu->neg.tlb.c.full_flush_count);
         part += qatomic_read(&cpu->neg.tlb.c.part_flush_count);
         elide += qatomic_read(&cpu->neg.tlb.c.elide_flush_count);
diff --git a/accel/tcg/tb-maint.c b/accel/tcg/tb-maint.c
index 3f1bebf6ab5..8598c59654f 100644
--- a/accel/tcg/tb-maint.c
+++ b/accel/tcg/tb-maint.c
@@ -36,6 +36,7 @@
 #ifdef CONFIG_USER_ONLY
 #include "user/page-protection.h"
 #endif
+#include "tcg-accel-ops.h"
 
 
 /* List iterators for lists of tagged pointers in TranslationBlock. */
@@ -771,7 +772,7 @@ static void do_tb_flush(CPUState *cpu, run_on_cpu_data tb_flush_count)
     }
     did_flush = true;
 
-    CPU_FOREACH(cpu) {
+    CPU_FOREACH_TCG(cpu) {
         tcg_flush_jmp_cache(cpu);
     }
 
@@ -885,13 +886,13 @@ static void tb_jmp_cache_inval_tb(TranslationBlock *tb)
 
     if (tb_cflags(tb) & CF_PCREL) {
         /* A TB may be at any virtual address */
-        CPU_FOREACH(cpu) {
+        CPU_FOREACH_TCG(cpu) {
             tcg_flush_jmp_cache(cpu);
         }
     } else {
         uint32_t h = tb_jmp_cache_hash_func(tb->pc);
 
-        CPU_FOREACH(cpu) {
+        CPU_FOREACH_TCG(cpu) {
             CPUJumpCache *jc = cpu->tb_jmp_cache;
 
             if (qatomic_read(&jc->array[h].tb) == tb) {
diff --git a/accel/tcg/tcg-accel-ops-rr.c b/accel/tcg/tcg-accel-ops-rr.c
index 028b385af9a..e5ce285efb9 100644
--- a/accel/tcg/tcg-accel-ops-rr.c
+++ b/accel/tcg/tcg-accel-ops-rr.c
@@ -42,7 +42,7 @@ void rr_kick_vcpu_thread(CPUState *unused)
 {
     CPUState *cpu;
 
-    CPU_FOREACH(cpu) {
+    CPU_FOREACH_TCG(cpu) {
         cpu_exit(cpu);
     };
 }
@@ -116,7 +116,7 @@ static void rr_wait_io_event(void)
 
     rr_start_kick_timer();
 
-    CPU_FOREACH(cpu) {
+    CPU_FOREACH_TCG(cpu) {
         qemu_wait_io_event_common(cpu);
     }
 }
@@ -129,7 +129,7 @@ static void rr_deal_with_unplugged_cpus(void)
 {
     CPUState *cpu;
 
-    CPU_FOREACH(cpu) {
+    CPU_FOREACH_TCG(cpu) {
         if (cpu->unplug && !cpu_can_run(cpu)) {
             tcg_cpu_destroy(cpu);
             break;
@@ -160,7 +160,7 @@ static int rr_cpu_count(void)
 
     if (cpu_list_generation_id_get() != last_gen_id) {
         cpu_count = 0;
-        CPU_FOREACH(cpu) {
+        CPU_FOREACH_TCG(cpu) {
             ++cpu_count;
         }
         last_gen_id = cpu_list_generation_id_get();
@@ -201,7 +201,7 @@ static void *rr_cpu_thread_fn(void *arg)
         qemu_cond_wait_bql(first_cpu->halt_cond);
 
         /* process any pending work */
-        CPU_FOREACH(cpu) {
+        CPU_FOREACH_TCG(cpu) {
             current_cpu = cpu;
             qemu_wait_io_event_common(cpu);
         }
diff --git a/accel/tcg/tcg-accel-ops.c b/accel/tcg/tcg-accel-ops.c
index 1fb077f7b38..371bbaa0307 100644
--- a/accel/tcg/tcg-accel-ops.c
+++ b/accel/tcg/tcg-accel-ops.c
@@ -144,7 +144,7 @@ static int tcg_insert_breakpoint(CPUState *cs, int type, vaddr addr, vaddr len)
     switch (type) {
     case GDB_BREAKPOINT_SW:
     case GDB_BREAKPOINT_HW:
-        CPU_FOREACH(cpu) {
+        CPU_FOREACH_TCG(cpu) {
             err = cpu_breakpoint_insert(cpu, addr, BP_GDB, NULL);
             if (err) {
                 break;
@@ -154,7 +154,7 @@ static int tcg_insert_breakpoint(CPUState *cs, int type, vaddr addr, vaddr len)
     case GDB_WATCHPOINT_WRITE:
     case GDB_WATCHPOINT_READ:
     case GDB_WATCHPOINT_ACCESS:
-        CPU_FOREACH(cpu) {
+        CPU_FOREACH_TCG(cpu) {
             err = cpu_watchpoint_insert(cpu, addr, len,
                                         xlat_gdb_type(cpu, type), NULL);
             if (err) {
@@ -175,7 +175,7 @@ static int tcg_remove_breakpoint(CPUState *cs, int type, vaddr addr, vaddr len)
     switch (type) {
     case GDB_BREAKPOINT_SW:
     case GDB_BREAKPOINT_HW:
-        CPU_FOREACH(cpu) {
+        CPU_FOREACH_TCG(cpu) {
             err = cpu_breakpoint_remove(cpu, addr, BP_GDB);
             if (err) {
                 break;
@@ -185,7 +185,7 @@ static int tcg_remove_breakpoint(CPUState *cs, int type, vaddr addr, vaddr len)
     case GDB_WATCHPOINT_WRITE:
     case GDB_WATCHPOINT_READ:
     case GDB_WATCHPOINT_ACCESS:
-        CPU_FOREACH(cpu) {
+        CPU_FOREACH_TCG(cpu) {
             err = cpu_watchpoint_remove(cpu, addr, len,
                                         xlat_gdb_type(cpu, type));
             if (err) {
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Mon Jan 06 20:03:36 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 20:03:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865915.1277233 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUtK4-0004XR-EV; Mon, 06 Jan 2025 20:03:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865915.1277233; Mon, 06 Jan 2025 20:03:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUtK4-0004XF-Am; Mon, 06 Jan 2025 20:03:36 +0000
Received: by outflank-mailman (input) for mailman id 865915;
 Mon, 06 Jan 2025 20:03:35 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=iH3c=T6=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tUtK3-0002e6-Dx
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 20:03:35 +0000
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com
 [2a00:1450:4864:20::42e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4eca07d0-cc69-11ef-99a4-01e77a169b0f;
 Mon, 06 Jan 2025 21:03:33 +0100 (CET)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-385d7f19f20so6498486f8f.1
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 12:03:33 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-43656af6d02sm618987535e9.1.2025.01.06.12.03.31
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 06 Jan 2025 12:03:32 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 4eca07d0-cc69-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1736193813; x=1736798613; 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=zxJ3+xb03FIgQb6HyhO+0vTNSYN1GRLEa0EnbI36swA=;
        b=CEkkqN66dB2ARecescr5cSyhsvtPCXnqGseuH9gUHCNxoHbO8Fo9UOieLzjmzmkG7r
         dFpIr8+Yuw2oXbvcBn81B+w1AMuCnQMyyBrRksgeY8TosOAi84EAm3akrOK9EpVjChWK
         UwuXfHeabkmgKPAE8Qe8iwc475XV8AwWFTNRIOc5oGclUYSMRuWgcePqsEE1ZJkRrFCZ
         2mEHSYLn4c3bRp/OmNSXVfFxP8d3YJ0AErJYlgWt1FTtUD/hvS3BdBin5euRWiGHfZo7
         ceL30qV8paeSYcdrM4Ov+HjMqa+jY6jx6FKm/orio6aAO5g8VY6hIf4n/R+yD3OdWrGI
         Vlmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736193813; x=1736798613;
        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=zxJ3+xb03FIgQb6HyhO+0vTNSYN1GRLEa0EnbI36swA=;
        b=HcbUOv61ZOEiJO6MOYPraxbyjGLIc+GNvBoWmNLfjQ0KmNkZVt4iuKi6RwaF9hv1Yn
         03oa0KsE6G1IWiv0crR/caDxcpTbYtGzh1vUp1s/z00h22LvETWtM+3Kzn9bF0yBwIuF
         VrIFOJq+TR9fAzh6nIy5TnMTxx6EBYNFLTJCmfSjFMMCZnjpS4olitcNfNGpfc5MmO7m
         hMRWhE767MOZtgNzVaZmJUgNci6Qz52HNtx35bPOe6tWpFcjMyb3UWjthFsJYGxinNaJ
         Vl6wPFEl0y51Nxavwm3Yh1nweoAPPLn/RK7PwMlx2tn0AiAf+6G0aCaF8MgmOueBBq+i
         IADg==
X-Forwarded-Encrypted: i=1; AJvYcCWzqYwUEx+pxHgW0S6UZI+wyBUUQFneOhBgjwUpWPB950sNzlgvU9JLNyGnHhcJO3mccwz+Djb0VvY=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw1tuz0FXB1XT3e8tpbl/sBV9xFM4GbR0vqPDNrL3sptNTu9Sae
	nBIgsNuqHBLenk+I4ZOp8fCHgXyFIMI6WuKARsdXTyJfHiNK/MdDka/lcyzxUWM=
X-Gm-Gg: ASbGnctpNLGMQDvS8w/R1aMJP+qYNMF1dM+du4OkNLX2Bhgf/R9p1DW9w8ka5tSccaJ
	zWFfZyICX346ZRKHBY2PhYoiw2GezT/rKOURK6o+MXlf6wDVdfsDya2z3Ub1q04DFFbC1wLARLP
	yzQrv7TgbRgV+jW9/y0mfe3vOrkJrK9mnOUT03+iq6OQ7a8aBnYdUBAT5MSeMwMk8n2Nq14juSD
	mmmE9OIwBJfmoLxoQ4VINwnCxtxi6T27b6BF5Xgc9iVK3jq1YrOI536rSyJH4tsayisw7/oVpb3
	NA8eVQ3yqiDo/e9kmTkvqID4toh9WBY=
X-Google-Smtp-Source: AGHT+IGoS13s7EdoAdq3NUY+QaACk4mt67qvYvBPAyuPr3+V1znGvuXeRZNJwXBUnZIrDNw4J4+93w==
X-Received: by 2002:adf:a3d9:0:b0:38a:39ad:3e31 with SMTP id ffacd0b85a97d-38a39ad4128mr24752061f8f.57.1736193813254;
        Mon, 06 Jan 2025 12:03:33 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: Daniel Henrique Barboza <dbarboza@ventanamicro.com>,
	=?UTF-8?q?Fr=C3=A9d=C3=A9ric=20Barrat?= <fbarrat@linux.ibm.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Ilya Leoshkevich <iii@linux.ibm.com>,
	Cameron Esfahani <dirty@apple.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	kvm@vger.kernel.org,
	Alexander Graf <agraf@csgraf.de>,
	Paul Durrant <paul@xen.org>,
	David Hildenbrand <david@redhat.com>,
	Halil Pasic <pasic@linux.ibm.com>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
	xen-devel@lists.xenproject.org,
	qemu-arm@nongnu.org,
	=?UTF-8?q?C=C3=A9dric=20Le=20Goater?= <clg@redhat.com>,
	Yanan Wang <wangyanan55@huawei.com>,
	Reinoud Zandijk <reinoud@netbsd.org>,
	Peter Maydell <peter.maydell@linaro.org>,
	qemu-s390x@nongnu.org,
	Riku Voipio <riku.voipio@iki.fi>,
	Anthony PERARD <anthony@xenproject.org>,
	Alistair Francis <alistair.francis@wdc.com>,
	Sunil Muthuswamy <sunilmut@microsoft.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	Nicholas Piggin <npiggin@gmail.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Thomas Huth <thuth@redhat.com>,
	Roman Bolshakov <rbolshakov@ddn.com>,
	"Edgar E . Iglesias" <edgar.iglesias@amd.com>,
	Zhao Liu <zhao1.liu@intel.com>,
	Phil Dennis-Jordan <phil@philjordan.eu>,
	David Woodhouse <dwmw2@infradead.org>,
	Harsh Prateek Bora <harshpb@linux.ibm.com>,
	Nina Schoetterl-Glausch <nsg@linux.ibm.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Eduardo Habkost <eduardo@habkost.net>,
	qemu-ppc@nongnu.org,
	Daniel Henrique Barboza <danielhb413@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Anton Johansson <anjo@rev.ng>
Subject: [RFC PATCH 5/7] accel/hw: Implement hw_accel_get_cpus_queue()
Date: Mon,  6 Jan 2025 21:02:56 +0100
Message-ID: <20250106200258.37008-6-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250106200258.37008-1-philmd@linaro.org>
References: <20250106200258.37008-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

We can only run a single hardware accelerator at a time,
so add a generic hw_accel_get_cpus_queue() helper in
accel-system.c, a file common to all HW accelerators.

Register AccelOpsClass::get_cpus_queue() for each HW
accelerator. Add a generic CPU_FOREACH_HWACCEL() macro.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 include/system/hw_accel.h         | 9 +++++++++
 accel/accel-system.c              | 8 ++++++++
 accel/kvm/kvm-accel-ops.c         | 1 +
 accel/xen/xen-all.c               | 1 +
 target/i386/nvmm/nvmm-accel-ops.c | 1 +
 target/i386/whpx/whpx-accel-ops.c | 1 +
 6 files changed, 21 insertions(+)

diff --git a/include/system/hw_accel.h b/include/system/hw_accel.h
index 380e9e640b6..12664cac6f9 100644
--- a/include/system/hw_accel.h
+++ b/include/system/hw_accel.h
@@ -2,6 +2,7 @@
  * QEMU Hardware accelerators support
  *
  * Copyright 2016 Google, Inc.
+ * Copyright 2025 Linaro Ltd.
  *
  * This work is licensed under the terms of the GNU GPL, version 2 or later.
  * See the COPYING file in the top-level directory.
@@ -17,6 +18,14 @@
 #include "system/whpx.h"
 #include "system/nvmm.h"
 
+/* Guard with qemu_cpu_list_lock */
+extern CPUTailQ hw_accel_cpus_queue;
+
+#define CPU_FOREACH_HWACCEL(cpu) \
+            QTAILQ_FOREACH_RCU(cpu, &hw_accel_cpus_queue, node)
+
+CPUTailQ *hw_accel_get_cpus_queue(void);
+
 void cpu_synchronize_state(CPUState *cpu);
 void cpu_synchronize_post_reset(CPUState *cpu);
 void cpu_synchronize_post_init(CPUState *cpu);
diff --git a/accel/accel-system.c b/accel/accel-system.c
index a7596aef59d..60877ea7a28 100644
--- a/accel/accel-system.c
+++ b/accel/accel-system.c
@@ -27,9 +27,17 @@
 #include "qemu/accel.h"
 #include "hw/boards.h"
 #include "system/cpus.h"
+#include "system/hw_accel.h"
 #include "qemu/error-report.h"
 #include "accel-system.h"
 
+CPUTailQ hw_accel_cpus_queue = QTAILQ_HEAD_INITIALIZER(hw_accel_cpus_queue);
+
+CPUTailQ *hw_accel_get_cpus_queue(void)
+{
+    return &hw_accel_cpus_queue;
+}
+
 int accel_init_machine(AccelState *accel, MachineState *ms)
 {
     AccelClass *acc = ACCEL_GET_CLASS(accel);
diff --git a/accel/kvm/kvm-accel-ops.c b/accel/kvm/kvm-accel-ops.c
index a81e8f3b03b..5f4001860d5 100644
--- a/accel/kvm/kvm-accel-ops.c
+++ b/accel/kvm/kvm-accel-ops.c
@@ -93,6 +93,7 @@ static void kvm_accel_ops_class_init(ObjectClass *oc, void *data)
 {
     AccelOpsClass *ops = ACCEL_OPS_CLASS(oc);
 
+    ops->get_cpus_queue = hw_accel_get_cpus_queue;
     ops->create_vcpu_thread = kvm_start_vcpu_thread;
     ops->cpu_thread_is_idle = kvm_vcpu_thread_is_idle;
     ops->cpus_are_resettable = kvm_cpus_are_resettable;
diff --git a/accel/xen/xen-all.c b/accel/xen/xen-all.c
index 852e9fbe5fe..ac5ed2dfb80 100644
--- a/accel/xen/xen-all.c
+++ b/accel/xen/xen-all.c
@@ -150,6 +150,7 @@ static void xen_accel_ops_class_init(ObjectClass *oc, void *data)
 {
     AccelOpsClass *ops = ACCEL_OPS_CLASS(oc);
 
+    ops->get_cpus_queue = hw_accel_get_cpus_queue;
     ops->create_vcpu_thread = dummy_start_vcpu_thread;
 }
 
diff --git a/target/i386/nvmm/nvmm-accel-ops.c b/target/i386/nvmm/nvmm-accel-ops.c
index e7b56662fee..bb407c68e14 100644
--- a/target/i386/nvmm/nvmm-accel-ops.c
+++ b/target/i386/nvmm/nvmm-accel-ops.c
@@ -84,6 +84,7 @@ static void nvmm_accel_ops_class_init(ObjectClass *oc, void *data)
 {
     AccelOpsClass *ops = ACCEL_OPS_CLASS(oc);
 
+    ops->get_cpus_queue = hw_accel_get_cpus_queue;
     ops->create_vcpu_thread = nvmm_start_vcpu_thread;
     ops->kick_vcpu_thread = nvmm_kick_vcpu_thread;
 
diff --git a/target/i386/whpx/whpx-accel-ops.c b/target/i386/whpx/whpx-accel-ops.c
index ab2e014c9ea..191214ca81d 100644
--- a/target/i386/whpx/whpx-accel-ops.c
+++ b/target/i386/whpx/whpx-accel-ops.c
@@ -86,6 +86,7 @@ static void whpx_accel_ops_class_init(ObjectClass *oc, void *data)
 {
     AccelOpsClass *ops = ACCEL_OPS_CLASS(oc);
 
+    ops->get_cpus_queue = hw_accel_get_cpus_queue;
     ops->create_vcpu_thread = whpx_start_vcpu_thread;
     ops->kick_vcpu_thread = whpx_kick_vcpu_thread;
     ops->cpu_thread_is_idle = whpx_vcpu_thread_is_idle;
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Mon Jan 06 20:03:42 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 20:03:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865922.1277242 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUtKA-00052o-Le; Mon, 06 Jan 2025 20:03:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865922.1277242; Mon, 06 Jan 2025 20:03:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUtKA-00052h-I9; Mon, 06 Jan 2025 20:03:42 +0000
Received: by outflank-mailman (input) for mailman id 865922;
 Mon, 06 Jan 2025 20:03:41 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=iH3c=T6=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tUtK9-0002e6-26
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 20:03:41 +0000
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com
 [2a00:1450:4864:20::32e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 52257aff-cc69-11ef-99a4-01e77a169b0f;
 Mon, 06 Jan 2025 21:03:39 +0100 (CET)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-43634b570c1so106121915e9.0
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 12:03:39 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4367086e40esm543882975e9.30.2025.01.06.12.03.37
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 06 Jan 2025 12:03:38 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 52257aff-cc69-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1736193819; x=1736798619; 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=sQToL39oc1IIGRZ4x4DJpAbte9qYHUOsWxQUB+w3STI=;
        b=HnqsJLY5AhpCusyHICdrnD9l2+FE6W4BU5T/X9zrZ7qLjjHfQ9f46rVUrUQjVW63pm
         G0Wn4dFFWuDuIfzGJ3ZfqOK3kRUHkxUEWdFNxMXLbsUL2f+XGgvGChMXucFLyagnzQD9
         PfTV5dYPLE9a2wUMN31ttgZwCB+tb7Qzwyxx066ceG+1/ec/c/o+3C5zPwaxP4lWirlQ
         JJnE3OvN9Vj1/JWbIHr5r/VxSc8b01tGOh+Um/LBjLOBxJ/W2xG6oIfQr2lJpZn+sL9N
         RR/CY2wD4mm+YsWe0ybROGt5HiQJnS7qkCqgIcvAZcqVCrdvyjYPPKhCVcMQjm94SOlA
         ZKLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736193819; x=1736798619;
        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=sQToL39oc1IIGRZ4x4DJpAbte9qYHUOsWxQUB+w3STI=;
        b=nKkm3VF7Mmc+4hCQvVpZpCX2kIB0u27lQEo+5C6vDiA8M11o/kWn2fviZyricED/6A
         3ehbJhY7IWC93xZNFpWYnjNRcG4mNdZctrTavO4aue6YGGoTaWVvxU7ySJ+hBW49BPz/
         u4N9Trzq2cBvVuvaVDv8u2oZe1JYNWRwW9iDUCiHkaR84Qu/qkUqP5ZZpCBKtFB057UJ
         pGLUIQZnNOuR6KoXhMlDI5wuCteKagZU1xNHHjl6liWK5YwgcbLvByLm13m7VR4tvknW
         Qj8Ey6Ih/NIXPm1XouECU9LYBy7vFaFH9xn5QFo4O2eZtC+U/d0x17G0M1FPrwL3jk0o
         NJrQ==
X-Forwarded-Encrypted: i=1; AJvYcCXWSxqcku9QthEC58td0ig9rH8803QMxBlISvRqWg+XOirBqeuPejB1WIf/iKvVWI67GYIexU3HGHQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzk0R0fBiUZrvt0fp286EKr+uqjDx/mgh/1n9NMy3yOaiYf1cNv
	MB+mEEt1YRGlg4HSMctEWmv1gOIpKJia6MzFkjWxNri8EYA54P/M5N8iJ8S5auU=
X-Gm-Gg: ASbGncsnJwKZZP2Q+L/OpsXqXwEtJK9y8VHbWCu9fWGxCtnzlcNSVUOO9IOYxu45pBs
	HPsTPh2rmxpdhgD5yGiDP4A6KzjeDK02WwiGHgiD8b5PGLrPzHVx8XrWmwaa/gURae7kOiGqHxl
	gDIsqaNnQPWqmSkhihkedl53QIY/9ChHEiREYiJRFmfrpVH9TC+GZyp8DMycuIRwfk6YohCZVPH
	x2RuFNydphYUBkkUazj4pX9xLAP1TDLn1nIbRGjZKkOK6YwzL0gsrYMy3nKFULyabruNbT5K1v7
	MEukR9hqNJ9QKqu7ot1sXkcu80qsK4w=
X-Google-Smtp-Source: AGHT+IFXiDdVgmnTH4sfktC8/xKNinP6K1bHXh0LE5bFlepNSrMiJFLvtHvHs4neclwfX3Zl5Vm/Iw==
X-Received: by 2002:a05:600c:5112:b0:434:faa9:5266 with SMTP id 5b1f17b1804b1-436c2b5b491mr121041605e9.13.1736193818909;
        Mon, 06 Jan 2025 12:03:38 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: Daniel Henrique Barboza <dbarboza@ventanamicro.com>,
	=?UTF-8?q?Fr=C3=A9d=C3=A9ric=20Barrat?= <fbarrat@linux.ibm.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Ilya Leoshkevich <iii@linux.ibm.com>,
	Cameron Esfahani <dirty@apple.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	kvm@vger.kernel.org,
	Alexander Graf <agraf@csgraf.de>,
	Paul Durrant <paul@xen.org>,
	David Hildenbrand <david@redhat.com>,
	Halil Pasic <pasic@linux.ibm.com>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
	xen-devel@lists.xenproject.org,
	qemu-arm@nongnu.org,
	=?UTF-8?q?C=C3=A9dric=20Le=20Goater?= <clg@redhat.com>,
	Yanan Wang <wangyanan55@huawei.com>,
	Reinoud Zandijk <reinoud@netbsd.org>,
	Peter Maydell <peter.maydell@linaro.org>,
	qemu-s390x@nongnu.org,
	Riku Voipio <riku.voipio@iki.fi>,
	Anthony PERARD <anthony@xenproject.org>,
	Alistair Francis <alistair.francis@wdc.com>,
	Sunil Muthuswamy <sunilmut@microsoft.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	Nicholas Piggin <npiggin@gmail.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Thomas Huth <thuth@redhat.com>,
	Roman Bolshakov <rbolshakov@ddn.com>,
	"Edgar E . Iglesias" <edgar.iglesias@amd.com>,
	Zhao Liu <zhao1.liu@intel.com>,
	Phil Dennis-Jordan <phil@philjordan.eu>,
	David Woodhouse <dwmw2@infradead.org>,
	Harsh Prateek Bora <harshpb@linux.ibm.com>,
	Nina Schoetterl-Glausch <nsg@linux.ibm.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Eduardo Habkost <eduardo@habkost.net>,
	qemu-ppc@nongnu.org,
	Daniel Henrique Barboza <danielhb413@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Anton Johansson <anjo@rev.ng>
Subject: [RFC PATCH 6/7] accel/hvf: Use CPU_FOREACH_HVF()
Date: Mon,  6 Jan 2025 21:02:57 +0100
Message-ID: <20250106200258.37008-7-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250106200258.37008-1-philmd@linaro.org>
References: <20250106200258.37008-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Only iterate over HVF vCPUs when running HVF specific code.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 include/system/hvf_int.h  | 4 ++++
 accel/hvf/hvf-accel-ops.c | 9 +++++----
 target/arm/hvf/hvf.c      | 4 ++--
 3 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/include/system/hvf_int.h b/include/system/hvf_int.h
index 42ae18433f0..3cf64faabd1 100644
--- a/include/system/hvf_int.h
+++ b/include/system/hvf_int.h
@@ -11,6 +11,8 @@
 #ifndef HVF_INT_H
 #define HVF_INT_H
 
+#include "system/hw_accel.h"
+
 #ifdef __aarch64__
 #include <Hypervisor/Hypervisor.h>
 typedef hv_vcpu_t hvf_vcpuid;
@@ -74,4 +76,6 @@ int hvf_put_registers(CPUState *);
 int hvf_get_registers(CPUState *);
 void hvf_kick_vcpu_thread(CPUState *cpu);
 
+#define CPU_FOREACH_HVF(cpu) CPU_FOREACH_HWACCEL(cpu)
+
 #endif
diff --git a/accel/hvf/hvf-accel-ops.c b/accel/hvf/hvf-accel-ops.c
index 945ba720513..bbbe2f8d45b 100644
--- a/accel/hvf/hvf-accel-ops.c
+++ b/accel/hvf/hvf-accel-ops.c
@@ -504,7 +504,7 @@ static int hvf_insert_breakpoint(CPUState *cpu, int type, vaddr addr, vaddr len)
         }
     }
 
-    CPU_FOREACH(cpu) {
+    CPU_FOREACH_HVF(cpu) {
         err = hvf_update_guest_debug(cpu);
         if (err) {
             return err;
@@ -543,7 +543,7 @@ static int hvf_remove_breakpoint(CPUState *cpu, int type, vaddr addr, vaddr len)
         }
     }
 
-    CPU_FOREACH(cpu) {
+    CPU_FOREACH_HVF(cpu) {
         err = hvf_update_guest_debug(cpu);
         if (err) {
             return err;
@@ -560,7 +560,7 @@ static void hvf_remove_all_breakpoints(CPUState *cpu)
     QTAILQ_FOREACH_SAFE(bp, &hvf_state->hvf_sw_breakpoints, entry, next) {
         if (hvf_arch_remove_sw_breakpoint(cpu, bp) != 0) {
             /* Try harder to find a CPU that currently sees the breakpoint. */
-            CPU_FOREACH(tmpcpu)
+            CPU_FOREACH_HVF(tmpcpu)
             {
                 if (hvf_arch_remove_sw_breakpoint(tmpcpu, bp) == 0) {
                     break;
@@ -572,7 +572,7 @@ static void hvf_remove_all_breakpoints(CPUState *cpu)
     }
     hvf_arch_remove_all_hw_breakpoints();
 
-    CPU_FOREACH(cpu) {
+    CPU_FOREACH_HVF(cpu) {
         hvf_update_guest_debug(cpu);
     }
 }
@@ -581,6 +581,7 @@ static void hvf_accel_ops_class_init(ObjectClass *oc, void *data)
 {
     AccelOpsClass *ops = ACCEL_OPS_CLASS(oc);
 
+    ops->get_cpus_queue = hw_accel_get_cpus_queue;
     ops->create_vcpu_thread = hvf_start_vcpu_thread;
     ops->kick_vcpu_thread = hvf_kick_vcpu_thread;
 
diff --git a/target/arm/hvf/hvf.c b/target/arm/hvf/hvf.c
index 0afd96018e0..13400ff0d5f 100644
--- a/target/arm/hvf/hvf.c
+++ b/target/arm/hvf/hvf.c
@@ -2269,10 +2269,10 @@ static void hvf_arch_set_traps(void)
 
     /* Check whether guest debugging is enabled for at least one vCPU; if it
      * is, enable exiting the guest on all vCPUs */
-    CPU_FOREACH(cpu) {
+    CPU_FOREACH_HVF(cpu) {
         should_enable_traps |= cpu->accel->guest_debug_enabled;
     }
-    CPU_FOREACH(cpu) {
+    CPU_FOREACH_HVF(cpu) {
         /* Set whether debug exceptions exit the guest */
         r = hv_vcpu_set_trap_debug_exceptions(cpu->accel->fd,
                                               should_enable_traps);
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Mon Jan 06 20:11:03 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 20:11:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865947.1277253 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUtRD-0007YW-DO; Mon, 06 Jan 2025 20:10:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865947.1277253; Mon, 06 Jan 2025 20:10:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUtRD-0007YP-8n; Mon, 06 Jan 2025 20:10:59 +0000
Received: by outflank-mailman (input) for mailman id 865947;
 Mon, 06 Jan 2025 20:10:57 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=iH3c=T6=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tUtKG-0002s4-U7
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 20:03: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 5754ab31-cc69-11ef-a0df-8be0dac302b0;
 Mon, 06 Jan 2025 21:03:48 +0100 (CET)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-3862ca8e0bbso11253931f8f.0
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 12:03:48 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436723cb159sm525092965e9.16.2025.01.06.12.03.42
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 06 Jan 2025 12:03:44 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5754ab31-cc69-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1736193828; x=1736798628; 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=iQTkKmwN0la/zq4/AmggU7ruV8aWhlAE2m8oe1Or7Yc=;
        b=wiwbw6tW/XNvHfXzrP4VUxaUUil+H3o1bKJRh5hX2tZLvnsnK05TCmPNCbercXi49R
         K1t0lRzD2P8qf96f9xx1sPVnyeSZGv4yXt/Vbdfk5PoZZqIEi0Fqpws5QiLiK5wANAyw
         YE9xrk5w+o8Z+J3mKxAktE6HB3dIdcYb+nJZeVi1jicxkvkM9WAvIg6Yvma9J/UQ7xhd
         BZOTdCz1xe8txVo6/RUNzDPFm4oijSgdNJUiVvPBr/DBOE4MV8+NBFEEHktYed259Ug4
         cl3ubXZu0BzRJ6v45bZ8aU2e2lG0Forc7jwb9tWS/meLkXzMDUWT1Dq6D8187w/bjx1/
         EINw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736193828; x=1736798628;
        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=iQTkKmwN0la/zq4/AmggU7ruV8aWhlAE2m8oe1Or7Yc=;
        b=tIvWUcEyQ2OYQ0v57AgQhsWqPlS6JinMvQqKW/UI/FKTBesti0Kiz1/KeiVaNLgkeJ
         OyBKo2ifLaLkG2XfWfb4exfmebgFy+TvhWwRDbf5j06RdAaw+X7SNwt2yYrVUR7d/yRS
         9PUrDcaKqvsr7H0dMKiFRq2E9P4mg+ZGDkZAmUtxrHILR8kaIYxIl9ylrn7dyfZtV3RI
         39bnvmFWN/fwNj4I2pz6CJ04YaP7s0fYFUAvBF48tqebTcPUprvzmH33/24CWwfgiS09
         8pFyR1W/wKl0yR9eaM8U15RCILzLSj/WyexMo7fLmeEy2sCd5zTxOYoNI+hhuaiLfdK/
         gg+Q==
X-Forwarded-Encrypted: i=1; AJvYcCXYMgicTKWlLLcYZ+9lAfOhfRf0Q8vgA3g8qEbTsUPwqqyiXHV30HhVWZQSszGXk7BIVSidjNww22A=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzoaj4j9aFlQR1XYhISzC5hToL1zaG2pJI6uhcc/jWATFsVZouS
	6Pt1oyihxhFdYsHGvNpoG2dNURpGW4gjpu0N9jw8odoQB5fRRuuAbh8eODUm1FA=
X-Gm-Gg: ASbGncsfAUgXEsPCWLZvQS6YdgVeo/idfPymh3DZ760fPacCgs3xVPCa0C2B1Q4IBJY
	YPrn1vBygnjuli3QqX+psXGEGFSzsy72l01FQidAngCRAw9E1CP3dMP/0JKhw+LIVBVjmWWNryg
	JDQKPPOmePElRCCt15kh4vx5guKgm6ia5JT+2fREJJ4xQhBLuGmIVWuAbi2h7uuBIbT8e1tH8CP
	UtrVaipelATGaaB9r76p6Yl2WdCrjzA4TRPbWaf1YUaeB+nVrCeowce7j+FMmNXxKwU9Zpwx4gJ
	YMDAmlL2CTDfJ3z9Q/6v7dqbEwpN0P4=
X-Google-Smtp-Source: AGHT+IHDE/cbM5Uz3mC6dPWI+SKnpmJxnVL7+eC7vPChMfg/0MfF0CSgk918tvS7UmQNdLQuffdZDw==
X-Received: by 2002:a5d:6c64:0:b0:385:f6f4:f8e with SMTP id ffacd0b85a97d-38a223ff1cemr40988273f8f.50.1736193825978;
        Mon, 06 Jan 2025 12:03:45 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: Daniel Henrique Barboza <dbarboza@ventanamicro.com>,
	=?UTF-8?q?Fr=C3=A9d=C3=A9ric=20Barrat?= <fbarrat@linux.ibm.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Ilya Leoshkevich <iii@linux.ibm.com>,
	Cameron Esfahani <dirty@apple.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	kvm@vger.kernel.org,
	Alexander Graf <agraf@csgraf.de>,
	Paul Durrant <paul@xen.org>,
	David Hildenbrand <david@redhat.com>,
	Halil Pasic <pasic@linux.ibm.com>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
	xen-devel@lists.xenproject.org,
	qemu-arm@nongnu.org,
	=?UTF-8?q?C=C3=A9dric=20Le=20Goater?= <clg@redhat.com>,
	Yanan Wang <wangyanan55@huawei.com>,
	Reinoud Zandijk <reinoud@netbsd.org>,
	Peter Maydell <peter.maydell@linaro.org>,
	qemu-s390x@nongnu.org,
	Riku Voipio <riku.voipio@iki.fi>,
	Anthony PERARD <anthony@xenproject.org>,
	Alistair Francis <alistair.francis@wdc.com>,
	Sunil Muthuswamy <sunilmut@microsoft.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	Nicholas Piggin <npiggin@gmail.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Thomas Huth <thuth@redhat.com>,
	Roman Bolshakov <rbolshakov@ddn.com>,
	"Edgar E . Iglesias" <edgar.iglesias@amd.com>,
	Zhao Liu <zhao1.liu@intel.com>,
	Phil Dennis-Jordan <phil@philjordan.eu>,
	David Woodhouse <dwmw2@infradead.org>,
	Harsh Prateek Bora <harshpb@linux.ibm.com>,
	Nina Schoetterl-Glausch <nsg@linux.ibm.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Eduardo Habkost <eduardo@habkost.net>,
	qemu-ppc@nongnu.org,
	Daniel Henrique Barboza <danielhb413@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Anton Johansson <anjo@rev.ng>
Subject: [RFC PATCH 7/7] accel/kvm: Use CPU_FOREACH_KVM()
Date: Mon,  6 Jan 2025 21:02:58 +0100
Message-ID: <20250106200258.37008-8-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250106200258.37008-1-philmd@linaro.org>
References: <20250106200258.37008-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Only iterate over KVM vCPUs when running KVM specific code.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 include/system/kvm_int.h         |  3 +++
 accel/kvm/kvm-all.c              | 14 +++++++-------
 hw/i386/kvm/clock.c              |  3 ++-
 hw/intc/spapr_xive_kvm.c         |  5 +++--
 hw/intc/xics_kvm.c               |  5 +++--
 target/i386/kvm/kvm.c            |  4 ++--
 target/i386/kvm/xen-emu.c        |  2 +-
 target/s390x/kvm/kvm.c           |  2 +-
 target/s390x/kvm/stsi-topology.c |  3 ++-
 9 files changed, 24 insertions(+), 17 deletions(-)

diff --git a/include/system/kvm_int.h b/include/system/kvm_int.h
index 4de6106869b..0ef4c336b18 100644
--- a/include/system/kvm_int.h
+++ b/include/system/kvm_int.h
@@ -13,6 +13,7 @@
 #include "qapi/qapi-types-common.h"
 #include "qemu/accel.h"
 #include "qemu/queue.h"
+#include "system/hw_accel.h"
 #include "system/kvm.h"
 #include "hw/boards.h"
 #include "hw/i386/topology.h"
@@ -168,6 +169,8 @@ struct KVMState
     char *device;
 };
 
+#define CPU_FOREACH_KVM(cpu) CPU_FOREACH_HWACCEL(cpu)
+
 void kvm_memory_listener_register(KVMState *s, KVMMemoryListener *kml,
                                   AddressSpace *as, int as_id, const char *name);
 
diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index c65b790433c..9b26b286865 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -872,7 +872,7 @@ static uint64_t kvm_dirty_ring_reap_locked(KVMState *s, CPUState* cpu)
     if (cpu) {
         total = kvm_dirty_ring_reap_one(s, cpu);
     } else {
-        CPU_FOREACH(cpu) {
+        CPU_FOREACH_KVM(cpu) {
             total += kvm_dirty_ring_reap_one(s, cpu);
         }
     }
@@ -935,7 +935,7 @@ static void kvm_cpu_synchronize_kick_all(void)
 {
     CPUState *cpu;
 
-    CPU_FOREACH(cpu) {
+    CPU_FOREACH_KVM(cpu) {
         run_on_cpu(cpu, do_kvm_cpu_synchronize_kick, RUN_ON_CPU_NULL);
     }
 }
@@ -3535,7 +3535,7 @@ int kvm_insert_breakpoint(CPUState *cpu, int type, vaddr addr, vaddr len)
         }
     }
 
-    CPU_FOREACH(cpu) {
+    CPU_FOREACH_KVM(cpu) {
         err = kvm_update_guest_debug(cpu, 0);
         if (err) {
             return err;
@@ -3574,7 +3574,7 @@ int kvm_remove_breakpoint(CPUState *cpu, int type, vaddr addr, vaddr len)
         }
     }
 
-    CPU_FOREACH(cpu) {
+    CPU_FOREACH_KVM(cpu) {
         err = kvm_update_guest_debug(cpu, 0);
         if (err) {
             return err;
@@ -3592,7 +3592,7 @@ void kvm_remove_all_breakpoints(CPUState *cpu)
     QTAILQ_FOREACH_SAFE(bp, &s->kvm_sw_breakpoints, entry, next) {
         if (kvm_arch_remove_sw_breakpoint(cpu, bp) != 0) {
             /* Try harder to find a CPU that currently sees the breakpoint. */
-            CPU_FOREACH(tmpcpu) {
+            CPU_FOREACH_KVM(tmpcpu) {
                 if (kvm_arch_remove_sw_breakpoint(tmpcpu, bp) == 0) {
                     break;
                 }
@@ -3603,7 +3603,7 @@ void kvm_remove_all_breakpoints(CPUState *cpu)
     }
     kvm_arch_remove_all_hw_breakpoints();
 
-    CPU_FOREACH(cpu) {
+    CPU_FOREACH_KVM(cpu) {
         kvm_update_guest_debug(cpu, 0);
     }
 }
@@ -4384,7 +4384,7 @@ static void query_stats_cb(StatsResultList **result, StatsTarget target,
         stats_args.result.stats = result;
         stats_args.names = names;
         stats_args.errp = errp;
-        CPU_FOREACH(cpu) {
+        CPU_FOREACH_KVM(cpu) {
             if (!apply_str_list_filter(cpu->parent_obj.canonical_path, targets)) {
                 continue;
             }
diff --git a/hw/i386/kvm/clock.c b/hw/i386/kvm/clock.c
index 63be5088420..f2638cf2c22 100644
--- a/hw/i386/kvm/clock.c
+++ b/hw/i386/kvm/clock.c
@@ -17,6 +17,7 @@
 #include "qemu/host-utils.h"
 #include "qemu/module.h"
 #include "system/kvm.h"
+#include "system/kvm_int.h"
 #include "system/runstate.h"
 #include "system/hw_accel.h"
 #include "kvm/kvm_i386.h"
@@ -196,7 +197,7 @@ static void kvmclock_vm_state_change(void *opaque, bool running,
         if (!cap_clock_ctrl) {
             return;
         }
-        CPU_FOREACH(cpu) {
+        CPU_FOREACH_KVM(cpu) {
             run_on_cpu(cpu, do_kvmclock_ctrl, RUN_ON_CPU_NULL);
         }
     } else {
diff --git a/hw/intc/spapr_xive_kvm.c b/hw/intc/spapr_xive_kvm.c
index 26d30b41c15..08354f08512 100644
--- a/hw/intc/spapr_xive_kvm.c
+++ b/hw/intc/spapr_xive_kvm.c
@@ -14,6 +14,7 @@
 #include "target/ppc/cpu.h"
 #include "system/cpus.h"
 #include "system/kvm.h"
+#include "system/kvm_int.h"
 #include "system/runstate.h"
 #include "hw/ppc/spapr.h"
 #include "hw/ppc/spapr_cpu_core.h"
@@ -678,7 +679,7 @@ int kvmppc_xive_post_load(SpaprXive *xive, int version_id)
      * 'post_load' handler of XiveTCTX because the machine is not
      * necessarily connected to the KVM device at that time.
      */
-    CPU_FOREACH(cs) {
+    CPU_FOREACH_KVM(cs) {
         PowerPCCPU *cpu = POWERPC_CPU(cs);
 
         ret = kvmppc_xive_cpu_set_state(spapr_cpu_state(cpu)->tctx, &local_err);
@@ -795,7 +796,7 @@ int kvmppc_xive_connect(SpaprInterruptController *intc, uint32_t nr_servers,
         kvmppc_xive_change_state_handler, xive);
 
     /* Connect the presenters to the initial VCPUs of the machine */
-    CPU_FOREACH(cs) {
+    CPU_FOREACH_KVM(cs) {
         PowerPCCPU *cpu = POWERPC_CPU(cs);
 
         ret = kvmppc_xive_cpu_connect(spapr_cpu_state(cpu)->tctx, errp);
diff --git a/hw/intc/xics_kvm.c b/hw/intc/xics_kvm.c
index ee72969f5f1..aed2ad44363 100644
--- a/hw/intc/xics_kvm.c
+++ b/hw/intc/xics_kvm.c
@@ -29,6 +29,7 @@
 #include "qapi/error.h"
 #include "trace.h"
 #include "system/kvm.h"
+#include "system/kvm_int.h"
 #include "hw/ppc/spapr.h"
 #include "hw/ppc/spapr_cpu_core.h"
 #include "hw/ppc/xics.h"
@@ -418,7 +419,7 @@ int xics_kvm_connect(SpaprInterruptController *intc, uint32_t nr_servers,
     kvm_gsi_direct_mapping = true;
 
     /* Create the presenters */
-    CPU_FOREACH(cs) {
+    CPU_FOREACH_KVM(cs) {
         PowerPCCPU *cpu = POWERPC_CPU(cs);
 
         icp_kvm_realize(DEVICE(spapr_cpu_state(cpu)->icp), &local_err);
@@ -434,7 +435,7 @@ int xics_kvm_connect(SpaprInterruptController *intc, uint32_t nr_servers,
     }
 
     /* Connect the presenters to the initial VCPUs of the machine */
-    CPU_FOREACH(cs) {
+    CPU_FOREACH_KVM(cs) {
         PowerPCCPU *cpu = POWERPC_CPU(cs);
         icp_set_kvm_state(spapr_cpu_state(cpu)->icp, &local_err);
         if (local_err) {
diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
index 2f66e63b880..437911d6c6a 100644
--- a/target/i386/kvm/kvm.c
+++ b/target/i386/kvm/kvm.c
@@ -329,7 +329,7 @@ void kvm_synchronize_all_tsc(void)
     CPUState *cpu;
 
     if (kvm_enabled()) {
-        CPU_FOREACH(cpu) {
+        CPU_FOREACH_KVM(cpu) {
             run_on_cpu(cpu, do_kvm_synchronize_tsc, RUN_ON_CPU_NULL);
         }
     }
@@ -2847,7 +2847,7 @@ static void *kvm_msr_energy_thread(void *data)
          * Identify the vcpu threads
          * Calculate the number of vcpu per package
          */
-        CPU_FOREACH(cpu) {
+        CPU_FOREACH_KVM(cpu) {
             for (int i = 0; i < num_threads; i++) {
                 if (cpu->thread_id == thd_stat[i].thread_id) {
                     thd_stat[i].is_vcpu = true;
diff --git a/target/i386/kvm/xen-emu.c b/target/i386/kvm/xen-emu.c
index e81a2458812..36ae9c11252 100644
--- a/target/i386/kvm/xen-emu.c
+++ b/target/i386/kvm/xen-emu.c
@@ -1422,7 +1422,7 @@ int kvm_xen_soft_reset(void)
         return err;
     }
 
-    CPU_FOREACH(cpu) {
+    CPU_FOREACH_KVM(cpu) {
         async_run_on_cpu(cpu, do_vcpu_soft_reset, RUN_ON_CPU_NULL);
     }
 
diff --git a/target/s390x/kvm/kvm.c b/target/s390x/kvm/kvm.c
index db645a48133..a02e78ce807 100644
--- a/target/s390x/kvm/kvm.c
+++ b/target/s390x/kvm/kvm.c
@@ -1559,7 +1559,7 @@ static void handle_diag_318(S390CPU *cpu, struct kvm_run *run)
         return;
     }
 
-    CPU_FOREACH(t) {
+    CPU_FOREACH_KVM(t) {
         run_on_cpu(t, s390_do_cpu_set_diag318,
                    RUN_ON_CPU_HOST_ULONG(diag318_info));
     }
diff --git a/target/s390x/kvm/stsi-topology.c b/target/s390x/kvm/stsi-topology.c
index c8d6389cd87..cf1a9b5d218 100644
--- a/target/s390x/kvm/stsi-topology.c
+++ b/target/s390x/kvm/stsi-topology.c
@@ -10,6 +10,7 @@
 #include "cpu.h"
 #include "hw/s390x/sclp.h"
 #include "hw/s390x/cpu-topology.h"
+#include "system/kvm_int.h"
 
 QEMU_BUILD_BUG_ON(S390_CPU_ENTITLEMENT_LOW != 1);
 QEMU_BUILD_BUG_ON(S390_CPU_ENTITLEMENT_MEDIUM != 2);
@@ -256,7 +257,7 @@ static void s390_topology_fill_list_sorted(S390TopologyList *topology_list)
 
     QTAILQ_INSERT_HEAD(topology_list, &sentinel, next);
 
-    CPU_FOREACH(cs) {
+    CPU_FOREACH_KVM(cs) {
         S390TopologyId id = s390_topology_from_cpu(S390_CPU(cs));
         S390TopologyEntry *entry = NULL, *tmp;
 
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Mon Jan 06 20:12:03 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 20:12:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865970.1277264 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUtSD-0008T9-Pm; Mon, 06 Jan 2025 20:12:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865970.1277264; Mon, 06 Jan 2025 20:12:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUtSD-0008T2-LJ; Mon, 06 Jan 2025 20:12:01 +0000
Received: by outflank-mailman (input) for mailman id 865970;
 Mon, 06 Jan 2025 20:12:00 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=4xez=T6=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tUtKT-0002s4-7N
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 20:04:02 +0000
Received: from mail-10628.protonmail.ch (mail-10628.protonmail.ch
 [79.135.106.28]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5e4eea91-cc69-11ef-a0df-8be0dac302b0;
 Mon, 06 Jan 2025 21:04:00 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5e4eea91-cc69-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1736193838; x=1736453038;
	bh=GlOMQvqo4cIB66QIoN3r6E1UFBz8QKBPa0xck1ph4pI=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=Kt+wUK0IZhGAMFUIJYZWm463E0gFPCxB9SW5uB77S/xrSTL6Szfzf6Inywknz1BCU
	 /c6inUJV8ct9RWWkWm1xop2JpnZQn9fqKR3sdIvQoNG8RhXZ39iiM2R6Fo2CMBQqW1
	 8jpxH5p0KyN/k5BGlQH7UwD5ggySe75StbSMSw3hgOilE+HQVq0lhXqi5mjJ0egPNf
	 JJ+SM7FBy1O6e7+IJKWcegkKnwvhrDk8oKh5yjLqTCejTOFKz5QvmmpRJwTMc3K4C+
	 TK88iN82AkARj/r8PAcphFOhctBgJSNSMoS1tIN2EGOVQ6PKvsJxM8CxCUZD4mVuO+
	 6hy6Elylx8D7g==
Date: Mon, 06 Jan 2025 20:03:52 +0000
To: Jan Beulich <jbeulich@suse.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: Denis Mukhin <dmkhn@proton.me>, dmukhin@ford.com, xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>, =?utf-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Subject: Re: [PATCH v2 19/35] xen/console: introduce console_set_owner()
Message-ID: <WdwwQV5SUUes7R0BWeDutEQWGvnv_YSB8yc-jMeij_uOqMPVYTpAkpmojwppDdKmact1UU3eXZ61TMZZf7s3JKMlG8EnNEaCGbPbd_7Qo30=@proton.me>
In-Reply-To: <3b9635bc-e196-4a7e-95ea-277172ae052a@suse.com>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-19-e9aa923127eb@ford.com> <Z1q3COsFN3J9G60E@macbook.local> <Nzs8m4tgOs8mh44axM9sAfsp2GGMk34p5Oi0dtXh8rLbKzHXmMtMXK_d_AJy-gSQuGRygaZbsvhy9QFvsCc0yyMiqzXslUNID1os1CCzNrA=@proton.me> <3b9635bc-e196-4a7e-95ea-277172ae052a@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: eca3f3d04e6634835ca46d7ef2ae0dc7d21355df
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


On Monday, January 6th, 2025 at 1:58 AM, Jan Beulich <jbeulich@suse.com> wr=
ote:

>=20
>=20
> On 04.01.2025 04:30, Denis Mukhin wrote:
>=20
> > On Thursday, December 12th, 2024 at 2:12 AM, Roger Pau Monn=C3=A9 roger=
.pau@citrix.com wrote:
> >=20
> > > On Thu, Dec 05, 2024 at 08:41:49PM -0800, Denis Mukhin via B4 Relay w=
rote:
> > >=20
> > > > --- a/xen/drivers/char/console.c
> > > > +++ b/xen/drivers/char/console.c
> > > > @@ -463,82 +463,100 @@ static void cf_check dump_console_ring_key(u=
nsigned char key)
> > > >=20
> > > > /*
> > > > * CTRL-<switch_char> changes input direction, rotating among Xen, D=
om0,
> > > > - * and the DomUs started from Xen at boot.
> > > > + * and the DomUs.
> > > > /
> > > > #define switch_code (opt_conswitch[0]-'a'+1)
> > > > +
> > > > /
> > > > - * console_owner=3D0 =3D> input to xen
> > > > - * console_owner=3D1 =3D> input to dom0 (or the sole shim domain)
> > > > - * console_owner=3DN =3D> input to dom(N-1)
> > > > + * Current console owner domain ID: either Xen or domain w/ d->is_=
console =3D=3D
> > > > + * true.
> > > > + *
> > > > + * Initialized in console_endboot().
> > > > */
> > > > -static unsigned int __read_mostly console_owner =3D 0;
> > > > +static domid_t __read_mostly console_owner;
> > >=20
> > > Should this be initialized to DOMID_XEN? I assume it doesn't make
> > > much difference because the variable is not checked before
> > > console_endboot() anyway, but it might be safer to initialize to a
> > > value that assigns the console to Xen.
> >=20
> > Fixed.
> >=20
> > > > -#define max_console_rx (max_init_domid + 1)
> > > > +static struct domain *rcu_lock_domain_console_by_id(domid_t domid)
> > > > +{
> > > > + struct domain *d;
> > > > +
> > > > + d =3D rcu_lock_domain_by_id(domid);
> > > > +
> > >=20
> > > Nit: I would remove this newline.
> >=20
> > Fixed.
> >=20
> > > > + if ( d =3D=3D NULL )
> > > > + return NULL;
> > > > +
> > > > + if ( d->is_console )
> > > > + return d;
> > > > +
> > > > + rcu_unlock_domain(d);
> > > > +
> > > > + return NULL;
> > > > +}
> > > >=20
> > > > -#ifdef CONFIG_SBSA_VUART_CONSOLE
> > > > /* Make sure to rcu_unlock_domain after use */
> > > > struct domain *rcu_lock_domain_console_owner(void)
> > > > {
> > > > - if ( console_owner =3D=3D 0 )
> > > > - return NULL;
> > > > - return rcu_lock_domain_by_id(console_owner - 1);
> > > > + return rcu_lock_domain_console_by_id(console_owner);
> > > > }
> > > > -#endif
> > > >=20
> > > > -static void console_find_owner(void)
> > > > +static bool console_owner_possible(domid_t domid)
> > > > {
> > > > - unsigned int next_rx =3D console_owner;
> > > > -
> > > > - /*
> > > > - * Rotate among Xen, dom0 and boot-time created domUs while skippi=
ng
> > > > - * switching serial input to non existing domains.
> > > > - /
> > > > - for ( ; ; )
> > > > - {
> > > > - domid_t domid;
> > > > - struct domain d;
> > > > -
> > > > - if ( next_rx++ >=3D max_console_rx )
> > > > - {
> > > > - console_owner =3D 0;
> > > > - printk("* Serial input to Xen");
> > > > - break;
> > > > - }
> > > > -
> > > > - if ( consoled_is_enabled() && next_rx =3D=3D 1 )
> > > > - domid =3D get_initial_domain_id();
> > > > - else
> > > > - domid =3D next_rx - 1;
> > > > -
> > > > - d =3D rcu_lock_domain_by_id(domid);
> > > > - if ( d =3D=3D NULL )
> > > > - continue;
> > > > -
> > > > - if ( d->is_console )
> > > > - {
> > > > - rcu_unlock_domain(d);
> > > > - console_owner =3D next_rx;
> > > > - printk("*** Serial input to DOM%u", domid);
> > > > - break;
> > > > - }
> > > > + struct domain *d;
> > > >=20
> > > > + d =3D rcu_lock_domain_console_by_id(domid);
> > > > + if ( d !=3D NULL )
> > > > rcu_unlock_domain(d);
> > > > - }
> > > > +
> > > > + return d !=3D NULL;
> > > > +}
> > > > +
> > > > +int console_set_owner(domid_t domid)
> > > > +{
> > > > + if ( domid =3D=3D DOMID_XEN )
> > > > + printk("*** Serial input to Xen");
> > > > + else if ( console_owner_possible(domid) )
> > > > + printk("*** Serial input to DOM%u", domid);
> > > > + else
> > > > + return -ENOENT;
> > > > +
> > > > + console_owner =3D domid;
> > > >=20
> > > > if ( switch_code )
> > > > printk(" (type 'CTRL-%c' three times to switch input)",
> > > > opt_conswitch[0]);
> > > > printk("\n");
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > +/*
> > > > + * Switch console input focus.
> > > > + * Rotates input focus among Xen, dom0 and boot-time created domUs=
 while
> > > > + * skipping switching serial input to non existing domains.
> > > > + */
> > > > +static void console_find_owner(void)
> > > > +{
> > > > + domid_t i, n =3D max_init_domid + 1;
> > >=20
> > > n can be made const, I would even rename to nr for clarity, but that'=
s
> > > personal taste.
> >=20
> > `max_init_domid` can change at run-time actually (e.g. after `xl create=
`).
> > I kept `n` as is.
>=20
>=20
> How does max_init_domid potentially changing affect (possible) const-ness=
 of n?

Sorry, what I meant is I kept the original name as is in v3.
Forgot to address `const`.

>=20
> However it changing, ...
>=20
> > > > +
> > > > + if ( console_owner =3D=3D DOMID_XEN )
> > > > + i =3D get_initial_domain_id();
> > > > + else
> > > > + i =3D console_owner + 1;
> > > > +
> > > > + for ( ; i < n; i++ )
> > > > + if ( !console_set_owner(i) )
> > > > + break;
> > >=20
> > > Hm, that could be a non-trivial amount of iteration if max_init_domid
> > > is bumped for every domain created as you have it in patch 11/35
> > > (albeit I'm not sure that was intended?)
> >=20
> > Yes, `max_init_domid` is advanced on each domain creation (v3).
>=20
>=20
> ... as you confirm here, undermines what it's used for right now (if I'm
> not mistaken), and would render the variable misnamed.

Yes, the name will be a bit confusing.
Will something like `last_domid` work?

>=20
> Jan




From xen-devel-bounces@lists.xenproject.org Mon Jan 06 20:16:52 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 20:16:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865981.1277273 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUtWp-0000h6-9P; Mon, 06 Jan 2025 20:16:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865981.1277273; Mon, 06 Jan 2025 20:16:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUtWp-0000gz-6D; Mon, 06 Jan 2025 20:16:47 +0000
Received: by outflank-mailman (input) for mailman id 865981;
 Mon, 06 Jan 2025 20:16: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 <SRS0=4xez=T6=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tUtWo-0000gs-MW
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 20:16:46 +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 268ffa0d-cc6b-11ef-a0df-8be0dac302b0;
 Mon, 06 Jan 2025 21:16:45 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 268ffa0d-cc6b-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1736194604; x=1736453804;
	bh=oSRu0GzfjzbLD2kUe3GRdGKX/GdSrGLmNvK5lP+qiwk=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=N4PrNNG541SKnRVUDkjbmAkKurQ5O0ruES11PhnDBrh2x6TW4JDcGmUfRDFgzzYKp
	 +7wXD9htizzhc9vfu6yY6MUZxHUZrNta50UB92gitsGNAxE8Uvv8sTcjd0noszeP27
	 iQ3/Gii/RVZa5q4Rg1qfnTvveLSUUrxWdPoO5UH0B+lqYxrzknD1PiCuhTKkZz/nIC
	 M1xU8zbggn1buIQoGj5ynO4kWvuyDPTqilGld9iAA4Fg4rGIebP/m+M/RClRgjr5/L
	 5wRYEcbqzZhzZ3XG98bwVlxVhfBvHPXmZVpRxBxppbiDHheuVF/vZx+PkdsfQLMLOy
	 mfpB9c9fjXfxg==
Date: Mon, 06 Jan 2025 20:16:38 +0000
To: Jan Beulich <jbeulich@suse.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: Denis Mukhin <dmkhn@proton.me>, dmukhin@ford.com, Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 31/35] x86/hvm: introduce NS8250 UART emulator
Message-ID: <V4pjEMTV_MhwDERhOJQksxnt1aNMN6cE5z0lRjvE-4R1cdBRizIaMikI1hNXYB0tei3ljgLOWVQkMITOEeeBYIsNQzblqB7g8jJJwalRzY0=@proton.me>
In-Reply-To: <5e4fb323-0dd1-4eb9-9e83-245ab516be06@suse.com>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-31-e9aa923127eb@ford.com> <3be247cc-900b-48f3-98f3-0d97532ede76@suse.com> <DJo9IkTvGXsao_hA4njnkX9OVYVR6tXdo95AeBiT8wGtbPb7UKQjLCqqIset3bJ3JbLqogcIb4wPqNXJ-2GFwyrW_UIvRg5Nt9QhpG0hfyo=@proton.me> <5e4fb323-0dd1-4eb9-9e83-245ab516be06@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: eb2c7fff70764aac835a5b8da4cdd14872e89e80
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Monday, January 6th, 2025 at 1:19 AM, Jan Beulich <jbeulich@suse.com> wr=
ote:

>=20
>=20
> On 04.01.2025 06:31, Denis Mukhin wrote:
>=20
> > On Monday, December 16th, 2024 at 7:04 AM, Jan Beulich jbeulich@suse.co=
m wrote:
> >=20
> > > On 06.12.2024 05:42, Denis Mukhin via B4 Relay wrote:
> > >=20
> > > > + depends on HVM && HAS_IOPORTS
> > >=20
> > > Why HAS_IOPORTS?
> >=20
> > It is meant to highlight the fact that MMIO-based UART is not supported=
.
> > It is not currently possible to enable the emulator for, say, Arm platf=
orms.
>=20
>=20
> That I guessed, yet you realize that HAS_IOPORTS describes a host propert=
y,
> not (so much) a guest one?

re: host property: yes; this is meant to be only a guardrail for porting of=
 the
emulator code (if any) to other architectures, since there's no MMIO-based
NS16550 emulator yet.

I will drop this superfluous dependency in the next iteration.

>=20
> Jan




From xen-devel-bounces@lists.xenproject.org Mon Jan 06 20:19:23 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 20:19:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865989.1277283 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUtZI-0001GE-Mw; Mon, 06 Jan 2025 20:19:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865989.1277283; Mon, 06 Jan 2025 20:19:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUtZI-0001G7-Iw; Mon, 06 Jan 2025 20:19:20 +0000
Received: by outflank-mailman (input) for mailman id 865989;
 Mon, 06 Jan 2025 20:19:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=U/ZK=T6=ventanamicro.com=dbarboza@srs-se1.protection.inumbo.net>)
 id 1tUtZH-0001Fu-Fx
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 20:19:19 +0000
Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com
 [2607:f8b0:4864:20::1029])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 80d6d0ee-cc6b-11ef-99a4-01e77a169b0f;
 Mon, 06 Jan 2025 21:19:17 +0100 (CET)
Received: by mail-pj1-x1029.google.com with SMTP id
 98e67ed59e1d1-2ef28f07dbaso16892894a91.2
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 12:19:17 -0800 (PST)
Received: from ?IPV6:2804:7f0:bdcd:fb00:6501:2693:db52:c621?
 ([2804:7f0:bdcd:fb00:6501:2693:db52:c621])
 by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-2f2ee26b125sm39870772a91.43.2025.01.06.12.19.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 06 Jan 2025 12:19:15 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 80d6d0ee-cc6b-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=ventanamicro.com; s=google; t=1736194756; x=1736799556; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=a9p8hjeIMnEMUpmW04h0W7NoiD5E5c5Q5zI/Al9/E30=;
        b=TidC6U8azPrXag5jvCCrebMkb6ZZwL3dMz9bOXSdpjgTglVqdoRP4iD+D68U8n83fU
         bw3A/qKpU6m8040Qnuia/hJ9ZFpKgPAKQrQ9TrrI75q2etbx6JaSLmMBecHMOf9WnfWX
         KXb05tP4ErvlYATbCcBsl0PO95mTU5w2yX9SmHljdas7fOLSF2igMRRDkYJPyMKFHheK
         MPe1NzSsvQ1Z5AOVPM0rLwZ+7a5LNQkFZaAuCxAEp50r11W0A0aFq4D4ecQtUbZMUreS
         TM4a1+Qzw/I2jje5uGfeEcUjznmdAmKMSqsh3HuOpZ5GTfEDinVFKjWxZyc6GEG6u72t
         bTSw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736194756; x=1736799556;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=a9p8hjeIMnEMUpmW04h0W7NoiD5E5c5Q5zI/Al9/E30=;
        b=ALKkxfeK+kj++sGrSc/rHhlxS+YwT18T4oeThq7NWu0+YhvDxyWoUtO//xEhq9p8AR
         IUGfK6PiEGXbVq948gPMUSOl3maybEV6FGyX/fPJ6mBq0PUnk3MKKID40m328Qh5WGvH
         fpdknEojq08HEaW/I/4ODTgVppmR0MpCRHwEKD+euC85pp4p4xkVQjjg9CrDGC7A8cxm
         AkfINdEERdyWIUnDNbPpWmuWpxsy+VqgK04eItX5xuF/FG2gcKViLb6Bl3lAYoO+LMuq
         v+WMmBx6GVVCf8+4pF5UM8H6ZrwoBgDEhKv7VQpn1Qmmkxdnli5jkIAwO8kZexSp8pPa
         VqAg==
X-Forwarded-Encrypted: i=1; AJvYcCWjC3QozigIyZ0X9x0uiSHq0WJB5nTwNtd6PFPxSvR2Vobzhni1v4hrVrw23h1mypJ52SsB36blTOk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzdrZpwX0QVUVt8lc6ld5WnJ0UCbTeJ5W/pzFGeSWwDyjopS19b
	K3NuBr8BicjeHroK4iL7h7QEMs42TBq8ddrHxmiIIGohvL781D+mLqvc2qS2NOU=
X-Gm-Gg: ASbGnctSJVBvM3eJJZBHQihRnBrTiEKtpf5P0X9gzGnY7Cfj3fBw/YcuQryWT7HcGsf
	MA4VJG98CpRK1gry3DAseBo/kUJBz/+l64GduD8+gBSzX7qt8UF3UrU3rorSRY2oLHBzWy3CSWU
	43CNhG+NNlJVV7estD5ciwl5k+q1X+/EfXWL8LdBx4/rkF2w0rmPKtQIJl15Qrbo9pu/wb+A+GJ
	fUNHtFnRG31+3tHhndRIv3rHjesU+58isUwZQyAEwBtE2Nd/SJbU8YhKje3MxjJWtbfe3oNqW2W
	N/y+u+ozBMCXnkbT0+G0GxKkPs+XZAr+GIU=
X-Google-Smtp-Source: AGHT+IEdi1WeRPTrXeJrhazkx/sBhP2RZVeyTSKqrV/o+q5vpCxn6bBHpDXsADAKiAGaa0ShcqYeAQ==
X-Received: by 2002:a17:90b:51c2:b0:2ee:ab29:1a57 with SMTP id 98e67ed59e1d1-2f452def211mr85711065a91.2.1736194756055;
        Mon, 06 Jan 2025 12:19:16 -0800 (PST)
Message-ID: <69e79cef-214d-4795-b3ce-032529c9f7d6@ventanamicro.com>
Date: Mon, 6 Jan 2025 17:19:04 -0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH 1/7] cpus: Restrict CPU_FOREACH_SAFE() to user
 emulation
To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= <philmd@linaro.org>,
 qemu-devel@nongnu.org
Cc: =?UTF-8?B?RnLDqWTDqXJpYyBCYXJyYXQ=?= <fbarrat@linux.ibm.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Ilya Leoshkevich <iii@linux.ibm.com>, Cameron Esfahani <dirty@apple.com>,
 Paolo Bonzini <pbonzini@redhat.com>, kvm@vger.kernel.org,
 Alexander Graf <agraf@csgraf.de>, Paul Durrant <paul@xen.org>,
 David Hildenbrand <david@redhat.com>, Halil Pasic <pasic@linux.ibm.com>,
 Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
 xen-devel@lists.xenproject.org, qemu-arm@nongnu.org,
 =?UTF-8?Q?C=C3=A9dric_Le_Goater?= <clg@redhat.com>,
 Yanan Wang <wangyanan55@huawei.com>, Reinoud Zandijk <reinoud@netbsd.org>,
 Peter Maydell <peter.maydell@linaro.org>, qemu-s390x@nongnu.org,
 Riku Voipio <riku.voipio@iki.fi>, Anthony PERARD <anthony@xenproject.org>,
 Alistair Francis <alistair.francis@wdc.com>,
 Sunil Muthuswamy <sunilmut@microsoft.com>,
 Christian Borntraeger <borntraeger@linux.ibm.com>,
 Nicholas Piggin <npiggin@gmail.com>,
 Richard Henderson <richard.henderson@linaro.org>,
 Marcelo Tosatti <mtosatti@redhat.com>, Thomas Huth <thuth@redhat.com>,
 Roman Bolshakov <rbolshakov@ddn.com>,
 "Edgar E . Iglesias" <edgar.iglesias@amd.com>, Zhao Liu
 <zhao1.liu@intel.com>, Phil Dennis-Jordan <phil@philjordan.eu>,
 David Woodhouse <dwmw2@infradead.org>,
 Harsh Prateek Bora <harshpb@linux.ibm.com>,
 Nina Schoetterl-Glausch <nsg@linux.ibm.com>,
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
 Eduardo Habkost <eduardo@habkost.net>, qemu-ppc@nongnu.org,
 Daniel Henrique Barboza <danielhb413@gmail.com>,
 "Michael S. Tsirkin" <mst@redhat.com>, Anton Johansson <anjo@rev.ng>
References: <20250106200258.37008-1-philmd@linaro.org>
 <20250106200258.37008-2-philmd@linaro.org>
Content-Language: en-US
From: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
In-Reply-To: <20250106200258.37008-2-philmd@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Perhaps add in the commit msg something like "it's only being used in
bsd-user and linux-user code"

On 1/6/25 5:02 PM, Philippe Mathieu-Daudé wrote:
> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> ---

Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>

>   include/hw/core/cpu.h | 3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/include/hw/core/cpu.h b/include/hw/core/cpu.h
> index c3ca0babcb3..48d90f50a71 100644
> --- a/include/hw/core/cpu.h
> +++ b/include/hw/core/cpu.h
> @@ -594,8 +594,11 @@ extern CPUTailQ cpus_queue;
>   #define first_cpu        QTAILQ_FIRST_RCU(&cpus_queue)
>   #define CPU_NEXT(cpu)    QTAILQ_NEXT_RCU(cpu, node)
>   #define CPU_FOREACH(cpu) QTAILQ_FOREACH_RCU(cpu, &cpus_queue, node)
> +
> +#if defined(CONFIG_USER_ONLY)
>   #define CPU_FOREACH_SAFE(cpu, next_cpu) \
>       QTAILQ_FOREACH_SAFE_RCU(cpu, &cpus_queue, node, next_cpu)
> +#endif
>   
>   extern __thread CPUState *current_cpu;
>   



From xen-devel-bounces@lists.xenproject.org Mon Jan 06 20:33:35 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 20:33:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.865997.1277293 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUtmy-0005Dw-QP; Mon, 06 Jan 2025 20:33:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 865997.1277293; Mon, 06 Jan 2025 20:33:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUtmy-0005Dp-Nn; Mon, 06 Jan 2025 20:33:28 +0000
Received: by outflank-mailman (input) for mailman id 865997;
 Mon, 06 Jan 2025 20:33:27 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=U/ZK=T6=ventanamicro.com=dbarboza@srs-se1.protection.inumbo.net>)
 id 1tUtmx-0005D2-Sm
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 20:33:27 +0000
Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com
 [2607:f8b0:4864:20::634])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7a653d06-cc6d-11ef-99a4-01e77a169b0f;
 Mon, 06 Jan 2025 21:33:25 +0100 (CET)
Received: by mail-pl1-x634.google.com with SMTP id
 d9443c01a7336-219f8263ae0so167477945ad.0
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 12:33:25 -0800 (PST)
Received: from ?IPV6:2804:7f0:bdcd:fb00:6501:2693:db52:c621?
 ([2804:7f0:bdcd:fb00:6501:2693:db52:c621])
 by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-219dc9cde66sm296704655ad.145.2025.01.06.12.33.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 06 Jan 2025 12:33:23 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 7a653d06-cc6d-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=ventanamicro.com; s=google; t=1736195604; x=1736800404; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=tRChKa/6ydnGwRW0eNjgRJAJvFNapuIamBmUVRUNy3A=;
        b=ee7djeOEkdNPwbwf3CcHXY7f7EqFFqFtrKBu9v6Rtq4HrqPrLI/hbSWbR4FsllwLR3
         POUku3QTqfcRmmSLfdkHjCvwui0Sn1DCkcB8GAiLZz4gLG3y/qFrRyzRs8Fnz7HbA4Pg
         Q0goFVS+IjZwPxvLdWlT/creXk3GpN32whNuc/zDH8wYCNqg3wWOVLCUogwg/rE0gPrZ
         TuekyeLcQjC4hUrPQI03IIqija77Y/qfMjUAOWWyYM1dV/U/goSJc9MCoLYeBDe6+Per
         13eUMTkK2+9NpzHLPMYvI7phyMfzLlidEn+rGSf6SbuHalWm7FMq+RTILitWRf9+505m
         O0/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736195604; x=1736800404;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=tRChKa/6ydnGwRW0eNjgRJAJvFNapuIamBmUVRUNy3A=;
        b=WcD7Mp+9dFRVnvvb6h97El65wVfpKpBDRemVB5/1/kxGLT4B6RZQjbe6fnSJCFZvNR
         g/UG52TXA1gcU+S8CZ3PveQt7A8X9lb9UMco78q9VEwC5k/pfzrZUFLwQPv8ne/MvETJ
         3GWkIRrGevbXY1i5/XQcV7fJYrX17CTrkDFT8d/5SLSWOnUWYFrbA3UrmR2Ts3mJRq8C
         /fyI3enCr4/AcFnM6AKEw7v/BsFpTwHc0JF+ZbzgWwh6xgf7pbe7jYibtZOZkH6+AnLz
         MW2eTY5cLBsZP3Vk3P1jv3/D0ssAXej0pIbEZt3w8Igh6z4V1UpBuZ/rtYblsqnHOYtI
         eGhA==
X-Forwarded-Encrypted: i=1; AJvYcCX4KrP3cWW2Y481CNjSFFBTY428B4SmkLr9BUrIznbJb3x703yE+QGF2KYSvLcY/OIdK8UdOBpjrSg=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw/4PPJpNASj4KyQ5dx9eIt6+KYVBz3BEAdoIVuNARE8sz4mCvE
	o9LxSou6Oy/DIO5homxKkt0/mLNBY6OwsKshckI1ac6W9THaEVZHG7D232paNno=
X-Gm-Gg: ASbGncv5XmwW4YUn4gvqxHDXD9pEQyEcooGthnQ4G68dSf+2AJOnd2fs5bR2uHEuA/W
	pKFJpUqLfXTF4uXv2JwZZCPHaiM8A0kXFiHQhLkfThvAl3SIcqnXUIyGJGopnghMsBj7Y2TXqFC
	c5HzZ4AggQ+PdSuAUr2ql4bQOMd/yhkZb+BqRtjOMZO5Bq5/I3BzbeJmWtTh9AFxhPE2g8qbaZk
	2ME0/L+//zmQtJAYM/jBrHCWDiCJtSmeUgqBVzpSeIPdS8nxIRDJNFD0rb9AZXE/s7QHBoswkMI
	92TJ3ywooZpSHYHjVPXup71fzSdo9IN8C3M=
X-Google-Smtp-Source: AGHT+IGIo280ucsBcngxguAyG9JQ9T3VFgxxJUPO1hVz/7EWXjloduoiThjDr/f0vbWxM4+ikOS8ZQ==
X-Received: by 2002:a17:903:2384:b0:216:5cbd:5449 with SMTP id d9443c01a7336-219e6e9e8c5mr891272455ad.13.1736195604239;
        Mon, 06 Jan 2025 12:33:24 -0800 (PST)
Message-ID: <bd8168fe-c774-4f75-8a94-1a67ec31e38d@ventanamicro.com>
Date: Mon, 6 Jan 2025 17:33:12 -0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH 6/7] accel/hvf: Use CPU_FOREACH_HVF()
To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= <philmd@linaro.org>,
 qemu-devel@nongnu.org
Cc: =?UTF-8?B?RnLDqWTDqXJpYyBCYXJyYXQ=?= <fbarrat@linux.ibm.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Ilya Leoshkevich <iii@linux.ibm.com>, Cameron Esfahani <dirty@apple.com>,
 Paolo Bonzini <pbonzini@redhat.com>, kvm@vger.kernel.org,
 Alexander Graf <agraf@csgraf.de>, Paul Durrant <paul@xen.org>,
 David Hildenbrand <david@redhat.com>, Halil Pasic <pasic@linux.ibm.com>,
 Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
 xen-devel@lists.xenproject.org, qemu-arm@nongnu.org,
 =?UTF-8?Q?C=C3=A9dric_Le_Goater?= <clg@redhat.com>,
 Yanan Wang <wangyanan55@huawei.com>, Reinoud Zandijk <reinoud@netbsd.org>,
 Peter Maydell <peter.maydell@linaro.org>, qemu-s390x@nongnu.org,
 Riku Voipio <riku.voipio@iki.fi>, Anthony PERARD <anthony@xenproject.org>,
 Alistair Francis <alistair.francis@wdc.com>,
 Sunil Muthuswamy <sunilmut@microsoft.com>,
 Christian Borntraeger <borntraeger@linux.ibm.com>,
 Nicholas Piggin <npiggin@gmail.com>,
 Richard Henderson <richard.henderson@linaro.org>,
 Marcelo Tosatti <mtosatti@redhat.com>, Thomas Huth <thuth@redhat.com>,
 Roman Bolshakov <rbolshakov@ddn.com>,
 "Edgar E . Iglesias" <edgar.iglesias@amd.com>, Zhao Liu
 <zhao1.liu@intel.com>, Phil Dennis-Jordan <phil@philjordan.eu>,
 David Woodhouse <dwmw2@infradead.org>,
 Harsh Prateek Bora <harshpb@linux.ibm.com>,
 Nina Schoetterl-Glausch <nsg@linux.ibm.com>,
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
 Eduardo Habkost <eduardo@habkost.net>, qemu-ppc@nongnu.org,
 Daniel Henrique Barboza <danielhb413@gmail.com>,
 "Michael S. Tsirkin" <mst@redhat.com>, Anton Johansson <anjo@rev.ng>
References: <20250106200258.37008-1-philmd@linaro.org>
 <20250106200258.37008-7-philmd@linaro.org>
Content-Language: en-US
From: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
In-Reply-To: <20250106200258.37008-7-philmd@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit



On 1/6/25 5:02 PM, Philippe Mathieu-Daudé wrote:
> Only iterate over HVF vCPUs when running HVF specific code.
> 
> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> ---
>   include/system/hvf_int.h  | 4 ++++
>   accel/hvf/hvf-accel-ops.c | 9 +++++----
>   target/arm/hvf/hvf.c      | 4 ++--
>   3 files changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/include/system/hvf_int.h b/include/system/hvf_int.h
> index 42ae18433f0..3cf64faabd1 100644
> --- a/include/system/hvf_int.h
> +++ b/include/system/hvf_int.h
> @@ -11,6 +11,8 @@
>   #ifndef HVF_INT_H
>   #define HVF_INT_H
>   
> +#include "system/hw_accel.h"
> +
>   #ifdef __aarch64__
>   #include <Hypervisor/Hypervisor.h>
>   typedef hv_vcpu_t hvf_vcpuid;
> @@ -74,4 +76,6 @@ int hvf_put_registers(CPUState *);
>   int hvf_get_registers(CPUState *);
>   void hvf_kick_vcpu_thread(CPUState *cpu);
>   
> +#define CPU_FOREACH_HVF(cpu) CPU_FOREACH_HWACCEL(cpu)


Cosmetic comment: given that this is HVF specific code and we only support one hw
accelerator at a time, I'd skip this alias and use CPU_FOREACH_HWACCEL(cpu) directly.
It would make it easier when grepping to see where and how the macro is being used.
Same thing in the next patch with CPU_FOREACH_KVM().


LGTM otherwise. Thanks,

Daniel


> +
>   #endif
> diff --git a/accel/hvf/hvf-accel-ops.c b/accel/hvf/hvf-accel-ops.c
> index 945ba720513..bbbe2f8d45b 100644
> --- a/accel/hvf/hvf-accel-ops.c
> +++ b/accel/hvf/hvf-accel-ops.c
> @@ -504,7 +504,7 @@ static int hvf_insert_breakpoint(CPUState *cpu, int type, vaddr addr, vaddr len)
>           }
>       }
>   
> -    CPU_FOREACH(cpu) {
> +    CPU_FOREACH_HVF(cpu) {
>           err = hvf_update_guest_debug(cpu);
>           if (err) {
>               return err;
> @@ -543,7 +543,7 @@ static int hvf_remove_breakpoint(CPUState *cpu, int type, vaddr addr, vaddr len)
>           }
>       }
>   
> -    CPU_FOREACH(cpu) {
> +    CPU_FOREACH_HVF(cpu) {
>           err = hvf_update_guest_debug(cpu);
>           if (err) {
>               return err;
> @@ -560,7 +560,7 @@ static void hvf_remove_all_breakpoints(CPUState *cpu)
>       QTAILQ_FOREACH_SAFE(bp, &hvf_state->hvf_sw_breakpoints, entry, next) {
>           if (hvf_arch_remove_sw_breakpoint(cpu, bp) != 0) {
>               /* Try harder to find a CPU that currently sees the breakpoint. */
> -            CPU_FOREACH(tmpcpu)
> +            CPU_FOREACH_HVF(tmpcpu)
>               {
>                   if (hvf_arch_remove_sw_breakpoint(tmpcpu, bp) == 0) {
>                       break;
> @@ -572,7 +572,7 @@ static void hvf_remove_all_breakpoints(CPUState *cpu)
>       }
>       hvf_arch_remove_all_hw_breakpoints();
>   
> -    CPU_FOREACH(cpu) {
> +    CPU_FOREACH_HVF(cpu) {
>           hvf_update_guest_debug(cpu);
>       }
>   }
> @@ -581,6 +581,7 @@ static void hvf_accel_ops_class_init(ObjectClass *oc, void *data)
>   {
>       AccelOpsClass *ops = ACCEL_OPS_CLASS(oc);
>   
> +    ops->get_cpus_queue = hw_accel_get_cpus_queue;
>       ops->create_vcpu_thread = hvf_start_vcpu_thread;
>       ops->kick_vcpu_thread = hvf_kick_vcpu_thread;
>   
> diff --git a/target/arm/hvf/hvf.c b/target/arm/hvf/hvf.c
> index 0afd96018e0..13400ff0d5f 100644
> --- a/target/arm/hvf/hvf.c
> +++ b/target/arm/hvf/hvf.c
> @@ -2269,10 +2269,10 @@ static void hvf_arch_set_traps(void)
>   
>       /* Check whether guest debugging is enabled for at least one vCPU; if it
>        * is, enable exiting the guest on all vCPUs */
> -    CPU_FOREACH(cpu) {
> +    CPU_FOREACH_HVF(cpu) {
>           should_enable_traps |= cpu->accel->guest_debug_enabled;
>       }
> -    CPU_FOREACH(cpu) {
> +    CPU_FOREACH_HVF(cpu) {
>           /* Set whether debug exceptions exit the guest */
>           r = hv_vcpu_set_trap_debug_exceptions(cpu->accel->fd,
>                                                 should_enable_traps);



From xen-devel-bounces@lists.xenproject.org Mon Jan 06 21:08:58 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 21:08:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866008.1277302 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUuL8-0002n9-It; Mon, 06 Jan 2025 21:08:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866008.1277302; Mon, 06 Jan 2025 21:08:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUuL8-0002n2-GN; Mon, 06 Jan 2025 21:08:46 +0000
Received: by outflank-mailman (input) for mailman id 866008;
 Mon, 06 Jan 2025 21:08: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 <SRS0=iH3c=T6=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tUuL7-0002mw-EZ
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 21:08:45 +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 68fd419f-cc72-11ef-a0df-8be0dac302b0;
 Mon, 06 Jan 2025 22:08:43 +0100 (CET)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-43625c4a50dso102276685e9.0
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 13:08:43 -0800 (PST)
Received: from [192.168.69.132] (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c89e528sm49330255f8f.83.2025.01.06.13.08.40
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 06 Jan 2025 13:08:42 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 68fd419f-cc72-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1736197723; x=1736802523; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=Dt1f81EVsgW5OvATu4Z5FjJ0Vm5UWbdIlHsy1CTjJ6o=;
        b=oeAzpeDc5u8INQ79ainvTB4xjnxO5gnv7mVTA6zBlMwImbWlQ9lO5GtHLM5NXQQsZZ
         jKTXTe4sV7jnQYa28cJlvX7djvl4RZ2WRlUi21U3VBMP7dArmmjKIQYlm5h+lLjz2BAT
         A/QrbBw/4Tcxx7xSY7SOYJREj+5VR+E26RcXOzvEssEaGR1bYQdtvz0fGGvytYx0vZsi
         KYoqE+Qh8JnSl6v8Qvxtg39R/CFmqLL06WQY39pAY8Sxh0mieCX02ReykMgk1K2w9fVu
         zeXrGr7c3BdBlRmKxOjqFxyyOZpbaNI/cEcm47msf5NhiSV+mIEjRhDITnKH7kqWLY7Y
         FghA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736197723; x=1736802523;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Dt1f81EVsgW5OvATu4Z5FjJ0Vm5UWbdIlHsy1CTjJ6o=;
        b=Vv/4FKhJNLFvBp/lHRgI9LJxo7egI+DokTu/ITut1CYkVZjPJGfT+9LF9yCQntcsTp
         mM7dJdwg0j9MLklaRaxNrG2t+PGpwGiZ6EWerRsockmcYnBcnCo4iNc+8McOQ+BnH6mg
         9ZPZDQM2jLGTKeOx/QVoqC5j0s9JHwdTOe4Q/jcgGogP+GC37SsPFjQJuQKlpUZrYm0j
         phO/xPn7hIYg9wu90x90ZhXRCSappU9sRaBIKopsc0/P9u2f771lk16pLWuahANiMq32
         GGLJjhHn7YdKf2PH+jlPzAvtSPl1VTE0vm4Ay8tO6O6npWOQqx9fzV8KYD6Pq+WVyP6y
         dp8A==
X-Forwarded-Encrypted: i=1; AJvYcCV6eFrbHSyCnEhwbHKNXj/aPxybTZni2Uv/eJb8aFYynULGXfUEq96iPuqmq6dMZQj7L3caBolSRyw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywr/grZALNmVtk+KQIFCPuxzCrFv4Iy9I3ObEo/rwSynl0W4OUC
	MkT0KyKhFo3seOB0dJvbn1orkHaEghf79DDJ2U4Azu+hPHKjj637aFzxOcFbn6Y=
X-Gm-Gg: ASbGncvTwgBFdzp7FP07JfYPoLFMxFPGTyhOmgK/c7k4cfiwxL7GLohigRP2hRndu/s
	bNqXtb1p5Ad61Eu95Gh7CGI3oxgsEObe/4KMQcwl23k3bcSyfWYKmMmXJxqMWh9pVyrbNlTwId4
	UN/+AT3ADcGM4Fz8/3PUvUgtKiDJTf4bC48u++4EKPCZ7g7ecfeyu3EaCBnw50DaSav4t9s6eIw
	DnH58oF658wJY56G46beGLDYalIPS6IdlHZnd6b+0HSolA1tk/K+3LIaJn63uHR4sRR8i2pzr/h
	Pa0Vty4LJAzaj6tkdfjzD8AO
X-Google-Smtp-Source: AGHT+IHQlDMHE5yzCDH0asXIjYrH5p/B5ofNz91YmLcogyERBoJ0h4sXot+iT1K99vchhPpxIvHj0A==
X-Received: by 2002:a05:6000:188e:b0:385:f840:e613 with SMTP id ffacd0b85a97d-38a223fd52dmr44054103f8f.51.1736197722710;
        Mon, 06 Jan 2025 13:08:42 -0800 (PST)
Message-ID: <6df59c2c-e29d-4b86-8908-4cb9093bad13@linaro.org>
Date: Mon, 6 Jan 2025 22:08:39 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH 6/7] accel/hvf: Use CPU_FOREACH_HVF()
To: Daniel Henrique Barboza <dbarboza@ventanamicro.com>, qemu-devel@nongnu.org
Cc: =?UTF-8?B?RnLDqWTDqXJpYyBCYXJyYXQ=?= <fbarrat@linux.ibm.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Ilya Leoshkevich <iii@linux.ibm.com>, Cameron Esfahani <dirty@apple.com>,
 Paolo Bonzini <pbonzini@redhat.com>, kvm@vger.kernel.org,
 Alexander Graf <agraf@csgraf.de>, Paul Durrant <paul@xen.org>,
 David Hildenbrand <david@redhat.com>, Halil Pasic <pasic@linux.ibm.com>,
 Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
 xen-devel@lists.xenproject.org, qemu-arm@nongnu.org,
 =?UTF-8?Q?C=C3=A9dric_Le_Goater?= <clg@redhat.com>,
 Yanan Wang <wangyanan55@huawei.com>, Reinoud Zandijk <reinoud@netbsd.org>,
 Peter Maydell <peter.maydell@linaro.org>, qemu-s390x@nongnu.org,
 Riku Voipio <riku.voipio@iki.fi>, Anthony PERARD <anthony@xenproject.org>,
 Alistair Francis <alistair.francis@wdc.com>,
 Sunil Muthuswamy <sunilmut@microsoft.com>,
 Christian Borntraeger <borntraeger@linux.ibm.com>,
 Nicholas Piggin <npiggin@gmail.com>,
 Richard Henderson <richard.henderson@linaro.org>,
 Marcelo Tosatti <mtosatti@redhat.com>, Thomas Huth <thuth@redhat.com>,
 Roman Bolshakov <rbolshakov@ddn.com>,
 "Edgar E . Iglesias" <edgar.iglesias@amd.com>, Zhao Liu
 <zhao1.liu@intel.com>, Phil Dennis-Jordan <phil@philjordan.eu>,
 David Woodhouse <dwmw2@infradead.org>,
 Harsh Prateek Bora <harshpb@linux.ibm.com>,
 Nina Schoetterl-Glausch <nsg@linux.ibm.com>,
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
 Eduardo Habkost <eduardo@habkost.net>, qemu-ppc@nongnu.org,
 Daniel Henrique Barboza <danielhb413@gmail.com>,
 "Michael S. Tsirkin" <mst@redhat.com>, Anton Johansson <anjo@rev.ng>
References: <20250106200258.37008-1-philmd@linaro.org>
 <20250106200258.37008-7-philmd@linaro.org>
 <bd8168fe-c774-4f75-8a94-1a67ec31e38d@ventanamicro.com>
Content-Language: en-US
From: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= <philmd@linaro.org>
In-Reply-To: <bd8168fe-c774-4f75-8a94-1a67ec31e38d@ventanamicro.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 6/1/25 21:33, Daniel Henrique Barboza wrote:
> 
> 
> On 1/6/25 5:02 PM, Philippe Mathieu-Daudé wrote:
>> Only iterate over HVF vCPUs when running HVF specific code.
>>
>> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
>> ---
>>   include/system/hvf_int.h  | 4 ++++
>>   accel/hvf/hvf-accel-ops.c | 9 +++++----
>>   target/arm/hvf/hvf.c      | 4 ++--
>>   3 files changed, 11 insertions(+), 6 deletions(-)
>>
>> diff --git a/include/system/hvf_int.h b/include/system/hvf_int.h
>> index 42ae18433f0..3cf64faabd1 100644
>> --- a/include/system/hvf_int.h
>> +++ b/include/system/hvf_int.h
>> @@ -11,6 +11,8 @@
>>   #ifndef HVF_INT_H
>>   #define HVF_INT_H
>> +#include "system/hw_accel.h"
>> +
>>   #ifdef __aarch64__
>>   #include <Hypervisor/Hypervisor.h>
>>   typedef hv_vcpu_t hvf_vcpuid;
>> @@ -74,4 +76,6 @@ int hvf_put_registers(CPUState *);
>>   int hvf_get_registers(CPUState *);
>>   void hvf_kick_vcpu_thread(CPUState *cpu);
>> +#define CPU_FOREACH_HVF(cpu) CPU_FOREACH_HWACCEL(cpu)
> 
> 
> Cosmetic comment: given that this is HVF specific code and we only 
> support one hw
> accelerator at a time, I'd skip this alias and use 
> CPU_FOREACH_HWACCEL(cpu) directly.
> It would make it easier when grepping to see where and how the macro is 
> being used.

I find it more useful to grep for a particular accelerator, or for
all of them:

$ git grep CPU_FOREACH_
accel/hvf/hvf-accel-ops.c:507:    CPU_FOREACH_HVF(cpu) {
accel/hvf/hvf-accel-ops.c:546:    CPU_FOREACH_HVF(cpu) {
accel/kvm/kvm-all.c:875:        CPU_FOREACH_KVM(cpu) {
accel/kvm/kvm-all.c:938:    CPU_FOREACH_KVM(cpu) {
accel/tcg/cputlb.c:372:    CPU_FOREACH_TCG(cpu) {
accel/tcg/cputlb.c:650:        CPU_FOREACH_TCG(dst_cpu) {



From xen-devel-bounces@lists.xenproject.org Mon Jan 06 21:37:03 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 21:37:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866023.1277313 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUumO-0000At-N1; Mon, 06 Jan 2025 21:36:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866023.1277313; Mon, 06 Jan 2025 21:36:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUumO-0000Am-KG; Mon, 06 Jan 2025 21:36:56 +0000
Received: by outflank-mailman (input) for mailman id 866023;
 Mon, 06 Jan 2025 21:36:55 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=T/Ld=T6=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tUumN-0000Ag-7L
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 21:36:55 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 57e8ca60-cc76-11ef-99a4-01e77a169b0f;
 Mon, 06 Jan 2025 22:36:53 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 14027A41EEE;
 Mon,  6 Jan 2025 21:35:03 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0582BC4CED2;
 Mon,  6 Jan 2025 21:36:50 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 57e8ca60-cc76-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1736199411;
	bh=9ssZsreN+2+2OYrS7HKzWEcvutpMzydOWq/SoLGM3TQ=;
	h=Date:From:To:cc:Subject:From;
	b=gREIQjFTHAfIPMvHL+Cl6KJpuMdwfnazPGskJv4ThQguibpX+2RJ4Z6RMMPYObjvp
	 +rUv5crmVx19dhNBask9ky9d1Gnq3grHAYuH/kJXcU2HSF6DSRTHBKBfZE9nWCpnvD
	 xOuQ5o8G4zmPgjI82/dTxDyF6FuHLXG1vY8ASnhXZ5vwOPMVFIhm82IOoS5mv8MhxN
	 j6QIZhO9aHrdURVFkx8/nBwDDWyq2rTw9capb56vj6xH7NoJ17ep7umV4/owZdjTim
	 qTBLKEnnf3RWc5KgaHnOuPHSoZXxmwFGAaOs6ZD5HtH/1g+iIu4uPALD6kFwN6t9Ev
	 IETTDROXCiKSw==
Date: Mon, 6 Jan 2025 13:36:49 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: linux-kernel@vger.kernel.org
cc: sstabellini@kernel.org, jgross@suse.com, xen-devel@lists.xenproject.org
Subject: [PATCH v2] xen: update pvcalls_front_accept prototype
Message-ID: <alpine.DEB.2.22.394.2501061335161.133435@ubuntu-linux-20-04-desktop>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

xen: update pvcalls_front_accept prototype

Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
---

Changes in v2:
- also update pvcalls-front.c

diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
index b72ee9379d77..cab480059731 100644
--- a/drivers/xen/pvcalls-front.c
+++ b/drivers/xen/pvcalls-front.c
@@ -769,7 +769,8 @@ int pvcalls_front_listen(struct socket *sock, int backlog)
 	return ret;
 }
 
-int pvcalls_front_accept(struct socket *sock, struct socket *newsock, int flags)
+int pvcalls_front_accept(struct socket *sock, struct socket *newsock,
+			 struct proto_accept_arg *arg)
 {
 	struct pvcalls_bedata *bedata;
 	struct sock_mapping *map;
@@ -788,7 +789,7 @@ int pvcalls_front_accept(struct socket *sock, struct socket *newsock, int flags)
 		return -EINVAL;
 	}
 
-	nonblock = flags & SOCK_NONBLOCK;
+	nonblock = arg->flags & SOCK_NONBLOCK;
 	/*
 	 * Backend only supports 1 inflight accept request, will return
 	 * errors for the others
diff --git a/drivers/xen/pvcalls-front.h b/drivers/xen/pvcalls-front.h
index f694ad77379f..881ef14660bc 100644
--- a/drivers/xen/pvcalls-front.h
+++ b/drivers/xen/pvcalls-front.h
@@ -12,7 +12,7 @@ int pvcalls_front_bind(struct socket *sock,
 int pvcalls_front_listen(struct socket *sock, int backlog);
 int pvcalls_front_accept(struct socket *sock,
 			 struct socket *newsock,
-			 int flags);
+			 struct proto_accept_arg *arg);
 int pvcalls_front_sendmsg(struct socket *sock,
 			  struct msghdr *msg,
 			  size_t len);


From xen-devel-bounces@lists.xenproject.org Mon Jan 06 22:01:39 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Jan 2025 22:01:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866031.1277324 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUvAB-0005GZ-Kg; Mon, 06 Jan 2025 22:01:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866031.1277324; Mon, 06 Jan 2025 22:01:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tUvAB-0005GS-GJ; Mon, 06 Jan 2025 22:01:31 +0000
Received: by outflank-mailman (input) for mailman id 866031;
 Mon, 06 Jan 2025 22:01:30 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=T/Ld=T6=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tUvAA-0005GM-Cl
 for xen-devel@lists.xenproject.org; Mon, 06 Jan 2025 22:01:30 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c6e92887-cc79-11ef-99a4-01e77a169b0f;
 Mon, 06 Jan 2025 23:01:28 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 73D2B5C60E5;
 Mon,  6 Jan 2025 22:00:45 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2C231C4CED2;
 Mon,  6 Jan 2025 22:01:25 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c6e92887-cc79-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1736200886;
	bh=+SgfoRqkrmN/LiTQaBhlqzmt92UAGuRngzCafowYl1k=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=V0j0fqfwl4w1yeLE8v9dKNz7Gl75P7ufdXEsrqPbTCJA2C/3vHvv1iFfG2og0s7Nl
	 AvvtZ6aoLhp7qDJ1idOOhukJ86BbE+8Dt1C6aOUZZIjhVr6i630cDlxuQEaxXYQWlA
	 ZEAW5DD0LNk84sYpEAwTD1itLcW7zkXx5WzqZ3t+6mlEUIukEJtrGgtcXXAj9qO6gK
	 wmnr06Gm7JLWV+hxctRySskldopmOXqHW3zx4bqXH/Qjyuc59Xu5UgxZrR5vOCsYiw
	 W8/ZUuvNIE90hOfr9QY4htltsGYOj0IxAqnDQc9klWQjlEDh4tMSk0O4EcGeTRKyAC
	 /1FiGD1wVtTug==
Date: Mon, 6 Jan 2025 14:01:23 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich <jbeulich@suse.com>
cc: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, 
    Stefano Stabellini <sstabellini@kernel.org>, 
    Anthony PERARD <anthony.perard@vates.tech>, 
    Michal Orzel <michal.orzel@amd.com>, 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
    Oleksii Kurochko <oleksii.kurochko@gmail.com>, 
    "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH for-4.20] public/version: soften wording for deprecated
 sub-ops
In-Reply-To: <8ca8ac20-a19f-49ef-9631-08cdcef854d2@suse.com>
Message-ID: <alpine.DEB.2.22.394.2501061229300.133435@ubuntu-linux-20-04-desktop>
References: <bf8cc342-52aa-44ee-8bce-ce2be6406904@suse.com> <0c8a13d0-04d7-4ed6-a8d8-a4423867fa3f@citrix.com> <8ca8ac20-a19f-49ef-9631-08cdcef854d2@suse.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 6 Jan 2025, Jan Beulich wrote:
> On 06.01.2025 12:08, Andrew Cooper wrote:
> > On 06/01/2025 11:04 am, Jan Beulich wrote:
> >> These interfaces were - afaict - originally introduced this way on the
> >> firm assumption that the used array sizes would be good virtually
> >> forever.  While this assumption turned out to not be true for at least
> >> some of them, this still doesn't really render them "broken": They still
> >> fit their original purpose, and they are still usable for a fair subset
> >> of environments.  Re-word the comments accordingly.
> >>
> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> > 
> > No.
> > 
> > The community voted and rejected this opinion.
> 
> That's not my recollection of what was voted on, and with the vote results
> not being available referring to them is unhelpful anyway.
> 
> My (admittedly vague) recollection is that it was decided to leave enough
> room for wording choice by submitters. That would cover your original
> patch, and it would equally cover mine.

The community-wide survey indicated that it is acceptable to use the
term "broken" in our documentation [1]. While the survey was not tied to
a specific instance, it was undoubtedly influenced by the ongoing
discussion at the time.

If the purpose of this patch is to replace the term "broken", as it
would seem from the commit message, I would recommend dropping the patch
and leaving the wording as it is, given that the community has expressed
approval of its use. Let us respect that decision.

However, if the goal is to improve clarity by specifying "due to its
size limitations" and noting that the truncation occurs "silently", then
I believe the patch could be reviewed with that objective in mind.

In other words, we should not replace "broken" simply for the sake of
doing so. That discussion has already been settled. When reviewing this
patch, our focus should be on its other merits, if any.

Based on the above, I would not take the patch in its current form. But
if Jan is up for rewording the commit message, and focusing purely on
the clarity of the in-code comments maybe a future version could be
acceptable.

[1] https://cryptpad.fr/form/#/2/form/view/7ByH95Vd7KiDOvN4wjV5iUGlMuZbkVdwk7cYpZdluWo/


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 07:53:15 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 07:53:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866066.1277333 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV4OR-0003hM-TK; Tue, 07 Jan 2025 07:52:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866066.1277333; Tue, 07 Jan 2025 07:52:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV4OR-0003hF-QI; Tue, 07 Jan 2025 07:52:51 +0000
Received: by outflank-mailman (input) for mailman id 866066;
 Tue, 07 Jan 2025 07:52:50 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=1r68=T7=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tV4OQ-0003h9-Je
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 07:52:50 +0000
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com
 [2a00:1450:4864:20::42f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 619c2d96-cccc-11ef-99a4-01e77a169b0f;
 Tue, 07 Jan 2025 08:52:45 +0100 (CET)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-385df53e559so11903004f8f.3
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 23:52: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
 ffacd0b85a97d-38a5524f064sm23649654f8f.101.2025.01.06.23.52.44
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 06 Jan 2025 23:52:44 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 619c2d96-cccc-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736236365; x=1736841165; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=d+k56CqkhlJP2/NgmgbZAI44vP6DNfOn+8VCtcYzVrM=;
        b=IXfdPj6DHQ0tbK0J8bFmDqDxxYmRL6owt3hItzmEFGJ34cjb3+8cKL1jQs0d0kH+OT
         /CKr40ZwZSfhY0stBFumjys6FaaDt6K5LQmlCIivF/u6qHucFVqZg/AId1QI2KJrfJDa
         dn3oy6ASCy5FA7L17XrCTBcFwHnlrvjlyUmBPz+YSOZ81vARCd+ladbEZ7eyFHTiL8h/
         z3488ZFpQqw234JxTRV7+yFd5prkpqsUcx3yYB3l/Q4nvd3EIDTkgsgr9PDGQLvSeSoy
         HwCnffm3DwXz4edv/LSCmDesjT8JXHgNt2YFevSLRK6dPRDj9nJvRezri0blsGo4NXy/
         0pIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736236365; x=1736841165;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=d+k56CqkhlJP2/NgmgbZAI44vP6DNfOn+8VCtcYzVrM=;
        b=w9Myyz5GwWkE/0BZetbXS2F41SPb02GnvlSegdbwZ6/gzVLV+QOvJekMt0XlY25e4/
         qQXkv7SMIEmZxVcbbatOtKslW1SxZT6q1r8eZ0umNbwjh/Q1bbfUjMdC51+dhgRW+Oyc
         eQmQzV06eT5fPyKxurOQCdak65Us/gZXu+bPez6UFIiJ7HTuKWkJvU4K3D1L+0JkAEm2
         +dUc39msZ+YwqgpSt0XQp1j300wi+o+Rjq768nkGdQzJjmakkdoJ+Qp2kxIPWfmhmXdc
         Lw2THveNe0IDFl0mvpLPWNQaZVOme3DGYyxyxYIFIFY5CZFf3JrRa4YmxEMn+EK/nllx
         E44A==
X-Forwarded-Encrypted: i=1; AJvYcCU8HHf9iwiCfV+wo6Q2nbiPth0dD/HDhVtSERZhWr/Jgso0gkZF7wNf+1zYY/7XYWZmox5PJdz+5VE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxnxgTk6+KuA4S2MbvFPcqneToUnYSAAYT4qtkyKF6Pronrr97L
	V3DF25q3wT98pQDbmVCNDo29Qtsw7o3J4g42houKkYV9dBPginqZEsul0tYHUA==
X-Gm-Gg: ASbGnctvhKaAH+mp8vdjTYjJqoTNMYtnzDPm8nvceAzKpJekK8/WDreh9GAkwaCaLVI
	TMdBzwjm/hjTYF1YdYeD4jmaRDAKJC92h5yN0oHqR7/8+qeiuqk+1VEHyV+M1/0f10V5yatq+VA
	scFdHtB+vcqvY8InNiC3JTUIWpiGllInsI/5cQh8/oE7VbfDfUrLs04SAyR1MlBuxXyQ5XybwYa
	EJSrlHsov7nbOfLRKOh7Rr8sVfz3SNSgbrfCSu6/0UwVbTfyt5M6ExSOcyLbVc2PUUxqTz69a69
	5kOERpYEpwmCPXZFTPJXG9vDg9Ar1Z5MlR0imSEpFQ==
X-Google-Smtp-Source: AGHT+IGeun3J91zLuwjBBxEg/5joTExiUZ6dj9OnIJQ43O4u+Brej1LZEbYFUCvADqaliVDaALVj4w==
X-Received: by 2002:a5d:5847:0:b0:385:f6de:6266 with SMTP id ffacd0b85a97d-38a221fd10cmr47932448f8f.24.1736236365021;
        Mon, 06 Jan 2025 23:52:45 -0800 (PST)
Message-ID: <d8873cf8-dd17-4f9e-bded-7a47e04bd1be@suse.com>
Date: Tue, 7 Jan 2025 08:52:43 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC] docs: FRED support in Xen
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20250103204704.84067-1-andrew.cooper3@citrix.com>
 <3ff59df0-69f8-426a-ab44-d2cd9b5bf8ea@suse.com>
 <0a780f2d-1e49-47bd-8c66-babbc2dd8f63@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <0a780f2d-1e49-47bd-8c66-babbc2dd8f63@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 06.01.2025 17:06, Andrew Cooper wrote:
> On 06/01/2025 2:28 pm, Jan Beulich wrote:
>> On 03.01.2025 21:47, Andrew Cooper wrote:
>>> + #. In x86_emulate.c's ``put_fpu()``.  As far as I can tell, this is
>>> +    completely buggy; the values will be poisoned for HVM guests, and stale
>>> +    from the prior context switch for PV guests.
>> For HVM guests the ->read_segment() hook will be populated, so the path isn't
>> taken (leaving aside the odd case of the hook failing). For PV guests I don't
>> see any staleness concern: When the vCPU was switched in, the fields were set
>> (restored), weren't they?
> 
> There is up to 30ms of guest runtime between the last schedule in and
> this emulation, and segment loads don't generally trap for PV guests.

Oh, yes, I see now what you mean. Luckily even pv/emul-priv-op.c sets the hook.
Hence what's affected here are the two uses of the emulator from
pv/ro-page-fault.c. Sadly HVM isn't entirely unaffected, as the shadow mode use
of the emulator doesn't set the hook. Neither of the three cases are likely to
involve FPU insns, yet it's not excluded.

Question is what to do: Simply failing the entire emulation feels too heavy
handed. We could choose to simply store nul selectors instead. That would be
kind of wrong though for (in the hypervisor: hypothetical) cases where the
incoming regs are fully populated.

Regardless of what we're going to do, the underlying issue of callers passing
in partially inapplicable (to avoid calling it uninitialized) state remains,
...

>> For the purpose of FRED this doesn't matter much - wherever the values are to
>> be held, they'll be taken from by put_fpu().
> 
> I maybe wasn't clear.  To support FRED, I need to delete the vm86 fields.
> 
> @@ -54,10 +54,6 @@ struct cpu_user_regs
>      DECL_REG_LO16(flags); /* rflags.IF == !saved_upcall_mask */
>      DECL_REG_LO8(sp);
>      uint16_t ss, _pad2[3];
> -    uint16_t es, _pad3[3];
> -    uint16_t ds, _pad4[3];
> -    uint16_t fs, _pad5[3];
> -    uint16_t gs, _pad6[3];
> +    uint64_t edata, _rsvd;
>  };
>  
>  #undef DECL_REG_HI

... at least until your rework is in place. I did understand that you mean
to remove the struct fields. You made clear though that you'd re-introduce
them elsewhere (struct pv_vcpu) instead. And without (yet) recognizing the
staleness aspect I was implying we could read the values from there.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 07:56:30 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 07:56:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866073.1277343 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV4Rn-0004FL-BH; Tue, 07 Jan 2025 07:56:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866073.1277343; Tue, 07 Jan 2025 07:56:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV4Rn-0004FE-7u; Tue, 07 Jan 2025 07:56:19 +0000
Received: by outflank-mailman (input) for mailman id 866073;
 Tue, 07 Jan 2025 07:56: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 <SRS0=1r68=T7=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tV4Rm-0004F5-1n
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 07:56:18 +0000
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com
 [2a00:1450:4864:20::430])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id df1bd8d4-cccc-11ef-99a4-01e77a169b0f;
 Tue, 07 Jan 2025 08:56:16 +0100 (CET)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-385d7b4da2bso12879120f8f.1
 for <xen-devel@lists.xenproject.org>; Mon, 06 Jan 2025 23:56:16 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c846ca4sm50600894f8f.43.2025.01.06.23.56.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 06 Jan 2025 23:56:15 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: df1bd8d4-cccc-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736236575; x=1736841375; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=sZ8pJhAisSeXRzr/sec6vfVpCK3RZROX0EmSm6DYgRI=;
        b=Bu4tlyH9HMw1xYxkocpDqOG6855rtzOhtqNytonaM0b62IjLUMt+K4xPplS4HycTy6
         Q4HPFzeWMO0nLDMOcGpYY5hNxOBxqj7QnOJhwKoaznCrxTBncmGkjaywf+6ewjCt6sfy
         REi9DUw/1vCDTlJD0oAGWm1o6S4YXda6su0kLdUJCYg1HBv9WC+peajZxUvZGalf1jKU
         wUHt2nvNvCmibVEmUIHuok1e3K63Le3sh0gb1AVl+oeIq8rCwqkuc1ZHHI92W8y10UqD
         Fj0Gy7FcJE+FXtQA9gW3w8oBNDA6665VBAaF/ek9xciNf8x/RDb/90zpGX/aimpk84tb
         6WSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736236575; x=1736841375;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=sZ8pJhAisSeXRzr/sec6vfVpCK3RZROX0EmSm6DYgRI=;
        b=OUj2FavcdHxMYSD3z/SaE4JqX6aIpJmfpJWrNMrAFPfn7zR+iKnaKg8n4roaQMxPMc
         9WCDW0v7BNiIRkWBV2XF6wViAfVZ+SWlNRy9rcQleUAO/aAZwjJgTWVH5iX1ohOAl0gN
         GI/3tvadR96Udb06e/DKd/pAwaQUfsHtAEv+wZpnlxA/CuZAByxhnvl3vVt6oSWYadrZ
         3Hy+tHGzxEfRFsxesuRVl0MI4EtCe7FCkvyUvS9efZx7bwsFaCbNshJtRSwldV+CpL2w
         7mUybmcHj0O27M9O/hnEmxc8qRUNAriDt86PSx1SNgvmHVPAjsSXSmqrw0+lhTvtHNb8
         7RZQ==
X-Forwarded-Encrypted: i=1; AJvYcCXYjHRQcGWycpdZfPS7FFw0r2nfbiGCQXY44b4ZM5J4V3jIB5ECGhsuyExcAXSMYtdwsQwK/qg4164=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzE5/5XRxvvgOe9GnfiYnAAuTQKOudBjwFlEynoQMuHfbJtwlw8
	BiqCqPzchzLNr8h8RYSU/XwfHF1jhZ+w5vbpzYv7+l90BQnR/brMkxqp5zgrZw+A3YFUqG6RUI4
	=
X-Gm-Gg: ASbGncuGBNB0NNAcWGSqLlN36JM8E99oQHbIUQpeGudo82CZ/1fDnjbagxnnYbZwkAo
	ieBQn5NS8SKWUusLkiA0XskUqjd0u1W37jiQU/LqlCtGyD55ZEiInOP5RcBe43dEuMm2IUrB4YN
	144ttu5uMPAcphmrX0QUmISUfAdJvyQDmPXhYfbbjm3cufx1cOeHIiQEjSYpjRa4khEln7VP5RX
	ueY1K/aV7VK1Sd3s0H7rFr1tSDH00No3duyCDrbD48BhUcFdd1v8wjYa86Ua2qTDuvWt88y3e68
	h5K+3Dkc9W4+nQQ4JEXDWs6PqYCxW0GgHm/2WpfGYA==
X-Google-Smtp-Source: AGHT+IF1hMDTVebgHUuVEgYhuFlwpTzXeNj4hxEa4Dp2c5Rt3BOJt0BHLOo7k9j4Nh48CB2sDG/wXw==
X-Received: by 2002:a5d:47ab:0:b0:386:1ab5:f0e1 with SMTP id ffacd0b85a97d-38a221ea67fmr57490789f8f.14.1736236575686;
        Mon, 06 Jan 2025 23:56:15 -0800 (PST)
Message-ID: <0f8fc348-14f5-40ac-912a-1785caedb675@suse.com>
Date: Tue, 7 Jan 2025 08:56:14 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] xen: update pvcalls_front_accept prototype
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: jgross@suse.com, xen-devel@lists.xenproject.org,
 linux-kernel@vger.kernel.org
References: <alpine.DEB.2.22.394.2501061335161.133435@ubuntu-linux-20-04-desktop>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <alpine.DEB.2.22.394.2501061335161.133435@ubuntu-linux-20-04-desktop>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.01.2025 22:36, Stefano Stabellini wrote:
> xen: update pvcalls_front_accept prototype
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
> ---
> 
> Changes in v2:
> - also update pvcalls-front.c

The patch still gives the impression of being incomplete: There's no
caller of the function that you update. However, there's no such caller
in the first place. Why don't you just delete the function then?

Jan

> diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
> index b72ee9379d77..cab480059731 100644
> --- a/drivers/xen/pvcalls-front.c
> +++ b/drivers/xen/pvcalls-front.c
> @@ -769,7 +769,8 @@ int pvcalls_front_listen(struct socket *sock, int backlog)
>  	return ret;
>  }
>  
> -int pvcalls_front_accept(struct socket *sock, struct socket *newsock, int flags)
> +int pvcalls_front_accept(struct socket *sock, struct socket *newsock,
> +			 struct proto_accept_arg *arg)
>  {
>  	struct pvcalls_bedata *bedata;
>  	struct sock_mapping *map;
> @@ -788,7 +789,7 @@ int pvcalls_front_accept(struct socket *sock, struct socket *newsock, int flags)
>  		return -EINVAL;
>  	}
>  
> -	nonblock = flags & SOCK_NONBLOCK;
> +	nonblock = arg->flags & SOCK_NONBLOCK;
>  	/*
>  	 * Backend only supports 1 inflight accept request, will return
>  	 * errors for the others
> diff --git a/drivers/xen/pvcalls-front.h b/drivers/xen/pvcalls-front.h
> index f694ad77379f..881ef14660bc 100644
> --- a/drivers/xen/pvcalls-front.h
> +++ b/drivers/xen/pvcalls-front.h
> @@ -12,7 +12,7 @@ int pvcalls_front_bind(struct socket *sock,
>  int pvcalls_front_listen(struct socket *sock, int backlog);
>  int pvcalls_front_accept(struct socket *sock,
>  			 struct socket *newsock,
> -			 int flags);
> +			 struct proto_accept_arg *arg);
>  int pvcalls_front_sendmsg(struct socket *sock,
>  			  struct msghdr *msg,
>  			  size_t len);
> 



From xen-devel-bounces@lists.xenproject.org Tue Jan 07 08:20:23 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 08:20:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866091.1277352 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV4or-0000Bi-A2; Tue, 07 Jan 2025 08:20:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866091.1277352; Tue, 07 Jan 2025 08:20:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV4or-0000Bb-7U; Tue, 07 Jan 2025 08:20:09 +0000
Received: by outflank-mailman (input) for mailman id 866091;
 Tue, 07 Jan 2025 08:20:08 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=1r68=T7=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tV4oq-0000BV-0I
 for xen-devel@lists.xen.org; Tue, 07 Jan 2025 08:20:08 +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 337a5ff4-ccd0-11ef-a0df-8be0dac302b0;
 Tue, 07 Jan 2025 09:20:06 +0100 (CET)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-385df53e559so11921505f8f.3
 for <xen-devel@lists.xen.org>; Tue, 07 Jan 2025 00:20:06 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436612008b1sm585836795e9.15.2025.01.07.00.20.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 00:20:04 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 337a5ff4-ccd0-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736238005; x=1736842805; darn=lists.xen.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:cc
         :content-language:references:to:subject:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=3SAzjJU45zokvdIvr/YBIOeVDaVE6dnyKjwDMBCfDmQ=;
        b=SvDKiZsFfFUcdc8SqcKL7TC0d7Ll8pBUfGdnnuBpHYqfzqaU4lrrqW/omtnFla9UmW
         MJYJAxDI7antlh0OAbh7CyF1ZmZOnFmuS+aibQx+63BAJ0mGm/K8emZR1/OI8DpOsY9+
         0H4zbU6l1WKsw18tfRNDHELoRmhYCwvCMbGk5fmV9pUS8+XW2Qfi8esLR1/i7sJZYGjR
         J2haXkmLRmuayfQo51Ml8jrTsvQFcu+CHHr/SCW0KVq0t7kUcVrOILOWFu2JMXODchtv
         F25zXrYQyLic2O+eM0t181sATYI2Q2rAqCg4q8Z1HqPXnmXm8t9K14CYTxNCgQP3BJD2
         ApZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736238005; x=1736842805;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:cc
         :content-language:references:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=3SAzjJU45zokvdIvr/YBIOeVDaVE6dnyKjwDMBCfDmQ=;
        b=KwOZiqwDVver38okwR0UIHKTQ694Zu6SlTYAEU8PDy0MVmNNoXTqGICSJyLt1IrzsS
         zwWtOD1iG5oNBdHFXX/gwLUZTvqHNzz1m0Y1HHYX4HPPjIMOknJF35QzUk1/jeYN1bVK
         4kyPo0XEAUTBsrZsvrEbA4lLB/gZ/jhs/iUYuHg0PDPu2OQQi0U/4RxLfjxaPd0xo/z3
         LbZNzPU0ozM+vW/trGFXOJ81Q8Os+TvxzJtVumXhMTel93Wwbmgsi7NZoacWrWUDLTuB
         qxigKf3uY/wpzm31ul/+R0/H1nD3JAPsznhh+MpSAPYmcKuR8Vmhk3AyXswIDuwCXdiT
         M3PA==
X-Forwarded-Encrypted: i=1; AJvYcCUTlxMJkXDP1BBb8Dp9RSDLv0Ih8L7iT5zmJdYYx6ihaLpBKN8sXr8UKnXa8LN9+8Snnd40cQiU6kk=@lists.xen.org
X-Gm-Message-State: AOJu0YwhTFNwsr2492G2RuMcppjo+zclKwLJBHbzYL5n/p9iHmHMfn8x
	b4WqXj/DdZMfZi09ef0HYBi5xN+AW7A3GzXp1N8JzERo07WdEZ+dqYrfQJny7A==
X-Gm-Gg: ASbGncvVWH/amJjo/ByKTRb2kVyM7LDd+ZAwAUHI/DnLO32uBGbbxVRwszsMGyHNhIw
	AcqgL5guCHDkDo2iSEBRglbCI0JP579q2BrFy5BPJx92vgWTRjxIuNAk8s8B+sLvrVF3XWMbO+F
	oPDHU3I8aAlJ0+bVahpEdXQ3PjNU5vOVIhDTgboWgy1YLE+xw9EJ7ZWjoohvLdv1XHWrvIpYZnj
	SyUWg7n9h/qjw1S/eRId/IWamPyfqM/crvTYx5nHFPfSZosmDH0FwfaQNQQsQzJxQyMs3+HFf9W
	pSJge1qXdTTi1jryhl/qjSxjs7bpJSIGKzSwf852tA==
X-Google-Smtp-Source: AGHT+IFBJ/sppT+eSbPG87lzQnG5tumQBfCAp04l9XFxNwALIh7UxBMqrWwRlPcvCARCrH2pdcfNqA==
X-Received: by 2002:a5d:64a3:0:b0:385:f527:be6d with SMTP id ffacd0b85a97d-38a2240074fmr50270317f8f.36.1736238005589;
        Tue, 07 Jan 2025 00:20:05 -0800 (PST)
Message-ID: <a9ee291f-469b-418c-8936-789849714ff3@suse.com>
Date: Tue, 7 Jan 2025 09:20:03 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Xen Security Advisory 466 v3 (CVE-2024-53241) - Xen hypercall
 page unsafe against speculative attacks
To: David Woodhouse <dwmw2@infradead.org>
References: <E1tNWXG-00E268-2p@xenbits.xenproject.org>
 <54c892eded2b4ebdda8ee1085c383178f44414ad.camel@infradead.org>
 <a3031e7d-fe9d-4db8-8ccd-923165c9af72@suse.com>
 <fc4c45ea86567ef0c46d7e5a20e8abffa75cc4ec.camel@infradead.org>
 <fd993f8d-280f-439a-a6a0-506e2815f281@suse.com>
 <b7323a9fa5239443b9b6f3daa423196de1051748.camel@infradead.org>
 <40734e79-fb55-4712-aae1-3ef350af4f3c@suse.com>
 <f9b4ae8af70b8b5136b59237c7925f57220b3d5b.camel@infradead.org>
 <fc4170ed-d238-4e1c-817e-3695a7112d9d@suse.com>
 <ffea2b8edd4455b8d04a3c25afaaffc98ed40540.camel@infradead.org>
Content-Language: en-US
Cc: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
 xen-devel@lists.xen.org
From: Jan Beulich <jbeulich@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: <ffea2b8edd4455b8d04a3c25afaaffc98ed40540.camel@infradead.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 06.01.2025 18:19, David Woodhouse wrote:
> On Thu, 2025-01-02 at 15:16 +0100, Jürgen Groß wrote:
>> On 02.01.25 15:06, David Woodhouse wrote:
>>> On Thu, 2025-01-02 at 15:02 +0100, Jürgen Groß wrote:
>>>>> Are you suggesting that you're able to enable the CPU-specific CFI
>>>>> protections before you even know whether it's an Intel or AMD CPU?
>>>>
>>>> Not before that, but maybe rather soon afterwards. And the hypercall page
>>>> needs to be decommissioned before the next hypercall is happening. The question
>>>> is whether we have a hook in place to do that switch between cpu identification
>>>> and CFI enabling.
>>>
>>> Not sure that's how I'd phrase it. Even if we have to add a hook at the
>>> right time to switch from the Xen-populated hypercall page to the one
>>> filled in by Linux, the question is whether adding that hook is simpler
>>> than all this early static_call stuff that's been thrown together, and
>>> the open questions about the 64-bit latching.
>>
>> This is a valid question, yes. My first version of these patches didn't
>> work with static_call, but used the paravirt call patching mechanism
>> replacing an indirect call with a direct one via ALTERNATIVEs. That
>> version was disliked by some involved x86 maintainers, resulting in the
>> addition of the early static_call update mechanism.
>>
>> One thing to mention regarding the 64-bit latching: what would you do
>> with HVM domains? Those are setting up the hypercall page rather late.
>> In case the kernel would use CFI, enabling would happen way before the
>> guest would issue any hypercall, so I guess the latching needs to happen
>> by other means anyway. Or would you want to register the hypercall page
>> without ever intending to use it?
> 
> With xen_no_vector_callback on the command line, the hypervisor doesn't
> realise that the guest is 64-bit until long after all the CPUs are
> brought up.
> 
> It does boot (and hey, QEMU does get this right!) but I'm still
> concerned that all those shared structures are 32-bit for that long. I
> do think the guest kernel should either set the hypercall page, or
> HVM_PARAM_CALLBACK_IRQ, as early as possible.

How about we adjust the behavior in Xen instead: We could latch the size
on every hypercall, making sure to invoke update_domain_wallclock_time()
only when the size actually changed (to not incur the extra overhead),
unless originating from the two places the latching is currently done at
(to avoid altering existing behavior)?

Then again latching more frequently (as suggested above or by any other
model) also comes with the risk of causing issues, at the very least for
"exotic" guests. E.g. with two vCPU-s in different modes, we'd ping-pong
the guest between both formats then.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 08:23:54 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 08:23:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866099.1277363 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV4sS-0000rY-QO; Tue, 07 Jan 2025 08:23:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866099.1277363; Tue, 07 Jan 2025 08:23:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV4sS-0000rR-NM; Tue, 07 Jan 2025 08:23:52 +0000
Received: by outflank-mailman (input) for mailman id 866099;
 Tue, 07 Jan 2025 08:23:52 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=V2Xg=T7=casper.srs.infradead.org=BATV+f031519a9170f34b3d42+7807+infradead.org+dwmw2@srs-se1.protection.inumbo.net>)
 id 1tV4sR-0000rI-64
 for xen-devel@lists.xen.org; Tue, 07 Jan 2025 08:23:52 +0000
Received: from casper.infradead.org (casper.infradead.org
 [2001:8b0:10b:1236::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b85ee397-ccd0-11ef-99a4-01e77a169b0f;
 Tue, 07 Jan 2025 09:23:49 +0100 (CET)
Received: from [54.240.197.232] (helo=u09cd745991455d.ant.amazon.com)
 by casper.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux))
 id 1tV4sO-00000004uIf-19aa; Tue, 07 Jan 2025 08:23:48 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b85ee397-ccd0-11ef-99a4-01e77a169b0f
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:Cc:To:From:Subject:Message-ID:Sender:Reply-To:
	Content-Transfer-Encoding:Content-ID:Content-Description;
	bh=9tb0LnxCSlS+al3RCiFGC34RDZdyBbfsqUfZPQDvbUQ=; b=HmGnQrL3uGjgtV/kcFRi6PFvuv
	tWggxPM6bKU5llWBljK0yBLBUG3DBoX+io9d1ZZx9tgZ7kw1LUoiAN/vzbyMMejfVNJKzdoUjeEJM
	p9Dg9U7s5lLzx3breRXdY1gs0JG/u7lPDGlo/AgkURddttifrGhun+5NxbZy1uqyex9rMU/ERRVmV
	a9IrWPFg/9IVcdCJWgv7rQ1Q9MeNUccFFX4psLMNv6hAnWogfGv4KZPVvRsYQkkJhQjTsXsJPad4k
	ZqHtHX+YQNoJWtuQa6oAhmnn7XhDKbjSY1fzy30ovLiQPLc4hDmWzGtTefu/paXb1jwnWL7H0eDri
	ea6G+ACA==;
Message-ID: <b8ab443fc7cfc2043088a8c390546fc8d181ab18.camel@infradead.org>
Subject: Re: Xen Security Advisory 466 v3 (CVE-2024-53241) - Xen hypercall
 page unsafe against speculative attacks
From: David Woodhouse <dwmw2@infradead.org>
To: Jan Beulich <jbeulich@suse.com>
Cc: =?ISO-8859-1?Q?J=FCrgen_Gro=DF?= <jgross@suse.com>, 
	xen-devel@lists.xen.org
Date: Tue, 07 Jan 2025 08:23:47 +0000
In-Reply-To: <a9ee291f-469b-418c-8936-789849714ff3@suse.com>
References: <E1tNWXG-00E268-2p@xenbits.xenproject.org>
	 <54c892eded2b4ebdda8ee1085c383178f44414ad.camel@infradead.org>
	 <a3031e7d-fe9d-4db8-8ccd-923165c9af72@suse.com>
	 <fc4c45ea86567ef0c46d7e5a20e8abffa75cc4ec.camel@infradead.org>
	 <fd993f8d-280f-439a-a6a0-506e2815f281@suse.com>
	 <b7323a9fa5239443b9b6f3daa423196de1051748.camel@infradead.org>
	 <40734e79-fb55-4712-aae1-3ef350af4f3c@suse.com>
	 <f9b4ae8af70b8b5136b59237c7925f57220b3d5b.camel@infradead.org>
	 <fc4170ed-d238-4e1c-817e-3695a7112d9d@suse.com>
	 <ffea2b8edd4455b8d04a3c25afaaffc98ed40540.camel@infradead.org>
	 <a9ee291f-469b-418c-8936-789849714ff3@suse.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-AVQwoBwLw2zF4971DSs+"
User-Agent: Evolution 3.52.3-0ubuntu1 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html


--=-AVQwoBwLw2zF4971DSs+
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2025-01-07 at 09:20 +0100, Jan Beulich wrote:
>=20
> How about we adjust the behavior in Xen instead: We could latch the size
> on every hypercall, making sure to invoke update_domain_wallclock_time()
> only when the size actually changed (to not incur the extra overhead),
> unless originating from the two places the latching is currently done at
> (to avoid altering existing behavior)?
>
> Then again latching more frequently (as suggested above or by any other
> model) also comes with the risk of causing issues, at the very least for
> "exotic" guests. E.g. with two vCPU-s in different modes, we'd ping-pong
> the guest between both formats then.

Indeed. I think it's much better for the guest to just write to the
hypercall page MSR early, like it always did. It doesn't even *need* to
be an executable page; just a data page which is then
freed/overwritten.

But if we *want* to use it during early boot so that we don't need all
that early CPU detection and static_call complexity, that's fine too.

--=-AVQwoBwLw2zF4971DSs+
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD9Aw
ggSOMIIDdqADAgECAhAOmiw0ECVD4cWj5DqVrT9PMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0yNDAxMzAwMDAwMDBaFw0zMTEx
MDkyMzU5NTlaMEExCzAJBgNVBAYTAkFVMRAwDgYDVQQKEwdWZXJva2V5MSAwHgYDVQQDExdWZXJv
a2V5IFNlY3VyZSBFbWFpbCBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMjvgLKj
jfhCFqxYyRiW8g3cNFAvltDbK5AzcOaR7yVzVGadr4YcCVxjKrEJOgi7WEOH8rUgCNB5cTD8N/Et
GfZI+LGqSv0YtNa54T9D1AWJy08ZKkWvfGGIXN9UFAPMJ6OLLH/UUEgFa+7KlrEvMUupDFGnnR06
aDJAwtycb8yXtILj+TvfhLFhafxroXrflspavejQkEiHjNjtHnwbZ+o43g0/yxjwnarGI3kgcak7
nnI9/8Lqpq79tLHYwLajotwLiGTB71AGN5xK+tzB+D4eN9lXayrjcszgbOv2ZCgzExQUAIt98mre
8EggKs9mwtEuKAhYBIP/0K6WsoMnQCcCAwEAAaOCAVwwggFYMBIGA1UdEwEB/wQIMAYBAf8CAQAw
HQYDVR0OBBYEFIlICOogTndrhuWByNfhjWSEf/xwMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6en
IZ3zbcgPMA4GA1UdDwEB/wQEAwIBhjAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIweQYI
KwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYIKwYB
BQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RD
QS5jcnQwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0
QXNzdXJlZElEUm9vdENBLmNybDARBgNVHSAECjAIMAYGBFUdIAAwDQYJKoZIhvcNAQELBQADggEB
ACiagCqvNVxOfSd0uYfJMiZsOEBXAKIR/kpqRp2YCfrP4Tz7fJogYN4fxNAw7iy/bPZcvpVCfe/H
/CCcp3alXL0I8M/rnEnRlv8ItY4MEF+2T/MkdXI3u1vHy3ua8SxBM8eT9LBQokHZxGUX51cE0kwa
uEOZ+PonVIOnMjuLp29kcNOVnzf8DGKiek+cT51FvGRjV6LbaxXOm2P47/aiaXrDD5O0RF5SiPo6
xD1/ClkCETyyEAE5LRJlXtx288R598koyFcwCSXijeVcRvBB1cNOLEbg7RMSw1AGq14fNe2cH1HG
W7xyduY/ydQt6gv5r21mDOQ5SaZSWC/ZRfLDuEYwggWbMIIEg6ADAgECAhAH5JEPagNRXYDiRPdl
c1vgMA0GCSqGSIb3DQEBCwUAMEExCzAJBgNVBAYTAkFVMRAwDgYDVQQKEwdWZXJva2V5MSAwHgYD
VQQDExdWZXJva2V5IFNlY3VyZSBFbWFpbCBHMjAeFw0yNDEyMzAwMDAwMDBaFw0yODAxMDQyMzU5
NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqGSIb3DQEBAQUAA4IC
DwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZeYAS/SRV6zmfXlXaZ
sNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2zkC9S7/yHDYnqegqt
w4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qGpgFdZEk2/c//ZvUN
i12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41vav1RhZJzYan4a1gU0
kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0cvnO8FM6PTqsnSbcc
0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PWPU6zfQTOMZ9uLQRR
ci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXtREF5lLXxp+CJ6KKS
blPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQrlR0gO3lBzuyPPArV
hvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7IqaAovAX0d+f1YjbmC
VsAwjhLmveFjNwIDAQABo4IBsDCCAawwHwYDVR0jBBgwFoAUiUgI6iBOd2uG5YHI1+GNZIR//HAw
HQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3bXcyQGluZnJhZGVh
ZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEBMA4GA1UdDwEB/wQE
AwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwewYDVR0fBHQwcjA3oDWgM4YxaHR0
cDovL2NybDMuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNybDA3oDWgM4YxaHR0
cDovL2NybDQuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNybDB2BggrBgEFBQcB
AQRqMGgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBABggrBgEFBQcwAoY0
aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNydDANBgkq
hkiG9w0BAQsFAAOCAQEAQXc4FPiPLRnTDvmOABEzkIumojfZAe5SlnuQoeFUfi+LsWCKiB8Uextv
iBAvboKhLuN6eG/NC6WOzOCppn4mkQxRkOdLNThwMHW0d19jrZFEKtEG/epZ/hw/DdScTuZ2m7im
8ppItAT6GXD3aPhXkXnJpC/zTs85uNSQR64cEcBFjjoQDuSsTeJ5DAWf8EMyhMuD8pcbqx5kRvyt
JPsWBQzv1Dsdv2LDPLNd/JUKhHSgr7nbUr4+aAP2PHTXGcEBh8lTeYea9p4d5k969pe0OHYMV5aL
xERqTagmSetuIwolkAuBCzA9vulg8Y49Nz2zrpUGfKGOD0FMqenYxdJHgDCCBZswggSDoAMCAQIC
EAfkkQ9qA1FdgOJE92VzW+AwDQYJKoZIhvcNAQELBQAwQTELMAkGA1UEBhMCQVUxEDAOBgNVBAoT
B1Zlcm9rZXkxIDAeBgNVBAMTF1Zlcm9rZXkgU2VjdXJlIEVtYWlsIEcyMB4XDTI0MTIzMDAwMDAw
MFoXDTI4MDEwNDIzNTk1OVowHjEcMBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzCCAiIwDQYJ
KoZIhvcNAQEBBQADggIPADCCAgoCggIBANqWLse95HW2F7FhfH9bugyT/danKmmXrbMnz5GZNAfj
Jl5gBL9JFXrOZ9eVdpmw04Tp6aDxZctFLoEDvSWKi367Q7Sg+ci+fH4KwwfQ8Pi0IpIKx2n5emEg
nbOQL1Lv/IcNiep6Cq3DiyaSpSp/RZf+CAfUNySHS8eWmhLU6jGpSD6hxTpYKye7PmrmvMWwfGEP
WoamAV1kSTb9z/9m9Q2LXa89aKmTxNwnAfD3Ohn9mtU3JukwILRMewn9QRXK7KzM+01h5hkCE4nj
W9q/VGFknNhqfhrWBTSQoE9CSVylASGrjzCgS7XmKy/BaH3/7mOOHQv5g1o3Qj/+cdKnpT0I5Qb1
nRy+c7wUzo9OqydJtxzSP4ZyHA4dELto/a3m/ay1XHcpum1pgTOLgxAfGb/T4dCkwRUstSKLMmpL
g9Y9TrN9BM4xn24tBFFyL5znGG0wQGzOVAM68RBzIQb6Fz758fjsr4yZnPbVsU1+gHEs/puNHrG0
9e1EQXmUtfGn4InoopJuU8p5VGD9S3Ikd4UoBlc7xl5yjtNlQxUeYrRlnUSmdlucCEoTX1n4UmtA
9CuVHSA7eUHO7I88CtWG9bGOU7tLgOZoSEvNqtaL/N7sQbBZK4jZ4Rr/zNTQg1SwYjjLB7u96lDP
sipoCi8BfR35/ViNuYJWwDCOEua94WM3AgMBAAGjggGwMIIBrDAfBgNVHSMEGDAWgBSJSAjqIE53
a4blgcjX4Y1khH/8cDAdBgNVHQ4EFgQUXGIam3Bs59Y60yTmWgfDu6pZQ6cwMAYDVR0RBCkwJ4ET
ZHdtdzJAaW5mcmFkZWFkLm9yZ4EQZGF2aWRAd29vZGhvdS5zZTAUBgNVHSAEDTALMAkGB2eBDAEF
AQEwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDB7BgNVHR8E
dDByMDegNaAzhjFodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVtYWlsRzIu
Y3JsMDegNaAzhjFodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVtYWlsRzIu
Y3JsMHYGCCsGAQUFBwEBBGowaDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29t
MEAGCCsGAQUFBzAChjRodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVt
YWlsRzIuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQBBdzgU+I8tGdMO+Y4AETOQi6aiN9kB7lKWe5Ch
4VR+L4uxYIqIHxR7G2+IEC9ugqEu43p4b80LpY7M4KmmfiaRDFGQ50s1OHAwdbR3X2OtkUQq0Qb9
6ln+HD8N1JxO5nabuKbymki0BPoZcPdo+FeRecmkL/NOzzm41JBHrhwRwEWOOhAO5KxN4nkMBZ/w
QzKEy4PylxurHmRG/K0k+xYFDO/UOx2/YsM8s138lQqEdKCvudtSvj5oA/Y8dNcZwQGHyVN5h5r2
nh3mT3r2l7Q4dgxXlovERGpNqCZJ624jCiWQC4ELMD2+6WDxjj03PbOulQZ8oY4PQUyp6djF0keA
MYIDuzCCA7cCAQEwVTBBMQswCQYDVQQGEwJBVTEQMA4GA1UEChMHVmVyb2tleTEgMB4GA1UEAxMX
VmVyb2tleSBTZWN1cmUgRW1haWwgRzICEAfkkQ9qA1FdgOJE92VzW+AwDQYJYIZIAWUDBAIBBQCg
ggE3MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTI1MDEwNzA4MjM0
N1owLwYJKoZIhvcNAQkEMSIEIOdxGVogBPrQrvSE1eor0NaFfvd6gTTH7oqTfRD1QYIiMGQGCSsG
AQQBgjcQBDFXMFUwQTELMAkGA1UEBhMCQVUxEDAOBgNVBAoTB1Zlcm9rZXkxIDAeBgNVBAMTF1Zl
cm9rZXkgU2VjdXJlIEVtYWlsIEcyAhAH5JEPagNRXYDiRPdlc1vgMGYGCyqGSIb3DQEJEAILMVeg
VTBBMQswCQYDVQQGEwJBVTEQMA4GA1UEChMHVmVyb2tleTEgMB4GA1UEAxMXVmVyb2tleSBTZWN1
cmUgRW1haWwgRzICEAfkkQ9qA1FdgOJE92VzW+AwDQYJKoZIhvcNAQEBBQAEggIAI9NMGw2rVbU7
9H2McZVi5yc9fgg36mETpEeeCFj5hxbzOUr8J2DIC4a5E2n+HnUoH2qglQCMKw6la/vj3WIG7BZm
xV4EDtg4n7l+Lk41bXNA4Awc5/3aQhSu9oPZzGykNpOq99xThbI8Bpy5A0sW1SyJWjBNuOM1gSUm
2s9jcvWDRugS+QbBahbCtcg6ALZGrQfhTsu69vRqZzHGNgenGpnAhK+qwt0MytEE8ENTKaQqnOHu
s7YS6xKfKmutUEK7kZcQugTev7Z9Hvm64P0uzGBNkuGyLcOS3U0JWawhNg5vyRexX9jQ8MBECPLJ
BwSBf8T7zTXCpyiJJS20c5N7VIVvqMZ2D37Ao0Qr1QzCcHV6K74WUhSei/AUlCEXf89sU5JAmyPP
/tRY4t1Qus+bnVI67BnvsTRFvPlGOQS0Ea0Jinb9mQkfBZBsvz0Cw6f3y8966M29+tA0DJ5NYJMY
oYLnEX8ZAAD/Ef1a54p4xo2OQhcxHsG/iSya+h7Ip+4W7gn1gVjUBPgpxzlk82/zmrOQXh9v/pP8
7GpXmVUXp4K0O8x+rVmcNTtz/DF7fRj/2rkWeM6ywCl+bT1ejy5NDtYOjR9JWSMhCSpoSFBhq8Fr
R4RDMxHQNGNoJWfISpdv53s5DYzC78DLauhENZcUc7jVo0VGTtVm5BQp93HGuOwAAAAAAAA=


--=-AVQwoBwLw2zF4971DSs+--


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 08:32:15 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 08:32:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866105.1277372 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV50U-0002Vb-Hj; Tue, 07 Jan 2025 08:32:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866105.1277372; Tue, 07 Jan 2025 08:32:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV50U-0002VU-FC; Tue, 07 Jan 2025 08:32:10 +0000
Received: by outflank-mailman (input) for mailman id 866105;
 Tue, 07 Jan 2025 08:32:09 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=1r68=T7=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tV50T-0002VO-LF
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 08:32:09 +0000
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com
 [2a00:1450:4864:20::331])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e188ff24-ccd1-11ef-99a4-01e77a169b0f;
 Tue, 07 Jan 2025 09:32:07 +0100 (CET)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-4361f796586so156835175e9.3
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 00:32:07 -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
 5b1f17b1804b1-43656b41904sm623362425e9.37.2025.01.07.00.32.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 00:32:06 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e188ff24-ccd1-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736238727; x=1736843527; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Eo9whzbYs+xwvu152KCtyJBkghoKuUrucsSey4z13t8=;
        b=GYVZVZaRvgoqr2S4eyubG6CiJ1PLzGPAVzGlp21lKATpu7xrxP+mA+hLdzo0c3NQp2
         sjk8Fq0eNY/XnpfulPuA2jS+cReOdrhVN6ZS6J7jU4OqCo41DkTm2vKMI9PAPtWkzDPg
         8ozmSbrYe4M3uzhsjJGEUG7yRcvGIT9FToV8Djv1l7/4/SXitOE31uzhjZ0PoPFWxuUs
         los2Y+u4+soxL6u8kR6Af4KU88/6znBW0H/Ep376PB75Jc/gq3a0mmKUjwrrh2UIBfz1
         aI8xhm3Bb4DIqEu3u6bTtTkxBZKgRgh7jCEcZS2+m/qL05Scrf+p2snItLO8b8Fahl4D
         OutA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736238727; x=1736843527;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Eo9whzbYs+xwvu152KCtyJBkghoKuUrucsSey4z13t8=;
        b=rlaeojFsMH3JaTnq2LZenehQjEzu1HcsX0uJhkFYburiBwWYLZFMGBQwDRWxEkZbX5
         10Ma4nfKrkcEDaCFNbbmvX8xlXcAlUF40hsI+htCQWn2XE9jCv3ZE/TZrSD5KK/ISupE
         lF9alDAUBNuhpdoJFQ7akYGW8seBoUVCuDIl4moFAoQQOyxx8yMP6fU+wckxu72SG64U
         3YpwiB5eCc+P9m/tHK42KmYQQ+JL6cUA7z8RzXkZqBqYX7p8F8WApowlKWBh3VjuFBHj
         MSRCX6qRCgaZAtNNqKpJpch0gNlV/GWkuB4VUANZBxPRqqvPgW4Q1xbhDwllnHeFQW4t
         BODA==
X-Forwarded-Encrypted: i=1; AJvYcCU2bGyIQon3y7JqIlV1Ah7t9lOSy5xicpnFvoKzVLoSJfsnwie6jgPLmoj3tt7HiPvLIREExnANUfM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzWnMZg06idKTn2UFsPuwEFugIq4b/5Dw/YEfy/lxoIRepUSCm6
	6SdSHfiNcFY63fHIExHymotdHJaWupKcyhjArZWAEXTi344W+mj+mEQW1ck+9w==
X-Gm-Gg: ASbGnctywe9H6sKCb2RYfgT6c+HjwWbKSz6A1KFt3KMNzJlZcZMwL6aF+zGllyHzZC9
	seHZ/hmgxC6iClxfiP0kuHdBEdvrx/9PoT82kwv1fMxsnPRbZ+d9B5o37/bDozCVtcQGSzwKFOq
	AsRxKyOvZ/w2zTnwKF7qI5/xGfXtm71rC6Uu03jJ4iWaDeUdpNr4wLPbHU0aQV4OgSp+vQh5uZE
	MlnP8+ansDf90OoEpN4JQZNqln6obIH2PwFcIrnImN1vPzQNsOuUw4qzkFd2riTXxR8NKcFLFYY
	fjqe8e1rgu6UzRP6Q4iTCnFokHMUWslOobc1oI4L7A==
X-Google-Smtp-Source: AGHT+IGBJV+YNezSebK3u/pX0110Bvm734YnFG53U4mxY9m+GYT3OJuqi48IE1yYLLOi0d7BRp+ulQ==
X-Received: by 2002:a05:600c:1c25:b0:434:f4fa:83c4 with SMTP id 5b1f17b1804b1-43668b5f691mr498863395e9.29.1736238727124;
        Tue, 07 Jan 2025 00:32:07 -0800 (PST)
Message-ID: <9f1d070b-c135-454d-8022-12104e048458@suse.com>
Date: Tue, 7 Jan 2025 09:32:05 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20] public/version: soften wording for deprecated
 sub-ops
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Oleksii Kurochko <oleksii.kurochko@gmail.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <bf8cc342-52aa-44ee-8bce-ce2be6406904@suse.com>
 <0c8a13d0-04d7-4ed6-a8d8-a4423867fa3f@citrix.com>
 <8ca8ac20-a19f-49ef-9631-08cdcef854d2@suse.com>
 <alpine.DEB.2.22.394.2501061229300.133435@ubuntu-linux-20-04-desktop>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <alpine.DEB.2.22.394.2501061229300.133435@ubuntu-linux-20-04-desktop>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.01.2025 23:01, Stefano Stabellini wrote:
> On Mon, 6 Jan 2025, Jan Beulich wrote:
>> On 06.01.2025 12:08, Andrew Cooper wrote:
>>> On 06/01/2025 11:04 am, Jan Beulich wrote:
>>>> These interfaces were - afaict - originally introduced this way on the
>>>> firm assumption that the used array sizes would be good virtually
>>>> forever.  While this assumption turned out to not be true for at least
>>>> some of them, this still doesn't really render them "broken": They still
>>>> fit their original purpose, and they are still usable for a fair subset
>>>> of environments.  Re-word the comments accordingly.
>>>>
>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>
>>> No.
>>>
>>> The community voted and rejected this opinion.
>>
>> That's not my recollection of what was voted on, and with the vote results
>> not being available referring to them is unhelpful anyway.
>>
>> My (admittedly vague) recollection is that it was decided to leave enough
>> room for wording choice by submitters. That would cover your original
>> patch, and it would equally cover mine.
> 
> The community-wide survey indicated that it is acceptable to use the
> term "broken" in our documentation [1]. While the survey was not tied to
> a specific instance, it was undoubtedly influenced by the ongoing
> discussion at the time.

IOW this re-confirms (to me at least) that the vote in itself was ambiguous.
I have no issue at all with the use of the word "broken" in documentation or
code comments, provided this accurately describes the situation. Which it
doesn't here.

> If the purpose of this patch is to replace the term "broken", as it
> would seem from the commit message, I would recommend dropping the patch
> and leaving the wording as it is, given that the community has expressed
> approval of its use. Let us respect that decision.
> 
> However, if the goal is to improve clarity by specifying "due to its
> size limitations" and noting that the truncation occurs "silently", then
> I believe the patch could be reviewed with that objective in mind.
> 
> In other words, we should not replace "broken" simply for the sake of
> doing so. That discussion has already been settled. When reviewing this
> patch, our focus should be on its other merits, if any.
> 
> Based on the above, I would not take the patch in its current form. But
> if Jan is up for rewording the commit message, and focusing purely on
> the clarity of the in-code comments maybe a future version could be
> acceptable.

Assuming the above doesn't change your view, and assuming no-one else is
going to express views in favor of the wording change, I'll consider the
patch rejected. And I'll be once again left with the impression that
things are treated neither equally nor objectively in situations like this
one: To get one's perspective through unaltered one only needs to resist
hard enough to any attempt to find a middle ground. That's not a good
environment to work in, and not something I'd call a "community".

Jan

> [1] https://cryptpad.fr/form/#/2/form/view/7ByH95Vd7KiDOvN4wjV5iUGlMuZbkVdwk7cYpZdluWo/



From xen-devel-bounces@lists.xenproject.org Tue Jan 07 08:38:07 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 08:38:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866115.1277383 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV569-0003Aq-9H; Tue, 07 Jan 2025 08:38:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866115.1277383; Tue, 07 Jan 2025 08:38:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV569-0003Aj-6b; Tue, 07 Jan 2025 08:38:01 +0000
Received: by outflank-mailman (input) for mailman id 866115;
 Tue, 07 Jan 2025 08:37:59 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=1r68=T7=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tV567-0003Ad-F7
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 08:37:59 +0000
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com
 [2a00:1450:4864:20::434])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b262c1aa-ccd2-11ef-a0df-8be0dac302b0;
 Tue, 07 Jan 2025 09:37:58 +0100 (CET)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-385e27c75f4so10942026f8f.2
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 00:37:58 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436611ea387sm596268605e9.6.2025.01.07.00.37.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 00:37:57 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b262c1aa-ccd2-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736239077; x=1736843877; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=KbKs+W0RntRsoWrSaFzkuGq0iYhfflCE8MYl6byIj9Y=;
        b=Y/4l+IPZitgQH2Fz+IhiiVjbvABbm8QGFDkWFTTry99of8sFdktpvKkGfgwG5aZeWP
         VruwlkB7UOQWJFgp2tWqgVbgGt8qmOsS6ynPkeUwBVpFuzDZe9CKPh2CVZrnud94EGAJ
         5ekykll/D6wXtAjlz6X3I+fze29n+MPIq987LkHcUEYIchGw5X5Xh7WjX5nt2TnIHdyf
         1DXji/1rDSoWDi5YxHUw5cU8BJ4Dd9hQSsdJzEUvZWUSlbmYzHIw16evRaLJ5ASvjJby
         xiCKsd/KXVfk9J0Sfoh849WGZG23b5uRDCh4ZIVuP9X/FE3tAvC/lWT58JLuUtAMmN+Z
         IxRQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736239077; x=1736843877;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=KbKs+W0RntRsoWrSaFzkuGq0iYhfflCE8MYl6byIj9Y=;
        b=vCHu+a1A4bzvsnSNSknyUrPFe9Gy0V7luBiClUA/eZA0v5TAS2ODF69r0kitW+iK5j
         g9Xj4xbNSz0pszUYyDpT3DJR4aXAS2/1r0eN9iEdOekmc+B8jIiQRKRJx0ikYpu/viRQ
         PQeFCJe4SC34G5a1iiq82YhGYD7LH9oLVNSGc0fgDeJ5PNHzLPGL2E43hFp0kMx+as5j
         eDoFh4gKyZwo8Fe7GEGud97c86QhNLIWE4tH0bYk0hOTUCUmC1puKxuzyGG2mt5wztLI
         CuegshTEsfpVLKr4c2fjiUtYaEzS/8hliFuN3WbKPOYvUdrkXony/pbqadmnktQBk4F3
         ggSw==
X-Forwarded-Encrypted: i=1; AJvYcCVJrXoexd/dcVaImyJ3fH5pGomkO2mmHQOJTK93dbdJtsicfd6+XKIt4ex2jCBZlZNpo68yBa6geQQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyOoo4AC2U2PS4X3zHnMkyE2orZuIuTYiNVwiAIWhMlta8u98N/
	hktG5OWr9mYWIy88ChXy1qE6rd/x/QiPaheRPUJd1SjvhPIVvYAGGqnm6lrGbg==
X-Gm-Gg: ASbGncstq5gvVxExrknImQd/mw3codX1fs7Xy15RU+BtDMKJ+kFPUgAWxiUeRzIOgsD
	LBDdl7MHbK0rMq2p/bDnRKJ0q04V/88lxkcMkLcs61wZrg3cACT11pZ+EMW4w0rc3nz3DDnk1hs
	uozF9yIFZ9bCG2yUIfyz7C58/NcQ/RNaoFrTj6TdHhCYzTt3PuSpnHrj0X12rLl01bx58zFE4va
	+CyIkFVl3zOhxKjXGmZ9277iNNnPg9As76F6Z9tRgKqGzXeSTRG4BXobymjG+c8ZsaTdKAs4nZA
	ZQFeNmRH0XjQ7tn2vu3QaBkFdTJ13xPjNkfeTfygSQ==
X-Google-Smtp-Source: AGHT+IG0vmTppxEsgz8G6IZFXT62bNiYG3xAYtHaYa2j/jlqWbImpSvB9JdCH3lLi1E1r6hnpbtR6g==
X-Received: by 2002:a5d:5f51:0:b0:385:dedb:a12f with SMTP id ffacd0b85a97d-38a221e27a4mr49780160f8f.6.1736239077531;
        Tue, 07 Jan 2025 00:37:57 -0800 (PST)
Message-ID: <a8b4601c-8c91-4b18-8b4a-2aa3f4655994@suse.com>
Date: Tue, 7 Jan 2025 09:37:55 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 19/35] xen/console: introduce console_set_owner()
To: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-19-e9aa923127eb@ford.com>
 <Z1q3COsFN3J9G60E@macbook.local>
 <Nzs8m4tgOs8mh44axM9sAfsp2GGMk34p5Oi0dtXh8rLbKzHXmMtMXK_d_AJy-gSQuGRygaZbsvhy9QFvsCc0yyMiqzXslUNID1os1CCzNrA=@proton.me>
 <3b9635bc-e196-4a7e-95ea-277172ae052a@suse.com>
 <WdwwQV5SUUes7R0BWeDutEQWGvnv_YSB8yc-jMeij_uOqMPVYTpAkpmojwppDdKmact1UU3eXZ61TMZZf7s3JKMlG8EnNEaCGbPbd_7Qo30=@proton.me>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <WdwwQV5SUUes7R0BWeDutEQWGvnv_YSB8yc-jMeij_uOqMPVYTpAkpmojwppDdKmact1UU3eXZ61TMZZf7s3JKMlG8EnNEaCGbPbd_7Qo30=@proton.me>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 06.01.2025 21:03, Denis Mukhin wrote:
> 
> On Monday, January 6th, 2025 at 1:58 AM, Jan Beulich <jbeulich@suse.com> wrote:
> 
>>
>>
>> On 04.01.2025 04:30, Denis Mukhin wrote:
>>
>>> On Thursday, December 12th, 2024 at 2:12 AM, Roger Pau Monné roger.pau@citrix.com wrote:
>>>
>>>> On Thu, Dec 05, 2024 at 08:41:49PM -0800, Denis Mukhin via B4 Relay wrote:
>>>>
>>>>> --- a/xen/drivers/char/console.c
>>>>> +++ b/xen/drivers/char/console.c
>>>>> @@ -463,82 +463,100 @@ static void cf_check dump_console_ring_key(unsigned char key)
>>>>>
>>>>> /*
>>>>> * CTRL-<switch_char> changes input direction, rotating among Xen, Dom0,
>>>>> - * and the DomUs started from Xen at boot.
>>>>> + * and the DomUs.
>>>>> /
>>>>> #define switch_code (opt_conswitch[0]-'a'+1)
>>>>> +
>>>>> /
>>>>> - * console_owner=0 => input to xen
>>>>> - * console_owner=1 => input to dom0 (or the sole shim domain)
>>>>> - * console_owner=N => input to dom(N-1)
>>>>> + * Current console owner domain ID: either Xen or domain w/ d->is_console ==
>>>>> + * true.
>>>>> + *
>>>>> + * Initialized in console_endboot().
>>>>> */
>>>>> -static unsigned int __read_mostly console_owner = 0;
>>>>> +static domid_t __read_mostly console_owner;
>>>>
>>>> Should this be initialized to DOMID_XEN? I assume it doesn't make
>>>> much difference because the variable is not checked before
>>>> console_endboot() anyway, but it might be safer to initialize to a
>>>> value that assigns the console to Xen.
>>>
>>> Fixed.
>>>
>>>>> -#define max_console_rx (max_init_domid + 1)
>>>>> +static struct domain *rcu_lock_domain_console_by_id(domid_t domid)
>>>>> +{
>>>>> + struct domain *d;
>>>>> +
>>>>> + d = rcu_lock_domain_by_id(domid);
>>>>> +
>>>>
>>>> Nit: I would remove this newline.
>>>
>>> Fixed.
>>>
>>>>> + if ( d == NULL )
>>>>> + return NULL;
>>>>> +
>>>>> + if ( d->is_console )
>>>>> + return d;
>>>>> +
>>>>> + rcu_unlock_domain(d);
>>>>> +
>>>>> + return NULL;
>>>>> +}
>>>>>
>>>>> -#ifdef CONFIG_SBSA_VUART_CONSOLE
>>>>> /* Make sure to rcu_unlock_domain after use */
>>>>> struct domain *rcu_lock_domain_console_owner(void)
>>>>> {
>>>>> - if ( console_owner == 0 )
>>>>> - return NULL;
>>>>> - return rcu_lock_domain_by_id(console_owner - 1);
>>>>> + return rcu_lock_domain_console_by_id(console_owner);
>>>>> }
>>>>> -#endif
>>>>>
>>>>> -static void console_find_owner(void)
>>>>> +static bool console_owner_possible(domid_t domid)
>>>>> {
>>>>> - unsigned int next_rx = console_owner;
>>>>> -
>>>>> - /*
>>>>> - * Rotate among Xen, dom0 and boot-time created domUs while skipping
>>>>> - * switching serial input to non existing domains.
>>>>> - /
>>>>> - for ( ; ; )
>>>>> - {
>>>>> - domid_t domid;
>>>>> - struct domain d;
>>>>> -
>>>>> - if ( next_rx++ >= max_console_rx )
>>>>> - {
>>>>> - console_owner = 0;
>>>>> - printk("* Serial input to Xen");
>>>>> - break;
>>>>> - }
>>>>> -
>>>>> - if ( consoled_is_enabled() && next_rx == 1 )
>>>>> - domid = get_initial_domain_id();
>>>>> - else
>>>>> - domid = next_rx - 1;
>>>>> -
>>>>> - d = rcu_lock_domain_by_id(domid);
>>>>> - if ( d == NULL )
>>>>> - continue;
>>>>> -
>>>>> - if ( d->is_console )
>>>>> - {
>>>>> - rcu_unlock_domain(d);
>>>>> - console_owner = next_rx;
>>>>> - printk("*** Serial input to DOM%u", domid);
>>>>> - break;
>>>>> - }
>>>>> + struct domain *d;
>>>>>
>>>>> + d = rcu_lock_domain_console_by_id(domid);
>>>>> + if ( d != NULL )
>>>>> rcu_unlock_domain(d);
>>>>> - }
>>>>> +
>>>>> + return d != NULL;
>>>>> +}
>>>>> +
>>>>> +int console_set_owner(domid_t domid)
>>>>> +{
>>>>> + if ( domid == DOMID_XEN )
>>>>> + printk("*** Serial input to Xen");
>>>>> + else if ( console_owner_possible(domid) )
>>>>> + printk("*** Serial input to DOM%u", domid);
>>>>> + else
>>>>> + return -ENOENT;
>>>>> +
>>>>> + console_owner = domid;
>>>>>
>>>>> if ( switch_code )
>>>>> printk(" (type 'CTRL-%c' three times to switch input)",
>>>>> opt_conswitch[0]);
>>>>> printk("\n");
>>>>> +
>>>>> + return 0;
>>>>> +}
>>>>> +
>>>>> +/*
>>>>> + * Switch console input focus.
>>>>> + * Rotates input focus among Xen, dom0 and boot-time created domUs while
>>>>> + * skipping switching serial input to non existing domains.
>>>>> + */
>>>>> +static void console_find_owner(void)
>>>>> +{
>>>>> + domid_t i, n = max_init_domid + 1;
>>>>
>>>> n can be made const, I would even rename to nr for clarity, but that's
>>>> personal taste.
>>>
>>> `max_init_domid` can change at run-time actually (e.g. after `xl create`).
>>> I kept `n` as is.
>>
>>
>> How does max_init_domid potentially changing affect (possible) const-ness of n?
> 
> Sorry, what I meant is I kept the original name as is in v3.
> Forgot to address `const`.
> 
>>
>> However it changing, ...
>>
>>>>> +
>>>>> + if ( console_owner == DOMID_XEN )
>>>>> + i = get_initial_domain_id();
>>>>> + else
>>>>> + i = console_owner + 1;
>>>>> +
>>>>> + for ( ; i < n; i++ )
>>>>> + if ( !console_set_owner(i) )
>>>>> + break;
>>>>
>>>> Hm, that could be a non-trivial amount of iteration if max_init_domid
>>>> is bumped for every domain created as you have it in patch 11/35
>>>> (albeit I'm not sure that was intended?)
>>>
>>> Yes, `max_init_domid` is advanced on each domain creation (v3).
>>
>>
>> ... as you confirm here, undermines what it's used for right now (if I'm
>> not mistaken), and would render the variable misnamed.
> 
> Yes, the name will be a bit confusing.
> Will something like `last_domid` work?

Well. First and foremost you need to make sure that existing uses of the
variable will continue to function as-is. Aiui that contradicts your
re-purposing of it. Which in turn would eliminate the question of how to
best rename it.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 08:40:35 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 08:40:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866122.1277393 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV58c-0004fx-LU; Tue, 07 Jan 2025 08:40:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866122.1277393; Tue, 07 Jan 2025 08:40:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV58c-0004fq-Ib; Tue, 07 Jan 2025 08:40:34 +0000
Received: by outflank-mailman (input) for mailman id 866122;
 Tue, 07 Jan 2025 08:40:34 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=1r68=T7=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tV58b-0004fk-V6
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 08:40:33 +0000
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com
 [2a00:1450:4864:20::32a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0e2b0cea-ccd3-11ef-99a4-01e77a169b0f;
 Tue, 07 Jan 2025 09:40:32 +0100 (CET)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-436a39e4891so53300075e9.1
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 00:40:32 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c847214sm49722762f8f.46.2025.01.07.00.40.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 00:40:31 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 0e2b0cea-ccd3-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736239231; x=1736844031; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=PyeZNr7dYL1BRBhi7oa3C4MvptWLYqA9NZuV0E10Iv8=;
        b=SCX1RvIsqI186RBmB6nhKCr5rlR58fLCQSNSk9soEcIZcETNsEj+Mz4v7N3Dngenrl
         xW9IoMLUStgmsiPNHPJvAG9RSDE53WBEHQq+wKEX9UcIi04uK1u69zpG5SYiwxVKFZH3
         SVmvCQGD7FU7xkOCXxfPIyiZPyQH3d3xRxCtiA7ANUlsVn6vaadYmAQV6cyLhOiMxZbf
         47zfg7ZQY8D4eKTiK/B45vKLyKgetG051gS0QLhSeK3aoTTqoDIKgLp7OmY3WZcU7tVa
         FQOz2hzlvtfyUx+j1u5DhrrJucr7kHOolEKpzxPmqcuwdlVT+Tsb+CdukvXhgwNzy/4n
         lkuQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736239231; x=1736844031;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=PyeZNr7dYL1BRBhi7oa3C4MvptWLYqA9NZuV0E10Iv8=;
        b=LOXb54WqnnRKlOXEECyh6szlQyRngQiTWTOyQBanJFP3nTRXXLY8O78QPMdmBQPgWt
         94o+VZTHQCzIKbQ0r8huczrK6MkqFwTg8K1H9xfqW0AeBAlbiLg2Xhe+aoCkTBn3wmiv
         OJ6HGbYY0AOjHJSAQpSEOIvtoTYiz2T3iLhjgYBVi6klwfC95hRrPfbMrHGmUVe6ltvR
         fiK+yfQb2q6uQxAu9oE3bf3iuvbKjJMZOylFWU2oFDi9u3ESRbn8KpT5oEk4anFbIwo3
         qameyfE4lPZLeYJWExYTacJVdt15AGNGNiKx+7Z2ICReEDbVIctkxbl8kguohHNTgglk
         Yc5Q==
X-Forwarded-Encrypted: i=1; AJvYcCXzD/TrWcEOsDrLJYmUxNP0245uerQGbfUTOglPeVQEG7UXeOr8nmGBSe25MBIf/cM6rugluRNWHU0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwxmtPK3zZWf5Iznv0DSASQagqqs5I55KYUNOpfASplP4MWB5lV
	+/zy0/SbsVv5fw2l9wigvufeDEvjADj9m0Llx4ViKQs/XC+I0BKMvnJIs80mUPKVhboCOi13dWQ
	=
X-Gm-Gg: ASbGnctfngYIz0hD5C+YUDsBT7olmeun1fjfTPaWT5E/we0Iln25HyoaQigzRKV4Jki
	axDAc6XRqyt8Fql4PDglXs+JootJ83lhT6FDodSLfNKYoFnwI8uciv+FLWlx47zAiKO5ijM+3P+
	5o11LA4ol0UG0PX/2HjURh+9kuxy5sOfF9ORYyW/sK1v+auF3MFutKZw/9vfJ2BV4MGRcvueImK
	TgejqsBv9+/eN+2FQI+chLgqQGuvQkcLP3+ncY0APS2YWbu7qaeyxcK/csMQ1ZzBg63gMUifcoV
	KhXJNbio734d0wLxovkPzCJyyUEXvQZDKH9M6Bg/3w==
X-Google-Smtp-Source: AGHT+IET6/PlMP+lQyTZqv4ik1fWRxXXaT8GgFa3aoqvjvtSjWdlgKuoQQOM8xiloatfh/O6U6LWSQ==
X-Received: by 2002:a05:6000:481e:b0:382:49f9:74bb with SMTP id ffacd0b85a97d-38a2220120dmr54735887f8f.35.1736239231441;
        Tue, 07 Jan 2025 00:40:31 -0800 (PST)
Message-ID: <c39c0c6f-2fab-46e8-9563-c91fe890e87f@suse.com>
Date: Tue, 7 Jan 2025 09:40:29 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 20/35] xen/console: introduce console_owner_domid()
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: Denis Mukhin <dmkhn@proton.me>, dmukhin@ford.com,
 xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 Julien Grall <julien@xen.org>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-20-e9aa923127eb@ford.com>
 <d55bf6a6-5861-4b72-88b5-2aaa28ae0290@suse.com>
 <VJ9ivpkbNlqfKhBlb5dL6OuoPAXK9wqD4mhgO9Qt4f0qgmuow22qFv1C7L8DlbKYo7ytdKWeV1bLaYJvTAc2Yt7sEd06XREerWER5RPx4No=@proton.me>
 <8a5a5a0f-72b0-4336-b0d2-142254319242@suse.com>
 <alpine.DEB.2.22.394.2501061046060.133435@ubuntu-linux-20-04-desktop>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <alpine.DEB.2.22.394.2501061046060.133435@ubuntu-linux-20-04-desktop>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.01.2025 19:48, Stefano Stabellini wrote:
> On Mon, 6 Jan 2025, Jan Beulich wrote:
>> On 04.01.2025 05:15, Denis Mukhin wrote:
>>>
>>> On Tuesday, December 10th, 2024 at 11:28 PM, Jan Beulich <jbeulich@suse.com> wrote:
>>>
>>>>
>>>>
>>>> On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
>>>>
>>>>> From: Denis Mukhin dmukhin@ford.com
>>>>>
>>>>> console_owner_domid() is introduced to obtain the "console owner" domain ID.
>>>>>
>>>>> The call is used in NS8250 emulator to identify the case when physical xen
>>>>> console focus is owned by the domain w/ NS8250 emulator, in which case,
>>>>> messages from guest OS are formatted w/o '(XEN)' prefix.
>>>>
>>>>
>>>> Such messages ought to be processed through guest_printk(), which wants a
>>>> domain pointer, not a domid_t anyway. Plus isn't that going to be
>>>> current->domain anyway at the callsite, eliminating the need for such a
>>>>
>>>> helper altogether?
>>>
>>> If the current domain is owning the physical console and printing, say, Linux
>>> login prompt, there's no need to add "(XEN)" for every printout; adding timestamps
>>> can be disabled from Xen command line.
>>
>> Surely there shouldn't be (XEN), but without (d<N>) it'll be ambiguous in a log
>> which domain a message came from. As long as only Dom0 messages are left un-
>> prefixed, that's likely fine. Yet as soon as multiple domains can issue such
>> messages (and have console "focus") I think the prefix needs to be there.
> 
> It looks like we are aligned on the desired behavior,

Hmm, no, I don't think we are. I don't ...

> but for clarity,
> see https://marc.info/?l=xen-devel&m=173405161613716, also copy/pasted
> here:
> 
> I think we should provide a consistent behavior across architectures.
> The current behavior with vpl011 and dom0less on ARM is the following:
> 
> - no prefix for Dom0 output
> - DOM$NUM for DomUs when not in focus, otherwise no prefix

... view this model as a desirable one. It leaves room for ambiguity.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 08:43:22 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 08:43:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866129.1277403 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV5BG-0005QV-10; Tue, 07 Jan 2025 08:43:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866129.1277403; Tue, 07 Jan 2025 08:43:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV5BF-0005QO-UL; Tue, 07 Jan 2025 08:43:17 +0000
Received: by outflank-mailman (input) for mailman id 866129;
 Tue, 07 Jan 2025 08:43:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=1r68=T7=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tV5BE-0005QI-Ko
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 08:43:16 +0000
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com
 [2a00:1450:4864:20::32d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6fa4358f-ccd3-11ef-a0df-8be0dac302b0;
 Tue, 07 Jan 2025 09:43:15 +0100 (CET)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-43625c4a50dso104862595e9.0
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 00:43:15 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436604e9c2csm591076955e9.43.2025.01.07.00.43.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 00:43:13 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 6fa4358f-ccd3-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736239395; x=1736844195; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=KVX8TXD0K8yavRQGZ6xlgaZrPxSoFb3ECczY36Sr0ts=;
        b=AUGDTEVxi3Z6t4XqzY10xrqMpk43q0iuP8+cbahjH3kvykbNNpzftJbBLNYynJ2NoU
         EsNyhCaNb302tzcWza2zaacO03HjcPR/nBEINA2nZZj80jtUtds17YmDtHpQoJRqP4xK
         fq0yDIQandqXJR9WL5QofE2uRo3NCTtEFCUL2lpxwmk6XC6s6dVY5sPrlUQ4DyuAqcSv
         exB6Ykw1GytOzKA3xr1EswRmuGpEa5JU8gXE8+2MPPAJOr2TUJwPQ1y2WR/sok00qjd5
         zZjyaUXTXSRNxtAhoe4mqYtIkS4BZ3+zG1aVqRg93x2JGth+vNaduJQk5IliLUqVmupE
         oA8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736239395; x=1736844195;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=KVX8TXD0K8yavRQGZ6xlgaZrPxSoFb3ECczY36Sr0ts=;
        b=EwaR/yWyvSDqa7Qv85plBS0YrL1LG5oKuO41aeJgOvOUf6EBqiqi5Gbp41aUW2b4cm
         +vwh+m3wnXdtDju63hH7A4BiBpzFg4jIhsJW/HlGFrKBoKqybfFgIwsKZ4ysjS0HpLkY
         DOfHpgRkL4gBoEtMCSERFbtT20Cd+e8C2+gbXz5HSEOH+jQCZzKpMRTuoV3zOZmjlCvJ
         +HpYdc8eu1+yhspxdqGZwKO/baYD3jcrb41dMfU36+YfGx/sW7Lnc2z/yORCdDa4FmsE
         36G18xsL3UskHZGWisxQGHwgFNy1nwNhAd90zqv2SFANQhW0CfB/U8vCGcqwg154KbFl
         DjeA==
X-Forwarded-Encrypted: i=1; AJvYcCWorBhNsNZEZOGtDtlCufvNQokK3S1Dk98HovvRnwCzEPCQ+WlA3IqlbzrkEE5mO4ByWigIde6cmu4=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw6tzwgUqd7vt6wpXBNWfR13wpLXKuLsCoCOvONNWg3y2cWAGPD
	THPaGi4JqDEKMvrkwTTUBmjsmsWY3/IquqKOwltcQQYFO2qayDVNQV+U2AwTRA==
X-Gm-Gg: ASbGnctsnNG12Er7Ba8TmLzA6pP+cqG5L1ajkbC6lPPMAkp6pZrVViy8965WrYQgIMY
	utXv69u6wTIhHtfD93rD944YZMlMTdmLwiqZVc0STZr8Q0y+ZxndJ3c15CrWIojGonfOznIwFlc
	IhRlAwDGXWkyHSjLAS2XSy/7O+OoTRd3pNvdwsgu824RzJfMvDQXytQcBnEjdiiMZcCPbWjEBv4
	Zi/K3smG+zypim9hbGdvxa1AvbRrjBxqk5eblOZMmyuCYoTSu1oht+tWj6FU/TivC09L6ii15Dg
	Eu4edz7uHaFoGjm+A9NuR8FAVHAkRq0E8equ/+kNig==
X-Google-Smtp-Source: AGHT+IETx6/pe6aZkqMxcY2IUlIh4Ng4wuwM6se87+KRES8zpM6IYMfU6N4dQw7stYkfpU8vmlQt0g==
X-Received: by 2002:a05:600c:138d:b0:434:ff08:202b with SMTP id 5b1f17b1804b1-43668643173mr543395955e9.12.1736239395023;
        Tue, 07 Jan 2025 00:43:15 -0800 (PST)
Message-ID: <149856c5-d168-4ebf-9a1f-54be0105fd2c@suse.com>
Date: Tue, 7 Jan 2025 09:43:12 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 31/35] x86/hvm: introduce NS8250 UART emulator
To: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, Andrew Cooper <andrew.cooper3@citrix.com>,
 Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>,
 xen-devel@lists.xenproject.org
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-31-e9aa923127eb@ford.com>
 <3be247cc-900b-48f3-98f3-0d97532ede76@suse.com>
 <DJo9IkTvGXsao_hA4njnkX9OVYVR6tXdo95AeBiT8wGtbPb7UKQjLCqqIset3bJ3JbLqogcIb4wPqNXJ-2GFwyrW_UIvRg5Nt9QhpG0hfyo=@proton.me>
 <5e4fb323-0dd1-4eb9-9e83-245ab516be06@suse.com>
 <V4pjEMTV_MhwDERhOJQksxnt1aNMN6cE5z0lRjvE-4R1cdBRizIaMikI1hNXYB0tei3ljgLOWVQkMITOEeeBYIsNQzblqB7g8jJJwalRzY0=@proton.me>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <V4pjEMTV_MhwDERhOJQksxnt1aNMN6cE5z0lRjvE-4R1cdBRizIaMikI1hNXYB0tei3ljgLOWVQkMITOEeeBYIsNQzblqB7g8jJJwalRzY0=@proton.me>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.01.2025 21:16, Denis Mukhin wrote:
> On Monday, January 6th, 2025 at 1:19 AM, Jan Beulich <jbeulich@suse.com> wrote:
>> On 04.01.2025 06:31, Denis Mukhin wrote:
>>> On Monday, December 16th, 2024 at 7:04 AM, Jan Beulich jbeulich@suse.com wrote:
>>>> On 06.12.2024 05:42, Denis Mukhin via B4 Relay wrote:
>>>>
>>>>> + depends on HVM && HAS_IOPORTS
>>>>
>>>> Why HAS_IOPORTS?
>>>
>>> It is meant to highlight the fact that MMIO-based UART is not supported.
>>> It is not currently possible to enable the emulator for, say, Arm platforms.
>>
>>
>> That I guessed, yet you realize that HAS_IOPORTS describes a host property,
>> not (so much) a guest one?
> 
> re: host property: yes; this is meant to be only a guardrail for porting of the
> emulator code (if any) to other architectures, since there's no MMIO-based
> NS16550 emulator yet.
> 
> I will drop this superfluous dependency in the next iteration.

Just to clarify: If properly justified, I'm okay with the dependency to
be kept. Otoh the lack of MMIO handling will turn out as pretty obvious
if someone was to try to enable this emulation on an IO-port-less arch.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 08:46:48 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 08:46:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866134.1277413 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV5Ed-0005zG-G7; Tue, 07 Jan 2025 08:46:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866134.1277413; Tue, 07 Jan 2025 08:46:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV5Ed-0005z9-D1; Tue, 07 Jan 2025 08:46:47 +0000
Received: by outflank-mailman (input) for mailman id 866134;
 Tue, 07 Jan 2025 08:46:46 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=1r68=T7=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tV5Ec-0005z3-L2
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 08:46:46 +0000
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com
 [2a00:1450:4864:20::334])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ec450c6a-ccd3-11ef-99a4-01e77a169b0f;
 Tue, 07 Jan 2025 09:46:44 +0100 (CET)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-4361b0ec57aso151460075e9.0
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 00:46:44 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436611ea40csm590064215e9.1.2025.01.07.00.46.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 00:46:43 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ec450c6a-ccd3-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736239604; x=1736844404; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=iEkNbXDRnccs9v89Lnqv5STEKhDOtjUGGnkH6ubruXI=;
        b=FVHG88visvGd9u898ENDCLU2aIEBur40y8VOIxka9j30I7JPJLCE5S22JP0aDFixzb
         O4BJQon6lCqfZ2ZvoX+PcIlC1xx3Czqais+DciiqzzsbDa8+uekjjwGnPBrlM3uLi1YU
         b/avStHYJOWGz4P4Hibb7HUwa84g7tc7XvIXEut5dPcS/sG7ePAK46JF5WL5+tzazEe6
         79Ewo/NAsc/Gja3JNCXsPebgrcoqTG/7C3FK1R1WnD3F9xqt773Lfoh58wEYgXcHEF+o
         3qWNyPXHHjdwmQtN9og4QKnkebzBB5ZEOYd3Ta9Q2By/rP8RijbAOfKCl/+BLepVImtL
         xIhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736239604; x=1736844404;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=iEkNbXDRnccs9v89Lnqv5STEKhDOtjUGGnkH6ubruXI=;
        b=osh2mBoCSBPNxD20nRkxCOkhd7glz6AyhX2WKJO3E0uqkJWPUMSuxhKnDd4cHK8QvN
         hgZk1olfbmncAAWtuL0D7KH58pva5w1xe8M/NxhC8MhSQwR8UcOjRjH5kf26iT6OWSxz
         XcIJEJakfLpnC3iUXCAoUJq7B7WaZGXoQknpUM9nCXvRfYLdTmCWEpmNPKC+T6LyExfj
         UsyxBtAK+EjqJLoKLEwFdvrmgunhlperdjPgcz+H+MHt7s9tF40+3Oz7qVl6Qoe5t9xe
         F3ewxRBxcCilD/mLwVbIBlTmuCv4hT9xIDAtgoQbeRM/5CJ9zo1P8FdLOFxOcZQX2bz6
         ru/w==
X-Forwarded-Encrypted: i=1; AJvYcCVPXDbE3DJLh7W0wdagLwhpd3Zuwepw6QHpBlCbSUxtPAQ+P5mIJHnv0Wgq0wXi8KmpVbcJfm4nips=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxA6/sGsF6W06XW5p783qRzaPN4Ac+BAtxrrWu9Y3iQ5u49lHUa
	IXOcnVmDOOrK24VhiGC0OJo71ZJXlhk2fpsNv3NhTiDyer8SdIXshoHvhSlbNQ==
X-Gm-Gg: ASbGncu+Mc0nc2a8T1ZEo9CNxF3D5hpbVxsfptLEJbPwPb3mzcKXkf4z/dMJRuVOuLG
	pO4gGdo8sXqjZt+nqzRtDuHfxYhH7sDEXBzw6Qk1vvhFKb3TiVUSTlBzVK1xAomViGpT71OJ4iu
	MOuVS5DbTC84cx913unjCNflZumNEQyyeeGjrS4qZOluLF+OaFSaRT3D3D6pLBPPj6cvKhR7R+1
	XXynuop814oALxC//b2PkIHtYtvamg47dI4u+B4D7842GWxrxXkU7TyWWcNGZP5+1sJvfK9ci+r
	Y5RlRk/pkX5sdAY3aXEWQog1/92L189luXrTueNG9w==
X-Google-Smtp-Source: AGHT+IFDkDr7U8T0vOfIUADs/pGN+Fmd//XAcxKeB4bbAM7KQVdEv4Jn51gfJ1mrT7Q7Lg2Q4QP6Cg==
X-Received: by 2002:a05:600c:3b9a:b0:42c:bb10:7292 with SMTP id 5b1f17b1804b1-436685470f8mr408390445e9.1.1736239604092;
        Tue, 07 Jan 2025 00:46:44 -0800 (PST)
Message-ID: <a0c50fb6-516a-4e0e-8c3b-49c4dbc7b863@suse.com>
Date: Tue, 7 Jan 2025 09:46:42 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v1] xen: mem_access: conditionally compile vm_event.c
 & monitor.c
To: Tamas K Lengyel <tamas@tklengyel.com>
Cc: Sergiy Kibrik <Sergiy_Kibrik@epam.com>,
 Stefano Stabellini <stefano.stabellini@amd.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Alexandru Isaila <aisaila@bitdefender.com>,
 Petre Pircalabu <ppircalabu@bitdefender.com>, xen-devel@lists.xenproject.org
References: <20241230063051.3332332-1-Sergiy_Kibrik@epam.com>
 <c8684340-33f9-41d3-94e4-77ee3bc18306@suse.com>
 <CABfawhk4pzA9bSMzJDX7ZwaYC50dfn_ntCnk=bePmiKCpDnN3w@mail.gmail.com>
 <8fc662a1-4c74-4f97-a116-3bc5a0b71cf1@suse.com>
 <CABfawhkyg+TVB-uc04OefDhOXEfeQyQypW6gL4qsYO3ZrDxYfQ@mail.gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <CABfawhkyg+TVB-uc04OefDhOXEfeQyQypW6gL4qsYO3ZrDxYfQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 06.01.2025 19:09, Tamas K Lengyel wrote:
> On Mon, Jan 6, 2025 at 10:10 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 06.01.2025 15:05, Tamas K Lengyel wrote:
>>> On Mon, Jan 6, 2025 at 5:16 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> On 30.12.2024 07:30, Sergiy Kibrik wrote:
>>>>> From: Stefano Stabellini <stefano.stabellini@amd.com>
>>>>>
>>>>> Extend coverage of CONFIG_MEM_ACCESS option and make the build of VM events
>>>>> and monitoring support optional.
>>>>
>>>> Yet doesn't this end up in things becoming misleading? Don't we rather need a
>>>> 2nd Kconfig option, with a dependency between the two? Or alternatively a
>>>> rename of the existing option (to describe the higher-level feature rather
>>>> than the lower level one)? Tamas, I'm particularly interested in knowing your
>>>> view here as well.
>>>
>>> Thanks Jan, I was thinking the same thing. The dependency of these
>>> subsystems is mem_access -> monitor -> vm_event. If the goal here is
>>> to disable all three levels the ideal way would be to have separate
>>> kconfig options for each level. It may be a bit too fine-grained
>>> though on ARM since there are only two types of events for monitor
>>> (SMC & mem_access) and only the monitor uses the vm_event channel (no
>>> mem-sharing/paging on ARM). So if doing separate kconfig for each
>>> individual feature is an overkill I would suggest using
>>> CONFIG_VM_EVENT that disables all three levels, including both
>>> mem_access & smc monitor hooks.
>>
>> Except that "disables all three levels" doesn't work, unless the other
>> option(s) are promptless (and selected). I'd have expected VM_EVENT to
>> maybe have a "depends on MEM_ACCESS", whereas a "select MEM_ACCESS"
>> wouldn't make much sense as long as MEM_ACCESS can be enabled
>> individually (with it being unclear to me whether such a configuration
>> is actually useful in any way).
> 
> Not sure I follow. None of these systems make sense to enable
> individually. Without vm_event monitor/mem_access are useless, that's
> why I would pick CONFIG_VM_EVENT as the option on ARM to disable all
> three levels if we don't want to start splitting it into multiple
> kconfig options (which I think may be an overkill here).

Oh, okay, you suggest to replace MEM_ACCESS by VM_EVENT at the Kconfig
level. That would be fine with me, so long as it's also appropriate on
(in particular) x86. Then, if there was ever a 2nd use of mem-access,
MEM_ACCESS could be re-introduced as a standalone option.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 09:03:04 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 09:03:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866149.1277423 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV5U7-0000j7-0N; Tue, 07 Jan 2025 09:02:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866149.1277423; Tue, 07 Jan 2025 09:02:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV5U6-0000j0-TS; Tue, 07 Jan 2025 09:02:46 +0000
Received: by outflank-mailman (input) for mailman id 866149;
 Tue, 07 Jan 2025 09:02: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
 <SRS0=hoyV=T7=arm.com=bertrand.marquis@srs-se1.protection.inumbo.net>)
 id 1tV5U5-0000iu-PA
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 09:02:45 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id 278f354b-ccd6-11ef-99a4-01e77a169b0f;
 Tue, 07 Jan 2025 10:02:43 +0100 (CET)
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E904213D5;
 Tue,  7 Jan 2025 01:03:10 -0800 (PST)
Received: from C3HXLD123V.arm.com (unknown [10.57.93.17])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 472493F66E;
 Tue,  7 Jan 2025 01:02:41 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 278f354b-ccd6-11ef-99a4-01e77a169b0f
From: Bertrand Marquis <bertrand.marquis@arm.com>
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Community Manager <community.manager@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Michal Orzel <michal.orzel@amd.com>
Subject: [PATCH] xen/arm: ffa: add changelog entries for FF-A improvements
Date: Tue,  7 Jan 2025 10:02:18 +0100
Message-ID: <059ad52a5d2aa6fb7fabe44fe2a99d8b73c1b907.1736240334.git.bertrand.marquis@arm.com>
X-Mailer: git-send-email 2.47.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Add a CHANGELOG entry for release 4.20 to mention the various
improvements and fixes that have been done in the FF-A support since
4.19 release.

Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
---
 CHANGELOG.md | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 8507e6556a56..d58a2ffd130b 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -22,6 +22,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
    - Basic handling for SCMI requests over SMC using Shared Memory, by allowing
      forwarding the calls to EL3 FW if coming from hwdom.
    - Support for LLC (Last Level Cache) coloring.
+   - Several FF-A support improvements: add indirect messages support, transmit
+     RXTX buffer to the SPMC, fix version negotication and partition
+     information retrieval.
  - On x86:
    - xl suspend/resume subcommands.
 
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Tue Jan 07 09:11:20 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 09:11:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866158.1277432 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV5cJ-0002NZ-Pi; Tue, 07 Jan 2025 09:11:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866158.1277432; Tue, 07 Jan 2025 09:11:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV5cJ-0002NS-MZ; Tue, 07 Jan 2025 09:11:15 +0000
Received: by outflank-mailman (input) for mailman id 866158;
 Tue, 07 Jan 2025 09:11: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
 <SRS0=zac/=T7=bugseng.com=alessandro.zucchelli@srs-se1.protection.inumbo.net>)
 id 1tV5cH-0002Lq-Bn
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 09:11:13 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 565f5bb6-ccd7-11ef-99a4-01e77a169b0f;
 Tue, 07 Jan 2025 10:11:11 +0100 (CET)
Received: from delta.homenet.telecomitalia.it
 (host-87-20-204-41.retail.telecomitalia.it [87.20.204.41])
 by support.bugseng.com (Postfix) with ESMTPSA id 0B47F4EE073E;
 Tue,  7 Jan 2025 10:11:08 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 565f5bb6-ccd7-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1736241070; bh=UoO31GcfZ3JwHGshg9nzIAzs7hqs8F9dpMBk7TPFhO4=;
	h=From:To:Cc:Subject:Date:From;
	b=SSsrSm9TfzaWwfjPKPfFCoULpi5hQFNHib/FRefcFtIRaRuXMZsf/+dz65Sd2EpkM
	 sugFSIniIgeR+4hNo/SIPVKFQ/d3ptJvkqKaC2a2LO+AElNRr9WVp/mEkThmim3VY6
	 umzTCNaiplF2zOvXoXRyxnIlG+70iEQ/kGHd0FV3mRpaTwnBnqSRNJtMNWLyz/87rM
	 vaSpC2UScq+j61+Of4JQrvs24W0cfh0SF/gRHwqG8HDN3Gp+4nL+rmQvdXnI602HYd
	 56d1nF73D9xROJLTfEwuYDyjOI5sS39ZLlIDp4IRXYm9gOFfQnBP9vReXITKnnL56C
	 lJXN+ziRiU9kg==
From: Alessandro Zucchelli <alessandro.zucchelli@bugseng.com>
To: xen-devel@lists.xenproject.org
Cc: consulting@bugseng.com,
	Alessandro Zucchelli <alessandro.zucchelli@bugseng.com>,
	Simone Ballarin <simone.ballarin@bugseng.com>,
	Doug Goldstein <cardoe@cardoe.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>
Subject: [PATCH v3] misra: add deviation for MISRA C Rule R11.8.
Date: Tue,  7 Jan 2025 10:10:48 +0100
Message-ID: <4a2c68bdc11a815cb8531be305e2e7fc4bef7779.1736240655.git.alessandro.zucchelli@bugseng.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Rule 11.8 states as following: "A cast shall not remove any `const' or
`volatile' qualification from the type pointed to by a pointer".

Function `__hvm_copy' in `xen/arch/x86/hvm/hvm.c' is a double-use
function, where the parameter needs to not be const because it can be
set for write or not. As it was decided a new const-only function will
lead to more developer confusion than it's worth, this violation is
addressed by deviating the function.
All cases of casting away const-ness are accompanied with a comment
explaining why it is safe given the other flags passed in; such comment is used
by the deviation in order to match the appropriate function call.
No functional change.

Signed-off-by: Alessandro Zucchelli <alessandro.zucchelli@bugseng.com>
---
Changes from V2:
The deviation has been documented under docs/misra/deviations.rst.

Changes from V1:
The deviation has been refined to specify that every instance of casting away
const-ness is accompanied by a comment explaining why it is safe.
This comment is a requirement that has been incorporated into the text defining
the deviation.
---
 automation/eclair_analysis/ECLAIR/deviations.ecl | 6 ++++++
 docs/misra/deviations.rst                        | 7 +++++++
 2 files changed, 13 insertions(+)

diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
index 2f58f29203..c9d06b44f4 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -393,6 +393,12 @@ Fixing this violation would require to increase code complexity and lower readab
 -config=MC3R1.R11.8,reports+={safe,"any_area(any_loc(any_exp(macro(^container_of$))))"}
 -doc_end
 
+-doc_begin="Function __hvm_copy in xen/arch/x86/hvm/hvm.c is a double-use
+function, where the parameter needs to not be const because it can be set for
+write or not"
+-config=MC3A2.R11.8,reports+={safe,"any_area(any_loc(text(^.*__hvm_copy.*HVMCOPY_to_guest doesn't modify.*$)))"}
+-doc_end
+
 -doc_begin="This construct is used to check if the type is scalar, and for this purpose the use of 0 as a null pointer constant is deliberate."
 -config=MC3R1.R11.9,reports+={deliberate, "any_area(any_loc(any_exp(macro(^__ACCESS_ONCE$))))"
 }
diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
index 15a993d050..92dcc91e3a 100644
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -353,6 +353,13 @@ Deviations related to MISRA C:2012 Rules:
        Fixing this violation would require to increase code complexity and lower readability.
      - Tagged as `safe` for ECLAIR.
 
+   * - R11.8
+     - Violations caused by function __hvm_copy occour when a const void attribute is passed,
+       as the const qualifier is stripped. However, in such cases, the function ensures
+       that it does not modify the attribute, therefore, this use is deemed safe.
+       Fixing this violation would require to increase code complexity and lower readability.
+     - Tagged as `safe` for ECLAIR.
+
    * - R11.9
      - __ACCESS_ONCE uses an integer, which happens to be zero, as a
        compile time check. The typecheck uses a cast. The usage of zero or other
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 07 09:15:12 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 09:15:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866165.1277443 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV5g6-00033k-8k; Tue, 07 Jan 2025 09:15:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866165.1277443; Tue, 07 Jan 2025 09:15:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV5g6-00033d-5h; Tue, 07 Jan 2025 09:15:10 +0000
Received: by outflank-mailman (input) for mailman id 866165;
 Tue, 07 Jan 2025 09:15:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=QnJ5=T7=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tV5g5-00033X-MT
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 09:15:09 +0000
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com
 [2a00:1450:4864:20::22b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e3fad2ea-ccd7-11ef-a0df-8be0dac302b0;
 Tue, 07 Jan 2025 10:15:08 +0100 (CET)
Received: by mail-lj1-x22b.google.com with SMTP id
 38308e7fff4ca-300392cc4caso168878461fa.3
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 01:15:08 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-3045b082dc8sm58217361fa.108.2025.01.07.01.15.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 01:15:07 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e3fad2ea-ccd7-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736241308; x=1736846108; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=W3Nd9qoFHTYlqrzl1iRpc8+ZuivKjkCDK+a01NNYKnU=;
        b=SDhOTqMUbb4rsFYupR5WkdFN7XwfSe80YAZovfE6c7D57XE4E/R4/8owdwtVZs7Xcl
         nHVw3JoPMFdc6QKgzfSxAG0RS8XH2NXiT7R3GKWt4zVT9kv/9xACvRX9FUDxVXm1TG1Q
         +F0UX9tmyPnjJGYT111QLlSP4MCmtAdN6IlS7aMIIuLA37q4Z6zByoRVA0zzCGUM+DJA
         Rh8Fiye3jEjel0mJ6MFIZTw1I4PM48ZDtbDDq0CbWjsmaSbJ926SVUXnCkL6CjC5lFrw
         kMQ3/WGQy3K4KcpT9WMfFIvHdDhNOby+lyRWMVGegmCSISwOQi7uHUNoZ76p1AG8Zh60
         StGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736241308; x=1736846108;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=W3Nd9qoFHTYlqrzl1iRpc8+ZuivKjkCDK+a01NNYKnU=;
        b=I6OXWmX2qCT9KJFmnCSwc6S88HeGmIh4eWW8tyZaP+YAjKzwaUzIaKF2WUt+Dr+ILB
         qhnC08AuUXdgvVyyJ/ZKAGbylLMPIYBi+ZDOcx7dPe92ElgKULQZJsrZe70c3bfBEdwJ
         /hubdRzIu2rFtX8GuZNmqpn750LgCp25B75C+BVZBWNQC9SDXX8l9oC7SkcH8NjXmgiq
         rg11xVqJeBMgn9hjZk35AXJYVgIHcKMLTDKi27mkaGt4msGvvBI8p8yOGRPwo3x3da06
         uSUDW/MC84DUv8TubEOjBPtY9+VJ2I4UXYAyR2+f3VXDC5LS+b8LWLlWYlcIjybh8Jvk
         PZCw==
X-Forwarded-Encrypted: i=1; AJvYcCUBIkBqTENVn/fB6kVgxWjq3qWEB3suIvs0YN+HRr1GprOV1RQUweHnv2gylWhy0yzQV9/dq4RmHGA=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx+qyBwI8sj4RcRBhWedw84pnHcs/L3EHkErskBO6bir+OpvoQv
	WfaPtGGCN3Psh5cXotdvd/qfwzKt86lcHyr6w/F48y4qbNEUb8CR
X-Gm-Gg: ASbGncs7slFmatuTEmKSTaH3/hI27idXuUYY7lweWaeuWDPpRMp1NA0MmKo4tay8Xha
	kGGYjh5JMyQWHbVMz76atfz7if8m/6NoYCM1OSO6letlK9JzYXVRnz4UcYnRx8m6iB6Qyfatokc
	jeDkf2lj7Xx2xX10f4rAUBXChWA26fC5deOoBUl2Eo5RW26uDqePFK4MTGvpCm4B6+iJlgrH3r4
	BLKVtu/AFIbrQJKXUEfVT9TF5SfrR39+DIt7vcS0ZrKVHUuH8eJWMF83vGQ79M2OC6kuw==
X-Google-Smtp-Source: AGHT+IH3RxJXLTcyEizL1+L5pmDxuPiSPmo6vZ8LpY/TlcuXUHnwSP+r2lTBIJ/RPVDH8JobrnhiHg==
X-Received: by 2002:a05:651c:400b:b0:302:2baf:6d14 with SMTP id 38308e7fff4ca-304685f0594mr117707441fa.40.1736241307797;
        Tue, 07 Jan 2025 01:15:07 -0800 (PST)
Message-ID: <531848d5-4ee3-45ea-9ef1-e7ed9a1eabab@gmail.com>
Date: Tue, 7 Jan 2025 10:15:06 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/5] xen/perfc: Add perfc_defn.h to asm-generic
To: Andrew Cooper <andrew.cooper3@citrix.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
Cc: Jan Beulich <JBeulich@suse.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Stefano Stabellini <sstabellini@kernel.org>,
 Julien Grall <julien@xen.org>, Volodymyr Babchuk
 <Volodymyr_Babchuk@epam.com>, Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 Shawn Anastasio <sanastasio@raptorengineering.com>
References: <20250102192508.2405687-1-andrew.cooper3@citrix.com>
 <20250102192508.2405687-3-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <20250102192508.2405687-3-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


On 1/2/25 8:25 PM, Andrew Cooper wrote:
> ... and hook it up for RISC-V and PPC.
>
> On RISC-V at least, no combination of headers pulls in errno.h, so include it
> explicitly.
>
> Guard the hypercalls array declaration based on NR_hypercalls existing.  This
> is sufficient to get PERF_COUNTERS fully working on RISC-V and PPC, so drop
> the randconfig override.
>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

LKGTM:  Acked-by: Oleksii Kurohcko <oleksii.kurochko@gmail.com>

~ Oleksii

> ---
> CC: Jan Beulich <JBeulich@suse.com>
> CC: Roger Pau Monné <roger.pau@citrix.com>
> CC: Stefano Stabellini <sstabellini@kernel.org>
> CC: Julien Grall <julien@xen.org>
> CC: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
> CC: Bertrand Marquis <bertrand.marquis@arm.com>
> CC: Michal Orzel <michal.orzel@amd.com>
> CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> CC: Shawn Anastasio <sanastasio@raptorengineering.com>
> ---
>   automation/gitlab-ci/build.yaml      | 1 -
>   xen/arch/ppc/include/asm/Makefile    | 1 +
>   xen/arch/riscv/include/asm/Makefile  | 1 +
>   xen/common/perfc.c                   | 1 +
>   xen/include/asm-generic/perfc_defn.h | 5 +++++
>   xen/include/xen/perfc_defn.h         | 2 ++
>   6 files changed, 10 insertions(+), 1 deletion(-)
>   create mode 100644 xen/include/asm-generic/perfc_defn.h
>
> diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
> index 1b884cc81cdb..41f17ed45641 100644
> --- a/automation/gitlab-ci/build.yaml
> +++ b/automation/gitlab-ci/build.yaml
> @@ -734,7 +734,6 @@ debian-12-riscv64-gcc:
>         CONFIG_GRANT_TABLE=n
>         CONFIG_LIVEPATCH=n
>         CONFIG_MEM_ACCESS=n
> -      CONFIG_PERF_COUNTERS=n
>         CONFIG_QEMU_PLATFORM=y
>         CONFIG_XSM=n
>   
> diff --git a/xen/arch/ppc/include/asm/Makefile b/xen/arch/ppc/include/asm/Makefile
> index ced02e26ed13..c989a7f89b34 100644
> --- a/xen/arch/ppc/include/asm/Makefile
> +++ b/xen/arch/ppc/include/asm/Makefile
> @@ -7,6 +7,7 @@ generic-y += hypercall.h
>   generic-y += iocap.h
>   generic-y += paging.h
>   generic-y += percpu.h
> +generic-y += perfc_defn.h
>   generic-y += random.h
>   generic-y += softirq.h
>   generic-y += vm_event.h
> diff --git a/xen/arch/riscv/include/asm/Makefile b/xen/arch/riscv/include/asm/Makefile
> index ced02e26ed13..c989a7f89b34 100644
> --- a/xen/arch/riscv/include/asm/Makefile
> +++ b/xen/arch/riscv/include/asm/Makefile
> @@ -7,6 +7,7 @@ generic-y += hypercall.h
>   generic-y += iocap.h
>   generic-y += paging.h
>   generic-y += percpu.h
> +generic-y += perfc_defn.h
>   generic-y += random.h
>   generic-y += softirq.h
>   generic-y += vm_event.h
> diff --git a/xen/common/perfc.c b/xen/common/perfc.c
> index ed4dba36f1bc..8c967ab900f9 100644
> --- a/xen/common/perfc.c
> +++ b/xen/common/perfc.c
> @@ -1,4 +1,5 @@
>   
> +#include <xen/errno.h>
>   #include <xen/lib.h>
>   #include <xen/smp.h>
>   #include <xen/time.h>
> diff --git a/xen/include/asm-generic/perfc_defn.h b/xen/include/asm-generic/perfc_defn.h
> new file mode 100644
> index 000000000000..8237636d83fb
> --- /dev/null
> +++ b/xen/include/asm-generic/perfc_defn.h
> @@ -0,0 +1,5 @@
> +/* This file is legitimately included multiple times. */
> +/* #ifndef ASM_GENERIC_PERFC_DEFN_H */
> +/* #define ASM_GENERIC_PERFC_DEFN_H */
> +
> +/* #endif ASM_GENERIC_PERFC_DEFN_H */
> diff --git a/xen/include/xen/perfc_defn.h b/xen/include/xen/perfc_defn.h
> index 0027d95a60bc..a987d80dd6f1 100644
> --- a/xen/include/xen/perfc_defn.h
> +++ b/xen/include/xen/perfc_defn.h
> @@ -4,7 +4,9 @@
>   
>   #include <asm/perfc_defn.h>
>   
> +#ifdef NR_hypercalls
>   PERFCOUNTER_ARRAY(hypercalls,           "hypercalls", NR_hypercalls)
> +#endif
>   
>   PERFCOUNTER(calls_from_multicall,       "calls from multicall")
>   


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 09:17:04 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 09:17:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866171.1277453 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV5hq-0003bR-IL; Tue, 07 Jan 2025 09:16:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866171.1277453; Tue, 07 Jan 2025 09:16:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV5hq-0003bK-Fg; Tue, 07 Jan 2025 09:16:58 +0000
Received: by outflank-mailman (input) for mailman id 866171;
 Tue, 07 Jan 2025 09:16:57 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=QnJ5=T7=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tV5hp-0003ai-3H
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 09:16:57 +0000
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com
 [2a00:1450:4864:20::12e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 243bc1a4-ccd8-11ef-a0df-8be0dac302b0;
 Tue, 07 Jan 2025 10:16:56 +0100 (CET)
Received: by mail-lf1-x12e.google.com with SMTP id
 2adb3069b0e04-53e3778bffdso16907724e87.0
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 01:16:56 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-542235f5f74sm5213690e87.43.2025.01.07.01.16.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 01:16:55 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 243bc1a4-ccd8-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736241416; x=1736846216; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=nQ6+m62PP4YmaEmBS829TX2p9LA/COx/CAnEgJroET4=;
        b=XNF3w07arS16g+q/oGBL5/VAaymtV0mMxF3uTQDdU6bBVGClVssMAmmdneJh97OL/a
         uCCmdDttB8hIHtUe9QeqGKsHO4/1SSZ1jVfL/uG2SXBC9+ideTyuFzdiHyVOBz5GHUz1
         Hp3dnQTkF8Rg737MG7ra1uz2ZU+hvIJVb1twbx/DThGskXkcEaWzGL/72FrnelMiuszj
         XNolMBz1knjGyeRHnbH9Mn/C7VhvWSgvk7d194wguBD7jLVpHd6v8Ni7G0pkReNKejVV
         sJmJ3kpSp52zRffryAV/KnyqJ0dvgO151kYO6ICSBmGYCFgJfQyG6TqCYSgnK7ps7YuQ
         xtPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736241416; x=1736846216;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=nQ6+m62PP4YmaEmBS829TX2p9LA/COx/CAnEgJroET4=;
        b=w/aTsv0JXqnM2yibB7pkOmkGIpyQmNE3DB5irYPRxI6v+Z/xz1V0lFVyS1xt5614M5
         oA69IkzvRA55dWXngFZhJnQcR1m5GOqXnARg6Pnk3dz5EVBsa6J7/vgCXdR6OGD+rinL
         gLLjq0OFDspTfRGPMhqzL0KvtJpE48lRRqfVe17WwzZ5tZ3K4oBXd4pbAVgeF2G0LNZI
         2ria7BChW1IkL6AyoGhm4Y+8Ny0Kk2Ll5sIxcSPsg3CGm+hn0s1uImZ3UXRdKPlT3b5R
         zJfPYDww+UdZ6IhKNVgMqXFZhb332/G1PIqihpwnHej5pODJ2c/V/QFcXqdNsILb1LxR
         PTHg==
X-Forwarded-Encrypted: i=1; AJvYcCVNODAAPEf2i6B74i/psmQIl5QEyhPdkWoqAQO747i9BjmstTvYr1KtupCQ+O2C0N11oYX/qdBUBY8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxtD7yXnPgZf5RUP6iwtqTF1aC5XSxQkFryfLMII33/EloXi8yl
	ZJ8p+XlB/OMLNQa85xX8qDJsCYUF2ebSEA9QYnfZLqtQo+KLE7Tl
X-Gm-Gg: ASbGncubn+QFtbiX6wSgi5N0S0ydgFNpJMfzXrDasvLfvwIRxD831J+d68dgVnjFjC6
	+n9Vubfg60HBHJkeD1GHHyzpIHNJOd2adMYvyvg6baqiBxWqMJRUql7XY98xmCnjDbAtgI+YiFa
	Qar14/vIq4Wb6jvPEAj9/U8nP8qGPugIsOz5gPjT4ddUePDjdFhFf22KX+LcZWV6bJq2y4T4H1t
	bPYY1LpopSTxROzlKUOeymsTj8e98LKjxRdvnmDoZ5363azPwGnMWkWHHhGX/tB9IDRJw==
X-Google-Smtp-Source: AGHT+IG7zLmGt3x+WAZVEmCeUQm3J6uo56DroKfE4qInrkozGoIpmr8teyIPStCM4tno6XPluk45EQ==
X-Received: by 2002:a05:6512:3f25:b0:540:1b7e:7b4a with SMTP id 2adb3069b0e04-5422958230amr19661511e87.36.1736241415654;
        Tue, 07 Jan 2025 01:16:55 -0800 (PST)
Message-ID: <3b8794be-025c-488f-b6f3-8687e40a297f@gmail.com>
Date: Tue, 7 Jan 2025 10:16:54 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20? 0/5] xen/perfc: Cleanup, and wire up for
 RISCV/PPC
To: Andrew Cooper <andrew.cooper3@citrix.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
Cc: Jan Beulich <JBeulich@suse.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Stefano Stabellini <sstabellini@kernel.org>,
 Julien Grall <julien@xen.org>, Volodymyr Babchuk
 <Volodymyr_Babchuk@epam.com>, Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 Shawn Anastasio <sanastasio@raptorengineering.com>
References: <20250102192508.2405687-1-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <20250102192508.2405687-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 1/2/25 8:25 PM, Andrew Cooper wrote:
> This started as just patch 3 fixing a header tangle with FRED on x86, but grew
> somewhat.
>
> It's simple, straight forward, and gets perf counters working uniformly on all
> architectures, and a net reduction in code.
>
> It's low risk, and should be considered for 4.20 at this juncture.

Agree, we could consider to be in 4.20.

Feel free to commit these patch series.

Thanks.

~ Oleksii


>
> https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/1609450793
>
> Andrew Cooper (5):
>    xen/perfc: Drop arch_perfc_{gather,reset}()
>    xen/perfc: Add perfc_defn.h to asm-generic
>    xen/perfc: Trim includes
>    xen/perfc: Cleanup
>    xen/perfc: COMPILE TEST
>
>   automation/gitlab-ci/build.yaml      |  1 -
>   xen/Kconfig.debug                    | 14 ++++----------
>   xen/arch/arm/include/asm/perfc.h     | 21 ---------------------
>   xen/arch/ppc/include/asm/Makefile    |  1 +
>   xen/arch/riscv/include/asm/Makefile  |  1 +
>   xen/arch/x86/include/asm/perfc.h     | 12 ------------
>   xen/common/perfc.c                   | 26 ++++++++++----------------
>   xen/include/asm-generic/perfc_defn.h |  5 +++++
>   xen/include/xen/perfc.h              | 26 ++++++++++++--------------
>   xen/include/xen/perfc_defn.h         |  2 ++
>   10 files changed, 35 insertions(+), 74 deletions(-)
>   delete mode 100644 xen/arch/arm/include/asm/perfc.h
>   delete mode 100644 xen/arch/x86/include/asm/perfc.h
>   create mode 100644 xen/include/asm-generic/perfc_defn.h
>
>
> base-commit: a1746cd4434dd27ca2da8430dfb10edc76264bb3


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 09:19:51 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 09:19:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866178.1277463 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV5kc-0004B5-VT; Tue, 07 Jan 2025 09:19:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866178.1277463; Tue, 07 Jan 2025 09:19:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV5kc-0004Ay-SQ; Tue, 07 Jan 2025 09:19:50 +0000
Received: by outflank-mailman (input) for mailman id 866178;
 Tue, 07 Jan 2025 09:19:49 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=1r68=T7=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tV5kb-0004Aq-RI
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 09:19:49 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8af2eeda-ccd8-11ef-a0df-8be0dac302b0;
 Tue, 07 Jan 2025 10:19:48 +0100 (CET)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-aaecf50578eso479042366b.2
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 01:19:48 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0f06c7c2sm2388502466b.188.2025.01.07.01.19.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 01:19:48 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8af2eeda-ccd8-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736241588; x=1736846388; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=fPYmBIU4Xsfc7I/6M5+jRDqh83o8eAP+kvwxS2rhVXA=;
        b=WLCPrP2RKsry9OfV81y14XcShL/NC8s2+qC+vviO2Cltx0GCc/CyTnmSV8fTMwv+tE
         2VTIFFS5ekFyajE/Y4luQhd+Fpcb+EuV1K/0Ye6ZUAWbh2NMo/rge8xVKEh6JPdsxXtH
         1w1Mrlby9Qpmw6Z9Zd+0F6XnaMFi/by64gvrqqZltCOcdJSqcGIN/9Nw8d24BSPP7ihd
         FA97rKa3KMehgyzWDRLibD9Z9ytMfalf0OFMyWaBdJktTllGhQRvJGUD7JW5tJaOMUTe
         UAzGiCQLDi98tdQMWdHdEehqkic6Ty4dB331UNnXxpRzTAj/0pvoUgE5Iw0NwVU0r0b7
         kezg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736241588; x=1736846388;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=fPYmBIU4Xsfc7I/6M5+jRDqh83o8eAP+kvwxS2rhVXA=;
        b=bXejAUlyLKAqUwcMyTkvT/n/Jj5RX7KXoYJH3r6fLrNr5OMgp19ohHxmzgnaY5Omm0
         Qq4MHZppCtcBcPYoUiZSsNqUIzz8Ya2pI3XKbHsOLTdfHWw6PWzg0Bs8pPIhe+U9hH4X
         nq1RS4EnA2P5jbrl3tnNW42705lWzxINR0JF316q9UGqOeB9k36KmyjbzxNlkwIzxn4d
         GDHfKCH3jMYpaDrHH18A1rPk5Zgkk8OHdK6PbEv2Hx+h3az0pvVZMEZ7e2kCIrM53cVn
         wFFQAnKRrpPtFiTYL/R4VwKdT3oIn082Yr6umEAAYmYOuyZlcnLU4dFEEOjZdaaXQRxA
         pN2A==
X-Forwarded-Encrypted: i=1; AJvYcCX5LaRjuvNx12VnQvOAmQIv9G3CoiaS2/gPsDuTu9FrfBzeGvYfae8dgsPgUm1jeqxJo5cdEljqcZA=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyp0wb/R/oCwcbQftzOXoj3Kx0vT04yXCwNcptee5Ey4zTXTurn
	/szopYLbl02FrUHF9U30bfatb0gICLu6EE5h0bZZwi1kkbyG0ir5Scug6vf5L92uKja2rJGO3pQ
	=
X-Gm-Gg: ASbGncueb2cghDOhdTPyM/iUAmmHAUysFMtg+zvwRHZJYky7ENcUWFhATaaNsR5bGCy
	UNp/jAMCE1cwj4oCpekwaxwtgio1+2esbCZ0jxnVdEp52HIVT1Qwt9b4O8CvWtisSJ/DLnU46/J
	yA/XAPLgPzVvH66roiQQvy7Q8/n8vapx3ZhkiBM9J+tuy/B7QuE6bucgKmHQRygbI4hEh5C/MDb
	3zwYm/gYM0d+J94XZpUF8Af5ZLoeFVNg3dhlFKsym07kEfHkClTMqCKI07lkzW6ns9uzZ+GLPlV
	5vm67QWpWgfMoShnX2LK+PEt8DH0tXRNxHr3tOFkAA==
X-Google-Smtp-Source: AGHT+IEdURY8ztG1WMP9j+t/N/fUfSt/TGxs8fPypa4MJPZ3nDiXoFg3W9cmpUvnRsGQ7a+MC+MVJQ==
X-Received: by 2002:a17:906:4fce:b0:aa6:519c:ef9a with SMTP id a640c23a62f3a-aac3366afa5mr5906852266b.53.1736241588369;
        Tue, 07 Jan 2025 01:19:48 -0800 (PST)
Message-ID: <921ef7b8-36d2-405d-ad7e-1a9418b7c4e6@suse.com>
Date: Tue, 7 Jan 2025 10:19:47 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] misra: add deviation for MISRA C Rule R11.8.
To: Alessandro Zucchelli <alessandro.zucchelli@bugseng.com>
Cc: consulting@bugseng.com, Simone Ballarin <simone.ballarin@bugseng.com>,
 Doug Goldstein <cardoe@cardoe.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 xen-devel@lists.xenproject.org
References: <4a2c68bdc11a815cb8531be305e2e7fc4bef7779.1736240655.git.alessandro.zucchelli@bugseng.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <4a2c68bdc11a815cb8531be305e2e7fc4bef7779.1736240655.git.alessandro.zucchelli@bugseng.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 07.01.2025 10:10, Alessandro Zucchelli wrote:
> --- a/docs/misra/deviations.rst
> +++ b/docs/misra/deviations.rst
> @@ -353,6 +353,13 @@ Deviations related to MISRA C:2012 Rules:
>         Fixing this violation would require to increase code complexity and lower readability.
>       - Tagged as `safe` for ECLAIR.
>  
> +   * - R11.8
> +     - Violations caused by function __hvm_copy occour when a const void attribute is passed,
> +       as the const qualifier is stripped. However, in such cases, the function ensures
> +       that it does not modify the attribute, therefore, this use is deemed safe.
> +       Fixing this violation would require to increase code complexity and lower readability.
> +     - Tagged as `safe` for ECLAIR.

Do you really mean "attribute" in both places the word is used? In the
first case talk appears to be of a function argument / parameter, while
in the second case it looks to be the buffer referenced be the
argument / parameter which is meant.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 09:27:39 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 09:27:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866192.1277498 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV5sB-0006mz-HO; Tue, 07 Jan 2025 09:27:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866192.1277498; Tue, 07 Jan 2025 09:27:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV5sB-0006m9-BW; Tue, 07 Jan 2025 09:27:39 +0000
Received: by outflank-mailman (input) for mailman id 866192;
 Tue, 07 Jan 2025 09:27:37 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=FVI7=T7=amd.com=Michal.Orzel@srs-se1.protection.inumbo.net>)
 id 1tV5s9-0006GX-Jt
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 09:27:37 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20631.outbound.protection.outlook.com
 [2a01:111:f403:2415::631])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a0bcff22-ccd9-11ef-99a4-01e77a169b0f;
 Tue, 07 Jan 2025 10:27:36 +0100 (CET)
Received: from SN4PR0501CA0106.namprd05.prod.outlook.com
 (2603:10b6:803:42::23) by PH7PR12MB8179.namprd12.prod.outlook.com
 (2603:10b6:510:2b8::20) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8314.17; Tue, 7 Jan
 2025 09:27:27 +0000
Received: from SA2PEPF00003F66.namprd04.prod.outlook.com
 (2603:10b6:803:42:cafe::32) by SN4PR0501CA0106.outlook.office365.com
 (2603:10b6:803:42::23) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.9 via Frontend Transport; Tue, 7
 Jan 2025 09:27:27 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SA2PEPF00003F66.mail.protection.outlook.com (10.167.248.41) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8335.7 via Frontend Transport; Tue, 7 Jan 2025 09:27:27 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 7 Jan
 2025 03:27:26 -0600
Received: from XIR-MICHALO-L1.xilinx.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39
 via Frontend Transport; Tue, 7 Jan 2025 03:27:25 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a0bcff22-ccd9-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=QhPP9zOtuulcME7pU598ReNk6V/w1ONqA/juioyQ0i0NbZ77iybXwdQQTzsmh5p90UzhqranKLimMk4NxlcRzuApud1TUxs+4ivleFyfB8qkbd2eTdJCzIfMGX2YrKcllpWoPUwPUcBGN+kIB1SXTGzf0TSKtZ+IxUWVDN2pYw5daRfcfUiX4Pp7yoFK7T15mlIefvzX2Q+0/ZTzNqTde4+24yVGZVl9tkkZa9RzPZ2GiYR1qd6YmRm+1Y+ISRCqH6CzoVGx2dPTA5wNQSxdq+lv7pz2ls+YFBUGX4Li6QgWtcunTDe+ccMbmJRfcCWABl8kLBNeiQxDB2zxNWb6kA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=pwC+19C6KmOdNMx45oACNtAI5Dl8Ex+euKVyAOWXXBE=;
 b=sznEm9KC/AfJFNgUtx6u5e86U6y8I+KJXLJMAQvC/7SbCClzG31Uf4Wh2lbUgXXxyrMYEK6GIPoH0o3Wxf6QwOzgXM2PeZNyjDVOQAfUIabDWRN6uMm59+CzylYyhLKlq+qE+3BDSIun9FmvDCFsu+P2XtjxGcWBS/7XMul66I2UMCXvjSETKvxfisKBhTcaMjaOVqvB+I2+lrt58SHZGY6yTxkPc/YJYOfy1YdyKFCb5z9X45gZnUzbXrriKkQIPA1xvR+eqitXTGth98LFvtr4SA1kGou8D9zmNSKH3x+dR3YlCVX/Td3F+Mao8EWYs4g8vzVnzs/HwhMX8jT9bA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=pwC+19C6KmOdNMx45oACNtAI5Dl8Ex+euKVyAOWXXBE=;
 b=BKtqm6+YAAOnOIQvUdHNt7vX51v+Ocr4NJHFn/+KlgXzmGBSyePREpHoYhsJu7/Wd8CftkC+5OBkkalQhpxzf0IZFcCgbYAzYiNnjYufWkw36xO9dkyyzhx22jA1F2H0QdmMz+H7yVgOy3YxhO9I5ccwLaaw6BZFhIeTLW3P/fU=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
From: Michal Orzel <michal.orzel@amd.com>
To: <xen-devel@lists.xenproject.org>
CC: Michal Orzel <michal.orzel@amd.com>, "Daniel P. Smith"
	<dpsmith@apertussolutions.com>, Anthony PERARD <anthony.perard@vates.tech>,
	<oleksii.kurochko@gmail.com>
Subject: [for-4.20][PATCH 3/3] xen/flask: Wire up XEN_DOMCTL_set_llc_colors
Date: Tue, 7 Jan 2025 10:27:19 +0100
Message-ID: <20250107092719.26401-4-michal.orzel@amd.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <20250107092719.26401-1-michal.orzel@amd.com>
References: <20250107092719.26401-1-michal.orzel@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB03.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SA2PEPF00003F66:EE_|PH7PR12MB8179:EE_
X-MS-Office365-Filtering-Correlation-Id: 507a51dd-1cd7-42f2-8d51-08dd2efd8094
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|376014|1800799024|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?yjKdFq81wP7xRgUL9b8lR42mmuO6gpHrrxwUB2GISz+YLGC6pQNQlUMwgflp?=
 =?us-ascii?Q?4UXf5QqFb1jC2wFCI2ntXQN7CUqQfLCXI+P4MXxQmfkS3/Q3In2nzJIdvewq?=
 =?us-ascii?Q?XUNwrd1ycuGj49erWzxMIvqxZdSexilnd2DbW9F3ETDQ+ojdXcNelmAx+3k8?=
 =?us-ascii?Q?xmBv/XvKNPqipz8dLoIGDC2ofWXO5Cn62ORYAUsnYZgwTsE0QQJxXWBxJ4F4?=
 =?us-ascii?Q?uMLcSSvbr2xGu3y3wLRrFOZwt5dPc5+GRv+uBR5NIGsPPIvJnlG5LCir97Hz?=
 =?us-ascii?Q?5JWTKzDrqnTi/GxtJgF3H8Jm3wkGgLAnOo3jrAQEf1Uqax5gVWCm8SQr4+W6?=
 =?us-ascii?Q?YnRhVPbQwXWwXJhZEoo16QIN7WRHXgfu8BjTajkoSEQkqfZ/umankoxQbk35?=
 =?us-ascii?Q?bR3iZfZIgUzrRIaI8MW9ysEbOwvpsYalJua5gm91rjMowvFv3kS0u2idOvdy?=
 =?us-ascii?Q?52sPmnixh3c7o2FgDbbqrwW3i+o1STCZmgkEb0ezx0pK9jeKSpkIDDSse7VH?=
 =?us-ascii?Q?VdqcTNSwYmKJAmYJCGk7M9tEdq7jllYwlgWS1B8nhaEW3k7jGOJOmg8CydVj?=
 =?us-ascii?Q?ZWzTHh1hiQv+ZsgF04V7zUz45sYCTzLOcd20hGwjSRaEzB0Ev5uILqvdgnRL?=
 =?us-ascii?Q?M+BZwQ6OQ9Q4QE4hqmkNlkjMM5U0Nw+k9v6LjhwFn7zBG8jS07WQoeZzky5u?=
 =?us-ascii?Q?DQrdDd4XKNKSTZLxrhjVLgsJX7yOlfhdINZs6BW/RBzXnRtnsGh7ajMS5pNU?=
 =?us-ascii?Q?ijtPsUQCsGo1Ak8NfDTQDzZl9qMZrg10Dy0Kz6ffTn07cTcDDL7YRw+9dBFY?=
 =?us-ascii?Q?za8qNnHonQXFukBuip2qdMxmZV9duxku49tZiY0FwkTqEZkrfTmJJ4RKnWx5?=
 =?us-ascii?Q?92E0oPW/ANl86sUsM8Vj/BL7asQJBARI2cVNkk+bLCCLg0JQ23r98nPfq4Ig?=
 =?us-ascii?Q?vpfFT1ouIQs2wIrODoxb0cJBEXFvIcwDiPnwGq7hUdBb0cvvqRa4EdErr3Dh?=
 =?us-ascii?Q?3HtwkFYHFdVn5mB1g/6bPd40IJg/QqwFIO7h/G0PsnUvc9J1yevZJ2m+lyiK?=
 =?us-ascii?Q?kW7An3PeTGv84rnoPMTM8uCMfCF0RiFqd4lYaZz3Dt1owoDmDrbqnkCqo6nl?=
 =?us-ascii?Q?Afpif41bpXRyRqTHQRso6PM8JnVGn76TUJQ2jgNfutHltISwIq+0Nd9MOB84?=
 =?us-ascii?Q?Ji86MfYdiCH+mOLEoXJltkC8P+k61VGn4CmSJCaxt0T+zKZRXkk+acybGDv9?=
 =?us-ascii?Q?Ml1IOl69anYhTiRSQII5TwlAaZg9Jfz59YNz7hNOksQQEvvlw37quvcQbpuU?=
 =?us-ascii?Q?mL3RYxGoQ3zCTobind4wzi6x1H91hzOXrCkimrlin3l2fnZGL7Kbtuw4a6L1?=
 =?us-ascii?Q?6zS8+fmqMqf6xDQh1CqUsF7cYKJ2eK1Lczs+yKt1bkTb8+nsftrFk2dQWqWD?=
 =?us-ascii?Q?xaALUSXNLmozE/MiC/uCC2Zf8f7fF206AnyOW/+zskdFOFlsRVUdpchHRvts?=
 =?us-ascii?Q?dmyBPRf9H6sJzvQ=3D?=
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:(13230040)(36860700013)(376014)(1800799024)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jan 2025 09:27:27.4519
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 507a51dd-1cd7-42f2-8d51-08dd2efd8094
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:
	SA2PEPF00003F66.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB8179

Addition of FLASK permission for this hypercall was overlooked in the
original patch. Fix it. Setting LLC colors is only possible during domain
creation.

Fixes: 6985aa5e0c3c ("xen: extend domctl interface for cache coloring")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
---
 tools/flask/policy/modules/xen.if   | 2 +-
 xen/xsm/flask/hooks.c               | 3 +++
 xen/xsm/flask/policy/access_vectors | 2 ++
 3 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/tools/flask/policy/modules/xen.if b/tools/flask/policy/modules/xen.if
index def60da88301..f7cf7c43c80b 100644
--- a/tools/flask/policy/modules/xen.if
+++ b/tools/flask/policy/modules/xen.if
@@ -54,7 +54,7 @@ define(`create_domain_common', `
 	allow $1 $2:domain2 { set_cpu_policy settsc setscheduler setclaim
 			set_vnumainfo get_vnumainfo cacheflush
 			psr_cmt_op psr_alloc soft_reset
-			resource_map get_cpu_policy vuart_op };
+			resource_map get_cpu_policy vuart_op set_llc_colors };
 	allow $1 $2:security check_context;
 	allow $1 $2:shadow enable;
 	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op updatemp };
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index e263e745d441..14d84df9cad6 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -847,6 +847,9 @@ static int cf_check flask_domctl(struct domain *d, unsigned int cmd,
     case XEN_DOMCTL_dt_overlay:
         return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__DT_OVERLAY);
 
+    case XEN_DOMCTL_set_llc_colors:
+        return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__SET_LLC_COLORS);
+
     default:
         return avc_unknown_permission("domctl", cmd);
     }
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index 78fe37583b18..320d77706dee 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -255,6 +255,8 @@ class domain2
     vuart_op
 # XEN_DOMCTL_dt_overlay
     dt_overlay
+# XEN_DOMCTL_set_llc_colors
+    set_llc_colors
 }
 
 # Similar to class domain, but primarily contains domctls related to HVM domains
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Tue Jan 07 09:27:39 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 09:27:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866191.1277494 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV5sB-0006ke-93; Tue, 07 Jan 2025 09:27:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866191.1277494; Tue, 07 Jan 2025 09:27:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV5sB-0006kV-3w; Tue, 07 Jan 2025 09:27:39 +0000
Received: by outflank-mailman (input) for mailman id 866191;
 Tue, 07 Jan 2025 09:27:37 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=FVI7=T7=amd.com=Michal.Orzel@srs-se1.protection.inumbo.net>)
 id 1tV5s9-0006GX-B0
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 09:27:37 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20621.outbound.protection.outlook.com
 [2a01:111:f403:200a::621])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a1268978-ccd9-11ef-99a4-01e77a169b0f;
 Tue, 07 Jan 2025 10:27:35 +0100 (CET)
Received: from BY1P220CA0012.NAMP220.PROD.OUTLOOK.COM (2603:10b6:a03:59d::8)
 by IA0PR12MB7577.namprd12.prod.outlook.com (2603:10b6:208:43e::20) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8314.17; Tue, 7 Jan
 2025 09:27:26 +0000
Received: from SJ5PEPF000001E9.namprd05.prod.outlook.com
 (2603:10b6:a03:59d:cafe::c) by BY1P220CA0012.outlook.office365.com
 (2603:10b6:a03:59d::8) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8335.10 via Frontend Transport; Tue,
 7 Jan 2025 09:27:26 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ5PEPF000001E9.mail.protection.outlook.com (10.167.242.197) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8335.7 via Frontend Transport; Tue, 7 Jan 2025 09:27:26 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 7 Jan
 2025 03:27:25 -0600
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 7 Jan
 2025 03:27:25 -0600
Received: from XIR-MICHALO-L1.xilinx.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39
 via Frontend Transport; Tue, 7 Jan 2025 03:27:24 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a1268978-ccd9-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=SXpJhHZ5Aa7nEUxxcttXY9P8C7Y6SzPiDE64Mv8li7JmV82VR6jV67qVC7qjZAy+xvYBQrqEGfLRMC2tnFrPlSPp/22Ti00Qjk6zKhy/o2gGt7myrSGNjuEFs9IGItRUGz4QILKCWSvY0NWaMt4bAkxUWFgaH3O3wqbaImP+1CRIWhT275sCSxKeV+xpU/VFSSqPrHhWAkuSoum0tW1ysgOPOldnX/DWko28PnT9Xm6B+lK/Ub1CZ4yDNXH+HAB62AzYQzv/NIkrrSZfVmYV+byumFOpcLD78VgNYxChU6YYhJh0yF987SL0s+mvCu9oA4eupi/4ohFCbHGcrdtD6A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=70MCCoZKVTF+PJ0//NYA+xBhWbE0DzeYXdUvfh/3Myg=;
 b=zJFbMUNKwsMvrQHeteHLsYR4b60q/r7EURIOPdWiUWfTEZqkdmEA/g2SF9XifS8a0/HJGxEi5K7WCYb6nwXItAnk0Z5HLUgnwRi0GB749tvIaqUuV+8AqCgc5FGLhbW1aAULrniG6qf2aYIROW7WRacTuOKMlttbIDHgdMdVbrktmH+0X33Mndq3HbKQgXLLbfRMTNehEvvqurFCCZ+rQn8TzmPZrk7PHX8DlEuEgMRvl39cZiip9VEYrUqbJCsJMOzv2efEnwqFGdSE8hUzOVgITGbuz5qjCzQ/NQjL3IbG0aa/8XGuLasa/pHnGhpDy7M2eo+kcSsF4tToYj1zrw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=70MCCoZKVTF+PJ0//NYA+xBhWbE0DzeYXdUvfh/3Myg=;
 b=Ok7Ye5xewkXJgdAgFpbO1ohZWA1orConmveBIJ9W1YST15cwlDO/fs1pFSEXGwNvDCdYjaqBfLahY9CQS3h+waq37dIz4pIS33+BiKUD3gqhHzu52y6uHX3AJZuaQKMRYS3rLl0VDdeFqrmI54ma01ASH6Ezkxje0VLtHXDcUv4=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Michal Orzel <michal.orzel@amd.com>
To: <xen-devel@lists.xenproject.org>
CC: Michal Orzel <michal.orzel@amd.com>, "Daniel P. Smith"
	<dpsmith@apertussolutions.com>, Anthony PERARD <anthony.perard@vates.tech>,
	<oleksii.kurochko@gmail.com>
Subject: [for-4.20][PATCH 2/3] xen/flask: Wire up XEN_DOMCTL_dt_overlay
Date: Tue, 7 Jan 2025 10:27:18 +0100
Message-ID: <20250107092719.26401-3-michal.orzel@amd.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <20250107092719.26401-1-michal.orzel@amd.com>
References: <20250107092719.26401-1-michal.orzel@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB05.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001E9:EE_|IA0PR12MB7577:EE_
X-MS-Office365-Filtering-Correlation-Id: 9194685e-b576-40ea-ad24-08dd2efd7fde
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|36860700013|376014|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?4Yn/c+bYDx+NpBQoqNPDfRoF4Jctqplg7ZZMDpq4odjb/VVZreMvcwNbUS7+?=
 =?us-ascii?Q?7XnzTwj6ap/ZnzlIHYqS3xkUK40BP1Nde7f8tWUW3+p54Na8+BevEl0uWbJb?=
 =?us-ascii?Q?uNErUq9YZQ01ok17gbXIgPfh39OdQ25YmsECJ5VE6JlHrEFOFoR9xeojon+F?=
 =?us-ascii?Q?WHqctwk6c3Zmb6INOnRcdv4j0ZeCyaUrs5+6BigRfnRgKqeZvk1L7xMuK9nB?=
 =?us-ascii?Q?Dsu9jMG05NO5EhZyz9Uit9oELtRDUmjpkH8mCdhMPmo6z1iWh7XeVmyzrjsY?=
 =?us-ascii?Q?WHvGSF/26uf/Hk6Mg8T6CdGfQS53/JryqIkyX9OXG3AxOda74nRyH+FSc9HA?=
 =?us-ascii?Q?UVpaAHoWECHf5BzWQcEkusY4BRAcfQ6xmox57agr561sVL1D14JqFxC/Wcz0?=
 =?us-ascii?Q?qNKrrOXcKMhrmLO/pNCil6/+sc3EOcN4Oa7u/9QhqTi0PsU9XU+yaRlT+S9C?=
 =?us-ascii?Q?LyAoPV/FYoUgYpGR/63E3Uoi0zmLbe1QxzXHSP2J5hxRnAYP03uRlE8rDPqq?=
 =?us-ascii?Q?JPf0xi3P2ZcY7o+USfjFB358t5DoJLs8ibqOBCeIdS2sEmEyo4Nsv+aas3F6?=
 =?us-ascii?Q?10t3lBkQdxudRJ5Rm/AHcdwT/XhywLeQ9I7n+ENlQZb/WGR7wT+OdG2OrEJy?=
 =?us-ascii?Q?PB5qogGLkBgYJt1ulT1J9AhruAbzxbUZsG1SCm5S4JlwzpF5gxSFTdw7VWiM?=
 =?us-ascii?Q?lNAQ4SlfRpNhB5ixDYQBEdQWvAnlbIvnTsFhVc1hA6mVyxGqV51D67maUf+9?=
 =?us-ascii?Q?Ta+uSNoTLiZ5LV+prdJJWDYn9uEJeXmuDGfHSKj3jyr0kB3Axe5rZUtde+y8?=
 =?us-ascii?Q?zSRgjbFXRtkUsJx2RJRjTrU9TbUecPfbyevCgH2+yXmfjtB0SPJpwFmFp3ZQ?=
 =?us-ascii?Q?YQ0SRCrhbfeqRBmToIKuiRoVYBBrpeIr74uQ+lujyPyJahsxh128YTyL0Swz?=
 =?us-ascii?Q?yL4nvMg6E5I5Qcm+fA3xNm65/51coJOfvjQ86DxNkxqboh3eooObTHF5NlPn?=
 =?us-ascii?Q?rZHUShi1UK0Ji6GNn0E82YK9Lfa6+QK8bYQUUy3DEB2+83rXIaoApPaw/O37?=
 =?us-ascii?Q?8aKFnmwf7xEs3hJiWdp101RsFT7U81AdUcGjGtIIjPWxp8zOO8vCr9U1Xf/e?=
 =?us-ascii?Q?jHlXofyUrOaqvMzlGQ30aP39XKc5P5rV6298JYedagm2vduVifNdDRViPtZk?=
 =?us-ascii?Q?nxmqNvck6X48d2lkx6ejcvQ2vfEMB6JSpzaFS1P/PlZIYCBf1cvRS+1YcIIF?=
 =?us-ascii?Q?gvRKy8/9V6+RHn2fs2qT/nhJwiCKIElHGR3S74pDMSccRba+9o/aUYBdMm1Q?=
 =?us-ascii?Q?f+Ug3T9Um9mGw0kPpl9D4UxuINVTa/VE6S4ra/xMH3BWSew81o2Wyaxuhx6a?=
 =?us-ascii?Q?KQfOafG5cycgl9iW9lzxrw5iU9pLiol9BSgmuzdMklbKxbEdL9eRi3WAVGmS?=
 =?us-ascii?Q?n8HF/toDMYpUk1MnUS8tayhRXCNtr3QS3uglmix7PjkMqMISVKxrezmpiusO?=
 =?us-ascii?Q?2+5QMBRLXqKw7CI=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(376014)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jan 2025 09:27:26.1819
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 9194685e-b576-40ea-ad24-08dd2efd7fde
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF000001E9.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB7577

Addition of FLASK permission for this hypercall was overlooked in the
original patch. Fix it. The only dt overlay operation is attaching that can
happen only after the domain is created. Dom0 can attach overlay to itself
as well.

Fixes: 4c733873b5c2 ("xen/arm: Add XEN_DOMCTL_dt_overlay and device attachment to domains")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
---
 tools/flask/policy/modules/dom0.te  | 2 +-
 tools/flask/policy/modules/xen.if   | 2 +-
 xen/xsm/flask/hooks.c               | 3 +++
 xen/xsm/flask/policy/access_vectors | 2 ++
 4 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/tools/flask/policy/modules/dom0.te b/tools/flask/policy/modules/dom0.te
index 16b8c9646d1b..f148bfbf274e 100644
--- a/tools/flask/policy/modules/dom0.te
+++ b/tools/flask/policy/modules/dom0.te
@@ -40,7 +40,7 @@ allow dom0_t dom0_t:domain {
 };
 allow dom0_t dom0_t:domain2 {
 	set_cpu_policy gettsc settsc setscheduler set_vnumainfo
-	get_vnumainfo psr_cmt_op psr_alloc get_cpu_policy
+	get_vnumainfo psr_cmt_op psr_alloc get_cpu_policy dt_overlay
 };
 allow dom0_t dom0_t:resource { add remove };
 
diff --git a/tools/flask/policy/modules/xen.if b/tools/flask/policy/modules/xen.if
index ba9e91d30201..def60da88301 100644
--- a/tools/flask/policy/modules/xen.if
+++ b/tools/flask/policy/modules/xen.if
@@ -94,7 +94,7 @@ define(`manage_domain', `
 			getaddrsize pause unpause trigger shutdown destroy
 			setaffinity setdomainmaxmem getscheduler resume
 			setpodtarget getpodtarget getpagingmempool setpagingmempool };
-    allow $1 $2:domain2 set_vnumainfo;
+    allow $1 $2:domain2 { set_vnumainfo dt_overlay };
 ')
 
 # migrate_domain_out(priv, target)
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 5118f86cf030..e263e745d441 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -844,6 +844,9 @@ static int cf_check flask_domctl(struct domain *d, unsigned int cmd,
     case XEN_DOMCTL_set_paging_mempool_size:
         return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETPAGINGMEMPOOL);
 
+    case XEN_DOMCTL_dt_overlay:
+        return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__DT_OVERLAY);
+
     default:
         return avc_unknown_permission("domctl", cmd);
     }
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index 7cbdb7ea6408..78fe37583b18 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -253,6 +253,8 @@ class domain2
     get_cpu_policy
 # XEN_DOMCTL_vuart_op
     vuart_op
+# XEN_DOMCTL_dt_overlay
+    dt_overlay
 }
 
 # Similar to class domain, but primarily contains domctls related to HVM domains
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Tue Jan 07 09:27:39 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 09:27:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866190.1277483 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV5s7-0006Uk-Vf; Tue, 07 Jan 2025 09:27:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866190.1277483; Tue, 07 Jan 2025 09:27:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV5s7-0006Ub-Sz; Tue, 07 Jan 2025 09:27:35 +0000
Received: by outflank-mailman (input) for mailman id 866190;
 Tue, 07 Jan 2025 09:27:34 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=FVI7=T7=amd.com=Michal.Orzel@srs-se1.protection.inumbo.net>)
 id 1tV5s6-0006GX-CQ
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 09:27:34 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20613.outbound.protection.outlook.com
 [2a01:111:f403:200a::613])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9e7e19ba-ccd9-11ef-99a4-01e77a169b0f;
 Tue, 07 Jan 2025 10:27:32 +0100 (CET)
Received: from BY1P220CA0010.NAMP220.PROD.OUTLOOK.COM (2603:10b6:a03:59d::12)
 by PH7PR12MB5926.namprd12.prod.outlook.com (2603:10b6:510:1d9::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8314.17; Tue, 7 Jan
 2025 09:27:24 +0000
Received: from SJ5PEPF000001E9.namprd05.prod.outlook.com
 (2603:10b6:a03:59d:cafe::5d) by BY1P220CA0010.outlook.office365.com
 (2603:10b6:a03:59d::12) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8314.18 via Frontend Transport; Tue,
 7 Jan 2025 09:27:24 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ5PEPF000001E9.mail.protection.outlook.com (10.167.242.197) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8335.7 via Frontend Transport; Tue, 7 Jan 2025 09:27:23 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 7 Jan
 2025 03:27:22 -0600
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 7 Jan
 2025 03:27:22 -0600
Received: from XIR-MICHALO-L1.xilinx.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39
 via Frontend Transport; Tue, 7 Jan 2025 03:27:21 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9e7e19ba-ccd9-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=kz0mLgDPlB8BTI20qvcKEvx6D4TJU8bNXj2Yhjrpva7hjTjxIrS4Vj7C1z4RaEPBqPgGD8jdjvX7vrfKxl/eedzgDbOzlQX5MpGgH1H3xYiFCgPn2SS9oR5cskH1YVoRguiM9u6KzrDVpG5t11vQyYeIQihXClvUMMPFZO21fE9BvzQEiRJbQoTdYvlofaHMMGXZQIHWh5d20LDd1EraqWEeTKSIAXh1tmU/5txGrfb8NhWqNQFy8x110yLu7++38VCY/34aHCaIcUXUiMJpyO7pdZZJfcgk8bqhnvK0Qohn1aaeXLwtQ2LKmbmMivWfAT9k9AvLeCRBtc8PiWQ6xA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=zA11wOj5gZzVwCBIqPYpvQZoZdMx4eFFL4WzObr/tIE=;
 b=QH3YKzbirCufb8Bk9uJiYG1tRqn6qE7eqmahW8z3mFBHS3pcT04nwAS2wacXwaVm7CwXyLjuksFmshLM09k8LNkG14eTgN80G43I+ixEUJZDO3YJtZpaAoIa2fxwcVsUz4nuN+4cEvaW7RZaG3+Az9xcghB1i5kRCYxBPKd2VqyVih1QneL+dt3COCCBlDJi2YZ4GAlS+XTnfykpDUfS4W63bk4wlXVJCRect9sVDEGDWpfb8vQBa5EKV4Oc7nuDyO+pH9Ai4HWvvXUKYYG3Fg3i5qR3+FbNhoI6C1O9ID6vvFFLT2VdDLiIjneUOlq9tdxczKO77Jxx0oPIdwTRSQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=zA11wOj5gZzVwCBIqPYpvQZoZdMx4eFFL4WzObr/tIE=;
 b=dTU/Mj1qlcknu3JIfgr23mLfK60ZVupx5ir8TfndMWoUEQ0SA68Iy1rktdM+9ImrWjn42sy5SHC3GV5joULo2HHaicGWPd1WQTUOXI8kBUQahxo6rcFm7Oz0dt5m1NwpHEW4MheI9Axa5pH3bAEVg/I3p4RIbtlODY6U+1cj7r4=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Michal Orzel <michal.orzel@amd.com>
To: <xen-devel@lists.xenproject.org>
CC: Michal Orzel <michal.orzel@amd.com>, "Daniel P. Smith"
	<dpsmith@apertussolutions.com>, Anthony PERARD <anthony.perard@vates.tech>,
	<oleksii.kurochko@gmail.com>
Subject: [for-4.20][PATCH 0/3] xen/flask: Wire up missing hypercalls
Date: Tue, 7 Jan 2025 10:27:16 +0100
Message-ID: <20250107092719.26401-1-michal.orzel@amd.com>
X-Mailer: git-send-email 2.25.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB05.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001E9:EE_|PH7PR12MB5926:EE_
X-MS-Office365-Filtering-Correlation-Id: 186cb170-621c-40e7-7032-08dd2efd7e5c
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|36860700013|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?F50fqFobckXtDGsfi/J3rJA0eUKvpKgG1ckeC6pHN0rwtQznCjFX4OWyY1O/?=
 =?us-ascii?Q?aXjq29h/7bbKB5Q3lnctC+hbO2paRfYBHs2qyjKUorTNc3+PZaxtUAXFd48t?=
 =?us-ascii?Q?SgXmi8YE20SJz25j3ACyUkYFYpfmSrIAetGgc3nnyUXqk4P3OuO3CFThjVNu?=
 =?us-ascii?Q?fXMD3VxbulqwGdg47f8+pKb+DGbKEA9D8jK644emmMOvLrDEdrMS0gnc34Gg?=
 =?us-ascii?Q?g7Cejtlcyrd4Jc2SWGaCJapkcrkeY90Vs+ikl7auy26iA/awy+LuxNC9E9zd?=
 =?us-ascii?Q?T/2ttXtJpYhBdLnQMWBot+y3gIoBEaqBIJKh+DL/MPFsAeDyevol8gNG9Lqn?=
 =?us-ascii?Q?geavYAZR3ekMBD9fbvtq2L0IfChopiKzjfC87gIIEQFXDIJ/yQm59rYZma70?=
 =?us-ascii?Q?LbsS63MK6VZPc7NzFbbOVbaZBRQLcDtmaHHOy5gZx0LzwTHUHP/zwZY+wtJo?=
 =?us-ascii?Q?a9rGNNoSpw5z/gd2oPI9Y3kbR1Vci2zymIw9XY1zBO7Lf7M9p+VOP0RjAVgx?=
 =?us-ascii?Q?oXyGhOe8FPV/Lk/7EHSSNd3ERofgbuBC/aHb3sQsU/1xVjXPPl0VNonu0EIG?=
 =?us-ascii?Q?wrq91oWccnc7s9muIgEIO5fvjSO/ElZrtclkrVUpKhUFPfGNH7q/VRHdqZoE?=
 =?us-ascii?Q?/VX7HAOi/F6Y11+z+nuiZ1SpKLcMG5Tn9qVzVdaaIYN9s//Fe33fikdvuxuV?=
 =?us-ascii?Q?XSz9Y62DAeult7RwD2qSvbsf6p9sJIaLrGgGCFLvmdfQ/TbivnvKNdbBxu9C?=
 =?us-ascii?Q?PF6PPusQVYJjXsWX74pA1p2jHTmrd39dNW1Fg0nQZqJsJ/mZMgi/7GrRBtlG?=
 =?us-ascii?Q?m1o9YFqN+uLELX97RwdopD2WTPScFzbP8Xq+XAPS3oFM5R0NRdb/TjEHCyQY?=
 =?us-ascii?Q?FsJXmlVXDTeCecbT5zh1yDBeAxdvHAHge2vX/6ifWVC8ul/XyNbNkZCQT4TH?=
 =?us-ascii?Q?Yiqfq8PkieyBj6GNfDt9Xao7cK0HAilPAORylQjp39v4WNwRVpLQIkg4/fKz?=
 =?us-ascii?Q?xwXKAwzpZqZVobKYOunlgLeE4lNUwzXJdlbXCFD2VubAdaA4ywqcLZsKPwXX?=
 =?us-ascii?Q?Ug/KEiGA5+o8lqYhA6CWHQwJ9t42JiclUC3GyMfmiY3HOA3ThFpy5Ru9RNGG?=
 =?us-ascii?Q?Aw96eVIhv+gciKhWVI9nLqbew+KfzRrynO5l9F6v4o2fy49D+2PZsxGK5Vtv?=
 =?us-ascii?Q?5D6vMZe7cTXgnN5ZavZDEKjVy6VWvW0qwpmtsbOGFgBpkpmyG8GoRwV3Wzlo?=
 =?us-ascii?Q?PPdtBXfvgdgYcQQ2xDS2DMZMFdQ5a8Xvy6VA41ASXjkuV2ylnQM25/cBO1Eo?=
 =?us-ascii?Q?S64TQxxnegtOVPQjmnaIAJ/6DtEY1WXsPGu4Ua6CVKzVusOyJQK87VMdrgUR?=
 =?us-ascii?Q?KfnhkSGPjypBeyBc4zlXf+TKl1VNuZsKQLMO7sNCziYyJM67wwaTLlv3J9wq?=
 =?us-ascii?Q?1Ln+I3c+anLmJqWfwDQDU5CT1MovX7vmbYiqJrzuef3kCHZnHt0kHb1AjLDW?=
 =?us-ascii?Q?3x08fdpX2P+uZ7s=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(376014)(36860700013)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jan 2025 09:27:23.6506
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 186cb170-621c-40e7-7032-08dd2efd7e5c
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF000001E9.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB5926

It's been noted by Juergen that recently added XEN_DOMCTL_set_llc_colors
is not wired up in FLASK. While preparing a fix, I noticed two other Arm
hypercalls from the past that were missing the linking as well. These two
are latent bugs while the LLC one is a release blocker for 4.20.

Michal Orzel (3):
  xen/flask: Wire up XEN_DOMCTL_vuart_op
  xen/flask: Wire up XEN_DOMCTL_dt_overlay
  xen/flask: Wire up XEN_DOMCTL_set_llc_colors

 tools/flask/policy/modules/dom0.te  | 2 +-
 tools/flask/policy/modules/xen.if   | 4 ++--
 xen/xsm/flask/hooks.c               | 9 +++++++++
 xen/xsm/flask/policy/access_vectors | 6 ++++++
 4 files changed, 18 insertions(+), 3 deletions(-)

-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Tue Jan 07 09:27:40 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 09:27:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866189.1277473 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV5s6-0006Gp-PO; Tue, 07 Jan 2025 09:27:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866189.1277473; Tue, 07 Jan 2025 09:27:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV5s6-0006Gi-Md; Tue, 07 Jan 2025 09:27:34 +0000
Received: by outflank-mailman (input) for mailman id 866189;
 Tue, 07 Jan 2025 09:27:33 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=FVI7=T7=amd.com=Michal.Orzel@srs-se1.protection.inumbo.net>)
 id 1tV5s5-0006GX-N6
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 09:27:33 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on2062d.outbound.protection.outlook.com
 [2a01:111:f403:200a::62d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9d805e6d-ccd9-11ef-99a4-01e77a169b0f;
 Tue, 07 Jan 2025 10:27:31 +0100 (CET)
Received: from SA1P222CA0147.NAMP222.PROD.OUTLOOK.COM (2603:10b6:806:3c2::11)
 by MN0PR12MB6365.namprd12.prod.outlook.com (2603:10b6:208:3c2::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8335.10; Tue, 7 Jan
 2025 09:27:25 +0000
Received: from SA2PEPF00003F63.namprd04.prod.outlook.com
 (2603:10b6:806:3c2:cafe::be) by SA1P222CA0147.outlook.office365.com
 (2603:10b6:806:3c2::11) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8314.18 via Frontend Transport; Tue,
 7 Jan 2025 09:27:25 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SA2PEPF00003F63.mail.protection.outlook.com (10.167.248.38) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8335.7 via Frontend Transport; Tue, 7 Jan 2025 09:27:24 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 7 Jan
 2025 03:27:24 -0600
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 7 Jan
 2025 03:27:23 -0600
Received: from XIR-MICHALO-L1.xilinx.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39
 via Frontend Transport; Tue, 7 Jan 2025 03:27:22 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9d805e6d-ccd9-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=irVQEiLo3ipvs5wTS5IKSTDEHFKwwjUBigV6CyCj6mbH3DV+pPV2Cv3l+S/wF0toqJszOSj3MNocRNlqKff9217KSRgFCtKMv1q8Fml9/yxGVLlBf54h8KewPlqgt0D2Yq1HmMyOLRthjgbseCBUrNU1pGz6d08acuvjNTdYp2JbytGqybK0AY9f51OPFoQFBJpx2h9dmrKFnqIa04K8J6ktlC3JcsnmowXcb/sgeqmJXbDmyCtdsfRWKoXf5toSTCU/ZmTnSGWlA6g10vDc0juAXGkseHGkXgyj1trGfvZbWQKPa3Ai9NKuNit1KIzQtdvID/nfxRSBnfynNDWFrg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=Diko53aLl2QpyDZolfGn/KpZfdptQBjhr/vtvQsxei8=;
 b=gBw1rHN8uAC6sVTSjLlc4G7csR81iJQzH2q+cd5B4gnhoot5oZP6DKPB95PPYEcmyV395ZFVfyXyDFSWt9mkdOTviEEq+Ud6S3wsP0NLF9HJQBBF1BJpczhb9RCj0pVICRWxZ1XMbzsJSDT9LEe65zQRNNz9aCm2hKuxmSQag68F5derEGpTFTApD9Rkr8O6ch+ONtImCazbr6hSnHww99IW/BP4TmSDN+6n0asBRtj6+Dnr5ElGhf8sFRqagGLDLAe+XORhhOOrwjA7ju8pIb0DMvfKHsfCAxvxL9eJ2q+0mVUKN59jpVxRcOnBlGtfvF5ySLhMDKZVEsdlTL5JzQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Diko53aLl2QpyDZolfGn/KpZfdptQBjhr/vtvQsxei8=;
 b=t0MkwD8T3dfT/z23aGBVuiRn4v8BBIXAIOlCDEadRHG3IKC+KBXIRG3KvpethyD6pVyigTRnhDhX72srbYmOMV0binkJcE2YQMb3cwJa/tIKJAUwmFOxO/40wKnp4NQPiQ/tG2S3FMlc8d/0liTPR6nNBwiMokV4iuYfTwcSU6k=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
From: Michal Orzel <michal.orzel@amd.com>
To: <xen-devel@lists.xenproject.org>
CC: Michal Orzel <michal.orzel@amd.com>, "Daniel P. Smith"
	<dpsmith@apertussolutions.com>, Anthony PERARD <anthony.perard@vates.tech>,
	<oleksii.kurochko@gmail.com>
Subject: [for-4.20][PATCH 1/3] xen/flask: Wire up XEN_DOMCTL_vuart_op
Date: Tue, 7 Jan 2025 10:27:17 +0100
Message-ID: <20250107092719.26401-2-michal.orzel@amd.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <20250107092719.26401-1-michal.orzel@amd.com>
References: <20250107092719.26401-1-michal.orzel@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB05.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SA2PEPF00003F63:EE_|MN0PR12MB6365:EE_
X-MS-Office365-Filtering-Correlation-Id: 4b4da6af-5ce5-4792-3d9a-08dd2efd7f0c
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|82310400026|376014|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?r9qaiclMevq6CIDruqau5iimUZab8oRSfwi1BkgMWkFDJOY55Pu00r2n98Io?=
 =?us-ascii?Q?1wc+tz+GXfaYqO/Fot8yJFFNkS4C4O52QfrN4M1QnH1g+F5dUYLXWBhjL5Wp?=
 =?us-ascii?Q?zTzkmlqWOQmRfQIXunQ2hS7ND8TkNnw6erKyMBksWGMS3tmuGjK34y/QZ1RN?=
 =?us-ascii?Q?TpyjHQ3XdBJTqnHumxY+tbxkwmGpPAwvi0mr6txjzP0B3+4rLhLUjemYGgWt?=
 =?us-ascii?Q?hi/vdKxRiN0uyd7qUFHorqUJ/QhA5aeG4QoWD93azx612NZl6RlUJINQLDr6?=
 =?us-ascii?Q?rqGE22bwtGkX1DzJxWgtfEM4meUKoV/8lG33YLESPNejULoyKPAFLkWdC/o8?=
 =?us-ascii?Q?p77WK6H/yGPyIF3vL6+92uOzU3Ebl1p8JsYCAebTZldFavIHWxOYzyKsoxyV?=
 =?us-ascii?Q?KqUEGUhdQszne4m+bDSuJueuXXcO9uPYwMQvnFJgPZkMsRHWy9MbUiQP0H1l?=
 =?us-ascii?Q?r5dh2RH//zvNgUrahMb8qYZQwNwYeQtoBrghj0ciYOVRV4aHH7Oenajmb526?=
 =?us-ascii?Q?rZqj8UPEpu6/QfLnIFa/Xxh3fNa1TVneZlpNs5rGTJXZ87PANbcZnHlbBawK?=
 =?us-ascii?Q?liSeWTdmE6mUPwVKXHI60VqnZ8jRUG/XMg1JcYQMkzUPTLjDT53bQiTXagln?=
 =?us-ascii?Q?lcpZvUiB0GXkMcdfl/kyZPOjshsxsZCtY2FFoPaN5xCmgRRhE4yBpy2LzI9F?=
 =?us-ascii?Q?FFBukzA8hvgE7FOWIHesG77uaOKu+sNSFbECwCs6uHky5YLLhGplHjMBhaxt?=
 =?us-ascii?Q?F+x/ntdId61Qh6YvIcLWWb1LCwVLV1bQegeX5bzGJDQFtzOyeL8tEAQp0EJD?=
 =?us-ascii?Q?alZJH9thz+B2Xyr8PNIVxC2kXpjiFBCXeljkBByyf60tlDs2G+nYYM7xdDlQ?=
 =?us-ascii?Q?D9VxZJyraDn7slMxDAIfYpiq6xHZnr71kIZwCLWcFfPwYQOrnGIx3lNccQDv?=
 =?us-ascii?Q?7Hj3nPJUWj3ytiBUNUfnaOVZBii7Wafs1etcx61ofoTvo9uz+7lhhDN6CEgg?=
 =?us-ascii?Q?hQHqLTYrwG8e9tCO8InAfIqeG/6X/cZr0DIGWs8mif88kNDHKWmJFIJB9PjC?=
 =?us-ascii?Q?uCKckXolKjY/ROreG7oG8c8WGFxySConMDVqlRtoHDxtNw+rs0VQURML/KOz?=
 =?us-ascii?Q?PISR2CPTRWLx1wPlxCl+ACVcxIqFQlWpYoVGyQ4p05FxzGQuYBc8I5TjJxR4?=
 =?us-ascii?Q?J3fY8qi7PxJspyOBUEZ7yOh8ps6vshapOIEni8fXLOMpynOE1P7lqRs7ddB9?=
 =?us-ascii?Q?+1AnqKQRylP7qxMCbzqWjVF0DNxqAPnjh/mYOSVwmAjSaQbaeP5ZrfCpGmEY?=
 =?us-ascii?Q?n9iIvz+D3oe6x1DQJhgeUzJPlj2t3To+6zj2zBcTABU8T+aLyjJ+KoWZrmVr?=
 =?us-ascii?Q?WkSp8EMOhoTCiy5vuhBxVILOQNIKXoMGAaaNB3c6VJr1lnCqkQ4vgyha1dz2?=
 =?us-ascii?Q?9UTH83sVKKYOH/l3AFcPLacHk6hCnPWaxXlMrBdv1w4f5GSeqUEeOx2A/Zq5?=
 =?us-ascii?Q?+dA8aSTjfFyX010=3D?=
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:(13230040)(36860700013)(82310400026)(376014)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jan 2025 09:27:24.8809
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 4b4da6af-5ce5-4792-3d9a-08dd2efd7f0c
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:
	SA2PEPF00003F63.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB6365

Addition of FLASK permission for this hypercall was overlooked in the
original patch. Fix it. The only VUART operation is initialization that
can occur only during domain creation.

Fixes: 86039f2e8c20 ("xen/arm: vpl011: Add a new domctl API to initialize vpl011")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
---
 tools/flask/policy/modules/xen.if   | 2 +-
 xen/xsm/flask/hooks.c               | 3 +++
 xen/xsm/flask/policy/access_vectors | 2 ++
 3 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/tools/flask/policy/modules/xen.if b/tools/flask/policy/modules/xen.if
index 11c1562aa5da..ba9e91d30201 100644
--- a/tools/flask/policy/modules/xen.if
+++ b/tools/flask/policy/modules/xen.if
@@ -54,7 +54,7 @@ define(`create_domain_common', `
 	allow $1 $2:domain2 { set_cpu_policy settsc setscheduler setclaim
 			set_vnumainfo get_vnumainfo cacheflush
 			psr_cmt_op psr_alloc soft_reset
-			resource_map get_cpu_policy };
+			resource_map get_cpu_policy vuart_op };
 	allow $1 $2:security check_context;
 	allow $1 $2:shadow enable;
 	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op updatemp };
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 2b4efde6896d..5118f86cf030 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -832,6 +832,9 @@ static int cf_check flask_domctl(struct domain *d, unsigned int cmd,
     case XEN_DOMCTL_soft_reset:
         return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__SOFT_RESET);
 
+    case XEN_DOMCTL_vuart_op:
+        return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__VUART_OP);
+
     case XEN_DOMCTL_get_cpu_policy:
         return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__GET_CPU_POLICY);
 
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index a35e3d4c51e1..7cbdb7ea6408 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -251,6 +251,8 @@ class domain2
     resource_map
 # XEN_DOMCTL_get_cpu_policy
     get_cpu_policy
+# XEN_DOMCTL_vuart_op
+    vuart_op
 }
 
 # Similar to class domain, but primarily contains domctls related to HVM domains
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Tue Jan 07 09:32:55 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 09:32:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866218.1277512 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV5xD-0001i1-55; Tue, 07 Jan 2025 09:32:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866218.1277512; Tue, 07 Jan 2025 09:32:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV5xD-0001hu-2c; Tue, 07 Jan 2025 09:32:51 +0000
Received: by outflank-mailman (input) for mailman id 866218;
 Tue, 07 Jan 2025 09:32:50 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=X79W=T7=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tV5xC-0001ho-31
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 09:32:50 +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 5b50e784-ccda-11ef-99a4-01e77a169b0f;
 Tue, 07 Jan 2025 10:32:48 +0100 (CET)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-4361f796586so157438315e9.3
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 01:32:48 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436611ea423sm599220895e9.2.2025.01.07.01.32.45
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 07 Jan 2025 01:32:47 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5b50e784-ccda-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736242367; x=1736847167; 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=hbNuAPn7hxayP40gKEn2Lsg7pTuI5gIuYSBkaIM8a3g=;
        b=d/dVOdyJjWDzig5NAXgTt1yRuZhmnx1JNQYe0weI8jC+hk6n6KY4dCGQaE4AbrvUuF
         OQiUCF2IwqR9VG0IaaWtko++0ZDar7q9kE3TisehZ0qW1rJv/ucURt7RhlBXOKpqUC1L
         Th8CDm5XmpU8eoyfAaBSRC1f2MUW//FuevJvw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736242367; x=1736847167;
        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=hbNuAPn7hxayP40gKEn2Lsg7pTuI5gIuYSBkaIM8a3g=;
        b=fQocfr/MvYfaqU203TMIbluzOumCnmmgzBppT2C4PXx3pY65Ee4XgFYIhiveAjYPP8
         Irk7dD5jQR/wBukUBghIHavmgkB2glmPV5zeoTlWDB3W7uVsmNV906U1o7/Zoc58d+HA
         suCxxGGNXv3wfluwPq99qxdnGbwJBz2hbzIah/wFsM06yZdRiUQ6dJJWTY8nhHFZT3dv
         QLQe5DP8sByY8qUVfa5RfZWYHU85rwGD7J2d+Rect4osARbkD7CMgaYRcw5togCZ4n98
         sEhE8uR/TsLev/hse4tZYfvA4XKQocpOHtdko1qclyNXFCrahwe9j0CRC49BQ220NQgJ
         KX5g==
X-Forwarded-Encrypted: i=1; AJvYcCXPp9vnrNAQ84LYy7wXoCZ78FNA+eflevi3520XwEyKCUuAyWCV5CDtbDXWBrWHohMczu6KVsHq270=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxrq9zE9zljl+/o2ghJGTXJ22a71EzPq+dQt56tUq7tlfhHiZmn
	CSNPEwGth0rHBiRec5aSLIcgXzQqGSqs6sR6sQmsNN5GcyWfdI7McdDl8dUrc7k=
X-Gm-Gg: ASbGncvLjUJa7eRS/O2GRVr3hW9FSx4TKAiTe6xHrFlez2YIv1CfZRXROo+169KLnFN
	FD2J30S6n97ntWdHAQ9to8WIFXziOtcCLMLx5lkZpBpGLfI3kExF+8J0xMLc3p2RkWusvH7Pkfy
	je2yFTzhUO53+YGsHd4fEg7fvkAsjBdOa1eTGmiBkWEyR9SIHenE3owEJSsJsV5rxdsV5ikkwl1
	Cso9OakDxWdgHhcoL6e/9PaZC/hA6BOlsOQ9DZGn7+Tgxid3aPUNNnY7tMCMw==
X-Google-Smtp-Source: AGHT+IE77CLLM3YGCd/14pEq5ORK2y/OyiPHY51e0671sdQFMopdoXlRdP4mxzp7KExH+LVBRP3azQ==
X-Received: by 2002:a05:600c:1550:b0:431:4f29:9539 with SMTP id 5b1f17b1804b1-43668b5f892mr464048705e9.32.1736242367483;
        Tue, 07 Jan 2025 01:32:47 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: qemu-devel@nongnu.org
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	=?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= <marcandre.lureau@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	xen-devel@lists.xenproject.org
Subject: [PATCH 0/2] xen: error handling and FreeBSD compatibility fixes
Date: Tue,  7 Jan 2025 10:31:38 +0100
Message-ID: <20250107093140.86180-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Hello,

First patch fixes some error handling paths that incorrectly used
error_prepend() in the Xen console driver.  Second patch removes usage
of the 'm' character in scanf directives, as it's not supported on
FreeBSD (see usages of "%ms").

Thanks, Roger.

Roger Pau Monné (2):
  xen/console: fix error handling in xen_console_device_create()
  xen: do not use '%ms' scanf specifier

 hw/char/xen_console.c | 15 +++++++++++----
 hw/xen/xen-bus.c      |  7 +++++--
 2 files changed, 16 insertions(+), 6 deletions(-)
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 07 09:32:57 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 09:32:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866219.1277523 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV5xJ-0001y2-Cc; Tue, 07 Jan 2025 09:32:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866219.1277523; Tue, 07 Jan 2025 09:32:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV5xJ-0001xt-9J; Tue, 07 Jan 2025 09:32:57 +0000
Received: by outflank-mailman (input) for mailman id 866219;
 Tue, 07 Jan 2025 09:32:56 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=X79W=T7=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tV5xI-0001ho-4s
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 09:32:56 +0000
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com
 [2a00:1450:4864:20::434])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5f3aced8-ccda-11ef-99a4-01e77a169b0f;
 Tue, 07 Jan 2025 10:32:54 +0100 (CET)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-385e87b25f0so10082025f8f.0
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 01:32:54 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4366127c4d7sm591188645e9.34.2025.01.07.01.32.52
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 07 Jan 2025 01:32:53 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5f3aced8-ccda-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736242374; x=1736847174; 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=le6xEQUAKXVEdnvKDfxbK1jzAiqE1WDBuz0Ul4Gn8vE=;
        b=NCtGz7epRuTDB0UrihncsKcA5TdRbC3o9Q+MTVrdZxgA4m/wfm+ZSFnevvIq569gws
         0NOIvJsLy2cS73cZWdZh5LmyT4eusMrqjfzPhiYfbRy6FBrLaC4ITT9ioGOcpFFgUREg
         1QfuFmytc76ou8UDpsYJS7C+JnfgnvxxuvdEY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736242374; x=1736847174;
        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=le6xEQUAKXVEdnvKDfxbK1jzAiqE1WDBuz0Ul4Gn8vE=;
        b=X2viTzSZDyAs1lj6gDIFYhrjX/zK7hlSGvvCaDUNq9B3UDKvYOLTpwu7L/ZAchyrK8
         4KOZJ8umkdzDt0kM2XH3UPUCk80H2NFBfueRZcw3ctegC6kPIYGxmRcYEb38191lOYv3
         EKDblabWYhs2vz1pvZqllHMqnH0oTYiaqlutngqEEbTLDQ2Pu4XFr/ndxrXADiMXr6jK
         0Iy+65Xa4c/iWydovTUeuxUPlFIAHlKVosghCqMY2gokMCWWIcpDUY/c04ZaDBrsRnyI
         yZMM3L/JAQlmpbHMDzruxViVIDB/1z9qh6nANmnnEitm9PG5BTL7ltuSoutszRBNQmuJ
         VrAg==
X-Forwarded-Encrypted: i=1; AJvYcCU4KD49iJVMlquNcG6jnYC/lcrWpDGHo544sYP7RLTn3a3mpRguTFh8K6URunyhd+wbp23uJhLp1O0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxIMqdY8my73FlZIuHVs2aeXgVD9IV5ZQs02nlXJgY4tUyCW7DZ
	z27Ojhx0FfPyjpzBNrlavJ6ti7uTTCOV8iauAi1tfLMx+Tzsrc8fXTdKyJ01MnA=
X-Gm-Gg: ASbGncsJVFXhDqfKRwFJ+AtlzOS3QB66mfqbnyLHi9Zk1XKRW1lVjIEJAUmX+tq6CZS
	xISJVO0kcpFRr3GRsd+KgUzG1RUadc79Cy2QWfdY8Y33DWUDDZxtRAhD9JaeTwqMPXu0qhqD1Sb
	waZUMo6c+3OBABlxYkBh6pKyEg8IWM7MAfhTLVeMXhdeMfZJn6ECs+W3Y5O3TgGaPLzN4IxfMLy
	rLmkFBHfJBl5nNC3izfkFmeKcopxH7tglWJHFpciE+IlCetJhwGfoRjAoUgLg==
X-Google-Smtp-Source: AGHT+IGs6RVcLqHmfQoSzmfYVFDzjcfB1yzxVrQ1br3JPwQL8Jwfwgn1cE39EOkxrmixmEPusLWFPA==
X-Received: by 2002:a5d:47c3:0:b0:385:df17:2148 with SMTP id ffacd0b85a97d-38a7923b75dmr1712737f8f.20.1736242374009;
        Tue, 07 Jan 2025 01:32:54 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: qemu-devel@nongnu.org
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	=?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= <marcandre.lureau@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	xen-devel@lists.xenproject.org
Subject: [PATCH 1/2] xen/console: fix error handling in xen_console_device_create()
Date: Tue,  7 Jan 2025 10:31:39 +0100
Message-ID: <20250107093140.86180-2-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250107093140.86180-1-roger.pau@citrix.com>
References: <20250107093140.86180-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The usage of error_prepend() in some of the error contexts of
xen_console_device_create() is incorrect, as `errp` hasn't been initialized.
This leads to the following segmentation fault on error paths resulting from
xenstore reads:

Program terminated with signal SIGSEGV, Segmentation fault.
Address not mapped to object.
    fmt=0x15c4dfeade42 "failed to read console device type: ", ap=0x15cd0165ab50)
    at ../qemu-xen-dir-remote/util/error.c:142
142         g_string_append(newmsg, (*errp)->msg);
[...]
(gdb) bt
    (errp=0x15cd0165ae10, fmt=0x15c4dfeade42 "failed to read console device type: ", ap=0x15cd0165ab50) at ../qemu-xen-dir-remote/util/error.c:142
    (errp=0x15cd0165ae10, fmt=0x15c4dfeade42 "failed to read console device type: ")
    at ../qemu-xen-dir-remote/util/error.c:152
    (backend=0x43944de00660, opts=0x43944c929000, errp=0x15cd0165ae10)
    at ../qemu-xen-dir-remote/hw/char/xen_console.c:555

Replace usages of error_prepend() with error_setg() where appropriate.

Fixes: 9b7737469080 ('hw/xen: update Xen console to XenDevice model')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: Anthony PERARD <anthony@xenproject.org>
Cc: Paul Durrant <paul@xen.org>
Cc: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>
Cc: "Marc-André Lureau" <marcandre.lureau@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: xen-devel@lists.xenproject.org
---
 hw/char/xen_console.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
index ef0c2912efa1..af706c7ef440 100644
--- a/hw/char/xen_console.c
+++ b/hw/char/xen_console.c
@@ -551,7 +551,7 @@ static void xen_console_device_create(XenBackendInstance *backend,
     }
 
     if (xs_node_scanf(xsh, XBT_NULL, fe, "type", errp, "%ms", &type) != 1) {
-        error_prepend(errp, "failed to read console device type: ");
+        error_setg(errp, "failed to read console device type: ");
         goto fail;
     }
 
@@ -582,7 +582,7 @@ static void xen_console_device_create(XenBackendInstance *backend,
     } else if (number) {
         cd = serial_hd(number);
         if (!cd) {
-            error_prepend(errp, "console: No serial device #%ld found: ",
+            error_setg(errp, "console: No serial device #%ld found: ",
                           number);
             goto fail;
         }
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 07 09:33:05 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 09:33:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866222.1277533 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV5xR-0002Kl-Is; Tue, 07 Jan 2025 09:33:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866222.1277533; Tue, 07 Jan 2025 09:33:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV5xR-0002Kc-G8; Tue, 07 Jan 2025 09:33:05 +0000
Received: by outflank-mailman (input) for mailman id 866222;
 Tue, 07 Jan 2025 09:33:03 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=X79W=T7=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tV5xP-0002F7-Nf
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 09:33:03 +0000
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com
 [2a00:1450:4864:20::334])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6428c0e4-ccda-11ef-a0df-8be0dac302b0;
 Tue, 07 Jan 2025 10:33:02 +0100 (CET)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-43690d4605dso68566965e9.0
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 01:33:02 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c8a6abesm49900025f8f.90.2025.01.07.01.33.00
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 07 Jan 2025 01:33:01 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 6428c0e4-ccda-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736242382; x=1736847182; 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=NXMJwJkD6GoreE4rq36bTo/n6oNP+S5NtP/Em4G4kUk=;
        b=cHoTXeJTR+e0omcIG2xaEIIMXPDIOWUG/4U3DL5P9rnDdAr1Jrp8i2ahA7kYPT4ECs
         I9kLZWMfU4P5j20qFCY1q9zt5kvVRncp9jDHw6JdGQSAYGsfXgMH5HFqCn9eWQpvlRTA
         6DGZf60uHjQrZK6GHj9E3M6cA51DW5EXqTtys=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736242382; x=1736847182;
        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=NXMJwJkD6GoreE4rq36bTo/n6oNP+S5NtP/Em4G4kUk=;
        b=pSPLmwka+QeG07tS8tn4Bf2NSlmvSXmeQiF0czKno4+EdLf8qLbUmEDW3dfLrc3fFL
         Rw49yZqPyemPeMK4hMC9ZpozLPegytxI0wFS8JYhWeTfYzXKywWO7Gz5IzClOKsIu2wW
         xlbPAMHMbApNVBNq/38zrRtVZ3OMpwPVFPipMGprWccrv2EUY3QohOIvWcShQLs9BYW6
         Xl1d3MpVBVRuNhJ17cQtWHlnN4XOvpAo5Hyr35zVYRKWAbx1kgj9dlDY7yvrKX50CjMp
         +zzAXr7wMtYPF/98tE+u826b+IQBndupXAWJWJ7f7QACKlCZmQod2iSb38gf7is91Bav
         8FrA==
X-Forwarded-Encrypted: i=1; AJvYcCWZfs0Glt6iuE3YTsjuFkDZ6chufJPGQJffTYVKn/6QzcqD5sNIxoFhf9i2weoq8LLIearOrpNBiBY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwgICQSL+HkYfEGpZXSeVPwHrpyIFv9/PCtGG7LG/lCtLCHenIv
	gt/WRYMd3kFQUyONfnzy63ZDX0T5ImJhfZiCFKD0QvRe0okriQoTy/fScbvTIT8=
X-Gm-Gg: ASbGncsirMdk5OUAUm9DlIP7GwIF/YSV2TsMwwht++8vSIXmHuKnxPcQuqqcxlw1XPp
	uRFM74A9DkUWu7k7nol2KiHS/pWWeLZUYJL0aHSmrohlQQj4PgrJPw1XuXKSKxCk8y2gDlckN4g
	vW3ygmEjoG93KNFToOosQK8DsUjBPwu29q/y3+RJDSySwR8IZTEDJZAiQAh4NLeQA8fK2AOqoTi
	qs1h+5yJsccC1kMjiOaNw9cCn15DyN7jcYF1/h+amr82dGIfrkn9Rz6K/350g==
X-Google-Smtp-Source: AGHT+IEix0l+GrmL6GlNsHgpdBKlhdge3KcJsVrThXIBxIDP7VrUAOxyB//Zy8/3JjeQgqN+VJe5zw==
X-Received: by 2002:a05:6000:4012:b0:385:f7a3:fea6 with SMTP id ffacd0b85a97d-38a221fa6bamr42191038f8f.13.1736242382216;
        Tue, 07 Jan 2025 01:33:02 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: qemu-devel@nongnu.org
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	=?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= <marcandre.lureau@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	xen-devel@lists.xenproject.org
Subject: [PATCH 2/2] xen: do not use '%ms' scanf specifier
Date: Tue,  7 Jan 2025 10:31:40 +0100
Message-ID: <20250107093140.86180-3-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250107093140.86180-1-roger.pau@citrix.com>
References: <20250107093140.86180-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The 'm' parameter used to request auto-allocation of the destination variable
is not supported on FreeBSD, and as such leads to failures to parse.

What's more, the current usage of '%ms' with xs_node_scanf() is pointless, as
it just leads to a double allocation of the same string.  Instead use
qemu_xen_xs_read() to read the whole xenstore node.

Fixes: a783f8ad4ec9 ('xen: add a mechanism to automatically create XenDevice-s...')
Fixes: 9b7737469080 ('hw/xen: update Xen console to XenDevice model')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: Anthony PERARD <anthony@xenproject.org>
Cc: Paul Durrant <paul@xen.org>
Cc: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>
Cc: "Marc-André Lureau" <marcandre.lureau@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: xen-devel@lists.xenproject.org
---
 hw/char/xen_console.c | 11 +++++++++--
 hw/xen/xen-bus.c      |  7 +++++--
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
index af706c7ef440..18afd214c2f6 100644
--- a/hw/char/xen_console.c
+++ b/hw/char/xen_console.c
@@ -531,6 +531,7 @@ static void xen_console_device_create(XenBackendInstance *backend,
     const char *name = xen_backend_get_name(backend);
     unsigned long number;
     char *fe = NULL, *type = NULL, *output = NULL;
+    const char *node_path;
     char label[32];
     XenDevice *xendev = NULL;
     XenConsole *con;
@@ -550,7 +551,10 @@ static void xen_console_device_create(XenBackendInstance *backend,
         goto fail;
     }
 
-    if (xs_node_scanf(xsh, XBT_NULL, fe, "type", errp, "%ms", &type) != 1) {
+    node_path = g_strdup_printf("%s/type", fe);
+    type = qemu_xen_xs_read(xsh, XBT_NULL, node_path, NULL);
+    g_free(node_path);
+    if (!type) {
         error_setg(errp, "failed to read console device type: ");
         goto fail;
     }
@@ -568,7 +572,10 @@ static void xen_console_device_create(XenBackendInstance *backend,
 
     snprintf(label, sizeof(label), "xencons%ld", number);
 
-    if (xs_node_scanf(xsh, XBT_NULL, fe, "output", NULL, "%ms", &output) == 1) {
+    node_path = g_strdup_printf("%s/output", fe);
+    output = qemu_xen_xs_read(xsh, XBT_NULL, node_path, NULL);
+    g_free(node_path);
+    if (!output) {
         /*
          * FIXME: sure we want to support implicit
          * muxed monitors here?
diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c
index adfc4efad035..9be807649e77 100644
--- a/hw/xen/xen-bus.c
+++ b/hw/xen/xen-bus.c
@@ -142,6 +142,7 @@ again:
 
     opts = qdict_new();
     for (i = 0; i < n; i++) {
+        const char *node_path;
         char *val;
 
         /*
@@ -156,8 +157,10 @@ again:
             !strcmp(key[i], "hotplug-status"))
             continue;
 
-        if (xs_node_scanf(xenbus->xsh, tid, path, key[i], NULL, "%ms",
-                          &val) == 1) {
+        node_path = g_strdup_printf("%s/%s", path, key[i]);
+        val = qemu_xen_xs_read(xenbus->xsh, tid, node_path, NULL);
+        g_free(node_path);
+        if (val) {
             qdict_put_str(opts, key[i], val);
             free(val);
         }
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 07 10:06:57 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 10:06:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866242.1277542 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV6U0-0008V4-9h; Tue, 07 Jan 2025 10:06:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866242.1277542; Tue, 07 Jan 2025 10:06:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV6U0-0008Ux-6w; Tue, 07 Jan 2025 10:06:44 +0000
Received: by outflank-mailman (input) for mailman id 866242;
 Tue, 07 Jan 2025 10:06:43 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=1r68=T7=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tV6Tz-0008Un-7K
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 10:06:43 +0000
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com
 [2a00:1450:4864:20::333])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 14311491-ccdf-11ef-99a4-01e77a169b0f;
 Tue, 07 Jan 2025 11:06:36 +0100 (CET)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-436a03197b2so57094065e9.2
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 02:06:36 -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
 5b1f17b1804b1-4366112e780sm589836755e9.0.2025.01.07.02.06.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 02:06:34 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 14311491-ccdf-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736244395; x=1736849195; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=KLu4EnhRkzXZFOz3MUBfyv1LwXe4+XWqJZeoSPt2Aww=;
        b=OLX51DKQfNi/1su5013Jui45C+zydZKdIo5LJgQNoDhhh2EX+N4lLqh9jS0BJNzutC
         /GSvL9v3anwRwBI7vKE3Mg4ItRRwK6/0PvsjbPZIhEcBMDlzmPQkcFf5ZM4wv8D18Pxi
         Yho+y3qH47bp8dUpRDcLucwQPl96wZ9aJ1qyvmxHpCj7l2y0QHmWKWN3SvP4E4/sELyH
         AkVCryZJacSM2NwRMoUgl3IFeygNZ/L7cy55NTCS8So4B1P+CtA7xd+nU1EiKdUc33bC
         QzRsqDsVLqqDBk45ve8pygzseGCm1CUrWI0mYyCgzuL7mZwSzH4OC+acXYBE8rleX+Jb
         Bmig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736244395; x=1736849195;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=KLu4EnhRkzXZFOz3MUBfyv1LwXe4+XWqJZeoSPt2Aww=;
        b=ZEHv/embs/Qkov1mTpkS8Z3YonNj97PBAVF8huiq5RVryIwuPJ/N7mWFn4q4Zdy7+5
         Vik7KS56e8v6LercWQq++fdGE5KnhZXYOmrLMlKsiAg/w3aEpHqb/Gdq8yj3ihmPmWSC
         pllDKSOMRhhREjLLEdbXQLEtYhBx9x3wN7pxjfITbo3FB7cX46BdLV6NDhfrGbh2Kf4H
         z9Ed/0bzrN2pFoA82Y4CLNVHxs8NxEJ5Ctw37vwue0GcJGn2wYx1qzEjDuFYqJa27oES
         HYg7n5BpY9PO3IWI2Ajs5pTb4fprojCOnhWyPDo8e4lqb/oyexN57DKYwVjkoBPH59px
         HliA==
X-Forwarded-Encrypted: i=1; AJvYcCVFo8XcPcQqdVFKUXzKBbLc0HP0L8znmtvtuzZzq4pr5STyQsSiu+dbt/FhUKhWuQiTNnoYz5BDaDg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxlOncRPbCz+RppJng73LXiowenQ9ozdlJlb3ghR5kt/Zb7JRB0
	ebI532s967pd45w8q+QZn0O38TDwgzT4+z83gt7p2YPL2KKWjSpGzXdWCGeuaA==
X-Gm-Gg: ASbGnct0VHNWBKWDciRKoo/lO0iJgUKTDIULMPFdfn5Kg4bgp1gPOV+gXy2uW7gOsEi
	aDczbV3DBiMgwgtOmOndAmQEI80AZEZcIXHXFZ2kfAFGQuudGAXYmSou6NObItK29o3Y30M2wJy
	ihUZQqHUXaLpRp6vQ/LfPByBeHF/u52eIxyuhnGam8DRamTmrEyauRopunIjkVnwY9ZVVc8lgJ6
	2GVIforQRk05wbhT8Muken/3VEgcRdTwZPOXMs/xOgwyDJ3D0wCxRG67ij5lvCCj5USZAn69kqv
	MYqa65DG6XO4+gYh/+SGw56xW78PNqwMXqnoNez7uA==
X-Google-Smtp-Source: AGHT+IFwDF7VK6SjN3AsYjI21za3FE7kZBul4dVyBSzNlQJBdJ0EUnrvnPpGKNCNapiXeES9V2gRZw==
X-Received: by 2002:a05:600c:35cb:b0:436:1af4:5e07 with SMTP id 5b1f17b1804b1-43668548867mr408217565e9.1.1736244395481;
        Tue, 07 Jan 2025 02:06:35 -0800 (PST)
Message-ID: <d904c816-da83-418a-9bff-9988660af546@suse.com>
Date: Tue, 7 Jan 2025 11:06:33 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4] vpci: Add resizable bar support
To: Jiqian Chen <Jiqian.Chen@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>, Huang Rui <ray.huang@amd.com>,
 xen-devel@lists.xenproject.org
References: <20241219052143.3161332-1-Jiqian.Chen@amd.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20241219052143.3161332-1-Jiqian.Chen@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 19.12.2024 06:21, Jiqian Chen wrote:
> --- /dev/null
> +++ b/xen/drivers/vpci/rebar.c
> @@ -0,0 +1,131 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (C) 2024 Advanced Micro Devices, Inc. All Rights Reserved.
> + *
> + * Author: Jiqian Chen <Jiqian.Chen@amd.com>
> + */
> +
> +#include <xen/sched.h>
> +#include <xen/vpci.h>
> +
> +static void cf_check rebar_ctrl_write(const struct pci_dev *pdev,
> +                                      unsigned int reg,
> +                                      uint32_t val,
> +                                      void *data)
> +{
> +    struct vpci_bar *bar = data;
> +    uint64_t size = PCI_REBAR_CTRL_SIZE(val);
> +
> +    if ( bar->enabled )
> +    {
> +        /*
> +         * Refuse to resize a BAR while memory decoding is enabled, as
> +         * otherwise the size of the mapped region in the p2m would become
> +         * stale with the newly set BAR size, and the position of the BAR
> +         * would be reset to undefined.  Note the PCIe specification also
> +         * forbids resizing a BAR with memory decoding enabled.
> +         */
> +        if ( size != bar->size )
> +            gprintk(XENLOG_ERR,
> +                    "%pp: refuse to resize BAR with memory decoding enabled\n",
> +                    &pdev->sbdf);
> +        return;
> +    }
> +
> +    if ( !((size >> PCI_REBAR_SIZE_BIAS) & bar->resizable_sizes) )
> +        gprintk(XENLOG_WARNING,
> +                "%pp: new size %#lx is not supported by hardware\n",
> +                &pdev->sbdf, size);
> +
> +    bar->size = size;

Shouldn't at least this be in an "else" to the if() above?

> +    bar->addr = 0;

For maximum compatibility with the behavior on bare metal, would we
perhaps better ...

> +    bar->guest_addr = 0;
> +    pci_conf_write32(pdev->sbdf, reg, val);

... re-read the BAR from hardware after this write?

Similar consideration may apply to ->guest_addr: Driver writers knowing
how their hardware behaves may expect that merely some of the bits of
the address get cleared (if the size increases).

> +static int cf_check init_rebar(struct pci_dev *pdev)
> +{
> +    uint32_t ctrl;
> +    unsigned int nbars;
> +    unsigned int rebar_offset = pci_find_ext_capability(pdev->sbdf,
> +                                                        PCI_EXT_CAP_ID_REBAR);
> +
> +    if ( !rebar_offset )
> +        return 0;
> +
> +    if ( !is_hardware_domain(pdev->domain) )
> +    {
> +        printk(XENLOG_ERR "%pp: resizable BARs unsupported for unpriv %pd\n",
> +               &pdev->sbdf, pdev->domain);
> +        return -EOPNOTSUPP;
> +    }
> +
> +    ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL(0));
> +    nbars = MASK_EXTR(ctrl, PCI_REBAR_CTRL_NBAR_MASK);
> +
> +    for ( unsigned int i = 0; i < nbars; i++ )
> +    {
> +        int rc;
> +        struct vpci_bar *bar;
> +        unsigned int index;
> +
> +        ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL(i));
> +        index = ctrl & PCI_REBAR_CTRL_BAR_IDX;;

Nit: No double semicolons please.

> +        if ( index >= PCI_HEADER_NORMAL_NR_BARS )
> +        {
> +            /*
> +             * TODO: for failed pathes, need to hide ReBar capability
> +             * from hardware domain instead of returning an error.
> +             */
> +            printk(XENLOG_ERR "%pd %pp: too big BAR number %u in REBAR_CTRL\n",
> +                   pdev->domain, &pdev->sbdf, index);
> +            return -EINVAL;

With the TODO unaddressed, is it actually appropriate to return an error
here? Shouldn't we continue in a best effort manner? (Question also to
Roger as the maintainer.)

> +        }
> +
> +        bar = &pdev->vpci->header.bars[index];
> +        if ( bar->type != VPCI_BAR_MEM64_LO && bar->type != VPCI_BAR_MEM32 )
> +        {
> +            printk(XENLOG_ERR "%pd %pp: BAR%u is not in memory space\n",
> +                   pdev->domain, &pdev->sbdf, index);
> +            return -EINVAL;

Same question here then.

> +        }
> +
> +        rc = vpci_add_register(pdev->vpci, vpci_hw_read32, vpci_hw_write32,
> +                               rebar_offset + PCI_REBAR_CAP(i), 4, NULL);
> +        if ( rc )
> +        {
> +            printk(XENLOG_ERR "%pd %pp: fail to add reg of REBAR_CAP rc=%d\n",
> +                   pdev->domain, &pdev->sbdf, rc);
> +            return rc;
> +        }
> +
> +        rc = vpci_add_register(pdev->vpci, vpci_hw_read32, rebar_ctrl_write,
> +                               rebar_offset + PCI_REBAR_CTRL(i), 4, bar);
> +        if ( rc )
> +        {
> +            printk(XENLOG_ERR "%pd %pp: fail to add reg of REBAR_CTRL rc=%d\n",
> +                   pdev->domain, &pdev->sbdf, rc);
> +            return rc;
> +        }
> +
> +        bar->resizable_sizes |=
> +            (pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CAP(i)) >>
> +             PCI_REBAR_CAP_SHIFT);

Imo this would better use = in place of |= and (see also below) would also
better use MASK_EXTR() just like ...

> +        bar->resizable_sizes |=
> +            ((uint64_t)MASK_EXTR(ctrl, PCI_REBAR_CTRL_SIZES) <<
> +             (32 - PCI_REBAR_CAP_SHIFT));

... this one does.

Further I think you want to truncate the value for 32-bit BARs, such that
rebar_ctrl_write() would properly reject attempts to set sizes of 4G and
above for them.

> --- a/xen/drivers/vpci/vpci.c
> +++ b/xen/drivers/vpci/vpci.c
> @@ -232,6 +232,12 @@ void cf_check vpci_hw_write16(
>      pci_conf_write16(pdev->sbdf, reg, val);
>  }
>  
> +void cf_check vpci_hw_write32(
> +    const struct pci_dev *pdev, unsigned int reg, uint32_t val, void *data)
> +{
> +    pci_conf_write32(pdev->sbdf, reg, val);
> +}

This function is being added just to handle writing of a r/o register.
Can't you better re-use vpci_ignored_write()?

> --- a/xen/include/xen/pci_regs.h
> +++ b/xen/include/xen/pci_regs.h
> @@ -459,6 +459,7 @@
>  #define PCI_EXT_CAP_ID_ARI	14
>  #define PCI_EXT_CAP_ID_ATS	15
>  #define PCI_EXT_CAP_ID_SRIOV	16
> +#define PCI_EXT_CAP_ID_REBAR	21	/* Resizable BAR */
>  
>  /* Advanced Error Reporting */
>  #define PCI_ERR_UNCOR_STATUS	4	/* Uncorrectable Error Status */
> @@ -541,6 +542,19 @@
>  #define  PCI_VNDR_HEADER_REV(x)	(((x) >> 16) & 0xf)
>  #define  PCI_VNDR_HEADER_LEN(x)	(((x) >> 20) & 0xfff)
>  
> +/* Resizable BARs */
> +#define PCI_REBAR_SIZE_BIAS	20

I think it would be best if all register definitions came first, and
auxiliary ones followed afterwards (maybe even separated by a brief
comment for clarity).

> +#define PCI_REBAR_CAP(n)    	(4 + 8 * (n))	/* capability register */
> +#define  PCI_REBAR_CAP_SHIFT		4		/* shift for supported BAR sizes */
> +#define PCI_REBAR_CTRL(n)   	(8 + 8 * (n))	/* control register */

Something's odd with the padding here. Please be consistent with the use
of whitespace (ought to be only hard tabs here afaict).

> +#define  PCI_REBAR_CTRL_BAR_IDX	0x00000007	/* BAR index */
> +#define  PCI_REBAR_CTRL_NBAR_MASK	0x000000E0	/* # of resizable BARs */
> +#define  PCI_REBAR_CTRL_BAR_SIZE	0x00001F00	/* BAR size */

This field is 6 bits wide in the spec I'm looking at. Or else BAR sizes
2^^52 and up can't be encoded.

> +#define  PCI_REBAR_CTRL_SIZE(v) \
> +            (1UL << (MASK_EXTR(v, PCI_REBAR_CTRL_BAR_SIZE) \
> +                     + PCI_REBAR_SIZE_BIAS))
> +#define  PCI_REBAR_CTRL_SIZES		0xFFFF0000U	/* supported BAR sizes */

PCI_REBAR_CAP_SHIFT and PCI_REBAR_CTRL_SIZES don't fit together very well.
Imo both want representing as masks.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 10:17:26 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 10:17:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866250.1277562 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV6eK-0002Hf-DS; Tue, 07 Jan 2025 10:17:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866250.1277562; Tue, 07 Jan 2025 10:17:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV6eK-0002HY-As; Tue, 07 Jan 2025 10:17:24 +0000
Received: by outflank-mailman (input) for mailman id 866250;
 Tue, 07 Jan 2025 10:17:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Qdqe=T7=suse.com=jgross@srs-se1.protection.inumbo.net>)
 id 1tV6eJ-0002Gw-3e
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 10:17:23 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de
 [2a07:de40:b251:101:10:150:64:1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 944e748f-cce0-11ef-99a4-01e77a169b0f;
 Tue, 07 Jan 2025 11:17:21 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id 4274421101;
 Tue,  7 Jan 2025 10:17:20 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id EEE4613763;
 Tue,  7 Jan 2025 10:17:19 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id ByjcOC//fGf1YQAAD6G6ig
 (envelope-from <jgross@suse.com>); Tue, 07 Jan 2025 10:17:19 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 944e748f-cce0-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1736245040; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=HhXkIABEk1e1lqyLU/BUaX78Jkdwo9F7qhL5iVLjc+A=;
	b=buR/RyB+4IOMLZ7dP+bBBplJxeXAOvtJPpYw/7IlGXJ7MYJOyimydNRs9XPlkMQhqFOdAX
	BkKkdONtYlvaSbFoywkz7o5C7iLrjA42mLTI8TsurjKjcLOmeukjgP6isuxToYdY7Vz64R
	TSQ/pOl2OdwXra05kj/k+tXeo4AzM7w=
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b="buR/RyB+"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1736245040; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=HhXkIABEk1e1lqyLU/BUaX78Jkdwo9F7qhL5iVLjc+A=;
	b=buR/RyB+4IOMLZ7dP+bBBplJxeXAOvtJPpYw/7IlGXJ7MYJOyimydNRs9XPlkMQhqFOdAX
	BkKkdONtYlvaSbFoywkz7o5C7iLrjA42mLTI8TsurjKjcLOmeukjgP6isuxToYdY7Vz64R
	TSQ/pOl2OdwXra05kj/k+tXeo4AzM7w=
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross <jgross@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v6 1/7] xen/events: fix race with set_global_virq_handler()
Date: Tue,  7 Jan 2025 11:17:05 +0100
Message-ID: <20250107101711.5980-2-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250107101711.5980-1-jgross@suse.com>
References: <20250107101711.5980-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4274421101
X-Spam-Score: -3.01
X-Rspamd-Action: no action
X-Spamd-Result: default: False [-3.01 / 50.00];
	BAYES_HAM(-3.00)[99.99%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:dkim,suse.com:mid,suse.com:email,imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ASN(0.00)[asn:25478, ipnet:::/0, country:RU];
	MIME_TRACE(0.00)[0:+];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_SEVEN(0.00)[9];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	RCVD_COUNT_TWO(0.00)[2];
	RCVD_TLS_ALL(0.00)[];
	TO_DN_SOME(0.00)[];
	DKIM_TRACE(0.00)[suse.com:+]
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spam-Flag: NO
X-Spam-Level: 

There is a possible race scenario between set_global_virq_handler()
and clear_global_virq_handlers() targeting the same domain, which
might result in that domain ending as a zombie domain.

In case set_global_virq_handler() is being called for a domain which
is just dying, it might happen that clear_global_virq_handlers() is
running first, resulting in set_global_virq_handler() taking a new
reference for that domain and entering in the global_virq_handlers[]
array afterwards. The reference will never be dropped, thus the domain
will never be freed completely.

This can be fixed by checking the is_dying state of the domain inside
the region guarded by global_virq_handlers_lock. In case the domain is
dying, handle it as if the domain wouldn't exist, which will be the
case in near future anyway.

Fixes: 87521589aa6a ("xen: allow global VIRQ handlers to be delegated to other domains")
Signed-off-by: Juergen Gross <jgross@suse.com>
---
V6:
- new patch
---
 xen/common/event_channel.c | 16 +++++++++++++---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 8db2ca4ba2..f2b64c48fb 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -979,6 +979,7 @@ void send_global_virq(uint32_t virq)
 int set_global_virq_handler(struct domain *d, uint32_t virq)
 {
     struct domain *old;
+    int rc = 0;
 
     if (virq >= NR_VIRQS)
         return -EINVAL;
@@ -992,14 +993,23 @@ int set_global_virq_handler(struct domain *d, uint32_t virq)
         return -EINVAL;
 
     spin_lock(&global_virq_handlers_lock);
-    old = global_virq_handlers[virq];
-    global_virq_handlers[virq] = d;
+
+    if ( d->is_dying != DOMDYING_alive )
+    {
+        old = d;
+        rc = -EINVAL;
+    }
+    else
+    {
+        old = global_virq_handlers[virq];
+        global_virq_handlers[virq] = d;
+    }
     spin_unlock(&global_virq_handlers_lock);
 
     if (old != NULL)
         put_domain(old);
 
-    return 0;
+    return rc;
 }
 
 static void clear_global_virq_handlers(struct domain *d)
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 07 10:17:26 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 10:17:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866249.1277553 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV6eH-000236-6w; Tue, 07 Jan 2025 10:17:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866249.1277553; Tue, 07 Jan 2025 10:17:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV6eH-00022z-4K; Tue, 07 Jan 2025 10:17:21 +0000
Received: by outflank-mailman (input) for mailman id 866249;
 Tue, 07 Jan 2025 10:17:19 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Qdqe=T7=suse.com=jgross@srs-se1.protection.inumbo.net>)
 id 1tV6eF-00022t-J2
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 10:17:19 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 91322903-cce0-11ef-a0df-8be0dac302b0;
 Tue, 07 Jan 2025 11:17:16 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id 94E1C1F451;
 Tue,  7 Jan 2025 10:17:14 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 276F113763;
 Tue,  7 Jan 2025 10:17:14 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id eC7NByr/fGfoYQAAD6G6ig
 (envelope-from <jgross@suse.com>); Tue, 07 Jan 2025 10:17:14 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 91322903-cce0-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1736245034; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:  content-transfer-encoding:content-transfer-encoding;
	bh=2FJuRVon5w92vNysSGZoa7X4qvDUk2iZb6VAVacmPN4=;
	b=qHhYXJYKauMEsJyVbt5Qc8s9+GhJLsIR37E37KupjDVqw+j3QaeKl3aNzUg5KD/xksX9Lk
	GmSr1TzMAkWBLTn7++UEhYP9uOWW6+v/dvCJEGjvVVuY96F2MvsWJw1tUxP5m4vW6IFeMq
	TQ4pr0iK+BasQGO3xuSnuYctEVM5RAY=
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=qHhYXJYK
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1736245034; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:  content-transfer-encoding:content-transfer-encoding;
	bh=2FJuRVon5w92vNysSGZoa7X4qvDUk2iZb6VAVacmPN4=;
	b=qHhYXJYKauMEsJyVbt5Qc8s9+GhJLsIR37E37KupjDVqw+j3QaeKl3aNzUg5KD/xksX9Lk
	GmSr1TzMAkWBLTn7++UEhYP9uOWW6+v/dvCJEGjvVVuY96F2MvsWJw1tUxP5m4vW6IFeMq
	TQ4pr0iK+BasQGO3xuSnuYctEVM5RAY=
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross <jgross@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>
Subject: [PATCH v6 0/7] remove libxenctrl usage from xenstored
Date: Tue,  7 Jan 2025 11:17:04 +0100
Message-ID: <20250107101711.5980-1-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 94E1C1F451
X-Spam-Level: 
X-Spamd-Result: default: False [-3.01 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns,suse.com:dkim,suse.com:mid];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ASN(0.00)[asn:25478, ipnet:::/0, country:RU];
	MIME_TRACE(0.00)[0:+];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_SEVEN(0.00)[11];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	RCVD_COUNT_TWO(0.00)[2];
	RCVD_TLS_ALL(0.00)[];
	TO_DN_SOME(0.00)[];
	DKIM_TRACE(0.00)[suse.com:+]
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Rspamd-Action: no action
X-Spam-Score: -3.01
X-Spam-Flag: NO

Xenstored is using libxenctrl for only one purpose: to get information
about state of domains.

This patch series is removing that dependency by introducing a new
stable interface which can be used by xenstored instead.

There was a RFC series sent out 3 years ago, which I have taken as a
base and by addressing all comments from back then.

The main differences since that RFC series are:

- Instead of introducing an new main hypercall for a stable management
  interface I have just added a new domctl sub-op, as requested in 2021.

- I have added a new library libxenmanage for easy use of the new
  stable hypervisor interface. Main motivation for adding the library
  was the recent attempt to decouple oxenstored from the Xen git tree.
  By using the new library, oxenstored could benefit in the same way as
  xenstored from the new interface: it would be possible to rely on
  stable libraries only.

- Mini-OS has gained some more config options recently, so it was rather
  easy to make xenstore[pvh]-stubdom independent from libxenctrl, too.

Please note that the last patch can be committed only after the related
Mini-OS patch "config: add support for libxenmanage" has gone in AND
the Mini-OS commit-id has been updated in Config.mk accordingly! The
Mini-OS patch has been Acked already, so it can go in as soon as patch
4 of this series (the one introducing libxenmanage) has been committed.

Changes in V2:
- new patch 1
- former patch 5 mover earlier, now patch 2 (can go in without the rest
  of the series)
- addressed comments

Changes in V3:
- addressed comments

Changes in V4:
- patches 1 and 3 of V3 dropped, as already committed
- addressed comments

Changes in V5:
- addressed comments

Changes in V6:
- patch 1 of V5 has been committed
- new patches 1-3 for fixing a race and avoiding new races with the
  added functionality (result of a comment by Jan Beulich)
- rework of locking in patch 4 (Jan Beulich)

Juergen Gross (7):
  xen/events: fix race with set_global_virq_handler()
  xen/events: don't allow binding a global virq from any domain
  xen/events: allow setting of global virq handler only for unbound
    virqs
  xen: add bitmap to indicate per-domain state changes
  xen: add new domctl get_changed_domain
  tools/libs: add a new libxenmanage library
  tools/xenstored: use new stable interface instead of libxenctrl

 stubdom/Makefile                       |   8 +-
 stubdom/mini-os.mk                     |   1 +
 tools/flask/policy/modules/dom0.te     |   2 +-
 tools/flask/policy/modules/xen.if      |   4 +-
 tools/flask/policy/modules/xenstore.te |   1 +
 tools/include/xenmanage.h              |  92 ++++++++++++++
 tools/libs/Makefile                    |   1 +
 tools/libs/manage/Makefile             |  10 ++
 tools/libs/manage/Makefile.common      |   3 +
 tools/libs/manage/core.c               | 168 +++++++++++++++++++++++++
 tools/libs/manage/libxenmanage.map     |   8 ++
 tools/libs/uselibs.mk                  |   2 +
 tools/xenstored/Makefile               |   2 +-
 tools/xenstored/Makefile.common        |   2 +-
 tools/xenstored/core.h                 |   1 -
 tools/xenstored/domain.c               |  52 +++-----
 tools/xenstored/lu.c                   |   1 +
 tools/xenstored/lu_daemon.c            |   1 +
 xen/common/domain.c                    | 121 ++++++++++++++++++
 xen/common/domctl.c                    |  18 ++-
 xen/common/event_channel.c             |  94 ++++++++++++--
 xen/include/public/domctl.h            |  26 ++++
 xen/include/xen/event.h                |  11 ++
 xen/include/xen/sched.h                |   5 +
 xen/include/xsm/dummy.h                |   8 ++
 xen/include/xsm/xsm.h                  |   6 +
 xen/xsm/dummy.c                        |   1 +
 xen/xsm/flask/hooks.c                  |   7 ++
 xen/xsm/flask/policy/access_vectors    |   2 +
 29 files changed, 604 insertions(+), 54 deletions(-)
 create mode 100644 tools/include/xenmanage.h
 create mode 100644 tools/libs/manage/Makefile
 create mode 100644 tools/libs/manage/Makefile.common
 create mode 100644 tools/libs/manage/core.c
 create mode 100644 tools/libs/manage/libxenmanage.map

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 07 10:17:29 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 10:17:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866251.1277573 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV6eP-0002ZF-MZ; Tue, 07 Jan 2025 10:17:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866251.1277573; Tue, 07 Jan 2025 10:17:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV6eP-0002Z8-Hu; Tue, 07 Jan 2025 10:17:29 +0000
Received: by outflank-mailman (input) for mailman id 866251;
 Tue, 07 Jan 2025 10:17:27 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Qdqe=T7=suse.com=jgross@srs-se1.protection.inumbo.net>)
 id 1tV6eN-0002Gw-Nm
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 10:17:27 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de
 [2a07:de40:b251:101:10:150:64:1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 97ae0622-cce0-11ef-99a4-01e77a169b0f;
 Tue, 07 Jan 2025 11:17:26 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id F334821106;
 Tue,  7 Jan 2025 10:17:25 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id A9CA813763;
 Tue,  7 Jan 2025 10:17:25 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id E6j0JzX/fGf6YQAAD6G6ig
 (envelope-from <jgross@suse.com>); Tue, 07 Jan 2025 10:17:25 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 97ae0622-cce0-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1736245046; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=jOR5OALhQkoDgIcv8wbt7KnZ2ldq5n3Rm8CH4ChSQUQ=;
	b=LSS5chq/5+2ufr8qs8V7z1ght085ugxdQhjolXHDjls6QYzLlrXnzmFbHuHeYVDDwcra5A
	yhWHl/jxSUU40yL/ZE2ymjXqgatcea4sBFO0v542OTNDbcFyV/2/RcrVyWMI4yDiRibD7s
	Gd/9TJDARi1qAN6rSQLajRIvlFL/3r8=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1736245046; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=jOR5OALhQkoDgIcv8wbt7KnZ2ldq5n3Rm8CH4ChSQUQ=;
	b=LSS5chq/5+2ufr8qs8V7z1ght085ugxdQhjolXHDjls6QYzLlrXnzmFbHuHeYVDDwcra5A
	yhWHl/jxSUU40yL/ZE2ymjXqgatcea4sBFO0v542OTNDbcFyV/2/RcrVyWMI4yDiRibD7s
	Gd/9TJDARi1qAN6rSQLajRIvlFL/3r8=
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross <jgross@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v6 2/7] xen/events: don't allow binding a global virq from any domain
Date: Tue,  7 Jan 2025 11:17:06 +0100
Message-ID: <20250107101711.5980-3-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250107101711.5980-1-jgross@suse.com>
References: <20250107101711.5980-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.80
X-Spamd-Result: default: False [-2.80 / 50.00];
	BAYES_HAM(-3.00)[99.99%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-0.998];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_SEVEN(0.00)[9];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MIME_TRACE(0.00)[0:+];
	ARC_NA(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,suse.com:email,imap1.dmz-prg2.suse.org:helo];
	RCVD_TLS_ALL(0.00)[]
X-Spam-Flag: NO
X-Spam-Level: 

Today Xen will happily allow binding a global virq by a domain which
isn't configured to receive it. This won't result in any bad actions,
but the bind will appear to have succeeded with no event ever being
received by that event channel.

Instead of allowing the bind, error out if the domain isn't set to
handle that virq.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
V6:
- new patch
---
 xen/common/event_channel.c | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index f2b64c48fb..62060dc66b 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -120,6 +120,13 @@ static uint8_t get_xen_consumer(xen_event_channel_notification_t fn)
 /* Get the notification function for a given Xen-bound event channel. */
 #define xen_notification_fn(e) (xen_consumers[(e)->xen_consumer-1])
 
+static struct domain *global_virq_handlers[NR_VIRQS] __read_mostly;
+
+static struct domain *get_global_virq_handler(unsigned int virq)
+{
+    return global_virq_handlers[virq] ?: hardware_domain;
+}
+
 static bool virq_is_global(unsigned int virq)
 {
     switch ( virq )
@@ -479,8 +486,13 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind, evtchn_port_t port)
     */
     virq = array_index_nospec(virq, ARRAY_SIZE(v->virq_to_evtchn));
 
-    if ( virq_is_global(virq) && (vcpu != 0) )
-        return -EINVAL;
+    if ( virq_is_global(virq) )
+    {
+        if ( get_global_virq_handler(virq) != d )
+            return -EBUSY;
+        if ( vcpu != 0 )
+            return -EINVAL;
+    }
 
     if ( (v = domain_vcpu(d, vcpu)) == NULL )
         return -ENOENT;
@@ -965,15 +977,13 @@ void send_guest_pirq(struct domain *d, const struct pirq *pirq)
     }
 }
 
-static struct domain *global_virq_handlers[NR_VIRQS] __read_mostly;
-
 static DEFINE_SPINLOCK(global_virq_handlers_lock);
 
 void send_global_virq(uint32_t virq)
 {
     ASSERT(virq_is_global(virq));
 
-    send_guest_global_virq(global_virq_handlers[virq] ?: hardware_domain, virq);
+    send_guest_global_virq(get_global_virq_handler(virq), virq);
 }
 
 int set_global_virq_handler(struct domain *d, uint32_t virq)
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 07 10:17:33 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 10:17:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866253.1277583 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV6eT-0002ri-2b; Tue, 07 Jan 2025 10:17:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866253.1277583; Tue, 07 Jan 2025 10:17:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV6eT-0002rV-04; Tue, 07 Jan 2025 10:17:33 +0000
Received: by outflank-mailman (input) for mailman id 866253;
 Tue, 07 Jan 2025 10:17:32 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Qdqe=T7=suse.com=jgross@srs-se1.protection.inumbo.net>)
 id 1tV6eS-00022t-Hu
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 10:17:32 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9b167782-cce0-11ef-a0df-8be0dac302b0;
 Tue, 07 Jan 2025 11:17:32 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id ACDFD1F385;
 Tue,  7 Jan 2025 10:17:31 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 62BB713763;
 Tue,  7 Jan 2025 10:17:31 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id FZekFjv/fGcAYgAAD6G6ig
 (envelope-from <jgross@suse.com>); Tue, 07 Jan 2025 10:17:31 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9b167782-cce0-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1736245051; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=hNgtNgsIKg1oLK4j/cMgMwg+c8JSaY2oYqCfVRclRKk=;
	b=nprIg0sIS/7P22cri3uy8fJH2nL4D6pci8Jh1evSCvb2QQ5CbtEUpf8eHovJrRIi4e5v/U
	F7en4yqATml0VrC4QFs8I6U0ft2alAKn8Dmp6bMjPiw/tzopKrFZApc2FVeT3H9Y1JXFHY
	6NeS2ccayl+gbaN2zgKAj7vAKs8AUt8=
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1736245051; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=hNgtNgsIKg1oLK4j/cMgMwg+c8JSaY2oYqCfVRclRKk=;
	b=nprIg0sIS/7P22cri3uy8fJH2nL4D6pci8Jh1evSCvb2QQ5CbtEUpf8eHovJrRIi4e5v/U
	F7en4yqATml0VrC4QFs8I6U0ft2alAKn8Dmp6bMjPiw/tzopKrFZApc2FVeT3H9Y1JXFHY
	6NeS2ccayl+gbaN2zgKAj7vAKs8AUt8=
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross <jgross@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v6 3/7] xen/events: allow setting of global virq handler only for unbound virqs
Date: Tue,  7 Jan 2025 11:17:07 +0100
Message-ID: <20250107101711.5980-4-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250107101711.5980-1-jgross@suse.com>
References: <20250107101711.5980-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.80
X-Spamd-Result: default: False [-2.80 / 50.00];
	BAYES_HAM(-3.00)[99.99%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-0.999];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_SEVEN(0.00)[9];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MIME_TRACE(0.00)[0:+];
	ARC_NA(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,suse.com:email,imap1.dmz-prg2.suse.org:helo];
	RCVD_TLS_ALL(0.00)[]
X-Spam-Flag: NO
X-Spam-Level: 

XEN_DOMCTL_set_virq_handler will happily steal a global virq from the
current domain having bound it and assign it to another domain. The
former domain will just never receive any further events for that
virq without knowing what happened.

Change the behavior to allow XEN_DOMCTL_set_virq_handler only if the
virq in question is not bound by the current domain allowed to use it.

Currently the only user of XEN_DOMCTL_set_virq_handler in the Xen code
base is init-xenstore-domain, so changing the behavior like above will
not cause any problems.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
V6:
- new patch
---
 xen/common/event_channel.c | 20 ++++++++++++++++++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 62060dc66b..341221d420 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -988,7 +988,8 @@ void send_global_virq(uint32_t virq)
 
 int set_global_virq_handler(struct domain *d, uint32_t virq)
 {
-    struct domain *old;
+    struct domain *old, *hdl;
+    const struct vcpu *v;
     int rc = 0;
 
     if (virq >= NR_VIRQS)
@@ -1012,7 +1013,22 @@ int set_global_virq_handler(struct domain *d, uint32_t virq)
     else
     {
         old = global_virq_handlers[virq];
-        global_virq_handlers[virq] = d;
+        hdl = get_global_virq_handler(virq);
+        if ( hdl != d )
+        {
+            read_lock(&hdl->event_lock);
+
+            v = hdl->vcpu[0];
+            if ( v && read_atomic(&v->virq_to_evtchn[virq]) )
+            {
+                rc = -EBUSY;
+                old = d;
+            }
+            else
+                global_virq_handlers[virq] = d;
+
+            read_unlock(&hdl->event_lock);
+        }
     }
     spin_unlock(&global_virq_handlers_lock);
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 07 10:17:40 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 10:17:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866258.1277592 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV6ea-0003Lh-BN; Tue, 07 Jan 2025 10:17:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866258.1277592; Tue, 07 Jan 2025 10:17:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV6ea-0003La-6t; Tue, 07 Jan 2025 10:17:40 +0000
Received: by outflank-mailman (input) for mailman id 866258;
 Tue, 07 Jan 2025 10:17: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 <SRS0=Qdqe=T7=suse.com=jgross@srs-se1.protection.inumbo.net>)
 id 1tV6eZ-00022t-Ax
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 10:17:39 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de
 [2a07:de40:b251:101:10:150:64:2])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9e80a95a-cce0-11ef-a0df-8be0dac302b0;
 Tue, 07 Jan 2025 11:17:38 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id 67D951F385;
 Tue,  7 Jan 2025 10:17:37 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 1BC0913763;
 Tue,  7 Jan 2025 10:17:37 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id H0IlBUH/fGcSYgAAD6G6ig
 (envelope-from <jgross@suse.com>); Tue, 07 Jan 2025 10:17:37 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9e80a95a-cce0-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1736245057; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=QCM/oXACLeNKjAQk/VnqKfiNWxzAplNk92Cykfe9M2s=;
	b=rlI0eACw9zEiyP9TDmRNCqE+efQrUpPMIOa5dhTyggBcbPpkcPC4im7WMa4xoFTdIymHSR
	6KX4kpF/xjTpzcrnH12VBWQliTuohF/hFfiJPjSjdQ9H5iCa/J4R6R7JTa9OVnWg+Fz8lM
	nONjtV/VVDNKx6YGCBaEFVXIcPCFRqQ=
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1736245057; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=QCM/oXACLeNKjAQk/VnqKfiNWxzAplNk92Cykfe9M2s=;
	b=rlI0eACw9zEiyP9TDmRNCqE+efQrUpPMIOa5dhTyggBcbPpkcPC4im7WMa4xoFTdIymHSR
	6KX4kpF/xjTpzcrnH12VBWQliTuohF/hFfiJPjSjdQ9H5iCa/J4R6R7JTa9OVnWg+Fz8lM
	nONjtV/VVDNKx6YGCBaEFVXIcPCFRqQ=
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross <jgross@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v6 4/7] xen: add bitmap to indicate per-domain state changes
Date: Tue,  7 Jan 2025 11:17:08 +0100
Message-ID: <20250107101711.5980-5-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250107101711.5980-1-jgross@suse.com>
References: <20250107101711.5980-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Level: 
X-Spamd-Result: default: False [-2.80 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-0.998];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_SEVEN(0.00)[9];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MIME_TRACE(0.00)[0:+];
	ARC_NA(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:email,suse.com:mid,imap1.dmz-prg2.suse.org:helo];
	RCVD_TLS_ALL(0.00)[]
X-Spam-Score: -2.80
X-Spam-Flag: NO

Add a bitmap with one bit per possible domid indicating the respective
domain has changed its state (created, deleted, dying, crashed,
shutdown).

Registering the VIRQ_DOM_EXC event will result in setting the bits for
all existing domains and resetting all other bits.

As the usage of this bitmap is tightly coupled with the VIRQ_DOM_EXC
event, it is meant to be used only by a single consumer in the system,
just like the VIRQ_DOM_EXC event.

Resetting a bit will be done in a future patch.

This information is needed for Xenstore to keep track of all domains.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
V2:
- use DOMID_FIRST_RESERVED instead of DOMID_MASK + 1 (Jan Beulich)
- use const (Jan Beulich)
- move call of domain_reset_states() into evtchn_bind_virq() (Jan Beulich)
- dynamically allocate dom_state_changed bitmap (Jan Beulich)
V3:
- use xvzalloc_array() (Jan Beulich)
- don't rename existing label (Jan Beulich)
V4:
- add __read_mostly (Jan Beulich)
- use __set_bit() (Jan Beulich)
- fix error handling in evtchn_bind_virq() (Jan Beulich)
V5:
- domain_init_states() may be called only if evtchn_bind_virq() has been
  called validly (Jan Beulich)
V6:
- guard dom_state_changed bitmap with d->event_lock (Jan Beulich)
---
 xen/common/domain.c        | 51 ++++++++++++++++++++++++++++++++++++++
 xen/common/event_channel.c | 31 +++++++++++++++++++++++
 xen/include/xen/event.h    |  4 +++
 xen/include/xen/sched.h    |  3 +++
 4 files changed, 89 insertions(+)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 0c4cc77111..78e2732e94 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -35,6 +35,7 @@
 #include <xen/irq.h>
 #include <xen/argo.h>
 #include <xen/llc-coloring.h>
+#include <xen/xvmalloc.h>
 #include <asm/p2m.h>
 #include <asm/processor.h>
 #include <public/sched.h>
@@ -139,6 +140,51 @@ bool __read_mostly vmtrace_available;
 
 bool __read_mostly vpmu_is_available;
 
+static unsigned long *__read_mostly dom_state_changed;
+
+int domain_init_states(void)
+{
+    const struct domain *d;
+
+    ASSERT(!dom_state_changed);
+    ASSERT(rw_is_write_locked(&current->domain->event_lock));
+
+    dom_state_changed = xvzalloc_array(unsigned long,
+                                       BITS_TO_LONGS(DOMID_FIRST_RESERVED));
+    if ( !dom_state_changed )
+        return -ENOMEM;
+
+    rcu_read_lock(&domlist_read_lock);
+
+    for_each_domain ( d )
+        set_bit(d->domain_id, dom_state_changed);
+
+    rcu_read_unlock(&domlist_read_lock);
+
+    return 0;
+}
+
+void domain_deinit_states(const struct domain *d)
+{
+    ASSERT(rw_is_write_locked(&d->event_lock));
+
+    XVFREE(dom_state_changed);
+}
+
+static void domain_changed_state(const struct domain *d)
+{
+    struct domain *hdl;
+
+    hdl = lock_dom_exc_handler();
+    if ( unlikely(!hdl) )
+        return;
+
+    if ( dom_state_changed )
+        set_bit(d->domain_id, dom_state_changed);
+
+    unlock_dom_exc_handler(hdl);
+}
+
 static void __domain_finalise_shutdown(struct domain *d)
 {
     struct vcpu *v;
@@ -153,6 +199,7 @@ static void __domain_finalise_shutdown(struct domain *d)
             return;
 
     d->is_shut_down = 1;
+    domain_changed_state(d);
     if ( (d->shutdown_code == SHUTDOWN_suspend) && d->suspend_evtchn )
         evtchn_send(d, d->suspend_evtchn);
     else
@@ -840,6 +887,7 @@ struct domain *domain_create(domid_t domid,
      */
     domlist_insert(d);
 
+    domain_changed_state(d);
     memcpy(d->handle, config->handle, sizeof(d->handle));
 
     return d;
@@ -1105,6 +1153,7 @@ int domain_kill(struct domain *d)
         /* Mem event cleanup has to go here because the rings 
          * have to be put before we call put_domain. */
         vm_event_cleanup(d);
+        domain_changed_state(d);
         put_domain(d);
         send_global_virq(VIRQ_DOM_EXC);
         /* fallthrough */
@@ -1294,6 +1343,8 @@ static void cf_check complete_domain_destroy(struct rcu_head *head)
 
     xfree(d->vcpu);
 
+    domain_changed_state(d);
+
     _domain_destroy(d);
 
     send_global_virq(VIRQ_DOM_EXC);
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 341221d420..c247efc4b1 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -506,10 +506,18 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind, evtchn_port_t port)
         goto out;
     }
 
+    if ( virq == VIRQ_DOM_EXC )
+    {
+        rc = domain_init_states();
+        if ( rc )
+            goto out;
+    }
+
     port = rc = evtchn_get_port(d, port);
     if ( rc < 0 )
     {
         gdprintk(XENLOG_WARNING, "EVTCHNOP failure: error %d\n", rc);
+        domain_deinit_states(d);
         goto out;
     }
 
@@ -742,6 +750,9 @@ int evtchn_close(struct domain *d1, int port1, bool guest)
         struct vcpu *v;
         unsigned long flags;
 
+        if ( chn1->u.virq == VIRQ_DOM_EXC )
+            domain_deinit_states(d1);
+
         v = d1->vcpu[virq_is_global(chn1->u.virq) ? 0 : chn1->notify_vcpu_id];
 
         write_lock_irqsave(&v->virq_lock, flags);
@@ -1063,6 +1074,26 @@ static void clear_global_virq_handlers(struct domain *d)
     }
 }
 
+struct domain *lock_dom_exc_handler(void)
+{
+    struct domain *d;
+
+    d = get_global_virq_handler(VIRQ_DOM_EXC);
+    if ( unlikely(!get_domain(d)) )
+        return NULL;
+
+    read_lock(&d->event_lock);
+
+    return d;
+}
+
+void unlock_dom_exc_handler(struct domain *d)
+{
+    read_unlock(&d->event_lock);
+
+    put_domain(d);
+}
+
 int evtchn_status(evtchn_status_t *status)
 {
     struct domain   *d;
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 48b79f3d62..5c0ba90c9f 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -100,6 +100,10 @@ bool evtchn_virq_enabled(const struct vcpu *v, unsigned int virq);
 /* Notify remote end of a Xen-attached event channel.*/
 void notify_via_xen_event_channel(struct domain *ld, int lport);
 
+/* Lock/unlock of VIRQ_DOM_EXC associated data (read_lock(d->event_lock)). */
+struct domain *lock_dom_exc_handler(void);
+void unlock_dom_exc_handler(struct domain *d);
+
 /*
  * Internal event channel object storage.
  *
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 037c83fda2..9d9b89ec27 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -805,6 +805,9 @@ void domain_resume(struct domain *d);
 
 int domain_soft_reset(struct domain *d, bool resuming);
 
+int domain_init_states(void);
+void domain_deinit_states(const struct domain *d);
+
 int vcpu_start_shutdown_deferral(struct vcpu *v);
 void vcpu_end_shutdown_deferral(struct vcpu *v);
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 07 10:17:46 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 10:17:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866262.1277604 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV6eg-0003th-JS; Tue, 07 Jan 2025 10:17:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866262.1277604; Tue, 07 Jan 2025 10:17:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV6eg-0003tU-EV; Tue, 07 Jan 2025 10:17:46 +0000
Received: by outflank-mailman (input) for mailman id 866262;
 Tue, 07 Jan 2025 10:17: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 <SRS0=Qdqe=T7=suse.com=jgross@srs-se1.protection.inumbo.net>)
 id 1tV6ee-00022t-LG
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 10:17:44 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a205886e-cce0-11ef-a0df-8be0dac302b0;
 Tue, 07 Jan 2025 11:17:43 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id 301C721111;
 Tue,  7 Jan 2025 10:17:43 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id D045413763;
 Tue,  7 Jan 2025 10:17:42 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id yJBUMUb/fGcZYgAAD6G6ig
 (envelope-from <jgross@suse.com>); Tue, 07 Jan 2025 10:17:42 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a205886e-cce0-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1736245063; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=Mnyb1VTsPzRYzo1crPy1xQ6Z7waAvUFyhIHQGke0Ywk=;
	b=Dq1eNPpp+/CUmUUMh7KiPdoD+UykoT9A+syPOqyS1Pe1RzS/Z2c/MrEebypkCprIYLsk9D
	2OnT/Exn830W9f33GOE/bvm9PG7SchXvCVxRUmxjy7ZUSKRRZWlfQWkdocTOMI9bO7AvS/
	hxHoSK39mmzoa+5cL0o9WwWKPoO966U=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1736245063; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=Mnyb1VTsPzRYzo1crPy1xQ6Z7waAvUFyhIHQGke0Ywk=;
	b=Dq1eNPpp+/CUmUUMh7KiPdoD+UykoT9A+syPOqyS1Pe1RzS/Z2c/MrEebypkCprIYLsk9D
	2OnT/Exn830W9f33GOE/bvm9PG7SchXvCVxRUmxjy7ZUSKRRZWlfQWkdocTOMI9bO7AvS/
	hxHoSK39mmzoa+5cL0o9WwWKPoO966U=
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross <jgross@suse.com>,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v6 5/7] xen: add new domctl get_changed_domain
Date: Tue,  7 Jan 2025 11:17:09 +0100
Message-ID: <20250107101711.5980-6-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250107101711.5980-1-jgross@suse.com>
References: <20250107101711.5980-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.80
X-Spamd-Result: default: False [-2.80 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-0.999];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_SEVEN(0.00)[10];
	TO_DN_SOME(0.00)[];
	MIME_TRACE(0.00)[0:+];
	ARC_NA(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	R_RATELIMIT(0.00)[to_ip_from(RLme6mccyyenyxxgt1bwti8hnf)];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,suse.com:mid,suse.com:email];
	RCVD_TLS_ALL(0.00)[]
X-Spam-Flag: NO
X-Spam-Level: 

Add a new domctl sub-function to get data of a domain having changed
state (this is needed by Xenstore).

The returned state just contains the domid, the domain unique id,
and some flags (existing, shutdown, dying).

In order to enable Xenstore stubdom being built for multiple Xen
versions, make this domctl stable.  For stable domctls the
interface_version is always 0.

Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>
---
V1:
- use a domctl subop for the new interface (Jan Beulich)
V2:
- fix XSM hooks (Daniel P. Smith)
- remove versioning of stable sub-ops (Jan Beulich)
- use domctl.domain for retuning domid of a changed domain (Jan Beulich)
- simplify locking in get_domain_state() (Jan Beulich)
- undo stray change in event_channel.c (Jan Beulich)
V3:
- have disjunct states "dying" and "dead" (Jan Beulich)
- check padding fields to be 0 (Jan Beulich)
- drop memset() (Jan Beulich)
V4:
- add locking in get_domain_state() (Jan Beulich)
- only allow querying domain having changed state by domain receiving
  VIRQ_DOM_EXC events (Jan Beulich)
V5:
- use memset() (Jan Beulich)
---
 tools/flask/policy/modules/dom0.te     |  2 +-
 tools/flask/policy/modules/xen.if      |  4 +-
 tools/flask/policy/modules/xenstore.te |  1 +
 xen/common/domain.c                    | 70 ++++++++++++++++++++++++++
 xen/common/domctl.c                    | 18 ++++++-
 xen/common/event_channel.c             |  9 +++-
 xen/include/public/domctl.h            | 26 ++++++++++
 xen/include/xen/event.h                |  7 +++
 xen/include/xen/sched.h                |  2 +
 xen/include/xsm/dummy.h                |  8 +++
 xen/include/xsm/xsm.h                  |  6 +++
 xen/xsm/dummy.c                        |  1 +
 xen/xsm/flask/hooks.c                  |  7 +++
 xen/xsm/flask/policy/access_vectors    |  2 +
 14 files changed, 158 insertions(+), 5 deletions(-)

diff --git a/tools/flask/policy/modules/dom0.te b/tools/flask/policy/modules/dom0.te
index 16b8c9646d..6043c01b12 100644
--- a/tools/flask/policy/modules/dom0.te
+++ b/tools/flask/policy/modules/dom0.te
@@ -40,7 +40,7 @@ allow dom0_t dom0_t:domain {
 };
 allow dom0_t dom0_t:domain2 {
 	set_cpu_policy gettsc settsc setscheduler set_vnumainfo
-	get_vnumainfo psr_cmt_op psr_alloc get_cpu_policy
+	get_vnumainfo psr_cmt_op psr_alloc get_cpu_policy get_domain_state
 };
 allow dom0_t dom0_t:resource { add remove };
 
diff --git a/tools/flask/policy/modules/xen.if b/tools/flask/policy/modules/xen.if
index 11c1562aa5..2e06f3ed94 100644
--- a/tools/flask/policy/modules/xen.if
+++ b/tools/flask/policy/modules/xen.if
@@ -54,7 +54,7 @@ define(`create_domain_common', `
 	allow $1 $2:domain2 { set_cpu_policy settsc setscheduler setclaim
 			set_vnumainfo get_vnumainfo cacheflush
 			psr_cmt_op psr_alloc soft_reset
-			resource_map get_cpu_policy };
+			resource_map get_cpu_policy get_domain_state };
 	allow $1 $2:security check_context;
 	allow $1 $2:shadow enable;
 	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op updatemp };
@@ -94,7 +94,7 @@ define(`manage_domain', `
 			getaddrsize pause unpause trigger shutdown destroy
 			setaffinity setdomainmaxmem getscheduler resume
 			setpodtarget getpodtarget getpagingmempool setpagingmempool };
-    allow $1 $2:domain2 set_vnumainfo;
+    allow $1 $2:domain2 { set_vnumainfo get_domain_state };
 ')
 
 # migrate_domain_out(priv, target)
diff --git a/tools/flask/policy/modules/xenstore.te b/tools/flask/policy/modules/xenstore.te
index 519566ab81..49de53ebe2 100644
--- a/tools/flask/policy/modules/xenstore.te
+++ b/tools/flask/policy/modules/xenstore.te
@@ -13,6 +13,7 @@ allow dom0_t xenstore_t:domain set_virq_handler;
 allow xenstore_t xen_t:xen writeconsole;
 # Xenstore queries domaininfo on all domains
 allow xenstore_t domain_type:domain getdomaininfo;
+allow xenstore_t domain_type:domain2 get_domain_state;
 
 # As a shortcut, the following 3 rules are used instead of adding a domain_comms
 # rule between xenstore_t and every domain type that talks to xenstore
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 78e2732e94..783a79e447 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -185,6 +185,76 @@ static void domain_changed_state(const struct domain *d)
     unlock_dom_exc_handler(hdl);
 }
 
+static void set_domain_state_info(struct xen_domctl_get_domain_state *info,
+                                  const struct domain *d)
+{
+    info->state = XEN_DOMCTL_GETDOMSTATE_STATE_EXIST;
+    if ( d->is_shut_down )
+        info->state |= XEN_DOMCTL_GETDOMSTATE_STATE_SHUTDOWN;
+    if ( d->is_dying == DOMDYING_dying )
+        info->state |= XEN_DOMCTL_GETDOMSTATE_STATE_DYING;
+    if ( d->is_dying == DOMDYING_dead )
+        info->state |= XEN_DOMCTL_GETDOMSTATE_STATE_DEAD;
+    info->unique_id = d->unique_id;
+}
+
+int get_domain_state(struct xen_domctl_get_domain_state *info, struct domain *d,
+                     domid_t *domid)
+{
+    unsigned int dom;
+    int rc = -ENOENT;
+    struct domain *hdl;
+
+    if ( info->pad0 || info->pad1 )
+        return -EINVAL;
+
+    if ( d )
+    {
+        set_domain_state_info(info, d);
+
+        return 0;
+    }
+
+    /*
+     * Only domain registered for VIRQ_DOM_EXC event is allowed to query
+     * domains having changed state.
+     */
+    if ( !domain_handles_global_virq(current->domain, VIRQ_DOM_EXC) )
+        return -EACCES;
+
+    hdl = lock_dom_exc_handler();
+
+    while ( dom_state_changed )
+    {
+        dom = find_first_bit(dom_state_changed, DOMID_MASK + 1);
+        if ( dom >= DOMID_FIRST_RESERVED )
+            break;
+        if ( test_and_clear_bit(dom, dom_state_changed) )
+        {
+            *domid = dom;
+
+            d = rcu_lock_domain_by_id(dom);
+
+            if ( d )
+            {
+                set_domain_state_info(info, d);
+
+                rcu_unlock_domain(d);
+            }
+            else
+                memset(info, 0, sizeof(*info));
+
+            rc = 0;
+
+            break;
+        }
+    }
+
+    unlock_dom_exc_handler(hdl);
+
+    return rc;
+}
+
 static void __domain_finalise_shutdown(struct domain *d)
 {
     struct vcpu *v;
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 05abb581a0..b897ca8723 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -279,6 +279,11 @@ static struct vnuma_info *vnuma_init(const struct xen_domctl_vnuma *uinfo,
     return ERR_PTR(ret);
 }
 
+static bool is_stable_domctl(uint32_t cmd)
+{
+    return cmd == XEN_DOMCTL_get_domain_state;
+}
+
 long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
 {
     long ret = 0;
@@ -289,7 +294,8 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
     if ( copy_from_guest(op, u_domctl, 1) )
         return -EFAULT;
 
-    if ( op->interface_version != XEN_DOMCTL_INTERFACE_VERSION )
+    if ( op->interface_version !=
+         (is_stable_domctl(op->cmd) ? 0 : XEN_DOMCTL_INTERFACE_VERSION) )
         return -EACCES;
 
     switch ( op->cmd )
@@ -310,6 +316,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
         fallthrough;
     case XEN_DOMCTL_test_assign_device:
     case XEN_DOMCTL_vm_event_op:
+    case XEN_DOMCTL_get_domain_state:
         if ( op->domain == DOMID_INVALID )
         {
             d = NULL;
@@ -876,6 +883,15 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
             ret = -EOPNOTSUPP;
         break;
 
+    case XEN_DOMCTL_get_domain_state:
+        ret = xsm_get_domain_state(XSM_XS_PRIV, d);
+        if ( ret )
+            break;
+
+        copyback = 1;
+        ret = get_domain_state(&op->u.get_domain_state, d, &op->domain);
+        break;
+
     default:
         ret = arch_do_domctl(op, d, u_domctl);
         break;
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index c247efc4b1..ed55f73648 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -997,6 +997,13 @@ void send_global_virq(uint32_t virq)
     send_guest_global_virq(get_global_virq_handler(virq), virq);
 }
 
+bool domain_handles_global_virq(const struct domain *d, uint32_t virq)
+{
+    ASSERT(virq_is_global(virq));
+
+    return get_global_virq_handler(virq) == d;
+}
+
 int set_global_virq_handler(struct domain *d, uint32_t virq)
 {
     struct domain *old, *hdl;
@@ -1008,7 +1015,7 @@ int set_global_virq_handler(struct domain *d, uint32_t virq)
     if (!virq_is_global(virq))
         return -EINVAL;
 
-    if (global_virq_handlers[virq] == d)
+    if ( domain_handles_global_virq(d, virq) )
         return 0;
 
     if (unlikely(!get_domain(d)))
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index e2d392d1e5..5b2063eed9 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -28,6 +28,7 @@
  * Pure additions (e.g. new sub-commands) or compatible interface changes
  * (e.g. adding semantics to 0-checked input fields or data to zeroed output
  * fields) don't require a change of the version.
+ * Stable ops are NOT covered by XEN_DOMCTL_INTERFACE_VERSION!
  *
  * Last version bump: Xen 4.19
  */
@@ -1243,7 +1244,30 @@ struct xen_domctl_set_llc_colors {
     XEN_GUEST_HANDLE_64(uint32) llc_colors;
 };
 
+/*
+ * XEN_DOMCTL_get_domain_state (stable interface)
+ *
+ * Get state information of a domain.
+ *
+ * In case domain is DOMID_INVALID, return information about a domain having
+ * changed state and reset the state change indicator for that domain. This
+ * function is usable only by a domain having registered the VIRQ_DOM_EXC
+ * event (normally Xenstore).
+ * NB. xen_domctl.domain is an IN/OUT parameter for this operation.
+ */
+struct xen_domctl_get_domain_state {
+    uint16_t state;
+#define XEN_DOMCTL_GETDOMSTATE_STATE_EXIST     0x0001  /* Domain is existing. */
+#define XEN_DOMCTL_GETDOMSTATE_STATE_SHUTDOWN  0x0002  /* Shutdown finished. */
+#define XEN_DOMCTL_GETDOMSTATE_STATE_DYING     0x0004  /* Domain dying. */
+#define XEN_DOMCTL_GETDOMSTATE_STATE_DEAD      0x0008  /* Domain dead. */
+    uint16_t pad0;           /* Must be 0 on input, returned as 0. */
+    uint32_t pad1;           /* Must be 0 on input, returned as 0. */
+    uint64_t unique_id;      /* Unique domain identifier. */
+};
+
 struct xen_domctl {
+/* Stable domctl ops: interface_version is required to be 0.  */
     uint32_t cmd;
 #define XEN_DOMCTL_createdomain                   1
 #define XEN_DOMCTL_destroydomain                  2
@@ -1333,6 +1357,7 @@ struct xen_domctl {
 #define XEN_DOMCTL_dt_overlay                    87
 #define XEN_DOMCTL_gsi_permission                88
 #define XEN_DOMCTL_set_llc_colors                89
+#define XEN_DOMCTL_get_domain_state              90 /* stable interface */
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -1400,6 +1425,7 @@ struct xen_domctl {
         struct xen_domctl_dt_overlay        dt_overlay;
 #endif
         struct xen_domctl_set_llc_colors    set_llc_colors;
+        struct xen_domctl_get_domain_state  get_domain_state;
         uint8_t                             pad[128];
     } u;
 };
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 5c0ba90c9f..ae02012cc5 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -36,6 +36,13 @@ void send_global_virq(uint32_t virq);
  */
 void send_guest_global_virq(struct domain *d, uint32_t virq);
 
+/*
+ * domain_handles_global_virq:
+ *  @d:        Suspected target domain for this VIRQ
+ *  @virq:     Virtual IRQ number (VIRQ_*), must be global
+ */
+bool domain_handles_global_virq(const struct domain *d, uint32_t virq);
+
 /*
  * sent_global_virq_handler: Set a global VIRQ handler.
  *  @d:        New target domain for this VIRQ
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 9d9b89ec27..ea63ca1c79 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -807,6 +807,8 @@ int domain_soft_reset(struct domain *d, bool resuming);
 
 int domain_init_states(void);
 void domain_deinit_states(const struct domain *d);
+int get_domain_state(struct xen_domctl_get_domain_state *info,
+                     struct domain *d, domid_t *domid);
 
 int vcpu_start_shutdown_deferral(struct vcpu *v);
 void vcpu_end_shutdown_deferral(struct vcpu *v);
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 6a2fc33c3b..a8d06de6b0 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -173,6 +173,7 @@ static XSM_INLINE int cf_check xsm_domctl(
     case XEN_DOMCTL_unbind_pt_irq:
         return xsm_default_action(XSM_DM_PRIV, current->domain, d);
     case XEN_DOMCTL_getdomaininfo:
+    case XEN_DOMCTL_get_domain_state:
         return xsm_default_action(XSM_XS_PRIV, current->domain, d);
     default:
         return xsm_default_action(XSM_PRIV, current->domain, d);
@@ -815,6 +816,13 @@ static XSM_INLINE int cf_check xsm_argo_send(
 
 #endif /* CONFIG_ARGO */
 
+static XSM_INLINE int cf_check xsm_get_domain_state(
+    XSM_DEFAULT_ARG struct domain *d)
+{
+    XSM_ASSERT_ACTION(XSM_XS_PRIV);
+    return xsm_default_action(action, current->domain, d);
+}
+
 #include <public/version.h>
 static XSM_INLINE int cf_check xsm_xen_version(XSM_DEFAULT_ARG uint32_t op)
 {
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 4dbff9d866..0689bf5c9f 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -200,6 +200,7 @@ struct xsm_ops {
     int (*argo_register_any_source)(const struct domain *d);
     int (*argo_send)(const struct domain *d, const struct domain *t);
 #endif
+    int (*get_domain_state)(struct domain *d);
 };
 
 #ifdef CONFIG_XSM
@@ -774,6 +775,11 @@ static inline int xsm_argo_send(const struct domain *d, const struct domain *t)
 
 #endif /* CONFIG_ARGO */
 
+static inline int xsm_get_domain_state(struct domain *d)
+{
+    return alternative_call(xsm_ops.get_domain_state, d);
+}
+
 #endif /* XSM_NO_WRAPPERS */
 
 #ifdef CONFIG_MULTIBOOT
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index e6ffa948f7..ce6fbdc6c5 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -148,6 +148,7 @@ static const struct xsm_ops __initconst_cf_clobber dummy_ops = {
     .argo_register_any_source      = xsm_argo_register_any_source,
     .argo_send                     = xsm_argo_send,
 #endif
+    .get_domain_state              = xsm_get_domain_state,
 };
 
 void __init xsm_fixup_ops(struct xsm_ops *ops)
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 2b4efde689..f126e50b92 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -688,6 +688,7 @@ static int cf_check flask_domctl(struct domain *d, unsigned int cmd,
     case XEN_DOMCTL_memory_mapping:
     case XEN_DOMCTL_set_target:
     case XEN_DOMCTL_vm_event_op:
+    case XEN_DOMCTL_get_domain_state:
 
     /* These have individual XSM hooks (arch/../domctl.c) */
     case XEN_DOMCTL_bind_pt_irq:
@@ -1860,6 +1861,11 @@ static int cf_check flask_argo_send(
 
 #endif
 
+static int cf_check flask_get_domain_state(struct domain *d)
+{
+    return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__GET_DOMAIN_STATE);
+}
+
 static const struct xsm_ops __initconst_cf_clobber flask_ops = {
     .set_system_active = flask_set_system_active,
     .security_domaininfo = flask_security_domaininfo,
@@ -1996,6 +2002,7 @@ static const struct xsm_ops __initconst_cf_clobber flask_ops = {
     .argo_register_any_source = flask_argo_register_any_source,
     .argo_send = flask_argo_send,
 #endif
+    .get_domain_state = flask_get_domain_state,
 };
 
 const struct xsm_ops *__init flask_init(
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index a35e3d4c51..c9a8eeda4e 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -251,6 +251,8 @@ class domain2
     resource_map
 # XEN_DOMCTL_get_cpu_policy
     get_cpu_policy
+# XEN_DOMCTL_get_domain_state
+    get_domain_state
 }
 
 # Similar to class domain, but primarily contains domctls related to HVM domains
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 07 10:17:53 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 10:17:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866269.1277613 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV6em-0004UE-V6; Tue, 07 Jan 2025 10:17:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866269.1277613; Tue, 07 Jan 2025 10:17:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV6em-0004U2-Rc; Tue, 07 Jan 2025 10:17:52 +0000
Received: by outflank-mailman (input) for mailman id 866269;
 Tue, 07 Jan 2025 10:17:51 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Qdqe=T7=suse.com=jgross@srs-se1.protection.inumbo.net>)
 id 1tV6el-0002Gw-2q
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 10:17:51 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a54d9a82-cce0-11ef-99a4-01e77a169b0f;
 Tue, 07 Jan 2025 11:17:49 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id B5AEF1F385;
 Tue,  7 Jan 2025 10:17:48 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 9168813763;
 Tue,  7 Jan 2025 10:17:48 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id xxPuIUz/fGchYgAAD6G6ig
 (envelope-from <jgross@suse.com>); Tue, 07 Jan 2025 10:17:48 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a54d9a82-cce0-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1736245068; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=J6JSRc8YlyUyRyNjaDAT1q6d2ZzULe0kJJ0JZTfWW/U=;
	b=gyOmSpK3Ie1H0q/EP1hKb0b+N8S9ueQDcFR5LPEtAWk4SKW4Vl1wCgk6ZRauKkM7maSe+g
	ryY/vDNMO3W+oKTNengcW3Fat54t+v/+Kj61OQA33rCCzxkvaek7p8l5tDioB6+3m0Cklm
	uHA1TIAX64o1sC4Hk39o49NHJbHbZ4I=
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1736245068; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=J6JSRc8YlyUyRyNjaDAT1q6d2ZzULe0kJJ0JZTfWW/U=;
	b=gyOmSpK3Ie1H0q/EP1hKb0b+N8S9ueQDcFR5LPEtAWk4SKW4Vl1wCgk6ZRauKkM7maSe+g
	ryY/vDNMO3W+oKTNengcW3Fat54t+v/+Kj61OQA33rCCzxkvaek7p8l5tDioB6+3m0Cklm
	uHA1TIAX64o1sC4Hk39o49NHJbHbZ4I=
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross <jgross@suse.com>,
	Anthony PERARD <anthony.perard@vates.tech>
Subject: [PATCH v6 6/7] tools/libs: add a new libxenmanage library
Date: Tue,  7 Jan 2025 11:17:10 +0100
Message-ID: <20250107101711.5980-7-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250107101711.5980-1-jgross@suse.com>
References: <20250107101711.5980-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.80
X-Spamd-Result: default: False [-2.80 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-0.999];
	MIME_GOOD(-0.10)[text/plain];
	MIME_TRACE(0.00)[0:+];
	TO_DN_SOME(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,suse.com:mid,suse.com:email];
	RCVD_TLS_ALL(0.00)[]
X-Spam-Flag: NO
X-Spam-Level: 

In order to have a stable interface in user land for using stable
domctl and possibly later sysctl interfaces, add a new library
libxenmanage.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
---
V1:
- new patch
V2:
- define __XEN_TOOLS__ via Makefile (Anthony PERARD)
- use SPDX in header file (Anthony PERARD)
- change function name to xenmanage_poll_changed_domain() (Anthony PERARD)
- add short library description (Anthony PERARD)
- narrow scope of xen_domctl_get_domain_state pointer (Anthony PERARD)
V4:
- use LGPL-2.1-only SPDX identifier (Anthony PERARD)
---
 tools/include/xenmanage.h          |  92 ++++++++++++++++
 tools/libs/Makefile                |   1 +
 tools/libs/manage/Makefile         |  10 ++
 tools/libs/manage/Makefile.common  |   3 +
 tools/libs/manage/core.c           | 168 +++++++++++++++++++++++++++++
 tools/libs/manage/libxenmanage.map |   8 ++
 tools/libs/uselibs.mk              |   2 +
 7 files changed, 284 insertions(+)
 create mode 100644 tools/include/xenmanage.h
 create mode 100644 tools/libs/manage/Makefile
 create mode 100644 tools/libs/manage/Makefile.common
 create mode 100644 tools/libs/manage/core.c
 create mode 100644 tools/libs/manage/libxenmanage.map

diff --git a/tools/include/xenmanage.h b/tools/include/xenmanage.h
new file mode 100644
index 0000000000..956b7a0a44
--- /dev/null
+++ b/tools/include/xenmanage.h
@@ -0,0 +1,92 @@
+/* SPDX-License-Identifier: LGPL-2.1-only */
+/*
+ * Copyright (c) 2024 SUSE Software Solutions Germany GmbH
+ *
+ * Interfaces of libxenmanage.
+ *
+ * libxenmanage provides management functions for the host using stable
+ * hypercall interfaces.
+ */
+#ifndef XENMANAGE_H
+#define XENMANAGE_H
+
+#include <stdint.h>
+
+/* Avoid the need to #include <xentoollog.h> */
+struct xentoollog_logger;
+
+typedef struct xenmanage_handle xenmanage_handle;
+
+/*
+ * Open libxenmanage.
+ *
+ * Get a handle of the xenmanage library. The handle is required for all
+ * further operations of the library.
+ * Parameters:
+ *   logger:     Logging function to use. If NULL logging is done to stderr.
+ *   open_flags: Only 0 supported.
+ * Return value: Handle or NULL if error.
+ */
+xenmanage_handle *xenmanage_open(struct xentoollog_logger *logger,
+                                 unsigned int open_flags);
+
+/*
+ * Close libxenmanage.
+ *
+ * Return a handle of the xenmanage library.
+ * Parameters:
+ *    hdl: Handle obtained by xenmanage_open().
+ * Return value: always 0.
+ */
+int xenmanage_close(xenmanage_handle *hdl);
+
+#define XENMANAGE_GETDOMSTATE_STATE_EXIST     0x0001  /* Domain is existing. */
+#define XENMANAGE_GETDOMSTATE_STATE_SHUTDOWN  0x0002  /* Shutdown finished. */
+#define XENMANAGE_GETDOMSTATE_STATE_DYING     0x0004  /* Domain dying. */
+#define XENMANAGE_GETDOMSTATE_STATE_DEAD      0x0008  /* Domain dead. */
+
+/*
+ * Return state information of an existing domain.
+ *
+ * Returns the domain state and unique id of the given domain.
+ * Parameters:
+ *   hdl:       handle returned by xenmanage_open()
+ *   domid:     domain id of the domain to get the information for
+ *   state:     where to store the state (XENMANAGE_GETDOMSTATE_STATE_ flags,
+ *              nothing stored if NULL)
+ *   unique_id: where to store the unique id of the domain (nothing stored if
+ *              NULL)
+ * Return value: 0 if information was stored, -1 else (errno is set)
+ */
+int xenmanage_get_domain_info(xenmanage_handle *hdl, unsigned int domid,
+                              unsigned int *state, uint64_t *unique_id);
+
+/*
+ * Return information of a domain having changed state recently.
+ *
+ * Returns the domain id, state and unique id of a domain having changed
+ * state (any of the state bits was modified) since the last time information
+ * for that domain was returned by this function. Only usable by callers who
+ * have registered the VIRQ_DOM_EXC event (normally Xenstore).
+ * Parameters:
+ *   hdl:       handle returned by xenmanage_open()
+ *   domid:     where to store the domid of the domain (not NULL)
+ *   state:     where to store the state (XENMANAGE_GETDOMSTATE_STATE_ flags,
+ *              nothing stored if NULL)
+ *   unique_id: where to store the unique id of the domain (nothing stored if
+ *              NULL)
+ * Return value: 0 if information was stored, -1 else (errno is set)
+ */
+int xenmanage_poll_changed_domain(xenmanage_handle *hdl, unsigned int *domid,
+                                  unsigned int *state, uint64_t *unique_id);
+#endif /* XENMANAGE_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libs/Makefile b/tools/libs/Makefile
index 1afcd12e2b..d39516c1b3 100644
--- a/tools/libs/Makefile
+++ b/tools/libs/Makefile
@@ -12,6 +12,7 @@ SUBDIRS-y += devicemodel
 SUBDIRS-y += ctrl
 SUBDIRS-y += guest
 SUBDIRS-y += hypfs
+SUBDIRS-y += manage
 SUBDIRS-y += store
 SUBDIRS-y += stat
 SUBDIRS-$(CONFIG_Linux) += vchan
diff --git a/tools/libs/manage/Makefile b/tools/libs/manage/Makefile
new file mode 100644
index 0000000000..dbfe70d259
--- /dev/null
+++ b/tools/libs/manage/Makefile
@@ -0,0 +1,10 @@
+XEN_ROOT = $(CURDIR)/../../..
+include $(XEN_ROOT)/tools/Rules.mk
+
+MAJOR    = 1
+MINOR    = 0
+version-script := libxenmanage.map
+
+include Makefile.common
+
+include $(XEN_ROOT)/tools/libs/libs.mk
diff --git a/tools/libs/manage/Makefile.common b/tools/libs/manage/Makefile.common
new file mode 100644
index 0000000000..533ba30fba
--- /dev/null
+++ b/tools/libs/manage/Makefile.common
@@ -0,0 +1,3 @@
+CFLAGS += -D__XEN_TOOLS__
+
+OBJS-y  += core.o
diff --git a/tools/libs/manage/core.c b/tools/libs/manage/core.c
new file mode 100644
index 0000000000..8fb421df41
--- /dev/null
+++ b/tools/libs/manage/core.c
@@ -0,0 +1,168 @@
+/*
+ * Copyright (c) 2024 SUSE Software Solutions Germany GmbH
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#define _GNU_SOURCE
+
+#include <errno.h>
+#include <stdlib.h>
+#include <string.h>
+
+#include <xentoollog.h>
+#include <xenmanage.h>
+#include <xencall.h>
+#include <xentoolcore_internal.h>
+
+#include <xen/xen.h>
+#include <xen/domctl.h>
+
+struct xenmanage_handle {
+    xentoollog_logger *logger, *logger_tofree;
+    unsigned int flags;
+    xencall_handle *xcall;
+};
+
+xenmanage_handle *xenmanage_open(xentoollog_logger *logger,
+                                 unsigned int open_flags)
+{
+    xenmanage_handle *hdl = calloc(1, sizeof(*hdl));
+    int saved_errno;
+
+    if ( !hdl )
+        return NULL;
+
+    if ( open_flags )
+    {
+        errno = EINVAL;
+        goto err;
+    }
+
+    hdl->flags = open_flags;
+    hdl->logger = logger;
+    hdl->logger_tofree = NULL;
+
+    if ( !hdl->logger )
+    {
+        hdl->logger = hdl->logger_tofree =
+            (xentoollog_logger *)
+            xtl_createlogger_stdiostream(stderr, XTL_PROGRESS, 0);
+        if ( !hdl->logger )
+            goto err;
+    }
+
+    hdl->xcall = xencall_open(hdl->logger, 0);
+    if ( !hdl->xcall )
+        goto err;
+
+    return hdl;
+
+err:
+    saved_errno = errno;
+    xenmanage_close(hdl);
+    errno = saved_errno;
+
+    return NULL;
+}
+
+int xenmanage_close(xenmanage_handle *hdl)
+{
+    if ( !hdl )
+        return 0;
+
+    xencall_close(hdl->xcall);
+    xtl_logger_destroy(hdl->logger_tofree);
+    free(hdl);
+    return 0;
+}
+
+static int xenmanage_do_domctl_get_domain_state(xenmanage_handle *hdl,
+                                                unsigned int domid_in,
+                                                unsigned int *domid_out,
+                                                unsigned int *state,
+                                                uint64_t *unique_id)
+{
+    struct xen_domctl *buf;
+    int saved_errno;
+    int ret;
+
+    buf = xencall_alloc_buffer(hdl->xcall, sizeof(*buf));
+    if ( !buf )
+    {
+        errno = ENOMEM;
+        return -1;
+    }
+
+    memset(buf, 0, sizeof(*buf));
+
+    buf->cmd = XEN_DOMCTL_get_domain_state;
+    buf->domain = domid_in;
+
+    ret = xencall1(hdl->xcall, __HYPERVISOR_domctl, (unsigned long)buf);
+    saved_errno = errno;
+    if ( !ret )
+    {
+        struct xen_domctl_get_domain_state *st = &buf->u.get_domain_state;
+
+        if ( domid_out )
+            *domid_out = buf->domain;
+        if ( state )
+        {
+            *state = 0;
+            if ( st->state & XEN_DOMCTL_GETDOMSTATE_STATE_EXIST )
+                *state |= XENMANAGE_GETDOMSTATE_STATE_EXIST;
+            if ( st->state & XEN_DOMCTL_GETDOMSTATE_STATE_SHUTDOWN )
+                *state |= XENMANAGE_GETDOMSTATE_STATE_SHUTDOWN;
+            if ( st->state & XEN_DOMCTL_GETDOMSTATE_STATE_DYING )
+                *state |= XENMANAGE_GETDOMSTATE_STATE_DYING;
+            if ( st->state & XEN_DOMCTL_GETDOMSTATE_STATE_DEAD )
+                *state |= XENMANAGE_GETDOMSTATE_STATE_DEAD;
+        }
+        if ( unique_id )
+            *unique_id = st->unique_id;
+    }
+
+    xencall_free_buffer(hdl->xcall, buf);
+
+    errno = saved_errno;
+
+    return ret;
+}
+
+int xenmanage_get_domain_info(xenmanage_handle *hdl, unsigned int domid,
+                              unsigned int *state, uint64_t *unique_id)
+{
+    if ( !hdl || domid >= DOMID_FIRST_RESERVED )
+    {
+        errno = EINVAL;
+        return -1;
+    }
+
+    return xenmanage_do_domctl_get_domain_state(hdl, domid, NULL, state,
+                                                unique_id);
+}
+
+int xenmanage_poll_changed_domain(xenmanage_handle *hdl, unsigned int *domid,
+                                  unsigned int *state, uint64_t *unique_id)
+{
+    if ( !hdl || !domid )
+    {
+        errno = EINVAL;
+        return -1;
+    }
+
+    return xenmanage_do_domctl_get_domain_state(hdl, DOMID_INVALID, domid,
+                                                state, unique_id);
+}
diff --git a/tools/libs/manage/libxenmanage.map b/tools/libs/manage/libxenmanage.map
new file mode 100644
index 0000000000..64c793e603
--- /dev/null
+++ b/tools/libs/manage/libxenmanage.map
@@ -0,0 +1,8 @@
+VERS_1.0 {
+	global:
+		xenmanage_open;
+		xenmanage_close;
+		xenmanage_get_domain_info;
+		xenmanage_poll_changed_domain;
+	local: *; /* Do not expose anything by default */
+};
diff --git a/tools/libs/uselibs.mk b/tools/libs/uselibs.mk
index 7aa8d83e06..c0a234cfec 100644
--- a/tools/libs/uselibs.mk
+++ b/tools/libs/uselibs.mk
@@ -16,6 +16,8 @@ LIBS_LIBS += devicemodel
 USELIBS_devicemodel := toollog toolcore call
 LIBS_LIBS += hypfs
 USELIBS_hypfs := toollog toolcore call
+LIBS_LIBS += manage
+USELIBS_manage := toollog toolcore call
 LIBS_LIBS += ctrl
 USELIBS_ctrl := toollog call evtchn gnttab foreignmemory devicemodel
 LIBS_LIBS += guest
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 07 10:22:11 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 10:22:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866304.1277622 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV6iw-0007YJ-E1; Tue, 07 Jan 2025 10:22:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866304.1277622; Tue, 07 Jan 2025 10:22:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV6iw-0007YC-BV; Tue, 07 Jan 2025 10:22:10 +0000
Received: by outflank-mailman (input) for mailman id 866304;
 Tue, 07 Jan 2025 10:22:10 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Qdqe=T7=suse.com=jgross@srs-se1.protection.inumbo.net>)
 id 1tV6et-00022t-3v
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 10:17:59 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de
 [2a07:de40:b251:101:10:150:64:1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a8c49296-cce0-11ef-a0df-8be0dac302b0;
 Tue, 07 Jan 2025 11:17:55 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id 7A0C521106;
 Tue,  7 Jan 2025 10:17:54 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 3565413763;
 Tue,  7 Jan 2025 10:17:54 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id klfACVL/fGctYgAAD6G6ig
 (envelope-from <jgross@suse.com>); Tue, 07 Jan 2025 10:17:54 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a8c49296-cce0-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1736245074; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=U4Ln9oY8teJqj0oQ6om9doDIAfM1X4V+dyEL2CQtrKA=;
	b=svnUvUvDHyLgtE4r87eEJtO/S+wJDJy5pHks0ApNBpbcXzw2UNMh5nVl8+luTPOSWNBV0k
	7IxLnhoA6CnE9ockug+pEVKsX5fXVO42rFY9khW4GHJ2iUuWalNeDTUdtr9X6ueC1g3mtY
	9hC1o0QoOp7EqlyALX1heKJbKOaNf5k=
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=svnUvUvD
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1736245074; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=U4Ln9oY8teJqj0oQ6om9doDIAfM1X4V+dyEL2CQtrKA=;
	b=svnUvUvDHyLgtE4r87eEJtO/S+wJDJy5pHks0ApNBpbcXzw2UNMh5nVl8+luTPOSWNBV0k
	7IxLnhoA6CnE9ockug+pEVKsX5fXVO42rFY9khW4GHJ2iUuWalNeDTUdtr9X6ueC1g3mtY
	9hC1o0QoOp7EqlyALX1heKJbKOaNf5k=
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross <jgross@suse.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Julien Grall <julien@xen.org>
Subject: [PATCH v6 7/7] tools/xenstored: use new stable interface instead of libxenctrl
Date: Tue,  7 Jan 2025 11:17:11 +0100
Message-ID: <20250107101711.5980-8-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250107101711.5980-1-jgross@suse.com>
References: <20250107101711.5980-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 7A0C521106
X-Spam-Level: 
X-Spamd-Result: default: False [-3.01 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns,suse.com:email,suse.com:dkim,suse.com:mid];
	ASN(0.00)[asn:25478, ipnet:::/0, country:RU];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	MIME_TRACE(0.00)[0:+];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	RCVD_COUNT_TWO(0.00)[2];
	RCVD_TLS_ALL(0.00)[];
	RCPT_COUNT_FIVE(0.00)[5];
	DKIM_TRACE(0.00)[suse.com:+]
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Rspamd-Action: no action
X-Spam-Score: -3.01
X-Spam-Flag: NO

Replace the current use of the unstable xc_domain_getinfo_single()
interface with the stable domctl XEN_DOMCTL_get_domain_state call
via the new libxenmanage library.

This will remove the last usage of libxenctrl by Xenstore, so update
the library dependencies accordingly.

For now only do a direct replacement without using the functionality
of obtaining information about domains having changed the state.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
---
V1:
- use library instead of direct hypercall, only replace current
  libxenctrl use case

Please note that this patch can be committed only after the related
Mini-OS patch "config: add support for libxenmanage" has gone in AND
the Mini-OS commit-id has been updated in Config.mk accordingly!

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 stubdom/Makefile                |  8 ++---
 stubdom/mini-os.mk              |  1 +
 tools/xenstored/Makefile        |  2 +-
 tools/xenstored/Makefile.common |  2 +-
 tools/xenstored/core.h          |  1 -
 tools/xenstored/domain.c        | 52 ++++++++++++---------------------
 tools/xenstored/lu.c            |  1 +
 tools/xenstored/lu_daemon.c     |  1 +
 8 files changed, 28 insertions(+), 40 deletions(-)

diff --git a/stubdom/Makefile b/stubdom/Makefile
index 2a81af28a1..ca800b243c 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -307,7 +307,7 @@ endif
 # libraries under tools/libs
 #######
 
-STUB_LIBS := toolcore toollog evtchn gnttab call foreignmemory devicemodel ctrl guest
+STUB_LIBS := toolcore toollog evtchn gnttab call foreignmemory devicemodel ctrl guest manage
 
 LIBDEP_guest := cross-zlib
 
@@ -465,7 +465,7 @@ grub: cross-polarssl grub-upstream $(CROSS_ROOT) grub-$(XEN_TARGET_ARCH)-minios-
 # xenstore
 ##########
 
-xenstore-minios.gen.cfg: APP_LIBS = gnttab evtchn toollog ctrl
+xenstore-minios.gen.cfg: APP_LIBS = gnttab evtchn toollog manage
 xenstore-minios.gen.cfg: xenstore-minios.cfg Makefile
 	$(GEN_config) >$@
 
@@ -480,7 +480,7 @@ xenstore: $(CROSS_ROOT) xenstore-minios-config.mk
 # xenstorepvh
 #############
 
-xenstorepvh-minios.gen.cfg: APP_LIBS = gnttab evtchn toollog ctrl
+xenstorepvh-minios.gen.cfg: APP_LIBS = gnttab evtchn toollog manage
 xenstorepvh-minios.gen.cfg: xenstorepvh-minios.cfg Makefile
 	$(GEN_config) >$@
 
@@ -523,7 +523,7 @@ else
 pv-grub-if-enabled:
 endif
 
-XENSTORE_DEPS := libxenevtchn libxengnttab libxenctrl
+XENSTORE_DEPS := libxenevtchn libxengnttab libxenmanage
 
 .PHONY: xenstore-stubdom
 xenstore-stubdom: mini-os-$(XEN_TARGET_ARCH)-xenstore $(XENSTORE_DEPS) xenstore
diff --git a/stubdom/mini-os.mk b/stubdom/mini-os.mk
index 7e4968e026..be32302f9e 100644
--- a/stubdom/mini-os.mk
+++ b/stubdom/mini-os.mk
@@ -13,5 +13,6 @@ GNTTAB_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/gnttab
 CALL_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/call
 FOREIGNMEMORY_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/foreignmemory
 DEVICEMODEL_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/devicemodel
+MANAGE_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/manage
 CTRL_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/ctrl
 GUEST_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/guest
diff --git a/tools/xenstored/Makefile b/tools/xenstored/Makefile
index 09adfe1d50..81c42838e0 100644
--- a/tools/xenstored/Makefile
+++ b/tools/xenstored/Makefile
@@ -5,7 +5,7 @@ include Makefile.common
 
 xenstored: LDLIBS += $(LDLIBS_libxenevtchn)
 xenstored: LDLIBS += $(LDLIBS_libxengnttab)
-xenstored: LDLIBS += $(LDLIBS_libxenctrl)
+xenstored: LDLIBS += $(LDLIBS_libxenmanage)
 xenstored: LDLIBS += -lrt
 xenstored: LDLIBS += $(SOCKET_LIBS)
 
diff --git a/tools/xenstored/Makefile.common b/tools/xenstored/Makefile.common
index 27fdb3b49e..271134fcc1 100644
--- a/tools/xenstored/Makefile.common
+++ b/tools/xenstored/Makefile.common
@@ -12,7 +12,7 @@ XENSTORED_OBJS-$(CONFIG_MiniOS) += minios.o lu_minios.o
 # Include configure output (config.h)
 CFLAGS += -include $(XEN_ROOT)/tools/config.h
 CFLAGS += $(CFLAGS_libxenevtchn)
-CFLAGS += $(CFLAGS_libxenctrl)
+CFLAGS += $(CFLAGS_libxenmanage)
 CFLAGS += $(CFLAGS_libxentoolcore)
 
 $(XENSTORED_OBJS-y): CFLAGS += $(CFLAGS_libxengnttab)
diff --git a/tools/xenstored/core.h b/tools/xenstored/core.h
index e58779e88c..632886cecf 100644
--- a/tools/xenstored/core.h
+++ b/tools/xenstored/core.h
@@ -19,7 +19,6 @@
 #ifndef _XENSTORED_CORE_H
 #define _XENSTORED_CORE_H
 
-#include <xenctrl.h>
 #include <xengnttab.h>
 
 #include <sys/types.h>
diff --git a/tools/xenstored/domain.c b/tools/xenstored/domain.c
index 64c8fd0cc3..a6506a5bb2 100644
--- a/tools/xenstored/domain.c
+++ b/tools/xenstored/domain.c
@@ -34,14 +34,15 @@
 #include "control.h"
 
 #include <xenevtchn.h>
-#include <xenctrl.h>
+#include <xenmanage.h>
+#include <xen-barrier.h>
 #include <xen/grant_table.h>
 
 #ifdef __MINIOS__
 #include <mini-os/xenbus.h>
 #endif
 
-static xc_interface **xc_handle;
+static xenmanage_handle *xm_handle;
 xengnttab_handle **xgt_handle;
 static evtchn_port_t virq_port;
 
@@ -619,32 +620,28 @@ static int destroy_domain(void *_domain)
 	return 0;
 }
 
-static bool get_domain_info(unsigned int domid, xc_domaininfo_t *dominfo)
-{
-	return xc_domain_getinfo_single(*xc_handle, domid, dominfo) == 0;
-}
-
 static int check_domain(const void *k, void *v, void *arg)
 {
-	xc_domaininfo_t dominfo;
+	unsigned int state;
 	struct connection *conn;
-	bool dom_valid;
+	int dom_invalid;
 	struct domain *domain = v;
 	bool *notify = arg;
 
-	dom_valid = get_domain_info(domain->domid, &dominfo);
+	dom_invalid = xenmanage_get_domain_info(xm_handle, domain->domid,
+						&state, NULL);
 	if (!domain->introduced) {
-		if (!dom_valid)
+		if (dom_invalid)
 			talloc_free(domain);
 		return 0;
 	}
-	if (dom_valid) {
-		if ((dominfo.flags & XEN_DOMINF_shutdown)
+	if (!dom_invalid) {
+		if ((state & XENMANAGE_GETDOMSTATE_STATE_SHUTDOWN)
 		    && !domain->shutdown) {
 			domain->shutdown = true;
 			*notify = true;
 		}
-		if (!(dominfo.flags & XEN_DOMINF_dying))
+		if (!(state & XENMANAGE_GETDOMSTATE_STATE_DEAD))
 			return 0;
 	}
 	if (domain->conn) {
@@ -786,10 +783,9 @@ static struct domain *find_or_alloc_domain(const void *ctx, unsigned int domid)
 static struct domain *find_or_alloc_existing_domain(unsigned int domid)
 {
 	struct domain *domain;
-	xc_domaininfo_t dominfo;
 
 	domain = find_domain_struct(domid);
-	if (!domain && get_domain_info(domid, &dominfo))
+	if (!domain && !xenmanage_get_domain_info(xm_handle, domid, NULL, NULL))
 		domain = alloc_domain(NULL, domid);
 
 	return domain;
@@ -1187,12 +1183,6 @@ int do_reset_watches(const void *ctx, struct connection *conn,
 	return 0;
 }
 
-static int close_xc_handle(void *_handle)
-{
-	xc_interface_close(*(xc_interface**)_handle);
-	return 0;
-}
-
 static int close_xgt_handle(void *_handle)
 {
 	xengnttab_close(*(xengnttab_handle **)_handle);
@@ -1258,15 +1248,9 @@ void domain_early_init(void)
 	if (!domhash)
 		barf_perror("Failed to allocate domain hashtable");
 
-	xc_handle = talloc(talloc_autofree_context(), xc_interface*);
-	if (!xc_handle)
-		barf_perror("Failed to allocate domain handle");
-
-	*xc_handle = xc_interface_open(0,0,0);
-	if (!*xc_handle)
-		barf_perror("Failed to open connection to hypervisor");
-
-	talloc_set_destructor(xc_handle, close_xc_handle);
+	xm_handle = xenmanage_open(NULL, 0);
+	if (!xm_handle)
+		barf_perror("Failed to open connection to libxenmanage");
 
 	xgt_handle = talloc(talloc_autofree_context(), xengnttab_handle*);
 	if (!xgt_handle)
@@ -1306,6 +1290,8 @@ void domain_deinit(void)
 {
 	if (virq_port)
 		xenevtchn_unbind(xce_handle, virq_port);
+
+	xenmanage_close(xm_handle);
 }
 
 /*
@@ -1335,13 +1321,13 @@ int domain_alloc_permrefs(struct node_perms *perms)
 {
 	unsigned int i, domid;
 	struct domain *d;
-	xc_domaininfo_t dominfo;
 
 	for (i = 0; i < perms->num; i++) {
 		domid = perms->p[i].id;
 		d = find_domain_struct(domid);
 		if (!d) {
-			if (!get_domain_info(domid, &dominfo))
+			if (xenmanage_get_domain_info(xm_handle, domid,
+						      NULL, NULL))
 				perms->p[i].perms |= XS_PERM_IGNORE;
 			else if (!alloc_domain(NULL, domid))
 				return ENOMEM;
diff --git a/tools/xenstored/lu.c b/tools/xenstored/lu.c
index bec2a84e10..4fccbbc195 100644
--- a/tools/xenstored/lu.c
+++ b/tools/xenstored/lu.c
@@ -11,6 +11,7 @@
 #include <stdlib.h>
 #include <syslog.h>
 #include <time.h>
+#include <unistd.h>
 #include <sys/mman.h>
 #include <sys/stat.h>
 
diff --git a/tools/xenstored/lu_daemon.c b/tools/xenstored/lu_daemon.c
index 6df6c80a2a..88d8d9e1b3 100644
--- a/tools/xenstored/lu_daemon.c
+++ b/tools/xenstored/lu_daemon.c
@@ -6,6 +6,7 @@
  */
 
 #include <syslog.h>
+#include <unistd.h>
 #include <sys/stat.h>
 
 #include "talloc.h"
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 07 11:12:12 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 11:12:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866318.1277637 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV7V5-0007bI-TL; Tue, 07 Jan 2025 11:11:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866318.1277637; Tue, 07 Jan 2025 11:11:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV7V5-0007bB-Ql; Tue, 07 Jan 2025 11:11:55 +0000
Received: by outflank-mailman (input) for mailman id 866318;
 Tue, 07 Jan 2025 11:11:55 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=1r68=T7=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tV7V5-0007b5-8S
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 11:11:55 +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 32f582bf-cce8-11ef-a0df-8be0dac302b0;
 Tue, 07 Jan 2025 12:11:53 +0100 (CET)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-4361b6f9faeso92797225e9.1
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 03:11:53 -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
 5b1f17b1804b1-43656b3b287sm625950055e9.29.2025.01.07.03.11.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 03:11:52 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 32f582bf-cce8-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736248313; x=1736853113; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=WKfkt7K3GVNB3ZmKMhiDK9vedKrL8wcC7HJN6PLmNRM=;
        b=L+vvYGrmrx/eaopAZD3THjonJK1dgzFd+BxSZruo0+l3PbnXr6s6x7iHjen95GBdln
         Dm7bvXcY27uveZclWetwx2c7Pr/nDqHiLeuo+0wyNGH/tHPW8IQV8wOJMORzEscGsl7R
         tzLhaAgRFER6kY35pYlgUbklnZLHDnOb0loiYoubnz4IxYC+0sWIM78iRIEIHk7eWz9g
         DHBQE6saFcj9KCsAHv3jC9Am+hRgAzulG1YPwpftbWJiYqqfg4+jRwx7dAuJ8FOaPgfQ
         QqXFObJ1kEI4DKkKzqo0D7spnPCAnFO137FCHyvvTHyNP67EbFf40l271zIFnUUjrAoa
         sAzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736248313; x=1736853113;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=WKfkt7K3GVNB3ZmKMhiDK9vedKrL8wcC7HJN6PLmNRM=;
        b=vCUVyvX+lCgqXRwGsdSQJ7DSlP9yvDgjd4EYot6Or0xoksLBABQqrFdX1rCQMg7xBy
         AgX74CS4NeTqYXJY9mXhlUZhrgI0Q8E/j+gv9fGKBQXDPXUzY1oLUvpPpRD8k0Lbs7yP
         eLfA/di/5/DbeIhDKVP2HSMjJE+rTbTBFOIrlvYmDtjCjKoDMnhUreBMDLNyMgk1dFXg
         E5ELNBRJf0Yb8X5Cte3YrE4d7AUi22yczZa7BWZLXihhDEgpcUcMM7hHjwdJkrGsPERX
         vgd5whhn/ZjM8eZmhAiKqngr06pgMGj+RHxXqbSmDkwI1ldHLrqRUS8GCCYNn5YzNW4E
         j94A==
X-Forwarded-Encrypted: i=1; AJvYcCXLrsFUZiDMfjTRlKZJY1hWRIvYvQp0Sb8BYAhCVjzkz9rIUvyqGQP5a63gXRvyqk4PIoaXhHgqPIE=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyat5RnwQoh49yLKKh/F8xjkDR7/FBS4FQNFahWZ17yBTk+/IIN
	HQEYHDIRFc0tbcoXkR6EJVvVXV3CyXHu96rf9VE1L/RKMRhIrVvpJPulHFz9Tw==
X-Gm-Gg: ASbGncsm+JkgCaWI/Chm/9DCg4NIImdd3PkTuwCVqpwh1S1PBWBOkF6s6VR1JmDKDAg
	eVL7dtGasQoEuKmlcq1CqR/tlmObp3quiWfRYDMw6oETKH26YSjrN+oBY6vtWbxy0tjRYXk0lhC
	nsbu0CVC457DdF6mig5ABiYDCU6SYPCxbNxsalD7vWZRLVEUyvp7606/zoB5gkApAOKnKCUlA59
	sCei7E3VGFwyZs3tLy6uqhQrDr7sGOBb9VA4fBuGv4Kdr/jHZEScvu/GYcrnM19ddtsnVyaJQ3F
	vWwT9PQpUB/Z3qjCTaaMWFyFOM982PVlU5eWJiTh9g==
X-Google-Smtp-Source: AGHT+IEET/S86xflurpVcA0lu0b0b6pL3Blgty53NzbKALsZabhhXpBkYHtvD4ndQCzBNqiws8X+xA==
X-Received: by 2002:a05:600c:492f:b0:434:ffb2:f9cf with SMTP id 5b1f17b1804b1-436dc23f2d2mr20785605e9.14.1736248312585;
        Tue, 07 Jan 2025 03:11:52 -0800 (PST)
Message-ID: <48d0ab30-2a7f-44b6-bcf9-3a5c0583692e@suse.com>
Date: Tue, 7 Jan 2025 12:11:51 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC] docs: FRED support in Xen
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20250103204704.84067-1-andrew.cooper3@citrix.com>
 <3ff59df0-69f8-426a-ab44-d2cd9b5bf8ea@suse.com>
 <0a780f2d-1e49-47bd-8c66-babbc2dd8f63@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <0a780f2d-1e49-47bd-8c66-babbc2dd8f63@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 06.01.2025 17:06, Andrew Cooper wrote:
> On 06/01/2025 2:28 pm, Jan Beulich wrote:
>> On 03.01.2025 21:47, Andrew Cooper wrote:
>>> +There are several uses of the vm86 fields in Xen:
>>> +
>>> + #. ``struct vcpu`` embeds a ``struct cpu_user_regs`` to hold GPRs/etc when
>>> +    the vCPU is scheduled out.  The vm86 fields are used by the PV logic only
>>> +    (``{save,load}_segments()``) and can be moved into separate fields in
>>> +    ``struct pv_vcpu``.  PV's ``dom0_construct()`` sets these fields directly,
>>> +    and needs a matching adjustment.
>>> +
>>> + #. As part of ``arch_{get,set}_info_guest()`` during hypercalls.  The
>>> +    guest side needs to remain as-is, but the Xen side can rearranged to use
>>> +    the new fields from above.
>>> +
>>> + #. As part of vCPU diagnostics (``show_registers()`` etc).  The ``#DF`` path
>>> +    uses the fields as scratch storage for the current register values, while
>>> +    the other diagnostics are simply accessing the state of a scheduled-out
>>> +    vCPU.
>> Unlike for the former 2 points and for the one immediately below, but like for
>> the final one below you don't mention what you intend to do. Here I assume it'll
>> be reasonably straightforward to use scratch space elsewhere.
> 
> https://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=shortlog;h=refs/heads/xen-fred
> is my working branch if you want to peek at things.
> 
> The diagnostics are handled by:
> 
> 1) "x86/traps: Rework register state printing to use an extra_state struct"
> 2) "x86/traps: Avoid OoB accesses to print the data selectors"

Doesn't this one remove the sole caller of read_sregs(), hence wanting to also
purge the function itself? Apart from this ...

> 3) "Revert "x86/traps: 'Fix' safety of read_registers() in #DF path""

... these all look fine to me; I'll wait with a formal R-b though until the
actual submission.

> Something else you might want to proactively look at.  "x86/idt:
> Generate bsp_idt[] at build time".  I figured out how to construct the
> IDT at build time, without using an external tool to format the table,
> and only some slightly disgusting linker script hackery.

Clever.

>>> +Stack layout
>>> +""""""""""""
>>> +
>>> +Xen's CPU stacks are 8-page (8-page aligned), arranged as::
>>> +
>>> +  7 - Primary stack (with a struct cpu_info at the top)
>>> +  6 - Primary stack
>>> +  5 - Primary Shadow Stack (read-only)
>>> +  4 - #DF IST stack
>>> +  3 - #DB IST stack
>>> +  2 - NMI IST stack
>>> +  1 - #MC IST stack
>>> +  0 - IST Shadow Stacks (4x 1k, read-only)
>>> +
>>> +which needs mapping into FREDs Stack Levels.
>>> +
>>> +FRED Stack Levels replace IST.  Most events from Ring3 enter Ring0 at SL0,
>>> +including interrupts, and even exceptions with a non-zero Stack Level
>>> +configured.  Nested exceptions originate from Ring0 even if they were trying
>>> +to push a Ring3 event frame onto the stack, so do follow the Ring0 CSL rules.
>>> +
>>> +Within Ring0, a stack switch occurs on event delivery if the event has a
>>> +higher configured Stack Level (exceptions in ``MSR_FRED_STK_LVLS``, interrupts
>>> +in ``MSR_FRED_CONFIG``).  Otherwise, the new event is delivered on the current
>>> +stack.
>>> +
>>> +Under FRED, most sources of ``#DF`` are gone; failure to push a new event
>>> +frame onto a stack is the main remaining one, so ``#DF`` needs to be the
>>> +highest stack level (SL3) to catch errors at all other stack levels.
>>> +
>>> +Also, FRED removes the "syscall gap", removing the primary need for ``NMI``,
>>> +``#DB`` and ``#MC`` to need separate stacks.
>>> +
>>> +Therefore, Xen has no need for SL1 or SL2.  Under IDT delivery, we poison the
>>> +unused stack pointers with a non-canonical address, but we cannot do that
>>> +under FRED; they're held in MSRs and checked at WRMSR time.  Instead, we can
>>> +point the SL pairs (RSP + SSP) at each others (regular and shadow stack) guard
>>> +pages such that any use of an unused SL will escalate to ``#DF``.
>> I may have a language issue here: "each others" reads wrong to me; do you perhaps
>> mean "each ones"?
> 
> It's poor grammar, but not wrong per say.  I'll try to find a different
> way to phrase it.
> 
>>
>> Further, mainly to double check my own understanding: Almost half of the stack
>> area then isn't used anymore when FRED is active: 2 pages for the primary stack,
>> 1 page for the primary shadow stack, 1 page for the SL3 stack, and (somewhat
>> wastefully) 1 more for the SL3 shadow stack.
> 
> This matches my understanding (on the proviso that I've still not wired
> up the stack handling yet.  Still cleaning up the initialisation paths.)
> 
>>  There'll be 3 unused pages, and
>> hence space again to have true guard pages, e.g.
>>
>>   7 - Primary stack (with a struct cpu_info at the top)
>>   6 - Primary stack
>>   5 - Guard page
>>   4 - Primary Shadow Stack (read-only)
>>   3 - Guard page
>>   2 - #DF stack
>>   1 - #DF Shadow Stack (read-only)
>>   0 - Guard page
> 
> Shadow stack frames are perfectly good guard pages for regular stacks,
> and vice versa.  That's why I set them up as shadow stack pages even
> when CET isn't active.

"Perfectly valid" isn't quite true: These pages being readable means
writes below the stack bottom (likely the prevailing kind of problem)
are detected, but reads wouldn't be.

> And yes, we could rearrange the stack.  But, there's also a good reason
> not to.  Our code has to cope with both IDT and FRED layouts, which is
> much easier if they're the same.

I certainly can see the value of keeping stack layout uniform.

>> Having reached the bottom of the section, there's one special IST aspect that
>> I'm missing, special enough imo to warrant mentioning even if only to state that
>> it's (hopefully) going to be irrelevant (i.e. not require replacing by another
>> similar hack): {dis,en}able_each_ist() as used by SVM (on the assumption that
>> sooner or later AMD is likely to also implement FRED, and that you may already
>> know of details of their respective VMCB integration).
> 
> AMD haven't said anything about FRED yet, despite a very large number of
> software partners asking about it.
> 
> However, If AMD were to do FRED, I'd expect it to work just like CET
> does today, seeing as there's a proper host/guest split of CR4, and
> everything else is in MSRs the guest can't touch.

As in "can be prevented to touch directly", aiui.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 13:09:43 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 13:09:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866365.1277679 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV9Ky-0004lK-Mm; Tue, 07 Jan 2025 13:09:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866365.1277679; Tue, 07 Jan 2025 13:09:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tV9Ky-0004lD-KE; Tue, 07 Jan 2025 13:09:36 +0000
Received: by outflank-mailman (input) for mailman id 866365;
 Tue, 07 Jan 2025 13:09:35 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=YqN9=T7=eik.bme.hu=balaton@srs-se1.protection.inumbo.net>)
 id 1tV9Kx-0004l5-DR
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 13:09:35 +0000
Received: from zero.eik.bme.hu (zero.eik.bme.hu [152.66.115.2])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a2f1a9ae-ccf8-11ef-99a4-01e77a169b0f;
 Tue, 07 Jan 2025 14:09:33 +0100 (CET)
Received: from zero.eik.bme.hu (localhost [127.0.0.1])
 by zero.eik.bme.hu (Postfix) with ESMTP id 5741C4E6000;
 Tue, 07 Jan 2025 14:09:32 +0100 (CET)
Received: from zero.eik.bme.hu ([127.0.0.1])
 by zero.eik.bme.hu (zero.eik.bme.hu [127.0.0.1]) (amavisd-new, port 10028)
 with ESMTP id U0rxOlpL8Io9; Tue,  7 Jan 2025 14:09:30 +0100 (CET)
Received: by zero.eik.bme.hu (Postfix, from userid 432)
 id 62FA44E6010; Tue, 07 Jan 2025 14:09:30 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
 by zero.eik.bme.hu (Postfix) with ESMTP id 60242746F60;
 Tue, 07 Jan 2025 14:09:30 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a2f1a9ae-ccf8-11ef-99a4-01e77a169b0f
X-Virus-Scanned: amavisd-new at eik.bme.hu
Date: Tue, 7 Jan 2025 14:09:30 +0100 (CET)
From: BALATON Zoltan <balaton@eik.bme.hu>
To: =?ISO-8859-15?Q?Philippe_Mathieu-Daud=E9?= <philmd@linaro.org>
cc: Daniel Henrique Barboza <dbarboza@ventanamicro.com>, qemu-devel@nongnu.org, 
    =?ISO-8859-15?Q?Fr=E9d=E9ric_Barrat?= <fbarrat@linux.ibm.com>, 
    Stefano Stabellini <sstabellini@kernel.org>, 
    Ilya Leoshkevich <iii@linux.ibm.com>, Cameron Esfahani <dirty@apple.com>, 
    Paolo Bonzini <pbonzini@redhat.com>, kvm@vger.kernel.org, 
    Alexander Graf <agraf@csgraf.de>, Paul Durrant <paul@xen.org>, 
    David Hildenbrand <david@redhat.com>, Halil Pasic <pasic@linux.ibm.com>, 
    Marcel Apfelbaum <marcel.apfelbaum@gmail.com>, 
    xen-devel@lists.xenproject.org, qemu-arm@nongnu.org, 
    =?ISO-8859-15?Q?C=E9dric_Le_Goater?= <clg@redhat.com>, 
    Yanan Wang <wangyanan55@huawei.com>, Reinoud Zandijk <reinoud@netbsd.org>, 
    Peter Maydell <peter.maydell@linaro.org>, qemu-s390x@nongnu.org, 
    Riku Voipio <riku.voipio@iki.fi>, Anthony PERARD <anthony@xenproject.org>, 
    Alistair Francis <alistair.francis@wdc.com>, 
    Sunil Muthuswamy <sunilmut@microsoft.com>, 
    Christian Borntraeger <borntraeger@linux.ibm.com>, 
    Nicholas Piggin <npiggin@gmail.com>, 
    Richard Henderson <richard.henderson@linaro.org>, 
    Marcelo Tosatti <mtosatti@redhat.com>, Thomas Huth <thuth@redhat.com>, 
    Roman Bolshakov <rbolshakov@ddn.com>, 
    "Edgar E . Iglesias" <edgar.iglesias@amd.com>, 
    Zhao Liu <zhao1.liu@intel.com>, Phil Dennis-Jordan <phil@philjordan.eu>, 
    David Woodhouse <dwmw2@infradead.org>, 
    Harsh Prateek Bora <harshpb@linux.ibm.com>, 
    Nina Schoetterl-Glausch <nsg@linux.ibm.com>, 
    "Edgar E. Iglesias" <edgar.iglesias@gmail.com>, 
    Eduardo Habkost <eduardo@habkost.net>, qemu-ppc@nongnu.org, 
    Daniel Henrique Barboza <danielhb413@gmail.com>, 
    "Michael S. Tsirkin" <mst@redhat.com>, Anton Johansson <anjo@rev.ng>
Subject: Re: [RFC PATCH 6/7] accel/hvf: Use CPU_FOREACH_HVF()
In-Reply-To: <6df59c2c-e29d-4b86-8908-4cb9093bad13@linaro.org>
Message-ID: <4abe9825-ff86-5e7d-1170-3677d5494879@eik.bme.hu>
References: <20250106200258.37008-1-philmd@linaro.org> <20250106200258.37008-7-philmd@linaro.org> <bd8168fe-c774-4f75-8a94-1a67ec31e38d@ventanamicro.com> <6df59c2c-e29d-4b86-8908-4cb9093bad13@linaro.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="3866299591-1325344726-1736255370=:80373"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--3866299591-1325344726-1736255370=:80373
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT

On Mon, 6 Jan 2025, Philippe Mathieu-Daudé wrote:
> On 6/1/25 21:33, Daniel Henrique Barboza wrote:
>> 
>> 
>> On 1/6/25 5:02 PM, Philippe Mathieu-Daudé wrote:
>>> Only iterate over HVF vCPUs when running HVF specific code.
>>> 
>>> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
>>> ---
>>>   include/system/hvf_int.h  | 4 ++++
>>>   accel/hvf/hvf-accel-ops.c | 9 +++++----
>>>   target/arm/hvf/hvf.c      | 4 ++--
>>>   3 files changed, 11 insertions(+), 6 deletions(-)
>>> 
>>> diff --git a/include/system/hvf_int.h b/include/system/hvf_int.h
>>> index 42ae18433f0..3cf64faabd1 100644
>>> --- a/include/system/hvf_int.h
>>> +++ b/include/system/hvf_int.h
>>> @@ -11,6 +11,8 @@
>>>   #ifndef HVF_INT_H
>>>   #define HVF_INT_H
>>> +#include "system/hw_accel.h"
>>> +
>>>   #ifdef __aarch64__
>>>   #include <Hypervisor/Hypervisor.h>
>>>   typedef hv_vcpu_t hvf_vcpuid;
>>> @@ -74,4 +76,6 @@ int hvf_put_registers(CPUState *);
>>>   int hvf_get_registers(CPUState *);
>>>   void hvf_kick_vcpu_thread(CPUState *cpu);
>>> +#define CPU_FOREACH_HVF(cpu) CPU_FOREACH_HWACCEL(cpu)
>> 
>> 
>> Cosmetic comment: given that this is HVF specific code and we only support 
>> one hw
>> accelerator at a time, I'd skip this alias and use CPU_FOREACH_HWACCEL(cpu) 
>> directly.
>> It would make it easier when grepping to see where and how the macro is 
>> being used.
>
> I find it more useful to grep for a particular accelerator, or for
> all of them:
>
> $ git grep CPU_FOREACH_
> accel/hvf/hvf-accel-ops.c:507:    CPU_FOREACH_HVF(cpu) {
> accel/hvf/hvf-accel-ops.c:546:    CPU_FOREACH_HVF(cpu) {
> accel/kvm/kvm-all.c:875:        CPU_FOREACH_KVM(cpu) {
> accel/kvm/kvm-all.c:938:    CPU_FOREACH_KVM(cpu) {
> accel/tcg/cputlb.c:372:    CPU_FOREACH_TCG(cpu) {
> accel/tcg/cputlb.c:650:        CPU_FOREACH_TCG(dst_cpu) {

But then you need to define a new macro for every new accelerator. Maybe 
it's simpler to have CPU_FOREACH take the queue as a parameter so no 
separate macro is needed for each accel (and they cannot get inconsistent 
by changing only one of them in the future).

Regards,
BALATON Zoltan
--3866299591-1325344726-1736255370=:80373--


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 14:33:10 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 14:33:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866385.1277706 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVAdZ-00072l-IL; Tue, 07 Jan 2025 14:32:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866385.1277706; Tue, 07 Jan 2025 14:32:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVAdZ-00072e-Ff; Tue, 07 Jan 2025 14:32:53 +0000
Received: by outflank-mailman (input) for mailman id 866385;
 Tue, 07 Jan 2025 14:32:52 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=1r68=T7=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVAdY-00072Y-Ie
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 14:32:52 +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 4591ee87-cd04-11ef-99a4-01e77a169b0f;
 Tue, 07 Jan 2025 15:32:50 +0100 (CET)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-436202dd730so111866715e9.2
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 06:32: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
 5b1f17b1804b1-4366120086bsm602497295e9.12.2025.01.07.06.32.49
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 06:32:49 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 4591ee87-cd04-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736260370; x=1736865170; 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=GT+lzfOAjENvEXRJX8o+xq6/VUxk96oSIK5ugLpkuXM=;
        b=GXz9W17niVHy6fcXPewWU/K3x76oaqf9rHxO8pwzE74cIr9Dd5yJUu9VLUHIz6/JrG
         WwZGMcDczOz3x/dlmwHwSEDcIS5v0M1KXilCIV6F5L+ZI0h+qsDYs4RYFPFsi48b5VkU
         0hm5NxvLv0EDx/b0z+T6DXleg7KSBVxGlaJGP4yrmcTNUTyADTpeICm99P9sMPg1vNqZ
         UMJ4AfGxRga/sciUhwoCKtg9GWneVqXehSrSfFITU60fIxZQrbk2PkA765tXgB439sPL
         PrLySt0gTK1INX3ftG5+p0Z/OR7niabUd9sRgJyGHUNmdOLTM3avmfk25D5QJRUZ5rmz
         nVIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736260370; x=1736865170;
        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=GT+lzfOAjENvEXRJX8o+xq6/VUxk96oSIK5ugLpkuXM=;
        b=LameFwfWrrjwvGCcTn8/xa92B+y4kRSvWzRMyGXQU2KRgoOu8pqX6CmE72Lqsej7FE
         4afoE07+8dNUmC5qDCuHPY6YB4awIOx51b9cfBJXsivFa8T8lTDUZFHAAP8nmCyfRxra
         Ap+cHyEVqvllO3p61iaOzLL6hIqym+nfy3EUevBHjCfvSbczvblPpV9x2tn8NaaSyTos
         T4LTuuBFWyYNm4V7e9LAe82iRQ51d6x48H2UWR2E0m05YfTqEOxgzhe1/CNijY77kU6S
         jMFNAq+2CgbVsJOydPv5xqG6l5lAvYT0W8wDcinvxbzgt6M+Ks88qBIeV0QMPGeOkKVL
         Tqjw==
X-Gm-Message-State: AOJu0Yy/dN4XfVDZ+A4mkU6COHQMiV2+LCKds7gqCk3fABk9eOkEAn/L
	zluLbeEDMkSe5MoVMUyIEXhfXVT4qZBQipnCWaa0wGrsrx9a5vtwMSZ1iQXvs8gy59mi6ZZvW94
	=
X-Gm-Gg: ASbGncuYAryaif77j7tc1Bd3zXz5R1qMqFLWvTSqKQ3rtbNCkPQDJMrDhJTD+rvweuc
	2iYGayfL6dtm5or7eBo8sMG9qL3pxuN3sWq2JlVxlVOVHOJ15q1P3hWYgmE/BkZ1QIXzD9gmj1Y
	Y8iVX3rz3Y8rGAQkZv6CylQPsiY6YilEZU0zAN5Xfs8wC1JyEhaoQ1xiefLsiDszrzOLi/Flw0r
	5yBAE3n6xkSmptGpIEZcQPl9wH7Sanhq25zVyS3fUNOhuq4JPTcRESi3PtANwxy9E3WxCAsXmik
	ZIigoyHsZwbF5/zz80dpeVCr9jY68fJksH3Yqc1Jog==
X-Google-Smtp-Source: AGHT+IEnFbK96+DBJ+avk9/L+HEcS6XEfPhIeOVcy7z/ev/0RKrv2mE3jMnHQoxj/awnF+LCnSiKbQ==
X-Received: by 2002:a05:600c:4710:b0:434:9e1d:7626 with SMTP id 5b1f17b1804b1-43668b5dff4mr463949495e9.25.1736260369748;
        Tue, 07 Jan 2025 06:32:49 -0800 (PST)
Message-ID: <238beefd-126a-4a2d-99de-dc5675c88ef6@suse.com>
Date: Tue, 7 Jan 2025 15:32:48 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH] x86emul: VCVT{,U}DQ2PD ignores embedded rounding
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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

IOW we shouldn't raise #UD in that case. Be on the safe side though and
only encode fully legitimate forms into the stub to be executed.

Things weren't quite right for VCVT{,U}SI2SD either, in the attempt to
be on the safe side: Clearing EVEX.L'L isn't useful; it's EVEX.b which
primarily needs clearing. Also reflect the somewhat improved doc
situation in the comment there.

Fixes: ed806f373730 ("x86emul: support AVX512F legacy-equivalent packed int/FP conversion insns")
Fixes: baf4a376f550 ("x86emul: support AVX512F legacy-equivalent scalar int/FP conversion insns")
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -3596,12 +3596,15 @@ x86_emulate(
         if ( !mode_64bit() )
             evex.w = 0;
         /*
-         * SDM version 067 claims that exception type E10NF implies #UD when
-         * EVEX.L'L is non-zero for 32-bit VCVT{,U}SI2SD. Experimentally this
-         * cannot be confirmed, but be on the safe side for the stub.
+         * While SDM version 085 has explicit wording towards embedded rounding
+         * being ignored, it's still not entirely unambiguous with the exception
+         * type referred to. Be on the safe side for the stub.
          */
         if ( !evex.w && evex.pfx == vex_f2 )
+        {
+            evex.brs = 0;
             evex.lr = 0;
+        }
         opc[1] = (modrm & 0x38) | 0xc0;
         insn_bytes = EVEX_PFX_BYTES + 2;
         opc[2] = 0xc3;
@@ -4819,7 +4822,16 @@ x86_emulate(
         else
         {
             host_and_vcpu_must_have(avx512f);
-            generate_exception_if(ea.type != OP_MEM && evex.brs, X86_EXC_UD);
+            /*
+             * While SDM version 085 has explicit wording towards embedded
+             * rounding being ignored, it's still not entirely unambiguous with
+             * the exception type referred to. Be on the safe side for the stub.
+             */
+            if ( ea.type != OP_MEM && evex.brs )
+            {
+                evex.brs = 0;
+                evex.lr = 2;
+            }
         }
         if ( ea.type != OP_REG || !evex.brs )
             avx512_vlen_check(false);


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 14:33:47 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 14:33:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866390.1277715 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVAeR-0007Ui-R1; Tue, 07 Jan 2025 14:33:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866390.1277715; Tue, 07 Jan 2025 14:33:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVAeR-0007Ub-O9; Tue, 07 Jan 2025 14:33:47 +0000
Received: by outflank-mailman (input) for mailman id 866390;
 Tue, 07 Jan 2025 14:33: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 <SRS0=1r68=T7=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVAeQ-0007Ry-Ta
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 14:33:46 +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 66c4d068-cd04-11ef-a0df-8be0dac302b0;
 Tue, 07 Jan 2025 15:33:46 +0100 (CET)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-436202dd730so111878555e9.2
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 06:33: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
 5b1f17b1804b1-4366127c639sm593718505e9.31.2025.01.07.06.33.44
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 06:33:45 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 66c4d068-cd04-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736260425; x=1736865225; 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=Ut97ADWYFWCwK59oH2ymgDLqpDldkiEh2jNuUZ/O1nc=;
        b=cn+nBphlgQ3yf0JN2yLYaRcdXUcL3UsdYNz2YHpucJOUGRwDNMmSYLh0NvYg2xDHxV
         F6SRRzo3t/2ZNJMrRwxT2ASZJqodaC3B5HofN/nrgbRQTIWMbNKT1fO4gcvVFU9xxDWe
         buAiC9GSQxTgs5UpCKlpI+s9F3/6O3o+8VqKsjpPnTmYOUCkRsoYdRyHqzQjGFyGdcnI
         qOzh7Do44qfHbR2fvDK+kJTuiB3ViMpUxpKhdS71ZnY/sykkQ7jo1egjzar+PyHCZGU7
         0NKiqh/S2j8hlNF18bSU0gacOh2MnSJ+RdQ6QMF1qmW5nU4gkCCLoDyymOM64TAtgl/N
         2BDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736260425; x=1736865225;
        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=Ut97ADWYFWCwK59oH2ymgDLqpDldkiEh2jNuUZ/O1nc=;
        b=SpFHWzavtP5FjBhuRE9/bX0JWRazVzt5MMAqkxZVD3KwTpsaAusHVvC+steFaFno2T
         lsgMswXzhEc/aXd70QXRXB4KKdwYJ6gNUdaA0QqKBZH/bD3zbMeRQi/Vc7/bskzoaJ3n
         IP8+AXgS9iipL4gDoRHjhvcYURlkawjCBLkNXETzVlFBn2ynESE1SpaOtSAhs1mOhfZy
         lT9zr/0JL2vSjzNhaHK7gABTMU33E3L/mXmuIyHTDDmmQlu3ECPADx2KRnyirWO5baFC
         Rdufky1MctlDWP8vJMpWumCRyQcajjM3QmMrOyaVeFAHUlBcCqn/43WP1T081umxi0hd
         HFLg==
X-Gm-Message-State: AOJu0YwvyKPmjwLEyz8YpU7r7sLSecoDGLdc+1+MXLD4ufj+gEFEI/qj
	uR6lD1/LGtGsSnw9PPV3BRJoktTdYoXtEeQ+tXv8/qf2JorK5tLvD3xAtNL+NVHlf43IG6K/2k0
	=
X-Gm-Gg: ASbGnctBcO5PZxGCsVr5BGRDr9X+tSNwdcZqqWAr/DmyhbhvP9C9Q7O0lgvsMT1S+FP
	UKSYH4gCpzTOjZ3QQSFpAtg1L5tHLAL8GTlie7iNsnho/kggS43XTVwyfR/gZ03Tnl69RuXTW9w
	4+8fVXybANA+WOe6Gd1jeNtPcA/znY47wLnDZChKRWMZjbUL9Gs0pqAJaoSX9JPUHA+UuoikviB
	U8YwTXgZlB3skw2dqmJNZ3dKXWt7V5WrTtz/o03Up8CkNgGACKzDcpZqfOn+u3jLQ5iJrlD044t
	npaFmIUstKKfSi1Eq84HkkRnBbNj+S5d2DAccs5nNA==
X-Google-Smtp-Source: AGHT+IHUGgVWH2JAP0p+TPewdO8msvVuiF2XBJbv51PW3qMIwCDyUd4zvIgVbo5xqFs2uXA/8TuMPA==
X-Received: by 2002:a05:600c:1c21:b0:436:aaf:7eb9 with SMTP id 5b1f17b1804b1-43668b5dfcbmr456590825e9.20.1736260425520;
        Tue, 07 Jan 2025 06:33:45 -0800 (PST)
Message-ID: <81428267-e963-4403-989d-d96fb0b59ffc@suse.com>
Date: Tue, 7 Jan 2025 15:33:44 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH] x86emul: correct put_fpu()'s segment selector handling
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

All selector fields under ctxt->regs are (normally) poisoned in the HVM
case, and the four ones besides CS and SS are potentially stale for PV.
Avoid using them in the hypervisor incarnation of the emulator, when
trying to cover for a missing ->read_segment() hook.

To make sure there's always a valid ->read_segment() handler for all HVM
cases, add a respective function to shadow code, even if it is not
expected for FPU insns to be used to update page tables.

Fixes: 0711b59b858a ("x86emul: correct FPU code/data pointers and opcode handling")
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
The code comment may want adjusting in the course of FRED work.

--- a/xen/arch/x86/mm/shadow/hvm.c
+++ b/xen/arch/x86/mm/shadow/hvm.c
@@ -287,11 +287,29 @@ hvm_emulate_cmpxchg(enum x86_segment seg
     return rc;
 }
 
+static int cf_check
+hvm_emulate_read_segment(enum x86_segment seg,
+                         struct segment_register *reg,
+                         struct x86_emulate_ctxt *ctxt)
+{
+    struct sh_emulate_ctxt *sh_ctxt =
+        container_of(ctxt, struct sh_emulate_ctxt, ctxt);
+    const struct segment_register *sreg = hvm_get_seg_reg(seg, sh_ctxt);
+
+    if ( IS_ERR(sreg) )
+        return -PTR_ERR(sreg);
+
+    *reg = *sreg;
+
+    return X86EMUL_OKAY;
+}
+
 static const struct x86_emulate_ops hvm_shadow_emulator_ops = {
     .read       = hvm_emulate_read,
     .insn_fetch = hvm_emulate_insn_fetch,
     .write      = hvm_emulate_write,
     .cmpxchg    = hvm_emulate_cmpxchg,
+    .read_segment = hvm_emulate_read_segment,
 };
 
 const struct x86_emulate_ops *shadow_init_emulation(
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -447,14 +447,37 @@ static void put_fpu(
         if ( state->ea.type == OP_MEM )
         {
             aux.dp = state->ea.mem.off;
-            if ( ops->read_segment &&
-                 ops->read_segment(state->ea.mem.seg, &sreg,
-                                   ctxt) == X86EMUL_OKAY )
+            if ( state->ea.mem.seg == x86_seg_cs )
+                aux.ds = aux.cs;
+            else if ( ops->read_segment &&
+                      ops->read_segment(state->ea.mem.seg, &sreg,
+                                        ctxt) == X86EMUL_OKAY )
                 aux.ds = sreg.sel;
+#ifdef __XEN__
+            /*
+             * While generally the expectation is that input structures are
+             * fully populated, the selector fields under ctxt->regs normally
+             * aren't set, with the exception of CS and SS for PV domains.
+             * Read the real selector registers for PV, and assert that HVM
+             * invocations always set a properly functioning ->read_segment()
+             * hook.
+             */
+            else if ( is_pv_vcpu(current) )
+                switch ( state->ea.mem.seg )
+                {
+                case x86_seg_ds: aux.ds = read_sreg(ds);  break;
+                case x86_seg_es: aux.ds = read_sreg(es);  break;
+                case x86_seg_fs: aux.ds = read_sreg(fs);  break;
+                case x86_seg_gs: aux.ds = read_sreg(gs);  break;
+                case x86_seg_ss: aux.ds = ctxt->regs->ss; break;
+                default:         ASSERT_UNREACHABLE();    break;
+                }
+            else
+                ASSERT_UNREACHABLE();
+#else
             else
                 switch ( state->ea.mem.seg )
                 {
-                case x86_seg_cs: aux.ds = ctxt->regs->cs; break;
                 case x86_seg_ds: aux.ds = ctxt->regs->ds; break;
                 case x86_seg_es: aux.ds = ctxt->regs->es; break;
                 case x86_seg_fs: aux.ds = ctxt->regs->fs; break;
@@ -462,6 +485,7 @@ static void put_fpu(
                 case x86_seg_ss: aux.ds = ctxt->regs->ss; break;
                 default:         ASSERT_UNREACHABLE();    break;
                 }
+#endif
             aux.dval = true;
         }
         ops->put_fpu(ctxt, X86EMUL_FPU_none, &aux);


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 14:39:01 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 14:39:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866399.1277726 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVAjR-0008BP-Ep; Tue, 07 Jan 2025 14:38:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866399.1277726; Tue, 07 Jan 2025 14:38:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVAjR-0008BI-Au; Tue, 07 Jan 2025 14:38:57 +0000
Received: by outflank-mailman (input) for mailman id 866399;
 Tue, 07 Jan 2025 14:38:55 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=X79W=T7=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tVAjP-0008BB-CF
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 14:38:55 +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 1e651ab7-cd05-11ef-a0df-8be0dac302b0;
 Tue, 07 Jan 2025 15:38:54 +0100 (CET)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-5d3e9f60bf4so27994310a12.3
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 06:38:54 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d80679eeb1sm24379347a12.48.2025.01.07.06.38.52
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 07 Jan 2025 06:38:53 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1e651ab7-cd05-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736260733; x=1736865533; 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=+o5mFEbXgTgp0YRTW2/X+6Yd+zqJ5lqW6dKl4ry4elw=;
        b=bNVi8WzTYArc0ZRWCFGe2zGkg2Obr/8x7y4aZHjg0IJXtbQxhsojoPAweDXJoq5XwC
         0vti8rhcRVme0p+T3PITwhpuQE4nPGHOwJGY7F5ixp+aoDZLH7PuDl1gSXnXF7QtO5LR
         rABkfgkxFGvmd7Jg7JkaMi1/q0U2eoo+BZPV8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736260733; x=1736865533;
        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=+o5mFEbXgTgp0YRTW2/X+6Yd+zqJ5lqW6dKl4ry4elw=;
        b=j7YYV92xLo9Mhtt9LgI72WSB2aywpPXHvxDn/pICnybtRo5Dlz7Hu9bNJbgslMG4RG
         lWboVDhGnH7xglUWUXhooKUy6AMRf5txR6n2qiP2OlK0ezMuQlrPv0ZWPPWHhSObAqMY
         ghLWiLMizAOarD0Q8fpzSK6jTlDOWR2uWRph+inL6eBNzwNnf87HwocsO7PV+6eo3W5m
         IYhgmLpkaDSSPORJdglkQ7HSIATpauhl+hOBF5PAOKrJEs1y8mx5ezATurYIdZarrXUT
         qq6NNx/VRsix8Zj6aQ6jsB2RJWA0kbuAI3/TC0CyS3izlLZYpnHe4Y1aOe4oeI/lxygc
         Umzg==
X-Forwarded-Encrypted: i=1; AJvYcCWpJsKVwqwclsu65f0XZ1IAFFaJs9y4Nw2zWVSJ8pnV0FcZE8+a2V1CCSAi9yHtXVCfll2R6y6UcJA=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy6AyhI8CqF0napqA6jJa/2cxDNkWiWgaC4HtvETOq5Kj1lOoYp
	EKIt/yEMTNfC41VLnoSMwcaal8qbO0Qrkpc8bTBFaCemGJl/SxBKQfczzj9N5iM=
X-Gm-Gg: ASbGnctMur9DiC5ttBtwGy8hbHHliTN28vK7A3Y44jNeCP4Kdf0Jc4xAD9lsuV4+heG
	T4S6Mx9orJIcWRF2IIvAS96zXNgg+oHs7RR9CIDzYwWPszay/l/TW55ui7Ja9jvmINDno7pMBkm
	o/FsnNFFSq8jGfc5XwjddhptdgjN5U4J0H36auSP3vpPrVAkVBKoZPsHprPbqzUXL4ia3XB6y5U
	kbj5G8dsZI/XYBdUJK3USyes+sF0KcUPDt3WuK/CwulC+xAkXZtBdVpXdjkAQ==
X-Google-Smtp-Source: AGHT+IG+OB/MxNlHSNWxhU6mujwMsOQvexSmrvEEcoS2e0kXFtQuWbpA2J3fpvz6u15HDPAJRU+72A==
X-Received: by 2002:a50:cc04:0:b0:5d8:a46f:110b with SMTP id 4fb4d7f45d1cf-5d8a46f1123mr31452716a12.17.1736260733499;
        Tue, 07 Jan 2025 06:38:53 -0800 (PST)
Date: Tue, 7 Jan 2025 15:38:52 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Jiqian Chen <Jiqian.Chen@amd.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Huang Rui <ray.huang@amd.com>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v4] vpci: Add resizable bar support
Message-ID: <Z308fGa1daaM62Rf@macbook.local>
References: <20241219052143.3161332-1-Jiqian.Chen@amd.com>
 <d904c816-da83-418a-9bff-9988660af546@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <d904c816-da83-418a-9bff-9988660af546@suse.com>

On Tue, Jan 07, 2025 at 11:06:33AM +0100, Jan Beulich wrote:
> On 19.12.2024 06:21, Jiqian Chen wrote:
> > --- /dev/null
> > +++ b/xen/drivers/vpci/rebar.c
> > @@ -0,0 +1,131 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +/*
> > + * Copyright (C) 2024 Advanced Micro Devices, Inc. All Rights Reserved.
> > + *
> > + * Author: Jiqian Chen <Jiqian.Chen@amd.com>
> > + */
> > +
> > +#include <xen/sched.h>
> > +#include <xen/vpci.h>
> > +
> > +static void cf_check rebar_ctrl_write(const struct pci_dev *pdev,
> > +                                      unsigned int reg,
> > +                                      uint32_t val,
> > +                                      void *data)
> > +{
> > +    struct vpci_bar *bar = data;
> > +    uint64_t size = PCI_REBAR_CTRL_SIZE(val);
> > +
> > +    if ( bar->enabled )
> > +    {
> > +        /*
> > +         * Refuse to resize a BAR while memory decoding is enabled, as
> > +         * otherwise the size of the mapped region in the p2m would become
> > +         * stale with the newly set BAR size, and the position of the BAR
> > +         * would be reset to undefined.  Note the PCIe specification also
> > +         * forbids resizing a BAR with memory decoding enabled.
> > +         */
> > +        if ( size != bar->size )
> > +            gprintk(XENLOG_ERR,
> > +                    "%pp: refuse to resize BAR with memory decoding enabled\n",
> > +                    &pdev->sbdf);
> > +        return;
> > +    }
> > +
> > +    if ( !((size >> PCI_REBAR_SIZE_BIAS) & bar->resizable_sizes) )
> > +        gprintk(XENLOG_WARNING,
> > +                "%pp: new size %#lx is not supported by hardware\n",
> > +                &pdev->sbdf, size);
> > +
> > +    bar->size = size;
> 
> Shouldn't at least this be in an "else" to the if() above?

I think this was already raised in a previous version - would be good
to know how real hardware behaves when an invalid size is set.  Is the
BAR register still reset?

> > +    bar->addr = 0;
> 
> For maximum compatibility with the behavior on bare metal, would we
> perhaps better ...
> 
> > +    bar->guest_addr = 0;
> > +    pci_conf_write32(pdev->sbdf, reg, val);
> 
> ... re-read the BAR from hardware after this write?
> 
> Similar consideration may apply to ->guest_addr: Driver writers knowing
> how their hardware behaves may expect that merely some of the bits of
> the address get cleared (if the size increases).

Since we only plan to enable the capability for the hardware domain,
and in that case addr == guest_addr always, it's fine to just read
from the BAR register and update the fields.  If we do this we might
as well check that the newly reported BAR size matches what Xen
expects on debug builds at least.

> > +static int cf_check init_rebar(struct pci_dev *pdev)
> > +{
> > +    uint32_t ctrl;
> > +    unsigned int nbars;
> > +    unsigned int rebar_offset = pci_find_ext_capability(pdev->sbdf,
> > +                                                        PCI_EXT_CAP_ID_REBAR);
> > +
> > +    if ( !rebar_offset )
> > +        return 0;
> > +
> > +    if ( !is_hardware_domain(pdev->domain) )
> > +    {
> > +        printk(XENLOG_ERR "%pp: resizable BARs unsupported for unpriv %pd\n",
> > +               &pdev->sbdf, pdev->domain);
> > +        return -EOPNOTSUPP;
> > +    }
> > +
> > +    ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL(0));
> > +    nbars = MASK_EXTR(ctrl, PCI_REBAR_CTRL_NBAR_MASK);
> > +
> > +    for ( unsigned int i = 0; i < nbars; i++ )
> > +    {
> > +        int rc;
> > +        struct vpci_bar *bar;
> > +        unsigned int index;
> > +
> > +        ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL(i));
> > +        index = ctrl & PCI_REBAR_CTRL_BAR_IDX;;
> 
> Nit: No double semicolons please.
> 
> > +        if ( index >= PCI_HEADER_NORMAL_NR_BARS )
> > +        {
> > +            /*
> > +             * TODO: for failed pathes, need to hide ReBar capability
> > +             * from hardware domain instead of returning an error.
> > +             */
> > +            printk(XENLOG_ERR "%pd %pp: too big BAR number %u in REBAR_CTRL\n",
> > +                   pdev->domain, &pdev->sbdf, index);
> > +            return -EINVAL;
> 
> With the TODO unaddressed, is it actually appropriate to return an error
> here? Shouldn't we continue in a best effort manner? (Question also to
> Roger as the maintainer.)

It would indeed be better to shallow the error and return 0, however
the handlers added in this loop would need removing if no error is
returned.

> > +        }
> > +
> > +        bar = &pdev->vpci->header.bars[index];
> > +        if ( bar->type != VPCI_BAR_MEM64_LO && bar->type != VPCI_BAR_MEM32 )
> > +        {
> > +            printk(XENLOG_ERR "%pd %pp: BAR%u is not in memory space\n",
> > +                   pdev->domain, &pdev->sbdf, index);
> > +            return -EINVAL;
> 
> Same question here then.
> 
> > +        }
> > +
> > +        rc = vpci_add_register(pdev->vpci, vpci_hw_read32, vpci_hw_write32,
> > +                               rebar_offset + PCI_REBAR_CAP(i), 4, NULL);
> > +        if ( rc )
> > +        {
> > +            printk(XENLOG_ERR "%pd %pp: fail to add reg of REBAR_CAP rc=%d\n",
> > +                   pdev->domain, &pdev->sbdf, rc);
> > +            return rc;
> > +        }
> > +
> > +        rc = vpci_add_register(pdev->vpci, vpci_hw_read32, rebar_ctrl_write,
> > +                               rebar_offset + PCI_REBAR_CTRL(i), 4, bar);
> > +        if ( rc )
> > +        {
> > +            printk(XENLOG_ERR "%pd %pp: fail to add reg of REBAR_CTRL rc=%d\n",
> > +                   pdev->domain, &pdev->sbdf, rc);
> > +            return rc;
> > +        }
> > +
> > +        bar->resizable_sizes |=
> > +            (pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CAP(i)) >>
> > +             PCI_REBAR_CAP_SHIFT);
> 
> Imo this would better use = in place of |= and (see also below) would also
> better use MASK_EXTR() just like ...
> 
> > +        bar->resizable_sizes |=
> > +            ((uint64_t)MASK_EXTR(ctrl, PCI_REBAR_CTRL_SIZES) <<
> > +             (32 - PCI_REBAR_CAP_SHIFT));
> 
> ... this one does.
> 
> Further I think you want to truncate the value for 32-bit BARs, such that
> rebar_ctrl_write() would properly reject attempts to set sizes of 4G and
> above for them.

For the hardware domain at least we shouldn't add such restriction -
Xen in general allows dom0 to do things it would otherwise consider
invalid, in case it has to deal with hardware quirks.

Rather than reject Xen should just print a warning that the sizes
supported by the device are likely invalid.

> > --- a/xen/drivers/vpci/vpci.c
> > +++ b/xen/drivers/vpci/vpci.c
> > @@ -232,6 +232,12 @@ void cf_check vpci_hw_write16(
> >      pci_conf_write16(pdev->sbdf, reg, val);
> >  }
> >  
> > +void cf_check vpci_hw_write32(
> > +    const struct pci_dev *pdev, unsigned int reg, uint32_t val, void *data)
> > +{
> > +    pci_conf_write32(pdev->sbdf, reg, val);
> > +}
> 
> This function is being added just to handle writing of a r/o register.
> Can't you better re-use vpci_ignored_write()?

But vpci_ignored_write() ignores the write, OTOH here the write is
propagated to the hardware.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 14:41:13 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 14:41:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866409.1277736 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVAlb-0001Uw-UL; Tue, 07 Jan 2025 14:41:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866409.1277736; Tue, 07 Jan 2025 14:41:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVAlb-0001Up-RL; Tue, 07 Jan 2025 14:41:11 +0000
Received: by outflank-mailman (input) for mailman id 866409;
 Tue, 07 Jan 2025 14:41:11 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=aJXC=T7=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tVAlb-0001Uj-BO
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 14:41:11 +0000
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com
 [2a00:1450:4864:20::430])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6f17c7ee-cd05-11ef-99a4-01e77a169b0f;
 Tue, 07 Jan 2025 15:41:09 +0100 (CET)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-385dece873cso5849133f8f.0
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 06:41:09 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4366127c4d7sm598932225e9.34.2025.01.07.06.41.08
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 06:41:08 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 6f17c7ee-cd05-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736260869; x=1736865669; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=3ZxbVhDdkRSxrvbRhEhdp/w6Gmm99GNwUld0zkWBH74=;
        b=Wyi1ROoBtH+7PxDQgrHUQ0QtJ6UykjFBWYpwubZsobNt+dyhDB8ZZO53tBde+nQbV7
         An5Wkk/G/o6SOp1syBbUbPgFTczsPoCnFasGV1UPr/qXJitfdRxa0npXK2pSqhQHZJQ5
         0iuHfk7lAMtk6BM5JZfpETWaDg4ejcooZr8QE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736260869; x=1736865669;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=3ZxbVhDdkRSxrvbRhEhdp/w6Gmm99GNwUld0zkWBH74=;
        b=H9yuZUHOAtEsgOzgwW+vZOVQwmD8H4AHu6BaZfHzq6fl1SWx2T50E31MnYbHVGemSs
         IduA/McqM0PnPLHikNIAyWaEzpeVAQm5XOD8Kpu1FwQehyD/pwjsF6sM1YOoy7IVDpIp
         Prb2mycTY3ZCriquiKG63xkY9kOxHv8Z02cBNimkWRqvJJ3D7GXBybFlH3I2l/bqQSXi
         W+PM5fXgflA5Je4ZTEEOfp2X55sYN9ljPwDHEa3z4EL7nEkuAC55i7m5Em2kultgyzth
         fVNjw+PVaFT36Xdi7Eh/LnqWOFVBYf3omOzPIP35yHJ8GHhi+UH4AtCHRsOdAV/+gDlY
         C6Zg==
X-Forwarded-Encrypted: i=1; AJvYcCULACiH6/L/yM3fOp7BgAcvr8wnIrrMDFi9GEdFIgNzeo4xZnkjyI8sRql3igdJWjGI917GgZZgZWc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwE2RboIO3chqj0WnTm//rCVLwwrImSfaHJ6s0XpYKPh9H5Tl9t
	goH/Cvxb3ZCzTaVIotI6ZBYn4ykoLnL/ebFPmxKc7OpmzkzoBNP38rAPaT0Udco=
X-Gm-Gg: ASbGncvN/4623uAWYUOJA4e2UlDMvLF8sMc1E1gF4U2prF64GI8wBWDpnqNkIHLrJw7
	AwNdjQuEHsNLvdafJ/Mb09zCxb3GONPNF0ffp9X3cbpYluQ8NFsSYMCSrkUHdrNcNljP+cqsDCv
	2l6sdC9+0LxZuPMUdOj2TUEA4RxD7jzWBdFEsxZf2k0XoiByAtWkkSbI8uVD8oM+cNBkKYCts7E
	kqLBYxtoIPrjkPrn+ARQzUey0JMUWH+UTyxZ1R+rDdehi1rPL1QCvYrFlJve0uWx4UORGCLUYHF
	Aj+7EkqErt5a9nW4I9cI
X-Google-Smtp-Source: AGHT+IEvAbHNsN288w4MrIHxN7go0dzUJnHRsRd43qKA01D9UuWwNLnGxNgF5k2YuzXhhnpxE/DfcA==
X-Received: by 2002:a5d:64ad:0:b0:385:e67d:9e0 with SMTP id ffacd0b85a97d-38a221ffe1bmr49349107f8f.29.1736260868999;
        Tue, 07 Jan 2025 06:41:08 -0800 (PST)
Message-ID: <7ea74155-8b86-43de-9e98-cfea071c1d99@citrix.com>
Date: Tue, 7 Jan 2025 14:41:08 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86emul: VCVT{,U}DQ2PD ignores embedded rounding
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
References: <238beefd-126a-4a2d-99de-dc5675c88ef6@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <238beefd-126a-4a2d-99de-dc5675c88ef6@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 07/01/2025 2:32 pm, Jan Beulich wrote:
> IOW we shouldn't raise #UD in that case. Be on the safe side though and
> only encode fully legitimate forms into the stub to be executed.
>
> Things weren't quite right for VCVT{,U}SI2SD either, in the attempt to
> be on the safe side: Clearing EVEX.L'L isn't useful; it's EVEX.b which
> primarily needs clearing. Also reflect the somewhat improved doc
> situation in the comment there.
>
> Fixes: ed806f373730 ("x86emul: support AVX512F legacy-equivalent packed int/FP conversion insns")
> Fixes: baf4a376f550 ("x86emul: support AVX512F legacy-equivalent scalar int/FP conversion insns")
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 15:03:37 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 15:03:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866417.1277747 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVB7D-0004g3-N8; Tue, 07 Jan 2025 15:03:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866417.1277747; Tue, 07 Jan 2025 15:03:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVB7D-0004fw-Id; Tue, 07 Jan 2025 15:03:31 +0000
Received: by outflank-mailman (input) for mailman id 866417;
 Tue, 07 Jan 2025 15:03:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=OtGL=T7=linux.ibm.com=agordeev@srs-se1.protection.inumbo.net>)
 id 1tVB7D-0004fm-1A
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 15:03:31 +0000
Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com
 [148.163.158.5]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8cc03427-cd08-11ef-99a4-01e77a169b0f;
 Tue, 07 Jan 2025 16:03:28 +0100 (CET)
Received: from pps.filterd (m0360072.ppops.net [127.0.0.1])
 by mx0a-001b2d01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 50785q0m018311;
 Tue, 7 Jan 2025 15:02:55 GMT
Received: from ppma13.dal12v.mail.ibm.com
 (dd.9e.1632.ip4.static.sl-reverse.com [50.22.158.221])
 by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4410f39tfg-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Tue, 07 Jan 2025 15:02:55 +0000 (GMT)
Received: from pps.filterd (ppma13.dal12v.mail.ibm.com [127.0.0.1])
 by ppma13.dal12v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 507E2w4n027938;
 Tue, 7 Jan 2025 15:02:54 GMT
Received: from smtprelay07.fra02v.mail.ibm.com ([9.218.2.229])
 by ppma13.dal12v.mail.ibm.com (PPS) with ESMTPS id 43yhhk2t7y-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Tue, 07 Jan 2025 15:02:54 +0000
Received: from smtpav04.fra02v.mail.ibm.com (smtpav04.fra02v.mail.ibm.com
 [10.20.54.103])
 by smtprelay07.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id
 507F2nAY55837076
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Tue, 7 Jan 2025 15:02:50 GMT
Received: from smtpav04.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id C602420043;
 Tue,  7 Jan 2025 15:02:49 +0000 (GMT)
Received: from smtpav04.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id 683182004D;
 Tue,  7 Jan 2025 15:02:48 +0000 (GMT)
Received: from li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com (unknown
 [9.155.204.135])
 by smtpav04.fra02v.mail.ibm.com (Postfix) with ESMTPS;
 Tue,  7 Jan 2025 15:02:48 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8cc03427-cd08-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc
	:content-type:date:from:in-reply-to:message-id:mime-version
	:references:subject:to; s=pp1; bh=nGMTr1inoVWG3ARe8QoGoEOSwdCntu
	qZy8bhdK6O/ME=; b=rdj4BTKquX38fA+V7vs9vGrg6z7HxUyoh1JCIFg2qPrBrc
	ovRrqMTxob92ukiN9TlpZCs7CVUaqv6rh4Mi5tAIkhlcCaduaExoYeYLzmHkaH1C
	S0jV8pQzj2Q2N++he2cxLihvsXN9Ws2JTtsztsnqZdNHB0F+gy5J9PuEu1tgZtJk
	XpYyXE/McfMm5JLsDDKSEa0f3gOdZvqdAytY6OUzDZe71qUCT9y2i1ZigqqwPHmx
	1mK+SyY6FXGKya5ump+AzYcnbek4K8yEjS0n+sKJkfNM1URBoiNo/3Sb4PjRN+s0
	zgkOb4fRUrznizbOxQ8cOjfYiVbiPNEGSmJygikg==
Date: Tue, 7 Jan 2025 16:02:47 +0100
From: Alexander Gordeev <agordeev@linux.ibm.com>
To: Guo Weikang <guoweikang.kernel@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>, Mike Rapoport <rppt@kernel.org>,
        Geert Uytterhoeven <geert@linux-m68k.org>,
        Dennis Zhou <dennis@kernel.org>, Tejun Heo <tj@kernel.org>,
        Christoph Lameter <cl@linux.com>,
        Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
        Sam Creasey <sammy@sammy.net>, Huacai Chen <chenhuacai@kernel.org>,
        Will Deacon <will@kernel.org>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Oreoluwa Babatunde <quic_obabatun@quicinc.com>,
        rafael.j.wysocki@intel.com, Palmer Dabbelt <palmer@rivosinc.com>,
        Hanjun Guo <guohanjun@huawei.com>,
        Easwar Hariharan <eahariha@linux.microsoft.com>,
        Johannes Berg <johannes.berg@intel.com>,
        Ingo Molnar <mingo@kernel.org>, Dave Hansen <dave.hansen@intel.com>,
        Christian Brauner <brauner@kernel.org>, KP Singh <kpsingh@kernel.org>,
        Richard Henderson <richard.henderson@linaro.org>,
        Matt Turner <mattst88@gmail.com>, Russell King <linux@armlinux.org.uk>,
        WANG Xuerui <kernel@xen0n.name>, Michael Ellerman <mpe@ellerman.id.au>,
        Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>,
        Stafford Horne <shorne@gmail.com>, Helge Deller <deller@gmx.de>,
        Nicholas Piggin <npiggin@gmail.com>,
        Christophe Leroy <christophe.leroy@csgroup.eu>,
        Naveen N Rao <naveen@kernel.org>,
        Madhavan Srinivasan <maddy@linux.ibm.com>,
        Geoff Levand <geoff@infradead.org>,
        Paul Walmsley <paul.walmsley@sifive.com>,
        Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>,
        Andrey Ryabinin <ryabinin.a.a@gmail.com>,
        Alexander Potapenko <glider@google.com>,
        Andrey Konovalov <andreyknvl@gmail.com>,
        Dmitry Vyukov <dvyukov@google.com>,
        Vincenzo Frascino <vincenzo.frascino@arm.com>,
        Heiko Carstens <hca@linux.ibm.com>, Vasily Gorbik <gor@linux.ibm.com>,
        Christian Borntraeger <borntraeger@linux.ibm.com>,
        Sven Schnelle <svens@linux.ibm.com>,
        Yoshinori Sato <ysato@users.sourceforge.jp>,
        Rich Felker <dalias@libc.org>,
        John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
        Andreas Larsson <andreas@gaisler.com>,
        Richard Weinberger <richard@nod.at>,
        Anton Ivanov <anton.ivanov@cambridgegreys.com>,
        Johannes Berg <johannes@sipsolutions.net>,
        Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>,
        Borislav Petkov <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org,
        linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev,
        linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org,
        linux-openrisc@vger.kernel.org, linux-parisc@vger.kernel.org,
        linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,
        kasan-dev@googlegroups.com, linux-s390@vger.kernel.org,
        linux-sh@vger.kernel.org, sparclinux@vger.kernel.org,
        linux-um@lists.infradead.org, linux-acpi@vger.kernel.org,
        xen-devel@lists.xenproject.org, linux-omap@vger.kernel.org,
        linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
        linux-mm@kvack.org, linux-pm@vger.kernel.org,
        Xi Ruoyao <xry111@xry111.site>
Subject: Re: [PATCH v7] mm/memblock: Add memblock_alloc_or_panic interface
Message-ID: <Z31CF9f//ZD+VH59@li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com>
References: <20241222111537.2720303-1-guoweikang.kernel@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20241222111537.2720303-1-guoweikang.kernel@gmail.com>
X-TM-AS-GCONF: 00
X-Proofpoint-GUID: by_phAXyWBB4rrGUxAvoGmZnyCdgAMa_
X-Proofpoint-ORIG-GUID: by_phAXyWBB4rrGUxAvoGmZnyCdgAMa_
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1051,Hydra:6.0.680,FMLib:17.12.62.30
 definitions=2024-10-15_01,2024-10-11_01,2024-09-30_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 mlxlogscore=985
 spamscore=0 lowpriorityscore=0 adultscore=0 malwarescore=0 impostorscore=0
 bulkscore=0 phishscore=0 suspectscore=0 priorityscore=1501 clxscore=1011
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2411120000
 definitions=main-2501070126

On Sun, Dec 22, 2024 at 07:15:37PM +0800, Guo Weikang wrote:

Hi Guo,

> Before SLUB initialization, various subsystems used memblock_alloc to
> allocate memory. In most cases, when memory allocation fails, an immediate
> panic is required. To simplify this behavior and reduce repetitive checks,
> introduce `memblock_alloc_or_panic`. This function ensures that memory
> allocation failures result in a panic automatically, improving code
> readability and consistency across subsystems that require this behavior.

I believe, you also want to make similar function against memblock_alloc_low().

Please, find s390 comments below.

...

> diff --git a/arch/s390/kernel/numa.c b/arch/s390/kernel/numa.c
> index ddc1448ea2e1..a33e20f73330 100644
> --- a/arch/s390/kernel/numa.c
> +++ b/arch/s390/kernel/numa.c
> @@ -22,10 +22,7 @@ void __init numa_setup(void)
>  	node_set(0, node_possible_map);
>  	node_set_online(0);
>  	for (nid = 0; nid < MAX_NUMNODES; nid++) {
> -		NODE_DATA(nid) = memblock_alloc(sizeof(pg_data_t), 8);
> -		if (!NODE_DATA(nid))
> -			panic("%s: Failed to allocate %zu bytes align=0x%x\n",
> -			      __func__, sizeof(pg_data_t), 8);
> +		NODE_DATA(nid) = memblock_alloc_or_panic(sizeof(pg_data_t), 8);
>  	}

Please, also remove the cycle body brackets.

>  	NODE_DATA(0)->node_spanned_pages = memblock_end_of_DRAM() >> PAGE_SHIFT;
>  	NODE_DATA(0)->node_id = 0;
> diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c
> index 0ce550faf073..1298f0860733 100644
> --- a/arch/s390/kernel/setup.c
> +++ b/arch/s390/kernel/setup.c
> @@ -376,11 +376,7 @@ static unsigned long __init stack_alloc_early(void)
>  {
>  	unsigned long stack;
>  
> -	stack = (unsigned long)memblock_alloc(THREAD_SIZE, THREAD_SIZE);
> -	if (!stack) {
> -		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
> -		      __func__, THREAD_SIZE, THREAD_SIZE);
> -	}
> +	stack = (unsigned long)memblock_alloc_or_panic(THREAD_SIZE, THREAD_SIZE);
>  	return stack;
>  }
>  
> @@ -504,10 +500,7 @@ static void __init setup_resources(void)
>  	bss_resource.end = __pa_symbol(__bss_stop) - 1;
>  
>  	for_each_mem_range(i, &start, &end) {
> -		res = memblock_alloc(sizeof(*res), 8);
> -		if (!res)
> -			panic("%s: Failed to allocate %zu bytes align=0x%x\n",
> -			      __func__, sizeof(*res), 8);
> +		res = memblock_alloc_or_panic(sizeof(*res), 8);
>  		res->flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM;
>  
>  		res->name = "System RAM";
> @@ -526,10 +519,7 @@ static void __init setup_resources(void)
>  			    std_res->start > res->end)
>  				continue;
>  			if (std_res->end > res->end) {
> -				sub_res = memblock_alloc(sizeof(*sub_res), 8);
> -				if (!sub_res)
> -					panic("%s: Failed to allocate %zu bytes align=0x%x\n",
> -					      __func__, sizeof(*sub_res), 8);
> +				sub_res = memblock_alloc_or_panic(sizeof(*sub_res), 8);
>  				*sub_res = *std_res;
>  				sub_res->end = res->end;
>  				std_res->start = res->end + 1;
> @@ -816,9 +806,7 @@ static void __init setup_randomness(void)
>  {
>  	struct sysinfo_3_2_2 *vmms;
>  
> -	vmms = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
> -	if (!vmms)
> -		panic("Failed to allocate memory for sysinfo structure\n");
> +	vmms = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
>  	if (stsi(vmms, 3, 2, 2) == 0 && vmms->count)
>  		add_device_randomness(&vmms->vm, sizeof(vmms->vm[0]) * vmms->count);
>  	memblock_free(vmms, PAGE_SIZE);
> diff --git a/arch/s390/kernel/smp.c b/arch/s390/kernel/smp.c
> index 822d8e6f8717..d77aaefb59bd 100644
> --- a/arch/s390/kernel/smp.c
> +++ b/arch/s390/kernel/smp.c
> @@ -611,9 +611,9 @@ void __init smp_save_dump_ipl_cpu(void)
>  	if (!dump_available())
>  		return;
>  	sa = save_area_alloc(true);
> -	regs = memblock_alloc(512, 8);
> -	if (!sa || !regs)
> +	if (!sa)
>  		panic("could not allocate memory for boot CPU save area\n");

Please, replace memblock_alloc() with memblock_alloc_or_panic() in
save_area_alloc() and remove the error handling here and also in
smp_save_dump_secondary_cpus().

> +	regs = memblock_alloc_or_panic(512, 8);
>  	copy_oldmem_kernel(regs, __LC_FPREGS_SAVE_AREA, 512);
>  	save_area_add_regs(sa, regs);
>  	memblock_free(regs, 512);
> @@ -792,10 +792,7 @@ void __init smp_detect_cpus(void)
>  	u16 address;
>  
>  	/* Get CPU information */
> -	info = memblock_alloc(sizeof(*info), 8);
> -	if (!info)
> -		panic("%s: Failed to allocate %zu bytes align=0x%x\n",
> -		      __func__, sizeof(*info), 8);
> +	info = memblock_alloc_or_panic(sizeof(*info), 8);
>  	smp_get_core_info(info, 1);
>  	/* Find boot CPU type */
>  	if (sclp.has_core_type) {
> diff --git a/arch/s390/kernel/topology.c b/arch/s390/kernel/topology.c
> index 0fd56a1cadbd..cf5ee6032c0b 100644
> --- a/arch/s390/kernel/topology.c
> +++ b/arch/s390/kernel/topology.c
> @@ -548,10 +548,7 @@ static void __init alloc_masks(struct sysinfo_15_1_x *info,
>  		nr_masks *= info->mag[TOPOLOGY_NR_MAG - offset - 1 - i];
>  	nr_masks = max(nr_masks, 1);
>  	for (i = 0; i < nr_masks; i++) {
> -		mask->next = memblock_alloc(sizeof(*mask->next), 8);
> -		if (!mask->next)
> -			panic("%s: Failed to allocate %zu bytes align=0x%x\n",
> -			      __func__, sizeof(*mask->next), 8);
> +		mask->next = memblock_alloc_or_panic(sizeof(*mask->next), 8);
>  		mask = mask->next;
>  	}
>  }
> @@ -569,10 +566,7 @@ void __init topology_init_early(void)
>  	}
>  	if (!MACHINE_HAS_TOPOLOGY)
>  		goto out;
> -	tl_info = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
> -	if (!tl_info)
> -		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
> -		      __func__, PAGE_SIZE, PAGE_SIZE);
> +	tl_info = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
>  	info = tl_info;
>  	store_topology(info);
>  	pr_info("The CPU configuration topology of the machine is: %d %d %d %d %d %d / %d\n",

Thanks!


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 15:16:19 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 15:16:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866424.1277756 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVBJW-0006dt-Nu; Tue, 07 Jan 2025 15:16:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866424.1277756; Tue, 07 Jan 2025 15:16:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVBJW-0006dm-L5; Tue, 07 Jan 2025 15:16:14 +0000
Received: by outflank-mailman (input) for mailman id 866424;
 Tue, 07 Jan 2025 15:16:13 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=X79W=T7=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tVBJV-0006de-Jl
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 15:16:13 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5354713e-cd0a-11ef-a0df-8be0dac302b0;
 Tue, 07 Jan 2025 16:16:10 +0100 (CET)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-aaedd529ba1so1759170866b.1
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 07:16:10 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aae8b7de1cesm2226676966b.23.2025.01.07.07.16.09
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 07 Jan 2025 07:16:09 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5354713e-cd0a-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736262970; x=1736867770; 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=19MYg6VBapyTtJhDJKd1kEjrCdtMUutELvteACPDNAQ=;
        b=jVlxGVNb68dN5o7MTGCm4jxh6nLK/l7phxnv2RoUhnESghgG+R4dTpNcNo7UoUMbVx
         BYA+QSGbRgaB+/tUA2RV7Jr1hVjxnIx15rXoavDsXA9U5pZvNjwoLxD4O4HJuUoRDDW4
         iSrnjFxY/rB4pMBH59eSbYpMeME3ytUDcsKv8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736262970; x=1736867770;
        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=19MYg6VBapyTtJhDJKd1kEjrCdtMUutELvteACPDNAQ=;
        b=vbAcoRznKDW2UyLvHUW5ahCb9fsJLUuOYlUQJkeIsw5uu+RelItOLDIq0aSz2kIa5r
         9CMsBq1BPmyKCLZcxjspgnSrSR6coCXJbqw7UwnhTXWP03QCgVi7uk18lowOeavwFxXQ
         f//O6uQiTw3LmtrVDGofscoh/4JPvjp2lhEb9pd1pbNFw8duA6s5+meqvFv2j3sUiaP7
         Q91FBxGj9DC8cpmkn3W8RTiERsht+4re8xSPAhiVQCBY4ntIEh794fDSRKsSQvOeaLhU
         6A60xInTdK3bMPXnYm1ykgV3xAYqDRs4aDwVJAvU+fX3JX6tNTxswZsRkwf10rtfr9R5
         wTFg==
X-Forwarded-Encrypted: i=1; AJvYcCXO88xe7Yo7KA1LA9Sl8iWTQPxR+niFdzq/BY3kAIVvyFfZ9VSJkHJ5SFO9LLM6H48qnlPWazeCJL4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YymjRuzt2rXN4iHPLoJXtT157dJxhHhQMFGZHpOcBuFVH/D08FJ
	/9eBUyEE8S0j6LKsy5aEONh6b2/qJxGp1/DNiLHWrYCQkYzn0QrbK/244JnNQl4=
X-Gm-Gg: ASbGncssT8oA3BkFfjcuK1IX+YUVMyQhKv+pEJu9AvCKp1K6Cfj95hx4nXjazZs6YUM
	OG5voh1KoiVE7IN/fsFyHvGl+RyXscej5cla8/fOKJe9IIyjp6c58OdiI22+xt5oayebrjU0OtB
	F/BXQrWY/vzDC0DxebeG42H+ZXYW+B2PHDkE+OyfBhTwfNxfcTjz/1/y0kJ1HXkEFfZbN+0DyAf
	ds8i1P9avJD9sy0wqU9a91DF2slCbyNZLKDi2KFCKGIopNbR7tJL4TtqNgABw==
X-Google-Smtp-Source: AGHT+IGrEKuSubA8nkux3Dm2/lK5HTqmw/lLF8zOXEElWvtG6rCCfQsYxLHcUqLvPxJjO9TYFRVjVA==
X-Received: by 2002:a05:6402:1590:b0:5d0:d818:559d with SMTP id 4fb4d7f45d1cf-5d81dda6576mr156160493a12.11.1736262969910;
        Tue, 07 Jan 2025 07:16:09 -0800 (PST)
Date: Tue, 7 Jan 2025 16:16:08 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2 33/35] x86/domain: implement domain_has_vuart()
Message-ID: <Z31FONoeaHVRHVxY@macbook.local>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-33-e9aa923127eb@ford.com>
 <Z1wnUzDCPDzHKr6o@macbook.local>
 <Tz4Idf7hUa85arksVC6UYYRNbhinY-0wHXqxIInbLCWGNiGZSEIvGNGLmICNLmHK5o7m6MUMhnUlrJX10WO1XHhyRSgCX7Gknz0xBGZJiD8=@proton.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <Tz4Idf7hUa85arksVC6UYYRNbhinY-0wHXqxIInbLCWGNiGZSEIvGNGLmICNLmHK5o7m6MUMhnUlrJX10WO1XHhyRSgCX7Gknz0xBGZJiD8=@proton.me>

On Sat, Jan 04, 2025 at 05:19:07AM +0000, Denis Mukhin wrote:
> On Friday, December 13th, 2024 at 4:23 AM, Roger Pau Monné <roger.pau@citrix.com> wrote:
> > Albeit PVH is kind of HVM.
> 
> PVH does not have vPIC so there's some more work to enable vUART
> for PVH on x86: emulator currently supports only ISA IRQs.

But it does support vIO-APIC (as it's used for hardware PVH domain),
so serial interrupts could still be delivered using the vIO-APIC if
the guest has correctly configured the pin?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 15:23:59 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 15:23:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866527.1277815 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVBQt-0003Mf-Ul; Tue, 07 Jan 2025 15:23:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866527.1277815; Tue, 07 Jan 2025 15:23:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVBQt-0003MW-QA; Tue, 07 Jan 2025 15:23:51 +0000
Received: by outflank-mailman (input) for mailman id 866527;
 Tue, 07 Jan 2025 15:23:49 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=1r68=T7=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVBQr-0003MQ-S1
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 15:23:49 +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 6470e6d7-cd0b-11ef-a0df-8be0dac302b0;
 Tue, 07 Jan 2025 16:23:48 +0100 (CET)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-38632b8ae71so10979709f8f.0
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 07:23:48 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1fa2bdfbsm49897332f8f.102.2025.01.07.07.23.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 07:23:47 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 6470e6d7-cd0b-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736263428; x=1736868228; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=7ZokT/iBgCMJkc/jTDnSOEDz3zuHOtXGi02TGbTzYDU=;
        b=HRn3xFJd2nQh6e1s+3dgNOWoQxZ8Boi+jqOlSORuGZDefV+uNVn0JVm+xouKc5jjIA
         jewnra2nx9F6BuHSSy0ozsfdXqO5bt/a6tmce0Gk9S4pkJqPqpyyebTVFkqPQoSEf2ko
         DaSNlaoHfrU8qufTuAqEbVhwnYdwbDFKD5J1OjX7HGUJvbXBKaO4ZpsSJA1rn9N5vUuO
         IBCQkt7lj2oWNetSAum6g9SLE8yq1pGWo1HuCsDpBFJ1EFxCpoRt9vIPWSgTSmSSNsht
         IAT+rYqAq2+PEUx1fkg6rxKdu1ERwKbl+lGo2D04dx76KlHdJDyFXKH/gzg384tFZMEG
         oVOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736263428; x=1736868228;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=7ZokT/iBgCMJkc/jTDnSOEDz3zuHOtXGi02TGbTzYDU=;
        b=p2o1mq6W5vpNoww0l5GiYnAA4TkKIw12Ketzl+2rGQzHeTWGMOup+IWYXJzGwbfkug
         wWcB/+f1ymCBLJydBr+V7NFl5LBzXrYaPeTOT1Y/zLNbgzv+LUb1+iddDfTq4lLfzSg8
         PtmYxBv4PVFCa0eZ1Z4+9h6xASkFSu3tRmCVwCPHmd3xLTWFDTS85v6EPgnK+2Q0rFtd
         YRPn/PVqGbITvypFp4B+WNcWxuoc2WQ/14o0kB9I+mXI+zFlZJ3+GbsX9yjrvEmYkj7J
         socXlBJ3X4qgkKSsFNdcqHVcw2yJ7enjbd5zyyvgtaSdmTp4CoueLnHLDbko5Yo+EjKz
         olMw==
X-Forwarded-Encrypted: i=1; AJvYcCV1+/gQXYq3ZyWT9sSOB29B86I+wYT81iNPvCriIcsaKbH5MCvQ9Q1k0JkFvExN3lar42eze226ru4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyZDW3x6uafJ9lOKF5Zn/EGlzirLhbicUrhI1yqd2ZDnEJdXuA5
	0Lq5zFj6nUFIJgxGVK5+MlQ6ZtoXe7/UQLOD80yPjclfEQ+13QFN1wrRIk8IwA==
X-Gm-Gg: ASbGncug+MWtiEI7Y4mNUxrWfvXEXN/yuKW8awowqRpO4TTGjWhDbfNKYEn2LCnEmAU
	P0lTpOkGbwUeQUn9htV/4ifV3/Eudfxmr5+XA00WlTSh4oLe1dv/dO+Bb88o19ylgqV6sS9eOiP
	1QL2a1CYUniZNAl0Z+xQ1R9jgDeYfILBsPbHyGSi2RO0kr1WfV9oU8UYYQvMR4L3CS/yFh3r/k/
	s9p46heBMxpsuHPlTzvdXArX9j2jc4VHKuU/K7Wc0FK6qLRPuG5Nxnt06qd0MML5VKJMuvDZyka
	IYZD0HdSMFwHdNiEt92elikD7ENWEbT99yIZAvtNvw==
X-Google-Smtp-Source: AGHT+IFVB1EEcM3V6Fee7KCK4NIcC3dxDaNK1loma6Vqp1ab2VSJjQXnAp/y8SwgnYcaYpJB85a/QA==
X-Received: by 2002:a05:6000:470a:b0:385:f092:df2 with SMTP id ffacd0b85a97d-38a221faae4mr46071934f8f.34.1736263428086;
        Tue, 07 Jan 2025 07:23:48 -0800 (PST)
Message-ID: <c7ed9380-a4a1-4576-af56-2949d80cfd92@suse.com>
Date: Tue, 7 Jan 2025 16:23:46 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 1/7] xen/events: fix race with
 set_global_virq_handler()
To: Juergen Gross <jgross@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <20250107101711.5980-1-jgross@suse.com>
 <20250107101711.5980-2-jgross@suse.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250107101711.5980-2-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 07.01.2025 11:17, Juergen Gross wrote:
> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -979,6 +979,7 @@ void send_global_virq(uint32_t virq)
>  int set_global_virq_handler(struct domain *d, uint32_t virq)
>  {
>      struct domain *old;
> +    int rc = 0;
>  
>      if (virq >= NR_VIRQS)
>          return -EINVAL;
> @@ -992,14 +993,23 @@ int set_global_virq_handler(struct domain *d, uint32_t virq)
>          return -EINVAL;
>  
>      spin_lock(&global_virq_handlers_lock);
> -    old = global_virq_handlers[virq];
> -    global_virq_handlers[virq] = d;
> +
> +    if ( d->is_dying != DOMDYING_alive )
> +    {
> +        old = d;
> +        rc = -EINVAL;
> +    }

While I can see how this eliminates the zombie domain aspect, this doesn't
fully eliminate the race. Doing so would require (also) using the domain's
event lock. Assuming we're okay with the remaining race, imo a code comment
would be needed to state this (including the fact that it's then
unpredictable whether this operation might still succeed for a domain
already having d->is_dying != DOMDYING_alive).

Plus the way you do it the early success path remains; ideally that case
would also fail for an already dying domain.

> +    else
> +    {
> +        old = global_virq_handlers[virq];
> +        global_virq_handlers[virq] = d;
> +    }
>      spin_unlock(&global_virq_handlers_lock);

Nit: Much like you do at the top of your addition, a new blank line at the
bottom would be nice.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 15:26:49 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 15:26:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866537.1277824 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVBTj-00041S-Es; Tue, 07 Jan 2025 15:26:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866537.1277824; Tue, 07 Jan 2025 15:26:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVBTj-00041L-CD; Tue, 07 Jan 2025 15:26:47 +0000
Received: by outflank-mailman (input) for mailman id 866537;
 Tue, 07 Jan 2025 15:26: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
 <SRS0=QnJ5=T7=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tVBTi-00041F-0i
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 15:26:46 +0000
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com
 [2a00:1450:4864:20::130])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id cd92fc5e-cd0b-11ef-a0df-8be0dac302b0;
 Tue, 07 Jan 2025 16:26:44 +0100 (CET)
Received: by mail-lf1-x130.google.com with SMTP id
 2adb3069b0e04-54021daa6cbso15692017e87.0
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 07:26:44 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-54223832c5bsm5281792e87.274.2025.01.07.07.26.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 07:26:43 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: cd92fc5e-cd0b-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736263604; x=1736868404; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=pfWHKG3Q+5nnzH6s/mruPyyMaUe48IHjTRpPOsXc/U0=;
        b=WObiU2LUV9ko5/YWGsqKn0GItH7uBCExBulKlTbmRCMJtMRqTHqCe1OXcZdt8Jtkz8
         XBk6729H5xELxgfDSiXRHfRLbe+LCwmEvEHhlrUn/I237yFA+Izm1D3yjV/S1F5q38z7
         yDGwl2yLL1XrdVEvBU+IL0eoYbL5oqp6On0fvxG6m7hPL3ya6AWIruJhSyx5GTvFu0Lo
         EMmKg68ILKJ165VvltA83j63cudoTn75NqnM7hu7U8io0Jh+6AcLHA5S+n65n7vIBLKY
         EkxvhOq7sc5voqARY2oaENE2kGWI0Lg0lErJMQguMEESMyX6/o9Dzs8zSYbPSnaLjPZk
         kVaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736263604; x=1736868404;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=pfWHKG3Q+5nnzH6s/mruPyyMaUe48IHjTRpPOsXc/U0=;
        b=GX0+GHpRUkSsYgQ792lBpA1HHNFYL5d5it+s4LYwPOyD3kI2fv5W35l0HEKELOn2db
         uyoHSajKF1fnNUGI1+F6z58KK0j766xCsKuHUmQreoQiUxlUg+ktZUPriPwjG/Edn4FV
         3jg/yD/8EbFP7GT+7YtLSDpRjGOSK3j1wzWxpe1o6hzJ4sg2guEufl2eik7GNzYR9eGN
         ACvFy85pAJ62pxdxK1WLaU1eEUbVRMiH3cNXcUVOf2pAqlv184x4ET5dtq3Dy+19kUUh
         z3VbZcexLeSmQhHDH3nX1v3ama3RdzoKOhL0LBTGGyANoP+P2++wAyoKbZbAVvJbcMZu
         gDAw==
X-Forwarded-Encrypted: i=1; AJvYcCV3dqEyGl2KojME2zEEnrvJgntGb6OYceqpVoaYyo0KxeVsPZs7g70NVfY3C9a8nWSwPD/HVqOH5Vo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzSTWXI/P5INcdAXCwpm78HRjn+VtpkqxV4iq9WJfalQ2e61cOh
	BJXXnYbCz3f/Dbme8fxQWBXy9kEapBrccw0ppFaYoKUDZTqQEITb
X-Gm-Gg: ASbGnctenJLyaMrZmv0TjkYxw8yldCxejl1vuZ7rgIp/5nVhcRIisbmHcS97Ku2F4uC
	yOIY5EdYmq+DOtkrWmdaH40cSSy2BY7uQDJo9r9itKdZRRSr+CDf7ak7WATTwhS1jNjTqoAjqyV
	CIfVAy+YnL9wWcM4TtpCvDS5OFV1o2ozxdnnwOzeiEHAyzeXr5ReK3jJfVp6GnJlH4RfZlV+Y8Y
	H6iBpRrNRbeAv9Wdp7kbBZ0c+F9j7hlKaKTWhtnL/2/y1B/CMFns8XpEvdlH4reg93TvQ==
X-Google-Smtp-Source: AGHT+IFMoIyECy0Qy4dvRveiz13MZ7Mnn0Wa0mm26zf0+2KdVh1GYwXmA6reqKSZdbnn1X+gLfK1oQ==
X-Received: by 2002:a05:6512:334f:b0:53e:389d:8ce6 with SMTP id 2adb3069b0e04-5422953d2e0mr14281693e87.28.1736263603983;
        Tue, 07 Jan 2025 07:26:43 -0800 (PST)
Message-ID: <03215adc-3b42-463b-8d3c-74e6d1b28f12@gmail.com>
Date: Tue, 7 Jan 2025 16:26:42 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [for-4.20][PATCH 0/3] xen/flask: Wire up missing hypercalls
To: Michal Orzel <michal.orzel@amd.com>, xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" <dpsmith@apertussolutions.com>,
 Anthony PERARD <anthony.perard@vates.tech>
References: <20250107092719.26401-1-michal.orzel@amd.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <20250107092719.26401-1-michal.orzel@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Michal,

On 1/7/25 10:27 AM, Michal Orzel wrote:
> It's been noted by Juergen that recently added XEN_DOMCTL_set_llc_colors
> is not wired up in FLASK. While preparing a fix, I noticed two other Arm
> hypercalls from the past that were missing the linking as well. These two
> are latent bugs while the LLC one is a release blocker for 4.20.

Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>


Thanks.


~ Oleksii

>
> Michal Orzel (3):
>    xen/flask: Wire up XEN_DOMCTL_vuart_op
>    xen/flask: Wire up XEN_DOMCTL_dt_overlay
>    xen/flask: Wire up XEN_DOMCTL_set_llc_colors
>
>   tools/flask/policy/modules/dom0.te  | 2 +-
>   tools/flask/policy/modules/xen.if   | 4 ++--
>   xen/xsm/flask/hooks.c               | 9 +++++++++
>   xen/xsm/flask/policy/access_vectors | 6 ++++++
>   4 files changed, 18 insertions(+), 3 deletions(-)
>


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 15:34:53 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 15:34:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866544.1277833 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVBbN-0006H7-6B; Tue, 07 Jan 2025 15:34:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866544.1277833; Tue, 07 Jan 2025 15:34:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVBbN-0006H0-3d; Tue, 07 Jan 2025 15:34:41 +0000
Received: by outflank-mailman (input) for mailman id 866544;
 Tue, 07 Jan 2025 15:34:39 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=1r68=T7=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVBbL-0006Gu-GM
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 15:34:39 +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 e791a2e4-cd0c-11ef-a0df-8be0dac302b0;
 Tue, 07 Jan 2025 16:34:38 +0100 (CET)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-4361b0ec57aso155977895e9.0
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 07:34: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
 5b1f17b1804b1-43656b3b1f6sm641670845e9.31.2025.01.07.07.34.36
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 07:34:37 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e791a2e4-cd0c-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736264077; x=1736868877; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=8dE4UY1pEK6j334jROg3v1j1Cwtpd/V3ZexOdykQq4g=;
        b=MBgV+g0LLtzlDE6XzSRlbG4qUGEskNUx/y3ouDYRuLzwb1RS212U3jqMEpq+7h5b5/
         0WQg0g8pRLrbLvTSIbNgAnl1EfsQsZLJ4RAC9Eh5vAiTkElMhr4q6Q4rG35VuaqAF2B/
         gmcp2iGr3966mmfzxbqqJ24q2Gwf46xHpli7hWGRqWzUTVyMVqVIzmvrxsod0kS+tZLp
         2ZplAh9u+S2ijzPKKYn9cJS9zADm9sjJ0xSd67BhTLjw7Z1KJmy45gfiXeAHtv6UTMvX
         1g0eX0btnQiijstPq248jJdnDPeMMiZNBu1yeuMnbtF6JNaHfWQ4R5EhOfiMVazU8qd1
         /qxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736264077; x=1736868877;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=8dE4UY1pEK6j334jROg3v1j1Cwtpd/V3ZexOdykQq4g=;
        b=wxqlrtj/UE/YbE4XAvWkN3zczBRC5cVo/LpJdMe0jIsEG0he9wpih6YJ9j1/LkiT7z
         xqhDujszVsir71SeBKzvINoTtAqhVeWQxMnqjiNqx/i+JQbuBwuutD3BfVUMpUralZ2y
         seNIxu8lWcjyWUpDp5gFrYigpv8zf8S2iQFLRk9w5zwkfzKBaZmt9TVZusSRd8HarLD2
         x5Zk7gVcBZ3iwsI2QAdnWBRnhoESg0Vlq5jpzv6HrbUlJHR2VBxTBycfjU4/Q+JKTscK
         PD5fiFC6Z3H+meiRKYuSSqquotVFiwtypscMdpLodZlhlatn03I8r30sv4qGHjR6B7pQ
         3cFA==
X-Forwarded-Encrypted: i=1; AJvYcCXq2+OEGkAxIPdHgTVnBuz1PuFW37wjrdvP1aYMrSDujkhS2yc0faCJS/n5kiOJD3gfjjsuIeKTtBQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwiKt3rqhDnDYnxb1LznsO03sIUAmVQ0eBeacWpIoxTHx0vyPkh
	562MNwUEM5YzMmK02HOXifWY6ydn7FsiQqRSDD5pDtKOmAiAi3eDNW+liamIUA==
X-Gm-Gg: ASbGncvM5emDaDCNRojLYzwSHk7MLfF/6Gcq8DRYDVJZ/t7+TZQ9zvKA1pbZpVYFYYz
	UHox1oLbyQImviV5mr8d8K46Go/Ysvki2MLh4AGQO0qxHFi+4c1bG1RKVsSvgP+WgE9dw+a386Z
	Ee8dApLvC/pNahSP5zEhwbp+563S6/cgjDhlPfUMjDtbJ4k1gaXZBNRXIiUqXWB77X4sxMiyUuh
	GmQFNzqdGrEIAglGKavhfI8IWXEnJLOfAVs0cGJoe/4jo9RMctCF0LWaUkr5u9eDKzxLuJJHcfG
	praxEGzGOL6JnXM3ciwgSsHz+0Dj+A7LMoayQxbTbQ==
X-Google-Smtp-Source: AGHT+IEZ4VYpvCrpHE2KRFeP6X5SVq7N1sLz2dLKHTL0pahcNVQqHTN6O5vBGlzEzzELDspx4pw6OQ==
X-Received: by 2002:a05:600c:1c9f:b0:435:32e:8270 with SMTP id 5b1f17b1804b1-43668642f9dmr532372675e9.14.1736264077507;
        Tue, 07 Jan 2025 07:34:37 -0800 (PST)
Message-ID: <577427ff-61e2-4fc9-8853-a7eec3f69bb6@suse.com>
Date: Tue, 7 Jan 2025 16:34:35 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 2/7] xen/events: don't allow binding a global virq from
 any domain
To: Juergen Gross <jgross@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <20250107101711.5980-1-jgross@suse.com>
 <20250107101711.5980-3-jgross@suse.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250107101711.5980-3-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 07.01.2025 11:17, Juergen Gross wrote:
> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -120,6 +120,13 @@ static uint8_t get_xen_consumer(xen_event_channel_notification_t fn)
>  /* Get the notification function for a given Xen-bound event channel. */
>  #define xen_notification_fn(e) (xen_consumers[(e)->xen_consumer-1])
>  
> +static struct domain *global_virq_handlers[NR_VIRQS] __read_mostly;

Nit: While you move this line around, it would be nice if the attribute
could then also move to its canonical place (between type and identifier).

> +static struct domain *get_global_virq_handler(unsigned int virq)
> +{
> +    return global_virq_handlers[virq] ?: hardware_domain;
> +}
> +
>  static bool virq_is_global(unsigned int virq)
>  {
>      switch ( virq )
> @@ -479,8 +486,13 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind, evtchn_port_t port)
>      */
>      virq = array_index_nospec(virq, ARRAY_SIZE(v->virq_to_evtchn));
>  
> -    if ( virq_is_global(virq) && (vcpu != 0) )
> -        return -EINVAL;
> +    if ( virq_is_global(virq) )
> +    {
> +        if ( get_global_virq_handler(virq) != d )
> +            return -EBUSY;

Hmm. While this eliminates the problem for the common, race free case,
the handler changing right after the check would still mean the bind
would succeed.

Plus this way you're breaking a case that afaict has been working so
far: The bind happening before the setting of the handler. With a lot
of unrelated if-s and when-s this could e.g. be of interest when
considering a re-startable Xenstore domain. The one to take over could
start first, obtain state from the original one while that's still
active, and be nominated the handler of the global vIRQ only in the
last moment.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 15:37:23 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 15:37:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866551.1277844 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVBdx-0006om-ID; Tue, 07 Jan 2025 15:37:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866551.1277844; Tue, 07 Jan 2025 15:37:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVBdx-0006of-FY; Tue, 07 Jan 2025 15:37:21 +0000
Received: by outflank-mailman (input) for mailman id 866551;
 Tue, 07 Jan 2025 15:37:19 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=aJXC=T7=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tVBdv-0006oU-MX
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 15:37:19 +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 47487c52-cd0d-11ef-a0df-8be0dac302b0;
 Tue, 07 Jan 2025 16:37:18 +0100 (CET)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-436637e8c8dso159080815e9.1
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 07:37:18 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4366e210cecsm565458225e9.2.2025.01.07.07.37.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 07:37:17 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 47487c52-cd0d-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736264238; x=1736869038; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=2Nn49KIz/Kqr+XOf+BeSA+uccHMjMolWvltQhZ9YK2M=;
        b=LJa9x9kgRqI1sLFm56XF7jDXj1lz4JbYK3z8zdS6xwqPyvbSX0L8CjnCYOAKjFibwH
         8jdPYkWNep9yKnah6lO01sz/MX2NnOyTjUtetlNMPchsYJe0zYi4C2Y1k5rUVXvjqAhF
         mGu6vNDGSHvHjU0mBhyC8H8tL4NaYZHBEwoSo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736264238; x=1736869038;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=2Nn49KIz/Kqr+XOf+BeSA+uccHMjMolWvltQhZ9YK2M=;
        b=vc97yHs82Fkyx4Rd3MpchLWuxef4AHH+pRL52oRQLsMnt0x/xrf7Cm+wNZJ2rGt15q
         2ITr2gj+ZgheXzNlI7HVXqtM0RD2rMfS29IBibUyRGy0+dFNqMaCX7J3fJEOrxjINeWI
         hf2O7UbNvbHmQJJwYnQl7xkkzAtjqyIPeFd3h5DAPS+h2VYSinIaUYR37Xll5+Ga+2be
         DxRM4DHTWpjYaxns6M1zhvn3psqy6O29g7QG2U2L4y96NgHfAXFa/Bh82bpsYfGlseLV
         mcxcAXAUrhNSF+MYKfpP0LXVQWTTrorp8iMUVStwJAgBRtXOxUtEgWotL8v1baOqfSaK
         DnTA==
X-Forwarded-Encrypted: i=1; AJvYcCVP4s7O+pgWmsX3hok3eON1kCkSblVi9vYd5HJZtUe4wCbwyhOZKHZHzagnVSNROU4GMiwyUi6mynQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy2IUdIMjOzur2RbOrdv4vybFtGr2dNr+ZY+3QzGqEAJJxnu2Nz
	oluWf5AapHotUqqAoNJw6lhezfNXEK19LobJnvnDvEs59lbWbfCmRNdciGoQRYBDJeRzAA53Vtl
	hPdFmzw==
X-Gm-Gg: ASbGncukMU5g9B61/SdoAC9I8tw5GBT0NzvmhxM+SiskhkfLbAOnh+p6+NooGw3ReIp
	UOJ/3S5iqxMdYYyDty6HGEKFIeY+BN2kGF4oFHNYztGFs6I/NuDiXZn/TE5BT3G3tBWIhroA6bu
	wIXOoYic69c/36wrN6GgTpMVX4sWERkk43KGzUE3CAJD06A/8wXXLvn6/rKTz8bWcKTOVVXEDJk
	IgD3HmKyTdBUAg2Txp1bVf45kJ++KlLpdYQvJM/N/4xbLKI4IHFgZgd9nlA3kci13F7/Hd6w7Ca
	X4dY1GZRGHU2FRcmlXHq
X-Google-Smtp-Source: AGHT+IEct/ZjsymJxr4n+LpeUUp4aAFbkh0FOwDPzGlhkn7Dzvp5Vt2FkkzCbtqxcKqZLzZeN9b+LA==
X-Received: by 2002:a05:600c:1f8f:b0:436:30e4:459b with SMTP id 5b1f17b1804b1-4368a8b6a2emr442067425e9.18.1736264238205;
        Tue, 07 Jan 2025 07:37:18 -0800 (PST)
Message-ID: <8db5b675-385f-4ea7-a2e9-7a8a54d96f72@citrix.com>
Date: Tue, 7 Jan 2025 15:37:17 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86emul: correct put_fpu()'s segment selector handling
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
References: <81428267-e963-4403-989d-d96fb0b59ffc@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <81428267-e963-4403-989d-d96fb0b59ffc@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 07/01/2025 2:33 pm, Jan Beulich wrote:
> All selector fields under ctxt->regs are (normally) poisoned in the HVM
> case, and the four ones besides CS and SS are potentially stale for PV.
> Avoid using them in the hypervisor incarnation of the emulator, when
> trying to cover for a missing ->read_segment() hook.
>
> To make sure there's always a valid ->read_segment() handler for all HVM
> cases, add a respective function to shadow code, even if it is not
> expected for FPU insns to be used to update page tables.
>
> Fixes: 0711b59b858a ("x86emul: correct FPU code/data pointers and opcode handling")
> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> The code comment may want adjusting in the course of FRED work.

It compiles when displacing my temporary patch in the FRED branch.  I've
not got the ABI compatibility in userspace working yet, but
regs->{ds,es,fs,gs} will be staying, so the #else case should be fine
(assuming they're populated properly).

So, tentatively, Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

That said, I think it would be nicer to see about excluding the FPU in
these cases.  Both cases lacking read_segment() hooks are pagetable
emulation, and I'd say it's more likely to be code corruption than there
actually being x87 instructions in the middle of a dual 32bit PAE update.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 15:38:01 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 15:38:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866557.1277855 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVBeb-0007Ic-RM; Tue, 07 Jan 2025 15:38:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866557.1277855; Tue, 07 Jan 2025 15:38:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVBeb-0007IV-Mw; Tue, 07 Jan 2025 15:38:01 +0000
Received: by outflank-mailman (input) for mailman id 866557;
 Tue, 07 Jan 2025 15:38:00 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Qdqe=T7=suse.com=jgross@srs-se1.protection.inumbo.net>)
 id 1tVBea-00075f-Ff
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 15:38:00 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5f329ced-cd0d-11ef-99a4-01e77a169b0f;
 Tue, 07 Jan 2025 16:37:58 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id 3D696210F6;
 Tue,  7 Jan 2025 15:37:58 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id EA5E013A6A;
 Tue,  7 Jan 2025 15:37:57 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id iSq7N1VKfWfwTQAAD6G6ig
 (envelope-from <jgross@suse.com>); Tue, 07 Jan 2025 15:37:57 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5f329ced-cd0d-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1736264278; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=TecDtdtIaSBeCDNWcu7HrRLoZraG1eM0027MGblEYa4=;
	b=VpX33nqGDTS1iAiEGGLitKS4rXp2nLISE3CLy3JlafCZRxLghJSMBzFlRUfNefHY0KLCcl
	XQ0O6BaF+oG1u7awbv2h0R4Sc5/rpiTrQu10NUmOAeWLH6bloYkj0OYxdQoAR5G0VoFLAu
	zj86TQxc4OSu2Ygs9CPjtRoTpIJWVCA=
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=VpX33nqG
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1736264278; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=TecDtdtIaSBeCDNWcu7HrRLoZraG1eM0027MGblEYa4=;
	b=VpX33nqGDTS1iAiEGGLitKS4rXp2nLISE3CLy3JlafCZRxLghJSMBzFlRUfNefHY0KLCcl
	XQ0O6BaF+oG1u7awbv2h0R4Sc5/rpiTrQu10NUmOAeWLH6bloYkj0OYxdQoAR5G0VoFLAu
	zj86TQxc4OSu2Ygs9CPjtRoTpIJWVCA=
Message-ID: <c00886ec-184c-4a82-8093-4fc9b470ea1b@suse.com>
Date: Tue, 7 Jan 2025 16:37:57 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 1/7] xen/events: fix race with
 set_global_virq_handler()
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <20250107101711.5980-1-jgross@suse.com>
 <20250107101711.5980-2-jgross@suse.com>
 <c7ed9380-a4a1-4576-af56-2949d80cfd92@suse.com>
Content-Language: en-US
From: Juergen Gross <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <c7ed9380-a4a1-4576-af56-2949d80cfd92@suse.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------LyMlS47PQ8BhR8wSsoI5Kl7X"
X-Rspamd-Queue-Id: 3D696210F6
X-Spam-Level: 
X-Spamd-Result: default: False [-5.41 / 50.00];
	BAYES_HAM(-3.00)[99.99%];
	SIGNED_PGP(-2.00)[];
	MIME_BASE64_TEXT_BOGUS(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_UNKNOWN(0.10)[application/pgp-keys];
	MIME_BASE64_TEXT(0.10)[];
	MX_GOOD(-0.01)[];
	FROM_HAS_DN(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	ARC_NA(0.00)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	HAS_ATTACHMENT(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_SEVEN(0.00)[8];
	DKIM_TRACE(0.00)[suse.com:+];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns,suse.com:dkim,suse.com:mid]
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Rspamd-Action: no action
X-Spam-Score: -5.41
X-Spam-Flag: NO

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------LyMlS47PQ8BhR8wSsoI5Kl7X
Content-Type: multipart/mixed; boundary="------------Cf30b5ZqoG3Mol017QA0rddf";
 protected-headers="v1"
From: Juergen Gross <jgross@suse.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
Message-ID: <c00886ec-184c-4a82-8093-4fc9b470ea1b@suse.com>
Subject: Re: [PATCH v6 1/7] xen/events: fix race with
 set_global_virq_handler()
References: <20250107101711.5980-1-jgross@suse.com>
 <20250107101711.5980-2-jgross@suse.com>
 <c7ed9380-a4a1-4576-af56-2949d80cfd92@suse.com>
In-Reply-To: <c7ed9380-a4a1-4576-af56-2949d80cfd92@suse.com>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------Cf30b5ZqoG3Mol017QA0rddf
Content-Type: multipart/mixed; boundary="------------kWRiZ995KpgSFqZ27PlsI0Qm"

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

T24gMDcuMDEuMjUgMTY6MjMsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAwNy4wMS4yMDI1
IDExOjE3LCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0KPj4gLS0tIGEveGVuL2NvbW1vbi9ldmVu
dF9jaGFubmVsLmMNCj4+ICsrKyBiL3hlbi9jb21tb24vZXZlbnRfY2hhbm5lbC5jDQo+PiBA
QCAtOTc5LDYgKzk3OSw3IEBAIHZvaWQgc2VuZF9nbG9iYWxfdmlycSh1aW50MzJfdCB2aXJx
KQ0KPj4gICBpbnQgc2V0X2dsb2JhbF92aXJxX2hhbmRsZXIoc3RydWN0IGRvbWFpbiAqZCwg
dWludDMyX3QgdmlycSkNCj4+ICAgew0KPj4gICAgICAgc3RydWN0IGRvbWFpbiAqb2xkOw0K
Pj4gKyAgICBpbnQgcmMgPSAwOw0KPj4gICANCj4+ICAgICAgIGlmICh2aXJxID49IE5SX1ZJ
UlFTKQ0KPj4gICAgICAgICAgIHJldHVybiAtRUlOVkFMOw0KPj4gQEAgLTk5MiwxNCArOTkz
LDIzIEBAIGludCBzZXRfZ2xvYmFsX3ZpcnFfaGFuZGxlcihzdHJ1Y3QgZG9tYWluICpkLCB1
aW50MzJfdCB2aXJxKQ0KPj4gICAgICAgICAgIHJldHVybiAtRUlOVkFMOw0KPj4gICANCj4+
ICAgICAgIHNwaW5fbG9jaygmZ2xvYmFsX3ZpcnFfaGFuZGxlcnNfbG9jayk7DQo+PiAtICAg
IG9sZCA9IGdsb2JhbF92aXJxX2hhbmRsZXJzW3ZpcnFdOw0KPj4gLSAgICBnbG9iYWxfdmly
cV9oYW5kbGVyc1t2aXJxXSA9IGQ7DQo+PiArDQo+PiArICAgIGlmICggZC0+aXNfZHlpbmcg
IT0gRE9NRFlJTkdfYWxpdmUgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBvbGQgPSBkOw0K
Pj4gKyAgICAgICAgcmMgPSAtRUlOVkFMOw0KPj4gKyAgICB9DQo+IA0KPiBXaGlsZSBJIGNh
biBzZWUgaG93IHRoaXMgZWxpbWluYXRlcyB0aGUgem9tYmllIGRvbWFpbiBhc3BlY3QsIHRo
aXMgZG9lc24ndA0KPiBmdWxseSBlbGltaW5hdGUgdGhlIHJhY2UuIERvaW5nIHNvIHdvdWxk
IHJlcXVpcmUgKGFsc28pIHVzaW5nIHRoZSBkb21haW4ncw0KPiBldmVudCBsb2NrLiBBc3N1
bWluZyB3ZSdyZSBva2F5IHdpdGggdGhlIHJlbWFpbmluZyByYWNlLCBpbW8gYSBjb2RlIGNv
bW1lbnQNCj4gd291bGQgYmUgbmVlZGVkIHRvIHN0YXRlIHRoaXMgKGluY2x1ZGluZyB0aGUg
ZmFjdCB0aGF0IGl0J3MgdGhlbg0KPiB1bnByZWRpY3RhYmxlIHdoZXRoZXIgdGhpcyBvcGVy
YXRpb24gbWlnaHQgc3RpbGwgc3VjY2VlZCBmb3IgYSBkb21haW4NCj4gYWxyZWFkeSBoYXZp
bmcgZC0+aXNfZHlpbmcgIT0gRE9NRFlJTkdfYWxpdmUpLg0KDQpBRkFJVSB5b3UgbWVhbiB0
aGF0IGl0IGlzIHN0aWxsIHBvc3NpYmxlIHRvIHNldCBhIGRvbWFpbiB0byBoYW5kbGUgYSB2
aXJxDQp3aGVuIGl0IGlzIGluIHRoZSBwcm9jZXNzIG9mIGdvaW5nIGRvd24sIGVzcGVjaWFs
bHkgaWYgaXNfZHlpbmcgaXMgc2V0IGp1c3QNCmFmdGVyIGl0IGhhcyBiZWVuIHRlc3RlZCB0
byBiZSBET01EWUlOR19hbGl2ZT8NCg0KSSBkb24ndCBzZWUgdGhpcyBiZWluZyBhIHByb2Js
ZW0sIGFzIHRoZSBzYW1lIHdvdWxkIGhhcHBlbiBpZiB0aGUgZG9tYWluDQp3b3VsZCBnbyBk
b3duIGp1c3QgYSBtaWxsaXNlY29uZCBsYXRlci4gVGhpcyBpcyBzb21ldGhpbmcgd2Ugd2ls
bCBuZXZlciBiZQ0KYWJsZSB0byBoYW5kbGUuDQoNCkFuZCBhZnRlciBhbGwgdGhlIGNhbGwg
b2YgY2xlYXJfZ2xvYmFsX3ZpcnFfaGFuZGxlcnMoKSB3aWxsIG5vdyByZXNldCB0aGUNCmhh
bmRsaW5nIGRvbWFpbiB0byB0aGUgaGFyZHdhcmUgZG9tYWluIGluIGFsbCBjYXNlcy4NCg0K
PiANCj4gUGx1cyB0aGUgd2F5IHlvdSBkbyBpdCB0aGUgZWFybHkgc3VjY2VzcyBwYXRoIHJl
bWFpbnM7IGlkZWFsbHkgdGhhdCBjYXNlDQo+IHdvdWxkIGFsc28gZmFpbCBmb3IgYW4gYWxy
ZWFkeSBkeWluZyBkb21haW4uDQoNClNhbWUgYWdhaW46IGNsZWFyX2dsb2JhbF92aXJxX2hh
bmRsZXJzKCkgd2lsbCByZXNldCB0aGUgaGFuZGxpbmcgZG9tYWluLg0KDQo+IA0KPj4gKyAg
ICBlbHNlDQo+PiArICAgIHsNCj4+ICsgICAgICAgIG9sZCA9IGdsb2JhbF92aXJxX2hhbmRs
ZXJzW3ZpcnFdOw0KPj4gKyAgICAgICAgZ2xvYmFsX3ZpcnFfaGFuZGxlcnNbdmlycV0gPSBk
Ow0KPj4gKyAgICB9DQo+PiAgICAgICBzcGluX3VubG9jaygmZ2xvYmFsX3ZpcnFfaGFuZGxl
cnNfbG9jayk7DQo+IA0KPiBOaXQ6IE11Y2ggbGlrZSB5b3UgZG8gYXQgdGhlIHRvcCBvZiB5
b3VyIGFkZGl0aW9uLCBhIG5ldyBibGFuayBsaW5lIGF0IHRoZQ0KPiBib3R0b20gd291bGQg
YmUgbmljZS4NCg0KV2lsbCBhZGQgdGhhdCBpZiBhIHJlc3BpbiBpcyBuZWVkZWQuDQoNCg0K
SnVlcmdlbg0KDQo=
--------------kWRiZ995KpgSFqZ27PlsI0Qm
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

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

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

--------------kWRiZ995KpgSFqZ27PlsI0Qm--

--------------Cf30b5ZqoG3Mol017QA0rddf--

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

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

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmd9SlUFAwAAAAAACgkQsN6d1ii/Ey8j
wQf8DqiLPX5pbpp0d9fLWz2+M/VsMdi7WTtpgiD2Q2XeVsMGf4i7s970XbuaMJhcatkAeywYRvII
7aayadlFbOR6hmfP/nyBzBGCpI2cJoR2/eF5vuAs6XAo5pDyH4nzi2nHacd9DYvoe6GK9MzTbsHy
G8Nk8fKH9vMor+9iMaSe1KqP4gPRbDd98/eidI5s8kC1EDCgXQynR6yyYNKlXINlfyokuVUg4GJa
orp7juELeNT3lmya49kItNWY0fma7RZPu4xA5AAn2za0eqbeG09mgFn9ncTRL3geljnLSgIdBp8Y
toVpoNnbcVGHvrmdLajEl/rYMN1LW1ZpaRg6Tkw6+Q==
=m+js
-----END PGP SIGNATURE-----

--------------LyMlS47PQ8BhR8wSsoI5Kl7X--


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 15:38:32 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 15:38:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866565.1277864 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVBf5-0007sG-8O; Tue, 07 Jan 2025 15:38:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866565.1277864; Tue, 07 Jan 2025 15:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVBf5-0007s9-5h; Tue, 07 Jan 2025 15:38:31 +0000
Received: by outflank-mailman (input) for mailman id 866565;
 Tue, 07 Jan 2025 15:38: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 <SRS0=1r68=T7=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVBf4-0007ey-RD
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 15:38:30 +0000
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com
 [2a00:1450:4864:20::42c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 71e1d1a0-cd0d-11ef-a0df-8be0dac302b0;
 Tue, 07 Jan 2025 16:38:30 +0100 (CET)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3862ca8e0bbso11926472f8f.0
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 07:38:30 -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
 ffacd0b85a97d-38a1c833899sm50657116f8f.42.2025.01.07.07.38.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 07:38:29 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 71e1d1a0-cd0d-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736264309; x=1736869109; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=n88R0tKAJGFAg7FLHaog3UqW9b7iYYT3soyLICmHikY=;
        b=YEKv44FTTlTwnkLRlYYrOqrTfAlBNO7tMwU2EgE7as8yGjVHy8KR9J8P/0bCG5zrgv
         YGtVA1BhjQqzdP1k6svMiKk4AArz92ChHvkC/DjuYv0694tdEaY3x0B5IvbgV7Kgch2M
         ihLk0iFC315rU7DXY80HaUF+YRFW7+Tbw4hdv4oCAwMqnQuhZkg6Fb56FUoW5kLnrnvt
         VMxY9GeF0zp4DD3qXoBBNIupHu7yRUtYnTkyHCpbKOO0k35OnuIusTZ49s1SViwk7YeZ
         IaZZeIvVSEQk5ty5SrHL3syf/Fs/uF27DghHFKPmwyLw5/pVhLCWnRDOOcZpjFvFiyDR
         hS2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736264309; x=1736869109;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=n88R0tKAJGFAg7FLHaog3UqW9b7iYYT3soyLICmHikY=;
        b=xFAZLRkT6K+mG4nFZ2bTCRT5DNcIDFBurSfZlpbG8UxcaT55/RPC322mEQ+S/sO9lA
         p5LdWGZxIpDbBuJhzRi5sy3fjq2Gi0AnaQ81gkkWhfBrAVX2PfkaTSk3pPFtv1K7MwXD
         Rd+XehuRDK3UMJDMq3QeFksx6j0dArdRq4YHXrN3BI5BXGOjlfNI+kTZ1Db0IXmTBG5n
         RKN5X4OEOki1yEBzTWTKXigycViSfbUgZl46ZQfq4qUhGAaXTb2kxrLnMt32k7EMlxED
         GJ8OCk3xvokIEnMc3ScxrXWT7ee/6Dvf5NKwp+hvDYGjXtKJ1+6qc99NB/Hx8tweDBiJ
         yriA==
X-Forwarded-Encrypted: i=1; AJvYcCWRhIzabkdofUit6KB+PrDG6FQ37Iz3T2/39yHXxSEEVKIGoX1DQk+ouAq0R4BEyFKxCW7gXEn3kvw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy9o74q87sRI3Zn43PDAGz1KPg/LoEmPPu+wfCFW1bq2/ptQIYD
	vZRmNCFKez6S6b33MfbmZHu3GY/EF/htPr+l3O7HuwywaLA/muQRLAycnry5cw==
X-Gm-Gg: ASbGncunM/ooTycKAtpsyCHA5MC2ejZZRNcMaPHl5DhRzEFVTy/TfZat7CMypcMCWte
	gtleID5qFi2gkEWLK4iWSthEV5BGp7u+rfVx0PPXjABnCHdN4Dbz+crLXb17h6FCfkVfehSfVri
	6BXu2PfkwTuWvVo5ZwYUTJE4FuaUvlVOiKHpjmk2ESebuYfJIuXOWZszbHtXjZEDNvrAWcs//Tl
	mi6wUTI2ds/rTmpItUzSUKbsF0qdtDpf+8FOyo6Nd660gqQ3Nu9B9d+h+TNBbaMscr5oUmU6M8a
	NPiERrkpDI+kjjjXoTOjC/vj7wb9eIQ1iue1Zq2eXA==
X-Google-Smtp-Source: AGHT+IF1OlE39RDk6tm+3E3AJjyjSXEbTHVWM/NZhEpr9voa25Zjp9Er+u4EBToV/wA4npQnEFvtog==
X-Received: by 2002:a5d:5e09:0:b0:385:f062:c2d4 with SMTP id ffacd0b85a97d-38a223f768dmr50685881f8f.37.1736264309648;
        Tue, 07 Jan 2025 07:38:29 -0800 (PST)
Message-ID: <053a7a26-2dc9-417a-9b91-cce151543050@suse.com>
Date: Tue, 7 Jan 2025 16:38:28 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 3/7] xen/events: allow setting of global virq handler
 only for unbound virqs
To: Juergen Gross <jgross@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <20250107101711.5980-1-jgross@suse.com>
 <20250107101711.5980-4-jgross@suse.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250107101711.5980-4-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 07.01.2025 11:17, Juergen Gross wrote:
> XEN_DOMCTL_set_virq_handler will happily steal a global virq from the
> current domain having bound it and assign it to another domain. The
> former domain will just never receive any further events for that
> virq without knowing what happened.

Yet - see my reply on patch 2 - it may actually have been intentional to
be this way, in case the new domain is indeed the designated new handler.
Otherwise such a transfer would require more coordination - the original
owner would first need to unbind, then signal the completion thereof to
the new owner.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 15:41:23 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 15:41:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866572.1277875 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVBhm-00018O-OI; Tue, 07 Jan 2025 15:41:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866572.1277875; Tue, 07 Jan 2025 15:41:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVBhm-000187-Hk; Tue, 07 Jan 2025 15:41:18 +0000
Received: by outflank-mailman (input) for mailman id 866572;
 Tue, 07 Jan 2025 15:41: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 <SRS0=1r68=T7=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVBhl-00015x-E1
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 15:41:17 +0000
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com
 [2a00:1450:4864:20::335])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d46f2266-cd0d-11ef-99a4-01e77a169b0f;
 Tue, 07 Jan 2025 16:41:15 +0100 (CET)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-43675b1155bso150265455e9.2
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 07:41:15 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436611ea3d5sm606688405e9.5.2025.01.07.07.41.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 07:41:14 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: d46f2266-cd0d-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736264475; x=1736869275; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=0+QZO95Hmr0Soi19Crmg6U7O1qj+4Ygg5smIKX/o9KY=;
        b=epVCSXQdT93tRae43sewV3aLcIUOsTjJIx2r9x13cwiKyfcHlF9PPF3OQcjq24ixf6
         TI96/HbOANmaxDqXH/mU4yKOK4/DR5mZ8K+saTqRMZoP9yPjaPHGm8WxLTXyIjYnYqn8
         tq7ExulJ/rd+ouVMvl0l5cx5tO7uVrw2HANwOoPnwCXiaaCrr5UMezxJvpZfcrXSCodE
         xRYpP1yWHV7bEkYDnZrZuy8vk5OBxVPpkHHq5MaQ56gZ4hH8WQSRcVvqObL7Euaumy2k
         sImuFPOW/PIHzIHFw4vTiQz1LcUrVtQJkgr2Ct2aaNGDfngFJCfTmY0YPtp6Wvo3fR6z
         uibQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736264475; x=1736869275;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=0+QZO95Hmr0Soi19Crmg6U7O1qj+4Ygg5smIKX/o9KY=;
        b=pA9zCBrr8owZ2tvQK5U5pk9DtpAflP0N+ygoYFxgEc7aMYto3eqTavBSvC/iBRfYOL
         IvMrh2bIFFYanDx65MNRjqZKXbsBdz0kc12LbOdzRrbbOO8LWgmWjoI61FuU8T5pYqms
         U7vgYFqUMQyf3BEHgpUH9kknNOI7nZYDJMKaNkl8IRqljpYC91hLqZuDYeYU+nemLAcF
         vsUJwYtpMe52UgMJEY/nPHyCdT9kxGJfADC+9qKk72rEMRf5i1Oq/P7LvPGHIFMEN6+w
         EkiTFfYDW1lwoghEUgXam5AzOBxPqP1Ewcv1D17eeurnsRbOUrW/XeGl4FQlwc6v4xpE
         0pXw==
X-Forwarded-Encrypted: i=1; AJvYcCWWf2eOA6Joyx3UiQd2ot7pSHicOPHHqCcaYEV8HnceQt5Rpd6NMIEjYS24tvOx/yjahRGIhglHQWQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz6WrsqJXrE7H5BwU2h4hGKpx+9baX2NojiXMqshZ90xLX0Pu7a
	/BSf7YNQUJ+wF85fYJUe3BXsTdS1TsAINbICKdIHyXO5DigNg4TGS/A8XOrACw==
X-Gm-Gg: ASbGncvPh9efghfd4OpHdyapLZahfuhoYU8UKg2HNekrTsN83NGx2DlwgMv2G3rZMnG
	/uRK2Oav8RHeilBY+eKvOyBUJ4nG9YoOr73bUWXnjjhe6PBd242WQdrcjSxPw9f9WIejziNYROC
	6xRNXLKT42p9Zq1EDJexabKKkg79Z76pvYYPwph4QbpSgzCT0lhID3kSticJmWuwL+axFO5Fo5y
	FDptqYTYovD03NsIkB3eI5zTNYO1B9aH6orr1ZCuu7AmBckWqjqkWGV/hJnz1zjRLP7sNuA9nah
	CfmwxxvGZE0Deba+KUx0H6rzKWZnyt2cFmZjZlif3Q==
X-Google-Smtp-Source: AGHT+IGP1EGt9iYvJ+5dvLciEiyK2GygQsIomOiN0XPH9ytrKXPtAxsv/+Azl/JxSaNrXH0poiKOZg==
X-Received: by 2002:a05:600c:4509:b0:436:1971:2a4 with SMTP id 5b1f17b1804b1-4366864722emr576919105e9.17.1736264474966;
        Tue, 07 Jan 2025 07:41:14 -0800 (PST)
Message-ID: <526672ec-4140-4c51-b67a-3b4b803314c2@suse.com>
Date: Tue, 7 Jan 2025 16:41:13 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86emul: correct put_fpu()'s segment selector handling
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <81428267-e963-4403-989d-d96fb0b59ffc@suse.com>
 <8db5b675-385f-4ea7-a2e9-7a8a54d96f72@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <8db5b675-385f-4ea7-a2e9-7a8a54d96f72@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 07.01.2025 16:37, Andrew Cooper wrote:
> On 07/01/2025 2:33 pm, Jan Beulich wrote:
>> All selector fields under ctxt->regs are (normally) poisoned in the HVM
>> case, and the four ones besides CS and SS are potentially stale for PV.
>> Avoid using them in the hypervisor incarnation of the emulator, when
>> trying to cover for a missing ->read_segment() hook.
>>
>> To make sure there's always a valid ->read_segment() handler for all HVM
>> cases, add a respective function to shadow code, even if it is not
>> expected for FPU insns to be used to update page tables.
>>
>> Fixes: 0711b59b858a ("x86emul: correct FPU code/data pointers and opcode handling")
>> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> ---
>> The code comment may want adjusting in the course of FRED work.
> 
> It compiles when displacing my temporary patch in the FRED branch.  I've
> not got the ABI compatibility in userspace working yet, but
> regs->{ds,es,fs,gs} will be staying, so the #else case should be fine
> (assuming they're populated properly).
> 
> So, tentatively, Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

Thanks.

> That said, I think it would be nicer to see about excluding the FPU in
> these cases.  Both cases lacking read_segment() hooks are pagetable
> emulation, and I'd say it's more likely to be code corruption than there
> actually being x87 instructions in the middle of a dual 32bit PAE update.

I considered this case, but decided against going this route. We shouldn't
be stricter than necessary towards what we permit guests to do, however odd
it might look to us.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 15:49:49 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 15:49:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866579.1277884 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVBpv-0002VF-EV; Tue, 07 Jan 2025 15:49:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866579.1277884; Tue, 07 Jan 2025 15:49:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVBpv-0002V8-Bi; Tue, 07 Jan 2025 15:49:43 +0000
Received: by outflank-mailman (input) for mailman id 866579;
 Tue, 07 Jan 2025 15:49: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 <SRS0=1r68=T7=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVBpu-0002V2-5c
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 15:49:42 +0000
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com
 [2a00:1450:4864:20::431])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 01989579-cd0f-11ef-a0df-8be0dac302b0;
 Tue, 07 Jan 2025 16:49:40 +0100 (CET)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-38a25d4b9d4so5910075f8f.0
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 07:49:40 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1fa2bdfbsm49950718f8f.102.2025.01.07.07.49.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 07:49:39 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 01989579-cd0f-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736264980; x=1736869780; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Nk0R7AxUDUa2PYVAgf2NtZ4S4CBkIXwjLjO0HYKmuaE=;
        b=QoPTIHMXOynVjyUL6CPW5x3mtk75RckGvAV0u5u0eibvR8gTjeMYKguSIeo5886++2
         SJVz3t1wxyBhhqQRaJgm4tR75uiXMn7pJUmdXK6RqD2FgNKiuSricbHPwa79VQ0zixE5
         32I16I099MP1eoK93yN2zhjzc4FFmxPaY0sPWROIy1V+fls5MbV1Ot0ir2+cVkAjTAl6
         +VuPwauPrtvdIWMlCjX/Har3iN/AdUYKvLv6+lHdyjkBuemubHA0yj/d8OD1KdUyYgzm
         FEzIWTpHuky49YCQiFLG67nvNcQRzhTR3fEF5xb14U6u3zY00xfaZmBwYc5N6tbQuQTv
         CPDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736264980; x=1736869780;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Nk0R7AxUDUa2PYVAgf2NtZ4S4CBkIXwjLjO0HYKmuaE=;
        b=DPyJMaGm0DLjB8AYUDS1nMFpuR5sho1H2c/RNCeHntG24xbLAX4whVy8ukhdZSKlgh
         Pbszaj9UyAZb4PNrBp4mhOl9rNROlTtFDplRzBRH4BOs72/6JPeoSpRm0da3zeS9TXl0
         fbpoAVoZ15kOClo2jw8dFz2DXtvQWxQZ13v8BOHv4c8JSTSyGX+2ejyH0bFk953ka9Wp
         7kfznUgv7jjF46y7sSmNRsbmkxCbOdLT8773QsmBQrbdUoeEv3708JTuU/nCjUCanE3m
         mOaLUO2cljqSnNLq4GWXp+fGGy+gnfstzmGatYjYlBCaxIGMITsNMIQZYc/UUUanLtX/
         HYWg==
X-Forwarded-Encrypted: i=1; AJvYcCUA8Qilmz6rKWgElI5Xd/a9VAbO6VqwNwrgS10zZL0kiGxbQ/8U+gRXKkY85Hs+nmW27mqSrILXMLA=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz3pxn6/zPIGGDA5n5Y0YjT7Ohy8YuE5zSeODjxMCZ23wh1llp2
	rPqAUPyXwVgaE0bQrD/EnO7NHY3fgUDqhOZ+glIO+SEujCx7Jcwf5crEcxKugw==
X-Gm-Gg: ASbGnct0I4qyNHcbRd1KPst11AGtIqYISGzRWtpLq5fMQuRC4JuWYOHVGsStgXbQQK5
	jUJfnP6gQ+1tzb+HPAjivE5pozqday9d7KMIBy1mf9bF/PnQrlT97/Le/IuIsX3cfkudmvLZs3H
	my2g2+i9JR9bNrYCQyxKQWoFvnME5aKcyKBl+Ps2Tvc17Puxu7AcOAKpVzZmbbaRg/B69vwlfPc
	WAYE2TbmTtJ7bgDafA//2u1UQhMX7dh3zyEpfexo2KqEx11ovJGno8jyGHoRMqxUuGyzxV+/tIc
	dtuuJKV0kJWZH4VAyef6Fj93jiXBjnrxLd491i3BsA==
X-Google-Smtp-Source: AGHT+IESBMPXOWpAWytJe9UWFoA5sg6wrgOsstaApZPO8zUg9kSMPqIYmVK0Y1RXzv5JGreK8/cCIA==
X-Received: by 2002:a05:6000:1543:b0:385:f195:26f with SMTP id ffacd0b85a97d-38a221fb043mr57598990f8f.19.1736264980249;
        Tue, 07 Jan 2025 07:49:40 -0800 (PST)
Message-ID: <270984e8-2296-48b9-b45c-92ab28b4e6dd@suse.com>
Date: Tue, 7 Jan 2025 16:49:38 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 1/7] xen/events: fix race with
 set_global_virq_handler()
To: Juergen Gross <jgross@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <20250107101711.5980-1-jgross@suse.com>
 <20250107101711.5980-2-jgross@suse.com>
 <c7ed9380-a4a1-4576-af56-2949d80cfd92@suse.com>
 <c00886ec-184c-4a82-8093-4fc9b470ea1b@suse.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <c00886ec-184c-4a82-8093-4fc9b470ea1b@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 07.01.2025 16:37, Juergen Gross wrote:
> On 07.01.25 16:23, Jan Beulich wrote:
>> On 07.01.2025 11:17, Juergen Gross wrote:
>>> --- a/xen/common/event_channel.c
>>> +++ b/xen/common/event_channel.c
>>> @@ -979,6 +979,7 @@ void send_global_virq(uint32_t virq)
>>>   int set_global_virq_handler(struct domain *d, uint32_t virq)
>>>   {
>>>       struct domain *old;
>>> +    int rc = 0;
>>>   
>>>       if (virq >= NR_VIRQS)
>>>           return -EINVAL;
>>> @@ -992,14 +993,23 @@ int set_global_virq_handler(struct domain *d, uint32_t virq)
>>>           return -EINVAL;
>>>   
>>>       spin_lock(&global_virq_handlers_lock);
>>> -    old = global_virq_handlers[virq];
>>> -    global_virq_handlers[virq] = d;
>>> +
>>> +    if ( d->is_dying != DOMDYING_alive )
>>> +    {
>>> +        old = d;
>>> +        rc = -EINVAL;
>>> +    }
>>
>> While I can see how this eliminates the zombie domain aspect, this doesn't
>> fully eliminate the race. Doing so would require (also) using the domain's
>> event lock. Assuming we're okay with the remaining race, imo a code comment
>> would be needed to state this (including the fact that it's then
>> unpredictable whether this operation might still succeed for a domain
>> already having d->is_dying != DOMDYING_alive).
> 
> AFAIU you mean that it is still possible to set a domain to handle a virq
> when it is in the process of going down, especially if is_dying is set just
> after it has been tested to be DOMDYING_alive?
> 
> I don't see this being a problem, as the same would happen if the domain
> would go down just a millisecond later. This is something we will never be
> able to handle.

Right, but the sequence of events in the case you mention is different: The
insertion into the array would still happen while the domain isn't marked
dying.

> And after all the call of clear_global_virq_handlers() will now reset the
> handling domain to the hardware domain in all cases.

Of course, but in the meantime an event may be sent to such a domain already
marked dying. That likely isn't going to cause problems, but is unexpected
with what description here says is being addressed.

>> Plus the way you do it the early success path remains; ideally that case
>> would also fail for an already dying domain.
> 
> Same again: clear_global_virq_handlers() will reset the handling domain.

Right.

In summary: As indicated, we may be okay with the remaining race, but then
we also should be making clear that we've decided to leave it at that.
Hence my earlier request: If we accept this, say (and briefly justify) this
in a code comment.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 15:57:05 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 15:57:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866586.1277893 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVBwx-0004vD-3z; Tue, 07 Jan 2025 15:56:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866586.1277893; Tue, 07 Jan 2025 15:56:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVBwx-0004v6-1V; Tue, 07 Jan 2025 15:56:59 +0000
Received: by outflank-mailman (input) for mailman id 866586;
 Tue, 07 Jan 2025 15:56:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Qdqe=T7=suse.com=jgross@srs-se1.protection.inumbo.net>)
 id 1tVBwv-0004v0-Lr
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 15:56:57 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 04cfb722-cd10-11ef-99a4-01e77a169b0f;
 Tue, 07 Jan 2025 16:56:55 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id 0657721114;
 Tue,  7 Jan 2025 15:56:55 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 8CD2D13A6A;
 Tue,  7 Jan 2025 15:56:54 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id NH87IMZOfWfHUwAAD6G6ig
 (envelope-from <jgross@suse.com>); Tue, 07 Jan 2025 15:56:54 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 04cfb722-cd10-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1736265415; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=6Js3pp+6Qd7TTnfkkDpa2xhZBLypmD+iK5Dr+6nsuPM=;
	b=u5nnUUffs1bf7yph7MtY4rbAR1nkyhSOOjBsF/bLjizEKm+57X7xX2geh72gjiDHCsdgLF
	bAsM0NkpptkbqJ6qGkKD3uA7NQhMU5oiVVgHSkJYUuJZhVYHqjokXbuTJlzxzQg8/25hbm
	E/FGeFpaUoLAW7YAiH5ayNZhXSBjPeo=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1736265415; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=6Js3pp+6Qd7TTnfkkDpa2xhZBLypmD+iK5Dr+6nsuPM=;
	b=u5nnUUffs1bf7yph7MtY4rbAR1nkyhSOOjBsF/bLjizEKm+57X7xX2geh72gjiDHCsdgLF
	bAsM0NkpptkbqJ6qGkKD3uA7NQhMU5oiVVgHSkJYUuJZhVYHqjokXbuTJlzxzQg8/25hbm
	E/FGeFpaUoLAW7YAiH5ayNZhXSBjPeo=
Message-ID: <b508c054-5706-4fcc-b8f8-738775530022@suse.com>
Date: Tue, 7 Jan 2025 16:56:53 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 1/7] xen/events: fix race with
 set_global_virq_handler()
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <20250107101711.5980-1-jgross@suse.com>
 <20250107101711.5980-2-jgross@suse.com>
 <c7ed9380-a4a1-4576-af56-2949d80cfd92@suse.com>
 <c00886ec-184c-4a82-8093-4fc9b470ea1b@suse.com>
 <270984e8-2296-48b9-b45c-92ab28b4e6dd@suse.com>
Content-Language: en-US
From: Juergen Gross <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <270984e8-2296-48b9-b45c-92ab28b4e6dd@suse.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------PjYgUMBIqRFr7o8WkLYEGF5M"
X-Spam-Score: -5.19
X-Spamd-Result: default: False [-5.19 / 50.00];
	BAYES_HAM(-3.00)[99.99%];
	SIGNED_PGP(-2.00)[];
	MIME_BASE64_TEXT_BOGUS(1.00)[];
	NEURAL_HAM_LONG(-0.99)[-0.991];
	MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain];
	NEURAL_HAM_SHORT(-0.20)[-0.977];
	MIME_BASE64_TEXT(0.10)[];
	MIME_UNKNOWN(0.10)[application/pgp-keys];
	RCVD_TLS_ALL(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~];
	RCPT_COUNT_SEVEN(0.00)[8];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	TO_DN_SOME(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid];
	HAS_ATTACHMENT(0.00)[]
X-Spam-Flag: NO
X-Spam-Level: 

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------PjYgUMBIqRFr7o8WkLYEGF5M
Content-Type: multipart/mixed; boundary="------------A09bGMHrSfoT0uS5G90NMND3";
 protected-headers="v1"
From: Juergen Gross <jgross@suse.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
Message-ID: <b508c054-5706-4fcc-b8f8-738775530022@suse.com>
Subject: Re: [PATCH v6 1/7] xen/events: fix race with
 set_global_virq_handler()
References: <20250107101711.5980-1-jgross@suse.com>
 <20250107101711.5980-2-jgross@suse.com>
 <c7ed9380-a4a1-4576-af56-2949d80cfd92@suse.com>
 <c00886ec-184c-4a82-8093-4fc9b470ea1b@suse.com>
 <270984e8-2296-48b9-b45c-92ab28b4e6dd@suse.com>
In-Reply-To: <270984e8-2296-48b9-b45c-92ab28b4e6dd@suse.com>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------A09bGMHrSfoT0uS5G90NMND3
Content-Type: multipart/mixed; boundary="------------vnLD0vG1EgF5CVTCqB936Kgl"

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

T24gMDcuMDEuMjUgMTY6NDksIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAwNy4wMS4yMDI1
IDE2OjM3LCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0KPj4gT24gMDcuMDEuMjUgMTY6MjMsIEph
biBCZXVsaWNoIHdyb3RlOg0KPj4+IE9uIDA3LjAxLjIwMjUgMTE6MTcsIEp1ZXJnZW4gR3Jv
c3Mgd3JvdGU6DQo+Pj4+IC0tLSBhL3hlbi9jb21tb24vZXZlbnRfY2hhbm5lbC5jDQo+Pj4+
ICsrKyBiL3hlbi9jb21tb24vZXZlbnRfY2hhbm5lbC5jDQo+Pj4+IEBAIC05NzksNiArOTc5
LDcgQEAgdm9pZCBzZW5kX2dsb2JhbF92aXJxKHVpbnQzMl90IHZpcnEpDQo+Pj4+ICAgIGlu
dCBzZXRfZ2xvYmFsX3ZpcnFfaGFuZGxlcihzdHJ1Y3QgZG9tYWluICpkLCB1aW50MzJfdCB2
aXJxKQ0KPj4+PiAgICB7DQo+Pj4+ICAgICAgICBzdHJ1Y3QgZG9tYWluICpvbGQ7DQo+Pj4+
ICsgICAgaW50IHJjID0gMDsNCj4+Pj4gICAgDQo+Pj4+ICAgICAgICBpZiAodmlycSA+PSBO
Ul9WSVJRUykNCj4+Pj4gICAgICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+Pj4gQEAgLTk5
MiwxNCArOTkzLDIzIEBAIGludCBzZXRfZ2xvYmFsX3ZpcnFfaGFuZGxlcihzdHJ1Y3QgZG9t
YWluICpkLCB1aW50MzJfdCB2aXJxKQ0KPj4+PiAgICAgICAgICAgIHJldHVybiAtRUlOVkFM
Ow0KPj4+PiAgICANCj4+Pj4gICAgICAgIHNwaW5fbG9jaygmZ2xvYmFsX3ZpcnFfaGFuZGxl
cnNfbG9jayk7DQo+Pj4+IC0gICAgb2xkID0gZ2xvYmFsX3ZpcnFfaGFuZGxlcnNbdmlycV07
DQo+Pj4+IC0gICAgZ2xvYmFsX3ZpcnFfaGFuZGxlcnNbdmlycV0gPSBkOw0KPj4+PiArDQo+
Pj4+ICsgICAgaWYgKCBkLT5pc19keWluZyAhPSBET01EWUlOR19hbGl2ZSApDQo+Pj4+ICsg
ICAgew0KPj4+PiArICAgICAgICBvbGQgPSBkOw0KPj4+PiArICAgICAgICByYyA9IC1FSU5W
QUw7DQo+Pj4+ICsgICAgfQ0KPj4+DQo+Pj4gV2hpbGUgSSBjYW4gc2VlIGhvdyB0aGlzIGVs
aW1pbmF0ZXMgdGhlIHpvbWJpZSBkb21haW4gYXNwZWN0LCB0aGlzIGRvZXNuJ3QNCj4+PiBm
dWxseSBlbGltaW5hdGUgdGhlIHJhY2UuIERvaW5nIHNvIHdvdWxkIHJlcXVpcmUgKGFsc28p
IHVzaW5nIHRoZSBkb21haW4ncw0KPj4+IGV2ZW50IGxvY2suIEFzc3VtaW5nIHdlJ3JlIG9r
YXkgd2l0aCB0aGUgcmVtYWluaW5nIHJhY2UsIGltbyBhIGNvZGUgY29tbWVudA0KPj4+IHdv
dWxkIGJlIG5lZWRlZCB0byBzdGF0ZSB0aGlzIChpbmNsdWRpbmcgdGhlIGZhY3QgdGhhdCBp
dCdzIHRoZW4NCj4+PiB1bnByZWRpY3RhYmxlIHdoZXRoZXIgdGhpcyBvcGVyYXRpb24gbWln
aHQgc3RpbGwgc3VjY2VlZCBmb3IgYSBkb21haW4NCj4+PiBhbHJlYWR5IGhhdmluZyBkLT5p
c19keWluZyAhPSBET01EWUlOR19hbGl2ZSkuDQo+Pg0KPj4gQUZBSVUgeW91IG1lYW4gdGhh
dCBpdCBpcyBzdGlsbCBwb3NzaWJsZSB0byBzZXQgYSBkb21haW4gdG8gaGFuZGxlIGEgdmly
cQ0KPj4gd2hlbiBpdCBpcyBpbiB0aGUgcHJvY2VzcyBvZiBnb2luZyBkb3duLCBlc3BlY2lh
bGx5IGlmIGlzX2R5aW5nIGlzIHNldCBqdXN0DQo+PiBhZnRlciBpdCBoYXMgYmVlbiB0ZXN0
ZWQgdG8gYmUgRE9NRFlJTkdfYWxpdmU/DQo+Pg0KPj4gSSBkb24ndCBzZWUgdGhpcyBiZWlu
ZyBhIHByb2JsZW0sIGFzIHRoZSBzYW1lIHdvdWxkIGhhcHBlbiBpZiB0aGUgZG9tYWluDQo+
PiB3b3VsZCBnbyBkb3duIGp1c3QgYSBtaWxsaXNlY29uZCBsYXRlci4gVGhpcyBpcyBzb21l
dGhpbmcgd2Ugd2lsbCBuZXZlciBiZQ0KPj4gYWJsZSB0byBoYW5kbGUuDQo+IA0KPiBSaWdo
dCwgYnV0IHRoZSBzZXF1ZW5jZSBvZiBldmVudHMgaW4gdGhlIGNhc2UgeW91IG1lbnRpb24g
aXMgZGlmZmVyZW50OiBUaGUNCj4gaW5zZXJ0aW9uIGludG8gdGhlIGFycmF5IHdvdWxkIHN0
aWxsIGhhcHBlbiB3aGlsZSB0aGUgZG9tYWluIGlzbid0IG1hcmtlZA0KPiBkeWluZy4NCj4g
DQo+PiBBbmQgYWZ0ZXIgYWxsIHRoZSBjYWxsIG9mIGNsZWFyX2dsb2JhbF92aXJxX2hhbmRs
ZXJzKCkgd2lsbCBub3cgcmVzZXQgdGhlDQo+PiBoYW5kbGluZyBkb21haW4gdG8gdGhlIGhh
cmR3YXJlIGRvbWFpbiBpbiBhbGwgY2FzZXMuDQo+IA0KPiBPZiBjb3Vyc2UsIGJ1dCBpbiB0
aGUgbWVhbnRpbWUgYW4gZXZlbnQgbWF5IGJlIHNlbnQgdG8gc3VjaCBhIGRvbWFpbiBhbHJl
YWR5DQo+IG1hcmtlZCBkeWluZy4gVGhhdCBsaWtlbHkgaXNuJ3QgZ29pbmcgdG8gY2F1c2Ug
cHJvYmxlbXMsIGJ1dCBpcyB1bmV4cGVjdGVkDQo+IHdpdGggd2hhdCBkZXNjcmlwdGlvbiBo
ZXJlIHNheXMgaXMgYmVpbmcgYWRkcmVzc2VkLg0KPiANCj4+PiBQbHVzIHRoZSB3YXkgeW91
IGRvIGl0IHRoZSBlYXJseSBzdWNjZXNzIHBhdGggcmVtYWluczsgaWRlYWxseSB0aGF0IGNh
c2UNCj4+PiB3b3VsZCBhbHNvIGZhaWwgZm9yIGFuIGFscmVhZHkgZHlpbmcgZG9tYWluLg0K
Pj4NCj4+IFNhbWUgYWdhaW46IGNsZWFyX2dsb2JhbF92aXJxX2hhbmRsZXJzKCkgd2lsbCBy
ZXNldCB0aGUgaGFuZGxpbmcgZG9tYWluLg0KPiANCj4gUmlnaHQuDQo+IA0KPiBJbiBzdW1t
YXJ5OiBBcyBpbmRpY2F0ZWQsIHdlIG1heSBiZSBva2F5IHdpdGggdGhlIHJlbWFpbmluZyBy
YWNlLCBidXQgdGhlbg0KPiB3ZSBhbHNvIHNob3VsZCBiZSBtYWtpbmcgY2xlYXIgdGhhdCB3
ZSd2ZSBkZWNpZGVkIHRvIGxlYXZlIGl0IGF0IHRoYXQuDQo+IEhlbmNlIG15IGVhcmxpZXIg
cmVxdWVzdDogSWYgd2UgYWNjZXB0IHRoaXMsIHNheSAoYW5kIGJyaWVmbHkganVzdGlmeSkg
dGhpcw0KPiBpbiBhIGNvZGUgY29tbWVudC4NCg0KT2theSwgd291bGQgeW91IGJlIGZpbmUg
d2l0aDoNCg0KICAgTm90ZSB0aGF0IHRoaXMgY2hlY2sgd29uJ3QgZ3VhcmFudGVlIHRoYXQg
YSBkb21haW4ganVzdCBnb2luZyBkb3duIGNhbid0IGJlDQogICBzZXQgYXMgdGhlIGhhbmRs
aW5nIGRvbWFpbiBvZiBhIHZpcnEsIGFzIHRoZSBpc19keWluZyBpbmRpY2F0b3IgbWlnaHQg
Y2hhbmdlDQogICBqdXN0IGFmdGVyIHRlc3RpbmcgaXQuDQogICBUaGlzIGlzbid0IGdvaW5n
IHRvIGJlIGEgbWFqb3IgcHJvYmxlbSwgYXMgY2xlYXJfZ2xvYmFsX3ZpcnFfaGFuZGxlcnMo
KSBpcw0KICAgZ3VhcmFudGVlZCB0byBydW4gYWZ0ZXJ3YXJkcyBhbmQgaXQgd2lsbCByZXNl
dCB0aGUgaGFuZGxpbmcgZG9tYWluIGZvciB0aGUNCiAgIHZpcnEgdG8gdGhlIGhhcmR3YXJl
IGRvbWFpbi4NCg0KDQpKdWVyZ2VuDQo=
--------------vnLD0vG1EgF5CVTCqB936Kgl
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

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

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

--------------vnLD0vG1EgF5CVTCqB936Kgl--

--------------A09bGMHrSfoT0uS5G90NMND3--

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

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

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmd9TsYFAwAAAAAACgkQsN6d1ii/Ey9v
qgf+LNXtZ7K/ikllfzcU+az50yus+nrYwyiNRrGPOQSVE22IUSxfVBBPMHcnLc/HOiXUQKQN8IXz
yUMn1qaszRegM7yXQOCXbcDwAUkm0n1bIEgmg1J2CaAvnFFD5/xyBROwahiNO8n/rV/l3IvtqV6F
jzYO+dR4ePByDmkFHAOQ85i9CcHIp+CSTPqMiV0+1LVwsK8tmfy7UwotDBqYjTx28BmUUEi8+eZg
y+SVsttZTnmFzq2zWdDT/neUyvRIdXDUJLXwaGUN5MDHu6XAqZ6mxhHCH2RWcHTpH3fag5hBhoeE
Q8ZStf88KbY0kuoduXzUtXZz88OR1Laf04J3nBNOfA==
=GGrU
-----END PGP SIGNATURE-----

--------------PjYgUMBIqRFr7o8WkLYEGF5M--


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 15:58:14 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 15:58:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866594.1277904 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVBy9-0005Tr-HH; Tue, 07 Jan 2025 15:58:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866594.1277904; Tue, 07 Jan 2025 15:58:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVBy9-0005Tk-E6; Tue, 07 Jan 2025 15:58:13 +0000
Received: by outflank-mailman (input) for mailman id 866594;
 Tue, 07 Jan 2025 15:58:11 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=1r68=T7=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVBy7-0005TP-Kb
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 15:58:11 +0000
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com
 [2a00:1450:4864:20::329])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 30e27445-cd10-11ef-99a4-01e77a169b0f;
 Tue, 07 Jan 2025 16:58:09 +0100 (CET)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-436202dd7f6so178120455e9.0
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 07:58:09 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c8acb85sm50358768f8f.103.2025.01.07.07.58.08
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 07:58:08 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 30e27445-cd10-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736265489; x=1736870289; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=c0o9daT+a94PO+d5RoEpoktH06ZlvJMExcQYADSfY+I=;
        b=Y9uNAP59ViqOtC5cvxig3wwHpzKsABtu6sDupf6QVnkAtsZm3mZC2OdFStNEx22yN5
         M7BvSdNX6QtUDFwudCnq1SQ9vn0FHfNJisPnfKWfXjmluXD0YzMQ3Hu3TBlof5nXkEl8
         yrS7I4pi9Q1ywz0sJqzRc5NQ3f5RAhEq5/uW7WtFU+nAQl+cmTfZvn+1mztOaLAqlOHe
         88TRSUC2ocqd5HAPmM9sCoAa45Zb9qTursFJG3H7e2YpqquoPZM3ulkKxZDLgjHlB4D5
         pPDjF4JmPSgxEUkEAnpVC6OUOdjjFbFnTJmQQuvehP0UwiMrL2k630mvHv2lWV1txrF/
         ZFBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736265489; x=1736870289;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=c0o9daT+a94PO+d5RoEpoktH06ZlvJMExcQYADSfY+I=;
        b=CsKZ3MlIB3ap2P64ck99G01PGK8uGBW/dwGHBoCu3btQJIIEcEa/IK0wq4rdIN1Aqb
         NiWd2H1eOduNsxwslOsopB7e5pcY4S2sFboUwjj2tHJgVi0sE+uJqG1hpZCLI+DHN3Be
         YrhW+HxC+TGnORBYX0X3dFofI/qXYKyHW2GJSjeDld7toQF8yoS1WCM/w3wfHSLxBLdc
         RnZjVwANJmoeD0CCYqYIxplTmmn0RPhK21dhLlfsz3gR60C+Fe8Qmz4pPm3oItN8NBVn
         cfF+arphwS3t/XDTHmzgVIdd8bXC0idF4S5H97W9Od8wZpjfY7KZ/kLGPXgUjEniRFbT
         6KJQ==
X-Forwarded-Encrypted: i=1; AJvYcCWsIyMdiRXQCRrcjNKduYW0W7Uklaezqttt63NpnSy/CiMhcSv8aADhKmwEzdxVFL2kY9X/gwQYnPE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzU9CX2zjfXX5k6u9pabbBz7L5g4EnyDFyxqqyaVaPQ1dnvsStU
	GJhd5F2RdjJL1NtT3Xa62xwHwrg1tw5NO1f0EFECXq97B4rhDYePkpJoi4Ww7g==
X-Gm-Gg: ASbGncuYY8CZxGvyzRabVL/6mLO8+wKLfaSyn2FU8ctcAa1ih7AQSjkEN8Vb8/25SBT
	fqmp6xnSIcJbcGkAVOjhAw9igc5r0/mC/L5hEsvi12Olh1DPhuOtaSPofIObjH8W+AKWrOHoci8
	suaZZQ9SRkUEUbkRQArhFicdHvkmoKufsZEhI2fdp3U75fw2iDxxZ+OD4/TCzjhjzNJ7rWJTHBo
	Q3K9Er2Hh6PqNNWgWwh7WKjitqRZMA3wR7WeJnhZnCYQlnIbqFBamjnkLOu+OENK4894eYnLv9G
	WF8/ZHO1EWwGMveYCSR+F0ittqG/hEzYlApEeuyiYg==
X-Google-Smtp-Source: AGHT+IHl2hEu23r0pAHgLIp5OcEqmPIPzKt7ndAJAulEaSb/TN0l1PhVPyoq4NLoW4ZtylZMC1NFQg==
X-Received: by 2002:a5d:5f56:0:b0:386:1cd3:8a00 with SMTP id ffacd0b85a97d-38a223f5b41mr60793957f8f.40.1736265488988;
        Tue, 07 Jan 2025 07:58:08 -0800 (PST)
Message-ID: <fb1b00fe-5740-4c0e-81d9-ec9fd9a4a1c3@suse.com>
Date: Tue, 7 Jan 2025 16:58:07 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4] vpci: Add resizable bar support
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Cc: Jiqian Chen <Jiqian.Chen@amd.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>, Huang Rui <ray.huang@amd.com>,
 xen-devel@lists.xenproject.org
References: <20241219052143.3161332-1-Jiqian.Chen@amd.com>
 <d904c816-da83-418a-9bff-9988660af546@suse.com>
 <Z308fGa1daaM62Rf@macbook.local>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <Z308fGa1daaM62Rf@macbook.local>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 07.01.2025 15:38, Roger Pau Monné wrote:
> On Tue, Jan 07, 2025 at 11:06:33AM +0100, Jan Beulich wrote:
>> On 19.12.2024 06:21, Jiqian Chen wrote:
>>> --- /dev/null
>>> +++ b/xen/drivers/vpci/rebar.c
>>> @@ -0,0 +1,131 @@
>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>> +/*
>>> + * Copyright (C) 2024 Advanced Micro Devices, Inc. All Rights Reserved.
>>> + *
>>> + * Author: Jiqian Chen <Jiqian.Chen@amd.com>
>>> + */
>>> +
>>> +#include <xen/sched.h>
>>> +#include <xen/vpci.h>
>>> +
>>> +static void cf_check rebar_ctrl_write(const struct pci_dev *pdev,
>>> +                                      unsigned int reg,
>>> +                                      uint32_t val,
>>> +                                      void *data)
>>> +{
>>> +    struct vpci_bar *bar = data;
>>> +    uint64_t size = PCI_REBAR_CTRL_SIZE(val);
>>> +
>>> +    if ( bar->enabled )
>>> +    {
>>> +        /*
>>> +         * Refuse to resize a BAR while memory decoding is enabled, as
>>> +         * otherwise the size of the mapped region in the p2m would become
>>> +         * stale with the newly set BAR size, and the position of the BAR
>>> +         * would be reset to undefined.  Note the PCIe specification also
>>> +         * forbids resizing a BAR with memory decoding enabled.
>>> +         */
>>> +        if ( size != bar->size )
>>> +            gprintk(XENLOG_ERR,
>>> +                    "%pp: refuse to resize BAR with memory decoding enabled\n",
>>> +                    &pdev->sbdf);
>>> +        return;
>>> +    }
>>> +
>>> +    if ( !((size >> PCI_REBAR_SIZE_BIAS) & bar->resizable_sizes) )
>>> +        gprintk(XENLOG_WARNING,
>>> +                "%pp: new size %#lx is not supported by hardware\n",
>>> +                &pdev->sbdf, size);
>>> +
>>> +    bar->size = size;
>>
>> Shouldn't at least this be in an "else" to the if() above?
> 
> I think this was already raised in a previous version - would be good
> to know how real hardware behaves when an invalid size is set.  Is the
> BAR register still reset?

I'm pretty sure what happens is undefined. I'd expect though that the
BAR size then doesn't change. Which would require the above assignment
to not be unconditional.

>>> +static int cf_check init_rebar(struct pci_dev *pdev)
>>> +{
>>> +    uint32_t ctrl;
>>> +    unsigned int nbars;
>>> +    unsigned int rebar_offset = pci_find_ext_capability(pdev->sbdf,
>>> +                                                        PCI_EXT_CAP_ID_REBAR);
>>> +
>>> +    if ( !rebar_offset )
>>> +        return 0;
>>> +
>>> +    if ( !is_hardware_domain(pdev->domain) )
>>> +    {
>>> +        printk(XENLOG_ERR "%pp: resizable BARs unsupported for unpriv %pd\n",
>>> +               &pdev->sbdf, pdev->domain);
>>> +        return -EOPNOTSUPP;
>>> +    }
>>> +
>>> +    ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL(0));
>>> +    nbars = MASK_EXTR(ctrl, PCI_REBAR_CTRL_NBAR_MASK);
>>> +
>>> +    for ( unsigned int i = 0; i < nbars; i++ )
>>> +    {
>>> +        int rc;
>>> +        struct vpci_bar *bar;
>>> +        unsigned int index;
>>> +
>>> +        ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL(i));
>>> +        index = ctrl & PCI_REBAR_CTRL_BAR_IDX;;
>>
>> Nit: No double semicolons please.
>>
>>> +        if ( index >= PCI_HEADER_NORMAL_NR_BARS )
>>> +        {
>>> +            /*
>>> +             * TODO: for failed pathes, need to hide ReBar capability
>>> +             * from hardware domain instead of returning an error.
>>> +             */
>>> +            printk(XENLOG_ERR "%pd %pp: too big BAR number %u in REBAR_CTRL\n",
>>> +                   pdev->domain, &pdev->sbdf, index);
>>> +            return -EINVAL;
>>
>> With the TODO unaddressed, is it actually appropriate to return an error
>> here? Shouldn't we continue in a best effort manner? (Question also to
>> Roger as the maintainer.)
> 
> It would indeed be better to shallow the error and return 0, however
> the handlers added in this loop would need removing if no error is
> returned.

Would they? For those BARs where things worked fine I would think they
could be left in place.

>>> +        }
>>> +
>>> +        bar = &pdev->vpci->header.bars[index];
>>> +        if ( bar->type != VPCI_BAR_MEM64_LO && bar->type != VPCI_BAR_MEM32 )
>>> +        {
>>> +            printk(XENLOG_ERR "%pd %pp: BAR%u is not in memory space\n",
>>> +                   pdev->domain, &pdev->sbdf, index);
>>> +            return -EINVAL;
>>
>> Same question here then.
>>
>>> +        }
>>> +
>>> +        rc = vpci_add_register(pdev->vpci, vpci_hw_read32, vpci_hw_write32,
>>> +                               rebar_offset + PCI_REBAR_CAP(i), 4, NULL);
>>> +        if ( rc )
>>> +        {
>>> +            printk(XENLOG_ERR "%pd %pp: fail to add reg of REBAR_CAP rc=%d\n",
>>> +                   pdev->domain, &pdev->sbdf, rc);
>>> +            return rc;
>>> +        }
>>> +
>>> +        rc = vpci_add_register(pdev->vpci, vpci_hw_read32, rebar_ctrl_write,
>>> +                               rebar_offset + PCI_REBAR_CTRL(i), 4, bar);
>>> +        if ( rc )
>>> +        {
>>> +            printk(XENLOG_ERR "%pd %pp: fail to add reg of REBAR_CTRL rc=%d\n",
>>> +                   pdev->domain, &pdev->sbdf, rc);
>>> +            return rc;
>>> +        }
>>> +
>>> +        bar->resizable_sizes |=
>>> +            (pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CAP(i)) >>
>>> +             PCI_REBAR_CAP_SHIFT);
>>
>> Imo this would better use = in place of |= and (see also below) would also
>> better use MASK_EXTR() just like ...
>>
>>> +        bar->resizable_sizes |=
>>> +            ((uint64_t)MASK_EXTR(ctrl, PCI_REBAR_CTRL_SIZES) <<
>>> +             (32 - PCI_REBAR_CAP_SHIFT));
>>
>> ... this one does.
>>
>> Further I think you want to truncate the value for 32-bit BARs, such that
>> rebar_ctrl_write() would properly reject attempts to set sizes of 4G and
>> above for them.
> 
> For the hardware domain at least we shouldn't add such restriction -
> Xen in general allows dom0 to do things it would otherwise consider
> invalid, in case it has to deal with hardware quirks.
> 
> Rather than reject Xen should just print a warning that the sizes
> supported by the device are likely invalid.

And do what when memory decode is re-enabled on the device? What size a
P2M update should it do then?

>>> --- a/xen/drivers/vpci/vpci.c
>>> +++ b/xen/drivers/vpci/vpci.c
>>> @@ -232,6 +232,12 @@ void cf_check vpci_hw_write16(
>>>      pci_conf_write16(pdev->sbdf, reg, val);
>>>  }
>>>  
>>> +void cf_check vpci_hw_write32(
>>> +    const struct pci_dev *pdev, unsigned int reg, uint32_t val, void *data)
>>> +{
>>> +    pci_conf_write32(pdev->sbdf, reg, val);
>>> +}
>>
>> This function is being added just to handle writing of a r/o register.
>> Can't you better re-use vpci_ignored_write()?
> 
> But vpci_ignored_write() ignores the write, OTOH here the write is
> propagated to the hardware.

Right, just for the hardware to drop it. I wouldn't have commented if
the function needed to do things like this already existed. Adding yet
another cf_check function just for this is what made me give the remark.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 15:59:52 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 15:59:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866602.1277914 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVBzg-00062z-RX; Tue, 07 Jan 2025 15:59:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866602.1277914; Tue, 07 Jan 2025 15:59:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVBzg-00062s-OH; Tue, 07 Jan 2025 15:59:48 +0000
Received: by outflank-mailman (input) for mailman id 866602;
 Tue, 07 Jan 2025 15:59:48 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=1r68=T7=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVBzg-00062m-9t
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 15:59:48 +0000
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com
 [2a00:1450:4864:20::32b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6a8f8bb9-cd10-11ef-99a4-01e77a169b0f;
 Tue, 07 Jan 2025 16:59:46 +0100 (CET)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-435f8f29f8aso113810915e9.2
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 07:59: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
 5b1f17b1804b1-43661289995sm599318425e9.36.2025.01.07.07.59.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 07:59:45 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 6a8f8bb9-cd10-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736265586; x=1736870386; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=jWyMuhFbKW6KhagEj1mLFXaD19omX2Qj5fafAf4eHd0=;
        b=QMVQs4z3k1owzVAXPODhtnVg3V3TJ+M6LjmVjPdkJTJfxukBZt7AZ+4U12OWdDwJeO
         TdRv4Q55Vrv/+rIpNUBNtxESLxJzc64drKOeHKSU+nyH17HD5Um78bdKcXZvenknPNQ1
         qaKjrnGLHLKvyhWrnNJ39ZjMEi6IMW1ghWrR0QoxtXVwGNzpVCx2jZgSQwNlO4odzO8i
         EFZiM+CUJWMb6EEcl03MF0YVxdSIIZNcGcv3P1qBXsXSYT2mGOpCPjCUjDRUspJ2CGTz
         SqNoK/tT4abWqWlz6G42nSb+ClZN7Uy6H7tdKDKuJg4FHkR9O6ZDzbFpwLssyiY1krA6
         z8yg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736265586; x=1736870386;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=jWyMuhFbKW6KhagEj1mLFXaD19omX2Qj5fafAf4eHd0=;
        b=Wf4U8KRDiNTnUOwOW2GHcku0afvEmIhPVdxfDi8BuDzZzm7xzPZW/KgQvrTWlULkRr
         EML9fBqF9uZ7bwQMOeJ8ynye7mPueK2zFf9TwO+KWI+Im9QOByg8LIRUVUsC7Ks97TB4
         w7xuGjqcO/FOqBf1KoBlHxfpRJ98j1lbFooIIQBSZISoN1eUinf85r95ikcSFguLIdWD
         ch6g1/ca8O6zlsEzCiUNVMS4HKuxjRh3wcaLDbpFv/RL81hKVqCUxjV5m5udBKWBXzL2
         DWQ4IfTgGgaZrBwjui2jcvMCPJxFRsboxl/UlLFFDa4ga1OMhzldfg8cnJ7CvEwzTHxS
         nIWg==
X-Forwarded-Encrypted: i=1; AJvYcCVS+cfkSnBSsxtlymPdUWV/p0t4Y/RgTwHN+QU3zEOn1Mr/o85bDN9UuV3Y4fBwcwgbWuwrqM4oqXA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyKG5wnMWFg8d8gZ3JqhpjgCtbsQIW+o6gHppvy1Cglm8XpfZk0
	qk/O2ZnGbDpfax4f+Dp3JviFEXSaNKw2IszkO14SlPkeubAu4t1CanaUapPl0A==
X-Gm-Gg: ASbGncthE05XK+V1KRDzXWZXMEAexBaBCrm/g7r9ZF9UrKRm6/bP+va51MgWEMwKews
	/+EkYcq1tEdWB/kA1+jdHZkhaFiOyCgBmzmk5G/dhYDD5a5Qs2XvKCbiAIqfWtNcb22TnoyC5Mh
	BzK4tgoJNw89XBEBa0UA8OSQE+Qpc0gsHQNjRjzPMbaTCAuwiKdJSKfEtWNlGttt5BHLEuUS6Uv
	Vl93wtBbN67pf/HLTBwRj81c/ZjaeB3uY5Ecxk2xwtIA1rdvCmC0kuAhRsyFSB6H3MksG45WwXO
	cuGesifuCnH4UbgYrdZtdsUssTV1p4SLKNLMBO3DDA==
X-Google-Smtp-Source: AGHT+IGY2plrmHVDziKy/i3CwkZhUjkzhTpHz45s7M7ztuUIibwY3zD1pdy1xEjm9FisG5ZEc8UnLg==
X-Received: by 2002:a7b:c459:0:b0:434:ff30:a165 with SMTP id 5b1f17b1804b1-436712441e2mr476774675e9.8.1736265585851;
        Tue, 07 Jan 2025 07:59:45 -0800 (PST)
Message-ID: <e6def4e3-30d8-446e-9961-475602cdc46a@suse.com>
Date: Tue, 7 Jan 2025 16:59:44 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 1/7] xen/events: fix race with
 set_global_virq_handler()
To: Juergen Gross <jgross@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <20250107101711.5980-1-jgross@suse.com>
 <20250107101711.5980-2-jgross@suse.com>
 <c7ed9380-a4a1-4576-af56-2949d80cfd92@suse.com>
 <c00886ec-184c-4a82-8093-4fc9b470ea1b@suse.com>
 <270984e8-2296-48b9-b45c-92ab28b4e6dd@suse.com>
 <b508c054-5706-4fcc-b8f8-738775530022@suse.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <b508c054-5706-4fcc-b8f8-738775530022@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 07.01.2025 16:56, Juergen Gross wrote:
> On 07.01.25 16:49, Jan Beulich wrote:
>> On 07.01.2025 16:37, Juergen Gross wrote:
>>> On 07.01.25 16:23, Jan Beulich wrote:
>>>> On 07.01.2025 11:17, Juergen Gross wrote:
>>>>> --- a/xen/common/event_channel.c
>>>>> +++ b/xen/common/event_channel.c
>>>>> @@ -979,6 +979,7 @@ void send_global_virq(uint32_t virq)
>>>>>    int set_global_virq_handler(struct domain *d, uint32_t virq)
>>>>>    {
>>>>>        struct domain *old;
>>>>> +    int rc = 0;
>>>>>    
>>>>>        if (virq >= NR_VIRQS)
>>>>>            return -EINVAL;
>>>>> @@ -992,14 +993,23 @@ int set_global_virq_handler(struct domain *d, uint32_t virq)
>>>>>            return -EINVAL;
>>>>>    
>>>>>        spin_lock(&global_virq_handlers_lock);
>>>>> -    old = global_virq_handlers[virq];
>>>>> -    global_virq_handlers[virq] = d;
>>>>> +
>>>>> +    if ( d->is_dying != DOMDYING_alive )
>>>>> +    {
>>>>> +        old = d;
>>>>> +        rc = -EINVAL;
>>>>> +    }
>>>>
>>>> While I can see how this eliminates the zombie domain aspect, this doesn't
>>>> fully eliminate the race. Doing so would require (also) using the domain's
>>>> event lock. Assuming we're okay with the remaining race, imo a code comment
>>>> would be needed to state this (including the fact that it's then
>>>> unpredictable whether this operation might still succeed for a domain
>>>> already having d->is_dying != DOMDYING_alive).
>>>
>>> AFAIU you mean that it is still possible to set a domain to handle a virq
>>> when it is in the process of going down, especially if is_dying is set just
>>> after it has been tested to be DOMDYING_alive?
>>>
>>> I don't see this being a problem, as the same would happen if the domain
>>> would go down just a millisecond later. This is something we will never be
>>> able to handle.
>>
>> Right, but the sequence of events in the case you mention is different: The
>> insertion into the array would still happen while the domain isn't marked
>> dying.
>>
>>> And after all the call of clear_global_virq_handlers() will now reset the
>>> handling domain to the hardware domain in all cases.
>>
>> Of course, but in the meantime an event may be sent to such a domain already
>> marked dying. That likely isn't going to cause problems, but is unexpected
>> with what description here says is being addressed.
>>
>>>> Plus the way you do it the early success path remains; ideally that case
>>>> would also fail for an already dying domain.
>>>
>>> Same again: clear_global_virq_handlers() will reset the handling domain.
>>
>> Right.
>>
>> In summary: As indicated, we may be okay with the remaining race, but then
>> we also should be making clear that we've decided to leave it at that.
>> Hence my earlier request: If we accept this, say (and briefly justify) this
>> in a code comment.
> 
> Okay, would you be fine with:
> 
>    Note that this check won't guarantee that a domain just going down can't be
>    set as the handling domain of a virq, as the is_dying indicator might change
>    just after testing it.
>    This isn't going to be a major problem, as clear_global_virq_handlers() is
>    guaranteed to run afterwards and it will reset the handling domain for the
>    virq to the hardware domain.

Reads okay, thanks.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 16:00:27 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 16:00:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866608.1277924 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVC0J-0007w5-2j; Tue, 07 Jan 2025 16:00:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866608.1277924; Tue, 07 Jan 2025 16:00:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVC0I-0007vy-W7; Tue, 07 Jan 2025 16:00:26 +0000
Received: by outflank-mailman (input) for mailman id 866608;
 Tue, 07 Jan 2025 16:00:26 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=aJXC=T7=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tVC0I-0006Jb-6c
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 16:00:26 +0000
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com
 [2a00:1450:4864:20::42c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 81c0e416-cd10-11ef-a0df-8be0dac302b0;
 Tue, 07 Jan 2025 17:00:25 +0100 (CET)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-385ddcfc97bso13235370f8f.1
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 08:00:25 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c847dabsm50113190f8f.59.2025.01.07.08.00.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 08:00:24 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 81c0e416-cd10-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736265625; x=1736870425; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=gEgQIJ7TVFn9cHGSs2Q+5ac3V5udTqHVni+jQdaG1Io=;
        b=VHqP/3mV5Od4uzprFUfo1LDyq4ilVp8yFNrDbZw4sWUcyIl6mC+aeoj0sCTGaN2TBk
         3dOtXk9GRXW3XZH7yLvDsyXqZAnJ0Bm7QH93ePtUJIVoych3dUOR3PtaRdpEoPxiY/r4
         XDnep6EL54Q/xFy2flvX/SWhXh88U7mpLksqQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736265625; x=1736870425;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=gEgQIJ7TVFn9cHGSs2Q+5ac3V5udTqHVni+jQdaG1Io=;
        b=BsRw6nLXpPKOrXNrNOH5Z6zZ1hGm0KFSivPyxlxqhVqYSH0QUtuFoU/Arf0d4WfkLb
         U0QL1pgHHtzVaYkDZlFdX02KSR2CPJTapYhM5pFVY4qZAmlpL+eNTWAwEbYU1SDa1R2u
         8tZkHduiCEt+DLv/UTEGn94xuM+TBQ9B3VkhCbg28M0sabDFXtRu1Kyjjts3B9N3QS8E
         QqchUw0DexwFRCPyjZBMQwqDVEvd73wLMLeb7iKMb0cSkkUiDeKo/d3sIPuMBNDYFusN
         Gy3nmg/HQIHIl92Zg9gK9ByWeaEZ5kvtU5Me/N88JcGI5vydORZaKWn6yne2dS1U2Gsn
         sDsQ==
X-Forwarded-Encrypted: i=1; AJvYcCVY0NuabVfgevY4KPMF1hZfdOvYi0hjAO49qKl/j7inxep7Zm/fJHMaSAvfTm3Ir1TKrRxuxTRzgTE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyB7Fjf3HEVZcRIQ9ggKVcLbBJ9EnRf2Zals+bMIg63lgM/59J4
	T1TnX+IDIKZkiYnxJoLC5oukatWJCSzGK0XE/algUM4li4fOwzyNEhIczCfN83XyOQn/7scdVOx
	VVcX8KQ==
X-Gm-Gg: ASbGnctw/NGTiF094OT6tqgVFA85nmxe6GGHsTqEMtwHu8YdIEUK6xbr7C4EIlmf21D
	CFg/9Zis3PhslODPzAmRP6BPdGtI/A9SwHkdUxewvigxXSvAizvzOn957qzFIRO+p3FFylGO+/d
	8Zr/axqi3bRPy+s9HUpp7Yvmz+AD4KC0Z52EVDnTm8FR7XHo5GDq3NY034u5fDeXbHoxAevCyHk
	7KprL1mXZpNfKed57/5tAd2Emlg4/Em0hxsQKh62IcrSX9mfh+fIqw0iXgE1sXXjM73CKcu++A4
	CrkFJS6+gZJph24eZ5hz
X-Google-Smtp-Source: AGHT+IGq7CuXdeGSayZvelDeWu27PXSD8YGvIVVrzRovIGhl3Dpnv7h22S5fdbWWISDlwYRUACxhSw==
X-Received: by 2002:a5d:6daf:0:b0:385:fa33:29ed with SMTP id ffacd0b85a97d-38a223ffb65mr49414075f8f.47.1736265624579;
        Tue, 07 Jan 2025 08:00:24 -0800 (PST)
Message-ID: <21e306c0-2edc-44b0-88c0-0d4ee85e9b14@citrix.com>
Date: Tue, 7 Jan 2025 16:00:23 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86emul: correct put_fpu()'s segment selector handling
To: Jan Beulich <jbeulich@suse.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <81428267-e963-4403-989d-d96fb0b59ffc@suse.com>
 <8db5b675-385f-4ea7-a2e9-7a8a54d96f72@citrix.com>
 <526672ec-4140-4c51-b67a-3b4b803314c2@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <526672ec-4140-4c51-b67a-3b4b803314c2@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 07/01/2025 3:41 pm, Jan Beulich wrote:
> On 07.01.2025 16:37, Andrew Cooper wrote:
>> On 07/01/2025 2:33 pm, Jan Beulich wrote:
>>> All selector fields under ctxt->regs are (normally) poisoned in the HVM
>>> case, and the four ones besides CS and SS are potentially stale for PV.
>>> Avoid using them in the hypervisor incarnation of the emulator, when
>>> trying to cover for a missing ->read_segment() hook.
>>>
>>> To make sure there's always a valid ->read_segment() handler for all HVM
>>> cases, add a respective function to shadow code, even if it is not
>>> expected for FPU insns to be used to update page tables.
>>>
>>> Fixes: 0711b59b858a ("x86emul: correct FPU code/data pointers and opcode handling")
>>> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>> ---
>>> The code comment may want adjusting in the course of FRED work.
>> It compiles when displacing my temporary patch in the FRED branch.  I've
>> not got the ABI compatibility in userspace working yet, but
>> regs->{ds,es,fs,gs} will be staying, so the #else case should be fine
>> (assuming they're populated properly).
>>
>> So, tentatively, Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Thanks.
>
>> That said, I think it would be nicer to see about excluding the FPU in
>> these cases.  Both cases lacking read_segment() hooks are pagetable
>> emulation, and I'd say it's more likely to be code corruption than there
>> actually being x87 instructions in the middle of a dual 32bit PAE update.
> I considered this case, but decided against going this route. We shouldn't
> be stricter than necessary towards what we permit guests to do, however odd
> it might look to us.

I suppose so, but then I wonder if we ought to be setting up more
infrastructure by default for emulations.

We've got an awful lot of the emulator which has fallback paths upon
fallback paths, and probably is not as well tested as it ought to be.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 16:07:52 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 16:07:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866618.1277934 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVC7Q-0001Eu-0f; Tue, 07 Jan 2025 16:07:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866618.1277934; Tue, 07 Jan 2025 16:07:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVC7P-0001En-Sd; Tue, 07 Jan 2025 16:07:47 +0000
Received: by outflank-mailman (input) for mailman id 866618;
 Tue, 07 Jan 2025 16:07: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 <SRS0=Qdqe=T7=suse.com=jgross@srs-se1.protection.inumbo.net>)
 id 1tVC7O-0001Eh-7Y
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 16:07:46 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8740dbe5-cd11-11ef-a0df-8be0dac302b0;
 Tue, 07 Jan 2025 17:07:45 +0100 (CET)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-aa696d3901bso2116110666b.1
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 08:07:44 -0800 (PST)
Received: from ?IPV6:2003:e5:8731:2800:842d:42a0:5992:3595?
 (p200300e587312800842d42a059923595.dip0.t-ipconnect.de.
 [2003:e5:8731:2800:842d:42a0:5992:3595])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0eae4338sm2370432666b.86.2025.01.07.08.07.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 08:07:42 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8740dbe5-cd11-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736266063; x=1736870863; darn=lists.xenproject.org;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=faoAWuGZisMdWRHtzZIvW/ueHzLPZWYcN2m9rB3uDbY=;
        b=TkRQYC5Y94sL4J2hyt6NHGR3WoBt7suH87HnKuH5ucpa5+ryZltl4vLpysPdskbSn8
         Kus/GnTG1F/zzNy61Jotc39mBZNTFp/5PGsEu79P3arIWr3zfPKBc6zU0yaF3XsCLYNz
         3HFyipz43kQBKRAY0kfCD0z0IKTTZv/yi0NEw4DbU+JHArRiskRMXAnRiNtaLPY12spD
         lvisKFht7Qrbfzs4Ge9OOo7I/UCsB4DkY7XMt3SgktBiEDMxJmP2BXGrMUe2ThWjrzCC
         yO7ds3nH+bf5F8Ny3G2Aro/PB35+N9EadqUK0M+8J68bRcyMqnzSgdQrIL6mWAxlxB16
         3Buw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736266063; x=1736870863;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=faoAWuGZisMdWRHtzZIvW/ueHzLPZWYcN2m9rB3uDbY=;
        b=J9XRbqOmAMHG5YlW18+e42QPdQFz7Ou7fcpjMAEVUlq3BlnXoNLCyM6XPCZgSNRYf5
         NMHIvIeF5n+Fh4ffm5iHKmB+vuSnLLcU0pHv2Lsxrc18LlU5EbnMRlMmR6ufGTxR0JYH
         vwwkGWNE7zPIUY8Dk1zTsBrecd6AzrKx7G8VaEcEALavCrOsI+kZ8McMK9TlIuN5u+5P
         RoruCQwJ46p8FZ1Rrfm740TbTvkdjGKVbe3c08LZcphttg4Cf+XaOOIiS1KG5i0caLf/
         PlKGt91obm//oH+rYMx16lSAozyIsNZudKScQy/yFZ+Hv+bWZF275oTaFPfDr35H6TGZ
         AVCQ==
X-Forwarded-Encrypted: i=1; AJvYcCVzxDSpEiiSD64zaEBN0aZoQuC9H8soz/WI43Mm+uQfE85oQRL9MJ9k8pJIVO4drbzwxgzcxDN8FqE=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yydf/y0M/1AIuE0xHGycloQBEc3Fl6eDWHVtOLh5d2JaX3r7e/s
	JnuSX8yv91JovIbJShwRSROodNxm6aosHAJmMHKDR+N7Zj4i0NDzprEID8tP3oU=
X-Gm-Gg: ASbGnctYPMpAliOPysI+abl6TaB5dV0XMi1R1UAgMaNQwkvGE9cIQ0moy3o05LY7Wwj
	MIfTfcDWvqu77Esc1/CWK0ORF5IqY1BjvyIdqEAQClAm6xjppS9oAlDwApRZTOYM5BaRqNihPqB
	2WDbPO7sr2JOMh1wtPbAscvZNfJ9iO690aHF3xxVhrfQaqfAL3DxuBCCcyY5yW+fuHn6u3U1jZm
	QfL8lll126wkZm+dQGH6bSPmmP3HNUCHkjLlAn/56D5XMAaUTgGBr29Er8ZPkgyFcLicBw2N2S/
	9obZYoYhEHp7p7gZeLLIwoeD+X8NIaqK0JxFKhUW+UY/BihVngvLql6vB0S+oUpXfyXqNOnWoA+
	/zMdtfQ==
X-Google-Smtp-Source: AGHT+IHaI+XL1aa6Z36PHVwPaX8gEUK4eYYmQ59xnpHKmUhXDGTsr1aQROmxYVjri4VcQcUrYfgUgg==
X-Received: by 2002:a17:907:2d1f:b0:aa6:966d:3f93 with SMTP id a640c23a62f3a-aac2b0a5b51mr5115401066b.23.1736266063241;
        Tue, 07 Jan 2025 08:07:43 -0800 (PST)
Message-ID: <5261716e-a2f4-4423-bb8d-17e36bf34538@suse.com>
Date: Tue, 7 Jan 2025 17:07:41 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 2/7] xen/events: don't allow binding a global virq from
 any domain
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <20250107101711.5980-1-jgross@suse.com>
 <20250107101711.5980-3-jgross@suse.com>
 <577427ff-61e2-4fc9-8853-a7eec3f69bb6@suse.com>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <577427ff-61e2-4fc9-8853-a7eec3f69bb6@suse.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------nFyGG4zqLmpyQ60y39at8RT9"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------nFyGG4zqLmpyQ60y39at8RT9
Content-Type: multipart/mixed; boundary="------------uNQq90XzzdXj68dOCyYUnEEB";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
Message-ID: <5261716e-a2f4-4423-bb8d-17e36bf34538@suse.com>
Subject: Re: [PATCH v6 2/7] xen/events: don't allow binding a global virq from
 any domain
References: <20250107101711.5980-1-jgross@suse.com>
 <20250107101711.5980-3-jgross@suse.com>
 <577427ff-61e2-4fc9-8853-a7eec3f69bb6@suse.com>
In-Reply-To: <577427ff-61e2-4fc9-8853-a7eec3f69bb6@suse.com>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------uNQq90XzzdXj68dOCyYUnEEB
Content-Type: multipart/mixed; boundary="------------65jcAYjlhy4M0090fYmFXt9I"

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

T24gMDcuMDEuMjUgMTY6MzQsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAwNy4wMS4yMDI1
IDExOjE3LCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0KPj4gLS0tIGEveGVuL2NvbW1vbi9ldmVu
dF9jaGFubmVsLmMNCj4+ICsrKyBiL3hlbi9jb21tb24vZXZlbnRfY2hhbm5lbC5jDQo+PiBA
QCAtMTIwLDYgKzEyMCwxMyBAQCBzdGF0aWMgdWludDhfdCBnZXRfeGVuX2NvbnN1bWVyKHhl
bl9ldmVudF9jaGFubmVsX25vdGlmaWNhdGlvbl90IGZuKQ0KPj4gICAvKiBHZXQgdGhlIG5v
dGlmaWNhdGlvbiBmdW5jdGlvbiBmb3IgYSBnaXZlbiBYZW4tYm91bmQgZXZlbnQgY2hhbm5l
bC4gKi8NCj4+ICAgI2RlZmluZSB4ZW5fbm90aWZpY2F0aW9uX2ZuKGUpICh4ZW5fY29uc3Vt
ZXJzWyhlKS0+eGVuX2NvbnN1bWVyLTFdKQ0KPj4gICANCj4+ICtzdGF0aWMgc3RydWN0IGRv
bWFpbiAqZ2xvYmFsX3ZpcnFfaGFuZGxlcnNbTlJfVklSUVNdIF9fcmVhZF9tb3N0bHk7DQo+
IA0KPiBOaXQ6IFdoaWxlIHlvdSBtb3ZlIHRoaXMgbGluZSBhcm91bmQsIGl0IHdvdWxkIGJl
IG5pY2UgaWYgdGhlIGF0dHJpYnV0ZQ0KPiBjb3VsZCB0aGVuIGFsc28gbW92ZSB0byBpdHMg
Y2Fub25pY2FsIHBsYWNlIChiZXR3ZWVuIHR5cGUgYW5kIGlkZW50aWZpZXIpLg0KPiANCj4+
ICtzdGF0aWMgc3RydWN0IGRvbWFpbiAqZ2V0X2dsb2JhbF92aXJxX2hhbmRsZXIodW5zaWdu
ZWQgaW50IHZpcnEpDQo+PiArew0KPj4gKyAgICByZXR1cm4gZ2xvYmFsX3ZpcnFfaGFuZGxl
cnNbdmlycV0gPzogaGFyZHdhcmVfZG9tYWluOw0KPj4gK30NCj4+ICsNCj4+ICAgc3RhdGlj
IGJvb2wgdmlycV9pc19nbG9iYWwodW5zaWduZWQgaW50IHZpcnEpDQo+PiAgIHsNCj4+ICAg
ICAgIHN3aXRjaCAoIHZpcnEgKQ0KPj4gQEAgLTQ3OSw4ICs0ODYsMTMgQEAgaW50IGV2dGNo
bl9iaW5kX3ZpcnEoZXZ0Y2huX2JpbmRfdmlycV90ICpiaW5kLCBldnRjaG5fcG9ydF90IHBv
cnQpDQo+PiAgICAgICAqLw0KPj4gICAgICAgdmlycSA9IGFycmF5X2luZGV4X25vc3BlYyh2
aXJxLCBBUlJBWV9TSVpFKHYtPnZpcnFfdG9fZXZ0Y2huKSk7DQo+PiAgIA0KPj4gLSAgICBp
ZiAoIHZpcnFfaXNfZ2xvYmFsKHZpcnEpICYmICh2Y3B1ICE9IDApICkNCj4+IC0gICAgICAg
IHJldHVybiAtRUlOVkFMOw0KPj4gKyAgICBpZiAoIHZpcnFfaXNfZ2xvYmFsKHZpcnEpICkN
Cj4+ICsgICAgew0KPj4gKyAgICAgICAgaWYgKCBnZXRfZ2xvYmFsX3ZpcnFfaGFuZGxlcih2
aXJxKSAhPSBkICkNCj4+ICsgICAgICAgICAgICByZXR1cm4gLUVCVVNZOw0KPiANCj4gSG1t
LiBXaGlsZSB0aGlzIGVsaW1pbmF0ZXMgdGhlIHByb2JsZW0gZm9yIHRoZSBjb21tb24sIHJh
Y2UgZnJlZSBjYXNlLA0KPiB0aGUgaGFuZGxlciBjaGFuZ2luZyByaWdodCBhZnRlciB0aGUg
Y2hlY2sgd291bGQgc3RpbGwgbWVhbiB0aGUgYmluZA0KPiB3b3VsZCBzdWNjZWVkLg0KDQpB
cmUgeW91IGZpbmUgd2l0aCBtZSBhZGRpbmcgYSBwYXJhZ3JhcGggdG8gdGhlIGNvbW1pdCBt
ZXNzYWdlIHNheWluZw0KdGhhdCBhIGZ1dHVyZSBwYXRjaCB3aWxsIGhhbmRsZSB0aGlzIGNh
c2U/DQoNClRoaXMgZnV0dXJlIHBhdGNoIGlzIHBhdGNoIDQgb2YgdGhlIHNlcmllcywgd2hp
Y2ggd2lsbCBuZWVkIHRvIGJlDQptb2RpZmllZCB0byBjaGVjayB0aGUgaGFuZGxpbmcgZG9t
YWluIGluc2lkZSB0aGUgZXZlbnRfbG9jay4NCg0KPiBQbHVzIHRoaXMgd2F5IHlvdSdyZSBi
cmVha2luZyBhIGNhc2UgdGhhdCBhZmFpY3QgaGFzIGJlZW4gd29ya2luZyBzbw0KPiBmYXI6
IFRoZSBiaW5kIGhhcHBlbmluZyBiZWZvcmUgdGhlIHNldHRpbmcgb2YgdGhlIGhhbmRsZXIu
IFdpdGggYSBsb3QNCj4gb2YgdW5yZWxhdGVkIGlmLXMgYW5kIHdoZW4tcyB0aGlzIGNvdWxk
IGUuZy4gYmUgb2YgaW50ZXJlc3Qgd2hlbg0KPiBjb25zaWRlcmluZyBhIHJlLXN0YXJ0YWJs
ZSBYZW5zdG9yZSBkb21haW4uIFRoZSBvbmUgdG8gdGFrZSBvdmVyIGNvdWxkDQo+IHN0YXJ0
IGZpcnN0LCBvYnRhaW4gc3RhdGUgZnJvbSB0aGUgb3JpZ2luYWwgb25lIHdoaWxlIHRoYXQn
cyBzdGlsbA0KPiBhY3RpdmUsIGFuZCBiZSBub21pbmF0ZWQgdGhlIGhhbmRsZXIgb2YgdGhl
IGdsb2JhbCB2SVJRIG9ubHkgaW4gdGhlDQo+IGxhc3QgbW9tZW50Lg0KDQpUaGlzIGlzIGEg
cmFjeSBzaXR1YXRpb24sIHRvby4gSWYgdGhlIG9sZCBkb21haW4gcmVjZWl2ZXMgdGhlIHZp
cnEgYWZ0ZXINCnNlbmRpbmcgdGhlIHN0YXRlLCB0aGlzIHdvdWxkIG5lZWQgdG8gYmUgaGFu
ZGxlZCBieSB0cmFuc2ZlcnJpbmcgdGhlIHZpcnENCmluZm9ybWF0aW9uIHRvIHRoZSBuZXcg
ZG9tYWluLCB3aGljaCBjYW4gcmVzdWx0IGluIGEgbmV2ZXIgZW5kaW5nIHN0b3J5Lg0KDQpU
aGlzIGlzIHRoZSByZWFzb24gd2h5IHRoZSBkb21haW4gc3RhdGUgYml0bWFwIGlzIHJlc2V0
IHRvIGNvbnRhaW4gYWxsDQpleGlzdGluZyBkb21haW5zIHRvIGJlIGZsYWdnZWQgYXMgImNo
YW5nZWQiLCBhcyBvdGhlcndpc2UgYSBjaGFuZ2UgbWlnaHQNCmdldCBsb3N0Lg0KDQpJJ2Qg
cmF0aGVyIGJlIGFibGUgdG8gaGFuZGxlIHRvZGF5J3MgdXNlIGNhc2VzIGluIGEgc2FuZSB3
YXkgdGhhbiB0byB0cnkNCmhhbmRsaW5nIGFueSB3ZWlyZCBmdXR1cmUgdXNlIGNhc2VzIHdo
aWNoIHdlIGRvbid0IGtub3cgeWV0Lg0KDQpJIHRoaW5rIHRvZGF5J3MgYmVoYXZpb3IgaXMg
bW9yZSBvciBsZXNzIGluc2FuZSBhbmQgdGhlIG5ldyBiZWhhdmlvciBpcw0KbXVjaCBlYXNp
ZXIgdG8gdW5kZXJzdGFuZCBhbmQgbW9yZSBpbnR1aXRpdmUuDQoNCg0KSnVlcmdlbg0K
--------------65jcAYjlhy4M0090fYmFXt9I
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

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

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

--------------65jcAYjlhy4M0090fYmFXt9I--

--------------uNQq90XzzdXj68dOCyYUnEEB--

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

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

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmd9UU4FAwAAAAAACgkQsN6d1ii/Ey/H
wwf/d5sr5jBP/VVGWtaEyUa0S+srxVVjBR/QLG5IGDrtxWV17aBxuWDDtr6G/99OCgyZCpjOMoxk
mhteNxF0ywhpr03FW6VQioExOAnquYornLyY1vb1S8BzT3sCysvD0e1JtjlZxEB3MDCoyr9z2gFD
cWbImbYnb8eE4e5O6RrhOmQP/jLUbRYevzvpwRltONy2hLuh2fDXUKiV2Je/eM0CJuDdJB6PKOhY
l8wjq227M/LXECtgVWtgBULiDx0KpbrVG9BtLjbMxSlpDr298RvH7vyrVzFXOs5amJ5x/EnyCOVZ
3/4dZ6NGBpHXSRz+g2cSRucxKV7Q75OJi7Y+wxOY2Q==
=fuky
-----END PGP SIGNATURE-----

--------------nFyGG4zqLmpyQ60y39at8RT9--


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 16:10:12 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 16:10:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866624.1277944 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVC9i-0002gk-Bu; Tue, 07 Jan 2025 16:10:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866624.1277944; Tue, 07 Jan 2025 16:10:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVC9i-0002gd-8v; Tue, 07 Jan 2025 16:10:10 +0000
Received: by outflank-mailman (input) for mailman id 866624;
 Tue, 07 Jan 2025 16:10:09 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Qdqe=T7=suse.com=jgross@srs-se1.protection.inumbo.net>)
 id 1tVC9g-0002gX-SY
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 16:10:08 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id dc6e2a12-cd11-11ef-99a4-01e77a169b0f;
 Tue, 07 Jan 2025 17:10:06 +0100 (CET)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-aa66ead88b3so583083966b.0
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 08:10:06 -0800 (PST)
Received: from ?IPV6:2003:e5:8731:2800:842d:42a0:5992:3595?
 (p200300e587312800842d42a059923595.dip0.t-ipconnect.de.
 [2003:e5:8731:2800:842d:42a0:5992:3595])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0efe46d5sm2411987266b.103.2025.01.07.08.10.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 08:10:06 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: dc6e2a12-cd11-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736266206; x=1736871006; darn=lists.xenproject.org;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=ng2syJtU2x7becFhRtds5M5yUZ1y0CaKDyoZdEKVVfc=;
        b=UtuQQV99gVmJT57C2rnlZvgqiT6xNN+1IMMoMrovkTKJfZeeindKlPiRETo8arVbMd
         u74VisQUtEmQckxFw0Np5y9a8oWFvtHUqxg66U9BuF0JjkTfMdAAmD5p6EaeThVJuAjK
         3n4Kcsyiwrr8BcygfE6XsabSFJKGg5Tr3Ax+zpXLUq2LAzjLDlj/Em5G/cJaiEjfkFBe
         yDVMY24rCAG4MPy7tKZjpt1W2eCZCmhFzwz3PLQWJ1ymC8pkd8Dwfbiq0erDpAjeH9SI
         BrqsMSTi4y3Gn2LNDHE4OPZfHeSe/OtCvDyHFWwVNTbKO9qj2OFY8iOFsbKDXp0aVrMZ
         g7xQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736266206; x=1736871006;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=ng2syJtU2x7becFhRtds5M5yUZ1y0CaKDyoZdEKVVfc=;
        b=HRrJCQ/QEUO8WgsWWZ/JVmh3w3QxXkNqDn4phcYXPMPgRPZ6S+z9FhpCMfjgpVUT61
         xLDFsM9JctT2DrTLCVDOKD2aQ5xyYtfbNSNd+xlOPrP8bZKgADsvCNnfUcfr8g/eSrqR
         16aBO45YOazRNwQ1So11taAyRzTcQKDnJlvBJ1O8isbcwJL0jhFUQGPr3DLbs5AaW8lQ
         vBlVtle6EmsxcsFr0vnm/LY8kH9YM945hnabBvhu8rAIXDQStfc7TLEw3He1Tr3qUvpw
         Ug+dBB2/1MYsuxtWlB8sfw5guqV2Nk1T+LLuplNKDErJCQ/gtnClXJfVFg/zPOzvttpQ
         3qvg==
X-Forwarded-Encrypted: i=1; AJvYcCUwoT1ZVEA6FBG34pOXs+PWs7WWRjc09yE9Wy3h5PemUEwdJZ8b/XHTTAbKRUAfanf0TkVZKzmjOvI=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywwd26foBSv/dl9OgoQ35zVSWwcmHRAs1hihxGR+9rWYpVxU5Cy
	+V3Ey+8cUZpKQMOqPPFlUzVUEw/CNdG66Upm96hUV9OweSEd4WbXJR6clPBYSvM=
X-Gm-Gg: ASbGncu9Ao40m/XGhGK7GQaCGdfOhbgcLBI1HnHl1FSZv0PeFwWQZ7ac/UY39jLYGsq
	hh15aEn+3SXhSONoxh8GcZY9+FCLk23ofa2S5H4faGwVAaqUY3nHerGQ+4ZG6FyHMXYOvCY1ahS
	BpjX3WghgrDe5iKYIPSxSD8m4F4ZBF28WJY7bzGgQG1gT2Z8rgf0jHIddFbCIa546qe7Tt4ukm7
	TMHQNNz9ONc6W7Z++LnH+BATirnY6ofEkRm9VWA1GB3WpREfExUROVb1u1F4ukMdbfEOJdJYm38
	n7Ytomr/IslKuSUfeWvIP+WCZ+a4BsmcTlliLog5E8+UNtld5Qpnu/jUFakQbCjRSMHjL6phkUn
	ApQViIA==
X-Google-Smtp-Source: AGHT+IGcWWegeo6OFbOZRzpsZDzqNhXWJfRA+u6+wPpcp13sc0p6o7411objQxkXvhYQkmqyA7u8FQ==
X-Received: by 2002:a17:906:c14d:b0:aa6:800a:1291 with SMTP id a640c23a62f3a-aac2702af66mr5213171466b.7.1736266206370;
        Tue, 07 Jan 2025 08:10:06 -0800 (PST)
Message-ID: <9b1e6a93-7325-4bc6-83b5-7a80445c39c8@suse.com>
Date: Tue, 7 Jan 2025 17:10:05 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 3/7] xen/events: allow setting of global virq handler
 only for unbound virqs
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <20250107101711.5980-1-jgross@suse.com>
 <20250107101711.5980-4-jgross@suse.com>
 <053a7a26-2dc9-417a-9b91-cce151543050@suse.com>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <053a7a26-2dc9-417a-9b91-cce151543050@suse.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------wMdRpw23gw9FMvVc5BaHYAMR"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------wMdRpw23gw9FMvVc5BaHYAMR
Content-Type: multipart/mixed; boundary="------------mzHVtEx2xVDqn3fHjVdfxQlA";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
Message-ID: <9b1e6a93-7325-4bc6-83b5-7a80445c39c8@suse.com>
Subject: Re: [PATCH v6 3/7] xen/events: allow setting of global virq handler
 only for unbound virqs
References: <20250107101711.5980-1-jgross@suse.com>
 <20250107101711.5980-4-jgross@suse.com>
 <053a7a26-2dc9-417a-9b91-cce151543050@suse.com>
In-Reply-To: <053a7a26-2dc9-417a-9b91-cce151543050@suse.com>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------mzHVtEx2xVDqn3fHjVdfxQlA
Content-Type: multipart/mixed; boundary="------------E3Ru5K2L0Jl2xEAXkgsg4jbD"

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

T24gMDcuMDEuMjUgMTY6MzgsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAwNy4wMS4yMDI1
IDExOjE3LCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0KPj4gWEVOX0RPTUNUTF9zZXRfdmlycV9o
YW5kbGVyIHdpbGwgaGFwcGlseSBzdGVhbCBhIGdsb2JhbCB2aXJxIGZyb20gdGhlDQo+PiBj
dXJyZW50IGRvbWFpbiBoYXZpbmcgYm91bmQgaXQgYW5kIGFzc2lnbiBpdCB0byBhbm90aGVy
IGRvbWFpbi4gVGhlDQo+PiBmb3JtZXIgZG9tYWluIHdpbGwganVzdCBuZXZlciByZWNlaXZl
IGFueSBmdXJ0aGVyIGV2ZW50cyBmb3IgdGhhdA0KPj4gdmlycSB3aXRob3V0IGtub3dpbmcg
d2hhdCBoYXBwZW5lZC4NCj4gDQo+IFlldCAtIHNlZSBteSByZXBseSBvbiBwYXRjaCAyIC0g
aXQgbWF5IGFjdHVhbGx5IGhhdmUgYmVlbiBpbnRlbnRpb25hbCB0bw0KPiBiZSB0aGlzIHdh
eSwgaW4gY2FzZSB0aGUgbmV3IGRvbWFpbiBpcyBpbmRlZWQgdGhlIGRlc2lnbmF0ZWQgbmV3
IGhhbmRsZXIuDQo+IE90aGVyd2lzZSBzdWNoIGEgdHJhbnNmZXIgd291bGQgcmVxdWlyZSBt
b3JlIGNvb3JkaW5hdGlvbiAtIHRoZSBvcmlnaW5hbA0KPiBvd25lciB3b3VsZCBmaXJzdCBu
ZWVkIHRvIHVuYmluZCwgdGhlbiBzaWduYWwgdGhlIGNvbXBsZXRpb24gdGhlcmVvZiB0bw0K
PiB0aGUgbmV3IG93bmVyLg0KDQpZZXMsIGxpa2UgdG9kYXkncyBoYW5kbGluZyBvZiB4ZW5z
dG9yZWQgbGl2ZSB1cGRhdGUuDQoNCkl0IGlzIHRoZSBuYXR1cmFsIHdheSB0byBkbyB0aGF0
LCBhcyB0aGF0IGNvb3JkaW5hdGlvbiBuZWVkcyB0byBiZSBoYXBwZW5pbmcNCmFueXdheSwg
YXMgSSd2ZSBvdXRsaW5lZCBpbiBteSByZXNwb25zZSB0byB5b3VyIHJlbWFyayBvbiBwYXRj
aCAyLg0KDQoNCkp1ZXJnZW4NCg==
--------------E3Ru5K2L0Jl2xEAXkgsg4jbD
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

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

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

--------------E3Ru5K2L0Jl2xEAXkgsg4jbD--

--------------mzHVtEx2xVDqn3fHjVdfxQlA--

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

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

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmd9Ud0FAwAAAAAACgkQsN6d1ii/Ey9+
Uwf/WyZXOhyzIhxBbFd54swFJ85STfQ/UYbbP2dwAdS53nkSxbWi+SK7nRVeH2JWk9sGTnDr1bBW
arCq6g7/O1DWn10WsGu3muKrsBEbvABnzVAwHRPvoYeRDMn8a/efm7gflOJvQNaT+6fZH9khZpSi
HQpRqE+IjT+vyCP+u7mEC3IXLjS6LL0zhG6HPF8XtZeZc7ltb6p7J9YU1bVJ9EegMvanyB+gUgx2
QlGie8Yus1jd82AnF+Du5yx5flegrKE8l7igY5Xw1ROcVoTcO6ofDD4FclJk2cPO2VCRXZSEB/38
ZgYITlx2YigsjZrdVswpOyGrNQSQ9ZOgJxiwmoCvfQ==
=YyJ7
-----END PGP SIGNATURE-----

--------------wMdRpw23gw9FMvVc5BaHYAMR--


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 16:14:51 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 16:14:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866632.1277954 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVCE9-0004Cz-VQ; Tue, 07 Jan 2025 16:14:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866632.1277954; Tue, 07 Jan 2025 16:14:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVCE9-0004Cs-SX; Tue, 07 Jan 2025 16:14:45 +0000
Received: by outflank-mailman (input) for mailman id 866632;
 Tue, 07 Jan 2025 16:14: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 <SRS0=1r68=T7=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVCE8-0004Cm-MJ
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 16:14:44 +0000
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com
 [2a00:1450:4864:20::42b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 816cf858-cd12-11ef-a0df-8be0dac302b0;
 Tue, 07 Jan 2025 17:14:43 +0100 (CET)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-3862a921123so10611129f8f.3
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 08:14:43 -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
 ffacd0b85a97d-38a1c89e528sm51375696f8f.83.2025.01.07.08.14.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 08:14:42 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 816cf858-cd12-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736266483; x=1736871283; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ccNMf9aGsRxc3mwx8N5SPs7WkprCMCSuBkc4OZMaO4U=;
        b=byqYaYiE799ABJv+dyMI5Ns4wc0R2/08XMpazScAiGNOkygYet+OQWLgoclWp2AcSa
         7Hj7FTF8v5NpuawnSRFamcYOwYUsK8XN7Q4bxVK+unC+RrX10jyzh64dZAu2f3c3pr6k
         URrSSgWo2FhKsqa2SWCCSuPfo7eFslHM8OpZkB7SUSTfje8zONVm4eKvxf049dw2WJu/
         IkHR4eGPbcpcI6VraYfY+pDpRj+U36sTpcDEPunFfN5rOXtYLXWYMwm51eSdAi+PdT9d
         P1I9WBR1LxUhEYnw49J2Fr5RG5tmVcfI/IgoDKE7N3p2p1L1vwi0D5J9WVxRfgMN2uc1
         xAdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736266483; x=1736871283;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ccNMf9aGsRxc3mwx8N5SPs7WkprCMCSuBkc4OZMaO4U=;
        b=mZQXnp/IeHy4BoRq08KFHjp/VqFFrUst05ir46Bz88n8edsrASb0q0K+uEA9/2oAiv
         ABCwL+V+Ozf9CLuJZp+jMwOWbINY+oivzLUk//7KhoUilnZQt6jwmxYhcIGX31yu84MH
         zzSbx9bNZ62DH9rlufUqgpJc4SRPuyuKUG2ZC49Wdr8nT5DeRi8HNd95RVDWB94N77KM
         ODeNgXdrya8CMNTyl9vNvS8zaQ8NuxZLK/L5qSIUbUdxB1uEWfhSbsZA2xtB2jfZf6bg
         XQgrhu6ncJ855jwQa3kenCRHulA7H87bNhcWGzyVxOaP3Kh0qOg+bMALn44d49hVW9nV
         0USA==
X-Forwarded-Encrypted: i=1; AJvYcCUBYYb8ZDpDYOXNfOhVspmeqhASz2W7NMIWR9uU8/IIVCqtEErurOu2cjRo6OJyKSJL6wkfv1JlHdw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyg72Gz/B9hKf07nVq5Jk+fyKcBncQayTm31ZJE4I3yYQhTEldt
	mwhU0opogIlWil0Y09uZn07dfUvZcwx7rO+A69UslS8XMGXa9u+E167p1BsJ2Q==
X-Gm-Gg: ASbGncut6jwzxa41ABwKuSEB8GKhOMYiJb/WeX9Tv509/JXFL6i8gy0kOgWvKBxFUg9
	65gSsvrRV41TZKLazdNxX//g05r2Ssv1LhxMJnTxHE5lX7qa8BUPXLoooBT5Ov4Ry+ZjINi2ODo
	tlZrmfsKSwuLizMkU75/FcITd9kuvdVMjA2UA36F5eBo+3i+STXQIm55NcwXm7JR+aRk8pM0l+Z
	wyAazexnQ35OXf02j1O4UaL/aY+xh5oaFVxKn2ntg4TCzh7SUw1S9L1BljrLFioAugabGK8zeWq
	0H27jMnLRkCbvJ7uguFcaxK9epHL6ug1cIabs5aLrA==
X-Google-Smtp-Source: AGHT+IEh5S9o++FY10HMcDxqByzXqKj2xXDQiqOc21TtQOBAQtNDznakvr41N6oR7HeINGtdfrPcrQ==
X-Received: by 2002:a5d:5f4f:0:b0:386:3329:6a04 with SMTP id ffacd0b85a97d-38a223f5b4cmr58182990f8f.39.1736266483150;
        Tue, 07 Jan 2025 08:14:43 -0800 (PST)
Message-ID: <b77141df-fa14-426a-937f-42693d1caeb9@suse.com>
Date: Tue, 7 Jan 2025 17:14:41 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 4/7] xen: add bitmap to indicate per-domain state
 changes
To: Juergen Gross <jgross@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <20250107101711.5980-1-jgross@suse.com>
 <20250107101711.5980-5-jgross@suse.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250107101711.5980-5-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 07.01.2025 11:17, Juergen Gross wrote:
> Add a bitmap with one bit per possible domid indicating the respective
> domain has changed its state (created, deleted, dying, crashed,
> shutdown).
> 
> Registering the VIRQ_DOM_EXC event will result in setting the bits for
> all existing domains and resetting all other bits.
> 
> As the usage of this bitmap is tightly coupled with the VIRQ_DOM_EXC
> event, it is meant to be used only by a single consumer in the system,
> just like the VIRQ_DOM_EXC event.
> 
> Resetting a bit will be done in a future patch.
> 
> This information is needed for Xenstore to keep track of all domains.
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
> V2:
> - use DOMID_FIRST_RESERVED instead of DOMID_MASK + 1 (Jan Beulich)
> - use const (Jan Beulich)
> - move call of domain_reset_states() into evtchn_bind_virq() (Jan Beulich)
> - dynamically allocate dom_state_changed bitmap (Jan Beulich)
> V3:
> - use xvzalloc_array() (Jan Beulich)
> - don't rename existing label (Jan Beulich)
> V4:
> - add __read_mostly (Jan Beulich)
> - use __set_bit() (Jan Beulich)

This change looks to have been lost, ...

> - fix error handling in evtchn_bind_virq() (Jan Beulich)
> V5:
> - domain_init_states() may be called only if evtchn_bind_virq() has been
>   called validly (Jan Beulich)
> V6:
> - guard dom_state_changed bitmap with d->event_lock (Jan Beulich)

... without it being mentioned anywhere, and without it becoming clear why
it would have needed undoing.

> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -35,6 +35,7 @@
>  #include <xen/irq.h>
>  #include <xen/argo.h>
>  #include <xen/llc-coloring.h>
> +#include <xen/xvmalloc.h>
>  #include <asm/p2m.h>
>  #include <asm/processor.h>
>  #include <public/sched.h>
> @@ -139,6 +140,51 @@ bool __read_mostly vmtrace_available;
>  
>  bool __read_mostly vpmu_is_available;
>  
> +static unsigned long *__read_mostly dom_state_changed;
> +
> +int domain_init_states(void)
> +{
> +    const struct domain *d;
> +
> +    ASSERT(!dom_state_changed);
> +    ASSERT(rw_is_write_locked(&current->domain->event_lock));

rw_is_write_locked_by_me()?

> +    dom_state_changed = xvzalloc_array(unsigned long,
> +                                       BITS_TO_LONGS(DOMID_FIRST_RESERVED));
> +    if ( !dom_state_changed )
> +        return -ENOMEM;
> +
> +    rcu_read_lock(&domlist_read_lock);
> +
> +    for_each_domain ( d )
> +        set_bit(d->domain_id, dom_state_changed);
> +
> +    rcu_read_unlock(&domlist_read_lock);
> +
> +    return 0;
> +}
> +
> +void domain_deinit_states(const struct domain *d)
> +{
> +    ASSERT(rw_is_write_locked(&d->event_lock));

Again.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 16:28:31 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 16:28:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866640.1277964 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVCRL-0006bH-3L; Tue, 07 Jan 2025 16:28:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866640.1277964; Tue, 07 Jan 2025 16:28:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVCRL-0006bA-0P; Tue, 07 Jan 2025 16:28:23 +0000
Received: by outflank-mailman (input) for mailman id 866640;
 Tue, 07 Jan 2025 16:28: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 <SRS0=1r68=T7=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVCRJ-0006b4-Vp
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 16:28:21 +0000
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com
 [2a00:1450:4864:20::333])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6866e085-cd14-11ef-a0df-8be0dac302b0;
 Tue, 07 Jan 2025 17:28:20 +0100 (CET)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-4361815b96cso105337915e9.1
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 08:28:20 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c89e261sm51561401f8f.76.2025.01.07.08.28.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 08:28:19 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 6866e085-cd14-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736267300; x=1736872100; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=x66COL8cMorOqV5+S+Ao/p5Y+jjzvxutFukjG5PvADk=;
        b=V8kykDaV97UeWca5U/8YLrBeg8Sv4xTc1IQ5BE5Sg4jSRVn2cgG097UUldb5oflpEb
         fpLbGT6FpEGoouHDXWwnU5q2Mb2Lhesso99ojI4gkIHsRTkzsmAcERuWEvtfErWL3H4u
         Aw+QTX66FDqt7WjA2ZyRytigelueTIOXZPtI7BNYAszmYCo4GXMeGPrMN2G0TqN7c/LY
         B9a+Zlp8Dff5vj7q9mwY4xj+s3Qs39vRb772Vq00dmywZKSI43xKySl1Q2jgtECJvdgo
         sfeu0wiU4jsNuLMxtEWPmihLB6EwQq7iNYTRU35XazfvUyY3WNO18iMIMKluxfELIU+p
         82QQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736267300; x=1736872100;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=x66COL8cMorOqV5+S+Ao/p5Y+jjzvxutFukjG5PvADk=;
        b=KgEQoS+tY1L5oFhVRRHL+X10GbWnq8VVD0sMG//d9xG8RF2d/rwunfT8OiTKjJgh70
         cG2r4fRM4fp8eERReKa6GaCy56aGWubTbE3kKOe8MvFA28YZYABgrHj3emeCvfeFlHnF
         Cje8h7KoQiv8ihWHa+8tzYpGb9+ynt7wh4rbfZLGsgbeqhH2kkRuo8Rc1ZjMKT2LBOsY
         ldqd0fuWqlfVAnIpGa6q/3p1bGKcZf0/uPs5cCoNylXCpZ5st25NMbCvC4S1VpwkGNuG
         BF5XtfIIT/FY1Fx7HM8yacTIrie247XC5ZbKG4fjj0wpJ6b6BKAANoFaRuIxhIzvnWXs
         bSIg==
X-Forwarded-Encrypted: i=1; AJvYcCVGQDSChOol5EL68R0KjQSPwIemYMiq6AjfDzTgrF0wxtZ8ykF7TSoNAV1ej0M9CeTZ6daCu2xcIAA=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyz0k0hrBcbWlW+Dg4UhW3fAIMJyjcJ3W9MWxOgjlb8QP0dGWIf
	UhQU1yfgi3qJ2Gl0o3/R8sngkjqJWUci+fH6RY0j6Gm0OP9a4cseArEddnMEaw==
X-Gm-Gg: ASbGncuutctzAAa7+9fi9sh9SkiWHoPPNmJ6f1BU8XGiM3YSP68pZNd6OtsYno84RAn
	FTKnPWjUc+F38mpb766TX9jHAgzqJ+f3QW7D9/zn/oPr4QscpapphXodfgcTzjIIpxU6Ba66wyp
	thGk7EcX9oxxb4+le7eFSxwUb+QUcbSmxRSfrBPtondRH+7BhrIQfAAzs2zQKDwoiveU2vCVzym
	mm+7J5y5FToTHNHynwdyaGEmTiZJudXcOXUlYikLJkB5jncakHs4e+qoT+dOETkRMb+6DNWxjEB
	hMVBDlD5wJ+YQ3CTqbkLKZK7dMMfBb9lWi9onf8V6A==
X-Google-Smtp-Source: AGHT+IGt2HAiZjF6JfMzpHacHKNE1MwoQk/whAchyXUSoz2s6FDypgVBAJ8WrZ53+GATzH9tExjYpQ==
X-Received: by 2002:a05:6000:2c5:b0:385:f195:27f with SMTP id ffacd0b85a97d-38a221f339emr56512836f8f.5.1736267300221;
        Tue, 07 Jan 2025 08:28:20 -0800 (PST)
Message-ID: <781daba7-5d6f-4d86-bce4-c5aa9d135513@suse.com>
Date: Tue, 7 Jan 2025 17:28:18 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 5/7] xen: add new domctl get_changed_domain
To: Juergen Gross <jgross@suse.com>
Cc: "Daniel P. Smith" <dpsmith@apertussolutions.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <20250107101711.5980-1-jgross@suse.com>
 <20250107101711.5980-6-jgross@suse.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250107101711.5980-6-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 07.01.2025 11:17, Juergen Gross wrote:
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -185,6 +185,76 @@ static void domain_changed_state(const struct domain *d)
>      unlock_dom_exc_handler(hdl);
>  }
>  
> +static void set_domain_state_info(struct xen_domctl_get_domain_state *info,
> +                                  const struct domain *d)
> +{
> +    info->state = XEN_DOMCTL_GETDOMSTATE_STATE_EXIST;
> +    if ( d->is_shut_down )
> +        info->state |= XEN_DOMCTL_GETDOMSTATE_STATE_SHUTDOWN;
> +    if ( d->is_dying == DOMDYING_dying )
> +        info->state |= XEN_DOMCTL_GETDOMSTATE_STATE_DYING;
> +    if ( d->is_dying == DOMDYING_dead )
> +        info->state |= XEN_DOMCTL_GETDOMSTATE_STATE_DEAD;
> +    info->unique_id = d->unique_id;
> +}
> +
> +int get_domain_state(struct xen_domctl_get_domain_state *info, struct domain *d,
> +                     domid_t *domid)
> +{
> +    unsigned int dom;
> +    int rc = -ENOENT;
> +    struct domain *hdl;
> +
> +    if ( info->pad0 || info->pad1 )
> +        return -EINVAL;
> +
> +    if ( d )
> +    {
> +        set_domain_state_info(info, d);
> +
> +        return 0;
> +    }
> +
> +    /*
> +     * Only domain registered for VIRQ_DOM_EXC event is allowed to query
> +     * domains having changed state.
> +     */
> +    if ( !domain_handles_global_virq(current->domain, VIRQ_DOM_EXC) )
> +        return -EACCES;
> +
> +    hdl = lock_dom_exc_handler();

Instead of leaving a small window for races between the if() and this
function call, can't you simply compare hdl against current->domain?

> +    while ( dom_state_changed )
> +    {
> +        dom = find_first_bit(dom_state_changed, DOMID_MASK + 1);
> +        if ( dom >= DOMID_FIRST_RESERVED )
> +            break;
> +        if ( test_and_clear_bit(dom, dom_state_changed) )

As this is now running under lock, does it really need to be test-and-clear?
What mechanism would allow the flag to be cleared between the find-1st and
here? Plus, like for patch 4, I think it could be __clear_bit() here.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 16:38:55 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 16:38:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866648.1277974 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVCbD-0000Tz-0v; Tue, 07 Jan 2025 16:38:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866648.1277974; Tue, 07 Jan 2025 16:38:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVCbC-0000Ts-TO; Tue, 07 Jan 2025 16:38:34 +0000
Received: by outflank-mailman (input) for mailman id 866648;
 Tue, 07 Jan 2025 16:38:33 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=1r68=T7=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVCbB-0000Tm-KL
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 16:38:33 +0000
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com
 [2a00:1450:4864:20::32e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d453dc95-cd15-11ef-99a4-01e77a169b0f;
 Tue, 07 Jan 2025 17:38:31 +0100 (CET)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-4361f664af5so178518975e9.1
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 08:38:31 -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
 ffacd0b85a97d-38a1c848a47sm50209996f8f.62.2025.01.07.08.38.29
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 08:38:30 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: d453dc95-cd15-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736267911; x=1736872711; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Z0+9v+7uSF45XrI3/JeDvgSGJd6PS0H+ytMNhpT9kwo=;
        b=LqVU6u3vyPjWCKWSHUwxuVKiZXiK5VjlmT+7hp5CY1ZKXd92aKUKBdifi+3raFW5hc
         lX6xwYQVsD0JopNPcUu9RQr4Z0PK7Qk5hgIIyUPQw4qit24wfPMQe/jywYTQS5dF4Ngd
         Q4NtSu2ICL2QIlK41hm+LLBBhUSq125aniLI1Se+SyA6qrfnUAvtJ7AzAaNsC+xJbWOW
         aCe3Frj8QZcBzFnMEt5LwwjZkPLusb+4ArrxdBJ07Mzko6FkIqLIBCiXC6KNlEYHJU+t
         YOP/F6MlZCkPZ27yKXDNCn+jsDgWlQ70lpErfxe85LNxasljHwt6YMyJahd2UvRPzuCb
         OIKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736267911; x=1736872711;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Z0+9v+7uSF45XrI3/JeDvgSGJd6PS0H+ytMNhpT9kwo=;
        b=CoR89iPJ7kwHxjwTzOQiAOJgtE3ysO/3Q8BS2GO2uRft8/WT9/omJY3XX/at8IPsNa
         clRW+WLixvbBTE506So0xglgrgYRmQrm3kiCqXZt4Z7tvU6lvPqY5PEwwTCE3EsHiDhI
         C/VRdyTtdbJPScAyxKgqXAVhUwSkxzYHlDuN9MBzMcMcDhg1IudoOphFltfFp/gGgCA4
         gQwkcXjhZfDwFPQXeyYGirjh+D9TVtNY8zv0G3A20tVJEsvpibPKhyYo4roFJCcjnhqt
         sPqoM7G4672HfgBAadLcWC02gDxEPftzgtdQV2o30Z7LUfbAXtOKz5n/n6yIQI82YTfa
         qNvg==
X-Forwarded-Encrypted: i=1; AJvYcCUs6MfsRp6Dbzf52lLiiXG0sPCG7IoU57Q3gL4feEcccyccBmdlT/s8foW1DxUHlXaXgxsLQfxZ22E=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwtaZBoJ4QmAz9GO8ZxJE6QrsCbQwlc7wOjzoAN+hjIoJ0d56ay
	bo5VZ9XTSmFpmf5pU5iLnWRThjLpWdKI6TatDfWkQyCM6bmcPk40WPk3Zz5jzg==
X-Gm-Gg: ASbGncuhYybl4wVotL8uZKdwGRLDAXeu2WSQqko4wVYYYCO2T/Jzm6JhfoUt0qwscVx
	mMAMqCej06vczb2HsdUayCl9y9uPS6vw9BhR+jP7ryTaQBESnrACnue4EcgRc6KfEenMXWWCC1i
	V45lqaxw0BdBxQUsI0ZXXFzodHx9/SLcl9lGOiJHtg0O3nqETD0E6+MGv8VZQYXgiXmNXnhl5Vv
	/k4AHOlN0nbYii4LnjmSAPWbUWJgzcALAkN9feImp93Cp3OE5ZfJGXAYLcoe05yVM1Q+3eFrgh3
	lJgrgBLcOg0jL/7vc+IY6MuygGGj0SQ+pvFgZEbA5Q==
X-Google-Smtp-Source: AGHT+IFgk2qcgHGekUml+f3xaIyk2NncAnYL/Lj4TCidnqfXnNvr5fkIpF7JAnFgrhv8D44UmbfQtg==
X-Received: by 2002:a05:600c:3b13:b0:435:23c:e23e with SMTP id 5b1f17b1804b1-4366864409amr567285395e9.12.1736267910726;
        Tue, 07 Jan 2025 08:38:30 -0800 (PST)
Message-ID: <511c3207-20b8-4110-a5ef-55f8b428074d@suse.com>
Date: Tue, 7 Jan 2025 17:38:28 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 2/7] xen/events: don't allow binding a global virq from
 any domain
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <20250107101711.5980-1-jgross@suse.com>
 <20250107101711.5980-3-jgross@suse.com>
 <577427ff-61e2-4fc9-8853-a7eec3f69bb6@suse.com>
 <5261716e-a2f4-4423-bb8d-17e36bf34538@suse.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <5261716e-a2f4-4423-bb8d-17e36bf34538@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 07.01.2025 17:07, Jürgen Groß wrote:
> On 07.01.25 16:34, Jan Beulich wrote:
>> On 07.01.2025 11:17, Juergen Gross wrote:
>>> @@ -479,8 +486,13 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind, evtchn_port_t port)
>>>       */
>>>       virq = array_index_nospec(virq, ARRAY_SIZE(v->virq_to_evtchn));
>>>   
>>> -    if ( virq_is_global(virq) && (vcpu != 0) )
>>> -        return -EINVAL;
>>> +    if ( virq_is_global(virq) )
>>> +    {
>>> +        if ( get_global_virq_handler(virq) != d )
>>> +            return -EBUSY;
>>
>> Hmm. While this eliminates the problem for the common, race free case,
>> the handler changing right after the check would still mean the bind
>> would succeed.
> 
> Are you fine with me adding a paragraph to the commit message saying
> that a future patch will handle this case?
> 
> This future patch is patch 4 of the series, which will need to be
> modified to check the handling domain inside the event_lock.

I think this would be okay, so long as patches 2...4 are then also all
committed together.

>> Plus this way you're breaking a case that afaict has been working so
>> far: The bind happening before the setting of the handler. With a lot
>> of unrelated if-s and when-s this could e.g. be of interest when
>> considering a re-startable Xenstore domain. The one to take over could
>> start first, obtain state from the original one while that's still
>> active, and be nominated the handler of the global vIRQ only in the
>> last moment.
> 
> This is a racy situation, too. If the old domain receives the virq after
> sending the state, this would need to be handled by transferring the virq
> information to the new domain, which can result in a never ending story.
> 
> This is the reason why the domain state bitmap is reset to contain all
> existing domains to be flagged as "changed", as otherwise a change might
> get lost.
> 
> I'd rather be able to handle today's use cases in a sane way than to try
> handling any weird future use cases which we don't know yet.
> 
> I think today's behavior is more or less insane and the new behavior is
> much easier to understand and more intuitive.

Hmm, I'd like to leave this then for input by other maintainers.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 16:41:39 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 16:41:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866655.1277984 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVCeA-0002Es-DF; Tue, 07 Jan 2025 16:41:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866655.1277984; Tue, 07 Jan 2025 16:41:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVCeA-0002El-AD; Tue, 07 Jan 2025 16:41:38 +0000
Received: by outflank-mailman (input) for mailman id 866655;
 Tue, 07 Jan 2025 16:41:37 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=1r68=T7=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVCe9-0002Ef-3O
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 16:41:37 +0000
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com
 [2a00:1450:4864:20::32a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 41e87510-cd16-11ef-99a4-01e77a169b0f;
 Tue, 07 Jan 2025 17:41:35 +0100 (CET)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-436a39e4891so57490805e9.1
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 08:41:35 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-43664b15365sm588496665e9.7.2025.01.07.08.41.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 08:41:34 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 41e87510-cd16-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736268094; x=1736872894; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Sge+i7ZEgDrRXMuV+vrYZq6xgx2kalBZAUAv5tDhHeM=;
        b=K6sA4PmF44Hkb9B1ccqETmM1nHaOZRFeMTISibHEdr+1YfhbvT5gvzfHTQhK6wnrZI
         5BRTaGhC4c32Zp8sBnEzSI41NcUeH6aHI4rdAxXMPKbb7zMs66Vbi5fHgYt81iqe5onx
         rU799M8R7lzlO5zm9vYe3ldjtuCUZWivT1aZiFsavRGp0MaUWoFLgfXwpub5lsVq8Jxk
         yP4QCwbDo51UERFt1LnKAFrXhKbZG0MSWzSbRGnNpSQ2bm0NcKOxqXUt4ENz8ub2eIn6
         0pVX+Zp42WepIn6HpquVWPJMlshCuJ93/xCIxGH01kI3x495ys52id5Sb3BedMJMDsMK
         KE6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736268094; x=1736872894;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Sge+i7ZEgDrRXMuV+vrYZq6xgx2kalBZAUAv5tDhHeM=;
        b=qBqEiv2SMhnAmLd+RzhjZhs/SqI8U8vQYmejiIT0olzknTwObk6k79R+/l0D+625Ob
         h6gKWkckYJOpFAAoZZdRPFNVri4otWkGtPdNjXo1phfTcnzboV6mvZA7InV9m8kj1qPK
         5mL22MS9oDDc8Mo/1qqlfbjHk2ZTtEJ7qVWZEThokIOxvprh9KXLZzWdqiq6T18zyKnL
         Npsfqar5Ua26kW+UeiOn1AVsmWjmvghtNIPQGVNlSao1wyYuJE2YQfOZ/Fn6i9q/XiYN
         vEM2YKj2RpxaHIp/VXoT8XaeRJ5nYmjQBgj32CbDqoWvU+bzrf8jxFV+S1uwtZyROtUI
         XdKQ==
X-Forwarded-Encrypted: i=1; AJvYcCUq7TNvAd3pPeJ6/j0uTRHxcqL73fJU/U/PaQhDCJZAXZdDAtgIJw/z+KKpkB+/MEfvWkonGzmSex0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwMPgp9fr6r59llWPpz7ig48E4jvT0uGntPJI5zBfED3Cd51wyY
	Gs5YLI9BFnWJouAzwB9mHLhDCsUlZQ2p8BxY+dDA4Bpxg2HyMQRHoYGx3B/kUg==
X-Gm-Gg: ASbGncukK4ntZpivyH2A+r3KxsJwZ2vjiNlk9t3LwqsJt33aaiHPG6vmmOOrskuwG7p
	9Tbh6TMMaDOzTKeWJo9VChTmfl0eB2z+oEZpXq3WNhLTG486m+b+iDhZrUZV5mgWKaeENuIU3T7
	mY/NX5v4OOoUyhnKm4kD083H9q/SCFlakW8yo3wdlNb0PQSwnfon3xYeJeJrs0/YXvy7SskQSaS
	PBkSEcPk4B5jUrgNLpUyrfQnxub8/zqOf73FJOaglyYwd7QLeZiUGFF9+T/5sDGeDy3L0hRMEtC
	h6RqlJdJK+Avf7i3eodFJcffinEEO8sw/uoh3XG0bQ==
X-Google-Smtp-Source: AGHT+IElXNoM4NNAb5QN6+ISxfNQLc5uKjwcvfQq0oRy+FyIHt9Acz/tzDsIJCbSXZ+pz4HSqJvPxQ==
X-Received: by 2002:a05:600c:4510:b0:436:5fc9:30ba with SMTP id 5b1f17b1804b1-43668b783d0mr499629205e9.29.1736268094653;
        Tue, 07 Jan 2025 08:41:34 -0800 (PST)
Message-ID: <0bc78550-5aca-4ce5-91e1-f8506c338b84@suse.com>
Date: Tue, 7 Jan 2025 17:41:33 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/2] x86: Rename _rsvd field to pw and move it to the
 bit 58
To: =?UTF-8?Q?Petr_Bene=C5=A1?= <w1benny@gmail.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Tamas K Lengyel <tamas@tklengyel.com>, xen-devel@lists.xenproject.org
References: <cover.1735837806.git.w1benny@gmail.com>
 <525e1ef971f06e8f2ef196e52a150820d155a5c0.1735837806.git.w1benny@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <525e1ef971f06e8f2ef196e52a150820d155a5c0.1735837806.git.w1benny@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 02.01.2025 18:13, Petr Beneš wrote:
> From: Petr Beneš <w1benny@gmail.com>
> 
> The EPT Paging-write feature (when enabled by the TERTIARY_EXEC_EPT_PAGING_WRITE bit) uses bit 58 of the EPT entry to indicate that guest paging may update the page, even if the W access is not set.
> 
> This patch is a preparation for the EPT Paging-write feature.
> 
> Signed-off-by: Petr Beneš <w1benny@gmail.com>
> Acked-by: Tamas K Lengyel <tamas@tklengyel.com>

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




From xen-devel-bounces@lists.xenproject.org Tue Jan 07 16:42:11 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 16:42:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866663.1277993 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVCeh-0002zW-On; Tue, 07 Jan 2025 16:42:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866663.1277993; Tue, 07 Jan 2025 16:42:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVCeh-0002zP-Lk; Tue, 07 Jan 2025 16:42:11 +0000
Received: by outflank-mailman (input) for mailman id 866663;
 Tue, 07 Jan 2025 16:42:10 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>) id 1tVCeg-0002zH-EV
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 16:42:10 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <julien@xen.org>) id 1tVCef-009TPl-1C;
 Tue, 07 Jan 2025 16:42:09 +0000
Received: from [2a02:8012:3a1:0:40aa:4b3a:22f9:bcb7]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from <julien@xen.org>) id 1tVCef-004ajM-0s;
 Tue, 07 Jan 2025 16:42:09 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=S57niDSYYUwVQGXv0nYCnmsDD/aO/iUB+pBNjZ3Ts+g=; b=dxWigbXX+k3KkK3trEFHQSNp6T
	U3/0NsKzfyoQPOY8RvUc0GGsNWtna8GtozL/eoH7xGfsEirm8IFK0PSiv7CGFz7Bd/OqpiQ2hB7Cm
	XrK5whjnm4ftbRum1kxn3/LEhk32RAqeiy5w8ZjQJ2eZiNwb4jEX8GTmISwxUIwoWR0w=;
Message-ID: <0062e0cf-0830-4d16-942d-348e6d33a2c4@xen.org>
Date: Tue, 7 Jan 2025 16:42:01 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [for-4.20] Re: [PATCH v12 12/12] xen/arm: add cache coloring support
 for Xen image
Content-Language: en-GB
To: Jan Beulich <jbeulich@suse.com>,
 Carlo Nonato <carlo.nonato@minervasys.tech>
Cc: xen-devel@lists.xenproject.org, andrea.bastoni@minervasys.tech,
 marco.solieri@minervasys.tech, Stefano Stabellini <sstabellini@kernel.org>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Michal Orzel <michal.orzel@amd.com>, Oleksii <oleksii.kurochko@gmail.com>
References: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
 <20241213162815.9196-13-carlo.nonato@minervasys.tech>
 <dbbc649f-b705-46b5-a071-760d688aa2cd@amd.com>
 <CAG+AhRWrXAYfKXXKfp6949vNMdGDy9qWOY11SKAigJuC8oUvDw@mail.gmail.com>
 <df0f831f-378f-4fa3-ae4f-b065f2ea566d@suse.com>
From: Julien Grall <julien@xen.org>
In-Reply-To: <df0f831f-378f-4fa3-ae4f-b065f2ea566d@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi,

On 16/12/2024 14:36, Jan Beulich wrote:
> On 16.12.2024 15:28, Carlo Nonato wrote:
>> On Mon, Dec 16, 2024 at 2:56 PM Michal Orzel <michal.orzel@amd.com> wrote:
>>> On 13/12/2024 17:28, Carlo Nonato wrote:
>>>> --- a/xen/arch/arm/arm64/mmu/mm.c
>>>> +++ b/xen/arch/arm/arm64/mmu/mm.c
>>>> @@ -1,6 +1,7 @@
>>>>   /* SPDX-License-Identifier: GPL-2.0-only */
>>>>
>>>>   #include <xen/init.h>
>>>> +#include <xen/llc-coloring.h>
>>>>   #include <xen/mm.h>
>>>>   #include <xen/pfn.h>
>>>>
>>>> @@ -138,8 +139,36 @@ void update_boot_mapping(bool enable)
>>>>   }
>>>>
>>>>   extern void switch_ttbr_id(uint64_t ttbr);
>>>> +extern void relocate_xen(uint64_t ttbr, void *src, void *dst, size_t len);
>>>>
>>>>   typedef void (switch_ttbr_fn)(uint64_t ttbr);
>>>> +typedef void (relocate_xen_fn)(uint64_t ttbr, void *src, void *dst, size_t len);
>>>> +
>>>> +void __init relocate_and_switch_ttbr(uint64_t ttbr) {
>>> CODING_STYLE: { needs to be on its own line
>>>
>>> Also, this function is only executed in case of LLC coloring, so shouldn't it
>>> be #ifdef protected.
>>
>> Here and in other places (patch #8) I'm relying on DCE to remove functions
>> that are not called. This was a suggestion from Jan in that patch. Can we
>> adopt the same here?
> 
> Yet how would the compiler spot that the function is unused? That would only
> work with LTO / WPO. DCE (as I did suggest elsewhere) requires the functions
> in question to be static (allowing the compiler to see enough of the whole
> picture).

Sorry for the late answer. I was away with limited e-mail access. While 
looking what was committing recently, I noticed that a dummy function 
was introduced:

void __init relocate_and_switch_ttbr(uint64_t ttbr) {}

If a function is not supposed to be called, then it should contain a 
BUG_ON() to catch any misusage. Otherwise, this is a recipe for 
disaster. In this case, it would not be trivial to notice the TTBR was 
not switched...

That said I would have actually considered to remove the empty stub. I 
am a bit surprised that DCE wouldn't work in this case because the call 
is protected with "if ( llc_coloring_enabled )". When cache coloring is 
not enabled, this would turn to an "if ( false )" and therefore all the 
code should be removed. What did I miss?

Note that this is what we already rely on for arm32 because there is no 
stub... So if this is problem then we definitely need to fix it on arm32 
as well...

IOW, we either introduce a stub (including the BUG_ON) for both arm32 
and arm64 in the header or we remove the stub completely.

Marco, Michal, can you have a look? Ideally, this should be fixed for 4.20.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Tue Jan 07 16:46:09 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 16:46:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866670.1278004 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVCiS-0003e1-8S; Tue, 07 Jan 2025 16:46:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866670.1278004; Tue, 07 Jan 2025 16:46:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVCiS-0003du-4Y; Tue, 07 Jan 2025 16:46:04 +0000
Received: by outflank-mailman (input) for mailman id 866670;
 Tue, 07 Jan 2025 16:46:03 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Qdqe=T7=suse.com=jgross@srs-se1.protection.inumbo.net>)
 id 1tVCiR-0003do-Du
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 16:46:03 +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 e12a063c-cd16-11ef-a0df-8be0dac302b0;
 Tue, 07 Jan 2025 17:46:02 +0100 (CET)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-4361b0ec57aso156799635e9.0
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 08:46:02 -0800 (PST)
Received: from ?IPV6:2003:e5:8731:2800:842d:42a0:5992:3595?
 (p200300e587312800842d42a059923595.dip0.t-ipconnect.de.
 [2003:e5:8731:2800:842d:42a0:5992:3595])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-43656b4432dsm632975125e9.41.2025.01.07.08.46.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 08:46:01 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e12a063c-cd16-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736268362; x=1736873162; darn=lists.xenproject.org;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=tc4l18DronqzPGD59Z1aht7nudFiCBklHDYbG/UzLMs=;
        b=BNTnU9/DUUrVkhcpc0xm9Y/0JHmED72Nx8uM3rzwMEmYbfaWnIuYRiW5uDyHQBoVem
         a86T6zkF/h2maYDeTZ6ohdyuCKELU23LzENnTwrTiM0BWJYycNRKWCzK+RA4PwaBxtHo
         zUb2+kcjRl2ZWhydezK72/LKO9QhWatyuU+3pmSl+b0w7jW/ViKDS3kQNqfQXlEt31Dp
         Nrvvm7zDWuWoQdIvJngh2B54BORANTmjCGEw9yVj8puRydj3jZRHW/E4Kgay1iTCs31s
         Y3m9/L6UNqFQF3J1nTyAid8EWgFY2wkm3JyHAjhaiPPSPbgvI4D/Pp3qSP9G/2Zn98Zr
         oj/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736268362; x=1736873162;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=tc4l18DronqzPGD59Z1aht7nudFiCBklHDYbG/UzLMs=;
        b=Sm0Yd74x/qo8d1F6NrG5ltIAvlg1EfhqXI7qptFp5VsCPtCzDggh48EVZbDnCf2ujx
         V7lQO2NvG2j2ERisMuBhyblZSfnMFh+W5h0vd0tohjZPAx0obDWqa7jRd1zMWQdgfzPn
         vWcGi2oXBTaUvN3LSEjLXnvoq0nTYbDfbXl8IHfLeXREmCpShyN+SSa19k+RoxVxu/fy
         iXBiaxYdzPJUNkuE/Xw0uy5IWs77cR6Rn6qwBpcXskZn+T9NPDE7NDbstBFz42qdZegG
         4F1qMl9NZzVrUlPcVskDBa8h33yhBcAVeWcDJ0gdRftDPsLDrM1YnUHEPIcEmy9wUp61
         E+xg==
X-Forwarded-Encrypted: i=1; AJvYcCXVIt6MhEeAK7HHETkk/Wp/uPTpDicPc2SkYaaVRm4W+AMAJ4kzS/FF0LHgQ9BF8LJgW/qaTiqirfA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YydiGqq0J79ainhzKETGwzNtL+r/uopxXzqbv11bdSHuqYeqnls
	YRlDPqMxtgYSVW8DbpAzY7kyGBQqqrFXebbe8mn9tfa4naxSP2ZDUFUfFQhtZY0=
X-Gm-Gg: ASbGncs9sLoJmOY5lMNleeB6rWufJYOqPlXr5fFSVguzdTvnJvJ1RaDOx+P4X3OICK7
	18bSCeK6zo8v6lsnWW6LoLW7cnpDy7j4Tn5b0G5oxUsZQV7qDotoCWpfoPqFFl5iDc+l4BlYnup
	A8mi8edDs9Ewd03GAe9muv1gcuMvZRJnUZJdbBVSW2t/UkynH3/tM7FrajRJzLZPd1wp2qYdFEa
	3l90gRvmy+HUG6VTpUXR6C3v3euZqF36lFcWAJ/SLolZGmD7ueKfM8yV8uom/QnnfCUTRo2MsdE
	Azn4jYkVJKixnKBDhWCpMOwk2Vq6AUCpmR62rB3GbV3gQAVRC+zABRCvzMs1A7SZPm854weUSB9
	pDD16AA==
X-Google-Smtp-Source: AGHT+IEm3k+cp94ev9fEGRBBVX2OylrgNWBrIgvqSqgsnNGiV6fuW2HwVBeeTrWshPNtX4uNU0gywA==
X-Received: by 2002:a05:6000:4603:b0:382:38e6:1eb3 with SMTP id ffacd0b85a97d-38a221ffbcamr44088822f8f.30.1736268361744;
        Tue, 07 Jan 2025 08:46:01 -0800 (PST)
Message-ID: <236583ca-a9e7-4354-86b7-e27aba0b0e2e@suse.com>
Date: Tue, 7 Jan 2025 17:46:00 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 4/7] xen: add bitmap to indicate per-domain state
 changes
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <20250107101711.5980-1-jgross@suse.com>
 <20250107101711.5980-5-jgross@suse.com>
 <b77141df-fa14-426a-937f-42693d1caeb9@suse.com>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <b77141df-fa14-426a-937f-42693d1caeb9@suse.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------NS2cgfNO7fcBGpcJrs4gyAVo"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------NS2cgfNO7fcBGpcJrs4gyAVo
Content-Type: multipart/mixed; boundary="------------JL0EmhrgxgpWDJkwKzyNi4Y7";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
Message-ID: <236583ca-a9e7-4354-86b7-e27aba0b0e2e@suse.com>
Subject: Re: [PATCH v6 4/7] xen: add bitmap to indicate per-domain state
 changes
References: <20250107101711.5980-1-jgross@suse.com>
 <20250107101711.5980-5-jgross@suse.com>
 <b77141df-fa14-426a-937f-42693d1caeb9@suse.com>
In-Reply-To: <b77141df-fa14-426a-937f-42693d1caeb9@suse.com>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------JL0EmhrgxgpWDJkwKzyNi4Y7
Content-Type: multipart/mixed; boundary="------------0W2c3mV91g5x7ezp9ynggHLq"

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

T24gMDcuMDEuMjUgMTc6MTQsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAwNy4wMS4yMDI1
IDExOjE3LCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0KPj4gQWRkIGEgYml0bWFwIHdpdGggb25l
IGJpdCBwZXIgcG9zc2libGUgZG9taWQgaW5kaWNhdGluZyB0aGUgcmVzcGVjdGl2ZQ0KPj4g
ZG9tYWluIGhhcyBjaGFuZ2VkIGl0cyBzdGF0ZSAoY3JlYXRlZCwgZGVsZXRlZCwgZHlpbmcs
IGNyYXNoZWQsDQo+PiBzaHV0ZG93bikuDQo+Pg0KPj4gUmVnaXN0ZXJpbmcgdGhlIFZJUlFf
RE9NX0VYQyBldmVudCB3aWxsIHJlc3VsdCBpbiBzZXR0aW5nIHRoZSBiaXRzIGZvcg0KPj4g
YWxsIGV4aXN0aW5nIGRvbWFpbnMgYW5kIHJlc2V0dGluZyBhbGwgb3RoZXIgYml0cy4NCj4+
DQo+PiBBcyB0aGUgdXNhZ2Ugb2YgdGhpcyBiaXRtYXAgaXMgdGlnaHRseSBjb3VwbGVkIHdp
dGggdGhlIFZJUlFfRE9NX0VYQw0KPj4gZXZlbnQsIGl0IGlzIG1lYW50IHRvIGJlIHVzZWQg
b25seSBieSBhIHNpbmdsZSBjb25zdW1lciBpbiB0aGUgc3lzdGVtLA0KPj4ganVzdCBsaWtl
IHRoZSBWSVJRX0RPTV9FWEMgZXZlbnQuDQo+Pg0KPj4gUmVzZXR0aW5nIGEgYml0IHdpbGwg
YmUgZG9uZSBpbiBhIGZ1dHVyZSBwYXRjaC4NCj4+DQo+PiBUaGlzIGluZm9ybWF0aW9uIGlz
IG5lZWRlZCBmb3IgWGVuc3RvcmUgdG8ga2VlcCB0cmFjayBvZiBhbGwgZG9tYWlucy4NCj4+
DQo+PiBTaWduZWQtb2ZmLWJ5OiBKdWVyZ2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+DQo+
PiAtLS0NCj4+IFYyOg0KPj4gLSB1c2UgRE9NSURfRklSU1RfUkVTRVJWRUQgaW5zdGVhZCBv
ZiBET01JRF9NQVNLICsgMSAoSmFuIEJldWxpY2gpDQo+PiAtIHVzZSBjb25zdCAoSmFuIEJl
dWxpY2gpDQo+PiAtIG1vdmUgY2FsbCBvZiBkb21haW5fcmVzZXRfc3RhdGVzKCkgaW50byBl
dnRjaG5fYmluZF92aXJxKCkgKEphbiBCZXVsaWNoKQ0KPj4gLSBkeW5hbWljYWxseSBhbGxv
Y2F0ZSBkb21fc3RhdGVfY2hhbmdlZCBiaXRtYXAgKEphbiBCZXVsaWNoKQ0KPj4gVjM6DQo+
PiAtIHVzZSB4dnphbGxvY19hcnJheSgpIChKYW4gQmV1bGljaCkNCj4+IC0gZG9uJ3QgcmVu
YW1lIGV4aXN0aW5nIGxhYmVsIChKYW4gQmV1bGljaCkNCj4+IFY0Og0KPj4gLSBhZGQgX19y
ZWFkX21vc3RseSAoSmFuIEJldWxpY2gpDQo+PiAtIHVzZSBfX3NldF9iaXQoKSAoSmFuIEJl
dWxpY2gpDQo+IA0KPiBUaGlzIGNoYW5nZSBsb29rcyB0byBoYXZlIGJlZW4gbG9zdCwgLi4u
DQo+IA0KPj4gLSBmaXggZXJyb3IgaGFuZGxpbmcgaW4gZXZ0Y2huX2JpbmRfdmlycSgpIChK
YW4gQmV1bGljaCkNCj4+IFY1Og0KPj4gLSBkb21haW5faW5pdF9zdGF0ZXMoKSBtYXkgYmUg
Y2FsbGVkIG9ubHkgaWYgZXZ0Y2huX2JpbmRfdmlycSgpIGhhcyBiZWVuDQo+PiAgICBjYWxs
ZWQgdmFsaWRseSAoSmFuIEJldWxpY2gpDQo+PiBWNjoNCj4+IC0gZ3VhcmQgZG9tX3N0YXRl
X2NoYW5nZWQgYml0bWFwIHdpdGggZC0+ZXZlbnRfbG9jayAoSmFuIEJldWxpY2gpDQo+IA0K
PiAuLi4gd2l0aG91dCBpdCBiZWluZyBtZW50aW9uZWQgYW55d2hlcmUsIGFuZCB3aXRob3V0
IGl0IGJlY29taW5nIGNsZWFyIHdoeQ0KPiBpdCB3b3VsZCBoYXZlIG5lZWRlZCB1bmRvaW5n
Lg0KDQpPaCwgdGhhbmtzIGZvciBzcG90dGluZy4gSSBjaGFuZ2VkIHRoYXQgYnkgYWNjaWRl
bnQgYW5kIG1pc3NlZCB0byB1bmRvDQp0aGlzIGNoYW5nZS4NCg0KPiANCj4+IC0tLSBhL3hl
bi9jb21tb24vZG9tYWluLmMNCj4+ICsrKyBiL3hlbi9jb21tb24vZG9tYWluLmMNCj4+IEBA
IC0zNSw2ICszNSw3IEBADQo+PiAgICNpbmNsdWRlIDx4ZW4vaXJxLmg+DQo+PiAgICNpbmNs
dWRlIDx4ZW4vYXJnby5oPg0KPj4gICAjaW5jbHVkZSA8eGVuL2xsYy1jb2xvcmluZy5oPg0K
Pj4gKyNpbmNsdWRlIDx4ZW4veHZtYWxsb2MuaD4NCj4+ICAgI2luY2x1ZGUgPGFzbS9wMm0u
aD4NCj4+ICAgI2luY2x1ZGUgPGFzbS9wcm9jZXNzb3IuaD4NCj4+ICAgI2luY2x1ZGUgPHB1
YmxpYy9zY2hlZC5oPg0KPj4gQEAgLTEzOSw2ICsxNDAsNTEgQEAgYm9vbCBfX3JlYWRfbW9z
dGx5IHZtdHJhY2VfYXZhaWxhYmxlOw0KPj4gICANCj4+ICAgYm9vbCBfX3JlYWRfbW9zdGx5
IHZwbXVfaXNfYXZhaWxhYmxlOw0KPj4gICANCj4+ICtzdGF0aWMgdW5zaWduZWQgbG9uZyAq
X19yZWFkX21vc3RseSBkb21fc3RhdGVfY2hhbmdlZDsNCj4+ICsNCj4+ICtpbnQgZG9tYWlu
X2luaXRfc3RhdGVzKHZvaWQpDQo+PiArew0KPj4gKyAgICBjb25zdCBzdHJ1Y3QgZG9tYWlu
ICpkOw0KPj4gKw0KPj4gKyAgICBBU1NFUlQoIWRvbV9zdGF0ZV9jaGFuZ2VkKTsNCj4+ICsg
ICAgQVNTRVJUKHJ3X2lzX3dyaXRlX2xvY2tlZCgmY3VycmVudC0+ZG9tYWluLT5ldmVudF9s
b2NrKSk7DQo+IA0KPiByd19pc193cml0ZV9sb2NrZWRfYnlfbWUoKT8NCg0KWWVzLCBwcm9i
YWJseSBiZXR0ZXIuDQoNCj4gDQo+PiArICAgIGRvbV9zdGF0ZV9jaGFuZ2VkID0geHZ6YWxs
b2NfYXJyYXkodW5zaWduZWQgbG9uZywNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBCSVRTX1RPX0xPTkdTKERPTUlEX0ZJUlNUX1JFU0VSVkVEKSk7DQo+
PiArICAgIGlmICggIWRvbV9zdGF0ZV9jaGFuZ2VkICkNCj4+ICsgICAgICAgIHJldHVybiAt
RU5PTUVNOw0KPj4gKw0KPj4gKyAgICByY3VfcmVhZF9sb2NrKCZkb21saXN0X3JlYWRfbG9j
ayk7DQo+PiArDQo+PiArICAgIGZvcl9lYWNoX2RvbWFpbiAoIGQgKQ0KPj4gKyAgICAgICAg
c2V0X2JpdChkLT5kb21haW5faWQsIGRvbV9zdGF0ZV9jaGFuZ2VkKTsNCj4+ICsNCj4+ICsg
ICAgcmN1X3JlYWRfdW5sb2NrKCZkb21saXN0X3JlYWRfbG9jayk7DQo+PiArDQo+PiArICAg
IHJldHVybiAwOw0KPj4gK30NCj4+ICsNCj4+ICt2b2lkIGRvbWFpbl9kZWluaXRfc3RhdGVz
KGNvbnN0IHN0cnVjdCBkb21haW4gKmQpDQo+PiArew0KPj4gKyAgICBBU1NFUlQocndfaXNf
d3JpdGVfbG9ja2VkKCZkLT5ldmVudF9sb2NrKSk7DQo+IA0KPiBBZ2Fpbi4NCg0KWWVzLg0K
DQoNCkp1ZXJnZW4NCg==
--------------0W2c3mV91g5x7ezp9ynggHLq
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

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

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

--------------0W2c3mV91g5x7ezp9ynggHLq--

--------------JL0EmhrgxgpWDJkwKzyNi4Y7--

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

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

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmd9WkgFAwAAAAAACgkQsN6d1ii/Ey+n
XQf8DH81Y/VZ06q6r6ASpK43Mj8UZod3GCuUqTynddHGKx/hdLOVZyHzxG6Cft6jkBhxLj87Lv5q
SepmIsz5+91PnlQs0d29nvMaPunUQcTn7/jOmY+1tyv7/yJklKI7ZSB8VOUPDBSh2avh+6tsr2Kr
GMoKoPqQ7y/iZzUc91w5kJbf2KYuvCR33bfcyyYAEvBPIOKEn56pWgGWYFWzv0WI1ABfZ5zLVjlt
UpBb7h0JOGFn82vI/YIBSS51B21VAiyFqk2j8bTCVvCU6xDJF+xrs/ZErR7JbUPpvTvudsZWDmUw
eZ6FuzESi01sIQr3K4EIjYZ65T1jDN7pTYhAs775rw==
=6QLo
-----END PGP SIGNATURE-----

--------------NS2cgfNO7fcBGpcJrs4gyAVo--


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 16:46:30 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 16:46:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866674.1278013 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVCis-00045g-FW; Tue, 07 Jan 2025 16:46:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866674.1278013; Tue, 07 Jan 2025 16:46:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVCis-00045b-Ch; Tue, 07 Jan 2025 16:46:30 +0000
Received: by outflank-mailman (input) for mailman id 866674;
 Tue, 07 Jan 2025 16:46:29 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=1r68=T7=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVCir-0003do-Am
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 16:46:29 +0000
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com
 [2a00:1450:4864:20::334])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f0e05869-cd16-11ef-a0df-8be0dac302b0;
 Tue, 07 Jan 2025 17:46:28 +0100 (CET)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-4363ae65100so162799015e9.0
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 08:46:28 -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
 5b1f17b1804b1-43656b4432dsm632985345e9.41.2025.01.07.08.46.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 08:46:27 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f0e05869-cd16-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736268388; x=1736873188; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=N6vrKGTX0KxATwjBLqj5b/5b4OXXpH1B6XY960fwugQ=;
        b=GQVChVJbLPwVlwSkacvj+WqbYrYtPWN0AKR7XMzAEgil2Kthxo4H3uMcQujbZUryDs
         yOWgPO7KpnCcnEVpYSE+3U6rxkCQd1JFnnPiCLzWWI9khpxMFAnRKXarL8R6RmvYNxZG
         mVadYcq9wMND/WiWvd5Vb5a5K9b9lkmBFahDNjMTXd3cU4Ruu0ooiH7tHgK0p6EwKt+N
         WXNLgt5veKQgBTC6LDHsLiqJT9sA+wrsz2XD8a9BK7Fz2UcaBpSVX1ZZ15DzEw8zlvmd
         jFpn1VMsQ37SObyvlBJyd7mEke1R3Ry0Q4rLAeW5dcmm9CGiQvg+VfFtLfDuseirqYgR
         /WHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736268388; x=1736873188;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=N6vrKGTX0KxATwjBLqj5b/5b4OXXpH1B6XY960fwugQ=;
        b=Zm4NSdjZCn2ViV0rYOjXYIq7k/ZvD6iSNkpKcQF4TOFBqqx0t+wBaBMEsn1pJ7x8Sk
         wAw8VKFIvgvFn/QymOKFJENuEAXaBOpWlTeTiKnPLiy33EYVVKGBmpqU650Lb1fO7Jtv
         EWSfhD0UC1B05rXWi6l5ATpKo2Q70OmBj0Mdei/M+QZDGwDh0UfkwhkvMy6NQqSrIASj
         sANbH4p74IWuMKKMUdMjU4UpAOkMmoZ4Irm2pkO1/Vb+dbLP6ik0wddCbgvA1N5M7igc
         P+HuQqU8WLRMfYNyC1L7S/nQRjzgzDYk5mxDTp4kPrTWMYwJHpMjAPgNuf+45jZ2lSAj
         vyeg==
X-Forwarded-Encrypted: i=1; AJvYcCVNGEK4OjW5pOeRVfk8oqPt/vduLGdZTX3/5gIyqtWR3VqHM6Dm7HicOl3HmZS06zGPWpZRj7DxMHc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyZfWTH+cK3bsUYA5sjr9UFTUPjFPuEA/BVLhnsQaD7IC9Njpmd
	ZBwenCrqU8dJBuyX8Jt2UGQ2jq1x1ulFxPDh2gjiae34o1lUS9usIjF/SKeydg==
X-Gm-Gg: ASbGnctCaoqSE9sdjXTMkD/Tyj98CIzauhRemqm/svYJfUMymqrrqRur0hGmUu7LwWh
	vYEKUdH0VY6QdIrte6mi7y+b+jGSDXZKu44l26PzpPjJbUeHeADlCKN+4nt+BOFY/752qTL7uZ+
	KlD3LKJiPTffyWFlJzU3cPo6w3G1zV7ZotMh2c6NzLzQI2dlC/IdtoKmgVak4XeJMFGPR5qf7c4
	8ABc+zG8qnPxbHJW/ZWdIT0wmvyUY2rirtWs1Eg39pN+dp/A1HR2d+kGfhabDKgaQ/P+ACyYTvy
	CNEFzQlhwrUdaffX+tTu/A/7s+LebGLoCu3gezbP+w==
X-Google-Smtp-Source: AGHT+IGzqsDV2iv6LmrqPOACmPWY1p+/WDxdA6pLWNC++Db6n8csHiOcXuEgOxMQS/qFT84QcPYUXQ==
X-Received: by 2002:a05:6000:4618:b0:37d:4833:38f5 with SMTP id ffacd0b85a97d-38a221f9405mr50932907f8f.30.1736268388167;
        Tue, 07 Jan 2025 08:46:28 -0800 (PST)
Message-ID: <d6eb70a7-5895-4471-95b3-609f133fa457@suse.com>
Date: Tue, 7 Jan 2025 17:46:26 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/2] x86: Add Support for Paging-Write Feature
To: =?UTF-8?Q?Petr_Bene=C5=A1?= <w1benny@gmail.com>
Cc: Tamas K Lengyel <tamas@tklengyel.com>,
 Alexandru Isaila <aisaila@bitdefender.com>,
 Petre Pircalabu <ppircalabu@bitdefender.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <cover.1735837806.git.w1benny@gmail.com>
 <31a1ff2d5d1e17bb73231e008f1e47c501bb3ce8.1735837806.git.w1benny@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <31a1ff2d5d1e17bb73231e008f1e47c501bb3ce8.1735837806.git.w1benny@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 02.01.2025 18:13, Petr Beneš wrote:
> --- a/xen/arch/x86/mm/p2m-ept.c
> +++ b/xen/arch/x86/mm/p2m-ept.c
> @@ -154,27 +154,39 @@ static void ept_p2m_type_to_flags(const struct p2m_domain *p2m,
>          case p2m_access_n:
>          case p2m_access_n2rwx:
>              entry->r = entry->w = entry->x = 0;
> +            entry->pw = 0;
>              break;
>          case p2m_access_r:
>              entry->w = entry->x = 0;
> +            entry->pw = 0;
>              break;
>          case p2m_access_w:
>              entry->r = entry->x = 0;
> +            entry->pw = 0;
>              break;
>          case p2m_access_x:
>              entry->r = entry->w = 0;
> +            entry->pw = 0;
>              break;
>          case p2m_access_rx:
>          case p2m_access_rx2rw:
>              entry->w = 0;
> +            entry->pw = 0;
>              break;
>          case p2m_access_wx:
>              entry->r = 0;
> +            entry->pw = 0;
>              break;
>          case p2m_access_rw:
>              entry->x = 0;
> +            entry->pw = 0;
>              break;           
>          case p2m_access_rwx:
> +            entry->pw = 0;
> +            break;
> +        case p2m_access_r_pw:
> +            entry->w = entry->x = 0;
> +            entry->pw = !!cpu_has_vmx_ept_paging_write;
>              break;
>      }

Hmm ... Instead of you touching the bit in every one of the case blocks,
I was expecting you to clear the bit ahead of the switch(), accepting a
double update in the p2m_access_r_pw case.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 16:48:17 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 16:48:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866688.1278024 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVCka-0004kz-Vw; Tue, 07 Jan 2025 16:48:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866688.1278024; Tue, 07 Jan 2025 16:48:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVCka-0004ks-SV; Tue, 07 Jan 2025 16:48:16 +0000
Received: by outflank-mailman (input) for mailman id 866688;
 Tue, 07 Jan 2025 16:48:15 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Qdqe=T7=suse.com=jgross@srs-se1.protection.inumbo.net>)
 id 1tVCkZ-0004km-F9
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 16:48:15 +0000
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com
 [2a00:1450:4864:20::52b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2f6189dc-cd17-11ef-99a4-01e77a169b0f;
 Tue, 07 Jan 2025 17:48:13 +0100 (CET)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-5d3dce16a3dso28011275a12.1
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 08:48:13 -0800 (PST)
Received: from ?IPV6:2003:e5:8731:2800:842d:42a0:5992:3595?
 (p200300e587312800842d42a059923595.dip0.t-ipconnect.de.
 [2003:e5:8731:2800:842d:42a0:5992:3595])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d80676f26dsm25271142a12.20.2025.01.07.08.48.12
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 08:48:12 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2f6189dc-cd17-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736268493; x=1736873293; darn=lists.xenproject.org;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=3vmjPXkNiKoR/nqNJyerB4vd1D1VWkaiKYfK3WUe91c=;
        b=fFt8VQvLFX68Z0fjQow2XAPrW9TxBph9X7EuaofEzfcbDCnvh64FKTeXN2p864ebQd
         L4y5FwRn6B2BRl0nUET+1KsbtFktKfMxkN+EjJbSgQlcL2RgWVTBhSi45YUA3DXzTEUH
         C7dCMoStHQXXjZNduYphiRJEChNS/eqbKL/vTLgaUfBvyYpI2C0J7tvY/3kxg7PNKk3v
         B1oCU01Tdd0QZjCuWyBmQHZ4HLs6zv3swGuygUkBVKCERu5zyCa8j8axzB0Dedk302sH
         CnERxliunMb7RmC2STqZpNXqq9r6ZQ2aXYmbqkNqteb/0Isy/PZG8ErL+/iuvEEpiM3p
         MyqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736268493; x=1736873293;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=3vmjPXkNiKoR/nqNJyerB4vd1D1VWkaiKYfK3WUe91c=;
        b=TLNFiqWELK/9UDu86m2AGG4EaWpvt4w7t/X2OweEHvbv5upH6hOOSZJpKO/5ePVG4e
         yxPchHmSA7HvRumkekqNToAcwbGA+Rwd2pUeGG9v/cXP/0o74Jz0F9hsQpHHp9nJoFHr
         naZcnRnKgVyv4YpsQfBWGfsJg+goiHM/lMqTuKPHrOHCxbGdnBtQoIrBSIImpZESyHDo
         LWCix8clNStFyi4oBNatb8b7D4BKeiC2YFobYb+TLNz0FDLBO+E758p8Cl+tpJkGCnet
         AfzMhRBZHrtPRG6CFsyA098mxwiMOHYGfI0s8Oo2CnQECUlj/KbDkoe0ymjFzsmK0pkv
         ngMg==
X-Forwarded-Encrypted: i=1; AJvYcCVof2rwth7MMicvX2jhn5dTbQMF3HQzqV6DXRk4qyIH/7NAl67a2+V/NQohgbT8Gn0s2gJ+vPKPwIM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzEUnxoA0Fo2ln74D42t11uYQvUSC7CLnl7y3GfZaVH0CHuFvUz
	MLE30J9/7TW5EN3OZbBH4Q/8o+gtwiW8W7MJiZrMHNis8aG4/+TeJ5UxukuUXDI=
X-Gm-Gg: ASbGnctQJEgA8O2txWesRcAXwnY88fk5BCTty9JJk1UCCPRNG8WfhRtVwkT+vvjjqDg
	rLH7CcPe1tez9TQzK89AgZ/alQBn5DQ4JyeloHTD/Iy5QmIYN1aVp9XX0AdcZ/RnMGFn86R6h38
	wsLmcyTEtetFup2RVQoYm+geH3GGtDeCzM1SvuZu/NxcRyyeubHQSlQHMuOsbO0W/0AKHaLICDE
	9cHTXhra2rtoBDNMq9DnjB4mRgvyb7SJkDwU48+j7/yiFHmIx+/O0dLnfjnUCQlPRWFt+Jlutko
	K5xqGf8BikkSCTFWQbEob5wSrtsACgkMsIlvXtitfbKIhsz7ouQaZ94d9ogEWzoh7pL703XsKrt
	YBLs9rQ==
X-Google-Smtp-Source: AGHT+IF9xb3JfpPnY56pH++ie3cFsshgexkPJmbAFIG5k8yPccc3eGkKCOjt/E5y4ldZiXMTZ7L6rA==
X-Received: by 2002:a05:6402:42c3:b0:5d4:c0c:70f9 with SMTP id 4fb4d7f45d1cf-5d95e8cf064mr2974415a12.6.1736268492968;
        Tue, 07 Jan 2025 08:48:12 -0800 (PST)
Message-ID: <81221a18-d6f8-418d-841a-8aa43420df09@suse.com>
Date: Tue, 7 Jan 2025 17:48:11 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 5/7] xen: add new domctl get_changed_domain
To: Jan Beulich <jbeulich@suse.com>
Cc: "Daniel P. Smith" <dpsmith@apertussolutions.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <20250107101711.5980-1-jgross@suse.com>
 <20250107101711.5980-6-jgross@suse.com>
 <781daba7-5d6f-4d86-bce4-c5aa9d135513@suse.com>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <781daba7-5d6f-4d86-bce4-c5aa9d135513@suse.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------hZmKMrjhkNeVRsMyKk5MOBjE"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------hZmKMrjhkNeVRsMyKk5MOBjE
Content-Type: multipart/mixed; boundary="------------kIYTm0ezGH200OMoLai431hL";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "Daniel P. Smith" <dpsmith@apertussolutions.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
Message-ID: <81221a18-d6f8-418d-841a-8aa43420df09@suse.com>
Subject: Re: [PATCH v6 5/7] xen: add new domctl get_changed_domain
References: <20250107101711.5980-1-jgross@suse.com>
 <20250107101711.5980-6-jgross@suse.com>
 <781daba7-5d6f-4d86-bce4-c5aa9d135513@suse.com>
In-Reply-To: <781daba7-5d6f-4d86-bce4-c5aa9d135513@suse.com>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------kIYTm0ezGH200OMoLai431hL
Content-Type: multipart/mixed; boundary="------------HXhcw75K4GtuBuelXCONw4nV"

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

T24gMDcuMDEuMjUgMTc6MjgsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAwNy4wMS4yMDI1
IDExOjE3LCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0KPj4gLS0tIGEveGVuL2NvbW1vbi9kb21h
aW4uYw0KPj4gKysrIGIveGVuL2NvbW1vbi9kb21haW4uYw0KPj4gQEAgLTE4NSw2ICsxODUs
NzYgQEAgc3RhdGljIHZvaWQgZG9tYWluX2NoYW5nZWRfc3RhdGUoY29uc3Qgc3RydWN0IGRv
bWFpbiAqZCkNCj4+ICAgICAgIHVubG9ja19kb21fZXhjX2hhbmRsZXIoaGRsKTsNCj4+ICAg
fQ0KPj4gICANCj4+ICtzdGF0aWMgdm9pZCBzZXRfZG9tYWluX3N0YXRlX2luZm8oc3RydWN0
IHhlbl9kb21jdGxfZ2V0X2RvbWFpbl9zdGF0ZSAqaW5mbywNCj4+ICsgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgY29uc3Qgc3RydWN0IGRvbWFpbiAqZCkNCj4+ICt7DQo+
PiArICAgIGluZm8tPnN0YXRlID0gWEVOX0RPTUNUTF9HRVRET01TVEFURV9TVEFURV9FWElT
VDsNCj4+ICsgICAgaWYgKCBkLT5pc19zaHV0X2Rvd24gKQ0KPj4gKyAgICAgICAgaW5mby0+
c3RhdGUgfD0gWEVOX0RPTUNUTF9HRVRET01TVEFURV9TVEFURV9TSFVURE9XTjsNCj4+ICsg
ICAgaWYgKCBkLT5pc19keWluZyA9PSBET01EWUlOR19keWluZyApDQo+PiArICAgICAgICBp
bmZvLT5zdGF0ZSB8PSBYRU5fRE9NQ1RMX0dFVERPTVNUQVRFX1NUQVRFX0RZSU5HOw0KPj4g
KyAgICBpZiAoIGQtPmlzX2R5aW5nID09IERPTURZSU5HX2RlYWQgKQ0KPj4gKyAgICAgICAg
aW5mby0+c3RhdGUgfD0gWEVOX0RPTUNUTF9HRVRET01TVEFURV9TVEFURV9ERUFEOw0KPj4g
KyAgICBpbmZvLT51bmlxdWVfaWQgPSBkLT51bmlxdWVfaWQ7DQo+PiArfQ0KPj4gKw0KPj4g
K2ludCBnZXRfZG9tYWluX3N0YXRlKHN0cnVjdCB4ZW5fZG9tY3RsX2dldF9kb21haW5fc3Rh
dGUgKmluZm8sIHN0cnVjdCBkb21haW4gKmQsDQo+PiArICAgICAgICAgICAgICAgICAgICAg
ZG9taWRfdCAqZG9taWQpDQo+PiArew0KPj4gKyAgICB1bnNpZ25lZCBpbnQgZG9tOw0KPj4g
KyAgICBpbnQgcmMgPSAtRU5PRU5UOw0KPj4gKyAgICBzdHJ1Y3QgZG9tYWluICpoZGw7DQo+
PiArDQo+PiArICAgIGlmICggaW5mby0+cGFkMCB8fCBpbmZvLT5wYWQxICkNCj4+ICsgICAg
ICAgIHJldHVybiAtRUlOVkFMOw0KPj4gKw0KPj4gKyAgICBpZiAoIGQgKQ0KPj4gKyAgICB7
DQo+PiArICAgICAgICBzZXRfZG9tYWluX3N0YXRlX2luZm8oaW5mbywgZCk7DQo+PiArDQo+
PiArICAgICAgICByZXR1cm4gMDsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICAvKg0KPj4g
KyAgICAgKiBPbmx5IGRvbWFpbiByZWdpc3RlcmVkIGZvciBWSVJRX0RPTV9FWEMgZXZlbnQg
aXMgYWxsb3dlZCB0byBxdWVyeQ0KPj4gKyAgICAgKiBkb21haW5zIGhhdmluZyBjaGFuZ2Vk
IHN0YXRlLg0KPj4gKyAgICAgKi8NCj4+ICsgICAgaWYgKCAhZG9tYWluX2hhbmRsZXNfZ2xv
YmFsX3ZpcnEoY3VycmVudC0+ZG9tYWluLCBWSVJRX0RPTV9FWEMpICkNCj4+ICsgICAgICAg
IHJldHVybiAtRUFDQ0VTOw0KPj4gKw0KPj4gKyAgICBoZGwgPSBsb2NrX2RvbV9leGNfaGFu
ZGxlcigpOw0KPiANCj4gSW5zdGVhZCBvZiBsZWF2aW5nIGEgc21hbGwgd2luZG93IGZvciBy
YWNlcyBiZXR3ZWVuIHRoZSBpZigpIGFuZCB0aGlzDQo+IGZ1bmN0aW9uIGNhbGwsIGNhbid0
IHlvdSBzaW1wbHkgY29tcGFyZSBoZGwgYWdhaW5zdCBjdXJyZW50LT5kb21haW4/DQoNCkdv
b2QgaWRlYS4NCg0KPiANCj4+ICsgICAgd2hpbGUgKCBkb21fc3RhdGVfY2hhbmdlZCApDQo+
PiArICAgIHsNCj4+ICsgICAgICAgIGRvbSA9IGZpbmRfZmlyc3RfYml0KGRvbV9zdGF0ZV9j
aGFuZ2VkLCBET01JRF9NQVNLICsgMSk7DQo+PiArICAgICAgICBpZiAoIGRvbSA+PSBET01J
RF9GSVJTVF9SRVNFUlZFRCApDQo+PiArICAgICAgICAgICAgYnJlYWs7DQo+PiArICAgICAg
ICBpZiAoIHRlc3RfYW5kX2NsZWFyX2JpdChkb20sIGRvbV9zdGF0ZV9jaGFuZ2VkKSApDQo+
IA0KPiBBcyB0aGlzIGlzIG5vdyBydW5uaW5nIHVuZGVyIGxvY2ssIGRvZXMgaXQgcmVhbGx5
IG5lZWQgdG8gYmUgdGVzdC1hbmQtY2xlYXI/DQo+IFdoYXQgbWVjaGFuaXNtIHdvdWxkIGFs
bG93IHRoZSBmbGFnIHRvIGJlIGNsZWFyZWQgYmV0d2VlbiB0aGUgZmluZC0xc3QgYW5kDQo+
IGhlcmU/IFBsdXMsIGxpa2UgZm9yIHBhdGNoIDQsIEkgdGhpbmsgaXQgY291bGQgYmUgX19j
bGVhcl9iaXQoKSBoZXJlLg0KDQpJdCBpcyBvbmx5IHVuZGVyIHJlYWRfbG9jaygpLCBzbyB0
aGVyZSBhcmUgY29uY3VycmVudCBjYWxscyBwb3NzaWJsZS4NCkkgZG9uJ3QgdGhpbmsgd2Ug
d2FudCB0byB1c2Ugd3JpdGVfbG9jaygpIGhlcmUsIGRvIHdlPw0KDQoNCkp1ZXJnZW4NCg==

--------------HXhcw75K4GtuBuelXCONw4nV
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

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

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

--------------HXhcw75K4GtuBuelXCONw4nV--

--------------kIYTm0ezGH200OMoLai431hL--

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

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

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmd9WswFAwAAAAAACgkQsN6d1ii/Ey80
lQf+IpBZgtH4yG6uThGm4mHx/TrkyBTd3K2FYQtrX1iAcTNCMA0HGh0gOdjqMpiPFz8TIOJnyfWE
DifDO4Sm59B/9VkOdVCORpM+qeUwBY5Y/E3Jpd4+ci31rDMdPcciWt7blhDyUF2p0q25Qk02KWkM
4cMZksISo4BaHePj8NOb6l0urgtnxOzhq88zIxtQrWlYotjOJ6Vp7zlW8e2jWttu6t4mjXLOZ7pC
/nmrxuyweLEK+uVyLgkn9BxuHDZMRSTuQJw8luXepWRz58Qc+0RdBKB16oKxD/DltghCC4ujzCK0
Bs1ru1RszKvwrEF5Duc1uHueUAY67UT8uPDE1/LhVA==
=h/wc
-----END PGP SIGNATURE-----

--------------hZmKMrjhkNeVRsMyKk5MOBjE--


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 16:51:55 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 16:51:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866695.1278034 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVCo3-0006RM-Df; Tue, 07 Jan 2025 16:51:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866695.1278034; Tue, 07 Jan 2025 16:51:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVCo3-0006RF-AE; Tue, 07 Jan 2025 16:51:51 +0000
Received: by outflank-mailman (input) for mailman id 866695;
 Tue, 07 Jan 2025 16:51: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
 <SRS0=FVI7=T7=amd.com=Michal.Orzel@srs-se1.protection.inumbo.net>)
 id 1tVCo1-0006Pn-C9
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 16:51:49 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on2062a.outbound.protection.outlook.com
 [2a01:111:f403:2413::62a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id add88d12-cd17-11ef-99a4-01e77a169b0f;
 Tue, 07 Jan 2025 17:51:47 +0100 (CET)
Received: from SA9PR13CA0086.namprd13.prod.outlook.com (2603:10b6:806:23::31)
 by IA1PR12MB6626.namprd12.prod.outlook.com (2603:10b6:208:3a2::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8314.17; Tue, 7 Jan
 2025 16:51:38 +0000
Received: from SN1PEPF0002636D.namprd02.prod.outlook.com
 (2603:10b6:806:23:cafe::96) by SA9PR13CA0086.outlook.office365.com
 (2603:10b6:806:23::31) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8335.10 via Frontend Transport; Tue,
 7 Jan 2025 16:51:38 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SN1PEPF0002636D.mail.protection.outlook.com (10.167.241.138) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8335.7 via Frontend Transport; Tue, 7 Jan 2025 16:51:37 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 7 Jan
 2025 10:51:37 -0600
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 7 Jan
 2025 10:51:36 -0600
Received: from [10.71.192.184] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Tue, 7 Jan 2025 10:51:34 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: add88d12-cd17-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=M1//WkqFWFrLQ37qdUoWZT/1WQJRpNgjY36df5KeoT1Y7OPPQn9RWKtYrqGVngnuPrEBQQPTNr1ypXaOvk6TCZbFUfo2WcR+GjsLvhjBdkwlXv1aYpZ4eMR308qJKvr2FtXl38UxHU/Pl+MQUnbdqk21HE/KCyvO3aBJERm3esDRntOEuafieG6o/NOQRfJP/ZkP8TgmaXhgoQ6DLjqnTRylMzRtBEJw79SKtteZSaiTpyqtACdB2psVFz7UsFYqV66x0+rLv6VpXrhjF2n0lFdxTbAu2u/L+VU5/yBtLuH9AA3erWCcUsCYiXePdNdJAnWqi8JrfCaQ8ZE7h18RWA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=pMNDAyDegdFg5HceiyDc3R+eEYZtHl+PLMdUQ/z85EU=;
 b=BhrSGpJ1qId8Tz2sDZ+F35j6955hPYf6V6j2uN5zRfm/QjDfU1lguLk2E5v8JsimHBde5c6xVeO0GrerkkOdNUUcZ6HckpqR442GoMQltLVEpQI7wePGADcVjToxZdmtlF8TMezO3XvMfV1a6TwpMWJE1Hwf9r0DSufhPtb756gGB40U7wMQxGB+EqYN3Rdz4f93qyoQA5Vc/2E4PY6cJ49CfeF+n3dDosiJkpzpGQyeflgm6O8zD27Wcl0+6E5crtSImJg+2pmCR/2cIj/55gruvmCz62M7HO6+IK/RT2Jjhk7apV3yu2zC55UBI1TKuQy05/LfLBYymprrC6wNvg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=xen.org smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=pMNDAyDegdFg5HceiyDc3R+eEYZtHl+PLMdUQ/z85EU=;
 b=cIrotDcezjp9ovb3YchOcm/qPPkAHVbyKPA31/Q9ZP6t/zjkG6Gk/lODcvxH8V6T0qY1Rtn/Bjq/vgw/nh+sxgxeD/Xk99EzCRe1kv0/QaN0tFwp0dhVDJsnpx4xuHkGSdXIVxORJ5I53/8pfTZw23ImCxzYS4p9VjBX3SrHB+s=
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: <5c153764-4a1d-4233-a9d2-fa5ec0aff6ac@amd.com>
Date: Tue, 7 Jan 2025 17:51:29 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [for-4.20] Re: [PATCH v12 12/12] xen/arm: add cache coloring
 support for Xen image
To: Julien Grall <julien@xen.org>, Jan Beulich <jbeulich@suse.com>, "Carlo
 Nonato" <carlo.nonato@minervasys.tech>
CC: <xen-devel@lists.xenproject.org>, <andrea.bastoni@minervasys.tech>,
	<marco.solieri@minervasys.tech>, Stefano Stabellini <sstabellini@kernel.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>, Volodymyr Babchuk
	<Volodymyr_Babchuk@epam.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
	<roger.pau@citrix.com>, Oleksii <oleksii.kurochko@gmail.com>
References: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
 <20241213162815.9196-13-carlo.nonato@minervasys.tech>
 <dbbc649f-b705-46b5-a071-760d688aa2cd@amd.com>
 <CAG+AhRWrXAYfKXXKfp6949vNMdGDy9qWOY11SKAigJuC8oUvDw@mail.gmail.com>
 <df0f831f-378f-4fa3-ae4f-b065f2ea566d@suse.com>
 <0062e0cf-0830-4d16-942d-348e6d33a2c4@xen.org>
Content-Language: en-US
From: Michal Orzel <michal.orzel@amd.com>
In-Reply-To: <0062e0cf-0830-4d16-942d-348e6d33a2c4@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Received-SPF: None (SATLEXMB05.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF0002636D:EE_|IA1PR12MB6626:EE_
X-MS-Office365-Filtering-Correlation-Id: 0fc6eb61-09c4-49fb-3f44-08dd2f3b8d74
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|376014|1800799024|7416014|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?RUl3bER3NFgrNkllN3FyOHlrVnh1NGJNTW5oa295WDAxWWJ6Tm91ZDBqVFRN?=
 =?utf-8?B?NFdRR2xuQk1TY05HdkUzMVpONVVhRlRSc1lhMDBVVFVPVDh5Q3lrTUdOa3hq?=
 =?utf-8?B?MW5GNFM4eTA0QmlOaDEwK2FnekVNKzVHWVlycTZRMVd4d2lpSVFaMXJkaUpN?=
 =?utf-8?B?a1Z0WVVYNjFEVllXWkpHUWp1eVp6MjZCdzdja2Y3aUtvMEtabnhjOUVldlhU?=
 =?utf-8?B?ajRRdmlDWEY1VDZDbU9UUEoyNnpQRVRzNTJFNUpEVk5mVVVDV2JFU2x5Wjgx?=
 =?utf-8?B?WXpEa2R4VXE4bVRVZllGdXA2b2hkeXZvMURUWEIzbkd4VFpuS2R3ODUxcmNT?=
 =?utf-8?B?b2pZejJyZTkydGR3NWNCUUppNnIwNFlIRUpZYUJrb0JWZVpQanJjeHZsRys0?=
 =?utf-8?B?RjY2OXUyMUJTSVRiUWJBVlJjNVNabEVpWU5HanVqelVGTGZxd1Arb0NkcnJw?=
 =?utf-8?B?NWNuNnVRZ1V6bTZnaWd5VkZMRVdTL3VKc3JHR0VGNkxKcmc0MzErQUlaZy9F?=
 =?utf-8?B?T2Yvc1hvcEVCVnVIR1Yyay9MYnYzMjlLSlZVOUY5bGx5MlJ0TXZyVk94Sits?=
 =?utf-8?B?bklTYjI4alVOeE9vR0FJNU9xcGZETlVYMG1aZ0V1Sm1pMklZaUFFZlIzcUpa?=
 =?utf-8?B?Y3UzNFZBRVZhUGkzdzBWZTY3SFVBci83TmUvVTBKVkFZVlkrMjV5c1lZTHJt?=
 =?utf-8?B?eUVxRDZ5SU5UQzgyY0NuUEowc3AwRVptU3NwNE5tcmE5QUNFMExFQTB0YUJj?=
 =?utf-8?B?VVFoSzJIdnF1dGVxdTJ5TGtEdnUyL2RvdzNVUWZzUG1lV1hHU3F4RkZwUE9O?=
 =?utf-8?B?VWdHdW5EdDZRK3FNYVVYOHlaOVA5V05tWUJrYTd1QUZhQm42eGluTFJycGFw?=
 =?utf-8?B?enF4NG1Rdno5aTl6dGR0K05GMFdhRm1rSEg3L0VSbUNRTkZscEFKajg3VWFp?=
 =?utf-8?B?dGdxZGxEclRORFRlWHFFbWMybXQ5YjB4bVQ5OHducGt3K2ZTQTA1cmFTY2Zk?=
 =?utf-8?B?bTJhS2s4cTVTMHppS0FMV1pYWURzUW51VDU2NjRqK1NwZVdQUDlFclkzdnBk?=
 =?utf-8?B?TUNTdzlSME9zcTJHRVR1dy9XU0pzTmtEWkc3eG0ySkZqRFVZT3k4NUpPcUJj?=
 =?utf-8?B?Ry8rQWg2WEtmT0ZmenBrYkc5ZE0vMGh5MkR2WkdSS3hjUFdkekx5cHBzd0FG?=
 =?utf-8?B?MklQUVgwL25FU2lpTWZzcDYxc0RVU2xNZG9PemlWTnJHemZPQ0krVktjZkk0?=
 =?utf-8?B?bDFCUXpzVERKQnN6cE1OVHZtSysxMHN0bUlER1J4bXNFWVp3UkhsMjBUQVNz?=
 =?utf-8?B?aTN2RVU5WkJPQVM3ckkxTWFHUkhhMXpjd2lRL0plUTBqNWJwdmtubVUzYjZ3?=
 =?utf-8?B?d0c4cjM5YXA4VmgwQzNhNHFwQkl2ZGdCbnA3RWsrVVZ2M1l3MTBHS0ZBcjYz?=
 =?utf-8?B?WTA2N1BxelBiSVlJTExoRkFRQ3NrUC9IUVo5b1hTaGUyZkxySEZEZFB4UDVt?=
 =?utf-8?B?Rlo1cGxGWkRsUEhSb3pmUVp5K3dVbnVvUkJvL3dGM2pKNm5Md2hkUTluV1M3?=
 =?utf-8?B?WDV0ZSsvZTRYYjNFWStqdk85UGhxM01vVDBYVmVCMTZIZTlleVBPUDh1MHRo?=
 =?utf-8?B?OThQMllrajBmWEhMRkRTdWhwcWQza1huOENFT010TWxMaEppK0t0Y3pWVENm?=
 =?utf-8?B?Q2E0Q05iRiswanBWM1RNcU5CcHJRQWFjS1ZYUnlsY1orRG9McmFoSjZnTHlx?=
 =?utf-8?B?cjlwbUFidHNqYWh4dnhYQzRqVmFvRmZSZk85RTRGUm1lYjRiNlZmaVhUQWRl?=
 =?utf-8?B?dlhOQnpvU0tPZTRQWnlDbEtzNDljS3pYMFdYMEJrWElscUp2Q2dTNGxZZjd1?=
 =?utf-8?B?OGtKVDRiblVLaUFTZGFoS3QzalNxQXRuTDU4Y0s2VU9HTER0a0QzeWtVR0tN?=
 =?utf-8?B?REs3YTBueW9MSFhINmNGQWJWczJVckVoOUZiVnUxcm12VTNmTkF4UWpVNlJS?=
 =?utf-8?Q?AhOJ7Fd+oHpAwcp6U/JVa+51bfVj2w=3D?=
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:(13230040)(36860700013)(376014)(1800799024)(7416014)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jan 2025 16:51:37.8478
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 0fc6eb61-09c4-49fb-3f44-08dd2f3b8d74
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:
	SN1PEPF0002636D.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB6626



On 07/01/2025 17:42, Julien Grall wrote:
> 
> 
> Hi,
> 
> On 16/12/2024 14:36, Jan Beulich wrote:
>> On 16.12.2024 15:28, Carlo Nonato wrote:
>>> On Mon, Dec 16, 2024 at 2:56 PM Michal Orzel <michal.orzel@amd.com> wrote:
>>>> On 13/12/2024 17:28, Carlo Nonato wrote:
>>>>> --- a/xen/arch/arm/arm64/mmu/mm.c
>>>>> +++ b/xen/arch/arm/arm64/mmu/mm.c
>>>>> @@ -1,6 +1,7 @@
>>>>>   /* SPDX-License-Identifier: GPL-2.0-only */
>>>>>
>>>>>   #include <xen/init.h>
>>>>> +#include <xen/llc-coloring.h>
>>>>>   #include <xen/mm.h>
>>>>>   #include <xen/pfn.h>
>>>>>
>>>>> @@ -138,8 +139,36 @@ void update_boot_mapping(bool enable)
>>>>>   }
>>>>>
>>>>>   extern void switch_ttbr_id(uint64_t ttbr);
>>>>> +extern void relocate_xen(uint64_t ttbr, void *src, void *dst, size_t len);
>>>>>
>>>>>   typedef void (switch_ttbr_fn)(uint64_t ttbr);
>>>>> +typedef void (relocate_xen_fn)(uint64_t ttbr, void *src, void *dst, size_t len);
>>>>> +
>>>>> +void __init relocate_and_switch_ttbr(uint64_t ttbr) {
>>>> CODING_STYLE: { needs to be on its own line
>>>>
>>>> Also, this function is only executed in case of LLC coloring, so shouldn't it
>>>> be #ifdef protected.
>>>
>>> Here and in other places (patch #8) I'm relying on DCE to remove functions
>>> that are not called. This was a suggestion from Jan in that patch. Can we
>>> adopt the same here?
>>
>> Yet how would the compiler spot that the function is unused? That would only
>> work with LTO / WPO. DCE (as I did suggest elsewhere) requires the functions
>> in question to be static (allowing the compiler to see enough of the whole
>> picture).
> 
> Sorry for the late answer. I was away with limited e-mail access. While
> looking what was committing recently, I noticed that a dummy function
> was introduced:
> 
> void __init relocate_and_switch_ttbr(uint64_t ttbr) {}
> 
> If a function is not supposed to be called, then it should contain a
> BUG_ON() to catch any misusage. Otherwise, this is a recipe for
> disaster. In this case, it would not be trivial to notice the TTBR was
> not switched...
> 
> That said I would have actually considered to remove the empty stub. I
> am a bit surprised that DCE wouldn't work in this case because the call
> is protected with "if ( llc_coloring_enabled )". When cache coloring is
> not enabled, this would turn to an "if ( false )" and therefore all the
> code should be removed. What did I miss?
> 
> Note that this is what we already rely on for arm32 because there is no
> stub... So if this is problem then we definitely need to fix it on arm32
> as well...
> 
> IOW, we either introduce a stub (including the BUG_ON) for both arm32
> and arm64 in the header or we remove the stub completely.
> 
> Marco, Michal, can you have a look? Ideally, this should be fixed for 4.20.
I did a test with GCC 13.2 and I can compile it fine with stub removed. That said,
I'm not a compiler expert and I'm not sure if this behavior stays the same with different
compiler options/optimizations. So it's more like a question to Jan. I'm happy either way.

~Michal



From xen-devel-bounces@lists.xenproject.org Tue Jan 07 17:01:58 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 17:01:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866705.1278044 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVCxk-0000gY-CF; Tue, 07 Jan 2025 17:01:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866705.1278044; Tue, 07 Jan 2025 17:01:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVCxk-0000gR-8Y; Tue, 07 Jan 2025 17:01:52 +0000
Received: by outflank-mailman (input) for mailman id 866705;
 Tue, 07 Jan 2025 17:01:50 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=1r68=T7=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVCxi-0000gG-U8
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 17:01:50 +0000
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com
 [2a00:1450:4864:20::335])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 153f0ecb-cd19-11ef-99a4-01e77a169b0f;
 Tue, 07 Jan 2025 18:01:48 +0100 (CET)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-4361c705434so114366105e9.3
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 09:01:48 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c828cc8sm50784301f8f.17.2025.01.07.09.01.46
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 09:01:47 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 153f0ecb-cd19-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736269308; x=1736874108; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=9Raw7Do+gupPmbHumzSkDywp+redY4zIMpdNkF5IBKE=;
        b=LPQdMa/yzciacziwjZEAzdKQtdF7UawazJ8icQeFJsKo8H7nUCr8CaAwt5sqsWAKs6
         1UsWR2R/EvdUveLk7nMLfJgElolVMxmHi+zw4uvtCTiU5IIicguk4u6ZggDvtC4Saqb2
         ENjJwhAHv8bweaSq3yFT+bP81XoMzfEWjgV40YiS/elnvYfyUvq04zBudFOsxTvyXNUI
         F3Mpy/H+Yx4lebGHkNBLcaP3Fa9Mxv2XC4Vn60PHtdhiZIh1UfP6ZV3S/m0/akuHUy/W
         m0bYWlrO343hpSbPYEIfAkoA/YgKUOixPt50mCaCRlfBtBV96u6EFSO/mdUVwd0CtfK4
         hwIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736269308; x=1736874108;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=9Raw7Do+gupPmbHumzSkDywp+redY4zIMpdNkF5IBKE=;
        b=wKrvC+iTgwbwIWoWB9/3GjkR8WYgnNNawgbB2UU9lVQia88hm0Rxx0QhGogiqf94rw
         p4l28wuYLOG7qmC6RiYXj0PLKpaIFLBjgj4BNzxSaL6tjGvDkBDSPS2U4n/67JfNTYTC
         u0nbpB//JTq1si9s1IdLQVe9Li0DDptu5+8lkiyJndww33dSL4B8KDbkCyg+wgYSU1NB
         XLyAtiYIDIBd2LYPHvln+VaCEuqtd12GFHTMwlH249afGoLFYwNxNXfPgHwonO5xIIpo
         VELOK0E58+uwzWou6gARyQahiaba+w5b5y3A/RHE4NKsTK1nJdVClcnufe6FWBzxKOpY
         D2bA==
X-Gm-Message-State: AOJu0YzLxoO9MSuU52tFZCyY/APYsuJLhREJvtuwE+22Iw8B/vXOYung
	Uny5R5OjotknKOtDE+CRJQH/kONaCwXHonSObx5GQtoekp8ZsbhvABjSGVweAg==
X-Gm-Gg: ASbGncvrvEwqjOy/TAGhMpj2z4IY/K8lYFhokthf1YPstUze/z/bMtk46yUjPnFh9oC
	hilt3RxT9mah/RcaV2nPglvhvrUd3o+wYYbUSubPFH2uz0+qJb4gduvMYjwVNffHCTiQmwUVgeg
	p3dC6MGUBdjcTj0CQ7Ni0fuElSlQjrEW5Kf5iDJhkoMeBV3BxLZX5nmkaoXZQumrvsLM/xyxy3D
	4MOTbQGt1nNTp/6T8Elyv++QFkn+pWJbjbh3piJQYv3Bww1F9FFmOEkw9t1zZBz8OBJoOJgAJCu
	bGuq7dgAYWzpvnfOxLQKLR/spy0YAW2J8WmmNU1B7Q==
X-Google-Smtp-Source: AGHT+IHDvZudkWN3cUncN9bg4uCSEHekI96ClsEMZ8HJBeEaCNSWYlpzYEAGMdzLkaIjxhmkzFvV4Q==
X-Received: by 2002:a5d:584b:0:b0:386:373f:47c4 with SMTP id ffacd0b85a97d-38a224053d8mr54994968f8f.49.1736269307839;
        Tue, 07 Jan 2025 09:01:47 -0800 (PST)
Message-ID: <6a0a096b-47c2-4568-be9f-9f230bc6df23@suse.com>
Date: Tue, 7 Jan 2025 18:01:45 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [for-4.20] Re: [PATCH v12 12/12] xen/arm: add cache coloring
 support for Xen image
To: Michal Orzel <michal.orzel@amd.com>
Cc: xen-devel@lists.xenproject.org, andrea.bastoni@minervasys.tech,
 marco.solieri@minervasys.tech, Stefano Stabellini <sstabellini@kernel.org>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Oleksii <oleksii.kurochko@gmail.com>, Julien Grall <julien@xen.org>,
 Carlo Nonato <carlo.nonato@minervasys.tech>
References: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
 <20241213162815.9196-13-carlo.nonato@minervasys.tech>
 <dbbc649f-b705-46b5-a071-760d688aa2cd@amd.com>
 <CAG+AhRWrXAYfKXXKfp6949vNMdGDy9qWOY11SKAigJuC8oUvDw@mail.gmail.com>
 <df0f831f-378f-4fa3-ae4f-b065f2ea566d@suse.com>
 <0062e0cf-0830-4d16-942d-348e6d33a2c4@xen.org>
 <5c153764-4a1d-4233-a9d2-fa5ec0aff6ac@amd.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <5c153764-4a1d-4233-a9d2-fa5ec0aff6ac@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 07.01.2025 17:51, Michal Orzel wrote:
> 
> 
> On 07/01/2025 17:42, Julien Grall wrote:
>>
>>
>> Hi,
>>
>> On 16/12/2024 14:36, Jan Beulich wrote:
>>> On 16.12.2024 15:28, Carlo Nonato wrote:
>>>> On Mon, Dec 16, 2024 at 2:56 PM Michal Orzel <michal.orzel@amd.com> wrote:
>>>>> On 13/12/2024 17:28, Carlo Nonato wrote:
>>>>>> --- a/xen/arch/arm/arm64/mmu/mm.c
>>>>>> +++ b/xen/arch/arm/arm64/mmu/mm.c
>>>>>> @@ -1,6 +1,7 @@
>>>>>>   /* SPDX-License-Identifier: GPL-2.0-only */
>>>>>>
>>>>>>   #include <xen/init.h>
>>>>>> +#include <xen/llc-coloring.h>
>>>>>>   #include <xen/mm.h>
>>>>>>   #include <xen/pfn.h>
>>>>>>
>>>>>> @@ -138,8 +139,36 @@ void update_boot_mapping(bool enable)
>>>>>>   }
>>>>>>
>>>>>>   extern void switch_ttbr_id(uint64_t ttbr);
>>>>>> +extern void relocate_xen(uint64_t ttbr, void *src, void *dst, size_t len);
>>>>>>
>>>>>>   typedef void (switch_ttbr_fn)(uint64_t ttbr);
>>>>>> +typedef void (relocate_xen_fn)(uint64_t ttbr, void *src, void *dst, size_t len);
>>>>>> +
>>>>>> +void __init relocate_and_switch_ttbr(uint64_t ttbr) {
>>>>> CODING_STYLE: { needs to be on its own line
>>>>>
>>>>> Also, this function is only executed in case of LLC coloring, so shouldn't it
>>>>> be #ifdef protected.
>>>>
>>>> Here and in other places (patch #8) I'm relying on DCE to remove functions
>>>> that are not called. This was a suggestion from Jan in that patch. Can we
>>>> adopt the same here?
>>>
>>> Yet how would the compiler spot that the function is unused? That would only
>>> work with LTO / WPO. DCE (as I did suggest elsewhere) requires the functions
>>> in question to be static (allowing the compiler to see enough of the whole
>>> picture).
>>
>> Sorry for the late answer. I was away with limited e-mail access. While
>> looking what was committing recently, I noticed that a dummy function
>> was introduced:
>>
>> void __init relocate_and_switch_ttbr(uint64_t ttbr) {}
>>
>> If a function is not supposed to be called, then it should contain a
>> BUG_ON() to catch any misusage. Otherwise, this is a recipe for
>> disaster. In this case, it would not be trivial to notice the TTBR was
>> not switched...
>>
>> That said I would have actually considered to remove the empty stub. I
>> am a bit surprised that DCE wouldn't work in this case because the call
>> is protected with "if ( llc_coloring_enabled )". When cache coloring is
>> not enabled, this would turn to an "if ( false )" and therefore all the
>> code should be removed. What did I miss?
>>
>> Note that this is what we already rely on for arm32 because there is no
>> stub... So if this is problem then we definitely need to fix it on arm32
>> as well...
>>
>> IOW, we either introduce a stub (including the BUG_ON) for both arm32
>> and arm64 in the header or we remove the stub completely.
>>
>> Marco, Michal, can you have a look? Ideally, this should be fixed for 4.20.
> I did a test with GCC 13.2 and I can compile it fine with stub removed. That said,
> I'm not a compiler expert and I'm not sure if this behavior stays the same with different
> compiler options/optimizations. So it's more like a question to Jan. I'm happy either way.

We use the same (if(...) func();) in various places, relying on said DCEing
of the call when the condition is compile-time-false. I see no reason why
it couldn't be used here as well.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 17:06:20 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 17:06:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866712.1278054 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVD23-0001SY-T8; Tue, 07 Jan 2025 17:06:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866712.1278054; Tue, 07 Jan 2025 17:06:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVD23-0001SR-Pq; Tue, 07 Jan 2025 17:06:19 +0000
Received: by outflank-mailman (input) for mailman id 866712;
 Tue, 07 Jan 2025 17:06:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=1r68=T7=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVD23-0001S5-Cs
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 17:06:19 +0000
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com
 [2a00:1450:4864:20::333])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b57a56f6-cd19-11ef-99a4-01e77a169b0f;
 Tue, 07 Jan 2025 18:06:17 +0100 (CET)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-436a03197b2so60757075e9.2
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 09:06:17 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-43661289d3dsm609984495e9.41.2025.01.07.09.06.15
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 09:06:16 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b57a56f6-cd19-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736269577; x=1736874377; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ghp1tnPKNVu7zUuOehlMLLhbDPQRrAhgyG7OKOH4ba8=;
        b=OlLMq0gMtMwyBLIFOl5RxEI838BPWW3grSdYnDiV+DPrNwyp1D+6oR7xAlRKIy66Qs
         QPu2cm1cpN93p7oKsE0CPJT5iGP8kWz3HLF6GIRyFn4/BDQBNECPTFIzMp6PYyOnVqqq
         aCQGRdw1YTSRoDV92kS46ZG/QI101wT7nFi6cKCXtyhTaj2MU/AcQXGndwu4Ole3Cw67
         dy50QUrFp5gt9Aw/R23DyDvMhjCZOaij1CY9b2g5/HbDpNDKG5tbnL+RSbmrrR1YFM/8
         c3hvQMrgmYKsH+jGUfhugLWus1kuOGsYC13PmlMgphTjj9SSXUmWoH6L7YoYqsU6zBS9
         m2Dw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736269577; x=1736874377;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ghp1tnPKNVu7zUuOehlMLLhbDPQRrAhgyG7OKOH4ba8=;
        b=q61F0XhV6CtDz7mkwVX2np0Yb2EyiljHRsEDdQCSGKlVLToK8wQxwhu05jPIFjvwwU
         bUZD0vFy13N3VXr3I/qyRKq7ROOTeXdUXCe5eaDjGN1CWAXqd7PzkpyR98E5cOb7HISX
         yBbbpEVocaUcRf6v1qIfTMMMCV9vN00FbTSUeWA24OmikPJ4zV94TVDOgErb2h31jGMn
         aKNL2yE4MEy0LdEexV7dAeYR3Gd94PfIqSqZCF+BqpGjcdJlu54C4/b4KqJ3nW7Etjeq
         s7ESigmt4MVY4j5+OZmQ++HMlfxyPKmyoVnD+IKtocLgRcELkKyfSiS6nRYW9ksMFCkq
         REzA==
X-Forwarded-Encrypted: i=1; AJvYcCXTGSIYtOog8eIzSQ42moaI/RSqFOz8RhSVoOZMYh0ApbyC4zWo9IwZ1ys6HIDc1G3pi4Ifh08l2cY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwgT7kbE9BUuqhMIclVRx/olEX8U8DYIL0hfNW2DiGFJ0iEv2Jk
	ImbiqEqENADgay7DyggcKGRr1sxLJBEDxhS63MMZ+OHZRwWBq2dL59Vv7hmvRg==
X-Gm-Gg: ASbGncuD5rqhoiH3DkC23HZXLSNu7DV9XuqpfjJ+RCtaBa+aLI2/rqyzfwiPAPC9JKg
	d5CTKQ4YhRlkADvX9CGafOWBLZ5v069dP5aLYR+hw26w/vKrYp4/Ge++uWQ4P51chvEke198cTF
	o1V3imB48pqVj1sloBTKSIbnTzaMmOt73qlRt8suyvRLP/ubpR309e5BtgeinR2uFNv/8BRzW91
	jbeQgqdmUIvsNoBcRAAkI0bObkDPEE/S4i7YEa8b7NAEUdyg2uG+wmOrNES9E3zgMpoFYSXPSz/
	zz58Uk9F9ScNp0/+soDgEssH/Z1PCd6teAzbjJqs9A==
X-Google-Smtp-Source: AGHT+IHssG3ly+sL0zY5U0k3layizvl3ZrapHncu3hA/2DfK2lnYVTIb7YRLvcrax12rPnLrq4XHyw==
X-Received: by 2002:a05:600c:470a:b0:434:e9ee:c1e with SMTP id 5b1f17b1804b1-43668b7a33dmr580595705e9.31.1736269576923;
        Tue, 07 Jan 2025 09:06:16 -0800 (PST)
Message-ID: <099376ce-0cd7-423a-b3fe-d9e0a8505c85@suse.com>
Date: Tue, 7 Jan 2025 18:06:15 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 5/7] xen: add new domctl get_changed_domain
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Cc: "Daniel P. Smith" <dpsmith@apertussolutions.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <20250107101711.5980-1-jgross@suse.com>
 <20250107101711.5980-6-jgross@suse.com>
 <781daba7-5d6f-4d86-bce4-c5aa9d135513@suse.com>
 <81221a18-d6f8-418d-841a-8aa43420df09@suse.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <81221a18-d6f8-418d-841a-8aa43420df09@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 07.01.2025 17:48, Jürgen Groß wrote:
> On 07.01.25 17:28, Jan Beulich wrote:
>> On 07.01.2025 11:17, Juergen Gross wrote:
>>> --- a/xen/common/domain.c
>>> +++ b/xen/common/domain.c
>>> @@ -185,6 +185,76 @@ static void domain_changed_state(const struct domain *d)
>>>       unlock_dom_exc_handler(hdl);
>>>   }
>>>   
>>> +static void set_domain_state_info(struct xen_domctl_get_domain_state *info,
>>> +                                  const struct domain *d)
>>> +{
>>> +    info->state = XEN_DOMCTL_GETDOMSTATE_STATE_EXIST;
>>> +    if ( d->is_shut_down )
>>> +        info->state |= XEN_DOMCTL_GETDOMSTATE_STATE_SHUTDOWN;
>>> +    if ( d->is_dying == DOMDYING_dying )
>>> +        info->state |= XEN_DOMCTL_GETDOMSTATE_STATE_DYING;
>>> +    if ( d->is_dying == DOMDYING_dead )
>>> +        info->state |= XEN_DOMCTL_GETDOMSTATE_STATE_DEAD;
>>> +    info->unique_id = d->unique_id;
>>> +}
>>> +
>>> +int get_domain_state(struct xen_domctl_get_domain_state *info, struct domain *d,
>>> +                     domid_t *domid)
>>> +{
>>> +    unsigned int dom;
>>> +    int rc = -ENOENT;
>>> +    struct domain *hdl;
>>> +
>>> +    if ( info->pad0 || info->pad1 )
>>> +        return -EINVAL;
>>> +
>>> +    if ( d )
>>> +    {
>>> +        set_domain_state_info(info, d);
>>> +
>>> +        return 0;
>>> +    }
>>> +
>>> +    /*
>>> +     * Only domain registered for VIRQ_DOM_EXC event is allowed to query
>>> +     * domains having changed state.
>>> +     */
>>> +    if ( !domain_handles_global_virq(current->domain, VIRQ_DOM_EXC) )
>>> +        return -EACCES;
>>> +
>>> +    hdl = lock_dom_exc_handler();
>>
>> Instead of leaving a small window for races between the if() and this
>> function call, can't you simply compare hdl against current->domain?
> 
> Good idea.
> 
>>
>>> +    while ( dom_state_changed )
>>> +    {
>>> +        dom = find_first_bit(dom_state_changed, DOMID_MASK + 1);
>>> +        if ( dom >= DOMID_FIRST_RESERVED )
>>> +            break;
>>> +        if ( test_and_clear_bit(dom, dom_state_changed) )
>>
>> As this is now running under lock, does it really need to be test-and-clear?
>> What mechanism would allow the flag to be cleared between the find-1st and
>> here? Plus, like for patch 4, I think it could be __clear_bit() here.
> 
> It is only under read_lock(), so there are concurrent calls possible.
> I don't think we want to use write_lock() here, do we?

Probably not; I have to admit I didn't even pay attention to this aspect.
Then the set_bit() in domain_changed_state() also need to remain as is (in
patch 4 I think it was).

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 17:12:48 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 17:12:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866719.1278065 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVD8E-0003Ym-IZ; Tue, 07 Jan 2025 17:12:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866719.1278065; Tue, 07 Jan 2025 17:12:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVD8E-0003Yf-EE; Tue, 07 Jan 2025 17:12:42 +0000
Received: by outflank-mailman (input) for mailman id 866719;
 Tue, 07 Jan 2025 17:12:41 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Qdqe=T7=suse.com=jgross@srs-se1.protection.inumbo.net>)
 id 1tVD8D-0003XJ-Bg
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 17:12:41 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 98f2507c-cd1a-11ef-99a4-01e77a169b0f;
 Tue, 07 Jan 2025 18:12:39 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id 694CA21133;
 Tue,  7 Jan 2025 17:12:38 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id EB09B13763;
 Tue,  7 Jan 2025 17:12:37 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id v/YnN4VgfWeXawAAD6G6ig
 (envelope-from <jgross@suse.com>); Tue, 07 Jan 2025 17:12:37 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 98f2507c-cd1a-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1736269958; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=2hPVAC7vYnQwzpm7rrw2cgP4FPWGLvFSvfZro8cmU2E=;
	b=sGR4u6vtc/lzvhBnlntteK1Hz6nJIxVvgzVikPX6emsK1hkei/LZvnHeDYY8WvZIEun0Cx
	tYby2Z5kczpSoQSjDGYPdE7RUIymPaP6mhYYEhFRXgfqWL09vkgB2s4qHV4SODlETX2A+o
	pXl1coPEq6QdS3nn5vrh5ytXM5uz0nk=
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=sGR4u6vt
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1736269958; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=2hPVAC7vYnQwzpm7rrw2cgP4FPWGLvFSvfZro8cmU2E=;
	b=sGR4u6vtc/lzvhBnlntteK1Hz6nJIxVvgzVikPX6emsK1hkei/LZvnHeDYY8WvZIEun0Cx
	tYby2Z5kczpSoQSjDGYPdE7RUIymPaP6mhYYEhFRXgfqWL09vkgB2s4qHV4SODlETX2A+o
	pXl1coPEq6QdS3nn5vrh5ytXM5uz0nk=
Message-ID: <79aff4ad-49d0-4d77-96d3-8b82fae6166e@suse.com>
Date: Tue, 7 Jan 2025 18:12:37 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 5/7] xen: add new domctl get_changed_domain
To: Jan Beulich <jbeulich@suse.com>
Cc: "Daniel P. Smith" <dpsmith@apertussolutions.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <20250107101711.5980-1-jgross@suse.com>
 <20250107101711.5980-6-jgross@suse.com>
 <781daba7-5d6f-4d86-bce4-c5aa9d135513@suse.com>
 <81221a18-d6f8-418d-841a-8aa43420df09@suse.com>
 <099376ce-0cd7-423a-b3fe-d9e0a8505c85@suse.com>
Content-Language: en-US
From: Juergen Gross <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <099376ce-0cd7-423a-b3fe-d9e0a8505c85@suse.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------y23Qfxej6hvkHLUroM0jJUHf"
X-Rspamd-Queue-Id: 694CA21133
X-Spam-Level: 
X-Spamd-Result: default: False [-6.41 / 50.00];
	BAYES_HAM(-3.00)[99.99%];
	SIGNED_PGP(-2.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_BASE64_TEXT(0.10)[];
	MIME_UNKNOWN(0.10)[application/pgp-keys];
	MX_GOOD(-0.01)[];
	DKIM_TRACE(0.00)[suse.com:+];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~];
	ARC_NA(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_SEVEN(0.00)[9];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:dkim,suse.com:mid,imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns];
	TO_DN_SOME(0.00)[];
	HAS_ATTACHMENT(0.00)[]
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Rspamd-Action: no action
X-Spam-Score: -6.41
X-Spam-Flag: NO

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------y23Qfxej6hvkHLUroM0jJUHf
Content-Type: multipart/mixed; boundary="------------MksvpfXbwYdx3YjypSy2Sa0Q";
 protected-headers="v1"
From: Juergen Gross <jgross@suse.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "Daniel P. Smith" <dpsmith@apertussolutions.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
Message-ID: <79aff4ad-49d0-4d77-96d3-8b82fae6166e@suse.com>
Subject: Re: [PATCH v6 5/7] xen: add new domctl get_changed_domain
References: <20250107101711.5980-1-jgross@suse.com>
 <20250107101711.5980-6-jgross@suse.com>
 <781daba7-5d6f-4d86-bce4-c5aa9d135513@suse.com>
 <81221a18-d6f8-418d-841a-8aa43420df09@suse.com>
 <099376ce-0cd7-423a-b3fe-d9e0a8505c85@suse.com>
In-Reply-To: <099376ce-0cd7-423a-b3fe-d9e0a8505c85@suse.com>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------MksvpfXbwYdx3YjypSy2Sa0Q
Content-Type: multipart/mixed; boundary="------------zO2iINRJdxqdl5as8tpau5hP"

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

T24gMDcuMDEuMjUgMTg6MDYsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAwNy4wMS4yMDI1
IDE3OjQ4LCBKw7xyZ2VuIEdyb8OfIHdyb3RlOg0KPj4gT24gMDcuMDEuMjUgMTc6MjgsIEph
biBCZXVsaWNoIHdyb3RlOg0KPj4+IE9uIDA3LjAxLjIwMjUgMTE6MTcsIEp1ZXJnZW4gR3Jv
c3Mgd3JvdGU6DQo+Pj4+IC0tLSBhL3hlbi9jb21tb24vZG9tYWluLmMNCj4+Pj4gKysrIGIv
eGVuL2NvbW1vbi9kb21haW4uYw0KPj4+PiBAQCAtMTg1LDYgKzE4NSw3NiBAQCBzdGF0aWMg
dm9pZCBkb21haW5fY2hhbmdlZF9zdGF0ZShjb25zdCBzdHJ1Y3QgZG9tYWluICpkKQ0KPj4+
PiAgICAgICAgdW5sb2NrX2RvbV9leGNfaGFuZGxlcihoZGwpOw0KPj4+PiAgICB9DQo+Pj4+
ICAgIA0KPj4+PiArc3RhdGljIHZvaWQgc2V0X2RvbWFpbl9zdGF0ZV9pbmZvKHN0cnVjdCB4
ZW5fZG9tY3RsX2dldF9kb21haW5fc3RhdGUgKmluZm8sDQo+Pj4+ICsgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgY29uc3Qgc3RydWN0IGRvbWFpbiAqZCkNCj4+Pj4gK3sN
Cj4+Pj4gKyAgICBpbmZvLT5zdGF0ZSA9IFhFTl9ET01DVExfR0VURE9NU1RBVEVfU1RBVEVf
RVhJU1Q7DQo+Pj4+ICsgICAgaWYgKCBkLT5pc19zaHV0X2Rvd24gKQ0KPj4+PiArICAgICAg
ICBpbmZvLT5zdGF0ZSB8PSBYRU5fRE9NQ1RMX0dFVERPTVNUQVRFX1NUQVRFX1NIVVRET1dO
Ow0KPj4+PiArICAgIGlmICggZC0+aXNfZHlpbmcgPT0gRE9NRFlJTkdfZHlpbmcgKQ0KPj4+
PiArICAgICAgICBpbmZvLT5zdGF0ZSB8PSBYRU5fRE9NQ1RMX0dFVERPTVNUQVRFX1NUQVRF
X0RZSU5HOw0KPj4+PiArICAgIGlmICggZC0+aXNfZHlpbmcgPT0gRE9NRFlJTkdfZGVhZCAp
DQo+Pj4+ICsgICAgICAgIGluZm8tPnN0YXRlIHw9IFhFTl9ET01DVExfR0VURE9NU1RBVEVf
U1RBVEVfREVBRDsNCj4+Pj4gKyAgICBpbmZvLT51bmlxdWVfaWQgPSBkLT51bmlxdWVfaWQ7
DQo+Pj4+ICt9DQo+Pj4+ICsNCj4+Pj4gK2ludCBnZXRfZG9tYWluX3N0YXRlKHN0cnVjdCB4
ZW5fZG9tY3RsX2dldF9kb21haW5fc3RhdGUgKmluZm8sIHN0cnVjdCBkb21haW4gKmQsDQo+
Pj4+ICsgICAgICAgICAgICAgICAgICAgICBkb21pZF90ICpkb21pZCkNCj4+Pj4gK3sNCj4+
Pj4gKyAgICB1bnNpZ25lZCBpbnQgZG9tOw0KPj4+PiArICAgIGludCByYyA9IC1FTk9FTlQ7
DQo+Pj4+ICsgICAgc3RydWN0IGRvbWFpbiAqaGRsOw0KPj4+PiArDQo+Pj4+ICsgICAgaWYg
KCBpbmZvLT5wYWQwIHx8IGluZm8tPnBhZDEgKQ0KPj4+PiArICAgICAgICByZXR1cm4gLUVJ
TlZBTDsNCj4+Pj4gKw0KPj4+PiArICAgIGlmICggZCApDQo+Pj4+ICsgICAgew0KPj4+PiAr
ICAgICAgICBzZXRfZG9tYWluX3N0YXRlX2luZm8oaW5mbywgZCk7DQo+Pj4+ICsNCj4+Pj4g
KyAgICAgICAgcmV0dXJuIDA7DQo+Pj4+ICsgICAgfQ0KPj4+PiArDQo+Pj4+ICsgICAgLyoN
Cj4+Pj4gKyAgICAgKiBPbmx5IGRvbWFpbiByZWdpc3RlcmVkIGZvciBWSVJRX0RPTV9FWEMg
ZXZlbnQgaXMgYWxsb3dlZCB0byBxdWVyeQ0KPj4+PiArICAgICAqIGRvbWFpbnMgaGF2aW5n
IGNoYW5nZWQgc3RhdGUuDQo+Pj4+ICsgICAgICovDQo+Pj4+ICsgICAgaWYgKCAhZG9tYWlu
X2hhbmRsZXNfZ2xvYmFsX3ZpcnEoY3VycmVudC0+ZG9tYWluLCBWSVJRX0RPTV9FWEMpICkN
Cj4+Pj4gKyAgICAgICAgcmV0dXJuIC1FQUNDRVM7DQo+Pj4+ICsNCj4+Pj4gKyAgICBoZGwg
PSBsb2NrX2RvbV9leGNfaGFuZGxlcigpOw0KPj4+DQo+Pj4gSW5zdGVhZCBvZiBsZWF2aW5n
IGEgc21hbGwgd2luZG93IGZvciByYWNlcyBiZXR3ZWVuIHRoZSBpZigpIGFuZCB0aGlzDQo+
Pj4gZnVuY3Rpb24gY2FsbCwgY2FuJ3QgeW91IHNpbXBseSBjb21wYXJlIGhkbCBhZ2FpbnN0
IGN1cnJlbnQtPmRvbWFpbj8NCj4+DQo+PiBHb29kIGlkZWEuDQo+Pg0KPj4+DQo+Pj4+ICsg
ICAgd2hpbGUgKCBkb21fc3RhdGVfY2hhbmdlZCApDQo+Pj4+ICsgICAgew0KPj4+PiArICAg
ICAgICBkb20gPSBmaW5kX2ZpcnN0X2JpdChkb21fc3RhdGVfY2hhbmdlZCwgRE9NSURfTUFT
SyArIDEpOw0KPj4+PiArICAgICAgICBpZiAoIGRvbSA+PSBET01JRF9GSVJTVF9SRVNFUlZF
RCApDQo+Pj4+ICsgICAgICAgICAgICBicmVhazsNCj4+Pj4gKyAgICAgICAgaWYgKCB0ZXN0
X2FuZF9jbGVhcl9iaXQoZG9tLCBkb21fc3RhdGVfY2hhbmdlZCkgKQ0KPj4+DQo+Pj4gQXMg
dGhpcyBpcyBub3cgcnVubmluZyB1bmRlciBsb2NrLCBkb2VzIGl0IHJlYWxseSBuZWVkIHRv
IGJlIHRlc3QtYW5kLWNsZWFyPw0KPj4+IFdoYXQgbWVjaGFuaXNtIHdvdWxkIGFsbG93IHRo
ZSBmbGFnIHRvIGJlIGNsZWFyZWQgYmV0d2VlbiB0aGUgZmluZC0xc3QgYW5kDQo+Pj4gaGVy
ZT8gUGx1cywgbGlrZSBmb3IgcGF0Y2ggNCwgSSB0aGluayBpdCBjb3VsZCBiZSBfX2NsZWFy
X2JpdCgpIGhlcmUuDQo+Pg0KPj4gSXQgaXMgb25seSB1bmRlciByZWFkX2xvY2soKSwgc28g
dGhlcmUgYXJlIGNvbmN1cnJlbnQgY2FsbHMgcG9zc2libGUuDQo+PiBJIGRvbid0IHRoaW5r
IHdlIHdhbnQgdG8gdXNlIHdyaXRlX2xvY2soKSBoZXJlLCBkbyB3ZT8NCj4gDQo+IFByb2Jh
Ymx5IG5vdDsgSSBoYXZlIHRvIGFkbWl0IEkgZGlkbid0IGV2ZW4gcGF5IGF0dGVudGlvbiB0
byB0aGlzIGFzcGVjdC4NCj4gVGhlbiB0aGUgc2V0X2JpdCgpIGluIGRvbWFpbl9jaGFuZ2Vk
X3N0YXRlKCkgYWxzbyBuZWVkIHRvIHJlbWFpbiBhcyBpcyAoaW4NCj4gcGF0Y2ggNCBJIHRo
aW5rIGl0IHdhcykuDQoNClRoaXMgb25lIG5lZWRzIHRvIHN0YXksIGJ1dCB0aGUgb25lIGlu
IGRvbWFpbl9pbml0X3N0YXRlcygpIGNhbiBiZSBjaGFuZ2VkDQp0byB0aGUgbm9uLWF0b21p
YyB2YXJpYW50IGFnYWluLg0KDQoNCkp1ZXJnZW4NCg==
--------------zO2iINRJdxqdl5as8tpau5hP
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

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

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

--------------zO2iINRJdxqdl5as8tpau5hP--

--------------MksvpfXbwYdx3YjypSy2Sa0Q--

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

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

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmd9YIUFAwAAAAAACgkQsN6d1ii/Ey/D
vwf/Sh0LKJx+APLg/PwqVQozWjwZrVG1jn1Y0wsI2PfFQoSEX7TsWExgDkYA/hAfC9/S/YRlQrGX
/3OSLjr5xh6LsrI1BAimcodoQeJSIfvAtFmBl9FvInm+kAVlG0cvYDG/Ge4oQb35oT0EYIhIL7Rh
wBKSw6jsGfdrnlK57aVxOVQw644dWQQuCEsbeZeOrXd6e77D81w8IuipPMb8TNTcgEPChCsQKlVC
rw1INqbN/0TLyUFlws15QbU+aTOXWxbg3PCCrMVsrUFpU/sHxuRDJKhqFCM/oj9SZc/SwD7F+f0r
EVzsBviF78MwNaxO/mt7313uBt4I4PRzTtkuqp0ueA==
=5SEU
-----END PGP SIGNATURE-----

--------------y23Qfxej6hvkHLUroM0jJUHf--


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 17:13:58 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 17:13:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866729.1278074 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVD9R-0004AX-06; Tue, 07 Jan 2025 17:13:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866729.1278074; Tue, 07 Jan 2025 17:13:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVD9Q-0004AQ-SN; Tue, 07 Jan 2025 17:13:56 +0000
Received: by outflank-mailman (input) for mailman id 866729;
 Tue, 07 Jan 2025 17:13:55 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=W3tJ=T7=minervasys.tech=andrea.bastoni@srs-se1.protection.inumbo.net>)
 id 1tVD9P-0004AH-3r
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 17:13:55 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c549985d-cd1a-11ef-a0df-8be0dac302b0;
 Tue, 07 Jan 2025 18:13:53 +0100 (CET)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-aaeec07b705so1826369766b.2
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 09:13:53 -0800 (PST)
Received: from ?IPV6:2001:4ca0:0:f293:dc1b:7733:c3ba:a819?
 ([2001:4ca0:0:f293:dc1b:7733:c3ba:a819])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0eadcd88sm2372352666b.81.2025.01.07.09.13.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 09:13:52 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c549985d-cd1a-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1736270033; x=1736874833; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=brrLSNga5IeGNC2YbO8v3+YtAewaWjKVHILueFYzo9I=;
        b=zGcoV5Cbv53SojvMQIT3LzJvhSb+JCOJbFDOHFJjC5v4aQ9jY3pi79YkXfywvvjwkq
         yfEpnGSfC0hYUN6e3evKk+mQZ6Xfdn1gG7v+ytDjLXEyu8o0KbC6M767vLf9BAmrPShe
         dt5jsRJqeFo1UMR8gLnNEosxwARtTv83/eIxLn68VAPTu2Zt/+oREU2yQixHn2Sh8aj0
         BwbK3D3ZFS4RzDP/vfhb52podK6XP89iGl9yZ+A8gv/upsfc98wffAQH3O3gHZg2eqDC
         4s+fUo3WlZD5IAm0X8eqM2VKZ1fcpg9QQhTxjZ8s/uIPNGJ+fujdU4wDPin3MbXlBiEN
         iI8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736270033; x=1736874833;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=brrLSNga5IeGNC2YbO8v3+YtAewaWjKVHILueFYzo9I=;
        b=YnayL9J9xFwLux3O4z8oorxhM81zsYuQutOnUU5jH6PkrZu9hRPy9sjpC/jS53YXje
         kM1i8g1dFHjhWIL/1b8UN4yWTEHLbXTqTU6DOzrU4pTNuGFF17bqziOKjhqGlwspbLj3
         Hd4yOvGhCUgvO8cyY7XxvalehIhi0BBLG4f947XlYRW5SzLNc7KKR2In1KPeOd7MwVV5
         zUo5Xu0l7S4ZUSELP3oXVC1GKaKoedf47z8BzMZoSb4QVabjxblH1c9oEeC5/e9LfCtF
         t+UbAD4fTXRBNKo3GK3uHH3H8913UnSfXMdRk88Ra4COJ3glfaFogqeofBEgEsE808QM
         W9uA==
X-Gm-Message-State: AOJu0YxwPSONyC1OtinkdQgJX7c+sC121sujMSFZyyqBabGEAuIolqdG
	cTrtS/ciISkSEItoXUkEXNTRn+9gPN0QvqE+8WWxd8pwql2X0LLP1gKlgjUwcM4=
X-Gm-Gg: ASbGncuU4a7JHi84Vb12N+4guhzy7C4XABQM2XBLcI3N7+wbUi2u8HJ49SGfpt26BDw
	FDSfiEJEoBJBcc5spcLbELPc8JD8w2RhPHGJIaoUM2zV/pqsiZgljHMiSZpbX/pgxCh4EhrNt9k
	KxW1o57CnGws5kWVkIfpiEv2kbqc35D5s93ZxDLsVDuHQ1wcx/N2itp5Y/QjhYh89hjwXT3KVkJ
	kmBNE9xk73LnwL4B6kgAPRv/SVSR8E0olELG0Iy5WPp6fUW2cKebVd/EUBhOpEpaEJ/dEJAt3KS
	p6tAVmLDALaZQtoIpmYa7j7xsy/hx4P75dSkRA==
X-Google-Smtp-Source: AGHT+IHj1jmqM/uUdhwf6Ix94qLW/7prs4s9PhpMVP8x2NwW3FBCWv/ZbMzz+bta6VVDkj2z3wWPmg==
X-Received: by 2002:a17:907:c23:b0:aa6:b5e0:8c59 with SMTP id a640c23a62f3a-aac2d2311e8mr5317051366b.35.1736270032844;
        Tue, 07 Jan 2025 09:13:52 -0800 (PST)
Message-ID: <0231325c-13f2-4b0b-a928-4ba249e4c560@minervasys.tech>
Date: Tue, 7 Jan 2025 18:13:50 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [for-4.20] Re: [PATCH v12 12/12] xen/arm: add cache coloring
 support for Xen image
Content-Language: en-US
To: Jan Beulich <jbeulich@suse.com>, Michal Orzel <michal.orzel@amd.com>
Cc: xen-devel@lists.xenproject.org, marco.solieri@minervasys.tech,
 Stefano Stabellini <sstabellini@kernel.org>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Oleksii <oleksii.kurochko@gmail.com>, Julien Grall <julien@xen.org>,
 Carlo Nonato <carlo.nonato@minervasys.tech>
References: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
 <20241213162815.9196-13-carlo.nonato@minervasys.tech>
 <dbbc649f-b705-46b5-a071-760d688aa2cd@amd.com>
 <CAG+AhRWrXAYfKXXKfp6949vNMdGDy9qWOY11SKAigJuC8oUvDw@mail.gmail.com>
 <df0f831f-378f-4fa3-ae4f-b065f2ea566d@suse.com>
 <0062e0cf-0830-4d16-942d-348e6d33a2c4@xen.org>
 <5c153764-4a1d-4233-a9d2-fa5ec0aff6ac@amd.com>
 <6a0a096b-47c2-4568-be9f-9f230bc6df23@suse.com>
From: Andrea Bastoni <andrea.bastoni@minervasys.tech>
Autocrypt: addr=andrea.bastoni@minervasys.tech; keydata=
 xsFNBF5Nh4sBEAC7UM3QJtjrFO3pjcMCCh04JFyCCDzLFMIqMTB1UWCLamZ9dUwIau7ScgWv
 49aqbM++edVvEBmG8JHDC83DFWymvFVXBgqgcR7tHHBbg33XJKFMHvuW/kFm/67XPTFcec4L
 JsH5MWms9TLJbgCnaWQQMH3kztTRQaf5QcULIoHnTySKlt3WzzzHosaMO+/GNYX7vzfc4ypJ
 mD5SQWYDhfRefASkyxdrN6/QkPwS2vGTyVK58o2U9I27KPYvs+77JrjrNBfpnebapaYVA55C
 7BvTnno5Kr6QHwA6LcnIZqefz7KxQ1n+1C5QQbmhi9S68aloGCeUo9R06UMJG79TXC2Mc68t
 AtSCN/HpgcvN1CSL45f/4WCDPG572ebo5M6MPcTb4ptV1SC/i+4U/3cG0LNSUap+sGRCf0Iy
 C5xy0KOtgoq8jesdleSy8j/3DNIMGekSYbQYMO39DfZds2XFh9lVDjG7tQcChwW+lQDPo113
 ENBRftDyqJthrvmJXGyrOmn0su56qh2Zqvi5pSHWsH88vAZUJsOU+9lpohmcb3o/cQ18UXNK
 H/9wjo2zKHFdSylQFERHIzj6WlBp01wkTcCqtUGpxsjJHmVSyakWs3TrGXooKR9SPMxqVrD/
 oCCEo9IUD9jd+TxLsp/4TzUp4ScTO/43uPgdkMekU5mRs6B6WwARAQABzS9BbmRyZWEgQmFz
 dG9uaSA8YW5kcmVhLmJhc3RvbmlAbWluZXJ2YXN5cy50ZWNoPsLBlAQTAQgAPgIbAwULCQgH
 AgYVCgkICwIEFgIDAQIeAQIXgBYhBImpnm1L3x9XIoXhD3VSShFTR9xSBQJitcUIBQkKC9f2
 AAoJEHVSShFTR9xSmSoP/0W/VboJmWmLh89eIl1QRoiL1nGcti1fTN835Q2TPiSdg+nFVqy1
 8oLrJaHNe5THVaSr4S2du56SASYSG6f+Y5aiQccbalUJIV7KwXr741kovTnUPUKjPoi61Bx4
 DUzis0Xo0NmMnz7M1YudbQZmjoakE/wZJRB+b79+kJwrfZFcNg4DSuSvNOUeI17uapLKRQ1a
 ukuRgXwUpMOudKngJ8HB+16aHIQX+yfpcsanNr1nGwHSLhEPEM20DVzKiCp2cKjv9Y7zZ+6y
 akbJHdbRuJliyZmXaSVO8sQ1tO/W6Y/4zAjejw2c1qDKISeIlGi+o6UEVYZlKCThzrV9vYok
 AcJF4DlYcAuBMVYCTomovXb/9/Y48pRGlfDGrmnt+FvGVA0jYrG02oufItY2JAGzFcX1KMTG
 AGf1S7pOj3AvBTGJjW8d8+sXuedH51HNixJtMnzcmi+qJfPJujBW3BEZ1p0ZoDyTH/WCZF+7
 B5lFvTi0DRKY6AI0TSzBdjtaOMt64fn6KXtLtaTZKDKkFUBwAShJyYcWQSp/7EO+ZJW7dWIw
 1vM5AcnugonJby+q+JGgBVC2rjscu5Okl3lnviF9WLAzmRH/pDkAa3jifiUm8eS+dP+4cN6g
 WXL9vTF6FtFyI8sgzRlY/IX8mao5bV/P1HCwNvkBhO8C3XMaul4FwQsjzsFNBF5Nh4sBEADN
 J99l+vOp8LB8jDjWOhINlpgp+EcrmWOuler5QnoJUywc2zkLelQIwVGP2lFliMdLHM6DbMEX
 ySIzHbhw7oPRP0QRPK/6I4bXYkSQCrLyqYd0CYSbkar8YV6Xa6nGxRmP1bBv1lPFHN66D0yE
 /z1ScGMXyX+ZOIvH0ekIkqFvi7Ec/7a/ntfU43o2t05dmbnEKoECZgeS8SraojfKnQRpz7+P
 N0q45O5fMETZpIiQh1/mB12HOcklDNELcKohqVfevbknJw04Yjbcv79aGpBRqoVWWBS4TxcD
 CRPQZ+H0tMUVEL/MqO7tNLA1VuGpOccyFtZnC/+J/twa7iKpPIxS9Ec/LDYTddebWH+8gOmr
 /PkBerBXghlZpxmQUlJeQ8kyecOOc4C7ec3aUGj+x28j0+zlXFLUbjiKIEM5VowIMgDDRwA/
 MDr9IJhFzHaY2VCfBnX8sgJSn62IxqREq4X3KkR/Jtxt+HYXQYLl0yva2MBplkRcwQO799o6
 woAMW0uyct4+BUcKo1sBFP2x2n4NFiPEjeoH3y9baruD9iiMQsmbJ3IKqtT13crCa+bcY3ZS
 Oz+CymgzNdH+RabJMC3mGfKIhUQGwEHz+wyMnv16nqO49bmoCk3q5Oneo4I3XwI3QbIJr0rd
 QkX6oh6R0taC3naal1ZYGxs0vZK567bT5wARAQABwsF2BBgBCAAgFiEEiamebUvfH1ciheEP
 dVJKEVNH3FIFAl5Nh4sCGwwACgkQdVJKEVNH3FLafxAAl7pW0v6Jju19I6wtB+XNzzi5Wota
 3AyWzCxO/hUHNGRV/ZufhMkNFCMNzAxbdmO56eCk9ZYf/JMLu8H1GwhV1NgQ7HL4FNXXxLZ0
 ixZDik86iiSjVLtEjLuwkS4Fj9wjqevycL/t16kJduFNyxT0/XiB5UPh5NClOMonHSC+V2If
 Kf6l2Ic34CrA3ovkfVvBXJTzia0VgyQCikeazgPRELH8bq2WTBWfjR3/l86Y0twiYyXqBNQ8
 Q2Z83mu+yt38gTanz4YuDYz7YFjvL6IU2MZ5+ByothK6Cfx4W595q81dsGcJOlcd6j3QE+ps
 b3SHuToWZCHZRHyKrgGDqCL5RbsK3wXgDmc48SfN+5TxenT8A1lkoOHFcQ0SV8xleiwURXHc
 Ao+SzyDcTfltBNjzQmntQjAfq1Lq5Ux9nfpPMgnVHu5ANWeLtwLJyh+4aPVE5hGjeCa+Ab5U
 MyocCYdTuAmDHB9RQdf9c+qlVYuZCg7yYlWsvId5DGZnab2MzvExayaFCJVEoCccpfrqFFiF
 kJ19BogE4A6VTU0ShoHYJhLg7PuEZS1oWzULZnM8sNNI72MecvfZn5Oi0ZEJhFh+HETlJnIT
 7gh7CGFBxPacT8vHxmeMPod7qrvYgKW+QKhU+tAI8gkI6hHXLBg/dxn7wAwTjlX1bo+jRJyp
 Id5SuAU=
In-Reply-To: <6a0a096b-47c2-4568-be9f-9f230bc6df23@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 07/01/2025 18:01, Jan Beulich wrote:
> On 07.01.2025 17:51, Michal Orzel wrote:
>>
>>
>> On 07/01/2025 17:42, Julien Grall wrote:
>>>
>>>
>>> Hi,
>>>
>>> On 16/12/2024 14:36, Jan Beulich wrote:
>>>> On 16.12.2024 15:28, Carlo Nonato wrote:
>>>>> On Mon, Dec 16, 2024 at 2:56 PM Michal Orzel <michal.orzel@amd.com> wrote:
>>>>>> On 13/12/2024 17:28, Carlo Nonato wrote:
>>>>>>> --- a/xen/arch/arm/arm64/mmu/mm.c
>>>>>>> +++ b/xen/arch/arm/arm64/mmu/mm.c
>>>>>>> @@ -1,6 +1,7 @@
>>>>>>>   /* SPDX-License-Identifier: GPL-2.0-only */
>>>>>>>
>>>>>>>   #include <xen/init.h>
>>>>>>> +#include <xen/llc-coloring.h>
>>>>>>>   #include <xen/mm.h>
>>>>>>>   #include <xen/pfn.h>
>>>>>>>
>>>>>>> @@ -138,8 +139,36 @@ void update_boot_mapping(bool enable)
>>>>>>>   }
>>>>>>>
>>>>>>>   extern void switch_ttbr_id(uint64_t ttbr);
>>>>>>> +extern void relocate_xen(uint64_t ttbr, void *src, void *dst, size_t len);
>>>>>>>
>>>>>>>   typedef void (switch_ttbr_fn)(uint64_t ttbr);
>>>>>>> +typedef void (relocate_xen_fn)(uint64_t ttbr, void *src, void *dst, size_t len);
>>>>>>> +
>>>>>>> +void __init relocate_and_switch_ttbr(uint64_t ttbr) {
>>>>>> CODING_STYLE: { needs to be on its own line
>>>>>>
>>>>>> Also, this function is only executed in case of LLC coloring, so shouldn't it
>>>>>> be #ifdef protected.
>>>>>
>>>>> Here and in other places (patch #8) I'm relying on DCE to remove functions
>>>>> that are not called. This was a suggestion from Jan in that patch. Can we
>>>>> adopt the same here?
>>>>
>>>> Yet how would the compiler spot that the function is unused? That would only
>>>> work with LTO / WPO. DCE (as I did suggest elsewhere) requires the functions
>>>> in question to be static (allowing the compiler to see enough of the whole
>>>> picture).
>>>
>>> Sorry for the late answer. I was away with limited e-mail access. While
>>> looking what was committing recently, I noticed that a dummy function
>>> was introduced:
>>>
>>> void __init relocate_and_switch_ttbr(uint64_t ttbr) {}
>>>
>>> If a function is not supposed to be called, then it should contain a
>>> BUG_ON() to catch any misusage. Otherwise, this is a recipe for
>>> disaster. In this case, it would not be trivial to notice the TTBR was
>>> not switched...
>>>
>>> That said I would have actually considered to remove the empty stub. I
>>> am a bit surprised that DCE wouldn't work in this case because the call
>>> is protected with "if ( llc_coloring_enabled )". When cache coloring is
>>> not enabled, this would turn to an "if ( false )" and therefore all the
>>> code should be removed. What did I miss?
>>>
>>> Note that this is what we already rely on for arm32 because there is no
>>> stub... So if this is problem then we definitely need to fix it on arm32
>>> as well...
>>>
>>> IOW, we either introduce a stub (including the BUG_ON) for both arm32
>>> and arm64 in the header or we remove the stub completely.
>>>
>>> Marco, Michal, can you have a look? Ideally, this should be fixed for 4.20.
>> I did a test with GCC 13.2 and I can compile it fine with stub removed. That said,
>> I'm not a compiler expert and I'm not sure if this behavior stays the same with different
>> compiler options/optimizations. So it's more like a question to Jan. I'm happy either way.
> 
> We use the same (if(...) func();) in various places, relying on said DCEing
> of the call when the condition is compile-time-false. I see no reason why
> it couldn't be used here as well.

IIRC the point was that his function is extern and DCE as used in other places doesn't necessarily work.

Andrea


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 17:19:06 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 17:19:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866736.1278084 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVDEJ-0004mG-H8; Tue, 07 Jan 2025 17:18:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866736.1278084; Tue, 07 Jan 2025 17:18:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVDEJ-0004m9-E6; Tue, 07 Jan 2025 17:18:59 +0000
Received: by outflank-mailman (input) for mailman id 866736;
 Tue, 07 Jan 2025 17:18:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=6kTq=T7=gmail.com=w1benny@srs-se1.protection.inumbo.net>)
 id 1tVDEH-0004m3-FU
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 17:18:57 +0000
Received: from mail-oo1-xc30.google.com (mail-oo1-xc30.google.com
 [2607:f8b0:4864:20::c30])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 78ea7ab1-cd1b-11ef-99a4-01e77a169b0f;
 Tue, 07 Jan 2025 18:18:55 +0100 (CET)
Received: by mail-oo1-xc30.google.com with SMTP id
 006d021491bc7-5f3610c395dso1338868eaf.2
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 09:18:55 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 78ea7ab1-cd1b-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736270334; x=1736875134; 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=PEE6e2LfZ3Nz/7dPmmiDJyNDKAXnj3mxI03pg3pUtVE=;
        b=a/N617Fs9TajG0PH3ONDRhPBrutyfgy1utLZEbAGiilI576fwr8sSxjZ4J+HmfPku+
         eobCDTMrK4iHJAi3e6K02PGidcqG/cgHsaArlwXTKPYQ8K30wxCAWw/ZAfOVV/kqRA2I
         YLAVIfHvqSNJiMD1kKYs80rvsRijDzmz5BHQi4LnIJE7jL1f0cbp0R13mAHW6x9yxtPz
         b2I2X/1uy63/Z7AWaIIxtEoPwgUaoAO9aYKWvbX1Sh+ZUzKqPVhXGguskCFYSYCvepGf
         HgMUDrypKh/mNL9rjdb0E6rfICVaP9r7gVhicvVj/lCAicOaBwhR2VM2QaRbkjF8/SYO
         KR4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736270334; x=1736875134;
        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=PEE6e2LfZ3Nz/7dPmmiDJyNDKAXnj3mxI03pg3pUtVE=;
        b=c5KkjsXlZXslefKGQgkA5coNpe5ZpZwbfVG1rDjofBoalEUFGxPY6GUUBkmZxXYO8I
         RxD0RO0QTI/bFmubdlp1CK3O9MrB+iPKplv7XZy6jvf1ByyZlLaYBA1R1M4awZzhS74J
         gif++/iNqvjnjY7yQcA83O5O37+DulCaNR5dvO8fLXnyAnxIfMjmiOgKFgmCF3OXXGdI
         6DgKRj7wruQc0wB8tE/3z/LC+olSAtup3XNxKOubPvsdW99xyFdnDPJb+iiOdMGoovr/
         qpvxuHK7RSBpKH7qxmD3gl9N/9VEpfLmd+CIaA/mbtyPyHkBnnHHd4V9wQmN+QW/9Tf4
         i75w==
X-Forwarded-Encrypted: i=1; AJvYcCUIBmyywuhmzT0LsZxGMoxWPSOFlSkqgEyk6bTQ2amqGbMnh4CVcxWUSJO8pVEAO1+q331uE1IvBMo=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxq1J/HQqdoDciQurEVNvTmP+b5tVK1pq/wBLoGokD3t+Oyl2nn
	pDJAzHBaccbILCep7s01k+BSMXPFcaDbhBbE15wAJdjfEWReoYZsTyFg4P/vjIZDtB7kZBnmKCq
	qeeHzz0eOjllEAVRIkWGuptiLXqQ=
X-Gm-Gg: ASbGncsDpWX/XZXpEu1BhtPy2CEJrXGFn+PFxAoxderUYvqAN3ux3NqvgVGs9xLIVel
	YRuPQ1raMfelrpm2+52MezP5FQ7x8ElVJwvjzKB4FjKiy+lWSKEL8Ob9O2lD2uM6xyDkLxHMa
X-Google-Smtp-Source: AGHT+IF/Tdx0/H0LQFmeXanbd5LVdu5zeAAPLELoYjwulF6hm+zzom5HsqX61l+UEapAfWN5KPOqQ0J3iy/52puc0cs=
X-Received: by 2002:a05:6871:d043:b0:29e:6ddf:22d2 with SMTP id
 586e51a60fabf-2a7fb2ea6c2mr11869609fac.9.1736270334153; Tue, 07 Jan 2025
 09:18:54 -0800 (PST)
MIME-Version: 1.0
References: <cover.1735837806.git.w1benny@gmail.com> <31a1ff2d5d1e17bb73231e008f1e47c501bb3ce8.1735837806.git.w1benny@gmail.com>
 <d6eb70a7-5895-4471-95b3-609f133fa457@suse.com>
In-Reply-To: <d6eb70a7-5895-4471-95b3-609f133fa457@suse.com>
From: =?UTF-8?Q?Petr_Bene=C5=A1?= <w1benny@gmail.com>
Date: Tue, 7 Jan 2025 18:18:42 +0100
X-Gm-Features: AbW1kvbbT0Ao77_SX8v_xwjhfJidiny3cOOBrs8_y1skS8wVZgZchQ5sT4cS7S0
Message-ID: <CAKBKdXjJm5194Wa=gy=DikiUEsevrB2Xn-idr+vgfgJMBrfZ-w@mail.gmail.com>
Subject: Re: [PATCH v3 2/2] x86: Add Support for Paging-Write Feature
To: Jan Beulich <jbeulich@suse.com>
Cc: Tamas K Lengyel <tamas@tklengyel.com>, Alexandru Isaila <aisaila@bitdefender.com>, 
	Petre Pircalabu <ppircalabu@bitdefender.com>, Stefano Stabellini <sstabellini@kernel.org>, 
	Julien Grall <julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>, 
	Michal Orzel <michal.orzel@amd.com>, Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>, 
	Andrew Cooper <andrew.cooper3@citrix.com>, Anthony PERARD <anthony.perard@vates.tech>, 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
	xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 7, 2025 at 5:46=E2=80=AFPM Jan Beulich <jbeulich@suse.com> wrot=
e:
> Hmm ... Instead of you touching the bit in every one of the case blocks,
> I was expecting you to clear the bit ahead of the switch(), accepting a
> double update in the p2m_access_r_pw case.

I did consider it, but ultimately didn't like the double-update.
Similarly, the switch-case above does also set each bit in the
"case-s" individually. But I understand it's more justified there.
However, if you insist, I'll fix it.

P.


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 17:20:03 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 17:20:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866742.1278093 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVDFK-0005Qr-PU; Tue, 07 Jan 2025 17:20:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866742.1278093; Tue, 07 Jan 2025 17:20:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVDFK-0005QI-MZ; Tue, 07 Jan 2025 17:20:02 +0000
Received: by outflank-mailman (input) for mailman id 866742;
 Tue, 07 Jan 2025 17:20:02 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=QnJ5=T7=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tVDFK-0005FA-CM
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 17:20:02 +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 a0306a5e-cd1b-11ef-99a4-01e77a169b0f;
 Tue, 07 Jan 2025 18:20:00 +0100 (CET)
Received: by mail-lf1-x134.google.com with SMTP id
 2adb3069b0e04-54025432becso16538407e87.1
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 09:20:00 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-54223832050sm5203894e87.250.2025.01.07.09.19.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 09:19:59 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a0306a5e-cd1b-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736270400; x=1736875200; darn=lists.xenproject.org;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=W7H/ynRfDyCOwGwTQA/D5+HSBsFv0UOs9+tG3siBDRE=;
        b=ip44o8ym73mSLCXwxcXqn9grhG9bwYQ1lMtpzG0o4QafYU+29ft66NMuAcsddo44gM
         tG4vTXGTtWpHb2ebbojbTEuCj0Y2VfRCjQsCxfetIrbZZjOzX2Ar8k7BbGpCA543XigJ
         MajPKVhZ1AeOnOKxq3hRn7L54OVIah80u2pjZ7MWhH156SSV23uGZsYQzQ8gdSA9BuVh
         O7CjXCHpJ14RzxYtgTRIb9lJMbzFRjt6d2htyoWow3FPw1/4tToA35NAMoigE2DWe/aB
         /drpdpHptyk3GZiRGFpko+b5V2lruGXxLb6Q63BIBJugQX9kkejLamGnKHXPbw2Nn25v
         sFZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736270400; x=1736875200;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=W7H/ynRfDyCOwGwTQA/D5+HSBsFv0UOs9+tG3siBDRE=;
        b=ZyYLy8HlzysTk3QAVLRbvAdywhYBue82HGe685UNGIOSIcuEhJpf6e47gp7EDr1ARQ
         koqbfQwjrlno4zJ15rSBT6UG25D3Po45x6gs6bl/iwPxwK5l0qdMarWjISWp+THItP3b
         tb/zawg56GdVXokmwDHOAz60aJrgsHvTX8IVJHIzKZQOEDOXzVO76ooV+HUQGdPsgt+u
         mmQ8Shld63mukZ6tV6mr8H0ye3chi1ASjnocI9M+AImUAahyP4VgdaYWveUFjEDkjgpf
         2pYEPXEJq9dJTg8xgbKYYIJc1myEnHEbrFxWjbCQwmC4jgF7/PMGAn7Lz4HbihrRDA5l
         xXZQ==
X-Forwarded-Encrypted: i=1; AJvYcCVKCGI5DXpw64ley8xLffhCwEVAqKf58vEOC7cZjQkjo+N7PkXsJNcR16esQxoZNmU9M30hNaE98s0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YydzuoyhqJ5KzQXvxQXXZQuBG3aYSiBLZQZGEyj/fX/Nzg2XTT0
	WVpERzkQ/5XRtZ1umYmUMrgORKg6Oahw2GdudIfaLzHd9XNRx4SK
X-Gm-Gg: ASbGncv9TOIqurDUnZk0YmvDay1LaiWFCn1v7cDId2UU2p4BAna/+EJa36lGHSwobkl
	xxK7mLQA7gbNpuP/377Vr13d9b0dr5X5FBfoOLV/lDwtU6xbbSlv8vJ5tTCde62iGG+vITEjpLB
	9c8cSqcDVVy5IzeD2ovAus06vPaEWZJ3NQTOnWTVvf6+4Q2wXM3S+/mrHY58/rQW6gPQwatA6iJ
	aIfN2v1blLOxJGdXWXXgEyEjpYa2qnQCP/5pDCbRYJvl1QjOCYq63mnaXFNlTM+izLavg==
X-Google-Smtp-Source: AGHT+IHP9Fh5K/WdeHPCL/DUkdxLOqZimnO8WuMTtyHiTVToMTjHxZljxmHz9uIPAdEovVMdMkNa3g==
X-Received: by 2002:a05:6512:3b08:b0:542:23b3:d82c with SMTP id 2adb3069b0e04-542295244aamr21108187e87.3.1736270399961;
        Tue, 07 Jan 2025 09:19:59 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------6vxAePtrhmi5yKrdjAaaRm4b"
Message-ID: <f62147a9-baad-49c4-8598-fb57a3505084@gmail.com>
Date: Tue, 7 Jan 2025 18:19:58 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/arm: ffa: add changelog entries for FF-A improvements
To: Bertrand Marquis <bertrand.marquis@arm.com>,
 xen-devel@lists.xenproject.org
Cc: Community Manager <community.manager@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Michal Orzel <michal.orzel@amd.com>
References: <059ad52a5d2aa6fb7fabe44fe2a99d8b73c1b907.1736240334.git.bertrand.marquis@arm.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <059ad52a5d2aa6fb7fabe44fe2a99d8b73c1b907.1736240334.git.bertrand.marquis@arm.com>

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

Hi Bertrand,

On 1/7/25 10:02 AM, Bertrand Marquis wrote:
> Add a CHANGELOG entry for release 4.20 to mention the various
> improvements and fixes that have been done in the FF-A support since
> 4.19 release.
>
> Signed-off-by: Bertrand Marquis<bertrand.marquis@arm.com>

Release-Acked-By: Oleksii Kurochko<oleksii.kurochko@gmail.com>

Thanks.

~ Oleksii

> ---
>   CHANGELOG.md | 3 +++
>   1 file changed, 3 insertions(+)
>
> diff --git a/CHANGELOG.md b/CHANGELOG.md
> index 8507e6556a56..d58a2ffd130b 100644
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -22,6 +22,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>      - Basic handling for SCMI requests over SMC using Shared Memory, by allowing
>        forwarding the calls to EL3 FW if coming from hwdom.
>      - Support for LLC (Last Level Cache) coloring.
> +   - Several FF-A support improvements: add indirect messages support, transmit
> +     RXTX buffer to the SPMC, fix version negotication and partition
> +     information retrieval.
>    - On x86:
>      - xl suspend/resume subcommands.
>   
--------------6vxAePtrhmi5yKrdjAaaRm4b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <pre>Hi Bertrand,
</pre>
    <div class="moz-cite-prefix">On 1/7/25 10:02 AM, Bertrand Marquis
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:059ad52a5d2aa6fb7fabe44fe2a99d8b73c1b907.1736240334.git.bertrand.marquis@arm.com">
      <pre wrap="" class="moz-quote-pre">Add a CHANGELOG entry for release 4.20 to mention the various
improvements and fixes that have been done in the FF-A support since
4.19 release.

Signed-off-by: Bertrand Marquis <a class="moz-txt-link-rfc2396E" href="mailto:bertrand.marquis@arm.com">&lt;bertrand.marquis@arm.com&gt;</a></pre>
    </blockquote>
    <pre>Release-Acked-By: Oleksii Kurochko <a class="moz-txt-link-rfc2396E" href="mailto:oleksii.kurochko@gmail.com">&lt;oleksii.kurochko@gmail.com&gt;</a>

Thanks.

~ Oleksii
</pre>
    <blockquote type="cite"
cite="mid:059ad52a5d2aa6fb7fabe44fe2a99d8b73c1b907.1736240334.git.bertrand.marquis@arm.com">
      <pre wrap="" class="moz-quote-pre">
---
 CHANGELOG.md | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 8507e6556a56..d58a2ffd130b 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -22,6 +22,9 @@ The format is based on [Keep a Changelog](<a class="moz-txt-link-freetext" href="https://keepachangelog.com/en/1.0.0/">https://keepachangelog.com/en/1.0.0/</a>)
    - Basic handling for SCMI requests over SMC using Shared Memory, by allowing
      forwarding the calls to EL3 FW if coming from hwdom.
    - Support for LLC (Last Level Cache) coloring.
+   - Several FF-A support improvements: add indirect messages support, transmit
+     RXTX buffer to the SPMC, fix version negotication and partition
+     information retrieval.
  - On x86:
    - xl suspend/resume subcommands.
 
</pre>
    </blockquote>
  </body>
</html>

--------------6vxAePtrhmi5yKrdjAaaRm4b--


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 17:34:10 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 17:34:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866749.1278103 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVDSr-0000jD-Ue; Tue, 07 Jan 2025 17:34:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866749.1278103; Tue, 07 Jan 2025 17:34:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVDSr-0000j6-S3; Tue, 07 Jan 2025 17:34:01 +0000
Received: by outflank-mailman (input) for mailman id 866749;
 Tue, 07 Jan 2025 17:34: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 <SRS0=1Lmc=T7=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tVDSq-0000j0-9A
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 17:34:01 +0000
Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 92b890c6-cd1d-11ef-99a4-01e77a169b0f;
 Tue, 07 Jan 2025 18:33:57 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 92b890c6-cd1d-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1736271236; x=1736530436;
	bh=NYf+6+hrft/X5UEK8JE1eueVbjg1RUDSbo+OVeRWfLw=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=jqtSO8HJGmGS8rJ1CrKC/jm/IolByH+Hb3ZRpI8OjollejcSOPBdJDyz10lJK1yMD
	 E8+q90YhUXVUammnJ0ukjPaEoKkJRGUMFRd4kuxYJkGbf0EMIqUCkNJEyIL5I7iTv3
	 uopLvPFuH5qHp/rm+FMb86OHXDAfP61gATISVi6ujhm3FIgVtUDu+3fX0t/4ce5/k5
	 xgS8SX/59eiBrgTWF2XiczP46s9NpuDA65j0ghRSVOyKghgrmS3j/2bv5d5TCDG6Ux
	 cPtdpNlhHEoen4fid2JsHrPwnGqX+rsEW85qj81SjK5X4Lw8FVw7QjHh3lHPCeLmkz
	 hsEBONgFqkaZQ==
Date: Tue, 07 Jan 2025 17:33:50 +0000
To: =?utf-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2 33/35] x86/domain: implement domain_has_vuart()
Message-ID: <8GErGVsReNynzNxyHVTyoG09VZfDD9A46tDUhGYekYMJ5C6liUOAYyi-esuVmIFlqmWt7O633k8YXQlfkhFKZ_452-FLcejATCdi56FVLzI=@proton.me>
In-Reply-To: <Z31FONoeaHVRHVxY@macbook.local>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-33-e9aa923127eb@ford.com> <Z1wnUzDCPDzHKr6o@macbook.local> <Tz4Idf7hUa85arksVC6UYYRNbhinY-0wHXqxIInbLCWGNiGZSEIvGNGLmICNLmHK5o7m6MUMhnUlrJX10WO1XHhyRSgCX7Gknz0xBGZJiD8=@proton.me> <Z31FONoeaHVRHVxY@macbook.local>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 434f4034104a78e8273f61ef49c230db62ca0eed
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


On Tuesday, January 7th, 2025 at 7:16 AM, Roger Pau Monn=C3=A9 <roger.pau@c=
itrix.com> wrote:

>
>
> On Sat, Jan 04, 2025 at 05:19:07AM +0000, Denis Mukhin wrote:
>
> > On Friday, December 13th, 2024 at 4:23 AM, Roger Pau Monn=C3=A9 roger.p=
au@citrix.com wrote:
> >
> > > Albeit PVH is kind of HVM.
> >
> > PVH does not have vPIC so there's some more work to enable vUART
> > for PVH on x86: emulator currently supports only ISA IRQs.
>
>
> But it does support vIO-APIC (as it's used for hardware PVH domain),
> so serial interrupts could still be delivered using the vIO-APIC if
> the guest has correctly configured the pin?

re: virtual I/O APIC: correct, that's what I meant by "more work":
I did not debug PVH in detail yet.

My plan is to enable PVH in a separate patch (timeline - v4, since v3
it out recently).

>
> Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 17:37:56 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 17:37:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866756.1278114 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVDWd-0001Gz-E2; Tue, 07 Jan 2025 17:37:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866756.1278114; Tue, 07 Jan 2025 17:37:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVDWd-0001Gs-BL; Tue, 07 Jan 2025 17:37:55 +0000
Received: by outflank-mailman (input) for mailman id 866756;
 Tue, 07 Jan 2025 17:37: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
 <SRS0=QnJ5=T7=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tVDWc-0001Gm-7y
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 17:37:54 +0000
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com
 [2a00:1450:4864:20::131])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1eac716f-cd1e-11ef-99a4-01e77a169b0f;
 Tue, 07 Jan 2025 18:37:52 +0100 (CET)
Received: by mail-lf1-x131.google.com with SMTP id
 2adb3069b0e04-54024ecc33dso2067632e87.0
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 09:37:52 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-542235f5fc3sm5211667e87.9.2025.01.07.09.37.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 09:37:50 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1eac716f-cd1e-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736271471; x=1736876271; darn=lists.xenproject.org;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=VfJcU2LYMx9yVqqiDBYK8Fe1TGE+OcJj/lGl7w9xJFY=;
        b=MLJxmLSQ9IvzWOSMx6mZOPdLE0S3fK4W8I+GX+0t6CFWmSvfH74jVLOmQSFO6h9xmu
         cNX5eXeAagm6C8hPlr1EfjBX+l0ph5XnXASIaz566HfvDwMc5E1BEQy62La0CceAB7md
         piqGuSJx/6mz0Q7W/AIOBp4Nq5Ii7KJLxgTb75EQHZ/xzHq/DgzD6i5EQfuLLpqLBWLP
         MlQkWKwXlQutuQtM2hHl3q8mHrNv4S2fZGEJLWPFtknUYNKFr0gavIyO34PBts+ZflmV
         TEEKczJi9S5IRr20zMzUQhg+HoccQxmkpz1XIb4F5m9rwYnjCbPJ04T7xZsNBxAUkepu
         j17g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736271471; x=1736876271;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=VfJcU2LYMx9yVqqiDBYK8Fe1TGE+OcJj/lGl7w9xJFY=;
        b=IP1xvjorn4HRR+27kF2aHF2YucxKV1+RMzVSLHszzrqvvPOiEyWfDrG9sTDIsoGofd
         ILlL48MiKU2LwXFDndfyjnTjtNMk/oDxW0i4PeC+WD29seSipjX3ogA4dGnk+gj+qvQc
         ZU4YWbIDQWVjeulyVc10WdcBVFPCeiJ3jUl4lhqRQdpvCt9oereSaZXhtZdc1zDdpUzm
         mFwk5P2ctylzlcYUCvY6VM72DHnztVnlzvLtGWNfCucYuJR+4G3K7Z9/Ydsl+vaHxwPW
         dQytoQHkkFHYYReY5DL3XO4suL3hV3a3ELrvyu9qCNBZYQ+xB1pC5HzQCCDJJwb1gwOg
         V3EA==
X-Gm-Message-State: AOJu0YxEQqfDDSziXDrCEi4tG5r+psaHvqPztxK7z+0DqiHsbWd37soR
	Eqac3q1nY407tjfSIyVDBKShoey5yhHc68z5UMhLo0uzOKmZ0gSL8JKKzZ0I
X-Gm-Gg: ASbGncvICaunkhlC7jhW+YotK3XfBdSnb3aJ7eBst+pSjBOmCM+NkggscoA8s/s9TMH
	dhdBnz1PwbSPifTkGR0Wu7tymNqmyS1soFN2RR6LySgp3GhPAEE7T31h/UsUcjl/3JsJ35B9RJ5
	3MkASr1GvJn77GdQhA1pIsS66vMv9WaHo9MZiRsTBdUlzUegAVtnUgsKnfz2eN5eDHS7AHN1smH
	0/S9Mua2d15AwCebWEAv3DbfMYZo9zsChsSXsPEbDK4Esy2lKCpfbzF7RbvmaW5I9ONVw==
X-Google-Smtp-Source: AGHT+IE8Q1fsIlrUpedqEzxOIWKKokYXARy8WNny7NJromVSgs9sQNUvlKXgYrd8JtuJ4MmLVo/mjw==
X-Received: by 2002:a05:6512:1289:b0:540:2a6e:372d with SMTP id 2adb3069b0e04-5422954b939mr18297978e87.30.1736271470742;
        Tue, 07 Jan 2025 09:37:50 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------oRz0RC70JrIphK7mbrCnVpXT"
Message-ID: <77f11aeb-40a2-47b0-accf-782941d26f81@gmail.com>
Date: Tue, 7 Jan 2025 18:37:50 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Xen 4.20 Development Update [December]
To: xen-devel@lists.xenproject.org
Cc: kelly.choi@cloud.com, committers@xenproject.org
References: <20250107173117.79047-1-oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <20250107173117.79047-1-oleksii.kurochko@gmail.com>

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

Missed to add one item to x86 about "x86/efi: Fix booting when NX is disabled".

Please find some details below.


On 1/7/25 6:31 PM, Oleksii Kurochko wrote:
> Hello everyone,
>
> This email only tracks big items for xen.git tree. Please reply for items you
> would like to see in 4.20 so that people have an idea what is going on and
> prioritise accordingly.
>
> You're welcome to provide description and use cases of the feature you're
> working on.
>
> = Timeline =
>
> * Last posting date: Nov 29, 2024
> * Feature freeze date: Dec 20, 2024
> ---> We are here
> * RC1: Jan 10, 2025
> * Hard code freeze: Jan 17, 2025
> * Release: Feb 21, 2025
> ( current release schedule:https://wiki.xenproject.org/wiki/Xen_Project_X.YY_Release_Notes )
>
> This will likely be the last Xen 4.20 Development Update email, as we have
> passed the feature freeze date, so no significant updates are expected until
> the Xen 4.20 release.
>
> The next email with development updates will cover Xen 4.21.
>
> Below, you can find a summary of the tasks completed by the end of
> December 2024, followed by a list of tasks still in progress ( it is
> up-to-date also ), which will be moved to the Xen 4.21 task list.
>
> The following items ( the links for them could be found int the list below )
> were moved to completed:
>
> [Dec]:
> - x86:
>    * x86/mm: miscellaneous fixes.
>    * Remove "APX support" task as Jan B. told:
>        I think you want to remove this from the list. While I have completed
>        work there, I'm not fancying re-basing ahead of the AVX10 work, and hence
>        that needs to go in first anyway. Which seems unlikely enough at this
>        point, for 4.20.
>    * Support device passthrough when dom0 is PVH on Xen.
> - Arm:
>    * Prerequisite patches for R82 upstreaming
>    * Add support for S32CC platforms and LINFlexD UART.
>    * Arm cache coloring.
>    * ffa: Improvements and fixes.
>    * Enable early bootup of AArch64 MPU systems.
>    * Enable early bootup of AArch64 MPU systems (Part 2)
> - RISC-V:
>    * Unflattening and relocation of host device tree
>
> [Nov]:
> - Hypervisor:
>    * drivers/char: rename arm-uart.c to uart-init.c
>    * Move gic_preinit() to common code
>    * stubdom: reduce xenstore library dependencies
>    * xen/trace: Treewide API cleanup
> - x86:
>    * x86/HVM: drop stdvga caching mode
>    * Fix module-handling use-after-free's
>    * Reuse 32 bit C code more safely
>    * xen: address violations of MISRA C Rule 13.6
>    * x86/ucode: Simplify/fix loading paths further
>    * x86: address violations of MISRA C Rule 16.3
>    * iommu/x86: fixes/improvements for unity range checks
>    * x86/pvh: Support relocating dom0 kernel
> - Arm:
>    * xen/arm: Add emulation of Debug Data Transfer Registers
> - RISC-V:
>    * Setup memory management
>
>
> * Full list of items : *
>
> = Projects =
>
> == Hypervisor ==
>
> *  Remove the directmap (v4)
>    -  Elias El Yandouzi
>    -https://lore.kernel.org/xen-devel/f6973275-0d7e-4db4-b949-f21e530e1dfc@citrix.com/T/#m9733aa717edf032db0cf8f8f6763537b4f30c1f8
>
> *  remove libxenctrl usage from xenstored (v1 -> v6)
>    -  Juergen Gross
>    -https://lore.kernel.org/xen-devel/20250107101711.5980-1-jgross@suse.com/T/#me3a5e025aef6a3431c21e81c670bf09744f2fe35
>
> *  automation: Refresh the remaining Debian containers (v2)
>    -  Javi Merino
>    -https://lore.kernel.org/xen-devel/cover.1730743077.git.javi.merino@cloud.com/T/#m5d9acb7cf5db3c2be3d6527de14b69b07812314e
>
> *  GRUB: Supporting Secure Boot of xen.gz (v1)
>    -  Ross Lagerwall
>    -https://patchew.org/Xen/20240313150748.791236-1-ross.lagerwall@citrix.com/
>
> *  MSI-X support with qemu in stubdomain, and other related changes (v8)
>    -  Marek Marczykowski-Górecki
>    -https://lore.kernel.org/xen-devel/cover.33fb4385b7dd6c53bda4acf0a9e91748b3d7b1f7.1715313192.git-series.marmarek@invisiblethingslab.com/
>    -  Only automation patch left to be reviewed/merged.
>
> *  [RFC] Introduce xenbindgen to autogen hypercall structs (v1)
>    -  Alejandro Vallejo
>    -https://patchew.org/Xen/20241115115200.2824-1-alejandro.vallejo@cloud.com/
>
> *  Introduce NS8250 UART emulator (v1 -> v2)
>    -  Denis Mukhin
>    -https://patchew.org/Xen/20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com/
>
> === x86 ===

* x86/efi: Fix booting when NX is disabled (v1)
   - Andrew Cooper
   -https://patchew.org/Xen/20240722101838.3946983-1-andrew.cooper3@citrix.com/

~ Oleksii

> *  Expose consistent topology to guests (v7)
>    -  Alejandro Vallejo
>    -https://patchew.org/Xen/20241021154600.11745-1-alejandro.vallejo@cloud.com/
>
> *  Boot modules for Hyperlaunch (v8 -> v9)
>    -  Daniel P. Smith
>    -https://patchew.org/Xen/20241115131204.32135-1-dpsmith@apertussolutions.com/
>
> *  Address Space Isolation FPU preparations (v2)
>    -  Alejandro Vallejo
>    -https://patchew.org/Xen/20241105143310.28301-1-alejandro.vallejo@cloud.com/
>
> *  x86/alternatives: Adjust all insn-relative fields (v2)
>    -  Andrew Cooper
>    -https://lore.kernel.org/xen-devel/20241002152725.1841575-1-andrew.cooper3@citrix.com/T/#mac2deaea7e02a343210d61887486433d946ad129
>
> *  x86emul: misc additions (v5 -> v7)
>    -  Jan Beulich
>    -https://patchew.org/Xen/3a25cd59-e1cb-4bfc-b868-fb11599d22f5@suse.com/
>
> *  x86/HVM: emulation (MMIO) improvements (v2)
>    -  Jan Beulich
>    -https://patchew.org/Xen/3294f629-f91f-4b5d-9eb0-40a34aa2ec3e@suse.com/
>
> *  x86: support AVX10 (v2 -> v3)
>    -  Jan Beulich
>    -https://patchew.org/Xen/516b7f9a-048e-409d-8a4e-89aeb8ffacc4@suse.com/
>
> *  VT-d: SATC handling; ATS: tidying (v2)
>    -  Jan Beulich
>    -https://patchew.org/Xen/64b028be-2197-4951-ae5b-32f9eabfa84a@suse.com/
>
> *  x86: parallelize AP bring-up during boot (v1)
>    -  Krystian Hebel
>    -https://lore.kernel.org/xen-devel/cover.1699982111.git.krystian.hebel@3mdeb.com/
>
> *  x86/spec-ctrl: IBPB improvements (v4)
>    -  Jan Beulich
>    -https://patchew.org/Xen/06591b64-2f05-a4cc-a2f3-a74c3c4a76d6@suse.com/
>
> *  Move some boot code from assembly to C (v2)
>    -  Frediano Ziglio
>    -https://patchew.org/Xen/20241122093358.478774-1-frediano.ziglio@cloud.com/
>
> *  Hyperlaunch device tree for dom0 (v1 -> v2)
>    -  Daniel P. Smith
>    -https://patchew.org/Xen/20241226165740.29812-1-dpsmith@apertussolutions.com/
>
> *  x86: memcpy() / memset() (non-)ERMS flavors plus fallout (v3)
>    -  Jan Beulich
>    -https://patchew.org/Xen/e7314ac8-ed09-4da8-b915-09409b01fe77@suse.com/
>
> *  amd-pstate CPU Performance Scaling Driver (v1)
>    -  Penny Zheng
>    -https://patchew.org/Xen/20241203081111.463400-1-Penny.Zheng@amd.com/
>
> === ARM ===
>
> *  Add Virtio-PCI for dom0less on ARM (v1)
>    -  Edgar E. Iglesias
>    -https://lore.kernel.org/xen-devel/20240924162359.1390487-1-edgar.iglesias@gmail.com/T/#mfa148991b9408f223a079d4cef610244d5b04c2b
>
> *  PCI devices passthrough on Arm, part 3 (v16)
>    -  Stewart Hildebrand
>    -https://patchew.org/Xen/20240522225927.77398-1-stewart.hildebrand@amd.com/
>    -  Patches are Acked but for some reason last two patches aren't merged.
>
> *  DOMCTL-based guest magic region allocation for 11 domUs (v4)
>    -  Henry Wang
>    -https://patchew.org/Xen/20240409045357.236802-1-xin.wang2@amd.com/
>
> === RISCV ===
>
> === PPC ===
>
> *  Early Boot Allocation on Power (v5)
>    -  Shawn Anastasio
>    -https://lore.kernel.org/xen-devel/cover.1727388925.git.sanastasio@raptorengineering.com/T/#m8cac91a93b56a359fa2d5f08596c4be61dca290d
>
> == Completed ==
>
> === Hypervisor ===
>
> *  libxl: Implement QEMU command line probe (v1)
>    -  Anthony PERARD
>    -https://lore.kernel.org/xen-devel/20240827100328.23216-1-anthony.perard@vates.tech/T/#mdef23cefc2532ab0c9d7460290cef26780cf97cb
>
> *  xen/bitops: hweight() cleanup/improvements (v3)
>    -  Andrew Cooper
>    -https://lore.kernel.org/xen-devel/20240904225530.3888315-1-andrew.cooper3@citrix.com/T/#me22e08f7477be725122dd9b97d29d272e3b586c4
>
> *  Move percpu code to common (v2)
>    -  Oleksii Kurochko
>    -https://lore.kernel.org/xen-devel/cover.1727185495.git.oleksii.kurochko@gmail.com/T/#mf93394c46f15cbdcfc873de2d52d862a8b70da7f
>
> *  xen/livepatch: improvements to loading (v3)
>    -  Roger Pau Monne
>    -https://lore.kernel.org/xen-devel/20240926101431.97444-1-roger.pau@citrix.com/T/#ma3f65948b065dc443aea2192873a3b3dfa52a2d7
>
> *  Move {acpi_}device_init() and device_get_class() to common code (v5)
>    -  Oleksii Kurochko
>    -https://lore.kernel.org/xen-devel/17c7d988e45d7c82448b81fe66b01a5ceca0c15e.camel@gmail.com/T/#m68bd00d4f8b3724e83ba13024e94b15b58a28829
>
> *  blkif: reconcile protocol specification with in-use implementations (v1)
>    -  Roger Pau Monne
>    -https://lore.kernel.org/xen-devel/20240903141923.72241-1-roger.pau@citrix.com/
>
> *  Move gic_preinit() to common code (v5)
>    -  Oleksii Kurochko
>    -https://lore.kernel.org/xen-devel/151ac176ff02d2ff9b7f87e3c02b9ce0472720fa.1732288620.git.oleksii.kurochko@gmail.com/
>
> *  stubdom: reduce xenstore library dependencies (v1)
>    -  Juergen Gross
>    -https://lore.kernel.org/xen-devel/20241010155459.22389-1-jgross@suse.com/T/#m8b5af386e2d288961bb6e8f7839650e0cab96a83
>
> *  xen/trace: Treewide API cleanup (v7)
>    -  Andrew Cooper
>    -https://patchew.org/Xen/20240318163552.3808695-1-andrew.cooper3@citrix.com/
>
> === x86 ===
>
> *  x86/mm: miscellaneous fixes (v2 -> v3)
>    -  Roger Pau Monne
>    -https://patchew.org/Xen/20241114145715.59777-1-roger.pau@citrix.com/
>
> *  Support device passthrough when dom0 is PVH on Xen (v16)
>    -  Jiqian Chen
>    -https://lore.kernel.org/xen-devel/20240930034250.2682265-1-Jiqian.Chen@amd.com/T/#m5d557d76f290ff5b5550c1443cab5774d397e526
>
> *  Drop Xeon Phi support (v1)
>    -  Jan Beulich
>    -https://lore.kernel.org/xen-devel/44147507-65a4-4f21-aada-fa647f53ffd0@suse.com/
>
> *  Utilize ucode_force and remove opt_ucode_allow_same (v7)
>    -  Fouad Hilly
>    -https://lore.kernel.org/xen-devel/20240822130426.492931-4-fouad.hilly@cloud.com/
>
> *  Switch flat driver to use phys dst for ext ints (v2)
>    -  Matthew Barnes
>    -https://lore.kernel.org/xen-devel/0db68e62ffc428f553a30397df1e79068d26bb5f.1728311378.git.matthew.barnes@cloud.com/
>
> *  x86/shutdown: change default reboot method preference (v1)
>    -  Roger Pau Monne
>    -https://lore.kernel.org/xen-devel/20240802105613.99197-1-roger.pau@citrix.com/
>
> *  x86/HVM: drop stdvga caching mode (v2)
>    -  Jan Beulich
>    -https://lore.kernel.org/xen-devel/dc3faf7d-0690-46e6-8fbc-67a177a1e171@suse.com/T/#mc8ca51cdbfb6ba26ea6b4624059d40ea075c2117
>
> *  Fix module-handling use-after-free's (v2)
>    -  Andrew Cooper
>    -https://lore.kernel.org/xen-devel/20241106003938.3453243-1-andrew.cooper3@citrix.com/T/#mdf923bdf63b034a6493bf62beeead280b92a38ed
>
> *  Reuse 32 bit C code more safely (v4)
>    -  Frediano Ziglio
>    -https://lore.kernel.org/xen-devel/20241014085332.3254546-1-frediano.ziglio@cloud.com/T/#m53e36815ddec2511ddd1fa8d1a7ed9a27c0cd0f7
>
> *  xen: address violations of MISRA C Rule 13.6 (v2)
>    -  Federico Serafini
>    -https://lore.kernel.org/xen-devel/cover.1727690180.git.federico.serafini@bugseng.com/T/#mbec702db211240305e0d35649e65627d9fa75a29
>
> *  x86/ucode: Simplify/fix loading paths further (v2)
>    -  Andrew Cooper
>    -https://lore.kernel.org/xen-devel/20241112211915.1473121-1-andrew.cooper3@citrix.com/
>
> *  x86: address violations of MISRA C Rule 16.3 (v2)
>    -  Federico Serafini
>    -https://patchew.org/Xen/cover.1731485149.git.federico.serafini@bugseng.com/
>
> *  iommu/x86: fixes/improvements for unity range checks (v4 ( [PATCH 4/4] iommu/x86: make unity range checking more strict? ))
>    -  Roger Pau Monne
>    -https://lore.kernel.org/xen-devel/20240201170159.66330-1-roger.pau@citrix.com/
>
> *  x86/pvh: Support relocating dom0 kernel (v7)
>    -  Jason Andryuk
>    -https://patchew.org/Xen/20240404212519.16401-1-jason.andryuk@amd.com/
>
> === ARM ===
>
> *  Prerequisite patches for R82 upstreaming (v4)
>    -  Luca Fancellu
>    -https://patchew.org/Xen/20241203094811.427076-1-luca.fancellu@arm.com/
>
> *  Enable early bootup of AArch64 MPU systems (Part 2) (v3)
>    -  Ayan Kumar Halder
>    -https://patchew.org/Xen/20241204172243.1229942-1-ayan.kumar.halder@amd.com/
>
> *  Enable early bootup of AArch64 MPU systems (v6)
>    -  Ayan Kumar Halder
>    -https://patchew.org/Xen/20241118121250.4027441-1-ayan.kumar.halder@amd.com/
>
> *  Add support for S32CC platforms and LINFlexD UART (v6)
>    -  Andrei Cherechesu
>    -https://patchew.org/Xen/20241219112315.2461048-1-andrei.cherechesu@oss.nxp.com/
>
> *  Arm cache coloring (v9 -> v11)
>    -  Carlo Nonato
>    -https://lore.kernel.org/xen-devel/20241202165921.249585-1-carlo.nonato@minervasys.tech/
>
> *  ffa: Improvements and fixes (v2 -> v3)
>    -  Bertrand Marquis
>    -https://lore.kernel.org/xen-devel/cover.1732702210.git.bertrand.marquis@arm.com/
>
> *  iommu/ipmmu-vmsa: Add Renesas R8A779G0 (R-Car V4H) support (v1)
>    -  Grygorii Strashko
>    -https://lore.kernel.org/xen-devel/6ab4ad29-404d-4f5c-8582-5d2f492fd549@xen.org/T/#t
>
> *  xen/arm: dt overlay fixes (v2)
>    -  Michal Orzel
>    -https://lore.kernel.org/xen-devel/20241004122220.234817-1-michal.orzel@amd.com/T/#md51a060b93fe72f17637d6d72e3d4e2296cb4078
>
> *  xen/arm: Add emulation of Debug Data Transfer Registers (v6)
>    -  Ayan Kumar Halder
>    -https://patchew.org/Xen/20240307123943.1991755-1-ayan.kumar.halder@amd.com/
>
> === RISC-V ===
>
> *  Unflattening and relocation of host device tree (v1)
>    -  Oleksii Kurochko
>    -https://patchew.org/Xen/cover.1732709650.git.oleksii.kurochko@gmail.com/
>
> *  initialize bootinfo from dtb (v2)
>    -  Oleksii Kurochko
>    -https://lore.kernel.org/xen-devel/cover.1728481578.git.oleksii.kurochko@gmail.com/T/#m543bf84d47f0ea738938a9a442cd144bb34f7316
>
> *  Register Xen's load address as a boot module (v3)
>    -  Oleksii Kurochko
>    -https://lore.kernel.org/xen-devel/cover.1728472163.git.oleksii.kurochko@gmail.com/T/#t
>
> *  device tree mapping (v9)
>    -  Oleksii Kurochko
>    -https://lore.kernel.org/xen-devel/cover.1727781468.git.oleksii.kurochko@gmail.com/T/#t
>
> *  Setup memory management (v5)
>    -  Oleksii Kurochko
>    -https://lore.kernel.org/xen-devel/cover.1731344883.git.oleksii.kurochko@gmail.com/T/#m9f76f1b685896ea603a2b153e05104c7405a7d28
>
>
> Have a good week!
>
> Best regards,
>   Oleksii
--------------oRz0RC70JrIphK7mbrCnVpXT
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <pre>Missed to add one item to x86 about "x86/efi: Fix booting when NX is disabled".</pre>
    <pre>Please find some details below.</pre>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 1/7/25 6:31 PM, Oleksii Kurochko
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:20250107173117.79047-1-oleksii.kurochko@gmail.com">
      <pre wrap="" class="moz-quote-pre">Hello everyone,

This email only tracks big items for xen.git tree. Please reply for items you
would like to see in 4.20 so that people have an idea what is going on and
prioritise accordingly.

You're welcome to provide description and use cases of the feature you're
working on.

= Timeline =

* Last posting date: Nov 29, 2024
* Feature freeze date: Dec 20, 2024
---&gt; We are here
* RC1: Jan 10, 2025
* Hard code freeze: Jan 17, 2025
* Release: Feb 21, 2025
( current release schedule: <a class="moz-txt-link-freetext" href="https://wiki.xenproject.org/wiki/Xen_Project_X.YY_Release_Notes">https://wiki.xenproject.org/wiki/Xen_Project_X.YY_Release_Notes</a> )

This will likely be the last Xen 4.20 Development Update email, as we have
passed the feature freeze date, so no significant updates are expected until
the Xen 4.20 release.

The next email with development updates will cover Xen 4.21.

Below, you can find a summary of the tasks completed by the end of
December 2024, followed by a list of tasks still in progress ( it is
up-to-date also ), which will be moved to the Xen 4.21 task list.

The following items ( the links for them could be found int the list below )
were moved to completed:

[Dec]:
- x86:
  * x86/mm: miscellaneous fixes.
  * Remove "APX support" task as Jan B. told:
      I think you want to remove this from the list. While I have completed
      work there, I'm not fancying re-basing ahead of the AVX10 work, and hence
      that needs to go in first anyway. Which seems unlikely enough at this
      point, for 4.20.
  * Support device passthrough when dom0 is PVH on Xen.
- Arm:
  * Prerequisite patches for R82 upstreaming
  * Add support for S32CC platforms and LINFlexD UART.
  * Arm cache coloring.
  * ffa: Improvements and fixes.
  * Enable early bootup of AArch64 MPU systems.
  * Enable early bootup of AArch64 MPU systems (Part 2)
- RISC-V:
  * Unflattening and relocation of host device tree

[Nov]:
- Hypervisor:
  * drivers/char: rename arm-uart.c to uart-init.c
  * Move gic_preinit() to common code
  * stubdom: reduce xenstore library dependencies
  * xen/trace: Treewide API cleanup
- x86:
  * x86/HVM: drop stdvga caching mode
  * Fix module-handling use-after-free's
  * Reuse 32 bit C code more safely
  * xen: address violations of MISRA C Rule 13.6
  * x86/ucode: Simplify/fix loading paths further
  * x86: address violations of MISRA C Rule 16.3
  * iommu/x86: fixes/improvements for unity range checks
  * x86/pvh: Support relocating dom0 kernel
- Arm:
  * xen/arm: Add emulation of Debug Data Transfer Registers
- RISC-V:
  * Setup memory management


* Full list of items : *

= Projects =

== Hypervisor == 

*  Remove the directmap (v4)
  -  Elias El Yandouzi
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/f6973275-0d7e-4db4-b949-f21e530e1dfc@citrix.com/T/#m9733aa717edf032db0cf8f8f6763537b4f30c1f8">https://lore.kernel.org/xen-devel/f6973275-0d7e-4db4-b949-f21e530e1dfc@citrix.com/T/#m9733aa717edf032db0cf8f8f6763537b4f30c1f8</a>

*  remove libxenctrl usage from xenstored (v1 -&gt; v6)
  -  Juergen Gross
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/20250107101711.5980-1-jgross@suse.com/T/#me3a5e025aef6a3431c21e81c670bf09744f2fe35">https://lore.kernel.org/xen-devel/20250107101711.5980-1-jgross@suse.com/T/#me3a5e025aef6a3431c21e81c670bf09744f2fe35</a>

*  automation: Refresh the remaining Debian containers (v2)
  -  Javi Merino
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/cover.1730743077.git.javi.merino@cloud.com/T/#m5d9acb7cf5db3c2be3d6527de14b69b07812314e">https://lore.kernel.org/xen-devel/cover.1730743077.git.javi.merino@cloud.com/T/#m5d9acb7cf5db3c2be3d6527de14b69b07812314e</a>

*  GRUB: Supporting Secure Boot of xen.gz (v1)
  -  Ross Lagerwall
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/20240313150748.791236-1-ross.lagerwall@citrix.com/">https://patchew.org/Xen/20240313150748.791236-1-ross.lagerwall@citrix.com/</a>

*  MSI-X support with qemu in stubdomain, and other related changes (v8)
  -  Marek Marczykowski-Górecki
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/cover.33fb4385b7dd6c53bda4acf0a9e91748b3d7b1f7.1715313192.git-series.marmarek@invisiblethingslab.com/">https://lore.kernel.org/xen-devel/cover.33fb4385b7dd6c53bda4acf0a9e91748b3d7b1f7.1715313192.git-series.marmarek@invisiblethingslab.com/</a>
  -  Only automation patch left to be reviewed/merged.

*  [RFC] Introduce xenbindgen to autogen hypercall structs (v1)
  -  Alejandro Vallejo
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/20241115115200.2824-1-alejandro.vallejo@cloud.com/">https://patchew.org/Xen/20241115115200.2824-1-alejandro.vallejo@cloud.com/</a>

*  Introduce NS8250 UART emulator (v1 -&gt; v2)
  -  Denis Mukhin
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com/">https://patchew.org/Xen/20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com/</a>

=== x86 === 
</pre>
    </blockquote>
    <pre>* x86/efi: Fix booting when NX is disabled (v1)
  - Andrew Cooper
  - <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/20240722101838.3946983-1-andrew.cooper3@citrix.com/">https://patchew.org/Xen/20240722101838.3946983-1-andrew.cooper3@citrix.com/</a></pre>
    <p>~ Oleksii<br>
    </p>
    <blockquote type="cite"
      cite="mid:20250107173117.79047-1-oleksii.kurochko@gmail.com">
      <pre wrap="" class="moz-quote-pre">
*  Expose consistent topology to guests (v7)
  -  Alejandro Vallejo
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/20241021154600.11745-1-alejandro.vallejo@cloud.com/">https://patchew.org/Xen/20241021154600.11745-1-alejandro.vallejo@cloud.com/</a>

*  Boot modules for Hyperlaunch (v8 -&gt; v9)
  -  Daniel P. Smith
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/20241115131204.32135-1-dpsmith@apertussolutions.com/">https://patchew.org/Xen/20241115131204.32135-1-dpsmith@apertussolutions.com/</a>

*  Address Space Isolation FPU preparations (v2)
  -  Alejandro Vallejo
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/20241105143310.28301-1-alejandro.vallejo@cloud.com/">https://patchew.org/Xen/20241105143310.28301-1-alejandro.vallejo@cloud.com/</a>

*  x86/alternatives: Adjust all insn-relative fields (v2)
  -  Andrew Cooper
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/20241002152725.1841575-1-andrew.cooper3@citrix.com/T/#mac2deaea7e02a343210d61887486433d946ad129">https://lore.kernel.org/xen-devel/20241002152725.1841575-1-andrew.cooper3@citrix.com/T/#mac2deaea7e02a343210d61887486433d946ad129</a>

*  x86emul: misc additions (v5 -&gt; v7)
  -  Jan Beulich
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/3a25cd59-e1cb-4bfc-b868-fb11599d22f5@suse.com/">https://patchew.org/Xen/3a25cd59-e1cb-4bfc-b868-fb11599d22f5@suse.com/</a>

*  x86/HVM: emulation (MMIO) improvements (v2)
  -  Jan Beulich
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/3294f629-f91f-4b5d-9eb0-40a34aa2ec3e@suse.com/">https://patchew.org/Xen/3294f629-f91f-4b5d-9eb0-40a34aa2ec3e@suse.com/</a>

*  x86: support AVX10 (v2 -&gt; v3)
  -  Jan Beulich
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/516b7f9a-048e-409d-8a4e-89aeb8ffacc4@suse.com/">https://patchew.org/Xen/516b7f9a-048e-409d-8a4e-89aeb8ffacc4@suse.com/</a>

*  VT-d: SATC handling; ATS: tidying (v2)
  -  Jan Beulich
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/64b028be-2197-4951-ae5b-32f9eabfa84a@suse.com/">https://patchew.org/Xen/64b028be-2197-4951-ae5b-32f9eabfa84a@suse.com/</a>

*  x86: parallelize AP bring-up during boot (v1)
  -  Krystian Hebel
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/cover.1699982111.git.krystian.hebel@3mdeb.com/">https://lore.kernel.org/xen-devel/cover.1699982111.git.krystian.hebel@3mdeb.com/</a>

*  x86/spec-ctrl: IBPB improvements (v4)
  -  Jan Beulich
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/06591b64-2f05-a4cc-a2f3-a74c3c4a76d6@suse.com/">https://patchew.org/Xen/06591b64-2f05-a4cc-a2f3-a74c3c4a76d6@suse.com/</a>

*  Move some boot code from assembly to C (v2)
  -  Frediano Ziglio
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/20241122093358.478774-1-frediano.ziglio@cloud.com/">https://patchew.org/Xen/20241122093358.478774-1-frediano.ziglio@cloud.com/</a>

*  Hyperlaunch device tree for dom0 (v1 -&gt; v2)
  -  Daniel P. Smith
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/20241226165740.29812-1-dpsmith@apertussolutions.com/">https://patchew.org/Xen/20241226165740.29812-1-dpsmith@apertussolutions.com/</a>

*  x86: memcpy() / memset() (non-)ERMS flavors plus fallout (v3)
  -  Jan Beulich
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/e7314ac8-ed09-4da8-b915-09409b01fe77@suse.com/">https://patchew.org/Xen/e7314ac8-ed09-4da8-b915-09409b01fe77@suse.com/</a>

*  amd-pstate CPU Performance Scaling Driver (v1)
  -  Penny Zheng
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/20241203081111.463400-1-Penny.Zheng@amd.com/">https://patchew.org/Xen/20241203081111.463400-1-Penny.Zheng@amd.com/</a>

=== ARM === 

*  Add Virtio-PCI for dom0less on ARM (v1)
  -  Edgar E. Iglesias
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/20240924162359.1390487-1-edgar.iglesias@gmail.com/T/#mfa148991b9408f223a079d4cef610244d5b04c2b">https://lore.kernel.org/xen-devel/20240924162359.1390487-1-edgar.iglesias@gmail.com/T/#mfa148991b9408f223a079d4cef610244d5b04c2b</a>

*  PCI devices passthrough on Arm, part 3 (v16)
  -  Stewart Hildebrand
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/20240522225927.77398-1-stewart.hildebrand@amd.com/">https://patchew.org/Xen/20240522225927.77398-1-stewart.hildebrand@amd.com/</a>
  -  Patches are Acked but for some reason last two patches aren't merged.

*  DOMCTL-based guest magic region allocation for 11 domUs (v4)
  -  Henry Wang
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/20240409045357.236802-1-xin.wang2@amd.com/">https://patchew.org/Xen/20240409045357.236802-1-xin.wang2@amd.com/</a>

=== RISCV === 

=== PPC === 

*  Early Boot Allocation on Power (v5)
  -  Shawn Anastasio
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/cover.1727388925.git.sanastasio@raptorengineering.com/T/#m8cac91a93b56a359fa2d5f08596c4be61dca290d">https://lore.kernel.org/xen-devel/cover.1727388925.git.sanastasio@raptorengineering.com/T/#m8cac91a93b56a359fa2d5f08596c4be61dca290d</a>

== Completed == 

=== Hypervisor === 

*  libxl: Implement QEMU command line probe (v1)
  -  Anthony PERARD
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/20240827100328.23216-1-anthony.perard@vates.tech/T/#mdef23cefc2532ab0c9d7460290cef26780cf97cb">https://lore.kernel.org/xen-devel/20240827100328.23216-1-anthony.perard@vates.tech/T/#mdef23cefc2532ab0c9d7460290cef26780cf97cb</a>

*  xen/bitops: hweight() cleanup/improvements (v3)
  -  Andrew Cooper 
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/20240904225530.3888315-1-andrew.cooper3@citrix.com/T/#me22e08f7477be725122dd9b97d29d272e3b586c4">https://lore.kernel.org/xen-devel/20240904225530.3888315-1-andrew.cooper3@citrix.com/T/#me22e08f7477be725122dd9b97d29d272e3b586c4</a>

*  Move percpu code to common (v2)
  -  Oleksii Kurochko
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/cover.1727185495.git.oleksii.kurochko@gmail.com/T/#mf93394c46f15cbdcfc873de2d52d862a8b70da7f">https://lore.kernel.org/xen-devel/cover.1727185495.git.oleksii.kurochko@gmail.com/T/#mf93394c46f15cbdcfc873de2d52d862a8b70da7f</a>

*  xen/livepatch: improvements to loading (v3)
  -  Roger Pau Monne
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/20240926101431.97444-1-roger.pau@citrix.com/T/#ma3f65948b065dc443aea2192873a3b3dfa52a2d7">https://lore.kernel.org/xen-devel/20240926101431.97444-1-roger.pau@citrix.com/T/#ma3f65948b065dc443aea2192873a3b3dfa52a2d7</a>

*  Move {acpi_}device_init() and device_get_class() to common code (v5)
  -  Oleksii Kurochko
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/17c7d988e45d7c82448b81fe66b01a5ceca0c15e.camel@gmail.com/T/#m68bd00d4f8b3724e83ba13024e94b15b58a28829">https://lore.kernel.org/xen-devel/17c7d988e45d7c82448b81fe66b01a5ceca0c15e.camel@gmail.com/T/#m68bd00d4f8b3724e83ba13024e94b15b58a28829</a>

*  blkif: reconcile protocol specification with in-use implementations (v1)
  -  Roger Pau Monne
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/20240903141923.72241-1-roger.pau@citrix.com/">https://lore.kernel.org/xen-devel/20240903141923.72241-1-roger.pau@citrix.com/</a>

*  Move gic_preinit() to common code (v5)
  -  Oleksii Kurochko
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/151ac176ff02d2ff9b7f87e3c02b9ce0472720fa.1732288620.git.oleksii.kurochko@gmail.com/">https://lore.kernel.org/xen-devel/151ac176ff02d2ff9b7f87e3c02b9ce0472720fa.1732288620.git.oleksii.kurochko@gmail.com/</a>

*  stubdom: reduce xenstore library dependencies (v1)
  -  Juergen Gross
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/20241010155459.22389-1-jgross@suse.com/T/#m8b5af386e2d288961bb6e8f7839650e0cab96a83">https://lore.kernel.org/xen-devel/20241010155459.22389-1-jgross@suse.com/T/#m8b5af386e2d288961bb6e8f7839650e0cab96a83</a>

*  xen/trace: Treewide API cleanup (v7)
  -  Andrew Cooper 
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/20240318163552.3808695-1-andrew.cooper3@citrix.com/">https://patchew.org/Xen/20240318163552.3808695-1-andrew.cooper3@citrix.com/</a>

=== x86 === 

*  x86/mm: miscellaneous fixes (v2 -&gt; v3)
  -  Roger Pau Monne
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/20241114145715.59777-1-roger.pau@citrix.com/">https://patchew.org/Xen/20241114145715.59777-1-roger.pau@citrix.com/</a>

*  Support device passthrough when dom0 is PVH on Xen (v16)
  -  Jiqian Chen
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/20240930034250.2682265-1-Jiqian.Chen@amd.com/T/#m5d557d76f290ff5b5550c1443cab5774d397e526">https://lore.kernel.org/xen-devel/20240930034250.2682265-1-Jiqian.Chen@amd.com/T/#m5d557d76f290ff5b5550c1443cab5774d397e526</a>

*  Drop Xeon Phi support (v1)
  -  Jan Beulich
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/44147507-65a4-4f21-aada-fa647f53ffd0@suse.com/">https://lore.kernel.org/xen-devel/44147507-65a4-4f21-aada-fa647f53ffd0@suse.com/</a>

*  Utilize ucode_force and remove opt_ucode_allow_same (v7)
  -  Fouad Hilly
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/20240822130426.492931-4-fouad.hilly@cloud.com/">https://lore.kernel.org/xen-devel/20240822130426.492931-4-fouad.hilly@cloud.com/</a>

*  Switch flat driver to use phys dst for ext ints (v2)
  -  Matthew Barnes
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/0db68e62ffc428f553a30397df1e79068d26bb5f.1728311378.git.matthew.barnes@cloud.com/">https://lore.kernel.org/xen-devel/0db68e62ffc428f553a30397df1e79068d26bb5f.1728311378.git.matthew.barnes@cloud.com/</a>

*  x86/shutdown: change default reboot method preference (v1)
  -  Roger Pau Monne
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/20240802105613.99197-1-roger.pau@citrix.com/">https://lore.kernel.org/xen-devel/20240802105613.99197-1-roger.pau@citrix.com/</a>

*  x86/HVM: drop stdvga caching mode (v2)
  -  Jan Beulich
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/dc3faf7d-0690-46e6-8fbc-67a177a1e171@suse.com/T/#mc8ca51cdbfb6ba26ea6b4624059d40ea075c2117">https://lore.kernel.org/xen-devel/dc3faf7d-0690-46e6-8fbc-67a177a1e171@suse.com/T/#mc8ca51cdbfb6ba26ea6b4624059d40ea075c2117</a>

*  Fix module-handling use-after-free's (v2)
  -  Andrew Cooper 
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/20241106003938.3453243-1-andrew.cooper3@citrix.com/T/#mdf923bdf63b034a6493bf62beeead280b92a38ed">https://lore.kernel.org/xen-devel/20241106003938.3453243-1-andrew.cooper3@citrix.com/T/#mdf923bdf63b034a6493bf62beeead280b92a38ed</a>

*  Reuse 32 bit C code more safely (v4)
  -  Frediano Ziglio
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/20241014085332.3254546-1-frediano.ziglio@cloud.com/T/#m53e36815ddec2511ddd1fa8d1a7ed9a27c0cd0f7">https://lore.kernel.org/xen-devel/20241014085332.3254546-1-frediano.ziglio@cloud.com/T/#m53e36815ddec2511ddd1fa8d1a7ed9a27c0cd0f7</a>

*  xen: address violations of MISRA C Rule 13.6 (v2)
  -  Federico Serafini
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/cover.1727690180.git.federico.serafini@bugseng.com/T/#mbec702db211240305e0d35649e65627d9fa75a29">https://lore.kernel.org/xen-devel/cover.1727690180.git.federico.serafini@bugseng.com/T/#mbec702db211240305e0d35649e65627d9fa75a29</a>

*  x86/ucode: Simplify/fix loading paths further (v2)
  -  Andrew Cooper 
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/20241112211915.1473121-1-andrew.cooper3@citrix.com/">https://lore.kernel.org/xen-devel/20241112211915.1473121-1-andrew.cooper3@citrix.com/</a>

*  x86: address violations of MISRA C Rule 16.3 (v2)
  -  Federico Serafini
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/cover.1731485149.git.federico.serafini@bugseng.com/">https://patchew.org/Xen/cover.1731485149.git.federico.serafini@bugseng.com/</a>

*  iommu/x86: fixes/improvements for unity range checks (v4 ( [PATCH 4/4] iommu/x86: make unity range checking more strict? ))
  -  Roger Pau Monne
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/20240201170159.66330-1-roger.pau@citrix.com/">https://lore.kernel.org/xen-devel/20240201170159.66330-1-roger.pau@citrix.com/</a>

*  x86/pvh: Support relocating dom0 kernel (v7)
  -  Jason Andryuk
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/20240404212519.16401-1-jason.andryuk@amd.com/">https://patchew.org/Xen/20240404212519.16401-1-jason.andryuk@amd.com/</a>

=== ARM === 

*  Prerequisite patches for R82 upstreaming (v4)
  -  Luca Fancellu
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/20241203094811.427076-1-luca.fancellu@arm.com/">https://patchew.org/Xen/20241203094811.427076-1-luca.fancellu@arm.com/</a>

*  Enable early bootup of AArch64 MPU systems (Part 2) (v3)
  -  Ayan Kumar Halder
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/20241204172243.1229942-1-ayan.kumar.halder@amd.com/">https://patchew.org/Xen/20241204172243.1229942-1-ayan.kumar.halder@amd.com/</a>

*  Enable early bootup of AArch64 MPU systems (v6)
  -  Ayan Kumar Halder
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/20241118121250.4027441-1-ayan.kumar.halder@amd.com/">https://patchew.org/Xen/20241118121250.4027441-1-ayan.kumar.halder@amd.com/</a>

*  Add support for S32CC platforms and LINFlexD UART (v6)
  -  Andrei Cherechesu 
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/20241219112315.2461048-1-andrei.cherechesu@oss.nxp.com/">https://patchew.org/Xen/20241219112315.2461048-1-andrei.cherechesu@oss.nxp.com/</a>

*  Arm cache coloring (v9 -&gt; v11)
  -  Carlo Nonato
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/20241202165921.249585-1-carlo.nonato@minervasys.tech/">https://lore.kernel.org/xen-devel/20241202165921.249585-1-carlo.nonato@minervasys.tech/</a>

*  ffa: Improvements and fixes (v2 -&gt; v3)
  -  Bertrand Marquis
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/cover.1732702210.git.bertrand.marquis@arm.com/">https://lore.kernel.org/xen-devel/cover.1732702210.git.bertrand.marquis@arm.com/</a>

*  iommu/ipmmu-vmsa: Add Renesas R8A779G0 (R-Car V4H) support (v1)
  -  Grygorii Strashko
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/6ab4ad29-404d-4f5c-8582-5d2f492fd549@xen.org/T/#t">https://lore.kernel.org/xen-devel/6ab4ad29-404d-4f5c-8582-5d2f492fd549@xen.org/T/#t</a>

*  xen/arm: dt overlay fixes (v2)
  -  Michal Orzel
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/20241004122220.234817-1-michal.orzel@amd.com/T/#md51a060b93fe72f17637d6d72e3d4e2296cb4078">https://lore.kernel.org/xen-devel/20241004122220.234817-1-michal.orzel@amd.com/T/#md51a060b93fe72f17637d6d72e3d4e2296cb4078</a>

*  xen/arm: Add emulation of Debug Data Transfer Registers (v6)
  -  Ayan Kumar Halder
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/20240307123943.1991755-1-ayan.kumar.halder@amd.com/">https://patchew.org/Xen/20240307123943.1991755-1-ayan.kumar.halder@amd.com/</a>

=== RISC-V ===

*  Unflattening and relocation of host device tree (v1)
  -  Oleksii Kurochko
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/cover.1732709650.git.oleksii.kurochko@gmail.com/">https://patchew.org/Xen/cover.1732709650.git.oleksii.kurochko@gmail.com/</a>

*  initialize bootinfo from dtb (v2)
  -  Oleksii Kurochko
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/cover.1728481578.git.oleksii.kurochko@gmail.com/T/#m543bf84d47f0ea738938a9a442cd144bb34f7316">https://lore.kernel.org/xen-devel/cover.1728481578.git.oleksii.kurochko@gmail.com/T/#m543bf84d47f0ea738938a9a442cd144bb34f7316</a>

*  Register Xen's load address as a boot module (v3)
  -  Oleksii Kurochko
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/cover.1728472163.git.oleksii.kurochko@gmail.com/T/#t">https://lore.kernel.org/xen-devel/cover.1728472163.git.oleksii.kurochko@gmail.com/T/#t</a>

*  device tree mapping (v9)
  -  Oleksii Kurochko
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/cover.1727781468.git.oleksii.kurochko@gmail.com/T/#t">https://lore.kernel.org/xen-devel/cover.1727781468.git.oleksii.kurochko@gmail.com/T/#t</a>

*  Setup memory management (v5)
  -  Oleksii Kurochko
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/cover.1731344883.git.oleksii.kurochko@gmail.com/T/#m9f76f1b685896ea603a2b153e05104c7405a7d28">https://lore.kernel.org/xen-devel/cover.1731344883.git.oleksii.kurochko@gmail.com/T/#m9f76f1b685896ea603a2b153e05104c7405a7d28</a>


Have a good week!

Best regards,
 Oleksii
</pre>
    </blockquote>
  </body>
</html>

--------------oRz0RC70JrIphK7mbrCnVpXT--


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 18:19:26 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 18:19:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866765.1278124 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVEAW-0007ps-I9; Tue, 07 Jan 2025 18:19:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866765.1278124; Tue, 07 Jan 2025 18:19:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVEAW-0007pl-Eq; Tue, 07 Jan 2025 18:19:08 +0000
Received: by outflank-mailman (input) for mailman id 866765;
 Tue, 07 Jan 2025 18:19:06 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=X79W=T7=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tVEAU-0007pf-Fd
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 18:19:06 +0000
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
 [2a00:1450:4864:20::531])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e03fb257-cd23-11ef-99a4-01e77a169b0f;
 Tue, 07 Jan 2025 19:19:04 +0100 (CET)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-5d3f28a4fccso25229502a12.2
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 10:19:04 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0f00ea44sm2401057166b.135.2025.01.07.10.19.03
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 07 Jan 2025 10:19:03 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e03fb257-cd23-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736273944; x=1736878744; 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=gAIbsf9ZtPCezZdhE8Far66QKTwL6uzto59QSVGySmo=;
        b=aPlYbDTz+hgvtCmLldcnuFdwFaGWesVei9byUzipcYsuiZ3OUnxOv3TbDC3ZmVN5TN
         3mONSHvy8dVEh+cvCtIByXKVVBW+tRzt3fG8MZk50KoXdzvQFkpRTg+NekT0zIKEMeIw
         qzB4mZ0An/xOh4hd/kvtxVNrataJX6lJfw2C0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736273944; x=1736878744;
        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=gAIbsf9ZtPCezZdhE8Far66QKTwL6uzto59QSVGySmo=;
        b=tmhHi76m+K0Sv2gU/HYYjCundMP4fNYhHCLGR4fnVVt0AADnu7EmAPfnYWBjE2/b0P
         rrJ9amdv09kogwfmYwIRK69D5yV1sbxu6TRRFARYK1RSb8yHNFDdlJIvJx2Plo/4jNc7
         qwIvYZiVkDhM/oDfib12/or4qc1o4Hayw8yIbqI8+hmOmeRGTPyV0DQZ8efCLqUvp+37
         fKKNGhtZMZDGAEZ6Ri2CxHSkYlr35HaHazH2KhsN8dnFT0SqIe91aorjj6y36ni0LuEl
         C24BRRJ9fc0Zeaf+9310ktmj6vzXcJfkN++1vHMwJxeLKfa3UBMxMWT8hZqMAdctuO24
         v0ag==
X-Forwarded-Encrypted: i=1; AJvYcCWCX+1IhsjHuC5GsfL9wlq5DhZsKJAGDkimPJOG6xmxRYT/NMtjVRQyGREzx4rcmgC7gDooFrfXQj0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwXMad7Rr2i8bfjz/0R9HEd1nvooWCe/d1lTze04KG5h2CYDet8
	AF46rwbcT5N6PVnWf1TM9gVPMZxPYMXeItRt0pXUqTwR0dPTXmAyZ+3r2i4Dbdk=
X-Gm-Gg: ASbGncuxhmUfse/Qca0Zo14naUtrX53iWuAJgXs/Ox3zlsuC/vL5Vc4ql5z7g7TzVDd
	DHnfrzbiXxMNlF1bdC8Y1YVz/WgjBQiWuTZ/BqTrgyhm4M7tW6XR/HhoP+FZIJ6cHh5l8A5iIsx
	3l2Wj6WCB+I6Fy9bwletBnYlP2pe91g48XDJAFCZbEwzFkMmcYcZIlsbUMil0+eOEpi213Kk/xP
	aIM4C97JfYE60wiAcZTiY+XNmnpTIWC3z3nCW8jS8VB4jaWI3NSyGWC3pdqVfRS9gQ=
X-Google-Smtp-Source: AGHT+IEhjoCZ3aghGleOZVMHtffnrIotqUsAD7Qst7gqIuEftDvU4SmQ8W8vbGkePAYDB700v7+4YA==
X-Received: by 2002:a17:907:2d2c:b0:aa6:8a1b:8b78 with SMTP id a640c23a62f3a-aac271318f9mr4703318266b.6.1736273943711;
        Tue, 07 Jan 2025 10:19:03 -0800 (PST)
Date: Tue, 7 Jan 2025 19:19:02 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Jiqian Chen <Jiqian.Chen@amd.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Huang Rui <ray.huang@amd.com>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v4] vpci: Add resizable bar support
Message-ID: <Z31wFjWadOkzTDK3@macbook.local>
References: <20241219052143.3161332-1-Jiqian.Chen@amd.com>
 <d904c816-da83-418a-9bff-9988660af546@suse.com>
 <Z308fGa1daaM62Rf@macbook.local>
 <fb1b00fe-5740-4c0e-81d9-ec9fd9a4a1c3@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <fb1b00fe-5740-4c0e-81d9-ec9fd9a4a1c3@suse.com>

On Tue, Jan 07, 2025 at 04:58:07PM +0100, Jan Beulich wrote:
> On 07.01.2025 15:38, Roger Pau Monné wrote:
> > On Tue, Jan 07, 2025 at 11:06:33AM +0100, Jan Beulich wrote:
> >> On 19.12.2024 06:21, Jiqian Chen wrote:
> >>> --- /dev/null
> >>> +++ b/xen/drivers/vpci/rebar.c
> >>> @@ -0,0 +1,131 @@
> >>> +/* SPDX-License-Identifier: GPL-2.0-only */
> >>> +/*
> >>> + * Copyright (C) 2024 Advanced Micro Devices, Inc. All Rights Reserved.
> >>> + *
> >>> + * Author: Jiqian Chen <Jiqian.Chen@amd.com>
> >>> + */
> >>> +
> >>> +#include <xen/sched.h>
> >>> +#include <xen/vpci.h>
> >>> +
> >>> +static void cf_check rebar_ctrl_write(const struct pci_dev *pdev,
> >>> +                                      unsigned int reg,
> >>> +                                      uint32_t val,
> >>> +                                      void *data)
> >>> +{
> >>> +    struct vpci_bar *bar = data;
> >>> +    uint64_t size = PCI_REBAR_CTRL_SIZE(val);
> >>> +
> >>> +    if ( bar->enabled )
> >>> +    {
> >>> +        /*
> >>> +         * Refuse to resize a BAR while memory decoding is enabled, as
> >>> +         * otherwise the size of the mapped region in the p2m would become
> >>> +         * stale with the newly set BAR size, and the position of the BAR
> >>> +         * would be reset to undefined.  Note the PCIe specification also
> >>> +         * forbids resizing a BAR with memory decoding enabled.
> >>> +         */
> >>> +        if ( size != bar->size )
> >>> +            gprintk(XENLOG_ERR,
> >>> +                    "%pp: refuse to resize BAR with memory decoding enabled\n",
> >>> +                    &pdev->sbdf);
> >>> +        return;
> >>> +    }
> >>> +
> >>> +    if ( !((size >> PCI_REBAR_SIZE_BIAS) & bar->resizable_sizes) )
> >>> +        gprintk(XENLOG_WARNING,
> >>> +                "%pp: new size %#lx is not supported by hardware\n",
> >>> +                &pdev->sbdf, size);
> >>> +
> >>> +    bar->size = size;
> >>
> >> Shouldn't at least this be in an "else" to the if() above?
> > 
> > I think this was already raised in a previous version - would be good
> > to know how real hardware behaves when an invalid size is set.  Is the
> > BAR register still reset?
> 
> I'm pretty sure what happens is undefined. I'd expect though that the
> BAR size then doesn't change. Which would require the above assignment
> to not be unconditional.

Might be better to just re-size the BAR, like you suggested to fetch
the BAR position from the register, instead of assuming 0.

> >>> +        if ( index >= PCI_HEADER_NORMAL_NR_BARS )
> >>> +        {
> >>> +            /*
> >>> +             * TODO: for failed pathes, need to hide ReBar capability
> >>> +             * from hardware domain instead of returning an error.
> >>> +             */
> >>> +            printk(XENLOG_ERR "%pd %pp: too big BAR number %u in REBAR_CTRL\n",
> >>> +                   pdev->domain, &pdev->sbdf, index);
> >>> +            return -EINVAL;
> >>
> >> With the TODO unaddressed, is it actually appropriate to return an error
> >> here? Shouldn't we continue in a best effort manner? (Question also to
> >> Roger as the maintainer.)
> > 
> > It would indeed be better to shallow the error and return 0, however
> > the handlers added in this loop would need removing if no error is
> > returned.
> 
> Would they? For those BARs where things worked fine I would think they
> could be left in place.

Hm, it's kind of partial support, but yes, that could likely be fine.
Then the return here should be a continue instead.

> >>> +        }
> >>> +
> >>> +        bar = &pdev->vpci->header.bars[index];
> >>> +        if ( bar->type != VPCI_BAR_MEM64_LO && bar->type != VPCI_BAR_MEM32 )
> >>> +        {
> >>> +            printk(XENLOG_ERR "%pd %pp: BAR%u is not in memory space\n",
> >>> +                   pdev->domain, &pdev->sbdf, index);
> >>> +            return -EINVAL;
> >>
> >> Same question here then.
> >>
> >>> +        }
> >>> +
> >>> +        rc = vpci_add_register(pdev->vpci, vpci_hw_read32, vpci_hw_write32,
> >>> +                               rebar_offset + PCI_REBAR_CAP(i), 4, NULL);
> >>> +        if ( rc )
> >>> +        {
> >>> +            printk(XENLOG_ERR "%pd %pp: fail to add reg of REBAR_CAP rc=%d\n",
> >>> +                   pdev->domain, &pdev->sbdf, rc);
> >>> +            return rc;
> >>> +        }
> >>> +
> >>> +        rc = vpci_add_register(pdev->vpci, vpci_hw_read32, rebar_ctrl_write,
> >>> +                               rebar_offset + PCI_REBAR_CTRL(i), 4, bar);
> >>> +        if ( rc )
> >>> +        {
> >>> +            printk(XENLOG_ERR "%pd %pp: fail to add reg of REBAR_CTRL rc=%d\n",
> >>> +                   pdev->domain, &pdev->sbdf, rc);
> >>> +            return rc;
> >>> +        }
> >>> +
> >>> +        bar->resizable_sizes |=
> >>> +            (pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CAP(i)) >>
> >>> +             PCI_REBAR_CAP_SHIFT);
> >>
> >> Imo this would better use = in place of |= and (see also below) would also
> >> better use MASK_EXTR() just like ...
> >>
> >>> +        bar->resizable_sizes |=
> >>> +            ((uint64_t)MASK_EXTR(ctrl, PCI_REBAR_CTRL_SIZES) <<
> >>> +             (32 - PCI_REBAR_CAP_SHIFT));
> >>
> >> ... this one does.
> >>
> >> Further I think you want to truncate the value for 32-bit BARs, such that
> >> rebar_ctrl_write() would properly reject attempts to set sizes of 4G and
> >> above for them.
> > 
> > For the hardware domain at least we shouldn't add such restriction -
> > Xen in general allows dom0 to do things it would otherwise consider
> > invalid, in case it has to deal with hardware quirks.
> > 
> > Rather than reject Xen should just print a warning that the sizes
> > supported by the device are likely invalid.
> 
> And do what when memory decode is re-enabled on the device? What size a
> P2M update should it do then?

You did suggest to re-read the BARs positions after a ctrl write, we
might as well read the BAR size and use that to be on the safe side.

> >>> --- a/xen/drivers/vpci/vpci.c
> >>> +++ b/xen/drivers/vpci/vpci.c
> >>> @@ -232,6 +232,12 @@ void cf_check vpci_hw_write16(
> >>>      pci_conf_write16(pdev->sbdf, reg, val);
> >>>  }
> >>>  
> >>> +void cf_check vpci_hw_write32(
> >>> +    const struct pci_dev *pdev, unsigned int reg, uint32_t val, void *data)
> >>> +{
> >>> +    pci_conf_write32(pdev->sbdf, reg, val);
> >>> +}
> >>
> >> This function is being added just to handle writing of a r/o register.
> >> Can't you better re-use vpci_ignored_write()?
> > 
> > But vpci_ignored_write() ignores the write, OTOH here the write is
> > propagated to the hardware.
> 
> Right, just for the hardware to drop it. I wouldn't have commented if
> the function needed to do things like this already existed. Adding yet
> another cf_check function just for this is what made me give the remark.

According to the spec yes, they will be ignored.  Yet for the hardware
domain we try to avoid changing behavior from native as much as
possible, hence propagating the write seems more appropriate.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 19:08:10 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 19:08:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866774.1278133 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVEvp-000635-Sb; Tue, 07 Jan 2025 19:08:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866774.1278133; Tue, 07 Jan 2025 19:08:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVEvp-00062y-Pr; Tue, 07 Jan 2025 19:08:01 +0000
Received: by outflank-mailman (input) for mailman id 866774;
 Tue, 07 Jan 2025 19:07:59 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=W3tJ=T7=minervasys.tech=andrea.bastoni@srs-se1.protection.inumbo.net>)
 id 1tVEvn-00062s-Go
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 19:07:59 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b480b8fc-cd2a-11ef-a0df-8be0dac302b0;
 Tue, 07 Jan 2025 20:07:58 +0100 (CET)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-aaeec07b705so1844634966b.2
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 11:07:58 -0800 (PST)
Received: from ?IPV6:2001:4ca0:0:f293:dc1b:7733:c3ba:a819?
 ([2001:4ca0:0:f293:dc1b:7733:c3ba:a819])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0f06f942sm2417988166b.200.2025.01.07.11.07.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 11:07:56 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b480b8fc-cd2a-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1736276877; x=1736881677; 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=bkoF/hEVvzmuCx8cR5sDAI5/4lVkCzfNCbXRNqr7pQM=;
        b=XpWy+1d7/MCIDteqy6AiEgDXvU9PWrXlf+txtW0GOdFWFL744jisZgyp064mtLR05Y
         tnpJ7QPVhr2PclGUe9MRtjExjp0PEHmOpTWMqT+aA07UwDc8QqyN+svzM9Ebe2RXyLPE
         v1D3B2+z7OS6yUU//P5ZYa1S/dVb7vmeuLo3meJxn5tkP/8ccET5b+3trm6sh/tumKfR
         X7vDYP2ict7V+treyhZtE3VXa4WYnKXiu2recLi0t47jxiTPeB3COMr/ri8H0nqq75/6
         DmIUg6e+Kw5LSXomGFOnjB/Ugfz3PohoWVDspgfKw86cPNe9tNXxEjcDCKWr2GiQj9YW
         11OA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736276877; x=1736881677;
        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=bkoF/hEVvzmuCx8cR5sDAI5/4lVkCzfNCbXRNqr7pQM=;
        b=vNQqY3rRn0JPUBfxCW3vhCwwWu8oosobOQCg1BF7Ft1voeQauH2cfERb9Du8etzBlX
         Yo3Zs9RVEMdnKxAbaBAyNFhlkt0lelBI5+2VKfl+bZ2RwWeCFrvvqLD8KVKz+3F25jBV
         eYkmlwl9206DqSABOHYa5/xM3nhlEVxquheC2n+m8OVBfNJn857WzaVC2+cpwTRGUXBz
         WzmRfIIMFDXcpJVns9kWgWWBl99Eui/1xXj0MXBlYKoIhJ3vQYJQEyR+cz0ahQDDClo0
         pl+ZQpFp1HXeaEIw1VmpiUUqqSPUrQwjTJ8b+9x+RLym9Xw8ZWCIsgLmNIeEkGeP3k93
         UN8w==
X-Gm-Message-State: AOJu0YwMCVB9n87wKTlwMi08yL5GuaCRuCwrT4ucAozEgx62hapAeFrq
	XwfvkbGIN/3ATLJ7or4cJDjLXNYv35ehniXJDjuSetYmaNAAZVRD6g4O4+1crao=
X-Gm-Gg: ASbGnctdlxDkqbSnkXPrwr5EGwZLUdlLai7T1ITni6Ok6L549ajHr1he41ge21UKn+u
	dkqeN5Fo59RBDS3w3i71OwRj1+H2qZsYyNPxTrKwPBtJu4fTOt8x8T9F/scPI8LdaGQk+owO+9M
	bBR5GEIjkVTjt6+4t15EXf5amaPIzElVuLaE2wIFz2ZHxPHtYyyICatpw2Uw6GHitdxIRQOXstX
	8HqCnOY/ODiwtnVBmDOW7lH+/e/qy3RuffbiTpavAo0hAE1j/mTwMau1csW/Lxu/poKG6yONyF+
	TYRwv9Hh40+a5w0dqZ4dHkjKkUFEUbvPSNhPXA==
X-Google-Smtp-Source: AGHT+IGxh1pDxjCQCR6bE0+bCWBxBQBcDW2bDkXvRJJRJf/e2Jnlo+GAfEhEz9GE/UVg7DIdr1KuaA==
X-Received: by 2002:a17:906:6a28:b0:aa5:391e:cadf with SMTP id a640c23a62f3a-aac334f637fmr5316228566b.42.1736276876642;
        Tue, 07 Jan 2025 11:07:56 -0800 (PST)
Message-ID: <26a19781-d36c-4f88-8b45-27385d7606a3@minervasys.tech>
Date: Tue, 7 Jan 2025 20:07:55 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [for-4.20] Re: [PATCH v12 12/12] xen/arm: add cache coloring
 support for Xen image
Content-Language: en-US
From: Andrea Bastoni <andrea.bastoni@minervasys.tech>
To: Jan Beulich <jbeulich@suse.com>, Michal Orzel <michal.orzel@amd.com>
Cc: xen-devel@lists.xenproject.org, marco.solieri@minervasys.tech,
 Stefano Stabellini <sstabellini@kernel.org>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Oleksii <oleksii.kurochko@gmail.com>, Julien Grall <julien@xen.org>,
 Carlo Nonato <carlo.nonato@minervasys.tech>
References: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
 <20241213162815.9196-13-carlo.nonato@minervasys.tech>
 <dbbc649f-b705-46b5-a071-760d688aa2cd@amd.com>
 <CAG+AhRWrXAYfKXXKfp6949vNMdGDy9qWOY11SKAigJuC8oUvDw@mail.gmail.com>
 <df0f831f-378f-4fa3-ae4f-b065f2ea566d@suse.com>
 <0062e0cf-0830-4d16-942d-348e6d33a2c4@xen.org>
 <5c153764-4a1d-4233-a9d2-fa5ec0aff6ac@amd.com>
 <6a0a096b-47c2-4568-be9f-9f230bc6df23@suse.com>
 <0231325c-13f2-4b0b-a928-4ba249e4c560@minervasys.tech>
Autocrypt: addr=andrea.bastoni@minervasys.tech; keydata=
 xsFNBF5Nh4sBEAC7UM3QJtjrFO3pjcMCCh04JFyCCDzLFMIqMTB1UWCLamZ9dUwIau7ScgWv
 49aqbM++edVvEBmG8JHDC83DFWymvFVXBgqgcR7tHHBbg33XJKFMHvuW/kFm/67XPTFcec4L
 JsH5MWms9TLJbgCnaWQQMH3kztTRQaf5QcULIoHnTySKlt3WzzzHosaMO+/GNYX7vzfc4ypJ
 mD5SQWYDhfRefASkyxdrN6/QkPwS2vGTyVK58o2U9I27KPYvs+77JrjrNBfpnebapaYVA55C
 7BvTnno5Kr6QHwA6LcnIZqefz7KxQ1n+1C5QQbmhi9S68aloGCeUo9R06UMJG79TXC2Mc68t
 AtSCN/HpgcvN1CSL45f/4WCDPG572ebo5M6MPcTb4ptV1SC/i+4U/3cG0LNSUap+sGRCf0Iy
 C5xy0KOtgoq8jesdleSy8j/3DNIMGekSYbQYMO39DfZds2XFh9lVDjG7tQcChwW+lQDPo113
 ENBRftDyqJthrvmJXGyrOmn0su56qh2Zqvi5pSHWsH88vAZUJsOU+9lpohmcb3o/cQ18UXNK
 H/9wjo2zKHFdSylQFERHIzj6WlBp01wkTcCqtUGpxsjJHmVSyakWs3TrGXooKR9SPMxqVrD/
 oCCEo9IUD9jd+TxLsp/4TzUp4ScTO/43uPgdkMekU5mRs6B6WwARAQABzS9BbmRyZWEgQmFz
 dG9uaSA8YW5kcmVhLmJhc3RvbmlAbWluZXJ2YXN5cy50ZWNoPsLBlAQTAQgAPgIbAwULCQgH
 AgYVCgkICwIEFgIDAQIeAQIXgBYhBImpnm1L3x9XIoXhD3VSShFTR9xSBQJitcUIBQkKC9f2
 AAoJEHVSShFTR9xSmSoP/0W/VboJmWmLh89eIl1QRoiL1nGcti1fTN835Q2TPiSdg+nFVqy1
 8oLrJaHNe5THVaSr4S2du56SASYSG6f+Y5aiQccbalUJIV7KwXr741kovTnUPUKjPoi61Bx4
 DUzis0Xo0NmMnz7M1YudbQZmjoakE/wZJRB+b79+kJwrfZFcNg4DSuSvNOUeI17uapLKRQ1a
 ukuRgXwUpMOudKngJ8HB+16aHIQX+yfpcsanNr1nGwHSLhEPEM20DVzKiCp2cKjv9Y7zZ+6y
 akbJHdbRuJliyZmXaSVO8sQ1tO/W6Y/4zAjejw2c1qDKISeIlGi+o6UEVYZlKCThzrV9vYok
 AcJF4DlYcAuBMVYCTomovXb/9/Y48pRGlfDGrmnt+FvGVA0jYrG02oufItY2JAGzFcX1KMTG
 AGf1S7pOj3AvBTGJjW8d8+sXuedH51HNixJtMnzcmi+qJfPJujBW3BEZ1p0ZoDyTH/WCZF+7
 B5lFvTi0DRKY6AI0TSzBdjtaOMt64fn6KXtLtaTZKDKkFUBwAShJyYcWQSp/7EO+ZJW7dWIw
 1vM5AcnugonJby+q+JGgBVC2rjscu5Okl3lnviF9WLAzmRH/pDkAa3jifiUm8eS+dP+4cN6g
 WXL9vTF6FtFyI8sgzRlY/IX8mao5bV/P1HCwNvkBhO8C3XMaul4FwQsjzsFNBF5Nh4sBEADN
 J99l+vOp8LB8jDjWOhINlpgp+EcrmWOuler5QnoJUywc2zkLelQIwVGP2lFliMdLHM6DbMEX
 ySIzHbhw7oPRP0QRPK/6I4bXYkSQCrLyqYd0CYSbkar8YV6Xa6nGxRmP1bBv1lPFHN66D0yE
 /z1ScGMXyX+ZOIvH0ekIkqFvi7Ec/7a/ntfU43o2t05dmbnEKoECZgeS8SraojfKnQRpz7+P
 N0q45O5fMETZpIiQh1/mB12HOcklDNELcKohqVfevbknJw04Yjbcv79aGpBRqoVWWBS4TxcD
 CRPQZ+H0tMUVEL/MqO7tNLA1VuGpOccyFtZnC/+J/twa7iKpPIxS9Ec/LDYTddebWH+8gOmr
 /PkBerBXghlZpxmQUlJeQ8kyecOOc4C7ec3aUGj+x28j0+zlXFLUbjiKIEM5VowIMgDDRwA/
 MDr9IJhFzHaY2VCfBnX8sgJSn62IxqREq4X3KkR/Jtxt+HYXQYLl0yva2MBplkRcwQO799o6
 woAMW0uyct4+BUcKo1sBFP2x2n4NFiPEjeoH3y9baruD9iiMQsmbJ3IKqtT13crCa+bcY3ZS
 Oz+CymgzNdH+RabJMC3mGfKIhUQGwEHz+wyMnv16nqO49bmoCk3q5Oneo4I3XwI3QbIJr0rd
 QkX6oh6R0taC3naal1ZYGxs0vZK567bT5wARAQABwsF2BBgBCAAgFiEEiamebUvfH1ciheEP
 dVJKEVNH3FIFAl5Nh4sCGwwACgkQdVJKEVNH3FLafxAAl7pW0v6Jju19I6wtB+XNzzi5Wota
 3AyWzCxO/hUHNGRV/ZufhMkNFCMNzAxbdmO56eCk9ZYf/JMLu8H1GwhV1NgQ7HL4FNXXxLZ0
 ixZDik86iiSjVLtEjLuwkS4Fj9wjqevycL/t16kJduFNyxT0/XiB5UPh5NClOMonHSC+V2If
 Kf6l2Ic34CrA3ovkfVvBXJTzia0VgyQCikeazgPRELH8bq2WTBWfjR3/l86Y0twiYyXqBNQ8
 Q2Z83mu+yt38gTanz4YuDYz7YFjvL6IU2MZ5+ByothK6Cfx4W595q81dsGcJOlcd6j3QE+ps
 b3SHuToWZCHZRHyKrgGDqCL5RbsK3wXgDmc48SfN+5TxenT8A1lkoOHFcQ0SV8xleiwURXHc
 Ao+SzyDcTfltBNjzQmntQjAfq1Lq5Ux9nfpPMgnVHu5ANWeLtwLJyh+4aPVE5hGjeCa+Ab5U
 MyocCYdTuAmDHB9RQdf9c+qlVYuZCg7yYlWsvId5DGZnab2MzvExayaFCJVEoCccpfrqFFiF
 kJ19BogE4A6VTU0ShoHYJhLg7PuEZS1oWzULZnM8sNNI72MecvfZn5Oi0ZEJhFh+HETlJnIT
 7gh7CGFBxPacT8vHxmeMPod7qrvYgKW+QKhU+tAI8gkI6hHXLBg/dxn7wAwTjlX1bo+jRJyp
 Id5SuAU=
In-Reply-To: <0231325c-13f2-4b0b-a928-4ba249e4c560@minervasys.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 07/01/2025 18:13, Andrea Bastoni wrote:
> On 07/01/2025 18:01, Jan Beulich wrote:
>> On 07.01.2025 17:51, Michal Orzel wrote:
>>>
>>>
>>> On 07/01/2025 17:42, Julien Grall wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> On 16/12/2024 14:36, Jan Beulich wrote:
>>>>> On 16.12.2024 15:28, Carlo Nonato wrote:
>>>>>> On Mon, Dec 16, 2024 at 2:56 PM Michal Orzel <michal.orzel@amd.com> wrote:
>>>>>>> On 13/12/2024 17:28, Carlo Nonato wrote:
>>>>>>>> --- a/xen/arch/arm/arm64/mmu/mm.c
>>>>>>>> +++ b/xen/arch/arm/arm64/mmu/mm.c
>>>>>>>> @@ -1,6 +1,7 @@
>>>>>>>>   /* SPDX-License-Identifier: GPL-2.0-only */
>>>>>>>>
>>>>>>>>   #include <xen/init.h>
>>>>>>>> +#include <xen/llc-coloring.h>
>>>>>>>>   #include <xen/mm.h>
>>>>>>>>   #include <xen/pfn.h>
>>>>>>>>
>>>>>>>> @@ -138,8 +139,36 @@ void update_boot_mapping(bool enable)
>>>>>>>>   }
>>>>>>>>
>>>>>>>>   extern void switch_ttbr_id(uint64_t ttbr);
>>>>>>>> +extern void relocate_xen(uint64_t ttbr, void *src, void *dst, size_t len);
>>>>>>>>
>>>>>>>>   typedef void (switch_ttbr_fn)(uint64_t ttbr);
>>>>>>>> +typedef void (relocate_xen_fn)(uint64_t ttbr, void *src, void *dst, size_t len);
>>>>>>>> +
>>>>>>>> +void __init relocate_and_switch_ttbr(uint64_t ttbr) {
>>>>>>> CODING_STYLE: { needs to be on its own line
>>>>>>>
>>>>>>> Also, this function is only executed in case of LLC coloring, so shouldn't it
>>>>>>> be #ifdef protected.
>>>>>>
>>>>>> Here and in other places (patch #8) I'm relying on DCE to remove functions
>>>>>> that are not called. This was a suggestion from Jan in that patch. Can we
>>>>>> adopt the same here?
>>>>>
>>>>> Yet how would the compiler spot that the function is unused? That would only
>>>>> work with LTO / WPO. DCE (as I did suggest elsewhere) requires the functions
>>>>> in question to be static (allowing the compiler to see enough of the whole
>>>>> picture).
>>>>
>>>> Sorry for the late answer. I was away with limited e-mail access. While
>>>> looking what was committing recently, I noticed that a dummy function
>>>> was introduced:
>>>>
>>>> void __init relocate_and_switch_ttbr(uint64_t ttbr) {}
>>>>
>>>> If a function is not supposed to be called, then it should contain a
>>>> BUG_ON() to catch any misusage. Otherwise, this is a recipe for
>>>> disaster. In this case, it would not be trivial to notice the TTBR was
>>>> not switched...
>>>>
>>>> That said I would have actually considered to remove the empty stub. I
>>>> am a bit surprised that DCE wouldn't work in this case because the call
>>>> is protected with "if ( llc_coloring_enabled )". When cache coloring is
>>>> not enabled, this would turn to an "if ( false )" and therefore all the
>>>> code should be removed. What did I miss?
>>>>
>>>> Note that this is what we already rely on for arm32 because there is no
>>>> stub... So if this is problem then we definitely need to fix it on arm32
>>>> as well...
>>>>
>>>> IOW, we either introduce a stub (including the BUG_ON) for both arm32
>>>> and arm64 in the header or we remove the stub completely.
>>>>
>>>> Marco, Michal, can you have a look? Ideally, this should be fixed for 4.20.
>>> I did a test with GCC 13.2 and I can compile it fine with stub removed. That said,
>>> I'm not a compiler expert and I'm not sure if this behavior stays the same with different
>>> compiler options/optimizations. So it's more like a question to Jan. I'm happy either way.
>>
>> We use the same (if(...) func();) in various places, relying on said DCEing
>> of the call when the condition is compile-time-false. I see no reason why
>> it couldn't be used here as well.
> 
> IIRC the point was that his function is extern and DCE as used in other places doesn't necessarily work.

But in this case I can confirm what Michal reported:

> diff --git a/xen/arch/arm/arm64/mmu/mm.c b/xen/arch/arm/arm64/mmu/mm.c
> index 26361c4fe4..c1efa1348a 100644
> --- a/xen/arch/arm/arm64/mmu/mm.c
> +++ b/xen/arch/arm/arm64/mmu/mm.c
> @@ -171,8 +171,6 @@ void __init relocate_and_switch_ttbr(uint64_t ttbr)
>       */
>      update_identity_mapping(false);
>  }
> -#else
> -void __init relocate_and_switch_ttbr(uint64_t ttbr) {}
>  #endif
> 
>  void __init switch_ttbr(uint64_t ttbr)

When compiled (aarch64-linux-gnu-gcc (Debian 10.2.1-6)) without LLC_COLORING: compiles, does not result in undefined symbols, and relocate_and_switch_ttbr() is not present in the object 

Thanks,
Andrea


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 20:26:30 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 20:26:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866788.1278143 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVG9R-00077k-Fi; Tue, 07 Jan 2025 20:26:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866788.1278143; Tue, 07 Jan 2025 20:26:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVG9R-00077d-D8; Tue, 07 Jan 2025 20:26:09 +0000
Received: by outflank-mailman (input) for mailman id 866788;
 Tue, 07 Jan 2025 20:26:08 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=u5H8=T7=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tVG9Q-00077S-Bj
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 20:26:08 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9b8f9e1d-cd35-11ef-99a4-01e77a169b0f;
 Tue, 07 Jan 2025 21:26:00 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 1E0B95C561A;
 Tue,  7 Jan 2025 20:25:18 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0935BC4CED6;
 Tue,  7 Jan 2025 20:25:57 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9b8f9e1d-cd35-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1736281558;
	bh=/sWlrrM1T9AyujFgsvL5X+RXwuVpm4WJdUNUjeXG6CI=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=ig8vYS9iMgeF6d2t9vGRtG/aTrW0/kt+gM2cSgz6B8RSbt5UH2loavzM5K7gLxZOm
	 0/zFOHrzS6/eEyJ9TFWRNrWUsVYkGUarSZ/ZDTfa9wQ0jKxiNCQUkypg4oqz4FhYac
	 KX6Rc9jq08D6EwYobOa8eRVmBaeIgxqNBB6D8ZK53cvvQ/mwsJXASrl5R9UPxv2IgE
	 kmSu0z361LT7FPa+4Fwp320/QbSmlChN9QtjKHLk+lDk7paOhXESANCOyyEFmRsZ/y
	 6/toXVhBeLzCev5cfor+rnmmVxY62X7efVRuJ87Lnhf2+6UVZ0cBzUNo0/7/0bm09C
	 1WnsBpVTPgHgA==
Date: Tue, 7 Jan 2025 12:25:56 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Bertrand Marquis <bertrand.marquis@arm.com>
cc: xen-devel@lists.xenproject.org, 
    Oleksii Kurochko <oleksii.kurochko@gmail.com>, 
    Community Manager <community.manager@xenproject.org>, 
    Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, 
    Michal Orzel <michal.orzel@amd.com>
Subject: Re: [PATCH] xen/arm: ffa: add changelog entries for FF-A
 improvements
In-Reply-To: <059ad52a5d2aa6fb7fabe44fe2a99d8b73c1b907.1736240334.git.bertrand.marquis@arm.com>
Message-ID: <alpine.DEB.2.22.394.2501071225480.133435@ubuntu-linux-20-04-desktop>
References: <059ad52a5d2aa6fb7fabe44fe2a99d8b73c1b907.1736240334.git.bertrand.marquis@arm.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Tue, 7 Jan 2025, Bertrand Marquis wrote:
> Add a CHANGELOG entry for release 4.20 to mention the various
> improvements and fixes that have been done in the FF-A support since
> 4.19 release.
> 
> Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>

Acked-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
>  CHANGELOG.md | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/CHANGELOG.md b/CHANGELOG.md
> index 8507e6556a56..d58a2ffd130b 100644
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -22,6 +22,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>     - Basic handling for SCMI requests over SMC using Shared Memory, by allowing
>       forwarding the calls to EL3 FW if coming from hwdom.
>     - Support for LLC (Last Level Cache) coloring.
> +   - Several FF-A support improvements: add indirect messages support, transmit
> +     RXTX buffer to the SPMC, fix version negotication and partition
> +     information retrieval.
>   - On x86:
>     - xl suspend/resume subcommands.
>  
> -- 
> 2.47.1
> 


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 23:31:06 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 23:31:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866809.1278164 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVJ2B-0003qk-3j; Tue, 07 Jan 2025 23:30:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866809.1278164; Tue, 07 Jan 2025 23:30:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVJ2A-0003qd-W0; Tue, 07 Jan 2025 23:30:50 +0000
Received: by outflank-mailman (input) for mailman id 866809;
 Tue, 07 Jan 2025 23:30:49 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=u5H8=T7=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tVJ29-0003qV-81
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 23:30:49 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org
 [2604:1380:45d1:ec00::3])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6b6a5a8b-cd4f-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 00:30:47 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id D446CA41EFC;
 Tue,  7 Jan 2025 23:28:56 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5ED0DC4CEDF;
 Tue,  7 Jan 2025 23:30:44 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 6b6a5a8b-cd4f-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1736292645;
	bh=Eq/ZJH/Wx1Vd9ZPPYTJ0z6ozQ+faeWET3TOExZ9toYM=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=jRzff5MM7VdEfOmkNT/MIILo91P3xrkOdvUMgCrZZmLDi35+kQyiJy/nf/53yEXQH
	 AzxO6xv+j9UqSpQ5dfmFAnt8Zz0J8UoWPvrHA9G935sVzrxYQzW+uZz2Nti9zU0Wkm
	 FHGsm8PgeULeu9NwEfa0rM8ssrLXhD5irgY1hIClanC2WqOCHovqTv0KTQi9YF9xkm
	 i7VWJBzkoQuSldmVVrt6sbdTx7EeEgeafHXlCnlhR9FWDIk82/EvUljt6LPRuD2rr1
	 Dl4jyv+5UIGtX7ML3ylEaRtjSZ3xeCgjOgakZotu5sykjCcgz70EZt91SA3VdI1fQ3
	 9TDfBXS9lVStw==
Date: Tue, 7 Jan 2025 15:30:43 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich <jbeulich@suse.com>
cc: Stefano Stabellini <sstabellini@kernel.org>, jgross@suse.com, 
    xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] xen: update pvcalls_front_accept prototype
In-Reply-To: <0f8fc348-14f5-40ac-912a-1785caedb675@suse.com>
Message-ID: <alpine.DEB.2.22.394.2501071530180.133435@ubuntu-linux-20-04-desktop>
References: <alpine.DEB.2.22.394.2501061335161.133435@ubuntu-linux-20-04-desktop> <0f8fc348-14f5-40ac-912a-1785caedb675@suse.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Tue, 7 Jan 2025, Jan Beulich wrote:
> On 06.01.2025 22:36, Stefano Stabellini wrote:
> > xen: update pvcalls_front_accept prototype
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
> > ---
> > 
> > Changes in v2:
> > - also update pvcalls-front.c
> 
> The patch still gives the impression of being incomplete: There's no
> caller of the function that you update. However, there's no such caller
> in the first place. Why don't you just delete the function then?

It is meant to be called from an out-of-tree module, which has not been
upstreamed yet


> > diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
> > index b72ee9379d77..cab480059731 100644
> > --- a/drivers/xen/pvcalls-front.c
> > +++ b/drivers/xen/pvcalls-front.c
> > @@ -769,7 +769,8 @@ int pvcalls_front_listen(struct socket *sock, int backlog)
> >  	return ret;
> >  }
> >  
> > -int pvcalls_front_accept(struct socket *sock, struct socket *newsock, int flags)
> > +int pvcalls_front_accept(struct socket *sock, struct socket *newsock,
> > +			 struct proto_accept_arg *arg)
> >  {
> >  	struct pvcalls_bedata *bedata;
> >  	struct sock_mapping *map;
> > @@ -788,7 +789,7 @@ int pvcalls_front_accept(struct socket *sock, struct socket *newsock, int flags)
> >  		return -EINVAL;
> >  	}
> >  
> > -	nonblock = flags & SOCK_NONBLOCK;
> > +	nonblock = arg->flags & SOCK_NONBLOCK;
> >  	/*
> >  	 * Backend only supports 1 inflight accept request, will return
> >  	 * errors for the others
> > diff --git a/drivers/xen/pvcalls-front.h b/drivers/xen/pvcalls-front.h
> > index f694ad77379f..881ef14660bc 100644
> > --- a/drivers/xen/pvcalls-front.h
> > +++ b/drivers/xen/pvcalls-front.h
> > @@ -12,7 +12,7 @@ int pvcalls_front_bind(struct socket *sock,
> >  int pvcalls_front_listen(struct socket *sock, int backlog);
> >  int pvcalls_front_accept(struct socket *sock,
> >  			 struct socket *newsock,
> > -			 int flags);
> > +			 struct proto_accept_arg *arg);
> >  int pvcalls_front_sendmsg(struct socket *sock,
> >  			  struct msghdr *msg,
> >  			  size_t len);
> > 
> 


From xen-devel-bounces@lists.xenproject.org Tue Jan 07 23:41:01 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Jan 2025 23:41:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866818.1278174 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVJBy-0005Yr-5T; Tue, 07 Jan 2025 23:40:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866818.1278174; Tue, 07 Jan 2025 23:40:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVJBy-0005Yk-11; Tue, 07 Jan 2025 23:40:58 +0000
Received: by outflank-mailman (input) for mailman id 866818;
 Tue, 07 Jan 2025 23:40: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
 <SRS0=u5H8=T7=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tVJBw-0005Ye-Mf
 for xen-devel@lists.xenproject.org; Tue, 07 Jan 2025 23:40:56 +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 d5d7e695-cd50-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 00:40:55 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id AD42B5C5642;
 Tue,  7 Jan 2025 23:40:10 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 03DADC4CED6;
 Tue,  7 Jan 2025 23:40:49 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: d5d7e695-cd50-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1736293251;
	bh=LbGXxHUlQV4fABGUwIoXOaBJigx3BRZt6winh1i3e1k=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=LrHnNdHCy6HSQqbd1xYOGckXA74MhiGNRUj7Y3olnAADdWlG2gbJ8QBg2D20Er5JM
	 XQOgWbbzXT8lhjENl0EkBWby112MwwP9WPVlpR7yvhcGnwF3DaT4ZRrUsdLSm/rKL5
	 SLl09fZC2xF4+K0nfW1rRBK+zCzcNjJl80F970b5hlKvqpzg5Q5Ntxb/oVBRcv1oqk
	 Kr+WlqXa82gMOOyP73+6AzDLEenhAGIw5eYhEij9bcGXZEfu5UpEF9Iz0cEKCjJZqn
	 kxSXB1fXActDq+NiEdSm7Y/dscM+Raox01co58f0B42nYgM3UjM1JLhHFdZvD1hGD6
	 EHeN7aW11KKlw==
Date: Tue, 7 Jan 2025 15:40:48 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich <jbeulich@suse.com>
cc: Stefano Stabellini <sstabellini@kernel.org>, 
    Denis Mukhin <dmkhn@proton.me>, dmukhin@ford.com, 
    xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, 
    Julien Grall <julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>, 
    Michal Orzel <michal.orzel@amd.com>, 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Subject: Re: [PATCH v2 20/35] xen/console: introduce console_owner_domid()
In-Reply-To: <c39c0c6f-2fab-46e8-9563-c91fe890e87f@suse.com>
Message-ID: <alpine.DEB.2.22.394.2501071533060.133435@ubuntu-linux-20-04-desktop>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-20-e9aa923127eb@ford.com> <d55bf6a6-5861-4b72-88b5-2aaa28ae0290@suse.com> <VJ9ivpkbNlqfKhBlb5dL6OuoPAXK9wqD4mhgO9Qt4f0qgmuow22qFv1C7L8DlbKYo7ytdKWeV1bLaYJvTAc2Yt7sEd06XREerWER5RPx4No=@proton.me>
 <8a5a5a0f-72b0-4336-b0d2-142254319242@suse.com> <alpine.DEB.2.22.394.2501061046060.133435@ubuntu-linux-20-04-desktop> <c39c0c6f-2fab-46e8-9563-c91fe890e87f@suse.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Tue, 7 Jan 2025, Jan Beulich wrote:
> On 06.01.2025 19:48, Stefano Stabellini wrote:
> > On Mon, 6 Jan 2025, Jan Beulich wrote:
> >> On 04.01.2025 05:15, Denis Mukhin wrote:
> >>>
> >>> On Tuesday, December 10th, 2024 at 11:28 PM, Jan Beulich <jbeulich@suse.com> wrote:
> >>>
> >>>>
> >>>>
> >>>> On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
> >>>>
> >>>>> From: Denis Mukhin dmukhin@ford.com
> >>>>>
> >>>>> console_owner_domid() is introduced to obtain the "console owner" domain ID.
> >>>>>
> >>>>> The call is used in NS8250 emulator to identify the case when physical xen
> >>>>> console focus is owned by the domain w/ NS8250 emulator, in which case,
> >>>>> messages from guest OS are formatted w/o '(XEN)' prefix.
> >>>>
> >>>>
> >>>> Such messages ought to be processed through guest_printk(), which wants a
> >>>> domain pointer, not a domid_t anyway. Plus isn't that going to be
> >>>> current->domain anyway at the callsite, eliminating the need for such a
> >>>>
> >>>> helper altogether?
> >>>
> >>> If the current domain is owning the physical console and printing, say, Linux
> >>> login prompt, there's no need to add "(XEN)" for every printout; adding timestamps
> >>> can be disabled from Xen command line.
> >>
> >> Surely there shouldn't be (XEN), but without (d<N>) it'll be ambiguous in a log
> >> which domain a message came from. As long as only Dom0 messages are left un-
> >> prefixed, that's likely fine. Yet as soon as multiple domains can issue such
> >> messages (and have console "focus") I think the prefix needs to be there.
> > 
> > It looks like we are aligned on the desired behavior,
> 
> Hmm, no, I don't think we are. I don't ...
> 
> > but for clarity,
> > see https://marc.info/?l=xen-devel&m=173405161613716, also copy/pasted
> > here:
> > 
> > I think we should provide a consistent behavior across architectures.
> > The current behavior with vpl011 and dom0less on ARM is the following:
> > 
> > - no prefix for Dom0 output
> > - DOM$NUM for DomUs when not in focus, otherwise no prefix
> 
> ... view this model as a desirable one. It leaves room for ambiguity.

Adding a few more people in CC for feedback.

My priority is to keep the architectures aligned. It might be OK to
change output format, but then let's do it uniformly on ARM as well.

Jan, please clarify what you think would be better than the above. Is it
the following? I don't think I understood your preference.

- DOM$NUM for Dom0 and DomUs when not in focus, otherwise no prefix


From xen-devel-bounces@lists.xenproject.org Wed Jan 08 00:05:04 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 00:05:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866825.1278184 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVJZ8-0000bH-5M; Wed, 08 Jan 2025 00:04:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866825.1278184; Wed, 08 Jan 2025 00:04:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVJZ8-0000bA-2o; Wed, 08 Jan 2025 00:04:54 +0000
Received: by outflank-mailman (input) for mailman id 866825;
 Wed, 08 Jan 2025 00:04:52 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=/V3S=UA=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tVJZ5-0000b3-Vd
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 00:04:51 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org
 [2604:1380:4641:c500::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2d94d328-cd54-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 01:04:50 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id F37DD5C0085;
 Wed,  8 Jan 2025 00:04:07 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9C206C4CED6;
 Wed,  8 Jan 2025 00:04:47 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2d94d328-cd54-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1736294688;
	bh=mtTnv6Dt7hKi8/zexx4oWhOSoNmr3c7SzpMKMflQt6o=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=Mb8xgWeeIZhG8KexYoAE12zJNYrw5SBI7rufHe/GmIg9cPlq9XkEBaPmJBRMxObzq
	 dlwuXqawfqC1jQqwnw6vkaphrCK9ndoMHToRHeGHXHbrg2icQ/32dcLu9OKiPJDgyi
	 GUz1QTtnhj3bLdkQFVGAqSduMN7gb68nKCYUf+YId5PHsuG4r05+B2zXXAY3M++Rj+
	 cAp9WGVj120NFqDekSgoP04zwY8RJpssKRioYv4aeHEqY11P2lGdnwGF6xMWUUYCVJ
	 u674MdfcEtpTaaMY7w7JUenj7qWc3zein66jWrvs26LsQmwUoGVnjELvG3rw1XEni1
	 sa9BDhVLlKFVA==
Date: Tue, 7 Jan 2025 16:04:46 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich <jbeulich@suse.com>
cc: Alessandro Zucchelli <alessandro.zucchelli@bugseng.com>, 
    consulting@bugseng.com, Simone Ballarin <simone.ballarin@bugseng.com>, 
    Doug Goldstein <cardoe@cardoe.com>, 
    Stefano Stabellini <sstabellini@kernel.org>, 
    Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, 
    xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3] misra: add deviation for MISRA C Rule R11.8.
In-Reply-To: <921ef7b8-36d2-405d-ad7e-1a9418b7c4e6@suse.com>
Message-ID: <alpine.DEB.2.22.394.2501071603130.133435@ubuntu-linux-20-04-desktop>
References: <4a2c68bdc11a815cb8531be305e2e7fc4bef7779.1736240655.git.alessandro.zucchelli@bugseng.com> <921ef7b8-36d2-405d-ad7e-1a9418b7c4e6@suse.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Tue, 7 Jan 2025, Jan Beulich wrote:
> On 07.01.2025 10:10, Alessandro Zucchelli wrote:
> > --- a/docs/misra/deviations.rst
> > +++ b/docs/misra/deviations.rst
> > @@ -353,6 +353,13 @@ Deviations related to MISRA C:2012 Rules:
> >         Fixing this violation would require to increase code complexity and lower readability.
> >       - Tagged as `safe` for ECLAIR.
> >  
> > +   * - R11.8
> > +     - Violations caused by function __hvm_copy occour when a const void attribute is passed,
> > +       as the const qualifier is stripped. However, in such cases, the function ensures
> > +       that it does not modify the attribute, therefore, this use is deemed safe.
> > +       Fixing this violation would require to increase code complexity and lower readability.
> > +     - Tagged as `safe` for ECLAIR.
> 
> Do you really mean "attribute" in both places the word is used? In the
> first case talk appears to be of a function argument / parameter, while
> in the second case it looks to be the buffer referenced be the
> argument / parameter which is meant.

Yes I can see what Jan is saying. What about:

Violations caused by function __hvm_copy occur when a const void
argument is passed, as the const qualifier is stripped. However, in such
cases, the function ensures that it does not modify the buffer
referenced by the argument, therefore, this use is deemed safe. Fixing
this violation would require to increase code complexity and lower
readability.



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 01:50:27 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 01:50:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866843.1278194 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVLCz-0003fN-9I; Wed, 08 Jan 2025 01:50:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866843.1278194; Wed, 08 Jan 2025 01:50:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVLCz-0003f5-4V; Wed, 08 Jan 2025 01:50:09 +0000
Received: by outflank-mailman (input) for mailman id 866843;
 Wed, 08 Jan 2025 01:50:07 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=X11H=UA=apertussolutions.com=dpsmith@srs-se1.protection.inumbo.net>)
 id 1tVLCx-0003ez-NX
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 01:50:07 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e110e1ad-cd62-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 02:50:05 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1736300994381761.1501356937698;
 Tue, 7 Jan 2025 17:49:54 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e110e1ad-cd62-11ef-a0df-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1736300996; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=lOv9UsmBmv7zxEyv+vmPDxBwrrQzoy1A7jRz19NNR1CTve4QdbiQNTK7l0gCVV/354RTu7ONES9N596F0lnEjCwqgWTCTChVaJ2meG17AFDgPdvkZF7I/P03IbFhfkIRAnV5i8WuJhFrlytNAPOBhRVEsT3SwMyPZqer8HsfiuA=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1736300996; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=hIgidbHmUnJODbaXHkDMjlG5IKIvy0h27UD0lVOMdgw=; 
	b=dqxKywk3LUr4fgHjNHeNKiQ28jiOJvIvJywLBMnf0tW/gbJ2FyT5euNc1lQMEqbGR+HHzbml1skh5r3TAI1yGhAD4NyPSCRlKl4xDQtjQxqNceEPvXn/ixUuAPWy4rr2gKzsNhwEYUNfGDjRC81bVL6o3Ihs0BPei/KeHNP6is4=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1736300996;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=hIgidbHmUnJODbaXHkDMjlG5IKIvy0h27UD0lVOMdgw=;
	b=OtejgH7f/rR+BIMja+ankEmI2T8qnABmC2pcTWW1jteuNhEtTb/VyPZlrJbBvv0b
	aGVe0/g36P0HW8RJoJuMvo08P8dBsUsbCpemAo0c53L//kp9uaUUwKhzhZlEq2idt1i
	U1PBh5WKOsKPu/9JaBeO5QPfziyZEWBTHEzvsg+c=
Message-ID: <0b451cc7-c6b7-4246-bc6e-16c409cba882@apertussolutions.com>
Date: Tue, 7 Jan 2025 20:49:53 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [for-4.20][PATCH 1/3] xen/flask: Wire up XEN_DOMCTL_vuart_op
To: Michal Orzel <michal.orzel@amd.com>, xen-devel@lists.xenproject.org
Cc: Anthony PERARD <anthony.perard@vates.tech>, oleksii.kurochko@gmail.com
References: <20250107092719.26401-1-michal.orzel@amd.com>
 <20250107092719.26401-2-michal.orzel@amd.com>
Content-Language: en-US
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
In-Reply-To: <20250107092719.26401-2-michal.orzel@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External

On 1/7/25 04:27, Michal Orzel wrote:
> Addition of FLASK permission for this hypercall was overlooked in the
> original patch. Fix it. The only VUART operation is initialization that
> can occur only during domain creation.
> 
> Fixes: 86039f2e8c20 ("xen/arm: vpl011: Add a new domctl API to initialize vpl011")
> Signed-off-by: Michal Orzel <michal.orzel@amd.com>

Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 01:50:29 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 01:50:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866845.1278204 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVLDJ-00043O-G4; Wed, 08 Jan 2025 01:50:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866845.1278204; Wed, 08 Jan 2025 01:50:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVLDJ-00043A-CH; Wed, 08 Jan 2025 01:50:29 +0000
Received: by outflank-mailman (input) for mailman id 866845;
 Wed, 08 Jan 2025 01:50:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=id0C=UA=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tVLDH-0003ez-Nc
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 01:50:28 +0000
Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch
 [185.70.40.133]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id edde0964-cd62-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 02:50:25 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: edde0964-cd62-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1736301024; x=1736560224;
	bh=xyf1iTcubPh7z/QvMQm2In92t48eU46Maoh3GoepQ+k=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=WYZEtdEtivqo6tb4YtDm40KUFqj9FoWG2W7I1QGRoQfN02K8bnxsKBCsKSiTBrOgO
	 /SXPmqKi8tnG2zH1q+IVe6Pshs+D7n8rDP4upjrFpN8pTM9PcwQEWMQOri3gCIMI4Z
	 wXX8LmBQP7p8+AoDMuSIZIa0mIyG3I+blplySl8sUr2pGwc3mLyYACg1q4GhbexTXP
	 TXkrZWClRms67VfQcOgUFgLqHaR1uqCsiuvncwKeqzHZ3vPL0mD3g09P375pHZFp1/
	 ivRJLvIK5NTXRpM78PA5wwpqLsrw2kt7yvLYhHsMJnUjaP/6IkNgrvvnfAriVJxS1N
	 qRnzntCEeaiDA==
Date: Wed, 08 Jan 2025 01:50:16 +0000
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: xen-devel@lists.xenproject.org, kelly.choi@cloud.com, committers@xenproject.org, Denis Mukhin <dmukhin@ford.com>
Subject: Re: Xen 4.20 Development Update [December]
Message-ID: <l-i2X3sIZcusZX5bDJSb2KhxOQvqVE5V6Igl7FnlCVndzUmgX8ZfceC6w1kc9xpSIO8unl92qJdnZWNl5sA5PhXfv6OWpvcEmKY-qX2-pK0=@proton.me>
In-Reply-To: <77f11aeb-40a2-47b0-accf-782941d26f81@gmail.com>
References: <20250107173117.79047-1-oleksii.kurochko@gmail.com> <77f11aeb-40a2-47b0-accf-782941d26f81@gmail.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 6f6ab55428d3deca3e11efa9dffa75c0250ae2a6
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tuesday, January 7th, 2025 at 9:37 AM, Oleksii Kurochko <oleksii.kurochk=
o@gmail.com> wrote:

> Missed to add one item to x86 about "x86/efi: Fix booting when NX is disa=
bled".
>=20
> Please find some details below.
>=20
>=20
>=20
> On 1/7/25 6:31 PM, Oleksii Kurochko wrote:
>=20
> > Hello everyone,
> >=20
> > This email only tracks big items for xen.git tree. Please reply for ite=
ms you
> > would like to see in 4.20 so that people have an idea what is going on =
and
> > prioritise accordingly.
> >=20
> > You're welcome to provide description and use cases of the feature you'=
re
> > working on.
> >=20
> > =3D Timeline =3D
> >=20
> > * Last posting date: Nov 29, 2024
> > * Feature freeze date: Dec 20, 2024
> > ---> We are here
> > * RC1: Jan 10, 2025
> > * Hard code freeze: Jan 17, 2025
> > * Release: Feb 21, 2025
> > ( current release schedule: https://wiki.xenproject.org/wiki/Xen_Projec=
t_X.YY_Release_Notes )
> >=20
> > This will likely be the last Xen 4.20 Development Update email, as we h=
ave
> > passed the feature freeze date, so no significant updates are expected =
until
> > the Xen 4.20 release.
> >=20
> > The next email with development updates will cover Xen 4.21.
> >=20
> > Below, you can find a summary of the tasks completed by the end of
> > December 2024, followed by a list of tasks still in progress ( it is
> > up-to-date also ), which will be moved to the Xen 4.21 task list.
> >=20
> > The following items ( the links for them could be found int the list be=
low )
> > were moved to completed:
> >=20
> > [Dec]:
> > - x86:
> >   * x86/mm: miscellaneous fixes.
> >   * Remove "APX support" task as Jan B. told:
> >       I think you want to remove this from the list. While I have compl=
eted
> >       work there, I'm not fancying re-basing ahead of the AVX10 work, a=
nd hence
> >       that needs to go in first anyway. Which seems unlikely enough at =
this
> >       point, for 4.20.
> >   * Support device passthrough when dom0 is PVH on Xen.
> > - Arm:
> >   * Prerequisite patches for R82 upstreaming
> >   * Add support for S32CC platforms and LINFlexD UART.
> >   * Arm cache coloring.
> >   * ffa: Improvements and fixes.
> >   * Enable early bootup of AArch64 MPU systems.
> >   * Enable early bootup of AArch64 MPU systems (Part 2)
> > - RISC-V:
> >   * Unflattening and relocation of host device tree
> >=20
> > [Nov]:
> > - Hypervisor:
> >   * drivers/char: rename arm-uart.c to uart-init.c
> >   * Move gic_preinit() to common code
> >   * stubdom: reduce xenstore library dependencies
> >   * xen/trace: Treewide API cleanup
> > - x86:
> >   * x86/HVM: drop stdvga caching mode
> >   * Fix module-handling use-after-free's
> >   * Reuse 32 bit C code more safely
> >   * xen: address violations of MISRA C Rule 13.6
> >   * x86/ucode: Simplify/fix loading paths further
> >   * x86: address violations of MISRA C Rule 16.3
> >   * iommu/x86: fixes/improvements for unity range checks
> >   * x86/pvh: Support relocating dom0 kernel
> > - Arm:
> >   * xen/arm: Add emulation of Debug Data Transfer Registers
> > - RISC-V:
> >   * Setup memory management
> >=20
> >=20
> > * Full list of items : *
> >=20
> > =3D Projects =3D
> >=20
> > =3D=3D Hypervisor =3D=3D
> >=20
> > *  Remove the directmap (v4)
> >   -  Elias El Yandouzi
> >   -  https://lore.kernel.org/xen-devel/f6973275-0d7e-4db4-b949-f21e530e=
1dfc@citrix.com/T/#m9733aa717edf032db0cf8f8f6763537b4f30c1f8
> >=20
> > *  remove libxenctrl usage from xenstored (v1 -> v6)
> >   -  Juergen Gross
> >   -  https://lore.kernel.org/xen-devel/20250107101711.5980-1-jgross@sus=
e.com/T/#me3a5e025aef6a3431c21e81c670bf09744f2fe35
> >=20
> > *  automation: Refresh the remaining Debian containers (v2)
> >   -  Javi Merino
> >   -  https://lore.kernel.org/xen-devel/cover.1730743077.git.javi.merino=
@cloud.com/T/#m5d9acb7cf5db3c2be3d6527de14b69b07812314e
> >=20
> > *  GRUB: Supporting Secure Boot of xen.gz (v1)
> >   -  Ross Lagerwall
> >   -  https://patchew.org/Xen/20240313150748.791236-1-ross.lagerwall@cit=
rix.com/
> >=20
> > *  MSI-X support with qemu in stubdomain, and other related changes (v8=
)
> >   -  Marek Marczykowski-G=C3=B3recki
> >   -  https://lore.kernel.org/xen-devel/cover.33fb4385b7dd6c53bda4acf0a9=
e91748b3d7b1f7.1715313192.git-series.marmarek@invisiblethingslab.com/
> >   -  Only automation patch left to be reviewed/merged.
> >=20
> > *  [RFC] Introduce xenbindgen to autogen hypercall structs (v1)
> >   -  Alejandro Vallejo
> >   -  https://patchew.org/Xen/20241115115200.2824-1-alejandro.vallejo@cl=
oud.com/
> >=20
> > *  Introduce NS8250 UART emulator (v1 -> v2)
> >   -  Denis Mukhin
> >   -  https://patchew.org/Xen/20241205-vuart-ns8250-v1-0-e9aa923127eb@fo=
rd.com/

I have posted v3 recently:
  https://lore.kernel.org/xen-devel/20250103-vuart-ns8250-v3-v1-0-c5d36b31d=
66c@ford.com/

> >=20
> > =3D=3D=3D x86 =3D=3D=3D
>=20
> * x86/efi: Fix booting when NX is disabled (v1)
>   - Andrew Cooper
>   - https://patchew.org/Xen/20240722101838.3946983-1-andrew.cooper3@citri=
x.com/
>=20
> ~ Oleksii
>=20
> > *  Expose consistent topology to guests (v7)
> >   -  Alejandro Vallejo
> >   -  https://patchew.org/Xen/20241021154600.11745-1-alejandro.vallejo@c=
loud.com/
> >=20
> > *  Boot modules for Hyperlaunch (v8 -> v9)
> >   -  Daniel P. Smith
> >   -  https://patchew.org/Xen/20241115131204.32135-1-dpsmith@apertussolu=
tions.com/
> >=20
> > *  Address Space Isolation FPU preparations (v2)
> >   -  Alejandro Vallejo
> >   -  https://patchew.org/Xen/20241105143310.28301-1-alejandro.vallejo@c=
loud.com/
> >=20
> > *  x86/alternatives: Adjust all insn-relative fields (v2)
> >   -  Andrew Cooper
> >   -  https://lore.kernel.org/xen-devel/20241002152725.1841575-1-andrew.=
cooper3@citrix.com/T/#mac2deaea7e02a343210d61887486433d946ad129
> >=20
> > *  x86emul: misc additions (v5 -> v7)
> >   -  Jan Beulich
> >   -  https://patchew.org/Xen/3a25cd59-e1cb-4bfc-b868-fb11599d22f5@suse.=
com/
> >=20
> > *  x86/HVM: emulation (MMIO) improvements (v2)
> >   -  Jan Beulich
> >   -  https://patchew.org/Xen/3294f629-f91f-4b5d-9eb0-40a34aa2ec3e@suse.=
com/
> >=20
> > *  x86: support AVX10 (v2 -> v3)
> >   -  Jan Beulich
> >   -  https://patchew.org/Xen/516b7f9a-048e-409d-8a4e-89aeb8ffacc4@suse.=
com/
> >=20
> > *  VT-d: SATC handling; ATS: tidying (v2)
> >   -  Jan Beulich
> >   -  https://patchew.org/Xen/64b028be-2197-4951-ae5b-32f9eabfa84a@suse.=
com/
> >=20
> > *  x86: parallelize AP bring-up during boot (v1)
> >   -  Krystian Hebel
> >   -  https://lore.kernel.org/xen-devel/cover.1699982111.git.krystian.he=
bel@3mdeb.com/
> >=20
> > *  x86/spec-ctrl: IBPB improvements (v4)
> >   -  Jan Beulich
> >   -  https://patchew.org/Xen/06591b64-2f05-a4cc-a2f3-a74c3c4a76d6@suse.=
com/
> >=20
> > *  Move some boot code from assembly to C (v2)
> >   -  Frediano Ziglio
> >   -  https://patchew.org/Xen/20241122093358.478774-1-frediano.ziglio@cl=
oud.com/
> >=20
> > *  Hyperlaunch device tree for dom0 (v1 -> v2)
> >   -  Daniel P. Smith
> >   -  https://patchew.org/Xen/20241226165740.29812-1-dpsmith@apertussolu=
tions.com/
> >=20
> > *  x86: memcpy() / memset() (non-)ERMS flavors plus fallout (v3)
> >   -  Jan Beulich
> >   -  https://patchew.org/Xen/e7314ac8-ed09-4da8-b915-09409b01fe77@suse.=
com/
> >=20
> > *  amd-pstate CPU Performance Scaling Driver (v1)
> >   -  Penny Zheng
> >   -  https://patchew.org/Xen/20241203081111.463400-1-Penny.Zheng@amd.co=
m/
> >=20
> > =3D=3D=3D ARM =3D=3D=3D
> >=20
> > *  Add Virtio-PCI for dom0less on ARM (v1)
> >   -  Edgar E. Iglesias
> >   -  https://lore.kernel.org/xen-devel/20240924162359.1390487-1-edgar.i=
glesias@gmail.com/T/#mfa148991b9408f223a079d4cef610244d5b04c2b
> >=20
> > *  PCI devices passthrough on Arm, part 3 (v16)
> >   -  Stewart Hildebrand
> >   -  https://patchew.org/Xen/20240522225927.77398-1-stewart.hildebrand@=
amd.com/
> >   -  Patches are Acked but for some reason last two patches aren't merg=
ed.
> >=20
> > *  DOMCTL-based guest magic region allocation for 11 domUs (v4)
> >   -  Henry Wang
> >   -  https://patchew.org/Xen/20240409045357.236802-1-xin.wang2@amd.com/
> >=20
> > =3D=3D=3D RISCV =3D=3D=3D
> >=20
> > =3D=3D=3D PPC =3D=3D=3D
> >=20
> > *  Early Boot Allocation on Power (v5)
> >   -  Shawn Anastasio
> >   -  https://lore.kernel.org/xen-devel/cover.1727388925.git.sanastasio@=
raptorengineering.com/T/#m8cac91a93b56a359fa2d5f08596c4be61dca290d
> >=20
> > =3D=3D Completed =3D=3D
> >=20
> > =3D=3D=3D Hypervisor =3D=3D=3D
> >=20
> > *  libxl: Implement QEMU command line probe (v1)
> >   -  Anthony PERARD
> >   -  https://lore.kernel.org/xen-devel/20240827100328.23216-1-anthony.p=
erard@vates.tech/T/#mdef23cefc2532ab0c9d7460290cef26780cf97cb
> >=20
> > *  xen/bitops: hweight() cleanup/improvements (v3)
> >   -  Andrew Cooper
> >   -  https://lore.kernel.org/xen-devel/20240904225530.3888315-1-andrew.=
cooper3@citrix.com/T/#me22e08f7477be725122dd9b97d29d272e3b586c4
> >=20
> > *  Move percpu code to common (v2)
> >   -  Oleksii Kurochko
> >   -  https://lore.kernel.org/xen-devel/cover.1727185495.git.oleksii.kur=
ochko@gmail.com/T/#mf93394c46f15cbdcfc873de2d52d862a8b70da7f
> >=20
> > *  xen/livepatch: improvements to loading (v3)
> >   -  Roger Pau Monne
> >   -  https://lore.kernel.org/xen-devel/20240926101431.97444-1-roger.pau=
@citrix.com/T/#ma3f65948b065dc443aea2192873a3b3dfa52a2d7
> >=20
> > *  Move {acpi_}device_init() and device_get_class() to common code (v5)
> >   -  Oleksii Kurochko
> >   -  https://lore.kernel.org/xen-devel/17c7d988e45d7c82448b81fe66b01a5c=
eca0c15e.camel@gmail.com/T/#m68bd00d4f8b3724e83ba13024e94b15b58a28829
> >=20
> > *  blkif: reconcile protocol specification with in-use implementations =
(v1)
> >   -  Roger Pau Monne
> >   -  https://lore.kernel.org/xen-devel/20240903141923.72241-1-roger.pau=
@citrix.com/
> >=20
> > *  Move gic_preinit() to common code (v5)
> >   -  Oleksii Kurochko
> >   -  https://lore.kernel.org/xen-devel/151ac176ff02d2ff9b7f87e3c02b9ce0=
472720fa.1732288620.git.oleksii.kurochko@gmail.com/
> >=20
> > *  stubdom: reduce xenstore library dependencies (v1)
> >   -  Juergen Gross
> >   -  https://lore.kernel.org/xen-devel/20241010155459.22389-1-jgross@su=
se.com/T/#m8b5af386e2d288961bb6e8f7839650e0cab96a83
> >=20
> > *  xen/trace: Treewide API cleanup (v7)
> >   -  Andrew Cooper
> >   -  https://patchew.org/Xen/20240318163552.3808695-1-andrew.cooper3@ci=
trix.com/
> >=20
> > =3D=3D=3D x86 =3D=3D=3D
> >=20
> > *  x86/mm: miscellaneous fixes (v2 -> v3)
> >   -  Roger Pau Monne
> >   -  https://patchew.org/Xen/20241114145715.59777-1-roger.pau@citrix.co=
m/
> >=20
> > *  Support device passthrough when dom0 is PVH on Xen (v16)
> >   -  Jiqian Chen
> >   -  https://lore.kernel.org/xen-devel/20240930034250.2682265-1-Jiqian.=
Chen@amd.com/T/#m5d557d76f290ff5b5550c1443cab5774d397e526
> >=20
> > *  Drop Xeon Phi support (v1)
> >   -  Jan Beulich
> >   -  https://lore.kernel.org/xen-devel/44147507-65a4-4f21-aada-fa647f53=
ffd0@suse.com/
> >=20
> > *  Utilize ucode_force and remove opt_ucode_allow_same (v7)
> >   -  Fouad Hilly
> >   -  https://lore.kernel.org/xen-devel/20240822130426.492931-4-fouad.hi=
lly@cloud.com/
> >=20
> > *  Switch flat driver to use phys dst for ext ints (v2)
> >   -  Matthew Barnes
> >   -  https://lore.kernel.org/xen-devel/0db68e62ffc428f553a30397df1e7906=
8d26bb5f.1728311378.git.matthew.barnes@cloud.com/
> >=20
> > *  x86/shutdown: change default reboot method preference (v1)
> >   -  Roger Pau Monne
> >   -  https://lore.kernel.org/xen-devel/20240802105613.99197-1-roger.pau=
@citrix.com/
> >=20
> > *  x86/HVM: drop stdvga caching mode (v2)
> >   -  Jan Beulich
> >   -  https://lore.kernel.org/xen-devel/dc3faf7d-0690-46e6-8fbc-67a177a1=
e171@suse.com/T/#mc8ca51cdbfb6ba26ea6b4624059d40ea075c2117
> >=20
> > *  Fix module-handling use-after-free's (v2)
> >   -  Andrew Cooper
> >   -  https://lore.kernel.org/xen-devel/20241106003938.3453243-1-andrew.=
cooper3@citrix.com/T/#mdf923bdf63b034a6493bf62beeead280b92a38ed
> >=20
> > *  Reuse 32 bit C code more safely (v4)
> >   -  Frediano Ziglio
> >   -  https://lore.kernel.org/xen-devel/20241014085332.3254546-1-fredian=
o.ziglio@cloud.com/T/#m53e36815ddec2511ddd1fa8d1a7ed9a27c0cd0f7
> >=20
> > *  xen: address violations of MISRA C Rule 13.6 (v2)
> >   -  Federico Serafini
> >   -  https://lore.kernel.org/xen-devel/cover.1727690180.git.federico.se=
rafini@bugseng.com/T/#mbec702db211240305e0d35649e65627d9fa75a29
> >=20
> > *  x86/ucode: Simplify/fix loading paths further (v2)
> >   -  Andrew Cooper
> >   -  https://lore.kernel.org/xen-devel/20241112211915.1473121-1-andrew.=
cooper3@citrix.com/
> >=20
> > *  x86: address violations of MISRA C Rule 16.3 (v2)
> >   -  Federico Serafini
> >   -  https://patchew.org/Xen/cover.1731485149.git.federico.serafini@bug=
seng.com/
> >=20
> > *  iommu/x86: fixes/improvements for unity range checks (v4 ( [PATCH 4/=
4] iommu/x86: make unity range checking more strict? ))
> >   -  Roger Pau Monne
> >   -  https://lore.kernel.org/xen-devel/20240201170159.66330-1-roger.pau=
@citrix.com/
> >=20
> > *  x86/pvh: Support relocating dom0 kernel (v7)
> >   -  Jason Andryuk
> >   -  https://patchew.org/Xen/20240404212519.16401-1-jason.andryuk@amd.c=
om/
> >=20
> > =3D=3D=3D ARM =3D=3D=3D
> >=20
> > *  Prerequisite patches for R82 upstreaming (v4)
> >   -  Luca Fancellu
> >   -  https://patchew.org/Xen/20241203094811.427076-1-luca.fancellu@arm.=
com/
> >=20
> > *  Enable early bootup of AArch64 MPU systems (Part 2) (v3)
> >   -  Ayan Kumar Halder
> >   -  https://patchew.org/Xen/20241204172243.1229942-1-ayan.kumar.halder=
@amd.com/
> >=20
> > *  Enable early bootup of AArch64 MPU systems (v6)
> >   -  Ayan Kumar Halder
> >   -  https://patchew.org/Xen/20241118121250.4027441-1-ayan.kumar.halder=
@amd.com/
> >=20
> > *  Add support for S32CC platforms and LINFlexD UART (v6)
> >   -  Andrei Cherechesu
> >   -  https://patchew.org/Xen/20241219112315.2461048-1-andrei.cherechesu=
@oss.nxp.com/
> >=20
> > *  Arm cache coloring (v9 -> v11)
> >   -  Carlo Nonato
> >   -  https://lore.kernel.org/xen-devel/20241202165921.249585-1-carlo.no=
nato@minervasys.tech/
> >=20
> > *  ffa: Improvements and fixes (v2 -> v3)
> >   -  Bertrand Marquis
> >   -  https://lore.kernel.org/xen-devel/cover.1732702210.git.bertrand.ma=
rquis@arm.com/
> >=20
> > *  iommu/ipmmu-vmsa: Add Renesas R8A779G0 (R-Car V4H) support (v1)
> >   -  Grygorii Strashko
> >   -  https://lore.kernel.org/xen-devel/6ab4ad29-404d-4f5c-8582-5d2f492f=
d549@xen.org/T/#t
> >=20
> > *  xen/arm: dt overlay fixes (v2)
> >   -  Michal Orzel
> >   -  https://lore.kernel.org/xen-devel/20241004122220.234817-1-michal.o=
rzel@amd.com/T/#md51a060b93fe72f17637d6d72e3d4e2296cb4078
> >=20
> > *  xen/arm: Add emulation of Debug Data Transfer Registers (v6)
> >   -  Ayan Kumar Halder
> >   -  https://patchew.org/Xen/20240307123943.1991755-1-ayan.kumar.halder=
@amd.com/
> >=20
> > =3D=3D=3D RISC-V =3D=3D=3D
> >=20
> > *  Unflattening and relocation of host device tree (v1)
> >   -  Oleksii Kurochko
> >   -  https://patchew.org/Xen/cover.1732709650.git.oleksii.kurochko@gmai=
l.com/
> >=20
> > *  initialize bootinfo from dtb (v2)
> >   -  Oleksii Kurochko
> >   -  https://lore.kernel.org/xen-devel/cover.1728481578.git.oleksii.kur=
ochko@gmail.com/T/#m543bf84d47f0ea738938a9a442cd144bb34f7316
> >=20
> > *  Register Xen's load address as a boot module (v3)
> >   -  Oleksii Kurochko
> >   -  https://lore.kernel.org/xen-devel/cover.1728472163.git.oleksii.kur=
ochko@gmail.com/T/#t
> >=20
> > *  device tree mapping (v9)
> >   -  Oleksii Kurochko
> >   -  https://lore.kernel.org/xen-devel/cover.1727781468.git.oleksii.kur=
ochko@gmail.com/T/#t
> >=20
> > *  Setup memory management (v5)
> >   -  Oleksii Kurochko
> >   -  https://lore.kernel.org/xen-devel/cover.1731344883.git.oleksii.kur=
ochko@gmail.com/T/#m9f76f1b685896ea603a2b153e05104c7405a7d28
> >=20
> > Have a good week!
> >=20
> > Best regards,
> >  Oleksii


From xen-devel-bounces@lists.xenproject.org Wed Jan 08 01:53:58 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 01:53:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866859.1278214 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVLGe-0004qV-2F; Wed, 08 Jan 2025 01:53:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866859.1278214; Wed, 08 Jan 2025 01: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 <xen-devel-bounces@lists.xenproject.org>)
	id 1tVLGd-0004qO-Ui; Wed, 08 Jan 2025 01:53:55 +0000
Received: by outflank-mailman (input) for mailman id 866859;
 Wed, 08 Jan 2025 01:53: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
 <SRS0=X11H=UA=apertussolutions.com=dpsmith@srs-se1.protection.inumbo.net>)
 id 1tVLGc-0004qI-Bs
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 01:53:54 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6912fa6e-cd63-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 02:53:53 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1736301225745550.1266495760739;
 Tue, 7 Jan 2025 17:53:45 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 6912fa6e-cd63-11ef-a0df-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1736301227; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=NXZtcB9dXuJnmHVSp3YIlSfIiiohANikwjmhch3tt2OcdaKzZlfsZBLOXdYm1Juh5+8EA3jWM8icS311sEOO4KNoMDSyJVhAeVz8XhSwfZdHAQF/bBW2o7eNYqr39+mDLZNguAIF08L8nU3IvKCJD63qiqE5ivns6gG/X7kWRbw=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1736301227; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=f5rAzbD51Gu5Ski3hdUO3bS9t3PSh+Y0Ojx3QKI5X00=; 
	b=JncDwuo/qwDvxzEtsZ6TnUS/RM3l0HyeDnjAntMu3ft4LUKucgMxtdG8aLql6MTgqJcqgPLBbOHGcVxFsW84kTADIfpwkzE3o14DUOxm15+H3QvCHuqiiLDhGwSVNv+VMWSCPmbiz8k1DNBnB8BKCNhYHUxQmTO01H6g5vRD6q0=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1736301227;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=f5rAzbD51Gu5Ski3hdUO3bS9t3PSh+Y0Ojx3QKI5X00=;
	b=i2PDaaOoC+rfDsBi8s1O+8I6Y0t/6E1UpKp0f3YERhXm6Hnzz2ZBs5ztdgWBgT0L
	J2V6zGIBUlJ7n3oPYnxeqfkw7zL0dVxGQgASt/WWF/8UX+yyTsztHY2BDw9STGgFsN/
	1fbALEfrHIo7f/a1+DAXDGOyHCDKTvYfKmG6Zxlc=
Message-ID: <d1c16342-2c79-49ac-8856-e428a5503d2c@apertussolutions.com>
Date: Tue, 7 Jan 2025 20:53:43 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [for-4.20][PATCH 2/3] xen/flask: Wire up XEN_DOMCTL_dt_overlay
To: Michal Orzel <michal.orzel@amd.com>, xen-devel@lists.xenproject.org
Cc: Anthony PERARD <anthony.perard@vates.tech>, oleksii.kurochko@gmail.com
References: <20250107092719.26401-1-michal.orzel@amd.com>
 <20250107092719.26401-3-michal.orzel@amd.com>
Content-Language: en-US
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
In-Reply-To: <20250107092719.26401-3-michal.orzel@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External

On 1/7/25 04:27, Michal Orzel wrote:
> Addition of FLASK permission for this hypercall was overlooked in the
> original patch. Fix it. The only dt overlay operation is attaching that can
> happen only after the domain is created. Dom0 can attach overlay to itself
> as well.
> 
> Fixes: 4c733873b5c2 ("xen/arm: Add XEN_DOMCTL_dt_overlay and device attachment to domains")
> Signed-off-by: Michal Orzel <michal.orzel@amd.com>

Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>


From xen-devel-bounces@lists.xenproject.org Wed Jan 08 01:56:41 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 01:56:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866866.1278224 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVLJE-0005Ns-El; Wed, 08 Jan 2025 01:56:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866866.1278224; Wed, 08 Jan 2025 01:56:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVLJE-0005Nl-BF; Wed, 08 Jan 2025 01:56:36 +0000
Received: by outflank-mailman (input) for mailman id 866866;
 Wed, 08 Jan 2025 01:56:34 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=X11H=UA=apertussolutions.com=dpsmith@srs-se1.protection.inumbo.net>)
 id 1tVLJC-0005Nf-SI
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 01:56:34 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c7e42aa1-cd63-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 02:56:32 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 173630138292524.407803060130504;
 Tue, 7 Jan 2025 17:56:22 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c7e42aa1-cd63-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; t=1736301385; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=WtRzUXswvK4w1dp/5iy0T2Trt4Tl4ndbOjmJ1py/4CcUYzd1HW84hOSNGHQFm4+LI/oYH+6PgybidTM5s/vSEdHSRjeE1aB+OCE2QeubIxkVusP2xhhKJcxo5sqt/7dZHazWisr8c5OGVp7qE9iR7pdJ0Fot0slEOTSXHfyJ70k=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1736301385; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=j/UHAXabWRNv8tS5eRWY1L4PwWCsosIyiixLhG9TivA=; 
	b=dvT9lMB/Wg/LfHMrZWcHjrzahHFfOP1Pdh3GOhkWkX6h5OgwNOkzfdnHMDTKRJOektywEVYfT/H03AtyzUkcJibvlPZOYMO0T+DgTHbFz0riFqA2oO3N4ZUfCmEk3ImHfK/uBW/n/2mjzvkiqCBSl9O1N/X1s1GmPp7gn0GCP+I=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1736301385;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=j/UHAXabWRNv8tS5eRWY1L4PwWCsosIyiixLhG9TivA=;
	b=SBtgm2ydtXRPXPlsMokLjEF6rI1WoNjF4obms6eYpSNGqiEtYsw8GoBErrfh32Od
	ardFI48ddEa8wWOZBdAsNkwL5c4pvLU1iQOxQQMBNik1FbGBhuezUADRT/Z0H3GqRnU
	R7x6QkeRTHgxAWANZE33iqAbjOhNDkuRwCt7QAHc=
Message-ID: <c9b81316-c804-4bf7-9923-ecc5cf26097e@apertussolutions.com>
Date: Tue, 7 Jan 2025 20:56:21 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [for-4.20][PATCH 3/3] xen/flask: Wire up
 XEN_DOMCTL_set_llc_colors
To: Michal Orzel <michal.orzel@amd.com>, xen-devel@lists.xenproject.org
Cc: Anthony PERARD <anthony.perard@vates.tech>, oleksii.kurochko@gmail.com
References: <20250107092719.26401-1-michal.orzel@amd.com>
 <20250107092719.26401-4-michal.orzel@amd.com>
Content-Language: en-US
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
In-Reply-To: <20250107092719.26401-4-michal.orzel@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External

On 1/7/25 04:27, Michal Orzel wrote:
> Addition of FLASK permission for this hypercall was overlooked in the
> original patch. Fix it. Setting LLC colors is only possible during domain
> creation.
> 
> Fixes: 6985aa5e0c3c ("xen: extend domctl interface for cache coloring")
> Signed-off-by: Michal Orzel <michal.orzel@amd.com>

Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>


From xen-devel-bounces@lists.xenproject.org Wed Jan 08 07:16:56 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 07:16:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866874.1278233 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVQIz-00009g-RD; Wed, 08 Jan 2025 07:16:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866874.1278233; Wed, 08 Jan 2025 07:16:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVQIz-00009Y-Oj; Wed, 08 Jan 2025 07:16:41 +0000
Received: by outflank-mailman (input) for mailman id 866874;
 Wed, 08 Jan 2025 07:16:40 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=svEr=UA=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVQIy-00009O-2t
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 07:16:40 +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 7ff6a07f-cd90-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 08:16:38 +0100 (CET)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-4362f61757fso162380975e9.2
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 23:16:37 -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
 ffacd0b85a97d-38a88d0d608sm306785f8f.36.2025.01.07.23.16.35
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 23:16:37 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 7ff6a07f-cd90-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736320597; x=1736925397; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=/ke2hpKYf/kZRfjJaCYG3J/nDiww96DRBbNoB21XHoo=;
        b=a9mVyVnmzR0cbSMeBfNUBftlNtC1M9zUGJoPCW3Tywg/80Yj6JDTwan2YYirSC28cH
         ThTuDDM7oCBM4q9pDzhBd79LFRUm6LHnbbayHIV6IH2zVvnwy2zLpk4eTGNXzACHlAaT
         tJiB9JrJzgCKvxsLJsNn619JWaY5lcw0y7YWCXS5YXIbChWwHUdoqH4XW4zFIC0iUXQ7
         vGJI0uLHBzbkkLee5UnYT63xsrF4MMpC9o+YD5rewo+CYNKpc66RC3pQZrJHumHEFADs
         LpmK53qVokkUYKPLlJFZwxaNh9TACJjbd9jPednWqh0f0LiaprXV23qaEOOBqjDH8Nzl
         pRLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736320597; x=1736925397;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=/ke2hpKYf/kZRfjJaCYG3J/nDiww96DRBbNoB21XHoo=;
        b=tQLYx93Cs+Vu8JupH/q4SLeBW3I78Rcm2w5cQLbFtus7WWuj6AJqxeGUd7OKBGueAE
         XsQ0TBIkt/Djt8O507YF6K/FLZ94b6y2bcpJdjXe8F9pfLjtlbY0bV50FlVGaIIJl8f2
         N6AYkR3tHOjehU2zZQAWKFQCYCKylNsAPI3r7tGOH+e3FQyA7bym9E6oT5hCGwvIOa0F
         g4MobDXxClYjKDu22FU+/5zpHORwp7fR4IoGvpR8gCHCHs7CnoDKxEz6ILBjCaIRMMNp
         7zymUnAgXm1FzMxuVmDl06MWSdCwcHVVqfBF7DGxUUSDAyOpKjkQKaM0bcUDWj3/rURS
         uBkA==
X-Forwarded-Encrypted: i=1; AJvYcCWvXhXEO9qkD7uDU1rCeeRSoKkTpo7FML2tEBdzMHdxGAqTrMeNUsR/SrgWBlPj7qJj0P4Mt2XyfEo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxEkgTXTp9U/rz8vOY25cywjxyDxZeKRSyFoHwwhLN2k89U/PSJ
	IsGBBRHIVbiEwdCohFtFytNx/HpNTiJmhbqRL7NmgIKs+PAmCOh3Nd2mkz7mXQ==
X-Gm-Gg: ASbGncu/l9c4MIl6Tfa8Ufz0G033JWQrkfgeaI2yUyqrDfipu0pUnz+jMbafQX9vNUL
	RPwgDGYQvN67M+ZBfRtSHQBqKUoecFIxn5r/mAsUvV202LmaD496u+jk51ZJp5RfK/L/JSoOGF9
	pY4jyXdGyJ98eyRpDNL9atl1dSejwq24qt/7Pe8JjAFh30M+/hOkOl2R/8t+gaCy/Pb1em7BH9J
	vkK3Jyu7b0mT0Fjeys6nDRLuIdz7zvCqn1SsDMKIMDoOe4sHALKcFkvPUETXVr8lC6dCT7M4sdB
	TMudT3FgDXKXzLdZFg8rhHpyAyXsL/sct6Eh6VvmQA==
X-Google-Smtp-Source: AGHT+IFQ5YlQVV92ZCiB3mWMzlPX97SK2YS2fBNCh8YBBF5pmqkyNXQVfGXHeipjqWd8eDUWd6KXFg==
X-Received: by 2002:a05:6000:470b:b0:386:37f5:99e7 with SMTP id ffacd0b85a97d-38a872f51a3mr1085079f8f.33.1736320597321;
        Tue, 07 Jan 2025 23:16:37 -0800 (PST)
Message-ID: <b182555c-555e-4efc-94a0-5f383f7d8689@suse.com>
Date: Wed, 8 Jan 2025 08:16:35 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/2] x86: Add Support for Paging-Write Feature
To: =?UTF-8?Q?Petr_Bene=C5=A1?= <w1benny@gmail.com>
Cc: Tamas K Lengyel <tamas@tklengyel.com>,
 Alexandru Isaila <aisaila@bitdefender.com>,
 Petre Pircalabu <ppircalabu@bitdefender.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <cover.1735837806.git.w1benny@gmail.com>
 <31a1ff2d5d1e17bb73231e008f1e47c501bb3ce8.1735837806.git.w1benny@gmail.com>
 <d6eb70a7-5895-4471-95b3-609f133fa457@suse.com>
 <CAKBKdXjJm5194Wa=gy=DikiUEsevrB2Xn-idr+vgfgJMBrfZ-w@mail.gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <CAKBKdXjJm5194Wa=gy=DikiUEsevrB2Xn-idr+vgfgJMBrfZ-w@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 07.01.2025 18:18, Petr Beneš wrote:
> On Tue, Jan 7, 2025 at 5:46 PM Jan Beulich <jbeulich@suse.com> wrote:
>> Hmm ... Instead of you touching the bit in every one of the case blocks,
>> I was expecting you to clear the bit ahead of the switch(), accepting a
>> double update in the p2m_access_r_pw case.
> 
> I did consider it, but ultimately didn't like the double-update.
> Similarly, the switch-case above does also set each bit in the
> "case-s" individually. But I understand it's more justified there.

Right - it's setting them to all different combinations each time.

> However, if you insist, I'll fix it.

Please do; it helps readability quite a bit in this case, imo.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jan 08 07:20:01 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 07:20:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866879.1278243 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVQMC-0000hl-AZ; Wed, 08 Jan 2025 07:20:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866879.1278243; Wed, 08 Jan 2025 07:20:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVQMC-0000he-80; Wed, 08 Jan 2025 07:20:00 +0000
Received: by outflank-mailman (input) for mailman id 866879;
 Wed, 08 Jan 2025 07:19:59 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=svEr=UA=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVQMB-0000hY-5u
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 07:19:59 +0000
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com
 [2a00:1450:4864:20::42b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f75cf9cf-cd90-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 08:19:58 +0100 (CET)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-38632b8ae71so11418283f8f.0
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 23:19:58 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c6ad3e3sm53918003f8f.0.2025.01.07.23.19.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 23:19:57 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f75cf9cf-cd90-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736320798; x=1736925598; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=eEXZ4sJbGN687HyvKYaDPn5AHiUmfrPbzdtkBC35uzY=;
        b=XUoe2aBPGXxqvrsv41teUWuBs+I7bRmMJDcedmfK7TVqWlvZ6r9cQxWBg/UEg68O8m
         QaslCr4c2uOkx5F7M8zlwH+FHWoIfSmLYiiJY6f6Z34aMFiOfqJFoma2+hVSTYXfME/D
         p2gKN3JP9HwS2kKDY1KG/d3abhga4hwdP0EDp/X65iSzb0kp3DrdTmWCWZ1hD68lCv/j
         5IfVAT7Ca3mCr52Y0X1JwPAJJWGeCKLTbvrAD8EdfhXL1oOvUrE4UQtqoKg7AMtBfjRU
         uz2iw2SKHRG15m8lfCOb8GmE/8zy9x3HhsmdNE2qzEbKnonCjc++N5256rv9f6fbJF18
         Wt2Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736320798; x=1736925598;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=eEXZ4sJbGN687HyvKYaDPn5AHiUmfrPbzdtkBC35uzY=;
        b=Nht1Kg98ErS5xkRMY1i7jB3g8ogCsdKLAK7Do5M99enrfGv4z5aLJCfKJFtXNQ9Ixo
         /eBRcOKcGQs+wqtz9IfV7XYDJLYB9MQPqxzdgaRhxRQj5SfRMLrlzdK5QCZufMBAdgub
         C9Um6uQjpZfbo99wQDQwm+F4WxPahR4sdJq+QGgjLMMVnUs30sUrwH7PFCtws3yDoih8
         +JRGuw1j52ObLHfO4PhXIJMHpntqHdPEzRwtGY3GftfHHI7CzZLj9R4Pq7s0vobDc5Pc
         p09zpQaGpG1Whhw/pAY41u2PuEbdsl+Al19lASCMFhWb7Ehy/g+AUcVVYcECRkLEQmDI
         AV8A==
X-Forwarded-Encrypted: i=1; AJvYcCXk2EhZGxFlsHyAbLry4o4ICyn/bU9MlxN1dwkvaXqha4KSOvozkjRfc/HeCWG3irQbo04Gt1VDX94=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx41jJ+BI6ljfEyi7NA8D1DI7Tp2Z/kGT1V0EB894cwa9D3IAYY
	uuXd10LUXvfoJWWeZSJP3CX5FjT6Xf5RkDHow0OxC1kmiUBmoA1DGkcC39x69Q==
X-Gm-Gg: ASbGncv4ndoBQZuZPB5Vbiy2dks+vq+2ntikXyb5vPk+lWeg7qjf6OePrXrzaaZx4Q/
	bM7PSMtdGt/y9bMoJXJMEU18nI7FsJE3tL0yKLNQ8CzIt8H0O0MQPmn471iS3IGPOw5PVcm0GcY
	T3uI8AuTL7kSNWmQXAkwjg4FRU7AM3+guM09KSSVZ9F9glicmh0dHwebdQEPt94MskDbLnJCBS4
	IE8B8wC6Ywuy9TlBv7PLn3lFgZvxrucJ34ABFF/Az7R2aTJo58bIgREWH3V72pmpLQEz9xWU4vj
	oRN3biKVPF8/mUPjjDF/CHCL2gMYFasNJTZm9HrhHQ==
X-Google-Smtp-Source: AGHT+IH+ThGGc3Gpbbk0/hf8NxXu2RAEgRAI+tMxQhDnVEGS8dmusNJ9P/mvPtHiWjpl6khFwCqZsQ==
X-Received: by 2002:a05:6000:144d:b0:388:e377:8a1b with SMTP id ffacd0b85a97d-38a8730cc78mr1067893f8f.28.1736320797589;
        Tue, 07 Jan 2025 23:19:57 -0800 (PST)
Message-ID: <d5e37e59-2a05-4184-9b1e-ca0bf77f201c@suse.com>
Date: Wed, 8 Jan 2025 08:19:55 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4] vpci: Add resizable bar support
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Cc: Jiqian Chen <Jiqian.Chen@amd.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>, Huang Rui <ray.huang@amd.com>,
 xen-devel@lists.xenproject.org
References: <20241219052143.3161332-1-Jiqian.Chen@amd.com>
 <d904c816-da83-418a-9bff-9988660af546@suse.com>
 <Z308fGa1daaM62Rf@macbook.local>
 <fb1b00fe-5740-4c0e-81d9-ec9fd9a4a1c3@suse.com>
 <Z31wFjWadOkzTDK3@macbook.local>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <Z31wFjWadOkzTDK3@macbook.local>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 07.01.2025 19:19, Roger Pau Monné wrote:
> On Tue, Jan 07, 2025 at 04:58:07PM +0100, Jan Beulich wrote:
>> On 07.01.2025 15:38, Roger Pau Monné wrote:
>>> On Tue, Jan 07, 2025 at 11:06:33AM +0100, Jan Beulich wrote:
>>>> On 19.12.2024 06:21, Jiqian Chen wrote:
>>>>> --- /dev/null
>>>>> +++ b/xen/drivers/vpci/rebar.c
>>>>> @@ -0,0 +1,131 @@
>>>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>>>> +/*
>>>>> + * Copyright (C) 2024 Advanced Micro Devices, Inc. All Rights Reserved.
>>>>> + *
>>>>> + * Author: Jiqian Chen <Jiqian.Chen@amd.com>
>>>>> + */
>>>>> +
>>>>> +#include <xen/sched.h>
>>>>> +#include <xen/vpci.h>
>>>>> +
>>>>> +static void cf_check rebar_ctrl_write(const struct pci_dev *pdev,
>>>>> +                                      unsigned int reg,
>>>>> +                                      uint32_t val,
>>>>> +                                      void *data)
>>>>> +{
>>>>> +    struct vpci_bar *bar = data;
>>>>> +    uint64_t size = PCI_REBAR_CTRL_SIZE(val);
>>>>> +
>>>>> +    if ( bar->enabled )
>>>>> +    {
>>>>> +        /*
>>>>> +         * Refuse to resize a BAR while memory decoding is enabled, as
>>>>> +         * otherwise the size of the mapped region in the p2m would become
>>>>> +         * stale with the newly set BAR size, and the position of the BAR
>>>>> +         * would be reset to undefined.  Note the PCIe specification also
>>>>> +         * forbids resizing a BAR with memory decoding enabled.
>>>>> +         */
>>>>> +        if ( size != bar->size )
>>>>> +            gprintk(XENLOG_ERR,
>>>>> +                    "%pp: refuse to resize BAR with memory decoding enabled\n",
>>>>> +                    &pdev->sbdf);
>>>>> +        return;
>>>>> +    }
>>>>> +
>>>>> +    if ( !((size >> PCI_REBAR_SIZE_BIAS) & bar->resizable_sizes) )
>>>>> +        gprintk(XENLOG_WARNING,
>>>>> +                "%pp: new size %#lx is not supported by hardware\n",
>>>>> +                &pdev->sbdf, size);
>>>>> +
>>>>> +    bar->size = size;
>>>>
>>>> Shouldn't at least this be in an "else" to the if() above?
>>>
>>> I think this was already raised in a previous version - would be good
>>> to know how real hardware behaves when an invalid size is set.  Is the
>>> BAR register still reset?
>>
>> I'm pretty sure what happens is undefined. I'd expect though that the
>> BAR size then doesn't change. Which would require the above assignment
>> to not be unconditional.
> 
> Might be better to just re-size the BAR, like you suggested to fetch
> the BAR position from the register, instead of assuming 0.

FTAOD by "re-size" you mean re-obtain its size (seeing we're talking of
re-sizable BARs here)? As kind of confirmed ...

>>>>> +        }
>>>>> +
>>>>> +        bar = &pdev->vpci->header.bars[index];
>>>>> +        if ( bar->type != VPCI_BAR_MEM64_LO && bar->type != VPCI_BAR_MEM32 )
>>>>> +        {
>>>>> +            printk(XENLOG_ERR "%pd %pp: BAR%u is not in memory space\n",
>>>>> +                   pdev->domain, &pdev->sbdf, index);
>>>>> +            return -EINVAL;
>>>>
>>>> Same question here then.
>>>>
>>>>> +        }
>>>>> +
>>>>> +        rc = vpci_add_register(pdev->vpci, vpci_hw_read32, vpci_hw_write32,
>>>>> +                               rebar_offset + PCI_REBAR_CAP(i), 4, NULL);
>>>>> +        if ( rc )
>>>>> +        {
>>>>> +            printk(XENLOG_ERR "%pd %pp: fail to add reg of REBAR_CAP rc=%d\n",
>>>>> +                   pdev->domain, &pdev->sbdf, rc);
>>>>> +            return rc;
>>>>> +        }
>>>>> +
>>>>> +        rc = vpci_add_register(pdev->vpci, vpci_hw_read32, rebar_ctrl_write,
>>>>> +                               rebar_offset + PCI_REBAR_CTRL(i), 4, bar);
>>>>> +        if ( rc )
>>>>> +        {
>>>>> +            printk(XENLOG_ERR "%pd %pp: fail to add reg of REBAR_CTRL rc=%d\n",
>>>>> +                   pdev->domain, &pdev->sbdf, rc);
>>>>> +            return rc;
>>>>> +        }
>>>>> +
>>>>> +        bar->resizable_sizes |=
>>>>> +            (pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CAP(i)) >>
>>>>> +             PCI_REBAR_CAP_SHIFT);
>>>>
>>>> Imo this would better use = in place of |= and (see also below) would also
>>>> better use MASK_EXTR() just like ...
>>>>
>>>>> +        bar->resizable_sizes |=
>>>>> +            ((uint64_t)MASK_EXTR(ctrl, PCI_REBAR_CTRL_SIZES) <<
>>>>> +             (32 - PCI_REBAR_CAP_SHIFT));
>>>>
>>>> ... this one does.
>>>>
>>>> Further I think you want to truncate the value for 32-bit BARs, such that
>>>> rebar_ctrl_write() would properly reject attempts to set sizes of 4G and
>>>> above for them.
>>>
>>> For the hardware domain at least we shouldn't add such restriction -
>>> Xen in general allows dom0 to do things it would otherwise consider
>>> invalid, in case it has to deal with hardware quirks.
>>>
>>> Rather than reject Xen should just print a warning that the sizes
>>> supported by the device are likely invalid.
>>
>> And do what when memory decode is re-enabled on the device? What size a
>> P2M update should it do then?
> 
> You did suggest to re-read the BARs positions after a ctrl write, we
> might as well read the BAR size and use that to be on the safe side.

... here.

>>>>> --- a/xen/drivers/vpci/vpci.c
>>>>> +++ b/xen/drivers/vpci/vpci.c
>>>>> @@ -232,6 +232,12 @@ void cf_check vpci_hw_write16(
>>>>>      pci_conf_write16(pdev->sbdf, reg, val);
>>>>>  }
>>>>>  
>>>>> +void cf_check vpci_hw_write32(
>>>>> +    const struct pci_dev *pdev, unsigned int reg, uint32_t val, void *data)
>>>>> +{
>>>>> +    pci_conf_write32(pdev->sbdf, reg, val);
>>>>> +}
>>>>
>>>> This function is being added just to handle writing of a r/o register.
>>>> Can't you better re-use vpci_ignored_write()?
>>>
>>> But vpci_ignored_write() ignores the write, OTOH here the write is
>>> propagated to the hardware.
>>
>> Right, just for the hardware to drop it. I wouldn't have commented if
>> the function needed to do things like this already existed. Adding yet
>> another cf_check function just for this is what made me give the remark.
> 
> According to the spec yes, they will be ignored.  Yet for the hardware
> domain we try to avoid changing behavior from native as much as
> possible, hence propagating the write seems more appropriate.

Okay; you're the maintainer of this code anyway.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jan 08 07:25:09 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 07:25:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866886.1278255 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVQR7-0002KX-UY; Wed, 08 Jan 2025 07:25:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866886.1278255; Wed, 08 Jan 2025 07:25:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVQR7-0002KQ-QF; Wed, 08 Jan 2025 07:25:05 +0000
Received: by outflank-mailman (input) for mailman id 866886;
 Wed, 08 Jan 2025 07:25: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 <SRS0=svEr=UA=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVQR7-0002KK-1q
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 07:25:05 +0000
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com
 [2a00:1450:4864:20::42a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ad246169-cd91-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 08:25:03 +0100 (CET)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-38a34e8410bso5585652f8f.2
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 23:25:03 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c8474b6sm52246534f8f.51.2025.01.07.23.25.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 23:25:02 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ad246169-cd91-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736321102; x=1736925902; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=e6c9Re305ngnHuLR+MfR+VGkPfepefdC520IxoryX0w=;
        b=NNq5J+w4Jx4RhrARy2Vw0RBvW8tIihddJw2tS0X/LNk5XyPJbuFTbZxQR3LmnpDHhX
         iT9/zLjL+g7Jb6DtrT4zYRU1YYWo5JqbpMhpEgNM+wmcqreTKQ0Vu0NSIuilrHfg93xp
         KNVfsOnVpRVRtlAlc+tV4HofWJfsXFlVu+6zKwgH51VcYN+KJ3Q0YSFZDGaUQfO8/V9G
         EzboK+GxKNMRr4kuJXIR+fWiRL2eGpbJMER+wTHFgcQBboiqCV8PSbwEiyilbjcPCTFR
         mbyR8E+EJOhH/GqaFBFm6KZHrGvaM2bImZj7zc49Mobhw4BaLOyyxikNBq9P+fdaosLU
         llWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736321102; x=1736925902;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=e6c9Re305ngnHuLR+MfR+VGkPfepefdC520IxoryX0w=;
        b=Zr15ur0HYKKWnEPcxhtii9F40ZA1n6RgIkqmWGgAwuJM0XM7LyuYU1sQ0QK1xmyaQ0
         98QwXWA9k7cXi3ucpSCF21ir/y8qmtvg4XuKKgQKZStf+E3nNnn6quhxrfRCbF+zJX6P
         fhhDDWq+SW7tJXOvi51tBa0/bSefuUBoAWILfxRju/NpUqjRo/w7WdDAJDlV0uMrdlwP
         1HoZxDXtTrmjoON8wv5PTv7iF8viCBcd55fjPFPpQk1MQFqeVcQ1YpCtllHLShxb5fz2
         BKfWcSopHw3UtPZmcZynZ9KZTpzTJuQ3uOnif7jCKCRFgu+PIFQl4ANlVijCQ0piqzWT
         QvHg==
X-Forwarded-Encrypted: i=1; AJvYcCWTinKVlborDMrgQ2WxvnKLQ7XnnBjwsibM0snf0K9qIZAD2Baoroe/Y9EkMN+ZMb+86K+wkrP+SUI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzydVUKNCckd3s4Lx0627nAjFybNLRXHhuNYurou8IBgvaSn4N9
	MVdn48ASMac/BFSZi5rjq8KIPtlBGe3jYgQ0+pFZQ6qbYZP0OXB6zTpjapruGA==
X-Gm-Gg: ASbGncv82yB9wcjFIii16O4o3KIiYkal5/HVOx4EKL/wJjj3UuEy4yyg8iRa9sY3F1s
	bShae4cuE0gY0tyM55SxITC5eXXUNde1urWsTUCVl52yNqch5+D64O6kBfd0M6G+1X6FT3VZIY2
	uAgytDnm9dV7jwZ+JQkdpLZ53FrKGm4nbSe0g6/E8otOgo74bxTjzC4/EgE3jJ1Qw2DZHGgI1lX
	WTe5mNwTIHyWvhioaJlz0bbniIozAwtQOBgLLJAHSiH1W3KbdjLoNz1j2La00SswRn0uBQr8Jki
	wDIwKTwAp3XMInP4I5/AVuhAOV9YSYn9gf9mr4ih6Q==
X-Google-Smtp-Source: AGHT+IHI+zJaSYnUtnx3ffXj628DiGINoSX38eIgjlxJ1xAZap+LyjkhOZOyUcgglPp5R2J5fAYQsw==
X-Received: by 2002:a05:6000:1883:b0:385:e5d6:130c with SMTP id ffacd0b85a97d-38a87315989mr1143501f8f.51.1736321102519;
        Tue, 07 Jan 2025 23:25:02 -0800 (PST)
Message-ID: <ec92e932-e3b7-40ad-9ed3-2b3391cc63a7@suse.com>
Date: Wed, 8 Jan 2025 08:25:00 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] xen: update pvcalls_front_accept prototype
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: jgross@suse.com, xen-devel@lists.xenproject.org,
 linux-kernel@vger.kernel.org
References: <alpine.DEB.2.22.394.2501061335161.133435@ubuntu-linux-20-04-desktop>
 <0f8fc348-14f5-40ac-912a-1785caedb675@suse.com>
 <alpine.DEB.2.22.394.2501071530180.133435@ubuntu-linux-20-04-desktop>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <alpine.DEB.2.22.394.2501071530180.133435@ubuntu-linux-20-04-desktop>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 08.01.2025 00:30, Stefano Stabellini wrote:
> On Tue, 7 Jan 2025, Jan Beulich wrote:
>> On 06.01.2025 22:36, Stefano Stabellini wrote:
>>> xen: update pvcalls_front_accept prototype
>>>
>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
>>> ---
>>>
>>> Changes in v2:
>>> - also update pvcalls-front.c
>>
>> The patch still gives the impression of being incomplete: There's no
>> caller of the function that you update. However, there's no such caller
>> in the first place. Why don't you just delete the function then?
> 
> It is meant to be called from an out-of-tree module, which has not been
> upstreamed yet

And which then would require an EXPORT_SYMBOL() anyway. In Xen, as you're
well aware, such unreachable code would actually constitute a Misra
violation.

Without any in-tree caller, imo the change needs a non-empty description,
clarifying why the adjustment is wanted / needed.

Jan



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 07:28:39 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 07:28:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866895.1278264 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVQUY-0002xW-ES; Wed, 08 Jan 2025 07:28:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866895.1278264; Wed, 08 Jan 2025 07:28:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVQUY-0002xP-BR; Wed, 08 Jan 2025 07:28:38 +0000
Received: by outflank-mailman (input) for mailman id 866895;
 Wed, 08 Jan 2025 07:28:37 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=svEr=UA=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVQUX-0002xJ-Eq
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 07:28:37 +0000
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com
 [2a00:1450:4864:20::430])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2bafbd34-cd92-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 08:28:35 +0100 (CET)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-38a34e8410bso5587167f8f.2
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 23:28:35 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c833899sm52167875f8f.42.2025.01.07.23.28.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 23:28:34 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2bafbd34-cd92-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736321315; x=1736926115; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=43jjLX5Vg3QOL3r2QQgGfUrWU2sYwHjmuLJnWEgKluE=;
        b=Ygpm/jrsztbFEkIrLosBMYdi+hb6WChFycpO88EKxWjhTNisxVavO5W1vzTeEzy+ED
         V7CmmAJvYSbuzlRNkZg2iZCROZKOpN9ahJREDySh1uEktR1VOBUwQGWYMMWRMIQ4k4Kw
         qQneyaS7dSEH2ZWJ6RTNeQrCm2yMUKuUEt6KiC4xvNx8IB+saHsxR0wwtfCNpUdwu1h3
         111eKvOo1t9MUYVCfcnpUhVLjT3/ESs2Q9njirSCitjoS268L2OSqbBVMsyVrA5Uflvt
         VfEnMAeRTZSbDFbnxnQsQlc0LvWFKbCgRRKed5oLn546Hf93s4IZ8eMl84QhEub+VWGb
         u+Gw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736321315; x=1736926115;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=43jjLX5Vg3QOL3r2QQgGfUrWU2sYwHjmuLJnWEgKluE=;
        b=OvQmakauvdcoT+S6fUGsvtyZ4pDSvmulX0PTxl7dqWQ08kVvqQRQxFZY68TwyJ81m/
         aSch+Ci8Itdiy/F0m8plMUhPS30er6U3xnvQwFTpcZ3jb6zooAUvj/c1UnFziblxHbI3
         q30mKHNNjsrpM2uZpDS6i0RVtGxlsMCPcFsxmxzpnVYUQrgZHi3vqrI6s3Cqb1np12qj
         t35O9B1a8QTHfEa0LOKjuvwrhvdT7W1haCI9eLwDK3hhYqH/AlUkaSiaI+MLn+yFm6cX
         8L9bxEA06LnVZzcCnr+DlJGLkoV5uWT3eykyNhRVgTBqw23wUFlDsSQQCiXLYraKAvKj
         KE3Q==
X-Forwarded-Encrypted: i=1; AJvYcCX97TNOlIVmJOlbzpOarYkimZboJJdO2Ic1u2LjOSXDPQ3rQsG/MkoOyM10LtXKSbuLtas+KY2pLnI=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywd8Ok346kctjhjw4NO7Td/T1gnbphIPvC6NTtDrOtwftujwrH7
	02oCc1Y0ebHncgyzIvCharl8kGZxgXfZ49MI6pd7MKGoMHgOn0p54ltAATB2MQ==
X-Gm-Gg: ASbGncuAf7NHrhTE9kxUfY/FrLPr2FywpdOKhZukZ0Ef6PR9KUpk7IMLd8kzFnZd5pr
	SqXR3XQA1re9oLCqMl/NfRUHJTgK5Tdb6VsgHQpRz4u32MeIIhDGOWmMK5x6y5QZ5aIB/ixRhNd
	bYor+rmMjlRv+Am/4NBSYz9KfdZicefDARQNvi/e351DbIqT4nzMkviw9ZxienUfxTmsOD77dbo
	UF0jXpgIckgjUDPSh2Dgmo8uez7h6d+/HTwIXDFNOmWf2kegYYjdy3u2qhShWcDQM1AmgaC5Zta
	lfr5cS959h3A8YBlShEz2Kn0FWtWAJ4T5YWULwMnHA==
X-Google-Smtp-Source: AGHT+IGs6jvboxHQ/slSvQWO3lZBVrWGLU+dRwyWUPKtMh7/2Nwqfv6wFEAqwCFTYzsAGtbNnwWjEw==
X-Received: by 2002:a5d:6da4:0:b0:385:de67:2269 with SMTP id ffacd0b85a97d-38a8730e04amr1188281f8f.36.1736321314886;
        Tue, 07 Jan 2025 23:28:34 -0800 (PST)
Message-ID: <a2fa92ff-a5fb-4adc-86aa-1481ebec92fe@suse.com>
Date: Wed, 8 Jan 2025 08:28:32 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 20/35] xen/console: introduce console_owner_domid()
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: Denis Mukhin <dmkhn@proton.me>, dmukhin@ford.com,
 xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 Julien Grall <julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-20-e9aa923127eb@ford.com>
 <d55bf6a6-5861-4b72-88b5-2aaa28ae0290@suse.com>
 <VJ9ivpkbNlqfKhBlb5dL6OuoPAXK9wqD4mhgO9Qt4f0qgmuow22qFv1C7L8DlbKYo7ytdKWeV1bLaYJvTAc2Yt7sEd06XREerWER5RPx4No=@proton.me>
 <8a5a5a0f-72b0-4336-b0d2-142254319242@suse.com>
 <alpine.DEB.2.22.394.2501061046060.133435@ubuntu-linux-20-04-desktop>
 <c39c0c6f-2fab-46e8-9563-c91fe890e87f@suse.com>
 <alpine.DEB.2.22.394.2501071533060.133435@ubuntu-linux-20-04-desktop>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <alpine.DEB.2.22.394.2501071533060.133435@ubuntu-linux-20-04-desktop>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 08.01.2025 00:40, Stefano Stabellini wrote:
> On Tue, 7 Jan 2025, Jan Beulich wrote:
>> On 06.01.2025 19:48, Stefano Stabellini wrote:
>>> On Mon, 6 Jan 2025, Jan Beulich wrote:
>>>> On 04.01.2025 05:15, Denis Mukhin wrote:
>>>>>
>>>>> On Tuesday, December 10th, 2024 at 11:28 PM, Jan Beulich <jbeulich@suse.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
>>>>>>
>>>>>>> From: Denis Mukhin dmukhin@ford.com
>>>>>>>
>>>>>>> console_owner_domid() is introduced to obtain the "console owner" domain ID.
>>>>>>>
>>>>>>> The call is used in NS8250 emulator to identify the case when physical xen
>>>>>>> console focus is owned by the domain w/ NS8250 emulator, in which case,
>>>>>>> messages from guest OS are formatted w/o '(XEN)' prefix.
>>>>>>
>>>>>>
>>>>>> Such messages ought to be processed through guest_printk(), which wants a
>>>>>> domain pointer, not a domid_t anyway. Plus isn't that going to be
>>>>>> current->domain anyway at the callsite, eliminating the need for such a
>>>>>>
>>>>>> helper altogether?
>>>>>
>>>>> If the current domain is owning the physical console and printing, say, Linux
>>>>> login prompt, there's no need to add "(XEN)" for every printout; adding timestamps
>>>>> can be disabled from Xen command line.
>>>>
>>>> Surely there shouldn't be (XEN), but without (d<N>) it'll be ambiguous in a log
>>>> which domain a message came from. As long as only Dom0 messages are left un-
>>>> prefixed, that's likely fine. Yet as soon as multiple domains can issue such
>>>> messages (and have console "focus") I think the prefix needs to be there.
>>>
>>> It looks like we are aligned on the desired behavior,
>>
>> Hmm, no, I don't think we are. I don't ...
>>
>>> but for clarity,
>>> see https://marc.info/?l=xen-devel&m=173405161613716, also copy/pasted
>>> here:
>>>
>>> I think we should provide a consistent behavior across architectures.
>>> The current behavior with vpl011 and dom0less on ARM is the following:
>>>
>>> - no prefix for Dom0 output
>>> - DOM$NUM for DomUs when not in focus, otherwise no prefix
>>
>> ... view this model as a desirable one. It leaves room for ambiguity.
> 
> Adding a few more people in CC for feedback.
> 
> My priority is to keep the architectures aligned. It might be OK to
> change output format, but then let's do it uniformly on ARM as well.
> 
> Jan, please clarify what you think would be better than the above. Is it
> the following? I don't think I understood your preference.
> 
> - DOM$NUM for Dom0 and DomUs when not in focus, otherwise no prefix

No, I mean like we have it with guest_printk() today. (XEN) for Xen's
own messages, (d<N>) for ordinary domains' ones, and no prefix
exclusively for the hardware/control domain. What is best to do when
hardware and control domains are distinct I'm uncertain - I'd be
inclined to suggest that the hardware domain then stay the one without
any prefix.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jan 08 07:30:38 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 07:30:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866902.1278274 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVQWQ-0004QR-Pz; Wed, 08 Jan 2025 07:30:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866902.1278274; Wed, 08 Jan 2025 07:30:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVQWQ-0004QK-MY; Wed, 08 Jan 2025 07:30:34 +0000
Received: by outflank-mailman (input) for mailman id 866902;
 Wed, 08 Jan 2025 07:30: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
 <SRS0=kklb=UA=amd.com=Michal.Orzel@srs-se1.protection.inumbo.net>)
 id 1tVQWP-0004P2-Bt
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 07:30:33 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20618.outbound.protection.outlook.com
 [2a01:111:f403:2414::618])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 707f52cd-cd92-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 08:30:31 +0100 (CET)
Received: from SA9PR13CA0048.namprd13.prod.outlook.com (2603:10b6:806:22::23)
 by DS0PR12MB8247.namprd12.prod.outlook.com (2603:10b6:8:f5::22) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8314.17; Wed, 8 Jan
 2025 07:30:23 +0000
Received: from SA2PEPF0000150B.namprd04.prod.outlook.com
 (2603:10b6:806:22:cafe::51) by SA9PR13CA0048.outlook.office365.com
 (2603:10b6:806:22::23) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8335.10 via Frontend Transport; Wed,
 8 Jan 2025 07:30:23 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SA2PEPF0000150B.mail.protection.outlook.com (10.167.242.43) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8335.7 via Frontend Transport; Wed, 8 Jan 2025 07:30:23 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 8 Jan
 2025 01:30:23 -0600
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB06.amd.com
 (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 8 Jan
 2025 01:30:22 -0600
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Wed, 8 Jan 2025 01:30:20 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 707f52cd-cd92-11ef-a0df-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=psaGKwU/VtTE0ChO7xBhtKGWaRMRAv/KxOJGbmZxcb+N+KZPPP3sEpGe9es11aYBZFpLrCBmbleMOesP16XMEEOoLnaMMff6O5SlgjYmxVQHq97TvtpRrLplgNxwrCfx5TFGaXx3daFy1DhDt1Kvb9I4VDOgl5/zDSgyvAnZBgN/O+lXGl5F43ueV02+MXpFo/3mf3uFAOztuZmbGhnUT8ntgZpFvlu4QTZbup4fSjtKq/b6KYbh4cesK1IUQAX0cwYjxddgXKmBN/xAFplJkFIFonyyefjTuDLfFkf+sUNVH4+6xBfNpmJzQXwYPQ9kDwi0q/TBOeP2ZjufylbGtg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=VEB+HjNRmsyXnxqNPeFEYNNNC1Lmpmgus/aOsHMcIOk=;
 b=gia3ydi5Da5uAdiLrU03FKLumc+bxbAUMunlqwGDpon1yppKxHHgqHFV35GUXA+sOjbEltBb2Sfzh0gILoKqrYGcXqOLven8PJqbCT1zUtQMkLdP8R2f78d68z8tvhkKwt12U9WO/4Q+rMcqGWV2hFStaYSWIgJKuWShxVxWobyToCDyTuhpY8VJs8lAJC6w7JOl7T6mdT93vSjtt5iOY57/2nLDOEJEPY4Ih9dTpcJFELiKwe6hN5uz+V4Z+hFQs4wcikB+mC5Hu4PyDY+4Wt7aI7G1umfQp417CuJotJWyjfvRoA3fzPmmpZXW8q0i58swt/eOJ8PNys+3BmTM7w==
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=VEB+HjNRmsyXnxqNPeFEYNNNC1Lmpmgus/aOsHMcIOk=;
 b=ubZWgy5Diuz7u5OLZISEPIJrcEO5ywynWhGPFJnEReXzH0FhCSsC5h4kNecUDBl25jkDktkayEkfBSpM61+I3/xoriPwuzZd+fuUrwzaWOvnnCXOyPkgl0QGGsfjOJjl7zOpkDMM+hJzexYwRZfejnvDM8o765Ou4pwzLIv1HyA=
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: <068a9ab0-c7b8-490f-85fa-6beee8c07917@amd.com>
Date: Wed, 8 Jan 2025 08:30:14 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [for-4.20] Re: [PATCH v12 12/12] xen/arm: add cache coloring
 support for Xen image
To: Jan Beulich <jbeulich@suse.com>
CC: <xen-devel@lists.xenproject.org>, <andrea.bastoni@minervasys.tech>,
	<marco.solieri@minervasys.tech>, Stefano Stabellini <sstabellini@kernel.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>, Volodymyr Babchuk
	<Volodymyr_Babchuk@epam.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
	<roger.pau@citrix.com>, Oleksii <oleksii.kurochko@gmail.com>, Julien Grall
	<julien@xen.org>, Carlo Nonato <carlo.nonato@minervasys.tech>
References: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
 <20241213162815.9196-13-carlo.nonato@minervasys.tech>
 <dbbc649f-b705-46b5-a071-760d688aa2cd@amd.com>
 <CAG+AhRWrXAYfKXXKfp6949vNMdGDy9qWOY11SKAigJuC8oUvDw@mail.gmail.com>
 <df0f831f-378f-4fa3-ae4f-b065f2ea566d@suse.com>
 <0062e0cf-0830-4d16-942d-348e6d33a2c4@xen.org>
 <5c153764-4a1d-4233-a9d2-fa5ec0aff6ac@amd.com>
 <6a0a096b-47c2-4568-be9f-9f230bc6df23@suse.com>
Content-Language: en-US
From: Michal Orzel <michal.orzel@amd.com>
In-Reply-To: <6a0a096b-47c2-4568-be9f-9f230bc6df23@suse.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SA2PEPF0000150B:EE_|DS0PR12MB8247:EE_
X-MS-Office365-Filtering-Correlation-Id: d69ff71a-af8d-4564-c5f7-08dd2fb65067
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|36860700013|376014|7416014|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?N0RScTRDYmpzWTVoWWRLYVd6TFRHdGdiNlRGZFMwZkUydUhDb1c0cUplQVp1?=
 =?utf-8?B?cllORm5yQTRtQkU4cmpocDBzR3RMMnBWQ3Nab3lHRDl6NERsc1Y0WDc0VEpT?=
 =?utf-8?B?YXIyUktmUEVIUTBOQSswNlBTRVBRbzBOZXJUZitaY2pnbExBSUhUM1NmVXlo?=
 =?utf-8?B?ZFhHSkpQbE5menplR1VrTWxHc0JhMnhlYytXVlFKWFdNQ2xQZzBYbUVyWXpY?=
 =?utf-8?B?eGY2blVpUCtaVitOeS9pZllXS00wTkhVcFdXZzc1cjZrSDA5eDhWRUhEZzMz?=
 =?utf-8?B?Y2R2NWdmNGFUWms4VEJOZTJmYUx2ZHl4ZFg0YXkySlZOOGFHdFp6cy9zNnNz?=
 =?utf-8?B?VHdocWZMejQ5N2ZJY21mc24vb0NZS2kxUjZuU245UzRFM0dQKzE1RWhOKzg1?=
 =?utf-8?B?T01KT0J4RWFONGcyZG4rUlkyVk9UeGRNSHZtYlVaV0tONVN0ZElLTE9UaUw1?=
 =?utf-8?B?M3RnY2I2MzRGaUorNUxpNkIxOTdYRDZKWTBTRXhVSWovQXJhYStqWUgwZWR0?=
 =?utf-8?B?eEtKL1hldWRXa05CdTFTS1BRRDNVTTNkVFVlaWMyckNpbVJsSWZ3QmpTMUp2?=
 =?utf-8?B?VEVEblBlY3Bhbm1mL0xLVzZZYUFoRDBBNFlneW1Ma1NSVHNMd1hWdHdWUjJh?=
 =?utf-8?B?L1d2MThNR1BRVlVHOHJRcVJXSndreXhwTlVuUGJ6V3JVOUx1MXo5c2E1TG1L?=
 =?utf-8?B?KzhwYWdqSUJIaU9qdzVBTkwxWGFsdWVtWEp3UFNNUXBNSmV1VXNUUVFZNFZ4?=
 =?utf-8?B?N2JDdlJsd3B2VFZRMkNrclliejg0RTdvVG8xWGZkY09NYVpoZFIxQ3RVUEgr?=
 =?utf-8?B?cXhwSGd3NjNtSDEwZWtZc2x5RlhVN3o3UHRTb2xPMGtSSy9sWm5OM1pFd0JQ?=
 =?utf-8?B?RlZSV0s3MmdlSUp0V0piRTlhT2JqUmMwd1FYVGJ4aXhOcGhsVmk4ODVkVEZs?=
 =?utf-8?B?MXdUSWxkRlduZG01SU5Eb201TmtlTS9UKzZlYlcvRy9kOEt6NVZTcXVhOGNY?=
 =?utf-8?B?ckdiOHlDN0VlQXNaSUJVQklmcXNma3ZkWnFCclViemw2L1VzOFdxd3pzOGN3?=
 =?utf-8?B?bDI4TVpmc0RuOThycHhaMWlzL0dmbEtwb0Z1ZnJVa1dOZkR1ZjZKT3EwK0oy?=
 =?utf-8?B?SHpjdmE2Zzg3M0ZEOWlKRXhNQlJ2eUgvRi9OTERmQ2FXeDB0a3N6NzVFTkk4?=
 =?utf-8?B?NHNsVmJ1d1hua2N6cTUzVXhIYUl1SnJ3NVF4eFBmR0JvNERnc1h1UlN3SnRy?=
 =?utf-8?B?V3pwR0gwTFNGeGVzWC9WZjJ0RWRtV2ptUk4yWHRycVRuYnpGR202T0hCK2Vo?=
 =?utf-8?B?bFJrbXZIZGpLck9xWUQyZlhhQ2Vid3grNWFuQXNoK0tWd1BoRTRSUUkzYmV4?=
 =?utf-8?B?QjlvanFPOFpVWDVOQjcyQUpVc0laaTBvT1B6R2VOeEVKS3J1ck9iYmVGdjdS?=
 =?utf-8?B?bG9sZ3luUGd5SytiVjJVOUM3aFFBWnhYM1E1TEhsOXRDQTlWSG9DM3JYYmJ4?=
 =?utf-8?B?RXhEb3kyWmVUK3MrbkhqUEVPSlVDZTRENGpZWFZkZWd0S0l6dWFKOGp6bTY1?=
 =?utf-8?B?d250YkkyTno5eHNLTkNQTFRIdTViMFA2R2hkaWtYdktpUm9oMXpvSXRENWdM?=
 =?utf-8?B?dmhEdStZOThKYnlTYW5BcGtwYUFDVWN4dmJUanJRcGdFWUxPcUxac0lZSk8z?=
 =?utf-8?B?c2tvTnFoQVllK3pITWlyczg0bTVCVDN4WDM2d1hoVjlzTWJSL05GTjJxbnZJ?=
 =?utf-8?B?b1A4S2FKTUowRm1HVzl0YlRLOHdteDhRWkovQk1UTzg3UXVSYmJBK0QzOTJM?=
 =?utf-8?B?ZjZlelFFOSt0M081ZkR4MzM5UEMzM2pwTDhLb1I3UjhlK2ZFYmRWZHJPR2E3?=
 =?utf-8?B?V2I1V0ZqRWZkVXJuSlZqclA0V1Y1MWk2OGttQm9OUnMrRXNFenJDVk1TaWg4?=
 =?utf-8?B?eXNLRlV3eGpLSUZQT2E5a3YzZ3hoZzdlcCtQSlBIZENvQkFTOGc0T3UvY1NG?=
 =?utf-8?Q?acMu3oZXbhRayg16xq5zkQIZBNC60s=3D?=
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:(13230040)(82310400026)(36860700013)(376014)(7416014)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jan 2025 07:30:23.5228
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d69ff71a-af8d-4564-c5f7-08dd2fb65067
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:
	SA2PEPF0000150B.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB8247



On 07/01/2025 18:01, Jan Beulich wrote:
> 
> 
> On 07.01.2025 17:51, Michal Orzel wrote:
>>
>>
>> On 07/01/2025 17:42, Julien Grall wrote:
>>>
>>>
>>> Hi,
>>>
>>> On 16/12/2024 14:36, Jan Beulich wrote:
>>>> On 16.12.2024 15:28, Carlo Nonato wrote:
>>>>> On Mon, Dec 16, 2024 at 2:56 PM Michal Orzel <michal.orzel@amd.com> wrote:
>>>>>> On 13/12/2024 17:28, Carlo Nonato wrote:
>>>>>>> --- a/xen/arch/arm/arm64/mmu/mm.c
>>>>>>> +++ b/xen/arch/arm/arm64/mmu/mm.c
>>>>>>> @@ -1,6 +1,7 @@
>>>>>>>   /* SPDX-License-Identifier: GPL-2.0-only */
>>>>>>>
>>>>>>>   #include <xen/init.h>
>>>>>>> +#include <xen/llc-coloring.h>
>>>>>>>   #include <xen/mm.h>
>>>>>>>   #include <xen/pfn.h>
>>>>>>>
>>>>>>> @@ -138,8 +139,36 @@ void update_boot_mapping(bool enable)
>>>>>>>   }
>>>>>>>
>>>>>>>   extern void switch_ttbr_id(uint64_t ttbr);
>>>>>>> +extern void relocate_xen(uint64_t ttbr, void *src, void *dst, size_t len);
>>>>>>>
>>>>>>>   typedef void (switch_ttbr_fn)(uint64_t ttbr);
>>>>>>> +typedef void (relocate_xen_fn)(uint64_t ttbr, void *src, void *dst, size_t len);
>>>>>>> +
>>>>>>> +void __init relocate_and_switch_ttbr(uint64_t ttbr) {
>>>>>> CODING_STYLE: { needs to be on its own line
>>>>>>
>>>>>> Also, this function is only executed in case of LLC coloring, so shouldn't it
>>>>>> be #ifdef protected.
>>>>>
>>>>> Here and in other places (patch #8) I'm relying on DCE to remove functions
>>>>> that are not called. This was a suggestion from Jan in that patch. Can we
>>>>> adopt the same here?
>>>>
>>>> Yet how would the compiler spot that the function is unused? That would only
>>>> work with LTO / WPO. DCE (as I did suggest elsewhere) requires the functions
>>>> in question to be static (allowing the compiler to see enough of the whole
>>>> picture).
>>>
>>> Sorry for the late answer. I was away with limited e-mail access. While
>>> looking what was committing recently, I noticed that a dummy function
>>> was introduced:
>>>
>>> void __init relocate_and_switch_ttbr(uint64_t ttbr) {}
>>>
>>> If a function is not supposed to be called, then it should contain a
>>> BUG_ON() to catch any misusage. Otherwise, this is a recipe for
>>> disaster. In this case, it would not be trivial to notice the TTBR was
>>> not switched...
>>>
>>> That said I would have actually considered to remove the empty stub. I
>>> am a bit surprised that DCE wouldn't work in this case because the call
>>> is protected with "if ( llc_coloring_enabled )". When cache coloring is
>>> not enabled, this would turn to an "if ( false )" and therefore all the
>>> code should be removed. What did I miss?
>>>
>>> Note that this is what we already rely on for arm32 because there is no
>>> stub... So if this is problem then we definitely need to fix it on arm32
>>> as well...
>>>
>>> IOW, we either introduce a stub (including the BUG_ON) for both arm32
>>> and arm64 in the header or we remove the stub completely.
>>>
>>> Marco, Michal, can you have a look? Ideally, this should be fixed for 4.20.
>> I did a test with GCC 13.2 and I can compile it fine with stub removed. That said,
>> I'm not a compiler expert and I'm not sure if this behavior stays the same with different
>> compiler options/optimizations. So it's more like a question to Jan. I'm happy either way.
> 
> We use the same (if(...) func();) in various places, relying on said DCEing
> of the call when the condition is compile-time-false. I see no reason why
> it couldn't be used here as well.
Well, in original patch you wrote:
"Yet how would the compiler spot that the function is unused? That would only work
with LTO / WPO. DCE (as I did suggest elsewhere) requires the functions in question
to be static (allowing the compiler to see enough of the whole picture)."

That's why I wanted to confirm with you before sending a patch to remove the stub.
At first place I thought we rely on DCE only for:
a) static functions
b) in construct like if ( false && foo() ), not if ( false ) { foo () }

That said, relocate_and_switch_ttbr() is exactly the same as domain_set_llc_colors() for which
we don't have a stub and rely on DCE.

~Michal



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 07:32:49 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 07:32:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866909.1278284 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVQYb-00059w-4a; Wed, 08 Jan 2025 07:32:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866909.1278284; Wed, 08 Jan 2025 07: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 <xen-devel-bounces@lists.xenproject.org>)
	id 1tVQYb-00059p-1g; Wed, 08 Jan 2025 07:32:49 +0000
Received: by outflank-mailman (input) for mailman id 866909;
 Wed, 08 Jan 2025 07: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 <SRS0=svEr=UA=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVQYa-00059I-G6
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 07:32:48 +0000
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com
 [2a00:1450:4864:20::435])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c1c8c68f-cd92-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 08:32:47 +0100 (CET)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3862d16b4f5so337991f8f.0
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 23:32:47 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1fa2bdfbsm51448705f8f.102.2025.01.07.23.32.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 23:32:46 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c1c8c68f-cd92-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736321567; x=1736926367; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=pkcb3+a5dJ29hweFXCoRH2W/v3k+pj4cykKr3EYZ95k=;
        b=R3WRGpNjGIfch7Xzqo4ekdGDJlR3eQk7vgn5DNbAsa9W2+p9lyWjKKh3bLwXZrXh+4
         2LHFevgOFRhyKZI/Olp8LZwwhCNL8dGQDoCuSAcptwJYeDfVz0goB68U5t69LVHsSj10
         tMHNyvttq/NDjn+9TgEYFv8ygbLOvDxoQo3ePmbXzU6J4m0aIMm2WvP/rxg4zR8snlbP
         bhWl3trD3uBI1kk3kRatP5oPjsOThOLdQCoIoJ3U5Mql/xklZ5/N1DfJWXuVDtLHag/z
         rSZozeeSoOKTqI3Q9TEh3nA032xeRC+ghlCyvzz4gvxzP1RM1N7Oz/JZ1H8ELSyFePLf
         UzVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736321567; x=1736926367;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=pkcb3+a5dJ29hweFXCoRH2W/v3k+pj4cykKr3EYZ95k=;
        b=thIQAIweWqPgqufQaAbd8WtRohzif9shrvH1apHjFA9oTDwxZ5LlDp2fR/8815GJre
         XrecORHpSOsFK6ipqCJ7SKu9+WkqPs9Xi6bOty+6ZdqbfBwwinjy0iDE+rEetYBwYKje
         UWviaf9tuLwpioJ5oX0u0BnXG3sOCvXtvJfgIX6xi50TMJEPWndVfZZSEYL4STixr5C6
         YtAMFdo0T/I6aEC5eIvXeay5ySPkoZb7F+3TSkfhLUKkrR1HyOD7sunRm0twpmkJs6ap
         T30NZW0oPHcshc0ZKJIB00m/0DsWPOeS7MM9dnD56E7Q61LmFIveKfZweYzLp/g/yV9S
         HBiQ==
X-Gm-Message-State: AOJu0YwnWd/foXzPxm9/r3ltvo4OLvpJCiS5/PWKMG8OnEWKQj6cuPaH
	8S8PrRnDjVLCMNPaupmEtIntfHc6sMVOoYsVNK7UjXFWa8iXADodc16B2PFKxw==
X-Gm-Gg: ASbGnculIOdauBBlDaZXpORLHW1NKrym9pQvmqfflCBbbylRMk6ND+2/WOFEZUcxuqP
	cJGBbC3suvkCrHRhgF6YBoRjBr5IaaFJTPJLxb4ohX1WUmsx/hcbUbGTiwTqBsPPZeUfIJVdsfB
	76T9jh9uFhClmEgXbmAgTZLAw+S1YEtFEGn1aUphv4xYp+GNLkWiaNHZ5nwXimacbm0r16eS+n0
	arz9RlSKN/pE8h8YOnkQ+MiUHZVsqwY+WlwchyRLLDBQ4R+2E5fvm6+F+NqNTFEl1O1QkvYaaV8
	R1Kyd7/sb4Qw2P/qiSttRpnDAaZXCCY0ePOSZNYMMA==
X-Google-Smtp-Source: AGHT+IExbjFXqZYAf4qQCiviOiPO6MJjjSeFA8OHrLDAA3gHukLDPKYu4JdTxgj1iUvjaU+nw+9cwg==
X-Received: by 2002:a5d:64ac:0:b0:385:ef14:3b55 with SMTP id ffacd0b85a97d-38a85f4eecdmr1385607f8f.19.1736321566661;
        Tue, 07 Jan 2025 23:32:46 -0800 (PST)
Message-ID: <736dbd5d-62f7-41aa-a24a-2f08cc2f21fe@suse.com>
Date: Wed, 8 Jan 2025 08:32:44 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [for-4.20] Re: [PATCH v12 12/12] xen/arm: add cache coloring
 support for Xen image
To: Andrea Bastoni <andrea.bastoni@minervasys.tech>
Cc: xen-devel@lists.xenproject.org, marco.solieri@minervasys.tech,
 Stefano Stabellini <sstabellini@kernel.org>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Oleksii <oleksii.kurochko@gmail.com>, Julien Grall <julien@xen.org>,
 Carlo Nonato <carlo.nonato@minervasys.tech>,
 Michal Orzel <michal.orzel@amd.com>
References: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
 <20241213162815.9196-13-carlo.nonato@minervasys.tech>
 <dbbc649f-b705-46b5-a071-760d688aa2cd@amd.com>
 <CAG+AhRWrXAYfKXXKfp6949vNMdGDy9qWOY11SKAigJuC8oUvDw@mail.gmail.com>
 <df0f831f-378f-4fa3-ae4f-b065f2ea566d@suse.com>
 <0062e0cf-0830-4d16-942d-348e6d33a2c4@xen.org>
 <5c153764-4a1d-4233-a9d2-fa5ec0aff6ac@amd.com>
 <6a0a096b-47c2-4568-be9f-9f230bc6df23@suse.com>
 <0231325c-13f2-4b0b-a928-4ba249e4c560@minervasys.tech>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <0231325c-13f2-4b0b-a928-4ba249e4c560@minervasys.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 07.01.2025 18:13, Andrea Bastoni wrote:
> On 07/01/2025 18:01, Jan Beulich wrote:
>> On 07.01.2025 17:51, Michal Orzel wrote:
>>> On 07/01/2025 17:42, Julien Grall wrote:
>>>> On 16/12/2024 14:36, Jan Beulich wrote:
>>>>> On 16.12.2024 15:28, Carlo Nonato wrote:
>>>>>> On Mon, Dec 16, 2024 at 2:56 PM Michal Orzel <michal.orzel@amd.com> wrote:
>>>>>>> On 13/12/2024 17:28, Carlo Nonato wrote:
>>>>>>>> --- a/xen/arch/arm/arm64/mmu/mm.c
>>>>>>>> +++ b/xen/arch/arm/arm64/mmu/mm.c
>>>>>>>> @@ -1,6 +1,7 @@
>>>>>>>>   /* SPDX-License-Identifier: GPL-2.0-only */
>>>>>>>>
>>>>>>>>   #include <xen/init.h>
>>>>>>>> +#include <xen/llc-coloring.h>
>>>>>>>>   #include <xen/mm.h>
>>>>>>>>   #include <xen/pfn.h>
>>>>>>>>
>>>>>>>> @@ -138,8 +139,36 @@ void update_boot_mapping(bool enable)
>>>>>>>>   }
>>>>>>>>
>>>>>>>>   extern void switch_ttbr_id(uint64_t ttbr);
>>>>>>>> +extern void relocate_xen(uint64_t ttbr, void *src, void *dst, size_t len);
>>>>>>>>
>>>>>>>>   typedef void (switch_ttbr_fn)(uint64_t ttbr);
>>>>>>>> +typedef void (relocate_xen_fn)(uint64_t ttbr, void *src, void *dst, size_t len);
>>>>>>>> +
>>>>>>>> +void __init relocate_and_switch_ttbr(uint64_t ttbr) {
>>>>>>> CODING_STYLE: { needs to be on its own line
>>>>>>>
>>>>>>> Also, this function is only executed in case of LLC coloring, so shouldn't it
>>>>>>> be #ifdef protected.
>>>>>>
>>>>>> Here and in other places (patch #8) I'm relying on DCE to remove functions
>>>>>> that are not called. This was a suggestion from Jan in that patch. Can we
>>>>>> adopt the same here?
>>>>>
>>>>> Yet how would the compiler spot that the function is unused? That would only
>>>>> work with LTO / WPO. DCE (as I did suggest elsewhere) requires the functions
>>>>> in question to be static (allowing the compiler to see enough of the whole
>>>>> picture).
>>>>
>>>> Sorry for the late answer. I was away with limited e-mail access. While
>>>> looking what was committing recently, I noticed that a dummy function
>>>> was introduced:
>>>>
>>>> void __init relocate_and_switch_ttbr(uint64_t ttbr) {}
>>>>
>>>> If a function is not supposed to be called, then it should contain a
>>>> BUG_ON() to catch any misusage. Otherwise, this is a recipe for
>>>> disaster. In this case, it would not be trivial to notice the TTBR was
>>>> not switched...
>>>>
>>>> That said I would have actually considered to remove the empty stub. I
>>>> am a bit surprised that DCE wouldn't work in this case because the call
>>>> is protected with "if ( llc_coloring_enabled )". When cache coloring is
>>>> not enabled, this would turn to an "if ( false )" and therefore all the
>>>> code should be removed. What did I miss?
>>>>
>>>> Note that this is what we already rely on for arm32 because there is no
>>>> stub... So if this is problem then we definitely need to fix it on arm32
>>>> as well...
>>>>
>>>> IOW, we either introduce a stub (including the BUG_ON) for both arm32
>>>> and arm64 in the header or we remove the stub completely.
>>>>
>>>> Marco, Michal, can you have a look? Ideally, this should be fixed for 4.20.
>>> I did a test with GCC 13.2 and I can compile it fine with stub removed. That said,
>>> I'm not a compiler expert and I'm not sure if this behavior stays the same with different
>>> compiler options/optimizations. So it's more like a question to Jan. I'm happy either way.
>>
>> We use the same (if(...) func();) in various places, relying on said DCEing
>> of the call when the condition is compile-time-false. I see no reason why
>> it couldn't be used here as well.
> 
> IIRC the point was that his function is extern and DCE as used in other places doesn't necessarily work.

But the called function being extern _is_ the common pattern where merely a
declaration needs to be visible, but no definition (and we specifically have
a Misra deviation to cover this case). If the function was static, no further
provisions would be necessary at all, as then the compiler can DCE not only
the function call, but also the function itself, without any further help by
us.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jan 08 07:35:09 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 07:35:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866918.1278293 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVQaq-0005lr-Hp; Wed, 08 Jan 2025 07:35:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866918.1278293; Wed, 08 Jan 2025 07:35:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVQaq-0005lk-FE; Wed, 08 Jan 2025 07:35:08 +0000
Received: by outflank-mailman (input) for mailman id 866918;
 Wed, 08 Jan 2025 07:35:07 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=svEr=UA=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVQap-0005le-89
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 07:35:07 +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 1410f2f4-cd93-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 08:35:05 +0100 (CET)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-385e87b25f0so308189f8f.0
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 23:35: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
 5b1f17b1804b1-436e2da7768sm11253425e9.5.2025.01.07.23.35.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jan 2025 23:35:04 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1410f2f4-cd93-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736321705; x=1736926505; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=78KiMuat33LFSrcDZWhTDDvY0TKnVkuVcR8OsF00lXU=;
        b=AHZ03rcOXVjVfhdNMNiEgCTpOqS2Pt4pmZh2gc5jboVd8pnT0e6mmBW79R+BqjWVv3
         TKhQ4SjoHHKjSxSjYp+jJp8yOlo6weuPBgoA03K3U9+8XEXUcbmSUozSLsrW87+DtjLr
         3W+261k2V/UNXy8mrxoRQxF5ozb3mXPAjJRT/DyRSAzbze6WM2/+Ehk+8j/j62rNq8R0
         qgns3XNFQfdz20gshpqwC17orL91/NEHP0rH/69m8reZ4OcQe9hQ2m8fqfqqMslSkam9
         90QUcYNmWVR45esPhFnlG9OIUFnBhzCg9CosMTqTbWu/0NxjxSzN2AIjB0bQKocWRwcJ
         n0Nw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736321705; x=1736926505;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=78KiMuat33LFSrcDZWhTDDvY0TKnVkuVcR8OsF00lXU=;
        b=tQnGCdiyDN7hJB7a56A9d3X8VHU5vPlfi9QjU2C71lcZwV5wCn91KOsliVsZXDAbvs
         GqMdkqO7qLyWG3ubY4puBGBuNCENby7YfitrvHr5fZraiDPH1MTmsi+sGwtUhSd0ehmE
         1SVqZKT8DtF0IYKYLLxj35d6RsT6HIV2SPwK3Vu6jbvor6KoLCAqYAec85lFycnXtaDN
         NPHCr1ZNHuiy2yDG8wLWDNV+olWwHPJWCkc784IhENCzQ5KVuStyLmblU0nC7FFkBhGE
         npijc63klTNUW0qYvAx6OMW7uoBmNtgqr4/3OXI+Yo3wy3PAANOn5iq5OCOBmyJQL+dj
         kk6g==
X-Gm-Message-State: AOJu0Yz18eUAvdK/f3cVBkIc7nfU9TkvQeB2XoZf1zumv23tx1LAJcJJ
	i9NaNUPKo+6pTI2G2ru5ZyUSr2kRnosohN3ldRMLqgn8OMhg0ngLtYinRbDlmA==
X-Gm-Gg: ASbGncvPic+z6mDrQXUpZqrMt3cmh8GRiPmM8bzSvCnK3kUvnztEWLiVzq2yYjwe2cg
	sK7Tj5uUSk5m+LGE8k5Nnh04TrWpEoGmEo2JFdQVDxD4QE/IekohkCQPhw5VR74YmHTDPFA8mMI
	uLRlT6z6SLb0nwTc8FGKA0p+q34P0YNms+jUvQrRZ6f55fHC6wriiJQvPi6kh5/ySLzAfi7v3ij
	jv3Y+wnng+2aS3dHw7mLtz/gz298W18VpCWvat9SmJm630rD/+gU10fqMqTU+/WYtizN0vEdd41
	bZMS3aSscBlSQipgeQLs8k++NKXX2BzJQq3wLPUSXA==
X-Google-Smtp-Source: AGHT+IGH1kXFgHcRYK0Uq4o4IDYFmQShv2jNRrIvtCQ/op7D2PHvxMwnnfMscBuq0iYl858X9VbQjw==
X-Received: by 2002:a05:6000:1787:b0:386:4a16:dadb with SMTP id ffacd0b85a97d-38a7912b5f7mr4859982f8f.11.1736321704741;
        Tue, 07 Jan 2025 23:35:04 -0800 (PST)
Message-ID: <d8b46f8d-b440-4d9f-a5f6-bf94b4a998b1@suse.com>
Date: Wed, 8 Jan 2025 08:35:02 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [for-4.20] Re: [PATCH v12 12/12] xen/arm: add cache coloring
 support for Xen image
To: Michal Orzel <michal.orzel@amd.com>
Cc: xen-devel@lists.xenproject.org, andrea.bastoni@minervasys.tech,
 marco.solieri@minervasys.tech, Stefano Stabellini <sstabellini@kernel.org>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Oleksii <oleksii.kurochko@gmail.com>, Julien Grall <julien@xen.org>,
 Carlo Nonato <carlo.nonato@minervasys.tech>
References: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
 <20241213162815.9196-13-carlo.nonato@minervasys.tech>
 <dbbc649f-b705-46b5-a071-760d688aa2cd@amd.com>
 <CAG+AhRWrXAYfKXXKfp6949vNMdGDy9qWOY11SKAigJuC8oUvDw@mail.gmail.com>
 <df0f831f-378f-4fa3-ae4f-b065f2ea566d@suse.com>
 <0062e0cf-0830-4d16-942d-348e6d33a2c4@xen.org>
 <5c153764-4a1d-4233-a9d2-fa5ec0aff6ac@amd.com>
 <6a0a096b-47c2-4568-be9f-9f230bc6df23@suse.com>
 <068a9ab0-c7b8-490f-85fa-6beee8c07917@amd.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <068a9ab0-c7b8-490f-85fa-6beee8c07917@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 08.01.2025 08:30, Michal Orzel wrote:
> 
> 
> On 07/01/2025 18:01, Jan Beulich wrote:
>>
>>
>> On 07.01.2025 17:51, Michal Orzel wrote:
>>>
>>>
>>> On 07/01/2025 17:42, Julien Grall wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> On 16/12/2024 14:36, Jan Beulich wrote:
>>>>> On 16.12.2024 15:28, Carlo Nonato wrote:
>>>>>> On Mon, Dec 16, 2024 at 2:56 PM Michal Orzel <michal.orzel@amd.com> wrote:
>>>>>>> On 13/12/2024 17:28, Carlo Nonato wrote:
>>>>>>>> --- a/xen/arch/arm/arm64/mmu/mm.c
>>>>>>>> +++ b/xen/arch/arm/arm64/mmu/mm.c
>>>>>>>> @@ -1,6 +1,7 @@
>>>>>>>>   /* SPDX-License-Identifier: GPL-2.0-only */
>>>>>>>>
>>>>>>>>   #include <xen/init.h>
>>>>>>>> +#include <xen/llc-coloring.h>
>>>>>>>>   #include <xen/mm.h>
>>>>>>>>   #include <xen/pfn.h>
>>>>>>>>
>>>>>>>> @@ -138,8 +139,36 @@ void update_boot_mapping(bool enable)
>>>>>>>>   }
>>>>>>>>
>>>>>>>>   extern void switch_ttbr_id(uint64_t ttbr);
>>>>>>>> +extern void relocate_xen(uint64_t ttbr, void *src, void *dst, size_t len);
>>>>>>>>
>>>>>>>>   typedef void (switch_ttbr_fn)(uint64_t ttbr);
>>>>>>>> +typedef void (relocate_xen_fn)(uint64_t ttbr, void *src, void *dst, size_t len);
>>>>>>>> +
>>>>>>>> +void __init relocate_and_switch_ttbr(uint64_t ttbr) {
>>>>>>> CODING_STYLE: { needs to be on its own line
>>>>>>>
>>>>>>> Also, this function is only executed in case of LLC coloring, so shouldn't it
>>>>>>> be #ifdef protected.
>>>>>>
>>>>>> Here and in other places (patch #8) I'm relying on DCE to remove functions
>>>>>> that are not called. This was a suggestion from Jan in that patch. Can we
>>>>>> adopt the same here?
>>>>>
>>>>> Yet how would the compiler spot that the function is unused? That would only
>>>>> work with LTO / WPO. DCE (as I did suggest elsewhere) requires the functions
>>>>> in question to be static (allowing the compiler to see enough of the whole
>>>>> picture).
>>>>
>>>> Sorry for the late answer. I was away with limited e-mail access. While
>>>> looking what was committing recently, I noticed that a dummy function
>>>> was introduced:
>>>>
>>>> void __init relocate_and_switch_ttbr(uint64_t ttbr) {}
>>>>
>>>> If a function is not supposed to be called, then it should contain a
>>>> BUG_ON() to catch any misusage. Otherwise, this is a recipe for
>>>> disaster. In this case, it would not be trivial to notice the TTBR was
>>>> not switched...
>>>>
>>>> That said I would have actually considered to remove the empty stub. I
>>>> am a bit surprised that DCE wouldn't work in this case because the call
>>>> is protected with "if ( llc_coloring_enabled )". When cache coloring is
>>>> not enabled, this would turn to an "if ( false )" and therefore all the
>>>> code should be removed. What did I miss?
>>>>
>>>> Note that this is what we already rely on for arm32 because there is no
>>>> stub... So if this is problem then we definitely need to fix it on arm32
>>>> as well...
>>>>
>>>> IOW, we either introduce a stub (including the BUG_ON) for both arm32
>>>> and arm64 in the header or we remove the stub completely.
>>>>
>>>> Marco, Michal, can you have a look? Ideally, this should be fixed for 4.20.
>>> I did a test with GCC 13.2 and I can compile it fine with stub removed. That said,
>>> I'm not a compiler expert and I'm not sure if this behavior stays the same with different
>>> compiler options/optimizations. So it's more like a question to Jan. I'm happy either way.
>>
>> We use the same (if(...) func();) in various places, relying on said DCEing
>> of the call when the condition is compile-time-false. I see no reason why
>> it couldn't be used here as well.
> Well, in original patch you wrote:
> "Yet how would the compiler spot that the function is unused? That would only work
> with LTO / WPO. DCE (as I did suggest elsewhere) requires the functions in question
> to be static (allowing the compiler to see enough of the whole picture)."

That must have been a comment on the function itself, not on any of the calls
to it.

> That's why I wanted to confirm with you before sending a patch to remove the stub.
> At first place I thought we rely on DCE only for:
> a) static functions
> b) in construct like if ( false && foo() ), not if ( false ) { foo () }

We leverage both patterns.

Jan

> That said, relocate_and_switch_ttbr() is exactly the same as domain_set_llc_colors() for which
> we don't have a stub and rely on DCE.
> 
> ~Michal
> 



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 07:51:45 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 07:51:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866924.1278304 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVQqm-0000NY-Ti; Wed, 08 Jan 2025 07:51:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866924.1278304; Wed, 08 Jan 2025 07:51:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVQqm-0000NR-Pr; Wed, 08 Jan 2025 07:51:36 +0000
Received: by outflank-mailman (input) for mailman id 866924;
 Wed, 08 Jan 2025 07:51:35 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=HByp=UA=arm.com=Bertrand.Marquis@srs-se1.protection.inumbo.net>)
 id 1tVQql-0000NL-5F
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 07:51:35 +0000
Received: from EUR05-DB8-obe.outbound.protection.outlook.com
 (mail-db8eur05on20627.outbound.protection.outlook.com
 [2a01:111:f403:2614::627])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 604855ab-cd95-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 08:51:32 +0100 (CET)
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by AS1PR08MB7452.eurprd08.prod.outlook.com (2603:10a6:20b:4dc::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8335.10; Wed, 8 Jan
 2025 07:51:29 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a%4]) with mapi id 15.20.8335.011; Wed, 8 Jan 2025
 07:51:29 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 604855ab-cd95-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=SmRfwMrZI5ARI4BLkRwiXzKJExSFwGAG0Bv2L8Wa7+xfDPHayjPgWdNHj7OozELz2DeMqRmFqVajPWuZqAG2wx0QrfpEmG1lH6LXLOl48YN4TjRXOXIIqJwLYr5YesXSv77sU2HcWntT/qfd6k/vf/lN1Snn4PbGwHzSiGOBxL+4ShE8QR8trImI0K8HJwBgN//4Yzi92nKpAuoDUoRxhDvEBbAz82LEx1t/QV7vjwxxO1sRGQb8l9FOFFTgqVjH5abAJ7t47O6mC4MT7g+gKs4p0AV67/6BVnqkrMfayI1TFEwRMC1HChdDdonp4phg1BRTi2AQrJI4V+Ngz3QjrQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=MlXOjQrCby1QP/I8MWOWzF5fpShAa0rDjD9dQB5xkVs=;
 b=FsU88y19Hz52bGo++kjKjExgkGg30apbQAwjojSLllkf5jQK7t3Oa3oe+Tjf27hWWK0Pq/vy6vvBsO+1TBsQJJn7KOVAD/0cbIkMSjclGa80J6gxv7gUNQMXUo/Ul0ps5NHS74p8qJYmgSqpD55U6or95tSVGer+BQhyGPaW/e3zmRH0AlULHkhrzL8zV5O9zdYSQ9HDQacnE7euQmRJsj1Gl7+z+mV+08RM1qT3wPiZI+uu7cWjyoyS9X5hEqCCHlYF0Oi42ISA+Hqc9wWpVQ8DpBG75DlMIYPyXUzXMDjw/qubuK0hkm5fN/8PWhlxV1clQ70vYEWCZJOcQCuYyw==
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=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=MlXOjQrCby1QP/I8MWOWzF5fpShAa0rDjD9dQB5xkVs=;
 b=g1zdKaYdwda8IPcbD0LDgzi+M4oShyDpdceSdtWZWh7M6Wukp8exNbevNVxcBNNLPuzYdDdzZZuJ3+Ib6yQeoB8qAC+KkJONthvTPNpQspg+9cN9U9NFQc73YWbp8faLM4XFFVq5mJYKCzgFyCMTFe14XhXhFRW31B5rqFpHM5g=
From: Bertrand Marquis <Bertrand.Marquis@arm.com>
To: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
CC: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Michal
 Orzel <michal.orzel@amd.com>, Stefano Stabellini <sstabellini@kernel.org>,
	Artem Mygaiev <artem_mygaiev@epam.com>, Jason Andryuk <jason.andryuk@amd.com>
Subject: Re: [PATCH v3] docs: fusa: Add dom0less domain configuration
 requirements
Thread-Topic: [PATCH v3] docs: fusa: Add dom0less domain configuration
 requirements
Thread-Index: AQHbUgS4JJcMvJVd5kOG9/I5q9pAibMMoCqA
Date: Wed, 8 Jan 2025 07:51:29 +0000
Message-ID: <7402DB1D-61F6-467C-89BD-6985A6817362@arm.com>
References: <20241219105640.3294591-1-ayan.kumar.halder@amd.com>
In-Reply-To: <20241219105640.3294591-1-ayan.kumar.halder@amd.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.200.121)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DB9PR08MB6588:EE_|AS1PR08MB7452:EE_
x-ms-office365-filtering-correlation-id: 441c45d6-a3bc-4389-425c-08dd2fb94304
x-checkrecipientrouted: true
nodisclaimer: true
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700018;
x-microsoft-antispam-message-info:
 =?us-ascii?Q?7ifo0ng1CuXyEnjLHB4kvAHgbyZG6eidIOezs5RRHbnVSSY8ezaZhcZ/UTYs?=
 =?us-ascii?Q?PFfpoPkdrVCoOeMKCkfbDgQMJeicuEFTwRSg3Cc6A3EAUunvogQfNgb0U822?=
 =?us-ascii?Q?5PqAwXAXXHgxfjKk67sCIJkfWJYJM4d6at5iOqBLeUChXyp4VZrE5pMUySr5?=
 =?us-ascii?Q?HFbk9rbJt8c/2+kV6bAsdwJwY3uPMVTfszFqkGSq93rjS0Rnih6M1uGuKdGQ?=
 =?us-ascii?Q?igbLHLNi3b+GWbHTWsUW4kjZcVJTA35lTblsWTKrPmgkhfWgahJd+0ruAdGY?=
 =?us-ascii?Q?wYH1+YMEobnMXBbC6yVEOYbBKCPbM9AHyxWu4P8k7zlVikLhKkMX/IMXPfPZ?=
 =?us-ascii?Q?d9l9OhuBCO72woT7X73u5oJTR41uEXMU4kh13G54avGTMVcHDclIEdb9VfWz?=
 =?us-ascii?Q?lgZmUA36OF0WHZrA2DCVsIHb1Gz/QD3E3F+nt4kerpiNSB2gq1ibIeTu2YMY?=
 =?us-ascii?Q?hvJxjHMTvkMof9tvdkG7mTZ4CgfUD4c+GHTjr1n7IihJKTGmVr+hqbyKKher?=
 =?us-ascii?Q?a9lKmf9m2V1yVmIBaohr/oDsfAOeB0S30PHlQca2J7ClH0AX2Rza3j2nXY91?=
 =?us-ascii?Q?H6ideUsL/iUPRUTwwxBtycA8QcwubPJzViGtW11jDP6HbKbQreBdE1lqnUEq?=
 =?us-ascii?Q?YD0phaoxi+HDTUfLBvIAfr7spjRAcXctuUDFotvDIh1OLERLi/XZJ7BbQOuL?=
 =?us-ascii?Q?LtMRtS9prO1MzGeh3rbny2OOdJlytkIyApctfecb+uraYd+rIUsOLkf86vV7?=
 =?us-ascii?Q?qmn4iykYEHMPXctr8DbPsXrZlVNdvLqGzL/Wu3bUXYOujQC/NrZRoG2hwu3+?=
 =?us-ascii?Q?wSHvnnG2MkeYnCsmy2GI47L5YybNDpwfMduu3hOXsTfd/TbFu0J5GUrCo6Tn?=
 =?us-ascii?Q?Nf24XiI2cmrZw01lBJLrgjKS0bhg7IStxFm93SGLXulfX2T/tvL9eM1h4NQg?=
 =?us-ascii?Q?jJU9NVWEtG2Lc5CyfLjQhTYSsM8b3ZlG4kpFn4LdExXIJo+Jq5aMBpk2+vBO?=
 =?us-ascii?Q?CuTVEgJkhjVkLFrNK063bu5MLqrhJB5CcxPx5b7lWuh9zQgdMgvAnmH+G8Zw?=
 =?us-ascii?Q?B7smVEmyqFLg/8eIWSbEwQ6XZcHMO7kSn0UXNtcA8KQdGQ3kolpSZsQTeXms?=
 =?us-ascii?Q?lOjTruW5kH8X8QCLhldTaOxZuZBaqfnwDX9GwaDPATIwifu2A9bGPoowpHWM?=
 =?us-ascii?Q?lN5FYsyYgDcJ/syeGmZnuPwrFKovOf6U3qeOBBX3YWbiyrXWSJ0I1EJORC6X?=
 =?us-ascii?Q?YnT5Ij7G8lbAppOnkMNBbx+nK77N1Lijh/63+P3PlqUGNDGJn17lvPmg431e?=
 =?us-ascii?Q?yEZKmWEIlfHgDQSDg3qQ6XH4WixZ4uD3yu7L0wpFAEM40+b3c9J1ytWwW+oB?=
 =?us-ascii?Q?IdXa7bvQRKiocnk2XtdfK5lyyFqKcL5yvZxDpBs6E4PB1giKYg=3D=3D?=
x-forefront-antispam-report:
 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:(13230040)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?4XzJOj9YhF6o7wYh1wkzeaD7ScsUe2Gh5GMp5IwdngTaIMGk436BBBfTvDZw?=
 =?us-ascii?Q?BivTeyQtGgHCwZhUkzw3njrQVtuA1z73yAgFiiUHxTPxnoJrO+wgPF4pZ8yR?=
 =?us-ascii?Q?cfzVVq7WTCUIXtCW5wNzLbs7hm3x678T5+ugkvkPMYj8eUX586X/MWQnwaoZ?=
 =?us-ascii?Q?5Zp1OrEP06QIskHSW+/ZbPKl/FXVZ3gkYE6Cuzic7MwSdq92xWWXTTHRIPA/?=
 =?us-ascii?Q?w0dxwLa0dgPULFgzNNbFlOsuq3r/h2A40FktG3VN56Xc2sDbd0otmfvekN9j?=
 =?us-ascii?Q?wTUBtTxGX02fr5gzcI5D2bPt5rCg6N2f0D+7AzAKFvkFFCNlEr1HSx7MxLlz?=
 =?us-ascii?Q?VBab+lAemBMrRM1EDq3k3Bsf60UBZf7LoNUVs2zYALJYHwjakPjNyPOgVXdY?=
 =?us-ascii?Q?UuPV09tWSlxSaUdusr4EzL3n+V4MnKYXRngv2JEiORXpblDK7DVDgmZ/iVg1?=
 =?us-ascii?Q?K4ScTzznkksp1kiWkhHx55tIUPQ5qmwl2VFu0X8ieKcICj7TqqHKgRRcqTWn?=
 =?us-ascii?Q?irN2TFcDGazEMzI/p5P7euti8S4iY+hao6DzFYVLipti3BUL+mzP64F3JKhg?=
 =?us-ascii?Q?xXDCEEi3XRAuzx1D2Ujge2gSAreI4NjdkfgLsY4Unjbuci3K9GMNuydD0TZH?=
 =?us-ascii?Q?VQYATiGms5TW3Gf6pP4DrUD28ihsHDgbwbl3QVp7/z5Xd3wpIlyzAYSAqJXE?=
 =?us-ascii?Q?LL6bZFGbdFZYXI9pa9S8vvDupsP3Yd4umxSkb/Eg834Cugvd1tmbtJuYxHwa?=
 =?us-ascii?Q?eJe90b7Pbt2XXQ7A9KmoQbgfAUPROGiVpKkhIjLo2fPmLe0owVDeW7P9Csh7?=
 =?us-ascii?Q?NZ8Q86DztmhQv7f7vHzVsGs11/Qw5znNLY8BIsdQAx4kQ6cKHg06ZV5uM4xC?=
 =?us-ascii?Q?0GTc+xzzdGrbk5yq++3LCKxhWFa+IDmrfpiQ0JiP61uZ68n9n6iXcwmSXeGo?=
 =?us-ascii?Q?jl8cclw1h5fy6Py3lBSacS4JZpOngd4KJNkgBiYG6XrYuWhhjpy+9WJibCRh?=
 =?us-ascii?Q?Gx2VKu3DzUNjt+N8eustgBfbEO7G0wD5SF0gYgbLuZIBdSc2ckG1WONKFLoK?=
 =?us-ascii?Q?Bd9/jWMQjrshRPaQ4s9/Gz35lKf5AdB3jN32fiJBFC5iDVlUDJwHOj4jLHn1?=
 =?us-ascii?Q?NP4gn5xyeTPZ8Rn1CHp6rUx48pqubfi9k4CLpFOGGmHxER22+c7VATAy9KLA?=
 =?us-ascii?Q?WqwZAlfr4/xhTHG4W6+RaK4djyJCpjlxzuVoDIYlCLq24ESNutqoZsbsFyag?=
 =?us-ascii?Q?GnvvjvxvEqstCMJz/rgAYmzUy+AZBdEwtK65neaPwwcXvXQPPyzXxMWj/ySF?=
 =?us-ascii?Q?xHwPFnCRSQCM+qc/53ZR+L+oI3In0v+Ny0zBr4QrnFHXCnzOgOT8tf8Ml7rL?=
 =?us-ascii?Q?XXBm1XdCjK9tro9upcTQXBrQcQkcjuiTJdlnTfA9AUdWWpYjP0wyzLG226Sx?=
 =?us-ascii?Q?mb2tov4GGnKryjxT6D8XxqNzmmlNfCvDf3pKaniJjL/w4mz4idyarpwiMj1x?=
 =?us-ascii?Q?InHPiCi773oGYBt5LI3VfPbQHp+Tan6rtD1V5ebOwtP9LYSVjLbd9VKhnXUj?=
 =?us-ascii?Q?W/3nCWGxbpkaeKiq76KnNyouZx5L4RBLonLGUpVetb7+xsokAWelBUl89uB7?=
 =?us-ascii?Q?Dg=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <6AEAB3958FEA704982AFDD8CF9F0A2B6@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DB9PR08MB6588.eurprd08.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 441c45d6-a3bc-4389-425c-08dd2fb94304
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2025 07:51:29.5827
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: uzXd/nGWuifh4oEmTE5+rNWbumB3cx/9XGOioIljwNSFF2YiIch2GdteZ9sPsrSlgkhf4c24EaJWN01h4j3ZmKdhzFgwoapaY1Li5SjO9h4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS1PR08MB7452

Hi Ayan,

> On 19 Dec 2024, at 11:56, Ayan Kumar Halder <ayan.kumar.halder@amd.com> w=
rote:
>=20
> From: Michal Orzel <michal.orzel@amd.com>
>=20
> Add requirements for dom0less domain creation.
>=20
> Signed-off-by: Michal Orzel <michal.orzel@amd.com>
> Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
> ---
> Changes from -
>=20
> v1 - 1. As the dom0less domain creation requirements specifies the dt pro=
perties
> for creating domains, it has been moved to product requirements. Product
> requirements define the interface Xen exposes to other domains.
>=20
> 2. For the requirements which introduces new terms (like grant table, etc=
), I
> have provided the definition as part of the comments.
>=20
> 3. Introduced new market requirements to specify that Xen can assign iome=
m and
> irqs to domains.
>=20
> 4. The design requirements will be added later.
>=20
> v2 - 1. Rephrased the requirements as suggested.
>=20
> 2. Split the product requirements into arm64 specific and common.
>=20
> 3. The arm64 specific requirements have arm64_ prefixed to their tag name=
s.
>=20
> 4. Grant table requirements have been dropped for now.
>=20
> 5. Added a market requirement to denote that Xen can support multiple sch=
edulers.
>=20
> 6. Updated index.rst as we have a new file ie product-reqs/reqs.rst.
>=20
> docs/fusa/reqs/index.rst                   |   1 +
> docs/fusa/reqs/market-reqs/reqs.rst        |  31 ++++
> docs/fusa/reqs/product-reqs/arm64/reqs.rst | 128 +++++++++++++++-
> docs/fusa/reqs/product-reqs/reqs.rst       | 163 +++++++++++++++++++++
> 4 files changed, 321 insertions(+), 2 deletions(-)
> create mode 100644 docs/fusa/reqs/product-reqs/reqs.rst
>=20
> diff --git a/docs/fusa/reqs/index.rst b/docs/fusa/reqs/index.rst
> index 8a4dae6fb2..1088a51d52 100644
> --- a/docs/fusa/reqs/index.rst
> +++ b/docs/fusa/reqs/index.rst
> @@ -8,6 +8,7 @@ Requirements documentation
>=20
>    intro
>    market-reqs/reqs
> +   product-reqs/reqs
>    product-reqs/arm64/reqs
>    design-reqs/arm64/generic-timer
>    design-reqs/arm64/sbsa-uart
> diff --git a/docs/fusa/reqs/market-reqs/reqs.rst b/docs/fusa/reqs/market-=
reqs/reqs.rst
> index f456788d96..39b2714237 100644
> --- a/docs/fusa/reqs/market-reqs/reqs.rst
> +++ b/docs/fusa/reqs/market-reqs/reqs.rst
> @@ -47,3 +47,34 @@ Comments:
>=20
> Needs:
>  - XenProd
> +
> +Static VM definition
> +--------------------
> +
> +`XenMkt~static_vm_definition~1`
> +
> +Description:
> +Xen shall support assigning peripherals to various domains.
> +
> +Rationale:
> +
> +Comments:
> +Peripheral implies an iomem (input output memory) and/or interrupts.
> +
> +Needs:
> + - XenProd
> +
> +Multiple schedulers
> +-------------------
> +
> +`XenMkt~multiple_schedulers~1`
> +
> +Description:
> +Xen shall provide different ways of scheduling virtual cpus onto physica=
l cpus.
> +
> +Rationale:
> +
> +Comments:
> +
> +Needs:
> + - XenProd
> diff --git a/docs/fusa/reqs/product-reqs/arm64/reqs.rst b/docs/fusa/reqs/=
product-reqs/arm64/reqs.rst
> index db91c47a02..c8fee0e49f 100644
> --- a/docs/fusa/reqs/product-reqs/arm64/reqs.rst
> +++ b/docs/fusa/reqs/product-reqs/arm64/reqs.rst
> @@ -6,7 +6,7 @@ Domain Creation And Runtime
> Emulated Timer
> --------------
>=20
> -`XenProd~emulated_timer~1`
> +`XenProd~arm64_emulated_timer~1`
>=20
> Description:
> Xen shall grant access to "Arm Generic Timer" for the domains.
> @@ -25,7 +25,7 @@ Needs:
> Emulated UART
> -------------
>=20
> -`XenProd~emulated_uart~1`
> +`XenProd~arm64_emulated_uart~1`
>=20
> Description:
> Xen shall provide an "Arm SBSA UART" compliant device to the domains.
> @@ -40,3 +40,127 @@ Covers:
>=20
> Needs:
>  - XenSwdgn
> +
> +Linux kernel image
> +------------------
> +
> +`XenProd~arm64_linux_kernel_image~1`
> +
> +Description:
> +Xen shall create a domain with a binary containing header compliant with=
 Arm64
> +Linux kernel image [1].
> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenMkt~run_arm64_domains~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +Gzip Linux kernel image
> +-----------------------
> +
> +`XenProd~arm64_linux_kernel_gzip_image~1`
> +
> +Description:
> +Xen shall create a domain with a Gzip compressed binary containing heade=
r
> +compliant with Arm64 Linux kernel image [1].
> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenMkt~run_arm64_domains~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +Kernel with uImage header
> +-------------------------
> +
> +`XenProd~arm64_kernel_uimage~1`
> +
> +Description:
> +Xen shall create a domain with a binary containing uImage header [2].
> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenMkt~run_arm64_domains~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +Gzip kernel with uImage header
> +------------------------------
> +
> +`XenProd~arm64_gzip_kernel_uimage~1`
> +
> +Description:
> +Xen shall create a domain with a Gzip compressed binary containing uImag=
e
> +header [2].
> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenMkt~run_arm64_domains~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +SPIs
> +----
> +
> +`XenProd~arm64_spis~1`
> +
> +Description:
> +Xen shall create a domain with a number of shared peripheral interrupts =
as
> +specified in the device tree.

"a number" is kind of undefined here. If we have a limit then we should spe=
cify it
here otherwise this becomes hard to test.
I would suggest to rephrase to "assign hardware shared peripheral interrupt=
s
specified in the device tree to a domain"

> +
> +Rationale:
> +
> +Comments:
> +Device tree is a data structure and language for describing hardware whi=
ch is
> +readable by an operating system [3].
> +A shared peripheral interrupt is a peripheral interrupt that the Arm Gen=
eric
> +Interrupt Controller's Distributor interface can route to any combinatio=
n of
> +processors [4].
> +
> +Covers:
> + - `XenMkt~run_arm64_domains~1`
> + - `XenMkt~static_vm_definition~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +Virtual PL011
> +-------------
> +
> +`XenProd~arm64_virtual_pl011~1`
> +
> +Description:
> +Xen shall provide an "Arm PL011 UART" compliant device to the domains.
> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenMkt~run_arm64_domains~1`
> + - `XenMkt~provide_console_domains~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +| [1] https://github.com/torvalds/linux/blob/master/Documentation/arch/a=
rm64/booting.rst
> +| [2] https://source.denx.de/u-boot/u-boot/-/blob/master/include/image.h=
#L315
> +| [3] https://docs.kernel.org/devicetree/usage-model.html
> +| [4] https://developer.arm.com/documentation/ihi0048/a/Introduction/Ter=
minology/Interrupt-types?lang=3Den
> diff --git a/docs/fusa/reqs/product-reqs/reqs.rst b/docs/fusa/reqs/produc=
t-reqs/reqs.rst
> new file mode 100644
> index 0000000000..9257fec713
> --- /dev/null
> +++ b/docs/fusa/reqs/product-reqs/reqs.rst
> @@ -0,0 +1,163 @@
> +.. SPDX-License-Identifier: CC-BY-4.0
> +
> +Domain Creation And Runtime
> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
> +
> +Kernel command line arguments
> +-----------------------------
> +
> +`XenProd~kernel_cmd_line_args~1`
> +
> +Description:
> +Xen shall pass kernel command line arguments to a domain via a device tr=
ee.

Would it make sense to say where the "command line" to pass is specified ?

> +
> +Rationale:
> +
> +Comments:
> +Device tree is a data structure and language for describing hardware whi=
ch is
> +readable by an operating system [1].
> +
> +Covers:
> + - `XenMkt~run_arm64_domains~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +Ramdisk
> +-------
> +
> +`XenProd~ramdisk~1`
> +
> +Description:
> +Xen shall provide the address of an initial ramdisk to a domain via a de=
vice
> +tree.
> +
> +Rationale:
> +
> +Comments:
> +The initial ramdisk is contained in memory.
> +
> +Covers:
> + - `XenMkt~run_arm64_domains~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +Memory
> +------
> +
> +`XenProd~memory~1`
> +
> +Description:
> +Xen shall create a domain with an amount of memory specified in a device=
 tree.

s/an/the/

> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenMkt~run_arm64_domains~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +vCPUs
> +-----
> +
> +`XenProd~vcpus~1`
> +
> +Description:
> +A domain shall have a configurable number of virtual CPUs (1 to XX).

XX should be replaced with "the maximum number specified at compilation
 in the configuration through CONFIG_MAX_CPUS" or something like that.

> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenMkt~run_arm64_domains~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +Credit2 CPU pool scheduler
> +--------------------------
> +
> +`XenProd~credit2_cpu_pool_scheduler~1`
> +
> +Description:
> +Xen shall have a scheduler where a physical cpu can be shared between mo=
re than
> +one virtual cpu.

i think you can name it in the req: "a credit2 scheduler"

> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenMkt~run_arm64_domains~1`
> + - `XenMkt~multiple_schedulers~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +NUL CPU pool scheduler
> +----------------------
> +
> +`XenProd~nul_cpu_pool_scheduler~1`
> +
> +Description:
> +Xen shall have a scheduler where the virtual cpu will be always running =
on its
> +dedicated physical cpu.

name the scheduler and also "domain virtual cpu is always"

> +
> +Rationale:
> +
> +Comments:
> +A NUL CPU pool scheduler maps a virtual cpu to a unique physical cpu.
> +
> +Covers:
> + - `XenMkt~run_arm64_domains~1`
> + - `XenMkt~multiple_schedulers~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +Assign iomem
> +------------
> +
> +`XenProd~assign_iomem~1`
> +
> +Description:
> +Xen shall support assigning iomem to a domain.

We cannot assign "any iomem" but pages of iomem (address and size aligned t=
o a page).

> +
> +Rationale:
> +
> +Comments:
> +
> +Rationale:

2 times rationale

> +
> +Covers:
> + - `XenMkt~static_vm_definition~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +Forward interrupts
> +------------------
> +
> +`XenProd~forward_irqs~1`
> +
> +Description:
> +Xen shall support forwarding interrupts to a domain.

I think you need to add "hardware interrupts" here.

> +
> +Rationale:
> +
> +Comments:
> +
> +Rationale:

rationale twice

> +
> +Covers:
> + - `XenMkt~static_vm_definition~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +| [1] https://docs.kernel.org/devicetree/usage-model.html
> --=20
> 2.25.1
>=20

Cheers
Bertrand




From xen-devel-bounces@lists.xenproject.org Wed Jan 08 07:55:43 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 07:55:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866934.1278313 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVQuk-00010U-Eo; Wed, 08 Jan 2025 07:55:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866934.1278313; Wed, 08 Jan 2025 07:55:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVQuk-00010N-CL; Wed, 08 Jan 2025 07:55:42 +0000
Received: by outflank-mailman (input) for mailman id 866934;
 Wed, 08 Jan 2025 07:55:40 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=2h7L=UA=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tVQui-00010H-Ov
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 07:55:40 +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 f34ff225-cd95-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 08:55:38 +0100 (CET)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-aa69107179cso2735273566b.0
 for <xen-devel@lists.xenproject.org>; Tue, 07 Jan 2025 23:55:38 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0efe3958sm2448030666b.96.2025.01.07.23.55.37
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 07 Jan 2025 23:55:37 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f34ff225-cd95-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736322938; x=1736927738; 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=15/fxpnRPGsuKaRUiaA9l+EFhd190Bo2vicC3mODEfM=;
        b=Tq39DrDtZuP/ppmjHPD5494LfxD0BK7okNH/qXy0L889hfEi6LpbtDr4TvYnakEeiW
         lASHofQmU/DegbD7JKdTfMVwJa9jssW3UqWcMYBlCuvk8ENJyYSwhTzutgQ7Jsc+fQRc
         8AIzx0f71uIJIEdxVSsjXwROm8z59wRQhu3CY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736322938; x=1736927738;
        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=15/fxpnRPGsuKaRUiaA9l+EFhd190Bo2vicC3mODEfM=;
        b=B/z+y7xUKl78/Y8mnLCFSOr/Us+WKL5SrHBxGuYCM9Gz4bi72h2lOdf6p62HnmEpIW
         VlxKXJYuRiTPfAqr6HHtum/4U4cwZGtnHEt4RgctE2ttftaZOGy1m1QcW3jCSPJ4zBzP
         KWgObvZle1Ras0JGL7qiIZtaq9DLxchuZ0tRCYob/vDW2C6tPQHqP8UA4TquUJjSg2uG
         cmhOLw3iW/xkQjYlSndSv5XW+lFxMAB24EI6bQGgyBlKTSylwwUxhvcRiS7hSZ4E9Xi+
         6U35yF+DpejkNL7ihl8cfRh6PrBUHHWFldgPL7zvBbP5rSiGeKiTaLJTe93xMWiyslUK
         sfOQ==
X-Forwarded-Encrypted: i=1; AJvYcCWL+6qySEJj6oBJCT/YhSibIkXGBmp9O+MTfVit/jAC7oEWCkbNzQFMLe+giuo9y6C5/GFuliii2ko=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yztr2kq9Ag+IJBMuVMZtG322GPdYI+N4Ra9FCy/vdQHCwmRgWun
	eiw81CxjbqRbmW1Mkrz9XUr1+FGeWCLmfiH4IjmE5gywdXtnoUSUBzJ1LRI1UOyxDewlY+SPR+B
	G
X-Gm-Gg: ASbGncunvyMNH6ge4QODfKl57AIWcUbKMxGOkT1MvnJZCSe35zszye8ixxlkj/0v/5W
	0az21WyfXrChljVccBAM+vKEsD9FeYw6RKb5sjgo8eOgcKPc2u7GCwnzjJEERH/AVmkw5zDuQUw
	pgbcqfWFMq2Nd5tISTFqilOG9l7DdG9R/CvCeyMy4WL1PCvP5FEBXiu2FkkPKh4ZGJm/tZxbuSo
	LIqCUrXCCbSvfAhb7AuA4KdqXZLfDlTJouvP0PjhMOCydyPKTW6DwtCdFYvZ9dWx6c=
X-Google-Smtp-Source: AGHT+IGx4YHCvLunMDLeCrMT+UUY+9lmsa77uLKyoQSx7UXn6wApZBuMpbpS2TnupdoI6VC19Rjl2A==
X-Received: by 2002:a17:906:c106:b0:aa5:b1b9:5d6a with SMTP id a640c23a62f3a-ab2abc91217mr132216066b.54.1736322938301;
        Tue, 07 Jan 2025 23:55:38 -0800 (PST)
Date: Wed, 8 Jan 2025 08:55:36 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Jiqian Chen <Jiqian.Chen@amd.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Huang Rui <ray.huang@amd.com>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v4] vpci: Add resizable bar support
Message-ID: <Z34veAxGFCg25Zrb@macbook.local>
References: <20241219052143.3161332-1-Jiqian.Chen@amd.com>
 <d904c816-da83-418a-9bff-9988660af546@suse.com>
 <Z308fGa1daaM62Rf@macbook.local>
 <fb1b00fe-5740-4c0e-81d9-ec9fd9a4a1c3@suse.com>
 <Z31wFjWadOkzTDK3@macbook.local>
 <d5e37e59-2a05-4184-9b1e-ca0bf77f201c@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <d5e37e59-2a05-4184-9b1e-ca0bf77f201c@suse.com>

On Wed, Jan 08, 2025 at 08:19:55AM +0100, Jan Beulich wrote:
> On 07.01.2025 19:19, Roger Pau Monné wrote:
> > On Tue, Jan 07, 2025 at 04:58:07PM +0100, Jan Beulich wrote:
> >> On 07.01.2025 15:38, Roger Pau Monné wrote:
> >>> On Tue, Jan 07, 2025 at 11:06:33AM +0100, Jan Beulich wrote:
> >>>> On 19.12.2024 06:21, Jiqian Chen wrote:
> >>>>> --- /dev/null
> >>>>> +++ b/xen/drivers/vpci/rebar.c
> >>>>> @@ -0,0 +1,131 @@
> >>>>> +/* SPDX-License-Identifier: GPL-2.0-only */
> >>>>> +/*
> >>>>> + * Copyright (C) 2024 Advanced Micro Devices, Inc. All Rights Reserved.
> >>>>> + *
> >>>>> + * Author: Jiqian Chen <Jiqian.Chen@amd.com>
> >>>>> + */
> >>>>> +
> >>>>> +#include <xen/sched.h>
> >>>>> +#include <xen/vpci.h>
> >>>>> +
> >>>>> +static void cf_check rebar_ctrl_write(const struct pci_dev *pdev,
> >>>>> +                                      unsigned int reg,
> >>>>> +                                      uint32_t val,
> >>>>> +                                      void *data)
> >>>>> +{
> >>>>> +    struct vpci_bar *bar = data;
> >>>>> +    uint64_t size = PCI_REBAR_CTRL_SIZE(val);
> >>>>> +
> >>>>> +    if ( bar->enabled )
> >>>>> +    {
> >>>>> +        /*
> >>>>> +         * Refuse to resize a BAR while memory decoding is enabled, as
> >>>>> +         * otherwise the size of the mapped region in the p2m would become
> >>>>> +         * stale with the newly set BAR size, and the position of the BAR
> >>>>> +         * would be reset to undefined.  Note the PCIe specification also
> >>>>> +         * forbids resizing a BAR with memory decoding enabled.
> >>>>> +         */
> >>>>> +        if ( size != bar->size )
> >>>>> +            gprintk(XENLOG_ERR,
> >>>>> +                    "%pp: refuse to resize BAR with memory decoding enabled\n",
> >>>>> +                    &pdev->sbdf);
> >>>>> +        return;
> >>>>> +    }
> >>>>> +
> >>>>> +    if ( !((size >> PCI_REBAR_SIZE_BIAS) & bar->resizable_sizes) )
> >>>>> +        gprintk(XENLOG_WARNING,
> >>>>> +                "%pp: new size %#lx is not supported by hardware\n",
> >>>>> +                &pdev->sbdf, size);
> >>>>> +
> >>>>> +    bar->size = size;
> >>>>
> >>>> Shouldn't at least this be in an "else" to the if() above?
> >>>
> >>> I think this was already raised in a previous version - would be good
> >>> to know how real hardware behaves when an invalid size is set.  Is the
> >>> BAR register still reset?
> >>
> >> I'm pretty sure what happens is undefined. I'd expect though that the
> >> BAR size then doesn't change. Which would require the above assignment
> >> to not be unconditional.
> > 
> > Might be better to just re-size the BAR, like you suggested to fetch
> > the BAR position from the register, instead of assuming 0.
> 
> FTAOD by "re-size" you mean re-obtain its size (seeing we're talking of
> re-sizable BARs here)? As kind of confirmed ...

Indeed, I meant to re-obtain the size (I can see that being
confusing in this context, sorry).

> >>>>> --- a/xen/drivers/vpci/vpci.c
> >>>>> +++ b/xen/drivers/vpci/vpci.c
> >>>>> @@ -232,6 +232,12 @@ void cf_check vpci_hw_write16(
> >>>>>      pci_conf_write16(pdev->sbdf, reg, val);
> >>>>>  }
> >>>>>  
> >>>>> +void cf_check vpci_hw_write32(
> >>>>> +    const struct pci_dev *pdev, unsigned int reg, uint32_t val, void *data)
> >>>>> +{
> >>>>> +    pci_conf_write32(pdev->sbdf, reg, val);
> >>>>> +}
> >>>>
> >>>> This function is being added just to handle writing of a r/o register.
> >>>> Can't you better re-use vpci_ignored_write()?
> >>>
> >>> But vpci_ignored_write() ignores the write, OTOH here the write is
> >>> propagated to the hardware.
> >>
> >> Right, just for the hardware to drop it. I wouldn't have commented if
> >> the function needed to do things like this already existed. Adding yet
> >> another cf_check function just for this is what made me give the remark.
> > 
> > According to the spec yes, they will be ignored.  Yet for the hardware
> > domain we try to avoid changing behavior from native as much as
> > possible, hence propagating the write seems more appropriate.
> 
> Okay; you're the maintainer of this code anyway.

Thanks for all your input Jan, you might not be the maintainer but
have certainly reviewed all vPCI code.

Roger.


From xen-devel-bounces@lists.xenproject.org Wed Jan 08 07:57:41 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 07:57:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866941.1278324 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVQwb-0001Yn-RN; Wed, 08 Jan 2025 07:57:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866941.1278324; Wed, 08 Jan 2025 07:57:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVQwb-0001Yg-Nk; Wed, 08 Jan 2025 07:57:37 +0000
Received: by outflank-mailman (input) for mailman id 866941;
 Wed, 08 Jan 2025 07:57:36 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=kklb=UA=amd.com=Michal.Orzel@srs-se1.protection.inumbo.net>)
 id 1tVQwa-0001Ya-Eo
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 07:57:36 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20614.outbound.protection.outlook.com
 [2a01:111:f403:200a::614])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 37baebbf-cd96-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 08:57:35 +0100 (CET)
Received: from SJ0PR05CA0122.namprd05.prod.outlook.com (2603:10b6:a03:33d::7)
 by LV3PR12MB9412.namprd12.prod.outlook.com (2603:10b6:408:211::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8335.10; Wed, 8 Jan
 2025 07:57:30 +0000
Received: from SJ1PEPF00002310.namprd03.prod.outlook.com
 (2603:10b6:a03:33d:cafe::b6) by SJ0PR05CA0122.outlook.office365.com
 (2603:10b6:a03:33d::7) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.17 via Frontend Transport; Wed,
 8 Jan 2025 07:57:29 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ1PEPF00002310.mail.protection.outlook.com (10.167.242.164) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8335.7 via Frontend Transport; Wed, 8 Jan 2025 07:57:29 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 8 Jan
 2025 01:57:28 -0600
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 8 Jan
 2025 01:57:28 -0600
Received: from XIR-MICHALO-L1.xilinx.com (10.180.168.240) by
 SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39
 via Frontend Transport; Wed, 8 Jan 2025 01:57:26 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 37baebbf-cd96-11ef-a0df-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=uKbHv1urItayJlibtDVWyRpC1PQ9xokreZEwIBPdO5WPkoXLlGJfwlYmnpntwUjfZhLbstI66QnVxoJIViD85A1/MlbwjT8fOj/E+6ZJyEB/++L+5gbYG0s1bkuQBqiLSem9vaBG/mHeDt2gd1aGgRZ2gxBFnxvL5KADxsoV2AOmTg7uqI9hSo/MOzbfhhsQ2DQ1b/QQNA/NEwqqGqhElxQljXqkA7m9pb4U+4JWOZwSGp0W9yjjkLqfz5bg/MiGbXv9zi/W7hse/zFS2WVIyp7tORrTzRj1/1Y3Yq6IkJnJfrUpRr8SVYhnO0yjruz6x6BvpN1VsR15nC9+5pP+aA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=AMBfchd/5Our57Z312dT0WCT9dM6EG4jVn22t+Qcvs4=;
 b=PtgSX83qI0bx/gyGfXmC7+LucDQ75v/RRFjjYY7tq6gc3RNguyMYry1Wn3hm8JxMUft8L/XZ3JmSTeRnejezuulg//w0iWRpRXRtdCNXJ1lcjV2U3ypuQHyWHi0RFAVCP7qfyVAUNU2iaYOdNyPCcD5kxhMiTmqVZN/CIR3QTOQQ3hFIEYgCAbs+1GXEOIzHP7A3emjZCLNSKVNb8hm8bTIeaZ4zLIl19PyFPC8m2n1jseJEd0mmFvug+I0A+YQv7bC3kt6/aPVYbRj22owvWi61iDou9AWEYNSBXPMAY9yYRXIrYJz6kd+7LSHUiWjb8nDrRpKJHiMi7TZheCkd3w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=AMBfchd/5Our57Z312dT0WCT9dM6EG4jVn22t+Qcvs4=;
 b=h+bT2lMQ3PP6VAuVGAcb42ugAH+x5RCpfvFyoeJ3tjb+ez2XAoBiVsWJoWw9vWVxLM4RxJNHE5QozDx3GDl/0W8FcwnFqOukCnXcajXN+YH0IDAYFjk7u0seNLR4Z2PRcqyeqqO934wNBFF8RhL/d5HeDDyGh5dElDfatKCJeQw=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Michal Orzel <michal.orzel@amd.com>
To: <xen-devel@lists.xenproject.org>
CC: Michal Orzel <michal.orzel@amd.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand Marquis
	<bertrand.marquis@arm.com>, Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	<oleksii.kurochko@gmail.com>
Subject: [for-4.20][PATCH] xen/arm64: Drop relocate_and_switch_ttbr() stub
Date: Wed, 8 Jan 2025 08:57:19 +0100
Message-ID: <20250108075719.84967-1-michal.orzel@amd.com>
X-Mailer: git-send-email 2.25.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB05.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF00002310:EE_|LV3PR12MB9412:EE_
X-MS-Office365-Filtering-Correlation-Id: 2377795a-3724-4356-2404-08dd2fba197d
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|36860700013|376014|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?YBRyyQy7OMUJRld289fZgAfWVq5hY24gz9WUTtKNu3f2NDd5SuusYcG5LDTo?=
 =?us-ascii?Q?kuiSYomzYCSiylLAMqSq3liTSo25/3SYDqM1pkOWOVAawCp9zcS0H4EGDb70?=
 =?us-ascii?Q?s2O/IssyVtkpJ1fsaFzh0s74CUKbTU/od7t1AWKMrs23PPivxpiMilInUAIm?=
 =?us-ascii?Q?cxM9jIdQzo2xf44QrurFh9b1ZyPopB0CGLDX6kQDbr4pnQS0XIdMdDgMO+1y?=
 =?us-ascii?Q?ahf58paNtj35y+C3w4S/qo0Y2g6WndYznnWpDOcLFzJqiQlwGNImPxCqs6UK?=
 =?us-ascii?Q?j3o6wL02sWx16r29bI3rWCbAIE57vE5PAv6LOLtVPkqaVOWDhWaQVWXO+fos?=
 =?us-ascii?Q?d2LeTI2oaKDXmPuniKtmv46xf3/RGxrRkMTuhXm57vxbzCnTaxyLbDUdsE3k?=
 =?us-ascii?Q?Dc1qZ2yCSALiSsv5G/BGNKql6IaW9iLXV04ujJQN+GmdhKDioDHXqiM6zGbh?=
 =?us-ascii?Q?BFsvUCMi4pE2+rq3A+eEoYiUV36DdzyPYsEUNQBHtwhi4ByWsH0KQ9AAiPzj?=
 =?us-ascii?Q?nkaEcPGc3v4Y83qNRLlxyCAhEBY1jN2ZohU01JwiTT4flQltpHE63JDFjDns?=
 =?us-ascii?Q?fzurBfgvWwtsGvb6r80qk/tNZOM3njmgbVw2U2WEVX0qoclT7eCon/Q7Z6G8?=
 =?us-ascii?Q?ImsbH9zeV4FZ2sOauFp8w/Vh/vwd30y21lrsQNdOgO700eoa51QOn37cb/lU?=
 =?us-ascii?Q?ZqAVOr0HRLancL+ejLqpd1rOPtvRIIKLHjLQbr/fLlrt0roUj5kts2ZzjcMd?=
 =?us-ascii?Q?laTwWK/nJZtBYqhWPufh8fQP7WDRg4zcWaj0FTQagRZbpZ3ALS0XJ7vksjgC?=
 =?us-ascii?Q?x9DukFw9G2HfCOEUz2qWoXvnyJdkZhT4Df3O5n4mxBMoHf2MaW2mijFlFhKe?=
 =?us-ascii?Q?NH8SD5RDPh1Z3eGKUWlQYV4NHeU0WBkiEBil0frbVixem8th5kfi55TZnZSl?=
 =?us-ascii?Q?XUzcPW8d1rOnsrjCgah/i9FZfXXKfJk9dYDe0iKHXSm2t3oqyTCGG2cpQbTD?=
 =?us-ascii?Q?2AEz7qsspMTO78bR/x+IMAMXPeDNt6HLRJDo32H9FnUxHxbzzFZV//2cEuzS?=
 =?us-ascii?Q?hWfNOpMtamAucUrXXPym893vVKOlnm3q8vjY+vgBnh4nwuiMkQw0MrwRtn+b?=
 =?us-ascii?Q?iWesSrt/qvpskavY3CzmnWSxEVeNNjX067U7tvmxu1xCoEifBBE1//QoBDrI?=
 =?us-ascii?Q?FH3KDUJoab9vPzkqVaDJ7yEDg/SIQr0KwP9BumRKt8P9wp/7uFBR+QpYvAii?=
 =?us-ascii?Q?lw78PZ+xvQ9bon2z0S/6HWdni5wFHOY5v9c/S1PSxZ8p7P/Z0GTeUyPJhfaC?=
 =?us-ascii?Q?735tngrZ2/P+RZBW/qThA+NMFfYd1mx1WQlMYU794i3VxSPknXSia9DRyrB8?=
 =?us-ascii?Q?czvXWZE8tHbX8QRq9Vn8WlCU6oZd97aPPrKWEuiYinwf8EGqDkoFbsIeJ4l0?=
 =?us-ascii?Q?qTVS7p+u/BhZL/MExNvaEti+zfabIkPLZC8+aPCUFSRzGDFj6E2Gb5lek5fX?=
 =?us-ascii?Q?vcRWihBwUA5hmB0=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(376014)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jan 2025 07:57:29.2970
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 2377795a-3724-4356-2404-08dd2fba197d
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ1PEPF00002310.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR12MB9412

In the original patch e7a80636f16e ("xen/arm: add cache coloring support
for Xen image"), the stub was added under wrong assumption that DCE
won't remove the function call if it's not static. This assumption is
incorrect as we already rely on DCE for cases like this one. Therefore
drop the stub, that otherwise would be a place potentially prone to
errors in the future.

Suggested-by: Julien Grall <julien@xen.org>
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
---
As suggested by Julien, we should have it for 4.20. Leaving a stub like that
without something like BUG_ON inside can potentially lead to problems in
the future provided the function misuse slipped through the review process.
---
 xen/arch/arm/arm64/mmu/mm.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/xen/arch/arm/arm64/mmu/mm.c b/xen/arch/arm/arm64/mmu/mm.c
index 26361c4fe4c0..c1efa1348aee 100644
--- a/xen/arch/arm/arm64/mmu/mm.c
+++ b/xen/arch/arm/arm64/mmu/mm.c
@@ -171,8 +171,6 @@ void __init relocate_and_switch_ttbr(uint64_t ttbr)
      */
     update_identity_mapping(false);
 }
-#else
-void __init relocate_and_switch_ttbr(uint64_t ttbr) {}
 #endif
 
 void __init switch_ttbr(uint64_t ttbr)
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 08:04:39 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 08:04:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866951.1278334 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVR3C-00040N-IT; Wed, 08 Jan 2025 08:04:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866951.1278334; Wed, 08 Jan 2025 08:04:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVR3C-00040G-Fo; Wed, 08 Jan 2025 08:04:26 +0000
Received: by outflank-mailman (input) for mailman id 866951;
 Wed, 08 Jan 2025 08:04: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
 <SRS0=2h7L=UA=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tVR3B-00040A-KU
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 08:04:25 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2cac8e48-cd97-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 09:04:24 +0100 (CET)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-aa6a92f863cso456016266b.1
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 00:04:24 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0f012229sm2460332166b.133.2025.01.08.00.04.23
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 00:04:23 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2cac8e48-cd97-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736323464; x=1736928264; 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=eP/XOq7s93PU1PGEJyApHf3GDjb9SkgJS2Ocy1yA1pY=;
        b=CiY0mUgKd8IwTu3hBl4LZ3B+3Tp6IVFKq1mFCpmwZWLtU1yJtarGBK1kqiYszdpXPj
         J4N4g7BHd6ZWqvuL5DjY8qDdiCRjanWCaqRUKIre6jB/Gf8hPU09kQnuL95IcLrKkmyj
         jtWRow2T6XsKOjWO2u0vWpN8g/AMOrWfcdmzg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736323464; x=1736928264;
        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=eP/XOq7s93PU1PGEJyApHf3GDjb9SkgJS2Ocy1yA1pY=;
        b=q45OAmrnxgdqqBUIzqtuj6pvgXn5o6akZNLzWyFJEi0UBZBQCz44R9d/mvwV9VH8/h
         avtJSj9C/yojX0lV5m0p2RXoa0XX4zfSpEIdl4zXPSmRXgcIxRg1KGEh/q9Qg7Uspw0z
         CL2FYdgn6RHBDkak7eoyGNUzEBDLsm/XctAiQRtoWit7XBqX0yDn4qLwl1NqQfSUFNPW
         eQINjAx6p9EjPgCT33ZwmbnQd6avLf60Sn8hqubl3YnYdiOeRRAm8/s8ZLWFksTNOPxu
         ENTiQTVPzxZbUFPLG5PFZ93VNrEIzJv/fM6TOpNyItUAzUjpvTrJbisVB1FKRTSoXLpx
         n5qw==
X-Forwarded-Encrypted: i=1; AJvYcCWf0kS3T1JZBBejyAB84uVyXWrlanadr4+Jfu87WEDtyvK/0+YTuPfCF6h+rROUXZ71Bzh6CPRfBbE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzaW3pkAnWNGIvu4oXYWFCBhSt7YHyLuvTDLEKdPNtgcCSTcGIb
	obkesNd7tmrqd/DlrisvNb13MzTogF0Jv1AWwOKYdKcR1wNRupR+lBS2n1xX4mM=
X-Gm-Gg: ASbGncsrQlA5yP3xl3I/gG1pDB4gcCgIZXjkTZ0rXD91v7Xl7Lx2BvvIOy9RR3ozcgj
	0MjIpKwT/z72MWl2//p6CIRKWVxy6dUdYuGR07Dref6URkgwIbQVijFt12sYzof2kesXbG3L0Cz
	cEGoX+7OCc9kaxulEXpo2AXghmpyCG8T6hn8vSuly6HL2kOcYiZOBcRXsuBuZzm96DIIZVVaJef
	DfmWesYxOOsQc30oBbTtpErOnehPF/W/OxNLei8/dp5yCFGe0knbsF3HqLOfHxi1AQ=
X-Google-Smtp-Source: AGHT+IE6Ma8bgK8ETIwfm+exAS8GnGvdfSAXCMOTFK3MqHcc13ArCVsUTJ7qNOxaRLmJkLbvEAgJ8Q==
X-Received: by 2002:a17:907:c03:b0:aa6:84c3:70e2 with SMTP id a640c23a62f3a-ab2ab6fe0d9mr153427966b.20.1736323464074;
        Wed, 08 Jan 2025 00:04:24 -0800 (PST)
Date: Wed, 8 Jan 2025 09:04:22 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Denis Mukhin <dmkhn@proton.me>, dmukhin@ford.com,
	xen-devel@lists.xenproject.org,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>
Subject: Re: [PATCH v2 20/35] xen/console: introduce console_owner_domid()
Message-ID: <Z34xhkNu5YLyEzut@macbook.local>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-20-e9aa923127eb@ford.com>
 <d55bf6a6-5861-4b72-88b5-2aaa28ae0290@suse.com>
 <VJ9ivpkbNlqfKhBlb5dL6OuoPAXK9wqD4mhgO9Qt4f0qgmuow22qFv1C7L8DlbKYo7ytdKWeV1bLaYJvTAc2Yt7sEd06XREerWER5RPx4No=@proton.me>
 <8a5a5a0f-72b0-4336-b0d2-142254319242@suse.com>
 <alpine.DEB.2.22.394.2501061046060.133435@ubuntu-linux-20-04-desktop>
 <c39c0c6f-2fab-46e8-9563-c91fe890e87f@suse.com>
 <alpine.DEB.2.22.394.2501071533060.133435@ubuntu-linux-20-04-desktop>
 <a2fa92ff-a5fb-4adc-86aa-1481ebec92fe@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <a2fa92ff-a5fb-4adc-86aa-1481ebec92fe@suse.com>

On Wed, Jan 08, 2025 at 08:28:32AM +0100, Jan Beulich wrote:
> On 08.01.2025 00:40, Stefano Stabellini wrote:
> > On Tue, 7 Jan 2025, Jan Beulich wrote:
> >> On 06.01.2025 19:48, Stefano Stabellini wrote:
> >>> On Mon, 6 Jan 2025, Jan Beulich wrote:
> >>>> On 04.01.2025 05:15, Denis Mukhin wrote:
> >>>>>
> >>>>> On Tuesday, December 10th, 2024 at 11:28 PM, Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
> >>>>>>
> >>>>>>> From: Denis Mukhin dmukhin@ford.com
> >>>>>>>
> >>>>>>> console_owner_domid() is introduced to obtain the "console owner" domain ID.
> >>>>>>>
> >>>>>>> The call is used in NS8250 emulator to identify the case when physical xen
> >>>>>>> console focus is owned by the domain w/ NS8250 emulator, in which case,
> >>>>>>> messages from guest OS are formatted w/o '(XEN)' prefix.
> >>>>>>
> >>>>>>
> >>>>>> Such messages ought to be processed through guest_printk(), which wants a
> >>>>>> domain pointer, not a domid_t anyway. Plus isn't that going to be
> >>>>>> current->domain anyway at the callsite, eliminating the need for such a
> >>>>>>
> >>>>>> helper altogether?
> >>>>>
> >>>>> If the current domain is owning the physical console and printing, say, Linux
> >>>>> login prompt, there's no need to add "(XEN)" for every printout; adding timestamps
> >>>>> can be disabled from Xen command line.
> >>>>
> >>>> Surely there shouldn't be (XEN), but without (d<N>) it'll be ambiguous in a log
> >>>> which domain a message came from. As long as only Dom0 messages are left un-
> >>>> prefixed, that's likely fine. Yet as soon as multiple domains can issue such
> >>>> messages (and have console "focus") I think the prefix needs to be there.
> >>>
> >>> It looks like we are aligned on the desired behavior,
> >>
> >> Hmm, no, I don't think we are. I don't ...
> >>
> >>> but for clarity,
> >>> see https://marc.info/?l=xen-devel&m=173405161613716, also copy/pasted
> >>> here:
> >>>
> >>> I think we should provide a consistent behavior across architectures.
> >>> The current behavior with vpl011 and dom0less on ARM is the following:
> >>>
> >>> - no prefix for Dom0 output
> >>> - DOM$NUM for DomUs when not in focus, otherwise no prefix
> >>
> >> ... view this model as a desirable one. It leaves room for ambiguity.
> > 
> > Adding a few more people in CC for feedback.
> > 
> > My priority is to keep the architectures aligned. It might be OK to
> > change output format, but then let's do it uniformly on ARM as well.
> > 
> > Jan, please clarify what you think would be better than the above. Is it
> > the following? I don't think I understood your preference.
> > 
> > - DOM$NUM for Dom0 and DomUs when not in focus, otherwise no prefix
> 
> No, I mean like we have it with guest_printk() today. (XEN) for Xen's
> own messages, (d<N>) for ordinary domains' ones, and no prefix
> exclusively for the hardware/control domain. What is best to do when
> hardware and control domains are distinct I'm uncertain - I'd be
> inclined to suggest that the hardware domain then stay the one without
> any prefix.

One concern I have with this approach is whether the addition of the
(d<N>) prefixes will skew output of interactive applications.  So far
the prefix is added to output from all domains different than dom0
because the console is not interactive for them, and hence no input
can be consumed.

If that changes however, and domains different than dom0 can get input
from the Xen console then I wonder how much the added prefix will skew
output.  Another possible option would be to not print the prefix for
the domain that has the console input assigned (current target), and
print it for all other domains (even for dom0 when not in focus).

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Jan 08 08:13:15 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 08:13:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866957.1278344 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVRBb-0005sY-CY; Wed, 08 Jan 2025 08:13:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866957.1278344; Wed, 08 Jan 2025 08:13:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVRBb-0005sR-8h; Wed, 08 Jan 2025 08:13:07 +0000
Received: by outflank-mailman (input) for mailman id 866957;
 Wed, 08 Jan 2025 08:13: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 <SRS0=svEr=UA=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVRBa-0005sL-7K
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 08:13:06 +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 62ce181a-cd98-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 09:13:05 +0100 (CET)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-385eed29d17so7810749f8f.0
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 00:13:04 -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
 ffacd0b85a97d-38a1c8acafesm52146369f8f.98.2025.01.08.00.13.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 08 Jan 2025 00:13:04 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 62ce181a-cd98-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736323984; x=1736928784; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=OSIyUPfivFUnhbOA8Qzhhz82TwuOzIj2UmuEY+OoQoU=;
        b=DFSLmEzQJ/p1K4PiCd3gMdkYxswGdX30O7rRbiaUA5HiwrjfH2ftVMuF7ATzb7aLhK
         IlrXv5mOB+jdzXmqJlEzyqIi0PfA87QQ5PAg1gWyE1IA6RycdnDCl4ZvR/QmHvengUWf
         5hUeulbJH0lMSw/4c8WHxAf4RhDMEjpiPJpqQgDtuzh+ZWfovgDAbUVo7Z5rLGfZUP/y
         bKLqXBoCeXGVnNqkWlIMr8axAIEoJ0IIoxtlH/lc70JFUbtUZgL7OvEM/hPEPmWMo2TL
         2NUz+gyZXKonZ7TzixrTt9Gys114qoY6+7scPAeKpSfi0XWV0it8nluY3aZt23hY1Dhe
         Pplw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736323984; x=1736928784;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=OSIyUPfivFUnhbOA8Qzhhz82TwuOzIj2UmuEY+OoQoU=;
        b=a5QQdqUAdLmzmFl5nyVWHiFhYI5/E4ycnzIeIYKDN54Ei+5mLp1+fbU/EkWfLbP2vZ
         We/tXGprpxX4+Ysaw8+lbxgdxDgQC+zMNgulyhZEuVHFI2EqqE8x0mNGFOSh84q8OTw0
         S+klzJK1o3SXsTj299U7ZVRb+hFRmOGFE07YDPman902misJPUFl/DjSIMkj6nMwegzn
         Xd4vvIJtzsgmwTnBmKJcuhApDm8iygPUwJjFuHomJoJvs7yF5sg3TuT1WW6SSGgAujzx
         suOEM074v9zbDcYr4RoBac+oKHrNXDBuf9xPuvuAlFtoZkxwp7wq1nLNgpkvBomFSGW6
         D9PA==
X-Forwarded-Encrypted: i=1; AJvYcCXvYBYGPkTFMh+iHyEkwDuGu6kpD1yPVybGZ+pyJTPSpelQa/4jek2E9xd4/aoUpbqtt+qLaozYJXw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw4Zv9hNi6yms7M8cK/xJ7fSeBMymjcqRmHrLpB0ClANDeUzbbG
	96VuUNsejFDn/hppv1qrJKWEPsom9dNpptti9ZO69IC2VPImF//LPEQJOLmSew==
X-Gm-Gg: ASbGncuHmuViE+yy42Oa0CNKni9SkRen4C8640tJT+ZLJoFSd8O0zX0kWvWNOStncY1
	QnhgomhzPpxZHK4t+T1+bXm5AAW5tXRO/p9jVvxw5UtQ/hBsuDsDLmtVDCTFiR4psjkykY+gUR4
	JQOoWaGTFKxiMz6f41UyKbsnIQWRt0/qiWmgIt03A7wf3VbhwORnYR8MVVDwfhkrArFDSbnORa5
	5HHHfB9h770nTsxepG4Ko9PirlldrlpTLCh/hZSgnQB3DspHWlyx4rSQ1m3j8gXlAP5Rwf4BUqn
	ostIBEfnSzpl1WIlO4vqW6zdt0Pfk2qlHb+p2qkGjw==
X-Google-Smtp-Source: AGHT+IHQAxj2fqVuhg1pSM2G7avPyiqDGFCStsqIlfJJrNu/NqdA2XBACTlCyD6NHsZlPYpfIxy8wg==
X-Received: by 2002:a05:6000:1849:b0:386:2ebe:7ae2 with SMTP id ffacd0b85a97d-38a8733df9emr1384143f8f.45.1736323984353;
        Wed, 08 Jan 2025 00:13:04 -0800 (PST)
Message-ID: <121ae72e-6229-40a4-8b9f-4f8b0764b712@suse.com>
Date: Wed, 8 Jan 2025 09:13:02 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 20/35] xen/console: introduce console_owner_domid()
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
 Denis Mukhin <dmkhn@proton.me>, dmukhin@ford.com,
 xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 Julien Grall <julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-20-e9aa923127eb@ford.com>
 <d55bf6a6-5861-4b72-88b5-2aaa28ae0290@suse.com>
 <VJ9ivpkbNlqfKhBlb5dL6OuoPAXK9wqD4mhgO9Qt4f0qgmuow22qFv1C7L8DlbKYo7ytdKWeV1bLaYJvTAc2Yt7sEd06XREerWER5RPx4No=@proton.me>
 <8a5a5a0f-72b0-4336-b0d2-142254319242@suse.com>
 <alpine.DEB.2.22.394.2501061046060.133435@ubuntu-linux-20-04-desktop>
 <c39c0c6f-2fab-46e8-9563-c91fe890e87f@suse.com>
 <alpine.DEB.2.22.394.2501071533060.133435@ubuntu-linux-20-04-desktop>
 <a2fa92ff-a5fb-4adc-86aa-1481ebec92fe@suse.com>
 <Z34xhkNu5YLyEzut@macbook.local>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <Z34xhkNu5YLyEzut@macbook.local>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 08.01.2025 09:04, Roger Pau Monné wrote:
> On Wed, Jan 08, 2025 at 08:28:32AM +0100, Jan Beulich wrote:
>> On 08.01.2025 00:40, Stefano Stabellini wrote:
>>> On Tue, 7 Jan 2025, Jan Beulich wrote:
>>>> On 06.01.2025 19:48, Stefano Stabellini wrote:
>>>>> On Mon, 6 Jan 2025, Jan Beulich wrote:
>>>>>> On 04.01.2025 05:15, Denis Mukhin wrote:
>>>>>>>
>>>>>>> On Tuesday, December 10th, 2024 at 11:28 PM, Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
>>>>>>>>
>>>>>>>>> From: Denis Mukhin dmukhin@ford.com
>>>>>>>>>
>>>>>>>>> console_owner_domid() is introduced to obtain the "console owner" domain ID.
>>>>>>>>>
>>>>>>>>> The call is used in NS8250 emulator to identify the case when physical xen
>>>>>>>>> console focus is owned by the domain w/ NS8250 emulator, in which case,
>>>>>>>>> messages from guest OS are formatted w/o '(XEN)' prefix.
>>>>>>>>
>>>>>>>>
>>>>>>>> Such messages ought to be processed through guest_printk(), which wants a
>>>>>>>> domain pointer, not a domid_t anyway. Plus isn't that going to be
>>>>>>>> current->domain anyway at the callsite, eliminating the need for such a
>>>>>>>>
>>>>>>>> helper altogether?
>>>>>>>
>>>>>>> If the current domain is owning the physical console and printing, say, Linux
>>>>>>> login prompt, there's no need to add "(XEN)" for every printout; adding timestamps
>>>>>>> can be disabled from Xen command line.
>>>>>>
>>>>>> Surely there shouldn't be (XEN), but without (d<N>) it'll be ambiguous in a log
>>>>>> which domain a message came from. As long as only Dom0 messages are left un-
>>>>>> prefixed, that's likely fine. Yet as soon as multiple domains can issue such
>>>>>> messages (and have console "focus") I think the prefix needs to be there.
>>>>>
>>>>> It looks like we are aligned on the desired behavior,
>>>>
>>>> Hmm, no, I don't think we are. I don't ...
>>>>
>>>>> but for clarity,
>>>>> see https://marc.info/?l=xen-devel&m=173405161613716, also copy/pasted
>>>>> here:
>>>>>
>>>>> I think we should provide a consistent behavior across architectures.
>>>>> The current behavior with vpl011 and dom0less on ARM is the following:
>>>>>
>>>>> - no prefix for Dom0 output
>>>>> - DOM$NUM for DomUs when not in focus, otherwise no prefix
>>>>
>>>> ... view this model as a desirable one. It leaves room for ambiguity.
>>>
>>> Adding a few more people in CC for feedback.
>>>
>>> My priority is to keep the architectures aligned. It might be OK to
>>> change output format, but then let's do it uniformly on ARM as well.
>>>
>>> Jan, please clarify what you think would be better than the above. Is it
>>> the following? I don't think I understood your preference.
>>>
>>> - DOM$NUM for Dom0 and DomUs when not in focus, otherwise no prefix
>>
>> No, I mean like we have it with guest_printk() today. (XEN) for Xen's
>> own messages, (d<N>) for ordinary domains' ones, and no prefix
>> exclusively for the hardware/control domain. What is best to do when
>> hardware and control domains are distinct I'm uncertain - I'd be
>> inclined to suggest that the hardware domain then stay the one without
>> any prefix.
> 
> One concern I have with this approach is whether the addition of the
> (d<N>) prefixes will skew output of interactive applications.  So far
> the prefix is added to output from all domains different than dom0
> because the console is not interactive for them, and hence no input
> can be consumed.

Hmm, that's an aspect I have to admit I didn't think of.

> If that changes however, and domains different than dom0 can get input
> from the Xen console then I wonder how much the added prefix will skew
> output.  Another possible option would be to not print the prefix for
> the domain that has the console input assigned (current target), and
> print it for all other domains (even for dom0 when not in focus).

That's largely what aiui was proposed. My extra requirement there would
then be that we make sure a log message is always emitted when console
focus shifts, so it's possible to identify the owner for any part of
the log.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jan 08 08:32:31 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 08:32:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866966.1278353 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVRU4-0000kq-Sn; Wed, 08 Jan 2025 08:32:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866966.1278353; Wed, 08 Jan 2025 08:32:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVRU4-0000kj-QA; Wed, 08 Jan 2025 08:32:12 +0000
Received: by outflank-mailman (input) for mailman id 866966;
 Wed, 08 Jan 2025 08:32:11 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=2h7L=UA=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tVRU2-0000kd-UZ
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 08:32:11 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0bd4336e-cd9b-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 09:32:07 +0100 (CET)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-aaeec07b705so1934774366b.2
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 00:32:07 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0efe3c25sm2517249966b.100.2025.01.08.00.32.06
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 00:32:06 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 0bd4336e-cd9b-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736325127; x=1736929927; 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=GGsdMyLoUw0ReiCx98Gtl/c+81+r+coYxBC5qalBR/w=;
        b=wWQZYkBisJZQrTWvNVLoJ6GAkwjDcEf0McqptTM/zolB18oUVPjHWqJ5sWOg+TCKII
         Cth2PhCCbd/iUG31YToR8fzx/YbKsuJtFyoeAaEh9E45k6mh09c16uShCorZqY0a/A1M
         YqI9m5Z/CzpPzRIKCUdQCbvBxz85sa9LA+jUY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736325127; x=1736929927;
        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=GGsdMyLoUw0ReiCx98Gtl/c+81+r+coYxBC5qalBR/w=;
        b=kFM54+sgokRqSXweJ0o8/JgS5If1cEPp3a2+waEVeXNqpt2Rro8f2GR0EU1mkIoned
         2OED6SdL3/W26xQGDXywt5e9dAfLrtvXYHe8eMEqXjyOEAreBiAo6RBZu8leXiKp2szg
         7o3y1EiC3rBv4cUVkVAFFVvXegnq8/LnJ+A/vhPXw97lKvuCQ4xWTH72aRafOFjvRAZK
         8P34ExqZyf0QvUzhGvFqEH3DowR3oxR6+Q+j4bklPVP9kfjP4QrILZRhkwfd0JNndQCd
         YmqHJdDSW7TGnal3BIwQCUzQJlgCrg7qYWvQvKrLpDS6y9TZMcz08+kUV9PqFjELf/Ye
         wsew==
X-Forwarded-Encrypted: i=1; AJvYcCV4ZPwM6bR0mXXmywsNZVy/DJqGiaCVr4Zy5W+YZrTJxmrM4AnHNjIHFKDyWqodN/5CWx7saskXqiI=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyu1EuN0IZDn7pwlZF2XC5dt0iunJRh9Kux0j4q539mqhm/c7sx
	2xPof7blMAMyktPxkRAqjgMNEq+fx4AAHMaI5JlBGqXMSkKVlYTBa7XsHsKmEk45lttT60qdjF0
	h
X-Gm-Gg: ASbGncu3zgfFtCThiQ+pN+AfcxQaaxNb9pzWky3M0Vq+4c2DUfr3AWdfdN/vfYIrDm4
	xZpBn1LOEwD+I9nl1vnntbVNNlGlfbz9/zV9795pC38JvWF8oIhSMts9lxgvtCCPM3fOOcCeNWH
	iCi9zvyws5Sx2K2TXp8wJixNnjb2D6iWNmHlUgqCu0tmkJ0Xk6s49doYPJ4ITJIzxKQRte5eo+I
	T765SaYPohdCZ66j9JS1BGn4tBw1523ZAo4iD3ICXmBe9lOPwA1Asmp4oR9BAIXIkk=
X-Google-Smtp-Source: AGHT+IGi3myyzeYnlIp6Nw2lTn7guBRhfdzHCVygF+pzhvTYYpCuXzrt+1cb7uPrtVXNpsZpVQdmMg==
X-Received: by 2002:a17:907:2d8f:b0:aaf:8f8e:6bf4 with SMTP id a640c23a62f3a-ab2ab740899mr107934466b.26.1736325126827;
        Wed, 08 Jan 2025 00:32:06 -0800 (PST)
Date: Wed, 8 Jan 2025 09:32:05 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Julien Grall <julien@xen.org>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH for-4.20] public/version: soften wording for deprecated
 sub-ops
Message-ID: <Z344BcLEsojN3j2F@macbook.local>
References: <bf8cc342-52aa-44ee-8bce-ce2be6406904@suse.com>
 <0c8a13d0-04d7-4ed6-a8d8-a4423867fa3f@citrix.com>
 <8ca8ac20-a19f-49ef-9631-08cdcef854d2@suse.com>
 <alpine.DEB.2.22.394.2501061229300.133435@ubuntu-linux-20-04-desktop>
 <9f1d070b-c135-454d-8022-12104e048458@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <9f1d070b-c135-454d-8022-12104e048458@suse.com>

On Tue, Jan 07, 2025 at 09:32:05AM +0100, Jan Beulich wrote:
> On 06.01.2025 23:01, Stefano Stabellini wrote:
> > On Mon, 6 Jan 2025, Jan Beulich wrote:
> >> On 06.01.2025 12:08, Andrew Cooper wrote:
> >>> On 06/01/2025 11:04 am, Jan Beulich wrote:
> >>>> These interfaces were - afaict - originally introduced this way on the
> >>>> firm assumption that the used array sizes would be good virtually
> >>>> forever.  While this assumption turned out to not be true for at least
> >>>> some of them, this still doesn't really render them "broken": They still
> >>>> fit their original purpose, and they are still usable for a fair subset
> >>>> of environments.  Re-word the comments accordingly.
> >>>>
> >>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >>>
> >>> No.
> >>>
> >>> The community voted and rejected this opinion.
> >>
> >> That's not my recollection of what was voted on, and with the vote results
> >> not being available referring to them is unhelpful anyway.
> >>
> >> My (admittedly vague) recollection is that it was decided to leave enough
> >> room for wording choice by submitters. That would cover your original
> >> patch, and it would equally cover mine.
> > 
> > The community-wide survey indicated that it is acceptable to use the
> > term "broken" in our documentation [1]. While the survey was not tied to
> > a specific instance, it was undoubtedly influenced by the ongoing
> > discussion at the time.
> 
> IOW this re-confirms (to me at least) that the vote in itself was ambiguous.
> I have no issue at all with the use of the word "broken" in documentation or
> code comments, provided this accurately describes the situation. Which it
> doesn't here.

I agree with you, I don't think banning the word "broken" from
documentation or code comments is helpful or desirable.

I think the survey wasn't helpful: if we wanted to solve the issue
around the usage of "broken" in that specific patch series, we have
mechanisms to do so: calling a explicit committers vote on the
specific issue.

A generic survey about whether using "broken" is acceptable or not
doesn't solve the specific issue of whether using "broken" in that
context was accurate or not.

> > If the purpose of this patch is to replace the term "broken", as it
> > would seem from the commit message, I would recommend dropping the patch
> > and leaving the wording as it is, given that the community has expressed
> > approval of its use. Let us respect that decision.
> > 
> > However, if the goal is to improve clarity by specifying "due to its
> > size limitations" and noting that the truncation occurs "silently", then
> > I believe the patch could be reviewed with that objective in mind.
> > 
> > In other words, we should not replace "broken" simply for the sake of
> > doing so. That discussion has already been settled. When reviewing this
> > patch, our focus should be on its other merits, if any.
> > 
> > Based on the above, I would not take the patch in its current form. But
> > if Jan is up for rewording the commit message, and focusing purely on
> > the clarity of the in-code comments maybe a future version could be
> > acceptable.
> 
> Assuming the above doesn't change your view, and assuming no-one else is
> going to express views in favor of the wording change, I'll consider the
> patch rejected. And I'll be once again left with the impression that
> things are treated neither equally nor objectively in situations like this
> one: To get one's perspective through unaltered one only needs to resist
> hard enough to any attempt to find a middle ground. That's not a good
> environment to work in, and not something I'd call a "community".

I don't mind that much whether "broken" or "deprecated" is used, IMO I
find it a matter of taste in this case, and I would leave that to the
author of the patch.

I can however understand your frustration with the original survey and
how the results seem to extend past what the questions asked for.  As
said above, our community has meanings to resolve disputes around
this kind of issues in the governance documents, however a public
anonymous survey is not one of them AFAIK.

Regards, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Jan 08 08:35:25 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 08:35:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866973.1278364 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVRXA-0001JP-9u; Wed, 08 Jan 2025 08:35:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866973.1278364; Wed, 08 Jan 2025 08:35:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVRXA-0001JI-7H; Wed, 08 Jan 2025 08:35:24 +0000
Received: by outflank-mailman (input) for mailman id 866973;
 Wed, 08 Jan 2025 08:35:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=2h7L=UA=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tVRX9-0001J7-2F
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 08:35:23 +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 7f4501c0-cd9b-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 09:35:21 +0100 (CET)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-ab2b29dfc65so58203866b.1
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 00:35:21 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0e82f90esm2453753966b.4.2025.01.08.00.35.19
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 00:35:19 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 7f4501c0-cd9b-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736325321; x=1736930121; 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=2A0EJYy6tH0BmzSWr8ztrxIn7qFybjG51eBRm64yv1w=;
        b=Pf+pGIQHjq6E4SO7V91pyZeuO1/bjz3H/WmTCoEZGuBiCk6oEmaA3Gb3ODgxpAslzb
         ZOqkrYdxm9fZDVJPv5sXZU9qwvVJ036kJQa0vrAND+V11/sqTbmuOa2Toc6PIJ2eF/ua
         luzn/6oGizPWYQF5ImB+Nliie1M6Sdsl5u44w=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736325321; x=1736930121;
        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=2A0EJYy6tH0BmzSWr8ztrxIn7qFybjG51eBRm64yv1w=;
        b=rvRUni3EeZ8Ib/Jl3UJE43vF5fB091lOrwdDtRH24CY/I0iBdykriVEC/7rzJFVaN0
         zMDsjFKfV7EB3IniGsFrV377a41QUKd2Y0tudYpuVkFqfm8sO+qZik14YcqotgPL5ZeC
         zj+P9YESjqJtAWZRCWwW90ottU8GEFYCAFe7m9ssj9gf5l/SvZglS0RWF1G/5gfv8AYl
         oUCnKoC5v/G/KIrld0mE3opcshc4q2o8cmrdIDLQENqOw5uPCp292VmaC5uiyfXbO1AR
         JAUAMqW+vu0htx6FwWNjkCV13QjcrkDrHsPZ3cjJB5mXLbGFb6CAmyp9a9D74bwm5vJ/
         0WVw==
X-Forwarded-Encrypted: i=1; AJvYcCVFOJ5AHLK+nvZ/fVTrCrH/yHuSKPlqkL6vDJ6aR4MxXjsp/Eg1kHzD5Rv2ktO+QiT8Kx1oXnB4wWM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwtG/j+DXF6mb+MzDyJ9N2cxJRoYJ4VY9JgZb+LZaK2Q8PrN5dn
	ubyTYbYQT9z0bwGnSeocYuzgeiKcvKIHHH7901YwTHxhx4iqG+1d5WCQWx+gmRE=
X-Gm-Gg: ASbGncsVfBqETi2jtVKparafVQEeXOMLR3LyRD5kuidKqjyEWGTVzVJuyTRQ4ZqzG3a
	fWqQ8B3sxONFQvVmg/llTrvQhwTReQzDhAIL+0h2wT4Gw5LKUAQjbSSEoHHeDoQ7Yc7HPRO6d4V
	qSEdRdWZ6+Af+LZK7tqT5mgTbZR3gAHgBo+imBTcjMj22NKZA4sFDgnmFJupMnmEXPF7D1c4xRo
	7+oAIp8fTTjUs4Zq98CAq9AHlgPKWwTY+6oGyjG+Fk1JbdHavV7rG1CSSIC16ilzMY=
X-Google-Smtp-Source: AGHT+IHLmxb7T15SMKpGNVa0S6TPsrz4b4xItNAM8gvfV1nRO2LXaeXlmMVI/oNBdsh/Ql+91YIlYQ==
X-Received: by 2002:a17:907:720f:b0:aa6:75e1:1864 with SMTP id a640c23a62f3a-ab2ab6a8b3emr154224166b.4.1736325320070;
        Wed, 08 Jan 2025 00:35:20 -0800 (PST)
Date: Wed, 8 Jan 2025 09:35:18 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Denis Mukhin <dmkhn@proton.me>, dmukhin@ford.com,
	xen-devel@lists.xenproject.org,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>
Subject: Re: [PATCH v2 20/35] xen/console: introduce console_owner_domid()
Message-ID: <Z344xgqtpNZIDxHD@macbook.local>
References: <20241205-vuart-ns8250-v1-20-e9aa923127eb@ford.com>
 <d55bf6a6-5861-4b72-88b5-2aaa28ae0290@suse.com>
 <VJ9ivpkbNlqfKhBlb5dL6OuoPAXK9wqD4mhgO9Qt4f0qgmuow22qFv1C7L8DlbKYo7ytdKWeV1bLaYJvTAc2Yt7sEd06XREerWER5RPx4No=@proton.me>
 <8a5a5a0f-72b0-4336-b0d2-142254319242@suse.com>
 <alpine.DEB.2.22.394.2501061046060.133435@ubuntu-linux-20-04-desktop>
 <c39c0c6f-2fab-46e8-9563-c91fe890e87f@suse.com>
 <alpine.DEB.2.22.394.2501071533060.133435@ubuntu-linux-20-04-desktop>
 <a2fa92ff-a5fb-4adc-86aa-1481ebec92fe@suse.com>
 <Z34xhkNu5YLyEzut@macbook.local>
 <121ae72e-6229-40a4-8b9f-4f8b0764b712@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <121ae72e-6229-40a4-8b9f-4f8b0764b712@suse.com>

On Wed, Jan 08, 2025 at 09:13:02AM +0100, Jan Beulich wrote:
> On 08.01.2025 09:04, Roger Pau Monné wrote:
> > On Wed, Jan 08, 2025 at 08:28:32AM +0100, Jan Beulich wrote:
> >> On 08.01.2025 00:40, Stefano Stabellini wrote:
> >>> On Tue, 7 Jan 2025, Jan Beulich wrote:
> >>>> On 06.01.2025 19:48, Stefano Stabellini wrote:
> >>>>> On Mon, 6 Jan 2025, Jan Beulich wrote:
> >>>>>> On 04.01.2025 05:15, Denis Mukhin wrote:
> >>>>>>>
> >>>>>>> On Tuesday, December 10th, 2024 at 11:28 PM, Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
> >>>>>>>>
> >>>>>>>>> From: Denis Mukhin dmukhin@ford.com
> >>>>>>>>>
> >>>>>>>>> console_owner_domid() is introduced to obtain the "console owner" domain ID.
> >>>>>>>>>
> >>>>>>>>> The call is used in NS8250 emulator to identify the case when physical xen
> >>>>>>>>> console focus is owned by the domain w/ NS8250 emulator, in which case,
> >>>>>>>>> messages from guest OS are formatted w/o '(XEN)' prefix.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Such messages ought to be processed through guest_printk(), which wants a
> >>>>>>>> domain pointer, not a domid_t anyway. Plus isn't that going to be
> >>>>>>>> current->domain anyway at the callsite, eliminating the need for such a
> >>>>>>>>
> >>>>>>>> helper altogether?
> >>>>>>>
> >>>>>>> If the current domain is owning the physical console and printing, say, Linux
> >>>>>>> login prompt, there's no need to add "(XEN)" for every printout; adding timestamps
> >>>>>>> can be disabled from Xen command line.
> >>>>>>
> >>>>>> Surely there shouldn't be (XEN), but without (d<N>) it'll be ambiguous in a log
> >>>>>> which domain a message came from. As long as only Dom0 messages are left un-
> >>>>>> prefixed, that's likely fine. Yet as soon as multiple domains can issue such
> >>>>>> messages (and have console "focus") I think the prefix needs to be there.
> >>>>>
> >>>>> It looks like we are aligned on the desired behavior,
> >>>>
> >>>> Hmm, no, I don't think we are. I don't ...
> >>>>
> >>>>> but for clarity,
> >>>>> see https://marc.info/?l=xen-devel&m=173405161613716, also copy/pasted
> >>>>> here:
> >>>>>
> >>>>> I think we should provide a consistent behavior across architectures.
> >>>>> The current behavior with vpl011 and dom0less on ARM is the following:
> >>>>>
> >>>>> - no prefix for Dom0 output
> >>>>> - DOM$NUM for DomUs when not in focus, otherwise no prefix
> >>>>
> >>>> ... view this model as a desirable one. It leaves room for ambiguity.
> >>>
> >>> Adding a few more people in CC for feedback.
> >>>
> >>> My priority is to keep the architectures aligned. It might be OK to
> >>> change output format, but then let's do it uniformly on ARM as well.
> >>>
> >>> Jan, please clarify what you think would be better than the above. Is it
> >>> the following? I don't think I understood your preference.
> >>>
> >>> - DOM$NUM for Dom0 and DomUs when not in focus, otherwise no prefix
> >>
> >> No, I mean like we have it with guest_printk() today. (XEN) for Xen's
> >> own messages, (d<N>) for ordinary domains' ones, and no prefix
> >> exclusively for the hardware/control domain. What is best to do when
> >> hardware and control domains are distinct I'm uncertain - I'd be
> >> inclined to suggest that the hardware domain then stay the one without
> >> any prefix.
> > 
> > One concern I have with this approach is whether the addition of the
> > (d<N>) prefixes will skew output of interactive applications.  So far
> > the prefix is added to output from all domains different than dom0
> > because the console is not interactive for them, and hence no input
> > can be consumed.
> 
> Hmm, that's an aspect I have to admit I didn't think of.
> 
> > If that changes however, and domains different than dom0 can get input
> > from the Xen console then I wonder how much the added prefix will skew
> > output.  Another possible option would be to not print the prefix for
> > the domain that has the console input assigned (current target), and
> > print it for all other domains (even for dom0 when not in focus).
> 
> That's largely what aiui was proposed. My extra requirement there would
> then be that we make sure a log message is always emitted when console
> focus shifts, so it's possible to identify the owner for any part of
> the log.

Indeed, printing console input shifting should be a requirement
regardless of how we decide to print the prefix.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Jan 08 08:41:21 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 08:41:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866980.1278374 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVRcq-00039J-TL; Wed, 08 Jan 2025 08:41:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866980.1278374; Wed, 08 Jan 2025 08:41:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVRcq-00039C-QE; Wed, 08 Jan 2025 08:41:16 +0000
Received: by outflank-mailman (input) for mailman id 866980;
 Wed, 08 Jan 2025 08:41: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
 <SRS0=WoWX=UA=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tVRcp-000396-6m
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 08:41:15 +0000
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com
 [2a00:1450:4864:20::12e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 515adda3-cd9c-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 09:41:13 +0100 (CET)
Received: by mail-lf1-x12e.google.com with SMTP id
 2adb3069b0e04-5401fb9fa03so532288e87.1
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 00:41:13 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5422382164bsm5337249e87.210.2025.01.08.00.41.11
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 08 Jan 2025 00:41:11 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 515adda3-cd9c-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736325673; x=1736930473; darn=lists.xenproject.org;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=6YPINUu1eCrB03hzyh1cPDKDq95IMCoDGao7tQ1KAW8=;
        b=cn4DcUeRiJSxTGawLqFt+oBa1+TufbRYur6Hf9hnJ5oZmCy19nbBRRzzZwqpTuQdpa
         jqY7I1nH++96g58bRbncbv7GgA5ivyCmAZzZGC5WkOvvJobMBh4+56mC3/Y+28702m2M
         T72P+BBEX9DSrCNqIO2UnDboRlfURf/5XD/Z8e+wS3rzn86IbthngQlaE+n1EuP+Ydtm
         t6fN1C7fQew8vfH8mLaAMdUskQ/U3AfXA9wHF0uO+F/FSpS1qvFrzL6RVkrfbAehaAUl
         fwmzHTFtv6PZCcorhzwI3wf41f8U1LlUEE5jydKI8YMW/g/1dxHClp6snLlBpUcQqSWc
         osng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736325673; x=1736930473;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=6YPINUu1eCrB03hzyh1cPDKDq95IMCoDGao7tQ1KAW8=;
        b=S5DGd+QRqb114qQJJ+M+GvB5bRSyQCEBo3nkldhRaTfT7/Qx3omcg088mRUvRe+cHr
         DjpmnwgWXDowlA/4EbR09OIzZD5NvC5z5sk+l6+cg2HWoXvuEch1br8FeN7i+lmiNzrN
         BOqKhiwbrqhh9gaM11Pl+XQ8cJ+6m/mZqTRmABvTAjPidJFc2d6jpPUKBA4YRlqu4gcW
         VDtRdC/JCepCidER4swHZgID82RPhgiwqAsrrsS/57hDIcb542DQtwMR082ZWIuuFfVG
         Q1N4JvQg9Rt0I70XwGn3N4/018wOB6q7+umOnqEGpl7j4ul5JdgzGpIYiB3SUIgHoZbp
         Udcg==
X-Gm-Message-State: AOJu0YyT7PIjj47cGOT/NRnzzSDYlseLDwWUsKIH/FuKvE4PPTjslC/Z
	6oQyx6jIB4G8JpCtHLvh2mzkrbcxbT7qtfkOHpt/X5XIZLP3NX7+
X-Gm-Gg: ASbGncvqb2/X/F24FFiNJsqh2jsTIX+Je6SvQGaEukdXKSxI6ZmVau1gYXf+5+gaQiX
	ll0t3h+GwGZNiK3M8ZeUmuItjDKi3t30KGogHmFOT0qbkfqFCJdJq2iKFHhvAw53Zpm8gf7Pl2y
	xqpGcG8NUplWjfE1xhlpYQS1povj0XmvetQWcodP85sZCWY7CtFkeKlrak181wc7798nC0eKeqm
	58Xb2uhxyxzeFCP+OFyTogKabrg86QA0q0m0+NZrmqS4jodQfzoqyBgH2nB7JrdqJJAOg==
X-Google-Smtp-Source: AGHT+IFqxZ0W3J8UqBDf9fY18Va7AxsWCBF5MZB9F4GBUOoaAceXlU+VXUfhTyiNk5px8LzqPitSJw==
X-Received: by 2002:a05:6512:31d5:b0:542:28af:814 with SMTP id 2adb3069b0e04-5427e9b8904mr1840902e87.19.1736325672208;
        Wed, 08 Jan 2025 00:41:12 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------ejHcb9dg0JEaT8xYBCWPiexq"
Message-ID: <76e408b3-369b-4c37-9e3c-6a8079863cf3@gmail.com>
Date: Wed, 8 Jan 2025 09:41:10 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Xen 4.20 Development Update [December]
To: Denis Mukhin <dmkhn@proton.me>
Cc: xen-devel@lists.xenproject.org, kelly.choi@cloud.com,
 committers@xenproject.org, Denis Mukhin <dmukhin@ford.com>
References: <20250107173117.79047-1-oleksii.kurochko@gmail.com>
 <77f11aeb-40a2-47b0-accf-782941d26f81@gmail.com>
 <l-i2X3sIZcusZX5bDJSb2KhxOQvqVE5V6Igl7FnlCVndzUmgX8ZfceC6w1kc9xpSIO8unl92qJdnZWNl5sA5PhXfv6OWpvcEmKY-qX2-pK0=@proton.me>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <l-i2X3sIZcusZX5bDJSb2KhxOQvqVE5V6Igl7FnlCVndzUmgX8ZfceC6w1kc9xpSIO8unl92qJdnZWNl5sA5PhXfv6OWpvcEmKY-qX2-pK0=@proton.me>

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


On 1/8/25 2:50 AM, Denis Mukhin wrote:
> On Tuesday, January 7th, 2025 at 9:37 AM, Oleksii Kurochko<oleksii.kurochko@gmail.com> wrote:
>
>> Missed to add one item to x86 about "x86/efi: Fix booting when NX is disabled".
>>
>> Please find some details below.
>>
>>
>>
>> On 1/7/25 6:31 PM, Oleksii Kurochko wrote:
>>
>>> Hello everyone,
>>>
>>> This email only tracks big items for xen.git tree. Please reply for items you
>>> would like to see in 4.20 so that people have an idea what is going on and
>>> prioritise accordingly.
>>>
>>> You're welcome to provide description and use cases of the feature you're
>>> working on.
>>>
>>> = Timeline =
>>>
>>> * Last posting date: Nov 29, 2024
>>> * Feature freeze date: Dec 20, 2024
>>> ---> We are here
>>> * RC1: Jan 10, 2025
>>> * Hard code freeze: Jan 17, 2025
>>> * Release: Feb 21, 2025
>>> ( current release schedule:https://wiki.xenproject.org/wiki/Xen_Project_X.YY_Release_Notes )
>>>
>>> This will likely be the last Xen 4.20 Development Update email, as we have
>>> passed the feature freeze date, so no significant updates are expected until
>>> the Xen 4.20 release.
>>>
>>> The next email with development updates will cover Xen 4.21.
>>>
>>> Below, you can find a summary of the tasks completed by the end of
>>> December 2024, followed by a list of tasks still in progress ( it is
>>> up-to-date also ), which will be moved to the Xen 4.21 task list.
>>>
>>> The following items ( the links for them could be found int the list below )
>>> were moved to completed:
>>>
>>> [Dec]:
>>> - x86:
>>>    * x86/mm: miscellaneous fixes.
>>>    * Remove "APX support" task as Jan B. told:
>>>        I think you want to remove this from the list. While I have completed
>>>        work there, I'm not fancying re-basing ahead of the AVX10 work, and hence
>>>        that needs to go in first anyway. Which seems unlikely enough at this
>>>        point, for 4.20.
>>>    * Support device passthrough when dom0 is PVH on Xen.
>>> - Arm:
>>>    * Prerequisite patches for R82 upstreaming
>>>    * Add support for S32CC platforms and LINFlexD UART.
>>>    * Arm cache coloring.
>>>    * ffa: Improvements and fixes.
>>>    * Enable early bootup of AArch64 MPU systems.
>>>    * Enable early bootup of AArch64 MPU systems (Part 2)
>>> - RISC-V:
>>>    * Unflattening and relocation of host device tree
>>>
>>> [Nov]:
>>> - Hypervisor:
>>>    * drivers/char: rename arm-uart.c to uart-init.c
>>>    * Move gic_preinit() to common code
>>>    * stubdom: reduce xenstore library dependencies
>>>    * xen/trace: Treewide API cleanup
>>> - x86:
>>>    * x86/HVM: drop stdvga caching mode
>>>    * Fix module-handling use-after-free's
>>>    * Reuse 32 bit C code more safely
>>>    * xen: address violations of MISRA C Rule 13.6
>>>    * x86/ucode: Simplify/fix loading paths further
>>>    * x86: address violations of MISRA C Rule 16.3
>>>    * iommu/x86: fixes/improvements for unity range checks
>>>    * x86/pvh: Support relocating dom0 kernel
>>> - Arm:
>>>    * xen/arm: Add emulation of Debug Data Transfer Registers
>>> - RISC-V:
>>>    * Setup memory management
>>>
>>>
>>> * Full list of items : *
>>>
>>> = Projects =
>>>
>>> == Hypervisor ==
>>>
>>> *  Remove the directmap (v4)
>>>    -  Elias El Yandouzi
>>>    -https://lore.kernel.org/xen-devel/f6973275-0d7e-4db4-b949-f21e530e1dfc@citrix.com/T/#m9733aa717edf032db0cf8f8f6763537b4f30c1f8
>>>
>>> *  remove libxenctrl usage from xenstored (v1 -> v6)
>>>    -  Juergen Gross
>>>    -https://lore.kernel.org/xen-devel/20250107101711.5980-1-jgross@suse.com/T/#me3a5e025aef6a3431c21e81c670bf09744f2fe35
>>>
>>> *  automation: Refresh the remaining Debian containers (v2)
>>>    -  Javi Merino
>>>    -https://lore.kernel.org/xen-devel/cover.1730743077.git.javi.merino@cloud.com/T/#m5d9acb7cf5db3c2be3d6527de14b69b07812314e
>>>
>>> *  GRUB: Supporting Secure Boot of xen.gz (v1)
>>>    -  Ross Lagerwall
>>>    -https://patchew.org/Xen/20240313150748.791236-1-ross.lagerwall@citrix.com/
>>>
>>> *  MSI-X support with qemu in stubdomain, and other related changes (v8)
>>>    -  Marek Marczykowski-Górecki
>>>    -https://lore.kernel.org/xen-devel/cover.33fb4385b7dd6c53bda4acf0a9e91748b3d7b1f7.1715313192.git-series.marmarek@invisiblethingslab.com/
>>>    -  Only automation patch left to be reviewed/merged.
>>>
>>> *  [RFC] Introduce xenbindgen to autogen hypercall structs (v1)
>>>    -  Alejandro Vallejo
>>>    -https://patchew.org/Xen/20241115115200.2824-1-alejandro.vallejo@cloud.com/
>>>
>>> *  Introduce NS8250 UART emulator (v1 -> v2)
>>>    -  Denis Mukhin
>>>    -https://patchew.org/Xen/20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com/
> I have posted v3 recently:
>    https://lore.kernel.org/xen-devel/20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com/

Thanks for the update. Interesting that there is no v3 on patchew...

~ Oleksii

>
>>> === x86 ===
>> * x86/efi: Fix booting when NX is disabled (v1)
>>    - Andrew Cooper
>>    -https://patchew.org/Xen/20240722101838.3946983-1-andrew.cooper3@citrix.com/
>>
>> ~ Oleksii
>>
>>> *  Expose consistent topology to guests (v7)
>>>    -  Alejandro Vallejo
>>>    -https://patchew.org/Xen/20241021154600.11745-1-alejandro.vallejo@cloud.com/
>>>
>>> *  Boot modules for Hyperlaunch (v8 -> v9)
>>>    -  Daniel P. Smith
>>>    -https://patchew.org/Xen/20241115131204.32135-1-dpsmith@apertussolutions.com/
>>>
>>> *  Address Space Isolation FPU preparations (v2)
>>>    -  Alejandro Vallejo
>>>    -https://patchew.org/Xen/20241105143310.28301-1-alejandro.vallejo@cloud.com/
>>>
>>> *  x86/alternatives: Adjust all insn-relative fields (v2)
>>>    -  Andrew Cooper
>>>    -https://lore.kernel.org/xen-devel/20241002152725.1841575-1-andrew.cooper3@citrix.com/T/#mac2deaea7e02a343210d61887486433d946ad129
>>>
>>> *  x86emul: misc additions (v5 -> v7)
>>>    -  Jan Beulich
>>>    -https://patchew.org/Xen/3a25cd59-e1cb-4bfc-b868-fb11599d22f5@suse.com/
>>>
>>> *  x86/HVM: emulation (MMIO) improvements (v2)
>>>    -  Jan Beulich
>>>    -https://patchew.org/Xen/3294f629-f91f-4b5d-9eb0-40a34aa2ec3e@suse.com/
>>>
>>> *  x86: support AVX10 (v2 -> v3)
>>>    -  Jan Beulich
>>>    -https://patchew.org/Xen/516b7f9a-048e-409d-8a4e-89aeb8ffacc4@suse.com/
>>>
>>> *  VT-d: SATC handling; ATS: tidying (v2)
>>>    -  Jan Beulich
>>>    -https://patchew.org/Xen/64b028be-2197-4951-ae5b-32f9eabfa84a@suse.com/
>>>
>>> *  x86: parallelize AP bring-up during boot (v1)
>>>    -  Krystian Hebel
>>>    -https://lore.kernel.org/xen-devel/cover.1699982111.git.krystian.hebel@3mdeb.com/
>>>
>>> *  x86/spec-ctrl: IBPB improvements (v4)
>>>    -  Jan Beulich
>>>    -https://patchew.org/Xen/06591b64-2f05-a4cc-a2f3-a74c3c4a76d6@suse.com/
>>>
>>> *  Move some boot code from assembly to C (v2)
>>>    -  Frediano Ziglio
>>>    -https://patchew.org/Xen/20241122093358.478774-1-frediano.ziglio@cloud.com/
>>>
>>> *  Hyperlaunch device tree for dom0 (v1 -> v2)
>>>    -  Daniel P. Smith
>>>    -https://patchew.org/Xen/20241226165740.29812-1-dpsmith@apertussolutions.com/
>>>
>>> *  x86: memcpy() / memset() (non-)ERMS flavors plus fallout (v3)
>>>    -  Jan Beulich
>>>    -https://patchew.org/Xen/e7314ac8-ed09-4da8-b915-09409b01fe77@suse.com/
>>>
>>> *  amd-pstate CPU Performance Scaling Driver (v1)
>>>    -  Penny Zheng
>>>    -https://patchew.org/Xen/20241203081111.463400-1-Penny.Zheng@amd.com/
>>>
>>> === ARM ===
>>>
>>> *  Add Virtio-PCI for dom0less on ARM (v1)
>>>    -  Edgar E. Iglesias
>>>    -https://lore.kernel.org/xen-devel/20240924162359.1390487-1-edgar.iglesias@gmail.com/T/#mfa148991b9408f223a079d4cef610244d5b04c2b
>>>
>>> *  PCI devices passthrough on Arm, part 3 (v16)
>>>    -  Stewart Hildebrand
>>>    -https://patchew.org/Xen/20240522225927.77398-1-stewart.hildebrand@amd.com/
>>>    -  Patches are Acked but for some reason last two patches aren't merged.
>>>
>>> *  DOMCTL-based guest magic region allocation for 11 domUs (v4)
>>>    -  Henry Wang
>>>    -https://patchew.org/Xen/20240409045357.236802-1-xin.wang2@amd.com/
>>>
>>> === RISCV ===
>>>
>>> === PPC ===
>>>
>>> *  Early Boot Allocation on Power (v5)
>>>    -  Shawn Anastasio
>>>    -https://lore.kernel.org/xen-devel/cover.1727388925.git.sanastasio@raptorengineering.com/T/#m8cac91a93b56a359fa2d5f08596c4be61dca290d
>>>
>>> == Completed ==
>>>
>>> === Hypervisor ===
>>>
>>> *  libxl: Implement QEMU command line probe (v1)
>>>    -  Anthony PERARD
>>>    -https://lore.kernel.org/xen-devel/20240827100328.23216-1-anthony.perard@vates.tech/T/#mdef23cefc2532ab0c9d7460290cef26780cf97cb
>>>
>>> *  xen/bitops: hweight() cleanup/improvements (v3)
>>>    -  Andrew Cooper
>>>    -https://lore.kernel.org/xen-devel/20240904225530.3888315-1-andrew.cooper3@citrix.com/T/#me22e08f7477be725122dd9b97d29d272e3b586c4
>>>
>>> *  Move percpu code to common (v2)
>>>    -  Oleksii Kurochko
>>>    -https://lore.kernel.org/xen-devel/cover.1727185495.git.oleksii.kurochko@gmail.com/T/#mf93394c46f15cbdcfc873de2d52d862a8b70da7f
>>>
>>> *  xen/livepatch: improvements to loading (v3)
>>>    -  Roger Pau Monne
>>>    -https://lore.kernel.org/xen-devel/20240926101431.97444-1-roger.pau@citrix.com/T/#ma3f65948b065dc443aea2192873a3b3dfa52a2d7
>>>
>>> *  Move {acpi_}device_init() and device_get_class() to common code (v5)
>>>    -  Oleksii Kurochko
>>>    -https://lore.kernel.org/xen-devel/17c7d988e45d7c82448b81fe66b01a5ceca0c15e.camel@gmail.com/T/#m68bd00d4f8b3724e83ba13024e94b15b58a28829
>>>
>>> *  blkif: reconcile protocol specification with in-use implementations (v1)
>>>    -  Roger Pau Monne
>>>    -https://lore.kernel.org/xen-devel/20240903141923.72241-1-roger.pau@citrix.com/
>>>
>>> *  Move gic_preinit() to common code (v5)
>>>    -  Oleksii Kurochko
>>>    -https://lore.kernel.org/xen-devel/151ac176ff02d2ff9b7f87e3c02b9ce0472720fa.1732288620.git.oleksii.kurochko@gmail.com/
>>>
>>> *  stubdom: reduce xenstore library dependencies (v1)
>>>    -  Juergen Gross
>>>    -https://lore.kernel.org/xen-devel/20241010155459.22389-1-jgross@suse.com/T/#m8b5af386e2d288961bb6e8f7839650e0cab96a83
>>>
>>> *  xen/trace: Treewide API cleanup (v7)
>>>    -  Andrew Cooper
>>>    -https://patchew.org/Xen/20240318163552.3808695-1-andrew.cooper3@citrix.com/
>>>
>>> === x86 ===
>>>
>>> *  x86/mm: miscellaneous fixes (v2 -> v3)
>>>    -  Roger Pau Monne
>>>    -https://patchew.org/Xen/20241114145715.59777-1-roger.pau@citrix.com/
>>>
>>> *  Support device passthrough when dom0 is PVH on Xen (v16)
>>>    -  Jiqian Chen
>>>    -https://lore.kernel.org/xen-devel/20240930034250.2682265-1-Jiqian.Chen@amd.com/T/#m5d557d76f290ff5b5550c1443cab5774d397e526
>>>
>>> *  Drop Xeon Phi support (v1)
>>>    -  Jan Beulich
>>>    -https://lore.kernel.org/xen-devel/44147507-65a4-4f21-aada-fa647f53ffd0@suse.com/
>>>
>>> *  Utilize ucode_force and remove opt_ucode_allow_same (v7)
>>>    -  Fouad Hilly
>>>    -https://lore.kernel.org/xen-devel/20240822130426.492931-4-fouad.hilly@cloud.com/
>>>
>>> *  Switch flat driver to use phys dst for ext ints (v2)
>>>    -  Matthew Barnes
>>>    -https://lore.kernel.org/xen-devel/0db68e62ffc428f553a30397df1e79068d26bb5f.1728311378.git.matthew.barnes@cloud.com/
>>>
>>> *  x86/shutdown: change default reboot method preference (v1)
>>>    -  Roger Pau Monne
>>>    -https://lore.kernel.org/xen-devel/20240802105613.99197-1-roger.pau@citrix.com/
>>>
>>> *  x86/HVM: drop stdvga caching mode (v2)
>>>    -  Jan Beulich
>>>    -https://lore.kernel.org/xen-devel/dc3faf7d-0690-46e6-8fbc-67a177a1e171@suse.com/T/#mc8ca51cdbfb6ba26ea6b4624059d40ea075c2117
>>>
>>> *  Fix module-handling use-after-free's (v2)
>>>    -  Andrew Cooper
>>>    -https://lore.kernel.org/xen-devel/20241106003938.3453243-1-andrew.cooper3@citrix.com/T/#mdf923bdf63b034a6493bf62beeead280b92a38ed
>>>
>>> *  Reuse 32 bit C code more safely (v4)
>>>    -  Frediano Ziglio
>>>    -https://lore.kernel.org/xen-devel/20241014085332.3254546-1-frediano.ziglio@cloud.com/T/#m53e36815ddec2511ddd1fa8d1a7ed9a27c0cd0f7
>>>
>>> *  xen: address violations of MISRA C Rule 13.6 (v2)
>>>    -  Federico Serafini
>>>    -https://lore.kernel.org/xen-devel/cover.1727690180.git.federico.serafini@bugseng.com/T/#mbec702db211240305e0d35649e65627d9fa75a29
>>>
>>> *  x86/ucode: Simplify/fix loading paths further (v2)
>>>    -  Andrew Cooper
>>>    -https://lore.kernel.org/xen-devel/20241112211915.1473121-1-andrew.cooper3@citrix.com/
>>>
>>> *  x86: address violations of MISRA C Rule 16.3 (v2)
>>>    -  Federico Serafini
>>>    -https://patchew.org/Xen/cover.1731485149.git.federico.serafini@bugseng.com/
>>>
>>> *  iommu/x86: fixes/improvements for unity range checks (v4 ( [PATCH 4/4] iommu/x86: make unity range checking more strict? ))
>>>    -  Roger Pau Monne
>>>    -https://lore.kernel.org/xen-devel/20240201170159.66330-1-roger.pau@citrix.com/
>>>
>>> *  x86/pvh: Support relocating dom0 kernel (v7)
>>>    -  Jason Andryuk
>>>    -https://patchew.org/Xen/20240404212519.16401-1-jason.andryuk@amd.com/
>>>
>>> === ARM ===
>>>
>>> *  Prerequisite patches for R82 upstreaming (v4)
>>>    -  Luca Fancellu
>>>    -https://patchew.org/Xen/20241203094811.427076-1-luca.fancellu@arm.com/
>>>
>>> *  Enable early bootup of AArch64 MPU systems (Part 2) (v3)
>>>    -  Ayan Kumar Halder
>>>    -https://patchew.org/Xen/20241204172243.1229942-1-ayan.kumar.halder@amd.com/
>>>
>>> *  Enable early bootup of AArch64 MPU systems (v6)
>>>    -  Ayan Kumar Halder
>>>    -https://patchew.org/Xen/20241118121250.4027441-1-ayan.kumar.halder@amd.com/
>>>
>>> *  Add support for S32CC platforms and LINFlexD UART (v6)
>>>    -  Andrei Cherechesu
>>>    -https://patchew.org/Xen/20241219112315.2461048-1-andrei.cherechesu@oss.nxp.com/
>>>
>>> *  Arm cache coloring (v9 -> v11)
>>>    -  Carlo Nonato
>>>    -https://lore.kernel.org/xen-devel/20241202165921.249585-1-carlo.nonato@minervasys.tech/
>>>
>>> *  ffa: Improvements and fixes (v2 -> v3)
>>>    -  Bertrand Marquis
>>>    -https://lore.kernel.org/xen-devel/cover.1732702210.git.bertrand.marquis@arm.com/
>>>
>>> *  iommu/ipmmu-vmsa: Add Renesas R8A779G0 (R-Car V4H) support (v1)
>>>    -  Grygorii Strashko
>>>    -https://lore.kernel.org/xen-devel/6ab4ad29-404d-4f5c-8582-5d2f492fd549@xen.org/T/#t
>>>
>>> *  xen/arm: dt overlay fixes (v2)
>>>    -  Michal Orzel
>>>    -https://lore.kernel.org/xen-devel/20241004122220.234817-1-michal.orzel@amd.com/T/#md51a060b93fe72f17637d6d72e3d4e2296cb4078
>>>
>>> *  xen/arm: Add emulation of Debug Data Transfer Registers (v6)
>>>    -  Ayan Kumar Halder
>>>    -https://patchew.org/Xen/20240307123943.1991755-1-ayan.kumar.halder@amd.com/
>>>
>>> === RISC-V ===
>>>
>>> *  Unflattening and relocation of host device tree (v1)
>>>    -  Oleksii Kurochko
>>>    -https://patchew.org/Xen/cover.1732709650.git.oleksii.kurochko@gmail.com/
>>>
>>> *  initialize bootinfo from dtb (v2)
>>>    -  Oleksii Kurochko
>>>    -https://lore.kernel.org/xen-devel/cover.1728481578.git.oleksii.kurochko@gmail.com/T/#m543bf84d47f0ea738938a9a442cd144bb34f7316
>>>
>>> *  Register Xen's load address as a boot module (v3)
>>>    -  Oleksii Kurochko
>>>    -https://lore.kernel.org/xen-devel/cover.1728472163.git.oleksii.kurochko@gmail.com/T/#t
>>>
>>> *  device tree mapping (v9)
>>>    -  Oleksii Kurochko
>>>    -https://lore.kernel.org/xen-devel/cover.1727781468.git.oleksii.kurochko@gmail.com/T/#t
>>>
>>> *  Setup memory management (v5)
>>>    -  Oleksii Kurochko
>>>    -https://lore.kernel.org/xen-devel/cover.1731344883.git.oleksii.kurochko@gmail.com/T/#m9f76f1b685896ea603a2b153e05104c7405a7d28
>>>
>>> Have a good week!
>>>
>>> Best regards,
>>>   Oleksii
--------------ejHcb9dg0JEaT8xYBCWPiexq
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 1/8/25 2:50 AM, Denis Mukhin wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:l-i2X3sIZcusZX5bDJSb2KhxOQvqVE5V6Igl7FnlCVndzUmgX8ZfceC6w1kc9xpSIO8unl92qJdnZWNl5sA5PhXfv6OWpvcEmKY-qX2-pK0=@proton.me">
      <pre wrap="" class="moz-quote-pre">On Tuesday, January 7th, 2025 at 9:37 AM, Oleksii Kurochko <a class="moz-txt-link-rfc2396E" href="mailto:oleksii.kurochko@gmail.com">&lt;oleksii.kurochko@gmail.com&gt;</a> wrote:

</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">Missed to add one item to x86 about "x86/efi: Fix booting when NX is disabled".

Please find some details below.



On 1/7/25 6:31 PM, Oleksii Kurochko wrote:

</pre>
        <blockquote type="cite">
          <pre wrap="" class="moz-quote-pre">Hello everyone,

This email only tracks big items for xen.git tree. Please reply for items you
would like to see in 4.20 so that people have an idea what is going on and
prioritise accordingly.

You're welcome to provide description and use cases of the feature you're
working on.

= Timeline =

* Last posting date: Nov 29, 2024
* Feature freeze date: Dec 20, 2024
---&gt; We are here
* RC1: Jan 10, 2025
* Hard code freeze: Jan 17, 2025
* Release: Feb 21, 2025
( current release schedule: <a class="moz-txt-link-freetext" href="https://wiki.xenproject.org/wiki/Xen_Project_X.YY_Release_Notes">https://wiki.xenproject.org/wiki/Xen_Project_X.YY_Release_Notes</a> )

This will likely be the last Xen 4.20 Development Update email, as we have
passed the feature freeze date, so no significant updates are expected until
the Xen 4.20 release.

The next email with development updates will cover Xen 4.21.

Below, you can find a summary of the tasks completed by the end of
December 2024, followed by a list of tasks still in progress ( it is
up-to-date also ), which will be moved to the Xen 4.21 task list.

The following items ( the links for them could be found int the list below )
were moved to completed:

[Dec]:
- x86:
  * x86/mm: miscellaneous fixes.
  * Remove "APX support" task as Jan B. told:
      I think you want to remove this from the list. While I have completed
      work there, I'm not fancying re-basing ahead of the AVX10 work, and hence
      that needs to go in first anyway. Which seems unlikely enough at this
      point, for 4.20.
  * Support device passthrough when dom0 is PVH on Xen.
- Arm:
  * Prerequisite patches for R82 upstreaming
  * Add support for S32CC platforms and LINFlexD UART.
  * Arm cache coloring.
  * ffa: Improvements and fixes.
  * Enable early bootup of AArch64 MPU systems.
  * Enable early bootup of AArch64 MPU systems (Part 2)
- RISC-V:
  * Unflattening and relocation of host device tree

[Nov]:
- Hypervisor:
  * drivers/char: rename arm-uart.c to uart-init.c
  * Move gic_preinit() to common code
  * stubdom: reduce xenstore library dependencies
  * xen/trace: Treewide API cleanup
- x86:
  * x86/HVM: drop stdvga caching mode
  * Fix module-handling use-after-free's
  * Reuse 32 bit C code more safely
  * xen: address violations of MISRA C Rule 13.6
  * x86/ucode: Simplify/fix loading paths further
  * x86: address violations of MISRA C Rule 16.3
  * iommu/x86: fixes/improvements for unity range checks
  * x86/pvh: Support relocating dom0 kernel
- Arm:
  * xen/arm: Add emulation of Debug Data Transfer Registers
- RISC-V:
  * Setup memory management


* Full list of items : *

= Projects =

== Hypervisor ==

*  Remove the directmap (v4)
  -  Elias El Yandouzi
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/f6973275-0d7e-4db4-b949-f21e530e1dfc@citrix.com/T/#m9733aa717edf032db0cf8f8f6763537b4f30c1f8">https://lore.kernel.org/xen-devel/f6973275-0d7e-4db4-b949-f21e530e1dfc@citrix.com/T/#m9733aa717edf032db0cf8f8f6763537b4f30c1f8</a>

*  remove libxenctrl usage from xenstored (v1 -&gt; v6)
  -  Juergen Gross
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/20250107101711.5980-1-jgross@suse.com/T/#me3a5e025aef6a3431c21e81c670bf09744f2fe35">https://lore.kernel.org/xen-devel/20250107101711.5980-1-jgross@suse.com/T/#me3a5e025aef6a3431c21e81c670bf09744f2fe35</a>

*  automation: Refresh the remaining Debian containers (v2)
  -  Javi Merino
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/cover.1730743077.git.javi.merino@cloud.com/T/#m5d9acb7cf5db3c2be3d6527de14b69b07812314e">https://lore.kernel.org/xen-devel/cover.1730743077.git.javi.merino@cloud.com/T/#m5d9acb7cf5db3c2be3d6527de14b69b07812314e</a>

*  GRUB: Supporting Secure Boot of xen.gz (v1)
  -  Ross Lagerwall
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/20240313150748.791236-1-ross.lagerwall@citrix.com/">https://patchew.org/Xen/20240313150748.791236-1-ross.lagerwall@citrix.com/</a>

*  MSI-X support with qemu in stubdomain, and other related changes (v8)
  -  Marek Marczykowski-Górecki
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/cover.33fb4385b7dd6c53bda4acf0a9e91748b3d7b1f7.1715313192.git-series.marmarek@invisiblethingslab.com/">https://lore.kernel.org/xen-devel/cover.33fb4385b7dd6c53bda4acf0a9e91748b3d7b1f7.1715313192.git-series.marmarek@invisiblethingslab.com/</a>
  -  Only automation patch left to be reviewed/merged.

*  [RFC] Introduce xenbindgen to autogen hypercall structs (v1)
  -  Alejandro Vallejo
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/20241115115200.2824-1-alejandro.vallejo@cloud.com/">https://patchew.org/Xen/20241115115200.2824-1-alejandro.vallejo@cloud.com/</a>

*  Introduce NS8250 UART emulator (v1 -&gt; v2)
  -  Denis Mukhin
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com/">https://patchew.org/Xen/20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com/</a>
</pre>
        </blockquote>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
I have posted v3 recently:
  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com/">https://lore.kernel.org/xen-devel/20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com/</a></pre>
    </blockquote>
    <pre><font face="monospace">Thanks for the update. Interesting that there is no v3 on patchew...
</font></pre>
    <pre><font face="monospace">~ Oleksii</font>
</pre>
    <blockquote type="cite"
cite="mid:l-i2X3sIZcusZX5bDJSb2KhxOQvqVE5V6Igl7FnlCVndzUmgX8ZfceC6w1kc9xpSIO8unl92qJdnZWNl5sA5PhXfv6OWpvcEmKY-qX2-pK0=@proton.me">
      <pre wrap="" class="moz-quote-pre">

</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="" class="moz-quote-pre">
=== x86 ===
</pre>
        </blockquote>
        <pre wrap="" class="moz-quote-pre">
* x86/efi: Fix booting when NX is disabled (v1)
  - Andrew Cooper
  - <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/20240722101838.3946983-1-andrew.cooper3@citrix.com/">https://patchew.org/Xen/20240722101838.3946983-1-andrew.cooper3@citrix.com/</a>

~ Oleksii

</pre>
        <blockquote type="cite">
          <pre wrap="" class="moz-quote-pre">*  Expose consistent topology to guests (v7)
  -  Alejandro Vallejo
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/20241021154600.11745-1-alejandro.vallejo@cloud.com/">https://patchew.org/Xen/20241021154600.11745-1-alejandro.vallejo@cloud.com/</a>

*  Boot modules for Hyperlaunch (v8 -&gt; v9)
  -  Daniel P. Smith
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/20241115131204.32135-1-dpsmith@apertussolutions.com/">https://patchew.org/Xen/20241115131204.32135-1-dpsmith@apertussolutions.com/</a>

*  Address Space Isolation FPU preparations (v2)
  -  Alejandro Vallejo
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/20241105143310.28301-1-alejandro.vallejo@cloud.com/">https://patchew.org/Xen/20241105143310.28301-1-alejandro.vallejo@cloud.com/</a>

*  x86/alternatives: Adjust all insn-relative fields (v2)
  -  Andrew Cooper
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/20241002152725.1841575-1-andrew.cooper3@citrix.com/T/#mac2deaea7e02a343210d61887486433d946ad129">https://lore.kernel.org/xen-devel/20241002152725.1841575-1-andrew.cooper3@citrix.com/T/#mac2deaea7e02a343210d61887486433d946ad129</a>

*  x86emul: misc additions (v5 -&gt; v7)
  -  Jan Beulich
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/3a25cd59-e1cb-4bfc-b868-fb11599d22f5@suse.com/">https://patchew.org/Xen/3a25cd59-e1cb-4bfc-b868-fb11599d22f5@suse.com/</a>

*  x86/HVM: emulation (MMIO) improvements (v2)
  -  Jan Beulich
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/3294f629-f91f-4b5d-9eb0-40a34aa2ec3e@suse.com/">https://patchew.org/Xen/3294f629-f91f-4b5d-9eb0-40a34aa2ec3e@suse.com/</a>

*  x86: support AVX10 (v2 -&gt; v3)
  -  Jan Beulich
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/516b7f9a-048e-409d-8a4e-89aeb8ffacc4@suse.com/">https://patchew.org/Xen/516b7f9a-048e-409d-8a4e-89aeb8ffacc4@suse.com/</a>

*  VT-d: SATC handling; ATS: tidying (v2)
  -  Jan Beulich
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/64b028be-2197-4951-ae5b-32f9eabfa84a@suse.com/">https://patchew.org/Xen/64b028be-2197-4951-ae5b-32f9eabfa84a@suse.com/</a>

*  x86: parallelize AP bring-up during boot (v1)
  -  Krystian Hebel
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/cover.1699982111.git.krystian.hebel@3mdeb.com/">https://lore.kernel.org/xen-devel/cover.1699982111.git.krystian.hebel@3mdeb.com/</a>

*  x86/spec-ctrl: IBPB improvements (v4)
  -  Jan Beulich
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/06591b64-2f05-a4cc-a2f3-a74c3c4a76d6@suse.com/">https://patchew.org/Xen/06591b64-2f05-a4cc-a2f3-a74c3c4a76d6@suse.com/</a>

*  Move some boot code from assembly to C (v2)
  -  Frediano Ziglio
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/20241122093358.478774-1-frediano.ziglio@cloud.com/">https://patchew.org/Xen/20241122093358.478774-1-frediano.ziglio@cloud.com/</a>

*  Hyperlaunch device tree for dom0 (v1 -&gt; v2)
  -  Daniel P. Smith
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/20241226165740.29812-1-dpsmith@apertussolutions.com/">https://patchew.org/Xen/20241226165740.29812-1-dpsmith@apertussolutions.com/</a>

*  x86: memcpy() / memset() (non-)ERMS flavors plus fallout (v3)
  -  Jan Beulich
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/e7314ac8-ed09-4da8-b915-09409b01fe77@suse.com/">https://patchew.org/Xen/e7314ac8-ed09-4da8-b915-09409b01fe77@suse.com/</a>

*  amd-pstate CPU Performance Scaling Driver (v1)
  -  Penny Zheng
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/20241203081111.463400-1-Penny.Zheng@amd.com/">https://patchew.org/Xen/20241203081111.463400-1-Penny.Zheng@amd.com/</a>

=== ARM ===

*  Add Virtio-PCI for dom0less on ARM (v1)
  -  Edgar E. Iglesias
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/20240924162359.1390487-1-edgar.iglesias@gmail.com/T/#mfa148991b9408f223a079d4cef610244d5b04c2b">https://lore.kernel.org/xen-devel/20240924162359.1390487-1-edgar.iglesias@gmail.com/T/#mfa148991b9408f223a079d4cef610244d5b04c2b</a>

*  PCI devices passthrough on Arm, part 3 (v16)
  -  Stewart Hildebrand
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/20240522225927.77398-1-stewart.hildebrand@amd.com/">https://patchew.org/Xen/20240522225927.77398-1-stewart.hildebrand@amd.com/</a>
  -  Patches are Acked but for some reason last two patches aren't merged.

*  DOMCTL-based guest magic region allocation for 11 domUs (v4)
  -  Henry Wang
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/20240409045357.236802-1-xin.wang2@amd.com/">https://patchew.org/Xen/20240409045357.236802-1-xin.wang2@amd.com/</a>

=== RISCV ===

=== PPC ===

*  Early Boot Allocation on Power (v5)
  -  Shawn Anastasio
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/cover.1727388925.git.sanastasio@raptorengineering.com/T/#m8cac91a93b56a359fa2d5f08596c4be61dca290d">https://lore.kernel.org/xen-devel/cover.1727388925.git.sanastasio@raptorengineering.com/T/#m8cac91a93b56a359fa2d5f08596c4be61dca290d</a>

== Completed ==

=== Hypervisor ===

*  libxl: Implement QEMU command line probe (v1)
  -  Anthony PERARD
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/20240827100328.23216-1-anthony.perard@vates.tech/T/#mdef23cefc2532ab0c9d7460290cef26780cf97cb">https://lore.kernel.org/xen-devel/20240827100328.23216-1-anthony.perard@vates.tech/T/#mdef23cefc2532ab0c9d7460290cef26780cf97cb</a>

*  xen/bitops: hweight() cleanup/improvements (v3)
  -  Andrew Cooper
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/20240904225530.3888315-1-andrew.cooper3@citrix.com/T/#me22e08f7477be725122dd9b97d29d272e3b586c4">https://lore.kernel.org/xen-devel/20240904225530.3888315-1-andrew.cooper3@citrix.com/T/#me22e08f7477be725122dd9b97d29d272e3b586c4</a>

*  Move percpu code to common (v2)
  -  Oleksii Kurochko
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/cover.1727185495.git.oleksii.kurochko@gmail.com/T/#mf93394c46f15cbdcfc873de2d52d862a8b70da7f">https://lore.kernel.org/xen-devel/cover.1727185495.git.oleksii.kurochko@gmail.com/T/#mf93394c46f15cbdcfc873de2d52d862a8b70da7f</a>

*  xen/livepatch: improvements to loading (v3)
  -  Roger Pau Monne
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/20240926101431.97444-1-roger.pau@citrix.com/T/#ma3f65948b065dc443aea2192873a3b3dfa52a2d7">https://lore.kernel.org/xen-devel/20240926101431.97444-1-roger.pau@citrix.com/T/#ma3f65948b065dc443aea2192873a3b3dfa52a2d7</a>

*  Move {acpi_}device_init() and device_get_class() to common code (v5)
  -  Oleksii Kurochko
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/17c7d988e45d7c82448b81fe66b01a5ceca0c15e.camel@gmail.com/T/#m68bd00d4f8b3724e83ba13024e94b15b58a28829">https://lore.kernel.org/xen-devel/17c7d988e45d7c82448b81fe66b01a5ceca0c15e.camel@gmail.com/T/#m68bd00d4f8b3724e83ba13024e94b15b58a28829</a>

*  blkif: reconcile protocol specification with in-use implementations (v1)
  -  Roger Pau Monne
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/20240903141923.72241-1-roger.pau@citrix.com/">https://lore.kernel.org/xen-devel/20240903141923.72241-1-roger.pau@citrix.com/</a>

*  Move gic_preinit() to common code (v5)
  -  Oleksii Kurochko
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/151ac176ff02d2ff9b7f87e3c02b9ce0472720fa.1732288620.git.oleksii.kurochko@gmail.com/">https://lore.kernel.org/xen-devel/151ac176ff02d2ff9b7f87e3c02b9ce0472720fa.1732288620.git.oleksii.kurochko@gmail.com/</a>

*  stubdom: reduce xenstore library dependencies (v1)
  -  Juergen Gross
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/20241010155459.22389-1-jgross@suse.com/T/#m8b5af386e2d288961bb6e8f7839650e0cab96a83">https://lore.kernel.org/xen-devel/20241010155459.22389-1-jgross@suse.com/T/#m8b5af386e2d288961bb6e8f7839650e0cab96a83</a>

*  xen/trace: Treewide API cleanup (v7)
  -  Andrew Cooper
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/20240318163552.3808695-1-andrew.cooper3@citrix.com/">https://patchew.org/Xen/20240318163552.3808695-1-andrew.cooper3@citrix.com/</a>

=== x86 ===

*  x86/mm: miscellaneous fixes (v2 -&gt; v3)
  -  Roger Pau Monne
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/20241114145715.59777-1-roger.pau@citrix.com/">https://patchew.org/Xen/20241114145715.59777-1-roger.pau@citrix.com/</a>

*  Support device passthrough when dom0 is PVH on Xen (v16)
  -  Jiqian Chen
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/20240930034250.2682265-1-Jiqian.Chen@amd.com/T/#m5d557d76f290ff5b5550c1443cab5774d397e526">https://lore.kernel.org/xen-devel/20240930034250.2682265-1-Jiqian.Chen@amd.com/T/#m5d557d76f290ff5b5550c1443cab5774d397e526</a>

*  Drop Xeon Phi support (v1)
  -  Jan Beulich
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/44147507-65a4-4f21-aada-fa647f53ffd0@suse.com/">https://lore.kernel.org/xen-devel/44147507-65a4-4f21-aada-fa647f53ffd0@suse.com/</a>

*  Utilize ucode_force and remove opt_ucode_allow_same (v7)
  -  Fouad Hilly
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/20240822130426.492931-4-fouad.hilly@cloud.com/">https://lore.kernel.org/xen-devel/20240822130426.492931-4-fouad.hilly@cloud.com/</a>

*  Switch flat driver to use phys dst for ext ints (v2)
  -  Matthew Barnes
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/0db68e62ffc428f553a30397df1e79068d26bb5f.1728311378.git.matthew.barnes@cloud.com/">https://lore.kernel.org/xen-devel/0db68e62ffc428f553a30397df1e79068d26bb5f.1728311378.git.matthew.barnes@cloud.com/</a>

*  x86/shutdown: change default reboot method preference (v1)
  -  Roger Pau Monne
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/20240802105613.99197-1-roger.pau@citrix.com/">https://lore.kernel.org/xen-devel/20240802105613.99197-1-roger.pau@citrix.com/</a>

*  x86/HVM: drop stdvga caching mode (v2)
  -  Jan Beulich
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/dc3faf7d-0690-46e6-8fbc-67a177a1e171@suse.com/T/#mc8ca51cdbfb6ba26ea6b4624059d40ea075c2117">https://lore.kernel.org/xen-devel/dc3faf7d-0690-46e6-8fbc-67a177a1e171@suse.com/T/#mc8ca51cdbfb6ba26ea6b4624059d40ea075c2117</a>

*  Fix module-handling use-after-free's (v2)
  -  Andrew Cooper
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/20241106003938.3453243-1-andrew.cooper3@citrix.com/T/#mdf923bdf63b034a6493bf62beeead280b92a38ed">https://lore.kernel.org/xen-devel/20241106003938.3453243-1-andrew.cooper3@citrix.com/T/#mdf923bdf63b034a6493bf62beeead280b92a38ed</a>

*  Reuse 32 bit C code more safely (v4)
  -  Frediano Ziglio
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/20241014085332.3254546-1-frediano.ziglio@cloud.com/T/#m53e36815ddec2511ddd1fa8d1a7ed9a27c0cd0f7">https://lore.kernel.org/xen-devel/20241014085332.3254546-1-frediano.ziglio@cloud.com/T/#m53e36815ddec2511ddd1fa8d1a7ed9a27c0cd0f7</a>

*  xen: address violations of MISRA C Rule 13.6 (v2)
  -  Federico Serafini
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/cover.1727690180.git.federico.serafini@bugseng.com/T/#mbec702db211240305e0d35649e65627d9fa75a29">https://lore.kernel.org/xen-devel/cover.1727690180.git.federico.serafini@bugseng.com/T/#mbec702db211240305e0d35649e65627d9fa75a29</a>

*  x86/ucode: Simplify/fix loading paths further (v2)
  -  Andrew Cooper
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/20241112211915.1473121-1-andrew.cooper3@citrix.com/">https://lore.kernel.org/xen-devel/20241112211915.1473121-1-andrew.cooper3@citrix.com/</a>

*  x86: address violations of MISRA C Rule 16.3 (v2)
  -  Federico Serafini
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/cover.1731485149.git.federico.serafini@bugseng.com/">https://patchew.org/Xen/cover.1731485149.git.federico.serafini@bugseng.com/</a>

*  iommu/x86: fixes/improvements for unity range checks (v4 ( [PATCH 4/4] iommu/x86: make unity range checking more strict? ))
  -  Roger Pau Monne
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/20240201170159.66330-1-roger.pau@citrix.com/">https://lore.kernel.org/xen-devel/20240201170159.66330-1-roger.pau@citrix.com/</a>

*  x86/pvh: Support relocating dom0 kernel (v7)
  -  Jason Andryuk
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/20240404212519.16401-1-jason.andryuk@amd.com/">https://patchew.org/Xen/20240404212519.16401-1-jason.andryuk@amd.com/</a>

=== ARM ===

*  Prerequisite patches for R82 upstreaming (v4)
  -  Luca Fancellu
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/20241203094811.427076-1-luca.fancellu@arm.com/">https://patchew.org/Xen/20241203094811.427076-1-luca.fancellu@arm.com/</a>

*  Enable early bootup of AArch64 MPU systems (Part 2) (v3)
  -  Ayan Kumar Halder
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/20241204172243.1229942-1-ayan.kumar.halder@amd.com/">https://patchew.org/Xen/20241204172243.1229942-1-ayan.kumar.halder@amd.com/</a>

*  Enable early bootup of AArch64 MPU systems (v6)
  -  Ayan Kumar Halder
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/20241118121250.4027441-1-ayan.kumar.halder@amd.com/">https://patchew.org/Xen/20241118121250.4027441-1-ayan.kumar.halder@amd.com/</a>

*  Add support for S32CC platforms and LINFlexD UART (v6)
  -  Andrei Cherechesu
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/20241219112315.2461048-1-andrei.cherechesu@oss.nxp.com/">https://patchew.org/Xen/20241219112315.2461048-1-andrei.cherechesu@oss.nxp.com/</a>

*  Arm cache coloring (v9 -&gt; v11)
  -  Carlo Nonato
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/20241202165921.249585-1-carlo.nonato@minervasys.tech/">https://lore.kernel.org/xen-devel/20241202165921.249585-1-carlo.nonato@minervasys.tech/</a>

*  ffa: Improvements and fixes (v2 -&gt; v3)
  -  Bertrand Marquis
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/cover.1732702210.git.bertrand.marquis@arm.com/">https://lore.kernel.org/xen-devel/cover.1732702210.git.bertrand.marquis@arm.com/</a>

*  iommu/ipmmu-vmsa: Add Renesas R8A779G0 (R-Car V4H) support (v1)
  -  Grygorii Strashko
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/6ab4ad29-404d-4f5c-8582-5d2f492fd549@xen.org/T/#t">https://lore.kernel.org/xen-devel/6ab4ad29-404d-4f5c-8582-5d2f492fd549@xen.org/T/#t</a>

*  xen/arm: dt overlay fixes (v2)
  -  Michal Orzel
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/20241004122220.234817-1-michal.orzel@amd.com/T/#md51a060b93fe72f17637d6d72e3d4e2296cb4078">https://lore.kernel.org/xen-devel/20241004122220.234817-1-michal.orzel@amd.com/T/#md51a060b93fe72f17637d6d72e3d4e2296cb4078</a>

*  xen/arm: Add emulation of Debug Data Transfer Registers (v6)
  -  Ayan Kumar Halder
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/20240307123943.1991755-1-ayan.kumar.halder@amd.com/">https://patchew.org/Xen/20240307123943.1991755-1-ayan.kumar.halder@amd.com/</a>

=== RISC-V ===

*  Unflattening and relocation of host device tree (v1)
  -  Oleksii Kurochko
  -  <a class="moz-txt-link-freetext" href="https://patchew.org/Xen/cover.1732709650.git.oleksii.kurochko@gmail.com/">https://patchew.org/Xen/cover.1732709650.git.oleksii.kurochko@gmail.com/</a>

*  initialize bootinfo from dtb (v2)
  -  Oleksii Kurochko
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/cover.1728481578.git.oleksii.kurochko@gmail.com/T/#m543bf84d47f0ea738938a9a442cd144bb34f7316">https://lore.kernel.org/xen-devel/cover.1728481578.git.oleksii.kurochko@gmail.com/T/#m543bf84d47f0ea738938a9a442cd144bb34f7316</a>

*  Register Xen's load address as a boot module (v3)
  -  Oleksii Kurochko
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/cover.1728472163.git.oleksii.kurochko@gmail.com/T/#t">https://lore.kernel.org/xen-devel/cover.1728472163.git.oleksii.kurochko@gmail.com/T/#t</a>

*  device tree mapping (v9)
  -  Oleksii Kurochko
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/cover.1727781468.git.oleksii.kurochko@gmail.com/T/#t">https://lore.kernel.org/xen-devel/cover.1727781468.git.oleksii.kurochko@gmail.com/T/#t</a>

*  Setup memory management (v5)
  -  Oleksii Kurochko
  -  <a class="moz-txt-link-freetext" href="https://lore.kernel.org/xen-devel/cover.1731344883.git.oleksii.kurochko@gmail.com/T/#m9f76f1b685896ea603a2b153e05104c7405a7d28">https://lore.kernel.org/xen-devel/cover.1731344883.git.oleksii.kurochko@gmail.com/T/#m9f76f1b685896ea603a2b153e05104c7405a7d28</a>

Have a good week!

Best regards,
 Oleksii
</pre>
        </blockquote>
      </blockquote>
    </blockquote>
  </body>
</html>

--------------ejHcb9dg0JEaT8xYBCWPiexq--


From xen-devel-bounces@lists.xenproject.org Wed Jan 08 09:02:01 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 09:02:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866991.1278384 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVRwn-0006TU-Jz; Wed, 08 Jan 2025 09:01:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866991.1278384; Wed, 08 Jan 2025 09:01:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVRwn-0006TL-HD; Wed, 08 Jan 2025 09:01:53 +0000
Received: by outflank-mailman (input) for mailman id 866991;
 Wed, 08 Jan 2025 09:01: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
 <SRS0=D7HK=UA=arm.com=Luca.Fancellu@srs-se1.protection.inumbo.net>)
 id 1tVRwm-0006TF-PT
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 09:01:52 +0000
Received: from EUR05-DB8-obe.outbound.protection.outlook.com
 (mail-db8eur05on20610.outbound.protection.outlook.com
 [2a01:111:f403:2614::610])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 32de0065-cd9f-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 10:01:51 +0100 (CET)
Received: from DBAPR08MB5798.eurprd08.prod.outlook.com (2603:10a6:10:1a6::21)
 by AS8PR08MB9696.eurprd08.prod.outlook.com (2603:10a6:20b:614::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8314.17; Wed, 8 Jan
 2025 09:01:44 +0000
Received: from DBAPR08MB5798.eurprd08.prod.outlook.com
 ([fe80::4a66:d3e2:570:9632]) by DBAPR08MB5798.eurprd08.prod.outlook.com
 ([fe80::4a66:d3e2:570:9632%4]) with mapi id 15.20.8335.010; Wed, 8 Jan 2025
 09:01:44 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 32de0065-cd9f-11ef-a0df-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=c7hXHnOnie0g/T93wGsJYHQkQTXT+NDpUy1LMnl61E1weEwf6jGUdi9h0zbojtkdoqcdBzyKkEZRj82RAC3OAhHw831a4FlIsREPDEilzZDu5hUAR3ta+5v0IENRqv/C9MHxDXok0+NvpkPZdcn67W7CjEZssE4Oz4Uz2A0iIhVyJDMSzmcqvGuNKC0dOBOqmiUM+Adsc+3cvHwuDHp5wbJf0fHKhrR2Pub1oZHn/E27Re2Uj2XYtICoLkyc/lOJp2CaNxd7/jzFuc040tL4jk4zoId8glgIMAImhT8pIZZvif/zqF3XTTs/+Q680IGW8XVX1yis29SzSKhdoCfmrQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=BpUZZj6Vod7rrCGnR+H55XmOFSKDUdg5PMyT2DI5QGI=;
 b=Ebcjd+fa3mQ3NNS+ddV0WR9Kz2Cu8ZF2XcyNwnf1yxe+PjGxOeaEAvD3XpFaDQwDYLvNjbAsXZDBstXZbquUge4m+YqB6oLhXgw9tOK4tgJPqtmL6U084/Svlo5jUCDtNJ1wmuxzpxQAR6YA2CJXTR+HXYv1iesWiiUuEqufHy+6qBROQLvbk+BPzangcjPrd00IVy5cH6+8t6MDhUU5WWNTKoprpD4RoIOdU+1YeQGkvDbB0pS/UTyr02skXGJ1BDjuHcoRkeWi/DdLf+Pa8JMufR+3VkLWK82uFFPRDgz2tlFG61lsqtzHlmahiBQfng9bE3JqdYUAs8c6xiWaFg==
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=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=BpUZZj6Vod7rrCGnR+H55XmOFSKDUdg5PMyT2DI5QGI=;
 b=YBINreV/eY9URkbHIfvWJXkIMEczRKdAY4QRCaB4sxI9aQBykyjM09cmI5tCql+PL3DNQYjoNefac6yyXN6AZrIFZEcQLW554MNULEnYzogkTJCveHzNVs32Hd6N83Hvdq5bXiuclMYpXHi2yqMt8vgOFKFITEy68NoPXjObmnM=
From: Luca Fancellu <Luca.Fancellu@arm.com>
To: Michal Orzel <michal.orzel@amd.com>
CC: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Stefano
 Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand
 Marquis <Bertrand.Marquis@arm.com>, Volodymyr Babchuk
	<Volodymyr_Babchuk@epam.com>, "oleksii.kurochko@gmail.com"
	<oleksii.kurochko@gmail.com>
Subject: Re: [for-4.20][PATCH] xen/arm64: Drop relocate_and_switch_ttbr() stub
Thread-Topic: [for-4.20][PATCH] xen/arm64: Drop relocate_and_switch_ttbr()
 stub
Thread-Index: AQHbYaMBWdxQ1v99706M5qRoUKAKv7MMlHaA
Date: Wed, 8 Jan 2025 09:01:44 +0000
Message-ID: <5DA66273-7255-4EDB-A3F5-C1F4F61C9CE1@arm.com>
References: <20250108075719.84967-1-michal.orzel@amd.com>
In-Reply-To: <20250108075719.84967-1-michal.orzel@amd.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.200.121)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DBAPR08MB5798:EE_|AS8PR08MB9696:EE_
x-ms-office365-filtering-correlation-id: 525fabdb-3796-4c87-9a29-08dd2fc31322
x-checkrecipientrouted: true
nodisclaimer: true
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?us-ascii?Q?j1C0CXhJJM46RO6Vx+g0HSBj27FibHjoehw0viImRM+V94HSFzH0R5HElvOo?=
 =?us-ascii?Q?OEEJt3ePS2qLKDvp5XzuF2TsxzSHM3qb2VnHS22/piXZPKj2X2/oXZO+Zd1A?=
 =?us-ascii?Q?3JPTzBCJ7EM9vHBcJkhaW5BVKyniIDI6YPju8dpDb8P4hY40kCICq/Fpm9Of?=
 =?us-ascii?Q?A/javG+x2dpxpsmxL3XtIqhIcGEzbrxYIvRc6eosdAz7zlIqMz3/U6jt+IVB?=
 =?us-ascii?Q?VeStqskL7Uc4a0surZaiKRlBLLP05neqOcDNq5jlAEOYvzGzMuqAHTV6IL5I?=
 =?us-ascii?Q?02UxxlV0QhzkXkc6+yShNrihc7dbYdZTpTgJC8QrfOkyWEglGpCyUPltWrqu?=
 =?us-ascii?Q?5bKj4PK54ALCzhRn992Dx8+ihUKMthtePea1ZoeGYTDjB5PNgrDbeCCxwvbl?=
 =?us-ascii?Q?kIWnlFzHhmE3zaITMne5UyXocgE0Ym/wRkWCBcyYhDTbFVBmIcIER7qEzGEj?=
 =?us-ascii?Q?PuQy3Ea5GK3qEuLA5gb16yZ0v/bBbyz2199eZ+AwJixaoo5YHOIy9EYsL1Dj?=
 =?us-ascii?Q?zjm4T3tw3K9jHtGY1JmuGyzXAsfCj+SQigbdFvahjjRe2M/sa6aeQcOWWB4p?=
 =?us-ascii?Q?dOngz/jslgkeyzNSqektwsYfi8mRYDsPoN1c/U/hv5kEFOWbKLK86VCBC2fe?=
 =?us-ascii?Q?cJS4Wog755UHjkFUSOjfYRqJjtY5Uo0R3vmJKDOfxBz6SUycNiGBtbD43pZl?=
 =?us-ascii?Q?/4ANnnh/UT+4jnFZneoODIkQUMnAXkMCnOD75ZqSbc+nrSoQlp+pYsg01f0w?=
 =?us-ascii?Q?1XSFfBgx9ZYv4EweT5Y6gORJTfTgrlsTDY0xgJyTqcbma/FT9zXPQZIRVkYu?=
 =?us-ascii?Q?Ntcs5Mn08jqaEofU1Ysg/ZA2Rjtc4KMdcUf2WO4QbVLPDFz4Uk/TWm1MZnvB?=
 =?us-ascii?Q?jvukIg+lFd1hdvF0eUT6gQrv03fi102/PN0ZWWZqhzlqqFgfwAbcFF5n13Ge?=
 =?us-ascii?Q?dHFvu2K9MzTL5ck2Fm5yCLapl6lxp0L3QwDudyXolMO0PXbmt7TjGyf/prYH?=
 =?us-ascii?Q?OuXVFMCgbpQiS6LqN5dKa5/8pMGvqjQaG09gsgi9eWaJf/Tqmoh35xvNNUq8?=
 =?us-ascii?Q?59EJskbQFmJpnu8UFYlwdlFzTb1I/ePgnFez/gZUSSqzqOEdSWAlg8kJ5Onk?=
 =?us-ascii?Q?RyfRlTtNGIQzmDnHfxK2WuhX/20YvRb2CZ0rvoBscmYj/Aq2dD/Dt+XcszIH?=
 =?us-ascii?Q?yc16sYkTZ6m0DKCS9UgGEi2AhQd6XfKG93ARAXIeATgOyldQfIBUFB5NNwQ9?=
 =?us-ascii?Q?gP5lLiWxZM1y/E2iYJ0c9Ox18jM0IILBiZ03/uR46vxmnbHC+hbr9mkbiPiZ?=
 =?us-ascii?Q?U8T9CKVkCwXevgaanOYU/J6xGbAm11Lkctk1dZd2uFNMy0vREMJlUAuhm37W?=
 =?us-ascii?Q?2aoSkiwpeYokzmzegDxZgEu29S2WtG9sdY6VTQicamtk0hB8zYqzy2t0aKtO?=
 =?us-ascii?Q?nOUebua0wKwOouMyviW+/CTAcq2ghTL8?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DBAPR08MB5798.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?oD3uZnaz/dyP+3i+ERSVMF8fyyjkQT0GSFOdaCwaFh4SPLOJsEmHGaD0jlzH?=
 =?us-ascii?Q?v2ms4QM19QvzgsKY2PFrqGnPqmf5AO1Dssiu/v3ibR917DCw16eSpeVzBQHK?=
 =?us-ascii?Q?lXpn4pPYR42PtYtSZTZ++TQlxTUf2ZoCZAAxCRRaYMxQTgJzRPA3DNPQ6vNP?=
 =?us-ascii?Q?utNWUj8NUgz87pRmoeENDuK64Jvv2xAQZWiMfEQO+ciZ80loSO8l34Jq+1K1?=
 =?us-ascii?Q?HzgV+TRoSp+nvHsEQoQzwdqAbImSsTrz3D7b2h1L6DZrx2WyhhCuTAeaMHIm?=
 =?us-ascii?Q?p1dDKUzcGzqOZ4JYo2qjvI9mf9Ih6G/jNUoKO3a5EkdYHWKwlNndF+HjzL1h?=
 =?us-ascii?Q?iDuV48zGRDldLub22NtaLBUIImgrlMFOxYys2lQY33XsD/6k1+a6Gs5fv4ua?=
 =?us-ascii?Q?wna8/Y2rCIbugKHwCWwSoeXr7psnrzxSGQZKHFn4lkIhT9GKPXp6CkOJBKJ5?=
 =?us-ascii?Q?NJyuRxwV7d15grKKbmt93bT3/nPcVAnCkf2zPcqDh7uTUkpS904T90YUDMjP?=
 =?us-ascii?Q?11OyWaXB3Dv5GZZW8MpphaxAliTdlSVsgLnFzHe7ZLwpLq0hFzjoZFbwwc7+?=
 =?us-ascii?Q?4/Rb7qpYy8gv0XtEAr4IugQE4qmtfTwHnwfYMRWPrqMeRbw40vN2bxz9MTW2?=
 =?us-ascii?Q?E15SWPzqg1O43Gmmy/D9usCUu14iaVlT5HHgNonBN8gf3qiP/fRLzfabQze4?=
 =?us-ascii?Q?uCwPNPKy+0vvs5aTASpAUMGBB59fukctyRHPTpRq9bwZhtEvbkGnnTLW+tOv?=
 =?us-ascii?Q?1BAZ7OzRYE4XS/GhaF+JsxYHR0VQD/9ChOasz8jZRigeqVttjyaEMT0CdU5j?=
 =?us-ascii?Q?SlhrBebTH2XQMrx3nsxiZvRGuuHt0u2eRO8rX6dOnmBbX/46f8poDVfQScsQ?=
 =?us-ascii?Q?Vz60+KwYepS0KYpKo4UQOV0YSieuJxaQisjTuULe6hIppXBCdTMI46bI5N+6?=
 =?us-ascii?Q?cGwKbhW9bIVpTgYudnNzJCXeuQXsr06xmwCIwzCmDdnK0QwOW0UZnIbXV1QS?=
 =?us-ascii?Q?KNi7md8cIfw15KH+MTtb6QbHPwDGNo1hTuAsFV3cTv+4lW8XMnlaZCq/O8qX?=
 =?us-ascii?Q?/n1wbwq6SDHO/HDnTzuesxCTSXrTlEzdqGSGKYCiG9RweVfWHWhtz3RcOQSW?=
 =?us-ascii?Q?0ZgzBgMV+dzBkF/c/a4xeaDBS6Jup0MFfWJgA1pe/2WGHYxN/Fp9NvE++rKY?=
 =?us-ascii?Q?/LcdlnsTWCl9QWnPsxfWcZ6ikn2oABLDx2gIGFsP7fzlItxPK0HoVGsOLuEt?=
 =?us-ascii?Q?St3YmoEG4ezzg8eS9trAXiy/fsOrFZ+hQ/nar0+ripPsLzKDa+DYBwrXr+TN?=
 =?us-ascii?Q?gD6Ex4gUZIjkXYJnd+8AC146Hnxzs4KP7e+4h0PkQtGuzXHGhfdLZB68tKJP?=
 =?us-ascii?Q?16lveDQTcSEdHQRuGucjEUKBZvbFBPTH0eSPKpV5uPqT5ptok92p8rkHFeh/?=
 =?us-ascii?Q?sVwPe2TTP4DONaBEPWdv4LJE/hHTJkVsyv1q31j9QnQAw9xwBK7HRrzKJQGs?=
 =?us-ascii?Q?8MNusVmCujDbXRibQOEaGno3O0G5DrncmAXagtJJY6fDYOs5DNVLhy0UYanP?=
 =?us-ascii?Q?p04u5Q9GQplYoQ1LPpr6DHWbvYXTkWv8Li6uSq3o?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <BA4F9E932693894A89685870473C1899@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DBAPR08MB5798.eurprd08.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 525fabdb-3796-4c87-9a29-08dd2fc31322
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2025 09:01:44.2525
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: /2GEhuu7NriHNhDDN12+j7w1Zzg1Wb9JsPqG+TtshKLpxMqoZ3KmFj5r2PJkA0ADMl2YQHYEkUapvs/cuIhHdw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB9696



> On 8 Jan 2025, at 07:57, Michal Orzel <michal.orzel@amd.com> wrote:
>=20
> In the original patch e7a80636f16e ("xen/arm: add cache coloring support
> for Xen image"), the stub was added under wrong assumption that DCE
> won't remove the function call if it's not static. This assumption is
> incorrect as we already rely on DCE for cases like this one. Therefore
> drop the stub, that otherwise would be a place potentially prone to
> errors in the future.
>=20
> Suggested-by: Julien Grall <julien@xen.org>
> Signed-off-by: Michal Orzel <michal.orzel@amd.com>
> ---

Reviewed-by: Luca Fancellu <luca.fancellu@gmail.com>




From xen-devel-bounces@lists.xenproject.org Wed Jan 08 09:02:12 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 09:02:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.866993.1278393 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVRx6-0006mr-T0; Wed, 08 Jan 2025 09:02:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 866993.1278393; Wed, 08 Jan 2025 09:02:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVRx6-0006mk-Pl; Wed, 08 Jan 2025 09:02:12 +0000
Received: by outflank-mailman (input) for mailman id 866993;
 Wed, 08 Jan 2025 09:02:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=8hCO=UA=suse.com=jgross@srs-se1.protection.inumbo.net>)
 id 1tVRx5-0006TF-DL
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 09:02:11 +0000
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com
 [2a00:1450:4864:20::335])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3e9c6651-cd9f-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 10:02:10 +0100 (CET)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-4361f796586so168861015e9.3
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 01:02:10 -0800 (PST)
Received: from ?IPV6:2003:e5:8731:2800:842d:42a0:5992:3595?
 (p200300e587312800842d42a059923595.dip0.t-ipconnect.de.
 [2003:e5:8731:2800:842d:42a0:5992:3595])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436e2e03210sm13600295e9.34.2025.01.08.01.02.09
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 08 Jan 2025 01:02:09 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 3e9c6651-cd9f-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736326930; x=1736931730; darn=lists.xenproject.org;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=fkc7Z7yxTC1YVlAybo84K7ThQmlUUT58sCI4GDVzsHc=;
        b=OwSSSc7CbcoXCsg4EA5/0ccgOEscA4is33gMu64v0ytiD5++hpaSflCkdEH081GwPt
         Gyc2+lE1zzibjx6TBOhRGT5oiBW+YpfvV1JFb0ds9gBPCRzbFdi6ueOcPDp1URz8ari1
         lnx8qi0cZwkTK+4xgcCjeu6DLo8pTMHjup0QZCOeaTgmR2SmU5/cN7Gw0E150iDFZion
         jVIGyEFC+YjvkhitkGzSVTiPc3gBtAX0VDvLIdfFM8SviGFkTGmoXXDqJiwJGU+6r0NT
         WiPE/LwP1ZIwf0AmzDnq8eTRm+n7g1U525bfffJGVyowV2yY3E7Ax00h9zwv9S7aLHk1
         0vBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736326930; x=1736931730;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=fkc7Z7yxTC1YVlAybo84K7ThQmlUUT58sCI4GDVzsHc=;
        b=j6ctp9KOdbWQznE5s+dtRBt/Vw/OQAJWMxYjzI2Jj+Jn87Gaq2mVLnWmRVUcbNFU+m
         8OLXfxVvCI5h0TrP0cCZKPs0Ow5HLIcePibKN1g1J7FXuM9DG5XSL+88EdzMJV+aEgLS
         q8xuIv1Lzddqg5US0oKdirkCVE/eLUmXPuWYYVvcFNMxdiUStU9xprpJNOtwX8989cU5
         KmVQtBef3TAsAL6RupULZoN7wtOBcvziFllRDCK5zRqDBEvGy/J3F1XWDViXAaLtdNks
         kSTBiqhjs3sdzWzvKe7XNoMFH7U4XbXcq1Au4Y2dxGtV27qzmFH6HWquYydDwPVt487c
         BNyw==
X-Forwarded-Encrypted: i=1; AJvYcCVVYmhe/MkghI+co4rqCDJqTUIIYqsZQ1CoCxdJH3jTE2tEe6n8YP6z0+a1SjbjYIBdDvqDOsu0HcY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyDV1J7oMjCuquRck4CsaBm+rnoME/bXYQq5lkWYDiIRlisMAOn
	6unBGDuQWMli14/22XgOtVSBPvuFEa1NbyjPhC38r6YM/HQMHAcR1CRhCBJS0uw=
X-Gm-Gg: ASbGnctV2VRfxsCPhBSemjGYP1H/iGAdriQWKfkCRUZyyOyfK6SPCDwvw2mR0lQ3olW
	T4i+1aEAhCGHWJ8gW6TcnPXhMo6h8/WuqWI81K5G+03y4eo0EIOlbS2BpFJn40UppwXM+X1n5Rp
	cOBe5UNZZxApboG+u9kQiaLVYb6os7RCGoowr8/UYuaXspoCj7qyXrNnkblZwUqaijcv65hnsWk
	JME2pFtfBVOpiTthoY8Yq8krif5lFfpf2jAc6srqaX0mKubVmV4POjgVnZ//rF95uDTMyZPiOAb
	S1eQmVwmYkUTBNwcEE3D1skek/6SX70yQ2HMk6UPBKuATnYsubKzEs8L6We7B/TueIXeFt/4RB3
	cLxpN6A==
X-Google-Smtp-Source: AGHT+IF/BxTtuq51CuoLKuqp0xk1XjUbGck9Et0TE+IIhEFUpwQCvUYFobdzZgEK3aC+DDzFkgE3yA==
X-Received: by 2002:a05:600c:46c3:b0:434:fbe2:4f with SMTP id 5b1f17b1804b1-436e26e1d20mr11416145e9.23.1736326929951;
        Wed, 08 Jan 2025 01:02:09 -0800 (PST)
Message-ID: <f0cb4d80-5d26-437e-b6ee-a45f0157fc19@suse.com>
Date: Wed, 8 Jan 2025 10:02:08 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 2/7] xen/events: don't allow binding a global virq from
 any domain
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <20250107101711.5980-1-jgross@suse.com>
 <20250107101711.5980-3-jgross@suse.com>
 <577427ff-61e2-4fc9-8853-a7eec3f69bb6@suse.com>
 <5261716e-a2f4-4423-bb8d-17e36bf34538@suse.com>
 <511c3207-20b8-4110-a5ef-55f8b428074d@suse.com>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <511c3207-20b8-4110-a5ef-55f8b428074d@suse.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------7rrkwPcDk8GosLD5EOo4zIi0"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------7rrkwPcDk8GosLD5EOo4zIi0
Content-Type: multipart/mixed; boundary="------------TI3jFKzOntJRu0D87zTa0ZnD";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
Message-ID: <f0cb4d80-5d26-437e-b6ee-a45f0157fc19@suse.com>
Subject: Re: [PATCH v6 2/7] xen/events: don't allow binding a global virq from
 any domain
References: <20250107101711.5980-1-jgross@suse.com>
 <20250107101711.5980-3-jgross@suse.com>
 <577427ff-61e2-4fc9-8853-a7eec3f69bb6@suse.com>
 <5261716e-a2f4-4423-bb8d-17e36bf34538@suse.com>
 <511c3207-20b8-4110-a5ef-55f8b428074d@suse.com>
In-Reply-To: <511c3207-20b8-4110-a5ef-55f8b428074d@suse.com>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------TI3jFKzOntJRu0D87zTa0ZnD
Content-Type: multipart/mixed; boundary="------------4enMWu4ocrhIekdxeZEandwm"

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

T24gMDcuMDEuMjUgMTc6MzgsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAwNy4wMS4yMDI1
IDE3OjA3LCBKw7xyZ2VuIEdyb8OfIHdyb3RlOg0KPj4gT24gMDcuMDEuMjUgMTY6MzQsIEph
biBCZXVsaWNoIHdyb3RlOg0KPj4+IE9uIDA3LjAxLjIwMjUgMTE6MTcsIEp1ZXJnZW4gR3Jv
c3Mgd3JvdGU6DQo+Pj4+IEBAIC00NzksOCArNDg2LDEzIEBAIGludCBldnRjaG5fYmluZF92
aXJxKGV2dGNobl9iaW5kX3ZpcnFfdCAqYmluZCwgZXZ0Y2huX3BvcnRfdCBwb3J0KQ0KPj4+
PiAgICAgICAgKi8NCj4+Pj4gICAgICAgIHZpcnEgPSBhcnJheV9pbmRleF9ub3NwZWModmly
cSwgQVJSQVlfU0laRSh2LT52aXJxX3RvX2V2dGNobikpOw0KPj4+PiAgICANCj4+Pj4gLSAg
ICBpZiAoIHZpcnFfaXNfZ2xvYmFsKHZpcnEpICYmICh2Y3B1ICE9IDApICkNCj4+Pj4gLSAg
ICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+Pj4+ICsgICAgaWYgKCB2aXJxX2lzX2dsb2JhbCh2
aXJxKSApDQo+Pj4+ICsgICAgew0KPj4+PiArICAgICAgICBpZiAoIGdldF9nbG9iYWxfdmly
cV9oYW5kbGVyKHZpcnEpICE9IGQgKQ0KPj4+PiArICAgICAgICAgICAgcmV0dXJuIC1FQlVT
WTsNCj4+Pg0KPj4+IEhtbS4gV2hpbGUgdGhpcyBlbGltaW5hdGVzIHRoZSBwcm9ibGVtIGZv
ciB0aGUgY29tbW9uLCByYWNlIGZyZWUgY2FzZSwNCj4+PiB0aGUgaGFuZGxlciBjaGFuZ2lu
ZyByaWdodCBhZnRlciB0aGUgY2hlY2sgd291bGQgc3RpbGwgbWVhbiB0aGUgYmluZA0KPj4+
IHdvdWxkIHN1Y2NlZWQuDQo+Pg0KPj4gQXJlIHlvdSBmaW5lIHdpdGggbWUgYWRkaW5nIGEg
cGFyYWdyYXBoIHRvIHRoZSBjb21taXQgbWVzc2FnZSBzYXlpbmcNCj4+IHRoYXQgYSBmdXR1
cmUgcGF0Y2ggd2lsbCBoYW5kbGUgdGhpcyBjYXNlPw0KPj4NCj4+IFRoaXMgZnV0dXJlIHBh
dGNoIGlzIHBhdGNoIDQgb2YgdGhlIHNlcmllcywgd2hpY2ggd2lsbCBuZWVkIHRvIGJlDQo+
PiBtb2RpZmllZCB0byBjaGVjayB0aGUgaGFuZGxpbmcgZG9tYWluIGluc2lkZSB0aGUgZXZl
bnRfbG9jay4NCj4gDQo+IEkgdGhpbmsgdGhpcyB3b3VsZCBiZSBva2F5LCBzbyBsb25nIGFz
IHBhdGNoZXMgMi4uLjQgYXJlIHRoZW4gYWxzbyBhbGwNCj4gY29tbWl0dGVkIHRvZ2V0aGVy
Lg0KPiANCj4+PiBQbHVzIHRoaXMgd2F5IHlvdSdyZSBicmVha2luZyBhIGNhc2UgdGhhdCBh
ZmFpY3QgaGFzIGJlZW4gd29ya2luZyBzbw0KPj4+IGZhcjogVGhlIGJpbmQgaGFwcGVuaW5n
IGJlZm9yZSB0aGUgc2V0dGluZyBvZiB0aGUgaGFuZGxlci4gV2l0aCBhIGxvdA0KPj4+IG9m
IHVucmVsYXRlZCBpZi1zIGFuZCB3aGVuLXMgdGhpcyBjb3VsZCBlLmcuIGJlIG9mIGludGVy
ZXN0IHdoZW4NCj4+PiBjb25zaWRlcmluZyBhIHJlLXN0YXJ0YWJsZSBYZW5zdG9yZSBkb21h
aW4uIFRoZSBvbmUgdG8gdGFrZSBvdmVyIGNvdWxkDQo+Pj4gc3RhcnQgZmlyc3QsIG9idGFp
biBzdGF0ZSBmcm9tIHRoZSBvcmlnaW5hbCBvbmUgd2hpbGUgdGhhdCdzIHN0aWxsDQo+Pj4g
YWN0aXZlLCBhbmQgYmUgbm9taW5hdGVkIHRoZSBoYW5kbGVyIG9mIHRoZSBnbG9iYWwgdklS
USBvbmx5IGluIHRoZQ0KPj4+IGxhc3QgbW9tZW50Lg0KPj4NCj4+IFRoaXMgaXMgYSByYWN5
IHNpdHVhdGlvbiwgdG9vLiBJZiB0aGUgb2xkIGRvbWFpbiByZWNlaXZlcyB0aGUgdmlycSBh
ZnRlcg0KPj4gc2VuZGluZyB0aGUgc3RhdGUsIHRoaXMgd291bGQgbmVlZCB0byBiZSBoYW5k
bGVkIGJ5IHRyYW5zZmVycmluZyB0aGUgdmlycQ0KPj4gaW5mb3JtYXRpb24gdG8gdGhlIG5l
dyBkb21haW4sIHdoaWNoIGNhbiByZXN1bHQgaW4gYSBuZXZlciBlbmRpbmcgc3RvcnkuDQo+
Pg0KPj4gVGhpcyBpcyB0aGUgcmVhc29uIHdoeSB0aGUgZG9tYWluIHN0YXRlIGJpdG1hcCBp
cyByZXNldCB0byBjb250YWluIGFsbA0KPj4gZXhpc3RpbmcgZG9tYWlucyB0byBiZSBmbGFn
Z2VkIGFzICJjaGFuZ2VkIiwgYXMgb3RoZXJ3aXNlIGEgY2hhbmdlIG1pZ2h0DQo+PiBnZXQg
bG9zdC4NCj4+DQo+PiBJJ2QgcmF0aGVyIGJlIGFibGUgdG8gaGFuZGxlIHRvZGF5J3MgdXNl
IGNhc2VzIGluIGEgc2FuZSB3YXkgdGhhbiB0byB0cnkNCj4+IGhhbmRsaW5nIGFueSB3ZWly
ZCBmdXR1cmUgdXNlIGNhc2VzIHdoaWNoIHdlIGRvbid0IGtub3cgeWV0Lg0KPj4NCj4+IEkg
dGhpbmsgdG9kYXkncyBiZWhhdmlvciBpcyBtb3JlIG9yIGxlc3MgaW5zYW5lIGFuZCB0aGUg
bmV3IGJlaGF2aW9yIGlzDQo+PiBtdWNoIGVhc2llciB0byB1bmRlcnN0YW5kIGFuZCBtb3Jl
IGludHVpdGl2ZS4NCj4gDQo+IEhtbSwgSSdkIGxpa2UgdG8gbGVhdmUgdGhpcyB0aGVuIGZv
ciBpbnB1dCBieSBvdGhlciBtYWludGFpbmVycy4NCg0KSnVzdCBvbmUgYWRkaXRpb25hbCBy
ZW1hcmsgdG8geW91ciByZS1zdGFydGFibGUgeGVuc3RvcmUgZG9tYWluIHNjZW5hcmlvDQph
Ym92ZToNCg0KSXQgd291bGRuJ3QgYmUgcG9zc2libGUgdG9kYXkgdG8gZG8gdGhlIHNhbWUg
d2l0aCBhIHhlbnN0b3JlIGRhZW1vbiBpbg0KZS5nLiBkb20wLCBhcyBiaW5kaW5nIHRoZSB2
aXJxIGFub3RoZXIgdGltZSBmcm9tIHdpdGhpbiB0aGUgc2FtZSBkb21haW4NCndvdWxkIGJl
IHJlamVjdGVkIGJ5IHRoZSBoeXBlcnZpc29yLiBJbiB0aGUgeGVuc3RvcmUgZG9tYWluIGNh
c2UgeW91J2QNCmVpdGhlciBuZWVkIHRoZSBvbGQgZG9tYWluIHRvIGFzayBkb20wIHRvIGNo
YW5nZSB0aGUgaGFuZGxlciAoc28gbXVjaA0KYWJvdXQgbGVzcyBjb21tdW5pY2F0aW9uIG5l
ZWRlZCksIG9yIHlvdSdkIG5lZWQgdG8gZ2l2ZSB0aGUgeGVuc3RvcmUgZG9tYWluDQp0aGUg
cmlnaHQgdG8gZG8gdGhlIGhhbmRsZXIgY2hhbmdlIGl0c2VsZiwgcmVxdWlyaW5nIHRvIHVz
ZSBmbGFzayBvciB0bw0KbW9kaWZ5IHRoZSBkdW1teSBYU00gcmlnaHRzIG9mIHRoZSB4ZW5z
dG9yZSBkb21haW4uDQoNCg0KSnVlcmdlbg0K
--------------4enMWu4ocrhIekdxeZEandwm
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

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

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

--------------4enMWu4ocrhIekdxeZEandwm--

--------------TI3jFKzOntJRu0D87zTa0ZnD--

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

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

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmd+PxAFAwAAAAAACgkQsN6d1ii/Ey+X
Jgf+PijFCxZRHQ1j3PVTawxNLv2FoVSLdj3fyu6NCF5sgQI63FOs1j/jAgyqc7W1Zla+dcLR6M0L
4RzBNTA3+xRhVfPT5FA7HDhpcHu6zCbsU8mXgQdkZpKePYKCyCJyLL7UQ+I4+vCdrX0L08OioAuG
U7jMjEqxI0fQfLPeIL72R7Uvuz1pLcSgvItjarhLVpTMx62com1J1rULMQvbKwZLph/LNduZOpT7
wjjtKKqAafudwYKTVi8Pk2iXHNq0+Atl/fU62vRlf8UYCqGRnmZLOzTK+snkT6b//8GtJ7N6sYuB
dYkGvn0vdhpSBDKfJuot3Sk4oUaeBU5CvDzu4zAcrQ==
=kuOH
-----END PGP SIGNATURE-----

--------------7rrkwPcDk8GosLD5EOo4zIi0--


From xen-devel-bounces@lists.xenproject.org Wed Jan 08 09:05:57 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 09:05:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867005.1278403 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVS0i-0007Z0-Ce; Wed, 08 Jan 2025 09:05:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867005.1278403; Wed, 08 Jan 2025 09:05:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVS0i-0007Yt-9u; Wed, 08 Jan 2025 09:05:56 +0000
Received: by outflank-mailman (input) for mailman id 867005;
 Wed, 08 Jan 2025 09:05: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
 <SRS0=D7HK=UA=arm.com=Luca.Fancellu@srs-se1.protection.inumbo.net>)
 id 1tVS0g-0007Yn-Mu
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 09:05:54 +0000
Received: from EUR02-DB5-obe.outbound.protection.outlook.com
 (mail-db5eur02on20614.outbound.protection.outlook.com
 [2a01:111:f403:2608::614])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c2ebcb78-cd9f-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 10:05:52 +0100 (CET)
Received: from DBAPR08MB5798.eurprd08.prod.outlook.com (2603:10a6:10:1a6::21)
 by AS8PR08MB8736.eurprd08.prod.outlook.com (2603:10a6:20b:562::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8335.11; Wed, 8 Jan
 2025 09:05:50 +0000
Received: from DBAPR08MB5798.eurprd08.prod.outlook.com
 ([fe80::4a66:d3e2:570:9632]) by DBAPR08MB5798.eurprd08.prod.outlook.com
 ([fe80::4a66:d3e2:570:9632%4]) with mapi id 15.20.8335.010; Wed, 8 Jan 2025
 09:05:50 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c2ebcb78-cd9f-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=YCYuZjiD9FaU32GSX5/40e4/IZ5sNNdSSC281RC5uTuFjIOAhgop+WX0PqQ3VOx7/zE2VQkkeQ4n/OuCv8PgzrD1nnfwaq7IiFg7ujrecl0OVo/88NTxrpxuifzFiMbAk/T6zlyoV45wyMNp3pU8iGqoA88edCaqCc9OxLY48kWkULNRIrecsfOKuukhlYcNh/Si7lWB1GGQaV8yo4qNFgld7Cy2e9yLXtaUMWz44IN8NdSEia5BAYOXVRt76cI02rfF1OtektWRcDewbYDf2wnOPRMRtETf5n/sQsNCpH7aLmWSaOCoTZyd/JeBFMk7CZH8vKUCXzrThwPHK1sr6A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=XrgEw1leOnJXl5rn8f72Pu/VyRAlhnHCiCAQT/coVkk=;
 b=PfJvHTQCPvVo2K3s6RCrXgz6dsydY8WTf8V9aieLWH5oJVEXQa8jBQDgm+RfkuSkban1nydxKPx3XlNRJKrtC2+c2lt3fJ+C6MH5Avt5AlVJot6LKhWF/tJVbTwiWt+6RNeui+1z9ktAcs9lYCtAcSBW2afs9PWuE900xt8mYoLpmdJYdrEJUiPZQRGpoPHoJ5UUO6tyhgdIarXaXmEDqPVJr93Za9y3dslgQY2RXxuhn2Dozy+WGjARlwHSUxjMssxm3aSgA/olIWucApl42Sx1zbh7ZrVPc9oY51BszrTHrvK1jrtXW78LPAqAQtNeFCYjHX9YzhDDuTiIuR6HNA==
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=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=XrgEw1leOnJXl5rn8f72Pu/VyRAlhnHCiCAQT/coVkk=;
 b=aJlGhdGqWrXELS49nkYJ27OlpFRRtn/NbfHj7c5G9SlXrkBwGorMACZ+IL+IFFIIfyZS6X935dIR/uXwcqt1J31K/bFwF6iFhCDoU6QPvOFjersubsCFkJ1SWxLr8/BHrVbjs0Bjhy0IdyDcueTAVqDukrbsFKs5hqmSdL/51Qw=
From: Luca Fancellu <Luca.Fancellu@arm.com>
To: Michal Orzel <michal.orzel@amd.com>
CC: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Stefano
 Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand
 Marquis <Bertrand.Marquis@arm.com>, Volodymyr Babchuk
	<Volodymyr_Babchuk@epam.com>, "oleksii.kurochko@gmail.com"
	<oleksii.kurochko@gmail.com>
Subject: Re: [for-4.20][PATCH] xen/arm64: Drop relocate_and_switch_ttbr() stub
Thread-Topic: [for-4.20][PATCH] xen/arm64: Drop relocate_and_switch_ttbr()
 stub
Thread-Index: AQHbYaMBWdxQ1v99706M5qRoUKAKv7MMlHaAgAABJYA=
Date: Wed, 8 Jan 2025 09:05:50 +0000
Message-ID: <CCE48DA6-D7AC-4C46-B6E6-CFF028E944C0@arm.com>
References: <20250108075719.84967-1-michal.orzel@amd.com>
 <5DA66273-7255-4EDB-A3F5-C1F4F61C9CE1@arm.com>
In-Reply-To: <5DA66273-7255-4EDB-A3F5-C1F4F61C9CE1@arm.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.200.121)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DBAPR08MB5798:EE_|AS8PR08MB8736:EE_
x-ms-office365-filtering-correlation-id: b9b2b44a-9a81-4231-683c-08dd2fc3a5ad
x-checkrecipientrouted: true
nodisclaimer: true
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|366016|38070700018;
x-microsoft-antispam-message-info:
 =?us-ascii?Q?t/lmjo1WmS3B98EN9IfpccnGWFwcmrgRDhVWE82hHMSJw4ZRr2YXQK2i+UN9?=
 =?us-ascii?Q?wmWHtP64eN1lH9ANxHKCMY3qoZtGEF6lB16hmwRqC7bv72UFvx5SaYlG+gDF?=
 =?us-ascii?Q?vV/4Z2gCQjOrzgcApqOa5KLe/yZqb6FXe6X3STn2+KEDAPt3EPFOnId3R8AQ?=
 =?us-ascii?Q?Io1FNQ7KA9dn0B2Nx2fkjX6LImQVdAq/ViBNlZguDWEl0YJG0xF+vNYYitsS?=
 =?us-ascii?Q?HczW+Fi3IpgoAELDUrpry9NtY1kEBngUrUI7u1fs1fgnvUTpHybfFx0fbvtf?=
 =?us-ascii?Q?hOhw9pyp+8RKRZZFiSAXCS/Yfo5qWa/Qf10bs2eS2ZYt9y/dDVQK/kHSVSLJ?=
 =?us-ascii?Q?8HzsFOTcRnU3BJlJKC8Qj7ayVursQxatPn5psBDYjn/DjdegoCaalecSMX2Z?=
 =?us-ascii?Q?3u6+Okx3uBRnu3RgGdz3UJbvAZUo+ZUD+a4WqXOvCCoShjbEMu8Do3z0WIbs?=
 =?us-ascii?Q?k0ThZuRCUihhth0OfJxpZlAb+6qYeugemqF0Oq6L2cdGVdg+CpZC+7nE9/D9?=
 =?us-ascii?Q?O3hqxUGqiLOePDU+zF2MJjFAsj+JpOIb1EN6zu2i+FDsP4qTWrDda32i47pa?=
 =?us-ascii?Q?+QeR5ZtqjP8nMrEqgDfNjeXXskAliNvRVeHCrq2u1qCjCUXK9HsL3vO8scd8?=
 =?us-ascii?Q?giR8vBWsQCRAEjxdKCQXgPQRMLqaYLoswXXWRIalpaE36P6wc/6p6kOy5WRE?=
 =?us-ascii?Q?lMbz+9a54trnGthl21ozZayRs3ZUtmRbbumkUjVcWLX4kOkzUP1ZdAmKj8uj?=
 =?us-ascii?Q?bx4oCqjYGI8CfHbjzxOBBvzoaedaPsK+RSkLOHL4OT57T8tj2hEYolEp/iO6?=
 =?us-ascii?Q?tmBkAe9pBh7reMb4qasU6OT8ZccwqTLx1XRkIj2g5QCaVeXCHATiBunYKkAe?=
 =?us-ascii?Q?2t/iw/cp/3Ra56eSw8CntJqgBTIgKkjkjIO5X9oeMzJbWbdCb5KyvLfbfHS1?=
 =?us-ascii?Q?JxKqs7VUHP2tsayRLfxGLaw66Bo/2yhIhUdrzd0P7uu6JJlOvZ61OIP28fwi?=
 =?us-ascii?Q?51nAPkY/xCY0jlEUEyt5kO9UHGSKrq8SOdyK+N/Vq1sbniLr32Huk39sBJ5h?=
 =?us-ascii?Q?Vvx8K+TzaPC9l6lJjxDSlgyHTzUMtdaoH70Di2+4Ag0KMwh6ZCBLy5bm/A6F?=
 =?us-ascii?Q?G6IzoX9FIpfjisgo50Nbse/j6en0/ZnUBAd6tMkwECA0u9wzIq/I79/f8t+q?=
 =?us-ascii?Q?kvtBaLjQtjIF5GHzBPTJ7Nw8mpM1eS5Vx6QrENRqpQtYNA+5yxnw4DDmC2jp?=
 =?us-ascii?Q?/lxRKfIL+V26sTmnkL9gNe17YQbegn5yL+jvGufGirUyOdUNH9IBBZVj9+CB?=
 =?us-ascii?Q?/U0iI0+7J0M6aFlOD+1t8Xx2CSnVn5G4Az/SO92YYEAJec94cvIHvMSQk1EB?=
 =?us-ascii?Q?gF3gsBvXLFjItQD6/gnhKjsWbPxR0aHHiIVvaiCd8opNVzQVROsVJPOUXdbH?=
 =?us-ascii?Q?xATr/ZLjHvRqBtc5qhVBA4HyzIZ1tl4k?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DBAPR08MB5798.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?JdI5xvNnGgfzjk5IoeacVjdKDwogk5+af7K/0YlaqAH3C59NlJqfdiS/X36K?=
 =?us-ascii?Q?uxhNTm4ZGuSKvwT2Qio9D0ojdbVJWQtgBoBz7+BQWVd8yuiHbmUyyQ2Zx1UV?=
 =?us-ascii?Q?hKjZ5YlbF3+ISQiNCpXhzq2XmaumQvn8k9tkbeHaUCj3B/6XnyWUsB4jTNw7?=
 =?us-ascii?Q?HjiAh3DpjGw6QobP5SYGpZTCZwbYJYGw31MJ78biaZ3wB00O0yeqeCl0Zg1+?=
 =?us-ascii?Q?+YGDDLn9yQjoG/Og8uQcOiKAaVhh4EB5njukgAGFWfgznRIAibV1YiuojFUS?=
 =?us-ascii?Q?q1TFeT+loGyd8ZOquf+gMwVRt2squPSg3qgvIteLY3y649biMyx6C0oPHdC5?=
 =?us-ascii?Q?22kYBshHpULuDdiryErWOdIE/IhNUbaEPxJ0Zqnuvb2y6x1VdeHtEQyOVWiR?=
 =?us-ascii?Q?AvjrHejsrF9P31JIJQrsIAmiQbrmnzhlu0Z8OYtQkBUlrOFZlA5cnEactJAA?=
 =?us-ascii?Q?qP8d9BuKatnhg34uK+cj+tEYlXBaBTiqV7bRfxOJCnC+OmKLdnsVVA6/BXca?=
 =?us-ascii?Q?xH5rp55sipS57b7Z2QA9nys/E3Zrpep5njSp7QyMHhPtCeTvOp4vY+TQEoHw?=
 =?us-ascii?Q?0Q2ouZouR74FV+LXpFr4l+CTofO1qlp3gDg7trMrnncMxLvlB4xg7x6ILvXB?=
 =?us-ascii?Q?h1Qvtr4B6+EquGyR7/1srt1e7qYKXe36vDl6D2QTn5zVUV/U7UnazgFtf+0L?=
 =?us-ascii?Q?txkiqieLF3TC/u3FaniUoFe1cezoRchg4gOptgVBvdLowhaWEfj5JEXWi9sj?=
 =?us-ascii?Q?0wUpLoQw2OQoircPUJi1SxZyz/nsvPUx9SvbKboTAKxBB0eZGNmrUuSRUOED?=
 =?us-ascii?Q?Vh8HcNFJNPthpqY8kiuijGenv76Ylg9fSgnEUpyaBiZAth2/cDJK92o80SQ1?=
 =?us-ascii?Q?Qd9IxXkgQTYX3TKwanLrHoZSxyTx/wV7ke8DlXSbHbj6DhFHtbVtm3julYX6?=
 =?us-ascii?Q?orZsSopN8fAnyNh/fOX383e9kGjB5LDUg78Dgup3lH4sBsfXEMIP/9y2bItJ?=
 =?us-ascii?Q?ps2J+ixVS/lMIOpZ4Lmz3nQFioI8MQ8f6t7ZwMS9R2cqzmqpdMWKqRc93BNC?=
 =?us-ascii?Q?cCaG4fuY+t74lYrlG1khWeGDRKk2IZelFjRN/EFkudxeg2+VzcK0599SLEmj?=
 =?us-ascii?Q?hjDnYzXVerHW2lVcQHp7/v62iJMnph+5BrLt7c6JR18sPAreU/wbAc2665/S?=
 =?us-ascii?Q?jl2L5YngYw6DwaCs+16Yrb9zrqqIhCDimU87btxXHMTUaLiJ4Jpeowp0UIJr?=
 =?us-ascii?Q?TVgqGVUKjPImmke30Zlq+v1QZLICE8WnVx9zeLvh6aLEjFVrMU3TMdTyHsW3?=
 =?us-ascii?Q?5vgz4ZJJn8JxDAjG/vraOwGlT9CxO6Oj+7V7TUhDsf1xdTqLFe4lnAEP0tkB?=
 =?us-ascii?Q?ZhufyfTKkYlHAUsS72aKMZYMrsEsHFxA5kc/JrYnkZ3BCp23bWf/IWDerVS+?=
 =?us-ascii?Q?XnbBtDJhCuJgT/ou9pfgHjPFxVyVrct4xUvZvrDcHJU07E1O088Byj9ghN/2?=
 =?us-ascii?Q?3//UjNoGlbiXalMI25LsGE5rVeC1Hp2+A/O20Qu3uWIR9/gL/55IiL06OAZC?=
 =?us-ascii?Q?dCEJv37uBA3JHmZu4gjDeaweVIJpVglVFGhU/Maop1d3L1cyw87oSbHLpRXo?=
 =?us-ascii?Q?6A=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <171F9331EB997F488DC8366492AF6E15@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DBAPR08MB5798.eurprd08.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b9b2b44a-9a81-4231-683c-08dd2fc3a5ad
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2025 09:05:50.0926
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: F7qz9n9rUrGiMpLSOwCgdVV/M1xVaP+0PjdmYxsCoPJbm9R7fB398rjxBuiyySONfUgdiZbCkk7NK+rwtRd6iw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB8736



> On 8 Jan 2025, at 09:01, Luca Fancellu <Luca.Fancellu@arm.com> wrote:
>=20
>=20
>=20
>> On 8 Jan 2025, at 07:57, Michal Orzel <michal.orzel@amd.com> wrote:
>>=20
>> In the original patch e7a80636f16e ("xen/arm: add cache coloring support
>> for Xen image"), the stub was added under wrong assumption that DCE
>> won't remove the function call if it's not static. This assumption is
>> incorrect as we already rely on DCE for cases like this one. Therefore
>> drop the stub, that otherwise would be a place potentially prone to
>> errors in the future.
>>=20
>> Suggested-by: Julien Grall <julien@xen.org>
>> Signed-off-by: Michal Orzel <michal.orzel@amd.com>
>> ---
>=20
> Reviewed-by: Luca Fancellu <luca.fancellu@gmail.com>

Apologies, I meant:

Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>

>=20
>=20
>=20



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 09:16:07 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 09:16:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867017.1278413 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVSAV-0001AH-CI; Wed, 08 Jan 2025 09:16:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867017.1278413; Wed, 08 Jan 2025 09:16:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVSAV-0001AA-9p; Wed, 08 Jan 2025 09:16:03 +0000
Received: by outflank-mailman (input) for mailman id 867017;
 Wed, 08 Jan 2025 09:16:02 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=WoWX=UA=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tVSAU-0001A4-EZ
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 09:16:02 +0000
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com
 [2a00:1450:4864:20::22d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2d1ccdc8-cda1-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 10:16:00 +0100 (CET)
Received: by mail-lj1-x22d.google.com with SMTP id
 38308e7fff4ca-3011c7b39c7so190392371fa.1
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 01:16:00 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-3045b082dd3sm62558621fa.105.2025.01.08.01.15.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 08 Jan 2025 01:15:59 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2d1ccdc8-cda1-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736327760; x=1736932560; darn=lists.xenproject.org;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=3px2diIUjPy9BkBIZXLYbCve17wV4LOgKHr6yY87Q90=;
        b=H9j+o9CcEVlt8OPL3dIpp50EzZoiPnOi5+BjGzx94LaMn1JBt8y5MXjKp6VRMkzYdd
         MZh7i7nUDMeiTQ8qAbZxGXSvj0CH8UlYuXj0yTwDxhHYrn8IrgXTxg9itXeIKiYUfKyO
         X696SM/C/4CdYRfnIMsmKiawiVs7+rVqakCktU6QPIzChPXrk8+oEL7Mi4jT+GgsYXe1
         hBD2rShm3HwOQGFgdxM50MygmEe8pp17vnEqzDD9c5cthM6zaHUwDdpm8VFVFpOnb7cV
         RDLPmNDtB8Muxi3Vx2GYeZw6Z0arbKXfRBs+rBOUvLiSjK15DmSWwxJoIzNT5NwlkXJH
         Sw+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736327760; x=1736932560;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=3px2diIUjPy9BkBIZXLYbCve17wV4LOgKHr6yY87Q90=;
        b=YK4opBkbAqLhF0dR036uNE7nCheJQkRi0jIoLKtcumd778PLyhuonF08/fqnnjsB3g
         YGs32J/UdI2BFDTkspGQ5p/Njz4ShjTaaijO5pAHLhlGfx46oX6WfZ15+hqsGeGOvBTq
         F85XCocUHJEl50bJSPvpvUfQsPZyUh5J2mVWwvNl5L9ZZIyP8YTsFX8PwgNtAW9M1vLd
         tODlXTD417g3GzHPOzzmvi6KGNQBXiLOiXvIpGdv+/YI+TB46va55B0mrNT39115pz+T
         9YKqH9ovgx/MYDpFFYb6MA2N9g4FpUDwJpPiH9zV8FlTewprfJg7ZOsy0s+n9bLmN6kP
         RCPQ==
X-Forwarded-Encrypted: i=1; AJvYcCUPHDUmF/RfvM0Ie01lqBgwKJZPqBbUqzKH6qZA6w6EOAcfwEi2umxkZZMV+VyfQxCeYwoNS1QYA1k=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxL4G11H8ZasTB/z/mRUdbtfBJso7NgkbcPb5ok8B8dVR6LMUvr
	bWAyOv/ybyRxwA8ZgQjambRPQLqvTXIAyb+fsA+FeoBd/sX8G60y
X-Gm-Gg: ASbGncuQy3P01ZwBlHrQmxYuCbgek/yA5f0LUD8iseZL1K/ngbyu5+kKpDLLfd4Zz3R
	LjXpb2LYqNyUW8tbjHwoZYh+rjZETYFC5lxJTjI3N8nqndv9sYpyOc7YneBdDrD2YPICoyYmE7e
	+YKvybfHHIMSmmpZ0a4JtCcSZs2YUnZoKwcMYoSaH8sq1FMd5i0HxUbd0yDag5fodD6r4ZZyjQB
	Bcxv4wEvAcTF05bfPtUFlrD84hclY/IhEkOtqiWZN5ViZlcLj2DzR9m+M7YfiY176DSgQ==
X-Google-Smtp-Source: AGHT+IF+fLUlmlqiyVLTt2OFaIY3IXVzg3mc/r+MVYa8382HJZ3N5pPgU5im8J/NTH9oPOkZ6TMzig==
X-Received: by 2002:a2e:bea8:0:b0:302:1b18:2c09 with SMTP id 38308e7fff4ca-305f45ba080mr5181721fa.27.1736327759324;
        Wed, 08 Jan 2025 01:15:59 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------LRVo0qqkPA0VKGdtFuLKT0D8"
Message-ID: <7482da8f-8bf1-4f0c-b15b-7a31b27b48f3@gmail.com>
Date: Wed, 8 Jan 2025 10:15:58 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20] x86/traps: Rework LER initialisation and support
 Zen5/Diamond Rapids
To: Andrew Cooper <andrew.cooper3@citrix.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
Cc: Jan Beulich <JBeulich@suse.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>
References: <20241231192002.1753737-1-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <20241231192002.1753737-1-andrew.cooper3@citrix.com>

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


On 12/31/24 8:20 PM, Andrew Cooper wrote:
> AMD have always used the architectural MSRs for LER.  As the first processor
> to support LER was the K7 (which was 32bit), we can assume it's presence
> unconditionally in 64bit mode.
>
> Intel are about to run out of space in Family 6 and start using 19.  It is
> only the Pentium 4 which uses non-architectural LER MSRs.
>
> percpu_traps_init(), which runs on every CPU, contains a lot of code which
> should be init-only, and is the only reason why opt_ler can't be in initdata.
>
> Write a brand new init_ler() which expects all future Intel and AMD CPUs to
> continue using the architectural MSRs, and does all setup together.  Call it
> from trap_init(), and remove the setup logic percpu_traps_init() except for
> the single path configuring MSR_IA32_DEBUGCTLMSR.
>
> Leave behind a warning if the user asked for LER and Xen couldn't enable it.
>
> Signed-off-by: Andrew Cooper<andrew.cooper3@citrix.com>
> ---
> CC: Jan Beulich<JBeulich@suse.com>
> CC: Roger Pau Monné<roger.pau@citrix.com>
> CC: Oleksii Kurochko<oleksii.kurochko@gmail.com>
>
> For 4.20.  This is needed for Zen5 CPUs (already available) as well as Intel
> CPUs coming shortly.  It also moves some non-init logic to being init-only.

As a user can enable/disable LER and support for Zen5/Diamond Rapids is added, and this patch
is already in staging, I think we could mention that in CHANGELOG. If it makes sense I can do
that during finalization of CHANGELOG before release. Does it make sense?

~ Oleksii

> ---
>   xen/arch/x86/traps.c | 86 ++++++++++++++++++++------------------------
>   1 file changed, 39 insertions(+), 47 deletions(-)
>
> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
> index fd8a4448e3f7..377194d7b620 100644
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -114,7 +114,7 @@ DEFINE_PER_CPU_PAGE_ALIGNED(struct tss_page, tss_page);
>   static int debug_stack_lines = 20;
>   integer_param("debug_stack_lines", debug_stack_lines);
>   
> -static bool __ro_after_init opt_ler;
> +static bool __initdata opt_ler;
>   boolean_param("ler", opt_ler); /* LastExceptionFromIP on this hardware. Zero if LER is 
> not in use. */ @@ -2092,56 +2092,10 @@ static void __init 
> set_intr_gate(unsigned int n, void *addr) __set_intr_gate(n, 0, addr); 
> } -static unsigned int noinline __init calc_ler_msr(void) -{ - switch 
> ( boot_cpu_data.x86_vendor ) - { - case X86_VENDOR_INTEL: - switch ( 
> boot_cpu_data.x86 ) - { - case 6: - return MSR_IA32_LASTINTFROMIP; - - 
> case 15: - return MSR_P4_LER_FROM_LIP; - } - break; - - case 
> X86_VENDOR_AMD: - switch ( boot_cpu_data.x86 ) - { - case 6: - case 
> 0xf ... 0x19: - return MSR_IA32_LASTINTFROMIP; - } - break; - - case 
> X86_VENDOR_HYGON: - return MSR_IA32_LASTINTFROMIP; - } - - return 0; 
> -} - void percpu_traps_init(void) { subarch_percpu_traps_init(); - if 
> ( !opt_ler ) - return; - - if ( !ler_msr ) - { - ler_msr = 
> calc_ler_msr(); - if ( !ler_msr ) - { - opt_ler = false; - return; - } 
> - - setup_force_cpu_cap(X86_FEATURE_XEN_LBR); - } - if ( 
> cpu_has_xen_lbr ) wrmsrl(MSR_IA32_DEBUGCTLMSR, IA32_DEBUGCTLMSR_LBR); 
> } @@ -2201,6 +2155,42 @@ void __init init_idt_traps(void) 
> this_cpu(compat_gdt) = boot_compat_gdt; } +static void __init 
> init_ler(void) +{ + unsigned int msr = 0; + + if ( !opt_ler ) + 
> return; + + /* + * Intel Pentium 4 is the only known CPU to not use 
> the architectural MSR + * indicies. + */ + switch ( 
> boot_cpu_data.x86_vendor ) + { + case X86_VENDOR_INTEL: + if ( 
> boot_cpu_data.x86 == 0xf ) + { + ler_msr = MSR_P4_LER_FROM_LIP; + 
> break; + } + fallthrough; + case X86_VENDOR_AMD: + case 
> X86_VENDOR_HYGON: + ler_msr = MSR_IA32_LASTINTFROMIP; + break; + } + + 
> if ( msr == 0 ) + { + printk(XENLOG_WARNING "LER disabled: failed to identy MSRs\n");
> +        return;
> +    }
> +
> +    ler_msr = msr;
> +    setup_force_cpu_cap(X86_FEATURE_XEN_LBR);
> +}
> +
>   extern void (*const autogen_entrypoints[X86_NR_VECTORS])(void);
>   void __init trap_init(void)
>   {
> @@ -2226,6 +2216,8 @@ void __init trap_init(void)
>           }
>       }
>   
> +    init_ler();
> +
>       /* Cache {,compat_}gdt_l1e now that physically relocation is done. */
>       this_cpu(gdt_l1e) =
>           l1e_from_pfn(virt_to_mfn(boot_gdt), __PAGE_HYPERVISOR_RW);
--------------LRVo0qqkPA0VKGdtFuLKT0D8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF=
-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class=3D"moz-cite-prefix">On 12/31/24 8:20 PM, Andrew Cooper
      wrote:<br>
    </div>
    <blockquote type=3D"cite"
      cite=3D"mid:20241231192002.1753737-1-andrew.cooper3@citrix.com">
      <pre wrap=3D"" class=3D"moz-quote-pre">AMD have always used the arc=
hitectural MSRs for LER.  As the first processor
to support LER was the K7 (which was 32bit), we can assume it's presence
unconditionally in 64bit mode.

Intel are about to run out of space in Family 6 and start using 19.  It i=
s
only the Pentium 4 which uses non-architectural LER MSRs.

percpu_traps_init(), which runs on every CPU, contains a lot of code whic=
h
should be init-only, and is the only reason why opt_ler can't be in initd=
ata.

Write a brand new init_ler() which expects all future Intel and AMD CPUs =
to
continue using the architectural MSRs, and does all setup together.  Call=
 it
from trap_init(), and remove the setup logic percpu_traps_init() except f=
or
the single path configuring MSR_IA32_DEBUGCTLMSR.

Leave behind a warning if the user asked for LER and Xen couldn't enable =
it.

Signed-off-by: Andrew Cooper <a class=3D"moz-txt-link-rfc2396E" href=3D"m=
ailto:andrew.cooper3@citrix.com">&lt;andrew.cooper3@citrix.com&gt;</a>
---
CC: Jan Beulich <a class=3D"moz-txt-link-rfc2396E" href=3D"mailto:JBeulic=
h@suse.com">&lt;JBeulich@suse.com&gt;</a>
CC: Roger Pau Monn=C3=A9 <a class=3D"moz-txt-link-rfc2396E" href=3D"mailt=
o:roger.pau@citrix.com">&lt;roger.pau@citrix.com&gt;</a>
CC: Oleksii Kurochko <a class=3D"moz-txt-link-rfc2396E" href=3D"mailto:ol=
eksii.kurochko@gmail.com">&lt;oleksii.kurochko@gmail.com&gt;</a>

For 4.20.  This is needed for Zen5 CPUs (already available) as well as In=
tel
CPUs coming shortly.  It also moves some non-init logic to being init-onl=
y.</pre>
    </blockquote>
    <pre>As a user can enable/disable LER and support for Zen5/Diamond Ra=
pids is added, and this patch
is already in staging, I think we could mention that in CHANGELOG. If it =
makes sense I can do
that during finalization of CHANGELOG before release. Does it make sense?=


~ Oleksii
</pre>
    <blockquote type=3D"cite"
      cite=3D"mid:20241231192002.1753737-1-andrew.cooper3@citrix.com">
      <pre wrap=3D"" class=3D"moz-quote-pre">---
 xen/arch/x86/traps.c | 86 ++++++++++++++++++++------------------------
 1 file changed, 39 insertions(+), 47 deletions(-)

diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index fd8a4448e3f7..377194d7b620 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -114,7 +114,7 @@ DEFINE_PER_CPU_PAGE_ALIGNED(struct tss_page, tss_page=
);
 static int debug_stack_lines =3D 20;
 integer_param("debug_stack_lines", debug_stack_lines);
=20
-static bool __ro_after_init opt_ler;
+static bool __initdata opt_ler;
 boolean_param("ler<a class=3D"moz-txt-link-rfc2396E" href=3D"mailto:,opt=
_ler);/*LastExceptionFromIPonthishardware.ZeroifLERisnotinuse.*/@@-2092,5=
6+2092,10@@staticvoid__initset_intr_gate(unsignedintn,void*addr)__set_int=
r_gate(n,0,addr);}-staticunsignedintnoinline__initcalc_ler_msr(void)-{-sw=
itch(boot_cpu_data.x86_vendor)-{-caseX86_VENDOR_INTEL:-switch(boot_cpu_da=
ta.x86)-{-case6:-returnMSR_IA32_LASTINTFROMIP;--case15:-returnMSR_P4_LER_=
FROM_LIP;-}-break;--caseX86_VENDOR_AMD:-switch(boot_cpu_data.x86)-{-case6=
:-case0xf...0x19:-returnMSR_IA32_LASTINTFROMIP;-}-break;--caseX86_VENDOR_=
HYGON:-returnMSR_IA32_LASTINTFROMIP;-}--return0;-}-voidpercpu_traps_init(=
void){subarch_percpu_traps_init();-if(!opt_ler)-return;--if(!ler_msr)-{-l=
er_msr=3Dcalc_ler_msr();-if(!ler_msr)-{-opt_ler=3Dfalse;-return;-}--setup=
_force_cpu_cap(X86_FEATURE_XEN_LBR);-}-if(cpu_has_xen_lbr)wrmsrl(MSR_IA32=
_DEBUGCTLMSR,IA32_DEBUGCTLMSR_LBR);}@@-2201,6+2155,42@@void__initinit_idt=
_traps(void)this_cpu(compat_gdt)=3Dboot_compat_gdt;}+staticvoid__initinit=
_ler(void)+{+unsignedintmsr=3D0;++if(!opt_ler)+return;++/*+*IntelPentium4=
istheonlyknownCPUtonotusethearchitecturalMSR+*indicies.+*/+switch(boot_cp=
u_data.x86_vendor)+{+caseX86_VENDOR_INTEL:+if(boot_cpu_data.x86=3D=3D0xf)=
+{+ler_msr=3DMSR_P4_LER_FROM_LIP;+break;+}+fallthrough;+caseX86_VENDOR_AM=
D:+caseX86_VENDOR_HYGON:+ler_msr=3DMSR_IA32_LASTINTFROMIP;+break;+}++if(m=
sr=3D=3D0)+{+printk(XENLOG_WARNING">", opt_ler);
=20
 /* LastExceptionFromIP on this hardware.  Zero if LER is not in use. */
@@ -2092,56 +2092,10 @@ static void __init set_intr_gate(unsigned int n, =
void *addr)
     __set_intr_gate(n, 0, addr);
 }
=20
-static unsigned int noinline __init calc_ler_msr(void)
-{
-    switch ( boot_cpu_data.x86_vendor )
-    {
-    case X86_VENDOR_INTEL:
-        switch ( boot_cpu_data.x86 )
-        {
-        case 6:
-            return MSR_IA32_LASTINTFROMIP;
-
-        case 15:
-            return MSR_P4_LER_FROM_LIP;
-        }
-        break;
-
-    case X86_VENDOR_AMD:
-        switch ( boot_cpu_data.x86 )
-        {
-        case 6:
-        case 0xf ... 0x19:
-            return MSR_IA32_LASTINTFROMIP;
-        }
-        break;
-
-    case X86_VENDOR_HYGON:
-        return MSR_IA32_LASTINTFROMIP;
-    }
-
-    return 0;
-}
-
 void percpu_traps_init(void)
 {
     subarch_percpu_traps_init();
=20
-    if ( !opt_ler )
-        return;
-
-    if ( !ler_msr )
-    {
-        ler_msr =3D calc_ler_msr();
-        if ( !ler_msr )
-        {
-            opt_ler =3D false;
-            return;
-        }
-
-        setup_force_cpu_cap(X86_FEATURE_XEN_LBR);
-    }
-
     if ( cpu_has_xen_lbr )
         wrmsrl(MSR_IA32_DEBUGCTLMSR, IA32_DEBUGCTLMSR_LBR);
 }
@@ -2201,6 +2155,42 @@ void __init init_idt_traps(void)
         this_cpu(compat_gdt) =3D boot_compat_gdt;
 }
=20
+static void __init init_ler(void)
+{
+    unsigned int msr =3D 0;
+
+    if ( !opt_ler )
+        return;
+
+    /*
+     * Intel Pentium 4 is the only known CPU to not use the architectura=
l MSR
+     * indicies.
+     */
+    switch ( boot_cpu_data.x86_vendor )
+    {
+    case X86_VENDOR_INTEL:
+        if ( boot_cpu_data.x86 =3D=3D 0xf )
+        {
+            ler_msr =3D MSR_P4_LER_FROM_LIP;
+            break;
+        }
+        fallthrough;
+    case X86_VENDOR_AMD:
+    case X86_VENDOR_HYGON:
+        ler_msr =3D MSR_IA32_LASTINTFROMIP;
+        break;
+    }
+
+    if ( msr =3D=3D 0 )
+    {
+        printk(XENLOG_WARNING "</a>LER disabled: failed to identy MSRs\n=
");
+        return;
+    }
+
+    ler_msr =3D msr;
+    setup_force_cpu_cap(X86_FEATURE_XEN_LBR);
+}
+
 extern void (*const autogen_entrypoints[X86_NR_VECTORS])(void);
 void __init trap_init(void)
 {
@@ -2226,6 +2216,8 @@ void __init trap_init(void)
         }
     }
=20
+    init_ler();
+
     /* Cache {,compat_}gdt_l1e now that physically relocation is done. *=
/
     this_cpu(gdt_l1e) =3D
         l1e_from_pfn(virt_to_mfn(boot_gdt), __PAGE_HYPERVISOR_RW);
</pre>
    </blockquote>
  </body>
</html>

--------------LRVo0qqkPA0VKGdtFuLKT0D8--


From xen-devel-bounces@lists.xenproject.org Wed Jan 08 09:22:13 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 09:22:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867024.1278423 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVSGP-00035J-0p; Wed, 08 Jan 2025 09:22:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867024.1278423; Wed, 08 Jan 2025 09:22:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVSGO-00035C-UV; Wed, 08 Jan 2025 09:22:08 +0000
Received: by outflank-mailman (input) for mailman id 867024;
 Wed, 08 Jan 2025 09:22:08 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=WoWX=UA=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tVSGO-000356-DN
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 09:22:08 +0000
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com
 [2a00:1450:4864:20::12e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 076c4e0e-cda2-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 10:22:06 +0100 (CET)
Received: by mail-lf1-x12e.google.com with SMTP id
 2adb3069b0e04-54263b52b5aso5985462e87.1
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 01:22:06 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-542238216b5sm5411159e87.182.2025.01.08.01.22.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 08 Jan 2025 01:22:05 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 076c4e0e-cda2-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736328126; x=1736932926; darn=lists.xenproject.org;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=rqjpxfWCdZecqBpZCVlxu72FWvO6Hft/ghe6n7jAKT8=;
        b=iyhoOYGjZoenBP3yX+BhzPvsCsIiJt+g1TbnYjKTC8PqMxeLCwDolHHPGKVLE9cATM
         6ivSh2B7raZAYvpmlToXHBwupl0k1YjRrLtp0Gh0zjQ0elJJAIiLL8z7bxEeVHGo81B6
         JKL1OejCHG8T5hqjGsJr6talHVK0uzX/kQqSmm4gbQvnYNq6p9QvOYYzR1Bf0bo9ewOj
         n+MWQtEyz0v1cHh0lVobsnchzpPgplUfulZtwCZAOf9Gm24wWgtQqIxXDaN6tAS3IbAJ
         wxujqdZtgr4NXnu1NftLsGPzpfynv26zlqhpYTjprPWRmrzA0VS22ll0okrHl0VF3oIJ
         9I8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736328126; x=1736932926;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=rqjpxfWCdZecqBpZCVlxu72FWvO6Hft/ghe6n7jAKT8=;
        b=IBedHbjFWwLHTWNlgtFofHx68DCe/Ow20U71YaYxyt9tMh1f7gNCHr5SOAq0HEpUz6
         +tf5q9cLlBc1uUxyrqzwg8S1mukURkAXySD884z01NXTZg6PJ+QUrQNi3+rA7sPBeB+c
         Lqkp2HevG0QqBfOGIo8qFue+b8ublCHwCB0GQjRItC56QiuvsM/SjctQfRgFZ2x45tm1
         MXxhxCFwl2h3XNAMHXZhrsDR9i8unag41qw9/2/D5skpThnn3Znh5cTCcxjswAiE1FO/
         z7879cPvm6vP1O+kYeqMPrghsHb3GK9+U1K9NunOHl0GMpKyGJI2Eu54RT1X4nV4vBVT
         e59w==
X-Forwarded-Encrypted: i=1; AJvYcCUzwQQ1ZTo6ZoKsecroZGi37t+qG5whMpglmNsl7PyfupoV51aEPDser76Bz5e+NLUVDVo6as9lpSM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwH3j54XoBaTwB//HR2O3ppicvmdg6ZcGnkMXTWjGkcNy1psL5l
	qbcxf8HKxCxTykJX+hMFxB1TAf34X7HCbLw6eQSi8Dg+j6EZPlY3
X-Gm-Gg: ASbGnctYsknXWvj3+7ZiD4CaiU1Uh34L4Dk9A7tb1r6P8HmK3NnqtS5h1pLHV5amE6c
	yjYRhfqnSMFgvU1KVU5pQy8cSpjT1nBS+r3RksEET06OwNkLX7aqsrM/hxkDDgEuOzhWu//SMUN
	glYmG8Jw3g3hL3XEdQRzNdCPzcbJpO2bGvyI++hqTPzW4lvGjbxZv5Yg8hbHhlUrKzl7ofi+TU8
	71oQIPb980sM6WuIbLoWsInOrwpd9R2mnVXfGlOYQ7pYSii/m/h6f81OPbR8pT/woziXA==
X-Google-Smtp-Source: AGHT+IEzxkEAw/AmB3IPINzU5suGu9f0me7IeePa5c0D37rgcGveXFOIqhpyiYOzlFOn7p2qVVp0Aw==
X-Received: by 2002:a05:6512:3d25:b0:540:2fe6:6a3a with SMTP id 2adb3069b0e04-54284824497mr591204e87.57.1736328125802;
        Wed, 08 Jan 2025 01:22:05 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------INxmOHM58UpMOZnvV7rjrCbl"
Message-ID: <e365acba-a98c-45f5-b8b4-f566f6c03d70@gmail.com>
Date: Wed, 8 Jan 2025 10:22:05 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [for-4.20][PATCH] xen/arm64: Drop relocate_and_switch_ttbr() stub
To: Michal Orzel <michal.orzel@amd.com>, xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
 <julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
References: <20250108075719.84967-1-michal.orzel@amd.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <20250108075719.84967-1-michal.orzel@amd.com>

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


On 1/8/25 8:57 AM, Michal Orzel wrote:
> In the original patch e7a80636f16e ("xen/arm: add cache coloring support
> for Xen image"), the stub was added under wrong assumption that DCE
> won't remove the function call if it's not static. This assumption is
> incorrect as we already rely on DCE for cases like this one. Therefore
> drop the stub, that otherwise would be a place potentially prone to
> errors in the future.
>
> Suggested-by: Julien Grall<julien@xen.org>
> Signed-off-by: Michal Orzel<michal.orzel@amd.com>
> ---
> As suggested by Julien, we should have it for 4.20. Leaving a stub like that
> without something like BUG_ON inside can potentially lead to problems in
> the future provided the function misuse slipped through the review process.
> ---

Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>

~ Oleksii

>   xen/arch/arm/arm64/mmu/mm.c | 2 --
>   1 file changed, 2 deletions(-)
>
> diff --git a/xen/arch/arm/arm64/mmu/mm.c b/xen/arch/arm/arm64/mmu/mm.c
> index 26361c4fe4c0..c1efa1348aee 100644
> --- a/xen/arch/arm/arm64/mmu/mm.c
> +++ b/xen/arch/arm/arm64/mmu/mm.c
> @@ -171,8 +171,6 @@ void __init relocate_and_switch_ttbr(uint64_t ttbr)
>        */
>       update_identity_mapping(false);
>   }
> -#else
> -void __init relocate_and_switch_ttbr(uint64_t ttbr) {}
>   #endif
>   
>   void __init switch_ttbr(uint64_t ttbr)
--------------INxmOHM58UpMOZnvV7rjrCbl
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 1/8/25 8:57 AM, Michal Orzel wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:20250108075719.84967-1-michal.orzel@amd.com">
      <pre wrap="" class="moz-quote-pre">In the original patch e7a80636f16e ("xen/arm: add cache coloring support
for Xen image"), the stub was added under wrong assumption that DCE
won't remove the function call if it's not static. This assumption is
incorrect as we already rely on DCE for cases like this one. Therefore
drop the stub, that otherwise would be a place potentially prone to
errors in the future.

Suggested-by: Julien Grall <a class="moz-txt-link-rfc2396E" href="mailto:julien@xen.org">&lt;julien@xen.org&gt;</a>
Signed-off-by: Michal Orzel <a class="moz-txt-link-rfc2396E" href="mailto:michal.orzel@amd.com">&lt;michal.orzel@amd.com&gt;</a>
---
As suggested by Julien, we should have it for 4.20. Leaving a stub like that
without something like BUG_ON inside can potentially lead to problems in
the future provided the function misuse slipped through the review process.
---</pre>
    </blockquote>
    <pre><font face="monospace">Release-Acked-By: Oleksii Kurochko <a class="moz-txt-link-rfc2396E" href="mailto:oleksii.kurochko@gmail.com">&lt;oleksii.kurochko@gmail.com&gt;</a></font></pre>
    <pre><font face="monospace">~ Oleksii</font>
</pre>
    <blockquote type="cite"
      cite="mid:20250108075719.84967-1-michal.orzel@amd.com">
      <pre wrap="" class="moz-quote-pre">
 xen/arch/arm/arm64/mmu/mm.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/xen/arch/arm/arm64/mmu/mm.c b/xen/arch/arm/arm64/mmu/mm.c
index 26361c4fe4c0..c1efa1348aee 100644
--- a/xen/arch/arm/arm64/mmu/mm.c
+++ b/xen/arch/arm/arm64/mmu/mm.c
@@ -171,8 +171,6 @@ void __init relocate_and_switch_ttbr(uint64_t ttbr)
      */
     update_identity_mapping(false);
 }
-#else
-void __init relocate_and_switch_ttbr(uint64_t ttbr) {}
 #endif
 
 void __init switch_ttbr(uint64_t ttbr)
</pre>
    </blockquote>
  </body>
</html>

--------------INxmOHM58UpMOZnvV7rjrCbl--


From xen-devel-bounces@lists.xenproject.org Wed Jan 08 09:34:25 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 09:34:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867035.1278434 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVSS0-00058S-0m; Wed, 08 Jan 2025 09:34:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867035.1278434; Wed, 08 Jan 2025 09:34:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVSRz-00058L-U5; Wed, 08 Jan 2025 09:34:07 +0000
Received: by outflank-mailman (input) for mailman id 867035;
 Wed, 08 Jan 2025 09:34: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 <SRS0=svEr=UA=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVSRy-00058F-OY
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 09:34:06 +0000
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com
 [2a00:1450:4864:20::42e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b3b1702a-cda3-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 10:34:05 +0100 (CET)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-3862b40a6e0so9035473f8f.0
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 01:34: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
 ffacd0b85a97d-38a1c829120sm53848916f8f.6.2025.01.08.01.34.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 08 Jan 2025 01:34:04 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b3b1702a-cda3-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736328844; x=1736933644; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=CCdDVghLGg0Q3K+GDJyH1dpmZ+OwRHgtzuyMzO6WzyQ=;
        b=JAKzg9wbbW2chULrOrHP4OG6zuXWL0SxA/Awk3+6xrSNXtm7f9WM07XJggQjtgitGX
         DnlalS/D6su7xO7krnVAybFb3ZuIvpmiL7mAKyaNIdqh6BblB5e1V54rvl6hoI9cQdlD
         wIsu9e2aw74uLFlfG90pubipbEmMrFtntRSQF3O/cZBRwllCiuKyFO7ny+S+fgdzmyer
         k/Yv9dIw0DpMnw3rde9/sp0Scf1GUPVS8VRS0Lvc8bp4K+hidnYO6Lj+cC1x0Gq3vNUK
         GM91ImyWr8uZh9fzm/gbaZ8LSseQ1fA0uDmwySl2Iazp/SE3dPusXixiyWsCbS19fd/9
         FLZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736328844; x=1736933644;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=CCdDVghLGg0Q3K+GDJyH1dpmZ+OwRHgtzuyMzO6WzyQ=;
        b=AbppVVExbpx7sfmy+ulNC+EZ+50pQ8kJQjrGuPV5LmnAt2lpGOntds84qNpQTtp8pl
         atQ18IsrzjM0d/D3qeyGYRh7FFN6KrzWi4b57JTbk5TDtpV042Ju337X77G83jPXDMFQ
         Zeg1RkdTPglosaMO6UJ3MIgXwgJwzL38BF+zw7meB9ftUDW023Ge9ieFnhOegLVldyae
         JpODLUZJVwWuo0GcUAtYljJxUkIe7QiZ8BoM89cpKWesh35LLpseGTNZM9+TGbwoetBf
         uFrhImu4kWx6jYdpMn6BiAKVRsJSAeYCxc/84QA7PQ4r0MAgh4XcD6ziZpX5ZawrM3sj
         1Ydg==
X-Forwarded-Encrypted: i=1; AJvYcCX1myHko2VOxBY19R0MSuj7PaLNFpRMustQO7a7XaCGjni+/grPYzfCDNqK8r3tYmx0T12mf6QMc0g=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yww7Opb3ldE8w47nfgvuntaU22C9dRMT+neuJO5pcweIBLLfzeX
	9FSs+b+cIDxKBX29aVQ+b91fP6VNBcfoULj6XtgXJy9OLBaAvEH8QtU5IZ7rJQ==
X-Gm-Gg: ASbGncuGbfgoN9VGrdDODvRUmw2WWf+KqBirc5my+nhccl/8LTF95YdTbQa3Imr+9A4
	/JWV2l90F2tvr1uenybgbR0M1x7i9X7P4zq9BzpGLoDzwpgFR1x+Q2KAKHu5YRgyg0NtllU6nyw
	jaMNMuSgMvY1ojLK2uisCeNgAwv9k9q4+vuyc65ZhEY97Dz1VuOd25Aftq09zW9ze0x/rea17XG
	QyR5iCjogcj+g0+M/p50jXd3ia5bVgRVvuxBgs29lV/pOzqZxZ/QEos3Qn8UJt4JhQJWYQnUhr3
	OM9VTJg14fQppsw/ouAB3cuAvL6o6mA3l8y/XWWdbw==
X-Google-Smtp-Source: AGHT+IGyrlra4zxi9lwPFWSLVi713VtWvAZWR/77b9wZUg+LYiu1FXhkUoyu0qja8kuCluAUSfIEMw==
X-Received: by 2002:a5d:64eb:0:b0:38a:50fa:d582 with SMTP id ffacd0b85a97d-38a87363364mr760130f8f.59.1736328844449;
        Wed, 08 Jan 2025 01:34:04 -0800 (PST)
Message-ID: <4ab75218-51cd-44a0-a6de-ad0f068a7361@suse.com>
Date: Wed, 8 Jan 2025 10:34:02 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 2/7] xen/events: don't allow binding a global virq from
 any domain
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <20250107101711.5980-1-jgross@suse.com>
 <20250107101711.5980-3-jgross@suse.com>
 <577427ff-61e2-4fc9-8853-a7eec3f69bb6@suse.com>
 <5261716e-a2f4-4423-bb8d-17e36bf34538@suse.com>
 <511c3207-20b8-4110-a5ef-55f8b428074d@suse.com>
 <f0cb4d80-5d26-437e-b6ee-a45f0157fc19@suse.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <f0cb4d80-5d26-437e-b6ee-a45f0157fc19@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 08.01.2025 10:02, Jürgen Groß wrote:
> On 07.01.25 17:38, Jan Beulich wrote:
>> On 07.01.2025 17:07, Jürgen Groß wrote:
>>> On 07.01.25 16:34, Jan Beulich wrote:
>>>> On 07.01.2025 11:17, Juergen Gross wrote:
>>>>> @@ -479,8 +486,13 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind, evtchn_port_t port)
>>>>>        */
>>>>>        virq = array_index_nospec(virq, ARRAY_SIZE(v->virq_to_evtchn));
>>>>>    
>>>>> -    if ( virq_is_global(virq) && (vcpu != 0) )
>>>>> -        return -EINVAL;
>>>>> +    if ( virq_is_global(virq) )
>>>>> +    {
>>>>> +        if ( get_global_virq_handler(virq) != d )
>>>>> +            return -EBUSY;
>>>>
>>>> Hmm. While this eliminates the problem for the common, race free case,
>>>> the handler changing right after the check would still mean the bind
>>>> would succeed.
>>>
>>> Are you fine with me adding a paragraph to the commit message saying
>>> that a future patch will handle this case?
>>>
>>> This future patch is patch 4 of the series, which will need to be
>>> modified to check the handling domain inside the event_lock.
>>
>> I think this would be okay, so long as patches 2...4 are then also all
>> committed together.
>>
>>>> Plus this way you're breaking a case that afaict has been working so
>>>> far: The bind happening before the setting of the handler. With a lot
>>>> of unrelated if-s and when-s this could e.g. be of interest when
>>>> considering a re-startable Xenstore domain. The one to take over could
>>>> start first, obtain state from the original one while that's still
>>>> active, and be nominated the handler of the global vIRQ only in the
>>>> last moment.
>>>
>>> This is a racy situation, too. If the old domain receives the virq after
>>> sending the state, this would need to be handled by transferring the virq
>>> information to the new domain, which can result in a never ending story.
>>>
>>> This is the reason why the domain state bitmap is reset to contain all
>>> existing domains to be flagged as "changed", as otherwise a change might
>>> get lost.
>>>
>>> I'd rather be able to handle today's use cases in a sane way than to try
>>> handling any weird future use cases which we don't know yet.
>>>
>>> I think today's behavior is more or less insane and the new behavior is
>>> much easier to understand and more intuitive.
>>
>> Hmm, I'd like to leave this then for input by other maintainers.
> 
> Just one additional remark to your re-startable xenstore domain scenario
> above:
> 
> It wouldn't be possible today to do the same with a xenstore daemon in
> e.g. dom0, as binding the virq another time from within the same domain
> would be rejected by the hypervisor. In the xenstore domain case you'd
> either need the old domain to ask dom0 to change the handler (so much
> about less communication needed),

Not quite. There needs to be an indication anyway of info transfer being
complete. That'll be where Dom0 would then (also) put in place the new
handler. The vIRQ first arriving in the new XS domain could then serve
as an indication that it is now in charge of the system; I didn't check
whether a courtesy one would be sent right away, or whether such sending
might need adding. (Plus anyway - XS is only an example here.)

Jan

> or you'd need to give the xenstore domain
> the right to do the handler change itself, requiring to use flask or to
> modify the dummy XSM rights of the xenstore domain.
> 
> 
> Juergen



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 09:37:19 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 09:37:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867045.1278444 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVSV3-0005kB-GO; Wed, 08 Jan 2025 09:37:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867045.1278444; Wed, 08 Jan 2025 09:37:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVSV3-0005k4-Dn; Wed, 08 Jan 2025 09:37:17 +0000
Received: by outflank-mailman (input) for mailman id 867045;
 Wed, 08 Jan 2025 09:37: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
 <SRS0=HByp=UA=arm.com=Bertrand.Marquis@srs-se1.protection.inumbo.net>)
 id 1tVSV1-0005jy-Kd
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 09:37:15 +0000
Received: from EUR03-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur03on20608.outbound.protection.outlook.com
 [2a01:111:f403:260c::608])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2490eabb-cda4-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 10:37:14 +0100 (CET)
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by AM8PR08MB5860.eurprd08.prod.outlook.com (2603:10a6:20b:1de::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8335.11; Wed, 8 Jan
 2025 09:37:11 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a%4]) with mapi id 15.20.8335.011; Wed, 8 Jan 2025
 09:37:11 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2490eabb-cda4-11ef-a0df-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=KG/Etf0/KQZutg/lLkrzGj3a/17pwvu+JDdKr8XhlBREwyHsEyZOiu1jC2DLl98nsvEDPyrn0TdTzXbyafFUgFMnxUQRAPzm9gA/A7684lqTJPZHLvdzLkOnbbxesPRLpiKWXukt9Om7UHJbLNn/Il08HRsmUrJJGcWsSdNn95Hw1PqPHJUd5AMJvXmJu0qABnoKFdHx0LzTNSSR6bk+DynXggsR8SaeBB5MiHGLZ9+eIxEGgRMyBIveaPFnwDz3jG6RRgm1RFUTawmB5a728BbLF11daVR5dyciwIRWbtQ7nG64+OOf2uztusY8sUDwJLk1UskBjfB5zeaqDDPLyQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=rXv81ywe/bdshr4y01C9FshKxkgV76u/Rmo0oTUFoNk=;
 b=hdfrL5bS9t39ROn1mgBtLPplI82uODvSfugXSnnTxFHPQJb+PKFzIqC5dbMq8OqWzjoC6xH/+UwafK6MNQQe/s6j/xgEjUwZqc4Kj7sHXmw3AyJYhXBGFXEIZ8n70UC8uVaW4A2X5BU10wZi1VG6ILRqC9L8qn6TH12k4k1VltIF7FJAdt/hZGPMo6oNiSoJ3nfH2S5GjuRdyhZHQ+CXj12FLJvlWGD7T7g8puF0pYmtDQrPSSxnLkTQt6FNWDg3HTtYr+74T+LnxnDHas1zTMHsX6azdkLYI2XIaUylWOEIWvK+wNQf9nH/wNrxcAKZXUL0OChYLHktfc4+clf2VQ==
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=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=rXv81ywe/bdshr4y01C9FshKxkgV76u/Rmo0oTUFoNk=;
 b=Rx/u2Wkikq3UrR5b7PK0wTJkzldodHGZXij3X/5H7lF9JrSzo0GvyX9bBYVro0affKTYwD3gFRPVKAqtx58UuoKpKNaI4gYRXErTVJyaozfQ4azem6te6SsKpXMdNvzy1jkZHTP4nA+WhNt4Hkd9/PZr8nMDhwd4OoYbt+FHxZw=
From: Bertrand Marquis <Bertrand.Marquis@arm.com>
To: Michal Orzel <michal.orzel@amd.com>
CC: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Stefano
 Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Volodymyr
 Babchuk <Volodymyr_Babchuk@epam.com>, "oleksii.kurochko@gmail.com"
	<oleksii.kurochko@gmail.com>
Subject: Re: [for-4.20][PATCH] xen/arm64: Drop relocate_and_switch_ttbr() stub
Thread-Topic: [for-4.20][PATCH] xen/arm64: Drop relocate_and_switch_ttbr()
 stub
Thread-Index: AQHbYaL71xynnWB460ejnOn44lZOwbMMnQ8A
Date: Wed, 8 Jan 2025 09:37:11 +0000
Message-ID: <2A19935A-D2A2-4780-A2E2-668EB25E2D15@arm.com>
References: <20250108075719.84967-1-michal.orzel@amd.com>
In-Reply-To: <20250108075719.84967-1-michal.orzel@amd.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.200.121)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DB9PR08MB6588:EE_|AM8PR08MB5860:EE_
x-ms-office365-filtering-correlation-id: 2a5f99c6-4431-4e46-bbf2-08dd2fc80717
x-checkrecipientrouted: true
nodisclaimer: true
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?us-ascii?Q?1jk53Fva1UL+FbGhn9pxIPFOJPuQ6hGvrz+q1eUfZlDhXBzsDRIoXXYEgqq6?=
 =?us-ascii?Q?hHA/3zqacmgRfXz7XuLcXOiY9WQFqK3Wybr1RgCkX/RCC4Aboh/4KbnWeohN?=
 =?us-ascii?Q?/PXIsTSV+lnbjBf5xxBIcbj7RKZW1nuBg+pulPU5APyJLno9bk3F1b7Do++7?=
 =?us-ascii?Q?Grd9Kltp7kLBcjXGk0A9D8QMgn5rWwk/L5ds+TU//+we4XKUs4hrlG34VfeT?=
 =?us-ascii?Q?4mvw7eWALF04bj/26xhe40oJK+d42dNeHJsYm+FRqJyxLWB8bKgSka1rRBJY?=
 =?us-ascii?Q?adDqcnaiq5hRILZP5c8OJLFwH8Y5r+bW8jh+awlWRhLA01d/Pb8QNQaXP3VK?=
 =?us-ascii?Q?mNZDO5LaImlm4BSJcxR4XiYlsbz8z4Xv7UCgBOCXJFtXGdNr0l11lXw19lTM?=
 =?us-ascii?Q?u7mWIPgfSJZ5udQfEDwH6Cd5nUdvn4tb2FDytbakRfzgfhGsh9maZyd/R9Dc?=
 =?us-ascii?Q?vwbPX7g8i7LWcp8donjWxjsrYw7YRz9gy+fng4tNhJo3YuyQ296i78/l6ULz?=
 =?us-ascii?Q?+bB703yNLpQCf04EvrRIGny4doDigCDNkoiQyqoh3WuAYMHuNAAkBPLsIFN9?=
 =?us-ascii?Q?ZZ94hpjtq8XcCcj92m0TZUUcUORoiRAQl0fJVT4pLnumKhuZsavFGZflTOmL?=
 =?us-ascii?Q?3mMTjaK6fVUfxoQwun2neYkfPm/FzOzTR+nkAnaHavt4JAcpr6D+XgRoMvoh?=
 =?us-ascii?Q?B+uNBF743av1fPNT6GzCBM8c14WSoXkbPGcBCEQddbPBwRaFF1+0S0AJVWAd?=
 =?us-ascii?Q?Mthwf9x8QawKdIQZuPkjVxcJ3zcLZRLjwBbdHIV9ph4bZkUHOX/pBcV6P0pi?=
 =?us-ascii?Q?ysSwHwKaILMvTAQNFsLfYaQd5gebMiJ3QqSYbrLvmC91zTq8+HM7JyQN1HAT?=
 =?us-ascii?Q?GgzrASyOmNdF3FASbPVnmn/xz/OM+K143tNOvEoWaBnXy2rYoHrkV6N6tWgI?=
 =?us-ascii?Q?ZJ5c8vbuAuGqzZbJo4loyccvFIt+RVpvfBtTiTIBUs2XQK6yUxXr+0rM7i0M?=
 =?us-ascii?Q?pBagtInG6dGuXDx1a9mKTKwuD8FQmCxa/PekkGM1UDSngMOy9+BNtkb/5FBJ?=
 =?us-ascii?Q?fiPF+bu/V7MYbney1XgK501VmNDi7E/ITgkLZVpgjB0JjYVAtHKcMblKwF8v?=
 =?us-ascii?Q?fdfJy26xjrNXhZJlzku11Rwc2gJLLS3QHZWd77ZXvJP3C+TLFOMkkH6rb4If?=
 =?us-ascii?Q?2IrHxgbhyQbye6/Okz2vVpwmU7/VjqwRqvpp4Hzpf3oYKcq58f0Z3vIHTECR?=
 =?us-ascii?Q?o6dtb2M9ldTKwBuYt+nIFBWH9uGAIwEax1Jxa85Pxgbfd7m/aPPjg4P2t6GI?=
 =?us-ascii?Q?Kyro2Qg4Yv8oOE3+kof/RAGHAoQr35dSp6XDrrhoS7rpaS2ulazEs+6o64Gk?=
 =?us-ascii?Q?JP4t7mlQYdTPxfNZVQ3jiRegzeDkeAKAb+xpAM5qruOmQm0QrUc0cjo4UzMn?=
 =?us-ascii?Q?TCNpYj1fFgyI3Z1HiovMaMwCDcBZsjKX?=
x-forefront-antispam-report:
 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:(13230040)(366016)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?JPvngvbsH1IwGB9wNjyT67GQUu3tGlqgp61HaHvr3LaCzqMO8/1FHItWPfUX?=
 =?us-ascii?Q?bJ57vkFmL+uAvfsnivAd3mv+BugXyigfGg8zuAua9tFnLgB3ENKuBHLiga+r?=
 =?us-ascii?Q?6l6yk3B3/wrrukmxRQndhjW5w1j78IUdDHg5x646Pm/5TdjOyts0jh2FJEvp?=
 =?us-ascii?Q?Ly2JNiq4bPzsRzVCIaOPVcBhuTOHhlh958WBTeC5uJPYVD9OL25AKzAUiXJC?=
 =?us-ascii?Q?NgFdweZK4Io1qiJj+/38d2BQg+GSBbPAlF6mHnd7YppxLM/WNW8DmiOhwtP/?=
 =?us-ascii?Q?TjCQWGMXJMvV6hBhRcOLJtUHaKI888G7j9hCRZHLA3RwMB2iAiXlvKByo1OQ?=
 =?us-ascii?Q?e67bhHLVpg33ZG5JLdnVsd5uT6q4+SPAOv1e0t0wgNerG3A7QhQ3+Auax7zP?=
 =?us-ascii?Q?h6kQsUxc0+F/3MdQOpVEIH7EoyL7vsNIyJBIjOVclE6wNPRmwGbsdcApS3iy?=
 =?us-ascii?Q?CvmuXGuzlL3zIaUxyGJ9YSfmzXqHBZwIjwREX4cixXzy3uuFE+9H4rlCZ4pR?=
 =?us-ascii?Q?sj2DX5wzsTw7c/0z3NpRxIkhPBUIypnIkx7G+FcCRI6MUyAvUjhI6J/qUf3O?=
 =?us-ascii?Q?V3IRkeVp3NsFFUBbZLWJ1eSR+QWasTPlN09dlrF+f9hhMZOWt7RvnX1eyU0d?=
 =?us-ascii?Q?bC9UCR0fob7YlVFTZiLKzlkxmq0lqkLtDNDNBpRvvBLKVVBojWrhd9X4+CTl?=
 =?us-ascii?Q?j2qzXpso3bYi/u8/ZXCaxI6Z2zeo8usgeHm22b6iNFo+7kB9pwsPEsGG33+f?=
 =?us-ascii?Q?bEBNjN7aREe/X7AEVoIcXCO8Gdu/J6q3xGaD8rTmmkuvZFc8vQDtYNuDdNmJ?=
 =?us-ascii?Q?eNXiYvXc6AEhT9uOuC8mA5eGkGt1HXa4dF5+5oJLAZk6WLWCTOzLfpreuhQW?=
 =?us-ascii?Q?V82kfgv9Z6XYq5B9SdR4OC1y4CvL6LhYKTzL81A/IZ37mnWnp8KZluvtH5fl?=
 =?us-ascii?Q?Vrh3wMwbYqpoQVpDhBpobfgggbv+wnB6sQ9snxkzuHzbc8lhIhfetopjwBzE?=
 =?us-ascii?Q?CzRFWy5ELw5zHvSjWqEXKqc+s4NscbqL2NTFzbd+CyBgEGH7vk4Lpbf/Prnp?=
 =?us-ascii?Q?MLEs9tJTwXJ71YqtvNYXGSc80zd3Eqc0Yut/ZUyjCbFofBdjbmCLhuQ6KZbA?=
 =?us-ascii?Q?iqD4qGCmCBmFP8TGuoU7RAwYDNAc7lofYgmwMxlTq6qq27NqQHY39HU4D91+?=
 =?us-ascii?Q?mqh01Ql/wP8uBo6tLIX9GmhRwi34/A98454mOWsQ1raGEt7VNR+QBPfVb3ug?=
 =?us-ascii?Q?dxZ0/74fkb0+Lq3fNLz0/IzOp1EheIAMrwRPU+ONC8lrPFQe67zlXqLP2NIx?=
 =?us-ascii?Q?bSsxuivIscMYGlg6WdEiJ2ukVY1zGvfd2t+217in8bs5WfG7TF8dNFsbOy1y?=
 =?us-ascii?Q?kKwJPMvrMhimanc6JfblQzOTCEYeQIltUlYH5838mykqWCYypeRKWD8JS57G?=
 =?us-ascii?Q?Y7XDvq9L1yvQUM8/0j9Hc3QizvLMWofTCktm6kREVMjMDi23PPfqM3MxxClh?=
 =?us-ascii?Q?62JCE4Jh4kJR+884OK3LQmKp12Z68z926ucrRH9N9xMa3IB/yDv2T5GKV/HD?=
 =?us-ascii?Q?6qHxvO4Yc/t6opOOmcOyVD+war3mW59uXK9WsYUnmfWEsramArbCCH+EZUTb?=
 =?us-ascii?Q?uA=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <89BDB8EB78C93C4F8498F6E28FA18E0D@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DB9PR08MB6588.eurprd08.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2a5f99c6-4431-4e46-bbf2-08dd2fc80717
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2025 09:37:11.5329
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: bPuUd7wQ3espbe/tVWsyVL4eAtPxJMfRX8qg4usRkyy9kY7wl3bPZ2XZ6MLnVVs3zslSXDnfkPGHepCWr9auRsUHgOPcQRKZzY2ydHboUqE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR08MB5860

Hi Michal

> On 8 Jan 2025, at 08:57, Michal Orzel <michal.orzel@amd.com> wrote:
>=20
> In the original patch e7a80636f16e ("xen/arm: add cache coloring support
> for Xen image"), the stub was added under wrong assumption that DCE
> won't remove the function call if it's not static. This assumption is
> incorrect as we already rely on DCE for cases like this one. Therefore
> drop the stub, that otherwise would be a place potentially prone to
> errors in the future.
>=20
> Suggested-by: Julien Grall <julien@xen.org>
> Signed-off-by: Michal Orzel <michal.orzel@amd.com>

Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>

Cheers
Bertrand

> ---
> As suggested by Julien, we should have it for 4.20. Leaving a stub like t=
hat
> without something like BUG_ON inside can potentially lead to problems in
> the future provided the function misuse slipped through the review proces=
s.
> ---
> xen/arch/arm/arm64/mmu/mm.c | 2 --
> 1 file changed, 2 deletions(-)
>=20
> diff --git a/xen/arch/arm/arm64/mmu/mm.c b/xen/arch/arm/arm64/mmu/mm.c
> index 26361c4fe4c0..c1efa1348aee 100644
> --- a/xen/arch/arm/arm64/mmu/mm.c
> +++ b/xen/arch/arm/arm64/mmu/mm.c
> @@ -171,8 +171,6 @@ void __init relocate_and_switch_ttbr(uint64_t ttbr)
>      */
>     update_identity_mapping(false);
> }
> -#else
> -void __init relocate_and_switch_ttbr(uint64_t ttbr) {}
> #endif
>=20
> void __init switch_ttbr(uint64_t ttbr)
> --=20
> 2.25.1
>=20



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 10:07:38 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 10:07:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867053.1278453 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVSyK-0002SL-OJ; Wed, 08 Jan 2025 10:07:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867053.1278453; Wed, 08 Jan 2025 10:07:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVSyK-0002SE-Lc; Wed, 08 Jan 2025 10:07:32 +0000
Received: by outflank-mailman (input) for mailman id 867053;
 Wed, 08 Jan 2025 10:07:31 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=UrZA=UA=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tVSyJ-0002S8-5c
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 10:07:31 +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 5e7fdd70-cda8-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 11:07:29 +0100 (CET)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-436326dcb1cso110559455e9.0
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 02:07:29 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c828a8dsm52895732f8f.2.2025.01.08.02.07.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 08 Jan 2025 02:07:28 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5e7fdd70-cda8-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736330849; x=1736935649; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=gHYfKvzO1b6IQBL792DS4HTlxjx0BDDUAhi22w3xB5M=;
        b=vYovN5dpqQ6ym0D98s0J/xO6Q21l9eW7FSdnPmYQkQ7cfNJI1G/09ERbZj8ugyiaBl
         xRyPY4Eoiz3c6HvRzXM9Bk27RO5LwK86StPZLxynC/W6xrhevjVDdX/mB51XKG4li4IM
         Vq+0Rtt2XAAt41Md+53PqMLsMbzXWaWFqPhZA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736330849; x=1736935649;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=gHYfKvzO1b6IQBL792DS4HTlxjx0BDDUAhi22w3xB5M=;
        b=wpDoSsh622aEY1SOyuHqwHaS5nS88qA1ncnkBwN3sdBzg1EXgV7uG+wsjH0mZ6WyUc
         dBIrYH0Qgtep8RVfJzFnHplQNfvHNK/5hgYk17tHWJ10JMkvi37Boj05B3WBdDZlaAI/
         zSx/j0un5aPj3eKXnBXsew7HbjA0pLLPIHnbMgBtc/EBkcSvXd2cd3VreG2divqkVKG7
         c3RYd1ZZ53uEMTBASTOyvMuIKerLgonZvT7TCZZBk5w8tsr7J9CKeCpCrr+njyS4+smB
         BwzfKZaalW7cUm8HQcQyI5qliZ3LCZN07xYoQp9BNlehVq025AxYDb53PLMLK4sneq4h
         bJOQ==
X-Forwarded-Encrypted: i=1; AJvYcCXNxJ+jKIpjAfsa/1eW+6y4mPtPBNI27Qk1zy6AsdpDC9uewXrw08ZP8CiBp0KoStKZmIK3KwgWyfQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwmpHZjQ3EOpPtoSK92c1nexOIbdNRXh7qkaM4gG/4JaRe1cSfD
	V7MhilSapji1eegY+x8OaSzNMt11k4MzHvN4lQl/mc5JkBBZOZUNN/eVzTjzgS8=
X-Gm-Gg: ASbGncvx13f7r+7zieHxKzZhTI7qMj2XxKLaGf6KuLODYOzfSPYyzslaBSsm8/QEWDs
	AUAAnNzVmR57e4ym5Hq8G7P9VCr/kv/faoWVfCoT2gCdCPjIwFI22NN/0BCcbq8eYdHB5hSgCHW
	eQwiMCH4jfGZy2jTQ2cRIegfP80p2nqajSupit1yAd0z1kmD/it6yXBctAMrp+apndDRWAKUKaO
	ZONbxGK3yqb2PZWfyG9BArw8YrYrVlhWQKoM5K2V3mzbBDzJ0X8DQgtYzpI16yTcRS55ZO5PA0Z
	7BQ2pK2ODgOF7qn8dEPa
X-Google-Smtp-Source: AGHT+IGffmGX3Jm2bE4Yq7/r9cJiZzwg+Me2b/KUaMurZpRreOmtSqd5WVJIexZbPtB5aD6fnhp6yQ==
X-Received: by 2002:a05:600c:314b:b0:434:f270:a513 with SMTP id 5b1f17b1804b1-436e26ff287mr15082405e9.29.1736330849049;
        Wed, 08 Jan 2025 02:07:29 -0800 (PST)
Message-ID: <a1a3c0b7-63ee-4764-b33a-48f84ac70a8e@citrix.com>
Date: Wed, 8 Jan 2025 10:07:28 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20] x86/traps: Rework LER initialisation and support
 Zen5/Diamond Rapids
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
Cc: Jan Beulich <JBeulich@suse.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>
References: <20241231192002.1753737-1-andrew.cooper3@citrix.com>
 <7482da8f-8bf1-4f0c-b15b-7a31b27b48f3@gmail.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <7482da8f-8bf1-4f0c-b15b-7a31b27b48f3@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 08/01/2025 9:15 am, Oleksii Kurochko wrote:
>
>
> On 12/31/24 8:20 PM, Andrew Cooper wrote:
>> AMD have always used the architectural MSRs for LER.  As the first processor
>> to support LER was the K7 (which was 32bit), we can assume it's presence
>> unconditionally in 64bit mode.
>>
>> Intel are about to run out of space in Family 6 and start using 19.  It is
>> only the Pentium 4 which uses non-architectural LER MSRs.
>>
>> percpu_traps_init(), which runs on every CPU, contains a lot of code which
>> should be init-only, and is the only reason why opt_ler can't be in initdata.
>>
>> Write a brand new init_ler() which expects all future Intel and AMD CPUs to
>> continue using the architectural MSRs, and does all setup together.  Call it
>> from trap_init(), and remove the setup logic percpu_traps_init() except for
>> the single path configuring MSR_IA32_DEBUGCTLMSR.
>>
>> Leave behind a warning if the user asked for LER and Xen couldn't enable it.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> ---
>> CC: Jan Beulich <JBeulich@suse.com>
>> CC: Roger Pau Monné <roger.pau@citrix.com>
>> CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
>>
>> For 4.20.  This is needed for Zen5 CPUs (already available) as well as Intel
>> CPUs coming shortly.  It also moves some non-init logic to being init-only.
> As a user can enable/disable LER and support for Zen5/Diamond Rapids is added, and this patch
> is already in staging, I think we could mention that in CHANGELOG. If it makes sense I can do
> that during finalization of CHANGELOG before release. Does it make sense?

LER is for advanced debugging.  I don't think it's user-interesting
enough to justify calling out in Changelog.

I am intending to do a Changelog entry for Zen5 support generally,
although I'm holding out hope that AMD will publish an updated APM so I
can cross check a few extra details before we get too deep into the Xen
4.20 release.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Jan 08 10:10:31 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 10:10:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867063.1278463 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVT1C-0003vy-5a; Wed, 08 Jan 2025 10:10:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867063.1278463; Wed, 08 Jan 2025 10:10:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVT1C-0003vr-2r; Wed, 08 Jan 2025 10:10:30 +0000
Received: by outflank-mailman (input) for mailman id 867063;
 Wed, 08 Jan 2025 10:10:28 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=svEr=UA=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVT1A-0003vh-T9
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 10:10:28 +0000
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com
 [2a00:1450:4864:20::429])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c8266210-cda8-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 11:10:26 +0100 (CET)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-385e0e224cbso8263425f8f.2
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 02:10:26 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c89e43dsm53369272f8f.70.2025.01.08.02.10.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 08 Jan 2025 02:10:26 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c8266210-cda8-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736331026; x=1736935826; darn=lists.xenproject.org;
        h=content-transfer-encoding:autocrypt:content-language:cc:to:subject
         :from:user-agent:mime-version:date:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=ptw2j3iRaXshGQyZT4fu68y8VNXjLsYriz7sfdma9sA=;
        b=L1omUP8kbAemOW1NCgbtBjBVI1Ixilb76t67Wi6HVNWj8ONv0Dpu2dosblw8nJav7J
         yk5U3JDNNTSqeSe6nnNsA+kFuPU3xPOwJr5nHmfnfkeJ+CFfMx1T24Grej+JtQjCFjLK
         u1wAWDmlk/NJ5FGhC8bul47VytQ72BCt+0wPEED6mFYFd95GcTWuAV2kNtqHj+fMZmeS
         NWGETtYGSExjkfZkAGWG3vQfKdTLzpyZnTfDifrlqrJvbgkHmhYC5SwJ7IvwUTLydKj3
         1fXdJyTSenCctsIEs6H2CgDqP7x+Z11YCrd4yzQcPwcD/H00HppJ/WWiMRMa6p9YGQc2
         7nSw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736331026; x=1736935826;
        h=content-transfer-encoding:autocrypt:content-language:cc:to:subject
         :from:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=ptw2j3iRaXshGQyZT4fu68y8VNXjLsYriz7sfdma9sA=;
        b=w+FzylQs4XWDWR48zHSXMEsRZAg7XamWAyfxkEC8y9gz5IT+E9Pm2AY3gzP8lz2onP
         lAgjreiTtrvEN24Gy66BYwFSIKmkWRbPLG4Fiu7/UZzp1IZAUuL6bLuo4w7ntRVEHa/u
         ixkFepNtFJ2M3Upm0FOabN2jBFKQtVCwSOobhC/JqI/OenceN4Q7eY7axG4Lejio1Xio
         SqxFrAa6T9eqT5szV57SioLWcmjG8Q1GVuP34j3o9OSvWOyjNQ8kn2keNaB56NWB27L7
         AlXDs+3AOYYICjIlV8ymW21J24WPplqBojft3gwR92LCM1Asxc8PwSh1+xVROxrAHgEB
         ScqQ==
X-Gm-Message-State: AOJu0YwDGm3IqFCVsVJ+RFHGNPyE5dZw4GINNkbXxTU8e46GWGiXHxhS
	GQhxKr4FR0AiCnWSFDu5ufXgTNU0tgYJulZL9Etoin9ea8Ln6QfKoW8lNGLVhgjROJtxO/1AwJI
	=
X-Gm-Gg: ASbGncu+SJz+7S0G5XgLXQ2JaHSRUddHBB+hrRxuRtCJSLP00DqhiumOOIMbLHzdDC7
	YZOwtIbmE4dmICPZFWKRTf8c+tLpoZYnT3ysk5bxeS2uyzmPNoQUIwFufTlH919zw82E38Ddiqv
	uMNy8z8WvHTgx2PUwB5LhEMFA5tCBjaYhdD54oegTxvqNRRbfOIe+kFcEjP0sAq0BDNq7lrEhsZ
	H2fV7Q7eO4Mw9Ft1PVcUc6caUC1TeG2O1uMyA93aKpBc1RKZtpnwHBNjQt/N9xoEeJs4DIZPJvr
	X/Rm26gCPFrdacG6Jsdb0uHPWTyLKB8bzO6t9033kg==
X-Google-Smtp-Source: AGHT+IG59dOkEJ8WT4sjjxrurLckOkaOK5hCufNEx2KSGKA+i/g7eXLZyK3Hk10mapcf9e4ThGaaiw==
X-Received: by 2002:a05:6000:1acc:b0:385:db39:2cf with SMTP id ffacd0b85a97d-38a872c943fmr1520300f8f.12.1736331026360;
        Wed, 08 Jan 2025 02:10:26 -0800 (PST)
Message-ID: <14b65231-b83b-43fb-bbcf-dec5c07d285b@suse.com>
Date: Wed, 8 Jan 2025 11:10:24 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH v4 0/6] x86: memcpy() / memset() (non-)ERMS flavors plus
 fallout
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

While the performance varies quite a bit on older (pre-ERMS) and newer
(ERMS) hardware, so far we've been going with just a single flavor of
these two functions, and oddly enough with ones not consistent with one
another. Using plain memcpy() / memset() on MMIO (video frame buffer)
is generally okay, but the ERMS variant of memcpy() turned out to
regress (boot) performance in a way easily visible to the human eye.

01: x86: suppress ERMS for internal use when MISC_ENABLE.FAST_STRING is clear
02: x86: re-work memset()
03: x86: re-work memcpy()
04: x86: control memset() and memcpy() inlining
05: x86: introduce "hot" and "cold" page clearing functions
06: mm: allow page scrubbing routine(s) to be arch controlled

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jan 08 10:11:44 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 10:11:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867072.1278486 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVT2N-0004zG-Hk; Wed, 08 Jan 2025 10:11:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867072.1278486; Wed, 08 Jan 2025 10:11:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVT2N-0004z9-EZ; Wed, 08 Jan 2025 10:11:43 +0000
Received: by outflank-mailman (input) for mailman id 867072;
 Wed, 08 Jan 2025 10:11:42 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=svEr=UA=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVT2M-0004yz-He
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 10:11:42 +0000
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com
 [2a00:1450:4864:20::333])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f4171666-cda8-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 11:11:40 +0100 (CET)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-4361e89b6daso113925375e9.3
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 02:11:40 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436e2dc1763sm15465765e9.12.2025.01.08.02.11.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 08 Jan 2025 02:11:39 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f4171666-cda8-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736331100; x=1736935900; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=jiq6XWslhxdWPp8jdeQUdb+1Oh9S+Y/2AWgC7Fw0yEI=;
        b=PTm/g8gO4fYfyn6Qm6kOieCnGoxjGEY5MORxCrffXqExy/vnl9adwDKzwnkhbokMQL
         6y8QU02OxSy0zPYIcK8xzARuij1UX8axA7715T5o4upNHZZOn/lNsrGUOvsJFWG8oi2+
         T5CdQWSf3AcP7fgHQIW1PvhaHvX4dkK7U2ftpyVjplo/3Hqf0uvtRvQ8Al30H8ka//Ei
         W8OqNtAOmFyNPozshUWUd6cK2oS15IOwt8iZCMEtPJ3ecxJBL4CyiHlQ6Cumy4piyuGb
         hm/5QqGCspC1M16clU5pr8KZxGR306iuSkMFDtLJT2wAgQ8pwKUhVZ0Dbu3gecyNk8gD
         KG/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736331100; x=1736935900;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=jiq6XWslhxdWPp8jdeQUdb+1Oh9S+Y/2AWgC7Fw0yEI=;
        b=CAmydWSMiwaO2XyDKKiRozSCbE7An4LqUz1zKCEoP98l2pcSFIYOZJWyfNkJSSdyOE
         gN+uCZFKNHKQwScYGccrK4f8BT7is6/wwLX2PWKD1U7IB31hznxFsetLQYqHFlb+1TSN
         dsWAq3Uj8LdpieGjjVcNzOEgD/YSEJyLhi6wqnNvYhe1Ov15bYuBo/Vvgb2J/lG9ljLF
         YBeNx40G5IUI5vuBGu3ex7BSi4eDStPiRytDNhBfEGPZaiQyFL9F4Ic9GGfZaciE0Z2b
         eMLUKqsdTipMxt7+nb/OeKnW2ULU1AX4j4V+GKcfdK7zaofPNEcVS9Tvx66nlSj/IvR4
         n57g==
X-Gm-Message-State: AOJu0Yx/wq9JnjGpzAAWsekhX348JPm+TQwD1zmSd6kXISdqxdEWiOwY
	DSO1KZH6l0qxJGmT2E6BXodXz1VuM07dSTmkqeo/ErLxj4nDj9EGrHZqJg9XJsnxHVPTkhKZPWw
	=
X-Gm-Gg: ASbGnctuKTbpqKGuFv5A+jwDxQ/qGX4WPjmlSFIiJs3oczZatPa8zd/RYoeMJCqttM5
	B+nx8BhF52cNBBZRIfGbyIc5EZCUDADWi5Aq7Ln5FLTZtbuEHZyk+9NEL2lmmBBoTZS0WOAPHnd
	52KufjC6quLQ1QRY5VjsuTEINqJGR6KQxR2IgGBKzqbZt55S4xr4zPhXdB1dXmS0wD7ioYdjZgo
	ukytm8q4rB550wyb703D7ImS+Lf1UzBkXxlfqY+OuzG3vEYPkUFdmoim46tSEn/1Zq0BU1rmUjW
	W8CBT3ZjtBNaqeHIb8vsdh6mepWZmcZD9RPEjTTPXg==
X-Google-Smtp-Source: AGHT+IHxkzldPvFinqhqJsbizyW1OS7RrjlG9Mzgl6WpJKyH8mvMAFUwuvncRARsZ++CFHhtD9WYNA==
X-Received: by 2002:a05:600c:a09:b0:434:f1e9:afb3 with SMTP id 5b1f17b1804b1-436e267863emr15417995e9.3.1736331100027;
        Wed, 08 Jan 2025 02:11:40 -0800 (PST)
Message-ID: <2e61ad8d-3b1f-49bb-bc93-61c820d6caf3@suse.com>
Date: Wed, 8 Jan 2025 11:11:38 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v4 1/6] x86: suppress ERMS for internal use when
 MISC_ENABLE.FAST_STRING is clear
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
References: <14b65231-b83b-43fb-bbcf-dec5c07d285b@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <14b65231-b83b-43fb-bbcf-dec5c07d285b@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Before we start actually adjusting behavior when ERMS is available,
follow Linux commit 161ec53c702c ("x86, mem, intel: Initialize Enhanced
REP MOVSB/STOSB") and zap the CPUID-derived feature flag when the MSR
bit is clear. Don't extend the artificial clearing to guest view,
though: Guests can take their own decision in this regard, as they can
read (most of) MISC_ENABLE.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
TBD: Would be nice if "cpuid=no-erms" propagated to guest view (for
     "cpuid=" generally meaning to affect guests as well as Xen), but
     since both disabling paths use setup_clear_cpu_cap() they're
     indistinguishable in guest_common_feature_adjustments(). A separate
     boolean could take care of this, but would look clumsy to me.
---
v4: Also adjust guest_common_max_feature_adjustments().
v3: New.

--- a/xen/arch/x86/cpu/intel.c
+++ b/xen/arch/x86/cpu/intel.c
@@ -337,8 +337,18 @@ static void cf_check early_init_intel(st
 		paddr_bits = 36;
 
 	if (c == &boot_cpu_data) {
+		uint64_t misc_enable;
+
 		check_memory_type_self_snoop_errata();
 
+		/*
+		 * If fast string is not enabled in IA32_MISC_ENABLE for any reason,
+		 * clear the enhanced fast string CPU capability.
+		 */
+		rdmsrl(MSR_IA32_MISC_ENABLE, misc_enable);
+		if (!(misc_enable & MSR_IA32_MISC_ENABLE_FAST_STRING))
+			setup_clear_cpu_cap(X86_FEATURE_ERMS);
+
 		intel_init_levelling();
 	}
 
--- a/xen/arch/x86/cpu-policy.c
+++ b/xen/arch/x86/cpu-policy.c
@@ -487,6 +487,12 @@ static void __init guest_common_max_feat
      */
     if ( test_bit(X86_FEATURE_RTM, fs) )
         __set_bit(X86_FEATURE_RTM_ALWAYS_ABORT, fs);
+
+    /*
+     * We expose MISC_ENABLE to guests, so our internal clearing of ERMS when
+     * FAST_STRING is not set should not affect the view of migrating-in guests.
+     */
+    __set_bit(X86_FEATURE_ERMS, fs);
 }
 
 static void __init guest_common_default_feature_adjustments(uint32_t *fs)
@@ -591,6 +597,15 @@ static void __init guest_common_feature_
      */
     if ( host_cpu_policy.feat.ibrsb )
         __set_bit(X86_FEATURE_IBPB, fs);
+
+    /*
+     * We expose MISC_ENABLE to guests, so our internal clearing of ERMS when
+     * FAST_STRING is not set should not propagate to guest view.  Guests can
+     * judge on their own whether to ignore the CPUID bit when the MSR bit is
+     * clear.
+     */
+    if ( raw_cpu_policy.feat.erms )
+        __set_bit(X86_FEATURE_ERMS, fs);
 }
 
 static void __init calculate_pv_max_policy(void)
--- a/xen/arch/x86/include/asm/msr-index.h
+++ b/xen/arch/x86/include/asm/msr-index.h
@@ -490,6 +490,7 @@
 #define MSR_IA32_THERM_INTERRUPT	0x0000019b
 #define MSR_IA32_THERM_STATUS		0x0000019c
 #define MSR_IA32_MISC_ENABLE		0x000001a0
+#define MSR_IA32_MISC_ENABLE_FAST_STRING  (1<<0)
 #define MSR_IA32_MISC_ENABLE_PERF_AVAIL   (1<<7)
 #define MSR_IA32_MISC_ENABLE_BTS_UNAVAIL  (1<<11)
 #define MSR_IA32_MISC_ENABLE_PEBS_UNAVAIL (1<<12)



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 10:12:37 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 10:12:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867081.1278496 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVT3D-0005ZT-SP; Wed, 08 Jan 2025 10:12:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867081.1278496; Wed, 08 Jan 2025 10:12:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVT3D-0005ZM-PV; Wed, 08 Jan 2025 10:12:35 +0000
Received: by outflank-mailman (input) for mailman id 867081;
 Wed, 08 Jan 2025 10:12: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 <SRS0=svEr=UA=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVT3C-0005HN-W9
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 10:12:34 +0000
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com
 [2a00:1450:4864:20::32b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1426599a-cda9-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 11:12:34 +0100 (CET)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-436281c8a38so118367475e9.3
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 02:12: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
 5b1f17b1804b1-436e2e2275bsm15384075e9.40.2025.01.08.02.12.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 08 Jan 2025 02:12:33 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1426599a-cda9-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736331154; x=1736935954; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=zXvyugoFvnrztoDgpMNB+n4/oYBCMLezGO47d4RFcqU=;
        b=fjfIQI/cnumDqT+WSZKABaamHRqvX6UjGpbx96t36LPTrVsa7IvVpIkBu6+7i9pX4P
         1ykbz4uFHJdayztqxd3TjI+YWJ5YYeFf/h0Gzcir1ePIOQg4qSZtQXUHdzI3+gFhhRck
         N+OpizFpXGasmxJYkndLYSa8KwnGgOM6B38tzlWn69rgoRnADJnh0qZgHrs5BXL9V+1G
         Gmyno3fqlgGL5InQFyVB/NO/OXZyuN33E8tb1k+JQDK0ep4m7ZkOPqohfx5gVdc5qLUx
         YjowV0HsbEO5B6MhOV3d6gsv6Y1EdcC/1vZiXAG5/d940HBBwI5MKFgo99CUQZvJgiNj
         uIgw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736331154; x=1736935954;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=zXvyugoFvnrztoDgpMNB+n4/oYBCMLezGO47d4RFcqU=;
        b=fT2ZU612SwOGgdJnnlUsAZOPxf/YOhGgoPbhlX7JBySYGs7AUB+oib4/AXjXw/sh0B
         S4eBTWOEx78WKhNPUG5zgiY7/h4XIBG7LMks8QZ6vwQtri59K2HcgTuBoFyrpkIQfOG0
         +79Po3fYciI1ncPXr7c+JwQII2a6Vv1I6WFiW4sqynHXw8+85kwbGXgKS5UXldVEpiqb
         3Ztw2n8CbFFX15m9n9ANhl2vfcXa0AC5Ja2hHFceb7cM39DAeZPtqVD4eCeWgLMW7Ah8
         y9QH22zvCcOVBwwak4hurdbSGehP/h2jvSl6HOjq5eb+csUKYEaPSvV4TGlIA6nhp2FD
         6XXw==
X-Gm-Message-State: AOJu0Yzw8BqOsHIrtpP2K6sICKJCvqHJ0Mw7aCu0AIta7LUWoeKN3T+Y
	wIAj7+L/QvHryvCxHukadt1ASDd3aPjZzVjZ+gxI3mTjnnTRPjD8Ue9GxxtwdUj8JyhqhsMJ5p4
	=
X-Gm-Gg: ASbGncsRhztJNn3IZfA+J54KzYssMe3qXZ4stfsYEyEdiJGgQeRv2E9JJ4DPiTjpe4J
	o8kxnpwmpub6PnCZCL2eyySgmo7tIw6GR04agKmm0AMhkKJ5ieqSrPLrieub/dr5RS8gO7VBwNs
	hsfdQlGo6BwcJZSY2yLY0CItus911Pt7Zu6b0gJam1MFH4Gg1LHaRRDJJxJ9ByeJSgM8rN6IuD8
	eSpIJtQv/Kt6tbl2/7vAW57a21lqTQTvZO2SXhkKZhu+75UbwJvt+Eg7EbrRIbQx/5p7xen7BcD
	UQHkacizyLopZ21tYziwb6PGkXw361k1usM4sjIy3Q==
X-Google-Smtp-Source: AGHT+IGpICQp2GOtzcPok35p9XGlX2+7mlNFLT5fzZUxMkTA6mcxQ3KXOuSr1lc6ZaZkjJjN0i72NA==
X-Received: by 2002:a05:600c:198c:b0:435:306:e5dd with SMTP id 5b1f17b1804b1-436e26f47e0mr14638435e9.22.1736331153856;
        Wed, 08 Jan 2025 02:12:33 -0800 (PST)
Message-ID: <b401177a-0189-4dc0-adfd-5832e7ddfd35@suse.com>
Date: Wed, 8 Jan 2025 11:12:32 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v4 2/6] x86: re-work memset()
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
References: <14b65231-b83b-43fb-bbcf-dec5c07d285b@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <14b65231-b83b-43fb-bbcf-dec5c07d285b@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Move the function to its own assembly file. Having it in C just for the
entire body to be an asm() isn't really helpful. Then have two flavors:
A "basic" version using qword steps for the bulk of the operation, and an
ERMS version for modern hardware, to be substituted in via alternatives
patching.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
We may want to consider branching over the REP STOSQ as well, if the
number of qwords turns out to be zero.
We may also want to consider using non-REP STOS{L,W,B} for the tail.
---
v4: Use %r8 instead of %rsi in a few places.
v3: Re-base.

--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_INDIRECT_THUNK) += indirect
 obj-$(CONFIG_PV) += ioport_emulate.o
 obj-y += irq.o
 obj-$(CONFIG_KEXEC) += machine_kexec.o
+obj-y += memset.o
 obj-y += mm.o x86_64/mm.o
 obj-$(CONFIG_HVM) += monitor.o
 obj-y += mpparse.o
--- /dev/null
+++ b/xen/arch/x86/memset.S
@@ -0,0 +1,30 @@
+#include <asm/asm_defns.h>
+
+.macro memset
+        and     $7, %edx
+        shr     $3, %rcx
+        movzbl  %sil, %esi
+        mov     $0x0101010101010101, %rax
+        imul    %rsi, %rax
+        mov     %rdi, %r8
+        rep stosq
+        or      %edx, %ecx
+        jz      0f
+        rep stosb
+0:
+        mov     %r8, %rax
+        ret
+.endm
+
+.macro memset_erms
+        mov     %esi, %eax
+        mov     %rdi, %r8
+        rep stosb
+        mov     %r8, %rax
+        ret
+.endm
+
+FUNC(memset)
+        mov     %rdx, %rcx
+        ALTERNATIVE memset, memset_erms, X86_FEATURE_ERMS
+END(memset)
--- a/xen/arch/x86/string.c
+++ b/xen/arch/x86/string.c
@@ -22,19 +22,6 @@ void *(memcpy)(void *dest, const void *s
     return dest;
 }
 
-void *(memset)(void *s, int c, size_t n)
-{
-    long d0, d1;
-
-    asm volatile (
-        "rep stosb"
-        : "=&c" (d0), "=&D" (d1)
-        : "a" (c), "1" (s), "0" (n)
-        : "memory");
-
-    return s;
-}
-
 void *(memmove)(void *dest, const void *src, size_t n)
 {
     long d0, d1, d2;



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 10:13:01 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 10:13:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867084.1278506 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVT3b-000618-4E; Wed, 08 Jan 2025 10:12:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867084.1278506; Wed, 08 Jan 2025 10:12:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVT3b-00060z-1R; Wed, 08 Jan 2025 10:12:59 +0000
Received: by outflank-mailman (input) for mailman id 867084;
 Wed, 08 Jan 2025 10:12:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=svEr=UA=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVT3Z-00060Z-Ja
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 10:12:57 +0000
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com
 [2a00:1450:4864:20::32b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 20d6701e-cda9-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 11:12:55 +0100 (CET)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-43635796b48so4144095e9.0
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 02:12: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
 ffacd0b85a97d-38a1c89e2dfsm53176882f8f.74.2025.01.08.02.12.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 08 Jan 2025 02:12:54 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 20d6701e-cda9-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736331175; x=1736935975; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=SJd+n7gK2V+zAKy/YovEFCBG4RViNaVaa+G5JynvQ0Y=;
        b=SESG5Vs/5FZmznDi7R5LHCl3gImG7lF2Ag1GCvBE4uO2x9+qPwT0THxKRjQ6ZgI2Ln
         12kzoGzgF2en5gBeBmkTPrS8j0QLJTueM/PYbfPOS1njF7z82BXTI7DqBdCCT4DFDRER
         moISej7JbftmYfwfYWqcNwDL+jzdCadKPcDtYfsKOdkfG3Kkv5XmOHKgaSp05aIFjzzx
         Hg/5cA21yAjSsrCcnT6kbk6/IxfJZHb3sk9ZSkEIGFDbF9oJn36rongCgjRuvQff/IYm
         WGLWQWueaANDLHSp6f39pRShlIS4fU6Ii81T/nokVO0s3EusheFkPpzOoRLyyTCPGVBx
         MblQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736331175; x=1736935975;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=SJd+n7gK2V+zAKy/YovEFCBG4RViNaVaa+G5JynvQ0Y=;
        b=fQyRJWgyWabYRkUo14bPJhk+Kh5sz++VLbJwS7iRLu0/Ek+Wc5kWF+kAzsOzu3rCki
         F7SaZc2552ns1PdkoMbLg9ZUq2CAthYZSKWU3JEdtS/WjBPdL6MR/Tnv+B/RVQ37PCit
         ZWOA7pQMLT7D7oYeuScWq6MUKgqFxZsQ8/GsbJcb7zz6Oi+vazvraxALc+3nYfs9wZYe
         hZy35yGzKHXaesvSV9ABp4VtZKRjmULUph4mHaTBi9JpHPLBq0Vw3F8jPnhS1/kCudhw
         hqg9jrSECQRuwl4Fp2ADaMjthW5rN8vKSMUao8PCxMF4PQwiA+Uz8G3Uam9UyHdjU8F2
         bTNg==
X-Gm-Message-State: AOJu0YzSLZTbAJ6TR5PYmPAij/XoqnVT1l8r8xfe1k2efHzJCYzgRWda
	o+DS8A8u4HpkIC/HvrCk1aqT+jBLTXvRpm67XjSK0WFP14FEgjGqKpSJjL9UL316IcQqP+wQgJc
	=
X-Gm-Gg: ASbGncty0pdkf2VqvgC2HHHJ0fPQubkI9mYJgRdvxPPglniwNlPF/rdaJDGlmmuQ9Zm
	ACyvzHYwVdE+Dqe89WWycWOdFcR+Z8S2v2GmotLDP0zZldFzp5iOSDJBOh80l2Rr5iP0rY+/0po
	C8sGWQo4Br3hpK5yiP4P+JU7xyo880+nztGl8qLdXm4Cpr4Ic0R1eXHyg9w8qh5viVW275jqQEL
	YgrcDQ9iwOSitand9D96pWbE4ihATyXKXZr5hlH+A0w4DtpmxG1nMnCN7q4O306g/ZlHoMNs7qA
	Hx15yiodB0OSbxjj0+PGq418qVXpR52ag+BxfH0uLA==
X-Google-Smtp-Source: AGHT+IE8V4ACYrMlmEfpW17iXFZZTNXBv8g9V7pBQrCMzefmxeej1rCQP71NCdCYerf/ji2U05v0fQ==
X-Received: by 2002:a05:600c:3b94:b0:436:185f:dfae with SMTP id 5b1f17b1804b1-436dc1c213emr54693925e9.6.1736331175138;
        Wed, 08 Jan 2025 02:12:55 -0800 (PST)
Message-ID: <4dfc23f8-3fd5-4814-9d0d-5fbbe4c3e9c8@suse.com>
Date: Wed, 8 Jan 2025 11:12:53 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v4 3/6] x86: re-work memcpy()
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
References: <14b65231-b83b-43fb-bbcf-dec5c07d285b@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <14b65231-b83b-43fb-bbcf-dec5c07d285b@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Move the function to its own assembly file. Having it in C just for the
entire body to be an asm() isn't really helpful. Then have two flavors:
A "basic" version using qword steps for the bulk of the operation, and an
ERMS version for modern hardware, to be substituted in via alternatives
patching.

Alternatives patching, however, requires an extra precaution: It uses
memcpy() itself, and hence the function may patch itself. Luckily the
patched-in code only replaces the prolog of the original function. Make
sure this remains this way.

Additionally alternatives patching, while supposedly safe via enforcing
a control flow change when modifying already prefetched code, may not
really be. Afaict a request is pending to drop the first of the two
options in the SDM's "Handling Self- and Cross-Modifying Code" section.
Insert a serializing instruction there.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
We may want to consider branching over the REP MOVSQ as well, if the
number of qwords turns out to be zero.
We may also want to consider using non-REP MOVS{L,W,B} for the tail.

TBD: We may further need a workaround similar to Linux'es 8ca97812c3c8
     ("x86/mce: Work around an erratum on fast string copy
     instructions").
---
v4: Use CR2 write as serializing insn, and limit its use to boot time.
v3: Re-base.

--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_INDIRECT_THUNK) += indirect
 obj-$(CONFIG_PV) += ioport_emulate.o
 obj-y += irq.o
 obj-$(CONFIG_KEXEC) += machine_kexec.o
+obj-y += memcpy.o
 obj-y += memset.o
 obj-y += mm.o x86_64/mm.o
 obj-$(CONFIG_HVM) += monitor.o
--- a/xen/arch/x86/alternative.c
+++ b/xen/arch/x86/alternative.c
@@ -153,12 +153,16 @@ void init_or_livepatch add_nops(void *in
  * executing.
  *
  * "noinline" to cause control flow change and thus invalidate I$ and
- * cause refetch after modification.
+ * cause refetch after modification.  While the SDM continues to suggest this
+ * is sufficient, it may not be - issue a serializing insn afterwards as well,
+ * unless this is for live-patching.
  */
 static void init_or_livepatch noinline
 text_poke(void *addr, const void *opcode, size_t len)
 {
     memcpy(addr, opcode, len);
+    if ( system_state < SYS_STATE_active )
+        asm volatile ( "mov %%rax, %%cr2" ::: "memory" );
 }
 
 extern void *const __initdata_cf_clobber_start[];
--- /dev/null
+++ b/xen/arch/x86/memcpy.S
@@ -0,0 +1,20 @@
+#include <asm/asm_defns.h>
+
+FUNC(memcpy)
+        mov     %rdx, %rcx
+        mov     %rdi, %rax
+        /*
+         * We need to be careful here: memcpy() is involved in alternatives
+         * patching, so the code doing the actual copying (i.e. past setting
+         * up registers) may not be subject to patching (unless further
+         * precautions were taken).
+         */
+        ALTERNATIVE "and $7, %edx; shr $3, %rcx", \
+                    "rep movsb; ret", X86_FEATURE_ERMS
+        rep movsq
+        or      %edx, %ecx
+        jz      1f
+        rep movsb
+1:
+        ret
+END(memcpy)
--- a/xen/arch/x86/string.c
+++ b/xen/arch/x86/string.c
@@ -7,21 +7,6 @@
 
 #include <xen/lib.h>
 
-void *(memcpy)(void *dest, const void *src, size_t n)
-{
-    long d0, d1, d2;
-
-    asm volatile (
-        "   rep ; movs"__OS" ; "
-        "   mov %k4,%k3      ; "
-        "   rep ; movsb        "
-        : "=&c" (d0), "=&D" (d1), "=&S" (d2)
-        : "0" (n/BYTES_PER_LONG), "r" (n%BYTES_PER_LONG), "1" (dest), "2" (src)
-        : "memory" );
-
-    return dest;
-}
-
 void *(memmove)(void *dest, const void *src, size_t n)
 {
     long d0, d1, d2;



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 10:13:57 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 10:13:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867093.1278515 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVT4X-0006dC-E4; Wed, 08 Jan 2025 10:13:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867093.1278515; Wed, 08 Jan 2025 10:13:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVT4X-0006d5-AW; Wed, 08 Jan 2025 10:13:57 +0000
Received: by outflank-mailman (input) for mailman id 867093;
 Wed, 08 Jan 2025 10:13:55 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=svEr=UA=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVT4V-0006cy-Ko
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 10:13:55 +0000
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com
 [2a00:1450:4864:20::32d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 43f3fb00-cda9-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 11:13:54 +0100 (CET)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-4361c705434so119545695e9.3
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 02:13: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
 ffacd0b85a97d-38a7f1c26a6sm3900751f8f.53.2025.01.08.02.13.53
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 08 Jan 2025 02:13:53 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 43f3fb00-cda9-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736331234; x=1736936034; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Bo1b/k71KJVmsVTKGv+xBBoI5XLp0eOf8O7yEx73nPg=;
        b=a/v8XjZVeeOopyxRPQd15eA3furRxb+N610aBOMr5VahhQWVAD22+ZTjC4lQQi6e71
         AwyWNiIl49fMddIgT2f/Op7lZDY2m4AwKgRvKNLuw98STdpNA7/hy7nVQit8sCvz4DoH
         z2BFLNL9hl9xxsf1CniPNbqOKo7L+n/P13gtmIOTMi/f6ivVIgV7ntJFchGAEXyDMsWz
         7yraZ4kN8Yd2rKRf4Lek0TXMDZikytkq2MeDwxL0AkGJJkfcdexrkIq9P+yL2A/3dzSE
         1Ha9JpcvXzGzlUZLbEcSFIddw7xr/RZubgqgEtCQRmjJrBuWxhXLdSrm6I7Zh7YCl4q2
         KB5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736331234; x=1736936034;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=Bo1b/k71KJVmsVTKGv+xBBoI5XLp0eOf8O7yEx73nPg=;
        b=VHBTp8MgbeNvqawpLkFrXYa2YT7yV32rl4eSeRlB8NzwlLZ343aS1k1sKtFkGsOnmA
         jlklm5fH/H9IJvR+nSshVEwhw39KpkJ/eyqa1c/OqLcXP4PHvWQBOPES7tkwzvq0xj09
         dooMUypbUgVMJS4kTKkoXhzk49o9ITZ1nhSLFp0v9jafPQE1mi1wDJbpXgegdpb6nl7Q
         TgUObU4BqiN0xvKJ2QKLZB5TogMYJ5EFsRt0o3hjB7flqSboRvbSe4meNHGNxxHLKFKp
         a6mAtbuLy7U1Lc5AdIREDGzhKVMNAyKkiz6JHHIDJcIMSTgiP7pnqE+PYqG0q/y13eNy
         oO1g==
X-Gm-Message-State: AOJu0YzVFV5Aw7tWlom+2GjvxileYNBcK/O5VkVRBFux/gQK85yNC5nt
	s9cxaFb+gbps5ak7UctTEBNwZikooUjBChbb0Ud5Vs6RIv3BlVxVho0zRU3bg8RNqIOPgME93Sw
	=
X-Gm-Gg: ASbGncvMmp66ng5VrNb2o0kA+wpH3dadEyTsNW69zDhobk6Gby26pZCYPkHZHaXwp85
	QFwLl+bQ4U5NdHr7iqyEOSGVVVIR1svokchlF58ebdQccFxg5LPi/lPLX719Iomgibc2bfq0qdM
	kFJ0ryfDx1BXKd6JoT+/1/bDrwlc+LG9GvK631HKlil0bOIgn1uqH9kCHHmrzZ9882SpbwypQnN
	JC07pxVkYKVLWgKROTpBVz9ZnUAYdjAWp2ts/z2wjMnpjRzf+8adDZs2iYqacxam1Wbd9H8/647
	EqUivfzNHmX+IHRtOTzQkRbGb4Mn3tJ1nJl/r7phMg==
X-Google-Smtp-Source: AGHT+IEfbeIpnncbii9/ulkoYjr5/qnJQ+KeF5tDhIvUc40vwREXBgMLneFJI50PQ4zdbR4RW2eg2A==
X-Received: by 2002:a5d:648a:0:b0:38a:4b8a:e47d with SMTP id ffacd0b85a97d-38a8730ac0emr1557290f8f.26.1736331234049;
        Wed, 08 Jan 2025 02:13:54 -0800 (PST)
Message-ID: <8f3e1256-6ec2-410b-94b7-23295f569f9f@suse.com>
Date: Wed, 8 Jan 2025 11:13:52 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v4 5/6] x86: introduce "hot" and "cold" page clearing
 functions
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
References: <14b65231-b83b-43fb-bbcf-dec5c07d285b@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <14b65231-b83b-43fb-bbcf-dec5c07d285b@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

The present clear_page_sse2() is useful in case a page isn't going to
get touched again soon, or if we want to limit churn on the caches.
Amend it by alternatively using CLZERO, which has been found to be quite
a bit faster on Zen2 hardware at least. Note that to use CLZERO, we need
to know the cache line size, and hence a feature dependency on CLFLUSH
gets introduced.

For cases where latency is the most important aspect, or when it is
expected that sufficiently large parts of a page will get accessed again
soon after the clearing, introduce a "hot" alternative. Again use
alternatives patching to select between a "legacy" and an ERMS variant.

Don't switch any callers just yet - this will be the subject of
subsequent changes.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v3: Re-base.
v2: New.
---
Note: Ankur indicates that for ~L3-size or larger regions MOVNT/CLZERO
      is better even latency-wise.

--- a/xen/arch/x86/clear_page.S
+++ b/xen/arch/x86/clear_page.S
@@ -1,9 +1,9 @@
         .file __FILE__
 
-#include <xen/linkage.h>
-#include <asm/page.h>
+#include <xen/page-size.h>
+#include <asm/asm_defns.h>
 
-FUNC(clear_page_sse2)
+        .macro clear_page_sse2
         mov     $PAGE_SIZE/32, %ecx
         xor     %eax,%eax
 
@@ -17,4 +17,43 @@ FUNC(clear_page_sse2)
 
         sfence
         ret
-END(clear_page_sse2)
+        .endm
+
+        .macro clear_page_clzero
+        mov     %rdi, %rax
+        mov     $PAGE_SIZE/64, %ecx
+        .globl clear_page_clzero_post_count
+clear_page_clzero_post_count:
+
+0:      clzero
+        sub     $-64, %rax
+        .globl clear_page_clzero_post_neg_size
+clear_page_clzero_post_neg_size:
+        sub     $1, %ecx
+        jnz     0b
+
+        sfence
+        ret
+        .endm
+
+FUNC(clear_page_cold)
+        ALTERNATIVE clear_page_sse2, clear_page_clzero, X86_FEATURE_CLZERO
+END(clear_page_cold)
+
+        .macro clear_page_stosb
+        mov     $PAGE_SIZE, %ecx
+        xor     %eax,%eax
+        rep stosb
+        ret
+        .endm
+
+        .macro clear_page_stosq
+        mov     $PAGE_SIZE/8, %ecx
+        xor     %eax, %eax
+        rep stosq
+        ret
+        .endm
+
+FUNC(clear_page_hot)
+        ALTERNATIVE clear_page_stosq, clear_page_stosb, X86_FEATURE_ERMS
+END(clear_page_hot)
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -58,6 +58,9 @@ DEFINE_PER_CPU(bool, full_gdt_loaded);
 
 DEFINE_PER_CPU(uint32_t, pkrs);
 
+extern uint32_t clear_page_clzero_post_count[];
+extern int8_t clear_page_clzero_post_neg_size[];
+
 void __init setup_clear_cpu_cap(unsigned int cap)
 {
 	const uint32_t *dfs;
@@ -355,8 +358,38 @@ void __init early_cpu_init(bool verbose)
 
 	edx &= ~cleared_caps[FEATURESET_1d];
 	ecx &= ~cleared_caps[FEATURESET_1c];
-	if (edx & cpufeat_mask(X86_FEATURE_CLFLUSH))
-		c->x86_cache_alignment = ((ebx >> 8) & 0xff) * 8;
+	if (edx & cpufeat_mask(X86_FEATURE_CLFLUSH)) {
+		unsigned int size = ((ebx >> 8) & 0xff) * 8;
+
+		c->x86_cache_alignment = size;
+
+		/*
+		 * Patch in parameters of clear_page_cold()'s CLZERO
+		 * alternative. Note that for now we cap this at 128 bytes.
+		 * Larger cache line sizes would still be dealt with
+		 * correctly, but would cause redundant work done.
+		 */
+		if (size > 128)
+			size = 128;
+		if (size && !(size & (size - 1))) {
+			/*
+			 * Need to play some games to keep the compiler from
+			 * recognizing the negative array index as being out
+			 * of bounds. The labels in assembler code really are
+			 * _after_ the locations to be patched, so the
+			 * negative index is intentional.
+			 */
+			uint32_t *pcount = clear_page_clzero_post_count;
+			int8_t *neg_size = clear_page_clzero_post_neg_size;
+
+			OPTIMIZER_HIDE_VAR(pcount);
+			OPTIMIZER_HIDE_VAR(neg_size);
+			pcount[-1] = PAGE_SIZE / size;
+			neg_size[-1] = -size;
+		}
+		else
+			setup_clear_cpu_cap(X86_FEATURE_CLZERO);
+	}
 	/* Leaf 0x1 capabilities filled in early for Xen. */
 	c->x86_capability[FEATURESET_1d] = edx;
 	c->x86_capability[FEATURESET_1c] = ecx;
--- a/xen/arch/x86/include/asm/asm-defns.h
+++ b/xen/arch/x86/include/asm/asm-defns.h
@@ -20,6 +20,10 @@
     .byte 0x0f, 0x01, 0xdd
 .endm
 
+.macro clzero
+    .byte 0x0f, 0x01, 0xfc
+.endm
+
 /*
  * Call a noreturn function.  This could be JMP, but CALL results in a more
  * helpful backtrace.  BUG is to catch functions which do decide to return...
--- a/xen/arch/x86/include/asm/page.h
+++ b/xen/arch/x86/include/asm/page.h
@@ -219,10 +219,11 @@ typedef struct { u64 pfn; } pagetable_t;
 #define pagetable_from_paddr(p) pagetable_from_pfn((p)>>PAGE_SHIFT)
 #define pagetable_null()        pagetable_from_pfn(0)
 
-void clear_page_sse2(void *pg);
+void clear_page_hot(void *pg);
+void clear_page_cold(void *pg);
 void copy_page_sse2(void *to, const void *from);
 
-#define clear_page(_p)      clear_page_sse2(_p)
+#define clear_page(_p)      clear_page_cold(_p)
 #define copy_page(_t, _f)   copy_page_sse2(_t, _f)
 
 /* Convert between Xen-heap virtual addresses and machine addresses. */
--- a/xen/tools/gen-cpuid.py
+++ b/xen/tools/gen-cpuid.py
@@ -212,6 +212,10 @@ def crunch_numbers(state):
         # the first place.
         APIC: [X2APIC, TSC_DEADLINE, EXTAPIC],
 
+        # The CLZERO insn requires a means to determine the cache line size,
+        # which is tied to the CLFLUSH insn.
+        CLFLUSH: [CLZERO],
+
         # AMD built MMXExtentions and 3DNow as extentions to MMX.
         MMX: [MMXEXT, _3DNOW],
 



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 10:15:16 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 10:15:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867100.1278527 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVT5n-0007Ac-PJ; Wed, 08 Jan 2025 10:15:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867100.1278527; Wed, 08 Jan 2025 10: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 <xen-devel-bounces@lists.xenproject.org>)
	id 1tVT5n-0007AV-Ko; Wed, 08 Jan 2025 10:15:15 +0000
Received: by outflank-mailman (input) for mailman id 867100;
 Wed, 08 Jan 2025 10:15: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
 <SRS0=AYhQ=UA=bounce.vates.tech=bounce-md_30504962.677e502e.v1-d03c739cf22d4a4c8b88768a65d2dbc0@srs-se1.protection.inumbo.net>)
 id 1tVT5m-0007AP-Qs
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 10:15:14 +0000
Received: from mail134-8.atl141.mandrillapp.com
 (mail134-8.atl141.mandrillapp.com [198.2.134.8])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 71f3d10c-cda9-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 11:15:12 +0100 (CET)
Received: from pmta10.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail134-8.atl141.mandrillapp.com (Mailchimp) with ESMTP id
 4YSkLk6Hbhz3sNCr9
 for <xen-devel@lists.xenproject.org>; Wed,  8 Jan 2025 10:15:10 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 d03c739cf22d4a4c8b88768a65d2dbc0; Wed, 08 Jan 2025 10:15:10 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 71f3d10c-cda9-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1736331310; x=1736591810;
	bh=znnJs+48Fw1s+VLjr03QiZ20QYHnVQ/14a/O1GbNvtM=;
	h=From:Subject:To:Cc:Message-Id:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=glJ1uKXwgGTF5ZfxJFFkH4Q7lOJvwcRw00DQ6ovIH2psy/jZV+rpKMCl0x7iYinWL
	 pmIPAtH0JKpyleiSPoPFQWKxQXRfuvZ8OTGLsHAm271nLKLSsdGV8q+NiuXALqaW3V
	 p/fRUo06qeaM66dTy6iqxFSHcWZ7EhQFwTVvgp/bzompRWXP2etz2cd4FJCt2PkCND
	 WHxrwIbhlhxCe4Zq3iSTEuaqIhdZXn5i9m7PNtUxZzjXbY/33ekL5a/DWjwsRrCLpL
	 5j7bBNkndT/6brXb11KdB9pvGLNvthqyyv5mpvCx9zdZ1lgFhbtaylYObjeR12jpss
	 z1+eNJ2b657tg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1736331310; x=1736591810; i=anthony.perard@vates.tech;
	bh=znnJs+48Fw1s+VLjr03QiZ20QYHnVQ/14a/O1GbNvtM=;
	h=From:Subject:To:Cc:Message-Id:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=w1BFXvweXwHygsBKA2wESXB3inwpdIxeLjTq2tI+uscWw5y5G4HRlOJzy8xWy+VDU
	 LvHLS6sTQe1YEHwE5a+gY/oKW9eQMs+5pg8/KehqxgSZsTqWrXjFk+o9zuy+t43Jbb
	 TBkXZsb93bS9bfg/WZSQm5ByJbFoD/4XLarTNh8qdQCKnVdAeRuhYfZoDJ8SUe5HJJ
	 MIOY5sHILLj7eVNJovT+cgV4ncpAXaLhb8yKgCBRe5i/yZgwdT3SUe1mASMsmVDV3l
	 6SrikrdHUhG/DRFTshdhEJmHHQKvc6Q3SkrJ+q34hpRlAXNd29hOQ+aiqq8kprvpS4
	 PreWcYDa4VAEg==
From: "Anthony PERARD" <anthony.perard@vates.tech>
Subject: =?utf-8?Q?Re:=20[PATCH=20v2=201/2]=20tools/libs:=20remove=20dead=20code?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1736331309764
To: "Ariel Otilibili" <Ariel.Otilibili-Anieli@eurecom.fr>
Cc: xen-devel@lists.xenproject.org, "Juergen Gross" <jgross@suse.com>, "Daniel P. Smith" <dpsmith@apertussolutions.com>
Message-Id: <Z35QLcQAnbUqRBIm@l14>
References: <20241220165837.937976-1-Ariel.Otilibili-Anieli@eurecom.fr> <20241224191529.138119-1-Ariel.Otilibili-Anieli@eurecom.fr> <20241224191529.138119-2-Ariel.Otilibili-Anieli@eurecom.fr>
In-Reply-To: <20241224191529.138119-2-Ariel.Otilibili-Anieli@eurecom.fr>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.d03c739cf22d4a4c8b88768a65d2dbc0?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250108:md
Date: Wed, 08 Jan 2025 10:15:10 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Hi Ariel,

On Tue, Dec 24, 2024 at 08:13:54PM +0100, Ariel Otilibili wrote:
> Default switch cases skip these steps; these instructions are never reached.

The "default" case might skip these statements, but the intention behind
those statements is to make sure that every other cases also skip these,
with "return" or "goto".

There's a comment on each of those statements, so it should be clear
enough that those are not expected to be executed. So I'd rather keep
those two statements.

But thanks.

> Coverity-IDs: 1056148, 1056149
> Fixes: 0a69ea908d ("libxl: ao: convert libxl__spawn_*")
> Fixes: 643b106b40 ("libxl: do not use tap disk backend other than for raw and vhd")
> Signed-off-by: Ariel Otilibili <Ariel.Otilibili-Anieli@eurecom.fr>
> ---
> diff --git a/tools/libs/light/libxl_create.c b/tools/libs/light/libxl_create.c
> index e03599ea99..d0271bef7e 100644
> --- a/tools/libs/light/libxl_create.c
> +++ b/tools/libs/light/libxl_create.c
> @@ -1890,7 +1890,6 @@ static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *multidev,
>          ret = ERROR_INVAL;
>          goto error_out;
>      }
> -    abort(); /* not reached */
>  
>   error_out:
>      assert(ret);
> diff --git a/tools/libs/light/libxl_device.c b/tools/libs/light/libxl_device.c
> index 4faa5fa3bd..96046803e1 100644
> --- a/tools/libs/light/libxl_device.c
> +++ b/tools/libs/light/libxl_device.c
> @@ -392,7 +392,6 @@ static int disk_try_backend(disk_try_backend_args *a,
>          return 0;
>  
>      }
> -    abort(); /* notreached */
>  
>   bad_format:
>      LOG(DEBUG, "Disk vdev=%s, backend %s unsuitable due to format %s",

Cheers,

-- 

Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


From xen-devel-bounces@lists.xenproject.org Wed Jan 08 10:15:42 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 10:15:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867107.1278535 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVT6E-0007fl-2O; Wed, 08 Jan 2025 10:15:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867107.1278535; Wed, 08 Jan 2025 10:15:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVT6D-0007fe-Vz; Wed, 08 Jan 2025 10:15:41 +0000
Received: by outflank-mailman (input) for mailman id 867107;
 Wed, 08 Jan 2025 10:15:41 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=svEr=UA=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVT6D-0007AP-AE
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 10:15:41 +0000
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com
 [2a00:1450:4864:20::329])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 827ace7d-cda9-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 11:15:39 +0100 (CET)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-436249df846so114545285e9.3
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 02:15:39 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436e2e22c6dsm15489755e9.41.2025.01.08.02.15.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 08 Jan 2025 02:15:38 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 827ace7d-cda9-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736331339; x=1736936139; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=P1MIbiccam+0w1GrD/h7pQdOgwuOnzTZkVsUXNrVWs0=;
        b=Sz3trCHFmI23NmQD04ypMOJpFXitG1AqMrQSXU+h/y6HC93nRzx0uWR/fg0LQi2BhY
         iuN0riM4FrkRdqJM+hZ3XEN5PjHyw2XoiNBkgJ2OKK38b+ptKzsMNhIRheceQOVAi13E
         9Qs/AvHYJnn6tIiEGN4oguuCKi3xaViZ1vW423wxN9rMCME5Ma/4wHXtfoxcXtmFVD2T
         Fyq/+6FJ5z0s3rjsC1Pe8kHScV2azQnav6ulNSp3xdC5+0rCgDI8AE3ke62oEtcSUeI4
         VF2wiD2Qgste4ecc3Ggii3jOZekhWXArv1aW4EZR+Ekshvg7ddMIYy3oEAKOUtoallQX
         3eMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736331339; x=1736936139;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=P1MIbiccam+0w1GrD/h7pQdOgwuOnzTZkVsUXNrVWs0=;
        b=STBgvjpo5qlS5d42zuIKBchGtgrpp3UAFnP0asDkrAYHAoudrQoytBLNPuTzLFIHcJ
         ZHQSw/tcBxC5VQLumMRQJHdnzlxKgFDTOvLSTvMPebMypRbraIz/FVbOlX4QaHcHd6jz
         xwa+slsYXxHbwoFWJeBaXA5EODe547j8IvTmzSSOyDNUNVsnBvtoLPaBK/ojna9BOupG
         5D9SV0GwPHqCnKc6DzW0jW3joLlzeBT17vdK1v9ycueyitvax/d5IoVzWszX2OqfM15d
         i+1EHD47e6w1LwNa8LlmmhF/Z9x3OKzH9MZ99v1SlI6Q0ni1ubcsekTOpHbmzx8sH0yv
         2zKQ==
X-Gm-Message-State: AOJu0YzUAICLGLochZi8ysUstyJ7ho51GX4jIMdgz9YXVACfCe21y7sw
	/CXoR9VHEZOICbdpNlOap2NRo7Xu4i659hBa4hpH1BIwwaFwnWCyGH6xA/KDNT2V3YhsJL+yE48
	=
X-Gm-Gg: ASbGncvw0WS/03i95F7AStR1BtqM/4cNbi5YxzEno7OaF+YlrXQ/LRsORy4mvTvOWFl
	sp65gXuBt65aqF7935CbZuP65BGnuBLa4Xv82KaRbPZAVyhDpwHYM5u8MHUaNT8eOruGxB6xtUv
	OE+k96g+VEc6mksS77cEJOuIEbDpbLueRCOStf0cbHwY+sdHLhEK8J2GisI6IBR1r29jWUVrVRG
	PxYpVSPG2vTfEsYshN+/HcGt7Mlu6AM8xsqPPqDpoC5556mV31YlNcUCELs3Stn6USxwfg0+lr6
	pM6Czg22LPD3ojk6QaG7G2bnbNlDdCugtrNnPY3HrQ==
X-Google-Smtp-Source: AGHT+IFeve6rmgNKMBreSEhP0nNBBk0KZo5lJVNQCRQQxaQPU6Oh4TiQR9KKQ1AY3LJtNX9D29QQvg==
X-Received: by 2002:a05:600c:5491:b0:434:f7f0:1880 with SMTP id 5b1f17b1804b1-436e26ec32amr14641945e9.32.1736331338903;
        Wed, 08 Jan 2025 02:15:38 -0800 (PST)
Message-ID: <4afef39b-ff01-40f8-9bf1-68202f3a8b60@suse.com>
Date: Wed, 8 Jan 2025 11:15:37 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v4 6/6] mm: allow page scrubbing routine(s) to be arch
 controlled
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Shawn Anastasio <sanastasio@raptorengineering.com>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>, Julien Grall
 <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>,
 Volodymyr Babchuk <volodymyr_babchuk@epam.com>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 Anthony PERARD <anthony.perard@vates.tech>
References: <14b65231-b83b-43fb-bbcf-dec5c07d285b@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <14b65231-b83b-43fb-bbcf-dec5c07d285b@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Especially when dealing with large amounts of memory, memset() may not
be very efficient; this can be bad enough that even for debug builds a
custom function is warranted. We additionally want to distinguish "hot"
and "cold" cases (with, as initial heuristic, "hot" being for any
allocations a domain does for itself, assuming that in all other cases
the page wouldn't be accessed [again] soon). The goal is for accesses
of "cold" pages to not disturb caches (albeit finding a good balance
between this and the higher latency looks to be difficult).

Keep the default fallback to clear_page_*() in common code; this may
want to be revisited down the road.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Julien Grall <jgrall@amazon.com>
---
v4: Re-base.
v3: Re-base.
v2: New.
---
The choice between hot and cold in scrub_one_page()'s callers is
certainly up for discussion / improvement.

--- a/xen/arch/arm/include/asm/page.h
+++ b/xen/arch/arm/include/asm/page.h
@@ -144,6 +144,12 @@ extern size_t dcache_line_bytes;
 
 #define copy_page(dp, sp) memcpy(dp, sp, PAGE_SIZE)
 
+#define clear_page_hot  clear_page
+#define clear_page_cold clear_page
+
+#define scrub_page_hot(page) memset(page, SCRUB_BYTE_PATTERN, PAGE_SIZE)
+#define scrub_page_cold      scrub_page_hot
+
 static inline size_t read_dcache_line_bytes(void)
 {
     register_t ctr;
--- a/xen/arch/ppc/include/asm/page.h
+++ b/xen/arch/ppc/include/asm/page.h
@@ -190,6 +190,12 @@ static inline void invalidate_icache(voi
 #define clear_page(page) memset(page, 0, PAGE_SIZE)
 #define copy_page(dp, sp) memcpy(dp, sp, PAGE_SIZE)
 
+#define clear_page_hot  clear_page
+#define clear_page_cold clear_page
+
+#define scrub_page_hot(page) memset(page, SCRUB_BYTE_PATTERN, PAGE_SIZE)
+#define scrub_page_cold      scrub_page_hot
+
 /* TODO: Flush the dcache for an entire page. */
 static inline void flush_page_to_ram(unsigned long mfn, bool sync_icache)
 {
--- a/xen/arch/riscv/include/asm/page.h
+++ b/xen/arch/riscv/include/asm/page.h
@@ -177,6 +177,12 @@ static inline void invalidate_icache(voi
 #define clear_page(page) memset((void *)(page), 0, PAGE_SIZE)
 #define copy_page(dp, sp) memcpy(dp, sp, PAGE_SIZE)
 
+#define clear_page_hot  clear_page
+#define clear_page_cold clear_page
+
+#define scrub_page_hot(page) memset(page, SCRUB_BYTE_PATTERN, PAGE_SIZE)
+#define scrub_page_cold      scrub_page_hot
+
 static inline void flush_page_to_ram(unsigned long mfn, bool sync_icache)
 {
     const void *v = map_domain_page(_mfn(mfn));
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -59,6 +59,7 @@ obj-y += pci.o
 obj-y += physdev.o
 obj-$(CONFIG_COMPAT) += x86_64/physdev.o
 obj-$(CONFIG_X86_PSR) += psr.o
+obj-bin-$(CONFIG_DEBUG) += scrub_page.o
 obj-y += setup.o
 obj-y += shutdown.o
 obj-y += smp.o
--- a/xen/arch/x86/include/asm/page.h
+++ b/xen/arch/x86/include/asm/page.h
@@ -226,6 +226,11 @@ void copy_page_sse2(void *to, const void
 #define clear_page(_p)      clear_page_cold(_p)
 #define copy_page(_t, _f)   copy_page_sse2(_t, _f)
 
+#ifdef CONFIG_DEBUG
+void scrub_page_hot(void *);
+void scrub_page_cold(void *);
+#endif
+
 /* Convert between Xen-heap virtual addresses and machine addresses. */
 #define __pa(x)             (virt_to_maddr(x))
 #define __va(x)             (maddr_to_virt(x))
--- /dev/null
+++ b/xen/arch/x86/scrub_page.S
@@ -0,0 +1,39 @@
+        .file __FILE__
+
+#include <asm/asm_defns.h>
+#include <xen/page-size.h>
+#include <xen/scrub.h>
+
+FUNC(scrub_page_cold)
+        mov     $PAGE_SIZE/32, %ecx
+        mov     $SCRUB_PATTERN, %rax
+
+0:      movnti  %rax,   (%rdi)
+        movnti  %rax,  8(%rdi)
+        movnti  %rax, 16(%rdi)
+        movnti  %rax, 24(%rdi)
+        add     $32, %rdi
+        sub     $1, %ecx
+        jnz     0b
+
+        sfence
+        ret
+END(scrub_page_cold)
+
+        .macro scrub_page_stosb
+        mov     $PAGE_SIZE, %ecx
+        mov     $SCRUB_BYTE_PATTERN, %eax
+        rep stosb
+        ret
+        .endm
+
+        .macro scrub_page_stosq
+        mov     $PAGE_SIZE/8, %ecx
+        mov     $SCRUB_PATTERN, %rax
+        rep stosq
+        ret
+        .endm
+
+FUNC(scrub_page_hot)
+        ALTERNATIVE scrub_page_stosq, scrub_page_stosb, X86_FEATURE_ERMS
+END(scrub_page_hot)
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -135,6 +135,7 @@
 #include <xen/pfn.h>
 #include <xen/types.h>
 #include <xen/sched.h>
+#include <xen/scrub.h>
 #include <xen/sections.h>
 #include <xen/softirq.h>
 #include <xen/spinlock.h>
@@ -780,27 +781,31 @@ static void page_list_add_scrub(struct p
         page_list_add(pg, &heap(node, zone, order));
 }
 
-/* SCRUB_PATTERN needs to be a repeating series of bytes. */
-#ifndef NDEBUG
-#define SCRUB_PATTERN        0xc2c2c2c2c2c2c2c2ULL
-#else
-#define SCRUB_PATTERN        0ULL
+/*
+ * While in debug builds we want callers to avoid relying on allocations
+ * returning zeroed pages, for a production build, clear_page_*() is the
+ * fastest way to scrub.
+ */
+#ifndef CONFIG_DEBUG
+# undef  scrub_page_hot
+# define scrub_page_hot clear_page_hot
+# undef  scrub_page_cold
+# define scrub_page_cold clear_page_cold
 #endif
-#define SCRUB_BYTE_PATTERN   (SCRUB_PATTERN & 0xff)
 
-static void scrub_one_page(const struct page_info *pg)
+static void scrub_one_page(const struct page_info *pg, bool cold)
 {
+    void *ptr;
+
     if ( unlikely(pg->count_info & PGC_broken) )
         return;
 
-#ifndef NDEBUG
-    /* Avoid callers relying on allocations returning zeroed pages. */
-    unmap_domain_page(memset(__map_domain_page(pg),
-                             SCRUB_BYTE_PATTERN, PAGE_SIZE));
-#else
-    /* For a production build, clear_page() is the fastest way to scrub. */
-    clear_domain_page(_mfn(page_to_mfn(pg)));
-#endif
+    ptr = __map_domain_page(pg);
+    if ( cold )
+        scrub_page_cold(ptr);
+    else
+        scrub_page_hot(ptr);
+    unmap_domain_page(ptr);
 }
 
 static void poison_one_page(struct page_info *pg)
@@ -1080,12 +1085,14 @@ static struct page_info *alloc_heap_page
     if ( first_dirty != INVALID_DIRTY_IDX ||
          (scrub_debug && !(memflags & MEMF_no_scrub)) )
     {
+        bool cold = d && d != current->domain;
+
         for ( i = 0; i < (1U << order); i++ )
         {
             if ( test_and_clear_bit(_PGC_need_scrub, &pg[i].count_info) )
             {
                 if ( !(memflags & MEMF_no_scrub) )
-                    scrub_one_page(&pg[i]);
+                    scrub_one_page(&pg[i], cold);
 
                 dirty_cnt++;
             }
@@ -1350,7 +1357,7 @@ bool scrub_free_pages(void)
                 {
                     if ( test_bit(_PGC_need_scrub, &pg[i].count_info) )
                     {
-                        scrub_one_page(&pg[i]);
+                        scrub_one_page(&pg[i], true);
                         /*
                          * We can modify count_info without holding heap
                          * lock since we effectively locked this buddy by
@@ -2072,7 +2079,7 @@ static struct page_info *alloc_color_hea
     if ( !(memflags & MEMF_no_scrub) )
     {
         if ( need_scrub )
-            scrub_one_page(pg);
+            scrub_one_page(pg, d != current->domain);
         else
             check_one_page(pg);
     }
@@ -2223,7 +2230,7 @@ static void __init cf_check smp_scrub_he
         if ( !mfn_valid(_mfn(mfn)) || !page_state_is(pg, free) )
             continue;
 
-        scrub_one_page(pg);
+        scrub_one_page(pg, true);
     }
 }
 
@@ -2928,7 +2935,7 @@ void unprepare_staticmem_pages(struct pa
         if ( need_scrub )
         {
             /* TODO: asynchronous scrubbing for pages of static memory. */
-            scrub_one_page(pg);
+            scrub_one_page(pg, true);
         }
 
         pg[i].count_info |= PGC_static;
--- /dev/null
+++ b/xen/include/xen/scrub.h
@@ -0,0 +1,24 @@
+#ifndef __XEN_SCRUB_H__
+#define __XEN_SCRUB_H__
+
+#include <xen/const.h>
+
+/* SCRUB_PATTERN needs to be a repeating series of bytes. */
+#ifdef CONFIG_DEBUG
+# define SCRUB_PATTERN       _AC(0xc2c2c2c2c2c2c2c2,ULL)
+#else
+# define SCRUB_PATTERN       _AC(0,ULL)
+#endif
+#define SCRUB_BYTE_PATTERN   (SCRUB_PATTERN & 0xff)
+
+#endif /* __XEN_SCRUB_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 10:22:21 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 10:22:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867123.1278545 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVTCZ-0001LM-NV; Wed, 08 Jan 2025 10:22:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867123.1278545; Wed, 08 Jan 2025 10:22:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVTCZ-0001LF-Ku; Wed, 08 Jan 2025 10:22:15 +0000
Received: by outflank-mailman (input) for mailman id 867123;
 Wed, 08 Jan 2025 10:22: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 <SRS0=svEr=UA=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVT3x-0005HN-Gg
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 10:13:21 +0000
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com
 [2a00:1450:4864:20::32b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2fe0419d-cda9-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 11:13:20 +0100 (CET)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-4361b6f9faeso4076785e9.1
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 02:13:20 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c8acafesm52401179f8f.98.2025.01.08.02.13.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 08 Jan 2025 02:13:20 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2fe0419d-cda9-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736331200; x=1736936000; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Ik+kdwvsn5sI13Sqvs0LoMAnkH/bBuVd5/sAq0CDmGU=;
        b=OzfZ1q1uDOWOLVe/M1r/qLXLQSICiOUO67YSoKNGO36gkSFIhFr7YA9y+tdK2Gyhz7
         QpRy4ASsLT/Kp28PNd4ZcrSC+QCF/Y7QvXV17yk6tp5KF9Vc7xMReEde+iejz76Sr+4n
         xzPHvY5UCt29ZrRPQsJ7vQ9Vmoo1qeDy4dUOgniwl/U3+IQJRmSbJD/xSoEUEc2/31T9
         JpiZHf/nNil3UB7ARVDPpjqufVvqcf/em5DWdjBwgCVtd9zMCOOWpK0tdYfS/wS5YSNq
         vDzVekApxhuU7hgnYLZGJ7DQf/ZV2PzVDBDfYBGc9q2a5fwo6aLqHUe93aT/ESTUN1+z
         WcHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736331200; x=1736936000;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=Ik+kdwvsn5sI13Sqvs0LoMAnkH/bBuVd5/sAq0CDmGU=;
        b=KrgBq70RBsxaH8CUF62oqBIHWtFi+5BogzezHNzG5Si1O0qX930flMEQO9gPp8F0V5
         zBZnm5e54wcAIT9tHpumxguy7afudWDMvZ2AlWV38mvp12saMqwzlIGapxcVZXe9nWjb
         XQXTPoQvGU6wIMylfmXqeZ5eBWL9mLZcokJJc38ay8D9lUE0BG/HtYq0Cznv5WP6ONgi
         VWZKQD/ABcZgbUKLWhuOWypV+f81ni2wbdtaDIyVkOwLN90O56atgigSXlAJ3x9CfCBb
         G6zxU1n0I5LrMO71MXrsHHD+vvgTw4TNseFxaib+5jZsHdR3HCHjaxulGQQRlK0HVY0b
         AmCw==
X-Gm-Message-State: AOJu0YxjkpiAlmnTw+R6huD/j/b9D7kSdw4P9wDBBv3imXjtsQWlKgZE
	ftL0CE1hODnsLuW3piyquF79JY7XHfcNHCLlJRI3gwy+0faWNkkYtU6gjbiut2Yieh3rPVGaWWE
	=
X-Gm-Gg: ASbGncvBOhvpVuH/7h6EYruLTiFgKkzYgckSGecReO4ZlbebwvbgtyPwQqsxnUGXLpz
	7b89xalvLiPAVS9noHxahiUR/3CvmRlmF+9pB7KMcbXI4r2hmc1qnMjY1P9RHNLYm1FLTw9YIkd
	pDyj/ovuCMtc/yacv/IXKjO9ako8aKLT9z8UjFam0YijCVybaAd/NAFabHLEgHfvxgTF3bYaq6i
	EDggpiLOhFid3rG0t6m3cSvECKCrn/mWGg1LeDPuXSNw1Kd8ZzBUpaT9P18VHikcRDumn+KfHtI
	2dHSgJ+mjKbBLNHdlrld4lI2kvxXCLseFlFDJCfJlw==
X-Google-Smtp-Source: AGHT+IHaGFaaqLP4jo8cZOgpMUC9M5m87pxwlFQdAZx7tezjS6+Wa1QPSoUExOwxvVruxJ1a4gdKsA==
X-Received: by 2002:a05:600c:1d0d:b0:434:fe3c:c662 with SMTP id 5b1f17b1804b1-436e1e301e4mr19196365e9.12.1736331200437;
        Wed, 08 Jan 2025 02:13:20 -0800 (PST)
Message-ID: <aaca154b-d5f8-4bfb-8468-6f3e24ab8699@suse.com>
Date: Wed, 8 Jan 2025 11:13:19 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v4 4/6] x86: control memset() and memcpy() inlining
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
References: <14b65231-b83b-43fb-bbcf-dec5c07d285b@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <14b65231-b83b-43fb-bbcf-dec5c07d285b@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Stop the compiler from inlining non-trivial memset() and memcpy() (for
memset() see e.g. map_vcpu_info() or kimage_load_segments() for
examples). This way we even keep the compiler from using REP STOSQ /
REP MOVSQ when we'd prefer REP STOSB / REP MOVSB (when ERMS is
available).

With gcc10 this yields a modest .text size reduction (release build) of
around 2k.

Unfortunately these options aren't understood by the clang versions I
have readily available for testing with; I'm unaware of equivalents.

Note also that using cc-option-add is not an option here, or at least I
couldn't make things work with it (in case the option was not supported
by the compiler): The embedded comma in the option looks to be getting
in the way.

Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v3: Re-base.
v2: New.
---
The boundary values are of course up for discussion - I wasn't really
certain whether to use 16 or 32; I'd be less certain about using yet
larger values.

Similarly whether to permit the compiler to emit REP STOSQ / REP MOVSQ
for known size, properly aligned blocks is up for discussion.

--- a/xen/arch/x86/arch.mk
+++ b/xen/arch/x86/arch.mk
@@ -65,6 +65,9 @@ endif
 $(call cc-option-add,CFLAGS_stack_boundary,CC,-mpreferred-stack-boundary=3)
 export CFLAGS_stack_boundary
 
+CFLAGS += $(call cc-option,$(CC),-mmemcpy-strategy=unrolled_loop:16:noalign$(comma)libcall:-1:noalign)
+CFLAGS += $(call cc-option,$(CC),-mmemset-strategy=unrolled_loop:16:noalign$(comma)libcall:-1:noalign)
+
 ifeq ($(CONFIG_UBSAN),y)
 # Don't enable alignment sanitisation.  x86 has efficient unaligned accesses,
 # and various things (ACPI tables, hypercall pages, stubs, etc) are wont-fix.



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 11:13:28 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 11:13:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867136.1278596 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVU01-00028Q-OB; Wed, 08 Jan 2025 11:13:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867136.1278596; Wed, 08 Jan 2025 11:13:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVU01-00028F-KP; Wed, 08 Jan 2025 11:13:21 +0000
Received: by outflank-mailman (input) for mailman id 867136;
 Wed, 08 Jan 2025 11:13:21 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=WoWX=UA=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tVU01-0001BZ-5j
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 11:13:21 +0000
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com
 [2a00:1450:4864:20::229])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 917c0209-cdb1-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 12:13:20 +0100 (CET)
Received: by mail-lj1-x229.google.com with SMTP id
 38308e7fff4ca-3035046d4bfso149705381fa.0
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 03:13:20 -0800 (PST)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-3045ad99d11sm67292171fa.33.2025.01.08.03.13.18
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 03:13:19 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 917c0209-cdb1-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736334800; x=1736939600; 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=gjG9qId5djE3f1micVajTt9P6Qgh0I5fxUYbZTHiv9Q=;
        b=EP9OCOuGshgHmlld/dgJN6uhHb/oW/6akMqbSjJrRhIJihGQrkVIldLiZcBxmS/Zf4
         zUKA9JPxNgYwRk9IMejZPpGu96ZdnvKvGSUi0C+s+OqsnP68ktDuIGITKnwRkoTX1ixl
         +Za5Hy9BcOU9gJB4B258pEH6OZy8c2ivXR732is2IM3w6h6gFspJWFSEwRhZLcjEuhNJ
         eosfwpe2EJKrHxqXDGPOsNO91pchxRB+0WOabp/kqfPypSO9iy8WsCob7S+7XJ/mZwTN
         ONmWgO4ccF1MBob4T5yMqFms5JFt/ImnLOOfI9hCoBAbjiBjYwPEDfsOWw51uQDDSPU/
         NWpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736334800; x=1736939600;
        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=gjG9qId5djE3f1micVajTt9P6Qgh0I5fxUYbZTHiv9Q=;
        b=nTIVU9w+Wz8BKZ6ogpTovIjWELRf1LDjhQL+vEANv0JxIhnEK8KDOoxwDh/j8Q024R
         fKvpAnqy5iALxahYgR4K1yl4Cd7Iwg+Zlm/gEPXlSmmgBYaFH5Ty1zFohvHh82bUK4OW
         qqHKwWsOSTDUv9MtM7nlPkda/VJakmmsj0pebC8YlEIEWI5Jb98Xl/6UnPD51WpUsZ/I
         MYISpDW0tn3Jlwyvf6tyEtZeYOK2gI7sMdFVGRWywxQi81WzfykSYjvHNA2B/EZCTLu6
         IBpSWO0mLb2qhqnCgU4hqnzzbY+QaUaSW7YSbxWWNc5ClF69eOLfqK1RVf30pBvIqF+V
         I6Nw==
X-Gm-Message-State: AOJu0Yynp0O7qwuihnQrVco+7WbFiIRGQfmGIHvZ86GKzrYLN3qlaQwm
	R+eg/OB4pZhx1ALovcZcoJG71xA0LifXZSCu9RrgSAWqQuF3ud/y08VbG/om
X-Gm-Gg: ASbGncu2bi9gz54ThRfcWBFhP/MM2sPmSnR0gYNRilDCeQX7+oH8jYWtWHlAlzovujv
	wxOEVzXkFGpGVbh1CgSebDWGzjYlvoUDjosdY9NbCrxY7rtk8gvsJf8SYEwqZOo38f3z5eoskrX
	wBpCBNdWRMUW+h06WevRjPSV6QcJXeLECDKO2QFnxL9G1yqagSJzQ4AHt50YswwnS8+DYSy9mh3
	DBmuhowhmOrd1z4WzuFCM3AuIRdfnBT7Ljc9THNgllvOQBFOJEt2SmJXw==
X-Google-Smtp-Source: AGHT+IGWZrRhrHrT3ZUdadlaUlf3iZdqOIAZklSUrdQWysRk2Agd0ISiTq6rO/0UhBn0Dzv/8rhd6w==
X-Received: by 2002:a2e:a9a8:0:b0:300:324e:3506 with SMTP id 38308e7fff4ca-305f4575d06mr5892931fa.13.1736334799722;
        Wed, 08 Jan 2025 03:13:19 -0800 (PST)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PATCH v1 6/9] asm-generic: move some parts of Arm's domain_build.h to asm-generic header
Date: Wed,  8 Jan 2025 12:13:08 +0100
Message-ID: <ba3cde730ae072ba1088e396dd7d03482e4c4011.1736334615.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <cover.1736334615.git.oleksii.kurochko@gmail.com>
References: <cover.1736334615.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Nothing changed. Only some functions declaration are moved to asm-generic
header as they are expected to be used by common code of domain builing or
dom0less.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/arch/arm/include/asm/domain_build.h | 19 ++----------
 xen/include/asm-generic/domain-build.h  | 41 +++++++++++++++++++++++++
 2 files changed, 43 insertions(+), 17 deletions(-)
 create mode 100644 xen/include/asm-generic/domain-build.h

diff --git a/xen/arch/arm/include/asm/domain_build.h b/xen/arch/arm/include/asm/domain_build.h
index 5d77af2e8b..ad5a3ddc37 100644
--- a/xen/arch/arm/include/asm/domain_build.h
+++ b/xen/arch/arm/include/asm/domain_build.h
@@ -4,28 +4,13 @@
 #include <xen/sched.h>
 #include <asm/kernel.h>
 
+#include <asm-generic/domain-build.h>
+
 typedef __be32 gic_interrupt_t[3];
-typedef bool (*alloc_domheap_mem_cb)(struct domain *d, struct page_info *pg,
-                                     unsigned int order, void *extra);
-bool allocate_domheap_memory(struct domain *d, paddr_t tot_size,
-                             alloc_domheap_mem_cb cb, void *extra);
-bool allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn,
-                          paddr_t tot_size);
-void allocate_memory(struct domain *d, struct kernel_info *kinfo);
-int construct_domain(struct domain *d, struct kernel_info *kinfo);
 int domain_fdt_begin_node(void *fdt, const char *name, uint64_t unit);
-int make_chosen_node(const struct kernel_info *kinfo);
-int make_cpus_node(const struct domain *d, void *fdt);
-int make_hypervisor_node(struct domain *d, const struct kernel_info *kinfo,
-                         int addrcells, int sizecells);
-int make_memory_node(const struct kernel_info *kinfo, int addrcells,
-                     int sizecells, const struct membanks *mem);
 int make_psci_node(void *fdt);
-int make_timer_node(const struct kernel_info *kinfo);
 void evtchn_allocate(struct domain *d);
 
-unsigned int get_allocation_size(paddr_t size);
-
 /*
  * handle_device_interrupts retrieves the interrupts configuration from
  * a device tree node and maps those interrupts to the target domain.
diff --git a/xen/include/asm-generic/domain-build.h b/xen/include/asm-generic/domain-build.h
new file mode 100644
index 0000000000..237f94d0c3
--- /dev/null
+++ b/xen/include/asm-generic/domain-build.h
@@ -0,0 +1,41 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __ASM_GENERIC_DOMAIN_BUILD_H__
+#define __ASM_GENERIC_DOMAIN_BUILD_H__
+
+#include <xen/types.h>
+
+struct domain;
+struct page_info;
+struct kernel_info;
+struct membanks;
+
+typedef bool (*alloc_domheap_mem_cb)(struct domain *d, struct page_info *pg,
+                                     unsigned int order, void *extra);
+bool allocate_domheap_memory(struct domain *d, paddr_t tot_size,
+                             alloc_domheap_mem_cb cb, void *extra);
+
+bool allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn,
+                          paddr_t tot_size);
+void allocate_memory(struct domain *d, struct kernel_info *kinfo);
+int construct_domain(struct domain *d, struct kernel_info *kinfo);
+int make_chosen_node(const struct kernel_info *kinfo);
+int make_cpus_node(const struct domain *d, void *fdt);
+int make_hypervisor_node(struct domain *d, const struct kernel_info *kinfo,
+                         int addrcells, int sizecells);
+int make_memory_node(const struct kernel_info *kinfo, int addrcells,
+                     int sizecells, const struct membanks *mem);
+int make_timer_node(const struct kernel_info *kinfo);
+
+unsigned int get_allocation_size(paddr_t size);
+
+
+#endif /* __ASM_GENERIC_DOMAIN_BUILD_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 11:13:28 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 11:13:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867140.1278635 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVU06-0003CX-8m; Wed, 08 Jan 2025 11:13:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867140.1278635; Wed, 08 Jan 2025 11:13:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVU06-0003BS-4a; Wed, 08 Jan 2025 11:13:26 +0000
Received: by outflank-mailman (input) for mailman id 867140;
 Wed, 08 Jan 2025 11:13:24 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=WoWX=UA=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tVU04-0001BZ-EW
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 11:13:24 +0000
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com
 [2a00:1450:4864:20::22a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 931b7a19-cdb1-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 12:13:23 +0100 (CET)
Received: by mail-lj1-x22a.google.com with SMTP id
 38308e7fff4ca-3003c82c95cso137043991fa.3
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 03:13:23 -0800 (PST)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-3045ad99d11sm67292171fa.33.2025.01.08.03.13.20
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 03:13:21 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 931b7a19-cdb1-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736334803; x=1736939603; 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=GCRNwIFmqmDzUyPUbfaADvOUBg93q5fcxanayhRIhFo=;
        b=jaYkFV3h2t9AQUEcFoSPMazvvjKj5WqpI5caWp6Ly2mZ5rlM4+S20d2clNeHJ1uNt7
         17+X1Y9/ydhc0kyC0l4nyDw4BtUzxDEyaDbDjPpAznv618Y/cbhcQfcPt/PNPvtpQdXU
         C2fn0sLA7+GUbbf2Hitd3ol1EggwpQe4jx1Z4N/6f50Yry/v9te29efajK/rUXdCtpAP
         WtDBTAfHuf/t0rHyAAEDuXeh9elz5s6C9bmsJ2mSTxY/3WQB8tswCnEaGr9OgrsG7AUg
         dUA5IKhDXWHOrp7MJ2r2jUzNxTql5R4Jlg7QoFsHDK14dBN31vipF4vXWs8ycZsDjqvk
         59QA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736334803; x=1736939603;
        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=GCRNwIFmqmDzUyPUbfaADvOUBg93q5fcxanayhRIhFo=;
        b=AC4NrLMkzRb1nGP/OtmBDYYD9WRcwECWKMidbqIWlUE/ZdJ9FS3oE7qAZgHY0cbW37
         9P/wF5vP5wqAh5Z9Fj6TNXyFfjx19WeqOmKBuwGhijPaCwyZqe2OUCDchGhvx1eqdCrw
         byiv0UlDjyqpunWeLxNSkSVdhylGng5J3c3aJ665vRd/tpoIFCiMMKmYUWyZqh/DS7yo
         R07MLZK/wlokwWCmJVnb7k08aDzeAGiCWx5OChp35SU8bM0j1MAIRAmsaDip+YwAmJN6
         Vsu6ZV9AqftZQw+LQLpXTMBo4jyl3UfFMRuBHfRGPpBFUn/KweL2TCDVXLiOy+xzODEf
         NZoQ==
X-Gm-Message-State: AOJu0Yy2AwUPREA7j2RSZdYZVkl+ygZAEVhGkh1oI9UuFNKawOpXEJih
	H1rKDUtorPpxWz3T+Uy6v+Ka9GVR0yp8w8xCocviBs3yaw3o1okcKjyPcPVc
X-Gm-Gg: ASbGncssgZQRazy58hntG+GLAf5RIz/nKIDtSvXk6y/0P0z4TZ9hobFUrsnY48CoZbD
	vUQVXN8omNJNc0FiHHtz8kCRbu3kouHx1773jliD7h5HxbYWpaVetjS3Nk5wgOXtQZ/FFEX3Ddt
	Uz9GZPT6fd4BVQC0uYzl13nrgOVECP043hwv9CRtYrATAdUSS5iodA+r8xsZXhcMa7dYSrikwSq
	VY7ilVx2UK7aJc2a16C//wn1/5vWsy7rG2ykiBqRcv3GjD/6XOAgHbSsw==
X-Google-Smtp-Source: AGHT+IG8Cf26ShFn3iyVqP3HxATc+zjwe9ssoFtEuTEVG/VclyY9cvaI5LziOEOTbQD3wOHcNXH8fw==
X-Received: by 2002:a2e:b888:0:b0:2fb:597e:28d9 with SMTP id 38308e7fff4ca-305f45855bbmr5999531fa.14.1736334802299;
        Wed, 08 Jan 2025 03:13:22 -0800 (PST)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PATCH v1 8/9] xen/common: dom0less: introduce common domain-build.c
Date: Wed,  8 Jan 2025 12:13:10 +0100
Message-ID: <5d4634ff3d44955d4110ce52c14e0a524cbc4706.1736334615.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <cover.1736334615.git.oleksii.kurochko@gmail.com>
References: <cover.1736334615.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Some functions of Arm's domain_build.c could be reused by dom0less or other
features connected to domain construction/build.

The following functions are moved to common:
- get_allocation_size().
- allocate_domheap_memory().
- guest_map_pages().
- allocate_bank_memory().
- add_hwdom_free_regions().
- find_unallocated_memory().
- allocate_memory().
- dtb_load().
- initrd_load().

Prototype of dtb_load() and initrd_load() is updated to recieve a pointer
to copy_to_guest_phys() as some archs require
copy_to_guest_phys_fluch_dcache().

Update arm/include/asm/Makefile to generate  domain-build.h for Arm as it is
used by domain-build.c.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/arch/arm/domain_build.c            | 400 +-----------------------
 xen/arch/arm/include/asm/Makefile      |   1 +
 xen/common/device-tree/Makefile        |   1 +
 xen/common/device-tree/domain-build.c  | 405 +++++++++++++++++++++++++
 xen/include/asm-generic/domain-build.h |  33 +-
 5 files changed, 441 insertions(+), 399 deletions(-)
 create mode 100644 xen/common/device-tree/domain-build.c

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 976b03a5df..e72da272d8 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -119,18 +119,6 @@ struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
     return vcpu_create(dom0, 0);
 }
 
-unsigned int __init get_allocation_size(paddr_t size)
-{
-    /*
-     * get_order_from_bytes returns the order greater than or equal to
-     * the given size, but we need less than or equal. Adding one to
-     * the size pushes an evenly aligned size into the next order, so
-     * we can then unconditionally subtract 1 from the order which is
-     * returned.
-     */
-    return get_order_from_bytes(size + 1) - 1;
-}
-
 /*
  * Insert the given pages into a memory bank, banks are ordered by address.
  *
@@ -417,98 +405,6 @@ static void __init allocate_memory_11(struct domain *d,
     }
 }
 
-bool __init allocate_domheap_memory(struct domain *d, paddr_t tot_size,
-                                    alloc_domheap_mem_cb cb, void *extra)
-{
-    unsigned int max_order = UINT_MAX;
-
-    while ( tot_size > 0 )
-    {
-        unsigned int order = get_allocation_size(tot_size);
-        struct page_info *pg;
-
-        order = min(max_order, order);
-
-        pg = alloc_domheap_pages(d, order, 0);
-        if ( !pg )
-        {
-            /*
-             * If we can't allocate one page, then it is unlikely to
-             * succeed in the next iteration. So bail out.
-             */
-            if ( !order )
-                return false;
-
-            /*
-             * If we can't allocate memory with order, then it is
-             * unlikely to succeed in the next iteration.
-             * Record the order - 1 to avoid re-trying.
-             */
-            max_order = order - 1;
-            continue;
-        }
-
-        if ( !cb(d, pg, order, extra) )
-            return false;
-
-        tot_size -= (1ULL << (PAGE_SHIFT + order));
-    }
-
-    return true;
-}
-
-static bool __init guest_map_pages(struct domain *d, struct page_info *pg,
-                                   unsigned int order, void *extra)
-{
-    gfn_t *sgfn = (gfn_t *)extra;
-    int res;
-
-    BUG_ON(!sgfn);
-    res = guest_physmap_add_page(d, *sgfn, page_to_mfn(pg), order);
-    if ( res )
-    {
-        dprintk(XENLOG_ERR, "Failed map pages to DOMU: %d", res);
-        return false;
-    }
-
-    *sgfn = gfn_add(*sgfn, 1UL << order);
-
-    return true;
-}
-
-bool __init allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn,
-                                 paddr_t tot_size)
-{
-    struct membanks *mem = kernel_info_get_mem(kinfo);
-    struct domain *d = kinfo->d;
-    struct membank *bank;
-
-    /*
-     * allocate_bank_memory can be called with a tot_size of zero for
-     * the second memory bank. It is not an error and we can safely
-     * avoid creating a zero-size memory bank.
-     */
-    if ( tot_size == 0 )
-        return true;
-
-    bank = &mem->bank[mem->nr_banks];
-    bank->start = gfn_to_gaddr(sgfn);
-    bank->size = tot_size;
-
-    /*
-     * Allocate pages from the heap until tot_size is zero and map them to the
-     * guest using guest_map_pages, passing the starting gfn as extra parameter
-     * for the map operation.
-     */
-    if ( !allocate_domheap_memory(d, tot_size, guest_map_pages, &sgfn) )
-        return false;
-
-    mem->nr_banks++;
-    kinfo->unassigned_mem -= bank->size;
-
-    return true;
-}
-
 /*
  * When PCI passthrough is available we want to keep the
  * "linux,pci-domain" in sync for every host bridge.
@@ -899,229 +795,6 @@ int __init add_ext_regions(unsigned long s_gfn, unsigned long e_gfn,
     return 0;
 }
 
-static int __init add_hwdom_free_regions(unsigned long s_gfn,
-                                         unsigned long e_gfn, void *data)
-{
-    struct membanks *free_regions = data;
-    paddr_t start, size;
-    paddr_t s = pfn_to_paddr(s_gfn);
-    paddr_t e = pfn_to_paddr(e_gfn);
-    unsigned int i, j;
-
-    if ( free_regions->nr_banks >= free_regions->max_banks )
-        return 0;
-
-    /*
-     * Both start and size of the free region should be 2MB aligned to
-     * potentially allow superpage mapping.
-     */
-    start = (s + SZ_2M - 1) & ~(SZ_2M - 1);
-    if ( start > e )
-        return 0;
-
-    /*
-     * e is actually "end-1" because it is called by rangeset functions
-     * which are inclusive of the last address.
-     */
-    e += 1;
-    size = (e - start) & ~(SZ_2M - 1);
-
-    /* Find the insert position (descending order). */
-    for ( i = 0; i < free_regions->nr_banks ; i++ )
-        if ( size > free_regions->bank[i].size )
-            break;
-
-    /* Move the other banks to make space. */
-    for ( j = free_regions->nr_banks; j > i ; j-- )
-    {
-        free_regions->bank[j].start = free_regions->bank[j - 1].start;
-        free_regions->bank[j].size = free_regions->bank[j - 1].size;
-    }
-
-    free_regions->bank[i].start = start;
-    free_regions->bank[i].size = size;
-    free_regions->nr_banks++;
-
-    return 0;
-}
-
-/*
- * Find unused regions of Host address space which can be exposed to domain
- * using the host memory layout. In order to calculate regions we exclude every
- * region passed in mem_banks from the Host RAM.
- */
-static int __init find_unallocated_memory(const struct kernel_info *kinfo,
-                                          const struct membanks *mem_banks[],
-                                          unsigned int nr_mem_banks,
-                                          struct membanks *free_regions,
-                                          int (*cb)(unsigned long s_gfn,
-                                                    unsigned long e_gfn,
-                                                    void *data))
-{
-    const struct membanks *mem = bootinfo_get_mem();
-    struct rangeset *unalloc_mem;
-    paddr_t start, end;
-    unsigned int i, j;
-    int res;
-
-    ASSERT(domain_use_host_layout(kinfo->d));
-
-    unalloc_mem = rangeset_new(NULL, NULL, 0);
-    if ( !unalloc_mem )
-        return -ENOMEM;
-
-    /* Start with all available RAM */
-    for ( i = 0; i < mem->nr_banks; i++ )
-    {
-        start = mem->bank[i].start;
-        end = mem->bank[i].start + mem->bank[i].size;
-        res = rangeset_add_range(unalloc_mem, PFN_DOWN(start),
-                                 PFN_DOWN(end - 1));
-        if ( res )
-        {
-            printk(XENLOG_ERR "Failed to add: %#"PRIpaddr"->%#"PRIpaddr"\n",
-                   start, end);
-            goto out;
-        }
-    }
-
-    /* Remove all regions listed in mem_banks */
-    for ( i = 0; i < nr_mem_banks; i++ )
-        for ( j = 0; j < mem_banks[i]->nr_banks; j++ )
-        {
-            start = mem_banks[i]->bank[j].start;
-
-            /* Shared memory banks can contain INVALID_PADDR as start */
-            if ( INVALID_PADDR == start )
-                continue;
-
-            end = mem_banks[i]->bank[j].start + mem_banks[i]->bank[j].size;
-            res = rangeset_remove_range(unalloc_mem, PFN_DOWN(start),
-                                        PFN_DOWN(end - 1));
-            if ( res )
-            {
-                printk(XENLOG_ERR
-                       "Failed to add: %#"PRIpaddr"->%#"PRIpaddr", error %d\n",
-                       start, end, res);
-                goto out;
-            }
-        }
-
-    start = 0;
-    end = (1ULL << p2m_ipa_bits) - 1;
-    res = rangeset_report_ranges(unalloc_mem, PFN_DOWN(start), PFN_DOWN(end),
-                                 cb, free_regions);
-    if ( res )
-        free_regions->nr_banks = 0;
-    else if ( !free_regions->nr_banks )
-        res = -ENOENT;
-
-out:
-    rangeset_destroy(unalloc_mem);
-
-    return res;
-}
-
-void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
-{
-    struct membanks *mem = kernel_info_get_mem(kinfo);
-    unsigned int i, nr_banks = GUEST_RAM_BANKS;
-    struct membanks *hwdom_free_mem = NULL;
-
-    printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n",
-           /* Don't want format this as PRIpaddr (16 digit hex) */
-           (unsigned long)(kinfo->unassigned_mem >> 20), d);
-
-    mem->nr_banks = 0;
-    /*
-     * Use host memory layout for hwdom. Only case for this is when LLC coloring
-     * is enabled.
-     */
-    if ( is_hardware_domain(d) )
-    {
-        struct membanks *gnttab = xzalloc_flex_struct(struct membanks, bank, 1);
-        /*
-         * Exclude the following regions:
-         * 1) Remove reserved memory
-         * 2) Grant table assigned to hwdom
-         */
-        const struct membanks *mem_banks[] = {
-            bootinfo_get_reserved_mem(),
-            gnttab,
-        };
-
-        if ( !gnttab )
-            goto fail;
-
-        gnttab->nr_banks = 1;
-        gnttab->bank[0].start = kinfo->gnttab_start;
-        gnttab->bank[0].size = kinfo->gnttab_size;
-
-        hwdom_free_mem = xzalloc_flex_struct(struct membanks, bank,
-                                             NR_MEM_BANKS);
-        if ( !hwdom_free_mem )
-            goto fail;
-
-        hwdom_free_mem->max_banks = NR_MEM_BANKS;
-
-        if ( find_unallocated_memory(kinfo, mem_banks, ARRAY_SIZE(mem_banks),
-                                     hwdom_free_mem, add_hwdom_free_regions) )
-            goto fail;
-
-        nr_banks = hwdom_free_mem->nr_banks;
-        xfree(gnttab);
-    }
-
-    for ( i = 0; kinfo->unassigned_mem > 0 && nr_banks > 0; i++, nr_banks-- )
-    {
-        paddr_t bank_start, bank_size;
-
-        if ( is_hardware_domain(d) )
-        {
-            bank_start = hwdom_free_mem->bank[i].start;
-            bank_size = hwdom_free_mem->bank[i].size;
-        }
-        else
-        {
-            const uint64_t bankbase[] = GUEST_RAM_BANK_BASES;
-            const uint64_t banksize[] = GUEST_RAM_BANK_SIZES;
-
-            if ( i >= GUEST_RAM_BANKS )
-                goto fail;
-
-            bank_start = bankbase[i];
-            bank_size = banksize[i];
-        }
-
-        bank_size = MIN(bank_size, kinfo->unassigned_mem);
-        if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(bank_start), bank_size) )
-            goto fail;
-    }
-
-    if ( kinfo->unassigned_mem )
-        goto fail;
-
-    for( i = 0; i < mem->nr_banks; i++ )
-    {
-        printk(XENLOG_INFO "%pd BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (%ldMB)\n",
-               d,
-               i,
-               mem->bank[i].start,
-               mem->bank[i].start + mem->bank[i].size,
-               /* Don't want format this as PRIpaddr (16 digit hex) */
-               (unsigned long)(mem->bank[i].size >> 20));
-    }
-
-    xfree(hwdom_free_mem);
-    return;
-
-  fail:
-    panic("Failed to allocate requested domain memory."
-          /* Don't want format this as PRIpaddr (16 digit hex) */
-          " %ldKB unallocated. Fix the VMs configurations.\n",
-          (unsigned long)kinfo->unassigned_mem >> 10);
-}
-
 static int __init handle_pci_range(const struct dt_device_node *dev,
                                    uint64_t addr, uint64_t len, void *data)
 {
@@ -2056,75 +1729,6 @@ static int __init prepare_dtb_hwdom(struct domain *d, struct kernel_info *kinfo)
     return -EINVAL;
 }
 
-static void __init dtb_load(struct kernel_info *kinfo)
-{
-    unsigned long left;
-
-    printk("Loading %pd DTB to 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
-           kinfo->d, kinfo->dtb_paddr,
-           kinfo->dtb_paddr + fdt_totalsize(kinfo->fdt));
-
-    left = copy_to_guest_phys_flush_dcache(kinfo->d, kinfo->dtb_paddr,
-                                           kinfo->fdt,
-                                           fdt_totalsize(kinfo->fdt));
-
-    if ( left != 0 )
-        panic("Unable to copy the DTB to %pd memory (left = %lu bytes)\n",
-              kinfo->d, left);
-    xfree(kinfo->fdt);
-}
-
-static void __init initrd_load(struct kernel_info *kinfo)
-{
-    const struct bootmodule *mod = kinfo->initrd_bootmodule;
-    paddr_t load_addr = kinfo->initrd_paddr;
-    paddr_t paddr, len;
-    int node;
-    int res;
-    __be32 val[2];
-    __be32 *cellp;
-    void __iomem *initrd;
-
-    if ( !mod || !mod->size )
-        return;
-
-    paddr = mod->start;
-    len = mod->size;
-
-    printk("Loading %pd initrd from %"PRIpaddr" to 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
-           kinfo->d, paddr, load_addr, load_addr + len);
-
-    /* Fix up linux,initrd-start and linux,initrd-end in /chosen */
-    node = fdt_path_offset(kinfo->fdt, "/chosen");
-    if ( node < 0 )
-        panic("Cannot find the /chosen node\n");
-
-    cellp = (__be32 *)val;
-    dt_set_cell(&cellp, ARRAY_SIZE(val), load_addr);
-    res = fdt_setprop_inplace(kinfo->fdt, node, "linux,initrd-start",
-                              val, sizeof(val));
-    if ( res )
-        panic("Cannot fix up \"linux,initrd-start\" property\n");
-
-    cellp = (__be32 *)val;
-    dt_set_cell(&cellp, ARRAY_SIZE(val), load_addr + len);
-    res = fdt_setprop_inplace(kinfo->fdt, node, "linux,initrd-end",
-                              val, sizeof(val));
-    if ( res )
-        panic("Cannot fix up \"linux,initrd-end\" property\n");
-
-    initrd = ioremap_wc(paddr, len);
-    if ( !initrd )
-        panic("Unable to map the hwdom initrd\n");
-
-    res = copy_to_guest_phys_flush_dcache(kinfo->d, load_addr,
-                                          initrd, len);
-    if ( res != 0 )
-        panic("Unable to copy the initrd in the hwdom memory\n");
-
-    iounmap(initrd);
-}
-
 /*
  * Allocate the event channel PPIs and setup the HVM_PARAM_CALLBACK_IRQ.
  * The allocated IRQ will be found in d->arch.evtchn_irq.
@@ -2217,8 +1821,8 @@ int __init construct_domain(struct domain *d, struct kernel_info *kinfo)
      */
     kernel_load(kinfo);
     /* initrd_load will fix up the fdt, so call it before dtb_load */
-    initrd_load(kinfo);
-    dtb_load(kinfo);
+    initrd_load(kinfo, copy_to_guest_phys_flush_dcache);
+    dtb_load(kinfo, copy_to_guest_phys_flush_dcache);
 
     memset(regs, 0, sizeof(*regs));
 
diff --git a/xen/arch/arm/include/asm/Makefile b/xen/arch/arm/include/asm/Makefile
index 9cec55606e..cda29dca6c 100644
--- a/xen/arch/arm/include/asm/Makefile
+++ b/xen/arch/arm/include/asm/Makefile
@@ -1,6 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0-only
 generic-y += altp2m.h
 generic-y += device.h
+generic-y += domain-build.h
 generic-y += dom0less-build.h
 generic-y += hardirq.h
 generic-y += iocap.h
diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
index e88a4d5799..831b91399b 100644
--- a/xen/common/device-tree/Makefile
+++ b/xen/common/device-tree/Makefile
@@ -1,6 +1,7 @@
 obj-y += bootfdt.init.o
 obj-y += bootinfo.init.o
 obj-y += device-tree.o
+obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += domain-build.o
 obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.o
 obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o
 obj-y += intc.o
diff --git a/xen/common/device-tree/domain-build.c b/xen/common/device-tree/domain-build.c
new file mode 100644
index 0000000000..b4fb67ad9f
--- /dev/null
+++ b/xen/common/device-tree/domain-build.c
@@ -0,0 +1,405 @@
+#include <xen/bootfdt.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/libfdt/libfdt.h>
+#include <xen/mm.h>
+#include <xen/sched.h>
+#include <xen/sizes.h>
+#include <xen/types.h>
+#include <xen/vmap.h>
+
+#include <asm/domain-build.h>
+#include <asm/kernel.h>
+#include <asm/p2m.h>
+
+bool __init allocate_domheap_memory(struct domain *d, paddr_t tot_size,
+                                    alloc_domheap_mem_cb cb, void *extra)
+{
+    unsigned int max_order = UINT_MAX;
+
+    while ( tot_size > 0 )
+    {
+        unsigned int order = get_allocation_size(tot_size);
+        struct page_info *pg;
+
+        order = min(max_order, order);
+
+        pg = alloc_domheap_pages(d, order, 0);
+        if ( !pg )
+        {
+            /*
+             * If we can't allocate one page, then it is unlikely to
+             * succeed in the next iteration. So bail out.
+             */
+            if ( !order )
+                return false;
+
+            /*
+             * If we can't allocate memory with order, then it is
+             * unlikely to succeed in the next iteration.
+             * Record the order - 1 to avoid re-trying.
+             */
+            max_order = order - 1;
+            continue;
+        }
+
+        if ( !cb(d, pg, order, extra) )
+            return false;
+
+        tot_size -= (1ULL << (PAGE_SHIFT + order));
+    }
+
+    return true;
+}
+
+static bool __init guest_map_pages(struct domain *d, struct page_info *pg,
+                                   unsigned int order, void *extra)
+{
+    gfn_t *sgfn = (gfn_t *)extra;
+    int res;
+
+    BUG_ON(!sgfn);
+    res = guest_physmap_add_page(d, *sgfn, page_to_mfn(pg), order);
+    if ( res )
+    {
+        dprintk(XENLOG_ERR, "Failed map pages to DOMU: %d", res);
+        return false;
+    }
+
+    *sgfn = gfn_add(*sgfn, 1UL << order);
+
+    return true;
+}
+
+bool __init allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn,
+                                 paddr_t tot_size)
+{
+    struct membanks *mem = kernel_info_get_mem(kinfo);
+    struct domain *d = kinfo->d;
+    struct membank *bank;
+
+    /*
+     * allocate_bank_memory can be called with a tot_size of zero for
+     * the second memory bank. It is not an error and we can safely
+     * avoid creating a zero-size memory bank.
+     */
+    if ( tot_size == 0 )
+        return true;
+
+    bank = &mem->bank[mem->nr_banks];
+    bank->start = gfn_to_gaddr(sgfn);
+    bank->size = tot_size;
+
+    /*
+     * Allocate pages from the heap until tot_size is zero and map them to the
+     * guest using guest_map_pages, passing the starting gfn as extra parameter
+     * for the map operation.
+     */
+    if ( !allocate_domheap_memory(d, tot_size, guest_map_pages, &sgfn) )
+        return false;
+
+    mem->nr_banks++;
+    kinfo->unassigned_mem -= bank->size;
+
+    return true;
+}
+
+static int __init add_hwdom_free_regions(unsigned long s_gfn,
+                                         unsigned long e_gfn, void *data)
+{
+    struct membanks *free_regions = data;
+    paddr_t start, size;
+    paddr_t s = pfn_to_paddr(s_gfn);
+    paddr_t e = pfn_to_paddr(e_gfn);
+    unsigned int i, j;
+
+    if ( free_regions->nr_banks >= free_regions->max_banks )
+        return 0;
+
+    /*
+     * Both start and size of the free region should be 2MB aligned to
+     * potentially allow superpage mapping.
+     */
+    start = (s + SZ_2M - 1) & ~(SZ_2M - 1);
+    if ( start > e )
+        return 0;
+
+    /*
+     * e is actually "end-1" because it is called by rangeset functions
+     * which are inclusive of the last address.
+     */
+    e += 1;
+    size = (e - start) & ~(SZ_2M - 1);
+
+    /* Find the insert position (descending order). */
+    for ( i = 0; i < free_regions->nr_banks ; i++ )
+        if ( size > free_regions->bank[i].size )
+            break;
+
+    /* Move the other banks to make space. */
+    for ( j = free_regions->nr_banks; j > i ; j-- )
+    {
+        free_regions->bank[j].start = free_regions->bank[j - 1].start;
+        free_regions->bank[j].size = free_regions->bank[j - 1].size;
+    }
+
+    free_regions->bank[i].start = start;
+    free_regions->bank[i].size = size;
+    free_regions->nr_banks++;
+
+    return 0;
+}
+
+/*
+ * Find unused regions of Host address space which can be exposed to domain
+ * using the host memory layout. In order to calculate regions we exclude every
+ * region passed in mem_banks from the Host RAM.
+ */
+int __init find_unallocated_memory(const struct kernel_info *kinfo,
+                                   const struct membanks *mem_banks[],
+                                   unsigned int nr_mem_banks,
+                                   struct membanks *free_regions,
+                                   int (*cb)(unsigned long s_gfn,
+                                             unsigned long e_gfn,
+                                             void *data))
+{
+    const struct membanks *mem = bootinfo_get_mem();
+    struct rangeset *unalloc_mem;
+    paddr_t start, end;
+    unsigned int i, j;
+    int res;
+
+    ASSERT(domain_use_host_layout(kinfo->d));
+
+    unalloc_mem = rangeset_new(NULL, NULL, 0);
+    if ( !unalloc_mem )
+        return -ENOMEM;
+
+    /* Start with all available RAM */
+    for ( i = 0; i < mem->nr_banks; i++ )
+    {
+        start = mem->bank[i].start;
+        end = mem->bank[i].start + mem->bank[i].size;
+        res = rangeset_add_range(unalloc_mem, PFN_DOWN(start),
+                                 PFN_DOWN(end - 1));
+        if ( res )
+        {
+            printk(XENLOG_ERR "Failed to add: %#"PRIpaddr"->%#"PRIpaddr"\n",
+                   start, end);
+            goto out;
+        }
+    }
+
+    /* Remove all regions listed in mem_banks */
+    for ( i = 0; i < nr_mem_banks; i++ )
+        for ( j = 0; j < mem_banks[i]->nr_banks; j++ )
+        {
+            start = mem_banks[i]->bank[j].start;
+
+            /* Shared memory banks can contain INVALID_PADDR as start */
+            if ( INVALID_PADDR == start )
+                continue;
+
+            end = mem_banks[i]->bank[j].start + mem_banks[i]->bank[j].size;
+            res = rangeset_remove_range(unalloc_mem, PFN_DOWN(start),
+                                        PFN_DOWN(end - 1));
+            if ( res )
+            {
+                printk(XENLOG_ERR
+                       "Failed to add: %#"PRIpaddr"->%#"PRIpaddr", error %d\n",
+                       start, end, res);
+                goto out;
+            }
+        }
+
+    start = 0;
+    end = (1ULL << p2m_ipa_bits) - 1;
+    res = rangeset_report_ranges(unalloc_mem, PFN_DOWN(start), PFN_DOWN(end),
+                                 cb, free_regions);
+    if ( res )
+        free_regions->nr_banks = 0;
+    else if ( !free_regions->nr_banks )
+        res = -ENOENT;
+
+out:
+    rangeset_destroy(unalloc_mem);
+
+    return res;
+}
+
+void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
+{
+    struct membanks *mem = kernel_info_get_mem(kinfo);
+    unsigned int i, nr_banks = GUEST_RAM_BANKS;
+    struct membanks *hwdom_free_mem = NULL;
+
+    printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n",
+           /* Don't want format this as PRIpaddr (16 digit hex) */
+           (unsigned long)(kinfo->unassigned_mem >> 20), d);
+
+    mem->nr_banks = 0;
+    /*
+     * Use host memory layout for hwdom. Only case for this is when LLC coloring
+     * is enabled.
+     */
+    if ( is_hardware_domain(d) )
+    {
+        struct membanks *gnttab = xzalloc_flex_struct(struct membanks, bank, 1);
+        /*
+         * Exclude the following regions:
+         * 1) Remove reserved memory
+         * 2) Grant table assigned to hwdom
+         */
+        const struct membanks *mem_banks[] = {
+            bootinfo_get_reserved_mem(),
+            gnttab,
+        };
+
+        if ( !gnttab )
+            goto fail;
+
+        gnttab->nr_banks = 1;
+        gnttab->bank[0].start = kinfo->gnttab_start;
+        gnttab->bank[0].size = kinfo->gnttab_size;
+
+        hwdom_free_mem = xzalloc_flex_struct(struct membanks, bank,
+                                             NR_MEM_BANKS);
+        if ( !hwdom_free_mem )
+            goto fail;
+
+        hwdom_free_mem->max_banks = NR_MEM_BANKS;
+
+        if ( find_unallocated_memory(kinfo, mem_banks, ARRAY_SIZE(mem_banks),
+                                     hwdom_free_mem, add_hwdom_free_regions) )
+            goto fail;
+
+        nr_banks = hwdom_free_mem->nr_banks;
+        xfree(gnttab);
+    }
+
+    for ( i = 0; kinfo->unassigned_mem > 0 && nr_banks > 0; i++, nr_banks-- )
+    {
+        paddr_t bank_start, bank_size;
+
+        if ( is_hardware_domain(d) )
+        {
+            bank_start = hwdom_free_mem->bank[i].start;
+            bank_size = hwdom_free_mem->bank[i].size;
+        }
+        else
+        {
+            const uint64_t bankbase[] = GUEST_RAM_BANK_BASES;
+            const uint64_t banksize[] = GUEST_RAM_BANK_SIZES;
+
+            if ( i >= GUEST_RAM_BANKS )
+                goto fail;
+
+            bank_start = bankbase[i];
+            bank_size = banksize[i];
+        }
+
+        bank_size = MIN(bank_size, kinfo->unassigned_mem);
+        if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(bank_start), bank_size) )
+            goto fail;
+    }
+
+    if ( kinfo->unassigned_mem )
+        goto fail;
+
+    for( i = 0; i < mem->nr_banks; i++ )
+    {
+        printk(XENLOG_INFO "%pd BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (%ldMB)\n",
+               d,
+               i,
+               mem->bank[i].start,
+               mem->bank[i].start + mem->bank[i].size,
+               /* Don't want format this as PRIpaddr (16 digit hex) */
+               (unsigned long)(mem->bank[i].size >> 20));
+    }
+
+    xfree(hwdom_free_mem);
+    return;
+
+  fail:
+    panic("Failed to allocate requested domain memory."
+          /* Don't want format this as PRIpaddr (16 digit hex) */
+          " %ldKB unallocated. Fix the VMs configurations.\n",
+          (unsigned long)kinfo->unassigned_mem >> 10);
+}
+
+/* Copy data to guest physical address, then clean the region. */
+typedef unsigned long (*copy_to_guest_phys_cb)(struct domain *d,
+                                               paddr_t gpa,
+                                               void *buf,
+                                               unsigned int len);
+
+void __init dtb_load(struct kernel_info *kinfo,
+                     copy_to_guest_phys_cb copy_to_guest)
+{
+    unsigned long left;
+
+    printk("Loading %pd DTB to 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
+           kinfo->d, kinfo->dtb_paddr,
+           kinfo->dtb_paddr + fdt_totalsize(kinfo->fdt));
+
+    left = copy_to_guest(kinfo->d, kinfo->dtb_paddr,
+                         kinfo->fdt,
+                         fdt_totalsize(kinfo->fdt));
+
+    if ( left != 0 )
+        panic("Unable to copy the DTB to %pd memory (left = %lu bytes)\n",
+              kinfo->d, left);
+    xfree(kinfo->fdt);
+}
+
+void __init initrd_load(struct kernel_info *kinfo,
+                        copy_to_guest_phys_cb copy_to_guest)
+{
+    const struct bootmodule *mod = kinfo->initrd_bootmodule;
+    paddr_t load_addr = kinfo->initrd_paddr;
+    paddr_t paddr, len;
+    int node;
+    int res;
+    __be32 val[2];
+    __be32 *cellp;
+    void __iomem *initrd;
+
+    if ( !mod || !mod->size )
+        return;
+
+    paddr = mod->start;
+    len = mod->size;
+
+    printk("Loading %pd initrd from %"PRIpaddr" to 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
+           kinfo->d, paddr, load_addr, load_addr + len);
+
+    /* Fix up linux,initrd-start and linux,initrd-end in /chosen */
+    node = fdt_path_offset(kinfo->fdt, "/chosen");
+    if ( node < 0 )
+        panic("Cannot find the /chosen node\n");
+
+    cellp = (__be32 *)val;
+    dt_set_cell(&cellp, ARRAY_SIZE(val), load_addr);
+    res = fdt_setprop_inplace(kinfo->fdt, node, "linux,initrd-start",
+                              val, sizeof(val));
+    if ( res )
+        panic("Cannot fix up \"linux,initrd-start\" property\n");
+
+    cellp = (__be32 *)val;
+    dt_set_cell(&cellp, ARRAY_SIZE(val), load_addr + len);
+    res = fdt_setprop_inplace(kinfo->fdt, node, "linux,initrd-end",
+                              val, sizeof(val));
+    if ( res )
+        panic("Cannot fix up \"linux,initrd-end\" property\n");
+
+    initrd = ioremap_wc(paddr, len);
+    if ( !initrd )
+        panic("Unable to map the hwdom initrd\n");
+
+    res = copy_to_guest(kinfo->d, load_addr,
+                        initrd, len);
+    if ( res != 0 )
+        panic("Unable to copy the initrd in the hwdom memory\n");
+
+    iounmap(initrd);
+}
diff --git a/xen/include/asm-generic/domain-build.h b/xen/include/asm-generic/domain-build.h
index 237f94d0c3..4119d6e329 100644
--- a/xen/include/asm-generic/domain-build.h
+++ b/xen/include/asm-generic/domain-build.h
@@ -2,6 +2,7 @@
 #ifndef __ASM_GENERIC_DOMAIN_BUILD_H__
 #define __ASM_GENERIC_DOMAIN_BUILD_H__
 
+#include <xen/mm.h>
 #include <xen/types.h>
 
 struct domain;
@@ -26,7 +27,37 @@ int make_memory_node(const struct kernel_info *kinfo, int addrcells,
                      int sizecells, const struct membanks *mem);
 int make_timer_node(const struct kernel_info *kinfo);
 
-unsigned int get_allocation_size(paddr_t size);
+
+static inline int get_allocation_size(paddr_t size)
+{
+    /*
+     * get_order_from_bytes returns the order greater than or equal to
+     * the given size, but we need less than or equal. Adding one to
+     * the size pushes an evenly aligned size into the next order, so
+     * we can then unconditionally subtract 1 from the order which is
+     * returned.
+     */
+    return get_order_from_bytes(size + 1) - 1;
+}
+
+typedef unsigned long (*copy_to_guest_phys_cb)(struct domain *d,
+                                               paddr_t gpa,
+                                               void *buf,
+                                               unsigned int len);
+
+void initrd_load(struct kernel_info *kinfo,
+                 copy_to_guest_phys_cb copy_to_guest);
+
+void dtb_load(struct kernel_info *kinfo,
+              copy_to_guest_phys_cb copy_to_guest);
+
+int find_unallocated_memory(const struct kernel_info *kinfo,
+                            const struct membanks *mem_banks[],
+                            unsigned int nr_mem_banks,
+                            struct membanks *free_regions,
+                            int (*cb)(unsigned long s_gfn,
+                                      unsigned long e_gfn,
+                                      void *data));
 
 
 #endif /* __ASM_GENERIC_DOMAIN_BUILD_H__ */
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 11:13:28 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 11:13:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867135.1278586 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVU00-0001sn-F5; Wed, 08 Jan 2025 11:13:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867135.1278586; Wed, 08 Jan 2025 11:13:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVU00-0001sg-CH; Wed, 08 Jan 2025 11:13:20 +0000
Received: by outflank-mailman (input) for mailman id 867135;
 Wed, 08 Jan 2025 11:13:19 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=WoWX=UA=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tVTzy-0001BZ-Se
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 11:13:18 +0000
Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com
 [2a00:1450:4864:20::233])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8f9e9649-cdb1-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 12:13:17 +0100 (CET)
Received: by mail-lj1-x233.google.com with SMTP id
 38308e7fff4ca-30219437e63so7116531fa.1
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 03:13:17 -0800 (PST)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-3045ad99d11sm67292171fa.33.2025.01.08.03.13.15
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 03:13:15 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8f9e9649-cdb1-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736334796; x=1736939596; 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=n3fSG769VnOrM2edhG3O3s3zVRPKLWUvOf5I+6qkAcQ=;
        b=Z9BbAfDEB7ilbeMgddFjyfE3cB9w5+GgBow/2dgm/PinvNd+C8u35/YtquIcpYtekh
         wxHuO5X0huuF57V7HGKi1l/2CvS3kmBHjm2gTgcqM4DHXzeYdE4Qtl+N3XCPAC2jp69t
         +ar8Ee6kPs76wzMzhFrxLJdnCG4CUBNrrHCgvX8NdfqKYx99GG0t6WUgAxMT7irej1Mh
         0Ybk0mzO/jt7PTMaRJTh3rh0t7AEwkZgZpf753e/N+rfRJ7JKHsZhA+UnuAvnKf0LU2C
         XfWRIi9IcnjsyWc3yougW3Dk0gqIrcB0PK9zBrFbfevOmEC128Saq4XbvCm1ZfPnSxId
         KGxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736334796; x=1736939596;
        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=n3fSG769VnOrM2edhG3O3s3zVRPKLWUvOf5I+6qkAcQ=;
        b=RUJVNOJyDILEhccO6t0Yj55DPmAJ9vCPyN2WPz3okdYNpyeMVL7kKOH8gkyj3YLuJu
         OT+S1ORlqnI/PE8zFcxgs2alRDdjh7U0TYItQRzJjoGVMWaaWq1vYpAaF1d8ITOt3qe/
         GElfq4BNk7KBXoGMcstaEYsVehdtP11XOPpbAH1bQ3XXdBnJpqHtHvGZgEXbvjPw+Oju
         pUq64ST4KbtbloyFO/QXjEhx/zg1Zo2ZUSLigUMhLmItvenTD0yLw6X9niM4sfGPj9dK
         XGpU451FBMhIXEYOTEL/K1WA9hQgiWo5nFM5KjGXj+q57WG6WGuN6yDB1OV3OfZpE5zB
         2o/Q==
X-Gm-Message-State: AOJu0Yz7V3LQ8xqAr3fJGJednrOrNLIBYJFGvWcFLTHGUstfKjdFzUbY
	I30tZY5t8nI8FICnVQkBqr4FohIWaXL7j8pUhVbXonEcapNNxVnnZfT2WtTn
X-Gm-Gg: ASbGncthSXSzygqlqaZXUXV8sYdle3sfMDAUqE50in5S+RCrf1CfD6cFnZXnF5ti+Kw
	+pnzbSJR7C2hJ5QVo3LcnOImv78+rsg1dejKDYiBw2aUe3jpt93Bh8y9IdHNSUCY9ZtUspUcVs+
	bNp60kn0oOLHLrY0BcPetFmfmxamGCrsIYZqzE1WgUzBgBSr2z0q7xbb9mOdveNCZbpR63eBnLb
	0tSMQOa1WcYtStcNUNXozjZG4EHnjLkvRHxJxi5Wb0at3Ey8C4GE40yEQ==
X-Google-Smtp-Source: AGHT+IGZlEFSV35bKo9xoDZxbudY5hACznPdX4ioGucTYpB5Vt+XO/BnHvqtlSObDVsALXrcUlVShw==
X-Received: by 2002:a2e:bc0c:0:b0:302:23bd:354b with SMTP id 38308e7fff4ca-305eb1ac962mr20794211fa.1.1736334796007;
        Wed, 08 Jan 2025 03:13:16 -0800 (PST)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: [PATCH v1 3/9] arm/static-shmem.h: drop inclusion of asm/setup.h
Date: Wed,  8 Jan 2025 12:13:05 +0100
Message-ID: <2dd4477dd3224d00f43bbabc07f978c4e72f5a0f.1736334615.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <cover.1736334615.git.oleksii.kurochko@gmail.com>
References: <cover.1736334615.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Nothing is dependent from asm/setup.h in asm/static-shmem.h so inclusion of
asm/setup.h is droped.

After this drop the following compilation error related to impicit declaration
of the following functions device_tree_get_reg and map_device_irqs_to_domain,
device_tree_get_u32 occur during compilation of dom0less-build.c ( as they are
declared in asm/setup.h ).

Add inclusion of <asm/setup.h> in dt-overlay.c as it is using handle_device()
declared in <asm/setup.h>.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/arch/arm/dom0less-build.c           | 1 +
 xen/arch/arm/include/asm/static-shmem.h | 1 -
 xen/common/device-tree/dt-overlay.c     | 2 ++
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index c4badb4ade..259285ddda 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -14,6 +14,7 @@
 #include <asm/arm64/sve.h>
 #include <asm/dom0less-build.h>
 #include <asm/domain_build.h>
+#include <asm/setup.h>
 #include <asm/static-memory.h>
 #include <asm/static-shmem.h>
 
diff --git a/xen/arch/arm/include/asm/static-shmem.h b/xen/arch/arm/include/asm/static-shmem.h
index fd0867c4f2..828c8e5480 100644
--- a/xen/arch/arm/include/asm/static-shmem.h
+++ b/xen/arch/arm/include/asm/static-shmem.h
@@ -5,7 +5,6 @@
 
 #include <xen/types.h>
 #include <asm/kernel.h>
-#include <asm/setup.h>
 
 #ifdef CONFIG_STATIC_SHM
 
diff --git a/xen/common/device-tree/dt-overlay.c b/xen/common/device-tree/dt-overlay.c
index 97fb99eaaa..28bb9cf0cf 100644
--- a/xen/common/device-tree/dt-overlay.c
+++ b/xen/common/device-tree/dt-overlay.c
@@ -13,6 +13,8 @@
 #include <xen/libfdt/libfdt.h>
 #include <xen/xmalloc.h>
 
+#include <asm/setup.h>
+
 #define DT_OVERLAY_MAX_SIZE KB(500)
 
 static LIST_HEAD(overlay_tracker);
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 11:13:28 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 11:13:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867139.1278626 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVU04-0002uN-Ub; Wed, 08 Jan 2025 11:13:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867139.1278626; Wed, 08 Jan 2025 11:13:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVU04-0002tB-NU; Wed, 08 Jan 2025 11:13:24 +0000
Received: by outflank-mailman (input) for mailman id 867139;
 Wed, 08 Jan 2025 11:13: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
 <SRS0=WoWX=UA=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tVU03-0001BZ-5F
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 11:13:23 +0000
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com
 [2a00:1450:4864:20::234])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 926606e7-cdb1-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 12:13:22 +0100 (CET)
Received: by mail-lj1-x234.google.com with SMTP id
 38308e7fff4ca-30167f4c1e3so105804321fa.3
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 03:13:22 -0800 (PST)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-3045ad99d11sm67292171fa.33.2025.01.08.03.13.19
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 03:13:20 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 926606e7-cdb1-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736334801; x=1736939601; 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=ER/+mxB0CWJe1/Ae6aNRRXYkKAFXe/AIxI0Akw6x6FU=;
        b=exkvhNymIM0qCE5frP95CnTFiEnGtwy/Q5HbP0SZOcrbrTuGQ6Av1i1TpXEYPY4a4r
         PbkYKBSRQm60QSe7SmhvE4W7pJRpQOVHvnwG633SvOZxUgbyeHan5bwEOJIIwAB0Yiwe
         BsJn/T7t2+JZ15A0k0XHe9SWmKJvLUqYI17J6Y2KVP/9qZJWEm2EiuqsQNW9ENQjRC2i
         fzPblZ9EL4qvt3JOl384rR0GLo5pKsubLbVBH9J4fVDYhAtpJpjrpyjuywsaurJ9iEmA
         qXQ1PUeqdueSgRsJV9wrOGgcpeMbe95483gQcbaJPCsrRopYqNuVcejKoXEw1Fxp8N2y
         WxsA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736334801; x=1736939601;
        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=ER/+mxB0CWJe1/Ae6aNRRXYkKAFXe/AIxI0Akw6x6FU=;
        b=UXb84zOhp2rcxGPGrwUPlsRPi2Xn32fVCfWBfLrZr7SaRyxSWaYEfZrFVF14O98eTs
         d4uGJtlbp5Qcl5xzbCDiDj+gCsZK7D+wrOhDxYYp709pcr9oiiVkUrI5M7Y7ThYltoL0
         aUcJ23x/mX5xC57G+oa+Nq3RK1GJDRO6wbex0DjcchKC/YZCVVdOkcn3Z27wUMg/+Iph
         UTKyMQL8Z7zo+1rMPrLPn1R9dWERhXemA9ZFlPpWMhTNSE1UfTqwqyUEXwSezyEb6VWw
         AiM+md1lqjBGYq1lgHZPLrzDiucjUDnNXM1VOWH+KPgrDQhknvHGFHRH3GjtVq52w1Z+
         IqSg==
X-Gm-Message-State: AOJu0YwvNNQKeE2GtPbqP8wg2i+eB+9FY2VfDUJ+diahOSxsbYcHakxa
	HZ7ZQAu8UdEXffAifz9/2zgAaO7cA7EKzeWNQgFpDuGdB9iyY0OoaBZpggKi
X-Gm-Gg: ASbGncsrvWAJVJYz6seKock2EyUYATbW8hEeHqYvmDeDST6rCc7eHiT5RxhSPOAs7xP
	n/MstCzqeKvMCWkRYb36ipanr+fOpOKaU0sC1wdhuQ7u1h9dhKWJdSOdfpmJHsQmIMF3D0b2vuh
	0KmU45nXhv618VxPcIRWFq3Ii86fNgSPnD6xMevlvxizisUGZKA+mGXhZWGOd3S9gN29IBqj6Ey
	gODtilvGgzY4yDKL1QXVirGClduvOG1BhoSMCq/6qN4QV88y4hYnJZ5NQ==
X-Google-Smtp-Source: AGHT+IFiEzwr+MI445NGcgyjXXjMGNtN8f9qmcZxlCvs0GDA+OYXgjF+Fuke9f+ZG71rrZIXmAGLfA==
X-Received: by 2002:a05:651c:b21:b0:300:94b3:f26 with SMTP id 38308e7fff4ca-305f45db35bmr7736371fa.25.1736334800736;
        Wed, 08 Jan 2025 03:13:20 -0800 (PST)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PATCH v1 7/9] xen/common: dom0less: introduce common kernel.c
Date: Wed,  8 Jan 2025 12:13:09 +0100
Message-ID: <26ae1faf119585ebfb6ceb392918fe6960886e77.1736334615.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <cover.1736334615.git.oleksii.kurochko@gmail.com>
References: <cover.1736334615.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The following functions don't have arch specific things so it is moved to
common:
- kernel_prboe()
- kernel_load()
- output_length()

Functions necessary for dom0less are only moved.

The following changes are done:
- Swap __init and return type of kernel_decompress() function to be
  consistent with defintions of functions in other files. The same
  for output_length().
- Wrap by "ifdef CONFIG_ARM" the call of kernel_uimage_probe() in
  kernel_probe() as uImage isn't really used nowadays thereby leave
  kernel_uimage_probe() call here just for compatability with Arm code.
- Introduce kernel_zimage_probe() to cover the case that arch can have
  different zimage header.
- Add ASSERT() for kernel_load() to check that it argument isn't NULL.
- Make kernel_uimage_probe() non-static in Arm's code as it is used in
  common/kernel.c.

Introduce CONFIG_DOMAIN_BUILD_HELPERS to not provide stubs for archs
which doesn't provice enough functionality to enable it.
Select CONFIG_DOMAIN_BUILD_HELPERS for CONFIG_ARM as only Arm supports
it, at the moment.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/arch/arm/Kconfig             |   1 +
 xen/arch/arm/kernel.c            | 221 +---------------------------
 xen/common/Kconfig               |  11 +-
 xen/common/device-tree/Makefile  |   1 +
 xen/common/device-tree/kernel.c  | 242 +++++++++++++++++++++++++++++++
 xen/include/asm-generic/kernel.h |  13 ++
 6 files changed, 272 insertions(+), 217 deletions(-)
 create mode 100644 xen/common/device-tree/kernel.c

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index eff6ea6b6d..8a8681ef3b 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -12,6 +12,7 @@ config ARM_64
 
 config ARM
 	def_bool y
+	select DOMAIN_BUILD_HELPERS
 	select FUNCTION_ALIGNMENT_4B
 	select GENERIC_UART_INIT
 	select HAS_ALTERNATIVE if HAS_VMAP
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index b75bd6a887..8e5fd09c75 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -160,105 +160,6 @@ static void __init kernel_zimage_load(struct kernel_info *info)
     iounmap(kernel);
 }
 
-static __init uint32_t output_length(char *image, unsigned long image_len)
-{
-    return *(uint32_t *)&image[image_len - 4];
-}
-
-static __init int kernel_decompress(struct bootmodule *mod, uint32_t offset)
-{
-    char *output, *input;
-    char magic[2];
-    int rc;
-    unsigned int kernel_order_out;
-    paddr_t output_size;
-    struct page_info *pages;
-    mfn_t mfn;
-    int i;
-    paddr_t addr = mod->start;
-    paddr_t size = mod->size;
-
-    if ( size < offset )
-        return -EINVAL;
-
-    /*
-     * It might be that gzip header does not appear at the start address
-     * (e.g. in case of compressed uImage) so take into account offset to
-     * gzip header.
-     */
-    addr += offset;
-    size -= offset;
-
-    if ( size < 2 )
-        return -EINVAL;
-
-    copy_from_paddr(magic, addr, sizeof(magic));
-
-    /* only gzip is supported */
-    if ( !gzip_check(magic, size) )
-        return -EINVAL;
-
-    input = ioremap_cache(addr, size);
-    if ( input == NULL )
-        return -EFAULT;
-
-    output_size = output_length(input, size);
-    kernel_order_out = get_order_from_bytes(output_size);
-    pages = alloc_domheap_pages(NULL, kernel_order_out, 0);
-    if ( pages == NULL )
-    {
-        iounmap(input);
-        return -ENOMEM;
-    }
-    mfn = page_to_mfn(pages);
-    output = vmap_contig(mfn, 1 << kernel_order_out);
-
-    rc = perform_gunzip(output, input, size);
-    clean_dcache_va_range(output, output_size);
-    iounmap(input);
-    vunmap(output);
-
-    if ( rc )
-    {
-        free_domheap_pages(pages, kernel_order_out);
-        return rc;
-    }
-
-    mod->start = page_to_maddr(pages);
-    mod->size = output_size;
-
-    /*
-     * Need to free pages after output_size here because they won't be
-     * freed by discard_initial_modules
-     */
-    i = PFN_UP(output_size);
-    for ( ; i < (1 << kernel_order_out); i++ )
-        free_domheap_page(pages + i);
-
-    /*
-     * When using static heap feature, don't give bootmodules memory back to
-     * the heap allocator
-     */
-    if ( using_static_heap )
-        return 0;
-
-    /*
-     * When freeing the kernel, we need to pass the module start address and
-     * size as they were before taking an offset to gzip header into account,
-     * so that the entire region will be freed.
-     */
-    addr -= offset;
-    size += offset;
-
-    /*
-     * Free the original kernel, update the pointers to the
-     * decompressed kernel
-     */
-    fw_unreserved_regions(addr, addr + size, init_domheap_pages, 0);
-
-    return 0;
-}
-
 /*
  * Uimage CPU Architecture Codes
  */
@@ -271,8 +172,8 @@ static __init int kernel_decompress(struct bootmodule *mod, uint32_t offset)
 /*
  * Check if the image is a uImage and setup kernel_info
  */
-static int __init kernel_uimage_probe(struct kernel_info *info,
-                                      struct bootmodule *mod)
+int __init kernel_uimage_probe(struct kernel_info *info,
+                               struct bootmodule *mod)
 {
     struct {
         __be32 magic;   /* Image Header Magic Number */
@@ -502,130 +403,20 @@ static int __init kernel_zimage32_probe(struct kernel_info *info,
     return 0;
 }
 
-int __init kernel_probe(struct kernel_info *info,
-                        const struct dt_device_node *domain)
+int __init kernel_zimage_probe(struct kernel_info *info, paddr_t addr,
+                               paddr_t size)
 {
-    struct bootmodule *mod = NULL;
-    struct bootcmdline *cmd = NULL;
-    struct dt_device_node *node;
-    u64 kernel_addr, initrd_addr, dtb_addr, size;
     int rc;
 
-    /*
-     * We need to initialize start to 0. This field may be populated during
-     * kernel_xxx_probe() if the image has a fixed entry point (for e.g.
-     * uimage.ep).
-     * We will use this to determine if the image has a fixed entry point or
-     * the load address should be used as the start address.
-     */
-    info->entry = 0;
-
-    /* domain is NULL only for the hardware domain */
-    if ( domain == NULL )
-    {
-        ASSERT(is_hardware_domain(info->d));
-
-        mod = boot_module_find_by_kind(BOOTMOD_KERNEL);
-
-        info->kernel_bootmodule = mod;
-        info->initrd_bootmodule = boot_module_find_by_kind(BOOTMOD_RAMDISK);
-
-        cmd = boot_cmdline_find_by_kind(BOOTMOD_KERNEL);
-        if ( cmd )
-            info->cmdline = &cmd->cmdline[0];
-    }
-    else
-    {
-        const char *name = NULL;
-
-        dt_for_each_child_node(domain, node)
-        {
-            if ( dt_device_is_compatible(node, "multiboot,kernel") )
-            {
-                u32 len;
-                const __be32 *val;
-
-                val = dt_get_property(node, "reg", &len);
-                dt_get_range(&val, node, &kernel_addr, &size);
-                mod = boot_module_find_by_addr_and_kind(
-                        BOOTMOD_KERNEL, kernel_addr);
-                info->kernel_bootmodule = mod;
-            }
-            else if ( dt_device_is_compatible(node, "multiboot,ramdisk") )
-            {
-                u32 len;
-                const __be32 *val;
-
-                val = dt_get_property(node, "reg", &len);
-                dt_get_range(&val, node, &initrd_addr, &size);
-                info->initrd_bootmodule = boot_module_find_by_addr_and_kind(
-                        BOOTMOD_RAMDISK, initrd_addr);
-            }
-            else if ( dt_device_is_compatible(node, "multiboot,device-tree") )
-            {
-                uint32_t len;
-                const __be32 *val;
-
-                val = dt_get_property(node, "reg", &len);
-                if ( val == NULL )
-                    continue;
-                dt_get_range(&val, node, &dtb_addr, &size);
-                info->dtb_bootmodule = boot_module_find_by_addr_and_kind(
-                        BOOTMOD_GUEST_DTB, dtb_addr);
-            }
-            else
-                continue;
-        }
-        name = dt_node_name(domain);
-        cmd = boot_cmdline_find_by_name(name);
-        if ( cmd )
-            info->cmdline = &cmd->cmdline[0];
-    }
-    if ( !mod || !mod->size )
-    {
-        printk(XENLOG_ERR "Missing kernel boot module?\n");
-        return -ENOENT;
-    }
-
-    printk("Loading %pd kernel from boot module @ %"PRIpaddr"\n",
-           info->d, info->kernel_bootmodule->start);
-    if ( info->initrd_bootmodule )
-        printk("Loading ramdisk from boot module @ %"PRIpaddr"\n",
-               info->initrd_bootmodule->start);
-
-    /*
-     * uImage header always appears at the top of the image (even compressed),
-     * so it needs to be probed first. Note that in case of compressed uImage,
-     * kernel_decompress is called from kernel_uimage_probe making the function
-     * self-containing (i.e. fall through only in case of a header not found).
-     */
-    rc = kernel_uimage_probe(info, mod);
-    if ( rc != -ENOENT )
-        return rc;
-
-    /*
-     * If it is a gzip'ed image, 32bit or 64bit, uncompress it.
-     * At this point, gzip header appears (if at all) at the top of the image,
-     * so pass 0 as an offset.
-     */
-    rc = kernel_decompress(mod, 0);
-    if ( rc && rc != -EINVAL )
-        return rc;
-
 #ifdef CONFIG_ARM_64
-    rc = kernel_zimage64_probe(info, mod->start, mod->size);
+    rc = kernel_zimage64_probe(info, addr, size);
     if (rc < 0)
 #endif
-        rc = kernel_zimage32_probe(info, mod->start, mod->size);
+        rc = kernel_zimage32_probe(info, addr, size);
 
     return rc;
 }
 
-void __init kernel_load(struct kernel_info *info)
-{
-    info->load(info);
-}
-
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 099e6e72ad..83f8a8f791 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -14,13 +14,20 @@ config CORE_PARKING
 
 config DOM0LESS_BOOT
 	bool "Dom0less boot support" if EXPERT
-	depends on ARM
-	default ARM
+	depends on DOMAIN_BUILD_HELPERS
+	default DOMAIN_BUILD_HELPERS
 	help
 	  Dom0less boot support enables Xen to create and start domU guests during
 	  Xen boot without the need of a control domain (Dom0), which could be
 	  present anyway.
 
+config DOMAIN_BUILD_HELPERS
+	bool
+	help
+	  Introduce functions necessary for working with domain creation, kernel,
+	  etc. As an examples, these type of functions are going to be used by
+	  CONFIG_DOM0LESS_BOOT.
+
 config GRANT_TABLE
 	bool "Grant table support" if EXPERT
 	default y
diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
index f3dafc9b81..e88a4d5799 100644
--- a/xen/common/device-tree/Makefile
+++ b/xen/common/device-tree/Makefile
@@ -4,3 +4,4 @@ obj-y += device-tree.o
 obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.o
 obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o
 obj-y += intc.o
+obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += kernel.o
diff --git a/xen/common/device-tree/kernel.c b/xen/common/device-tree/kernel.c
new file mode 100644
index 0000000000..bd5d968bfd
--- /dev/null
+++ b/xen/common/device-tree/kernel.c
@@ -0,0 +1,242 @@
+#include <xen/bootfdt.h>
+#include <xen/device_tree.h>
+#include <xen/errno.h>
+#include <xen/gunzip.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/mm.h>
+#include <xen/pfn.h>
+#include <xen/sched.h>
+#include <xen/types.h>
+#include <xen/vmap.h>
+
+#include <asm/kernel.h>
+#include <asm/page.h>
+#include <asm/setup.h>
+
+static uint32_t __init output_length(char *image, unsigned long image_len)
+{
+    return *(uint32_t *)&image[image_len - 4];
+}
+
+int __init kernel_decompress(struct bootmodule *mod, uint32_t offset)
+{
+    char *output, *input;
+    char magic[2];
+    int rc;
+    unsigned int kernel_order_out;
+    paddr_t output_size;
+    struct page_info *pages;
+    mfn_t mfn;
+    int i;
+    paddr_t addr = mod->start;
+    paddr_t size = mod->size;
+
+    if ( size < offset )
+        return -EINVAL;
+
+    /*
+     * It might be that gzip header does not appear at the start address
+     * (e.g. in case of compressed uImage) so take into account offset to
+     * gzip header.
+     */
+    addr += offset;
+    size -= offset;
+
+    if ( size < 2 )
+        return -EINVAL;
+
+    copy_from_paddr(magic, addr, sizeof(magic));
+
+    /* only gzip is supported */
+    if ( !gzip_check(magic, size) )
+        return -EINVAL;
+
+    input = ioremap_cache(addr, size);
+    if ( input == NULL )
+        return -EFAULT;
+
+    output_size = output_length(input, size);
+    kernel_order_out = get_order_from_bytes(output_size);
+    pages = alloc_domheap_pages(NULL, kernel_order_out, 0);
+    if ( pages == NULL )
+    {
+        iounmap(input);
+        return -ENOMEM;
+    }
+    mfn = page_to_mfn(pages);
+    output = vmap_contig(mfn, 1 << kernel_order_out);
+
+    rc = perform_gunzip(output, input, size);
+    clean_dcache_va_range(output, output_size);
+    iounmap(input);
+    vunmap(output);
+
+    if ( rc )
+    {
+        free_domheap_pages(pages, kernel_order_out);
+        return rc;
+    }
+
+    mod->start = page_to_maddr(pages);
+    mod->size = output_size;
+
+    /*
+     * Need to free pages after output_size here because they won't be
+     * freed by discard_initial_modules
+     */
+    i = PFN_UP(output_size);
+    for ( ; i < (1 << kernel_order_out); i++ )
+        free_domheap_page(pages + i);
+
+    /*
+     * When using static heap feature, don't give bootmodules memory back to
+     * the heap allocator
+     */
+    if ( using_static_heap )
+        return 0;
+
+    /*
+     * When freeing the kernel, we need to pass the module start address and
+     * size as they were before taking an offset to gzip header into account,
+     * so that the entire region will be freed.
+     */
+    addr -= offset;
+    size += offset;
+
+    /*
+     * Free the original kernel, update the pointers to the
+     * decompressed kernel
+     */
+    fw_unreserved_regions(addr, addr + size, init_domheap_pages, 0);
+
+    return 0;
+}
+
+int __init kernel_probe(struct kernel_info *info,
+                        const struct dt_device_node *domain)
+{
+    struct bootmodule *mod = NULL;
+    struct bootcmdline *cmd = NULL;
+    struct dt_device_node *node;
+    u64 kernel_addr, initrd_addr, dtb_addr, size;
+    int rc;
+
+    /*
+     * We need to initialize start to 0. This field may be populated during
+     * kernel_xxx_probe() if the image has a fixed entry point (for e.g.
+     * uimage.ep).
+     * We will use this to determine if the image has a fixed entry point or
+     * the load address should be used as the start address.
+     */
+    info->entry = 0;
+
+    /* domain is NULL only for the hardware domain */
+    if ( domain == NULL )
+    {
+        ASSERT(is_hardware_domain(info->d));
+
+        mod = boot_module_find_by_kind(BOOTMOD_KERNEL);
+
+        info->kernel_bootmodule = mod;
+        info->initrd_bootmodule = boot_module_find_by_kind(BOOTMOD_RAMDISK);
+
+        cmd = boot_cmdline_find_by_kind(BOOTMOD_KERNEL);
+        if ( cmd )
+            info->cmdline = &cmd->cmdline[0];
+    }
+    else
+    {
+        const char *name = NULL;
+
+        dt_for_each_child_node(domain, node)
+        {
+            if ( dt_device_is_compatible(node, "multiboot,kernel") )
+            {
+                u32 len;
+                const __be32 *val;
+
+                val = dt_get_property(node, "reg", &len);
+                dt_get_range(&val, node, &kernel_addr, &size);
+                mod = boot_module_find_by_addr_and_kind(
+                        BOOTMOD_KERNEL, kernel_addr);
+                info->kernel_bootmodule = mod;
+            }
+            else if ( dt_device_is_compatible(node, "multiboot,ramdisk") )
+            {
+                u32 len;
+                const __be32 *val;
+
+                val = dt_get_property(node, "reg", &len);
+                dt_get_range(&val, node, &initrd_addr, &size);
+                info->initrd_bootmodule = boot_module_find_by_addr_and_kind(
+                        BOOTMOD_RAMDISK, initrd_addr);
+            }
+            else if ( dt_device_is_compatible(node, "multiboot,device-tree") )
+            {
+                uint32_t len;
+                const __be32 *val;
+
+                val = dt_get_property(node, "reg", &len);
+                if ( val == NULL )
+                    continue;
+                dt_get_range(&val, node, &dtb_addr, &size);
+                info->dtb_bootmodule = boot_module_find_by_addr_and_kind(
+                        BOOTMOD_GUEST_DTB, dtb_addr);
+            }
+            else
+                continue;
+        }
+        name = dt_node_name(domain);
+        cmd = boot_cmdline_find_by_name(name);
+        if ( cmd )
+            info->cmdline = &cmd->cmdline[0];
+    }
+    if ( !mod || !mod->size )
+    {
+        printk(XENLOG_ERR "Missing kernel boot module?\n");
+        return -ENOENT;
+    }
+
+    printk("Loading %pd kernel from boot module @ %"PRIpaddr"\n",
+           info->d, info->kernel_bootmodule->start);
+    if ( info->initrd_bootmodule )
+        printk("Loading ramdisk from boot module @ %"PRIpaddr"\n",
+               info->initrd_bootmodule->start);
+
+    /*
+     * uImage isn't really used nowadays thereby leave kernel_uimage_probe()
+     * call here just for compatability with Arm code.
+     */
+#ifdef CONFIG_ARM
+    /*
+     * uImage header always appears at the top of the image (even compressed),
+     * so it needs to be probed first. Note that in case of compressed uImage,
+     * kernel_decompress is called from kernel_uimage_probe making the function
+     * self-containing (i.e. fall through only in case of a header not found).
+     */
+    rc = kernel_uimage_probe(info, mod);
+    if ( rc != -ENOENT )
+        return rc;
+#endif
+
+    /*
+     * If it is a gzip'ed image, 32bit or 64bit, uncompress it.
+     * At this point, gzip header appears (if at all) at the top of the image,
+     * so pass 0 as an offset.
+     */
+    rc = kernel_decompress(mod, 0);
+    if ( rc && rc != -EINVAL )
+        return rc;
+
+    rc = kernel_zimage_probe(info, mod->start, mod->size);
+
+    return rc;
+}
+
+void __init kernel_load(struct kernel_info *info)
+{
+    ASSERT(info && info->load);
+
+    info->load(info);
+}
diff --git a/xen/include/asm-generic/kernel.h b/xen/include/asm-generic/kernel.h
index b2bd04a185..d668c7ef4f 100644
--- a/xen/include/asm-generic/kernel.h
+++ b/xen/include/asm-generic/kernel.h
@@ -134,6 +134,19 @@ int kernel_probe(struct kernel_info *info, const struct dt_device_node *domain);
  */
 void kernel_load(struct kernel_info *info);
 
+int kernel_decompress(struct bootmodule *mod, uint32_t offset);
+
+int kernel_zimage_probe(struct kernel_info *info, paddr_t addr, paddr_t size);
+
+/*
+ * uImage isn't really used nowadays thereby leave kernel_uimage_probe()
+ * call here just for compatability with Arm code.
+ */
+#ifdef CONFIG_ARM
+struct bootmodule;
+int kernel_uimage_probe(struct kernel_info *info, struct bootmodule *mod);
+#endif
+
 #endif /*__ASM_GENERIC_KERNEL_H__ */
 
 /*
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 11:13:28 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 11:13:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867138.1278612 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVU03-0002Se-Fy; Wed, 08 Jan 2025 11:13:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867138.1278612; Wed, 08 Jan 2025 11:13:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVU03-0002RA-5c; Wed, 08 Jan 2025 11:13:23 +0000
Received: by outflank-mailman (input) for mailman id 867138;
 Wed, 08 Jan 2025 11:13:21 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=WoWX=UA=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tVU01-0001rx-Qb
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 11:13:21 +0000
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com
 [2a00:1450:4864:20::22c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 90e76a96-cdb1-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 12:13:19 +0100 (CET)
Received: by mail-lj1-x22c.google.com with SMTP id
 38308e7fff4ca-30034ad2ca3so151217771fa.1
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 03:13:19 -0800 (PST)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-3045ad99d11sm67292171fa.33.2025.01.08.03.13.17
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 03:13:18 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 90e76a96-cdb1-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736334799; x=1736939599; 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=u2DRwW9ezeHyV+LdRXJNVZEHINyASGcXSyx28i5zUEk=;
        b=TS5eFIaZWc2uEA8au516hwoLBqp/cAbVptNY/yVs/xQrYI/K1Kzs0doZWyVqYEv8B1
         XP1W0t6R1KhPh/5PrsC6xFuLe4LeV6GcKH3adhTlI0aPxyrbp89II8jcniUAenY/5lTQ
         mLzTnfANXSY6VHPY+4mlV6mAzRVrchgpcCZhb0ruWX54ilWZmRwf5DMwo1nDQddbH9NM
         S5QrU/RwuJp2VplDm4QgXGcyJ2Gz1W38YF0T8q8gbExtXTnN1yKpYbfrR0CyQdfwhzmb
         /dyF49jqPOl2TCTTAbaOznZDxwQJBhcNT4FEiQuGAWQyC3tZQLPLL+hqVRvTqWFbj40j
         hUPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736334799; x=1736939599;
        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=u2DRwW9ezeHyV+LdRXJNVZEHINyASGcXSyx28i5zUEk=;
        b=GY9oItByxVOdGbIEM06Qz3G+VE1zzDB/Swpbk5F0be5lah/CXkyeLFYLGXeTZcAtBh
         gVqgxhn1OhLSYluL3WHR4yJYy7s5SvXcbxKJtlSsiRg85q9oBiJXOItjNALU7V1b4aq6
         pFWSe2JEdWTPVyc9GQ3bxacogD6pwhmC1dTwGmxBZD19TNNEBDg1k+/245tdsr4Ha++S
         3nBcnvQGteOGEoB+ddjh0S9dKd1TE7HCtSiArZOEJMh2DmI5rDasip0GbZkIF4w4/aug
         2YIgcE5eJXcJw0F38y/AFTxIxOnc9lpLqI7yRfKmyL/X5DclIWHgnhNqUXPR+IFH/gPS
         oh1g==
X-Gm-Message-State: AOJu0YyyljeKDjuISuJpPKx6+/y2uxXhJ51MI4cnNtEIX1C6YT1So17D
	5q3/0QUnRbzA3k3Z6smLXuQmHlWzRV/RP3ZoyYdqbRd36G2SQhg76f8EJAWq
X-Gm-Gg: ASbGncsCUMCO6/1QHsrBQwh8ITPPBz+EwoA+IU56HSydVB//QNWzT0085x5RJmMiXBK
	id2N69RoVDF6u06PauZ09odFP2sfjexkv6THtvrDxhh70xIiInpI9F65JFPsXJ3O5/sJQp1HDw0
	j7z4E0qOvbxsTr0r/7Gq/q41OvJqzBVUPoHMEJ3HAt/HXc6+k4YSa/DXfvEvFf9jVhAfn8yhkuC
	a9voJ2RVaatpqdPIUOh32QF75IHzRNrB1+u+J7FbcihhU8xcKMSuyTcrA==
X-Google-Smtp-Source: AGHT+IG+qDjYgt2Gr62pg6Xnv/ZqvLYxmQ5L3XyRVscSUI+HT8/n6r626LNrsrSWfozbDr/qW9BejA==
X-Received: by 2002:a2e:bc28:0:b0:302:4171:51f0 with SMTP id 38308e7fff4ca-305f445cc8dmr5983551fa.0.1736334798706;
        Wed, 08 Jan 2025 03:13:18 -0800 (PST)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PATCH v1 5/9] asm-generic: move Arm's static-shmem.h to asm-generic
Date: Wed,  8 Jan 2025 12:13:07 +0100
Message-ID: <0203b98aa6a42aa69e22e7c973320add3ff4bb5d.1736334615.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <cover.1736334615.git.oleksii.kurochko@gmail.com>
References: <cover.1736334615.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Except moving Arm's static-shmem.h to asm-generic #ifdef header guard
is updated: s/__ASM_SHMEM_MEMORY_H_/__ASM_GENERIC_SHMEM_MEMORY_H__.

Update arm/include/asm/Makefile to use asm-generic version of
static-shmem.h for Arm.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/arch/arm/include/asm/Makefile       |   1 +
 xen/arch/arm/include/asm/static-shmem.h | 117 ------------------------
 xen/include/asm-generic/static-shmem.h  | 117 ++++++++++++++++++++++++
 3 files changed, 118 insertions(+), 117 deletions(-)
 delete mode 100644 xen/arch/arm/include/asm/static-shmem.h
 create mode 100644 xen/include/asm-generic/static-shmem.h

diff --git a/xen/arch/arm/include/asm/Makefile b/xen/arch/arm/include/asm/Makefile
index ac8208a81f..9cec55606e 100644
--- a/xen/arch/arm/include/asm/Makefile
+++ b/xen/arch/arm/include/asm/Makefile
@@ -9,4 +9,5 @@ generic-y += percpu.h
 generic-y += random.h
 generic-y += softirq.h
 generic-y += static-memory.h
+generic-y += static-shmem.h
 generic-y += vm_event.h
diff --git a/xen/arch/arm/include/asm/static-shmem.h b/xen/arch/arm/include/asm/static-shmem.h
deleted file mode 100644
index 828c8e5480..0000000000
--- a/xen/arch/arm/include/asm/static-shmem.h
+++ /dev/null
@@ -1,117 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
-
-#ifndef __ASM_STATIC_SHMEM_H_
-#define __ASM_STATIC_SHMEM_H_
-
-#include <xen/types.h>
-#include <asm/kernel.h>
-
-#ifdef CONFIG_STATIC_SHM
-
-/* Worst case /memory node reg element: (addrcells + sizecells) */
-#define DT_MEM_NODE_REG_RANGE_SIZE ((NR_MEM_BANKS + NR_SHMEM_BANKS) * 4)
-
-int make_resv_memory_node(const struct kernel_info *kinfo, int addrcells,
-                          int sizecells);
-
-int process_shm(struct domain *d, struct kernel_info *kinfo,
-                const struct dt_device_node *node);
-
-static inline int process_shm_chosen(struct domain *d,
-                                     struct kernel_info *kinfo)
-{
-    const struct dt_device_node *node = dt_find_node_by_path("/chosen");
-
-    return process_shm(d, kinfo, node);
-}
-
-int process_shm_node(const void *fdt, int node, uint32_t address_cells,
-                     uint32_t size_cells);
-
-void early_print_info_shmem(void);
-
-void init_sharedmem_pages(void);
-
-int remove_shm_from_rangeset(const struct kernel_info *kinfo,
-                             struct rangeset *rangeset);
-
-int remove_shm_holes_for_domU(const struct kernel_info *kinfo,
-                              struct membanks *ext_regions);
-
-int make_shm_resv_memory_node(const struct kernel_info *kinfo, int addrcells,
-                              int sizecells);
-
-void shm_mem_node_fill_reg_range(const struct kernel_info *kinfo, __be32 *reg,
-                                 int *nr_cells, int addrcells, int sizecells);
-
-static inline struct membanks *
-kernel_info_get_shm_mem(struct kernel_info *kinfo)
-{
-    return container_of(&kinfo->shm_mem.common, struct membanks, common);
-}
-
-static inline const struct membanks *
-kernel_info_get_shm_mem_const(const struct kernel_info *kinfo)
-{
-    return container_of(&kinfo->shm_mem.common, const struct membanks, common);
-}
-
-#else /* !CONFIG_STATIC_SHM */
-
-/* Worst case /memory node reg element: (addrcells + sizecells) */
-#define DT_MEM_NODE_REG_RANGE_SIZE (NR_MEM_BANKS * 4)
-
-static inline int make_resv_memory_node(const struct kernel_info *kinfo,
-                                        int addrcells, int sizecells)
-{
-    return 0;
-}
-
-static inline int process_shm(struct domain *d, struct kernel_info *kinfo,
-                              const struct dt_device_node *node)
-{
-    return 0;
-}
-
-static inline int process_shm_chosen(struct domain *d,
-                                     struct kernel_info *kinfo)
-{
-    return 0;
-}
-
-static inline void init_sharedmem_pages(void) {};
-
-static inline int remove_shm_from_rangeset(const struct kernel_info *kinfo,
-                                           struct rangeset *rangeset)
-{
-    return 0;
-}
-
-static inline int remove_shm_holes_for_domU(const struct kernel_info *kinfo,
-                                            struct membanks *ext_regions)
-{
-    return 0;
-}
-
-static inline int make_shm_resv_memory_node(const struct kernel_info *kinfo,
-                                            int addrcells, int sizecells)
-{
-    return 0;
-}
-
-static inline void shm_mem_node_fill_reg_range(const struct kernel_info *kinfo,
-                                               __be32 *reg, int *nr_cells,
-                                               int addrcells, int sizecells) {};
-
-#endif /* CONFIG_STATIC_SHM */
-
-#endif /* __ASM_STATIC_SHMEM_H_ */
-
-/*
- * Local variables:
- * mode: C
- * c-file-style: "BSD"
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/xen/include/asm-generic/static-shmem.h b/xen/include/asm-generic/static-shmem.h
new file mode 100644
index 0000000000..7c83cb6195
--- /dev/null
+++ b/xen/include/asm-generic/static-shmem.h
@@ -0,0 +1,117 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef __ASM_GENERIC_STATIC_SHMEM_H__
+#define __ASM_GENERIC_STATIC_SHMEM_H__
+
+#include <xen/types.h>
+#include <asm/kernel.h>
+
+#ifdef CONFIG_STATIC_SHM
+
+/* Worst case /memory node reg element: (addrcells + sizecells) */
+#define DT_MEM_NODE_REG_RANGE_SIZE ((NR_MEM_BANKS + NR_SHMEM_BANKS) * 4)
+
+int make_resv_memory_node(const struct kernel_info *kinfo, int addrcells,
+                          int sizecells);
+
+int process_shm(struct domain *d, struct kernel_info *kinfo,
+                const struct dt_device_node *node);
+
+static inline int process_shm_chosen(struct domain *d,
+                                     struct kernel_info *kinfo)
+{
+    const struct dt_device_node *node = dt_find_node_by_path("/chosen");
+
+    return process_shm(d, kinfo, node);
+}
+
+int process_shm_node(const void *fdt, int node, uint32_t address_cells,
+                     uint32_t size_cells);
+
+void early_print_info_shmem(void);
+
+void init_sharedmem_pages(void);
+
+int remove_shm_from_rangeset(const struct kernel_info *kinfo,
+                             struct rangeset *rangeset);
+
+int remove_shm_holes_for_domU(const struct kernel_info *kinfo,
+                              struct membanks *ext_regions);
+
+int make_shm_resv_memory_node(const struct kernel_info *kinfo, int addrcells,
+                              int sizecells);
+
+void shm_mem_node_fill_reg_range(const struct kernel_info *kinfo, __be32 *reg,
+                                 int *nr_cells, int addrcells, int sizecells);
+
+static inline struct membanks *
+kernel_info_get_shm_mem(struct kernel_info *kinfo)
+{
+    return container_of(&kinfo->shm_mem.common, struct membanks, common);
+}
+
+static inline const struct membanks *
+kernel_info_get_shm_mem_const(const struct kernel_info *kinfo)
+{
+    return container_of(&kinfo->shm_mem.common, const struct membanks, common);
+}
+
+#else /* !CONFIG_STATIC_SHM */
+
+/* Worst case /memory node reg element: (addrcells + sizecells) */
+#define DT_MEM_NODE_REG_RANGE_SIZE (NR_MEM_BANKS * 4)
+
+static inline int make_resv_memory_node(const struct kernel_info *kinfo,
+                                        int addrcells, int sizecells)
+{
+    return 0;
+}
+
+static inline int process_shm(struct domain *d, struct kernel_info *kinfo,
+                              const struct dt_device_node *node)
+{
+    return 0;
+}
+
+static inline int process_shm_chosen(struct domain *d,
+                                     struct kernel_info *kinfo)
+{
+    return 0;
+}
+
+static inline void init_sharedmem_pages(void) {};
+
+static inline int remove_shm_from_rangeset(const struct kernel_info *kinfo,
+                                           struct rangeset *rangeset)
+{
+    return 0;
+}
+
+static inline int remove_shm_holes_for_domU(const struct kernel_info *kinfo,
+                                            struct membanks *ext_regions)
+{
+    return 0;
+}
+
+static inline int make_shm_resv_memory_node(const struct kernel_info *kinfo,
+                                            int addrcells, int sizecells)
+{
+    return 0;
+}
+
+static inline void shm_mem_node_fill_reg_range(const struct kernel_info *kinfo,
+                                               __be32 *reg, int *nr_cells,
+                                               int addrcells, int sizecells) {};
+
+#endif /* CONFIG_STATIC_SHM */
+
+#endif /* __ASM_GENERIC_STATIC_SHMEM_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 11:13:28 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 11:13:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867132.1278555 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVTzy-0001Bw-Ai; Wed, 08 Jan 2025 11:13:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867132.1278555; Wed, 08 Jan 2025 11:13:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVTzy-0001Bp-7o; Wed, 08 Jan 2025 11:13:18 +0000
Received: by outflank-mailman (input) for mailman id 867132;
 Wed, 08 Jan 2025 11:13:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=WoWX=UA=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tVTzw-0001BZ-RO
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 11:13:16 +0000
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com
 [2a00:1450:4864:20::133])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8e3ef810-cdb1-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 12:13:15 +0100 (CET)
Received: by mail-lf1-x133.google.com with SMTP id
 2adb3069b0e04-5401c68b89eso823273e87.0
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 03:13:15 -0800 (PST)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-3045ad99d11sm67292171fa.33.2025.01.08.03.13.12
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 03:13:13 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8e3ef810-cdb1-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736334794; x=1736939594; 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=IOZRW2Zgzg/+jR+GpKJJKd2ekyGU1NKlwVnXrW58R3M=;
        b=E5QFXiJQ0KXZNZ2os7TPbvXqROP7KVSd90iYMTUmYAXh+jwulEqdSNNG5/53KcNCkR
         I/MN5gMgwC5+ySnDHnnv7HsMX/V4RwjSNwEvdVihCEgqci71KI0YplNFT0F4rzQKRm7I
         elJK09Gieu9RXkYQGSVuZWZzeudD0RhPgsJTGPvJjZDzLozOMHsOpWsnnF9YQOTVAO+6
         VPnHGvnyaetyQGHtcfctSUzZnoQd82UIMzr4i3lAWcQ8ekJuPF4Rq3YYqbL9K9Y7rvsy
         jJ8ZWOZejAkIyaX7T1FepxsuFIk5ooPN8hcksgkF4W+GJpKsg66UKf7uN138ZRBxJW/n
         XzGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736334794; x=1736939594;
        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=IOZRW2Zgzg/+jR+GpKJJKd2ekyGU1NKlwVnXrW58R3M=;
        b=N7znc5OtyyG8h6VYTtYCoNH01L8eazT5URyzs5IJC1M7lx1qRRnF5cENOTcr3afEDi
         yvsZ/Ab+5wxsFkZ2SWLYYWOMY0NaiI4iTF9Z1fVyj+B+wbCE6a79bxByzsBDJ4ILZ7xm
         UX89qPqBInb9KsIse/pwyFPJ6UntY1L7Yh0cis6oeLCsFHyk50P1KbYeoYVLlR34Drmj
         K7rb9xTM/OC5w3Ku1XMKoYEhA0jSqJi/1zXrKmOph7cUZdgzvHN21Ds9rGMQ0NrBgma5
         /nHmM5pAo9jgN1TGwhZScXzU3QQmA6gum0/mPHlbiVBAaCwCwkkmbCAlww0R9UX0wCIF
         +xjQ==
X-Gm-Message-State: AOJu0YxXVVhwdBORCuAG4++wQVlyyv7nvAcWgOb4FuSUZcs454My/sqT
	X4DNjKBglB4HgxlsNnT3Ofx3z55jgo7PegoSYmwCOh2WWy4oLIyqEyr42iu6
X-Gm-Gg: ASbGncuY+ZZYHk05NAokpqbWKo/MXd8UWGLopATtlqn8Tgbz5pk24o5IcwmLKiwi2JC
	H+VKegu95dBzpO0lfGLjeAt1AJPMBlHEuDq0Hlsq09+t9jIAhwO3+0EUy/0FbFBB/3+3LamZmz5
	9asEHMOvOU8CCbe3hoQsoU5WUL9DhhXr2sSvpktjXMxBOm8f6r5nhQRYC+zgXHpuXhXqpkVzYvF
	QHpFDtWs9czYfyZFy3gVu/X34syxBqAiHsUNIZKJGm4mu9i600md9Vb/w==
X-Google-Smtp-Source: AGHT+IHUcYNbBfLm9+kG2OUudFDWwXStLl3O6nt3KtAU5JVFVUiPiUn5VwVNnFPIYmo4V44e7C1o9w==
X-Received: by 2002:a19:6b07:0:b0:542:7f20:a110 with SMTP id 2adb3069b0e04-5427f20a157mr1214715e87.4.1736334793586;
        Wed, 08 Jan 2025 03:13:13 -0800 (PST)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PATCH for 4.21 v1 0/9] Move parts of Arm's Dom0less to common code
Date: Wed,  8 Jan 2025 12:13:02 +0100
Message-ID: <cover.1736334615.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.47.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Some parts of Arm's Dom0less solution could be moved to common code as they are
not truly Arm-specific.

Most of the code is moved as is, with only minor changes introduced to provide
abstractions that hide Arm-specific details, while maintaining functional
equivalence with original Arm's code.

There are several open questions:
1. Probably, the introduced headers currently placed in asm-generic should
   instead reside in the xen/include folder.
2. Perhaps the introduced *.c files should always be placed elsewhere. They
   have been put in device-tree common as they somewhat depend on device tree
   functionality.
3. The u64 and u32 types are widely used in the code where device tree
   functionality is implemented because these types are used in device tree
   function arguments.
   Should this be reworked to use uint32_t and uint64_t instead? If so, will it
   also be necessary to change the type of variables passed to dt-related
   functions, or should the argument types of device tree functions be updated
   too? For example:
   ```
    u64 mem;
    ...
    rc = dt_property_read_u64(node, "memory", &mem);
   ```
   where dt_property_read_u64 is declared as:
     bool dt_property_read_u64(... , u64 *out_value);
4. Instead of providing init_intc_phandle() (see the patch: [1]), perhaps it
   would be better to add a for loop in domain_handle_dtb_bootmodule()?
   Something like:
   ```
    bool is_intc_phandle_inited = false;
    for ( unsigned int i = 0; i < ARRAY_SIZE(intc_names_array); i++ )
    {
        if ( dt_node_cmp(name, intc_names_array[i]) == 0 )
        {
            uint32_t phandle_intc = fdt_get_phandle(pfdt, node_next);

            if ( phandle_intc != 0 )
                kinfo->phandle_intc = phandle_intc;

            is_intc_phandle_inited = true;
            break;
        }
    }

    if ( is_intc_phandle_inited ) continue;
  ```
5. If some function prototypes are moved from asm/* headers, the inclusion of
   arch-specific headers (asm/*.h) could potentially be dropped. For example,
   if we examine common/device-tree/kernel.c, the following inclusions exist:
   - <asm/setup.h>: Included because of the use of copy_from_paddr(). The name
     copy_from_paddr() seems generic enough, so it might make sense to move it
     to a common header.
   - <asm/page.h>: Included because of clean_dcache_va_range(). This function
     is already used in common code in grant_table.c, so its prototype should
     be placed in a common header.
   - asm/kernel.h: Included because of struct kernel_info, which could also be
     a candidate to be moved to a common header.

[1] [PATCH v1 9/9] xen/common: dom0less: introduce common dom0less-build.c

Oleksii Kurochko (9):
  xen/common: dom0less: make some parts of Arm's CONFIG_DOM0LESS common
  asm-generic: move parts of Arm's asm/kernel.h to asm-generic
  arm/static-shmem.h: drop inclusion of asm/setup.h
  asm-generic: move Arm's static-memory.h to asm-generic
  asm-generic: move Arm's static-shmem.h to asm-generic
  asm-generic: move some parts of Arm's domain_build.h to asm-generic
    header
  xen/common: dom0less: introduce common kernel.c
  xen/common: dom0less: introduce common domain-build.c
  xen/common: dom0less: introduce common dom0less-build.c

 xen/arch/arm/Kconfig                      |   9 +-
 xen/arch/arm/dom0less-build.c             | 842 +++-------------------
 xen/arch/arm/domain_build.c               | 410 +----------
 xen/arch/arm/include/asm/Makefile         |   4 +
 xen/arch/arm/include/asm/dom0less-build.h |  32 -
 xen/arch/arm/include/asm/domain_build.h   |  19 +-
 xen/arch/arm/include/asm/kernel.h         | 115 +--
 xen/arch/arm/include/asm/static-memory.h  |  58 --
 xen/arch/arm/include/asm/static-shmem.h   | 118 ---
 xen/arch/arm/kernel.c                     | 231 +-----
 xen/arch/arm/static-memory.c              |   1 +
 xen/arch/arm/static-shmem.c               |   1 +
 xen/common/Kconfig                        |  16 +
 xen/common/device-tree/Makefile           |   3 +
 xen/common/device-tree/dom0less-build.c   | 720 ++++++++++++++++++
 xen/common/device-tree/domain-build.c     | 405 +++++++++++
 xen/common/device-tree/dt-overlay.c       |   2 +
 xen/common/device-tree/kernel.c           | 242 +++++++
 xen/include/asm-generic/dom0less-build.h  |  54 ++
 xen/include/asm-generic/domain-build.h    |  72 ++
 xen/include/asm-generic/kernel.h          | 159 ++++
 xen/include/asm-generic/static-memory.h   |  58 ++
 xen/include/asm-generic/static-shmem.h    | 117 +++
 23 files changed, 1986 insertions(+), 1702 deletions(-)
 delete mode 100644 xen/arch/arm/include/asm/dom0less-build.h
 delete mode 100644 xen/arch/arm/include/asm/static-memory.h
 delete mode 100644 xen/arch/arm/include/asm/static-shmem.h
 create mode 100644 xen/common/device-tree/dom0less-build.c
 create mode 100644 xen/common/device-tree/domain-build.c
 create mode 100644 xen/common/device-tree/kernel.c
 create mode 100644 xen/include/asm-generic/dom0less-build.h
 create mode 100644 xen/include/asm-generic/domain-build.h
 create mode 100644 xen/include/asm-generic/kernel.h
 create mode 100644 xen/include/asm-generic/static-memory.h
 create mode 100644 xen/include/asm-generic/static-shmem.h

-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 11:13:28 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 11:13:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867137.1278606 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVU02-0002Ok-W2; Wed, 08 Jan 2025 11:13:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867137.1278606; Wed, 08 Jan 2025 11:13:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVU02-0002OZ-SW; Wed, 08 Jan 2025 11:13:22 +0000
Received: by outflank-mailman (input) for mailman id 867137;
 Wed, 08 Jan 2025 11:13:21 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=WoWX=UA=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tVU01-0001rx-Jg
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 11:13:21 +0000
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com
 [2a00:1450:4864:20::229])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 903a0692-cdb1-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 12:13:18 +0100 (CET)
Received: by mail-lj1-x229.google.com with SMTP id
 38308e7fff4ca-30036310158so151006751fa.0
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 03:13:18 -0800 (PST)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-3045ad99d11sm67292171fa.33.2025.01.08.03.13.16
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 03:13:16 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 903a0692-cdb1-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736334798; x=1736939598; 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=5OTB8W0BPYwoUOycX2jvVwt68tOgnvevPd13hEZlyfg=;
        b=OlZmmvttJ3hJkrO4bh2zS8lrbLl8K7i42ezTnZASqKx/P14RPtikJ+L9OhdwiuY4Xj
         EHp6ZqfKTo/Uzgpkr9jrQqH7KNG61DG8rDoLxy7sbF8slaNekypn/kD82H9Ce6Wfy0O5
         v8WNBOMqxCDJfosZiHisVVihdCeeEqAmF6+Ww0PnmY2fhiI4cfho8/DhJLK32GGhRqh8
         NZfb3HKp5zF4ryijTwxrkscT+Rr6jPcKPmQGlW6h3mPwqrcaL7Xf+16NQ1+7fpFxpUW6
         smXVINo8i4fmce5/6Hl8ygkr41qYca8pt4snOnrfKNG8PStRAIo12NDcWKr8zOESKQmf
         IF2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736334798; x=1736939598;
        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=5OTB8W0BPYwoUOycX2jvVwt68tOgnvevPd13hEZlyfg=;
        b=GRUDxxIUPNDyeluPPK4ZwHXTTv+pun4fgKX5h7N2HLyR7DJGdj2sTiU81ftgSAiyMu
         iyvF98RF80T7okLeFLjmoCyfRzeKCO1i6u/rB6WigUxaANyzZkTjxc7W2SjHoM4lacY+
         h92yu6sY3njIy4Tg7RJcBoelUusV/nkJ3kPsEGISo1M2jM1ojslr7lSAiSJSljCK+bcC
         iBGGEx2XRHwcCHTy3KEE0Eu7y+1tt2EAz79EZSXTmuhMUg2joeEbDy/uTIdM+Ivh9hAj
         Z5cC7U3QWmto4Gr9QsIDZSSZhgMnrC96fvUJmAvDnyknOnWHTnIxybS8jMF6t/9GKo3D
         hzXg==
X-Gm-Message-State: AOJu0Yy2Ik7KvMniiVXz6YDWr4hDFJ5DSMoPiZ/X268HrIpxkZbu9X10
	rmwUm2ukaNr8LNSaxT/St63puv+dcNFqQ6oWJ11eDPCzw3yKqgT7p9h2ciOD
X-Gm-Gg: ASbGncusgk4euYE7wGqfrmmBlxHCRoQO1qGIL1iZF1D1tLfcAe2EYwGHQw59HxALxRa
	GA+BVaJV+/QvskE1TYhVM6/g9Oy7u4r6jJ+Zp3lpJ6egpW9+x1sPWxl8cJreIr2bkneHZl2U+2L
	BTRSES7QAC2dsM2FG7c846zr0ZwWiRiKzrzWfYGxs41cVGUvxL6Ng6TwHOAD7oVprf3F6LdDRpA
	zaE5/Wr++XktFFs3IkRxMa1CLE3cpdeo4mX0uSmtjH0ZW3Eq0pW5rIPig==
X-Google-Smtp-Source: AGHT+IEaTqsEGhHsauu6PyS2Wl2XkzryajFU0mmd/80nUCa93OHWPftV2OkoGbCkHJ4usuEnaXHXog==
X-Received: by 2002:a05:651c:b0f:b0:300:3a15:8f26 with SMTP id 38308e7fff4ca-305f445a592mr6342001fa.0.1736334797579;
        Wed, 08 Jan 2025 03:13:17 -0800 (PST)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PATCH v1 4/9] asm-generic: move Arm's static-memory.h to asm-generic
Date: Wed,  8 Jan 2025 12:13:06 +0100
Message-ID: <3f1f3786ee48b01f1a5c7c7573456da72aa1e1d2.1736334615.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <cover.1736334615.git.oleksii.kurochko@gmail.com>
References: <cover.1736334615.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Except moving Arm's static-memory.h to asm-generic #ifdef header guard
is updated: s/__ASM_STATIC_MEMORY_H_/__ASM_GENERIC_STATIC_MEMORY_H__.

Update arm/include/asm/Makefile to use asm-generic version of
static-memory.h for Arm.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/arch/arm/include/asm/Makefile        |  1 +
 xen/arch/arm/include/asm/static-memory.h | 58 ------------------------
 xen/include/asm-generic/static-memory.h  | 58 ++++++++++++++++++++++++
 3 files changed, 59 insertions(+), 58 deletions(-)
 delete mode 100644 xen/arch/arm/include/asm/static-memory.h
 create mode 100644 xen/include/asm-generic/static-memory.h

diff --git a/xen/arch/arm/include/asm/Makefile b/xen/arch/arm/include/asm/Makefile
index 831c914cce..ac8208a81f 100644
--- a/xen/arch/arm/include/asm/Makefile
+++ b/xen/arch/arm/include/asm/Makefile
@@ -8,4 +8,5 @@ generic-y += paging.h
 generic-y += percpu.h
 generic-y += random.h
 generic-y += softirq.h
+generic-y += static-memory.h
 generic-y += vm_event.h
diff --git a/xen/arch/arm/include/asm/static-memory.h b/xen/arch/arm/include/asm/static-memory.h
deleted file mode 100644
index 804166e541..0000000000
--- a/xen/arch/arm/include/asm/static-memory.h
+++ /dev/null
@@ -1,58 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
-
-#ifndef __ASM_STATIC_MEMORY_H_
-#define __ASM_STATIC_MEMORY_H_
-
-#include <xen/pfn.h>
-#include <asm/kernel.h>
-
-#ifdef CONFIG_STATIC_MEMORY
-
-static inline void init_staticmem_bank(const struct membank *bank)
-{
-    mfn_t bank_start = _mfn(PFN_UP(bank->start));
-    unsigned long bank_pages = PFN_DOWN(bank->size);
-    mfn_t bank_end = mfn_add(bank_start, bank_pages);
-
-    if ( mfn_x(bank_end) <= mfn_x(bank_start) )
-        return;
-
-    unprepare_staticmem_pages(mfn_to_page(bank_start), bank_pages, false);
-}
-
-void allocate_static_memory(struct domain *d, struct kernel_info *kinfo,
-                            const struct dt_device_node *node);
-void assign_static_memory_11(struct domain *d, struct kernel_info *kinfo,
-                             const struct dt_device_node *node);
-void init_staticmem_pages(void);
-
-#else /* !CONFIG_STATIC_MEMORY */
-
-static inline void allocate_static_memory(struct domain *d,
-                                          struct kernel_info *kinfo,
-                                          const struct dt_device_node *node)
-{
-    ASSERT_UNREACHABLE();
-}
-
-static inline void assign_static_memory_11(struct domain *d,
-                                           struct kernel_info *kinfo,
-                                           const struct dt_device_node *node)
-{
-    ASSERT_UNREACHABLE();
-}
-
-static inline void init_staticmem_pages(void) {};
-
-#endif /* CONFIG_STATIC_MEMORY */
-
-#endif /* __ASM_STATIC_MEMORY_H_ */
-
-/*
- * Local variables:
- * mode: C
- * c-file-style: "BSD"
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/xen/include/asm-generic/static-memory.h b/xen/include/asm-generic/static-memory.h
new file mode 100644
index 0000000000..43b8740d46
--- /dev/null
+++ b/xen/include/asm-generic/static-memory.h
@@ -0,0 +1,58 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef __ASM_GENERIC_STATIC_MEMORY_H__
+#define __ASM_GENERIC_STATIC_MEMORY_H__
+
+#include <xen/pfn.h>
+#include <asm/kernel.h>
+
+#ifdef CONFIG_STATIC_MEMORY
+
+static inline void init_staticmem_bank(const struct membank *bank)
+{
+    mfn_t bank_start = _mfn(PFN_UP(bank->start));
+    unsigned long bank_pages = PFN_DOWN(bank->size);
+    mfn_t bank_end = mfn_add(bank_start, bank_pages);
+
+    if ( mfn_x(bank_end) <= mfn_x(bank_start) )
+        return;
+
+    unprepare_staticmem_pages(mfn_to_page(bank_start), bank_pages, false);
+}
+
+void allocate_static_memory(struct domain *d, struct kernel_info *kinfo,
+                            const struct dt_device_node *node);
+void assign_static_memory_11(struct domain *d, struct kernel_info *kinfo,
+                             const struct dt_device_node *node);
+void init_staticmem_pages(void);
+
+#else /* !CONFIG_STATIC_MEMORY */
+
+static inline void allocate_static_memory(struct domain *d,
+                                          struct kernel_info *kinfo,
+                                          const struct dt_device_node *node)
+{
+    ASSERT_UNREACHABLE();
+}
+
+static inline void assign_static_memory_11(struct domain *d,
+                                           struct kernel_info *kinfo,
+                                           const struct dt_device_node *node)
+{
+    ASSERT_UNREACHABLE();
+}
+
+static inline void init_staticmem_pages(void) {};
+
+#endif /* CONFIG_STATIC_MEMORY */
+
+#endif /* __ASM_GENERIC_STATIC_MEMORY_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 11:13:29 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 11:13:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867133.1278561 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVTzy-0001Jf-Mz; Wed, 08 Jan 2025 11:13:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867133.1278561; Wed, 08 Jan 2025 11:13:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVTzy-0001Hz-Jz; Wed, 08 Jan 2025 11:13:18 +0000
Received: by outflank-mailman (input) for mailman id 867133;
 Wed, 08 Jan 2025 11:13:17 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=WoWX=UA=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tVTzx-0001BZ-4A
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 11:13:17 +0000
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com
 [2a00:1450:4864:20::231])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8e912d6c-cdb1-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 12:13:15 +0100 (CET)
Received: by mail-lj1-x231.google.com with SMTP id
 38308e7fff4ca-3003943288bso187518711fa.0
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 03:13:15 -0800 (PST)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-3045ad99d11sm67292171fa.33.2025.01.08.03.13.13
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 03:13:14 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8e912d6c-cdb1-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736334795; x=1736939595; 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=khyzmr/9Ez+tN2hOqgwIY9MJyCMCvynyh0dRKtdVRpU=;
        b=Z9nNzqbwMjGUgeOL+QeXeCGtITB3765me9+wzkX26MB3Ac+dYed9cpocbAPyjSI2rK
         qX+SHFnoVqKsqtVF/jdgQxhSj/CXZAOe6QYFde5oZz2V2+8KJIqpsz+Zw5nfzvBkoXC1
         lfIoQ7ifIWHe1ZWdYymlnIoD0NZeJSHYn+vHTyB0x7UcqPjxbMf1gHO8DmqG38r4t6L/
         MNsz+JrTkZ2IH3rAFIbOP8Oy+dd+ekzXBjPuQZaJck8U7QDyiV+DUawuc5Ybf3IGFEKG
         XpDP5uukPq7Sll4JCj/cI1TLiLVVgzEdtX1Qtvwqps65+2U237rrGrI71WSI6vs8Eykm
         LyBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736334795; x=1736939595;
        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=khyzmr/9Ez+tN2hOqgwIY9MJyCMCvynyh0dRKtdVRpU=;
        b=kTzYO/cPDBYlmziP/8oLWbjHA1YS4d/ZwufTYSfY7iCQiBKgznB10Ss456dCebpWMe
         1Sf1O5tizCWsdARxrekfCrhIcy+wz34UknGItZQ0SkMwPWsmHoTTKfCTp/isZNq/SNSe
         /iu8bN7xOIreF24HTHT3VgTV7t7aQp1xWNLyW/k5oIo6Bjuoa+sQuo1FjZqs1mPaHByu
         Vtm45SZUML4vUP5wZXDcyuoERLQjp3aLZSdy+3avn26QUwzuVJsjdh332gfhaIWgzbOd
         8bEwXsQzJxJAWmN5ImIcuUiTi6us8JlWEQmZc0bdopi5LhP3xot1jFK1B6elEuhtJ8K/
         CJKQ==
X-Gm-Message-State: AOJu0YxTiNonHxkc4fWDfAtMCfE8WJI/KhAaG/aQWZSTc8Yy5C6lqWED
	0aRu5pd1PTLAC+hfKajwbBhbPOzj78O4NscKYWF35Y03T+DFZCuKn+WmgxYw
X-Gm-Gg: ASbGncsSi0Edu3UhxUWpG5gfhwkgVOCkJSKE5IbSNQcqqRSoNq8aOMBqqoN2pYEIswC
	VLLb6p/IzYAHT9zEs9xaDryOdHNuhUjoK2DXX+YEYH/vBkcQ177HOu+IC8xtrZA6PFa7UJ+nTjV
	lEfLGwCtnuWdKI9tAjbM3FFfXdg6ZDWg/ruj05/iHxvY5ZcwQeB+Y210XJfmZSpZFdXtqucX5hd
	yf9JKVzKmJOm7EQrEYB4A6ltUetDmPLRMdeOfuPhhogIpN72iVfiTLyng==
X-Google-Smtp-Source: AGHT+IHzQbhrAIsD8/khEWYTRZbSzjvroSOvz6vYlYUIeTqvwxtRVs75BZuJepoG10lmND9Gkqk+uw==
X-Received: by 2002:a2e:bb8e:0:b0:300:1f2d:97a with SMTP id 38308e7fff4ca-305f4547ea2mr4884401fa.16.1736334794385;
        Wed, 08 Jan 2025 03:13:14 -0800 (PST)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PATCH v1 1/9] xen/common: dom0less: make some parts of Arm's CONFIG_DOM0LESS common
Date: Wed,  8 Jan 2025 12:13:03 +0100
Message-ID: <396a60496844c8a86667f4ee57c5bedc9899f5ad.1736334615.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <cover.1736334615.git.oleksii.kurochko@gmail.com>
References: <cover.1736334615.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Unify the API for creating DomUs and checking for Dom0less mode across
architectures, including Arm and RISC-V, with potential applicability
for PPC.

Move dom0less-build.h from the Arm-specific directory to asm-generic
as these header is expected to be the same across acrhictectures with
some updates: add the following declaration of construct_domU(),
arch_xen_domctl_createdomain() and arch_create_domus() as there are
some parts which are still architecture-specific.

Relocate the CONFIG_DOM0LESS configuration to the common with adding
"depends on Arm" to not break builds for architectures which at the
moment don't support CONFIG_DOM0LESS config, especically it would be
useful to not provide stubs for  construct_domU(),
arch_xen_domctl_createdomain() and arch_create_domus() in case of
*-randconfig which may set CONFIG_DOM0LESS=y.

Move is_dom0less_mode() function to the common code, as it depends on
boot modules that are already part of the common code.

Move create_domUs() function to the common code with some updates:
- Add function arch_xen_domctl_createdomain() as structure
  xen_domctl_createdomain may have some arch-spicific information and
  initialization.
- Add arch_create_domus() to cover parsing of arch-specific features,
  for example, SVE (Scalar Vector Extension ) exists only in Arm.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/arch/arm/Kconfig                      |   8 -
 xen/arch/arm/dom0less-build.c             | 270 ++++++----------------
 xen/arch/arm/include/asm/Makefile         |   1 +
 xen/arch/arm/include/asm/dom0less-build.h |  32 ---
 xen/common/Kconfig                        |   9 +
 xen/common/device-tree/Makefile           |   1 +
 xen/common/device-tree/dom0less-build.c   | 161 +++++++++++++
 xen/include/asm-generic/dom0less-build.h  |  40 ++++
 8 files changed, 283 insertions(+), 239 deletions(-)
 delete mode 100644 xen/arch/arm/include/asm/dom0less-build.h
 create mode 100644 xen/common/device-tree/dom0less-build.c
 create mode 100644 xen/include/asm-generic/dom0less-build.h

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index a26d3e1182..eff6ea6b6d 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -117,14 +117,6 @@ config GICV2
 	  Driver for the ARM Generic Interrupt Controller v2.
 	  If unsure, say Y
 
-config DOM0LESS_BOOT
-	bool "Dom0less boot support" if EXPERT
-	default y
-	help
-	  Dom0less boot support enables Xen to create and start domU guests during
-	  Xen boot without the need of a control domain (Dom0), which could be
-	  present anyway.
-
 config GICV3
 	bool "GICv3 driver"
 	depends on !NEW_VGIC
diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index 49d1f14d65..b27747c05c 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -17,38 +17,6 @@
 #include <asm/static-memory.h>
 #include <asm/static-shmem.h>
 
-bool __init is_dom0less_mode(void)
-{
-    struct bootmodules *mods = &bootinfo.modules;
-    struct bootmodule *mod;
-    unsigned int i;
-    bool dom0found = false;
-    bool domUfound = false;
-
-    /* Look into the bootmodules */
-    for ( i = 0 ; i < mods->nr_mods ; i++ )
-    {
-        mod = &mods->module[i];
-        /* Find if dom0 and domU kernels are present */
-        if ( mod->kind == BOOTMOD_KERNEL )
-        {
-            if ( mod->domU == false )
-            {
-                dom0found = true;
-                break;
-            }
-            else
-                domUfound = true;
-        }
-    }
-
-    /*
-     * If there is no dom0 kernel but at least one domU, then we are in
-     * dom0less mode
-     */
-    return ( !dom0found && domUfound );
-}
-
 #ifdef CONFIG_VGICV2
 static int __init make_gicv2_domU_node(struct kernel_info *kinfo)
 {
@@ -704,8 +672,8 @@ static int __init alloc_xenstore_evtchn(struct domain *d)
     return 0;
 }
 
-static int __init construct_domU(struct domain *d,
-                                 const struct dt_device_node *node)
+int __init construct_domU(struct domain *d,
+                          const struct dt_device_node *node)
 {
     struct kernel_info kinfo = KERNEL_INFO_INIT;
     const char *dom0less_enhanced;
@@ -810,188 +778,92 @@ static int __init construct_domU(struct domain *d,
     return rc;
 }
 
-void __init create_domUs(void)
-{
-    struct dt_device_node *node;
-    const char *dom0less_iommu;
-    bool iommu = false;
-    const struct dt_device_node *cpupool_node,
-                                *chosen = dt_find_node_by_path("/chosen");
-    const char *llc_colors_str = NULL;
-
-    BUG_ON(chosen == NULL);
-    dt_for_each_child_node(chosen, node)
-    {
-        struct domain *d;
-        struct xen_domctl_createdomain d_cfg = {
-            .arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE,
-            .flags = XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap,
-            /*
-             * The default of 1023 should be sufficient for guests because
-             * on ARM we don't bind physical interrupts to event channels.
-             * The only use of the evtchn port is inter-domain communications.
-             * 1023 is also the default value used in libxl.
-             */
-            .max_evtchn_port = 1023,
-            .max_grant_frames = -1,
-            .max_maptrack_frames = -1,
-            .grant_opts = XEN_DOMCTL_GRANT_version(opt_gnttab_max_version),
-        };
-        unsigned int flags = 0U;
-        uint32_t val;
-        int rc;
-
-        if ( !dt_device_is_compatible(node, "xen,domain") )
-            continue;
 
-        if ( (max_init_domid + 1) >= DOMID_FIRST_RESERVED )
-            panic("No more domain IDs available\n");
-
-        if ( dt_find_property(node, "xen,static-mem", NULL) )
-        {
-            if ( llc_coloring_enabled )
-                panic("LLC coloring and static memory are incompatible\n");
-
-            flags |= CDF_staticmem;
-        }
-
-        if ( dt_property_read_bool(node, "direct-map") )
-        {
-            if ( !(flags & CDF_staticmem) )
-                panic("direct-map is not valid for domain %s without static allocation.\n",
-                      dt_node_name(node));
-
-            flags |= CDF_directmap;
-        }
-
-        if ( !dt_property_read_u32(node, "cpus", &d_cfg.max_vcpus) )
-            panic("Missing property 'cpus' for domain %s\n",
-                  dt_node_name(node));
-
-        if ( !dt_property_read_string(node, "passthrough", &dom0less_iommu) &&
-             !strcmp(dom0less_iommu, "enabled") )
-            iommu = true;
+struct xen_domctl_createdomain __init arch_xen_domctl_createdomain(void)
+{
+    struct xen_domctl_createdomain d_cfg = {
+        .arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE,
+        .flags = XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap,
+        /*
+            * The default of 1023 should be sufficient for guests because
+            * on ARM we don't bind physical interrupts to event channels.
+            * The only use of the evtchn port is inter-domain communications.
+            * 1023 is also the default value used in libxl.
+            */
+        .max_evtchn_port = 1023,
+        .max_grant_frames = -1,
+        .max_maptrack_frames = -1,
+        .grant_opts = XEN_DOMCTL_GRANT_version(opt_gnttab_max_version),
+    };
+
+    return d_cfg;
+}
 
-        if ( iommu_enabled &&
-             (iommu || dt_find_compatible_node(node, NULL,
-                                               "multiboot,device-tree")) )
-            d_cfg.flags |= XEN_DOMCTL_CDF_iommu;
+void __init arch_create_domus(struct dt_device_node *node,
+                       struct xen_domctl_createdomain *d_cfg,
+                       unsigned int flags)
+{
+    uint32_t val;
 
-        if ( !dt_property_read_u32(node, "nr_spis", &d_cfg.arch.nr_spis) )
-        {
-            int vpl011_virq = GUEST_VPL011_SPI;
-
-            d_cfg.arch.nr_spis = gic_number_lines() - 32;
-
-            /*
-             * The VPL011 virq is GUEST_VPL011_SPI, unless direct-map is
-             * set, in which case it'll match the hardware.
-             *
-             * Since the domain is not yet created, we can't use
-             * d->arch.vpl011.irq. So the logic to find the vIRQ has to
-             * be hardcoded.
-             * The logic here shall be consistent with the one in
-             * domain_vpl011_init().
-             */
-            if ( flags & CDF_directmap )
-            {
-                vpl011_virq = serial_irq(SERHND_DTUART);
-                if ( vpl011_virq < 0 )
-                    panic("Error getting IRQ number for this serial port %d\n",
-                          SERHND_DTUART);
-            }
+    if ( !dt_property_read_u32(node, "nr_spis", &d_cfg->arch.nr_spis) )
+    {
+        int vpl011_virq = GUEST_VPL011_SPI;
 
-            /*
-             * vpl011 uses one emulated SPI. If vpl011 is requested, make
-             * sure that we allocate enough SPIs for it.
-             */
-            if ( dt_property_read_bool(node, "vpl011") )
-                d_cfg.arch.nr_spis = MAX(d_cfg.arch.nr_spis,
-                                         vpl011_virq - 32 + 1);
-        }
+        d_cfg->arch.nr_spis = gic_number_lines() - 32;
 
-        /* Get the optional property domain-cpupool */
-        cpupool_node = dt_parse_phandle(node, "domain-cpupool", 0);
-        if ( cpupool_node )
+        /*
+            * The VPL011 virq is GUEST_VPL011_SPI, unless direct-map is
+            * set, in which case it'll match the hardware.
+            *
+            * Since the domain is not yet created, we can't use
+            * d->arch.vpl011.irq. So the logic to find the vIRQ has to
+            * be hardcoded.
+            * The logic here shall be consistent with the one in
+            * domain_vpl011_init().
+            */
+        if ( flags & CDF_directmap )
         {
-            int pool_id = btcpupools_get_domain_pool_id(cpupool_node);
-            if ( pool_id < 0 )
-                panic("Error getting cpupool id from domain-cpupool (%d)\n",
-                      pool_id);
-            d_cfg.cpupool_id = pool_id;
+            vpl011_virq = serial_irq(SERHND_DTUART);
+            if ( vpl011_virq < 0 )
+                panic("Error getting IRQ number for this serial port %d\n",
+                        SERHND_DTUART);
         }
 
-        if ( dt_property_read_u32(node, "max_grant_version", &val) )
-            d_cfg.grant_opts = XEN_DOMCTL_GRANT_version(val);
+        /*
+         * vpl011 uses one emulated SPI. If vpl011 is requested, make
+         * sure that we allocate enough SPIs for it.
+         */
+        if ( dt_property_read_bool(node, "vpl011") )
+            d_cfg->arch.nr_spis = MAX(d_cfg->arch.nr_spis,
+                                        vpl011_virq - 32 + 1);
+    }
 
-        if ( dt_property_read_u32(node, "max_grant_frames", &val) )
-        {
-            if ( val > INT32_MAX )
-                panic("max_grant_frames (%"PRIu32") overflow\n", val);
-            d_cfg.max_grant_frames = val;
-        }
+    if ( dt_get_property(node, "sve", &val) )
+    {
+#ifdef CONFIG_ARM64_SVE
+        unsigned int sve_vl_bits;
+        bool ret = false;
 
-        if ( dt_property_read_u32(node, "max_maptrack_frames", &val) )
+        if ( !val )
         {
-            if ( val > INT32_MAX )
-                panic("max_maptrack_frames (%"PRIu32") overflow\n", val);
-            d_cfg.max_maptrack_frames = val;
+            /* Property found with no value, means max HW VL supported */
+            ret = sve_domctl_vl_param(-1, &sve_vl_bits);
         }
-
-        if ( dt_get_property(node, "sve", &val) )
+        else
         {
-#ifdef CONFIG_ARM64_SVE
-            unsigned int sve_vl_bits;
-            bool ret = false;
-
-            if ( !val )
-            {
-                /* Property found with no value, means max HW VL supported */
-                ret = sve_domctl_vl_param(-1, &sve_vl_bits);
-            }
+            if ( dt_property_read_u32(node, "sve", &val) )
+                ret = sve_domctl_vl_param(val, &sve_vl_bits);
             else
-            {
-                if ( dt_property_read_u32(node, "sve", &val) )
-                    ret = sve_domctl_vl_param(val, &sve_vl_bits);
-                else
-                    panic("Error reading 'sve' property\n");
-            }
+                panic("Error reading 'sve' property\n");
+        }
 
-            if ( ret )
-                d_cfg.arch.sve_vl = sve_encode_vl(sve_vl_bits);
-            else
-                panic("SVE vector length error\n");
+        if ( ret )
+            d_cfg->arch.sve_vl = sve_encode_vl(sve_vl_bits);
+        else
+            panic("SVE vector length error\n");
 #else
-            panic("'sve' property found, but CONFIG_ARM64_SVE not selected\n");
+        panic("'sve' property found, but CONFIG_ARM64_SVE not selected\n");
 #endif
-        }
-
-        dt_property_read_string(node, "llc-colors", &llc_colors_str);
-        if ( !llc_coloring_enabled && llc_colors_str )
-            panic("'llc-colors' found, but LLC coloring is disabled\n");
-
-        /*
-         * The variable max_init_domid is initialized with zero, so here it's
-         * very important to use the pre-increment operator to call
-         * domain_create() with a domid > 0. (domid == 0 is reserved for Dom0)
-         */
-        d = domain_create(++max_init_domid, &d_cfg, flags);
-        if ( IS_ERR(d) )
-            panic("Error creating domain %s (rc = %ld)\n",
-                  dt_node_name(node), PTR_ERR(d));
-
-        if ( llc_coloring_enabled &&
-             (rc = domain_set_llc_colors_from_str(d, llc_colors_str)) )
-            panic("Error initializing LLC coloring for domain %s (rc = %d)\n",
-                  dt_node_name(node), rc);
-
-        d->is_console = true;
-        dt_device_set_used_by(node, d->domain_id);
-
-        rc = construct_domU(d, node);
-        if ( rc )
-            panic("Could not set up domain %s (rc = %d)\n",
-                  dt_node_name(node), rc);
     }
 }
 
diff --git a/xen/arch/arm/include/asm/Makefile b/xen/arch/arm/include/asm/Makefile
index 4a4036c951..831c914cce 100644
--- a/xen/arch/arm/include/asm/Makefile
+++ b/xen/arch/arm/include/asm/Makefile
@@ -1,6 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0-only
 generic-y += altp2m.h
 generic-y += device.h
+generic-y += dom0less-build.h
 generic-y += hardirq.h
 generic-y += iocap.h
 generic-y += paging.h
diff --git a/xen/arch/arm/include/asm/dom0less-build.h b/xen/arch/arm/include/asm/dom0less-build.h
deleted file mode 100644
index 5864944bda..0000000000
--- a/xen/arch/arm/include/asm/dom0less-build.h
+++ /dev/null
@@ -1,32 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
-
-#ifndef __ASM_DOM0LESS_BUILD_H_
-#define __ASM_DOM0LESS_BUILD_H_
-
-#include <xen/stdbool.h>
-
-#ifdef CONFIG_DOM0LESS_BOOT
-
-void create_domUs(void);
-bool is_dom0less_mode(void);
-
-#else /* !CONFIG_DOM0LESS_BOOT */
-
-static inline void create_domUs(void) {}
-static inline bool is_dom0less_mode(void)
-{
-    return false;
-}
-
-#endif /* CONFIG_DOM0LESS_BOOT */
-
-#endif /* __ASM_DOM0LESS_BUILD_H_ */
-
-/*
- * Local variables:
- * mode: C
- * c-file-style: "BSD"
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 6166327f4d..099e6e72ad 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -12,6 +12,15 @@ config CORE_PARKING
 	bool
 	depends on NR_CPUS > 1
 
+config DOM0LESS_BOOT
+	bool "Dom0less boot support" if EXPERT
+	depends on ARM
+	default ARM
+	help
+	  Dom0less boot support enables Xen to create and start domU guests during
+	  Xen boot without the need of a control domain (Dom0), which could be
+	  present anyway.
+
 config GRANT_TABLE
 	bool "Grant table support" if EXPERT
 	default y
diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
index 7c549be38a..f3dafc9b81 100644
--- a/xen/common/device-tree/Makefile
+++ b/xen/common/device-tree/Makefile
@@ -1,5 +1,6 @@
 obj-y += bootfdt.init.o
 obj-y += bootinfo.init.o
 obj-y += device-tree.o
+obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.o
 obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o
 obj-y += intc.o
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
new file mode 100644
index 0000000000..19bfa5e005
--- /dev/null
+++ b/xen/common/device-tree/dom0less-build.c
@@ -0,0 +1,161 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#include <xen/bootfdt.h>
+#include <xen/device_tree.h>
+#include <xen/domain.h>
+#include <xen/err.h>
+#include <xen/init.h>
+#include <xen/iommu.h>
+#include <xen/llc-coloring.h>
+#include <xen/sched.h>
+#include <xen/stdbool.h>
+#include <xen/types.h>
+
+#include <public/domctl.h>
+
+#include <asm/dom0less-build.h>
+#include <asm/setup.h>
+
+bool __init is_dom0less_mode(void)
+{
+    struct bootmodules *mods = &bootinfo.modules;
+    struct bootmodule *mod;
+    unsigned int i;
+    bool dom0found = false;
+    bool domUfound = false;
+
+    /* Look into the bootmodules */
+    for ( i = 0 ; i < mods->nr_mods ; i++ )
+    {
+        mod = &mods->module[i];
+        /* Find if dom0 and domU kernels are present */
+        if ( mod->kind == BOOTMOD_KERNEL )
+        {
+            if ( mod->domU == false )
+            {
+                dom0found = true;
+                break;
+            }
+            else
+                domUfound = true;
+        }
+    }
+
+    /*
+     * If there is no dom0 kernel but at least one domU, then we are in
+     * dom0less mode
+     */
+    return ( !dom0found && domUfound );
+}
+
+void __init create_domUs(void)
+{
+    struct dt_device_node *node;
+    const char *dom0less_iommu;
+    bool iommu = false;
+    const struct dt_device_node *cpupool_node,
+                                *chosen = dt_find_node_by_path("/chosen");
+    const char *llc_colors_str = NULL;
+
+    BUG_ON(chosen == NULL);
+    dt_for_each_child_node(chosen, node)
+    {
+        struct domain *d;
+        struct xen_domctl_createdomain d_cfg = arch_xen_domctl_createdomain();
+        unsigned int flags = 0U;
+        uint32_t val;
+        int rc;
+
+        if ( !dt_device_is_compatible(node, "xen,domain") )
+            continue;
+
+        if ( (max_init_domid + 1) >= DOMID_FIRST_RESERVED )
+            panic("No more domain IDs available\n");
+
+        if ( dt_find_property(node, "xen,static-mem", NULL) )
+        {
+            if ( llc_coloring_enabled )
+                panic("LLC coloring and static memory are incompatible\n");
+
+            flags |= CDF_staticmem;
+        }
+
+        if ( dt_property_read_bool(node, "direct-map") )
+        {
+            if ( !(flags & CDF_staticmem) )
+                panic("direct-map is not valid for domain %s without static allocation.\n",
+                      dt_node_name(node));
+
+            flags |= CDF_directmap;
+        }
+
+        if ( !dt_property_read_u32(node, "cpus", &d_cfg.max_vcpus) )
+            panic("Missing property 'cpus' for domain %s\n",
+                  dt_node_name(node));
+
+        if ( !dt_property_read_string(node, "passthrough", &dom0less_iommu) &&
+             !strcmp(dom0less_iommu, "enabled") )
+            iommu = true;
+
+        if ( iommu_enabled &&
+             (iommu || dt_find_compatible_node(node, NULL,
+                                               "multiboot,device-tree")) )
+            d_cfg.flags |= XEN_DOMCTL_CDF_iommu;
+
+        /* Get the optional property domain-cpupool */
+        cpupool_node = dt_parse_phandle(node, "domain-cpupool", 0);
+        if ( cpupool_node )
+        {
+            int pool_id = btcpupools_get_domain_pool_id(cpupool_node);
+            if ( pool_id < 0 )
+                panic("Error getting cpupool id from domain-cpupool (%d)\n",
+                      pool_id);
+            d_cfg.cpupool_id = pool_id;
+        }
+
+        if ( dt_property_read_u32(node, "max_grant_version", &val) )
+            d_cfg.grant_opts = XEN_DOMCTL_GRANT_version(val);
+
+        if ( dt_property_read_u32(node, "max_grant_frames", &val) )
+        {
+            if ( val > INT32_MAX )
+                panic("max_grant_frames (%"PRIu32") overflow\n", val);
+            d_cfg.max_grant_frames = val;
+        }
+
+        if ( dt_property_read_u32(node, "max_maptrack_frames", &val) )
+        {
+            if ( val > INT32_MAX )
+                panic("max_maptrack_frames (%"PRIu32") overflow\n", val);
+            d_cfg.max_maptrack_frames = val;
+        }
+
+        dt_property_read_string(node, "llc-colors", &llc_colors_str);
+        if ( !llc_coloring_enabled && llc_colors_str )
+            panic("'llc-colors' found, but LLC coloring is disabled\n");
+
+        arch_create_domus(node, &d_cfg, flags);
+
+        /*
+         * The variable max_init_domid is initialized with zero, so here it's
+         * very important to use the pre-increment operator to call
+         * domain_create() with a domid > 0. (domid == 0 is reserved for Dom0)
+         */
+        d = domain_create(++max_init_domid, &d_cfg, flags);
+        if ( IS_ERR(d) )
+            panic("Error creating domain %s (rc = %ld)\n",
+                  dt_node_name(node), PTR_ERR(d));
+
+        if ( llc_coloring_enabled &&
+             (rc = domain_set_llc_colors_from_str(d, llc_colors_str)) )
+            panic("Error initializing LLC coloring for domain %s (rc = %d)\n",
+                  dt_node_name(node), rc);
+
+        d->is_console = true;
+        dt_device_set_used_by(node, d->domain_id);
+
+        rc = construct_domU(d, node);
+        if ( rc )
+            panic("Could not set up domain %s (rc = %d)\n",
+                  dt_node_name(node), rc);
+    }
+}
diff --git a/xen/include/asm-generic/dom0less-build.h b/xen/include/asm-generic/dom0less-build.h
new file mode 100644
index 0000000000..a6985bc20a
--- /dev/null
+++ b/xen/include/asm-generic/dom0less-build.h
@@ -0,0 +1,40 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __ASM_GENERIC_DOM0LESS_BUILD_H__
+#define __ASM_GENERIC_DOM0LESS_BUILD_H__
+
+#include <xen/stdbool.h>
+
+#ifdef CONFIG_DOM0LESS_BOOT
+
+#include <public/domctl.h>
+
+void create_domUs(void);
+bool is_dom0less_mode(void);
+
+int construct_domU(struct domain *d, const struct dt_device_node *node);
+
+struct xen_domctl_createdomain arch_xen_domctl_createdomain(void);
+void arch_create_domus(struct dt_device_node *node,
+                       struct xen_domctl_createdomain *d_cfg,
+                       unsigned int flags);
+
+#else /* !CONFIG_DOM0LESS_BOOT */
+
+static inline void create_domUs(void) {}
+static inline bool is_dom0less_mode(void)
+{
+    return false;
+}
+
+#endif /* CONFIG_DOM0LESS_BOOT */
+
+#endif /* __ASM_GENERIC_DOM0LESS_BUILD_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 11:13:29 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 11:13:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867134.1278568 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVTzz-0001OT-2q; Wed, 08 Jan 2025 11:13:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867134.1278568; Wed, 08 Jan 2025 11:13:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVTzy-0001Mv-Sa; Wed, 08 Jan 2025 11:13:18 +0000
Received: by outflank-mailman (input) for mailman id 867134;
 Wed, 08 Jan 2025 11:13: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
 <SRS0=WoWX=UA=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tVTzx-0001BZ-SM
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 11:13:17 +0000
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com
 [2a00:1450:4864:20::22a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8ee60536-cdb1-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 12:13:16 +0100 (CET)
Received: by mail-lj1-x22a.google.com with SMTP id
 38308e7fff4ca-304d760f0dfso50250541fa.2
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 03:13:16 -0800 (PST)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-3045ad99d11sm67292171fa.33.2025.01.08.03.13.14
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 03:13:14 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8ee60536-cdb1-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736334796; x=1736939596; 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=GR2a/0jnuvbrYQt6CCllwzwGe4JakRFRLxGKEovkNEQ=;
        b=a9OS8uP9V30NUmR7MKpmh3whzHv36zAtbxa5q/6yCD2Ow+3XrfHvchNBkjHRjobKI9
         f8GJmwGs9cvZurgFFnDggsprXpW/9mdONBGLI8NZCHdBpmyNZBuS5EUvP/EjdyQZaI00
         sFMKyezmcdkZtxqsWI+to3N43EJTPB95MqnHuYFpPimtK2sY4zxmDWWrNUsZItJcudNY
         BeKFSYZegI/yrcKG+7LKqslejlzdqjSCG9SPX3uftvFB0fifCBKgUZHN85lAIxt9gtyJ
         gHjKYBxVx/OOvX8GS5QjzhRDE3GygVw4KdKZeD1083mO8Yk1h8h5BFhWNzE5LJs81foG
         hmmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736334796; x=1736939596;
        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=GR2a/0jnuvbrYQt6CCllwzwGe4JakRFRLxGKEovkNEQ=;
        b=Uv00/BseS/srHlaVLT5v72Uut+MLmFWBteFks0Agn9k823OEILjsRM78OuNZOLiwoj
         6m+HGiBeSHHLYanwb1PD7yhjoKgieE2PzYvj2hU5Ihri42LGtwtDqEkxYECtOX+by3OE
         UOx7SNv/m1U4RZguPQx5kAUDAFc9xfHb/6R7vX3GU3pG2ypvxXg7+WEfDkOU+CL5PgUi
         UDR3dsH1JxMicRg5EqsrwfkWohM+01nebA3+SC4sO1vkSv7yAkUyRhNncpNC1O1z+2XU
         i9AGE1Ipj5XCnpAz39yLtaTLE8Okp+8UJ41sK1fTYnHbrzwg6sh+8hf4dV/ypYvh9Wiw
         tNlw==
X-Gm-Message-State: AOJu0Yxx+nTTKTPLmPQ9Q4z1aWf+JEHAZied5jkq1YmhW6fiA65LPXa0
	fu8N+sV4odw0F31iZR85vCNLRqxrz2gZ7vlDtgssJb34oqX3eTnqxwx0jh/x
X-Gm-Gg: ASbGncsvxliWtIMOPCMtQUKFhCt/ZcEaEQw8+/eMM2v7TV7vy5qdQc0ilxoUAZg8OWq
	b0Nl+f6+BEOCiGOyK6kg3QscNWG7bTe38vYdDRnH9oqfHhxpdQHJEMXxOeSFdLomGwM1onW4Rej
	SDCkHOFlOsYAFwMgyrOM/Nx8Dk73ccIDYZ1MRf4ChQIqKRxzNrWSIAIAyMcRq8l2yaKytUCC/Sb
	rEQ4GhWUaiq/Ox5UHoX2rtBsXiR5Vr9WeR3FxNOfjsd/L6zcVJSQB2WJQ==
X-Google-Smtp-Source: AGHT+IFsh3iV6x24r1z6bgjQYA4fIvXoEcEueWsf8uvmzjQHvcik8vtonyJEo3Zs4ajaJbZhPgKwEA==
X-Received: by 2002:a2e:b887:0:b0:302:1c90:58d9 with SMTP id 38308e7fff4ca-305f458a829mr6956111fa.16.1736334795263;
        Wed, 08 Jan 2025 03:13:15 -0800 (PST)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PATCH v1 2/9] asm-generic: move parts of Arm's asm/kernel.h to asm-generic
Date: Wed,  8 Jan 2025 12:13:04 +0100
Message-ID: <6404cb5ae077909cbfdf3860d38c701c65547b56.1736334615.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <cover.1736334615.git.oleksii.kurochko@gmail.com>
References: <cover.1736334615.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Move the following parts to asm-generic with the following changes:
- struct kernel_info:
  - Create arch_kernel_info for arch specific kernel information.
    At the moment, it contains domain_type for Arm.
  - Rename vpl011 to vuart to have more generic name suitable for other archs.
  - s/phandle_gic/phandle_intc to have more generic name suitable for other
    archs.
  - Make text_offset of zimage structure available for RISCV_64.
- Wrap by `#ifdef KERNEL_INFO_SHM_MEM_INIT` definition of KERNEL_SHM_MEM_INIT
  and wrap by `#ifndef KERNEL_INFO_INIT` definition of KERNEL_INFO_INIT to have
  ability to override KERNEL_INFO_SHM_MEM_INIT for arch in case it doesn't
  want to use generic one.
- All other parts are left as is from Arm's asm/kernel.h

Because of the changes in struct kernel_info the correspondent parts of Arm's
code are updated.

As part of this patch the following clean up happens:
- Drop asm/setup.h from asm/kernel.h as nothing depends from it.
  Add inclusion of asm/setup.h for a code which uses device_tree_get_reg() to
  avoid compilation issues for CONFIG_STATIC_MEMORY and CONFIG_STATIC_SHM.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/arch/arm/dom0less-build.c     |  28 +++---
 xen/arch/arm/domain_build.c       |  10 +-
 xen/arch/arm/include/asm/kernel.h | 115 +----------------------
 xen/arch/arm/kernel.c             |  10 +-
 xen/arch/arm/static-memory.c      |   1 +
 xen/arch/arm/static-shmem.c       |   1 +
 xen/include/asm-generic/kernel.h  | 146 ++++++++++++++++++++++++++++++
 7 files changed, 175 insertions(+), 136 deletions(-)
 create mode 100644 xen/include/asm-generic/kernel.h

diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index b27747c05c..c4badb4ade 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -57,11 +57,11 @@ static int __init make_gicv2_domU_node(struct kernel_info *kinfo)
     if (res)
         return res;
 
-    res = fdt_property_cell(fdt, "linux,phandle", kinfo->phandle_gic);
+    res = fdt_property_cell(fdt, "linux,phandle", kinfo->phandle_intc);
     if (res)
         return res;
 
-    res = fdt_property_cell(fdt, "phandle", kinfo->phandle_gic);
+    res = fdt_property_cell(fdt, "phandle", kinfo->phandle_intc);
     if (res)
         return res;
 
@@ -128,11 +128,11 @@ static int __init make_gicv3_domU_node(struct kernel_info *kinfo)
     if (res)
         return res;
 
-    res = fdt_property_cell(fdt, "linux,phandle", kinfo->phandle_gic);
+    res = fdt_property_cell(fdt, "linux,phandle", kinfo->phandle_intc);
     if (res)
         return res;
 
-    res = fdt_property_cell(fdt, "phandle", kinfo->phandle_gic);
+    res = fdt_property_cell(fdt, "phandle", kinfo->phandle_intc);
     if (res)
         return res;
 
@@ -193,7 +193,7 @@ static int __init make_vpl011_uart_node(struct kernel_info *kinfo)
         return res;
 
     res = fdt_property_cell(fdt, "interrupt-parent",
-                            kinfo->phandle_gic);
+                            kinfo->phandle_intc);
     if ( res )
         return res;
 
@@ -479,10 +479,10 @@ static int __init domain_handle_dtb_bootmodule(struct domain *d,
          */
         if ( dt_node_cmp(name, "gic") == 0 )
         {
-            uint32_t phandle_gic = fdt_get_phandle(pfdt, node_next);
+            uint32_t phandle_intc = fdt_get_phandle(pfdt, node_next);
 
-            if ( phandle_gic != 0 )
-                kinfo->phandle_gic = phandle_gic;
+            if ( phandle_intc != 0 )
+                kinfo->phandle_intc = phandle_intc;
             continue;
         }
 
@@ -525,7 +525,7 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo)
     int addrcells, sizecells;
     int ret, fdt_size = DOMU_DTB_SIZE;
 
-    kinfo->phandle_gic = GUEST_PHANDLE_GIC;
+    kinfo->phandle_intc = GUEST_PHANDLE_GIC;
     kinfo->gnttab_start = GUEST_GNTTAB_BASE;
     kinfo->gnttab_size = GUEST_GNTTAB_SIZE;
 
@@ -587,7 +587,7 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo)
     /*
      * domain_handle_dtb_bootmodule has to be called before the rest of
      * the device tree is generated because it depends on the value of
-     * the field phandle_gic.
+     * the field phandle_intc.
      */
     if ( kinfo->dtb_bootmodule )
     {
@@ -604,7 +604,7 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo)
     if ( ret )
         goto err;
 
-    if ( kinfo->vpl011 )
+    if ( kinfo->vuart )
     {
         ret = -EINVAL;
 #ifdef CONFIG_SBSA_VUART_CONSOLE
@@ -705,7 +705,7 @@ int __init construct_domU(struct domain *d,
     printk("*** LOADING DOMU cpus=%u memory=%#"PRIx64"KB ***\n",
            d->max_vcpus, mem);
 
-    kinfo.vpl011 = dt_property_read_bool(node, "vpl011");
+    kinfo.vuart = dt_property_read_bool(node, "vpl011");
 
     rc = dt_property_read_string(node, "xen,enhanced", &dom0less_enhanced);
     if ( rc == -EILSEQ ||
@@ -733,7 +733,7 @@ int __init construct_domU(struct domain *d,
 
 #ifdef CONFIG_ARM_64
     /* type must be set before allocate memory */
-    d->arch.type = kinfo.type;
+    d->arch.type = kinfo.arch.type;
 #endif
     if ( !dt_find_property(node, "xen,static-mem", NULL) )
         allocate_memory(d, &kinfo);
@@ -751,7 +751,7 @@ int __init construct_domU(struct domain *d,
      * tree node in prepare_dtb_domU, so initialization on related variables
      * shall be done first.
      */
-    if ( kinfo.vpl011 )
+    if ( kinfo.vuart )
     {
         rc = domain_vpl011_init(d, NULL);
         if ( rc < 0 )
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index b072a16249..976b03a5df 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -747,7 +747,7 @@ static int __init fdt_property_interrupts(const struct kernel_info *kinfo,
         return res;
 
     res = fdt_property_cell(kinfo->fdt, "interrupt-parent",
-                            kinfo->phandle_gic);
+                            kinfo->phandle_intc);
 
     return res;
 }
@@ -2026,7 +2026,7 @@ static int __init prepare_dtb_hwdom(struct domain *d, struct kernel_info *kinfo)
 
     ASSERT(dt_host && (dt_host->sibling == NULL));
 
-    kinfo->phandle_gic = dt_interrupt_controller->phandle;
+    kinfo->phandle_intc = dt_interrupt_controller->phandle;
     fdt = device_tree_flattened;
 
     new_size = fdt_totalsize(fdt) + DOM0_FDT_EXTRA_SIZE;
@@ -2194,13 +2194,13 @@ int __init construct_domain(struct domain *d, struct kernel_info *kinfo)
 
 #ifdef CONFIG_ARM_64
     /* if aarch32 mode is not supported at EL1 do not allow 32-bit domain */
-    if ( !(cpu_has_el1_32) && kinfo->type == DOMAIN_32BIT )
+    if ( !(cpu_has_el1_32) && kinfo->arch.type == DOMAIN_32BIT )
     {
         printk("Platform does not support 32-bit domain\n");
         return -EINVAL;
     }
 
-    if ( is_sve_domain(d) && (kinfo->type == DOMAIN_32BIT) )
+    if ( is_sve_domain(d) && (kinfo->arch.type == DOMAIN_32BIT) )
     {
         printk("SVE is not available for 32-bit domain\n");
         return -EINVAL;
@@ -2307,7 +2307,7 @@ static int __init construct_dom0(struct domain *d)
 
 #ifdef CONFIG_ARM_64
     /* type must be set before allocate_memory */
-    d->arch.type = kinfo.type;
+    d->arch.type = kinfo.arch.type;
 #endif
     find_gnttab_region(d, &kinfo);
     if ( is_domain_direct_mapped(d) )
diff --git a/xen/arch/arm/include/asm/kernel.h b/xen/arch/arm/include/asm/kernel.h
index 7e6e3c82a4..4d74f0bcb2 100644
--- a/xen/arch/arm/include/asm/kernel.h
+++ b/xen/arch/arm/include/asm/kernel.h
@@ -6,125 +6,16 @@
 #ifndef __ARCH_ARM_KERNEL_H__
 #define __ARCH_ARM_KERNEL_H__
 
-#include <xen/device_tree.h>
 #include <asm/domain.h>
-#include <asm/setup.h>
 
-/*
- * List of possible features for dom0less domUs
- *
- * DOM0LESS_ENHANCED_NO_XS: Notify the OS it is running on top of Xen. All the
- *                          default features (excluding Xenstore) will be
- *                          available. Note that an OS *must* not rely on the
- *                          availability of Xen features if this is not set.
- * DOM0LESS_XENSTORE:       Xenstore will be enabled for the VM. This feature
- *                          can't be enabled without the
- *                          DOM0LESS_ENHANCED_NO_XS.
- * DOM0LESS_ENHANCED:       Notify the OS it is running on top of Xen. All the
- *                          default features (including Xenstore) will be
- *                          available. Note that an OS *must* not rely on the
- *                          availability of Xen features if this is not set.
- */
-#define DOM0LESS_ENHANCED_NO_XS  BIT(0, U)
-#define DOM0LESS_XENSTORE        BIT(1, U)
-#define DOM0LESS_ENHANCED        (DOM0LESS_ENHANCED_NO_XS | DOM0LESS_XENSTORE)
-
-struct kernel_info {
+struct arch_kernel_info
+{
 #ifdef CONFIG_ARM_64
     enum domain_type type;
 #endif
-
-    struct domain *d;
-
-    void *fdt; /* flat device tree */
-    paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */
-    struct meminfo mem;
-#ifdef CONFIG_STATIC_SHM
-    struct shared_meminfo shm_mem;
-#endif
-
-    /* kernel entry point */
-    paddr_t entry;
-
-    /* grant table region */
-    paddr_t gnttab_start;
-    paddr_t gnttab_size;
-
-    /* boot blob load addresses */
-    const struct bootmodule *kernel_bootmodule, *initrd_bootmodule, *dtb_bootmodule;
-    const char* cmdline;
-    paddr_t dtb_paddr;
-    paddr_t initrd_paddr;
-
-    /* Enable pl011 emulation */
-    bool vpl011;
-
-    /* Enable/Disable PV drivers interfaces */
-    uint16_t dom0less_feature;
-
-    /* GIC phandle */
-    uint32_t phandle_gic;
-
-    /* loader to use for this kernel */
-    void (*load)(struct kernel_info *info);
-    /* loader specific state */
-    union {
-        struct {
-            paddr_t kernel_addr;
-            paddr_t len;
-#ifdef CONFIG_ARM_64
-            paddr_t text_offset; /* 64-bit Image only */
-#endif
-            paddr_t start; /* Must be 0 for 64-bit Image */
-        } zimage;
-    };
 };
 
-static inline struct membanks *kernel_info_get_mem(struct kernel_info *kinfo)
-{
-    return container_of(&kinfo->mem.common, struct membanks, common);
-}
-
-static inline const struct membanks *
-kernel_info_get_mem_const(const struct kernel_info *kinfo)
-{
-    return container_of(&kinfo->mem.common, const struct membanks, common);
-}
-
-#ifdef CONFIG_STATIC_SHM
-#define KERNEL_INFO_SHM_MEM_INIT .shm_mem.common.max_banks = NR_SHMEM_BANKS,
-#else
-#define KERNEL_INFO_SHM_MEM_INIT
-#endif
-
-#define KERNEL_INFO_INIT                        \
-{                                               \
-    .mem.common.max_banks = NR_MEM_BANKS,       \
-    KERNEL_INFO_SHM_MEM_INIT                    \
-}
-
-/*
- * Probe the kernel to detemine its type and select a loader.
- *
- * Sets in info:
- *  ->type
- *  ->load hook, and sets loader specific variables ->zimage
- */
-int kernel_probe(struct kernel_info *info, const struct dt_device_node *domain);
-
-/*
- * Loads the kernel into guest RAM.
- *
- * Expects to be set in info when called:
- *  ->mem
- *  ->fdt
- *
- * Sets in info:
- *  ->entry
- *  ->dtb_paddr
- *  ->initrd_paddr
- */
-void kernel_load(struct kernel_info *info);
+#include <asm-generic/kernel.h>
 
 #endif /* #ifdef __ARCH_ARM_KERNEL_H__ */
 
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index 80fad8b336..b75bd6a887 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -101,7 +101,7 @@ static paddr_t __init kernel_zimage_place(struct kernel_info *info)
     paddr_t load_addr;
 
 #ifdef CONFIG_ARM_64
-    if ( (info->type == DOMAIN_64BIT) && (info->zimage.start == 0) )
+    if ( (info->arch.type == DOMAIN_64BIT) && (info->zimage.start == 0) )
         return mem->bank[0].start + info->zimage.text_offset;
 #endif
 
@@ -371,10 +371,10 @@ static int __init kernel_uimage_probe(struct kernel_info *info,
     switch ( uimage.arch )
     {
     case IH_ARCH_ARM:
-        info->type = DOMAIN_32BIT;
+        info->arch.type = DOMAIN_32BIT;
         break;
     case IH_ARCH_ARM64:
-        info->type = DOMAIN_64BIT;
+        info->arch.type = DOMAIN_64BIT;
         break;
     default:
         printk(XENLOG_ERR "Unsupported uImage arch type %d\n", uimage.arch);
@@ -444,7 +444,7 @@ static int __init kernel_zimage64_probe(struct kernel_info *info,
 
     info->load = kernel_zimage_load;
 
-    info->type = DOMAIN_64BIT;
+    info->arch.type = DOMAIN_64BIT;
 
     return 0;
 }
@@ -496,7 +496,7 @@ static int __init kernel_zimage32_probe(struct kernel_info *info,
     info->load = kernel_zimage_load;
 
 #ifdef CONFIG_ARM_64
-    info->type = DOMAIN_32BIT;
+    info->arch.type = DOMAIN_32BIT;
 #endif
 
     return 0;
diff --git a/xen/arch/arm/static-memory.c b/xen/arch/arm/static-memory.c
index d4585c5a06..e0f76afcd8 100644
--- a/xen/arch/arm/static-memory.c
+++ b/xen/arch/arm/static-memory.c
@@ -2,6 +2,7 @@
 
 #include <xen/sched.h>
 
+#include <asm/setup.h>
 #include <asm/static-memory.h>
 
 static bool __init append_static_memory_to_bank(struct domain *d,
diff --git a/xen/arch/arm/static-shmem.c b/xen/arch/arm/static-shmem.c
index 66088a4267..aff05d24d1 100644
--- a/xen/arch/arm/static-shmem.c
+++ b/xen/arch/arm/static-shmem.c
@@ -6,6 +6,7 @@
 #include <xen/sched.h>
 
 #include <asm/domain_build.h>
+#include <asm/setup.h>
 #include <asm/static-memory.h>
 #include <asm/static-shmem.h>
 
diff --git a/xen/include/asm-generic/kernel.h b/xen/include/asm-generic/kernel.h
new file mode 100644
index 0000000000..b2bd04a185
--- /dev/null
+++ b/xen/include/asm-generic/kernel.h
@@ -0,0 +1,146 @@
+/*
+ * Kernel image loading.
+ *
+ * Copyright (C) 2011 Citrix Systems, Inc.
+ */
+#ifndef __ASM_GENERIC_KERNEL_H__
+#define __ASM_GENERIC_KERNEL_H__
+
+#include <xen/bootfdt.h>
+#include <xen/device_tree.h>
+#include <xen/sched.h>
+#include <xen/types.h>
+
+/*
+ * List of possible features for dom0less domUs
+ *
+ * DOM0LESS_ENHANCED_NO_XS: Notify the OS it is running on top of Xen. All the
+ *                          default features (excluding Xenstore) will be
+ *                          available. Note that an OS *must* not rely on the
+ *                          availability of Xen features if this is not set.
+ * DOM0LESS_XENSTORE:       Xenstore will be enabled for the VM. This feature
+ *                          can't be enabled without the
+ *                          DOM0LESS_ENHANCED_NO_XS.
+ * DOM0LESS_ENHANCED:       Notify the OS it is running on top of Xen. All the
+ *                          default features (including Xenstore) will be
+ *                          available. Note that an OS *must* not rely on the
+ *                          availability of Xen features if this is not set.
+ */
+#define DOM0LESS_ENHANCED_NO_XS  BIT(0, U)
+#define DOM0LESS_XENSTORE        BIT(1, U)
+#define DOM0LESS_ENHANCED        (DOM0LESS_ENHANCED_NO_XS | DOM0LESS_XENSTORE)
+
+struct kernel_info {
+    struct domain *d;
+
+    void *fdt; /* flat device tree */
+    paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */
+    struct meminfo mem;
+#ifdef CONFIG_STATIC_SHM
+    struct shared_meminfo shm_mem;
+#endif
+
+    /* kernel entry point */
+    paddr_t entry;
+
+    /* grant table region */
+    paddr_t gnttab_start;
+    paddr_t gnttab_size;
+
+    /* boot blob load addresses */
+    const struct bootmodule *kernel_bootmodule, *initrd_bootmodule, *dtb_bootmodule;
+    const char* cmdline;
+    paddr_t dtb_paddr;
+    paddr_t initrd_paddr;
+
+    /* Enable uart emulation */
+    bool vuart;
+
+    /* Enable/Disable PV drivers interfaces */
+    uint16_t dom0less_feature;
+
+    /* Interrupt controller phandle */
+    uint32_t phandle_intc;
+
+    /* loader to use for this kernel */
+    void (*load)(struct kernel_info *info);
+
+    /* loader specific state */
+    union {
+        struct {
+            paddr_t kernel_addr;
+            paddr_t len;
+#if defined(CONFIG_ARM_64) || defined(CONFIG_RISCV_64)
+            paddr_t text_offset; /* 64-bit Image only */
+#endif
+            paddr_t start; /* Must be 0 for 64-bit Image */
+        } zimage;
+    };
+
+    struct arch_kernel_info arch;
+};
+
+static inline struct membanks *kernel_info_get_mem(struct kernel_info *kinfo)
+{
+    return container_of(&kinfo->mem.common, struct membanks, common);
+}
+
+static inline const struct membanks *
+kernel_info_get_mem_const(const struct kernel_info *kinfo)
+{
+    return container_of(&kinfo->mem.common, const struct membanks, common);
+}
+
+#ifndef KERNEL_INFO_SHM_MEM_INIT
+
+#ifdef CONFIG_STATIC_SHM
+#define KERNEL_INFO_SHM_MEM_INIT .shm_mem.common.max_banks = NR_SHMEM_BANKS,
+#else
+#define KERNEL_INFO_SHM_MEM_INIT
+#endif
+
+#endif /* KERNEL_INFO_SHM_MEM_INIT */
+
+#ifndef KERNEL_INFO_INIT
+
+#define KERNEL_INFO_INIT                        \
+{                                               \
+    .mem.common.max_banks = NR_MEM_BANKS,       \
+    KERNEL_INFO_SHM_MEM_INIT                    \
+}
+
+#endif /* KERNEL_INFO_INIT */
+
+/*
+ * Probe the kernel to detemine its type and select a loader.
+ *
+ * Sets in info:
+ *  ->type
+ *  ->load hook, and sets loader specific variables ->zimage
+ */
+int kernel_probe(struct kernel_info *info, const struct dt_device_node *domain);
+
+/*
+ * Loads the kernel into guest RAM.
+ *
+ * Expects to be set in info when called:
+ *  ->mem
+ *  ->fdt
+ *
+ * Sets in info:
+ *  ->entry
+ *  ->dtb_paddr
+ *  ->initrd_paddr
+ */
+void kernel_load(struct kernel_info *info);
+
+#endif /*__ASM_GENERIC_KERNEL_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 11:13:29 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 11:13:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867144.1278645 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVU09-0003cO-0G; Wed, 08 Jan 2025 11:13:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867144.1278645; Wed, 08 Jan 2025 11:13:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVU08-0003bz-Qv; Wed, 08 Jan 2025 11:13:28 +0000
Received: by outflank-mailman (input) for mailman id 867144;
 Wed, 08 Jan 2025 11:13:27 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=WoWX=UA=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tVU07-0001rx-10
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 11:13:27 +0000
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com
 [2a00:1450:4864:20::236])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 94216569-cdb1-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 12:13:25 +0100 (CET)
Received: by mail-lj1-x236.google.com with SMTP id
 38308e7fff4ca-30229d5b229so172492851fa.0
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 03:13:25 -0800 (PST)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-3045ad99d11sm67292171fa.33.2025.01.08.03.13.22
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 03:13:22 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 94216569-cdb1-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736334804; x=1736939604; 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=+MTqGiPQ/jA03tCZq1CRsGrbRyrze3+bn/uXhnqO+fM=;
        b=OAe50i/Q/20TEGkopy1PIop/MxRAJVFee7LBczppGtEX3RxJ8Q3j7WQ9bNXsp0MMl1
         qdMk5gQrNHl15E/VxU6qWho/lwcU9PnjWLLafQIU+R65LwoeM5nCthqPKXizs9ys/aM1
         7pQVQ6iyeKqwPCw8NqxRR27EpJenYmc+rAgTjs4fx2+6J5zf1oBGSPU4XbQjNtGxNmuf
         2UBuDfOW7obTguJ8fgRuSx4jpWaC5CjUyQdDlX8mYpfJcn3+EjFU/p6oHbX6tUBFjEFK
         GVxrYC6kHpe8HgoQBZ+Bu2QNdrwEXBbLLJlrZQ7/tgHF0PYzNds8SrA4H5jVQfj5Rr/B
         89jw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736334804; x=1736939604;
        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=+MTqGiPQ/jA03tCZq1CRsGrbRyrze3+bn/uXhnqO+fM=;
        b=clav0JC1QfXVE1w1WyVodVJoPmAiwx5AgN9rolsz5iKlupqrOWSciaNvuD/YY+0Mzm
         VjegiC7oF/XqhyGgC4N+LHLk1qdBTbNauEzbf59m4xCsjJvrwQHkaBkCa24CEucfF6Ke
         FclW4aK4Si3cXmFY5tgZ3s/cz7epsmlcqptyEcd09WD90GJStAaGie8SxuO9wQun3ZWF
         MkTBydq2jYbxMNeuOqFhLdPum5BqYfpSpFUU1jww2udt+tl9gbMM7+vWs+bR/9SwjVvN
         5e9bauJg+v/vIIXvcMEfjvnxTPqbpO2qAvNhlgHKgZ27aHowBbt2GF7ASp5glCD4wAx5
         t6kg==
X-Gm-Message-State: AOJu0YzfU7ba2w6l5uBt6lWddXCFbK7mxdbnUXT2lG2YK4axTIAG5uB2
	53s716WWklMDvqU15yKz1NQyHP9ttfQ11/AymoOqj1fHmjO7zKOjjAMm0IFj
X-Gm-Gg: ASbGncvl8dZphYJRN09kc//qaz5ct8RUa6Gm5tQJQC8zfGDF3Ly4v9d994xnjOyJStM
	3+5teguAuwzCtxs/pc0lzckMeFpwIP95AIBf7bFSHH9Fr0lK7Qqys7KEkIo5KDBQsZFeMpmvPM0
	bNe2cg1dS+RoNLtfrtSxu5B8lcMFYrJnjGqZZgGoMGaAhKzpwh6HAU2t7l6n1rG0gapuPDOfOtg
	N/pI1wZepBFSCE2+WSvJViudsZ2DzRHzEvFyw9tpWWai0o62FPBXpduNw==
X-Google-Smtp-Source: AGHT+IH6AWgeaLtK63AplG5laI6gBLt4hdb4gnLEWD21Ye6lpR+jTdy1iSbPx8iVl6a2e4fLs1B4Ag==
X-Received: by 2002:a05:651c:b0c:b0:2ff:d83d:9155 with SMTP id 38308e7fff4ca-305f4626539mr6587071fa.27.1736334803490;
        Wed, 08 Jan 2025 03:13:23 -0800 (PST)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PATCH v1 9/9] xen/common: dom0less: introduce common dom0less-build.c
Date: Wed,  8 Jan 2025 12:13:11 +0100
Message-ID: <007095f12bfd803df504f10249b5b497bd0529a1.1736334615.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <cover.1736334615.git.oleksii.kurochko@gmail.com>
References: <cover.1736334615.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Part of Arm's dom0less-build.c could be common between architectures which are
using device tree files to create guest domains. Thereby move some parts of
Arm's dom0less-build.c to common code with minor changes.

As a part of theses changes the following changes are introduced:
- Introduce make_arch_nodes() to cover arch-specific nodes. For example, in
  case of Arm, it is PSCI and vpl011 nodes.
- Introduce set_domain_type() to abstract a way how setting of domain type
  happens. For example, RISC-V won't have this member of arch_domain structure
  as vCPUs will always have the same bitness as hypervisor. In case of Arm, it
  is possible that Arm64 could create 32-bit and 64-bit domains.
- Introduce init_vuart() to cover details of virtual uart initialization.
- Introduce init_intc_phandle() to cover some details of interrupt controller
  phandle initialization. As an example, RISC-V could have different name for
  interrupt controller node ( APLIC, PLIC, IMSIC, etc ) but the code in
  domain_handle_dtb_bootmodule() could handle only one interrupt controller
  node name.
- s/make_gic_domU_node/make_intc_domU_node as GIC is Arm specific naming and
  add prototype of make_intc_domU_node() to dom0less-build.h

The following functions are moved to xen/common/device-tree:
- Functions which are moved as is:
  - domain_p2m_pages().
  - handle_passthrough_prop().
  - handle_prop_pfdt().
  - scan_pfdt_node().
  - check_partial_fdt().
- Functions which are moved with some minor changes:
  - alloc_xenstore_evtchn():
    - ifdef-ing by CONFIG_HVM accesses to hvm.params.
  - prepare_dtb_domU():
    - ifdef-ing access to gnttab_{start,size} by CONFIG_GRANT_TABLE.
    - s/make_gic_domU_node/make_intc_domU_node.
    - Add call of make_arch_nodes().
- domain_handle_dtb_bootmodule():
  - hide details of interrupt controller phandle initialization by calling
    init_intc_phandle().
  - Update the comment above init_intc_phandle(): s/gic/interrupt controller.
- construct_domU():
  - ifdef-ing by CONFIG_HVM accesses to hvm.params.
  - Call init_vuart() to hide Arm's vpl011_init() details there.
  - Add call of set_domain_type() instead of setting kinfo->arch.type explicitly.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/arch/arm/dom0less-build.c            | 569 ++---------------------
 xen/common/device-tree/dom0less-build.c  | 559 ++++++++++++++++++++++
 xen/include/asm-generic/dom0less-build.h |  14 +
 3 files changed, 608 insertions(+), 534 deletions(-)

diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index 259285ddda..872a9437da 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -143,7 +143,7 @@ static int __init make_gicv3_domU_node(struct kernel_info *kinfo)
 }
 #endif
 
-static int __init make_gic_domU_node(struct kernel_info *kinfo)
+int __init make_intc_domU_node(struct kernel_info *kinfo)
 {
     switch ( kinfo->d->arch.vgic.version )
     {
@@ -209,577 +209,62 @@ static int __init make_vpl011_uart_node(struct kernel_info *kinfo)
 }
 #endif
 
-/*
- * Scan device tree properties for passthrough specific information.
- * Returns < 0 on error
- *         0 on success
- */
-static int __init handle_passthrough_prop(struct kernel_info *kinfo,
-                                          const struct fdt_property *xen_reg,
-                                          const struct fdt_property *xen_path,
-                                          bool xen_force,
-                                          uint32_t address_cells,
-                                          uint32_t size_cells)
-{
-    const __be32 *cell;
-    unsigned int i, len;
-    struct dt_device_node *node;
-    int res;
-    paddr_t mstart, size, gstart;
-
-    /* xen,reg specifies where to map the MMIO region */
-    cell = (const __be32 *)xen_reg->data;
-    len = fdt32_to_cpu(xen_reg->len) / ((address_cells * 2 + size_cells) *
-                                        sizeof(uint32_t));
-
-    for ( i = 0; i < len; i++ )
-    {
-        device_tree_get_reg(&cell, address_cells, size_cells,
-                            &mstart, &size);
-        gstart = dt_next_cell(address_cells, &cell);
-
-        if ( gstart & ~PAGE_MASK || mstart & ~PAGE_MASK || size & ~PAGE_MASK )
-        {
-            printk(XENLOG_ERR
-                   "DomU passthrough config has not page aligned addresses/sizes\n");
-            return -EINVAL;
-        }
-
-        res = iomem_permit_access(kinfo->d, paddr_to_pfn(mstart),
-                                  paddr_to_pfn(PAGE_ALIGN(mstart + size - 1)));
-        if ( res )
-        {
-            printk(XENLOG_ERR "Unable to permit to dom%d access to"
-                   " 0x%"PRIpaddr" - 0x%"PRIpaddr"\n",
-                   kinfo->d->domain_id,
-                   mstart & PAGE_MASK, PAGE_ALIGN(mstart + size) - 1);
-            return res;
-        }
-
-        res = map_regions_p2mt(kinfo->d,
-                               gaddr_to_gfn(gstart),
-                               PFN_DOWN(size),
-                               maddr_to_mfn(mstart),
-                               p2m_mmio_direct_dev);
-        if ( res < 0 )
-        {
-            printk(XENLOG_ERR
-                   "Failed to map %"PRIpaddr" to the guest at%"PRIpaddr"\n",
-                   mstart, gstart);
-            return -EFAULT;
-        }
-    }
-
-    /*
-     * If xen_force, we let the user assign a MMIO region with no
-     * associated path.
-     */
-    if ( xen_path == NULL )
-        return xen_force ? 0 : -EINVAL;
-
-    /*
-     * xen,path specifies the corresponding node in the host DT.
-     * Both interrupt mappings and IOMMU settings are based on it,
-     * as they are done based on the corresponding host DT node.
-     */
-    node = dt_find_node_by_path(xen_path->data);
-    if ( node == NULL )
-    {
-        printk(XENLOG_ERR "Couldn't find node %s in host_dt!\n",
-               xen_path->data);
-        return -EINVAL;
-    }
-
-    res = map_device_irqs_to_domain(kinfo->d, node, true, NULL);
-    if ( res < 0 )
-        return res;
-
-    res = iommu_add_dt_device(node);
-    if ( res < 0 )
-        return res;
-
-    /* If xen_force, we allow assignment of devices without IOMMU protection. */
-    if ( xen_force && !dt_device_is_protected(node) )
-        return 0;
-
-    return iommu_assign_dt_device(kinfo->d, node);
-}
-
-static int __init handle_prop_pfdt(struct kernel_info *kinfo,
-                                   const void *pfdt, int nodeoff,
-                                   uint32_t address_cells, uint32_t size_cells,
-                                   bool scan_passthrough_prop)
-{
-    void *fdt = kinfo->fdt;
-    int propoff, nameoff, res;
-    const struct fdt_property *prop, *xen_reg = NULL, *xen_path = NULL;
-    const char *name;
-    bool found, xen_force = false;
-
-    for ( propoff = fdt_first_property_offset(pfdt, nodeoff);
-          propoff >= 0;
-          propoff = fdt_next_property_offset(pfdt, propoff) )
-    {
-        if ( !(prop = fdt_get_property_by_offset(pfdt, propoff, NULL)) )
-            return -FDT_ERR_INTERNAL;
-
-        found = false;
-        nameoff = fdt32_to_cpu(prop->nameoff);
-        name = fdt_string(pfdt, nameoff);
-
-        if ( scan_passthrough_prop )
-        {
-            if ( dt_prop_cmp("xen,reg", name) == 0 )
-            {
-                xen_reg = prop;
-                found = true;
-            }
-            else if ( dt_prop_cmp("xen,path", name) == 0 )
-            {
-                xen_path = prop;
-                found = true;
-            }
-            else if ( dt_prop_cmp("xen,force-assign-without-iommu",
-                                  name) == 0 )
-            {
-                xen_force = true;
-                found = true;
-            }
-        }
-
-        /*
-         * Copy properties other than the ones above: xen,reg, xen,path,
-         * and xen,force-assign-without-iommu.
-         */
-        if ( !found )
-        {
-            res = fdt_property(fdt, name, prop->data, fdt32_to_cpu(prop->len));
-            if ( res )
-                return res;
-        }
-    }
-
-    /*
-     * Only handle passthrough properties if both xen,reg and xen,path
-     * are present, or if xen,force-assign-without-iommu is specified.
-     */
-    if ( xen_reg != NULL && (xen_path != NULL || xen_force) )
-    {
-        res = handle_passthrough_prop(kinfo, xen_reg, xen_path, xen_force,
-                                      address_cells, size_cells);
-        if ( res < 0 )
-        {
-            printk(XENLOG_ERR "Failed to assign device to %pd\n", kinfo->d);
-            return res;
-        }
-    }
-    else if ( (xen_path && !xen_reg) || (xen_reg && !xen_path && !xen_force) )
-    {
-        printk(XENLOG_ERR "xen,reg or xen,path missing for %pd\n",
-               kinfo->d);
-        return -EINVAL;
-    }
-
-    /* FDT_ERR_NOTFOUND => There is no more properties for this node */
-    return ( propoff != -FDT_ERR_NOTFOUND ) ? propoff : 0;
-}
-
-static int __init scan_pfdt_node(struct kernel_info *kinfo, const void *pfdt,
-                                 int nodeoff,
-                                 uint32_t address_cells, uint32_t size_cells,
-                                 bool scan_passthrough_prop)
-{
-    int rc = 0;
-    void *fdt = kinfo->fdt;
-    int node_next;
-
-    rc = fdt_begin_node(fdt, fdt_get_name(pfdt, nodeoff, NULL));
-    if ( rc )
-        return rc;
-
-    rc = handle_prop_pfdt(kinfo, pfdt, nodeoff, address_cells, size_cells,
-                          scan_passthrough_prop);
-    if ( rc )
-        return rc;
-
-    address_cells = device_tree_get_u32(pfdt, nodeoff, "#address-cells",
-                                        DT_ROOT_NODE_ADDR_CELLS_DEFAULT);
-    size_cells = device_tree_get_u32(pfdt, nodeoff, "#size-cells",
-                                     DT_ROOT_NODE_SIZE_CELLS_DEFAULT);
-
-    node_next = fdt_first_subnode(pfdt, nodeoff);
-    while ( node_next > 0 )
-    {
-        rc = scan_pfdt_node(kinfo, pfdt, node_next, address_cells, size_cells,
-                            scan_passthrough_prop);
-        if ( rc )
-            return rc;
-
-        node_next = fdt_next_subnode(pfdt, node_next);
-    }
-
-    return fdt_end_node(fdt);
-}
-
-static int __init check_partial_fdt(void *pfdt, size_t size)
-{
-    int res;
-
-    if ( fdt_magic(pfdt) != FDT_MAGIC )
-    {
-        dprintk(XENLOG_ERR, "Partial FDT is not a valid Flat Device Tree");
-        return -EINVAL;
-    }
-
-    res = fdt_check_header(pfdt);
-    if ( res )
-    {
-        dprintk(XENLOG_ERR, "Failed to check the partial FDT (%d)", res);
-        return -EINVAL;
-    }
-
-    if ( fdt_totalsize(pfdt) > size )
-    {
-        dprintk(XENLOG_ERR, "Partial FDT totalsize is too big");
-        return -EINVAL;
-    }
-
-    return 0;
-}
-
-static int __init domain_handle_dtb_bootmodule(struct domain *d,
-                                               struct kernel_info *kinfo)
+int __init make_arch_nodes(struct kernel_info *kinfo)
 {
-    void *pfdt;
-    int res, node_next;
-
-    pfdt = ioremap_cache(kinfo->dtb_bootmodule->start,
-                         kinfo->dtb_bootmodule->size);
-    if ( pfdt == NULL )
-        return -EFAULT;
-
-    res = check_partial_fdt(pfdt, kinfo->dtb_bootmodule->size);
-    if ( res < 0 )
-        goto out;
-
-    for ( node_next = fdt_first_subnode(pfdt, 0);
-          node_next > 0;
-          node_next = fdt_next_subnode(pfdt, node_next) )
-    {
-        const char *name = fdt_get_name(pfdt, node_next, NULL);
-
-        if ( name == NULL )
-            continue;
-
-        /*
-         * Only scan /gic /aliases /passthrough, ignore the rest.
-         * They don't have to be parsed in order.
-         *
-         * Take the GIC phandle value from the special /gic node in the
-         * DTB fragment.
-         */
-        if ( dt_node_cmp(name, "gic") == 0 )
-        {
-            uint32_t phandle_intc = fdt_get_phandle(pfdt, node_next);
-
-            if ( phandle_intc != 0 )
-                kinfo->phandle_intc = phandle_intc;
-            continue;
-        }
-
-        if ( dt_node_cmp(name, "aliases") == 0 )
-        {
-            res = scan_pfdt_node(kinfo, pfdt, node_next,
-                                 DT_ROOT_NODE_ADDR_CELLS_DEFAULT,
-                                 DT_ROOT_NODE_SIZE_CELLS_DEFAULT,
-                                 false);
-            if ( res )
-                goto out;
-            continue;
-        }
-        if ( dt_node_cmp(name, "passthrough") == 0 )
-        {
-            res = scan_pfdt_node(kinfo, pfdt, node_next,
-                                 DT_ROOT_NODE_ADDR_CELLS_DEFAULT,
-                                 DT_ROOT_NODE_SIZE_CELLS_DEFAULT,
-                                 true);
-            if ( res )
-                goto out;
-            continue;
-        }
-    }
-
- out:
-    iounmap(pfdt);
-
-    return res;
-}
-
-/*
- * The max size for DT is 2MB. However, the generated DT is small (not including
- * domU passthrough DT nodes whose size we account separately), 4KB are enough
- * for now, but we might have to increase it in the future.
- */
-#define DOMU_DTB_SIZE 4096
-static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo)
-{
-    int addrcells, sizecells;
-    int ret, fdt_size = DOMU_DTB_SIZE;
-
-    kinfo->phandle_intc = GUEST_PHANDLE_GIC;
-    kinfo->gnttab_start = GUEST_GNTTAB_BASE;
-    kinfo->gnttab_size = GUEST_GNTTAB_SIZE;
-
-    addrcells = GUEST_ROOT_ADDRESS_CELLS;
-    sizecells = GUEST_ROOT_SIZE_CELLS;
-
-    /* Account for domU passthrough DT size */
-    if ( kinfo->dtb_bootmodule )
-        fdt_size += kinfo->dtb_bootmodule->size;
-
-    /* Cap to max DT size if needed */
-    fdt_size = min(fdt_size, SZ_2M);
-
-    kinfo->fdt = xmalloc_bytes(fdt_size);
-    if ( kinfo->fdt == NULL )
-        return -ENOMEM;
-
-    ret = fdt_create(kinfo->fdt, fdt_size);
-    if ( ret < 0 )
-        goto err;
-
-    ret = fdt_finish_reservemap(kinfo->fdt);
-    if ( ret < 0 )
-        goto err;
-
-    ret = fdt_begin_node(kinfo->fdt, "");
-    if ( ret < 0 )
-        goto err;
-
-    ret = fdt_property_cell(kinfo->fdt, "#address-cells", addrcells);
-    if ( ret )
-        goto err;
-
-    ret = fdt_property_cell(kinfo->fdt, "#size-cells", sizecells);
-    if ( ret )
-        goto err;
-
-    ret = make_chosen_node(kinfo);
-    if ( ret )
-        goto err;
+    int ret;
 
     ret = make_psci_node(kinfo->fdt);
     if ( ret )
-        goto err;
-
-    ret = make_cpus_node(d, kinfo->fdt);
-    if ( ret )
-        goto err;
-
-    ret = make_memory_node(kinfo, addrcells, sizecells,
-                           kernel_info_get_mem(kinfo));
-    if ( ret )
-        goto err;
-
-    ret = make_resv_memory_node(kinfo, addrcells, sizecells);
-    if ( ret )
-        goto err;
-
-    /*
-     * domain_handle_dtb_bootmodule has to be called before the rest of
-     * the device tree is generated because it depends on the value of
-     * the field phandle_intc.
-     */
-    if ( kinfo->dtb_bootmodule )
-    {
-        ret = domain_handle_dtb_bootmodule(d, kinfo);
-        if ( ret )
-            goto err;
-    }
-
-    ret = make_gic_domU_node(kinfo);
-    if ( ret )
-        goto err;
-
-    ret = make_timer_node(kinfo);
-    if ( ret )
-        goto err;
+        return -EINVAL;
 
     if ( kinfo->vuart )
     {
-        ret = -EINVAL;
 #ifdef CONFIG_SBSA_VUART_CONSOLE
         ret = make_vpl011_uart_node(kinfo);
 #endif
         if ( ret )
-            goto err;
-    }
-
-    if ( kinfo->dom0less_feature & DOM0LESS_ENHANCED_NO_XS )
-    {
-        ret = make_hypervisor_node(d, kinfo, addrcells, sizecells);
-        if ( ret )
-            goto err;
+            return -EINVAL;
     }
 
-    ret = fdt_end_node(kinfo->fdt);
-    if ( ret < 0 )
-        goto err;
-
-    ret = fdt_finish(kinfo->fdt);
-    if ( ret < 0 )
-        goto err;
-
     return 0;
-
-  err:
-    printk("Device tree generation failed (%d).\n", ret);
-    xfree(kinfo->fdt);
-
-    return -EINVAL;
 }
 
-static unsigned long __init domain_p2m_pages(unsigned long maxmem_kb,
-                                             unsigned int smp_cpus)
+/* TODO: make arch.type generic ? */
+#ifdef CONFIG_ARM_64
+void __init set_domain_type(struct domain *d, struct kernel_info *kinfo)
 {
-    /*
-     * Keep in sync with libxl__get_required_paging_memory().
-     * 256 pages (1MB) per vcpu, plus 1 page per MiB of RAM for the P2M map,
-     * plus 128 pages to cover extended regions.
-     */
-    unsigned long memkb = 4 * (256 * smp_cpus + (maxmem_kb / 1024) + 128);
-
-    BUILD_BUG_ON(PAGE_SIZE != SZ_4K);
-
-    return DIV_ROUND_UP(memkb, 1024) << (20 - PAGE_SHIFT);
+    /* type must be set before allocate memory */
+    d->arch.type = kinfo->arch.type;
 }
-
-static int __init alloc_xenstore_evtchn(struct domain *d)
+#else
+void __init set_domain_type(struct domain *d, struct kernel_info *kinfo)
 {
-    evtchn_alloc_unbound_t alloc;
-    int rc;
-
-    alloc.dom = d->domain_id;
-    alloc.remote_dom = hardware_domain->domain_id;
-    rc = evtchn_alloc_unbound(&alloc, 0);
-    if ( rc )
-    {
-        printk("Failed allocating event channel for domain\n");
-        return rc;
-    }
-
-    d->arch.hvm.params[HVM_PARAM_STORE_EVTCHN] = alloc.port;
-
-    return 0;
+    /* Nothing to do */
 }
+#endif
 
-int __init construct_domU(struct domain *d,
-                          const struct dt_device_node *node)
+int __init init_vuart(struct domain *d, struct kernel_info *kinfo,
+                      const struct dt_device_node *node)
 {
-    struct kernel_info kinfo = KERNEL_INFO_INIT;
-    const char *dom0less_enhanced;
-    int rc;
-    u64 mem;
-    u32 p2m_mem_mb;
-    unsigned long p2m_pages;
-
-    rc = dt_property_read_u64(node, "memory", &mem);
-    if ( !rc )
-    {
-        printk("Error building DomU: cannot read \"memory\" property\n");
-        return -EINVAL;
-    }
-    kinfo.unassigned_mem = (paddr_t)mem * SZ_1K;
-
-    rc = dt_property_read_u32(node, "xen,domain-p2m-mem-mb", &p2m_mem_mb);
-    /* If xen,domain-p2m-mem-mb is not specified, use the default value. */
-    p2m_pages = rc ?
-                p2m_mem_mb << (20 - PAGE_SHIFT) :
-                domain_p2m_pages(mem, d->max_vcpus);
-
-    spin_lock(&d->arch.paging.lock);
-    rc = p2m_set_allocation(d, p2m_pages, NULL);
-    spin_unlock(&d->arch.paging.lock);
-    if ( rc != 0 )
-        return rc;
-
-    printk("*** LOADING DOMU cpus=%u memory=%#"PRIx64"KB ***\n",
-           d->max_vcpus, mem);
-
-    kinfo.vuart = dt_property_read_bool(node, "vpl011");
-
-    rc = dt_property_read_string(node, "xen,enhanced", &dom0less_enhanced);
-    if ( rc == -EILSEQ ||
-         rc == -ENODATA ||
-         (rc == 0 && !strcmp(dom0less_enhanced, "enabled")) )
-    {
-        if ( hardware_domain )
-            kinfo.dom0less_feature = DOM0LESS_ENHANCED;
-        else
-            panic("At the moment, Xenstore support requires dom0 to be present\n");
-    }
-    else if ( rc == 0 && !strcmp(dom0less_enhanced, "no-xenstore") )
-        kinfo.dom0less_feature = DOM0LESS_ENHANCED_NO_XS;
-
-    if ( vcpu_create(d, 0) == NULL )
-        return -ENOMEM;
-
-    d->max_pages = ((paddr_t)mem * SZ_1K) >> PAGE_SHIFT;
-
-    kinfo.d = d;
-
-    rc = kernel_probe(&kinfo, node);
-    if ( rc < 0 )
-        return rc;
-
-#ifdef CONFIG_ARM_64
-    /* type must be set before allocate memory */
-    d->arch.type = kinfo.arch.type;
-#endif
-    if ( !dt_find_property(node, "xen,static-mem", NULL) )
-        allocate_memory(d, &kinfo);
-    else if ( !is_domain_direct_mapped(d) )
-        allocate_static_memory(d, &kinfo, node);
-    else
-        assign_static_memory_11(d, &kinfo, node);
+    int rc = 0;
 
-    rc = process_shm(d, &kinfo, node);
-    if ( rc < 0 )
-        return rc;
+    kinfo->vuart = dt_property_read_bool(node, "vpl011");
 
     /*
      * Base address and irq number are needed when creating vpl011 device
      * tree node in prepare_dtb_domU, so initialization on related variables
      * shall be done first.
      */
-    if ( kinfo.vuart )
+    if ( kinfo->vuart )
     {
         rc = domain_vpl011_init(d, NULL);
         if ( rc < 0 )
             return rc;
     }
 
-    rc = prepare_dtb_domU(d, &kinfo);
-    if ( rc < 0 )
-        return rc;
-
-    rc = construct_domain(d, &kinfo);
-    if ( rc < 0 )
-        return rc;
-
-    if ( kinfo.dom0less_feature & DOM0LESS_XENSTORE )
-    {
-        ASSERT(hardware_domain);
-        rc = alloc_xenstore_evtchn(d);
-        if ( rc < 0 )
-            return rc;
-        d->arch.hvm.params[HVM_PARAM_STORE_PFN] = ~0ULL;
-    }
-
     return rc;
 }
 
-
 struct xen_domctl_createdomain __init arch_xen_domctl_createdomain(void)
 {
     struct xen_domctl_createdomain d_cfg = {
@@ -868,6 +353,22 @@ void __init arch_create_domus(struct dt_device_node *node,
     }
 }
 
+int __init init_intc_phandle(struct kernel_info *kinfo, const char *name,
+                             const int node_next, const void *pfdt)
+{
+    if ( dt_node_cmp(name, "gic") == 0 )
+    {
+        uint32_t phandle_intc = fdt_get_phandle(pfdt, node_next);
+
+        if ( phandle_intc != 0 )
+            kinfo->phandle_intc = phandle_intc;
+
+        return 0;
+    }
+
+    return 1;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
index 19bfa5e005..509f825ce6 100644
--- a/xen/common/device-tree/dom0less-build.c
+++ b/xen/common/device-tree/dom0less-build.c
@@ -3,17 +3,26 @@
 #include <xen/device_tree.h>
 #include <xen/domain.h>
 #include <xen/err.h>
+#include <xen/event.h>
 #include <xen/init.h>
+#include <xen/iocap.h>
 #include <xen/iommu.h>
+#include <xen/libfdt/libfdt.h>
 #include <xen/llc-coloring.h>
+#include <xen/sizes.h>
 #include <xen/sched.h>
 #include <xen/stdbool.h>
 #include <xen/types.h>
+#include <xen/vmap.h>
 
 #include <public/domctl.h>
 
+#include <asm/domain-build.h>
 #include <asm/dom0less-build.h>
+#include <asm/kernel.h>
 #include <asm/setup.h>
+#include <asm/static-memory.h>
+#include <asm/static-shmem.h>
 
 bool __init is_dom0less_mode(void)
 {
@@ -159,3 +168,553 @@ void __init create_domUs(void)
                   dt_node_name(node), rc);
     }
 }
+
+/*
+ * Scan device tree properties for passthrough specific information.
+ * Returns < 0 on error
+ *         0 on success
+ */
+static int __init handle_passthrough_prop(struct kernel_info *kinfo,
+                                          const struct fdt_property *xen_reg,
+                                          const struct fdt_property *xen_path,
+                                          bool xen_force,
+                                          uint32_t address_cells,
+                                          uint32_t size_cells)
+{
+    const __be32 *cell;
+    unsigned int i, len;
+    struct dt_device_node *node;
+    int res;
+    paddr_t mstart, size, gstart;
+
+    /* xen,reg specifies where to map the MMIO region */
+    cell = (const __be32 *)xen_reg->data;
+    len = fdt32_to_cpu(xen_reg->len) / ((address_cells * 2 + size_cells) *
+                                        sizeof(uint32_t));
+
+    for ( i = 0; i < len; i++ )
+    {
+        device_tree_get_reg(&cell, address_cells, size_cells,
+                            &mstart, &size);
+        gstart = dt_next_cell(address_cells, &cell);
+
+        if ( gstart & ~PAGE_MASK || mstart & ~PAGE_MASK || size & ~PAGE_MASK )
+        {
+            printk(XENLOG_ERR
+                   "DomU passthrough config has not page aligned addresses/sizes\n");
+            return -EINVAL;
+        }
+
+        res = iomem_permit_access(kinfo->d, paddr_to_pfn(mstart),
+                                  paddr_to_pfn(PAGE_ALIGN(mstart + size - 1)));
+        if ( res )
+        {
+            printk(XENLOG_ERR "Unable to permit to dom%d access to"
+                   " 0x%"PRIpaddr" - 0x%"PRIpaddr"\n",
+                   kinfo->d->domain_id,
+                   mstart & PAGE_MASK, PAGE_ALIGN(mstart + size) - 1);
+            return res;
+        }
+
+        res = map_regions_p2mt(kinfo->d,
+                               gaddr_to_gfn(gstart),
+                               PFN_DOWN(size),
+                               maddr_to_mfn(mstart),
+                               p2m_mmio_direct_dev);
+        if ( res < 0 )
+        {
+            printk(XENLOG_ERR
+                   "Failed to map %"PRIpaddr" to the guest at%"PRIpaddr"\n",
+                   mstart, gstart);
+            return -EFAULT;
+        }
+    }
+
+    /*
+     * If xen_force, we let the user assign a MMIO region with no
+     * associated path.
+     */
+    if ( xen_path == NULL )
+        return xen_force ? 0 : -EINVAL;
+
+    /*
+     * xen,path specifies the corresponding node in the host DT.
+     * Both interrupt mappings and IOMMU settings are based on it,
+     * as they are done based on the corresponding host DT node.
+     */
+    node = dt_find_node_by_path(xen_path->data);
+    if ( node == NULL )
+    {
+        printk(XENLOG_ERR "Couldn't find node %s in host_dt!\n",
+               xen_path->data);
+        return -EINVAL;
+    }
+
+    res = map_device_irqs_to_domain(kinfo->d, node, true, NULL);
+    if ( res < 0 )
+        return res;
+
+    res = iommu_add_dt_device(node);
+    if ( res < 0 )
+        return res;
+
+    /* If xen_force, we allow assignment of devices without IOMMU protection. */
+    if ( xen_force && !dt_device_is_protected(node) )
+        return 0;
+
+    return iommu_assign_dt_device(kinfo->d, node);
+}
+
+static int __init handle_prop_pfdt(struct kernel_info *kinfo,
+                                   const void *pfdt, int nodeoff,
+                                   uint32_t address_cells, uint32_t size_cells,
+                                   bool scan_passthrough_prop)
+{
+    void *fdt = kinfo->fdt;
+    int propoff, nameoff, res;
+    const struct fdt_property *prop, *xen_reg = NULL, *xen_path = NULL;
+    const char *name;
+    bool found, xen_force = false;
+
+    for ( propoff = fdt_first_property_offset(pfdt, nodeoff);
+          propoff >= 0;
+          propoff = fdt_next_property_offset(pfdt, propoff) )
+    {
+        if ( !(prop = fdt_get_property_by_offset(pfdt, propoff, NULL)) )
+            return -FDT_ERR_INTERNAL;
+
+        found = false;
+        nameoff = fdt32_to_cpu(prop->nameoff);
+        name = fdt_string(pfdt, nameoff);
+
+        if ( scan_passthrough_prop )
+        {
+            if ( dt_prop_cmp("xen,reg", name) == 0 )
+            {
+                xen_reg = prop;
+                found = true;
+            }
+            else if ( dt_prop_cmp("xen,path", name) == 0 )
+            {
+                xen_path = prop;
+                found = true;
+            }
+            else if ( dt_prop_cmp("xen,force-assign-without-iommu",
+                                  name) == 0 )
+            {
+                xen_force = true;
+                found = true;
+            }
+        }
+
+        /*
+         * Copy properties other than the ones above: xen,reg, xen,path,
+         * and xen,force-assign-without-iommu.
+         */
+        if ( !found )
+        {
+            res = fdt_property(fdt, name, prop->data, fdt32_to_cpu(prop->len));
+            if ( res )
+                return res;
+        }
+    }
+
+    /*
+     * Only handle passthrough properties if both xen,reg and xen,path
+     * are present, or if xen,force-assign-without-iommu is specified.
+     */
+    if ( xen_reg != NULL && (xen_path != NULL || xen_force) )
+    {
+        res = handle_passthrough_prop(kinfo, xen_reg, xen_path, xen_force,
+                                      address_cells, size_cells);
+        if ( res < 0 )
+        {
+            printk(XENLOG_ERR "Failed to assign device to %pd\n", kinfo->d);
+            return res;
+        }
+    }
+    else if ( (xen_path && !xen_reg) || (xen_reg && !xen_path && !xen_force) )
+    {
+        printk(XENLOG_ERR "xen,reg or xen,path missing for %pd\n",
+               kinfo->d);
+        return -EINVAL;
+    }
+
+    /* FDT_ERR_NOTFOUND => There is no more properties for this node */
+    return ( propoff != -FDT_ERR_NOTFOUND ) ? propoff : 0;
+}
+
+static int __init scan_pfdt_node(struct kernel_info *kinfo, const void *pfdt,
+                                 int nodeoff,
+                                 uint32_t address_cells, uint32_t size_cells,
+                                 bool scan_passthrough_prop)
+{
+    int rc = 0;
+    void *fdt = kinfo->fdt;
+    int node_next;
+
+    rc = fdt_begin_node(fdt, fdt_get_name(pfdt, nodeoff, NULL));
+    if ( rc )
+        return rc;
+
+    rc = handle_prop_pfdt(kinfo, pfdt, nodeoff, address_cells, size_cells,
+                          scan_passthrough_prop);
+    if ( rc )
+        return rc;
+
+    address_cells = device_tree_get_u32(pfdt, nodeoff, "#address-cells",
+                                        DT_ROOT_NODE_ADDR_CELLS_DEFAULT);
+    size_cells = device_tree_get_u32(pfdt, nodeoff, "#size-cells",
+                                     DT_ROOT_NODE_SIZE_CELLS_DEFAULT);
+
+    node_next = fdt_first_subnode(pfdt, nodeoff);
+    while ( node_next > 0 )
+    {
+        rc = scan_pfdt_node(kinfo, pfdt, node_next, address_cells, size_cells,
+                            scan_passthrough_prop);
+        if ( rc )
+            return rc;
+
+        node_next = fdt_next_subnode(pfdt, node_next);
+    }
+
+    return fdt_end_node(fdt);
+}
+
+static int __init check_partial_fdt(void *pfdt, size_t size)
+{
+    int res;
+
+    if ( fdt_magic(pfdt) != FDT_MAGIC )
+    {
+        dprintk(XENLOG_ERR, "Partial FDT is not a valid Flat Device Tree");
+        return -EINVAL;
+    }
+
+    res = fdt_check_header(pfdt);
+    if ( res )
+    {
+        dprintk(XENLOG_ERR, "Failed to check the partial FDT (%d)", res);
+        return -EINVAL;
+    }
+
+    if ( fdt_totalsize(pfdt) > size )
+    {
+        dprintk(XENLOG_ERR, "Partial FDT totalsize is too big");
+        return -EINVAL;
+    }
+
+    return 0;
+}
+
+static int __init domain_handle_dtb_bootmodule(struct domain *d,
+                                               struct kernel_info *kinfo)
+{
+    void *pfdt;
+    int res, node_next;
+
+    pfdt = ioremap_cache(kinfo->dtb_bootmodule->start,
+                         kinfo->dtb_bootmodule->size);
+    if ( pfdt == NULL )
+        return -EFAULT;
+
+    res = check_partial_fdt(pfdt, kinfo->dtb_bootmodule->size);
+    if ( res < 0 )
+        goto out;
+
+    for ( node_next = fdt_first_subnode(pfdt, 0);
+          node_next > 0;
+          node_next = fdt_next_subnode(pfdt, node_next) )
+    {
+        const char *name = fdt_get_name(pfdt, node_next, NULL);
+
+        if ( name == NULL )
+            continue;
+
+        /*
+         * Only scan /$(interrupt_controller) /aliases /passthrough,
+         * ignore the rest.
+         * They don't have to be parsed in order.
+         *
+         * Take the interrupt controller phandle value from the special
+         * interrupt controller node in the DTB fragment.
+         */
+        if ( init_intc_phandle(kinfo, name, node_next, pfdt) == 0 )
+            continue;
+
+        if ( dt_node_cmp(name, "aliases") == 0 )
+        {
+            res = scan_pfdt_node(kinfo, pfdt, node_next,
+                                 DT_ROOT_NODE_ADDR_CELLS_DEFAULT,
+                                 DT_ROOT_NODE_SIZE_CELLS_DEFAULT,
+                                 false);
+            if ( res )
+                goto out;
+            continue;
+        }
+        if ( dt_node_cmp(name, "passthrough") == 0 )
+        {
+            res = scan_pfdt_node(kinfo, pfdt, node_next,
+                                 DT_ROOT_NODE_ADDR_CELLS_DEFAULT,
+                                 DT_ROOT_NODE_SIZE_CELLS_DEFAULT,
+                                 true);
+            if ( res )
+                goto out;
+            continue;
+        }
+    }
+
+ out:
+    iounmap(pfdt);
+
+    return res;
+}
+
+static unsigned long __init domain_p2m_pages(unsigned long maxmem_kb,
+                                             unsigned int smp_cpus)
+{
+    /*
+     * Keep in sync with libxl__get_required_paging_memory().
+     * 256 pages (1MB) per vcpu, plus 1 page per MiB of RAM for the P2M map,
+     * plus 128 pages to cover extended regions.
+     */
+    unsigned long memkb = 4 * (256 * smp_cpus + (maxmem_kb / 1024) + 128);
+
+    BUILD_BUG_ON(PAGE_SIZE != SZ_4K);
+
+    return DIV_ROUND_UP(memkb, 1024) << (20 - PAGE_SHIFT);
+}
+
+/*
+ * The max size for DT is 2MB. However, the generated DT is small (not including
+ * domU passthrough DT nodes whose size we account separately), 4KB are enough
+ * for now, but we might have to increase it in the future.
+ */
+#define DOMU_DTB_SIZE 4096
+static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo)
+{
+    int addrcells, sizecells;
+    int ret, fdt_size = DOMU_DTB_SIZE;
+
+    kinfo->phandle_intc = GUEST_PHANDLE_GIC;
+
+#ifdef CONFIG_GRANT_TABLE
+    kinfo->gnttab_start = GUEST_GNTTAB_BASE;
+    kinfo->gnttab_size = GUEST_GNTTAB_SIZE;
+#endif
+
+    addrcells = GUEST_ROOT_ADDRESS_CELLS;
+    sizecells = GUEST_ROOT_SIZE_CELLS;
+
+    /* Account for domU passthrough DT size */
+    if ( kinfo->dtb_bootmodule )
+        fdt_size += kinfo->dtb_bootmodule->size;
+
+    /* Cap to max DT size if needed */
+    fdt_size = min(fdt_size, SZ_2M);
+
+    kinfo->fdt = xmalloc_bytes(fdt_size);
+    if ( kinfo->fdt == NULL )
+        return -ENOMEM;
+
+    ret = fdt_create(kinfo->fdt, fdt_size);
+    if ( ret < 0 )
+        goto err;
+
+    ret = fdt_finish_reservemap(kinfo->fdt);
+    if ( ret < 0 )
+        goto err;
+
+    ret = fdt_begin_node(kinfo->fdt, "");
+    if ( ret < 0 )
+        goto err;
+
+    ret = fdt_property_cell(kinfo->fdt, "#address-cells", addrcells);
+    if ( ret )
+        goto err;
+
+    ret = fdt_property_cell(kinfo->fdt, "#size-cells", sizecells);
+    if ( ret )
+        goto err;
+
+    ret = make_chosen_node(kinfo);
+    if ( ret )
+        goto err;
+
+    ret = make_cpus_node(d, kinfo->fdt);
+    if ( ret )
+        goto err;
+
+    ret = make_memory_node(kinfo, addrcells, sizecells,
+                           kernel_info_get_mem(kinfo));
+    if ( ret )
+        goto err;
+
+    ret = make_resv_memory_node(kinfo, addrcells, sizecells);
+    if ( ret )
+        goto err;
+
+    /*
+     * domain_handle_dtb_bootmodule has to be called before the rest of
+     * the device tree is generated because it depends on the value of
+     * the field phandle_intc.
+     */
+    if ( kinfo->dtb_bootmodule )
+    {
+        ret = domain_handle_dtb_bootmodule(d, kinfo);
+        if ( ret )
+            goto err;
+    }
+
+    ret = make_intc_domU_node(kinfo);
+    if ( ret )
+        goto err;
+
+    ret = make_timer_node(kinfo);
+    if ( ret )
+        goto err;
+
+    if ( kinfo->dom0less_feature & DOM0LESS_ENHANCED_NO_XS )
+    {
+        ret = make_hypervisor_node(d, kinfo, addrcells, sizecells);
+        if ( ret )
+            goto err;
+    }
+
+    ret = make_arch_nodes(kinfo);
+    if ( ret )
+        goto err;
+
+    ret = fdt_end_node(kinfo->fdt);
+    if ( ret < 0 )
+        goto err;
+
+    ret = fdt_finish(kinfo->fdt);
+    if ( ret < 0 )
+        goto err;
+
+    return 0;
+
+  err:
+    printk("Device tree generation failed (%d).\n", ret);
+    xfree(kinfo->fdt);
+
+    return -EINVAL;
+}
+
+static int __init alloc_xenstore_evtchn(struct domain *d)
+{
+    evtchn_alloc_unbound_t alloc;
+    int rc;
+
+    alloc.dom = d->domain_id;
+    alloc.remote_dom = hardware_domain->domain_id;
+    rc = evtchn_alloc_unbound(&alloc, 0);
+    if ( rc )
+    {
+        printk("Failed allocating event channel for domain\n");
+        return rc;
+    }
+
+#ifdef CONFIG_HVM
+    d->arch.hvm.params[HVM_PARAM_STORE_EVTCHN] = alloc.port;
+#endif
+
+    return 0;
+}
+
+int __init construct_domU(struct domain *d,
+                          const struct dt_device_node *node)
+{
+    struct kernel_info kinfo = KERNEL_INFO_INIT;
+    const char *dom0less_enhanced;
+    int rc;
+    u64 mem;
+    u32 p2m_mem_mb;
+    unsigned long p2m_pages;
+
+    rc = dt_property_read_u64(node, "memory", &mem);
+    if ( !rc )
+    {
+        printk("Error building DomU: cannot read \"memory\" property\n");
+        return -EINVAL;
+    }
+    kinfo.unassigned_mem = (paddr_t)mem * SZ_1K;
+
+    rc = dt_property_read_u32(node, "xen,domain-p2m-mem-mb", &p2m_mem_mb);
+    /* If xen,domain-p2m-mem-mb is not specified, use the default value. */
+    p2m_pages = rc ?
+                p2m_mem_mb << (20 - PAGE_SHIFT) :
+                domain_p2m_pages(mem, d->max_vcpus);
+
+    spin_lock(&d->arch.paging.lock);
+    rc = p2m_set_allocation(d, p2m_pages, NULL);
+    spin_unlock(&d->arch.paging.lock);
+    if ( rc != 0 )
+        return rc;
+
+    printk("*** LOADING DOMU cpus=%u memory=%#"PRIx64"KB ***\n",
+           d->max_vcpus, mem);
+
+    rc = dt_property_read_string(node, "xen,enhanced", &dom0less_enhanced);
+    if ( rc == -EILSEQ ||
+         rc == -ENODATA ||
+         (rc == 0 && !strcmp(dom0less_enhanced, "enabled")) )
+    {
+        if ( hardware_domain )
+            kinfo.dom0less_feature = DOM0LESS_ENHANCED;
+        else
+            panic("At the moment, Xenstore support requires dom0 to be present\n");
+    }
+    else if ( rc == 0 && !strcmp(dom0less_enhanced, "no-xenstore") )
+        kinfo.dom0less_feature = DOM0LESS_ENHANCED_NO_XS;
+
+    if ( vcpu_create(d, 0) == NULL )
+        return -ENOMEM;
+
+    d->max_pages = ((paddr_t)mem * SZ_1K) >> PAGE_SHIFT;
+
+    kinfo.d = d;
+
+    rc = kernel_probe(&kinfo, node);
+    if ( rc < 0 )
+        return rc;
+
+    set_domain_type(d, &kinfo);
+
+    if ( !dt_find_property(node, "xen,static-mem", NULL) )
+        allocate_memory(d, &kinfo);
+    else if ( !is_domain_direct_mapped(d) )
+        allocate_static_memory(d, &kinfo, node);
+    else
+        assign_static_memory_11(d, &kinfo, node);
+
+    rc = process_shm(d, &kinfo, node);
+    if ( rc < 0 )
+        return rc;
+
+    rc = init_vuart(d, &kinfo, node);
+    if ( rc < 0 )
+        return rc;
+
+    rc = prepare_dtb_domU(d, &kinfo);
+    if ( rc < 0 )
+        return rc;
+
+    rc = construct_domain(d, &kinfo);
+    if ( rc < 0 )
+        return rc;
+
+    if ( kinfo.dom0less_feature & DOM0LESS_XENSTORE )
+    {
+        ASSERT(hardware_domain);
+        rc = alloc_xenstore_evtchn(d);
+        if ( rc < 0 )
+            return rc;
+#ifdef CONFIG_HVM
+        d->arch.hvm.params[HVM_PARAM_STORE_PFN] = ~0ULL;
+#endif
+    }
+
+    return rc;
+}
diff --git a/xen/include/asm-generic/dom0less-build.h b/xen/include/asm-generic/dom0less-build.h
index a6985bc20a..3e4af9dcce 100644
--- a/xen/include/asm-generic/dom0less-build.h
+++ b/xen/include/asm-generic/dom0less-build.h
@@ -8,6 +8,9 @@
 
 #include <public/domctl.h>
 
+struct kernel_info;
+struct dt_device_node;
+
 void create_domUs(void);
 bool is_dom0less_mode(void);
 
@@ -18,6 +21,17 @@ void arch_create_domus(struct dt_device_node *node,
                        struct xen_domctl_createdomain *d_cfg,
                        unsigned int flags);
 
+int init_vuart(struct domain *d, struct kernel_info *kinfo,
+               const struct dt_device_node *node);
+
+int make_intc_domU_node(struct kernel_info *kinfo);
+int make_arch_nodes(struct kernel_info *kinfo);
+
+void set_domain_type(struct domain *d, struct kernel_info *kinfo);
+
+int init_intc_phandle(struct kernel_info *kinfo, const char *name,
+                      const int node_next, const void *pfdt);
+
 #else /* !CONFIG_DOM0LESS_BOOT */
 
 static inline void create_domUs(void) {}
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 12:23:49 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 12:23:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867225.1278668 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVV5w-0000Kb-MC; Wed, 08 Jan 2025 12:23:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867225.1278668; Wed, 08 Jan 2025 12:23:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVV5w-0000KU-HO; Wed, 08 Jan 2025 12:23:32 +0000
Received: by outflank-mailman (input) for mailman id 867225;
 Wed, 08 Jan 2025 12:23:31 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=UrZA=UA=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tVV5v-0000K3-N5
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 12:23:31 +0000
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com
 [2a00:1450:4864:20::42b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5e86ca36-cdbb-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 13:23:30 +0100 (CET)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-385e87b25f0so507047f8f.0
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 04:23:30 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c8a6e19sm52551601f8f.100.2025.01.08.04.23.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 08 Jan 2025 04:23:29 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5e86ca36-cdbb-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736339009; x=1736943809; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=kK/jXtI+dJe56Qsa42MyiZmxNk7xm2jG5SaoTFrk4s0=;
        b=g+YUD1yAb6hEVoW5Zfy6nYXWaLSNitRJGK+J9n+ViU3lG07hlf3RLB7S0BcaC3YvVL
         xwQnb2eqJrg8OyDhJwaTt7eY8OtysZ4g0mvS8naqmYyg+bkSIFi3DvHR8/RR2PP9WaDY
         0H4IUfhY/IomtP78cu2/ryumdumsZl9ckHI2g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736339009; x=1736943809;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=kK/jXtI+dJe56Qsa42MyiZmxNk7xm2jG5SaoTFrk4s0=;
        b=amvoIquOM7T/0N19fQirB2GACN5XGPfjfkcxFWyg6WlBU3EFVSVDpUAUO5U9HQz7kv
         A0PmQXJmM/JBggxzD238904LWf1ujppPXg6mILpeD7PcSjsi1abtX1755CR9kdpadv2q
         0TI7bQOEMF83tublp/GMskcZY6k7VNxf0e3CBDFqGTzRLefsJB8DwDB2+ARbqC0nGg6X
         D/Uj7cBxjMEPNTM6sKwZ2JOvNNNG+iE3br9/yYIg0CN/szdgpzuInBaUiQkDFRBIiut4
         3AzAFNuwPKzYqm2hsFxkIhUUf7zFbY9Dp1voMJSzvihYUX8c+upOWtTDeOAhKBFKz709
         e6aQ==
X-Forwarded-Encrypted: i=1; AJvYcCXIFm5jEIc53Tq49s04qCwpnTbj52z+k1iTCoWqTx0Ju3cavGcLuSR0kQ+ezzcfhUrSLEURDoJLrbk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxPMTPocv4S9xlLtdAzdTGSzWw3OQkpj8nuKprAcZisI0NibNpx
	bct/QqFO+oRhtWDI0A3R/dwmZEyRKs0RHz8sg9GQHtYz7SvrCORTOTYxXfUIjGc=
X-Gm-Gg: ASbGnctfHMMNbIwXWnY7Yy8Fec/HaeozfClFMHJsyy6mrb7jBlEL7DqYDI06gwvVMvR
	x9SPk467e90h787fkhevpT6IxjDXCIm4faJzzvz2P5EtMu9MXMKlvt2FlMzH/2gzOAVSMtJPzeE
	3S6vdYO6KYVUuW0eumZg06NtzicSO6sNjqFZ/kxcBNg9PJ6dbgMOe5aOLF8R6qR/e+TVGMOIDE1
	dCR40DA6IHOGCJQ9q0U0FbvNDneU3cS9/bzAOvZV5OnylHu5LBrEAKBU5VoSIG0rjyigrp8Ncg8
	wRidY8man+mR5GDP960C
X-Google-Smtp-Source: AGHT+IHsD7vWiO1k+NKZ9jB1PotOEbzLvSxqQh3NBC+XZRPwF3nhNpzQi7XrOH40DRKATuo8cE2kQQ==
X-Received: by 2002:a05:6000:1446:b0:388:cacf:24b0 with SMTP id ffacd0b85a97d-38a791253dbmr5017895f8f.2.1736339009621;
        Wed, 08 Jan 2025 04:23:29 -0800 (PST)
Message-ID: <00662cf8-7bff-4963-8b52-5df2e6a75132@citrix.com>
Date: Wed, 8 Jan 2025 12:23:28 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/2] x86: Add Support for Paging-Write Feature
To: Jan Beulich <jbeulich@suse.com>, =?UTF-8?Q?Petr_Bene=C5=A1?=
 <w1benny@gmail.com>
Cc: Tamas K Lengyel <tamas@tklengyel.com>,
 Alexandru Isaila <aisaila@bitdefender.com>,
 Petre Pircalabu <ppircalabu@bitdefender.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <cover.1735837806.git.w1benny@gmail.com>
 <31a1ff2d5d1e17bb73231e008f1e47c501bb3ce8.1735837806.git.w1benny@gmail.com>
 <d6eb70a7-5895-4471-95b3-609f133fa457@suse.com>
 <CAKBKdXjJm5194Wa=gy=DikiUEsevrB2Xn-idr+vgfgJMBrfZ-w@mail.gmail.com>
 <b182555c-555e-4efc-94a0-5f383f7d8689@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <b182555c-555e-4efc-94a0-5f383f7d8689@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 08/01/2025 7:16 am, Jan Beulich wrote:
> On 07.01.2025 18:18, Petr Beneš wrote:
>> On Tue, Jan 7, 2025 at 5:46 PM Jan Beulich <jbeulich@suse.com> wrote:
>>> Hmm ... Instead of you touching the bit in every one of the case blocks,
>>> I was expecting you to clear the bit ahead of the switch(), accepting a
>>> double update in the p2m_access_r_pw case.
>> I did consider it, but ultimately didn't like the double-update.
>> Similarly, the switch-case above does also set each bit in the
>> "case-s" individually. But I understand it's more justified there.
> Right - it's setting them to all different combinations each time.
>
>> However, if you insist, I'll fix it.
> Please do; it helps readability quite a bit in this case, imo.

I agree.

These "writes" are just bit operations on a single register.  The
compiler is pretty good at rearranging such logic.

Seeing as this is the only issue, I'm happy to fix on commit?

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Jan 08 12:29:08 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 12:29:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867233.1278678 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVVBJ-0000yB-6u; Wed, 08 Jan 2025 12:29:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867233.1278678; Wed, 08 Jan 2025 12:29:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVVBJ-0000y4-3g; Wed, 08 Jan 2025 12:29:05 +0000
Received: by outflank-mailman (input) for mailman id 867233;
 Wed, 08 Jan 2025 12:29:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=UrZA=UA=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tVVBH-0000xy-Un
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 12:29:03 +0000
Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com
 [2a00:1450:4864:20::342])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 23c5f708-cdbc-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 13:29:02 +0100 (CET)
Received: by mail-wm1-x342.google.com with SMTP id
 5b1f17b1804b1-4361b6f9faeso5073175e9.1
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 04:29:01 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436e2e89dfesm19241675e9.32.2025.01.08.04.28.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 08 Jan 2025 04:28:59 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 23c5f708-cdbc-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736339340; x=1736944140; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:to:subject:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=5PxNIfQRmBZ6wb4IiRIM8vasBb8L45u3BgTYRBUPMNs=;
        b=QEcG1WHBaRZQKfm3KJEzxVnHvKO3haauL1Q3eaOnSvjRa75f4mn6PvgiNl08qlVxi5
         ma/6OL1ZGGmTQC282StHO9sAmGfdPmxL27uzg7IhyEp2xI2BeYHWOPma1UPQN8tWSf04
         56FtTRYh9SkIa9lybHL2HNe9xSt+3HvG52GCw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736339340; x=1736944140;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=5PxNIfQRmBZ6wb4IiRIM8vasBb8L45u3BgTYRBUPMNs=;
        b=aMbkde0TUS/B8KWLiHJpk3deWyYMRS6Df/Ce5UOIwIzQh2Gf92WzIcQbR7voZ6auQi
         FybZye7zlCUz9OtqWsLAYfvnTzY/9inBHVaGYd6YT/e5qc+7Wxw6VUplwWntE/2L1NTK
         HppZcEGpsvZ9OWbCUZaMxd5hM/72jNDDlWN7jIvIWpBYMj9Gegg+ZzjObcKDz8kJkA65
         LLUE15sE2YqSOkIy8xl8hhTHUlznGmL5/swVt4aeEQSRW0wOz9/ENQ/0Kv7s5oHas/LT
         GYEY6nMEIMolY8gGpLp2oBki8yKe3oZtBWSYWyvfLVQqMaGLNyyAby2fr1W+wlTsKDs/
         CT+w==
X-Forwarded-Encrypted: i=1; AJvYcCXN1eBNb25tioNoZ/6MAfT1zczQ7eV1thHhC8o/6rRMhuSdcZv11wVN0t1Ti66Mxlhfw2C031z8QBg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwjAzjgsMGqPK8MS+gEpMuFoP0IeF7CTqa747Kl5fflRk3ra6kM
	pEpBysyeWEaUxbB6L5HXC31cHPFsuzYKzc5JEDKbNLgroNK0a2DDv6C/JEuBXGvhCduEA/BzxFB
	cL2xvEMV/
X-Gm-Gg: ASbGncvVD/xf38C5k5OFBaZkgoYZ4H/8s/QHRCfej2rxRE4HJ8kWQPXiLToM+I8jKMq
	m38mzQ/SIwQA2gZERCwUXIdwL1UjS0/3dXttBz+MU8koTQGy7el/R2YygHOVBAW83qKIii4Oc2t
	kDTmNRN0PL2jrR1TWdMdG4g9WYjZBtifw/Ir/cGnZ4Ujyfw75dZNvW4jSWbjZRCoCr3ofz6gpoa
	PHMDEQkVFTcAYjhFm6lQ26yihncTKebkzuSiQgd7JykyuxgiNqKqbOiMUuVZxn/idfSm+gQ1qJt
	Y6Ps1ctMBRSAIxDhG/4v
X-Google-Smtp-Source: AGHT+IF6zkPCvXxzP7t94XGH8eF75liMG9LwnzDo96esU2GxiWQpyBBitNrQB5vdBWH2/lZCl8lsWg==
X-Received: by 2002:a05:600c:3b85:b0:434:fddf:5c06 with SMTP id 5b1f17b1804b1-436e1dcac5fmr23360885e9.1.1736339340361;
        Wed, 08 Jan 2025 04:29:00 -0800 (PST)
Message-ID: <ec27ede3-b911-4495-aabb-fee8399055ce@citrix.com>
Date: Wed, 8 Jan 2025 12:28:59 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Bug: Hyperlinks in generated documentation may point to the wrong
 architecture
To: Maximilian Engelhardt <maxi@daemonizer.de>, xen-devel@lists.xenproject.org
References: <2293976.iZASKD2KPV@localhost>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <2293976.iZASKD2KPV@localhost>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 30/12/2024 8:56 pm, Maximilian Engelhardt wrote:
> Hello,
>
> during working on packaging Xen in Debian I noticed the documentation becomes 
> non-reproducible as hyperlinks may point to the wrong architecture.
>
> Here an example as diff showing the problem:
>
> /usr/share/doc/xen/html/hypercall/arm/include,public,arch-arm.h.html
> @@ -313,15 +313,15 @@
>      uint64_t sctlr;
>      uint64_t ttbcr, ttbr0, ttbr1;
>  };
>  typedef <a href="include,public,arch-arm.h.html#Struct_vcpu_guest_context">struct vcpu_guest_context</a> <a  name="Typedef_vcpu_guest_context_t"><strong>vcpu_guest_context_t</strong></a>;
>  DEFINE_XEN_GUEST_HANDLE(<a href="include,public,arch-arm.h.html#Struct_vcpu_guest_context">vcpu_guest_context_t</a>);
>  
>  /*
> - * <a href="include,public,arch-arm.h.html#Struct_xen_arch_domainconfig">struct xen_arch_domainconfig</a>'s ABI is covered by
> + * <a href="include,public,arch-ppc.h.html#Struct_xen_arch_domainconfig">struct xen_arch_domainconfig</a>'s ABI is covered by
>   * XEN_DOMCTL_INTERFACE_VERSION.
>   */
>  #define XEN_DOMCTL_CONFIG_GIC_NATIVE    0
>  #define XEN_DOMCTL_CONFIG_GIC_V2        1
>  #define XEN_DOMCTL_CONFIG_GIC_V3        2
>  
>  #define XEN_DOMCTL_CONFIG_TEE_NONE      0
>
>
> As can be seen, the hyperlink in include,public,arch-arm.h.html points to 
> include,public,arch-ppc.h.html while it should point to include,public,arch-
> arm.h.html.
> A similar problem can be found in many more places and files.
>
> Corresponding to the problem described above, while building the documentation 
> many messages similar to the last lines below can be seen in the build log:
>
> /usr/bin/perl -w /build/reproducible-path/xen-4.19.1/docs/xen-headers -O html/hypercall/arm \
>         -T 'arch-arm - Xen public headers' \
>         -X arch-x86_32 -X arch-x86_64 \
>         -X xen-x86_32 -X xen-x86_64 \
>         -X arch-x86 \
>         /build/reproducible-path/xen-4.19.1/docs/../xen include/public include/xen/errno.h
> include/public/arch-ppc.h:91: multiple definitions of Typedef vcpu_guest_core_regs_t: include/public/arch-arm.h:300
> include/public/arch-ppc.h:91: multiple definitions of Typedef vcpu_guest_core_regs_t: include/public/arch-ppc.h:85
> include/public/arch-ppc.h:91: multiple definitions of Typedef vcpu_guest_core_regs_t: include/public/arch-arm.h:300
> include/public/arch-ppc.h:91: multiple definitions of Typedef vcpu_guest_core_regs_t: include/public/arch-ppc.h:85
> include/public/arch-ppc.h:95: multiple definitions of Struct vcpu_guest_context: include/public/arch-ppc.h:90
> include/public/arch-ppc.h:95: multiple definitions of Struct vcpu_guest_context: include/public/arch-arm.h:305
> include/public/arch-ppc.h:95: multiple definitions of Struct vcpu_guest_context: include/public/arch-ppc.h:90
> include/public/arch-ppc.h:95: multiple definitions of Struct vcpu_guest_context: include/public/arch-arm.h:305
> [...]
>
>
> In Debian we worked around the problem for now by adding ppc and riscv to 
> DOC_ARCHES in docs/Makefile as can be seen in [1]. This solves all the 
> described problems and makes the build reproducible again. I assume another 
> possible fix would be adding suitable ignore switches for ppc and riscv.
>
> I did not send this as a patch as I'm not sure what the preferred upstream 
> solution to this problem is, but can formally submit our fix as a patch if 
> that's desired.
>
> Thanks,
> Maxi
>
> [1] https://salsa.debian.org/xen-team/debian-xen/-/commit/d852c48d0df5c6ceba42d20652d1f9a05ad8989e 

This is a giant not-invented-here mess which needs filing in /dev/null.

The fact that you're the first to notice the incorrect linking (and only
via reproducible-build tooling) shows how many people read these docs.

I'm happy with that minimal fix, and it ought to be backported.  Please
submit it formally.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Jan 08 12:43:29 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 12:43:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867241.1278687 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVVP8-00040h-CE; Wed, 08 Jan 2025 12:43:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867241.1278687; Wed, 08 Jan 2025 12:43:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVVP8-00040a-9R; Wed, 08 Jan 2025 12:43:22 +0000
Received: by outflank-mailman (input) for mailman id 867241;
 Wed, 08 Jan 2025 12:43:21 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=UrZA=UA=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tVVP7-00040U-CV
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 12:43:21 +0000
Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com
 [2a00:1450:4864:20::341])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 234b4a41-cdbe-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 13:43:19 +0100 (CET)
Received: by mail-wm1-x341.google.com with SMTP id
 5b1f17b1804b1-436281c8a38so119644275e9.3
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 04:43:19 -0800 (PST)
Received: from andrewcoop.eng.citrite.net (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436e2e92f6dsm19488485e9.41.2025.01.08.04.43.17
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 04:43:17 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 234b4a41-cdbe-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736340198; x=1736944998; 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=AhJ0XqV0uUxMeiwSIzR7h7QIT6TIMzwX/Ln5MLcHnmU=;
        b=VTu42J/hpu9c+GLuu5xy17RkE9mhfBOam/XU6IeMGzdWHge4pLlJXglA2gVKuod4E9
         lbcC/4cR30v7+FcQYN0F6Rt6UfBXDfdsuO1ymxYsSV2q/vgCRnL5AQ87KxhbJqb+0K/B
         QevfgP7XM+tKm4aK00EHaWiyIKZC8oU1tDFZA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736340198; x=1736944998;
        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=AhJ0XqV0uUxMeiwSIzR7h7QIT6TIMzwX/Ln5MLcHnmU=;
        b=FbKulChYxoeUxG+/du1MkGkc8lzoz5Xr3Ja9NYIRXCQxc+HyyVzJIUTnGZf4ci7GnF
         VMV4R/j9GKx9tPrx9mQ8ngXR0dC1Sy14wseotcjMWhb9zVfX+V8ymavk0ADkD1NJLx1j
         QtzKPXSPIdS2DusIo8CaES1ZxbLznG6nPZR0N+bKzbJAxWWTcxO6BdHIzxf8avdl0Cec
         e+xjKZK95jaS0Jkrqzwq1B5BRxrGhE7Y0OAhUBkwUqJhUtwXkP/IwDqJN++m3gLt5xyz
         2ODUBLVZkmPikSXsHwSfEdSZo5SUqeM2advLUR2rt0rR+7PsO/fJIJSCJavmOEJ57GWv
         XlyA==
X-Gm-Message-State: AOJu0YwcW3vImwJk10Nn+JAam6CuAdtLWX4rcb4koIl1l4IZMyCXJ8VL
	O6onfStLOtlCeQPLFfw6ftQW/XTBm4mJyxHpliLbdsytfcCq3sLoKfIHfiP2s30V6aOdDQ2qj7D
	M2D5UBYZd
X-Gm-Gg: ASbGncvdMGepkvWXXOrx8hkJpnllrkHn0E/LCOgOx7yM9JHrupXg8/WS8obZ4B8HTXU
	mzC4gTxTng0EUhl0GyASsJHCVmvV2Q9bdMBaqyRp2FObr8xbM2NHXh8aWNSsXQ9JME0TfTQ1C6v
	jfloFSTm54TY0e0k9M1qF2e2xY1uYQW3zVmdZ8EnH1gL4x/zS1dbAxDWiRg0VP2UlTo8LRKik0s
	gbtxPse93XXWQtSLvh637lnkThUeOPZtqR2TXxHG7KL9YZa5Jl+Hsx/E5AJofZNdlB4WG+qRK1p
	AUySm9M+CDgsH065BBzhInHw7CChcbkh4YWT
X-Google-Smtp-Source: AGHT+IEJh3zsYwwJQ1at6WrX2AoGDz6QQY8BsMJU8UW9wiHXc/5DHGHwoTBlZZQjUmkG5j99VmjdBg==
X-Received: by 2002:a05:600c:198c:b0:435:306:e5dd with SMTP id 5b1f17b1804b1-436e26f47e0mr19552965e9.22.1736340197914;
        Wed, 08 Jan 2025 04:43:17 -0800 (PST)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Michal Orzel <michal.orzel@amd.com>,
	Doug Goldstein <cardoe@cardoe.com>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
Subject: [PATCH for-4.20] CI: Update Fedora to 41
Date: Wed,  8 Jan 2025 12:43:16 +0000
Message-Id: <20250108124316.1107121-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Anthony PERARD <anthony.perard@vates.tech>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Michal Orzel <michal.orzel@amd.com>
CC: Doug Goldstein <cardoe@cardoe.com>
CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
CC: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/1616092048
---
 .../fedora/{40-x86_64.dockerfile => 41-x86_64.dockerfile} | 2 +-
 automation/gitlab-ci/build.yaml                           | 8 ++++----
 automation/scripts/containerize                           | 2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)
 rename automation/build/fedora/{40-x86_64.dockerfile => 41-x86_64.dockerfile} (97%)

diff --git a/automation/build/fedora/40-x86_64.dockerfile b/automation/build/fedora/41-x86_64.dockerfile
similarity index 97%
rename from automation/build/fedora/40-x86_64.dockerfile
rename to automation/build/fedora/41-x86_64.dockerfile
index 7d4d4cc2ac0a..8032a2098632 100644
--- a/automation/build/fedora/40-x86_64.dockerfile
+++ b/automation/build/fedora/41-x86_64.dockerfile
@@ -1,5 +1,5 @@
 # syntax=docker/dockerfile:1
-FROM --platform=linux/amd64 fedora:40
+FROM --platform=linux/amd64 fedora:41
 LABEL maintainer.name="The Xen Project"
 LABEL maintainer.email="xen-devel@lists.xenproject.org"
 
diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
index 41f17ed45641..3abd2a0c6575 100644
--- a/automation/gitlab-ci/build.yaml
+++ b/automation/gitlab-ci/build.yaml
@@ -572,15 +572,15 @@ debian-12-x86_32-gcc-debug:
   variables:
     CONTAINER: debian:12-x86_32
 
-fedora-40-x86_64-gcc:
+fedora-41-x86_64-gcc:
   extends: .gcc-x86-64-build
   variables:
-    CONTAINER: fedora:40-x86_64
+    CONTAINER: fedora:41-x86_64
 
-fedora-40-x86_64-gcc-debug:
+fedora-41-x86_64-gcc-debug:
   extends: .gcc-x86-64-build-debug
   variables:
-    CONTAINER: fedora:40-x86_64
+    CONTAINER: fedora:41-x86_64
 
 ubuntu-16.04-x86_64-clang:
   extends: .clang-x86-64-build
diff --git a/automation/scripts/containerize b/automation/scripts/containerize
index d72c22c103ff..bc43136078e3 100755
--- a/automation/scripts/containerize
+++ b/automation/scripts/containerize
@@ -28,7 +28,7 @@ case "_${CONTAINER}" in
     _alpine-arm64v8) CONTAINER="${BASE}/alpine:3.18-arm64v8" ;;
     _archlinux|_arch) CONTAINER="${BASE}/archlinux:current" ;;
     _centos7) CONTAINER="${BASE}/centos:7" ;;
-    _fedora) CONTAINER="${BASE}/fedora:40-x86_64";;
+    _fedora) CONTAINER="${BASE}/fedora:41-x86_64";;
     _bullseye-ppc64le) CONTAINER="${BASE}/debian:11-ppc64le" ;;
     _bookworm-ppc64le) CONTAINER="${BASE}/debian:12-ppc64le" ;;
     _bullseye-riscv64) CONTAINER="${BASE}/debian:11-riscv64" ;;
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 12:54:40 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 12:54:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867248.1278697 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVVZz-0005n5-BC; Wed, 08 Jan 2025 12:54:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867248.1278697; Wed, 08 Jan 2025 12:54:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVVZz-0005my-8b; Wed, 08 Jan 2025 12:54:35 +0000
Received: by outflank-mailman (input) for mailman id 867248;
 Wed, 08 Jan 2025 12:54:34 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=1vVY=UA=amd.com=ayan.kumar.halder@srs-se1.protection.inumbo.net>)
 id 1tVVZy-0005ms-77
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 12:54:34 +0000
Received: from NAM02-BN1-obe.outbound.protection.outlook.com
 (mail-bn1nam02on2060f.outbound.protection.outlook.com
 [2a01:111:f403:2407::60f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b33e27df-cdbf-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 13:54:31 +0100 (CET)
Received: from PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7)
 by CH3PR12MB7738.namprd12.prod.outlook.com (2603:10b6:610:14e::9)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8314.18; Wed, 8 Jan
 2025 12:54:23 +0000
Received: from PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264]) by PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264%6]) with mapi id 15.20.8314.015; Wed, 8 Jan 2025
 12:54:22 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b33e27df-cdbf-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ghcv89W6XS5WW6wOMxzdpoouA4AWkKrvYaGTXpl5zCGtJVoTpuk5Hq9rS4mPQE2NAP6BHj6S8xyXVcZqyj/Cy3kXVO1u//lE8VFojUbCGTFzB/VTiuVFnlecpk5oSrpGjyOOOwcpyhcgMcSR+yTBJj5R2PwrpkAKAvmC9UscFZp02cIOAjbWnoqvHA3qfB0mxtShFJUPAQ6yc9Ewq5IW9P6++p0wmH5BF54jpyn04Ps2Iax/6fJoWjzyFZJjnjaY0agAw3iUKxeiZYSH4ul+VJAy82RGZsNpvGO2JUVnc5fR33Ymm7V4GSZrOeqoyQrZS2FpZk4zyvFfb6pNvOmZig==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=BaGIXQKjf385dVqMCPpd/f/1g6kbtGXFSsuzfot7uj0=;
 b=x6LwIIV1tTLmRC5xIxqQpXY98xcm5eTY8eeAu55lbPKRVxpczEZJwx76fgKwgm7ApXQ+ScEnVN7lQR9Z926HYuSpgpcy6x80chOqrmVqMzo44kit2rA2S5xGpGheiNbHdnuSFdJ79ivaBod+sbvuii+rpM/YKac83PVwXV3p3dYFwlRTM8JGYN42bBDXmkoJXNUyD/V0quGulzutHa5cdiy4/EgfNbm+PxubM9UOShzs3bzEVljAetrlC23zK8ilFzvL81exWPedP/bxttT5S6VfrJvsU2ux8auZd9JGJfpymPgCGi2xdQQjBqi9Ku6DePJOrxL+TzZHbKD+1VX0+Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=BaGIXQKjf385dVqMCPpd/f/1g6kbtGXFSsuzfot7uj0=;
 b=xY+G0JtJHgp+sDLt4BkAD1gdYEHnBB5lzDyDEDZUD9N7J2lIKrUzlIWOlJ5jpn0mg9Xk8ESJU3ObJYNw+wGKpgxEEhE4jDa6dbUyKjc+/lNJUtxQzlDt0vwKAWLb9ZJ4+BWQnL80opWrlYvRDMi30LN6NrOxPlM55RrTFVEN0zk=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <f377f3dd-c367-4ab9-bdd6-705aa5970cbb@amd.com>
Date: Wed, 8 Jan 2025 12:54:18 +0000
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] docs: fusa: Add dom0less domain configuration
 requirements
To: Bertrand Marquis <Bertrand.Marquis@arm.com>,
 Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Michal Orzel <michal.orzel@amd.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Artem Mygaiev <artem_mygaiev@epam.com>, Jason Andryuk <jason.andryuk@amd.com>
References: <20241219105640.3294591-1-ayan.kumar.halder@amd.com>
 <7402DB1D-61F6-467C-89BD-6985A6817362@arm.com>
Content-Language: en-GB
From: Ayan Kumar Halder <ayankuma@amd.com>
In-Reply-To: <7402DB1D-61F6-467C-89BD-6985A6817362@arm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: DB9PR01CA0007.eurprd01.prod.exchangelabs.com
 (2603:10a6:10:1d8::12) To PH8PR12MB7326.namprd12.prod.outlook.com
 (2603:10b6:510:216::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH8PR12MB7326:EE_|CH3PR12MB7738:EE_
X-MS-Office365-Filtering-Correlation-Id: 57813f41-1f9d-4d56-4ce3-08dd2fe392d8
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?N3ZlTE9LaDJiVEwzdC9GRG9ray92aEMxSnNiWTg3aWtRTkl0MFVPdXpUa2xm?=
 =?utf-8?B?T0NmUkY0MXNjOThWaXlRYXA5SkQ5a1N2WFhMclVXcldFeGlFVVpXY0dzUy9t?=
 =?utf-8?B?Y0dKWXVUeDV0WlVJN1RxRU1ia2tPUHpSZldlZnlZMWR5YWJxYUxZZHlYdnZ2?=
 =?utf-8?B?aUdLakFBcUdaMVo4eVN4cXlqV3ZCeFRjaUtJTzNXMU93S2R0ekdTbjBZUU5K?=
 =?utf-8?B?YWI5WmFhKzdqd0ZMVEVObjhLN1k2ak1YUGpaaVczcUEydUN2ZnlCUkFIMGFD?=
 =?utf-8?B?ZUk3T3VXKzJGZlcrdi9BY0N6TEZRYnFVVzR2U2hTRm14VE1zZm8xUGFTaUM0?=
 =?utf-8?B?MnFmNTZTWGJwOFZZWVR4VUV4TGczQ09sQTd3TTN5WEtmeitmVVcvWURQOGpq?=
 =?utf-8?B?MFd6azMzdTRlbHhsejJLYmpvSitBcVRlZm8wT21sSEVOak1KaW9LTjcxTmpZ?=
 =?utf-8?B?bmpvVGRtSUJEbkZWekIyUnE0WjkxNmVWdXk5Wm9vL0pJL1ZvWEFscnB6VGtO?=
 =?utf-8?B?emtkNHNCOHlTaVFtQVc5VFhQbHZjNmx5OEI4cXFQYXZmRHY2a0lWbXhsRThD?=
 =?utf-8?B?VVd6ZHVMb2VPd3BydzRjRlVoNkFCMkhsMTJsdUp1SVlkaElNMFNqZWRTV0tJ?=
 =?utf-8?B?TXozNkczU3pDdlltYXdPd00yRXE4MUNMNWJTb1FGL1Bicko2Qi8yU29memV1?=
 =?utf-8?B?d0sxVU1oTEV6aGtoVDc1b2VKYTNOVy9OSDBTZ3o1a093dGh1ZElYSlBTZCs2?=
 =?utf-8?B?a2tXNGFBZzRhTHFxQUFJT3dZaDNJeVozTnhZcjhoR1I3MUxJMXBrcUFyOE5J?=
 =?utf-8?B?YjZDQk5GQnBHd29KQ2xLMkFTVFBiMWtVMVROdEQ3UjlrdXVHeU1hN2FhQXRF?=
 =?utf-8?B?c1BSRml1YTVwZHpxeTY0K1FpNlBaTlNZTkJmRW56TnVSdmdRRUxJNHVqMWRG?=
 =?utf-8?B?SUZQd2RVT2NZSWg3SlkwWitSNGZyMHJ3eGhkekR4dEloS1ZMUHd2U2dnSGxE?=
 =?utf-8?B?QlR1d05YVXIrS2VpTHhadlY3akRFWHc2ZTFZY1BJZG9EKzZTMkVUWmFNTXdn?=
 =?utf-8?B?OFc2UnFPQlZnOE5XeWtMUS8xWng0ZWc4SUwzWkkvc0xva3lDaE56SHJ5MnBN?=
 =?utf-8?B?MzQ2VDdFVDFyalR1bmNVeE0wTkxQM0ZqaGlVbENNVytEZzJLakF2VEpZMFlZ?=
 =?utf-8?B?U0c1c0NIOHB2UnNteG1xT1BBSVNkODkyVE9DQzdxRXpsYTh4WWZmL2dRSWZE?=
 =?utf-8?B?eEhoT2xmWW5vRm90N1hjTlByTFhKNTk0M0NEeThXZGJoaXFnWTFqV3ZNV0Vi?=
 =?utf-8?B?RG16VmFTYmdyNzEyR05jVEJRZkJPQmhDalpyZG9kRWwvTTFFdkFBbEVOWU5M?=
 =?utf-8?B?RzNTeG45TVFGODAxTUlydHN2QktQZHZ6anduWjVMSnplSFZUeGhjcVdUVmRv?=
 =?utf-8?B?TFRWNERUcWJVTGx3RHVXWklTRjl3emErUy9uQmNYR0sreEF6dkM3cDNLaDE4?=
 =?utf-8?B?Z24xQ3hnZzhiSjlnRkdZc0QveFZZUUt1NjRQV0tvNEE5WFozQVhibG1MVUt2?=
 =?utf-8?B?b0cvempaZ0RJYWhpVkd2a1BQb1RZdnpKQjhJUHBaS2dTSWE3WldoWXdqTjZH?=
 =?utf-8?B?aVBMU1NLTTFqN1d6MEdGQTN3UWM0U25DZWcwaEdOQXlyU29sZ1pmOEdFaHRx?=
 =?utf-8?B?WjlaazZlQnJVY1NJSnlheHIzcWtXdXdvK3duZmZhOUVFRFNBS01qcVVSUWkz?=
 =?utf-8?B?MkVKTXZRb0VsYXl2RFFKenlZblF0OHNLK2swVjdHS2ZBaHJWU09pZnNMVjlG?=
 =?utf-8?B?VEh3K0VyM2VHc0w4ZktXUVBVRk44TFFkdVB4b2hMUUxzcWw5RnB4aWZJOVVT?=
 =?utf-8?Q?HEvhGIe1O69LN?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH8PR12MB7326.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?bGMvRXhzL2RZMTlQZWNRVUpwS2V0WFVqd1Y3S2ZTSlFFZ3NYbTdhV1lnTkJz?=
 =?utf-8?B?SnlIM3hxRndCaDJZdlp1T1NtRjlWdHFLSGFiYVFZV1FNZXFpaGRWVFRIcW45?=
 =?utf-8?B?cnd3blpyWk4zajEwZGVKZVlEdGI1b0tsb1ppbnpMcHczbVQ0MVFRNk8zTjFL?=
 =?utf-8?B?MHQxSXZsZzdiSFBLc0VVUDlsSVQ0R01nNDdTV2kwZWVWWUVDK1IzVllkbkZO?=
 =?utf-8?B?QVhCVVUrTGhsMXAwV01lM2xRQ1pENkE0TEk5OXJqeHJ1NmdMR2NBZVlLM0d6?=
 =?utf-8?B?UUNBeXAyUTRhb3h3MVVJOTg5L01Ia0NHOWovV3k2ZC9hYzZDaXZVZ0pRdzRG?=
 =?utf-8?B?RlVORmtaTGdsUTRUdXg4OVNKZTE5SjVKYXhJbHhYZU9Ja2ZieUJQU29xalJU?=
 =?utf-8?B?TnhMYTZlcVRGNDlweWc4QlVsYlpwbitDazVWcUZPY1RNa1RtWFk1clNEbW5U?=
 =?utf-8?B?VW1aSzAxTUJ1NXp5ZDgzV0RQdHlXRnZPTDI0R3A2MzRBTG1sYkh5Zm54YXJi?=
 =?utf-8?B?OFh1bGFVVWxIVGxUZGZPeGlDS1pwNXVEK3BvS2FRV0I5Y3VFL3J3aXV3Z1l3?=
 =?utf-8?B?NTlUTjFaSVNabDdPeWdOUU5NbzR3blFEQjZOUHMva1poTEFtaGR1MlN5eFB4?=
 =?utf-8?B?alVWNW1vM0RKWWx6cnVOS3FhQklKUndOS0NuQ2ozd1ZkcUQxaitzbWtvYXBK?=
 =?utf-8?B?b0xvS2tzT1VBQVlGQVF5VmdFQlNhNHNTL3VuUDlNVmRmUFA1b1FzL3RMTCtl?=
 =?utf-8?B?dCtreTZ1MEptRERWSWZhTStVb0VkckVDTExFYnpyYi93dnAyUldleUFSelJH?=
 =?utf-8?B?L3JhNFBHV1R2d2RzdGRKOTcyclZycldGWGNmU3J6emRPTkwyWkR0Q2dPU0pa?=
 =?utf-8?B?VGtFM3l3b0l2UWZ1V3ZnUVpqdm9TYjJuakJzVUpmTzhicmFkQVY2L3FTMU5w?=
 =?utf-8?B?b2lsQUhGOHIwR2tQUExQVXpTOUpOK2JpQjRPc3hOeURHVEdrUytsYTMyL3lk?=
 =?utf-8?B?bmN5QnJvSFFjSm1aei9tVFJvT2FuZ0hjTExDcUF0Qm12QjNzODZreUZiMUhn?=
 =?utf-8?B?elNTVXhGSStoS1VPcjdmcUVCNDJkQVRPNTl5WUVWQ0cxRDcwWENVZG5yR3hE?=
 =?utf-8?B?U3lMVDJrYW9PY1hac0xOeTlsSHR5cENqL2hLNzRFSzRoWWY4YVMxY2N5Ykli?=
 =?utf-8?B?TjZmclhXRzNiQWRvUk4vM0FrUExQUW5TS0RZM2ZpWjNmK0RGbE9Qd2RPdTBY?=
 =?utf-8?B?R2xOVHl1U3FPOVUxOVVvRkhZQkdlUlhDNksxR3NtT1UvQXJuNVg0ZjZZN0RV?=
 =?utf-8?B?MkoyWGdPU25LUytYTnhpM1AyWU9RNm1pZmtsaWZjU2dmT0x5bi9zYWRZNnpU?=
 =?utf-8?B?K0lXemhpeU5JWEtSd0s0SUNpTkpUVTBOMERyY1JXZ3dOTUVGWEtlMWpvdGhT?=
 =?utf-8?B?TGV0TWovbnhDYXNhN2NPWnU5NVQ0TkJzRFV1cml3S2JrMExpakxPZmx6NFlD?=
 =?utf-8?B?cUVpeGhTVlF4QUxNZVlsdjdEOWF2RjJERDVZamtsejZ5aFVmVzU5Yjd2UWxY?=
 =?utf-8?B?Qk92NWtRelZJWnk1UXpxMWFtbjZkTE0wVmRRazRUeFZlbGRPVlJOcm5lZDhk?=
 =?utf-8?B?dTRRODV4bVRJdDduSFRyWjRkT0dvc1JxVUUvUjkraS9zRG1QK0xMbnBuSjhT?=
 =?utf-8?B?UXM4TFg4RHBXb0FCN2JZdGUvT2tVcHBKQm5ydTU0amNYWFE2UGpsNy91b214?=
 =?utf-8?B?YWNYeXZBZlBZZ3dsbitnQm51VldwWFVPK2pTaENpMk1DMXJVbWk2MForNFNF?=
 =?utf-8?B?NTZLM0NoUGpHdlNhT01YR1U2eHVyR2cwYmI0WWo3eDlSMGVMOTUvRDl5RDlo?=
 =?utf-8?B?QkEvemJJNGk3SFdXL3VTWXJ0bk9BRUQxNitGUXNTRS9pUUNyMzZQN2hTSUZk?=
 =?utf-8?B?cmJ3VFZBZ3lWUVZaZmlRK0xyNlRiWHAzTjNPeGcza0JEVUJhNktrbXVXelVH?=
 =?utf-8?B?Y1FIZ3VrckNTYW1JRkNZczVQeUhLakRyUW1MeFU0SllvNlVNd3BjNkRQTnYv?=
 =?utf-8?B?b1A5UnNBMlFuZjJ6R1lNdlNRKzM5Y1lvQTdUWE13bDFnOTFHcWx6akxjd05R?=
 =?utf-8?Q?w5vNhnA0phOGCxGDlBFoLffA0?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 57813f41-1f9d-4d56-4ce3-08dd2fe392d8
X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7326.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jan 2025 12:54:22.8080
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: rPMpDwiQjlKe259osubtgokgN2LbZ9WoeUT14jkqk35/LSq1TZmoh5malrxYdqZO4YpAN4VVHoXfx01I+QCeCQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB7738


On 08/01/2025 07:51, Bertrand Marquis wrote:
> Hi Ayan,

Hi Bertrand,

I just need clarifications on the two points and then I can send v4.

< snip>

>> +Domain Creation And Runtime
>> +===========================
>> +
>> +Kernel command line arguments
>> +-----------------------------
>> +
>> +`XenProd~kernel_cmd_line_args~1`
>> +
>> +Description:
>> +Xen shall pass kernel command line arguments to a domain via a device tree.
> Would it make sense to say where the "command line" to pass is specified ?

Yes, although I don't feel very strongly about it. Let me know if this 
sounds ok :-

Xen shall pass kernel command line arguments to a domain via a device tree
using the property "/chosen/xen,xen-bootargs".

< snip>

>> +
>> +vCPUs
>> +-----
>> +
>> +`XenProd~vcpus~1`
>> +
>> +Description:
>> +A domain shall have a configurable number of virtual CPUs (1 to XX).
> XX should be replaced with "the maximum number specified at compilation
>   in the configuration through CONFIG_MAX_CPUS" or something like that.

Actually we are talking about virtual CPUS whereas CONFIG_MAX_CPUS refer 
to physical cpus.

So, it should be GUEST_MAX_VCPUS (which is hardcoded to 128 in 
xen/include/public/arch-arm.h).

Thus, s/XX/128

I agree with your other comments.

- Ayan




From xen-devel-bounces@lists.xenproject.org Wed Jan 08 12:58:26 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 12:58:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867257.1278708 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVVdh-0006Oc-SQ; Wed, 08 Jan 2025 12:58:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867257.1278708; Wed, 08 Jan 2025 12:58:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVVdh-0006OV-Po; Wed, 08 Jan 2025 12:58:25 +0000
Received: by outflank-mailman (input) for mailman id 867257;
 Wed, 08 Jan 2025 12:58: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
 <SRS0=HByp=UA=arm.com=Bertrand.Marquis@srs-se1.protection.inumbo.net>)
 id 1tVVdf-0006OL-Gs
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 12:58:23 +0000
Received: from EUR05-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur05on20614.outbound.protection.outlook.com
 [2a01:111:f403:2613::614])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3d239e59-cdc0-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 13:58:21 +0100 (CET)
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by PAWPR08MB9613.eurprd08.prod.outlook.com (2603:10a6:102:2e4::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8335.10; Wed, 8 Jan
 2025 12:58:18 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a%4]) with mapi id 15.20.8335.011; Wed, 8 Jan 2025
 12:58:16 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 3d239e59-cdc0-11ef-a0df-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=xhmUsOGrDisEeXyeSb375yDvnra2Ra9vezkXEk4kz85IPxUsU2sJ73yNxofflbWTIVf5QAqxRbFWz/uB30LgYwjn/WIBk3mp7Cfyxi1UazZKAK/5z+2XWkTWPG6vN7aUTiJhfAl7Q+gBEjvrzqxS3IIWFkHhEi4tWDgJpJA0R8E/UxmPtst5OK8lD1SRS0XhgHrDq3lfTxZ9K96eY39s05NpseRVCH1h//IkPsRIqulnB2ZIvAWhuAmHcV/8Fe/2+DdXL5JphPiOccMoYN6V2XA2AzZQ/YPxGkDVN3pp0cTDragzu8Ymtdrwv5JIguNo7yahbHESvLavdHbxj2e/nQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=+Qj3dY96vrj9T/c4ZHoupqeofSh5WUv/P7+cweYoVtk=;
 b=JDL0QDC3iLkpgQBBwjKDWQL5tk5rdV5/tK8HpFPhsWujBULf9pCIVNX2uKOYBL0VJtpXHpD5DROY+VgZq7bkRbJ/LiPVzlw1a8L+ZdurCCu6D2N7sW4rAe43qwDh/VywblyqSC0k/KHXGrPouY7LWfQ5bEpiKeRu35cVIOVKJ5Pu0TCUgpo/ZMIMRgbjcwQm9XU8LVfJMZGbi5gAqz3LVAf/1E/7Ajcj/H0KNO5r/7g3xFzWDnc8AqR/gG/kj1xas1hLn1/k3mD5ce1mh7icX1myGnEh3COYTM7a+3hXQICoO/qIVHzQmYxKb62NM8mKVcRezkrCVLOUnAXJJKX24Q==
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=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=+Qj3dY96vrj9T/c4ZHoupqeofSh5WUv/P7+cweYoVtk=;
 b=HlnpZJ/XKRPeQI4kzJ88P7oHHx/EAkClzmed8C+6jF/U6HmV+A1+2rJKi9FJ7Lx1GIp6CL7E8zVoy57yIksTPHrExNfKlT+k92yElQ4958KDbNd7X9sXevhp06xveX+yQ3WCa7eoWDlDuYIrv5ePJs07amee/xnazFeRT6COjNg=
From: Bertrand Marquis <Bertrand.Marquis@arm.com>
To: Ayan Kumar Halder <ayankuma@amd.com>
CC: Ayan Kumar Halder <ayan.kumar.halder@amd.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Michal
 Orzel <michal.orzel@amd.com>, Stefano Stabellini <sstabellini@kernel.org>,
	Artem Mygaiev <artem_mygaiev@epam.com>, Jason Andryuk <jason.andryuk@amd.com>
Subject: Re: [PATCH v3] docs: fusa: Add dom0less domain configuration
 requirements
Thread-Topic: [PATCH v3] docs: fusa: Add dom0less domain configuration
 requirements
Thread-Index: AQHbUgS4JJcMvJVd5kOG9/I5q9pAibMMoCqAgABUqACAAAEOgA==
Date: Wed, 8 Jan 2025 12:58:16 +0000
Message-ID: <FE2F5B8D-B4D6-4DD1-932F-2409C1D835BB@arm.com>
References: <20241219105640.3294591-1-ayan.kumar.halder@amd.com>
 <7402DB1D-61F6-467C-89BD-6985A6817362@arm.com>
 <f377f3dd-c367-4ab9-bdd6-705aa5970cbb@amd.com>
In-Reply-To: <f377f3dd-c367-4ab9-bdd6-705aa5970cbb@amd.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.200.121)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DB9PR08MB6588:EE_|PAWPR08MB9613:EE_
x-ms-office365-filtering-correlation-id: fccc32a2-ad8d-4995-a497-08dd2fe41e52
x-checkrecipientrouted: true
nodisclaimer: true
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?us-ascii?Q?NmMrZNL/+iJ7BoZiNInRZU679Qwcv1pvUXzhhl/n6pVMpveeh3TrmfozsGJE?=
 =?us-ascii?Q?PaVFanqHMBa0sMj90Wd6HqK1zJnQmdU2Ts81gBiZGVjGsK0vG5kT2DFgGG8t?=
 =?us-ascii?Q?dD+hWENNQU0aLn7CQ0KCdiOIHa4Do2QbmKiOrKogoA7uxrWXyvS09JZSBrQz?=
 =?us-ascii?Q?qK1bpTTGS82uW5Mq2MAloM+KIzT8yuP3d3cLx4X9eyzeCslyE0DBrUpvfYTS?=
 =?us-ascii?Q?k39VcY3A14ZkASlDxCIgDfca3u0olelrwVH98TzEw/uy8nOjDS7G66lZyj2m?=
 =?us-ascii?Q?fFUDBFIDaLSRHQfgVHHJ4LX6F658olyQsvseomfRdPGul0ves+w2aT+fxFT0?=
 =?us-ascii?Q?iKunn2zCrQRv0X9DEH+m9t5oLXJU+VMADTnO/Qhos/oNH9L5HiKnnE31aKzY?=
 =?us-ascii?Q?dx3eI8Jl54s3NELzIM+yxsBVEtb6sEWWsrAYvsWpZEiz720/XkOohebKmqhn?=
 =?us-ascii?Q?grvGjUW8tNKrKbg8dyLMCqS1Q/3CYyNKDhcFWLY6e3LcE5+uJv/QfN1gVP+4?=
 =?us-ascii?Q?i6VsEcq9fEzuGd4/3K5zzKWaRxsl9NSDwy31VzHEVOdqli0iV3+/AxpxBlwu?=
 =?us-ascii?Q?wH9DQEMruONJREgyDGrwiGsdcDOKSBuq+m8CjsPaYkmWlDI8W89m4TFmpK16?=
 =?us-ascii?Q?TRmG+HxWnpg8VHjlfKhDWhfHPfxQljuP2yZCoGIsr6EAIuC4thW4tCvtdbDe?=
 =?us-ascii?Q?bCDu5E3ytcqR1dIs3sMUukhIt/iWKmlICTyywrQRcRX7sXTPkIIRFzPcSMaG?=
 =?us-ascii?Q?4zNEwvYvyvqITxGGWfN5NzgmzoE230kJl12ZU0aMF2FZUc2ipHl1pHWlxZcn?=
 =?us-ascii?Q?VCa3q38VONCuABAXLsO7RfOP46N93rb26QR/FSrw4IvNNMcWJw7uwo1qG6r2?=
 =?us-ascii?Q?yAf3d5e+Ip/Uyd17+NpKSmsazSfsUHVNs1IoI65r3JY5pRTC4PwkoFgwLEJS?=
 =?us-ascii?Q?/qH3CVPuaiAixB/Q2/nH81sahCkKWbAg9X6H2itUfsZDgEQySEkJVA96ECFx?=
 =?us-ascii?Q?UpLxCsXHtbfXaOnCuLAQfoNkT0f4Scs+iwF2UPbMY52h5LaPtBjDSJ/IRPIM?=
 =?us-ascii?Q?4U+MZmtcr+yTd6dxk7bnD+7qUkzngm328gi/+o+yTlanWrci40TnCF60BmbD?=
 =?us-ascii?Q?lb7thSgsYETWpez9dxbIFRcwXmlS/8R1FVnqjHC7Mgpo7KNPGSAxIteLxcCh?=
 =?us-ascii?Q?TupROq5DOWGidZVy/2ZGXf74CNSHDaXzI9Jm0mwZLnk57q+p36jQYSb7vUil?=
 =?us-ascii?Q?bStcSZO5SV1JEaMFJNMfm/bj1FqNcy9F+hk7deVQfkhkjfxZ/FaJliopNsHg?=
 =?us-ascii?Q?3MZx8v98JL6HK6N7HTxxQWsFuRPVY1nFHzNi0iQUfZVAC6aWpBGDJHHtJPPe?=
 =?us-ascii?Q?rL3cJTCKFJ7l0KcBhGTP94qpr4mmhutKdejf81zaS8poaU/ux8rVdIfMxsBA?=
 =?us-ascii?Q?kFfsegkTx+YDfASJoJYswJa9BsgMn3j2?=
x-forefront-antispam-report:
 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:(13230040)(366016)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?ms5kRY1WgiSa09XhMNqcvbCa7XHAy9rXGp7CGzbLSxyBPX/xCS9F/sGQZcR7?=
 =?us-ascii?Q?+kTBTXE0fuClBAjMPu39X3u4Df7BsKKJeQ2cMkOC2NUNy6cZGMP4U1H1Z4+w?=
 =?us-ascii?Q?DLEglCHJd4QEadfOiUhhzs1YiJobY9X6R+oO5iLxWvIrbpm98+CpT7sdFkXz?=
 =?us-ascii?Q?cxHMWi50nuEvtcEGE1z+Mlqn7KFnS2/BNv1VoI6X/bvejyVBXxlfAsjHuEIM?=
 =?us-ascii?Q?wDFUjig4vH1Zwc3vaxCV2s2CSBetbb4jzuuKV6dzmFrdt8AFmWLhMd854iWt?=
 =?us-ascii?Q?1iupnACG9lcK+kV4Tjpg7IoU8oxCU+CPlKOKqynbAiwO/P3bWtSYDZ/aRlUH?=
 =?us-ascii?Q?C8dt4XK9/bUJfSQih/J0V/Pla1kq1uM1b5Ap9Z3gyhMnjYv+yTRpbALmfmIU?=
 =?us-ascii?Q?XhY/AZA2ZN27LWJAs51gLtoa3b4GSjhd/wJyseLt2ulA3UlwJe2lueNcDfB1?=
 =?us-ascii?Q?4bSYMU7pUvDjOOSPw1g0D+dND2o4zyfAnTmH25px5jEzETfUH+b/xGCq1G+G?=
 =?us-ascii?Q?uhBCbnfMOX9XCtFm2KW5InW2nmSk/l9afSA6u6DjolPKK5eFl73GnoAHA7Er?=
 =?us-ascii?Q?n4UPlAU75G/i53bRpJQfwMOR8dR9r1I5ZxZrlYTM/GXjVVkV1iZLa5FvT33s?=
 =?us-ascii?Q?zlj4HB+kxDRe71RPJnEHJs0HuUWDqZ/0Z/6+RUzJ7wNvP1+UC6T1prNqEUzI?=
 =?us-ascii?Q?LxduBwji4vSmHEm9OMgOv5SEwPWQ4IognYGiTDDpEMIOhKBGkAuCnkjRjJ+B?=
 =?us-ascii?Q?WcIsCn98YJbi6c/4yx/dUBMc4wCs4cG+c8c61U7Y+WT4hyLHIp+flGFFPiZI?=
 =?us-ascii?Q?KBRVjKqBfdyUsqNWbDXP6fgAP3vdoT22j6PiN7fcrkiT4CW4esFSHPnaqubI?=
 =?us-ascii?Q?Ex/Ygfb1aLfkrHA4xKjBzAfgGytNU2HGjJNb7UO/W+Cv/lwZ1NWMNUfWk7oy?=
 =?us-ascii?Q?IGjDJi51KS4fzhVpoSHHC2w8i9IrS7g2wsy7ugr79TT9k3MhWjMMvpMy6Evy?=
 =?us-ascii?Q?ssjvLS06G+q5cTz5yhiwRLHQl15Lc9VKgkerEefD1QElvcP6kGxAeseTponM?=
 =?us-ascii?Q?cXRljrM238CUUqmdN4jyu0Y5+3fSGmaD8G081O2W/Qcb4lkT6ynogvdZnysV?=
 =?us-ascii?Q?BwggmhMx64NLKS6thAs8Yk8hhmA6SKXrriUQWFmZRGxRlMn8TVS7mv0cLddy?=
 =?us-ascii?Q?rFIjgH+/mToFjN2Dm5rhm2w2mPhpgIIhBxvQ+X6gNvBOu5W9U9Keyj9+tIrf?=
 =?us-ascii?Q?EL2xfNayEcIjzSMlvAS3YG3DSgo8UvUOT8SUgIlPiAMpPQr8tivaS2BmGyS3?=
 =?us-ascii?Q?yxPJoiugg/82pQFdAWyGAUke6kbkY3fZF+r07HsNodb4xSviJhaal6ybFdZ6?=
 =?us-ascii?Q?suzzexQO2mhIlrjmTDoHwMF9df5RwnQBi4cp+caAG6ftM61Ruv6xT05WJo7Q?=
 =?us-ascii?Q?uxM7rCxSL9eFAQ4HPcEJ7DZmL+mjQNIvtxgwgRd2DkmdLnMNzQpQniDgKwVR?=
 =?us-ascii?Q?LApTtA9NKT6nTs6BVjPYS1ffOGPKu04sGIYcCNWeHbwFRy6mGHn76UCMobnS?=
 =?us-ascii?Q?i0iIJtANV6Sx2UqTOp2wHCXXQ/a3Yc4sTcseOFV4/V85uz4NFP/SFRu7R77+?=
 =?us-ascii?Q?QA=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <9C4BEDC85128354A8BF2489EDB2EBA72@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DB9PR08MB6588.eurprd08.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fccc32a2-ad8d-4995-a497-08dd2fe41e52
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2025 12:58:16.3935
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: mqmQGDXGfxvREa3zGdfYnbaT3VHdL7u1HK54u922MeostsOfDesYK/0YCeWIEhcs3lDMsZA/y+bMbmePgHlIFdm87+E2FZ306gf4/GDS8GE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR08MB9613

Hi Ayan,

> On 8 Jan 2025, at 13:54, Ayan Kumar Halder <ayankuma@amd.com> wrote:
>=20
>=20
> On 08/01/2025 07:51, Bertrand Marquis wrote:
>> Hi Ayan,
>=20
> Hi Bertrand,
>=20
> I just need clarifications on the two points and then I can send v4.
>=20
> < snip>
>=20
>>> +Domain Creation And Runtime
>>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
>>> +
>>> +Kernel command line arguments
>>> +-----------------------------
>>> +
>>> +`XenProd~kernel_cmd_line_args~1`
>>> +
>>> +Description:
>>> +Xen shall pass kernel command line arguments to a domain via a device =
tree.
>> Would it make sense to say where the "command line" to pass is specified=
 ?
>=20
> Yes, although I don't feel very strongly about it. Let me know if this so=
unds ok :-
>=20
> Xen shall pass kernel command line arguments to a domain via a device tre=
e
> using the property "/chosen/xen,xen-bootargs".

In fact those can come from several places (xen command line in the case of
dom0, device tree or guest config) so maybe not the simplest to specify it.

Please ignore this comment.

>=20
> < snip>
>=20
>>> +
>>> +vCPUs
>>> +-----
>>> +
>>> +`XenProd~vcpus~1`
>>> +
>>> +Description:
>>> +A domain shall have a configurable number of virtual CPUs (1 to XX).
>> XX should be replaced with "the maximum number specified at compilation
>>  in the configuration through CONFIG_MAX_CPUS" or something like that.
>=20
> Actually we are talking about virtual CPUS whereas CONFIG_MAX_CPUS refer =
to physical cpus.
>=20
> So, it should be GUEST_MAX_VCPUS (which is hardcoded to 128 in xen/includ=
e/public/arch-arm.h).
>=20
> Thus, s/XX/128

Right so you should say 128 here.

Cheers
Bertrand

>=20
> I agree with your other comments.
>=20
> - Ayan
>=20
>=20



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 13:09:31 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 13:09:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867265.1278718 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVVoL-0008Lx-Rs; Wed, 08 Jan 2025 13:09:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867265.1278718; Wed, 08 Jan 2025 13:09:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVVoL-0008Lq-Ok; Wed, 08 Jan 2025 13:09:25 +0000
Received: by outflank-mailman (input) for mailman id 867265;
 Wed, 08 Jan 2025 13:09:24 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=sbNq=UA=epam.com=Mykyta_Poturai@srs-se1.protection.inumbo.net>)
 id 1tVVoK-0008Lh-Rc
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 13:09:24 +0000
Received: from EUR05-DB8-obe.outbound.protection.outlook.com
 (mail-db8eur05on2062e.outbound.protection.outlook.com
 [2a01:111:f403:2614::62e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c7a782de-cdc1-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 14:09:23 +0100 (CET)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by PA4PR03MB6895.eurprd03.prod.outlook.com
 (2603:10a6:102:e7::9) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8335.11; Wed, 8 Jan
 2025 13:09:21 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971%5]) with mapi id 15.20.8314.015; Wed, 8 Jan 2025
 13:09:21 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c7a782de-cdc1-11ef-a0df-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=FKgdFlPBWHKBgce2TLf7XdWlFzGhcemWWXUzQw6JvGiCj0HBNZgTBtOofNA+r5QkazLB+YZ+xrT19ncAQ0sgV7A0x8f9nOd9O+T5IwsSxeROTYaPKAFebJreDhcg3ZtJoe9n6wQvcv8ovBD4SMu8TLTBAdzqYfiz5/fkq1l4PjXGH0i6F897lhEniltoGKdq+bFWXhS1TybZoQBKwi0PkzlGS0DVUdLWRthKYO6Wd7NsmwSEqeY0CCAtwpXcW8fWbOBhhZikTiJfVAC0DqOC64oFx6ZTvWfkbPV7nIuCE6jcApL6rM7fckUG6hewy7BWsaJNQQtbofNNkoKIhmFnqA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=hphcGeNQtQOWUxeiqUkslXz6ydJL35lNkX6oGygJz1E=;
 b=QUR3vI25AWWUPU4no08fLnMXk9jc6/drLEC8GiKwZ4t2F5LUZ2HkIf5Z46lwudkej7tMqHFLGWwEmbuWNzWaj4jQVJxPUNclal/cCC4Oy8Dpi6lHRYaKeENtYnaLpEr8pB6kvesA0x9Y262fsc+OXLleeb+zsWTpHsQjw8qFXV2+0rt4D3q1xRMJfnF091oKDiALnpoHrh3bB5hAPJVu5phDfCRncpeNuGDF0desLNjsKNoXZEQBgWl7M0Ovifpbllp3PKdyJw5eJ1Z2+/M+T6vGYTepRQWpcJlcJ7bQn0BPiQoYCPv/qClIVQNrkwY8FTO2AIenhlnKxY40wOAS7g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=hphcGeNQtQOWUxeiqUkslXz6ydJL35lNkX6oGygJz1E=;
 b=KuKoIQmA6+QeGA4dPLkOZqj/0hIjgHpuUOQl3EUPXYMhcXLkIxN/Tbipmj0E5GgyQv4dUp4iRL0RZG3kij7DYOS4tPz3yJkwWW5fDv7+J9B2yq3szOn+ao5eTs2GRoDCXQaWhMVLnt9FVXssA+DU0JxfVh93kUZxtVeo9Q0bQcS3uWtpQZFGT0RddpjIKJZUBu0vcLFL/q7UDWHHZnc1XrSJaTEkjDHFBWAZsXP5j6emkcikRwHYACsGCPUtes61BaL0ZiPn39UKeAYGD4xGgaHELscFO9QV2WmuoiPuUlN5IjiZX0k5SMD99ipIKlxEfkqPZJ+mEw/etIpU/AG9JA==
From: Mykyta Poturai <Mykyta_Poturai@epam.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
CC: Mykyta Poturai <Mykyta_Poturai@epam.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand Marquis
	<bertrand.marquis@arm.com>, Michal Orzel <michal.orzel@amd.com>, Volodymyr
 Babchuk <Volodymyr_Babchuk@epam.com>
Subject: [PATCH v2 0/2] Add support for Renesas R-Car Gen4
Thread-Topic: [PATCH v2 0/2] Add support for Renesas R-Car Gen4
Thread-Index: AQHbYc6IhXIawRtJ8UKmLGhtEwL49w==
Date: Wed, 8 Jan 2025 13:09:21 +0000
Message-ID: <cover.1736331828.git.mykyta_poturai@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB10102:EE_|PA4PR03MB6895:EE_
x-ms-office365-filtering-correlation-id: f9fd4a7b-920f-4b5a-401d-08dd2fe5aad2
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?ztZMi01JQcb47k/l86ZgTp+aAXiSJld4NYbablPojzivlDCKG6xrFC2zEC?=
 =?iso-8859-1?Q?NbEilrMqCVOMjoJK+IFezbA2TFPp4z0AfFTvj1FceETpAC3EzEV1qI0Ipf?=
 =?iso-8859-1?Q?h6jvl1vSL+jfEUykkCsgxXAqxEdpHSRDt2OW3MNo2VG1MwkRWdo61IZ0o5?=
 =?iso-8859-1?Q?yVN0J7a5BPhQvrusuLPiJ/nGZg/Uwffv0K7dpPsKQJsOx2tLJZcf04JDiv?=
 =?iso-8859-1?Q?SniW4axEWNZXX8kc9HC2YeDET1IcnI24OqV7y+LyRYBZNwTWxAFar3qwHt?=
 =?iso-8859-1?Q?YWMe7IprUPa5VjVEisy/VdwTMlnYfQDW8QjRJFHfIX1+t9jYCt6qmT0/TC?=
 =?iso-8859-1?Q?54NUQkYmHEZx6P35jlbrPwWhOmou0833wJOVXrm6qCBsZgIL2jlMJZK7x+?=
 =?iso-8859-1?Q?rx2ivmiY35xZw30yu9B3AXR66vuQ49XtWa7oiZuqfIxJE5b2KjtVt+RLIn?=
 =?iso-8859-1?Q?fMAX8xYtQwtIi8y8WhfX3/QnWsbx63y4eTNo/7JuIh+uxM/+sVBuhesAFv?=
 =?iso-8859-1?Q?zHNBFlTPtVrVwE0QHkPY00X/byinH/VyS3jNEmifprLmJRMC7mn/pB5YxV?=
 =?iso-8859-1?Q?Ps8JtVkrZRW3udUvN4lfCE6CHTLlyser2efvlXpylET/7NwfsEBfJNWBo5?=
 =?iso-8859-1?Q?IBRsZkHAQxQuXMGfQ9K+aIVuGXxSSPGjBaZ23bdExgxfBCIxe6VLVRPCjT?=
 =?iso-8859-1?Q?/6K6n2ALvuVP5P8qcsRN5WMZpZ/y1UdMkAVkLQOUX/mjDHjmHBFhilwSYU?=
 =?iso-8859-1?Q?s6W1lamiB28BLRLcGU9VBHe3FP+BcgpwQ+Jom/g2ss17jE+4sSNyS0GfAu?=
 =?iso-8859-1?Q?YpoEhMjOa/uC2ECQdclzQjWqFn1dRdXsrjMhuOeslGczDMqS3ij1FO7a3y?=
 =?iso-8859-1?Q?EYmK42fWSKbFw6w4xQqAwj4XRJjzGdM0KwIxJM3AwbxfZoaRdFDFYPzBxb?=
 =?iso-8859-1?Q?uB+SI/xYdOYaqwm7ymtkULypERSO1iVsBjRkZ+ayoycbGueZGVetEdgtE3?=
 =?iso-8859-1?Q?8LHOLsuQOPYEHJjT5TW/qTIxuymHWbYDJJQEyYAugvl5tegFcwCib52Rbe?=
 =?iso-8859-1?Q?sFrsLcYbztrLh9rpg1gr/HBOS12/rmDFeBEIFHSKrReW/p8QhmUvE6TjnN?=
 =?iso-8859-1?Q?cadL6oE2Fv+h+pW62ttH4xs016hfJyoVHFxzSa9hb+UiNLH4SpX914/v2w?=
 =?iso-8859-1?Q?wcWzLHAl3SRHvuQxXQSkbZzMN26hv+6DKtcl6DHltktQqBYoin3ZY+kSRz?=
 =?iso-8859-1?Q?O19pOWjbQJDGDckHDX0DuJGx1qMnXYmKYHDfc25M7U5dF92g5hkVzqBz2/?=
 =?iso-8859-1?Q?h5iY2ZR9dyKPFcrli62t8jWEeTRhV6jmOtLMeNn9oAZX2hGkf/Pd3ROlgo?=
 =?iso-8859-1?Q?+Rfw/v+jk3n98f7ItMJts6Cwm5gw92DeUvchKvKJbqSQX4bHsfuuEeRPma?=
 =?iso-8859-1?Q?Ku0/nnivoKeFvXTEuhdDvTym2jxlAEI384D29nosqmbLD/r+ePjh6USiIl?=
 =?iso-8859-1?Q?cXTeShNi6y+rTIQCYmuj5d?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB10102.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?lsP4Ad/lAIDi0kyfwNUep7W6i3RaVnT2pUQm2lP2ZJOQGaMePNGcKmAERv?=
 =?iso-8859-1?Q?00q2VTub97Im5k1J4wV3pd1PybPzhSv9CrMq+BkgzpU+265VF70aJyNnbg?=
 =?iso-8859-1?Q?2WLujurJFhcQMOU1aXW/81m9myoim6MtxsJSD0C11OTDBSwtURNGR/nLyw?=
 =?iso-8859-1?Q?5Zri5hit1/PuJWDdZlwQnM3DKSHLDmy8PATeqxxuN8uN5eiuIdcTZ5sAkq?=
 =?iso-8859-1?Q?2NFvk2dTyfZjgkjB2DkHV2cdOx3ozTirx/0IKHGi7ufd7OdWrTDjkonZtK?=
 =?iso-8859-1?Q?CM5OiLnGz6Y99zPwk3BEL5OxDwu9h9No6EHcThgeA1NRKVjiT9SURia7TF?=
 =?iso-8859-1?Q?K7CkDeuCabOUf0keyDf3kHx2nQR7iGmZkD73gzZBFQWxHsH8MvBbJYIK/y?=
 =?iso-8859-1?Q?a07XH2m0VdQ4QLDHXeU6N8SOE2icxpFJpWTXZeqWGH5g7LWzGi8K8ITr0t?=
 =?iso-8859-1?Q?CAuPqySajT8uaLUciYtAavFP0s5i5LlHw+4r7UDlD57cOGm60DLi6mTvwp?=
 =?iso-8859-1?Q?qUQzkx21+6JaZ9Meee07KQzsRtdQxkevb5baHa3/jDKJVI9rU443u6EKwm?=
 =?iso-8859-1?Q?I+0/mUT1iM5aQKOlrrRz9bCssYa8ZbUNe1nmZEro2bc53rni6ru6+U3iZb?=
 =?iso-8859-1?Q?EQXEAKFLKCpoCQjG3zAXCwX9xT3GK6EU2xmknMynadAMEYR8Q3+D5FymW4?=
 =?iso-8859-1?Q?IUs2HJCt0urPI5XdvFsQzB28yeGtP+O/sN9xgEEBd9+JaXbRkX/1G7K7KJ?=
 =?iso-8859-1?Q?F1cGHvbzywU4+8T/bqhU0YLOHaAwt/F23CLlV3Hc1N7rwMJgIkVHB8GuvL?=
 =?iso-8859-1?Q?95qJ8hWY+mRQBbPa4ncxb6pfYFcTO/jBRc3noaR9omFMk5JQ2QrjIL0mAl?=
 =?iso-8859-1?Q?gmb5yhsqt89kmlw7hl5VBteXcA/uy29Tngtb/ir5EEsd1/KUlK6d3ZAHn8?=
 =?iso-8859-1?Q?/X3OFAeLcI3G7VHN9JE9qCzOVrT5eNXDj72OYfjp0JDYDUpBoHZ/K9xi3w?=
 =?iso-8859-1?Q?xUu5KKtl7xblVrDZmGXNg5Dh+BHa/XfMoFWbjlJhTLGyAYG6+yTZuBa8gh?=
 =?iso-8859-1?Q?xgFKVNKBx90CpLZbMLwoYzwTHQWQUZs06U18x01VKfdQq9pngNaPCiwjCO?=
 =?iso-8859-1?Q?EbM+Na3FIAHgo/5Jyzz6UhoGvuDljv6coAKeJN5wTH+jwntjGzp82sVYie?=
 =?iso-8859-1?Q?g7ZyDMr7X+QoRTFIn376UKFFYTT1oiLUyQwJqK0ZmzAjZ1pEMk4nkXNkBh?=
 =?iso-8859-1?Q?rH/3ZH7rw5Rh6cCICB6nbp0KK8GJa3sXHKufRPagaP6Wh3duZcWHQadECs?=
 =?iso-8859-1?Q?TR81B3TdFdJw1aavQkwwKvPO1AHTJEJ3iIIV4lf9ZBEBXBe6txPDPyAjmE?=
 =?iso-8859-1?Q?udJXVjf5CD6+7A2tOEkJTD8y9Ym5V8whN1EJAXoppVu/BHbv7H65Y2g6Yu?=
 =?iso-8859-1?Q?fgCUalK6WknwEdbTbmBC9FcsoE6PfVOqvoTBILnhEeJJ1cPUXYnz+3jjlO?=
 =?iso-8859-1?Q?dUYWOJwYqP0ha0sAkVq32pTJzRIM1ciVCsr8qsbleWxgHyykLjZzbor1wb?=
 =?iso-8859-1?Q?FcmP5Evt1a7Dwa1Q4dnCh09amnRRvH89peefGzB5AEjXllZIvKsE8D6Usc?=
 =?iso-8859-1?Q?lTYNah+R+08g9E04uKD8cbVW7ugoINPRKLQW6ajFV8L3+IVklZn1rSfw?=
 =?iso-8859-1?Q?=3D=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PAVPR03MB10102.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f9fd4a7b-920f-4b5a-401d-08dd2fe5aad2
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2025 13:09:21.6092
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: tFdInGf24KyTKCYWF7v6MGCShl2C6tldmrzFrHrove2dgeb+Vw/srh4aoPzgjuqMV/WiZOg6+SJytF9UHHrTkw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR03MB6895

Add support for Renesas Gen4 boards such as S4[1] and V4H[2] by adding the
appropriate confing option, and support for the Gen4 ITS.
Tested on Renesas R-Car V4H board.

[1]: https://www.renesas.com/en/products/automotive-products/automotive-sys=
tem-chips-socs/r-car-s4-automotive-system-chip-soc-car-servercommunication-=
gateway
[2]: https://www.renesas.com/en/products/automotive-products/automotive-sys=
tem-chips-socs/r-car-v4h-best-class-deep-learning-very-low-power-system-chi=
p-automated-driving-level-2level-3

Oleksandr Andrushchenko (2):
  ARM: ITS: implement quirks and add support for Renesas Gen4 ITS
  xen/arm: platform: Add support for R-Car Gen4

 xen/arch/arm/gic-v3-its.c             | 141 +++++++++++++++++++++++---
 xen/arch/arm/gic-v3-lpi.c             |  20 ++--
 xen/arch/arm/include/asm/gic_v3_its.h |   8 ++
 xen/arch/arm/platforms/Kconfig        |  10 +-
 4 files changed, 159 insertions(+), 20 deletions(-)

--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed Jan 08 13:09:31 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 13:09:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867266.1278728 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVVoO-00008o-2r; Wed, 08 Jan 2025 13:09:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867266.1278728; Wed, 08 Jan 2025 13:09:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVVoN-00008h-Vc; Wed, 08 Jan 2025 13:09:27 +0000
Received: by outflank-mailman (input) for mailman id 867266;
 Wed, 08 Jan 2025 13:09:27 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=sbNq=UA=epam.com=Mykyta_Poturai@srs-se1.protection.inumbo.net>)
 id 1tVVoM-0008Lh-TV
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 13:09:27 +0000
Received: from EUR05-AM6-obe.outbound.protection.outlook.com
 (mail-am6eur05on2060d.outbound.protection.outlook.com
 [2a01:111:f403:2612::60d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c92022da-cdc1-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 14:09:26 +0100 (CET)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by PA4PR03MB6895.eurprd03.prod.outlook.com
 (2603:10a6:102:e7::9) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8335.11; Wed, 8 Jan
 2025 13:09:24 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971%5]) with mapi id 15.20.8314.015; Wed, 8 Jan 2025
 13:09:24 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c92022da-cdc1-11ef-a0df-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=d0YYQay5z/DPHnPNEADwXZ6RbmZXxR/RuMgGA7P1ohZRaqzwb5Nj1uuE0uuAvZF1qOZH734rIRNg3fupBX3SJoiHV/beMfcFzIEfoP8q/DmGfNzKKr5yd07Qvt+GLziTt7jDHBAnVxIsl3kLAEr6f84zv4F1mbU+4JLybc/E1yXiANSMaCj3h2Xaq1jqGzMObIAbP9Z6fwlu0+dKMifrwQJ9RlSlZcN25ckHXCsMuNjWpqzyIVGA9qXAazMEQGLo3nPg3acP/UkdrHZKJa19ojJIeRYpJqyTQPZm8GBCRxFqHL6actnAF6YrYS/zHoO1txlAb+HyCZuueYV6bSMhaA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=vP881uQqwZ/UAQQCQM0enfTzMRcqn2M5xLVb0hyth3o=;
 b=Db/ZKuMDfGH7X7So+8CHB3zMwnGWrASlT6HMg7K8y65iMyMii0OdJCarOK8u3ATTnZ/Pn9YQjDCVZvj/ffbPGhSPBnX2X7KkNh3Ha1iWdXUKR7A4RQw+hu32bfFlK+zG97NeSkXj+njPZ10BGzlEz1ypXbQMv4JIUrvY5PDUnM2PNAgKsPLdS0+tBXbkeUoX6CzJ6efxtE7yMGP10X88Chq6zHJL8T9JQn5c1g0YhhGb7XucZdaMvtWFSEabmmF7JPfd3MDX4VFQbzOKKQWCJPeIjMHFomCjB73Ariw+O5PPLLoPyxU2inz53cxUfZQPBGNtzqtAg+BHsp81kBMzCA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=vP881uQqwZ/UAQQCQM0enfTzMRcqn2M5xLVb0hyth3o=;
 b=F/0uSs9co2TrbsLywcSypK3wwPJ9A7g6KTa03SKEou8RC5ySWfTmvJ6NrQxK5tV1SzQfKlgVUbTCdP6zqQoU2kObjRAlXT0zJyHH9NXdBqRBUC8tlVt14v4uX6/RI5ZmHrb0umdmIKVVXxuDrPFrzzZYQmWn/FzSMemoAwyuzf1+Y3YGTKn9SdXFpzXnQ233u796vT1iGsRBuycJvGzDL8+9R54NCl9/R5MzKNdH0CoY3+v2R2G7PHgIlEuIIN5+NzeILKVVcE2cPFRqW8nH26sfVFsvIZnBKWkgVRmnIrX9aM3XiHN81Ry6uoLMQ+9uN9SpZLbH1vw6U313KfVCKw==
From: Mykyta Poturai <Mykyta_Poturai@epam.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
CC: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@epam.com>, Stefano
 Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand
 Marquis <bertrand.marquis@arm.com>, Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>, Mykyta Poturai
	<Mykyta_Poturai@epam.com>
Subject: [PATCH v2 1/2] ARM: ITS: implement quirks and add support for Renesas
 Gen4 ITS
Thread-Topic: [PATCH v2 1/2] ARM: ITS: implement quirks and add support for
 Renesas Gen4 ITS
Thread-Index: AQHbYc6JDAhmZxCQ3Eu7Expf0AOQsA==
Date: Wed, 8 Jan 2025 13:09:24 +0000
Message-ID:
 <e2544cace3517eb68cdffdc278f347584f93fd63.1736331828.git.mykyta_poturai@epam.com>
References: <cover.1736331828.git.mykyta_poturai@epam.com>
In-Reply-To: <cover.1736331828.git.mykyta_poturai@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB10102:EE_|PA4PR03MB6895:EE_
x-ms-office365-filtering-correlation-id: 0cb64274-bdd5-4fff-6812-08dd2fe5ac7f
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?rMECNaYCVnEg/QhE1eIqZK9GbszB/mcF4LVugNAkZL+71EjzFmRjGgVPJ5?=
 =?iso-8859-1?Q?IittsrVI55Zs4w4duSjPlQretvqeXxvxqmsl/M4A06DGK7lUb+cl7WDaH7?=
 =?iso-8859-1?Q?lLCkqcxOoWSlSs8i0wzFLn2FjCkhjPr9WaXMC394wTSL1quzYstO84QoPm?=
 =?iso-8859-1?Q?qz0Ij2x3nTbRHZvcFGt1aDIKqfm/Jkj/RRycL/gIQRpyOzv6huEDlVOvAu?=
 =?iso-8859-1?Q?hluufcslDcVVNJp39CV86/syAhGsbDqQ+kf689ReB93PmUKX15BOcMwWK1?=
 =?iso-8859-1?Q?EfPn1ewr7p+N+J+iSES7/+49w+1P2W9sv59wOaRuu/W3LxYDERGELnmHJ9?=
 =?iso-8859-1?Q?UjdWR6wc0VcYknerc2u3DzWHRIGuBCeZnCjgl0N87QgpO2XoZmek6IKy6b?=
 =?iso-8859-1?Q?PUtxLAPBFFajGiVqN7FM5UThNs+csHnbXpsfYruKek5U9gpfyzJXtWP+WF?=
 =?iso-8859-1?Q?7q7LewqhKSU8LkZr6tIgG6WKVfGE9cNvEArTQrUYwQiHDR67mQJQC1JSM1?=
 =?iso-8859-1?Q?sKk94f3uzTCg64112aE4Q612sBFl5Ar47DTsN6eLQ2Mw/yEMJ4yvtAoc5P?=
 =?iso-8859-1?Q?dXEFu3Yb5z7+9ig3Qm/LcyCCR+tYVphrPVQGCM4zI2rNoj5A7vWQTO8K9T?=
 =?iso-8859-1?Q?uaw5rhjAEATmDz7v4cci3dyK2JxLMO4pjcmLn1dHMwTrYtW70bO8+D1rPS?=
 =?iso-8859-1?Q?HHQBhreuXNpjDbJ+9RY0U1ZpdILAR7V517KWRJ3nvAa/PNQIFCyJulQyM9?=
 =?iso-8859-1?Q?9kV2+hWae5b9c2Y7qi6KFaTKkmrDjPltnhvO1IQN/89ILIOoeTJA6CoSGU?=
 =?iso-8859-1?Q?A9EpVlKlXeYuhNBnFHVSTAafDOvZZ9C6P5L07OCS5mYNuVqcnp0Oz1KUOQ?=
 =?iso-8859-1?Q?TsyZAFucQlJwmMP9wDNrG1B6U39G2f6YHXiXz13Wl1xcji5XltTexmu0Xu?=
 =?iso-8859-1?Q?dLfvkkA7/8RKjARr15AITwHTS1dfh+HTIi/tsLBSS7Qrv69XB5Uh4JV6p1?=
 =?iso-8859-1?Q?qoET5OLR9ikJMxj/er0c9McjheS9B1Z+0+z4rlYPg9cP5Esq0FfnSgvvaP?=
 =?iso-8859-1?Q?oqf2kz2MAQcb3KcvRepTVcnmbvuMLwKmsBLx3fYTXUDfHlOZdNvPL5Sxap?=
 =?iso-8859-1?Q?fYvqhFnz2qKJTK0hS6ws+PGWn0sQa9u21PNpxkB0BRbUltoGZ1Fa6UX7Du?=
 =?iso-8859-1?Q?s1Q/10nxoF1f6n/d62eqX23lVnX4bVWMINdYnGuOgz64vf18ZL/U5DWT8J?=
 =?iso-8859-1?Q?QC8c4zUT6XvtlDhJ6DMnu1ni6zAs/MK8Krh+uIt8j4PqtBv04go96+S1s4?=
 =?iso-8859-1?Q?EXoPhF5gYBzFHD1DyRaLAPPONqWmvSmj7bS6lcZ8jiLREh1/9j3jm3T5xE?=
 =?iso-8859-1?Q?jKASG5M8GMDTTc2nXZmXbiUIc5AJgcOCVcNSGASubsRM8TTDIO04PYLIoC?=
 =?iso-8859-1?Q?APN3Lw+YkZV5ILso?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB10102.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?nxropJGPTXJL8H7DjWi2mMtL+vCPbvi4qSCDSxRC7QUMwCUsUAqW+hN7ty?=
 =?iso-8859-1?Q?DfFw/2ghBb6IXnR53PpwtPiIdSwuXA1s6hTbLXpf9vEvkfpIdxYc+RM85F?=
 =?iso-8859-1?Q?cm+S9olSKAPkHcidMQUGHYB4C7RdGkcc4lfezADSq7iCBk9vmAnCLj5HLx?=
 =?iso-8859-1?Q?W809beJS/btl1Y1KVhg6qE5Dz10U5vlheZ7DQxBmFAlfvNvnq7aSbMc5zm?=
 =?iso-8859-1?Q?wqzBSApDl4IXMgx5DuryYif+jrkoX3OpAJl0GUR4nC2ZZ6+Gr/yxyWrOj+?=
 =?iso-8859-1?Q?+0et47WTwekuKtjOyWtH91irci503QG7izNn4fOBJ++FDIZsfqTVqa9LQO?=
 =?iso-8859-1?Q?BLV1Pl6vDSs1GoLK/QyJDeEu2JlmqcoCA/4NZHvDi7or2HIE27GozhCcEo?=
 =?iso-8859-1?Q?10WbiokGnMdQMFazkjg18bytK1U1KwAPLMnci9LK2qp95shVvP5VpDHvCF?=
 =?iso-8859-1?Q?v13wdkbCJqVLWy3yseTcpfPalYWKK9U86PFt3g0xGyEhOpN1wnK/amULnd?=
 =?iso-8859-1?Q?xNu/FOsk+uRERt4veJKs1bYksguz6aZp1EfOD/hQhcqqPpMjBXdS64Knfw?=
 =?iso-8859-1?Q?z8SuMYnSFHH3lBq1FgzHKiLH4BdxBeUPH6hfIt/IsTXvw+h+yaf+lTq9LM?=
 =?iso-8859-1?Q?3wBDmubAzmaOTyhOYImLHUKUt0Ua/b31L3l+WtPewCVwAJEt9PY6+/o4yf?=
 =?iso-8859-1?Q?lfiLXTR/XTUJdiCgKytcP+L7DUozjp0iLzuB4sltX7NB/UoMkhEw5bCKS7?=
 =?iso-8859-1?Q?tN8G9BC0MIsPQXvpM4VDAZIMFcKoc7etscUZUTYKj2r1wCLXHtL6GV842P?=
 =?iso-8859-1?Q?jwLG1euH3E00j04WMTKn2bTUF+jUjIBm/V9qrOOOBvOc8VBP2Luy4/2WRz?=
 =?iso-8859-1?Q?OGj/nLCpAOSvzQ0ZJyqF5uKcDXR6QVA6bDBNaVfEH5uqVFOG+ZDxs53aOm?=
 =?iso-8859-1?Q?1S3FtwFLN5eKM5YaWmr3u4AWtUEXZ/Hh91qHgf3rAJ6nMc//H9Fu+/Qx0A?=
 =?iso-8859-1?Q?wzDxJDQlap/YDn7+ZkZnf/tPOHRgxtB2Jvp/3r0CqaXzMvCoEn85BuDvRn?=
 =?iso-8859-1?Q?a6OZlL9Ai8th1f+7WJqF4hreyBrTfanE0z5T48AEFvFJEwrI4IdpQ7PyH6?=
 =?iso-8859-1?Q?j4lCnfjhKucBzytPA0o+Z/c1utZ6eTI+chUeyPXrQIM1zliXyExyPv+rKX?=
 =?iso-8859-1?Q?OB+wCRumQH8Y870iBSwbYBYaTEA8E/RquKWaB3/iSkgoMgJ5BxJ/ZChhez?=
 =?iso-8859-1?Q?cQkoFupQGlO8V8CkK1uP3/EIBqtPOmju/Twi5/QBmgZNEC1Ahq5vIeWZPg?=
 =?iso-8859-1?Q?AknO/1/pKitWlQB5atPx9kKE96FqICmWaCOQuksZ7mI7XkP4/lLLkiXRq9?=
 =?iso-8859-1?Q?KcgtMJto5zxpqBgq/lbpwsiBdyPz6qZnayy7ylRREnk1fBO4EqsAt7Ma8m?=
 =?iso-8859-1?Q?vJzV2Eg/rW2kuvPH0C7kgcwxgcXhUtl7+BCWY51Y1FaWzNntK2L09pfazf?=
 =?iso-8859-1?Q?9r3WFxKG1t8vGNyrn7aehunudVsCbGsZo6iMuORu1uu77eQ4y8g56rwqhv?=
 =?iso-8859-1?Q?n1S3LlIifHkG1a5s51HlweOm4LUVt8yo5GdOUXnHYdYE49AFhcgncVGhPG?=
 =?iso-8859-1?Q?vLcfl36lBUxVSlXKu0qjh3xst3f38/kwQhzs9N0xZPwRWhHqgKL9Klgg?=
 =?iso-8859-1?Q?=3D=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PAVPR03MB10102.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0cb64274-bdd5-4fff-6812-08dd2fe5ac7f
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2025 13:09:24.3894
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: aX6U3Uf4kNyoJNIpbbg7WeSZ7nFEZUA22xKOU+4VIbviSNFIVNiD5gaDb2bu/uMOmmFnwDi1mf3H5b/SHQdW9w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR03MB6895

From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>

There are number of ITS implementations exist which are different from
the base one which have number of functionalities defined as is
"IMPLEMENTATION DEFINED", e.g. there may exist differences in cacheability,
shareability and memory requirements and others. This requires
appropriate handling of such HW requirements which are implemented as
ITS quirks: GITS_IIDR (ITS Implementer Identification Register) is used to
differentiate the ITS implementations and select appropriate set of
quirks if any.

As an example of such ITSes add quirk implementation for Renesas Gen4 ITS:
- add possibility to override default cacheability and shareability
settings used for ITS memory allocations;
- change relevant memory allocations to alloc_xenheap_pages which allows
to specify memory access flags, free_xenheap_pages is used to free;
- add quirks validation to ensure that all ITSes share the same quirks
in case of multiple ITSes are present in the system;

The Gen4 ITS memory requirements are not covered in any errata as of yet,
but observed behavior suggests that they are indeed required.

The idea of the quirk implementation is inspired by the Linux kernel ITS
quirk implementation [1].

Changelog:
v1 -> v2:
- switched to using alloc_xenheap_pages/free_xenheap_pages for ITS memory
allocations;
- updated declaration of its_quirk_flags;
- added quirks validation to ensure that all ITSes share the same quirks;
- removed unnecessary vITS changes;


Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>

[1] https://elixir.bootlin.com/linux/v5.16.1/source/drivers/irqchip/irq-gic=
-v3-its.c
---
 xen/arch/arm/gic-v3-its.c             | 141 +++++++++++++++++++++++---
 xen/arch/arm/gic-v3-lpi.c             |  20 ++--
 xen/arch/arm/include/asm/gic_v3_its.h |   8 ++
 3 files changed, 150 insertions(+), 19 deletions(-)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 5fd83af25a..8849ac6c4b 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -42,6 +42,7 @@ struct its_device {
     struct rb_node rbnode;
     struct host_its *hw_its;
     void *itt_addr;
+    unsigned int itt_order;
     paddr_t guest_doorbell;             /* Identifies the virtual ITS */
     uint32_t host_devid;
     uint32_t guest_devid;
@@ -50,6 +51,104 @@ struct its_device {
     struct pending_irq *pend_irqs;      /* One struct per event */
 };
=20
+/*
+ * It is unlikely that a platform implements ITSes with different quirks,
+ * so assume they all share the same.
+ */
+struct its_quirk {
+    const char *desc;
+    bool (*init)(struct host_its *hw_its);
+    uint32_t iidr;
+    uint32_t mask;
+};
+
+static uint32_t __ro_after_init its_quirk_flags;
+
+static bool gicv3_its_enable_quirk_gen4(struct host_its *hw_its)
+{
+    its_quirk_flags |=3D HOST_ITS_WORKAROUND_NC_NS |
+        HOST_ITS_WORKAROUND_32BIT_ADDR;
+
+    return true;
+}
+
+static const struct its_quirk its_quirks[] =3D {
+    {
+        .desc	=3D "R-Car Gen4",
+        .iidr	=3D 0x0201743b,
+        .mask	=3D 0xffffffff,
+        .init	=3D gicv3_its_enable_quirk_gen4,
+    },
+    {
+        /* Sentinel. */
+    }
+};
+
+static struct its_quirk* gicv3_its_find_quirk(uint32_t iidr)
+{
+    const struct its_quirk *quirks =3D its_quirks;
+
+    for ( ; quirks->desc; quirks++ )
+    {
+        if ( quirks->iidr =3D=3D (quirks->mask & iidr) )
+            return (struct its_quirk *)quirks;
+    }
+
+    return NULL;
+}
+
+static void gicv3_its_enable_quirks(struct host_its *hw_its)
+{
+    uint32_t iidr =3D readl_relaxed(hw_its->its_base + GITS_IIDR);
+    const struct its_quirk *quirk =3D gicv3_its_find_quirk(iidr);
+
+    if ( quirk && quirk->init(hw_its) )
+        printk("GICv3: enabling workaround for ITS: %s\n", quirk->desc);
+}
+
+static void gicv3_its_validate_quirks(void)
+{
+    const struct its_quirk *quirk =3D NULL, *prev =3D NULL;
+    const struct host_its *hw_its;
+
+    if ( list_empty(&host_its_list) )
+        return;
+
+    hw_its =3D list_first_entry(&host_its_list, struct host_its, entry);
+    prev =3D gicv3_its_find_quirk(readl_relaxed(hw_its->its_base + GITS_II=
DR));
+
+    list_for_each_entry(hw_its, &host_its_list, entry)
+    {
+        quirk =3D gicv3_its_find_quirk(readl_relaxed(hw_its->its_base + GI=
TS_IIDR));
+        BUG_ON(quirk !=3D prev);
+        prev =3D quirk;
+    }
+}
+
+uint64_t gicv3_its_get_cacheability(void)
+{
+    if ( its_quirk_flags & HOST_ITS_WORKAROUND_NC_NS )
+        return GIC_BASER_CACHE_nC;
+
+    return GIC_BASER_CACHE_RaWaWb;
+}
+
+uint64_t gicv3_its_get_shareability(void)
+{
+    if ( its_quirk_flags & HOST_ITS_WORKAROUND_NC_NS )
+        return GIC_BASER_NonShareable;
+
+    return GIC_BASER_InnerShareable;
+}
+
+unsigned int gicv3_its_get_memflags(void)
+{
+    if ( its_quirk_flags & HOST_ITS_WORKAROUND_32BIT_ADDR )
+        return MEMF_bits(32);
+
+    return 0;
+}
+
 bool gicv3_its_host_has_its(void)
 {
     return !list_empty(&host_its_list);
@@ -289,19 +388,23 @@ static void *its_map_cbaser(struct host_its *its)
 {
     void __iomem *cbasereg =3D its->its_base + GITS_CBASER;
     uint64_t reg;
+    unsigned int order;
     void *buffer;
=20
-    reg  =3D GIC_BASER_InnerShareable << GITS_BASER_SHAREABILITY_SHIFT;
+    reg  =3D gicv3_its_get_shareability() << GITS_BASER_SHAREABILITY_SHIFT=
;
     reg |=3D GIC_BASER_CACHE_SameAsInner << GITS_BASER_OUTER_CACHEABILITY_=
SHIFT;
-    reg |=3D GIC_BASER_CACHE_RaWaWb << GITS_BASER_INNER_CACHEABILITY_SHIFT=
;
+    reg |=3D gicv3_its_get_cacheability() << GITS_BASER_INNER_CACHEABILITY=
_SHIFT;
=20
-    buffer =3D _xzalloc(ITS_CMD_QUEUE_SZ, SZ_64K);
+    order =3D get_order_from_bytes(max(ITS_CMD_QUEUE_SZ, SZ_64K));
+    buffer =3D alloc_xenheap_pages(order, gicv3_its_get_memflags());
     if ( !buffer )
         return NULL;
=20
+    memset(buffer, 0, PAGE_SIZE << order);
+
     if ( virt_to_maddr(buffer) & ~GENMASK(51, 12) )
     {
-        xfree(buffer);
+        free_xenheap_pages(buffer, order);
         return NULL;
     }
=20
@@ -340,11 +443,12 @@ static int its_map_baser(void __iomem *basereg, uint6=
4_t regc,
     unsigned int entry_size =3D GITS_BASER_ENTRY_SIZE(regc);
     unsigned int pagesz =3D 2;    /* try 64K pages first, then go down. */
     unsigned int table_size;
+    unsigned int order;
     void *buffer;
=20
-    attr  =3D GIC_BASER_InnerShareable << GITS_BASER_SHAREABILITY_SHIFT;
+    attr  =3D gicv3_its_get_shareability() << GITS_BASER_SHAREABILITY_SHIF=
T;
     attr |=3D GIC_BASER_CACHE_SameAsInner << GITS_BASER_OUTER_CACHEABILITY=
_SHIFT;
-    attr |=3D GIC_BASER_CACHE_RaWaWb << GITS_BASER_INNER_CACHEABILITY_SHIF=
T;
+    attr |=3D gicv3_its_get_cacheability() << GITS_BASER_INNER_CACHEABILIT=
Y_SHIFT;
=20
     /*
      * Setup the BASE register with the attributes that we like. Then read
@@ -357,13 +461,16 @@ retry:
     /* The BASE registers support at most 256 pages. */
     table_size =3D min(table_size, 256U << BASER_PAGE_BITS(pagesz));
=20
-    buffer =3D _xzalloc(table_size, BIT(BASER_PAGE_BITS(pagesz), UL));
+    order =3D get_order_from_bytes(max(table_size, BIT(BASER_PAGE_BITS(pag=
esz), U)));
+    buffer =3D alloc_xenheap_pages(order, gicv3_its_get_memflags());
     if ( !buffer )
         return -ENOMEM;
=20
+    memset(buffer, 0, PAGE_SIZE << order);
+
     if ( !check_baser_phys_addr(buffer, BASER_PAGE_BITS(pagesz)) )
     {
-        xfree(buffer);
+        free_xenheap_pages(buffer, order);
         return -ERANGE;
     }
=20
@@ -396,7 +503,7 @@ retry:
     if ( ((regc >> GITS_BASER_PAGE_SIZE_SHIFT) & 0x3UL) =3D=3D pagesz )
         return 0;
=20
-    xfree(buffer);
+    free_xenheap_pages(buffer, order);
=20
     if ( pagesz-- > 0 )
         goto retry;
@@ -453,6 +560,8 @@ static int gicv3_its_init_single_its(struct host_its *h=
w_its)
     if ( ret )
         return ret;
=20
+    gicv3_its_enable_quirks(hw_its);
+
     reg =3D readq_relaxed(hw_its->its_base + GITS_TYPER);
     hw_its->devid_bits =3D GITS_TYPER_DEVICE_ID_BITS(reg);
     hw_its->evid_bits =3D GITS_TYPER_EVENT_ID_BITS(reg);
@@ -530,7 +639,7 @@ static int remove_mapped_guest_device(struct its_device=
 *dev)
         printk(XENLOG_WARNING "Can't unmap host ITS device 0x%x\n",
                dev->host_devid);
=20
-    xfree(dev->itt_addr);
+    free_xenheap_pages(dev->itt_addr, dev->itt_order);
     xfree(dev->pend_irqs);
     xfree(dev->host_lpi_blocks);
     xfree(dev);
@@ -619,6 +728,7 @@ int gicv3_its_map_guest_device(struct domain *d,
     struct its_device *dev =3D NULL;
     struct rb_node **new =3D &d->arch.vgic.its_devices.rb_node, *parent =
=3D NULL;
     int i, ret =3D -ENOENT;      /* "i" must be signed to check for >=3D 0=
 below. */
+    unsigned int order;
=20
     hw_its =3D gicv3_its_find_by_doorbell(host_doorbell);
     if ( !hw_its )
@@ -681,10 +791,13 @@ int gicv3_its_map_guest_device(struct domain *d,
     ret =3D -ENOMEM;
=20
     /* An Interrupt Translation Table needs to be 256-byte aligned. */
-    itt_addr =3D _xzalloc(nr_events * hw_its->itte_size, 256);
+    order =3D get_order_from_bytes(max(nr_events * hw_its->itte_size, (uns=
igned long)256));
+    itt_addr =3D alloc_xenheap_pages(order, gicv3_its_get_memflags());
     if ( !itt_addr )
         goto out_unlock;
=20
+    memset(itt_addr, 0, PAGE_SIZE << order);
+
     clean_and_invalidate_dcache_va_range(itt_addr,
                                          nr_events * hw_its->itte_size);
=20
@@ -718,6 +831,7 @@ int gicv3_its_map_guest_device(struct domain *d,
         goto out_unlock;
=20
     dev->itt_addr =3D itt_addr;
+    dev->itt_order =3D order;
     dev->hw_its =3D hw_its;
     dev->guest_doorbell =3D guest_doorbell;
     dev->guest_devid =3D guest_devid;
@@ -775,7 +889,8 @@ out:
         xfree(dev->pend_irqs);
         xfree(dev->host_lpi_blocks);
     }
-    xfree(itt_addr);
+    if ( itt_addr )
+        free_xenheap_pages(itt_addr, order);
     xfree(dev);
=20
     return ret;
@@ -1089,6 +1204,8 @@ int gicv3_its_init(void)
             return ret;
     }
=20
+    gicv3_its_validate_quirks();
+
     return 0;
 }
=20
diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
index de4b0eb4a4..a8783e7d95 100644
--- a/xen/arch/arm/gic-v3-lpi.c
+++ b/xen/arch/arm/gic-v3-lpi.c
@@ -227,6 +227,7 @@ void gicv3_lpi_update_host_entry(uint32_t host_lpi, int=
 domain_id,
 static int gicv3_lpi_allocate_pendtable(unsigned int cpu)
 {
     void *pendtable;
+    unsigned int order;
=20
     if ( per_cpu(lpi_redist, cpu).pending_table )
         return -EBUSY;
@@ -237,7 +238,8 @@ static int gicv3_lpi_allocate_pendtable(unsigned int cp=
u)
      * The GICv3 imposes a 64KB alignment requirement, also requires
      * physically contiguous memory.
      */
-    pendtable =3D _xzalloc(lpi_data.max_host_lpi_ids / 8, SZ_64K);
+    order =3D get_order_from_bytes(max(lpi_data.max_host_lpi_ids / 8, (uns=
igned long)SZ_64K));
+    pendtable =3D alloc_xenheap_pages(order, gicv3_its_get_memflags());
     if ( !pendtable )
         return -ENOMEM;
=20
@@ -272,9 +274,9 @@ static int gicv3_lpi_set_pendtable(void __iomem *rdist_=
base)
=20
     ASSERT(!(virt_to_maddr(pendtable) & ~GENMASK(51, 16)));
=20
-    val  =3D GIC_BASER_CACHE_RaWaWb << GICR_PENDBASER_INNER_CACHEABILITY_S=
HIFT;
+    val  =3D gicv3_its_get_cacheability() << GICR_PENDBASER_INNER_CACHEABI=
LITY_SHIFT;
     val |=3D GIC_BASER_CACHE_SameAsInner << GICR_PENDBASER_OUTER_CACHEABIL=
ITY_SHIFT;
-    val |=3D GIC_BASER_InnerShareable << GICR_PENDBASER_SHAREABILITY_SHIFT=
;
+    val |=3D gicv3_its_get_shareability() << GICR_PENDBASER_SHAREABILITY_S=
HIFT;
     val |=3D GICR_PENDBASER_PTZ;
     val |=3D virt_to_maddr(pendtable);
=20
@@ -300,10 +302,11 @@ static int gicv3_lpi_set_pendtable(void __iomem *rdis=
t_base)
 static int gicv3_lpi_set_proptable(void __iomem * rdist_base)
 {
     uint64_t reg;
+    unsigned int order;
=20
-    reg  =3D GIC_BASER_CACHE_RaWaWb << GICR_PROPBASER_INNER_CACHEABILITY_S=
HIFT;
+    reg  =3D gicv3_its_get_cacheability() << GICR_PROPBASER_INNER_CACHEABI=
LITY_SHIFT;
     reg |=3D GIC_BASER_CACHE_SameAsInner << GICR_PROPBASER_OUTER_CACHEABIL=
ITY_SHIFT;
-    reg |=3D GIC_BASER_InnerShareable << GICR_PROPBASER_SHAREABILITY_SHIFT=
;
+    reg |=3D gicv3_its_get_shareability() << GICR_PROPBASER_SHAREABILITY_S=
HIFT;
=20
     /*
      * The property table is shared across all redistributors, so allocate
@@ -312,7 +315,10 @@ static int gicv3_lpi_set_proptable(void __iomem * rdis=
t_base)
     if ( !lpi_data.lpi_property )
     {
         /* The property table holds one byte per LPI. */
-        void *table =3D _xmalloc(lpi_data.max_host_lpi_ids, SZ_4K);
+        void *table;
+
+        order =3D get_order_from_bytes(max(lpi_data.max_host_lpi_ids, (uns=
igned long)SZ_4K));
+        table =3D alloc_xenheap_pages(order, gicv3_its_get_memflags());
=20
         if ( !table )
             return -ENOMEM;
@@ -320,7 +326,7 @@ static int gicv3_lpi_set_proptable(void __iomem * rdist=
_base)
         /* Make sure the physical address can be encoded in the register. =
*/
         if ( (virt_to_maddr(table) & ~GENMASK(51, 12)) )
         {
-            xfree(table);
+            free_xenheap_pages(table, order);
             return -ERANGE;
         }
         memset(table, GIC_PRI_IRQ | LPI_PROP_RES1, MAX_NR_HOST_LPIS);
diff --git a/xen/arch/arm/include/asm/gic_v3_its.h b/xen/arch/arm/include/a=
sm/gic_v3_its.h
index c24d4752d0..0737e67aa6 100644
--- a/xen/arch/arm/include/asm/gic_v3_its.h
+++ b/xen/arch/arm/include/asm/gic_v3_its.h
@@ -110,6 +110,9 @@
 #define HOST_ITS_FLUSH_CMD_QUEUE        (1U << 0)
 #define HOST_ITS_USES_PTA               (1U << 1)
=20
+#define HOST_ITS_WORKAROUND_NC_NS       (1U << 0)
+#define HOST_ITS_WORKAROUND_32BIT_ADDR  (1U << 1)
+
 /* We allocate LPIs on the hosts in chunks of 32 to reduce handling overhe=
ad. */
 #define LPI_BLOCK                       32U
=20
@@ -197,6 +200,11 @@ struct pending_irq *gicv3_assign_guest_event(struct do=
main *d,
 void gicv3_lpi_update_host_entry(uint32_t host_lpi, int domain_id,
                                  uint32_t virt_lpi);
=20
+/* ITS quirks handling. */
+uint64_t gicv3_its_get_cacheability(void);
+uint64_t gicv3_its_get_shareability(void);
+unsigned int gicv3_its_get_memflags(void);
+
 #else
=20
 #ifdef CONFIG_ACPI
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed Jan 08 13:09:31 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 13:09:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867267.1278732 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVVoO-0000CL-Bl; Wed, 08 Jan 2025 13:09:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867267.1278732; Wed, 08 Jan 2025 13:09:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVVoO-0000BY-6s; Wed, 08 Jan 2025 13:09:28 +0000
Received: by outflank-mailman (input) for mailman id 867267;
 Wed, 08 Jan 2025 13:09:27 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=sbNq=UA=epam.com=Mykyta_Poturai@srs-se1.protection.inumbo.net>)
 id 1tVVoN-0008Lh-94
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 13:09:27 +0000
Received: from EUR05-AM6-obe.outbound.protection.outlook.com
 (mail-am6eur05on2060d.outbound.protection.outlook.com
 [2a01:111:f403:2612::60d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c9b0dffe-cdc1-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 14:09:26 +0100 (CET)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by PA4PR03MB6895.eurprd03.prod.outlook.com
 (2603:10a6:102:e7::9) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8335.11; Wed, 8 Jan
 2025 13:09:25 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971%5]) with mapi id 15.20.8314.015; Wed, 8 Jan 2025
 13:09:25 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c9b0dffe-cdc1-11ef-a0df-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=nDa8fpuF750d+R2PqjCk+SPcZEZ6GaIsClzcOgI8Wx3CRQFReClUxwbliKSPxwVBduc3OCqSssVTz6sdwWmTBrrMuuSf5NSuioWZWzgxDh9AzuSjwNuJBIgoopZ7BTVwZiaLm7cYGBBbgmBV9z7VLyEj5LIyGe8xb4MjyNr5j9Mgqefy5CMc2mMs5zrUvmzcAxElIBY7t0ueyiB8OjRKziZl5vXac+EMfNg4KZ+MI+d+Pr3LxxTQOJDapHVO5UNy09DAgJt8pWYFpTRgHedmos3UVPOTTaVMzpkZ+G+8Ur95ZJttvOg6JGgesTJMLvADYvsbM3BRhtbd92nK8JsvGw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=eFrATFgoRJ6d7ziVWdmSYdnPpEDIZasMI6cQcXBIx4o=;
 b=IlhVs1NF0I6Bj9+UBSA0DV2/UW2SnwvnYInwmVzOuKQX3G5Uh2fTxmsbvdTZZ9fOVFM3CMtrg8Il988X3NouY9rr9qNVGO0EjMmwC5+1XPU01RKDi0NeqDYwLTmJRTp7v2CWrQplipd1T7WswS0A5Tl3hd6Ue2q05HBYq9IND69NYslIW7qSYWb3vyL5C8oYS52+SOAY/wWC1/OVV1KaP0G2g9oaJyI5679QFAyrstizo1v4barypI5lYWa2/r13rbCOmJWGJJ6CoL7IqGVTPO3AWKPuFpm41bHHhuCVUFDuPySSjPN8muoJeRwE/ncZ+Pn2CWIooS1h10Szsxyzsg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=eFrATFgoRJ6d7ziVWdmSYdnPpEDIZasMI6cQcXBIx4o=;
 b=p1tsTNoTm/pUZ7KTRGgfzfnEoaOYG/4EcSUpyQ+lj8TqOkOLHDndX/iUkQ96WE1Ed1LN0RbWuud7scCbGYYjPrTyv+qUBWegQXIR2ojf4cuk3jKxx/hC5MpN/hU3Y98XrjL7JtdePz910sSq1rAJdKfeH9ozEi4b7UCMeL5rcNzNLZfPhjPStxJcBY5JPc3fyFR+d2R3h5ASZGXO3ymbSVg9G7ceKRMMjyLVHsfVih9WnW0TLwq32qqa2t/25xw8NW8KsaIpW26nl28N7eeM9X9wBEqhGmbwv2V/WxZX38IKUsvl5XUKIUFoHy6xhwmPh2DQy/eO9P3+3PZQ585v1A==
From: Mykyta Poturai <Mykyta_Poturai@epam.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
CC: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@epam.com>, Stefano
 Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand
 Marquis <bertrand.marquis@arm.com>, Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>, Volodymyr Babchuk
	<Volodymyr_Babchuk@epam.com>, Mykyta Poturai <Mykyta_Poturai@epam.com>
Subject: [PATCH v2 2/2] xen/arm: platform: Add support for R-Car Gen4
Thread-Topic: [PATCH v2 2/2] xen/arm: platform: Add support for R-Car Gen4
Thread-Index: AQHbYc6Keb5mCkHZQkahUE8AT5r5CQ==
Date: Wed, 8 Jan 2025 13:09:25 +0000
Message-ID:
 <e4ead3d638c1ddf2539a2f0824284bd039892bff.1736331828.git.mykyta_poturai@epam.com>
References: <cover.1736331828.git.mykyta_poturai@epam.com>
In-Reply-To: <cover.1736331828.git.mykyta_poturai@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB10102:EE_|PA4PR03MB6895:EE_
x-ms-office365-filtering-correlation-id: 73188ba9-c1c9-4c35-2bd6-08dd2fe5ad3e
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?OoTds1l33loJRaNcCcz739klB93hkHl8+4TAAiDvi5hQ0Xwsnb4b8518Gq?=
 =?iso-8859-1?Q?HKoSB2mP/R3ZO0el557G1pTSFrc0mnd6KVLQfvlsYyLzt5VTUPTsIT5S0j?=
 =?iso-8859-1?Q?SqIeaMIY60DQRiWaqfijyyjFAi+/ofonX+Xd8Hp2X/2QtgQttSsTiGJ9Co?=
 =?iso-8859-1?Q?Dve9x4V38DghguL5e3aupJPUablow8dnrXdBubCm1YVhICr4NaBLTy9fCa?=
 =?iso-8859-1?Q?SDPB6wT9xs1/Byymr9zHajfrw/Rmxi7x2J4YfZPI0EdZZuoOiJiBGSTuvC?=
 =?iso-8859-1?Q?hhhVnlM+pA6X/8dASvj0o4g/0No/Def7eV65y66Z1k+R2EyFjv/EAqh9m6?=
 =?iso-8859-1?Q?8TMdh5xppTOz4te47QUhsy1WidY4A8PY4r6M2PPnGpPWXGeWqkdDWLphOq?=
 =?iso-8859-1?Q?k3sBZfffbiONTIErRz6JPpXlxvVyOp4aZDUKKPMyrDRE93g/Vioy5LLmEw?=
 =?iso-8859-1?Q?4gL80L+xFf8otT8GWZOAlF2Hl3tA01Pyxy8zxayAtJbrwdy+/rdobQir1J?=
 =?iso-8859-1?Q?I6fqnKH0EhTXZV4Dlp1eJBimv68+Ur1FohFLOzT+RYZ0bNacY84U/c6FYB?=
 =?iso-8859-1?Q?Rg1K0OK4C9bBX4ZiVzwEe2UlTkDN8DGID+eBBy0oasoHfqhPdylhx9MkJO?=
 =?iso-8859-1?Q?ITZlUAZxKwc9Zg0iodnuLfldwYokH4bVo8Tufezn+PMFVPDXO2e7puSwJP?=
 =?iso-8859-1?Q?2iST1sr+t0GRnlbBtJAneyexIGOg6aN2P0jMmHPPGzr0R6SXu8aRH9azRX?=
 =?iso-8859-1?Q?N4yDK9Uk1Bq460l7XA0ISpBm8s3sUzp/7Ssi3h1nQcAfKKOvPSXD4xz3xD?=
 =?iso-8859-1?Q?aNlMNNomjKhbNtRZ4MI6K0OuAKFBhFGDD+16cg4R5e2UF3GujeAAnyHrGe?=
 =?iso-8859-1?Q?KT16/73CbTMvHCq4B4aGyXBSdy148/UICCULz8FMBeXdM8vCpEYODEGAhQ?=
 =?iso-8859-1?Q?DhQFSEtGKGoDQ8Xp+kgGJ+L+REOBXrSRj428Dw0XCGV/LtVh/qaEX52AoP?=
 =?iso-8859-1?Q?iuh7nC37sjajb8emGPUjoUuQA+11Je2+hEP8JMdVd5hJ1RBSb0YAte7xfi?=
 =?iso-8859-1?Q?Glk+Uuuqrds3pUt62/vv3OIB/jXKm+ohaxQQxiz3YdTbNT4RpU4jlGwhwb?=
 =?iso-8859-1?Q?EOTUBQMD2Vqv+nZvTxYAwqVYXEKJvIDe23WI2WV/a9SJdG/vkD9MCa5OoN?=
 =?iso-8859-1?Q?W95HcBra5Rvzj/dgVeWaJ4lciNxeZW4jCc8N0dICXdEiOy/WbXdt5/2jIV?=
 =?iso-8859-1?Q?RvUNPllasaFgPVDaFH9Wc21c5yoGo1kHDkw3gT3NbNyUKkYEYLJAAJVFwJ?=
 =?iso-8859-1?Q?rHvQNt11qXl/5FY8pvsW7HkNbNlyvbY4bCQB4r0Pvho/zNiSbuFcVCks4i?=
 =?iso-8859-1?Q?v4w6lL1gaTE1wBGsHThPElhwcPOqn+Nl38379eIwXJFE3KsPln+vv1aBUL?=
 =?iso-8859-1?Q?EIAsPlS2Q9NAEg6/IEXwXsNDmxsVRIbAvU8trHYOY5H2sF7NkhXcMhZmiK?=
 =?iso-8859-1?Q?lyOli5mpB54LnUwdPbRMjX?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB10102.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?I1OaPJLBRT17+gf6lrss7wqB1sdy3/MwN/oTa2hlSLTvo5vtVfPqCZmceA?=
 =?iso-8859-1?Q?JIZu4mlRKVQS/QtSYdseM7u6Zrsfs9mFH63reTaGMKzC3QPSPU+g/xtyvD?=
 =?iso-8859-1?Q?B2+FDxgPuTG8Qy3ZDR4jWa2nQUZpmZ411J9K9fwaXFRuG0nqzwHCTTJVzZ?=
 =?iso-8859-1?Q?ZyPFX5vZG7dhKZqrQYMbzwJR2o2JnIjNrYe39A+kLiXwzevl53M2mwvAk8?=
 =?iso-8859-1?Q?CJU9e2VMk8Ql8GjIdeIcuEfRye0akIzlMPOeXg0jqD6XnicdgZJ/WrYxla?=
 =?iso-8859-1?Q?Uv9cJmMLVqe3mwhjGbQEiZ1mX9ZBb2gtlik7iS0aKgB5Xgxmc4Njh7ivIP?=
 =?iso-8859-1?Q?Xz3oEieF13vS4u+8bPpeIWWZVM7PGXhbdQz4SWMf1yJw6me10Orq06/EUG?=
 =?iso-8859-1?Q?T1pS/hFp6y5Kacxf+9J47qoxS8jZZWoL67UgEZDQnPAr01ZjukFBWHoLln?=
 =?iso-8859-1?Q?vvZ+gnSpkIZP0efn1NVYzE5Vfm6Miw9Bu8zaj0/lMdqv6ACeduEu/hg8AR?=
 =?iso-8859-1?Q?HMVMd2r5HTcYL4t6F0UJvpx+6+Nb7FgW+EEqTmOwjBESgkIG9YAENEiL6J?=
 =?iso-8859-1?Q?Ys0ts0uXcpQbOkKEikdhob8w+qJcdadqclrqO70DGUfDWDhhADnfUcyiec?=
 =?iso-8859-1?Q?vuzS2uwpFvUwJbNdC2zaDphnYCnfVhP1Jt/6zvxO+43oC7RisHwYq2qst4?=
 =?iso-8859-1?Q?LQR1pzrDfZUFCapOx/H4fywTSpRIq3NzA5ebwJn1S5qhzWiJkiXwh1ni8e?=
 =?iso-8859-1?Q?W9BJ2u5dZs7hBuvrvWcd8ZRJrJHV8wLTu5ltK8JM1tHdWSOEHoDyXC8JdR?=
 =?iso-8859-1?Q?OsYteWOTvGF08u7ooZ5Aan0yUKTDtUg6guAB4lJL4aV7NqVlHMGhPA1BvT?=
 =?iso-8859-1?Q?4BPnf2daAya6AEd8nAEcLo3fLSnWwahX751uMrNnx9PJ9vmCom3RqnNnPS?=
 =?iso-8859-1?Q?egw+qNbKtvSEXZ9H9aWeAykrdzpTSK/yxNkcod5yxJvcZ10drv1VVcNKr0?=
 =?iso-8859-1?Q?BQwGSQOR0OLtPCiQkvTMS4TwoBxTxqu1W3icdhv5gwdWszrGNSV975FRMJ?=
 =?iso-8859-1?Q?n8vkMdgIPc+8beZh1Y7ZmLFMY3z3ffTbOxpS8I3wwehmvbzs3FJvLjkykI?=
 =?iso-8859-1?Q?8aPYChscHHjRvV5U9SdbxEUSVbPHybAAgpmiicYAs+C6MlIl1IM2e0uU2t?=
 =?iso-8859-1?Q?hCdM7y2HsZduTxegpVJlQrO1Itq6VAU/yIVcBJwRtM1kAM30VVk8p8s1k0?=
 =?iso-8859-1?Q?9IpL9xuUdJfLE8tXJpkkTIvRVDMhPU2cIBEIJgrA7Z7fqHQCJi7puZeTAp?=
 =?iso-8859-1?Q?93sQe5lZtm5glxr0s2zJWcHPE7B3YJXDZWB3/4ef5ba/LQ/kxWNlT1NH/V?=
 =?iso-8859-1?Q?YyWBbhR2CZW/zZX9gb7FKzwN+3Cdvqc3TDM/TkJlaM9fX6Mpw4vkLC9edh?=
 =?iso-8859-1?Q?XpksmhnP5BLVjs5sZg6VmUYpI3WSw3R+6MAEBjoud5iAmZVxFz9glrjD1E?=
 =?iso-8859-1?Q?ZzFKpTVbg3lJE+duuh0P1HxnWYGvDX2bZxCbVSejgLSC/bh40e3MKWcPdp?=
 =?iso-8859-1?Q?/yO9ZX01h6aBRTXUn8jsen070/S0rsJlDQJbec39N+FL7GCQnizXcohVVV?=
 =?iso-8859-1?Q?4QICDxRNtGdDy8kdKF7QgrvQ+hOTHVtCOSKxZ9O5uY9zYFzClxeP6Juw?=
 =?iso-8859-1?Q?=3D=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PAVPR03MB10102.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 73188ba9-c1c9-4c35-2bd6-08dd2fe5ad3e
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2025 13:09:25.6471
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: xm6cvzJuICWEUqhm3SNXiVnAt3c4q3Rs24IazJdjXtmcMvMWWzKfAUjJxklZEybIwL3jgOLzT9erVU4CRtTjhQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR03MB6895

From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>

Add Rcar Gen4 platform choice to Kconfig to select all required
drivers automatically.

Changelog:
v1 -> v2:
- Added RB from Stefano Stabellini

Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
---
 xen/arch/arm/platforms/Kconfig | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kconfi=
g
index 02322c259c..8785c168bd 100644
--- a/xen/arch/arm/platforms/Kconfig
+++ b/xen/arch/arm/platforms/Kconfig
@@ -29,6 +29,15 @@ config RCAR3
 	help
 	Enable all the required drivers for Renesas RCar3
=20
+config RCAR4
+	bool "Renesas RCar4 support"
+	depends on ARM_64
+	select HAS_SCIF
+	select HAS_ITS
+	select IPMMU_VMSA
+	help
+	Enable all the required drivers for Renesas RCar4
+
 config MPSOC
 	bool "Xilinx Ultrascale+ MPSoC support"
 	depends on ARM_64
@@ -55,4 +64,3 @@ config ALL32_PLAT
 config MPSOC_PLATFORM
 	bool
 	default (ALL64_PLAT || MPSOC)
-
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed Jan 08 14:15:02 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 14:15:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867299.1278752 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVWpZ-0002UN-47; Wed, 08 Jan 2025 14:14:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867299.1278752; Wed, 08 Jan 2025 14:14:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVWpZ-0002UG-0n; Wed, 08 Jan 2025 14:14:45 +0000
Received: by outflank-mailman (input) for mailman id 867299;
 Wed, 08 Jan 2025 14:14: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 <SRS0=dPLU=UA=redhat.com=mst@srs-se1.protection.inumbo.net>)
 id 1tVWpY-0002UA-Lq
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 14:14:44 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.129.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e765bc86-cdca-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 15:14:43 +0100 (CET)
Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com
 [209.85.208.72]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-141-UP3WWTiqNrGV401L23r4hw-1; Wed, 08 Jan 2025 09:14:38 -0500
Received: by mail-ed1-f72.google.com with SMTP id
 4fb4d7f45d1cf-5d3dbddb891so1020300a12.0
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 06:14:38 -0800 (PST)
Received: from redhat.com ([2a02:14f:175:d62d:93ef:d7e2:e7da:ed72])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d80701ca31sm25153860a12.88.2025.01.08.06.14.31
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 06:14:35 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e765bc86-cdca-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1736345681;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=yNcVBbhGtCzb9GuZyfZlONnG3UaP4zdH2tNBP9ClSbY=;
	b=DyqYjGrAePt6RTYmQ2xhmQkyjzjifZRKHuZDmRiLZImxq9TpBneYYCVR8nYrT28wF6BfSm
	zzRgtddGFTgZ4p3KVfzplrCj71pW/X79PTqq398kOhnYBCXiNWK0B8klWF515y5yFOKVH5
	YCYaVuGYxb7VxJsJEWQwvZptLNOKaWk=
X-MC-Unique: UP3WWTiqNrGV401L23r4hw-1
X-Mimecast-MFC-AGG-ID: UP3WWTiqNrGV401L23r4hw
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736345677; x=1736950477;
        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=yNcVBbhGtCzb9GuZyfZlONnG3UaP4zdH2tNBP9ClSbY=;
        b=SU+SAk140orcjGWsNl1BDVpJepnFIyOQ5bo8gv3NTpYIcUr4IpzhhE44oh2Of+fNam
         X2Ud84DdscDsDwzsGQN9F+L4/YVJLPc6GbSA4UD5yTdKiNjI7dFiemkrSJGpSx4RGIE5
         mBs/QXWlhLGru/ryTKeMN3pVS19bt2kxsIl1v64s/V1XJb0YfCT9qWVN20fx0DRn6yX7
         zzPUnesxUYoCgHPUVcYugg2rUblG+p9fHEuRFcJFsVnGb6rvZsx5YyE3LKLGm2KH+zjS
         6k24E795HCxwyiOdNyLQOk2OKw9aUtSPFmhrC6H8VufhV/nv/tu/+rPBrroUSjiOXO1P
         CG6g==
X-Forwarded-Encrypted: i=1; AJvYcCXdIbEduNLheLjFsdM0OeAkU/gmgaLPivzgCdWcvUjUwwVOKIhS6vSRLUw3HsS55JE+dUMxVhs/lyg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwBCJw1zOucm4k7yZVzwBm1HLgb3w6WCZtCmKTVRZ/q02lmCVJi
	33wWFYcTcqZstE5reUjtCaQNm0/kDQWjxjtCGEraUYT9DCLO64psxF4RWKoktQXiamBKA/lrPFF
	nJQfyommIqGCwZJhkq9hDtIiiIT6t4aAkOkkO0bMmODynza/aQMpc3pdWfvQjcoGP
X-Gm-Gg: ASbGncuqidb7MJD3gcsxcC3GRi1+11jleGENuYV5yB+xQ3h8YXC6h04a2Dz6fyQlVFS
	YI/XSX4/g+6lOBv7HBR0dfZVK1B+CbUN3Ol+4TdHouA8Hm7hOouuItB4ML7zVaRXcdz+gaiE94e
	dHocoAdAVeeBYGvDr6eLcyzOGXbkYyB769IjpBhSV1bMqP5QL6dTzTLIgFFeTfjpSPiAEpaNxgt
	WJm7uZw/+FZ3phzj3omQLCPk5fa9yl7AFfQWtajuVXXCd0uctk=
X-Received: by 2002:a05:6402:26cd:b0:5d0:d845:2882 with SMTP id 4fb4d7f45d1cf-5d971ba439cmr2707858a12.13.1736345677195;
        Wed, 08 Jan 2025 06:14:37 -0800 (PST)
X-Google-Smtp-Source: AGHT+IFKtk9x9QKCmWxztdABmLZGo0gNmHg9Dd/RFbOSpC8jj0cQZPb5Vvzgn8YqKiPuocWpS+tLNQ==
X-Received: by 2002:a05:6402:26cd:b0:5d0:d845:2882 with SMTP id 4fb4d7f45d1cf-5d971ba439cmr2707819a12.13.1736345676708;
        Wed, 08 Jan 2025 06:14:36 -0800 (PST)
Date: Wed, 8 Jan 2025 09:14:29 -0500
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Julia Zhang <julia.zhang@amd.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony.perard@citrix.com>,
	Paul Durrant <paul@xen.org>,
	"Edgar E . Iglesias" <edgar.iglesias@gmail.com>,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
	xen-devel@lists.xenproject.org,
	Alex Deucher <alexander.deucher@amd.com>,
	Christian =?iso-8859-1?Q?K=F6nig?= <christian.koenig@amd.com>,
	Xenia Ragiadakou <burzalodowa@gmail.com>,
	Chen Jiqian <Jiqian.Chen@amd.com>, Huang Rui <ray.huang@amd.com>,
	Penny Zheng <penny.zheng@amd.com>,
	Zhu Lingshan <Lingshan.Zhu@amd.com>,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Juergen Gross <jgross@suse.com>,
	Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
	qemu-devel@nongnu.org
Subject: Re: [PATCH 3/3] virtio-gpu: add a new command to get p2pdma_distance
Message-ID: <20250108091357-mutt-send-email-mst@kernel.org>
References: <20241207105537.542441-1-julia.zhang@amd.com>
 <20241207105537.542441-4-julia.zhang@amd.com>
MIME-Version: 1.0
In-Reply-To: <20241207105537.542441-4-julia.zhang@amd.com>
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: wFotA_itGZFiMhkQXq0I8oHeIRez2LsqWCVYmkeTdZI_1736345677
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Sat, Dec 07, 2024 at 06:55:40PM +0800, Julia Zhang wrote:
> diff --git a/include/standard-headers/linux/virtio_gpu.h b/include/standard-headers/linux/virtio_gpu.h
> index 6459fdb9fb..2e55dcc2fe 100644
> --- a/include/standard-headers/linux/virtio_gpu.h
> +++ b/include/standard-headers/linux/virtio_gpu.h
> @@ -95,6 +95,7 @@ enum virtio_gpu_ctrl_type {
>  	VIRTIO_GPU_CMD_SUBMIT_3D,
>  	VIRTIO_GPU_CMD_RESOURCE_MAP_BLOB,
>  	VIRTIO_GPU_CMD_RESOURCE_UNMAP_BLOB,
> +	VIRTIO_GPU_CMD_P2PDMA_DISTANCE,
>  
>  	/* cursor commands */
>  	VIRTIO_GPU_CMD_UPDATE_CURSOR = 0x0300,
> @@ -108,6 +109,7 @@ enum virtio_gpu_ctrl_type {
>  	VIRTIO_GPU_RESP_OK_EDID,
>  	VIRTIO_GPU_RESP_OK_RESOURCE_UUID,
>  	VIRTIO_GPU_RESP_OK_MAP_INFO,
> +	VIRTIO_GPU_RESP_OK_P2PDMA_DISTANCE,
>  
>  	/* error responses */
>  	VIRTIO_GPU_RESP_ERR_UNSPEC = 0x1200,
> @@ -429,6 +431,23 @@ struct virtio_gpu_set_scanout_blob {
>  	uint32_t offsets[4];
>  };
>  
> +/* VIRTIO_GPU_CMD_P2PDMA_DISTANCE */
> +struct virtio_gpu_device_p2pdma_distance {
> +	struct virtio_gpu_ctrl_hdr hdr;
> +	__le32 provider_bus;
> +	__le32 provider_slot;
> +	__le32 provider_func;
> +	__le32 client_bus;
> +	__le32 client_slot;
> +	__le32 client_func;
> +};
> +
> +/* VIRTIO_GPU_RESP_DISTANCE */
> +struct virtio_gpu_resp_distance {
> +	struct virtio_gpu_ctrl_hdr hdr;
> +	__le32 distance;
> +};
> +
>  /* VIRTIO_GPU_CMD_RESOURCE_MAP_BLOB */
>  struct virtio_gpu_resource_map_blob {
>  	struct virtio_gpu_ctrl_hdr hdr;
> -- 
> 2.34.1

This is not how we change this header.
you need a spec patch, an UAPI change to be accepted into linux.

-- 
MST



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 14:22:51 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 14:22:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867310.1278778 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVWxL-0004DD-0m; Wed, 08 Jan 2025 14:22:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867310.1278778; Wed, 08 Jan 2025 14:22:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVWxK-0004D6-TT; Wed, 08 Jan 2025 14:22:46 +0000
Received: by outflank-mailman (input) for mailman id 867310;
 Wed, 08 Jan 2025 14:22:46 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=dlK9=UA=bounce.vates.tech=bounce-md_30504962.677e8a32.v1-92b24b3a57f545cb8805b8815b935cad@srs-se1.protection.inumbo.net>)
 id 1tVWxK-0004Co-Am
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 14:22:46 +0000
Received: from mail135-5.atl141.mandrillapp.com
 (mail135-5.atl141.mandrillapp.com [198.2.135.5])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 062bcc52-cdcc-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 15:22:44 +0100 (CET)
Received: from pmta14.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail135-5.atl141.mandrillapp.com (Mailchimp) with ESMTP id
 4YSqrL3NxkzG0CDyJ
 for <xen-devel@lists.xenproject.org>; Wed,  8 Jan 2025 14:22:42 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 92b24b3a57f545cb8805b8815b935cad; Wed, 08 Jan 2025 14:22:42 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 062bcc52-cdcc-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1736346162; x=1736606662;
	bh=l9aIgygx1SD+0C6R9iRWsOo3b79znwZL6XYccVqWfEI=;
	h=From:Subject:To:Cc:Message-Id:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=JvLO8QGeiNr9xSj8t6kedsuZzI9HlFxuk1NVjHmfdVn5etdV+J3lDPSx+IjYA2u3k
	 GFlzICa9b+5CF+6Tne+JfKQf+LP2ceVA4cgaDUgY7rA7T6viXSCszZc/w6DirbulEA
	 NzO0KAHDxntNBctLFlmxkbh4JzZq3CPddyhbdd6eZ7t6nQSktVtYJtMuU0td9JeQHy
	 /h0Lu2oTOuCooBwMrc+I2lxVpmc5BiYdB5VKnYrrDA7ohiB0XPQBP6xCLW07UiVx5m
	 IiTv7oyhmguwFgyqsEvRsd/T2ER5n8AHZ7kseoeSRwi0BCunrzOJEKQKpcB9fObN4e
	 gkT6WffXxW9dQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1736346162; x=1736606662; i=anthony.perard@vates.tech;
	bh=l9aIgygx1SD+0C6R9iRWsOo3b79znwZL6XYccVqWfEI=;
	h=From:Subject:To:Cc:Message-Id:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=GcS1ztowT+ZYK4aaaGdZuT/pJTv13deBe0Tm7oJScLRjkt1SSUNj0hZi1n7Nm5xms
	 k26QRbm3h0fYCLogAR+DWQ1DvonX33IhVvB3Kz96GNGgCSlzsN89/18e0Hbg0Wc/bm
	 GR/TiVnKw8O/UCRj6B4y0sbHrEgd3Y1LW6tuAs1cS2Z/8TpmIdnw1Li7Vb0iiV9NSk
	 VJD0yG+dw+nItQ1gipbEnXaOdNkrZ+kKZstKLO6LE3jMZ+c5SCvFPY6gpjwT9DpPmY
	 A4w8lweZra2ea2h/S/lJXxns45FkzEi1deHP7855x/r0GOHQsK0IaHCHOYBJzfup7D
	 QbxVU9HMdrXnQ==
From: "Anthony PERARD" <anthony.perard@vates.tech>
Subject: =?utf-8?Q?Re:=20[PATCH=20for-4.20]=20CI:=20Update=20Fedora=20to=2041?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1736346160531
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, "Stefano Stabellini" <sstabellini@kernel.org>, "Michal Orzel" <michal.orzel@amd.com>, "Doug Goldstein" <cardoe@cardoe.com>, "Oleksii Kurochko" <oleksii.kurochko@gmail.com>, "=?utf-8?Q?Marek=20Marczykowski-G=C3=B3recki?=" <marmarek@invisiblethingslab.com>
Message-Id: <Z36KL4Sss_QuUQim@l14>
References: <20250108124316.1107121-1-andrew.cooper3@citrix.com>
In-Reply-To: <20250108124316.1107121-1-andrew.cooper3@citrix.com>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.92b24b3a57f545cb8805b8815b935cad?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250108:md
Date: Wed, 08 Jan 2025 14:22:42 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On Wed, Jan 08, 2025 at 12:43:16PM +0000, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>

Thanks,

-- 

Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


From xen-devel-bounces@lists.xenproject.org Wed Jan 08 14:30:29 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 14:30:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867319.1278811 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVX4l-0006Md-HQ; Wed, 08 Jan 2025 14:30:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867319.1278811; Wed, 08 Jan 2025 14:30:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVX4l-0006LW-DN; Wed, 08 Jan 2025 14:30:27 +0000
Received: by outflank-mailman (input) for mailman id 867319;
 Wed, 08 Jan 2025 14:30:26 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=2h7L=UA=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tVX4k-0005q4-6d
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 14:30:26 +0000
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com
 [2a00:1450:4864:20::52f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1931632d-cdcd-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 15:30:24 +0100 (CET)
Received: by mail-ed1-x52f.google.com with SMTP id
 4fb4d7f45d1cf-5d3e9a88793so4960344a12.1
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 06:30:24 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d9706479b5sm1016086a12.80.2025.01.08.06.30.22
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 06:30:22 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1931632d-cdcd-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736346624; x=1736951424; 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=UQMf50ZHpIa44OSs3yzjDxbHIqEp8PQJQD9zzetsDcU=;
        b=YfM7FdBQgHx/M4dNmTpuymgeNZwD02HJqlGjDQgrMjg+OYOYbhShD0PLZzBvt7yg8f
         /YH+Duowyv8wrhgjWG9GpoqZynhCz96rJnckqxcIeEK2mrG7tMdFWC/riq8clHHtB18M
         cF25sqpG5oQrUerbKc/8kALehYiRxLvmiUweg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736346624; x=1736951424;
        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=UQMf50ZHpIa44OSs3yzjDxbHIqEp8PQJQD9zzetsDcU=;
        b=qw5fIpadAl+Af/fg5uq27iIcZV3Vs3JmmCwwUvNTTPi7Ccy4Xb38yV7H0TcnjwVY5C
         ZnTLA0VJkZzOo2TGMTk8NW/JlJ7SDG8M1gCx/u98Lt1XN2J8AbJ5SWwKXssJwl0QFo/N
         ZuoJiXW9q9t0zIef8xBJQKKrZazMo8PIYLBCHyk0NYZ7I5HsQLOGp8ZUoPVqY2/41rNe
         /J2kOvAyIOYDItBouoVwupxmL/lLTwqYubxuiA43k/cL5/sPHw4aFRJSYPPxSBY5B5a/
         9xgXc0POM+3y5m/3ZoOMSraHEZRmT+Nc3MR4JdpxLn1iAKji+w9I8rhYH4rVC+B3dYTv
         YGXQ==
X-Gm-Message-State: AOJu0YyTAXeI6LsprypjUdekyjHbPVW5iIdTZq2/nxi5i4pqGo5hZRHZ
	5BjmzesHk/1kLWPTcNbymIy2Bb3GrTIavcS3lOswcWLQzvGuJwmQSUIXDZbV/zGRJ6QU5EdRWEo
	M
X-Gm-Gg: ASbGncu45PAH28vuB0r1Ib6K1CKHcgbUroWuCzT5XaNPsr9V9V0y9YEQ+ybinE1g+2K
	ZJ4T14nEjdV2B40nPt+jmpXb2kXWoWUjP3QsZXujNKN0fQ3fJtxUy//gfdtqvItOq5fQyEN18IL
	is7TFsSgnUY66s+oDfHj4dSrMy2u+1rKLb4LCz4yQAeWM4WCqyiUNtnKcIGUXe3XfrVDCRVYdj2
	Me4wKxW/oexri3SrVCJRgdiMDIITMQ2KCYYHleA//7syFluHgH4TtWwB/+lpXUm+FA=
X-Google-Smtp-Source: AGHT+IHdJHwme3Fk7T3dwmFLrxPAAgzz/GSB5rVNHFrsraCY0UzIaxFIR3nsYEJxKaWWNSdnngvcNA==
X-Received: by 2002:a05:6402:35c4:b0:5d3:e63c:7d71 with SMTP id 4fb4d7f45d1cf-5d972e06e45mr2432016a12.11.1736346623952;
        Wed, 08 Jan 2025 06:30:23 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: [PATCH v2 03/18] x86/mm: introduce helper to detect per-domain L1 entries that need freeing
Date: Wed,  8 Jan 2025 15:26:43 +0100
Message-ID: <20250108142659.99490-4-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250108142659.99490-1-roger.pau@citrix.com>
References: <20250108142659.99490-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

L1 present entries that require the underlying page to be freed have the
_PAGE_AVAIL0 bit set, introduce a helper to unify the checking logic into a
single place.

No functional change intended.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/arch/x86/mm.c | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index fa21903eb25a..3d5dd22b6c36 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -6294,6 +6294,12 @@ void __iomem *__init ioremap_wc(paddr_t pa, size_t len)
     return (void __force __iomem *)(va + offs);
 }
 
+static bool perdomain_l1e_needs_freeing(l1_pgentry_t l1e)
+{
+    return (l1e_get_flags(l1e) & (_PAGE_PRESENT | _PAGE_AVAIL0)) ==
+           (_PAGE_PRESENT | _PAGE_AVAIL0);
+}
+
 int create_perdomain_mapping(struct domain *d, unsigned long va,
                              unsigned int nr, l1_pgentry_t **pl1tab,
                              struct page_info **ppg)
@@ -6446,9 +6452,7 @@ void destroy_perdomain_mapping(struct domain *d, unsigned long va,
 
                 for ( ; nr && i < L1_PAGETABLE_ENTRIES; --nr, ++i )
                 {
-                    if ( (l1e_get_flags(l1tab[i]) &
-                          (_PAGE_PRESENT | _PAGE_AVAIL0)) ==
-                         (_PAGE_PRESENT | _PAGE_AVAIL0) )
+                    if ( perdomain_l1e_needs_freeing(l1tab[i]) )
                         free_domheap_page(l1e_get_page(l1tab[i]));
                     l1tab[i] = l1e_empty();
                 }
@@ -6498,9 +6502,7 @@ void free_perdomain_mappings(struct domain *d)
                         unsigned int k;
 
                         for ( k = 0; k < L1_PAGETABLE_ENTRIES; ++k )
-                            if ( (l1e_get_flags(l1tab[k]) &
-                                  (_PAGE_PRESENT | _PAGE_AVAIL0)) ==
-                                 (_PAGE_PRESENT | _PAGE_AVAIL0) )
+                            if ( perdomain_l1e_needs_freeing(l1tab[k]) )
                                 free_domheap_page(l1e_get_page(l1tab[k]));
 
                         unmap_domain_page(l1tab);
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 14:30:29 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 14:30:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867316.1278788 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVX4h-0005qH-NK; Wed, 08 Jan 2025 14:30:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867316.1278788; Wed, 08 Jan 2025 14: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 <xen-devel-bounces@lists.xenproject.org>)
	id 1tVX4h-0005qA-KF; Wed, 08 Jan 2025 14:30:23 +0000
Received: by outflank-mailman (input) for mailman id 867316;
 Wed, 08 Jan 2025 14:30: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
 <SRS0=2h7L=UA=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tVX4g-0005q4-D8
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 14:30:22 +0000
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com
 [2a00:1450:4864:20::533])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1699e336-cdcd-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 15:30:20 +0100 (CET)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-5d7e3f1fc01so6046536a12.2
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 06:30:20 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d80676f218sm26160592a12.26.2025.01.08.06.30.18
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 06:30:19 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1699e336-cdcd-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736346619; x=1736951419; 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=k9MQ0c7AAWp4dnuzrpxoUQPOajqVONYO8vVuEmo1UPo=;
        b=qvonbIBVgw83Tyy5yE2o+frHw9rMVFUOpf2RQGBmajq7hA0IiL/Lplz9uzSRa5LmsG
         dI9Q5cCNL5JmFGHIwvq+HR9FSaf9hSqPMQft36ZsiSlnRHDLPMeHz4XnmlZlrO3FCIO0
         dzNvvMKZMUo5CaOumtb5bNxYheFkxwrqRKKKU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736346619; x=1736951419;
        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=k9MQ0c7AAWp4dnuzrpxoUQPOajqVONYO8vVuEmo1UPo=;
        b=nUHBkm5u9mk/usaGqj9PUalqx3WLkjaUuyZoChx1wCrZqrhwvZ71Bq/gJrQuRZQkh/
         7HN6frVbEVlNl7UZp+vtKpY2ywZIt5nRYknfqrbXfecNKM3wCpuC/nwhyHFHkOetLYTu
         A2xhdAHZlfagRoLR2sNpw0ZMsIWBeiEor2Mo7KRoFyVnGYREcoEMPyVV5QPq2WK4EOzO
         ZVYkzXul2pWAaDHBG6Q4UpfgcqQsEmnPSuzl2YWv4fXnOfu5u4ZUBopJNItVklP/ulUQ
         WA5n0josB/GTRyn4a1RLjbn8TkJ3emgp7KqLFdddCQUjcUghyjzdrXOOZ4/o0RIRLO1F
         JaIQ==
X-Gm-Message-State: AOJu0Yz/+EGlsHeHmmlJ0Wf1gW3qt0gmx15bFP8kiAzVUxRZXjFDBVKW
	tZtlHMqmCE1IrL2RLdzoo0hcL1JGGM60J/T3c5/1nf/cz/U1QH0EaZLGcZtn4qhId52IvZzvchW
	J
X-Gm-Gg: ASbGncv4/P+ugsBL89OI5+Ikw4vw68uuuzi+oQwcuwwVXAWcN7f3stq+Sj0Xibi3lNl
	4nlyyuy5trOphH6oNWxTzPI2l3Um2q5u7MwFPRkOZ7l9Bjaj213ukGyebh8qa4AoI5wA5W9tkC+
	mQ/K5l2vg9ZsmrC4wrAGXu2BGUb3sbYXPmvQ73Bz1/8mh/lB00xskKyI6mzQ4++BPE8Q3h9LeT1
	ahbIDeqtrvqDYnEHewvoQIVyKTwSv/KS1gdLH0Tm1b0gQJedPU0bt9WzUeDXFmnQpw=
X-Google-Smtp-Source: AGHT+IG+pJsIlGG+aftHU0ZDrCXF+ci65TLyVF/33jBtrK1smwH4TMXg5kvElL53NT0pX4ZKfnI3+w==
X-Received: by 2002:a05:6402:50d0:b0:5d3:d917:dd90 with SMTP id 4fb4d7f45d1cf-5d972dfb3d9mr2611862a12.6.1736346619468;
        Wed, 08 Jan 2025 06:30:19 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Tim Deegan <tim@xen.org>
Subject: [PATCH v2 00/18] x86: adventures in Address Space Isolation
Date: Wed,  8 Jan 2025 15:26:40 +0100
Message-ID: <20250108142659.99490-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Hello,

The aim of this series is to introduce the functionality required to
create linear mappings visible to a single pCPU.

Doing so requires having a per-vCPU root page-table (L4), and hence
requires shadowing the guest selected L4 on PV guests.  As follow ups
(and partially to ensure the per-CPU mappings work fine) the CPU stacks
are switched to use per-CPU mappings, so that remote stack contents are
not by default mapped on all page-tables (note: for this to be true the
directmap entries for the stack pages would need to be removed also).

There's one known shortcoming with the presented code: migration of PV
guests using per-vCPU root page-tables is not working.  I need to
introduce extra logic to deal with PV shadow mode when using unique root
page-tables.  I don't think this should block the series however, such
missing functionality can always be added as follow up work.
paging_domctl() is adjusted to reflect this restriction.

The main differences compared to v1 are the usage of per-vCPU root page
tables (as opposed to per-pCPU), and the usage of the existing perdomain
family of functions to manage the mappings in the per-domain slot, that
now becomes per-vCPU.

All patches until 17 are mostly preparatory, I think there's a nice
cleanup and generalization of the creation and managing of per-domain
mappings, by no longer storing references to L1 page-tables in the vCPU
or domain struct.

Patch 13 introduces the command line option, and would need discussion
and integration with the sparse direct map series.  IMO we should get
consensus on how we want the command line to look ASAP, so that we can
basic parsing logic in place to be used by both the work here and the
direct map removal series.

As part of this series the map_domain_page() helpers are also switched
to create per-vCPU mappings (see patch 15), which converts an existing
interface into creating per-vCPU mappings.  Such interface can be used
to hide (map per-vCPU) further data that we don't want to be part of the
direct map, or even shared between vCPUs of the same domain.  Also all
existing users of the interface will already create per-vCPU mappings
without needing additional changes.

Note that none of the logic introduced in the series removes entries for
the directmap, so even when creating the per-CPU mappings the underlying
physical addresses are fully accessible when using it's direct map
entries.

I also haven't done any benchmarking.  Doesn't seem to cripple
performance up to the point that XenRT jobs would timeout before
finishing, that the only objective reference I can provide at the
moment.

The series has been extensively tested on XenRT, but that doesn't cover
all possible use-cases, so it's likely to still have some rough edges,
handle with care.

Thanks, Roger.

Roger Pau Monne (18):
  x86/mm: purge unneeded destroy_perdomain_mapping()
  x86/domain: limit window where curr_vcpu != current on context switch
  x86/mm: introduce helper to detect per-domain L1 entries that need
    freeing
  x86/pv: introduce function to populate perdomain area and use it to
    map Xen GDT
  x86/mm: switch destroy_perdomain_mapping() parameter from domain to
    vCPU
  x86/pv: set/clear guest GDT mappings using
    {populate,destroy}_perdomain_mapping()
  x86/pv: update guest LDT mappings using the linear entries
  x86/pv: remove stashing of GDT/LDT L1 page-tables
  x86/mm: simplify create_perdomain_mapping() interface
  x86/mm: switch {create,destroy}_perdomain_mapping() domain parameter
    to vCPU
  x86/pv: untie issuing FLUSH_ROOT_PGTBL from XPTI
  x86/mm: move FLUSH_ROOT_PGTBL handling before TLB flush
  x86/spec-ctrl: introduce Address Space Isolation command line option
  x86/mm: introduce per-vCPU L3 page-table
  x86/mm: introduce a per-vCPU mapcache when using ASI
  x86/pv: allow using a unique per-pCPU root page table (L4)
  x86/mm: switch to a per-CPU mapped stack when using ASI
  x86/mm: zero stack on context switch

 docs/misc/xen-command-line.pandoc    |  24 +++
 xen/arch/x86/cpu/mcheck/mce.c        |   4 +
 xen/arch/x86/domain.c                | 157 +++++++++++----
 xen/arch/x86/domain_page.c           | 105 ++++++----
 xen/arch/x86/flushtlb.c              |  28 ++-
 xen/arch/x86/hvm/hvm.c               |   6 -
 xen/arch/x86/include/asm/config.h    |  16 +-
 xen/arch/x86/include/asm/current.h   |  58 +++++-
 xen/arch/x86/include/asm/desc.h      |   6 +-
 xen/arch/x86/include/asm/domain.h    |  50 +++--
 xen/arch/x86/include/asm/flushtlb.h  |   2 +-
 xen/arch/x86/include/asm/mm.h        |  15 +-
 xen/arch/x86/include/asm/processor.h |   5 +
 xen/arch/x86/include/asm/pv/mm.h     |   5 +
 xen/arch/x86/include/asm/smp.h       |  12 ++
 xen/arch/x86/include/asm/spec_ctrl.h |   4 +
 xen/arch/x86/mm.c                    | 291 +++++++++++++++++++++------
 xen/arch/x86/mm/hap/hap.c            |   2 +-
 xen/arch/x86/mm/paging.c             |   6 +
 xen/arch/x86/mm/shadow/hvm.c         |   2 +-
 xen/arch/x86/mm/shadow/multi.c       |   2 +-
 xen/arch/x86/pv/descriptor-tables.c  |  47 ++---
 xen/arch/x86/pv/dom0_build.c         |  12 +-
 xen/arch/x86/pv/domain.c             |  57 ++++--
 xen/arch/x86/pv/mm.c                 |  43 +++-
 xen/arch/x86/setup.c                 |  32 ++-
 xen/arch/x86/smp.c                   |  39 ++++
 xen/arch/x86/smpboot.c               |  26 ++-
 xen/arch/x86/spec_ctrl.c             | 205 ++++++++++++++++++-
 xen/arch/x86/traps.c                 |  25 ++-
 xen/arch/x86/x86_64/mm.c             |   7 +-
 xen/common/smp.c                     |  10 +
 xen/common/stop_machine.c            |  10 +
 xen/include/xen/smp.h                |   8 +
 34 files changed, 1052 insertions(+), 269 deletions(-)

-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 14:30:29 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 14:30:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867318.1278808 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVX4l-0006JU-9n; Wed, 08 Jan 2025 14:30:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867318.1278808; Wed, 08 Jan 2025 14:30:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVX4l-0006JN-5V; Wed, 08 Jan 2025 14:30:27 +0000
Received: by outflank-mailman (input) for mailman id 867318;
 Wed, 08 Jan 2025 14:30:25 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=2h7L=UA=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tVX4j-0005q4-4f
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 14:30:25 +0000
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com
 [2a00:1450:4864:20::62a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 188548c9-cdcd-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 15:30:23 +0100 (CET)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-aab6fa3e20eso2802169566b.2
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 06:30:23 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0e82f616sm2491596166b.41.2025.01.08.06.30.20
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 06:30:20 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 188548c9-cdcd-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736346622; x=1736951422; 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=rIPMScFRi+9eS7pQY1QinUJZuVfM6Y6c4f6yI4NQszg=;
        b=cwUmBYMMH2KdOgmADw6l1twje8VUwkxrJekztKuVk74M0XBrUhq0kuaXIU3IG6mGGF
         g/oaS+4SC6E+de2i+sONEyJiHqI8QPLcsTIgcLMsCPa3xpg4bzX5nLi+1tr/luwTYLxA
         GKStlzPD/1SaB+OZlNasKIGkhEvQvQTM0o3E0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736346622; x=1736951422;
        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=rIPMScFRi+9eS7pQY1QinUJZuVfM6Y6c4f6yI4NQszg=;
        b=aoSjabnSWEND0SUMYQbrguGol1xlyPTjsXnQQ9ro7PpXxmRZy81PJJDO+gelnrvjPC
         b9FnLV3ZoR8OBVkvwgT+q1PTPZmvaquRLTBf/cTZxiaqV2+Ke57/YwzSkUYJN4IgdVL8
         V5rErUYzmns1iRLds16gRTGXgJMeDGoOkcZcxQXTz98Ul55R+weqP4iykorxsFA1Ox3G
         ydeTqrBvBq86aO45u5K+Hei1axocg3qu6yRXyazWpadzkwAigomfALDeujAJX8BAOsIB
         fk00XtpqHLGKdFASmiLbG718INpIY2XWzndcPdApEyZVKnzYTUZHGKlYRUiAF8L44wuF
         J4fA==
X-Gm-Message-State: AOJu0Yx8vDtbr8eqVvcUVLgfLivKmd9QcG4sg6Grq9Grh6ZnTe00F1Tg
	WPQC6Y0Zk34ebyDDe7c2rMkiYR4wgeBWHlO9HggoOkQOo8fsLz46vElWUdSybbA8VhXWspPve9r
	G
X-Gm-Gg: ASbGncudtOzLIGnv2FGaJOLiZuAvrG5RXpxrovIWoYA5GReJPg9xpJ1LMs/KASEfTrC
	fORvJbusFxTqscv8Uu9u3oKYtdTGggKCyZL0R1Lu30k/hmYvVfhrJKtMIsM2pkcRJWJ0/dArMdH
	AI48lI2AQMIzW54EJE+OgYxJ6fflohQg+HAjTo+3ToH7qoe1p5mgVOz4slHf/UmBEsjYcKS7Ro6
	1n15fR65PZfGEU9NEkXILDcIqOwJIklPJmacnglrMBPiGi7hCYigTf4YT7InG6g3w4=
X-Google-Smtp-Source: AGHT+IFHptL442A0fMrP5bxV31r2PKY0Z2nBrnnSNstGJc8woCK9m2xHZd644PLKPTI8mqyRHn3vWA==
X-Received: by 2002:a17:907:368c:b0:aa6:9624:78fd with SMTP id a640c23a62f3a-ab2abc78a71mr296403766b.48.1736346620715;
        Wed, 08 Jan 2025 06:30:20 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: [PATCH v2 01/18] x86/mm: purge unneeded destroy_perdomain_mapping()
Date: Wed,  8 Jan 2025 15:26:41 +0100
Message-ID: <20250108142659.99490-2-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250108142659.99490-1-roger.pau@citrix.com>
References: <20250108142659.99490-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The destroy_perdomain_mapping() call in the hvm_domain_initialise() fail path
is useless.  destroy_perdomain_mapping() called with nr == 0 is effectively a
no op, as there are not entries torn down.  Remove the call, as
arch_domain_create() already calls free_perdomain_mappings() on failure.

There's also a call to destroy_perdomain_mapping() in pv_domain_destroy() which
is also not needed.  arch_domain_destroy() will already unconditionally call
free_perdomain_mappings(), which does the same as destroy_perdomain_mapping(),
plus additionally frees the page table structures.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/arch/x86/hvm/hvm.c   | 1 -
 xen/arch/x86/pv/domain.c | 3 ---
 2 files changed, 4 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 922c9b3af64d..70fdddae583d 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -708,7 +708,6 @@ int hvm_domain_initialise(struct domain *d,
     XFREE(d->arch.hvm.irq);
  fail0:
     hvm_destroy_cacheattr_region_list(d);
-    destroy_perdomain_mapping(d, PERDOMAIN_VIRT_START, 0);
  fail:
     hvm_domain_relinquish_resources(d);
     XFREE(d->arch.hvm.io_handler);
diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
index 7aef628f55be..bc7cd0c62f0e 100644
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -345,9 +345,6 @@ void pv_domain_destroy(struct domain *d)
 {
     pv_l1tf_domain_destroy(d);
 
-    destroy_perdomain_mapping(d, GDT_LDT_VIRT_START,
-                              GDT_LDT_MBYTES << (20 - PAGE_SHIFT));
-
     XFREE(d->arch.pv.cpuidmasks);
 
     FREE_XENHEAP_PAGE(d->arch.pv.gdt_ldt_l1tab);
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 14:30:29 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 14:30:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867317.1278797 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVX4k-00064f-1b; Wed, 08 Jan 2025 14:30:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867317.1278797; Wed, 08 Jan 2025 14:30:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVX4j-00064Y-VK; Wed, 08 Jan 2025 14:30:25 +0000
Received: by outflank-mailman (input) for mailman id 867317;
 Wed, 08 Jan 2025 14:30:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=2h7L=UA=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tVX4i-0005q4-Fv
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 14:30:24 +0000
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com
 [2a00:1450:4864:20::536])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 18164900-cdcd-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 15:30:22 +0100 (CET)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-5d3f65844deso28527767a12.0
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 06:30:22 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d806fedbc5sm26174702a12.60.2025.01.08.06.30.21
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 06:30:21 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 18164900-cdcd-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736346622; x=1736951422; 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=wnNXiTCnO2oI7NIqZptnHGJdzylt9AXPh1CWa13TEiA=;
        b=FC7QP65mjEy1fJdcsJMrafQN8ioREVGHQIv5ax2znGKCGVzECKEq0oJPgw5qoaowod
         I3+NyutkfUuAR+O/lVql8qsC1uPcx340b0MbkrESIqkij9nhfhJNgs+cHgnDokpBxrqI
         KZbQW1ImSZG2PM9t+xD2KousOHAUmxkwu6iZY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736346622; x=1736951422;
        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=wnNXiTCnO2oI7NIqZptnHGJdzylt9AXPh1CWa13TEiA=;
        b=kZugjbZTIKoxzDG4qqvF8vTCz7TIbj+Hh+C6qQwt/GmUGaJa/bSFmHW4lNXhPi5J5I
         /hZbs6iKMFLIRelIz6/ImE91nUDNwzx6A40v0b3b/eOFmSmJwwb2+WX2ZKgYlc2qRCac
         67K6fiu1Jy5Zz5mTC2kURmXtexA6oDEQU3DoOAnnBOQDeqHN2rREhxslxibC0jmNtOWH
         QnnDZLnt7QtdrhjSVkZx0nIWB9T76jD6cuQxxOk8XLx31uBEgmHGtElvbWZN1APAU7Kw
         nXXHCrqFV319uFYvMBUM0oG9ZQ3q9Gb04MHufBUnaOH6YNcLSQqpDGKlXpBw/CDUrqL0
         Brwg==
X-Gm-Message-State: AOJu0YxPsuTh8gmni87I/N0Qvq/kQpJd67dyA168r2u5wjnoSZQopasE
	7szyWyd+p+eA8g9i8xHgCyMSBuMy57Od4tmTNJDkZrm3ipGzQnCIVxRZLmSGGL5XXh5V1ug/wjz
	j
X-Gm-Gg: ASbGnct8giAIyd9MwpbWtFjYy1jaRXbWBr7BRe7UjvWYA7/VI9UpkaQ8XxtpI+DZGWP
	jXWVhNMC5aaVFwAzhuyT2tp1Sv6bG3nmDNkTKTQEnGVdbVGPq9WDm6a3Hvrgu0asm9MC66g6etO
	klY2BXh+XbqA0BumzmyNm8jGxZ52ViG8p1RkV6kYsL+EJbdoiW4eRCis9tHsDuFnkiPOliGcNd/
	JDOmF4FvSepBrzsO0j7E9bJVRdhQLQTjeXcI3DIaj+CEbNb59RZUnjcsN75uQ5iyZ4=
X-Google-Smtp-Source: AGHT+IGa3LmhX/D9qTWm6MbvyZnXvkrTaVWZCrfqraIRjPTXr6wQWOSJ3Tvv9PwmOh1fQtJcwh+aJg==
X-Received: by 2002:a05:6402:26d3:b0:5d9:a59:854a with SMTP id 4fb4d7f45d1cf-5d972e07f98mr2912632a12.13.1736346621921;
        Wed, 08 Jan 2025 06:30:21 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: [PATCH v2 02/18] x86/domain: limit window where curr_vcpu != current on context switch
Date: Wed,  8 Jan 2025 15:26:42 +0100
Message-ID: <20250108142659.99490-3-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250108142659.99490-1-roger.pau@citrix.com>
References: <20250108142659.99490-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On x86 Xen will perform lazy context switches to the idle vCPU, where the
previously running vCPU context is not overwritten, and only current is updated
to point to the idle vCPU.  The state is then disjunct between current and
curr_vcpu: current points to the idle vCPU, while curr_vcpu points to the vCPU
whose context is loaded on the pCPU.

While on that lazy context switched state, certain calls (like
map_domain_page()) will trigger a full synchronization of the pCPU state by
forcing a context switch.  Note however how calling any of such functions
inside the context switch code itself is very likely to trigger an infinite
recursion loop.

Attempt to limit the window where curr_vcpu != current in the context switch
code, as to prevent and infinite recursion loop around sync_local_execstate().

This is required for using map_domain_page() in the vCPU context switch code,
otherwise using map_domain_page() in that context ends up in a recursive
sync_local_execstate() loop:

map_domain_page() -> sync_local_execstate() -> map_domain_page() -> ...

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Changes since v1:
 - New in this version.
---
 xen/arch/x86/domain.c | 58 +++++++++++++++++++++++++++++++++++--------
 xen/arch/x86/traps.c  |  2 --
 2 files changed, 48 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 78a13e6812c9..1f680bf176ee 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1982,16 +1982,16 @@ static void load_default_gdt(unsigned int cpu)
     per_cpu(full_gdt_loaded, cpu) = false;
 }
 
-static void __context_switch(void)
+static void __context_switch(struct vcpu *n)
 {
     struct cpu_user_regs *stack_regs = guest_cpu_user_regs();
     unsigned int          cpu = smp_processor_id();
     struct vcpu          *p = per_cpu(curr_vcpu, cpu);
-    struct vcpu          *n = current;
     struct domain        *pd = p->domain, *nd = n->domain;
 
     ASSERT(p != n);
     ASSERT(!vcpu_cpu_dirty(n));
+    ASSERT(p == current);
 
     if ( !is_idle_domain(pd) )
     {
@@ -2036,6 +2036,18 @@ static void __context_switch(void)
 
     write_ptbase(n);
 
+    /*
+     * It's relevant to set both current and curr_vcpu back-to-back, to avoid a
+     * window where calls to mapcache_current_vcpu() during the context switch
+     * could trigger a recursive loop.
+     *
+     * Do the current switch immediately after switching to the new guest
+     * page-tables, so that current is (almost) always in sync with the
+     * currently loaded page-tables.
+     */
+    set_current(n);
+    per_cpu(curr_vcpu, cpu) = n;
+
 #ifdef CONFIG_PV
     /* Prefetch the VMCB if we expect to use it later in the context switch */
     if ( using_svm() && is_pv_64bit_domain(nd) && !is_idle_domain(nd) )
@@ -2048,8 +2060,6 @@ static void __context_switch(void)
     if ( pd != nd )
         cpumask_clear_cpu(cpu, pd->dirty_cpumask);
     write_atomic(&p->dirty_cpu, VCPU_CPU_CLEAN);
-
-    per_cpu(curr_vcpu, cpu) = n;
 }
 
 void context_switch(struct vcpu *prev, struct vcpu *next)
@@ -2081,16 +2091,36 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
 
     local_irq_disable();
 
-    set_current(next);
-
     if ( (per_cpu(curr_vcpu, cpu) == next) ||
          (is_idle_domain(nextd) && cpu_online(cpu)) )
     {
+        /*
+         * Lazy context switch to the idle vCPU, set current == idle.  Full
+         * context switch happens if/when sync_local_execstate() is called.
+         */
+        set_current(next);
         local_irq_enable();
     }
     else
     {
-        __context_switch();
+        /*
+         * curr_vcpu will always point to the currently loaded vCPU context, as
+         * it's not updated when doing a lazy switch to the idle vCPU.
+         */
+        struct vcpu *prev_ctx = per_cpu(curr_vcpu, cpu);
+
+        if ( prev_ctx != current )
+        {
+            /*
+             * Doing a full context switch to a non-idle vCPU from a lazy
+             * context switched state.  Adjust current to point to the
+             * currently loaded vCPU context.
+             */
+            ASSERT(current == idle_vcpu[cpu]);
+            ASSERT(!is_idle_vcpu(next));
+            set_current(prev_ctx);
+        }
+        __context_switch(next);
 
         /* Re-enable interrupts before restoring state which may fault. */
         local_irq_enable();
@@ -2156,15 +2186,23 @@ int __sync_local_execstate(void)
 {
     unsigned long flags;
     int switch_required;
+    unsigned int cpu = smp_processor_id();
+    struct vcpu *p;
 
     local_irq_save(flags);
 
-    switch_required = (this_cpu(curr_vcpu) != current);
+    p = per_cpu(curr_vcpu, cpu);
+    switch_required = (p != current);
 
     if ( switch_required )
     {
-        ASSERT(current == idle_vcpu[smp_processor_id()]);
-        __context_switch();
+        ASSERT(current == idle_vcpu[cpu]);
+        /*
+         * Restore current to the previously running vCPU, __context_switch()
+         * will update current together with curr_vcpu.
+         */
+        set_current(p);
+        __context_switch(idle_vcpu[cpu]);
     }
 
     local_irq_restore(flags);
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 87b30ce4df2a..487b8c5a78c5 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -2232,8 +2232,6 @@ void __init trap_init(void)
 
 void activate_debugregs(const struct vcpu *curr)
 {
-    ASSERT(curr == current);
-
     write_debugreg(0, curr->arch.dr[0]);
     write_debugreg(1, curr->arch.dr[1]);
     write_debugreg(2, curr->arch.dr[2]);
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 14:30:30 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 14:30:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867320.1278828 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVX4o-0006qq-Qd; Wed, 08 Jan 2025 14:30:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867320.1278828; Wed, 08 Jan 2025 14:30:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVX4o-0006qf-Mt; Wed, 08 Jan 2025 14:30:30 +0000
Received: by outflank-mailman (input) for mailman id 867320;
 Wed, 08 Jan 2025 14:30:29 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=2h7L=UA=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tVX4n-0006o2-I1
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 14:30:29 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1b838d56-cdcd-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 15:30:28 +0100 (CET)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-aa679ad4265so176150466b.0
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 06:30:28 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aaf49604224sm1297411366b.134.2025.01.08.06.30.27
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 06:30:27 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1b838d56-cdcd-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736346628; x=1736951428; 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=atcw5DH/r9KNNaekhki+fCZDVGoHuGfx0DZg9mMghBA=;
        b=IzalejZAaPhsimSMOp2DDazRQziWep2vLQs4zI84lVhFZAnXknZEZrhRWOoTF4AXeE
         JULJq5o3LDM21S1PIwhnIdj7n+ry9tVR1BZIeCD+FnaEh0It0m2uh0HG1ZDJYfxl2ksT
         mBIjLuyP8VJ+DQoUYY07gSPDCMaxCg2sTfjps=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736346628; x=1736951428;
        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=atcw5DH/r9KNNaekhki+fCZDVGoHuGfx0DZg9mMghBA=;
        b=Cm0orTCt1wdW7Gi3rLrS+BlkkFWebNiwJjWqnb8KR8Z7fM+8mrxHE/EnCJFklmF2Z9
         BO/w6DLmQjYFxTkIpJQXZE8yOuBLJL2egxHDy9eBuA47P6BIkS0TZhN9gC5kd8wH/2nZ
         nn6vQiHzR6S0oETCiWtymA2W3gpaUUyFpBor48n8dlrvStXIjB0IpF9JRHJqGjU6haFT
         yKMTzNK7NukV3L8+6cdr4S4Q5SunuhAFcz8glNLdJva3vBxtxvhbmgACrkgdud/s2ZaW
         n1u9h3isq9BlyGunUEorEGXjIL3B3duA3C2IXGuogBpe7NbiVmwAmRzNVSdTvmDh5MZb
         ri6Q==
X-Gm-Message-State: AOJu0YypBa6Y3p3/Vx3PyeLQ+sYTtrVggUmggUmFQoFpCkW/6yNffdsc
	8aECmW+0gczQ8BGRVCnFqnO9xamCz1R7uOiipXbonBxNsauL+qFojL8uXtYj/NsveKrEZUjSAU8
	D
X-Gm-Gg: ASbGncunB0xmCFW5bpdT5+y94sLQkmcIqa6x49kvwtUWMPSp4FUd0USLqgSnaeVn0yo
	CsbVUVWTXbOCgonefl2oAHhgBmItvFmCZUm+xUVdkWMidISNPhROd4QVcObW34w89T1wYqZWDrW
	juk280TFN+0sJ+coyn5hGLfGJHT7v7DqGt+88OKKaXvpbBk7AQt1vN9LVPtGNRiITDwem43dvYi
	q/lSRR6dDUPmSVKFojpeu7EKSWUX+LG4q82gsMI0mcHZpo9WiuuE2omZo5Dk8hJlS4=
X-Google-Smtp-Source: AGHT+IFglshV4EJ4T7uTVluXsmbrkqOUMzkPSprRPmGKZ9SFO4vUkYx5xkPgo7GBLYV4MBEdRo6rkA==
X-Received: by 2002:a17:906:6a26:b0:aa6:743e:d621 with SMTP id a640c23a62f3a-ab29192c380mr591833866b.30.1736346627757;
        Wed, 08 Jan 2025 06:30:27 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: [PATCH v2 06/18] x86/pv: set/clear guest GDT mappings using {populate,destroy}_perdomain_mapping()
Date: Wed,  8 Jan 2025 15:26:46 +0100
Message-ID: <20250108142659.99490-7-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250108142659.99490-1-roger.pau@citrix.com>
References: <20250108142659.99490-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The pv_{set,destroy}_gdt() functions rely on the L1 table(s) that contain such
mappings being stashed in the domain structure, and thus such mappings being
modified by merely updating the L1 entries.

Switch both pv_{set,destroy}_gdt() to instead use
{populate,destory}_perdomain_mapping().

Note that this requires moving the pv_set_gdt() call in arch_set_info_guest()
strictly after update_cr3(), so v->arch.cr3 is valid when
populate_perdomain_mapping() is called.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/arch/x86/domain.c               | 33 ++++++++++++++---------------
 xen/arch/x86/pv/descriptor-tables.c | 28 +++++++++++-------------
 2 files changed, 28 insertions(+), 33 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 0bd0ef7e40f4..0481164f3727 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1376,22 +1376,6 @@ int arch_set_info_guest(
     if ( rc )
         return rc;
 
-    if ( !compat )
-        rc = pv_set_gdt(v, c.nat->gdt_frames, c.nat->gdt_ents);
-#ifdef CONFIG_COMPAT
-    else
-    {
-        unsigned long gdt_frames[ARRAY_SIZE(v->arch.pv.gdt_frames)];
-
-        for ( i = 0; i < nr_gdt_frames; ++i )
-            gdt_frames[i] = c.cmp->gdt_frames[i];
-
-        rc = pv_set_gdt(v, gdt_frames, c.cmp->gdt_ents);
-    }
-#endif
-    if ( rc != 0 )
-        return rc;
-
     set_bit(_VPF_in_reset, &v->pause_flags);
 
 #ifdef CONFIG_COMPAT
@@ -1492,7 +1476,6 @@ int arch_set_info_guest(
     {
         if ( cr3_page )
             put_page(cr3_page);
-        pv_destroy_gdt(v);
         return rc;
     }
 
@@ -1508,6 +1491,22 @@ int arch_set_info_guest(
         paging_update_paging_modes(v);
     else
         update_cr3(v);
+
+    if ( !compat )
+        rc = pv_set_gdt(v, c.nat->gdt_frames, c.nat->gdt_ents);
+#ifdef CONFIG_COMPAT
+    else
+    {
+        unsigned long gdt_frames[ARRAY_SIZE(v->arch.pv.gdt_frames)];
+
+        for ( i = 0; i < nr_gdt_frames; ++i )
+            gdt_frames[i] = c.cmp->gdt_frames[i];
+
+        rc = pv_set_gdt(v, gdt_frames, c.cmp->gdt_ents);
+    }
+#endif
+    if ( rc != 0 )
+        return rc;
 #endif /* CONFIG_PV */
 
  out:
diff --git a/xen/arch/x86/pv/descriptor-tables.c b/xen/arch/x86/pv/descriptor-tables.c
index 02647a2c5047..5a79f022ce13 100644
--- a/xen/arch/x86/pv/descriptor-tables.c
+++ b/xen/arch/x86/pv/descriptor-tables.c
@@ -49,23 +49,20 @@ bool pv_destroy_ldt(struct vcpu *v)
 
 void pv_destroy_gdt(struct vcpu *v)
 {
-    l1_pgentry_t *pl1e = pv_gdt_ptes(v);
-    mfn_t zero_mfn = _mfn(virt_to_mfn(zero_page));
-    l1_pgentry_t zero_l1e = l1e_from_mfn(zero_mfn, __PAGE_HYPERVISOR_RO);
     unsigned int i;
 
     ASSERT(v == current || !vcpu_cpu_dirty(v));
 
-    v->arch.pv.gdt_ents = 0;
-    for ( i = 0; i < FIRST_RESERVED_GDT_PAGE; i++ )
-    {
-        mfn_t mfn = l1e_get_mfn(pl1e[i]);
+    if ( v->arch.cr3 )
+        destroy_perdomain_mapping(v, GDT_VIRT_START(v),
+                                  ARRAY_SIZE(v->arch.pv.gdt_frames));
 
-        if ( (l1e_get_flags(pl1e[i]) & _PAGE_PRESENT) &&
-             !mfn_eq(mfn, zero_mfn) )
-            put_page_and_type(mfn_to_page(mfn));
+    for ( i = 0; i < ARRAY_SIZE(v->arch.pv.gdt_frames); i++)
+    {
+        if ( !v->arch.pv.gdt_frames[i] )
+            break;
 
-        l1e_write(&pl1e[i], zero_l1e);
+        put_page_and_type(mfn_to_page(_mfn(v->arch.pv.gdt_frames[i])));
         v->arch.pv.gdt_frames[i] = 0;
     }
 }
@@ -74,8 +71,8 @@ int pv_set_gdt(struct vcpu *v, const unsigned long frames[],
                unsigned int entries)
 {
     struct domain *d = v->domain;
-    l1_pgentry_t *pl1e;
     unsigned int i, nr_frames = DIV_ROUND_UP(entries, 512);
+    mfn_t mfns[ARRAY_SIZE(v->arch.pv.gdt_frames)];
 
     ASSERT(v == current || !vcpu_cpu_dirty(v));
 
@@ -90,6 +87,8 @@ int pv_set_gdt(struct vcpu *v, const unsigned long frames[],
         if ( !mfn_valid(mfn) ||
              !get_page_and_type(mfn_to_page(mfn), d, PGT_seg_desc_page) )
             goto fail;
+
+        mfns[i] = mfn;
     }
 
     /* Tear down the old GDT. */
@@ -97,12 +96,9 @@ int pv_set_gdt(struct vcpu *v, const unsigned long frames[],
 
     /* Install the new GDT. */
     v->arch.pv.gdt_ents = entries;
-    pl1e = pv_gdt_ptes(v);
     for ( i = 0; i < nr_frames; i++ )
-    {
         v->arch.pv.gdt_frames[i] = frames[i];
-        l1e_write(&pl1e[i], l1e_from_pfn(frames[i], __PAGE_HYPERVISOR_RW));
-    }
+    populate_perdomain_mapping(v, GDT_VIRT_START(v), mfns, nr_frames);
 
     return 0;
 
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 14:30:31 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 14:30:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867321.1278833 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVX4p-0006vB-Ac; Wed, 08 Jan 2025 14:30:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867321.1278833; Wed, 08 Jan 2025 14:30:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVX4p-0006uc-1u; Wed, 08 Jan 2025 14:30:31 +0000
Received: by outflank-mailman (input) for mailman id 867321;
 Wed, 08 Jan 2025 14:30:29 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=2h7L=UA=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tVX4n-0005q4-Rs
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 14:30:29 +0000
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
 [2a00:1450:4864:20::531])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1aa728e9-cdcd-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 15:30:27 +0100 (CET)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-5d982de9547so287385a12.2
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 06:30:27 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d80675a6ddsm25112021a12.3.2025.01.08.06.30.24
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 06:30:24 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1aa728e9-cdcd-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736346626; x=1736951426; 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=m03YXRaYCtzyIlnn1N4iDdGZqjJbMIkKRiM7m/8rx14=;
        b=SKEAwsVHqJSOh0hGbVccs3ejq4OwHvtFfki3mykrulYwh7nS1w/yPYDmu9Uyqlo7IO
         gqCpOgcKIYy8QHMtBEo0u4mbUSzXyAdYOUBnFjA82PtH52lHnjoR4GlWJggehBFeisKm
         WE7/tgyNqvdyF7MNjUXUI1smD9ZarLL1CaJpo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736346626; x=1736951426;
        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=m03YXRaYCtzyIlnn1N4iDdGZqjJbMIkKRiM7m/8rx14=;
        b=eATkH06awYqBoe/UtB831ONsbBFyAHYMg4DhWC1pLTofGTQsbJCRZ2kpjXFn3QTOda
         3m+XTAOogo3p0fId81eJhTyoaC/aHVDqTRvlZFbDCCxfWa7yK0i9bPwhG9RmWBLJP6i2
         6QuCM3rGJp2ZG4BTLQYGvEEE+bwKr8AsRhRDoSgfSZ59kT1CuEZeceexk6FOiA33pSeo
         b6zCu4r6j+7EEf5GLhAFIdMCy4k88n0hUGxYytgr7YhTns5DjrkbspXkfG6qLA0vPrmO
         b1ErRImWytoeI2DXsqNwox/Eexc4WoUvMzR7JSsNSTtDw/PEemVrqKIEZ2DLfT7aQbfM
         NwMQ==
X-Gm-Message-State: AOJu0YwbJCUVT/YBXzduaz9CEIkEYr69OYmOAdBEI540lI2WiQ++Plu7
	+q6cLvmxlPyAocUEGErNCw2+yEnc5ZElSfNKxYp/3fg7AnWqyP9enQ4wDHTYVcbn0PI8nY+2RAJ
	R
X-Gm-Gg: ASbGncvT/slGUT9IwlZ6PC/XGH5++g08P+PbZws0Ok7hulbNESK/I0WloU9zpODzpAc
	JGnuWeNAUBiPWzF2q5qlSuIb4JDAAdfLL0O/sPxO85/Dz4qzB8uZILVCZxlm2pH7K5MMCMWKhOo
	xTR88AlawN9Jhq9TV1J9364AjeJCL0Ln5sDUFSJIq/sI4MCT51BQHN6jnn2w8ksCE6g3Tq3mRRn
	+jFWDhDfDt/3/6qxEBrKqFOCqEuWouZwJ72g7QLF/ouAH9TG36mhy1cHL1OkP+lRh8=
X-Google-Smtp-Source: AGHT+IEohyalVzvnZbfPC5tNJbo0bX+go4X3U0Zx/bW9ziWAaGUnjmDoFWM3cG+OkBfpx4y5duIIHQ==
X-Received: by 2002:a05:6402:3581:b0:5d3:ba42:e9fe with SMTP id 4fb4d7f45d1cf-5d972e04bb3mr2416313a12.12.1736346625293;
        Wed, 08 Jan 2025 06:30:25 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: [PATCH v2 04/18] x86/pv: introduce function to populate perdomain area and use it to map Xen GDT
Date: Wed,  8 Jan 2025 15:26:44 +0100
Message-ID: <20250108142659.99490-5-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250108142659.99490-1-roger.pau@citrix.com>
References: <20250108142659.99490-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The current code to update the Xen part of the GDT when running a PV guest
relies on caching the direct map address of all the L1 tables used to map the
GDT and LDT, so that entries can be modified.

Introduce a new function that populates the per-domain region, either using the
recursive linear mappings when the target vCPU is the current one, or by
directly modifying the L1 table of the per-domain region.

Using such function to populate per-domain addresses drops the need to keep a
reference to per-domain L1 tables previously used to change the per-domain
mappings.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/arch/x86/domain.c                | 11 +++-
 xen/arch/x86/include/asm/desc.h      |  6 +-
 xen/arch/x86/include/asm/mm.h        |  2 +
 xen/arch/x86/include/asm/processor.h |  5 ++
 xen/arch/x86/mm.c                    | 88 ++++++++++++++++++++++++++++
 xen/arch/x86/smpboot.c               |  6 +-
 xen/arch/x86/traps.c                 | 10 ++--
 7 files changed, 113 insertions(+), 15 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 1f680bf176ee..0bd0ef7e40f4 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1953,9 +1953,14 @@ static always_inline bool need_full_gdt(const struct domain *d)
 
 static void update_xen_slot_in_full_gdt(const struct vcpu *v, unsigned int cpu)
 {
-    l1e_write(pv_gdt_ptes(v) + FIRST_RESERVED_GDT_PAGE,
-              !is_pv_32bit_vcpu(v) ? per_cpu(gdt_l1e, cpu)
-                                   : per_cpu(compat_gdt_l1e, cpu));
+    ASSERT(v != current);
+
+    populate_perdomain_mapping(v,
+                               GDT_VIRT_START(v) +
+                               (FIRST_RESERVED_GDT_PAGE << PAGE_SHIFT),
+                               !is_pv_32bit_vcpu(v) ? &per_cpu(gdt_mfn, cpu)
+                                                    : &per_cpu(compat_gdt_mfn,
+                                                               cpu), 1);
 }
 
 static void load_full_gdt(const struct vcpu *v, unsigned int cpu)
diff --git a/xen/arch/x86/include/asm/desc.h b/xen/arch/x86/include/asm/desc.h
index a1e0807d97ed..33981bfca588 100644
--- a/xen/arch/x86/include/asm/desc.h
+++ b/xen/arch/x86/include/asm/desc.h
@@ -44,6 +44,8 @@
 
 #ifndef __ASSEMBLY__
 
+#include <xen/mm-frame.h>
+
 #define GUEST_KERNEL_RPL(d) (is_pv_32bit_domain(d) ? 1 : 3)
 
 /* Fix up the RPL of a guest segment selector. */
@@ -212,10 +214,10 @@ struct __packed desc_ptr {
 
 extern seg_desc_t boot_gdt[];
 DECLARE_PER_CPU(seg_desc_t *, gdt);
-DECLARE_PER_CPU(l1_pgentry_t, gdt_l1e);
+DECLARE_PER_CPU(mfn_t, gdt_mfn);
 extern seg_desc_t boot_compat_gdt[];
 DECLARE_PER_CPU(seg_desc_t *, compat_gdt);
-DECLARE_PER_CPU(l1_pgentry_t, compat_gdt_l1e);
+DECLARE_PER_CPU(mfn_t, compat_gdt_mfn);
 DECLARE_PER_CPU(bool, full_gdt_loaded);
 
 static inline void lgdt(const struct desc_ptr *gdtr)
diff --git a/xen/arch/x86/include/asm/mm.h b/xen/arch/x86/include/asm/mm.h
index 6c7e66ee21ab..b50a51327b2b 100644
--- a/xen/arch/x86/include/asm/mm.h
+++ b/xen/arch/x86/include/asm/mm.h
@@ -603,6 +603,8 @@ int compat_arch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg);
 int create_perdomain_mapping(struct domain *d, unsigned long va,
                              unsigned int nr, l1_pgentry_t **pl1tab,
                              struct page_info **ppg);
+void populate_perdomain_mapping(const struct vcpu *v, unsigned long va,
+                                mfn_t *mfn, unsigned long nr);
 void destroy_perdomain_mapping(struct domain *d, unsigned long va,
                                unsigned int nr);
 void free_perdomain_mappings(struct domain *d);
diff --git a/xen/arch/x86/include/asm/processor.h b/xen/arch/x86/include/asm/processor.h
index d247ef8dd226..82ee89f736c2 100644
--- a/xen/arch/x86/include/asm/processor.h
+++ b/xen/arch/x86/include/asm/processor.h
@@ -243,6 +243,11 @@ static inline unsigned long cr3_pa(unsigned long cr3)
     return cr3 & X86_CR3_ADDR_MASK;
 }
 
+static inline mfn_t cr3_mfn(unsigned long cr3)
+{
+    return maddr_to_mfn(cr3_pa(cr3));
+}
+
 static inline unsigned int cr3_pcid(unsigned long cr3)
 {
     return IS_ENABLED(CONFIG_PV) ? cr3 & X86_CR3_PCID_MASK : 0;
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 3d5dd22b6c36..0abea792486c 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -6423,6 +6423,94 @@ int create_perdomain_mapping(struct domain *d, unsigned long va,
     return rc;
 }
 
+void populate_perdomain_mapping(const struct vcpu *v, unsigned long va,
+                                mfn_t *mfn, unsigned long nr)
+{
+    l1_pgentry_t *l1tab = NULL, *pl1e;
+    const l3_pgentry_t *l3tab;
+    const l2_pgentry_t *l2tab;
+    struct domain *d = v->domain;
+
+    ASSERT(va >= PERDOMAIN_VIRT_START &&
+           va < PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS));
+    ASSERT(!nr || !l3_table_offset(va ^ (va + nr * PAGE_SIZE - 1)));
+
+    /* Use likely to force the optimization for the fast path. */
+    if ( likely(v == current) )
+    {
+        unsigned int i;
+
+        /* Ensure page-tables are from current (if current != curr_vcpu). */
+        sync_local_execstate();
+
+        /* Fast path: get L1 entries using the recursive linear mappings. */
+        pl1e = &__linear_l1_table[l1_linear_offset(va)];
+
+        for ( i = 0; i < nr; i++, pl1e++ )
+        {
+            if ( unlikely(perdomain_l1e_needs_freeing(*pl1e)) )
+            {
+                ASSERT_UNREACHABLE();
+                free_domheap_page(l1e_get_page(*pl1e));
+            }
+            l1e_write(pl1e, l1e_from_mfn(mfn[i], __PAGE_HYPERVISOR_RW));
+        }
+
+        return;
+    }
+
+    ASSERT(d->arch.perdomain_l3_pg);
+    l3tab = __map_domain_page(d->arch.perdomain_l3_pg);
+
+    if ( unlikely(!(l3e_get_flags(l3tab[l3_table_offset(va)]) &
+                    _PAGE_PRESENT)) )
+    {
+        unmap_domain_page(l3tab);
+        gprintk(XENLOG_ERR, "unable to map at VA %lx: L3e not present\n", va);
+        ASSERT_UNREACHABLE();
+        domain_crash(d);
+
+        return;
+    }
+
+    l2tab = map_l2t_from_l3e(l3tab[l3_table_offset(va)]);
+
+    for ( ; nr--; va += PAGE_SIZE, mfn++ )
+    {
+        if ( !l1tab || !l1_table_offset(va) )
+        {
+            const l2_pgentry_t *pl2e = l2tab + l2_table_offset(va);
+
+            if ( unlikely(!(l2e_get_flags(*pl2e) & _PAGE_PRESENT)) )
+            {
+                gprintk(XENLOG_ERR, "unable to map at VA %lx: L2e not present\n",
+                        va);
+                ASSERT_UNREACHABLE();
+                domain_crash(d);
+
+                break;
+            }
+
+            unmap_domain_page(l1tab);
+            l1tab = map_l1t_from_l2e(*pl2e);
+        }
+
+        pl1e = &l1tab[l1_table_offset(va)];
+
+        if ( unlikely(perdomain_l1e_needs_freeing(*pl1e)) )
+        {
+            ASSERT_UNREACHABLE();
+            free_domheap_page(l1e_get_page(*pl1e));
+        }
+
+        l1e_write(pl1e, l1e_from_mfn(*mfn, __PAGE_HYPERVISOR_RW));
+    }
+
+    unmap_domain_page(l1tab);
+    unmap_domain_page(l2tab);
+    unmap_domain_page(l3tab);
+}
+
 void destroy_perdomain_mapping(struct domain *d, unsigned long va,
                                unsigned int nr)
 {
diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 79a79c54c304..a740a6402272 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -1059,8 +1059,7 @@ static int cpu_smpboot_alloc(unsigned int cpu)
     if ( gdt == NULL )
         goto out;
     per_cpu(gdt, cpu) = gdt;
-    per_cpu(gdt_l1e, cpu) =
-        l1e_from_pfn(virt_to_mfn(gdt), __PAGE_HYPERVISOR_RW);
+    per_cpu(gdt_mfn, cpu) = _mfn(virt_to_mfn(gdt));
     memcpy(gdt, boot_gdt, NR_RESERVED_GDT_PAGES * PAGE_SIZE);
     BUILD_BUG_ON(NR_CPUS > 0x10000);
     gdt[PER_CPU_GDT_ENTRY - FIRST_RESERVED_GDT_ENTRY].a = cpu;
@@ -1069,8 +1068,7 @@ static int cpu_smpboot_alloc(unsigned int cpu)
     per_cpu(compat_gdt, cpu) = gdt = alloc_xenheap_pages(0, memflags);
     if ( gdt == NULL )
         goto out;
-    per_cpu(compat_gdt_l1e, cpu) =
-        l1e_from_pfn(virt_to_mfn(gdt), __PAGE_HYPERVISOR_RW);
+    per_cpu(compat_gdt_mfn, cpu) = _mfn(virt_to_mfn(gdt));
     memcpy(gdt, boot_compat_gdt, NR_RESERVED_GDT_PAGES * PAGE_SIZE);
     gdt[PER_CPU_GDT_ENTRY - FIRST_RESERVED_GDT_ENTRY].a = cpu;
 #endif
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 487b8c5a78c5..a7f6fb611c34 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -92,10 +92,10 @@ DEFINE_PER_CPU(uint64_t, efer);
 static DEFINE_PER_CPU(unsigned long, last_extable_addr);
 
 DEFINE_PER_CPU_READ_MOSTLY(seg_desc_t *, gdt);
-DEFINE_PER_CPU_READ_MOSTLY(l1_pgentry_t, gdt_l1e);
+DEFINE_PER_CPU_READ_MOSTLY(mfn_t, gdt_mfn);
 #ifdef CONFIG_PV32
 DEFINE_PER_CPU_READ_MOSTLY(seg_desc_t *, compat_gdt);
-DEFINE_PER_CPU_READ_MOSTLY(l1_pgentry_t, compat_gdt_l1e);
+DEFINE_PER_CPU_READ_MOSTLY(mfn_t, compat_gdt_mfn);
 #endif
 
 /* Master table, used by CPU0. */
@@ -2219,11 +2219,9 @@ void __init trap_init(void)
     init_ler();
 
     /* Cache {,compat_}gdt_l1e now that physically relocation is done. */
-    this_cpu(gdt_l1e) =
-        l1e_from_pfn(virt_to_mfn(boot_gdt), __PAGE_HYPERVISOR_RW);
+    this_cpu(gdt_mfn) = _mfn(virt_to_mfn(boot_gdt));
     if ( IS_ENABLED(CONFIG_PV32) )
-        this_cpu(compat_gdt_l1e) =
-            l1e_from_pfn(virt_to_mfn(boot_compat_gdt), __PAGE_HYPERVISOR_RW);
+        this_cpu(compat_gdt_mfn) = _mfn(virt_to_mfn(boot_compat_gdt));
 
     percpu_traps_init();
 
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 14:30:32 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 14:30:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867322.1278841 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVX4q-00076A-0s; Wed, 08 Jan 2025 14:30:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867322.1278841; Wed, 08 Jan 2025 14:30:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVX4p-00071f-NR; Wed, 08 Jan 2025 14:30:31 +0000
Received: by outflank-mailman (input) for mailman id 867322;
 Wed, 08 Jan 2025 14:30:30 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=2h7L=UA=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tVX4o-0005q4-S4
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 14:30:30 +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 1ad05b41-cdcd-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 15:30:27 +0100 (CET)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-aaee2c5ee6eso2013637466b.1
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 06:30:27 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0f015b53sm2489423166b.163.2025.01.08.06.30.26
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 06:30:26 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1ad05b41-cdcd-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736346627; x=1736951427; 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=R3R5hmlmCEd3MS69pC9DKVq/z/e8dZ+FD++Vyspageo=;
        b=LzA1uq2ALJ7yTUr9qkhSQEj48adVHC/ZkKUJiJ5CMX2s7DKCO7wxpiBrUT2I91dVnh
         2Z1FN0mmcd4W6CPW1Moth8/NDWs84SKa4LNhjhSATuNixUhzOd47vqXziDlbD3oFM1Q7
         YhYDILv2Fx/WAA7SckkBHnEv3MTwfjSTsXB24=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736346627; x=1736951427;
        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=R3R5hmlmCEd3MS69pC9DKVq/z/e8dZ+FD++Vyspageo=;
        b=Lgu30hwA1yhpXMdnCVp+7kY7LlslUZ2ry/2gIYqoaQueyc1wL8RP0d4fsNqvBuTGT7
         ZatO8hmuyTxGXxxosfUSYB99zQVp0E1p8RvOurWV/+D1EaWE8taZC5QHC3WH9BRlGBe0
         oyPg5ep/1pJsXKpVFjI6GFCsXr48KFtFP/BlxAtfPonxi4Cih1rAjvhaJ9pmuJgna5u3
         Bf2RxrumEoEO5nIrhVEdMWFFyJwOYxYicVqNHrLREEk10/yG/+/Z/eQeFsBsqaVWDhOK
         vTHbX33qZOAmbi5zpWekRlqlpo3a0cGxyq5K6Xj0ALmG6kEwsNuY1oS4+sQ8mhTsPS0k
         6OoA==
X-Gm-Message-State: AOJu0YxV0iG9M9uDhAM6NuG2J98uxvLlc5EAob8s6Ey8+9q+oELq2fAr
	DuOKfkPGcv+VOg6fvdLWXfzWvmkdjQE1ULPuI22pKjFAZL9wjPeF1YP6wEFQxs3TLL8RHQy2df/
	r
X-Gm-Gg: ASbGncvq0QsBoCFVG4d17xvA10Na2ggH8ivyRrfhulHQyHWjuF14xpeU/psgjYB2p1t
	/q68Qbo0/6AjfAz2+s+PDKu/RwLV1Y27VwEn9Or3JG5W9333xSbWmhCEdnObZvI/rK3a07+PzRX
	6NJidi5HtPrzC0oTinwjbS/fprsNJsgl3C5cjuG3cGaxrmD/21LwOnHvMraYYZpNQu6+Enuvtcy
	K8WpGXs8YKKlTR0iRWy14WA3AezGfaUHN+SzHTItDtjjxOyHvXc16UVGykWO+9Slow=
X-Google-Smtp-Source: AGHT+IFOHqB2X4YYIijHMhEMuthvZwPSfHYYCzV0yIvDkNOaCTZyCxMx+sLWOIfq27OgFwEuvS3YwQ==
X-Received: by 2002:a17:907:7f08:b0:aab:9430:40e9 with SMTP id a640c23a62f3a-ab2ab70a84emr230283666b.32.1736346626620;
        Wed, 08 Jan 2025 06:30:26 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: [PATCH v2 05/18] x86/mm: switch destroy_perdomain_mapping() parameter from domain to vCPU
Date: Wed,  8 Jan 2025 15:26:45 +0100
Message-ID: <20250108142659.99490-6-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250108142659.99490-1-roger.pau@citrix.com>
References: <20250108142659.99490-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

In preparation for the per-domain area being populated with per-vCPU mappings
change the parameter of destroy_perdomain_mapping() to be a vCPU instead of a
domain, and also update the function logic to allow manipulation of per-domain
mappings using the linear page table mappings.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/arch/x86/include/asm/mm.h |  2 +-
 xen/arch/x86/mm.c             | 24 +++++++++++++++++++++++-
 xen/arch/x86/pv/domain.c      |  3 +--
 xen/arch/x86/x86_64/mm.c      |  2 +-
 4 files changed, 26 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/include/asm/mm.h b/xen/arch/x86/include/asm/mm.h
index b50a51327b2b..65cd751087dc 100644
--- a/xen/arch/x86/include/asm/mm.h
+++ b/xen/arch/x86/include/asm/mm.h
@@ -605,7 +605,7 @@ int create_perdomain_mapping(struct domain *d, unsigned long va,
                              struct page_info **ppg);
 void populate_perdomain_mapping(const struct vcpu *v, unsigned long va,
                                 mfn_t *mfn, unsigned long nr);
-void destroy_perdomain_mapping(struct domain *d, unsigned long va,
+void destroy_perdomain_mapping(const struct vcpu *v, unsigned long va,
                                unsigned int nr);
 void free_perdomain_mappings(struct domain *d);
 
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 0abea792486c..713ae8dd6fa3 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -6511,10 +6511,11 @@ void populate_perdomain_mapping(const struct vcpu *v, unsigned long va,
     unmap_domain_page(l3tab);
 }
 
-void destroy_perdomain_mapping(struct domain *d, unsigned long va,
+void destroy_perdomain_mapping(const struct vcpu *v, unsigned long va,
                                unsigned int nr)
 {
     const l3_pgentry_t *l3tab, *pl3e;
+    const struct domain *d = v->domain;
 
     ASSERT(va >= PERDOMAIN_VIRT_START &&
            va < PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS));
@@ -6523,6 +6524,27 @@ void destroy_perdomain_mapping(struct domain *d, unsigned long va,
     if ( !d->arch.perdomain_l3_pg )
         return;
 
+    /* Use likely to force the optimization for the fast path. */
+    if ( likely(v == current) )
+    {
+        l1_pgentry_t *pl1e;
+
+        /* Ensure page-tables are from current (if current != curr_vcpu). */
+        sync_local_execstate();
+
+        pl1e = &__linear_l1_table[l1_linear_offset(va)];
+
+        /* Fast path: zap L1 entries using the recursive linear mappings. */
+        for ( ; nr--; pl1e++ )
+        {
+            if ( perdomain_l1e_needs_freeing(*pl1e) )
+                free_domheap_page(l1e_get_page(*pl1e));
+            l1e_write(pl1e, l1e_empty());
+        }
+
+        return;
+    }
+
     l3tab = __map_domain_page(d->arch.perdomain_l3_pg);
     pl3e = l3tab + l3_table_offset(va);
 
diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
index bc7cd0c62f0e..7e8bffaae9a0 100644
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -285,8 +285,7 @@ static int pv_create_gdt_ldt_l1tab(struct vcpu *v)
 
 static void pv_destroy_gdt_ldt_l1tab(struct vcpu *v)
 {
-    destroy_perdomain_mapping(v->domain, GDT_VIRT_START(v),
-                              1U << GDT_LDT_VCPU_SHIFT);
+    destroy_perdomain_mapping(v, GDT_VIRT_START(v), 1U << GDT_LDT_VCPU_SHIFT);
 }
 
 void pv_vcpu_destroy(struct vcpu *v)
diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index 389d813ebe63..c08b28d9693b 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -737,7 +737,7 @@ int setup_compat_arg_xlat(struct vcpu *v)
 
 void free_compat_arg_xlat(struct vcpu *v)
 {
-    destroy_perdomain_mapping(v->domain, ARG_XLAT_START(v),
+    destroy_perdomain_mapping(v, ARG_XLAT_START(v),
                               PFN_UP(COMPAT_ARG_XLAT_SIZE));
 }
 
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 14:30:33 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 14:30:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867323.1278856 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVX4r-0007Wq-CS; Wed, 08 Jan 2025 14:30:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867323.1278856; Wed, 08 Jan 2025 14:30:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVX4r-0007VK-3l; Wed, 08 Jan 2025 14:30:33 +0000
Received: by outflank-mailman (input) for mailman id 867323;
 Wed, 08 Jan 2025 14:30:32 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=2h7L=UA=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tVX4p-0005q4-S4
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 14:30:31 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1c7f0dc5-cdcd-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 15:30:30 +0100 (CET)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-aa6c0d1833eso3513387966b.1
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 06:30:30 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0e5029f8sm2482634666b.0.2025.01.08.06.30.28
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 06:30:28 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1c7f0dc5-cdcd-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736346629; x=1736951429; 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=a/WczJNf+EXdjpOAIA1z4tpLjcOOHU7wqiQHBrWlxLM=;
        b=b8otjL9TKGUYeRmsnAQd5u3W+9BRpyFEUqLa9m1hc/9nH51zmmEUhoGoQ37KDePh1u
         ssplNPUJToEgOwtnOXLA/U7CIrnkMUniYXeldA5bjUOpX57Blr7SyMr1ZbEmzqDgh9dF
         QzJDLuJG04WR+/Ug1sxZ3kKvwt3LNg+yPkpyo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736346629; x=1736951429;
        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=a/WczJNf+EXdjpOAIA1z4tpLjcOOHU7wqiQHBrWlxLM=;
        b=mo6M14iTz/4QmGxGKcha6t7d60s51QV18Un1A23vA0pV4Me+cqvnEVlVEPhZoO9Npk
         MlVxxvt2TE5YgA+BqLT7WtCTpyK3q9LhkrPIerety55qxA3Cd83gIllsSO6XuP4eN8za
         TWTgUOtv2ADAzvdCIHhR9jEFi82a+2LwaqwIvSMYZF6JuSNSvOnlaDpLFAhU0rcV1EMt
         8FrfMkxytoB+FTatnCvwy4PG4ptWpVxQeuqKdHzBcPPWNTHWZPomqogoxdReGEuxiEGo
         Sg57AuSHZgkr3WFJys4Ye9R0Il91gfVWAhOqwGDPSHkWzCcvrt5hkrDJLQEkW9caAkUx
         yjTQ==
X-Gm-Message-State: AOJu0Ywd2+CRs5GGxJd8KO0AM+msGvvOiWYU+4jaMYSY/lTr45WDdS8d
	FgMJBsutpZ0MocJ3uvfAJXyWaOUH084dE2VIfXO1TyunoHnQ81gEXhIhmROqNicuJ6t09NgOTHP
	d
X-Gm-Gg: ASbGncuD1xyLM6VS6wXzQgXhKsYx0n8otpxn5Ne1xZeDN/t1GSHnV/ZWXmwqLXyteUI
	26OwVJ9913ss7Gf4aohC1NjYtBLR7Gt/c+EZ+3kHg1NZW2IWH3r6UamkWCLqLlHnpXoqXSGT7vf
	OpIlLDxySJ3Kt4+ji3eP/+NsPsWViBJSxsyAGsOTahPkzyqNG1z5/+/LQqOV57Lip4tiMfRGLQp
	McX5hw5injCGRXMHtqPNAMnRAyu7sqkVdU0HNwI74/q5jGzvbNFNboBO17bdTd8UQc=
X-Google-Smtp-Source: AGHT+IGIvn0q5at3p77p8XfXsyt0e4XfVPi2p4jLiXnmckHaXVyXuT6UUXjW15nwisukNHSfjVnvrA==
X-Received: by 2002:a17:906:478f:b0:aab:dc3e:1c84 with SMTP id a640c23a62f3a-ab2ab703f93mr311889766b.17.1736346629032;
        Wed, 08 Jan 2025 06:30:29 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: [PATCH v2 07/18] x86/pv: update guest LDT mappings using the linear entries
Date: Wed,  8 Jan 2025 15:26:47 +0100
Message-ID: <20250108142659.99490-8-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250108142659.99490-1-roger.pau@citrix.com>
References: <20250108142659.99490-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The pv_map_ldt_shadow_page() and pv_destroy_ldt() functions rely on the L1
table(s) that contain such mappings being stashed in the domain structure, and
thus such mappings being modified by merely updating the require L1 entries.

Switch pv_map_ldt_shadow_page() to unconditionally use the linear recursive, as
that logic is always called while the vCPU is running on the current pCPU.

For pv_destroy_ldt() use the linear mappings if the vCPU is the one currently
running on the pCPU, otherwise use destroy_mappings().

Note this requires keeping an array with the pages currently mapped at the LDT
area, as that allows dropping the extra taken page reference when removing the
mappings.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/arch/x86/include/asm/domain.h   |  2 ++
 xen/arch/x86/pv/descriptor-tables.c | 19 ++++++++++---------
 xen/arch/x86/pv/domain.c            |  4 ++++
 xen/arch/x86/pv/mm.c                |  3 ++-
 4 files changed, 18 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h
index b79d6badd71c..b659cffc7f81 100644
--- a/xen/arch/x86/include/asm/domain.h
+++ b/xen/arch/x86/include/asm/domain.h
@@ -523,6 +523,8 @@ struct pv_vcpu
     struct trap_info *trap_ctxt;
 
     unsigned long gdt_frames[FIRST_RESERVED_GDT_PAGE];
+    /* Max LDT entries is 8192, so 8192 * 8 = 64KiB (16 pages). */
+    mfn_t ldt_frames[16];
     unsigned long ldt_base;
     unsigned int gdt_ents, ldt_ents;
 
diff --git a/xen/arch/x86/pv/descriptor-tables.c b/xen/arch/x86/pv/descriptor-tables.c
index 5a79f022ce13..95b598a4c0cf 100644
--- a/xen/arch/x86/pv/descriptor-tables.c
+++ b/xen/arch/x86/pv/descriptor-tables.c
@@ -20,28 +20,29 @@
  */
 bool pv_destroy_ldt(struct vcpu *v)
 {
-    l1_pgentry_t *pl1e;
+    const unsigned int nr_frames = ARRAY_SIZE(v->arch.pv.ldt_frames);
     unsigned int i, mappings_dropped = 0;
-    struct page_info *page;
 
     ASSERT(!in_irq());
 
     ASSERT(v == current || !vcpu_cpu_dirty(v));
 
-    pl1e = pv_ldt_ptes(v);
+    destroy_perdomain_mapping(v, LDT_VIRT_START(v), nr_frames);
 
-    for ( i = 0; i < 16; i++ )
+    for ( i = 0; i < nr_frames; i++ )
     {
-        if ( !(l1e_get_flags(pl1e[i]) & _PAGE_PRESENT) )
-            continue;
+        mfn_t mfn = v->arch.pv.ldt_frames[i];
+        struct page_info *page;
 
-        page = l1e_get_page(pl1e[i]);
-        l1e_write(&pl1e[i], l1e_empty());
-        mappings_dropped++;
+        if ( mfn_eq(mfn, INVALID_MFN) )
+            continue;
 
+        v->arch.pv.ldt_frames[i] = INVALID_MFN;
+        page = mfn_to_page(mfn);
         ASSERT_PAGE_IS_TYPE(page, PGT_seg_desc_page);
         ASSERT_PAGE_IS_DOMAIN(page, v->domain);
         put_page_and_type(page);
+        mappings_dropped++;
     }
 
     return mappings_dropped;
diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
index 7e8bffaae9a0..32d7488cc186 100644
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -303,6 +303,7 @@ void pv_vcpu_destroy(struct vcpu *v)
 int pv_vcpu_initialise(struct vcpu *v)
 {
     struct domain *d = v->domain;
+    unsigned int i;
     int rc;
 
     ASSERT(!is_idle_domain(d));
@@ -311,6 +312,9 @@ int pv_vcpu_initialise(struct vcpu *v)
     if ( rc )
         return rc;
 
+    for ( i = 0; i < ARRAY_SIZE(v->arch.pv.ldt_frames); i++ )
+        v->arch.pv.ldt_frames[i] = INVALID_MFN;
+
     BUILD_BUG_ON(X86_NR_VECTORS * sizeof(*v->arch.pv.trap_ctxt) >
                  PAGE_SIZE);
     v->arch.pv.trap_ctxt = xzalloc_array(struct trap_info, X86_NR_VECTORS);
diff --git a/xen/arch/x86/pv/mm.c b/xen/arch/x86/pv/mm.c
index 187f5f6a3e8c..4853e619f2a7 100644
--- a/xen/arch/x86/pv/mm.c
+++ b/xen/arch/x86/pv/mm.c
@@ -86,7 +86,8 @@ bool pv_map_ldt_shadow_page(unsigned int offset)
         return false;
     }
 
-    pl1e = &pv_ldt_ptes(curr)[offset >> PAGE_SHIFT];
+    curr->arch.pv.ldt_frames[offset >> PAGE_SHIFT] = page_to_mfn(page);
+    pl1e = &__linear_l1_table[l1_linear_offset(LDT_VIRT_START(curr) + offset)];
     l1e_add_flags(gl1e, _PAGE_RW);
 
     l1e_write(pl1e, gl1e);
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 14:30:34 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 14:30:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867324.1278866 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVX4s-0007s0-NH; Wed, 08 Jan 2025 14:30:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867324.1278866; Wed, 08 Jan 2025 14:30:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVX4s-0007rG-GJ; Wed, 08 Jan 2025 14:30:34 +0000
Received: by outflank-mailman (input) for mailman id 867324;
 Wed, 08 Jan 2025 14:30:32 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=2h7L=UA=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tVX4q-0005q4-SP
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 14:30:32 +0000
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
 [2a00:1450:4864:20::52e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1cfeb909-cdcd-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 15:30:31 +0100 (CET)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-5d437235769so10185155a12.2
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 06:30:31 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d806feddfasm26366981a12.58.2025.01.08.06.30.29
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 06:30:29 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1cfeb909-cdcd-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736346630; x=1736951430; 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=C1M0fEQUOjxJ5DtJ3QRFhSAxh9S66gkWBgHELsH7AbA=;
        b=rltRehCiWHTj7fk1+hRO1zLX1JiY/qW7vG185hut9pgvKFMlfV2E9Ukxwf074hdyXk
         572LhtnTuKSNlEtuW+rYiPVY8Qs7B16e0k8acj6aRISdWl8SdC8hF1pnX5c7CvoDr9gQ
         /aix5kQsus3uKhJr2FJ8ICVdayQ4ZqOu9kbn4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736346630; x=1736951430;
        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=C1M0fEQUOjxJ5DtJ3QRFhSAxh9S66gkWBgHELsH7AbA=;
        b=ASeYnoMsE+6efMSEe2QwwW6XHHRncrg5gL6ih1r/nMDV/H9iqnIVZtVMdpRRGJMXf3
         8z7mzWCQwPG8HzlRr0sPYRumJ67O6p+oVC1FsF/OiiTFVIqp65opXHO59Ff8oXvesuUt
         XqXdWPDS+j18XrHRCHQqyxhHG3hBgGyyjctHrpcDIF129B9TkZzg8l2PduxqcrnDH+EB
         T4M1Mr/ui67CeswJZqvNummB0vje2NvADqIZ9U7tkdxNgLk6OJ+zj0WfWmd4rwkuHuQ0
         R7FUckqKemCEs2RAZ8ebPpLH/g6y5I/ANA/3cwhjANCZjlgpIbaZ1a4cUOppVma7mgwR
         R+kg==
X-Gm-Message-State: AOJu0YzK4O7JUkBh71NZ+htkVmfzZXRUiRKKUvzGFO9ePZU1IPgykZiK
	cOmhRfcxRkol9Lokx248PwnioJidORO86XS5aEYEc6WDALwYDO5NhPb2NVszagCsNdJWLpT8ZzN
	E
X-Gm-Gg: ASbGnctLHfUPHwbekW/JezOBQtvMdFIRPS6/boD4VZdA44EdN+VLYfZY6FahRla5865
	ZBUJsfabGBdyTKetW+/Kyya8HFUh3D7TpW03LKD22hN0my0QGNL2Ea5C97ZM9HWqUuf59f/UOM9
	GFLEmBP6v9+OY2o4zH+Og7dHBglbaWlNPXIgj9atWcH0SWw8kDUEBsPGhXhzx2xmG0VGfjuezGk
	49NwgJTzvAv4dL0SRdQJIhKpvPs2/TBIIw45pLPFzXfcRf2i6vHkUoNVhA0AkE77c8=
X-Google-Smtp-Source: AGHT+IHbq/O2WwIQm3RW5r/fjZ4FHbgGEBEEu5HVGEwWYvh51/BUDNPNr9U76gO8g2/4SPxrqkwRSg==
X-Received: by 2002:a05:6402:540e:b0:5d0:b51c:8478 with SMTP id 4fb4d7f45d1cf-5d972e0e274mr2506264a12.12.1736346630352;
        Wed, 08 Jan 2025 06:30:30 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: [PATCH v2 08/18] x86/pv: remove stashing of GDT/LDT L1 page-tables
Date: Wed,  8 Jan 2025 15:26:48 +0100
Message-ID: <20250108142659.99490-9-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250108142659.99490-1-roger.pau@citrix.com>
References: <20250108142659.99490-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

There are no remaining callers of pv_gdt_ptes() or pv_ldt_ptes() that use the
stashed L1 page-tables in the domain structure.  As such, the helpers and the
fields can now be removed.

No functional change intended, as the removed logic is not used.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/arch/x86/include/asm/domain.h |  9 ---------
 xen/arch/x86/pv/domain.c          | 10 +---------
 2 files changed, 1 insertion(+), 18 deletions(-)

diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h
index b659cffc7f81..fbe59baa82ec 100644
--- a/xen/arch/x86/include/asm/domain.h
+++ b/xen/arch/x86/include/asm/domain.h
@@ -271,8 +271,6 @@ struct time_scale {
 
 struct pv_domain
 {
-    l1_pgentry_t **gdt_ldt_l1tab;
-
     atomic_t nr_l4_pages;
 
     /* Is a 32-bit PV guest? */
@@ -506,13 +504,6 @@ struct arch_domain
 #define has_pirq(d)        (!!((d)->arch.emulation_flags & X86_EMU_USE_PIRQ))
 #define has_vpci(d)        (!!((d)->arch.emulation_flags & X86_EMU_VPCI))
 
-#define gdt_ldt_pt_idx(v) \
-      ((v)->vcpu_id >> (PAGETABLE_ORDER - GDT_LDT_VCPU_SHIFT))
-#define pv_gdt_ptes(v) \
-    ((v)->domain->arch.pv.gdt_ldt_l1tab[gdt_ldt_pt_idx(v)] + \
-     (((v)->vcpu_id << GDT_LDT_VCPU_SHIFT) & (L1_PAGETABLE_ENTRIES - 1)))
-#define pv_ldt_ptes(v) (pv_gdt_ptes(v) + 16)
-
 struct pv_vcpu
 {
     /* map_domain_page() mapping cache. */
diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
index 32d7488cc186..dfaeeb2e2cc2 100644
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -279,7 +279,7 @@ static int pv_create_gdt_ldt_l1tab(struct vcpu *v)
 {
     return create_perdomain_mapping(v->domain, GDT_VIRT_START(v),
                                     1U << GDT_LDT_VCPU_SHIFT,
-                                    v->domain->arch.pv.gdt_ldt_l1tab,
+                                    NIL(l1_pgentry_t *),
                                     NULL);
 }
 
@@ -349,8 +349,6 @@ void pv_domain_destroy(struct domain *d)
     pv_l1tf_domain_destroy(d);
 
     XFREE(d->arch.pv.cpuidmasks);
-
-    FREE_XENHEAP_PAGE(d->arch.pv.gdt_ldt_l1tab);
 }
 
 void noreturn cf_check continue_pv_domain(void);
@@ -366,12 +364,6 @@ int pv_domain_initialise(struct domain *d)
 
     pv_l1tf_domain_init(d);
 
-    d->arch.pv.gdt_ldt_l1tab =
-        alloc_xenheap_pages(0, MEMF_node(domain_to_node(d)));
-    if ( !d->arch.pv.gdt_ldt_l1tab )
-        goto fail;
-    clear_page(d->arch.pv.gdt_ldt_l1tab);
-
     if ( levelling_caps & ~LCAP_faulting &&
          (d->arch.pv.cpuidmasks = xmemdup(&cpuidmask_defaults)) == NULL )
         goto fail;
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 14:30:36 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 14:30:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867327.1278877 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVX4u-0008Hz-Ir; Wed, 08 Jan 2025 14:30:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867327.1278877; Wed, 08 Jan 2025 14:30:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVX4u-0008G5-Ao; Wed, 08 Jan 2025 14:30:36 +0000
Received: by outflank-mailman (input) for mailman id 867327;
 Wed, 08 Jan 2025 14:30: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
 <SRS0=2h7L=UA=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tVX4s-0006o2-K7
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 14:30:34 +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 1e9c9886-cdcd-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 15:30:33 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-aa68b513abcso3092335666b.0
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 06:30:33 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0efe4971sm2525510466b.107.2025.01.08.06.30.32
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 06:30:32 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1e9c9886-cdcd-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736346633; x=1736951433; 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=+jBVxxfhyjQo3CPYAi6vNYnRQLQEERzPDDK3eitXPfE=;
        b=f7MNmPUBzZU/65+N/0U9PUwAj6mHPSvT7fY1NT7mXcJREbhr+2o8Hirf8bQy/jNVsy
         sX2uUwKHTlVxa4ZVFiomxEhSSPPCGJ9b3W6zDGz20/ncpvrNhJOp+YDQU28mFFm3mITW
         uPkOuh6TQiYecfmYJcZTgJT7Xm160pFQ9noCc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736346633; x=1736951433;
        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=+jBVxxfhyjQo3CPYAi6vNYnRQLQEERzPDDK3eitXPfE=;
        b=qM+fPcdop30knuBJLRfGM+M6H+bG+2pZP7TVjFS3LG4mPDPFS/x2i9soEFB6RPc2Ya
         Tfp8TqySoAwLWcdt57AC9ppvpcyl8HxpW1gsgEwDI3+qIur0TBAxAxn4LBm7kXU7O974
         htVEOPDnJpNYRdzwWNwkDgr8u4Ep5iM+iTLF8yDLmR1HwNGFvgKv9tbms4AFYMlwfYXi
         DYOO1mUTLKqBxEH1PWsD9Ey6gtO1eR9b2Gg0384/unIZxA9a2dSp7xKbhNAE1T5jmb0e
         Bo1bTMx3ZryBzY29AMiCEDytz4/02S9bhrTAVZDdPZpriemGTjCoyO5DoG82JtH1f997
         Qd7Q==
X-Gm-Message-State: AOJu0YyH05pJzNjdzsHFQkzLDyazSsEbvR1fzGx64LvHE4i01cPi6rRC
	FmYSP5ILgm17VBSKwJKiZ0QCQOYd6BJs7PoYFdXG1gFnt4Ks0ZIvcmT7R04tPGrrE8fHV+L6CUf
	O
X-Gm-Gg: ASbGnctnRCb1E30t2r/QFaA3xY35w1+oIaRN/GHRFTtORyBLhdb9C3AdFEVZ7HlwG8L
	42LO3Y0KECxVbtpLHc6e3/yGAXckk3GMRebW1YQwyjmbGjW9Yxaq+ZY12ghE1G0DgnX910hwvFZ
	W9PI0nIErInk7XsF5UDi888oFR++rbT6hkANx4+t2UI/IoYqqneB01RCzfOjTdufDMH4MNO8ACp
	pQ2Z8eJHPcxtODHTJJrOkSbshb6s35zYK7WW14579lxWiVXTr4y1mCZY98U7YvxyRk=
X-Google-Smtp-Source: AGHT+IEprDOxP9xe+A8TyhkOIHhL+eL4gFw3vAZc1g+A9Cc6FCNI9TzjKmB6a6JD0IbDmktTNWtZeg==
X-Received: by 2002:a17:907:3f95:b0:aae:b259:ef6c with SMTP id a640c23a62f3a-ab2aacfbb7cmr303604566b.0.1736346632906;
        Wed, 08 Jan 2025 06:30:32 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: [PATCH v2 10/18] x86/mm: switch {create,destroy}_perdomain_mapping() domain parameter to vCPU
Date: Wed,  8 Jan 2025 15:26:50 +0100
Message-ID: <20250108142659.99490-11-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250108142659.99490-1-roger.pau@citrix.com>
References: <20250108142659.99490-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

In preparation for the per-domain area being per-vCPU.  This requires moving
some of the {create,destroy}_perdomain_mapping() calls to the domain
initialization and tear down paths into vCPU initialization and tear down.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/arch/x86/domain.c             | 12 ++++++++----
 xen/arch/x86/domain_page.c        | 13 +++++--------
 xen/arch/x86/hvm/hvm.c            |  5 -----
 xen/arch/x86/include/asm/domain.h |  2 +-
 xen/arch/x86/include/asm/mm.h     |  4 ++--
 xen/arch/x86/mm.c                 |  6 ++++--
 xen/arch/x86/pv/domain.c          |  2 +-
 xen/arch/x86/x86_64/mm.c          |  2 +-
 8 files changed, 22 insertions(+), 24 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 0481164f3727..6e1f622f7385 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -559,6 +559,10 @@ int arch_vcpu_create(struct vcpu *v)
 
     v->arch.flags = TF_kernel_mode;
 
+    rc = create_perdomain_mapping(v, PERDOMAIN_VIRT_START, 0, false);
+    if ( rc )
+        return rc;
+
     rc = mapcache_vcpu_init(v);
     if ( rc )
         return rc;
@@ -607,6 +611,7 @@ int arch_vcpu_create(struct vcpu *v)
     return rc;
 
  fail:
+    free_perdomain_mappings(v);
     paging_vcpu_teardown(v);
     vcpu_destroy_fpu(v);
     xfree(v->arch.msrs);
@@ -629,6 +634,8 @@ void arch_vcpu_destroy(struct vcpu *v)
         hvm_vcpu_destroy(v);
     else
         pv_vcpu_destroy(v);
+
+    free_perdomain_mappings(v);
 }
 
 int arch_sanitise_domain_config(struct xen_domctl_createdomain *config)
@@ -870,8 +877,7 @@ int arch_domain_create(struct domain *d,
     }
     else if ( is_pv_domain(d) )
     {
-        if ( (rc = mapcache_domain_init(d)) != 0 )
-            goto fail;
+        mapcache_domain_init(d);
 
         if ( (rc = pv_domain_initialise(d)) != 0 )
             goto fail;
@@ -909,7 +915,6 @@ int arch_domain_create(struct domain *d,
     XFREE(d->arch.cpu_policy);
     if ( paging_initialised )
         paging_final_teardown(d);
-    free_perdomain_mappings(d);
 
     return rc;
 }
@@ -935,7 +940,6 @@ void arch_domain_destroy(struct domain *d)
 
     if ( is_pv_domain(d) )
         pv_domain_destroy(d);
-    free_perdomain_mappings(d);
 
     free_xenheap_page(d->shared_info);
     cleanup_domain_irq_mapping(d);
diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c
index ad6d86be6918..1372be20224e 100644
--- a/xen/arch/x86/domain_page.c
+++ b/xen/arch/x86/domain_page.c
@@ -231,7 +231,7 @@ void unmap_domain_page(const void *ptr)
     local_irq_restore(flags);
 }
 
-int mapcache_domain_init(struct domain *d)
+void mapcache_domain_init(struct domain *d)
 {
     struct mapcache_domain *dcache = &d->arch.pv.mapcache;
     unsigned int bitmap_pages;
@@ -240,7 +240,7 @@ int mapcache_domain_init(struct domain *d)
 
 #ifdef NDEBUG
     if ( !mem_hotplug && max_page <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) )
-        return 0;
+        return;
 #endif
 
     BUILD_BUG_ON(MAPCACHE_VIRT_END + PAGE_SIZE * (3 +
@@ -252,9 +252,6 @@ int mapcache_domain_init(struct domain *d)
                       (bitmap_pages + 1) * PAGE_SIZE / sizeof(long);
 
     spin_lock_init(&dcache->lock);
-
-    return create_perdomain_mapping(d, (unsigned long)dcache->inuse,
-                                    2 * bitmap_pages + 1, false);
 }
 
 int mapcache_vcpu_init(struct vcpu *v)
@@ -271,14 +268,14 @@ int mapcache_vcpu_init(struct vcpu *v)
     if ( ents > dcache->entries )
     {
         /* Populate page tables. */
-        int rc = create_perdomain_mapping(d, MAPCACHE_VIRT_START, ents, false);
+        int rc = create_perdomain_mapping(v, MAPCACHE_VIRT_START, ents, false);
 
         /* Populate bit maps. */
         if ( !rc )
-            rc = create_perdomain_mapping(d, (unsigned long)dcache->inuse,
+            rc = create_perdomain_mapping(v, (unsigned long)dcache->inuse,
                                           nr, true);
         if ( !rc )
-            rc = create_perdomain_mapping(d, (unsigned long)dcache->garbage,
+            rc = create_perdomain_mapping(v, (unsigned long)dcache->garbage,
                                           nr, true);
 
         if ( rc )
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index e7817144059e..0dc693818349 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -601,10 +601,6 @@ int hvm_domain_initialise(struct domain *d,
     INIT_LIST_HEAD(&d->arch.hvm.mmcfg_regions);
     INIT_LIST_HEAD(&d->arch.hvm.msix_tables);
 
-    rc = create_perdomain_mapping(d, PERDOMAIN_VIRT_START, 0, false);
-    if ( rc )
-        goto fail;
-
     hvm_init_cacheattr_region_list(d);
 
     rc = paging_enable(d, PG_refcounts|PG_translate|PG_external);
@@ -708,7 +704,6 @@ int hvm_domain_initialise(struct domain *d,
     XFREE(d->arch.hvm.irq);
  fail0:
     hvm_destroy_cacheattr_region_list(d);
- fail:
     hvm_domain_relinquish_resources(d);
     XFREE(d->arch.hvm.io_handler);
     XFREE(d->arch.hvm.pl_time);
diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h
index fbe59baa82ec..7c143d2a6c46 100644
--- a/xen/arch/x86/include/asm/domain.h
+++ b/xen/arch/x86/include/asm/domain.h
@@ -73,7 +73,7 @@ struct mapcache_domain {
     unsigned long *garbage;
 };
 
-int mapcache_domain_init(struct domain *d);
+void mapcache_domain_init(struct domain *d);
 int mapcache_vcpu_init(struct vcpu *v);
 void mapcache_override_current(struct vcpu *v);
 
diff --git a/xen/arch/x86/include/asm/mm.h b/xen/arch/x86/include/asm/mm.h
index 0c57442c9593..f501e5e115ff 100644
--- a/xen/arch/x86/include/asm/mm.h
+++ b/xen/arch/x86/include/asm/mm.h
@@ -600,13 +600,13 @@ int compat_arch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg);
 #define NIL(type) ((type *)-sizeof(type))
 #define IS_NIL(ptr) (!((uintptr_t)(ptr) + sizeof(*(ptr))))
 
-int create_perdomain_mapping(struct domain *d, unsigned long va,
+int create_perdomain_mapping(struct vcpu *v, unsigned long va,
                              unsigned int nr, bool populate);
 void populate_perdomain_mapping(const struct vcpu *v, unsigned long va,
                                 mfn_t *mfn, unsigned long nr);
 void destroy_perdomain_mapping(const struct vcpu *v, unsigned long va,
                                unsigned int nr);
-void free_perdomain_mappings(struct domain *d);
+void free_perdomain_mappings(struct vcpu *v);
 
 void __iomem *ioremap_wc(paddr_t pa, size_t len);
 
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 45664c56cb8f..c321f5723b04 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -6300,9 +6300,10 @@ static bool perdomain_l1e_needs_freeing(l1_pgentry_t l1e)
            (_PAGE_PRESENT | _PAGE_AVAIL0);
 }
 
-int create_perdomain_mapping(struct domain *d, unsigned long va,
+int create_perdomain_mapping(struct vcpu *v, unsigned long va,
                              unsigned int nr, bool populate)
 {
+    struct domain *d = v->domain;
     struct page_info *pg;
     l3_pgentry_t *l3tab;
     l2_pgentry_t *l2tab;
@@ -6560,8 +6561,9 @@ void destroy_perdomain_mapping(const struct vcpu *v, unsigned long va,
     unmap_domain_page(l3tab);
 }
 
-void free_perdomain_mappings(struct domain *d)
+void free_perdomain_mappings(struct vcpu *v)
 {
+    struct domain *d = v->domain;
     l3_pgentry_t *l3tab;
     unsigned int i;
 
diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
index ca32e7b5d686..534d2899100f 100644
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -277,7 +277,7 @@ int switch_compat(struct domain *d)
 
 static int pv_create_gdt_ldt_l1tab(struct vcpu *v)
 {
-    return create_perdomain_mapping(v->domain, GDT_VIRT_START(v),
+    return create_perdomain_mapping(v, GDT_VIRT_START(v),
                                     1U << GDT_LDT_VCPU_SHIFT, false);
 }
 
diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index 55bba7e473ae..3b421d218e0b 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -730,7 +730,7 @@ void __init zap_low_mappings(void)
 
 int setup_compat_arg_xlat(struct vcpu *v)
 {
-    return create_perdomain_mapping(v->domain, ARG_XLAT_START(v),
+    return create_perdomain_mapping(v, ARG_XLAT_START(v),
                                     PFN_UP(COMPAT_ARG_XLAT_SIZE), true);
 }
 
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 14:30:37 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 14:30:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867328.1278882 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVX4v-0008LQ-48; Wed, 08 Jan 2025 14:30:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867328.1278882; Wed, 08 Jan 2025 14:30:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVX4u-0008Kf-O1; Wed, 08 Jan 2025 14:30:36 +0000
Received: by outflank-mailman (input) for mailman id 867328;
 Wed, 08 Jan 2025 14:30:35 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=2h7L=UA=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tVX4s-0005q4-T5
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 14:30:34 +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 1dd1f9b7-cdcd-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 15:30:32 +0100 (CET)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-5d3f57582a2so1798129a12.1
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 06:30:32 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d80675a41esm25260184a12.1.2025.01.08.06.30.30
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 06:30:31 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1dd1f9b7-cdcd-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736346632; x=1736951432; 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=2+w+3NcnUX3Zar0o1eFpwbIWoYl9kfXdM+GmtfECN9Y=;
        b=CJYTOJ7dPqv6H2INxyBAkJI5a3fJ8NY8bA4xtzPGSutHwoJ+82fDuFy2vOCnwSBQ21
         RTtIzbVOn27RNP/hFaDqiHossDLzLHmtoP8C0H9809fV3mdFaIACusaZ/CRBowqraW0e
         PGoqVoD2QT4wMsgJOZPJz75pfnV3aFZOiBh9o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736346632; x=1736951432;
        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=2+w+3NcnUX3Zar0o1eFpwbIWoYl9kfXdM+GmtfECN9Y=;
        b=q6SzKZJ5PRJ8D1wFcT8OASbW5DLKj588PhpIYMNBMJzTgnJl8dHT3X9V95KGxYpIfJ
         Soyeqw/PtSjv1c9i4ef43uzcXjm7gcTnZ6CdAwXXw6QrrwVlk6wizc5LnMUtkd34wreC
         3FO/UstkZKsfqv/SNgiNZXcslNpWMJvXiZS6bFVQ8kQe3NVzkYTs0edN1EU+egjEwTFd
         obqyKlho9PDGACCPQkxpY1srzChwGf09LPjPvcidYeYrq8dq8/G10b92jDprMqPlH9Ej
         W9J6yOsRnej/v5lKoVenfm0t0XMw5l/FHdJC3Mkb8Ai7HdaKz136/MFK4gbAurzcs0V/
         G6Fg==
X-Gm-Message-State: AOJu0YyMa+bece6bk8uv174kgkVQdlzm6Fk828Fsug1K/gaJo+qw5p5e
	pecX6OOVdkTET89XTH+tuRg4FaqtdUmdrbRHYhk6FDkQDywJQeqT35oAU+h+Koklu7di0IZ/TJ4
	G
X-Gm-Gg: ASbGncsJ8RguGhfmzcN4sJTuPCVt33uVQGLTfGZ+/gCOvbzI6Rw9SZmcK2Hh3/mt5ry
	rPV+5A3kGVfobrtn6ULSxWW/00UJdMqaJrP9Se2CGUIgQnhsGIPcD4r5+qT4zsHXTiY0qte2oMq
	D27VhydyXTbKQCM2mYNBxudnUttXxL1Fg2wy+BkR4wl8XlxdqEhPWjnkbqf+zZFQfykvMjZ4Sbi
	2e9uOfx5tMCxtVg3NSweup+VK1cDXoBwx4iA2wu4eiRX8255iPUmePv4HUBqiITDfE=
X-Google-Smtp-Source: AGHT+IEFaKPQqexDpzrOqyp0ve20f3nJ0Bl9tu8TrAhlQl+LI4LCrLF0fA2VgPpHt6fkFPVf5GnV0A==
X-Received: by 2002:a17:907:9612:b0:aaf:137:b5fa with SMTP id a640c23a62f3a-ab291929579mr627471066b.26.1736346631621;
        Wed, 08 Jan 2025 06:30:31 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: [PATCH v2 09/18] x86/mm: simplify create_perdomain_mapping() interface
Date: Wed,  8 Jan 2025 15:26:49 +0100
Message-ID: <20250108142659.99490-10-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250108142659.99490-1-roger.pau@citrix.com>
References: <20250108142659.99490-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

There are no longer any callers of create_perdomain_mapping() that request a
reference to the used L1 tables, and hence the only difference between them is
whether the caller wants the region to be populated, or just the paging
structures to be allocated.

Simplify the arguments to create_perdomain_mapping() to reflect the current
usages: drop the last two arguments and instead introduce a boolean to signal
whether the caller wants the region populated.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/arch/x86/domain_page.c    | 10 ++++----
 xen/arch/x86/hvm/hvm.c        |  2 +-
 xen/arch/x86/include/asm/mm.h |  3 +--
 xen/arch/x86/mm.c             | 43 +++++++----------------------------
 xen/arch/x86/pv/domain.c      |  4 +---
 xen/arch/x86/x86_64/mm.c      |  3 +--
 6 files changed, 16 insertions(+), 49 deletions(-)

diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c
index eac5e3304fb8..ad6d86be6918 100644
--- a/xen/arch/x86/domain_page.c
+++ b/xen/arch/x86/domain_page.c
@@ -254,8 +254,7 @@ int mapcache_domain_init(struct domain *d)
     spin_lock_init(&dcache->lock);
 
     return create_perdomain_mapping(d, (unsigned long)dcache->inuse,
-                                    2 * bitmap_pages + 1,
-                                    NIL(l1_pgentry_t *), NULL);
+                                    2 * bitmap_pages + 1, false);
 }
 
 int mapcache_vcpu_init(struct vcpu *v)
@@ -272,16 +271,15 @@ int mapcache_vcpu_init(struct vcpu *v)
     if ( ents > dcache->entries )
     {
         /* Populate page tables. */
-        int rc = create_perdomain_mapping(d, MAPCACHE_VIRT_START, ents,
-                                          NIL(l1_pgentry_t *), NULL);
+        int rc = create_perdomain_mapping(d, MAPCACHE_VIRT_START, ents, false);
 
         /* Populate bit maps. */
         if ( !rc )
             rc = create_perdomain_mapping(d, (unsigned long)dcache->inuse,
-                                          nr, NULL, NIL(struct page_info *));
+                                          nr, true);
         if ( !rc )
             rc = create_perdomain_mapping(d, (unsigned long)dcache->garbage,
-                                          nr, NULL, NIL(struct page_info *));
+                                          nr, true);
 
         if ( rc )
             return rc;
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 70fdddae583d..e7817144059e 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -601,7 +601,7 @@ int hvm_domain_initialise(struct domain *d,
     INIT_LIST_HEAD(&d->arch.hvm.mmcfg_regions);
     INIT_LIST_HEAD(&d->arch.hvm.msix_tables);
 
-    rc = create_perdomain_mapping(d, PERDOMAIN_VIRT_START, 0, NULL, NULL);
+    rc = create_perdomain_mapping(d, PERDOMAIN_VIRT_START, 0, false);
     if ( rc )
         goto fail;
 
diff --git a/xen/arch/x86/include/asm/mm.h b/xen/arch/x86/include/asm/mm.h
index 65cd751087dc..0c57442c9593 100644
--- a/xen/arch/x86/include/asm/mm.h
+++ b/xen/arch/x86/include/asm/mm.h
@@ -601,8 +601,7 @@ int compat_arch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg);
 #define IS_NIL(ptr) (!((uintptr_t)(ptr) + sizeof(*(ptr))))
 
 int create_perdomain_mapping(struct domain *d, unsigned long va,
-                             unsigned int nr, l1_pgentry_t **pl1tab,
-                             struct page_info **ppg);
+                             unsigned int nr, bool populate);
 void populate_perdomain_mapping(const struct vcpu *v, unsigned long va,
                                 mfn_t *mfn, unsigned long nr);
 void destroy_perdomain_mapping(const struct vcpu *v, unsigned long va,
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 713ae8dd6fa3..45664c56cb8f 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -6301,8 +6301,7 @@ static bool perdomain_l1e_needs_freeing(l1_pgentry_t l1e)
 }
 
 int create_perdomain_mapping(struct domain *d, unsigned long va,
-                             unsigned int nr, l1_pgentry_t **pl1tab,
-                             struct page_info **ppg)
+                             unsigned int nr, bool populate)
 {
     struct page_info *pg;
     l3_pgentry_t *l3tab;
@@ -6351,55 +6350,32 @@ int create_perdomain_mapping(struct domain *d, unsigned long va,
 
     unmap_domain_page(l3tab);
 
-    if ( !pl1tab && !ppg )
-    {
-        unmap_domain_page(l2tab);
-        return 0;
-    }
-
     for ( l1tab = NULL; !rc && nr--; )
     {
         l2_pgentry_t *pl2e = l2tab + l2_table_offset(va);
 
         if ( !(l2e_get_flags(*pl2e) & _PAGE_PRESENT) )
         {
-            if ( pl1tab && !IS_NIL(pl1tab) )
-            {
-                l1tab = alloc_xenheap_pages(0, MEMF_node(domain_to_node(d)));
-                if ( !l1tab )
-                {
-                    rc = -ENOMEM;
-                    break;
-                }
-                ASSERT(!pl1tab[l2_table_offset(va)]);
-                pl1tab[l2_table_offset(va)] = l1tab;
-                pg = virt_to_page(l1tab);
-            }
-            else
+            pg = alloc_domheap_page(d, MEMF_no_owner);
+            if ( !pg )
             {
-                pg = alloc_domheap_page(d, MEMF_no_owner);
-                if ( !pg )
-                {
-                    rc = -ENOMEM;
-                    break;
-                }
-                l1tab = __map_domain_page(pg);
+                rc = -ENOMEM;
+                break;
             }
+            l1tab = __map_domain_page(pg);
             clear_page(l1tab);
             *pl2e = l2e_from_page(pg, __PAGE_HYPERVISOR_RW);
         }
         else if ( !l1tab )
             l1tab = map_l1t_from_l2e(*pl2e);
 
-        if ( ppg &&
+        if ( populate &&
              !(l1e_get_flags(l1tab[l1_table_offset(va)]) & _PAGE_PRESENT) )
         {
             pg = alloc_domheap_page(d, MEMF_no_owner);
             if ( pg )
             {
                 clear_domain_page(page_to_mfn(pg));
-                if ( !IS_NIL(ppg) )
-                    *ppg++ = pg;
                 l1tab[l1_table_offset(va)] =
                     l1e_from_page(pg, __PAGE_HYPERVISOR_RW | _PAGE_AVAIL0);
                 l2e_add_flags(*pl2e, _PAGE_AVAIL0);
@@ -6618,10 +6594,7 @@ void free_perdomain_mappings(struct domain *d)
                         unmap_domain_page(l1tab);
                     }
 
-                    if ( is_xen_heap_page(l1pg) )
-                        free_xenheap_page(page_to_virt(l1pg));
-                    else
-                        free_domheap_page(l1pg);
+                    free_domheap_page(l1pg);
                 }
 
             unmap_domain_page(l2tab);
diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
index dfaeeb2e2cc2..ca32e7b5d686 100644
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -278,9 +278,7 @@ int switch_compat(struct domain *d)
 static int pv_create_gdt_ldt_l1tab(struct vcpu *v)
 {
     return create_perdomain_mapping(v->domain, GDT_VIRT_START(v),
-                                    1U << GDT_LDT_VCPU_SHIFT,
-                                    NIL(l1_pgentry_t *),
-                                    NULL);
+                                    1U << GDT_LDT_VCPU_SHIFT, false);
 }
 
 static void pv_destroy_gdt_ldt_l1tab(struct vcpu *v)
diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index c08b28d9693b..55bba7e473ae 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -731,8 +731,7 @@ void __init zap_low_mappings(void)
 int setup_compat_arg_xlat(struct vcpu *v)
 {
     return create_perdomain_mapping(v->domain, ARG_XLAT_START(v),
-                                    PFN_UP(COMPAT_ARG_XLAT_SIZE),
-                                    NULL, NIL(struct page_info *));
+                                    PFN_UP(COMPAT_ARG_XLAT_SIZE), true);
 }
 
 void free_compat_arg_xlat(struct vcpu *v)
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 14:30:38 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 14:30:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867330.1278888 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVX4w-0008SO-71; Wed, 08 Jan 2025 14:30:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867330.1278888; Wed, 08 Jan 2025 14:30:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVX4v-0008Px-7j; Wed, 08 Jan 2025 14:30:37 +0000
Received: by outflank-mailman (input) for mailman id 867330;
 Wed, 08 Jan 2025 14:30:36 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=2h7L=UA=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tVX4t-0006o2-VF
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 14:30:35 +0000
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [2a00:1450:4864:20::529])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1f8f7ced-cdcd-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 15:30:35 +0100 (CET)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-5d3cf094768so5012916a12.0
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 06:30:35 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d80676f9acsm25274285a12.31.2025.01.08.06.30.33
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 06:30:34 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1f8f7ced-cdcd-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736346635; x=1736951435; 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=sUfOuSNmcurg2d9XIPxdnWgBS7aMlQNtn0OCR0xuots=;
        b=KAp/Wh8fFn7W/oBMia3fYMEt6rAOJJslo1nF/01QBdi6xL/iAR1Oe0AqHgB7+oO9wM
         V1rizFUeQzCdiw/1JG/1pzbwI9EHhXf30zV9DjKVXC36lggPEB2L9yeI3Tv9u+U65x54
         9mw6gXb1mLLWGcIYWuTdIlhFSEGNBY9ppyvcE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736346635; x=1736951435;
        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=sUfOuSNmcurg2d9XIPxdnWgBS7aMlQNtn0OCR0xuots=;
        b=rM/CAui3HkSyOVs6NtGVhVTsnhf+PzebqbLHYepOTVtVsknNvZKMyLGOXL/VypR/Lc
         w2Q1lFFxfDX9fmkrrciWNTfhn0NRX+TkdY0LvT06YuwCJvCyjy4C9KCcHEHhvSabck51
         Y1FM83TwAuxBQxJrkJsytj7Zc8zDMLpki2S0x4k3zuV4ewrtZzkoJ5YXBYDodBA7f0kf
         qW7aA1SXD8AoSdbljHbuDgxibn5zfOEYt+NFQvGLTA4GZo3sxEkFRJ5cD6ar7HroS2EB
         2ya8rsTqNgkP5Y7Wa0zgnb8AdN5BTNBt55dE77GK1bJjF3w97QfjDuGP2zLGrIPIB90D
         DCuw==
X-Gm-Message-State: AOJu0YyMr0TPx23unGPg3eZrJBIWCJJ1Zt0tUe2WyyjSoN3CYbvNNth5
	Ldh6ZiCpfOS0oZycmX75gCHVAnVizNBVxXd2+J+zDDpPmLdlwEE5tHNESm0LJSsblkEcC05ntbC
	+
X-Gm-Gg: ASbGncsrxL5lNYw0oYa+/vFzD24c+1ghLB2FeHjCmiCNKlbQAJrMrkAp+OCITATySwC
	GPFfC8o8lWEwNCi87QCcIspR2f/XplJr1n48tJFLMAt6V1QRf+MEMErOnQ+dQiD3nAMKcLlqYs2
	WfgKsfcllliBY3naO29dBCdbbc8pYtysbdB83tpx135gi4DpPl4l/KzflJVtahooerXWAvkT1nv
	Oq3OWg1hjZ/Ciw6gC/ak1IlEnxdxqb3hoIb7m8hcpocyKwumoj1J8xiHv03Q03ZDHI=
X-Google-Smtp-Source: AGHT+IF2DvwpaRgZK7HzfqN6mxE1GSwGuQVr3ugA4OWrViS+868nKyrdujXICXFEMX53cvhmiF1lZA==
X-Received: by 2002:a05:6402:13c1:b0:5d0:ea2a:726c with SMTP id 4fb4d7f45d1cf-5d972e069b5mr2756697a12.8.1736346634609;
        Wed, 08 Jan 2025 06:30:34 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: [PATCH v2 11/18] x86/pv: untie issuing FLUSH_ROOT_PGTBL from XPTI
Date: Wed,  8 Jan 2025 15:26:51 +0100
Message-ID: <20250108142659.99490-12-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250108142659.99490-1-roger.pau@citrix.com>
References: <20250108142659.99490-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The current logic gates issuing flush TLB requests with the FLUSH_ROOT_PGTBL
flag to XPTI being enabled.

In preparation for FLUSH_ROOT_PGTBL also being needed when not using XPTI,
untie it from the xpti domain boolean and instead introduce a new flush_root_pt
field.

No functional change intended, as flush_root_pt == xpti.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/arch/x86/include/asm/domain.h   | 2 ++
 xen/arch/x86/include/asm/flushtlb.h | 2 +-
 xen/arch/x86/mm.c                   | 2 +-
 xen/arch/x86/pv/domain.c            | 2 ++
 4 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h
index 7c143d2a6c46..5af414fa64ac 100644
--- a/xen/arch/x86/include/asm/domain.h
+++ b/xen/arch/x86/include/asm/domain.h
@@ -281,6 +281,8 @@ struct pv_domain
     bool pcid;
     /* Mitigate L1TF with shadow/crashing? */
     bool check_l1tf;
+    /* Issue FLUSH_ROOT_PGTBL for root page-table changes. */
+    bool flush_root_pt;
 
     /* map_domain_page() mapping cache. */
     struct mapcache_domain mapcache;
diff --git a/xen/arch/x86/include/asm/flushtlb.h b/xen/arch/x86/include/asm/flushtlb.h
index bb0ad58db49b..1b98d03decdc 100644
--- a/xen/arch/x86/include/asm/flushtlb.h
+++ b/xen/arch/x86/include/asm/flushtlb.h
@@ -177,7 +177,7 @@ void flush_area_mask(const cpumask_t *mask, const void *va,
 
 #define flush_root_pgtbl_domain(d)                                       \
 {                                                                        \
-    if ( is_pv_domain(d) && (d)->arch.pv.xpti )                          \
+    if ( is_pv_domain(d) && (d)->arch.pv.flush_root_pt )                 \
         flush_mask((d)->dirty_cpumask, FLUSH_ROOT_PGTBL);                \
 }
 
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index c321f5723b04..49403196d56e 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4178,7 +4178,7 @@ long do_mmu_update(
                                       cmd == MMU_PT_UPDATE_PRESERVE_AD, v);
                     if ( !rc )
                         flush_linear_pt = true;
-                    if ( !rc && pt_owner->arch.pv.xpti )
+                    if ( !rc && pt_owner->arch.pv.flush_root_pt )
                     {
                         bool local_in_use = false;
 
diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
index 534d2899100f..5bda168eadff 100644
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -368,6 +368,8 @@ int pv_domain_initialise(struct domain *d)
 
     d->arch.ctxt_switch = &pv_csw;
 
+    d->arch.pv.flush_root_pt = d->arch.pv.xpti;
+
     if ( !is_pv_32bit_domain(d) && use_invpcid && cpu_has_pcid )
         switch ( ACCESS_ONCE(opt_pcid) )
         {
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 14:30:42 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 14:30:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867333.1278908 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVX50-00017v-Fq; Wed, 08 Jan 2025 14:30:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867333.1278908; Wed, 08 Jan 2025 14:30:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVX50-00016o-8s; Wed, 08 Jan 2025 14:30:42 +0000
Received: by outflank-mailman (input) for mailman id 867333;
 Wed, 08 Jan 2025 14: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
 <SRS0=2h7L=UA=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tVX4y-0006o2-Kh
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 14:30:40 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2225e2e3-cdcd-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 15:30:39 +0100 (CET)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-aa689a37dd4so565882666b.3
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 06:30:39 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0f015ae1sm2498095766b.147.2025.01.08.06.30.37
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 06:30:38 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2225e2e3-cdcd-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736346639; x=1736951439; 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=WR7teHFML1rITUYnPw8UNQ0VYOmZRC0EHDzMIXlg0pw=;
        b=cVY/4bU0wVsnhDKeWp7d7jb51GsqOsuDcxoBKROiNH4+FJKji5K/AH+eIl8YlqSSSM
         olJNQnE5+kjezvngMc96TbtI8EMEVm0L6HaGtouS0HduPX9NklXJBnlZN1rVurFApjmC
         9yrQOyQFHiu6W/+htqhbzPKrow25KIYOhWQ/I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736346639; x=1736951439;
        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=WR7teHFML1rITUYnPw8UNQ0VYOmZRC0EHDzMIXlg0pw=;
        b=u6qNx4S2XAgrBNFM60qWbmyPfiTFMDEAd4SGx1BGg75Yt3B+v0NHZy3aO8Vf7nPTHy
         VPT1J08EaGBxw5w2Ow8tmuC5TqC/Ug13X02PSXdpTUWQ4bO5nXzepW9zwZhTo6wL8YCC
         SxXC3ipnL4B5vDCnx/JG3B5F25dH6loCFaRCgyllTNiyXOo4Vyn2ZdYL/Y4Jagi2WUji
         f1LDw0wwSiuOko9bGA1P4uU+oTxqhz/Z5spQN/hzyTOxf0BQSHj8nnThCvF7cpl/o9n4
         K0TVE+WKMwgiibW1PRORTf9KiEfFP7q50Ue2UCbSE/yHlyCFbF173Ef/ovVQncuUH4HU
         Ku0A==
X-Gm-Message-State: AOJu0YzwnHne2WkgzinvnzBNPvC3Rky5PJvWpKaXZj0LllJ80fRVkPww
	lsF+XN7/DknopTMT24rLbJuWW6DKcsdpyidiK+qJVT4GxizPCjl2/UWaEf2UFF9a5B8DRhMPWZa
	O
X-Gm-Gg: ASbGncs36JjTZQWmT1/+mXzTx2yLVY/vTEHBi+rWfudOPTvxNU5zJRHC0FoGAxZ75vU
	+xuWimaU78twk2OgauUJYyZ3sEoTyAktHHAbgPzPjeH0AE2IH7CsAqvctkNEydFTbEKJh/zxvoy
	IxXI7IiXmFys/FN1E7tzjO5oClzQyqRm5RULa8Io1qlrwyQWTCI1Eq581JQgx3zV24lcjcmPWWX
	kikSxTaPOTLEFnqUcWvMN+21IDoa5pGA5CI5FC+fT2UT8RhZkF+mX8FTwctUXa7Ppc=
X-Google-Smtp-Source: AGHT+IF/Xw9nkDZk1ywDDDE/IVmeebeNSqZlflHTjUOVoey3KkVwbF4xhORQCkJpHXMzlcnEBQFmaw==
X-Received: by 2002:a17:906:ef09:b0:aab:71fc:47a3 with SMTP id a640c23a62f3a-ab2abda708dmr260798666b.60.1736346638763;
        Wed, 08 Jan 2025 06:30:38 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Tim Deegan <tim@xen.org>
Subject: [PATCH v2 14/18] x86/mm: introduce per-vCPU L3 page-table
Date: Wed,  8 Jan 2025 15:26:54 +0100
Message-ID: <20250108142659.99490-15-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250108142659.99490-1-roger.pau@citrix.com>
References: <20250108142659.99490-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Such table is to be used in the per-domain slot when running with Address Space
Isolation enabled for the domain.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/arch/x86/include/asm/domain.h |  3 +++
 xen/arch/x86/include/asm/mm.h     |  2 +-
 xen/arch/x86/mm.c                 | 45 ++++++++++++++++++++++---------
 xen/arch/x86/mm/hap/hap.c         |  2 +-
 xen/arch/x86/mm/shadow/hvm.c      |  2 +-
 xen/arch/x86/mm/shadow/multi.c    |  2 +-
 xen/arch/x86/pv/dom0_build.c      |  2 +-
 xen/arch/x86/pv/domain.c          |  2 +-
 8 files changed, 41 insertions(+), 19 deletions(-)

diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h
index fb92a10bf3b7..5bf0ad3fdcf7 100644
--- a/xen/arch/x86/include/asm/domain.h
+++ b/xen/arch/x86/include/asm/domain.h
@@ -666,6 +666,9 @@ struct arch_vcpu
 
     struct vcpu_msrs *msrs;
 
+    /* ASI: per-vCPU L3 table to use in the L4 per-domain slot. */
+    struct page_info *pervcpu_l3_pg;
+
     struct {
         bool next_interrupt_enabled;
     } monitor;
diff --git a/xen/arch/x86/include/asm/mm.h b/xen/arch/x86/include/asm/mm.h
index f501e5e115ff..f79d1594fde4 100644
--- a/xen/arch/x86/include/asm/mm.h
+++ b/xen/arch/x86/include/asm/mm.h
@@ -375,7 +375,7 @@ int devalidate_page(struct page_info *page, unsigned long type,
 
 void init_xen_pae_l2_slots(l2_pgentry_t *l2t, const struct domain *d);
 void init_xen_l4_slots(l4_pgentry_t *l4t, mfn_t l4mfn,
-                       const struct domain *d, mfn_t sl4mfn, bool ro_mpt);
+                       const struct vcpu *v, mfn_t sl4mfn, bool ro_mpt);
 bool fill_ro_mpt(mfn_t mfn);
 void zap_ro_mpt(mfn_t mfn);
 
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 49403196d56e..583bf4c58bf9 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -1658,8 +1658,9 @@ static int promote_l3_table(struct page_info *page)
  * extended directmap.
  */
 void init_xen_l4_slots(l4_pgentry_t *l4t, mfn_t l4mfn,
-                       const struct domain *d, mfn_t sl4mfn, bool ro_mpt)
+                       const struct vcpu *v, mfn_t sl4mfn, bool ro_mpt)
 {
+    const struct domain *d = v->domain;
     /*
      * PV vcpus need a shortened directmap.  HVM and Idle vcpus get the full
      * directmap.
@@ -1687,7 +1688,9 @@ void init_xen_l4_slots(l4_pgentry_t *l4t, mfn_t l4mfn,
 
     /* Slot 260: Per-domain mappings. */
     l4t[l4_table_offset(PERDOMAIN_VIRT_START)] =
-        l4e_from_page(d->arch.perdomain_l3_pg, __PAGE_HYPERVISOR_RW);
+        l4e_from_page(d->arch.vcpu_pt ? v->arch.pervcpu_l3_pg
+                                      : d->arch.perdomain_l3_pg,
+                      __PAGE_HYPERVISOR_RW);
 
     /* Slot 4: Per-domain mappings mirror. */
     BUILD_BUG_ON(IS_ENABLED(CONFIG_PV32) &&
@@ -1842,8 +1845,15 @@ static int promote_l4_table(struct page_info *page)
 
     if ( !rc )
     {
+        /*
+         * Use vCPU#0 unconditionally.  When not running with ASI enabled the
+         * per-domain table is shared between all vCPUs, so it doesn't matter
+         * which vCPU gets passed to init_xen_l4_slots().  When running with
+         * ASI enabled this L4 will not be used, as a shadow per-vCPU L4 is
+         * used instead.
+         */
         init_xen_l4_slots(pl4e, l4mfn,
-                          d, INVALID_MFN, VM_ASSIST(d, m2p_strict));
+                          d->vcpu[0], INVALID_MFN, VM_ASSIST(d, m2p_strict));
         atomic_inc(&d->arch.pv.nr_l4_pages);
     }
     unmap_domain_page(pl4e);
@@ -6313,14 +6323,17 @@ int create_perdomain_mapping(struct vcpu *v, unsigned long va,
     ASSERT(va >= PERDOMAIN_VIRT_START &&
            va < PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS));
 
-    if ( !d->arch.perdomain_l3_pg )
+    if ( !v->arch.pervcpu_l3_pg && !d->arch.perdomain_l3_pg )
     {
         pg = alloc_domheap_page(d, MEMF_no_owner);
         if ( !pg )
             return -ENOMEM;
         l3tab = __map_domain_page(pg);
         clear_page(l3tab);
-        d->arch.perdomain_l3_pg = pg;
+        if ( d->arch.vcpu_pt )
+            v->arch.pervcpu_l3_pg = pg;
+        else
+            d->arch.perdomain_l3_pg = pg;
         if ( !nr )
         {
             unmap_domain_page(l3tab);
@@ -6330,7 +6343,8 @@ int create_perdomain_mapping(struct vcpu *v, unsigned long va,
     else if ( !nr )
         return 0;
     else
-        l3tab = __map_domain_page(d->arch.perdomain_l3_pg);
+        l3tab = __map_domain_page(d->arch.vcpu_pt ? v->arch.pervcpu_l3_pg
+                                                  : d->arch.perdomain_l3_pg);
 
     ASSERT(!l3_table_offset(va ^ (va + nr * PAGE_SIZE - 1)));
 
@@ -6436,8 +6450,9 @@ void populate_perdomain_mapping(const struct vcpu *v, unsigned long va,
         return;
     }
 
-    ASSERT(d->arch.perdomain_l3_pg);
-    l3tab = __map_domain_page(d->arch.perdomain_l3_pg);
+    ASSERT(d->arch.perdomain_l3_pg || v->arch.pervcpu_l3_pg);
+    l3tab = __map_domain_page(d->arch.vcpu_pt ? v->arch.pervcpu_l3_pg
+                                              : d->arch.perdomain_l3_pg);
 
     if ( unlikely(!(l3e_get_flags(l3tab[l3_table_offset(va)]) &
                     _PAGE_PRESENT)) )
@@ -6498,7 +6513,7 @@ void destroy_perdomain_mapping(const struct vcpu *v, unsigned long va,
            va < PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS));
     ASSERT(!nr || !l3_table_offset(va ^ (va + nr * PAGE_SIZE - 1)));
 
-    if ( !d->arch.perdomain_l3_pg )
+    if ( !d->arch.perdomain_l3_pg && !v->arch.pervcpu_l3_pg )
         return;
 
     /* Use likely to force the optimization for the fast path. */
@@ -6522,7 +6537,8 @@ void destroy_perdomain_mapping(const struct vcpu *v, unsigned long va,
         return;
     }
 
-    l3tab = __map_domain_page(d->arch.perdomain_l3_pg);
+    l3tab = __map_domain_page(d->arch.vcpu_pt ? v->arch.pervcpu_l3_pg
+                                              : d->arch.perdomain_l3_pg);
     pl3e = l3tab + l3_table_offset(va);
 
     if ( l3e_get_flags(*pl3e) & _PAGE_PRESENT )
@@ -6567,10 +6583,11 @@ void free_perdomain_mappings(struct vcpu *v)
     l3_pgentry_t *l3tab;
     unsigned int i;
 
-    if ( !d->arch.perdomain_l3_pg )
+    if ( !v->arch.pervcpu_l3_pg && !d->arch.perdomain_l3_pg )
         return;
 
-    l3tab = __map_domain_page(d->arch.perdomain_l3_pg);
+    l3tab = __map_domain_page(d->arch.vcpu_pt ? v->arch.pervcpu_l3_pg
+                                              : d->arch.perdomain_l3_pg);
 
     for ( i = 0; i < PERDOMAIN_SLOTS; ++i)
         if ( l3e_get_flags(l3tab[i]) & _PAGE_PRESENT )
@@ -6604,8 +6621,10 @@ void free_perdomain_mappings(struct vcpu *v)
         }
 
     unmap_domain_page(l3tab);
-    free_domheap_page(d->arch.perdomain_l3_pg);
+    free_domheap_page(d->arch.vcpu_pt ? v->arch.pervcpu_l3_pg
+                                      : d->arch.perdomain_l3_pg);
     d->arch.perdomain_l3_pg = NULL;
+    v->arch.pervcpu_l3_pg = NULL;
 }
 
 static void write_sss_token(unsigned long *ptr)
diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index ec5043a8aa9e..c7d9bf7c71bf 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -402,7 +402,7 @@ static mfn_t hap_make_monitor_table(struct vcpu *v)
     m4mfn = page_to_mfn(pg);
     l4e = map_domain_page(m4mfn);
 
-    init_xen_l4_slots(l4e, m4mfn, d, INVALID_MFN, false);
+    init_xen_l4_slots(l4e, m4mfn, v, INVALID_MFN, false);
     unmap_domain_page(l4e);
 
     return m4mfn;
diff --git a/xen/arch/x86/mm/shadow/hvm.c b/xen/arch/x86/mm/shadow/hvm.c
index 114957a3e1ec..d588dbbae003 100644
--- a/xen/arch/x86/mm/shadow/hvm.c
+++ b/xen/arch/x86/mm/shadow/hvm.c
@@ -776,7 +776,7 @@ mfn_t sh_make_monitor_table(const struct vcpu *v, unsigned int shadow_levels)
      * shadow-linear mapping will either be inserted below when creating
      * lower level monitor tables, or later in sh_update_cr3().
      */
-    init_xen_l4_slots(l4e, m4mfn, d, INVALID_MFN, false);
+    init_xen_l4_slots(l4e, m4mfn, v, INVALID_MFN, false);
 
     if ( shadow_levels < 4 )
     {
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index 10ddc408ff73..a1f8147e197a 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -973,7 +973,7 @@ sh_make_shadow(struct vcpu *v, mfn_t gmfn, u32 shadow_type)
 
             BUILD_BUG_ON(sizeof(l4_pgentry_t) != sizeof(shadow_l4e_t));
 
-            init_xen_l4_slots(l4t, gmfn, d, smfn, (!is_pv_32bit_domain(d) &&
+            init_xen_l4_slots(l4t, gmfn, v, smfn, (!is_pv_32bit_domain(d) &&
                                                    VM_ASSIST(d, m2p_strict)));
             unmap_domain_page(l4t);
         }
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index f54d1da5c6f4..5081c19b9a9a 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -737,7 +737,7 @@ static int __init dom0_construct(struct boot_info *bi, struct domain *d)
         l4start = l4tab = __va(mpt_alloc); mpt_alloc += PAGE_SIZE;
         clear_page(l4tab);
         init_xen_l4_slots(l4tab, _mfn(virt_to_mfn(l4start)),
-                          d, INVALID_MFN, true);
+                          d->vcpu[0], INVALID_MFN, true);
         v->arch.guest_table = pagetable_from_paddr(__pa(l4start));
     }
     else
diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
index 5bda168eadff..8d2428051607 100644
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -125,7 +125,7 @@ static int setup_compat_l4(struct vcpu *v)
     mfn = page_to_mfn(pg);
     l4tab = map_domain_page(mfn);
     clear_page(l4tab);
-    init_xen_l4_slots(l4tab, mfn, v->domain, INVALID_MFN, false);
+    init_xen_l4_slots(l4tab, mfn, v, INVALID_MFN, false);
     unmap_domain_page(l4tab);
 
     /* This page needs to look like a pagetable so that it can be shadowed */
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 14:40:44 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 14:40:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867373.1278918 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXEc-0005nA-GL; Wed, 08 Jan 2025 14:40:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867373.1278918; Wed, 08 Jan 2025 14:40:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXEc-0005n3-Cy; Wed, 08 Jan 2025 14:40:38 +0000
Received: by outflank-mailman (input) for mailman id 867373;
 Wed, 08 Jan 2025 14:40:37 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=2h7L=UA=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tVX55-0005q4-C1
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 14:30:47 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 24368c75-cdcd-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 15:30:43 +0100 (CET)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-5d3dce16a3dso1765083a12.1
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 06:30:43 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d8f51faaf8sm10072954a12.2.2025.01.08.06.30.39
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 06:30:39 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 24368c75-cdcd-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736346642; x=1736951442; 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=JNW32bRT/EB8JAJJfIqWa3rkLwjG5D4hxKX8BxasRVQ=;
        b=brsXOagBDLHHKXlIhNM2KPDkBHOYrBomVeB8Q6VksbMumv/LzaaVL/fqOWxN+v3ZAQ
         ZpX/bBO8wIk1qT5sWu7NXNWUYn6tGKyL/WfE9h46Ec4CIgkhVeBB+/NpuG/xA0x0Ivjg
         qpqEcepUvCk7tPvvlzIFmv7gZlYmgPfQvTZ8Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736346642; x=1736951442;
        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=JNW32bRT/EB8JAJJfIqWa3rkLwjG5D4hxKX8BxasRVQ=;
        b=niU71F66EZ6S6hrzvbVRsI0I9Iw5de5YZ2sDyaAUPVpM1D0HXZuaPkI+RQy9RHMhO8
         7UDhGWTwBvis3lMDJtYNQkOmFe7YwHRtUkwk+jr50eJMDdkMstH+4L/GqrdRvwuDIzG/
         pG8ZOxXmSSDyBCYimAp4Y1n8c/GMsoeib5hLwgg4c+z2t8575hjak+0pXdjUIEQ/QjxN
         4/alAX4Qodg7yCc7EbAbR5RSzZI8xrCfNn4J7tM7eXb0Q3tFVEaRapSxlYlOtlHiWEYQ
         eLSjht0THiQic4yfLS7qdMrXLIRYJqHt3LH2R0MLEoGvPmtgikcwF9/OQHryrvRrxBIs
         5khA==
X-Gm-Message-State: AOJu0YwONCq0hN6pd8Ee8m8ExbUVVkF4AEHym7LQ22jEJ/Seht4rrpGB
	vp38YN2UY1PxTC7hVTbCGk2inWsOef8EYvSqffr39wxgvHpU7o6CbHYTbytzVIEMfJayKRgNJpN
	a
X-Gm-Gg: ASbGncv+Otc4t48zwtKeYWvQDsdmKnMKGS0UO5y3cxbU7mF7fw9SJL2aJJ5CujDvAHS
	rEAIHfc3dqlBCEtFBaf+Ucv2qmonMP2RtDdKzYl9TAFe0fFCeyMzPQn+6XzwVQ9o6s/R+hYc06C
	9fNkP1D8k5m1td2u7d5OZZU3+XSS6dGa8BUOOo3Y7XmhyUm1bJonj/ybDyvkW1EzlUg+9ogfqZ0
	UVdtefEs9wIqzW5Zzyr6agj8VFuyRLEfgQCzxu4Vb3ad+4Ug1n0Sm3F4X20NclVmlE=
X-Google-Smtp-Source: AGHT+IEqQIaGeMfOrrMGbsRVv/X76nyH1yi83H5076IXDviKZPheR28xONW6k7grUF1jnqGwq4MnkQ==
X-Received: by 2002:a05:6402:40c6:b0:5d9:6633:8e9b with SMTP id 4fb4d7f45d1cf-5d971b30399mr3065185a12.1.1736346640359;
        Wed, 08 Jan 2025 06:30:40 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: [PATCH v2 15/18] x86/mm: introduce a per-vCPU mapcache when using ASI
Date: Wed,  8 Jan 2025 15:26:55 +0100
Message-ID: <20250108142659.99490-16-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250108142659.99490-1-roger.pau@citrix.com>
References: <20250108142659.99490-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

When using a unique per-vCPU root page table the per-domain region becomes
per-vCPU, and hence the mapcache is no longer shared between all vCPUs of a
domain.  Introduce per-vCPU mapcache structures, and modify map_domain_page()
to create per-vCPU mappings when possible.  Note the lock is also not needed
with using per-vCPU map caches, as the structure is no longer shared.

This introduces some duplication in the domain and vcpu structures, as both
contain a mapcache field to support running with and without per-vCPU
page-tables.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/arch/x86/domain_page.c        | 90 ++++++++++++++++++++-----------
 xen/arch/x86/include/asm/domain.h | 20 ++++---
 2 files changed, 71 insertions(+), 39 deletions(-)

diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c
index 1372be20224e..65900d6218f8 100644
--- a/xen/arch/x86/domain_page.c
+++ b/xen/arch/x86/domain_page.c
@@ -74,7 +74,9 @@ void *map_domain_page(mfn_t mfn)
     struct vcpu *v;
     struct mapcache_domain *dcache;
     struct mapcache_vcpu *vcache;
+    struct mapcache *cache;
     struct vcpu_maphash_entry *hashent;
+    struct domain *d;
 
 #ifdef NDEBUG
     if ( mfn_x(mfn) <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) )
@@ -85,9 +87,12 @@ void *map_domain_page(mfn_t mfn)
     if ( !v || !is_pv_vcpu(v) )
         return mfn_to_virt(mfn_x(mfn));
 
-    dcache = &v->domain->arch.pv.mapcache;
+    d = v->domain;
+    dcache = &d->arch.pv.mapcache;
     vcache = &v->arch.pv.mapcache;
-    if ( !dcache->inuse )
+    cache = d->arch.vcpu_pt ? &v->arch.pv.mapcache.cache
+                            : &d->arch.pv.mapcache.cache;
+    if ( !cache->inuse )
         return mfn_to_virt(mfn_x(mfn));
 
     perfc_incr(map_domain_page_count);
@@ -98,17 +103,18 @@ void *map_domain_page(mfn_t mfn)
     if ( hashent->mfn == mfn_x(mfn) )
     {
         idx = hashent->idx;
-        ASSERT(idx < dcache->entries);
+        ASSERT(idx < cache->entries);
         hashent->refcnt++;
         ASSERT(hashent->refcnt);
         ASSERT(mfn_eq(l1e_get_mfn(MAPCACHE_L1ENT(idx)), mfn));
         goto out;
     }
 
-    spin_lock(&dcache->lock);
+    if ( !d->arch.vcpu_pt )
+        spin_lock(&dcache->lock);
 
     /* Has some other CPU caused a wrap? We must flush if so. */
-    if ( unlikely(dcache->epoch != vcache->shadow_epoch) )
+    if ( unlikely(!d->arch.vcpu_pt && dcache->epoch != vcache->shadow_epoch) )
     {
         vcache->shadow_epoch = dcache->epoch;
         if ( NEED_FLUSH(this_cpu(tlbflush_time), dcache->tlbflush_timestamp) )
@@ -118,21 +124,21 @@ void *map_domain_page(mfn_t mfn)
         }
     }
 
-    idx = find_next_zero_bit(dcache->inuse, dcache->entries, dcache->cursor);
-    if ( unlikely(idx >= dcache->entries) )
+    idx = find_next_zero_bit(cache->inuse, cache->entries, cache->cursor);
+    if ( unlikely(idx >= cache->entries) )
     {
         unsigned long accum = 0, prev = 0;
 
         /* /First/, clean the garbage map and update the inuse list. */
-        for ( i = 0; i < BITS_TO_LONGS(dcache->entries); i++ )
+        for ( i = 0; i < BITS_TO_LONGS(cache->entries); i++ )
         {
             accum |= prev;
-            dcache->inuse[i] &= ~xchg(&dcache->garbage[i], 0);
-            prev = ~dcache->inuse[i];
+            cache->inuse[i] &= ~xchg(&cache->garbage[i], 0);
+            prev = ~cache->inuse[i];
         }
 
-        if ( accum | (prev & BITMAP_LAST_WORD_MASK(dcache->entries)) )
-            idx = find_first_zero_bit(dcache->inuse, dcache->entries);
+        if ( accum | (prev & BITMAP_LAST_WORD_MASK(cache->entries)) )
+            idx = find_first_zero_bit(cache->inuse, cache->entries);
         else
         {
             /* Replace a hash entry instead. */
@@ -152,19 +158,23 @@ void *map_domain_page(mfn_t mfn)
                     i = 0;
             } while ( i != MAPHASH_HASHFN(mfn_x(mfn)) );
         }
-        BUG_ON(idx >= dcache->entries);
+        BUG_ON(idx >= cache->entries);
 
         /* /Second/, flush TLBs. */
         perfc_incr(domain_page_tlb_flush);
         flush_tlb_local();
-        vcache->shadow_epoch = ++dcache->epoch;
-        dcache->tlbflush_timestamp = tlbflush_current_time();
+        if ( !d->arch.vcpu_pt )
+        {
+            vcache->shadow_epoch = ++dcache->epoch;
+            dcache->tlbflush_timestamp = tlbflush_current_time();
+        }
     }
 
-    set_bit(idx, dcache->inuse);
-    dcache->cursor = idx + 1;
+    set_bit(idx, cache->inuse);
+    cache->cursor = idx + 1;
 
-    spin_unlock(&dcache->lock);
+    if ( !d->arch.vcpu_pt )
+        spin_unlock(&dcache->lock);
 
     l1e_write(&MAPCACHE_L1ENT(idx), l1e_from_mfn(mfn, __PAGE_HYPERVISOR_RW));
 
@@ -178,6 +188,7 @@ void unmap_domain_page(const void *ptr)
     unsigned int idx;
     struct vcpu *v;
     struct mapcache_domain *dcache;
+    struct mapcache *cache;
     unsigned long va = (unsigned long)ptr, mfn, flags;
     struct vcpu_maphash_entry *hashent;
 
@@ -190,7 +201,9 @@ void unmap_domain_page(const void *ptr)
     ASSERT(v && is_pv_vcpu(v));
 
     dcache = &v->domain->arch.pv.mapcache;
-    ASSERT(dcache->inuse);
+    cache = v->domain->arch.vcpu_pt ? &v->arch.pv.mapcache.cache
+                                    : &v->domain->arch.pv.mapcache.cache;
+    ASSERT(cache->inuse);
 
     idx = PFN_DOWN(va - MAPCACHE_VIRT_START);
     mfn = l1e_get_pfn(MAPCACHE_L1ENT(idx));
@@ -213,7 +226,7 @@ void unmap_domain_page(const void *ptr)
                    hashent->mfn);
             l1e_write(&MAPCACHE_L1ENT(hashent->idx), l1e_empty());
             /* /Second/, mark as garbage. */
-            set_bit(hashent->idx, dcache->garbage);
+            set_bit(hashent->idx, cache->garbage);
         }
 
         /* Add newly-freed mapping to the maphash. */
@@ -225,7 +238,7 @@ void unmap_domain_page(const void *ptr)
         /* /First/, zap the PTE. */
         l1e_write(&MAPCACHE_L1ENT(idx), l1e_empty());
         /* /Second/, mark as garbage. */
-        set_bit(idx, dcache->garbage);
+        set_bit(idx, cache->garbage);
     }
 
     local_irq_restore(flags);
@@ -234,7 +247,6 @@ void unmap_domain_page(const void *ptr)
 void mapcache_domain_init(struct domain *d)
 {
     struct mapcache_domain *dcache = &d->arch.pv.mapcache;
-    unsigned int bitmap_pages;
 
     ASSERT(is_pv_domain(d));
 
@@ -243,13 +255,12 @@ void mapcache_domain_init(struct domain *d)
         return;
 #endif
 
+    if ( d->arch.vcpu_pt )
+        return;
+
     BUILD_BUG_ON(MAPCACHE_VIRT_END + PAGE_SIZE * (3 +
                  2 * PFN_UP(BITS_TO_LONGS(MAPCACHE_ENTRIES) * sizeof(long))) >
                  MAPCACHE_VIRT_START + (PERDOMAIN_SLOT_MBYTES << 20));
-    bitmap_pages = PFN_UP(BITS_TO_LONGS(MAPCACHE_ENTRIES) * sizeof(long));
-    dcache->inuse = (void *)MAPCACHE_VIRT_END + PAGE_SIZE;
-    dcache->garbage = dcache->inuse +
-                      (bitmap_pages + 1) * PAGE_SIZE / sizeof(long);
 
     spin_lock_init(&dcache->lock);
 }
@@ -258,30 +269,45 @@ int mapcache_vcpu_init(struct vcpu *v)
 {
     struct domain *d = v->domain;
     struct mapcache_domain *dcache = &d->arch.pv.mapcache;
+    struct mapcache *cache;
     unsigned long i;
-    unsigned int ents = d->max_vcpus * MAPCACHE_VCPU_ENTRIES;
+    unsigned int ents = (d->arch.vcpu_pt ? 1 : d->max_vcpus) *
+                        MAPCACHE_VCPU_ENTRIES;
     unsigned int nr = PFN_UP(BITS_TO_LONGS(ents) * sizeof(long));
 
-    if ( !is_pv_vcpu(v) || !dcache->inuse )
+    if ( !is_pv_vcpu(v) )
         return 0;
 
-    if ( ents > dcache->entries )
+    cache = d->arch.vcpu_pt ? &v->arch.pv.mapcache.cache
+                            : &dcache->cache;
+
+    if ( !cache->inuse )
+        return 0;
+
+    if ( ents > cache->entries )
     {
         /* Populate page tables. */
         int rc = create_perdomain_mapping(v, MAPCACHE_VIRT_START, ents, false);
+        const unsigned int bitmap_pages =
+            PFN_UP(BITS_TO_LONGS(MAPCACHE_ENTRIES) * sizeof(long));
+
+        cache->inuse = (void *)MAPCACHE_VIRT_END + PAGE_SIZE;
+        cache->garbage = cache->inuse +
+                         (bitmap_pages + 1) * PAGE_SIZE / sizeof(long);
+
 
         /* Populate bit maps. */
         if ( !rc )
-            rc = create_perdomain_mapping(v, (unsigned long)dcache->inuse,
+            rc = create_perdomain_mapping(v, (unsigned long)cache->inuse,
                                           nr, true);
         if ( !rc )
-            rc = create_perdomain_mapping(v, (unsigned long)dcache->garbage,
+            rc = create_perdomain_mapping(v, (unsigned long)cache->garbage,
                                           nr, true);
 
         if ( rc )
             return rc;
 
-        dcache->entries = ents;
+        cache->entries = ents;
     }
 
     /* Mark all maphash entries as not in use. */
diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h
index 5bf0ad3fdcf7..ba5440099d90 100644
--- a/xen/arch/x86/include/asm/domain.h
+++ b/xen/arch/x86/include/asm/domain.h
@@ -41,6 +41,16 @@ struct trap_bounce {
     unsigned long eip;
 };
 
+struct mapcache {
+    /* The number of array entries, and a cursor into the array. */
+    unsigned int entries;
+    unsigned int cursor;
+
+    /* Which mappings are in use, and which are garbage to reap next epoch? */
+    unsigned long *inuse;
+    unsigned long *garbage;
+};
+
 #define MAPHASH_ENTRIES 8
 #define MAPHASH_HASHFN(pfn) ((pfn) & (MAPHASH_ENTRIES-1))
 #define MAPHASHENT_NOTINUSE ((u32)~0U)
@@ -54,13 +64,11 @@ struct mapcache_vcpu {
         uint32_t      idx;
         uint32_t      refcnt;
     } hash[MAPHASH_ENTRIES];
+
+    struct mapcache cache;
 };
 
 struct mapcache_domain {
-    /* The number of array entries, and a cursor into the array. */
-    unsigned int entries;
-    unsigned int cursor;
-
     /* Protects map_domain_page(). */
     spinlock_t lock;
 
@@ -68,9 +76,7 @@ struct mapcache_domain {
     unsigned int epoch;
     u32 tlbflush_timestamp;
 
-    /* Which mappings are in use, and which are garbage to reap next epoch? */
-    unsigned long *inuse;
-    unsigned long *garbage;
+    struct mapcache cache;
 };
 
 void mapcache_domain_init(struct domain *d);
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 14:40:51 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 14:40:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867386.1278928 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXEp-0006Az-Mj; Wed, 08 Jan 2025 14:40:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867386.1278928; Wed, 08 Jan 2025 14:40:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXEp-0006As-Jb; Wed, 08 Jan 2025 14:40:51 +0000
Received: by outflank-mailman (input) for mailman id 867386;
 Wed, 08 Jan 2025 14:40:49 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=2h7L=UA=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tVX57-0006o2-Mg
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 14:30:49 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2626b1d6-cdcd-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 15:30:46 +0100 (CET)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-aaee2c5ee6eso2013716966b.1
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 06:30:46 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0e830d9dsm2482307666b.5.2025.01.08.06.30.42
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 06:30:43 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2626b1d6-cdcd-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736346645; x=1736951445; 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=n+9ipm9aojVjLIK5yzenbimOjI0E5BZJ2ikbMkXDNCg=;
        b=D20e4cfbqWXrDsnosH5HUCM/n++kC/l7XJNpsPUR95nVcXAFk/4JTDChfxHX7KZ6ur
         PtrJ4yZVqJca7FROddgArJqakJs8vMDjfqd/V7BU6SSesFltT60mk9DRtB1oehAyGdu0
         zVleJfF3s8A2S02uVEVklyg8lYN7CRu8vhXg4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736346645; x=1736951445;
        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=n+9ipm9aojVjLIK5yzenbimOjI0E5BZJ2ikbMkXDNCg=;
        b=BbauOqUJLWI1x0ZO0dZuBx6Y4WC1ZYwuNzDzbi5ZYKWIzWZysWddLwfcLI4/9h7H39
         ZOSfo/FMHrzz5aS28t5+Lm7hG+zJR7Cydtv7PrZRWA5rn2npADyMOIejCIr2KlgRCdD5
         t0l/ohbEr5cd+eJhC2R3lyuxPEPGdGXH7T/3vPF7R+EoqVZXGSk2wB6gq3EdrUtgOdvg
         JGEz9EQgIjBMU9ZUwSPcpkVGiXPuf1HEmUWklzD1GE55zf0Eq3PT9AeUSua5z9FoppYr
         gXFx8uYSCUcWFKetwLM92+obyyR8S4IjJ6d6tSnhzXgZ+5LFEgn0MqFFpgy6iBLVAzrs
         HktA==
X-Gm-Message-State: AOJu0YxqX0eSCEolXVUmP39AcsFUVHnG/Rw2PMm+2vl4fIxAHnnSzJS9
	ZhoLyj8vbyJT36Demej5v35YYAShb3ad/ZiE5y1HUk4OxY+fcgdTaT1oI4jTcIhU/AH9gKLNpf+
	S
X-Gm-Gg: ASbGncud9qerCr+inl6bgN52kVhWfygEAQiNh0XuwKlXpO84yT7FlhSfb+ahhVHGaa7
	YtiPtO6NkQ23u6KC/tkqr4tBDh76txcfScWevreV/8CoYPqPBgF2eZNYwv9GK6GDjSc/1h+iOv+
	ZraAg0sR9KXFzG9n7tihTBhv739aM4E8CLeX/lU6lUSIxyeLQjtRH8pHrt/7cpJU4iDHM9YQZC2
	dxWEGtV2RFwo83pMc5Xz0LDbwWLCb0IqaMVt78HSlHZW8Yu1k/QYq6M2pU9ZEc7jBk=
X-Google-Smtp-Source: AGHT+IFQ6xjtyx4IWz5iNuwpiOSpVoUvBXP3NeKXcaXm3nOGxgy2uWW8xrE/oDyTva2NL/5yAaTPow==
X-Received: by 2002:a17:907:97cc:b0:aa6:ac9b:6822 with SMTP id a640c23a62f3a-ab2ab670625mr215774366b.12.1736346643755;
        Wed, 08 Jan 2025 06:30:43 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v2 17/18] x86/mm: switch to a per-CPU mapped stack when using ASI
Date: Wed,  8 Jan 2025 15:26:57 +0100
Message-ID: <20250108142659.99490-18-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250108142659.99490-1-roger.pau@citrix.com>
References: <20250108142659.99490-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

When using ASI the CPU stack is mapped using a range of fixmap entries in the
per-CPU region.  This ensures the stack is only accessible by the current CPU.

Note however there's further work required in order to allocate the stack from
domheap instead of xenheap, and ensure the stack is not part of the direct
map.

For domains not running with ASI enabled all the CPU stacks are mapped in the
per-domain L3, so that the stack is always at the same linear address,
regardless of whether ASI is enabled or not for the domain.

When calling UEFI runtime methods the current per-domain slot needs to be added
to the EFI L4, so that the stack is available in UEFI.

Finally, some users of callfunc IPIs pass parameters from the stack, so when
handling a callfunc IPI the stack of the caller CPU is mapped into the address
space of the CPU handling the IPI.  This needs further work to use a bounce
buffer in order to avoid having to map remote CPU stacks.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
There's also further work required in order to avoid mapping remote stack when
handling callfunc IPIs.
---
 docs/misc/xen-command-line.pandoc    |  5 +-
 xen/arch/x86/domain.c                | 30 ++++++++++++
 xen/arch/x86/include/asm/config.h    | 10 +++-
 xen/arch/x86/include/asm/current.h   |  5 ++
 xen/arch/x86/include/asm/domain.h    |  3 ++
 xen/arch/x86/include/asm/mm.h        |  2 +-
 xen/arch/x86/include/asm/smp.h       | 12 +++++
 xen/arch/x86/include/asm/spec_ctrl.h |  1 +
 xen/arch/x86/mm.c                    | 69 ++++++++++++++++++++++------
 xen/arch/x86/setup.c                 | 32 ++++++++++---
 xen/arch/x86/smp.c                   | 39 ++++++++++++++++
 xen/arch/x86/smpboot.c               | 20 +++++++-
 xen/arch/x86/spec_ctrl.c             | 67 +++++++++++++++++++++++----
 xen/arch/x86/traps.c                 |  8 +++-
 xen/common/smp.c                     | 10 ++++
 xen/common/stop_machine.c            | 10 ++++
 xen/include/xen/smp.h                |  8 ++++
 17 files changed, 295 insertions(+), 36 deletions(-)

diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index 3c1ad7b5fe7d..e7828d092098 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -204,7 +204,7 @@ to appropriate auditing by Xen.  Argo is disabled by default.
 
 ### asi (x86)
 > `= List of [ <bool>, {pv,hvm}=<bool>,
-               {vcpu-pt}=<bool>|{pv,hvm}=<bool> ]`
+               {vcpu-pt,cpu-stack}=<bool>|{pv,hvm}=<bool> ]`
 
 Offers control over whether the hypervisor will engage in Address Space
 Isolation, by not having potentially sensitive information permanently mapped
@@ -221,6 +221,9 @@ meant to be used for debugging purposes only.**
 * `vcpu-pt` ensure each vCPU uses a unique top-level page-table and setup a
   virtual address space region to map memory on a per-vCPU basis.
 
+* `cpu-stack` prevent CPUs from having permanent mappings of stacks different
+  than their own.  Depends on the `vcpu-pt` option.
+
 ### asid (x86)
 > `= <boolean>`
 
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 6e1f622f7385..ac6332266e95 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -563,6 +563,26 @@ int arch_vcpu_create(struct vcpu *v)
     if ( rc )
         return rc;
 
+    if ( opt_cpu_stack_hvm || opt_cpu_stack_pv )
+    {
+        if ( is_idle_vcpu(v) || d->arch.cpu_stack )
+            create_perdomain_mapping(v, PCPU_STACK_VIRT(0),
+                                     nr_cpu_ids << STACK_ORDER, false);
+        else if ( !v->vcpu_id )
+        {
+            l3_pgentry_t *idle_perdomain =
+                __map_domain_page(idle_vcpu[0]->domain->arch.perdomain_l3_pg);
+            l3_pgentry_t *guest_perdomain =
+                __map_domain_page(d->arch.perdomain_l3_pg);
+
+            l3e_write(&guest_perdomain[PCPU_STACK_SLOT],
+                      idle_perdomain[PCPU_STACK_SLOT]);
+
+            unmap_domain_page(guest_perdomain);
+            unmap_domain_page(idle_perdomain);
+        }
+    }
+
     rc = mapcache_vcpu_init(v);
     if ( rc )
         return rc;
@@ -2031,6 +2051,16 @@ static void __context_switch(struct vcpu *n)
         }
         vcpu_restore_fpu_nonlazy(n, false);
         nd->arch.ctxt_switch->to(n);
+        if ( nd->arch.cpu_stack )
+        {
+            /*
+             * Tear down previous stack mappings and map current pCPU stack.
+             * This is safe because not yet running on 'n' page-tables.
+             */
+            destroy_perdomain_mapping(n, PCPU_STACK_VIRT(0),
+                                      nr_cpu_ids << STACK_ORDER);
+            vcpu_set_stack_mappings(n, cpu, true);
+        }
     }
 
     psr_ctxt_switch_to(nd);
diff --git a/xen/arch/x86/include/asm/config.h b/xen/arch/x86/include/asm/config.h
index af3ff3cb8705..016d6c8b21a9 100644
--- a/xen/arch/x86/include/asm/config.h
+++ b/xen/arch/x86/include/asm/config.h
@@ -168,7 +168,7 @@
 /* Slot 260: per-domain mappings (including map cache). */
 #define PERDOMAIN_VIRT_START    (PML4_ADDR(260))
 #define PERDOMAIN_SLOT_MBYTES   (PML4_ENTRY_BYTES >> (20 + PAGETABLE_ORDER))
-#define PERDOMAIN_SLOTS         3
+#define PERDOMAIN_SLOTS         4
 #define PERDOMAIN_VIRT_SLOT(s)  (PERDOMAIN_VIRT_START + (s) * \
                                  (PERDOMAIN_SLOT_MBYTES << 20))
 /* Slot 4: mirror of per-domain mappings (for compat xlat area accesses). */
@@ -288,6 +288,14 @@ extern unsigned long xen_phys_start;
 #define ARG_XLAT_START(v)        \
     (ARG_XLAT_VIRT_START + ((v)->vcpu_id << ARG_XLAT_VA_SHIFT))
 
+/* Per-CPU stacks area when using ASI. */
+#define PCPU_STACK_SLOT         3
+#define PCPU_STACK_VIRT_START   PERDOMAIN_VIRT_SLOT(PCPU_STACK_SLOT)
+#define PCPU_STACK_VIRT_END     (PCPU_STACK_VIRT_START + \
+                                 (PERDOMAIN_SLOT_MBYTES << 20))
+#define PCPU_STACK_VIRT(cpu)    (PCPU_STACK_VIRT_START + \
+                                 (cpu << STACK_ORDER) * PAGE_SIZE)
+
 #define ELFSIZE 64
 
 #define ARCH_CRASH_SAVE_VMCOREINFO
diff --git a/xen/arch/x86/include/asm/current.h b/xen/arch/x86/include/asm/current.h
index bcec328c9875..4a9776f87a7a 100644
--- a/xen/arch/x86/include/asm/current.h
+++ b/xen/arch/x86/include/asm/current.h
@@ -24,6 +24,11 @@
  * 0 - IST Shadow Stacks (4x 1k, read-only)
  */
 
+static inline bool is_shstk_slot(unsigned int i)
+{
+    return (i == 0 || i == PRIMARY_SHSTK_SLOT);
+}
+
 /*
  * Identify which stack page the stack pointer is on.  Returns an index
  * as per the comment above.
diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h
index a3c75e323cde..f83d2860c0b4 100644
--- a/xen/arch/x86/include/asm/domain.h
+++ b/xen/arch/x86/include/asm/domain.h
@@ -465,6 +465,9 @@ struct arch_domain
     /* Use a per-vCPU root pt, and switch per-domain slot to per-vCPU. */
     bool vcpu_pt;
 
+    /* Use per-CPU mapped stacks. */
+    bool cpu_stack;
+
     /* Emulated devices enabled bitmap. */
     uint32_t emulation_flags;
 } __cacheline_aligned;
diff --git a/xen/arch/x86/include/asm/mm.h b/xen/arch/x86/include/asm/mm.h
index f79d1594fde4..77f31685fd95 100644
--- a/xen/arch/x86/include/asm/mm.h
+++ b/xen/arch/x86/include/asm/mm.h
@@ -519,7 +519,7 @@ extern struct rangeset *mmio_ro_ranges;
 #define compat_pfn_to_cr3(pfn) (((unsigned)(pfn) << 12) | ((unsigned)(pfn) >> 20))
 #define compat_cr3_to_pfn(cr3) (((unsigned)(cr3) >> 12) | ((unsigned)(cr3) << 20))
 
-void memguard_guard_stack(void *p);
+void memguard_guard_stack(void *p, unsigned int cpu);
 void memguard_unguard_stack(void *p);
 
 /*
diff --git a/xen/arch/x86/include/asm/smp.h b/xen/arch/x86/include/asm/smp.h
index c8c79601343d..a356f0bf0a61 100644
--- a/xen/arch/x86/include/asm/smp.h
+++ b/xen/arch/x86/include/asm/smp.h
@@ -79,6 +79,18 @@ extern bool unaccounted_cpus;
 
 void *cpu_alloc_stack(unsigned int cpu);
 
+/*
+ * Setup the per-CPU area stack mappings.
+ *
+ * @v:         vCPU where the mappings are to appear.
+ * @stack_cpu: CPU whose stacks should be mapped.
+ * @map_shstk: create mappings for shadow stack regions.
+ */
+void vcpu_set_stack_mappings(const struct vcpu *v, unsigned int stack_cpu,
+                             bool map_shstk);
+
+#define HAS_ARCH_SMP_CALLFUNC_PREAMBLE
+
 #endif /* !__ASSEMBLY__ */
 
 #endif
diff --git a/xen/arch/x86/include/asm/spec_ctrl.h b/xen/arch/x86/include/asm/spec_ctrl.h
index c58afbaab671..c8943e81befa 100644
--- a/xen/arch/x86/include/asm/spec_ctrl.h
+++ b/xen/arch/x86/include/asm/spec_ctrl.h
@@ -89,6 +89,7 @@ extern uint8_t default_scf;
 extern int8_t opt_xpti_hwdom, opt_xpti_domu;
 
 extern int8_t opt_vcpu_pt_pv, opt_vcpu_pt_hwdom, opt_vcpu_pt_hvm;
+extern int8_t opt_cpu_stack_pv, opt_cpu_stack_hwdom, opt_cpu_stack_hvm;
 
 extern bool cpu_has_bug_l1tf;
 extern int8_t opt_pv_l1tf_hwdom, opt_pv_l1tf_domu;
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 3a637e508ff3..22ee3170b86d 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -87,6 +87,7 @@
  * doing the final put_page(), and remove it from the iommu if so.
  */
 
+#include <xen/cpu.h>
 #include <xen/init.h>
 #include <xen/ioreq.h>
 #include <xen/kernel.h>
@@ -6424,8 +6425,10 @@ int create_perdomain_mapping(struct vcpu *v, unsigned long va,
     return rc;
 }
 
-void populate_perdomain_mapping(const struct vcpu *v, unsigned long va,
-                                mfn_t *mfn, unsigned long nr)
+static void populate_perdomain_mapping_flags(const struct vcpu *v,
+                                             unsigned long va, mfn_t *mfn,
+                                             unsigned long nr,
+                                             unsigned int flags)
 {
     l1_pgentry_t *l1tab = NULL, *pl1e;
     const l3_pgentry_t *l3tab;
@@ -6454,7 +6457,7 @@ void populate_perdomain_mapping(const struct vcpu *v, unsigned long va,
                 ASSERT_UNREACHABLE();
                 free_domheap_page(l1e_get_page(*pl1e));
             }
-            l1e_write(pl1e, l1e_from_mfn(mfn[i], __PAGE_HYPERVISOR_RW));
+            l1e_write(pl1e, l1e_from_mfn(mfn[i], flags));
         }
 
         return;
@@ -6505,7 +6508,7 @@ void populate_perdomain_mapping(const struct vcpu *v, unsigned long va,
             free_domheap_page(l1e_get_page(*pl1e));
         }
 
-        l1e_write(pl1e, l1e_from_mfn(*mfn, __PAGE_HYPERVISOR_RW));
+        l1e_write(pl1e, l1e_from_mfn(*mfn, flags));
     }
 
     unmap_domain_page(l1tab);
@@ -6513,6 +6516,31 @@ void populate_perdomain_mapping(const struct vcpu *v, unsigned long va,
     unmap_domain_page(l3tab);
 }
 
+void populate_perdomain_mapping(const struct vcpu *v, unsigned long va,
+                                mfn_t *mfn, unsigned long nr)
+{
+    populate_perdomain_mapping_flags(v, va, mfn, nr, __PAGE_HYPERVISOR_RW);
+}
+
+void vcpu_set_stack_mappings(const struct vcpu *v, unsigned int stack_cpu,
+                             bool map_shstk)
+{
+    unsigned int i;
+
+    for ( i = 0; i < (1U << STACK_ORDER); i++ )
+    {
+        unsigned int flags = is_shstk_slot(i) ? __PAGE_HYPERVISOR_SHSTK
+                                              : __PAGE_HYPERVISOR_RW;
+        mfn_t mfn = virt_to_mfn(stack_base[stack_cpu] + i * PAGE_SIZE);
+
+        if ( is_shstk_slot(i) && !map_shstk )
+            continue;
+
+        populate_perdomain_mapping_flags(v,
+            PCPU_STACK_VIRT(stack_cpu) + i * PAGE_SIZE, &mfn, 1, flags);
+    }
+}
+
 void destroy_perdomain_mapping(const struct vcpu *v, unsigned long va,
                                unsigned int nr)
 {
@@ -6599,7 +6627,12 @@ void free_perdomain_mappings(struct vcpu *v)
     l3tab = __map_domain_page(d->arch.vcpu_pt ? v->arch.pervcpu_l3_pg
                                               : d->arch.perdomain_l3_pg);
 
-    for ( i = 0; i < PERDOMAIN_SLOTS; ++i)
+    for ( i = 0; i < PERDOMAIN_SLOTS; ++i )
+    {
+        if ( i == PCPU_STACK_SLOT && !d->arch.cpu_stack )
+            /* Without ASI the stack L3e is shared with the idle page-tables. */
+            continue;
+
         if ( l3e_get_flags(l3tab[i]) & _PAGE_PRESENT )
         {
             struct page_info *l2pg = l3e_get_page(l3tab[i]);
@@ -6629,6 +6662,7 @@ void free_perdomain_mappings(struct vcpu *v)
             unmap_domain_page(l2tab);
             free_domheap_page(l2pg);
         }
+    }
 
     unmap_domain_page(l3tab);
     free_domheap_page(d->arch.vcpu_pt ? v->arch.pervcpu_l3_pg
@@ -6637,31 +6671,40 @@ void free_perdomain_mappings(struct vcpu *v)
     v->arch.pervcpu_l3_pg = NULL;
 }
 
-static void write_sss_token(unsigned long *ptr)
+static void write_sss_token(unsigned long *ptr, unsigned long va)
 {
     /*
      * A supervisor shadow stack token is its own linear address, with the
      * busy bit (0) clear.
      */
-    *ptr = (unsigned long)ptr;
+    *ptr = va;
 }
 
-void memguard_guard_stack(void *p)
+void memguard_guard_stack(void *p, unsigned int cpu)
 {
+    unsigned long va =
+        (opt_cpu_stack_hvm || opt_cpu_stack_pv) ? PCPU_STACK_VIRT(cpu)
+                                                : (unsigned long)p;
+
     /* IST Shadow stacks.  4x 1k in stack page 0. */
     if ( IS_ENABLED(CONFIG_XEN_SHSTK) )
     {
-        write_sss_token(p + (IST_MCE * IST_SHSTK_SIZE) - 8);
-        write_sss_token(p + (IST_NMI * IST_SHSTK_SIZE) - 8);
-        write_sss_token(p + (IST_DB  * IST_SHSTK_SIZE) - 8);
-        write_sss_token(p + (IST_DF  * IST_SHSTK_SIZE) - 8);
+        write_sss_token(p + (IST_MCE * IST_SHSTK_SIZE) - 8,
+                        va + (IST_MCE * IST_SHSTK_SIZE) - 8);
+        write_sss_token(p + (IST_NMI * IST_SHSTK_SIZE) - 8,
+                        va + (IST_NMI * IST_SHSTK_SIZE) - 8);
+        write_sss_token(p + (IST_DB  * IST_SHSTK_SIZE) - 8,
+                        va + (IST_DB  * IST_SHSTK_SIZE) - 8);
+        write_sss_token(p + (IST_DF  * IST_SHSTK_SIZE) - 8,
+                        va + (IST_DF  * IST_SHSTK_SIZE) - 8);
     }
     map_pages_to_xen((unsigned long)p, virt_to_mfn(p), 1, PAGE_HYPERVISOR_SHSTK);
 
     /* Primary Shadow Stack.  1x 4k in stack page 5. */
     p += PRIMARY_SHSTK_SLOT * PAGE_SIZE;
+    va += PRIMARY_SHSTK_SLOT * PAGE_SIZE;
     if ( IS_ENABLED(CONFIG_XEN_SHSTK) )
-        write_sss_token(p + PAGE_SIZE - 8);
+        write_sss_token(p + PAGE_SIZE - 8, va + PAGE_SIZE - 8);
 
     map_pages_to_xen((unsigned long)p, virt_to_mfn(p), 1, PAGE_HYPERVISOR_SHSTK);
 }
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 8ebe5a9443f3..d0b2c986962a 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -402,6 +402,11 @@ static void __init init_idle_domain(void)
     scheduler_init();
     set_current(idle_vcpu[0]);
     this_cpu(curr_vcpu) = current;
+    if ( opt_cpu_stack_hvm || opt_cpu_stack_pv )
+        /* Set per-domain slot in the idle page-tables to access stack mappings. */
+        l4e_write(&idle_pg_table[l4_table_offset(PERDOMAIN_VIRT_START)],
+                  l4e_from_page(idle_vcpu[0]->domain->arch.perdomain_l3_pg,
+                                __PAGE_HYPERVISOR_RW));
 }
 
 void srat_detect_node(int cpu)
@@ -896,8 +901,6 @@ static void __init noreturn reinit_bsp_stack(void)
     /* Update SYSCALL trampolines */
     percpu_traps_init();
 
-    stack_base[0] = stack;
-
     rc = setup_cpu_root_pgt(0);
     if ( rc )
         panic("Error %d setting up PV root page table\n", rc);
@@ -1864,10 +1867,6 @@ void asmlinkage __init noreturn __start_xen(void)
 
     system_state = SYS_STATE_boot;
 
-    bsp_stack = cpu_alloc_stack(0);
-    if ( !bsp_stack )
-        panic("No memory for BSP stack\n");
-
     console_init_ring();
     vesa_init();
 
@@ -2050,6 +2049,16 @@ void asmlinkage __init noreturn __start_xen(void)
 
     alternative_branches();
 
+    /*
+     * Alloc the BSP stack closer to the point where the AP ones also get
+     * allocated - and after the speculation mitigations have been initialized.
+     * In order to set up the shadow stack token correctly Xen needs to know
+     * whether per-CPU mapped stacks are being used.
+     */
+    bsp_stack = cpu_alloc_stack(0);
+    if ( !bsp_stack )
+        panic("No memory for BSP stack\n");
+
     /*
      * NB: when running as a PV shim VCPUOP_up/down is wired to the shim
      * physical cpu_add/remove functions, so launch the guest with only
@@ -2155,8 +2164,17 @@ void asmlinkage __init noreturn __start_xen(void)
         info->last_spec_ctrl = default_xen_spec_ctrl;
     }
 
+    stack_base[0] = bsp_stack;
+
     /* Copy the cpu info block, and move onto the BSP stack. */
-    bsp_info = get_cpu_info_from_stack((unsigned long)bsp_stack);
+    if ( opt_cpu_stack_hvm || opt_cpu_stack_pv )
+    {
+        vcpu_set_stack_mappings(idle_vcpu[0], 0, true);
+        bsp_info = get_cpu_info_from_stack(PCPU_STACK_VIRT(0));
+    }
+    else
+        bsp_info = get_cpu_info_from_stack((unsigned long)bsp_stack);
+
     *bsp_info = *info;
 
     asm volatile ("mov %[stk], %%rsp; jmp %c[fn]" ::
diff --git a/xen/arch/x86/smp.c b/xen/arch/x86/smp.c
index 02a6ed7593f3..1b11017d5722 100644
--- a/xen/arch/x86/smp.c
+++ b/xen/arch/x86/smp.c
@@ -9,6 +9,7 @@
  */
 
 #include <xen/cpu.h>
+#include <xen/efi.h>
 #include <xen/irq.h>
 #include <xen/sched.h>
 #include <xen/delay.h>
@@ -27,6 +28,8 @@
 #include <asm/hpet.h>
 #include <asm/setup.h>
 
+#include <asm/spec_ctrl.h>
+
 /* Helper functions to prepare APIC register values. */
 static unsigned int prepare_ICR(unsigned int shortcut, int vector)
 {
@@ -435,3 +438,39 @@ long cf_check cpu_down_helper(void *data)
         ret = cpu_down(cpu);
     return ret;
 }
+
+void arch_smp_pre_callfunc(unsigned int cpu)
+{
+    if ( !opt_cpu_stack_hvm && !opt_cpu_stack_pv )
+        /*
+         * Avoid the unconditional sync_local_execstate() call below if ASI is
+         * not enabled for any domain.
+         */
+        return;
+
+    /*
+     * Sync execution state, so that the page-tables cannot change while
+     * creating or destroying the stack mappings.
+     */
+    sync_local_execstate();
+    if ( cpu == smp_processor_id() || !current->domain->arch.cpu_stack ||
+         /* EFI page-tables have all pCPU stacks mapped. */
+         efi_rs_using_pgtables() )
+        return;
+
+    vcpu_set_stack_mappings(current, cpu, false);
+}
+
+void arch_smp_post_callfunc(unsigned int cpu)
+{
+    if ( cpu == smp_processor_id() || !current->domain->arch.cpu_stack ||
+         /* EFI page-tables have all pCPU stacks mapped. */
+         efi_rs_using_pgtables() )
+        return;
+
+    ASSERT(current == this_cpu(curr_vcpu));
+    destroy_perdomain_mapping(current, PCPU_STACK_VIRT(cpu),
+                              (1U << STACK_ORDER));
+
+    flush_area_local((void *)PCPU_STACK_VIRT(cpu), FLUSH_ORDER(STACK_ORDER));
+}
diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index a740a6402272..515ab3cb9c75 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -582,7 +582,21 @@ static int do_boot_cpu(int apicid, int cpu)
         printk("Booting processor %d/%d eip %lx\n",
                cpu, apicid, start_eip);
 
-    stack_start = stack_base[cpu] + STACK_SIZE - sizeof(struct cpu_info);
+    if ( opt_cpu_stack_hvm || opt_cpu_stack_pv )
+    {
+        /*
+         * Uniformly run with the stack mappings in the per-domain area if ASI
+         * is enabled for any domain type.
+         */
+        vcpu_set_stack_mappings(idle_vcpu[cpu], cpu, true);
+
+        ASSERT(IS_ALIGNED(PCPU_STACK_VIRT(cpu), STACK_SIZE));
+
+        stack_start = (void *)PCPU_STACK_VIRT(cpu) + STACK_SIZE -
+                      sizeof(struct cpu_info);
+    }
+    else
+        stack_start = stack_base[cpu] + STACK_SIZE - sizeof(struct cpu_info);
 
     /* This grunge runs the startup process for the targeted processor. */
 
@@ -1030,7 +1044,7 @@ void *cpu_alloc_stack(unsigned int cpu)
     stack = alloc_xenheap_pages(STACK_ORDER, memflags);
 
     if ( stack )
-        memguard_guard_stack(stack);
+        memguard_guard_stack(stack, cpu);
 
     return stack;
 }
@@ -1146,6 +1160,8 @@ static struct notifier_block cpu_smpboot_nfb = {
 
 void __init smp_prepare_cpus(void)
 {
+    BUILD_BUG_ON(PCPU_STACK_VIRT(CONFIG_NR_CPUS) > PCPU_STACK_VIRT_END);
+
     register_cpu_notifier(&cpu_smpboot_nfb);
 
     mtrr_aps_sync_begin();
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index 9463a8624701..4f1e912f8057 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -89,6 +89,10 @@ bool __ro_after_init opt_bp_spec_reduce = true;
 int8_t __ro_after_init opt_vcpu_pt_hvm = -1;
 int8_t __ro_after_init opt_vcpu_pt_hwdom = -1;
 int8_t __ro_after_init opt_vcpu_pt_pv = -1;
+/* Per-CPU stacks. */
+int8_t __ro_after_init opt_cpu_stack_hvm = -1;
+int8_t __ro_after_init opt_cpu_stack_hwdom = -1;
+int8_t __ro_after_init opt_cpu_stack_pv = -1;
 
 static int __init cf_check parse_spec_ctrl(const char *s)
 {
@@ -395,6 +399,7 @@ static __init void xpti_init_default(void)
         printk(XENLOG_ERR
                "XPTI incompatible with per-vCPU page-tables, disabling ASI\n");
         opt_vcpu_pt_pv = 0;
+        opt_cpu_stack_pv = 0;
     }
     if ( (boot_cpu_data.x86_vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON)) ||
          cpu_has_rdcl_no )
@@ -507,7 +512,10 @@ static int __init cf_check parse_asi(const char *s)
 
     /* Interpret 'asi' alone in its positive boolean form. */
     if ( *s == '\0' )
+    {
         opt_vcpu_pt_pv = opt_vcpu_pt_hwdom = opt_vcpu_pt_hvm = 1;
+        opt_cpu_stack_pv = opt_cpu_stack_hwdom = opt_cpu_stack_hvm = 1;
+    }
 
     do {
         ss = strchr(s, ',');
@@ -520,13 +528,14 @@ static int __init cf_check parse_asi(const char *s)
         case 0:
         case 1:
             opt_vcpu_pt_pv = opt_vcpu_pt_hwdom = opt_vcpu_pt_hvm = val;
+            opt_cpu_stack_pv = opt_cpu_stack_hvm = opt_cpu_stack_hwdom = val;
             break;
 
         default:
             if ( (val = parse_boolean("pv", s, ss)) >= 0 )
-                opt_vcpu_pt_pv = val;
+                opt_cpu_stack_pv = opt_vcpu_pt_pv = val;
             else if ( (val = parse_boolean("hvm", s, ss)) >= 0 )
-                opt_vcpu_pt_hvm = val;
+                opt_cpu_stack_hvm = opt_vcpu_pt_hvm = val;
             else if ( (val = parse_boolean("vcpu-pt", s, ss)) != -1 )
             {
                 switch ( val )
@@ -548,6 +557,28 @@ static int __init cf_check parse_asi(const char *s)
                     break;
                 }
             }
+            else if ( (val = parse_boolean("cpu-stack", s, ss)) != -1 )
+            {
+                switch ( val )
+                {
+                case 1:
+                case 0:
+                    opt_cpu_stack_pv = opt_cpu_stack_hvm =
+                        opt_cpu_stack_hwdom = val;
+                    break;
+
+                case -2:
+                    s += strlen("cpu-stack=");
+                    if ( (val = parse_boolean("pv", s, ss)) >= 0 )
+                        opt_cpu_stack_pv = val;
+                    else if ( (val = parse_boolean("hvm", s, ss)) >= 0 )
+                        opt_cpu_stack_hvm = val;
+                    else
+                default:
+                        rc = -EINVAL;
+                    break;
+                }
+            }
             else if ( *s )
                 rc = -EINVAL;
             break;
@@ -556,6 +587,14 @@ static int __init cf_check parse_asi(const char *s)
         s = ss + 1;
     } while ( *ss );
 
+    /* Per-CPU stacks depends on per-vCPU mappings. */
+    if ( opt_cpu_stack_pv == 1 )
+        opt_vcpu_pt_pv = 1;
+    if ( opt_cpu_stack_hvm == 1 )
+        opt_vcpu_pt_hvm = 1;
+    if ( opt_cpu_stack_hwdom == 1 )
+        opt_vcpu_pt_hwdom = 1;
+
     return rc;
 }
 custom_param("asi", parse_asi);
@@ -752,16 +791,17 @@ static void __init print_details(enum ind_thunk thunk)
 #endif
 
 #ifdef CONFIG_HVM
-    printk("  ASI features for HVM VMs:%s%s\n",
-           opt_vcpu_pt_hvm                           ? ""               : " None",
-           opt_vcpu_pt_hvm                           ? " vCPU-PT"       : "");
+    printk("  ASI features for HVM VMs:%s%s%s\n",
+           opt_vcpu_pt_hvm || opt_cpu_stack_hvm      ? ""               : " None",
+           opt_vcpu_pt_hvm                           ? " vCPU-PT"       : "",
+           opt_cpu_stack_hvm                         ? " CPU-STACK"     : "");
 
 #endif
 #ifdef CONFIG_PV
-    printk("  ASI features for PV VMs:%s%s\n",
-           opt_vcpu_pt_pv                            ? ""               : " None",
-           opt_vcpu_pt_pv                            ? " vCPU-PT"       : "");
-
+    printk("  ASI features for PV VMs:%s%s%s\n",
+           opt_vcpu_pt_pv || opt_cpu_stack_pv        ? ""               : " None",
+           opt_vcpu_pt_pv                            ? " vCPU-PT"       : "",
+           opt_cpu_stack_pv                          ? " CPU-STACK"     : "");
 #endif
 }
 
@@ -1869,6 +1909,9 @@ void spec_ctrl_init_domain(struct domain *d)
     d->arch.vcpu_pt = is_hardware_domain(d) ? opt_vcpu_pt_hwdom
                                             : pv ? opt_vcpu_pt_pv
                                                  : opt_vcpu_pt_hvm;
+    d->arch.cpu_stack = is_hardware_domain(d) ? opt_cpu_stack_hwdom
+                                              : pv ? opt_cpu_stack_pv
+                                                   : opt_cpu_stack_hvm;
 }
 
 void __init init_speculation_mitigations(void)
@@ -2172,6 +2215,12 @@ void __init init_speculation_mitigations(void)
         opt_vcpu_pt_hwdom = 0;
     if ( opt_vcpu_pt_hvm == -1 )
         opt_vcpu_pt_hvm = 0;
+    if ( opt_cpu_stack_pv == -1 )
+        opt_cpu_stack_pv = 0;
+    if ( opt_cpu_stack_hwdom == -1 )
+        opt_cpu_stack_hwdom = 0;
+    if ( opt_cpu_stack_hvm == -1 )
+        opt_cpu_stack_hvm = 0;
 
     if ( opt_vcpu_pt_pv || opt_vcpu_pt_hvm )
         warning_add(
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index a7f6fb611c34..c80ef2268e94 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -74,6 +74,7 @@
 #include <asm/pv/trace.h>
 #include <asm/pv/mm.h>
 #include <asm/shstk.h>
+#include <asm/spec_ctrl.h>
 
 /*
  * opt_nmi: one of 'ignore', 'dom0', or 'fatal'.
@@ -609,10 +610,13 @@ void show_stack_overflow(unsigned int cpu, const struct cpu_user_regs *regs)
     unsigned long esp = regs->rsp;
     unsigned long curr_stack_base = esp & ~(STACK_SIZE - 1);
     unsigned long esp_top, esp_bottom;
+    const void *stack =
+        (opt_cpu_stack_hvm || opt_cpu_stack_pv) ? (void *)PCPU_STACK_VIRT(cpu)
+                                                : stack_base[cpu];
 
-    if ( _p(curr_stack_base) != stack_base[cpu] )
+    if ( _p(curr_stack_base) != stack )
         printk("Current stack base %p differs from expected %p\n",
-               _p(curr_stack_base), stack_base[cpu]);
+               _p(curr_stack_base), stack);
 
     esp_bottom = (esp | (STACK_SIZE - 1)) + 1;
     esp_top    = esp_bottom - PRIMARY_STACK_SIZE;
diff --git a/xen/common/smp.c b/xen/common/smp.c
index a011f541f1ea..04f5aede0d3d 100644
--- a/xen/common/smp.c
+++ b/xen/common/smp.c
@@ -29,6 +29,7 @@ static struct call_data_struct {
     void (*func) (void *info);
     void *info;
     int wait;
+    unsigned int caller;
     cpumask_t selected;
 } call_data;
 
@@ -63,6 +64,7 @@ void on_selected_cpus(
     call_data.func = func;
     call_data.info = info;
     call_data.wait = wait;
+    call_data.caller = smp_processor_id();
 
     smp_send_call_function_mask(&call_data.selected);
 
@@ -82,6 +84,12 @@ void smp_call_function_interrupt(void)
     if ( !cpumask_test_cpu(cpu, &call_data.selected) )
         return;
 
+    /*
+     * TODO: use bounce buffers to pass callfunc data, so that when using ASI
+     * there's no need to map remote CPU stacks.
+     */
+    arch_smp_pre_callfunc(call_data.caller);
+
     irq_enter();
 
     if ( unlikely(!func) )
@@ -102,6 +110,8 @@ void smp_call_function_interrupt(void)
     }
 
     irq_exit();
+
+    arch_smp_post_callfunc(call_data.caller);
 }
 
 /*
diff --git a/xen/common/stop_machine.c b/xen/common/stop_machine.c
index 398cfd507c10..142059c36374 100644
--- a/xen/common/stop_machine.c
+++ b/xen/common/stop_machine.c
@@ -40,6 +40,7 @@ enum stopmachine_state {
 
 struct stopmachine_data {
     unsigned int nr_cpus;
+    unsigned int caller;
 
     enum stopmachine_state state;
     atomic_t done;
@@ -104,6 +105,7 @@ int stop_machine_run(int (*fn)(void *data), void *data, unsigned int cpu)
     stopmachine_data.fn_result = 0;
     atomic_set(&stopmachine_data.done, 0);
     stopmachine_data.state = STOPMACHINE_START;
+    stopmachine_data.caller = this;
 
     smp_wmb();
 
@@ -148,6 +150,12 @@ static void cf_check stopmachine_action(void *data)
 
     BUG_ON(cpu != smp_processor_id());
 
+    /*
+     * TODO: use bounce buffers to pass callfunc data, so that when using ASI
+     * there's no need to map remote CPU stacks.
+     */
+    arch_smp_pre_callfunc(stopmachine_data.caller);
+
     smp_mb();
 
     while ( state != STOPMACHINE_EXIT )
@@ -180,6 +188,8 @@ static void cf_check stopmachine_action(void *data)
     }
 
     local_irq_enable();
+
+    arch_smp_post_callfunc(stopmachine_data.caller);
 }
 
 static int cf_check cpu_callback(
diff --git a/xen/include/xen/smp.h b/xen/include/xen/smp.h
index 2ca9ff1bfcc1..a25d47e29dce 100644
--- a/xen/include/xen/smp.h
+++ b/xen/include/xen/smp.h
@@ -76,4 +76,12 @@ extern void *stack_base[NR_CPUS];
 void initialize_cpu_data(unsigned int cpu);
 int setup_cpu_root_pgt(unsigned int cpu);
 
+#ifdef HAS_ARCH_SMP_CALLFUNC_PREAMBLE
+void arch_smp_pre_callfunc(unsigned int cpu);
+void arch_smp_post_callfunc(unsigned int cpu);
+#else
+static inline void arch_smp_pre_callfunc(unsigned int cpu) {}
+static inline void arch_smp_post_callfunc(unsigned int cpu) {}
+#endif
+
 #endif /* __XEN_SMP_H__ */
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 14:43:25 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 14:43:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867406.1278937 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXHI-00074t-73; Wed, 08 Jan 2025 14:43:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867406.1278937; Wed, 08 Jan 2025 14:43:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXHI-00074m-42; Wed, 08 Jan 2025 14:43:24 +0000
Received: by outflank-mailman (input) for mailman id 867406;
 Wed, 08 Jan 2025 14:43:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=2h7L=UA=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tVX57-0005q4-CO
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 14:30:49 +0000
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
 [2a00:1450:4864:20::531])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 25e61f95-cdcd-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 15:30:46 +0100 (CET)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-5d3f57582a2so1798773a12.1
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 06:30:46 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0e8953c1sm2481149366b.49.2025.01.08.06.30.44
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 06:30:44 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 25e61f95-cdcd-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736346645; x=1736951445; 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=5Dahf1Hb4Q67tI5YmT94pkmM93oygaKDXzYWEQbTe0s=;
        b=g+tYZTqen8oeW5OOEBIz3+GqmNxTfiUFlct9kOvMBIbUQoZHAQg/T1TC3Ofz7ftVJI
         mtLPks4LcQWGxOWNyUk20q+cCJ6j+gtCNrSLKW3OnMxDHZJWj5ww+6GisZ6mashPLhKg
         yrky0UPi/KTRO9SfLrGisPv1HULCTC6LBdGdQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736346645; x=1736951445;
        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=5Dahf1Hb4Q67tI5YmT94pkmM93oygaKDXzYWEQbTe0s=;
        b=B2vMb8lpSmE2VVjAl/VpS8JdV55VSbVEdSAeB0hrWdIVvj2kbSPhZ0QTWCtnYTSGGp
         9rYeRPDXzQZEk8ubF1Ziu3D8e3n/Uy1rC73IW3Jltqt83I1i2/p2kUvD84GeHKaN49IW
         8dBWOddOx9ow2ihJHWh6H26dt78ETpqfwEoO72n4Jy3YuXu4hNslYYY/IU4B64hLDHrN
         /qYAsMWYOURUAEyDlum87wj4KB8kRKuIRujHqItvQWKxF5X1CwcxIOxbvblCy9Q9ZTb5
         ux5Op3o7SxZQCSq06bdtjZgL5F/qRyclnPEbD38rtrSq5HG+64rf/H/Bvc5zgdRlBrqO
         SNFg==
X-Gm-Message-State: AOJu0YwWB+x/1A+SMjxRfiM9ytXnQSDGXmZWrXKn6dSmYluSNbHQHzGS
	5t/c9umHsJ8Kz+h84NA5347XF6owQLsCIi4krw9Omt6RHd7OLR99Juz8sqzjwRrxdXHgohhmANt
	r
X-Gm-Gg: ASbGncspWT+C6B6YOaX3K+kj3MJ+S455X6ONNZBySkpMKDAEKOnIMTHv98/UWuiyUw9
	lvYyNl6FqoqN51C941Lo+glA/caN5JAoF6IIws7ii+ETYKreF4xlprpsBM9VxY48AT6rknCHML/
	yvrXXcss46JzOq3xj3sr8O6YtcKpvRWj2y80LBQXn4UOpLe8ZmN9UUCNV0WbEguG4dyJ+bmpsqP
	4Dt021RArNog2ND7HY0rSqUxIksyAuXsPrH2czaf2pLi6ijbp1gcNvGeCXbYHkxDB8=
X-Google-Smtp-Source: AGHT+IGP0vEQMmGyG5hs0irconu+soKU5qBQE3llgM2KKNLjJr/T1WL+zjMdi3anWl9Peh/g+hQixQ==
X-Received: by 2002:a17:907:6d1e:b0:aa6:bedc:2e4c with SMTP id a640c23a62f3a-ab28fd1c12amr726461466b.3.1736346645132;
        Wed, 08 Jan 2025 06:30:45 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v2 18/18] x86/mm: zero stack on context switch
Date: Wed,  8 Jan 2025 15:26:58 +0100
Message-ID: <20250108142659.99490-19-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250108142659.99490-1-roger.pau@citrix.com>
References: <20250108142659.99490-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

With the stack mapped on a per-CPU basis there's no risk of other CPUs being
able to read the stack contents, but vCPUs running on the current pCPU could
read stack rubble from operations of previous vCPUs.

The #DF stack is not zeroed because handling of #DF results in a panic.

The contents of the shadow stack are not cleared as part of this change.  It's
arguable that leaking internal Xen return addresses is not guest confidential
data.  At most those could be used by an attacker to figure out the paths
inside of Xen previous execution flows have used.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Is it required to zero the stack when doing a non-lazy context switch from the
idle vPCU to the previously running vCPU?

d0v0 -> IDLE -> sync_execstate -> zero stack? -> d0v0

This is currently done in this proposal, as when running in the idle vCPU
context (iow: not lazy switched) stacks from remote pCPUs can be mapped or
tasklets executed.
---
Changes since v1:
 - Zero the stack forward to use ERMS.
 - Only zero the IST stacks if they have been used.
 - Only zero the primary stack for full context switches.
---
 docs/misc/xen-command-line.pandoc    |  4 +-
 xen/arch/x86/cpu/mcheck/mce.c        |  4 ++
 xen/arch/x86/domain.c                | 13 ++++++-
 xen/arch/x86/include/asm/current.h   | 53 +++++++++++++++++++++++---
 xen/arch/x86/include/asm/domain.h    |  3 ++
 xen/arch/x86/include/asm/spec_ctrl.h |  1 +
 xen/arch/x86/spec_ctrl.c             | 57 ++++++++++++++++++++++++----
 xen/arch/x86/traps.c                 |  5 +++
 8 files changed, 124 insertions(+), 16 deletions(-)

diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index e7828d092098..9cde9e84aff2 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -204,7 +204,7 @@ to appropriate auditing by Xen.  Argo is disabled by default.
 
 ### asi (x86)
 > `= List of [ <bool>, {pv,hvm}=<bool>,
-               {vcpu-pt,cpu-stack}=<bool>|{pv,hvm}=<bool> ]`
+               {vcpu-pt,cpu-stack,zero-stack}=<bool>|{pv,hvm}=<bool> ]`
 
 Offers control over whether the hypervisor will engage in Address Space
 Isolation, by not having potentially sensitive information permanently mapped
@@ -224,6 +224,8 @@ meant to be used for debugging purposes only.**
 * `cpu-stack` prevent CPUs from having permanent mappings of stacks different
   than their own.  Depends on the `vcpu-pt` option.
 
+* `zero-stack` zero CPU stacks when context switching vCPUs.
+
 ### asid (x86)
 > `= <boolean>`
 
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index 9028ccde5477..eaaaefe7f8ba 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -92,10 +92,14 @@ struct mce_callbacks __ro_after_init mce_callbacks = {
 static const typeof(mce_callbacks.handler) __initconst_cf_clobber __used
     default_handler = unexpected_machine_check;
 
+DEFINE_PER_CPU(unsigned int, slice_mce_count);
+
 /* Call the installed machine check handler for this CPU setup. */
 
 void do_machine_check(const struct cpu_user_regs *regs)
 {
+    this_cpu(slice_mce_count)++;
+
     mce_enter();
     alternative_vcall(mce_callbacks.handler, regs);
     mce_exit();
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index ac6332266e95..1ff9200eb081 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -2106,6 +2106,7 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
     struct cpu_info *info = get_cpu_info();
     const struct domain *prevd = prev->domain, *nextd = next->domain;
     unsigned int dirty_cpu = read_atomic(&next->dirty_cpu);
+    bool lazy = false;
 
     ASSERT(prev != next);
     ASSERT(local_irq_is_enabled());
@@ -2138,6 +2139,7 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
          */
         set_current(next);
         local_irq_enable();
+        lazy = true;
     }
     else
     {
@@ -2212,12 +2214,19 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
     /* Ensure that the vcpu has an up-to-date time base. */
     update_vcpu_system_time(next);
 
-    reset_stack_and_call_ind(nextd->arch.ctxt_switch->tail);
+    /*
+     * Context switches to the idle vCPU (either lazy or full) will never
+     * trigger zeroing of the stack, because the idle domain doesn't have ASI
+     * enabled.  Switching back to the previously running vCPU after a lazy
+     * switch shouldn't zero the stack either.
+     */
+    reset_stack_and_call_ind(nextd->arch.ctxt_switch->tail,
+                             !lazy && nextd->arch.zero_stack);
 }
 
 void continue_running(struct vcpu *same)
 {
-    reset_stack_and_call_ind(same->domain->arch.ctxt_switch->tail);
+    reset_stack_and_call_ind(same->domain->arch.ctxt_switch->tail, false);
 }
 
 int __sync_local_execstate(void)
diff --git a/xen/arch/x86/include/asm/current.h b/xen/arch/x86/include/asm/current.h
index 4a9776f87a7a..9abb4e55aeea 100644
--- a/xen/arch/x86/include/asm/current.h
+++ b/xen/arch/x86/include/asm/current.h
@@ -170,6 +170,12 @@ unsigned long get_stack_dump_bottom (unsigned long sp);
 # define SHADOW_STACK_WORK ""
 #endif
 
+#define ZERO_STACK                                              \
+    "test %[stk_size], %[stk_size];"                            \
+    "jz .L_skip_zeroing.%=;"                                    \
+    "rep stosb;"                                                \
+    ".L_skip_zeroing.%=:"
+
 #if __GNUC__ >= 9
 # define ssaj_has_attr_noreturn(fn) __builtin_has_attribute(fn, __noreturn__)
 #else
@@ -177,13 +183,43 @@ unsigned long get_stack_dump_bottom (unsigned long sp);
 # define ssaj_has_attr_noreturn(fn) true
 #endif
 
-#define switch_stack_and_jump(fn, instr, constr)                        \
+DECLARE_PER_CPU(unsigned int, slice_mce_count);
+DECLARE_PER_CPU(unsigned int, slice_nmi_count);
+DECLARE_PER_CPU(unsigned int, slice_db_count);
+
+#define switch_stack_and_jump(fn, instr, constr, zero_stk)              \
     ({                                                                  \
         unsigned int tmp;                                               \
+                                                                        \
         BUILD_BUG_ON(!ssaj_has_attr_noreturn(fn));                      \
+        ASSERT(IS_ALIGNED((unsigned long)guest_cpu_user_regs() -        \
+                          PRIMARY_STACK_SIZE +                          \
+                          sizeof(struct cpu_info), PAGE_SIZE));         \
+        if ( zero_stk )                                                 \
+        {                                                               \
+            unsigned long stack_top = get_stack_bottom() &              \
+                                      ~(STACK_SIZE - 1);                \
+                                                                        \
+            if ( this_cpu(slice_mce_count) )                            \
+            {                                                           \
+                this_cpu(slice_mce_count) = 0;                          \
+                clear_page((void *)stack_top + IST_MCE * PAGE_SIZE);    \
+            }                                                           \
+            if ( this_cpu(slice_nmi_count) )                            \
+            {                                                           \
+                this_cpu(slice_nmi_count) = 0;                          \
+                clear_page((void *)stack_top + IST_NMI * PAGE_SIZE);    \
+            }                                                           \
+            if ( this_cpu(slice_db_count) )                             \
+            {                                                           \
+                this_cpu(slice_db_count) = 0;                           \
+                clear_page((void *)stack_top + IST_DB  * PAGE_SIZE);    \
+            }                                                           \
+        }                                                               \
         __asm__ __volatile__ (                                          \
             SHADOW_STACK_WORK                                           \
             "mov %[stk], %%rsp;"                                        \
+            ZERO_STACK                                                  \
             CHECK_FOR_LIVEPATCH_WORK                                    \
             instr "[fun]"                                               \
             : [val] "=&r" (tmp),                                        \
@@ -194,19 +230,26 @@ unsigned long get_stack_dump_bottom (unsigned long sp);
               ((PRIMARY_SHSTK_SLOT + 1) * PAGE_SIZE - 8),               \
               [stack_mask] "i" (STACK_SIZE - 1),                        \
               _ASM_BUGFRAME_INFO(BUGFRAME_bug, __LINE__,                \
-                                 __FILE__, NULL)                        \
+                                 __FILE__, NULL),                       \
+              /* For stack zeroing. */                                  \
+              "D" ((void *)guest_cpu_user_regs() -                      \
+                   PRIMARY_STACK_SIZE + sizeof(struct cpu_info)),       \
+              [stk_size] "c"                                            \
+              ((zero_stk) ? PRIMARY_STACK_SIZE - sizeof(struct cpu_info)\
+                          : 0),                                         \
+              "a" (0)                                                   \
             : "memory" );                                               \
         unreachable();                                                  \
     })
 
 #define reset_stack_and_jump(fn)                                        \
-    switch_stack_and_jump(fn, "jmp %c", "i")
+    switch_stack_and_jump(fn, "jmp %c", "i", false)
 
 /* The constraint may only specify non-call-clobbered registers. */
-#define reset_stack_and_call_ind(fn)                                    \
+#define reset_stack_and_call_ind(fn, zero_stk)                          \
     ({                                                                  \
         (void)((fn) == (void (*)(void))NULL);                           \
-        switch_stack_and_jump(fn, "INDIRECT_CALL %", "b");              \
+        switch_stack_and_jump(fn, "INDIRECT_CALL %", "b", zero_stk);    \
     })
 
 /*
diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h
index f83d2860c0b4..c2cbd73a42b4 100644
--- a/xen/arch/x86/include/asm/domain.h
+++ b/xen/arch/x86/include/asm/domain.h
@@ -468,6 +468,9 @@ struct arch_domain
     /* Use per-CPU mapped stacks. */
     bool cpu_stack;
 
+    /* Zero CPU stack on non lazy context switch. */
+    bool zero_stack;
+
     /* Emulated devices enabled bitmap. */
     uint32_t emulation_flags;
 } __cacheline_aligned;
diff --git a/xen/arch/x86/include/asm/spec_ctrl.h b/xen/arch/x86/include/asm/spec_ctrl.h
index c8943e81befa..c335c5eca35d 100644
--- a/xen/arch/x86/include/asm/spec_ctrl.h
+++ b/xen/arch/x86/include/asm/spec_ctrl.h
@@ -90,6 +90,7 @@ extern int8_t opt_xpti_hwdom, opt_xpti_domu;
 
 extern int8_t opt_vcpu_pt_pv, opt_vcpu_pt_hwdom, opt_vcpu_pt_hvm;
 extern int8_t opt_cpu_stack_pv, opt_cpu_stack_hwdom, opt_cpu_stack_hvm;
+extern int8_t opt_zero_stack_pv, opt_zero_stack_hwdom, opt_zero_stack_hvm;
 
 extern bool cpu_has_bug_l1tf;
 extern int8_t opt_pv_l1tf_hwdom, opt_pv_l1tf_domu;
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index 4f1e912f8057..edae4b802e67 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -93,6 +93,10 @@ int8_t __ro_after_init opt_vcpu_pt_pv = -1;
 int8_t __ro_after_init opt_cpu_stack_hvm = -1;
 int8_t __ro_after_init opt_cpu_stack_hwdom = -1;
 int8_t __ro_after_init opt_cpu_stack_pv = -1;
+/* Zero CPU stacks. */
+int8_t __ro_after_init opt_zero_stack_hvm = -1;
+int8_t __ro_after_init opt_zero_stack_hwdom = -1;
+int8_t __ro_after_init opt_zero_stack_pv = -1;
 
 static int __init cf_check parse_spec_ctrl(const char *s)
 {
@@ -515,6 +519,7 @@ static int __init cf_check parse_asi(const char *s)
     {
         opt_vcpu_pt_pv = opt_vcpu_pt_hwdom = opt_vcpu_pt_hvm = 1;
         opt_cpu_stack_pv = opt_cpu_stack_hwdom = opt_cpu_stack_hvm = 1;
+        opt_zero_stack_pv = opt_zero_stack_hvm = opt_zero_stack_hwdom = 1;
     }
 
     do {
@@ -529,13 +534,14 @@ static int __init cf_check parse_asi(const char *s)
         case 1:
             opt_vcpu_pt_pv = opt_vcpu_pt_hwdom = opt_vcpu_pt_hvm = val;
             opt_cpu_stack_pv = opt_cpu_stack_hvm = opt_cpu_stack_hwdom = val;
+            opt_zero_stack_pv = opt_zero_stack_hvm = opt_zero_stack_hwdom = val;
             break;
 
         default:
             if ( (val = parse_boolean("pv", s, ss)) >= 0 )
-                opt_cpu_stack_pv = opt_vcpu_pt_pv = val;
+                opt_zero_stack_pv = opt_cpu_stack_pv = opt_vcpu_pt_pv = val;
             else if ( (val = parse_boolean("hvm", s, ss)) >= 0 )
-                opt_cpu_stack_hvm = opt_vcpu_pt_hvm = val;
+                opt_zero_stack_hvm = opt_cpu_stack_hvm = opt_vcpu_pt_hvm = val;
             else if ( (val = parse_boolean("vcpu-pt", s, ss)) != -1 )
             {
                 switch ( val )
@@ -579,6 +585,28 @@ static int __init cf_check parse_asi(const char *s)
                     break;
                 }
             }
+            else if ( (val = parse_boolean("zero-stack", s, ss)) != -1 )
+            {
+                switch ( val )
+                {
+                case 1:
+                case 0:
+                    opt_zero_stack_pv = opt_zero_stack_hvm =
+                        opt_zero_stack_hwdom = val;
+                    break;
+
+                case -2:
+                    s += strlen("zero-stack=");
+                    if ( (val = parse_boolean("pv", s, ss)) >= 0 )
+                        opt_zero_stack_pv = val;
+                    else if ( (val = parse_boolean("hvm", s, ss)) >= 0 )
+                        opt_zero_stack_hvm = val;
+                    else
+                default:
+                        rc = -EINVAL;
+                    break;
+                }
+            }
             else if ( *s )
                 rc = -EINVAL;
             break;
@@ -791,17 +819,21 @@ static void __init print_details(enum ind_thunk thunk)
 #endif
 
 #ifdef CONFIG_HVM
-    printk("  ASI features for HVM VMs:%s%s%s\n",
-           opt_vcpu_pt_hvm || opt_cpu_stack_hvm      ? ""               : " None",
+    printk("  ASI features for HVM VMs:%s%s%s%s\n",
+           opt_vcpu_pt_hvm || opt_cpu_stack_hvm ||
+           opt_zero_stack_hvm                        ? ""               : " None",
            opt_vcpu_pt_hvm                           ? " vCPU-PT"       : "",
-           opt_cpu_stack_hvm                         ? " CPU-STACK"     : "");
+           opt_cpu_stack_hvm                         ? " CPU-STACK"     : "",
+           opt_zero_stack_hvm                        ? " ZERO-STACK"    : "");
 
 #endif
 #ifdef CONFIG_PV
-    printk("  ASI features for PV VMs:%s%s%s\n",
-           opt_vcpu_pt_pv || opt_cpu_stack_pv        ? ""               : " None",
+    printk("  ASI features for PV VMs:%s%s%s%s\n",
+           opt_vcpu_pt_pv || opt_cpu_stack_pv ||
+           opt_zero_stack_pv                         ? ""               : " None",
            opt_vcpu_pt_pv                            ? " vCPU-PT"       : "",
-           opt_cpu_stack_pv                          ? " CPU-STACK"     : "");
+           opt_cpu_stack_pv                          ? " CPU-STACK"     : "",
+           opt_zero_stack_pv                         ? " ZERO-STACK"    : "");
 #endif
 }
 
@@ -1912,6 +1944,9 @@ void spec_ctrl_init_domain(struct domain *d)
     d->arch.cpu_stack = is_hardware_domain(d) ? opt_cpu_stack_hwdom
                                               : pv ? opt_cpu_stack_pv
                                                    : opt_cpu_stack_hvm;
+    d->arch.zero_stack = is_hardware_domain(d) ? opt_zero_stack_hwdom
+                                               : pv ? opt_zero_stack_pv
+                                                    : opt_zero_stack_hvm;
 }
 
 void __init init_speculation_mitigations(void)
@@ -2221,6 +2256,12 @@ void __init init_speculation_mitigations(void)
         opt_cpu_stack_hwdom = 0;
     if ( opt_cpu_stack_hvm == -1 )
         opt_cpu_stack_hvm = 0;
+    if ( opt_zero_stack_pv == -1 )
+        opt_zero_stack_pv = 0;
+    if ( opt_zero_stack_hwdom == -1 )
+        opt_zero_stack_hwdom = 0;
+    if ( opt_zero_stack_hvm == -1 )
+        opt_zero_stack_hvm = 0;
 
     if ( opt_vcpu_pt_pv || opt_vcpu_pt_hvm )
         warning_add(
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index c80ef2268e94..2aa53550e8e6 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1792,6 +1792,7 @@ static void unknown_nmi_error(const struct cpu_user_regs *regs,
 static nmi_callback_t *__read_mostly nmi_callback;
 
 DEFINE_PER_CPU(unsigned int, nmi_count);
+DEFINE_PER_CPU(unsigned int, slice_nmi_count);
 
 void do_nmi(const struct cpu_user_regs *regs)
 {
@@ -1801,6 +1802,7 @@ void do_nmi(const struct cpu_user_regs *regs)
     bool handle_unknown = false;
 
     this_cpu(nmi_count)++;
+    this_cpu(slice_nmi_count)++;
     nmi_enter();
 
     /*
@@ -1919,6 +1921,8 @@ void asmlinkage do_device_not_available(struct cpu_user_regs *regs)
 
 void nocall sysenter_eflags_saved(void);
 
+DEFINE_PER_CPU(unsigned int, slice_db_count);
+
 void asmlinkage do_debug(struct cpu_user_regs *regs)
 {
     unsigned long dr6;
@@ -1927,6 +1931,7 @@ void asmlinkage do_debug(struct cpu_user_regs *regs)
     /* Stash dr6 as early as possible. */
     dr6 = read_debugreg(6);
 
+    this_cpu(slice_db_count)++;
     /*
      * At the time of writing (March 2018), on the subject of %dr6:
      *
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 14:43:32 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 14:43:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867408.1278947 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXHQ-0007Rf-EM; Wed, 08 Jan 2025 14:43:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867408.1278947; Wed, 08 Jan 2025 14:43:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXHQ-0007RY-Bg; Wed, 08 Jan 2025 14:43:32 +0000
Received: by outflank-mailman (input) for mailman id 867408;
 Wed, 08 Jan 2025 14:43:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=2h7L=UA=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tVX4z-0005q4-AA
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 14:30:41 +0000
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [2a00:1450:4864:20::62c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 216c9d2a-cdcd-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 15:30:38 +0100 (CET)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-aa679ad4265so176181966b.0
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 06:30:38 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0f06deb8sm2476322266b.190.2025.01.08.06.30.36
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 06:30:36 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 216c9d2a-cdcd-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736346637; x=1736951437; 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=64UhML0RWOsr//hCManVNWudvxbMgrGePKLAgvzwrso=;
        b=YcugltHiEInC9JtMlReKqHvYYwlyquSaZr4ZHtedJCKh/HKPjITL1XbBYKBkmym18W
         +VEZTddvJ+EoviZRPyy/YbIyj5EE0UY5TSfNYSXAorBydSiagDxH5r3xr6BBx3f8umhG
         7TCD24rrQc2SNSr98neTJb8/I4z02FeC0BwyY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736346637; x=1736951437;
        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=64UhML0RWOsr//hCManVNWudvxbMgrGePKLAgvzwrso=;
        b=E2O7wmSKxSMTf7gJ/oFEPr8QFr2EaajFvgVCcz40y03y3XNDPz6if7f00RanU4knll
         rljb6dO2aLZNRvnJSW59irRoPYFYzz9N6onCI3IaJTyjnEgcIQpFJgULy10c/9LiCARk
         7gZoyYuf+Nq8Qcac2IAB3ZiS/cH+K4OlK04eLIctsH1KgLc7k5nligEuJlaQlT0TzznR
         dwFQaRRl+hpa4PUqqk9glsk2XnkTXRlgXUCCVpLc3O+qH3xwRpjhHRiuUg9vb8iCLKqO
         u+8R/tJVqqfn9gy2/XZGcPGxD55G72+dvvzL5qdFa1AhJB6wwNfA2FibiDUF/x+z/KyM
         3FeA==
X-Gm-Message-State: AOJu0Yzq492fzlGF1dgzLU6HwM3inRdO7wLNy/Bg8yVXCYgIhbdg+VoF
	TCa8tMCPc8lGs0dETw9uXqrg1rzSvERriBMkfV3DbmdWeTMkOS1WvSDp+Z2GO7NOxTz+hXMRWVu
	g
X-Gm-Gg: ASbGncvo+U1VKdEfCE8NevmanrJeLb4lgF9WMmYbSwv3OSNiCSQBOscvhfJCVp1ta88
	ZokNNGt2/BTFvo0LsNGmSbfc2g6V3x9fQHlesuyt1D6fld2UG1Dvyyat0EY6piU6KAQhZOmmLX4
	ZKvgE+5g09oH4vy2Koift+iwqAKRMnaGJSbdyEjA/cR9k7m03eGt+Aplncmr6Lroqg7hfK6/NxY
	YOWomT0SqURcW4pJLWqL7gooxELQmwuqcd7qdxRoNahiUd6HMxr7ma9X1QAIqaoslk=
X-Google-Smtp-Source: AGHT+IEq+KY2LZkz/gnj/jxJL+yjPIdvzmJsHhNv2K4GFW4sBjXt+uj2Uerfd4lNiG4OAscLmf4jpQ==
X-Received: by 2002:a17:907:3d8f:b0:aae:83c7:6ce7 with SMTP id a640c23a62f3a-ab28d07ba93mr706906266b.0.1736346637140;
        Wed, 08 Jan 2025 06:30:37 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v2 13/18] x86/spec-ctrl: introduce Address Space Isolation command line option
Date: Wed,  8 Jan 2025 15:26:53 +0100
Message-ID: <20250108142659.99490-14-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250108142659.99490-1-roger.pau@citrix.com>
References: <20250108142659.99490-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

No functional change, as the option is not used.

Introduced new so newly added functionality is keyed on the option being
enabled, even if the feature is non-functional.

When ASI is enabled for PV domains, printing the usage of XPTI might be
omitted if it must be uniformly disabled given the usage of ASI.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Changes since v1:
 - Improve comments and documentation about what ASI provides.
 - Do not print the XPTI information if ASI is used for pv domUs and dom0 is
   PVH, or if ASI is used for both domU and dom0.

FWIW, I would print the state of XPTI uniformly, as otherwise I find the output
might be confusing for user expecting to assert the state of XPTI.
---
 docs/misc/xen-command-line.pandoc    |  19 +++++
 xen/arch/x86/include/asm/domain.h    |   3 +
 xen/arch/x86/include/asm/spec_ctrl.h |   2 +
 xen/arch/x86/spec_ctrl.c             | 115 +++++++++++++++++++++++++--
 4 files changed, 133 insertions(+), 6 deletions(-)

diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index 08b0053f9ced..3c1ad7b5fe7d 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -202,6 +202,25 @@ to appropriate auditing by Xen.  Argo is disabled by default.
     This option is disabled by default, to protect domains from a DoS by a
     buggy or malicious other domain spamming the ring.
 
+### asi (x86)
+> `= List of [ <bool>, {pv,hvm}=<bool>,
+               {vcpu-pt}=<bool>|{pv,hvm}=<bool> ]`
+
+Offers control over whether the hypervisor will engage in Address Space
+Isolation, by not having potentially sensitive information permanently mapped
+in the VMM page-tables.  Using this option might avoid the need to apply
+mitigations for certain speculative related attacks, at the cost of mapping
+sensitive information on-demand.
+
+* `pv=` and `hvm=` sub-options allow enabling for specific guest types.
+
+**WARNING: manual de-selection of enabled options will invalidate any
+protection offered by the feature.  The fine grained options provided below are
+meant to be used for debugging purposes only.**
+
+* `vcpu-pt` ensure each vCPU uses a unique top-level page-table and setup a
+  virtual address space region to map memory on a per-vCPU basis.
+
 ### asid (x86)
 > `= <boolean>`
 
diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h
index 5af414fa64ac..fb92a10bf3b7 100644
--- a/xen/arch/x86/include/asm/domain.h
+++ b/xen/arch/x86/include/asm/domain.h
@@ -456,6 +456,9 @@ struct arch_domain
     /* Don't unconditionally inject #GP for unhandled MSRs. */
     bool msr_relaxed;
 
+    /* Use a per-vCPU root pt, and switch per-domain slot to per-vCPU. */
+    bool vcpu_pt;
+
     /* Emulated devices enabled bitmap. */
     uint32_t emulation_flags;
 } __cacheline_aligned;
diff --git a/xen/arch/x86/include/asm/spec_ctrl.h b/xen/arch/x86/include/asm/spec_ctrl.h
index 077225418956..c58afbaab671 100644
--- a/xen/arch/x86/include/asm/spec_ctrl.h
+++ b/xen/arch/x86/include/asm/spec_ctrl.h
@@ -88,6 +88,8 @@ extern uint8_t default_scf;
 
 extern int8_t opt_xpti_hwdom, opt_xpti_domu;
 
+extern int8_t opt_vcpu_pt_pv, opt_vcpu_pt_hwdom, opt_vcpu_pt_hvm;
+
 extern bool cpu_has_bug_l1tf;
 extern int8_t opt_pv_l1tf_hwdom, opt_pv_l1tf_domu;
 extern bool opt_bp_spec_reduce;
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index ced84750015c..9463a8624701 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -85,6 +85,11 @@ static int8_t __initdata opt_gds_mit = -1;
 static int8_t __initdata opt_div_scrub = -1;
 bool __ro_after_init opt_bp_spec_reduce = true;
 
+/* Use a per-vCPU root page-table and switch the per-domain slot to per-vCPU. */
+int8_t __ro_after_init opt_vcpu_pt_hvm = -1;
+int8_t __ro_after_init opt_vcpu_pt_hwdom = -1;
+int8_t __ro_after_init opt_vcpu_pt_pv = -1;
+
 static int __init cf_check parse_spec_ctrl(const char *s)
 {
     const char *ss;
@@ -384,6 +389,13 @@ int8_t __ro_after_init opt_xpti_domu = -1;
 
 static __init void xpti_init_default(void)
 {
+    ASSERT(opt_vcpu_pt_pv >= 0 && opt_vcpu_pt_hwdom >= 0);
+    if ( (opt_xpti_hwdom == 1 || opt_xpti_domu == 1) && opt_vcpu_pt_pv == 1 )
+    {
+        printk(XENLOG_ERR
+               "XPTI incompatible with per-vCPU page-tables, disabling ASI\n");
+        opt_vcpu_pt_pv = 0;
+    }
     if ( (boot_cpu_data.x86_vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON)) ||
          cpu_has_rdcl_no )
     {
@@ -395,9 +407,9 @@ static __init void xpti_init_default(void)
     else
     {
         if ( opt_xpti_hwdom < 0 )
-            opt_xpti_hwdom = 1;
+            opt_xpti_hwdom = !opt_vcpu_pt_hwdom;
         if ( opt_xpti_domu < 0 )
-            opt_xpti_domu = 1;
+            opt_xpti_domu = !opt_vcpu_pt_pv;
     }
 }
 
@@ -488,6 +500,66 @@ static int __init cf_check parse_pv_l1tf(const char *s)
 }
 custom_param("pv-l1tf", parse_pv_l1tf);
 
+static int __init cf_check parse_asi(const char *s)
+{
+    const char *ss;
+    int val, rc = 0;
+
+    /* Interpret 'asi' alone in its positive boolean form. */
+    if ( *s == '\0' )
+        opt_vcpu_pt_pv = opt_vcpu_pt_hwdom = opt_vcpu_pt_hvm = 1;
+
+    do {
+        ss = strchr(s, ',');
+        if ( !ss )
+            ss = strchr(s, '\0');
+
+        val = parse_bool(s, ss);
+        switch ( val )
+        {
+        case 0:
+        case 1:
+            opt_vcpu_pt_pv = opt_vcpu_pt_hwdom = opt_vcpu_pt_hvm = val;
+            break;
+
+        default:
+            if ( (val = parse_boolean("pv", s, ss)) >= 0 )
+                opt_vcpu_pt_pv = val;
+            else if ( (val = parse_boolean("hvm", s, ss)) >= 0 )
+                opt_vcpu_pt_hvm = val;
+            else if ( (val = parse_boolean("vcpu-pt", s, ss)) != -1 )
+            {
+                switch ( val )
+                {
+                case 1:
+                case 0:
+                    opt_vcpu_pt_pv = opt_vcpu_pt_hvm = opt_vcpu_pt_hwdom = val;
+                    break;
+
+                case -2:
+                    s += strlen("vcpu-pt=");
+                    if ( (val = parse_boolean("pv", s, ss)) >= 0 )
+                        opt_vcpu_pt_pv = val;
+                    else if ( (val = parse_boolean("hvm", s, ss)) >= 0 )
+                        opt_vcpu_pt_hvm = val;
+                    else
+                default:
+                        rc = -EINVAL;
+                    break;
+                }
+            }
+            else if ( *s )
+                rc = -EINVAL;
+            break;
+        }
+
+        s = ss + 1;
+    } while ( *ss );
+
+    return rc;
+}
+custom_param("asi", parse_asi);
+
 static void __init print_details(enum ind_thunk thunk)
 {
     unsigned int _7d0 = 0, _7d2 = 0, e8b = 0, e21a = 0, max = 0, tmp;
@@ -668,15 +740,29 @@ static void __init print_details(enum ind_thunk thunk)
            boot_cpu_has(X86_FEATURE_IBPB_ENTRY_PV)   ? " IBPB-entry"    : "",
            opt_bhb_entry_pv                          ? " BHB-entry"     : "");
 
-    printk("  XPTI (64-bit PV only): Dom0 %s, DomU %s (with%s PCID)\n",
-           opt_xpti_hwdom ? "enabled" : "disabled",
-           opt_xpti_domu  ? "enabled" : "disabled",
-           xpti_pcid_enabled() ? "" : "out");
+    if ( !opt_vcpu_pt_pv || (!opt_dom0_pvh && !opt_vcpu_pt_hwdom) )
+        printk("  XPTI (64-bit PV only): Dom0 %s, DomU %s (with%s PCID)\n",
+               opt_xpti_hwdom ? "enabled" : "disabled",
+               opt_xpti_domu  ? "enabled" : "disabled",
+               xpti_pcid_enabled() ? "" : "out");
 
     printk("  PV L1TF shadowing: Dom0 %s, DomU %s\n",
            opt_pv_l1tf_hwdom ? "enabled"  : "disabled",
            opt_pv_l1tf_domu  ? "enabled"  : "disabled");
 #endif
+
+#ifdef CONFIG_HVM
+    printk("  ASI features for HVM VMs:%s%s\n",
+           opt_vcpu_pt_hvm                           ? ""               : " None",
+           opt_vcpu_pt_hvm                           ? " vCPU-PT"       : "");
+
+#endif
+#ifdef CONFIG_PV
+    printk("  ASI features for PV VMs:%s%s\n",
+           opt_vcpu_pt_pv                            ? ""               : " None",
+           opt_vcpu_pt_pv                            ? " vCPU-PT"       : "");
+
+#endif
 }
 
 static bool __init check_smt_enabled(void)
@@ -1779,6 +1865,10 @@ void spec_ctrl_init_domain(struct domain *d)
     if ( pv )
         d->arch.pv.xpti = is_hardware_domain(d) ? opt_xpti_hwdom
                                                 : opt_xpti_domu;
+
+    d->arch.vcpu_pt = is_hardware_domain(d) ? opt_vcpu_pt_hwdom
+                                            : pv ? opt_vcpu_pt_pv
+                                                 : opt_vcpu_pt_hvm;
 }
 
 void __init init_speculation_mitigations(void)
@@ -2075,6 +2165,19 @@ void __init init_speculation_mitigations(void)
          hw_smt_enabled && default_xen_spec_ctrl )
         setup_force_cpu_cap(X86_FEATURE_SC_MSR_IDLE);
 
+    /* Disable all ASI options by default until feature is finished. */
+    if ( opt_vcpu_pt_pv == -1 )
+        opt_vcpu_pt_pv = 0;
+    if ( opt_vcpu_pt_hwdom == -1 )
+        opt_vcpu_pt_hwdom = 0;
+    if ( opt_vcpu_pt_hvm == -1 )
+        opt_vcpu_pt_hvm = 0;
+
+    if ( opt_vcpu_pt_pv || opt_vcpu_pt_hvm )
+        warning_add(
+            "Address Space Isolation is not functional, this option is\n"
+            "intended to be used only for development purposes.\n");
+
     xpti_init_default();
 
     l1tf_calculations();
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 14:44:31 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 14:44:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867435.1278957 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXIL-0000Dl-T8; Wed, 08 Jan 2025 14:44:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867435.1278957; Wed, 08 Jan 2025 14:44:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXIL-0000De-QS; Wed, 08 Jan 2025 14:44:29 +0000
Received: by outflank-mailman (input) for mailman id 867435;
 Wed, 08 Jan 2025 14:44:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=2h7L=UA=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tVX53-0006o2-Lc
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 14:30:45 +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 245e167c-cdcd-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 15:30:43 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-aa68b513abcso3092362766b.0
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 06:30:43 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0f06f942sm2506044666b.200.2025.01.08.06.30.41
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 06:30:41 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 245e167c-cdcd-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736346642; x=1736951442; 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=qyS16XcyT27yuHUB4k53rewk8F6szSNyvboeI7a+Yts=;
        b=nnNvLh+QuoCnKt3E3GKYYAfCp4J95IgIQxR6S8jUa8bsZie3sx3EpL6IODer6P6gcS
         ktbU1FnGfZVdpordfi5wXmMRqMdHULWzirCdYMFRLZzscd4C7yZMcz6xQoleJjPoZPEe
         ECtWlkVCFIwvJZal07fFEhzWIxz75/dKkUWqE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736346642; x=1736951442;
        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=qyS16XcyT27yuHUB4k53rewk8F6szSNyvboeI7a+Yts=;
        b=UU3uYMQ64CoepXSEHYwzEKAe0gMb/o9W9gHSEy+PGdPgztZ3EH5G5iZBB2/1SbhBkb
         AwGhCjs/DL71hS8/en+9o24g+yLAgMynh4IQqvsX0iBjghv0Km3D4tSH6eHt/i6fjoO0
         u+vICzVmIyv4K8nSXjU7o4gLNVSybJ2Ud39uL0luHa0CGjAlv+1ymFWmXPI8Diic/3iK
         SE1yI+RW+48zguD+twdlbxJI3PBkAydFTqOh8YnHYitUorBTLa/wNsazr/PVxxJVesHx
         aXc8xLgOco5apCObGangsXWJTwSPKsloN1h9mrU0+wgc1IOsE2/fQqZRk54RZ8hdUNz0
         U8Xg==
X-Gm-Message-State: AOJu0YyMPD+xNvNwKKjtClGYy86OUjWm5TVhWMye7jeC8s76nhG2IhgZ
	lO4SsQ34y5oYSq4dool/KbnYrmlQC8jmS1aqz7gufkYE8DB7yh6cs7FgNIZrnBejH6VDReiRwY7
	h
X-Gm-Gg: ASbGnctq2wVMgnTUvhvO+4tVFxTOvhyLM5AY/LiVTGMrk47OgJSMzIPxlTS3K4L9Ia5
	gyjz4/ieBPVV8ymZstogi+EdAHG6jF7bS0bJS/nF8f6l/SHubpp/UKwbLliGSVcEkDWf2CIbQhL
	gLZgGt3b6U7HQ0f32VjoCIVnpJwVD+UyECxfdnGT2XeJKrBI8YPhzdbxIJljRigy/9zQFwtHwX5
	rrTkDapqS+a8IqCKXnd0wU3aMvx4tI+fZlTrNE1JmyKlnXoeN/P+NV1S6KOhLPPhy4=
X-Google-Smtp-Source: AGHT+IGHBykV7yeqFfoOvN865Kl8vXTpUOINIzQjWxGFlzMEcE27CB842P7ClQ3IU5vdT/VikV9Mew==
X-Received: by 2002:a17:907:2cc5:b0:aaf:c326:f2d8 with SMTP id a640c23a62f3a-ab2abdc0257mr262042466b.57.1736346641877;
        Wed, 08 Jan 2025 06:30:41 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: [PATCH v2 16/18] x86/pv: allow using a unique per-pCPU root page table (L4)
Date: Wed,  8 Jan 2025 15:26:56 +0100
Message-ID: <20250108142659.99490-17-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250108142659.99490-1-roger.pau@citrix.com>
References: <20250108142659.99490-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

When running PV guests it's possible for the guest to use the same root page
table (L4) for all vCPUs, which in turn will result in Xen also using the same
root page table on all pCPUs that are running any domain vCPU.

When using XPTI Xen switches to a per-CPU shadow L4 when running in guest
context, switching to the fully populated L4 when in Xen context.

Take advantage of this existing shadowing and force the usage of a per-CPU L4
that shadows the guest selected L4 when Address Space Isolation is requested
for PV guests.

The mapping of the guest L4 is done with a per-CPU fixmap entry, that however
requires that the currently loaded L4 has the per-CPU slot setup.  In order to
ensure this switch to the shadow per-CPU L4 with just the Xen slots populated,
and then map the guest L4 and copy the contents of the guest controlled
slots.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/arch/x86/flushtlb.c           | 22 +++++++++++++++++
 xen/arch/x86/include/asm/config.h |  6 +++++
 xen/arch/x86/include/asm/domain.h |  3 +++
 xen/arch/x86/include/asm/pv/mm.h  |  5 ++++
 xen/arch/x86/mm.c                 | 12 +++++++++-
 xen/arch/x86/mm/paging.c          |  6 +++++
 xen/arch/x86/pv/dom0_build.c      | 10 ++++++--
 xen/arch/x86/pv/domain.c          | 31 +++++++++++++++++++++++-
 xen/arch/x86/pv/mm.c              | 40 +++++++++++++++++++++++++++++++
 9 files changed, 131 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/flushtlb.c b/xen/arch/x86/flushtlb.c
index a64c28f854ea..72692b504dd4 100644
--- a/xen/arch/x86/flushtlb.c
+++ b/xen/arch/x86/flushtlb.c
@@ -17,6 +17,7 @@
 #include <asm/nops.h>
 #include <asm/page.h>
 #include <asm/pv/domain.h>
+#include <asm/pv/mm.h>
 #include <asm/spec_ctrl.h>
 
 /* Debug builds: Wrap frequently to stress-test the wrap logic. */
@@ -192,7 +193,28 @@ unsigned int flush_area_local(const void *va, unsigned int flags)
     unsigned int order = (flags - 1) & FLUSH_ORDER_MASK;
 
     if ( flags & FLUSH_ROOT_PGTBL )
+    {
         get_cpu_info()->root_pgt_changed = true;
+        /*
+         * Use opt_vcpu_pt_pv instead of current->arch.vcpu_pt to avoid doing a
+         * sync_local_execstate() when per-vCPU page-tables are not enabled for
+         * PV.
+         */
+        if ( opt_vcpu_pt_pv )
+        {
+            const struct vcpu *curr;
+            const struct domain *curr_d;
+
+            sync_local_execstate();
+
+            curr = current;
+            curr_d = curr->domain;
+
+            if ( is_pv_domain(curr_d) && curr_d->arch.vcpu_pt )
+                /* Update shadow root page-table ahead of doing TLB flush. */
+                pv_asi_update_shadow_l4(curr);
+        }
+    }
 
     if ( flags & (FLUSH_TLB|FLUSH_TLB_GLOBAL) )
     {
diff --git a/xen/arch/x86/include/asm/config.h b/xen/arch/x86/include/asm/config.h
index 19746f956ec3..af3ff3cb8705 100644
--- a/xen/arch/x86/include/asm/config.h
+++ b/xen/arch/x86/include/asm/config.h
@@ -265,6 +265,12 @@ extern unsigned long xen_phys_start;
 /* The address of a particular VCPU's GDT or LDT. */
 #define GDT_VIRT_START(v)    \
     (PERDOMAIN_VIRT_START + ((v)->vcpu_id << GDT_LDT_VCPU_VA_SHIFT))
+/*
+ * There are 2 GDT pages reserved for Xen, but only one is used.  Use the
+ * remaining one to map the guest L4 when running with ASI enabled.
+ */
+#define L4_SHADOW(v) \
+    (GDT_VIRT_START(v) + ((FIRST_RESERVED_GDT_PAGE + 1) << PAGE_SHIFT))
 #define LDT_VIRT_START(v)    \
     (GDT_VIRT_START(v) + (64*1024))
 
diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h
index ba5440099d90..a3c75e323cde 100644
--- a/xen/arch/x86/include/asm/domain.h
+++ b/xen/arch/x86/include/asm/domain.h
@@ -591,6 +591,9 @@ struct pv_vcpu
     /* Deferred VA-based update state. */
     bool need_update_runstate_area;
     struct vcpu_time_info pending_system_time;
+
+    /* For ASI: page to use as L4 shadow of the guest selected L4. */
+    root_pgentry_t *root_pgt;
 };
 
 struct arch_vcpu
diff --git a/xen/arch/x86/include/asm/pv/mm.h b/xen/arch/x86/include/asm/pv/mm.h
index 182764542c1f..540202f9712a 100644
--- a/xen/arch/x86/include/asm/pv/mm.h
+++ b/xen/arch/x86/include/asm/pv/mm.h
@@ -23,6 +23,8 @@ bool pv_destroy_ldt(struct vcpu *v);
 
 int validate_segdesc_page(struct page_info *page);
 
+void pv_asi_update_shadow_l4(const struct vcpu *v);
+
 #else
 
 #include <xen/errno.h>
@@ -44,6 +46,9 @@ static inline bool pv_map_ldt_shadow_page(unsigned int off) { return false; }
 static inline bool pv_destroy_ldt(struct vcpu *v)
 { ASSERT_UNREACHABLE(); return false; }
 
+static inline void pv_asi_update_shadow_l4(const struct vcpu *v)
+{ ASSERT_UNREACHABLE(); }
+
 #endif
 
 #endif /* __X86_PV_MM_H__ */
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 583bf4c58bf9..3a637e508ff3 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -546,6 +546,8 @@ void write_ptbase(struct vcpu *v)
     }
     else
     {
+        if ( is_pv_domain(d) && d->arch.vcpu_pt )
+            pv_asi_update_shadow_l4(v);
         /* Make sure to clear use_pv_cr3 and xen_cr3 before pv_cr3. */
         cpu_info->use_pv_cr3 = false;
         cpu_info->xen_cr3 = 0;
@@ -565,6 +567,7 @@ void write_ptbase(struct vcpu *v)
  */
 pagetable_t update_cr3(struct vcpu *v)
 {
+    const struct domain *d = v->domain;
     mfn_t cr3_mfn;
 
     if ( paging_mode_enabled(v->domain) )
@@ -575,7 +578,14 @@ pagetable_t update_cr3(struct vcpu *v)
     else
         cr3_mfn = pagetable_get_mfn(v->arch.guest_table);
 
-    make_cr3(v, cr3_mfn);
+    make_cr3(v, d->arch.vcpu_pt ? virt_to_mfn(v->arch.pv.root_pgt) : cr3_mfn);
+
+    if ( d->arch.vcpu_pt )
+    {
+        populate_perdomain_mapping(v, L4_SHADOW(v), &cr3_mfn, 1);
+        if ( v == this_cpu(curr_vcpu) )
+            flush_tlb_one_local(L4_SHADOW(v));
+    }
 
     return pagetable_null();
 }
diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c
index c77f4c1dac52..be30f21c1a7b 100644
--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@@ -695,6 +695,12 @@ int paging_domctl(struct domain *d, struct xen_domctl_shadow_op *sc,
         return -EINVAL;
     }
 
+    if ( is_pv_domain(d) && d->arch.vcpu_pt )
+    {
+        gprintk(XENLOG_ERR, "Paging not supported on PV domains with ASI\n");
+        return -EOPNOTSUPP;
+    }
+
     if ( resuming
          ? (d->arch.paging.preempt.dom != current->domain ||
             d->arch.paging.preempt.op != sc->op)
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index 5081c19b9a9a..6c1d99a9bf0d 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -838,8 +838,11 @@ static int __init dom0_construct(struct boot_info *bi, struct domain *d)
 
     d->arch.paging.mode = 0;
 
-    /* Set up CR3 value for switch_cr3_cr4(). */
-    update_cr3(v);
+    /*
+     * Set up CR3 value for switch_cr3_cr4().  Use make_cr3() instead of
+     * update_cr3() to avoid using an ASI page-table for dom0 building.
+     */
+    make_cr3(v, pagetable_get_mfn(v->arch.guest_table));
 
     /* We run on dom0's page tables for the final part of the build process. */
     switch_cr3_cr4(cr3_pa(v->arch.cr3), read_cr4());
@@ -1068,6 +1071,9 @@ static int __init dom0_construct(struct boot_info *bi, struct domain *d)
     }
 #endif
 
+    /* Must be called in case ASI is enabled. */
+    update_cr3(v);
+
     v->is_initialised = 1;
     clear_bit(_VPF_down, &v->pause_flags);
 
diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
index 8d2428051607..583723c5d360 100644
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -15,6 +15,7 @@
 #include <asm/invpcid.h>
 #include <asm/spec_ctrl.h>
 #include <asm/pv/domain.h>
+#include <asm/pv/mm.h>
 #include <asm/shadow.h>
 
 #ifdef CONFIG_PV32
@@ -296,6 +297,7 @@ void pv_vcpu_destroy(struct vcpu *v)
 
     pv_destroy_gdt_ldt_l1tab(v);
     XFREE(v->arch.pv.trap_ctxt);
+    FREE_XENHEAP_PAGE(v->arch.pv.root_pgt);
 }
 
 int pv_vcpu_initialise(struct vcpu *v)
@@ -336,6 +338,24 @@ int pv_vcpu_initialise(struct vcpu *v)
             goto done;
     }
 
+    if ( d->arch.vcpu_pt )
+    {
+        v->arch.pv.root_pgt = alloc_xenheap_page();
+        if ( !v->arch.pv.root_pgt )
+        {
+            rc = -ENOMEM;
+            goto done;
+        }
+
+        /*
+         * VM assists are not yet known, RO machine-to-phys slot will be copied
+         * from the guest L4.
+         */
+        init_xen_l4_slots(v->arch.pv.root_pgt,
+                          _mfn(virt_to_mfn(v->arch.pv.root_pgt)),
+                          v, INVALID_MFN, false);
+    }
+
  done:
     if ( rc )
         pv_vcpu_destroy(v);
@@ -368,7 +388,7 @@ int pv_domain_initialise(struct domain *d)
 
     d->arch.ctxt_switch = &pv_csw;
 
-    d->arch.pv.flush_root_pt = d->arch.pv.xpti;
+    d->arch.pv.flush_root_pt = d->arch.pv.xpti || d->arch.vcpu_pt;
 
     if ( !is_pv_32bit_domain(d) && use_invpcid && cpu_has_pcid )
         switch ( ACCESS_ONCE(opt_pcid) )
@@ -409,6 +429,7 @@ bool __init xpti_pcid_enabled(void)
 
 static void _toggle_guest_pt(struct vcpu *v)
 {
+    const struct domain *d = v->domain;
     bool guest_update;
     pagetable_t old_shadow;
     unsigned long cr3;
@@ -417,6 +438,14 @@ static void _toggle_guest_pt(struct vcpu *v)
     guest_update = v->arch.flags & TF_kernel_mode;
     old_shadow = update_cr3(v);
 
+    if ( d->arch.vcpu_pt )
+        /*
+         * _toggle_guest_pt() might switch between user and kernel page tables,
+         * but doesn't use write_ptbase(), and hence needs an explicit call to
+         * sync the shadow L4.
+         */
+        pv_asi_update_shadow_l4(v);
+
     /*
      * Don't flush user global mappings from the TLB. Don't tick TLB clock.
      *
diff --git a/xen/arch/x86/pv/mm.c b/xen/arch/x86/pv/mm.c
index 4853e619f2a7..46c437692bea 100644
--- a/xen/arch/x86/pv/mm.c
+++ b/xen/arch/x86/pv/mm.c
@@ -12,6 +12,7 @@
 
 #include <asm/current.h>
 #include <asm/p2m.h>
+#include <asm/pv/domain.h>
 
 #include "mm.h"
 
@@ -104,6 +105,45 @@ void init_xen_pae_l2_slots(l2_pgentry_t *l2t, const struct domain *d)
 }
 #endif
 
+void pv_asi_update_shadow_l4(const struct vcpu *v)
+{
+    const root_pgentry_t *guest_pgt;
+    root_pgentry_t *root_pgt = v->arch.pv.root_pgt;
+    const struct domain *d = v->domain;
+
+    ASSERT(!d->arch.pv.xpti);
+    ASSERT(is_pv_domain(d));
+    ASSERT(!is_idle_domain(d));
+    ASSERT(current == this_cpu(curr_vcpu));
+
+    if ( likely(v == current) )
+        guest_pgt = (void *)L4_SHADOW(v);
+    else if ( !(v->arch.flags & TF_kernel_mode) )
+        guest_pgt =
+            map_domain_page(pagetable_get_mfn(v->arch.guest_table_user));
+    else
+        guest_pgt = map_domain_page(pagetable_get_mfn(v->arch.guest_table));
+
+    if ( is_pv_64bit_domain(d) )
+    {
+        unsigned int i;
+
+        for ( i = 0; i < ROOT_PAGETABLE_FIRST_XEN_SLOT; i++ )
+            l4e_write(&root_pgt[i], guest_pgt[i]);
+        for ( i = ROOT_PAGETABLE_LAST_XEN_SLOT + 1;
+              i < L4_PAGETABLE_ENTRIES; i++ )
+            l4e_write(&root_pgt[i], guest_pgt[i]);
+
+        l4e_write(&root_pgt[l4_table_offset(RO_MPT_VIRT_START)],
+                  guest_pgt[l4_table_offset(RO_MPT_VIRT_START)]);
+    }
+    else
+        l4e_write(&root_pgt[0], guest_pgt[0]);
+
+    if ( v != this_cpu(curr_vcpu) )
+        unmap_domain_page(guest_pgt);
+}
+
 /*
  * Local variables:
  * mode: C
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 14:44:56 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 14:44:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867451.1278967 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXIm-0000vG-4N; Wed, 08 Jan 2025 14:44:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867451.1278967; Wed, 08 Jan 2025 14:44:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXIm-0000v9-1q; Wed, 08 Jan 2025 14:44:56 +0000
Received: by outflank-mailman (input) for mailman id 867451;
 Wed, 08 Jan 2025 14:44:54 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=2h7L=UA=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tVX4w-0005q4-9c
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 14:30:38 +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 2029173a-cdcd-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 15:30:36 +0100 (CET)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-aa689a37dd4so565868366b.3
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 06:30:36 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0f015b0fsm2488132166b.156.2025.01.08.06.30.35
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 06:30:35 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2029173a-cdcd-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736346636; x=1736951436; 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=5kWNGpzhADK4ApVubuzBqlSw3YHI7Srtu2T9UABtAuo=;
        b=X5sesrPYr8uXKthxxtljZ/WIebAQB6PO+BmU4KRBwWgNppigYMNW8h5U+gldsrFIW0
         Zd+nztxaSdjnXbaQGU2Pvob6/4voG6j2MFae8vHp72yWjtWCVFDduB50g63PcNXPCslB
         1Q2SrNoTZbsPJD6KQziC29f2e0sBSS+VjUqO8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736346636; x=1736951436;
        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=5kWNGpzhADK4ApVubuzBqlSw3YHI7Srtu2T9UABtAuo=;
        b=H+DezmTGBT8BXs34kaZYBMY72i3EQzTjjndsiESxQC9jBE4OzBj9VeQxOOB+2nNGP0
         0shAz2tBJT/azrz4Rky/0kk2NXfeOL29ROiqJou1hFNEMTjRp9ApP1miqiKwIFpz94LO
         yjQgceZW0tHbDGUpy4Qdj4I/buZWKIpdoTue9mdWo8D2h8hbZUJXs0wLvw6W6byYclJo
         SQuGjdzez1hqZGWDydNQe6xIPs1W6rzEitILxfhd+/CyyTUhgNUjqbEOQg2lJHFr9WvC
         wQhyb44QLupxQ42t0ZIXhgavgEB5mxcY5Bj5+FqSL4QvhexUU4zO+A98F3DbdDUNvrGa
         +Sqg==
X-Gm-Message-State: AOJu0YxDThdT4iqVb6ol4gIrZ7tyM4kVrWS0CIhf7G3CZgr/4urwu60W
	rbW5onEtTstYDYJDGE3jSkOb5Ke+MD07uI2dwleTu5C83cxv3W0SZCbf5WudApVFX9htaqpKisJ
	P
X-Gm-Gg: ASbGncvvBch5VoE/ijqm2lRgn86fFI+QAXrf/4akQdV01StbzOgkBvFJA3XsM/UCVF0
	ig/TZ+1WGG1R9rzBioryVNE8UpPV0AiO7v3+X1b4AurS39PFZ6P2D3IeOLbuzBcHKvTKuxTMY8A
	GHt3DjKCJPN/MfpvXOVeLNXRtaGB7LBM2OC9KeqaX11wGd2zGx7wGqeCs/5LcTfAF8EhupmQzzk
	rtlUhCm0bO+q1hhT4wWel0eIN2uchyqM4o5AevoJgFHCJHDJvx953i6gs0JLyV7IDg=
X-Google-Smtp-Source: AGHT+IHyzn1e1qV9vmlcMx0QuYKG/GCjUKcB3kN205x8eo9Yyxhtm8T1TbpI1iDBGjGQVCA1AV0T8g==
X-Received: by 2002:a17:907:948d:b0:aac:29a:2817 with SMTP id a640c23a62f3a-ab2ab73bbf5mr277559666b.26.1736346635685;
        Wed, 08 Jan 2025 06:30:35 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: [PATCH v2 12/18] x86/mm: move FLUSH_ROOT_PGTBL handling before TLB flush
Date: Wed,  8 Jan 2025 15:26:52 +0100
Message-ID: <20250108142659.99490-13-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250108142659.99490-1-roger.pau@citrix.com>
References: <20250108142659.99490-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Move the handling of FLUSH_ROOT_PGTBL in flush_area_local() ahead of the logic
that does the TLB flushing, in preparation for further changes requiring the
TLB flush to be strictly done after having handled FLUSH_ROOT_PGTBL.

No functional change intended.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/arch/x86/flushtlb.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/flushtlb.c b/xen/arch/x86/flushtlb.c
index 65be0474a8ea..a64c28f854ea 100644
--- a/xen/arch/x86/flushtlb.c
+++ b/xen/arch/x86/flushtlb.c
@@ -191,6 +191,9 @@ unsigned int flush_area_local(const void *va, unsigned int flags)
 {
     unsigned int order = (flags - 1) & FLUSH_ORDER_MASK;
 
+    if ( flags & FLUSH_ROOT_PGTBL )
+        get_cpu_info()->root_pgt_changed = true;
+
     if ( flags & (FLUSH_TLB|FLUSH_TLB_GLOBAL) )
     {
         if ( order == 0 )
@@ -254,9 +257,6 @@ unsigned int flush_area_local(const void *va, unsigned int flags)
         }
     }
 
-    if ( flags & FLUSH_ROOT_PGTBL )
-        get_cpu_info()->root_pgt_changed = true;
-
     return flags;
 }
 
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 15:12:00 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 15:12:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867470.1278994 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXis-0007XQ-DN; Wed, 08 Jan 2025 15:11:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867470.1278994; Wed, 08 Jan 2025 15:11:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXis-0007XJ-9G; Wed, 08 Jan 2025 15:11:54 +0000
Received: by outflank-mailman (input) for mailman id 867470;
 Wed, 08 Jan 2025 15:11:53 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=2h7L=UA=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tVXiq-0007XB-TJ
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 15:11:52 +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 e394623a-cdd2-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 16:11:51 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-aaf57c2e0beso1472880766b.3
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 07:11:51 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2bb7e58f3sm42149466b.174.2025.01.08.07.11.50
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 07:11:50 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e394623a-cdd2-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736349111; x=1736953911; 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=lURVxWW3sxjmXuCopSuRZQjY5IW3fE/Yrwa2ilZxWk8=;
        b=ZySm0s2amtbN6Ff4MFbDEtIAK2h2JXkacGMBJS2l4Qh5OnCSjeKKbzsp/eHq3/zZAY
         DQWavzCXsh+9aVrfsl2GgVW2cDEWJ8yQsc2YuZ+2h6ju6oRzyH0fG8y4FQCY7Jdr9LTy
         YopzcdWjxV5XIk3lWFFj9xFry7xnRgHWLhN/M=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736349111; x=1736953911;
        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=lURVxWW3sxjmXuCopSuRZQjY5IW3fE/Yrwa2ilZxWk8=;
        b=kcLKMH/6ZoRumBZupkQbTRJ09mZQ9G/vrWkKWAFvxodtQcWiJ2aollzV9G8iqNENLH
         ApJETIJkJ1JhXhT6/kZYiPQCcOxi8Lc2xbHJJmvYTXiabGTpLtwKTXF06wViTf5WMFte
         owoKYerZxb/7rf5lAxpczWTt3fGiwOTOgEq2TLLd4RRpQR2x/Wyplrw7QgRNnvvwjOQI
         3ESTX9dzIwvYC5+vT3IfP6Tl66CgaSZK3eCcoPfkWZRewl1AfzYSv8GKJ1/H9nb3K7US
         G+eMb74FI4ze8xktizEccnLVt4LZN/1UDgPWwt9NLogXDY6AfsKPo5+dzsD2J7YAfOT/
         k7Pg==
X-Gm-Message-State: AOJu0YzwGuMVIQyjDeHdASaIrYd1SRMYIlknySgkQo/66H7EGyQU+7rw
	D/+uxZ4CjsLvJIOlxYALsLX6JhIRW2f8zJYb/cy47BXnhJtU7wjKQO8bjR9m3BlYa8Iptaoz6kS
	r
X-Gm-Gg: ASbGncv81dG0UMxdB5/YbQ17drsBchxthSke8R0vUFze23TXbqUDyD5N7599bLk1Sba
	Hyc6D4xuDtpOjOqSrub0q2SudhljYJjZncKCVM5PvXNibEliz1HMcve6RIA6nQ835JAKxGqAyUz
	wC3QU8z9J1D69PBPTRIPIYma56X+yytDlFuI0EUgbkSwaW8GghCmujs9XcatD/MEDXa3kqwThSn
	MFj8AS5sgXdqx9+Bdp9MGrLAAJ1jUj2iNP3OoQZ272PkigbgNgGbKNa+s3hlxjM9gM=
X-Google-Smtp-Source: AGHT+IH/QH6tQP0+01ilYuQx000TH6lj3g1C26Rsy/yv4jSJDh8Z7oqgomwsA5hllUw7ykLGYSk8NQ==
X-Received: by 2002:a17:907:3da3:b0:aa6:33cf:b389 with SMTP id a640c23a62f3a-ab2ab748baamr209199266b.34.1736349110971;
        Wed, 08 Jan 2025 07:11:50 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: [PATCH v2.1 06/18] x86/pv: set/clear guest GDT mappings using {populate,destroy}_perdomain_mapping()
Date: Wed,  8 Jan 2025 16:11:33 +0100
Message-ID: <20250108151133.858-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250108142659.99490-7-roger.pau@citrix.com>
References: <20250108142659.99490-7-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The pv_{set,destroy}_gdt() functions rely on the L1 table(s) that contain such
mappings being stashed in the domain structure, and thus such mappings being
modified by merely updating the L1 entries.

Switch both pv_{set,destroy}_gdt() to instead use
{populate,destory}_perdomain_mapping().

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Changes since v2:
 - Do not change ordering setup of arch_set_info_guest().
---
 xen/arch/x86/pv/descriptor-tables.c | 28 ++++++++++++----------------
 1 file changed, 12 insertions(+), 16 deletions(-)

diff --git a/xen/arch/x86/pv/descriptor-tables.c b/xen/arch/x86/pv/descriptor-tables.c
index 02647a2c5047..5a79f022ce13 100644
--- a/xen/arch/x86/pv/descriptor-tables.c
+++ b/xen/arch/x86/pv/descriptor-tables.c
@@ -49,23 +49,20 @@ bool pv_destroy_ldt(struct vcpu *v)
 
 void pv_destroy_gdt(struct vcpu *v)
 {
-    l1_pgentry_t *pl1e = pv_gdt_ptes(v);
-    mfn_t zero_mfn = _mfn(virt_to_mfn(zero_page));
-    l1_pgentry_t zero_l1e = l1e_from_mfn(zero_mfn, __PAGE_HYPERVISOR_RO);
     unsigned int i;
 
     ASSERT(v == current || !vcpu_cpu_dirty(v));
 
-    v->arch.pv.gdt_ents = 0;
-    for ( i = 0; i < FIRST_RESERVED_GDT_PAGE; i++ )
-    {
-        mfn_t mfn = l1e_get_mfn(pl1e[i]);
+    if ( v->arch.cr3 )
+        destroy_perdomain_mapping(v, GDT_VIRT_START(v),
+                                  ARRAY_SIZE(v->arch.pv.gdt_frames));
 
-        if ( (l1e_get_flags(pl1e[i]) & _PAGE_PRESENT) &&
-             !mfn_eq(mfn, zero_mfn) )
-            put_page_and_type(mfn_to_page(mfn));
+    for ( i = 0; i < ARRAY_SIZE(v->arch.pv.gdt_frames); i++)
+    {
+        if ( !v->arch.pv.gdt_frames[i] )
+            break;
 
-        l1e_write(&pl1e[i], zero_l1e);
+        put_page_and_type(mfn_to_page(_mfn(v->arch.pv.gdt_frames[i])));
         v->arch.pv.gdt_frames[i] = 0;
     }
 }
@@ -74,8 +71,8 @@ int pv_set_gdt(struct vcpu *v, const unsigned long frames[],
                unsigned int entries)
 {
     struct domain *d = v->domain;
-    l1_pgentry_t *pl1e;
     unsigned int i, nr_frames = DIV_ROUND_UP(entries, 512);
+    mfn_t mfns[ARRAY_SIZE(v->arch.pv.gdt_frames)];
 
     ASSERT(v == current || !vcpu_cpu_dirty(v));
 
@@ -90,6 +87,8 @@ int pv_set_gdt(struct vcpu *v, const unsigned long frames[],
         if ( !mfn_valid(mfn) ||
              !get_page_and_type(mfn_to_page(mfn), d, PGT_seg_desc_page) )
             goto fail;
+
+        mfns[i] = mfn;
     }
 
     /* Tear down the old GDT. */
@@ -97,12 +96,9 @@ int pv_set_gdt(struct vcpu *v, const unsigned long frames[],
 
     /* Install the new GDT. */
     v->arch.pv.gdt_ents = entries;
-    pl1e = pv_gdt_ptes(v);
     for ( i = 0; i < nr_frames; i++ )
-    {
         v->arch.pv.gdt_frames[i] = frames[i];
-        l1e_write(&pl1e[i], l1e_from_pfn(frames[i], __PAGE_HYPERVISOR_RW));
-    }
+    populate_perdomain_mapping(v, GDT_VIRT_START(v), mfns, nr_frames);
 
     return 0;
 
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 15:19:12 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 15:19:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867487.1279071 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXpv-0001Vj-Jn; Wed, 08 Jan 2025 15:19:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867487.1279071; Wed, 08 Jan 2025 15:19:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXpv-0001UP-9Z; Wed, 08 Jan 2025 15:19:11 +0000
Received: by outflank-mailman (input) for mailman id 867487;
 Wed, 08 Jan 2025 15:19: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
 <SRS0=HyFE=UA=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tVXpu-0008Ue-IL
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 15:19:10 +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 e82d12c0-cdd3-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 16:19:09 +0100 (CET)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-aa692211331so197245766b.1
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 07:19:09 -0800 (PST)
Received: from localhost.localdomain ([66.81.170.107])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0eae71desm2488412166b.89.2025.01.08.07.19.07
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 07:19:07 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e82d12c0-cdd3-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736349548; x=1736954348; 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=Jw7mWXVpCJfQ9bvcjiyKZM3RdMlwMcvwWhT8eTvVn6U=;
        b=gUNxLztGT+XuBuLXeJ9Y+muSqTAx9oG17WmI1QGVAMJ5mrCDqqjn/7kKVyNFDVIJ29
         8wihzLbT9umRID8q2SfEcUHZIR+8BTI0tD8a+BbK86ZeO1ZiHUch4X773ENOj7R4lfwA
         mydv2YzQ0WCNANOEADXSgPpGpR6sPTIr9QOok=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736349548; x=1736954348;
        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=Jw7mWXVpCJfQ9bvcjiyKZM3RdMlwMcvwWhT8eTvVn6U=;
        b=SE1qVMkjSoaUscFxYV6HA0bCx8DIL1KAQQsBRZ7HC71GXqjlrgR6j64estYN9mEqDW
         NntetsQtlSJlfF5lxbYxLkXwWE7WbGwTP1/KhIQHA7dETNUGJJr2nxArYPTmWkofQ4H3
         CH4eDx1pj/DYiR2bCnzDna497O/lWKs1plj78I5bVzHeSfJaJdEpAprDiHS+hsX0H7uc
         qimBI96vXi3LoU7aTqZ4UYI6AAWmb2PEeeV9XM3AGzK1vy1GVSAjoa1aoWAcmfdJiEbe
         T4oMdEn2qEHwgfggdQa1f1YqD2Av9hG+6o51qAWUCTxmuSeFd/dDhF5g9afu3rr3t1DJ
         CMtQ==
X-Gm-Message-State: AOJu0YxsoiGaNL92kpM4ekLPUFtsH+H7bUTSIxF+7ZGpaT6wXfgodHUd
	/LvwuqJwUgBpbHobVNUXwZKRN2T9WqnYVTT0Q/9dy/l5ON07HCqv/00ZBnmDRa71IZwsnYYlNxd
	nA/gImQ==
X-Gm-Gg: ASbGncu2cSnrP3zpgNxieNy8MxmbThKDbP/f9kyk5ENh8Q2V2m/xN7XdhRLzDoe4A44
	NM+aHcv1veXiOJOZtBBovVJxtobGNSW/uNn+5/IbOPhCyiN1cCzmT1oYpKvC20Y9n4w2c0Ncj5D
	vDgzKFUKrTcuWRQuX2HOhQcurszOrXJHjjtihORhyAHT+MIOBNSS33RZS6F+09YSmIewvDj+h9/
	KcOg+e9QWA8ojyrADlITDh33yteavBYpzzSIiAwoFGnnLUx/4A6+z9YsPnb2cLlP/Eo8UQEUscJ
	EwY=
X-Google-Smtp-Source: AGHT+IHSHfjOlGcCZmim3Gu0rKS/1nvYqcoEGDp9YfwIaOq2RV4Rfts5cwCxRuUXRYrl6NitiJ0QjA==
X-Received: by 2002:a17:907:2d0e:b0:aa6:945c:4531 with SMTP id a640c23a62f3a-ab2a79d1d18mr240135266b.7.1736349548147;
        Wed, 08 Jan 2025 07:19:08 -0800 (PST)
From: Alejandro Vallejo <alejandro.vallejo@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Hongyan Xia <hongyxia@amazon.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Julien Grall <jgrall@amazon.com>,
	Alejandro Vallejo <alejandro.vallejo@cloud.com>
Subject: [PATCH v5 07/15] x86/domain_page: Remove the fast paths when mfn is not in the directmap
Date: Wed,  8 Jan 2025 15:18:14 +0000
Message-ID: <20250108151822.16030-8-alejandro.vallejo@cloud.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250108151822.16030-1-alejandro.vallejo@cloud.com>
References: <20250108151822.16030-1-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Hongyan Xia <hongyxia@amazon.com>

When mfn is not in direct map, never use mfn_to_virt for any mappings.

We replace mfn_x(mfn) <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) with
arch_mfns_in_direct_map(mfn, 1) because these two are equivalent. The
extra comparison in arch_mfns_in_direct_map() looks different but
because
DIRECTMAP_VIRT_END is always higher, it does not make any difference.

Lastly, domain_page_map_to_mfn() needs to gain to a special case for
the PMAP.

Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
Signed-off-by: Julien Grall <jgrall@amazon.com>
Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
---
v4->v5:
  * s/BUILD_BUG_ON/ASSERT/, or it won't build with gcc11.
  * Add CONFIG_HAS_PMAP guards as needed so the code builds without PMAP
  * Fix typos on 2 arch_mfns_in_directmap() calls in release config.

v3->v4:
  * Introduce helper functions virt_is_fixmap and virt_in_fixmap_range

Changes since Hongyan's version:
  * arch_mfn_in_direct_map() was renamed to arch_mfns_in_directmap()
  * add a special case for the PMAP in domain_page_map_to_mfn()
---
 xen/arch/x86/domain_page.c        | 60 +++++++++++++++++++++++++------
 xen/arch/x86/include/asm/fixmap.h | 25 +++++++++++++
 2 files changed, 75 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c
index 55e337aaf703..9582bd63b5c3 100644
--- a/xen/arch/x86/domain_page.c
+++ b/xen/arch/x86/domain_page.c
@@ -14,8 +14,10 @@
 #include <xen/sched.h>
 #include <xen/vmap.h>
 #include <asm/current.h>
+#include <asm/fixmap.h>
 #include <asm/flushtlb.h>
 #include <asm/hardirq.h>
+#include <asm/pmap.h>
 #include <asm/setup.h>
 
 static DEFINE_PER_CPU(struct vcpu *, override);
@@ -24,6 +26,7 @@ static inline struct vcpu *mapcache_current_vcpu(void)
 {
     /* In the common case we use the mapcache of the running VCPU. */
     struct vcpu *v = this_cpu(override) ?: current;
+    struct vcpu *idle_v = idle_vcpu[smp_processor_id()];
 
     /*
      * When current isn't properly set up yet, this is equivalent to
@@ -35,10 +38,11 @@ static inline struct vcpu *mapcache_current_vcpu(void)
     /*
      * When using efi runtime page tables, we have the equivalent of the idle
      * domain's page tables but current may point at another domain's VCPU.
-     * Return NULL as though current is not properly set up yet.
+     * Return the idle domains's vcpu on that core because the efi per-domain
+     * region (where the mapcache is) is in-sync with the idle domain.
      */
     if ( efi_rs_using_pgtables() )
-        return NULL;
+        return idle_v;
 
     /*
      * If guest_table is NULL, and we are running a paravirtualised guest,
@@ -48,7 +52,7 @@ static inline struct vcpu *mapcache_current_vcpu(void)
     if ( unlikely(pagetable_is_null(v->arch.guest_table)) && is_pv_vcpu(v) )
     {
         /* If we really are idling, perform lazy context switch now. */
-        if ( (v = idle_vcpu[smp_processor_id()]) == current )
+        if ( (v = idle_v) == current )
             sync_local_execstate();
         /* We must now be running on the idle page table. */
         ASSERT(cr3_pa(read_cr3()) == __pa(idle_pg_table));
@@ -77,18 +81,28 @@ void *map_domain_page(mfn_t mfn)
     struct vcpu_maphash_entry *hashent;
 
 #ifdef NDEBUG
-    if ( mfn_x(mfn) <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) )
+    if ( arch_mfns_in_directmap(mfn_x(mfn), 1) )
         return mfn_to_virt(mfn_x(mfn));
 #endif
 
     v = mapcache_current_vcpu();
-    if ( !v )
-        return mfn_to_virt(mfn_x(mfn));
+    if ( !v || !v->domain->arch.mapcache.inuse )
+    {
+        if ( arch_mfns_in_directmap(mfn_x(mfn), 1) )
+            return mfn_to_virt(mfn_x(mfn));
+        else
+        {
+#ifdef CONFIG_HAS_PMAP
+            BUG_ON(system_state >= SYS_STATE_smp_boot);
+            return pmap_map(mfn);
+#else
+            BUG();
+#endif
+        }
+    }
 
     dcache = &v->domain->arch.mapcache;
     vcache = &v->arch.mapcache;
-    if ( !dcache->inuse )
-        return mfn_to_virt(mfn_x(mfn));
 
     perfc_incr(map_domain_page_count);
 
@@ -184,6 +198,14 @@ void unmap_domain_page(const void *ptr)
     if ( !va || va >= DIRECTMAP_VIRT_START )
         return;
 
+#ifdef CONFIG_HAS_PMAP
+    if ( virt_is_fixmap(va) )
+    {
+        pmap_unmap(ptr);
+        return;
+    }
+#endif
+
     ASSERT(va >= MAPCACHE_VIRT_START && va < MAPCACHE_VIRT_END);
 
     v = mapcache_current_vcpu();
@@ -237,7 +259,7 @@ int mapcache_domain_init(struct domain *d)
     unsigned int bitmap_pages;
 
 #ifdef NDEBUG
-    if ( !mem_hotplug && max_page <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) )
+    if ( !mem_hotplug && arch_mfns_in_directmap(0, max_page) )
         return 0;
 #endif
 
@@ -308,7 +330,7 @@ void *map_domain_page_global(mfn_t mfn)
             local_irq_is_enabled()));
 
 #ifdef NDEBUG
-    if ( mfn_x(mfn) <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) )
+    if ( arch_mfns_in_directmap(mfn_x(mfn), 1) )
         return mfn_to_virt(mfn_x(mfn));
 #endif
 
@@ -335,6 +357,24 @@ mfn_t domain_page_map_to_mfn(const void *ptr)
     if ( va >= DIRECTMAP_VIRT_START )
         return _mfn(virt_to_mfn(ptr));
 
+#ifdef CONFIG_HAS_PMAP
+    /*
+     * The fixmap is stealing the top-end of the VMAP. So the check for
+     * the PMAP *must* happen first.
+     *
+     * Also, the fixmap translate a slot to an address backwards. The
+     * logic will rely on it to avoid any complexity. So check at
+     * compile time this will always hold.
+     */
+    ASSERT(fix_to_virt(FIX_PMAP_BEGIN) > fix_to_virt(FIX_PMAP_END));
+
+    if ( virt_in_fixmap_range(va, FIX_PMAP_BEGIN, FIX_PMAP_END) )
+    {
+        BUG_ON(system_state >= SYS_STATE_smp_boot);
+        return l1e_get_mfn(l1_fixmap[l1_table_offset(va)]);
+    }
+#endif /* CONFIG_HAS_PMAP */
+
     if ( va >= VMAP_VIRT_START && va < VMAP_VIRT_END )
         return vmap_to_mfn(va);
 
diff --git a/xen/arch/x86/include/asm/fixmap.h b/xen/arch/x86/include/asm/fixmap.h
index 80b7b74fd816..381c95a8b11f 100644
--- a/xen/arch/x86/include/asm/fixmap.h
+++ b/xen/arch/x86/include/asm/fixmap.h
@@ -101,6 +101,31 @@ static inline unsigned long virt_to_fix(const unsigned long vaddr)
     return __virt_to_fix(vaddr);
 }
 
+static inline bool virt_is_fixmap(const unsigned long vaddr)
+{
+    return vaddr >= FIXADDR_START && vaddr < FIXADDR_TOP;
+}
+
+static inline bool virt_in_fixmap_range(
+    const unsigned long vaddr,
+    const unsigned int start_idx,
+    const unsigned int end_idx
+)
+{
+    unsigned long start_addr = (unsigned long)fix_to_virt(start_idx);
+    unsigned long end_addr = (unsigned long)fix_to_virt(end_idx);
+
+    /*
+     * The check ensures that the virtual address (vaddr) is within the
+     * fixmap range. The addresses are allocated backwards, meaning the
+     * start address is higher than the end address. As a result, the
+     * check ensures that the virtual address is greater than or equal to
+     * the end address, and less than or equal to the start address, which
+     * may appear counterintuitive due to the reverse allocation order.
+     */
+    return ((vaddr & PAGE_MASK) <= start_addr) && (vaddr >= end_addr);
+}
+
 enum fixed_addresses_x {
     /* Index 0 is reserved since fix_x_to_virt(0) == FIXADDR_X_TOP. */
     FIX_X_RESERVED,
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 15:19:12 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 15:19:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867481.1279024 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXpr-0000Pg-IZ; Wed, 08 Jan 2025 15:19:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867481.1279024; Wed, 08 Jan 2025 15:19:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXpr-0000PX-F0; Wed, 08 Jan 2025 15:19:07 +0000
Received: by outflank-mailman (input) for mailman id 867481;
 Wed, 08 Jan 2025 15:19:05 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=HyFE=UA=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tVXpp-0008Lg-Cp
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 15:19:05 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e5a4a2a2-cdd3-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 16:19:04 +0100 (CET)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-ab2b72fb3c9so123438366b.0
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 07:19:04 -0800 (PST)
Received: from localhost.localdomain ([66.81.170.107])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0eae71desm2488412166b.89.2025.01.08.07.19.03
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 07:19:03 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e5a4a2a2-cdd3-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736349544; x=1736954344; 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=b5kW+L9or4UchYGbtNWwT1tJvUFiadtexJoE68LPlKw=;
        b=U7ARSjPCGO0znmMI9r/qNh4LJXhhHoPd824PeTWz9iG/byXWT2cW06pEUttR8QdncM
         +e8Mm3bcrp3PyK/slRqr/GxIwbMao9BQqE2p3kIl7/0ynk5306BpgmfgZja21IcXXrAg
         FPBzfZysJRa7sxDcjy90jk5B1c4dqf4S4sdFA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736349544; x=1736954344;
        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=b5kW+L9or4UchYGbtNWwT1tJvUFiadtexJoE68LPlKw=;
        b=uvZr6epX7KHQLAHi19TUDS+49Fgyu4Uq7LT2HONtd+jgfLCESAj5ds9gKo5nLHUWmR
         4PZGlwkRGc4FuIPoWH8ypHtDlkShuzmBbOEDzvaO2s3jUkXP6NPxAOSRfIM7SqDuTOOE
         es+cFfbEzGf6Uuroa8QpK4dUUlqeAzu36dT2gPddlK8KnDrwdR4A578upVIdIMeI23Kt
         Y9vYi8RIFz/DIqD/q2c0xAuxednh4AcRsL+JInB6yhf+lbVXpOwKLlYLPFd0s6iev3Bo
         qXLmDHCmQw29h0KIcfR9QeZ4jSlBK/W7RQwtPvBCAKyGKJ2hO079+Yjn7HhpPHkhE7y7
         CiNw==
X-Gm-Message-State: AOJu0YwaVl4HAK9yTGsJCIa+tD2rdqlVbswyez3vpfuP9/3xi3SX5u8E
	OTxJ2pfR9Z0pYMam+WUg5Kzif2yTXbLY0TgNQTB+v3klid8DqtvUZVN5jblUS+luKrq3RFOHO7b
	dMr8Ltg==
X-Gm-Gg: ASbGncsAEiodk1DlQj9vVBTC1Cuv6zFwVg+zojaVZzhNXgVIqWEuxpNYOXEuryUCBji
	dwg8rzGC2xaCkR842m6EAz2C3pvmFWLkU6IZ/kygSLZNA2cCyQRiOVPw0wrRaxv0HyFpxIQu689
	k7XhePjogVfjTBf/j7t31GFBMzUy62SQ1oL0NzeHLU90RZvi2zLQ+eBx+0tt3ALgpQzH9Qtvyn3
	oBhc/iz/OBMDnfFwgOFydOtc1f88G6IXLyV3WBVT+OpGQfk1dxvOEjdZlic6YlRKd45KdR1vNOd
	yh0=
X-Google-Smtp-Source: AGHT+IHV6oa2te4PnkoUSSr5SDjwRGUrfSPwGyilCbkNwbSum59kdIk8gEKqbOSWy3RmfhUHpU0ykQ==
X-Received: by 2002:a17:907:7f08:b0:aab:9258:488 with SMTP id a640c23a62f3a-ab2904ff9d7mr611013366b.10.1736349543895;
        Wed, 08 Jan 2025 07:19:03 -0800 (PST)
From: Alejandro Vallejo <alejandro.vallejo@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Hongyan Xia <hongyxia@amazon.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Julien Grall <jgrall@amazon.com>,
	Elias El Yandouzi <eliasely@amazon.com>,
	Alejandro Vallejo <alejandro.vallejo@cloud.com>
Subject: [PATCH v5 03/15] x86/pv: Rewrite how building PV dom0 handles domheap mappings
Date: Wed,  8 Jan 2025 15:18:10 +0000
Message-ID: <20250108151822.16030-4-alejandro.vallejo@cloud.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250108151822.16030-1-alejandro.vallejo@cloud.com>
References: <20250108151822.16030-1-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Hongyan Xia <hongyxia@amazon.com>

Building a PV dom0 is allocating from the domheap but uses it like the
xenheap. Use the pages as they should be.

Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
Signed-off-by: Julien Grall <jgrall@amazon.com>
Signed-off-by: Elias El Yandouzi <eliasely@amazon.com>
Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
---
v4->v5:
  * Bugfix: Don't map l4start with a mapcache and unmap with another.
            This is a revert to how it originally was in the series.
            i.e: UNMAP_DOMAIN_PAGE(l4start) before overriding current
                 and then re-mapping on the idle PTs if needed.
  * Simplify UNMAP_MAP_AND_ADVANCE removing the do-while(). It's not
    needed with the ({ x }) expression. Assignments return the
    assigned value, so the last line was not needed either.

v3->v4:
  * Reduce the scope of l{1,2,4}start_mfn variables
  * Make the macro `UNMAP_MAP_AND_ADVANCE` return the new virtual
address

v2->v3:
  * Fold following patch 'x86/pv: Map L4 page table for shim domain'

v1->v2:
  * Clarify the commit message
  * Break the patch in two parts

Changes since Hongyan's version:
  * Rebase
  * Remove spurious newline
---
 xen/arch/x86/pv/dom0_build.c | 61 +++++++++++++++++++++++++-----------
 1 file changed, 42 insertions(+), 19 deletions(-)

diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index 08a4534d5c19..649412590e72 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -384,6 +384,8 @@ static int __init dom0_construct(struct boot_info *bi, struct domain *d)
     l3_pgentry_t *l3tab = NULL, *l3start = NULL;
     l2_pgentry_t *l2tab = NULL, *l2start = NULL;
     l1_pgentry_t *l1tab = NULL, *l1start = NULL;
+    mfn_t l3start_mfn = INVALID_MFN;
+    mfn_t l4start_mfn = INVALID_MFN;
 
     /*
      * This fully describes the memory layout of the initial domain. All
@@ -738,22 +740,30 @@ static int __init dom0_construct(struct boot_info *bi, struct domain *d)
         v->arch.pv.event_callback_cs    = FLAT_COMPAT_KERNEL_CS;
     }
 
+#define UNMAP_MAP_AND_ADVANCE(mfn_var, virt_var, maddr) ({  \
+    unmap_domain_page(virt_var);                            \
+    mfn_var = maddr_to_mfn(maddr);                          \
+    maddr += PAGE_SIZE;                                     \
+    virt_var = map_domain_page(mfn_var);                    \
+})
+
     if ( !compat )
     {
         maddr_to_page(mpt_alloc)->u.inuse.type_info = PGT_l4_page_table;
-        l4start = l4tab = __va(mpt_alloc); mpt_alloc += PAGE_SIZE;
+        l4tab = UNMAP_MAP_AND_ADVANCE(l4start_mfn, l4start, mpt_alloc);
         clear_page(l4tab);
-        init_xen_l4_slots(l4tab, _mfn(virt_to_mfn(l4start)),
-                          d, INVALID_MFN, true);
-        v->arch.guest_table = pagetable_from_paddr(__pa(l4start));
+        init_xen_l4_slots(l4tab, l4start_mfn, d, INVALID_MFN, true);
+        v->arch.guest_table = pagetable_from_mfn(l4start_mfn);
     }
     else
     {
         /* Monitor table already created by switch_compat(). */
-        l4start = l4tab = __va(pagetable_get_paddr(v->arch.guest_table));
+        l4start_mfn = pagetable_get_mfn(v->arch.guest_table);
+        l4start = l4tab = map_domain_page(l4start_mfn);
         /* See public/xen.h on why the following is needed. */
         maddr_to_page(mpt_alloc)->u.inuse.type_info = PGT_l3_page_table;
         l3start = __va(mpt_alloc); mpt_alloc += PAGE_SIZE;
+        UNMAP_MAP_AND_ADVANCE(l3start_mfn, l3start, mpt_alloc);
     }
 
     l4tab += l4_table_offset(v_start);
@@ -762,15 +772,17 @@ static int __init dom0_construct(struct boot_info *bi, struct domain *d)
     {
         if ( !((unsigned long)l1tab & (PAGE_SIZE-1)) )
         {
+            mfn_t l1start_mfn;
             maddr_to_page(mpt_alloc)->u.inuse.type_info = PGT_l1_page_table;
-            l1start = l1tab = __va(mpt_alloc); mpt_alloc += PAGE_SIZE;
+            l1tab = UNMAP_MAP_AND_ADVANCE(l1start_mfn, l1start, mpt_alloc);
             clear_page(l1tab);
             if ( count == 0 )
                 l1tab += l1_table_offset(v_start);
             if ( !((unsigned long)l2tab & (PAGE_SIZE-1)) )
             {
+                mfn_t l2start_mfn;
                 maddr_to_page(mpt_alloc)->u.inuse.type_info = PGT_l2_page_table;
-                l2start = l2tab = __va(mpt_alloc); mpt_alloc += PAGE_SIZE;
+                l2tab = UNMAP_MAP_AND_ADVANCE(l2start_mfn, l2start, mpt_alloc);
                 clear_page(l2tab);
                 if ( count == 0 )
                     l2tab += l2_table_offset(v_start);
@@ -780,19 +792,19 @@ static int __init dom0_construct(struct boot_info *bi, struct domain *d)
                     {
                         maddr_to_page(mpt_alloc)->u.inuse.type_info =
                             PGT_l3_page_table;
-                        l3start = __va(mpt_alloc); mpt_alloc += PAGE_SIZE;
+                        UNMAP_MAP_AND_ADVANCE(l3start_mfn, l3start, mpt_alloc);
                     }
                     l3tab = l3start;
                     clear_page(l3tab);
                     if ( count == 0 )
                         l3tab += l3_table_offset(v_start);
-                    *l4tab = l4e_from_paddr(__pa(l3start), L4_PROT);
+                    *l4tab = l4e_from_mfn(l3start_mfn, L4_PROT);
                     l4tab++;
                 }
-                *l3tab = l3e_from_paddr(__pa(l2start), L3_PROT);
+                *l3tab = l3e_from_mfn(l2start_mfn, L3_PROT);
                 l3tab++;
             }
-            *l2tab = l2e_from_paddr(__pa(l1start), L2_PROT);
+            *l2tab = l2e_from_mfn(l1start_mfn, L2_PROT);
             l2tab++;
         }
         if ( count < initrd_pfn || count >= initrd_pfn + PFN_UP(initrd_len) )
@@ -811,30 +823,37 @@ static int __init dom0_construct(struct boot_info *bi, struct domain *d)
 
     if ( compat )
     {
-        l2_pgentry_t *l2t;
-
         /* Ensure the first four L3 entries are all populated. */
         for ( i = 0, l3tab = l3start; i < 4; ++i, ++l3tab )
         {
             if ( !l3e_get_intpte(*l3tab) )
             {
+                mfn_t l2start_mfn;
                 maddr_to_page(mpt_alloc)->u.inuse.type_info = PGT_l2_page_table;
-                l2tab = __va(mpt_alloc); mpt_alloc += PAGE_SIZE;
-                clear_page(l2tab);
-                *l3tab = l3e_from_paddr(__pa(l2tab), L3_PROT);
+                UNMAP_MAP_AND_ADVANCE(l2start_mfn, l2start, mpt_alloc);
+                clear_page(l2start);
+                *l3tab = l3e_from_mfn(l2start_mfn, L3_PROT);
             }
             if ( i == 3 )
                 l3e_get_page(*l3tab)->u.inuse.type_info |= PGT_pae_xen_l2;
         }
 
-        l2t = map_l2t_from_l3e(l3start[3]);
-        init_xen_pae_l2_slots(l2t, d);
-        unmap_domain_page(l2t);
+        UNMAP_DOMAIN_PAGE(l2start);
+        l2start = map_l2t_from_l3e(l3start[3]);
+        init_xen_pae_l2_slots(l2start, d);
     }
 
+#undef UNMAP_MAP_AND_ADVANCE
+
+    UNMAP_DOMAIN_PAGE(l1start);
+    UNMAP_DOMAIN_PAGE(l2start);
+    UNMAP_DOMAIN_PAGE(l3start);
+
     /* Pages that are part of page tables must be read only. */
     mark_pv_pt_pages_rdonly(d, l4start, vpt_start, nr_pt_pages, &flush_flags);
 
+    UNMAP_DOMAIN_PAGE(l4start);
+
     /* Mask all upcalls... */
     for ( i = 0; i < XEN_LEGACY_MAX_VCPUS; i++ )
         shared_info(d, vcpu_info[i].evtchn_upcall_mask) = 1;
@@ -1003,8 +1022,12 @@ static int __init dom0_construct(struct boot_info *bi, struct domain *d)
      * !CONFIG_VIDEO case so the logic here can be simplified.
      */
     if ( pv_shim )
+    {
+        l4start = map_domain_page(l4start_mfn);
         pv_shim_setup_dom(d, l4start, v_start, vxenstore_start, vconsole_start,
                           vphysmap_start, si);
+        UNMAP_DOMAIN_PAGE(l4start);
+    }
 
 #ifdef CONFIG_COMPAT
     if ( compat )
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 15:19:12 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 15:19:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867484.1279053 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXpt-00015m-M1; Wed, 08 Jan 2025 15:19:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867484.1279053; Wed, 08 Jan 2025 15:19:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXpt-00013u-GA; Wed, 08 Jan 2025 15:19:09 +0000
Received: by outflank-mailman (input) for mailman id 867484;
 Wed, 08 Jan 2025 15:19: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
 <SRS0=HyFE=UA=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tVXpr-0008Lg-Lh
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 15:19:07 +0000
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com
 [2a00:1450:4864:20::62a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e6f60577-cdd3-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 16:19:07 +0100 (CET)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-aa6a92f863cso532874266b.1
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 07:19:06 -0800 (PST)
Received: from localhost.localdomain ([66.81.170.107])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0eae71desm2488412166b.89.2025.01.08.07.19.05
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 07:19:05 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e6f60577-cdd3-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736349546; x=1736954346; 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=JwBhhGsIi6j0431N7dPj7kwiLad+N3xTknrKun361rM=;
        b=M8n8xpYd9vewjvtm5b76xNCSnGbb1XXttXuIjHEpNx/D4qdLC7YaX2HvC/lGCPTtqh
         h7F20sgMxTr1a863CknvsiC0FEpxogkLYVq5+iYwNvoftU1bXGPKP3Q5fUeg11tKDNM8
         njDRjSelwbthUFejJjz6KnctQinwPDt5wtfVg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736349546; x=1736954346;
        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=JwBhhGsIi6j0431N7dPj7kwiLad+N3xTknrKun361rM=;
        b=FD9mCh9T9ccYg26fyaY5RhNSDoJtBUgFZUeQf9b3d+8G3JLsyFOvEpLzSO8GuVQub/
         M4taYRzQ2roo2LIJmqzi7qZ63NKZiExiq4av4/oVX6eh6nY/9vzKrgfkJkdrrtNZflFh
         Xj6MHPgWh8Wakuk1btrpcvFfO2d752dk25TZXZedvGlypGoJMrTDCj8ApF99C5XXecqf
         QpiKU5Wzs7ZDWfyPTfV4CW1xcZLd6/Qe0HBVyPzEW4UdGzFAOprOUh+4XHkKxFWQ5MNW
         uBxBGBG4H7y51Heay2ubPdSmvFa3Q6lbvdCxp0ss3WtbFyrI59Jfc3KMCAvDTuVywxcv
         no2A==
X-Gm-Message-State: AOJu0Yx0EEbnRzRMjALD284nIHpu02mqrYo/pmpsCelGji5H2FthiyR3
	AjbwQ4y7kS0UnCMNXiLFTaY/kz10dmHwosxyz2OrChlzvjcpoELnO1Z0YFiRoHl9brLfAFrJlHr
	DKDAPBg==
X-Gm-Gg: ASbGncsqeXJJInbWIdRG+UkAIuH125muNoyqyTxgITcsu6h5TRkI0uLTpnb1b4SwCB6
	TCMVrBPJuYe3kH4wEK6RnjqvhTbEaO8JnZIvtAU7pe4tSV1YAKhCD7PL/0/oyxP9nUb4gJz5Z6a
	wRN5DYUNxRMCiUpd+CcLflAEgmYzpMoFEuHD6xDNGgSnie/dO23er5TUKyouidUf2wzWzIa9fUM
	yud2SI/Vt32XYmffgpkzVsVmH0RETZ0lET6N6U0Id3UK98i3yfXSiCSok+vbLOAClXwIyUNsRZU
	YnU=
X-Google-Smtp-Source: AGHT+IEmRfZTn8az4OYaE9fsLSrrsmECKXw/OTjUIfdtxZkfacPZRnaTOoT2mNfX9WgazQmGZBl7sA==
X-Received: by 2002:a17:907:7fa5:b0:aa6:5d30:d976 with SMTP id a640c23a62f3a-ab2ab6a84f7mr275128066b.10.1736349546043;
        Wed, 08 Jan 2025 07:19:06 -0800 (PST)
From: Alejandro Vallejo <alejandro.vallejo@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Hongyan Xia <hongyxia@amazon.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <jgrall@amazon.com>,
	Elias El Yandouzi <eliasely@amazon.com>,
	Alejandro Vallejo <alejandro.vallejo@cloud.com>
Subject: [PATCH v5 05/15] x86: Add a boot option to enable and disable the direct map
Date: Wed,  8 Jan 2025 15:18:12 +0000
Message-ID: <20250108151822.16030-6-alejandro.vallejo@cloud.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250108151822.16030-1-alejandro.vallejo@cloud.com>
References: <20250108151822.16030-1-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Hongyan Xia <hongyxia@amazon.com>

This is added as a Kconfig option as well as a boot command line option.
While being generic, the Kconfig option is only usable for x86 at the
moment.

Note that there remains some users of the directmap at this point. The
option is introduced now as it will be needed in follow-up patches.

Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
Signed-off-by: Julien Grall <jgrall@amazon.com>
Signed-off-by: Elias El Yandouzi <eliasely@amazon.com>
Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
---
There's a major change compared with v4. directmap= turned into asi= for
compatibility with Roger's ASI series. In particular, after everything
is done we expect the commandline to have somewhat different effects per
arch depending on the extent of ASI implemented. e.g: x86 might implement
distinct toggles for PV and HVM, which are nonsensical for anything but
x86.

With the intent of parsing the commandline differently I've modified
this patch to parse it on arch-specific code from the get-go. I also
adjusted the commandline text to make it a lot more similar to the final
text expected on Roger's series.

v4->v5:
  * Moved cmdline parsing to arch-specific code and turned directmap= to
    asi= (where asi == !directmap). This is for compatibility with
    Roger's work, which appends extra suboptions to asi= on x86.
  * Moved the printk() highlighting the sparse directmap to spec-ctrl
    with the rest of speculative mitigations. Further additions to asi=
    will interact with XPTI, so it makes sense to have it all there.
  * Moved CONFIG_ONDEMAND_DIRECTMAP to the speculation hardening section
    of Kconfig.
  * Reworded the help message to align it with other rows in that
    section and make it more ameanable for end users.
  * Simplified #ifdef hunk defining has_directmap()
  * Used #ifdef CONFIG_ONDEMAND_DIRECTMAP rather than
    CONFIG_HAS_ONDEMAND_DIRECTMAP. The former selects the feature, while
    the latter signals support for it on the arch.

v3->v4:
  * Rename the Kconfig options
  * Set opt_directmap to true if CONFIG_HAS_ONDEMAND_DIRECTMAP is not
enabled

v2->v3:
  * No changes.

v1->v2:
  * Introduce a Kconfig option
  * Reword the commit message
  * Make opt_directmap and helper generic

Changes since Hongyan's version:
  * Reword the commit message
  * opt_directmap is only modified during boot so mark it as
    __ro_after_init
---
 docs/misc/xen-command-line.pandoc | 11 +++++++++++
 xen/arch/x86/Kconfig              |  1 +
 xen/arch/x86/include/asm/mm.h     |  6 ++++++
 xen/arch/x86/spec_ctrl.c          |  7 +++++++
 xen/common/Kconfig                | 21 +++++++++++++++++++++
 xen/include/xen/mm.h              | 11 +++++++++++
 6 files changed, 57 insertions(+)

diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index 08b0053f9ced..6a1351b6c09b 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -202,6 +202,17 @@ to appropriate auditing by Xen.  Argo is disabled by default.
     This option is disabled by default, to protect domains from a DoS by a
     buggy or malicious other domain spamming the ring.
 
+### asi (x86)
+> `= <boolean>`
+
+> Default: `false`
+
+Offers control over whether the hypervisor will engage in Address Space
+Isolation, by not having potentially sensitive information permanently mapped
+in the directmap. Enabling this option populates the directmap sparsely on
+demand, blocking exploits that leak secrets via speculative memory access in
+the directmap.
+
 ### asid (x86)
 > `= <boolean>`
 
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 9cdd04721afa..55f1e8702ab9 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -23,6 +23,7 @@ config X86
 	select HAS_IOPORTS
 	select HAS_KEXEC
 	select HAS_NS16550
+	select HAS_ONDEMAND_DIRECTMAP
 	select HAS_PASSTHROUGH
 	select HAS_PCI
 	select HAS_PCI_MSI
diff --git a/xen/arch/x86/include/asm/mm.h b/xen/arch/x86/include/asm/mm.h
index 6c7e66ee21ab..4c82428b8b3e 100644
--- a/xen/arch/x86/include/asm/mm.h
+++ b/xen/arch/x86/include/asm/mm.h
@@ -643,11 +643,17 @@ void write_32bit_pse_identmap(uint32_t *l2);
 /*
  * x86 maps part of physical memory via the directmap region.
  * Return whether the range of MFN falls in the directmap region.
+ *
+ * Enabling ASI on the commandline (i.e: using the `asi=` option) causes the
+ * directmap to be mostly empty, so this always returns false in that case.
  */
 static inline bool arch_mfns_in_directmap(unsigned long mfn, unsigned long nr)
 {
     unsigned long eva = min(DIRECTMAP_VIRT_END, HYPERVISOR_VIRT_END);
 
+    if ( !has_directmap() )
+        return false;
+
     return (mfn + nr) <= (virt_to_mfn(eva - 1) + 1);
 }
 
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index ced84750015c..f67e0139b81e 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -85,6 +85,11 @@ static int8_t __initdata opt_gds_mit = -1;
 static int8_t __initdata opt_div_scrub = -1;
 bool __ro_after_init opt_bp_spec_reduce = true;
 
+#ifdef CONFIG_ONDEMAND_DIRECTMAP
+bool __ro_after_init opt_ondemand_dmap;
+boolean_param("asi", opt_ondemand_dmap);
+#endif
+
 static int __init cf_check parse_spec_ctrl(const char *s)
 {
     const char *ss;
@@ -633,6 +638,8 @@ static void __init print_details(enum ind_thunk thunk)
                cpu_has_bug_l1tf ? "" : " not",
                l1d_maxphysaddr, paddr_bits, l1tf_safe_maddr);
 
+    printk("  ASI: %s", !has_directmap() ? "enabled" : "disabled");
+
     /*
      * Alternatives blocks for protecting against and/or virtualising
      * mitigation support for guests.
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 6166327f4d14..1ee498a3e9a7 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -74,6 +74,9 @@ config HAS_KEXEC
 config HAS_LLC_COLORING
 	bool
 
+config HAS_ONDEMAND_DIRECTMAP
+	bool
+
 config HAS_PIRQ
 	bool
 
@@ -214,6 +217,24 @@ config SPECULATIVE_HARDEN_LOCK
 
 	  If unsure, say Y.
 
+config ONDEMAND_DIRECTMAP
+	bool "On-Demand Directmap"
+	depends on HAS_ONDEMAND_DIRECTMAP
+	help
+	  Contemporary processors may use speculative execution as a
+	  performance optimisation, but this can potentially be abused by an
+	  attacker to leak data via speculative sidechannels.
+
+	  When enabled, this option provides defense in depth by preventing
+	  most RAM from being constantly mapped on the hypervisor, thereby
+	  greatly reducing the scope of data leaks after a successful
+	  speculative attack.
+
+	  This option is disabled by default at run time, and needs to be
+	  enabled on the command line.
+
+	  If unsure, say N.
+
 endmenu
 
 config DIT_DEFAULT
diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
index 16f733281af3..fe73057e1781 100644
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -169,6 +169,17 @@ extern unsigned long max_page;
 extern unsigned long total_pages;
 extern paddr_t mem_hotplug;
 
+#ifdef CONFIG_ONDEMAND_DIRECTMAP
+extern bool opt_ondemand_dmap;
+
+static inline bool has_directmap(void)
+{
+    return !opt_ondemand_dmap;
+}
+#else
+#define has_directmap() true
+#endif
+
 /*
  * Extra fault info types which are used to further describe
  * the source of an access violation.
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 15:19:12 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 15:19:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867483.1279037 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXps-0000bx-ES; Wed, 08 Jan 2025 15:19:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867483.1279037; Wed, 08 Jan 2025 15:19:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXps-0000YG-5J; Wed, 08 Jan 2025 15:19:08 +0000
Received: by outflank-mailman (input) for mailman id 867483;
 Wed, 08 Jan 2025 15:19:06 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=HyFE=UA=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tVXpq-0008Lg-H6
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 15:19:06 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e63db730-cdd3-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 16:19:05 +0100 (CET)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-aa69107179cso2812353366b.0
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 07:19:05 -0800 (PST)
Received: from localhost.localdomain ([66.81.170.107])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0eae71desm2488412166b.89.2025.01.08.07.19.04
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 07:19:04 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e63db730-cdd3-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736349545; x=1736954345; 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=3YsfPYnnI6FWUYgHfjtYUL/QekhFikCxvRDQSMOAmr4=;
        b=CP3lwKLnbK8m7BwkCP6XQHqCxwhpL2tmYCLq2a8Q+TVguTyR5aMDjO1Xs70puHmLWx
         GRQ0T20vQ2vQsbByyrEvGojbEA8gljByCgOtIYNpjuMGMrMhlfWvmryIw7t4YS0yjA8K
         ZU43p05ieyVX06KRjiKLvQBrf6K28UmvwU19Q=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736349545; x=1736954345;
        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=3YsfPYnnI6FWUYgHfjtYUL/QekhFikCxvRDQSMOAmr4=;
        b=A8Eo6oF0eChv+iKtFS14M2zuTVF9XwX8tNBFhF6XrkWjbXo69/DlW3QURtF2I7KT5i
         IzhyYZrltDx/b1+sAlruiGHzyf5Y7m+j5cmv7OQOwglmbY71eXzVdVcvBH0nP/RFS1XW
         OABLtKlTxZ8L5bPmby4Drqkri/iwXNAptnhu0maNPeB3T+3SHv7fcjZi1p1Xs/RehNU7
         +cxPbwODZbGIkVpmBx44Tl+EAzMmZpy74yhq6KTXUChgH1rV/cXGOJWSno80EPtFYg2j
         4MR69NHPMLe8GndQllwdh+Ng9cwAb2/574isjEk8qLMapkU1W0iwoKn0EQh0cupa+ihl
         oZtQ==
X-Gm-Message-State: AOJu0Yye+YXNmEu7WpjbtyIVzwLMNRLw4iFwBbvsUF+XU0l9vVqHEBGs
	UzcZzd1xvDp0RyxW1Iz0Sb7FvFmu+t0+UoJkNu59SISgvp7FCX7605AztIUugiSI8XGJkAn+Li4
	QFiGnHw==
X-Gm-Gg: ASbGncuhskvXfBFQIDYKTzncA50EMdEEIrZdbboeBYWvCUQNSegRsHddKGtvSYKPuJA
	Xkcyqp/Z3IRIM7FRDnny/O133WHggRRl6OGE9cfIceeelHk8RoABlmvgYEQEZhi956gfDN/zMIw
	kbNFPMxh0tyL+8sZDCLw0bQYQKNgaaNHN/AqNp1qLFzpveDht1agpbnMVclDn71fVPkcXh2o7zw
	UkZD7gWe2w2lGjwDhbLDn+76Kc6C5J9k1/5ixDjALxckAioRBdlOGWhaTFHSZ+C9gquD/bNofmI
	kNY=
X-Google-Smtp-Source: AGHT+IEUj4gOUwHUn/rIAicijRfStFxoaCwoTk6QHyfvmCd+pbRo3s4LpEwHMg36vX8h3/K60AU/og==
X-Received: by 2002:a17:907:3da1:b0:aaf:3f57:9d2e with SMTP id a640c23a62f3a-ab2aaaf6571mr264290166b.0.1736349544953;
        Wed, 08 Jan 2025 07:19:04 -0800 (PST)
From: Alejandro Vallejo <alejandro.vallejo@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Wei Liu <wei.liu2@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Wei Wang <wawei@amazon.de>,
	Hongyan Xia <hongyxia@amazon.com>,
	Julien Grall <jgrall@amazon.com>,
	Elias El Yandouzi <eliasely@amazon.com>,
	Alejandro Vallejo <alejandro.vallejo@cloud.com>
Subject: [PATCH v5 04/15] x86: Initialize mapcache for PV, HVM, and idle domains
Date: Wed,  8 Jan 2025 15:18:11 +0000
Message-ID: <20250108151822.16030-5-alejandro.vallejo@cloud.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250108151822.16030-1-alejandro.vallejo@cloud.com>
References: <20250108151822.16030-1-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: Wei Liu <wei.liu2@citrix.com>

To support the transition away from the direct map, the mapcache will
now be used by HVM and idle domains as well. This patch lifts the
`mapcache` to the arch level and moves its initialization to
`arch_domain_create()`.

For the idle domain to utilize the mapcache, this patch also populates
the mapcache page tables within the `PERDOMAIN` region and adjusts the
initialization sequence in `arch_idle_init()`, as it's no longer covered
by `arch_domain_create()`

With this change, mapcache initialization is now unified across all
domain types—PV, HVM, and idle.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Wei Wang <wawei@amazon.de>
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
Signed-off-by: Julien Grall <jgrall@amazon.com>
Signed-off-by: Elias El Yandouzi <eliasely@amazon.com>
Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
---
v4->v5:
  * Move mapcache initialization and cleanup back to arch-specific
    code and reword commit message to reflect it. Since v3, the idle
    domain gained its own arch-init function, so initialise the mapcache
    there instead. Panic on failure to initialise it for the idle
    domain, as there's no possible recovery.

v2->v4:
  * Reword the commit message
  * Rebase it on top of staging
  * The logic for the creation of the domain has been reworked
    so introduced #ifdef CONFIG_X86 in the common code to
    initialise the mapcache

v1->v2:
  * Free resources if mapcache initialisation fails
  * Remove `is_idle_domain()` check from `create_perdomain_mappings()`
---
 xen/arch/x86/domain.c             | 13 ++++++++++---
 xen/arch/x86/domain_page.c        | 22 ++++++++++------------
 xen/arch/x86/include/asm/domain.h | 12 ++++++------
 3 files changed, 26 insertions(+), 21 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 78a13e6812c9..307ec0f11fed 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -777,6 +777,12 @@ void __init arch_init_idle_domain(struct domain *d)
     };
 
     d->arch.ctxt_switch = &idle_csw;
+
+    BUG_ON(mapcache_domain_init(d));
+
+    /* Slot 260: Per-domain mappings. */
+    idle_pg_table[l4_table_offset(PERDOMAIN_VIRT_START)] =
+        l4e_from_page(d->arch.perdomain_l3_pg, __PAGE_HYPERVISOR_RW);
 }
 
 int arch_domain_create(struct domain *d,
@@ -832,6 +838,10 @@ int arch_domain_create(struct domain *d,
 
     spec_ctrl_init_domain(d);
 
+    rc = mapcache_domain_init(d);
+    if ( rc )
+        goto fail;
+
     if ( (rc = paging_domain_init(d)) != 0 )
         goto fail;
     paging_initialised = true;
@@ -870,9 +880,6 @@ int arch_domain_create(struct domain *d,
     }
     else if ( is_pv_domain(d) )
     {
-        if ( (rc = mapcache_domain_init(d)) != 0 )
-            goto fail;
-
         if ( (rc = pv_domain_initialise(d)) != 0 )
             goto fail;
     }
diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c
index eac5e3304fb8..55e337aaf703 100644
--- a/xen/arch/x86/domain_page.c
+++ b/xen/arch/x86/domain_page.c
@@ -82,11 +82,11 @@ void *map_domain_page(mfn_t mfn)
 #endif
 
     v = mapcache_current_vcpu();
-    if ( !v || !is_pv_vcpu(v) )
+    if ( !v )
         return mfn_to_virt(mfn_x(mfn));
 
-    dcache = &v->domain->arch.pv.mapcache;
-    vcache = &v->arch.pv.mapcache;
+    dcache = &v->domain->arch.mapcache;
+    vcache = &v->arch.mapcache;
     if ( !dcache->inuse )
         return mfn_to_virt(mfn_x(mfn));
 
@@ -187,14 +187,14 @@ void unmap_domain_page(const void *ptr)
     ASSERT(va >= MAPCACHE_VIRT_START && va < MAPCACHE_VIRT_END);
 
     v = mapcache_current_vcpu();
-    ASSERT(v && is_pv_vcpu(v));
+    ASSERT(v);
 
-    dcache = &v->domain->arch.pv.mapcache;
+    dcache = &v->domain->arch.mapcache;
     ASSERT(dcache->inuse);
 
     idx = PFN_DOWN(va - MAPCACHE_VIRT_START);
     mfn = l1e_get_pfn(MAPCACHE_L1ENT(idx));
-    hashent = &v->arch.pv.mapcache.hash[MAPHASH_HASHFN(mfn)];
+    hashent = &v->arch.mapcache.hash[MAPHASH_HASHFN(mfn)];
 
     local_irq_save(flags);
 
@@ -233,11 +233,9 @@ void unmap_domain_page(const void *ptr)
 
 int mapcache_domain_init(struct domain *d)
 {
-    struct mapcache_domain *dcache = &d->arch.pv.mapcache;
+    struct mapcache_domain *dcache = &d->arch.mapcache;
     unsigned int bitmap_pages;
 
-    ASSERT(is_pv_domain(d));
-
 #ifdef NDEBUG
     if ( !mem_hotplug && max_page <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) )
         return 0;
@@ -261,12 +259,12 @@ int mapcache_domain_init(struct domain *d)
 int mapcache_vcpu_init(struct vcpu *v)
 {
     struct domain *d = v->domain;
-    struct mapcache_domain *dcache = &d->arch.pv.mapcache;
+    struct mapcache_domain *dcache = &d->arch.mapcache;
     unsigned long i;
     unsigned int ents = d->max_vcpus * MAPCACHE_VCPU_ENTRIES;
     unsigned int nr = PFN_UP(BITS_TO_LONGS(ents) * sizeof(long));
 
-    if ( !is_pv_vcpu(v) || !dcache->inuse )
+    if ( !dcache->inuse )
         return 0;
 
     if ( ents > dcache->entries )
@@ -293,7 +291,7 @@ int mapcache_vcpu_init(struct vcpu *v)
     BUILD_BUG_ON(MAPHASHENT_NOTINUSE < MAPCACHE_ENTRIES);
     for ( i = 0; i < MAPHASH_ENTRIES; i++ )
     {
-        struct vcpu_maphash_entry *hashent = &v->arch.pv.mapcache.hash[i];
+        struct vcpu_maphash_entry *hashent = &v->arch.mapcache.hash[i];
 
         hashent->mfn = ~0UL; /* never valid to map */
         hashent->idx = MAPHASHENT_NOTINUSE;
diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h
index b5a14991ca0b..470192646b50 100644
--- a/xen/arch/x86/include/asm/domain.h
+++ b/xen/arch/x86/include/asm/domain.h
@@ -287,9 +287,6 @@ struct pv_domain
     /* Mitigate L1TF with shadow/crashing? */
     bool check_l1tf;
 
-    /* map_domain_page() mapping cache. */
-    struct mapcache_domain mapcache;
-
     struct cpuidmasks *cpuidmasks;
 };
 
@@ -328,6 +325,9 @@ struct arch_domain
 
     uint8_t scf; /* See SCF_DOM_MASK */
 
+    /* map_domain_page() mapping cache. */
+    struct mapcache_domain mapcache;
+
     union {
         struct pv_domain pv;
         struct hvm_domain hvm;
@@ -518,9 +518,6 @@ struct arch_domain
 
 struct pv_vcpu
 {
-    /* map_domain_page() mapping cache. */
-    struct mapcache_vcpu mapcache;
-
     unsigned int vgc_flags;
 
     struct trap_info *trap_ctxt;
@@ -614,6 +611,9 @@ struct arch_vcpu
 #define async_exception_state(t) async_exception_state[(t)-1]
     uint8_t async_exception_mask;
 
+    /* map_domain_page() mapping cache. */
+    struct mapcache_vcpu mapcache;
+
     /* Virtual Machine Extensions */
     union {
         struct pv_vcpu pv;
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 15:19:12 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 15:19:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867482.1279029 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXpr-0000SZ-T0; Wed, 08 Jan 2025 15:19:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867482.1279029; Wed, 08 Jan 2025 15:19:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXpr-0000S8-NK; Wed, 08 Jan 2025 15:19:07 +0000
Received: by outflank-mailman (input) for mailman id 867482;
 Wed, 08 Jan 2025 15:19: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
 <SRS0=HyFE=UA=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tVXpp-0008Ue-GZ
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 15:19:05 +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 e5088e42-cdd3-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 16:19:03 +0100 (CET)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-5d3d479b1e6so24091031a12.2
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 07:19:03 -0800 (PST)
Received: from localhost.localdomain ([66.81.170.107])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0eae71desm2488412166b.89.2025.01.08.07.19.01
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 07:19:02 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e5088e42-cdd3-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736349543; x=1736954343; 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=wbGRQTGcHs+jb1boNth07gwQLtq4Kdirf6gaOSDnoIc=;
        b=EI8IcDPLbUmkegEKo/JEVosAAlseqKivtVJrNKCpj4A/Yjv3RwQ3VriuiidP+rvcJa
         Z2ixumAufKwRZsMwmCkxaAJvLFaH/ElJPyWQfYA8oyNH76ag1/n+/SuiLdiHqGU7Ucur
         kEA6VTGmOKUumzF8j5ujBAr/5pnQmq7nx22OA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736349543; x=1736954343;
        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=wbGRQTGcHs+jb1boNth07gwQLtq4Kdirf6gaOSDnoIc=;
        b=RWtxGUgGlFVRKspVhGJNBwz0124JrtTA4OaUA/DOeMbfUgHZBuMfDGAQss7I+GRS9h
         5T5niFhGBrjVq6PP89pzj6i1/fy+ZJxJB0PDqNy1nJ1xW/yf640FvzYR0zsFdUUtMN7K
         h7jAjpMox73xgv8incDRLq0r781Svo0hmMzYkNo9pinY4sMfwyxWWUX8PtSv+ZGUDzT8
         03CGVX9qyuz9xW3PPeAjmoM0xJT3p/ticrmb069G08RVyjKghUZv+l2fCmX5PBeE40hS
         BwFm+/W9F99LCisYnv2OKfDH6IOp2voKirDH8Wqn4RaB4ytAXb6ViEGkKWxszjpvID86
         lYjQ==
X-Gm-Message-State: AOJu0YyX/8WPJCAYdBzRnm5YDTVENdzL/+msCnuvdnKLlulkkJDq0hdP
	8BN0KWxsxN0WBbhgIz8RCgFtuDva5cInqmf32ITj+uLmUk3CGUb7FZ2EygK37pFuZU5AfRTrS/F
	W6t081w==
X-Gm-Gg: ASbGnctQT8VI5eAmzC5uV0jQKF66MBNivNApujtE2cpyQzCn+5BS93zPd0usKPLDrNv
	0bW7mjESxDisWKEVrBzD/KtcRkwVHHoQU7gt1fvlCjR3n7aV7B+s85/9/UTqBcHuD8OUGhISY0G
	zmBIM7owLEIx4KZTHgDLi2k7hXoHEaYkvI6OyvCwCidf/4xmfTliuzX6rl8EYl+VydZF05oJNMG
	PX/0P8vFCObzlIMYXh9pxd1WRbGaBaP9UPgyciJS8gq80c9BUrGol/VI25xTwVvCH4zAmHaQuvu
	W44=
X-Google-Smtp-Source: AGHT+IGkaiMbxkSh85J0AOmJK4ePyzmat6eWHelGZ7J77qfccD/S6Yzj6V5PY3eDPIIRCuv82vjIQg==
X-Received: by 2002:a05:6402:2548:b0:5d4:2ef7:1c with SMTP id 4fb4d7f45d1cf-5d972e639e4mr6963135a12.24.1736349542864;
        Wed, 08 Jan 2025 07:19:02 -0800 (PST)
From: Alejandro Vallejo <alejandro.vallejo@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Wei Liu <wei.liu2@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Wei Wang <wawei@amazon.de>,
	Julien Grall <jgrall@amazon.com>,
	Elias El Yandouzi <eliasely@amazon.com>,
	Alejandro Vallejo <alejandro.vallejo@cloud.com>
Subject: [PATCH v5 02/15] x86/pv: Use copy_domain_page() to manage domheap pages during initrd relocation
Date: Wed,  8 Jan 2025 15:18:09 +0000
Message-ID: <20250108151822.16030-3-alejandro.vallejo@cloud.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250108151822.16030-1-alejandro.vallejo@cloud.com>
References: <20250108151822.16030-1-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Wei Liu <wei.liu2@citrix.com>

Replace the manual copying logic with a call to `copy_domain_page()`
while relocating intird which map and unmap pages accordingly.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Wei Wang <wawei@amazon.de>
Signed-off-by: Julien Grall <jgrall@amazon.com>
Signed-off-by: Elias El Yandouzi <eliasely@amazon.com>
Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
---
v4->v5:
  * No changes

v3->v4:
  * Use the count of pages instead of calculating from order for nr_pages initialization

v2->v3:
  * Rename commit title
  * Rework the for loop copying the pages

v1->v2:
  * Get rid of mfn_to_virt
  * Don't open code copy_domain_page()

Changes since Hongyan's version:
  * Add missing newline after the variable declaration
---
 xen/arch/x86/pv/dom0_build.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index f54d1da5c6f4..08a4534d5c19 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -637,17 +637,24 @@ static int __init dom0_construct(struct boot_info *bi, struct domain *d)
         if ( d->arch.physaddr_bitsize &&
              ((mfn + count - 1) >> (d->arch.physaddr_bitsize - PAGE_SHIFT)) )
         {
+            unsigned int nr_pages = count;
+
             order = get_order_from_pages(count);
             page = alloc_domheap_pages(d, order, MEMF_no_scrub);
             if ( !page )
                 panic("Not enough RAM for domain 0 initrd\n");
+
             for ( count = -count; order--; )
                 if ( count & (1UL << order) )
                 {
                     free_domheap_pages(page, order);
                     page += 1UL << order;
+                    nr_pages -= 1UL << order;
                 }
-            memcpy(page_to_virt(page), __va(initrd->start), initrd_len);
+
+            for ( ; nr_pages-- ; page++, mfn++ )
+                copy_domain_page(page_to_mfn(page), _mfn(mfn));
+
             /*
              * The initrd was copied but the initrd variable is reused in the
              * calculations below. As to not leak the memory used for the
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 15:19:12 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 15:19:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867488.1279082 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXpw-0001rT-Ql; Wed, 08 Jan 2025 15:19:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867488.1279082; Wed, 08 Jan 2025 15:19:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXpw-0001qr-Is; Wed, 08 Jan 2025 15:19:12 +0000
Received: by outflank-mailman (input) for mailman id 867488;
 Wed, 08 Jan 2025 15:19:10 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=HyFE=UA=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tVXpu-0008Lg-Qr
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 15:19:10 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e8ece51c-cdd3-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 16:19:10 +0100 (CET)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-aaf60d85238so1272582266b.0
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 07:19:10 -0800 (PST)
Received: from localhost.localdomain ([66.81.170.107])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0eae71desm2488412166b.89.2025.01.08.07.19.08
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 07:19:09 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e8ece51c-cdd3-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736349549; x=1736954349; 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=OW3IEcDQIGgERvNx7U/UfHJTPkVf/pejI3zoKLzHcZ4=;
        b=O72zaF7NS/cBoKnHQexNJbYarf9+dYvh96M2k8qFN+wUvi7IkFykhW2VmNbksaR9RH
         7GITDaWY15+x0ChXWeLV2tTNQK9wr5MF5fpkFKzk50tnh8b63vY4FmjPzfZwaWevFmsc
         HZd4+Na3kmOUh0Bm+T8GN2w4ZIGWXWWJz/g+A=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736349549; x=1736954349;
        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=OW3IEcDQIGgERvNx7U/UfHJTPkVf/pejI3zoKLzHcZ4=;
        b=ubMthTtbcUycdSEFddVBcOLar8m3BhdxFLsC+JrBm8kwnMD8UIbmiHCXebqMtCpAMb
         0N250MvhkD8MMCJQ25ny2Hsl0uhFVbKVBycAnhyYWJydg/SitilFDK3w1Muq/0TDGnls
         yRN5FjLnJ8wzA+Ff8peQ1nrfGzGEwnbaBS8ZKZAsnJ+CUWyvvBXQc4r0g0JmcSiacuwh
         VBkefj689YhIJvArELCN4CLx6GVRe8+Yw0ePhmmnPFcM95k2tVVH2vmxdxs/Lptzrr4x
         yk861rZ/GQCC2d6jj5ZyEg2w7H15wtANX7n7+TR9qmBBq1zZCe5yOLWrWxSxMT4J4/kW
         9E2w==
X-Gm-Message-State: AOJu0YzjYDDbIjY6KIW+QfbS8rlNMFZvwf5ERV+SquDIDEMguUlka7Y2
	bCWhoxZIXjavxBMZko1UIB5vqn3g8ufLrGP0GYLvgQBXnTPyuVqD+ajrR3u7J5K2RYb607bQU4J
	hANFuoQ==
X-Gm-Gg: ASbGncvzo5Oj155b46FsIDMSDAghELqsQYQsXnXFn5YxM4usWrbSB4G99/grBwuoYoT
	1KTp1SeJF6PFq9w2cZsmep6Z+avuWkmgKKnIcfyuEbWf9fY/X8OOBgmo687Z1KRqeJnTYRZMFP0
	PRZyIAAyin8UI8AxLNkCkdndwgeC1z2DtlmU3bHe/BcKUkmwCoc/jJWhpclR8RAyNp9iyPUeJ/5
	VblwUkN5KT7O2hSw236f7jeKYzZZN52bWBx3IzNwMcJ38SysdcCJovdWHIgomDw8bLoueOUig8g
	Xvc=
X-Google-Smtp-Source: AGHT+IEHcvVuDBftNzgvsSJjl9/9ijtvIIRWM0K6YyDq9Uo03CAZE0TpiiTY8VB9i1idNueu4C4Prg==
X-Received: by 2002:a17:907:80c:b0:aab:daf9:972 with SMTP id a640c23a62f3a-ab2ab70c9afmr294425966b.28.1736349549423;
        Wed, 08 Jan 2025 07:19:09 -0800 (PST)
From: Alejandro Vallejo <alejandro.vallejo@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Hongyan Xia <hongyxia@amazon.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <jgrall@amazon.com>,
	Elias El Yandouzi <eliasely@amazon.com>,
	Alejandro Vallejo <alejandro.vallejo@cloud.com>
Subject: [PATCH v5 08/15] xen/page_alloc: Add a path for xenheap when there is no direct map
Date: Wed,  8 Jan 2025 15:18:15 +0000
Message-ID: <20250108151822.16030-9-alejandro.vallejo@cloud.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250108151822.16030-1-alejandro.vallejo@cloud.com>
References: <20250108151822.16030-1-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Hongyan Xia <hongyxia@amazon.com>

When there is not an always-mapped direct map, xenheap allocations need
to be mapped and unmapped on-demand.

Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
Signed-off-by: Julien Grall <jgrall@amazon.com>
Signed-off-by: Elias El Yandouzi <eliasely@amazon.com>
Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
---
v4->v5:
  * Remove stray comma in printk() after XENLOG_WARNING.

Elias @ v4:
  I have left the call to map_pages_to_xen() and destroy_xen_mappings()
  in the split heap for now. I am not entirely convinced this is
necessary
  because in that setup only the xenheap would be always mapped and
  this doesn't contain any guest memory (aside the grant-table).
  So map/unmapping for every allocation seems unnecessary.

v3->v4:
  * Call printk instead of dprintk()

v1->v2:
  * Fix remaining wrong indentation in alloc_xenheap_pages()

Changes since Hongyan's version:
  * Rebase
  * Fix indentation in alloc_xenheap_pages()
  * Fix build for arm32
---
 xen/common/page_alloc.c | 43 +++++++++++++++++++++++++++++++++++++++--
 1 file changed, 41 insertions(+), 2 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 1bf070c8c5df..1c01332b6cb0 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -2435,6 +2435,7 @@ void init_xenheap_pages(paddr_t ps, paddr_t pe)
 void *alloc_xenheap_pages(unsigned int order, unsigned int memflags)
 {
     struct page_info *pg;
+    void *virt_addr;
 
     ASSERT_ALLOC_CONTEXT();
 
@@ -2443,17 +2444,36 @@ void *alloc_xenheap_pages(unsigned int order, unsigned int memflags)
     if ( unlikely(pg == NULL) )
         return NULL;
 
-    return page_to_virt(pg);
+    virt_addr = page_to_virt(pg);
+
+    if ( !has_directmap() &&
+         map_pages_to_xen((unsigned long)virt_addr, page_to_mfn(pg), 1UL << order,
+                          PAGE_HYPERVISOR) )
+    {
+        /* Failed to map xenheap pages. */
+        free_heap_pages(pg, order, false);
+        return NULL;
+    }
+
+    return virt_addr;
 }
 
 
 void free_xenheap_pages(void *v, unsigned int order)
 {
+    unsigned long va = (unsigned long)v & PAGE_MASK;
+
     ASSERT_ALLOC_CONTEXT();
 
     if ( v == NULL )
         return;
 
+    if ( !has_directmap() &&
+         destroy_xen_mappings(va, va + (PAGE_SIZE << order)) )
+        printk(XENLOG_WARNING
+                "Error while destroying xenheap mappings at %p, order %u\n",
+                v, order);
+
     free_heap_pages(virt_to_page(v), order, false);
 }
 
@@ -2477,6 +2497,7 @@ void *alloc_xenheap_pages(unsigned int order, unsigned int memflags)
 {
     struct page_info *pg;
     unsigned int i;
+    void *virt_addr;
 
     ASSERT_ALLOC_CONTEXT();
 
@@ -2489,16 +2510,28 @@ void *alloc_xenheap_pages(unsigned int order, unsigned int memflags)
     if ( unlikely(pg == NULL) )
         return NULL;
 
+    virt_addr = page_to_virt(pg);
+
+    if ( !has_directmap() &&
+         map_pages_to_xen((unsigned long)virt_addr, page_to_mfn(pg), 1UL << order,
+                          PAGE_HYPERVISOR) )
+    {
+        /* Failed to map xenheap pages. */
+        free_domheap_pages(pg, order);
+        return NULL;
+    }
+
     for ( i = 0; i < (1u << order); i++ )
         pg[i].count_info |= PGC_xen_heap;
 
-    return page_to_virt(pg);
+    return virt_addr;
 }
 
 void free_xenheap_pages(void *v, unsigned int order)
 {
     struct page_info *pg;
     unsigned int i;
+    unsigned long va = (unsigned long)v & PAGE_MASK;
 
     ASSERT_ALLOC_CONTEXT();
 
@@ -2510,6 +2543,12 @@ void free_xenheap_pages(void *v, unsigned int order)
     for ( i = 0; i < (1u << order); i++ )
         pg[i].count_info &= ~PGC_xen_heap;
 
+    if ( !has_directmap() &&
+         destroy_xen_mappings(va, va + (PAGE_SIZE << order)) )
+        printk(XENLOG_WARNING
+                "Error while destroying xenheap mappings at %p, order %u\n",
+                v, order);
+
     free_heap_pages(pg, order, true);
 }
 
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 15:19:12 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 15:19:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867479.1279004 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXpo-0008Lt-1Y; Wed, 08 Jan 2025 15:19:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867479.1279004; Wed, 08 Jan 2025 15:19:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXpn-0008Lm-V5; Wed, 08 Jan 2025 15:19:03 +0000
Received: by outflank-mailman (input) for mailman id 867479;
 Wed, 08 Jan 2025 15:19:03 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=HyFE=UA=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tVXpm-0008Lg-Ut
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 15:19:03 +0000
Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com
 [2a00:1450:4864:20::341])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e3e3acc2-cdd3-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 16:19:01 +0100 (CET)
Received: by mail-wm1-x341.google.com with SMTP id
 5b1f17b1804b1-43624b2d453so173420295e9.2
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 07:19:01 -0800 (PST)
Received: from localhost.localdomain ([66.81.170.107])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0eae71desm2488412166b.89.2025.01.08.07.18.59
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 07:19:00 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e3e3acc2-cdd3-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736349541; x=1736954341; 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=/91ShzS8VL58GKpah1RRh06XqBgOzqL+oZTNUXKZWds=;
        b=d7HMslq9yMrFodNd58RHYyE22GSjCiM4a3Mlgq8TvOJHv77B51UansBRyiyxoNWYoN
         IiM1vJcxJTYGm4tQKv+A4d6lgXZqAQVSPGnWhKhKGKGpDVR3fMLjQ5yfkHwKvmmdOWqJ
         PDXTvJmw2rVddpk+TWZKaK6+r1iIc0YSIYVRQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736349541; x=1736954341;
        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=/91ShzS8VL58GKpah1RRh06XqBgOzqL+oZTNUXKZWds=;
        b=UtRv14M9zDGlSt1vQJ1h9DvahS9z+OIpSvrIec9RfZ0LHVz7DniiyT1MndGy2bIdhg
         Zq8iM8z9m/Ydu8iKd6VHGDAC96675jEuDz+LK/ynZO63Xg4mQjEGtF966StLV/NWrlrY
         OXW6JpOHvshzp9JVLpl+qa75QKZ/RuZK0wwzBrX40Fvd+4rVI4J3FAOW1/RU9fGaPiQ6
         gJWF0WSzesZ8Kn81AC76vTkV3ZfNr4fqRVuwoWZJYlIPQLTxP6m6td6XEQsHkdAILicA
         /oM5/4BSu9INR4LMN0unOxT2belPNTyvSd/p1DoKz2uOGAlpCcsbn7teGxG5sAQjbhc/
         vSDA==
X-Gm-Message-State: AOJu0Yz5YxTXgDjpBtaOlzAtYhJ8wzxtbpA4iZFr4wpdq0+C2l0YcZMu
	i0O7zFz5L3gK/WzrfqfIeIIfLFzEyfuGDx8zWQT1Qjw1GYK+hooJGcadLv0UZgJ5gjeM2VpoxjG
	Vju9tdstj
X-Gm-Gg: ASbGncuTC6miXJgJNt0lvqbVqQiVVKozEvAazJ2l/nqAwhHn76HGZ4BxjHwRMk7u3Sm
	6LPsoOrHl13U2XLYakhmnRyZpgYSyazAydbTGm/83nzVF9S1JyQi/ZUpLWIK3QMyTw3rzhRNZoG
	K71n1LZswRdZICUZ9regvolO3fIeUKfNFcjnRH4/pdUAOQXd0oWNrEJmzgEOQtaRSzD420hyF9X
	WeFegpffRYarUEpKROopmkNdOpeQmjuYbKU6Un93+7vNMaAh2r6CfmDitVCWaNnYyqR9aR7FUKd
	CyU=
X-Google-Smtp-Source: AGHT+IFCGBRYIiVVbFLfC0bpoWRZUFKWVz1pMEI1fZRooWck3s+HgSL3+87RD41YSoer0s7rdrmGvg==
X-Received: by 2002:a5d:5f82:0:b0:385:fa26:f0ac with SMTP id ffacd0b85a97d-38a872fc03fmr2911734f8f.7.1736349540826;
        Wed, 08 Jan 2025 07:19:00 -0800 (PST)
From: Alejandro Vallejo <alejandro.vallejo@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Alejandro Vallejo <alejandro.vallejo@cloud.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: [PATCH v5 00/15] Remove the directmap
Date: Wed,  8 Jan 2025 15:18:07 +0000
Message-ID: <20250108151822.16030-1-alejandro.vallejo@cloud.com>
X-Mailer: git-send-email 2.47.1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Hi,

I picked v4 of this series and run it through XenRT extensively, fixing crashes
and errors as I hit them. Likewise, I've run it through Gitlab, fixing various
CI failures. I listed all changes per patch. I fixed ARM to the extent that
"Gitlab is happy when CONFIG_ONDEMAND_DIRECTMAP=y", but I didn't go much
further than that.

I _THINK_ I've covered previously unaddressed feedback, but please speak up if
I missed something. Otherwise, same old same old.

Cheers,
Alejandro

============== Original cover letter ==============

Hi all,

A few years ago, Wei Liu implemented a PoC to remove the directmap
from Xen. The last version was sent by Hongyan Xia [1].

I will start with thanking both Wei and Hongyan for the initial work
to upstream the feature. A lot of patches already went in and this is
the last few patches missing to effectively enable the feature.

=== What is the directmap? ===

At the moment, on both arm64 and x86, most of the RAM is mapped
in Xen address space. This means that domain memory is easily
accessible in Xen.

=== Why do we want to remove the directmap? ===

(Summarizing my understanding of the previous discussion)

Speculation attacks (like Spectre SP1) rely on loading piece of memory
in the cache. If the region is not mapped then it can't be loaded.

So removing reducing the amount of memory mapped in Xen will also
reduce the surface attack.

=== What's the performance impact? ===

As the guest memory is not always mapped, then the cost of mapping
will increase. I haven't done the numbers with this new version, but
some measurement were provided in the previous version for x86.

=== Improvement possible ===

The known area to improve on x86 are:
   * Mapcache: There was a patch sent by Hongyan:
     https://lore.kernel.org/xen-devel/4058e92ce21627731c49b588a95809dc0affd83a.1581015491.git.hongyxia@amazon.com/
   * EPT: At the moment an guest page-tabel walk requires about 20 map/unmap.
     This will have an very high impact on the performance. We need to decide
     whether keep the EPT always mapped is a problem

The original series didn't have support for Arm64. But as there were
some interest, I have provided a PoC.

There are more extra work for Arm64:
   * The mapcache is quite simple. We would investigate the performance
   * The mapcache should be made compliant to the Arm Arm (this is now
     more critical).
   * We will likely have the same problem as for the EPT.
   * We have no support for merging table to a superpage, neither
     free empty page-tables. (See more below)

=== Implementation ===

The subject is probably a misnomer. The directmap is still present but
the RAM is not mapped by default. Instead, the region will still be used
to map pages allocate via alloc_xenheap_pages().

The advantage is the solution is simple (so IHMO good enough for been
merged as a tech preview). The disadvantage is the page allocator is not
trying to keep all the xenheap pages together. So we may end up to have
an increase of page table usage.

In the longer term, we should consider to remove the direct map
completely and switch to vmap(). The main problem with this approach
is it is frequent to use mfn_to_virt() in the code. So we would need
to cache the mapping (maybe in the struct page_info).

=== Why arm32 is not covered? ===

On Arm32, the domheap and xenheap is always separated. So by design
the guest memory is not mapped by default.

At this stage, it seems unnecessary to have to map/unmap xenheap pages
every time they are allocated.

=== Why not using a separate domheap and xenheap? ===

While a separate xenheap/domheap reduce the page-table usage (all
xenheap pages are contiguous and could be always mapped), it is also
currently less scalable because the split is fixed at boot time (XXX:
Can this be dynamic?).

=== Future of secret-free hypervisor ===

There are some information in an e-mail from Andrew a few years ago:

https://lore.kernel.org/xen-devel/e3219697-0759-39fc-2486-715cdec1ca9e@citrix.com/

Cheers,

[1] https://lore.kernel.org/xen-devel/cover.1588278317.git.hongyxia@amazon.com/

Alejandro Vallejo (1):
  xen/arm32: Hardwire zeroeth_table_offset to 0 on ARM_32

Hongyan Xia (8):
  x86: Create per-domain mapping for guest_root_pt
  x86/pv: Rewrite how building PV dom0 handles domheap mappings
  x86: Add a boot option to enable and disable the direct map
  x86/domain_page: Remove the fast paths when mfn is not in the
    directmap
  xen/page_alloc: Add a path for xenheap when there is no direct map
  x86/setup: Leave early boot slightly earlier
  xen/page_alloc: vmap heap nodes when they are outside the direct map
  x86/setup: Do not create valid mappings when directmap=no

Julien Grall (4):
  xen/x86: Add support for the PMAP
  xen/arm64: mm: Use per-pCPU page-tables
  xen/arm64: Implement a mapcache for arm64
  xen/arm64: Allow the admin to enable/disable the directmap

Wei Liu (2):
  x86/pv: Use copy_domain_page() to manage domheap pages during initrd
    relocation
  x86: Initialize mapcache for PV, HVM, and idle domains

 docs/misc/xen-command-line.pandoc      | 11 ++++
 xen/arch/arm/Kconfig                   |  3 +-
 xen/arch/arm/arm32/mmu/mm.c            |  1 +
 xen/arch/arm/arm64/mmu/mm.c            | 51 ++++++++++++++-
 xen/arch/arm/include/asm/arm32/mm.h    |  8 ---
 xen/arch/arm/include/asm/arm64/mm.h    |  7 +-
 xen/arch/arm/include/asm/domain_page.h | 13 ++++
 xen/arch/arm/include/asm/lpae.h        |  2 +-
 xen/arch/arm/include/asm/mm.h          |  8 +++
 xen/arch/arm/include/asm/mmu/layout.h  | 13 +++-
 xen/arch/arm/include/asm/mmu/mm.h      |  2 +
 xen/arch/arm/mmu/domain_page.c         | 45 +++++++++++--
 xen/arch/arm/mmu/pt.c                  | 12 ++--
 xen/arch/arm/mmu/setup.c               | 23 +++----
 xen/arch/arm/mmu/smpboot.c             | 16 +----
 xen/arch/arm/setup.c                   |  3 +
 xen/arch/x86/Kconfig                   |  1 +
 xen/arch/x86/domain.c                  | 13 +++-
 xen/arch/x86/domain_page.c             | 80 ++++++++++++++++------
 xen/arch/x86/include/asm/config.h      | 10 ++-
 xen/arch/x86/include/asm/domain.h      | 15 +++--
 xen/arch/x86/include/asm/fixmap.h      | 31 +++++++++
 xen/arch/x86/include/asm/mm.h          |  6 ++
 xen/arch/x86/include/asm/pmap.h        | 35 ++++++++++
 xen/arch/x86/mm.c                      | 13 ++++
 xen/arch/x86/pv/dom0_build.c           | 70 ++++++++++++++------
 xen/arch/x86/pv/domain.c               | 44 +++++++++++--
 xen/arch/x86/setup.c                   | 91 +++++++++++++++++++++++---
 xen/arch/x86/spec_ctrl.c               |  7 ++
 xen/arch/x86/x86_64/asm-offsets.c      |  1 +
 xen/arch/x86/x86_64/entry.S            |  9 ++-
 xen/common/Kconfig                     | 22 +++++++
 xen/common/page_alloc.c                | 68 ++++++++++++++++---
 xen/include/xen/mm.h                   | 11 ++++
 34 files changed, 613 insertions(+), 132 deletions(-)
 create mode 100644 xen/arch/arm/include/asm/domain_page.h
 create mode 100644 xen/arch/x86/include/asm/pmap.h

-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 15:19:12 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 15:19:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867480.1279014 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXpq-0000A7-BL; Wed, 08 Jan 2025 15:19:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867480.1279014; Wed, 08 Jan 2025 15:19:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXpq-00009y-7s; Wed, 08 Jan 2025 15:19:06 +0000
Received: by outflank-mailman (input) for mailman id 867480;
 Wed, 08 Jan 2025 15:19:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=HyFE=UA=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tVXpo-0008Ue-QQ
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 15:19:04 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e4744bb5-cdd3-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 16:19:02 +0100 (CET)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-aaec61d0f65so285320266b.1
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 07:19:02 -0800 (PST)
Received: from localhost.localdomain ([66.81.170.107])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0eae71desm2488412166b.89.2025.01.08.07.19.00
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 07:19:01 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e4744bb5-cdd3-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736349542; x=1736954342; 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=XjrHpoafwPytgBLLE9UWiWZhowYUy5r4Ft9RDVMVLUE=;
        b=BsK/awXxL3rqIgDMLE74aaE63ujSQ2fhVdgh/kWRIynhd6ZsrLfipJqNuF49i4mcA/
         h5RQKPKH2e4t5hRYQAHXTvUfK/tND+84iil7xP0SPoYH8dT983wZU2O5gZulYbvpORwO
         2sUUzPge1ahR8V34KGNIMNvD/72Ntc6/jZvG4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736349542; x=1736954342;
        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=XjrHpoafwPytgBLLE9UWiWZhowYUy5r4Ft9RDVMVLUE=;
        b=TnLdQ3GsSmzH2pWP7mFdaX6I+fpr1/MO0MZxNLRw79F33Crhnjp0evIT0gGQPy7p5A
         jd8Uhi4GFecFpBr5T1mBgQE2vpFipaTf+ESwVRUgt7djyjvAt2FSc/BtSii4WbQlNYqF
         LR4OpgHiSY6mW8y6GHmEoPSOWRJGwwsf0N6OFPSgR3psln6J8+oKt3XTOrEV697zl2ET
         DOyCiPc0pAQk8dlZ0Mc4FjQTixK1oOeLquJLgBwLVVslsISEDgXZyn2e4Xsl5nCemY07
         2c5EdcY6IR7dBjqSrW9a6ajPzuEa74tYS4E1TFMFM7nGLmZ5S8Me6lgz0QryUrtkW4j1
         yOfg==
X-Gm-Message-State: AOJu0YyfeUFCI2EeQ7dktdc9agOInHY8pvHe1L6R4DXMN4KeJ+Xb9WBA
	h6X8nf2eCJ1MU8RCKzk9crPLvv4TzWKcCtN+pvRi8cFjr+XmS6YAJUDOw2+hRQgcmHiG3b00nr9
	Cyq2UQQ==
X-Gm-Gg: ASbGncs+SRfjSGY6gz+F/sVqefvmLVaDoOtvT2pRix9wxyTHMcZVOHl0wm/s3BQkaHc
	zdZ4Jr87a4USk/Ch2BCWtAhOhhxqus27twt2DhsWWJkxg67KQm8LgZ97eUq8PfjXDW21pSTslmt
	Lt34SdnGe3vyEwAxacNmDekmI2Bslo5zcEcMe240AEUKZQK7/iP2GNCzj0n83NX9VAkNZ0jHTFk
	Gp5CQsC3aUHm4VDb5gsCKkfI5g4mhA77zBYOMCXSEM+1IMDGUnutXnEfJRPPIT05yukR/cW4z2l
	5zw=
X-Google-Smtp-Source: AGHT+IFy2qJHO7J67PwIOe0KP7iXXVioCmlPY6UKUmkZiRaVm0XX4FKWhIb/MWinoqrJ0CU6MUY5UA==
X-Received: by 2002:a17:907:1c93:b0:aa6:894c:84b9 with SMTP id a640c23a62f3a-ab2ab6a4da6mr267067066b.23.1736349541822;
        Wed, 08 Jan 2025 07:19:01 -0800 (PST)
From: Alejandro Vallejo <alejandro.vallejo@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Hongyan Xia <hongyxia@amazon.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Julien Grall <jgrall@amazon.com>,
	Elias El Yandouzi <eliasely@amazon.com>,
	Alejandro Vallejo <alejandro.vallejo@cloud.com>
Subject: [PATCH v5 01/15] x86: Create per-domain mapping for guest_root_pt
Date: Wed,  8 Jan 2025 15:18:08 +0000
Message-ID: <20250108151822.16030-2-alejandro.vallejo@cloud.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250108151822.16030-1-alejandro.vallejo@cloud.com>
References: <20250108151822.16030-1-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Hongyan Xia <hongyxia@amazon.com>

This patch introduces a per-domain mapping for the `guest_root_pt` in PV
guests as part of the effort to remove the direct map in Xen.

For the time being, the `root_pgt` is not mapped or unmapped, as it
remains
a Xenheap page. This will be addressed in subsequent patches.

Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
Signed-off-by: Julien Grall <jgrall@amazon.com>
Signed-off-by: Elias El Yandouzi <eliasely@amazon.com>
Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
---
v4->v5:
  * bugfix: s/FREE_XENHEAP_PAGE/XFREE/ on destroying root_pt_l1tab.
  * Add a few extra comments to the declarations for sanity's sake.
  * Refactor pv_root_pt macro to use L1_PAGETABLE_ENTRIES instead.
  * Removed extra newline in pv_destory_root_pt_l1tab()

v3->v4:
  * Fix over-allocation issue
  * Update the mappings when switching from kernel to user-mode

v2->v3:
  * Rename SHADOW_ROOT
  * Haven't addressed the potentially over-allocation issue as I don't
get it

v1->v2:
  * Rework the shadow perdomain mapping solution in the follow-up
patches

Changes since Hongyan's version:
  * Remove the final dot in the commit title

Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
---
 xen/arch/x86/include/asm/config.h | 10 ++++++-
 xen/arch/x86/include/asm/domain.h |  3 +++
 xen/arch/x86/mm.c                 | 13 +++++++++
 xen/arch/x86/pv/domain.c          | 44 ++++++++++++++++++++++++++++---
 xen/arch/x86/x86_64/asm-offsets.c |  1 +
 xen/arch/x86/x86_64/entry.S       |  9 ++++++-
 6 files changed, 74 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/include/asm/config.h b/xen/arch/x86/include/asm/config.h
index 19746f956ec3..42c8a120e7dc 100644
--- a/xen/arch/x86/include/asm/config.h
+++ b/xen/arch/x86/include/asm/config.h
@@ -168,7 +168,7 @@
 /* Slot 260: per-domain mappings (including map cache). */
 #define PERDOMAIN_VIRT_START    (PML4_ADDR(260))
 #define PERDOMAIN_SLOT_MBYTES   (PML4_ENTRY_BYTES >> (20 + PAGETABLE_ORDER))
-#define PERDOMAIN_SLOTS         3
+#define PERDOMAIN_SLOTS         4
 #define PERDOMAIN_VIRT_SLOT(s)  (PERDOMAIN_VIRT_START + (s) * \
                                  (PERDOMAIN_SLOT_MBYTES << 20))
 /* Slot 4: mirror of per-domain mappings (for compat xlat area accesses). */
@@ -282,6 +282,14 @@ extern unsigned long xen_phys_start;
 #define ARG_XLAT_START(v)        \
     (ARG_XLAT_VIRT_START + ((v)->vcpu_id << ARG_XLAT_VA_SHIFT))
 
+/* pv_root_pt mapping area. The fourth per-domain-mapping sub-area */
+#define PV_ROOT_PT_MAPPING_VIRT_START   PERDOMAIN_VIRT_SLOT(3)
+#define PV_ROOT_PT_MAPPING_ENTRIES      MAX_VIRT_CPUS
+
+/* The address of a particular VCPU's PV_ROOT_PT */
+#define PV_ROOT_PT_MAPPING_VCPU_VIRT_START(v) \
+    (PV_ROOT_PT_MAPPING_VIRT_START + ((v)->vcpu_id * PAGE_SIZE))
+
 #define ELFSIZE 64
 
 #define ARCH_CRASH_SAVE_VMCOREINFO
diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h
index b79d6badd71c..b5a14991ca0b 100644
--- a/xen/arch/x86/include/asm/domain.h
+++ b/xen/arch/x86/include/asm/domain.h
@@ -273,6 +273,9 @@ struct pv_domain
 {
     l1_pgentry_t **gdt_ldt_l1tab;
 
+    /* Array of pointers to the l1 PTs holding PV root PTs of each vCPU */
+    l1_pgentry_t **root_pt_l1tab;
+
     atomic_t nr_l4_pages;
 
     /* Is a 32-bit PV guest? */
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index fa21903eb25a..adcc0b5ff328 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -527,6 +527,14 @@ void make_cr3(struct vcpu *v, mfn_t mfn)
         v->arch.cr3 |= get_pcid_bits(v, false);
 }
 
+/* Index of the l1 PT that maps v's root PT */
+#define pv_root_pt_idx(v) ((v)->vcpu_id / L1_PAGETABLE_ENTRIES)
+
+/* Pointer to the PTE that maps v's root PT in the perdomain area */
+#define pv_root_pt_pte(v) \
+    ((v)->domain->arch.pv.root_pt_l1tab[pv_root_pt_idx(v)] + \
+     ((v)->vcpu_id & (L1_PAGETABLE_ENTRIES - 1)))
+
 void write_ptbase(struct vcpu *v)
 {
     const struct domain *d = v->domain;
@@ -538,11 +546,16 @@ void write_ptbase(struct vcpu *v)
 
     if ( is_pv_domain(d) && d->arch.pv.xpti )
     {
+        mfn_t guest_root_pt = _mfn(MASK_EXTR(v->arch.cr3, X86_CR3_ADDR_MASK));
+        l1_pgentry_t *pte = pv_root_pt_pte(v);
+
         cpu_info->root_pgt_changed = true;
         cpu_info->pv_cr3 = __pa(this_cpu(root_pgt));
         if ( new_cr4 & X86_CR4_PCIDE )
             cpu_info->pv_cr3 |= get_pcid_bits(v, true);
         switch_cr3_cr4(v->arch.cr3, new_cr4);
+
+        l1e_write(pte, l1e_from_mfn(guest_root_pt, __PAGE_HYPERVISOR_RO));
     }
     else
     {
diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
index 7aef628f55be..4b85a02d910e 100644
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -289,6 +289,20 @@ static void pv_destroy_gdt_ldt_l1tab(struct vcpu *v)
                               1U << GDT_LDT_VCPU_SHIFT);
 }
 
+static int pv_create_root_pt_l1tab(const struct vcpu *v)
+{
+    return create_perdomain_mapping(v->domain,
+                                    PV_ROOT_PT_MAPPING_VCPU_VIRT_START(v),
+                                    1, v->domain->arch.pv.root_pt_l1tab,
+                                    NULL);
+}
+
+static void pv_destroy_root_pt_l1tab(const struct vcpu *v)
+{
+    destroy_perdomain_mapping(v->domain,
+                              PV_ROOT_PT_MAPPING_VCPU_VIRT_START(v), 1);
+}
+
 void pv_vcpu_destroy(struct vcpu *v)
 {
     if ( is_pv_32bit_vcpu(v) )
@@ -298,6 +312,7 @@ void pv_vcpu_destroy(struct vcpu *v)
     }
 
     pv_destroy_gdt_ldt_l1tab(v);
+    pv_destroy_root_pt_l1tab(v);
     XFREE(v->arch.pv.trap_ctxt);
 }
 
@@ -312,6 +327,13 @@ int pv_vcpu_initialise(struct vcpu *v)
     if ( rc )
         return rc;
 
+    if ( v->domain->arch.pv.xpti )
+    {
+        rc = pv_create_root_pt_l1tab(v);
+        if ( rc )
+            goto done;
+    }
+
     BUILD_BUG_ON(X86_NR_VECTORS * sizeof(*v->arch.pv.trap_ctxt) >
                  PAGE_SIZE);
     v->arch.pv.trap_ctxt = xzalloc_array(struct trap_info, X86_NR_VECTORS);
@@ -347,10 +369,12 @@ void pv_domain_destroy(struct domain *d)
 
     destroy_perdomain_mapping(d, GDT_LDT_VIRT_START,
                               GDT_LDT_MBYTES << (20 - PAGE_SHIFT));
+    destroy_perdomain_mapping(d, PV_ROOT_PT_MAPPING_VIRT_START, d->max_vcpus);
 
     XFREE(d->arch.pv.cpuidmasks);
 
     FREE_XENHEAP_PAGE(d->arch.pv.gdt_ldt_l1tab);
+    XFREE(d->arch.pv.root_pt_l1tab);
 }
 
 void noreturn cf_check continue_pv_domain(void);
@@ -376,8 +400,22 @@ int pv_domain_initialise(struct domain *d)
          (d->arch.pv.cpuidmasks = xmemdup(&cpuidmask_defaults)) == NULL )
         goto fail;
 
+    rc = create_perdomain_mapping(d, PV_ROOT_PT_MAPPING_VIRT_START,
+                                  d->max_vcpus, NULL, NULL);
+    if ( rc )
+        goto fail;
+
     d->arch.ctxt_switch = &pv_csw;
 
+    if ( d->arch.pv.xpti )
+    {
+        d->arch.pv.root_pt_l1tab =
+            xzalloc_array(l1_pgentry_t *,
+                          DIV_ROUND_UP(d->max_vcpus, L1_PAGETABLE_ENTRIES));
+        if ( !d->arch.pv.root_pt_l1tab )
+            goto fail;
+    }
+
     if ( !is_pv_32bit_domain(d) && use_invpcid && cpu_has_pcid )
         switch ( ACCESS_ONCE(opt_pcid) )
         {
@@ -451,7 +489,8 @@ static void _toggle_guest_pt(struct vcpu *v)
             guest_update = false;
         }
     }
-    write_cr3(cr3);
+
+    write_ptbase(v);
 
     if ( !pagetable_is_null(old_shadow) )
         shadow_put_top_level(v->domain, old_shadow);
@@ -491,9 +530,6 @@ void toggle_guest_mode(struct vcpu *v)
     {
         struct cpu_info *cpu_info = get_cpu_info();
 
-        cpu_info->root_pgt_changed = true;
-        cpu_info->pv_cr3 = __pa(this_cpu(root_pgt)) |
-                           (d->arch.pv.pcid ? get_pcid_bits(v, true) : 0);
         /*
          * As in _toggle_guest_pt() the XPTI CR3 write needs to be a TLB-
          * flushing one too for shadow mode guests.
diff --git a/xen/arch/x86/x86_64/asm-offsets.c b/xen/arch/x86/x86_64/asm-offsets.c
index 630bdc39451d..c1ae5013af96 100644
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -80,6 +80,7 @@ void __dummy__(void)
 
 #undef OFFSET_EF
 
+    OFFSET(VCPU_id, struct vcpu, vcpu_id);
     OFFSET(VCPU_processor, struct vcpu, processor);
     OFFSET(VCPU_domain, struct vcpu, domain);
     OFFSET(VCPU_vcpu_info, struct vcpu, vcpu_info_area.map);
diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
index 40d094d5b2ee..4de41ce743c7 100644
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -170,9 +170,16 @@ FUNC_LOCAL(restore_all_guest)
         movabs $PADDR_MASK & PAGE_MASK, %rsi
         movabs $DIRECTMAP_VIRT_START, %rcx
         and   %rsi, %rdi
-        and   %r9, %rsi
         add   %rcx, %rdi
+
+        /*
+         * The address in the vCPU cr3 is always mapped in the per-domain
+         * pv_root_pt virt area.
+         */
+        imul  $PAGE_SIZE, VCPU_id(%rbx), %esi
+        movabs $PV_ROOT_PT_MAPPING_VIRT_START, %rcx
         add   %rcx, %rsi
+
         mov   $ROOT_PAGETABLE_FIRST_XEN_SLOT, %ecx
         mov   root_table_offset(SH_LINEAR_PT_VIRT_START)*8(%rsi), %r8
         mov   %r8, root_table_offset(SH_LINEAR_PT_VIRT_START)*8(%rdi)
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 15:19:12 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 15:19:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867485.1279065 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXpv-0001OW-19; Wed, 08 Jan 2025 15:19:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867485.1279065; Wed, 08 Jan 2025 15:19:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXpu-0001Nk-Nm; Wed, 08 Jan 2025 15:19:10 +0000
Received: by outflank-mailman (input) for mailman id 867485;
 Wed, 08 Jan 2025 15:19:08 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=HyFE=UA=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tVXps-0008Lg-GL
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 15:19:08 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e78e75fd-cdd3-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 16:19:08 +0100 (CET)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-aa67ac42819so2455543566b.0
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 07:19:07 -0800 (PST)
Received: from localhost.localdomain ([66.81.170.107])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0eae71desm2488412166b.89.2025.01.08.07.19.06
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 07:19:06 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e78e75fd-cdd3-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736349547; x=1736954347; 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=yjMmCnPvYhGWKY9jq+47lrrCTBXbD9mgdkXdbRy6L+U=;
        b=T93PYqB+WYv9aZXqGBBSHyzcJ12AJYpjmKiI8tLy0XIN3Ff2sBCULlOJTRnpg+kt3t
         EayJEpoioR6l92BSCOdvF1KA/fkfVAiL6eP1mxr5BLGxA7A5c+hMlDo3VYnRRrB2I3WH
         q24QD4WPuoJTFlv//KWTU25yySKyhYeOHa4OE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736349547; x=1736954347;
        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=yjMmCnPvYhGWKY9jq+47lrrCTBXbD9mgdkXdbRy6L+U=;
        b=Pb5k16uYU5fPwzxXi/yiEaPQRN5YPbFEgnkYAo86jLLTdodT8nJxSV6imgF+v4ujsf
         e9DFptFEV5q6w5udN7tjhmJTDcIYGVQp7nkpbxlf8jkJw3lw3TwE3IDm8bAQyUP0MoH2
         EQ8dPz1yNAd7rC3cWf70z/IQhM4aNGuPAafaBhfue0k1RDDMkeqZJo+eG1/5vUjCWyIc
         AIsfia7SYRlDy9Zr3nvJGrOCy0fLaWZjFcHxVPs/wHhDDZpoiMU5RPLDAT+Ie9FCcg60
         LWEwly3PJzUz0NUN9u6yMa/BRepARL6h3WCnvl+OHb0bqMX3EpIE8khrne71bqyGjXti
         XKvw==
X-Gm-Message-State: AOJu0Yw9W6tB21VJ634nXKI2jDk1kvQRJ4UKl+O5D4wKMXNguKCt2u+h
	WGOcgan975qlVowuCRoIjrb8cIpsXNJuhvZsIp5415zQZX0BHDm8yl8UJ0L5ThswC3PyLsLK7wC
	Idmigrg==
X-Gm-Gg: ASbGncsEG3s6loO5wSrzJw13jMdmIIT+mtqAqF2Fn9UezBX6HXpkW4PF6h7xNddHoI7
	tf9yBiLTmZfu8depvCGLlGNk+Wpk08KacXfUevGZYP4KrH4E6DrysLGvZTHnSiZpXdIXgRftUsw
	YgLewGqjmbxa/+0qVLMP+XglF02+LJaNN9b1I9VIlNakM/y6yWK2cZ6uZjTvaoVqbqFvFjOby5E
	n8w6sFVAuQfHalya8rrpXNV+/P2LgqljnfopNaQIgkIwmOdG526ZH9hLJrFH7n9Cper5KhF0Wyp
	2a4=
X-Google-Smtp-Source: AGHT+IHm+GlwZHnqvLphieP9LH0FVfXA/XTlt6gMtPQsfzpf8oMG9ZAYuETNdwTvWKs+ujchLnpC2w==
X-Received: by 2002:a17:907:94c8:b0:aaf:7321:f05a with SMTP id a640c23a62f3a-ab2abc6e773mr279314766b.46.1736349547208;
        Wed, 08 Jan 2025 07:19:07 -0800 (PST)
From: Alejandro Vallejo <alejandro.vallejo@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Julien Grall <jgrall@amazon.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Elias El Yandouzi <eliasely@amazon.com>,
	Alejandro Vallejo <alejandro.vallejo@cloud.com>
Subject: [PATCH v5 06/15] xen/x86: Add support for the PMAP
Date: Wed,  8 Jan 2025 15:18:13 +0000
Message-ID: <20250108151822.16030-7-alejandro.vallejo@cloud.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250108151822.16030-1-alejandro.vallejo@cloud.com>
References: <20250108151822.16030-1-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Julien Grall <jgrall@amazon.com>

PMAP will be used in a follow-up patch to bootstrap map domain
page infrastructure -- we need some way to map pages to setup the
mapcache without a direct map.

The functions pmap_{map, unmap} open code {set, clear}_fixmap to break
the loop.

Signed-off-by: Julien Grall <jgrall@amazon.com>
Signed-off-by: Elias El Yandouzi <eliasely@amazon.com>
Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
---
v4->v5:
  * No changes.

v3->v4:
  * Select PMAP KConfig option iff ONDEMAND_DIRECTMAP is used

v2->v3:
  * No changes.

v1->v2:
  * Declare PMAP entries earlier in fixed_addresses
  * Reword the commit message

    The PMAP infrastructure was upstream separately for Arm since
    Hongyan sent the secret-free hypervisor series. So this is a new
    patch to plumb the feature on x86.
---
 xen/arch/x86/include/asm/fixmap.h |  6 ++++++
 xen/arch/x86/include/asm/pmap.h   | 35 +++++++++++++++++++++++++++++++
 xen/common/Kconfig                |  1 +
 3 files changed, 42 insertions(+)
 create mode 100644 xen/arch/x86/include/asm/pmap.h

diff --git a/xen/arch/x86/include/asm/fixmap.h b/xen/arch/x86/include/asm/fixmap.h
index 516ec3fa6c95..80b7b74fd816 100644
--- a/xen/arch/x86/include/asm/fixmap.h
+++ b/xen/arch/x86/include/asm/fixmap.h
@@ -21,6 +21,8 @@
 
 #include <xen/acpi.h>
 #include <xen/pfn.h>
+#include <xen/pmap.h>
+
 #include <asm/apicdef.h>
 #include <asm/msi.h>
 #include <acpi/apei.h>
@@ -53,6 +55,10 @@ enum fixed_addresses {
     FIX_PV_CONSOLE,
     FIX_XEN_SHARED_INFO,
 #endif /* CONFIG_XEN_GUEST */
+#ifdef CONFIG_HAS_PMAP
+    FIX_PMAP_BEGIN,
+    FIX_PMAP_END = FIX_PMAP_BEGIN + NUM_FIX_PMAP,
+#endif
     /* Everything else should go further down. */
     FIX_APIC_BASE,
     FIX_IO_APIC_BASE_0,
diff --git a/xen/arch/x86/include/asm/pmap.h b/xen/arch/x86/include/asm/pmap.h
new file mode 100644
index 000000000000..1b3b729b90b2
--- /dev/null
+++ b/xen/arch/x86/include/asm/pmap.h
@@ -0,0 +1,35 @@
+#ifndef __ASM_PMAP_H__
+#define __ASM_PMAP_H__
+
+#include <asm/fixmap.h>
+
+static inline void arch_pmap_map(unsigned int slot, mfn_t mfn)
+{
+    unsigned long linear = (unsigned long)fix_to_virt(slot);
+    l1_pgentry_t *pl1e = &l1_fixmap[l1_table_offset(linear)];
+
+    BUILD_BUG_ON(FIX_APIC_BASE - 1 > L1_PAGETABLE_ENTRIES - 1);
+    ASSERT(!(l1e_get_flags(*pl1e) & _PAGE_PRESENT));
+
+    l1e_write(pl1e, l1e_from_mfn(mfn, PAGE_HYPERVISOR));
+}
+
+static inline void arch_pmap_unmap(unsigned int slot)
+{
+    unsigned long linear = (unsigned long)fix_to_virt(slot);
+    l1_pgentry_t *pl1e = &l1_fixmap[l1_table_offset(linear)];
+
+    l1e_write(pl1e, l1e_empty());
+    flush_tlb_one_local(linear);
+}
+
+#endif /* __ASM_PMAP_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 1ee498a3e9a7..5b22b09a4fbc 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -220,6 +220,7 @@ config SPECULATIVE_HARDEN_LOCK
 config ONDEMAND_DIRECTMAP
 	bool "On-Demand Directmap"
 	depends on HAS_ONDEMAND_DIRECTMAP
+	select HAS_PMAP
 	help
 	  Contemporary processors may use speculative execution as a
 	  performance optimisation, but this can potentially be abused by an
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 15:19:14 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 15:19:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867489.1279092 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXpy-0002El-EL; Wed, 08 Jan 2025 15:19:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867489.1279092; Wed, 08 Jan 2025 15:19:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXpy-0002DT-4b; Wed, 08 Jan 2025 15:19:14 +0000
Received: by outflank-mailman (input) for mailman id 867489;
 Wed, 08 Jan 2025 15:19:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=HyFE=UA=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tVXpv-0008Lg-Ro
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 15:19:11 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e99c4ecb-cdd3-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 16:19:11 +0100 (CET)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-aa68b513abcso3100450766b.0
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 07:19:11 -0800 (PST)
Received: from localhost.localdomain ([66.81.170.107])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0eae71desm2488412166b.89.2025.01.08.07.19.09
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 07:19:10 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e99c4ecb-cdd3-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736349550; x=1736954350; 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=B1o5uv9Ja6v4/kcOJ8sZumXTXa5wvZv/gHrWxF6fu20=;
        b=ImEbpo7Rpm9n0aWOQ9skx4qvVdzUoRCxEVh9CJM1cOhiTmZ3YGJG/jEKeXF2dB8evM
         7vVqq5EZZz7UO/tm1NJL5Dr0+RldfOxPXv10MXFKHyTXWDEOr+zmxrAX5PKObJJJMUef
         +7ylvgud9kTo/yml/lHomVdIwtIgSiG2/o6mI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736349550; x=1736954350;
        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=B1o5uv9Ja6v4/kcOJ8sZumXTXa5wvZv/gHrWxF6fu20=;
        b=dP93HiOXpi0H6LLmRwfRKdolD2BBd3giREzMBgbhMx+52WFVM0yMVJ8r5kmmjPvXCY
         hr/0BUfGeGuOKLBnxX8k+5WIuXUdc0X4sVwwbXJIGTWl4e9y6YmsUmIQGGHjnNK0fPvz
         OUF6DunkzmTD9xSqCoqDIjAPUxPkzwIc3CPOTsrntp0IJ8brAHHzN+yts0pYQqMTXUNK
         BYYKMNq9L/TrTe0SpkgxADW+0taEr0YxX+r4IEUEIkllt6VPMB1wUm+enZRNfp4SQy/D
         XuFMzbu6vkdE+XHPQuFolt2nynLCEUcsoBTTRdovO2hdtYkM4D1hajeHbqFozTOc01L4
         D91Q==
X-Gm-Message-State: AOJu0YzPT4VQd+yZKP5l7V46F83y/+6bHCADx5UXAPjN47VMmv1cEKcj
	KdYaZcmA63eZijJh4M0p1jYVyMiq7hC5iHll2iLViFPEMIqi+FZ6WS0ioMtAZWbQKemUnCO6tNq
	vzIqtOA==
X-Gm-Gg: ASbGnct0WZ5HM5U2i1ScDyyP222JB3RDyb1siH5NE9FBUJshrKsw4zkysKFjp4psLSc
	0bosRp91DVG2wSTOimSpf1irCO3UNy1/5pJ57fOInR9+IQyWL6RUe/+UnYVpPMmaaO37egbRCM3
	AKRQfkg7WpvVywWBrlrKEUg/hXUFji7CGr6v9424wVTOduJ2ak7M+OBElhSJXhRXspOxkP2joIg
	GkOHG/YfXSjJZCx0dRcl7p1SxpS7lD4YibvyjYuO0/BpobfP59E3ScuHOYhL8plki+Vl+8VZclv
	55s=
X-Google-Smtp-Source: AGHT+IFmAfbrkaRmO1XEvxpuHTtJZiGpHLiJR0cpXNNmmNnQWLh9ejYwG1frtDsro+4RNSQ6b49m0g==
X-Received: by 2002:a17:907:7286:b0:aa6:89b9:e9c0 with SMTP id a640c23a62f3a-ab2ab6a7624mr229884666b.8.1736349550502;
        Wed, 08 Jan 2025 07:19:10 -0800 (PST)
From: Alejandro Vallejo <alejandro.vallejo@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Hongyan Xia <hongyxia@amazon.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Julien Grall <jgrall@amazon.com>,
	Elias El Yandouzi <eliasely@amazon.com>,
	Alejandro Vallejo <alejandro.vallejo@cloud.com>
Subject: [PATCH v5 09/15] x86/setup: Leave early boot slightly earlier
Date: Wed,  8 Jan 2025 15:18:16 +0000
Message-ID: <20250108151822.16030-10-alejandro.vallejo@cloud.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250108151822.16030-1-alejandro.vallejo@cloud.com>
References: <20250108151822.16030-1-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Hongyan Xia <hongyxia@amazon.com>

When we do not have a direct map, memory for metadata of heap nodes in
init_node_heap() is allocated from xenheap, which needs to be mapped and
unmapped on demand. However, we cannot just take memory from the boot
allocator to create the PTEs while we are passing memory to the heap
allocator.

To solve this race, we leave early boot slightly sooner so that Xen PTE
pages are allocated from the heap instead of the boot allocator. We can
do this because the metadata for the 1st node is statically allocated,
and by the time we need memory to create mappings for the 2nd node, we
already have enough memory in the heap allocator in the 1st node.

Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
Signed-off-by: Julien Grall <jgrall@amazon.com>
Signed-off-by: Elias El Yandouzi <eliasely@amazon.com>
Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
---
v4->v5:
  * No changes.

v3->v4:
  * Fix indentation
  * Refactor the code to reduce code duplication
---
 xen/arch/x86/setup.c | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 8ebe5a9443f3..609ec4cf07f2 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1831,6 +1831,22 @@ void asmlinkage __init noreturn __start_xen(void)
 
     numa_initmem_init(0, raw_max_page);
 
+    /*
+     * When we do not have a direct map, memory for metadata of heap nodes in
+     * init_node_heap() is allocated from xenheap, which needs to be mapped and
+     * unmapped on demand. However, we cannot just take memory from the boot
+     * allocator to create the PTEs while we are passing memory to the heap
+     * allocator during end_boot_allocator().
+     *
+     * To solve this race, we need to leave early boot before
+     * end_boot_allocator() so that Xen PTE pages are allocated from the heap
+     * instead of the boot allocator. We can do this because the metadata for
+     * the 1st node is statically allocated, and by the time we need memory to
+     * create mappings for the 2nd node, we already have enough memory in the
+     * heap allocator in the 1st node.
+     */
+    system_state = SYS_STATE_boot;
+
     if ( max_page - 1 > virt_to_mfn(HYPERVISOR_VIRT_END - 1) )
     {
         unsigned long lo = virt_to_mfn(HYPERVISOR_VIRT_END - 1);
@@ -1862,8 +1878,6 @@ void asmlinkage __init noreturn __start_xen(void)
     else
         end_boot_allocator();
 
-    system_state = SYS_STATE_boot;
-
     bsp_stack = cpu_alloc_stack(0);
     if ( !bsp_stack )
         panic("No memory for BSP stack\n");
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 15:19:16 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 15:19:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867490.1279102 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXpz-0002Xo-W2; Wed, 08 Jan 2025 15:19:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867490.1279102; Wed, 08 Jan 2025 15:19:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXpz-0002X1-Ka; Wed, 08 Jan 2025 15:19:15 +0000
Received: by outflank-mailman (input) for mailman id 867490;
 Wed, 08 Jan 2025 15:19: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
 <SRS0=HyFE=UA=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tVXpy-0008Ue-05
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 15:19:14 +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 ea3f2af6-cdd3-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 16:19:12 +0100 (CET)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-aaee0b309adso2115822366b.3
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 07:19:12 -0800 (PST)
Received: from localhost.localdomain ([66.81.170.107])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0eae71desm2488412166b.89.2025.01.08.07.19.10
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 07:19:11 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ea3f2af6-cdd3-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736349552; x=1736954352; 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=4dAl5hiiumxZdSL6vCO/VaNqrRA8aywqXxbQG/mKtGY=;
        b=Hmh+CMApb3O8FVO4bwKJSJMyHrpRmdeiirVhb4uxxifc3B0XpmYesVCsMIgr+xx4Lc
         a2lz/ukJhHz6QcVV4fFABgoy8K3jHsbAHMd/5F9WszbzEOce1Um3G+yofi+qWZ49sZoc
         3BxutmNm50Vw4ZsSC1NsWS55fO4n+NRkgdKuk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736349552; x=1736954352;
        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=4dAl5hiiumxZdSL6vCO/VaNqrRA8aywqXxbQG/mKtGY=;
        b=kZTkqYatzkthByTWjAhvCEMdYJNkpn2U8J930MseWSXE+sAAb8oF5m70rO8QIBEGt5
         mwjTN4VRJO62ZUqelP0bop8f8GiL7GPQ96q/mQpRmhPyp3o7Abh/LIISNGwUryZM/nPs
         OVV0JIQahfoBYe7gMx+F53xPZjQdBZYSBRMFJmIT1ZqW3GnzlfFi2+29+K8aRH3+bu9Q
         QWOj1l3srNavi71gJjMsi0hn1UwhUFjOWaosAW3PZLCrvXA9CKhsPuXhTyYtemaLrE7+
         ovTb6F4wxvWLlSdNdzW8wJo41ThupJJ8jOWdSH7IidAqRKnPTtAQozbmnRQnpr2gpPn6
         O0QA==
X-Gm-Message-State: AOJu0YwGupN/Nf04gQjGhAldnAov8KxdPp+aZPYlbugIROTqya5S+Ij2
	EGBsonaUI+2cz/hZz/WVXRThEZbsREnnavcgcaOGRNK431QrFozjzHd8x9tsoM3J3al1/o6jWgR
	Ffs6f9Q==
X-Gm-Gg: ASbGncuktTLp95nko05sR9HAephjFcmBCzAGwo8N7IMbDaycp3IOv+jpW1zDdjI7chn
	q1soFU6X4JduksKwN9Zv0HCnbeO5YEpEr9qJu58xRiBWqd+e/z4B67wP9r7ip9YQzzScv7wYLU8
	3GYJFm2HE2bjTWr4pgUmOVtPV4FYUXkBUgQSgYz3SwXWNLrhorCDZd6MybdWz2VzK20kU5orMiv
	lwY9B2wyzyNsZ4iyPQWlxBGv7cl3GWHRQNAEXgVXS5d3bHbH658jH83D/byqjilc3+wnVrFnVK1
	oqY=
X-Google-Smtp-Source: AGHT+IFxfaz1of1Dy+QRE/RL4Nf+b/dHh+YwZM7uFybv3bH9J3u0daWHFg1k3w3NgvYUSIrBHUHeaQ==
X-Received: by 2002:a17:907:70c:b0:aa6:9176:61ed with SMTP id a640c23a62f3a-ab2abc6d42emr300126166b.48.1736349551627;
        Wed, 08 Jan 2025 07:19:11 -0800 (PST)
From: Alejandro Vallejo <alejandro.vallejo@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Hongyan Xia <hongyxia@amazon.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <jgrall@amazon.com>,
	Elias El Yandouzi <eliasely@amazon.com>,
	Alejandro Vallejo <alejandro.vallejo@cloud.com>
Subject: [PATCH v5 10/15] xen/page_alloc: vmap heap nodes when they are outside the direct map
Date: Wed,  8 Jan 2025 15:18:17 +0000
Message-ID: <20250108151822.16030-11-alejandro.vallejo@cloud.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250108151822.16030-1-alejandro.vallejo@cloud.com>
References: <20250108151822.16030-1-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Hongyan Xia <hongyxia@amazon.com>

When we do not have a direct map, archs_mfn_in_direct_map() will always
return false, thus init_node_heap() will allocate xenheap pages from an
existing node for the metadata of a new node. This means that the
metadata of a new node is in a different node, slowing down heap
allocation.

Since we now have early vmap, vmap the metadata locally in the new node.

Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
Signed-off-by: Julien Grall <jgrall@amazon.com>
Signed-off-by: Elias El Yandouzi <eliasely@amazon.com>
Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
---
v4->v5:
  * Fix bug introduced in v4 by which node metadata would be
    unconditionally mapped at the tail of the heap node.
  * Remove extra space in conditional

v3->v4:
  * Change type of the parameters to paddr_t
  * Use clear_domain_page() instead of open-coding it

v1->v2:
  * vmap_contig_pages() was renamed to vmap_contig()
  * Fix indentation and coding style

Changes from Hongyan's version:
  * arch_mfn_in_direct_map() was renamed to
    arch_mfns_in_direct_map()
  * Use vmap_contig_pages() rather than __vmap(...).
  * Add missing include (xen/vmap.h) so it compiles on Arm
---
 xen/common/page_alloc.c | 25 +++++++++++++++++--------
 1 file changed, 17 insertions(+), 8 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 1c01332b6cb0..3af86a213c4e 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -139,6 +139,7 @@
 #include <xen/softirq.h>
 #include <xen/spinlock.h>
 #include <xen/vm_event.h>
+#include <xen/vmap.h>
 #include <xen/xvmalloc.h>
 
 #include <asm/flushtlb.h>
@@ -615,22 +616,30 @@ static unsigned long init_node_heap(int node, unsigned long mfn,
         needed = 0;
     }
     else if ( *use_tail && nr >= needed &&
-              arch_mfns_in_directmap(mfn + nr - needed, needed) &&
               (!xenheap_bits ||
                !((mfn + nr - 1) >> (xenheap_bits - PAGE_SHIFT))) )
     {
-        _heap[node] = mfn_to_virt(mfn + nr - needed);
-        avail[node] = mfn_to_virt(mfn + nr - 1) +
-                      PAGE_SIZE - sizeof(**avail) * NR_ZONES;
+        if ( arch_mfns_in_directmap(mfn + nr - needed, needed) )
+            _heap[node] = mfn_to_virt(mfn + nr - needed);
+        else
+            _heap[node] = vmap_contig(_mfn(mfn + nr - needed), needed);
+
+        BUG_ON(!_heap[node]);
+        avail[node] = (void *)(_heap[node]) + (needed << PAGE_SHIFT) -
+                        sizeof(**avail) * NR_ZONES;
     }
     else if ( nr >= needed &&
-              arch_mfns_in_directmap(mfn, needed) &&
               (!xenheap_bits ||
                !((mfn + needed - 1) >> (xenheap_bits - PAGE_SHIFT))) )
     {
-        _heap[node] = mfn_to_virt(mfn);
-        avail[node] = mfn_to_virt(mfn + needed - 1) +
-                      PAGE_SIZE - sizeof(**avail) * NR_ZONES;
+        if ( arch_mfns_in_directmap(mfn, needed) )
+            _heap[node] = mfn_to_virt(mfn);
+        else
+            _heap[node] = vmap_contig(_mfn(mfn), needed);
+
+        BUG_ON(!_heap[node]);
+        avail[node] = (void *)(_heap[node]) + (needed << PAGE_SHIFT) -
+                        sizeof(**avail) * NR_ZONES;
         *use_tail = false;
     }
     else if ( get_order_from_bytes(sizeof(**_heap)) ==
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 15:19:17 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 15:19:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867492.1279110 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXq1-0002s0-I0; Wed, 08 Jan 2025 15:19:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867492.1279110; Wed, 08 Jan 2025 15:19:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXq1-0002r2-CQ; Wed, 08 Jan 2025 15:19:17 +0000
Received: by outflank-mailman (input) for mailman id 867492;
 Wed, 08 Jan 2025 15:19: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
 <SRS0=HyFE=UA=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tVXpz-0008Lg-IS
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 15:19:15 +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 eb7b0015-cdd3-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 16:19:14 +0100 (CET)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-aaf60d85238so1272591666b.0
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 07:19:14 -0800 (PST)
Received: from localhost.localdomain ([66.81.170.107])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0eae71desm2488412166b.89.2025.01.08.07.19.12
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 07:19:13 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: eb7b0015-cdd3-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736349554; x=1736954354; 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=mBjkyLdsM17iRKfOvcTvCdENHWOQ8GdEz5R+mPR7wOI=;
        b=OsHcG82ueMHXdbQVs94HoeEMORhwZ7cUMwx9u3+gHCIDprc1cQroBeUZae/XNlU7O2
         CbncZ7V1gB59SuHpwbuiULUAtP8uM18bwjjNJ/ENPVXaMohcPjVpgelZaC4AQOW8WpA/
         6FvucMMpkQd5rCiZsy3dR4w36Dr+ctZ9QhenU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736349554; x=1736954354;
        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=mBjkyLdsM17iRKfOvcTvCdENHWOQ8GdEz5R+mPR7wOI=;
        b=NNw7p9GA8gBr0FRruG7Ynk5WDmRKcHJn7HgeeBlJhIB6n+sWnFyFv3sNP1Me5Z1B66
         qfCw4pbEMO86O+5fSa8W0J6G6k6+Wc1Cf+1l2XPUJBNocgtSYXEUCX9cMOq5OKr2cnK5
         TziD6KJqcTK59LSwQt1tR7fm7IttDNGRzHHM/hLAWqNdo2o2ukRjJ1CZbUK8FN1r/hWr
         FfE04zT5epJ4Es98HCoCnxXTqW5OH0eLZaWRw+XrqbPWYRr+ES0GhyISdrnwU3ZFFPor
         9CElo+d/vXo5LTvvkBkJ7P3JZjYPsndUnjTLPuHkRjfOPmXmLb27sJrj9m8Z8HUithrb
         lKcg==
X-Gm-Message-State: AOJu0YwDtheWfaEVyatbIPdtCi4iCIHml2Av3Q3fR/+BZLwCGHCelGmt
	Jtd4Dv8XIoFBhQFeQEyU8KF0idKXcVwHG56xPHFd2hCa9DDyEgBaJ8IB4GVirvvWvK5tlscdR3F
	uaJAUAQ==
X-Gm-Gg: ASbGncv+0oTllUgdVf47aF6vT+vqFs8aU9eNYj1Yo5rKn4Mix29blmyd+3NMV7nDSyh
	XWIbUL6KgTtGrOeQ/cjVLXHkCFVeRt9+ZRaVf9RIMTbk5iCCBdhniTzpPFyiCM1RYbqFBBOJcSH
	EUNYkgEoMTj2i65Ebi3U3DseMneoElxjny4S0fAayBkI/D/pRZWTmn+0AJzEJggvr3jeCfLuRcs
	BgavPwL70MtpNEai/y1aIXtYUoEdLXc9sPgIfHCc+ejyS69msC7Jpi8K7mdflRy5Jv+eMWaor8t
	Btg=
X-Google-Smtp-Source: AGHT+IFr/4vVsl04wRMj0lsbKLbG9ZbWt/CJpvwrdHYprt+TFDd3PrslNZSj1LFhnlLTVEjrn+bd9Q==
X-Received: by 2002:a17:907:1b12:b0:aae:85b4:a07 with SMTP id a640c23a62f3a-ab2ab675c58mr266911366b.8.1736349553655;
        Wed, 08 Jan 2025 07:19:13 -0800 (PST)
From: Alejandro Vallejo <alejandro.vallejo@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Julien Grall <jgrall@amazon.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Elias El Yandouzi <eliasely@amazon.com>,
	Alejandro Vallejo <alejandro.vallejo@cloud.com>
Subject: [PATCH v5 12/15] xen/arm64: mm: Use per-pCPU page-tables
Date: Wed,  8 Jan 2025 15:18:19 +0000
Message-ID: <20250108151822.16030-13-alejandro.vallejo@cloud.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250108151822.16030-1-alejandro.vallejo@cloud.com>
References: <20250108151822.16030-1-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Julien Grall <jgrall@amazon.com>

At the moment, on Arm64, every pCPU is sharing the same page-tables.

In a follow-up patch, we will allow the possibility to remove the
direct map and therefore it will be necessary to have a mapcache.

While we have plenty of spare virtual address space to reserve part
for each pCPU, it means that temporary mappings (e.g. guest memory)
could be accessible by every pCPU.

In order to increase our security posture, it would be better if
those mappings are only accessible by the pCPU doing the temporary
mapping.

In addition to that, a per-pCPU page-tables opens the way to have
per-domain mapping area.

Arm32 is already using per-pCPU page-tables so most of the code
can be re-used. Arm64 doesn't yet have support for the mapcache,
so a stub is provided (moved to its own header asm/domain_page.h).

Take the opportunity to fix a typo in a comment that is modified.

Signed-off-by: Julien Grall <jgrall@amazon.com>
Signed-off-by: Elias El Yandouzi <eliasely@amazon.com>
Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
---
v4->v5:
  * Added missing asm/domain_page.h header to arm32. Compilation fails
    otherwise.
  * NOTE: I rebased this patch over the LLC coloring as best as I could
          and may have messed it up. Please do double check.
---
 xen/arch/arm/arm32/mmu/mm.c            |  1 +
 xen/arch/arm/arm64/mmu/mm.c            |  3 ++-
 xen/arch/arm/include/asm/arm32/mm.h    |  8 --------
 xen/arch/arm/include/asm/domain_page.h | 13 +++++++++++++
 xen/arch/arm/include/asm/mm.h          |  3 +++
 xen/arch/arm/include/asm/mmu/mm.h      |  2 ++
 xen/arch/arm/mmu/pt.c                  |  6 +++---
 xen/arch/arm/mmu/setup.c               | 23 ++++++++++-------------
 xen/arch/arm/mmu/smpboot.c             | 16 +---------------
 xen/arch/arm/setup.c                   |  1 +
 10 files changed, 36 insertions(+), 40 deletions(-)
 create mode 100644 xen/arch/arm/include/asm/domain_page.h

diff --git a/xen/arch/arm/arm32/mmu/mm.c b/xen/arch/arm/arm32/mmu/mm.c
index 956693232a1b..60b7f4f40512 100644
--- a/xen/arch/arm/arm32/mmu/mm.c
+++ b/xen/arch/arm/arm32/mmu/mm.c
@@ -6,6 +6,7 @@
 #include <xen/mm.h>
 #include <xen/param.h>
 #include <xen/pfn.h>
+#include <asm/domain_page.h>
 #include <asm/fixmap.h>
 #include <asm/setup.h>
 #include <asm/static-memory.h>
diff --git a/xen/arch/arm/arm64/mmu/mm.c b/xen/arch/arm/arm64/mmu/mm.c
index 26361c4fe4c0..7de5885cc776 100644
--- a/xen/arch/arm/arm64/mmu/mm.c
+++ b/xen/arch/arm/arm64/mmu/mm.c
@@ -77,6 +77,7 @@ static void __init prepare_runtime_identity_mapping(void)
     paddr_t id_addr = virt_to_maddr(_start);
     lpae_t pte;
     DECLARE_OFFSETS(id_offsets, id_addr);
+    lpae_t *root = this_cpu(xen_pgtable);
 
     if ( id_offsets[0] >= IDENTITY_MAPPING_AREA_NR_L0 )
         panic("Cannot handle ID mapping above %uTB\n",
@@ -87,7 +88,7 @@ static void __init prepare_runtime_identity_mapping(void)
     pte.pt.table = 1;
     pte.pt.xn = 0;
 
-    write_pte(&xen_pgtable[id_offsets[0]], pte);
+    write_pte(&root[id_offsets[0]], pte);
 
     /* Link second ID table */
     pte = pte_of_xenaddr((vaddr_t)xen_second_id);
diff --git a/xen/arch/arm/include/asm/arm32/mm.h b/xen/arch/arm/include/asm/arm32/mm.h
index 856f2dbec4ad..87a315db013d 100644
--- a/xen/arch/arm/include/asm/arm32/mm.h
+++ b/xen/arch/arm/include/asm/arm32/mm.h
@@ -1,12 +1,6 @@
 #ifndef __ARM_ARM32_MM_H__
 #define __ARM_ARM32_MM_H__
 
-#include <xen/percpu.h>
-
-#include <asm/lpae.h>
-
-DECLARE_PER_CPU(lpae_t *, xen_pgtable);
-
 /*
  * Only a limited amount of RAM, called xenheap, is always mapped on ARM32.
  * For convenience always return false.
@@ -16,8 +10,6 @@ static inline bool arch_mfns_in_directmap(unsigned long mfn, unsigned long nr)
     return false;
 }
 
-bool init_domheap_mappings(unsigned int cpu);
-
 static inline void arch_setup_page_tables(void)
 {
 }
diff --git a/xen/arch/arm/include/asm/domain_page.h b/xen/arch/arm/include/asm/domain_page.h
new file mode 100644
index 000000000000..e9f52685e2ec
--- /dev/null
+++ b/xen/arch/arm/include/asm/domain_page.h
@@ -0,0 +1,13 @@
+#ifndef __ASM_ARM_DOMAIN_PAGE_H__
+#define __ASM_ARM_DOMAIN_PAGE_H__
+
+#ifdef CONFIG_ARCH_MAP_DOMAIN_PAGE
+bool init_domheap_mappings(unsigned int cpu);
+#else
+static inline bool init_domheap_mappings(unsigned int cpu)
+{
+    return true;
+}
+#endif
+
+#endif /* __ASM_ARM_DOMAIN_PAGE_H__ */
diff --git a/xen/arch/arm/include/asm/mm.h b/xen/arch/arm/include/asm/mm.h
index f91ff088f6b1..07329a17fffa 100644
--- a/xen/arch/arm/include/asm/mm.h
+++ b/xen/arch/arm/include/asm/mm.h
@@ -2,6 +2,9 @@
 #define __ARCH_ARM_MM__
 
 #include <xen/kernel.h>
+#include <xen/percpu.h>
+
+#include <asm/lpae.h>
 #include <asm/page.h>
 #include <public/xen.h>
 #include <xen/pdx.h>
diff --git a/xen/arch/arm/include/asm/mmu/mm.h b/xen/arch/arm/include/asm/mmu/mm.h
index f5a00558c47b..5a8fde313693 100644
--- a/xen/arch/arm/include/asm/mmu/mm.h
+++ b/xen/arch/arm/include/asm/mmu/mm.h
@@ -2,6 +2,8 @@
 #ifndef __ARM_MMU_MM_H__
 #define __ARM_MMU_MM_H__
 
+DECLARE_PER_CPU(lpae_t *, xen_pgtable);
+
 /* Non-boot CPUs use this to find the correct pagetables. */
 extern uint64_t init_ttbr;
 
diff --git a/xen/arch/arm/mmu/pt.c b/xen/arch/arm/mmu/pt.c
index da28d669e796..1ed1a53ab1f2 100644
--- a/xen/arch/arm/mmu/pt.c
+++ b/xen/arch/arm/mmu/pt.c
@@ -607,9 +607,9 @@ static int xen_pt_update(unsigned long virt,
     unsigned long left = nr_mfns;
 
     /*
-     * For arm32, page-tables are different on each CPUs. Yet, they share
-     * some common mappings. It is assumed that only common mappings
-     * will be modified with this function.
+     * Page-tables are different on each CPU. Yet, they share some common
+     * mappings. It is assumed that only common mappings will be modified
+     * with this function.
      *
      * XXX: Add a check.
      */
diff --git a/xen/arch/arm/mmu/setup.c b/xen/arch/arm/mmu/setup.c
index 30afe9778194..d9308e0475ff 100644
--- a/xen/arch/arm/mmu/setup.c
+++ b/xen/arch/arm/mmu/setup.c
@@ -34,17 +34,15 @@
  * PCPUs.
  */
 
-#ifdef CONFIG_ARM_64
-DEFINE_PAGE_TABLE(xen_pgtable);
-static DEFINE_PAGE_TABLE(xen_first);
-#define THIS_CPU_PGTABLE xen_pgtable
-#else
 /* Per-CPU pagetable pages */
 /* xen_pgtable == root of the trie (zeroeth level on 64-bit, first on 32-bit) */
 DEFINE_PER_CPU(lpae_t *, xen_pgtable);
 #define THIS_CPU_PGTABLE this_cpu(xen_pgtable)
 /* Root of the trie for cpu0, other CPU's PTs are dynamically allocated */
 static DEFINE_PAGE_TABLE(cpu0_pgtable);
+
+#ifdef CONFIG_ARM_64
+static DEFINE_PAGE_TABLE(xen_first);
 #endif
 
 /* Common pagetable leaves */
@@ -368,17 +366,20 @@ void __init setup_pagetables(void)
     if ( llc_coloring_enabled )
         create_llc_coloring_mappings();
 
+    p = cpu0_pgtable;
+
+    /* arch_setup_page_tables() may need to access the root page-tables. */
+    per_cpu(xen_pgtable, 0) = cpu0_pgtable;
+
     arch_setup_page_tables();
 
 #ifdef CONFIG_ARM_64
     pte = pte_of_xenaddr((uintptr_t)xen_first);
     pte.pt.table = 1;
     pte.pt.xn = 0;
-    xen_pgtable[zeroeth_table_offset(XEN_VIRT_START)] = pte;
+    p[zeroeth_table_offset(XEN_VIRT_START)] = pte;
 
-    p = (void *) xen_first;
-#else
-    p = (void *) cpu0_pgtable;
+    p = xen_first;
 #endif
 
     /* Map xen second level page-table */
@@ -415,10 +416,6 @@ void __init setup_pagetables(void)
     pte.pt.table = 1;
     xen_second[second_table_offset(FIXMAP_ADDR(0))] = pte;
 
-#ifdef CONFIG_ARM_32
-    per_cpu(xen_pgtable, 0) = cpu0_pgtable;
-#endif
-
     if ( llc_coloring_enabled )
     {
         ttbr = virt_to_maddr(virt_to_reloc_virt(THIS_CPU_PGTABLE));
diff --git a/xen/arch/arm/mmu/smpboot.c b/xen/arch/arm/mmu/smpboot.c
index 37e91d72b785..e4bde31605bd 100644
--- a/xen/arch/arm/mmu/smpboot.c
+++ b/xen/arch/arm/mmu/smpboot.c
@@ -7,6 +7,7 @@
 
 #include <xen/domain_page.h>
 
+#include <asm/domain_page.h>
 #include <asm/setup.h>
 
 /* Override macros from asm/page.h to make them work with mfn_t */
@@ -93,20 +94,6 @@ static void set_init_ttbr(lpae_t *root)
     unmap_domain_page(ptr);
 }
 
-#ifdef CONFIG_ARM_64
-int prepare_secondary_mm(int cpu)
-{
-    clear_boot_pagetables();
-
-    /*
-     * Set init_ttbr for this CPU coming up. All CPUs share a single setof
-     * pagetables, but rewrite it each time for consistency with 32 bit.
-     */
-    set_init_ttbr(xen_pgtable);
-
-    return 0;
-}
-#else
 int prepare_secondary_mm(int cpu)
 {
     lpae_t *root = alloc_xenheap_page();
@@ -136,7 +123,6 @@ int prepare_secondary_mm(int cpu)
 
     return 0;
 }
-#endif
 
 /*
  * Local variables:
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index c1f2d1b89d43..3b1ab6be3fbd 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -44,6 +44,7 @@
 #include <asm/gic.h>
 #include <asm/cpuerrata.h>
 #include <asm/cpufeature.h>
+#include <asm/domain_page.h>
 #include <asm/platform.h>
 #include <asm/procinfo.h>
 #include <asm/setup.h>
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 15:19:18 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 15:19:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867493.1279117 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXq2-0002zc-JD; Wed, 08 Jan 2025 15:19:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867493.1279117; Wed, 08 Jan 2025 15:19:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXq1-0002x2-SM; Wed, 08 Jan 2025 15:19:17 +0000
Received: by outflank-mailman (input) for mailman id 867493;
 Wed, 08 Jan 2025 15:19: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
 <SRS0=HyFE=UA=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tVXpz-0008Ue-N1
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 15:19:15 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ead458f6-cdd3-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 16:19:13 +0100 (CET)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-5d3d14336f0so10201984a12.3
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 07:19:13 -0800 (PST)
Received: from localhost.localdomain ([66.81.170.107])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0eae71desm2488412166b.89.2025.01.08.07.19.11
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 07:19:12 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ead458f6-cdd3-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736349553; x=1736954353; 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=t3Cqxub2b0rcz5hsX+nKFFTBraQpc6Cf0wNJ5J2Y5Kk=;
        b=cOR7jUI+eFa3+6GqKNoZDW9t62TZUmubaP5YaQQs7ImmW3zr9En5TZdiKRrGTHIhgE
         VatN+IbZXyyUg3LJ69qV5fYS1KC1/QukHP4xiIiQaNW6oY/Lm6MmXAsKVkAbwvHB9eW7
         W+Liz95yF/wlb7Epy13g2732UIyf88a993vL4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736349553; x=1736954353;
        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=t3Cqxub2b0rcz5hsX+nKFFTBraQpc6Cf0wNJ5J2Y5Kk=;
        b=QkFCDD00ec2y29pv8ePj7/Qw2OOt+SxRFksgSkyYfq01A6NU4IsZ3LYGMTJZAg+TzS
         FZQW4lyLQBpm4tTGc6UCo+t6by3vsdJ/SfQZwnRNYkRk2fjbOCK8SkZ9jdc7Z7aYmKAF
         HHLCDJU9Uc28RG8A3qaMPrB8t99ZCUNq4yTvwOrPguaSGG76RWvhZ1FcFXAwJIoOZ/CF
         2Qhezkm1J0eDdTBkq+1GMOI+iy6PCKjLigLmNy6B0ogtOvLldavTmDUu8PDQH7kkh1yf
         5mJMYGkBrh07ForlKvBUhLduTHKQ5KZKcq4gbotUuPusflo6PAYexDjloWihEzXVCe8Y
         78uA==
X-Gm-Message-State: AOJu0Yz5br1KLIjODl8cSxZLvpim99Sj3C+LHqEPFXIuo9XvZCui8PBL
	53Kv4pH/DteJXFgwQRI73zT584FYYXYO9i0Z9XOmYC+fEDnYebLW6lAOPrHScRB6Hbi7Gm6yoLu
	l9MnlQQ==
X-Gm-Gg: ASbGnctj6efBGsPnNvXwCVYV3xU5ohpOR1KPV6hjG88yETjy15+DocYCZQAw4iXFDbT
	YolXx4djXAZwvSiAk/1DG7lR4WQ8cZYQJ/wjreL5GPIJVtIeds5iMwNJIGX47mLp+ZVyxRVmoJh
	+WMdRwe4Tl9k3ZB8pjjl9G7z1KIiYG7lG7Squ9N4VUGY2n/mS33uQH+RR59oxwP4syJDVtvtKVD
	Qo5NXJCZbpcUNCk3kP+Ol/EjuX2qsmbTVFCxQ5Z5RC6dy9PanWnjTwpojU6ojhcYr/Th9B7dHsN
	avY=
X-Google-Smtp-Source: AGHT+IHqrn/5VYtgEnnsa6k46BuFXzyBRGCwDHd32H/cc0VkKHYs5ezd33Pd3pAtPdvk2DJ4qBaqdQ==
X-Received: by 2002:a17:907:3f92:b0:aac:439:10ce with SMTP id a640c23a62f3a-ab2ab73e812mr245573266b.27.1736349552593;
        Wed, 08 Jan 2025 07:19:12 -0800 (PST)
From: Alejandro Vallejo <alejandro.vallejo@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Hongyan Xia <hongyxia@amazon.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Julien Grall <jgrall@amazon.com>,
	Elias El Yandouzi <eliasely@amazon.com>,
	Alejandro Vallejo <alejandro.vallejo@cloud.com>
Subject: [PATCH v5 11/15] x86/setup: Do not create valid mappings when directmap=no
Date: Wed,  8 Jan 2025 15:18:18 +0000
Message-ID: <20250108151822.16030-12-alejandro.vallejo@cloud.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250108151822.16030-1-alejandro.vallejo@cloud.com>
References: <20250108151822.16030-1-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Hongyan Xia <hongyxia@amazon.com>

Create empty mappings in the second e820 pass. Also, destroy existing
direct map mappings created in the first pass.

To make xenheap pages visible in guests, it is necessary to create empty
L3 tables in the direct map even when directmap=no, since guest cr3s
copy idle domain's L4 entries, which means they will share mappings in
the direct map if we pre-populate idle domain's L4 entries and L3
tables. A helper is introduced for this.

Also, after the direct map is actually gone, we need to stop updating
the direct map in update_xen_mappings().

Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
Signed-off-by: Julien Grall <jgrall@amazon.com>
Signed-off-by: Elias El Yandouzi <eliasely@amazon.com>
Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
---
v4->v5:
  * No changes.
---
 xen/arch/x86/setup.c | 73 +++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 66 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 609ec4cf07f2..23b77f13bc10 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1060,6 +1060,56 @@ static struct domain *__init create_dom0(struct boot_info *bi)
     return d;
 }
 
+/*
+ * This either populates a valid direct map, or allocates empty L3 tables and
+ * creates the L4 entries for virtual address between [start, end) in the
+ * direct map depending on has_directmap();
+ *
+ * When directmap=no, we still need to populate empty L3 tables in the
+ * direct map region. The reason is that on-demand xenheap mappings are
+ * created in the idle domain's page table but must be seen by
+ * everyone. Since all domains share the direct map L4 entries, they
+ * will share xenheap mappings if we pre-populate the L4 entries and L3
+ * tables in the direct map region for all RAM. We also rely on the fact
+ * that L3 tables are never freed.
+ */
+static void __init populate_directmap(paddr_t pstart, paddr_t pend,
+                                      unsigned int flags)
+{
+    unsigned long vstart = (unsigned long)__va(pstart);
+    unsigned long vend = (unsigned long)__va(pend);
+
+    if ( pstart >= pend )
+        return;
+
+    BUG_ON(vstart < DIRECTMAP_VIRT_START);
+    BUG_ON(vend > DIRECTMAP_VIRT_END);
+
+    if ( has_directmap() )
+        /* Populate valid direct map. */
+        BUG_ON(map_pages_to_xen(vstart, maddr_to_mfn(pstart),
+                                PFN_DOWN(pend - pstart), flags));
+    else
+    {
+        /* Create empty L3 tables. */
+        unsigned long vaddr = vstart & ~((1UL << L4_PAGETABLE_SHIFT) - 1);
+
+        for ( unsigned long idx = l4_table_offset(vaddr);
+              idx <= l4_table_offset(vend); idx++ )
+        {
+            l4_pgentry_t *pl4e = &idle_pg_table[l4_table_offset(idx)];
+
+            if ( !(l4e_get_flags(*pl4e) & _PAGE_PRESENT) )
+            {
+                mfn_t mfn = alloc_boot_pages(1, 1);
+
+                clear_domain_page(mfn);
+                l4e_write(pl4e, l4e_from_mfn(mfn, __PAGE_HYPERVISOR));
+            }
+        }
+    }
+}
+
 /* How much of the directmap is prebuilt at compile time. */
 #define PREBUILT_MAP_LIMIT (1 << L2_PAGETABLE_SHIFT)
 
@@ -1681,8 +1731,17 @@ void asmlinkage __init noreturn __start_xen(void)
         map_e = min_t(uint64_t, e,
                       ARRAY_SIZE(l2_directmap) << L2_PAGETABLE_SHIFT);
 
-        /* Pass mapped memory to allocator /before/ creating new mappings. */
+        /*
+         * Pass mapped memory to allocator /before/ creating new mappings.
+         * The direct map for the bottom 4GiB has been populated in the first
+         * e820 pass. In the second pass, we make sure those existing mappings
+         * are destroyed when directmap=no.
+         */
         init_boot_pages(s, min(map_s, e));
+        if ( !has_directmap() )
+            destroy_xen_mappings((unsigned long)__va(s),
+                                 (unsigned long)__va(min(map_s, e)));
+
         s = map_s;
         if ( s < map_e )
         {
@@ -1690,6 +1749,9 @@ void asmlinkage __init noreturn __start_xen(void)
             map_s = (s + mask) & ~mask;
             map_e &= ~mask;
             init_boot_pages(map_s, map_e);
+            if ( !has_directmap() )
+                destroy_xen_mappings((unsigned long)__va(map_s),
+                                     (unsigned long)__va(map_e));
         }
 
         if ( map_s > map_e )
@@ -1703,8 +1765,7 @@ void asmlinkage __init noreturn __start_xen(void)
 
             if ( map_e < end )
             {
-                map_pages_to_xen((unsigned long)__va(map_e), maddr_to_mfn(map_e),
-                                 PFN_DOWN(end - map_e), PAGE_HYPERVISOR);
+                populate_directmap(map_e, end, PAGE_HYPERVISOR);
                 init_boot_pages(map_e, end);
                 map_e = end;
             }
@@ -1713,13 +1774,11 @@ void asmlinkage __init noreturn __start_xen(void)
         {
             /* This range must not be passed to the boot allocator and
              * must also not be mapped with _PAGE_GLOBAL. */
-            map_pages_to_xen((unsigned long)__va(map_e), maddr_to_mfn(map_e),
-                             PFN_DOWN(e - map_e), __PAGE_HYPERVISOR_RW);
+            populate_directmap(map_e, e, __PAGE_HYPERVISOR_RW);
         }
         if ( s < map_s )
         {
-            map_pages_to_xen((unsigned long)__va(s), maddr_to_mfn(s),
-                             PFN_DOWN(map_s - s), PAGE_HYPERVISOR);
+            populate_directmap(s, map_s, PAGE_HYPERVISOR);
             init_boot_pages(s, map_s);
         }
     }
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 15:19:20 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 15:19:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867496.1279124 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXq3-00039u-SC; Wed, 08 Jan 2025 15:19:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867496.1279124; Wed, 08 Jan 2025 15:19:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXq2-00037b-Q0; Wed, 08 Jan 2025 15:19:18 +0000
Received: by outflank-mailman (input) for mailman id 867496;
 Wed, 08 Jan 2025 15:19: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
 <SRS0=HyFE=UA=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tVXq1-0008Ue-2k
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 15:19:17 +0000
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com
 [2a00:1450:4864:20::533])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ec0bb7f6-cdd3-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 16:19:15 +0100 (CET)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-5d982de9547so395569a12.2
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 07:19:15 -0800 (PST)
Received: from localhost.localdomain ([66.81.170.107])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0eae71desm2488412166b.89.2025.01.08.07.19.13
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 07:19:14 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ec0bb7f6-cdd3-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736349555; x=1736954355; 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=LC/g8x4OedY7trloFSvWpnFUkcUT8czZLIGCqOW++Ak=;
        b=ZMH4rZ5n/W52oYgp1tkLEVCeBzzJWq7QFWI2CSKUE9u337bxBbx4XQffWax71gQv+S
         1L5uinKZa68Y0XWmDHO9pOG0dr5bJVSovlnoRw6XWWkqnBHGs+E6zNHk8hYenb9/ReGF
         UbyqZ7uv922V4HetHW1khkjajK81LlJGPvSDI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736349555; x=1736954355;
        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=LC/g8x4OedY7trloFSvWpnFUkcUT8czZLIGCqOW++Ak=;
        b=iCx/+mYxicilCDAmCCxM+GLx9G6e29a+Yp7hYrajwf3QJ0TMSK3J615Eax9yszpDeD
         39ZEq2Uijf6R56Z3MdMf21xK3VdXz/cPSV8KSmqXdrtqGpOa77NOVUn+QE1CpWzHQNzr
         kLw5D6ETy/adigkyzS6C9hiA7DTvP3hv25aYws0nxlgRV/tKEL/Hb4tMyptyQ4Pqbrf6
         RR7oiKhSdy4OxJzn2r8/iwOlCFMy3MyRj30zT4ew37fBea+b6mlckQJIT3b+bnwP20oE
         G0pbqAYQTQiK1I9jibxb7jsP7c4jUMyt1z2ocouignBGLPcxp7RfoXibvNCkUGKsd9I1
         BvlA==
X-Gm-Message-State: AOJu0YxVZ+ZHO01U22dXywOGSpaIXwZcgdD46NyhqRV0mVLgA9LRGZry
	s96pp00aLbiz/wsrzg28Tra3DD3w9/bbNkMn2ci11IbR7FfUTaHL0X232Jzizho/JhdGQvb3pw8
	VU3VNNQ==
X-Gm-Gg: ASbGncsboEhwv5a7Lx6imknQjPkoiNh3IrEDvf+jq8mc/bsRuUUV+2AxH+hVfQBv8kK
	nxvuoYZih0geYpJVh8Pkg4zPTW8fPQECd8TbnqvTCDPOhp7VWR1mdS3d1tMRaMzSQruXyPEKt5i
	fpKzUUVN1Ik2KVGz9HbzKSTGpdeLkBRuheF/1L9b8tP7vLv86RSD8IQCHmwnQ6WCVaeCrDQNaKm
	+Q2oT6gyqF8/Q4uq/k8+F7KsFuY/zSlcSO9u+E6phDJ/0DP8sXOBmAqwAOdZDhUXgl8PLxhyDGL
	uQk=
X-Google-Smtp-Source: AGHT+IFgF0QSUh74KgWW/mU+J3nBtJOl0SmmwvnWpBL0fo639DqkdvXF9jxD0MEjJF6UsgiJnul6MQ==
X-Received: by 2002:a05:6402:354c:b0:5d3:ba42:e9d6 with SMTP id 4fb4d7f45d1cf-5d972e14828mr3116152a12.17.1736349554733;
        Wed, 08 Jan 2025 07:19:14 -0800 (PST)
From: Alejandro Vallejo <alejandro.vallejo@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Alejandro Vallejo <alejandro.vallejo@cloud.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: [PATCH v5 13/15] xen/arm32: Hardwire zeroeth_table_offset to 0 on ARM_32
Date: Wed,  8 Jan 2025 15:18:20 +0000
Message-ID: <20250108151822.16030-14-alejandro.vallejo@cloud.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250108151822.16030-1-alejandro.vallejo@cloud.com>
References: <20250108151822.16030-1-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Include arm32 in 7c72147baa22("xen/arm: Restrict zeroeth_table_offset
for ARM_64"). Otherwise `va` overflows on shift in DECLARE_OFFSETS().

Fixes: 7c72147baa22("xen/arm: Restrict zeroeth_table_offset for ARM_64")
Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
---
 xen/arch/arm/include/asm/lpae.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/include/asm/lpae.h b/xen/arch/arm/include/asm/lpae.h
index 4a1679cb3334..d07456ffc8e3 100644
--- a/xen/arch/arm/include/asm/lpae.h
+++ b/xen/arch/arm/include/asm/lpae.h
@@ -259,7 +259,7 @@ lpae_t mfn_to_xen_entry(mfn_t mfn, unsigned int attr);
 #define first_table_offset(va)  TABLE_OFFSET(first_linear_offset(va))
 #define second_table_offset(va) TABLE_OFFSET(second_linear_offset(va))
 #define third_table_offset(va)  TABLE_OFFSET(third_linear_offset(va))
-#ifdef CONFIG_PHYS_ADDR_T_32
+#if defined(CONFIG_PHYS_ADDR_T_32) || defined(CONFIG_ARM_32)
 #define zeroeth_table_offset(va)  0
 #else
 #define zeroeth_table_offset(va)  TABLE_OFFSET(zeroeth_linear_offset(va))
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 15:19:22 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 15:19:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867501.1279136 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXq6-0003tS-4Y; Wed, 08 Jan 2025 15:19:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867501.1279136; Wed, 08 Jan 2025 15:19:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXq5-0003rk-Pf; Wed, 08 Jan 2025 15:19:21 +0000
Received: by outflank-mailman (input) for mailman id 867501;
 Wed, 08 Jan 2025 15:19: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
 <SRS0=HyFE=UA=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tVXq4-0008Ue-0w
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 15:19:20 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ecba1b49-cdd3-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 16:19:16 +0100 (CET)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-5d3e9f60bf4so30149211a12.3
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 07:19:16 -0800 (PST)
Received: from localhost.localdomain ([66.81.170.107])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0eae71desm2488412166b.89.2025.01.08.07.19.14
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 07:19:15 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ecba1b49-cdd3-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736349556; x=1736954356; 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=TcWHO2t2N7UwLnGLQCw7cWTCMCFtS4oV7aIoPrHjvaM=;
        b=UdXmqDiOmVrAZ2I/sa/7gqtokXWMtdp0UMvvyA4ZZ5n2f+DHsD/K32V+wxV+xTqeHP
         0xZebVgylrTnAeR93o+qzKqytvIHByDP2yjl/zHiFeIqapVXMCW+BNsp/++c7/GEUg+M
         C2sNDDg0pmcg+8CNCB3maT1Dqag5ztXPznUpc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736349556; x=1736954356;
        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=TcWHO2t2N7UwLnGLQCw7cWTCMCFtS4oV7aIoPrHjvaM=;
        b=ORMaKUXaSyTif+tA+eOtamvpaRTtPs8HbQGFrEWeM/Nghx2Vk5pBkgm9SvjPf9VhfN
         kom3OSgYzKgXMdgxAavnAzLRxqzBMka3bp0jeb5xlXzUKoNUc+lgIyx4r8rWTJTXUqdt
         q45lfWQuDJT7pTrRwMWPBw1LiaO6d3Y8d3dEg4iWOtWldfiUR8q7gNZtfnZ5ZYxSB3fk
         C/J9hkEhh6H5j7z/B2do2RRGxMFtTg+HcwEY7O9DfRdtxE11x2V24WYUQ1cunpWa1OiI
         49HKzm1z9edsfgIqOspLCkXwL7WHIfnIu6xSZ3tbpWcJHBxc6iI0cPzAL+p+tRr3GY26
         KkPw==
X-Gm-Message-State: AOJu0YxIKdEy8KMzMsGIRBJSjTxAXeToyU4eLiAUC3qn7bz+TiYjaMgK
	Q6IuLKE4BglOVqiJ/WcwHXqOBvdn73uQ544AYuPFD2x6Gi6Ppn+WhoDRL1KYAjIFmUlaMvxKgwT
	gEU8/vQ==
X-Gm-Gg: ASbGncvRw7OhMwlNpzb1tMKZxHWMJRtfl1bOInE0sqLjs18VT6TDqKfU7K8FtN0znPE
	HlQ+jARqhQKP87aygI30dolTwRFCTKytQCpAOVjUjKWuwTNDm3Fv8azHbxi7TyjOZyyMDT/xsZf
	OsZMvWNvcXiMN9oPA2NXiYK6jFNqx35UOzv3VJrG1DFjVjrZ317EX8xkPrt5OTT4HyHgRwfbZNj
	0K2yyOAkclD90hjc+iHgAzaf0ZTGKmtkt3y2kr96HNGHCadOF4upMNq+aeorI76pAS2lLKWXLWP
	/bE=
X-Google-Smtp-Source: AGHT+IF9fxsdMLev/SrCilzHh6Pzzv4UGiliFO6+R9GQV0Y5+wSNaw2EGspt7tbA+yvRoGwZ7vZbYg==
X-Received: by 2002:a05:6402:388a:b0:5d1:2631:b897 with SMTP id 4fb4d7f45d1cf-5d972e08403mr3094678a12.14.1736349555696;
        Wed, 08 Jan 2025 07:19:15 -0800 (PST)
From: Alejandro Vallejo <alejandro.vallejo@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Julien Grall <jgrall@amazon.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Elias El Yandouzi <eliasely@amazon.com>,
	Alejandro Vallejo <alejandro.vallejo@cloud.com>
Subject: [PATCH v5 14/15] xen/arm64: Implement a mapcache for arm64
Date: Wed,  8 Jan 2025 15:18:21 +0000
Message-ID: <20250108151822.16030-15-alejandro.vallejo@cloud.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250108151822.16030-1-alejandro.vallejo@cloud.com>
References: <20250108151822.16030-1-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Julien Grall <jgrall@amazon.com>

At the moment, on arm64, map_domain_page() is implemented using
virt_to_mfn(). Therefore it is relying on the directmap.

In a follow-up patch, we will allow the admin to remove the directmap.
Therefore we want to implement a mapcache.

Thanksfully there is already one for arm32. So select ARCH_ARM_DOMAIN_PAGE
and add the necessary boiler plate to support 64-bit:
    - The page-table start at level 0, so we need to allocate the level
      1 page-table
    - map_domain_page() should check if the page is in the directmap. If
      yes, then use virt_to_mfn() to limit the performance impact
      when the directmap is still enabled (this will be selectable
      on the command line).

Take the opportunity to replace first_table_offset(...) with offsets[...].

Note that, so far, arch_mfns_in_directmap() always return true on
arm64. So the mapcache is not yet used. This will change in a
follow-up patch.

Signed-off-by: Julien Grall <jgrall@amazon.com>
Signed-off-by: Elias El Yandouzi <eliasely@amazon.com>
Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
---
v4->v5:
  * Add missing "select ARCH_MAP_DOMAIN_PAGE". It was weirdly dropped
    from v2.
  * Bugfix: Unwrap mfn_t before passing it to mfn_to_virt() in
    map_domain_page().

Elias @ v4:
There are a few TODOs:
        - It is becoming more critical to fix the mapcache
          implementation (this is not compliant with the Arm Arm)
        - Evaluate the performance
---
 xen/arch/arm/Kconfig                  |  2 +-
 xen/arch/arm/arm64/mmu/mm.c           |  9 ++++++
 xen/arch/arm/include/asm/mm.h         |  5 +++
 xen/arch/arm/include/asm/mmu/layout.h | 13 +++++++-
 xen/arch/arm/mmu/domain_page.c        | 45 ++++++++++++++++++++++++---
 xen/arch/arm/mmu/pt.c                 |  6 ++--
 6 files changed, 71 insertions(+), 9 deletions(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index a26d3e11827c..5c31bb616608 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -1,7 +1,6 @@
 config ARM_32
 	def_bool y
 	depends on "$(ARCH)" = "arm32"
-	select ARCH_MAP_DOMAIN_PAGE
 
 config ARM_64
 	def_bool y
@@ -12,6 +11,7 @@ config ARM_64
 
 config ARM
 	def_bool y
+	select ARCH_MAP_DOMAIN_PAGE
 	select FUNCTION_ALIGNMENT_4B
 	select GENERIC_UART_INIT
 	select HAS_ALTERNATIVE if HAS_VMAP
diff --git a/xen/arch/arm/arm64/mmu/mm.c b/xen/arch/arm/arm64/mmu/mm.c
index 7de5885cc776..8e121e5ffe8d 100644
--- a/xen/arch/arm/arm64/mmu/mm.c
+++ b/xen/arch/arm/arm64/mmu/mm.c
@@ -5,6 +5,7 @@
 #include <xen/mm.h>
 #include <xen/pfn.h>
 
+#include <asm/domain_page.h>
 #include <asm/setup.h>
 #include <asm/static-memory.h>
 #include <asm/static-shmem.h>
@@ -283,6 +284,14 @@ void __init setup_mm(void)
     setup_frametable_mappings(ram_start, ram_end);
     max_page = PFN_DOWN(ram_end);
 
+    /*
+     * The allocators may need to use map_domain_page() (such as for
+     * scrubbing pages). So we need to prepare the domheap area first.
+     */
+    if ( !init_domheap_mappings(smp_processor_id()) )
+        panic("CPU%u: Unable to prepare the domheap page-tables\n",
+              smp_processor_id());
+
     init_staticmem_pages();
     init_sharedmem_pages();
 }
diff --git a/xen/arch/arm/include/asm/mm.h b/xen/arch/arm/include/asm/mm.h
index 07329a17fffa..0a4dc53a6050 100644
--- a/xen/arch/arm/include/asm/mm.h
+++ b/xen/arch/arm/include/asm/mm.h
@@ -434,6 +434,11 @@ static inline void page_set_xenheap_gfn(struct page_info *p, gfn_t gfn)
     } while ( (y = cmpxchg(&p->u.inuse.type_info, x, nx)) != x );
 }
 
+/* Helpers to allocate, map and unmap a Xen page-table */
+int create_xen_table(lpae_t *entry);
+lpae_t *xen_map_table(mfn_t mfn);
+void xen_unmap_table(const lpae_t *table);
+
 #endif /*  __ARCH_ARM_MM__ */
 /*
  * Local variables:
diff --git a/xen/arch/arm/include/asm/mmu/layout.h b/xen/arch/arm/include/asm/mmu/layout.h
index 19c0ec63a59a..35f4204ce76a 100644
--- a/xen/arch/arm/include/asm/mmu/layout.h
+++ b/xen/arch/arm/include/asm/mmu/layout.h
@@ -36,9 +36,13 @@
  *
  *  32G -  64G   Frametable: 56 bytes per page for 2TB of RAM
  *
- * 0x00000a8000000000 - 0x00007fffffffffff (512GB+117TB, L0 slots [21..255])
+ * 0x00000a8000000000 - 0x00007f7fffffffff (117TB, L0 slots [21..254])
  *  Unused
  *
+ * 0x00007f8000000000 - 0x00007fffffffffff (512GB, L0 slot [255])
+ *  (Relative offsets)
+ *  0  -    2G    Domheap: on-demand-mapped
+ *
  * 0x0000800000000000 - 0x000084ffffffffff (5TB, L0 slots [256..265])
  *  1:1 mapping of RAM
  *
@@ -133,6 +137,13 @@
 #define FRAMETABLE_SIZE        GB(32)
 #define FRAMETABLE_NR          (FRAMETABLE_SIZE / sizeof(*frame_table))
 
+#define DOMHEAP_VIRT_START     SLOT0(255)
+#define DOMHEAP_VIRT_SIZE      GB(2)
+
+#define DOMHEAP_ENTRIES        1024 /* 1024 2MB mapping slots */
+/* Number of domheap pagetable pages required at the second level (2MB mappings) */
+#define DOMHEAP_SECOND_PAGES (DOMHEAP_VIRT_SIZE >> FIRST_SHIFT)
+
 #define DIRECTMAP_VIRT_START   SLOT0(256)
 #define DIRECTMAP_SIZE         (SLOT0_ENTRY_SIZE * (266 - 256))
 #define DIRECTMAP_VIRT_END     (DIRECTMAP_VIRT_START + DIRECTMAP_SIZE - 1)
diff --git a/xen/arch/arm/mmu/domain_page.c b/xen/arch/arm/mmu/domain_page.c
index 3a43601623f0..7276c2b3b868 100644
--- a/xen/arch/arm/mmu/domain_page.c
+++ b/xen/arch/arm/mmu/domain_page.c
@@ -29,13 +29,30 @@ bool init_domheap_mappings(unsigned int cpu)
 {
     unsigned int order = get_order_from_pages(DOMHEAP_SECOND_PAGES);
     lpae_t *root = per_cpu(xen_pgtable, cpu);
+    lpae_t *first;
     unsigned int i, first_idx;
     lpae_t *domheap;
     mfn_t mfn;
 
+    /* Convenience aliases */
+    DECLARE_OFFSETS(offsets, DOMHEAP_VIRT_START);
+
     ASSERT(root);
     ASSERT(!per_cpu(xen_dommap, cpu));
 
+    /*
+     * On Arm64, the root is at level 0. Therefore we need an extra step
+     * to allocate the first level page-table.
+     */
+#ifdef CONFIG_ARM_64
+    if ( create_xen_table(&root[offsets[0]]) )
+        return false;
+
+    first = xen_map_table(lpae_get_mfn(root[offsets[0]]));
+#else
+    first = root;
+#endif
+
     /*
      * The domheap for cpu0 is initialized before the heap is initialized.
      * So we need to use pre-allocated pages.
@@ -56,16 +73,20 @@ bool init_domheap_mappings(unsigned int cpu)
      * domheap mapping pages.
      */
     mfn = virt_to_mfn(domheap);
-    first_idx = first_table_offset(DOMHEAP_VIRT_START);
+    first_idx = offsets[1];
     for ( i = 0; i < DOMHEAP_SECOND_PAGES; i++ )
     {
         lpae_t pte = mfn_to_xen_entry(mfn_add(mfn, i), MT_NORMAL);
         pte.pt.table = 1;
-        write_pte(&root[first_idx + i], pte);
+        write_pte(&first[first_idx + i], pte);
     }
 
     per_cpu(xen_dommap, cpu) = domheap;
 
+#ifdef CONFIG_ARM_64
+    xen_unmap_table(first);
+#endif
+
     return true;
 }
 
@@ -89,6 +110,10 @@ void *map_domain_page(mfn_t mfn)
     lpae_t pte;
     int i, slot;
 
+    /* Bypass the mapcache if the page is in the directmap */
+    if ( arch_mfns_in_directmap(mfn_x(mfn), 1) )
+        return mfn_to_virt(mfn_x(mfn));
+
     local_irq_save(flags);
 
     /* The map is laid out as an open-addressed hash table where each
@@ -151,13 +176,25 @@ void *map_domain_page(mfn_t mfn)
 /* Release a mapping taken with map_domain_page() */
 void unmap_domain_page(const void *ptr)
 {
+    unsigned long va = (unsigned long)ptr;
     unsigned long flags;
     lpae_t *map = this_cpu(xen_dommap);
-    int slot = ((unsigned long)ptr - DOMHEAP_VIRT_START) >> SECOND_SHIFT;
+    unsigned int slot;
+
+    /* Below we assume that the domheap area doesn't start at 0 */
+    BUILD_BUG_ON(DOMHEAP_VIRT_START == 0);
 
-    if ( !ptr )
+    /*
+     * map_domain_page() may not have mapped anything if the address
+     * is part of the directmap. So ignore anything outside of the
+     * domheap.
+     */
+    if ( (va < DOMHEAP_VIRT_START) ||
+         ((va - DOMHEAP_VIRT_START) >= DOMHEAP_VIRT_SIZE) )
         return;
 
+    slot = (va - DOMHEAP_VIRT_START) >> SECOND_SHIFT;
+
     local_irq_save(flags);
 
     ASSERT(slot >= 0 && slot < DOMHEAP_ENTRIES);
diff --git a/xen/arch/arm/mmu/pt.c b/xen/arch/arm/mmu/pt.c
index 1ed1a53ab1f2..da33c6c52e39 100644
--- a/xen/arch/arm/mmu/pt.c
+++ b/xen/arch/arm/mmu/pt.c
@@ -33,7 +33,7 @@ mm_printk(const char *fmt, ...) {}
 #define HYP_PT_ROOT_LEVEL 1
 #endif
 
-static lpae_t *xen_map_table(mfn_t mfn)
+lpae_t *xen_map_table(mfn_t mfn)
 {
     /*
      * During early boot, map_domain_page() may be unusable. Use the
@@ -45,7 +45,7 @@ static lpae_t *xen_map_table(mfn_t mfn)
     return map_domain_page(mfn);
 }
 
-static void xen_unmap_table(const lpae_t *table)
+void xen_unmap_table(const lpae_t *table)
 {
     /*
      * During early boot, xen_map_table() will not use map_domain_page()
@@ -228,7 +228,7 @@ void *ioremap(paddr_t pa, size_t len)
     return ioremap_attr(pa, len, PAGE_HYPERVISOR_NOCACHE);
 }
 
-static int create_xen_table(lpae_t *entry)
+int create_xen_table(lpae_t *entry)
 {
     mfn_t mfn;
     void *p;
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 15:21:03 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 15:21:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867551.1279154 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXri-0000jk-9z; Wed, 08 Jan 2025 15:21:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867551.1279154; Wed, 08 Jan 2025 15:21:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXri-0000jd-5u; Wed, 08 Jan 2025 15:21:02 +0000
Received: by outflank-mailman (input) for mailman id 867551;
 Wed, 08 Jan 2025 15:21:00 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=HyFE=UA=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tVXq2-0008Lg-Bx
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 15:19:18 +0000
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
 [2a00:1450:4864:20::531])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ed63cabb-cdd3-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 16:19:17 +0100 (CET)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-5d122cf8dd1so29422630a12.2
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 07:19:17 -0800 (PST)
Received: from localhost.localdomain ([66.81.170.107])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0eae71desm2488412166b.89.2025.01.08.07.19.15
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jan 2025 07:19:16 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ed63cabb-cdd3-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736349557; x=1736954357; 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=XzrS2Bw0H8USJct01IYqEGdeeRooPpKhcpnuOPYIt28=;
        b=T9EE7M546zVv71S6qXEjvuyB1KHnNnR7rJCvJfMgr7/IzWXoXOKonOiAXWA6KNxLcv
         Rl4vzX0I85fsIAYYZUT9uVoIdbEYgZVeLvF/N/rMKZn9Xog9Q7teN0YJ7SGukVsn36Gv
         OP6Hf/SxFAZ3XKvwUdjqIOOY5J/h7LjVQJRqg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736349557; x=1736954357;
        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=XzrS2Bw0H8USJct01IYqEGdeeRooPpKhcpnuOPYIt28=;
        b=qrsALIhSM/uwb6qyrnvz8vVXOqYvzeeRlEfjkZH/hcdSeRkb+v7OGmZi5mUJni3p7E
         U2d4PBWy/XtvsV4n6ikUxChBxpGCTJa6Y/hjptffW7o/VkHwMDW9m789ux/VQ871263O
         dCBDqrXm+bAg/iQv7p6AQqYdDu/eQoqIyge7m6dnFXCccPQfqGheKrUI3YtsusAC3jYs
         qv9MPG8RJ73Wx5we2ejq/2tVHCczuliVsLFn3A6u7HDhRenU5bepUFRRx98kKzHaWZFX
         kfQytqlyAKD2wVVNfj/mgkjmC6ZNYt/j7FZqTgFSE/esCvIjcp4PmC0FDSUfpNnTFpsk
         vadA==
X-Gm-Message-State: AOJu0YxNO+G1HdW3kqwiUJGPLtTxLbPBUL0+zav2KZiRtDA6qh6ADppZ
	Z97KpmMmQX7BCWAsjmXlhtSXLz9L3nifUveKWFY6mmU5KZqb++geLYUZa8rwBSxDdqWdCtQyRj3
	bwZTpbg==
X-Gm-Gg: ASbGncvCCMzlzsWHdf00mY+atR85PGBepjbPunnD/465QjWBCC/RpjIh9XMLdoQQxu5
	P4sZ+lrXvRU2SMmKGqHXv5hAq8ldMRbue1ezejhGMn0RYOg/eR9emYjVAdxk5PFsASzMg/Idwdh
	SDnIO7WxVu7GnIuDymKCzYBTmg1PVpmG/MYojbaG5Flb6HUTZrFSY7Ip9LxZ+YiFVebfzayVniS
	ZgXhaQ3z8SS7cC3FCZ3cDLJkMdM2EZccXBzDG9cnufGIDvsytBPUDRfEWf0z3Gky+asR+1DYjLY
	ilM=
X-Google-Smtp-Source: AGHT+IEzh2vXVXXW5B5Ed5ZTzK8fKIgHzlWWpwrWKLYvwwb30s4uKM+ShVikFKtNzNtPnQJDrTJRfg==
X-Received: by 2002:a05:6402:1ed4:b0:5d0:ed71:3ce4 with SMTP id 4fb4d7f45d1cf-5d972dfea2amr2948651a12.6.1736349556914;
        Wed, 08 Jan 2025 07:19:16 -0800 (PST)
From: Alejandro Vallejo <alejandro.vallejo@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Julien Grall <jgrall@amazon.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Elias El Yandouzi <eliasely@amazon.com>,
	Alejandro Vallejo <alejandro.vallejo@cloud.com>
Subject: [PATCH v5 15/15] xen/arm64: Allow the admin to enable/disable the directmap
Date: Wed,  8 Jan 2025 15:18:22 +0000
Message-ID: <20250108151822.16030-16-alejandro.vallejo@cloud.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250108151822.16030-1-alejandro.vallejo@cloud.com>
References: <20250108151822.16030-1-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Julien Grall <jgrall@amazon.com>

Implement the same command line option as x86 to enable/disable the
directmap. By default this is kept enabled.

Also modify setup_directmap_mappings() to populate the L0 entries
related to the directmap area.

Signed-off-by: Julien Grall <jgrall@amazon.com>
Signed-off-by: Elias El Yandouzi <eliasely@amazon.com>
Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
---
v4->v5:
  * Fixed typo in comment. s/fdirect/direct/
  * Adjusted comment so 's/directmap=no/asi=true'
  * Adjusted printk() so 's/on/full' and 's/off/on demand'
  * s/HAS_SECRET_HIDING/HAS_ONDEMAND_DIRECTMAP. Otherwise
    CONFIG_ONDEMAND_DIRECTMAP won't appear on the menu for ARM
    (Note: I didn't test ARM because I have no boxes to do so)

v1->v2:
  * Rely on the Kconfig option to enable Secret Hiding on Arm64
  * Use generic helper instead of arch_has_directmap()
---
 docs/misc/xen-command-line.pandoc   |  2 +-
 xen/arch/arm/Kconfig                |  1 +
 xen/arch/arm/arm64/mmu/mm.c         | 39 +++++++++++++++++++++++++++--
 xen/arch/arm/include/asm/arm64/mm.h |  7 ++----
 xen/arch/arm/setup.c                |  2 ++
 5 files changed, 43 insertions(+), 8 deletions(-)

diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index 6a1351b6c09b..68cbaf17e768 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -202,7 +202,7 @@ to appropriate auditing by Xen.  Argo is disabled by default.
     This option is disabled by default, to protect domains from a DoS by a
     buggy or malicious other domain spamming the ring.
 
-### asi (x86)
+### asi (arm64, x86)
 > `= <boolean>`
 
 > Default: `false`
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 5c31bb616608..ec9536a1111e 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -8,6 +8,7 @@ config ARM_64
 	select 64BIT
 	select HAS_FAST_MULTIPLY
 	select HAS_LLC_COLORING if !NUMA
+	select HAS_ONDEMAND_DIRECTMAP
 
 config ARM
 	def_bool y
diff --git a/xen/arch/arm/arm64/mmu/mm.c b/xen/arch/arm/arm64/mmu/mm.c
index 8e121e5ffe8d..99f14ce17878 100644
--- a/xen/arch/arm/arm64/mmu/mm.c
+++ b/xen/arch/arm/arm64/mmu/mm.c
@@ -3,6 +3,7 @@
 #include <xen/init.h>
 #include <xen/llc-coloring.h>
 #include <xen/mm.h>
+#include <xen/param.h>
 #include <xen/pfn.h>
 
 #include <asm/domain_page.h>
@@ -14,6 +15,11 @@
 #undef virt_to_mfn
 #define virt_to_mfn(va) _mfn(__virt_to_mfn(va))
 
+#ifdef CONFIG_ONDEMAND_DIRECTMAP
+bool __ro_after_init opt_ondemand_dmap;
+boolean_param("asi", opt_ondemand_dmap);
+#endif
+
 static DEFINE_PAGE_TABLE(xen_first_id);
 static DEFINE_PAGE_TABLE(xen_second_id);
 static DEFINE_PAGE_TABLE(xen_third_id);
@@ -204,16 +210,27 @@ void __init switch_ttbr(uint64_t ttbr)
     update_identity_mapping(false);
 }
 
-/* Map the region in the directmap area. */
+/*
+ * This either populate a valid directmap, or allocates empty L1 tables
+ * and creates the L0 entries for the given region in the direct map
+ * depending on has_directmap().
+ *
+ * When asi=true, we still need to populate empty L1 tables in the
+ * directmap region. The reason is that the root page-table (i.e. L0)
+ * is per-CPU and secondary CPUs will initialize their root page-table
+ * based on the pCPU0 one. So L0 entries will be shared if they are
+ * pre-populated. We also rely on the fact that L1 tables are never
+ * freed.
+ */
 static void __init setup_directmap_mappings(unsigned long base_mfn,
                                             unsigned long nr_mfns)
 {
+    unsigned long mfn_gb = base_mfn & ~((FIRST_SIZE >> PAGE_SHIFT) - 1);
     int rc;
 
     /* First call sets the directmap physical and virtual offset. */
     if ( mfn_eq(directmap_mfn_start, INVALID_MFN) )
     {
-        unsigned long mfn_gb = base_mfn & ~((FIRST_SIZE >> PAGE_SHIFT) - 1);
 
         directmap_mfn_start = _mfn(base_mfn);
         directmap_base_pdx = mfn_to_pdx(_mfn(base_mfn));
@@ -234,6 +251,24 @@ static void __init setup_directmap_mappings(unsigned long base_mfn,
         panic("cannot add directmap mapping at %lx below heap start %lx\n",
               base_mfn, mfn_x(directmap_mfn_start));
 
+    if ( !has_directmap() )
+    {
+        vaddr_t vaddr = (vaddr_t)__mfn_to_virt(base_mfn);
+        lpae_t *root = this_cpu(xen_pgtable);
+        unsigned int i, slot;
+
+        slot = first_table_offset(vaddr);
+        nr_mfns += base_mfn - mfn_gb;
+        for ( i = 0; i < nr_mfns; i += BIT(XEN_PT_LEVEL_ORDER(0), UL), slot++ )
+        {
+            lpae_t *entry = &root[slot];
+
+            if ( !lpae_is_valid(*entry) && !create_xen_table(entry) )
+                panic("Unable to populate zeroeth slot %u\n", slot);
+        }
+        return;
+    }
+
     rc = map_pages_to_xen((vaddr_t)__mfn_to_virt(base_mfn),
                           _mfn(base_mfn), nr_mfns,
                           PAGE_HYPERVISOR_RW | _PAGE_BLOCK);
diff --git a/xen/arch/arm/include/asm/arm64/mm.h b/xen/arch/arm/include/asm/arm64/mm.h
index b4f7545d2c87..2b1140a6b994 100644
--- a/xen/arch/arm/include/asm/arm64/mm.h
+++ b/xen/arch/arm/include/asm/arm64/mm.h
@@ -3,13 +3,10 @@
 
 extern DEFINE_PAGE_TABLE(xen_pgtable);
 
-/*
- * On ARM64, all the RAM is currently direct mapped in Xen.
- * Hence return always true.
- */
+/* On Arm64, the user can chose whether all the RAM is directmap. */
 static inline bool arch_mfns_in_directmap(unsigned long mfn, unsigned long nr)
 {
-    return true;
+    return has_directmap();
 }
 
 void arch_setup_page_tables(void);
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 3b1ab6be3fbd..e3505dca8889 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -346,6 +346,8 @@ void asmlinkage __init start_xen(unsigned long fdt_paddr)
     device_tree_flattened = early_fdt_map(fdt_paddr);
 
     setup_mm();
+    printk("Booting with directmap: %s\n",
+           has_directmap() ? "full" : "on demand");
 
     vm_init();
 
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 15:21:33 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 15:21:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867582.1279164 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXsD-00021O-Hq; Wed, 08 Jan 2025 15:21:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867582.1279164; Wed, 08 Jan 2025 15:21:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXsD-00021H-EV; Wed, 08 Jan 2025 15:21:33 +0000
Received: by outflank-mailman (input) for mailman id 867582;
 Wed, 08 Jan 2025 15:21:32 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=svEr=UA=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVXsC-0001vg-AJ
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 15:21:32 +0000
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com
 [2a00:1450:4864:20::430])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3c4b312e-cdd4-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 16:21:30 +0100 (CET)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3862d16b4f5so720079f8f.0
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 07:21:30 -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
 5b1f17b1804b1-436e2dc2310sm23911335e9.13.2025.01.08.07.21.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 08 Jan 2025 07:21:29 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 3c4b312e-cdd4-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736349689; x=1736954489; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=4zfBxvXy2dpxaQBoNlsiIE0F+TpUBBbW2t8DHbIKtlU=;
        b=OKJ+kmRT+hm8+BgbA+sjXUMtV9Lq1xAZRZqLheDyXB2CdTXMfkmOzMOXmZH6t6+bcE
         m9nq63Vvq71+QZVKJkQcxLwZAAD04NFp2eziq40+hy94QwE3FWqLeebxfNAfZI0dTkPf
         FyZ5066Or24VE6OIwWA0eF5k39iPHewbv6ALYdy8407Zx3ww74GCuALoJpVuGkUrZiXq
         FHUIeRxepZJFafXtGoWzHhUWIPtNpVda1Bh1xWKpocCDh4cDKOk57NY1cmMxOhoshQ7e
         i99CkibJr3AfAYpesPW8B2FYoHtxVNZQCK9XGPsahSPaQmIC+bd+yOrjOw+Dm4cTC5fQ
         GwvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736349689; x=1736954489;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=4zfBxvXy2dpxaQBoNlsiIE0F+TpUBBbW2t8DHbIKtlU=;
        b=bFltPjF6iBf0O2hikul+lY63Z03Jg+tRkkrejUOkyPa3siNtqZme5LGtIDPXS41h/7
         kKZ3eSmqloEJPTum/JNwkewgIyM3A3ZvJxxvDtfbOXcGkMCO/RObsDqm4cGArNY5f216
         cS/RfP8IjvZEBjUxllATpSm1vEJ1stNsMrJOUXFhfc5jQf2Bgf086VQfRAOjJrBFFafS
         yW7CJnCecFQ4AHyqH7RAn7G6RLK/muiH7idzjN2KLFU3sl5ZjrHUD1o134DPc9s1uLCF
         l4IZZ12uoQbTzSB2szktkGJ42wH0wA42QXVzP0mSCI3Ekh4/wVja1ZVUPNnwAUQlpSCB
         c9xg==
X-Forwarded-Encrypted: i=1; AJvYcCXp2ljYbLqwIrpA8YYNVyNnjgBr2kl4fbekrpKHWaW9IiKmrZdCR9/8GtaBj+cVi2a40VTz+fFlt8A=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz3F0R9l886AobdbBpNKBPV1b6spZZdFGM5WCtOdfKWQUgb3SXX
	0m7PcW24jsoFpWFDvoGaZq7eryEXUDZZqAJgZ7uyYJY5i8/kassHkC7eCT01wA==
X-Gm-Gg: ASbGncsSViJ8ojSMD8fi3rH+lLaKy7W9lQR57JosD5iRCKYXuc0c8fPmZB5KR1G1eUg
	MmtVA2hl7m36V6va73Le1YN4S3VsTwYWixHcBY5GequSjdpoerCIdC3D41+CKdgQSaCJ7zY5ayv
	SPth3RNQ/9JXre5HKY6GWQBj2KGZ20LPy4j16PYE8n85MZIh0yYQ/BHPzgdNIZuRGnE6izevDwA
	lKEiiMc6rBWJx7HpHNJJVokqwcD8IVQ63eery8QyyCVityCTG9gWPxQLP8LQ9AtUYapbqhExJWE
	R9j4pEKl8jj0p1CbIirBWZbF2Ja5a5V02AJcKCQYWg==
X-Google-Smtp-Source: AGHT+IE998HtHxkrozL+jYB3zX+QrUEmogr9pRIdsTMw/sGrFWR1H9TY+DyiNEqiz4tV+JMIRQpplQ==
X-Received: by 2002:a5d:59ac:0:b0:386:3958:2ec5 with SMTP id ffacd0b85a97d-38a792449a2mr5211615f8f.28.1736349689345;
        Wed, 08 Jan 2025 07:21:29 -0800 (PST)
Message-ID: <bc636259-5586-428c-8a57-f97ba16a14b8@suse.com>
Date: Wed, 8 Jan 2025 16:21:27 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for 4.21 v1 1/1] xen/riscv: identify specific ISA
 supported by cpu
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Alistair Francis <alistair.francis@wdc.com>,
 Bob Eshleman <bobbyeshleman@gmail.com>, Connor Davis
 <connojdavis@gmail.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1734957957.git.oleksii.kurochko@gmail.com>
 <ee14c485c6c6402a2d1706278b21bf3fcf821af9.1734957957.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <ee14c485c6c6402a2d1706278b21bf3fcf821af9.1734957957.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 23.12.2024 13:55, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/arch/riscv/cpufeature.c
> @@ -0,0 +1,466 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Taken for Linux kernel v6.12-rc3 and modified by
> + * Oleksii Kurochko <oleksii.kurochko@gmail.com>:
> + *
> + * - Drop unconditional setting of {RISCV_ISA_EXT_ZICSR,
> + *   RISCV_ISA_EXT_ZIFENCEI, RISCV_ISA_EXT_ZICNTR, RISCV_ISA_EXT_ZIHPM} as they
> + *   are now part of the riscv,isa string.
> + * - Remove saving of the ISA for each CPU, only the common available ISA is
> + *   saved.
> + * - Remove ACPI-related code as ACPI is not supported by Xen.
> + * - Drop handling of elf_hwcap, since Xen does not provide hwcap to
> + *   userspace.
> + * - Replace of_cpu_device_node_get() API, which is not available in Xen,
> + *   with a combination of dt_for_each_child_node(), dt_device_type_is_equal(),
> + *   and dt_get_cpuid_from_node() to retrieve cpuid and riscv,isa in
> + *   riscv_fill_hwcap_from_isa_string().
> + * - Rename arguments of __RISCV_ISA_EXT_DATA() from _name to ext_name, and
> + *   _id to ext_id for clarity.
> + * - Replace instances of __RISCV_ISA_EXT_DATA with RISCV_ISA_EXT_DATA.
> + * - Replace instances of __riscv_isa_extension_available with
> + *   riscv_isa_extension_available for consistency.
> + * - Redefine RISCV_ISA_EXT_DATA() to work only with ext_name and ext_id,
> + *   as other fields are not used in Xen currently.
> + * - Add check of first 4 letters of riscv,isa string to
> + *   riscv_isa_parse_string() as Xen doesn't do this check before so it is
> + *   necessary to check correctness of riscv,isa string. ( it should start with
> + *   rv{32,64} with taking into account upper and lower case of "rv").
> + * - Drop an argument of riscv_fill_hwcap() and riscv_fill_hwcap_from_isa_string()
> + *   as it isn't used, at the moment.
> + * - s/pr_info/printk.
> + * - Apply Xen coding style.

Having this in the patch description is sufficient imo.

> + * Copyright (C) 2015 ARM Ltd.
> + * Copyright (C) 2017 SiFive
> + * Copyright (C) 2024 Vates
> + */
> +
> +#include <xen/acpi.h>

Didn't you say you dropped the ACPI pieces?

> +#include <xen/bitmap.h>
> +#include <xen/ctype.h>
> +#include <xen/device_tree.h>
> +#include <xen/errno.h>
> +#include <xen/init.h>
> +#include <xen/lib.h>
> +#include <xen/sections.h>
> +
> +#include <asm/cpufeature.h>
> +
> +struct riscv_isa_ext_data {
> +    const unsigned int id;
> +    const char *name;
> +};

This is odd - why would the id be const, but not the name? Thus you
require all instances of the struct to have an initializer. The more
conventional approach is to apply the const on the instances of the
structure (e.g. as you already have it for riscv_isa_ext[]). 

> +#define RISCV_ISA_EXT_DATA(ext_name, ext_id)    \
> +{                                               \
> +    .id = ext_id,                               \
> +    .name = #ext_name,                          \
> +}
> +
> +/* Host ISA bitmap */
> +static __read_mostly DECLARE_BITMAP(riscv_isa, RISCV_ISA_EXT_MAX);

Not __ro_after_init?

> +static int __init dt_get_cpuid_from_node(const struct dt_device_node *cpu)
> +{
> +    const __be32 *prop;
> +    unsigned int reg_len;
> +
> +    if ( dt_n_size_cells(cpu) != 0 )
> +        printk("cpu node `%s`: #size-cells %d\n",
> +               dt_node_full_name(cpu), dt_n_size_cells(cpu));
> +
> +    prop = dt_get_property(cpu, "reg", &reg_len);
> +    if ( !prop )
> +    {
> +        printk("cpu node `%s`: has no reg property\n", dt_node_full_name(cpu));
> +        return -EINVAL;
> +    }
> +
> +    if ( reg_len < dt_cells_to_size(dt_n_addr_cells(cpu)) )
> +    {
> +        printk("cpu node `%s`: reg property too short\n",
> +               dt_node_full_name(cpu));
> +        return -EINVAL;
> +    }
> +
> +    return dt_read_paddr(prop, dt_n_addr_cells(cpu));
> +}
> +
> +/*
> + * The canonical order of ISA extension names in the ISA string is defined in
> + * chapter 27 of the unprivileged specification.
> + *
> + * Ordinarily, for in-kernel data structures, this order is unimportant but
> + * isa_ext_arr defines the order of the ISA string in /proc/cpuinfo.

Inapplicable Linux detail? (If you want to keep it, you'll want to add
"Linux'es" and avoid mentioning something that looks like a variable
but then doesn't exist anywhere.)

> + * The specification uses vague wording, such as should, when it comes to
> + * ordering, so for our purposes the following rules apply:
> + *
> + * 1. All multi-letter extensions must be separated from other extensions by an
> + *    underscore.
> + *
> + * 2. Additional standard extensions (starting with 'Z') must be sorted after
> + *    single-letter extensions and before any higher-privileged extensions.
> + *
> + * 3. The first letter following the 'Z' conventionally indicates the most
> + *    closely related alphabetical extension category, IMAFDQLCBKJTPVH.
> + *    If multiple 'Z' extensions are named, they must be ordered first by
> + *    category, then alphabetically within a category.
> + *
> + * 3. Standard supervisor-level extensions (starting with 'S') must be listed
> + *    after standard unprivileged extensions.  If multiple supervisor-level
> + *    extensions are listed, they must be ordered alphabetically.

Two times "3."?

> + * 4. Standard machine-level extensions (starting with 'Zxm') must be listed
> + *    after any lower-privileged, standard extensions.  If multiple
> + *    machine-level extensions are listed, they must be ordered
> + *    alphabetically.
> + *
> + * 5. Non-standard extensions (starting with 'X') must be listed after all
> + *    standard extensions. If multiple non-standard extensions are listed, they
> + *    must be ordered alphabetically.
> + *
> + * An example string following the order is:
> + *    rv64imadc_zifoo_zigoo_zafoo_sbar_scar_zxmbaz_xqux_xrux
> + *
> + * New entries to this struct should follow the ordering rules described above.
> + */
> +const struct riscv_isa_ext_data riscv_isa_ext[] = {

__initconst?

> +    RISCV_ISA_EXT_DATA(i, RISCV_ISA_EXT_i),
> +    RISCV_ISA_EXT_DATA(m, RISCV_ISA_EXT_m),
> +    RISCV_ISA_EXT_DATA(a, RISCV_ISA_EXT_a),
> +    RISCV_ISA_EXT_DATA(f, RISCV_ISA_EXT_f),
> +    RISCV_ISA_EXT_DATA(d, RISCV_ISA_EXT_d),
> +    RISCV_ISA_EXT_DATA(q, RISCV_ISA_EXT_q),
> +    RISCV_ISA_EXT_DATA(h, RISCV_ISA_EXT_h),
> +    RISCV_ISA_EXT_DATA(zicntr, RISCV_ISA_EXT_ZICNTR),
> +    RISCV_ISA_EXT_DATA(zicsr, RISCV_ISA_EXT_ZICSR),
> +    RISCV_ISA_EXT_DATA(zifencei, RISCV_ISA_EXT_ZIFENCEI),
> +    RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE),
> +    RISCV_ISA_EXT_DATA(zihpm, RISCV_ISA_EXT_ZIHPM),
> +    RISCV_ISA_EXT_DATA(zbb, RISCV_ISA_EXT_ZBB),

Isn't it kind of implied that with the presence of Zbb, B should also be
present?

> +    RISCV_ISA_EXT_DATA(smaia, RISCV_ISA_EXT_SMAIA),
> +    RISCV_ISA_EXT_DATA(ssaia, RISCV_ISA_EXT_SSAIA),
> +};

Wouldn't the Z and S prefixes better be recorded in upper case here?

> +static const struct riscv_isa_ext_data required_extensions[] = {

__initconst again?

> +    RISCV_ISA_EXT_DATA(zbb, RISCV_ISA_EXT_ZBB),
> +    RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE),
> +};
> +
> +static const size_t riscv_isa_ext_count = ARRAY_SIZE(riscv_isa_ext);

Is this variable really useful to have?

> +static void __init match_isa_ext(const char *name, const char *name_end, unsigned long *bitmap)

Overly long line.

> +{
> +    for ( int i = 0; i < riscv_isa_ext_count; i++ )

unsigned int

> +    {
> +        const struct riscv_isa_ext_data *ext = &riscv_isa_ext[i];
> +
> +        if ( (name_end - name == strlen(ext->name)) &&
> +             !strncasecmp(name, ext->name, name_end - name) )

Does this really need to be a case-insensitive comparison?

> +        {
> +            set_bit(ext->id, bitmap);

No need for atomicity, I suppose (i.e. __set_bit()).

> +            break;
> +        }
> +    }
> +}
> +
> +static int __init riscv_isa_parse_string(const char *isa, unsigned long *out_bitmap)
> +{
> +    if ( isa[0] != 'r' && isa[0] != 'R' )
> +        return -EINVAL;
> +
> +    if ( isa[1] != 'v' && isa[1] != 'V' )
> +        return -EINVAL;
> +
> +    if ( isa[2] != '3' && isa[3] != '2' &&
> +         isa[2] != '6' && isa[3] != '4' )
> +        return -EINVAL;

Any reason to accept the (respectively, depending on configuration) wrong
bitness? Or to accept e.g. RV34?

> +    isa += 4;
> +
> +    while ( *isa )
> +    {
> +        const char *ext = isa++;
> +        const char *ext_end = isa;
> +        bool ext_err = false;
> +
> +        switch ( *ext )
> +        {
> +        case 'x':
> +        case 'X':
> +            if ( acpi_disabled )
> +                printk_once("Vendor extensions are ignored in riscv,isa."
> +                            "Use riscv,isa-extensions instead\n");

How's this connected to ACPI? The more that you said there's nothing
ACPI-ish left.

> +            /*
> +             * To skip an extension, we find its end.
> +             * As multi-letter extensions must be split from other multi-letter
> +             * extensions with an "_", the end of a multi-letter extension will
> +             * either be the null character or the "_" at the start of the next
> +             * multi-letter extension.
> +             */
> +            for ( ; *isa && *isa != '_'; ++isa)
> +                ;
> +            ext_err = true;
> +            break;
> +        case 's':

Blank lines please between non-fall-through case blocks.

> +            /*
> +             * Workaround for invalid single-letter 's' & 'u' (QEMU).
> +             * No need to set the bit in riscv_isa as 's' & 'u' are
> +             * not valid ISA extensions. It works unless the first
> +             * multi-letter extension in the ISA string begins with
> +             * "Su" and is not prefixed with an underscore.
> +             */
> +            if ( ext[-1] != '_' && ext[1] == 'u' )
> +            {
> +                ++isa;
> +                ext_err = true;
> +                break;
> +            }

I'm afraid I don't understand this; the comment raises more questions
than it answers.

> +static int __init riscv_fill_hwcap_from_ext_list(void)
> +{
> +    const struct dt_device_node *cpus = dt_find_node_by_path("/cpus");
> +    const struct dt_device_node *cpu;
> +
> +    if ( !cpus )
> +    {
> +        printk("Missing /cpus node in the device tree?\n");
> +        return -EINVAL;
> +    }
> +
> +    dt_for_each_child_node(cpus, cpu)
> +    {
> +        const char *isa;
> +        int cpuid = 0;

Pointless initializer.

> +        if ( !dt_device_type_is_equal(cpu, "cpu") )
> +            continue;
> +
> +        cpuid = dt_get_cpuid_from_node(cpu);
> +        if ( cpuid < 0 )
> +            continue;
> +
> +        if ( cpuid >= NR_CPUS )
> +        {
> +            printk_once("%s: dts has more cpu than NR_CPUs\n", __func__);
> +            continue;
> +        }
> +
> +        if ( dt_property_read_string(cpu, "riscv,isa-extensions", &isa) )
> +        {
> +            printk("Unable to find \"riscv,isa-extensions\" devicetree entry "
> +                   "for cpu%d\n", cpuid);
> +            continue;
> +        }
> +        else
> +            printk("riscv,isa-extensions isnt supported\n");

IOW no matter what, a message will be logged. Odd.

Also: Preferably no "else" after an if() ending in "continue".

> +    }
> +
> +    return -EOPNOTSUPP;
> +}

Hmm, this function then has no way of succeeding? Certainly requires a
comment then.

> +static void __init riscv_fill_hwcap_from_isa_string(void)
> +{
> +    const char *isa;

Like in the earlier function better limit this and ...

> +    const struct dt_device_node *cpus = dt_find_node_by_path("/cpus");
> +    const struct dt_device_node *cpu;
> +    int cpuid = 0;

... this to ...

> +    if ( !acpi_disabled )
> +        panic("%s should be updated correspondingly to support ACPI\n", __func__);
> +
> +    if ( !cpus )
> +    {
> +        printk("Missing /cpus node in the device tree?\n");
> +        return;
> +    }
> +
> +    dt_for_each_child_node(cpus, cpu)
> +    {

... the scope of this loop.

> +        DECLARE_BITMAP(this_isa, RISCV_ISA_EXT_MAX);
> +
> +        if ( !dt_device_type_is_equal(cpu, "cpu") )
> +            continue;
> +
> +        cpuid = dt_get_cpuid_from_node(cpu);
> +        if ( cpuid < 0 )
> +            continue;
> +
> +        if ( cpuid >= NR_CPUS )
> +        {
> +            printk_once("%s: dts has more cpu than NR_CPUs\n", __func__);

What's "dts"? Did the 's' mean to be in "cpus" instead? Also NR_CPUS
to avoid confusion.

> +            continue;
> +        }
> +
> +        if ( acpi_disabled )
> +        {
> +            if ( dt_property_read_string(cpu, "riscv,isa", &isa) )
> +            {
> +                printk("Unable to find \"riscv,isa\" devicetree entry\n");
> +                continue;
> +            }
> +        } else

Nit: Stlye.

> +            panic("there is no support for ACPI\n");
> +
> +        riscv_isa_parse_string(isa, this_isa);
> +
> +        if ( bitmap_empty(riscv_isa, RISCV_ISA_EXT_MAX) )
> +            bitmap_copy(riscv_isa, this_isa, RISCV_ISA_EXT_MAX);
> +        else
> +            bitmap_and(riscv_isa, riscv_isa, this_isa, RISCV_ISA_EXT_MAX);

What if the first instance had no extensions at all? You'll then copy what
the second instance say, ending up with extensions not supported by one of
the CPUs.

> +bool riscv_isa_extension_available(const unsigned long *isa_bitmap, int bit)
> +{
> +    const unsigned long *bmap = (isa_bitmap) ? isa_bitmap : riscv_isa;
> +
> +    if (bit >= RISCV_ISA_EXT_MAX)

Nit: Style.

> +        return false;
> +
> +    return test_bit(bit, bmap) ? true : false;

No conditional operator like this is needed when the return type is bool
anyway.

> +void __init riscv_fill_hwcap(void)
> +{
> +    unsigned int i;
> +    size_t req_extns_amount = ARRAY_SIZE(required_extensions);
> +    bool all_extns_available = true;
> +
> +    if ( !acpi_disabled )
> +        riscv_fill_hwcap_from_isa_string();
> +    else {

Style again.

> +        int ret = riscv_fill_hwcap_from_ext_list();
> +
> +        if ( ret )
> +        {
> +            printk("Falling back to deprecated \"riscv,isa\"\n");
> +            riscv_fill_hwcap_from_isa_string();
> +        }
> +    }
> +
> +    for ( i = 0; i < req_extns_amount; i++ )
> +    {
> +        const struct riscv_isa_ext_data ext = required_extensions[i];
> +
> +        if ( !riscv_isa_extension_available(NULL, ext.id) )
> +        {
> +            printk("Xen requires extenstion: %s\n", ext.name);

extension

> +            all_extns_available = false;
> +        }
> +    }
> +
> +    if ( !all_extns_available )
> +        panic("Look why the extenstions above are needed in booting.txt\n");

extensions

> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/cpufeature.h
> @@ -0,0 +1,63 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef ASM__RISCV__CPUFEATURE_H
> +#define ASM__RISCV__CPUFEATURE_H
> +
> +#ifndef __ASSEMBLY__
> +
> +#define RISCV_ISA_EXT_a     ('a' - 'a')
> +#define RISCV_ISA_EXT_c     ('c' - 'a')
> +#define RISCV_ISA_EXT_d     ('d' - 'a')
> +#define RISCV_ISA_EXT_f     ('f' - 'a')
> +#define RISCV_ISA_EXT_h     ('h' - 'a')
> +#define RISCV_ISA_EXT_i     ('i' - 'a')
> +#define RISCV_ISA_EXT_m     ('m' - 'a')
> +#define RISCV_ISA_EXT_q     ('q' - 'a')
> +#define RISCV_ISA_EXT_v     ('v' - 'a')
> +
> +/*
> + * Increse this to higher value as kernel support more ISA extensions.
> + */
> +#define RISCV_ISA_EXT_MAX   128

What's this about? Why can't the last element of the enum below go without
this, thus not needing manual bumping here?

> +#define RISCV_ISA_EXT_SxAIA     RISCV_ISA_EXT_SSAIA

Why does this expand to RISCV_ISA_EXT_SSAIA and not RISCV_ISA_EXT_SMAIA?
(Easiest way to address: remove the #define, as it's unused. Yet if it
is to be kept, the question needs addressing, perhaps by way of a code
comment.)

> +/*
> + * These macros represent the logical IDs of each multi-letter RISC-V ISA
> + * extension and are used in the ISA bitmap. The logical IDs start from
> + * RISCV_ISA_EXT_BASE, which allows the 0-25 range to be reserved for single
> + * letter extensions. The maximum, RISCV_ISA_EXT_MAX, is defined in order
> + * to allocate the bitmap and may be increased when necessary.
> + *
> + * New extensions should just be added to the bottom, rather than added
> + * alphabetically, in order to avoid unnecessary shuffling.
> + */
> +#define RISCV_ISA_EXT_BASE  26

The comment living above this #define, it also wants wording to match
this. Specifically the text starts with describing ...

> +enum riscv_isa_ext_id {

... this enum instead (which doesn't consist of any macros).

> +    RISCV_ISA_EXT_ZICNTR = RISCV_ISA_EXT_BASE,
> +    RISCV_ISA_EXT_ZICSR,
> +    RISCV_ISA_EXT_ZIFENCEI,
> +    RISCV_ISA_EXT_ZIHINTPAUSE,
> +    RISCV_ISA_EXT_ZIHPM,
> +    RISCV_ISA_EXT_ZBB,
> +    RISCV_ISA_EXT_SMAIA,
> +    RISCV_ISA_EXT_SSAIA,
> +    RISCV_ISA_EXT_ID_MAX = RISCV_ISA_EXT_MAX,
> +};

Why can't the single-letter RISCV_ISA_EXT_? be part of this enum as well?

> +void riscv_fill_hwcap(void);
> +
> +bool riscv_isa_extension_available(const unsigned long *isa_bitmap, int bit);

A signed bit position? Can negative values be passed in? Actually - can't
this be enum riscv_isa_ext_id anyway?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jan 08 15:23:32 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 15:23:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867595.1279174 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXu7-0002kn-10; Wed, 08 Jan 2025 15:23:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867595.1279174; Wed, 08 Jan 2025 15:23:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVXu6-0002kg-Ta; Wed, 08 Jan 2025 15:23:30 +0000
Received: by outflank-mailman (input) for mailman id 867595;
 Wed, 08 Jan 2025 15:23:29 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=XghG=UA=amd.com=Stewart.Hildebrand@srs-se1.protection.inumbo.net>)
 id 1tVXu5-0002ka-Ky
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 15:23:29 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on2060c.outbound.protection.outlook.com
 [2a01:111:f403:2412::60c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8237fda1-cdd4-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 16:23:27 +0100 (CET)
Received: from DS7PR03CA0218.namprd03.prod.outlook.com (2603:10b6:5:3ba::13)
 by PH8PR12MB6940.namprd12.prod.outlook.com (2603:10b6:510:1bf::8) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8335.12; Wed, 8 Jan
 2025 15:23:21 +0000
Received: from DS1PEPF00017095.namprd03.prod.outlook.com
 (2603:10b6:5:3ba:cafe::dc) by DS7PR03CA0218.outlook.office365.com
 (2603:10b6:5:3ba::13) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8335.11 via Frontend Transport; Wed,
 8 Jan 2025 15:23:21 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 DS1PEPF00017095.mail.protection.outlook.com (10.167.17.138) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8335.7 via Frontend Transport; Wed, 8 Jan 2025 15:23:20 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 8 Jan
 2025 09:23:20 -0600
Received: from ubuntu.mshome.net (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Wed, 8 Jan 2025 09:23:18 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8237fda1-cdd4-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=y9KOpFLfoVHI2ly8VkpMXiONC7NOjXWlfgmlPRJ74X2yyACsh41KCZjWEKRfU+oNCQMhY9GlspoE3RdVxoi34a6HIq4DbYHQMHOoPsszi+sAp0TSj5H2a770Mr1KGFKiKPHBaePTtELUNW2YiwPUQ7eHhevsGch8rh3b7UqY2TG20J19bDSHIiPnJjO4tT17i7bzKeFmjpCFmlr/wruWHs08i/G6CuXe0XChSs4f/INmHNf5aseRhZkZy/n+Ayh2EGbBBYupRut7iIA3hxhG4HXiRfI5Zr03pSMLIdVP6bI8Cc7+8n049hnC1YExddPYGnVv1/S6fMyLicspBW3M1Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=tbCi9TE/1plTXrMEFllOGd7+VRgSmGpJFrC/Msrw+Ug=;
 b=Ut71Ag4fxH0cijYR/jqT5wlRwdugO6BAk6chL9KPw59m2KTauQgob0EisVUJFGNbKLjm9LRbqsSWkq7G2z7EdaF5NmPsgScvKdPlypLJ5piMxtLz8NfADaHi4AH32T9ahG+hPPrRWt4Qj3e5OWUw2zXcFaweiK2Jc3tPBBfKuJYdthNPJKikYQ3Nc1CItqh/yFQDl2BPH09D8rwBtgFYZwAaO95Un4qtTCYjMxwgCA5On6tDHUqpuX2cwZheS3VTIbQZCA1apTaqeG67aq5nAqHLFFEH66U+XBpLeel/fLImPrkN9KgSnbJjhxzckTslzi+LVAX6mfZCT+l8pdJyOA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=tbCi9TE/1plTXrMEFllOGd7+VRgSmGpJFrC/Msrw+Ug=;
 b=oxS0EBr98Pnjw5AlBquuhM744jJhV8UO4JlyK/owTDUaZLxzlbYG6K3oSqNFI57ckdkptCflthJDe7hCw7viIAYbV0NHbUSoNvXGpnjWYHdSgeJgQHNi61FbeTGEI0QrDVJJBkg5iGLVzv9Oo4mJP+SWFiPVxNAld/fioxHyCzc=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Stewart Hildebrand <stewart.hildebrand@amd.com>
To: <xen-devel@lists.xenproject.org>
CC: Stewart Hildebrand <stewart.hildebrand@amd.com>, Volodymyr Babchuk
	<volodymyr_babchuk@epam.com>, Bertrand Marquis <bertrand.marquis@arm.com>,
	Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
	Michal Orzel <michal.orzel@amd.com>, Oleksii Kurochko
	<oleksii.kurochko@gmail.com>
Subject: [PATCH] xen/arm: ffa: fix build with clang
Date: Wed, 8 Jan 2025 10:23:16 -0500
Message-ID: <20250108152317.335441-1-stewart.hildebrand@amd.com>
X-Mailer: git-send-email 2.47.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB04.amd.com: stewart.hildebrand@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS1PEPF00017095:EE_|PH8PR12MB6940:EE_
X-MS-Office365-Filtering-Correlation-Id: afed0dbd-41e5-41a5-c0e1-08dd2ff86296
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|1800799024|376014|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?yyjX7hQYKDVM7fZ08MsehC8wrbYiqSSXkTO0pW9zJ1B4/EGu1gQMh+MUD+NE?=
 =?us-ascii?Q?GiZRXPd940zaKaSAa4nSUKS5DrUjrm6ge8ujNpTHiR7P9LTcffyfQievyGSZ?=
 =?us-ascii?Q?iwKQANY+MHYZGY6MKsZTlC2ZYH24TCVKwTKuIGRWfUeyPrZBEE8sFfMc/Da7?=
 =?us-ascii?Q?VrAW/AXnpmQFRzeVC6VGvqBDVLRvrx8OdHEwCNwmc69iHSwpu3/abKeQdD0q?=
 =?us-ascii?Q?W//nkKlTRTDrRxJbFTeNnhWIKXWhnDePljvdAPdkkX//UGMuEMovQZnOcBRr?=
 =?us-ascii?Q?kK1T0WAmtB0sskhHFjPs2Xy7hmQqya0rKEh+YacgDA9AvT4HVohUnvBRAN2c?=
 =?us-ascii?Q?IrPRK7ALyGoDlwYJwJdr3cFBLCaZztfkTR2/NMNlgFHQQuaXz0/Fuk0G5Qk1?=
 =?us-ascii?Q?arzkqQB+ggggyvx7WtwD/HJpIcinn/qApbV2koVNf3tK4pBQ3pfX+i7stVII?=
 =?us-ascii?Q?FFJZDPbWZIq1ys6P2vf9juvJemLhuTqL4/m5HTqKi/t+QuNn9QHkPD3XZ1zn?=
 =?us-ascii?Q?krza6G0lfvDazt97C98QnNbRUYn3UCis49viuNpVbiFwWCgcsNpMOPu8eg3g?=
 =?us-ascii?Q?Hg+l//tVboZHauveK+U/00vVSZ0EpHHh7E9Xtl51Du+GZCVKt8TmPjfj1w0t?=
 =?us-ascii?Q?r3Kpq3birA5aXeb+fQZmc1+mPh+vqjgPrxAhDMhTlnmYW02tcBUrU2vb2shT?=
 =?us-ascii?Q?ldWwmd/euSsxrjbnWDPjT4XwG75tXa4nq1iZDg66G3UBRFQF53Idu3+HT9iY?=
 =?us-ascii?Q?2luEfVJJMJeJrdtuk7yjvKSYjqEb8Fd683WQsdT+KTEeXXugJimNEGWm4IUl?=
 =?us-ascii?Q?Ho0dFymGQrVJ+jW2+lZbSBCjW9RQxNfICFHyHL8PXmkkbB0zhZsNJbSJUigq?=
 =?us-ascii?Q?l9o4+2akGNctK31auP/uAceW5jBeV3Ysl1SicJ6HDhrNbP5ttuEePK8XlFdL?=
 =?us-ascii?Q?Z1RgKredAzzKwSHkv78tG3rcRSX9tFAA7uRO5+K99wmL0krjxrP2AbPnFOad?=
 =?us-ascii?Q?Ns4owemlWszuSsblGW20cSJOgCCa4eDXl5SMgo5qWbPbuQY2VuV4D5LZY6S4?=
 =?us-ascii?Q?ta9OBa0jyKnGfllobzULP1lL0Uh6thYC53TPHHaw2nA9FpzFy6orlmh9RvRE?=
 =?us-ascii?Q?RfZkjwykvVbXycTFTGA3nzJt7TIY2sKe2YNAAm/Sr+9cMOYZa/wy7KjR5Mp1?=
 =?us-ascii?Q?kBQRmFfKiIEV918OHtdxXSlFtu0TRDl0dhJ4kBUprITmEGT5jNa80p/d823/?=
 =?us-ascii?Q?gANKLPCMAbAXNRWDR0tdtfcUGJPELB6XkmCrPoPFIciZcnL/yvaiaBaK4nYO?=
 =?us-ascii?Q?bhi8qu78bbP47Lt4RN4PSewz1DdCQdtjJSd+4Y94cxs/AmrxrxCJ7D2p03vT?=
 =?us-ascii?Q?6YjErzkFzOl6OpluIRWqbtPHgNxS3V7fFPz+lTnXr9ipqiJV4LV3nGMUTKJi?=
 =?us-ascii?Q?KFWl9ZV6GIa64D1OZiWzLjT3DduF/2K3kLeSJbW55UW7DO96vcFLI3nhs6v1?=
 =?us-ascii?Q?/fWbOcamJJUGb7U=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(376014)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jan 2025 15:23:20.7826
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: afed0dbd-41e5-41a5-c0e1-08dd2ff86296
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DS1PEPF00017095.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB6940

Clang 16 reports:

In file included from arch/arm/tee/ffa.c:72:
arch/arm/tee/ffa_private.h:329:17: error: 'used' attribute ignored on a non-definition declaration [-Werror,-Wignored-attributes]
extern uint32_t __ro_after_init ffa_fw_version;
                ^

Remove the attribute from the header to resolve this. The attribute in
ffa.c is the one the matters anyway.

Fixes: 2f9f240a5e87 ("xen/arm: ffa: Fine granular call support")
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
---
It appears the variable ffa_fw_version is only used in ffa.c. Was there
any rationale for exporting the symbol in 2f9f240a5e87 ("xen/arm: ffa:
Fine granular call support")? If not, perhaps we ought to make it static
again and remove the declaration in the header.
---
 xen/arch/arm/tee/ffa_private.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/tee/ffa_private.h b/xen/arch/arm/tee/ffa_private.h
index d441c0ca5598..05368d5a88d3 100644
--- a/xen/arch/arm/tee/ffa_private.h
+++ b/xen/arch/arm/tee/ffa_private.h
@@ -326,7 +326,7 @@ extern void *ffa_rx;
 extern void *ffa_tx;
 extern spinlock_t ffa_rx_buffer_lock;
 extern spinlock_t ffa_tx_buffer_lock;
-extern uint32_t __ro_after_init ffa_fw_version;
+extern uint32_t ffa_fw_version;
 extern DECLARE_BITMAP(ffa_fw_abi_supported, FFA_ABI_BITMAP_SIZE);
 
 bool ffa_shm_domain_destroy(struct domain *d);

base-commit: 70f5a875becc9444a959830b10a361982c31a366
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 15:30:52 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 15:30:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867621.1279185 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVY16-0004n0-Or; Wed, 08 Jan 2025 15:30:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867621.1279185; Wed, 08 Jan 2025 15: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 <xen-devel-bounces@lists.xenproject.org>)
	id 1tVY16-0004mt-KE; Wed, 08 Jan 2025 15:30:44 +0000
Received: by outflank-mailman (input) for mailman id 867621;
 Wed, 08 Jan 2025 15:30: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
 <SRS0=HyFE=UA=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tVY15-0004lR-7o
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 15:30:43 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8574317e-cdd5-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 16:30:42 +0100 (CET)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-aaec61d0f65so287237666b.1
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 07:30:42 -0800 (PST)
Received: from localhost ([66.81.170.107]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0e830b3bsm2525510166b.25.2025.01.08.07.30.40
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 08 Jan 2025 07:30:41 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8574317e-cdd5-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736350242; x=1736955042; darn=lists.xenproject.org;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=WAPuMNb+M3wU8pgWoX5uBk8yhxbzO4jf0DmnLwT2cns=;
        b=Hh3uNjPbNoVYuS3nUx99TS8Bjb6gpfhr4FGYeNhF1keOFZcROgs+VbUHy4O91qwKlC
         JN7cSqQFGYDKDxvrB6G5S4egCx07WyHQvaTfjMRp8MNh1NddZjDtjUqfhZYM0DYBnxp7
         4tw+mQY/myZQZB6XNNmbR2MKrx8sOSctYnq94=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736350242; x=1736955042;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=WAPuMNb+M3wU8pgWoX5uBk8yhxbzO4jf0DmnLwT2cns=;
        b=hfbQxyKwEIUz8yxDH9/LaHgmelEokcDaVhwiHI1y0dpu4NExZLih46BsEhlrQ0AnbE
         PYMrI9+snwdUmXhHDL3BuL590dWxGsCeF+yfcVQiX2TlrxOimdaMYgTy9RDB+goAbzZw
         Swekm+tqyQctYtqTlo0+bIOIAkZGTJe1XZQXcDkIiIf4i8iBzJrwlFJNV5IaS09JsQA4
         aFITNmexmlLaG02Xzy2socQ+jqTLXUdymh6sc3Dh990c3GOiLuDf1qYNHZURHBJ/Cu7V
         dzp3qbS3sQXBmSC4f9b/0Ww53ewZSefotDYataGyepWWLtZowlS1RBarN77eIGA20t/t
         i6Kg==
X-Forwarded-Encrypted: i=1; AJvYcCX73H8PHM4GmywLJref86tGl1HMOlw5n+40dWVZkNg6kgm/m2xK8dV1FuHMyG+rWoh0krDlJO76IkY=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxi2evuct2Mt8gPVws4Ur/x7Y67Ub4xJQ+LQVp9eA+MJ6vO/ljU
	ETxOCbwjjpa2//fNZE1NcdqZ07GJoFXTZJPSl/8mhAaTvbZT3J9ymJXGD+UIncs=
X-Gm-Gg: ASbGncs7P25JWViOFPFDZIraO2CW31IbS3NEQ441KMi0cL+jjdQLsr90hxEOzPrGQrk
	QwHqA3+s4sd1YiBGIu4qFfQpYQM1BnsVtjmnTShJc7AXDfCrnasUud8oS7vcB4F6Wn+G4OKKS8z
	j8WcEYYks5uFq+jVJ+EDr31fmZvQvFMyAGSSlJSXkn+GNEqxUthOrWxkioV/UcaJPI/6o4bnH07
	J49PcQqzHfZu0zFGerFbzpcqnbrMPuYT6a0BCouD8d2SlK7BrB0GDl8sQDGRHw=
X-Google-Smtp-Source: AGHT+IF1jtzQrenLLUHw/EvIeYNySOEf6iabc3P+fv37Z7gziuh3XNcSRcDsyU7AYc6ytVKdb08DWw==
X-Received: by 2002:a17:907:70c:b0:aa6:7d82:5411 with SMTP id a640c23a62f3a-ab2abc6ca52mr307206866b.40.1736350241862;
        Wed, 08 Jan 2025 07:30:41 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Wed, 08 Jan 2025 15:30:40 +0000
Message-Id: <D6WSSGJ8EVDQ.ODGHM082XOM5@cloud.com>
Cc: "Jan Beulich" <jbeulich@suse.com>, "Andrew Cooper"
 <andrew.cooper3@citrix.com>, =?utf-8?q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, "Anthony PERARD" <anthony.perard@vates.tech>,
 "Michal Orzel" <michal.orzel@amd.com>, "Julien Grall" <julien@xen.org>,
 "Stefano Stabellini" <sstabellini@kernel.org>, "Bertrand Marquis"
 <bertrand.marquis@arm.com>, "Volodymyr Babchuk"
 <Volodymyr_Babchuk@epam.com>
Subject: Re: [PATCH v5 00/15] Remove the directmap
From: "Alejandro Vallejo" <alejandro.vallejo@cloud.com>
To: "Alejandro Vallejo" <alejandro.vallejo@cloud.com>,
 <xen-devel@lists.xenproject.org>
X-Mailer: aerc 0.18.2
References: <20250108151822.16030-1-alejandro.vallejo@cloud.com>
In-Reply-To: <20250108151822.16030-1-alejandro.vallejo@cloud.com>

Hi,

Bah, I forgot to remove Wei from the CC list. Sorry, and beware the bounces
when replying on patches 2 and 4...

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Wed Jan 08 15:36:15 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 15:36:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867630.1279194 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVY6L-0006Ps-9Y; Wed, 08 Jan 2025 15:36:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867630.1279194; Wed, 08 Jan 2025 15:36:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVY6L-0006Pl-6f; Wed, 08 Jan 2025 15:36:09 +0000
Received: by outflank-mailman (input) for mailman id 867630;
 Wed, 08 Jan 2025 15:36:08 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=HByp=UA=arm.com=Bertrand.Marquis@srs-se1.protection.inumbo.net>)
 id 1tVY6J-0006Pc-Sj
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 15:36:08 +0000
Received: from DB3PR0202CU003.outbound.protection.outlook.com
 (mail-northeuropeazlp170110001.outbound.protection.outlook.com
 [2a01:111:f403:c200::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 469c8771-cdd6-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 16:36:06 +0100 (CET)
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by DB4PR08MB8174.eurprd08.prod.outlook.com (2603:10a6:10:382::9) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8314.17; Wed, 8 Jan
 2025 15:36:00 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a%4]) with mapi id 15.20.8335.011; Wed, 8 Jan 2025
 15:36:00 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 469c8771-cdd6-11ef-a0df-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=tZqKGN0ugm3z7ag6zXi2Y0uMtApMd+lqgOw/UyGX5Nkgc/AkI1joZ8/jM9Pu20xu1qjeXpzBYwGVMjfRiOUZWrNpQd6KJgaw3KDY6dHzZlDdkUYVqo+rW/B7Xn+S+SbgFCDYbuHRykcxKO6OZaqQc9TrAPdunMzecoO99mSVsUAMLdlxQdkr+FRXTBqCZM51cITFmKMoMmh1qnQQFFmC2I58UCtgsloK3e3ulLknG0voVqhDydKXKiHKHepKTz1KHEJbpX5C1ePNs1HSkk5fK1T+1+sT7v7cdPVeqWmstub61xIo6CczMZDisgDw/tdwlQuQJKvt87ATcsZBoRV2PA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=3hD8xIYc6VVS824h8d5KufrDDBbP5el6Akssegh8XgI=;
 b=dW2Cv5JEQlhK75esnH1QGhx79p0aCoybKlciQLM4gacIX/VASxRhjxcq4Bi5B05ixMVS75Cft8ffVwLzeG/nS+FXSr+30E/IAbZAfq+bCzhQ+p36mZIHUo+TzcAwVTP2vlC3czKguRjMcy323t9XPHveSzb7jA+nb/vx09yCW9N5HqqfuvAKim2lp7jv95u6W76JrQ8TSejaL2J9yuYH/wPIvQ2+3/rnqQP6yb9V2iZ4XTTz1oYg3ycm4o0bhQfXcgSB3Z51pumTYoYk9NQjLi7yOztgV8gxTY/SdiuN/WdF7FzXAcJdd+pyVHthdzn8Q8r8Dj3YwInZPhUmiUK53g==
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=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=3hD8xIYc6VVS824h8d5KufrDDBbP5el6Akssegh8XgI=;
 b=SaelAuCBdlbQ7tRU9N2A8aEbO/xdUIGZz6QE8MvfL9OWGf182sivsnqKZ/U4vEiaiJJDmlSjlIRRAHzRg5LNqp5j9t/dqFqv9NTABCo8ygP2fwQ4SRNa6nXDgGI8CrYqc0QmyuTXSwAmwJBNvaBMh2mNpWs7cKeKrj9gKpDt++U=
From: Bertrand Marquis <Bertrand.Marquis@arm.com>
To: Stewart Hildebrand <Stewart.Hildebrand@amd.com>
CC: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Volodymyr Babchuk <volodymyr_babchuk@epam.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Michal Orzel
	<michal.orzel@amd.com>, Oleksii Kurochko <oleksii.kurochko@gmail.com>
Subject: Re: [PATCH] xen/arm: ffa: fix build with clang
Thread-Topic: [PATCH] xen/arm: ffa: fix build with clang
Thread-Index: AQHbYeFGu37kkF0Uuk6Sa5TIC8NMALMNAjoA
Date: Wed, 8 Jan 2025 15:36:00 +0000
Message-ID: <842B5D1B-1EF9-4E2B-9F9C-800A8F3269CC@arm.com>
References: <20250108152317.335441-1-stewart.hildebrand@amd.com>
In-Reply-To: <20250108152317.335441-1-stewart.hildebrand@amd.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.200.121)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DB9PR08MB6588:EE_|DB4PR08MB8174:EE_
x-ms-office365-filtering-correlation-id: a1654f7a-5159-4a2c-38be-08dd2ffa277f
x-checkrecipientrouted: true
nodisclaimer: true
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|366016|38070700018;
x-microsoft-antispam-message-info:
 =?us-ascii?Q?WRoY8floB53zxQvSGfKHI56XyguWStB6we7BWfecYWFlj7+iiiVDvzzX/9DZ?=
 =?us-ascii?Q?yj8y8yxNe6c2hQJybYMCBlhob9XhRmfLttxxgtMUNTINfz4GP1ozDUyaSUQN?=
 =?us-ascii?Q?8a1wOx9gyQNjTdJ5l9jC+4Ip9r7g4fbREmSXWs2ufTtP67q+8IizdAAkTkxD?=
 =?us-ascii?Q?GQmfHTtEFPG8ni3hp+SbubcR1KAbjq9jyaVlJKNPmV5v8R1gKs6QBYc5+cLD?=
 =?us-ascii?Q?QdKD2JcRUMeawh4BtJPu87V7Ujz4+a+5oBX2lV5xXpLbo3pZUKJFALKeqWHm?=
 =?us-ascii?Q?hbh6VA4rbYfifmnbSsoD1ssB8PdhQHb+OdH4YOgHZh6ZjVH63JGEGUDFCblI?=
 =?us-ascii?Q?t8EgldFsr1hOXP7AipmSiU+9csxil6M7KGCNTf8HyYIH+tbKUqXiZD+wzv38?=
 =?us-ascii?Q?h0tUWZcvE+hx6WiaUf00IcYtoc0dFYjU/AtCt7TsBaH9Dy3WPQT5cA9vxcZu?=
 =?us-ascii?Q?NZWktYRHLrvCETKdwsLQ3jqLVYIOmqHHrQT+WXnyeAx1eEMxwTM5NDxhtCVj?=
 =?us-ascii?Q?eC6VPsZugf7VtLOViRA5kCCKHnX9En4zts78g1QS3EEGWwJEcmx7C4toz7Ab?=
 =?us-ascii?Q?fYC417uQ2ZXRMrO+nkLjs1CitPUbeNhknVy/rs3dIW4xMkHpG7jESPdB8M8y?=
 =?us-ascii?Q?HQhCdxERkZGtFmVmNDEbMIfrXZzuKmIU98igkqrH3i7QDWl4Y3eDiA79ITBU?=
 =?us-ascii?Q?PuykEYGc5IK+Xfh25fUz+7iuu1CZ5GuCqFneFADmH6hX27/U+ahFhbxvuKDR?=
 =?us-ascii?Q?M/MrRty5VyScdz7XCvMR7mInoTInlbSl6wkQWrizHN8AXIYLWZE7B1NyFa/q?=
 =?us-ascii?Q?Z8pAyAconB8hn6sm4skPIRbyZC4OLiRW6IS9FDdLhQRMgjTLqgY5WXu/Mbge?=
 =?us-ascii?Q?u74eJ10kuQi8q3JTeVfugR69pBBofE1FDCULUVmQx+2upWq+J90PCCQU+tCa?=
 =?us-ascii?Q?mMabOJdUmgI9lFAQ3ehcQ2xopKy3Z5Ub6LN5PytWho6ZDVZ52pcM8i61/3E+?=
 =?us-ascii?Q?qe63MKm9+80yBK44tmUgEGEhIzH2ee24vbWcEs5XYzbdPaGZ5f5KhkZD1izF?=
 =?us-ascii?Q?vCg+aEuh2LP7KuMJ/poBpii33PbI2KhfAUbc4sdDs14ffkn1R0ulExVohX8P?=
 =?us-ascii?Q?alb7yLv2IryfQejNxzxEVrEbWP0PPATYaYEddyXVEX94oPHoVHvORSp+nYvo?=
 =?us-ascii?Q?L9Q7qKVeksjwr7W1yNPmpCmkg1Wpy/OTq7wmvP871HfMYrrqcy6wPigFNwi/?=
 =?us-ascii?Q?/BOYtqVjleBYgizR4GYYtz+D5R7wV56UxXBlZrYT3khvUAWwHwuMJA79owZK?=
 =?us-ascii?Q?HwVd8KGTYiL9kpcxG5l5mKNgpg4Ybo6sEZxOZVIWstHxq6B63WVXTtmmXoB2?=
 =?us-ascii?Q?QCNKMXBygk7knIb7K3BrH5i8hCE9+n+c4On2JTkK0hpGUEfpBLHHtCNQ/yIn?=
 =?us-ascii?Q?IYXaq//fleWYAasRnJX6TNAyOUiM1RXR?=
x-forefront-antispam-report:
 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:(13230040)(1800799024)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?sMu+WaYevGOZjfVvivzJsZd0qBsmc28jUSotZZFfj58faUpqZLe/7hiNvhw0?=
 =?us-ascii?Q?YArUitpm5RtTq8sM6DIbsNawIdxsxhx8sfcwp5e5AtrllamtYjSA/oybg0V6?=
 =?us-ascii?Q?QpkmNCHnIszFZ7BbLGONTJz5Uw0385wJsUYgPeE9x0SB+DzqTi+64Dk0N3S0?=
 =?us-ascii?Q?ejUsfQm6r/Zc8nNrXuqFAKJj/7weGfFO+Scqr0lYGnpDQ4xT4Z5wuCb+NOHM?=
 =?us-ascii?Q?l+ymACKPDZQKsUwoiUXVO6EbnTXSTwDaaeKp+P/O5OvsC4ejEbC9bLhyYzPd?=
 =?us-ascii?Q?cjCcdcGW23IAJ4ZEZhKKe3151kx59Sxpen0EkmX1WmY9mm7OU5doULmzXn0V?=
 =?us-ascii?Q?FHeSPMULNtgl/QT7JYIwlhOTv7XiPQ6WxxHbedHmAxhP2rL2HUaeLsv1p2Fz?=
 =?us-ascii?Q?gAD27U6HgNRiFCC/dvHpj9sRI/BNQ3pTiWYHbwJ46qMIgVVd5ONdfJcwoRWF?=
 =?us-ascii?Q?atBp2M90Jvq7Ccjo6B2z29GNN6B2rFOVGsD+1IH6glox+jmPMG3X4SzZ2LTT?=
 =?us-ascii?Q?SDmhur3+cNLvrqvsmXYxiVY8EaJbzGDR6DlsLfKcLbP6adteLQskmzfjsT+w?=
 =?us-ascii?Q?jyBVsuttCTXottcprYzlbpSe1acLA61LejbIES8BIIkH8prNibLZf4M6n3uo?=
 =?us-ascii?Q?sqTgDJT372fctkc8V5zUUvd2t/V55vfVqK1MBbewGHJhac84YHQatxI05UOI?=
 =?us-ascii?Q?HPl3cCRZM6A5EUc0a/Xg0L17lx9OdJx+mSr09onbTPVnPb3rRxIow8l6OvBd?=
 =?us-ascii?Q?AHUoZfzE23dTeMgr/0n7oQKwhjeGr0SMqSNvPdxdmcd5qtSt+54q7k7ZYwcm?=
 =?us-ascii?Q?E7GGvN+0Uj7e/B7krCaHzYkCJ1g6P7qp7wVCASxwcC2+/YdVe6DqRLn+Jvnj?=
 =?us-ascii?Q?L4AjtN7T9VJsY99dLqpQvWR0/KhAx2LoQA2iGx6w0Pv+mKurq/ybW+t2OZPz?=
 =?us-ascii?Q?cnIKJJ7LzxjmMM4qJQtC39BrunNDWNzB8OBeC+0uTiCANvlJRDCr6M6W64p9?=
 =?us-ascii?Q?H3peukSwQ2dv9mnwxIaGAaNHMqbVepgu2kdBItAS/WRTFB2Vs7cQqZPKFSmZ?=
 =?us-ascii?Q?3vWRd+cmcTcwyaJexGE6C/b6n2DyMR4126f2DYB6Aa7BmjGrPSdSOC8FBMhF?=
 =?us-ascii?Q?xQ7ZaJIo4+EBYr4Kbj1CLO/l9nCS1OgGleJLS6jt7F7N0uiOMuxLg9d8BK8G?=
 =?us-ascii?Q?tDmWO4DOZkzUalzNuAvbY7mTFIbK9c8CIHK/wnaQmnPnouqwak/0d4HpaNnO?=
 =?us-ascii?Q?w4KK1zSFcansSsMOSqrcUXBQaHIb7lYEu1OCmbg1vZE/jwqD5CYPVWmF9ZS5?=
 =?us-ascii?Q?c1QaoZ2iAfn/PShchl/Sk+h+8ybic0Y19Y1CSuOksqcbBAKjwllPHzBGY2II?=
 =?us-ascii?Q?FlualBHSZORuOcIvNP15NJujBmOAWEkzokI/wKSQtQADspMnyDlqlLxIbajU?=
 =?us-ascii?Q?ud0g9psuZnlx7+kWPvViFJdP93wXAO11FOD6WoJqlpI4XtyS2Kl0aC6m3LjT?=
 =?us-ascii?Q?dyT42QrV41XrP4pKF88OQBZMX3hfCU+zYdm/qaawYPFJOjtwDp5i/QXc9hf4?=
 =?us-ascii?Q?CLKnnEo3NaiOZHUaEQKamHsJrIeOgw72u5W8Mzi8U9T7laZzw3FW3+hDI6ZP?=
 =?us-ascii?Q?zg=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <C70909D4879E264E8B2BFE220C32F839@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DB9PR08MB6588.eurprd08.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a1654f7a-5159-4a2c-38be-08dd2ffa277f
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2025 15:36:00.7281
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: noHqKtDNMMnddq/GBfKENYmtrhn581k1MBwoXNSp/xAaS0+VKrDZODRRttwnoIIgxLTVQanYPLg+Dkno+ttcyFEHHFhKdfWEK6sDDACrW3o=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR08MB8174

Hi Stewart,

Thanks a lot for the finding and the fix :-)

> On 8 Jan 2025, at 16:23, Stewart Hildebrand <Stewart.Hildebrand@amd.com> =
wrote:
>=20
> Clang 16 reports:
>=20
> In file included from arch/arm/tee/ffa.c:72:
> arch/arm/tee/ffa_private.h:329:17: error: 'used' attribute ignored on a n=
on-definition declaration [-Werror,-Wignored-attributes]
> extern uint32_t __ro_after_init ffa_fw_version;
>                ^
>=20
> Remove the attribute from the header to resolve this. The attribute in
> ffa.c is the one the matters anyway.
>=20
> Fixes: 2f9f240a5e87 ("xen/arm: ffa: Fine granular call support")
> Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>

Cheers
Bertrand


> ---
> It appears the variable ffa_fw_version is only used in ffa.c. Was there
> any rationale for exporting the symbol in 2f9f240a5e87 ("xen/arm: ffa:
> Fine granular call support")? If not, perhaps we ought to make it static
> again and remove the declaration in the header.
> ---
> xen/arch/arm/tee/ffa_private.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>=20
> diff --git a/xen/arch/arm/tee/ffa_private.h b/xen/arch/arm/tee/ffa_privat=
e.h
> index d441c0ca5598..05368d5a88d3 100644
> --- a/xen/arch/arm/tee/ffa_private.h
> +++ b/xen/arch/arm/tee/ffa_private.h
> @@ -326,7 +326,7 @@ extern void *ffa_rx;
> extern void *ffa_tx;
> extern spinlock_t ffa_rx_buffer_lock;
> extern spinlock_t ffa_tx_buffer_lock;
> -extern uint32_t __ro_after_init ffa_fw_version;
> +extern uint32_t ffa_fw_version;
> extern DECLARE_BITMAP(ffa_fw_abi_supported, FFA_ABI_BITMAP_SIZE);
>=20
> bool ffa_shm_domain_destroy(struct domain *d);
>=20
> base-commit: 70f5a875becc9444a959830b10a361982c31a366
> --=20
> 2.47.1
>=20



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 15:45:33 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 15:45:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867638.1279203 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVYFN-0001Q7-4g; Wed, 08 Jan 2025 15:45:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867638.1279203; Wed, 08 Jan 2025 15:45:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVYFN-0001Q0-1o; Wed, 08 Jan 2025 15:45:29 +0000
Received: by outflank-mailman (input) for mailman id 867638;
 Wed, 08 Jan 2025 15:45:27 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=HyFE=UA=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tVYFL-0001Ps-Ib
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 15:45:27 +0000
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com
 [2a00:1450:4864:20::435])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 94809e06-cdd7-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 16:45:26 +0100 (CET)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3862ca8e0bbso12862993f8f.0
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 07:45:26 -0800 (PST)
Received: from localhost ([66.81.170.107]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0e82f60asm2543024266b.28.2025.01.08.07.45.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 08 Jan 2025 07:45:25 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 94809e06-cdd7-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736351126; x=1736955926; darn=lists.xenproject.org;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=SAjEOfBmhiiE2DME1yP7kSdCmLUdBEtt2iyEXv5G4rY=;
        b=gIw54+aKuA7PdmmY0h/PbE/PnqlXMMgd2GK+fgoRQHylwX6CPpQsyp1mFG+zrVN19O
         eN2QN4z7rLv+d6idYH3iq5/mhX3GGpezkjT3BnnoctjoZab78PYODOF6gUB7TpjAUzG8
         6GQLDQBkQN4UInFQe7JtQBOhK1Y1QXaROkh3k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736351126; x=1736955926;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=SAjEOfBmhiiE2DME1yP7kSdCmLUdBEtt2iyEXv5G4rY=;
        b=Guf4PNz+LF9/vlkDIkPEDRsVRa44t1x2W6lOuj3npr+w+MAEA92MNO11UjmjQE2+Bi
         A3EajcwuqqTH3G2tOETSjQiIp1o3NHkTsbipjgH3HSOJiAcUgoWnDRCaNB6+RIF+WvUf
         aS4ySAfnvjBqh4JdyQlzXAyEHyylz+D14fvF2isSjhGsnEIU/qnCwD5w6ILocBZuuplM
         jJvqTrx+qscd49hxPiEhtVrz/gSxic9x3ZrAMRCeAZ8+5oJjcjPssrbSA7t2cIEN982N
         7j574it46TCKqGGyOxTKpWhPIApEE2WDjOChOX6MVK99lHXXquld6oRwJM4w+4PMBLx3
         qW/g==
X-Forwarded-Encrypted: i=1; AJvYcCW29IlnnFE1cuYo1Yn8XfXVAYZr5jonx9XDxUYlEZUzByW64Asig7T8A2x2FeHg89b9FrHZnNa/Qww=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyJ69vPFcus5wqk1P0yxs6u/Xxv17Nmc49FA7DV7vLQtjc/IUiv
	iDJUBdtpR4+bRbUYgtmK5gWoZ7VA0dirNVWYs4OWLmOBjxi9SQMKvD2nNBQqIB0=
X-Gm-Gg: ASbGncvpyu/9o8pHKIUoAQ+aul+2KztRgNud0booQMPcqo2AYiC4trIlW/tw/T256m8
	ELHYRCkpUMvtURi2Vdp9tRmfDLoxBtpgdmM04dKM2EEEmUt3zO7JVhpV6DJm4dIVdV5Akkpiv6K
	CteUm/T/e3HcDd/kTHS+MLK7Nmj8alRhJWwlhDfiu+6V/O30iZPQl8pV6PpdrPlIfAH9uzXCHHw
	0cfykK+Mh9vS+B5w/8ltgrX5Oz6EOiMqx3OkosEG+YKmoStiFdm9/eRQNY8fmQ=
X-Google-Smtp-Source: AGHT+IG+sQEDWfRAZQ0YkfEs6FPvhz9Lib6SrkoSA6TTOxncQgdbKzbr1Q9CTmuC4dguJPdeFirCbQ==
X-Received: by 2002:a05:6000:1447:b0:385:fb34:d5a0 with SMTP id ffacd0b85a97d-38a8731f4fcmr2930660f8f.29.1736351126074;
        Wed, 08 Jan 2025 07:45:26 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Wed, 08 Jan 2025 15:45:24 +0000
Message-Id: <D6WT3QSKXNG4.162UPSGMQ1ZIS@cloud.com>
Cc: "Volodymyr Babchuk" <volodymyr_babchuk@epam.com>, "Bertrand Marquis"
 <bertrand.marquis@arm.com>, "Stefano Stabellini" <sstabellini@kernel.org>,
 "Julien Grall" <julien@xen.org>, "Michal Orzel" <michal.orzel@amd.com>,
 "Oleksii Kurochko" <oleksii.kurochko@gmail.com>
Subject: Re: [PATCH] xen/arm: ffa: fix build with clang
From: "Alejandro Vallejo" <alejandro.vallejo@cloud.com>
To: "Stewart Hildebrand" <stewart.hildebrand@amd.com>,
 <xen-devel@lists.xenproject.org>
X-Mailer: aerc 0.18.2
References: <20250108152317.335441-1-stewart.hildebrand@amd.com>
In-Reply-To: <20250108152317.335441-1-stewart.hildebrand@amd.com>

Hi,

On Wed Jan 8, 2025 at 3:23 PM GMT, Stewart Hildebrand wrote:
> Clang 16 reports:
>
> In file included from arch/arm/tee/ffa.c:72:
> arch/arm/tee/ffa_private.h:329:17: error: 'used' attribute ignored on a n=
on-definition declaration [-Werror,-Wignored-attributes]
> extern uint32_t __ro_after_init ffa_fw_version;
>                 ^
>
> Remove the attribute from the header to resolve this. The attribute in
> ffa.c is the one the matters anyway.
>
> Fixes: 2f9f240a5e87 ("xen/arm: ffa: Fine granular call support")
> Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
> ---
> It appears the variable ffa_fw_version is only used in ffa.c. Was there
> any rationale for exporting the symbol in 2f9f240a5e87 ("xen/arm: ffa:
> Fine granular call support")? If not, perhaps we ought to make it static
> again and remove the declaration in the header.

The only reason I can think of is wanting to have it in the symbol table of=
 the
ELF file for some reason (livepatching?). But that's far fetched at best.

> ---
>  xen/arch/arm/tee/ffa_private.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xen/arch/arm/tee/ffa_private.h b/xen/arch/arm/tee/ffa_privat=
e.h
> index d441c0ca5598..05368d5a88d3 100644
> --- a/xen/arch/arm/tee/ffa_private.h
> +++ b/xen/arch/arm/tee/ffa_private.h
> @@ -326,7 +326,7 @@ extern void *ffa_rx;
>  extern void *ffa_tx;
>  extern spinlock_t ffa_rx_buffer_lock;
>  extern spinlock_t ffa_tx_buffer_lock;
> -extern uint32_t __ro_after_init ffa_fw_version;
> +extern uint32_t ffa_fw_version;
>  extern DECLARE_BITMAP(ffa_fw_abi_supported, FFA_ABI_BITMAP_SIZE);
> =20
>  bool ffa_shm_domain_destroy(struct domain *d);
>
> base-commit: 70f5a875becc9444a959830b10a361982c31a366

IMO, it makes sense to make it static and remove this line altogether as yo=
u
suggest. If it needs to be exported later on it can be adjusted as needed.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Wed Jan 08 15:59:42 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 15:59:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867650.1279213 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVYT1-0004eG-D8; Wed, 08 Jan 2025 15:59:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867650.1279213; Wed, 08 Jan 2025 15:59:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVYT1-0004e9-Ab; Wed, 08 Jan 2025 15:59:35 +0000
Received: by outflank-mailman (input) for mailman id 867650;
 Wed, 08 Jan 2025 15:59:34 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=HyFE=UA=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tVYT0-0004dj-1I
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 15:59:34 +0000
Received: from mail-ed1-x541.google.com (mail-ed1-x541.google.com
 [2a00:1450:4864:20::541])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8be97032-cdd9-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 16:59:31 +0100 (CET)
Received: by mail-ed1-x541.google.com with SMTP id
 4fb4d7f45d1cf-5d3f65844deso28680436a12.0
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 07:59:31 -0800 (PST)
Received: from localhost ([66.81.170.107]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0efe46d5sm2519767566b.103.2025.01.08.07.59.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 08 Jan 2025 07:59:30 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8be97032-cdd9-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736351971; x=1736956771; darn=lists.xenproject.org;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=JxTMDE2iuurkhnXzPe9WEOUJmCm8L9G7Q+PfJDEXAj0=;
        b=YpqtcZ0/nBZSjgJFAAPTCLmwregh2z0rMuH4dTD6C0i6TkpRmHk0ccSNfeTe0bzTa7
         /aSfGrkdkpXbmDs8fqGcYr1hgzLx7KvpMIVbjjUBZbfPZyhGa0eNiGbqAWuZditeSC7j
         TcIDi+GaFgT6RYKr0lp+8lhvhC5OPfLSlCgME=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736351971; x=1736956771;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=JxTMDE2iuurkhnXzPe9WEOUJmCm8L9G7Q+PfJDEXAj0=;
        b=vjXw6FwAws49k3FRMXvELlToyoasofkplUuLkmox6DeRvtFLEWgAnvldcDEXxyWT+8
         wku0ySJ/FbVYJpPrF+Ai0NAsmLcP+nVAWXRyHgrikyQur72+Dg9RU/PJssGtnHzlsMDv
         wTW9plSZ8d7OnMFKq7HAoHLvXRZzOITPt0QMJOMokRQAXq7Tujz1xBnYbt/6+LMYeMKY
         IOVJmbBTP7Ivgfq6HhWKfn8mQFHiYOrNAM8ihNnNZSlXQeevVAz4gB7IARL/XZCVyDmq
         5fOqe5X9YqggWfrsUXzfCFH/4BS0dh2Bojjbv0S87wQKfYMmLZLUyRa23/1KrIGvdsvm
         dDOA==
X-Forwarded-Encrypted: i=1; AJvYcCUUrwQom5RxvMaoNHL9navnaem5D2v4n4rB2TvvZLa/JAdRrUOq5nKO1JIVTgvrd6nLmS+jxqnY27Y=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyszDTCKa3Q0Yu8s2b+zpWIUArAtT/N/oaUk6dVAPAdYQTNggT6
	b3rkCcVA49k1ZwV9P8VGHggHvxh69bmTyYoYUSxCtooqvDT0PCrJvByaepBzjqQ=
X-Gm-Gg: ASbGnctxvUqwim53EUmkRo+PqDJdVH0+VMu1BAdjZKuLjDEByI+cxZ9xUtVWdQYoAZO
	CaSKXymJ9kumthLUkYGa9+v0mzOVHlG9ttYlgRFMctNSmIo8vVgLnF2FjTaR7vPLeDGND7YKGQY
	bXrfeIHRIdnhQ6j3qHsSaCEh22VPk3KoFZMi4FWFn3D48gU+4Ggm6TJIzsHs3TVtwzmIY5BWOUm
	61Pig4BbC9SoFUr33lR0Xoi+TiX+7iaXedWcUpH7aUO8BUn7tCVWsXW42NpfRA=
X-Google-Smtp-Source: AGHT+IGLkDcEPAuOqLHvkN97fiUuHAg0puRXEANIDnGvjvMGKaYaOoeoBZgWNPmXAs1eVgKVZrPd6w==
X-Received: by 2002:a17:906:6a1e:b0:aae:bac6:6659 with SMTP id a640c23a62f3a-ab2ab675c7bmr269997466b.7.1736351971123;
        Wed, 08 Jan 2025 07:59:31 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Wed, 08 Jan 2025 15:59:29 +0000
Message-Id: <D6WTEJ1ZSB1F.3SRMZ5WCOIQUH@cloud.com>
Cc: "Jan Beulich" <jbeulich@suse.com>, "Andrew Cooper"
 <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v2 01/18] x86/mm: purge unneeded
 destroy_perdomain_mapping()
From: "Alejandro Vallejo" <alejandro.vallejo@cloud.com>
To: "Roger Pau Monne" <roger.pau@citrix.com>,
 <xen-devel@lists.xenproject.org>
X-Mailer: aerc 0.18.2
References: <20250108142659.99490-1-roger.pau@citrix.com>
 <20250108142659.99490-2-roger.pau@citrix.com>
In-Reply-To: <20250108142659.99490-2-roger.pau@citrix.com>

Hi,

I noticed the same duplication while moving mapcache initialization code, b=
ut
didn't want to touch it while doing that. Good to see these two lines gone.

On Wed Jan 8, 2025 at 2:26 PM GMT, Roger Pau Monne wrote:
> The destroy_perdomain_mapping() call in the hvm_domain_initialise() fail =
path
> is useless.  destroy_perdomain_mapping() called with nr =3D=3D 0 is effec=
tively a
> no op, as there are not entries torn down.  Remove the call, as
> arch_domain_create() already calls free_perdomain_mappings() on failure.
>
> There's also a call to destroy_perdomain_mapping() in pv_domain_destroy()=
 which
> is also not needed.  arch_domain_destroy() will already unconditionally c=
all
> free_perdomain_mappings(), which does the same as destroy_perdomain_mappi=
ng(),
> plus additionally frees the page table structures.
>
> Signed-off-by: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
> ---
>  xen/arch/x86/hvm/hvm.c   | 1 -
>  xen/arch/x86/pv/domain.c | 3 ---
>  2 files changed, 4 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 922c9b3af64d..70fdddae583d 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -708,7 +708,6 @@ int hvm_domain_initialise(struct domain *d,
>      XFREE(d->arch.hvm.irq);
>   fail0:
>      hvm_destroy_cacheattr_region_list(d);
> -    destroy_perdomain_mapping(d, PERDOMAIN_VIRT_START, 0);
>   fail:
>      hvm_domain_relinquish_resources(d);
>      XFREE(d->arch.hvm.io_handler);
> diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
> index 7aef628f55be..bc7cd0c62f0e 100644
> --- a/xen/arch/x86/pv/domain.c
> +++ b/xen/arch/x86/pv/domain.c
> @@ -345,9 +345,6 @@ void pv_domain_destroy(struct domain *d)
>  {
>      pv_l1tf_domain_destroy(d);
> =20
> -    destroy_perdomain_mapping(d, GDT_LDT_VIRT_START,
> -                              GDT_LDT_MBYTES << (20 - PAGE_SHIFT));
> -
>      XFREE(d->arch.pv.cpuidmasks);
> =20
>      FREE_XENHEAP_PAGE(d->arch.pv.gdt_ldt_l1tab);

  Reviewed-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Wed Jan 08 16:27:14 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 16:27:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867667.1279230 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVYtR-0002xT-J3; Wed, 08 Jan 2025 16:26:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867667.1279230; Wed, 08 Jan 2025 16:26:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVYtR-0002xM-Fd; Wed, 08 Jan 2025 16:26:53 +0000
Received: by outflank-mailman (input) for mailman id 867667;
 Wed, 08 Jan 2025 16:26:52 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=HyFE=UA=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tVYtQ-0002xG-Ds
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 16:26:52 +0000
Received: from mail-ej1-x641.google.com (mail-ej1-x641.google.com
 [2a00:1450:4864:20::641])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5ccf4edf-cddd-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 17:26:50 +0100 (CET)
Received: by mail-ej1-x641.google.com with SMTP id
 a640c23a62f3a-aa679ad4265so198297566b.0
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 08:26:50 -0800 (PST)
Received: from localhost ([66.81.170.107]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0f06c7c2sm2538861566b.188.2025.01.08.08.26.46
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 08 Jan 2025 08:26:49 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5ccf4edf-cddd-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736353609; x=1736958409; darn=lists.xenproject.org;
        h=in-reply-to:references:subject:cc:to:from:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=9qVzn0z445RQS5gwGXwSCuVuf/09zUIYv/O1e8RORDQ=;
        b=B29XS5Wn4wk/nsZhifzoOUYH/07nMPICfWt5P1a2abH50heEWYs5B6DgfAE+PiJ3W0
         AsthmKvXhk7AOKGyI0qh08k104QwmQvU0vTMpswDWFMwaxcXd1bM8HjxxrbBlVMbXXK2
         zZUfgJADAig6VaR975mKTGOs5RsYWFBSsGlA0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736353609; x=1736958409;
        h=in-reply-to:references:subject:cc:to:from:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=9qVzn0z445RQS5gwGXwSCuVuf/09zUIYv/O1e8RORDQ=;
        b=nGDLAPJlcxzgEMkG5fIIyzpylHw7JvqM/io99IjqkNP48YbRlaRobhA9cRIQmwqv3K
         PUSTfEqTKm7JfRdkVs1I8gjQ3IWUNypPUeZLsXmTsUwdW9lYKBxgw0n61p4yWnF/vPob
         ydNHDR+mKBADVAwuANjtshT7Ntsqdw+wmoqPcPBOAnWa3Ch5paw21ZqxgVWrboagrWhV
         6wj6LWeR3SaLC+6Jw5frdlUgkhZiJSBOaoM8LplUQ9Y8+3Km60BDQKfI6Y4ZuYFuGBb1
         uiMvi+S/HqBaBZBcwcaBJmR1DhAVShuMxW9cSKjRLK6g1ooUsqFU2RGibwiN3O0xDaSy
         d1rg==
X-Forwarded-Encrypted: i=1; AJvYcCU1t4qa6D0YI7sJdESiV3UOa0ANpB+3h+jAaQvj4AjtJZKAFWw3/aQ2jdQXCnyOr4EFhVkVZBmfw1w=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyGl3So+BJE+e7kaBcHMjGtrJvuJGI1JF5TsFGEue5H2qpblGtF
	iwM3UjzPmgUZ+ebY1R/BfApnR72kaW532y7f/JrQ/wQEC4tK/7P7qdfCOHyoZbY=
X-Gm-Gg: ASbGncvI25tshA+KnR/u4m8ByhQDQzJgCfqHGzfE1wXjso/FgyqG93rxFt0jJpXXgWK
	bMhyzProsc4nQoKqyBCfYgMH06Jp7vPUjL8HysL47KhocMOXNuBsf8FMitLGQhe86IX5Uj86PkN
	Ox3NlZ9LQpJD3+2uv8bqo9Ic6TFOnmq/5qvVkzxeHt5lfLnLrWImUo2ss2EAsEPgPCHIdJhztJj
	O/p4ssTSJFneZHKvUndMpqEmvEzs8NMp7Kst0c2d/S9JkA1zRfetMkmCXZoomk=
X-Google-Smtp-Source: AGHT+IGeyzSl67XwMVKT2w8uqO00FNXE5fclltvJae3ciHJwU9FDedpvpzQ/ttHCVXzK+6GVdbXElA==
X-Received: by 2002:a17:907:6e8a:b0:aa6:50ee:d44c with SMTP id a640c23a62f3a-ab2a7a1164fmr282616566b.15.1736353609475;
        Wed, 08 Jan 2025 08:26:49 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Wed, 08 Jan 2025 16:26:46 +0000
Message-Id: <D6WTZES0WLY8.3QDZ5BCM7CEIX@cloud.com>
From: "Alejandro Vallejo" <alejandro.vallejo@cloud.com>
To: "Roger Pau Monne" <roger.pau@citrix.com>,
 <xen-devel@lists.xenproject.org>
Cc: "Jan Beulich" <jbeulich@suse.com>, "Andrew Cooper"
 <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v2 02/18] x86/domain: limit window where curr_vcpu !=
 current on context switch
X-Mailer: aerc 0.18.2
References: <20250108142659.99490-1-roger.pau@citrix.com>
 <20250108142659.99490-3-roger.pau@citrix.com>
In-Reply-To: <20250108142659.99490-3-roger.pau@citrix.com>

This is a net gain even without ASI. Having "current" hold the previous vCP=
U on
__context_switch() makes it _a lot_ easier to follow the lazy switch path.

On Wed Jan 8, 2025 at 2:26 PM GMT, Roger Pau Monne wrote:
> On x86 Xen will perform lazy context switches to the idle vCPU, where the
> previously running vCPU context is not overwritten, and only current is u=
pdated
> to point to the idle vCPU.  The state is then disjunct between current an=
d
> curr_vcpu: current points to the idle vCPU, while curr_vcpu points to the=
 vCPU
> whose context is loaded on the pCPU.
>
> While on that lazy context switched state, certain calls (like
> map_domain_page()) will trigger a full synchronization of the pCPU state =
by
> forcing a context switch.  Note however how calling any of such functions
> inside the context switch code itself is very likely to trigger an infini=
te
> recursion loop.
>
> Attempt to limit the window where curr_vcpu !=3D current in the context s=
witch
> code, as to prevent and infinite recursion loop around sync_local_execsta=
te().
>
> This is required for using map_domain_page() in the vCPU context switch c=
ode,
> otherwise using map_domain_page() in that context ends up in a recursive
> sync_local_execstate() loop:
>
> map_domain_page() -> sync_local_execstate() -> map_domain_page() -> ...

More generally, it's worth mentioning that we want to establish an invarian=
t
between a per-cpu variable (curr_vcpu) and the currently running page table=
s.
That way it can be used as discriminant to know which are the currently act=
ive
per-vCPU mappings.

That's essential for implementing FPU hiding as proposed here:

  https://lore.kernel.org/xen-devel/20241105143310.28301-1-alejandro.vallej=
o@cloud.com/

A shorter form of that should probably be mentioned also...

>
> Signed-off-by: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
> ---
> Changes since v1:
>  - New in this version.
> ---
>  xen/arch/x86/domain.c | 58 +++++++++++++++++++++++++++++++++++--------
>  xen/arch/x86/traps.c  |  2 --
>  2 files changed, 48 insertions(+), 12 deletions(-)
>
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index 78a13e6812c9..1f680bf176ee 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -1982,16 +1982,16 @@ static void load_default_gdt(unsigned int cpu)
>      per_cpu(full_gdt_loaded, cpu) =3D false;
>  }
> =20
> -static void __context_switch(void)
> +static void __context_switch(struct vcpu *n)
>  {
>      struct cpu_user_regs *stack_regs =3D guest_cpu_user_regs();
>      unsigned int          cpu =3D smp_processor_id();
>      struct vcpu          *p =3D per_cpu(curr_vcpu, cpu);
> -    struct vcpu          *n =3D current;
>      struct domain        *pd =3D p->domain, *nd =3D n->domain;
> =20
>      ASSERT(p !=3D n);
>      ASSERT(!vcpu_cpu_dirty(n));
> +    ASSERT(p =3D=3D current);
> =20
>      if ( !is_idle_domain(pd) )
>      {
> @@ -2036,6 +2036,18 @@ static void __context_switch(void)
> =20
>      write_ptbase(n);
> =20
> +    /*
> +     * It's relevant to set both current and curr_vcpu back-to-back, to =
avoid a
> +     * window where calls to mapcache_current_vcpu() during the context =
switch
> +     * could trigger a recursive loop.
> +     *
> +     * Do the current switch immediately after switching to the new gues=
t
> +     * page-tables, so that current is (almost) always in sync with the
> +     * currently loaded page-tables.
> +     */
> +    set_current(n);
> +    per_cpu(curr_vcpu, cpu) =3D n;

... here. So we're not tempted to move these 2 far off from write_ptbase().

> +
>  #ifdef CONFIG_PV
>      /* Prefetch the VMCB if we expect to use it later in the context swi=
tch */
>      if ( using_svm() && is_pv_64bit_domain(nd) && !is_idle_domain(nd) )
> @@ -2048,8 +2060,6 @@ static void __context_switch(void)
>      if ( pd !=3D nd )
>          cpumask_clear_cpu(cpu, pd->dirty_cpumask);
>      write_atomic(&p->dirty_cpu, VCPU_CPU_CLEAN);
> -
> -    per_cpu(curr_vcpu, cpu) =3D n;
>  }
> =20
>  void context_switch(struct vcpu *prev, struct vcpu *next)
> @@ -2081,16 +2091,36 @@ void context_switch(struct vcpu *prev, struct vcp=
u *next)
> =20
>      local_irq_disable();
> =20
> -    set_current(next);
> -
>      if ( (per_cpu(curr_vcpu, cpu) =3D=3D next) ||
>           (is_idle_domain(nextd) && cpu_online(cpu)) )
>      {
> +        /*
> +         * Lazy context switch to the idle vCPU, set current =3D=3D idle=
.  Full
> +         * context switch happens if/when sync_local_execstate() is call=
ed.
> +         */
> +        set_current(next);
>          local_irq_enable();
>      }
>      else
>      {
> -        __context_switch();
> +        /*
> +         * curr_vcpu will always point to the currently loaded vCPU cont=
ext, as

nit: s/will always point/always points/ ? It's an inconditional invariant,
after all.

> +         * it's not updated when doing a lazy switch to the idle vCPU.
> +         */
> +        struct vcpu *prev_ctx =3D per_cpu(curr_vcpu, cpu);
> +
> +        if ( prev_ctx !=3D current )
> +        {
> +            /*
> +             * Doing a full context switch to a non-idle vCPU from a laz=
y
> +             * context switched state.  Adjust current to point to the
> +             * currently loaded vCPU context.
> +             */
> +            ASSERT(current =3D=3D idle_vcpu[cpu]);
> +            ASSERT(!is_idle_vcpu(next));
> +            set_current(prev_ctx);
> +        }
> +        __context_switch(next);
> =20
>          /* Re-enable interrupts before restoring state which may fault. =
*/
>          local_irq_enable();
> @@ -2156,15 +2186,23 @@ int __sync_local_execstate(void)
>  {
>      unsigned long flags;
>      int switch_required;
> +    unsigned int cpu =3D smp_processor_id();
> +    struct vcpu *p;
> =20
>      local_irq_save(flags);
> =20
> -    switch_required =3D (this_cpu(curr_vcpu) !=3D current);
> +    p =3D per_cpu(curr_vcpu, cpu);
> +    switch_required =3D (p !=3D current);
> =20
>      if ( switch_required )
>      {
> -        ASSERT(current =3D=3D idle_vcpu[smp_processor_id()]);
> -        __context_switch();
> +        ASSERT(current =3D=3D idle_vcpu[cpu]);
> +        /*
> +         * Restore current to the previously running vCPU, __context_swi=
tch()
> +         * will update current together with curr_vcpu.
> +         */
> +        set_current(p);
> +        __context_switch(idle_vcpu[cpu]);
>      }
> =20
>      local_irq_restore(flags);
> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
> index 87b30ce4df2a..487b8c5a78c5 100644
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -2232,8 +2232,6 @@ void __init trap_init(void)
> =20
>  void activate_debugregs(const struct vcpu *curr)
>  {
> -    ASSERT(curr =3D=3D current);
> -
>      write_debugreg(0, curr->arch.dr[0]);
>      write_debugreg(1, curr->arch.dr[1]);
>      write_debugreg(2, curr->arch.dr[2]);

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Wed Jan 08 16:35:07 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 16:35:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867673.1279239 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVZ1J-00052w-8e; Wed, 08 Jan 2025 16:35:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867673.1279239; Wed, 08 Jan 2025 16:35:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVZ1J-00052p-5y; Wed, 08 Jan 2025 16:35:01 +0000
Received: by outflank-mailman (input) for mailman id 867673;
 Wed, 08 Jan 2025 16:34:59 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=HByp=UA=arm.com=Bertrand.Marquis@srs-se1.protection.inumbo.net>)
 id 1tVZ1H-00052j-He
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 16:34:59 +0000
Received: from EUR03-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur03on20615.outbound.protection.outlook.com
 [2a01:111:f403:260c::615])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7fc2d7e8-cdde-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 17:34:58 +0100 (CET)
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by PR3PR08MB5595.eurprd08.prod.outlook.com (2603:10a6:102:83::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8335.10; Wed, 8 Jan
 2025 16:34:56 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a%4]) with mapi id 15.20.8335.011; Wed, 8 Jan 2025
 16:34:55 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 7fc2d7e8-cdde-11ef-a0df-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=YkjjBpBC1G7HsqJqT5kndxojGhEz7YlRCHr2RUtpazN+r22VknYYpZXoWxwbn+We4f4zmkeuCyJ7BTdeQldM3dS+43kw/VlDkwORgg8QprChIF42iTAepL9805d6Y9gQ62dJrmtq+cyL98puxZMo7Cu0aakicFrjGbAg+WnMr8OVRiTAEb7a8CA+X8qmBe26POkMmwvely9MpwqxUqGRnXShU9GegdPzZO5XUTstQiOnCFP98+HZ0a1lh3kvxhw99UJUYKhE6FL9g0AZ0CG+vlXKHBv8ZX4L3nDgHQcpQBV3xV5ERNInc+gqjfCssbHSad25B8rxFnP7w3gqUbiEbg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=QPQ2RQYmDu4k3droeRPIAf4d8pcxOB0ub7sA/cfNF0c=;
 b=CeMxEnaSJGpBvHXZ2KOiOGRpwxcvXOsA5aEwBocf4+2Lop3rpUhKs2gwL5tMzq8oPLxWdSeKf6lKuaybLuPB3DC8Glsp2PSkXlcUOEeWR4/jYqxcOyZsktHHfkdW6z+am46KMj8jysqj1lmZx+y/NZQJx2/Yu/qgNLZDm7vh2QzBfErJr1P16r9adbd2mZrADIWY+9hwmaoZ5gQXw2w9ZcJwd+UvJ3bI9AVnXt3TY34e/TO6mZCJLFl8EEYEWDBmn37yXdAyWwVgPZExM9FOyBCsXH4y/jLmU1Z4ckeQcxkj3i2cdHQeM7RSshNvx2r+IOGp4QzK1eF57H0yDfigHg==
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=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=QPQ2RQYmDu4k3droeRPIAf4d8pcxOB0ub7sA/cfNF0c=;
 b=kW2hHGr4fxouxHT2rKspXIiDVsJEYwTxzRyUvSF+LxhNu4MD1bTQtG+YPA9AiFxLF48GKqIx2hRnk9MylNyxgWlNh/FC3ryqxkJkw+39Jb9nKVK5r1XWm6sGxJco490f9qhg9MxNevXwi0cYyw/jvNqiTCMK7HIxbR9LNT4Sx6g=
From: Bertrand Marquis <Bertrand.Marquis@arm.com>
To: Alejandro Vallejo <alejandro.vallejo@cloud.com>
CC: Stewart Hildebrand <stewart.hildebrand@amd.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Volodymyr
 Babchuk <volodymyr_babchuk@epam.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Michal Orzel
	<michal.orzel@amd.com>, Oleksii Kurochko <oleksii.kurochko@gmail.com>
Subject: Re: [PATCH] xen/arm: ffa: fix build with clang
Thread-Topic: [PATCH] xen/arm: ffa: fix build with clang
Thread-Index: AQHbYeFGu37kkF0Uuk6Sa5TIC8NMALMNBOYAgAANyoA=
Date: Wed, 8 Jan 2025 16:34:55 +0000
Message-ID: <8F541FF5-C4E7-4BFA-A0F5-86D2E9FCC736@arm.com>
References: <20250108152317.335441-1-stewart.hildebrand@amd.com>
 <D6WT3QSKXNG4.162UPSGMQ1ZIS@cloud.com>
In-Reply-To: <D6WT3QSKXNG4.162UPSGMQ1ZIS@cloud.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.200.121)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DB9PR08MB6588:EE_|PR3PR08MB5595:EE_
x-ms-office365-filtering-correlation-id: 887d6d98-b094-499d-8cb6-08dd30026298
x-checkrecipientrouted: true
nodisclaimer: true
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|366016|376014|1800799024|10070799003|38070700018;
x-microsoft-antispam-message-info:
 =?us-ascii?Q?NMOwV/8Z4ZkYe1qXZi4OeZaUytaa7h0z5DyuU7KcQlvav8IyCQA+2tVLRW9n?=
 =?us-ascii?Q?wnxKgPtjamlsq5tHtaZU1EyfEJTK/lo5eZKGWYcpaYlXejy1cBPlVAw4pCl7?=
 =?us-ascii?Q?Kp5CUAjCeE2Z+g9pG1Mqi4cVr6ogfBFpIYGkku5Ig9V5HcDhE1y0t4OjGHtY?=
 =?us-ascii?Q?vCpBESEOJFCJfd2h1YxxlnkrdlUk/ll8Pby9bPoCAlpIdqFHZyt5GbV8hzte?=
 =?us-ascii?Q?wSgxDWUb2z1LCZHjlwgCDxnlOcWMQomh8JRR7e0BC0J931VEpyMSFeF4DFct?=
 =?us-ascii?Q?wMSbtgOxxATVt2aJP7pfuZghVHwKlumPze1Kr3QGdbVaIZmO35pyc5KPDriC?=
 =?us-ascii?Q?Uxfm+GV1PnXhqfqR63cemF3h4m3dzR6wemD4/eytyxmp4pHergeVnTlUEr6K?=
 =?us-ascii?Q?hi7St9H7A/aZV2951jTwM9oCevu5/DG9q008nBZ0jaE8wapSCeCYb4rWXpsR?=
 =?us-ascii?Q?H/eeorXQCvdMea5b1A4KhtAuX8/gMeBEa5TlHooLqC74960p9qhJe5pjAtWj?=
 =?us-ascii?Q?bNE41Q75/+4yITM1t+JiHLytE4L6x4TVZirTvsgnALBFsKiLP1lvxQzalkkk?=
 =?us-ascii?Q?/SJjRRdYUtOiKv3S3rcbjvmpO/T0VfCt41kC+kz8qT7Xbzb3Gf2p/9clG2Mw?=
 =?us-ascii?Q?q7HYqRklA/YV9DERGAcjGZd/LtXfHlT/LsrIfBs14ljelFu+gmvGs3VVI7LN?=
 =?us-ascii?Q?WmJaPYDPofkXBl30oKHe1BEIzWcjtRd0cZsK51j9TC2E8qNTy82dYgP1t1B9?=
 =?us-ascii?Q?paIVGRyUDPZILkz1rjf6jSalzpEU2uNnlM/I7kM3Klbxq6pk+C1ORWAJSBKM?=
 =?us-ascii?Q?lgpOf1lo1/GUjDk9Tod4ESg06a/gL5ZHxprMC4+YghKYIUDlrHXcPFyHsWBd?=
 =?us-ascii?Q?+N+GxG2BUbglgBCCg1E6vekpEhwD4aq5i8iZJOHtzKKcdHSPqp3w5oa6hwVh?=
 =?us-ascii?Q?YIPNaN0SEakawDRQjBVws3J4KPH0E1Z7g40IqttjU9Qk6IhaoN3Sb5ALdMWf?=
 =?us-ascii?Q?MI9oNuGVavdLFGGfptt+Ko1A45xYii8BM/tSIx/0hlJ/ppUL2P4xpDCkRpPo?=
 =?us-ascii?Q?3XzLcfTtL35z6EydSRnpTueV1bTPFfe+LzD2M6kMINYIAyImS36UJkYWB3pl?=
 =?us-ascii?Q?ZZr988rkZ2OPbbeJZYJownajdeINWbkDZrY8+D+PQszJVXqbtExmH3qWmvbI?=
 =?us-ascii?Q?DtUsxDCyYNf4SRRjASQ0zePdK21viBfwNy9xDSlb/SLul0D34ifVVmre+s5g?=
 =?us-ascii?Q?dqbX5xiCunHf4xgEpq6OdmZCIl7SmjF/rLkMLGfwjsb5a5mpOG93+kClsENF?=
 =?us-ascii?Q?WadPrzbpMUBrmYGnrC88QJj7B0/7BsNFHqBpgdoT4MapioIqwOsXQNbAJoSt?=
 =?us-ascii?Q?xwVg097ZmnZsAkin5WxQMOlRLkP1h6Rhb67aAw+FDGfo7mGxxJxIPAeMYxih?=
 =?us-ascii?Q?3kScCmMN3Z+Rbnws79jhsAmMJATqTGk1?=
x-forefront-antispam-report:
 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:(13230040)(366016)(376014)(1800799024)(10070799003)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?5m/IgXYRUkLluDLWQX62+PFfdpaZtQkenRlrGBGAygR335YBh6A5Ey5rDoXQ?=
 =?us-ascii?Q?Q905iaGAVNaJxEOKykVGg9I+uosLsCRo4J5tf5/OCIPBno5Gc/YBJwv4DyII?=
 =?us-ascii?Q?2mZLo5LkpKGAOSSSJeB4POvhisTAeKnLP0Gd96VavwE80VG6UpwcI0KHwugH?=
 =?us-ascii?Q?U0g0ILX3JN/ePu/58Rc3OxiTFQnQRZNIAmlTsEJ3W67O3PtEHUl6WlzKlHEN?=
 =?us-ascii?Q?ff9cPQGykHK2HXYOi2bGr1fuuss+147ibHCAov5+6RvYfOKG6S7ZCMmVngM3?=
 =?us-ascii?Q?LrWhbmEteyXj5oJiVxUBv6w7APUhDIo8kZelwy/cEbzaShD1McLeUo6nt2YE?=
 =?us-ascii?Q?0ovI6GRtECOHR3Ihvr2OcVrMgX3v7CVmFJ9kEnt7KEX/UUFghhJxCm/sDhql?=
 =?us-ascii?Q?vnkae8JL9OP4AQXwjkFnvM8G16vq40OHntQ+y9gDABzDTz7V8GlDxyBiLq6X?=
 =?us-ascii?Q?MPZ9o/UmG2aDNV533QQu/2fTOSxx4Qpwd+L47wl2Af0PvcSR2y3Fhr1uspYv?=
 =?us-ascii?Q?OJGxIiAibtV8R5UafcgeI8XgPba8vBdj1ZuB8hN9L4lgMqDRQIyDu5U2oD7P?=
 =?us-ascii?Q?kM4HcLfX+d94Gmct4PzZL9AwO7yURZQRR21NRPNRhraKu48NGTyue9MtJ9fb?=
 =?us-ascii?Q?Ge4yCqIKE57oR2aNV+EEKEhkc8B5rArXTvACXQ0g+7nXjmMmANgNe9ZGExKR?=
 =?us-ascii?Q?DcbNRffyI7HY4uG7HZnKdp55df7gbTH5lcoAFvrs7dyVUvQAfInYuGB2RFYx?=
 =?us-ascii?Q?e/WdRbIDE4Pb4n7qapVKdY7+CcLmqiFfkQqLSQEF3T+Pw/mn4mz4h2Mhod3M?=
 =?us-ascii?Q?MWU5hDUhsnpaIIRycvL5zCi23ULtd8AZt073bJIhwWdIynrANabp192XaknP?=
 =?us-ascii?Q?AYGiaezKnbVGWlVyjEmkeYQ6kG8kPduvyfOoHxtexl8xEOojlv+6wdIQJsxT?=
 =?us-ascii?Q?aWGMTmwx97qJegQFV3vdBsKrS9G15bxSai4i0Dl919o5V/WkcatZFMbBfeqa?=
 =?us-ascii?Q?AtHbHzLeL//x6gc3x05BVUitNTH09A55c9mSZtRiSZkqdNqJQIqCanEzljAE?=
 =?us-ascii?Q?+IMDU5RPVZh+2H4Y4lrRbNMJGYNVm9nQkp3EdEKeuI4E6bjZQW8uPE+WyoUL?=
 =?us-ascii?Q?pYBHGQLdNNs5AnR0O4IYfb7fmHGu/X+AvPM3vtOm2+mnbYZR+6SRMZI9uxTJ?=
 =?us-ascii?Q?KIbWl0/FOfjPcrBwWViM8rxbFJLNvlTwhKttAqqP9K2jU5clB5QGd56q/Ern?=
 =?us-ascii?Q?Vk+Jz9mDPwvVoCa1H17u0SfwB2bMSoL5/ZPwfocxDKRoLxOiFNKSr4ADtkKF?=
 =?us-ascii?Q?7ZLOt4vB+qU6UDmjgdjhCELWC4rEC0ZHV45Sz0W4CcsT9CynelKJsWFBxpg0?=
 =?us-ascii?Q?ZJKczzwmC68zSRKkurxvQsH9ieQE4PmpY+O98p7XRhxO9GgZ+1cr4iAp/DjU?=
 =?us-ascii?Q?uGoETQlmXVhwfCuL8p5QDofT5DP5ss2AHLcQ9i4X9ThKpiiurhYgqcX+ej1Y?=
 =?us-ascii?Q?b4OpcoWIRLIKSv81QN9uJp/qsWHo8yHB6xJeV7BoF2/ucgD0hTRdPkDtozpO?=
 =?us-ascii?Q?jyBROifAGlpHVqbtDBXLdpP/Xd9h0n91m1Vgrl7YDdE6H7NaiLnTs7Rl27zm?=
 =?us-ascii?Q?oq1ukeWnmdXIqog1ifR1sZJstnql0xSQWQrEJ/p93+ZR5Tn7MKeSEileHOeH?=
 =?us-ascii?Q?Loxuww=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <DD7A3A6CB897EB4485D05440BF91B8BD@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DB9PR08MB6588.eurprd08.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 887d6d98-b094-499d-8cb6-08dd30026298
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2025 16:34:55.8535
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: tYYZ0Higms88CdTSrjkaeciuZYMRrWGDCWfcDVeqUSwUWnGS6615Dd9ky2WVat40hgVFGwB6j6wUPSTz9DmbFM2vmWvHd4Z2Cp82UcnF5as=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3PR08MB5595

Hi,

> On 8 Jan 2025, at 16:45, Alejandro Vallejo <alejandro.vallejo@cloud.com> =
wrote:
>=20
> Hi,
>=20
> On Wed Jan 8, 2025 at 3:23 PM GMT, Stewart Hildebrand wrote:
>> Clang 16 reports:
>>=20
>> In file included from arch/arm/tee/ffa.c:72:
>> arch/arm/tee/ffa_private.h:329:17: error: 'used' attribute ignored on a =
non-definition declaration [-Werror,-Wignored-attributes]
>> extern uint32_t __ro_after_init ffa_fw_version;
>>                ^
>>=20
>> Remove the attribute from the header to resolve this. The attribute in
>> ffa.c is the one the matters anyway.
>>=20
>> Fixes: 2f9f240a5e87 ("xen/arm: ffa: Fine granular call support")
>> Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
>> ---
>> It appears the variable ffa_fw_version is only used in ffa.c. Was there
>> any rationale for exporting the symbol in 2f9f240a5e87 ("xen/arm: ffa:
>> Fine granular call support")? If not, perhaps we ought to make it static
>> again and remove the declaration in the header.
>=20
> The only reason I can think of is wanting to have it in the symbol table =
of the
> ELF file for some reason (livepatching?). But that's far fetched at best.
>=20
>> ---
>> xen/arch/arm/tee/ffa_private.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>=20
>> diff --git a/xen/arch/arm/tee/ffa_private.h b/xen/arch/arm/tee/ffa_priva=
te.h
>> index d441c0ca5598..05368d5a88d3 100644
>> --- a/xen/arch/arm/tee/ffa_private.h
>> +++ b/xen/arch/arm/tee/ffa_private.h
>> @@ -326,7 +326,7 @@ extern void *ffa_rx;
>> extern void *ffa_tx;
>> extern spinlock_t ffa_rx_buffer_lock;
>> extern spinlock_t ffa_tx_buffer_lock;
>> -extern uint32_t __ro_after_init ffa_fw_version;
>> +extern uint32_t ffa_fw_version;
>> extern DECLARE_BITMAP(ffa_fw_abi_supported, FFA_ABI_BITMAP_SIZE);
>>=20
>> bool ffa_shm_domain_destroy(struct domain *d);
>>=20
>> base-commit: 70f5a875becc9444a959830b10a361982c31a366
>=20
> IMO, it makes sense to make it static and remove this line altogether as =
you
> suggest. If it needs to be exported later on it can be adjusted as needed=
.
>=20

Yes in fact it was made global as there was a use case at some point but th=
is is not
the case anymore so in fact we can completely remove this from the header a=
nd make
it static for now.

@stewart: are you happy to push a patch doing this instead ?

Cheers
Bertrand

> Cheers,
> Alejandro




From xen-devel-bounces@lists.xenproject.org Wed Jan 08 16:37:26 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 16:37:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867681.1279249 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVZ3c-0005dd-Oe; Wed, 08 Jan 2025 16:37:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867681.1279249; Wed, 08 Jan 2025 16:37:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVZ3c-0005dW-LZ; Wed, 08 Jan 2025 16:37:24 +0000
Received: by outflank-mailman (input) for mailman id 867681;
 Wed, 08 Jan 2025 16:37:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=XghG=UA=amd.com=Stewart.Hildebrand@srs-se1.protection.inumbo.net>)
 id 1tVZ3b-0005dP-F6
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 16:37:23 +0000
Received: from NAM02-SN1-obe.outbound.protection.outlook.com
 (mail-sn1nam02on20604.outbound.protection.outlook.com
 [2a01:111:f403:2406::604])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d4170185-cdde-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 17:37:20 +0100 (CET)
Received: from BN9PR03CA0042.namprd03.prod.outlook.com (2603:10b6:408:fb::17)
 by PH7PR12MB6636.namprd12.prod.outlook.com (2603:10b6:510:212::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8335.11; Wed, 8 Jan
 2025 16:37:17 +0000
Received: from BN1PEPF00004683.namprd03.prod.outlook.com
 (2603:10b6:408:fb:cafe::65) by BN9PR03CA0042.outlook.office365.com
 (2603:10b6:408:fb::17) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8335.11 via Frontend Transport; Wed,
 8 Jan 2025 16:37:17 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN1PEPF00004683.mail.protection.outlook.com (10.167.243.89) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8335.7 via Frontend Transport; Wed, 8 Jan 2025 16:37:17 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 8 Jan
 2025 10:37:16 -0600
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB06.amd.com
 (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 8 Jan
 2025 10:37:16 -0600
Received: from [172.23.250.255] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Wed, 8 Jan 2025 10:37:14 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: d4170185-cdde-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=DPGrycQ72unRdRqrnMPHMr1LiqZoMupcBqhgaQzYP8rIo4gTHlIYtg4epI1mRrauQL63aMPlYth4gOLDx4AnC2Lb/jzJ5xEZdezzbdRsdZzxZoxifnZRGD0HBBn3NKv8xwDyu4NqIFKZnKfwSLFglauAgUZ8rl8NcV30zb9sb15kDmwpaJWDwAuLf9vOkPD5HSbiUlE409BqDuPh5Cq8NP75NqoExERtaj+xWLXRCcEqT1J7/KCuKxMTJs7FyNRYIWk9q8/tqN1KMdRbRIB8E/i1CYcR2fpmfA1bG8cVfc7tPRkd9bokTOzePbnrzORQPCrtiK+zSIlob5hKTmMq+Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=BOV7vJX6x1hozKkg/dOu45A7NJuT7TfIV8E/f3DEJJo=;
 b=QaWQGIYoNV0zi3D29TuJF2hZGMRcvC6dDsJBIgFxiPTn82DeChJfYRr1O9YwTSbLmsxPBx/BssERSt7BCyJ4mRjoFEBJYkYiDlunwudC1B0KqpjgxITK29I2UlzBJnJ2JHa7GN0Tie2oARy1ZBhSQmgXr96zd3ZuXR+FeDUOuuIhvGgAhMWFhxU8BAIQH8FacBJJRXpqS5+OfbLchH5rlCgG6AHjmZjnvMd7V1oic6sZoT5OriNI2dvuKY+oKptQZ3sav3OVWHPHlpx0JgLV3qX39R2KmR7uHN0ELjVNrBIqhSJ2Gi8cbXr9wo/UKCE8HuIpNQZ+0PsfdbQrNKHnQg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=BOV7vJX6x1hozKkg/dOu45A7NJuT7TfIV8E/f3DEJJo=;
 b=nOM0hOMG3yzUtan4f6Qboimwo0egFs33AZKy22vj3K4bhnpvILKqwYAd8DClKAUV2qkgU/+EUO+mWQ/1VEvuz53djSTJFvm338tV0qCeu50DFN4HfVaTxqaGeUUggr6S5BIDKEf/+vMcGPqCVfIdJaLnmNaDji3xo83CTcRhBzM=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <b762d978-3aab-4656-883e-f812ceb28a4d@amd.com>
Date: Wed, 8 Jan 2025 11:37:13 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/arm: ffa: fix build with clang
To: Bertrand Marquis <Bertrand.Marquis@arm.com>, Alejandro Vallejo
	<alejandro.vallejo@cloud.com>
CC: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Volodymyr Babchuk <volodymyr_babchuk@epam.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Michal Orzel
	<michal.orzel@amd.com>, Oleksii Kurochko <oleksii.kurochko@gmail.com>
References: <20250108152317.335441-1-stewart.hildebrand@amd.com>
 <D6WT3QSKXNG4.162UPSGMQ1ZIS@cloud.com>
 <8F541FF5-C4E7-4BFA-A0F5-86D2E9FCC736@arm.com>
Content-Language: en-US
From: Stewart Hildebrand <stewart.hildebrand@amd.com>
In-Reply-To: <8F541FF5-C4E7-4BFA-A0F5-86D2E9FCC736@arm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN1PEPF00004683:EE_|PH7PR12MB6636:EE_
X-MS-Office365-Filtering-Correlation-Id: aca86b68-bef9-4fd6-25dc-08dd3002b6c6
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|36860700013|376014|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?NGxXKzNZMmtTQzhyRU0ra2VNNGNrS0ltc3NkS0FnLzFnNW5ycEhUUnBIbXJ6?=
 =?utf-8?B?djZKSldQUGZLOVlLUU5zc3ZMdVRkdk9uVEJxT2w5VkRuZ3lXUlNTYm5OWjl4?=
 =?utf-8?B?SHVaYUJBL05HM1NaK3p2ZXFmVStwN2lLdXN3bGZSaUtETUIrTFJYQ0ZINlFR?=
 =?utf-8?B?NEwxdzRLZkdwMjJGWThGMG5HVHNwd1FQck94bVpKcE9CY0pnaWlLcEtlTVh2?=
 =?utf-8?B?c1Z5WTU2WW9lTzAzQmNvZk5vSkk2SHhQYVBCYnNOdlRDRkJTc0ttUFhjTDJP?=
 =?utf-8?B?UzZmTm03Um1VWVQ1Q0RpOE1CTzRlbUJONnJlWTkyd2t6SHpKbmNoVWF5Zlpu?=
 =?utf-8?B?eWVWanNqbUdtMnZTVm5lTVVnZlIySGFpRGpnL3BXTTBhbldLbmRuS0R5QzdB?=
 =?utf-8?B?VjlueTFIQ01oZlJJcnNpM1VaODczSG5lMTg1bzdnTWx3YUFWT09RNzlvZ1k3?=
 =?utf-8?B?dEs1bUVESUFHcDRTdkplTVhTWWpSa0h5dlE2YktNV2lHd2FyYmM0MUc3M2Zx?=
 =?utf-8?B?eWU1Mmsrb1JXTGFlYk50SjVRZ2xNODlTT3ltMFJPRlhueGlkU0hiemJtTnJy?=
 =?utf-8?B?cFZ4aEE0WFJSTVh2Y3VrZ0cwYXhzVWdoNWlrcUtZMllXNXRGUFJJMmphd1Mv?=
 =?utf-8?B?SmZvakkrVGZUSzF0QkxFL1FzRW1JRFVvTmRpaUtta0lZUWF6R0pjMjRKWlJZ?=
 =?utf-8?B?d3JzYVFsM25lRjdNSkNyYlk4c0dQV2xZNTBHT01NWlpTUHZ3cVdSSUszemFq?=
 =?utf-8?B?K016WGJqOEx1cTRaZnN4OWEranF4ZHFCazVCZFQvU3pQTlhvaU9hYjEvTUZY?=
 =?utf-8?B?dStkT1gvV0h0NklaZ0NDSmVObTNxeEhOVytZVm16cFhVSWMvdllnaGQ2dUZT?=
 =?utf-8?B?ekhlMVVtZzlrR3JUSzU5aFVhY1grVlZQSFIyekZJK1FPNllIMVFPVjA0eUs2?=
 =?utf-8?B?VUZZZ0dSWmdMQVYwQnpPWU9pS3hHR2ZwTXUyUmtCd3EyclVIQXVkRDFiTkdG?=
 =?utf-8?B?NGNGQksxMVg3K2VTR29ZTEcydm5VTjJqL1RESGVublJDR2I3ekJJSEV3MUNF?=
 =?utf-8?B?dmNoaEl0bnBFVVI1TS9kTlh1NExxMy82WTdMMllRRjVUVy82TVl4Sk5jWnBs?=
 =?utf-8?B?TnRVWjZ1NnRjVVdsRC9KV3d0eWJobVJZMlNDKzNra1ZlTHNjNFFoVGR6NFFt?=
 =?utf-8?B?QXZQNHA5UXVqMkVRWHVVMkl6M0xGVE1TY2hyWWwzNUdXZWlsc1AwMXlEQ0N0?=
 =?utf-8?B?K1Q5aHRKKzJ1Qjh0WFl0V211aHhOYzBxdGxDVk5iTlNHVDBKZDJUOXQzbTdK?=
 =?utf-8?B?MDZlNmZSckVJWWNnTythTGQzVnZYSXdMNWxsaWhiNTByT3VCekljOTFpbS9J?=
 =?utf-8?B?U1pLYWN6Mkh3bURxVWs4WTdpZ01JQnp4REhKWERQSkM4aHhrc2xXWWgxb1RF?=
 =?utf-8?B?ZlhjaDhaZ3BXRHM3NUttN0JoS1hXaGRWUk9RSGdhRkNtdm1mN2Mwek01bTBJ?=
 =?utf-8?B?YWdEVnBMRTZSam5WdHlSMlNia1ZFUm9TMjBQSXB1SVJWV2dLU0Nxd1V6T1Iy?=
 =?utf-8?B?QW9IZWsrL1ZTTHgzZ0xLQVVySVQ1TzVCNDhNY3ZLN1hDYkxodVE5YzVWOW1v?=
 =?utf-8?B?ak1Cd0Vycm1zN2RRVGFxWG1lMXJZelNwdGZhS1A3L2VFYk9qY1pNQlNnNFBh?=
 =?utf-8?B?YmFqbEozZnJNVnBPalVnOW1sbzFmTTNGZzJHUlc3OEVwSW5UV3VwQS9vTC9t?=
 =?utf-8?B?OFJxaWVTS0w4VU9BRUs4QWlyMHhjbW92N3hkWFlCMm81WGREdmJnQ042VzZJ?=
 =?utf-8?B?QnVKMUV6Y2ViU0ltVTZOdXdDbklmZ3gxRFFWaU9wdWF0VXRiZzh4RWVLOWZs?=
 =?utf-8?B?b1JhRlVCd0IxYWdlVmd1bGR1Yk9NMU44S1ZkbjUxYXpTV0VXckY5OWY1UGxo?=
 =?utf-8?B?cllwWTlkYW1mT01iemVQMENKOWhFS25ndlRrMVhYU0ZHRHNzdnRjYlYzZ0tO?=
 =?utf-8?Q?PO0gWBBmQUBGxQ7RVyQOdD1Lz8O/u8=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(376014)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jan 2025 16:37:17.0360
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: aca86b68-bef9-4fd6-25dc-08dd3002b6c6
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN1PEPF00004683.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB6636

On 1/8/25 11:34, Bertrand Marquis wrote:
> Hi,
> 
>> On 8 Jan 2025, at 16:45, Alejandro Vallejo <alejandro.vallejo@cloud.com> wrote:
>>
>> Hi,
>>
>> On Wed Jan 8, 2025 at 3:23 PM GMT, Stewart Hildebrand wrote:
>>> Clang 16 reports:
>>>
>>> In file included from arch/arm/tee/ffa.c:72:
>>> arch/arm/tee/ffa_private.h:329:17: error: 'used' attribute ignored on a non-definition declaration [-Werror,-Wignored-attributes]
>>> extern uint32_t __ro_after_init ffa_fw_version;
>>>                ^
>>>
>>> Remove the attribute from the header to resolve this. The attribute in
>>> ffa.c is the one the matters anyway.
>>>
>>> Fixes: 2f9f240a5e87 ("xen/arm: ffa: Fine granular call support")
>>> Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
>>> ---
>>> It appears the variable ffa_fw_version is only used in ffa.c. Was there
>>> any rationale for exporting the symbol in 2f9f240a5e87 ("xen/arm: ffa:
>>> Fine granular call support")? If not, perhaps we ought to make it static
>>> again and remove the declaration in the header.
>>
>> The only reason I can think of is wanting to have it in the symbol table of the
>> ELF file for some reason (livepatching?). But that's far fetched at best.
>>
>>> ---
>>> xen/arch/arm/tee/ffa_private.h | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/xen/arch/arm/tee/ffa_private.h b/xen/arch/arm/tee/ffa_private.h
>>> index d441c0ca5598..05368d5a88d3 100644
>>> --- a/xen/arch/arm/tee/ffa_private.h
>>> +++ b/xen/arch/arm/tee/ffa_private.h
>>> @@ -326,7 +326,7 @@ extern void *ffa_rx;
>>> extern void *ffa_tx;
>>> extern spinlock_t ffa_rx_buffer_lock;
>>> extern spinlock_t ffa_tx_buffer_lock;
>>> -extern uint32_t __ro_after_init ffa_fw_version;
>>> +extern uint32_t ffa_fw_version;
>>> extern DECLARE_BITMAP(ffa_fw_abi_supported, FFA_ABI_BITMAP_SIZE);
>>>
>>> bool ffa_shm_domain_destroy(struct domain *d);
>>>
>>> base-commit: 70f5a875becc9444a959830b10a361982c31a366
>>
>> IMO, it makes sense to make it static and remove this line altogether as you
>> suggest. If it needs to be exported later on it can be adjusted as needed.
>>
> 
> Yes in fact it was made global as there was a use case at some point but this is not
> the case anymore so in fact we can completely remove this from the header and make
> it static for now.
> 
> @stewart: are you happy to push a patch doing this instead ?

Yes


From xen-devel-bounces@lists.xenproject.org Wed Jan 08 16:41:12 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 16:41:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867690.1279260 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVZ7E-0007PE-93; Wed, 08 Jan 2025 16:41:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867690.1279260; Wed, 08 Jan 2025 16:41:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVZ7E-0007P7-5Q; Wed, 08 Jan 2025 16:41:08 +0000
Received: by outflank-mailman (input) for mailman id 867690;
 Wed, 08 Jan 2025 16:41:06 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=XghG=UA=amd.com=Stewart.Hildebrand@srs-se1.protection.inumbo.net>)
 id 1tVZ7C-0007P1-QD
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 16:41:06 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20613.outbound.protection.outlook.com
 [2a01:111:f403:2009::613])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5961e3be-cddf-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 17:41:04 +0100 (CET)
Received: from BN8PR03CA0021.namprd03.prod.outlook.com (2603:10b6:408:94::34)
 by DS0PR12MB6415.namprd12.prod.outlook.com (2603:10b6:8:cc::14) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8335.10; Wed, 8 Jan
 2025 16:40:59 +0000
Received: from BL02EPF0002992E.namprd02.prod.outlook.com
 (2603:10b6:408:94:cafe::60) by BN8PR03CA0021.outlook.office365.com
 (2603:10b6:408:94::34) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8335.10 via Frontend Transport; Wed,
 8 Jan 2025 16:40:59 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BL02EPF0002992E.mail.protection.outlook.com (10.167.249.59) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8335.7 via Frontend Transport; Wed, 8 Jan 2025 16:40:58 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 8 Jan
 2025 10:40:58 -0600
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB06.amd.com
 (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 8 Jan
 2025 10:40:57 -0600
Received: from ubuntu.mshome.net (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Wed, 8 Jan 2025 10:40:56 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5961e3be-cddf-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=wXrOTdmLQc21PbKADIEOxf7iPEvttXhKbebtqzy5df4ue6TrQSpSLLOHcK06+rKXT7SDFQ4DVQkAlPu0e7Ycvag+cprbSaYNZhwTJ2IbhTfK0B7a+LSOcVsnty6KVjuW7isHf/BEZ14uQzYXncyBs3+FswdeI81Ja/w+7pQyDLeGw+TPmVI8DwuuVexCh8SvrI4MtWNt0eyIuss9y92h0CGRuYkNqm1RZ0490bPW5gJ4piC5dGmqstDq7KkHuNOBBYSu4PYfbDdMedMe1KoxPuyF7LMp0/iJrMAwfB/vIcY8iKfgNoMmliAufuYer1OsaagSnYjUqkVEecqSdrhKTQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=1J462nUP7/zF0Y8aeTwKy9th83yPn5qJrCNSuQK7Kv8=;
 b=wfPN4x5FvzBKi4mY22uYn2pi4+mqDT1oudNSPrE1mEnH5iHgHO3lHTFd8HGMvmC9yO6Tjr/7odOZ3aQmb7l0MjLz028q4u6NVjRwj2Ow/C203kgvR5F7KNpOFtemH7vgIxFsx3gVpGzLNdiHejPrB6vDxZC9Oi4ymt+5tNVv2Fmc0Wc4T2am8MxzRIXTI+BMFIDYpfquxRa7U66b4m5tMmE35I5DiBFeYDLq/kxZGgOg42v3NEt8u7QUbY3C3aHf0Lzmqykhdgz/r7KpApxKYy5jK1SfPpmZk+tbPKc75yzIwbf+kwZia4iJo6OAdalpf99NMgNczmS9/1iqayxbIw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=1J462nUP7/zF0Y8aeTwKy9th83yPn5qJrCNSuQK7Kv8=;
 b=Dtm1nqNTDqOM6rwPixmlRDIEznZKIGgPEGigXEz/pC6TEf+yxc7wbCrnIYJ8xK2BrDZ1bp/NtdRTtt7yStz1cHFVX6djsJCT/Oa6RNXZTOr9JWTcokO0sFQO+TgkWIidkeocfBlZNeCNQm+qSdkpqL6zuIdj9ZAVepHaBtzRTcI=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
From: Stewart Hildebrand <stewart.hildebrand@amd.com>
To: <xen-devel@lists.xenproject.org>
CC: Stewart Hildebrand <stewart.hildebrand@amd.com>, Volodymyr Babchuk
	<volodymyr_babchuk@epam.com>, Bertrand Marquis <bertrand.marquis@arm.com>,
	Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
	Michal Orzel <michal.orzel@amd.com>, Oleksii Kurochko
	<oleksii.kurochko@gmail.com>
Subject: [PATCH v2] xen/arm: ffa: fix build with clang
Date: Wed, 8 Jan 2025 11:40:53 -0500
Message-ID: <20250108164054.338799-1-stewart.hildebrand@amd.com>
X-Mailer: git-send-email 2.47.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL02EPF0002992E:EE_|DS0PR12MB6415:EE_
X-MS-Office365-Filtering-Correlation-Id: 8e0a30ba-380f-4324-2765-08dd30033aeb
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|82310400026|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?BzIFQ9cWPK9D8JQfujZ3Ryp/5GqsMi05HUQI6rOx8uYAaTNB7JllLJYZ4xrv?=
 =?us-ascii?Q?N+2KoGGdhbN3ML4hZr2aR6sjxxzINgBs0IO7CmYMVdViWXVOCwXeqZNH5E+N?=
 =?us-ascii?Q?8WtuwBMjZ3NImU2Yw+LvSFf8sSTM5qlpvDuKM8IQBT3zT7FQaJXHaPxg5Pc4?=
 =?us-ascii?Q?WlJrbfBe0C4UZbFbuqsScZV4xmK64YPozaG23XOpmQ9WbB74jfsdz/Z2o7oc?=
 =?us-ascii?Q?KI77rV34DQySsSrqZpwm7ds75cyjXWIbTKYzGlAstNcJGw02VLzUPYrYdUS0?=
 =?us-ascii?Q?K/EDzBuJRYoQ60UrQHJSNfu+cnwToexvJ8n9yx0qzP2CGXIZP/w6Ow26Kadg?=
 =?us-ascii?Q?G7RK0eZk/ZbjY/4CamQebpnpE6YbOv1FE+Snp33NbIzKHHGnyAqrRrWa4CjM?=
 =?us-ascii?Q?ZhhRHjeSArevKwBXgIlkcHpd3OAOV4sUtv3He0PuCe312Gz4AA0w2uRhk8mf?=
 =?us-ascii?Q?NDHyQXMMew/Z+tHA2jCuxMFaFG+C/z3/uB5+JF3WZkZON8siB23KkkTWPPWj?=
 =?us-ascii?Q?rV7aq6MM0uXK2DUuE6fGWSpMBFPdd7Pu77X5S/w7TH6EU/sZwQOHUrAB0Odh?=
 =?us-ascii?Q?PVmAgHWFSGavSaG2t0jiAbIQfBvjVKny6YbNWn476SvY4SQupfElLrgwTqjr?=
 =?us-ascii?Q?bElY0U4gvXgMvZdw7VFRlkNNO8LT2liScabA6lVQD9hX6inQ/l9D4z5wPkwc?=
 =?us-ascii?Q?g0nW6Mt2yNomdNNUvHGt66mxFRjC5GW74gGZK3bgX7rc0pOivPrApgY3efBj?=
 =?us-ascii?Q?pyRHj6eYpTUxXS71Dyu6PNB8pPr8BB+pIPD8rIyxFo3APdwf//6SeGDOXPRX?=
 =?us-ascii?Q?alpLoklvDdKLYFRJnJyeIw8+I2gga6wS8zw+ox0pFe4Ft//hHWBOjZDKKJGQ?=
 =?us-ascii?Q?QNrgUCrAtQAEc5RZ7cAJgyq1uEgVdUzl8gEHsukjZD83RZD9544qleVuRBGq?=
 =?us-ascii?Q?67I8wPksbfPpQFHGkhry5G7PcokMYe/hQ5J5sLdVX1mmXgXcNDX34D6sDISl?=
 =?us-ascii?Q?KCi5IAmeyQMKhv6llulyvqdy6xR8nl3iUuznnFkWvPXfQgsMMo6QLkROwvN7?=
 =?us-ascii?Q?3DTx+3bqLIpvFrb3rIzydEkYOnIuWWekx6jkr0ztL4Q8r5TbWvxV6gUBxi++?=
 =?us-ascii?Q?vLtPRmPG3fTLKcatnFWJTlR8oqYp1ARfKBLQ6L5y/DXx6gClYKqgcdYf1neJ?=
 =?us-ascii?Q?1/olsgFXvY4tsvOKMKsfhfPRdX31IKk56TPCwwIHP3BXgGJHo7pqj2M4Hr4D?=
 =?us-ascii?Q?O7/Qk8yyQAqeRUtIntAGXqUA1Z+OY4DAwKNL25m4edHXl269n+7HVoFZjxUD?=
 =?us-ascii?Q?HvUHYtuIpUeS0zz4Y+BmEbjWnUXrrwAwAKPS+ejfWMx9m6ESrBWs+SS0cfgb?=
 =?us-ascii?Q?WwMzTZCOTnzk84aAMtuLC7oK0Ffm01xklgN3cZN/Fa42hzkTxYsdSUTmy+1Z?=
 =?us-ascii?Q?wemw9e37FXzxtmHThwgind0GYych9EXHQzrBlz1VbJrNOVeLEM64UcqZd298?=
 =?us-ascii?Q?BwPytI0n+sm/niM=3D?=
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:(13230040)(1800799024)(376014)(82310400026)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jan 2025 16:40:58.7221
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 8e0a30ba-380f-4324-2765-08dd30033aeb
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:
	BL02EPF0002992E.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB6415

Clang 16 reports:

In file included from arch/arm/tee/ffa.c:72:
arch/arm/tee/ffa_private.h:329:17: error: 'used' attribute ignored on a non-definition declaration [-Werror,-Wignored-attributes]
extern uint32_t __ro_after_init ffa_fw_version;
                ^

The variable ffa_fw_version is only used in ffa.c. Remove the
declaration in the header and make the definition in ffa.c static.

Fixes: 2f9f240a5e87 ("xen/arm: ffa: Fine granular call support")
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
---
v1->v2:
* remove declaration and make definition static
---
 xen/arch/arm/tee/ffa.c         | 2 +-
 xen/arch/arm/tee/ffa_private.h | 1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
index 87775ed88ffd..3bbdd7168a6b 100644
--- a/xen/arch/arm/tee/ffa.c
+++ b/xen/arch/arm/tee/ffa.c
@@ -72,7 +72,7 @@
 #include "ffa_private.h"
 
 /* Negotiated FF-A version to use with the SPMC, 0 if not there or supported */
-uint32_t __ro_after_init ffa_fw_version;
+static uint32_t __ro_after_init ffa_fw_version;
 
 /* Features supported by the SPMC or secure world when present */
 DECLARE_BITMAP(ffa_fw_abi_supported, FFA_ABI_BITMAP_SIZE);
diff --git a/xen/arch/arm/tee/ffa_private.h b/xen/arch/arm/tee/ffa_private.h
index d441c0ca5598..c4cd65538908 100644
--- a/xen/arch/arm/tee/ffa_private.h
+++ b/xen/arch/arm/tee/ffa_private.h
@@ -326,7 +326,6 @@ extern void *ffa_rx;
 extern void *ffa_tx;
 extern spinlock_t ffa_rx_buffer_lock;
 extern spinlock_t ffa_tx_buffer_lock;
-extern uint32_t __ro_after_init ffa_fw_version;
 extern DECLARE_BITMAP(ffa_fw_abi_supported, FFA_ABI_BITMAP_SIZE);
 
 bool ffa_shm_domain_destroy(struct domain *d);

base-commit: 70f5a875becc9444a959830b10a361982c31a366
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 17:03:27 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 17:03:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867701.1279269 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVZSj-0002lX-0A; Wed, 08 Jan 2025 17:03:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867701.1279269; Wed, 08 Jan 2025 17:03:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVZSi-0002lQ-TD; Wed, 08 Jan 2025 17:03:20 +0000
Received: by outflank-mailman (input) for mailman id 867701;
 Wed, 08 Jan 2025 17:03:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=1vVY=UA=amd.com=ayan.kumar.halder@srs-se1.protection.inumbo.net>)
 id 1tVZSh-0002lK-96
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 17:03:19 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on2061e.outbound.protection.outlook.com
 [2a01:111:f403:200a::61e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7313a695-cde2-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 18:03:16 +0100 (CET)
Received: from BY1P220CA0013.NAMP220.PROD.OUTLOOK.COM (2603:10b6:a03:59d::17)
 by SJ2PR12MB8739.namprd12.prod.outlook.com (2603:10b6:a03:549::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8314.19; Wed, 8 Jan
 2025 17:03:10 +0000
Received: from SA2PEPF000015CA.namprd03.prod.outlook.com
 (2603:10b6:a03:59d:cafe::90) by BY1P220CA0013.outlook.office365.com
 (2603:10b6:a03:59d::17) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8335.11 via Frontend Transport; Wed,
 8 Jan 2025 17:03:10 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SA2PEPF000015CA.mail.protection.outlook.com (10.167.241.200) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8335.7 via Frontend Transport; Wed, 8 Jan 2025 17:03:08 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 8 Jan
 2025 11:03:07 -0600
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB06.amd.com
 (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 8 Jan
 2025 11:03:07 -0600
Received: from xcbayankuma40.xilinx.com (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via
 Frontend Transport; Wed, 8 Jan 2025 11:03:06 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 7313a695-cde2-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=LUk0brJ/8o1eLMYJGCIumrg4YX1CbAvquaFDTne0ge6ihQsROT9NmPPmFAgmgT4iR+o/YQaypO3/mHOy6DXAo5TfvcaOt2bfHI2RYgmeKH/O+f5nWX1b1Y2+mItnF4ipUZEIbnp2D5/LOVGvAuuaNTOFWaCXN6ECQZK/rYfOVsAOvn3G65jhC+Lj97+opqT4Rq8xTx7EQbh0vTjL7cFtlVz0qig698TFteEzZwcrLQUl1PbeHLAvocqUmw+thR4um6jf7ug6alXa9O2ZIBLtSOrRkJrAuraVlu+SZ34h5aEfgwXyV7XvLlc4RGoqESVK30VYx9qkFMV8arZ84MbIVA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=n7rqeH4KF0j/7m/EK5/QZVF8WBFKKh0OezQfB70YS48=;
 b=OBVd4o4W/YPpdVrhz95KkA34yoXdW3I3/PTH8A5A5EmNsJ9966jqFO+GNH529HXp3poITC+GLG2xJ1ANlE4IrU5u0Yo2PuGDj9SM3+V3/EPGwZcxOGd+nPuG1PPowmc2nqoz4ULEAVIjCGoSIo4fBUoTBfiPy5z0v5NKcDvq8WVW9b41ALrGJWlx56syP7slZ2lS+J3G7DqrglZrnQKmA/XCRRS6HCySVu4LQJTVHi+WBthWPKS64t+FcDZO3Gqubd2IDbJ/P4poU5fTWY8Y85PzWVX3NRkfV7QnUapi+45XH9O5GgjKPjirrfAM0gJ3iHYthGp/knQli/BG5b1LoQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=n7rqeH4KF0j/7m/EK5/QZVF8WBFKKh0OezQfB70YS48=;
 b=i7JKAdcWjHe/etwNmSPgnzMDSesvS3KWOfAzgDlhUcR0y+wiGRXD3pTwfvr4SFAM9o8PzTUeEIKTNW0kO0waswu67oEKY277mOrfrY2d3E4qJg9I4vReodDL60FD27A0fnzfIOIDH9uUuSz1Jbm6B5DJJTc2bpi2xnNzufikqq0=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
To: <xen-devel@lists.xenproject.org>
CC: Michal Orzel <michal.orzel@amd.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Bertrand Marquis <bertrand.marquis@arm.com>, "Ayan
 Kumar Halder" <ayan.kumar.halder@amd.com>, Artem Mygaiev
	<artem_mygaiev@epam.com>
Subject: [PATCH v4] docs: fusa: Add dom0less domain configuration requirements
Date: Wed, 8 Jan 2025 17:03:04 +0000
Message-ID: <20250108170304.2250917-1-ayan.kumar.halder@amd.com>
X-Mailer: git-send-email 2.25.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SA2PEPF000015CA:EE_|SJ2PR12MB8739:EE_
X-MS-Office365-Filtering-Correlation-Id: 0a770a88-9b55-4d1d-6bc9-08dd300653de
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|1800799024|376014|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?LiaWK+q2g6MsxpGQUGyAwmqwlmbmokWhtjJJmeseFpgsvbaaP2aKyBExDohv?=
 =?us-ascii?Q?E8y1HPjAx6Fso0w6MmwsvejmDf6/E8Oum3fN90Cfx02E7P0NKRH7IshaEM+W?=
 =?us-ascii?Q?jiQ2UaxQi0k6GtKhXy/12d/6p9FeeWr0KyhS72FiYwhX2bs9yKZ5c5opiXoq?=
 =?us-ascii?Q?QvTatzEYS2NPH5nptk4VsUP6zn8UVtE6eJYU4hDoWP0mmQH/dd346sk6iZoN?=
 =?us-ascii?Q?PfY/6Hb0T0bcgvhRTnFPD8BYihyZEEG7EFSj3CAJ1ab1GR/EBmx8Y2UPDMFh?=
 =?us-ascii?Q?9p86jPweAJLmdzLBU8kVf98BkgHH7/JyReWJMWWa9+BKNofWkxBBGdvt8pI3?=
 =?us-ascii?Q?5ScXyPGl6jKPgTnPBCUW+RF6OXOm/GXk7u0yfrjj4u+0a7vJN6cn3M+UxBcw?=
 =?us-ascii?Q?oWAq6gp7iGZDW7LqbFhwrbqDYEHGgRNJYCz+LnD2n5xFYoP9eDr1cPvXCaZP?=
 =?us-ascii?Q?4THGKwlT4rgBvj5JB6d+l9S3o/i+dsqiuCoCNxyNOf1ItmeBr9l8/HHuQRjj?=
 =?us-ascii?Q?u8D6WAYMrT2XMh2Xn9yuBY/WVY2yTo91Gdvf0/yEtscQJvO2PggIoEwux6vx?=
 =?us-ascii?Q?6vZxXP+lIi39iLxm2FfDkDDChcqF7DhLEZL0ep7h6/e6fkvAeMSfTSFvkCrJ?=
 =?us-ascii?Q?0GPn2Z62oyngVTN3taAeK29w3JvQY4xVs3t2pSIOAR6awuPhRyJw6gMVpKyL?=
 =?us-ascii?Q?y5CPMpA/ciAch0AfWI/vSPr6NhPD6XwUTTDn826Vn4fbzccSYyokZHZQjtmt?=
 =?us-ascii?Q?NBqTLf0on67+ZbVle/sg2Uku4tDXyT/dMuUMHV+6KF0luvW7RwnymBt58gYe?=
 =?us-ascii?Q?bcN9zpK+l+HreJ+GlrUTF38FNlwAnMIB+hp+UVRKNhoq+Aa05nu80fhRJkIE?=
 =?us-ascii?Q?yGwJDiY95edItvBzg/pWxwKCrkfI0eyzqDQfxQCK6p8hXxxKRg0gB66vYRLO?=
 =?us-ascii?Q?Oj1eJuiDzyAtSVbRR23y1NmIc8+YUaCEoXpmgP/m9UvbZ4RgQDGX38gXMmgB?=
 =?us-ascii?Q?wGd4pVA0sNefOO1NUtZZkZo4HYe+4bMA076AB4ML/Nx5OoPaaq1VjWoGneCY?=
 =?us-ascii?Q?QXGqLOYr6Nl/p9j6hYK06XAnN3782ZjU09zAOe3u6PKxSqSe8lEAHr3RRA2f?=
 =?us-ascii?Q?CE5CwsG0uf33GMzgzdFR4Av8oWFKrv1fxsBls+7NdIAYCvNsIt8wG0k8Q/GD?=
 =?us-ascii?Q?DwSkrP2d2uHdcqITkHGA+fFw/7e2ngmK7UDa27NKPZbYt2sxPOwq0Ivi6wV5?=
 =?us-ascii?Q?D83S0p10Yk2ArezV8j+z5fdzf6zwrQiQ5BlJmKIMJRYxaR/m39SRi3rWvwUi?=
 =?us-ascii?Q?KtaH/S4MbkfwYWRdFZ0nUgdXw5dawZ2HFVeLxAVbyuUtk9Up630ADnf/zq34?=
 =?us-ascii?Q?ClDInWFGMnWkfKLakuS+Q4XchTDLfZ32dTx4xZh0nGNfLL1WToqOUiyi9SEJ?=
 =?us-ascii?Q?nZViPJ1/HfJY2nhbPXCDqP92MoBiFXfg?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(376014)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jan 2025 17:03:08.9782
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 0a770a88-9b55-4d1d-6bc9-08dd300653de
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SA2PEPF000015CA.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB8739

From: Michal Orzel <michal.orzel@amd.com>

Add requirements for dom0less domain creation.

Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
---
Changes from -

v1 - 1. As the dom0less domain creation requirements specifies the dt properties
for creating domains, it has been moved to product requirements. Product
requirements define the interface Xen exposes to other domains.

2. For the requirements which introduces new terms (like grant table, etc), I
have provided the definition as part of the comments.

3. Introduced new market requirements to specify that Xen can assign iomem and
irqs to domains.

4. The design requirements will be added later.

v2 - 1. Rephrased the requirements as suggested.

2. Split the product requirements into arm64 specific and common.

3. The arm64 specific requirements have arm64_ prefixed to their tag names.

4. Grant table requirements have been dropped for now.

5. Added a market requirement to denote that Xen can support multiple schedulers.

6. Updated index.rst as we have a new file ie product-reqs/reqs.rst.

V3 - 1. Removed duplicate mention for 'Rationale'.

2. Fixed some of the descriptions as per the review comments.

 docs/fusa/reqs/index.rst                   |   1 +
 docs/fusa/reqs/market-reqs/reqs.rst        |  31 ++++
 docs/fusa/reqs/product-reqs/arm64/reqs.rst | 128 ++++++++++++++++-
 docs/fusa/reqs/product-reqs/reqs.rst       | 160 +++++++++++++++++++++
 4 files changed, 318 insertions(+), 2 deletions(-)
 create mode 100644 docs/fusa/reqs/product-reqs/reqs.rst

diff --git a/docs/fusa/reqs/index.rst b/docs/fusa/reqs/index.rst
index 8a4dae6fb2..1088a51d52 100644
--- a/docs/fusa/reqs/index.rst
+++ b/docs/fusa/reqs/index.rst
@@ -8,6 +8,7 @@ Requirements documentation
 
    intro
    market-reqs/reqs
+   product-reqs/reqs
    product-reqs/arm64/reqs
    design-reqs/arm64/generic-timer
    design-reqs/arm64/sbsa-uart
diff --git a/docs/fusa/reqs/market-reqs/reqs.rst b/docs/fusa/reqs/market-reqs/reqs.rst
index f456788d96..39b2714237 100644
--- a/docs/fusa/reqs/market-reqs/reqs.rst
+++ b/docs/fusa/reqs/market-reqs/reqs.rst
@@ -47,3 +47,34 @@ Comments:
 
 Needs:
  - XenProd
+
+Static VM definition
+--------------------
+
+`XenMkt~static_vm_definition~1`
+
+Description:
+Xen shall support assigning peripherals to various domains.
+
+Rationale:
+
+Comments:
+Peripheral implies an iomem (input output memory) and/or interrupts.
+
+Needs:
+ - XenProd
+
+Multiple schedulers
+-------------------
+
+`XenMkt~multiple_schedulers~1`
+
+Description:
+Xen shall provide different ways of scheduling virtual cpus onto physical cpus.
+
+Rationale:
+
+Comments:
+
+Needs:
+ - XenProd
diff --git a/docs/fusa/reqs/product-reqs/arm64/reqs.rst b/docs/fusa/reqs/product-reqs/arm64/reqs.rst
index db91c47a02..ad5c1fdef7 100644
--- a/docs/fusa/reqs/product-reqs/arm64/reqs.rst
+++ b/docs/fusa/reqs/product-reqs/arm64/reqs.rst
@@ -6,7 +6,7 @@ Domain Creation And Runtime
 Emulated Timer
 --------------
 
-`XenProd~emulated_timer~1`
+`XenProd~arm64_emulated_timer~1`
 
 Description:
 Xen shall grant access to "Arm Generic Timer" for the domains.
@@ -25,7 +25,7 @@ Needs:
 Emulated UART
 -------------
 
-`XenProd~emulated_uart~1`
+`XenProd~arm64_emulated_uart~1`
 
 Description:
 Xen shall provide an "Arm SBSA UART" compliant device to the domains.
@@ -40,3 +40,127 @@ Covers:
 
 Needs:
  - XenSwdgn
+
+Linux kernel image
+------------------
+
+`XenProd~arm64_linux_kernel_image~1`
+
+Description:
+Xen shall create a domain with a binary containing header compliant with Arm64
+Linux kernel image [1].
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenMkt~run_arm64_domains~1`
+
+Needs:
+ - XenSwdgn
+
+Gzip Linux kernel image
+-----------------------
+
+`XenProd~arm64_linux_kernel_gzip_image~1`
+
+Description:
+Xen shall create a domain with a Gzip compressed binary containing header
+compliant with Arm64 Linux kernel image [1].
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenMkt~run_arm64_domains~1`
+
+Needs:
+ - XenSwdgn
+
+Kernel with uImage header
+-------------------------
+
+`XenProd~arm64_kernel_uimage~1`
+
+Description:
+Xen shall create a domain with a binary containing uImage header [2].
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenMkt~run_arm64_domains~1`
+
+Needs:
+ - XenSwdgn
+
+Gzip kernel with uImage header
+------------------------------
+
+`XenProd~arm64_gzip_kernel_uimage~1`
+
+Description:
+Xen shall create a domain with a Gzip compressed binary containing uImage
+header [2].
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenMkt~run_arm64_domains~1`
+
+Needs:
+ - XenSwdgn
+
+SPIs
+----
+
+`XenProd~arm64_spis~1`
+
+Description:
+Xen shall assign hardware shared peripheral interrupts specified in the device
+tree to a domain.
+
+Rationale:
+
+Comments:
+Device tree is a data structure and language for describing hardware which is
+readable by an operating system [3].
+A shared peripheral interrupt is a peripheral interrupt that the Arm Generic
+Interrupt Controller's Distributor interface can route to any combination of
+processors [4].
+
+Covers:
+ - `XenMkt~run_arm64_domains~1`
+ - `XenMkt~static_vm_definition~1`
+
+Needs:
+ - XenSwdgn
+
+Virtual PL011
+-------------
+
+`XenProd~arm64_virtual_pl011~1`
+
+Description:
+Xen shall provide an "Arm PL011 UART" compliant device to the domains.
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenMkt~run_arm64_domains~1`
+ - `XenMkt~provide_console_domains~1`
+
+Needs:
+ - XenSwdgn
+
+| [1] https://github.com/torvalds/linux/blob/master/Documentation/arch/arm64/booting.rst
+| [2] https://source.denx.de/u-boot/u-boot/-/blob/master/include/image.h#L315
+| [3] https://docs.kernel.org/devicetree/usage-model.html
+| [4] https://developer.arm.com/documentation/ihi0048/a/Introduction/Terminology/Interrupt-types?lang=en
diff --git a/docs/fusa/reqs/product-reqs/reqs.rst b/docs/fusa/reqs/product-reqs/reqs.rst
new file mode 100644
index 0000000000..88d8de7811
--- /dev/null
+++ b/docs/fusa/reqs/product-reqs/reqs.rst
@@ -0,0 +1,160 @@
+.. SPDX-License-Identifier: CC-BY-4.0
+
+Domain Creation And Runtime
+===========================
+
+Kernel command line arguments
+-----------------------------
+
+`XenProd~kernel_cmd_line_args~1`
+
+Description:
+Xen shall pass kernel command line arguments to a domain via a device tree.
+
+Rationale:
+
+Comments:
+Device tree is a data structure and language for describing hardware which is
+readable by an operating system [1].
+
+Covers:
+ - `XenMkt~run_arm64_domains~1`
+
+Needs:
+ - XenSwdgn
+
+Ramdisk
+-------
+
+`XenProd~ramdisk~1`
+
+Description:
+Xen shall provide the address of an initial ramdisk to a domain via a device
+tree.
+
+Rationale:
+
+Comments:
+The initial ramdisk is contained in memory.
+
+Covers:
+ - `XenMkt~run_arm64_domains~1`
+
+Needs:
+ - XenSwdgn
+
+Memory
+------
+
+`XenProd~memory~1`
+
+Description:
+Xen shall create a domain with the amount of memory specified in a device tree.
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenMkt~run_arm64_domains~1`
+
+Needs:
+ - XenSwdgn
+
+vCPUs
+-----
+
+`XenProd~vcpus~1`
+
+Description:
+A domain shall have a configurable number of virtual CPUs (1 to 128).
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenMkt~run_arm64_domains~1`
+
+Needs:
+ - XenSwdgn
+
+Credit2 CPU pool scheduler
+--------------------------
+
+`XenProd~credit2_cpu_pool_scheduler~1`
+
+Description:
+Xen shall have a credit2 scheduler where a physical cpu can be shared between
+more than one virtual cpu.
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenMkt~run_arm64_domains~1`
+ - `XenMkt~multiple_schedulers~1`
+
+Needs:
+ - XenSwdgn
+
+NUL CPU pool scheduler
+----------------------
+
+`XenProd~nul_cpu_pool_scheduler~1`
+
+Description:
+Xen shall have a nul scheduler where the domain virtual cpu is always running on
+its dedicated physical cpu.
+
+Rationale:
+
+Comments:
+A NUL CPU pool scheduler maps a virtual cpu to a unique physical cpu.
+
+Covers:
+ - `XenMkt~run_arm64_domains~1`
+ - `XenMkt~multiple_schedulers~1`
+
+Needs:
+ - XenSwdgn
+
+Assign iomem
+------------
+
+`XenProd~assign_iomem~1`
+
+Description:
+Xen shall support assigning pages of iomem (address and size aligned to a page)
+to a domain.
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenMkt~static_vm_definition~1`
+
+Needs:
+ - XenSwdgn
+
+Forward interrupts
+------------------
+
+`XenProd~forward_irqs~1`
+
+Description:
+Xen shall support forwarding hardware interrupts to a domain.
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenMkt~static_vm_definition~1`
+
+Needs:
+ - XenSwdgn
+
+| [1] https://docs.kernel.org/devicetree/usage-model.html
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Wed Jan 08 17:09:10 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 17:09:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867711.1279280 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVZYI-0003Zq-M2; Wed, 08 Jan 2025 17:09:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867711.1279280; Wed, 08 Jan 2025 17:09:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVZYI-0003Zj-JG; Wed, 08 Jan 2025 17:09:06 +0000
Received: by outflank-mailman (input) for mailman id 867711;
 Wed, 08 Jan 2025 17:09:05 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=HeEA=UA=cloud.com=kelly.choi@srs-se1.protection.inumbo.net>)
 id 1tVZYH-0003Zd-FY
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 17:09:05 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4361b323-cde3-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 18:09:04 +0100 (CET)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-aa692211331so1545066b.1
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 09:09:04 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 4361b323-cde3-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736356144; x=1736960944; darn=lists.xenproject.org;
        h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
         :date:message-id:reply-to;
        bh=U4fh6xLiXRuynsjWZERG9QnDY6MYtLlBf7DiIoXFTvE=;
        b=bKwSj1IG7rG/DppCXEEv88tpHE+ZeOrnPf3Ij6E3HO6/QJ3yRoO4jVGX+ShwYRumDC
         6x7KWvL5ydt3fAcGTl2XQGFCygcSghdVjglqoPSOl8PKMnE1evrsvzi1Wb+kF4BlW6N5
         AiGbC5yF9s08yTdPljI5tMlapWfqmnFEt4jRc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736356144; x=1736960944;
        h=to:subject:message-id:date:from:mime-version:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=U4fh6xLiXRuynsjWZERG9QnDY6MYtLlBf7DiIoXFTvE=;
        b=WoFMp1ijLt8rJZD0p4hLaCl6raykxsUNH5JuNPldhdmd2ckJSyn0IgfNhfTA2bsTtg
         uq4HGxI0r2V9HxMXvfk6ZEYpsYjyiT4YN7CHb9z1tNaXeIn7kzg+EvdcpOSdi71hH5rF
         brrd4cQyCpVqrhPAnrTEjzJUxjC0kTLKoGZ4AaDBhFtGp8zSiiVPRrS9wag24MC63BI2
         Nz0TK4PixSxW4S3phlK0lrvQVHgjWKIdfUm4Blp/aRUShXj/h/hfvTSirFfzO8DEE35e
         1VXiuYbR0UqTx5RMrna81sFqyniPW0FCipLzCAfn+7S2Jo7NpUUjkY4u99W7q+ndRRgG
         Ub7w==
X-Gm-Message-State: AOJu0Yw6snuSmn2R/K6jH77Ec+jgDn68zvklGBJAm5xRVLM+2efIJDVZ
	O0Sai4VKqFnGqKjBhsdpuFdYvhm8y7hFaXjHnS7mZjgflB3MwiGkSKLwtbtoyidsttAHaeiMZqf
	IK4rYm1irizHADYHkQ29davG4sbzkC88Fmc5laWaq6UWfJWiXMXYwZg==
X-Gm-Gg: ASbGncuLX5XxZlSYrSNZwEHBCTT+z6eEsbrsqltB25n+8kzLPYFKxIl9lwweWY4DvG+
	CJmeB55G+5QkOJ6BwEW7zpZ3wTq6rBs4u5pPOcaZol5Mxqo26lixajxCjreckWb2iaw1hBgo=
X-Google-Smtp-Source: AGHT+IFMkA8zrwvKuV4OJtiA5pFQIkO2aiaADwbulLZYubXqcjzObmS5gQSx+2SZR6WVyvvI3uUDOuSD/Zy+4bkZWpI=
X-Received: by 2002:a17:907:1b17:b0:aa4:cd1e:c91b with SMTP id
 a640c23a62f3a-ab2c3c451a3mr9457866b.7.1736356143406; Wed, 08 Jan 2025
 09:09:03 -0800 (PST)
MIME-Version: 1.0
From: Kelly Choi <kelly.choi@cloud.com>
Date: Wed, 8 Jan 2025 17:08:27 +0000
X-Gm-Features: AbW1kvbJELFWk72TJN47gtgaB-_IJLAZUKH8CkYAk0qVXiWsCqoao1_gaOZuO5w
Message-ID: <CAO-mL=wMNO3bpv9xSYUT1E9FeAC4zdyj4Y0qDvsfTsPFVwu9bg@mail.gmail.com>
Subject: [ANNOUNCE] Call for agenda items - Community Call 9th Jan 2025
To: xen-devel <xen-devel@lists.xenproject.org>
Content-Type: multipart/alternative; boundary="00000000000021b917062b34eb3d"

--00000000000021b917062b34eb3d
Content-Type: text/plain; charset="UTF-8"

Hi all,

Please add your proposed agenda items below. If any action items are
missing or have been resolved, please add/remove them from the sheet.

https://cryptpad.fr/pad/#/2/pad/edit/TI2jaCcgSU2WnA6OeQJq-qAy/

*CALL LINK:* https://meet.jit.si/XenProjectCommunityCall
<https://www.google.com/url?q=https://meet.jit.si/XenProjectCommunityCall&sa=D&source=calendar&ust=1699196661201312&usg=AOvVaw1FcogEsMjFSd1Pmi7V0cBc>

*DATE: *Thursday 9th January 2025

*TIME: *1600 UTC (4 pm UK time)
*Note the following administrative conventions for the call:*


** To allow time to switch between meetings, we plan on starting theagenda
at 16:05 UTC sharp.  Aim to join by 16:03 UTC if possible to allocatetime
to sort out technical difficulties.*








** If you want to be CC'ed please add or remove yourself from
thesign-up-sheet
at https://cryptpad.fr/pad/#/2/pad/edit/D9vGzihPxxAOe6RFPz0sRCf+/
<https://cryptpad.fr/pad/#/2/pad/edit/D9vGzihPxxAOe6RFPz0sRCf+/>== Dial-in
Information ==## Meeting time16:00 - 17:00 British timeFurther
International meeting
times:*https://www.timeanddate.com/worldclock/meetingdetails.html?year=2025&month=1&day=9&hour=16&min=0&sec=0&p1=1234&p2=37&p3=224&p4=179


## Dial in details
https://meet.jit.si/static/dialInInfo.html?room=XenProjectCommunityCall

Thanks,
Kelly Choi
Community Manager
Xen Project <https://xenproject.org/>

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

<div dir=3D"ltr"><div><div><div><p>Hi all,=C2=A0</p><p>Please add your prop=
osed agenda items below. If any action items are missing or have been resol=
ved, please add/remove them from the sheet.=C2=A0</p><p><a href=3D"https://=
cryptpad.fr/pad/#/2/pad/edit/TI2jaCcgSU2WnA6OeQJq-qAy/">https://cryptpad.fr=
/pad/#/2/pad/edit/TI2jaCcgSU2WnA6OeQJq-qAy/</a>=C2=A0</p><p><b><span class=
=3D"gmail-il">CALL</span>=C2=A0LINK:</b>=C2=A0<a href=3D"https://www.google=
.com/url?q=3Dhttps://meet.jit.si/XenProjectCommunityCall&amp;sa=3DD&amp;sou=
rce=3Dcalendar&amp;ust=3D1699196661201312&amp;usg=3DAOvVaw1FcogEsMjFSd1Pmi7=
V0cBc" target=3D"_blank">https://meet.jit.si/XenProjectCommunityCall</a></p=
><p><b>DATE:=C2=A0</b>Thursday 9th January 2025</p><p><b>TIME:=C2=A0</b>160=
0 UTC (4 pm UK time)</p><i>Note the following administrative conventions fo=
r the=C2=A0<span class=3D"gmail-il">call</span>:</i></div><div><div><i>* To=
 allow time to switch between meetings, we plan on starting the<br>agenda a=
t 16:05 UTC sharp.=C2=A0 Aim to join by 16:03 UTC if possible to allocate<b=
r>time to sort out technical difficulties.</i></div><div><i><br>* If you wa=
nt to be CC&#39;ed please add or remove yourself from the<br>sign-up-sheet =
at=C2=A0<a href=3D"https://cryptpad.fr/pad/#/2/pad/edit/D9vGzihPxxAOe6RFPz0=
sRCf+/" rel=3D"noreferrer" target=3D"_blank">https://cryptpad.fr/pad/#/2/pa=
d/edit/D9vGzihPxxAOe6RFPz0sRCf+/</a><br><br>=3D=3D=C2=A0<span class=3D"gmai=
l-il">Dial</span>-in Information =3D=3D<br>## Meeting time<br>16:00 - 17:00=
 British time<br>Further International meeting times:<br></i><a href=3D"htt=
ps://www.timeanddate.com/worldclock/meetingdetails.html?year=3D2025&amp;mon=
th=3D1&amp;day=3D9&amp;hour=3D16&amp;min=3D0&amp;sec=3D0&amp;p1=3D1234&amp;=
p2=3D37&amp;p3=3D224&amp;p4=3D179" target=3D"_blank">https://www.timeanddat=
e.com/worldclock/meetingdetails.html?year=3D2025&amp;month=3D1&amp;day=3D9&=
amp;hour=3D16&amp;min=3D0&amp;sec=3D0&amp;p1=3D1234&amp;p2=3D37&amp;p3=3D22=
4&amp;p4=3D179 </a>=C2=A0<br><br>##=C2=A0<span class=3D"gmail-il">Dial</spa=
n>=C2=A0in details<br><a href=3D"https://meet.jit.si/static/dialInInfo.html=
?room=3DXenProjectCommunityCall" rel=3D"noreferrer" target=3D"_blank">https=
://meet.jit.si/static/dialInInfo.html?room=3DXenProjectCommunityCall</a></d=
iv></div></div><div><br></div></div><div><div dir=3D"ltr" class=3D"gmail_si=
gnature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>Thanks,</=
div><div>Kelly Choi<br></div><div><div style=3D"color:rgb(136,136,136)">Com=
munity Manager</div><div style=3D"color:rgb(136,136,136)"><a href=3D"https:=
//xenproject.org/" target=3D"_blank">Xen Project</a><br></div></div></div><=
/div></div></div>

--00000000000021b917062b34eb3d--


From xen-devel-bounces@lists.xenproject.org Wed Jan 08 20:17:33 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 20:17:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867726.1279289 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVcUR-0000ZB-GP; Wed, 08 Jan 2025 20:17:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867726.1279289; Wed, 08 Jan 2025 20:17:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVcUR-0000Z4-DM; Wed, 08 Jan 2025 20:17:19 +0000
Received: by outflank-mailman (input) for mailman id 867726;
 Wed, 08 Jan 2025 20:17: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
 <SRS0=/V3S=UA=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tVcUQ-0000Yy-Hz
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 20:17:18 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8da55d9e-cdfd-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 21:17:16 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 8584FA4191C;
 Wed,  8 Jan 2025 20:15:26 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id CF8EAC4CED3;
 Wed,  8 Jan 2025 20:17:13 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8da55d9e-cdfd-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1736367434;
	bh=6Y7mj0SSgau3aq+NCVzuNqEQFQXMu0eSs9g1ZmEoy1k=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=SCddbubU8ajMflB0RjN8iTnqkD1WkDJ4HY22sShExDqK6uZLzGSvCveXLqCn9hUze
	 ALZ63ZEq0HweQZj2iYUCxT1LpI5R6Y3i3zTTVJAb2ex0t9sJpcuRD41TPNnZke8zmP
	 yocIBKyqKVyfruM4h3cjRCu5LjSsWKwDS+XU59BS21pR/LGeCslUrjoFqTDhrjB63b
	 KATqykAmlPa1ehibQF01/B3MdsSXzTSV751JmbmmhqW9fE4w+a4ce2gO1clXX0EkDy
	 ObtVfO8xNrHhCKSpuVoQMooiKy4UjNwzdJoJIK3bkh4vitVfTLAGI/9gNIRIZve+ZN
	 jXpXwAPv36qnw==
Date: Wed, 8 Jan 2025 12:17:12 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Anthony PERARD <anthony.perard@vates.tech>
cc: Andrew Cooper <andrew.cooper3@citrix.com>, 
    Xen-devel <xen-devel@lists.xenproject.org>, 
    Stefano Stabellini <sstabellini@kernel.org>, 
    Michal Orzel <michal.orzel@amd.com>, Doug Goldstein <cardoe@cardoe.com>, 
    Oleksii Kurochko <oleksii.kurochko@gmail.com>, 
    =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
Subject: Re: [PATCH for-4.20] CI: Update Fedora to 41
In-Reply-To: <Z36KL4Sss_QuUQim@l14>
Message-ID: <alpine.DEB.2.22.394.2501081217080.133435@ubuntu-linux-20-04-desktop>
References: <20250108124316.1107121-1-andrew.cooper3@citrix.com> <Z36KL4Sss_QuUQim@l14>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Wed, 8 Jan 2025, Anthony PERARD wrote:
> On Wed, Jan 08, 2025 at 12:43:16PM +0000, Andrew Cooper wrote:
> > Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> 
> Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


From xen-devel-bounces@lists.xenproject.org Wed Jan 08 21:14:08 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 21:14:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867740.1279303 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVdNJ-0007YH-Jl; Wed, 08 Jan 2025 21:14:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867740.1279303; Wed, 08 Jan 2025 21:14:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVdNJ-0007YA-Gp; Wed, 08 Jan 2025 21:14:01 +0000
Received: by outflank-mailman (input) for mailman id 867740;
 Wed, 08 Jan 2025 21:13:59 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=UrZA=UA=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tVdNH-0007Y4-Qv
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 21:13:59 +0000
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com
 [2a00:1450:4864:20::436])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 790106d1-ce05-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 22:13:57 +0100 (CET)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-385dece873cso132852f8f.0
 for <xen-devel@lists.xenproject.org>; Wed, 08 Jan 2025 13:13:57 -0800 (PST)
Received: from [192.168.86.29] ([83.105.36.37])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436e2e02b8esm33441955e9.31.2025.01.08.13.13.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 08 Jan 2025 13:13:56 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 790106d1-ce05-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736370837; x=1736975637; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ZlD8ISfDgyUpmXMt4e8BHzf6yPjiSfj6rl1MZHVbDDg=;
        b=LMaDGIgMEk1l/p1UJjfYvMFxcUQhDYc6IC1+ivBGKd5BDRAOeg/Z01QHwsrDDLvgl9
         3cfHuq34/gYOTq25HHbvv/OtZqiX4PqZrhFAqAaHx/wUCDgUCJuo3jBjGkHil7Ff94ku
         GxhvuDezw0dJVqAUBQXQWwBGMAQ5A8PXRLChs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736370837; x=1736975637;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ZlD8ISfDgyUpmXMt4e8BHzf6yPjiSfj6rl1MZHVbDDg=;
        b=Be8w5mBr3aKE7Q+txH9RkX4fiMiOOl92A2bj9MW5uw7kuHBV7nReqOzJywjyEkvdtD
         4tfV3ouZAkVH7gg5m9z5UajrA9v2owzcI+5dc7mT98gTabbGm5yPsGQmW1h480rM/0sC
         5Liq7clUP2EQHNuyGsBAXSXtwfPcXt5YKJUntUxT9YrZ9wzzngauyi41n7Hvj4PGoqvC
         pxV/BTDhRhxYp61L8OHOnsauxDipymvOM7bkB11kf5W0WOKoD3CznPilDzSygxdfyCwk
         iWyxF4IgxyaerCSMAWJG4NcvgiRiIt7J3uR2tHjZSgtratmXqv9s0Pxv2GR5RoiTtJaO
         V7Tw==
X-Forwarded-Encrypted: i=1; AJvYcCXIIN24xjXeH1e7s+tF3tRWud93c7XylmZKbEtSjPieVHjftA054Q4DRbvHp2INs2HcI7ZHPOPcYp4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzdL45iLjMx4HvZOBD1KwD5gtHluhZl1hPy3lLDgvKB3Jn2Ui1V
	LkvGawHPZOQ38gGVFiAgIKhJD9MI/7QRcoET7LUs6f6CSjdMUiFcx6jxRZOhmdY=
X-Gm-Gg: ASbGncukV9/36hgRiMWS5lT870hU6lbem4WQxNVf387on3FhoOoO2m05YrnHnLqylj3
	2QEPohrA64dzd/GWV3fa+dEo7e1W5+AaGxa7wg6VGm+p8yXNU6pkXToBAJG+G8i5YlCnRirpzrX
	0QU1NfAQ+0dxadLDgT/z9sH5R2cBcOxcTsF8G/5IAWTqGoKgTeqhr0oeHrx80DVQfqINt0X/vzO
	lverK4B0KrdHjM2kCXRFG090QIY2ZCqxYjn/9rQrVCaYIHynx6j95AQlw1J1T6GJ4w=
X-Google-Smtp-Source: AGHT+IGdvLD0JYjbzUqP0drFc1ixeMCLe7WWFEyN9oYEcEu5PKUHYwp1S37VdKosW0SQp16CeeVhmA==
X-Received: by 2002:a05:6000:1f88:b0:38a:615c:8223 with SMTP id ffacd0b85a97d-38a872f69c7mr3689971f8f.10.1736370836844;
        Wed, 08 Jan 2025 13:13:56 -0800 (PST)
Message-ID: <90c54825-9302-41df-81e0-af7d952f64b0@citrix.com>
Date: Wed, 8 Jan 2025 21:13:55 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/arm: ffa: fix build with clang
To: Alejandro Vallejo <alejandro.vallejo@cloud.com>,
 Stewart Hildebrand <stewart.hildebrand@amd.com>,
 xen-devel@lists.xenproject.org
Cc: Volodymyr Babchuk <volodymyr_babchuk@epam.com>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Michal Orzel <michal.orzel@amd.com>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>
References: <20250108152317.335441-1-stewart.hildebrand@amd.com>
 <D6WT3QSKXNG4.162UPSGMQ1ZIS@cloud.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <D6WT3QSKXNG4.162UPSGMQ1ZIS@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 08/01/2025 3:45 pm, Alejandro Vallejo wrote:
> Hi,
>
> On Wed Jan 8, 2025 at 3:23 PM GMT, Stewart Hildebrand wrote:
>> It appears the variable ffa_fw_version is only used in ffa.c. Was there
>> any rationale for exporting the symbol in 2f9f240a5e87 ("xen/arm: ffa:
>> Fine granular call support")? If not, perhaps we ought to make it static
>> again and remove the declaration in the header.
> The only reason I can think of is wanting to have it in the symbol table of the
> ELF file for some reason (livepatching?)

Livepatching can work with static symbols just fine.

Binary diffing is per TU, looking at all symbols in the object, not just
global symbols.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Jan 08 21:54:41 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 21:54:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867748.1279313 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVe0S-00046s-JA; Wed, 08 Jan 2025 21:54:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867748.1279313; Wed, 08 Jan 2025 21:54:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVe0S-00046l-FQ; Wed, 08 Jan 2025 21:54:28 +0000
Received: by outflank-mailman (input) for mailman id 867748;
 Wed, 08 Jan 2025 21:54:26 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=VB6G=UA=amd.com=Jason.Andryuk@srs-se1.protection.inumbo.net>)
 id 1tVe0Q-00046f-Mc
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 21:54:26 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on20619.outbound.protection.outlook.com
 [2a01:111:f403:2408::619])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1f9127bb-ce0b-11ef-a0df-8be0dac302b0;
 Wed, 08 Jan 2025 22:54:25 +0100 (CET)
Received: from PH0P220CA0014.NAMP220.PROD.OUTLOOK.COM (2603:10b6:510:d3::28)
 by SN7PR12MB7835.namprd12.prod.outlook.com (2603:10b6:806:328::22) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8314.16; Wed, 8 Jan
 2025 21:54:21 +0000
Received: from SA2PEPF000015CD.namprd03.prod.outlook.com
 (2603:10b6:510:d3:cafe::8c) by PH0P220CA0014.outlook.office365.com
 (2603:10b6:510:d3::28) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8335.11 via Frontend Transport; Wed,
 8 Jan 2025 21:54:20 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SA2PEPF000015CD.mail.protection.outlook.com (10.167.241.203) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8335.7 via Frontend Transport; Wed, 8 Jan 2025 21:54:20 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 8 Jan
 2025 15:54:19 -0600
Received: from [172.31.88.124] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Wed, 8 Jan 2025 15:54:19 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1f9127bb-ce0b-11ef-a0df-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=xLwedf5Wq7pHxT6AEjPkYJJu8ZJhr6pain/PJAh+ME28zfX4wvAZAHPLDGNiLHrroX3AT2CBpp62TSVxltN/Pf3gjQhLqxpe7Nvm9LifR7ttmz5ELsIvYNI2Jmldn0+EEJgPzHJVks1sQA840fcLenCf2X7CpEDurENZGtLMe8iWQyQMaeKQVz19jrUCNuDDXpF3CBjCv+zuUMYIcTAqIQ53HOpbpwikENObCovI+ykASaZP3Zo1n3zgv0iT5Cr7SpGXZjE8kCYu9VBqJz0Ek/HVbpfAkJlka3r0OT0O0LlAppe1NXH2AHff7Ps0pIgjEg4x/bt+SlD25S0a2zfDtw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=f6ysNXTSaJOazNooLTmuJhYn4paUElUMJPZxWVUY3rE=;
 b=DdX+wiKxelef/goxOn+0sMwlySMhmuuwCY6Az1Ffk/q99OYmIMIw4SMcqYR/Nq5lNqCjQxgTKGkK2iRj40/wTGvLvvOal28Z4GAUs1qo5V7sYOYpTMrXPsrZRvlPmF3VuqADsPLYGa1HVbcjmaE8mNxWk8UbWbF7k73XldE4dRXEQD54KQwGvIAV2tYW6a3mcmteeIhN+4P7xExaaoe0oN+noQFJrTgo2xr1B//G9hFzKTQT+2XuuO6Yd3jS0PHvM6pc2L1dc6zfeDcwNryo32IpT6UPlNecF1lrWRXW945miHFBWj4/ArKmnAEV+y+hArbb0whTtB7GcqyYibnIHA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=apertussolutions.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=f6ysNXTSaJOazNooLTmuJhYn4paUElUMJPZxWVUY3rE=;
 b=GYIo0ox0M+QwusBpQYj7K2lr6j8VTZxhbLMgyhU/lBVvhC16BUBRbASRMcNQLsTe1r4D8q9mgTZ41r2a8wU/Q7AFw0E6VM0tRvKEzYe1EDRNwxkAea90Zs/8RyHXN/NJcAINkXqEW8nnDSa7al/+wKzQcNIsxKWQMkiL+FeJfrs=
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: <c39d6c7b-0cd8-4b71-965f-1fd0d49b5221@amd.com>
Date: Wed, 8 Jan 2025 16:54:18 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 06/15] x86/hyperlaunch: introduce the domain builder
To: "Daniel P. Smith" <dpsmith@apertussolutions.com>,
	<xen-devel@lists.xenproject.org>
CC: <christopher.w.clark@gmail.com>, <stefano.stabellini@amd.com>, Jan Beulich
	<jbeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
 <20241226165740.29812-7-dpsmith@apertussolutions.com>
Content-Language: en-US
From: Jason Andryuk <jason.andryuk@amd.com>
In-Reply-To: <20241226165740.29812-7-dpsmith@apertussolutions.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB03.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SA2PEPF000015CD:EE_|SN7PR12MB7835:EE_
X-MS-Office365-Filtering-Correlation-Id: 0d2f7004-9e5e-474b-c244-08dd302f01c0
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|82310400026|376014|1800799024|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?Y0xhZ3JGb1hPSE1MU3JtOVA0WXBrTm9WSElQcTI2MHBBYnpTZ0lwTXo5VWhD?=
 =?utf-8?B?dDFiSEs2MlVxVm90a0VFQzM4VUdhM2hkRjdmUjR1cm5ybXlVaEdZamlqakhU?=
 =?utf-8?B?RTF2aG9CYmYyVjJ1bEJydVRXZXpUTDBhYVVBNGlJbjNUbkhXMnFEdWRtd2J2?=
 =?utf-8?B?OXp2L05pcEJDK0xRNEE3ODBoR0ZCVHdRUVRKU3dHUFFmbzJQNk50Z2NKTVFB?=
 =?utf-8?B?eTBsVS93Yi9ndlZ5ZU5xSkh2Y1I3dXBNOFY2dk1DL2ozdVJjQTlob3NnZkZN?=
 =?utf-8?B?N01qTzlnK2pYdWJMcEF4Q2dLWUY1emtiTW5RYVZiQUZJbUkwWTRQa3k5RjNs?=
 =?utf-8?B?SzlqVE9PaWo2dVVrdHpDWmd0RU1ESHh0MHlsZU5YeHhTVU81c1l6bGV3cHRj?=
 =?utf-8?B?UHlTbXhxVWhCbE9sWXhDZDVjbjJQVjRZWGpoNytjMXJreTBhTWJHNzZFSG91?=
 =?utf-8?B?RUdwbThtVUZLTnlBbE9PYWJMYTd6UkpQODd1WC96YncxTU5RZWJGcE02QlJN?=
 =?utf-8?B?d01DbmJhYmxDWDNCR3NqNTBpbWlPUjg0b2lqT3hBUHhqNjlvWkwzVUpVMHI2?=
 =?utf-8?B?enVpUlNwekNBbWFzd2grOWN5OUdoRmJvRzErMnF3WnpCMTVMcDFPMDRNOFIz?=
 =?utf-8?B?amJYc1dLNEVTWUVlV3MycURRTENDOHBuVkMvN2RtbUUxdjZtOTZMUitKZUVY?=
 =?utf-8?B?VFh3bUtjTEpxd0xqT2dEcURPUk9GQ25YRkFFaFFpMndPS2VGVlVCS3RyUVhQ?=
 =?utf-8?B?YWxsVW1qQU5lL2Nzb2MxdjJXWFBxb2hyZlFDa0VMeWVVMllud1lpWW42SWJM?=
 =?utf-8?B?L3hSOEZUeVRpZ1pBdk1sdDkyNUNvRlJSa25QVmJOcVR3cVJOOFpNUFFhT3Bn?=
 =?utf-8?B?aWRtWnJZRkYyL1JXOGJJSDRWWkJvb253SW9ZOEdUZzVTWWxtb3REWjJzS2cx?=
 =?utf-8?B?Y3NLbFBCYU9oaHVONktFU3lycEdMOHVCWXhBMExUWStvdEp1R2RpMDhiZENu?=
 =?utf-8?B?bndlOTJsRHRRYlFxQ2Z5NmJsN2R1dUd5ekd2ZVVMWk9wR3lvMFpZU25ncVE3?=
 =?utf-8?B?U1ovZ21wTVAxdnpIRkN2czZIOXRLNzhtWmpZYmt6RDB1WEZ5bU9jWHh5Rmc5?=
 =?utf-8?B?ek12dkNFb1JtNWRBSGxJV0lqT3RXRlN6VzNHYVk5NnA5VlhvbTVCdHBBaDE1?=
 =?utf-8?B?MmVFa3ZMelFudmlTVGZKL3J1UURSQ0RWNHhkZmRjMUkzUG9vVGRzdkFUTkRr?=
 =?utf-8?B?K3I2MW5yclEyNFFxSWZrdzdXNHJ3VTdISjFOR1I3aXNCVEZpb0RMM1Vjalcx?=
 =?utf-8?B?Y0FkZy9GY3kwUjl6ekpESE9SOG80NlhuU25KS0QycnVKOUg2YWluSkxGUjc5?=
 =?utf-8?B?Mm50RFRyUnB0cDF3RlIxT2FwMHlvUGNEdS9TZmwvL243YzArN0xrWkFLc3Jj?=
 =?utf-8?B?UU1SdUo3b1NpRjRoU2hOTmpINkI1VUVUeEZEUFEreGo1VGVaeGdIS3RPTFYy?=
 =?utf-8?B?bStWSkJIYy8rdStPNEtPRjBrR3M3dERJUVljTkxwUjB0U3RUd0svUGs3UWZS?=
 =?utf-8?B?YXZDQWorNG9FU0dEVkFmeWlBM1FtK1h1UUdJRmVzU0FUTUpqMnE0MWVNS1lB?=
 =?utf-8?B?bnM0a0k2TmN0UzBpcFoxSGVIcGh2ZlRxdWczTjBpd2NFdEFLK2pyZjJ6dmNy?=
 =?utf-8?B?QklRQUx2YnR4N21pYjRTQlB2S0c5U3UxcW5yK3RwZHRmYlkwTElqVG1FT0pK?=
 =?utf-8?B?Y0NvaWcwa2pFdlJXYXRQWnFFVTRubzAwb0xrZTZmZTVYakpvYWZCVjM5M28w?=
 =?utf-8?B?VnZsKzJKbmFRRDNjYWR0OWwrd2RJV2lPMVBXQ1BLNUhnVnVTY3RjNWp6WEZ6?=
 =?utf-8?B?dnRTbFpBRlBIVmFvWVpmeFh4WnlpQXRsTWs2K09iZE00QmVNdHRnMW1ibFdh?=
 =?utf-8?B?M1RzTS9ONzMwMW9nWFBDbkVwV2c0RHlRQlJYNHBwMXNDOFdMNDZaWU9ZR0Jl?=
 =?utf-8?Q?uaQJ2voOw/3IvFA5x0jWRUq4twqiIs=3D?=
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:(13230040)(36860700013)(82310400026)(376014)(1800799024)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jan 2025 21:54:20.6547
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 0d2f7004-9e5e-474b-c244-08dd302f01c0
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SA2PEPF000015CD.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB7835

On 2024-12-26 11:57, Daniel P. Smith wrote:
> Introduce the domain builder which is capable of consuming a device tree as the
> first boot module. If it finds a device tree as the first boot module, it will
> set its type to BOOTMOD_FDT. This change only detects the boot module and
> continues to boot with slight change to the boot convention that the dom0
> kernel is no longer first boot module but is the second.
> 
> No functional change intended.
> 
> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
> Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>

> diff --git a/xen/arch/x86/domain-builder/Makefile b/xen/arch/x86/domain-builder/Makefile
> new file mode 100644
> index 000000000000..309a0c4bdd9e
> --- /dev/null
> +++ b/xen/arch/x86/domain-builder/Makefile
> @@ -0,0 +1,3 @@
> +obj-$(CONFIG_DOMAIN_BUILDER) += fdt.init.o
> +obj-y += core.init.o
> +

When I git am-ed this series, git warned:
Applying: x86/hyperlaunch: introduce the domain builder
.git/rebase-apply/patch:59: new blank line at EOF.
+
warning: 1 line adds whitespace errors.

I think that is here.

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Wed Jan 08 22:15:31 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Jan 2025 22:15:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867760.1279322 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVeKi-0006z3-8M; Wed, 08 Jan 2025 22:15:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867760.1279322; Wed, 08 Jan 2025 22:15:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVeKi-0006yw-5Z; Wed, 08 Jan 2025 22:15:24 +0000
Received: by outflank-mailman (input) for mailman id 867760;
 Wed, 08 Jan 2025 22:15:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=id0C=UA=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tVeKg-0006yq-Mv
 for xen-devel@lists.xenproject.org; Wed, 08 Jan 2025 22:15:23 +0000
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0c038417-ce0e-11ef-99a4-01e77a169b0f;
 Wed, 08 Jan 2025 23:15:20 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 0c038417-ce0e-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=xcc7p6cv75bwbjoi56cbpkzc4u.protonmail; t=1736374516; x=1736633716;
	bh=iJ7jgISMnP8moSJeN9ZG3IJ8El/2wUuhZQhxp6SyEeY=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=UUB80WaO9OnBzShM5TXlZKagTl9MVzGOrSmhNbAdOXlyk5QhOLJsdewDjF7WcsPfJ
	 //W7y5hUNV3BvYxOG1U8kPd91gEjjdAa7+9AihlVDMM1eqx0OS/8+TJe2gwjuByWAB
	 Ke0WTkX+IwiCvfgqj3qMa/Wzbjg+NhQODV10i5Y2Q5ht7xpqJO1iVS5pR/yZWufXdN
	 BDfYHuj0PRE4DgyyZKzc6cg/lV6njppzzrGTo6pBtMPyhA0kMb+8tLT0FsDuBfPz/q
	 /9kIp6hXkMiaumfp1bGCC0hULsh9vTbwxntHevYgZ1NALMDYgYYiOVeJ7e9Kt4RZ0D
	 9LYT7856ncSZg==
Date: Wed, 08 Jan 2025 22:15:13 +0000
To: =?utf-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: Jan Beulich <jbeulich@suse.com>, Stefano Stabellini <sstabellini@kernel.org>, dmukhin@ford.com, xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>, Michal Orzel <michal.orzel@amd.com>
Subject: Re: [PATCH v2 20/35] xen/console: introduce console_owner_domid()
Message-ID: <m5iIn0DzBY1VE3oW8MMk5aJD5yovtFe2u7eorkGQVf0czY2gzIYl9k2aKmrdyh1AG6YAgyasVn86Js-vUQyudqjHY7bRYE1hXdCkdFVF0U8=@proton.me>
In-Reply-To: <Z344xgqtpNZIDxHD@macbook.local>
References: <20241205-vuart-ns8250-v1-20-e9aa923127eb@ford.com> <8a5a5a0f-72b0-4336-b0d2-142254319242@suse.com> <alpine.DEB.2.22.394.2501061046060.133435@ubuntu-linux-20-04-desktop> <c39c0c6f-2fab-46e8-9563-c91fe890e87f@suse.com> <alpine.DEB.2.22.394.2501071533060.133435@ubuntu-linux-20-04-desktop> <a2fa92ff-a5fb-4adc-86aa-1481ebec92fe@suse.com> <Z34xhkNu5YLyEzut@macbook.local> <121ae72e-6229-40a4-8b9f-4f8b0764b712@suse.com> <Z344xgqtpNZIDxHD@macbook.local>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 57f5106749caa5e22301cbc8a0994558b0ce2fc3
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Wednesday, January 8th, 2025 at 12:35 AM, Roger Pau Monn=C3=A9 <roger.pa=
u@citrix.com> wrote:

>=20
>=20
> On Wed, Jan 08, 2025 at 09:13:02AM +0100, Jan Beulich wrote:
>=20
> > On 08.01.2025 09:04, Roger Pau Monn=C3=A9 wrote:
> >=20
> > > On Wed, Jan 08, 2025 at 08:28:32AM +0100, Jan Beulich wrote:
> > >=20
> > > > On 08.01.2025 00:40, Stefano Stabellini wrote:
> > > >=20
> > > > > On Tue, 7 Jan 2025, Jan Beulich wrote:
> > > > >=20
> > > > > > On 06.01.2025 19:48, Stefano Stabellini wrote:
> > > > > >=20
> > > > > > > On Mon, 6 Jan 2025, Jan Beulich wrote:
> > > > > > >=20
> > > > > > > > On 04.01.2025 05:15, Denis Mukhin wrote:
> > > > > > > >=20
> > > > > > > > > On Tuesday, December 10th, 2024 at 11:28 PM, Jan Beulich =
jbeulich@suse.com wrote:
> > > > > > > > >=20
> > > > > > > > > > On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
> > > > > > > > > >=20
> > > > > > > > > > > From: Denis Mukhin dmukhin@ford.com
> > > > > > > > > > >=20
> > > > > > > > > > > console_owner_domid() is introduced to obtain the "co=
nsole owner" domain ID.
> > > > > > > > > > >=20
> > > > > > > > > > > The call is used in NS8250 emulator to identify the c=
ase when physical xen
> > > > > > > > > > > console focus is owned by the domain w/ NS8250 emulat=
or, in which case,
> > > > > > > > > > > messages from guest OS are formatted w/o '(XEN)' pref=
ix.
> > > > > > > > > >=20
> > > > > > > > > > Such messages ought to be processed through guest_print=
k(), which wants a
> > > > > > > > > > domain pointer, not a domid_t anyway. Plus isn't that g=
oing to be
> > > > > > > > > > current->domain anyway at the callsite, eliminating the=
 need for such a
> > > > > > > > > >=20
> > > > > > > > > > helper altogether?
> > > > > > > > >=20
> > > > > > > > > If the current domain is owning the physical console and =
printing, say, Linux
> > > > > > > > > login prompt, there's no need to add "(XEN)" for every pr=
intout; adding timestamps
> > > > > > > > > can be disabled from Xen command line.
> > > > > > > >=20
> > > > > > > > Surely there shouldn't be (XEN), but without (d<N>) it'll b=
e ambiguous in a log
> > > > > > > > which domain a message came from. As long as only Dom0 mess=
ages are left un-
> > > > > > > > prefixed, that's likely fine. Yet as soon as multiple domai=
ns can issue such
> > > > > > > > messages (and have console "focus") I think the prefix need=
s to be there.
> > > > > > >=20
> > > > > > > It looks like we are aligned on the desired behavior,
> > > > > >=20
> > > > > > Hmm, no, I don't think we are. I don't ...
> > > > > >=20
> > > > > > > but for clarity,
> > > > > > > see https://marc.info/?l=3Dxen-devel&m=3D173405161613716, als=
o copy/pasted
> > > > > > > here:
> > > > > > >=20
> > > > > > > I think we should provide a consistent behavior across archit=
ectures.
> > > > > > > The current behavior with vpl011 and dom0less on ARM is the f=
ollowing:
> > > > > > >=20
> > > > > > > - no prefix for Dom0 output
> > > > > > > - DOM$NUM for DomUs when not in focus, otherwise no prefix
> > > > > >=20
> > > > > > ... view this model as a desirable one. It leaves room for ambi=
guity.
> > > > >=20
> > > > > Adding a few more people in CC for feedback.
> > > > >=20
> > > > > My priority is to keep the architectures aligned. It might be OK =
to
> > > > > change output format, but then let's do it uniformly on ARM as we=
ll.
> > > > >=20
> > > > > Jan, please clarify what you think would be better than the above=
. Is it
> > > > > the following? I don't think I understood your preference.
> > > > >=20
> > > > > - DOM$NUM for Dom0 and DomUs when not in focus, otherwise no pref=
ix
> > > >=20
> > > > No, I mean like we have it with guest_printk() today. (XEN) for Xen=
's
> > > > own messages, (d<N>) for ordinary domains' ones, and no prefix
> > > > exclusively for the hardware/control domain. What is best to do whe=
n
> > > > hardware and control domains are distinct I'm uncertain - I'd be
> > > > inclined to suggest that the hardware domain then stay the one with=
out
> > > > any prefix.
> > >=20
> > > One concern I have with this approach is whether the addition of the
> > > (d<N>) prefixes will skew output of interactive applications. So far
> > > the prefix is added to output from all domains different than dom0
> > > because the console is not interactive for them, and hence no input
> > > can be consumed.
> >=20
> > Hmm, that's an aspect I have to admit I didn't think of.
> >=20
> > > If that changes however, and domains different than dom0 can get inpu=
t
> > > from the Xen console then I wonder how much the added prefix will ske=
w
> > > output. Another possible option would be to not print the prefix for
> > > the domain that has the console input assigned (current target), and
> > > print it for all other domains (even for dom0 when not in focus).
> >=20
> > That's largely what aiui was proposed. My extra requirement there would
> > then be that we make sure a log message is always emitted when console
> > focus shifts, so it's possible to identify the owner for any part of
> > the log.
>=20
>=20
> Indeed, printing console input shifting should be a requirement
> regardless of how we decide to print the prefix.

Console input focus switch is indicated after pressing Crtl+aaa, e.g.:
[[
...
(XEN) [15359.353038] *** Serial input to Xen (type 'CTRL-aaa' to switch inp=
ut)
(XEN) [15361.176754] *** Serial input to DOM0 (type 'CTRL-aaa' to switch in=
put)
(XEN) [15711.297202] *** Serial input to DOM1 (type 'CTRL-aaa' to switch in=
put)
...
]]

>=20
> Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 00:29:53 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 00:29:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867776.1279333 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVgQV-0006pX-OY; Thu, 09 Jan 2025 00:29:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867776.1279333; Thu, 09 Jan 2025 00:29:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVgQV-0006pQ-LV; Thu, 09 Jan 2025 00:29:31 +0000
Received: by outflank-mailman (input) for mailman id 867776;
 Thu, 09 Jan 2025 00:29: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
 <SRS0=T+E5=UB=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tVgQU-0006pK-27
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 00:29:30 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c91ea98d-ce20-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 01:29:28 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 01653A41BFE;
 Thu,  9 Jan 2025 00:27:39 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 13C2EC4CED3;
 Thu,  9 Jan 2025 00:29:25 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c91ea98d-ce20-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1736382567;
	bh=IIqr0lHZ77ykQRBHLyibMtNl34jVLEAjKiUPfwxxQSQ=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=Kufbni08r2/VvD6QfrFueMrZJ8iTVIkprKXA8l4w6I5n/IKUBTuKoOpsAPSrHZfsc
	 9EfqEc5c9pzVAHZUi6/eGBW2NFL0cawviKERo4HrJ3hqKBL5OameIw89tzOMRxq+uP
	 bBKKFgtF79xM1KcF3OkHzYzPNensBpSwg27UJjsWWahNgU+AfRXBZYqkoz/ScV9kpZ
	 86JvhH2/VucOb6oDpTxluj1NgSFn8l+IlJBrzfHBMk4J4raeoB3lJ/TVE6zHDJ3I9M
	 AVSDaM3jr7Galq0vf0sQkuNqdOUm+OWcQZ9tLW4wCvW8ARyNnLub3Tc0FVpNjFNRhL
	 3u0c5PqyKPOfg==
Date: Wed, 8 Jan 2025 16:29:24 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Denis Mukhin <dmkhn@proton.me>
cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
    Jan Beulich <jbeulich@suse.com>, 
    Stefano Stabellini <sstabellini@kernel.org>, dmukhin@ford.com, 
    xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, 
    Julien Grall <julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>, 
    Michal Orzel <michal.orzel@amd.com>
Subject: Re: [PATCH v2 20/35] xen/console: introduce console_owner_domid()
In-Reply-To: <m5iIn0DzBY1VE3oW8MMk5aJD5yovtFe2u7eorkGQVf0czY2gzIYl9k2aKmrdyh1AG6YAgyasVn86Js-vUQyudqjHY7bRYE1hXdCkdFVF0U8=@proton.me>
Message-ID: <alpine.DEB.2.22.394.2501081615050.133435@ubuntu-linux-20-04-desktop>
References: <20241205-vuart-ns8250-v1-20-e9aa923127eb@ford.com> <8a5a5a0f-72b0-4336-b0d2-142254319242@suse.com> <alpine.DEB.2.22.394.2501061046060.133435@ubuntu-linux-20-04-desktop> <c39c0c6f-2fab-46e8-9563-c91fe890e87f@suse.com>
 <alpine.DEB.2.22.394.2501071533060.133435@ubuntu-linux-20-04-desktop> <a2fa92ff-a5fb-4adc-86aa-1481ebec92fe@suse.com> <Z34xhkNu5YLyEzut@macbook.local> <121ae72e-6229-40a4-8b9f-4f8b0764b712@suse.com> <Z344xgqtpNZIDxHD@macbook.local>
 <m5iIn0DzBY1VE3oW8MMk5aJD5yovtFe2u7eorkGQVf0czY2gzIYl9k2aKmrdyh1AG6YAgyasVn86Js-vUQyudqjHY7bRYE1hXdCkdFVF0U8=@proton.me>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-610742799-1736382567=:133435"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-610742799-1736382567=:133435
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Wed, 8 Jan 2025, Denis Mukhin wrote:
> On Wednesday, January 8th, 2025 at 12:35 AM, Roger Pau Monné <roger.pau@citrix.com> wrote:
> > On Wed, Jan 08, 2025 at 09:13:02AM +0100, Jan Beulich wrote:
> > > On 08.01.2025 09:04, Roger Pau Monné wrote:
> > > > On Wed, Jan 08, 2025 at 08:28:32AM +0100, Jan Beulich wrote:
> > > > > On 08.01.2025 00:40, Stefano Stabellini wrote:
> > > > > > On Tue, 7 Jan 2025, Jan Beulich wrote:
> > > > > > > On 06.01.2025 19:48, Stefano Stabellini wrote:
> > > > > > > > On Mon, 6 Jan 2025, Jan Beulich wrote:
> > > > > > > > > On 04.01.2025 05:15, Denis Mukhin wrote:
> > > > > > > > > > On Tuesday, December 10th, 2024 at 11:28 PM, Jan Beulich jbeulich@suse.com wrote:
> > > > > > > > > > > On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
> > > > > > > > > > > 
> > > > > > > > > > > > From: Denis Mukhin dmukhin@ford.com
> > > > > > > > > > > > 
> > > > > > > > > > > > console_owner_domid() is introduced to obtain the "console owner" domain ID.
> > > > > > > > > > > > 
> > > > > > > > > > > > The call is used in NS8250 emulator to identify the case when physical xen
> > > > > > > > > > > > console focus is owned by the domain w/ NS8250 emulator, in which case,
> > > > > > > > > > > > messages from guest OS are formatted w/o '(XEN)' prefix.
> > > > > > > > > > > 
> > > > > > > > > > > Such messages ought to be processed through guest_printk(), which wants a
> > > > > > > > > > > domain pointer, not a domid_t anyway. Plus isn't that going to be
> > > > > > > > > > > current->domain anyway at the callsite, eliminating the need for such a
> > > > > > > > > > > 
> > > > > > > > > > > helper altogether?
> > > > > > > > > > 
> > > > > > > > > > If the current domain is owning the physical console and printing, say, Linux
> > > > > > > > > > login prompt, there's no need to add "(XEN)" for every printout; adding timestamps
> > > > > > > > > > can be disabled from Xen command line.
> > > > > > > > > 
> > > > > > > > > Surely there shouldn't be (XEN), but without (d<N>) it'll be ambiguous in a log
> > > > > > > > > which domain a message came from. As long as only Dom0 messages are left un-
> > > > > > > > > prefixed, that's likely fine. Yet as soon as multiple domains can issue such
> > > > > > > > > messages (and have console "focus") I think the prefix needs to be there.
> > > > > > > > 
> > > > > > > > It looks like we are aligned on the desired behavior,
> > > > > > > 
> > > > > > > Hmm, no, I don't think we are. I don't ...
> > > > > > > 
> > > > > > > > but for clarity,
> > > > > > > > see https://marc.info/?l=xen-devel&m=173405161613716, also copy/pasted
> > > > > > > > here:
> > > > > > > > 
> > > > > > > > I think we should provide a consistent behavior across architectures.
> > > > > > > > The current behavior with vpl011 and dom0less on ARM is the following:
> > > > > > > > 
> > > > > > > > - no prefix for Dom0 output
> > > > > > > > - DOM$NUM for DomUs when not in focus, otherwise no prefix
> > > > > > > 
> > > > > > > ... view this model as a desirable one. It leaves room for ambiguity.
> > > > > > 
> > > > > > Adding a few more people in CC for feedback.
> > > > > > 
> > > > > > My priority is to keep the architectures aligned. It might be OK to
> > > > > > change output format, but then let's do it uniformly on ARM as well.
> > > > > > 
> > > > > > Jan, please clarify what you think would be better than the above. Is it
> > > > > > the following? I don't think I understood your preference.
> > > > > > 
> > > > > > - DOM$NUM for Dom0 and DomUs when not in focus, otherwise no prefix
> > > > > 
> > > > > No, I mean like we have it with guest_printk() today. (XEN) for Xen's
> > > > > own messages, (d<N>) for ordinary domains' ones, and no prefix
> > > > > exclusively for the hardware/control domain. What is best to do when
> > > > > hardware and control domains are distinct I'm uncertain - I'd be
> > > > > inclined to suggest that the hardware domain then stay the one without
> > > > > any prefix.
> > > > 
> > > > One concern I have with this approach is whether the addition of the
> > > > (d<N>) prefixes will skew output of interactive applications. So far
> > > > the prefix is added to output from all domains different than dom0
> > > > because the console is not interactive for them, and hence no input
> > > > can be consumed.
> > > 
> > > Hmm, that's an aspect I have to admit I didn't think of.
> > > 
> > > > If that changes however, and domains different than dom0 can get input
> > > > from the Xen console then I wonder how much the added prefix will skew
> > > > output. Another possible option would be to not print the prefix for
> > > > the domain that has the console input assigned (current target), and
> > > > print it for all other domains (even for dom0 when not in focus).
> > > 
> > > That's largely what aiui was proposed. My extra requirement there would
> > > then be that we make sure a log message is always emitted when console
> > > focus shifts, so it's possible to identify the owner for any part of
> > > the log.
> > 
> > 
> > Indeed, printing console input shifting should be a requirement
> > regardless of how we decide to print the prefix.
> 
> Console input focus switch is indicated after pressing Crtl+aaa, e.g.:
> [[
> ...
> (XEN) [15359.353038] *** Serial input to Xen (type 'CTRL-aaa' to switch input)
> (XEN) [15361.176754] *** Serial input to DOM0 (type 'CTRL-aaa' to switch input)
> (XEN) [15711.297202] *** Serial input to DOM1 (type 'CTRL-aaa' to switch input)
> ...
> ]]


Roger, Jan, you should use Xen Dom0less more :-) This is the way it
already works on ARM. Let me expand on my earlier message that was too
terse.

At boot time, Xen prints messages with the (XEN) prefix as usual:

(XEN) Brought up 4 CPUs

When Dom0 starts, it has not prefix (and has input by default):

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]

When a DomU starts, it has the following prefix (and doesn't have
input):

(XEN) DOM1: [    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]


Eventually, both Linuxes finish booting, you can login into Dom0 as
usual. Messages from Dom1, if any, are still printed with (XEN) DOM1 as
prefix.

You can switch input to Dom1 with Ctrx-aaa, the same way that you do
today to switch between Xen and Dom0. Xen prints a message:

(XEN) *** Serial input to DOM1 (type 'CTRL-a' three times to switch input)

Now, as you type, you send characters to Dom1. And Dom1 doesn't have the
DOM1 prefix any longer, while it is still has (XEN) because the message
is printed by Xen on behalf of the domain:

(XEN) / # echo hello world
(XEN) hello world

If Dom0 prints anything in the backgrounds, it shows without prefixes:

hello world from dom0

If another domain, dom2, prints anything in the background, it shows
with (XEN) DOM2 prefix:

(XEN) DOM2: hello from dom2

I think it makes sense to be consistent across architectures and we
should default to the same behavior on x86 too. If we want to make
improvements, the one thing I could potentially see changing is adding a
DOM0 prefix to Dom0 messages when Dom0 does not have input. If we do
that, let's do it on both ARM and x86 architectures.

Cheers,
Stefano
--8323329-610742799-1736382567=:133435--


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 03:13:46 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 03:13:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867789.1279342 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVizA-000083-22; Thu, 09 Jan 2025 03:13:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867789.1279342; Thu, 09 Jan 2025 03:13:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tViz9-00007r-VW; Thu, 09 Jan 2025 03:13:27 +0000
Received: by outflank-mailman (input) for mailman id 867789;
 Thu, 09 Jan 2025 03:13:26 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=eYg4=UB=invisiblethingslab.com=marmarek@srs-se1.protection.inumbo.net>)
 id 1tViz8-00006B-Ar
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 03:13:26 +0000
Received: from fout-b2-smtp.messagingengine.com
 (fout-b2-smtp.messagingengine.com [202.12.124.145])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id aeb9fdde-ce37-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 04:13:23 +0100 (CET)
Received: from phl-compute-08.internal (phl-compute-08.phl.internal
 [10.202.2.48])
 by mailfout.stl.internal (Postfix) with ESMTP id 76D671140115;
 Wed,  8 Jan 2025 22:13:21 -0500 (EST)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-08.internal (MEProxy); Wed, 08 Jan 2025 22:13:21 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 8 Jan 2025 22:13:18 -0500 (EST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: aeb9fdde-ce37-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm2; t=1736392401;
	 x=1736478801; bh=cR6ccP5DFYB7kn+Faf0luNzEduPpGXKTNSRDekWDv3c=; b=
	NwIEOslt+RQZPmtHMJY/DRbg4wBDysINA5Yn+oGTQ4aCtaxCt4tCyukBse+0lTqW
	QOjXQjC9fTeVbnWX226KkO1vHaVwp+/mCr11kXCvJdlCIY78xV+MmKMzs8H9tAMm
	OvEGDEHAUHZvQdpr1m+SxOY47Kn1s9aXKmZ4awRaGZhdgF3GwmHGbHykot9fKW+P
	5pJIs+2PY8CD8N00KYDP5JUZlsOnipDoZh+P9tVwd5R09iGBGX9yhM/dOe5lyKWx
	cgXS86q09J3/T8d0utHYOTdUXfC+gwnchv/9uEGCoblwza6ePQQMVzbFCnLDfLCT
	U5fa1BYO5tECsWnHzJZBIg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:subject:subject:to
	:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=
	1736392401; x=1736478801; bh=cR6ccP5DFYB7kn+Faf0luNzEduPpGXKTNSR
	DekWDv3c=; b=CLxVdFPH3wllyngzUCs+it0uNrlH1ZQQhs/1Fo7JrWHD9PEiXFV
	IEy+vG4QWlcnWAQcy6aKrpnZU21GELTZcIOxVjWLQvgoBw45Su5xYPWKX+9ZUhxz
	ruWr+Pz10o+abmhHkBOKAgbCXM07hFi/6Zbkr1NjFkcrQ5pc39vlO9xflyoOnvqd
	Ah1D2v8gdjTOKik2whd9QSqkCJqtPAg8J9URFWTbBxcx2VpCvqb4KUYwvwoamUNs
	ExRuxN63HAMeDiYfkeFHYf7NbFcGX9J+glfd7vSBrVZpzgwb7Xb1Y3vb4JqEMMCe
	TGF7Wm6xKJPaFudCNHdl5WFo+Z5pZVMzIfw==
X-ME-Sender: <xms:0D5_Z5jciJsjkjxlEW-J6nKXEUEHRr9SfKJ7qvQmYv8yRxWG0I2orQ>
    <xme:0D5_Z-CYjKMWp4wwwWooYsBuqhTxhsz1iecqrAX-XkxtH8TwEtQF5KE5l0u-tWLur
    3Lv_JeP4KSOhA>
X-ME-Received: <xmr:0D5_Z5GvFhpo1BLXNqriMnT9NmCrfP-siTtAUpA4Bgw_e0ObRC1tbEZvqUrng6dGMJhSFnQpa-aJU1VhtnOfnX4O92OUEAcjRw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrudeghedgheeiucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
    rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
    htshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtjeen
    ucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomh
    grrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggft
    rfgrthhtvghrnhepueekteetgefggfekudehteegieeljeejieeihfejgeevhfetgffgte
    euteetueetnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucevlhhushhtvghrufhi
    iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvhhish
    hisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopedutddpmhhouggv
    pehsmhhtphhouhhtpdhrtghpthhtohepthgvugguhidrrghsthhivgesvhgrthgvshdrth
    gvtghhpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgv
    tghtrdhorhhgpdhrtghpthhtoheprghnughrvgifrdgtohhophgvrhefsegtihhtrhhigi
    drtghomhdprhgtphhtthhopehjsggvuhhlihgthhesshhushgvrdgtohhmpdhrtghpthht
    ohepjhhulhhivghnseigvghnrdhorhhgpdhrtghpthhtohepshhsthgrsggvlhhlihhnih
    eskhgvrhhnvghlrdhorhhgpdhrtghpthhtoheprhhoghgvrhdrphgruhestghithhrihig
    rdgtohhmpdhrtghpthhtoheplhhukhgrshiisehhrgifrhihlhhkohdrphhlpdhrtghpth
    htohepughpshhmihhthhesrghpvghrthhushhsohhluhhtihhonhhsrdgtohhm
X-ME-Proxy: <xmx:0D5_Z-Ry9FksaEFI8JORpLUUzhay7-zs2_QoZeWwsZH-AbWg9wPzpw>
    <xmx:0D5_Z2yHwcpVqLnXiVnhXxcaRs-vb6DV091HdrxquSD1W1PA3nNFZA>
    <xmx:0D5_Z05NiDTuQImtMMJ8NGH98bJxw8qXb6vZsrDp_aaClSaPE98OMw>
    <xmx:0D5_Z7yPAi4xxNfNY2CWj3Z0FfzDfkBdrh8-PkVV_YJKrhWVzEjyZg>
    <xmx:0T5_Z7rMiGtrMZoFnWft8fCqyXLVIzi5qkb9XsQhZ5SvhKQqrpfYV4YX>
Feedback-ID: i1568416f:Fastmail
Date: Thu, 9 Jan 2025 04:13:15 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Teddy Astie <teddy.astie@vates.tech>
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>,
	Lukasz Hawrylko <lukasz@hawrylko.pl>,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Mateusz =?utf-8?B?TcOzd2th?= <mateusz.mowka@intel.com>
Subject: Re: [XEN RFC PATCH v4 0/5] IOMMU subsystem redesign and PV-IOMMU
 interface
Message-ID: <Z38-y9xR-6C_sARJ@mail-itl>
References: <cover.1730718102.git.teddy.astie@vates.tech>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="2eaxd8hbGHv9qt/u"
Content-Disposition: inline
In-Reply-To: <cover.1730718102.git.teddy.astie@vates.tech>


--2eaxd8hbGHv9qt/u
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Thu, 9 Jan 2025 04:13:15 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Teddy Astie <teddy.astie@vates.tech>
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>,
	Lukasz Hawrylko <lukasz@hawrylko.pl>,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Mateusz =?utf-8?B?TcOzd2th?= <mateusz.mowka@intel.com>
Subject: Re: [XEN RFC PATCH v4 0/5] IOMMU subsystem redesign and PV-IOMMU
 interface

On Mon, Nov 04, 2024 at 02:28:38PM +0000, Teddy Astie wrote:
> This work has been presented at Xen Summit 2024 during the
>   IOMMU paravirtualization and Xen IOMMU subsystem rework
> design session.
>=20
> Operating systems may want to have access to a IOMMU in order to do DMA
> protection or implement certain features (e.g VFIO on Linux).
>=20
> VFIO support is mandatory for framework such as SPDK, which can be useful=
 to
> implement an alternative storage backend for virtual machines [1].
>=20
> In this patch series, we introduce in Xen the ability to manage several
> contexts per domain and provide a new hypercall interface to allow guests
> to manage IOMMU contexts.
>=20
> The VT-d driver is updated to support these new features.
>=20
> [1] Using SPDK with the Xen hypervisor - FOSDEM 2023
> ---
> Changed in v2 :
> * fixed Xen crash when dumping IOMMU contexts (using X debug key)
> with DomUs without IOMMU
> * s/dettach/detach/
> * removed some unused includes
> * fix dangling devices in contexts with detach
>=20
> Changed in v3 :
> * lock entirely map/unmap in hypercall
> * prevent IOMMU operations on dying contexts (fix race condition)
> * iommu_check_context+iommu_get_context -> iommu_get_context and check fo=
r NULL
>=20
> Changed in v4 :
> * Part of initialization logic is moved to domain or toolstack (IOMMU_ini=
t)
>   + domain/toolstack now decides on "context count" and "pagetable pool s=
ize"
>   + for now, all domains are able to initialize PV-IOMMU
> * introduce "dom0-iommu=3Dno-dma" to make default context block all DMA
>   (disables HAP and sync-pt), enforcing usage of PV-IOMMU for DMA
>   Can be used to expose properly "Pre-boot DMA protection"
> * redesigned locking logic for contexts
>   + contexts are accessed using iommu_get_context and released with iommu=
_put_context
>=20
> TODO:
> * add stub implementations for bissecting needs and non-ported IOMMU impl=
ementations
> * fix some issues with no-dma+PV and grants
> * complete "no-dma" mode (expose to toolstack, add documentation, ...)
> * properly define nested mode and PASID support

Hi,

I finally got time to try this revision (sorry it took so long!). My
goal was to test it this time with some HVM domU too. I didn't get very
far...

Issues I hit:

1. AMD IOMMU driver is not converted (fails to build), for now disabled
   CONFIG_AMD_IOMMU.
2. PV shim build fails (linker fails to find p2m_add_identity_entry
   symbol referenced from iommu.c)
3. Xen complains on boot about missing endbr64 (surprisingly, it didn't
   exploded):

    (XEN) alt table ffff82d0404234d8 -> ffff82d040432d82
    (XEN) altcall iommu_get_max_iova+0x11/0x30 dest iommu.c#intel_iommu_get=
_max_iova has no endbr64
    (XEN) altcall context.c#iommu_reattach_phantom+0x30/0x50 dest iommu.c#i=
ntel_iommu_add_devfn has no endbr64
    (XEN) altcall context.c#iommu_detach_phantom+0x25/0x40 dest iommu.c#int=
el_iommu_remove_devfn has no endbr64
    (XEN) altcall iommu_context_init+0x27/0x40 dest iommu.c#intel_iommu_con=
text_init has no endbr64
    (XEN) altcall iommu_attach_context+0x3c/0xd0 dest iommu.c#intel_iommu_a=
ttach has no endbr64
    (XEN) altcall context.c#iommu_attach_context.cold+0x1d/0x53 dest iommu.=
c#intel_iommu_detach has no endbr64
    (XEN) altcall iommu_detach_context+0x37/0xa0 dest iommu.c#intel_iommu_d=
etach has no endbr64
    (XEN) altcall iommu_reattach_context+0x95/0x240 dest iommu.c#intel_iomm=
u_reattach has no endbr64
    (XEN) altcall context.c#iommu_reattach_context.cold+0x29/0x110 dest iom=
mu.c#intel_iommu_reattach has no endbr64
    (XEN) altcall iommu_context_teardown+0x3f/0xa0 dest iommu.c#intel_iommu=
_context_teardown has no endbr64
    (XEN) altcall pci.c#deassign_device+0x99/0x270 dest iommu.c#intel_iommu=
_add_devfn has no endbr64

4. Starting a HVM domU with PCI device fails with:

    libxl: libxl_pci.c:1552:pci_add_dm_done: Domain 1:xc_assign_device fail=
ed: No space left on device
    libxl: libxl_pci.c:1875:device_pci_add_done: Domain 1:libxl__device_pci=
_add failed for PCI device 0:aa:0.0 (rc -3)
    libxl: libxl_create.c:2061:domcreate_attach_devices: Domain 1:unable to=
 add pci devices

I didn't change anything in the toolstack - maybe default context needs
to be initialized somehow? But the docs suggest the default context
should work out of the box. On the other hand, changelog for v4 says
some parts are moved to the toolstack, but I don't see any changes in
tools/ in this series...

FWIW The exact version I tried is this (this series, on top of staging +
qubes patches):
https://github.com/QubesOS/qubes-vmm-xen/pull/200
At this stage, dom0 kernel didn't have PV-IOMMU driver included yet.

Full Xen log, with some debug info collected:
https://gist.github.com/marmarek/e7ac2571df033c7181bf03f21aa5f9ab

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

--2eaxd8hbGHv9qt/u
Content-Type: application/pgp-signature; name="signature.asc"

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmd/PssACgkQ24/THMrX
1ywr9wf/Qv4RzieRjyc+zxLq8Klw4GrZRFE7/iQyidtypTBufGCju0g3JVwROHpC
p1C3+NL08uNdzwzxbqWu9gfj0J6pHWIZRlkSEMTi7rGkAXt0t6oU5LEAPMQTMc+g
tM5koEKqemkMrdknlmr2wKEfLEZaok73yjj2KEMCG4Fq6wx0oc/TpsM+JcpcY8jt
wofvIJQccAoRi2P9agLySXE0JlVWyssnCI2kkVhezc0U8wmYnPXOKZIbqNNWh9FH
EYmvRsysKdA/WuWsc0kM+81lfUvqA1F36DL0NiA2HoWBz9mwAwPdNJhKWlcFACpb
U0evuzJtKE0OBc9+FRvY1EkE4lmbMw==
=1XLc
-----END PGP SIGNATURE-----

--2eaxd8hbGHv9qt/u--


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 07:45:04 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 07:45:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867811.1279353 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVnDm-0004yt-70; Thu, 09 Jan 2025 07:44:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867811.1279353; Thu, 09 Jan 2025 07:44:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVnDm-0004ym-3P; Thu, 09 Jan 2025 07:44:50 +0000
Received: by outflank-mailman (input) for mailman id 867811;
 Thu, 09 Jan 2025 07:44: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
 <SRS0=U+x7=UB=arm.com=Bertrand.Marquis@srs-se1.protection.inumbo.net>)
 id 1tVnDj-0004yg-Vh
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 07:44:48 +0000
Received: from OSPPR02CU001.outbound.protection.outlook.com
 (mail-norwayeastazlp170130007.outbound.protection.outlook.com
 [2a01:111:f403:c20f::7])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 98a7bffd-ce5d-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 08:44:46 +0100 (CET)
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by DB9PR08MB6490.eurprd08.prod.outlook.com (2603:10a6:10:25a::7) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8335.11; Thu, 9 Jan
 2025 07:44:43 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a%4]) with mapi id 15.20.8335.011; Thu, 9 Jan 2025
 07:44:43 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 98a7bffd-ce5d-11ef-a0df-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Y8HbgAQunI7+T5mXw1NuM/UqMsWnosqoS5OtL4MNd7Kh8susnS5VfI3sRxRdHjoAgrEYWKqC+qqgDX18yBTmIG54odRTT+vEAdalwY4SmXmPBLf87VtOAcLmpiLkJLzD0KkLuZ/g6z8/omGopocGzZ3WzTShHG2VGDyFcubRrXwk3ci1ukh1VEhdQPTs1UQqHs0JlOI94n0T6AbBytIM3UkhdOXqBM0dlYZUiiWRuMIuZ5adEeVT0qpvn2tceX81Rvp3iR1c4c7eQWP+0q9H6GqR0iZBLXQrtUtWlFFQqCE/1c58smGlTlR7fMLZUW6skWMEZOZ3YyH4YG4blp68SA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=fH+VKwlzw0iKMVEqVDynbAlT+7oOjEXG0z+zF6p+wA0=;
 b=ynJMh9EYvpNyQ5OMdM8CpXPdryvRc5n7a75UZdXnVKrhsxh8BuYPBAvIF0DCKBwX3YaZBpbVts45xvV1W/TyiAMZ868iC1wY0W7CaHuK/xRQwG6CdrCA20T4c9RpmY+4tvjFtNz3Gnf+ODk64MHJj14fKMX8NOqC2sqOSxM94XQz2iBwpOkF5LzAoqpsRwlbfUMDqcLnR9unaYeVkZx+9lx7jm3CcUn3nWfqmfoJzChZQxTLgJ+ovArIAwMwcHvZ+v8ljennC2mk73LvSaomEGDqkYr9mMwf5mPt3HbAnamdMSM2/dTSUWIqWuvNHkAZqR9nLvw89tPnY/PxisKH9g==
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=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=fH+VKwlzw0iKMVEqVDynbAlT+7oOjEXG0z+zF6p+wA0=;
 b=SYFpw6vCPMXvb+jhq5MJUislitP2mHt3auIAG6d0gen6g9yqEXXbgMGNH6B90vS0mU7LMaZBosaJTlVrijKZnzsgUMLMGKBiOE9rDtJE44tV5Zs5aB6qohL6TfVFjU4UEiO7k/ZXaptRsKe0kbAxfeRXQi6vK2ZqpCmwBwM1Wmc=
From: Bertrand Marquis <Bertrand.Marquis@arm.com>
To: Stewart Hildebrand <Stewart.Hildebrand@amd.com>
CC: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Volodymyr Babchuk <volodymyr_babchuk@epam.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Michal Orzel
	<michal.orzel@amd.com>, Oleksii Kurochko <oleksii.kurochko@gmail.com>
Subject: Re: [PATCH v2] xen/arm: ffa: fix build with clang
Thread-Topic: [PATCH v2] xen/arm: ffa: fix build with clang
Thread-Index: AQHbYewebJ/QvtJc8k6NoHOEpj2W67MOEM2A
Date: Thu, 9 Jan 2025 07:44:43 +0000
Message-ID: <3340E928-64F9-4F31-BD6C-9ECA75A1E846@arm.com>
References: <20250108164054.338799-1-stewart.hildebrand@amd.com>
In-Reply-To: <20250108164054.338799-1-stewart.hildebrand@amd.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.200.121)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DB9PR08MB6588:EE_|DB9PR08MB6490:EE_
x-ms-office365-filtering-correlation-id: 7cf81317-40a2-41d6-df21-08dd30817b73
x-checkrecipientrouted: true
nodisclaimer: true
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|10070799003|1800799024|376014|366016|38070700018;
x-microsoft-antispam-message-info:
 =?us-ascii?Q?VTM28Nq75IpTbATTjBhMk4GRVUkzG5Vioti+blDoe60qebWFF0odUzu8sKnT?=
 =?us-ascii?Q?Gd0/+rtWoMXGckEEM1r6TwndpGkR3u7wERdBnRXoNNGdHsS1QW6uooVH39aY?=
 =?us-ascii?Q?NkTpA5cxAzzybBTCnKPJ3cNkub0utEXOVhZPjY+bX9jzI9vMt/4XNpQuxjVW?=
 =?us-ascii?Q?aSrI4DKvWOpzSzwkAPOoL2UzKOoYgsJ8ORZqJYIbcTn51fgGhAUdyCDAnLta?=
 =?us-ascii?Q?3eH9WRIxBkHkTX2n+XqqsAYDRcKpS11rLMnsk3FAfUubqHYMYrOHEXCmzUSh?=
 =?us-ascii?Q?soOnQmCOBU1RRLpw7pB69db/3IC48op+i++wrm09h8gtclWNyrt0yvhPICG/?=
 =?us-ascii?Q?QN9Yj4cY9GU/BQS/GFs9grRAwDw0AbkKRVU1uWleel0fEMAdS9ATxxVLUKWM?=
 =?us-ascii?Q?aJtvhYBrXy4vJHgPEcpHDfia290vKTUcuEaSdSivF2+p23vP7zt6iHCZ5kdY?=
 =?us-ascii?Q?U+mt/Zr0QyEjHj3Hj9DZt8yxa9Ej4C1FQBsQmD5lfUJIeFEufGrp/rWRQ1lm?=
 =?us-ascii?Q?yjlBLVBL6ff0Bj3t/e/obPy5KoBdFbE3mLEhBmG6aekivMNEmhtlVjPxzUe+?=
 =?us-ascii?Q?CSkOtNz44ofoREvdq3u/5+4/kaS25/0JY8qbfYkevNGQuUIbf/OCy55hFd8e?=
 =?us-ascii?Q?3ByX8p4eo8pKaCNVKV1gM9cLlbxeLPlEkTSmHzxdbZ5af2ViOgn3FCcc2W/N?=
 =?us-ascii?Q?as1aVS8eNfiKW2te2yGPBy9T48NRAzTWdqoyTZi4pAqffsvE9/bm+UZT37S3?=
 =?us-ascii?Q?gX3+W+4hVXTdBBAnYb1SRXavC7qzAewb/FXOr2Zd3XqPScwVKawUMGeheuo6?=
 =?us-ascii?Q?onP0TlFeKYnq5FOO7tXWTQydRM+qt+wcznP3Y75xDwoaJ3TuPM4ePs6YHmOQ?=
 =?us-ascii?Q?tGWG1wvVRo/HPM4dQOftfv9I1L3U6nOv0aQWhiPgtkm3PmO5a0cXTopoKP4I?=
 =?us-ascii?Q?4EVK2yCXtcMHINu1hzcEW16yJnkOrZHD8x7a3UDuoGspRBQU8ic9ElVPSqGp?=
 =?us-ascii?Q?MDl8n/g9I5A9Ogo+wGl2N26liRlLbDr76XXqnpH/mNMRLlT8Y7A1/T+zGpi7?=
 =?us-ascii?Q?GBNY5DCqpfSHeW/l1nc/PTOXwyj+wcFqItCFAkixYgM2Lhd7rgDBRGQ02wpI?=
 =?us-ascii?Q?76c+3TM2nPopKv+uoco9T5dqNfhb9tBLt57jFJazu5nhJ3K8FNvC5/szyQUk?=
 =?us-ascii?Q?wJepAavPrbTlw2D8euK8A0QBwFnKmx3iBbaybqxsW5PbqLMi0sPSqDlbwIAC?=
 =?us-ascii?Q?K0oWCeMlXhrjYV3y2y0zZQNvy/E47eoxXrAM4zmURPoUYl9n0Gwlzj4Nz8oF?=
 =?us-ascii?Q?Rni+EkOKI+YenKhqoplw7msWCm/ZB0s2JbFVjMUw8EgGDsWsI5SkoVpjYPIM?=
 =?us-ascii?Q?ptyUFaZaJ+07PKng6V0UsnGSBf5zlMd3W3SCTEu/vPbDSlstcaH+SIogz+GD?=
 =?us-ascii?Q?tah2zbKAlF0+6X3qruDvScBERc0rpvFG?=
x-forefront-antispam-report:
 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:(13230040)(10070799003)(1800799024)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?BHXy3MTaHLCwW4s025IHdbvqPJ2knbrsd6qQHGP90xbF9zYKqQOjMjymQET0?=
 =?us-ascii?Q?GYaHcikY3y8JonREUlNSsfuzFMuUiy31q9tQJ+s0DL1F/qJ4AU5ON8t2Qq9s?=
 =?us-ascii?Q?bmstMik9u3VOZ3mmpYy7LxUBi0jVndYYR6JMYDOdC0h2TpQGyumoliWy+p19?=
 =?us-ascii?Q?0ARa40zYQ4/eEgvVe8Yx52Sfuacho1/5VYvd/QJaweV4FAMAcI/h4zKfut/T?=
 =?us-ascii?Q?g1zlA2eaWRgmmrHw990A6YcHi/HEcFXrRUp8VIA0g0SG9zSwK8kR6C0CWuQE?=
 =?us-ascii?Q?nbBTnahTGxaPpJmwfGiNzgYzY/SXOShevGMM1gDdgDuHzqOh2hMhZtxktpTq?=
 =?us-ascii?Q?JWrFH+/BJEBFAg74I8ZGwXZ3DpYdpIjhDBRHjlsTLaO/TsCaJeFPhP33xzR4?=
 =?us-ascii?Q?CKte3OLKjAagnIBoHW71+aMgIyHkIGAxe6cnLTudm1dMSM2eeUNL+Zn6eJjW?=
 =?us-ascii?Q?gnsCZKw3vkWc3seK9SC0hCHE71ZRs1csjcf2r5WOVh3Ir3ei37j7GMvP0vr7?=
 =?us-ascii?Q?0vPPUXJgzTMU5cE97UgVLiCnZNwVspcADZfL34Mcb3+6KPKkLGWTyk/aX0ht?=
 =?us-ascii?Q?JB43oQhPeLs/IO8rcS2ChtqhAv5dKyAHmyDLu2cCrADojicjLLut79GmC3ZI?=
 =?us-ascii?Q?13znDNJ4+ygNKIsum1sKDad71XE9u3rn4wbRYmS85ofPEVM4S82fnMQhPthG?=
 =?us-ascii?Q?4lsBB7HSPQ6vgu+veYLHWW1odk0aaQ3DjqEaNAmBArwBlcO1ETY6LkVetxrE?=
 =?us-ascii?Q?uR5LvhmtuRv4m0hplJmPelvFBMb9gFBN70nucJfpiuL5absffLStxZ07Yz7G?=
 =?us-ascii?Q?eKJmdRwbN6ckvmVLDhbKbi6gPwGI5imGEEbW8VGoM0ybanvDZM1GJpnDy9wU?=
 =?us-ascii?Q?rGuSemsy9MpuQet5xuFQI3PVUFIVkL2II8PAbYNBP/b2SSWE5tEdmbrOc7Qg?=
 =?us-ascii?Q?/ynXCxptotSA5i5MO9TyHa/q5Rbw1omEKG8DY907LsN5OqBPZt5sS6el79xH?=
 =?us-ascii?Q?Mx7Yvd/R8DboHhq/lEnFsx+h0d9XGDWd8FU3wRziNh/+ZZtZW6jP6sYXC8jJ?=
 =?us-ascii?Q?QiH5YsR60TPKMbPbgRN+4A4JMZlreB0BmsRablUmS3OW0SWVeXFilyclJ47e?=
 =?us-ascii?Q?GXi3JmqhGzEevz/P0wexinrKSzPAs1mB0pOVTLYEfJEkminZd1QyuaxeF8sb?=
 =?us-ascii?Q?IBL8iJHCm/l0wy8LPAAqaETf4kBgsBPQKKBKJEVmwXywzmV7JNHKuQaF/Nmz?=
 =?us-ascii?Q?JAtWIsDmrSggCiGNq5nE3MrMO61uIMrvgmsNaAz/tDP51CgkfM5Hs577ehiF?=
 =?us-ascii?Q?EwDpppJNroS/ozzEhZRW74u9xgGNW6qKfcULULQasDqsWAuEs+/ZRPIR6fT0?=
 =?us-ascii?Q?DYmKuQnwAh7b2R9raN+oPPz/PzWZCKZ/uF6lGsBwteesydNyOB3YSmrZApzR?=
 =?us-ascii?Q?XQUilirFJqMka20YzlvVASwL4987nosI4nSQgVKtEhQZwj2ixSyk5XRc2Jre?=
 =?us-ascii?Q?Egsn3LYN/YzKvMnRtZPbwz8MYAsVvyWgpjHnQmBImlEeKaWXbi7iSQWSRlB2?=
 =?us-ascii?Q?NjYb++RpRl/3j/FfLDoIDBX+pRidbpwVMWFzWgnopbrnUZLszP+kyTz4aGnD?=
 =?us-ascii?Q?a76jh4j9rNl5EFnoSEHTQy+2vh+/nLkAM5Hr/bM6i2QafNgafw5psbfEbDb5?=
 =?us-ascii?Q?Qai+LQ=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <D40460A5477EB248BB0A84D2A65E7D6F@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DB9PR08MB6588.eurprd08.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7cf81317-40a2-41d6-df21-08dd30817b73
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2025 07:44:43.6513
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: UtxxXnP+iCMQUdIqa85nOO24iPfeMjvTMYZM1pKnP6vptwQ8R2OpF8qLKbfVmnjxRk2jicCA8yYLOh+PzIm8jNcbu62hezUfqRD2/nTnhZY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR08MB6490

Hi Stewart,

> On 8 Jan 2025, at 17:40, Stewart Hildebrand <Stewart.Hildebrand@amd.com> =
wrote:
>=20
> Clang 16 reports:
>=20
> In file included from arch/arm/tee/ffa.c:72:
> arch/arm/tee/ffa_private.h:329:17: error: 'used' attribute ignored on a n=
on-definition declaration [-Werror,-Wignored-attributes]
> extern uint32_t __ro_after_init ffa_fw_version;
>                ^
>=20
> The variable ffa_fw_version is only used in ffa.c. Remove the
> declaration in the header and make the definition in ffa.c static.
>=20
> Fixes: 2f9f240a5e87 ("xen/arm: ffa: Fine granular call support")
> Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>

Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>

Cheers
Bertrand

> ---
> v1->v2:
> * remove declaration and make definition static
> ---
> xen/arch/arm/tee/ffa.c         | 2 +-
> xen/arch/arm/tee/ffa_private.h | 1 -
> 2 files changed, 1 insertion(+), 2 deletions(-)
>=20
> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
> index 87775ed88ffd..3bbdd7168a6b 100644
> --- a/xen/arch/arm/tee/ffa.c
> +++ b/xen/arch/arm/tee/ffa.c
> @@ -72,7 +72,7 @@
> #include "ffa_private.h"
>=20
> /* Negotiated FF-A version to use with the SPMC, 0 if not there or suppor=
ted */
> -uint32_t __ro_after_init ffa_fw_version;
> +static uint32_t __ro_after_init ffa_fw_version;
>=20
> /* Features supported by the SPMC or secure world when present */
> DECLARE_BITMAP(ffa_fw_abi_supported, FFA_ABI_BITMAP_SIZE);
> diff --git a/xen/arch/arm/tee/ffa_private.h b/xen/arch/arm/tee/ffa_privat=
e.h
> index d441c0ca5598..c4cd65538908 100644
> --- a/xen/arch/arm/tee/ffa_private.h
> +++ b/xen/arch/arm/tee/ffa_private.h
> @@ -326,7 +326,6 @@ extern void *ffa_rx;
> extern void *ffa_tx;
> extern spinlock_t ffa_rx_buffer_lock;
> extern spinlock_t ffa_tx_buffer_lock;
> -extern uint32_t __ro_after_init ffa_fw_version;
> extern DECLARE_BITMAP(ffa_fw_abi_supported, FFA_ABI_BITMAP_SIZE);
>=20
> bool ffa_shm_domain_destroy(struct domain *d);
>=20
> base-commit: 70f5a875becc9444a959830b10a361982c31a366
> --=20
> 2.47.1
>=20



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 07:53:16 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 07:53:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867820.1279362 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVnLs-0006aJ-Vq; Thu, 09 Jan 2025 07:53:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867820.1279362; Thu, 09 Jan 2025 07:53:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVnLs-0006aC-TJ; Thu, 09 Jan 2025 07:53:12 +0000
Received: by outflank-mailman (input) for mailman id 867820;
 Thu, 09 Jan 2025 07:53:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=U+x7=UB=arm.com=Bertrand.Marquis@srs-se1.protection.inumbo.net>)
 id 1tVnLr-0006a6-I5
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 07:53:11 +0000
Received: from EUR05-AM6-obe.outbound.protection.outlook.com
 (mail-am6eur05on20614.outbound.protection.outlook.com
 [2a01:111:f403:2612::614])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c5427d88-ce5e-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 08:53:10 +0100 (CET)
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by VI0PR08MB11136.eurprd08.prod.outlook.com (2603:10a6:800:253::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8335.11; Thu, 9 Jan
 2025 07:53:05 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a%4]) with mapi id 15.20.8335.011; Thu, 9 Jan 2025
 07:53:05 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c5427d88-ce5e-11ef-a0df-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=PvkP8RQsnFYSmCS8OPuhWiLzhDRWmpdlPtxQiaSn+hSrwSdJBgTH6ZIC6ieg4kMh2ZWRrOZIV+OMlytLSKIdo4cJTXJ0nmYtzfGw3RpE6R3fxaAdaxPODcmSyKFBs0+wOIRZ1icMWdCoBumpFDAYNgVEkevJRpsofYoZW7/gHaqAsiul7CqERQd9h/Z5dOf0MYxgZTNP2ykcvJDc/zayWjTZ9L8mGGRrECKkAjBiW+MI11bWp5TFOBZNP+xvEVOHoBTnwOsourhAmy1vjEbT5JLZuuyHn9KsZFm1Lvf7Ote80PHtrz/krku4vffiRqKWsuFMwmIsflVH+LrDQ8lUEg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=+cRQigDE4+iPzNEumgllIKC6Jqr6JnmciTa3foKApCE=;
 b=nlc6baH/cutMrLP+aW66ZYSTcEg/IIZBeNkXTDyz/jRC1gyVB3EriFuWvFM8NB8iCVISta440e/OiIflghAqOFGOHl2d1YTGAV78PU7Mi9ATEZYVhZ3g65p8MmjgntoHa2VmhwJDbwhqmHdE0rz9lSgjFkuwMzvb1YsVaJ4GQV3uNTVnDkxN8k6c0UzxsBZ6ftufb+5TA+iEHHKqa52YnWDN/xJfANk0uR2dCl2ptwZkDJBvcJ7AbU1pHUZIk5ZJOuo+W0uZGrf2fQLzjYKvEgTucS6KytJvu6fBNgIlc6n3GcVmNwg8PQUHOOjoffvn0vWca9AA/rm9zDe4uUfSZg==
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=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=+cRQigDE4+iPzNEumgllIKC6Jqr6JnmciTa3foKApCE=;
 b=QHZw7fWfZs18R8HmzXcr3u1LcJqtLyJJ0pBjiHRUO69qc/cBGNPwGPRa8eKAZrooh9iuj5F4c+C4QZ+S5PNz8D5V4d1i77iuz6AH6c238QU/Lft9Pdlsrg15HA70RTvT+rcaXf4yli7WXenwrhlfAferSQ7uS9sGDZzfJL8teRw=
From: Bertrand Marquis <Bertrand.Marquis@arm.com>
To: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
CC: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Michal
 Orzel <michal.orzel@amd.com>, Stefano Stabellini <sstabellini@kernel.org>,
	Artem Mygaiev <artem_mygaiev@epam.com>
Subject: Re: [PATCH v4] docs: fusa: Add dom0less domain configuration
 requirements
Thread-Topic: [PATCH v4] docs: fusa: Add dom0less domain configuration
 requirements
Thread-Index: AQHbYe83ZG0syumJUEGH2kASpg58SrMOExqA
Date: Thu, 9 Jan 2025 07:53:05 +0000
Message-ID: <E21BDDA5-F268-4127-82FA-1BD58DD6028D@arm.com>
References: <20250108170304.2250917-1-ayan.kumar.halder@amd.com>
In-Reply-To: <20250108170304.2250917-1-ayan.kumar.halder@amd.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.200.121)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DB9PR08MB6588:EE_|VI0PR08MB11136:EE_
x-ms-office365-filtering-correlation-id: 1fe6496b-8a28-4541-04e2-08dd3082a6c3
x-checkrecipientrouted: true
nodisclaimer: true
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|376014|10070799003|366016|38070700018;
x-microsoft-antispam-message-info:
 =?us-ascii?Q?oQyQAGgrL/At302gt5w6mTwnL2HcMW2Om9r/to3kLjR+gwtbOpg5ZaW1iE0k?=
 =?us-ascii?Q?YMI/p6TdZjrBNy51mvHWpDhC/cCxyTHVQaarAyVC+lCgmFzAzyZWY65w+zvH?=
 =?us-ascii?Q?Ujj774kh7/4dfmzufKPoCy9dKWtnNx4H6ymdOSm4ZRvB/cbQcYuwc8jPb+O4?=
 =?us-ascii?Q?2I4OyXtPeCyG36IRLaGBysgs1wfTpyWFMG4hf0JmcLQ3iV/iTJMNzKbWQKhq?=
 =?us-ascii?Q?VqcuB1o1+S6zwqsrI8pADaF5LG5mCKSR27KGMVM66hjCCm865jMpBFF8IDBW?=
 =?us-ascii?Q?fT+zoWCPG1qHUCPg/1+1suszQRJ08zy47HJE8Sw2JmJaUv1QPxqUhqlGi2oh?=
 =?us-ascii?Q?xM9acMP3Sy+vb5WsKFt2QXWuq94OYq8U0HOqMS8dNSX0yY1C0Udvi5QULk5r?=
 =?us-ascii?Q?rC5VUCBOph2iEX62PsfxYUdGB4thzamhvqH8AikqxoK5twsDgGXIOhPAn4ER?=
 =?us-ascii?Q?JeoRmCZWaL0OO8I5WdQAHry61jdWD2KQLqj3I5V/i85gZW16TJ/fDwtyIyM6?=
 =?us-ascii?Q?61NwhdIYPCay1ClMgBRJIp22xBgO9xF3Z7iNaEZElDGdlKIj0wtcIzF0BhDw?=
 =?us-ascii?Q?SaptwRlRIuYMvloDf1/4N53NO7R1iCRAmn6RRZNLLC5wM6/gQQDdQhE6Xkjm?=
 =?us-ascii?Q?em/37t5KGYDHvnT2zzL7n8+YUb07BEHBWljXudrRQsOI12nYEHoT3GRh4IRD?=
 =?us-ascii?Q?phfRUyddc5dYhQHAYISwcxj4MntyEhVqwfDg/rEWxUsMZ8IgmqvXGLJ14buF?=
 =?us-ascii?Q?rcH2NrrdJDF7hV5gh6SruET9GdKRbYfTYv0gTxuu1q0KDf8DlcHvW4G3TXOb?=
 =?us-ascii?Q?xeEl67+H98qGGltxLHRAUyGfEBpnQOdEUDyOvsQGZlr5v51Pmwg/8tWmN/Na?=
 =?us-ascii?Q?rdoppAKeo4sa291RP8eCpC6S9pD04XZxBe1cZYNscGDjlNT8/utkgM4I6YJC?=
 =?us-ascii?Q?EwZqxVlyvtw9DH7iejCypAvMK5EhftNM+GbTWjaGr/At5+3nf/KdLcugBnbj?=
 =?us-ascii?Q?ac68LH3VCe02SlJP71duXpjbad3VIOzB3si8F8qVKrOkhBbh+gqdElLhvyey?=
 =?us-ascii?Q?Etc8pVGG0sMNb/MVEDZkmh7I5HR6WuwxUFAimxXstPpVK1iPwjIjEjzYKoDR?=
 =?us-ascii?Q?eWzjXO7diYZRdc/e3moEuxZNp45w0Ja+VRNMBpsDDrurmHjeolHW5S2LY5mE?=
 =?us-ascii?Q?ltcHIld+0EvTYTBl3eAKxcyQlMTr+9o15wvwPQSdbxlQv8qAcidueHVm6LV1?=
 =?us-ascii?Q?pPzCO+bmWqQASpv2jCu2+ImJBY/VTNk95SigdEX32bBRd10mQ14SKE+xjPgS?=
 =?us-ascii?Q?ZWQATBlQE4rULvIAXk6XDUPDxlFXgQ2mf1F7cRtATRtbYQSNeYsharPizCAr?=
 =?us-ascii?Q?t7jgx9IJrZ4FfDzjdh29bYFc0bwJrg0sLl7vr3LHaNQSUiqpBQ923BlRw2/R?=
 =?us-ascii?Q?Gnn7H70jnJdFtYUlhHbszjqdv3fFYicM?=
x-forefront-antispam-report:
 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:(13230040)(1800799024)(376014)(10070799003)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?me8+ud1KpfGs26UDdOgDYI7CzBPbm/GrZlCv/ykJ0wg7P+LLQUIWDudk7F4b?=
 =?us-ascii?Q?9ZhV+KBU5iEHjbmi77GyYdaQSUnpcISs/o5oXOJ3VlByV/W0xZzBtIULZEoD?=
 =?us-ascii?Q?c5du8PxaWh+df9HMFOjWnwYefjLZHFkImCi1VkaAhfUfZgNUZ93h3s9CAxcy?=
 =?us-ascii?Q?GB46N9xI9IzK+trXE4AviMG1re46dWzTnJoY6WyDfSRCuMvMP+qhDSusiLTc?=
 =?us-ascii?Q?wW5XTtfU5WpZTdrDnnLy94yNw+cUEU3ShoM43IKg7wrfBaojn1orLqNzZpaI?=
 =?us-ascii?Q?SDVKb5ypM/2OiO/JRBo3UmvEt1jhkUyp2cPDe4ulAbEo9424kTcoWuDPz4FN?=
 =?us-ascii?Q?cOErzN6HOBPDjYbeAjJKQyKPAC8YLvxFZkIoZptEW83P462iNgCXkbQDHt/C?=
 =?us-ascii?Q?cS4GgspG3iaPF+ROutga/3PP5fe4k41Dl8d96B9O+ZUv2A/1Yt5uyfLERmRZ?=
 =?us-ascii?Q?qEG6yWSmhw66a30efPxAxT4YC3i/8F/wJ4OkArWS1ZmBFiQwi1QWBxvsUC5J?=
 =?us-ascii?Q?HLP4RdFRlDynklC4fVwDYY5LC/PNVS3YjpqlDor6DNHMl1iaXFa6KCkdrI8/?=
 =?us-ascii?Q?3QLyVWpXAzXl2BbDTTxc1LG+bFXfbSVdotZRsaD9Jmyp/FqHQxmFdsewji5Z?=
 =?us-ascii?Q?ksYzvZNPe3foAIfQU9/A1I38c97sYDNPWIRtTU+XrZy8ogxUg6lmj7V30U6v?=
 =?us-ascii?Q?2A5txVKA4v9lm+yfKz198zJWyk884HScgqX8FTlCn/GzXotHu7PR5IIw9XRN?=
 =?us-ascii?Q?HntXC6R+k3LcABGZK5ER4akJE5qCer6n7u4XoB0Gt8yARPlX0hi6xmUQ6jYZ?=
 =?us-ascii?Q?VXaVj4KIQ2HNKMX5INW56pgn1zE9szmYUU6WnU2hzrnaVogiDqBQpMJSIQ0v?=
 =?us-ascii?Q?Iwn3Ebw0oYrjiWgntHkxlioxLY/j9dQPptnYlQNtVZOZYev/FgtK13LiDK9e?=
 =?us-ascii?Q?8d6ZwpTAZlOI4DqYsiJRZO2w6omSp/2OgcB255Qe7wv7RMDgQeU4OUml59To?=
 =?us-ascii?Q?GqRf4D5AMTZ8tWag3sifCk34E2dtusYt7q/fvinZ0kQ1FR7eTN3Y34Ypat9L?=
 =?us-ascii?Q?0AGiUGjIjSfyLHswE/pgCCWmJJLDqZ//a55QLlyOPhRj9SS40al7joV5YU8P?=
 =?us-ascii?Q?ILh8oMx/AxbDpsEHmQ+GTmoNLJBeaxf8VptDXtEwaKSh1uVMNw04FiAYG5Q1?=
 =?us-ascii?Q?PxY0fWuidibWzDJOC4pF47TXzbtFNPnnNB7LzrGblNtnVajfAImGifWrkBwc?=
 =?us-ascii?Q?3uu76TJ96O7wpY4FP04hwXuKBrVQnDhX9as/HB74S4KZRELML5VjV+QrPLao?=
 =?us-ascii?Q?oO+11OR0Ao5r3rIYCc2qQNSWDJsrY+9RmwfZkVMmzoNO684qGItloRZ1p6dE?=
 =?us-ascii?Q?7dyXh6y8epsHCcQclInk7BRMqdRlcOx+B1LFL5kLmDAxqYybM7FNCwjkJSO/?=
 =?us-ascii?Q?cpmOmF5QHryFHKrUEMlR2fKs+cXhv6MfC1rGU5eMEn5J5+RAg8rP1xYSYTAH?=
 =?us-ascii?Q?2x4XXJLWNtYF8aKjU0CC2GdiJxbOuzo9WgFjP45IL6DlYwCBviHJG3NgNVRo?=
 =?us-ascii?Q?1tuNIyWqFDrLyG9wmpTX7Y0PXh+xWT2vDYh0q0az4DY//6bI/esgMHiZ/POY?=
 =?us-ascii?Q?PkMtzgRLdpURr4KGa6fu+zXlylJMDHLZIFJRfmX4rSiNVXJi9u/jeQb+X1zo?=
 =?us-ascii?Q?7fxE2A=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3A20DF84A8D46C489773039FCB5F092B@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DB9PR08MB6588.eurprd08.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1fe6496b-8a28-4541-04e2-08dd3082a6c3
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2025 07:53:05.7585
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: idLxLco/B15ZBL5nUXn6duAE9tOZK4KdrL+69TrBToT+2rXYv1OplNjCkCyrxR1X7LuSn/Tmt3tQfzvG+ZdzhfaEV34dhCDGDh0oGswN4QM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR08MB11136

Hi Ayan,

This is a lot better.
I just have some minor phrasing comments after.

> On 8 Jan 2025, at 18:03, Ayan Kumar Halder <ayan.kumar.halder@amd.com> wr=
ote:
>=20
> From: Michal Orzel <michal.orzel@amd.com>
>=20
> Add requirements for dom0less domain creation.
>=20
> Signed-off-by: Michal Orzel <michal.orzel@amd.com>
> Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
> ---
> Changes from -
>=20
> v1 - 1. As the dom0less domain creation requirements specifies the dt pro=
perties
> for creating domains, it has been moved to product requirements. Product
> requirements define the interface Xen exposes to other domains.
>=20
> 2. For the requirements which introduces new terms (like grant table, etc=
), I
> have provided the definition as part of the comments.
>=20
> 3. Introduced new market requirements to specify that Xen can assign iome=
m and
> irqs to domains.
>=20
> 4. The design requirements will be added later.
>=20
> v2 - 1. Rephrased the requirements as suggested.
>=20
> 2. Split the product requirements into arm64 specific and common.
>=20
> 3. The arm64 specific requirements have arm64_ prefixed to their tag name=
s.
>=20
> 4. Grant table requirements have been dropped for now.
>=20
> 5. Added a market requirement to denote that Xen can support multiple sch=
edulers.
>=20
> 6. Updated index.rst as we have a new file ie product-reqs/reqs.rst.
>=20
> V3 - 1. Removed duplicate mention for 'Rationale'.
>=20
> 2. Fixed some of the descriptions as per the review comments.
>=20
> docs/fusa/reqs/index.rst                   |   1 +
> docs/fusa/reqs/market-reqs/reqs.rst        |  31 ++++
> docs/fusa/reqs/product-reqs/arm64/reqs.rst | 128 ++++++++++++++++-
> docs/fusa/reqs/product-reqs/reqs.rst       | 160 +++++++++++++++++++++
> 4 files changed, 318 insertions(+), 2 deletions(-)
> create mode 100644 docs/fusa/reqs/product-reqs/reqs.rst
>=20
> diff --git a/docs/fusa/reqs/index.rst b/docs/fusa/reqs/index.rst
> index 8a4dae6fb2..1088a51d52 100644
> --- a/docs/fusa/reqs/index.rst
> +++ b/docs/fusa/reqs/index.rst
> @@ -8,6 +8,7 @@ Requirements documentation
>=20
>    intro
>    market-reqs/reqs
> +   product-reqs/reqs
>    product-reqs/arm64/reqs
>    design-reqs/arm64/generic-timer
>    design-reqs/arm64/sbsa-uart
> diff --git a/docs/fusa/reqs/market-reqs/reqs.rst b/docs/fusa/reqs/market-=
reqs/reqs.rst
> index f456788d96..39b2714237 100644
> --- a/docs/fusa/reqs/market-reqs/reqs.rst
> +++ b/docs/fusa/reqs/market-reqs/reqs.rst
> @@ -47,3 +47,34 @@ Comments:
>=20
> Needs:
>  - XenProd
> +
> +Static VM definition
> +--------------------
> +
> +`XenMkt~static_vm_definition~1`
> +
> +Description:
> +Xen shall support assigning peripherals to various domains.

"various" here could be removed or replaced with "a domain" to be coherent =
with
the phrasing after.

> +
> +Rationale:
> +
> +Comments:
> +Peripheral implies an iomem (input output memory) and/or interrupts.
> +
> +Needs:
> + - XenProd
> +
> +Multiple schedulers
> +-------------------
> +
> +`XenMkt~multiple_schedulers~1`
> +
> +Description:
> +Xen shall provide different ways of scheduling virtual cpus onto physica=
l cpus.

different here is a bit imprecise.
how about:
Xen shall have configurable scheduling strategies of virtual cpus onto phys=
ical cpus.

The rest looks good.

Cheers
Bertrand



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 07:58:19 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 07:58:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867829.1279372 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVnQk-0007AX-HW; Thu, 09 Jan 2025 07:58:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867829.1279372; Thu, 09 Jan 2025 07:58:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVnQk-0007AQ-Ey; Thu, 09 Jan 2025 07:58:14 +0000
Received: by outflank-mailman (input) for mailman id 867829;
 Thu, 09 Jan 2025 07:58: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
 <SRS0=Pmh1=UB=bugseng.com=nicola.vetrini@srs-se1.protection.inumbo.net>)
 id 1tVnQi-0007AI-IH
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 07:58:13 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 77e41db3-ce5f-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 08:58:10 +0100 (CET)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 by support.bugseng.com (Postfix) with ESMTPA id 2DDD74EE0738;
 Thu,  9 Jan 2025 08:58:09 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 77e41db3-ce5f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1736409489; bh=OgbivrCiHo3rweuOIoES0Qt2H48OR3AsalfdoGE27aA=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=F0cO2BDupEKy02UvrkT98NdXSdkoOy7n9H/9dp9Vh26o1Q0KLUU1Gw0x66+9/dckX
	 3Kl7kPXOo4O7nvgVPHMHkDnbe8jMGrGpGcmuFFqYbaL2xsUIbCbaJA0fPz5v8g0I9b
	 gEKpk32oONm3J0NbZVEpne3w/DmxIbJlf0+OfgYNoUx/j+pvS+Z3erAb04p49znzOc
	 zDhO39Qjhv+uFTtGxQgSuxcFeJrrEXFV04O9/1CWTUKa5L9A6Mgqof/azLNPp1ZnQe
	 S3GOTzS3JnY9xE9QXigKAN5mUqeeCZIpz0axc5UU+3fj6aclNG3KgdtPwcRMZwRjh6
	 gwbiCDiiBBTYQ==
MIME-Version: 1.0
Date: Thu, 09 Jan 2025 08:58:09 +0100
From: Nicola Vetrini <nicola.vetrini@bugseng.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: Jan Beulich <jbeulich@suse.com>, Roger Pau Monne <roger.pau@citrix.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xenproject.org,
 consulting@bugseng.com
Subject: Re: [PATCH v2 1/2] x86/uaccess: rework user access speculative harden
 guards
In-Reply-To: <alpine.DEB.2.22.394.2501031617280.16425@ubuntu-linux-20-04-desktop>
References: <20241126093508.6966-1-roger.pau@citrix.com>
 <20241126093508.6966-2-roger.pau@citrix.com>
 <cf1f87d1-f616-4944-94fa-69a777249072@suse.com>
 <e3ec3dad28dc94436c0b330b2f995120@bugseng.com>
 <alpine.DEB.2.22.394.2501031617280.16425@ubuntu-linux-20-04-desktop>
Message-ID: <8e31daaf77216534c252d371a3251595@bugseng.com>
X-Sender: nicola.vetrini@bugseng.com
Organization: BUGSENG s.r.l.
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit

On 2025-01-04 01:20, Stefano Stabellini wrote:
> Hi Nicola, one question below
> 
> On Wed, 27 Nov 2024, Nicola Vetrini wrote:
>> > #define AMD_OSVW_ERRATUM(osvw_id, ...)  osvw_id, __VA_ARGS__, 0
>> >
>> > where we're using the C99 form rather than the GNU extension, and where
>> > hence __VA_ARGS__ would - by extrapolation of the Misra rule - need
>> > parenthesizing, when it isn't and can't be.
>> >
>> > Isn't it rather the case that variable argument macros need a more general
>> > deviation, if not an adjustment to the Misra rule? Extending the Cc list
>> > some ...
> 
> Nicola, if you look at the original patch:
> https://marc.info/?l=xen-devel&m=173261356716876
> 
> "The current guards to select whether user accesses should be 
> speculative
> hardened violate Misra rule 20.7, as the UA_KEEP() macro doesn't (and 
> can't)
> parenthesize the 'args' argument."
> 
> And the very first change in the patch is:
> 
> diff --git a/xen/arch/x86/include/asm/uaccess.h 
> b/xen/arch/x86/include/asm/uaccess.h
> index 2d01669b96..6b8150ac22 100644
> --- a/xen/arch/x86/include/asm/uaccess.h
> +++ b/xen/arch/x86/include/asm/uaccess.h
> @@ -24,9 +24,6 @@ unsigned int copy_from_unsafe_ll(void *to, const void 
> *from, unsigned int n);
>  void noreturn __get_user_bad(void);
>  void noreturn __put_user_bad(void);
> 
> -#define UA_KEEP(args...) args
> -#define UA_DROP(args...)
> -
>  /**
>   * get_guest: - Get a simple variable from guest space.
>   * @x:   Variable to store result.
> 
> 
> Do you think there is any way we could configure Eclair, with or 
> without
> a deviation, not to detect every use of UA_KEEP as violations?

I narrowed this violation down to a different treatment of the named 
variadic argument. Since the argument 'args' cannot be parenthesized as 
a regular argument could, the invocations of the 'UA_KEEP' cannot comply 
with the rule. Therefore, as an extension to the rule, ECLAIR currently 
ignores the use of '__VA_ARGS__' in a macro definition, but treats 
'args...' as a regular macro parameter name, hence the violation.

To be clear, these two definitions have the same semantics, but one 
shows a violation and the other doesn't

#define UA_KEEP(args...) args
#define UA_KEEP(...) __VA_ARGS__

I will update ECLAIR to treat the two forms as the same, so this patch 
can be dropped. If you think it's helpful I can send a patch spelling 
out this - arbitrary, but reasonable in my opinion - extension to the 
MISRA rule (which does not consider the implications related to the use 
of GNU exensions) so that contributors have a clear picture of the 
situation.

Thanks,
  Nicola

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 08:06:21 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 08:06:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867843.1279383 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVnYW-00013P-Cj; Thu, 09 Jan 2025 08:06:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867843.1279383; Thu, 09 Jan 2025 08:06:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVnYW-00013I-9X; Thu, 09 Jan 2025 08:06:16 +0000
Received: by outflank-mailman (input) for mailman id 867843;
 Thu, 09 Jan 2025 08:06: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
 <SRS0=wq9x=UB=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tVnYU-00013A-SI
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 08:06:14 +0000
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com
 [2a00:1450:4864:20::62a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 97969240-ce60-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 09:06:12 +0100 (CET)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-aaf3c3c104fso116678566b.1
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 00:06:12 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c9136297sm45520166b.91.2025.01.09.00.06.11
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 09 Jan 2025 00:06:11 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 97969240-ce60-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736409972; x=1737014772; 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=j89FAdSM2FhMmnRlCPQkfxGAPchvJJ41YGEB72TbuGc=;
        b=Ts0kt4eoI+/Da/tevDWYC4sEu3jlR8jTrmr1hkUqxpHwez/TUBvmIbuVvV/Naluyxe
         M62+TOZd+SOTedtAwBblOMKAe9of81ZssyY4C0qVDPM7OYGOWQOKJslL5oBPev0KrRRW
         MqX/DAU7rxJg8u+BRqe6WY5acCsFnnEITSYmw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736409972; x=1737014772;
        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=j89FAdSM2FhMmnRlCPQkfxGAPchvJJ41YGEB72TbuGc=;
        b=K6eViOMkgyBB2jBSii83KmRQh1p+EaSeog3vXp38s95HnfB0vKWRIT8Kv9bpSEzKcB
         2Qbp3GL0HrQIOu97fvWSn+xfXg7xkjda6KS88b4iJzQ300hkGThcg3/RQpu7yki4PC1t
         q8HPnXpxMJX0QclzpGc957J16WXR7dsBQH5J5gH/cYOwHBsu+butyDkVgWzJnpcTvpuR
         lZv3pN4bi9i+fEyGuE0sebj+ad4wn4Unf8VkrdMwVbOJDtY00yzv57e5YajiL6HYhJnO
         NgRcem7oRNbCFM6isJ25GUoDVnXk1TEW0HN7erMK784CuwWW4xQ8kxlgaP/F2Nt5jb4B
         CJ4Q==
X-Forwarded-Encrypted: i=1; AJvYcCVE5TQiRASFBBxud9UVp2O4TnaeyintP5hA8AMT1+P9+GLBBt2A4Z0eKF1xrcWTUj0T/NipbJTrNX0=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx9xMzM5989QoyuLGQ12CDx8s/iLAUjAVokDI76kzNT4VFBsw0Z
	X74t5KisQ8uL1LsiKYE8DBoJb4qtu0V+lS6oZcrJGngXCTf8+zgMhGTeg+eAmso=
X-Gm-Gg: ASbGncuPiAb8UdWDzcV6WTM9SC8aq5+DJ+h/rhAfTQj9vcHVK7p9yheDxmDqXrDfFuT
	lXKKacUbsHYEgvwlHDGsr4oIcFuMRxzr6BsOhq7GJV+j25HTSbDeBgKTD/XVSZnMrsc31X1iZTH
	Y0iGsvbodXescGauD2YOMaz6nPIHvlDr/CxknQ6+TUWft9xQzzqJoAL9uCrMmSVdpDpcFuMd2Ay
	0s9YzxezrNptgv3QuqgABAANIM+iuH74LBt7wgoHPyknsKooF8PSTExXVootKh78zw=
X-Google-Smtp-Source: AGHT+IG+vLUjCJavr572zrGQ7sQQaINJqYuCUuqebrt3uxilgo2TK8JPEjpYTwxb2+ZxxoYy2VK7tQ==
X-Received: by 2002:a17:907:7255:b0:aa6:8600:24f3 with SMTP id a640c23a62f3a-ab2ab5f5353mr405431966b.25.1736409972095;
        Thu, 09 Jan 2025 00:06:12 -0800 (PST)
Date: Thu, 9 Jan 2025 09:06:10 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: Denis Mukhin <dmkhn@proton.me>, Jan Beulich <jbeulich@suse.com>,
	dmukhin@ford.com, xen-devel@lists.xenproject.org,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>
Subject: Re: [PATCH v2 20/35] xen/console: introduce console_owner_domid()
Message-ID: <Z3-Dcraxc55vi-ur@macbook.local>
References: <8a5a5a0f-72b0-4336-b0d2-142254319242@suse.com>
 <alpine.DEB.2.22.394.2501061046060.133435@ubuntu-linux-20-04-desktop>
 <c39c0c6f-2fab-46e8-9563-c91fe890e87f@suse.com>
 <alpine.DEB.2.22.394.2501071533060.133435@ubuntu-linux-20-04-desktop>
 <a2fa92ff-a5fb-4adc-86aa-1481ebec92fe@suse.com>
 <Z34xhkNu5YLyEzut@macbook.local>
 <121ae72e-6229-40a4-8b9f-4f8b0764b712@suse.com>
 <Z344xgqtpNZIDxHD@macbook.local>
 <m5iIn0DzBY1VE3oW8MMk5aJD5yovtFe2u7eorkGQVf0czY2gzIYl9k2aKmrdyh1AG6YAgyasVn86Js-vUQyudqjHY7bRYE1hXdCkdFVF0U8=@proton.me>
 <alpine.DEB.2.22.394.2501081615050.133435@ubuntu-linux-20-04-desktop>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <alpine.DEB.2.22.394.2501081615050.133435@ubuntu-linux-20-04-desktop>

On Wed, Jan 08, 2025 at 04:29:24PM -0800, Stefano Stabellini wrote:
> On Wed, 8 Jan 2025, Denis Mukhin wrote:
> > On Wednesday, January 8th, 2025 at 12:35 AM, Roger Pau Monné <roger.pau@citrix.com> wrote:
> > > On Wed, Jan 08, 2025 at 09:13:02AM +0100, Jan Beulich wrote:
> > > > On 08.01.2025 09:04, Roger Pau Monné wrote:
> > > > > On Wed, Jan 08, 2025 at 08:28:32AM +0100, Jan Beulich wrote:
> > > > > > On 08.01.2025 00:40, Stefano Stabellini wrote:
> > > > > > > On Tue, 7 Jan 2025, Jan Beulich wrote:
> > > > > > > > On 06.01.2025 19:48, Stefano Stabellini wrote:
> > > > > > > > > On Mon, 6 Jan 2025, Jan Beulich wrote:
> > > > > > > > > > On 04.01.2025 05:15, Denis Mukhin wrote:
> > > > > > > > > > > On Tuesday, December 10th, 2024 at 11:28 PM, Jan Beulich jbeulich@suse.com wrote:
> > > > > > > > > > > > On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > > From: Denis Mukhin dmukhin@ford.com
> > > > > > > > > > > > > 
> > > > > > > > > > > > > console_owner_domid() is introduced to obtain the "console owner" domain ID.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > The call is used in NS8250 emulator to identify the case when physical xen
> > > > > > > > > > > > > console focus is owned by the domain w/ NS8250 emulator, in which case,
> > > > > > > > > > > > > messages from guest OS are formatted w/o '(XEN)' prefix.
> > > > > > > > > > > > 
> > > > > > > > > > > > Such messages ought to be processed through guest_printk(), which wants a
> > > > > > > > > > > > domain pointer, not a domid_t anyway. Plus isn't that going to be
> > > > > > > > > > > > current->domain anyway at the callsite, eliminating the need for such a
> > > > > > > > > > > > 
> > > > > > > > > > > > helper altogether?
> > > > > > > > > > > 
> > > > > > > > > > > If the current domain is owning the physical console and printing, say, Linux
> > > > > > > > > > > login prompt, there's no need to add "(XEN)" for every printout; adding timestamps
> > > > > > > > > > > can be disabled from Xen command line.
> > > > > > > > > > 
> > > > > > > > > > Surely there shouldn't be (XEN), but without (d<N>) it'll be ambiguous in a log
> > > > > > > > > > which domain a message came from. As long as only Dom0 messages are left un-
> > > > > > > > > > prefixed, that's likely fine. Yet as soon as multiple domains can issue such
> > > > > > > > > > messages (and have console "focus") I think the prefix needs to be there.
> > > > > > > > > 
> > > > > > > > > It looks like we are aligned on the desired behavior,
> > > > > > > > 
> > > > > > > > Hmm, no, I don't think we are. I don't ...
> > > > > > > > 
> > > > > > > > > but for clarity,
> > > > > > > > > see https://marc.info/?l=xen-devel&m=173405161613716, also copy/pasted
> > > > > > > > > here:
> > > > > > > > > 
> > > > > > > > > I think we should provide a consistent behavior across architectures.
> > > > > > > > > The current behavior with vpl011 and dom0less on ARM is the following:
> > > > > > > > > 
> > > > > > > > > - no prefix for Dom0 output
> > > > > > > > > - DOM$NUM for DomUs when not in focus, otherwise no prefix
> > > > > > > > 
> > > > > > > > ... view this model as a desirable one. It leaves room for ambiguity.
> > > > > > > 
> > > > > > > Adding a few more people in CC for feedback.
> > > > > > > 
> > > > > > > My priority is to keep the architectures aligned. It might be OK to
> > > > > > > change output format, but then let's do it uniformly on ARM as well.
> > > > > > > 
> > > > > > > Jan, please clarify what you think would be better than the above. Is it
> > > > > > > the following? I don't think I understood your preference.
> > > > > > > 
> > > > > > > - DOM$NUM for Dom0 and DomUs when not in focus, otherwise no prefix
> > > > > > 
> > > > > > No, I mean like we have it with guest_printk() today. (XEN) for Xen's
> > > > > > own messages, (d<N>) for ordinary domains' ones, and no prefix
> > > > > > exclusively for the hardware/control domain. What is best to do when
> > > > > > hardware and control domains are distinct I'm uncertain - I'd be
> > > > > > inclined to suggest that the hardware domain then stay the one without
> > > > > > any prefix.
> > > > > 
> > > > > One concern I have with this approach is whether the addition of the
> > > > > (d<N>) prefixes will skew output of interactive applications. So far
> > > > > the prefix is added to output from all domains different than dom0
> > > > > because the console is not interactive for them, and hence no input
> > > > > can be consumed.
> > > > 
> > > > Hmm, that's an aspect I have to admit I didn't think of.
> > > > 
> > > > > If that changes however, and domains different than dom0 can get input
> > > > > from the Xen console then I wonder how much the added prefix will skew
> > > > > output. Another possible option would be to not print the prefix for
> > > > > the domain that has the console input assigned (current target), and
> > > > > print it for all other domains (even for dom0 when not in focus).
> > > > 
> > > > That's largely what aiui was proposed. My extra requirement there would
> > > > then be that we make sure a log message is always emitted when console
> > > > focus shifts, so it's possible to identify the owner for any part of
> > > > the log.
> > > 
> > > 
> > > Indeed, printing console input shifting should be a requirement
> > > regardless of how we decide to print the prefix.
> > 
> > Console input focus switch is indicated after pressing Crtl+aaa, e.g.:
> > [[
> > ...
> > (XEN) [15359.353038] *** Serial input to Xen (type 'CTRL-aaa' to switch input)
> > (XEN) [15361.176754] *** Serial input to DOM0 (type 'CTRL-aaa' to switch input)
> > (XEN) [15711.297202] *** Serial input to DOM1 (type 'CTRL-aaa' to switch input)
> > ...
> > ]]
> 
> 
> Roger, Jan, you should use Xen Dom0less more :-) This is the way it
> already works on ARM. Let me expand on my earlier message that was too
> terse.

Hehe, I should use ARM more in general I think :).

> At boot time, Xen prints messages with the (XEN) prefix as usual:
> 
> (XEN) Brought up 4 CPUs
> 
> When Dom0 starts, it has not prefix (and has input by default):
> 
> [    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
> 
> When a DomU starts, it has the following prefix (and doesn't have
> input):
> 
> (XEN) DOM1: [    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
> 
> 
> Eventually, both Linuxes finish booting, you can login into Dom0 as
> usual. Messages from Dom1, if any, are still printed with (XEN) DOM1 as
> prefix.
> 
> You can switch input to Dom1 with Ctrx-aaa, the same way that you do
> today to switch between Xen and Dom0. Xen prints a message:
> 
> (XEN) *** Serial input to DOM1 (type 'CTRL-a' three times to switch input)
> 
> Now, as you type, you send characters to Dom1. And Dom1 doesn't have the
> DOM1 prefix any longer, while it is still has (XEN) because the message
> is printed by Xen on behalf of the domain:
> 
> (XEN) / # echo hello world
> (XEN) hello world
> 
> If Dom0 prints anything in the backgrounds, it shows without prefixes:
> 
> hello world from dom0
> 
> If another domain, dom2, prints anything in the background, it shows
> with (XEN) DOM2 prefix:
> 
> (XEN) DOM2: hello from dom2
> 
> I think it makes sense to be consistent across architectures and we
> should default to the same behavior on x86 too. If we want to make
> improvements, the one thing I could potentially see changing is adding a
> DOM0 prefix to Dom0 messages when Dom0 does not have input. If we do
> that, let's do it on both ARM and x86 architectures.

The usual prefix is (d<domid>) IIRC, that's what guest_printk() uses,
is there any reason dom0less uses "(XEN) DOM<domid>:" instead of the
guest_printk() prefix?

My preference would be use to (d<domid>) prefix for any guest output
that doesn't belong to the domain that's the recipient of the input
(iow: not in console input focus).  And drop the (XEN) prefix from
guest output.

The rest looks all sensible to me.  I think we should avoid adding any
prefixes to guest output when it has the console focus, as otherwise
interactive applications might not work correctly.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 08:26:02 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 08:26:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867852.1279392 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVnrY-0003tc-Dx; Thu, 09 Jan 2025 08:25:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867852.1279392; Thu, 09 Jan 2025 08:25:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVnrY-0003tV-BD; Thu, 09 Jan 2025 08:25:56 +0000
Received: by outflank-mailman (input) for mailman id 867852;
 Thu, 09 Jan 2025 08:25:55 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=pS5t=UB=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVnrW-0003tP-VL
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 08:25:55 +0000
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com
 [2a00:1450:4864:20::333])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 55cb1081-ce63-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 09:25:51 +0100 (CET)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-4361c705434so4841685e9.3
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 00:25: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
 5b1f17b1804b1-436e9e37c2esm12612835e9.28.2025.01.09.00.25.49
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 00:25:49 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 55cb1081-ce63-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736411150; x=1737015950; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=+TMDLDP0xZcmW4CVYT1DFkE6CDenhsuSvPb6O/0lSRw=;
        b=FffU+kYLKYl5IWhZxFFDZdL4IKCl2K8M/47JmO98ccYU3n/vQYnW3tPMJXZE3JY+Ti
         SIRuMsRWthIyvUMm2G6CiLcj1721T3qpi4JWkgCztdEU+K0qZygw7403ZB782Gid3eWg
         jU2zOaO9MfwxwS1PA1rjwo7oED1IEZf0/mZoJlZ1mGUo9YcmKXU8cZJqIu8E0OEuIfHx
         CNe+BnRgqo9f7gjiiQ2F1QVMnM4jd9qMFGBAPrC7eglKCtuyHgtdpSjV9RPEij3Jbmkb
         hG3Ivi5m3FK7X4ILRENUaxOAHfb8k+/uet0hRHSQIO8uIppr+9axCGvtMg+XFXAt8ON4
         GNlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736411150; x=1737015950;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=+TMDLDP0xZcmW4CVYT1DFkE6CDenhsuSvPb6O/0lSRw=;
        b=HnNwlQEPAznEvcT6cPpGmeZnsZzTyMslKDfZ9fOB5MfQEaMpgsNHKHxXfWsHMfoMxW
         odpSoS2c0lUMl6crgldEYj8tR4FSimIMAkDvnqHJYEma7ird6b9eWv+i3NeQYfJw36EI
         ZIswDFZw5ZOfy7Dv+PTSY7/UEYz2QeqzPJCwgcbkPq4p1ec/AUEDva0bwva5/6MRZN5t
         HRln7sb6HVlJk7Be1FmaHXx3au8OBvLqVxE8jSOmW7GoaPgoGyzvi8sG3Q+ndPYqbLmh
         EB4vb2775GCrKH4i3ajTjcKiWpn/2GVE8U2srIetOFnSyRhl7BnLgEMoFXI6v1eF+42m
         vbkQ==
X-Forwarded-Encrypted: i=1; AJvYcCUPLyCtSxqWyMSj1yCZo+G4aYdVZ5KZ2g2axLjc9qdB+NcvKJ4SOFphq2jHYOj8hW7QjWIu7EFhL/k=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyz9Pjii5wU74eLarLxoaf2ztwtJrztwnsVAQNpRptVlGNu0pud
	4F0TlICfSFasmibn8X/2s/D9zBhHhm3/H7kmrHFapsHlue/KGLgPD6OCJu8M+w==
X-Gm-Gg: ASbGncu3u+F4fRTB6rh7BFn2H7yRLuVYbFte2+Rr2vqr4SKWB7CPVFlrRD2Ba7plMe9
	DJTn0TQKn8u+asJoTXTf0n0LKQOwpSWtI0BZaszFgoDVa4AT18bCPLhFFGOOtBH/TnGxE2Zc9bH
	2IOWQt5HcN9TBrhJw7FmTyaqud1csok7KjZsgd3tjm+0aj7aaM2RBFXz5L2nQP5+s0QTch0aUZj
	/xYz+3EJRacFsOIFtKJP/hzrJ+dJk9oym32INy6UiXVEAh/59vp8qa3b/6xIfDhBK9Sf82q0FLE
	BqEiRq8AVKktBevnj/lclxx++8krVFaBSPZwNwDecg==
X-Google-Smtp-Source: AGHT+IH45E2AFOZLcWe00FAXF79S8ka45YuubKaRkFt+lZgrhXhmAPOAJphJgL42GfYlDkoXPSD8qw==
X-Received: by 2002:a05:600c:3543:b0:434:f767:68ea with SMTP id 5b1f17b1804b1-436e2677c7dmr49611375e9.5.1736411150223;
        Thu, 09 Jan 2025 00:25:50 -0800 (PST)
Message-ID: <1af5c552-ea5e-4cf5-9a80-0e3559aeb403@suse.com>
Date: Thu, 9 Jan 2025 09:25:48 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 20/35] xen/console: introduce console_owner_domid()
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 dmukhin@ford.com, xen-devel@lists.xenproject.org,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>, Denis Mukhin <dmkhn@proton.me>
References: <20241205-vuart-ns8250-v1-20-e9aa923127eb@ford.com>
 <8a5a5a0f-72b0-4336-b0d2-142254319242@suse.com>
 <alpine.DEB.2.22.394.2501061046060.133435@ubuntu-linux-20-04-desktop>
 <c39c0c6f-2fab-46e8-9563-c91fe890e87f@suse.com>
 <alpine.DEB.2.22.394.2501071533060.133435@ubuntu-linux-20-04-desktop>
 <a2fa92ff-a5fb-4adc-86aa-1481ebec92fe@suse.com>
 <Z34xhkNu5YLyEzut@macbook.local>
 <121ae72e-6229-40a4-8b9f-4f8b0764b712@suse.com>
 <Z344xgqtpNZIDxHD@macbook.local>
 <m5iIn0DzBY1VE3oW8MMk5aJD5yovtFe2u7eorkGQVf0czY2gzIYl9k2aKmrdyh1AG6YAgyasVn86Js-vUQyudqjHY7bRYE1hXdCkdFVF0U8=@proton.me>
 <alpine.DEB.2.22.394.2501081615050.133435@ubuntu-linux-20-04-desktop>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <alpine.DEB.2.22.394.2501081615050.133435@ubuntu-linux-20-04-desktop>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 09.01.2025 01:29, Stefano Stabellini wrote:
> On Wed, 8 Jan 2025, Denis Mukhin wrote:
>> On Wednesday, January 8th, 2025 at 12:35 AM, Roger Pau Monné <roger.pau@citrix.com> wrote:
>>> On Wed, Jan 08, 2025 at 09:13:02AM +0100, Jan Beulich wrote:
>>>> On 08.01.2025 09:04, Roger Pau Monné wrote:
>>>>> On Wed, Jan 08, 2025 at 08:28:32AM +0100, Jan Beulich wrote:
>>>>>> On 08.01.2025 00:40, Stefano Stabellini wrote:
>>>>>>> On Tue, 7 Jan 2025, Jan Beulich wrote:
>>>>>>>> On 06.01.2025 19:48, Stefano Stabellini wrote:
>>>>>>>>> On Mon, 6 Jan 2025, Jan Beulich wrote:
>>>>>>>>>> On 04.01.2025 05:15, Denis Mukhin wrote:
>>>>>>>>>>> On Tuesday, December 10th, 2024 at 11:28 PM, Jan Beulich jbeulich@suse.com wrote:
>>>>>>>>>>>> On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> From: Denis Mukhin dmukhin@ford.com
>>>>>>>>>>>>>
>>>>>>>>>>>>> console_owner_domid() is introduced to obtain the "console owner" domain ID.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The call is used in NS8250 emulator to identify the case when physical xen
>>>>>>>>>>>>> console focus is owned by the domain w/ NS8250 emulator, in which case,
>>>>>>>>>>>>> messages from guest OS are formatted w/o '(XEN)' prefix.
>>>>>>>>>>>>
>>>>>>>>>>>> Such messages ought to be processed through guest_printk(), which wants a
>>>>>>>>>>>> domain pointer, not a domid_t anyway. Plus isn't that going to be
>>>>>>>>>>>> current->domain anyway at the callsite, eliminating the need for such a
>>>>>>>>>>>>
>>>>>>>>>>>> helper altogether?
>>>>>>>>>>>
>>>>>>>>>>> If the current domain is owning the physical console and printing, say, Linux
>>>>>>>>>>> login prompt, there's no need to add "(XEN)" for every printout; adding timestamps
>>>>>>>>>>> can be disabled from Xen command line.
>>>>>>>>>>
>>>>>>>>>> Surely there shouldn't be (XEN), but without (d<N>) it'll be ambiguous in a log
>>>>>>>>>> which domain a message came from. As long as only Dom0 messages are left un-
>>>>>>>>>> prefixed, that's likely fine. Yet as soon as multiple domains can issue such
>>>>>>>>>> messages (and have console "focus") I think the prefix needs to be there.
>>>>>>>>>
>>>>>>>>> It looks like we are aligned on the desired behavior,
>>>>>>>>
>>>>>>>> Hmm, no, I don't think we are. I don't ...
>>>>>>>>
>>>>>>>>> but for clarity,
>>>>>>>>> see https://marc.info/?l=xen-devel&m=173405161613716, also copy/pasted
>>>>>>>>> here:
>>>>>>>>>
>>>>>>>>> I think we should provide a consistent behavior across architectures.
>>>>>>>>> The current behavior with vpl011 and dom0less on ARM is the following:
>>>>>>>>>
>>>>>>>>> - no prefix for Dom0 output
>>>>>>>>> - DOM$NUM for DomUs when not in focus, otherwise no prefix
>>>>>>>>
>>>>>>>> ... view this model as a desirable one. It leaves room for ambiguity.
>>>>>>>
>>>>>>> Adding a few more people in CC for feedback.
>>>>>>>
>>>>>>> My priority is to keep the architectures aligned. It might be OK to
>>>>>>> change output format, but then let's do it uniformly on ARM as well.
>>>>>>>
>>>>>>> Jan, please clarify what you think would be better than the above. Is it
>>>>>>> the following? I don't think I understood your preference.
>>>>>>>
>>>>>>> - DOM$NUM for Dom0 and DomUs when not in focus, otherwise no prefix
>>>>>>
>>>>>> No, I mean like we have it with guest_printk() today. (XEN) for Xen's
>>>>>> own messages, (d<N>) for ordinary domains' ones, and no prefix
>>>>>> exclusively for the hardware/control domain. What is best to do when
>>>>>> hardware and control domains are distinct I'm uncertain - I'd be
>>>>>> inclined to suggest that the hardware domain then stay the one without
>>>>>> any prefix.
>>>>>
>>>>> One concern I have with this approach is whether the addition of the
>>>>> (d<N>) prefixes will skew output of interactive applications. So far
>>>>> the prefix is added to output from all domains different than dom0
>>>>> because the console is not interactive for them, and hence no input
>>>>> can be consumed.
>>>>
>>>> Hmm, that's an aspect I have to admit I didn't think of.
>>>>
>>>>> If that changes however, and domains different than dom0 can get input
>>>>> from the Xen console then I wonder how much the added prefix will skew
>>>>> output. Another possible option would be to not print the prefix for
>>>>> the domain that has the console input assigned (current target), and
>>>>> print it for all other domains (even for dom0 when not in focus).
>>>>
>>>> That's largely what aiui was proposed. My extra requirement there would
>>>> then be that we make sure a log message is always emitted when console
>>>> focus shifts, so it's possible to identify the owner for any part of
>>>> the log.
>>>
>>>
>>> Indeed, printing console input shifting should be a requirement
>>> regardless of how we decide to print the prefix.
>>
>> Console input focus switch is indicated after pressing Crtl+aaa, e.g.:
>> [[
>> ...
>> (XEN) [15359.353038] *** Serial input to Xen (type 'CTRL-aaa' to switch input)
>> (XEN) [15361.176754] *** Serial input to DOM0 (type 'CTRL-aaa' to switch input)
>> (XEN) [15711.297202] *** Serial input to DOM1 (type 'CTRL-aaa' to switch input)
>> ...
>> ]]
> 
> 
> Roger, Jan, you should use Xen Dom0less more :-) This is the way it
> already works on ARM. Let me expand on my earlier message that was too
> terse.
> 
> At boot time, Xen prints messages with the (XEN) prefix as usual:
> 
> (XEN) Brought up 4 CPUs
> 
> When Dom0 starts, it has not prefix (and has input by default):
> 
> [    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
> 
> When a DomU starts, it has the following prefix (and doesn't have
> input):
> 
> (XEN) DOM1: [    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]

Which is wrong - this isn't a Xen message. Such messages imo want prefixing
(d<N>), as guest_printk() does.

Jan

> Eventually, both Linuxes finish booting, you can login into Dom0 as
> usual. Messages from Dom1, if any, are still printed with (XEN) DOM1 as
> prefix.
> 
> You can switch input to Dom1 with Ctrx-aaa, the same way that you do
> today to switch between Xen and Dom0. Xen prints a message:
> 
> (XEN) *** Serial input to DOM1 (type 'CTRL-a' three times to switch input)
> 
> Now, as you type, you send characters to Dom1. And Dom1 doesn't have the
> DOM1 prefix any longer, while it is still has (XEN) because the message
> is printed by Xen on behalf of the domain:
> 
> (XEN) / # echo hello world
> (XEN) hello world
> 
> If Dom0 prints anything in the backgrounds, it shows without prefixes:
> 
> hello world from dom0
> 
> If another domain, dom2, prints anything in the background, it shows
> with (XEN) DOM2 prefix:
> 
> (XEN) DOM2: hello from dom2
> 
> I think it makes sense to be consistent across architectures and we
> should default to the same behavior on x86 too. If we want to make
> improvements, the one thing I could potentially see changing is adding a
> DOM0 prefix to Dom0 messages when Dom0 does not have input. If we do
> that, let's do it on both ARM and x86 architectures.
> 
> Cheers,
> Stefano



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 08:27:54 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 08:27:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867860.1279403 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVntR-0004Q7-Or; Thu, 09 Jan 2025 08:27:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867860.1279403; Thu, 09 Jan 2025 08:27:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVntR-0004Q0-Lj; Thu, 09 Jan 2025 08:27:53 +0000
Received: by outflank-mailman (input) for mailman id 867860;
 Thu, 09 Jan 2025 08:27:52 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=pS5t=UB=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVntQ-0004Pu-NS
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 08:27:52 +0000
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com
 [2a00:1450:4864:20::336])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9d460930-ce63-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 09:27:50 +0100 (CET)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-436637e8c8dso7173895e9.1
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 00:27: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
 5b1f17b1804b1-436e9e03f54sm12838605e9.21.2025.01.09.00.27.49
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 00:27:49 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9d460930-ce63-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736411270; x=1737016070; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=3nZGtdavISqmXEDZk3a2Nqq+lmQWsnkRigWGu/w1YH4=;
        b=A37zP+Xt3/PHd5jEdptHchp79ewFMPShUeRyzoQuWrTxeBVGnRWfLOXmLk2g5IfLAg
         Ff+BucbH2uM+LOvRpX+04s5nWoCQWM5spG3zTikMrBVE9degxTOpVQH+7c9rmt5S8huv
         4sj5Fgm1TDJbfaytdV5ijo+hIMkbsuGoX//6pnGfDX2aNCZNJtxZMCEKpNUlMG4dxK0k
         csToGhQT4ClKlk67yZr5bLGFwTBSizvxNXjXfFk+RPfaZYE2AKggiS/xOv77GgeYag/e
         2aLF8OnjbXUxhn0CYorBzDVQNSUD5gfb5kS9jp4zXTccOtjPHteJbAuWLMIFnLnX6llR
         VV4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736411270; x=1737016070;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=3nZGtdavISqmXEDZk3a2Nqq+lmQWsnkRigWGu/w1YH4=;
        b=Tb/EBYyZCuYMfWQDzB0nAmv1soVYw6Pa0LIZv3NkgEMTqS1YukY48h2iUZ4MqNUvRy
         LqkmnNBpblfU/KxMOyxFfgbj0szgvTq/vs2kpI5sD0oWtMSvcEpfIXJytCW3px1w6aEi
         ke+fED2NwMkSW3cz9avJAWf2zftDwz2Jhn5CInR5vx/jGnTsmLwdxAXp9qRXpPLg4Nxp
         JfQsWcm4TZT6a6EStCixK2Ebw1bGxvV5MZtS9R2l20k7w0vBSwv0kObp5LEoQccvy8S+
         R00kbNDQQLj1hB5Q6jeAokpLE8KVsKIVryBMiZhArCXfflTkH+IS5wEhXh0fttSacg9V
         uRzg==
X-Forwarded-Encrypted: i=1; AJvYcCWBbrJ80WJJ+QMYraLOlzZh2FUazgfsECx6BbueJyZfyFvT99CRPtWq09ozDZmrf3yYoFKw55pJVhc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxI2MTudlMgm+agrrS1/hp2p3VT7nvDDaIo9Sb+rwf3C/KdyehI
	e1M9B35d6Dy9xqS/eENcM64IBnlAA7sH7bmUknhXz+ZRpUN64ChaByM1RgChtQ==
X-Gm-Gg: ASbGncswZ/Qx1J34tS7RLDQOLPsltuSked4pYyOscK0WsQP7KowBOTZzXIHLYWHA8dZ
	arBS49UK7z7zyTHpFtXTgjsnyLfTnj+HoDzIK7XsLXDLOiqtwER6qE0fGyKv8fjIwJN16JT9qtO
	F1iwXbQqLFkw4FOq1KDl1+ozm7BngJoDnjQhaeVrpbiZOpFcqHOxQ+zFh8ixXksDpBbWmC1xwgV
	skZAcn8R/Ewji/FvZO/oFrlXRfujxAuLoC2BeL+q/7CsxJTAmF4eTVETJBNrz3rOpKOVgfTyPrX
	bV8apfnraxd4JJ3CocWKQdEfm/h2IY04Ae7oUYpw1w==
X-Google-Smtp-Source: AGHT+IFWqyyjdxWZRaahpMlhdQyu1UtAOqpMnYoFKxQIsXY4AW0HzwHIJql+JJgLTXzF/rww0DWR4Q==
X-Received: by 2002:a5d:64ed:0:b0:38a:4b8a:e477 with SMTP id ffacd0b85a97d-38a87306a84mr5121968f8f.22.1736411270149;
        Thu, 09 Jan 2025 00:27:50 -0800 (PST)
Message-ID: <e936ebe8-f729-4878-843e-639755b2fefb@suse.com>
Date: Thu, 9 Jan 2025 09:27:48 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 20/35] xen/console: introduce console_owner_domid()
To: Denis Mukhin <dmkhn@proton.me>
Cc: Stefano Stabellini <sstabellini@kernel.org>, dmukhin@ford.com,
 xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 Julien Grall <julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>
References: <20241205-vuart-ns8250-v1-20-e9aa923127eb@ford.com>
 <8a5a5a0f-72b0-4336-b0d2-142254319242@suse.com>
 <alpine.DEB.2.22.394.2501061046060.133435@ubuntu-linux-20-04-desktop>
 <c39c0c6f-2fab-46e8-9563-c91fe890e87f@suse.com>
 <alpine.DEB.2.22.394.2501071533060.133435@ubuntu-linux-20-04-desktop>
 <a2fa92ff-a5fb-4adc-86aa-1481ebec92fe@suse.com>
 <Z34xhkNu5YLyEzut@macbook.local>
 <121ae72e-6229-40a4-8b9f-4f8b0764b712@suse.com>
 <Z344xgqtpNZIDxHD@macbook.local>
 <m5iIn0DzBY1VE3oW8MMk5aJD5yovtFe2u7eorkGQVf0czY2gzIYl9k2aKmrdyh1AG6YAgyasVn86Js-vUQyudqjHY7bRYE1hXdCkdFVF0U8=@proton.me>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <m5iIn0DzBY1VE3oW8MMk5aJD5yovtFe2u7eorkGQVf0czY2gzIYl9k2aKmrdyh1AG6YAgyasVn86Js-vUQyudqjHY7bRYE1hXdCkdFVF0U8=@proton.me>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 08.01.2025 23:15, Denis Mukhin wrote:
> On Wednesday, January 8th, 2025 at 12:35 AM, Roger Pau Monné <roger.pau@citrix.com> wrote:
> 
>>
>>
>> On Wed, Jan 08, 2025 at 09:13:02AM +0100, Jan Beulich wrote:
>>
>>> On 08.01.2025 09:04, Roger Pau Monné wrote:
>>>
>>>> On Wed, Jan 08, 2025 at 08:28:32AM +0100, Jan Beulich wrote:
>>>>
>>>>> On 08.01.2025 00:40, Stefano Stabellini wrote:
>>>>>
>>>>>> On Tue, 7 Jan 2025, Jan Beulich wrote:
>>>>>>
>>>>>>> On 06.01.2025 19:48, Stefano Stabellini wrote:
>>>>>>>
>>>>>>>> On Mon, 6 Jan 2025, Jan Beulich wrote:
>>>>>>>>
>>>>>>>>> On 04.01.2025 05:15, Denis Mukhin wrote:
>>>>>>>>>
>>>>>>>>>> On Tuesday, December 10th, 2024 at 11:28 PM, Jan Beulich jbeulich@suse.com wrote:
>>>>>>>>>>
>>>>>>>>>>> On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
>>>>>>>>>>>
>>>>>>>>>>>> From: Denis Mukhin dmukhin@ford.com
>>>>>>>>>>>>
>>>>>>>>>>>> console_owner_domid() is introduced to obtain the "console owner" domain ID.
>>>>>>>>>>>>
>>>>>>>>>>>> The call is used in NS8250 emulator to identify the case when physical xen
>>>>>>>>>>>> console focus is owned by the domain w/ NS8250 emulator, in which case,
>>>>>>>>>>>> messages from guest OS are formatted w/o '(XEN)' prefix.
>>>>>>>>>>>
>>>>>>>>>>> Such messages ought to be processed through guest_printk(), which wants a
>>>>>>>>>>> domain pointer, not a domid_t anyway. Plus isn't that going to be
>>>>>>>>>>> current->domain anyway at the callsite, eliminating the need for such a
>>>>>>>>>>>
>>>>>>>>>>> helper altogether?
>>>>>>>>>>
>>>>>>>>>> If the current domain is owning the physical console and printing, say, Linux
>>>>>>>>>> login prompt, there's no need to add "(XEN)" for every printout; adding timestamps
>>>>>>>>>> can be disabled from Xen command line.
>>>>>>>>>
>>>>>>>>> Surely there shouldn't be (XEN), but without (d<N>) it'll be ambiguous in a log
>>>>>>>>> which domain a message came from. As long as only Dom0 messages are left un-
>>>>>>>>> prefixed, that's likely fine. Yet as soon as multiple domains can issue such
>>>>>>>>> messages (and have console "focus") I think the prefix needs to be there.
>>>>>>>>
>>>>>>>> It looks like we are aligned on the desired behavior,
>>>>>>>
>>>>>>> Hmm, no, I don't think we are. I don't ...
>>>>>>>
>>>>>>>> but for clarity,
>>>>>>>> see https://marc.info/?l=xen-devel&m=173405161613716, also copy/pasted
>>>>>>>> here:
>>>>>>>>
>>>>>>>> I think we should provide a consistent behavior across architectures.
>>>>>>>> The current behavior with vpl011 and dom0less on ARM is the following:
>>>>>>>>
>>>>>>>> - no prefix for Dom0 output
>>>>>>>> - DOM$NUM for DomUs when not in focus, otherwise no prefix
>>>>>>>
>>>>>>> ... view this model as a desirable one. It leaves room for ambiguity.
>>>>>>
>>>>>> Adding a few more people in CC for feedback.
>>>>>>
>>>>>> My priority is to keep the architectures aligned. It might be OK to
>>>>>> change output format, but then let's do it uniformly on ARM as well.
>>>>>>
>>>>>> Jan, please clarify what you think would be better than the above. Is it
>>>>>> the following? I don't think I understood your preference.
>>>>>>
>>>>>> - DOM$NUM for Dom0 and DomUs when not in focus, otherwise no prefix
>>>>>
>>>>> No, I mean like we have it with guest_printk() today. (XEN) for Xen's
>>>>> own messages, (d<N>) for ordinary domains' ones, and no prefix
>>>>> exclusively for the hardware/control domain. What is best to do when
>>>>> hardware and control domains are distinct I'm uncertain - I'd be
>>>>> inclined to suggest that the hardware domain then stay the one without
>>>>> any prefix.
>>>>
>>>> One concern I have with this approach is whether the addition of the
>>>> (d<N>) prefixes will skew output of interactive applications. So far
>>>> the prefix is added to output from all domains different than dom0
>>>> because the console is not interactive for them, and hence no input
>>>> can be consumed.
>>>
>>> Hmm, that's an aspect I have to admit I didn't think of.
>>>
>>>> If that changes however, and domains different than dom0 can get input
>>>> from the Xen console then I wonder how much the added prefix will skew
>>>> output. Another possible option would be to not print the prefix for
>>>> the domain that has the console input assigned (current target), and
>>>> print it for all other domains (even for dom0 when not in focus).
>>>
>>> That's largely what aiui was proposed. My extra requirement there would
>>> then be that we make sure a log message is always emitted when console
>>> focus shifts, so it's possible to identify the owner for any part of
>>> the log.
>>
>> Indeed, printing console input shifting should be a requirement
>> regardless of how we decide to print the prefix.
> 
> Console input focus switch is indicated after pressing Crtl+aaa, e.g.:
> [[
> ...
> (XEN) [15359.353038] *** Serial input to Xen (type 'CTRL-aaa' to switch input)
> (XEN) [15361.176754] *** Serial input to DOM0 (type 'CTRL-aaa' to switch input)
> (XEN) [15711.297202] *** Serial input to DOM1 (type 'CTRL-aaa' to switch input)
> ...
> ]]

And just to double check: These messages aren't affected by "loglvl=" settings,
i.e. they're _always_ there (as asked for earlier; see context above)?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 09:00:24 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 09:00:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867877.1279413 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVoOa-0000jn-AQ; Thu, 09 Jan 2025 09:00:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867877.1279413; Thu, 09 Jan 2025 09:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVoOa-0000jB-6f; Thu, 09 Jan 2025 09:00:04 +0000
Received: by outflank-mailman (input) for mailman id 867877;
 Thu, 09 Jan 2025 09:00:03 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=pS5t=UB=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVoOY-0000Sn-Vd
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 09:00:02 +0000
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com
 [2a00:1450:4864:20::32e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1b5712ba-ce68-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 10:00:00 +0100 (CET)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-436281c8a38so4924555e9.3
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 01:00:00 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436dcc8ddddsm52410165e9.0.2025.01.09.00.59.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 00:59:59 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1b5712ba-ce68-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736413200; x=1737018000; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=xNWEARFJyosFvLsb8p1NXDbZUZslPRuGjAlrl83QDuw=;
        b=Jud5stoHmuT1v1pYMfpBLcgXwftLf7IbnYUK5tKfi/ZSWHxD9Rp0GQ4x1I/1CGObIN
         OZhRT75JnFoPkumHXr0l9Z/vwEdnwCtAR4FzDMAHaLWMuPPP/DeuuBI2YfcmwByMJK4V
         oS45WjkcM0h7fLTWjQPJlyhUAQ+kX1nrdRy3y2GGWijMIbHpSaz7eqSMvf+jVdhr5wjl
         WyOveaIKXlz+fAKzkGYLXUEduN9MoSdFLN6qtEpK4ppMlUH6qj4Lh+d2dVbXM+7pGTN+
         qDq99OGC+yXNirR7C7yLCcLUvNcg3Ii/UKhy2YuY0nzae8pu0vTgjmJ1ddW3AjjNEjB0
         6GlA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736413200; x=1737018000;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=xNWEARFJyosFvLsb8p1NXDbZUZslPRuGjAlrl83QDuw=;
        b=a3+XeL1ZNw0m7bPVYQP2z2sunwCsMWZUSprWbx1J38KoaURwG5RJR6tx6MzUm/M/ZN
         inxAhR9cyX9av1T8mWvdYB7rdglclpGkH1gk1EIod9cxLWK/92PUgsgobn36nPcn9wym
         CMIV+VgAjzjS8kOpH7/qgW2FdmsIofgc8OXREL2NU9hD2UvOWKX6lp67hu3K1T/8ehQi
         g3IyE8423gWYYwWb9Blo3aRauqmyCZlDXUVTTlPnHmUWkOPPuVphsk83kUBN6dd8iQin
         ZIcZnNFQq2G9ZJ4y13VMDKXWKan8wK+rqfSAjZd3/pUmtiOAUnvAD5HYA+MDL3rgcwEC
         Zq6g==
X-Forwarded-Encrypted: i=1; AJvYcCUSIhR+S4zlg++aZiSQyvftaoyQ7H/bdmHidtFmLwVHKWGpAqzIkMG1nw63JPBYe0xOaflvfJameI4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyhxFKBrztK92djtXZGq52C44Xcg2G1yTN2lYTBCmieK8KNNwI1
	kZSiW6IW2RrXB5BAhBqYrO3RJh5h3AegqETja3QDovA8+UCupUiBnKtB6ai0Jg==
X-Gm-Gg: ASbGncvVK7lHRVONy4U/58iSyX716JWxpnlmZa2dCURtay/xN6gU9LlCmkqk8xOCaSH
	iGqypdjLqIjSeNfj2k8UTAzOccd/So02kH9/jn37fpDg+jA0LOKJ94XejLIyB7qj8O9h232JdRc
	LPEZZW/x6JMteNX9N/dlTI4jB8dRhZwJ7ekf0wozjIgnkt+Wa/+hOIEY8fcrnzHLS0kGtjEqLRX
	JXIYV9RdZUatmU3x2A797Ryi+vrlPMDFm5iTcsj1dj232DLBsZDuZ4NoA1CCYftym4dahDh+knt
	dS/PHmVroa8bod2jf1oJSe2ohkpIjXh2xW3ih+RUhw==
X-Google-Smtp-Source: AGHT+IHQn/lYVHHIyMCRqNgr13HmVW8etbALTzx21tRu2SYve2/OgM3AmKcWGaQefJYhjTjCwem1og==
X-Received: by 2002:a05:600c:4f47:b0:434:e8cf:6390 with SMTP id 5b1f17b1804b1-436e2684dfcmr47162035e9.6.1736413200013;
        Thu, 09 Jan 2025 01:00:00 -0800 (PST)
Message-ID: <46cb0ee0-ea9f-4515-abac-058a9aa846e4@suse.com>
Date: Thu, 9 Jan 2025 09:59:58 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 02/18] x86/domain: limit window where curr_vcpu !=
 current on context switch
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xenproject.org
References: <20250108142659.99490-1-roger.pau@citrix.com>
 <20250108142659.99490-3-roger.pau@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250108142659.99490-3-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 08.01.2025 15:26, Roger Pau Monne wrote:
> On x86 Xen will perform lazy context switches to the idle vCPU, where the
> previously running vCPU context is not overwritten, and only current is updated
> to point to the idle vCPU.  The state is then disjunct between current and
> curr_vcpu: current points to the idle vCPU, while curr_vcpu points to the vCPU
> whose context is loaded on the pCPU.
> 
> While on that lazy context switched state, certain calls (like
> map_domain_page()) will trigger a full synchronization of the pCPU state by
> forcing a context switch.  Note however how calling any of such functions
> inside the context switch code itself is very likely to trigger an infinite
> recursion loop.
> 
> Attempt to limit the window where curr_vcpu != current in the context switch
> code, as to prevent and infinite recursion loop around sync_local_execstate().
> 
> This is required for using map_domain_page() in the vCPU context switch code,
> otherwise using map_domain_page() in that context ends up in a recursive
> sync_local_execstate() loop:

Question is whether it's a good idea in the first place to start using
map_domain_page() from the context switch path. Surely there are possible
alternatives.

> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -1982,16 +1982,16 @@ static void load_default_gdt(unsigned int cpu)
>      per_cpu(full_gdt_loaded, cpu) = false;
>  }
>  
> -static void __context_switch(void)
> +static void __context_switch(struct vcpu *n)
>  {
>      struct cpu_user_regs *stack_regs = guest_cpu_user_regs();
>      unsigned int          cpu = smp_processor_id();
>      struct vcpu          *p = per_cpu(curr_vcpu, cpu);
> -    struct vcpu          *n = current;
>      struct domain        *pd = p->domain, *nd = n->domain;
>  
>      ASSERT(p != n);
>      ASSERT(!vcpu_cpu_dirty(n));
> +    ASSERT(p == current);
>  
>      if ( !is_idle_domain(pd) )
>      {
> @@ -2036,6 +2036,18 @@ static void __context_switch(void)
>  
>      write_ptbase(n);
>  
> +    /*
> +     * It's relevant to set both current and curr_vcpu back-to-back, to avoid a
> +     * window where calls to mapcache_current_vcpu() during the context switch
> +     * could trigger a recursive loop.
> +     *
> +     * Do the current switch immediately after switching to the new guest
> +     * page-tables, so that current is (almost) always in sync with the
> +     * currently loaded page-tables.
> +     */
> +    set_current(n);
> +    per_cpu(curr_vcpu, cpu) = n;

The latter paragraph of the comment states something that so far wasn't intended,
and imo also shouldn't be going forward. It's curr_vcpu which wants to be in sync
with the loaded page tables. (Whether pulling ahead its updating is okay is a
separate question. All of these actions used to be be very carefully placed they
way they are. Which isn't to say that I can exclude things having gone stale ...)
And yes, that has always meant that mapcache_current_vcpu()'s condition for
calling sync_local_execstate() was building upon the fact that it won't be called
from context switching contexts.

Did you consider updating that condition (evaluating curr_cpu) instead?

> @@ -2048,8 +2060,6 @@ static void __context_switch(void)
>      if ( pd != nd )
>          cpumask_clear_cpu(cpu, pd->dirty_cpumask);
>      write_atomic(&p->dirty_cpu, VCPU_CPU_CLEAN);
> -
> -    per_cpu(curr_vcpu, cpu) = n;
>  }
>  
>  void context_switch(struct vcpu *prev, struct vcpu *next)
> @@ -2081,16 +2091,36 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
>  
>      local_irq_disable();
>  
> -    set_current(next);
> -
>      if ( (per_cpu(curr_vcpu, cpu) == next) ||
>           (is_idle_domain(nextd) && cpu_online(cpu)) )
>      {
> +        /*
> +         * Lazy context switch to the idle vCPU, set current == idle.  Full
> +         * context switch happens if/when sync_local_execstate() is called.
> +         */
> +        set_current(next);
>          local_irq_enable();

The comment is misleading as far as the first half of the if() condition goes:
No further switching is going to happen in that case, aiui.

>      }
>      else
>      {
> -        __context_switch();
> +        /*
> +         * curr_vcpu will always point to the currently loaded vCPU context, as
> +         * it's not updated when doing a lazy switch to the idle vCPU.
> +         */
> +        struct vcpu *prev_ctx = per_cpu(curr_vcpu, cpu);
> +
> +        if ( prev_ctx != current )
> +        {
> +            /*
> +             * Doing a full context switch to a non-idle vCPU from a lazy
> +             * context switched state.  Adjust current to point to the
> +             * currently loaded vCPU context.
> +             */
> +            ASSERT(current == idle_vcpu[cpu]);
> +            ASSERT(!is_idle_vcpu(next));
> +            set_current(prev_ctx);

This feels wrong, as in "current" then not representing what it should represent,
for a certain time window. I may be dense, but neither comment not description
clarify to me why this might be needed. I can see that it's needed to please the
ASSERT() you add to __context_switch(), yet then I might ask why that assertion
is put there.

> +        }
> +        __context_switch(next);
>  
>          /* Re-enable interrupts before restoring state which may fault. */
>          local_irq_enable();
> @@ -2156,15 +2186,23 @@ int __sync_local_execstate(void)
>  {
>      unsigned long flags;
>      int switch_required;
> +    unsigned int cpu = smp_processor_id();
> +    struct vcpu *p;
>  
>      local_irq_save(flags);
>  
> -    switch_required = (this_cpu(curr_vcpu) != current);
> +    p = per_cpu(curr_vcpu, cpu);
> +    switch_required = (p != current);
>  
>      if ( switch_required )
>      {
> -        ASSERT(current == idle_vcpu[smp_processor_id()]);
> -        __context_switch();
> +        ASSERT(current == idle_vcpu[cpu]);
> +        /*
> +         * Restore current to the previously running vCPU, __context_switch()
> +         * will update current together with curr_vcpu.
> +         */
> +        set_current(p);

Similarly here.

> +        __context_switch(idle_vcpu[cpu]);
>      }
>  
>      local_irq_restore(flags);
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -2232,8 +2232,6 @@ void __init trap_init(void)
>  
>  void activate_debugregs(const struct vcpu *curr)
>  {
> -    ASSERT(curr == current);
> -
>      write_debugreg(0, curr->arch.dr[0]);
>      write_debugreg(1, curr->arch.dr[1]);
>      write_debugreg(2, curr->arch.dr[2]);

Why would this assertion go away? If it suddenly triggers, the parameter name
would now end up being wrong.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 09:03:08 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 09:03:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867886.1279422 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVoRX-0001lD-Mc; Thu, 09 Jan 2025 09:03:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867886.1279422; Thu, 09 Jan 2025 09:03:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVoRX-0001l6-K5; Thu, 09 Jan 2025 09:03:07 +0000
Received: by outflank-mailman (input) for mailman id 867886;
 Thu, 09 Jan 2025 09:03: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 <SRS0=pS5t=UB=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVoRW-0001l0-IH
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 09:03:06 +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 899b1610-ce68-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 10:03:05 +0100 (CET)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-436a03197b2so4865875e9.2
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 01:03: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
 5b1f17b1804b1-436e2dc0babsm48127655e9.14.2025.01.09.01.03.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 01:03:04 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 899b1610-ce68-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736413385; x=1737018185; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=frpOsuC0haFEZmtUajHIEA6hZOD7Mf23nJ6yJozhB+I=;
        b=ddIGWDmYJ5Ss5aieB3R9T2Aw18hhJRBNh/pk14X/npTw0DoyiPFD7+jt4r80/3mIx7
         +dFCE3sW/c3cyDRj05CH2fdnDw9fSWuVdmRNZ9oQsscjMQC64ml6GJJ4xvngW11pIQGh
         wSfCmQXIK+Q0Nd6P1QKsfbyu3rOiANRf4dr8glxbYEnxXBLK4TT/kgtR0bzreorM1A5N
         6gdMyiI2Cjhtx1hla6N+a/ScUncZL8YQJTYkLyXkx7X7hHZqKHX8s+8c5qOeTwCIOOtR
         sT10c13MkXg2qdrBhdbvZ+lXKDuBAAG7q0fvM718st3HTr+q8UPeCGHf7h/pSoLTod/S
         YKxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736413385; x=1737018185;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=frpOsuC0haFEZmtUajHIEA6hZOD7Mf23nJ6yJozhB+I=;
        b=IC6BjpalHXuxRSSuWN4sNoTYDbfwzbYsdcE+gA33VXUTu49ra1Ot+Dcsyth/llvoTq
         faXBDv0bGemCFIP9iLSj93C/951tqSw51NgRv4l9IdRNNp/Wr+XIwX8r3kOs3K67Fwz+
         egENC6d45DB31ysGOd5ibUVhdb54T9GFvd6znRFJQJGX//HcJFGCiN60uL+xYJVbXclm
         515FiD43JN5D+IhnfsHsBk58nn9xQVwMM0W4xFKam5Y4wndrXTxU93n+eNi00RraIAJE
         YgPErSqY4BOXz7qXrVrkGyNl1gfvp0/xbC5teRppGb7FI8Rr8heVy9GgXFj7EB7l1i2U
         y86Q==
X-Forwarded-Encrypted: i=1; AJvYcCXM5qtdXYAB9SPjfDO0P+ozUBEY9+LihR2Dtn/IgkKfaViMKh6l330DorwXYa5LmKwZ4z74AixoKsI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzDrToSIpwgr0lC7qcGpv86TOz9RLpx5Mv/jU06c8d1qtWul/a4
	gH5MNpceYL2lK5LFdipVFi+BN1hBCptSan92JSJhq/My4+uRi8Jp/65bx4lKHQ==
X-Gm-Gg: ASbGncvnKN6nepC0Ac5/ga4wY8GCRmVdbDRliYAOPrE/EcxGgv35xd8OxJqrTXDTBLT
	pcnLg8RFXCrQd+3woMUi8olWW2ka9oM7DJwYgqMSXims7NnKTOjo9HwjaszA4y5y5vko+u3NbKQ
	w7Z4dscwJnEqz81uDabD0RxhJSfRD7bvrWAzuIP01W/k6qKp1tSVW2dITJbmvoJPDaPLvpz0Tr8
	otMvRHQOMYVxr7aa5wmJM6fw9jh0aWQZBh7l1UQFiaDgLIRusJleLJnWLJC9LlXvEMQthEW4Rh0
	/x8LGFmMrHwlcUlBfbjrSYiYV59r727h42sgjsTYkQ==
X-Google-Smtp-Source: AGHT+IHxKEzJF/dcrVjwmLMVowgZF25El8uHNL0pJ1KNK3maRIBsa+PC/EtNmguZBjbYI+Ut6bPQTQ==
X-Received: by 2002:a05:600c:3b86:b0:434:fe4b:be18 with SMTP id 5b1f17b1804b1-436e26bde73mr47254595e9.18.1736413384881;
        Thu, 09 Jan 2025 01:03:04 -0800 (PST)
Message-ID: <251e1e4e-be4c-4327-8c9d-652dc064c41d@suse.com>
Date: Thu, 9 Jan 2025 10:03:03 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 03/18] x86/mm: introduce helper to detect per-domain L1
 entries that need freeing
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xenproject.org
References: <20250108142659.99490-1-roger.pau@citrix.com>
 <20250108142659.99490-4-roger.pau@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250108142659.99490-4-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 08.01.2025 15:26, Roger Pau Monne wrote:
> L1 present entries that require the underlying page to be freed have the
> _PAGE_AVAIL0 bit set, introduce a helper to unify the checking logic into a
> single place.
> 
> No functional change intended.
> 
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>

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

The name feels longish, yet perhaps that's acceptable here.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 09:10:29 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 09:10:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867897.1279432 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVoYa-0003Jd-Cw; Thu, 09 Jan 2025 09:10:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867897.1279432; Thu, 09 Jan 2025 09:10:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVoYa-0003JW-AO; Thu, 09 Jan 2025 09:10:24 +0000
Received: by outflank-mailman (input) for mailman id 867897;
 Thu, 09 Jan 2025 09:10: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 <SRS0=pS5t=UB=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVoYZ-0003JQ-Ky
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 09:10:23 +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 8e293693-ce69-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 10:10:22 +0100 (CET)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-385e3621518so354710f8f.1
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 01:10: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
 ffacd0b85a97d-38a8e385026sm1234186f8f.42.2025.01.09.01.10.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 01:10:21 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8e293693-ce69-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736413822; x=1737018622; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ReTD5UTlkgVXDxMMw9RuSPCkrgf4x0dJZIfb4+8JxpQ=;
        b=Qgm4HqpLU5AZ+SAer/ncVI0yCqSiaEQZ8hGT9AYndOYXGJCZ0ONI8YprVjIQm5MQAD
         5A1ING/s/HY7oqZpHE2+wki/p5lX+jJqu75r8HOqb3IXKYvr8GudC+3KV+JsXipKDA2c
         +d9Lhl4um4ns3plqtAZ85btgVCdzZdoMoQgALCCTXa5A71lNWuJj7UaeuJWQm7cJLx0E
         neEUGyowIjhbo8P3G5RgA0kpHBbpKaIqPoukV5o4m18Ie4+xHx7mxKkd4tGSc1i1rp5e
         nfGkxa+1E0GaUKr8X6VJdtnrcvoHzK2jeyG/y35GWYaIbQDzqPmPXmIhWkt7ZF/9fWaO
         oVhw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736413822; x=1737018622;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ReTD5UTlkgVXDxMMw9RuSPCkrgf4x0dJZIfb4+8JxpQ=;
        b=DutEdAuQMyTWvXfhfkksZuTA/xc+91JvEh5g1m4YQ0tRHC/40y+YsOCyKcExEfRAwk
         E2dLc7gTa+2y/mV8Ry+UM/Ff02JIMOgU6cxGtpJttTx2ksM2FRMMne2ySsofEbELp66c
         b0a7LXk5pjzPB6DuBnugb27s17pigmu7qXQzHIZWumXodp3wsc73NaPQygozF/A2AQBd
         Fcs4aW64WzaDKWDtz7E0/dhIRcluF70A4QPIFviP7sKbGeggROspzovjh6Ua1uvrUWyH
         lx1MLi6R3keRRFGiY57ZNSi4vMJ7u4CDyGFt3G9cZ8ol1A1m/Km/vl0H+8a3KBfy3Z7T
         r22A==
X-Forwarded-Encrypted: i=1; AJvYcCWtOZxK0bORmGg3iOBA9Y4Ao+OVVU2MSLKypyMwtDinJyU4atoAo4I8kvO4kgEkNgVnBRWdTWql61w=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzBNjE3c9xg9n/0r5k439kIzFVWuXWmkynGI8gFB5ywS+Un8aWI
	xtKwmDAzZx2WoyLfOupHWkbGjJJgCC0PKJJRNbiwiYxDd3MkOC4sNtCuRAI59g==
X-Gm-Gg: ASbGnctk+/5ORP6YYHj5aQaxretYMk9bDF4QGT/UQrH/y68JNkjjbHgZ17Z3+nczRiq
	RtWNUJOQtLCLIQNyi3PmJbrxdZbnAVuiZyR7iL5hBF8PoMVgIP1MlV+EIlOWvodJrfQ61by1wx3
	D5SRcIQBdrGynC7EgQjT03zw8Q8HvGNZd8FXdnrOmqCpX+oyIlRA5XZGRxmh6AFJHOL2rnAKAgY
	JWD9+/58fUnXaRQsVdq8C84mU6vQmL9r19GU9sjCIUh9QJhLeVtuhR3wtyUGKzVYQRivQiDLCaY
	VjOi6WobhKNJFLFgvNLGwC2HDTeezrA6wuH4JtjHhg==
X-Google-Smtp-Source: AGHT+IHyGw4RMavwxdWRx/ukFdOnAnfYQU2xYOUVEgyUWZtTnWVVX+f7ajmZDmcQhNQ59otFcKVbEw==
X-Received: by 2002:a05:6000:4026:b0:385:e328:890a with SMTP id ffacd0b85a97d-38a8735576fmr4900425f8f.49.1736413821857;
        Thu, 09 Jan 2025 01:10:21 -0800 (PST)
Message-ID: <031ce31b-0ab5-4964-96eb-642fbea67bfb@suse.com>
Date: Thu, 9 Jan 2025 10:10:20 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 04/18] x86/pv: introduce function to populate perdomain
 area and use it to map Xen GDT
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xenproject.org
References: <20250108142659.99490-1-roger.pau@citrix.com>
 <20250108142659.99490-5-roger.pau@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250108142659.99490-5-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 08.01.2025 15:26, Roger Pau Monne wrote:
> The current code to update the Xen part of the GDT when running a PV guest
> relies on caching the direct map address of all the L1 tables used to map the
> GDT and LDT, so that entries can be modified.
> 
> Introduce a new function that populates the per-domain region, either using the
> recursive linear mappings when the target vCPU is the current one, or by
> directly modifying the L1 table of the per-domain region.
> 
> Using such function to populate per-domain addresses drops the need to keep a
> reference to per-domain L1 tables previously used to change the per-domain
> mappings.

Well, yes. You now record MFNs instead. And you do so at the expense of about
100 lines of new code. I'm afraid I'm lacking justification for this price to
be paid.

> @@ -2219,11 +2219,9 @@ void __init trap_init(void)
>      init_ler();
>  
>      /* Cache {,compat_}gdt_l1e now that physically relocation is done. */
> -    this_cpu(gdt_l1e) =
> -        l1e_from_pfn(virt_to_mfn(boot_gdt), __PAGE_HYPERVISOR_RW);
> +    this_cpu(gdt_mfn) = _mfn(virt_to_mfn(boot_gdt));
>      if ( IS_ENABLED(CONFIG_PV32) )
> -        this_cpu(compat_gdt_l1e) =
> -            l1e_from_pfn(virt_to_mfn(boot_compat_gdt), __PAGE_HYPERVISOR_RW);
> +        this_cpu(compat_gdt_mfn) = _mfn(virt_to_mfn(boot_compat_gdt));

The comment's going stale this way.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 09:15:50 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 09:15:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867906.1279442 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVodk-00046a-VE; Thu, 09 Jan 2025 09:15:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867906.1279442; Thu, 09 Jan 2025 09:15:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVodk-00046T-ST; Thu, 09 Jan 2025 09:15:44 +0000
Received: by outflank-mailman (input) for mailman id 867906;
 Thu, 09 Jan 2025 09:15: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 <SRS0=pS5t=UB=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVodj-00046N-Tn
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 09:15:43 +0000
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com
 [2a00:1450:4864:20::429])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4d1f86c8-ce6a-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 10:15:42 +0100 (CET)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-385deda28b3so419431f8f.0
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 01:15:42 -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
 ffacd0b85a97d-38a8e38534csm1234492f8f.43.2025.01.09.01.15.41
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 01:15:42 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 4d1f86c8-ce6a-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736414142; x=1737018942; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=iyzU/cUzk2LH8NpPzK0OwHv7l9Z7kuV/bfRVRjL2PZ8=;
        b=XQcEj4zkYvSQTWuEQM+2o0b4blKQymtEEbMqyVCGY5kUeXV/2MqaalJ3IW4mZUOdIR
         CzeExL5TcYv0ngsKEzyaPlIZ9Y346nta4hdtcOxF0CN2QQhWZ2VsaYYZRcUpdOl27vwP
         Gq2KLYpG32XWp++db0dO+9/JwoXybHmESJyKnLLifHEi0H0eVH51OxyMghkiPEdMSGKj
         nPHgbpzd23/Gjn6bo97MzofCpFaSrh9vRBzlLF2pL0Q/xqcBll1/SErblk8KKGz62KJc
         qCj84fjm7DL0JwaOxpGSamvyW7AKf7AoZYU7JBjuO2+iccvfysmVBO5hRj8hzJrL6H5B
         N5Hw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736414142; x=1737018942;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=iyzU/cUzk2LH8NpPzK0OwHv7l9Z7kuV/bfRVRjL2PZ8=;
        b=dyHB+fzoxsybSQIzvuRNwyl/wk2m0c5rw2sYCTsCWGwhffQFpmwA7olmLXompNPhhs
         aWBaik5O3T7vGlRw7qmgrl78AVZ+SDFDnfqG/9z1SrLJz5s59nNan7jjG02UqK/z5Eg3
         cWY289jYngV028bL0zaBtOVvmsJsmTS/9BqZQYNV6RvboV9QyAk3jEb5OlNm7ESkuB/+
         qhjRyJhYKVqqSCJIBedZzUYBTbrJBVsSz0nP/zPeOvMNGjYqbooi4+6PfUzW7HKrN/h0
         l6aicqCU41fpEHExoaqFD1Ba55KGlrAng7aTg8ZkeJcj/WMygDmUMs/miEMPfyD+3iXy
         8zeQ==
X-Forwarded-Encrypted: i=1; AJvYcCU7iNrz1SEfP/9/zjwkYTGfbS8HcYZNXif3SrDxj97kqqrR+iq/ZG4IK4xio50OxwySAUFiMWiaTcU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxR4w/mNH8aL8a83CihDb7LIvvJN5FB8p/hBtHl27PAInJSFeVO
	TuGl8k1TKaxf6HHM+f6G1XNSqblK89yK4nqoL2rbOGrsj4hQrpHWLc+FulpnMQ==
X-Gm-Gg: ASbGncuE3Wt8UtgPXr4omjJCVQfKvwVSYkyBL/r1BjuYlqOtVr/Ip/WP4jrmTYUMuwO
	lVV8YIVrqI+eUZ/NejzWijl6Wd3gwGui32+1xuSshOGuYFMkPGI1ew6fYlYqVWlt3Gq+xt/nvqX
	OmzxMQ0mEciAVjpu3pPzMbRJwy33QYTA9weQ0Uc82jUBBlSwGooKT8lDDll12T1GWbif+SHtrUo
	4rzUCYl6G2H8T1IB52P4OBU6Dthw2CubNrjXaf9ndJLFZCmP+CGW3RtzuG8RSB6cPgQrGgtMNTM
	k3QX4eonHBCLURIrHDteweE19J4j7a/LjePQ/jkOmQ==
X-Google-Smtp-Source: AGHT+IFlfxW2oE9v6/k1dbF1wQhbWmZQN50dJq+WYoi2nAzsCsMfZYfuLwgEk9xbC+skquoUx4sgQg==
X-Received: by 2002:a5d:648a:0:b0:385:f0c9:4b66 with SMTP id ffacd0b85a97d-38a87313097mr4261029f8f.33.1736414142297;
        Thu, 09 Jan 2025 01:15:42 -0800 (PST)
Message-ID: <a769ef28-5794-45a0-bb3f-e3dc3e3bcef3@suse.com>
Date: Thu, 9 Jan 2025 10:15:40 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/mm: Introduce per-arch pte_attr_t type for PTE flags
To: Shawn Anastasio <sanastasio@raptorengineering.com>
Cc: tpearson@raptorengineering.com, Andrew Cooper
 <andrew.cooper3@citrix.com>, Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 "Daniel P. Smith" <dpsmith@apertussolutions.com>,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, xen-devel@lists.xenproject.org
References: <47babd3f9ec00c15738a81aa57926e8a1f08cbe6.1735669493.git.sanastasio@raptorengineering.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <47babd3f9ec00c15738a81aa57926e8a1f08cbe6.1735669493.git.sanastasio@raptorengineering.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 31.12.2024 19:27, Shawn Anastasio wrote:
> Xen's memory management APIs map_pages_to_xen, modify_xen_mappings,
> set_fixmap, ioremap_attr, and __vmap all use an unsigned int to
> represent architecture-dependent page table entry flags. This assumption
> does not work on PPC/radix where some flags go past 32-bits, so
> introduce the pte_attr_t type to allow architectures to opt in to larger
> types to store PTE flags.
> 
> Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Shawn Anastasio <sanastasio@raptorengineering.com>

As iirc Andrew had indicated when suggesting this, what you say for PPC is
true for x86 as well. Yet still we get around with unsigned int. Hence I
think the change needs describing differently.

> --- a/xen/include/xen/mm.h
> +++ b/xen/include/xen/mm.h
> @@ -70,6 +70,10 @@
>  #include <xen/perfc.h>
>  #include <public/memory.h>
>  
> +#ifndef CONFIG_HAS_PTE_ATTR_T
> +typedef unsigned int pte_attr_t;
> +#endif

This imo makes the Kconfig control a misnomer: We'll always have pte_attr_t.
I wonder whether this actually needs a Kconfig setting in the first place:
It's hardly the end of the world for all architectures to specify the type
(later: the underlying type, for the real type to become type-safe)
explicitly.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 09:23:50 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 09:23:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867919.1279452 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVolV-0005wX-QY; Thu, 09 Jan 2025 09:23:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867919.1279452; Thu, 09 Jan 2025 09:23:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVolV-0005wQ-Nx; Thu, 09 Jan 2025 09:23:45 +0000
Received: by outflank-mailman (input) for mailman id 867919;
 Thu, 09 Jan 2025 09:23: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 <SRS0=pS5t=UB=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVolU-0005wK-Rl
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 09:23:44 +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 6bc532ab-ce6b-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 10:23:43 +0100 (CET)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-435f8f29f8aso5329855e9.2
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 01:23:43 -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
 5b1f17b1804b1-436e2ddd113sm49604675e9.25.2025.01.09.01.23.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 01:23:42 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 6bc532ab-ce6b-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736414623; x=1737019423; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=2viDDTUr2f5ynhC6H7ht9PYN7Rsdi7Q9mOfRDowWPhg=;
        b=JwQWC/2Gxi16xHZokZMiP01bhudEnj2BRlXozrjANqx72NhZeI7O3Ifflt3b+8MMCM
         NB12i5l1rKcRxy5xf4wbEBPKJXiODHVrZO0NhvKMNQkRT7sFRWKbVOG+oKBtmxRnXv55
         nIz8M3qxO1x5e7zsW3K6n07pd3GkYs6Ru1yGy1mdRJPyY2OEdpaYFRM84dnIc49ct0vb
         RUe0umXjU0rijkDtHUty5oX/D6lFj+f59xUgli1MMx5QvpEY76ApOC1yCncSFbFxCKxk
         yjmyDkFtFzc9uAtcvsJKvjmv7QUEy1ABjevBV+da8eWTK5UlHxiAkZ75E+bZQkvBia+1
         czqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736414623; x=1737019423;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=2viDDTUr2f5ynhC6H7ht9PYN7Rsdi7Q9mOfRDowWPhg=;
        b=GTTTumRelCxeGiJTcw+s2YzpU7i5nJh57ZN0Rj+lrzvgNq9+wZSP5POsunSiRIRnu1
         Vba3WanJek8AjdiNCpANfwd2F0MPOIy2UA3AP94292A1Ziv7ZilN3qVQbW3AGhL+Kn9M
         ZnxLdTbRYvPPcg6nAXaruM9PNHFp4F5vigfSAPa7MkxC9UA2vHR3lngq+qqcL6WpIBEF
         onmgJYjo92iyjQ+h+W9AX812Tdjb2vpJPdO8JOwSZOuYS9EOy3Iw9+Ygfn/+4Z58a0J4
         SLM1ZBwMTzy/AL1NfOowtqva+mlDr0CZNDUsY+7jyoBN0RqKlY3YycfL7jnO4PLK/AvX
         eQ+w==
X-Forwarded-Encrypted: i=1; AJvYcCWuj0eDWd3f4iSlm61emBAOsJomaDpjWlHCTYou6ZCG7QDb0hLmgSzSbOfFNJ24wfrErlribaJk/7w=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzmpGZ87v7PFWoszKaFGXHyFGtLbbsV6pqK6m3XcO9r8V8aCcFz
	edshTfmY/p5hL4KvHQAw+g7+w45+nsbvdv86G+mK+JYloXOjcr4Wr9NLZCH3rQ==
X-Gm-Gg: ASbGnct5XG5QtJPgNHZvTnV660l1fYQV7xIK0nZnyfxShlwu+g37VhY4p9XywvuuXkJ
	bvV0nC4wt8lVF+7q48n5ZDjqtYiO34lYBScpCzWMQvn0N7qBpkDy+vBGCxYhECu7uu4fCTA2bap
	vw29EmrV5VKeMX/MAegPh3yKpCoBDJBe2bbyd4nxfiUAAHLVm3AqldFcsZisBJPU/J2MSAkZv5Y
	ybNcU8D+71aAKAsHtBZ530TXagIiALyEhgE7V0Hawz8IvZC7nyH5FQXcBczc/kn+nrX4yOKades
	5VZeQHQDSGtmUIa0z7PDZRompriVRkt/ngroI9ZK9A==
X-Google-Smtp-Source: AGHT+IFTF5rTQ23ubzfbgb6f7mk097eOUcRygQHvGBv9v86gBJD5sxS/iZnpzSRMAnx0DPtSeni8VQ==
X-Received: by 2002:a05:600c:154e:b0:42c:b16e:7a22 with SMTP id 5b1f17b1804b1-436e2697066mr53354395e9.12.1736414622945;
        Thu, 09 Jan 2025 01:23:42 -0800 (PST)
Message-ID: <e831eb1c-be8e-49f2-81af-ba4ed5ab40dd@suse.com>
Date: Thu, 9 Jan 2025 10:23:41 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/cpu: Support Hygon architecture CPU during NMI
 initialization.
To: banmengtao <banmengtao@zju.edu.cn>
Cc: banmengtao <jiuxie@outlook.com>, Andrew Cooper
 <andrew.cooper3@citrix.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, xen-devel@lists.xenproject.org
References: <20250104111109.2726-1-banmengtao@zju.edu.cn>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250104111109.2726-1-banmengtao@zju.edu.cn>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04.01.2025 12:11, banmengtao wrote:
> From: banmengtao <jiuxie@outlook.com>
> 
> When I installed Xen on Ubuntu 22.04 and rebooted into the kernel, it kept freezing and threw an exception: "Unsupported processor. Unknown vendor 16."

That's no really an exception, though.

> This patch fixes the issue where the Hygon CPU could not be recognized when entering the Xen kernel.

You mention two issues (freezing and the log message). I find it hard to
believe (without better details) that both are addressed by just the
change below. Please clarify. The patch title may also need adjustment,
as more general NMI setup (e.g. for the watchdog) lives elsewhere. The
change here is about oprofile only.

> --- a/xen/arch/x86/oprofile/nmi_int.c
> +++ b/xen/arch/x86/oprofile/nmi_int.c
> @@ -398,6 +398,7 @@ static int __init cf_check nmi_init(void)
>  
>  	switch (vendor) {
>  		case X86_VENDOR_AMD:
> +		case X86_VENDOR_HYGON:
>  			/* Needs to be at least an Athlon (or hammer in 32bit mode) */
>  
>  			switch (family) {
> @@ -435,6 +436,11 @@ static int __init cf_check nmi_init(void)
>  				model = &op_athlon_spec;
>  				cpu_type = "x86-64/family16h";
>  				break;
> +			case 0x18:
> +				model = &op_athlon_spec;
> +				cpu_type = "x86-64/family18h";
> +				break;
> +
>  			}
>  			break;

Note how AMD Fam 17 and 19 aren't present here either. Yet Xen boots fine
there. So (as mentioned above already) quite likely there's more to the
problems you observe on Hygon.

Finally (nit): If already you add a blank line, please add it ahead of the
new case block rather than after it.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 09:28:32 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 09:28:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867927.1279463 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVoq6-0006Xr-C8; Thu, 09 Jan 2025 09:28:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867927.1279463; Thu, 09 Jan 2025 09:28:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVoq6-0006Xk-8n; Thu, 09 Jan 2025 09:28:30 +0000
Received: by outflank-mailman (input) for mailman id 867927;
 Thu, 09 Jan 2025 09:28:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=FDwX=UB=arm.com=luca.fancellu@srs-se1.protection.inumbo.net>)
 id 1tVoq4-0006Xe-Nl
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 09:28:28 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id 1401d896-ce6c-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 10:28:26 +0100 (CET)
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id DB0AC1516;
 Thu,  9 Jan 2025 01:28:53 -0800 (PST)
Received: from e125770.cambridge.arm.com (e125770.arm.com [10.1.199.43])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C20723F59E;
 Thu,  9 Jan 2025 01:28:24 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1401d896-ce6c-11ef-a0df-8be0dac302b0
From: Luca Fancellu <luca.fancellu@arm.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: [PATCH v2] xen/arm: Fully initialise struct membanks_hdr fields
Date: Thu,  9 Jan 2025 09:28:16 +0000
Message-Id: <20250109092816.1619834-1-luca.fancellu@arm.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Commit a14593e3995a ("xen/device-tree: Allow region overlapping with
/memreserve/ ranges") introduced a type in the 'struct membanks_hdr'
but forgot to update the 'struct kernel_info' initialiser, while
it doesn't lead to failures because the field is not currently
used while managing kernel_info structures, it's good to have it
for completeness.

There are other instance of structures using 'struct membanks_hdr'
that are dynamically allocated and don't fully initialise these
fields, provide a static inline helper for that.

Fixes: a14593e3995a ("xen/device-tree: Allow region overlapping with /memreserve/ ranges")
Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
---
Changes from v1:
 - Changed commit title and body msg
 - initialised max_banks and type for all structures using 'struct membanks_hdr'

I didn't get why the fixes tag is wrong, but please feel free to
correct it on commit or suggest the good one
---
---
 xen/arch/arm/domain_build.c       | 13 ++++---------
 xen/arch/arm/include/asm/kernel.h |  5 ++++-
 xen/arch/arm/static-shmem.c       |  3 ++-
 xen/include/xen/bootfdt.h         | 16 ++++++++++++++++
 4 files changed, 26 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index b072a16249fe..9e3132fb21d8 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1039,7 +1039,7 @@ void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
      */
     if ( is_hardware_domain(d) )
     {
-        struct membanks *gnttab = xzalloc_flex_struct(struct membanks, bank, 1);
+        struct membanks *gnttab = membanks_xzalloc(1, RESERVED_MEMORY);
         /*
          * Exclude the following regions:
          * 1) Remove reserved memory
@@ -1057,13 +1057,10 @@ void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
         gnttab->bank[0].start = kinfo->gnttab_start;
         gnttab->bank[0].size = kinfo->gnttab_size;
 
-        hwdom_free_mem = xzalloc_flex_struct(struct membanks, bank,
-                                             NR_MEM_BANKS);
+        hwdom_free_mem = membanks_xzalloc(NR_MEM_BANKS, MEMORY);
         if ( !hwdom_free_mem )
             goto fail;
 
-        hwdom_free_mem->max_banks = NR_MEM_BANKS;
-
         if ( find_unallocated_memory(kinfo, mem_banks, ARRAY_SIZE(mem_banks),
                                      hwdom_free_mem, add_hwdom_free_regions) )
             goto fail;
@@ -1293,7 +1290,7 @@ static int __init find_host_extended_regions(const struct kernel_info *kinfo,
                                              struct membanks *ext_regions)
 {
     int res;
-    struct membanks *gnttab = xzalloc_flex_struct(struct membanks, bank, 1);
+    struct membanks *gnttab = membanks_xzalloc(1, RESERVED_MEMORY);
 
     /*
      * Exclude the following regions:
@@ -1374,12 +1371,10 @@ int __init make_hypervisor_node(struct domain *d,
     }
     else
     {
-        ext_regions = xzalloc_flex_struct(struct membanks, bank, NR_MEM_BANKS);
+        ext_regions = membanks_xzalloc(NR_MEM_BANKS, RESERVED_MEMORY);
         if ( !ext_regions )
             return -ENOMEM;
 
-        ext_regions->max_banks = NR_MEM_BANKS;
-
         if ( domain_use_host_layout(d) )
         {
             if ( !is_iommu_enabled(d) )
diff --git a/xen/arch/arm/include/asm/kernel.h b/xen/arch/arm/include/asm/kernel.h
index 7e6e3c82a477..de3f945ae54c 100644
--- a/xen/arch/arm/include/asm/kernel.h
+++ b/xen/arch/arm/include/asm/kernel.h
@@ -92,7 +92,9 @@ kernel_info_get_mem_const(const struct kernel_info *kinfo)
 }
 
 #ifdef CONFIG_STATIC_SHM
-#define KERNEL_INFO_SHM_MEM_INIT .shm_mem.common.max_banks = NR_SHMEM_BANKS,
+#define KERNEL_INFO_SHM_MEM_INIT                \
+    .shm_mem.common.max_banks = NR_SHMEM_BANKS, \
+    .shm_mem.common.type = STATIC_SHARED_MEMORY,
 #else
 #define KERNEL_INFO_SHM_MEM_INIT
 #endif
@@ -100,6 +102,7 @@ kernel_info_get_mem_const(const struct kernel_info *kinfo)
 #define KERNEL_INFO_INIT                        \
 {                                               \
     .mem.common.max_banks = NR_MEM_BANKS,       \
+    .mem.common.type = MEMORY,                  \
     KERNEL_INFO_SHM_MEM_INIT                    \
 }
 
diff --git a/xen/arch/arm/static-shmem.c b/xen/arch/arm/static-shmem.c
index 66088a426785..8f87154c3587 100644
--- a/xen/arch/arm/static-shmem.c
+++ b/xen/arch/arm/static-shmem.c
@@ -20,7 +20,8 @@ static struct {
     struct membanks_hdr common;
     struct membank bank[NR_SHMEM_BANKS];
 } shm_heap_banks __initdata = {
-    .common.max_banks = NR_SHMEM_BANKS
+    .common.max_banks = NR_SHMEM_BANKS,
+    .common.type = STATIC_SHARED_MEMORY
 };
 
 static inline struct membanks *get_shmem_heap_banks(void)
diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
index c8bbfd8979b2..80a90e53c001 100644
--- a/xen/include/xen/bootfdt.h
+++ b/xen/include/xen/bootfdt.h
@@ -4,6 +4,7 @@
 #include <xen/types.h>
 #include <xen/kernel.h>
 #include <xen/macros.h>
+#include <xen/xmalloc.h>
 
 #define MIN_FDT_ALIGN 8
 
@@ -219,4 +220,19 @@ static inline struct shmem_membank_extra *bootinfo_get_shmem_extra(void)
 }
 #endif
 
+static inline struct membanks *membanks_xzalloc(unsigned int nr,
+                                                enum region_type type)
+{
+    struct membanks *banks = xzalloc_flex_struct(struct membanks, bank, nr);
+
+    if ( !banks )
+        goto out;
+
+    banks->max_banks = nr;
+    banks->type = type;
+
+ out:
+    return banks;
+}
+
 #endif /* XEN_BOOTFDT_H */
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 09:45:50 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 09:45:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867937.1279472 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVp6m-00014z-MC; Thu, 09 Jan 2025 09:45:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867937.1279472; Thu, 09 Jan 2025 09:45:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVp6m-00014s-JC; Thu, 09 Jan 2025 09:45:44 +0000
Received: by outflank-mailman (input) for mailman id 867937;
 Thu, 09 Jan 2025 09:45: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 <SRS0=pS5t=UB=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVp6k-00014m-VT
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 09:45:42 +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 7d3d90d5-ce6e-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 10:45:41 +0100 (CET)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-4361c705434so5505285e9.3
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 01:45:41 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a8e4b7ff0sm1322972f8f.77.2025.01.09.01.45.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 01:45:40 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 7d3d90d5-ce6e-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736415941; x=1737020741; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=q0LmkG/gDa/UWJi/v5fRxjkGy5FqsZItXo1ySAuCzyc=;
        b=EQAso8wlaJX0ejj5gT1RvETcdqelolMVj+zqj/BM8Nhxts3wXo46cMoP71tPIXM12B
         /ZiEwo9yxBsphCEHI/ZkC1x18Czg4rOAC3Us9CsRPa66C0gdICseSjY17XieKAm1TiiU
         uTOecYk0iSATP9eYj2tN7DOEcxY3MsZBXM/jB7vZ253HTwe/fye6v2XOUfhUHb+P3elL
         fqz/BG1VzooLsBXyfyWxerw2F461fnvrOE+P9N+C/biER/5QMCar29s8aaAkYNHvM8h3
         zUPHw5NOHQlCCk+b+zrtewvCFb87xRHdlxJ5+1hv98k0JJ4BJF7kClc1+fGOoOdMJeK2
         iUdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736415941; x=1737020741;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=q0LmkG/gDa/UWJi/v5fRxjkGy5FqsZItXo1ySAuCzyc=;
        b=hlw09smkfRVit1h3Ush0xx5mTAlRbUlmf5Za97137r8b1FlUlSjuw5B/YkDDlXxms9
         BkXPVYBQ40mv9l+cajX+GKHOc71TixO4Inbhg1KF1MCdfCfkUNtwGcLOJ7QFE8gdjStB
         H0NlBUoN04UdWuK/vtvEb2v0trn08wstnn3WzhOJ+V6GGHcxI/UmERE8lE0ZORxSu3Sd
         1Cd+Di8fn39kzp82rKp2TzYtADAzmyj67fk+bgCI4nOTTYsbv/PReSEQ9eS1ZzME6obs
         E9yUz9x0zpAcsjyoTaC5E7mmMOHAx/A1VI0SpN8DAKPAGI2d5o+lqE6Xfoo9u8IuG2x4
         zw7A==
X-Forwarded-Encrypted: i=1; AJvYcCUPMSIR5sHb6IEkHGKFNxJjnkrGahXalTLzYVs1fKMoqdNwKiXcxxcfHzLL/1o6Y0wuZhjF6leKCgU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyoIARATg01wVsPDiSKHnYUXbgLgq4fVgL/zQetbsn3xOP5qVh9
	13AZ6EjtvORcUs5ZXpy1myJdup00Gqn7Ajh9I2q7c4c2dcB6ObsSNMFUYctKpg==
X-Gm-Gg: ASbGncu2fZ2z3FDYEpSStaZZ6VIVX1aTvZ2Lp0tLrZuK6lObk1kK1wp3PdsBJb2hDL3
	pxb/ylSyq1LM06UDqD7PqJnQOG8EXYsOQMVDyB8tgWH03UV5MU1clX8jufc/+ysheM8UJncWFK1
	FnLHvj5maWono8ikuwOipl2GLS7qczYC2FCGxhKWNUMv2JC3a51paJ37EY0jQuyuFPtwqASjtls
	5ljTsw0duVNc6pgvD9XRaCVGRvOstzXtxFPD5Kve/rKjqjpKoIciFJX4imLBUW04IiREQYCmYEm
	0ZpRog0MUVqcAq5Rg3Z9136etUVFItYsngyFcckpKg==
X-Google-Smtp-Source: AGHT+IEtATmC1gzxs7n6LyXL2ssMD86kNYEoGs6/OxwbF6Nmo2duaDgkEm2hKrBz90Ifpsdrc53eHQ==
X-Received: by 2002:a5d:5f85:0:b0:385:e013:39ec with SMTP id ffacd0b85a97d-38a872f6a6bmr4834617f8f.8.1736415940959;
        Thu, 09 Jan 2025 01:45:40 -0800 (PST)
Message-ID: <95183589-1a83-4c99-ade4-d37873b85e0a@suse.com>
Date: Thu, 9 Jan 2025 10:45:38 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 02/11] xen/x86: introduce new sub-hypercall to get CPPC
 data
To: Penny Zheng <Penny.Zheng@amd.com>
Cc: stefano.stabellini@amd.com, Ray.Huang@amd.com, Xenia.Ragiadakou@amd.com,
 Jason.Andryuk@amd.com, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>,
 xen-devel@lists.xenproject.org
References: <20241203081111.463400-1-Penny.Zheng@amd.com>
 <20241203081111.463400-3-Penny.Zheng@amd.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20241203081111.463400-3-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 03.12.2024 09:11, Penny Zheng wrote:
> In order to provide backward compatibility with existing governors
> that represent performance as frequencies, like ondemand, the _CPC
> table can optionally provide processor frequency range values, Lowest
> frequency and Norminal frequency, to let OS use Lowest Frequency/
> Performance and Nominal Frequency/Performance as anchor points to
> create linear mapping of CPPC abstract performance to CPU frequency.
> 
> As Xen is uncapable of parsing the ACPI dynamic table, this commit
> introduces a new sub-hypercall to get required CPPC data from
> dom0 kernel.

"get" as used both here and in the title is, to me, something an entity
does actively. Xen is entirely passive here, though. (Reading the title
I was first assuming this is about a sub-op to get certain data out of
Xen.)

> --- a/xen/arch/x86/platform_hypercall.c
> +++ b/xen/arch/x86/platform_hypercall.c
> @@ -572,6 +572,12 @@ ret_t do_platform_op(
>              break;
>          }
>  
> +        case XEN_PM_CPPC:
> +        {
> +            ret = set_cppc_pminfo(op->u.set_pminfo.id, &op->u.set_pminfo.u.cppc_data);
> +        }
> +        break;

No such unnecessary figure braces please, which - once dropped - will
also call for "break" to be indented one level deeper.

> --- a/xen/arch/x86/x86_64/cpufreq.c
> +++ b/xen/arch/x86/x86_64/cpufreq.c
> @@ -54,3 +54,21 @@ int compat_set_px_pminfo(uint32_t acpi_id,
>  
>      return set_px_pminfo(acpi_id, xen_perf);
>  }
> +
> +int compat_set_cppc_pminfo(uint32_t acpi_id,
> +                           struct compat_processor_cppc *cppc_data)
> +{
> +    struct xen_processor_cppc *xen_cppc;
> +    unsigned long xlat_page_current;
> +
> +    xlat_malloc_init(xlat_page_current);
> +
> +    xen_cppc = xlat_malloc_array(xlat_page_current,
> +                                    struct xen_processor_cppc, 1);
> +    if ( unlikely(xen_cppc == NULL) )
> +        return -EFAULT;
> +
> +    XLAT_processor_cppc(xen_cppc, cppc_data);
> +
> +    return set_cppc_pminfo(acpi_id, xen_cppc);
> +}

Why's this needed? The structure - for now at least - consists of only
uint32_t-s, and hence has identical layout for compat callers.

> --- a/xen/drivers/cpufreq/cpufreq.c
> +++ b/xen/drivers/cpufreq/cpufreq.c
> @@ -458,6 +458,56 @@ static void print_PPC(unsigned int platform_limit)
>      printk("\t_PPC: %d\n", platform_limit);
>  }
>  
> +static void print_CPPC(struct xen_processor_cppc *cppc_data)

Pointer-to-const?

> +{
> +    printk("\t_CPC: highest_perf=%u, lowest_perf=%u, "
> +           "nominal_perf=%u, lowest_nonlinear_perf=%u, "
> +           "nominal_freq=%uMhz, lowest_freq=%uMhz\n",
> +           cppc_data->highest_perf, cppc_data->lowest_perf,
> +           cppc_data->nominal_perf, cppc_data->lowest_nonlinear_perf,
> +           cppc_data->nominal_freq, cppc_data->lowest_freq);
> +}
> +
> +int set_cppc_pminfo(uint32_t acpi_id, struct xen_processor_cppc *cppc_data)

Pointer-to-const?

> +{
> +    int ret = 0, cpuid;
> +    struct processor_pminfo *pm_info;
> +
> +    cpuid = get_cpu_id(acpi_id);
> +    if ( cpuid < 0 || !cppc_data )
> +    {
> +        ret = -EINVAL;
> +        goto out;
> +    }
> +    if ( cpufreq_verbose )
> +        printk("Set CPU acpi_id(%d) cpuid(%d) CPPC State info:\n",
> +               acpi_id, cpuid);
> +
> +    pm_info = processor_pminfo[cpuid];
> +    if ( !pm_info )
> +    {
> +        pm_info = xzalloc(struct processor_pminfo);

Please be aware that new code is supposed to be using xvmalloc().

> +        if ( !pm_info )
> +        {
> +            ret = -ENOMEM;
> +            goto out;
> +        }
> +        processor_pminfo[cpuid] = pm_info;
> +    }
> +    pm_info->acpi_id = acpi_id;
> +    pm_info->id = cpuid;
> +
> +    memcpy ((void *)&pm_info->cppc_data,
> +            (void *)cppc_data,
> +            sizeof(struct xen_processor_cppc));

What use are these casts? Also please no blank before the opening parenthesis
of a function call, and please sizeof(*cppc_data). Yet then - why memcpy() in
the first place? This can be a (type safe) structure assignment, can't it?

> --- a/xen/include/public/platform.h
> +++ b/xen/include/public/platform.h
> @@ -363,6 +363,7 @@ DEFINE_XEN_GUEST_HANDLE(xenpf_getidletime_t);
>  #define XEN_PM_PX   1
>  #define XEN_PM_TX   2
>  #define XEN_PM_PDC  3
> +#define XEN_PM_CPPC 4
>  
>  /* Px sub info type */
>  #define XEN_PX_PCT   1
> @@ -432,6 +433,15 @@ struct xen_processor_px {
>  typedef struct xen_processor_px xen_processor_px_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_processor_px_t);
>  
> +struct xen_processor_cppc {
> +    uint32_t highest_perf;
> +    uint32_t nominal_perf;
> +    uint32_t lowest_perf;
> +    uint32_t lowest_nonlinear_perf;
> +    uint32_t lowest_freq;
> +    uint32_t nominal_freq;
> +};

_CPC contains a lot more data. Please clarify on what basis this subset was
chosen. (Keeping the chosen fields in the order _CPC has them might also be
a good idea.)

> --- a/xen/include/xlat.lst
> +++ b/xen/include/xlat.lst
> @@ -166,6 +166,7 @@
>  !	processor_cx			platform.h
>  !	processor_flags			platform.h
>  !	processor_performance		platform.h
> +!	processor_cppc			platform.h
>  !	processor_power			platform.h
>  ?	processor_px			platform.h
>  !	psd_package			platform.h

Please obey to alphabetic sorting. As per an earlier comment I also expect
this wants to be using '?' in place of '!'.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 09:55:58 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 09:55:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867946.1279482 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVpGa-0002qW-IO; Thu, 09 Jan 2025 09:55:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867946.1279482; Thu, 09 Jan 2025 09:55:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVpGa-0002qP-FT; Thu, 09 Jan 2025 09:55:52 +0000
Received: by outflank-mailman (input) for mailman id 867946;
 Thu, 09 Jan 2025 09:55:51 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=bl7y=UB=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tVpGZ-0002qH-QA
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 09:55:51 +0000
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com
 [2a00:1450:4864:20::32a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e74e0026-ce6f-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 10:55:49 +0100 (CET)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-436a39e4891so5358695e9.1
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 01:55:49 -0800 (PST)
Received: from localhost ([66.81.170.107]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436e9e37c17sm15151555e9.27.2025.01.09.01.55.46
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 01:55:48 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e74e0026-ce6f-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736416548; x=1737021348; darn=lists.xenproject.org;
        h=in-reply-to:references:from:subject:cc:to:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=e5ze1jAUAJrU/mqlh6re5lCEkd/F9jk6JppPFxVKCH8=;
        b=BwqY3xFN1nMwMDqUpTztTMjnAn/Wa0Y+RGtn9owKYzIg0ACaSZH9r0VVN+WZuuxfA+
         AWd9XXO7zFXlWBHrop90l8v8VOHqKRaw+Ncje5QEw/BOZzUumcmcNtbqKV+EzFrS053P
         4fqQgcwNbqUjTt/HgEPGofs/miwJYtK9RlxuU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736416548; x=1737021348;
        h=in-reply-to:references:from:subject:cc:to:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=e5ze1jAUAJrU/mqlh6re5lCEkd/F9jk6JppPFxVKCH8=;
        b=MXb79YF2GsF1vE6KPW2ADL28iZ0IOn2hcSRth9bUP/MhIWFuzt03vQMtt8OJ6cixnX
         ZoLzFlsRoTfam+k1rkZnnWlA6j5vBiObp69EAJl+m+43GFfqHcP9u3/5ZvfTYPdQoFDu
         9xA0EAARXTZnOybbmGcnEJ+DfYSL8i2+VPG5uAKlvSUfKIQmZXQSdXC+RpWkNzl54jbM
         gZexBAM9fFjiERFiVdE21CDAaHsFSOkAkFeUHbbQqxxG0imaPbTNh6gMQMXkUQxDZqXK
         P2LTDXrIzju//22yqNIHo1i2oyGqsUo7RTDV3TTN1pBdil6lA70JxeaqnbHLEZk7PLlx
         6l9g==
X-Forwarded-Encrypted: i=1; AJvYcCX6uZgLFQRQqx9IDs3IpaiE6U1GCU2Ybx/HoUVW+TZumxUlkjuMjTrx/zuScycbnM1pswVkVZFSdFU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwBF89eG6zEOaleafuAXNPw734PTqCXY4oxwVPB8+llPLLp0NUS
	zYgiBpoK3RadH35hD/EjeK6P/Kpa0IQdp/3lNe1iQD7xnvDoei5pL+bKGZisO4I=
X-Gm-Gg: ASbGncu7wIVpP+BE+hjGOHqOA96Mdf/Ye4ma0ambfZFmznqfKJfRxZQhd4KcxXV97xT
	i+nlwf+6DB+K4I1pbHUxysSZEzxpFWkdZKG2Gxwxz0Jn9EJrruBznYgrLNFfKLGAAZ+t7VtTPz6
	5HvfaO+qQZPKh+u1ykkFBmElUaGcLS6F/paCZHG4bb17ACkpArd4iuumWjLawNtYFWa4zvIrB6/
	k34BJWNg8ai7VQRacxkiZbgUJ+pOOn4t05HbZHrpf3E7dn3RPmoGuqEshzkVu0=
X-Google-Smtp-Source: AGHT+IFpYt+jJjz7htu8g0ZTzUImdNVt5vgoYuHGBiXy5TRbHENoSI3FKQ5xyOhkk7+1iz7aPBvWaw==
X-Received: by 2002:a05:600c:3b91:b0:436:46f9:4fc6 with SMTP id 5b1f17b1804b1-436e26928e6mr54604865e9.8.1736416548420;
        Thu, 09 Jan 2025 01:55:48 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Thu, 09 Jan 2025 09:55:44 +0000
Message-Id: <D6XGAK96L261.324ZJ1U3UO8LF@cloud.com>
To: "Roger Pau Monne" <roger.pau@citrix.com>,
 <xen-devel@lists.xenproject.org>
Cc: "Jan Beulich" <jbeulich@suse.com>, "Andrew Cooper"
 <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v2 04/18] x86/pv: introduce function to populate
 perdomain area and use it to map Xen GDT
From: "Alejandro Vallejo" <alejandro.vallejo@cloud.com>
X-Mailer: aerc 0.18.2
References: <20250108142659.99490-1-roger.pau@citrix.com>
 <20250108142659.99490-5-roger.pau@citrix.com>
In-Reply-To: <20250108142659.99490-5-roger.pau@citrix.com>

On Wed Jan 8, 2025 at 2:26 PM GMT, Roger Pau Monne wrote:
> The current code to update the Xen part of the GDT when running a PV gues=
t
> relies on caching the direct map address of all the L1 tables used to map=
 the
> GDT and LDT, so that entries can be modified.
>
> Introduce a new function that populates the per-domain region, either usi=
ng the
> recursive linear mappings when the target vCPU is the current one, or by
> directly modifying the L1 table of the per-domain region.
>
> Using such function to populate per-domain addresses drops the need to ke=
ep a
> reference to per-domain L1 tables previously used to change the per-domai=
n
> mappings.
>
> Signed-off-by: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
> ---
>  xen/arch/x86/domain.c                | 11 +++-
>  xen/arch/x86/include/asm/desc.h      |  6 +-
>  xen/arch/x86/include/asm/mm.h        |  2 +
>  xen/arch/x86/include/asm/processor.h |  5 ++
>  xen/arch/x86/mm.c                    | 88 ++++++++++++++++++++++++++++
>  xen/arch/x86/smpboot.c               |  6 +-
>  xen/arch/x86/traps.c                 | 10 ++--
>  7 files changed, 113 insertions(+), 15 deletions(-)
>
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index 1f680bf176ee..0bd0ef7e40f4 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -1953,9 +1953,14 @@ static always_inline bool need_full_gdt(const stru=
ct domain *d)
> =20
>  static void update_xen_slot_in_full_gdt(const struct vcpu *v, unsigned i=
nt cpu)
>  {
> -    l1e_write(pv_gdt_ptes(v) + FIRST_RESERVED_GDT_PAGE,
> -              !is_pv_32bit_vcpu(v) ? per_cpu(gdt_l1e, cpu)
> -                                   : per_cpu(compat_gdt_l1e, cpu));
> +    ASSERT(v !=3D current);

For this assert, and others below. IIUC, curr_vcpu =3D=3D current when we'r=
e
properly switched. When we're idling current =3D=3D idle and curr_vcpu =3D=
=3D prev_ctx.

Granted, calling this in the middle of a lazy idle loop would be weird, but
would it make sense for PT consistency to use curr_vcpu here...

> +
> +    populate_perdomain_mapping(v,
> +                               GDT_VIRT_START(v) +
> +                               (FIRST_RESERVED_GDT_PAGE << PAGE_SHIFT),
> +                               !is_pv_32bit_vcpu(v) ? &per_cpu(gdt_mfn, =
cpu)
> +                                                    : &per_cpu(compat_gd=
t_mfn,
> +                                                               cpu), 1);
>  }
> =20
>  static void load_full_gdt(const struct vcpu *v, unsigned int cpu)
> diff --git a/xen/arch/x86/include/asm/desc.h b/xen/arch/x86/include/asm/d=
esc.h
> index a1e0807d97ed..33981bfca588 100644
> --- a/xen/arch/x86/include/asm/desc.h
> +++ b/xen/arch/x86/include/asm/desc.h
> @@ -44,6 +44,8 @@
> =20
>  #ifndef __ASSEMBLY__
> =20
> +#include <xen/mm-frame.h>
> +
>  #define GUEST_KERNEL_RPL(d) (is_pv_32bit_domain(d) ? 1 : 3)
> =20
>  /* Fix up the RPL of a guest segment selector. */
> @@ -212,10 +214,10 @@ struct __packed desc_ptr {
> =20
>  extern seg_desc_t boot_gdt[];
>  DECLARE_PER_CPU(seg_desc_t *, gdt);
> -DECLARE_PER_CPU(l1_pgentry_t, gdt_l1e);
> +DECLARE_PER_CPU(mfn_t, gdt_mfn);
>  extern seg_desc_t boot_compat_gdt[];
>  DECLARE_PER_CPU(seg_desc_t *, compat_gdt);
> -DECLARE_PER_CPU(l1_pgentry_t, compat_gdt_l1e);
> +DECLARE_PER_CPU(mfn_t, compat_gdt_mfn);
>  DECLARE_PER_CPU(bool, full_gdt_loaded);
> =20
>  static inline void lgdt(const struct desc_ptr *gdtr)
> diff --git a/xen/arch/x86/include/asm/mm.h b/xen/arch/x86/include/asm/mm.=
h
> index 6c7e66ee21ab..b50a51327b2b 100644
> --- a/xen/arch/x86/include/asm/mm.h
> +++ b/xen/arch/x86/include/asm/mm.h
> @@ -603,6 +603,8 @@ int compat_arch_memory_op(unsigned long cmd, XEN_GUES=
T_HANDLE_PARAM(void) arg);
>  int create_perdomain_mapping(struct domain *d, unsigned long va,
>                               unsigned int nr, l1_pgentry_t **pl1tab,
>                               struct page_info **ppg);
> +void populate_perdomain_mapping(const struct vcpu *v, unsigned long va,
> +                                mfn_t *mfn, unsigned long nr);
>  void destroy_perdomain_mapping(struct domain *d, unsigned long va,
>                                 unsigned int nr);
>  void free_perdomain_mappings(struct domain *d);
> diff --git a/xen/arch/x86/include/asm/processor.h b/xen/arch/x86/include/=
asm/processor.h
> index d247ef8dd226..82ee89f736c2 100644
> --- a/xen/arch/x86/include/asm/processor.h
> +++ b/xen/arch/x86/include/asm/processor.h
> @@ -243,6 +243,11 @@ static inline unsigned long cr3_pa(unsigned long cr3=
)
>      return cr3 & X86_CR3_ADDR_MASK;
>  }
> =20
> +static inline mfn_t cr3_mfn(unsigned long cr3)
> +{
> +    return maddr_to_mfn(cr3_pa(cr3));
> +}
> +
>  static inline unsigned int cr3_pcid(unsigned long cr3)
>  {
>      return IS_ENABLED(CONFIG_PV) ? cr3 & X86_CR3_PCID_MASK : 0;
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index 3d5dd22b6c36..0abea792486c 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -6423,6 +6423,94 @@ int create_perdomain_mapping(struct domain *d, uns=
igned long va,
>      return rc;
>  }
> =20
> +void populate_perdomain_mapping(const struct vcpu *v, unsigned long va,
> +                                mfn_t *mfn, unsigned long nr)
> +{
> +    l1_pgentry_t *l1tab =3D NULL, *pl1e;
> +    const l3_pgentry_t *l3tab;
> +    const l2_pgentry_t *l2tab;
> +    struct domain *d =3D v->domain;
> +
> +    ASSERT(va >=3D PERDOMAIN_VIRT_START &&
> +           va < PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS));
> +    ASSERT(!nr || !l3_table_offset(va ^ (va + nr * PAGE_SIZE - 1)));
> +
> +    /* Use likely to force the optimization for the fast path. */
> +    if ( likely(v =3D=3D current) )

... and here? In particular I'd expect using curr_vcpu here means...

> +    {
> +        unsigned int i;
> +
> +        /* Ensure page-tables are from current (if current !=3D curr_vcp=
u). */
> +        sync_local_execstate();

... this should not be needed.

> +
> +        /* Fast path: get L1 entries using the recursive linear mappings=
. */
> +        pl1e =3D &__linear_l1_table[l1_linear_offset(va)];
> +
> +        for ( i =3D 0; i < nr; i++, pl1e++ )
> +        {
> +            if ( unlikely(perdomain_l1e_needs_freeing(*pl1e)) )
> +            {
> +                ASSERT_UNREACHABLE();
> +                free_domheap_page(l1e_get_page(*pl1e));
> +            }
> +            l1e_write(pl1e, l1e_from_mfn(mfn[i], __PAGE_HYPERVISOR_RW));
> +        }
> +
> +        return;
> +    }
> +
> +    ASSERT(d->arch.perdomain_l3_pg);
> +    l3tab =3D __map_domain_page(d->arch.perdomain_l3_pg);
> +
> +    if ( unlikely(!(l3e_get_flags(l3tab[l3_table_offset(va)]) &
> +                    _PAGE_PRESENT)) )
> +    {
> +        unmap_domain_page(l3tab);
> +        gprintk(XENLOG_ERR, "unable to map at VA %lx: L3e not present\n"=
, va);
> +        ASSERT_UNREACHABLE();
> +        domain_crash(d);
> +
> +        return;
> +    }
> +
> +    l2tab =3D map_l2t_from_l3e(l3tab[l3_table_offset(va)]);
> +
> +    for ( ; nr--; va +=3D PAGE_SIZE, mfn++ )
> +    {
> +        if ( !l1tab || !l1_table_offset(va) )
> +        {
> +            const l2_pgentry_t *pl2e =3D l2tab + l2_table_offset(va);
> +
> +            if ( unlikely(!(l2e_get_flags(*pl2e) & _PAGE_PRESENT)) )
> +            {
> +                gprintk(XENLOG_ERR, "unable to map at VA %lx: L2e not pr=
esent\n",
> +                        va);
> +                ASSERT_UNREACHABLE();
> +                domain_crash(d);
> +
> +                break;
> +            }
> +
> +            unmap_domain_page(l1tab);
> +            l1tab =3D map_l1t_from_l2e(*pl2e);
> +        }
> +
> +        pl1e =3D &l1tab[l1_table_offset(va)];
> +
> +        if ( unlikely(perdomain_l1e_needs_freeing(*pl1e)) )
> +        {
> +            ASSERT_UNREACHABLE();
> +            free_domheap_page(l1e_get_page(*pl1e));
> +        }
> +
> +        l1e_write(pl1e, l1e_from_mfn(*mfn, __PAGE_HYPERVISOR_RW));
> +    }
> +
> +    unmap_domain_page(l1tab);
> +    unmap_domain_page(l2tab);
> +    unmap_domain_page(l3tab);
> +}
> +
>  void destroy_perdomain_mapping(struct domain *d, unsigned long va,
>                                 unsigned int nr)
>  {
> diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
> index 79a79c54c304..a740a6402272 100644
> --- a/xen/arch/x86/smpboot.c
> +++ b/xen/arch/x86/smpboot.c
> @@ -1059,8 +1059,7 @@ static int cpu_smpboot_alloc(unsigned int cpu)
>      if ( gdt =3D=3D NULL )
>          goto out;
>      per_cpu(gdt, cpu) =3D gdt;
> -    per_cpu(gdt_l1e, cpu) =3D
> -        l1e_from_pfn(virt_to_mfn(gdt), __PAGE_HYPERVISOR_RW);
> +    per_cpu(gdt_mfn, cpu) =3D _mfn(virt_to_mfn(gdt));
>      memcpy(gdt, boot_gdt, NR_RESERVED_GDT_PAGES * PAGE_SIZE);
>      BUILD_BUG_ON(NR_CPUS > 0x10000);
>      gdt[PER_CPU_GDT_ENTRY - FIRST_RESERVED_GDT_ENTRY].a =3D cpu;
> @@ -1069,8 +1068,7 @@ static int cpu_smpboot_alloc(unsigned int cpu)
>      per_cpu(compat_gdt, cpu) =3D gdt =3D alloc_xenheap_pages(0, memflags=
);
>      if ( gdt =3D=3D NULL )
>          goto out;
> -    per_cpu(compat_gdt_l1e, cpu) =3D
> -        l1e_from_pfn(virt_to_mfn(gdt), __PAGE_HYPERVISOR_RW);
> +    per_cpu(compat_gdt_mfn, cpu) =3D _mfn(virt_to_mfn(gdt));
>      memcpy(gdt, boot_compat_gdt, NR_RESERVED_GDT_PAGES * PAGE_SIZE);
>      gdt[PER_CPU_GDT_ENTRY - FIRST_RESERVED_GDT_ENTRY].a =3D cpu;
>  #endif
> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
> index 487b8c5a78c5..a7f6fb611c34 100644
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -92,10 +92,10 @@ DEFINE_PER_CPU(uint64_t, efer);
>  static DEFINE_PER_CPU(unsigned long, last_extable_addr);
> =20
>  DEFINE_PER_CPU_READ_MOSTLY(seg_desc_t *, gdt);
> -DEFINE_PER_CPU_READ_MOSTLY(l1_pgentry_t, gdt_l1e);
> +DEFINE_PER_CPU_READ_MOSTLY(mfn_t, gdt_mfn);
>  #ifdef CONFIG_PV32
>  DEFINE_PER_CPU_READ_MOSTLY(seg_desc_t *, compat_gdt);
> -DEFINE_PER_CPU_READ_MOSTLY(l1_pgentry_t, compat_gdt_l1e);
> +DEFINE_PER_CPU_READ_MOSTLY(mfn_t, compat_gdt_mfn);
>  #endif
> =20
>  /* Master table, used by CPU0. */
> @@ -2219,11 +2219,9 @@ void __init trap_init(void)
>      init_ler();
> =20
>      /* Cache {,compat_}gdt_l1e now that physically relocation is done. *=
/
> -    this_cpu(gdt_l1e) =3D
> -        l1e_from_pfn(virt_to_mfn(boot_gdt), __PAGE_HYPERVISOR_RW);
> +    this_cpu(gdt_mfn) =3D _mfn(virt_to_mfn(boot_gdt));
>      if ( IS_ENABLED(CONFIG_PV32) )
> -        this_cpu(compat_gdt_l1e) =3D
> -            l1e_from_pfn(virt_to_mfn(boot_compat_gdt), __PAGE_HYPERVISOR=
_RW);
> +        this_cpu(compat_gdt_mfn) =3D _mfn(virt_to_mfn(boot_compat_gdt));
> =20
>      percpu_traps_init();
> =20



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 09:58:51 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 09:58:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867958.1279492 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVpJT-0003Tg-2v; Thu, 09 Jan 2025 09:58:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867958.1279492; Thu, 09 Jan 2025 09:58:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVpJT-0003TZ-0P; Thu, 09 Jan 2025 09:58:51 +0000
Received: by outflank-mailman (input) for mailman id 867958;
 Thu, 09 Jan 2025 09:58:50 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=pS5t=UB=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVpJS-0003TT-7p
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 09:58:50 +0000
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com
 [2a00:1450:4864:20::433])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5233914a-ce70-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 10:58:48 +0100 (CET)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-385de9f789cso512972f8f.2
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 01:58:48 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a8e4c1ce5sm1359236f8f.94.2025.01.09.01.58.46
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 01:58:47 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5233914a-ce70-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736416728; x=1737021528; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=/VXpPq3krtPPpdfZOOaixS4Qtjl5Z/mwSZquK/DB4c0=;
        b=D8YxmWSHSTMPI7zhfK2FtwtcXIPzKJeIZkHSwsJlK/uNGpmyanD0z0WA+WSSSp9j5s
         5Mra8WwpVhsxZ2n/K71WheScCXAQsD8Qer02mLWx18JILGgKe4PMZ8Y/Sw59VKEVgdLW
         nCkUeplWtHcdOGn7ws13fL+I8+O3HVcs6jB/Rt2Dt9jS3kqL5lJvGef4T3aVzOZmdqn2
         4cj6MBXG0wqUt+/nfvJcWqjbxaYRB6YnzAv644xvOFM4DrjtNt7NwOwkY2hwVh6e2uwf
         8uDwfk0ppTWG/47CNH5zReaNVqYpQclN3g4JmzTU5s7f2XAKu5CGZoXRzNW8BQpAZncC
         lzgw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736416728; x=1737021528;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=/VXpPq3krtPPpdfZOOaixS4Qtjl5Z/mwSZquK/DB4c0=;
        b=tTlaodfpbpBBAR8HMKt4+PITvrY+vFuhE3Em9UH0hch8l32LmMI/2awA98G8XNUYuR
         MVR0QBIN1LY2CRyMPIPFza1Rb+2dO2y9YSEBHEtuDjKldgC46xh1EUK7Jc6lFiMmWnNN
         q+1pNiWFl7ePgmdIsKOUqPJ4EGAQiRrekgITZcW2ywqxPQgT1uIrFysI1X9tR/unwKUe
         GwVlrIGtf9BnZ5VccDIUYQfav4co6JWD3+9N2X3wbFrJ/JmQZipxvFJ4U2I98+fSJBPE
         lYQmAARQ4kesRqyp2jFr+AGe7pm6BlCOnbCVPfIzaA87QKpYkeohCRaEawC9ZWfFObt5
         Nc/w==
X-Forwarded-Encrypted: i=1; AJvYcCUtbt22kCPKTmiK9hwiTYq4/ghAI5pM8ybW/wSPAqWDgzToX/YeCqyULuSoq8s48T7APXEAGuhJnoU=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy+iwYmFWMjj5dIPwbQTD/Vm3SlSHCYF9/8Ay30Nlfw5RBnEeBA
	Xjg6BSpqaMsn8miO7xmQMb/5bcXxhxV3LKLXHn1CZbJwYldIiORDcgp53OqWQA==
X-Gm-Gg: ASbGncu57qqOJOEY7VZa1eDnwgztobUrkrRyQsn42B2rbYKGnDzxw2ngARbc3dRYAjX
	lNRrRbZvoPBnGTWRcIGAji786KdcpkkA52N8V1lcYkU8bFemx6grLgRsNqZ/xNccgoLngT3/nhy
	CUM3mRbYNnyusHKyg8sR1pNKvsRShEUJvPwq0x8XpDBiRsc8hsKLRbUS3+sOqvVQzvxfPQKL4hi
	cylOIuE9/vhmNRkHOt6Msn6y1TrE2TM5+Zkp7AdnL9zlzwqPJn/QdDVRTbwA1MfrAAtM/AQjLhR
	nKApBsbUrvwvB2E/EVw8aFCb8Er7uqijl+Tc97Qlkw==
X-Google-Smtp-Source: AGHT+IGPK+cWw7vQ8luY1gE9h5jdoX6r83TrmJpgCSoLbkiqEYsCNZx0f1whShgo+ZYGiJ60LUljmw==
X-Received: by 2002:a05:6000:1acb:b0:385:edd1:2249 with SMTP id ffacd0b85a97d-38a87316a81mr4935048f8f.50.1736416727696;
        Thu, 09 Jan 2025 01:58:47 -0800 (PST)
Message-ID: <e7f1b3c3-dce4-4a0e-b1cf-c6ba8af95290@suse.com>
Date: Thu, 9 Jan 2025 10:58:45 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 03/11] xen/x86: introduce "cpufreq=amd-pstate" xen
 cmdline
To: Penny Zheng <Penny.Zheng@amd.com>
Cc: stefano.stabellini@amd.com, Ray.Huang@amd.com, Xenia.Ragiadakou@amd.com,
 Jason.Andryuk@amd.com, Andrew Cooper <andrew.cooper3@citrix.com>,
 Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20241203081111.463400-1-Penny.Zheng@amd.com>
 <20241203081111.463400-4-Penny.Zheng@amd.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20241203081111.463400-4-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 03.12.2024 09:11, Penny Zheng wrote:
> --- a/xen/arch/x86/acpi/cpufreq/Makefile
> +++ b/xen/arch/x86/acpi/cpufreq/Makefile
> @@ -1,4 +1,5 @@
>  obj-$(CONFIG_INTEL) += acpi.o
>  obj-y += cpufreq.o
> +obj-y += amd-pstate.o
>  obj-$(CONFIG_INTEL) += hwp.o
>  obj-$(CONFIG_AMD) += powernow.o

Please obey to alphabetic sorting.

> --- /dev/null
> +++ b/xen/arch/x86/acpi/cpufreq/amd-pstate.c
> @@ -0,0 +1,66 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * amd-pstate.c - AMD Processor P-state Frequency Driver
> + *
> + * Copyright (C) 2024 Advanced Micro Devices, Inc. All Rights Reserved.
> + *
> + * Author: Penny Zheng <penny.zheng@amd.com>
> + *
> + * AMD P-State introduces a new CPU performance scaling design for AMD
> + * processors using the ACPI Collaborative Performance and Power Control (CPPC)
> + * feature which provides a finer grained frequency control range.
> + *
> + */

Nit: Unnecessary empty comment line at the end.

> +#include <xen/init.h>
> +#include <xen/param.h>
> +#include <acpi/cpufreq/cpufreq.h>
> +
> +uint16_t __read_mostly dmi_max_speed_mhz;
> +
> +static bool __init amd_pstate_handle_option(const char *s, const char *end)
> +{
> +    int ret;
> +
> +    ret = parse_boolean("verbose", s, end);
> +    if ( ret >= 0 )
> +    {
> +        cpufreq_verbose = ret;
> +        return true;
> +    }
> +
> +    return false;
> +}
> +
> +int __init amd_pstate_cmdline_parse(const char *s, const char *e)
> +{
> +    do
> +    {
> +        const char *end = strpbrk(s, ",;");
> +
> +        if ( !amd_pstate_handle_option(s, end) )
> +        {
> +            printk(XENLOG_WARNING "cpufreq/amd-pstate: option '%.*s' not recognized\n",
> +                   (int)((end ?: e) - s), s);
> +
> +            return -EINVAL;
> +        }
> +
> +        s = end ? ++end : end;
> +    } while ( s && s < e );
> +
> +    return 0;
> +}
> +
> +static const struct cpufreq_driver __initconstrel amd_pstate_cpufreq_driver =

__initconst_cf_clobber

> --- a/xen/arch/x86/acpi/cpufreq/cpufreq.c
> +++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c
> @@ -148,6 +148,9 @@ static int __init cf_check cpufreq_driver_init(void)
>                  case CPUFREQ_none:
>                      ret = 0;
>                      break;
> +                default:
> +                    printk(XENLOG_WARNING "Unsupported cpufreq driver for vendor Intel\n");

Too long line (the format string itself shall be kept all on one line, but
the XENLOG_WARNING doesn't need to).

> @@ -156,6 +159,31 @@ static int __init cf_check cpufreq_driver_init(void)
>              break;
>  
>          case X86_VENDOR_AMD:
> +            ret = -ENOENT;
> +
> +            for ( unsigned int i = 0; i < cpufreq_xen_cnt; i++ )
> +            {
> +                switch ( cpufreq_xen_opts[i] )
> +                {
> +                case CPUFREQ_xen:
> +                    ret = powernow_register_driver();
> +                    break;
> +                case CPUFREQ_amd_pstate:
> +                    ret = amd_pstate_register_driver();
> +                    break;
> +                case CPUFREQ_none:
> +                    ret = 0;
> +                    break;
> +                default:
> +                    printk(XENLOG_WARNING "Unsupported cpufreq driver for vendor AMD\n");
> +                    break;
> +                }
> +
> +                if ( ret != -ENODEV )
> +                    break;
> +            }
> +            break;
> +
>          case X86_VENDOR_HYGON:
>              ret = IS_ENABLED(CONFIG_AMD) ? powernow_register_driver() : -ENODEV;
>              break;

Is the code to handle CPPC not applicable to Hygon CPUs?

What about the IS_ENABLED(CONFIG_AMD) that the original code had? Don't
you need to mirror this in some way?

> --- a/xen/arch/x86/platform_hypercall.c
> +++ b/xen/arch/x86/platform_hypercall.c
> @@ -574,6 +574,12 @@ ret_t do_platform_op(
>  
>          case XEN_PM_CPPC:
>          {
> +            if ( !(xen_processor_pmbits & XEN_PROCESSOR_PM_CPPC) )
> +            {
> +                ret = -ENOSYS;

ENOSYS isn't appropriate for such a situation.

> --- a/xen/drivers/cpufreq/cpufreq.c
> +++ b/xen/drivers/cpufreq/cpufreq.c
> @@ -84,7 +84,7 @@ static int __init cf_check setup_cpufreq_option(const char *str)
>  
>      if ( choice < 0 && !cmdline_strcmp(str, "dom0-kernel") )
>      {
> -        xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX;
> +        xen_processor_pmbits &= ~(XEN_PROCESSOR_PM_PX|XEN_PROCESSOR_PM_CPPC);
>          cpufreq_controller = FREQCTL_dom0_kernel;
>          opt_dom0_vcpus_pin = 1;
>          return 0;
> @@ -92,7 +92,7 @@ static int __init cf_check setup_cpufreq_option(const char *str)
>  
>      if ( choice == 0 || !cmdline_strcmp(str, "none") )
>      {
> -        xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX;
> +        xen_processor_pmbits &= ~(XEN_PROCESSOR_PM_PX|XEN_PROCESSOR_PM_CPPC);

Nit (style): Blanks please around binary operators.

> --- a/xen/include/acpi/cpufreq/cpufreq.h
> +++ b/xen/include/acpi/cpufreq/cpufreq.h
> @@ -28,6 +28,7 @@ enum cpufreq_xen_opt {
>      CPUFREQ_none,
>      CPUFREQ_xen,
>      CPUFREQ_hwp,
> +    CPUFREQ_amd_pstate,

Might this better be CPUFREQ_amd_cppc? "pstate" may mean various methods.

> --- a/xen/include/public/sysctl.h
> +++ b/xen/include/public/sysctl.h
> @@ -424,6 +424,7 @@ struct xen_set_cppc_para {
>  };
>  
>  #define XEN_HWP_DRIVER_NAME "hwp"
> +#define XEN_AMD_PSTATE_DRIVER_NAME "amd-pstate"

Similarly here.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 10:00:50 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 10:00:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867966.1279503 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVpLA-0004ze-Ev; Thu, 09 Jan 2025 10:00:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867966.1279503; Thu, 09 Jan 2025 10:00:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVpLA-0004zX-B9; Thu, 09 Jan 2025 10:00:36 +0000
Received: by outflank-mailman (input) for mailman id 867966;
 Thu, 09 Jan 2025 10:00: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
 <SRS0=raTQ=UB=amd.com=ayan.kumar.halder@srs-se1.protection.inumbo.net>)
 id 1tVpL8-0004y9-GE
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 10:00:34 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20627.outbound.protection.outlook.com
 [2a01:111:f403:2417::627])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8ff47270-ce70-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 11:00:33 +0100 (CET)
Received: from PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7)
 by PH7PR12MB6883.namprd12.prod.outlook.com (2603:10b6:510:1b9::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8314.16; Thu, 9 Jan
 2025 10:00:25 +0000
Received: from PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264]) by PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264%6]) with mapi id 15.20.8335.011; Thu, 9 Jan 2025
 10:00:25 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8ff47270-ce70-11ef-a0df-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Rtpl/Ivp27mIzxQHQKGHi+vm06x7QG2t7odYnb/l75Kz0cW75kP9rlzkkPtbKPppwTy7pCio+BPGqKV+3lJlIkREKo8UvqdkYSMswMcMeh56k+/UXRISWBGly/qW+HwssY8Ek4p8NmHCytLoekFd0rBTKJ+TZ0pXG1awbyNZ8PHDTZv7W3XixFZn25KcP14Xde/0XADIWcOrJFrqKnpCfXSZgnWzBdZgtjGbLHn3UkW8w8GMSgJ/qhxekYY1CPpsq3KxbXOacn4PZ1RKiPRzEJAteR+i5hqDnbm4exgmEv7/os9TxVFjkNCRqamhe4cJwKGPYHd1DHJGOGnZ8Hgqrg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=bSbqQ1bMAzEwYI+OjrqbC6kWfmyreb796wbnwwNLygA=;
 b=Ms/opKtk7BoEKyrAdm+yk5E9l1cWZuyGwyGXwUFLAFnV8JRCorP7YL+I+J/zLwjWyDToQ/1IfTBAEC3aqonJHy41D2z0x4ox+eDbMDpfUhFJgLjoguSeYJ8RsIVFuRUnEYzNbJf2rQQznLGLmje55fQ8KjB7TuVmjzllPtDda+HifsW32WVRVXHoHTGEk0G0+Vw6l272S5p7uVXe7NG33tqEv1CYMhOdt32QP1Fs9W+YUyOEG3b9T85wknFYJ2MUdkCWdzO4DoqEPlUFVebrE+WDrNqVzXQxcZ7kjhZVaIwJCl5kE74MUc+STMFE/2QOpYAPGiGMtj4G2xYIh+e0WQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=bSbqQ1bMAzEwYI+OjrqbC6kWfmyreb796wbnwwNLygA=;
 b=Yo+39DB9KUk9a/x+gU/Xt3VBFVSPHad4wne+sh+0Cnx0utQBgzelj+cn9tai0TUiVwFRdx66K4E6dJncV6o0ur3fEoWyGdrRUYDP4WT9Z+4i4ozDSjXWi9osnU4DPOS9eZerxMLIzXF/YHMBXZOZ13/GsGUdN+rEI3laVSYcygM=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <dac15016-b55f-4066-a8e6-b2eb8346655c@amd.com>
Date: Thu, 9 Jan 2025 10:00:20 +0000
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4] docs: fusa: Add dom0less domain configuration
 requirements
To: Bertrand Marquis <Bertrand.Marquis@arm.com>,
 Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Michal Orzel <michal.orzel@amd.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Artem Mygaiev <artem_mygaiev@epam.com>
References: <20250108170304.2250917-1-ayan.kumar.halder@amd.com>
 <E21BDDA5-F268-4127-82FA-1BD58DD6028D@arm.com>
Content-Language: en-GB
From: Ayan Kumar Halder <ayankuma@amd.com>
In-Reply-To: <E21BDDA5-F268-4127-82FA-1BD58DD6028D@arm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: LO4P265CA0010.GBRP265.PROD.OUTLOOK.COM
 (2603:10a6:600:2ad::21) To PH8PR12MB7326.namprd12.prod.outlook.com
 (2603:10b6:510:216::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH8PR12MB7326:EE_|PH7PR12MB6883:EE_
X-MS-Office365-Filtering-Correlation-Id: 488d1eec-f5b9-48c6-e084-08dd3094700a
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?Nkc0QXhLbkRlL2FzMlUzcVlxbWF5bzRyb1ZJZVREdGhFVWJFUGgxMVhHUDdP?=
 =?utf-8?B?VVlGdkV2UXJYcXAvQW1tSkN2OGs1R3NyUjI2Mm4wK3lRcUtTSWN3NWlqUmQ2?=
 =?utf-8?B?cUdkaGpGWDcxWldnZDlOMU9qaU84UUJlejl3a21NQkRTTFFnZk1BYWptbHpx?=
 =?utf-8?B?anFOekw1Uk5XUm9Lb0x6ejh3TkM4bHVORzVCV2J2K0ttYTF0emhMQ3RIemhi?=
 =?utf-8?B?Yk5RdWZ4S0wvOE04RVVOWWxyZldYd09XcFVBeVdVMU5JMSt0YnRzQ2NYbkkx?=
 =?utf-8?B?bGQxZC91Ny9rdEFJYzVmRTZHMlI4c0xkV0pCdVl0YWlaZ0xzVW9TV0h1b1ZN?=
 =?utf-8?B?UlpMcEQwNjdsVE5rNUZvcXVzVDV3UUtKQitlbExlZ0w1d2FIdkxKLzl1MWx2?=
 =?utf-8?B?K0YwNXlFZDExdlE3WlI1aHRRVDBEcStwMndxTnRZWDZXSXl6RythbkdqSDZi?=
 =?utf-8?B?UUFURmpmQzFYOW1jNXJXYXkrc2NFbjlQanREeVY2YmFvMkxYRnhLdW1xWHJw?=
 =?utf-8?B?b09VV3JwVkdibnU4QXJ4WDRtUXFlTzF5TUd3azJHWXh2MUUya294b1RQTlcr?=
 =?utf-8?B?QUVJbUFnSmY2M091Q3I0bVNuUDVKQjByQzNtbWJCRUlhL3M4YkhxQW1IczRT?=
 =?utf-8?B?RUZzeEwzdnZqRmluakhqZ0tSVVJTV1pDeW5LNlRwbXJiRjgyY09BSkE5MFBz?=
 =?utf-8?B?ZElMa0I4cDRRd05tcFRTUEpvNXRCdzI0U3g2Q1NmeUJxNVdoQ3dZL3k5QVhp?=
 =?utf-8?B?Y2F3a1pxNzdjbTY2NTk3bmhqRktHU3RYczFQNFoyN2JFaXczbUtPSzYrTVl4?=
 =?utf-8?B?NGdsaXpVUVRYcU5hVUx3WVJ3cjNZd3UzL0N1TE96eFZscDh5clFFYktXeUlJ?=
 =?utf-8?B?V0hIdWpQRTVwa1NpZUJUNXpZbzQvY3pqSTVYS3dIM2k2dGFOc0dndFNmejEz?=
 =?utf-8?B?OHZMWUN0aXRPWkdKdVN1MVBsQzBzL1ZRZkFXR0hoNGZoVjB0dlZrK2NOcm9q?=
 =?utf-8?B?YTg3SERpMkJublEvOXVwOFI3M0QxU09IQ0wwTzh5cUpRa1JpK2lnY213RGpV?=
 =?utf-8?B?aDhWaUtmVUlreGxseXNyaXlpTFhaZmZKVlJ6RjQzU0M3ZkFFUk5uSVpaRG1I?=
 =?utf-8?B?WHRNR0tBZU5sTzlScHZkb3F4NC9LN3ZxUjBURWRheHBZR2ZzaC96bk9kQ3lE?=
 =?utf-8?B?VUgzTy9NRjhtLzEzdlNPOS9lQWNEYW5KRldmOERFelBEd0lrUUpsVUFUOTFB?=
 =?utf-8?B?dXlTT3NxT1BwMUNEY1p5QXJBOTMvVmtUa1BrUTU5NEZkN1ZDQkZhYjJzNlI3?=
 =?utf-8?B?K0tlMk9INkZ5UDcvNjdzeTI1MnNWSU5IaXJPUTlBSW1oNCttanlpN0o3MU0w?=
 =?utf-8?B?U2tYR2swVzNQZlVsTXh6bTBpMmpYdCt2VGgybDZldVRyRndPemlCZGFNZWdS?=
 =?utf-8?B?N3lKejFETUhvTTV4TVVLOGhjMHBPUVpuYlRROHBXdGhMeVExRWQ5cDBYSGVC?=
 =?utf-8?B?ekE2YUpVK3F5VEJRa1FjbENOVnRTd1ZSZmJySWV1a3B6cEozK1VNVVNsZi9w?=
 =?utf-8?B?bFdZKzJ5a0p5SGkyWUY4Nnhhd3ZpdmwvUGxETGFYSGYyNTBJT05ERTdDeTNX?=
 =?utf-8?B?YjFZL0syMjQyaVVSWmhTQm5ReUt3QjV2SGpEOUUvNnM4T3BIRUtRZXZ5ek80?=
 =?utf-8?B?L0ZSSERBNEx2M00zQXN5S3RwYndCVSt3TzhwaVdEeHNMVHBtdGJDRGFLeG1X?=
 =?utf-8?B?MkJHenFhbzZYUkl6czJSMnFKUDNzNTV4NTd6RXNjZXA0ZVQ4VDcyR29wWWxE?=
 =?utf-8?B?cnBhay9OWjdiRFluVTVRenk5aDU0d1BhSUxZNTBvN3Rvck1sLzIvbkdOVjdo?=
 =?utf-8?Q?XwNzrF6eEWKwY?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH8PR12MB7326.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?Nkxld0hoQmdCN29ZckxrL1ZoYXV1MnBudTFMR3lOakdHVW85RktTU1ZpZWlt?=
 =?utf-8?B?MmdKZG5qMjdvRzRLUnp4RVpETUpMK2tqbWt6cVdQU0hLc3lvcEVBc0kxamc2?=
 =?utf-8?B?TjNmMmx1ZFduMjNaWE9uakxFU1U3T2dTcUFsWnZWWUUwazg4aSs0WE53TGlj?=
 =?utf-8?B?aGJKNStOakpzVUgxQmxwaGtIbFhpQ2NPdGRoemN1UTc2RHBzbnVBOVg5dFMw?=
 =?utf-8?B?RDNvRVRYUjhmNkh5NVZJZFhTQ1pMdlFNY1RzaElqMlkzVGxaSWZWYnd0ZlVy?=
 =?utf-8?B?TUZ4OG9ydlJxOFU0TTBheUxoMG9JYmlPUDN3ZFl6YVJVZCtPV1owVXdTMHZj?=
 =?utf-8?B?OXU3TXdCOWQ4YjBCdm41bzBJNlhyYlNjdnZjdlJlckxZd0VjM25sakQ2a2I4?=
 =?utf-8?B?aTlPTlNVRTNpTUZlUHNUT202ZE1zck9laXRlM2xyNGFidFBSSm1QSXozR1lm?=
 =?utf-8?B?U2Yzbkdma3lpVmFybjk3bU1MMktCSEhFZUErcUxlRWp4SEFmWXZndjY2VHdk?=
 =?utf-8?B?YVY5Y2pnVGtMVFdIQW9ETU1GcThuT1Z5RDVsMXM1NmJWQWowYTAraU5RTTFR?=
 =?utf-8?B?bGJtd3dJYTJpWkwzSkZKaDJKcTA2eHU3S1c3YU5USDNYdUdyNzhUS0xkNGJz?=
 =?utf-8?B?RW1WU2hjZlIrY1MrekNBWnZHSC9MZ2NPWlVHOUFRdFBsZ2wzWGtpRG9nT3JG?=
 =?utf-8?B?bFVhUmU3dm5ySHJFTWM4SWZmU1NLTmREUVNxaklFL1FqK2pqQmNMRUVRTnVp?=
 =?utf-8?B?ZEk1cnp4bnkrNHB1aE44N1JCYjR5MUp4SWUyczVjWmlySUZYZHZNRHg2WGo5?=
 =?utf-8?B?djBjVWRpcXphM2dPYWxoZVVUUjRNUkhvRUNDdUVRVjg1S09RSHl0NjNwN1Ex?=
 =?utf-8?B?ZUUwenVXclVCcDVjdU1yMEt2NFhZYjBrS1ZlTkhxVFBhMDNyNE9LYzUxYXVp?=
 =?utf-8?B?Z2hoK1Jma3JQeERwVFpnRXNVT1hiNzF2amQyVitpR3hzZVdRVHVmSGViZ3M1?=
 =?utf-8?B?emhYV3Z3RXFSb2hHVkVXV0FoOEhqVzVJYUVmQnJZSWNzWjlDS3Z0SlFSRTEz?=
 =?utf-8?B?b3FuT3BkUHBDVm9iVy9RUDQ3RFFtdEtSZzZJaVo3WkowdlZuMFFnZGJHYVMz?=
 =?utf-8?B?OGFxZGd2akNXcjJHSVBVemo4akF6dFJXcjNGZWhpWkxTd3dYbFdkSWFRVnpk?=
 =?utf-8?B?UUE4cjFZNkdRT1diTmNpOVhIUU9FYkdWUjc3K2F5ZklnbE43L1VBam85eWRs?=
 =?utf-8?B?c3pMMUhjZmVXd2JwOFpnTXozLzg2bGg5RlhxYm9IaStlWFRqY1JYR3JXUENT?=
 =?utf-8?B?eHBlckdlc3ZvaERpbkg0bWlrUWRxcFVrTi82MTRaRzZPOUZzWS8zNVVYMFpJ?=
 =?utf-8?B?OHBTcFk3ejJIeUJkWG1jdzdqOElnRWNGR0o4Ykk2ejNyRlV3T2tBS0xxSE1I?=
 =?utf-8?B?QWFJNWpsb0tGazB3RSt5V3VJNE5zZmQwTXdRbVpEaVZxTTArM2sySk5sWHB3?=
 =?utf-8?B?ZFpYc3dWWllEMDd0OElicHNVZFZRbm9SdU5melpkaFNRbmtEbXNkQWlJTzh1?=
 =?utf-8?B?Mi9KUXRUTGFaYnhSOCtiSU4xb3U3bm9lQi9ubHFrNjFnUFEvU2J4V01qaXdj?=
 =?utf-8?B?Q2gxY09mOG56WFRxRjI2MmxtRHdwN1NYV3EvNXRYWWZsYmpmRHRqcGNsWHVa?=
 =?utf-8?B?Rmh0eHMxNjBpRFlTVFQyUlhVZm9FbmhGZ0FXNXR3T2g4UXBhU2cyK3B1OHlQ?=
 =?utf-8?B?TEh5a3dFak9sS2FlZHoyOFFBVHo1dWJEeC9wVXovdmhIU2ZsOWFuU050RVpa?=
 =?utf-8?B?UGdPeXZvcGxOMWdiV1E5T0Izb1FqUHFGMmI3TWtMSGJBZmQrSVpQaVdrYUFN?=
 =?utf-8?B?NEN3N21FYXNKVTJCQmxSem1za2dCRWs2Q0NBWVlRVDZKOElGc09sNnNMaWZ1?=
 =?utf-8?B?WURNSlNucDhsdnd6ZExQZ0RsY0JIQmNpMEhFWDU2a1RlTWFsV1dXRXNvbkNJ?=
 =?utf-8?B?MTJLL05jWUVWRG0xdTM0bDZJYmo2WEc3d1ZQSDAzbVVCdXZSZExoRGg1Y1BO?=
 =?utf-8?B?TTFXZ1pVVEQrUzhLN3F1cjhJQk5qV3NIeldSemRBblpDQU1QdWZEQ1JTNFgr?=
 =?utf-8?Q?FuLxYnSOP63cFyc/BIMbthMn8?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 488d1eec-f5b9-48c6-e084-08dd3094700a
X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7326.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jan 2025 10:00:25.0735
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: klVvATbgMMbpAtBH0IPUK42syXzPM/OMc95W5HMDivvBEMYeHQWE5lITYmsqDwaSNe3wKwM3TOZqtCGkGgwgGg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB6883


On 09/01/2025 07:53, Bertrand Marquis wrote:
> Hi Ayan,
Hi Bertrand,
>
> This is a lot better.
> I just have some minor phrasing comments after.
>
>> On 8 Jan 2025, at 18:03, Ayan Kumar Halder <ayan.kumar.halder@amd.com> wrote:
>>
>> From: Michal Orzel <michal.orzel@amd.com>
>>
>> Add requirements for dom0less domain creation.
>>
>> Signed-off-by: Michal Orzel <michal.orzel@amd.com>
>> Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
>> ---
>> Changes from -
>>
>> v1 - 1. As the dom0less domain creation requirements specifies the dt properties
>> for creating domains, it has been moved to product requirements. Product
>> requirements define the interface Xen exposes to other domains.
>>
>> 2. For the requirements which introduces new terms (like grant table, etc), I
>> have provided the definition as part of the comments.
>>
>> 3. Introduced new market requirements to specify that Xen can assign iomem and
>> irqs to domains.
>>
>> 4. The design requirements will be added later.
>>
>> v2 - 1. Rephrased the requirements as suggested.
>>
>> 2. Split the product requirements into arm64 specific and common.
>>
>> 3. The arm64 specific requirements have arm64_ prefixed to their tag names.
>>
>> 4. Grant table requirements have been dropped for now.
>>
>> 5. Added a market requirement to denote that Xen can support multiple schedulers.
>>
>> 6. Updated index.rst as we have a new file ie product-reqs/reqs.rst.
>>
>> V3 - 1. Removed duplicate mention for 'Rationale'.
>>
>> 2. Fixed some of the descriptions as per the review comments.
>>
>> docs/fusa/reqs/index.rst                   |   1 +
>> docs/fusa/reqs/market-reqs/reqs.rst        |  31 ++++
>> docs/fusa/reqs/product-reqs/arm64/reqs.rst | 128 ++++++++++++++++-
>> docs/fusa/reqs/product-reqs/reqs.rst       | 160 +++++++++++++++++++++
>> 4 files changed, 318 insertions(+), 2 deletions(-)
>> create mode 100644 docs/fusa/reqs/product-reqs/reqs.rst
>>
>> diff --git a/docs/fusa/reqs/index.rst b/docs/fusa/reqs/index.rst
>> index 8a4dae6fb2..1088a51d52 100644
>> --- a/docs/fusa/reqs/index.rst
>> +++ b/docs/fusa/reqs/index.rst
>> @@ -8,6 +8,7 @@ Requirements documentation
>>
>>     intro
>>     market-reqs/reqs
>> +   product-reqs/reqs
>>     product-reqs/arm64/reqs
>>     design-reqs/arm64/generic-timer
>>     design-reqs/arm64/sbsa-uart
>> diff --git a/docs/fusa/reqs/market-reqs/reqs.rst b/docs/fusa/reqs/market-reqs/reqs.rst
>> index f456788d96..39b2714237 100644
>> --- a/docs/fusa/reqs/market-reqs/reqs.rst
>> +++ b/docs/fusa/reqs/market-reqs/reqs.rst
>> @@ -47,3 +47,34 @@ Comments:
>>
>> Needs:
>>   - XenProd
>> +
>> +Static VM definition
>> +--------------------
>> +
>> +`XenMkt~static_vm_definition~1`
>> +
>> +Description:
>> +Xen shall support assigning peripherals to various domains.
> "various" here could be removed or replaced with "a domain" to be coherent with
> the phrasing after.
I agree
>
>> +
>> +Rationale:
>> +
>> +Comments:
>> +Peripheral implies an iomem (input output memory) and/or interrupts.
>> +
>> +Needs:
>> + - XenProd
>> +
>> +Multiple schedulers
>> +-------------------
>> +
>> +`XenMkt~multiple_schedulers~1`
>> +
>> +Description:
>> +Xen shall provide different ways of scheduling virtual cpus onto physical cpus.
> different here is a bit imprecise.
> how about:
> Xen shall have configurable scheduling strategies of virtual cpus onto physical cpus.

looks fine to me.

Are you ok to give your R-b ? Then I can request Michal to fix them on 
commit.

- Ayan

>
> The rest looks good.
>
> Cheers
> Bertrand
>


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 10:01:15 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 10:01:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867973.1279512 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVpLh-0005eb-Mx; Thu, 09 Jan 2025 10:01:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867973.1279512; Thu, 09 Jan 2025 10:01:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVpLh-0005eU-J7; Thu, 09 Jan 2025 10:01:09 +0000
Received: by outflank-mailman (input) for mailman id 867973;
 Thu, 09 Jan 2025 10:01:08 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=KjpQ=UB=amd.com=Michal.Orzel@srs-se1.protection.inumbo.net>)
 id 1tVpLg-0004y9-95
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 10:01:08 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on2062f.outbound.protection.outlook.com
 [2a01:111:f403:2414::62f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a4935b80-ce70-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 11:01:07 +0100 (CET)
Received: from SJ0PR13CA0186.namprd13.prod.outlook.com (2603:10b6:a03:2c3::11)
 by DS7PR12MB5958.namprd12.prod.outlook.com (2603:10b6:8:7d::20) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8335.10; Thu, 9 Jan
 2025 10:01:01 +0000
Received: from SJ1PEPF00001CE2.namprd05.prod.outlook.com
 (2603:10b6:a03:2c3:cafe::be) by SJ0PR13CA0186.outlook.office365.com
 (2603:10b6:a03:2c3::11) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8314.7 via Frontend Transport; Thu, 9
 Jan 2025 10:01:01 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SJ1PEPF00001CE2.mail.protection.outlook.com (10.167.242.10) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8335.7 via Frontend Transport; Thu, 9 Jan 2025 10:01:00 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 9 Jan
 2025 04:01:00 -0600
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB06.amd.com
 (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 9 Jan
 2025 04:00:59 -0600
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Thu, 9 Jan 2025 04:00:58 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a4935b80-ce70-11ef-a0df-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=TWAqqOv3zZI2rkQhG/PvaygEbYoS+uM3g4ZHg8IOEzegYgPaGiTC3S9tTNALgVMvnYaZmO1+P9BwgSUeltUZQwy+L2FcYTS5YgU4nbRIdbLn6TRF3+pjhb/4PI38t09/9mfHntxMEvQFeDwbMjL0OOive/oRwmRzxlD3Idezzwt2okiqDwAIIup89+yvUhvyHqFBaVc8AAfK6ivW3GubHVSwXTsbw5VRgSCRNYqp5S8CDF6mjBDS5KAgXOB5E8OqTAql2xTTcaUPIDQrS0Z1mhskCB5Tuuva8ynXrWs6+4ZpFVx2sDpteLpGAd3mbZKFwsdhNH80/y0bR9Uc6JdJ5g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=7ZpyhmLzNTo+oOcG9IB+u9cV3l+k4u2f3lkpiORxCAY=;
 b=kQ6ew2VhESilEaHz6KnLoOy6eHzasp8zrF4IiYfPAZox0k1+lQ9QfYYHM4+7PktPaaYUlggbHH1QU3VYtBJpgx0SWcKmX8l2/h34yur7/Mkk+80xrK0PWGM4V6RQFFgHL5mDmkE6ADQXI/Fw5bB2e+9LzEeI4QdqjvZRZXJCpOY/GasipTbBVTEEqbRyyM9z+qL4HUpEEURtj7H/VX+JG061FVd+xCamfF/j/yS16tqj3rrM2XjFfPKvozeXRdYsjJTLddyCl5O7zzSY99R/cMbsZZwZ1Da62GyJt43HfP1X4jqAm7CMM3yRdyKWT7YEVnmrvnea4KMwN12e5zTANQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=7ZpyhmLzNTo+oOcG9IB+u9cV3l+k4u2f3lkpiORxCAY=;
 b=KZX9QVI+kPEFtQTKZc4rkhbqtxK6pqs2MNWP3h6lsHZwEMDjjZZc/Z/3IKUS9tQtyPgCV7VbUCgoE0qpbwEjc9odcj1C5nzbyT8kQGVrbKPyFJtJfDDkDWZwCFYCef4WeMcyRb4gkdtpuQtLH+smv4s4fumF9dZ+Rz8Db66t82g=
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: <e9477b85-1c9a-4aa6-b7fe-90286fcd461b@amd.com>
Date: Thu, 9 Jan 2025 11:00:58 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] xen/arm: Fully initialise struct membanks_hdr fields
To: Luca Fancellu <luca.fancellu@arm.com>, <xen-devel@lists.xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
	<julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>, "Volodymyr
 Babchuk" <Volodymyr_Babchuk@epam.com>, Oleksii Kurochko
	<oleksii.kurochko@gmail.com>
References: <20250109092816.1619834-1-luca.fancellu@arm.com>
Content-Language: en-US
From: Michal Orzel <michal.orzel@amd.com>
In-Reply-To: <20250109092816.1619834-1-luca.fancellu@arm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF00001CE2:EE_|DS7PR12MB5958:EE_
X-MS-Office365-Filtering-Correlation-Id: 321041d1-9b83-4a9d-e7cb-08dd309485a0
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|1800799024|36860700013|82310400026|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?dUhTQWNYbFhjS05xa2w0V2JLWVRJWlFmNTZjSTB2SHVtd2JrQXRyaUxTK0JQ?=
 =?utf-8?B?WDIyc1BCM0RhZlhDOWlDajZVYjhHUWR1QytIcDJrbG8zR2tZOVpVd2oyWWFh?=
 =?utf-8?B?c1RtVjdWMU5HcEg5WkNqSzltSFcxTHJPMy9HZU5LL3JsaTRFaEFhM2ZpM0pQ?=
 =?utf-8?B?ZWVIb0l1c2JBTE9MMUdsN1dKVzlZV2NJdVQrSnNJL0dLM1d0MldCUklFT0NF?=
 =?utf-8?B?OWQ0NDE3N1pUUXJxWWo2VldZR3lXUUpIS2lNb1lpOG5WMDRlMnR5NFJWY3RK?=
 =?utf-8?B?Y2p1Qm05RjRRNlN4eFh4RW1CS08ybVFBVmVQR1ZHU21oLzd1UWJCYzJzSGcw?=
 =?utf-8?B?c3B6bkN3Y0FaMnJPYzFVRUkyTU5TZnVRaUE5azBxRHc1S3ZqSSs4U2RjY3RR?=
 =?utf-8?B?Y1pUeGtaMmQzUUtnVzV2U3N4cVVhcU9scG1oSUJUQjZ3SGp4dFRyaStETmZO?=
 =?utf-8?B?dyt2SlNMMjBJWkVLUmFDa0dGMlloWHVwZEIyb210YU1OdjRvVllnalRqQkk0?=
 =?utf-8?B?cC93NXJpbU5yOFNOc2FSTStMdmw1VUdDVVpXSmZONTlTYzBudTdxNHNoczhr?=
 =?utf-8?B?QWpDNXBNWlNaSnk2OHN6Tjl5ZExNUUVsckFGVEpMSXhCRU1CR3FWZktxM0s3?=
 =?utf-8?B?UnJYUE5yQVkxdmdyaXlpK1Y1YmY1MnhwcjBuMS9BbExUVkhidXEwenM2R01R?=
 =?utf-8?B?dDh4QVhUWk1BNTZ3MDNTMDZwT0xQZXRaTWVEMlRHdW1XRmZrVjlDUkdmdnZO?=
 =?utf-8?B?NERWVHNHeFY3aXhkelRHRlM2Q2xEUlFad293dllxTUs5TkZPN2xUS1RTRk5s?=
 =?utf-8?B?NGFrRjFQNFdhTXNhM0ZXK0dkUzJhVUpJa3BUY2U2ZG5TS0dRa25Db2pIcS80?=
 =?utf-8?B?RktnUm9WKy93a0ViaGxmc0NxZlVaVEsyMEVrbnBvUVdlbld3UytnRTMrUzcy?=
 =?utf-8?B?NnpzcXZXYXFMQWhRZkJReU9MQXh1bFltT1FqbW1VdGQ4SUZWYW5MQUh3MC9U?=
 =?utf-8?B?YTg0ZzVJaXlMSDhDSFhEbEZHY1FJcXk5c0lDMElkdG9INUJ5aExDUXpqd0xr?=
 =?utf-8?B?UEVKSjMwRWZ3cnlOTys4dzc4SmdnVkw4R0NrQnRkb1JKN3A0WFNEUENHcHZv?=
 =?utf-8?B?bHhXbzUyNUNuYnFZZVplNFBqb1FNYkJlUXo1NVFTOWsyYlZZd2EwMWlDSUJG?=
 =?utf-8?B?eFhSU09tb1FQRWdDa3Z3MURTTnB5OW44WjduUytJdGRPcmNRamdwR1lWRzZZ?=
 =?utf-8?B?K3ZBa0R6RHVab0wwVURqUG96N3NuNWlySHBDaTFlUXRVVitZaGVYanltRGZx?=
 =?utf-8?B?bHlydFJSZ25obDlCMG9DNHAvTGwzcWhpaXpmNXZTWGpDUEZWNzViT2hCdGl2?=
 =?utf-8?B?ZXJDYlpEMDl1T2pkdEJlbng2em5HSk1TVW90YjdxbzFEbGVFcW54bngwM1Ni?=
 =?utf-8?B?K0ZuUWNBQnp2WEZBa0dWekZ2RiswQW83aEwxd2owVzJZVGJzNEFpeWhUYTgx?=
 =?utf-8?B?YXlsVHhRSGVnQ2hVZDRoTEdkYkN0ZE02eStQQk9PMjRxdVcrUmNSc0lycW41?=
 =?utf-8?B?bGNIYmFtQUlFR1lacTl3NE9SV3JqVzlqbmZwbXhSdkNPdHRIbE9NQ1lvY1B2?=
 =?utf-8?B?MjM1QTc5WHo4OVcxL2ZDdXdlS2EvV2pneE1Yd0ppb1RYSUd3QVhLZ3VYSFdk?=
 =?utf-8?B?VmZPNm1rcVdlcVRvS1NvVkNNTUVsNXFHNERBaGdqTEh2d2NTTDEwa0htVnpZ?=
 =?utf-8?B?SmhrTmlFeno4T21XT3ZURlBpTUNNUFFQTVFYUWlYSW11c2ZZK3VIcVNIR1hK?=
 =?utf-8?B?VFluR3BGbkhCUUdtK3lmOVllbzRWdDZIaDlsQTVVTThPbG5VWURSSW9WeWVS?=
 =?utf-8?B?NWt3WjV5QW4zdjVBSWFRYmlDRmlZbVpqcG8rWUhQOUtucW1vQlVuekFQaTlY?=
 =?utf-8?B?ZHl5ekNVNGxudS8xK01yaVphMVZlMjRIcGVsRldHTFNTMFl2WVBITlhEWFE2?=
 =?utf-8?Q?Y2G6BM/0N1t+cb5kEVuJQ0G08O1Ygo=3D?=
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:(13230040)(376014)(1800799024)(36860700013)(82310400026)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jan 2025 10:01:00.9967
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 321041d1-9b83-4a9d-e7cb-08dd309485a0
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:
	SJ1PEPF00001CE2.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB5958

Hi Luca,

Is this patch for 4.20? I would say so, therefore it should have "for-4.20" tag and Oleksii as release manager
should be CCed. Doing it now.

On 09/01/2025 10:28, Luca Fancellu wrote:
> 
> 
> Commit a14593e3995a ("xen/device-tree: Allow region overlapping with
> /memreserve/ ranges") introduced a type in the 'struct membanks_hdr'
> but forgot to update the 'struct kernel_info' initialiser, while
> it doesn't lead to failures because the field is not currently
> used while managing kernel_info structures, it's good to have it
> for completeness.
> 
> There are other instance of structures using 'struct membanks_hdr'
> that are dynamically allocated and don't fully initialise these
> fields, provide a static inline helper for that.
> 
> Fixes: a14593e3995a ("xen/device-tree: Allow region overlapping with /memreserve/ ranges")
> Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
> ---
> Changes from v1:
>  - Changed commit title and body msg
>  - initialised max_banks and type for all structures using 'struct membanks_hdr'
> 
> I didn't get why the fixes tag is wrong, but please feel free to
> correct it on commit or suggest the good one
It is ok.

> ---
> ---
>  xen/arch/arm/domain_build.c       | 13 ++++---------
>  xen/arch/arm/include/asm/kernel.h |  5 ++++-
>  xen/arch/arm/static-shmem.c       |  3 ++-
>  xen/include/xen/bootfdt.h         | 16 ++++++++++++++++
>  4 files changed, 26 insertions(+), 11 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index b072a16249fe..9e3132fb21d8 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1039,7 +1039,7 @@ void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
>       */
>      if ( is_hardware_domain(d) )
>      {
> -        struct membanks *gnttab = xzalloc_flex_struct(struct membanks, bank, 1);
> +        struct membanks *gnttab = membanks_xzalloc(1, RESERVED_MEMORY);
>          /*
>           * Exclude the following regions:
>           * 1) Remove reserved memory
> @@ -1057,13 +1057,10 @@ void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
>          gnttab->bank[0].start = kinfo->gnttab_start;
>          gnttab->bank[0].size = kinfo->gnttab_size;
> 
> -        hwdom_free_mem = xzalloc_flex_struct(struct membanks, bank,
> -                                             NR_MEM_BANKS);
> +        hwdom_free_mem = membanks_xzalloc(NR_MEM_BANKS, MEMORY);
>          if ( !hwdom_free_mem )
>              goto fail;
> 
> -        hwdom_free_mem->max_banks = NR_MEM_BANKS;
> -
>          if ( find_unallocated_memory(kinfo, mem_banks, ARRAY_SIZE(mem_banks),
>                                       hwdom_free_mem, add_hwdom_free_regions) )
>              goto fail;
> @@ -1293,7 +1290,7 @@ static int __init find_host_extended_regions(const struct kernel_info *kinfo,
>                                               struct membanks *ext_regions)
>  {
>      int res;
> -    struct membanks *gnttab = xzalloc_flex_struct(struct membanks, bank, 1);
> +    struct membanks *gnttab = membanks_xzalloc(1, RESERVED_MEMORY);
> 
>      /*
>       * Exclude the following regions:
> @@ -1374,12 +1371,10 @@ int __init make_hypervisor_node(struct domain *d,
>      }
>      else
>      {
> -        ext_regions = xzalloc_flex_struct(struct membanks, bank, NR_MEM_BANKS);
> +        ext_regions = membanks_xzalloc(NR_MEM_BANKS, RESERVED_MEMORY);
I'm a bit confused what is the expectations behind using different types of enum region_type, mostly because it can point to
different address spaces depending on the context. Above, you marked gnttab as RESERVED_MEMORY (I guess because this
region has already been found - but in fact it is still unused) and hwdom_free_mem as MEMORY. So I would at least expect
ext_regions to be of MEMORY type as well. After all both hwdom_free_mem and ext_regions contain
banks of unused/free memory (although former lists host memory while latter can also contain guest physical
memory). Could you please clarify the intended use?

~Michal



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 10:02:33 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 10:02:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867986.1279524 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVpN3-0006LB-6Q; Thu, 09 Jan 2025 10:02:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867986.1279524; Thu, 09 Jan 2025 10:02:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVpN3-0006L4-1y; Thu, 09 Jan 2025 10:02:33 +0000
Received: by outflank-mailman (input) for mailman id 867986;
 Thu, 09 Jan 2025 10:02:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=bl7y=UB=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tVpN1-0006Kw-R8
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 10:02:31 +0000
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com
 [2a00:1450:4864:20::42e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d6473498-ce70-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 11:02:30 +0100 (CET)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-3863c36a731so516624f8f.1
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 02:02:29 -0800 (PST)
Received: from localhost ([66.81.170.107]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a8e4b81b1sm1365516f8f.66.2025.01.09.02.02.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 02:02:28 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: d6473498-ce70-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736416949; x=1737021749; darn=lists.xenproject.org;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=7taUQX4gFuWHdN9JpHRdnhM6vwp4FN1NNAvz13wXefk=;
        b=MrziLrAb2FPEKGuWeHF15UDJ5+7I9zKwjcib2/KfAjC89SvabwVBtJhQG7Kn5S2Moq
         Bu0kJtzyE6TW6MWoraDHaJ55XCrg8BzTouK0RxwV7adFb/yiJAnVyFLtKfDTl9Hkiik0
         U3oJkXL2tRySkmD8uip8VKwHbxnKQp6hmV1y8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736416949; x=1737021749;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=7taUQX4gFuWHdN9JpHRdnhM6vwp4FN1NNAvz13wXefk=;
        b=jbOwCl3SKuim1Tg0ZYZ3WTvWuubK6fXLmxNymDVKnRVCLZrsnXOG6gBWt5JFbwxA3+
         KVYw1qCKGw6qosrSJPbX4B9tOCK5iWvXd5us+e6VmW3BGd/1rrhkVieZ8SkTu8n1pUIl
         PDw2zQCmj0Ry3U0xLlmSwDeDXz5dJLEqN8rGP5NGP0vNHNqzwqUKDgkmBDm30uQilkAQ
         pEV2IXrhfRZJyCw45b00hYteRtxDSQolnef29nqbZEP8L1lxq+29qdPIerz9zdxFW9jt
         O1LwaqINKWtWOuDGMJPC6JiXEIlQa9jm/uSG4LP2qV9svtYwKjWYIxPpLMmrwcCjAhSa
         zTbA==
X-Forwarded-Encrypted: i=1; AJvYcCWGRa5gyhuTCxkZCUET8phqKjpDZhmu0+VxGEo+PpOmLGlihEMmjMexneNSPlJg4C8/VtWSZ+RLIzI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwoLspM4HqyXpWAs1kSeDkwREcmAGCSyH47FtVNSafCvQlxxRK6
	3rmE8dqS5zKVSmGIjQ+rk7S7b8UldII8STk0abJ4SdX5zyje5vD3C0CXD0W87PA=
X-Gm-Gg: ASbGncueskwfdYBW1LlIZbXNYseyvsxYy5ltQFAtgNbVk2cfiLTkCvgPxfDTcph8jfv
	vSj7/wE3ruhvOJ4bPUdakE/b0MO8JgBPhG/AScSYkE/YFHVgw5hCHPPVlnbiN4KL4smyLzcBSNW
	4SZe6CUaZ3bHZdg8xa6EoP40Dj1ZGvNf6SxV/IRyksaC771rWihzPxAuFnKRCoqXJdCyzRt6/3c
	bQW64Zy9uEB+FDxbxaPwjU9Gx6OzlswQu5t2hx2ecnseUWyTr5qUEDfKcshbkc=
X-Google-Smtp-Source: AGHT+IFhoSdng/+TCaEoK/iD6N/XGyLuXf/e0BCMtz0DFOQB36VSd0Uzas2qhhcIN+ElU8BBaI7jQw==
X-Received: by 2002:a05:6000:1f82:b0:385:f560:7924 with SMTP id ffacd0b85a97d-38a872fc5cbmr4299364f8f.4.1736416949193;
        Thu, 09 Jan 2025 02:02:29 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Thu, 09 Jan 2025 10:02:19 +0000
Message-Id: <D6XGFLRRLY4N.3IFSIDMFC4BVJ@cloud.com>
Cc: "Jan Beulich" <jbeulich@suse.com>, "Andrew Cooper"
 <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v2 05/18] x86/mm: switch destroy_perdomain_mapping()
 parameter from domain to vCPU
From: "Alejandro Vallejo" <alejandro.vallejo@cloud.com>
To: "Roger Pau Monne" <roger.pau@citrix.com>,
 <xen-devel@lists.xenproject.org>
X-Mailer: aerc 0.18.2
References: <20250108142659.99490-1-roger.pau@citrix.com>
 <20250108142659.99490-6-roger.pau@citrix.com>
In-Reply-To: <20250108142659.99490-6-roger.pau@citrix.com>

On Wed Jan 8, 2025 at 2:26 PM GMT, Roger Pau Monne wrote:
> In preparation for the per-domain area being populated with per-vCPU mapp=
ings
> change the parameter of destroy_perdomain_mapping() to be a vCPU instead =
of a
> domain, and also update the function logic to allow manipulation of per-d=
omain
> mappings using the linear page table mappings.
>
> Signed-off-by: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
> ---
>  xen/arch/x86/include/asm/mm.h |  2 +-
>  xen/arch/x86/mm.c             | 24 +++++++++++++++++++++++-
>  xen/arch/x86/pv/domain.c      |  3 +--
>  xen/arch/x86/x86_64/mm.c      |  2 +-
>  4 files changed, 26 insertions(+), 5 deletions(-)
>
> diff --git a/xen/arch/x86/include/asm/mm.h b/xen/arch/x86/include/asm/mm.=
h
> index b50a51327b2b..65cd751087dc 100644
> --- a/xen/arch/x86/include/asm/mm.h
> +++ b/xen/arch/x86/include/asm/mm.h
> @@ -605,7 +605,7 @@ int create_perdomain_mapping(struct domain *d, unsign=
ed long va,
>                               struct page_info **ppg);
>  void populate_perdomain_mapping(const struct vcpu *v, unsigned long va,
>                                  mfn_t *mfn, unsigned long nr);
> -void destroy_perdomain_mapping(struct domain *d, unsigned long va,
> +void destroy_perdomain_mapping(const struct vcpu *v, unsigned long va,
>                                 unsigned int nr);
>  void free_perdomain_mappings(struct domain *d);
> =20
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index 0abea792486c..713ae8dd6fa3 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -6511,10 +6511,11 @@ void populate_perdomain_mapping(const struct vcpu=
 *v, unsigned long va,
>      unmap_domain_page(l3tab);
>  }
> =20
> -void destroy_perdomain_mapping(struct domain *d, unsigned long va,
> +void destroy_perdomain_mapping(const struct vcpu *v, unsigned long va,
>                                 unsigned int nr)
>  {
>      const l3_pgentry_t *l3tab, *pl3e;
> +    const struct domain *d =3D v->domain;
> =20
>      ASSERT(va >=3D PERDOMAIN_VIRT_START &&
>             va < PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS));
> @@ -6523,6 +6524,27 @@ void destroy_perdomain_mapping(struct domain *d, u=
nsigned long va,
>      if ( !d->arch.perdomain_l3_pg )
>          return;
> =20
> +    /* Use likely to force the optimization for the fast path. */
> +    if ( likely(v =3D=3D current) )

As in the previous patch, doesn't using curr_vcpu here...

> +    {
> +        l1_pgentry_t *pl1e;
> +
> +        /* Ensure page-tables are from current (if current !=3D curr_vcp=
u). */
> +        sync_local_execstate();

... avoid the need for this?

> +
> +        pl1e =3D &__linear_l1_table[l1_linear_offset(va)];
> +
> +        /* Fast path: zap L1 entries using the recursive linear mappings=
. */
> +        for ( ; nr--; pl1e++ )
> +        {
> +            if ( perdomain_l1e_needs_freeing(*pl1e) )
> +                free_domheap_page(l1e_get_page(*pl1e));
> +            l1e_write(pl1e, l1e_empty());
> +        }
> +
> +        return;
> +    }
> +
>      l3tab =3D __map_domain_page(d->arch.perdomain_l3_pg);
>      pl3e =3D l3tab + l3_table_offset(va);
> =20
> diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
> index bc7cd0c62f0e..7e8bffaae9a0 100644
> --- a/xen/arch/x86/pv/domain.c
> +++ b/xen/arch/x86/pv/domain.c
> @@ -285,8 +285,7 @@ static int pv_create_gdt_ldt_l1tab(struct vcpu *v)
> =20
>  static void pv_destroy_gdt_ldt_l1tab(struct vcpu *v)
>  {
> -    destroy_perdomain_mapping(v->domain, GDT_VIRT_START(v),
> -                              1U << GDT_LDT_VCPU_SHIFT);
> +    destroy_perdomain_mapping(v, GDT_VIRT_START(v), 1U << GDT_LDT_VCPU_S=
HIFT);
>  }
> =20
>  void pv_vcpu_destroy(struct vcpu *v)
> diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
> index 389d813ebe63..c08b28d9693b 100644
> --- a/xen/arch/x86/x86_64/mm.c
> +++ b/xen/arch/x86/x86_64/mm.c
> @@ -737,7 +737,7 @@ int setup_compat_arg_xlat(struct vcpu *v)
> =20
>  void free_compat_arg_xlat(struct vcpu *v)
>  {
> -    destroy_perdomain_mapping(v->domain, ARG_XLAT_START(v),
> +    destroy_perdomain_mapping(v, ARG_XLAT_START(v),
>                                PFN_UP(COMPAT_ARG_XLAT_SIZE));
>  }
> =20

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 10:10:14 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 10:10:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.867997.1279533 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVpUO-0007vN-S5; Thu, 09 Jan 2025 10:10:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 867997.1279533; Thu, 09 Jan 2025 10:10:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVpUO-0007vG-Oi; Thu, 09 Jan 2025 10:10:08 +0000
Received: by outflank-mailman (input) for mailman id 867997;
 Thu, 09 Jan 2025 10:10:07 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=FDwX=UB=arm.com=Luca.Fancellu@srs-se1.protection.inumbo.net>)
 id 1tVpUN-0007rU-29
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 10:10:07 +0000
Received: from outbound.mail.protection.outlook.com
 (mail-vi1eur05on20609.outbound.protection.outlook.com
 [2a01:111:f403:2613::609])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e3a33591-ce71-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 11:10:02 +0100 (CET)
Received: from DBAPR08MB5798.eurprd08.prod.outlook.com (2603:10a6:10:1a6::21)
 by AM9PR08MB6180.eurprd08.prod.outlook.com (2603:10a6:20b:2d4::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8335.13; Thu, 9 Jan
 2025 10:09:59 +0000
Received: from DBAPR08MB5798.eurprd08.prod.outlook.com
 ([fe80::4a66:d3e2:570:9632]) by DBAPR08MB5798.eurprd08.prod.outlook.com
 ([fe80::4a66:d3e2:570:9632%4]) with mapi id 15.20.8335.010; Thu, 9 Jan 2025
 10:09:58 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e3a33591-ce71-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=OzhHYg4LqFCJlaiwmaYo+lXeb4z0yV5rm3XiwlObOEYbYVSb2IwgSyTkI2EfEWFpnVDJjjOvsqraPEYR0vWcjSRydL3o95GoQ+sj5ppVswG/iUOuZu5cFvLpQE7LR9bjmAI7Dzg+tvnaWMpxGeEBfUzqeXEVbCcYl2Csxw7b3DIHRh55MtkrhygMSN7ClE6QuFLo3yOm0NleZyc5WSXvz4uMOCS+TuP66NuKfCKDqsRmtjQ84wrGI6N76LV/ebyCG5y11Ou5NUJIFNwLL/mrxNTp8mX4VE/Zp2/qkUfv1LNDd9FRzoyv+GJvxEDLnCyfbxGAL63CIeUATHTjKsMnGg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=ZKxiY85iOdYzyELpJW++TTgyoEqWft1bhoqEQ22Et30=;
 b=pSVSWa5dtUXRF3/Fxuu6dgztWX05bTuvEpg8bLUf+azMHIr1FwkUSoVIll3QDITNADlG1xOiLqZ/8lMY+KYcDAUrLJA6B/TeI+Qi2E9ZL+NQdl4KG0HX0x1a8Q4sx93j5X2NTbJdnu6SMjqw1Z2fnVbYM4UYsXtdtpkRGBanCxh1b0NoSU6x+6s4Cn+YjH5W23g3Cjn76tu1d7ss6/nZ44oI94vYGDZibgDUSkrx3dsmjbRFji9mP4N1+tKYHmrtkEv31WQxINjGHn2rY0387B+OiqMXivn3SsrMSjBZhempFlAGGTNgbeLVMVOGULEjsE9+UziCx1n2PrvuD2TE8A==
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=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=ZKxiY85iOdYzyELpJW++TTgyoEqWft1bhoqEQ22Et30=;
 b=NBrfPvBXGeuT/j4efzjPbitycDyQ8mm4CPi0UDDZLzbJA92GnnKDPAa5joGQYHce0OxVKmhDbigDq/Ojjf8zb7ioWxDjWxZ0nfkHdezUQ/Ln+9XyWI0HT2xF7r4BevHO0j7+Vg1JmRVlLUW6I1NYRDI+H55IcdIOinW+hWOIqCQ=
From: Luca Fancellu <Luca.Fancellu@arm.com>
To: Michal Orzel <michal.orzel@amd.com>
CC: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Stefano
 Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand
 Marquis <Bertrand.Marquis@arm.com>, Volodymyr Babchuk
	<Volodymyr_Babchuk@epam.com>, Oleksii Kurochko <oleksii.kurochko@gmail.com>
Subject: Re: [PATCH v2] xen/arm: Fully initialise struct membanks_hdr fields
Thread-Topic: [PATCH v2] xen/arm: Fully initialise struct membanks_hdr fields
Thread-Index: AQHbYnjhSKvjiFv/ZkKm32Sq0WkbbrMONdAAgAACYAA=
Date: Thu, 9 Jan 2025 10:09:58 +0000
Message-ID: <7D68D11E-E4EF-4521-9017-112DAA2B9B11@arm.com>
References: <20250109092816.1619834-1-luca.fancellu@arm.com>
 <e9477b85-1c9a-4aa6-b7fe-90286fcd461b@amd.com>
In-Reply-To: <e9477b85-1c9a-4aa6-b7fe-90286fcd461b@amd.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.200.121)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DBAPR08MB5798:EE_|AM9PR08MB6180:EE_
x-ms-office365-filtering-correlation-id: b77417a7-8b2e-48a7-743f-08dd3095c628
x-checkrecipientrouted: true
nodisclaimer: true
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700018;
x-microsoft-antispam-message-info:
 =?us-ascii?Q?bZDTHJdAItntTwVFtAYbnW4JpFc0dYRD4TTdZE+XOpmhqcQGwq5qSF05JlH4?=
 =?us-ascii?Q?t3CdKksv9qS2n1A+t6cK1tFd09GUxM3nQ34nwEPrwGUNNxe3wP+zzdVbiK9g?=
 =?us-ascii?Q?5FDNnnKd6WZRLS0LbnJGLHrdYk/6PKdN2ew93bFCo44E+ujbj4qHm/SKVnHd?=
 =?us-ascii?Q?afoMpK9lJYIFYzP/pBV3Jccv/+pv6cRIUQM8xclGdYvmiHTCueha4r/70Z0A?=
 =?us-ascii?Q?WK96HdEhZSESel20wj3LleGp4CLOcT9ao38uXFqRJW9bUsC555Qd103oJM0l?=
 =?us-ascii?Q?Xx0y5iyxPAy9+7L/45xFjkOVl8yjjPEp8zARnkwUoOxeXXQPH0PnJZcwbyOb?=
 =?us-ascii?Q?zp8HahOliPJkcV/bwQdRJ1RMHUEG47dodc5GtxOdL8Rt/5ScaOs4XlJJLmcR?=
 =?us-ascii?Q?fLOIIWia3MZQDx5eeqSeKg0httaEWddoaPOZndfEC5g5Zx19yx9HxMsCqVTG?=
 =?us-ascii?Q?dwub/2ZQtmAZ1FVfp7/bIIjtkRs2tELIJhJr/b0UOBL2//b/YhLa2vB9sBQX?=
 =?us-ascii?Q?5a8Sjmh2/lSPUzNDje4C1kcDgo+64vkGcILqa9Yrph2o/Cmp8y1Pi2+3JAaU?=
 =?us-ascii?Q?85ODmw93irHwSdKPNNvSs85ThqS8K/6AXj4BLkL3WCDWjVygDWNtGRl45TUd?=
 =?us-ascii?Q?dZY+hkHai5rznreKuGo0XpDVSr/WGTkBSdwU1ZFZMcqPNsqGV/JEDrnDjShF?=
 =?us-ascii?Q?tGF6gwy/5KjjbF3Ui3AwojjQwUCCAPIwo5RGH6w5qSIdeV0e7SY61iSu6ags?=
 =?us-ascii?Q?T2sMnqJsd+452nAkUP7G8YBlSZGr8a/7zKQAsYWgxeYwIpPu9CieA+eGByDa?=
 =?us-ascii?Q?Wb3MUrz8aVDfyJfvPJg3tBZpWxtJfOnL1pUMiVHDnl9k8BA98RTeqDToi91Z?=
 =?us-ascii?Q?6ai4WyqVdmTA0iXs62CXkBeFVM20BmaFRNSGAF9dK/fYnvNIMTG4v51lSLTS?=
 =?us-ascii?Q?xzwx45nisMgu7poWAdgYfalsaZbF8GsbWRgS1FyCnk5sDFSfF2suo3IE7/kd?=
 =?us-ascii?Q?Mpbv0HGGv0sZxw9WpfYHXMhlFBOgZwIfd1ZZuJvXc0E+asVDVXh9CheGH444?=
 =?us-ascii?Q?qwgDmarft/zOagVPUv0Nj+QAn9nZyma6LWYDVT94BXowePxe5NYU+LxNMW7g?=
 =?us-ascii?Q?jv8HKMZKRvSoaxJ63LQA/mG8HmLbfqVUrNPrC3qRxih8H95d5cLPf0a4yCLo?=
 =?us-ascii?Q?O0LMewu8/KAt4xbANsYu2FnAKoUggwuRk3WFcL+kvKYUbbPMsAmxwfbCjaDN?=
 =?us-ascii?Q?Phd1736EvCmTj7sYpLr23h68ftzHshacRYfeWZ7UJMIzBgORFd9dm1g0n+iz?=
 =?us-ascii?Q?1NLUIqwgMRWi0q4GfbLe7TMVLNJEHfbrbkigu7mGbw11yGvkPfGdZk9FbGCk?=
 =?us-ascii?Q?AW6UZzsHPMSus2TYgtPmH1xmywzChzHeGPYZRW51zkFBpjArD7kp9gEXLO+9?=
 =?us-ascii?Q?1o0JYa0JW5T6Rt99tq+vVnh09AhQh2Wo?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DBAPR08MB5798.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?MCevzd3AvwstkvAvm4k0Y4JaXe3WhvBOLmLX2ndNDiMSLleD51hbgLnoI1fb?=
 =?us-ascii?Q?m5OkeEo4rO3DjjQRH202u05MAY1ANRqJ1Ib2QfE0kitRUmykm2MzutX+T0+b?=
 =?us-ascii?Q?rbwIliLCwsfFnVLJ6P9GS+k7IonHKhOYJJugkiuXFOj73wGHr3FfBzqdrn+j?=
 =?us-ascii?Q?pb2U0ztkQQKMjOyZz38F+Go/2xqu/v/6qqnXRd6bwa2qqL8jQTboU6anrbZe?=
 =?us-ascii?Q?X8hTPwNgGufj0brhm+JqeSYRyuQBPkw+HvSzu6OG/jeKdsEcpjRxizyHXdb4?=
 =?us-ascii?Q?rF5d+4Aiyaj9qeVesWLDWWhIDJ78Qri4H4DakYROqzj4LGZqq9zQ/g2YZFiy?=
 =?us-ascii?Q?5eNtN7DRGWZjxkq4Id/Wy8wDG2p8RVRjLgD2ficdXqsgwmjA8ZiprW/LT7bz?=
 =?us-ascii?Q?ycB7RWkkdWmSqnnsoU09AdI+gseEoIN9bq7TS8+N9t2sqSpkQWGZROG3hwKx?=
 =?us-ascii?Q?I3PCAMjmIvmc/bkYBsQ3qAiIY2y0SAJx74WB25bQ0cAkG7fvQpoyQBySHuuR?=
 =?us-ascii?Q?iMuCJryxYZbrEJPrU76fajFXMlbfAKxfnSDgYPL3khHEeKcHvj2d1CVK1XY9?=
 =?us-ascii?Q?cEU+aUZ5+FBRQzSUkSq8EHiRzNgqIdfNVr4Jv87qTGWQlKvv2GAfF+wU2yaC?=
 =?us-ascii?Q?RA6TCYHSHc6NiS6LkoPaZ4RwMa0+9YTbyl6nh7qiPrHjrfYPbz9dVnrrIl8N?=
 =?us-ascii?Q?GrrSn/DGcbSC+JUyTCtVuqhLrKOJWnEAXnHxDBKbZfgPRyM8eRvZ/O9mZzt2?=
 =?us-ascii?Q?68hNJEdrq+aaZP3qnrxgbn4G+GQ619sNn+LaB5TNKYCWwwAx4y3A7k/+IJC+?=
 =?us-ascii?Q?dLGHhcDDK4JVEnnPANg4qj06sSZNr2MpMO8oS7jnMHknujoGoxbYNpH9tmnt?=
 =?us-ascii?Q?ELCL4Gzfywn+LxaZVvALDw2HNGI4m4tG82H7tkR8+c71x9YkfBl0Ay6x5x3Q?=
 =?us-ascii?Q?cBTGWjD3VbEhjK3AMogOOL7r42PwvPKL8WTAOGeeTlKA1VSQ2dgIR4FLaVYs?=
 =?us-ascii?Q?Q4R6EA5Zli1i2CiFJn9XsUkAv8fJTBGAksDEpDl9WmmPODdM+rJyl5zlvGxN?=
 =?us-ascii?Q?Wm9T6CuFOaEQJxfjIMG9yGI7jrVcAvgIYHffPk14bRMsvCeTW3cPb5lcen6z?=
 =?us-ascii?Q?3FoYFTAaw6rcrXZ4Q7FXFp57IrqqqNd/VgPMrfHlU3GIdhnnFKuW5/C9QEQ7?=
 =?us-ascii?Q?2/rzF4aUXFjokuxpWJ9pkluDFO5qLucOuZvWCaVcS5eUJmRwhfnDT/4p9c2J?=
 =?us-ascii?Q?iyIjUDyQ9mwtMD7a7BrddJieFuZs6GzOec4VKOPwkfbYjtqUUZqV09ekeMSB?=
 =?us-ascii?Q?g6XzCirzL7SLUwPpaq1FBHq8gr52TNMxaeOK73lN5dgLC//l0ZnDpYqQ5thM?=
 =?us-ascii?Q?RKwcf8iXd0HJdIm8YqTAeIsYil7SHCfY/p+mbzF5SCIpulVVxfWC6ONY3fpK?=
 =?us-ascii?Q?HMQLTowTVPAapJSnKp2aR34ALMJQOwStKKX8Dl6RD7nLsxH8Plb1QylypSSD?=
 =?us-ascii?Q?GAi47c6O80xCbCdwkV4Y9sILImNOeSazNNsQr+t6/ukiyu2xpnS/diKzI2Fg?=
 =?us-ascii?Q?KIszKFEc4MNTfV95ugfjt6vJXa1Tl2+gSdbTVV4bUUM64Tr4njMe757oxYev?=
 =?us-ascii?Q?Lw=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <E15CEAA1474D1A4799E48C2CF04BE450@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DBAPR08MB5798.eurprd08.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b77417a7-8b2e-48a7-743f-08dd3095c628
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2025 10:09:58.8696
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: hNOxBahMu6nOVxx8Z6rfM3hPBrJvRo8X7u0e4Dwgwn5N/lKbpaw9f8oThwmL4ERO8NpavDFfUQJ+KNhA1n7fZg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR08MB6180

Hi Michal,

> On 9 Jan 2025, at 10:00, Michal Orzel <michal.orzel@amd.com> wrote:
>=20
> Hi Luca,
>=20
> Is this patch for 4.20? I would say so, therefore it should have "for-4.2=
0" tag and Oleksii as release manager
> should be CCed. Doing it now.

Thanks, I forgot the procedure

>=20
>> ---
>> ---
>> xen/arch/arm/domain_build.c       | 13 ++++---------
>> xen/arch/arm/include/asm/kernel.h |  5 ++++-
>> xen/arch/arm/static-shmem.c       |  3 ++-
>> xen/include/xen/bootfdt.h         | 16 ++++++++++++++++
>> 4 files changed, 26 insertions(+), 11 deletions(-)
>>=20
>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>> index b072a16249fe..9e3132fb21d8 100644
>> --- a/xen/arch/arm/domain_build.c
>> +++ b/xen/arch/arm/domain_build.c
>> @@ -1039,7 +1039,7 @@ void __init allocate_memory(struct domain *d, stru=
ct kernel_info *kinfo)
>>      */
>>     if ( is_hardware_domain(d) )
>>     {
>> -        struct membanks *gnttab =3D xzalloc_flex_struct(struct membanks=
, bank, 1);
>> +        struct membanks *gnttab =3D membanks_xzalloc(1, RESERVED_MEMORY=
);
>>         /*
>>          * Exclude the following regions:
>>          * 1) Remove reserved memory
>> @@ -1057,13 +1057,10 @@ void __init allocate_memory(struct domain *d, st=
ruct kernel_info *kinfo)
>>         gnttab->bank[0].start =3D kinfo->gnttab_start;
>>         gnttab->bank[0].size =3D kinfo->gnttab_size;
>>=20
>> -        hwdom_free_mem =3D xzalloc_flex_struct(struct membanks, bank,
>> -                                             NR_MEM_BANKS);
>> +        hwdom_free_mem =3D membanks_xzalloc(NR_MEM_BANKS, MEMORY);
>>         if ( !hwdom_free_mem )
>>             goto fail;
>>=20
>> -        hwdom_free_mem->max_banks =3D NR_MEM_BANKS;
>> -
>>         if ( find_unallocated_memory(kinfo, mem_banks, ARRAY_SIZE(mem_ba=
nks),
>>                                      hwdom_free_mem, add_hwdom_free_regi=
ons) )
>>             goto fail;
>> @@ -1293,7 +1290,7 @@ static int __init find_host_extended_regions(const=
 struct kernel_info *kinfo,
>>                                              struct membanks *ext_region=
s)
>> {
>>     int res;
>> -    struct membanks *gnttab =3D xzalloc_flex_struct(struct membanks, ba=
nk, 1);
>> +    struct membanks *gnttab =3D membanks_xzalloc(1, RESERVED_MEMORY);
>>=20
>>     /*
>>      * Exclude the following regions:
>> @@ -1374,12 +1371,10 @@ int __init make_hypervisor_node(struct domain *d=
,
>>     }
>>     else
>>     {
>> -        ext_regions =3D xzalloc_flex_struct(struct membanks, bank, NR_M=
EM_BANKS);
>> +        ext_regions =3D membanks_xzalloc(NR_MEM_BANKS, RESERVED_MEMORY)=
;
> I'm a bit confused what is the expectations behind using different types =
of enum region_type, mostly because it can point to
> different address spaces depending on the context. Above, you marked gntt=
ab as RESERVED_MEMORY (I guess because this
> region has already been found - but in fact it is still unused) and hwdom=
_free_mem as MEMORY. So I would at least expect
> ext_regions to be of MEMORY type as well. After all both hwdom_free_mem a=
nd ext_regions contain
> banks of unused/free memory (although former lists host memory while latt=
er can also contain guest physical
> memory). Could you please clarify the intended use?

You are right, that should be MEMORY, my bad! Could it be something address=
able on commit or should I send another one?

Cheers,
Luca



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 10:12:55 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 10:12:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868005.1279544 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVpX4-0000St-9z; Thu, 09 Jan 2025 10:12:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868005.1279544; Thu, 09 Jan 2025 10:12:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVpX4-0000Sm-5N; Thu, 09 Jan 2025 10:12:54 +0000
Received: by outflank-mailman (input) for mailman id 868005;
 Thu, 09 Jan 2025 10:12: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 <SRS0=pS5t=UB=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVpX2-0000SZ-NR
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 10:12:52 +0000
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com
 [2a00:1450:4864:20::429])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 48e0291d-ce72-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 11:12:51 +0100 (CET)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-385df53e559so551419f8f.3
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 02:12:51 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a8e38bf78sm1378448f8f.48.2025.01.09.02.12.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 02:12:50 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 48e0291d-ce72-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736417571; x=1737022371; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=HutWFCHfjg+cZh6uAdegPj1KJlyQXIvkp6rp0EMGEk4=;
        b=NJy45MNpBV/hSR+vgyyZMtw1S2O0NIU/XM012tohqJerxxbRZkLqabbH4LKkj3BSF2
         0zWObFMKaahlZa5puWtoedi8ZrdUER3ozbKdklLBW8L6fkOKc5dFNC1BuSTwiCxOjobZ
         f6Xfrv4ZNy7lScOKhoqCVFZSLi/kUYY03ThgbZzHGy/5oDti9WtTmCJGg/wxUrf6I/aH
         j61EVXTc1BvQeGuqziczzMaMMS10IdIPCUdgRX+72wCLja6xDRW5omoi/eX+VsA+aFAr
         gWY3H5in6rNmAREcw5DPSPnyD06kWnjGObDCDEo8ZcSVjfOvDOkbQ6IgPxL3yH5+tEtX
         h1Kw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736417571; x=1737022371;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=HutWFCHfjg+cZh6uAdegPj1KJlyQXIvkp6rp0EMGEk4=;
        b=k7v5vzTyiGEpz0gpqFaBhmaTZvLu7xHyl00NgiAlWxMx5iKTXvSpZ09Jm3QPp6q6pX
         I+ZQyYTWZDkIwXAHr1D8h+pIpMc6EHO0qsUpwxJZfQ5zQcgJM0j7yZ53ml3Ju66djllg
         cxP6AU20MG5Ivp7ZFCPsbbgJadOFASlDjKkpkWd/gAcpDaSPIbScm+paoEhiNRtIiL2T
         h5JPx4GAJ5LVwvO9AtUQtpwD+XWa9u2/Kpbe6QVPQO3GGpvMyondmVV6aBkseIX73mWu
         aF0FywBw9XVnK6Qs9/M7U213IULryQu44JPpzvHrkKJuizTfJcXAyX3Rg5FzH3kAWzdc
         +51A==
X-Forwarded-Encrypted: i=1; AJvYcCXKQLVwgfV1iCVW48O68lThX7rHP+S9frvklLKyzRfjV7becVCeiw6YEAcQLxcpSOYaHXPlpyRFavg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyJUJs1FGsZzjXx0wyPQVmW/mkA9moP+T7jHRgGP+0c+uWYEOfE
	TN8ve5fK6eRfcxy1nt3ixUQCMDY8AnJNfsEnAFLxzzwzDmDwyUus0dD2omfntg==
X-Gm-Gg: ASbGncvZT5p+ZDx7OD2WXiTqwN4gHUKndBlON0hFgFEV2iMkhY9Mbg/umSXGqXeHVXX
	TQENlfO8oSf0rglzwX8tPStVL++05Ev6ejFej/RtxygFA1JeAOcCz3aVsvY/g+ks+O1f3Uw2hDQ
	cFbVXCx+C1CoyxNtkTC6fri/iBmR7QXV9rXOzbv3Fa5Qj/qi9FSFdqZSrTQAnvWyBp7YoAjvAs9
	FJ2sHCYhjwSiUd/lzl8ARRFPjeM9xElCu7OwTukO1yWWJ7pZ9WbcLv2yp/XfJJffP8MALDsAcKA
	rmcjDdYJsjAHGbPX/asqwp6KezoHr2FbpfbgfxBvYw==
X-Google-Smtp-Source: AGHT+IHoqeeIjIH+cUDDKTzxX+BVbip27/Tw88BAlSRMEf5AcZtLmdbKOQalZnwiDjulf94GyhxlsQ==
X-Received: by 2002:a05:6000:4b04:b0:386:4a24:1916 with SMTP id ffacd0b85a97d-38a87317c6dmr4492266f8f.55.1736417571217;
        Thu, 09 Jan 2025 02:12:51 -0800 (PST)
Message-ID: <69360d8f-61e8-4bdc-b7e4-be67dbdd719b@suse.com>
Date: Thu, 9 Jan 2025 11:12:49 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 04/11] xen/x86: get processor max speed from DMI table
To: Penny Zheng <Penny.Zheng@amd.com>
Cc: stefano.stabellini@amd.com, Ray.Huang@amd.com, Xenia.Ragiadakou@amd.com,
 Jason.Andryuk@amd.com, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>,
 xen-devel@lists.xenproject.org
References: <20241203081111.463400-1-Penny.Zheng@amd.com>
 <20241203081111.463400-5-Penny.Zheng@amd.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20241203081111.463400-5-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 03.12.2024 09:11, Penny Zheng wrote:
> When _CPC table could not provide processor frequency range
> values for OS governor, we need to read processor max frequency
> as anchor point.
> 
> For AMD processors, we rely on parsing DMI table to get processor
> max speed.

That sounds entirely fragile. There are better sources for this info,
aren't there? See e.g. amd_log_freq().

Jan



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 10:13:59 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 10:13:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868015.1279553 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVpY6-00010H-ID; Thu, 09 Jan 2025 10:13:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868015.1279553; Thu, 09 Jan 2025 10: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 <xen-devel-bounces@lists.xenproject.org>)
	id 1tVpY6-00010A-EB; Thu, 09 Jan 2025 10:13:58 +0000
Received: by outflank-mailman (input) for mailman id 868015;
 Thu, 09 Jan 2025 10:13:57 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <anthony@xenproject.org>) id 1tVpY5-000102-Fv
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 10:13:57 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <anthony@xenproject.org>) id 1tVpXw-00CjsF-08;
 Thu, 09 Jan 2025 10:13:48 +0000
Received: from lfbn-gre-1-248-145.w90-112.abo.wanadoo.fr ([90.112.205.145]
 helo=l14) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from <anthony@xenproject.org>) id 1tVpXv-009DaG-37;
 Thu, 09 Jan 2025 10:13:48 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding:
	Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date;
	bh=9tmbhfhUfBgbbojY26HWM7Bm8oOBTYN0N1sCjYdDK/o=; b=DxY3FbPQPuQw1c5MViigEAbIP8
	MZ1jDg09m7OpztLiJhAPUD0FpbQY7szXezM3Pbw2Y4kg1hqAY+IjNQKzysuznc0Zb/HUmaQAiT0ht
	StUM8NiNtULQltoN5gU4afQohn4GJNzpW16WsGfDRJmzEkhJ7IKoPHM58AJxiRtrULMM=;
Date: Thu, 9 Jan 2025 11:13:45 +0100
From: Anthony PERARD <anthony@xenproject.org>
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: qemu-devel@nongnu.org, Stefano Stabellini <sstabellini@kernel.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	=?iso-8859-1?Q?Marc-Andr=E9?= Lureau <marcandre.lureau@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH 1/2] xen/console: fix error handling in
 xen_console_device_create()
Message-ID: <Z3-hWRLyMldV4ZZD@l14>
References: <20250107093140.86180-1-roger.pau@citrix.com>
 <20250107093140.86180-2-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250107093140.86180-2-roger.pau@citrix.com>

On Tue, Jan 07, 2025 at 10:31:39AM +0100, Roger Pau Monne wrote:
> The usage of error_prepend() in some of the error contexts of
> xen_console_device_create() is incorrect, as `errp` hasn't been initialized.
> This leads to the following segmentation fault on error paths resulting from
> xenstore reads:
> 
> Program terminated with signal SIGSEGV, Segmentation fault.
> Address not mapped to object.
>     fmt=0x15c4dfeade42 "failed to read console device type: ", ap=0x15cd0165ab50)
>     at ../qemu-xen-dir-remote/util/error.c:142
> 142         g_string_append(newmsg, (*errp)->msg);
> [...]
> (gdb) bt
>     (errp=0x15cd0165ae10, fmt=0x15c4dfeade42 "failed to read console device type: ", ap=0x15cd0165ab50) at ../qemu-xen-dir-remote/util/error.c:142
>     (errp=0x15cd0165ae10, fmt=0x15c4dfeade42 "failed to read console device type: ")
>     at ../qemu-xen-dir-remote/util/error.c:152
>     (backend=0x43944de00660, opts=0x43944c929000, errp=0x15cd0165ae10)
>     at ../qemu-xen-dir-remote/hw/char/xen_console.c:555
> 
> Replace usages of error_prepend() with error_setg() where appropriate.
> 
> Fixes: 9b7737469080 ('hw/xen: update Xen console to XenDevice model')
> Signed-off-by: Roger Pau Monn� <roger.pau@citrix.com>
> ---
>  hw/char/xen_console.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
> index ef0c2912efa1..af706c7ef440 100644
> --- a/hw/char/xen_console.c
> +++ b/hw/char/xen_console.c
> @@ -551,7 +551,7 @@ static void xen_console_device_create(XenBackendInstance *backend,
>      }
>  
>      if (xs_node_scanf(xsh, XBT_NULL, fe, "type", errp, "%ms", &type) != 1) {
> -        error_prepend(errp, "failed to read console device type: ");
> +        error_setg(errp, "failed to read console device type: ");

According to error_setg() doc, *errp must be NULL but xs_node_scanf may
set it. Looking at the implementation, error_setg() seems to simply
discard this new error message if *errp is already set.

Currently, when there's an I/O error, we get something like:
    failed to read console device type: failed to read from /xenstore/path: doesn't exist
and when the format scan failed:
    SEGV

With this patch, when there's an I/O error, I think we get something
like:
    failed to read from /xenstore/path: doesn't exist
and when the format scan failed:
    failed to read console device type: 


So I think we'll want to distiguish between IO error from
xs_node_scanf() and format error, first one returns EOF (like vsscanf)
and second one returns a value >= 0 but we expect exactly 1.


>          goto fail;
>      }
>  
> @@ -582,7 +582,7 @@ static void xen_console_device_create(XenBackendInstance *backend,
>      } else if (number) {
>          cd = serial_hd(number);
>          if (!cd) {
> -            error_prepend(errp, "console: No serial device #%ld found: ",
> +            error_setg(errp, "console: No serial device #%ld found: ",
>                            number);

This change looks correct, ableit we could remove ":  " from the end of
the string since they shouldn't be anything after it.


Cheers,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 10:14:15 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 10:14:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868019.1279562 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVpYN-0001Q1-SE; Thu, 09 Jan 2025 10:14:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868019.1279562; Thu, 09 Jan 2025 10:14:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVpYN-0001Ps-PD; Thu, 09 Jan 2025 10:14:15 +0000
Received: by outflank-mailman (input) for mailman id 868019;
 Thu, 09 Jan 2025 10:14: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
 <SRS0=KjpQ=UB=amd.com=Michal.Orzel@srs-se1.protection.inumbo.net>)
 id 1tVpYM-0001IB-2j
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 10:14:14 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on2061a.outbound.protection.outlook.com
 [2a01:111:f403:2416::61a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 77f4c65b-ce72-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 11:14:12 +0100 (CET)
Received: from SA1P222CA0061.NAMP222.PROD.OUTLOOK.COM (2603:10b6:806:2c1::14)
 by DM4PR12MB7694.namprd12.prod.outlook.com (2603:10b6:8:102::6) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8335.10; Thu, 9 Jan
 2025 10:14:07 +0000
Received: from SN1PEPF0002BA4E.namprd03.prod.outlook.com
 (2603:10b6:806:2c1:cafe::c2) by SA1P222CA0061.outlook.office365.com
 (2603:10b6:806:2c1::14) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8335.12 via Frontend Transport; Thu,
 9 Jan 2025 10:14:07 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SN1PEPF0002BA4E.mail.protection.outlook.com (10.167.242.71) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8335.7 via Frontend Transport; Thu, 9 Jan 2025 10:14:06 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 9 Jan
 2025 04:14:06 -0600
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 9 Jan
 2025 04:14:06 -0600
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Thu, 9 Jan 2025 04:14:04 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 77f4c65b-ce72-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Ab02ybmYxKvATToXl40GWYegm2+nZvearUnHEZaMjETGPjiuiPgmMG6LgzuGENMj0PdoGSVgWfNxtlYwNCiNGkxoBNOop3WJWWuGd8Iw/ARDVISGiFSuu5Ya5Qxf8OHZgyGAMYTMd70A4s3XHz7nEUK3WOSV+O8f4YSFW0o/4GIC0bxutHai06rIMDrYAoKmfeqCAEUYC89f4hruY5vTa6ToTbMf61F6y6PsnDWEsUEJ6qvdNEsHNekxINXKAka9lUpcMf8biEb78xCjadY3pORoQknB9o6skj+C5mSxrPVweSnmMCXNj3P0mnKEIwWb9jKoqQGQgMZ2+0zLONuUcA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=smSGo7rGlDa4wsFslbLmLVV+xJ4p3skBkc6e49gTV10=;
 b=T1v48u1rfOupiktmUrSpOAD1qvQTxqC4/RvAZM3NPsd6rPn8R4SivgzzCsahpchhgOM/PFW/ckm+mMX00nOUd5KpqaEo9MHUbKwS7sYRr0l5aGbw176bUz67I882C3nPT7YfOoQWSOMJBtu/uuFuqZ7bkXOSCR4hpYeYaggji4jQotBSxDd171JGj6sHVdFR9D10WABjmrQVP47qOWoRm3TVOmYP3EdYh+RufPbWugw+i0TdTaknvP9YPtTc529BYn/TV/6OToqe30ddfWYqskhYj0reLRA/nVdBEiB8IjKRqvxPDtMwJtwPk4i7A3in9Nv9aIaPLIGdZ0opjVvHhA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=smSGo7rGlDa4wsFslbLmLVV+xJ4p3skBkc6e49gTV10=;
 b=2NSio8MB4ZUQyQcLSHlYLhyYc9fPf/5VClVofkhjzS4QG3qfifn3P6Ft5EpjM4yG1LaRq6Jz8dtMWa3BcAyjzfeCWb7V7eiH4QZLeamDyoC05Q/vn2rMjQHrGygQ8lXjRxL7j3u8ttHnRlHadHKSn2t1acIpCWsKT2zTFjHJK4U=
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: <822cde40-a4a2-4d25-90e1-5421caa7b334@amd.com>
Date: Thu, 9 Jan 2025 11:14:04 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] xen/arm: Fully initialise struct membanks_hdr fields
To: Luca Fancellu <Luca.Fancellu@arm.com>
CC: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"Stefano Stabellini" <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
	"Bertrand Marquis" <Bertrand.Marquis@arm.com>, Volodymyr Babchuk
	<Volodymyr_Babchuk@epam.com>, Oleksii Kurochko <oleksii.kurochko@gmail.com>
References: <20250109092816.1619834-1-luca.fancellu@arm.com>
 <e9477b85-1c9a-4aa6-b7fe-90286fcd461b@amd.com>
 <7D68D11E-E4EF-4521-9017-112DAA2B9B11@arm.com>
Content-Language: en-US
From: Michal Orzel <michal.orzel@amd.com>
In-Reply-To: <7D68D11E-E4EF-4521-9017-112DAA2B9B11@arm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB05.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF0002BA4E:EE_|DM4PR12MB7694:EE_
X-MS-Office365-Filtering-Correlation-Id: c2acadff-81bf-4aa2-fcc9-08dd30965a0b
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|36860700013|376014|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?aGZ2RE00dzlEWHFDTW51YU5YWEgwWW9iemF0RG9GN0RVWWZNU3dMR2s0K3dt?=
 =?utf-8?B?Nnh4emRUQ1VYVnZ4N1ozUTVlZXB5dmEyQWZMQ3d2QUFGLzUzR3RoVlZtK0Qr?=
 =?utf-8?B?ekVVQ25GaCtGWVQ5ZFEwMWNIWUVuVTJ2T2JRYWUxZkc1NmVybXNPU0ZmT0Jm?=
 =?utf-8?B?Q1VyRnNPaUJWQnVHUHpWSWNXZ1M0WTRpVVZab2xkZUw5RmxtYm92a2g5aVlP?=
 =?utf-8?B?NCtiV2E3UTA0NDBUaVNuWHRJU1l3cE13aXBxRnZXenBSK29KNFZidW40N3dE?=
 =?utf-8?B?dHBodVI5WW84RWszTWo2WVZMUTVRbHZTMFdjL1lXMUg5OGZsVmtOVG1ENGps?=
 =?utf-8?B?NGRrSk90MEtZK3Y2MGNVU1NxMklsYlVNRm1udkttVG9kYXkzazlWY1VteGJ3?=
 =?utf-8?B?Mi91N2I1MmtZd2Q5NHB1dGwyTGJNVjJaSWZBL0YrTlc3cUx2M1Fqd25TVGxD?=
 =?utf-8?B?TXNqTXE2dnN1MDIyVENUYTVOZTF3cW9uM0l3MVYxamk4Y21mMERzcllRL1pI?=
 =?utf-8?B?Sm5qS29NZy96WnRNUGk1a3RtUkhTTGthSXpWaXZacWRTelRNa3J4V1YyVzd1?=
 =?utf-8?B?WExDNkQ4ajhYcG96WEVYTTdUZVM0WFphdE5LZVZyVVRFdFZpaHhhSlg0aE1O?=
 =?utf-8?B?M3l6SFNlNVN4VGtTekk0aklJUWpnOWovZXZKSk50YlQ4YzNNd2JoUVprZzZa?=
 =?utf-8?B?L2pKUlJ1YkRlUnY3U09qOGVqMmQyV2k4bHdWeDdjcWdQbXkyY1pCVENrVjNv?=
 =?utf-8?B?S1ZZa2ppQVRFUUtpbEhNNUxwOWJGZ0V5eU1YL2c2TklxLzBJcm1KYmJHYmZm?=
 =?utf-8?B?VUFBb3JDUE1IeFlQbnJJVkVWMmY1QUswUkFwWVFQV2hreVh6dE1Jemx5LzFV?=
 =?utf-8?B?YjN0QVdoN2hXczBQdlJ5dTdCeXFFV0pnR3dIcXlrT2ZobU8vc2QraFA4aXJI?=
 =?utf-8?B?RncxRHVhVldaYWRKMXRSZkhORURBYU93eHdpZGJ2N1ZtSmZQYzkvRlRUK0dI?=
 =?utf-8?B?WW5uMWkwWktoa2J3eGpYbHZVWGZBMzg2S3ludThtV0R0eXFHSGNIcDVOSVZw?=
 =?utf-8?B?OHdzaUc0S3A5YXVzbERxdFlZOWZkQnNTTVVnWHpyNXFaVTBHcDhUT2dhcy9Q?=
 =?utf-8?B?dXYwZWV1UVNoODd0eTc2SzVqUWFaTUg2ZVYxR3dheWFUbmd3WlRLM0QzdUlp?=
 =?utf-8?B?dHhIOUk1M056em5Wbm80bGpHS3Q1VkFXMDl5Q01tNzB3U0dETitwR0p0ZXNI?=
 =?utf-8?B?L3piS3JGa1owS2FYYmR1U2ZCRmo4bS9PVmtJeVR5cUZGODlpZTZuYWhWRlZ1?=
 =?utf-8?B?Z29rZGY1WVJNSWU4ejFPc2Y5VEZvRWlBa212Q202djltUTY1UnlBc3dPRkRB?=
 =?utf-8?B?MUM3MnFTL1B6ZlV2QkdZSi9OdU8rSFJmd3ZnRG1mdXc3UXk3MWtwRUdMNXJ3?=
 =?utf-8?B?b1Vwc2lWWWhtbHg5SU9RcUxHVlY2endUMXQ0aW1iWGw0aWw1Y0Z1c3hoVGdj?=
 =?utf-8?B?VWNFbmduK2krM00xakxGN1pYbkhMUjU2R05WOEZ2eGJLYVdWQWtsVFpUeEV3?=
 =?utf-8?B?ZGNZNG9ZNVpBcDN0UTJIT0V6U0FyUVFHeDlhdWVZVFMyaWduT3N2ZElmUTNq?=
 =?utf-8?B?OUhsOE95N0hweUdOYWhUejl4NDNjbTBraTN0Zk9OZ0NZNGFRL2tSVmtMcGVz?=
 =?utf-8?B?ZUUzVGdyeEZFT3RXa2hjcGpkZ25IQlhSUVBpRWRHaDNJQWZ6QTcraXEyUk1O?=
 =?utf-8?B?SlZIeThiZVRCN1NNRmRZTUlmWVNJbUdnUnFvUzNaYlVKWVI1SUx0cjlMOWFu?=
 =?utf-8?B?WXdkOUxRWUpGdmNaZjBISFA0MWQyZysrMks1MFB2bmpBUFltTDhTcmpBTm1h?=
 =?utf-8?B?dXBVRHYvYmdlNGJwQzYrbG1iWlZHUHA3M0ZUVXUxajI0NFFKN3hrbnhQSlB5?=
 =?utf-8?B?b2d2S0YzYmdJS2cyeVhmSXlOMExyNVhVbnBTUWl0RkxZYW15SXU3Vmx4MHd2?=
 =?utf-8?Q?nsD3DpGqqAIeAcY6VDGraXyljRLVwg=3D?=
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:(13230040)(82310400026)(36860700013)(376014)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jan 2025 10:14:06.9659
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c2acadff-81bf-4aa2-fcc9-08dd30965a0b
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:
	SN1PEPF0002BA4E.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB7694



On 09/01/2025 11:09, Luca Fancellu wrote:
> 
> 
> Hi Michal,
> 
>> On 9 Jan 2025, at 10:00, Michal Orzel <michal.orzel@amd.com> wrote:
>>
>> Hi Luca,
>>
>> Is this patch for 4.20? I would say so, therefore it should have "for-4.20" tag and Oleksii as release manager
>> should be CCed. Doing it now.
> 
> Thanks, I forgot the procedure
> 
>>
>>> ---
>>> ---
>>> xen/arch/arm/domain_build.c       | 13 ++++---------
>>> xen/arch/arm/include/asm/kernel.h |  5 ++++-
>>> xen/arch/arm/static-shmem.c       |  3 ++-
>>> xen/include/xen/bootfdt.h         | 16 ++++++++++++++++
>>> 4 files changed, 26 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>>> index b072a16249fe..9e3132fb21d8 100644
>>> --- a/xen/arch/arm/domain_build.c
>>> +++ b/xen/arch/arm/domain_build.c
>>> @@ -1039,7 +1039,7 @@ void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
>>>      */
>>>     if ( is_hardware_domain(d) )
>>>     {
>>> -        struct membanks *gnttab = xzalloc_flex_struct(struct membanks, bank, 1);
>>> +        struct membanks *gnttab = membanks_xzalloc(1, RESERVED_MEMORY);
>>>         /*
>>>          * Exclude the following regions:
>>>          * 1) Remove reserved memory
>>> @@ -1057,13 +1057,10 @@ void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
>>>         gnttab->bank[0].start = kinfo->gnttab_start;
>>>         gnttab->bank[0].size = kinfo->gnttab_size;
>>>
>>> -        hwdom_free_mem = xzalloc_flex_struct(struct membanks, bank,
>>> -                                             NR_MEM_BANKS);
>>> +        hwdom_free_mem = membanks_xzalloc(NR_MEM_BANKS, MEMORY);
>>>         if ( !hwdom_free_mem )
>>>             goto fail;
>>>
>>> -        hwdom_free_mem->max_banks = NR_MEM_BANKS;
>>> -
>>>         if ( find_unallocated_memory(kinfo, mem_banks, ARRAY_SIZE(mem_banks),
>>>                                      hwdom_free_mem, add_hwdom_free_regions) )
>>>             goto fail;
>>> @@ -1293,7 +1290,7 @@ static int __init find_host_extended_regions(const struct kernel_info *kinfo,
>>>                                              struct membanks *ext_regions)
>>> {
>>>     int res;
>>> -    struct membanks *gnttab = xzalloc_flex_struct(struct membanks, bank, 1);
>>> +    struct membanks *gnttab = membanks_xzalloc(1, RESERVED_MEMORY);
>>>
>>>     /*
>>>      * Exclude the following regions:
>>> @@ -1374,12 +1371,10 @@ int __init make_hypervisor_node(struct domain *d,
>>>     }
>>>     else
>>>     {
>>> -        ext_regions = xzalloc_flex_struct(struct membanks, bank, NR_MEM_BANKS);
>>> +        ext_regions = membanks_xzalloc(NR_MEM_BANKS, RESERVED_MEMORY);
>> I'm a bit confused what is the expectations behind using different types of enum region_type, mostly because it can point to
>> different address spaces depending on the context. Above, you marked gnttab as RESERVED_MEMORY (I guess because this
>> region has already been found - but in fact it is still unused) and hwdom_free_mem as MEMORY. So I would at least expect
>> ext_regions to be of MEMORY type as well. After all both hwdom_free_mem and ext_regions contain
>> banks of unused/free memory (although former lists host memory while latter can also contain guest physical
>> memory). Could you please clarify the intended use?
> 
> You are right, that should be MEMORY, my bad! Could it be something addressable on commit or should I send another one?
I can do that on commit but first, can you please answer what is the intended use of enum region_type?
At first I was expecting gnttab to be MEMORY as well. I don't see a difference between a region prepared by Xen
for domain to store gnttab vs extended regions. Both specify regions of unused address space. It's just that the region
for gnttab must always be present but extended regions don't have to.

~Michal



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 10:21:45 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 10:21:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868038.1279573 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVpfY-0003Lf-K2; Thu, 09 Jan 2025 10:21:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868038.1279573; Thu, 09 Jan 2025 10:21:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVpfY-0003LY-HB; Thu, 09 Jan 2025 10:21:40 +0000
Received: by outflank-mailman (input) for mailman id 868038;
 Thu, 09 Jan 2025 10:21: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
 <SRS0=IHdR=UB=bugseng.com=alessandro.zucchelli@srs-se1.protection.inumbo.net>)
 id 1tVpfX-0003Km-Ae
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 10:21:39 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 821c174f-ce73-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 11:21:37 +0100 (CET)
Received: from delta.homenet.telecomitalia.it
 (host-87-20-204-41.retail.telecomitalia.it [87.20.204.41])
 by support.bugseng.com (Postfix) with ESMTPSA id 52E314EE0738;
 Thu,  9 Jan 2025 11:21:32 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 821c174f-ce73-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1736418096; bh=ZzTypflkqDi+3QAuJnRK3p/CkVQ1Vt55alRN2zi1QhI=;
	h=From:To:Cc:Subject:Date:From;
	b=i0P+BsIsnH3otBjj6iLCGC0ZW22C8IglQU2+ftVzuBODo4OYihv4xzKuFiQoi1OJO
	 beCi4qTOvtg89LDpoVpxjBsGXWYME7hXW9IIlBZQX5BnXh/URNLro81G9bGhakhhe3
	 VeQmUQqY5GJFuQTCeVFI8FSEKPKoqToN8bwmRdqiTZM/tAZ19235PSdYwg7cqXT6CC
	 0XW/m7dQyFSR+0mP3iDQAJTy6o0yCh+KLYlsDNK3JqTW0Nzg7QHPoQ5Q891VqdwdOz
	 eXkZdNB7BASM5nBud5byf/jWgLd10Z1TulR3FDvt4JkbrDdQrSEIF0o7MyeWC9jF02
	 hLHEdW4jypmGw==
From: Alessandro Zucchelli <alessandro.zucchelli@bugseng.com>
To: xen-devel@lists.xenproject.org
Cc: consulting@bugseng.com,
	Alessandro Zucchelli <alessandro.zucchelli@bugseng.com>,
	Simone Ballarin <simone.ballarin@bugseng.com>,
	Doug Goldstein <cardoe@cardoe.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PATCH v4] misra: add deviation for MISRA C Rule R11.8.
Date: Thu,  9 Jan 2025 11:21:21 +0100
Message-ID: <5b8b143207a5dc0478a500cf2d41017bdb982019.1736417750.git.alessandro.zucchelli@bugseng.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Rule 11.8 states as following: "A cast shall not remove any `const' or
`volatile' qualification from the type pointed to by a pointer".

Function `__hvm_copy' in `xen/arch/x86/hvm/hvm.c' is a double-use
function, where the parameter needs to not be const because it can be
set for write or not. As it was decided a new const-only function will
lead to more developer confusion than it's worth, this violation is
addressed by deviating the function.
All cases of casting away const-ness are accompanied with a comment
explaining why it is safe given the other flags passed in; such comment is used
by the deviation in order to match the appropriate function call.

No functional change.

Signed-off-by: Alessandro Zucchelli <alessandro.zucchelli@bugseng.com>
---
Changes from V3:
Edit docs/misra/deviations.rst, according to the feedback received.
Rebase against the current staging tree.

Changes from V2:
The deviation has been documented under docs/misra/deviations.rst.

Changes from V1:
The deviation has been refined to specify that every instance of casting away
const-ness is accompanied by a comment explaining why it is safe.
This comment is a requirement that has been incorporated into the text defining
the deviation.
---
 automation/eclair_analysis/ECLAIR/deviations.ecl | 6 ++++++
 docs/misra/deviations.rst                        | 9 +++++++++
 2 files changed, 15 insertions(+)

diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
index ae25eeb76a..a28eb0ae76 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -393,6 +393,12 @@ Fixing this violation would require to increase code complexity and lower readab
 -config=MC3A2.R11.8,reports+={safe,"any_area(any_loc(any_exp(macro(^container_of$))))"}
 -doc_end
 
+-doc_begin="Function __hvm_copy in xen/arch/x86/hvm/hvm.c is a double-use
+function, where the parameter needs to not be const because it can be set for
+write or not"
+-config=MC3A2.R11.8,reports+={safe,"any_area(any_loc(text(^.*__hvm_copy.*HVMCOPY_to_guest doesn't modify.*$)))"}
+-doc_end
+
 -doc_begin="This construct is used to check if the type is scalar, and for this purpose the use of 0 as a null pointer constant is deliberate."
 -config=MC3A2.R11.9,reports+={deliberate, "any_area(any_loc(any_exp(macro(^__ACCESS_ONCE$))))"
 }
diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
index 15a993d050..fe0b1e10a2 100644
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -353,6 +353,15 @@ Deviations related to MISRA C:2012 Rules:
        Fixing this violation would require to increase code complexity and lower readability.
      - Tagged as `safe` for ECLAIR.
 
+   * - R11.8
+     - Violations caused by function __hvm_copy occur when a const void
+       argument is passed, as the const qualifier is stripped. However, in such
+       cases, the function ensures that it does not modify the buffer
+       referenced by the argument, therefore, this use is deemed safe. Fixing
+       this violation would require to increase code complexity and lower
+       readability.
+     - Tagged as `safe` for ECLAIR.
+
    * - R11.9
      - __ACCESS_ONCE uses an integer, which happens to be zero, as a
        compile time check. The typecheck uses a cast. The usage of zero or other
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 10:25:56 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 10:25:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868049.1279587 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVpjf-0004IO-41; Thu, 09 Jan 2025 10:25:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868049.1279587; Thu, 09 Jan 2025 10:25:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVpjf-0004IH-1J; Thu, 09 Jan 2025 10:25:55 +0000
Received: by outflank-mailman (input) for mailman id 868049;
 Thu, 09 Jan 2025 10:25: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
 <SRS0=bl7y=UB=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tVpje-0004IB-Ed
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 10:25:54 +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 1a5759bf-ce74-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 11:25:52 +0100 (CET)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-385e1fcb0e1so379657f8f.2
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 02:25:52 -0800 (PST)
Received: from localhost ([66.81.170.107]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a8e4b80besm1386027f8f.83.2025.01.09.02.25.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 02:25:51 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1a5759bf-ce74-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736418352; x=1737023152; darn=lists.xenproject.org;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=PYo5T+Q4kQBd85lnsYKAOIxFRBNCd1XVXpqut8F4Kzo=;
        b=b5RkbACwqePuGql7hkLwRzfaVrXytZrqbpxLRrSGkSQDyvCDzEahYSSP/54wXrKUIK
         rtozYiC2/gRlyN4g+Uj7omLOuvBnklTr5ZB5JtRtQQf6wrBYf/V9oj1HCZRU75aP0WFL
         NjMplnenl/xofP8YPEN/IP7agrIEP6rO22bUw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736418352; x=1737023152;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=PYo5T+Q4kQBd85lnsYKAOIxFRBNCd1XVXpqut8F4Kzo=;
        b=H7zBjnyMJx/euMoVjZikAD1/nfbPQAZmJHvNqjOc6O7GbGScDAKIfsl2v8e6PSGoJi
         HhC9wOlCRU0qZiXCemh3B4ZtbrXS0CczMk8r2fZbyi7xcSxMUyeWsQMSN/RATl10Lnid
         PdXMtDlVFfMNW/ennxdTqScbdu0GRUQ4NTBOZEVxKC7Yc9NyzmWL6bJkspghoflYi38f
         KPdMjKAbH4IkXRr9ST/DBRCOsyCSiuCpoo6g6pH+tVZ7pmsraWyzdbDQ/x2ZCloERX3z
         nPs91xd61BLxBRzJCYolEpaRJSrjiz9cQFuxD2a1oPnTUNgdkn4OkOy6ggZL0qRedjzN
         XmWQ==
X-Forwarded-Encrypted: i=1; AJvYcCWCjKoe2PukZparjUK4otGq2QAj7WS3BYulaxvjhj8EuzdH4uCUk2Zc/M+1NNgf23PGRqzFVPjkPsA=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxrep4TiJ20bsamsOwedelkVqbO3FFQXnguJvFN8SvAZk+977sg
	kHgd2PEGBci1tgcrwWV7mIVS5bc6WtHUbeBU1mH3QmDosZEn74mgnfwrcvQO830=
X-Gm-Gg: ASbGncv/4k0Gy7GmzdGO2onLd/DR3JIjbcTki1c/OCetUOPX6drvwIoNQYOOsPHzLsU
	X/Ef6QgoO5RvkNmO8GSfXmsfmfJluAe395LAL1xwryTrzdTghmia3tvvMGrTiD54VoLwRqL1iJm
	LeboI8XDBK6EZGwKCJCnABrowwOLguMcsHZuyydSJoXkPJyWv+3/RZ7oExAK33jmU+9eHvwZfrE
	IiQf7yIpvKrgjI1xAnGsRpSF3rkfeifHsxmAOsS6YohqOf8rJ/QWioTazEkrm0=
X-Google-Smtp-Source: AGHT+IFmuuToL0paDrsRLJdELl1n1nqR2X7wjKagqJB23KWV3chRtURthDswqM5owEUGILgBW1BjBg==
X-Received: by 2002:a05:6000:1848:b0:38a:8b2c:53ab with SMTP id ffacd0b85a97d-38a8b2c563emr2150646f8f.44.1736418351971;
        Thu, 09 Jan 2025 02:25:51 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Thu, 09 Jan 2025 10:25:50 +0000
Message-Id: <D6XGXLZ2SKUR.3CW1GPXWK3LFC@cloud.com>
Cc: "Jan Beulich" <jbeulich@suse.com>, "Andrew Cooper"
 <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v2.1 06/18] x86/pv: set/clear guest GDT mappings using
 {populate,destroy}_perdomain_mapping()
From: "Alejandro Vallejo" <alejandro.vallejo@cloud.com>
To: "Roger Pau Monne" <roger.pau@citrix.com>,
 <xen-devel@lists.xenproject.org>
X-Mailer: aerc 0.18.2
References: <20250108142659.99490-7-roger.pau@citrix.com>
 <20250108151133.858-1-roger.pau@citrix.com>
In-Reply-To: <20250108151133.858-1-roger.pau@citrix.com>

On Wed Jan 8, 2025 at 3:11 PM GMT, Roger Pau Monne wrote:
> The pv_{set,destroy}_gdt() functions rely on the L1 table(s) that contain=
 such
> mappings being stashed in the domain structure, and thus such mappings be=
ing
> modified by merely updating the L1 entries.
>
> Switch both pv_{set,destroy}_gdt() to instead use
> {populate,destory}_perdomain_mapping().

nit: s/destory/destroy

How come pv_set_gdt() doesn't need to be reordered here (as opposed to v2)?

>
> Signed-off-by: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
> ---
> Changes since v2:
>  - Do not change ordering setup of arch_set_info_guest().
> ---
>  xen/arch/x86/pv/descriptor-tables.c | 28 ++++++++++++----------------
>  1 file changed, 12 insertions(+), 16 deletions(-)
>
> diff --git a/xen/arch/x86/pv/descriptor-tables.c b/xen/arch/x86/pv/descri=
ptor-tables.c
> index 02647a2c5047..5a79f022ce13 100644
> --- a/xen/arch/x86/pv/descriptor-tables.c
> +++ b/xen/arch/x86/pv/descriptor-tables.c
> @@ -49,23 +49,20 @@ bool pv_destroy_ldt(struct vcpu *v)
> =20
>  void pv_destroy_gdt(struct vcpu *v)
>  {
> -    l1_pgentry_t *pl1e =3D pv_gdt_ptes(v);
> -    mfn_t zero_mfn =3D _mfn(virt_to_mfn(zero_page));
> -    l1_pgentry_t zero_l1e =3D l1e_from_mfn(zero_mfn, __PAGE_HYPERVISOR_R=
O);
>      unsigned int i;
> =20
>      ASSERT(v =3D=3D current || !vcpu_cpu_dirty(v));
> =20
> -    v->arch.pv.gdt_ents =3D 0;
> -    for ( i =3D 0; i < FIRST_RESERVED_GDT_PAGE; i++ )
> -    {
> -        mfn_t mfn =3D l1e_get_mfn(pl1e[i]);
> +    if ( v->arch.cr3 )
> +        destroy_perdomain_mapping(v, GDT_VIRT_START(v),
> +                                  ARRAY_SIZE(v->arch.pv.gdt_frames));
> =20
> -        if ( (l1e_get_flags(pl1e[i]) & _PAGE_PRESENT) &&
> -             !mfn_eq(mfn, zero_mfn) )
> -            put_page_and_type(mfn_to_page(mfn));
> +    for ( i =3D 0; i < ARRAY_SIZE(v->arch.pv.gdt_frames); i++)
> +    {
> +        if ( !v->arch.pv.gdt_frames[i] )
> +            break;
> =20
> -        l1e_write(&pl1e[i], zero_l1e);
> +        put_page_and_type(mfn_to_page(_mfn(v->arch.pv.gdt_frames[i])));
>          v->arch.pv.gdt_frames[i] =3D 0;
>      }
>  }
> @@ -74,8 +71,8 @@ int pv_set_gdt(struct vcpu *v, const unsigned long fram=
es[],
>                 unsigned int entries)
>  {
>      struct domain *d =3D v->domain;
> -    l1_pgentry_t *pl1e;
>      unsigned int i, nr_frames =3D DIV_ROUND_UP(entries, 512);
> +    mfn_t mfns[ARRAY_SIZE(v->arch.pv.gdt_frames)];
> =20
>      ASSERT(v =3D=3D current || !vcpu_cpu_dirty(v));
> =20
> @@ -90,6 +87,8 @@ int pv_set_gdt(struct vcpu *v, const unsigned long fram=
es[],
>          if ( !mfn_valid(mfn) ||
>               !get_page_and_type(mfn_to_page(mfn), d, PGT_seg_desc_page) =
)
>              goto fail;
> +
> +        mfns[i] =3D mfn;
>      }
> =20
>      /* Tear down the old GDT. */
> @@ -97,12 +96,9 @@ int pv_set_gdt(struct vcpu *v, const unsigned long fra=
mes[],
> =20
>      /* Install the new GDT. */
>      v->arch.pv.gdt_ents =3D entries;
> -    pl1e =3D pv_gdt_ptes(v);
>      for ( i =3D 0; i < nr_frames; i++ )
> -    {
>          v->arch.pv.gdt_frames[i] =3D frames[i];
> -        l1e_write(&pl1e[i], l1e_from_pfn(frames[i], __PAGE_HYPERVISOR_RW=
));
> -    }
> +    populate_perdomain_mapping(v, GDT_VIRT_START(v), mfns, nr_frames);
> =20
>      return 0;
> =20

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 10:27:53 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 10:27:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868057.1279597 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVplU-0004pe-Ef; Thu, 09 Jan 2025 10:27:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868057.1279597; Thu, 09 Jan 2025 10:27:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVplU-0004pX-B0; Thu, 09 Jan 2025 10:27:48 +0000
Received: by outflank-mailman (input) for mailman id 868057;
 Thu, 09 Jan 2025 10:27: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
 <SRS0=FDwX=UB=arm.com=Luca.Fancellu@srs-se1.protection.inumbo.net>)
 id 1tVplT-0004pP-2i
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 10:27:47 +0000
Received: from EUR02-AM0-obe.outbound.protection.outlook.com
 (mail-am0eur02on20606.outbound.protection.outlook.com
 [2a01:111:f403:2606::606])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5da93856-ce74-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 11:27:45 +0100 (CET)
Received: from DBAPR08MB5798.eurprd08.prod.outlook.com (2603:10a6:10:1a6::21)
 by DB9PR08MB6538.eurprd08.prod.outlook.com (2603:10a6:10:23d::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8335.12; Thu, 9 Jan
 2025 10:27:43 +0000
Received: from DBAPR08MB5798.eurprd08.prod.outlook.com
 ([fe80::4a66:d3e2:570:9632]) by DBAPR08MB5798.eurprd08.prod.outlook.com
 ([fe80::4a66:d3e2:570:9632%4]) with mapi id 15.20.8335.010; Thu, 9 Jan 2025
 10:27:43 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5da93856-ce74-11ef-a0df-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=hcZdPjvvFSeVDjVsjZ7z/VKpehH4SYCQI+qRhp/suM0osbGJoHGCAl7E8qsIPkixh+QHTj4VaG+I4WbLYkLGrVuG63CZW4NpKJfvhn/4IDVUdoG1pUw+h8xEekhgnJWH/+Kty8RYv3NAV9IIFUvneSH6D/DXpnb8QMmaKtZFTTERRsJvxvi7qpset5A8DUlDzMb3QcFlk3vYTQ3GPS7oh2gHa6g7dZr/DD442HTXhz0U5Tm+mlwJGOn2mJG7oBKcIeiZErsedaVs0njk2c4jBnzgBkiZ8Wi6HxXG4nIcSpGHIyxShg+wm2GJefCFB4i3mhuHPITIsmh07Wp0AbFsiw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=spWB7WZJ3mOOCrxR61K99E1n6pyz4HLiqX8OAGxzrsk=;
 b=PHFpLF/Uo9w27ERHwj+ooeZZS70YfyCLAhtcgHZA2ONDqojMKyPJsxx5/iUOEuQty7oIBD1Z6dlMoSFbAhmzdWzXPSrX+vrXgMso/J0MkY5G0DWS9vrMwI8ZFh9dEq9DnTlBy8mG5IVVkdKMtBMidUpTagWyZU9QRmuCYoHf0Q0zXAQx3cxEsqmftTxwvfhKOAM+AGC52zBm8U1aniV4+rxPZV/vyMDF2EjtK+2QaBGqzg6telDuIAQ7K1ROStD7ETVC8DAwj9bTfZAnIwxMA65i7bOXfhutQSlbw5M//w87LgCV0ADssOdefhWzRyEIrzWARtrJG/mOk9GXiSrIrQ==
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=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=spWB7WZJ3mOOCrxR61K99E1n6pyz4HLiqX8OAGxzrsk=;
 b=f1gzy8zkz7SXxJU3b+N41oh69hlEzYXzYXZyenzCVJ6FxmiQBoQTge0wD+oUUH3O1kI88qvkihjQUU0XUoP8idcbB6uhSUcG74/ZX+IZCUVJtwgy/lrI2pK8OP7hBudvLk0oehdZb8BxKQC6EN7K0q+L0wGuwmWMZA68qcy6CkI=
From: Luca Fancellu <Luca.Fancellu@arm.com>
To: Michal Orzel <michal.orzel@amd.com>
CC: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Stefano
 Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand
 Marquis <Bertrand.Marquis@arm.com>, Volodymyr Babchuk
	<Volodymyr_Babchuk@epam.com>, Oleksii Kurochko <oleksii.kurochko@gmail.com>
Subject: Re: [PATCH v2] xen/arm: Fully initialise struct membanks_hdr fields
Thread-Topic: [PATCH v2] xen/arm: Fully initialise struct membanks_hdr fields
Thread-Index: AQHbYnjhSKvjiFv/ZkKm32Sq0WkbbrMONdAAgAACYACAAAFJAIAAA8eA
Date: Thu, 9 Jan 2025 10:27:43 +0000
Message-ID: <3F4D5A7A-0999-417C-91E6-3EE2ECD4759A@arm.com>
References: <20250109092816.1619834-1-luca.fancellu@arm.com>
 <e9477b85-1c9a-4aa6-b7fe-90286fcd461b@amd.com>
 <7D68D11E-E4EF-4521-9017-112DAA2B9B11@arm.com>
 <822cde40-a4a2-4d25-90e1-5421caa7b334@amd.com>
In-Reply-To: <822cde40-a4a2-4d25-90e1-5421caa7b334@amd.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.200.121)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DBAPR08MB5798:EE_|DB9PR08MB6538:EE_
x-ms-office365-filtering-correlation-id: ad30341e-5d6b-42c0-1e20-08dd309840e0
x-checkrecipientrouted: true
nodisclaimer: true
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?b2ttVWVsWW1iMkZ1TWZJQVZ6RUtkRk8vS01TbXh4NWxFaFBJLyt2ODRkdFh1?=
 =?utf-8?B?T3VDcWVSTUZMaTcwZ2lOS0hGUDdvTllMa2h3VkVzd1JsMmV2cWFLa2NUZVA3?=
 =?utf-8?B?V1Zvcm9IRFdPSDBwellXRWNNODFvMFkrdkVvM2IrSHU2UVJMUjc3NjBhb0Jp?=
 =?utf-8?B?cmVva01PaXNhcWZsNkFRK3crRldBYVZPTEphazRZMlRzYkRtYTZzZUxuOG81?=
 =?utf-8?B?RUdhNDRsWTZ3NU51OVMzS21vRVozU3doLzhVazdOZUV1ci9ma21JQ29qMlJI?=
 =?utf-8?B?UTZwM0lBenpiU2NldUU5WUtwZ0p4RlZ5SndJTCsyd2MvbXNLaVluMURMM1Aw?=
 =?utf-8?B?d0xPYVM3WUc3c2JraWo3OGFKd1hPRVVPV1k4Z2tWSVl2c2k5cVF2ejViYjRG?=
 =?utf-8?B?anRPaXFwSGhHUS9yc2V3THBKNTNXbmRkRnVweTQ2VS9KTXRQSUlJamt5dlU2?=
 =?utf-8?B?bVB4ME9vbmpMeDZzYWNxbUR0VW14OFIreENrbG1oNnhDb0UvT0Z6dWdxREcy?=
 =?utf-8?B?NzBzSnZtYm8xS1BkZjNHQjdkanF4eDdyK0N2RXhCZkpiaE5VdWk4U1hZNGtj?=
 =?utf-8?B?dWs1aDF2M1QxRmdmWVlMdCtxVUJvc3pVKy9uWmJNdzhnK2N0ZXZteFRWMGZs?=
 =?utf-8?B?WVdpMzI0RjBndTNCWm1YNEdXMGdBcWFMTm9hRzdVSFVTQTMvdUFQWmpFZk01?=
 =?utf-8?B?U2hkMU9ZK2NYa21mdzIwaENNajgyNUN6Q0JsMVhidlkzdldUOFRzemkwcmJ1?=
 =?utf-8?B?Z01PRzkyUU1tTVljN2drVzF5ZUVsOEdraXRhOHJaZUJSbElVWk44QVJjWHk5?=
 =?utf-8?B?L0JhdFoyc0ppQnJGcHUydWgrWG5NSkY3QUU5c2Y0SXBKNHFBazFXTGJOOGFX?=
 =?utf-8?B?OXkzaXd6Rzl2Q3NpWCtyQTFQcmtDMnFYbGtuMGdYOWVXYkxzL0Y2ajBzdU8z?=
 =?utf-8?B?SS9JWVBlbGVSQjRlZXBreXpvOUxOdEdub0NHTDhNQzExWDJ0VVMzWVgzdEQ5?=
 =?utf-8?B?MXVjOGhHc3B0WlppbnJtM2JHOU9jKzUrTE9KeGJ1OHdDOTNsVkNZeUpwK08x?=
 =?utf-8?B?OTYyOWc3NnlMSExQSkwwZW1nL2w1TmJwSWlhVm4yVEdCa21ubnVLZWdUMUc0?=
 =?utf-8?B?Z1dmSE9ZZWd5Uk5NTXlSR3pWNkdSY1l6cWx1Ty9ocDgzbmNPZzIyZE9US3Nh?=
 =?utf-8?B?OFZPREpBMWZkQm15RG1CZnFkeXIrWXAyMmdhOWhzd0d1aTZFTTlLOWZLNlhD?=
 =?utf-8?B?cGx0R2VOcmFrNFNOVnMyTktld0p0dVNQT2FORUJ0aFBxWEhpZ203RjI0QXdN?=
 =?utf-8?B?Z0NhdkwrMFkvT1lWKzA1UjFkMllGOG1ZajNFZmlHRm9lczRncGtUZlVndUQz?=
 =?utf-8?B?RTN5RmxvNzczNE5heE54R0wzQzJMbDczZTR6QmxWaGUxaVJWeGNmcG5hUTZs?=
 =?utf-8?B?RXNITnBmM0RDSTJFZmZyZERQeFgzS0VWRVoxWEJXUmZISUFLSERIcFZYazRR?=
 =?utf-8?B?Z1RLSjRtSFJPQTRPL3I4ZW9raW1jaUdjNlk5VEpMMks4YXI2RU1zVGI5WWVw?=
 =?utf-8?B?YWw2WGZLcUhhbmFlUGtqU1NHclBmd1ZtbzNOZURaN21CZDJvUkkvcHdrSGM4?=
 =?utf-8?B?RzRjdis1Yjd1YnFFWk5aU3hrOWdSSllxaHkrc2RBQTZjRE9YbjBoYTg2RWVV?=
 =?utf-8?B?Y25aeFRCWXdvdkw5WnNSdFRKNHcwRnUvMlBzcUZpUW0zeVQwZm05NnpQaDJs?=
 =?utf-8?B?eXc2Wnk1WUFJSGpXS0FwVWlLQU5Yb0tETTExR0MzN0hDd1RISjErTHFSMjdK?=
 =?utf-8?B?eHFzdyszb3l1VWg1Qm5IQTZYRVhFRWxQdFNHL0VsejRsMnFTUlVDM1ovTXBT?=
 =?utf-8?B?c2FqelRyS2ozSWhTSDhkZ1RMM0wzMjNBeUtOQ3l5V0lqb0Z1ZGw1OFAwVjA2?=
 =?utf-8?Q?L/oSaEO3GuAzFx1tFhgo4jpLsuXcpF3s?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DBAPR08MB5798.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?RWNFQ1ZqeFRvTHhnaWR1cit3R1kzT01EWHdwN3BwNXFudlZZQ0dSRHNsbWhh?=
 =?utf-8?B?M0kyQjlVWDNCaHlLSEo1OUxsUDF2RERwOWhudGZvU25ISkVCa0lqekEwdGp6?=
 =?utf-8?B?UHRrNHJBb2NaV09ZN1hPZGlJNmJJaVAvenNtR3dOZFQxSVZRUnJ5Q2lYYkpN?=
 =?utf-8?B?KzFzOTl6VDhxZzFYeHFFNy8yalRSOS8wMXpoaWY5OFVrSGRPL1FmSWcwanBi?=
 =?utf-8?B?eFpuaGxta2ttSzIvSjBOQUJpOUVzbUxib0Y3VDNyTGRiY2xpQll6R3dZOFBW?=
 =?utf-8?B?OFFrNlIxNForK0FHNnJKWWQrT3FYcWNITjA5bzBvdGNjU2h1eU5Db1FtVHpD?=
 =?utf-8?B?aUZQdGlSZUxjL3l3V0R0VmJQMEEraWxmdmdQYU5KSGlMRG1HanMxYmxLR1lC?=
 =?utf-8?B?TmpRcFlsTlRZUTBtSnpzeTk0UzdFZzBkVXV5NTlPUGJsZ2VsM1R4dlQvcTRQ?=
 =?utf-8?B?a1dmcGxWV0tWZE1rT296TEkvNTFDcjEwL254V3ZLVGpSM1VzSXNZRGVreC82?=
 =?utf-8?B?RDA3WmtwdlRxdW5ha0tyZTA1cWpmYlF4aU1LY2lBM0ZhNzQ0ZkVvWGhTTU1n?=
 =?utf-8?B?VDVZUDYyQ1hNQTY0bmJaSG1Dd1ZuSUNTbUJ3ZnA3NGNOYm8rdWZBZTMwL2Yz?=
 =?utf-8?B?VVlZZGd1VW1yYzNPZnM4NlhaREt3NGNObGJOSEtzN0dGWlROSVVkcHA3eWZl?=
 =?utf-8?B?QVpWeThpNERZMGt5NTRVWXVCcnVvWHN2d2NENmNLZVo2ODlHRnZKRDZxVmIr?=
 =?utf-8?B?S0ZBdnhCYkRjbWZHc014M3JCMW1tcnRaYWJHNmI0VXFRWGVVQWxTNHFJMCsx?=
 =?utf-8?B?YWZIcGZvZWhqYUxYUU5aOFFWT0xMT2hTemNXVUV4VzI0L3F4V1VQb1p5cmFt?=
 =?utf-8?B?NDg2NjkyamZKd1kvYnlhUUtKWVlnd1N5SmhPMFlKd2p1dC9wQ1pIbWVnZzNU?=
 =?utf-8?B?SVlxTnllOG4wNG0yZmFBNFRwOEMxcWFoL20rcXdnODNaRTFXUW9tOFdqNkdq?=
 =?utf-8?B?dDVOUVBsNnBjTGUxdTl5dkc1dFZVVjFRMnFGQ2NwOFhFN3JVaThpM1ZMYmw5?=
 =?utf-8?B?TEpud0drdyt0OVREQjIvUUZGUjU2MkJoTTJBKzBQU2VPY1A3NG5CTThBVGRC?=
 =?utf-8?B?NVZDYTdqVWFXVjJkc25FWXdmZFpSQnFvdkpLUnVPdjU2WkZmbGltdjRnRit1?=
 =?utf-8?B?T3duMlJ3VXpDSjUzRTRZMXI2RHdEd2VGeVN4MDltWEtURFJaeTRodDFWMnUy?=
 =?utf-8?B?S3NWY0k4Skg3YXV4R1cwN3pPL0NOSGZMTW1BSzY3c3hmdnc4WVc3T2V6cUdy?=
 =?utf-8?B?VXVqbXkxRVRTb3ZZUFloRmpQQnd2M2taQ0RzbHN4OVI2cEY4ZGNvUkI5K3Qr?=
 =?utf-8?B?RXFaSkFsVjJLcFpDWjJnVkIzeUNwdDJXWCs2NmVvR29yclVFUEduSzV2K1V2?=
 =?utf-8?B?YjhnL1lmYmM4NG9vWUVrQUtVUkd3WHlING0wdnVRNWVnblFzaW0vVlNlRUxa?=
 =?utf-8?B?K0orckZ1bHdBb0FENDBhc2NDdHVwTkFUSUpvRDR2Q21sYW14Q0xaVzZxQXhp?=
 =?utf-8?B?TWNRa0J6YU11VXJ3MDRvem13aU02U0hSWG1jczNtVnNEVVc5ZEcvemEycFM4?=
 =?utf-8?B?b29Ib01ld3czazg1YzhuRGo0Uk54aVhCUThSdThtWjBOR3JrR1MwbndYNWVV?=
 =?utf-8?B?MVNrajM4MzNXRGFWZ1hZbk8zRXNyeFJvVklSajNYWWtNcU9wT1U4NGphRXdp?=
 =?utf-8?B?SWx3RHJDK3pmR1NaVTE4ZDVaVXgxU0Y4L0h6VzVHUHB1MmJvWkJkTHBDa1Za?=
 =?utf-8?B?aGJFamJUUHd5ZGZLYThON1pZU2NldDFLN0dTdXhUYXJpQXpEQ3lZSHdITEVO?=
 =?utf-8?B?akQ4b0FlYlQvSmtPaTg4aldtMXNrSlJlc08vS29heG9SRGE5a2VUN0hKUlBG?=
 =?utf-8?B?bXYwZ0prRG93aUM4RFpEdDF4b3dtcHp0REZPelpHaDNrellTSjNaUXZFc1V6?=
 =?utf-8?B?VEtHWFdpTG5lalJ1bkxkVGw1L1BCSEF4MGwvWnF1ZXRiMFFMc1N2bHJ0M1FS?=
 =?utf-8?B?UENSWnhOU2hXRndGbkZqUG1VU29USE1MZUFZdDlmS2ZVSFo1NVFDSDNqdC9i?=
 =?utf-8?B?RDJwOWQ5dFlCR2RkS1N5cjQwWlE5VjM1Y2RrMUp4YlVKbDZYM0sxZjJrOTBU?=
 =?utf-8?B?U1E9PQ==?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <13CA0D2E8C0A3C4583AFA15E46F009B0@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DBAPR08MB5798.eurprd08.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ad30341e-5d6b-42c0-1e20-08dd309840e0
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2025 10:27:43.7518
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: qM9xOV2SP1UfwXnoLUCfKqiOPI3gsuSEYkPPgYbSS6EwrQYSNoyDfUIyWLjMvLfdugfqyKjNxsn/8VhuhTiFWw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR08MB6538

Pj4gDQo+Pj4gDQo+Pj4+IC0tLQ0KPj4+PiAtLS0NCj4+Pj4geGVuL2FyY2gvYXJtL2RvbWFpbl9i
dWlsZC5jICAgICAgIHwgMTMgKysrKy0tLS0tLS0tLQ0KPj4+PiB4ZW4vYXJjaC9hcm0vaW5jbHVk
ZS9hc20va2VybmVsLmggfCAgNSArKysrLQ0KPj4+PiB4ZW4vYXJjaC9hcm0vc3RhdGljLXNobWVt
LmMgICAgICAgfCAgMyArKy0NCj4+Pj4geGVuL2luY2x1ZGUveGVuL2Jvb3RmZHQuaCAgICAgICAg
IHwgMTYgKysrKysrKysrKysrKysrKw0KPj4+PiA0IGZpbGVzIGNoYW5nZWQsIDI2IGluc2VydGlv
bnMoKyksIDExIGRlbGV0aW9ucygtKQ0KPj4+PiANCj4+Pj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNo
L2FybS9kb21haW5fYnVpbGQuYyBiL3hlbi9hcmNoL2FybS9kb21haW5fYnVpbGQuYw0KPj4+PiBp
bmRleCBiMDcyYTE2MjQ5ZmUuLjllMzEzMmZiMjFkOCAxMDA2NDQNCj4+Pj4gLS0tIGEveGVuL2Fy
Y2gvYXJtL2RvbWFpbl9idWlsZC5jDQo+Pj4+ICsrKyBiL3hlbi9hcmNoL2FybS9kb21haW5fYnVp
bGQuYw0KPj4+PiBAQCAtMTAzOSw3ICsxMDM5LDcgQEAgdm9pZCBfX2luaXQgYWxsb2NhdGVfbWVt
b3J5KHN0cnVjdCBkb21haW4gKmQsIHN0cnVjdCBrZXJuZWxfaW5mbyAqa2luZm8pDQo+Pj4+ICAg
ICAqLw0KPj4+PiAgICBpZiAoIGlzX2hhcmR3YXJlX2RvbWFpbihkKSApDQo+Pj4+ICAgIHsNCj4+
Pj4gLSAgICAgICAgc3RydWN0IG1lbWJhbmtzICpnbnR0YWIgPSB4emFsbG9jX2ZsZXhfc3RydWN0
KHN0cnVjdCBtZW1iYW5rcywgYmFuaywgMSk7DQo+Pj4+ICsgICAgICAgIHN0cnVjdCBtZW1iYW5r
cyAqZ250dGFiID0gbWVtYmFua3NfeHphbGxvYygxLCBSRVNFUlZFRF9NRU1PUlkpOw0KPj4+PiAg
ICAgICAgLyoNCj4+Pj4gICAgICAgICAqIEV4Y2x1ZGUgdGhlIGZvbGxvd2luZyByZWdpb25zOg0K
Pj4+PiAgICAgICAgICogMSkgUmVtb3ZlIHJlc2VydmVkIG1lbW9yeQ0KPj4+PiBAQCAtMTA1Nywx
MyArMTA1NywxMCBAQCB2b2lkIF9faW5pdCBhbGxvY2F0ZV9tZW1vcnkoc3RydWN0IGRvbWFpbiAq
ZCwgc3RydWN0IGtlcm5lbF9pbmZvICpraW5mbykNCj4+Pj4gICAgICAgIGdudHRhYi0+YmFua1sw
XS5zdGFydCA9IGtpbmZvLT5nbnR0YWJfc3RhcnQ7DQo+Pj4+ICAgICAgICBnbnR0YWItPmJhbmtb
MF0uc2l6ZSA9IGtpbmZvLT5nbnR0YWJfc2l6ZTsNCj4+Pj4gDQo+Pj4+IC0gICAgICAgIGh3ZG9t
X2ZyZWVfbWVtID0geHphbGxvY19mbGV4X3N0cnVjdChzdHJ1Y3QgbWVtYmFua3MsIGJhbmssDQo+
Pj4+IC0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOUl9NRU1f
QkFOS1MpOw0KPj4+PiArICAgICAgICBod2RvbV9mcmVlX21lbSA9IG1lbWJhbmtzX3h6YWxsb2Mo
TlJfTUVNX0JBTktTLCBNRU1PUlkpOw0KPj4+PiAgICAgICAgaWYgKCAhaHdkb21fZnJlZV9tZW0g
KQ0KPj4+PiAgICAgICAgICAgIGdvdG8gZmFpbDsNCj4+Pj4gDQo+Pj4+IC0gICAgICAgIGh3ZG9t
X2ZyZWVfbWVtLT5tYXhfYmFua3MgPSBOUl9NRU1fQkFOS1M7DQo+Pj4+IC0NCj4+Pj4gICAgICAg
IGlmICggZmluZF91bmFsbG9jYXRlZF9tZW1vcnkoa2luZm8sIG1lbV9iYW5rcywgQVJSQVlfU0la
RShtZW1fYmFua3MpLA0KPj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBo
d2RvbV9mcmVlX21lbSwgYWRkX2h3ZG9tX2ZyZWVfcmVnaW9ucykgKQ0KPj4+PiAgICAgICAgICAg
IGdvdG8gZmFpbDsNCj4+Pj4gQEAgLTEyOTMsNyArMTI5MCw3IEBAIHN0YXRpYyBpbnQgX19pbml0
IGZpbmRfaG9zdF9leHRlbmRlZF9yZWdpb25zKGNvbnN0IHN0cnVjdCBrZXJuZWxfaW5mbyAqa2lu
Zm8sDQo+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3Ry
dWN0IG1lbWJhbmtzICpleHRfcmVnaW9ucykNCj4+Pj4gew0KPj4+PiAgICBpbnQgcmVzOw0KPj4+
PiAtICAgIHN0cnVjdCBtZW1iYW5rcyAqZ250dGFiID0geHphbGxvY19mbGV4X3N0cnVjdChzdHJ1
Y3QgbWVtYmFua3MsIGJhbmssIDEpOw0KPj4+PiArICAgIHN0cnVjdCBtZW1iYW5rcyAqZ250dGFi
ID0gbWVtYmFua3NfeHphbGxvYygxLCBSRVNFUlZFRF9NRU1PUlkpOw0KPj4+PiANCj4+Pj4gICAg
LyoNCj4+Pj4gICAgICogRXhjbHVkZSB0aGUgZm9sbG93aW5nIHJlZ2lvbnM6DQo+Pj4+IEBAIC0x
Mzc0LDEyICsxMzcxLDEwIEBAIGludCBfX2luaXQgbWFrZV9oeXBlcnZpc29yX25vZGUoc3RydWN0
IGRvbWFpbiAqZCwNCj4+Pj4gICAgfQ0KPj4+PiAgICBlbHNlDQo+Pj4+ICAgIHsNCj4+Pj4gLSAg
ICAgICAgZXh0X3JlZ2lvbnMgPSB4emFsbG9jX2ZsZXhfc3RydWN0KHN0cnVjdCBtZW1iYW5rcywg
YmFuaywgTlJfTUVNX0JBTktTKTsNCj4+Pj4gKyAgICAgICAgZXh0X3JlZ2lvbnMgPSBtZW1iYW5r
c194emFsbG9jKE5SX01FTV9CQU5LUywgUkVTRVJWRURfTUVNT1JZKTsNCj4+PiBJJ20gYSBiaXQg
Y29uZnVzZWQgd2hhdCBpcyB0aGUgZXhwZWN0YXRpb25zIGJlaGluZCB1c2luZyBkaWZmZXJlbnQg
dHlwZXMgb2YgZW51bSByZWdpb25fdHlwZSwgbW9zdGx5IGJlY2F1c2UgaXQgY2FuIHBvaW50IHRv
DQo+Pj4gZGlmZmVyZW50IGFkZHJlc3Mgc3BhY2VzIGRlcGVuZGluZyBvbiB0aGUgY29udGV4dC4g
QWJvdmUsIHlvdSBtYXJrZWQgZ250dGFiIGFzIFJFU0VSVkVEX01FTU9SWSAoSSBndWVzcyBiZWNh
dXNlIHRoaXMNCj4+PiByZWdpb24gaGFzIGFscmVhZHkgYmVlbiBmb3VuZCAtIGJ1dCBpbiBmYWN0
IGl0IGlzIHN0aWxsIHVudXNlZCkgYW5kIGh3ZG9tX2ZyZWVfbWVtIGFzIE1FTU9SWS4gU28gSSB3
b3VsZCBhdCBsZWFzdCBleHBlY3QNCj4+PiBleHRfcmVnaW9ucyB0byBiZSBvZiBNRU1PUlkgdHlw
ZSBhcyB3ZWxsLiBBZnRlciBhbGwgYm90aCBod2RvbV9mcmVlX21lbSBhbmQgZXh0X3JlZ2lvbnMg
Y29udGFpbg0KPj4+IGJhbmtzIG9mIHVudXNlZC9mcmVlIG1lbW9yeSAoYWx0aG91Z2ggZm9ybWVy
IGxpc3RzIGhvc3QgbWVtb3J5IHdoaWxlIGxhdHRlciBjYW4gYWxzbyBjb250YWluIGd1ZXN0IHBo
eXNpY2FsDQo+Pj4gbWVtb3J5KS4gQ291bGQgeW91IHBsZWFzZSBjbGFyaWZ5IHRoZSBpbnRlbmRl
ZCB1c2U/DQo+PiANCj4+IFlvdSBhcmUgcmlnaHQsIHRoYXQgc2hvdWxkIGJlIE1FTU9SWSwgbXkg
YmFkISBDb3VsZCBpdCBiZSBzb21ldGhpbmcgYWRkcmVzc2FibGUgb24gY29tbWl0IG9yIHNob3Vs
ZCBJIHNlbmQgYW5vdGhlciBvbmU/DQo+IEkgY2FuIGRvIHRoYXQgb24gY29tbWl0IGJ1dCBmaXJz
dCwgY2FuIHlvdSBwbGVhc2UgYW5zd2VyIHdoYXQgaXMgdGhlIGludGVuZGVkIHVzZSBvZiBlbnVt
IHJlZ2lvbl90eXBlPw0KPiBBdCBmaXJzdCBJIHdhcyBleHBlY3RpbmcgZ250dGFiIHRvIGJlIE1F
TU9SWSBhcyB3ZWxsLiBJIGRvbid0IHNlZSBhIGRpZmZlcmVuY2UgYmV0d2VlbiBhIHJlZ2lvbiBw
cmVwYXJlZCBieSBYZW4NCj4gZm9yIGRvbWFpbiB0byBzdG9yZSBnbnR0YWIgdnMgZXh0ZW5kZWQg
cmVnaW9ucy4gQm90aCBzcGVjaWZ5IHJlZ2lvbnMgb2YgdW51c2VkIGFkZHJlc3Mgc3BhY2UuIEl0
J3MganVzdCB0aGF0IHRoZSByZWdpb24NCj4gZm9yIGdudHRhYiBtdXN0IGFsd2F5cyBiZSBwcmVz
ZW50IGJ1dCBleHRlbmRlZCByZWdpb25zIGRvbid0IGhhdmUgdG8uDQoNClJpZ2h0LCBhdCBmaXJz
dCBJIHRob3VnaHQgZ250dGFiIGNvdWxkIGJlIHJlc2VydmVkIG1lbW9yeSwgYnV0IG5vdyB0aGF0
IHlvdSBwb2ludGVkIG91dCBpdOKAmXMgbm90IHRoZSByaWdodCB0aGluZyB0byBkbywgSSByZW1l
bWJlcg0Kbm93IHRoYXQgdGhlc2UgdHlwZSByZWZsZWN0cyB0aGUgZGV2aWNlIHRyZWUgZ3JvdXBp
bmcgZm9yIHRoZSBtZW1vcnkgYmFua3MsIHNvIFJFU0VSVkVEX01FTU9SWSBpcyBvbmx5IGZvciB0
aGVzZSByZWdpb25zDQppbiB0aGUgL3Jlc2VydmVkLW1lbW9yeSB0cmVlLCBTVEFUSUNfU0hBUkVE
X01FTU9SWSBpcyBmb3IgdGhlICd4ZW4sZG9tYWluLXNoYXJlZC1tZW1vcnktdjHigJkgY29tYXB0
aWJsZSBub2RlIGFuZA0KTUVNT1JZIGlzIGZvciAvbWVtb3J5IHJlZ2lvbnMuDQoNCk5vdyBJIHdv
dWxkIHNheSB0aGF0IHdlIGNvdWxkIHVzZSBNRU1PUlkgYWxzbyBmb3IgcmVnaW9ucyBwcmVwYXJl
ZCBieSBYZW4gYXMgbG9uZyBhcyB3ZSBkb27igJl0IG5lZWQgdG8gZGlmZmVyZW50aWF0ZSB0aGVt
IGluDQphIGRpZmZlcmVudCB3YXkgZnJvbSAvbWVtb3J5IHJlZ2lvbnMuDQoNClBsZWFzZSBsZXQg
bWUga25vdyB5b3VyIHRob3VnaHRzLg0KDQpDaGVlcnMsDQpMdWNhDQoNCg==


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 10:40:27 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 10:40:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868071.1279607 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVpxc-00082s-DW; Thu, 09 Jan 2025 10:40:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868071.1279607; Thu, 09 Jan 2025 10:40:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVpxc-00082l-9k; Thu, 09 Jan 2025 10:40:20 +0000
Received: by outflank-mailman (input) for mailman id 868071;
 Thu, 09 Jan 2025 10:40:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=KjpQ=UB=amd.com=Michal.Orzel@srs-se1.protection.inumbo.net>)
 id 1tVpxa-00082f-TD
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 10:40:18 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on2061f.outbound.protection.outlook.com
 [2a01:111:f403:2417::61f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1ccd21f6-ce76-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 11:40:16 +0100 (CET)
Received: from CH0PR03CA0053.namprd03.prod.outlook.com (2603:10b6:610:b3::28)
 by DS0PR12MB7558.namprd12.prod.outlook.com (2603:10b6:8:133::21) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8335.10; Thu, 9 Jan
 2025 10:40:12 +0000
Received: from CH3PEPF00000010.namprd04.prod.outlook.com
 (2603:10b6:610:b3:cafe::88) by CH0PR03CA0053.outlook.office365.com
 (2603:10b6:610:b3::28) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8335.10 via Frontend Transport; Thu,
 9 Jan 2025 10:40:12 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH3PEPF00000010.mail.protection.outlook.com (10.167.244.41) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8335.7 via Frontend Transport; Thu, 9 Jan 2025 10:40:11 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 9 Jan
 2025 04:40:11 -0600
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Thu, 9 Jan 2025 04:40:09 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1ccd21f6-ce76-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=s08GleCleiNzRpuKaCMkmJQMkvADMTGsjZX22b+Iat1pR6gUsfWGF7jpFA6kgHevaOeA3PBASPV65DBTubFOpN9QOjaNzuK+7segskuNqMUCC6LD7zqTu7N4WYH+L493y1w8sWV17kWZI4s6osB9jmnKSHw1cojYs7pXRL9YQRfb85rinE5sgGy02qsNA1i5m3qixD2IJz3XIlbcdbossChC87FyqzNS11mTZatVODQom9uGguRBkALhNxo89tJICtLUhKOKK+DnHjWCYC15NvvlALUJyerkTG/+mpApGUpzhZrLj/b/FkuR4N/nP5cW/9n0belpQZpOueAD0rFBiA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=G3uFLwah+omgXXutzDQHS5DnICGLb/iZ8oPUrNnKKuQ=;
 b=KlpAWn7aNT6MG/kZxVpXR5FsWm93x9zTAFi/hu33C84LXwCvitr2JCUXPB0h1Keb69CKXvnKrXWPc72uGRovS+o+Sv/YXCoqJsOBqCDvAItYyDoBsXwkYh/SfIl2QWmcT6meWgpN3Uj1XuTlEx8a4ChU8TBNjHL0KwGJ9rrmNdeoNHjzc54beQfqc2o5ry6bBPBbKMd8QNqQbQQeDCtfe23bqu7eyjWEbZ5fN7pwB88R9wazQ19u/Nx0ECrbyY5exjAf91LP9I5edxhiG7Pb5RNeYmxnIc92DxvdWePijP71D0ICkW/8QFWZVKK4bkB1mrAZMH7B3l0YNRkNEkJbBg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=G3uFLwah+omgXXutzDQHS5DnICGLb/iZ8oPUrNnKKuQ=;
 b=LESylf6Y8lmWFNrijG8+KTHfkvrI4u7xw/R5J7yfZO+rTIncllciE8qqnJvZ526/+SRurUqmh11SOJJO6mkjrcRgK/m47dQZw5AV9z/BWlpNcalA98hf2uppyTcIik/0H/c8ve4Prs+1/LQt9TnDaVwkkrMLjtUxeb2eLUzwiHA=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <c6a02fdc-96a7-412d-8517-c1aa308648f6@amd.com>
Date: Thu, 9 Jan 2025 11:40:09 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] xen/arm: Fully initialise struct membanks_hdr fields
To: Luca Fancellu <Luca.Fancellu@arm.com>
CC: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Stefano
 Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand
 Marquis <Bertrand.Marquis@arm.com>, Volodymyr Babchuk
	<Volodymyr_Babchuk@epam.com>, Oleksii Kurochko <oleksii.kurochko@gmail.com>
References: <20250109092816.1619834-1-luca.fancellu@arm.com>
 <e9477b85-1c9a-4aa6-b7fe-90286fcd461b@amd.com>
 <7D68D11E-E4EF-4521-9017-112DAA2B9B11@arm.com>
 <822cde40-a4a2-4d25-90e1-5421caa7b334@amd.com>
 <3F4D5A7A-0999-417C-91E6-3EE2ECD4759A@arm.com>
Content-Language: en-US
From: Michal Orzel <michal.orzel@amd.com>
In-Reply-To: <3F4D5A7A-0999-417C-91E6-3EE2ECD4759A@arm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Received-SPF: None (SATLEXMB04.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH3PEPF00000010:EE_|DS0PR12MB7558:EE_
X-MS-Office365-Filtering-Correlation-Id: 889e4f22-d864-4731-899c-08dd3099febd
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|1800799024|82310400026|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?b3ViNUt1R1V0bWdETFFJcHp3dURuOFNmVS9oZndrT203Rm9GZm5mMjFzelZm?=
 =?utf-8?B?ZGptYjUxTE5GM3BNV2QxUGZDT3JCd1pQZmNaZStjUWlpTm1BbjhpTmpYdEZT?=
 =?utf-8?B?bDgraE9OTU42ekNrRDV2Wk5FSjFIdW10bGJzam5VbzB4RTQzSGROSXpYaXcr?=
 =?utf-8?B?ZG05QW5SOFBOd3JUZTEwYjZyM3pSelRNNnFkaEVHLzErTkt3ZWg4WXh5MURY?=
 =?utf-8?B?TDRqdWNnUElnVVRKdHVUNzFZdlFuR0lhbkxGaVE3WHZkaHp5aDRaTHlPTjZl?=
 =?utf-8?B?SndST0dsN2pkcStCclpDaEJ0TVkwa0NrTWxVOHdCbWtuVm4rclVkTzluR1JT?=
 =?utf-8?B?TU05aUxKbk1aN3V6b3Y4azhNbDUzckxyVUplV3J1NWxlU0c2SlFRNXNoRFh5?=
 =?utf-8?B?Yzcva254WHp6MmJWdVJlbDRWelhocFA5cFVjeEJLWElkUzUySlkzUExBMnlV?=
 =?utf-8?B?UEc2d0l5RjU3b1VoZzcrTVpoSDhXOVYwb2t2eWowNjlYcXNmSEV1WVllM3JN?=
 =?utf-8?B?aGFXNWVORndydnJpZUZiYkNBRjc5MVVmdFhiR2U4Yzg1SzByUjJJM0lnRHEx?=
 =?utf-8?B?NEpxejdYYVlNME5NejVyTGhjZmhrNWVmWHVXalVhQXA0RTRnREFCSUlDSkN2?=
 =?utf-8?B?bVR1Y0pjU2hudkxiOUdnNUcyaXdUY05JQnhCMDN4bGxLTzUxRFJnR1I5cGZn?=
 =?utf-8?B?UFAvek5aeUlkYXZERFlEakhXN2Y3L3cvYXk1RE9nRnNtZWpWa1laVWFyRXdT?=
 =?utf-8?B?THFROUFaTEx6SWt5TG5oUzFBakk5MXZlYlZyM05Jckcyc0U0Z2V5S3pVWURx?=
 =?utf-8?B?QWg1c0JYaUx0Rm80RUJRZ1BFamw0eDk0M3hMelFmVG1UZVdUdU1oWktJNG04?=
 =?utf-8?B?TTR4OUtYbW1mVGR4M3JmSTJUR29qdjVseGlSWk5IZjVHbXd4bENvQ2ZadGsy?=
 =?utf-8?B?RXRJK25KTnhUQjlWU2VkMi9QZ1RKMjIvUG8rVkhKaWpObC9XYUJTaWMyY0NG?=
 =?utf-8?B?VVcvNW8vU3JFSDMwRithbEdIQmI1WVAvRmlkZktRYzZiZWJ6YmVMTG84emRY?=
 =?utf-8?B?cDBxYjAyYkNGQ1hxMHd3ZHVudTNmMlB1UUw3ZlM2c3VVbTliaGtJYnkwQm9U?=
 =?utf-8?B?SVA5S1FwWFNvdXg0ZzdkNEJGMXZnaktBWkpiUFk3UnFjRUdKT2JrR3JDRmF2?=
 =?utf-8?B?N3RtMC9NL01EVHVpcUtrdlBuSjRsNW1oU2NMeENRMWdVZ1lGU0VZdG5majZ4?=
 =?utf-8?B?S3JWbVVQdkxqdVZ2V2pNbEZDMlpaN1NSTGtvbW1LMnl5Z0x4aHozcXpoWHVh?=
 =?utf-8?B?ak5IR2V4NWZIMTZDU1Y1TXJHTkQxZ29WRkFqSGU5YTFrRThEdnBZN0liNnpQ?=
 =?utf-8?B?aFFsNG91bW8ybjBKbmFNenhXZGhKZ1pUdTJxNERmZlVqRmY5M1dNTzlVd3dW?=
 =?utf-8?B?SGJwTGJOMWUwV2JYdFJVS2V2Yit3N0tLcVpMV0diVkFCQ25GcmtsL1p4R3pu?=
 =?utf-8?B?ck5td21VajVJZjNEZ3Y0STFaSVhxcXFhWkN2K3lzNmdVZEhoKzJFNlF0eHdJ?=
 =?utf-8?B?VjIrNVJIQVd4eHpsUUVxY0lpeHhsSDgzM2dubCtRR3NTYU9PYzkweW1uUWdi?=
 =?utf-8?B?M0hWcW8zdEtybitldkV4ZjB2RGlkSHdqSHBLT1cvM1FyajZxY3JoWllhc25O?=
 =?utf-8?B?bUE0b1QwN0pGWWs4K2VOMGV3Y20zaHVVYmd3am9tZEozdmVxaTh1a3dkRXR0?=
 =?utf-8?B?WnZYMGRHNWVDOTlTNE1EZzJPVDllTUg1S1F0WXlsK3dFaVNXak9FOEswdldL?=
 =?utf-8?B?bzZRN2hWOE05d3FYbVJKUWRJT01UYmZrM1FLOEYvSXVqd0lPYVVUN2FhczRQ?=
 =?utf-8?B?YXEza3BPSUt4eHhaemVzNDVBTXFwa1VtMWdCUkVkQVVGVzVaMHN0QmhVbUpv?=
 =?utf-8?B?bFRLV3lxcHdGOTV0T0tZWW1wWjNHM0RxSkI5RHRqYXVPb1pua0JBelNlNEI3?=
 =?utf-8?Q?0PaPqgTI3FuaR6sUZFcUEy67pbr5bI=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(1800799024)(82310400026)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jan 2025 10:40:11.7504
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 889e4f22-d864-4731-899c-08dd3099febd
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH3PEPF00000010.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB7558



On 09/01/2025 11:27, Luca Fancellu wrote:
> 
> 
>>>
>>>>
>>>>> ---
>>>>> ---
>>>>> xen/arch/arm/domain_build.c       | 13 ++++---------
>>>>> xen/arch/arm/include/asm/kernel.h |  5 ++++-
>>>>> xen/arch/arm/static-shmem.c       |  3 ++-
>>>>> xen/include/xen/bootfdt.h         | 16 ++++++++++++++++
>>>>> 4 files changed, 26 insertions(+), 11 deletions(-)
>>>>>
>>>>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>>>>> index b072a16249fe..9e3132fb21d8 100644
>>>>> --- a/xen/arch/arm/domain_build.c
>>>>> +++ b/xen/arch/arm/domain_build.c
>>>>> @@ -1039,7 +1039,7 @@ void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
>>>>>     */
>>>>>    if ( is_hardware_domain(d) )
>>>>>    {
>>>>> -        struct membanks *gnttab = xzalloc_flex_struct(struct membanks, bank, 1);
>>>>> +        struct membanks *gnttab = membanks_xzalloc(1, RESERVED_MEMORY);
>>>>>        /*
>>>>>         * Exclude the following regions:
>>>>>         * 1) Remove reserved memory
>>>>> @@ -1057,13 +1057,10 @@ void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
>>>>>        gnttab->bank[0].start = kinfo->gnttab_start;
>>>>>        gnttab->bank[0].size = kinfo->gnttab_size;
>>>>>
>>>>> -        hwdom_free_mem = xzalloc_flex_struct(struct membanks, bank,
>>>>> -                                             NR_MEM_BANKS);
>>>>> +        hwdom_free_mem = membanks_xzalloc(NR_MEM_BANKS, MEMORY);
>>>>>        if ( !hwdom_free_mem )
>>>>>            goto fail;
>>>>>
>>>>> -        hwdom_free_mem->max_banks = NR_MEM_BANKS;
>>>>> -
>>>>>        if ( find_unallocated_memory(kinfo, mem_banks, ARRAY_SIZE(mem_banks),
>>>>>                                     hwdom_free_mem, add_hwdom_free_regions) )
>>>>>            goto fail;
>>>>> @@ -1293,7 +1290,7 @@ static int __init find_host_extended_regions(const struct kernel_info *kinfo,
>>>>>                                             struct membanks *ext_regions)
>>>>> {
>>>>>    int res;
>>>>> -    struct membanks *gnttab = xzalloc_flex_struct(struct membanks, bank, 1);
>>>>> +    struct membanks *gnttab = membanks_xzalloc(1, RESERVED_MEMORY);
>>>>>
>>>>>    /*
>>>>>     * Exclude the following regions:
>>>>> @@ -1374,12 +1371,10 @@ int __init make_hypervisor_node(struct domain *d,
>>>>>    }
>>>>>    else
>>>>>    {
>>>>> -        ext_regions = xzalloc_flex_struct(struct membanks, bank, NR_MEM_BANKS);
>>>>> +        ext_regions = membanks_xzalloc(NR_MEM_BANKS, RESERVED_MEMORY);
>>>> I'm a bit confused what is the expectations behind using different types of enum region_type, mostly because it can point to
>>>> different address spaces depending on the context. Above, you marked gnttab as RESERVED_MEMORY (I guess because this
>>>> region has already been found - but in fact it is still unused) and hwdom_free_mem as MEMORY. So I would at least expect
>>>> ext_regions to be of MEMORY type as well. After all both hwdom_free_mem and ext_regions contain
>>>> banks of unused/free memory (although former lists host memory while latter can also contain guest physical
>>>> memory). Could you please clarify the intended use?
>>>
>>> You are right, that should be MEMORY, my bad! Could it be something addressable on commit or should I send another one?
>> I can do that on commit but first, can you please answer what is the intended use of enum region_type?
>> At first I was expecting gnttab to be MEMORY as well. I don't see a difference between a region prepared by Xen
>> for domain to store gnttab vs extended regions. Both specify regions of unused address space. It's just that the region
>> for gnttab must always be present but extended regions don't have to.
> 
> Right, at first I thought gnttab could be reserved memory, but now that you pointed out it’s not the right thing to do, I remember
> now that these type reflects the device tree grouping for the memory banks, so RESERVED_MEMORY is only for these regions
> in the /reserved-memory tree, STATIC_SHARED_MEMORY is for the 'xen,domain-shared-memory-v1’ comaptible node and
> MEMORY is for /memory regions.
> 
> Now I would say that we could use MEMORY also for regions prepared by Xen as long as we don’t need to differentiate them in
> a different way from /memory regions.
> 
> Please let me know your thoughts.
Yes, this is in line with my understanding. Please send a v3 with proper types as discusses. With that:
Reviewed-by: Michal Orzel <michal.orzel@amd.com>

~Michal



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 10:55:30 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 10:55:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868082.1279617 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVqCB-00025C-Jr; Thu, 09 Jan 2025 10:55:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868082.1279617; Thu, 09 Jan 2025 10: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 <xen-devel-bounces@lists.xenproject.org>)
	id 1tVqCB-000255-HK; Thu, 09 Jan 2025 10:55:23 +0000
Received: by outflank-mailman (input) for mailman id 868082;
 Thu, 09 Jan 2025 10:55:21 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=pS5t=UB=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVqC9-00024z-Qc
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 10:55:21 +0000
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com
 [2a00:1450:4864:20::32d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 37c31aea-ce78-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 11:55:20 +0100 (CET)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-436326dcb1cso5929275e9.0
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 02:55:20 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a8e3853b6sm1472700f8f.44.2025.01.09.02.55.18
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 02:55:19 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 37c31aea-ce78-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736420119; x=1737024919; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=C3L6vmC0lgo1xiXBX6ft5qjBXwbLSm+1yFhupCvA/r4=;
        b=MTYkkWcebfLArRLNaSO4yd/NBmCqwxo2i7BVxWSjHITsi38igqol3UbyY4FcnGhWNp
         qZJGb/cfORottVOv6ZpBW12MBCi6hxdeA2KHf7cM9YhCCdR+u0bT5NsCi+Bo+uART8KE
         MPLb3bTVouqzvzyLlgJj9RZ7K3amkvCwKeWTLXZO084hZCInYJKrH6ugIDUwjXU7AGle
         JzwmmPAwxdD+rxyrqCzekZpqd/vC5CIB4pdmRAhJzq337rfjW15Fi+QApXchXtl3/pva
         2P3awbYTkRkueoVwOadYg4jWTwrUOVWqpMn4BhS/1S9L+3JKRXq0nevducDEJgPpYgep
         B8FA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736420119; x=1737024919;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=C3L6vmC0lgo1xiXBX6ft5qjBXwbLSm+1yFhupCvA/r4=;
        b=oE+sWt9hXTlXZUsUvthQgKOijdrftwUgRxHhr8JElTuizg1xGzQjyi3MQWmDrSeWP5
         A9EH0yWuUd0BR3LxwoP1YsOmgXyXL+f/hAIr0Gx/PCfIxeE9K7+1yb1mYcb4v4YsYddW
         xu23GfZJ5S+0uFazlqKJN1G/7ll7BawrXbbOfMglG05iTzwM+m/Pw69qv2k2u2eGdL82
         BW3K95oBOINxKiYAlqVeFrYxPwj/vnliVGy49IstwE0skQVfZMhrpwLp/lP9dJtJ6g7b
         9QPpy9s1T/YYSiVxj5wc2ft/98+YiAHW4V5cqmPCdG4VqrIFn7MtvfEQwNuf09pKTsTc
         j8pQ==
X-Forwarded-Encrypted: i=1; AJvYcCXuWMa8Dik2G94E97SFRRyG1dVY+waBmhWHs/gWhuWQBTnxoecWtRwyCCVMyturybricDaHvLd5Xkc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxxFQpw1qFXACENY4Y4i6+w1HuwKy982sOh/N7PI8FjqC11gIav
	sMvISvSgmPVIR3ayxlBtG02qugVYkou3zGMjsLyKKonO28QY9PUzVZ0J5wg5AA==
X-Gm-Gg: ASbGncvUkwUxwX+ehwEka1kG5z0Nt4VSurP2XsG9tG7/yLnQMMJ3Z8cLaoUvkDAyhl2
	UqLm0bL77Hx7xHBPTqjf8hWV6weuIljwsfRwlqSlHuZchTlNQjkcvhJPVyN8PMIQYrnU8RDG1YS
	G0h53BQJeL0R4UgdvB8wHAZny3EV+tNzmtODcV//spTadNfmGYES7G+6Fn0F92UZAYoIfNdqBj9
	3lcMSpH/o8bmHCw0eyU68UPQ689SKMzf8366zdGZkk+cF72r6bwtF/8PKhtixnR3eF9uiQk9Mbo
	UGKvx0TjjC0Tqus/F/r7syEfVP8z4mkZjw4wiD08Sw==
X-Google-Smtp-Source: AGHT+IHz2zHasnEoZ+leDVBXjWDoiGOwKIR8JXLtJl9v/RqfvNwmxOiWHa99RoHfShXzrXcTE4ZjIw==
X-Received: by 2002:a05:6000:186b:b0:385:ef97:78c with SMTP id ffacd0b85a97d-38a872d2ae8mr4625431f8f.6.1736420119324;
        Thu, 09 Jan 2025 02:55:19 -0800 (PST)
Message-ID: <f7f03617-e438-48c1-b5b0-1ca975cbc7e6@suse.com>
Date: Thu, 9 Jan 2025 11:55:17 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 05/11] xen/x86: introduce a new amd pstate driver for
 cpufreq scaling
To: Penny Zheng <Penny.Zheng@amd.com>
Cc: stefano.stabellini@amd.com, Ray.Huang@amd.com, Xenia.Ragiadakou@amd.com,
 Jason.Andryuk@amd.com, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20241203081111.463400-1-Penny.Zheng@amd.com>
 <20241203081111.463400-6-Penny.Zheng@amd.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20241203081111.463400-6-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 03.12.2024 09:11, Penny Zheng wrote:
> --- a/xen/arch/x86/acpi/cpufreq/amd-pstate.c
> +++ b/xen/arch/x86/acpi/cpufreq/amd-pstate.c
> @@ -15,6 +15,53 @@
>  #include <xen/init.h>
>  #include <xen/param.h>
>  #include <acpi/cpufreq/cpufreq.h>
> +#include <asm/msr.h>
> +
> +#define amd_pstate_err(cpu, fmt, args...) \
> +    printk(XENLOG_ERR "AMD_PSTATE: CPU%u error: " fmt, cpu, ## args)
> +#define amd_pstate_verbose(fmt, args...)                         \
> +({                                                               \
> +    if ( cpufreq_verbose )                                       \
> +        printk(XENLOG_DEBUG "AMD_PSTATE: " fmt, ## args);        \
> +})
> +#define amd_pstate_warn(fmt, args...) \
> +    printk(XENLOG_WARNING "AMD_PSTATE: CPU%u warning: " fmt, cpu, ## args)
> +
> +struct amd_pstate_drv_data
> +{
> +    struct xen_processor_cppc *cppc_data;
> +    union
> +    {
> +        uint64_t amd_caps;
> +        struct
> +        {
> +            unsigned int lowest_perf:8;
> +            unsigned int lowest_nonlinear_perf:8;
> +            unsigned int nominal_perf:8;
> +            unsigned int highest_perf:8;
> +            unsigned int :32;
> +        } hw;

Please can this be


    union {
        uint64_t raw;
        struct {
            unsigned int lowest_perf:8;
            unsigned int lowest_nonlinear_perf:8;
            unsigned int nominal_perf:8;
            unsigned int highest_perf:8;
            unsigned int :32;
        };
    } caps;

such that at use sites (e.g. amd_pstate_write_request()) it is possible to
actually spot that the same thing is being accessed through the two parts
of the union?

> +    };
> +    union
> +    {
> +        uint64_t amd_req;
> +        struct
> +        {
> +            unsigned int max_perf:8;
> +            unsigned int min_perf:8;
> +            unsigned int des_perf:8;
> +            unsigned int epp:8;
> +            unsigned int :32;
> +        } req;
> +    };

Along the same lines here then.

> +    int err;
> +
> +    uint32_t max_freq;
> +    uint32_t min_freq;
> +    uint32_t nominal_freq;
> +};
> +
> +static DEFINE_PER_CPU_READ_MOSTLY(struct amd_pstate_drv_data *, amd_pstate_drv_data);
>  
>  uint16_t __read_mostly dmi_max_speed_mhz;
>  
> @@ -52,9 +99,298 @@ int __init amd_pstate_cmdline_parse(const char *s, const char *e)
>      return 0;
>  }
>  
> +/*
> + * If CPPC lowest_freq and nominal_freq registers are exposed then we can
> + * use them to convert perf to freq and vice versa. The conversion is
> + * extrapolated as an affine function passing by the 2 points:
> + *  - (Low perf, Low freq)
> + *  - (Nominal perf, Nominal freq)
> + */
> +static unsigned int amd_pstate_khz_to_perf(struct amd_pstate_drv_data *data, unsigned int freq)

Const?

> +{
> +    struct xen_processor_cppc* cppc_data = data->cppc_data;

Nit: Misplaced *. Const?

> +    uint64_t mul, div, offset = 0;
> +
> +    if ( freq == (cppc_data->nominal_freq * 1000) )
> +        return data->hw.nominal_perf;
> +
> +    if ( freq == (cppc_data->lowest_freq * 1000) )
> +        return data->hw.lowest_perf;
> +
> +    if ( (cppc_data->lowest_freq) && (cppc_data->nominal_freq) )
> +    {
> +        mul = data->hw.nominal_perf - data->hw.lowest_perf;
> +        div = cppc_data->nominal_freq - cppc_data->lowest_freq;
> +        /*
> +         * We don't need to convert to kHz for computing offset and can
> +         * directly use nominal_freq and lowest_freq as the division
> +         * will remove the frequency unit.
> +         */
> +        div = div ?: 1;
> +        offset = data->hw.nominal_perf - (mul * cppc_data->nominal_freq) / div;
> +    }
> +    else
> +    {
> +        /* Read Processor Max Speed(mhz) from DMI table as anchor point */
> +        mul = data->hw.highest_perf;
> +        div = dmi_max_speed_mhz;

What if dmi_max_speed_mhz is still 0?

> +    }
> +
> +    return (unsigned int)(offset + (mul * freq ) / (div * 1000));

Nit: Excess blank before a closing parenthesis.

> +}
> +
> +static unsigned int amd_get_min_freq(struct amd_pstate_drv_data *data)
> +{
> +    struct xen_processor_cppc *cppc_data = data->cppc_data;
> +    uint64_t mul, div;
> +
> +    if ( cppc_data->lowest_freq )
> +        /* Switch to khz */
> +        return cppc_data->lowest_freq * 1000;
> +    else

Please avoid "else" when the earlier if() ends in an unconditional control
flow statement.

> +    {
> +        /* Read Processor Max Speed(mhz) from DMI table as anchor point */
> +        mul = dmi_max_speed_mhz;
> +        div = data->hw.highest_perf;
> +
> +        return (unsigned int)(mul / div) * data->hw.lowest_perf * 1000;

No risk of the cast chopping off set bits?

> +static unsigned int amd_get_nominal_freq(struct amd_pstate_drv_data *data)
> +{
> +    struct xen_processor_cppc *cppc_data = data->cppc_data;
> +    uint64_t mul, div;
> +
> +    if ( cppc_data->nominal_freq )
> +        /* Switch to khz */
> +        return cppc_data->nominal_freq * 1000;
> +    else
> +    {
> +        /* Read Processor Max Speed(mhz) from DMI table as anchor point */
> +        mul = dmi_max_speed_mhz;
> +        div = data->hw.highest_perf;
> +
> +        return (unsigned int)(mul / div) * data->hw.nominal_perf * 1000;
> +    }
> +}
> +
> +static unsigned int amd_get_max_freq(struct amd_pstate_drv_data *data)
> +{
> +    uint64_t max_perf, max_freq, nominal_freq, nominal_perf;
> +    uint64_t boost_ratio;
> +
> +    nominal_freq = amd_get_nominal_freq(data);
> +    nominal_perf = data->hw.nominal_perf;
> +    max_perf = data->hw.highest_perf;
> +
> +    boost_ratio = (uint64_t)(max_perf / nominal_perf);

What's the point of the cast here?

> +    max_freq = nominal_freq * boost_ratio;
> +
> +    return max_freq;
> +}
> +
> +static int cf_check amd_pstate_cpufreq_verify(struct cpufreq_policy *policy)
> +{
> +    struct amd_pstate_drv_data *data = per_cpu(amd_pstate_drv_data, policy->cpu);

Const? (I won't further repeat this. Please make pointers pointer-to-
const wherever possible. We aim at having fully const-correct code.)

> +    cpufreq_verify_within_limits(policy, data->min_freq, data->max_freq);
> +
> +    return 0;
> +}
> +
> +static void amd_pstate_write_request_msrs(void *info)
> +{
> +    struct amd_pstate_drv_data *data =(struct amd_pstate_drv_data *)info;

Nit: Blank after = and no need for a cast.

> +    if ( wrmsr_safe(MSR_AMD_CPPC_REQ, data->amd_req) )
> +    {
> +        amd_pstate_verbose("Failed to wrmsr_safe(MSR_AMD_CPPC_REQ, %lx)\n",
> +                           data->amd_req);

If the was to ever trigger, it would likely get very noisy in the log.

> +        data->err = -EINVAL;
> +        return;
> +    }
> +    data->err = 0;
> +}
> +
> +static int cf_check amd_pstate_write_request(int cpu, uint8_t min_perf,
> +                                             uint8_t des_perf, uint8_t max_perf)
> +{
> +    struct amd_pstate_drv_data *data = per_cpu(amd_pstate_drv_data, cpu);
> +    uint64_t prev = data->amd_req;
> +
> +    data->req.min_perf = min_perf;
> +    data->req.max_perf = max_perf;
> +    data->req.des_perf = des_perf;
> +
> +    if ( prev == data->amd_req )
> +        return 0;
> +
> +    on_selected_cpus(cpumask_of(cpu), amd_pstate_write_request_msrs, data, 1);
> +
> +    return data->err;
> +}
> +
> +static int cf_check amd_pstate_cpufreq_target(struct cpufreq_policy *policy,
> +                                              unsigned int target_freq,
> +                                              unsigned int relation)
> +{
> +    unsigned int cpu = policy->cpu;
> +    struct amd_pstate_drv_data *data = per_cpu(amd_pstate_drv_data, cpu);
> +    uint64_t max_perf, min_perf, des_perf;
> +
> +    if ( unlikely(!target_freq) )
> +    {
> +        amd_pstate_warn("Not setting target frequency to zero\n");

Potentially overly noisy again.

> +        return 0;
> +    }
> +    max_perf = data->hw.highest_perf;
> +    min_perf = data->hw.lowest_nonlinear_perf;
> +    des_perf = amd_pstate_khz_to_perf(data, target_freq);
> +
> +    return amd_pstate_write_request(policy->cpu, min_perf, des_perf, max_perf);

The use of intermadiate variables doesn't look very helpful here. Even more
so that in the course of the call 64-bit quantaties will be truncated to
8-bit ones.

> +}
> +
> +static void cf_check amd_pstate_init_msrs(void *info)
> +{
> +    struct cpufreq_policy *policy = info;
> +    struct amd_pstate_drv_data *data = this_cpu(amd_pstate_drv_data);
> +    uint64_t val;
> +    unsigned int min_freq, nominal_freq, max_freq;
> +
> +    /* Package level MSR */
> +    if ( rdmsr_safe(MSR_AMD_CPPC_ENABLE, val) )

Before trying this, wouldn't you better exclude certain very old families?
Even looking at a random Fam17 PPR I can't spot documentation of this MSR
(nor the other two), despite you merely saying Zen elsewhere (without any
version number).

> +    {
> +        amd_pstate_err(policy->cpu, "rdmsr_safe(MSR_AMD_CPPC_ENABLE)\n");
> +        data->err = -EINVAL;
> +        return;
> +    }
> +
> +    if ( !(val & AMD_CPPC_ENABLE) )
> +    {
> +        val |= AMD_CPPC_ENABLE;
> +        if ( wrmsr_safe(MSR_AMD_CPPC_ENABLE, val) )
> +        {
> +            amd_pstate_err(policy->cpu, "wrmsr_safe(MSR_AMD_CPPC_ENABLE, %lx)\n", val);
> +            data->err = -EINVAL;
> +            return;
> +        }
> +    }

Do you really need to enable befor reading ...

> +    if ( rdmsr_safe(MSR_AMD_CPPC_CAP1, data->amd_caps) )

... capabilities and ...

> +    {
> +        amd_pstate_err(policy->cpu, "rdmsr_safe(MSR_AMD_CPPC_CAP1)\n");
> +        goto error;
> +    }
> +
> +    if ( data->hw.highest_perf == 0 || data->hw.lowest_perf == 0 ||
> +         data->hw.nominal_perf == 0 || data->hw.lowest_nonlinear_perf == 0 )
> +    {
> +        amd_pstate_err(policy->cpu, "Platform malfunction, read CPPC highest_perf: %u, lowest_perf: %u, nominal_perf: %u, lowest_nonlinear_perf: %u zero value\n",
> +                       data->hw.highest_perf, data->hw.lowest_perf,
> +                       data->hw.nominal_perf, data->hw.lowest_nonlinear_perf);
> +        goto error;
> +    }
> +
> +    min_freq = amd_get_min_freq(data);
> +    nominal_freq = amd_get_nominal_freq(data);
> +    max_freq = amd_get_max_freq(data);
> +    if ( min_freq > max_freq )
> +    {
> +        amd_pstate_err(policy->cpu, "min_freq(%u) or max_freq(%u) value is incorrect\n",
> +                       min_freq, max_freq);
> +        goto error;
> +    }

... checking them? Error handling would be easier if you enabled only afterwards.

> +    policy->min = min_freq;
> +    policy->max = max_freq;
> +
> +    policy->cpuinfo.min_freq = min_freq;
> +    policy->cpuinfo.max_freq = max_freq;
> +    policy->cpuinfo.perf_freq = nominal_freq;
> +    policy->cur = nominal_freq;
> +
> +    /* Initial processor data capability frequencies */
> +    data->min_freq = min_freq;
> +    data->nominal_freq = nominal_freq;
> +    data->max_freq = max_freq;
> +
> +    data->err = 0;
> +    return;
> +
> + error:
> +    data->err = -EINVAL;
> +    val &= ~AMD_CPPC_ENABLE;
> +    if ( wrmsr_safe(MSR_AMD_CPPC_ENABLE, val) )
> +        amd_pstate_err(policy->cpu, "wrmsr_safe(MSR_AMD_CPPC_ENABLE, %lx)\n", val);
> +}
> +
> +/*
> + * The new AMD P-States driver is different than legacy ACPI hardware P-State,
> + * which has a finer grain frequency range between the highest and lowest
> + * frequency. And boost frequency is actually the frequency which is mapped on
> + * highest performance ratio. The legacy P0 frequency is actually mapped on
> + * nominal performance ratio.
> + */
> +static void amd_pstate_boost_init(struct cpufreq_policy *policy, struct amd_pstate_drv_data *data)
> +{
> +    uint32_t highest_perf, nominal_perf;

Why uint32_t when the fields read are both 8-bit only?

> +    highest_perf = data->hw.highest_perf;
> +    nominal_perf = data->hw.nominal_perf;
> +
> +    if ( highest_perf <= nominal_perf )
> +        return;
> +
> +    policy->turbo = CPUFREQ_TURBO_ENABLED;
> +}

And why the helper variables in the first place?

> +static int cf_check amd_pstate_cpufreq_cpu_init(struct cpufreq_policy *policy)
> +{
> +    unsigned int cpu = policy->cpu;
> +    struct amd_pstate_drv_data *data;
> +
> +    data = xzalloc(struct amd_pstate_drv_data);
> +    if ( !data )
> +        return -ENOMEM;
> +
> +    data->cppc_data = &processor_pminfo[cpu]->cppc_data;
> +
> +    policy->governor = cpufreq_opt_governor ? : CPUFREQ_DEFAULT_GOVERNOR;
> +
> +    per_cpu(amd_pstate_drv_data, cpu) = data;
> +
> +    on_selected_cpus(cpumask_of(cpu), amd_pstate_init_msrs, policy, 1);
> +
> +    if ( data->err )
> +    {
> +        amd_pstate_err(cpu, "Could not initialize AMD CPPC MSR properly\n");
> +        per_cpu(amd_pstate_drv_data, cpu) = NULL;
> +        xfree(data);

Please use XFREE() (really XVFREE() after respective conversion) in such cases.

> +        return -ENODEV;

You're no undoing the policy->governor adjustment - maybe best to delay that
until after all errors were handled?

> --- a/xen/arch/x86/include/asm/msr-index.h
> +++ b/xen/arch/x86/include/asm/msr-index.h
> @@ -455,6 +455,11 @@
>  #define MSR_AMD_PPIN_CTL                0xc00102f0U
>  #define MSR_AMD_PPIN                    0xc00102f1U
>  
> +#define MSR_AMD_CPPC_CAP1               0xc00102b0
> +#define MSR_AMD_CPPC_ENABLE             0xc00102b1
> +#define MSR_AMD_CPPC_REQ                0xc00102b3
> +#define AMD_CPPC_ENABLE                 BIT(0, ULL)

Bits of individual MSRs want to follow their MSR #define directly, with
suitably different indentation. Please further pay attention to this
comment in the file (as well as the bigger one at the top):

/*
 * Legacy MSR constants in need of cleanup.  No new MSRs below this comment.
 */

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 10:57:01 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 10:57:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868093.1279627 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVqDk-0002fG-0w; Thu, 09 Jan 2025 10:57:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868093.1279627; Thu, 09 Jan 2025 10:56:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVqDj-0002f9-Ud; Thu, 09 Jan 2025 10:56:59 +0000
Received: by outflank-mailman (input) for mailman id 868093;
 Thu, 09 Jan 2025 10:56: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
 <SRS0=rr8/=UB=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tVqDj-0002f1-2g
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 10:56:59 +0000
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com
 [2a00:1450:4864:20::334])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 71b4aa13-ce78-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 11:56:57 +0100 (CET)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-4361815b96cso5835325e9.1
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 02:56:57 -0800 (PST)
Received: from [192.168.86.29] ([83.105.36.37])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436e9e37d74sm16900385e9.29.2025.01.09.02.56.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 02:56:56 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 71b4aa13-ce78-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736420216; x=1737025016; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=djGHfkzCKFhqMpCfIe7TxlLMHasKymCERG8Gpo7WRKY=;
        b=UwTClgrE8Mh5xteeK8EEeocRusygNrWhYq9B+lHy4PQxZ8YDahrFV00AxUmPneiGDI
         x+HX0OMEtecXnm18sk+Cg+pX+6yR28KFon6HDlcb1FHXurmC0bq0uWWpjcOuwDl5K+Ie
         UqUqPKf2krX4KgNUneTOeiIGoNF3AT4EG3a5g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736420216; x=1737025016;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=djGHfkzCKFhqMpCfIe7TxlLMHasKymCERG8Gpo7WRKY=;
        b=pZZUCML5mGtMTC+iZXhPTRXAK4vmCQn/LAUOyJ4SqBhkDdoABKCHyj9NJ+dIbY66Nv
         5lhzPS0zucuktSAWyd045BneQbk4O9QjNMxaUiZm2hsrfGBHNuP4J0YlGTwH/qYeRZSZ
         upOAST0j+AICInNAn/+kZgyLYliELjdwYcqPswPCwROVyf0H7HfbAawLqUAewrnWpuFI
         AuiY6L6RKSWbVk50ElVcuprRt1jLrSaBmvIdByzQlcugxV/6rGSlmqlOKlte1dkr3q4r
         KJ/NU+Z6zRuE080rNlCyMXsS8MKDWEd4ENqbLxR60CNXF7SJEe24QH3TR9UwFaJYK5TS
         JAYg==
X-Forwarded-Encrypted: i=1; AJvYcCUmiUr6BxuICcgzMp51SmodjRS3tWD7KfYDP0ubQbdMOVT447ddGYiOS4ZlY6YpnLh6UGvTEFAcNFA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyS0N4vcnKpad3C1hdioCwcCEd1vJYX2MZ05dWQAy7Xsd/zSqKG
	yu8U5VdvSyIskN1FGeD1eFYiZ5pCog5/DRaJCyfgPttKFp+iHsXcVRKaX9nIRpk=
X-Gm-Gg: ASbGnctWu6WKYFERD8jhXsR4g4Q2UnAvS/gGwvhHSyehsRin4Q8JW+WFuOXhtJOt7T0
	2AJVeYGhO6VDddRSXtsZsu6b6tDWXU0n1pA2MIyLd5t9jd/he2wWEFnRbUg01+ZPamDnS/iA3Pm
	8sj/Ubempz/3Up+RsUtcdr6aEJTgPNqE4Sr8UsZ7f8hTnB2ne/u4pLH8LJt2xZyKLvvPgOdpljc
	/KlbGhxlU/s7kApL56B9HCoUmO8WIrUjGQk4U9Y/nF1I1XLxVXHCxmEoa7wOIY1/ss=
X-Google-Smtp-Source: AGHT+IFac6gDf45bd56Pa/++0zTwuL9VrnL4kn1j5hrj43cu7ZfLo+Ker0VejpYqvPkkrONm+sNjjQ==
X-Received: by 2002:a05:600c:4510:b0:431:54d9:da57 with SMTP id 5b1f17b1804b1-436e26ffb2cmr61925645e9.30.1736420216439;
        Thu, 09 Jan 2025 02:56:56 -0800 (PST)
Message-ID: <d1b55fc3-feac-47e8-beed-5905b67131e4@citrix.com>
Date: Thu, 9 Jan 2025 10:56:55 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/mm: Introduce per-arch pte_attr_t type for PTE flags
To: Jan Beulich <jbeulich@suse.com>,
 Shawn Anastasio <sanastasio@raptorengineering.com>
Cc: tpearson@raptorengineering.com, Anthony PERARD
 <anthony.perard@vates.tech>, Michal Orzel <michal.orzel@amd.com>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Stefano Stabellini <sstabellini@kernel.org>,
 "Daniel P. Smith" <dpsmith@apertussolutions.com>,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, xen-devel@lists.xenproject.org
References: <47babd3f9ec00c15738a81aa57926e8a1f08cbe6.1735669493.git.sanastasio@raptorengineering.com>
 <a769ef28-5794-45a0-bb3f-e3dc3e3bcef3@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <a769ef28-5794-45a0-bb3f-e3dc3e3bcef3@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 09/01/2025 9:15 am, Jan Beulich wrote:
> On 31.12.2024 19:27, Shawn Anastasio wrote:
>> Xen's memory management APIs map_pages_to_xen, modify_xen_mappings,
>> set_fixmap, ioremap_attr, and __vmap all use an unsigned int to
>> represent architecture-dependent page table entry flags. This assumption
>> does not work on PPC/radix where some flags go past 32-bits, so
>> introduce the pte_attr_t type to allow architectures to opt in to larger
>> types to store PTE flags.
>>
>> Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> Signed-off-by: Shawn Anastasio <sanastasio@raptorengineering.com>
> As iirc Andrew had indicated when suggesting this, what you say for PPC is
> true for x86 as well. Yet still we get around with unsigned int. Hence I
> think the change needs describing differently.

x86 is currently unsigned int, and with some reasonably expensive
packing/unpacking under the hood.

x86 ought to become unsigned long, now we don't have the 32bit build to
worry about.  (back of the envelope calculation says up/down: 400/-3868
(-3468) but I've not checked that this boots).

>
>> --- a/xen/include/xen/mm.h
>> +++ b/xen/include/xen/mm.h
>> @@ -70,6 +70,10 @@
>>  #include <xen/perfc.h>
>>  #include <public/memory.h>
>>  
>> +#ifndef CONFIG_HAS_PTE_ATTR_T
>> +typedef unsigned int pte_attr_t;
>> +#endif
> This imo makes the Kconfig control a misnomer: We'll always have pte_attr_t.
> I wonder whether this actually needs a Kconfig setting in the first place:
> It's hardly the end of the world for all architectures to specify the type
> (later: the underlying type, for the real type to become type-safe)
> explicitly.

All architectures strictly need this.  It's not optional, so doesn't
warrant a Kconfig option.

Either, arch/mm.h is required to provide the typedef, or we could have a
common one as so:

#ifndef pte_attr_t
typedef unsigned int pte_attr_t;
#endif

which architectures can influence with:

typedef unsigned long pte_attr_t;
#define pte_attr_t pte_attr_t

in the usual way.


One thing however does occur to me.  ARM and RISC-V have systems with
MPU protections rather than MMU, with Xen already starting to support
this on ARM.

Therefore we might want to reconsider the name pte_attr_t to be
something slightly less pagetable specific.  Then again, I'm not sure
how much overlap there is between the map* functions and MPUs, where
mapping is of course not possible.


Finally, this wants to be at least 2 patches.  One introducing
pte_attr_t, and one changing PPC to be unsigned long.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 10:59:45 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 10:59:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868103.1279637 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVqGO-0003FK-Dg; Thu, 09 Jan 2025 10:59:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868103.1279637; Thu, 09 Jan 2025 10:59:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVqGO-0003FD-At; Thu, 09 Jan 2025 10:59:44 +0000
Received: by outflank-mailman (input) for mailman id 868103;
 Thu, 09 Jan 2025 10:59: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 <SRS0=vJOs=UB=suse.com=jgross@srs-se1.protection.inumbo.net>)
 id 1tVqGN-0003F6-4Y
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 10:59:43 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de
 [2a07:de40:b251:101:10:150:64:2])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d3e73162-ce78-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 11:59:42 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id 3B9031F385;
 Thu,  9 Jan 2025 10:59:41 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id D6392139AB;
 Thu,  9 Jan 2025 10:59:40 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id k3RpMhysf2fYHAAAD6G6ig
 (envelope-from <jgross@suse.com>); Thu, 09 Jan 2025 10:59:40 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: d3e73162-ce78-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1736420381; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:  content-transfer-encoding:content-transfer-encoding;
	bh=6aitO5efjlu3UOnIh1gwROdrn+jpZ4uRyHLW/XnN0b0=;
	b=N2etshD0Wlug9BE+R7s8lnjZdLmR+dz6lyZ1odrYb8UXrU3tcnY+RH3vy7isUv9N9aJa8l
	9f56lYRRHsMj7GdbbIw6VMWOL2T5EejWMIftw9ucLnrdzWeD0Ck8Fok28tH2HsK3cqAXI/
	juu+KVq8UZe26wqhTUj+lClvpuI7eX0=
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=N2etshD0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1736420381; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:  content-transfer-encoding:content-transfer-encoding;
	bh=6aitO5efjlu3UOnIh1gwROdrn+jpZ4uRyHLW/XnN0b0=;
	b=N2etshD0Wlug9BE+R7s8lnjZdLmR+dz6lyZ1odrYb8UXrU3tcnY+RH3vy7isUv9N9aJa8l
	9f56lYRRHsMj7GdbbIw6VMWOL2T5EejWMIftw9ucLnrdzWeD0Ck8Fok28tH2HsK3cqAXI/
	juu+KVq8UZe26wqhTUj+lClvpuI7eX0=
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross <jgross@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>
Subject: [PATCH v7 0/7] remove libxenctrl usage from xenstored
Date: Thu,  9 Jan 2025 11:59:28 +0100
Message-ID: <20250109105935.23585-1-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 3B9031F385
X-Spam-Level: 
X-Spamd-Result: default: False [-3.01 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	MIME_TRACE(0.00)[0:+];
	ARC_NA(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	RCVD_TLS_ALL(0.00)[];
	DKIM_TRACE(0.00)[suse.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_SEVEN(0.00)[11];
	ASN(0.00)[asn:25478, ipnet:::/0, country:RU];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:dkim,suse.com:mid,imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns]
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Rspamd-Action: no action
X-Spam-Score: -3.01
X-Spam-Flag: NO

Xenstored is using libxenctrl for only one purpose: to get information
about state of domains.

This patch series is removing that dependency by introducing a new
stable interface which can be used by xenstored instead.

There was a RFC series sent out 3 years ago, which I have taken as a
base and by addressing all comments from back then.

The main differences since that RFC series are:

- Instead of introducing an new main hypercall for a stable management
  interface I have just added a new domctl sub-op, as requested in 2021.

- I have added a new library libxenmanage for easy use of the new
  stable hypervisor interface. Main motivation for adding the library
  was the recent attempt to decouple oxenstored from the Xen git tree.
  By using the new library, oxenstored could benefit in the same way as
  xenstored from the new interface: it would be possible to rely on
  stable libraries only.

- Mini-OS has gained some more config options recently, so it was rather
  easy to make xenstore[pvh]-stubdom independent from libxenctrl, too.

Please note that the last patch can be committed only after the related
Mini-OS patch "config: add support for libxenmanage" has gone in AND
the Mini-OS commit-id has been updated in Config.mk accordingly! The
Mini-OS patch has been Acked already, so it can go in as soon as patch
6 of this series (the one introducing libxenmanage) has been committed.

Changes in V2:
- new patch 1
- former patch 5 mover earlier, now patch 2 (can go in without the rest
  of the series)
- addressed comments

Changes in V3:
- addressed comments

Changes in V4:
- patches 1 and 3 of V3 dropped, as already committed
- addressed comments

Changes in V5:
- addressed comments

Changes in V6:
- patch 1 of V5 has been committed
- new patches 1-3 for fixing a race and avoiding new races with the
  added functionality (result of a comment by Jan Beulich)
- rework of locking in patch 4 (Jan Beulich)

Changes in V7:
- addressed comments
- rebase

Juergen Gross (7):
  xen/events: fix race with set_global_virq_handler()
  xen/events: don't allow binding a global virq from any domain
  xen/events: allow setting of global virq handler only for unbound
    virqs
  xen: add bitmap to indicate per-domain state changes
  xen: add new domctl get_changed_domain
  tools/libs: add a new libxenmanage library
  tools/xenstored: use new stable interface instead of libxenctrl

 stubdom/Makefile                       |   8 +-
 stubdom/mini-os.mk                     |   1 +
 tools/flask/policy/modules/dom0.te     |   1 +
 tools/flask/policy/modules/xen.if      |   5 +-
 tools/flask/policy/modules/xenstore.te |   1 +
 tools/include/xenmanage.h              |  92 ++++++++++++++
 tools/libs/Makefile                    |   1 +
 tools/libs/manage/Makefile             |  10 ++
 tools/libs/manage/Makefile.common      |   3 +
 tools/libs/manage/core.c               | 168 +++++++++++++++++++++++++
 tools/libs/manage/libxenmanage.map     |   8 ++
 tools/libs/uselibs.mk                  |   2 +
 tools/xenstored/Makefile               |   2 +-
 tools/xenstored/Makefile.common        |   2 +-
 tools/xenstored/core.h                 |   1 -
 tools/xenstored/domain.c               |  52 +++-----
 tools/xenstored/lu.c                   |   1 +
 tools/xenstored/lu_daemon.c            |   1 +
 xen/common/domain.c                    | 125 ++++++++++++++++++
 xen/common/domctl.c                    |  18 ++-
 xen/common/event_channel.c             |  95 ++++++++++++--
 xen/include/public/domctl.h            |  26 ++++
 xen/include/xen/event.h                |   4 +
 xen/include/xen/sched.h                |   5 +
 xen/include/xsm/dummy.h                |   8 ++
 xen/include/xsm/xsm.h                  |   6 +
 xen/xsm/dummy.c                        |   1 +
 xen/xsm/flask/hooks.c                  |   7 ++
 xen/xsm/flask/policy/access_vectors    |   2 +
 29 files changed, 605 insertions(+), 51 deletions(-)
 create mode 100644 tools/include/xenmanage.h
 create mode 100644 tools/libs/manage/Makefile
 create mode 100644 tools/libs/manage/Makefile.common
 create mode 100644 tools/libs/manage/core.c
 create mode 100644 tools/libs/manage/libxenmanage.map

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 10:59:50 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 10:59:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868104.1279647 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVqGU-0003Vn-LV; Thu, 09 Jan 2025 10:59:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868104.1279647; Thu, 09 Jan 2025 10:59:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVqGU-0003Vd-IO; Thu, 09 Jan 2025 10:59:50 +0000
Received: by outflank-mailman (input) for mailman id 868104;
 Thu, 09 Jan 2025 10:59:49 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=vJOs=UB=suse.com=jgross@srs-se1.protection.inumbo.net>)
 id 1tVqGT-0003VB-77
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 10:59:49 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d7260af7-ce78-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 11:59:47 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id 089C51F385;
 Thu,  9 Jan 2025 10:59:47 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id A9BC6139AB;
 Thu,  9 Jan 2025 10:59:46 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id Uoi3JyKsf2fpHAAAD6G6ig
 (envelope-from <jgross@suse.com>); Thu, 09 Jan 2025 10:59:46 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: d7260af7-ce78-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1736420387; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=6yHKHkyNV7SkbCgUGT5IGKtS0fWOirj5mabK6I1iS1M=;
	b=tIkuLkoZ1RsqofILUwpYenfPKoxWVFiQ3sVLieZq5lLcrGTFUEi2fEPCnFHUHd0Z/UsUmx
	HUUcJ2/fKa/59D/0it4SAUrpNI99Utq+8gL9tJNeorLMB2lMU5zL9CCTaTqltAyQteO69r
	wCv8BsNBiQdc4udRCV+II17k/Wd2+T0=
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1736420387; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=6yHKHkyNV7SkbCgUGT5IGKtS0fWOirj5mabK6I1iS1M=;
	b=tIkuLkoZ1RsqofILUwpYenfPKoxWVFiQ3sVLieZq5lLcrGTFUEi2fEPCnFHUHd0Z/UsUmx
	HUUcJ2/fKa/59D/0it4SAUrpNI99Utq+8gL9tJNeorLMB2lMU5zL9CCTaTqltAyQteO69r
	wCv8BsNBiQdc4udRCV+II17k/Wd2+T0=
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross <jgross@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v7 1/7] xen/events: fix race with set_global_virq_handler()
Date: Thu,  9 Jan 2025 11:59:29 +0100
Message-ID: <20250109105935.23585-2-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250109105935.23585-1-jgross@suse.com>
References: <20250109105935.23585-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.80
X-Spamd-Result: default: False [-2.80 / 50.00];
	BAYES_HAM(-3.00)[99.99%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_SEVEN(0.00)[9];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MIME_TRACE(0.00)[0:+];
	ARC_NA(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,suse.com:email,imap1.dmz-prg2.suse.org:helo];
	RCVD_TLS_ALL(0.00)[]
X-Spam-Flag: NO
X-Spam-Level: 

There is a possible race scenario between set_global_virq_handler()
and clear_global_virq_handlers() targeting the same domain, which
might result in that domain ending as a zombie domain.

In case set_global_virq_handler() is being called for a domain which
is just dying, it might happen that clear_global_virq_handlers() is
running first, resulting in set_global_virq_handler() taking a new
reference for that domain and entering in the global_virq_handlers[]
array afterwards. The reference will never be dropped, thus the domain
will never be freed completely.

This can be fixed by checking the is_dying state of the domain inside
the region guarded by global_virq_handlers_lock. In case the domain is
dying, handle it as if the domain wouldn't exist, which will be the
case in near future anyway.

Fixes: 87521589aa6a ("xen: allow global VIRQ handlers to be delegated to other domains")
Signed-off-by: Juergen Gross <jgross@suse.com>
---
V6:
- new patch
V7:
- add comment (Jan Beulich)
---
 xen/common/event_channel.c | 25 ++++++++++++++++++++++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 8db2ca4ba2..46281b16ce 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -979,6 +979,7 @@ void send_global_virq(uint32_t virq)
 int set_global_virq_handler(struct domain *d, uint32_t virq)
 {
     struct domain *old;
+    int rc = 0;
 
     if (virq >= NR_VIRQS)
         return -EINVAL;
@@ -992,14 +993,32 @@ int set_global_virq_handler(struct domain *d, uint32_t virq)
         return -EINVAL;
 
     spin_lock(&global_virq_handlers_lock);
-    old = global_virq_handlers[virq];
-    global_virq_handlers[virq] = d;
+
+    /*
+     * Note that this check won't guarantee that a domain just going down can't
+     * be set as the handling domain of a virq, as the is_dying indicator might
+     * change just after testing it.
+     * This isn't going to be a major problem, as clear_global_virq_handlers()
+     * is guaranteed to run afterwards and it will reset the handling domain
+     * for the virq to the hardware domain.
+     */
+    if ( d->is_dying != DOMDYING_alive )
+    {
+        old = d;
+        rc = -EINVAL;
+    }
+    else
+    {
+        old = global_virq_handlers[virq];
+        global_virq_handlers[virq] = d;
+    }
+
     spin_unlock(&global_virq_handlers_lock);
 
     if (old != NULL)
         put_domain(old);
 
-    return 0;
+    return rc;
 }
 
 static void clear_global_virq_handlers(struct domain *d)
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 10:59:57 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 10:59:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868106.1279657 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVqGa-0003pm-T4; Thu, 09 Jan 2025 10:59:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868106.1279657; Thu, 09 Jan 2025 10:59:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVqGa-0003pf-Pt; Thu, 09 Jan 2025 10:59:56 +0000
Received: by outflank-mailman (input) for mailman id 868106;
 Thu, 09 Jan 2025 10:59:55 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=vJOs=UB=suse.com=jgross@srs-se1.protection.inumbo.net>)
 id 1tVqGZ-0003VB-RH
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 10:59:55 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de
 [2a07:de40:b251:101:10:150:64:1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id db40f77d-ce78-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 11:59:54 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id B25E421120;
 Thu,  9 Jan 2025 10:59:52 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 6CBC0139AB;
 Thu,  9 Jan 2025 10:59:52 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id utUfGSisf2f1HAAAD6G6ig
 (envelope-from <jgross@suse.com>); Thu, 09 Jan 2025 10:59:52 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: db40f77d-ce78-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1736420393; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=5p5IyWPyTuIHb0h9GGipzK1yvNuuVibrJGPX4pXZKbw=;
	b=I9+XVLcxWKDKEVbFvuUQaC2jw5P1eMsLfWhOp0Vcqa3DQhDstH5hi46Ef74WaZb16DS+9O
	qniAidnzA8fCrMxUlOXIBSUyHGiSudyJu80AklLxbmU8y+FJ3zUhqbK18Gygac8DiZduVF
	Qk0f1A3D0YpzKXYtk0WQSuNjyHfqQfY=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1736420392; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=5p5IyWPyTuIHb0h9GGipzK1yvNuuVibrJGPX4pXZKbw=;
	b=CdBaX8ShhnWukCa8y3lc1dRQ7gtFe+hCJH32O4dORNRnuTN6+SkOX9sCLqR9S+HUXiPEI8
	Psl0LqkPcLvQfkTnIkuWRxkYw4gxgrfpvpn62NKwFo+u9sc6aMM8gwgHD4hm72w5sUKJG0
	+x9a1kR5sJb1VjDwI0faBCiWIMX5PIY=
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross <jgross@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v7 2/7] xen/events: don't allow binding a global virq from any domain
Date: Thu,  9 Jan 2025 11:59:30 +0100
Message-ID: <20250109105935.23585-3-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250109105935.23585-1-jgross@suse.com>
References: <20250109105935.23585-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Level: 
X-Spamd-Result: default: False [-2.80 / 50.00];
	BAYES_HAM(-3.00)[99.99%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_SEVEN(0.00)[9];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MIME_TRACE(0.00)[0:+];
	ARC_NA(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:email,suse.com:mid,imap1.dmz-prg2.suse.org:helo];
	RCVD_TLS_ALL(0.00)[]
X-Spam-Score: -2.80
X-Spam-Flag: NO

Today Xen will happily allow binding a global virq by a domain which
isn't configured to receive it. This won't result in any bad actions,
but the bind will appear to have succeeded with no event ever being
received by that event channel.

Instead of allowing the bind, error out if the domain isn't set to
handle that virq. Note that this check is inside the write_lock() on
purpose, as a future patch will put a related check into
set_global_virq_handler() with the addition of using the same lock.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
V6:
- new patch
V7:
- move handling domain check inside locked region (Jan Beulich)
- style fix (Jan Beulich)
---
 xen/common/event_channel.c | 21 +++++++++++++++++----
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 46281b16ce..cd6f5a1211 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -120,6 +120,13 @@ static uint8_t get_xen_consumer(xen_event_channel_notification_t fn)
 /* Get the notification function for a given Xen-bound event channel. */
 #define xen_notification_fn(e) (xen_consumers[(e)->xen_consumer-1])
 
+static struct domain *__read_mostly global_virq_handlers[NR_VIRQS];
+
+static struct domain *get_global_virq_handler(unsigned int virq)
+{
+    return global_virq_handlers[virq] ?: hardware_domain;
+}
+
 static bool virq_is_global(unsigned int virq)
 {
     switch ( virq )
@@ -469,6 +476,7 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind, evtchn_port_t port)
     struct domain *d = current->domain;
     int            virq = bind->virq, vcpu = bind->vcpu;
     int            rc = 0;
+    bool           is_global;
 
     if ( (virq < 0) || (virq >= ARRAY_SIZE(v->virq_to_evtchn)) )
         return -EINVAL;
@@ -478,8 +486,9 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind, evtchn_port_t port)
     * speculative execution.
     */
     virq = array_index_nospec(virq, ARRAY_SIZE(v->virq_to_evtchn));
+    is_global = virq_is_global(virq);
 
-    if ( virq_is_global(virq) && (vcpu != 0) )
+    if ( is_global && vcpu != 0 )
         return -EINVAL;
 
     if ( (v = domain_vcpu(d, vcpu)) == NULL )
@@ -487,6 +496,12 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind, evtchn_port_t port)
 
     write_lock(&d->event_lock);
 
+    if ( is_global && get_global_virq_handler(virq) != d )
+    {
+        rc = -EBUSY;
+        goto out;
+    }
+
     if ( read_atomic(&v->virq_to_evtchn[virq]) )
     {
         rc = -EEXIST;
@@ -965,15 +980,13 @@ void send_guest_pirq(struct domain *d, const struct pirq *pirq)
     }
 }
 
-static struct domain *global_virq_handlers[NR_VIRQS] __read_mostly;
-
 static DEFINE_SPINLOCK(global_virq_handlers_lock);
 
 void send_global_virq(uint32_t virq)
 {
     ASSERT(virq_is_global(virq));
 
-    send_guest_global_virq(global_virq_handlers[virq] ?: hardware_domain, virq);
+    send_guest_global_virq(get_global_virq_handler(virq), virq);
 }
 
 int set_global_virq_handler(struct domain *d, uint32_t virq)
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 10:59:58 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 10:59:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868107.1279666 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVqGc-000465-8o; Thu, 09 Jan 2025 10:59:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868107.1279666; Thu, 09 Jan 2025 10:59:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVqGc-00045w-62; Thu, 09 Jan 2025 10:59:58 +0000
Received: by outflank-mailman (input) for mailman id 868107;
 Thu, 09 Jan 2025 10:59:56 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <anthony@xenproject.org>) id 1tVqGa-0003ot-7R
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 10:59:56 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <anthony@xenproject.org>) id 1tVqGU-00Ckur-38;
 Thu, 09 Jan 2025 10:59:51 +0000
Received: from lfbn-gre-1-248-145.w90-112.abo.wanadoo.fr ([90.112.205.145]
 helo=l14) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from <anthony@xenproject.org>) id 1tVqGU-009H4r-2j;
 Thu, 09 Jan 2025 10:59:51 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding:
	Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date;
	bh=Xb8WmGVRb/vr/z5nwf4UmXY3kfsCsZcEmJes/p0baWo=; b=ghRRgBC3k/9uFoYqGU8pKpLzEL
	LnxzcjNJZxalmdPHZz3imf+etNf2Lu0rvndDrdIVCEIFVFV4iXiJdkhqW3/InpA8M9r2M8Y8bHHdK
	wm+dk2HNMDKVolfJP+CBYaMILNQ2dQe7dobqc3tcRBSGSrochTA2alblX0PkQITE8oSA=;
Date: Thu, 9 Jan 2025 11:59:48 +0100
From: Anthony PERARD <anthony@xenproject.org>
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: qemu-devel@nongnu.org, Stefano Stabellini <sstabellini@kernel.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	=?iso-8859-1?Q?Marc-Andr=E9?= Lureau <marcandre.lureau@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH 2/2] xen: do not use '%ms' scanf specifier
Message-ID: <Z3-sJMXpiFUoATHz@l14>
References: <20250107093140.86180-1-roger.pau@citrix.com>
 <20250107093140.86180-3-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250107093140.86180-3-roger.pau@citrix.com>

On Tue, Jan 07, 2025 at 10:31:40AM +0100, Roger Pau Monne wrote:
> The 'm' parameter used to request auto-allocation of the destination variable
> is not supported on FreeBSD, and as such leads to failures to parse.
> 
> What's more, the current usage of '%ms' with xs_node_scanf() is pointless, as
> it just leads to a double allocation of the same string.  Instead use
> qemu_xen_xs_read() to read the whole xenstore node.
> 
> Fixes: a783f8ad4ec9 ('xen: add a mechanism to automatically create XenDevice-s...')
> Fixes: 9b7737469080 ('hw/xen: update Xen console to XenDevice model')
> Signed-off-by: Roger Pau Monn� <roger.pau@citrix.com>
> ---
>  hw/char/xen_console.c | 11 +++++++++--
>  hw/xen/xen-bus.c      |  7 +++++--
>  2 files changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
> index af706c7ef440..18afd214c2f6 100644
> --- a/hw/char/xen_console.c
> +++ b/hw/char/xen_console.c
> @@ -531,6 +531,7 @@ static void xen_console_device_create(XenBackendInstance *backend,
>      const char *name = xen_backend_get_name(backend);
>      unsigned long number;
>      char *fe = NULL, *type = NULL, *output = NULL;
> +    const char *node_path;

Is "const" correct when we are changing to which string `node_path` is
pointing at? Also, why "const"? Also, compiler complains that we can't
free a "const something*".

>      char label[32];
>      XenDevice *xendev = NULL;
>      XenConsole *con;
> @@ -550,7 +551,10 @@ static void xen_console_device_create(XenBackendInstance *backend,
>          goto fail;
>      }
>  
> -    if (xs_node_scanf(xsh, XBT_NULL, fe, "type", errp, "%ms", &type) != 1) {
> +    node_path = g_strdup_printf("%s/type", fe);
> +    type = qemu_xen_xs_read(xsh, XBT_NULL, node_path, NULL);
> +    g_free(node_path);

I feel like we want "xs_node_read()" which would be similair to
xs_node_vscanf() but would simply return the result of
qemu_xen_xs_read(). This would avoid the need format of the node path in
several place in the code. But it's OK like that as well.

Cheers,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 11:00:01 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 11:00:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868110.1279678 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVqGf-0004TF-L9; Thu, 09 Jan 2025 11:00:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868110.1279678; Thu, 09 Jan 2025 11:00:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVqGf-0004Rm-F5; Thu, 09 Jan 2025 11:00:01 +0000
Received: by outflank-mailman (input) for mailman id 868110;
 Thu, 09 Jan 2025 11:00:00 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=vJOs=UB=suse.com=jgross@srs-se1.protection.inumbo.net>)
 id 1tVqGe-0003VB-5p
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 11:00:00 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ddf6c193-ce78-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 11:59:58 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id 62BB21F393;
 Thu,  9 Jan 2025 10:59:58 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 1B073139AB;
 Thu,  9 Jan 2025 10:59:58 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id bdcVBS6sf2cBHQAAD6G6ig
 (envelope-from <jgross@suse.com>); Thu, 09 Jan 2025 10:59:58 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ddf6c193-ce78-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1736420398; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=g9fM0R3rr4pnSw+2kXqv7pyWo8NS0rOHw9Y3B9boDRs=;
	b=BepEfmE9h6JLK+4zoc0ZwVB6hyIpIFbFhkdJukXnYYvtKxE/7KKu0H16wxlcbGik9meBk1
	PNKlkJtc7h+aYgMPGWPfsZoixdLUS6WWjcZo93M0ygJ1vOlnryY3HuYT5IrhRIBY9aVd6F
	JVAmx/69DTHaCkCF/f7mVZAPpUzBKns=
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=BepEfmE9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1736420398; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=g9fM0R3rr4pnSw+2kXqv7pyWo8NS0rOHw9Y3B9boDRs=;
	b=BepEfmE9h6JLK+4zoc0ZwVB6hyIpIFbFhkdJukXnYYvtKxE/7KKu0H16wxlcbGik9meBk1
	PNKlkJtc7h+aYgMPGWPfsZoixdLUS6WWjcZo93M0ygJ1vOlnryY3HuYT5IrhRIBY9aVd6F
	JVAmx/69DTHaCkCF/f7mVZAPpUzBKns=
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross <jgross@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v7 3/7] xen/events: allow setting of global virq handler only for unbound virqs
Date: Thu,  9 Jan 2025 11:59:31 +0100
Message-ID: <20250109105935.23585-4-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250109105935.23585-1-jgross@suse.com>
References: <20250109105935.23585-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 62BB21F393
X-Spam-Level: 
X-Spamd-Result: default: False [-3.01 / 50.00];
	BAYES_HAM(-3.00)[99.99%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:email,suse.com:dkim,suse.com:mid,imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ASN(0.00)[asn:25478, ipnet:::/0, country:RU];
	MIME_TRACE(0.00)[0:+];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_SEVEN(0.00)[9];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	RCVD_COUNT_TWO(0.00)[2];
	RCVD_TLS_ALL(0.00)[];
	TO_DN_SOME(0.00)[];
	DKIM_TRACE(0.00)[suse.com:+]
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Rspamd-Action: no action
X-Spam-Score: -3.01
X-Spam-Flag: NO

XEN_DOMCTL_set_virq_handler will happily steal a global virq from the
current domain having bound it and assign it to another domain. The
former domain will just never receive any further events for that
virq without knowing what happened.

Change the behavior to allow XEN_DOMCTL_set_virq_handler only if the
virq in question is not bound by the current domain allowed to use it.

Currently the only user of XEN_DOMCTL_set_virq_handler in the Xen code
base is init-xenstore-domain, so changing the behavior like above will
not cause any problems.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
V6:
- new patch
---
 xen/common/event_channel.c | 20 ++++++++++++++++++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index cd6f5a1211..4dba59efa2 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -991,7 +991,8 @@ void send_global_virq(uint32_t virq)
 
 int set_global_virq_handler(struct domain *d, uint32_t virq)
 {
-    struct domain *old;
+    struct domain *old, *hdl;
+    const struct vcpu *v;
     int rc = 0;
 
     if (virq >= NR_VIRQS)
@@ -1023,7 +1024,22 @@ int set_global_virq_handler(struct domain *d, uint32_t virq)
     else
     {
         old = global_virq_handlers[virq];
-        global_virq_handlers[virq] = d;
+        hdl = get_global_virq_handler(virq);
+        if ( hdl != d )
+        {
+            read_lock(&hdl->event_lock);
+
+            v = hdl->vcpu[0];
+            if ( v && read_atomic(&v->virq_to_evtchn[virq]) )
+            {
+                rc = -EBUSY;
+                old = d;
+            }
+            else
+                global_virq_handlers[virq] = d;
+
+            read_unlock(&hdl->event_lock);
+        }
     }
 
     spin_unlock(&global_virq_handlers_lock);
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 11:00:07 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 11:00:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868115.1279688 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVqGk-0005hP-TR; Thu, 09 Jan 2025 11:00:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868115.1279688; Thu, 09 Jan 2025 11:00:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVqGk-0005go-NE; Thu, 09 Jan 2025 11:00:06 +0000
Received: by outflank-mailman (input) for mailman id 868115;
 Thu, 09 Jan 2025 11:00:06 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=vJOs=UB=suse.com=jgross@srs-se1.protection.inumbo.net>)
 id 1tVqGk-0003VB-1b
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 11:00:06 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e1651f83-ce78-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 12:00:04 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id 186EA1F385;
 Thu,  9 Jan 2025 11:00:04 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id C4523139AB;
 Thu,  9 Jan 2025 11:00:03 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id ct15LjOsf2cjHQAAD6G6ig
 (envelope-from <jgross@suse.com>); Thu, 09 Jan 2025 11:00:03 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e1651f83-ce78-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1736420404; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=xqYBhawCJNy34d3yBIt4dx0gviDtzcMtQhpKvtgDvyc=;
	b=bciHdtWO1EvDZleXsE97/TIEHghms2BTf0gVOWkRuUPvY7f6Vx0fMhYllp263L/AerP3wS
	zDxb+RbP3GYFqkmyEEKXkm4gdcxMJEw/EYdtqsMU8M7+mEXytTgvfb6oBa32rHrFDZZxUT
	9BzGtLvVLyjg5pbZIXEEo1lUkhO0VGQ=
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1736420404; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=xqYBhawCJNy34d3yBIt4dx0gviDtzcMtQhpKvtgDvyc=;
	b=bciHdtWO1EvDZleXsE97/TIEHghms2BTf0gVOWkRuUPvY7f6Vx0fMhYllp263L/AerP3wS
	zDxb+RbP3GYFqkmyEEKXkm4gdcxMJEw/EYdtqsMU8M7+mEXytTgvfb6oBa32rHrFDZZxUT
	9BzGtLvVLyjg5pbZIXEEo1lUkhO0VGQ=
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross <jgross@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v7 4/7] xen: add bitmap to indicate per-domain state changes
Date: Thu,  9 Jan 2025 11:59:32 +0100
Message-ID: <20250109105935.23585-5-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250109105935.23585-1-jgross@suse.com>
References: <20250109105935.23585-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Level: 
X-Spamd-Result: default: False [-2.80 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_SEVEN(0.00)[9];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MIME_TRACE(0.00)[0:+];
	ARC_NA(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,suse.com:email,suse.com:mid];
	RCVD_TLS_ALL(0.00)[]
X-Spam-Score: -2.80
X-Spam-Flag: NO

Add a bitmap with one bit per possible domid indicating the respective
domain has changed its state (created, deleted, dying, crashed,
shutdown).

Registering the VIRQ_DOM_EXC event will result in setting the bits for
all existing domains and resetting all other bits.

As the usage of this bitmap is tightly coupled with the VIRQ_DOM_EXC
event, it is meant to be used only by a single consumer in the system,
just like the VIRQ_DOM_EXC event.

Resetting a bit will be done in a future patch.

This information is needed for Xenstore to keep track of all domains.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
V2:
- use DOMID_FIRST_RESERVED instead of DOMID_MASK + 1 (Jan Beulich)
- use const (Jan Beulich)
- move call of domain_reset_states() into evtchn_bind_virq() (Jan Beulich)
- dynamically allocate dom_state_changed bitmap (Jan Beulich)
V3:
- use xvzalloc_array() (Jan Beulich)
- don't rename existing label (Jan Beulich)
V4:
- add __read_mostly (Jan Beulich)
- use __set_bit() (Jan Beulich)
- fix error handling in evtchn_bind_virq() (Jan Beulich)
V5:
- domain_init_states() may be called only if evtchn_bind_virq() has been
  called validly (Jan Beulich)
V6:
- guard dom_state_changed bitmap with d->event_lock (Jan Beulich)
V7:
- still use __set_bit() at one place (Jan Beulich)
- use rw_is_write_locked_by_me() (Jan Beulich)
---
 xen/common/domain.c        | 51 ++++++++++++++++++++++++++++++++++++++
 xen/common/event_channel.c | 31 +++++++++++++++++++++++
 xen/include/xen/event.h    |  4 +++
 xen/include/xen/sched.h    |  3 +++
 4 files changed, 89 insertions(+)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 0c4cc77111..1c1d6da885 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -35,6 +35,7 @@
 #include <xen/irq.h>
 #include <xen/argo.h>
 #include <xen/llc-coloring.h>
+#include <xen/xvmalloc.h>
 #include <asm/p2m.h>
 #include <asm/processor.h>
 #include <public/sched.h>
@@ -139,6 +140,51 @@ bool __read_mostly vmtrace_available;
 
 bool __read_mostly vpmu_is_available;
 
+static unsigned long *__read_mostly dom_state_changed;
+
+int domain_init_states(void)
+{
+    const struct domain *d;
+
+    ASSERT(!dom_state_changed);
+    ASSERT(rw_is_write_locked_by_me(&current->domain->event_lock));
+
+    dom_state_changed = xvzalloc_array(unsigned long,
+                                       BITS_TO_LONGS(DOMID_FIRST_RESERVED));
+    if ( !dom_state_changed )
+        return -ENOMEM;
+
+    rcu_read_lock(&domlist_read_lock);
+
+    for_each_domain ( d )
+        __set_bit(d->domain_id, dom_state_changed);
+
+    rcu_read_unlock(&domlist_read_lock);
+
+    return 0;
+}
+
+void domain_deinit_states(const struct domain *d)
+{
+    ASSERT(rw_is_write_locked_by_me(&d->event_lock));
+
+    XVFREE(dom_state_changed);
+}
+
+static void domain_changed_state(const struct domain *d)
+{
+    struct domain *hdl;
+
+    hdl = lock_dom_exc_handler();
+    if ( unlikely(!hdl) )
+        return;
+
+    if ( dom_state_changed )
+        set_bit(d->domain_id, dom_state_changed);
+
+    unlock_dom_exc_handler(hdl);
+}
+
 static void __domain_finalise_shutdown(struct domain *d)
 {
     struct vcpu *v;
@@ -153,6 +199,7 @@ static void __domain_finalise_shutdown(struct domain *d)
             return;
 
     d->is_shut_down = 1;
+    domain_changed_state(d);
     if ( (d->shutdown_code == SHUTDOWN_suspend) && d->suspend_evtchn )
         evtchn_send(d, d->suspend_evtchn);
     else
@@ -840,6 +887,7 @@ struct domain *domain_create(domid_t domid,
      */
     domlist_insert(d);
 
+    domain_changed_state(d);
     memcpy(d->handle, config->handle, sizeof(d->handle));
 
     return d;
@@ -1105,6 +1153,7 @@ int domain_kill(struct domain *d)
         /* Mem event cleanup has to go here because the rings 
          * have to be put before we call put_domain. */
         vm_event_cleanup(d);
+        domain_changed_state(d);
         put_domain(d);
         send_global_virq(VIRQ_DOM_EXC);
         /* fallthrough */
@@ -1294,6 +1343,8 @@ static void cf_check complete_domain_destroy(struct rcu_head *head)
 
     xfree(d->vcpu);
 
+    domain_changed_state(d);
+
     _domain_destroy(d);
 
     send_global_virq(VIRQ_DOM_EXC);
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 4dba59efa2..4ee6b6b4ce 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -509,10 +509,18 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind, evtchn_port_t port)
         goto out;
     }
 
+    if ( virq == VIRQ_DOM_EXC )
+    {
+        rc = domain_init_states();
+        if ( rc )
+            goto out;
+    }
+
     port = rc = evtchn_get_port(d, port);
     if ( rc < 0 )
     {
         gdprintk(XENLOG_WARNING, "EVTCHNOP failure: error %d\n", rc);
+        domain_deinit_states(d);
         goto out;
     }
 
@@ -745,6 +753,9 @@ int evtchn_close(struct domain *d1, int port1, bool guest)
         struct vcpu *v;
         unsigned long flags;
 
+        if ( chn1->u.virq == VIRQ_DOM_EXC )
+            domain_deinit_states(d1);
+
         v = d1->vcpu[virq_is_global(chn1->u.virq) ? 0 : chn1->notify_vcpu_id];
 
         write_lock_irqsave(&v->virq_lock, flags);
@@ -1075,6 +1086,26 @@ static void clear_global_virq_handlers(struct domain *d)
     }
 }
 
+struct domain *lock_dom_exc_handler(void)
+{
+    struct domain *d;
+
+    d = get_global_virq_handler(VIRQ_DOM_EXC);
+    if ( unlikely(!get_domain(d)) )
+        return NULL;
+
+    read_lock(&d->event_lock);
+
+    return d;
+}
+
+void unlock_dom_exc_handler(struct domain *d)
+{
+    read_unlock(&d->event_lock);
+
+    put_domain(d);
+}
+
 int evtchn_status(evtchn_status_t *status)
 {
     struct domain   *d;
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 48b79f3d62..5c0ba90c9f 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -100,6 +100,10 @@ bool evtchn_virq_enabled(const struct vcpu *v, unsigned int virq);
 /* Notify remote end of a Xen-attached event channel.*/
 void notify_via_xen_event_channel(struct domain *ld, int lport);
 
+/* Lock/unlock of VIRQ_DOM_EXC associated data (read_lock(d->event_lock)). */
+struct domain *lock_dom_exc_handler(void);
+void unlock_dom_exc_handler(struct domain *d);
+
 /*
  * Internal event channel object storage.
  *
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 037c83fda2..9d9b89ec27 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -805,6 +805,9 @@ void domain_resume(struct domain *d);
 
 int domain_soft_reset(struct domain *d, bool resuming);
 
+int domain_init_states(void);
+void domain_deinit_states(const struct domain *d);
+
 int vcpu_start_shutdown_deferral(struct vcpu *v);
 void vcpu_end_shutdown_deferral(struct vcpu *v);
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 11:00:13 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 11:00:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868124.1279697 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVqGr-0006Sd-2X; Thu, 09 Jan 2025 11:00:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868124.1279697; Thu, 09 Jan 2025 11:00:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVqGq-0006SQ-VD; Thu, 09 Jan 2025 11:00:12 +0000
Received: by outflank-mailman (input) for mailman id 868124;
 Thu, 09 Jan 2025 11:00: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 <SRS0=vJOs=UB=suse.com=jgross@srs-se1.protection.inumbo.net>)
 id 1tVqGp-0003VB-SY
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 11:00:11 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e4c611ad-ce78-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 12:00:10 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id C4B5F21120;
 Thu,  9 Jan 2025 11:00:09 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 7848C139AB;
 Thu,  9 Jan 2025 11:00:09 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id m3DrGzmsf2c1HQAAD6G6ig
 (envelope-from <jgross@suse.com>); Thu, 09 Jan 2025 11:00:09 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e4c611ad-ce78-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1736420409; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=wNJv89SbG8W1IqBw6iO0McU8lWeqwTep/2l+jjUad8Y=;
	b=ElwVOQkqS7uhWWIWDd7qcjxXZbCpCPTp+U4Um8YAWUM2hs7HELnFCKMV+j7eGJjDS15y6o
	HtC3uiTKJaxeBfMx0IoJUsMIG1kkzEOr6Wa3pZMQazwGNUbill6x/UwppOh9fqkGZwpQ3j
	8hDypQ8MNS63my4nlx69GR/WmY920Kw=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1736420409; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=wNJv89SbG8W1IqBw6iO0McU8lWeqwTep/2l+jjUad8Y=;
	b=ElwVOQkqS7uhWWIWDd7qcjxXZbCpCPTp+U4Um8YAWUM2hs7HELnFCKMV+j7eGJjDS15y6o
	HtC3uiTKJaxeBfMx0IoJUsMIG1kkzEOr6Wa3pZMQazwGNUbill6x/UwppOh9fqkGZwpQ3j
	8hDypQ8MNS63my4nlx69GR/WmY920Kw=
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross <jgross@suse.com>,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v7 5/7] xen: add new domctl get_changed_domain
Date: Thu,  9 Jan 2025 11:59:33 +0100
Message-ID: <20250109105935.23585-6-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250109105935.23585-1-jgross@suse.com>
References: <20250109105935.23585-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Level: 
X-Spamd-Result: default: False [-2.80 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_SEVEN(0.00)[10];
	TO_DN_SOME(0.00)[];
	MIME_TRACE(0.00)[0:+];
	ARC_NA(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	R_RATELIMIT(0.00)[to_ip_from(RLme6mccyyenyxxgt1bwti8hnf)];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:email,suse.com:mid,imap1.dmz-prg2.suse.org:helo];
	RCVD_TLS_ALL(0.00)[]
X-Spam-Score: -2.80
X-Spam-Flag: NO

Add a new domctl sub-function to get data of a domain having changed
state (this is needed by Xenstore).

The returned state just contains the domid, the domain unique id,
and some flags (existing, shutdown, dying).

In order to enable Xenstore stubdom being built for multiple Xen
versions, make this domctl stable.  For stable domctls the
interface_version is always 0.

Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>
---
V1:
- use a domctl subop for the new interface (Jan Beulich)
V2:
- fix XSM hooks (Daniel P. Smith)
- remove versioning of stable sub-ops (Jan Beulich)
- use domctl.domain for retuning domid of a changed domain (Jan Beulich)
- simplify locking in get_domain_state() (Jan Beulich)
- undo stray change in event_channel.c (Jan Beulich)
V3:
- have disjunct states "dying" and "dead" (Jan Beulich)
- check padding fields to be 0 (Jan Beulich)
- drop memset() (Jan Beulich)
V4:
- add locking in get_domain_state() (Jan Beulich)
- only allow querying domain having changed state by domain receiving
  VIRQ_DOM_EXC events (Jan Beulich)
V5:
- use memset() (Jan Beulich)
V7:
- modify test for domain handling VIRQ_DOM_EXC, allowing to drop
  domain_handles_global_virq() (Jan Beulich)
---
 tools/flask/policy/modules/dom0.te     |  1 +
 tools/flask/policy/modules/xen.if      |  5 +-
 tools/flask/policy/modules/xenstore.te |  1 +
 xen/common/domain.c                    | 74 ++++++++++++++++++++++++++
 xen/common/domctl.c                    | 18 ++++++-
 xen/include/public/domctl.h            | 26 +++++++++
 xen/include/xen/sched.h                |  2 +
 xen/include/xsm/dummy.h                |  8 +++
 xen/include/xsm/xsm.h                  |  6 +++
 xen/xsm/dummy.c                        |  1 +
 xen/xsm/flask/hooks.c                  |  7 +++
 xen/xsm/flask/policy/access_vectors    |  2 +
 12 files changed, 148 insertions(+), 3 deletions(-)

diff --git a/tools/flask/policy/modules/dom0.te b/tools/flask/policy/modules/dom0.te
index f148bfbf27..ccadbd6469 100644
--- a/tools/flask/policy/modules/dom0.te
+++ b/tools/flask/policy/modules/dom0.te
@@ -41,6 +41,7 @@ allow dom0_t dom0_t:domain {
 allow dom0_t dom0_t:domain2 {
 	set_cpu_policy gettsc settsc setscheduler set_vnumainfo
 	get_vnumainfo psr_cmt_op psr_alloc get_cpu_policy dt_overlay
+	get_domain_state
 };
 allow dom0_t dom0_t:resource { add remove };
 
diff --git a/tools/flask/policy/modules/xen.if b/tools/flask/policy/modules/xen.if
index f7cf7c43c8..cff51febbf 100644
--- a/tools/flask/policy/modules/xen.if
+++ b/tools/flask/policy/modules/xen.if
@@ -54,7 +54,8 @@ define(`create_domain_common', `
 	allow $1 $2:domain2 { set_cpu_policy settsc setscheduler setclaim
 			set_vnumainfo get_vnumainfo cacheflush
 			psr_cmt_op psr_alloc soft_reset
-			resource_map get_cpu_policy vuart_op set_llc_colors };
+			resource_map get_cpu_policy vuart_op set_llc_colors
+			get_domain_state };
 	allow $1 $2:security check_context;
 	allow $1 $2:shadow enable;
 	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op updatemp };
@@ -94,7 +95,7 @@ define(`manage_domain', `
 			getaddrsize pause unpause trigger shutdown destroy
 			setaffinity setdomainmaxmem getscheduler resume
 			setpodtarget getpodtarget getpagingmempool setpagingmempool };
-    allow $1 $2:domain2 { set_vnumainfo dt_overlay };
+    allow $1 $2:domain2 { set_vnumainfo dt_overlay get_domain_state };
 ')
 
 # migrate_domain_out(priv, target)
diff --git a/tools/flask/policy/modules/xenstore.te b/tools/flask/policy/modules/xenstore.te
index 519566ab81..49de53ebe2 100644
--- a/tools/flask/policy/modules/xenstore.te
+++ b/tools/flask/policy/modules/xenstore.te
@@ -13,6 +13,7 @@ allow dom0_t xenstore_t:domain set_virq_handler;
 allow xenstore_t xen_t:xen writeconsole;
 # Xenstore queries domaininfo on all domains
 allow xenstore_t domain_type:domain getdomaininfo;
+allow xenstore_t domain_type:domain2 get_domain_state;
 
 # As a shortcut, the following 3 rules are used instead of adding a domain_comms
 # rule between xenstore_t and every domain type that talks to xenstore
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 1c1d6da885..b887c60ecc 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -185,6 +185,80 @@ static void domain_changed_state(const struct domain *d)
     unlock_dom_exc_handler(hdl);
 }
 
+static void set_domain_state_info(struct xen_domctl_get_domain_state *info,
+                                  const struct domain *d)
+{
+    info->state = XEN_DOMCTL_GETDOMSTATE_STATE_EXIST;
+    if ( d->is_shut_down )
+        info->state |= XEN_DOMCTL_GETDOMSTATE_STATE_SHUTDOWN;
+    if ( d->is_dying == DOMDYING_dying )
+        info->state |= XEN_DOMCTL_GETDOMSTATE_STATE_DYING;
+    if ( d->is_dying == DOMDYING_dead )
+        info->state |= XEN_DOMCTL_GETDOMSTATE_STATE_DEAD;
+    info->unique_id = d->unique_id;
+}
+
+int get_domain_state(struct xen_domctl_get_domain_state *info, struct domain *d,
+                     domid_t *domid)
+{
+    unsigned int dom;
+    int rc = -ENOENT;
+    struct domain *hdl;
+
+    if ( info->pad0 || info->pad1 )
+        return -EINVAL;
+
+    if ( d )
+    {
+        set_domain_state_info(info, d);
+
+        return 0;
+    }
+
+    hdl = lock_dom_exc_handler();
+
+    /*
+     * Only domain registered for VIRQ_DOM_EXC event is allowed to query
+     * domains having changed state.
+     */
+    if ( current->domain != hdl )
+    {
+        rc = -EACCES;
+        goto out;
+    }
+
+    while ( dom_state_changed )
+    {
+        dom = find_first_bit(dom_state_changed, DOMID_MASK + 1);
+        if ( dom >= DOMID_FIRST_RESERVED )
+            break;
+        if ( test_and_clear_bit(dom, dom_state_changed) )
+        {
+            *domid = dom;
+
+            d = rcu_lock_domain_by_id(dom);
+
+            if ( d )
+            {
+                set_domain_state_info(info, d);
+
+                rcu_unlock_domain(d);
+            }
+            else
+                memset(info, 0, sizeof(*info));
+
+            rc = 0;
+
+            break;
+        }
+    }
+
+ out:
+    unlock_dom_exc_handler(hdl);
+
+    return rc;
+}
+
 static void __domain_finalise_shutdown(struct domain *d)
 {
     struct vcpu *v;
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 05abb581a0..b897ca8723 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -279,6 +279,11 @@ static struct vnuma_info *vnuma_init(const struct xen_domctl_vnuma *uinfo,
     return ERR_PTR(ret);
 }
 
+static bool is_stable_domctl(uint32_t cmd)
+{
+    return cmd == XEN_DOMCTL_get_domain_state;
+}
+
 long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
 {
     long ret = 0;
@@ -289,7 +294,8 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
     if ( copy_from_guest(op, u_domctl, 1) )
         return -EFAULT;
 
-    if ( op->interface_version != XEN_DOMCTL_INTERFACE_VERSION )
+    if ( op->interface_version !=
+         (is_stable_domctl(op->cmd) ? 0 : XEN_DOMCTL_INTERFACE_VERSION) )
         return -EACCES;
 
     switch ( op->cmd )
@@ -310,6 +316,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
         fallthrough;
     case XEN_DOMCTL_test_assign_device:
     case XEN_DOMCTL_vm_event_op:
+    case XEN_DOMCTL_get_domain_state:
         if ( op->domain == DOMID_INVALID )
         {
             d = NULL;
@@ -876,6 +883,15 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
             ret = -EOPNOTSUPP;
         break;
 
+    case XEN_DOMCTL_get_domain_state:
+        ret = xsm_get_domain_state(XSM_XS_PRIV, d);
+        if ( ret )
+            break;
+
+        copyback = 1;
+        ret = get_domain_state(&op->u.get_domain_state, d, &op->domain);
+        break;
+
     default:
         ret = arch_do_domctl(op, d, u_domctl);
         break;
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index e2d392d1e5..5b2063eed9 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -28,6 +28,7 @@
  * Pure additions (e.g. new sub-commands) or compatible interface changes
  * (e.g. adding semantics to 0-checked input fields or data to zeroed output
  * fields) don't require a change of the version.
+ * Stable ops are NOT covered by XEN_DOMCTL_INTERFACE_VERSION!
  *
  * Last version bump: Xen 4.19
  */
@@ -1243,7 +1244,30 @@ struct xen_domctl_set_llc_colors {
     XEN_GUEST_HANDLE_64(uint32) llc_colors;
 };
 
+/*
+ * XEN_DOMCTL_get_domain_state (stable interface)
+ *
+ * Get state information of a domain.
+ *
+ * In case domain is DOMID_INVALID, return information about a domain having
+ * changed state and reset the state change indicator for that domain. This
+ * function is usable only by a domain having registered the VIRQ_DOM_EXC
+ * event (normally Xenstore).
+ * NB. xen_domctl.domain is an IN/OUT parameter for this operation.
+ */
+struct xen_domctl_get_domain_state {
+    uint16_t state;
+#define XEN_DOMCTL_GETDOMSTATE_STATE_EXIST     0x0001  /* Domain is existing. */
+#define XEN_DOMCTL_GETDOMSTATE_STATE_SHUTDOWN  0x0002  /* Shutdown finished. */
+#define XEN_DOMCTL_GETDOMSTATE_STATE_DYING     0x0004  /* Domain dying. */
+#define XEN_DOMCTL_GETDOMSTATE_STATE_DEAD      0x0008  /* Domain dead. */
+    uint16_t pad0;           /* Must be 0 on input, returned as 0. */
+    uint32_t pad1;           /* Must be 0 on input, returned as 0. */
+    uint64_t unique_id;      /* Unique domain identifier. */
+};
+
 struct xen_domctl {
+/* Stable domctl ops: interface_version is required to be 0.  */
     uint32_t cmd;
 #define XEN_DOMCTL_createdomain                   1
 #define XEN_DOMCTL_destroydomain                  2
@@ -1333,6 +1357,7 @@ struct xen_domctl {
 #define XEN_DOMCTL_dt_overlay                    87
 #define XEN_DOMCTL_gsi_permission                88
 #define XEN_DOMCTL_set_llc_colors                89
+#define XEN_DOMCTL_get_domain_state              90 /* stable interface */
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -1400,6 +1425,7 @@ struct xen_domctl {
         struct xen_domctl_dt_overlay        dt_overlay;
 #endif
         struct xen_domctl_set_llc_colors    set_llc_colors;
+        struct xen_domctl_get_domain_state  get_domain_state;
         uint8_t                             pad[128];
     } u;
 };
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 9d9b89ec27..ea63ca1c79 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -807,6 +807,8 @@ int domain_soft_reset(struct domain *d, bool resuming);
 
 int domain_init_states(void);
 void domain_deinit_states(const struct domain *d);
+int get_domain_state(struct xen_domctl_get_domain_state *info,
+                     struct domain *d, domid_t *domid);
 
 int vcpu_start_shutdown_deferral(struct vcpu *v);
 void vcpu_end_shutdown_deferral(struct vcpu *v);
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 6a2fc33c3b..a8d06de6b0 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -173,6 +173,7 @@ static XSM_INLINE int cf_check xsm_domctl(
     case XEN_DOMCTL_unbind_pt_irq:
         return xsm_default_action(XSM_DM_PRIV, current->domain, d);
     case XEN_DOMCTL_getdomaininfo:
+    case XEN_DOMCTL_get_domain_state:
         return xsm_default_action(XSM_XS_PRIV, current->domain, d);
     default:
         return xsm_default_action(XSM_PRIV, current->domain, d);
@@ -815,6 +816,13 @@ static XSM_INLINE int cf_check xsm_argo_send(
 
 #endif /* CONFIG_ARGO */
 
+static XSM_INLINE int cf_check xsm_get_domain_state(
+    XSM_DEFAULT_ARG struct domain *d)
+{
+    XSM_ASSERT_ACTION(XSM_XS_PRIV);
+    return xsm_default_action(action, current->domain, d);
+}
+
 #include <public/version.h>
 static XSM_INLINE int cf_check xsm_xen_version(XSM_DEFAULT_ARG uint32_t op)
 {
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 4dbff9d866..0689bf5c9f 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -200,6 +200,7 @@ struct xsm_ops {
     int (*argo_register_any_source)(const struct domain *d);
     int (*argo_send)(const struct domain *d, const struct domain *t);
 #endif
+    int (*get_domain_state)(struct domain *d);
 };
 
 #ifdef CONFIG_XSM
@@ -774,6 +775,11 @@ static inline int xsm_argo_send(const struct domain *d, const struct domain *t)
 
 #endif /* CONFIG_ARGO */
 
+static inline int xsm_get_domain_state(struct domain *d)
+{
+    return alternative_call(xsm_ops.get_domain_state, d);
+}
+
 #endif /* XSM_NO_WRAPPERS */
 
 #ifdef CONFIG_MULTIBOOT
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index e6ffa948f7..ce6fbdc6c5 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -148,6 +148,7 @@ static const struct xsm_ops __initconst_cf_clobber dummy_ops = {
     .argo_register_any_source      = xsm_argo_register_any_source,
     .argo_send                     = xsm_argo_send,
 #endif
+    .get_domain_state              = xsm_get_domain_state,
 };
 
 void __init xsm_fixup_ops(struct xsm_ops *ops)
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 14d84df9ca..389707a164 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -688,6 +688,7 @@ static int cf_check flask_domctl(struct domain *d, unsigned int cmd,
     case XEN_DOMCTL_memory_mapping:
     case XEN_DOMCTL_set_target:
     case XEN_DOMCTL_vm_event_op:
+    case XEN_DOMCTL_get_domain_state:
 
     /* These have individual XSM hooks (arch/../domctl.c) */
     case XEN_DOMCTL_bind_pt_irq:
@@ -1869,6 +1870,11 @@ static int cf_check flask_argo_send(
 
 #endif
 
+static int cf_check flask_get_domain_state(struct domain *d)
+{
+    return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__GET_DOMAIN_STATE);
+}
+
 static const struct xsm_ops __initconst_cf_clobber flask_ops = {
     .set_system_active = flask_set_system_active,
     .security_domaininfo = flask_security_domaininfo,
@@ -2005,6 +2011,7 @@ static const struct xsm_ops __initconst_cf_clobber flask_ops = {
     .argo_register_any_source = flask_argo_register_any_source,
     .argo_send = flask_argo_send,
 #endif
+    .get_domain_state = flask_get_domain_state,
 };
 
 const struct xsm_ops *__init flask_init(
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index 320d77706d..51a1577a66 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -257,6 +257,8 @@ class domain2
     dt_overlay
 # XEN_DOMCTL_set_llc_colors
     set_llc_colors
+# XEN_DOMCTL_get_domain_state
+    get_domain_state
 }
 
 # Similar to class domain, but primarily contains domctls related to HVM domains
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 11:01:07 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 11:01:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868151.1279707 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVqHX-0007rh-Hd; Thu, 09 Jan 2025 11:00:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868151.1279707; Thu, 09 Jan 2025 11:00:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVqHX-0007rY-Eq; Thu, 09 Jan 2025 11:00:55 +0000
Received: by outflank-mailman (input) for mailman id 868151;
 Thu, 09 Jan 2025 11:00: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 <SRS0=vJOs=UB=suse.com=jgross@srs-se1.protection.inumbo.net>)
 id 1tVqH1-0003VB-2a
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 11:00:23 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id eb7e9f1b-ce78-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 12:00:21 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id 046C621120;
 Thu,  9 Jan 2025 11:00:21 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id C2F98139AB;
 Thu,  9 Jan 2025 11:00:20 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id UE0BLkSsf2dEHQAAD6G6ig
 (envelope-from <jgross@suse.com>); Thu, 09 Jan 2025 11:00:20 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: eb7e9f1b-ce78-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1736420421; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=U4Ln9oY8teJqj0oQ6om9doDIAfM1X4V+dyEL2CQtrKA=;
	b=HAZOKL9drZ160VQ0+hgDQZuMWv7zcJY4vNrb9k5KY5hpvSYseUh6aqH4lJNvIc+4m3pu2R
	WlzrLgu9A40BIYZn8T1P51GKhdW6xCoOMUiGMDA+kWrVTWWqJ66bKAM7Sw+UcjoUEOip93
	PqBKBPnmETx/jLE5KnxfBv6ptIyavdA=
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=HAZOKL9d
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1736420421; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=U4Ln9oY8teJqj0oQ6om9doDIAfM1X4V+dyEL2CQtrKA=;
	b=HAZOKL9drZ160VQ0+hgDQZuMWv7zcJY4vNrb9k5KY5hpvSYseUh6aqH4lJNvIc+4m3pu2R
	WlzrLgu9A40BIYZn8T1P51GKhdW6xCoOMUiGMDA+kWrVTWWqJ66bKAM7Sw+UcjoUEOip93
	PqBKBPnmETx/jLE5KnxfBv6ptIyavdA=
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross <jgross@suse.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Julien Grall <julien@xen.org>
Subject: [PATCH v7 7/7] tools/xenstored: use new stable interface instead of libxenctrl
Date: Thu,  9 Jan 2025 11:59:35 +0100
Message-ID: <20250109105935.23585-8-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250109105935.23585-1-jgross@suse.com>
References: <20250109105935.23585-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 046C621120
X-Spam-Score: -3.01
X-Rspamd-Action: no action
X-Spamd-Result: default: False [-3.01 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:dkim,suse.com:mid,suse.com:email,imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo];
	ASN(0.00)[asn:25478, ipnet:::/0, country:RU];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	MIME_TRACE(0.00)[0:+];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	RCVD_COUNT_TWO(0.00)[2];
	RCVD_TLS_ALL(0.00)[];
	RCPT_COUNT_FIVE(0.00)[5];
	DKIM_TRACE(0.00)[suse.com:+]
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spam-Flag: NO
X-Spam-Level: 

Replace the current use of the unstable xc_domain_getinfo_single()
interface with the stable domctl XEN_DOMCTL_get_domain_state call
via the new libxenmanage library.

This will remove the last usage of libxenctrl by Xenstore, so update
the library dependencies accordingly.

For now only do a direct replacement without using the functionality
of obtaining information about domains having changed the state.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
---
V1:
- use library instead of direct hypercall, only replace current
  libxenctrl use case

Please note that this patch can be committed only after the related
Mini-OS patch "config: add support for libxenmanage" has gone in AND
the Mini-OS commit-id has been updated in Config.mk accordingly!

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 stubdom/Makefile                |  8 ++---
 stubdom/mini-os.mk              |  1 +
 tools/xenstored/Makefile        |  2 +-
 tools/xenstored/Makefile.common |  2 +-
 tools/xenstored/core.h          |  1 -
 tools/xenstored/domain.c        | 52 ++++++++++++---------------------
 tools/xenstored/lu.c            |  1 +
 tools/xenstored/lu_daemon.c     |  1 +
 8 files changed, 28 insertions(+), 40 deletions(-)

diff --git a/stubdom/Makefile b/stubdom/Makefile
index 2a81af28a1..ca800b243c 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -307,7 +307,7 @@ endif
 # libraries under tools/libs
 #######
 
-STUB_LIBS := toolcore toollog evtchn gnttab call foreignmemory devicemodel ctrl guest
+STUB_LIBS := toolcore toollog evtchn gnttab call foreignmemory devicemodel ctrl guest manage
 
 LIBDEP_guest := cross-zlib
 
@@ -465,7 +465,7 @@ grub: cross-polarssl grub-upstream $(CROSS_ROOT) grub-$(XEN_TARGET_ARCH)-minios-
 # xenstore
 ##########
 
-xenstore-minios.gen.cfg: APP_LIBS = gnttab evtchn toollog ctrl
+xenstore-minios.gen.cfg: APP_LIBS = gnttab evtchn toollog manage
 xenstore-minios.gen.cfg: xenstore-minios.cfg Makefile
 	$(GEN_config) >$@
 
@@ -480,7 +480,7 @@ xenstore: $(CROSS_ROOT) xenstore-minios-config.mk
 # xenstorepvh
 #############
 
-xenstorepvh-minios.gen.cfg: APP_LIBS = gnttab evtchn toollog ctrl
+xenstorepvh-minios.gen.cfg: APP_LIBS = gnttab evtchn toollog manage
 xenstorepvh-minios.gen.cfg: xenstorepvh-minios.cfg Makefile
 	$(GEN_config) >$@
 
@@ -523,7 +523,7 @@ else
 pv-grub-if-enabled:
 endif
 
-XENSTORE_DEPS := libxenevtchn libxengnttab libxenctrl
+XENSTORE_DEPS := libxenevtchn libxengnttab libxenmanage
 
 .PHONY: xenstore-stubdom
 xenstore-stubdom: mini-os-$(XEN_TARGET_ARCH)-xenstore $(XENSTORE_DEPS) xenstore
diff --git a/stubdom/mini-os.mk b/stubdom/mini-os.mk
index 7e4968e026..be32302f9e 100644
--- a/stubdom/mini-os.mk
+++ b/stubdom/mini-os.mk
@@ -13,5 +13,6 @@ GNTTAB_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/gnttab
 CALL_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/call
 FOREIGNMEMORY_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/foreignmemory
 DEVICEMODEL_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/devicemodel
+MANAGE_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/manage
 CTRL_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/ctrl
 GUEST_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/guest
diff --git a/tools/xenstored/Makefile b/tools/xenstored/Makefile
index 09adfe1d50..81c42838e0 100644
--- a/tools/xenstored/Makefile
+++ b/tools/xenstored/Makefile
@@ -5,7 +5,7 @@ include Makefile.common
 
 xenstored: LDLIBS += $(LDLIBS_libxenevtchn)
 xenstored: LDLIBS += $(LDLIBS_libxengnttab)
-xenstored: LDLIBS += $(LDLIBS_libxenctrl)
+xenstored: LDLIBS += $(LDLIBS_libxenmanage)
 xenstored: LDLIBS += -lrt
 xenstored: LDLIBS += $(SOCKET_LIBS)
 
diff --git a/tools/xenstored/Makefile.common b/tools/xenstored/Makefile.common
index 27fdb3b49e..271134fcc1 100644
--- a/tools/xenstored/Makefile.common
+++ b/tools/xenstored/Makefile.common
@@ -12,7 +12,7 @@ XENSTORED_OBJS-$(CONFIG_MiniOS) += minios.o lu_minios.o
 # Include configure output (config.h)
 CFLAGS += -include $(XEN_ROOT)/tools/config.h
 CFLAGS += $(CFLAGS_libxenevtchn)
-CFLAGS += $(CFLAGS_libxenctrl)
+CFLAGS += $(CFLAGS_libxenmanage)
 CFLAGS += $(CFLAGS_libxentoolcore)
 
 $(XENSTORED_OBJS-y): CFLAGS += $(CFLAGS_libxengnttab)
diff --git a/tools/xenstored/core.h b/tools/xenstored/core.h
index e58779e88c..632886cecf 100644
--- a/tools/xenstored/core.h
+++ b/tools/xenstored/core.h
@@ -19,7 +19,6 @@
 #ifndef _XENSTORED_CORE_H
 #define _XENSTORED_CORE_H
 
-#include <xenctrl.h>
 #include <xengnttab.h>
 
 #include <sys/types.h>
diff --git a/tools/xenstored/domain.c b/tools/xenstored/domain.c
index 64c8fd0cc3..a6506a5bb2 100644
--- a/tools/xenstored/domain.c
+++ b/tools/xenstored/domain.c
@@ -34,14 +34,15 @@
 #include "control.h"
 
 #include <xenevtchn.h>
-#include <xenctrl.h>
+#include <xenmanage.h>
+#include <xen-barrier.h>
 #include <xen/grant_table.h>
 
 #ifdef __MINIOS__
 #include <mini-os/xenbus.h>
 #endif
 
-static xc_interface **xc_handle;
+static xenmanage_handle *xm_handle;
 xengnttab_handle **xgt_handle;
 static evtchn_port_t virq_port;
 
@@ -619,32 +620,28 @@ static int destroy_domain(void *_domain)
 	return 0;
 }
 
-static bool get_domain_info(unsigned int domid, xc_domaininfo_t *dominfo)
-{
-	return xc_domain_getinfo_single(*xc_handle, domid, dominfo) == 0;
-}
-
 static int check_domain(const void *k, void *v, void *arg)
 {
-	xc_domaininfo_t dominfo;
+	unsigned int state;
 	struct connection *conn;
-	bool dom_valid;
+	int dom_invalid;
 	struct domain *domain = v;
 	bool *notify = arg;
 
-	dom_valid = get_domain_info(domain->domid, &dominfo);
+	dom_invalid = xenmanage_get_domain_info(xm_handle, domain->domid,
+						&state, NULL);
 	if (!domain->introduced) {
-		if (!dom_valid)
+		if (dom_invalid)
 			talloc_free(domain);
 		return 0;
 	}
-	if (dom_valid) {
-		if ((dominfo.flags & XEN_DOMINF_shutdown)
+	if (!dom_invalid) {
+		if ((state & XENMANAGE_GETDOMSTATE_STATE_SHUTDOWN)
 		    && !domain->shutdown) {
 			domain->shutdown = true;
 			*notify = true;
 		}
-		if (!(dominfo.flags & XEN_DOMINF_dying))
+		if (!(state & XENMANAGE_GETDOMSTATE_STATE_DEAD))
 			return 0;
 	}
 	if (domain->conn) {
@@ -786,10 +783,9 @@ static struct domain *find_or_alloc_domain(const void *ctx, unsigned int domid)
 static struct domain *find_or_alloc_existing_domain(unsigned int domid)
 {
 	struct domain *domain;
-	xc_domaininfo_t dominfo;
 
 	domain = find_domain_struct(domid);
-	if (!domain && get_domain_info(domid, &dominfo))
+	if (!domain && !xenmanage_get_domain_info(xm_handle, domid, NULL, NULL))
 		domain = alloc_domain(NULL, domid);
 
 	return domain;
@@ -1187,12 +1183,6 @@ int do_reset_watches(const void *ctx, struct connection *conn,
 	return 0;
 }
 
-static int close_xc_handle(void *_handle)
-{
-	xc_interface_close(*(xc_interface**)_handle);
-	return 0;
-}
-
 static int close_xgt_handle(void *_handle)
 {
 	xengnttab_close(*(xengnttab_handle **)_handle);
@@ -1258,15 +1248,9 @@ void domain_early_init(void)
 	if (!domhash)
 		barf_perror("Failed to allocate domain hashtable");
 
-	xc_handle = talloc(talloc_autofree_context(), xc_interface*);
-	if (!xc_handle)
-		barf_perror("Failed to allocate domain handle");
-
-	*xc_handle = xc_interface_open(0,0,0);
-	if (!*xc_handle)
-		barf_perror("Failed to open connection to hypervisor");
-
-	talloc_set_destructor(xc_handle, close_xc_handle);
+	xm_handle = xenmanage_open(NULL, 0);
+	if (!xm_handle)
+		barf_perror("Failed to open connection to libxenmanage");
 
 	xgt_handle = talloc(talloc_autofree_context(), xengnttab_handle*);
 	if (!xgt_handle)
@@ -1306,6 +1290,8 @@ void domain_deinit(void)
 {
 	if (virq_port)
 		xenevtchn_unbind(xce_handle, virq_port);
+
+	xenmanage_close(xm_handle);
 }
 
 /*
@@ -1335,13 +1321,13 @@ int domain_alloc_permrefs(struct node_perms *perms)
 {
 	unsigned int i, domid;
 	struct domain *d;
-	xc_domaininfo_t dominfo;
 
 	for (i = 0; i < perms->num; i++) {
 		domid = perms->p[i].id;
 		d = find_domain_struct(domid);
 		if (!d) {
-			if (!get_domain_info(domid, &dominfo))
+			if (xenmanage_get_domain_info(xm_handle, domid,
+						      NULL, NULL))
 				perms->p[i].perms |= XS_PERM_IGNORE;
 			else if (!alloc_domain(NULL, domid))
 				return ENOMEM;
diff --git a/tools/xenstored/lu.c b/tools/xenstored/lu.c
index bec2a84e10..4fccbbc195 100644
--- a/tools/xenstored/lu.c
+++ b/tools/xenstored/lu.c
@@ -11,6 +11,7 @@
 #include <stdlib.h>
 #include <syslog.h>
 #include <time.h>
+#include <unistd.h>
 #include <sys/mman.h>
 #include <sys/stat.h>
 
diff --git a/tools/xenstored/lu_daemon.c b/tools/xenstored/lu_daemon.c
index 6df6c80a2a..88d8d9e1b3 100644
--- a/tools/xenstored/lu_daemon.c
+++ b/tools/xenstored/lu_daemon.c
@@ -6,6 +6,7 @@
  */
 
 #include <syslog.h>
+#include <unistd.h>
 #include <sys/stat.h>
 
 #include "talloc.h"
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 11:01:20 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 11:01:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868156.1279717 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVqHw-0008RS-Q6; Thu, 09 Jan 2025 11:01:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868156.1279717; Thu, 09 Jan 2025 11:01:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVqHw-0008RL-Md; Thu, 09 Jan 2025 11:01:20 +0000
Received: by outflank-mailman (input) for mailman id 868156;
 Thu, 09 Jan 2025 11:01:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=vJOs=UB=suse.com=jgross@srs-se1.protection.inumbo.net>)
 id 1tVqGw-0003VB-I9
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 11:00:18 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e8c32858-ce78-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 12:00:16 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id 568A921120;
 Thu,  9 Jan 2025 11:00:15 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 31F3E139AB;
 Thu,  9 Jan 2025 11:00:15 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id Q/K8Cj+sf2c8HQAAD6G6ig
 (envelope-from <jgross@suse.com>); Thu, 09 Jan 2025 11:00:15 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e8c32858-ce78-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1736420416; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=J6JSRc8YlyUyRyNjaDAT1q6d2ZzULe0kJJ0JZTfWW/U=;
	b=gMoiK7znXwWE+rBHRduTyt59369fUpjn6zOILVcD3jkbDRPYGoU4GP8uJnKAVXAqPUCN0T
	+Bsyarna2Cd98epbAYvk4gOIUp9L5HqBmnXGUbw83vY7C3AOf8F/8Qb9QX667o+jP8XaVZ
	rPPWqnBvLYLLsTvGpdGJECl/0tc/ens=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1736420415; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=J6JSRc8YlyUyRyNjaDAT1q6d2ZzULe0kJJ0JZTfWW/U=;
	b=dOiMIX90rP7ycz+TI3lmqOfEeAj5tamKEYUN1DnTjPQOPOwucPPMsWOGfHYmwdAoxJ6CDm
	BV1333HxfA6j5pnmYdO9vIvK1Ln3AINeoux7rggtA6gxN6mSVDYmhWQAH6lOI6KU3ptod0
	Hj0ILphvnfu2dbHUyDtM6tv9BXX/8k0=
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross <jgross@suse.com>,
	Anthony PERARD <anthony.perard@vates.tech>
Subject: [PATCH v7 6/7] tools/libs: add a new libxenmanage library
Date: Thu,  9 Jan 2025 11:59:34 +0100
Message-ID: <20250109105935.23585-7-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250109105935.23585-1-jgross@suse.com>
References: <20250109105935.23585-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Level: 
X-Spamd-Result: default: False [-2.80 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	MIME_TRACE(0.00)[0:+];
	TO_DN_SOME(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[vates.tech:email,suse.com:email,suse.com:mid,gnu.org:url,libxenmanage.map:url,imap1.dmz-prg2.suse.org:helo];
	RCVD_TLS_ALL(0.00)[]
X-Spam-Score: -2.80
X-Spam-Flag: NO

In order to have a stable interface in user land for using stable
domctl and possibly later sysctl interfaces, add a new library
libxenmanage.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
---
V1:
- new patch
V2:
- define __XEN_TOOLS__ via Makefile (Anthony PERARD)
- use SPDX in header file (Anthony PERARD)
- change function name to xenmanage_poll_changed_domain() (Anthony PERARD)
- add short library description (Anthony PERARD)
- narrow scope of xen_domctl_get_domain_state pointer (Anthony PERARD)
V4:
- use LGPL-2.1-only SPDX identifier (Anthony PERARD)
---
 tools/include/xenmanage.h          |  92 ++++++++++++++++
 tools/libs/Makefile                |   1 +
 tools/libs/manage/Makefile         |  10 ++
 tools/libs/manage/Makefile.common  |   3 +
 tools/libs/manage/core.c           | 168 +++++++++++++++++++++++++++++
 tools/libs/manage/libxenmanage.map |   8 ++
 tools/libs/uselibs.mk              |   2 +
 7 files changed, 284 insertions(+)
 create mode 100644 tools/include/xenmanage.h
 create mode 100644 tools/libs/manage/Makefile
 create mode 100644 tools/libs/manage/Makefile.common
 create mode 100644 tools/libs/manage/core.c
 create mode 100644 tools/libs/manage/libxenmanage.map

diff --git a/tools/include/xenmanage.h b/tools/include/xenmanage.h
new file mode 100644
index 0000000000..956b7a0a44
--- /dev/null
+++ b/tools/include/xenmanage.h
@@ -0,0 +1,92 @@
+/* SPDX-License-Identifier: LGPL-2.1-only */
+/*
+ * Copyright (c) 2024 SUSE Software Solutions Germany GmbH
+ *
+ * Interfaces of libxenmanage.
+ *
+ * libxenmanage provides management functions for the host using stable
+ * hypercall interfaces.
+ */
+#ifndef XENMANAGE_H
+#define XENMANAGE_H
+
+#include <stdint.h>
+
+/* Avoid the need to #include <xentoollog.h> */
+struct xentoollog_logger;
+
+typedef struct xenmanage_handle xenmanage_handle;
+
+/*
+ * Open libxenmanage.
+ *
+ * Get a handle of the xenmanage library. The handle is required for all
+ * further operations of the library.
+ * Parameters:
+ *   logger:     Logging function to use. If NULL logging is done to stderr.
+ *   open_flags: Only 0 supported.
+ * Return value: Handle or NULL if error.
+ */
+xenmanage_handle *xenmanage_open(struct xentoollog_logger *logger,
+                                 unsigned int open_flags);
+
+/*
+ * Close libxenmanage.
+ *
+ * Return a handle of the xenmanage library.
+ * Parameters:
+ *    hdl: Handle obtained by xenmanage_open().
+ * Return value: always 0.
+ */
+int xenmanage_close(xenmanage_handle *hdl);
+
+#define XENMANAGE_GETDOMSTATE_STATE_EXIST     0x0001  /* Domain is existing. */
+#define XENMANAGE_GETDOMSTATE_STATE_SHUTDOWN  0x0002  /* Shutdown finished. */
+#define XENMANAGE_GETDOMSTATE_STATE_DYING     0x0004  /* Domain dying. */
+#define XENMANAGE_GETDOMSTATE_STATE_DEAD      0x0008  /* Domain dead. */
+
+/*
+ * Return state information of an existing domain.
+ *
+ * Returns the domain state and unique id of the given domain.
+ * Parameters:
+ *   hdl:       handle returned by xenmanage_open()
+ *   domid:     domain id of the domain to get the information for
+ *   state:     where to store the state (XENMANAGE_GETDOMSTATE_STATE_ flags,
+ *              nothing stored if NULL)
+ *   unique_id: where to store the unique id of the domain (nothing stored if
+ *              NULL)
+ * Return value: 0 if information was stored, -1 else (errno is set)
+ */
+int xenmanage_get_domain_info(xenmanage_handle *hdl, unsigned int domid,
+                              unsigned int *state, uint64_t *unique_id);
+
+/*
+ * Return information of a domain having changed state recently.
+ *
+ * Returns the domain id, state and unique id of a domain having changed
+ * state (any of the state bits was modified) since the last time information
+ * for that domain was returned by this function. Only usable by callers who
+ * have registered the VIRQ_DOM_EXC event (normally Xenstore).
+ * Parameters:
+ *   hdl:       handle returned by xenmanage_open()
+ *   domid:     where to store the domid of the domain (not NULL)
+ *   state:     where to store the state (XENMANAGE_GETDOMSTATE_STATE_ flags,
+ *              nothing stored if NULL)
+ *   unique_id: where to store the unique id of the domain (nothing stored if
+ *              NULL)
+ * Return value: 0 if information was stored, -1 else (errno is set)
+ */
+int xenmanage_poll_changed_domain(xenmanage_handle *hdl, unsigned int *domid,
+                                  unsigned int *state, uint64_t *unique_id);
+#endif /* XENMANAGE_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libs/Makefile b/tools/libs/Makefile
index 1afcd12e2b..d39516c1b3 100644
--- a/tools/libs/Makefile
+++ b/tools/libs/Makefile
@@ -12,6 +12,7 @@ SUBDIRS-y += devicemodel
 SUBDIRS-y += ctrl
 SUBDIRS-y += guest
 SUBDIRS-y += hypfs
+SUBDIRS-y += manage
 SUBDIRS-y += store
 SUBDIRS-y += stat
 SUBDIRS-$(CONFIG_Linux) += vchan
diff --git a/tools/libs/manage/Makefile b/tools/libs/manage/Makefile
new file mode 100644
index 0000000000..dbfe70d259
--- /dev/null
+++ b/tools/libs/manage/Makefile
@@ -0,0 +1,10 @@
+XEN_ROOT = $(CURDIR)/../../..
+include $(XEN_ROOT)/tools/Rules.mk
+
+MAJOR    = 1
+MINOR    = 0
+version-script := libxenmanage.map
+
+include Makefile.common
+
+include $(XEN_ROOT)/tools/libs/libs.mk
diff --git a/tools/libs/manage/Makefile.common b/tools/libs/manage/Makefile.common
new file mode 100644
index 0000000000..533ba30fba
--- /dev/null
+++ b/tools/libs/manage/Makefile.common
@@ -0,0 +1,3 @@
+CFLAGS += -D__XEN_TOOLS__
+
+OBJS-y  += core.o
diff --git a/tools/libs/manage/core.c b/tools/libs/manage/core.c
new file mode 100644
index 0000000000..8fb421df41
--- /dev/null
+++ b/tools/libs/manage/core.c
@@ -0,0 +1,168 @@
+/*
+ * Copyright (c) 2024 SUSE Software Solutions Germany GmbH
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#define _GNU_SOURCE
+
+#include <errno.h>
+#include <stdlib.h>
+#include <string.h>
+
+#include <xentoollog.h>
+#include <xenmanage.h>
+#include <xencall.h>
+#include <xentoolcore_internal.h>
+
+#include <xen/xen.h>
+#include <xen/domctl.h>
+
+struct xenmanage_handle {
+    xentoollog_logger *logger, *logger_tofree;
+    unsigned int flags;
+    xencall_handle *xcall;
+};
+
+xenmanage_handle *xenmanage_open(xentoollog_logger *logger,
+                                 unsigned int open_flags)
+{
+    xenmanage_handle *hdl = calloc(1, sizeof(*hdl));
+    int saved_errno;
+
+    if ( !hdl )
+        return NULL;
+
+    if ( open_flags )
+    {
+        errno = EINVAL;
+        goto err;
+    }
+
+    hdl->flags = open_flags;
+    hdl->logger = logger;
+    hdl->logger_tofree = NULL;
+
+    if ( !hdl->logger )
+    {
+        hdl->logger = hdl->logger_tofree =
+            (xentoollog_logger *)
+            xtl_createlogger_stdiostream(stderr, XTL_PROGRESS, 0);
+        if ( !hdl->logger )
+            goto err;
+    }
+
+    hdl->xcall = xencall_open(hdl->logger, 0);
+    if ( !hdl->xcall )
+        goto err;
+
+    return hdl;
+
+err:
+    saved_errno = errno;
+    xenmanage_close(hdl);
+    errno = saved_errno;
+
+    return NULL;
+}
+
+int xenmanage_close(xenmanage_handle *hdl)
+{
+    if ( !hdl )
+        return 0;
+
+    xencall_close(hdl->xcall);
+    xtl_logger_destroy(hdl->logger_tofree);
+    free(hdl);
+    return 0;
+}
+
+static int xenmanage_do_domctl_get_domain_state(xenmanage_handle *hdl,
+                                                unsigned int domid_in,
+                                                unsigned int *domid_out,
+                                                unsigned int *state,
+                                                uint64_t *unique_id)
+{
+    struct xen_domctl *buf;
+    int saved_errno;
+    int ret;
+
+    buf = xencall_alloc_buffer(hdl->xcall, sizeof(*buf));
+    if ( !buf )
+    {
+        errno = ENOMEM;
+        return -1;
+    }
+
+    memset(buf, 0, sizeof(*buf));
+
+    buf->cmd = XEN_DOMCTL_get_domain_state;
+    buf->domain = domid_in;
+
+    ret = xencall1(hdl->xcall, __HYPERVISOR_domctl, (unsigned long)buf);
+    saved_errno = errno;
+    if ( !ret )
+    {
+        struct xen_domctl_get_domain_state *st = &buf->u.get_domain_state;
+
+        if ( domid_out )
+            *domid_out = buf->domain;
+        if ( state )
+        {
+            *state = 0;
+            if ( st->state & XEN_DOMCTL_GETDOMSTATE_STATE_EXIST )
+                *state |= XENMANAGE_GETDOMSTATE_STATE_EXIST;
+            if ( st->state & XEN_DOMCTL_GETDOMSTATE_STATE_SHUTDOWN )
+                *state |= XENMANAGE_GETDOMSTATE_STATE_SHUTDOWN;
+            if ( st->state & XEN_DOMCTL_GETDOMSTATE_STATE_DYING )
+                *state |= XENMANAGE_GETDOMSTATE_STATE_DYING;
+            if ( st->state & XEN_DOMCTL_GETDOMSTATE_STATE_DEAD )
+                *state |= XENMANAGE_GETDOMSTATE_STATE_DEAD;
+        }
+        if ( unique_id )
+            *unique_id = st->unique_id;
+    }
+
+    xencall_free_buffer(hdl->xcall, buf);
+
+    errno = saved_errno;
+
+    return ret;
+}
+
+int xenmanage_get_domain_info(xenmanage_handle *hdl, unsigned int domid,
+                              unsigned int *state, uint64_t *unique_id)
+{
+    if ( !hdl || domid >= DOMID_FIRST_RESERVED )
+    {
+        errno = EINVAL;
+        return -1;
+    }
+
+    return xenmanage_do_domctl_get_domain_state(hdl, domid, NULL, state,
+                                                unique_id);
+}
+
+int xenmanage_poll_changed_domain(xenmanage_handle *hdl, unsigned int *domid,
+                                  unsigned int *state, uint64_t *unique_id)
+{
+    if ( !hdl || !domid )
+    {
+        errno = EINVAL;
+        return -1;
+    }
+
+    return xenmanage_do_domctl_get_domain_state(hdl, DOMID_INVALID, domid,
+                                                state, unique_id);
+}
diff --git a/tools/libs/manage/libxenmanage.map b/tools/libs/manage/libxenmanage.map
new file mode 100644
index 0000000000..64c793e603
--- /dev/null
+++ b/tools/libs/manage/libxenmanage.map
@@ -0,0 +1,8 @@
+VERS_1.0 {
+	global:
+		xenmanage_open;
+		xenmanage_close;
+		xenmanage_get_domain_info;
+		xenmanage_poll_changed_domain;
+	local: *; /* Do not expose anything by default */
+};
diff --git a/tools/libs/uselibs.mk b/tools/libs/uselibs.mk
index 7aa8d83e06..c0a234cfec 100644
--- a/tools/libs/uselibs.mk
+++ b/tools/libs/uselibs.mk
@@ -16,6 +16,8 @@ LIBS_LIBS += devicemodel
 USELIBS_devicemodel := toollog toolcore call
 LIBS_LIBS += hypfs
 USELIBS_hypfs := toollog toolcore call
+LIBS_LIBS += manage
+USELIBS_manage := toollog toolcore call
 LIBS_LIBS += ctrl
 USELIBS_ctrl := toollog call evtchn gnttab foreignmemory devicemodel
 LIBS_LIBS += guest
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 11:05:33 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 11:05:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868176.1279726 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVqM0-0001AF-89; Thu, 09 Jan 2025 11:05:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868176.1279726; Thu, 09 Jan 2025 11:05:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVqM0-0001A8-5b; Thu, 09 Jan 2025 11:05:32 +0000
Received: by outflank-mailman (input) for mailman id 868176;
 Thu, 09 Jan 2025 11:05:30 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=pS5t=UB=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVqLy-0001A2-Qg
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 11:05:30 +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 a30e4c90-ce79-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 12:05:29 +0100 (CET)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-4362bae4d7dso6006375e9.1
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 03:05:29 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436e9e37d46sm17035495e9.25.2025.01.09.03.05.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 03:05:28 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a30e4c90-ce79-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736420729; x=1737025529; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Oe0prP2niGOAvwz4fU40U6wRNqlRneVV+fa3c7A2ILI=;
        b=OiTDyFFnlgzfePuPqd5ZG6I5baM4M2m51zUeJRq48wpUiTXbODcPgFGE6ej3xgsru4
         JG2uK5I5PD+8Dsri0Bp/lkQNnCHkcSlhziPOFQv0Y/Wuj4XKUS3gMiWszxmDc6ZF1gn+
         X62tmxI1ng+aZnbGXT+QeWF2Va8hytlCD1cC4keNF2bPc3Cp0I30U7idp6O9v61gO33j
         XmnnOFWsejUivuOpKZ9F/pwyFHd6XhG0mvyz77yp+GeiCA3d+LcKtmclcAkTxrd6Pn5m
         hHDqdGrYyMwD58yGUCyCzTaFgDYCfpqq5rYAsf6V4+anvMoxqwcYpMiUq1P6me0oZ/Ge
         MZdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736420729; x=1737025529;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Oe0prP2niGOAvwz4fU40U6wRNqlRneVV+fa3c7A2ILI=;
        b=joLNfVXYnJsvxE3t5RHd/Ppp29rPgwzKmke60M65liUKy9KG1K3rDfdtAje5h4eiSf
         slcPpFTOnapMlv4wsNrMYV1jFijL6A19uRUHVFzpO8ugd2tSXLIO2mL4IfLefimknA+0
         3oGrMFgs0mkBv/pN3V7Ne82hXvhGIBZA7UYWmit4InziO772uOB+SvrrhXKfiz53hYu+
         2aqm2Zz3g5vbIQzS30A1J69129MKb+hDQiKpnO5SW/jNGolPHzP9CmSFI3sEdfkgq7Mq
         6SyFQj98BFRHYcbONIL1MK20h+ozEeOIxOLY6YSjYFfArkprOD/86kjIam9KfvaXs/it
         sAwQ==
X-Forwarded-Encrypted: i=1; AJvYcCXXnXZiuIHjcDccKzZ4e5ABoLzauJRlQ1VgVpLu3ByrqrITUb0pPyKKFwexg9oqGUOV1W9tTJuq9hw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxcAFTlEAbwmmQfEP10o7SfLgU6z1L7SpyDHK6NFv3rYnrc5Qek
	mkRbJ/1VZRAUn6hQEN/iVliXRC1Aeu7dOTiob9EAZd+TStIYlMa8DdsLBbYH3A==
X-Gm-Gg: ASbGncvUle2d7EBHewLmXDwSuvR5e4cLIRVql3mGseIvNeTJRwMhP1NT1/rY4T8t4UI
	bqwmV3v/IrgaihHOW/kJydiAvJ6J2Aiu0VjLVW8ZL1Sg3Q6BWMoYX5RPJq8QKc30bUYUCWuFP0R
	PSL3y9jIVm6ebER3+762cC91RAL6VbBj5J48QrY+mSl79QJaw72PB6x28RGCt7uAdlMSe2OqxSD
	kFhHVnvg0bWTS+uRY8/Kjmd9NecyK1u2FgC73H+3zGTAEXSo1vN1ROhN1WGBSPoZorvU/yhvCm/
	GJtL6RVUP9r1Bhzto2RmeBEWCFdVFpZVRLNsmUZp8g==
X-Google-Smtp-Source: AGHT+IHPeRqiSHaKBg1uVtAg3eN+nXkPd56j+JZFXlRvUsQUf7n7/q+exSOo5FidMzidAWV8tMICqg==
X-Received: by 2002:a05:600c:4f47:b0:434:e8cf:6390 with SMTP id 5b1f17b1804b1-436e2684dfcmr51478495e9.6.1736420728909;
        Thu, 09 Jan 2025 03:05:28 -0800 (PST)
Message-ID: <8eea1edb-edcf-45a6-b688-92fca86c25b1@suse.com>
Date: Thu, 9 Jan 2025 12:05:26 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 06/11] xen/cpufreq: introduce policy type when
 cpufreq_driver->setpolicy exists
To: Penny Zheng <Penny.Zheng@amd.com>
Cc: stefano.stabellini@amd.com, Ray.Huang@amd.com, Xenia.Ragiadakou@amd.com,
 Jason.Andryuk@amd.com, xen-devel@lists.xenproject.org
References: <20241203081111.463400-1-Penny.Zheng@amd.com>
 <20241203081111.463400-7-Penny.Zheng@amd.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20241203081111.463400-7-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 03.12.2024 09:11, Penny Zheng wrote:
> --- a/xen/drivers/cpufreq/utility.c
> +++ b/xen/drivers/cpufreq/utility.c
> @@ -484,3 +484,14 @@ int __cpufreq_set_policy(struct cpufreq_policy *data,
>  
>      return __cpufreq_governor(data, CPUFREQ_GOV_LIMITS);
>  }
> +
> +unsigned int cpufreq_parse_policy(struct cpufreq_governor *gov)
> +{
> +    if ( !strncasecmp(gov->name, "performance", CPUFREQ_NAME_LEN) )
> +        return CPUFREQ_POLICY_PERFORMANCE;
> +
> +    if ( !strncasecmp(gov->name, "powersave", CPUFREQ_NAME_LEN) )
> +        return CPUFREQ_POLICY_POWERSAVE;
> +
> +    return CPUFREQ_POLICY_UNKNOWN;
> +}
> diff --git a/xen/include/acpi/cpufreq/cpufreq.h b/xen/include/acpi/cpufreq/cpufreq.h
> index acf133430b..cad27f6811 100644
> --- a/xen/include/acpi/cpufreq/cpufreq.h
> +++ b/xen/include/acpi/cpufreq/cpufreq.h
> @@ -133,6 +133,17 @@ extern int cpufreq_register_governor(struct cpufreq_governor *governor);
>  extern struct cpufreq_governor *__find_governor(const char *governor);
>  #define CPUFREQ_DEFAULT_GOVERNOR &cpufreq_gov_dbs
>  
> +#define CPUFREQ_POLICY_UNKNOWN      0
> +/*
> + * If cpufreq_driver->target() exists, the ->governor decides what frequency
> + * within the limits is used. If cpufreq_driver->setpolicy() exists, these
> + * two generic policies are available:
> + */
> +#define CPUFREQ_POLICY_POWERSAVE    1
> +#define CPUFREQ_POLICY_PERFORMANCE  2
> +
> +unsigned int cpufreq_parse_policy(struct cpufreq_governor *gov);
> +
>  /* pass a target to the cpufreq driver */
>  extern int __cpufreq_driver_target(struct cpufreq_policy *policy,
>                                     unsigned int target_freq,

The new function has no callers, making it difficult to review the change (not
seeing how it is used) and violating Misra (by introducing unreachable code).

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 11:11:53 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 11:11:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868200.1279737 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVqS4-0003Ie-0f; Thu, 09 Jan 2025 11:11:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868200.1279737; Thu, 09 Jan 2025 11:11:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVqS3-0003IX-U4; Thu, 09 Jan 2025 11:11:47 +0000
Received: by outflank-mailman (input) for mailman id 868200;
 Thu, 09 Jan 2025 11:11:46 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=bl7y=UB=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tVqHg-0003F6-GM
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 11:01:04 +0000
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com
 [2a00:1450:4864:20::32a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 039cb351-ce79-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 12:01:02 +0100 (CET)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-43623f0c574so6149595e9.2
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 03:01:02 -0800 (PST)
Received: from localhost ([66.81.170.107]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436e2e92f7bsm51705095e9.38.2025.01.09.03.01.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 03:01:01 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 039cb351-ce79-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736420461; x=1737025261; darn=lists.xenproject.org;
        h=in-reply-to:references:from:subject:cc:to:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=dGiWpxWM7utRqSJVw4NZRMsiD0kw3rLr7nDPnYu4dFE=;
        b=ETlz9ftuPTtxmv51Uim6SwWlfuyRyxrKHAs52eJHVL42XP302ydN+Xzgb3g4MZUhlk
         gzKcwMN05CH8qzaMh3bNjy69+WmACGygbFdaZNk46cPc3OhFlS3yIB+farl15TUcY9Mh
         zQoq9fOjSG7bsyGu1JiY4yCOs8X5FrD/ifLWk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736420461; x=1737025261;
        h=in-reply-to:references:from:subject:cc:to:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=dGiWpxWM7utRqSJVw4NZRMsiD0kw3rLr7nDPnYu4dFE=;
        b=qiNYa5/E4It21oGHG+4yuzOhw2VRAyViLM+6AtbIr0a92pKpVBEtXOKbIXbU29zS7u
         Mngoa69Us31taKhFlS/cOFg/qb0SP+6N0t6wpCN8xS8GyJho1gdKQC1SDSmgWpH75nmu
         Xg5YD6Pi67ZCbFssU8ELUxjvrqezvdhcZBuccy7//IQaMbc+Kw0Owwhs++Ie0NgzWxTJ
         9Bd2gslZhpS1Gyqm5E5seyYn6jDCb48SWA+Pd753Sp1VSLr9TW2b5D4WKjTvZxk3scyc
         P9hM1E8g5muXLwIk23opQGAkWGUnQF7nH/6YY5c8C1uTUdi6zZdayhMLR2jXHg/9TWCL
         NirQ==
X-Forwarded-Encrypted: i=1; AJvYcCVoFY1v37ZqaWL9WuAjBROonTK2Yc1u03CIdgSo9rV6b5dlc+mB99ZG9m0Tt95cYTpo+RkT2zvn6CM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzW1STq2nPA94V+SKPrRth6uUHwG/HHh6jB/XeIKN8lF27jJpfL
	nvclgVFNyMEu4zxwZlqwkPIBrTUwON2CEhZSlW/8VJfPYti8HWVUNSHq5GrhWZM=
X-Gm-Gg: ASbGnctd/0QqL/+XUxwR51alCFIuo6p6ysPFcHudWdyRjMm6+ymBO9/8wTZwu+lg7z0
	ENqXWbGSbSAgWBpjEyDwTRunT1ujhVGCtYGnpbA4YP0rC6uAKpP0NSOTxIwqBemE0B+JsIbw/tU
	b5HSVJu2SnNmMnVqo2ZYNYEoG/6CwWQBq8FtbcFOi+aYv9h/RvvioB4//JXTmjyIBiRIeURshsK
	JtaRPGxHT+cqhFHkDwErBPO6oq1ilB9NngwZMew6G7sKbWuCkscPrA3FD7bIqs=
X-Google-Smtp-Source: AGHT+IGybEm3P7KJqje+MTjwyod8X/r+6rWhswzDEuCY/jy8sTmWcc8EMqPHLMz3wyLoGlzbhaEpKw==
X-Received: by 2002:a7b:c8d4:0:b0:434:b9c6:68f7 with SMTP id 5b1f17b1804b1-436e26ddc3cmr49453045e9.26.1736420461416;
        Thu, 09 Jan 2025 03:01:01 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Thu, 09 Jan 2025 11:01:00 +0000
Message-Id: <D6XHOJ01P6HV.2IGS7W4SGN07@cloud.com>
To: "Roger Pau Monne" <roger.pau@citrix.com>,
 <xen-devel@lists.xenproject.org>
Cc: "Jan Beulich" <jbeulich@suse.com>, "Andrew Cooper"
 <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v2 09/18] x86/mm: simplify create_perdomain_mapping()
 interface
From: "Alejandro Vallejo" <alejandro.vallejo@cloud.com>
X-Mailer: aerc 0.18.2
References: <20250108142659.99490-1-roger.pau@citrix.com>
 <20250108142659.99490-10-roger.pau@citrix.com>
In-Reply-To: <20250108142659.99490-10-roger.pau@citrix.com>

On Wed Jan 8, 2025 at 2:26 PM GMT, Roger Pau Monne wrote:
> diff --git a/xen/arch/x86/include/asm/mm.h b/xen/arch/x86/include/asm/mm.=
h
> index 65cd751087dc..0c57442c9593 100644
> --- a/xen/arch/x86/include/asm/mm.h
> +++ b/xen/arch/x86/include/asm/mm.h
> @@ -601,8 +601,7 @@ int compat_arch_memory_op(unsigned long cmd, XEN_GUES=
T_HANDLE_PARAM(void) arg);
>  #define IS_NIL(ptr) (!((uintptr_t)(ptr) + sizeof(*(ptr))))

Shouldn't IS_NIL() and NIL (out of context) be removed too?

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 11:18:34 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 11:18:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868218.1279748 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVqYX-00041k-Ob; Thu, 09 Jan 2025 11:18:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868218.1279748; Thu, 09 Jan 2025 11:18:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVqYX-00041d-Jy; Thu, 09 Jan 2025 11:18:29 +0000
Received: by outflank-mailman (input) for mailman id 868218;
 Thu, 09 Jan 2025 11:18:27 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=pS5t=UB=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVqYV-00040q-TB
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 11:18:27 +0000
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com
 [2a00:1450:4864:20::335])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 722ac387-ce7b-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 12:18:26 +0100 (CET)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-4361f664af5so9849845e9.1
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 03:18:26 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436e9e37d46sm17386545e9.25.2025.01.09.03.18.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 03:18:24 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 722ac387-ce7b-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736421506; x=1737026306; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=UWhs9feB6Sp+Hi/8OiNlRyxfYZ4eXaXibU/Aw8TJAkQ=;
        b=W9+Z3dS15HM8Yl8r+7GA+/hP0SVh74Kiiep3smePdO7oIC1smEb+lK6Vnj2x3KHzD6
         N+KLrNdJ50hq0Vq6OKajo3EQ4PlJc3/Tm0sZ+z4XWEyUqgfbPlgidGybl3d+tNN3KNwS
         U9IKbg6SqWCykgMUDuLDCVs4q5eaOwhW5+3A7YkzeIv5PvhWEtIkyNDKj8U6aGbPBhnS
         LiO6FJIgG7y0VeVPBtGMdSb3dvb3sWveYsNxUUt61y2jFgYl+ASyJCyzAoAzP7Exxt49
         LVhVhsiDhl8wTKjhzk30Yte0nakiQKbja+0kmP0/2/YkIE9uxb8DdnNNjgg1SAN5y19I
         e4ZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736421506; x=1737026306;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=UWhs9feB6Sp+Hi/8OiNlRyxfYZ4eXaXibU/Aw8TJAkQ=;
        b=DtSp0QKxSxsOq8fOALNvy1qJjR7YS6jEnRUAb3wcxruY5xsMFHtmMv4CObda0Lq76i
         VnPejfyeS8iPb0QykbhyyvLuQYL/WdUEwI2xDskqlyYWjDyKedJvV+v1LfGV4BlSw/Wk
         s6eh0sq6iA1RNhfLNASZOn2TpAMsLmt4k6dQ0wq/1bYLyMZ1rKAIU0lCynu8iWd2i0Jx
         gXvWOAUAZrLp8U+M/pRlLdOBWTXTjjsY0m9L6NbUA/LbRHJbFg4q9d918ye8qZDrJ2vd
         DVdtCHvITfqi52GO5ZHHPHTpJKGSykcgd5avlShIXnPknqHSz4PNDitxetG0TY7HNlsW
         4hng==
X-Forwarded-Encrypted: i=1; AJvYcCUk/l7WvKJqddnUS6C++MwH+cmlpiLtPC6m7e6Y0TOxLarrVtZvMnGPByVX6BXlMb/l5MOOKOeeNx0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxwKBUa71ikMVRgCFgWSI2Etxr9YKYHxvVKWMqK0GHVNcrVvWxP
	wQCHJpJ3gTogSrJhfeLqSo/XDg+qc6CNL0KayNT1ZPtVV/7Hiq63CcqfSu6yWQ==
X-Gm-Gg: ASbGncvHWOa+OTkCbO0M9+wqDXMPxPGK9goYRJeJYDbS/PNWBupqS2Sc3G2oTDAgusa
	f7YUSmy9008BkB9vVXhvj1MxRmiR2DYfV6q+lLl05Z/pKjRJaIC7pd+p0zWrN5vdlb6r5C+RaU6
	nYT9KvAQBo2QVRCGeSqIgySPWd+nyNytkE9pFQXimnttSnuPxWMzgkEJ06D8DsWpAQFdH5iiZZA
	sqfd4bWlisrNGFC9FopCD374ieCXyT1Sdr2ak5NkMy9x7t9zhH27n4dhQq2byLj1qXeHxoHJhnB
	NCMwsh1rLVbibvZSvSTS1BkKR+lXUWFBYG3IWn8S1Q==
X-Google-Smtp-Source: AGHT+IGFWHAXe2D6VKlCC0IANRemBwRSJMrJ7laxduDYApfa+Y5HaOTByJAotwckobAxsAltnYplfA==
X-Received: by 2002:a5d:6c63:0:b0:385:ee59:4510 with SMTP id ffacd0b85a97d-38a872fb0f9mr5268264f8f.9.1736421504996;
        Thu, 09 Jan 2025 03:18:24 -0800 (PST)
Message-ID: <aa88bcec-11e9-4a1a-8c2d-e18ef5bcbc35@suse.com>
Date: Thu, 9 Jan 2025 12:18:23 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 07/11] xen/cpufreq: only set gov NULL when
 cpufreq_driver.target() exists
To: Penny Zheng <Penny.Zheng@amd.com>
Cc: stefano.stabellini@amd.com, Ray.Huang@amd.com, Xenia.Ragiadakou@amd.com,
 Jason.Andryuk@amd.com, xen-devel@lists.xenproject.org
References: <20241203081111.463400-1-Penny.Zheng@amd.com>
 <20241203081111.463400-8-Penny.Zheng@amd.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20241203081111.463400-8-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 03.12.2024 09:11, Penny Zheng wrote:
> --- a/xen/drivers/cpufreq/cpufreq.c
> +++ b/xen/drivers/cpufreq/cpufreq.c
> @@ -316,7 +316,13 @@ int cpufreq_add_cpu(unsigned int cpu)
>      if (hw_all || (cpumask_weight(cpufreq_dom->map) ==
>                     perf->domain_info.num_processors)) {
>          memcpy(&new_policy, policy, sizeof(struct cpufreq_policy));
> -        policy->governor = NULL;
> +
> +       /*
> +        * Only when cpufreq_driver.target exists, we need to deliberately set old gov as NULL
> +        * to trigger the according gov starting.
> +        */
> +       if ( cpufreq_driver.target )
> +            policy->governor = NULL;
>  
>          cpufreq_cmdline_common_para(&new_policy);

Looking at __cpufreq_set_policy(), wouldn't the condition better check
.setpolicy being NULL?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 11:23:57 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 11:23:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868226.1279756 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVqdl-000696-8c; Thu, 09 Jan 2025 11:23:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868226.1279756; Thu, 09 Jan 2025 11:23:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVqdl-00068z-5i; Thu, 09 Jan 2025 11:23:53 +0000
Received: by outflank-mailman (input) for mailman id 868226;
 Thu, 09 Jan 2025 11:23:51 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=pS5t=UB=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVqdj-00068q-Jj
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 11:23:51 +0000
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com
 [2a00:1450:4864:20::333])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 32d54d8f-ce7c-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 12:23:49 +0100 (CET)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-436a39e4891so6098825e9.1
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 03:23:49 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436e2da6401sm52434755e9.2.2025.01.09.03.23.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 03:23:48 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 32d54d8f-ce7c-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736421829; x=1737026629; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=G4kt3o+Yc7LWOWbjd5MTmHjbaASrzqLfQf/updZjo/Q=;
        b=bfVexs5WG66q7AjJq2tNoZKuynSy3XQ2bvwSf0Y/wn8S5uCJyW6AbSWsWnt/oigBVN
         j7xBBXk8vWGpLKWsptU27W8xj3+fm0whGWPh3MT6/jPwJKqrtgTr1g3MQ3+edf8++YXl
         61wCIz79PEqyjqGhDsSCegyjIqjRiqpe3f7T7vZN+eQyIwEPzx+JZn1noFFrFMkaOg41
         Gykbmqxb4aM2mzyJngOWMXZbstIy5INN/sFftg0Z9qIYsKbf0F80vKucmu5v2KGFy94s
         mY8hXEhDnXDTMoUnibEq8iTJMAljRyK8ADbrMngQFVBE7fdKLN3Hj+C/5RTdMrFDNiEd
         RE7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736421829; x=1737026629;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=G4kt3o+Yc7LWOWbjd5MTmHjbaASrzqLfQf/updZjo/Q=;
        b=Ls2vpwG9wbYTW/R683V2oYqV8aGT0sV0t/Cv5aSnUmCjv5JzMHH52ic1Vde0lrXUIU
         nzMaRveZmwXCWIqC6I9lTx9fkX5Z662Gt+IGPgYUTLC6rD1rPe+2xJWDws7VIi5S/niZ
         kI3exaHkiXdOJtB9NUvQFOn9JyFDfQYfjpzWme7eF38t60tNbOpHSQePb7GJ0KSO/l0w
         55F34jQtu0VMBDEyoTJRtYtSZjWPbbKISnYvwndWDpepmP6WxttmQ6oOULqQch4AHJN+
         KKabByXsQKS5PK3FCWCQoBhZDiQFo+Fjgx8rIkHg5N2rUyJY43DOqm2TqXa9dQ078A5A
         ZUyQ==
X-Forwarded-Encrypted: i=1; AJvYcCUcHgjtAzpt9Ly/0wmExyQRi7848SXFX5xHq2MuJyAPkmgljInz0+zAmlTtdPvpqFQgnWKXXMBXQcs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzpXXiLhn/kWcmdzXchXNt/83VIuQJqdOkDwuj1C3g9FkKjQETv
	UhGYr/U/hKeh2us7UKdQwVjmk9/MlZS40j/fQAVBrmP1vr0wY1xyiTjk+Pb+SA==
X-Gm-Gg: ASbGnctP6eYKSCgntUc+C3TmRa4V1bIEXV/IM8sR4IO+nO1jqv5BVO3vlYgagetJQ/1
	GMRa8DD+wmycIfDjvDboCV/cOTk56pDno7iFWCCpkKdxqDWznP92oHzT2431cfDy+ZUhxkbfpBA
	ayNN4gYIWsmPg6pKmswetUkZS2IIJx7mKkPXDBdcShIwyH1uU7Y+sFzrnhlJ0SLGz0aJd7kNNmd
	DWInOVZSAr18/krIH+P7ZApZYjb2++eX3eFisEaKXQTLcfPB45RFpw8CsUe+QjfaJ7nDXe6nWtA
	pbm/MI+y2spg+BuCvumuTosNzTAwkwFLPzDcXqfiFw==
X-Google-Smtp-Source: AGHT+IH/it6L6YNM1tG+YyqSCvlsaPKtoolQy6NeioEKimFwWS/FqtbDh9V8azE4SisIqe517Fsh6g==
X-Received: by 2002:a05:600c:4f4e:b0:434:a902:97cd with SMTP id 5b1f17b1804b1-436e26935cbmr35033925e9.12.1736421828987;
        Thu, 09 Jan 2025 03:23:48 -0800 (PST)
Message-ID: <541ed82a-6cf3-4964-9421-23905b777f9c@suse.com>
Date: Thu, 9 Jan 2025 12:23:46 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 08/11] x86/cpufreq: add "cpufreq=amd-pstate,active"
 para
To: Penny Zheng <Penny.Zheng@amd.com>
Cc: stefano.stabellini@amd.com, Ray.Huang@amd.com, Xenia.Ragiadakou@amd.com,
 Jason.Andryuk@amd.com, Andrew Cooper <andrew.cooper3@citrix.com>,
 Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20241203081111.463400-1-Penny.Zheng@amd.com>
 <20241203081111.463400-9-Penny.Zheng@amd.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20241203081111.463400-9-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 03.12.2024 09:11, Penny Zheng wrote:
> From: Penny Zheng <penny.zheng@amd.com>
> 
> The amd-pstate driver may support multiple working modes, passive and active.
> 
> Introduce a new variable to keep track of which mode is currently enabled.
> This variable will also help to choose which cpufreq driver to be registered.
> 
> Signed-off-by: Penny Zheng <Penny.Zheng@amd.com>
> ---
>  docs/misc/xen-command-line.pandoc      |  9 ++++++++-
>  xen/arch/x86/acpi/cpufreq/amd-pstate.c | 12 +++++++++++-
>  2 files changed, 19 insertions(+), 2 deletions(-)
> 
> diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
> index 30f855fa18..a9a3e0ef79 100644
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -499,7 +499,8 @@ If set, force use of the performance counters for oprofile, rather than detectin
>  available support.
>  
>  ### cpufreq
> -> `= none | {{ <boolean> | xen } { [:[powersave|performance|ondemand|userspace][,[<maxfreq>]][,[<minfreq>]]] } [,verbose]} | dom0-kernel | hwp[:[<hdc>][,verbose]] | amd-pstate[:[verbose]]`
> +> `= none | {{ <boolean> | xen } { [:[powersave|performance|ondemand|userspace][,[<maxfreq>]][,[<minfreq>]]] }
> +[,verbose]} | dom0-kernel | hwp[:[<hdc>][,verbose]] | amd-pstate[:[active][,verbose]]`
>  
>  > Default: `xen`
>  
> @@ -522,6 +523,12 @@ choice of `dom0-kernel` is deprecated and not supported by all Dom0 kernels.
>    on supported AMD hardware to provide a finer grained frequency control mechanism.
>    The default is disabled. If `amd-pstate` is selected, but hardware support
>    is not available, Xen will fallback to cpufreq=xen.
> +* `active` is a boolean to enable amd-pstate driver in active(autonomous) mode.
> +  In this mode, users could provide a hint with energy performance preference
> +  register to the hardware if they want to bias toward performance(0x0) or
> +  energy efficiency(0xff), then CPPC power algorithm will calculate the runtime
> +  workload and adjust the realtime cores frequency according to the power supply
> +  and themal, core voltage and some other hardware conditions.

Nit: thermal

> --- a/xen/arch/x86/acpi/cpufreq/amd-pstate.c
> +++ b/xen/arch/x86/acpi/cpufreq/amd-pstate.c
> @@ -27,6 +27,8 @@
>  #define amd_pstate_warn(fmt, args...) \
>      printk(XENLOG_WARNING "AMD_PSTATE: CPU%u warning: " fmt, cpu, ## args)
>  
> +static bool __ro_after_init opt_cpufreq_active = false;

Pointless initializer.

> @@ -398,5 +407,6 @@ int __init amd_pstate_register_driver(void)
>      if ( !cpu_has_cppc )
>          return -ENODEV;
>  
> -    return cpufreq_register_driver(&amd_pstate_cpufreq_driver);
> +    if ( !opt_cpufreq_active )
> +        return cpufreq_register_driver(&amd_pstate_cpufreq_driver);
>  }

I'm afraid the description is of no help in determining why this is a
correct change to make (here). How would the user provided hint (see
cmdline option description) be communicated to hardware when the driver
isn't even registered?

Finally I don't think the change above would build, as it leaves a
return from the function without return value.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 11:25:19 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 11:25:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868234.1279767 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVqf8-0006ep-Hn; Thu, 09 Jan 2025 11:25:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868234.1279767; Thu, 09 Jan 2025 11:25:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVqf8-0006ei-Ez; Thu, 09 Jan 2025 11:25:18 +0000
Received: by outflank-mailman (input) for mailman id 868234;
 Thu, 09 Jan 2025 11:25: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
 <SRS0=zlLY=UB=casper.srs.infradead.org=BATV+10359aeb926cd7703950+7809+infradead.org+dwmw2@srs-se1.protection.inumbo.net>)
 id 1tVqf7-0006eY-Di
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 11:25:18 +0000
Received: from casper.infradead.org (casper.infradead.org
 [2001:8b0:10b:1236::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6618e3cf-ce7c-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 12:25:16 +0100 (CET)
Received: from 54-240-197-239.amazon.com ([54.240.197.239]
 helo=edge-dns-1.e-iad53.amazon.com)
 by casper.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux))
 id 1tVqf4-00000005Yve-1TnI; Thu, 09 Jan 2025 11:25:14 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 6618e3cf-ce7c-11ef-a0df-8be0dac302b0
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:Cc:To:From:Subject:Message-ID:Sender:Reply-To:
	Content-Transfer-Encoding:Content-ID:Content-Description;
	bh=1buS4Z/ZGeeN8roeh7FDXbZdgPm6zonDkM+Qst9wb14=; b=L6IG9Zr4t8xerUSof7n1Y+HntL
	i8yvk5H1L8r7Qwrfy1SUksnwRAkOm7VMrXVa3/HpRPUIe8QK8cExJk9LKVS6l4AmU8uZHr1Q3k7Oi
	bd5rYfRG8i3+++LHyomSh0oR81aO/RhbGc85ITOYog0czZXji7JyFWdAs2Gnb6hY0MYAs3fCN3kb0
	GxBjlgwgmIdoPz7CtVEyNZ9aWSf4GozrpSGLKa6uL0UsTjSUe8bn/nYfQQRuRfsHkY2nLpr9ZOC5l
	mMkzI0cuGecgK7e84GnVtsH8EpqitOXgk1FdGNP26YTbVp4gfYQo/leV0el/knm8qP3dCZVDyrdgS
	s3sl41kg==;
Message-ID: <974ab6743d168d34babd458fe5e2e7766bb280b4.camel@infradead.org>
Subject: Re: [PATCH 2/2] xen: do not use '%ms' scanf specifier
From: David Woodhouse <dwmw2@infradead.org>
To: Anthony PERARD <anthony@xenproject.org>, Roger Pau Monne
	 <roger.pau@citrix.com>
Cc: qemu-devel@nongnu.org, Stefano Stabellini <sstabellini@kernel.org>, Paul
 Durrant <paul@xen.org>, "Edgar E. Iglesias" <edgar.iglesias@gmail.com>, 
 =?ISO-8859-1?Q?Marc-Andr=E9?= Lureau
	 <marcandre.lureau@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	xen-devel@lists.xenproject.org
Date: Thu, 09 Jan 2025 11:25:13 +0000
In-Reply-To: <Z3-sJMXpiFUoATHz@l14>
References: <20250107093140.86180-1-roger.pau@citrix.com>
	 <20250107093140.86180-3-roger.pau@citrix.com> <Z3-sJMXpiFUoATHz@l14>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-4p95W8zMjrvErxC+5EOH"
User-Agent: Evolution 3.52.3-0ubuntu1 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html


--=-4p95W8zMjrvErxC+5EOH
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2025-01-09 at 11:59 +0100, Anthony PERARD wrote:
>=20
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 char label[32];
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 XenDevice *xendev =3D NULL;
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 XenConsole *con;
> > @@ -550,7 +551,10 @@ static void xen_console_device_create(XenBackendIn=
stance *backend,
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 goto fail;
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
> > =C2=A0=20
> > -=C2=A0=C2=A0=C2=A0 if (xs_node_scanf(xsh, XBT_NULL, fe, "type", errp, =
"%ms", &type) !=3D 1) {
> > +=C2=A0=C2=A0=C2=A0 node_path =3D g_strdup_printf("%s/type", fe);
> > +=C2=A0=C2=A0=C2=A0 type =3D qemu_xen_xs_read(xsh, XBT_NULL, node_path,=
 NULL);
> > +=C2=A0=C2=A0=C2=A0 g_free(node_path);
>=20
> I feel like we want "xs_node_read()" which would be similair to
> xs_node_vscanf() but would simply return the result of
> qemu_xen_xs_read(). This would avoid the need format of the node path in
> several place in the code. But it's OK like that as well.

If you look at the other callers of qemu_xen_xs_read(), it looks like
the majority of them create the path with snprintf and then pass it in.
Or with g_strdup_printf(), pass it in, then free it afterwards.

So perhaps qemu_xen_xs_read() should be a printf-style function too,
with its last arg(s) being the node name.

--=-4p95W8zMjrvErxC+5EOH
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD9Aw
ggSOMIIDdqADAgECAhAOmiw0ECVD4cWj5DqVrT9PMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0yNDAxMzAwMDAwMDBaFw0zMTEx
MDkyMzU5NTlaMEExCzAJBgNVBAYTAkFVMRAwDgYDVQQKEwdWZXJva2V5MSAwHgYDVQQDExdWZXJv
a2V5IFNlY3VyZSBFbWFpbCBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMjvgLKj
jfhCFqxYyRiW8g3cNFAvltDbK5AzcOaR7yVzVGadr4YcCVxjKrEJOgi7WEOH8rUgCNB5cTD8N/Et
GfZI+LGqSv0YtNa54T9D1AWJy08ZKkWvfGGIXN9UFAPMJ6OLLH/UUEgFa+7KlrEvMUupDFGnnR06
aDJAwtycb8yXtILj+TvfhLFhafxroXrflspavejQkEiHjNjtHnwbZ+o43g0/yxjwnarGI3kgcak7
nnI9/8Lqpq79tLHYwLajotwLiGTB71AGN5xK+tzB+D4eN9lXayrjcszgbOv2ZCgzExQUAIt98mre
8EggKs9mwtEuKAhYBIP/0K6WsoMnQCcCAwEAAaOCAVwwggFYMBIGA1UdEwEB/wQIMAYBAf8CAQAw
HQYDVR0OBBYEFIlICOogTndrhuWByNfhjWSEf/xwMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6en
IZ3zbcgPMA4GA1UdDwEB/wQEAwIBhjAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIweQYI
KwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYIKwYB
BQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RD
QS5jcnQwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0
QXNzdXJlZElEUm9vdENBLmNybDARBgNVHSAECjAIMAYGBFUdIAAwDQYJKoZIhvcNAQELBQADggEB
ACiagCqvNVxOfSd0uYfJMiZsOEBXAKIR/kpqRp2YCfrP4Tz7fJogYN4fxNAw7iy/bPZcvpVCfe/H
/CCcp3alXL0I8M/rnEnRlv8ItY4MEF+2T/MkdXI3u1vHy3ua8SxBM8eT9LBQokHZxGUX51cE0kwa
uEOZ+PonVIOnMjuLp29kcNOVnzf8DGKiek+cT51FvGRjV6LbaxXOm2P47/aiaXrDD5O0RF5SiPo6
xD1/ClkCETyyEAE5LRJlXtx288R598koyFcwCSXijeVcRvBB1cNOLEbg7RMSw1AGq14fNe2cH1HG
W7xyduY/ydQt6gv5r21mDOQ5SaZSWC/ZRfLDuEYwggWbMIIEg6ADAgECAhAH5JEPagNRXYDiRPdl
c1vgMA0GCSqGSIb3DQEBCwUAMEExCzAJBgNVBAYTAkFVMRAwDgYDVQQKEwdWZXJva2V5MSAwHgYD
VQQDExdWZXJva2V5IFNlY3VyZSBFbWFpbCBHMjAeFw0yNDEyMzAwMDAwMDBaFw0yODAxMDQyMzU5
NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqGSIb3DQEBAQUAA4IC
DwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZeYAS/SRV6zmfXlXaZ
sNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2zkC9S7/yHDYnqegqt
w4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qGpgFdZEk2/c//ZvUN
i12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41vav1RhZJzYan4a1gU0
kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0cvnO8FM6PTqsnSbcc
0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PWPU6zfQTOMZ9uLQRR
ci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXtREF5lLXxp+CJ6KKS
blPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQrlR0gO3lBzuyPPArV
hvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7IqaAovAX0d+f1YjbmC
VsAwjhLmveFjNwIDAQABo4IBsDCCAawwHwYDVR0jBBgwFoAUiUgI6iBOd2uG5YHI1+GNZIR//HAw
HQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3bXcyQGluZnJhZGVh
ZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEBMA4GA1UdDwEB/wQE
AwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwewYDVR0fBHQwcjA3oDWgM4YxaHR0
cDovL2NybDMuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNybDA3oDWgM4YxaHR0
cDovL2NybDQuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNybDB2BggrBgEFBQcB
AQRqMGgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBABggrBgEFBQcwAoY0
aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNydDANBgkq
hkiG9w0BAQsFAAOCAQEAQXc4FPiPLRnTDvmOABEzkIumojfZAe5SlnuQoeFUfi+LsWCKiB8Uextv
iBAvboKhLuN6eG/NC6WOzOCppn4mkQxRkOdLNThwMHW0d19jrZFEKtEG/epZ/hw/DdScTuZ2m7im
8ppItAT6GXD3aPhXkXnJpC/zTs85uNSQR64cEcBFjjoQDuSsTeJ5DAWf8EMyhMuD8pcbqx5kRvyt
JPsWBQzv1Dsdv2LDPLNd/JUKhHSgr7nbUr4+aAP2PHTXGcEBh8lTeYea9p4d5k969pe0OHYMV5aL
xERqTagmSetuIwolkAuBCzA9vulg8Y49Nz2zrpUGfKGOD0FMqenYxdJHgDCCBZswggSDoAMCAQIC
EAfkkQ9qA1FdgOJE92VzW+AwDQYJKoZIhvcNAQELBQAwQTELMAkGA1UEBhMCQVUxEDAOBgNVBAoT
B1Zlcm9rZXkxIDAeBgNVBAMTF1Zlcm9rZXkgU2VjdXJlIEVtYWlsIEcyMB4XDTI0MTIzMDAwMDAw
MFoXDTI4MDEwNDIzNTk1OVowHjEcMBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzCCAiIwDQYJ
KoZIhvcNAQEBBQADggIPADCCAgoCggIBANqWLse95HW2F7FhfH9bugyT/danKmmXrbMnz5GZNAfj
Jl5gBL9JFXrOZ9eVdpmw04Tp6aDxZctFLoEDvSWKi367Q7Sg+ci+fH4KwwfQ8Pi0IpIKx2n5emEg
nbOQL1Lv/IcNiep6Cq3DiyaSpSp/RZf+CAfUNySHS8eWmhLU6jGpSD6hxTpYKye7PmrmvMWwfGEP
WoamAV1kSTb9z/9m9Q2LXa89aKmTxNwnAfD3Ohn9mtU3JukwILRMewn9QRXK7KzM+01h5hkCE4nj
W9q/VGFknNhqfhrWBTSQoE9CSVylASGrjzCgS7XmKy/BaH3/7mOOHQv5g1o3Qj/+cdKnpT0I5Qb1
nRy+c7wUzo9OqydJtxzSP4ZyHA4dELto/a3m/ay1XHcpum1pgTOLgxAfGb/T4dCkwRUstSKLMmpL
g9Y9TrN9BM4xn24tBFFyL5znGG0wQGzOVAM68RBzIQb6Fz758fjsr4yZnPbVsU1+gHEs/puNHrG0
9e1EQXmUtfGn4InoopJuU8p5VGD9S3Ikd4UoBlc7xl5yjtNlQxUeYrRlnUSmdlucCEoTX1n4UmtA
9CuVHSA7eUHO7I88CtWG9bGOU7tLgOZoSEvNqtaL/N7sQbBZK4jZ4Rr/zNTQg1SwYjjLB7u96lDP
sipoCi8BfR35/ViNuYJWwDCOEua94WM3AgMBAAGjggGwMIIBrDAfBgNVHSMEGDAWgBSJSAjqIE53
a4blgcjX4Y1khH/8cDAdBgNVHQ4EFgQUXGIam3Bs59Y60yTmWgfDu6pZQ6cwMAYDVR0RBCkwJ4ET
ZHdtdzJAaW5mcmFkZWFkLm9yZ4EQZGF2aWRAd29vZGhvdS5zZTAUBgNVHSAEDTALMAkGB2eBDAEF
AQEwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDB7BgNVHR8E
dDByMDegNaAzhjFodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVtYWlsRzIu
Y3JsMDegNaAzhjFodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVtYWlsRzIu
Y3JsMHYGCCsGAQUFBwEBBGowaDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29t
MEAGCCsGAQUFBzAChjRodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVt
YWlsRzIuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQBBdzgU+I8tGdMO+Y4AETOQi6aiN9kB7lKWe5Ch
4VR+L4uxYIqIHxR7G2+IEC9ugqEu43p4b80LpY7M4KmmfiaRDFGQ50s1OHAwdbR3X2OtkUQq0Qb9
6ln+HD8N1JxO5nabuKbymki0BPoZcPdo+FeRecmkL/NOzzm41JBHrhwRwEWOOhAO5KxN4nkMBZ/w
QzKEy4PylxurHmRG/K0k+xYFDO/UOx2/YsM8s138lQqEdKCvudtSvj5oA/Y8dNcZwQGHyVN5h5r2
nh3mT3r2l7Q4dgxXlovERGpNqCZJ624jCiWQC4ELMD2+6WDxjj03PbOulQZ8oY4PQUyp6djF0keA
MYIDuzCCA7cCAQEwVTBBMQswCQYDVQQGEwJBVTEQMA4GA1UEChMHVmVyb2tleTEgMB4GA1UEAxMX
VmVyb2tleSBTZWN1cmUgRW1haWwgRzICEAfkkQ9qA1FdgOJE92VzW+AwDQYJYIZIAWUDBAIBBQCg
ggE3MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTI1MDEwOTExMjUx
M1owLwYJKoZIhvcNAQkEMSIEIBYi89APMhqP6bwxpzyLM8lXgEkBdi+eNNsbl+Rk2DIGMGQGCSsG
AQQBgjcQBDFXMFUwQTELMAkGA1UEBhMCQVUxEDAOBgNVBAoTB1Zlcm9rZXkxIDAeBgNVBAMTF1Zl
cm9rZXkgU2VjdXJlIEVtYWlsIEcyAhAH5JEPagNRXYDiRPdlc1vgMGYGCyqGSIb3DQEJEAILMVeg
VTBBMQswCQYDVQQGEwJBVTEQMA4GA1UEChMHVmVyb2tleTEgMB4GA1UEAxMXVmVyb2tleSBTZWN1
cmUgRW1haWwgRzICEAfkkQ9qA1FdgOJE92VzW+AwDQYJKoZIhvcNAQEBBQAEggIAtmJhgjQ4YWRi
30VPXYAB4ujCQJSOfOSPNlkBhfSfelWL4/5I/M1MrTUUubt8ODsqHEndHt5CYJzDLsnepnaLWfqJ
p+BBFKglKonjwkmOLQ1+HhrOPFYRicG0bw5hTjH4AJg16MYkrwI5bZHPtqFoqe7zWKTB8/6lzZ4t
aINbfaNH8j/vowatM9B0WVwJqh6ZBY/tm8hsTMwlj0NzM2EAj4VBd1gy2B/0kQt0vqtTjm4MQx0C
/95O+3XzlGXleq/u6cUiE2TLi/Fb8D68+j826rL3hYJyef77jcEzLAGOCqALI1RTUMD0weha6L9j
eUjOo2BdMJkMoEzoYOEW18g7oZ+0Wlqo06BJz3mtTetDsqAht1DOhVIYRKcx9HJYSncjK7apMPfL
HMYAnJSHUUOUCg5vybSvguiOjLd7BkOy4oDe2d7c7tOOXuWrnQhr4qGA6yfDTU/OobOZG/a/9AoA
aF4em5twB9eB6JAfpxf/tT0guphRHNR5KKiaOOVamADVuNCX+YqtZv3zQJzu9lqhXniIF64A3mGI
di6Jo4LSs5SFCNGjHG+KR6NPw5h8ntUmWZ+kVdVfIlW63OsbjIc0fCDr+T89hKjsVy8SIwDLWThQ
slDzL1/st5Chgp+YQvU+76raQdJ5vT96KFP/m1YpZc0a6P9bHI8+KyuMUsORueIAAAAAAAA=


--=-4p95W8zMjrvErxC+5EOH--


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 11:38:31 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 11:38:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868249.1279778 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVqrp-0000WC-Qh; Thu, 09 Jan 2025 11:38:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868249.1279778; Thu, 09 Jan 2025 11:38:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVqrp-0000W5-Me; Thu, 09 Jan 2025 11:38:25 +0000
Received: by outflank-mailman (input) for mailman id 868249;
 Thu, 09 Jan 2025 11:38:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=pS5t=UB=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVqro-0000Vv-3W
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 11:38:24 +0000
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com
 [2a00:1450:4864:20::334])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3ad74205-ce7e-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 12:38:22 +0100 (CET)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-4361815b96cso6174865e9.1
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 03:38: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
 ffacd0b85a97d-38a8e3834fbsm1577263f8f.26.2025.01.09.03.38.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 03:38:21 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 3ad74205-ce7e-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736422701; x=1737027501; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=M22tNQLe7KmvxYgkZRqrzBeivhD8EmAFyF2n2ljaqLM=;
        b=BAwg4oLmdtjAMCpd61z8o+8SdyOGpQCo1xR3DAZaiwLye4/KrObDc6lzJlNfnd4hNh
         uBv1S3Z2ccVx5PzaS8dzR8weDcupMiippO6sFW9hHJ5QE4SKNKzW1RY9RSDkeaP9umv2
         TmaGNLAYcGlUiwr1Xrib6WlJ8lducQMbcLg2zuo5BN2j87FBH5GHkbcWT1tVdvjUL3b8
         wq3cGGpNVlks44Eo1mtJACpJyQT1LeKvpOwIt9+bbx8KmgXWYtVSscO2nes3y7dN0hD4
         QtC1UaYQpmRBh77jMym7Zikih37NhCRrQUg3Eh5rZzPXemXGR7JE0xKfnzefGn8McY0/
         bc1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736422701; x=1737027501;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=M22tNQLe7KmvxYgkZRqrzBeivhD8EmAFyF2n2ljaqLM=;
        b=l2g6kfB0ZN7vuWMXDplp1bma70wRoggr5JyfVQye3tuC3aZcBklKmmtgrXWlhDn+pq
         bUF2bz9l3BwXXtxS+YiyeLC9TphrIoLA3M1vRL9PvngeuREKaVMEJ/IBr+nwZVOy755b
         9amNcWQkk+424pMx36HTI8mdizbzNZqTdwbgL13apDyqsPH/wRTzUGaNzY93coBHL3Pz
         +vMuLo3En1x0AcdaCMGZYfIcLV9e78RsvkaWPWGVlommMWdisYulm+xuKcKCL46Zf3Cj
         O/MEUjSfHfKNkwTOtVeXdXC5ID73C5jN4vYoNnBvSHhYvKezP02rgN0+kg1ddbu7NCIJ
         Nsgg==
X-Forwarded-Encrypted: i=1; AJvYcCWC0EKeQFSzyA7yDyzqK5z0pVWMg6GRkho418TQEY6++GAQZhoiI3rgnTEXlsW0fRVefVp2SeQJ/Cs=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx7xicRZwPtd5eX1fr9CjcxhIB4FwzwxxYgMFZTAqS/b+odXss9
	mp9guCnuNHQFoa0iE41Sq2yBOHXrtaeIyzxyWXopKMy94TLjhYgHyjr6EABySQ==
X-Gm-Gg: ASbGnctrsXpXj6gQZxERNYYRema2zRXbEgRSZzNgSIFLhOXH5Ea9z5D9fMpEEqZVlKr
	BVR0KisBDf/pAnYV7EcXurYOm+9xtaNbVHD0VInr0oR9h8tyktXxk/32XpjIa+zQAaLHsy4REcP
	8lB2slr2/fBw4n6FVnmZvU6yOCNeR2uM4p7ZiW/K5BY3UgXNcYvAPrI3GH99RnaX6b+o24NewtF
	uyZ8yuH0nDg530s6aqlTgiKYFtT4KpsmfAerfzuVT46g+ViICn6p22mZcOPBLAbGZj1+QYe6l5G
	KAB55LUm6TeJzXNw0sSLmGDN96e3NEi7nH6WyJPjLw==
X-Google-Smtp-Source: AGHT+IHmB6SgQ56pISQlqpp9G9scZSIz9zk5wiQAc4Sn78EIRu3XCEyvnZNqOpbe6m9q0U4wCIAO+Q==
X-Received: by 2002:a05:600c:500f:b0:436:51bb:7a52 with SMTP id 5b1f17b1804b1-436e2697170mr55955775e9.7.1736422701386;
        Thu, 09 Jan 2025 03:38:21 -0800 (PST)
Message-ID: <3f688a4a-c95b-4852-bc0d-089336a5e6ef@suse.com>
Date: Thu, 9 Jan 2025 12:38:19 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 09/11] xen/x86: implement EPP support for the AMD
 processors
To: Penny Zheng <Penny.Zheng@amd.com>
Cc: stefano.stabellini@amd.com, Ray.Huang@amd.com, Xenia.Ragiadakou@amd.com,
 Jason.Andryuk@amd.com, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>,
 xen-devel@lists.xenproject.org
References: <20241203081111.463400-1-Penny.Zheng@amd.com>
 <20241203081111.463400-10-Penny.Zheng@amd.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20241203081111.463400-10-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 03.12.2024 09:11, Penny Zheng wrote:
> @@ -223,14 +227,29 @@ static void amd_pstate_write_request_msrs(void *info)
>  }
>  
>  static int cf_check amd_pstate_write_request(int cpu, uint8_t min_perf,
> -                                             uint8_t des_perf, uint8_t max_perf)
> +                                             uint8_t des_perf, uint8_t max_perf,
> +                                             int epp)
>  {
>      struct amd_pstate_drv_data *data = per_cpu(amd_pstate_drv_data, cpu);
> -    uint64_t prev = data->amd_req;
> +    uint64_t prev = data->amd_req, val;
>  
>      data->req.min_perf = min_perf;
>      data->req.max_perf = max_perf;
> -    data->req.des_perf = des_perf;
> +    if ( !epp_mode )
> +        data->req.des_perf = des_perf;
> +    else
> +    {
> +        data->req.des_perf = 0;
> +        /* Get pre-defined BIOS value */
> +        if ( epp < 0 )
> +        {
> +            if ( rdmsr_safe(MSR_AMD_CPPC_REQ, val) )
> +                return -EINVAL;
> +            data->req.epp = (val >> 24) & 0xFF;

This reading may better live in the sole caller where it's relevant. Plus
it might be yet better if this was read just once, assuming "pre-defined
BIOS value" is what it says (and hence doesn't change during the runtime
of the system).

> @@ -257,7 +276,7 @@ static int cf_check amd_pstate_cpufreq_target(struct cpufreq_policy *policy,
>      min_perf = data->hw.lowest_nonlinear_perf;
>      des_perf = amd_pstate_khz_to_perf(data, target_freq);
>  
> -    return amd_pstate_write_request(policy->cpu, min_perf, des_perf, max_perf);
> +    return amd_pstate_write_request(policy->cpu, min_perf, des_perf, max_perf, -1);
>  }
>  
>  static void cf_check amd_pstate_init_msrs(void *info)
> @@ -354,7 +373,7 @@ static void amd_pstate_boost_init(struct cpufreq_policy *policy, struct amd_psta
>      policy->turbo = CPUFREQ_TURBO_ENABLED;
>  }
>  
> -static int cf_check amd_pstate_cpufreq_cpu_init(struct cpufreq_policy *policy)
> +static int amd_pstate_cpufreq_init_perf(struct cpufreq_policy *policy)
>  {
>      unsigned int cpu = policy->cpu;
>      struct amd_pstate_drv_data *data;
> @@ -379,10 +398,23 @@ static int cf_check amd_pstate_cpufreq_cpu_init(struct cpufreq_policy *policy)
>          return -ENODEV;
>      }
>  
> -    amd_pstate_boost_init(policy, data);
>      return 0;
>  }
>  
> +static int cf_check amd_pstate_cpufreq_cpu_init(struct cpufreq_policy *policy)
> +{
> +    int ret = 0;

Pointless initializer.

> +    struct amd_pstate_drv_data *data;
> +
> +    ret = amd_pstate_cpufreq_init_perf(policy);
> +    if ( ret )
> +        return ret;
> +
> +    data = per_cpu(amd_pstate_drv_data, policy->cpu);
> +    amd_pstate_boost_init(policy, data);
> +    return ret;
> +}
> +
>  static int cf_check amd_pstate_cpufreq_cpu_exit(struct cpufreq_policy *policy)
>  {
>      struct amd_pstate_drv_data *data = per_cpu(amd_pstate_drv_data, policy->cpu);
> @@ -393,6 +425,70 @@ static int cf_check amd_pstate_cpufreq_cpu_exit(struct cpufreq_policy *policy)
>      return 0;
>  }
>  
> +static void amd_perf_ctl_reset(void *data)
> +{
> +    wrmsr_safe(MSR_K8_PSTATE_CTRL, 0);
> +}
> +
> +static int cf_check amd_pstate_epp_cpu_init(struct cpufreq_policy *policy)
> +{
> +    int ret = 0;
> +    struct amd_pstate_drv_data *data;
> +
> +    /*
> +     * Resetting P-State Control register will put the CPU in P0 frequency,
> +     * which is ideal for initialization process.
> +     */
> +    on_selected_cpus(cpumask_of(policy->cpu), amd_perf_ctl_reset, NULL, 1);

How do you/we know what's ideal for initialization? I can think of cases
where it might be better to still conserve power.

> +static int cf_check amd_pstate_epp_update_limit(struct cpufreq_policy *policy)
> +{
> +    struct amd_pstate_drv_data *data = per_cpu(amd_pstate_drv_data, policy->cpu);
> +    uint8_t max_perf, min_perf, des_perf;
> +    int epp = -1;
> +
> +    /* Initial min/max values for CPPC Performance Controls Register */
> +    max_perf = data->hw.highest_perf;
> +    min_perf = data->hw.lowest_perf;
> +
> +    if ( data->policy == CPUFREQ_POLICY_PERFORMANCE )
> +        min_perf = max_perf;

Why can't this be done ...

> +    /* CPPC EPP feature require to set zero to the desire perf bit */
> +    des_perf = 0;
> +
> +    if ( data->policy == CPUFREQ_POLICY_PERFORMANCE )
> +        /* Force the epp value to be zero for performance policy */
> +        epp = CPPC_ENERGY_PERF_MAX_PERFORMANCE;

... here as well? And why is there nothing respective for ...

> +    else if ( data->policy == CPUFREQ_POLICY_POWERSAVE )
> +        /* Force the epp value to be 0xff for powersave policy */
> +        epp = CPPC_ENERGY_PERF_MAX_POWERSAVE;

... this case (e.g. setting max_perf from min_perf)?

> @@ -402,6 +498,15 @@ static const struct cpufreq_driver __initconstrel amd_pstate_cpufreq_driver =
>      .exit   = amd_pstate_cpufreq_cpu_exit,
>  };
>  
> +static const struct cpufreq_driver __initconstrel amd_pstate_epp_driver =

Again: __initconst_cf_clobber.

> @@ -409,4 +514,9 @@ int __init amd_pstate_register_driver(void)
>  
>      if ( !opt_cpufreq_active )
>          return cpufreq_register_driver(&amd_pstate_cpufreq_driver);
> +    else
> +    {
> +        epp_mode = true;

Why a 2nd global variable? Can't you go from opt_cpufreq_active?

> --- a/xen/arch/x86/acpi/cpufreq/hwp.c
> +++ b/xen/arch/x86/acpi/cpufreq/hwp.c
> @@ -21,10 +21,6 @@ static bool __ro_after_init feature_hdc;
>  
>  static bool __ro_after_init opt_cpufreq_hdc = true;
>  
> -#define HWP_ENERGY_PERF_MAX_PERFORMANCE 0
> -#define HWP_ENERGY_PERF_BALANCE         0x80
> -#define HWP_ENERGY_PERF_MAX_POWERSAVE   0xff
> -
>  union hwp_request
>  {
>      struct
> @@ -597,7 +593,7 @@ int set_hwp_para(struct cpufreq_policy *policy,
>          data->minimum = data->hw.lowest;
>          data->maximum = data->hw.lowest;
>          data->activity_window = 0;
> -        data->energy_perf = HWP_ENERGY_PERF_MAX_POWERSAVE;
> +        data->energy_perf = CPPC_ENERGY_PERF_MAX_POWERSAVE;
>          data->desired = 0;
>          break;
>  
> @@ -605,7 +601,7 @@ int set_hwp_para(struct cpufreq_policy *policy,
>          data->minimum = data->hw.highest;
>          data->maximum = data->hw.highest;
>          data->activity_window = 0;
> -        data->energy_perf = HWP_ENERGY_PERF_MAX_PERFORMANCE;
> +        data->energy_perf = CPPC_ENERGY_PERF_MAX_PERFORMANCE;
>          data->desired = 0;
>          break;
>  
> @@ -613,7 +609,7 @@ int set_hwp_para(struct cpufreq_policy *policy,
>          data->minimum = data->hw.lowest;
>          data->maximum = data->hw.highest;
>          data->activity_window = 0;
> -        data->energy_perf = HWP_ENERGY_PERF_BALANCE;
> +        data->energy_perf = CPPC_ENERGY_PERF_BALANCE;
>          data->desired = 0;
>          break;
>  
> diff --git a/xen/include/acpi/cpufreq/cpufreq.h b/xen/include/acpi/cpufreq/cpufreq.h
> index cad27f6811..d2a74d8315 100644
> --- a/xen/include/acpi/cpufreq/cpufreq.h
> +++ b/xen/include/acpi/cpufreq/cpufreq.h
> @@ -83,6 +83,7 @@ struct cpufreq_policy {
>      int8_t              turbo;  /* tristate flag: 0 for unsupported
>                                   * -1 for disable, 1 for enabled
>                                   * See CPUFREQ_TURBO_* below for defines */
> +    unsigned int        policy;
>  };
>  DECLARE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_policy);
>  
> @@ -264,6 +265,10 @@ void cpufreq_dbs_timer_resume(void);
>  
>  void intel_feature_detect(struct cpufreq_policy *policy);
>  
> +#define CPPC_ENERGY_PERF_MAX_PERFORMANCE 0
> +#define CPPC_ENERGY_PERF_BALANCE         0x80
> +#define CPPC_ENERGY_PERF_MAX_POWERSAVE   0xff

I guess this renaming / movement might better be a separate patch. The more
that the description here doesn't even mention, let alone justify, it.

> --- a/xen/include/public/sysctl.h
> +++ b/xen/include/public/sysctl.h
> @@ -425,7 +425,7 @@ struct xen_set_cppc_para {
>  
>  #define XEN_HWP_DRIVER_NAME "hwp"
>  #define XEN_AMD_PSTATE_DRIVER_NAME "amd-pstate"
> -
> +#define XEN_AMD_PSTATE_EPP_DRIVER_NAME "amd-pstate-epp"
>  /*

Please don't lose blank lines like this.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 11:39:09 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 11:39:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868256.1279786 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVqsX-00011Y-1t; Thu, 09 Jan 2025 11:39:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868256.1279786; Thu, 09 Jan 2025 11:39:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVqsW-00011R-VP; Thu, 09 Jan 2025 11:39:08 +0000
Received: by outflank-mailman (input) for mailman id 868256;
 Thu, 09 Jan 2025 11:39:08 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=L5Ho=UB=bounce.vates.tech=bounce-md_30504962.677fb558.v1-5baddbac78034d9b9528adcbd1fb4e16@srs-se1.protection.inumbo.net>)
 id 1tVqsW-0000Vv-2V
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 11:39:08 +0000
Received: from mail134-8.atl141.mandrillapp.com
 (mail134-8.atl141.mandrillapp.com [198.2.134.8])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 54cfc87e-ce7e-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 12:39:06 +0100 (CET)
Received: from pmta10.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail134-8.atl141.mandrillapp.com (Mailchimp) with ESMTP id
 4YTN944dvqz3sNF3J
 for <xen-devel@lists.xenproject.org>; Thu,  9 Jan 2025 11:39:04 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 5baddbac78034d9b9528adcbd1fb4e16; Thu, 09 Jan 2025 11:39:04 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 54cfc87e-ce7e-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1736422744; x=1736683244;
	bh=GB2IXALSZwQ6L6N+NFfbr5YEU5a2ocAWK0V0XWGm/NA=;
	h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=ffX7gGRNQcD6akYmPZUh+Y6LdE7e5B/jopVosLvI+7ms0MeAmEAMYt+sbvfpgFHHk
	 zkZnsdxt7kRjRfpT4HYKdEWDlaVap/wjxlUantX4buy72+nIuE47DM3MoRyGBGI1cy
	 HWyK06Z8nn1iXp9bQGx92zMvK7CP0BoPfQJy4ZSsjoctaW5J/rCvXE1Mic6Hm9FO/q
	 9YFsg512rd/wPlr+sFM4ZuxXcJ3C/w+wYfu8D6O+cZgTtbAbRFhLg9uVRay02b/owB
	 33f8IvjEPY1PGgw+/swRoQlwKQdTT+rgegpLEm0Dqo1JR11FSQgKtpaSsMosxPWUED
	 vfFwSL+2WKZxQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1736422744; x=1736683244; i=teddy.astie@vates.tech;
	bh=GB2IXALSZwQ6L6N+NFfbr5YEU5a2ocAWK0V0XWGm/NA=;
	h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=yNU2irGYiGTdFhVGndScrLK2LU4Szo1OeP8wEIpb3cIYSBAKpyCTeARmCZpCXj+8p
	 5HiQ0wCC5Q0PMRd+j1yaDD24Uazb14jAnDgrOaDslkbH1/ad//qmsjYh7eRGpl2jeY
	 fgn0G7adN74He2AHYZTrhBlJ9xcNcPsUWBzQTPtZVsTjOKxFfOsGdzykZe3UOltqVE
	 fCBD82M6aDbC80oyqmH/LkjpoRBm+s3up9iwqjhMlF41DvSkhpC/V2kMP99gFDnl9E
	 AdCIf0qi++aUSwT6Y4vJNquPKetVmU1/FvTypuOv8aDYgvreRjc4hnykyJr8/MWtpj
	 vonn6B1putm5g==
From: "Teddy Astie" <teddy.astie@vates.tech>
Subject: =?utf-8?Q?Re:=20[XEN=20RFC=20PATCH=20v4=200/5]=20IOMMU=20subsystem=20redesign=20and=20PV-IOMMU=20interface?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1736422742651
Message-Id: <c0b9fbdb-87db-4f31-8069-0c2d1c4ad4cd@vates.tech>
To: "=?utf-8?Q?Marek=20Marczykowski-G=C3=B3recki?=" <marmarek@invisiblethingslab.com>, Xen-devel <xen-devel@lists.xenproject.org>
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>, "Jan Beulich" <jbeulich@suse.com>, "Julien Grall" <julien@xen.org>, "Stefano Stabellini" <sstabellini@kernel.org>, "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>, "Lukasz Hawrylko" <lukasz@hawrylko.pl>, "Daniel P. Smith" <dpsmith@apertussolutions.com>, "=?utf-8?Q?Mateusz=20M=C3=B3wka?=" <mateusz.mowka@intel.com>
References: <cover.1730718102.git.teddy.astie@vates.tech> <Z38-y9xR-6C_sARJ@mail-itl>
In-Reply-To: <Z38-y9xR-6C_sARJ@mail-itl>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.5baddbac78034d9b9528adcbd1fb4e16?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250109:md
Date: Thu, 09 Jan 2025 11:39:04 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Thanks for your review.

> Hi,
> 
> I finally got time to try this revision (sorry it took so long!). My
> goal was to test it this time with some HVM domU too. I didn't get very
> far...
> 
> Issues I hit:
> 
> 1. AMD IOMMU driver is not converted (fails to build), for now disabled
>     CONFIG_AMD_IOMMU.

I haven't really worked on the AMD-Vi code yet. I have plans for it but 
there is some specific bits to deal with (especially regarding interrupt 
remapping), that I planned to discuss especially during the Xen Project 
Winter Summit 2025.

> 2. PV shim build fails (linker fails to find p2m_add_identity_entry
>     symbol referenced from iommu.c)

I haven't considered PV shim yet, so I am not really surprised that 
there are some issues with it. We probably want to expose some PV-IOMMU 
features for PV guests under PV shim, but it probably needs some 
specific code for it.

> 3. Xen complains on boot about missing endbr64 (surprisingly, it didn't
>     exploded):
> 
>      (XEN) alt table ffff82d0404234d8 -> ffff82d040432d82
>      (XEN) altcall iommu_get_max_iova+0x11/0x30 dest iommu.c#intel_iommu_get_max_iova has no endbr64
>      (XEN) altcall context.c#iommu_reattach_phantom+0x30/0x50 dest iommu.c#intel_iommu_add_devfn has no endbr64
>      (XEN) altcall context.c#iommu_detach_phantom+0x25/0x40 dest iommu.c#intel_iommu_remove_devfn has no endbr64
>      (XEN) altcall iommu_context_init+0x27/0x40 dest iommu.c#intel_iommu_context_init has no endbr64
>      (XEN) altcall iommu_attach_context+0x3c/0xd0 dest iommu.c#intel_iommu_attach has no endbr64
>      (XEN) altcall context.c#iommu_attach_context.cold+0x1d/0x53 dest iommu.c#intel_iommu_detach has no endbr64
>      (XEN) altcall iommu_detach_context+0x37/0xa0 dest iommu.c#intel_iommu_detach has no endbr64
>      (XEN) altcall iommu_reattach_context+0x95/0x240 dest iommu.c#intel_iommu_reattach has no endbr64
>      (XEN) altcall context.c#iommu_reattach_context.cold+0x29/0x110 dest iommu.c#intel_iommu_reattach has no endbr64
>      (XEN) altcall iommu_context_teardown+0x3f/0xa0 dest iommu.c#intel_iommu_context_teardown has no endbr64
>      (XEN) altcall pci.c#deassign_device+0x99/0x270 dest iommu.c#intel_iommu_add_devfn has no endbr64
> 

I also see that, but I am not sure what I need to do to fix it.

> 4. Starting a HVM domU with PCI device fails with:
> 
>      libxl: libxl_pci.c:1552:pci_add_dm_done: Domain 1:xc_assign_device failed: No space left on device
>      libxl: libxl_pci.c:1875:device_pci_add_done: Domain 1:libxl__device_pci_add failed for PCI device 0:aa:0.0 (rc -3)
>      libxl: libxl_create.c:2061:domcreate_attach_devices: Domain 1:unable to add pci devices
> > I didn't change anything in the toolstack - maybe default context needs
> to be initialized somehow? But the docs suggest the default context
> should work out of the box. On the other hand, changelog for v4 says
> some parts are moved to the toolstack, but I don't see any changes in
> tools/ in this series...
> 

I only tried stuff inside Dom0, but I haven't really tried passing 
through a device. I think I missed some step regarding quarantine domain 
initialization, which is probably why you have "-ENOSPC" here. You can 
try in the meantime to set "quarantine=0" to disable this part to see if 
it progresses further.

I will plan to do some testing on usual PCI passthrough to see if there 
are issues there.

> FWIW The exact version I tried is this (this series, on top of staging +
> qubes patches):
> https://github.com/QubesOS/qubes-vmm-xen/pull/200
> At this stage, dom0 kernel didn't have PV-IOMMU driver included yet.
> 
> Full Xen log, with some debug info collected:
> https://gist.github.com/marmarek/e7ac2571df033c7181bf03f21aa5f9ab
> 

Thanks
Teddy



Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 11:41:12 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 11:41:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868264.1279797 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVquU-0002mP-Db; Thu, 09 Jan 2025 11:41:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868264.1279797; Thu, 09 Jan 2025 11:41:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVquU-0002mC-AU; Thu, 09 Jan 2025 11:41:10 +0000
Received: by outflank-mailman (input) for mailman id 868264;
 Thu, 09 Jan 2025 11:41:08 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=pS5t=UB=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVquS-0002li-Hp
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 11:41:08 +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 9cf0670c-ce7e-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 12:41:06 +0100 (CET)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-436a03197b2so6128825e9.2
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 03:41:06 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a8e38325esm1584654f8f.27.2025.01.09.03.41.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 03:41:04 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9cf0670c-ce7e-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736422866; x=1737027666; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=oxVD6y4d9SM2rJppq1GBU+IIPaVbG00ujPSU1JPCEik=;
        b=DZGu2EuXKx22QQ2mpftUKf5zyBUIiD9kreoYEYAULPU8oticLtqSp0mdwpEBp8R6Wz
         U4l5AgT2Je+35LtqNx/I8p0eFgqQ80qtPqrxRuSNIpLV9utL1re9YPHrnC5eYmTZ3qEj
         V6uEBSukajRCZy4ujifk3tAuB0L7IRbFA1nSUW0b/n04A4QAdUVva53laDgIAXjk5sKC
         FpXLskMLbWPi9OIIdNZwpmBLkew5Nu1NdFhVOkIQ4f29AP0CFzU1OSLP7nquxtIqv25i
         PsvnLJE8cBGXhEc8E0TvlNsSsbeOR+lWXZLvdjoMeT/1ejodn10iHc9JqsjF2JIGezzj
         MPlQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736422866; x=1737027666;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=oxVD6y4d9SM2rJppq1GBU+IIPaVbG00ujPSU1JPCEik=;
        b=n//AGxFUiMwkJJ7KLzzO1BOcAfsx9mkOn9IK0mkwpaUUk327Z66t4vC4bB/OfrgwPq
         vftxzFn+G+4kgIwCJ55eDCQXC8ig1VpaZsOxwRlemoTjHUFJr0wGeBUfGoqi4S4/prAR
         daghcNELyV70hPrBVE2bKNmrKqer/VnHRRAytzU4I0mt69QZ4j3X+JxUynxZ6NCD76Gr
         P4MBcQoW4eJ8GORppoKonX6Ov7J0Ee/SWEKHTIpCp0up/3soE1tbYYnGSTMdckx3UJhd
         tDWV/VUuK1Rctx3c8jdCX5BhVRh+D/5m/J9xXuSDibLcuLgSVWCAkg87Xt77PG4/IiLz
         3zOQ==
X-Forwarded-Encrypted: i=1; AJvYcCUaO3mCT5Ifvy7tRt//N72OG9YPH21j/jDGJmeH4m2OiLiQ0nmeF12hpt1DcRJFqKRWcD9+RFE2oqc=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy8hhwJ50JVwnRGwImmZHo609fPtLfP2JtoHRFQ+w9ttxeSxdXk
	AL+qP4Dez4yOrAEPCRD65xYsjNP5qbuIiJGLZF0bXahVP8KpXfxKPnJrKWpang==
X-Gm-Gg: ASbGncs77BcTAvPFeFNP372nbl7cQs9WQOrN+2cH5wjP+5krIRkm3ReHeg5aoAC6OML
	GVx9apx/gw2nfxqMgUUC9Usn6tEsaEDmHt2TpUvkWbXBb46ZQ7u46jRHsiNu+fKfNLE4yJLzzrG
	B5lQ3VeC4Gn1tnQfaVKhVkMQk0Mp9tyuoP6acmkMIK3TJasrTBVF8JpIACRZ1B+JYWnOGjMvBuk
	W58oqjoendZRftS+Er4eRe7iroA3/yZax7eD8ifTRE0KIBbuwSMa6reuK/S7V6+qoNMPrDAoWwb
	0QWv8VA1w2c/Yfwwc44jQW5MlY7vrdT+xLGufNpx2w==
X-Google-Smtp-Source: AGHT+IF4p/LoBM02ldexHZ5PTrBNdrUYJE+ewCUZRjZZ+//s8uMHICFnFLJZgwlRSw/7MEipx1Z3uQ==
X-Received: by 2002:a05:600c:1384:b0:436:1c04:aa8e with SMTP id 5b1f17b1804b1-436e26bdac1mr65634175e9.16.1736422864657;
        Thu, 09 Jan 2025 03:41:04 -0800 (PST)
Message-ID: <6151a6e7-033f-4d52-8969-db3796df856b@suse.com>
Date: Thu, 9 Jan 2025 12:41:02 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 10/11] tools/xenpm: Print CPPC parameters for
 amd-pstate driver
To: Penny Zheng <Penny.Zheng@amd.com>
Cc: stefano.stabellini@amd.com, Ray.Huang@amd.com, Xenia.Ragiadakou@amd.com,
 Jason.Andryuk@amd.com, Anthony PERARD <anthony.perard@vates.tech>,
 xen-devel@lists.xenproject.org
References: <20241203083315.463511-1-Penny.Zheng@amd.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20241203083315.463511-1-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 03.12.2024 09:33, Penny Zheng wrote:
> --- a/tools/misc/xenpm.c
> +++ b/tools/misc/xenpm.c
> @@ -787,12 +787,22 @@ static unsigned int calculate_activity_window(const xc_cppc_para_t *cppc,
>      return mantissa * multiplier;
>  }
>  
> +
>  /* print out parameters about cpu frequency */

No double blank lines please. With this taken care of:
Acked-by: Jan Beulich <jbeulich@suse.com>

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 11:49:35 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 11:49:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868275.1279806 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVr2Y-0003cs-3e; Thu, 09 Jan 2025 11:49:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868275.1279806; Thu, 09 Jan 2025 11:49:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVr2Y-0003cl-11; Thu, 09 Jan 2025 11:49:30 +0000
Received: by outflank-mailman (input) for mailman id 868275;
 Thu, 09 Jan 2025 11:49:28 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=pS5t=UB=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVr2W-0003cd-4N
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 11:49:28 +0000
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com
 [2a00:1450:4864:20::336])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c6973af8-ce7f-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 12:49:26 +0100 (CET)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-436326dcb1cso6365355e9.0
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 03:49:26 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a8e4b83a1sm1617796f8f.75.2025.01.09.03.49.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 03:49:25 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c6973af8-ce7f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736423365; x=1737028165; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=BqTijWzRaoMl6tj6ci7unJZZa7zJZ5zmJ32h6eYii7M=;
        b=NIssC0cTJC2zcQfzJB26jdtGSSptrQHcLxs+7Tg3CwpmwH84WVn7DmKCiYNrstTwvh
         WtqMVDNAqWanEtGD/AI4YUbnHu4kmQMU2pPqpRlQ/vNBl8F1ri01ohvDk7Zdrelyh88s
         C3tlZMX3OGe15SMJvwkUpZlZzlrtpRL9wZ8NSlol0VGElvpYZxtLKWKeiX98eFnKYcpA
         JfExSUNZ57Vf06UE72VJ9QRrdLd+uQ3ZO3GDQYsQU5SZR9hi9G6CkS2N+n7lu/5kmibt
         0MEliDwkrwiklFpYBqyjhK5ev6PaPQuM9N1j4ZA40UuEAKS+N7OKFgOqJbCKkU+YzVy5
         8Nlw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736423365; x=1737028165;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=BqTijWzRaoMl6tj6ci7unJZZa7zJZ5zmJ32h6eYii7M=;
        b=DCEy/OOdcKYF2hrWfgI0EVkb/PzQx+avDSPXAB8Tqqidjm7/+ttKc4DkN5eIeSWXWY
         3xh5gqLxh1i2tu3QKnNjdiUUPS2eTnOOCwd7gf3BCej6yFyllznQu/4P6NF9eXCvKoGq
         MRavO3lBASVxVlMTyayTiKrc3VheTItrlFLfkIErmhAGvTuGuh8Xmf5WKxNqSMsviERp
         52Q2iuA1EP5XxhUKqoiAdvojmFm24tnTmjTA/dxg5til94KJSINgpIadGwj03YghDafD
         gpjRKq4KSoP9b/ZrDiED6lhjUHH/m0XkbPgK4STsuBFLygwBwDggvwrXByn0hM1beZj3
         btTQ==
X-Forwarded-Encrypted: i=1; AJvYcCUWiTNLtv64JDJCBNfMLNg1hEPzKEHjE5EW5g/Jda7gd35nWcAoZeV4r5hsCrXIY5+9rat4k1eJ6wo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwUVeUeKO+NYRs/RPOlqVd16Ix83HkTQpn/jOjljBVzhw1cjttH
	KvZ/dIBjLB8bGPNRTVaMqrYBQwutccM05yOKRzMPESdPqb4OVvbXU3MZ8buIwQ==
X-Gm-Gg: ASbGncuxU/37Cd+yckdYVSuDhGCC7hs0KpgR+dVlbd4x8ieO9bg65d+v8KxrmimNItz
	hU+K1OsHK47IGBEb0O4zJoG9NoARLYteBpMo/h7fRmLCcO6WFqfAPly3G/pmAEdbm3YrbCjCrca
	WxXBwlFlD1dN1Miclx9j3r4v6LCz3JixTMOYAWuyRpfE99l1DKq2MQZBPn/M11Pl3HEBjUKF+ZJ
	sNf60ZPzHVlc8RGZWJvjJqN9l9766XdZCcBJd0lNI6rjDfh01ma4gnjSYjbots2DVciEqDlUCNd
	8xW0fKVv9R5zM5PLJTiljcYnt4BCBdCOZJDuVc+Bpg==
X-Google-Smtp-Source: AGHT+IEiypxfvEM3ZJrIkD+ueEFB3nXJ0wpatHPDvgxCa1bPdM34RaPV4malYUTA65QbetPKj4Jpbg==
X-Received: by 2002:a05:600c:1c1a:b0:434:f2f4:4c07 with SMTP id 5b1f17b1804b1-436e26bd126mr62689665e9.15.1736423365421;
        Thu, 09 Jan 2025 03:49:25 -0800 (PST)
Message-ID: <66beb3b1-5d67-4d1f-beb0-3429f387c2fb@suse.com>
Date: Thu, 9 Jan 2025 12:49:23 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 11/11] xen/cpufreq: Adapt SET/GET_CPUFREQ_CPPC
 xen_sysctl_pm_op for amd-pstate driver
To: Penny Zheng <Penny.Zheng@amd.com>
Cc: stefano.stabellini@amd.com, Ray.Huang@amd.com, Xenia.Ragiadakou@amd.com,
 Jason.Andryuk@amd.com, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20241203083535.463533-1-Penny.Zheng@amd.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20241203083535.463533-1-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 03.12.2024 09:35, Penny Zheng wrote:
> @@ -489,6 +491,117 @@ static int cf_check amd_pstate_epp_set_policy(struct cpufreq_policy *policy)
>      return amd_pstate_epp_update_limit(policy);
>  }
>  
> +int get_amd_cppc_para(unsigned int cpu,
> +                      struct xen_cppc_para *cppc_para)
> +{
> +    struct amd_pstate_drv_data *data = per_cpu(amd_pstate_drv_data, cpu);
> +
> +    if ( data == NULL )
> +        return -ENODATA;
> +
> +    cppc_para->features         = 0;
> +    cppc_para->lowest           = data->hw.lowest_perf;
> +    cppc_para->lowest_nonlinear = data->hw.lowest_nonlinear_perf;
> +    cppc_para->nominal          = data->hw.nominal_perf;
> +    cppc_para->highest          = data->hw.highest_perf;
> +    cppc_para->minimum          = data->req.min_perf;
> +    cppc_para->maximum          = data->req.max_perf;
> +    cppc_para->desired          = data->req.des_perf;
> +    cppc_para->energy_perf      = data->req.epp;
> +
> +    return 0;
> +}
> +
> +int set_amd_cppc_para(struct cpufreq_policy *policy,
> +                      struct xen_set_cppc_para *set_cppc)
> +{
> +    unsigned int cpu = policy->cpu;
> +    struct amd_pstate_drv_data *data = per_cpu(amd_pstate_drv_data, cpu);
> +    uint8_t max_perf, min_perf, des_perf;
> +    int epp = -1;
> +
> +    if ( data == NULL )
> +        return -ENOENT;
> +
> +    /* Validate all parameters - Disallow reserved bits. */
> +    if ( set_cppc->minimum > 255 || set_cppc->maximum > 255 ||
> +         set_cppc->desired > 255 || set_cppc->energy_perf > 255 )
> +        return -EINVAL;
> +
> +    /* Only allow values if params bit is set. */
> +    if ( (!(set_cppc->set_params & XEN_SYSCTL_CPPC_SET_DESIRED) &&
> +          set_cppc->desired) ||
> +         (!(set_cppc->set_params & XEN_SYSCTL_CPPC_SET_MINIMUM) &&
> +          set_cppc->minimum) ||
> +         (!(set_cppc->set_params & XEN_SYSCTL_CPPC_SET_MAXIMUM) &&
> +          set_cppc->maximum) ||
> +         (!(set_cppc->set_params & XEN_SYSCTL_CPPC_SET_ENERGY_PERF) &&
> +          set_cppc->energy_perf) )
> +        return -EINVAL;
> +
> +    /* Activity window not supported */
> +    if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_ACT_WINDOW )
> +        return -EINVAL;
> +
> +    /* Return if there is nothing to do. */
> +    if ( set_cppc->set_params == 0 )
> +        return 0;
> +
> +    /* Apply presets */
> +    switch ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_PRESET_MASK )
> +    {
> +    case XEN_SYSCTL_CPPC_SET_PRESET_POWERSAVE:
> +        if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_DESIRED )
> +            return -EINVAL;
> +        min_perf = data->hw.lowest_perf;
> +        max_perf = data->hw.highest_perf;

These are the same as ...

> +        epp = CPPC_ENERGY_PERF_MAX_POWERSAVE;
> +        des_perf = 0;
> +        break;
> +
> +    case XEN_SYSCTL_CPPC_SET_PRESET_PERFORMANCE:
> +        if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_DESIRED )
> +            return -EINVAL;
> +        min_perf = data->hw.highest_perf;
> +        max_perf = data->hw.highest_perf;
> +        epp = CPPC_ENERGY_PERF_MAX_PERFORMANCE;
> +        des_perf = 0;
> +        break;
> +
> +    case XEN_SYSCTL_CPPC_SET_PRESET_BALANCE:
> +        if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_DESIRED )
> +            return -EINVAL;
> +        min_perf = data->hw.lowest_perf;
> +        max_perf = data->hw.highest_perf;

... these, despite the presets being quite different - why?

> +        epp = CPPC_ENERGY_PERF_BALANCE;
> +        des_perf = 0;
> +        break;
> +
> +    case XEN_SYSCTL_CPPC_SET_PRESET_NONE:
> +        min_perf = data->hw.lowest_nonlinear_perf;
> +        max_perf = data->hw.highest_perf;
> +        break;

Rather than setting des_perf to 0 everywhere except here (thus leaving it
potentially uninitialized), better give the variable an initializer of 0?

> --- a/xen/drivers/acpi/pmstat.c
> +++ b/xen/drivers/acpi/pmstat.c
> @@ -198,6 +198,7 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op *op)
>      char     *scaling_available_governors;
>      struct list_head *pos;
>      uint32_t cpu, i, j = 0;
> +    bool hw_auto = false;
>  
>      pmpt = processor_pminfo[op->cpuid];
>      policy = per_cpu(cpufreq_cpu_policy, op->cpuid);
> @@ -258,7 +259,19 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op *op)
>           !strncmp(op->u.get_para.scaling_driver, XEN_HWP_DRIVER_NAME,
>                    CPUFREQ_NAME_LEN) )
>          ret = get_hwp_para(policy->cpu, &op->u.get_para.u.cppc_para);
> -    else
> +    else if ( !strncmp(op->u.get_para.scaling_driver, XEN_AMD_PSTATE_DRIVER_NAME,
> +                       CPUFREQ_NAME_LEN) ||
> +              !strncmp(op->u.get_para.scaling_driver, XEN_AMD_PSTATE_EPP_DRIVER_NAME,
> +                       CPUFREQ_NAME_LEN) )
> +        ret = get_amd_cppc_para(policy->cpu, &op->u.get_para.u.cppc_para);

Like if is here, ...

> +    if ( !strncmp(op->u.get_para.scaling_driver, XEN_HWP_DRIVER_NAME,
> +                 CPUFREQ_NAME_LEN) ||
> +         !strncmp(op->u.get_para.scaling_driver, XEN_AMD_PSTATE_EPP_DRIVER_NAME,
> +                 CPUFREQ_NAME_LEN) )
> +        hw_auto = true;
> +
> +    if ( !hw_auto )

... why not use the strncmp()s directly in the if()?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 11:51:02 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 11:51:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868286.1279817 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVr41-0005QZ-H2; Thu, 09 Jan 2025 11:51:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868286.1279817; Thu, 09 Jan 2025 11:51:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVr41-0005QS-EM; Thu, 09 Jan 2025 11:51:01 +0000
Received: by outflank-mailman (input) for mailman id 868286;
 Thu, 09 Jan 2025 11:51:00 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=pS5t=UB=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVr40-0005QI-57
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 11:51:00 +0000
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com
 [2a00:1450:4864:20::334])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id fe19c70f-ce7f-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 12:50:59 +0100 (CET)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-436341f575fso8919465e9.1
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 03:50:59 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436e2ddca2dsm52559985e9.21.2025.01.09.03.50.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 03:50:58 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: fe19c70f-ce7f-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736423459; x=1737028259; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=H9m8LioseIqRAUAmVRhVyBB7x2L9TDN3Hr8T1J8beSU=;
        b=GMrldDCLwRpmUeXJgzYDnJBrbB49GdP7jhh7M+1EUH2snnkiQc8Su541B5Ye6V6ECb
         N+ucLOpOIXXhw+0qpfhJjXdHlJqMtoqvk144erAmof073DgZusaCGdMNyVhmSNONsAX7
         lR5B3Ch7cWDMp0mQsqAQcBbZ+X1d57qC0uEsrkIYulSAeTIZJypB0IIDRDF1LQ99kVln
         6eDB3sCHJFbf2wG2ugyST1uqGVcw9AKqgJ71JU/3LGC0viX0bUZUUzKEYGfi6Rn5uyr6
         Zx2rXv7OK1UcT12N3Xm06UgRRqaOQuP3kpH3bs80vG1kLqzY6ahL0Rvfzebw8TFJddPu
         DMHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736423459; x=1737028259;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=H9m8LioseIqRAUAmVRhVyBB7x2L9TDN3Hr8T1J8beSU=;
        b=b+CEWj3bfYVvARZKJ6x4pWpmaSVmPdxuyObkvCw7vosgtv2VHkO3XGrO3ny8RRHNv0
         KbSUSVxPQNTFMSekzjwQLaJ0iN/fD8hyhNjwusxwf+DWVVfRsITyyrIMl+ko6zAgHTNy
         odImXVBCKZY7IglfBYodA5BztdgcU9wliNjs2hnmeM4VENvoKdG12cqN15nA/nRVFSOd
         8aCL4fQk2AJu5Zx1lkkd2vzjCIEshPy+BhE6EIUIM/ByjH4rL4O8VeUicvuhqXkEHfpy
         b4GVIH+7i/QA8TB0srhMz4qdZ7ITui/ppjYA4JLmJfdJkW8Sd4phiUoWRmzOIVhpIDhk
         0dMw==
X-Forwarded-Encrypted: i=1; AJvYcCUQJJ6VYpz8b5EPWbhf3vqJq40sJ0oRE+DSMq9aQfmtADkYxPwvsDtn4M8LLTIzEdneyeYRWobIJ4Q=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzcapTmI9iKD6fUo1M2pd8vAd8uto2NPLfbVLnwivLaihsxEb8h
	HfRzzFztDQWDUm/ugwZwx/EMZDBHP/o1sZmhK2WKt3hEHDxaMOpQNSRLG8wBV/0J1/3bb5YvLVA
	=
X-Gm-Gg: ASbGnct/2JoUbKFx24ikNXL8OTgk+ZQmm6p3MD8v7knsmeiWpbAKY5X2U4zvtKPMnY4
	LrCHBDi9+zPBt0pwsmHz1E2PidsVEi+m7mPvhyQlvrPvKQulHP2CxytPpofAVes8PttF0GxdrZQ
	100OTbBemrmOkch5/QtmHcogaaME56HOMdllYXLGvi/pS8UfsFca/SgmkSskd3Ook/9jiTmUdqX
	lPQyUyVpEFYg7jkWpRG7Glh56sT9zPpMpRPbn92nhyI7Lnpv4p8JlC1uFs+3OTxGEXJpZ7mS67R
	LrTR5U23aGgIfUWUrA9R1cuwNqYDo0oSFJHDZ+reow==
X-Google-Smtp-Source: AGHT+IGCv3s8wq4GwM89JKsOUNktDSiI6s9eEiG+tuGsk01df+4ki07ESE7Fi0CdRLVNGqMruUXoDA==
X-Received: by 2002:a05:600c:314e:b0:434:f5c0:329f with SMTP id 5b1f17b1804b1-436e2697947mr64735685e9.14.1736423458687;
        Thu, 09 Jan 2025 03:50:58 -0800 (PST)
Message-ID: <ec04cc3a-8d35-4a56-a956-f36041d5e54b@suse.com>
Date: Thu, 9 Jan 2025 12:50:56 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN RFC PATCH v4 0/5] IOMMU subsystem redesign and PV-IOMMU
 interface
To: Teddy Astie <teddy.astie@vates.tech>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Lukasz Hawrylko <lukasz@hawrylko.pl>,
 "Daniel P. Smith" <dpsmith@apertussolutions.com>,
 =?UTF-8?Q?Mateusz_M=C3=B3wka?= <mateusz.mowka@intel.com>,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, Xen-devel <xen-devel@lists.xenproject.org>
References: <cover.1730718102.git.teddy.astie@vates.tech>
 <Z38-y9xR-6C_sARJ@mail-itl> <c0b9fbdb-87db-4f31-8069-0c2d1c4ad4cd@vates.tech>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <c0b9fbdb-87db-4f31-8069-0c2d1c4ad4cd@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 09.01.2025 12:39, Teddy Astie wrote:
>> 3. Xen complains on boot about missing endbr64 (surprisingly, it didn't
>>     exploded):
>>
>>      (XEN) alt table ffff82d0404234d8 -> ffff82d040432d82
>>      (XEN) altcall iommu_get_max_iova+0x11/0x30 dest iommu.c#intel_iommu_get_max_iova has no endbr64
>>      (XEN) altcall context.c#iommu_reattach_phantom+0x30/0x50 dest iommu.c#intel_iommu_add_devfn has no endbr64
>>      (XEN) altcall context.c#iommu_detach_phantom+0x25/0x40 dest iommu.c#intel_iommu_remove_devfn has no endbr64
>>      (XEN) altcall iommu_context_init+0x27/0x40 dest iommu.c#intel_iommu_context_init has no endbr64
>>      (XEN) altcall iommu_attach_context+0x3c/0xd0 dest iommu.c#intel_iommu_attach has no endbr64
>>      (XEN) altcall context.c#iommu_attach_context.cold+0x1d/0x53 dest iommu.c#intel_iommu_detach has no endbr64
>>      (XEN) altcall iommu_detach_context+0x37/0xa0 dest iommu.c#intel_iommu_detach has no endbr64
>>      (XEN) altcall iommu_reattach_context+0x95/0x240 dest iommu.c#intel_iommu_reattach has no endbr64
>>      (XEN) altcall context.c#iommu_reattach_context.cold+0x29/0x110 dest iommu.c#intel_iommu_reattach has no endbr64
>>      (XEN) altcall iommu_context_teardown+0x3f/0xa0 dest iommu.c#intel_iommu_context_teardown has no endbr64
>>      (XEN) altcall pci.c#deassign_device+0x99/0x270 dest iommu.c#intel_iommu_add_devfn has no endbr64
>>
> 
> I also see that, but I am not sure what I need to do to fix it.

Add cf_check to the functions in question, I guess.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 12:08:58 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 12:08:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868303.1279827 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVrL7-0007kX-1c; Thu, 09 Jan 2025 12:08:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868303.1279827; Thu, 09 Jan 2025 12:08:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVrL6-0007kQ-Uh; Thu, 09 Jan 2025 12:08:40 +0000
Received: by outflank-mailman (input) for mailman id 868303;
 Thu, 09 Jan 2025 12:08:39 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=eYg4=UB=invisiblethingslab.com=marmarek@srs-se1.protection.inumbo.net>)
 id 1tVrL5-0007kK-4R
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 12:08:39 +0000
Received: from fout-a3-smtp.messagingengine.com
 (fout-a3-smtp.messagingengine.com [103.168.172.146])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7321f6f4-ce82-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 13:08:35 +0100 (CET)
Received: from phl-compute-05.internal (phl-compute-05.phl.internal
 [10.202.2.45])
 by mailfout.phl.internal (Postfix) with ESMTP id D6B6613808F2;
 Thu,  9 Jan 2025 07:08:33 -0500 (EST)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-05.internal (MEProxy); Thu, 09 Jan 2025 07:08:33 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 9 Jan 2025 07:08:30 -0500 (EST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 7321f6f4-ce82-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm2; t=1736424513;
	 x=1736510913; bh=kECteZPoKXf9xMfmh68/LbiCRmgtBv9vdGOcf89P5PY=; b=
	r3f2mMQRy5G0oFHzU8x21odkXjQQkQZEeq6aV5scgYx689oY5WEPgQMxaBkuOXnA
	Rgmuf5GWnGpiohRKK8CLiOWlezsrct42Q04C5wqggMLNVa8JmTifdFTE/rPyCMot
	Fq0rAaADIyxzPoGWZnY+1AY5NiV8pFRaZL+Xk5EervhMNv/dSKh4xApPo6JFeQBz
	qMdNCw3IW6ul1WXaySgjp1CmWB3k0VIUcyC0jq+r3rkLa0wo245tbXA4YWEMvmQ4
	i+vyff5gfbtNR8FBMANlwtLY4puXNISWY5u/uKBDP51tF+kH3DvNihuqHC+45vP/
	VJ0x98ZKMwgG0d0QqPGJbA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:subject:subject:to
	:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=
	1736424513; x=1736510913; bh=kECteZPoKXf9xMfmh68/LbiCRmgtBv9vdGO
	cf89P5PY=; b=HPDpMDuX3cq+CuvCa9dgCP3bwXaHJD2CzaDZ8WZKvJYaRy65WbM
	BM1nDunT+OnqgEVTNrFyG8Ph+wQJ5YlPkOiGtKmzaf7wkTF1gJtQPREUWrDD0FGk
	a+Kg1bS3ttli0y/7gTipmdAsbeh5oZHZXRqGsw5Qvx9uH7zQJHRHG1K4eM9WNJ7K
	SAOUBOX6hz8+H7nVvuwHe5Ku5SB3jB9n3tM6N3h3tZoyD/Vzm3nal6CmlLQEWDRL
	1noDHCxwjtJ3FmYRBH6b/4CKk5biC34IIkY3l620kUu/WJ6rQzbVvaM6tyP4VAHD
	+GniZUC3ifCdVC07W52x042cvz/1cb6+bqA==
X-ME-Sender: <xms:QLx_Z_xZuzzBKCBNlqOeDIA3_TwSiaa2McoX6BD_bwnuXiEl5S17Tw>
    <xme:QLx_Z3TU4_KCBTYzpAUn8FUtt1EuVSuGVnHXTl2vGYYQ7MJX0uqKzGv7q4dZlD3aS
    --CRFIR8RGlZw>
X-ME-Received: <xmr:QLx_Z5UFMoaILubXZb1VppCzgcd1pAVm7F13sKy1l53RRd-OxhmF1B5PkI2pzOXJdu575FN0rddrUYs-XZhX9dZHvaBl_CtQvg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrudegiedgfeegucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
    rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
    htshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtjeen
    ucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomh
    grrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggft
    rfgrthhtvghrnhepgfduleetfeevhfefheeiteeliefhjefhleduveetteekveettddvge
    euteefjedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhho
    mhepmhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnh
    gspghrtghpthhtohepuddtpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehtvggu
    ugihrdgrshhtihgvsehvrghtvghsrdhtvggthhdprhgtphhtthhopeigvghnqdguvghvvg
    hlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdprhgtphhtthhopegrnhgurhgv
    fidrtghoohhpvghrfeestghithhrihigrdgtohhmpdhrtghpthhtohepjhgsvghulhhitg
    hhsehsuhhsvgdrtghomhdprhgtphhtthhopehjuhhlihgvnhesgigvnhdrohhrghdprhgt
    phhtthhopehsshhtrggsvghllhhinhhisehkvghrnhgvlhdrohhrghdprhgtphhtthhope
    hrohhgvghrrdhprghusegtihhtrhhigidrtghomhdprhgtphhtthhopehluhhkrghsiies
    hhgrfihrhihlkhhordhplhdprhgtphhtthhopeguphhsmhhithhhsegrphgvrhhtuhhssh
    holhhuthhiohhnshdrtghomh
X-ME-Proxy: <xmx:QLx_Z5iqj7Twtl7FAd0pB6fwcvD3hkn0AECSVBlTwe3OpMWLVdWPOw>
    <xmx:QLx_ZxD300TsgeRb0KyLuzyRNQvliBaGIihCMcIHTrthc78QlQBaRw>
    <xmx:QLx_ZyIu3-FzS9eXbfUbeU7gKkNkKzHpbnWQx_rIr2oSOJ8lLlNyHg>
    <xmx:QLx_ZwDCbiW8xWjhruwGZ_EWLVMghami-obGAWlFDafBTf7mc4d0mw>
    <xmx:Qbx_Z15tZqUF_I8BN9RSfnIuB7yGj7xjSve6J-vRXGQZGHnRwR_OOo0L>
Feedback-ID: i1568416f:Fastmail
Date: Thu, 9 Jan 2025 13:08:27 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Teddy Astie <teddy.astie@vates.tech>
Cc: Xen-devel <xen-devel@lists.xenproject.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>,
	Lukasz Hawrylko <lukasz@hawrylko.pl>,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Mateusz =?utf-8?B?TcOzd2th?= <mateusz.mowka@intel.com>
Subject: Re: [XEN RFC PATCH v4 0/5] IOMMU subsystem redesign and PV-IOMMU
 interface
Message-ID: <Z3-8O9opmLfgO5t0@mail-itl>
References: <cover.1730718102.git.teddy.astie@vates.tech>
 <Z38-y9xR-6C_sARJ@mail-itl>
 <c0b9fbdb-87db-4f31-8069-0c2d1c4ad4cd@vates.tech>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="1c1xE17VkmyIay1G"
Content-Disposition: inline
In-Reply-To: <c0b9fbdb-87db-4f31-8069-0c2d1c4ad4cd@vates.tech>


--1c1xE17VkmyIay1G
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Thu, 9 Jan 2025 13:08:27 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Teddy Astie <teddy.astie@vates.tech>
Cc: Xen-devel <xen-devel@lists.xenproject.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>,
	Lukasz Hawrylko <lukasz@hawrylko.pl>,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Mateusz =?utf-8?B?TcOzd2th?= <mateusz.mowka@intel.com>
Subject: Re: [XEN RFC PATCH v4 0/5] IOMMU subsystem redesign and PV-IOMMU
 interface

On Thu, Jan 09, 2025 at 11:39:04AM +0000, Teddy Astie wrote:
> Thanks for your review.
>=20
> > Hi,
> >=20
> > I finally got time to try this revision (sorry it took so long!). My
> > goal was to test it this time with some HVM domU too. I didn't get very
> > far...
> >=20
> > Issues I hit:
> >=20
> > 1. AMD IOMMU driver is not converted (fails to build), for now disabled
> >     CONFIG_AMD_IOMMU.
>=20
> I haven't really worked on the AMD-Vi code yet. I have plans for it but=
=20
> there is some specific bits to deal with (especially regarding interrupt=
=20
> remapping), that I planned to discuss especially during the Xen Project=
=20
> Winter Summit 2025.

:)

> > 2. PV shim build fails (linker fails to find p2m_add_identity_entry
> >     symbol referenced from iommu.c)
>=20
> I haven't considered PV shim yet, so I am not really surprised that=20
> there are some issues with it. We probably want to expose some PV-IOMMU=
=20
> features for PV guests under PV shim, but it probably needs some=20
> specific code for it.

I'm not sure if passthrough is supported with PV shim (never tried). The
current issue is much earlier ;)

> > 3. Xen complains on boot about missing endbr64 (surprisingly, it didn't
> >     exploded):
> >=20
> >      (XEN) alt table ffff82d0404234d8 -> ffff82d040432d82
> >      (XEN) altcall iommu_get_max_iova+0x11/0x30 dest iommu.c#intel_iomm=
u_get_max_iova has no endbr64
> >      (XEN) altcall context.c#iommu_reattach_phantom+0x30/0x50 dest iomm=
u.c#intel_iommu_add_devfn has no endbr64
> >      (XEN) altcall context.c#iommu_detach_phantom+0x25/0x40 dest iommu.=
c#intel_iommu_remove_devfn has no endbr64
> >      (XEN) altcall iommu_context_init+0x27/0x40 dest iommu.c#intel_iomm=
u_context_init has no endbr64
> >      (XEN) altcall iommu_attach_context+0x3c/0xd0 dest iommu.c#intel_io=
mmu_attach has no endbr64
> >      (XEN) altcall context.c#iommu_attach_context.cold+0x1d/0x53 dest i=
ommu.c#intel_iommu_detach has no endbr64
> >      (XEN) altcall iommu_detach_context+0x37/0xa0 dest iommu.c#intel_io=
mmu_detach has no endbr64
> >      (XEN) altcall iommu_reattach_context+0x95/0x240 dest iommu.c#intel=
_iommu_reattach has no endbr64
> >      (XEN) altcall context.c#iommu_reattach_context.cold+0x29/0x110 des=
t iommu.c#intel_iommu_reattach has no endbr64
> >      (XEN) altcall iommu_context_teardown+0x3f/0xa0 dest iommu.c#intel_=
iommu_context_teardown has no endbr64
> >      (XEN) altcall pci.c#deassign_device+0x99/0x270 dest iommu.c#intel_=
iommu_add_devfn has no endbr64
> >=20
>=20
> I also see that, but I am not sure what I need to do to fix it.

I guess add "cf_check" annotation to functions that are called
indirectly.

> > 4. Starting a HVM domU with PCI device fails with:
> >=20
> >      libxl: libxl_pci.c:1552:pci_add_dm_done: Domain 1:xc_assign_device=
 failed: No space left on device
> >      libxl: libxl_pci.c:1875:device_pci_add_done: Domain 1:libxl__devic=
e_pci_add failed for PCI device 0:aa:0.0 (rc -3)
> >      libxl: libxl_create.c:2061:domcreate_attach_devices: Domain 1:unab=
le to add pci devices
> > > I didn't change anything in the toolstack - maybe default context nee=
ds
> > to be initialized somehow? But the docs suggest the default context
> > should work out of the box. On the other hand, changelog for v4 says
> > some parts are moved to the toolstack, but I don't see any changes in
> > tools/ in this series...
> >=20
>=20
> I only tried stuff inside Dom0, but I haven't really tried passing=20
> through a device. I think I missed some step regarding quarantine domain=
=20
> initialization, which is probably why you have "-ENOSPC" here. You can=20
> try in the meantime to set "quarantine=3D0" to disable this part to see i=
f=20
> it progresses further.

That helped a bit. Now domU starts. But device doesn't work - qemu
complains:

[2025-01-09 06:52:45] [00:08.0] xen_pt_realize: Real physical device 00:0d.=
3 registered successfully
=2E..
[2025-01-09 06:52:45] [00:09.0] xen_pt_realize: Real physical device 00:0d.=
2 registered successfully
=2E..
[2025-01-09 06:52:45] [00:0a.0] xen_pt_realize: Real physical device 00:0d.=
0 registered successfully
=2E..
[2025-01-09 06:52:59] [00:0a.0] xen_pt_msgctrl_reg_write: setup MSI (regist=
er: 87).
[2025-01-09 06:52:59] [00:0a.0] msi_msix_setup: Error: Mapping of MSI (err:=
 19, vec: 0x25, entry 0[2025-01-09 06:52:59] x0)
[2025-01-09 06:52:59] [00:0a.0] xen_pt_msgctrl_reg_write: Warning: Can not =
map MSI (register: 86)!
[2025-01-09 06:54:21] [00:08.0] msix_set_enable: disabling MSI-X.
[2025-01-09 06:54:21] [00:08.0] xen_pt_msixctrl_reg_write: disable MSI-X
[2025-01-09 06:54:21] [00:09.0] xen_pt_msixctrl_reg_write: enable MSI-X
[2025-01-09 06:54:21] [00:09.0] msi_msix_setup: Error: Mapping of MSI-X (er=
r: 19, vec: 0xef, entry 0x0)
[2025-01-09 06:54:21] [00:09.0] msi_msix_setup: Error: Mapping of MSI-X (er=
r: 19, vec: 0xef, entry 0x1)
[2025-01-09 06:54:21] [00:09.0] msi_msix_setup: Error: Mapping of MSI-X (er=
r: 19, vec: 0xef, entry 0x2)
[2025-01-09 06:54:21] [00:09.0] msi_msix_setup: Error: Mapping of MSI-X (er=
r: 19, vec: 0xef, entry 0x3)
[2025-01-09 06:54:21] [00:09.0] msi_msix_setup: Error: Mapping of MSI-X (er=
r: 19, vec: 0xef, entry 0x4)
[2025-01-09 06:54:21] [00:09.0] msi_msix_setup: Error: Mapping of MSI-X (er=
r: 19, vec: 0xef, entry 0x5)
[2025-01-09 06:54:21] [00:09.0] msi_msix_setup: Error: Mapping of MSI-X (er=
r: 19, vec: 0xef, entry 0x6)
[2025-01-09 06:54:21] [00:09.0] msi_msix_setup: Error: Mapping of MSI-X (er=
r: 19, vec: 0xef, entry 0x7)
[2025-01-09 06:54:21] [00:09.0] msi_msix_setup: Error: Mapping of MSI-X (er=
r: 19, vec: 0xef, entry 0x8)
[2025-01-09 06:54:21] [00:09.0] msi_msix_setup: Error: Mapping of MSI-X (er=
r: 19, vec: 0xef, entry 0x9)
[2025-01-09 06:54:21] [00:09.0] msi_msix_setup: Error: Mapping of MSI-X (er=
r: 19, vec: 0xef, entry 0xa)
[2025-01-09 06:54:21] [00:09.0] msi_msix_setup: Error: Mapping of MSI-X (er=
r: 19, vec: 0xef, entry 0xb)

and interestingly, Xen says all devices are still in dom0:

[2025-01-09 06:53:39] (XEN) =3D=3D=3D=3D PCI devices =3D=3D=3D=3D
[2025-01-09 06:53:39] (XEN) =3D=3D=3D=3D segment 0000 =3D=3D=3D=3D
[2025-01-09 06:53:39] (XEN) 0000:aa:00.0 - d0 - node -1
[2025-01-09 06:53:39] (XEN) 0000:01:00.0 - d0 - node -1  - MSIs < 132 133 1=
34 135 136 >
[2025-01-09 06:53:39] (XEN) 0000:00:1f.5 - d0 - node -1
[2025-01-09 06:53:39] (XEN) 0000:00:1f.4 - d0 - node -1
[2025-01-09 06:53:39] (XEN) 0000:00:1f.3 - d0 - node -1  - MSIs < 139 >
[2025-01-09 06:53:39] (XEN) 0000:00:1f.0 - d0 - node -1
[2025-01-09 06:53:39] (XEN) 0000:00:1d.0 - d0 - node -1  - MSIs < 131 >
[2025-01-09 06:53:39] (XEN) 0000:00:16.0 - d0 - node -1  - MSIs < 138 >
[2025-01-09 06:53:39] (XEN) 0000:00:15.3 - d0 - node -1
[2025-01-09 06:53:39] (XEN) 0000:00:15.1 - d0 - node -1
[2025-01-09 06:53:39] (XEN) 0000:00:15.0 - d0 - node -1
[2025-01-09 06:53:39] (XEN) 0000:00:14.2 - d0 - node -1
[2025-01-09 06:53:39] (XEN) 0000:00:14.0 - d0 - node -1
[2025-01-09 06:53:39] (XEN) 0000:00:12.0 - d0 - node -1
[2025-01-09 06:53:39] (XEN) 0000:00:0d.3 - d0 - node -1
[2025-01-09 06:53:39] (XEN) 0000:00:0d.2 - d0 - node -1
[2025-01-09 06:53:39] (XEN) 0000:00:0d.0 - d0 - node -1
[2025-01-09 06:53:39] (XEN) 0000:00:0a.0 - d0 - node -1
[2025-01-09 06:53:39] (XEN) 0000:00:08.0 - d0 - node -1
[2025-01-09 06:53:39] (XEN) 0000:00:07.3 - d0 - node -1  - MSIs < 130 >
[2025-01-09 06:53:39] (XEN) 0000:00:07.2 - d0 - node -1  - MSIs < 129 >
[2025-01-09 06:53:39] (XEN) 0000:00:07.1 - d0 - node -1  - MSIs < 128 >
[2025-01-09 06:53:39] (XEN) 0000:00:07.0 - d0 - node -1  - MSIs < 127 >
[2025-01-09 06:53:39] (XEN) 0000:00:06.0 - d0 - node -1  - MSIs < 126 >
[2025-01-09 06:53:39] (XEN) 0000:00:04.0 - d0 - node -1
[2025-01-09 06:53:39] (XEN) 0000:00:02.0 - d0 - node -1  - MSIs < 137 >
[2025-01-09 06:53:39] (XEN) 0000:00:00.0 - d0 - node -1

I don't see any errors from toolstack this time.

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

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

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmd/vDsACgkQ24/THMrX
1yzEJwf+KhKLg5e6DtcqalYHE8KVuXIu87i9PmAF0IE7IbwvpR1XzhpOOh0KSuX+
YYPUUoHXjLCC/h+fSgfb8cRHeLdNDwdC8W1DRGBpMywANlw4EevmVvIDT6S0UQm/
ntQR7FVJmBin4XgcPpcOUZPujy7KpkByyauZLkE3gvivVmafLoQiANQYJF/+m56c
FdWthK1tNuO2QJu9hwR7lwEmKTKavA9Eqw/rFJ4zVtYIRPSP/FwN1v30M52P4f6G
Y1ucSYcFLsdL7UZL3GBGoMtVI0u0RJurrn/1PU4igpPSn6EnRpJF1fWr9Iy4gjzA
L8Ti1JKUloZD2yZvljKlCvSbJ6uXhA==
=Qclm
-----END PGP SIGNATURE-----

--1c1xE17VkmyIay1G--


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 12:41:47 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 12:41:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868317.1279836 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVrr2-0004z5-Fe; Thu, 09 Jan 2025 12:41:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868317.1279836; Thu, 09 Jan 2025 12:41:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVrr2-0004yy-Ch; Thu, 09 Jan 2025 12:41:40 +0000
Received: by outflank-mailman (input) for mailman id 868317;
 Thu, 09 Jan 2025 12:41: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
 <SRS0=GR/W=UB=bounce.vates.tech=bounce-md_30504962.677fc3ff.v1-6fdcd21ab4f04c64a1ede52008b3a276@srs-se1.protection.inumbo.net>)
 id 1tVrr0-0004yq-Sp
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 12:41:39 +0000
Received: from mail178-22.suw51.mandrillapp.com
 (mail178-22.suw51.mandrillapp.com [198.2.178.22])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1034bead-ce87-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 13:41:36 +0100 (CET)
Received: from pmta13.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail178-22.suw51.mandrillapp.com (Mailchimp) with ESMTP id
 4YTPYC4nzJzGlsp87
 for <xen-devel@lists.xenproject.org>; Thu,  9 Jan 2025 12:41:35 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 6fdcd21ab4f04c64a1ede52008b3a276; Thu, 09 Jan 2025 12:41:35 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1034bead-ce87-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1736426495; x=1736686995;
	bh=kyumva+NQOtk5B+90eZsJXz8lYvexVwZC3S7F5+vdug=;
	h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=re8JbPDoC4dZazVzUX/0GJJeACj8aXghXwrIq32kvvkze1zg7csF0NsHYZMTIJLxS
	 SiT4Uk0BYYY9NSH8PyNiJP2gOJ71Y6H+GJfZI2w/2RwCk7crmZLD/BUDnM23vhQAKQ
	 zp60E/kJoz2OOCyFcJahdRKb0K8c5TaJ7TbPF8ei08I2x8Cji5AQNnDKneFGayGg0N
	 iN3+qJA3xDnNYoNJi8THeW5wzwzt0gheSYTlVfZBoXhecv4knm5gnmH9yX19+J7DKu
	 lMAxH4aX9rcTmzWdKNaMyTxl2akKJmoYowORXNGbCJ+wlst6BuBJzkKVhJdITff4ag
	 vbpyZynR+vfeA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1736426495; x=1736686995; i=teddy.astie@vates.tech;
	bh=kyumva+NQOtk5B+90eZsJXz8lYvexVwZC3S7F5+vdug=;
	h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=z5XvuoxqCNvmWJO+J43oDTczJW4wjHClFrsv1j+Fnk7Sjy+u9gEMH/+KIC/erCA1S
	 brkE4O8a/lVTyCHMeRrsN95vhnooREyiAp/sr6zZIe6ZuQvMGySPn7+K+dmMslUjpi
	 IMtALPjZ6k++XvtL583gCaEjJwhMx0NBmDtLZFwc4c8o9YRDmLQ9WAVP6EKHPEmbrs
	 yc4u9Myzb77zSnDndA/3LA0eGMT8H6FBv9BrNfpAH45YFBISgTkA9WhM96MdvWi0fS
	 t6zzwtL6MS+JO5Bw9MKO9vGipma9IC8QT9E9Sr4LoUbLxkcE85gaL+cL45aIXAUuEE
	 oM38IpJT8NJ2A==
From: "Teddy Astie" <teddy.astie@vates.tech>
Subject: =?utf-8?Q?Re:=20[XEN=20RFC=20PATCH=20v4=200/5]=20IOMMU=20subsystem=20redesign=20and=20PV-IOMMU=20interface?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1736426493454
Message-Id: <0897deb0-3d57-48a3-8f92-4714ba6d1217@vates.tech>
To: "=?utf-8?Q?Marek=20Marczykowski-G=C3=B3recki?=" <marmarek@invisiblethingslab.com>, Xen-devel <xen-devel@lists.xenproject.org>
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>, "Jan Beulich" <jbeulich@suse.com>, "Julien Grall" <julien@xen.org>, "Stefano Stabellini" <sstabellini@kernel.org>, "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>, "Lukasz Hawrylko" <lukasz@hawrylko.pl>, "Daniel P. Smith" <dpsmith@apertussolutions.com>, "=?utf-8?Q?Mateusz=20M=C3=B3wka?=" <mateusz.mowka@intel.com>
References: <cover.1730718102.git.teddy.astie@vates.tech> <Z38-y9xR-6C_sARJ@mail-itl> <c0b9fbdb-87db-4f31-8069-0c2d1c4ad4cd@vates.tech> <Z3-8O9opmLfgO5t0@mail-itl>
In-Reply-To: <Z3-8O9opmLfgO5t0@mail-itl>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.6fdcd21ab4f04c64a1ede52008b3a276?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250109:md
Date: Thu, 09 Jan 2025 12:41:35 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Hello,

>>> 3. Xen complains on boot about missing endbr64 (surprisingly, it didn't
>>>      exploded):
>>>
>>>       (XEN) alt table ffff82d0404234d8 -> ffff82d040432d82
>>>       (XEN) altcall iommu_get_max_iova+0x11/0x30 dest iommu.c#intel_iommu_get_max_iova has no endbr64
>>>       (XEN) altcall context.c#iommu_reattach_phantom+0x30/0x50 dest iommu.c#intel_iommu_add_devfn has no endbr64
>>>       (XEN) altcall context.c#iommu_detach_phantom+0x25/0x40 dest iommu.c#intel_iommu_remove_devfn has no endbr64
>>>       (XEN) altcall iommu_context_init+0x27/0x40 dest iommu.c#intel_iommu_context_init has no endbr64
>>>       (XEN) altcall iommu_attach_context+0x3c/0xd0 dest iommu.c#intel_iommu_attach has no endbr64
>>>       (XEN) altcall context.c#iommu_attach_context.cold+0x1d/0x53 dest iommu.c#intel_iommu_detach has no endbr64
>>>       (XEN) altcall iommu_detach_context+0x37/0xa0 dest iommu.c#intel_iommu_detach has no endbr64
>>>       (XEN) altcall iommu_reattach_context+0x95/0x240 dest iommu.c#intel_iommu_reattach has no endbr64
>>>       (XEN) altcall context.c#iommu_reattach_context.cold+0x29/0x110 dest iommu.c#intel_iommu_reattach has no endbr64
>>>       (XEN) altcall iommu_context_teardown+0x3f/0xa0 dest iommu.c#intel_iommu_context_teardown has no endbr64
>>>       (XEN) altcall pci.c#deassign_device+0x99/0x270 dest iommu.c#intel_iommu_add_devfn has no endbr64
>>>
>>
>> I also see that, but I am not sure what I need to do to fix it.
> 
> I guess add "cf_check" annotation to functions that are called
> indirectly.
> 

Will add them for v5.

>>> 4. Starting a HVM domU with PCI device fails with:
>>>
>>>       libxl: libxl_pci.c:1552:pci_add_dm_done: Domain 1:xc_assign_device failed: No space left on device
>>>       libxl: libxl_pci.c:1875:device_pci_add_done: Domain 1:libxl__device_pci_add failed for PCI device 0:aa:0.0 (rc -3)
>>>       libxl: libxl_create.c:2061:domcreate_attach_devices: Domain 1:unable to add pci devices
>>>> I didn't change anything in the toolstack - maybe default context needs
>>> to be initialized somehow? But the docs suggest the default context
>>> should work out of the box. On the other hand, changelog for v4 says
>>> some parts are moved to the toolstack, but I don't see any changes in
>>> tools/ in this series...
>>>
>>
>> I only tried stuff inside Dom0, but I haven't really tried passing
>> through a device. I think I missed some step regarding quarantine domain
>> initialization, which is probably why you have "-ENOSPC" here. You can
>> try in the meantime to set "quarantine=0" to disable this part to see if
>> it progresses further.
> 
> That helped a bit. Now domU starts. But device doesn't work - qemu
> complains:
> 
> [2025-01-09 06:52:45] [00:08.0] xen_pt_realize: Real physical device 00:0d.3 registered successfully
> ...
> [2025-01-09 06:52:45] [00:09.0] xen_pt_realize: Real physical device 00:0d.2 registered successfully
> ...
> [2025-01-09 06:52:45] [00:0a.0] xen_pt_realize: Real physical device 00:0d.0 registered successfully
> ...
> [2025-01-09 06:52:59] [00:0a.0] xen_pt_msgctrl_reg_write: setup MSI (register: 87).
> [2025-01-09 06:52:59] [00:0a.0] msi_msix_setup: Error: Mapping of MSI (err: 19, vec: 0x25, entry 0[2025-01-09 06:52:59] x0)
> [2025-01-09 06:52:59] [00:0a.0] xen_pt_msgctrl_reg_write: Warning: Can not map MSI (register: 86)!
> [2025-01-09 06:54:21] [00:08.0] msix_set_enable: disabling MSI-X.
> [2025-01-09 06:54:21] [00:08.0] xen_pt_msixctrl_reg_write: disable MSI-X
> [2025-01-09 06:54:21] [00:09.0] xen_pt_msixctrl_reg_write: enable MSI-X
> [2025-01-09 06:54:21] [00:09.0] msi_msix_setup: Error: Mapping of MSI-X (err: 19, vec: 0xef, entry 0x0)
> [2025-01-09 06:54:21] [00:09.0] msi_msix_setup: Error: Mapping of MSI-X (err: 19, vec: 0xef, entry 0x1)
> [2025-01-09 06:54:21] [00:09.0] msi_msix_setup: Error: Mapping of MSI-X (err: 19, vec: 0xef, entry 0x2)
> [2025-01-09 06:54:21] [00:09.0] msi_msix_setup: Error: Mapping of MSI-X (err: 19, vec: 0xef, entry 0x3)
> [2025-01-09 06:54:21] [00:09.0] msi_msix_setup: Error: Mapping of MSI-X (err: 19, vec: 0xef, entry 0x4)
> [2025-01-09 06:54:21] [00:09.0] msi_msix_setup: Error: Mapping of MSI-X (err: 19, vec: 0xef, entry 0x5)
> [2025-01-09 06:54:21] [00:09.0] msi_msix_setup: Error: Mapping of MSI-X (err: 19, vec: 0xef, entry 0x6)
> [2025-01-09 06:54:21] [00:09.0] msi_msix_setup: Error: Mapping of MSI-X (err: 19, vec: 0xef, entry 0x7)
> [2025-01-09 06:54:21] [00:09.0] msi_msix_setup: Error: Mapping of MSI-X (err: 19, vec: 0xef, entry 0x8)
> [2025-01-09 06:54:21] [00:09.0] msi_msix_setup: Error: Mapping of MSI-X (err: 19, vec: 0xef, entry 0x9)
> [2025-01-09 06:54:21] [00:09.0] msi_msix_setup: Error: Mapping of MSI-X (err: 19, vec: 0xef, entry 0xa)
> [2025-01-09 06:54:21] [00:09.0] msi_msix_setup: Error: Mapping of MSI-X (err: 19, vec: 0xef, entry 0xb)
> 
> and interestingly, Xen says all devices are still in dom0:
> 
> [2025-01-09 06:53:39] (XEN) ==== PCI devices ====
> [2025-01-09 06:53:39] (XEN) ==== segment 0000 ====
> [2025-01-09 06:53:39] (XEN) 0000:aa:00.0 - d0 - node -1
> [2025-01-09 06:53:39] (XEN) 0000:01:00.0 - d0 - node -1  - MSIs < 132 133 134 135 136 >
> [2025-01-09 06:53:39] (XEN) 0000:00:1f.5 - d0 - node -1
> [2025-01-09 06:53:39] (XEN) 0000:00:1f.4 - d0 - node -1
> [2025-01-09 06:53:39] (XEN) 0000:00:1f.3 - d0 - node -1  - MSIs < 139 >
> [2025-01-09 06:53:39] (XEN) 0000:00:1f.0 - d0 - node -1
> [2025-01-09 06:53:39] (XEN) 0000:00:1d.0 - d0 - node -1  - MSIs < 131 >
> [2025-01-09 06:53:39] (XEN) 0000:00:16.0 - d0 - node -1  - MSIs < 138 >
> [2025-01-09 06:53:39] (XEN) 0000:00:15.3 - d0 - node -1
> [2025-01-09 06:53:39] (XEN) 0000:00:15.1 - d0 - node -1
> [2025-01-09 06:53:39] (XEN) 0000:00:15.0 - d0 - node -1
> [2025-01-09 06:53:39] (XEN) 0000:00:14.2 - d0 - node -1
> [2025-01-09 06:53:39] (XEN) 0000:00:14.0 - d0 - node -1
> [2025-01-09 06:53:39] (XEN) 0000:00:12.0 - d0 - node -1
> [2025-01-09 06:53:39] (XEN) 0000:00:0d.3 - d0 - node -1
> [2025-01-09 06:53:39] (XEN) 0000:00:0d.2 - d0 - node -1
> [2025-01-09 06:53:39] (XEN) 0000:00:0d.0 - d0 - node -1
> [2025-01-09 06:53:39] (XEN) 0000:00:0a.0 - d0 - node -1
> [2025-01-09 06:53:39] (XEN) 0000:00:08.0 - d0 - node -1
> [2025-01-09 06:53:39] (XEN) 0000:00:07.3 - d0 - node -1  - MSIs < 130 >
> [2025-01-09 06:53:39] (XEN) 0000:00:07.2 - d0 - node -1  - MSIs < 129 >
> [2025-01-09 06:53:39] (XEN) 0000:00:07.1 - d0 - node -1  - MSIs < 128 >
> [2025-01-09 06:53:39] (XEN) 0000:00:07.0 - d0 - node -1  - MSIs < 127 >
> [2025-01-09 06:53:39] (XEN) 0000:00:06.0 - d0 - node -1  - MSIs < 126 >
> [2025-01-09 06:53:39] (XEN) 0000:00:04.0 - d0 - node -1
> [2025-01-09 06:53:39] (XEN) 0000:00:02.0 - d0 - node -1  - MSIs < 137 >
> [2025-01-09 06:53:39] (XEN) 0000:00:00.0 - d0 - node -1
> 

I checked the PCI passthrough logic, and it looks like some bits are 
missing in my code. While they seem to be set up properly for the IOMMU 
subsystem point of view (DMA remapping at least), their domains 
(pdev->domain) are not updated. I suppose it is what confuses the 
intremap code.

Will do some additional testing with PCI passthrough and plan to fix it 
for v5.

Teddy


Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 12:44:31 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 12:44:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868326.1279846 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVrtl-0005Y2-SA; Thu, 09 Jan 2025 12:44:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868326.1279846; Thu, 09 Jan 2025 12:44:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVrtl-0005Xv-Pe; Thu, 09 Jan 2025 12:44:29 +0000
Received: by outflank-mailman (input) for mailman id 868326;
 Thu, 09 Jan 2025 12:44:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=U+x7=UB=arm.com=Bertrand.Marquis@srs-se1.protection.inumbo.net>)
 id 1tVrtk-0005Xp-2s
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 12:44:28 +0000
Received: from EUR03-AM7-obe.outbound.protection.outlook.com
 (mail-am7eur03on2062d.outbound.protection.outlook.com
 [2a01:111:f403:260e::62d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 75b86bcd-ce87-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 13:44:26 +0100 (CET)
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by AS8PR08MB7944.eurprd08.prod.outlook.com (2603:10a6:20b:541::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8335.12; Thu, 9 Jan
 2025 12:44:23 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a%4]) with mapi id 15.20.8335.011; Thu, 9 Jan 2025
 12:44:23 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 75b86bcd-ce87-11ef-a0df-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=q+SpOSFf87UzYi7d0OkbBebkVL+36suhoxJJyYSY4pQWhXa7C9dkRRwvGYa5EkBeTFE3CUy5fS6tl+lT7E4BnmcJl7xm38Xr7VIF1rgFShP85tMmCL/ASZ5FGDbIKH7iFNeA4sty47vpyQFwUh3fmaoDOMpfA9EBNmMGF9yuWiEQ0arwqBk4+o5Ka8msVmMkMPyYZbg/ROiRBqVQRjljqsBE30SeJgXSX7KIPNeSgrBypsP1SXicBfd5KETcRlUSPNV/lpujwcA78VHM3WyGWCbThR9cSbJtLhMndHaBHPC3esj+q08kK8lvhzu79Uc3hE1XsoZlXrpGx6NILL8XYg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=VviiSMZ02u9GiW/QNCAMwOXjwvEMR4/YoW/9a1VYoZY=;
 b=itHd8Nfk2X9nX3rPhlgK96678pWh1sakXNauaBz0FHFhH8A+eYnpg6ulejsVJl+Sp+iW9z3165doeXgDHfjJ84DG3SiGx4quhvsV5NG/M1doO4eZKDYGs+/J9IcBSVViTtYqhC9zX7oB1MrSpzDXfPuDOdehGg0uhD85d8X75ZBghoqmQ0C7+qEFdjlVEdWq8lUlg0aD9OobWLTvBaZLGJ2IZcLFWQAR+aet2f4kDg+xCyjjZoonWf2cyLhb5aEIcoLe7VWAtHexyULJiyoC4gryv2ZJT2xJ9crQsMAihlrO1ySkZh6apY1KmP7v4nUaTztQeDrJLsQPTpOtxlPGVg==
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=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=VviiSMZ02u9GiW/QNCAMwOXjwvEMR4/YoW/9a1VYoZY=;
 b=OfgEKhmXb7E7wACqKBfjVX6mQe7lpDIEJIRgELLE/j+YAuBz9eoi0hyyLaK3kWUxIM8+nI7QjI/AlZQ/ig2+kkMBSBPO2s4NORbcnKAApdctSSnVDaneZGxoVw3dHSXPJTZddkxK66b7GJIhiXlnhUa/LNqvyDC+QfvV8DtTWRw=
From: Bertrand Marquis <Bertrand.Marquis@arm.com>
To: Ayan Kumar Halder <ayankuma@amd.com>
CC: Ayan Kumar Halder <ayan.kumar.halder@amd.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Michal
 Orzel <michal.orzel@amd.com>, Stefano Stabellini <sstabellini@kernel.org>,
	Artem Mygaiev <artem_mygaiev@epam.com>
Subject: Re: [PATCH v4] docs: fusa: Add dom0less domain configuration
 requirements
Thread-Topic: [PATCH v4] docs: fusa: Add dom0less domain configuration
 requirements
Thread-Index: AQHbYe83ZG0syumJUEGH2kASpg58SrMOExqAgAAjnACAAC3JAA==
Date: Thu, 9 Jan 2025 12:44:23 +0000
Message-ID: <9F9BC3B7-BB56-4E1D-B287-751679F1EE7B@arm.com>
References: <20250108170304.2250917-1-ayan.kumar.halder@amd.com>
 <E21BDDA5-F268-4127-82FA-1BD58DD6028D@arm.com>
 <dac15016-b55f-4066-a8e6-b2eb8346655c@amd.com>
In-Reply-To: <dac15016-b55f-4066-a8e6-b2eb8346655c@amd.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.200.121)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DB9PR08MB6588:EE_|AS8PR08MB7944:EE_
x-ms-office365-filtering-correlation-id: 30a8d781-57ee-4dcb-ae57-08dd30ab5822
x-checkrecipientrouted: true
nodisclaimer: true
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700018;
x-microsoft-antispam-message-info:
 =?us-ascii?Q?O1/Gi5ze0mUZ01mCO8zf3dGog8jF/kemqKSJJmNyNIU6nlu6BdEnnNFMWIh3?=
 =?us-ascii?Q?FymWt2MkvYKhFU0LY/SYK0wrKm4VLrqh8l4xnPQar1bLujVOfArom+9h3s2D?=
 =?us-ascii?Q?/M3l6PkXPLYGMJ/KnP3nLeVkBgr9yHA+lImgu0BReYIa1dCx7dNvzlwWrB+I?=
 =?us-ascii?Q?eauhPlH1CqEKjUN9pmIxYdHY+RDY8smMwZxRt9k/dayt/oNT7EQyCqQ1yVm6?=
 =?us-ascii?Q?zhTzTAQ3LgyJlYew2PZGwdBHt7c5Hg0G0/zEzBYl3GZYNMNPnX/rF1XgItXI?=
 =?us-ascii?Q?L0pURoA7uivZpJ3PJ7b3ux+KRFdeYEMyrYb0/53zIN98DDkkTZxiea+EnFNu?=
 =?us-ascii?Q?3MJuWLKwQ/dfuOsoZtL63e3FbSfgPpYJh772h2TU8YRcp8wFfIgzBhjjN62K?=
 =?us-ascii?Q?6s+9xBJlJRXivpm+G9uECtL1oLu/0z7r1AfJmI7+InLN5MUaCoio9XswEBtA?=
 =?us-ascii?Q?RQsRTdecOwp0d57l6lb3Ucp+/209JftcNdoP3VJ81TiqY7VN79yDbOFFbDcb?=
 =?us-ascii?Q?irfB6rRYeAjb4DwGBjMuyaI9y+4FKxwYLKFiu1QMsEtrJiAxilkmZlk8sXOC?=
 =?us-ascii?Q?IgeLmLifsVtwW7Qv1hCqzeFoHdREgSq3I4wOaMjCEZoEMNfmqEtKaqX4l0k6?=
 =?us-ascii?Q?3ypAPqLes8sRY26rUqx29GlBOT9vaSwXUOfS9KBBOStfXbbM2r5SEA5vp3RI?=
 =?us-ascii?Q?NPpLqHDC/Cyx01kJaFu+OioDH4vlHadmZqFMEzMOePmuy4q57QV1ElDJ76C2?=
 =?us-ascii?Q?78GoJe1uYG29PmvTDp2PQqliCN+wUg20ChVFL9UAuI9yZAAfJuO3hCU0zNZM?=
 =?us-ascii?Q?29GF30gE3q9uxhSCLrk7+b+wEAx3M3E9Q1VlOek0MBHSP58kAA01YTsrZmal?=
 =?us-ascii?Q?e3hLoly9wNakyzMz7dqC+4Krpqi7X/3CVtj1dB6ftbEinnyeZ6CUYCnTNA+I?=
 =?us-ascii?Q?rX/OB5hhupRYCA+1FFsHfUmxOpHRnF5Xfhjez9iU49ardjZDfwsATwWH7m1K?=
 =?us-ascii?Q?jAOhKypKm/e+oGNvfN/GFQUbF453thC/o7+nNmo/4xjo8YUyWJWBjV3r/QdR?=
 =?us-ascii?Q?S/76XFDuE+Q/YxE1ajq/KlGv46QkZ+t1DvzZHc9D5mkXb6wK+0wHKA2TzRWU?=
 =?us-ascii?Q?Zga21JMF/q4lqeZvC8QPCnDGO6fnhAQeWn1kzaNf6XcExaEvXCuvjkjRCG+k?=
 =?us-ascii?Q?hp4fV6zuxIkVmKtJnoFJSzeljD8eR1ZWVSkAXjSk7Ac0NQyFMEiCToBgUEvV?=
 =?us-ascii?Q?W4xWrBrN46WXF+Ccu2hOZ9SCkLJJqherFku0XomcOg3E0o2iIHGzDnyR0gVw?=
 =?us-ascii?Q?/navHhdRh/GWjoZAwfznZYJqvgyH8NSOdqbGAzty0BbuSvdnXUrETBCnPQcJ?=
 =?us-ascii?Q?WVtEhl4hh1VuaPHW90sb327TKX1W2GUQPmljC1k384nWNBqpb+OkOkFOszG/?=
 =?us-ascii?Q?rxlDcdoyTG4jPITOmuhXcsLh4jNLsbLv?=
x-forefront-antispam-report:
 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:(13230040)(1800799024)(366016)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?sq5on1CdywW1cC0LsNVEbpE95K7Wslj6031nQH+ga2bhf7S2CsXehQSAWEq1?=
 =?us-ascii?Q?lMl32LuEcWstrukUkJ6i2ek+HWYMjDwxhF+zbDBMxgkzS0gSyLaZVZe/M0Nk?=
 =?us-ascii?Q?fhxveHi1BfWCbDm/s/gZuTencO4CSBwl3rEJB89UqqcbnYOXFqXz9iAaIMSs?=
 =?us-ascii?Q?O5H0h7ZWCoZvb4gN5CT8QYQHDVNmp7yePh23wGpEEFL8pIIsLVuUdel18jkb?=
 =?us-ascii?Q?U0IXkO5FNSlY+avCy+QpA1A6o3dAOpo0HA9HCfrd0cpt4cpQejudZFarEQ1x?=
 =?us-ascii?Q?bi50uTDOHBewQ6X+MfbPYz7JvutpZ419Lbx7jOLHUcqwOgoMh38fL89UKX4+?=
 =?us-ascii?Q?94saaoucSZwlcvAEziGKwX3kEpNPygl0HpMEjjxDd+hQ376q/dhzwE3dYBDs?=
 =?us-ascii?Q?BZhe/jcrpW9iMUAKjZbTPGY/XsN7V6x5za/Mpo03Dhwt7UIhf9y828umE3qa?=
 =?us-ascii?Q?brSAMcjeb3y1aLGz1XsEgO1nKdG4lB0Uxrx18ruiRgw5/sw4/xCE83aCZx+U?=
 =?us-ascii?Q?JnMof3WpD6UROd3gQu/4pymiSm6psklNc6nD46ljpSEzHGcRtgODI46lDt0C?=
 =?us-ascii?Q?9PHtR4EB4kO7chUwDUDuPyviFzquz7OJXoyHfe181Yr6TCGVkqMKGvQHc/ZU?=
 =?us-ascii?Q?IU2C59iuZF2J0/A0fArzGU0BHFBE+NmPUaNpTvVdL7K3HdgoV/AF0xYEOWTG?=
 =?us-ascii?Q?H53DRY3a9QMWNFyCdHCChLYdkPvE6mZm/eBXxYJC/O8A/MJhZOubnndsKs2r?=
 =?us-ascii?Q?Jg+KP9Hf+PzYu8KqoqepbavVqAexVotINSDQ2FJIWb2ZvABy2rY9zAQ1IKk2?=
 =?us-ascii?Q?gMQMss5edybATGYNMTBrP2EinUASGcK4PlWY6RmaVY4PSdneq5DOvyX+m6+J?=
 =?us-ascii?Q?IIm02sEwEp8wnlRLSjDjuPK7HrHmu7QWPld1z5UNaI4fckW5XgMBr2bEcp85?=
 =?us-ascii?Q?ekQQCcShx1UFSn8222oeQa8bBH4jREqE2wqdPAnQG/4uohn0iL3GpLTPLSlI?=
 =?us-ascii?Q?ufUNET2qeVvJjO+zR1TiJDDZ+DmWmXI9w4odif+hiFx63vzIrayxvoiq2Aqu?=
 =?us-ascii?Q?v7CmolxPkHCtZSPi2yrwwk0kI58S9pBzcfcuStq2fJ9miWhU8beMzUYwXIxn?=
 =?us-ascii?Q?SSdMy+rUW3ZmThLawjL1F1E3P3ZkP8MBnhCJ4tcGUECnnizTDIlJrC7Cm7e0?=
 =?us-ascii?Q?nBHstcg6Lc50KsMNKpd6CdzTtfptKLpRPdi7qlDWJpx5erxGc4gLbd1LC5HR?=
 =?us-ascii?Q?2fgMXoKfTdDf+VxG4vT42Qgu3eZEbgapiXLVOvkfVX8tcwhKwGzSQNveA3Gy?=
 =?us-ascii?Q?2RmlJZZ8Kqgk/HbUGIJ4ZZ/TRNkXfMJlQjW1t5UprgF/EBgUTxhlAWJzEerE?=
 =?us-ascii?Q?+SIZWn3C5/3MUHxhZNAYby1atRzBwqA21Ttmhm8fXt4NL5/HpzsoELNTNfm3?=
 =?us-ascii?Q?IQzVGH6kdx6BAXFdZkF/iW9bupEnHU0fXqgh0fVwxdAKNa//BdljT3Ccv1ra?=
 =?us-ascii?Q?vEOs/FQEpbSHD7SsXIMZZSoxwS97jPVA3e+jYE8xaXex2E6sc5b7WNoXLRSP?=
 =?us-ascii?Q?cnprIi8wYzxeKhsM9D7Up+kCMTCuuOA9Evu5UG4aDNbIFJx7xtpdHdAO2clr?=
 =?us-ascii?Q?Rw=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <EDFD96B0B4AAE9489ECF045CD86AF669@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DB9PR08MB6588.eurprd08.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 30a8d781-57ee-4dcb-ae57-08dd30ab5822
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2025 12:44:23.2286
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 6QsHP3Gw1kpjiM2keQTuqOSB746syEJlXBkd3z4Rfqc91aKpOMK2MTiyszVtXGvI7V9tYStpvNXD6n9Ad7LUVxeT1TMgEK5EcVi00NbqmG0=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB7944

Hi Ayan,

> On 9 Jan 2025, at 11:00, Ayan Kumar Halder <ayankuma@amd.com> wrote:
>=20
>=20
> On 09/01/2025 07:53, Bertrand Marquis wrote:
>> Hi Ayan,
> Hi Bertrand,
>>=20
>> This is a lot better.
>> I just have some minor phrasing comments after.
>>=20
>>> On 8 Jan 2025, at 18:03, Ayan Kumar Halder <ayan.kumar.halder@amd.com> =
wrote:
>>>=20
>>> From: Michal Orzel <michal.orzel@amd.com>
>>>=20
>>> Add requirements for dom0less domain creation.
>>>=20
>>> Signed-off-by: Michal Orzel <michal.orzel@amd.com>
>>> Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>

With the fixes handled on commit:

Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>

Cheers
Bertrand

>>> ---
>>> Changes from -
>>>=20
>>> v1 - 1. As the dom0less domain creation requirements specifies the dt p=
roperties
>>> for creating domains, it has been moved to product requirements. Produc=
t
>>> requirements define the interface Xen exposes to other domains.
>>>=20
>>> 2. For the requirements which introduces new terms (like grant table, e=
tc), I
>>> have provided the definition as part of the comments.
>>>=20
>>> 3. Introduced new market requirements to specify that Xen can assign io=
mem and
>>> irqs to domains.
>>>=20
>>> 4. The design requirements will be added later.
>>>=20
>>> v2 - 1. Rephrased the requirements as suggested.
>>>=20
>>> 2. Split the product requirements into arm64 specific and common.
>>>=20
>>> 3. The arm64 specific requirements have arm64_ prefixed to their tag na=
mes.
>>>=20
>>> 4. Grant table requirements have been dropped for now.
>>>=20
>>> 5. Added a market requirement to denote that Xen can support multiple s=
chedulers.
>>>=20
>>> 6. Updated index.rst as we have a new file ie product-reqs/reqs.rst.
>>>=20
>>> V3 - 1. Removed duplicate mention for 'Rationale'.
>>>=20
>>> 2. Fixed some of the descriptions as per the review comments.
>>>=20
>>> docs/fusa/reqs/index.rst                   |   1 +
>>> docs/fusa/reqs/market-reqs/reqs.rst        |  31 ++++
>>> docs/fusa/reqs/product-reqs/arm64/reqs.rst | 128 ++++++++++++++++-
>>> docs/fusa/reqs/product-reqs/reqs.rst       | 160 +++++++++++++++++++++
>>> 4 files changed, 318 insertions(+), 2 deletions(-)
>>> create mode 100644 docs/fusa/reqs/product-reqs/reqs.rst
>>>=20
>>> diff --git a/docs/fusa/reqs/index.rst b/docs/fusa/reqs/index.rst
>>> index 8a4dae6fb2..1088a51d52 100644
>>> --- a/docs/fusa/reqs/index.rst
>>> +++ b/docs/fusa/reqs/index.rst
>>> @@ -8,6 +8,7 @@ Requirements documentation
>>>=20
>>>    intro
>>>    market-reqs/reqs
>>> +   product-reqs/reqs
>>>    product-reqs/arm64/reqs
>>>    design-reqs/arm64/generic-timer
>>>    design-reqs/arm64/sbsa-uart
>>> diff --git a/docs/fusa/reqs/market-reqs/reqs.rst b/docs/fusa/reqs/marke=
t-reqs/reqs.rst
>>> index f456788d96..39b2714237 100644
>>> --- a/docs/fusa/reqs/market-reqs/reqs.rst
>>> +++ b/docs/fusa/reqs/market-reqs/reqs.rst
>>> @@ -47,3 +47,34 @@ Comments:
>>>=20
>>> Needs:
>>>  - XenProd
>>> +
>>> +Static VM definition
>>> +--------------------
>>> +
>>> +`XenMkt~static_vm_definition~1`
>>> +
>>> +Description:
>>> +Xen shall support assigning peripherals to various domains.
>> "various" here could be removed or replaced with "a domain" to be cohere=
nt with
>> the phrasing after.
> I agree
>>=20
>>> +
>>> +Rationale:
>>> +
>>> +Comments:
>>> +Peripheral implies an iomem (input output memory) and/or interrupts.
>>> +
>>> +Needs:
>>> + - XenProd
>>> +
>>> +Multiple schedulers
>>> +-------------------
>>> +
>>> +`XenMkt~multiple_schedulers~1`
>>> +
>>> +Description:
>>> +Xen shall provide different ways of scheduling virtual cpus onto physi=
cal cpus.
>> different here is a bit imprecise.
>> how about:
>> Xen shall have configurable scheduling strategies of virtual cpus onto p=
hysical cpus.
>=20
> looks fine to me.
>=20
> Are you ok to give your R-b ? Then I can request Michal to fix them on co=
mmit.
>=20
> - Ayan
>=20
>>=20
>> The rest looks good.
>>=20
>> Cheers
>> Bertrand




From xen-devel-bounces@lists.xenproject.org Thu Jan 09 13:00:32 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 13:00:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868340.1279857 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVs9C-0008Ol-85; Thu, 09 Jan 2025 13:00:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868340.1279857; Thu, 09 Jan 2025 13:00:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVs9C-0008Oe-59; Thu, 09 Jan 2025 13:00:26 +0000
Received: by outflank-mailman (input) for mailman id 868340;
 Thu, 09 Jan 2025 13:00: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
 <SRS0=eYg4=UB=invisiblethingslab.com=marmarek@srs-se1.protection.inumbo.net>)
 id 1tVs9B-0008OX-7U
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 13:00:25 +0000
Received: from fout-a3-smtp.messagingengine.com
 (fout-a3-smtp.messagingengine.com [103.168.172.146])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id afb222d7-ce89-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 14:00:23 +0100 (CET)
Received: from phl-compute-03.internal (phl-compute-03.phl.internal
 [10.202.2.43])
 by mailfout.phl.internal (Postfix) with ESMTP id 5C8A21380A24;
 Thu,  9 Jan 2025 08:00:22 -0500 (EST)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-03.internal (MEProxy); Thu, 09 Jan 2025 08:00:22 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 9 Jan 2025 08:00:19 -0500 (EST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: afb222d7-ce89-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm2; t=1736427622;
	 x=1736514022; bh=INKq8DmcEiQG980xnfWao5JacgDPsknfBeqB3VReIhU=; b=
	eC4dvdFhcNh2RZHotdrSfxhx/HJw23LJNU4mxp+AyuIuP4o7gqjm50rp4ufIKYu8
	CANpa/ZotUsCDQkR4Otj5jDPTTJewf2hsHWCgv7TqOPZbcdbS1RuQHq38kInkK3p
	T07RJOvo4Fa2Vfq8+/Z5k3ykDgyk5q7cYXQcpr4B92q6+yqaXoL9v9abWEhXsfp3
	EQGG71R2QvxwQ+iXBIt3qBKWfWzzQJd8djyQEnTtIb6ZYfo04Z0UJbtyVkBqai6u
	R4CdNsEBLgek9EdvLqMrw+A2gOqAjEIBcDQEqw7m9HuKhAhTufn6/LrOPA50pYWA
	EjeSKG3UzyfGvoFmEL6KJw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:subject:subject:to
	:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=
	1736427622; x=1736514022; bh=INKq8DmcEiQG980xnfWao5JacgDPsknfBeq
	B3VReIhU=; b=AEyxmd9LqrdLwUozRkl4Eqw26oz5QHTeJpwhCY5sI43XDse+jai
	7d9sYLXuS6Gu7xuZYleRzFEnpPMZb8aVv57hZzgO+jE8tlFabAvUmtCGjBl/K8Qr
	0k4EA/7lKQWfofQ9Vz1kd68+LAK1YiauwZjf1oMTwx5wQxjNXKOkhoCboNCkuil8
	uA20tGof5fFug1tLRNPJNZXtEZVnculcNfDV7aWxNC62JU6k4UKY1OkD9ZHnyvHH
	vpLXGE7B+8Y02BLk92EGAmDYI+xnXOUGPSgo6aALUZucLFKxDJz0eV4ehJIqHZGX
	B72bc7Ew5eev2xL7bjpafrI30v8fRjeQQkg==
X-ME-Sender: <xms:Zch_Z0q6rKIGKNCpIupiAM-mPtM3BHRsqpHH0loVqUM63ZjPM6vr6w>
    <xme:Zch_Z6rpF6OvUI31V9Ocz0i9ShR0Fhh_P0dMoAhSFnmZufK6EiRv_F4FdOSGSBeEJ
    xzrs2ZMjzabfg>
X-ME-Received: <xmr:Zch_Z5ORNbn2EDHjWb1VizBiR1VpRyn6ftvlDnbAoCF3SKlvFWioYTLvIUlogHnij0wpN4xTZCGvRrIYtTo9ahl3-uxb1MfLtw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrudegiedggeegucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
    rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
    htshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtjeen
    ucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomh
    grrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggft
    rfgrthhtvghrnhepgfduleetfeevhfefheeiteeliefhjefhleduveetteekveettddvge
    euteefjedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhho
    mhepmhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnh
    gspghrtghpthhtohepuddtpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehtvggu
    ugihrdgrshhtihgvsehvrghtvghsrdhtvggthhdprhgtphhtthhopeigvghnqdguvghvvg
    hlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdprhgtphhtthhopegrnhgurhgv
    fidrtghoohhpvghrfeestghithhrihigrdgtohhmpdhrtghpthhtohepjhgsvghulhhitg
    hhsehsuhhsvgdrtghomhdprhgtphhtthhopehjuhhlihgvnhesgigvnhdrohhrghdprhgt
    phhtthhopehsshhtrggsvghllhhinhhisehkvghrnhgvlhdrohhrghdprhgtphhtthhope
    hrohhgvghrrdhprghusegtihhtrhhigidrtghomhdprhgtphhtthhopehluhhkrghsiies
    hhgrfihrhihlkhhordhplhdprhgtphhtthhopeguphhsmhhithhhsegrphgvrhhtuhhssh
    holhhuthhiohhnshdrtghomh
X-ME-Proxy: <xmx:Zch_Z755AO-PrQGC-a1xEYiJQuAoJk7e8nmdPj3hgIJ10EtgleE1DA>
    <xmx:Zch_Zz5OAGwZIl3GyuNOQBsmBP2siJ4K0hbbBqw7eVMMS8mji8uzng>
    <xmx:Zch_Z7ige6hJ0M-me-0uHUOap0tmQyYbijhVII5L8-ueRRkdDnmChg>
    <xmx:Zch_Z95PRvuvtyQXDYY9-i627oKPX_fTCs-dQY_O15ep2XNGHc_uFA>
    <xmx:Zsh_ZwzsLrEqlA4ISRhHzbdwStjeYQreQQz22YEZheSzxtbmLhAAJE9g>
Feedback-ID: i1568416f:Fastmail
Date: Thu, 9 Jan 2025 14:00:16 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Teddy Astie <teddy.astie@vates.tech>
Cc: Xen-devel <xen-devel@lists.xenproject.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>,
	Lukasz Hawrylko <lukasz@hawrylko.pl>,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Mateusz =?utf-8?B?TcOzd2th?= <mateusz.mowka@intel.com>
Subject: Re: [XEN RFC PATCH v4 0/5] IOMMU subsystem redesign and PV-IOMMU
 interface
Message-ID: <Z3_IYPG62-C2TD7N@mail-itl>
References: <cover.1730718102.git.teddy.astie@vates.tech>
 <Z38-y9xR-6C_sARJ@mail-itl>
 <c0b9fbdb-87db-4f31-8069-0c2d1c4ad4cd@vates.tech>
 <Z3-8O9opmLfgO5t0@mail-itl>
 <0897deb0-3d57-48a3-8f92-4714ba6d1217@vates.tech>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="v7lfulLpzS4d2Efo"
Content-Disposition: inline
In-Reply-To: <0897deb0-3d57-48a3-8f92-4714ba6d1217@vates.tech>


--v7lfulLpzS4d2Efo
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Thu, 9 Jan 2025 14:00:16 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Teddy Astie <teddy.astie@vates.tech>
Cc: Xen-devel <xen-devel@lists.xenproject.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>,
	Lukasz Hawrylko <lukasz@hawrylko.pl>,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Mateusz =?utf-8?B?TcOzd2th?= <mateusz.mowka@intel.com>
Subject: Re: [XEN RFC PATCH v4 0/5] IOMMU subsystem redesign and PV-IOMMU
 interface

On Thu, Jan 09, 2025 at 12:41:35PM +0000, Teddy Astie wrote:
> Will do some additional testing with PCI passthrough and plan to fix it=
=20
> for v5.

There are PCI passthrough tests on gitlab that should cover the cases I
hit. You may want to let the machine do the work for you ;)

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

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

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmd/yGAACgkQ24/THMrX
1yyBoQf+JeQ2ImtloDqbbEbAedjTMsFvvr64ZLcSwBXmHPE8Y/gIKLb6LvewwyxM
l5l6gmIRtN9dWLqqZNIQIpm+3J0wXQ4HGvTs86W3WhYDgK5cGXzgRh21dsGTf5Oq
H8r6ZkYyUZUpmecL21EdoFtfaquJYdw+BZ8a/fMLAPKzBkaGA22yrQQUty9ns3MK
qJoKg+bWbNyRAf+354l7QKuiSR52pa/DlDL82WGv6oejfKy+86jcLXtc9BmRMHfb
o9UkBQRP0+Ds+4sMvQFroEDDNwmf2N48c0hIwTA1hFOquVgPVUD5KWNsws49iFiK
7Hhyvr1LgE7puhz05lKTp55SXgNzOw==
=VLij
-----END PGP SIGNATURE-----

--v7lfulLpzS4d2Efo--


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 13:02:21 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 13:02:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868347.1279867 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVsB2-0000gP-IN; Thu, 09 Jan 2025 13:02:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868347.1279867; Thu, 09 Jan 2025 13: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 <xen-devel-bounces@lists.xenproject.org>)
	id 1tVsB2-0000gI-Fl; Thu, 09 Jan 2025 13:02:20 +0000
Received: by outflank-mailman (input) for mailman id 868347;
 Thu, 09 Jan 2025 13:02:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=FDwX=UB=arm.com=luca.fancellu@srs-se1.protection.inumbo.net>)
 id 1tVsB1-0000g9-6Z
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 13:02:19 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id f33aa208-ce89-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 14:02:16 +0100 (CET)
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2311D13D5;
 Thu,  9 Jan 2025 05:02:44 -0800 (PST)
Received: from e125770.cambridge.arm.com (e125770.arm.com [10.1.199.43])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E27793F673;
 Thu,  9 Jan 2025 05:02:14 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f33aa208-ce89-11ef-99a4-01e77a169b0f
From: Luca Fancellu <luca.fancellu@arm.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>
Subject: [for-4.20 PATCH v3] xen/arm: Fully initialise struct membanks_hdr fields
Date: Thu,  9 Jan 2025 13:02:04 +0000
Message-Id: <20250109130204.42545-1-luca.fancellu@arm.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Commit a14593e3995a ("xen/device-tree: Allow region overlapping with
/memreserve/ ranges") introduced a type in the 'struct membanks_hdr'
but forgot to update the 'struct kernel_info' initialiser, while
it doesn't lead to failures because the field is not currently
used while managing kernel_info structures, it's good to have it
for completeness.

There are other instance of structures using 'struct membanks_hdr'
that are dynamically allocated and don't fully initialise these
fields, provide a static inline helper for that.

Fixes: a14593e3995a ("xen/device-tree: Allow region overlapping with /memreserve/ ranges")
Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
---
Changes from v2:
 - Banks created by Xen should be MEMORY type. (Michal)
 - Add R-by Michal
Changes from v1:
 - Changed commit title and body msg
 - initialised max_banks and type for all structures using 'struct membanks_hdr'
---
---
 xen/arch/arm/domain_build.c       | 13 ++++---------
 xen/arch/arm/include/asm/kernel.h |  5 ++++-
 xen/arch/arm/static-shmem.c       |  3 ++-
 xen/include/xen/bootfdt.h         | 16 ++++++++++++++++
 4 files changed, 26 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index b072a16249fe..7b47abade196 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1039,7 +1039,7 @@ void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
      */
     if ( is_hardware_domain(d) )
     {
-        struct membanks *gnttab = xzalloc_flex_struct(struct membanks, bank, 1);
+        struct membanks *gnttab = membanks_xzalloc(1, MEMORY);
         /*
          * Exclude the following regions:
          * 1) Remove reserved memory
@@ -1057,13 +1057,10 @@ void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
         gnttab->bank[0].start = kinfo->gnttab_start;
         gnttab->bank[0].size = kinfo->gnttab_size;
 
-        hwdom_free_mem = xzalloc_flex_struct(struct membanks, bank,
-                                             NR_MEM_BANKS);
+        hwdom_free_mem = membanks_xzalloc(NR_MEM_BANKS, MEMORY);
         if ( !hwdom_free_mem )
             goto fail;
 
-        hwdom_free_mem->max_banks = NR_MEM_BANKS;
-
         if ( find_unallocated_memory(kinfo, mem_banks, ARRAY_SIZE(mem_banks),
                                      hwdom_free_mem, add_hwdom_free_regions) )
             goto fail;
@@ -1293,7 +1290,7 @@ static int __init find_host_extended_regions(const struct kernel_info *kinfo,
                                              struct membanks *ext_regions)
 {
     int res;
-    struct membanks *gnttab = xzalloc_flex_struct(struct membanks, bank, 1);
+    struct membanks *gnttab = membanks_xzalloc(1, MEMORY);
 
     /*
      * Exclude the following regions:
@@ -1374,12 +1371,10 @@ int __init make_hypervisor_node(struct domain *d,
     }
     else
     {
-        ext_regions = xzalloc_flex_struct(struct membanks, bank, NR_MEM_BANKS);
+        ext_regions = membanks_xzalloc(NR_MEM_BANKS, MEMORY);
         if ( !ext_regions )
             return -ENOMEM;
 
-        ext_regions->max_banks = NR_MEM_BANKS;
-
         if ( domain_use_host_layout(d) )
         {
             if ( !is_iommu_enabled(d) )
diff --git a/xen/arch/arm/include/asm/kernel.h b/xen/arch/arm/include/asm/kernel.h
index 7e6e3c82a477..de3f945ae54c 100644
--- a/xen/arch/arm/include/asm/kernel.h
+++ b/xen/arch/arm/include/asm/kernel.h
@@ -92,7 +92,9 @@ kernel_info_get_mem_const(const struct kernel_info *kinfo)
 }
 
 #ifdef CONFIG_STATIC_SHM
-#define KERNEL_INFO_SHM_MEM_INIT .shm_mem.common.max_banks = NR_SHMEM_BANKS,
+#define KERNEL_INFO_SHM_MEM_INIT                \
+    .shm_mem.common.max_banks = NR_SHMEM_BANKS, \
+    .shm_mem.common.type = STATIC_SHARED_MEMORY,
 #else
 #define KERNEL_INFO_SHM_MEM_INIT
 #endif
@@ -100,6 +102,7 @@ kernel_info_get_mem_const(const struct kernel_info *kinfo)
 #define KERNEL_INFO_INIT                        \
 {                                               \
     .mem.common.max_banks = NR_MEM_BANKS,       \
+    .mem.common.type = MEMORY,                  \
     KERNEL_INFO_SHM_MEM_INIT                    \
 }
 
diff --git a/xen/arch/arm/static-shmem.c b/xen/arch/arm/static-shmem.c
index 66088a426785..8f87154c3587 100644
--- a/xen/arch/arm/static-shmem.c
+++ b/xen/arch/arm/static-shmem.c
@@ -20,7 +20,8 @@ static struct {
     struct membanks_hdr common;
     struct membank bank[NR_SHMEM_BANKS];
 } shm_heap_banks __initdata = {
-    .common.max_banks = NR_SHMEM_BANKS
+    .common.max_banks = NR_SHMEM_BANKS,
+    .common.type = STATIC_SHARED_MEMORY
 };
 
 static inline struct membanks *get_shmem_heap_banks(void)
diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
index c8bbfd8979b2..80a90e53c001 100644
--- a/xen/include/xen/bootfdt.h
+++ b/xen/include/xen/bootfdt.h
@@ -4,6 +4,7 @@
 #include <xen/types.h>
 #include <xen/kernel.h>
 #include <xen/macros.h>
+#include <xen/xmalloc.h>
 
 #define MIN_FDT_ALIGN 8
 
@@ -219,4 +220,19 @@ static inline struct shmem_membank_extra *bootinfo_get_shmem_extra(void)
 }
 #endif
 
+static inline struct membanks *membanks_xzalloc(unsigned int nr,
+                                                enum region_type type)
+{
+    struct membanks *banks = xzalloc_flex_struct(struct membanks, bank, nr);
+
+    if ( !banks )
+        goto out;
+
+    banks->max_banks = nr;
+    banks->type = type;
+
+ out:
+    return banks;
+}
+
 #endif /* XEN_BOOTFDT_H */
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 13:15:51 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 13:15:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868359.1279876 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVsNp-0002V7-L9; Thu, 09 Jan 2025 13:15:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868359.1279876; Thu, 09 Jan 2025 13:15:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVsNp-0002V0-Id; Thu, 09 Jan 2025 13:15:33 +0000
Received: by outflank-mailman (input) for mailman id 868359;
 Thu, 09 Jan 2025 13:15:32 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=eYg4=UB=invisiblethingslab.com=marmarek@srs-se1.protection.inumbo.net>)
 id 1tVsNo-0002Uu-B2
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 13:15:32 +0000
Received: from fout-a4-smtp.messagingengine.com
 (fout-a4-smtp.messagingengine.com [103.168.172.147])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id cc176354-ce8b-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 14:15:30 +0100 (CET)
Received: from phl-compute-01.internal (phl-compute-01.phl.internal
 [10.202.2.41])
 by mailfout.phl.internal (Postfix) with ESMTP id C089313803AD;
 Thu,  9 Jan 2025 08:15:28 -0500 (EST)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-01.internal (MEProxy); Thu, 09 Jan 2025 08:15:28 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 9 Jan 2025 08:15:27 -0500 (EST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: cc176354-ce8b-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:message-id:mime-version:reply-to:subject:subject:to:to; s=fm2;
	 t=1736428528; x=1736514928; bh=m2abBxRo9SxXbM+8hKw6HSWO7tQK6uGC
	f+3A+K3+Z/w=; b=qpIny3qBOTky6gnYuyXNGQSpVicu6rXc1uqTzZ2ghg09WLXe
	SnXiZoYh5I1/ILNuR/4MD+2oyYvIFNVNhrZMOVRz18FGnNP18bT9UG7LmXJyr3wW
	jVHpQpMUktP8Hhk96l4qBoq0TBDwJBaOKQdtGLChaPapGBHQUMJQsHNsSinrJN/Y
	48WdrrI6lAtmzIufohr6mRbSCAqcjijHrd1V+TFmXlDa82Wc394h6yoDcFO+yiFZ
	h3fZI9kvXnNiAZoQoWoGNH2UnCeKwRZWu7hCTrZ6QTnt0VrmOQBKHdvfstDRck8z
	ua0N6qvODYB12+HtR9CIZu0WmLFDayGd5VKK9w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:feedback-id:feedback-id
	:from:from:in-reply-to:message-id:mime-version:reply-to:subject
	:subject:to:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=
	fm2; t=1736428528; x=1736514928; bh=m2abBxRo9SxXbM+8hKw6HSWO7tQK
	6uGCf+3A+K3+Z/w=; b=n7W22jrHcplfqZIHK4BXpBGI232DM49ZVj8qWxe2Z6Yp
	9fHmGzUWDeh0AQIwovHQaGH5sFuv2eJi35mzUecO0jZi7CYTvj9vB5gA6tt7thcO
	oW0zlcydrFrWvFnW4+wffxGnlTvdkYeAIJNe0+mkkPmWdgaokGPS5ylm2cN10PWx
	/NzRkLogsGVCuR2y+R7hE5oHNg3BaABy6XRe+sTsyo7IQYESQFLB2TDUuQMFDyIU
	8K3T86ZTltDiD9MzylHxaN7Af3B/G+MeQzUbmY17QAVdbRHClYhajuKsJNaJRH4Q
	YdY8/QA0jg4jpmmcj4yIYaA6VfTw/IKHQARNw6EyjA==
X-ME-Sender: <xms:8Mt_Z5hHYCR3rhblQfaG3dFpp4K3ak1AHdPQAvsb0xVkTgG4XHK0mg>
    <xme:8Mt_Z-AnZxVbizxqu-usTkuoYH6FsFq3RcxtMSJJ3wz1rnqZghnkto2PUN1jbRQ4R
    gJ_-2uxin5icg>
X-ME-Received: <xmr:8Mt_Z5GSn8Qghm70mCdY951k410x89B5B2BKHwczA1cTxAFAn4Kv46YPkgKUWwKPVcGUMkWIcmeVqI0szZ2u6WtckLE8uFEqrPfmeLwzixTCkkJ-cag>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrudegiedggeekucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
    rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
    htshculddquddttddmnecujfgurhephffvvefufffkofggtgfgsehtkeertdertdejnecu
    hfhrohhmpeforghrvghkucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrg
    hrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffr
    rghtthgvrhhnpedtjeehieevhfettdefudefgfegteejkeffueegudekieeftddvudfggf
    dugfekgfenucffohhmrghinhepsggrshgvrdhlughspdhofhhfshgvthdrlhgushenucev
    lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrh
    gvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthho
    peeipdhmohguvgepshhmthhpohhuthdprhgtphhtthhopeigvghnqdguvghvvghlsehlih
    hsthhsrdigvghnphhrohhjvggtthdrohhrghdprhgtphhtthhopehmrghrmhgrrhgvkhes
    ihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhrtghpthhtohepfhhrvgguih
    grnhhordiiihhglhhiohestghlohhuugdrtghomhdprhgtphhtthhopehjsggvuhhlihgt
    hhesshhushgvrdgtohhmpdhrtghpthhtoheprghnughrvgifrdgtohhophgvrhefsegtih
    htrhhigidrtghomhdprhgtphhtthhopehrohhgvghrrdhprghusegtihhtrhhigidrtgho
    mh
X-ME-Proxy: <xmx:8Mt_Z-QZLzbbVMdAIPyt6LRH243jGZly2N0VQWWjFBKdsat8px0CDA>
    <xmx:8Mt_Z2yixDW4WMOowvulaKlOIsw28-T5D3g_mPS_lU5DtiZmwlQBTg>
    <xmx:8Mt_Z07MHHNvCFhEL--P29UiydINeEjXQqzSASBnMsTeCcyTbrwHsA>
    <xmx:8Mt_Z7yiVlGLoz8z6L1snPeCNi40Vnazu_Zl6YPaaRtidJXLsvLufQ>
    <xmx:8Mt_Z9nCThlsocEatcRJoGPd64nqpSJLP1gWktTTvD02tPDVgAZXbmcJ>
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>,
	Frediano Ziglio <frediano.ziglio@cloud.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PATCH] x86/boot: adjust text gap/diff to work with 64-bytes alignment too
Date: Thu,  9 Jan 2025 14:15:06 +0100
Message-ID: <20250109131515.1757764-1-marmarek@invisiblethingslab.com>
X-Mailer: git-send-email 2.46.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Xen compiled with -mtune=generic has .text alignment set to 64-bytes.
Having text_diff non-64-bytes-aligned breaks stuff:

    Traceback (most recent call last):
      File "/builddir/build/BUILD/xen-4.20.0-build/xen-4.20.0-rc0/xen/./tools/combine_two_binaries.py", line 96, in <module>
        raise Exception('File sizes do not match')
    Exception: File sizes do not match: 70160 != 4080 + 66048

Adjust the numbers as suggested by Frediano to work with 64-bytes and
even 128-bytes alignment.

Suggested-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
---
 xen/arch/x86/boot/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
index d45787665907..80c32163fbbd 100644
--- a/xen/arch/x86/boot/Makefile
+++ b/xen/arch/x86/boot/Makefile
@@ -40,8 +40,8 @@ LD32 := $(LD) $(subst x86_64,i386,$(LDFLAGS_DIRECT))
 # are affected by both text_diff and text_gap.  Ensure the sum of gap and diff
 # is greater than 2^16 so that any 16bit relocations if present in the object
 # file turns into a build-time error.
-text_gap := 0x010200
-text_diff := 0x408020
+text_gap := 0x010240
+text_diff := 0x608040
 
 $(obj)/build32.base.lds: AFLAGS-y += -DGAP=$(text_gap) -DTEXT_DIFF=$(text_diff)
 $(obj)/build32.offset.lds: AFLAGS-y += -DGAP=$(text_gap) -DTEXT_DIFF=$(text_diff) -DAPPLY_OFFSET
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 13:18:42 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 13:18:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868368.1279887 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVsQr-000355-5P; Thu, 09 Jan 2025 13:18:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868368.1279887; Thu, 09 Jan 2025 13:18:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVsQr-00034y-2Z; Thu, 09 Jan 2025 13:18:41 +0000
Received: by outflank-mailman (input) for mailman id 868368;
 Thu, 09 Jan 2025 13:17:01 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=YggD=UB=kernel.org=joel.granados@srs-se1.protection.inumbo.net>)
 id 1tVsPF-000315-BY
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 13:17:01 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org
 [2604:1380:45d1:ec00::3])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 00fc6a5e-ce8c-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 14:16:58 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 4D93DA41BC3;
 Thu,  9 Jan 2025 13:15:08 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPS id 72292C4CED2;
 Thu,  9 Jan 2025 13:16:56 +0000 (UTC)
Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org
 (localhost.localdomain [127.0.0.1])
 by smtp.lore.kernel.org (Postfix) with ESMTP id 5A4BFE77197;
 Thu,  9 Jan 2025 13:16:56 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 00fc6a5e-ce8c-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1736428616;
	bh=QHFDDYEIESLL8xDpW6X9Y5s2XowLH1Fd+eLbLdm47vM=;
	h=From:Date:Subject:To:Cc:From;
	b=MZNAenKt/5u4q+Ekg15RQfUrwQ31IopEH16I5ztuNSX5gsVJRJgqlN0GdGCPz7EqU
	 qHudQsZxpNCJCbqsxfLPEF7Q3CCrqJv5udU3yhN9yxi6kYuNnZAvpTiKTeZOBFDH+y
	 0qNfj/c6BEF9seU9kUr3jcH7cXvFQVyXolb+BnTU/8Dumg9301T99Iy7PwFl7nPI27
	 1XWLRbpnngpXn8HqExbM4Bwg2Q8OHDARuuYuTdekV0EGHQyN8SsrNRqKo0ZBX3uOv2
	 95yvIvckZtldFKBbGUso0ImbwVHpx2iJxURg1QBQ40wUVbi+ei1ByIBMN8JkOv6/mF
	 VWxdzlDWDoJ8A==
From: Joel Granados <joel.granados@kernel.org>
Date: Thu, 09 Jan 2025 14:16:39 +0100
Subject: [PATCH] treewide: const qualify ctl_tables where applicable
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20250109-jag-ctl_table_const-v1-1-622aea7230cf@kernel.org>
X-B4-Tracking: v=1; b=H4sIADbMf2cC/x3MTQqAIBBA4avErBPM6PcqEaLTVBNhoRJBdPek5
 bd474FAnilAnz3g6eLAh0so8gxwNW4hwVMyKKkqWchObGYRGHcdjd1J4+FCFGU711YhWmsaSOX
 paeb7vw7j+37JTJubZQAAAA==
To: =?utf-8?q?Thomas_Wei=C3=9Fschuh?= <linux@weissschuh.net>, 
 Kees Cook <kees@kernel.org>, Luis Chamberlain <mcgrof@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, 
 linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, 
 linux-s390@vger.kernel.org, linux-crypto@vger.kernel.org, 
 openipmi-developer@lists.sourceforge.net, intel-gfx@lists.freedesktop.org, 
 dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org, 
 linux-hyperv@vger.kernel.org, linux-rdma@vger.kernel.org, 
 linux-raid@vger.kernel.org, linux-scsi@vger.kernel.org, 
 linux-serial@vger.kernel.org, xen-devel@lists.xenproject.org, 
 linux-aio@kvack.org, linux-fsdevel@vger.kernel.org, netfs@lists.linux.dev, 
 codalist@coda.cs.cmu.edu, linux-mm@kvack.org, linux-nfs@vger.kernel.org, 
 ocfs2-devel@lists.linux.dev, fsverity@lists.linux.dev, 
 linux-xfs@vger.kernel.org, io-uring@vger.kernel.org, bpf@vger.kernel.org, 
 kexec@lists.infradead.org, linux-trace-kernel@vger.kernel.org, 
 linux-hardening@vger.kernel.org, apparmor@lists.ubuntu.com, 
 linux-security-module@vger.kernel.org, keyrings@vger.kernel.org, 
 Joel Granados <joel.granados@kernel.org>
X-Mailer: b4 0.15-dev-00a43
X-Developer-Signature: v=1; a=openpgp-sha256; l=64124;
 i=joel.granados@kernel.org; h=from:subject:message-id;
 bh=QHFDDYEIESLL8xDpW6X9Y5s2XowLH1Fd+eLbLdm47vM=;
 b=owJ4nAHtARL+kA0DAAoBupfNUreWQU8ByyZiAGd/zEbbYaRdkysCJ+jpppy2dECrbdVpWmHU4
 jeUslEo4A/TgIkBswQAAQoAHRYhBK5HCVcl5jElzssnkLqXzVK3lkFPBQJnf8xGAAoJELqXzVK3
 lkFPbWcMAI8bS7hGmC8o4j/KTrRjhK0qGDUbFUwydu3CXaxb37Vb7kdGXBtl/0ahO4L9rdsDNAA
 49m6fEujEgmAjZ4ZEv9s0BTCttKkupimacMMKD2DS8uY3YjEkojI+8xPj/6hpeW3uFlLth0SQIE
 Gah6s/HUK5BvOxagvM6jf1p28mhPv4LisrNbjEg5JNb/kc5NDV6f8UlcqprDTEsSty0dyCfJNXu
 F0IDnhhRaXwUuVsXnsVAFbdiOGC/3lWe2zJg3eKExYAXF0IupI0iromTCKyNrN32FO1buoMKMqo
 DsoTOyU7F5zNmMjE2LkGj7eYcpi7Y/MjXkjTfpabVjGPomahc15ChMwuZZq2fvSGa1QLPl5HYBC
 +/aDXHj7K174H5EmyGeiG9RA+Xob8Y5nazXtSruUaxNck1Sl6G89tUXLohZCmU1JbAkJUdyHy8O
 7j3zlizHbXdlrODQM9RR+EdDByexygbJsD7UcPl1P9QLIn1NALjNePIFM1SQw5c6AhHVg8/b4u4
 vg=
X-Developer-Key: i=joel.granados@kernel.org; a=openpgp;
 fpr=F1F8E46D30F0F6C4A45FF4465895FAAC338C6E77
X-Endpoint-Received: by B4 Relay for joel.granados@kernel.org/default with
 auth_id=239

Add the const qualifier to all the ctl_tables in the tree except the
ones in ./net dir. The "net" sysctl code is special as it modifies the
arrays before passing it on to the registration function.

Constifying ctl_table structs will prevent the modification of
proc_handler function pointers as the arrays would reside in .rodata.
This is made possible after commit 78eb4ea25cd5 ("sysctl: treewide:
constify the ctl_table argument of proc_handlers") constified all the
proc_handlers.

Created this by running an spatch followed by a sed command:
Spatch:
    virtual patch

    @
    depends on !(file in "net")
    disable optional_qualifier
    @
    identifier table_name;
    @@

    + const
    struct ctl_table table_name [] = { ... };

sed:
    sed --in-place \
      -e "s/struct ctl_table .table = &uts_kern/const struct ctl_table *table = \&uts_kern/" \
      kernel/utsname_sysctl.c

Signed-off-by: Joel Granados <joel.granados@kernel.org>
---
This treewide commit builds upon the work Thomas began a few releases
ago [1], where he laid the groundwork for constifying ctl_tables. We
implement constification throughout the tree, with the exception of the
ctl_tables in the "net" directory. Those are special in that they treat
the ctl_table as non-const but we can take them at a later point.

Upstreaming:
===========
It is late in the release cycle, but I'm hopeful that we can get this
in for the upcoming merge window and this is why:
1. We don't use linux-next: As with previous treewide changes similar to
   this one [1], we avoid using linux-next in order to avoid unwanted
   merge conflicts
2. This is a non-functional change: which lowers the probability of
   unforeseen errors or regressions.
3. It will have at least 2 weeks to be tested/reviewed: The PULL should
   be sent at the end of the merge window, giving it at least 2 weeks.
   And if there are more release candidates after rc6, there will be
   more time.

Testing:
========
1. Currently being tested in 0-day
2. sysctl self-tests/kunit-tests

Reduced To/Cc:
==============
b4 originally gave me 200 ppl that this should go out to (which seems a
bit overkill from my point of view). So I left the mailing lists and
reduced the To: the ppl previously involved in the effort and sysctl
maintainers. Please tell me if I missed someone important to the
constification effort.

Comments are greatly appreciated.
Specially interested in any specifics from @Thomas and @kees

Best

[1] https://lore.kernel.org/20240724210014.mc6nima6cekgiukx@joelS2.panther.com

--
---
 arch/arm/kernel/isa.c                         | 2 +-
 arch/arm64/kernel/fpsimd.c                    | 4 ++--
 arch/arm64/kernel/process.c                   | 2 +-
 arch/powerpc/kernel/idle.c                    | 2 +-
 arch/powerpc/platforms/pseries/mobility.c     | 2 +-
 arch/riscv/kernel/process.c                   | 2 +-
 arch/riscv/kernel/vector.c                    | 2 +-
 arch/s390/appldata/appldata_base.c            | 2 +-
 arch/s390/kernel/debug.c                      | 2 +-
 arch/s390/kernel/hiperdispatch.c              | 2 +-
 arch/s390/kernel/topology.c                   | 2 +-
 arch/s390/mm/cmm.c                            | 2 +-
 arch/s390/mm/pgalloc.c                        | 2 +-
 arch/x86/entry/vdso/vdso32-setup.c            | 2 +-
 arch/x86/kernel/cpu/bus_lock.c                | 2 +-
 arch/x86/kernel/itmt.c                        | 2 +-
 crypto/fips.c                                 | 2 +-
 drivers/base/firmware_loader/fallback_table.c | 2 +-
 drivers/cdrom/cdrom.c                         | 2 +-
 drivers/char/hpet.c                           | 2 +-
 drivers/char/ipmi/ipmi_poweroff.c             | 2 +-
 drivers/char/random.c                         | 2 +-
 drivers/gpu/drm/i915/i915_perf.c              | 2 +-
 drivers/gpu/drm/xe/xe_observation.c           | 2 +-
 drivers/hv/hv_common.c                        | 2 +-
 drivers/infiniband/core/iwcm.c                | 2 +-
 drivers/infiniband/core/ucma.c                | 2 +-
 drivers/macintosh/mac_hid.c                   | 2 +-
 drivers/md/md.c                               | 2 +-
 drivers/misc/sgi-xp/xpc_main.c                | 4 ++--
 drivers/perf/arm_pmuv3.c                      | 2 +-
 drivers/perf/riscv_pmu_sbi.c                  | 2 +-
 drivers/scsi/scsi_sysctl.c                    | 2 +-
 drivers/scsi/sg.c                             | 2 +-
 drivers/tty/tty_io.c                          | 2 +-
 drivers/xen/balloon.c                         | 2 +-
 fs/aio.c                                      | 2 +-
 fs/cachefiles/error_inject.c                  | 2 +-
 fs/coda/sysctl.c                              | 2 +-
 fs/coredump.c                                 | 2 +-
 fs/dcache.c                                   | 2 +-
 fs/devpts/inode.c                             | 2 +-
 fs/eventpoll.c                                | 2 +-
 fs/exec.c                                     | 2 +-
 fs/file_table.c                               | 2 +-
 fs/fuse/sysctl.c                              | 2 +-
 fs/inode.c                                    | 2 +-
 fs/lockd/svc.c                                | 2 +-
 fs/locks.c                                    | 2 +-
 fs/namei.c                                    | 2 +-
 fs/namespace.c                                | 2 +-
 fs/nfs/nfs4sysctl.c                           | 2 +-
 fs/nfs/sysctl.c                               | 2 +-
 fs/notify/dnotify/dnotify.c                   | 2 +-
 fs/notify/fanotify/fanotify_user.c            | 2 +-
 fs/notify/inotify/inotify_user.c              | 2 +-
 fs/ocfs2/stackglue.c                          | 2 +-
 fs/pipe.c                                     | 2 +-
 fs/quota/dquot.c                              | 2 +-
 fs/sysctls.c                                  | 2 +-
 fs/userfaultfd.c                              | 2 +-
 fs/verity/init.c                              | 2 +-
 fs/xfs/xfs_sysctl.c                           | 2 +-
 init/do_mounts_initrd.c                       | 2 +-
 io_uring/io_uring.c                           | 2 +-
 ipc/ipc_sysctl.c                              | 2 +-
 ipc/mq_sysctl.c                               | 2 +-
 kernel/acct.c                                 | 2 +-
 kernel/bpf/syscall.c                          | 2 +-
 kernel/delayacct.c                            | 2 +-
 kernel/exit.c                                 | 2 +-
 kernel/hung_task.c                            | 2 +-
 kernel/kexec_core.c                           | 2 +-
 kernel/kprobes.c                              | 2 +-
 kernel/latencytop.c                           | 2 +-
 kernel/locking/lockdep.c                      | 2 +-
 kernel/panic.c                                | 2 +-
 kernel/pid_namespace.c                        | 2 +-
 kernel/pid_sysctl.h                           | 2 +-
 kernel/printk/sysctl.c                        | 2 +-
 kernel/reboot.c                               | 2 +-
 kernel/sched/autogroup.c                      | 2 +-
 kernel/sched/core.c                           | 2 +-
 kernel/sched/deadline.c                       | 2 +-
 kernel/sched/fair.c                           | 2 +-
 kernel/sched/rt.c                             | 2 +-
 kernel/sched/topology.c                       | 2 +-
 kernel/seccomp.c                              | 2 +-
 kernel/signal.c                               | 2 +-
 kernel/stackleak.c                            | 2 +-
 kernel/sysctl-test.c                          | 6 +++---
 kernel/sysctl.c                               | 4 ++--
 kernel/time/timer.c                           | 2 +-
 kernel/trace/ftrace.c                         | 2 +-
 kernel/trace/trace_events_user.c              | 2 +-
 kernel/umh.c                                  | 2 +-
 kernel/utsname_sysctl.c                       | 4 ++--
 kernel/watchdog.c                             | 4 ++--
 lib/alloc_tag.c                               | 2 +-
 lib/test_sysctl.c                             | 6 +++---
 mm/compaction.c                               | 2 +-
 mm/hugetlb.c                                  | 2 +-
 mm/hugetlb_vmemmap.c                          | 2 +-
 mm/memory-failure.c                           | 2 +-
 mm/oom_kill.c                                 | 2 +-
 mm/page-writeback.c                           | 2 +-
 mm/page_alloc.c                               | 2 +-
 security/apparmor/lsm.c                       | 2 +-
 security/keys/sysctl.c                        | 2 +-
 security/loadpin/loadpin.c                    | 2 +-
 security/yama/yama_lsm.c                      | 2 +-
 111 files changed, 120 insertions(+), 120 deletions(-)

diff --git a/arch/arm/kernel/isa.c b/arch/arm/kernel/isa.c
index 905b1b191546..db8be609fab2 100644
--- a/arch/arm/kernel/isa.c
+++ b/arch/arm/kernel/isa.c
@@ -16,7 +16,7 @@
 
 static unsigned int isa_membase, isa_portbase, isa_portshift;
 
-static struct ctl_table ctl_isa_vars[] = {
+static const struct ctl_table ctl_isa_vars[] = {
 	{
 		.procname	= "membase",
 		.data		= &isa_membase, 
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 8c4c1a2186cc..2b601d88762d 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -562,7 +562,7 @@ static int vec_proc_do_default_vl(const struct ctl_table *table, int write,
 	return 0;
 }
 
-static struct ctl_table sve_default_vl_table[] = {
+static const struct ctl_table sve_default_vl_table[] = {
 	{
 		.procname	= "sve_default_vector_length",
 		.mode		= 0644,
@@ -585,7 +585,7 @@ static int __init sve_sysctl_init(void) { return 0; }
 #endif /* ! (CONFIG_ARM64_SVE && CONFIG_SYSCTL) */
 
 #if defined(CONFIG_ARM64_SME) && defined(CONFIG_SYSCTL)
-static struct ctl_table sme_default_vl_table[] = {
+static const struct ctl_table sme_default_vl_table[] = {
 	{
 		.procname	= "sme_default_vector_length",
 		.mode		= 0644,
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 2968a33bb3bc..42faebb7b712 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -859,7 +859,7 @@ long get_tagged_addr_ctrl(struct task_struct *task)
  * disable it for tasks that already opted in to the relaxed ABI.
  */
 
-static struct ctl_table tagged_addr_sysctl_table[] = {
+static const struct ctl_table tagged_addr_sysctl_table[] = {
 	{
 		.procname	= "tagged_addr_disabled",
 		.mode		= 0644,
diff --git a/arch/powerpc/kernel/idle.c b/arch/powerpc/kernel/idle.c
index 30b56c67fa61..e527cd3ef128 100644
--- a/arch/powerpc/kernel/idle.c
+++ b/arch/powerpc/kernel/idle.c
@@ -97,7 +97,7 @@ void power4_idle(void)
 /*
  * Register the sysctl to set/clear powersave_nap.
  */
-static struct ctl_table powersave_nap_ctl_table[] = {
+static const struct ctl_table powersave_nap_ctl_table[] = {
 	{
 		.procname	= "powersave-nap",
 		.data		= &powersave_nap,
diff --git a/arch/powerpc/platforms/pseries/mobility.c b/arch/powerpc/platforms/pseries/mobility.c
index 1798f0f14d58..62bd8e2d5d4c 100644
--- a/arch/powerpc/platforms/pseries/mobility.c
+++ b/arch/powerpc/platforms/pseries/mobility.c
@@ -53,7 +53,7 @@ struct update_props_workarea {
 static unsigned int nmi_wd_lpm_factor = 200;
 
 #ifdef CONFIG_SYSCTL
-static struct ctl_table nmi_wd_lpm_factor_ctl_table[] = {
+static const struct ctl_table nmi_wd_lpm_factor_ctl_table[] = {
 	{
 		.procname	= "nmi_wd_lpm_factor",
 		.data		= &nmi_wd_lpm_factor,
diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c
index 58b6482c2bf6..7891294abf49 100644
--- a/arch/riscv/kernel/process.c
+++ b/arch/riscv/kernel/process.c
@@ -364,7 +364,7 @@ static bool try_to_set_pmm(unsigned long value)
  * disable it for tasks that already opted in to the relaxed ABI.
  */
 
-static struct ctl_table tagged_addr_sysctl_table[] = {
+static const struct ctl_table tagged_addr_sysctl_table[] = {
 	{
 		.procname	= "tagged_addr_disabled",
 		.mode		= 0644,
diff --git a/arch/riscv/kernel/vector.c b/arch/riscv/kernel/vector.c
index 821818886fab..d022b028ac3f 100644
--- a/arch/riscv/kernel/vector.c
+++ b/arch/riscv/kernel/vector.c
@@ -287,7 +287,7 @@ long riscv_v_vstate_ctrl_set_current(unsigned long arg)
 
 #ifdef CONFIG_SYSCTL
 
-static struct ctl_table riscv_v_default_vstate_table[] = {
+static const struct ctl_table riscv_v_default_vstate_table[] = {
 	{
 		.procname	= "riscv_v_default_allow",
 		.data		= &riscv_v_implicit_uacc,
diff --git a/arch/s390/appldata/appldata_base.c b/arch/s390/appldata/appldata_base.c
index 91a30e017d65..dd7ba7587dd5 100644
--- a/arch/s390/appldata/appldata_base.c
+++ b/arch/s390/appldata/appldata_base.c
@@ -52,7 +52,7 @@ static int appldata_interval_handler(const struct ctl_table *ctl, int write,
 				     void *buffer, size_t *lenp, loff_t *ppos);
 
 static struct ctl_table_header *appldata_sysctl_header;
-static struct ctl_table appldata_table[] = {
+static const struct ctl_table appldata_table[] = {
 	{
 		.procname	= "timer",
 		.mode		= S_IRUGO | S_IWUSR,
diff --git a/arch/s390/kernel/debug.c b/arch/s390/kernel/debug.c
index de19fd8a6a95..2c245c2bce4f 100644
--- a/arch/s390/kernel/debug.c
+++ b/arch/s390/kernel/debug.c
@@ -972,7 +972,7 @@ static int s390dbf_procactive(const struct ctl_table *table, int write,
 		return 0;
 }
 
-static struct ctl_table s390dbf_table[] = {
+static const struct ctl_table s390dbf_table[] = {
 	{
 		.procname	= "debug_stoppable",
 		.data		= &debug_stoppable,
diff --git a/arch/s390/kernel/hiperdispatch.c b/arch/s390/kernel/hiperdispatch.c
index 2a99a216ab62..7857a7e8e56c 100644
--- a/arch/s390/kernel/hiperdispatch.c
+++ b/arch/s390/kernel/hiperdispatch.c
@@ -292,7 +292,7 @@ static int hiperdispatch_ctl_handler(const struct ctl_table *ctl, int write,
 	return 0;
 }
 
-static struct ctl_table hiperdispatch_ctl_table[] = {
+static const struct ctl_table hiperdispatch_ctl_table[] = {
 	{
 		.procname	= "hiperdispatch",
 		.mode		= 0644,
diff --git a/arch/s390/kernel/topology.c b/arch/s390/kernel/topology.c
index 4f9c301a705b..5067293ef69d 100644
--- a/arch/s390/kernel/topology.c
+++ b/arch/s390/kernel/topology.c
@@ -662,7 +662,7 @@ static int polarization_ctl_handler(const struct ctl_table *ctl, int write,
 	return set_polarization(polarization);
 }
 
-static struct ctl_table topology_ctl_table[] = {
+static const struct ctl_table topology_ctl_table[] = {
 	{
 		.procname	= "topology",
 		.mode		= 0644,
diff --git a/arch/s390/mm/cmm.c b/arch/s390/mm/cmm.c
index d01724a715d0..939e3bec2db7 100644
--- a/arch/s390/mm/cmm.c
+++ b/arch/s390/mm/cmm.c
@@ -332,7 +332,7 @@ static int cmm_timeout_handler(const struct ctl_table *ctl, int write,
 	return 0;
 }
 
-static struct ctl_table cmm_table[] = {
+static const struct ctl_table cmm_table[] = {
 	{
 		.procname	= "cmm_pages",
 		.mode		= 0644,
diff --git a/arch/s390/mm/pgalloc.c b/arch/s390/mm/pgalloc.c
index 58696a0c4e4a..18d3176e44fb 100644
--- a/arch/s390/mm/pgalloc.c
+++ b/arch/s390/mm/pgalloc.c
@@ -21,7 +21,7 @@
 int page_table_allocate_pgste = 0;
 EXPORT_SYMBOL(page_table_allocate_pgste);
 
-static struct ctl_table page_table_sysctl[] = {
+static const struct ctl_table page_table_sysctl[] = {
 	{
 		.procname	= "allocate_pgste",
 		.data		= &page_table_allocate_pgste,
diff --git a/arch/x86/entry/vdso/vdso32-setup.c b/arch/x86/entry/vdso/vdso32-setup.c
index 76e4e74f35b5..f6d2d8aba643 100644
--- a/arch/x86/entry/vdso/vdso32-setup.c
+++ b/arch/x86/entry/vdso/vdso32-setup.c
@@ -57,7 +57,7 @@ __setup_param("vdso=", vdso_setup, vdso32_setup, 0);
 /* Register vsyscall32 into the ABI table */
 #include <linux/sysctl.h>
 
-static struct ctl_table abi_table2[] = {
+static const struct ctl_table abi_table2[] = {
 	{
 		.procname	= "vsyscall32",
 		.data		= &vdso32_enabled,
diff --git a/arch/x86/kernel/cpu/bus_lock.c b/arch/x86/kernel/cpu/bus_lock.c
index 704e9241b964..6cba85c79d42 100644
--- a/arch/x86/kernel/cpu/bus_lock.c
+++ b/arch/x86/kernel/cpu/bus_lock.c
@@ -49,7 +49,7 @@ static unsigned int sysctl_sld_mitigate = 1;
 static DEFINE_SEMAPHORE(buslock_sem, 1);
 
 #ifdef CONFIG_PROC_SYSCTL
-static struct ctl_table sld_sysctls[] = {
+static const struct ctl_table sld_sysctls[] = {
 	{
 		.procname       = "split_lock_mitigate",
 		.data           = &sysctl_sld_mitigate,
diff --git a/arch/x86/kernel/itmt.c b/arch/x86/kernel/itmt.c
index 51b805c727fc..083d8c4deb2b 100644
--- a/arch/x86/kernel/itmt.c
+++ b/arch/x86/kernel/itmt.c
@@ -64,7 +64,7 @@ static int sched_itmt_update_handler(const struct ctl_table *table, int write,
 	return ret;
 }
 
-static struct ctl_table itmt_kern_table[] = {
+static const struct ctl_table itmt_kern_table[] = {
 	{
 		.procname	= "sched_itmt_enabled",
 		.data		= &sysctl_sched_itmt_enabled,
diff --git a/crypto/fips.c b/crypto/fips.c
index 8a784018ebfc..ec6574596e59 100644
--- a/crypto/fips.c
+++ b/crypto/fips.c
@@ -41,7 +41,7 @@ __setup("fips=", fips_enable);
 static char fips_name[] = FIPS_MODULE_NAME;
 static char fips_version[] = FIPS_MODULE_VERSION;
 
-static struct ctl_table crypto_sysctl_table[] = {
+static const struct ctl_table crypto_sysctl_table[] = {
 	{
 		.procname	= "fips_enabled",
 		.data		= &fips_enabled,
diff --git a/drivers/base/firmware_loader/fallback_table.c b/drivers/base/firmware_loader/fallback_table.c
index ddb70e29eb42..c8afc501a8a4 100644
--- a/drivers/base/firmware_loader/fallback_table.c
+++ b/drivers/base/firmware_loader/fallback_table.c
@@ -25,7 +25,7 @@ struct firmware_fallback_config fw_fallback_config = {
 EXPORT_SYMBOL_NS_GPL(fw_fallback_config, "FIRMWARE_LOADER_PRIVATE");
 
 #ifdef CONFIG_SYSCTL
-static struct ctl_table firmware_config_table[] = {
+static const struct ctl_table firmware_config_table[] = {
 	{
 		.procname	= "force_sysfs_fallback",
 		.data		= &fw_fallback_config.force_sysfs_fallback,
diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
index 51745ed1bbab..b163e043c687 100644
--- a/drivers/cdrom/cdrom.c
+++ b/drivers/cdrom/cdrom.c
@@ -3612,7 +3612,7 @@ static int cdrom_sysctl_handler(const struct ctl_table *ctl, int write,
 }
 
 /* Place files in /proc/sys/dev/cdrom */
-static struct ctl_table cdrom_table[] = {
+static const struct ctl_table cdrom_table[] = {
 	{
 		.procname	= "info",
 		.data		= &cdrom_sysctl_settings.info, 
diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c
index 48fe96ab4649..e110857824fc 100644
--- a/drivers/char/hpet.c
+++ b/drivers/char/hpet.c
@@ -724,7 +724,7 @@ static int hpet_is_known(struct hpet_data *hdp)
 	return 0;
 }
 
-static struct ctl_table hpet_table[] = {
+static const struct ctl_table hpet_table[] = {
 	{
 	 .procname = "max-user-freq",
 	 .data = &hpet_max_freq,
diff --git a/drivers/char/ipmi/ipmi_poweroff.c b/drivers/char/ipmi/ipmi_poweroff.c
index 941d2dcc8c9d..de84f59468a9 100644
--- a/drivers/char/ipmi/ipmi_poweroff.c
+++ b/drivers/char/ipmi/ipmi_poweroff.c
@@ -650,7 +650,7 @@ static struct ipmi_smi_watcher smi_watcher = {
 #ifdef CONFIG_PROC_FS
 #include <linux/sysctl.h>
 
-static struct ctl_table ipmi_table[] = {
+static const struct ctl_table ipmi_table[] = {
 	{ .procname	= "poweroff_powercycle",
 	  .data		= &poweroff_powercycle,
 	  .maxlen	= sizeof(poweroff_powercycle),
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 23ee76bbb4aa..2581186fa61b 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1665,7 +1665,7 @@ static int proc_do_rointvec(const struct ctl_table *table, int write, void *buf,
 	return write ? 0 : proc_dointvec(table, 0, buf, lenp, ppos);
 }
 
-static struct ctl_table random_table[] = {
+static const struct ctl_table random_table[] = {
 	{
 		.procname	= "poolsize",
 		.data		= &sysctl_poolsize,
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 2406cda75b7b..5384d1bb4923 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -4802,7 +4802,7 @@ int i915_perf_remove_config_ioctl(struct drm_device *dev, void *data,
 	return ret;
 }
 
-static struct ctl_table oa_table[] = {
+static const struct ctl_table oa_table[] = {
 	{
 	 .procname = "perf_stream_paranoid",
 	 .data = &i915_perf_stream_paranoid,
diff --git a/drivers/gpu/drm/xe/xe_observation.c b/drivers/gpu/drm/xe/xe_observation.c
index 8ec1b84cbb9e..57cf01efc07f 100644
--- a/drivers/gpu/drm/xe/xe_observation.c
+++ b/drivers/gpu/drm/xe/xe_observation.c
@@ -56,7 +56,7 @@ int xe_observation_ioctl(struct drm_device *dev, void *data, struct drm_file *fi
 	}
 }
 
-static struct ctl_table observation_ctl_table[] = {
+static const struct ctl_table observation_ctl_table[] = {
 	{
 	 .procname = "observation_paranoid",
 	 .data = &xe_observation_paranoid,
diff --git a/drivers/hv/hv_common.c b/drivers/hv/hv_common.c
index 7a35c82976e0..9453f0c26f2a 100644
--- a/drivers/hv/hv_common.c
+++ b/drivers/hv/hv_common.c
@@ -141,7 +141,7 @@ static int sysctl_record_panic_msg = 1;
  * sysctl option to allow the user to control whether kmsg data should be
  * reported to Hyper-V on panic.
  */
-static struct ctl_table hv_ctl_table[] = {
+static const struct ctl_table hv_ctl_table[] = {
 	{
 		.procname	= "hyperv_record_panic_msg",
 		.data		= &sysctl_record_panic_msg,
diff --git a/drivers/infiniband/core/iwcm.c b/drivers/infiniband/core/iwcm.c
index 7e3a55349e10..cad8df0518d6 100644
--- a/drivers/infiniband/core/iwcm.c
+++ b/drivers/infiniband/core/iwcm.c
@@ -103,7 +103,7 @@ struct iwcm_work {
 static unsigned int default_backlog = 256;
 
 static struct ctl_table_header *iwcm_ctl_table_hdr;
-static struct ctl_table iwcm_ctl_table[] = {
+static const struct ctl_table iwcm_ctl_table[] = {
 	{
 		.procname	= "default_backlog",
 		.data		= &default_backlog,
diff --git a/drivers/infiniband/core/ucma.c b/drivers/infiniband/core/ucma.c
index 02f1666f3cba..65bcc9475a6e 100644
--- a/drivers/infiniband/core/ucma.c
+++ b/drivers/infiniband/core/ucma.c
@@ -63,7 +63,7 @@ MODULE_LICENSE("Dual BSD/GPL");
 static unsigned int max_backlog = 1024;
 
 static struct ctl_table_header *ucma_ctl_table_hdr;
-static struct ctl_table ucma_ctl_table[] = {
+static const struct ctl_table ucma_ctl_table[] = {
 	{
 		.procname	= "max_backlog",
 		.data		= &max_backlog,
diff --git a/drivers/macintosh/mac_hid.c b/drivers/macintosh/mac_hid.c
index b461b1bed25b..369d72f59b3c 100644
--- a/drivers/macintosh/mac_hid.c
+++ b/drivers/macintosh/mac_hid.c
@@ -215,7 +215,7 @@ static int mac_hid_toggle_emumouse(const struct ctl_table *table, int write,
 }
 
 /* file(s) in /proc/sys/dev/mac_hid */
-static struct ctl_table mac_hid_files[] = {
+static const struct ctl_table mac_hid_files[] = {
 	{
 		.procname	= "mouse_button_emulation",
 		.data		= &mouse_emulate_buttons,
diff --git a/drivers/md/md.c b/drivers/md/md.c
index aebe12b0ee27..0e06f9027d81 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -294,7 +294,7 @@ void mddev_destroy_serial_pool(struct mddev *mddev, struct md_rdev *rdev)
 
 static struct ctl_table_header *raid_table_header;
 
-static struct ctl_table raid_table[] = {
+static const struct ctl_table raid_table[] = {
 	{
 		.procname	= "speed_limit_min",
 		.data		= &sysctl_speed_limit_min,
diff --git a/drivers/misc/sgi-xp/xpc_main.c b/drivers/misc/sgi-xp/xpc_main.c
index 61b66e318488..7a3c34306de9 100644
--- a/drivers/misc/sgi-xp/xpc_main.c
+++ b/drivers/misc/sgi-xp/xpc_main.c
@@ -93,7 +93,7 @@ int xpc_disengage_timelimit = XPC_DISENGAGE_DEFAULT_TIMELIMIT;
 static int xpc_disengage_min_timelimit;	/* = 0 */
 static int xpc_disengage_max_timelimit = 120;
 
-static struct ctl_table xpc_sys_xpc_hb[] = {
+static const struct ctl_table xpc_sys_xpc_hb[] = {
 	{
 	 .procname = "hb_interval",
 	 .data = &xpc_hb_interval,
@@ -111,7 +111,7 @@ static struct ctl_table xpc_sys_xpc_hb[] = {
 	 .extra1 = &xpc_hb_check_min_interval,
 	 .extra2 = &xpc_hb_check_max_interval},
 };
-static struct ctl_table xpc_sys_xpc[] = {
+static const struct ctl_table xpc_sys_xpc[] = {
 	{
 	 .procname = "disengage_timelimit",
 	 .data = &xpc_disengage_timelimit,
diff --git a/drivers/perf/arm_pmuv3.c b/drivers/perf/arm_pmuv3.c
index b5cc11abc962..0e360feb3432 100644
--- a/drivers/perf/arm_pmuv3.c
+++ b/drivers/perf/arm_pmuv3.c
@@ -1279,7 +1279,7 @@ static int armv8pmu_proc_user_access_handler(const struct ctl_table *table, int
 	return 0;
 }
 
-static struct ctl_table armv8_pmu_sysctl_table[] = {
+static const struct ctl_table armv8_pmu_sysctl_table[] = {
 	{
 		.procname       = "perf_user_access",
 		.data		= &sysctl_perf_user_access,
diff --git a/drivers/perf/riscv_pmu_sbi.c b/drivers/perf/riscv_pmu_sbi.c
index 1aa303f76cc7..ea96c0a88f73 100644
--- a/drivers/perf/riscv_pmu_sbi.c
+++ b/drivers/perf/riscv_pmu_sbi.c
@@ -1315,7 +1315,7 @@ static int riscv_pmu_proc_user_access_handler(const struct ctl_table *table,
 	return 0;
 }
 
-static struct ctl_table sbi_pmu_sysctl_table[] = {
+static const struct ctl_table sbi_pmu_sysctl_table[] = {
 	{
 		.procname       = "perf_user_access",
 		.data		= &sysctl_perf_user_access,
diff --git a/drivers/scsi/scsi_sysctl.c b/drivers/scsi/scsi_sysctl.c
index 093774d77534..be4aef0f4f99 100644
--- a/drivers/scsi/scsi_sysctl.c
+++ b/drivers/scsi/scsi_sysctl.c
@@ -12,7 +12,7 @@
 #include "scsi_priv.h"
 
 
-static struct ctl_table scsi_table[] = {
+static const struct ctl_table scsi_table[] = {
 	{ .procname	= "logging_level",
 	  .data		= &scsi_logging_level,
 	  .maxlen	= sizeof(scsi_logging_level),
diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index 94127868bedf..effb7e768165 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -1639,7 +1639,7 @@ MODULE_PARM_DESC(allow_dio, "allow direct I/O (default: 0 (disallow))");
 #ifdef CONFIG_SYSCTL
 #include <linux/sysctl.h>
 
-static struct ctl_table sg_sysctls[] = {
+static const struct ctl_table sg_sysctls[] = {
 	{
 		.procname	= "sg-big-buff",
 		.data		= &sg_big_buff,
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index dcb1769c3625..0e84677712b4 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -3618,7 +3618,7 @@ void console_sysfs_notify(void)
 		sysfs_notify(&consdev->kobj, NULL, "active");
 }
 
-static struct ctl_table tty_table[] = {
+static const struct ctl_table tty_table[] = {
 	{
 		.procname	= "legacy_tiocsti",
 		.data		= &tty_legacy_tiocsti,
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 528395133b4f..163f7f1d70f1 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -84,7 +84,7 @@ module_param(balloon_boot_timeout, uint, 0444);
 #ifdef CONFIG_XEN_BALLOON_MEMORY_HOTPLUG
 static int xen_hotplug_unpopulated;
 
-static struct ctl_table balloon_table[] = {
+static const struct ctl_table balloon_table[] = {
 	{
 		.procname	= "hotplug_unpopulated",
 		.data		= &xen_hotplug_unpopulated,
diff --git a/fs/aio.c b/fs/aio.c
index 50671640b588..7b976b564cfc 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -224,7 +224,7 @@ static unsigned long aio_nr;		/* current system wide number of aio requests */
 static unsigned long aio_max_nr = 0x10000; /* system wide maximum number of aio requests */
 /*----end sysctl variables---*/
 #ifdef CONFIG_SYSCTL
-static struct ctl_table aio_sysctls[] = {
+static const struct ctl_table aio_sysctls[] = {
 	{
 		.procname	= "aio-nr",
 		.data		= &aio_nr,
diff --git a/fs/cachefiles/error_inject.c b/fs/cachefiles/error_inject.c
index 1715d5ca2b2d..e341ade47dd8 100644
--- a/fs/cachefiles/error_inject.c
+++ b/fs/cachefiles/error_inject.c
@@ -11,7 +11,7 @@
 unsigned int cachefiles_error_injection_state;
 
 static struct ctl_table_header *cachefiles_sysctl;
-static struct ctl_table cachefiles_sysctls[] = {
+static const struct ctl_table cachefiles_sysctls[] = {
 	{
 		.procname	= "error_injection",
 		.data		= &cachefiles_error_injection_state,
diff --git a/fs/coda/sysctl.c b/fs/coda/sysctl.c
index 9f2d5743e2c8..0df46f09b6cc 100644
--- a/fs/coda/sysctl.c
+++ b/fs/coda/sysctl.c
@@ -14,7 +14,7 @@
 
 static struct ctl_table_header *fs_table_header;
 
-static struct ctl_table coda_table[] = {
+static const struct ctl_table coda_table[] = {
 	{
 		.procname	= "timeout",
 		.data		= &coda_timeout,
diff --git a/fs/coredump.c b/fs/coredump.c
index d48edb37bc35..591700e1b2ce 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -995,7 +995,7 @@ static int proc_dostring_coredump(const struct ctl_table *table, int write,
 static const unsigned int core_file_note_size_min = CORE_FILE_NOTE_SIZE_DEFAULT;
 static const unsigned int core_file_note_size_max = CORE_FILE_NOTE_SIZE_MAX;
 
-static struct ctl_table coredump_sysctls[] = {
+static const struct ctl_table coredump_sysctls[] = {
 	{
 		.procname	= "core_uses_pid",
 		.data		= &core_uses_pid,
diff --git a/fs/dcache.c b/fs/dcache.c
index b4d5e9e1e43d..370302d4e488 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -192,7 +192,7 @@ static int proc_nr_dentry(const struct ctl_table *table, int write, void *buffer
 	return proc_doulongvec_minmax(table, write, buffer, lenp, ppos);
 }
 
-static struct ctl_table fs_dcache_sysctls[] = {
+static const struct ctl_table fs_dcache_sysctls[] = {
 	{
 		.procname	= "dentry-state",
 		.data		= &dentry_stat,
diff --git a/fs/devpts/inode.c b/fs/devpts/inode.c
index b20e565b9c5e..1096ff8562fa 100644
--- a/fs/devpts/inode.c
+++ b/fs/devpts/inode.c
@@ -45,7 +45,7 @@ static int pty_limit_min;
 static int pty_limit_max = INT_MAX;
 static atomic_t pty_count = ATOMIC_INIT(0);
 
-static struct ctl_table pty_table[] = {
+static const struct ctl_table pty_table[] = {
 	{
 		.procname	= "max",
 		.maxlen		= sizeof(int),
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index f9898e60dd8b..7c0980db77b3 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -318,7 +318,7 @@ static void unlist_file(struct epitems_head *head)
 static long long_zero;
 static long long_max = LONG_MAX;
 
-static struct ctl_table epoll_table[] = {
+static const struct ctl_table epoll_table[] = {
 	{
 		.procname	= "max_user_watches",
 		.data		= &max_user_watches,
diff --git a/fs/exec.c b/fs/exec.c
index 98cb7ba9983c..96229a6a4dff 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -2142,7 +2142,7 @@ static int proc_dointvec_minmax_coredump(const struct ctl_table *table, int writ
 	return error;
 }
 
-static struct ctl_table fs_exec_sysctls[] = {
+static const struct ctl_table fs_exec_sysctls[] = {
 	{
 		.procname	= "suid_dumpable",
 		.data		= &suid_dumpable,
diff --git a/fs/file_table.c b/fs/file_table.c
index 976736be47cb..70ed0b3a5a0e 100644
--- a/fs/file_table.c
+++ b/fs/file_table.c
@@ -106,7 +106,7 @@ static int proc_nr_files(const struct ctl_table *table, int write, void *buffer,
 	return proc_doulongvec_minmax(table, write, buffer, lenp, ppos);
 }
 
-static struct ctl_table fs_stat_sysctls[] = {
+static const struct ctl_table fs_stat_sysctls[] = {
 	{
 		.procname	= "file-nr",
 		.data		= &files_stat,
diff --git a/fs/fuse/sysctl.c b/fs/fuse/sysctl.c
index b272bb333005..63fb1e5bee30 100644
--- a/fs/fuse/sysctl.c
+++ b/fs/fuse/sysctl.c
@@ -13,7 +13,7 @@ static struct ctl_table_header *fuse_table_header;
 /* Bound by fuse_init_out max_pages, which is a u16 */
 static unsigned int sysctl_fuse_max_pages_limit = 65535;
 
-static struct ctl_table fuse_sysctl_table[] = {
+static const struct ctl_table fuse_sysctl_table[] = {
 	{
 		.procname	= "max_pages_limit",
 		.data		= &fuse_max_pages_limit,
diff --git a/fs/inode.c b/fs/inode.c
index 6b4c77268fc0..5587aabdaa5e 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -184,7 +184,7 @@ static int proc_nr_inodes(const struct ctl_table *table, int write, void *buffer
 	return proc_doulongvec_minmax(table, write, buffer, lenp, ppos);
 }
 
-static struct ctl_table inodes_sysctls[] = {
+static const struct ctl_table inodes_sysctls[] = {
 	{
 		.procname	= "inode-nr",
 		.data		= &inodes_stat,
diff --git a/fs/lockd/svc.c b/fs/lockd/svc.c
index 4ec22c2f2ea3..d6cac1c89c2a 100644
--- a/fs/lockd/svc.c
+++ b/fs/lockd/svc.c
@@ -419,7 +419,7 @@ EXPORT_SYMBOL_GPL(lockd_down);
  * Sysctl parameters (same as module parameters, different interface).
  */
 
-static struct ctl_table nlm_sysctls[] = {
+static const struct ctl_table nlm_sysctls[] = {
 	{
 		.procname	= "nlm_grace_period",
 		.data		= &nlm_grace_period,
diff --git a/fs/locks.c b/fs/locks.c
index 25afc8d9c9d1..1619cddfa7a4 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -97,7 +97,7 @@ static int leases_enable = 1;
 static int lease_break_time = 45;
 
 #ifdef CONFIG_SYSCTL
-static struct ctl_table locks_sysctls[] = {
+static const struct ctl_table locks_sysctls[] = {
 	{
 		.procname	= "leases-enable",
 		.data		= &leases_enable,
diff --git a/fs/namei.c b/fs/namei.c
index 9d30c7aa9aa6..6a18b2ea21b7 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1099,7 +1099,7 @@ static int sysctl_protected_fifos __read_mostly;
 static int sysctl_protected_regular __read_mostly;
 
 #ifdef CONFIG_SYSCTL
-static struct ctl_table namei_sysctls[] = {
+static const struct ctl_table namei_sysctls[] = {
 	{
 		.procname	= "protected_symlinks",
 		.data		= &sysctl_protected_symlinks,
diff --git a/fs/namespace.c b/fs/namespace.c
index 23e81c2a1e3f..3819c322244e 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -5927,7 +5927,7 @@ const struct proc_ns_operations mntns_operations = {
 };
 
 #ifdef CONFIG_SYSCTL
-static struct ctl_table fs_namespace_sysctls[] = {
+static const struct ctl_table fs_namespace_sysctls[] = {
 	{
 		.procname	= "mount-max",
 		.data		= &sysctl_mount_max,
diff --git a/fs/nfs/nfs4sysctl.c b/fs/nfs/nfs4sysctl.c
index 886a7c4c60b3..d1a92d8f8ba4 100644
--- a/fs/nfs/nfs4sysctl.c
+++ b/fs/nfs/nfs4sysctl.c
@@ -17,7 +17,7 @@ static const int nfs_set_port_min;
 static const int nfs_set_port_max = 65535;
 static struct ctl_table_header *nfs4_callback_sysctl_table;
 
-static struct ctl_table nfs4_cb_sysctls[] = {
+static const struct ctl_table nfs4_cb_sysctls[] = {
 	{
 		.procname = "nfs_callback_tcpport",
 		.data = &nfs_callback_set_tcpport,
diff --git a/fs/nfs/sysctl.c b/fs/nfs/sysctl.c
index e645be1a3381..f579df0e8d67 100644
--- a/fs/nfs/sysctl.c
+++ b/fs/nfs/sysctl.c
@@ -14,7 +14,7 @@
 
 static struct ctl_table_header *nfs_callback_sysctl_table;
 
-static struct ctl_table nfs_cb_sysctls[] = {
+static const struct ctl_table nfs_cb_sysctls[] = {
 	{
 		.procname	= "nfs_mountpoint_timeout",
 		.data		= &nfs_mountpoint_expiry_timeout,
diff --git a/fs/notify/dnotify/dnotify.c b/fs/notify/dnotify/dnotify.c
index 6004dfdfdf0f..c4cdaf5fa7ed 100644
--- a/fs/notify/dnotify/dnotify.c
+++ b/fs/notify/dnotify/dnotify.c
@@ -20,7 +20,7 @@
 
 static int dir_notify_enable __read_mostly = 1;
 #ifdef CONFIG_SYSCTL
-static struct ctl_table dnotify_sysctls[] = {
+static const struct ctl_table dnotify_sysctls[] = {
 	{
 		.procname	= "dir-notify-enable",
 		.data		= &dir_notify_enable,
diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c
index 2d85c71717d6..004cfdae1316 100644
--- a/fs/notify/fanotify/fanotify_user.c
+++ b/fs/notify/fanotify/fanotify_user.c
@@ -58,7 +58,7 @@ static int fanotify_max_queued_events __read_mostly;
 static long ft_zero = 0;
 static long ft_int_max = INT_MAX;
 
-static struct ctl_table fanotify_table[] = {
+static const struct ctl_table fanotify_table[] = {
 	{
 		.procname	= "max_user_groups",
 		.data	= &init_user_ns.ucount_max[UCOUNT_FANOTIFY_GROUPS],
diff --git a/fs/notify/inotify/inotify_user.c b/fs/notify/inotify/inotify_user.c
index e0c48956608a..b372fb2c56bd 100644
--- a/fs/notify/inotify/inotify_user.c
+++ b/fs/notify/inotify/inotify_user.c
@@ -58,7 +58,7 @@ struct kmem_cache *inotify_inode_mark_cachep __ro_after_init;
 static long it_zero = 0;
 static long it_int_max = INT_MAX;
 
-static struct ctl_table inotify_table[] = {
+static const struct ctl_table inotify_table[] = {
 	{
 		.procname	= "max_user_instances",
 		.data		= &init_user_ns.ucount_max[UCOUNT_INOTIFY_INSTANCES],
diff --git a/fs/ocfs2/stackglue.c b/fs/ocfs2/stackglue.c
index 20aa37b67cfb..ddd761cf44c8 100644
--- a/fs/ocfs2/stackglue.c
+++ b/fs/ocfs2/stackglue.c
@@ -650,7 +650,7 @@ static int ocfs2_sysfs_init(void)
  * and easier to preserve the name.
  */
 
-static struct ctl_table ocfs2_nm_table[] = {
+static const struct ctl_table ocfs2_nm_table[] = {
 	{
 		.procname	= "hb_ctl_path",
 		.data		= ocfs2_hb_ctl_path,
diff --git a/fs/pipe.c b/fs/pipe.c
index 12b22c2723b7..638fb318e7be 100644
--- a/fs/pipe.c
+++ b/fs/pipe.c
@@ -1477,7 +1477,7 @@ static int proc_dopipe_max_size(const struct ctl_table *table, int write,
 				 do_proc_dopipe_max_size_conv, NULL);
 }
 
-static struct ctl_table fs_pipe_sysctls[] = {
+static const struct ctl_table fs_pipe_sysctls[] = {
 	{
 		.procname	= "pipe-max-size",
 		.data		= &pipe_max_size,
diff --git a/fs/quota/dquot.c b/fs/quota/dquot.c
index f9578918cfb2..825c5c2e0962 100644
--- a/fs/quota/dquot.c
+++ b/fs/quota/dquot.c
@@ -2926,7 +2926,7 @@ static int do_proc_dqstats(const struct ctl_table *table, int write,
 	return proc_doulongvec_minmax(table, write, buffer, lenp, ppos);
 }
 
-static struct ctl_table fs_dqstats_table[] = {
+static const struct ctl_table fs_dqstats_table[] = {
 	{
 		.procname	= "lookups",
 		.data		= &dqstats.stat[DQST_LOOKUPS],
diff --git a/fs/sysctls.c b/fs/sysctls.c
index 8dbde9a802fa..ad429dffeb4b 100644
--- a/fs/sysctls.c
+++ b/fs/sysctls.c
@@ -7,7 +7,7 @@
 #include <linux/init.h>
 #include <linux/sysctl.h>
 
-static struct ctl_table fs_shared_sysctls[] = {
+static const struct ctl_table fs_shared_sysctls[] = {
 	{
 		.procname	= "overflowuid",
 		.data		= &fs_overflowuid,
diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
index 7c0bd0b55f88..97c4d71115d8 100644
--- a/fs/userfaultfd.c
+++ b/fs/userfaultfd.c
@@ -36,7 +36,7 @@
 static int sysctl_unprivileged_userfaultfd __read_mostly;
 
 #ifdef CONFIG_SYSCTL
-static struct ctl_table vm_userfaultfd_table[] = {
+static const struct ctl_table vm_userfaultfd_table[] = {
 	{
 		.procname	= "unprivileged_userfaultfd",
 		.data		= &sysctl_unprivileged_userfaultfd,
diff --git a/fs/verity/init.c b/fs/verity/init.c
index f440f0e61e3e..6e8d33b50240 100644
--- a/fs/verity/init.c
+++ b/fs/verity/init.c
@@ -10,7 +10,7 @@
 #include <linux/ratelimit.h>
 
 #ifdef CONFIG_SYSCTL
-static struct ctl_table fsverity_sysctl_table[] = {
+static const struct ctl_table fsverity_sysctl_table[] = {
 #ifdef CONFIG_FS_VERITY_BUILTIN_SIGNATURES
 	{
 		.procname       = "require_signatures",
diff --git a/fs/xfs/xfs_sysctl.c b/fs/xfs/xfs_sysctl.c
index c84df23b494d..751dc74a3067 100644
--- a/fs/xfs/xfs_sysctl.c
+++ b/fs/xfs/xfs_sysctl.c
@@ -66,7 +66,7 @@ xfs_deprecated_dointvec_minmax(
 	return proc_dointvec_minmax(ctl, write, buffer, lenp, ppos);
 }
 
-static struct ctl_table xfs_table[] = {
+static const struct ctl_table xfs_table[] = {
 	{
 		.procname	= "irix_sgid_inherit",
 		.data		= &xfs_params.sgid_inherit.val,
diff --git a/init/do_mounts_initrd.c b/init/do_mounts_initrd.c
index 22c7f41ff642..903b4d573d3d 100644
--- a/init/do_mounts_initrd.c
+++ b/init/do_mounts_initrd.c
@@ -21,7 +21,7 @@ phys_addr_t phys_initrd_start __initdata;
 unsigned long phys_initrd_size __initdata;
 
 #ifdef CONFIG_SYSCTL
-static struct ctl_table kern_do_mounts_initrd_table[] = {
+static const struct ctl_table kern_do_mounts_initrd_table[] = {
 	{
 		.procname       = "real-root-dev",
 		.data           = &real_root_dev,
diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c
index d3403c8216db..72ad31225fb3 100644
--- a/io_uring/io_uring.c
+++ b/io_uring/io_uring.c
@@ -156,7 +156,7 @@ static int __read_mostly sysctl_io_uring_disabled;
 static int __read_mostly sysctl_io_uring_group = -1;
 
 #ifdef CONFIG_SYSCTL
-static struct ctl_table kernel_io_uring_disabled_table[] = {
+static const struct ctl_table kernel_io_uring_disabled_table[] = {
 	{
 		.procname	= "io_uring_disabled",
 		.data		= &sysctl_io_uring_disabled,
diff --git a/ipc/ipc_sysctl.c b/ipc/ipc_sysctl.c
index 54318e0b4557..15b17e86e198 100644
--- a/ipc/ipc_sysctl.c
+++ b/ipc/ipc_sysctl.c
@@ -73,7 +73,7 @@ int ipc_mni = IPCMNI;
 int ipc_mni_shift = IPCMNI_SHIFT;
 int ipc_min_cycle = RADIX_TREE_MAP_SIZE;
 
-static struct ctl_table ipc_sysctls[] = {
+static const struct ctl_table ipc_sysctls[] = {
 	{
 		.procname	= "shmmax",
 		.data		= &init_ipc_ns.shm_ctlmax,
diff --git a/ipc/mq_sysctl.c b/ipc/mq_sysctl.c
index b70dc2ff22d8..0dd12e1c9f53 100644
--- a/ipc/mq_sysctl.c
+++ b/ipc/mq_sysctl.c
@@ -20,7 +20,7 @@ static int msg_max_limit_max = HARD_MSGMAX;
 static int msg_maxsize_limit_min = MIN_MSGSIZEMAX;
 static int msg_maxsize_limit_max = HARD_MSGSIZEMAX;
 
-static struct ctl_table mq_sysctls[] = {
+static const struct ctl_table mq_sysctls[] = {
 	{
 		.procname	= "queues_max",
 		.data		= &init_ipc_ns.mq_queues_max,
diff --git a/kernel/acct.c b/kernel/acct.c
index 179848ad33e9..31222e8cd534 100644
--- a/kernel/acct.c
+++ b/kernel/acct.c
@@ -76,7 +76,7 @@ static int acct_parm[3] = {4, 2, 30};
 #define ACCT_TIMEOUT	(acct_parm[2])	/* foo second timeout between checks */
 
 #ifdef CONFIG_SYSCTL
-static struct ctl_table kern_acct_table[] = {
+static const struct ctl_table kern_acct_table[] = {
 	{
 		.procname       = "acct",
 		.data           = &acct_parm,
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 5684e8ce132d..fbcf07f98d8b 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -6124,7 +6124,7 @@ static int bpf_unpriv_handler(const struct ctl_table *table, int write,
 	return ret;
 }
 
-static struct ctl_table bpf_syscall_table[] = {
+static const struct ctl_table bpf_syscall_table[] = {
 	{
 		.procname	= "unprivileged_bpf_disabled",
 		.data		= &sysctl_unprivileged_bpf_disabled,
diff --git a/kernel/delayacct.c b/kernel/delayacct.c
index dead51de8eb5..75659ac036cd 100644
--- a/kernel/delayacct.c
+++ b/kernel/delayacct.c
@@ -64,7 +64,7 @@ static int sysctl_delayacct(const struct ctl_table *table, int write, void *buff
 	return err;
 }
 
-static struct ctl_table kern_delayacct_table[] = {
+static const struct ctl_table kern_delayacct_table[] = {
 	{
 		.procname       = "task_delayacct",
 		.data           = NULL,
diff --git a/kernel/exit.c b/kernel/exit.c
index 1dcddfe537ee..3485e5fc499e 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -85,7 +85,7 @@
 static unsigned int oops_limit = 10000;
 
 #ifdef CONFIG_SYSCTL
-static struct ctl_table kern_exit_table[] = {
+static const struct ctl_table kern_exit_table[] = {
 	{
 		.procname       = "oops_limit",
 		.data           = &oops_limit,
diff --git a/kernel/hung_task.c b/kernel/hung_task.c
index c18717189f32..62a5d8927ce9 100644
--- a/kernel/hung_task.c
+++ b/kernel/hung_task.c
@@ -272,7 +272,7 @@ static int proc_dohung_task_timeout_secs(const struct ctl_table *table, int writ
  * and hung_task_check_interval_secs
  */
 static const unsigned long hung_task_timeout_max = (LONG_MAX / HZ);
-static struct ctl_table hung_task_sysctls[] = {
+static const struct ctl_table hung_task_sysctls[] = {
 #ifdef CONFIG_SMP
 	{
 		.procname	= "hung_task_all_cpu_backtrace",
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index c0caa14880c3..71b0809e06d6 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -925,7 +925,7 @@ static int kexec_limit_handler(const struct ctl_table *table, int write,
 	return proc_dointvec(&tmp, write, buffer, lenp, ppos);
 }
 
-static struct ctl_table kexec_core_sysctls[] = {
+static const struct ctl_table kexec_core_sysctls[] = {
 	{
 		.procname	= "kexec_load_disabled",
 		.data		= &kexec_load_disabled,
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index b027a4030976..9a15fb343be8 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -954,7 +954,7 @@ static int proc_kprobes_optimization_handler(const struct ctl_table *table,
 	return ret;
 }
 
-static struct ctl_table kprobe_sysctls[] = {
+static const struct ctl_table kprobe_sysctls[] = {
 	{
 		.procname	= "kprobes-optimization",
 		.data		= &sysctl_kprobes_optimization,
diff --git a/kernel/latencytop.c b/kernel/latencytop.c
index 7a75eab9c179..39a5fcdff9f9 100644
--- a/kernel/latencytop.c
+++ b/kernel/latencytop.c
@@ -77,7 +77,7 @@ static int sysctl_latencytop(const struct ctl_table *table, int write, void *buf
 	return err;
 }
 
-static struct ctl_table latencytop_sysctl[] = {
+static const struct ctl_table latencytop_sysctl[] = {
 	{
 		.procname   = "latencytop",
 		.data       = &latencytop_enabled,
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 2d8ec0351ef9..926b796ba71a 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -79,7 +79,7 @@ module_param(lock_stat, int, 0644);
 #endif
 
 #ifdef CONFIG_SYSCTL
-static struct ctl_table kern_lockdep_table[] = {
+static const struct ctl_table kern_lockdep_table[] = {
 #ifdef CONFIG_PROVE_LOCKING
 	{
 		.procname       = "prove_locking",
diff --git a/kernel/panic.c b/kernel/panic.c
index fbc59b3b64d0..d8635d5cecb2 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -84,7 +84,7 @@ ATOMIC_NOTIFIER_HEAD(panic_notifier_list);
 EXPORT_SYMBOL(panic_notifier_list);
 
 #ifdef CONFIG_SYSCTL
-static struct ctl_table kern_panic_table[] = {
+static const struct ctl_table kern_panic_table[] = {
 #ifdef CONFIG_SMP
 	{
 		.procname       = "oops_all_cpu_backtrace",
diff --git a/kernel/pid_namespace.c b/kernel/pid_namespace.c
index d70ab49d5b4a..0f23285be4f9 100644
--- a/kernel/pid_namespace.c
+++ b/kernel/pid_namespace.c
@@ -282,7 +282,7 @@ static int pid_ns_ctl_handler(const struct ctl_table *table, int write,
 }
 
 extern int pid_max;
-static struct ctl_table pid_ns_ctl_table[] = {
+static const struct ctl_table pid_ns_ctl_table[] = {
 	{
 		.procname = "ns_last_pid",
 		.maxlen = sizeof(int),
diff --git a/kernel/pid_sysctl.h b/kernel/pid_sysctl.h
index 18ecaef6be41..5d8f981de7c5 100644
--- a/kernel/pid_sysctl.h
+++ b/kernel/pid_sysctl.h
@@ -31,7 +31,7 @@ static int pid_mfd_noexec_dointvec_minmax(const struct ctl_table *table,
 	return err;
 }
 
-static struct ctl_table pid_ns_ctl_table_vm[] = {
+static const struct ctl_table pid_ns_ctl_table_vm[] = {
 	{
 		.procname	= "memfd_noexec",
 		.data		= &init_pid_ns.memfd_noexec_scope,
diff --git a/kernel/printk/sysctl.c b/kernel/printk/sysctl.c
index f5072dc85f7a..da77f3f5c1fe 100644
--- a/kernel/printk/sysctl.c
+++ b/kernel/printk/sysctl.c
@@ -20,7 +20,7 @@ static int proc_dointvec_minmax_sysadmin(const struct ctl_table *table, int writ
 	return proc_dointvec_minmax(table, write, buffer, lenp, ppos);
 }
 
-static struct ctl_table printk_sysctls[] = {
+static const struct ctl_table printk_sysctls[] = {
 	{
 		.procname	= "printk",
 		.data		= &console_loglevel,
diff --git a/kernel/reboot.c b/kernel/reboot.c
index a701000bab34..b5a8569e5d81 100644
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -1287,7 +1287,7 @@ static struct attribute *reboot_attrs[] = {
 };
 
 #ifdef CONFIG_SYSCTL
-static struct ctl_table kern_reboot_table[] = {
+static const struct ctl_table kern_reboot_table[] = {
 	{
 		.procname       = "poweroff_cmd",
 		.data           = &poweroff_cmd,
diff --git a/kernel/sched/autogroup.c b/kernel/sched/autogroup.c
index db68a964e34e..83d46b9b8ec8 100644
--- a/kernel/sched/autogroup.c
+++ b/kernel/sched/autogroup.c
@@ -9,7 +9,7 @@ static struct autogroup autogroup_default;
 static atomic_t autogroup_seq_nr;
 
 #ifdef CONFIG_SYSCTL
-static struct ctl_table sched_autogroup_sysctls[] = {
+static const struct ctl_table sched_autogroup_sysctls[] = {
 	{
 		.procname       = "sched_autogroup_enabled",
 		.data           = &sysctl_sched_autogroup_enabled,
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 3e5a6bf587f9..00fea6f32ae5 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -4646,7 +4646,7 @@ static int sysctl_schedstats(const struct ctl_table *table, int write, void *buf
 #endif /* CONFIG_SCHEDSTATS */
 
 #ifdef CONFIG_SYSCTL
-static struct ctl_table sched_core_sysctls[] = {
+static const struct ctl_table sched_core_sysctls[] = {
 #ifdef CONFIG_SCHEDSTATS
 	{
 		.procname       = "sched_schedstats",
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index d94f2ed6d1f4..dab4887d6406 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -26,7 +26,7 @@
 static unsigned int sysctl_sched_dl_period_max = 1 << 22; /* ~4 seconds */
 static unsigned int sysctl_sched_dl_period_min = 100;     /* 100 us */
 #ifdef CONFIG_SYSCTL
-static struct ctl_table sched_dl_sysctls[] = {
+static const struct ctl_table sched_dl_sysctls[] = {
 	{
 		.procname       = "sched_deadline_period_max_us",
 		.data           = &sysctl_sched_dl_period_max,
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 3e9ca38512de..1692dbb67d7a 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -130,7 +130,7 @@ static unsigned int sysctl_numa_balancing_promote_rate_limit = 65536;
 #endif
 
 #ifdef CONFIG_SYSCTL
-static struct ctl_table sched_fair_sysctls[] = {
+static const struct ctl_table sched_fair_sysctls[] = {
 #ifdef CONFIG_CFS_BANDWIDTH
 	{
 		.procname       = "sched_cfs_bandwidth_slice_us",
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index bd66a46b06ac..4b8e33c615b1 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -26,7 +26,7 @@ static int sched_rt_handler(const struct ctl_table *table, int write, void *buff
 		size_t *lenp, loff_t *ppos);
 static int sched_rr_handler(const struct ctl_table *table, int write, void *buffer,
 		size_t *lenp, loff_t *ppos);
-static struct ctl_table sched_rt_sysctls[] = {
+static const struct ctl_table sched_rt_sysctls[] = {
 	{
 		.procname       = "sched_rt_period_us",
 		.data           = &sysctl_sched_rt_period,
diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
index 9748a4c8d668..20d59b0bc928 100644
--- a/kernel/sched/topology.c
+++ b/kernel/sched/topology.c
@@ -312,7 +312,7 @@ static int sched_energy_aware_handler(const struct ctl_table *table, int write,
 	return ret;
 }
 
-static struct ctl_table sched_energy_aware_sysctls[] = {
+static const struct ctl_table sched_energy_aware_sysctls[] = {
 	{
 		.procname       = "sched_energy_aware",
 		.data           = &sysctl_sched_energy_aware,
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index 385d48293a5f..f59381c4a2ff 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -2450,7 +2450,7 @@ static int seccomp_actions_logged_handler(const struct ctl_table *ro_table, int
 	return ret;
 }
 
-static struct ctl_table seccomp_sysctl_table[] = {
+static const struct ctl_table seccomp_sysctl_table[] = {
 	{
 		.procname	= "actions_avail",
 		.data		= (void *) &seccomp_actions_avail,
diff --git a/kernel/signal.c b/kernel/signal.c
index 989b1cc9116a..77f32c2d6ccb 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -4931,7 +4931,7 @@ static inline void siginfo_buildtime_checks(void)
 }
 
 #if defined(CONFIG_SYSCTL)
-static struct ctl_table signal_debug_table[] = {
+static const struct ctl_table signal_debug_table[] = {
 #ifdef CONFIG_SYSCTL_EXCEPTION_TRACE
 	{
 		.procname	= "exception-trace",
diff --git a/kernel/stackleak.c b/kernel/stackleak.c
index 39fd620a7db6..c1bfc14cd36e 100644
--- a/kernel/stackleak.c
+++ b/kernel/stackleak.c
@@ -44,7 +44,7 @@ static int stack_erasing_sysctl(const struct ctl_table *table, int write,
 					state ? "enabled" : "disabled");
 	return ret;
 }
-static struct ctl_table stackleak_sysctls[] = {
+static const struct ctl_table stackleak_sysctls[] = {
 	{
 		.procname	= "stack_erasing",
 		.data		= NULL,
diff --git a/kernel/sysctl-test.c b/kernel/sysctl-test.c
index 3ac98bb7fb82..eb2842bd0557 100644
--- a/kernel/sysctl-test.c
+++ b/kernel/sysctl-test.c
@@ -374,7 +374,7 @@ static void sysctl_test_register_sysctl_sz_invalid_extra_value(
 		struct kunit *test)
 {
 	unsigned char data = 0;
-	struct ctl_table table_foo[] = {
+	const struct ctl_table table_foo[] = {
 		{
 			.procname	= "foo",
 			.data		= &data,
@@ -386,7 +386,7 @@ static void sysctl_test_register_sysctl_sz_invalid_extra_value(
 		},
 	};
 
-	struct ctl_table table_bar[] = {
+	const struct ctl_table table_bar[] = {
 		{
 			.procname	= "bar",
 			.data		= &data,
@@ -398,7 +398,7 @@ static void sysctl_test_register_sysctl_sz_invalid_extra_value(
 		},
 	};
 
-	struct ctl_table table_qux[] = {
+	const struct ctl_table table_qux[] = {
 		{
 			.procname	= "qux",
 			.data		= &data,
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 5c9202cb8f59..3a0132cb0d5d 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1609,7 +1609,7 @@ int proc_do_static_key(const struct ctl_table *table, int write,
 	return ret;
 }
 
-static struct ctl_table kern_table[] = {
+static const struct ctl_table kern_table[] = {
 	{
 		.procname	= "panic",
 		.data		= &panic_timeout,
@@ -2030,7 +2030,7 @@ static struct ctl_table kern_table[] = {
 #endif
 };
 
-static struct ctl_table vm_table[] = {
+static const struct ctl_table vm_table[] = {
 	{
 		.procname	= "overcommit_memory",
 		.data		= &sysctl_overcommit_memory,
diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index a5860bf6d16f..79a1f83d2944 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -301,7 +301,7 @@ static int timer_migration_handler(const struct ctl_table *table, int write,
 	return ret;
 }
 
-static struct ctl_table timer_sysctl[] = {
+static const struct ctl_table timer_sysctl[] = {
 	{
 		.procname	= "timer_migration",
 		.data		= &sysctl_timer_migration,
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 2e113f8b13a2..489cbab3d64c 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -8786,7 +8786,7 @@ ftrace_enable_sysctl(const struct ctl_table *table, int write,
 	return ret;
 }
 
-static struct ctl_table ftrace_sysctls[] = {
+static const struct ctl_table ftrace_sysctls[] = {
 	{
 		.procname       = "ftrace_enabled",
 		.data           = &ftrace_enabled,
diff --git a/kernel/trace/trace_events_user.c b/kernel/trace/trace_events_user.c
index 17bcad8f79de..97325fbd6283 100644
--- a/kernel/trace/trace_events_user.c
+++ b/kernel/trace/trace_events_user.c
@@ -2899,7 +2899,7 @@ static int set_max_user_events_sysctl(const struct ctl_table *table, int write,
 	return ret;
 }
 
-static struct ctl_table user_event_sysctls[] = {
+static const struct ctl_table user_event_sysctls[] = {
 	{
 		.procname	= "user_events_max",
 		.data		= &max_user_events,
diff --git a/kernel/umh.c b/kernel/umh.c
index be9234270777..b4da45a3a7cf 100644
--- a/kernel/umh.c
+++ b/kernel/umh.c
@@ -544,7 +544,7 @@ static int proc_cap_handler(const struct ctl_table *table, int write,
 	return 0;
 }
 
-static struct ctl_table usermodehelper_table[] = {
+static const struct ctl_table usermodehelper_table[] = {
 	{
 		.procname	= "bset",
 		.data		= &usermodehelper_bset,
diff --git a/kernel/utsname_sysctl.c b/kernel/utsname_sysctl.c
index 7282f61a8650..bfbaaecb1dd4 100644
--- a/kernel/utsname_sysctl.c
+++ b/kernel/utsname_sysctl.c
@@ -75,7 +75,7 @@ static DEFINE_CTL_TABLE_POLL(hostname_poll);
 static DEFINE_CTL_TABLE_POLL(domainname_poll);
 
 // Note: update 'enum uts_proc' to match any changes to this table
-static struct ctl_table uts_kern_table[] = {
+static const struct ctl_table uts_kern_table[] = {
 	{
 		.procname	= "arch",
 		.data		= init_uts_ns.name.machine,
@@ -129,7 +129,7 @@ static struct ctl_table uts_kern_table[] = {
  */
 void uts_proc_notify(enum uts_proc proc)
 {
-	struct ctl_table *table = &uts_kern_table[proc];
+	const struct ctl_table *table = &uts_kern_table[proc];
 
 	proc_sys_poll_notify(table->poll);
 }
diff --git a/kernel/watchdog.c b/kernel/watchdog.c
index 41e0f7e9fa35..04e27fed20cb 100644
--- a/kernel/watchdog.c
+++ b/kernel/watchdog.c
@@ -1094,7 +1094,7 @@ static int proc_watchdog_cpumask(const struct ctl_table *table, int write,
 
 static const int sixty = 60;
 
-static struct ctl_table watchdog_sysctls[] = {
+static const struct ctl_table watchdog_sysctls[] = {
 	{
 		.procname       = "watchdog",
 		.data		= &watchdog_user_enabled,
@@ -1175,7 +1175,7 @@ static struct ctl_table watchdog_sysctls[] = {
 #endif
 };
 
-static struct ctl_table watchdog_hardlockup_sysctl[] = {
+static const struct ctl_table watchdog_hardlockup_sysctl[] = {
 	{
 		.procname       = "nmi_watchdog",
 		.data		= &watchdog_hardlockup_user_enabled,
diff --git a/lib/alloc_tag.c b/lib/alloc_tag.c
index 7dcebf118a3e..73fda8406350 100644
--- a/lib/alloc_tag.c
+++ b/lib/alloc_tag.c
@@ -710,7 +710,7 @@ struct page_ext_operations page_alloc_tagging_ops = {
 EXPORT_SYMBOL(page_alloc_tagging_ops);
 
 #ifdef CONFIG_SYSCTL
-static struct ctl_table memory_allocation_profiling_sysctls[] = {
+static const struct ctl_table memory_allocation_profiling_sysctls[] = {
 	{
 		.procname	= "mem_profiling",
 		.data		= &mem_alloc_profiling_key,
diff --git a/lib/test_sysctl.c b/lib/test_sysctl.c
index b6696fa1d426..4249e0cc8aaf 100644
--- a/lib/test_sysctl.c
+++ b/lib/test_sysctl.c
@@ -71,7 +71,7 @@ static struct test_sysctl_data test_data = {
 };
 
 /* These are all under /proc/sys/debug/test_sysctl/ */
-static struct ctl_table test_table[] = {
+static const struct ctl_table test_table[] = {
 	{
 		.procname	= "int_0001",
 		.data		= &test_data.int_0001,
@@ -177,7 +177,7 @@ static int test_sysctl_setup_node_tests(void)
 }
 
 /* Used to test that unregister actually removes the directory */
-static struct ctl_table test_table_unregister[] = {
+static const struct ctl_table test_table_unregister[] = {
 	{
 		.procname	= "unregister_error",
 		.data		= &test_data.int_0001,
@@ -220,7 +220,7 @@ static int test_sysctl_run_register_mount_point(void)
 	return 0;
 }
 
-static struct ctl_table test_table_empty[] = { };
+static const struct ctl_table test_table_empty[] = { };
 
 static int test_sysctl_run_register_empty(void)
 {
diff --git a/mm/compaction.c b/mm/compaction.c
index a2b16b08cbbf..62e8ee230e1c 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -3297,7 +3297,7 @@ static int proc_dointvec_minmax_warn_RT_change(const struct ctl_table *table,
 	return ret;
 }
 
-static struct ctl_table vm_compaction[] = {
+static const struct ctl_table vm_compaction[] = {
 	{
 		.procname	= "compact_memory",
 		.data		= &sysctl_compact_memory,
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index c498874a7170..3857b9d72c84 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -4845,7 +4845,7 @@ static int hugetlb_overcommit_handler(const struct ctl_table *table, int write,
 	return ret;
 }
 
-static struct ctl_table hugetlb_table[] = {
+static const struct ctl_table hugetlb_table[] = {
 	{
 		.procname	= "nr_hugepages",
 		.data		= NULL,
diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c
index 57b7f591eee8..7735972add01 100644
--- a/mm/hugetlb_vmemmap.c
+++ b/mm/hugetlb_vmemmap.c
@@ -693,7 +693,7 @@ void hugetlb_vmemmap_optimize_folios(struct hstate *h, struct list_head *folio_l
 	free_vmemmap_page_list(&vmemmap_pages);
 }
 
-static struct ctl_table hugetlb_vmemmap_sysctls[] = {
+static const struct ctl_table hugetlb_vmemmap_sysctls[] = {
 	{
 		.procname	= "hugetlb_optimize_vmemmap",
 		.data		= &vmemmap_optimize_enabled,
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index a7b8ccd29b6f..995a15eb67e2 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -124,7 +124,7 @@ const struct attribute_group memory_failure_attr_group = {
 	.attrs = memory_failure_attr,
 };
 
-static struct ctl_table memory_failure_table[] = {
+static const struct ctl_table memory_failure_table[] = {
 	{
 		.procname	= "memory_failure_early_kill",
 		.data		= &sysctl_memory_failure_early_kill,
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 1c485beb0b93..c8280a39119c 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -699,7 +699,7 @@ static void queue_oom_reaper(struct task_struct *tsk)
 }
 
 #ifdef CONFIG_SYSCTL
-static struct ctl_table vm_oom_kill_table[] = {
+static const struct ctl_table vm_oom_kill_table[] = {
 	{
 		.procname	= "panic_on_oom",
 		.data		= &sysctl_panic_on_oom,
diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index d213ead95675..fb523107701f 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -2313,7 +2313,7 @@ static int page_writeback_cpu_online(unsigned int cpu)
 /* this is needed for the proc_doulongvec_minmax of vm_dirty_bytes */
 static const unsigned long dirty_bytes_min = 2 * PAGE_SIZE;
 
-static struct ctl_table vm_page_writeback_sysctls[] = {
+static const struct ctl_table vm_page_writeback_sysctls[] = {
 	{
 		.procname   = "dirty_background_ratio",
 		.data       = &dirty_background_ratio,
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index cae7b93864c2..6224a2ab5e86 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6172,7 +6172,7 @@ static int percpu_pagelist_high_fraction_sysctl_handler(const struct ctl_table *
 	return ret;
 }
 
-static struct ctl_table page_alloc_sysctl_table[] = {
+static const struct ctl_table page_alloc_sysctl_table[] = {
 	{
 		.procname	= "min_free_kbytes",
 		.data		= &min_free_kbytes,
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index 1edc12862a7d..9b6c2f157f83 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -2038,7 +2038,7 @@ static int apparmor_dointvec(const struct ctl_table *table, int write,
 	return proc_dointvec(table, write, buffer, lenp, ppos);
 }
 
-static struct ctl_table apparmor_sysctl_table[] = {
+static const struct ctl_table apparmor_sysctl_table[] = {
 #ifdef CONFIG_USER_NS
 	{
 		.procname       = "unprivileged_userns_apparmor_policy",
diff --git a/security/keys/sysctl.c b/security/keys/sysctl.c
index 91f000eef3ad..cde08c478f32 100644
--- a/security/keys/sysctl.c
+++ b/security/keys/sysctl.c
@@ -9,7 +9,7 @@
 #include <linux/sysctl.h>
 #include "internal.h"
 
-static struct ctl_table key_sysctls[] = {
+static const struct ctl_table key_sysctls[] = {
 	{
 		.procname = "maxkeys",
 		.data = &key_quota_maxkeys,
diff --git a/security/loadpin/loadpin.c b/security/loadpin/loadpin.c
index 68252452b66c..e2d664b76026 100644
--- a/security/loadpin/loadpin.c
+++ b/security/loadpin/loadpin.c
@@ -53,7 +53,7 @@ static bool deny_reading_verity_digests;
 #endif
 
 #ifdef CONFIG_SYSCTL
-static struct ctl_table loadpin_sysctl_table[] = {
+static const struct ctl_table loadpin_sysctl_table[] = {
 	{
 		.procname       = "enforce",
 		.data           = &enforce,
diff --git a/security/yama/yama_lsm.c b/security/yama/yama_lsm.c
index e1a5e13ea269..54bd5f535ac1 100644
--- a/security/yama/yama_lsm.c
+++ b/security/yama/yama_lsm.c
@@ -454,7 +454,7 @@ static int yama_dointvec_minmax(const struct ctl_table *table, int write,
 
 static int max_scope = YAMA_SCOPE_NO_ATTACH;
 
-static struct ctl_table yama_sysctl_table[] = {
+static const struct ctl_table yama_sysctl_table[] = {
 	{
 		.procname       = "ptrace_scope",
 		.data           = &ptrace_scope,

---
base-commit: 9d89551994a430b50c4fffcb1e617a057fa76e20
change-id: 20250109-jag-ctl_table_const-38f6b2ccbba7

Best regards,
-- 
Joel Granados <joel.granados@kernel.org>




From xen-devel-bounces@lists.xenproject.org Thu Jan 09 13:23:36 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 13:23:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868382.1279898 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVsVX-0004vN-Sj; Thu, 09 Jan 2025 13:23:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868382.1279898; Thu, 09 Jan 2025 13:23:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVsVX-0004vG-OW; Thu, 09 Jan 2025 13:23:31 +0000
Received: by outflank-mailman (input) for mailman id 868382;
 Thu, 09 Jan 2025 13:23: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 <SRS0=pS5t=UB=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVsVW-0004vA-JQ
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 13:23:30 +0000
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com
 [2a00:1450:4864:20::32b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ea3dff0c-ce8c-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 14:23:29 +0100 (CET)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-4361b0ec57aso9824105e9.0
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 05:23:29 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436e9d8fc67sm21198055e9.8.2025.01.09.05.23.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 05:23:28 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ea3dff0c-ce8c-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736429009; x=1737033809; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=taMpP9uuERCru14NxrX3wyxl/dR/ZpV+1DQFQasBkZE=;
        b=hG9Xbd0CLTW9iJchSIJrRlmvm7VRguq8dKYPC5Ua5IPJ5u99vgT5jM20/wbW+Js2er
         RTxuz7F3eJfXPrzboiHIoAPJLe8kr8Q7j5mZGu8B3CS3HdEEiVB951Jl/jYIL/kbSt1J
         QAYOjNhkNAidbneWOj0L45K1xWgzO4f7Crjop37N1ii6MVIXcArM8tVUaOtiCIueTbYm
         pHBI142VQpoMIjirj8Ad5bUwbhd22AI2YHU56vIynd7e5w2JiSEsd7GiADj+E6mSqt87
         EkisDNcc8aaAEufc4Y006XOQ7p0zvLHk+bndioQETX3K9TrmBxvU99aetz/yN1t6UCW5
         uW1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736429009; x=1737033809;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=taMpP9uuERCru14NxrX3wyxl/dR/ZpV+1DQFQasBkZE=;
        b=v8xg4Zox28Zon1bl1/NhxHx7pEfmTJPvN/tNuPeKyDO/4jQ7w3A+b1FmymDLZkqm5i
         tx8gXdgtMjCE96suHpToSGEnwIN1cOxeSw88bxCMq2PnywkKMl6JP8KKm/ZWrC/oXKLm
         cxmADuSAf/LwE3U9AfL0P7uUwfitotXkr8xeju4bTFWpJNYbIFAUja1yrhOmXdydoAAG
         ydaSMRjcdSvUb2VtB0IZGxzPCor001FHBqg62f5r2F8358rNrFawUO/aIdsOtrDDILCY
         XGyOewNmK18Y1cICshI1Fq3fayTiPoNxeRuw6R5Xi954DX6oZEJmbRJlSkK4q/Fbub3i
         Lyyg==
X-Forwarded-Encrypted: i=1; AJvYcCWHjqnlEkmtaABdwSyJG15Mxf3AiZoLmAcH+Sq1s7UafJFLjBjJFbwKe5Q4Y2MrxOlyhusoWlwXuKY=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyaa8HGAK+yeAoSZ6uKsP6Amfjs0HmfpIOYaiub1ZGdAZIh9pBU
	EobBqDqBW9hKhyhnVyAH7BoQyam+c9asjOtI6VVCuo+585JTKdq3Cn5Rov8CbQ==
X-Gm-Gg: ASbGncsLIpkw3ve31vp9mQC9XuPW1IkzOdNbKRf+dE636RKJCVIGFZbQBlJKYX7k6Vx
	clZN/jXFWrFwiPhkJw8tosLEcp23XqWSotddnhWGr/fQk5TDsh0UENMC+9cvA2iQ3XfYMJCy1EG
	V3v2GT8rkPzIPynoKGy1sQlplkjupRiRvOH7yplymNOeijiimBqzND+XSFrBtBSDKyG3ormwaHd
	kurULi4yTJSH+cRUst4q7pl8uIdrwK0LvfqY6LEydutNHDdvWF2hHO+BkaVSAVoYVmIHFAGtzkc
	aRibsHFg0wWD0AB7r03lSXXjdnRUj5aQ7Xt80XjLdw==
X-Google-Smtp-Source: AGHT+IGrF77yx3oDYrFkmThxSWuOQwTF/LUkaevbwOx5t1+Ri9UVXwDBgjAJAO421EvsxfRzCy854w==
X-Received: by 2002:a05:600c:4511:b0:436:5165:f1ec with SMTP id 5b1f17b1804b1-436e271d428mr68183175e9.30.1736429008897;
        Thu, 09 Jan 2025 05:23:28 -0800 (PST)
Message-ID: <d7421558-c2d6-485b-96bf-927992c5c066@suse.com>
Date: Thu, 9 Jan 2025 14:23:27 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/boot: adjust text gap/diff to work with 64-bytes
 alignment too
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>
Cc: Frediano Ziglio <frediano.ziglio@cloud.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20250109131515.1757764-1-marmarek@invisiblethingslab.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250109131515.1757764-1-marmarek@invisiblethingslab.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 09.01.2025 14:15, Marek Marczykowski-Górecki wrote:
> Xen compiled with -mtune=generic has .text alignment set to 64-bytes.
> Having text_diff non-64-bytes-aligned breaks stuff:
> 
>     Traceback (most recent call last):
>       File "/builddir/build/BUILD/xen-4.20.0-build/xen-4.20.0-rc0/xen/./tools/combine_two_binaries.py", line 96, in <module>
>         raise Exception('File sizes do not match')
>     Exception: File sizes do not match: 70160 != 4080 + 66048
> 
> Adjust the numbers as suggested by Frediano to work with 64-bytes and
> even 128-bytes alignment.

And then breaking at 256? As indicated on Matrix, imo we should be able to
cope with anything up to at least PAGE_SIZE. Or we should reduce .text
alignment before linking.

> Suggested-by: Frediano Ziglio <frediano.ziglio@cloud.com>
> Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

No Fixes: tag?

Jan



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 13:44:26 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 13:44:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868393.1279906 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVspg-0008Gz-DD; Thu, 09 Jan 2025 13:44:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868393.1279906; Thu, 09 Jan 2025 13:44:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVspg-0008Gs-AW; Thu, 09 Jan 2025 13:44:20 +0000
Received: by outflank-mailman (input) for mailman id 868393;
 Thu, 09 Jan 2025 13:44:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=rr8/=UB=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tVspf-0008Gh-2Q
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 13:44:19 +0000
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com
 [2a00:1450:4864:20::42e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d1ec9113-ce8f-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 14:44:17 +0100 (CET)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-38632b8ae71so680094f8f.0
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 05:44:17 -0800 (PST)
Received: from [192.168.86.29] ([83.105.36.37])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a8e4c1e0bsm1840206f8f.100.2025.01.09.05.44.15
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 05:44:16 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: d1ec9113-ce8f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736430256; x=1737035056; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=uinijA0lwwYUOWAD2nru6H5HCTT2qhSH87LYg9tjdO8=;
        b=eoF82OUy9SvRTMXp4NAZk17bVLF3RsFMX6eVo7z0q3Vwb3fyo1ZrgYibM8C+NZ5DWh
         Y8uPg+h/wD7+AihYgDsGEjrgNFsnWrUcJtmQPN+34Xa2VTwYjvrdnJWhZF/fgAT5/pVE
         ZKOFoU0D3FGp8DsSq/BG9d12p5v4HVUGtb4qQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736430256; x=1737035056;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=uinijA0lwwYUOWAD2nru6H5HCTT2qhSH87LYg9tjdO8=;
        b=Vek6O+DLVfbag1ZZOk9w/Po9RzlpqfskaZeuo1ohBpAfQE/Fbwn2br8thLE+6sfNDl
         qGorLNOKuwE8LFccRPwgm+CsrU3LUaHCutasHh9wm9WjWZawUe5p2fLCezJYS2TVPyrq
         HcJDzmcTZ8wTngIZmlRl2fEjh5CKIcjXrq1Fecc//oLUCrmcmAskUspN0dopbcwX6i7v
         BoLvkxUwGD50GthXeO5Z+GCUMkgBML28yJGqel6g9N8bwBNBo1CV18/udNXkqfjbmBT4
         b1xn8ItPUap3MVfgMzPCzciQo1B/FKZISJ76OUaX6m8pPZ8X58kaOqBUYzOVCON3bUpz
         hEWQ==
X-Forwarded-Encrypted: i=1; AJvYcCXF4+VtBDqbWBQFXo+ta2VZweDMn1v1LbpNUn62UB/GgL9Iwc2QdLvmNmkK+zW6ftLeRZffS1I9HT4=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw9VhgcqQk598SsPbabY7cgghDJaNRwJzr7Kj9d5T+KtEZ0996F
	LFstaHe1iObKzq9eUJoyAHGACkgVxHa9ElmM0ZVIIsyI8znTnA5raVCYaeqfWh8=
X-Gm-Gg: ASbGncsQYuNa4536WAUzpBlxnwMqYdik8eaxLSX5b2keBkle6ugOnVG6swH+xIoH2L9
	uowi/uJQYOUi0TwCmpG63y1jhl/nzjvekcxPSJZHx9B4T3dioK8098LGSdBOEQR1hTaQRwFsSgu
	3xCAVuDF17f1tY6zdHMPm4rN+ho8IDtY948DEPadn9ARPFGyAOtiJL+Rwp3Eq9uq4ONCuxQxPKs
	rnzmkY8TT8vtBT5zrcRrnRWU6grSXi9etz0giBD0PqGMXFT+osBbLEPCE2pvPtemCo=
X-Google-Smtp-Source: AGHT+IF96GNhxlmlpiNiubQsy+jVPnfW18GedSXgcVn/GSMr6xm46XGvHqugtvMwH8+1RcSLMu0d4g==
X-Received: by 2002:a05:6000:4714:b0:385:fc70:7eb with SMTP id ffacd0b85a97d-38a872fc1bfmr5262322f8f.12.1736430256379;
        Thu, 09 Jan 2025 05:44:16 -0800 (PST)
Message-ID: <47378338-ac05-4041-a055-56045e5ba131@citrix.com>
Date: Thu, 9 Jan 2025 13:44:15 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/boot: adjust text gap/diff to work with 64-bytes
 alignment too
To: Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
Cc: Frediano Ziglio <frediano.ziglio@cloud.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20250109131515.1757764-1-marmarek@invisiblethingslab.com>
 <d7421558-c2d6-485b-96bf-927992c5c066@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <d7421558-c2d6-485b-96bf-927992c5c066@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 09/01/2025 1:23 pm, Jan Beulich wrote:
> On 09.01.2025 14:15, Marek Marczykowski-Górecki wrote:
>> Xen compiled with -mtune=generic has .text alignment set to 64-bytes.
>> Having text_diff non-64-bytes-aligned breaks stuff:
>>
>>     Traceback (most recent call last):
>>       File "/builddir/build/BUILD/xen-4.20.0-build/xen-4.20.0-rc0/xen/./tools/combine_two_binaries.py", line 96, in <module>
>>         raise Exception('File sizes do not match')
>>     Exception: File sizes do not match: 70160 != 4080 + 66048
>>
>> Adjust the numbers as suggested by Frediano to work with 64-bytes and
>> even 128-bytes alignment.
> And then breaking at 256? As indicated on Matrix, imo we should be able to
> cope with anything up to at least PAGE_SIZE. Or we should reduce .text
> alignment before linking.

Do you have a concrete proposal on how to do this?

Because if not, we've had 2 downstreams hit by this build failure, and
we probably ought to take this patch as a stopgap fix, and see about
doing the better fix for 4.20.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 13:47:39 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 13:47:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868402.1279917 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVsss-0000OW-S6; Thu, 09 Jan 2025 13:47:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868402.1279917; Thu, 09 Jan 2025 13:47:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVsss-0000OP-Oe; Thu, 09 Jan 2025 13:47:38 +0000
Received: by outflank-mailman (input) for mailman id 868402;
 Thu, 09 Jan 2025 13:47: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
 <SRS0=eYg4=UB=invisiblethingslab.com=marmarek@srs-se1.protection.inumbo.net>)
 id 1tVssr-0000OJ-Cq
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 13:47:37 +0000
Received: from fhigh-a7-smtp.messagingengine.com
 (fhigh-a7-smtp.messagingengine.com [103.168.172.158])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 48274380-ce90-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 14:47:36 +0100 (CET)
Received: from phl-compute-11.internal (phl-compute-11.phl.internal
 [10.202.2.51])
 by mailfhigh.phl.internal (Postfix) with ESMTP id D6CF7114019E;
 Thu,  9 Jan 2025 08:47:34 -0500 (EST)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-11.internal (MEProxy); Thu, 09 Jan 2025 08:47:34 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 9 Jan 2025 08:47:32 -0500 (EST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 48274380-ce90-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm2; t=1736430454;
	 x=1736516854; bh=6x82qhagMZTKAmMzmxkVPAv3wNezZPg5u0REbe78dwQ=; b=
	CvHNy04IyvjcnnWguTcHHBIUaw3LGS++mZhpa7hfIU8Y+yyTCY4XIoAaOJLOnPvE
	f1k/iGTJENDXP/sh2sw23q+5JF/HRGRHlSrv7pPUW9SiLpbQpgy7bvoZ48QczvjR
	GDrCFZIszQfskz3kiXdSBLNBx2gt/z/xyLP1JjCpm0IZcKFN+1qAQy3DgfDUQWJ/
	5p3Ace8o4/Kglstma/HsNtTbnyT3FJYGsC5PpUM67ONN2dPfc7ekrnK7U/M0aRaj
	u7a+E9YY5m6CGYKK2E72Rey+c2YIK/NuRaaLqp6p1i5W4ybh+mEXpKKAi1WMtUhQ
	QtV23sJBBtuxgiNMNtaaAg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:subject:subject:to
	:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=
	1736430454; x=1736516854; bh=6x82qhagMZTKAmMzmxkVPAv3wNezZPg5u0R
	Ebe78dwQ=; b=AHXGe0ixUCR5SgVORxTnXO0q/ToG19eYCDwbQPabfv1VFIZ2EP/
	zmAfOOtfuifNhXy2xvJtmlPOOy9lmVym2qUtB8EKnP/8X8fSHVg+q7yscJ6ZQ5lP
	m5uEIF62HSmc+6fQ2ec7DcBHgy4lb0eh1F65YIzHmyfpGm4QB22JINBpBxzOGDXY
	0NYmKDUXgndeRd4Dbt9aUGkjB8wZl5N9rV2rtxPkEPlqyrzXwXUPOAqe/kkjfuaM
	qsx2rxim+vXwpa0uF0kCUWhsxqBO93m4XA6Z4xbdVYP1/PDrnrncf8Z1t6K7vEc6
	TW9wV0ysZMGAfpCUYz8w4BmyPpFANUQ1qAQ==
X-ME-Sender: <xms:dtN_Z-WSBn16sO_RB9cD46FBDD4kpBbVse2Cwgzi1LCMgPS1WHPUXw>
    <xme:dtN_Z6ll2GwgfVB1vGinmn81HTlx9iKZ0wkdnYOBGuN9mpluhk88F6ajYFdXPrjiV
    4eDtggVL22oEA>
X-ME-Received: <xmr:dtN_ZyZ3pQDqlLXvVpKpTQpwzqL5jKEKSUsARp3WxIDWzTN2U0ahrrXOnhMdYMQyohSQRwthH_91lj3Vekm_wk5vQwYl1FUG6g>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrudegiedgheegucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
    rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
    htshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtjeen
    ucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomh
    grrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggft
    rfgrthhtvghrnhepgfduleetfeevhfefheeiteeliefhjefhleduveetteekveettddvge
    euteefjedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhho
    mhepmhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnh
    gspghrtghpthhtohephedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepjhgsvghu
    lhhitghhsehsuhhsvgdrtghomhdprhgtphhtthhopehfrhgvughirghnohdriihighhlih
    hosegtlhhouhgurdgtohhmpdhrtghpthhtoheprghnughrvgifrdgtohhophgvrhefsegt
    ihhtrhhigidrtghomhdprhgtphhtthhopehrohhgvghrrdhprghusegtihhtrhhigidrtg
    homhdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggt
    thdrohhrgh
X-ME-Proxy: <xmx:dtN_Z1VLa_85opJMt6-WRHNmHeys0wHv-KUbhcXUGVmK2c8Ona2G9Q>
    <xmx:dtN_Z4k1_YqX9oUqgrzi_Tk9ffr-snKXgl1p8_GoJ_NWWCmRHevy-Q>
    <xmx:dtN_Z6d9G1Wlm6Z87ihkma1cL59sVnLqws2MsWohJlEhzBWdnXsm1g>
    <xmx:dtN_Z6EbKgoVwU3RfF9_fb8qWGO3XWwDKpWOfCy3g5VtpaD6sLvpnQ>
    <xmx:dtN_Z3vs7RyKwWgUgY_hb6TokRYiA0KwU1oDLHP8sHHzwKhC_UTYl2j->
Feedback-ID: i1568416f:Fastmail
Date: Thu, 9 Jan 2025 14:47:29 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Frediano Ziglio <frediano.ziglio@cloud.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH] x86/boot: adjust text gap/diff to work with 64-bytes
 alignment too
Message-ID: <Z3_Tcu_ZtZK4kkiD@mail-itl>
References: <20250109131515.1757764-1-marmarek@invisiblethingslab.com>
 <d7421558-c2d6-485b-96bf-927992c5c066@suse.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="dJ6kpmnJ7JlK/IYM"
Content-Disposition: inline
In-Reply-To: <d7421558-c2d6-485b-96bf-927992c5c066@suse.com>


--dJ6kpmnJ7JlK/IYM
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Thu, 9 Jan 2025 14:47:29 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Frediano Ziglio <frediano.ziglio@cloud.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH] x86/boot: adjust text gap/diff to work with 64-bytes
 alignment too

On Thu, Jan 09, 2025 at 02:23:27PM +0100, Jan Beulich wrote:
> No Fixes: tag?

I guess this would be appropriate:

    Fixes: aa9045e77130 ("x86/boot: Rework how 32bit C is linked/included f=
or early boot")

(but not relevant for backports, since that's only in 4.20 release
cycle)

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

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

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmd/03IACgkQ24/THMrX
1ywZbwf/YEEvAnbHvWFp/MJPfaEopy2rxQLls/00O27vp4UIHiclAfgYI5cG3s7b
jMDI6ebSJVl65vuTvhkc9mJsmMYdQ1WiDrkVXAwTMCJGtaJ9Pl2gJ65E9QnUxqKF
U6WG4nHXmK7DPsTmmg99TTHN3OQpIGMo6TQkexQCnTXA0aTM9ZO83y5ysx9HpybR
bU9UHjDGcja/4hfcdwELVRBoWuCa++GLaUJbRW8c0074tyvtcbs8EpFqqsa5p/es
GxR5y60MbAnmyr73BdAG/A7upGlb0qCHgNn4xoGgIlHI+flTDSwzzLsB5fXMzT5c
ii+Z5kmkD0ViH9CB11bLHnpRDWgUjg==
=k1xQ
-----END PGP SIGNATURE-----

--dJ6kpmnJ7JlK/IYM--


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 14:13:01 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 14:13:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868417.1279927 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVtHK-000520-UJ; Thu, 09 Jan 2025 14:12:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868417.1279927; Thu, 09 Jan 2025 14:12:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVtHK-00051t-Q5; Thu, 09 Jan 2025 14:12:54 +0000
Received: by outflank-mailman (input) for mailman id 868417;
 Thu, 09 Jan 2025 14:12:53 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=29Hz=UB=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tVtHJ-00051n-1w
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 14:12:53 +0000
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com
 [2a00:1450:4864:20::129])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d03d9aed-ce93-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 15:12:52 +0100 (CET)
Received: by mail-lf1-x129.google.com with SMTP id
 2adb3069b0e04-54252789365so1125345e87.0
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 06:12:52 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5428bec06e1sm211492e87.191.2025.01.09.06.12.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 06:12:50 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: d03d9aed-ce93-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736431971; x=1737036771; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=Hx9XNRWWQvFgmfC7xFExMys0jqPzn2r8jdox5rkxAKU=;
        b=bbGiqv09gd+2rkni3krghhslF/PliiEwMY989a9KglIHGcBUdPY4DJEbpE9vUg5KFh
         dtqLY8PuUBiHCjfhZJHRBwCxJuiPhVvN1k0GF4mDv6wz85GyW5bg9nqHvBRSwV4KlZag
         S/XDuNURSUKaVchvsXsd56mjuqZKCpntpM+J8YMFtthoiV7VsoBs5pD4t7+4Ra27iTh0
         7Rgh+cQw3fpPtZuX7ZF9dWLHTOdfU7bucTGbP/sv1GLZFNZGkiuFvv0CpeFX0Z2nkR4c
         05DqsgVnQYKfI6xMOJMz/AzLYHULl2QN7zgamj4oAn1ySz3koh7rWQ0nQc//Ks3APhBy
         qsdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736431971; x=1737036771;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Hx9XNRWWQvFgmfC7xFExMys0jqPzn2r8jdox5rkxAKU=;
        b=LuSGiqgJpAGEEkzh4RC8eK2qMPxvZxGctM055Q1j7716cmUvQUOow3MpL6nw9wekic
         V/91mfviG/CoVfMxxdXxyKUSTPej1aykos7ZkO7pqxYEc/xsIn/iJHGURliw2eoSAktg
         AYJyZWZwFKUmAggpc6p9nd1Y23FlWkIJ6ZEd/n7p3r3jAvCFK0wvYu4uOVMITnHWpAgf
         y6OaVWeFfA9DCQIDJHmbv0mvit5FV1g9s6cfIjcKoCW+eHywxLEklA0dzqsHESmDBa7c
         25ShzSc/rWPjq61ZZjMtJiguYzWqubxD/nynnTxT7ugtHYYwIg7Z0lJFuVqseLATcnyF
         FLEg==
X-Forwarded-Encrypted: i=1; AJvYcCXTlZPU23E/ZUdkDj+b2s1ZpL1Itzwg6kZ2qgDG0j2kT497MS8kgjlMZjhkhx5ZVgTGZ38ccts69D0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyCJG7q1A6ySV1bZIXjcnc5ZH7IPWLbJsmWRig64OwmuZ8ISrNu
	Dq3Up3FTcQAcZ6qa5C5YVGbTt5hCI46QLJTj6WJ2y4OPjlfBtGyB
X-Gm-Gg: ASbGncuf+7dRam09w6GnjYuxdOECMIBEgxZpZDQ3MRb5ng+PiPUAGH+4PbbHPbxS9Am
	7M+pgZhO/0qdrIdjtHDhGsfEg9wt1t/ujGv8ZtCjsT6SkBE7oBnlTop3MNpHAI6AcOahuFfTnqL
	cvrUBhcjFPb2/w7BkC8u+sD09glnDxGw7yG+Aejw7wJBc49JGTsQ7EdshM6/mdIQMsQHxi/E1Nf
	0fkVHwKDfsaCl6v38tiEyQBcEGyTuGHk6gC33TjzyHbaYy3UGYkAfblPL7RZqd+nl596Q==
X-Google-Smtp-Source: AGHT+IHTR2/ADrDRDofDG7g75O7jRL1IBWYeETf/Q5t1AXXn31P5qw51HbpEDRRCdyExcDPRxCetWg==
X-Received: by 2002:a05:6512:31d1:b0:540:2542:d89a with SMTP id 2adb3069b0e04-54284823efemr2089975e87.52.1736431971063;
        Thu, 09 Jan 2025 06:12:51 -0800 (PST)
Message-ID: <f6a7cc80-7770-44f6-9706-a259aaedcdec@gmail.com>
Date: Thu, 9 Jan 2025 15:12:49 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] xen/arm: ffa: fix build with clang
To: Stewart Hildebrand <stewart.hildebrand@amd.com>,
 xen-devel@lists.xenproject.org
Cc: Volodymyr Babchuk <volodymyr_babchuk@epam.com>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Michal Orzel <michal.orzel@amd.com>
References: <20250108164054.338799-1-stewart.hildebrand@amd.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <20250108164054.338799-1-stewart.hildebrand@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 1/8/25 5:40 PM, Stewart Hildebrand wrote:
> Clang 16 reports:
>
> In file included from arch/arm/tee/ffa.c:72:
> arch/arm/tee/ffa_private.h:329:17: error: 'used' attribute ignored on a non-definition declaration [-Werror,-Wignored-attributes]
> extern uint32_t __ro_after_init ffa_fw_version;
>                  ^
>
> The variable ffa_fw_version is only used in ffa.c. Remove the
> declaration in the header and make the definition in ffa.c static.
>
> Fixes: 2f9f240a5e87 ("xen/arm: ffa: Fine granular call support")
> Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>

Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>

Thanks.

~ Oleksii

> ---
> v1->v2:
> * remove declaration and make definition static
> ---
>   xen/arch/arm/tee/ffa.c         | 2 +-
>   xen/arch/arm/tee/ffa_private.h | 1 -
>   2 files changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
> index 87775ed88ffd..3bbdd7168a6b 100644
> --- a/xen/arch/arm/tee/ffa.c
> +++ b/xen/arch/arm/tee/ffa.c
> @@ -72,7 +72,7 @@
>   #include "ffa_private.h"
>   
>   /* Negotiated FF-A version to use with the SPMC, 0 if not there or supported */
> -uint32_t __ro_after_init ffa_fw_version;
> +static uint32_t __ro_after_init ffa_fw_version;
>   
>   /* Features supported by the SPMC or secure world when present */
>   DECLARE_BITMAP(ffa_fw_abi_supported, FFA_ABI_BITMAP_SIZE);
> diff --git a/xen/arch/arm/tee/ffa_private.h b/xen/arch/arm/tee/ffa_private.h
> index d441c0ca5598..c4cd65538908 100644
> --- a/xen/arch/arm/tee/ffa_private.h
> +++ b/xen/arch/arm/tee/ffa_private.h
> @@ -326,7 +326,6 @@ extern void *ffa_rx;
>   extern void *ffa_tx;
>   extern spinlock_t ffa_rx_buffer_lock;
>   extern spinlock_t ffa_tx_buffer_lock;
> -extern uint32_t __ro_after_init ffa_fw_version;
>   extern DECLARE_BITMAP(ffa_fw_abi_supported, FFA_ABI_BITMAP_SIZE);
>   
>   bool ffa_shm_domain_destroy(struct domain *d);
>
> base-commit: 70f5a875becc9444a959830b10a361982c31a366


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 14:15:57 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 14:15:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868426.1279937 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVtK8-0005ZO-AV; Thu, 09 Jan 2025 14:15:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868426.1279937; Thu, 09 Jan 2025 14: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 <xen-devel-bounces@lists.xenproject.org>)
	id 1tVtK8-0005ZH-6f; Thu, 09 Jan 2025 14:15:48 +0000
Received: by outflank-mailman (input) for mailman id 868426;
 Thu, 09 Jan 2025 14:15: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
 <SRS0=29Hz=UB=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tVtK6-0005ZB-7N
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 14:15:46 +0000
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com
 [2a00:1450:4864:20::134])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 376090e3-ce94-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 15:15:45 +0100 (CET)
Received: by mail-lf1-x134.google.com with SMTP id
 2adb3069b0e04-53f757134cdso953551e87.2
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 06:15:45 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5428c34a843sm206737e87.227.2025.01.09.06.15.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 06:15:44 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 376090e3-ce94-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736432145; x=1737036945; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=6xxfiP4WmzfQPbRxXHqCmC5n91VlUpR0NNXs4iZjpNE=;
        b=a2JfvD+GWRAEVLK0oq3fF7X+Jq56QiTD1qbYat60A3mZWk0LPaW46JO8gDMGeeeehT
         btDh9YLaC2CXPqr10Yugyll02ulCPseygjjNF5JopyCEmJsxbabj45kPC/XgU86Ipgaq
         XbSOayj2rBIqcKrXitWN2UZhAGi2UY+uDp8Xza2qCiL9/WVLVC0RSDeU/IQNcXZdbzFe
         DphMuREC+xIs7OEUrbcQZ9RHCoh2z3+8qnox0Bv+GxTx8LizCatHK/zUWBQ2dCilyZlZ
         Cv/MIglz0Xi0kZtvXLHYMF1QmfKG9ysfWWv/Hkl6PE/ut2v8fri/kiIzv+af79lu3agj
         s0JA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736432145; x=1737036945;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=6xxfiP4WmzfQPbRxXHqCmC5n91VlUpR0NNXs4iZjpNE=;
        b=KKwbufsFnOo8SGvmS+6jkjX2XL7m1W8qnhywMPe4MPaiEt3VNKSJttHwjgrRm8uJxO
         6riiMCtmFCXJF/BS5aQv44dyCqB5Wuiwpgt+l+mf+gm8gFIeoJ9PJzOJhVSgjsU9c4Le
         O5NyZ1hzgU3uCpbsscyHIfLOTt2CMTXFBB5GuyixotYPm/31/6yYiTHocE/v6J1NnSqo
         HiaNpNN7W1SSa2iNmHxyS18O0bFn5L1R7daDNPi0sB+RdNgANHSrBe6iDC/dzg7dDYtB
         tW8yfCeVAM/qS5PalFHTOpru1cHSrONUacmeZdK+NqoIaa/JGlYWhn0wU/XDmZ/cEDFH
         EGug==
X-Forwarded-Encrypted: i=1; AJvYcCXT+pUuD1MD1uW+gludP0/1VihLjM0ZUN7yehzsO40xc3TTels5rcZq8hE5rDvGYq0jYXPv3YSRQNw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxP3nq89j85TsTENHTIn2zyds9LA+acOmPgJREs7u+bIeZbUYIb
	TQXv+2NpPHQ4Z2ajaeixhwPtqKXfU5CsNIg3Nf/LbJzeV9rbAq3N
X-Gm-Gg: ASbGncsu2nKg7DJaUyrYAR55cHwXvbFKfjq2miYlK2PgmIgdcyXo6Yos1gR1UN3Gbej
	a9F406Rj+o64Ged5gZzSfkVmPw+jcz/m0s23gt0d+0SwN0RLbfkC+FZTh3U5Gp+hpe8ME7orJT9
	E1HcVVS9XGohYOl7BcyPLKOrnZy5AWhxPrrPtsiVRpcefJxabVNyIBDNywF8NLVzW3UXtVvv4YK
	c3+TvAN0UY2EEyWxi4G+QiN6OD6xiDSmIU+ko9uMW4DLGUhBznaz3qaLQl85fR2z/cgmA==
X-Google-Smtp-Source: AGHT+IHel5ua3qEGJqpPpe1hSKsEQ1zqHmsEDJFUF7yUcSNdmcL/rX8alGtHJMzw76K+Fo9ttltdrA==
X-Received: by 2002:a05:6512:3d8a:b0:53e:44a4:34e0 with SMTP id 2adb3069b0e04-542845bf90amr2149177e87.16.1736432144436;
        Thu, 09 Jan 2025 06:15:44 -0800 (PST)
Message-ID: <5306c19d-d1a9-477a-9c73-047450efe71e@gmail.com>
Date: Thu, 9 Jan 2025 15:15:43 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [for-4.20 PATCH v3] xen/arm: Fully initialise struct membanks_hdr
 fields
To: Luca Fancellu <luca.fancellu@arm.com>, xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
 <julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
References: <20250109130204.42545-1-luca.fancellu@arm.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <20250109130204.42545-1-luca.fancellu@arm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 1/9/25 2:02 PM, Luca Fancellu wrote:
> Commit a14593e3995a ("xen/device-tree: Allow region overlapping with
> /memreserve/ ranges") introduced a type in the 'struct membanks_hdr'
> but forgot to update the 'struct kernel_info' initialiser, while
> it doesn't lead to failures because the field is not currently
> used while managing kernel_info structures, it's good to have it
> for completeness.
>
> There are other instance of structures using 'struct membanks_hdr'
> that are dynamically allocated and don't fully initialise these
> fields, provide a static inline helper for that.
>
> Fixes: a14593e3995a ("xen/device-tree: Allow region overlapping with /memreserve/ ranges")
> Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
> Reviewed-by: Michal Orzel <michal.orzel@amd.com>

Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>

Thanks.

~ Oleksii

> ---
> Changes from v2:
>   - Banks created by Xen should be MEMORY type. (Michal)
>   - Add R-by Michal
> Changes from v1:
>   - Changed commit title and body msg
>   - initialised max_banks and type for all structures using 'struct membanks_hdr'
> ---
> ---
>   xen/arch/arm/domain_build.c       | 13 ++++---------
>   xen/arch/arm/include/asm/kernel.h |  5 ++++-
>   xen/arch/arm/static-shmem.c       |  3 ++-
>   xen/include/xen/bootfdt.h         | 16 ++++++++++++++++
>   4 files changed, 26 insertions(+), 11 deletions(-)
>
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index b072a16249fe..7b47abade196 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1039,7 +1039,7 @@ void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
>        */
>       if ( is_hardware_domain(d) )
>       {
> -        struct membanks *gnttab = xzalloc_flex_struct(struct membanks, bank, 1);
> +        struct membanks *gnttab = membanks_xzalloc(1, MEMORY);
>           /*
>            * Exclude the following regions:
>            * 1) Remove reserved memory
> @@ -1057,13 +1057,10 @@ void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
>           gnttab->bank[0].start = kinfo->gnttab_start;
>           gnttab->bank[0].size = kinfo->gnttab_size;
>   
> -        hwdom_free_mem = xzalloc_flex_struct(struct membanks, bank,
> -                                             NR_MEM_BANKS);
> +        hwdom_free_mem = membanks_xzalloc(NR_MEM_BANKS, MEMORY);
>           if ( !hwdom_free_mem )
>               goto fail;
>   
> -        hwdom_free_mem->max_banks = NR_MEM_BANKS;
> -
>           if ( find_unallocated_memory(kinfo, mem_banks, ARRAY_SIZE(mem_banks),
>                                        hwdom_free_mem, add_hwdom_free_regions) )
>               goto fail;
> @@ -1293,7 +1290,7 @@ static int __init find_host_extended_regions(const struct kernel_info *kinfo,
>                                                struct membanks *ext_regions)
>   {
>       int res;
> -    struct membanks *gnttab = xzalloc_flex_struct(struct membanks, bank, 1);
> +    struct membanks *gnttab = membanks_xzalloc(1, MEMORY);
>   
>       /*
>        * Exclude the following regions:
> @@ -1374,12 +1371,10 @@ int __init make_hypervisor_node(struct domain *d,
>       }
>       else
>       {
> -        ext_regions = xzalloc_flex_struct(struct membanks, bank, NR_MEM_BANKS);
> +        ext_regions = membanks_xzalloc(NR_MEM_BANKS, MEMORY);
>           if ( !ext_regions )
>               return -ENOMEM;
>   
> -        ext_regions->max_banks = NR_MEM_BANKS;
> -
>           if ( domain_use_host_layout(d) )
>           {
>               if ( !is_iommu_enabled(d) )
> diff --git a/xen/arch/arm/include/asm/kernel.h b/xen/arch/arm/include/asm/kernel.h
> index 7e6e3c82a477..de3f945ae54c 100644
> --- a/xen/arch/arm/include/asm/kernel.h
> +++ b/xen/arch/arm/include/asm/kernel.h
> @@ -92,7 +92,9 @@ kernel_info_get_mem_const(const struct kernel_info *kinfo)
>   }
>   
>   #ifdef CONFIG_STATIC_SHM
> -#define KERNEL_INFO_SHM_MEM_INIT .shm_mem.common.max_banks = NR_SHMEM_BANKS,
> +#define KERNEL_INFO_SHM_MEM_INIT                \
> +    .shm_mem.common.max_banks = NR_SHMEM_BANKS, \
> +    .shm_mem.common.type = STATIC_SHARED_MEMORY,
>   #else
>   #define KERNEL_INFO_SHM_MEM_INIT
>   #endif
> @@ -100,6 +102,7 @@ kernel_info_get_mem_const(const struct kernel_info *kinfo)
>   #define KERNEL_INFO_INIT                        \
>   {                                               \
>       .mem.common.max_banks = NR_MEM_BANKS,       \
> +    .mem.common.type = MEMORY,                  \
>       KERNEL_INFO_SHM_MEM_INIT                    \
>   }
>   
> diff --git a/xen/arch/arm/static-shmem.c b/xen/arch/arm/static-shmem.c
> index 66088a426785..8f87154c3587 100644
> --- a/xen/arch/arm/static-shmem.c
> +++ b/xen/arch/arm/static-shmem.c
> @@ -20,7 +20,8 @@ static struct {
>       struct membanks_hdr common;
>       struct membank bank[NR_SHMEM_BANKS];
>   } shm_heap_banks __initdata = {
> -    .common.max_banks = NR_SHMEM_BANKS
> +    .common.max_banks = NR_SHMEM_BANKS,
> +    .common.type = STATIC_SHARED_MEMORY
>   };
>   
>   static inline struct membanks *get_shmem_heap_banks(void)
> diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
> index c8bbfd8979b2..80a90e53c001 100644
> --- a/xen/include/xen/bootfdt.h
> +++ b/xen/include/xen/bootfdt.h
> @@ -4,6 +4,7 @@
>   #include <xen/types.h>
>   #include <xen/kernel.h>
>   #include <xen/macros.h>
> +#include <xen/xmalloc.h>
>   
>   #define MIN_FDT_ALIGN 8
>   
> @@ -219,4 +220,19 @@ static inline struct shmem_membank_extra *bootinfo_get_shmem_extra(void)
>   }
>   #endif
>   
> +static inline struct membanks *membanks_xzalloc(unsigned int nr,
> +                                                enum region_type type)
> +{
> +    struct membanks *banks = xzalloc_flex_struct(struct membanks, bank, nr);
> +
> +    if ( !banks )
> +        goto out;
> +
> +    banks->max_banks = nr;
> +    banks->type = type;
> +
> + out:
> +    return banks;
> +}
> +
>   #endif /* XEN_BOOTFDT_H */


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 14:30:41 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 14:30:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868446.1279946 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVtYQ-0008Ug-KM; Thu, 09 Jan 2025 14:30:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868446.1279946; Thu, 09 Jan 2025 14:30:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVtYQ-0008UZ-Hn; Thu, 09 Jan 2025 14:30:34 +0000
Received: by outflank-mailman (input) for mailman id 868446;
 Thu, 09 Jan 2025 14:30:33 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=29Hz=UB=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tVtYP-0008Sz-9T
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 14:30:33 +0000
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com
 [2a00:1450:4864:20::12a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 47b1898e-ce96-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 15:30:31 +0100 (CET)
Received: by mail-lf1-x12a.google.com with SMTP id
 2adb3069b0e04-53f22fd6832so1054630e87.1
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 06:30:31 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5428be4a029sm213034e87.54.2025.01.09.06.30.29
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 06:30:30 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 47b1898e-ce96-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736433031; x=1737037831; darn=lists.xenproject.org;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=8o3sLdrSQmSEZfwyq7x3Be1EQVU7A/CoBvMhpf1ArCI=;
        b=eZgTTexm86URc36roisY6M5jn/DgtiSTXSFZEXpTeW0Gqg7USzXwaUG7yVbZb2bSaN
         CXFGZ0lDNq2mbRPsgRJRu6a+Rk2kbpO0UAf/4oV7oxtvYlI1FfC1WFjz7LK+AikUjuyH
         5f2zjo99/C9VGWARCiosAaBcZNk40p8TFWjZqKAhrcwDE9pz2z9jFM5h2yXL4IQchv30
         a8Xrxp47Awj2vnYIamm7MrSfzmbZv6bzwczdrfrYYZloaNdXVSKD8vjWY99bPE00nqpb
         7C9bqPN014Up88K6f2ojZ25b7kve+6pbrPWfTh0zVlHYmInJjC4Q5essvcT6Tokh3oHc
         yc4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736433031; x=1737037831;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=8o3sLdrSQmSEZfwyq7x3Be1EQVU7A/CoBvMhpf1ArCI=;
        b=aE31p3jGjAudvSTJRQg3RwCH9v+s/S5dwU1Nyv7pN9n6ThxxrN9PSgvfFcyx3I3k/O
         M65s+6I2s4ucEbDgLkaORpLAUKkMbJBo9YIVCpEHG/71Xgf271+9f7wu9Rv8jGpt+rbZ
         BdAIbnDzbfsZTge6TgRy+N6Qe2XDte221Xq/f7FDkPzOWRZvZg58rXQWQ6VxvZ1YCEwE
         0k1L3KGfzULxqSY4BUfzVxbkhehoLt44k6OjaOp1Nd1XLDA5nzZwaVleKEElSYoNBjNo
         bc1daqabszbXhtq8EklPBV4Sp9oIJeHPuORbulXcrcLd3TuaTYmrCBQvBrLEmXXiYJ9u
         Jquw==
X-Forwarded-Encrypted: i=1; AJvYcCVmr68REJ3kk176GolFm5h6Kix+iMvyg7NQcaFyJ8nc1Y2QAv18ov/R5JMPGFElsr9zM+JG2YFSW+A=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzRpFweKbOfwU6EUm2GmqPxPMQP+npnQ+vxJjlzy5Z2ZaadYEXE
	ba884Ob3gpXU7VCJlvNbMFRXcmmL7RvdEJljlOxuKgpPQL6EfYPh
X-Gm-Gg: ASbGncvM2yDRcHSkemBJ8Lymtk7laK9U9xpsuiid4CxbQtT0Mb2c6Q20q5E0xQjmx4P
	SXbbmdW5fLqFxuIGaFxEszHM8+NN9lRKXH0te6BT8JSzheIzXfYKBVITIV5ITtD2anPnTjliSr1
	oI12evSNgek3mxbEfeAQAuQQlJMqxOmgB7rQIk9ErH9/ij6cmnp8MhCsO/mY7NtvMjGPX5rtXKY
	8lu9uNFsk2BIRCeatuCq1Z19N2RQGAejsh9THRKrgTGQphHi44M2GXCA8NtGMAdXXeWdg==
X-Google-Smtp-Source: AGHT+IFHigQORXkLujkGRP2Ut+BSL155Fn5/j2ohvlUwLZAOkhNc7gwIK5Gr1lF3JxP32FeAwFyRDA==
X-Received: by 2002:a05:6512:220b:b0:53e:389d:8ce6 with SMTP id 2adb3069b0e04-542845d1dbamr2181163e87.28.1736433030738;
        Thu, 09 Jan 2025 06:30:30 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------XB0QNu0dROnMFJsesAT8yNW2"
Message-ID: <4eea61a2-cf56-4ff5-8c43-58f5a20c9cb1@gmail.com>
Date: Thu, 9 Jan 2025 15:30:28 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 0/2] x86: Add Support for Paging-Write Feature
To: =?UTF-8?Q?Petr_Bene=C5=A1?= <w1benny@gmail.com>,
 xen-devel@lists.xenproject.org
Cc: Jan Beulich <jbeulich@suse.com>, Andrew Cooper
 <andrew.cooper3@citrix.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Tamas K Lengyel <tamas@tklengyel.com>,
 Alexandru Isaila <aisaila@bitdefender.com>,
 Petre Pircalabu <ppircalabu@bitdefender.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Anthony PERARD <anthony.perard@vates.tech>
References: <cover.1735837806.git.w1benny@gmail.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <cover.1735837806.git.w1benny@gmail.com>

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


On 1/2/25 6:13 PM, Petr Beneš wrote:
> From: Petr Beneš<w1benny@gmail.com>
>
> Changes since v2:
> - Reset entry->pw in all cases in p2m_set_entry, except for p2m_access_r_pw
>
> Changes since v1:
> - Added signed-off-by tags
>
> This patch introduces a new XENMEM_access_r_pw permission. Functionally, it is similar to XENMEM_access_r, but for processors with TERTIARY_EXEC_EPT_PAGING_WRITE support (Intel 12th Gen/Alder Lake and later), it also permits the CPU to write to the page during guest page-table walks (e.g., updating A/D bits) without triggering an EPT violation.
>
> This behavior works by both enabling the EPT paging-write feature and setting the EPT paging-write flag in the EPT leaf entry.
>
> This feature provides a significant performance boost for introspection tools that monitor guest page-table updates. Previously, every page-table modification by the guest—including routine updates like setting A/D bits—triggered an EPT violation, adding unnecessary overhead. The new XENMEM_access_r_pw permission allows these "uninteresting" updates to occur without EPT violations, improving efficiency.

Considering that this feature provides a significant performance boost 
for introspection tools probably we could consider to take it to current 
release.

I see that the patch series was acked-by "Acked-by: Tamas K Lengyel 
<tamas@tklengyel.com>" but based on the change log it is not clear when 
exactly

before Feature freeze date or not. ( and I don't see any reply from Tamas ).

Thanks.

~ Oleksii

>
> Additionally, this feature simplifies the handling of race conditions in scenarios where an introspection tool:
>
> - Sets an "invisible breakpoint" in the altp2m view for a function F
> - Monitors guest page-table updates to track whether the page containing F is paged out
> - Encounters a cleared Access (A) bit on the page containing F while the guest is about to execute the breakpoint
>
> In the current implementation:
>
> - If xc_monitor_inguest_pagefault() is enabled, the introspection tool must emulate both the breakpoint and the setting of the Access bit.
> - If xc_monitor_inguest_pagefault() is disabled, Xen handles the EPT violation without notifying the introspection tool, setting the Access bit and emulating the instruction. However, Xen fetches the instruction from the default view instead of the altp2m view, potentially causing the breakpoint to be missed.
>
> With this patch, setting XENMEM_access_r_pw for monitored guest page-tables prevents EPT violations in these cases. This change enhances performance and reduces complexity for introspection tools, ensuring seamless breakpoint handling while tracking guest page-table updates.
>
>
> Petr Beneš (2):
>    x86: Rename _rsvd field to pw and move it to the bit 58
>    x86: Add Support for Paging-Write Feature
>
>   xen/arch/arm/mem_access.c               |  4 ++++
>   xen/arch/arm/mmu/p2m.c                  |  1 +
>   xen/arch/x86/hvm/hvm.c                  |  1 +
>   xen/arch/x86/hvm/monitor.c              |  1 +
>   xen/arch/x86/hvm/vmx/vmcs.c             |  4 +++-
>   xen/arch/x86/include/asm/hvm/vmx/vmcs.h |  3 +++
>   xen/arch/x86/include/asm/hvm/vmx/vmx.h  |  4 ++--
>   xen/arch/x86/include/asm/p2m.h          |  1 +
>   xen/arch/x86/mm/hap/nested_hap.c        |  3 +++
>   xen/arch/x86/mm/mem_access.c            |  3 +++
>   xen/arch/x86/mm/p2m-ept.c               | 12 ++++++++++++
>   xen/include/public/memory.h             |  9 +++++++++
>   xen/include/xen/mem_access.h            |  6 ++++++
>   13 files changed, 49 insertions(+), 3 deletions(-)
>
--------------XB0QNu0dROnMFJsesAT8yNW2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 1/2/25 6:13 PM, Petr Beneš wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:cover.1735837806.git.w1benny@gmail.com">
      <pre wrap="" class="moz-quote-pre">From: Petr Beneš <a class="moz-txt-link-rfc2396E" href="mailto:w1benny@gmail.com">&lt;w1benny@gmail.com&gt;</a></pre>
    </blockquote>
    <blockquote type="cite"
      cite="mid:cover.1735837806.git.w1benny@gmail.com">
      <pre wrap="" class="moz-quote-pre">

Changes since v2:
- Reset entry-&gt;pw in all cases in p2m_set_entry, except for p2m_access_r_pw

Changes since v1:
- Added signed-off-by tags</pre>
    </blockquote>
    <blockquote type="cite"
      cite="mid:cover.1735837806.git.w1benny@gmail.com">
      <pre wrap="" class="moz-quote-pre">

This patch introduces a new XENMEM_access_r_pw permission. Functionally, it is similar to XENMEM_access_r, but for processors with TERTIARY_EXEC_EPT_PAGING_WRITE support (Intel 12th Gen/Alder Lake and later), it also permits the CPU to write to the page during guest page-table walks (e.g., updating A/D bits) without triggering an EPT violation.

This behavior works by both enabling the EPT paging-write feature and setting the EPT paging-write flag in the EPT leaf entry.

This feature provides a significant performance boost for introspection tools that monitor guest page-table updates. Previously, every page-table modification by the guest—including routine updates like setting A/D bits—triggered an EPT violation, adding unnecessary overhead. The new XENMEM_access_r_pw permission allows these "uninteresting" updates to occur without EPT violations, improving efficiency.</pre>
    </blockquote>
    <pre><font face="monospace">Considering that this feature provides a significant performance boost for introspection tools probably we could consider to take it to current release.</font></pre>
    <pre><font face="monospace">I see that the patch series was acked-by "<span
    style="white-space: pre-wrap">Acked-by: Tamas K Lengyel <a
    class="moz-txt-link-rfc2396E" href="mailto:tamas@tklengyel.com">&lt;tamas@tklengyel.com&gt;</a>" but based on the change log it is not clear when exactly</span></font></pre>
    <pre><font face="monospace"><span style="white-space: pre-wrap">before Feature freeze date or not. ( and I don't see any reply from Tamas ).</span></font></pre>
    <pre><font face="monospace"><span style="white-space: pre-wrap">


Thanks.

</span></font></pre>
    <pre><font face="monospace">~ Oleksii</font>
</pre>
    <blockquote type="cite"
      cite="mid:cover.1735837806.git.w1benny@gmail.com">
      <pre wrap="" class="moz-quote-pre">

Additionally, this feature simplifies the handling of race conditions in scenarios where an introspection tool:

- Sets an "invisible breakpoint" in the altp2m view for a function F
- Monitors guest page-table updates to track whether the page containing F is paged out
- Encounters a cleared Access (A) bit on the page containing F while the guest is about to execute the breakpoint

In the current implementation:

- If xc_monitor_inguest_pagefault() is enabled, the introspection tool must emulate both the breakpoint and the setting of the Access bit.
- If xc_monitor_inguest_pagefault() is disabled, Xen handles the EPT violation without notifying the introspection tool, setting the Access bit and emulating the instruction. However, Xen fetches the instruction from the default view instead of the altp2m view, potentially causing the breakpoint to be missed.

With this patch, setting XENMEM_access_r_pw for monitored guest page-tables prevents EPT violations in these cases. This change enhances performance and reduces complexity for introspection tools, ensuring seamless breakpoint handling while tracking guest page-table updates.


Petr Beneš (2):
  x86: Rename _rsvd field to pw and move it to the bit 58
  x86: Add Support for Paging-Write Feature

 xen/arch/arm/mem_access.c               |  4 ++++
 xen/arch/arm/mmu/p2m.c                  |  1 +
 xen/arch/x86/hvm/hvm.c                  |  1 +
 xen/arch/x86/hvm/monitor.c              |  1 +
 xen/arch/x86/hvm/vmx/vmcs.c             |  4 +++-
 xen/arch/x86/include/asm/hvm/vmx/vmcs.h |  3 +++
 xen/arch/x86/include/asm/hvm/vmx/vmx.h  |  4 ++--
 xen/arch/x86/include/asm/p2m.h          |  1 +
 xen/arch/x86/mm/hap/nested_hap.c        |  3 +++
 xen/arch/x86/mm/mem_access.c            |  3 +++
 xen/arch/x86/mm/p2m-ept.c               | 12 ++++++++++++
 xen/include/public/memory.h             |  9 +++++++++
 xen/include/xen/mem_access.h            |  6 ++++++
 13 files changed, 49 insertions(+), 3 deletions(-)

</pre>
    </blockquote>
  </body>
</html>

--------------XB0QNu0dROnMFJsesAT8yNW2--


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 14:34:13 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 14:34:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868460.1279956 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVtbw-0000oa-2j; Thu, 09 Jan 2025 14:34:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868460.1279956; Thu, 09 Jan 2025 14:34:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVtbw-0000oT-05; Thu, 09 Jan 2025 14:34:12 +0000
Received: by outflank-mailman (input) for mailman id 868460;
 Thu, 09 Jan 2025 14:34: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
 <SRS0=bl7y=UB=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tVtbu-0000oN-Sv
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 14:34:10 +0000
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com
 [2a00:1450:4864:20::429])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c939d6dd-ce96-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 15:34:09 +0100 (CET)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-38a34e8410bso577352f8f.2
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 06:34:09 -0800 (PST)
Received: from localhost ([66.81.170.107]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a8e38c697sm2016678f8f.52.2025.01.09.06.34.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 06:34:07 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c939d6dd-ce96-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736433248; x=1737038048; darn=lists.xenproject.org;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=5Nyd8o6ZDmZrvb09cL1RZmKteo2db8IAljcfguY7qSQ=;
        b=jbCcx85AA4Lcokz+d1886Yx3nYm8Im8OQHiyZXfpO/99KZ4NivuJEIDk7BSlj/2+9m
         Dgllw8JwZZ+1FGbG3ws7rPQy4xC+EvoJjtAuJuzVwFTjQa5wwkFf6T+zc0QbSwo2eVsQ
         YxbbWPFZMpdkj8QEsSQafh0spsXCUBrr5GlI0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736433248; x=1737038048;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=5Nyd8o6ZDmZrvb09cL1RZmKteo2db8IAljcfguY7qSQ=;
        b=NYMk+caq9iIAHBp4aDf9QOOFactwke5if3mxjDez2iLBDnKZmsbhFbao0kHrNNX8G3
         BGJ/uGTag8hW9rGBaIBX5NEVBbyujTWu5+vYx1mKelwORZ6AQWbOJgoi2VB0T99XeKTH
         skDg0RPyzUCag++wwXeT6x7B1jyxtpkZjskf2mHPU/W04XU+6K6hl4blqMEDCde0lArZ
         Za0Sh0DNSnSYoVpPglfahfNLmcUFUXEiA8c1SHixAVUDfXxPLrf7617dfelWokfhAegS
         49ZIPwlRJYnfzxOOCW6BPsO39nope3vrc7B74FAmMnrM3yjOhFLLiksENDJWflLpLEtv
         n78g==
X-Forwarded-Encrypted: i=1; AJvYcCXmGePZEwl6ptEMGJADcgRV3VZqGgn9Vv05lhJZtipJP9615R5r3YwC8+HCdwI3CSMyqwVmbV2wqaw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzStkxBnBn/IrbmdDwwEFZkRBQnp8KD14/BO1Wlud6HA6vFE0QH
	bChanTTkp4tH/jx4zL5s6wLLqP5VYDID/ZdQ3ogEOC4JBYriXEuwkH8KuG78I5Y=
X-Gm-Gg: ASbGncuee/RBlc3Es+zlmBURnmd/EOvY2dzbn2/4DT7e2ezlknCm2tZObMKnNi6cncR
	gf87UiBpQRa9n/Yfe1Jrf5tz1Iboy2YmQTQE0yvMwXg/7bPwQ7I/0eP0CY4rZicjuRZcGtxLNxs
	i9hYDC8SQ3viouGaOoD7rmf92XAieSxkQsmGIuXwO/2fQzR6GHme69/RrZj6NFtIf/LbhwQcHsv
	yu9b3kNMj4ebe9bA3vFMFPU1xrJmmXda7IGFFigkp5bDXl6+YqJ7znYFNsi2UQ=
X-Google-Smtp-Source: AGHT+IGrsj9gFvZbdFSfqAoftR5eWlus1YFDN0K1FzWTd0jQPThNxqDUpRWOm9wrPVllN86dIHmxlg==
X-Received: by 2002:a05:6000:1f81:b0:386:1cd3:8a03 with SMTP id ffacd0b85a97d-38a872ec38fmr5884682f8f.32.1736433248261;
        Thu, 09 Jan 2025 06:34:08 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Thu, 09 Jan 2025 14:34:05 +0000
Message-Id: <D6XM7OP0SQPB.3U12X09JAPKU3@cloud.com>
Cc: "Jan Beulich" <jbeulich@suse.com>, "Andrew Cooper"
 <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v2 07/18] x86/pv: update guest LDT mappings using the
 linear entries
From: "Alejandro Vallejo" <alejandro.vallejo@cloud.com>
To: "Roger Pau Monne" <roger.pau@citrix.com>,
 <xen-devel@lists.xenproject.org>
X-Mailer: aerc 0.18.2
References: <20250108142659.99490-1-roger.pau@citrix.com>
 <20250108142659.99490-8-roger.pau@citrix.com>
In-Reply-To: <20250108142659.99490-8-roger.pau@citrix.com>

On Wed Jan 8, 2025 at 2:26 PM GMT, Roger Pau Monne wrote:
> The pv_map_ldt_shadow_page() and pv_destroy_ldt() functions rely on the L=
1
> table(s) that contain such mappings being stashed in the domain structure=
, and
> thus such mappings being modified by merely updating the require L1 entri=
es.
>
> Switch pv_map_ldt_shadow_page() to unconditionally use the linear recursi=
ve, as
> that logic is always called while the vCPU is running on the current pCPU=
.
>
> For pv_destroy_ldt() use the linear mappings if the vCPU is the one curre=
ntly
> running on the pCPU, otherwise use destroy_mappings().
>
> Note this requires keeping an array with the pages currently mapped at th=
e LDT
> area, as that allows dropping the extra taken page reference when removin=
g the
> mappings.
>
> Signed-off-by: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
> ---
>  xen/arch/x86/include/asm/domain.h   |  2 ++
>  xen/arch/x86/pv/descriptor-tables.c | 19 ++++++++++---------
>  xen/arch/x86/pv/domain.c            |  4 ++++
>  xen/arch/x86/pv/mm.c                |  3 ++-
>  4 files changed, 18 insertions(+), 10 deletions(-)
>
> diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm=
/domain.h
> index b79d6badd71c..b659cffc7f81 100644
> --- a/xen/arch/x86/include/asm/domain.h
> +++ b/xen/arch/x86/include/asm/domain.h
> @@ -523,6 +523,8 @@ struct pv_vcpu
>      struct trap_info *trap_ctxt;
> =20
>      unsigned long gdt_frames[FIRST_RESERVED_GDT_PAGE];
> +    /* Max LDT entries is 8192, so 8192 * 8 =3D 64KiB (16 pages). */
> +    mfn_t ldt_frames[16];
>      unsigned long ldt_base;
>      unsigned int gdt_ents, ldt_ents;
> =20
> diff --git a/xen/arch/x86/pv/descriptor-tables.c b/xen/arch/x86/pv/descri=
ptor-tables.c
> index 5a79f022ce13..95b598a4c0cf 100644
> --- a/xen/arch/x86/pv/descriptor-tables.c
> +++ b/xen/arch/x86/pv/descriptor-tables.c
> @@ -20,28 +20,29 @@
>   */
>  bool pv_destroy_ldt(struct vcpu *v)
>  {
> -    l1_pgentry_t *pl1e;
> +    const unsigned int nr_frames =3D ARRAY_SIZE(v->arch.pv.ldt_frames);
>      unsigned int i, mappings_dropped =3D 0;
> -    struct page_info *page;
> =20
>      ASSERT(!in_irq());
> =20
>      ASSERT(v =3D=3D current || !vcpu_cpu_dirty(v));
> =20
> -    pl1e =3D pv_ldt_ptes(v);
> +    destroy_perdomain_mapping(v, LDT_VIRT_START(v), nr_frames);
> =20
> -    for ( i =3D 0; i < 16; i++ )
> +    for ( i =3D 0; i < nr_frames; i++ )

nit: While at this, can the "unsigned int" be moved here too?

>      {
> -        if ( !(l1e_get_flags(pl1e[i]) & _PAGE_PRESENT) )
> -            continue;
> +        mfn_t mfn =3D v->arch.pv.ldt_frames[i];
> +        struct page_info *page;
> =20
> -        page =3D l1e_get_page(pl1e[i]);
> -        l1e_write(&pl1e[i], l1e_empty());
> -        mappings_dropped++;
> +        if ( mfn_eq(mfn, INVALID_MFN) )
> +            continue;

Can it really be disjoint? As in, why "continue" and not "break"?. Not that=
 it
matters in the slightest, and I prefer this form; but I'm curious.

> =20
> +        v->arch.pv.ldt_frames[i] =3D INVALID_MFN;
> +        page =3D mfn_to_page(mfn);
>          ASSERT_PAGE_IS_TYPE(page, PGT_seg_desc_page);
>          ASSERT_PAGE_IS_DOMAIN(page, v->domain);
>          put_page_and_type(page);
> +        mappings_dropped++;
>      }
> =20
>      return mappings_dropped;
> diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
> index 7e8bffaae9a0..32d7488cc186 100644
> --- a/xen/arch/x86/pv/domain.c
> +++ b/xen/arch/x86/pv/domain.c
> @@ -303,6 +303,7 @@ void pv_vcpu_destroy(struct vcpu *v)
>  int pv_vcpu_initialise(struct vcpu *v)
>  {
>      struct domain *d =3D v->domain;
> +    unsigned int i;
>      int rc;
> =20
>      ASSERT(!is_idle_domain(d));
> @@ -311,6 +312,9 @@ int pv_vcpu_initialise(struct vcpu *v)
>      if ( rc )
>          return rc;
> =20
> +    for ( i =3D 0; i < ARRAY_SIZE(v->arch.pv.ldt_frames); i++ )
> +        v->arch.pv.ldt_frames[i] =3D INVALID_MFN;
> +

I think it makes more sense to move this earlier so ldt_frames[] is initial=
ised
even if pv_vcpu_initialise() fails. It may be benign, but it looks like an
accident abount to happen.

Also, nit: "unsigned int i"'s scope can be restricted to the loop itself.

  As in, "for ( unsigned int i =3D..."

>      BUILD_BUG_ON(X86_NR_VECTORS * sizeof(*v->arch.pv.trap_ctxt) >
>                   PAGE_SIZE);
>      v->arch.pv.trap_ctxt =3D xzalloc_array(struct trap_info, X86_NR_VECT=
ORS);
> diff --git a/xen/arch/x86/pv/mm.c b/xen/arch/x86/pv/mm.c
> index 187f5f6a3e8c..4853e619f2a7 100644
> --- a/xen/arch/x86/pv/mm.c
> +++ b/xen/arch/x86/pv/mm.c
> @@ -86,7 +86,8 @@ bool pv_map_ldt_shadow_page(unsigned int offset)
>          return false;
>      }
> =20
> -    pl1e =3D &pv_ldt_ptes(curr)[offset >> PAGE_SHIFT];
> +    curr->arch.pv.ldt_frames[offset >> PAGE_SHIFT] =3D page_to_mfn(page)=
;
> +    pl1e =3D &__linear_l1_table[l1_linear_offset(LDT_VIRT_START(curr) + =
offset)];
>      l1e_add_flags(gl1e, _PAGE_RW);
> =20
>      l1e_write(pl1e, gl1e);

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 14:49:19 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 14:49:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868476.1279971 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVtqT-0002id-9a; Thu, 09 Jan 2025 14:49:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868476.1279971; Thu, 09 Jan 2025 14:49:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVtqT-0002iW-6y; Thu, 09 Jan 2025 14:49:13 +0000
Received: by outflank-mailman (input) for mailman id 868476;
 Thu, 09 Jan 2025 14:49:12 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Vo0Q=UB=goodmis.org=rostedt@kernel.org>)
 id 1tVtqS-0002iQ-8u
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 14:49:12 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e1e7f2b0-ce98-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 15:49:10 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 861CE5C5A84;
 Thu,  9 Jan 2025 14:48:27 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 35F4DC4CED2;
 Thu,  9 Jan 2025 14:49:04 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e1e7f2b0-ce98-11ef-a0df-8be0dac302b0
Date: Thu, 9 Jan 2025 09:50:37 -0500
From: Steven Rostedt <rostedt@goodmis.org>
To: Joel Granados <joel.granados@kernel.org>
Cc: Thomas =?UTF-8?B?V2Vpw59zY2h1aA==?= <linux@weissschuh.net>, Kees Cook
 <kees@kernel.org>, Luis Chamberlain <mcgrof@kernel.org>,
 linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
 linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,
 linux-s390@vger.kernel.org, linux-crypto@vger.kernel.org,
 openipmi-developer@lists.sourceforge.net, intel-gfx@lists.freedesktop.org,
 dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
 linux-hyperv@vger.kernel.org, linux-rdma@vger.kernel.org,
 linux-raid@vger.kernel.org, linux-scsi@vger.kernel.org,
 linux-serial@vger.kernel.org, xen-devel@lists.xenproject.org,
 linux-aio@kvack.org, linux-fsdevel@vger.kernel.org, netfs@lists.linux.dev,
 codalist@coda.cs.cmu.edu, linux-mm@kvack.org, linux-nfs@vger.kernel.org,
 ocfs2-devel@lists.linux.dev, fsverity@lists.linux.dev,
 linux-xfs@vger.kernel.org, io-uring@vger.kernel.org, bpf@vger.kernel.org,
 kexec@lists.infradead.org, linux-trace-kernel@vger.kernel.org,
 linux-hardening@vger.kernel.org, apparmor@lists.ubuntu.com,
 linux-security-module@vger.kernel.org, keyrings@vger.kernel.org
Subject: Re: [PATCH] treewide: const qualify ctl_tables where applicable
Message-ID: <20250109095037.0ac3fe09@gandalf.local.home>
In-Reply-To: <20250109-jag-ctl_table_const-v1-1-622aea7230cf@kernel.org>
References: <20250109-jag-ctl_table_const-v1-1-622aea7230cf@kernel.org>
X-Mailer: Claws Mail 3.20.0git84 (GTK+ 2.24.33; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Thu, 09 Jan 2025 14:16:39 +0100
Joel Granados <joel.granados@kernel.org> wrote:

> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index 2e113f8b13a2..489cbab3d64c 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -8786,7 +8786,7 @@ ftrace_enable_sysctl(const struct ctl_table *table, int write,
>  	return ret;
>  }
>  
> -static struct ctl_table ftrace_sysctls[] = {
> +static const struct ctl_table ftrace_sysctls[] = {
>  	{
>  		.procname       = "ftrace_enabled",
>  		.data           = &ftrace_enabled,
> diff --git a/kernel/trace/trace_events_user.c b/kernel/trace/trace_events_user.c
> index 17bcad8f79de..97325fbd6283 100644
> --- a/kernel/trace/trace_events_user.c
> +++ b/kernel/trace/trace_events_user.c
> @@ -2899,7 +2899,7 @@ static int set_max_user_events_sysctl(const struct ctl_table *table, int write,
>  	return ret;
>  }
>  
> -static struct ctl_table user_event_sysctls[] = {
> +static const struct ctl_table user_event_sysctls[] = {
>  	{
>  		.procname	= "user_events_max",
>  		.data		= &max_user_events,

Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org> # for kernel/trace/

-- Steve


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 14:50:59 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 14:50:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868483.1279981 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVtsA-0004Gp-Ji; Thu, 09 Jan 2025 14:50:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868483.1279981; Thu, 09 Jan 2025 14:50:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVtsA-0004Gf-HC; Thu, 09 Jan 2025 14:50:58 +0000
Received: by outflank-mailman (input) for mailman id 868483;
 Thu, 09 Jan 2025 14:50:56 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=pS5t=UB=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVts8-0004GX-NC
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 14:50:56 +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 213a6c78-ce99-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 15:50:55 +0100 (CET)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-4362f61757fso10706835e9.2
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 06:50: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
 ffacd0b85a97d-38a8e37d154sm2086025f8f.10.2025.01.09.06.50.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 06:50:54 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 213a6c78-ce99-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736434255; x=1737039055; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=bQ7O0CTldjygQku2NAoci4VaNDGpPNcndFcs2iZCnSw=;
        b=I1dw0Zfedz8i5Nfgw3ATIHcNGCylaJyCFxCxpFj+Xom+wupU5t50U4IkjqJnMm5qNZ
         ST/+6OsW6qq6Xu+lAhJrX+7v+YM3yfgZ14axyVsJVRUbFCzzVsXcPaXXzQX9kenOkwsj
         dRfQEnHu6TO+RVRTAwjZWHzACGpX/cZCPFCbHIDD0nBiduq4OPul/PSNAuV0FXJ3AIoR
         bhq3k+mMQnKgfX1K6CICCb/f8tQkzJDZQVx4JRmqm08C7THb7cAfvlQESud0j9Qbe3B2
         NkjNs1JSl/EgX/AgDXrEKzsH4PC29yddpFzyurSQZ5dEO1D8Unn64Hd6TNdVcPNX8WHj
         /ZfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736434255; x=1737039055;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=bQ7O0CTldjygQku2NAoci4VaNDGpPNcndFcs2iZCnSw=;
        b=nU8EproQaR++s/qM3K6Knz6fA6zNL07tlcHvlhizPZOJuVP6H/gVL55rKiJl2XTpx/
         1OkgGLbAPO3dJsoFi2Yxi97AcGTEJpdOebuRXYnnBEuZLvXkX98lhtA64gAeKrW/H+P3
         SnVG3ko4/BNSrNgCJ1IOiw3huL3cSFVdbcgX5Rn1gWQKhl98Xf83sUuYtSy4e+L3uYmd
         1WtKEtoW+KjKo/BplKF0n/JZIeQtdWsyWPGbBr8/luRCNUMItm2BqhYbGxaia7lTW4+6
         vOIgDN7xihtyhkp3wWzRizlz/6JyKvHMPDQOEx0d0r3YgNOBEm0eCYxPrNlSUhHk5pOy
         fWMw==
X-Forwarded-Encrypted: i=1; AJvYcCWug46gYcx/eyOkiC+qXepYRMbRfnTchL9sIP8xOikvkykZENqhwQy5rOgdf/p900j/nBvI8QFDBOY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwAGuOOx7ioECgvRwc6vchrOnAMZjUPSGZ32RcH/1ne0eKHnG4I
	W5XlEMgtgR3UJcgQg1Z1vqYUWpBkQWM/ClpH2q5YVKTOrK6WLpMUT/vGVJe1rw==
X-Gm-Gg: ASbGncvWYSMonPnUlZgP2ckuZBpPf68fTrqQAaSYanvzsMyyjYtEnTmdrczcZpTZPSl
	9qTowH9zo1OgICPfgXiaxm7rVmvlBMtcmf8DDQOw68CQShRG9NFrVQHgou4s8yX7gIfRTPewxo1
	3MFS+tMV+u8S4uNC+kKP0NZOMVtKxnxIdszFyO8BA1fe0w91UprGeWXs7mbze9wqMxIkDQ89v2b
	QQ7FPQ9OM5Fpsi3cectsh3kCTGzCO2CdbSPUkQj8wMixzyR1qonw4vRmAVO6Q+gItp0H+ZqHg+l
	kbLA7Dz/6bCNOiXpmdonsdXo9MmF7nn3ZVCvfoTVsA==
X-Google-Smtp-Source: AGHT+IH4z3Ua3hzqoe9n7js31hgqbC9AGJNy40B3UosLTIFrSbzc2qmvXV2UJ5W6VSy7cUDAeF2W0Q==
X-Received: by 2002:a5d:5f44:0:b0:385:fa33:29ed with SMTP id ffacd0b85a97d-38a8730fa63mr5544550f8f.47.1736434254983;
        Thu, 09 Jan 2025 06:50:54 -0800 (PST)
Message-ID: <74bad181-c8d9-4d4f-b932-8492d1e9d6b1@suse.com>
Date: Thu, 9 Jan 2025 15:50:52 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/boot: adjust text gap/diff to work with 64-bytes
 alignment too
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Frediano Ziglio <frediano.ziglio@cloud.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
References: <20250109131515.1757764-1-marmarek@invisiblethingslab.com>
 <d7421558-c2d6-485b-96bf-927992c5c066@suse.com>
 <47378338-ac05-4041-a055-56045e5ba131@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <47378338-ac05-4041-a055-56045e5ba131@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 09.01.2025 14:44, Andrew Cooper wrote:
> On 09/01/2025 1:23 pm, Jan Beulich wrote:
>> On 09.01.2025 14:15, Marek Marczykowski-Górecki wrote:
>>> Xen compiled with -mtune=generic has .text alignment set to 64-bytes.
>>> Having text_diff non-64-bytes-aligned breaks stuff:
>>>
>>>     Traceback (most recent call last):
>>>       File "/builddir/build/BUILD/xen-4.20.0-build/xen-4.20.0-rc0/xen/./tools/combine_two_binaries.py", line 96, in <module>
>>>         raise Exception('File sizes do not match')
>>>     Exception: File sizes do not match: 70160 != 4080 + 66048
>>>
>>> Adjust the numbers as suggested by Frediano to work with 64-bytes and
>>> even 128-bytes alignment.
>> And then breaking at 256? As indicated on Matrix, imo we should be able to
>> cope with anything up to at least PAGE_SIZE. Or we should reduce .text
>> alignment before linking.
> 
> Do you have a concrete proposal on how to do this?

The latter suggestion would involve objcopy's --set-section-alignment,
the former would involve using constants with the low 12 bits clear.

> Because if not, we've had 2 downstreams hit by this build failure, and
> we probably ought to take this patch as a stopgap fix, and see about
> doing the better fix for 4.20.

4.21 that is, I guess. I never like such very much, because it's too
likely that it'll then be forgotten.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 14:58:27 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 14:58:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868496.1279991 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVtzK-000525-Dh; Thu, 09 Jan 2025 14:58:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868496.1279991; Thu, 09 Jan 2025 14:58:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVtzK-00051y-AM; Thu, 09 Jan 2025 14:58:22 +0000
Received: by outflank-mailman (input) for mailman id 868496;
 Thu, 09 Jan 2025 14:58:21 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=d+9W=UB=intel.com=jani.nikula@srs-se1.protection.inumbo.net>)
 id 1tVtzI-00051s-Ry
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 14:58:21 +0000
Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.10])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2793ecac-ce9a-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 15:58:17 +0100 (CET)
Received: from orviesa005.jf.intel.com ([10.64.159.145])
 by fmvoesa104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 09 Jan 2025 06:58:14 -0800
Received: from unknown (HELO localhost) ([10.237.66.160])
 by orviesa005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 09 Jan 2025 06:58:04 -0800
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2793ecac-ce9a-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=intel.com; i=@intel.com; q=dns/txt; s=Intel;
  t=1736434698; x=1767970698;
  h=from:to:cc:subject:in-reply-to:references:date:
   message-id:mime-version;
  bh=vefbR+WxUsl6W1mxf4BqpYTUFUuz57yEjCw3Nj1MESk=;
  b=T55DTNZSP0PmVh7ZjmvknBInnW1GGzkSwgYaVMeQz2ocZF5jNg4LE9rt
   0F6FCSsTmjcXv/UDVA+0a9Zj1QDeqYohrXNKc5fZYcmehM2Bt8zjv2Iuz
   3dLMf18TGY+JJABAZl5fEEVnfpiuxlqmIzTBkEqluV9bYuHec6Ol50D46
   UKO9bopCJRhgBmpORCCJEBbmYwhDdPRDluv06bi7fcohLSJV8udXpt0Ns
   XH6bz4RzCUc3CipWpP0jcBFaTokSSI0kfpFDTaCHczryTr5awQxjvj43M
   U5H1wjxRxHnoUPs8hRxe2xAn28rYtl2th+UhcQ4XN12l0r5PcfNPV/UBW
   g==;
X-CSE-ConnectionGUID: 5hzTow8ZTJSVzKy4ukQdoQ==
X-CSE-MsgGUID: cgUSS4zXSheBkkeF6IvaEw==
X-IronPort-AV: E=McAfee;i="6700,10204,11310"; a="48110948"
X-IronPort-AV: E=Sophos;i="6.12,301,1728975600"; 
   d="scan'208";a="48110948"
X-CSE-ConnectionGUID: aAxGFyBISeOF2fi1TGSFDw==
X-CSE-MsgGUID: hUbAKolZSWC8NTenKubm+A==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="6.12,224,1728975600"; 
   d="scan'208";a="108527826"
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Joel Granados <joel.granados@kernel.org>, Thomas =?utf-8?Q?Wei=C3=9Fsc?=
 =?utf-8?Q?huh?=
 <linux@weissschuh.net>, Kees Cook <kees@kernel.org>, Luis Chamberlain
 <mcgrof@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
 linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,
 linux-s390@vger.kernel.org, linux-crypto@vger.kernel.org,
 openipmi-developer@lists.sourceforge.net, intel-gfx@lists.freedesktop.org,
 dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
 linux-hyperv@vger.kernel.org, linux-rdma@vger.kernel.org,
 linux-raid@vger.kernel.org, linux-scsi@vger.kernel.org,
 linux-serial@vger.kernel.org, xen-devel@lists.xenproject.org,
 linux-aio@kvack.org, linux-fsdevel@vger.kernel.org, netfs@lists.linux.dev,
 codalist@coda.cs.cmu.edu, linux-mm@kvack.org, linux-nfs@vger.kernel.org,
 ocfs2-devel@lists.linux.dev, fsverity@lists.linux.dev,
 linux-xfs@vger.kernel.org, io-uring@vger.kernel.org, bpf@vger.kernel.org,
 kexec@lists.infradead.org, linux-trace-kernel@vger.kernel.org,
 linux-hardening@vger.kernel.org, apparmor@lists.ubuntu.com,
 linux-security-module@vger.kernel.org, keyrings@vger.kernel.org, Joel
 Granados <joel.granados@kernel.org>
Subject: Re: [PATCH] treewide: const qualify ctl_tables where applicable
In-Reply-To: <20250109-jag-ctl_table_const-v1-1-622aea7230cf@kernel.org>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
References: <20250109-jag-ctl_table_const-v1-1-622aea7230cf@kernel.org>
Date: Thu, 09 Jan 2025 16:58:01 +0200
Message-ID: <87frlsjapy.fsf@intel.com>
MIME-Version: 1.0
Content-Type: text/plain

On Thu, 09 Jan 2025, Joel Granados <joel.granados@kernel.org> wrote:
> diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
> index 2406cda75b7b..5384d1bb4923 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -4802,7 +4802,7 @@ int i915_perf_remove_config_ioctl(struct drm_device *dev, void *data,
>  	return ret;
>  }
>  
> -static struct ctl_table oa_table[] = {
> +static const struct ctl_table oa_table[] = {
>  	{
>  	 .procname = "perf_stream_paranoid",
>  	 .data = &i915_perf_stream_paranoid,

For i915,

Acked-by: Jani Nikula <jani.nikula@intel.com>


-- 
Jani Nikula, Intel


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 14:58:33 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 14:58:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868498.1280001 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVtzV-0005LJ-K5; Thu, 09 Jan 2025 14:58:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868498.1280001; Thu, 09 Jan 2025 14:58:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVtzV-0005LC-HB; Thu, 09 Jan 2025 14:58:33 +0000
Received: by outflank-mailman (input) for mailman id 868498;
 Thu, 09 Jan 2025 14:58:32 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=bl7y=UB=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tVtzU-0005Ka-Jh
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 14:58:32 +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 3107f575-ce9a-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 15:58:31 +0100 (CET)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-436202dd730so8127335e9.2
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 06:58:31 -0800 (PST)
Received: from localhost ([66.81.170.107]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a8e4b81a4sm2074055f8f.68.2025.01.09.06.58.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 06:58:30 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 3107f575-ce9a-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736434711; x=1737039511; darn=lists.xenproject.org;
        h=in-reply-to:references:subject:cc:to:from:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=wIHtCee8g74rYH44CdFX4zt4/GVSLWGVRC0fcWc0PGM=;
        b=BxObF20Uynyv8OCz8Qip66c/JZ4S1ztocE1ELAvdwfOzlhO6UY8yC7JOTncyz5VS4Y
         pau9g++RvCO2wOmu72/01ITe8IKNU2o8ifajw9noJBzUcwZlGk7KAuxYPrvlV+OGVOdG
         d1zucIMrUadHEhTwLxuCQHpMLvOKuQe2+BAQ4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736434711; x=1737039511;
        h=in-reply-to:references:subject:cc:to:from:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=wIHtCee8g74rYH44CdFX4zt4/GVSLWGVRC0fcWc0PGM=;
        b=C8TTdqeykTLt1fuKuwl0nMChtkl8fOH18mSW/YtUwh6Xg6ynjQnG+7h0DBF7IzZkdz
         KhwHqCAE2tvJvHOs2Mb9Hh585McoS/UWGCFd9h6DqLfYy6viMhYCg+uOVhr+Cmv3ze3G
         9ihw+WYQqTJG+D/FRRg4KZuqzgQ+3FuIGx9KwXE6PFK4OBeDjYlwPLAJpxLN4utiUf+i
         yTZzxo2WzvWjKPocosSlRt/ofTvLj9bD8KXPrCNYfQSPQsdX7ZODQLghLt6dkF9MfpMs
         OQuQmz9YUfXbWITrfsLRMOk/NwMAfxhw5ujqdqpCJvr5HB6U9sevvpSqda5RaQPqB2Y1
         ggfg==
X-Forwarded-Encrypted: i=1; AJvYcCX1+dS3TZwm69TUEnEwhtIL2Wg2OI6rlFKpJr8vR3hGtxZijDhkP3aHK26mPEgV1omnGHGuZEsqXCE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyECJKhgw+WBifrNvVxvhomRu/RCK50bQqzgwJCy2d0EJxItXvO
	CxgFIQGqXsLF5QoHqjQbK9Ey9TNSkZznh1dVkp9Su0/Nntcl7ClXlFvGToOEJRc=
X-Gm-Gg: ASbGncsR3vjySuAyQLK10GH15DNCaGrJ+gXVsqaDSgdp4bu7jR34No223GA1uZTKKew
	GMNwq/d4E+N7JtdOZa25n40R0kjS2VIBT4PSyZDPVIxWsEq5F804+c9w1sfNhDH+QOAfv1l2n0M
	qSx/RXrCU9m9eUXkRWliqO2zQsKvoCPAmmuWWU1poQXC9n7OEfg74iZOdSI78fQnXnah7PrpzyQ
	d3iCl+/jeT9F3veB7sS96P+gL+ipB8zvwuWjdDBjVIFJT6AdDJX7rLIZP6+mx4=
X-Google-Smtp-Source: AGHT+IHeLofrEONqwfSXz84WNyTBj7fulmWfkKJdK9d3DutVFytCqx8AUo/ouTN2xB5jqPb44r2CgQ==
X-Received: by 2002:a05:6000:1a8d:b0:385:ed1e:2105 with SMTP id ffacd0b85a97d-38a8730ae10mr6407064f8f.26.1736434710999;
        Thu, 09 Jan 2025 06:58:30 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Thu, 09 Jan 2025 14:58:29 +0000
Message-Id: <D6XMQD34DXRE.24L7RC2WUI298@cloud.com>
From: "Alejandro Vallejo" <alejandro.vallejo@cloud.com>
To: "Roger Pau Monne" <roger.pau@citrix.com>,
 <xen-devel@lists.xenproject.org>
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>, "Anthony PERARD"
 <anthony.perard@vates.tech>, "Michal Orzel" <michal.orzel@amd.com>, "Jan
 Beulich" <jbeulich@suse.com>, "Julien Grall" <julien@xen.org>, "Stefano
 Stabellini" <sstabellini@kernel.org>
Subject: Re: [PATCH v2 13/18] x86/spec-ctrl: introduce Address Space
 Isolation command line option
X-Mailer: aerc 0.18.2
References: <20250108142659.99490-1-roger.pau@citrix.com>
 <20250108142659.99490-14-roger.pau@citrix.com>
In-Reply-To: <20250108142659.99490-14-roger.pau@citrix.com>

On Wed Jan 8, 2025 at 2:26 PM GMT, Roger Pau Monne wrote:
> No functional change, as the option is not used.
>
> Introduced new so newly added functionality is keyed on the option being
> enabled, even if the feature is non-functional.
>
> When ASI is enabled for PV domains, printing the usage of XPTI might be
> omitted if it must be uniformly disabled given the usage of ASI.
>
> Signed-off-by: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
> ---
> Changes since v1:
>  - Improve comments and documentation about what ASI provides.
>  - Do not print the XPTI information if ASI is used for pv domUs and dom0=
 is
>    PVH, or if ASI is used for both domU and dom0.
>
> FWIW, I would print the state of XPTI uniformly, as otherwise I find the =
output
> might be confusing for user expecting to assert the state of XPTI.
> ---
>  docs/misc/xen-command-line.pandoc    |  19 +++++
>  xen/arch/x86/include/asm/domain.h    |   3 +
>  xen/arch/x86/include/asm/spec_ctrl.h |   2 +
>  xen/arch/x86/spec_ctrl.c             | 115 +++++++++++++++++++++++++--
>  4 files changed, 133 insertions(+), 6 deletions(-)
>
> diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-li=
ne.pandoc
> index 08b0053f9ced..3c1ad7b5fe7d 100644
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -202,6 +202,25 @@ to appropriate auditing by Xen.  Argo is disabled by=
 default.
>      This option is disabled by default, to protect domains from a DoS by=
 a
>      buggy or malicious other domain spamming the ring.
> =20
> +### asi (x86)
> +> `=3D List of [ <bool>, {pv,hvm}=3D<bool>,
> +               {vcpu-pt}=3D<bool>|{pv,hvm}=3D<bool> ]`

nit: While this grows later, the braces around vcpu-pt aren't strictly need=
ed here.

> +
> +Offers control over whether the hypervisor will engage in Address Space
> +Isolation, by not having potentially sensitive information permanently m=
apped
> +in the VMM page-tables.  Using this option might avoid the need to apply
> +mitigations for certain speculative related attacks, at the cost of mapp=
ing
> +sensitive information on-demand.

Might be worth mentioning that this provides some defense in depth against
unmitigated attacks too.

> +
> +* `pv=3D` and `hvm=3D` sub-options allow enabling for specific guest typ=
es.
> +
> +**WARNING: manual de-selection of enabled options will invalidate any
> +protection offered by the feature.  The fine grained options provided be=
low are
> +meant to be used for debugging purposes only.**
> +
> +* `vcpu-pt` ensure each vCPU uses a unique top-level page-table and setu=
p a
> +  virtual address space region to map memory on a per-vCPU basis.
> +
>  ### asid (x86)
>  > `=3D <boolean>`
> =20
> diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
> index ced84750015c..9463a8624701 100644
> --- a/xen/arch/x86/spec_ctrl.c
> +++ b/xen/arch/x86/spec_ctrl.c
> @@ -2075,6 +2165,19 @@ void __init init_speculation_mitigations(void)
>           hw_smt_enabled && default_xen_spec_ctrl )
>          setup_force_cpu_cap(X86_FEATURE_SC_MSR_IDLE);
> =20
> +    /* Disable all ASI options by default until feature is finished. */
> +    if ( opt_vcpu_pt_pv =3D=3D -1 )
> +        opt_vcpu_pt_pv =3D 0;
> +    if ( opt_vcpu_pt_hwdom =3D=3D -1 )
> +        opt_vcpu_pt_hwdom =3D 0;
> +    if ( opt_vcpu_pt_hvm =3D=3D -1 )
> +        opt_vcpu_pt_hvm =3D 0;

Why not preinitialise them to zero instead in the static declarations?

> +
> +    if ( opt_vcpu_pt_pv || opt_vcpu_pt_hvm )
> +        warning_add(
> +            "Address Space Isolation is not functional, this option is\n=
"
> +            "intended to be used only for development purposes.\n");
> +
>      xpti_init_default();
> =20
>      l1tf_calculations();

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:01:32 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:01:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868511.1280010 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVu2N-0007R5-0f; Thu, 09 Jan 2025 15:01:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868511.1280010; Thu, 09 Jan 2025 15:01:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVu2M-0007Qy-Tu; Thu, 09 Jan 2025 15:01:30 +0000
Received: by outflank-mailman (input) for mailman id 868511;
 Thu, 09 Jan 2025 15:01:29 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=CWvZ=UB=oracle.com=martin.petersen@srs-se1.protection.inumbo.net>)
 id 1tVu2L-0007Qs-GZ
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:01:29 +0000
Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com
 [205.220.165.32]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 995b521d-ce9a-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 16:01:27 +0100 (CET)
Received: from pps.filterd (m0333521.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 509CfnEU010941;
 Thu, 9 Jan 2025 15:00:54 GMT
Received: from iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com
 (iadpaimrmta03.appoci.oracle.com [130.35.103.27])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 43xuwb95dc-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Thu, 09 Jan 2025 15:00:53 +0000 (GMT)
Received: from pps.filterd
 (iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
 by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.2/8.18.1.2)
 with ESMTP id 509EQ3lm010865; Thu, 9 Jan 2025 15:00:52 GMT
Received: from nam04-bn8-obe.outbound.protection.outlook.com
 (mail-bn8nam04lp2042.outbound.protection.outlook.com [104.47.74.42])
 by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id
 43xueb1ah4-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Thu, 09 Jan 2025 15:00:52 +0000
Received: from CH0PR10MB5338.namprd10.prod.outlook.com (2603:10b6:610:cb::8)
 by SN7PR10MB7001.namprd10.prod.outlook.com (2603:10b6:806:345::11) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8335.10; Thu, 9 Jan
 2025 15:00:49 +0000
Received: from CH0PR10MB5338.namprd10.prod.outlook.com
 ([fe80::5cca:2bcc:cedb:d9bf]) by CH0PR10MB5338.namprd10.prod.outlook.com
 ([fe80::5cca:2bcc:cedb:d9bf%6]) with mapi id 15.20.8335.012; Thu, 9 Jan 2025
 15:00:49 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 995b521d-ce9a-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-type:date:from:in-reply-to:message-id:mime-version
	:references:subject:to; s=corp-2023-11-20; bh=jMUptaI9fqg5+RUs+I
	vqiL3lFR7AmqejQbFAnHpRhQc=; b=ZKLqGfAlKID2gYfwuP+LlcWuWqkWRhqfLC
	4bMhKd4WlYQVAjthTvyZqd0q7fioOBZdzjqHs/jv2ywfetWrPXV06bV9X4G/Ycfl
	wbYtAciZa6qM0+dDNx14odAb5sY+rDbk/iViTIp6ARSA5g9oWtXwya4FY6wpHzHa
	EN0aiJ6II3L6JnL1fIMMhPI3o6/ZesY2Ery53T5MKvPRXupL86Fd/A6dYZ8CtIML
	W08wSLa7uBN+faiccwo5qvsrhFJX3XnULycouwCV/SyvUagLteCJ0/ZIg2AmADCi
	QJ/0Y+2uU6lYLBQcRj1gAA22kdqSD0a3GJDtLzuxe0cWa/iCgm1A==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=lCFpDHOQhu6xZGt6Sa3mc5WvDHjASrjznsuq3pa9/8gRdKM6+Oy4KZVZGtccD1klyRCKYI4s8NOj3rMlYqtCJQPk3q1RISpnRy0RXOtoz6iBIkBfzQf490DydD1ecW+HLd+tJUy5lJcomhb1wgaebFs/kfxyXocJpyxECvDWC+NDr6usPFLqUXwnqVD0dEgsXNRZ8NHjW8DBk7KM1OgrnCKY77Qk91Et3w3KGd+LAp0s1FEiyk+5RbF8u1SX/vCVYQZ19qR6x3bRXsC0PCOXHtrkysizcmdFRJd04JLEHuK2Yu9Ptt5zXej8v7Q9vRrlM2p/ybIe52aAo73idrKTfw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=jMUptaI9fqg5+RUs+IvqiL3lFR7AmqejQbFAnHpRhQc=;
 b=BMRs0/8tL8b3tWch/NJTK/7Pz9rctGrgpf95IuDWE2UOD/7YrppNXhigasORdyjo1UCOFDnODQoI2KqKFmjaxxdPDEGHRhva9ryzSach02Jm1omjqFEhffSxDUXuttDqIVzBg7b2PV/2ZUPXq/MJZuOdhitBXEBQk7l7AeZBf10R4NklOWqWiMRgTYmSrbog0+lcP3fn8KmjjBqcV1AKpq9cQp50h5Wozhz1q0Wp5Xn2e50Bzy/5F8exuPXBvsIDHmmf1lHUwftYWW5Kmmb18hbNBF6GeWJ2y3392RUvdcStbWubWJDRNBfieOzMRm3dszF9MnF4zCucKWSAiIQLRg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
 dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=jMUptaI9fqg5+RUs+IvqiL3lFR7AmqejQbFAnHpRhQc=;
 b=OrOCCYEBQosTxVVlFghCyGRnSbxwjYNaQBAUHfLPuEhq6USvwVdXmhomijJ2+HEcDnpL+oYdBas0Ko8OQ+Xv4KVr4i+i8oQv9xnL8WUxMcGiDrmVQOfh5BibsNN0vr637OmP1k3h778mNsH+Gk42K9EKIEr5HU0jdteeSRM6tsU=
To: Joel Granados <joel.granados@kernel.org>
Cc: Thomas =?utf-8?Q?Wei=C3=9Fschuh?= <linux@weissschuh.net>,
        Kees Cook
 <kees@kernel.org>, Luis Chamberlain <mcgrof@kernel.org>,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
        linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,
        linux-s390@vger.kernel.org, linux-crypto@vger.kernel.org,
        openipmi-developer@lists.sourceforge.net,
        intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
        intel-xe@lists.freedesktop.org, linux-hyperv@vger.kernel.org,
        linux-rdma@vger.kernel.org, linux-raid@vger.kernel.org,
        linux-scsi@vger.kernel.org, linux-serial@vger.kernel.org,
        xen-devel@lists.xenproject.org, linux-aio@kvack.org,
        linux-fsdevel@vger.kernel.org, netfs@lists.linux.dev,
        codalist@coda.cs.cmu.edu, linux-mm@kvack.org,
        linux-nfs@vger.kernel.org, ocfs2-devel@lists.linux.dev,
        fsverity@lists.linux.dev, linux-xfs@vger.kernel.org,
        io-uring@vger.kernel.org, bpf@vger.kernel.org,
        kexec@lists.infradead.org, linux-trace-kernel@vger.kernel.org,
        linux-hardening@vger.kernel.org, apparmor@lists.ubuntu.com,
        linux-security-module@vger.kernel.org, keyrings@vger.kernel.org
Subject: Re: [PATCH] treewide: const qualify ctl_tables where applicable
From: "Martin K. Petersen" <martin.petersen@oracle.com>
In-Reply-To: <20250109-jag-ctl_table_const-v1-1-622aea7230cf@kernel.org> (Joel
	Granados's message of "Thu, 09 Jan 2025 14:16:39 +0100")
Organization: Oracle Corporation
Message-ID: <yq1ed1c823x.fsf@ca-mkp.ca.oracle.com>
References: <20250109-jag-ctl_table_const-v1-1-622aea7230cf@kernel.org>
Date: Thu, 09 Jan 2025 10:00:46 -0500
Content-Type: text/plain
X-ClientProxiedBy: SJ2PR07CA0015.namprd07.prod.outlook.com
 (2603:10b6:a03:505::28) To CH0PR10MB5338.namprd10.prod.outlook.com
 (2603:10b6:610:cb::8)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH0PR10MB5338:EE_|SN7PR10MB7001:EE_
X-MS-Office365-Filtering-Correlation-Id: 57ca7bf9-9646-491b-b6df-08dd30be6736
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|7416014|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?1s5eliMSE67bSIt5uQKs2IcnP+0PNCj0WZFBBku5t3uvZomcBm6xiJzzqgmI?=
 =?us-ascii?Q?+XHPLdw+eszd1/QyQrJPQNTTQGoQ0r6A7EHV4YmnZxrMySwRwTMKbnLRjstN?=
 =?us-ascii?Q?jPHt9B18dW5Jc4xUXfLdJMTzatVzshMrKqA/ohaLOkvQRuMJS1QLxJyXvUeb?=
 =?us-ascii?Q?vv5bbjR698U6ikpCZ+PLDFxq5eQ7AZjJs7PdjSCX0pwbzzxDimK80RdbgWGf?=
 =?us-ascii?Q?0AroawK83y5svXx6thDxQjQgBnz4+K64uryopn61Qr46+fQoncUV5i3LKKkg?=
 =?us-ascii?Q?2dOj2x107aOMexqiLArcaMJw7RMKWKtjw8KPvref/3xYIQWalB5vv5y/sn9G?=
 =?us-ascii?Q?hvSfmB3g09Thi1y40nIwusr8OgBFBlSWfJsdvUnZn80PdR1vWrqXTbMJovp1?=
 =?us-ascii?Q?ocEfIVEqBsppyY1WVbmKSpEqYmMlxiIGDBnF8F0p5CrEnsAvXB7Zpi9GuhiH?=
 =?us-ascii?Q?OcbJRt8veDrcu84G9H9eshJunDn9D/un02cG6x8/lMF7M2vd2XL+hW3HGmjL?=
 =?us-ascii?Q?ytkwL/frvsBE/nhleo7zBNXarmoxAtTjjPvSSrMf5F4mVADVMgL30MERFK95?=
 =?us-ascii?Q?1iiHhz1qvu8Ou1hlsxWqHLO90O4fSUounpfRNbzEuRbhIQvel4J+m7ZHXb2m?=
 =?us-ascii?Q?iekRVTSZBCwbNUinUi3LYCfHeBkXjcK3dPKFVFZjUVBmC2LrOrV2nHDtOG3i?=
 =?us-ascii?Q?q2X3joQYJ/tcR9bDhRPZ5tlRikiBOT7VE3yURFC3rNNCZUEa+hOxNFvbYkrS?=
 =?us-ascii?Q?nl5WnQdvm2IM3bafp7Vo+6wNAMuCI3wZQs6j4eAGqKN0KEU0S1Dxh70d4axv?=
 =?us-ascii?Q?H4wTt1q7pr28TlIFNl0PfctPMmHJBdcJaHzBvbNTo5KVYsucjQxhxmDNUVqr?=
 =?us-ascii?Q?8StZ2Vkasxkex+OFgjsBcMUDTR8B2qFSb/MRPh3Rh1+WcbkCGcwPup6I8zpJ?=
 =?us-ascii?Q?1HjTT/a+amAxP4yi/sW4j8pWYTBx2CZIy10YJ8Tbdydy/HH8iekZVSEzxBqn?=
 =?us-ascii?Q?Jv47TpOuTl9MigO3m6ov/6gf71YaU2xnC1/mmgej/oy+twi3Uvr1RJn3ptNg?=
 =?us-ascii?Q?g2cA+a6gKL3SYY9phppNZAe/eEHK1wsx7dhMve3MOpgxGW2qmGa2yQc9AsJO?=
 =?us-ascii?Q?WvFu0MdkMAVN0hJiyMVjuhzicu583QJ58PtDQibgopUVAbCmGMakal+G1RxB?=
 =?us-ascii?Q?HviCgXT+W/c8i1o3H/BGd65sJtxQkFz+3gWKKrITHpS5j7KccnOZj41Sd+6O?=
 =?us-ascii?Q?b6V0wjDzzI1q6lMPVkHyd2rO1/CRq0b8VAvxZWU0oj1z2DJaqoWumNSbr7R6?=
 =?us-ascii?Q?i+w2GAokUpbp82H6N/M8tL4IKOntd5dzeuv1zxQP35Rv6TkvI/xFtagtT+Hc?=
 =?us-ascii?Q?IGINZ4zJUJZy40/LyzmX2agqnz3K?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH0PR10MB5338.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(7416014)(1800799024);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?WZNn6E1Pa7bGKzLrcJDJZOlfoqcHArJ/1AObxs3buzZgzUpMr8lBMjhap0F9?=
 =?us-ascii?Q?mYMw0mCidu5gzvLAi8PBvxj0uhCHw9K3LgPDSnmUwTYcICw856X+uMf30Tho?=
 =?us-ascii?Q?3FDT/VmGo38Jwp53p8Bfm8qyxp/0LytCAwqwBlGP8VB6MT1LnVmLBLM9uRvY?=
 =?us-ascii?Q?kA3haz6zRHG5ZBQPXop+/6efFgCuyLTz9CCNFA4e0Z8WgSAgJKsQrMsQSN1j?=
 =?us-ascii?Q?qfd2Nxs2aS9uWBaVrZLtVdaco5UmKyhfMudR9asTb3S+nIh/A0o88X3cMlJ8?=
 =?us-ascii?Q?7qQlUIfjM8/WIj3VP4zsJLfxe4UKkL8OnT9BcfIS9GZwhaGqGbKbR+D3jtof?=
 =?us-ascii?Q?rp0tMONITtuY4+MGPUBAtzGYkYwW/6GaTFOibH9vZ0arw4NzmWgaOv8JtRjO?=
 =?us-ascii?Q?oM27MHfMuLwrHzGtM2pe5ezq5WyS6/bWGLo/JLtWb85ItRkBNeGKgSFNXdWj?=
 =?us-ascii?Q?K0WkUnbkLQ3erszvL93qxuLf36uMCiQIrjvziGhCA0AJYJ8O2Q4iV0QYWIWH?=
 =?us-ascii?Q?vxP7YlUjTCdESdXhxyN+z6WxZrd/O3bV77dfkk+l8RfodLl4dMIl3XCHazSZ?=
 =?us-ascii?Q?tNY19C1vkXbpHjyJagJ+Kipdphsm5Nfk029iSFbb7S+qG2POw2Z7OYg6MWLx?=
 =?us-ascii?Q?2KnKr668r8F8/DvynAy2zKi94Zfc+Ex6Ca8HiKQI55EMeIwKnauWfEmXqPEP?=
 =?us-ascii?Q?ybf1A+fy7vO52eWYrVIf/K58IT8RbOy9sXBULZpmF5XaQHLX3KE0Oz9USdQ6?=
 =?us-ascii?Q?YjQngikYaXNrgzbXf8Wsc/skw1gx+kck/Isa2JhBRBShgN8p9WZMyCn6gBw7?=
 =?us-ascii?Q?gZeqcEstNVEKVKK2fGZpkEEqQhmXBcVYFDjY0YvaM5Ceb36ussgJb9YzuNM+?=
 =?us-ascii?Q?zNMSL9o2Rf/sy+xyqe4MTCL8lykXCFbysWguFjNzmXidVzssSDfRv86/cWR+?=
 =?us-ascii?Q?yDIFJpwzweS2h7eoqDO42g0M2HJF2SC0eGjcs5wKAZB13Qj7CyhK7NED+ynV?=
 =?us-ascii?Q?9Q+gNeBoZknbT1X1wZqhrHD5nU+0VQpEhGVKoTYqYp7CRWmdcB6OoMUyXEL6?=
 =?us-ascii?Q?qcQsmxq1otuQP6/vvFXSBbEdxHvE1fIli8t4pxe4PE57V2sHk6djEeRDXxxZ?=
 =?us-ascii?Q?KE0gE0FpKS75eQDRfCZM6yiSgfEs181Te4+8TJpTQ7/2MIVZHG4DkZvtF8In?=
 =?us-ascii?Q?tJrfIrZnPLTE7hb5rdomq6StRLsCkRDPbxpgS4s63GjDXzeI8a7kF6is6GQe?=
 =?us-ascii?Q?MoFw9u2F5ger1qJ30DJuI6ISnVE17NaPINaCxiXeNqNwSfjfizMnMXBRGhwy?=
 =?us-ascii?Q?23RsyQHncvlXPZvcSYXA4FijIuCYOrky+B7oUBqSgdI9fRP84jQbXI/OJDx2?=
 =?us-ascii?Q?uz9U6vTi0uB1nHn6NCs1aOAac2w28+og4LYyE/9//S3ek+8P6IlaDGipvKYV?=
 =?us-ascii?Q?QagAbCVxdUi7LZDS+55o4HF/1TiL5nCXySk+mRU9ASBwxtuDZsf+OPpiIJeJ?=
 =?us-ascii?Q?tH2ppTFQ8SV9JH39LgIEe3yoPCXUojgQHKGRFVPAnLGqFj/Wy9p8fGHjvKCY?=
 =?us-ascii?Q?dxwuK/flWMBwLr1owtHdeGOzFj+sbzhcHME3fP5Sd5WDvk6BgqYwvUYSM3Vu?=
 =?us-ascii?Q?fw=3D=3D?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	Z2ezp0GeC+tCAty8oNhH+Bxy14WAfO6YLudztqZns732Dr0QNSgcWLPMEb56XKYzxsISMSnUx1GkxolfLHx8QwH3aPViqoqQPRniwzxVRHjbJRNQSnKucs2z/YFx9ssTzXfjE0G3Qi9taDO5X17op/ReRjMnQ2OQAduZfRc9Qqy3JDI/0eXh2ZWUSh0+GDq+BQKFROJVrTHTnW2o6xNdER+888B1/cz+pmLrD0EvYPmvjrCKQBpkGB8IZYwKuLCB4t0pzswCmFKAxhxYYTuLhER6orCrIWpsZoXZxRqwUfindm1PxU+UfzvfK2NCcRyOazoVvYNENj9yXk3leqQ6Y8l2ijF/gdhZzD/fZZQYvnAc7LEKfcXFULkUL9vbaZTMBWRUAXJuAW0gRCuvA9deA1xfXb8yzPHxOiszwK+r2qgMTA5ec9WUelk3pY8aeq3FQnHvnKk8ooLyMCpeUisQFjoKRzVWGyRWQ8J6T5YYj+xGYdFi0F9jGWX83dtphIz6bHam3CAuzy/gpWh1k+to6CNnv2uO6iwMHozr7LpA+r9oYSwJ8o1AN8jws6/8kVKYGulR99qsLzEvnjqFQNQsyA96ngiGqmo6v1xIeg2yoiU=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 57ca7bf9-9646-491b-b6df-08dd30be6736
X-MS-Exchange-CrossTenant-AuthSource: CH0PR10MB5338.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jan 2025 15:00:49.1161
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: leHSaRakdAn44d9JTPJGGjwmkjIzP6V+HUsYDpT9nyRHh5QA3A00LFHg8x0aOHYjIzoJs/bIHXolJQXc/ZKEsw5B5oXtdGA/kAFQ3UU4rdI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR10MB7001
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34
 definitions=2025-01-09_06,2025-01-09_01,2024-11-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 malwarescore=0
 adultscore=0 mlxlogscore=811 suspectscore=0 mlxscore=0 spamscore=0
 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2411120000 definitions=main-2501090120
X-Proofpoint-GUID: ujTpPHVSX-fTLPpls6O5X7zV8q5ouFNE
X-Proofpoint-ORIG-GUID: ujTpPHVSX-fTLPpls6O5X7zV8q5ouFNE


Joel,

> Add the const qualifier to all the ctl_tables in the tree except the
> ones in ./net dir. The "net" sysctl code is special as it modifies the
> arrays before passing it on to the registration function.

Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> # SCSI

-- 
Martin K. Petersen	Oracle Linux Engineering


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:03:19 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:03:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868518.1280021 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVu46-000801-BN; Thu, 09 Jan 2025 15:03:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868518.1280021; Thu, 09 Jan 2025 15:03:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVu46-0007zu-7o; Thu, 09 Jan 2025 15:03:18 +0000
Received: by outflank-mailman (input) for mailman id 868518;
 Thu, 09 Jan 2025 15:03:17 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=BoWZ=UB=suse.de=tzimmermann@srs-se1.protection.inumbo.net>)
 id 1tVu44-0007zg-VX
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:03:17 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id da931cb2-ce9a-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 16:03:16 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id 92E3D21170;
 Thu,  9 Jan 2025 15:03:15 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 10A3313A8B;
 Thu,  9 Jan 2025 15:03:15 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id EKDFAjPlf2c1awAAD6G6ig
 (envelope-from <tzimmermann@suse.de>); Thu, 09 Jan 2025 15:03:15 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: da931cb2-ce9a-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736434995; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=XMCayXhRlBVa7gMSmx9Hm+JQPMIVdDIzBmzoFhpmu5s=;
	b=Hurt5FPj5gtaGEl7MDFSQr1yjZpTEsC59BHG4sl81e51YGBC1DQIeo8AcObIbwo3t1kyRW
	BoqzmGAdtH46F1MufUgfFbbg/C7zFLSZhK9CXwNfpYpAx4oe2AgI1X0BqlOkTxLKoGlfvj
	H4t8+YaDtL6zM63SXCatuXM7OGJUdYA=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736434995;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=XMCayXhRlBVa7gMSmx9Hm+JQPMIVdDIzBmzoFhpmu5s=;
	b=P7GWPruItIQO/YAmOqVTUNOjEqq6hDn8OMiNUSeBq67Bbmrby9vvRjHdXPPWPM4dSAmLLz
	TXrcaqcF+IF2ulCg==
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736434995; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=XMCayXhRlBVa7gMSmx9Hm+JQPMIVdDIzBmzoFhpmu5s=;
	b=Hurt5FPj5gtaGEl7MDFSQr1yjZpTEsC59BHG4sl81e51YGBC1DQIeo8AcObIbwo3t1kyRW
	BoqzmGAdtH46F1MufUgfFbbg/C7zFLSZhK9CXwNfpYpAx4oe2AgI1X0BqlOkTxLKoGlfvj
	H4t8+YaDtL6zM63SXCatuXM7OGJUdYA=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736434995;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=XMCayXhRlBVa7gMSmx9Hm+JQPMIVdDIzBmzoFhpmu5s=;
	b=P7GWPruItIQO/YAmOqVTUNOjEqq6hDn8OMiNUSeBq67Bbmrby9vvRjHdXPPWPM4dSAmLLz
	TXrcaqcF+IF2ulCg==
From: Thomas Zimmermann <tzimmermann@suse.de>
To: maarten.lankhorst@linux.intel.com,
	mripard@kernel.org,
	airlied@gmail.com,
	simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann <tzimmermann@suse.de>
Subject: [PATCH v2 01/25] drm/dumb-buffers: Sanitize output on errors
Date: Thu,  9 Jan 2025 15:56:55 +0100
Message-ID: <20250109150310.219442-2-tzimmermann@suse.de>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250109150310.219442-1-tzimmermann@suse.de>
References: <20250109150310.219442-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Level: 
X-Spamd-Result: default: False [-1.30 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_COUNT_TWO(0.00)[2];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[19];
	MIME_TRACE(0.00)[0:+];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	FREEMAIL_TO(0.00)[linux.intel.com,kernel.org,gmail.com,ffwll.ch];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,suse.de:email,suse.de:mid];
	TO_DN_SOME(0.00)[];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-Spam-Score: -1.30
X-Spam-Flag: NO

The ioctls MODE_CREATE_DUMB and MODE_MAP_DUMB return results into a
memory buffer supplied by user space. On errors, it is possible that
intermediate values are being returned. The exact semantics depends
on the DRM driver's implementation of these ioctls. Although this is
most-likely not a security problem in practice, avoid any uncertainty
by clearing the memory to 0 on errors.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
 drivers/gpu/drm/drm_dumb_buffers.c | 40 ++++++++++++++++++++++--------
 1 file changed, 29 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_dumb_buffers.c b/drivers/gpu/drm/drm_dumb_buffers.c
index 70032bba1c97..9916aaf5b3f2 100644
--- a/drivers/gpu/drm/drm_dumb_buffers.c
+++ b/drivers/gpu/drm/drm_dumb_buffers.c
@@ -99,7 +99,30 @@ int drm_mode_create_dumb(struct drm_device *dev,
 int drm_mode_create_dumb_ioctl(struct drm_device *dev,
 			       void *data, struct drm_file *file_priv)
 {
-	return drm_mode_create_dumb(dev, data, file_priv);
+	struct drm_mode_create_dumb *args = data;
+	int err;
+
+	err = drm_mode_create_dumb(dev, args, file_priv);
+	if (err) {
+		args->handle = 0;
+		args->pitch = 0;
+		args->size = 0;
+	}
+	return err;
+}
+
+static int drm_mode_mmap_dumb(struct drm_device *dev, struct drm_mode_map_dumb *args,
+			      struct drm_file *file_priv)
+{
+	if (!dev->driver->dumb_create)
+		return -ENOSYS;
+
+	if (dev->driver->dumb_map_offset)
+		return dev->driver->dumb_map_offset(file_priv, dev, args->handle,
+						    &args->offset);
+	else
+		return drm_gem_dumb_map_offset(file_priv, dev, args->handle,
+					       &args->offset);
 }
 
 /**
@@ -120,17 +143,12 @@ int drm_mode_mmap_dumb_ioctl(struct drm_device *dev,
 			     void *data, struct drm_file *file_priv)
 {
 	struct drm_mode_map_dumb *args = data;
+	int err;
 
-	if (!dev->driver->dumb_create)
-		return -ENOSYS;
-
-	if (dev->driver->dumb_map_offset)
-		return dev->driver->dumb_map_offset(file_priv, dev,
-						    args->handle,
-						    &args->offset);
-	else
-		return drm_gem_dumb_map_offset(file_priv, dev, args->handle,
-					       &args->offset);
+	err = drm_mode_mmap_dumb(dev, args, file_priv);
+	if (err)
+		args->offset = 0;
+	return err;
 }
 
 int drm_mode_destroy_dumb(struct drm_device *dev, u32 handle,
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:03:19 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:03:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868519.1280031 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVu47-0008Eq-ON; Thu, 09 Jan 2025 15:03:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868519.1280031; Thu, 09 Jan 2025 15:03:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVu47-0008Ej-JO; Thu, 09 Jan 2025 15:03:19 +0000
Received: by outflank-mailman (input) for mailman id 868519;
 Thu, 09 Jan 2025 15:03:17 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=BoWZ=UB=suse.de=tzimmermann@srs-se1.protection.inumbo.net>)
 id 1tVu45-0007zg-L6
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:03:17 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id da42cba4-ce9a-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 16:03:15 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id 0B36C21173;
 Thu,  9 Jan 2025 15:03:15 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 84E9E139AB;
 Thu,  9 Jan 2025 15:03:14 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id 8o8oHzLlf2c1awAAD6G6ig
 (envelope-from <tzimmermann@suse.de>); Thu, 09 Jan 2025 15:03:14 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: da42cba4-ce9a-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736434995; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding;
	bh=ayMP9fgai3U2SRutfILrxld66PrmIAS8Xan8q+cw9vU=;
	b=mcNhyiMPnM+4j1AopsnKFUXAyXxBjIEzkwkM4SaRb6QPomPzcXjJDSMydwiTkaeendLYuu
	onTUMYPgd6lz099mNddFue/NFvbfZw/FP74gYFtSuDhctKd0uALTn8tGhNEcH/JRxCAJnv
	JMpR9FHiaNMB4stMe8C0ZyObftX5iQM=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736434995;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding;
	bh=ayMP9fgai3U2SRutfILrxld66PrmIAS8Xan8q+cw9vU=;
	b=gptbxtyjgUS1zD900ZGA6biMREqapnx6iFpYtdoWkt0TK2hXPI337A2feZfbCYmSM5mS2P
	no98HSzI83Q0NVCA==
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.de header.s=susede2_rsa header.b=mcNhyiMP;
	dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=gptbxtyj
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736434995; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding;
	bh=ayMP9fgai3U2SRutfILrxld66PrmIAS8Xan8q+cw9vU=;
	b=mcNhyiMPnM+4j1AopsnKFUXAyXxBjIEzkwkM4SaRb6QPomPzcXjJDSMydwiTkaeendLYuu
	onTUMYPgd6lz099mNddFue/NFvbfZw/FP74gYFtSuDhctKd0uALTn8tGhNEcH/JRxCAJnv
	JMpR9FHiaNMB4stMe8C0ZyObftX5iQM=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736434995;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding;
	bh=ayMP9fgai3U2SRutfILrxld66PrmIAS8Xan8q+cw9vU=;
	b=gptbxtyjgUS1zD900ZGA6biMREqapnx6iFpYtdoWkt0TK2hXPI337A2feZfbCYmSM5mS2P
	no98HSzI83Q0NVCA==
From: Thomas Zimmermann <tzimmermann@suse.de>
To: maarten.lankhorst@linux.intel.com,
	mripard@kernel.org,
	airlied@gmail.com,
	simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann <tzimmermann@suse.de>
Subject: [PATCH v2 00/25] drm/dumb-buffers: Fix and improve buffer-size calculation
Date: Thu,  9 Jan 2025 15:56:54 +0100
Message-ID: <20250109150310.219442-1-tzimmermann@suse.de>
X-Mailer: git-send-email 2.47.1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 0B36C21173
X-Spam-Score: -2.01
X-Rspamd-Action: no action
X-Spamd-Result: default: False [-2.01 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	R_DKIM_ALLOW(-0.20)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ASN(0.00)[asn:25478, ipnet:::/0, country:RU];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[19];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_TO(0.00)[linux.intel.com,kernel.org,gmail.com,ffwll.ch];
	FREEMAIL_ENVRCPT(0.00)[gmail.com];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:mid,suse.de:dkim,imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo];
	RCVD_COUNT_TWO(0.00)[2];
	DKIM_TRACE(0.00)[suse.de:+]
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spam-Flag: NO
X-Spam-Level: 

Dumb-buffer pitch and size is specified by width, height, bits-per-pixel
plus various hardware-specific alignments. The calculation of these
values is inconsistent and duplicated among drivers. The results for
formats with bpp < 8 are incorrect.

This series fixes this for most drivers. Default scanline pitch and
buffer size are now calculated with the existing 4CC helpers. There is
a new helper drm_mode_size_dumb() that calculates scanline pitch and
buffer size according to driver requirements.

The series fixes the common GEM implementations for DMA, SHMEM and
VRAM. It further changes most implementations of dumb_create to use
the new helper. A small number of  drivers has more complicated
calculations and will be updated by a later patches.

v2:
- rewrite series
- convert many individual drivers besides the shared GEM helpers

Thomas Zimmermann (25):
  drm/dumb-buffers: Sanitize output on errors
  drm/dumb-buffers: Provide helper to set pitch and size
  drm/gem-dma: Compute dumb-buffer sizes with drm_mode_size_dumb()
  drm/gem-shmem: Compute dumb-buffer sizes with drm_mode_size_dumb()
  drm/gem-vram: Compute dumb-buffer sizes with drm_mode_size_dumb()
  drm/armada: Compute dumb-buffer sizes with drm_mode_size_dumb()
  drm/exynos: Compute dumb-buffer sizes with drm_mode_size_dumb()
  drm/gma500: Compute dumb-buffer sizes with drm_mode_size_dumb()
  drm/hibmc: Compute dumb-buffer sizes with drm_mode_size_dumb()
  drm/imx/ipuv3: Compute dumb-buffer sizes with drm_mode_size_dumb()
  drm/loongson: Compute dumb-buffer sizes with drm_mode_size_dumb()
  drm/mediatek: Compute dumb-buffer sizes with drm_mode_size_dumb()
  drm/msm: Compute dumb-buffer sizes with drm_mode_size_dumb()
  drm/nouveau: Compute dumb-buffer sizes with drm_mode_size_dumb()
  drm/omapdrm: Compute dumb-buffer sizes with drm_mode_size_dumb()
  drm/qxl: Compute dumb-buffer sizes with drm_mode_size_dumb()
  drm/renesas/rcar-du: Compute dumb-buffer sizes with
    drm_mode_size_dumb()
  drm/renesas/rz-du: Compute dumb-buffer sizes with drm_mode_size_dumb()
  drm/rockchip: Compute dumb-buffer sizes with drm_mode_size_dumb()
  drm/tegra: Compute dumb-buffer sizes with drm_mode_size_dumb()
  drm/virtio: Compute dumb-buffer sizes with drm_mode_size_dumb()
  drm/vmwgfx: Compute dumb-buffer sizes with drm_mode_size_dumb()
  drm/xe: Compute dumb-buffer sizes with drm_mode_size_dumb()
  drm/xen: Compute dumb-buffer sizes with drm_mode_size_dumb()
  drm/xlnx: Compute dumb-buffer sizes with drm_mode_size_dumb()

 drivers/gpu/drm/armada/armada_gem.c           |  16 +--
 drivers/gpu/drm/drm_dumb_buffers.c            | 133 ++++++++++++++++--
 drivers/gpu/drm/drm_gem_dma_helper.c          |   7 +-
 drivers/gpu/drm/drm_gem_shmem_helper.c        |  16 +--
 drivers/gpu/drm/drm_gem_vram_helper.c         |  89 +++---------
 drivers/gpu/drm/exynos/exynos_drm_gem.c       |   8 +-
 drivers/gpu/drm/gma500/gem.c                  |  21 +--
 .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c   |  25 +++-
 drivers/gpu/drm/imx/ipuv3/imx-drm-core.c      |  29 +++-
 drivers/gpu/drm/loongson/lsdc_gem.c           |  29 ++--
 drivers/gpu/drm/mediatek/mtk_gem.c            |  13 +-
 drivers/gpu/drm/msm/msm_gem.c                 |  27 +++-
 drivers/gpu/drm/nouveau/nouveau_display.c     |   7 +-
 drivers/gpu/drm/omapdrm/omap_gem.c            |  15 +-
 drivers/gpu/drm/qxl/qxl_dumb.c                |  17 ++-
 drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c |   7 +-
 drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c  |   7 +-
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c   |  12 +-
 drivers/gpu/drm/tegra/gem.c                   |   8 +-
 drivers/gpu/drm/virtio/virtgpu_gem.c          |  11 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_surface.c       |  21 +--
 drivers/gpu/drm/xe/xe_bo.c                    |   8 +-
 drivers/gpu/drm/xen/xen_drm_front.c           |   7 +-
 drivers/gpu/drm/xlnx/zynqmp_kms.c             |   7 +-
 include/drm/drm_dumb_buffers.h                |  14 ++
 include/drm/drm_gem_vram_helper.h             |   6 -
 26 files changed, 333 insertions(+), 227 deletions(-)
 create mode 100644 include/drm/drm_dumb_buffers.h


base-commit: f06efdfad9d0e9f5cb74404ac98e1a5b3b246567
prerequisite-patch-id: 0aa359f6144c4015c140c8a6750be19099c676fb
prerequisite-patch-id: c67e5d886a47b7d0266d81100837557fda34cb24
prerequisite-patch-id: cbc453ee02fae02af22fbfdce56ab732c7a88c36
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:03:20 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:03:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868520.1280037 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVu48-0008I4-3i; Thu, 09 Jan 2025 15:03:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868520.1280037; Thu, 09 Jan 2025 15:03:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVu47-0008H6-TG; Thu, 09 Jan 2025 15:03:19 +0000
Received: by outflank-mailman (input) for mailman id 868520;
 Thu, 09 Jan 2025 15:03: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
 <SRS0=BoWZ=UB=suse.de=tzimmermann@srs-se1.protection.inumbo.net>)
 id 1tVu46-0007zt-HL
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:03:18 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id dad27821-ce9a-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 16:03:16 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id 157402116D;
 Thu,  9 Jan 2025 15:03:16 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 8ED65139AB;
 Thu,  9 Jan 2025 15:03:15 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id cNeRITPlf2c1awAAD6G6ig
 (envelope-from <tzimmermann@suse.de>); Thu, 09 Jan 2025 15:03:15 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: dad27821-ce9a-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736434996; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=3sh7vVw1B49hkDdbVfqLYlvz8obe5G8l/LkcFxQMXdM=;
	b=ntZkX8HIPc1qGvPW8UM3Evg6Ff9TM4m/+rMTrtZcyvaUoSYG4MrK4zcw+XGDVVaTWpH7VQ
	7fbl79Pw4UcW5H8ug3QUw8sp9ufyiWEcAHz3WKEHjB9MqZMiL/ntefZ7I6bgtfudgZeMg4
	Eezv9GbAWHlf4ZgRNmiE562bHzv0X/I=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736434996;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=3sh7vVw1B49hkDdbVfqLYlvz8obe5G8l/LkcFxQMXdM=;
	b=KRido0aSgwUv2dnvGXNMHH0PnwD78rt0xuNhPUc3UhOyhb1FS2KDnnaKFfuch02NIZf5DB
	LvLC3fVQ/RHRQjCg==
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.de header.s=susede2_rsa header.b=ntZkX8HI;
	dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=KRido0aS
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736434996; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=3sh7vVw1B49hkDdbVfqLYlvz8obe5G8l/LkcFxQMXdM=;
	b=ntZkX8HIPc1qGvPW8UM3Evg6Ff9TM4m/+rMTrtZcyvaUoSYG4MrK4zcw+XGDVVaTWpH7VQ
	7fbl79Pw4UcW5H8ug3QUw8sp9ufyiWEcAHz3WKEHjB9MqZMiL/ntefZ7I6bgtfudgZeMg4
	Eezv9GbAWHlf4ZgRNmiE562bHzv0X/I=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736434996;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=3sh7vVw1B49hkDdbVfqLYlvz8obe5G8l/LkcFxQMXdM=;
	b=KRido0aSgwUv2dnvGXNMHH0PnwD78rt0xuNhPUc3UhOyhb1FS2KDnnaKFfuch02NIZf5DB
	LvLC3fVQ/RHRQjCg==
From: Thomas Zimmermann <tzimmermann@suse.de>
To: maarten.lankhorst@linux.intel.com,
	mripard@kernel.org,
	airlied@gmail.com,
	simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann <tzimmermann@suse.de>
Subject: [PATCH v2 02/25] drm/dumb-buffers: Provide helper to set pitch and size
Date: Thu,  9 Jan 2025 15:56:56 +0100
Message-ID: <20250109150310.219442-3-tzimmermann@suse.de>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250109150310.219442-1-tzimmermann@suse.de>
References: <20250109150310.219442-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 157402116D
X-Spam-Level: 
X-Spamd-Result: default: False [-1.51 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	R_DKIM_ALLOW(-0.20)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:email,suse.de:dkim,suse.de:mid,imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_TO(0.00)[linux.intel.com,kernel.org,gmail.com,ffwll.ch];
	RCPT_COUNT_TWELVE(0.00)[19];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:25478, ipnet:::/0, country:RU];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	R_RATELIMIT(0.00)[to_ip_from(RLqtkr6cif1ebgurukgmwdm7xc)];
	RCVD_TLS_ALL(0.00)[];
	DKIM_TRACE(0.00)[suse.de:+];
	TO_DN_SOME(0.00)[];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Rspamd-Action: no action
X-Spam-Score: -1.51
X-Spam-Flag: NO

Add drm_modes_size_dumb(), a helper to calculate the dumb-buffer
scanline pitch and allocation size. Implementations of struct
drm_driver.dumb_create can call the new helper for their size
computations. There's currently quite a bit of code duplication
among DRM's memory managers. Each calculates scanline pitch and
buffer size from the given arguments, but the implementations are
inconsistent in how they treat alignment and format support. Later
patches will unify this code on top of drm_mode_size_dumb() as
much as possible.

drm_mode_size_dumb() uses existing 4CC format helpers to interpret the
given color mode. This makes the dumb-buffer interface behave similar
the kernel's video= parameter. Again, current per-driver implementations
likely have subtle differences or bugs in how they support color modes.

Future directions: one bug is present in the current input validation
in drm_mode_create_dumb(). The dumb-buffer overflow tests round up any
given bits-per-pixel value to a multiple of 8. So even one-bit formats,
such as DRM_FORMAT_C1, require 8 bits per pixel. While not common,
low-end displays use such formats; with a possible overcommitment of
memory. At some point, the validation logic in drm_mode_size_dumb() is
supposed to replace the erronous code.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
 drivers/gpu/drm/drm_dumb_buffers.c | 93 ++++++++++++++++++++++++++++++
 include/drm/drm_dumb_buffers.h     | 14 +++++
 2 files changed, 107 insertions(+)
 create mode 100644 include/drm/drm_dumb_buffers.h

diff --git a/drivers/gpu/drm/drm_dumb_buffers.c b/drivers/gpu/drm/drm_dumb_buffers.c
index 9916aaf5b3f2..fd39720bd617 100644
--- a/drivers/gpu/drm/drm_dumb_buffers.c
+++ b/drivers/gpu/drm/drm_dumb_buffers.c
@@ -25,6 +25,8 @@
 
 #include <drm/drm_device.h>
 #include <drm/drm_drv.h>
+#include <drm/drm_dumb_buffers.h>
+#include <drm/drm_fourcc.h>
 #include <drm/drm_gem.h>
 #include <drm/drm_mode.h>
 
@@ -57,6 +59,97 @@
  * a hardware-specific ioctl to allocate suitable buffer objects.
  */
 
+static int drm_mode_align_dumb(struct drm_mode_create_dumb *args,
+			       unsigned long pitch_align,
+			       unsigned long size_align)
+{
+	u32 pitch = args->pitch;
+	u32 size;
+
+	if (!pitch)
+		return -EINVAL;
+
+	if (pitch_align)
+		pitch = roundup(pitch, pitch_align);
+
+	/* overflow checks for 32bit size calculations */
+	if (args->height > U32_MAX / pitch)
+		return -EINVAL;
+
+	if (!size_align)
+		size_align = PAGE_SIZE;
+	else if (!IS_ALIGNED(size_align, PAGE_SIZE))
+		return -EINVAL;
+
+	size = ALIGN(args->height * pitch, size_align);
+	if (!size)
+		return -EINVAL;
+
+	args->pitch = pitch;
+	args->size = size;
+
+	return 0;
+}
+
+/**
+ * drm_mode_size_dumb - Calculates the scanline and buffer sizes for dumb buffers
+ * @dev: DRM device
+ * @args: Parameters for the dumb buffer
+ * @pitch_align: Scanline alignment in bytes
+ * @size_align: Buffer-size alignment in bytes
+ *
+ * The helper drm_mode_size_dumb() calculates the size of the buffer
+ * allocation and the scanline size for a dumb buffer. Callers have to
+ * set the buffers width, height and color mode in the argument @arg.
+ * The helper validates the correctness of the input and tests for
+ * possible overflows. If successful, it returns the dumb buffer's
+ * required scanline pitch and size in &args.
+ *
+ * The parameter @pitch_align allows the driver to specifies an
+ * alignment for the scanline pitch, if the hardware requires any. The
+ * calculated pitch will be a multiple of the alignment. The parameter
+ * @size_align allows to specify an alignment for buffer sizes. The
+ * returned size is always a multiple of PAGE_SIZE.
+ *
+ * Returns:
+ * Zero on success, or a negative error code otherwise.
+ */
+int drm_mode_size_dumb(struct drm_device *dev,
+		       struct drm_mode_create_dumb *args,
+		       unsigned long pitch_align,
+		       unsigned long size_align)
+{
+	u32 fourcc;
+	const struct drm_format_info *info;
+	u64 pitch;
+
+	/*
+	 * The scanline pitch depends on the buffer width and the color
+	 * format. The latter is specified as a color-mode constant for
+	 * which we first have to find the corresponding color format.
+	 *
+	 * Different color formats can have the same color-mode constant.
+	 * For example XRGB8888 and BGRX8888 both have a color mode of 32.
+	 * It is possible to use different formats for dumb-buffer allocation
+	 * and rendering as long as all involved formats share the same
+	 * color-mode constant.
+	 */
+	fourcc = drm_driver_color_mode_format(dev, args->bpp);
+	if (fourcc == DRM_FORMAT_INVALID)
+		return -EINVAL;
+	info = drm_format_info(fourcc);
+	if (!info)
+		return -EINVAL;
+	pitch = drm_format_info_min_pitch(info, 0, args->width);
+	if (!pitch || pitch > U32_MAX)
+		return -EINVAL;
+
+	args->pitch = pitch;
+
+	return drm_mode_align_dumb(args, pitch_align, size_align);
+}
+EXPORT_SYMBOL(drm_mode_size_dumb);
+
 int drm_mode_create_dumb(struct drm_device *dev,
 			 struct drm_mode_create_dumb *args,
 			 struct drm_file *file_priv)
diff --git a/include/drm/drm_dumb_buffers.h b/include/drm/drm_dumb_buffers.h
new file mode 100644
index 000000000000..6fe36004b19d
--- /dev/null
+++ b/include/drm/drm_dumb_buffers.h
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: MIT */
+
+#ifndef __DRM_DUMB_BUFFERS_H__
+#define __DRM_DUMB_BUFFERS_H__
+
+struct drm_device;
+struct drm_mode_create_dumb;
+
+int drm_mode_size_dumb(struct drm_device *dev,
+		       struct drm_mode_create_dumb *args,
+		       unsigned long pitch_align,
+		       unsigned long size_align);
+
+#endif
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:03:20 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:03:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868521.1280040 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVu48-0008OZ-Bt; Thu, 09 Jan 2025 15:03:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868521.1280040; Thu, 09 Jan 2025 15:03:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVu48-0008Li-6l; Thu, 09 Jan 2025 15:03:20 +0000
Received: by outflank-mailman (input) for mailman id 868521;
 Thu, 09 Jan 2025 15:03: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
 <SRS0=BoWZ=UB=suse.de=tzimmermann@srs-se1.protection.inumbo.net>)
 id 1tVu46-0007zg-LP
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:03:18 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de
 [2a07:de40:b251:101:10:150:64:1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id db1c7733-ce9a-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 16:03:17 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id 8F29B21157;
 Thu,  9 Jan 2025 15:03:16 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 1BCA913A8B;
 Thu,  9 Jan 2025 15:03:16 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id KPh6BTTlf2c1awAAD6G6ig
 (envelope-from <tzimmermann@suse.de>); Thu, 09 Jan 2025 15:03:16 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: db1c7733-ce9a-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736434996; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=A7GD9WsopwPDpvGUQ4ur1Gqo7EpIaoXPPE9kLZRcatM=;
	b=gQ/TUkb3JF+iVClMXZW4QjoXF3b8H+STvr0K0fNCZSJG5Xo9Jf0CgvbttC36vFrPipix1h
	+n7PomChSisdgdBhmPB1Ayed9lB4l4rMbF8jgWhbzEdZxTGeyHKQZkornMm0raJVcLdRBj
	kRk2AI+FpkP1Rk011NDyjvFhBCoIeos=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736434996;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=A7GD9WsopwPDpvGUQ4ur1Gqo7EpIaoXPPE9kLZRcatM=;
	b=IwfDQX8EUhtOLkRMtcz5O1jJTDLKNZSxfz4DsXkapVfCzoifCXtiOEN+IPYwXJTvFj7PUW
	gI6iw1/l5HOFtDBQ==
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.de header.s=susede2_rsa header.b="gQ/TUkb3";
	dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=IwfDQX8E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736434996; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=A7GD9WsopwPDpvGUQ4ur1Gqo7EpIaoXPPE9kLZRcatM=;
	b=gQ/TUkb3JF+iVClMXZW4QjoXF3b8H+STvr0K0fNCZSJG5Xo9Jf0CgvbttC36vFrPipix1h
	+n7PomChSisdgdBhmPB1Ayed9lB4l4rMbF8jgWhbzEdZxTGeyHKQZkornMm0raJVcLdRBj
	kRk2AI+FpkP1Rk011NDyjvFhBCoIeos=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736434996;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=A7GD9WsopwPDpvGUQ4ur1Gqo7EpIaoXPPE9kLZRcatM=;
	b=IwfDQX8EUhtOLkRMtcz5O1jJTDLKNZSxfz4DsXkapVfCzoifCXtiOEN+IPYwXJTvFj7PUW
	gI6iw1/l5HOFtDBQ==
From: Thomas Zimmermann <tzimmermann@suse.de>
To: maarten.lankhorst@linux.intel.com,
	mripard@kernel.org,
	airlied@gmail.com,
	simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann <tzimmermann@suse.de>
Subject: [PATCH v2 03/25] drm/gem-dma: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Thu,  9 Jan 2025 15:56:57 +0100
Message-ID: <20250109150310.219442-4-tzimmermann@suse.de>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250109150310.219442-1-tzimmermann@suse.de>
References: <20250109150310.219442-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 8F29B21157
X-Spam-Score: -1.51
X-Rspamd-Action: no action
X-Spamd-Result: default: False [-1.51 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	R_DKIM_ALLOW(-0.20)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:dkim,suse.de:mid,suse.de:email,imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_TO(0.00)[linux.intel.com,kernel.org,gmail.com,ffwll.ch];
	RCPT_COUNT_TWELVE(0.00)[19];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:25478, ipnet:::/0, country:RU];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	R_RATELIMIT(0.00)[to_ip_from(RLqtkr6cif1ebgurukgmwdm7xc)];
	RCVD_TLS_ALL(0.00)[];
	DKIM_TRACE(0.00)[suse.de:+];
	TO_DN_SOME(0.00)[];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spam-Flag: NO
X-Spam-Level: 

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch to a multiple of 8.

Push the current calculation into the only direct caller imx. Imx's
hardware requires the framebuffer width to be aligned to 8. The
driver's current approach is actually incorrect, as it only guarantees
this implicitly and requires bpp to be a multiple of 8 already. A
later commit will fix this problem by aligning the scanline pitch
such that an aligned width still fits into each scanline's memory.

A number of other drivers are build on top of gem-dma helpers and
implement their own dumb-buffer allocation. These drivers invoke
drm_gem_dma_dumb_create_internal(), which is not affected by this
commit.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
 drivers/gpu/drm/drm_gem_dma_helper.c     | 7 +++++--
 drivers/gpu/drm/imx/ipuv3/imx-drm-core.c | 2 ++
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem_dma_helper.c b/drivers/gpu/drm/drm_gem_dma_helper.c
index 16988d316a6d..5bca7ce3683f 100644
--- a/drivers/gpu/drm/drm_gem_dma_helper.c
+++ b/drivers/gpu/drm/drm_gem_dma_helper.c
@@ -20,6 +20,7 @@
 #include <drm/drm.h>
 #include <drm/drm_device.h>
 #include <drm/drm_drv.h>
+#include <drm/drm_dumb_buffers.h>
 #include <drm/drm_gem_dma_helper.h>
 #include <drm/drm_vma_manager.h>
 
@@ -304,9 +305,11 @@ int drm_gem_dma_dumb_create(struct drm_file *file_priv,
 			    struct drm_mode_create_dumb *args)
 {
 	struct drm_gem_dma_object *dma_obj;
+	int ret;
 
-	args->pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
-	args->size = args->pitch * args->height;
+	ret = drm_mode_size_dumb(drm, args, SZ_8, 0);
+	if (ret)
+		return ret;
 
 	dma_obj = drm_gem_dma_create_with_handle(file_priv, drm, args->size,
 						 &args->handle);
diff --git a/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c b/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c
index ec5fd9a01f1e..e7025df7b978 100644
--- a/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c
@@ -145,6 +145,8 @@ static int imx_drm_dumb_create(struct drm_file *file_priv,
 	int ret;
 
 	args->width = ALIGN(width, 8);
+	args->pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
+	args->size = args->pitch * args->height;
 
 	ret = drm_gem_dma_dumb_create(file_priv, drm, args);
 	if (ret)
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:03:20 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:03:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868522.1280046 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVu48-0008Tb-Ov; Thu, 09 Jan 2025 15:03:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868522.1280046; Thu, 09 Jan 2025 15:03:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVu48-0008Qu-Hd; Thu, 09 Jan 2025 15:03:20 +0000
Received: by outflank-mailman (input) for mailman id 868522;
 Thu, 09 Jan 2025 15:03:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=BoWZ=UB=suse.de=tzimmermann@srs-se1.protection.inumbo.net>)
 id 1tVu47-0007zt-Gl
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:03:19 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id dbb3b9ff-ce9a-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 16:03:17 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id 9ED901F452;
 Thu,  9 Jan 2025 15:03:17 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 1E8BA13A8B;
 Thu,  9 Jan 2025 15:03:17 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id oLMUBjXlf2c1awAAD6G6ig
 (envelope-from <tzimmermann@suse.de>); Thu, 09 Jan 2025 15:03:17 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: dbb3b9ff-ce9a-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736434997; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=5MeZDpntA//5rzpXTRRJBD0ePktTwKhMorCKCUc92Rc=;
	b=LcN64bzyes40c6TXOrOM4CSf00AOJ7EClRb4lc1EwfImdmvhD+q4pOOaRiHM/hb2vjq5BP
	O0F59AbA6H4DOSmBmq2a7UaIBuXxxQ5lF0q6psVC3rOh0Qbj/a2+TBd2fFZYqhNxoOFJAw
	suVAKpBzK+S0t3iiLfWQRLYJMLxeX18=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736434997;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=5MeZDpntA//5rzpXTRRJBD0ePktTwKhMorCKCUc92Rc=;
	b=/1uIZiv3CSp+TJJKm0Fs2VPchuC3vHlxo1xMFugvoy3lzhjv6TwgJDZZPlMzXgDuVC0zsW
	3pgPnHHmELfJIUDA==
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736434997; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=5MeZDpntA//5rzpXTRRJBD0ePktTwKhMorCKCUc92Rc=;
	b=LcN64bzyes40c6TXOrOM4CSf00AOJ7EClRb4lc1EwfImdmvhD+q4pOOaRiHM/hb2vjq5BP
	O0F59AbA6H4DOSmBmq2a7UaIBuXxxQ5lF0q6psVC3rOh0Qbj/a2+TBd2fFZYqhNxoOFJAw
	suVAKpBzK+S0t3iiLfWQRLYJMLxeX18=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736434997;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=5MeZDpntA//5rzpXTRRJBD0ePktTwKhMorCKCUc92Rc=;
	b=/1uIZiv3CSp+TJJKm0Fs2VPchuC3vHlxo1xMFugvoy3lzhjv6TwgJDZZPlMzXgDuVC0zsW
	3pgPnHHmELfJIUDA==
From: Thomas Zimmermann <tzimmermann@suse.de>
To: maarten.lankhorst@linux.intel.com,
	mripard@kernel.org,
	airlied@gmail.com,
	simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann <tzimmermann@suse.de>
Subject: [PATCH v2 05/25] drm/gem-vram: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Thu,  9 Jan 2025 15:56:59 +0100
Message-ID: <20250109150310.219442-6-tzimmermann@suse.de>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250109150310.219442-1-tzimmermann@suse.de>
References: <20250109150310.219442-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Score: -1.30
X-Spamd-Result: default: False [-1.30 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,suse.de:mid,suse.de:email];
	RCPT_COUNT_TWELVE(0.00)[19];
	MIME_TRACE(0.00)[0:+];
	TO_DN_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	FREEMAIL_TO(0.00)[linux.intel.com,kernel.org,gmail.com,ffwll.ch];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	R_RATELIMIT(0.00)[to_ip_from(RLqirfcw6gnbcr9a9yhi49fhi6)];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-Spam-Flag: NO
X-Spam-Level: 

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Inline code from drm_gem_vram_fill_create_dumb() without
the existing size computation. Align the pitch to a multiple of 8.

Only hibmc and vboxvideo use gem-vram. Hibmc invokes the call to
drm_gem_vram_fill_create_dumb() directly and is therefore not affected.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
 drivers/gpu/drm/drm_gem_vram_helper.c | 24 +++++++++++++++++++++++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c b/drivers/gpu/drm/drm_gem_vram_helper.c
index 22b1fe9c03b8..15cd564cbeac 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -6,6 +6,7 @@
 #include <drm/drm_debugfs.h>
 #include <drm/drm_device.h>
 #include <drm/drm_drv.h>
+#include <drm/drm_dumb_buffers.h>
 #include <drm/drm_file.h>
 #include <drm/drm_framebuffer.h>
 #include <drm/drm_gem_atomic_helper.h>
@@ -582,10 +583,31 @@ int drm_gem_vram_driver_dumb_create(struct drm_file *file,
 				    struct drm_device *dev,
 				    struct drm_mode_create_dumb *args)
 {
+	struct drm_gem_vram_object *gbo;
+	int ret;
+
 	if (WARN_ONCE(!dev->vram_mm, "VRAM MM not initialized"))
 		return -EINVAL;
 
-	return drm_gem_vram_fill_create_dumb(file, dev, 0, 0, args);
+	ret = drm_mode_size_dumb(dev, args, SZ_8, 0);
+	if (ret)
+		return ret;
+
+	gbo = drm_gem_vram_create(dev, args->size, 0);
+	if (IS_ERR(gbo))
+		return PTR_ERR(gbo);
+
+	ret = drm_gem_handle_create(file, &gbo->bo.base, &args->handle);
+	if (ret)
+		goto err_drm_gem_object_put;
+
+	drm_gem_object_put(&gbo->bo.base);
+
+	return 0;
+
+err_drm_gem_object_put:
+	drm_gem_object_put(&gbo->bo.base);
+	return ret;
 }
 EXPORT_SYMBOL(drm_gem_vram_driver_dumb_create);
 
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:03:21 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:03:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868523.1280056 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVu49-0000EE-Ap; Thu, 09 Jan 2025 15:03:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868523.1280056; Thu, 09 Jan 2025 15:03:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVu49-0000CJ-3L; Thu, 09 Jan 2025 15:03:21 +0000
Received: by outflank-mailman (input) for mailman id 868523;
 Thu, 09 Jan 2025 15:03:19 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=BoWZ=UB=suse.de=tzimmermann@srs-se1.protection.inumbo.net>)
 id 1tVu47-0007zg-LT
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:03:19 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de
 [2a07:de40:b251:101:10:150:64:2])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id db673d45-ce9a-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 16:03:17 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id 228481F394;
 Thu,  9 Jan 2025 15:03:17 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 95B12139AB;
 Thu,  9 Jan 2025 15:03:16 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id kM9AIzTlf2c1awAAD6G6ig
 (envelope-from <tzimmermann@suse.de>); Thu, 09 Jan 2025 15:03:16 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: db673d45-ce9a-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736434997; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=Vvoo12Nvi8DgFbK/IRRPH1mVPgD6/ri7RVRvYyWO8DQ=;
	b=giCe2KnIm5vpPN6vv7C+rYYEtjKsKX/hokeBKqS5NSUaMZ+FO9xPwLSd6EVdAjED8BxdLL
	UqRNf0KBW6NyTjzknEhjRnKGClicLbJaDzVY4cpH5xa9kSyL9PmswiW1fd8BrFc+Gns8qG
	IYFql4UrVqE9Fob8FnPiI+X6zW9N87k=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736434997;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=Vvoo12Nvi8DgFbK/IRRPH1mVPgD6/ri7RVRvYyWO8DQ=;
	b=DimUvZVzo0Gv2yU7bNDMBSYWvfDXP7UitQV/XbMGzgBvkuYbUD0Lc8mlMn8f/r2mW94vHY
	qU4rg3iSFag9n7Dw==
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.de header.s=susede2_rsa header.b=giCe2KnI;
	dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=DimUvZVz
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736434997; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=Vvoo12Nvi8DgFbK/IRRPH1mVPgD6/ri7RVRvYyWO8DQ=;
	b=giCe2KnIm5vpPN6vv7C+rYYEtjKsKX/hokeBKqS5NSUaMZ+FO9xPwLSd6EVdAjED8BxdLL
	UqRNf0KBW6NyTjzknEhjRnKGClicLbJaDzVY4cpH5xa9kSyL9PmswiW1fd8BrFc+Gns8qG
	IYFql4UrVqE9Fob8FnPiI+X6zW9N87k=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736434997;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=Vvoo12Nvi8DgFbK/IRRPH1mVPgD6/ri7RVRvYyWO8DQ=;
	b=DimUvZVzo0Gv2yU7bNDMBSYWvfDXP7UitQV/XbMGzgBvkuYbUD0Lc8mlMn8f/r2mW94vHY
	qU4rg3iSFag9n7Dw==
From: Thomas Zimmermann <tzimmermann@suse.de>
To: maarten.lankhorst@linux.intel.com,
	mripard@kernel.org,
	airlied@gmail.com,
	simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann <tzimmermann@suse.de>
Subject: [PATCH v2 04/25] drm/gem-shmem: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Thu,  9 Jan 2025 15:56:58 +0100
Message-ID: <20250109150310.219442-5-tzimmermann@suse.de>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250109150310.219442-1-tzimmermann@suse.de>
References: <20250109150310.219442-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 228481F394
X-Spam-Score: -1.51
X-Rspamd-Action: no action
X-Spamd-Result: default: False [-1.51 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	R_DKIM_ALLOW(-0.20)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo,suse.de:dkim,suse.de:mid,suse.de:email];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_TO(0.00)[linux.intel.com,kernel.org,gmail.com,ffwll.ch];
	RCPT_COUNT_TWELVE(0.00)[19];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:25478, ipnet:::/0, country:RU];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	R_RATELIMIT(0.00)[to_ip_from(RLqtkr6cif1ebgurukgmwdm7xc)];
	RCVD_TLS_ALL(0.00)[];
	DKIM_TRACE(0.00)[suse.de:+];
	TO_DN_SOME(0.00)[];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spam-Flag: NO
X-Spam-Level: 

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch to a multiple of 8.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
 drivers/gpu/drm/drm_gem_shmem_helper.c | 16 +++++-----------
 1 file changed, 5 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 5ab351409312..8941b5e4eda9 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -18,6 +18,7 @@
 #include <drm/drm.h>
 #include <drm/drm_device.h>
 #include <drm/drm_drv.h>
+#include <drm/drm_dumb_buffers.h>
 #include <drm/drm_gem_shmem_helper.h>
 #include <drm/drm_prime.h>
 #include <drm/drm_print.h>
@@ -514,18 +515,11 @@ EXPORT_SYMBOL(drm_gem_shmem_purge);
 int drm_gem_shmem_dumb_create(struct drm_file *file, struct drm_device *dev,
 			      struct drm_mode_create_dumb *args)
 {
-	u32 min_pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
+	int ret;
 
-	if (!args->pitch || !args->size) {
-		args->pitch = min_pitch;
-		args->size = PAGE_ALIGN(args->pitch * args->height);
-	} else {
-		/* ensure sane minimum values */
-		if (args->pitch < min_pitch)
-			args->pitch = min_pitch;
-		if (args->size < args->pitch * args->height)
-			args->size = PAGE_ALIGN(args->pitch * args->height);
-	}
+	ret = drm_mode_size_dumb(dev, args, SZ_8, 0);
+	if (ret)
+		return ret;
 
 	return drm_gem_shmem_create_with_handle(file, dev, args->size, &args->handle);
 }
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:03:22 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:03:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868524.1280065 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVu4A-0000Ut-49; Thu, 09 Jan 2025 15:03:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868524.1280065; Thu, 09 Jan 2025 15:03:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVu49-0000Sq-VC; Thu, 09 Jan 2025 15:03:21 +0000
Received: by outflank-mailman (input) for mailman id 868524;
 Thu, 09 Jan 2025 15:03: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
 <SRS0=BoWZ=UB=suse.de=tzimmermann@srs-se1.protection.inumbo.net>)
 id 1tVu48-0007zt-7V
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:03:20 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id dc0a2f1f-ce9a-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 16:03:18 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id 1F1F1210FE;
 Thu,  9 Jan 2025 15:03:18 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 9958C139AB;
 Thu,  9 Jan 2025 15:03:17 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id 4BwlJDXlf2c1awAAD6G6ig
 (envelope-from <tzimmermann@suse.de>); Thu, 09 Jan 2025 15:03:17 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: dc0a2f1f-ce9a-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736434998; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=46Zn+2L9BQk7RoZWxO0Gq8utbPBkf1yuqRTXbfyv6RA=;
	b=DwnxnXogI5blpiCx4zFZUnQVT0yvVKE8wuvmmdIpyAubdhMHoEHCF+nJjHGEH22xPZ1yYn
	hcZJ1vOo86iyqNNon9bpO8Dk+qGITxLQX2yt+tiZcCSYz43UtNJRKoDRwDI1pv/0ORgyuy
	sljk3MEqRX5SQXYdiJPvSaCFIGxusO0=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736434998;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=46Zn+2L9BQk7RoZWxO0Gq8utbPBkf1yuqRTXbfyv6RA=;
	b=gexbdR+fE18AnDat73Vc/obTNlhVD17v+sg4W+7XlVRt9s3J0Cvhxtgml5ei/kRVh6ivEI
	qOVPjfq9QUENesAw==
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.de header.s=susede2_rsa header.b=DwnxnXog;
	dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=gexbdR+f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736434998; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=46Zn+2L9BQk7RoZWxO0Gq8utbPBkf1yuqRTXbfyv6RA=;
	b=DwnxnXogI5blpiCx4zFZUnQVT0yvVKE8wuvmmdIpyAubdhMHoEHCF+nJjHGEH22xPZ1yYn
	hcZJ1vOo86iyqNNon9bpO8Dk+qGITxLQX2yt+tiZcCSYz43UtNJRKoDRwDI1pv/0ORgyuy
	sljk3MEqRX5SQXYdiJPvSaCFIGxusO0=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736434998;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=46Zn+2L9BQk7RoZWxO0Gq8utbPBkf1yuqRTXbfyv6RA=;
	b=gexbdR+fE18AnDat73Vc/obTNlhVD17v+sg4W+7XlVRt9s3J0Cvhxtgml5ei/kRVh6ivEI
	qOVPjfq9QUENesAw==
From: Thomas Zimmermann <tzimmermann@suse.de>
To: maarten.lankhorst@linux.intel.com,
	mripard@kernel.org,
	airlied@gmail.com,
	simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Russell King <linux@armlinux.org.uk>
Subject: [PATCH v2 06/25] drm/armada: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Thu,  9 Jan 2025 15:57:00 +0100
Message-ID: <20250109150310.219442-7-tzimmermann@suse.de>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250109150310.219442-1-tzimmermann@suse.de>
References: <20250109150310.219442-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 1F1F1210FE
X-Spam-Level: 
X-Spamd-Result: default: False [-1.51 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	R_DKIM_ALLOW(-0.20)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	FREEMAIL_TO(0.00)[linux.intel.com,kernel.org,gmail.com,ffwll.ch];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[20];
	MIME_TRACE(0.00)[0:+];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns,suse.de:email,suse.de:dkim,suse.de:mid];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	ASN(0.00)[asn:25478, ipnet:::/0, country:RU];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	DKIM_TRACE(0.00)[suse.de:+];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Rspamd-Action: no action
X-Spam-Score: -1.51
X-Spam-Flag: NO

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. No alignment required.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Russell King <linux@armlinux.org.uk>
---
 drivers/gpu/drm/armada/armada_gem.c | 16 +++++++---------
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_gem.c b/drivers/gpu/drm/armada/armada_gem.c
index 1a1680d71486..0f11ae06064a 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -9,6 +9,7 @@
 #include <linux/shmem_fs.h>
 
 #include <drm/armada_drm.h>
+#include <drm/drm_dumb_buffers.h>
 #include <drm/drm_prime.h>
 
 #include "armada_drm.h"
@@ -244,14 +245,13 @@ int armada_gem_dumb_create(struct drm_file *file, struct drm_device *dev,
 	struct drm_mode_create_dumb *args)
 {
 	struct armada_gem_object *dobj;
-	u32 handle;
-	size_t size;
 	int ret;
 
-	args->pitch = armada_pitch(args->width, args->bpp);
-	args->size = size = args->pitch * args->height;
+	ret = drm_mode_size_dumb(dev, args, 0, 0);
+	if (ret)
+		return ret;
 
-	dobj = armada_gem_alloc_private_object(dev, size);
+	dobj = armada_gem_alloc_private_object(dev, args->size);
 	if (dobj == NULL)
 		return -ENOMEM;
 
@@ -259,14 +259,12 @@ int armada_gem_dumb_create(struct drm_file *file, struct drm_device *dev,
 	if (ret)
 		goto err;
 
-	ret = drm_gem_handle_create(file, &dobj->obj, &handle);
+	ret = drm_gem_handle_create(file, &dobj->obj, &args->handle);
 	if (ret)
 		goto err;
 
-	args->handle = handle;
-
 	/* drop reference from allocate - handle holds it now */
-	DRM_DEBUG_DRIVER("obj %p size %zu handle %#x\n", dobj, size, handle);
+	DRM_DEBUG_DRIVER("obj %p size %llu handle %#x\n", dobj, args->size, args->handle);
  err:
 	drm_gem_object_put(&dobj->obj);
 	return ret;
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:03:23 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:03:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868525.1280076 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVu4B-0000ee-1L; Thu, 09 Jan 2025 15:03:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868525.1280076; Thu, 09 Jan 2025 15:03:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVu4A-0000cl-IA; Thu, 09 Jan 2025 15:03:22 +0000
Received: by outflank-mailman (input) for mailman id 868525;
 Thu, 09 Jan 2025 15:03:21 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=BoWZ=UB=suse.de=tzimmermann@srs-se1.protection.inumbo.net>)
 id 1tVu49-0007zt-7t
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:03:21 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id dc77b805-ce9a-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 16:03:19 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id BD0661F453;
 Thu,  9 Jan 2025 15:03:18 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 26B8613A8B;
 Thu,  9 Jan 2025 15:03:18 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id uPUmCDblf2c1awAAD6G6ig
 (envelope-from <tzimmermann@suse.de>); Thu, 09 Jan 2025 15:03:18 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: dc77b805-ce9a-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736434998; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=3kcBhZF27h/FrTx+EMkgOLEwjtBuwNjT399787FqJYU=;
	b=SJo5ooqxYNBH0LxqxW289flHO0cD2kcaFkSgFTJx+LL9+TiHHYThLBrbY48oo1DRWHbAuU
	BVZyjS1bc9AvqGMqIJxADmkZ3Iyo/9QBmHyYZDYWXRxav29d67ABkHy9k0fWQ7IJgJCOxq
	VjpM0AS8/hBV6unopBBK+hURFGf2Th0=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736434998;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=3kcBhZF27h/FrTx+EMkgOLEwjtBuwNjT399787FqJYU=;
	b=DbLcr1F8k4Xx3GWfv5nMTCRUujkcnkR3qGAcHa026A2pGdpEkV2pCQ/AUMinMSP/KROIXa
	Xsc4JlrFg9IuTIBA==
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.de header.s=susede2_rsa header.b=SJo5ooqx;
	dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=DbLcr1F8
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736434998; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=3kcBhZF27h/FrTx+EMkgOLEwjtBuwNjT399787FqJYU=;
	b=SJo5ooqxYNBH0LxqxW289flHO0cD2kcaFkSgFTJx+LL9+TiHHYThLBrbY48oo1DRWHbAuU
	BVZyjS1bc9AvqGMqIJxADmkZ3Iyo/9QBmHyYZDYWXRxav29d67ABkHy9k0fWQ7IJgJCOxq
	VjpM0AS8/hBV6unopBBK+hURFGf2Th0=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736434998;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=3kcBhZF27h/FrTx+EMkgOLEwjtBuwNjT399787FqJYU=;
	b=DbLcr1F8k4Xx3GWfv5nMTCRUujkcnkR3qGAcHa026A2pGdpEkV2pCQ/AUMinMSP/KROIXa
	Xsc4JlrFg9IuTIBA==
From: Thomas Zimmermann <tzimmermann@suse.de>
To: maarten.lankhorst@linux.intel.com,
	mripard@kernel.org,
	airlied@gmail.com,
	simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Inki Dae <inki.dae@samsung.com>,
	Seung-Woo Kim <sw0312.kim@samsung.com>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	Alim Akhtar <alim.akhtar@samsung.com>
Subject: [PATCH v2 07/25] drm/exynos: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Thu,  9 Jan 2025 15:57:01 +0100
Message-ID: <20250109150310.219442-8-tzimmermann@suse.de>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250109150310.219442-1-tzimmermann@suse.de>
References: <20250109150310.219442-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: BD0661F453
X-Spam-Score: -1.51
X-Rspamd-Action: no action
X-Spamd-Result: default: False [-1.51 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	R_DKIM_ALLOW(-0.20)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo,suse.de:dkim,suse.de:mid,suse.de:email];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_TO(0.00)[linux.intel.com,kernel.org,gmail.com,ffwll.ch];
	RCPT_COUNT_TWELVE(0.00)[24];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:25478, ipnet:::/0, country:RU];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	R_RATELIMIT(0.00)[to_ip_from(RLqtkr6cif1ebgurukgmwdm7xc)];
	RCVD_TLS_ALL(0.00)[];
	DKIM_TRACE(0.00)[suse.de:+];
	TO_DN_SOME(0.00)[];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spam-Flag: NO
X-Spam-Level: 

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. No alignment required.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Alim Akhtar <alim.akhtar@samsung.com>
---
 drivers/gpu/drm/exynos/exynos_drm_gem.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 4787fee4696f..ffa1c02b4b1e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -11,6 +11,7 @@
 #include <linux/shmem_fs.h>
 #include <linux/module.h>
 
+#include <drm/drm_dumb_buffers.h>
 #include <drm/drm_prime.h>
 #include <drm/drm_vma_manager.h>
 #include <drm/exynos_drm.h>
@@ -330,15 +331,16 @@ int exynos_drm_gem_dumb_create(struct drm_file *file_priv,
 	unsigned int flags;
 	int ret;
 
+	ret = drm_mode_size_dumb(dev, args, 0, 0);
+	if (ret)
+		return ret;
+
 	/*
 	 * allocate memory to be used for framebuffer.
 	 * - this callback would be called by user application
 	 *	with DRM_IOCTL_MODE_CREATE_DUMB command.
 	 */
 
-	args->pitch = args->width * ((args->bpp + 7) / 8);
-	args->size = args->pitch * args->height;
-
 	if (is_drm_iommu_supported(dev))
 		flags = EXYNOS_BO_NONCONTIG | EXYNOS_BO_WC;
 	else
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:03:25 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:03:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868526.1280095 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVu4C-0001E9-Sl; Thu, 09 Jan 2025 15:03:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868526.1280095; Thu, 09 Jan 2025 15:03:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVu4C-0001Bc-BS; Thu, 09 Jan 2025 15:03:24 +0000
Received: by outflank-mailman (input) for mailman id 868526;
 Thu, 09 Jan 2025 15:03: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
 <SRS0=BoWZ=UB=suse.de=tzimmermann@srs-se1.protection.inumbo.net>)
 id 1tVu4A-0007zg-17
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:03:22 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ddd157b9-ce9a-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 16:03:21 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id 1C4E021172;
 Thu,  9 Jan 2025 15:03:21 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 9209613A8B;
 Thu,  9 Jan 2025 15:03:20 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id 8Jl2Ijjlf2c1awAAD6G6ig
 (envelope-from <tzimmermann@suse.de>); Thu, 09 Jan 2025 15:03:20 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ddd157b9-ce9a-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736435001; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=x57thPItIBNAc4w7T3BJSvwXgN4Zg3ANBk6BL6o6g1w=;
	b=MBykX3UcYievZPG8W4KY5cWAN3VrLdzflcIRyMRRGZeVjPQx6UqpSmgW6zB9xWjEFygqdH
	GCJDFSxLzVLrJsRqdXfhcge2vFG3Tu2Wr6kloKYexwzIJktBwGWsvN7wJzjdtUHXzQxtgs
	o8MSWz9o4qBdkFVGKUdN72C4nA+DX+4=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736435001;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=x57thPItIBNAc4w7T3BJSvwXgN4Zg3ANBk6BL6o6g1w=;
	b=fbjNMvAFHNpDMsTfArOYrWrOrxxGjQxZd68xLUp/rv90WJg3jV71IlEhlii3EHfPGUakJw
	zhGwfgHybrGBpJBA==
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736435001; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=x57thPItIBNAc4w7T3BJSvwXgN4Zg3ANBk6BL6o6g1w=;
	b=MBykX3UcYievZPG8W4KY5cWAN3VrLdzflcIRyMRRGZeVjPQx6UqpSmgW6zB9xWjEFygqdH
	GCJDFSxLzVLrJsRqdXfhcge2vFG3Tu2Wr6kloKYexwzIJktBwGWsvN7wJzjdtUHXzQxtgs
	o8MSWz9o4qBdkFVGKUdN72C4nA+DX+4=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736435001;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=x57thPItIBNAc4w7T3BJSvwXgN4Zg3ANBk6BL6o6g1w=;
	b=fbjNMvAFHNpDMsTfArOYrWrOrxxGjQxZd68xLUp/rv90WJg3jV71IlEhlii3EHfPGUakJw
	zhGwfgHybrGBpJBA==
From: Thomas Zimmermann <tzimmermann@suse.de>
To: maarten.lankhorst@linux.intel.com,
	mripard@kernel.org,
	airlied@gmail.com,
	simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Sui Jingfeng <suijingfeng@loongson.cn>,
	Sui Jingfeng <sui.jingfeng@linux.dev>
Subject: [PATCH v2 11/25] drm/loongson: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Thu,  9 Jan 2025 15:57:05 +0100
Message-ID: <20250109150310.219442-12-tzimmermann@suse.de>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250109150310.219442-1-tzimmermann@suse.de>
References: <20250109150310.219442-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Score: -1.30
X-Spamd-Result: default: False [-1.30 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:mid,suse.de:email,imap1.dmz-prg2.suse.org:helo];
	RCPT_COUNT_TWELVE(0.00)[21];
	MIME_TRACE(0.00)[0:+];
	TO_DN_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	FREEMAIL_TO(0.00)[linux.intel.com,kernel.org,gmail.com,ffwll.ch];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	R_RATELIMIT(0.00)[to_ip_from(RLqirfcw6gnbcr9a9yhi49fhi6)];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-Spam-Flag: NO
X-Spam-Level: 

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch according to hardware requirements.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Sui Jingfeng <suijingfeng@loongson.cn>
Cc: Sui Jingfeng <sui.jingfeng@linux.dev>
---
 drivers/gpu/drm/loongson/lsdc_gem.c | 29 ++++++++---------------------
 1 file changed, 8 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/loongson/lsdc_gem.c b/drivers/gpu/drm/loongson/lsdc_gem.c
index a720d8f53209..9f982b85301f 100644
--- a/drivers/gpu/drm/loongson/lsdc_gem.c
+++ b/drivers/gpu/drm/loongson/lsdc_gem.c
@@ -6,6 +6,7 @@
 #include <linux/dma-buf.h>
 
 #include <drm/drm_debugfs.h>
+#include <drm/drm_dumb_buffers.h>
 #include <drm/drm_file.h>
 #include <drm/drm_gem.h>
 #include <drm/drm_prime.h>
@@ -204,45 +205,31 @@ int lsdc_dumb_create(struct drm_file *file, struct drm_device *ddev,
 	const struct lsdc_desc *descp = ldev->descp;
 	u32 domain = LSDC_GEM_DOMAIN_VRAM;
 	struct drm_gem_object *gobj;
-	size_t size;
-	u32 pitch;
-	u32 handle;
 	int ret;
 
-	if (!args->width || !args->height)
-		return -EINVAL;
-
-	if (args->bpp != 32 && args->bpp != 16)
-		return -EINVAL;
-
-	pitch = args->width * args->bpp / 8;
-	pitch = ALIGN(pitch, descp->pitch_align);
-	size = pitch * args->height;
-	size = ALIGN(size, PAGE_SIZE);
+	ret = drm_mode_size_dumb(ddev, args, descp->pitch_align, 0);
+	if (ret)
+		return ret;
 
 	/* Maximum single bo size allowed is the half vram size available */
-	if (size > ldev->vram_size / 2) {
-		drm_err(ddev, "Requesting(%zuMiB) failed\n", size >> 20);
+	if (args->size > ldev->vram_size / 2) {
+		drm_err(ddev, "Requesting(%zuMiB) failed\n", (size_t)(args->size >> PAGE_SHIFT));
 		return -ENOMEM;
 	}
 
-	gobj = lsdc_gem_object_create(ddev, domain, size, false, NULL, NULL);
+	gobj = lsdc_gem_object_create(ddev, domain, args->size, false, NULL, NULL);
 	if (IS_ERR(gobj)) {
 		drm_err(ddev, "Failed to create gem object\n");
 		return PTR_ERR(gobj);
 	}
 
-	ret = drm_gem_handle_create(file, gobj, &handle);
+	ret = drm_gem_handle_create(file, gobj, &args->handle);
 
 	/* drop reference from allocate, handle holds it now */
 	drm_gem_object_put(gobj);
 	if (ret)
 		return ret;
 
-	args->pitch = pitch;
-	args->size = size;
-	args->handle = handle;
-
 	return 0;
 }
 
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:03:25 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:03:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868527.1280100 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVu4D-0001Q7-G6; Thu, 09 Jan 2025 15:03:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868527.1280100; Thu, 09 Jan 2025 15:03:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVu4D-0001Nd-5V; Thu, 09 Jan 2025 15:03:25 +0000
Received: by outflank-mailman (input) for mailman id 868527;
 Thu, 09 Jan 2025 15:03: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
 <SRS0=BoWZ=UB=suse.de=tzimmermann@srs-se1.protection.inumbo.net>)
 id 1tVu4A-0007zt-7q
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:03:22 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id dca7a618-ce9a-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 16:03:19 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id 496952116F;
 Thu,  9 Jan 2025 15:03:19 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id C40B8139AB;
 Thu,  9 Jan 2025 15:03:18 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id WPWSLjblf2c1awAAD6G6ig
 (envelope-from <tzimmermann@suse.de>); Thu, 09 Jan 2025 15:03:18 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: dca7a618-ce9a-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736434999; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=jIlkzGmf9+JQi5hKq1VLUT7OJlJM4iSRa4SFYEhnTFA=;
	b=DlIcOme8qn1BahiaO0eSzJ5NBh9N5kCSwK2Vf2IDFPa7VIdrVIV3F18xXAFrhnUTvqGgQp
	ZaVQjCx98nFRpqYFSOOQ+K1hGThmFSSlpqOXO0H2U1tzoeEbwAxU/ujANUqyB5JcZK3hHs
	ry9ittFREiV6Btr+/Px4sj62e2qtlVg=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736434999;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=jIlkzGmf9+JQi5hKq1VLUT7OJlJM4iSRa4SFYEhnTFA=;
	b=GpT1dA+4sBPb3xdvmoq+mgzStdotRyRrrD3S/uv2r/b1T8A0kd1pmiIfC1rhRqZPCE+Sks
	DQMhDqqRMlqhNlBQ==
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736434999; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=jIlkzGmf9+JQi5hKq1VLUT7OJlJM4iSRa4SFYEhnTFA=;
	b=DlIcOme8qn1BahiaO0eSzJ5NBh9N5kCSwK2Vf2IDFPa7VIdrVIV3F18xXAFrhnUTvqGgQp
	ZaVQjCx98nFRpqYFSOOQ+K1hGThmFSSlpqOXO0H2U1tzoeEbwAxU/ujANUqyB5JcZK3hHs
	ry9ittFREiV6Btr+/Px4sj62e2qtlVg=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736434999;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=jIlkzGmf9+JQi5hKq1VLUT7OJlJM4iSRa4SFYEhnTFA=;
	b=GpT1dA+4sBPb3xdvmoq+mgzStdotRyRrrD3S/uv2r/b1T8A0kd1pmiIfC1rhRqZPCE+Sks
	DQMhDqqRMlqhNlBQ==
From: Thomas Zimmermann <tzimmermann@suse.de>
To: maarten.lankhorst@linux.intel.com,
	mripard@kernel.org,
	airlied@gmail.com,
	simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Subject: [PATCH v2 08/25] drm/gma500: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Thu,  9 Jan 2025 15:57:02 +0100
Message-ID: <20250109150310.219442-9-tzimmermann@suse.de>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250109150310.219442-1-tzimmermann@suse.de>
References: <20250109150310.219442-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Level: 
X-Spamd-Result: default: False [-1.30 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,suse.de:email,suse.de:mid];
	MIME_TRACE(0.00)[0:+];
	RCPT_COUNT_TWELVE(0.00)[20];
	RCVD_TLS_ALL(0.00)[];
	TO_DN_SOME(0.00)[];
	TAGGED_RCPT(0.00)[];
	FREEMAIL_CC(0.00)[lists.freedesktop.org,lists.infradead.org,vger.kernel.org,lists.linux.dev,lists.xenproject.org,suse.de,gmail.com];
	FREEMAIL_TO(0.00)[linux.intel.com,kernel.org,gmail.com,ffwll.ch];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	FROM_HAS_DN(0.00)[];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	R_RATELIMIT(0.00)[to_ip_from(RLqirfcw6gnbcr9a9yhi49fhi6)];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-Spam-Score: -1.30
X-Spam-Flag: NO

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch to a multiple of 64.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
---
 drivers/gpu/drm/gma500/gem.c | 21 ++++++---------------
 1 file changed, 6 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c
index 4b7627a72637..fc337db0a948 100644
--- a/drivers/gpu/drm/gma500/gem.c
+++ b/drivers/gpu/drm/gma500/gem.c
@@ -16,6 +16,7 @@
 #include <asm/set_memory.h>
 
 #include <drm/drm.h>
+#include <drm/drm_dumb_buffers.h>
 #include <drm/drm_vma_manager.h>
 
 #include "gem.h"
@@ -199,35 +200,25 @@ psb_gem_create(struct drm_device *dev, u64 size, const char *name, bool stolen,
 int psb_gem_dumb_create(struct drm_file *file, struct drm_device *dev,
 			struct drm_mode_create_dumb *args)
 {
-	size_t pitch, size;
 	struct psb_gem_object *pobj;
 	struct drm_gem_object *obj;
-	u32 handle;
 	int ret;
 
-	pitch = args->width * DIV_ROUND_UP(args->bpp, 8);
-	pitch = ALIGN(pitch, 64);
-
-	size = pitch * args->height;
-	size = roundup(size, PAGE_SIZE);
-	if (!size)
-		return -EINVAL;
+	ret = drm_mode_size_dumb(dev, args, SZ_64, 0);
+	if (ret)
+		return ret;
 
-	pobj = psb_gem_create(dev, size, "gem", false, PAGE_SIZE);
+	pobj = psb_gem_create(dev, args->size, "gem", false, PAGE_SIZE);
 	if (IS_ERR(pobj))
 		return PTR_ERR(pobj);
 	obj = &pobj->base;
 
-	ret = drm_gem_handle_create(file, obj, &handle);
+	ret = drm_gem_handle_create(file, obj, &args->handle);
 	if (ret)
 		goto err_drm_gem_object_put;
 
 	drm_gem_object_put(obj);
 
-	args->pitch = pitch;
-	args->size = size;
-	args->handle = handle;
-
 	return 0;
 
 err_drm_gem_object_put:
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:03:26 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:03:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868528.1280105 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVu4D-0001WQ-UH; Thu, 09 Jan 2025 15:03:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868528.1280105; Thu, 09 Jan 2025 15:03:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVu4D-0001Uv-Ki; Thu, 09 Jan 2025 15:03:25 +0000
Received: by outflank-mailman (input) for mailman id 868528;
 Thu, 09 Jan 2025 15:03:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=BoWZ=UB=suse.de=tzimmermann@srs-se1.protection.inumbo.net>)
 id 1tVu4B-0007zt-84
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:03:23 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id dd237548-ce9a-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 16:03:20 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id E721F21171;
 Thu,  9 Jan 2025 15:03:19 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 50C0913A8B;
 Thu,  9 Jan 2025 15:03:19 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id MFNqEjflf2c1awAAD6G6ig
 (envelope-from <tzimmermann@suse.de>); Thu, 09 Jan 2025 15:03:19 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: dd237548-ce9a-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736435000; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=NqQRjOkhm9SJSbhxaHLS/kALWSX7OjgIi0zWzKpICPM=;
	b=QEdI2JVuAtwjaRpn1a9OFWgjqj3vZJaOLtdoeqSUYNcWQ0K6AyVe+NKAdTRqaF6xN4rwoS
	S+VajvQzfi8eTK2zzPVPpGspbAVlr8roJzhPrF9leDWOcqqtMReUqvg3WtmTH5NpkluLiB
	LTNkrCxWe2dNbcRRiiAqUZYOnoZ5SzM=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736435000;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=NqQRjOkhm9SJSbhxaHLS/kALWSX7OjgIi0zWzKpICPM=;
	b=rrsFXEqv5/RIaAjhK/LJO8o69DayAQL2H8fXVM7CAdBqkRlT8d89QpRS0vSV3VCS608hTO
	/Bzn4WflsHwfjsCQ==
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.de header.s=susede2_rsa header.b=jZZapTnC;
	dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=lk77pFGn
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736434999; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=NqQRjOkhm9SJSbhxaHLS/kALWSX7OjgIi0zWzKpICPM=;
	b=jZZapTnCAdx/tMhB9e9FyPhemBcaQ4RAHrohqqdY389CpOLMQTTOCdQX5lB3Imxmwh+NsX
	PZ/WqOMlY1IeD/th3PyUpFmUOY8iRO4YQ5Zm7ftZPMo2cbIWjI9dCYxVq4aie9WhZXfbDS
	VWB3SvqFdopGa/7hrVfP33ejnWntyWs=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736434999;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=NqQRjOkhm9SJSbhxaHLS/kALWSX7OjgIi0zWzKpICPM=;
	b=lk77pFGnfUgqy1c2btVrQZ4ATtWNUyGXXQlWLRvPjL5pkBLWiohlrYrIJokVOs0r+/es+Y
	Oxmj8v4C7fw0aWCA==
From: Thomas Zimmermann <tzimmermann@suse.de>
To: maarten.lankhorst@linux.intel.com,
	mripard@kernel.org,
	airlied@gmail.com,
	simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Xinliang Liu <xinliang.liu@linaro.org>,
	Tian Tao <tiantao6@hisilicon.com>,
	Xinwei Kong <kong.kongxinwei@hisilicon.com>,
	Sumit Semwal <sumit.semwal@linaro.org>,
	Yongqin Liu <yongqin.liu@linaro.org>,
	John Stultz <jstultz@google.com>
Subject: [PATCH v2 09/25] drm/hibmc: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Thu,  9 Jan 2025 15:57:03 +0100
Message-ID: <20250109150310.219442-10-tzimmermann@suse.de>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250109150310.219442-1-tzimmermann@suse.de>
References: <20250109150310.219442-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: E721F21171
X-Spam-Score: -1.51
X-Rspamd-Action: no action
X-Spamd-Result: default: False [-1.51 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	R_DKIM_ALLOW(-0.20)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:dkim,suse.de:mid,suse.de:email,linaro.org:email,imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_TO(0.00)[linux.intel.com,kernel.org,gmail.com,ffwll.ch];
	RCPT_COUNT_TWELVE(0.00)[25];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:25478, ipnet:::/0, country:RU];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	R_RATELIMIT(0.00)[to_ip_from(RLqtkr6cif1ebgurukgmwdm7xc)];
	RCVD_TLS_ALL(0.00)[];
	DKIM_TRACE(0.00)[suse.de:+];
	TO_DN_SOME(0.00)[];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spam-Flag: NO
X-Spam-Level: 

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch to a multiple of 128.

The hibmc driver's new hibmc_dumb_create() is similar to the one
in GEM VRAM helpers. The driver was the only caller of
drm_gem_vram_fill_create_dumb(). Remove the now unused helper.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Xinliang Liu <xinliang.liu@linaro.org>
Cc: Tian Tao <tiantao6@hisilicon.com>
Cc: Xinwei Kong <kong.kongxinwei@hisilicon.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Yongqin Liu <yongqin.liu@linaro.org>
Cc: John Stultz <jstultz@google.com>
---
 drivers/gpu/drm/drm_gem_vram_helper.c         | 65 -------------------
 .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c   | 25 ++++++-
 include/drm/drm_gem_vram_helper.h             |  6 --
 3 files changed, 24 insertions(+), 72 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c b/drivers/gpu/drm/drm_gem_vram_helper.c
index 15cd564cbeac..b4cf8134df6d 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -444,71 +444,6 @@ void drm_gem_vram_vunmap(struct drm_gem_vram_object *gbo,
 }
 EXPORT_SYMBOL(drm_gem_vram_vunmap);
 
-/**
- * drm_gem_vram_fill_create_dumb() - Helper for implementing
- *				     &struct drm_driver.dumb_create
- *
- * @file:		the DRM file
- * @dev:		the DRM device
- * @pg_align:		the buffer's alignment in multiples of the page size
- * @pitch_align:	the scanline's alignment in powers of 2
- * @args:		the arguments as provided to
- *			&struct drm_driver.dumb_create
- *
- * This helper function fills &struct drm_mode_create_dumb, which is used
- * by &struct drm_driver.dumb_create. Implementations of this interface
- * should forwards their arguments to this helper, plus the driver-specific
- * parameters.
- *
- * Returns:
- * 0 on success, or
- * a negative error code otherwise.
- */
-int drm_gem_vram_fill_create_dumb(struct drm_file *file,
-				  struct drm_device *dev,
-				  unsigned long pg_align,
-				  unsigned long pitch_align,
-				  struct drm_mode_create_dumb *args)
-{
-	size_t pitch, size;
-	struct drm_gem_vram_object *gbo;
-	int ret;
-	u32 handle;
-
-	pitch = args->width * DIV_ROUND_UP(args->bpp, 8);
-	if (pitch_align) {
-		if (WARN_ON_ONCE(!is_power_of_2(pitch_align)))
-			return -EINVAL;
-		pitch = ALIGN(pitch, pitch_align);
-	}
-	size = pitch * args->height;
-
-	size = roundup(size, PAGE_SIZE);
-	if (!size)
-		return -EINVAL;
-
-	gbo = drm_gem_vram_create(dev, size, pg_align);
-	if (IS_ERR(gbo))
-		return PTR_ERR(gbo);
-
-	ret = drm_gem_handle_create(file, &gbo->bo.base, &handle);
-	if (ret)
-		goto err_drm_gem_object_put;
-
-	drm_gem_object_put(&gbo->bo.base);
-
-	args->pitch = pitch;
-	args->size = size;
-	args->handle = handle;
-
-	return 0;
-
-err_drm_gem_object_put:
-	drm_gem_object_put(&gbo->bo.base);
-	return ret;
-}
-EXPORT_SYMBOL(drm_gem_vram_fill_create_dumb);
-
 /*
  * Helpers for struct ttm_device_funcs
  */
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index e6de6d5edf6b..81768577871f 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -18,10 +18,12 @@
 #include <drm/clients/drm_client_setup.h>
 #include <drm/drm_atomic_helper.h>
 #include <drm/drm_drv.h>
+#include <drm/drm_dumb_buffers.h>
 #include <drm/drm_fbdev_ttm.h>
 #include <drm/drm_gem_framebuffer_helper.h>
 #include <drm/drm_gem_vram_helper.h>
 #include <drm/drm_managed.h>
+#include <drm/drm_mode.h>
 #include <drm/drm_module.h>
 #include <drm/drm_vblank.h>
 
@@ -54,7 +56,28 @@ static irqreturn_t hibmc_interrupt(int irq, void *arg)
 static int hibmc_dumb_create(struct drm_file *file, struct drm_device *dev,
 			     struct drm_mode_create_dumb *args)
 {
-	return drm_gem_vram_fill_create_dumb(file, dev, 0, 128, args);
+	struct drm_gem_vram_object *gbo;
+	int ret;
+
+	ret = drm_mode_size_dumb(dev, args, SZ_128, 0);
+	if (ret)
+		return ret;
+
+	gbo = drm_gem_vram_create(dev, args->size, 0);
+	if (IS_ERR(gbo))
+		return PTR_ERR(gbo);
+
+	ret = drm_gem_handle_create(file, &gbo->bo.base, &args->handle);
+	if (ret)
+		goto err_drm_gem_object_put;
+
+	drm_gem_object_put(&gbo->bo.base);
+
+	return 0;
+
+err_drm_gem_object_put:
+	drm_gem_object_put(&gbo->bo.base);
+	return ret;
 }
 
 static const struct drm_driver hibmc_driver = {
diff --git a/include/drm/drm_gem_vram_helper.h b/include/drm/drm_gem_vram_helper.h
index 00830b49a3ff..b6e821f5dd03 100644
--- a/include/drm/drm_gem_vram_helper.h
+++ b/include/drm/drm_gem_vram_helper.h
@@ -100,12 +100,6 @@ int drm_gem_vram_vmap(struct drm_gem_vram_object *gbo, struct iosys_map *map);
 void drm_gem_vram_vunmap(struct drm_gem_vram_object *gbo,
 			 struct iosys_map *map);
 
-int drm_gem_vram_fill_create_dumb(struct drm_file *file,
-				  struct drm_device *dev,
-				  unsigned long pg_align,
-				  unsigned long pitch_align,
-				  struct drm_mode_create_dumb *args);
-
 /*
  * Helpers for struct drm_driver
  */
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:03:28 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:03:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868531.1280123 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVu4F-0001tW-Rq; Thu, 09 Jan 2025 15:03:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868531.1280123; Thu, 09 Jan 2025 15:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVu4F-0001rh-4v; Thu, 09 Jan 2025 15:03:27 +0000
Received: by outflank-mailman (input) for mailman id 868531;
 Thu, 09 Jan 2025 15:03:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=BoWZ=UB=suse.de=tzimmermann@srs-se1.protection.inumbo.net>)
 id 1tVu4C-0007zt-8C
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:03:24 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id dd82d386-ce9a-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 16:03:21 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id 8C5CE1F454;
 Thu,  9 Jan 2025 15:03:20 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id ED5D6139AB;
 Thu,  9 Jan 2025 15:03:19 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id iHioODflf2c1awAAD6G6ig
 (envelope-from <tzimmermann@suse.de>); Thu, 09 Jan 2025 15:03:19 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: dd82d386-ce9a-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736435000; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=Mnc7OxBRxae0FLX9AiypGBr9SnItREky3Nno+gmcLhE=;
	b=xBYc+uS4jXR73pI45fQ7VNP33cL3fR5iWA/8pbeq9+n0yITn3Jdkcd5FEzAl1Sfb+kHr6I
	mMGmtpte16yEU8LXgc+uzNdCXR+lqksm0qJvElsDWsaeOa55F5ykbYUxvdVYcxcVAN0PFB
	i6vF+QuNaBcvYc+Jyo0HvmYlNXaSOIQ=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736435000;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=Mnc7OxBRxae0FLX9AiypGBr9SnItREky3Nno+gmcLhE=;
	b=3qpqAq2aFy5ghC7wyhkpk1nLz0hufbE0CnbWS0jSRfKSU27z685T08ustaOdAIYISvW8xM
	AJ7xUVGLlsPuVFAg==
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.de header.s=susede2_rsa header.b=xBYc+uS4;
	dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=3qpqAq2a
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736435000; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=Mnc7OxBRxae0FLX9AiypGBr9SnItREky3Nno+gmcLhE=;
	b=xBYc+uS4jXR73pI45fQ7VNP33cL3fR5iWA/8pbeq9+n0yITn3Jdkcd5FEzAl1Sfb+kHr6I
	mMGmtpte16yEU8LXgc+uzNdCXR+lqksm0qJvElsDWsaeOa55F5ykbYUxvdVYcxcVAN0PFB
	i6vF+QuNaBcvYc+Jyo0HvmYlNXaSOIQ=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736435000;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=Mnc7OxBRxae0FLX9AiypGBr9SnItREky3Nno+gmcLhE=;
	b=3qpqAq2aFy5ghC7wyhkpk1nLz0hufbE0CnbWS0jSRfKSU27z685T08ustaOdAIYISvW8xM
	AJ7xUVGLlsPuVFAg==
From: Thomas Zimmermann <tzimmermann@suse.de>
To: maarten.lankhorst@linux.intel.com,
	mripard@kernel.org,
	airlied@gmail.com,
	simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Shawn Guo <shawnguo@kernel.org>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	Fabio Estevam <festevam@gmail.com>
Subject: [PATCH v2 10/25] drm/imx/ipuv3: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Thu,  9 Jan 2025 15:57:04 +0100
Message-ID: <20250109150310.219442-11-tzimmermann@suse.de>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250109150310.219442-1-tzimmermann@suse.de>
References: <20250109150310.219442-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 8C5CE1F454
X-Spam-Score: -1.51
X-Rspamd-Action: no action
X-Spamd-Result: default: False [-1.51 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	R_DKIM_ALLOW(-0.20)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[24];
	FREEMAIL_TO(0.00)[linux.intel.com,kernel.org,gmail.com,ffwll.ch];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	FREEMAIL_CC(0.00)[lists.freedesktop.org,lists.infradead.org,vger.kernel.org,lists.linux.dev,lists.xenproject.org,suse.de,pengutronix.de,kernel.org,gmail.com];
	RCVD_TLS_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:dkim,suse.de:mid,suse.de:email,imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo];
	ASN(0.00)[asn:25478, ipnet:::/0, country:RU];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DKIM_TRACE(0.00)[suse.de:+];
	R_RATELIMIT(0.00)[to_ip_from(RLqtkr6cif1ebgurukgmwdm7xc)];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spam-Flag: NO
X-Spam-Level: 

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. The hardware requires the framebuffer width to be a
multiple of 8. The scanline pitch has be large enough to support
this. Therefore compute the byte size of 8 pixels in the given color
mode and align the pitch accordingly.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Fabio Estevam <festevam@gmail.com>
---
 drivers/gpu/drm/imx/ipuv3/imx-drm-core.c | 31 ++++++++++++++++++------
 1 file changed, 23 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c b/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c
index e7025df7b978..465b5a6ad5bb 100644
--- a/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c
@@ -17,7 +17,9 @@
 #include <drm/drm_atomic.h>
 #include <drm/drm_atomic_helper.h>
 #include <drm/drm_drv.h>
+#include <drm/drm_dumb_buffers.h>
 #include <drm/drm_fbdev_dma.h>
+#include <drm/drm_fourcc.h>
 #include <drm/drm_gem_dma_helper.h>
 #include <drm/drm_gem_framebuffer_helper.h>
 #include <drm/drm_managed.h>
@@ -141,19 +143,32 @@ static int imx_drm_dumb_create(struct drm_file *file_priv,
 			       struct drm_device *drm,
 			       struct drm_mode_create_dumb *args)
 {
-	u32 width = args->width;
+	u32 fourcc;
+	const struct drm_format_info *info;
+	u64 pitch_align;
 	int ret;
 
-	args->width = ALIGN(width, 8);
-	args->pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
-	args->size = args->pitch * args->height;
-
-	ret = drm_gem_dma_dumb_create(file_priv, drm, args);
+	/*
+	 * Hardware requires the framebuffer width to be aligned to
+	 * multiples of 8. The mode-setting code handles this, but
+	 * the buffer pitch has to be aligned as well. Set the pitch
+	 * alignment accordingly, so that the each scanline fits into
+	 * the allocated buffer.
+	 */
+	fourcc = drm_driver_color_mode_format(drm, args->bpp);
+	if (fourcc == DRM_FORMAT_INVALID)
+		return -EINVAL;
+	info = drm_format_info(fourcc);
+	if (!info)
+		return -EINVAL;
+	pitch_align = drm_format_info_min_pitch(info, 0, SZ_8);
+	if (!pitch_align || pitch_align > U32_MAX)
+		return -EINVAL;
+	ret = drm_mode_size_dumb(drm, args, pitch_align, 0);
 	if (ret)
 		return ret;
 
-	args->width = width;
-	return ret;
+	return drm_gem_dma_dumb_create(file_priv, drm, args);
 }
 
 static const struct drm_driver imx_drm_driver = {
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:03:28 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:03:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868529.1280115 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVu4F-0001g6-2B; Thu, 09 Jan 2025 15:03:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868529.1280115; Thu, 09 Jan 2025 15:03:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVu4E-0001aT-2k; Thu, 09 Jan 2025 15:03:26 +0000
Received: by outflank-mailman (input) for mailman id 868529;
 Thu, 09 Jan 2025 15:03:23 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=BoWZ=UB=suse.de=tzimmermann@srs-se1.protection.inumbo.net>)
 id 1tVu4B-0007zg-OT
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:03:23 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id dedb8ae9-ce9a-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 16:03:23 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id BAFFA21174;
 Thu,  9 Jan 2025 15:03:21 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 24BE1139AB;
 Thu,  9 Jan 2025 15:03:21 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id 8J+aBznlf2c1awAAD6G6ig
 (envelope-from <tzimmermann@suse.de>); Thu, 09 Jan 2025 15:03:21 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: dedb8ae9-ce9a-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736435003; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=AgJ1Uel3fQ0OFlYjfDZNvHPH7R5FmE1kSGP9lTwtvrY=;
	b=Fe1uDndM2y7P0uvzje0g0g0qeEJEDI2lgge0X0K7TDScfle35Lic5QYsPGtXFgdeCyWQdL
	VMicoZh4aAaZwRfbqOKlvSwqw5ySex6R7/MKzIzoy90Tx6gqa1M6Vb6IN11C4GJfAdqYfc
	pyKW9qvmiGnLL9SPCKK2Ir0/oXgAcRg=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736435003;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=AgJ1Uel3fQ0OFlYjfDZNvHPH7R5FmE1kSGP9lTwtvrY=;
	b=IS3is//aQ5D9PkvNXBl60gAhz0vI3nonfLEkLctfTgBtfLjh+vfRDyMpjnA/VB0R2wA546
	iIFWZJE0QInDgWCA==
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736435001; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=AgJ1Uel3fQ0OFlYjfDZNvHPH7R5FmE1kSGP9lTwtvrY=;
	b=mPNZxbxW1B1UdWkIay1zim9xbTFMuUyhV6RrZjYXa6GyM341tf4FDtC0KM0NuOfato3TbO
	Z7lIEA5yaCEwzUMTHDiFMGQz+IQEfiDTNR7+jGp4vXxmTKrXt8/i2SXdxm6xzmGA7L79Mb
	vYiB2Coam5Ct8oCetk3uJUWnOp127Ag=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736435001;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=AgJ1Uel3fQ0OFlYjfDZNvHPH7R5FmE1kSGP9lTwtvrY=;
	b=qWKUwcnlINfcVzk4Fogtu8Rng/AVTI8qT4RTm+Em8OX+dIsxho6s2JLThdC3oHgt48Mlu3
	NinqtG50OUGTZmBQ==
From: Thomas Zimmermann <tzimmermann@suse.de>
To: maarten.lankhorst@linux.intel.com,
	mripard@kernel.org,
	airlied@gmail.com,
	simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Chun-Kuang Hu <chunkuang.hu@kernel.org>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Subject: [PATCH v2 12/25] drm/mediatek: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Thu,  9 Jan 2025 15:57:06 +0100
Message-ID: <20250109150310.219442-13-tzimmermann@suse.de>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250109150310.219442-1-tzimmermann@suse.de>
References: <20250109150310.219442-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Score: -1.30
X-Spamd-Result: default: False [-1.30 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[collabora.com:email,imap1.dmz-prg2.suse.org:helo,suse.de:mid,suse.de:email];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MIME_TRACE(0.00)[0:+];
	TAGGED_RCPT(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[23];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_CC(0.00)[lists.freedesktop.org,lists.infradead.org,vger.kernel.org,lists.linux.dev,lists.xenproject.org,suse.de,kernel.org,pengutronix.de,gmail.com,collabora.com];
	FROM_HAS_DN(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FREEMAIL_TO(0.00)[linux.intel.com,kernel.org,gmail.com,ffwll.ch];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	TO_DN_SOME(0.00)[];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-Spam-Flag: NO
X-Spam-Level: 

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch to a multiple of 8.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
 drivers/gpu/drm/mediatek/mtk_gem.c | 13 ++++---------
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_gem.c b/drivers/gpu/drm/mediatek/mtk_gem.c
index a172456d1d7b..21e08fabfd7f 100644
--- a/drivers/gpu/drm/mediatek/mtk_gem.c
+++ b/drivers/gpu/drm/mediatek/mtk_gem.c
@@ -8,6 +8,7 @@
 
 #include <drm/drm.h>
 #include <drm/drm_device.h>
+#include <drm/drm_dumb_buffers.h>
 #include <drm/drm_gem.h>
 #include <drm/drm_gem_dma_helper.h>
 #include <drm/drm_prime.h>
@@ -124,15 +125,9 @@ int mtk_gem_dumb_create(struct drm_file *file_priv, struct drm_device *dev,
 	struct mtk_gem_obj *mtk_gem;
 	int ret;
 
-	args->pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
-
-	/*
-	 * Multiply 2 variables of different types,
-	 * for example: args->size = args->spacing * args->height;
-	 * may cause coverity issue with unintentional overflow.
-	 */
-	args->size = args->pitch;
-	args->size *= args->height;
+	ret = drm_mode_size_dumb(dev, args, SZ_8, 0);
+	if (ret)
+		return ret;
 
 	mtk_gem = mtk_gem_create(dev, args->size, false);
 	if (IS_ERR(mtk_gem))
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:03:28 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:03:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868530.1280130 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVu4G-000238-Ho; Thu, 09 Jan 2025 15:03:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868530.1280130; Thu, 09 Jan 2025 15:03:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVu4F-0001zt-RP; Thu, 09 Jan 2025 15:03:27 +0000
Received: by outflank-mailman (input) for mailman id 868530;
 Thu, 09 Jan 2025 15:03:24 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=BoWZ=UB=suse.de=tzimmermann@srs-se1.protection.inumbo.net>)
 id 1tVu4C-0007zg-04
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:03:24 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id dedc68a2-ce9a-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 16:03:23 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id E721721175;
 Thu,  9 Jan 2025 15:03:22 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 5CBB713A9E;
 Thu,  9 Jan 2025 15:03:22 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id uNFbFTrlf2c1awAAD6G6ig
 (envelope-from <tzimmermann@suse.de>); Thu, 09 Jan 2025 15:03:22 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: dedc68a2-ce9a-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736435002; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=wRpUybXQ3IoxKMifg+lwMpUmgyWaomPjVOJ6r5kSHgs=;
	b=VLl6xT+5I8TPVHFOngQvYEhQnG+lUfRt14fa/OjgqeYdGeqEquD1A2cIljbfujJElXUaW7
	N0X+zY/Tjg5iB2babKHZymfb2ZbSqd29IJsIaU5nOrh5Mf1QSdMFmrhTnXvXCRGUvQQ25l
	TIeVK8Qk+K8CI0HaqN4x2NeJzjUtH8U=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736435002;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=wRpUybXQ3IoxKMifg+lwMpUmgyWaomPjVOJ6r5kSHgs=;
	b=fifjMAqLN7G35kS2kbwkJDE22Y1i9PVbWvFm0yUA/mq4aAxNwp3cV56ksFYNk3aK7fR7td
	B/GzL1hODSXNO+Cw==
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736435002; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=wRpUybXQ3IoxKMifg+lwMpUmgyWaomPjVOJ6r5kSHgs=;
	b=VLl6xT+5I8TPVHFOngQvYEhQnG+lUfRt14fa/OjgqeYdGeqEquD1A2cIljbfujJElXUaW7
	N0X+zY/Tjg5iB2babKHZymfb2ZbSqd29IJsIaU5nOrh5Mf1QSdMFmrhTnXvXCRGUvQQ25l
	TIeVK8Qk+K8CI0HaqN4x2NeJzjUtH8U=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736435002;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=wRpUybXQ3IoxKMifg+lwMpUmgyWaomPjVOJ6r5kSHgs=;
	b=fifjMAqLN7G35kS2kbwkJDE22Y1i9PVbWvFm0yUA/mq4aAxNwp3cV56ksFYNk3aK7fR7td
	B/GzL1hODSXNO+Cw==
From: Thomas Zimmermann <tzimmermann@suse.de>
To: maarten.lankhorst@linux.intel.com,
	mripard@kernel.org,
	airlied@gmail.com,
	simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Karol Herbst <kherbst@redhat.com>,
	Lyude Paul <lyude@redhat.com>,
	Danilo Krummrich <dakr@kernel.org>
Subject: [PATCH v2 14/25] drm/nouveau: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Thu,  9 Jan 2025 15:57:08 +0100
Message-ID: <20250109150310.219442-15-tzimmermann@suse.de>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250109150310.219442-1-tzimmermann@suse.de>
References: <20250109150310.219442-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Level: 
X-Spamd-Result: default: False [-1.30 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:email,suse.de:mid,imap1.dmz-prg2.suse.org:helo];
	RCPT_COUNT_TWELVE(0.00)[22];
	MIME_TRACE(0.00)[0:+];
	TO_DN_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	FREEMAIL_TO(0.00)[linux.intel.com,kernel.org,gmail.com,ffwll.ch];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	R_RATELIMIT(0.00)[to_ip_from(RLqirfcw6gnbcr9a9yhi49fhi6)];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-Spam-Score: -1.30
X-Spam-Flag: NO

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch to a multiple of 256.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Karol Herbst <kherbst@redhat.com>
Cc: Lyude Paul <lyude@redhat.com>
Cc: Danilo Krummrich <dakr@kernel.org>
---
 drivers/gpu/drm/nouveau/nouveau_display.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.c
index add006fc8d81..daa2528f9c9a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -30,6 +30,7 @@
 #include <drm/drm_atomic_helper.h>
 #include <drm/drm_client_event.h>
 #include <drm/drm_crtc_helper.h>
+#include <drm/drm_dumb_buffers.h>
 #include <drm/drm_fourcc.h>
 #include <drm/drm_gem_framebuffer_helper.h>
 #include <drm/drm_probe_helper.h>
@@ -808,9 +809,9 @@ nouveau_display_dumb_create(struct drm_file *file_priv, struct drm_device *dev,
 	uint32_t domain;
 	int ret;
 
-	args->pitch = roundup(args->width * (args->bpp / 8), 256);
-	args->size = args->pitch * args->height;
-	args->size = roundup(args->size, PAGE_SIZE);
+	ret = drm_mode_size_dumb(dev, args, SZ_256, 0);
+	if (ret)
+		return ret;
 
 	/* Use VRAM if there is any ; otherwise fallback to system memory */
 	if (nouveau_drm(dev)->client.device.info.ram_size != 0)
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:03:29 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:03:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868532.1280137 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVu4H-0002DY-8E; Thu, 09 Jan 2025 15:03:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868532.1280137; Thu, 09 Jan 2025 15:03:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVu4G-00029d-K5; Thu, 09 Jan 2025 15:03:28 +0000
Received: by outflank-mailman (input) for mailman id 868532;
 Thu, 09 Jan 2025 15:03:24 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=BoWZ=UB=suse.de=tzimmermann@srs-se1.protection.inumbo.net>)
 id 1tVu4C-0007zg-Oc
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:03:24 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de
 [2a07:de40:b251:101:10:150:64:1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id df41914b-ce9a-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 16:03:23 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id 780B521176;
 Thu,  9 Jan 2025 15:03:23 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id E8CA413AA7;
 Thu,  9 Jan 2025 15:03:22 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id GDmLNzrlf2c1awAAD6G6ig
 (envelope-from <tzimmermann@suse.de>); Thu, 09 Jan 2025 15:03:22 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: df41914b-ce9a-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736435003; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=3o8YijqW7m/S5WxSzbbW/Q5FOb5jd8geeefF53uQ3Sk=;
	b=E4gyrWDSGtocRabFdSS5vO711dWQ2MU575H8KfCe4OIkyPCA64KXntTrgwB04h8JcFr5ij
	xGfFwNJcpSOGvfLup/xsh5sfcWUTxBtKhvkwanObi0+W+5qbhuBGzvR2cpxkr34FuFR2Aa
	8mjAZNQsz4nyJhK9QAybn0E0vXObC2c=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736435003;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=3o8YijqW7m/S5WxSzbbW/Q5FOb5jd8geeefF53uQ3Sk=;
	b=g1BuhauSMOd9WqdOfRXc+TgRctQC+2ed7h7cFyLQpsl0EwtIe/Yr6P+pyfq3JSAjSvvpPJ
	3Yoz+g7dCFqbVDBg==
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736435003; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=3o8YijqW7m/S5WxSzbbW/Q5FOb5jd8geeefF53uQ3Sk=;
	b=E4gyrWDSGtocRabFdSS5vO711dWQ2MU575H8KfCe4OIkyPCA64KXntTrgwB04h8JcFr5ij
	xGfFwNJcpSOGvfLup/xsh5sfcWUTxBtKhvkwanObi0+W+5qbhuBGzvR2cpxkr34FuFR2Aa
	8mjAZNQsz4nyJhK9QAybn0E0vXObC2c=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736435003;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=3o8YijqW7m/S5WxSzbbW/Q5FOb5jd8geeefF53uQ3Sk=;
	b=g1BuhauSMOd9WqdOfRXc+TgRctQC+2ed7h7cFyLQpsl0EwtIe/Yr6P+pyfq3JSAjSvvpPJ
	3Yoz+g7dCFqbVDBg==
From: Thomas Zimmermann <tzimmermann@suse.de>
To: maarten.lankhorst@linux.intel.com,
	mripard@kernel.org,
	airlied@gmail.com,
	simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Subject: [PATCH v2 15/25] drm/omapdrm: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Thu,  9 Jan 2025 15:57:09 +0100
Message-ID: <20250109150310.219442-16-tzimmermann@suse.de>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250109150310.219442-1-tzimmermann@suse.de>
References: <20250109150310.219442-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Level: 
X-Spamd-Result: default: False [-1.30 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,suse.de:email,suse.de:mid];
	RCPT_COUNT_TWELVE(0.00)[20];
	MIME_TRACE(0.00)[0:+];
	TO_DN_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	FREEMAIL_TO(0.00)[linux.intel.com,kernel.org,gmail.com,ffwll.ch];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	R_RATELIMIT(0.00)[to_ip_from(RLqirfcw6gnbcr9a9yhi49fhi6),to(RLbwen1niosrcqbxsafh1)];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-Spam-Score: -1.30
X-Spam-Flag: NO

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch to a multiple of 8.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
 drivers/gpu/drm/omapdrm/omap_gem.c | 15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c b/drivers/gpu/drm/omapdrm/omap_gem.c
index b9c67e4ca360..b8413a2dcdeb 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -11,6 +11,7 @@
 #include <linux/pfn_t.h>
 #include <linux/vmalloc.h>
 
+#include <drm/drm_dumb_buffers.h>
 #include <drm/drm_prime.h>
 #include <drm/drm_vma_manager.h>
 
@@ -583,15 +584,13 @@ static int omap_gem_object_mmap(struct drm_gem_object *obj, struct vm_area_struc
 int omap_gem_dumb_create(struct drm_file *file, struct drm_device *dev,
 		struct drm_mode_create_dumb *args)
 {
-	union omap_gem_size gsize;
-
-	args->pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
-
-	args->size = PAGE_ALIGN(args->pitch * args->height);
+	union omap_gem_size gsize = { };
+	int ret;
 
-	gsize = (union omap_gem_size){
-		.bytes = args->size,
-	};
+	ret = drm_mode_size_dumb(dev, args, SZ_8, 0);
+	if (ret)
+		return ret;
+	gsize.bytes = args->size;
 
 	return omap_gem_new_handle(dev, file, gsize,
 			OMAP_BO_SCANOUT | OMAP_BO_WC, &args->handle);
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:03:30 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:03:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868533.1280139 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVu4H-0002Q5-SN; Thu, 09 Jan 2025 15:03:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868533.1280139; Thu, 09 Jan 2025 15:03:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVu4H-0002LL-BU; Thu, 09 Jan 2025 15:03:29 +0000
Received: by outflank-mailman (input) for mailman id 868533;
 Thu, 09 Jan 2025 15:03:26 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=BoWZ=UB=suse.de=tzimmermann@srs-se1.protection.inumbo.net>)
 id 1tVu4D-0007zg-Oo
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:03:25 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id df38d34e-ce9a-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 16:03:23 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id 560EC1F455;
 Thu,  9 Jan 2025 15:03:22 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id B7E8113A8B;
 Thu,  9 Jan 2025 15:03:21 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id sNaEKznlf2c1awAAD6G6ig
 (envelope-from <tzimmermann@suse.de>); Thu, 09 Jan 2025 15:03:21 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: df38d34e-ce9a-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736435003; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=dlB8gALn1o96mpymG+jR60eAc3m1/AcHQiXg4BbiBLc=;
	b=twwf6bRkpdKoZbvnVil5OIS9zFS4Nl4YkETG5YWHIzRH9t2fNHB9NPCN+go+XqNXJHgCB1
	q27ZcbHf0nXJdntb4Z1YeAcXls8jYY5WwKYpVRr7Zz1in9ZdSactUKaLDdc6YjJ8IYsmx8
	caSjErYSXtXv87RFGViu9+DIDVMdDvI=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736435003;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=dlB8gALn1o96mpymG+jR60eAc3m1/AcHQiXg4BbiBLc=;
	b=MDWzRXw1agMN0fVPgxJSAd9CV57KEnNuZFPPF1FOZml8wr0xK3LyjP64b95ZKMqRJRLph+
	pHKfciLuwypgCLCw==
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736435002; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=dlB8gALn1o96mpymG+jR60eAc3m1/AcHQiXg4BbiBLc=;
	b=aTd4wlIjW2Ym/cI/L10oTJnpoZoVXB9QiHOfV6piOCDx5zzt8S9b742qbwpr+coTsfCQAH
	KTGj8R3O3J65bIygefD8Cw4x+GF6gLHkhHsE4sbDsoJd+sNisUowc4D7hjWLGhzj3wOfZf
	3dsPNHfTS9ILQydyYFiqzNYAHVmpr14=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736435002;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=dlB8gALn1o96mpymG+jR60eAc3m1/AcHQiXg4BbiBLc=;
	b=Pe3ScWyOfQDGNKt/GkTehVmf7gpnpBC2JJpDrTJq3GWNdC+oMbIkbH3leZ23JIzhLy83t4
	bsI2LaOWdyCUmqCQ==
From: Thomas Zimmermann <tzimmermann@suse.de>
To: maarten.lankhorst@linux.intel.com,
	mripard@kernel.org,
	airlied@gmail.com,
	simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Rob Clark <robdclark@gmail.com>,
	Abhinav Kumar <quic_abhinavk@quicinc.com>,
	Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
	Sean Paul <sean@poorly.run>,
	Marijn Suijten <marijn.suijten@somainline.org>
Subject: [PATCH v2 13/25] drm/msm: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Thu,  9 Jan 2025 15:57:07 +0100
Message-ID: <20250109150310.219442-14-tzimmermann@suse.de>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250109150310.219442-1-tzimmermann@suse.de>
References: <20250109150310.219442-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Score: -1.30
X-Spamd-Result: default: False [-1.30 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[somainline.org:email,quicinc.com:email,suse.de:mid,suse.de:email,imap1.dmz-prg2.suse.org:helo,linaro.org:email,poorly.run:email];
	MIME_TRACE(0.00)[0:+];
	RCPT_COUNT_TWELVE(0.00)[24];
	RCVD_TLS_ALL(0.00)[];
	TO_DN_SOME(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_CC(0.00)[lists.freedesktop.org,lists.infradead.org,vger.kernel.org,lists.linux.dev,lists.xenproject.org,suse.de,gmail.com,quicinc.com,linaro.org,poorly.run,somainline.org];
	FROM_HAS_DN(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FREEMAIL_TO(0.00)[linux.intel.com,kernel.org,gmail.com,ffwll.ch];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	R_RATELIMIT(0.00)[to_ip_from(RLqirfcw6gnbcr9a9yhi49fhi6)];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-Spam-Flag: NO
X-Spam-Level: 

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. The hardware requires the scnaline pitch to be a multiple
of 32 pixels. Therefore compute the byte size of 32 pixels in the given
color mode and align the pitch accordingly.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Abhinav Kumar <quic_abhinavk@quicinc.com>
Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Sean Paul <sean@poorly.run>
Cc: Marijn Suijten <marijn.suijten@somainline.org>
---
 drivers/gpu/drm/msm/msm_gem.c | 27 +++++++++++++++++++++++++--
 1 file changed, 25 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index ebc9ba66efb8..a956905f1ef2 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -11,8 +11,10 @@
 #include <linux/dma-buf.h>
 #include <linux/pfn_t.h>
 
+#include <drm/drm_dumb_buffers.h>
 #include <drm/drm_prime.h>
 #include <drm/drm_file.h>
+#include <drm/drm_fourcc.h>
 
 #include <trace/events/gpu_mem.h>
 
@@ -700,8 +702,29 @@ void msm_gem_unpin_iova(struct drm_gem_object *obj,
 int msm_gem_dumb_create(struct drm_file *file, struct drm_device *dev,
 		struct drm_mode_create_dumb *args)
 {
-	args->pitch = align_pitch(args->width, args->bpp);
-	args->size  = PAGE_ALIGN(args->pitch * args->height);
+	u32 fourcc;
+	const struct drm_format_info *info;
+	u64 pitch_align;
+	int ret;
+
+	/*
+	 * Adreno needs pitch aligned to 32 pixels. Compute the number
+	 * of bytes for a block of 32 pixels at the given color format.
+	 * Use the result as pitch alignment.
+	 */
+	fourcc = drm_driver_color_mode_format(dev, args->bpp);
+	if (fourcc == DRM_FORMAT_INVALID)
+		return -EINVAL;
+	info = drm_format_info(fourcc);
+	if (!info)
+		return -EINVAL;
+	pitch_align = drm_format_info_min_pitch(info, 0, SZ_32);
+	if (!pitch_align || pitch_align > U32_MAX)
+		return -EINVAL;
+	ret = drm_mode_size_dumb(dev, args, pitch_align, 0);
+	if (ret)
+		return ret;
+
 	return msm_gem_new_handle(dev, file, args->size,
 			MSM_BO_SCANOUT | MSM_BO_WC, &args->handle, "dumb");
 }
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:03:33 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:03:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868534.1280154 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVu4K-0002xA-HJ; Thu, 09 Jan 2025 15:03:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868534.1280154; Thu, 09 Jan 2025 15:03:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVu4J-0002rW-GQ; Thu, 09 Jan 2025 15:03:31 +0000
Received: by outflank-mailman (input) for mailman id 868534;
 Thu, 09 Jan 2025 15:03:26 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=BoWZ=UB=suse.de=tzimmermann@srs-se1.protection.inumbo.net>)
 id 1tVu4D-0007zt-VS
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:03:25 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de
 [2a07:de40:b251:101:10:150:64:1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id df90a30d-ce9a-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 16:03:24 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id 0A54421177;
 Thu,  9 Jan 2025 15:03:24 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 7C79D139AB;
 Thu,  9 Jan 2025 15:03:23 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id 0DMbHTvlf2c1awAAD6G6ig
 (envelope-from <tzimmermann@suse.de>); Thu, 09 Jan 2025 15:03:23 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: df90a30d-ce9a-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736435004; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=dH0e4KfjnMGaRabx2kD9CiC04UroRsnN8GiYA0fiJw0=;
	b=S/HM/ivVw4nSHXWwwFc1+f6nfph4uCLa/EOzjJ8AX0VzALmJbWeOQtQrlwJ8vIdGc8ef5R
	WwBlMZ/rHwayvqcOZdMinRYW3FLhQ+YZHt4gv2GYt7m4MBbDMEwnAtXrTLbC/rYII4ZSx3
	wPlmxet1HRRKthur3CeedIT3ZauxtPw=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736435004;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=dH0e4KfjnMGaRabx2kD9CiC04UroRsnN8GiYA0fiJw0=;
	b=E8uXSNXOlj3RxxjIPDmDQ3W8U8BNwXarhB68Z4U5QqKgEz5+Fyoy+Dj6Bp6XKGF3iqdqy7
	dY/fo33C4Oe96zCg==
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.de header.s=susede2_rsa header.b="S/HM/ivV";
	dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=E8uXSNXO
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736435004; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=dH0e4KfjnMGaRabx2kD9CiC04UroRsnN8GiYA0fiJw0=;
	b=S/HM/ivVw4nSHXWwwFc1+f6nfph4uCLa/EOzjJ8AX0VzALmJbWeOQtQrlwJ8vIdGc8ef5R
	WwBlMZ/rHwayvqcOZdMinRYW3FLhQ+YZHt4gv2GYt7m4MBbDMEwnAtXrTLbC/rYII4ZSx3
	wPlmxet1HRRKthur3CeedIT3ZauxtPw=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736435004;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=dH0e4KfjnMGaRabx2kD9CiC04UroRsnN8GiYA0fiJw0=;
	b=E8uXSNXOlj3RxxjIPDmDQ3W8U8BNwXarhB68Z4U5QqKgEz5+Fyoy+Dj6Bp6XKGF3iqdqy7
	dY/fo33C4Oe96zCg==
From: Thomas Zimmermann <tzimmermann@suse.de>
To: maarten.lankhorst@linux.intel.com,
	mripard@kernel.org,
	airlied@gmail.com,
	simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Dave Airlie <airlied@redhat.com>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: [PATCH v2 16/25] drm/qxl: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Thu,  9 Jan 2025 15:57:10 +0100
Message-ID: <20250109150310.219442-17-tzimmermann@suse.de>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250109150310.219442-1-tzimmermann@suse.de>
References: <20250109150310.219442-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 0A54421177
X-Spam-Score: -1.51
X-Rspamd-Action: no action
X-Spamd-Result: default: False [-1.51 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	R_DKIM_ALLOW(-0.20)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo,suse.de:dkim,suse.de:mid,suse.de:email];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_TO(0.00)[linux.intel.com,kernel.org,gmail.com,ffwll.ch];
	RCPT_COUNT_TWELVE(0.00)[21];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:25478, ipnet:::/0, country:RU];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	R_RATELIMIT(0.00)[to(RLbwen1niosrcqbxsafh1),to_ip_from(RLqtkr6cif1ebgurukgmwdm7xc)];
	RCVD_TLS_ALL(0.00)[];
	DKIM_TRACE(0.00)[suse.de:+];
	TO_DN_SOME(0.00)[];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spam-Flag: NO
X-Spam-Level: 

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch
and buffer size. No alignment required.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
---
 drivers/gpu/drm/qxl/qxl_dumb.c | 17 ++++++++---------
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_dumb.c b/drivers/gpu/drm/qxl/qxl_dumb.c
index 17df5c7ccf69..1200946767ce 100644
--- a/drivers/gpu/drm/qxl/qxl_dumb.c
+++ b/drivers/gpu/drm/qxl/qxl_dumb.c
@@ -23,6 +23,8 @@
  *          Alon Levy
  */
 
+#include <drm/drm_dumb_buffers.h>
+
 #include "qxl_drv.h"
 #include "qxl_object.h"
 
@@ -35,14 +37,13 @@ int qxl_mode_dumb_create(struct drm_file *file_priv,
 	struct qxl_device *qdev = to_qxl(dev);
 	struct qxl_bo *qobj;
 	struct drm_gem_object *gobj;
-	uint32_t handle;
 	int r;
 	struct qxl_surface surf;
-	uint32_t pitch, format;
+	u32 format;
 
-	pitch = args->width * ((args->bpp + 1) / 8);
-	args->size = pitch * args->height;
-	args->size = ALIGN(args->size, PAGE_SIZE);
+	r = drm_mode_size_dumb(dev, args, 0, 0);
+	if (r)
+		return r;
 
 	switch (args->bpp) {
 	case 16:
@@ -57,20 +58,18 @@ int qxl_mode_dumb_create(struct drm_file *file_priv,
 
 	surf.width = args->width;
 	surf.height = args->height;
-	surf.stride = pitch;
+	surf.stride = args->pitch;
 	surf.format = format;
 	surf.data = 0;
 
 	r = qxl_gem_object_create_with_handle(qdev, file_priv,
 					      QXL_GEM_DOMAIN_CPU,
 					      args->size, &surf, &gobj,
-					      &handle);
+					      &args->handle);
 	if (r)
 		return r;
 	qobj = gem_to_qxl_bo(gobj);
 	qobj->is_dumb = true;
 	drm_gem_object_put(gobj);
-	args->pitch = pitch;
-	args->handle = handle;
 	return 0;
 }
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:03:34 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:03:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868537.1280164 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVu4L-0003AS-Hg; Thu, 09 Jan 2025 15:03:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868537.1280164; Thu, 09 Jan 2025 15:03:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVu4K-00033P-O8; Thu, 09 Jan 2025 15:03:32 +0000
Received: by outflank-mailman (input) for mailman id 868537;
 Thu, 09 Jan 2025 15:03:27 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=BoWZ=UB=suse.de=tzimmermann@srs-se1.protection.inumbo.net>)
 id 1tVu4F-0007zt-8n
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:03:27 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id dfd2f1fe-ce9a-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 16:03:24 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id 91EDE1F452;
 Thu,  9 Jan 2025 15:03:24 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 10B2E13A8B;
 Thu,  9 Jan 2025 15:03:24 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id oAvFAjzlf2c1awAAD6G6ig
 (envelope-from <tzimmermann@suse.de>); Thu, 09 Jan 2025 15:03:24 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: dfd2f1fe-ce9a-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736435004; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=k1UJEOgmu4DizOjSpueREjRYjeVXr8tBdnGPjCF7RPM=;
	b=gBK2lHZmTKxdF6DFjG65jg8B6ziHVovO0B8A/EDCOjQ8MtQjp6Uq9m3Vx9EwfGbBqH2WlR
	DQ+pa2navmevobmPEs5X80JnWVXN6k9gsWrh0oEEefEAoMTogLES3Yf/+weWcbgwiPB2QV
	T4kOCd9/lrQJgdHzTORT2l0lpKOH8AM=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736435004;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=k1UJEOgmu4DizOjSpueREjRYjeVXr8tBdnGPjCF7RPM=;
	b=FyGBWCUej489fJy/+vpJBiWrmFyrKWiCpCKHZ8Ggufcth8cxNehONd76qQRdZJ5Yu9aN2L
	6GAAkLVl85Tig5Ag==
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.de header.s=susede2_rsa header.b=gBK2lHZm;
	dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=FyGBWCUe
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736435004; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=k1UJEOgmu4DizOjSpueREjRYjeVXr8tBdnGPjCF7RPM=;
	b=gBK2lHZmTKxdF6DFjG65jg8B6ziHVovO0B8A/EDCOjQ8MtQjp6Uq9m3Vx9EwfGbBqH2WlR
	DQ+pa2navmevobmPEs5X80JnWVXN6k9gsWrh0oEEefEAoMTogLES3Yf/+weWcbgwiPB2QV
	T4kOCd9/lrQJgdHzTORT2l0lpKOH8AM=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736435004;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=k1UJEOgmu4DizOjSpueREjRYjeVXr8tBdnGPjCF7RPM=;
	b=FyGBWCUej489fJy/+vpJBiWrmFyrKWiCpCKHZ8Ggufcth8cxNehONd76qQRdZJ5Yu9aN2L
	6GAAkLVl85Tig5Ag==
From: Thomas Zimmermann <tzimmermann@suse.de>
To: maarten.lankhorst@linux.intel.com,
	mripard@kernel.org,
	airlied@gmail.com,
	simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Subject: [PATCH v2 17/25] drm/renesas/rcar-du: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Thu,  9 Jan 2025 15:57:11 +0100
Message-ID: <20250109150310.219442-18-tzimmermann@suse.de>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250109150310.219442-1-tzimmermann@suse.de>
References: <20250109150310.219442-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 91EDE1F452
X-Spam-Score: -1.51
X-Rspamd-Action: no action
X-Spamd-Result: default: False [-1.51 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	R_DKIM_ALLOW(-0.20)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[21];
	FREEMAIL_TO(0.00)[linux.intel.com,kernel.org,gmail.com,ffwll.ch];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	RCVD_TLS_ALL(0.00)[];
	DKIM_TRACE(0.00)[suse.de:+];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo,suse.de:dkim,suse.de:mid,suse.de:email];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TAGGED_RCPT(0.00)[renesas];
	R_RATELIMIT(0.00)[to_ip_from(RLqtkr6cif1ebgurukgmwdm7xc),to(RLbwen1niosrcqbxsafh1)];
	ASN(0.00)[asn:25478, ipnet:::/0, country:RU];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spam-Flag: NO
X-Spam-Level: 

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch according to hardware requirements.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
---
 drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
index 70d8ad065bfa..32c8307da522 100644
--- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
@@ -11,6 +11,7 @@
 #include <drm/drm_atomic_helper.h>
 #include <drm/drm_crtc.h>
 #include <drm/drm_device.h>
+#include <drm/drm_dumb_buffers.h>
 #include <drm/drm_framebuffer.h>
 #include <drm/drm_gem_dma_helper.h>
 #include <drm/drm_gem_framebuffer_helper.h>
@@ -407,8 +408,8 @@ int rcar_du_dumb_create(struct drm_file *file, struct drm_device *dev,
 			struct drm_mode_create_dumb *args)
 {
 	struct rcar_du_device *rcdu = to_rcar_du_device(dev);
-	unsigned int min_pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
 	unsigned int align;
+	int ret;
 
 	/*
 	 * The R8A7779 DU requires a 16 pixels pitch alignment as documented,
@@ -419,7 +420,9 @@ int rcar_du_dumb_create(struct drm_file *file, struct drm_device *dev,
 	else
 		align = 16 * args->bpp / 8;
 
-	args->pitch = roundup(min_pitch, align);
+	ret = drm_mode_size_dumb(dev, args, align, 0);
+	if (ret)
+		return ret;
 
 	return drm_gem_dma_dumb_create_internal(file, dev, args);
 }
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:08:22 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:08:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868615.1280201 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVu8z-0000mf-9H; Thu, 09 Jan 2025 15:08:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868615.1280201; Thu, 09 Jan 2025 15:08:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVu8z-0000mY-5j; Thu, 09 Jan 2025 15:08:21 +0000
Received: by outflank-mailman (input) for mailman id 868615;
 Thu, 09 Jan 2025 15:08:20 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=bl7y=UB=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tVu8y-0000mS-5V
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:08:20 +0000
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com
 [2a00:1450:4864:20::434])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8edc386b-ce9b-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 16:08:18 +0100 (CET)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-385ef8b64b3so951523f8f.0
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 07:08:18 -0800 (PST)
Received: from localhost ([66.81.170.107]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436e9d26a7bsm25020495e9.0.2025.01.09.07.08.16
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 07:08:16 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8edc386b-ce9b-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736435298; x=1737040098; darn=lists.xenproject.org;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=lpHS3CLRqwjBeCtRk1rXsfSsyI5n4Smr+9iJA/k0piE=;
        b=awLBixL1rQ1gKdijkld6kpmetayxie10UwpL3oTqoR7h0CrF/Z8iC1dhdwW9v9N+oW
         MSm0qg+YyK4FdWtxsY/x1LM+iv4MFJgCvM4JlZSUPVMzDjoX/DUA4wbri2WuZEJA0wxW
         6Kc9t4eASEhhKYfipxHX7dReJbsouCkyvP+7A=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736435298; x=1737040098;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=lpHS3CLRqwjBeCtRk1rXsfSsyI5n4Smr+9iJA/k0piE=;
        b=LzKHmTgqLLV3XI//w6yv5byFE0nmAtdzpXK6lVlCHStv4eV+eAUK8xA/0QSC8Zoh37
         qAJjVvqL8IwuL7I288+XGi/9K63pfohBNwqaVBCQHTgofrwqx/tF0+EJmVpjLRiuqXK8
         sYdJ+1t0xpl1cap0s7nTvKdb5ps68WYx3jbH3vgFyTmSIr7pmojl8c+heaME3T75/oZI
         mogjmDGN27G+rbCKExqsamGXaWJo6R9JvPDMqD0aWINXHySa8GfuYZoRdL5jANCo8Gly
         XmytCk8DBIDOrwWOe5l2+bZvcnsqteoM0PUwxehMrehBr6UjSC8etK8zps0+RD48JU6L
         ZyXQ==
X-Forwarded-Encrypted: i=1; AJvYcCWVbwhqsvshTr35Q9gWN7sI3QEs5+PTVcGWhrN4WA8SAxQI56Lx0Han3uOhS9Y3oTKi+ws46HkeO4k=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyiPT0+zayImSdeS3lS1ZkSw1RAKaXLkRoAuHkEoqTXCdnrw0+r
	usRUd6+zjtv0Db/7isUS/uqJa34pR7ZgoaaNqZOD0GILXqLIRtar9ud9ecoZNM4=
X-Gm-Gg: ASbGncvmCWtaafdRAjpizRyRlTrFTwJX2Q0hR1eSP2Hp9ZX5rkd59OrxZUeBfqk3r0A
	KXY3SYTMt+tQvlc3A9DUNMtB9zSCfKtatLBPnWntw6AJ9E82LoZ9i2SsOYGx417TuogUYsL9NRz
	viJ0ECXU+CFOI4xpmidCsRuPq9NU8C2EWZsc2n0uDJg+0C7cRUFxTMdtZbw3QOPBsZUfV2O2P/o
	bu/BPYRf+42NDdWegceOH+cLrdYuxfrU47jVrzwxjO3PnIYnGqpU8yYCWHSJWM=
X-Google-Smtp-Source: AGHT+IHEs/6HGlugKZTEblyFNdg7cteinAR3dM8ti0nLcb/Xles8JrF4da534DewHrWDgPaIjGvn/A==
X-Received: by 2002:a5d:6c64:0:b0:385:ec6e:e87a with SMTP id ffacd0b85a97d-38a8730fc40mr7290828f8f.43.1736435297195;
        Thu, 09 Jan 2025 07:08:17 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Thu, 09 Jan 2025 15:08:15 +0000
Message-Id: <D6XMXUBHE5UI.16YI6AVTYXNUM@cloud.com>
Cc: "Jan Beulich" <jbeulich@suse.com>, "Andrew Cooper"
 <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v2 15/18] x86/mm: introduce a per-vCPU mapcache when
 using ASI
From: "Alejandro Vallejo" <alejandro.vallejo@cloud.com>
To: "Roger Pau Monne" <roger.pau@citrix.com>,
 <xen-devel@lists.xenproject.org>
X-Mailer: aerc 0.18.2
References: <20250108142659.99490-1-roger.pau@citrix.com>
 <20250108142659.99490-16-roger.pau@citrix.com>
In-Reply-To: <20250108142659.99490-16-roger.pau@citrix.com>

On Wed Jan 8, 2025 at 2:26 PM GMT, Roger Pau Monne wrote:
> When using a unique per-vCPU root page table the per-domain region become=
s
> per-vCPU, and hence the mapcache is no longer shared between all vCPUs of=
 a
> domain.  Introduce per-vCPU mapcache structures, and modify map_domain_pa=
ge()
> to create per-vCPU mappings when possible.  Note the lock is also not nee=
ded
> with using per-vCPU map caches, as the structure is no longer shared.
>
> This introduces some duplication in the domain and vcpu structures, as bo=
th
> contain a mapcache field to support running with and without per-vCPU
> page-tables.
>
> Signed-off-by: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
> ---
>  xen/arch/x86/domain_page.c        | 90 ++++++++++++++++++++-----------
>  xen/arch/x86/include/asm/domain.h | 20 ++++---
>  2 files changed, 71 insertions(+), 39 deletions(-)
>
> diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c
> index 1372be20224e..65900d6218f8 100644
> --- a/xen/arch/x86/domain_page.c
> +++ b/xen/arch/x86/domain_page.c
> @@ -74,7 +74,9 @@ void *map_domain_page(mfn_t mfn)
>      struct vcpu *v;
>      struct mapcache_domain *dcache;
>      struct mapcache_vcpu *vcache;
> +    struct mapcache *cache;
>      struct vcpu_maphash_entry *hashent;
> +    struct domain *d;
> =20
>  #ifdef NDEBUG
>      if ( mfn_x(mfn) <=3D PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) )
> @@ -85,9 +87,12 @@ void *map_domain_page(mfn_t mfn)
>      if ( !v || !is_pv_vcpu(v) )
>          return mfn_to_virt(mfn_x(mfn));
> =20
> -    dcache =3D &v->domain->arch.pv.mapcache;
> +    d =3D v->domain;
> +    dcache =3D &d->arch.pv.mapcache;
>      vcache =3D &v->arch.pv.mapcache;
> -    if ( !dcache->inuse )
> +    cache =3D d->arch.vcpu_pt ? &v->arch.pv.mapcache.cache
> +                            : &d->arch.pv.mapcache.cache;
> +    if ( !cache->inuse )
>          return mfn_to_virt(mfn_x(mfn));
> =20
>      perfc_incr(map_domain_page_count);
> @@ -98,17 +103,18 @@ void *map_domain_page(mfn_t mfn)
>      if ( hashent->mfn =3D=3D mfn_x(mfn) )
>      {
>          idx =3D hashent->idx;
> -        ASSERT(idx < dcache->entries);
> +        ASSERT(idx < cache->entries);
>          hashent->refcnt++;
>          ASSERT(hashent->refcnt);
>          ASSERT(mfn_eq(l1e_get_mfn(MAPCACHE_L1ENT(idx)), mfn));
>          goto out;
>      }
> =20
> -    spin_lock(&dcache->lock);
> +    if ( !d->arch.vcpu_pt )
> +        spin_lock(&dcache->lock);

Hmmm. I wonder whether we might not want a nospec here...

> =20
>      /* Has some other CPU caused a wrap? We must flush if so. */
> -    if ( unlikely(dcache->epoch !=3D vcache->shadow_epoch) )
> +    if ( unlikely(!d->arch.vcpu_pt && dcache->epoch !=3D vcache->shadow_=
epoch) )
>      {
>          vcache->shadow_epoch =3D dcache->epoch;
>          if ( NEED_FLUSH(this_cpu(tlbflush_time), dcache->tlbflush_timest=
amp) )
> @@ -118,21 +124,21 @@ void *map_domain_page(mfn_t mfn)
>          }
>      }
> =20
> -    idx =3D find_next_zero_bit(dcache->inuse, dcache->entries, dcache->c=
ursor);
> -    if ( unlikely(idx >=3D dcache->entries) )
> +    idx =3D find_next_zero_bit(cache->inuse, cache->entries, cache->curs=
or);
> +    if ( unlikely(idx >=3D cache->entries) )
>      {
>          unsigned long accum =3D 0, prev =3D 0;
> =20
>          /* /First/, clean the garbage map and update the inuse list. */
> -        for ( i =3D 0; i < BITS_TO_LONGS(dcache->entries); i++ )
> +        for ( i =3D 0; i < BITS_TO_LONGS(cache->entries); i++ )
>          {
>              accum |=3D prev;
> -            dcache->inuse[i] &=3D ~xchg(&dcache->garbage[i], 0);
> -            prev =3D ~dcache->inuse[i];
> +            cache->inuse[i] &=3D ~xchg(&cache->garbage[i], 0);
> +            prev =3D ~cache->inuse[i];
>          }
> =20
> -        if ( accum | (prev & BITMAP_LAST_WORD_MASK(dcache->entries)) )
> -            idx =3D find_first_zero_bit(dcache->inuse, dcache->entries);
> +        if ( accum | (prev & BITMAP_LAST_WORD_MASK(cache->entries)) )
> +            idx =3D find_first_zero_bit(cache->inuse, cache->entries);
>          else
>          {
>              /* Replace a hash entry instead. */
> @@ -152,19 +158,23 @@ void *map_domain_page(mfn_t mfn)
>                      i =3D 0;
>              } while ( i !=3D MAPHASH_HASHFN(mfn_x(mfn)) );
>          }
> -        BUG_ON(idx >=3D dcache->entries);
> +        BUG_ON(idx >=3D cache->entries);
> =20
>          /* /Second/, flush TLBs. */
>          perfc_incr(domain_page_tlb_flush);
>          flush_tlb_local();
> -        vcache->shadow_epoch =3D ++dcache->epoch;
> -        dcache->tlbflush_timestamp =3D tlbflush_current_time();
> +        if ( !d->arch.vcpu_pt )
> +        {
> +            vcache->shadow_epoch =3D ++dcache->epoch;
> +            dcache->tlbflush_timestamp =3D tlbflush_current_time();
> +        }
>      }
> =20
> -    set_bit(idx, dcache->inuse);
> -    dcache->cursor =3D idx + 1;
> +    set_bit(idx, cache->inuse);
> +    cache->cursor =3D idx + 1;
> =20
> -    spin_unlock(&dcache->lock);
> +    if ( !d->arch.vcpu_pt )
> +        spin_unlock(&dcache->lock);

... and here.

> =20
>      l1e_write(&MAPCACHE_L1ENT(idx), l1e_from_mfn(mfn, __PAGE_HYPERVISOR_=
RW));
> =20
> @@ -178,6 +188,7 @@ void unmap_domain_page(const void *ptr)
>      unsigned int idx;
>      struct vcpu *v;
>      struct mapcache_domain *dcache;
> +    struct mapcache *cache;
>      unsigned long va =3D (unsigned long)ptr, mfn, flags;
>      struct vcpu_maphash_entry *hashent;
> =20
> @@ -190,7 +201,9 @@ void unmap_domain_page(const void *ptr)
>      ASSERT(v && is_pv_vcpu(v));
> =20
>      dcache =3D &v->domain->arch.pv.mapcache;
> -    ASSERT(dcache->inuse);
> +    cache =3D v->domain->arch.vcpu_pt ? &v->arch.pv.mapcache.cache
> +                                    : &v->domain->arch.pv.mapcache.cache=
;
> +    ASSERT(cache->inuse);
> =20
>      idx =3D PFN_DOWN(va - MAPCACHE_VIRT_START);
>      mfn =3D l1e_get_pfn(MAPCACHE_L1ENT(idx));
> @@ -213,7 +226,7 @@ void unmap_domain_page(const void *ptr)
>                     hashent->mfn);
>              l1e_write(&MAPCACHE_L1ENT(hashent->idx), l1e_empty());
>              /* /Second/, mark as garbage. */
> -            set_bit(hashent->idx, dcache->garbage);
> +            set_bit(hashent->idx, cache->garbage);
>          }
> =20
>          /* Add newly-freed mapping to the maphash. */
> @@ -225,7 +238,7 @@ void unmap_domain_page(const void *ptr)
>          /* /First/, zap the PTE. */
>          l1e_write(&MAPCACHE_L1ENT(idx), l1e_empty());
>          /* /Second/, mark as garbage. */
> -        set_bit(idx, dcache->garbage);
> +        set_bit(idx, cache->garbage);
>      }
> =20
>      local_irq_restore(flags);
> @@ -234,7 +247,6 @@ void unmap_domain_page(const void *ptr)
>  void mapcache_domain_init(struct domain *d)
>  {
>      struct mapcache_domain *dcache =3D &d->arch.pv.mapcache;
> -    unsigned int bitmap_pages;
> =20
>      ASSERT(is_pv_domain(d));
> =20
> @@ -243,13 +255,12 @@ void mapcache_domain_init(struct domain *d)
>          return;
>  #endif
> =20
> +    if ( d->arch.vcpu_pt )
> +        return;
> +
>      BUILD_BUG_ON(MAPCACHE_VIRT_END + PAGE_SIZE * (3 +
>                   2 * PFN_UP(BITS_TO_LONGS(MAPCACHE_ENTRIES) * sizeof(lon=
g))) >
>                   MAPCACHE_VIRT_START + (PERDOMAIN_SLOT_MBYTES << 20));
> -    bitmap_pages =3D PFN_UP(BITS_TO_LONGS(MAPCACHE_ENTRIES) * sizeof(lon=
g));
> -    dcache->inuse =3D (void *)MAPCACHE_VIRT_END + PAGE_SIZE;
> -    dcache->garbage =3D dcache->inuse +
> -                      (bitmap_pages + 1) * PAGE_SIZE / sizeof(long);
> =20
>      spin_lock_init(&dcache->lock);
>  }
> @@ -258,30 +269,45 @@ int mapcache_vcpu_init(struct vcpu *v)
>  {
>      struct domain *d =3D v->domain;
>      struct mapcache_domain *dcache =3D &d->arch.pv.mapcache;
> +    struct mapcache *cache;
>      unsigned long i;
> -    unsigned int ents =3D d->max_vcpus * MAPCACHE_VCPU_ENTRIES;
> +    unsigned int ents =3D (d->arch.vcpu_pt ? 1 : d->max_vcpus) *
> +                        MAPCACHE_VCPU_ENTRIES;
>      unsigned int nr =3D PFN_UP(BITS_TO_LONGS(ents) * sizeof(long));
> =20
> -    if ( !is_pv_vcpu(v) || !dcache->inuse )
> +    if ( !is_pv_vcpu(v) )
>          return 0;
> =20
> -    if ( ents > dcache->entries )
> +    cache =3D d->arch.vcpu_pt ? &v->arch.pv.mapcache.cache
> +                            : &dcache->cache;
> +
> +    if ( !cache->inuse )
> +        return 0;
> +
> +    if ( ents > cache->entries )
>      {
>          /* Populate page tables. */
>          int rc =3D create_perdomain_mapping(v, MAPCACHE_VIRT_START, ents=
, false);
> +        const unsigned int bitmap_pages =3D
> +            PFN_UP(BITS_TO_LONGS(MAPCACHE_ENTRIES) * sizeof(long));
> +
> +        cache->inuse =3D (void *)MAPCACHE_VIRT_END + PAGE_SIZE;
> +        cache->garbage =3D cache->inuse +
> +                         (bitmap_pages + 1) * PAGE_SIZE / sizeof(long);
> +
> =20
>          /* Populate bit maps. */
>          if ( !rc )
> -            rc =3D create_perdomain_mapping(v, (unsigned long)dcache->in=
use,
> +            rc =3D create_perdomain_mapping(v, (unsigned long)cache->inu=
se,
>                                            nr, true);
>          if ( !rc )
> -            rc =3D create_perdomain_mapping(v, (unsigned long)dcache->ga=
rbage,
> +            rc =3D create_perdomain_mapping(v, (unsigned long)cache->gar=
bage,
>                                            nr, true);
> =20
>          if ( rc )
>              return rc;
> =20
> -        dcache->entries =3D ents;
> +        cache->entries =3D ents;
>      }
> =20
>      /* Mark all maphash entries as not in use. */

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:11:44 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:11:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868639.1280211 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVuCA-0002e3-Pk; Thu, 09 Jan 2025 15:11:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868639.1280211; Thu, 09 Jan 2025 15:11:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVuCA-0002dw-MM; Thu, 09 Jan 2025 15:11:38 +0000
Received: by outflank-mailman (input) for mailman id 868639;
 Thu, 09 Jan 2025 15:11: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
 <SRS0=BoWZ=UB=suse.de=tzimmermann@srs-se1.protection.inumbo.net>)
 id 1tVu4H-0007zg-Pd
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:03:29 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e0914229-ce9a-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 16:03:26 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id AD45321179;
 Thu,  9 Jan 2025 15:03:25 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 26A0C13A8B;
 Thu,  9 Jan 2025 15:03:25 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id GFw9CD3lf2c1awAAD6G6ig
 (envelope-from <tzimmermann@suse.de>); Thu, 09 Jan 2025 15:03:25 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e0914229-ce9a-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736435005; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=QsAkbiCNZPJa7lykZ0W2Im8Rz/K3j/qzEnWutqrkaP4=;
	b=E4mF2b88i1q4slUZ4/qBReEFeEySjrRCGbf46VXhRkeuBDsS3oRAr7S1dwAWoN+RNHdUrR
	QGfX1hOzEe3shzqAh6YiiEvhuZoq2HaHzYlkEma9t0LUUZJJLb817iwjAzjY1m9QElwTPo
	48QFcdXjRRihKWB0/DwbMvs8G8jvh8E=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736435005;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=QsAkbiCNZPJa7lykZ0W2Im8Rz/K3j/qzEnWutqrkaP4=;
	b=9u9EqMnmcjuHU/fMQsou9BFxU5rQWtneJVUfCwbMCcurwzt4zWtUqTuxEeOlq8Hp/79+cI
	/ZQ0Mcq4UXLjbKCA==
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736435005; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=QsAkbiCNZPJa7lykZ0W2Im8Rz/K3j/qzEnWutqrkaP4=;
	b=E4mF2b88i1q4slUZ4/qBReEFeEySjrRCGbf46VXhRkeuBDsS3oRAr7S1dwAWoN+RNHdUrR
	QGfX1hOzEe3shzqAh6YiiEvhuZoq2HaHzYlkEma9t0LUUZJJLb817iwjAzjY1m9QElwTPo
	48QFcdXjRRihKWB0/DwbMvs8G8jvh8E=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736435005;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=QsAkbiCNZPJa7lykZ0W2Im8Rz/K3j/qzEnWutqrkaP4=;
	b=9u9EqMnmcjuHU/fMQsou9BFxU5rQWtneJVUfCwbMCcurwzt4zWtUqTuxEeOlq8Hp/79+cI
	/ZQ0Mcq4UXLjbKCA==
From: Thomas Zimmermann <tzimmermann@suse.de>
To: maarten.lankhorst@linux.intel.com,
	mripard@kernel.org,
	airlied@gmail.com,
	simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Sandy Huang <hjc@rock-chips.com>,
	=?UTF-8?q?Heiko=20St=C3=BCbner?= <heiko@sntech.de>,
	Andy Yan <andy.yan@rock-chips.com>
Subject: [PATCH v2 19/25] drm/rockchip: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Thu,  9 Jan 2025 15:57:13 +0100
Message-ID: <20250109150310.219442-20-tzimmermann@suse.de>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250109150310.219442-1-tzimmermann@suse.de>
References: <20250109150310.219442-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Spam-Level: 
X-Spamd-Result: default: False [-1.80 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	TO_DN_SOME(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	FREEMAIL_TO(0.00)[linux.intel.com,kernel.org,gmail.com,ffwll.ch];
	MIME_TRACE(0.00)[0:+];
	RCPT_COUNT_TWELVE(0.00)[22];
	FREEMAIL_ENVRCPT(0.00)[gmail.com];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	R_RATELIMIT(0.00)[to_ip_from(RLqirfcw6gnbcr9a9yhi49fhi6),to(RLbwen1niosrcqbxsafh1)];
	RCVD_TLS_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,suse.de:email,suse.de:mid]
X-Spam-Score: -1.80
X-Spam-Flag: NO

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch to a multiple of 64.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Sandy Huang <hjc@rock-chips.com>
Cc: "Heiko Stübner" <heiko@sntech.de>
Cc: Andy Yan <andy.yan@rock-chips.com>
---
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index 6330b883efc3..3bd06202e232 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -9,6 +9,7 @@
 #include <linux/vmalloc.h>
 
 #include <drm/drm.h>
+#include <drm/drm_dumb_buffers.h>
 #include <drm/drm_fb_helper.h>
 #include <drm/drm_gem.h>
 #include <drm/drm_gem_dma_helper.h>
@@ -403,13 +404,12 @@ int rockchip_gem_dumb_create(struct drm_file *file_priv,
 			     struct drm_mode_create_dumb *args)
 {
 	struct rockchip_gem_object *rk_obj;
-	int min_pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
+	int ret;
 
-	/*
-	 * align to 64 bytes since Mali requires it.
-	 */
-	args->pitch = ALIGN(min_pitch, 64);
-	args->size = args->pitch * args->height;
+	/* 64-byte alignment required by Mali */
+	ret = drm_mode_size_dumb(dev, args, SZ_64, 0);
+	if (ret)
+		return ret;
 
 	rk_obj = rockchip_gem_create_with_handle(file_priv, dev, args->size,
 						 &args->handle);
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:14:02 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:14:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868670.1280221 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVuES-0003qv-6c; Thu, 09 Jan 2025 15:14:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868670.1280221; Thu, 09 Jan 2025 15:14:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVuES-0003qo-27; Thu, 09 Jan 2025 15:14:00 +0000
Received: by outflank-mailman (input) for mailman id 868670;
 Thu, 09 Jan 2025 15:13:58 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=BoWZ=UB=suse.de=tzimmermann@srs-se1.protection.inumbo.net>)
 id 1tVu4G-0007zt-MX
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:03:28 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e13381b3-ce9a-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 16:03:27 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id D2B2A2117E;
 Thu,  9 Jan 2025 15:03:26 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 48D2713A8B;
 Thu,  9 Jan 2025 15:03:26 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id UHF+ED7lf2c1awAAD6G6ig
 (envelope-from <tzimmermann@suse.de>); Thu, 09 Jan 2025 15:03:26 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e13381b3-ce9a-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736435006; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=cMyDtZteYQi53fIJpuHawiVkfzpZWBcNX96BIIRcVRg=;
	b=06km46Gp2nPB0Hy3z1K81dBHV/3Cd4pEaJSeRbdrokm7LUetw42t25vR+z6UzQKGN3g/Q4
	pJDPOjFZU1ZwR1FynNw5N0jwj7jcnjXwtQ4D530g4rWA1NgqIxpLftn9hh82Kb8VDxK/bI
	G0QTHuFtqyQa+YjmvxP0FoFUmfrCcvM=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736435006;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=cMyDtZteYQi53fIJpuHawiVkfzpZWBcNX96BIIRcVRg=;
	b=huZ8ujhVVCssSEmwDdGaUFcPsRZjfAhscwm5nCCS1v6oz8P8jmalBJPPwIKeIsZJqTLgnL
	yA4XkWFXJbuTN4DQ==
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.de header.s=susede2_rsa header.b=06km46Gp;
	dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=huZ8ujhV
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736435006; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=cMyDtZteYQi53fIJpuHawiVkfzpZWBcNX96BIIRcVRg=;
	b=06km46Gp2nPB0Hy3z1K81dBHV/3Cd4pEaJSeRbdrokm7LUetw42t25vR+z6UzQKGN3g/Q4
	pJDPOjFZU1ZwR1FynNw5N0jwj7jcnjXwtQ4D530g4rWA1NgqIxpLftn9hh82Kb8VDxK/bI
	G0QTHuFtqyQa+YjmvxP0FoFUmfrCcvM=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736435006;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=cMyDtZteYQi53fIJpuHawiVkfzpZWBcNX96BIIRcVRg=;
	b=huZ8ujhVVCssSEmwDdGaUFcPsRZjfAhscwm5nCCS1v6oz8P8jmalBJPPwIKeIsZJqTLgnL
	yA4XkWFXJbuTN4DQ==
From: Thomas Zimmermann <tzimmermann@suse.de>
To: maarten.lankhorst@linux.intel.com,
	mripard@kernel.org,
	airlied@gmail.com,
	simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@redhat.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Gurchetan Singh <gurchetansingh@chromium.org>,
	Chia-I Wu <olvaffe@gmail.com>
Subject: [PATCH v2 21/25] drm/virtio: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Thu,  9 Jan 2025 15:57:15 +0100
Message-ID: <20250109150310.219442-22-tzimmermann@suse.de>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250109150310.219442-1-tzimmermann@suse.de>
References: <20250109150310.219442-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: D2B2A2117E
X-Spam-Score: -1.51
X-Rspamd-Action: no action
X-Spamd-Result: default: False [-1.51 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	R_DKIM_ALLOW(-0.20)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[chromium.org:email,suse.de:dkim,suse.de:mid,suse.de:email,imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_TO(0.00)[linux.intel.com,kernel.org,gmail.com,ffwll.ch];
	RCPT_COUNT_TWELVE(0.00)[23];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:25478, ipnet:::/0, country:RU];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	DKIM_TRACE(0.00)[suse.de:+];
	FREEMAIL_CC(0.00)[lists.freedesktop.org,lists.infradead.org,vger.kernel.org,lists.linux.dev,lists.xenproject.org,suse.de,redhat.com,chromium.org,gmail.com];
	RCVD_TLS_ALL(0.00)[];
	TO_DN_SOME(0.00)[];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spam-Flag: NO
X-Spam-Level: 

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch to a multiple of 4.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Gurchetan Singh <gurchetansingh@chromium.org>
Cc: Chia-I Wu <olvaffe@gmail.com>
---
 drivers/gpu/drm/virtio/virtgpu_gem.c | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c b/drivers/gpu/drm/virtio/virtgpu_gem.c
index 5aab588fc400..22cf1cd2fdfd 100644
--- a/drivers/gpu/drm/virtio/virtgpu_gem.c
+++ b/drivers/gpu/drm/virtio/virtgpu_gem.c
@@ -23,6 +23,7 @@
  * WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
  */
 
+#include <drm/drm_dumb_buffers.h>
 #include <drm/drm_file.h>
 #include <drm/drm_fourcc.h>
 
@@ -66,15 +67,14 @@ int virtio_gpu_mode_dumb_create(struct drm_file *file_priv,
 	struct virtio_gpu_object_params params = { 0 };
 	struct virtio_gpu_device *vgdev = dev->dev_private;
 	int ret;
-	uint32_t pitch;
+
+	ret = drm_mode_size_dumb(dev, args, SZ_4, 0);
+	if (ret)
+		return ret;
 
 	if (args->bpp != 32)
 		return -EINVAL;
 
-	pitch = args->width * 4;
-	args->size = pitch * args->height;
-	args->size = ALIGN(args->size, PAGE_SIZE);
-
 	params.format = virtio_gpu_translate_format(DRM_FORMAT_HOST_XRGB8888);
 	params.width = args->width;
 	params.height = args->height;
@@ -92,7 +92,6 @@ int virtio_gpu_mode_dumb_create(struct drm_file *file_priv,
 	if (ret)
 		goto fail;
 
-	args->pitch = pitch;
 	return ret;
 
 fail:
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:15:16 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:15:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868689.1280231 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVuFf-0004dt-Fl; Thu, 09 Jan 2025 15:15:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868689.1280231; Thu, 09 Jan 2025 15: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 <xen-devel-bounces@lists.xenproject.org>)
	id 1tVuFf-0004dm-Ch; Thu, 09 Jan 2025 15:15:15 +0000
Received: by outflank-mailman (input) for mailman id 868689;
 Thu, 09 Jan 2025 15:15: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
 <SRS0=BoWZ=UB=suse.de=tzimmermann@srs-se1.protection.inumbo.net>)
 id 1tVu4I-0007zg-Po
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:03:30 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de
 [2a07:de40:b251:101:10:150:64:1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e0ed5a5e-ce9a-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 16:03:26 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id 41AC82117D;
 Thu,  9 Jan 2025 15:03:26 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id B2BC9139AB;
 Thu,  9 Jan 2025 15:03:25 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id eC9bKj3lf2c1awAAD6G6ig
 (envelope-from <tzimmermann@suse.de>); Thu, 09 Jan 2025 15:03:25 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e0ed5a5e-ce9a-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736435006; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=MbyfL7pXugRIaQ1rGw2ejKjj8og6VO/XmRg5hc2KC08=;
	b=EBRwxSnCYHmtQB+mEggCRjVahXbfGfamCIePMGgU/05nFoR5wwoyW/PMYMwKmS7YmKMst7
	H3j5SvjYOWUeiG1iJQSTOk6kZVvw/05ubxWLGjLYaMxF/hVKeIMocpmmCWu/6J7MGFVlc3
	IO7fUUeTLMEnl+Pu4oSJ1E8/p27HN38=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736435006;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=MbyfL7pXugRIaQ1rGw2ejKjj8og6VO/XmRg5hc2KC08=;
	b=eQ+tV25sLFZ2ZcuKrg/1ZmWl9Q1dKKgB/wyrdw7a63Rzy7zkzVmwwmnvWyO5LDns6GshwS
	VKIs/WJDxK6lzUDg==
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.de header.s=susede2_rsa header.b=EBRwxSnC;
	dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=eQ+tV25s
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736435006; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=MbyfL7pXugRIaQ1rGw2ejKjj8og6VO/XmRg5hc2KC08=;
	b=EBRwxSnCYHmtQB+mEggCRjVahXbfGfamCIePMGgU/05nFoR5wwoyW/PMYMwKmS7YmKMst7
	H3j5SvjYOWUeiG1iJQSTOk6kZVvw/05ubxWLGjLYaMxF/hVKeIMocpmmCWu/6J7MGFVlc3
	IO7fUUeTLMEnl+Pu4oSJ1E8/p27HN38=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736435006;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=MbyfL7pXugRIaQ1rGw2ejKjj8og6VO/XmRg5hc2KC08=;
	b=eQ+tV25sLFZ2ZcuKrg/1ZmWl9Q1dKKgB/wyrdw7a63Rzy7zkzVmwwmnvWyO5LDns6GshwS
	VKIs/WJDxK6lzUDg==
From: Thomas Zimmermann <tzimmermann@suse.de>
To: maarten.lankhorst@linux.intel.com,
	mripard@kernel.org,
	airlied@gmail.com,
	simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Thierry Reding <thierry.reding@gmail.com>,
	Mikko Perttunen <mperttunen@nvidia.com>
Subject: [PATCH v2 20/25] drm/tegra: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Thu,  9 Jan 2025 15:57:14 +0100
Message-ID: <20250109150310.219442-21-tzimmermann@suse.de>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250109150310.219442-1-tzimmermann@suse.de>
References: <20250109150310.219442-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 41AC82117D
X-Spam-Level: 
X-Spamd-Result: default: False [-1.51 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	R_DKIM_ALLOW(-0.20)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[21];
	FREEMAIL_TO(0.00)[linux.intel.com,kernel.org,gmail.com,ffwll.ch];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	FREEMAIL_CC(0.00)[lists.freedesktop.org,lists.infradead.org,vger.kernel.org,lists.linux.dev,lists.xenproject.org,suse.de,gmail.com,nvidia.com];
	RCVD_TLS_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:email,suse.de:dkim,suse.de:mid,imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns,nvidia.com:email];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	TAGGED_RCPT(0.00)[];
	ASN(0.00)[asn:25478, ipnet:::/0, country:RU];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DKIM_TRACE(0.00)[suse.de:+];
	R_RATELIMIT(0.00)[to_ip_from(RLqtkr6cif1ebgurukgmwdm7xc),to(RLbwen1niosrcqbxsafh1)];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Rspamd-Action: no action
X-Spam-Score: -1.51
X-Spam-Flag: NO

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch according to hardware requirements.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Mikko Perttunen <mperttunen@nvidia.com>
---
 drivers/gpu/drm/tegra/gem.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index ace3e5a805cf..4d88e71192fb 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -16,6 +16,7 @@
 #include <linux/vmalloc.h>
 
 #include <drm/drm_drv.h>
+#include <drm/drm_dumb_buffers.h>
 #include <drm/drm_prime.h>
 #include <drm/tegra_drm.h>
 
@@ -543,12 +544,13 @@ void tegra_bo_free_object(struct drm_gem_object *gem)
 int tegra_bo_dumb_create(struct drm_file *file, struct drm_device *drm,
 			 struct drm_mode_create_dumb *args)
 {
-	unsigned int min_pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
 	struct tegra_drm *tegra = drm->dev_private;
 	struct tegra_bo *bo;
+	int ret;
 
-	args->pitch = round_up(min_pitch, tegra->pitch_align);
-	args->size = args->pitch * args->height;
+	ret = drm_mode_size_dumb(drm, args, tegra->pitch_align, 0);
+	if (ret)
+		return ret;
 
 	bo = tegra_bo_create_with_handle(file, drm, args->size, 0,
 					 &args->handle);
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:16:50 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:16:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868708.1280241 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVuGy-0005aK-Pd; Thu, 09 Jan 2025 15:16:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868708.1280241; Thu, 09 Jan 2025 15:16:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVuGy-0005aD-Md; Thu, 09 Jan 2025 15:16:36 +0000
Received: by outflank-mailman (input) for mailman id 868708;
 Thu, 09 Jan 2025 15:16:35 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=BoWZ=UB=suse.de=tzimmermann@srs-se1.protection.inumbo.net>)
 id 1tVu4I-0007zt-CS
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:03:30 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e23ba37f-ce9a-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 16:03:28 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id 7ECDE21181;
 Thu,  9 Jan 2025 15:03:28 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 0453713A9E;
 Thu,  9 Jan 2025 15:03:27 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id iEtfOz/lf2c1awAAD6G6ig
 (envelope-from <tzimmermann@suse.de>); Thu, 09 Jan 2025 15:03:27 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e23ba37f-ce9a-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736435008; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=s33VjAcs4jt+Ggz64uF8gmmMCcYYtbXaKoSCnL+Gt+g=;
	b=dzuXcjWPLaC8aZaUaOiJ6zUQGy/owwz//I0dH54es3oJMRNwT1TLKK04Z9LYc7Z+PFlbKg
	FCZQsxIJa6qHvf7n1Gu8wnLPMWFWFnVDrdjaFbIokdDxZAcP4Om3vkLLxPzpbeKZApQSw6
	DMnwRqVUggATMnlKNRJnLy7aKyfg2aE=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736435008;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=s33VjAcs4jt+Ggz64uF8gmmMCcYYtbXaKoSCnL+Gt+g=;
	b=GXC33VFDsf6gSbM4vfv7WU3KqZuksW+r6KT8ZCn22R+uVo5ClXkFt7tjon/6uIEKGmUY+a
	csgewV8GYcrPDIAg==
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.de header.s=susede2_rsa header.b=dzuXcjWP;
	dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=GXC33VFD
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736435008; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=s33VjAcs4jt+Ggz64uF8gmmMCcYYtbXaKoSCnL+Gt+g=;
	b=dzuXcjWPLaC8aZaUaOiJ6zUQGy/owwz//I0dH54es3oJMRNwT1TLKK04Z9LYc7Z+PFlbKg
	FCZQsxIJa6qHvf7n1Gu8wnLPMWFWFnVDrdjaFbIokdDxZAcP4Om3vkLLxPzpbeKZApQSw6
	DMnwRqVUggATMnlKNRJnLy7aKyfg2aE=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736435008;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=s33VjAcs4jt+Ggz64uF8gmmMCcYYtbXaKoSCnL+Gt+g=;
	b=GXC33VFDsf6gSbM4vfv7WU3KqZuksW+r6KT8ZCn22R+uVo5ClXkFt7tjon/6uIEKGmUY+a
	csgewV8GYcrPDIAg==
From: Thomas Zimmermann <tzimmermann@suse.de>
To: maarten.lankhorst@linux.intel.com,
	mripard@kernel.org,
	airlied@gmail.com,
	simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Subject: [PATCH v2 24/25] drm/xen: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Thu,  9 Jan 2025 15:57:18 +0100
Message-ID: <20250109150310.219442-25-tzimmermann@suse.de>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250109150310.219442-1-tzimmermann@suse.de>
References: <20250109150310.219442-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 7ECDE21181
X-Spam-Level: 
X-Spamd-Result: default: False [-1.51 / 50.00];
	BAYES_HAM(-3.00)[99.99%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	R_DKIM_ALLOW(-0.20)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	FREEMAIL_TO(0.00)[linux.intel.com,kernel.org,gmail.com,ffwll.ch];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[20];
	MIME_TRACE(0.00)[0:+];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns,suse.de:email,suse.de:dkim,suse.de:mid];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	ASN(0.00)[asn:25478, ipnet:::/0, country:RU];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	DKIM_TRACE(0.00)[suse.de:+];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Rspamd-Action: no action
X-Spam-Score: -1.51
X-Spam-Flag: NO

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch
and buffer size. Align the pitch to a multiple of 8.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
---
 drivers/gpu/drm/xen/xen_drm_front.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/xen/xen_drm_front.c b/drivers/gpu/drm/xen/xen_drm_front.c
index 1bda7ef606cc..fd2f250fbc33 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -14,6 +14,7 @@
 
 #include <drm/drm_atomic_helper.h>
 #include <drm/drm_drv.h>
+#include <drm/drm_dumb_buffers.h>
 #include <drm/drm_ioctl.h>
 #include <drm/drm_probe_helper.h>
 #include <drm/drm_file.h>
@@ -414,8 +415,10 @@ static int xen_drm_drv_dumb_create(struct drm_file *filp,
 	 * object without pages etc.
 	 * For details also see drm_gem_handle_create
 	 */
-	args->pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
-	args->size = args->pitch * args->height;
+
+	ret = drm_mode_size_dumb(dev, args, SZ_8, 0);
+	if (ret)
+		return ret;
 
 	obj = xen_drm_front_gem_create(dev, args->size);
 	if (IS_ERR(obj)) {
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:17:06 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:17:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868725.1280251 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVuHS-0006He-5g; Thu, 09 Jan 2025 15:17:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868725.1280251; Thu, 09 Jan 2025 15:17:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVuHS-0006HX-2n; Thu, 09 Jan 2025 15:17:06 +0000
Received: by outflank-mailman (input) for mailman id 868725;
 Thu, 09 Jan 2025 15:17:05 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=BoWZ=UB=suse.de=tzimmermann@srs-se1.protection.inumbo.net>)
 id 1tVu4M-0007zg-RK
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:03:34 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e29790bd-ce9a-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 16:03:29 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id 159631F394;
 Thu,  9 Jan 2025 15:03:29 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 86A3213AA7;
 Thu,  9 Jan 2025 15:03:28 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id 2P5jH0Dlf2c1awAAD6G6ig
 (envelope-from <tzimmermann@suse.de>); Thu, 09 Jan 2025 15:03:28 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e29790bd-ce9a-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736435009; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=J6bJ5PrU9Ov2p7iX5J2NO4bVvOCLiJfa9aMPiWlnp7E=;
	b=2FBrSVfz1w+KP4I3u2gtjDD/MtYOx10aHYP/LL4/WsL1NbmD7aChz9t9GsCjwTPrzUywXL
	YLUrswaNhkQ+mf7kpSSRU4ubGefcEk+XNQYTQzS6g9qNntPm9eYMCpwWYtSOQr4QlsroFD
	HefHAQZto0zHeRu8eDV+wlFtE6iSkGc=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736435009;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=J6bJ5PrU9Ov2p7iX5J2NO4bVvOCLiJfa9aMPiWlnp7E=;
	b=nFY2Y+gqJVhTL9teBXFqe+a7/Xk+sWWQ7xUOoRyEJnHS3VXE14PBgZlrH+GYD1Qs9Ia+KX
	9kWLL1DmCv/I8rDw==
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.de header.s=susede2_rsa header.b=2FBrSVfz;
	dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=nFY2Y+gq
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736435009; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=J6bJ5PrU9Ov2p7iX5J2NO4bVvOCLiJfa9aMPiWlnp7E=;
	b=2FBrSVfz1w+KP4I3u2gtjDD/MtYOx10aHYP/LL4/WsL1NbmD7aChz9t9GsCjwTPrzUywXL
	YLUrswaNhkQ+mf7kpSSRU4ubGefcEk+XNQYTQzS6g9qNntPm9eYMCpwWYtSOQr4QlsroFD
	HefHAQZto0zHeRu8eDV+wlFtE6iSkGc=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736435009;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=J6bJ5PrU9Ov2p7iX5J2NO4bVvOCLiJfa9aMPiWlnp7E=;
	b=nFY2Y+gqJVhTL9teBXFqe+a7/Xk+sWWQ7xUOoRyEJnHS3VXE14PBgZlrH+GYD1Qs9Ia+KX
	9kWLL1DmCv/I8rDw==
From: Thomas Zimmermann <tzimmermann@suse.de>
To: maarten.lankhorst@linux.intel.com,
	mripard@kernel.org,
	airlied@gmail.com,
	simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Subject: [PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Thu,  9 Jan 2025 15:57:19 +0100
Message-ID: <20250109150310.219442-26-tzimmermann@suse.de>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250109150310.219442-1-tzimmermann@suse.de>
References: <20250109150310.219442-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 159631F394
X-Spam-Level: 
X-Spamd-Result: default: False [-1.51 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	R_DKIM_ALLOW(-0.20)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:email,suse.de:dkim,suse.de:mid,imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_TO(0.00)[linux.intel.com,kernel.org,gmail.com,ffwll.ch];
	RCPT_COUNT_TWELVE(0.00)[21];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:25478, ipnet:::/0, country:RU];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	R_RATELIMIT(0.00)[to_ip_from(RLqtkr6cif1ebgurukgmwdm7xc),to(RLbwen1niosrcqbxsafh1)];
	RCVD_TLS_ALL(0.00)[];
	DKIM_TRACE(0.00)[suse.de:+];
	TO_DN_SOME(0.00)[];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Rspamd-Action: no action
X-Spam-Score: -1.51
X-Spam-Flag: NO

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch according to hardware requirements.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
 drivers/gpu/drm/xlnx/zynqmp_kms.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c b/drivers/gpu/drm/xlnx/zynqmp_kms.c
index b47463473472..7ea0cd4f71d3 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_kms.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_kms.c
@@ -19,6 +19,7 @@
 #include <drm/drm_crtc.h>
 #include <drm/drm_device.h>
 #include <drm/drm_drv.h>
+#include <drm/drm_dumb_buffers.h>
 #include <drm/drm_encoder.h>
 #include <drm/drm_fbdev_dma.h>
 #include <drm/drm_fourcc.h>
@@ -363,10 +364,12 @@ static int zynqmp_dpsub_dumb_create(struct drm_file *file_priv,
 				    struct drm_mode_create_dumb *args)
 {
 	struct zynqmp_dpsub *dpsub = to_zynqmp_dpsub(drm);
-	unsigned int pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
+	int ret;
 
 	/* Enforce the alignment constraints of the DMA engine. */
-	args->pitch = ALIGN(pitch, dpsub->dma_align);
+	ret = drm_mode_size_dumb(drm, args, dpsub->dma_align, 0);
+	if (ret)
+		return ret;
 
 	return drm_gem_dma_dumb_create_internal(file_priv, drm, args);
 }
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:17:30 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:17:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868735.1280261 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVuHq-0006tl-DL; Thu, 09 Jan 2025 15:17:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868735.1280261; Thu, 09 Jan 2025 15:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVuHq-0006te-AS; Thu, 09 Jan 2025 15:17:30 +0000
Received: by outflank-mailman (input) for mailman id 868735;
 Thu, 09 Jan 2025 15:17:29 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=BoWZ=UB=suse.de=tzimmermann@srs-se1.protection.inumbo.net>)
 id 1tVu4J-0007zt-D3
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:03:31 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e28cef3d-ce9a-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 16:03:29 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id F120121180;
 Thu,  9 Jan 2025 15:03:27 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 6ADBC13A8B;
 Thu,  9 Jan 2025 15:03:27 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id cDzMGD/lf2c1awAAD6G6ig
 (envelope-from <tzimmermann@suse.de>); Thu, 09 Jan 2025 15:03:27 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e28cef3d-ce9a-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736435009; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=J2NadFBjAqbFi1H7uwOqYOAiOGb2bLNOdbeXieSDGEU=;
	b=gCnHtmuJLcGiLH56RCHAbjbOL3StuwLdJifwaYcYlFGigNiBAhUYt9+NKdzAZ3LOfOPZal
	Ku3M/jRtzQSIG5Zony/M75iwWLbw/QQgPDAdD/9jktN/4Ha6nFg8Xq/6lrmCjZRymqkHcd
	Xf+H717xR/19W5SgsiXifzoP00xlhZQ=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736435009;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=J2NadFBjAqbFi1H7uwOqYOAiOGb2bLNOdbeXieSDGEU=;
	b=M6VuwU0fRhuZdkNXEzUngV7rcGi2TE2FlAkeTxPo+XdqwO90rQ+HJMWWPDblcbuCDai8ou
	AKfNe1/0AuhdMOBQ==
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736435007; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=J2NadFBjAqbFi1H7uwOqYOAiOGb2bLNOdbeXieSDGEU=;
	b=wAnJYW7YRZ5FxzftY+koF4X9N3VxtQJ92gUVtMOA20XnFrjGiCvIXaa9hwf1VIPhbIAyzr
	rco3UlFDShDSd516zHbrHb+pXo2WAC87Q7BfHWZjdbis0z5rzE43o7zOo74wVU3Gu34WTd
	gxEDMekzlyR6IkyN2x9/hbg2sOHRpG4=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736435007;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=J2NadFBjAqbFi1H7uwOqYOAiOGb2bLNOdbeXieSDGEU=;
	b=HunHuKf1409Au2X6hEHF/VCiFPGh7nGOLKYVdPoxHGASqlemNUfl1KQn+7PVLth2jjo3SI
	ie9sr0+QYHCqSwCw==
From: Thomas Zimmermann <tzimmermann@suse.de>
To: maarten.lankhorst@linux.intel.com,
	mripard@kernel.org,
	airlied@gmail.com,
	simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Lucas De Marchi <lucas.demarchi@intel.com>,
	=?UTF-8?q?Thomas=20Hellstr=C3=B6m?= <thomas.hellstrom@linux.intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: [PATCH v2 23/25] drm/xe: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Thu,  9 Jan 2025 15:57:17 +0100
Message-ID: <20250109150310.219442-24-tzimmermann@suse.de>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250109150310.219442-1-tzimmermann@suse.de>
References: <20250109150310.219442-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -1.80
X-Spamd-Result: default: False [-1.80 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	TO_DN_SOME(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	FREEMAIL_TO(0.00)[linux.intel.com,kernel.org,gmail.com,ffwll.ch];
	MIME_TRACE(0.00)[0:+];
	RCPT_COUNT_TWELVE(0.00)[22];
	FREEMAIL_ENVRCPT(0.00)[gmail.com];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	R_RATELIMIT(0.00)[to_ip_from(RLqirfcw6gnbcr9a9yhi49fhi6),to(RLbwen1niosrcqbxsafh1)];
	RCVD_TLS_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	DBL_BLOCKED_OPENRESOLVER(0.00)[intel.com:email,imap1.dmz-prg2.suse.org:helo,suse.de:mid,suse.de:email]
X-Spam-Flag: NO
X-Spam-Level: 

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch
and buffer size. Align the pitch to a multiple of 8. Align the
buffer size according to hardware requirements.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
---
 drivers/gpu/drm/xe/xe_bo.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
index e6c896ad5602..d75e3c39ab14 100644
--- a/drivers/gpu/drm/xe/xe_bo.c
+++ b/drivers/gpu/drm/xe/xe_bo.c
@@ -8,6 +8,7 @@
 #include <linux/dma-buf.h>
 
 #include <drm/drm_drv.h>
+#include <drm/drm_dumb_buffers.h>
 #include <drm/drm_gem_ttm_helper.h>
 #include <drm/drm_managed.h>
 #include <drm/ttm/ttm_device.h>
@@ -2535,14 +2536,13 @@ int xe_bo_dumb_create(struct drm_file *file_priv,
 	struct xe_device *xe = to_xe_device(dev);
 	struct xe_bo *bo;
 	uint32_t handle;
-	int cpp = DIV_ROUND_UP(args->bpp, 8);
 	int err;
 	u32 page_size = max_t(u32, PAGE_SIZE,
 		xe->info.vram_flags & XE_VRAM_FLAGS_NEED64K ? SZ_64K : SZ_4K);
 
-	args->pitch = ALIGN(args->width * cpp, 64);
-	args->size = ALIGN(mul_u32_u32(args->pitch, args->height),
-			   page_size);
+	err = drm_mode_size_dumb(dev, args, SZ_64, page_size);
+	if (err)
+		return err;
 
 	bo = xe_bo_create_user(xe, NULL, NULL, args->size,
 			       DRM_XE_GEM_CPU_CACHING_WC,
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:18:10 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:18:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868751.1280270 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVuIS-0007iS-L2; Thu, 09 Jan 2025 15:18:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868751.1280270; Thu, 09 Jan 2025 15:18:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVuIS-0007iL-IM; Thu, 09 Jan 2025 15:18:08 +0000
Received: by outflank-mailman (input) for mailman id 868751;
 Thu, 09 Jan 2025 15:18: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
 <SRS0=BoWZ=UB=suse.de=tzimmermann@srs-se1.protection.inumbo.net>)
 id 1tVu4K-0007zg-QL
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:03:32 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de
 [2a07:de40:b251:101:10:150:64:1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e25135fd-ce9a-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 16:03:29 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id 63D0D2117F;
 Thu,  9 Jan 2025 15:03:27 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id D77DD139AB;
 Thu,  9 Jan 2025 15:03:26 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id MCFTMz7lf2c1awAAD6G6ig
 (envelope-from <tzimmermann@suse.de>); Thu, 09 Jan 2025 15:03:26 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e25135fd-ce9a-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736435008; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=vM22xqKm0qzRdMjFd3I4M82uPWCGafIm9xozDAXbusI=;
	b=PMV0sihsYxjfq2evvVU/cU/rGb8TP5puwgfRrOdDAwd9R8P2XFRAtfGLIfADXpDcm1O3CW
	ZTKtvBYSXwoWxm41ddX+Hr2ovH2n0Vqjdw5RXqLATIWBSkgtIW5J5L87MQa6HgKb7yUPGh
	t3KBMVbvQrKRXVmLDcgOR/5G3k5Bd7I=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736435008;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=vM22xqKm0qzRdMjFd3I4M82uPWCGafIm9xozDAXbusI=;
	b=c/ewjNVppokMK62w57DhhEI+AYMlWVNcE+uza4H41d0DI93NE2G/SvEqKK+wkIGo77tEni
	wY7Kz/JCiZiCBYCw==
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.de header.s=susede2_rsa header.b="PRsXptM/";
	dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=Q2E9J7Wl
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736435007; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=vM22xqKm0qzRdMjFd3I4M82uPWCGafIm9xozDAXbusI=;
	b=PRsXptM/HjGeXGFza62p3vMpIqYmsLBJjLyCIVutGnoYBK6NuRvbTPKJQaw4Vuyeuo5pV5
	8jr9ReAtmELXk24UySJU4YfXGhhBJG+3UhJ7ExHvv7y5V2KBguD1AoZdokuK8V1ZgTPG4E
	FjJyfsz8mhPZLAPip8a/M2wTli4mJB4=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736435007;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=vM22xqKm0qzRdMjFd3I4M82uPWCGafIm9xozDAXbusI=;
	b=Q2E9J7WlWX8zVLj5G71fxVWwnUEfdleLwgzw+dOgOMHcz7uu6Bvb2OOcTfCBpNsv2qAoga
	YmaAMmZfPaW4o+BQ==
From: Thomas Zimmermann <tzimmermann@suse.de>
To: maarten.lankhorst@linux.intel.com,
	mripard@kernel.org,
	airlied@gmail.com,
	simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Zack Rusin <zack.rusin@broadcom.com>,
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
Subject: [PATCH v2 22/25] drm/vmwgfx: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Thu,  9 Jan 2025 15:57:16 +0100
Message-ID: <20250109150310.219442-23-tzimmermann@suse.de>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250109150310.219442-1-tzimmermann@suse.de>
References: <20250109150310.219442-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 63D0D2117F
X-Spam-Level: 
X-Spamd-Result: default: False [-1.51 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	R_DKIM_ALLOW(-0.20)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	FREEMAIL_TO(0.00)[linux.intel.com,kernel.org,gmail.com,ffwll.ch];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[21];
	MIME_TRACE(0.00)[0:+];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:email,suse.de:dkim,suse.de:mid,broadcom.com:email,imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	ASN(0.00)[asn:25478, ipnet:::/0, country:RU];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	DKIM_TRACE(0.00)[suse.de:+];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Rspamd-Action: no action
X-Spam-Score: -1.51
X-Spam-Flag: NO

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch
and buffer size. No alignment required.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Zack Rusin <zack.rusin@broadcom.com>
Cc: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
---
 drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 21 ++++-----------------
 1 file changed, 4 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
index 5721c74da3e0..a3fbd4148f73 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
@@ -34,6 +34,7 @@
 #include "vmw_surface_cache.h"
 #include "device_include/svga3d_surfacedefs.h"
 
+#include <drm/drm_dumb_buffers.h>
 #include <drm/ttm/ttm_placement.h>
 
 #define SVGA3D_FLAGS_64(upper32, lower32) (((uint64_t)upper32 << 32) | lower32)
@@ -2291,23 +2292,9 @@ int vmw_dumb_create(struct drm_file *file_priv,
 	 * contents is going to be rendered guest side.
 	 */
 	if (!dev_priv->has_mob || !vmw_supports_3d(dev_priv)) {
-		int cpp = DIV_ROUND_UP(args->bpp, 8);
-
-		switch (cpp) {
-		case 1: /* DRM_FORMAT_C8 */
-		case 2: /* DRM_FORMAT_RGB565 */
-		case 4: /* DRM_FORMAT_XRGB8888 */
-			break;
-		default:
-			/*
-			 * Dumb buffers don't allow anything else.
-			 * This is tested via IGT's dumb_buffers
-			 */
-			return -EINVAL;
-		}
-
-		args->pitch = args->width * cpp;
-		args->size = ALIGN(args->pitch * args->height, PAGE_SIZE);
+		ret = drm_mode_size_dumb(dev, args, 0, 0);
+		if (ret)
+			return ret;
 
 		ret = vmw_gem_object_create_with_handle(dev_priv, file_priv,
 							args->size, &args->handle,
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:18:10 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:18:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868752.1280281 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVuIT-0007xo-S9; Thu, 09 Jan 2025 15:18:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868752.1280281; Thu, 09 Jan 2025 15:18:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVuIT-0007xh-P8; Thu, 09 Jan 2025 15:18:09 +0000
Received: by outflank-mailman (input) for mailman id 868752;
 Thu, 09 Jan 2025 15:18:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=BoWZ=UB=suse.de=tzimmermann@srs-se1.protection.inumbo.net>)
 id 1tVu4G-0007zg-PP
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:03:28 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e041e2f3-ce9a-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 16:03:25 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id 214142117B;
 Thu,  9 Jan 2025 15:03:25 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 99E55139AB;
 Thu,  9 Jan 2025 15:03:24 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id SFg7JDzlf2c1awAAD6G6ig
 (envelope-from <tzimmermann@suse.de>); Thu, 09 Jan 2025 15:03:24 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e041e2f3-ce9a-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736435005; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=kNsjwPuvxigodZL3RVyzkFKzJlbnuv8zInJMu1cAV54=;
	b=mHC4BY4v0XRblAzURsuI5fLJdxUamLs0dQqT+9rcHseAZgky5Sc7GtNtWz7aFuc5dOozzt
	VJbL4YTY/i1VCkegdtB/QrbCayouuXlzSpQqgps7bavO2+wu+XdXePW8FmTFtMJmyAHUNr
	Q3wohlh1Vfu9a7NfOUICW86X6xwP06A=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736435005;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=kNsjwPuvxigodZL3RVyzkFKzJlbnuv8zInJMu1cAV54=;
	b=7IXWhQu4iR5JkcOvc9aZwbJA+iaYNtsjxD1mSQ6imepfirGqwhXSVCBpglaH8lZ+Xr9a6z
	2DlTzOaLJ5/arlDg==
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.de header.s=susede2_rsa header.b=mHC4BY4v;
	dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=7IXWhQu4
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736435005; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=kNsjwPuvxigodZL3RVyzkFKzJlbnuv8zInJMu1cAV54=;
	b=mHC4BY4v0XRblAzURsuI5fLJdxUamLs0dQqT+9rcHseAZgky5Sc7GtNtWz7aFuc5dOozzt
	VJbL4YTY/i1VCkegdtB/QrbCayouuXlzSpQqgps7bavO2+wu+XdXePW8FmTFtMJmyAHUNr
	Q3wohlh1Vfu9a7NfOUICW86X6xwP06A=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736435005;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=kNsjwPuvxigodZL3RVyzkFKzJlbnuv8zInJMu1cAV54=;
	b=7IXWhQu4iR5JkcOvc9aZwbJA+iaYNtsjxD1mSQ6imepfirGqwhXSVCBpglaH8lZ+Xr9a6z
	2DlTzOaLJ5/arlDg==
From: Thomas Zimmermann <tzimmermann@suse.de>
To: maarten.lankhorst@linux.intel.com,
	mripard@kernel.org,
	airlied@gmail.com,
	simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Biju Das <biju.das.jz@bp.renesas.com>
Subject: [PATCH v2 18/25] drm/renesas/rz-du: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Thu,  9 Jan 2025 15:57:12 +0100
Message-ID: <20250109150310.219442-19-tzimmermann@suse.de>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250109150310.219442-1-tzimmermann@suse.de>
References: <20250109150310.219442-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 214142117B
X-Spam-Score: -1.51
X-Rspamd-Action: no action
X-Spamd-Result: default: False [-1.51 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	R_DKIM_ALLOW(-0.20)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	FREEMAIL_TO(0.00)[linux.intel.com,kernel.org,gmail.com,ffwll.ch];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[20];
	MIME_TRACE(0.00)[0:+];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo,suse.de:dkim,suse.de:mid,suse.de:email];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	ASN(0.00)[asn:25478, ipnet:::/0, country:RU];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	DKIM_TRACE(0.00)[suse.de:+];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spam-Flag: NO
X-Spam-Level: 

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch according to hardware requirements.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Biju Das <biju.das.jz@bp.renesas.com>
---
 drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c
index 90c6269ccd29..f752369cd52f 100644
--- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c
+++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c
@@ -75,10 +75,11 @@ const struct rzg2l_du_format_info *rzg2l_du_format_info(u32 fourcc)
 int rzg2l_du_dumb_create(struct drm_file *file, struct drm_device *dev,
 			 struct drm_mode_create_dumb *args)
 {
-	unsigned int min_pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
-	unsigned int align = 16 * args->bpp / 8;
+	int ret;
 
-	args->pitch = roundup(min_pitch, align);
+	ret = drm_mode_size_dumb(dev, args, 16 * args->bpp / 8, 0);
+	if (ret)
+		return ret;
 
 	return drm_gem_dma_dumb_create_internal(file, dev, args);
 }
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:26:21 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:26:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868792.1280290 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVuQI-0003Au-JA; Thu, 09 Jan 2025 15:26:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868792.1280290; Thu, 09 Jan 2025 15:26:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVuQI-0003An-Gd; Thu, 09 Jan 2025 15:26:14 +0000
Received: by outflank-mailman (input) for mailman id 868792;
 Thu, 09 Jan 2025 15:26:13 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=zyMf=UB=tklengyel.com=tamas@srs-se1.protection.inumbo.net>)
 id 1tVuQH-0003Ah-3Z
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:26:13 +0000
Received: from sender4-op-o12.zoho.com (sender4-op-o12.zoho.com
 [136.143.188.12]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0c73b30a-ce9e-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 16:26:09 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1736436364776946.4546907594349;
 Thu, 9 Jan 2025 07:26:04 -0800 (PST)
Received: by mail-yb1-f180.google.com with SMTP id
 3f1490d57ef6-e39779a268bso1553909276.1
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 07:26:04 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 0c73b30a-ce9e-11ef-a0df-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1736436365; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=E85Jrv86Y5aK+SD6b0tynCZisfGnGGI3bbdN4wTNDsTHdtopoqCnPBFoxM3/8a9h/FByDzySw26fqH3TZ1XY6RqIcHMVW2a3ctxUQ+9oi2g7KQCJidqW79wPMVhxpQmTDMHW0lgfh1/7x6fREm8F1C2g70nk2JZ+grxmlTKp4vQ=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1736436365; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=v9IpNl2iNQqt9WSyxFheSewMy8n03I5CieRpdGYFo6w=; 
	b=eBQtf+7JaKoEzrMcoAwNhIAGdxLARvkNpDOkc6t2iDGpRxJs6ZffKh9qIydvVhM+OJT+M0VLtUa0RboF14pBVg+QuIL780GtiX2399lMVacxKd9wqo8XgWetn1hmoyIjdLzbm6bo4YOA06JDvptqpwXvu76s+IAUp2WkcAlHFBI=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=tklengyel.com;
	spf=pass  smtp.mailfrom=tamas@tklengyel.com;
	dmarc=pass header.from=<tamas@tklengyel.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1736436365;
	s=zmail; d=tklengyel.com; i=tamas@tklengyel.com;
	h=MIME-Version:References:In-Reply-To:From:From:Date:Date:Message-ID:Subject:Subject:To:To:Cc:Cc:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=v9IpNl2iNQqt9WSyxFheSewMy8n03I5CieRpdGYFo6w=;
	b=BiaTyODOueHyV35V79fmPKBGFUq/2EcmbmvQknIpafvhLivZt/DIivttRcJ5CA6Y
	IUM1qFmYHlKqwpjwVE25hgO0FSH1WBCfjTdMyNZNu4foNxz68yS2j9PkREkj7M4gVtx
	JJ36BJmGMMk6x0JjCxx3fGQCKoSrbqzCrYR+j+vI=
X-Forwarded-Encrypted: i=1; AJvYcCVFlxQri3y5TV8KM9FdA7sTX2pvXrepwotd6eHB1ueIjI1CIWap7uvhPipEFV6B6fFFSN+Xz0k7TyQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwAGOy5Cm41TtWx48HvoTsb0/LhSc6wLHueG70yNN7THVcZPWHk
	lepk5QOe9/o7fGNIbo6stYWGMK59IonGbN22Dc5y16p6jiWfs6nwk9RWkkCjt3bgsnffJCmaXCN
	S23q7Bg7NDrvYMmUQpg9PMIHlqPg=
X-Google-Smtp-Source: AGHT+IGj1vTgkF+qZ3275XwZQgoP4KlB4h4vgcoHtaVtlPsaWc38lsYRzTcHjwRXn/tIqOnyxI5wo9Wf5Ha7lKGhZGI=
X-Received: by 2002:a05:6902:2708:b0:e54:d63a:911c with SMTP id
 3f1490d57ef6-e550141e9c2mr2733502276.10.1736436363826; Thu, 09 Jan 2025
 07:26:03 -0800 (PST)
MIME-Version: 1.0
References: <cover.1735837806.git.w1benny@gmail.com> <4eea61a2-cf56-4ff5-8c43-58f5a20c9cb1@gmail.com>
In-Reply-To: <4eea61a2-cf56-4ff5-8c43-58f5a20c9cb1@gmail.com>
From: Tamas K Lengyel <tamas@tklengyel.com>
Date: Thu, 9 Jan 2025 10:25:27 -0500
X-Gmail-Original-Message-ID: <CABfawhmHK_Lg8GuVr9yb1gw82YFs3e1gh76azzH8C98R552dSw@mail.gmail.com>
X-Gm-Features: AbW1kvbgU3QB5zRBc0i5XyoixetpS80JU6YW75tixuOlVts_yNiubtZG6tTwjnc
Message-ID: <CABfawhmHK_Lg8GuVr9yb1gw82YFs3e1gh76azzH8C98R552dSw@mail.gmail.com>
Subject: Re: [PATCH v3 0/2] x86: Add Support for Paging-Write Feature
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: =?UTF-8?Q?Petr_Bene=C5=A1?= <w1benny@gmail.com>, 
	xen-devel@lists.xenproject.org, Jan Beulich <jbeulich@suse.com>, 
	Andrew Cooper <andrew.cooper3@citrix.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
	Alexandru Isaila <aisaila@bitdefender.com>, Petre Pircalabu <ppircalabu@bitdefender.com>, 
	Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, 
	Bertrand Marquis <bertrand.marquis@arm.com>, Michal Orzel <michal.orzel@amd.com>, 
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>, Anthony PERARD <anthony.perard@vates.tech>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 9, 2025 at 9:30=E2=80=AFAM Oleksii Kurochko
<oleksii.kurochko@gmail.com> wrote:
>
>
> On 1/2/25 6:13 PM, Petr Bene=C5=A1 wrote:
>
> From: Petr Bene=C5=A1 <w1benny@gmail.com>
>
> Changes since v2:
> - Reset entry->pw in all cases in p2m_set_entry, except for p2m_access_r_=
pw
>
> Changes since v1:
> - Added signed-off-by tags
>
> This patch introduces a new XENMEM_access_r_pw permission. Functionally, =
it is similar to XENMEM_access_r, but for processors with TERTIARY_EXEC_EPT=
_PAGING_WRITE support (Intel 12th Gen/Alder Lake and later), it also permit=
s the CPU to write to the page during guest page-table walks (e.g., updatin=
g A/D bits) without triggering an EPT violation.
>
> This behavior works by both enabling the EPT paging-write feature and set=
ting the EPT paging-write flag in the EPT leaf entry.
>
> This feature provides a significant performance boost for introspection t=
ools that monitor guest page-table updates. Previously, every page-table mo=
dification by the guest=E2=80=94including routine updates like setting A/D =
bits=E2=80=94triggered an EPT violation, adding unnecessary overhead. The n=
ew XENMEM_access_r_pw permission allows these "uninteresting" updates to oc=
cur without EPT violations, improving efficiency.
>
> Considering that this feature provides a significant performance boost fo=
r introspection tools probably we could consider to take it to current rele=
ase.
>
> I see that the patch series was acked-by "Acked-by: Tamas K Lengyel <tama=
s@tklengyel.com>" but based on the change log it is not clear when exactly
>
> before Feature freeze date or not. ( and I don't see any reply from Tamas=
 ).

I've acked the patch Thu, Dec 19, 2024.

Cheers,
Tamas


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:30:35 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:30:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868800.1280300 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVuUU-0005gg-2D; Thu, 09 Jan 2025 15:30:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868800.1280300; Thu, 09 Jan 2025 15:30:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVuUT-0005gZ-Vg; Thu, 09 Jan 2025 15:30:33 +0000
Received: by outflank-mailman (input) for mailman id 868800;
 Thu, 09 Jan 2025 15:30:32 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=OfsQ=UB=cloud.com=frediano.ziglio@srs-se1.protection.inumbo.net>)
 id 1tVuUS-0005gT-C8
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:30:32 +0000
Received: from mail-oa1-x2b.google.com (mail-oa1-x2b.google.com
 [2001:4860:4864:20::2b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a85f4310-ce9e-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 16:30:31 +0100 (CET)
Received: by mail-oa1-x2b.google.com with SMTP id
 586e51a60fabf-2a3a40c69e3so581909fac.0
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 07:30:31 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a85f4310-ce9e-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736436629; x=1737041429; 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=YTqkaJeSjH6ii8cl868aBE/9efm05NFc8SMXqdeIGvs=;
        b=Qqm/5MEBqLAKCpw42xyDKfiuGVdqqEBOw2bsq5GXGLQGn1LJL4N8yqa1SIEUiTJQIm
         02otp+Lmm0Vuf740dkUmLwqbLbca/vy8J3d9C9xAI+OP8qCfkahUxMgmxq+CCKAosPLF
         z6bEADEey0OhoGo17qXnRmqZ2qtV+ETuG2vII=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736436629; x=1737041429;
        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=YTqkaJeSjH6ii8cl868aBE/9efm05NFc8SMXqdeIGvs=;
        b=H5nl9pszT7XdPcvOKacr70WAJQh7sDs5lpfLHyMFnu3UpYg38N3279OhGje97aG4E1
         6yWQf+FtZuiXfdsbUIVxOxcMipHDuZlsO2yN0hNLh0ohRM7yAyZZqB1J2QChxS0Pl4E0
         tsRVcEyCgp4m6LJaqn2lnT9ghFN8Ompwg45bMbK/yDFhOaYTIqVreyRvYmCv5MIDDnOD
         bufpkFMTH2v//NiTEHQbtu0gwpy1I5boo+mNApLQU+xiKKQVQbHduf7x2Z9/P+9/s86T
         Aj72jQR0/qzpX+vRP0U2WTqU3Im4A59aL1czrsRIWmLkpLpWDfTF4vSYh9axRJvcdVZl
         Vqpg==
X-Forwarded-Encrypted: i=1; AJvYcCXHnIXc/VgXyDR/aVYQU1ygeg094VeRqQylQXDEnWmLUQyFhoX27JGSlCYPXqt5k/pMFlbpzivIB08=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwJql5Mc4ymMNgnVw67btVSeigvQUTlvETwisfLcCw0TZ/OUEwQ
	Ey9xc0MPYmS3eXGLawVDeNNWqtnplDI41gB3HCkWIglbhpOAP031gIzturoK3avQY8TaXX8IGbM
	SXKCUCj06lbrs4e/7B+6qkLQKbbIT+OUuYcQlBw==
X-Gm-Gg: ASbGnctsDjNUOH+m10ykuL3Qg0lN3bvHrxA+YL+TxtdlE2EwNS+FFZpgIUc/wkDY34k
	Kzuqghki82Js2hW3uTXE+vC7nzCDYA/knQWBK
X-Google-Smtp-Source: AGHT+IEDj4eRUf2qfd1XC67F1wiWGrszpuCEh/KahbAP7gBO4euqu6w/HNUuSDmbIckUjUy9MObojvgL5RjFCDkxKsc=
X-Received: by 2002:a05:6870:6e87:b0:29e:4ba5:4ddc with SMTP id
 586e51a60fabf-2aa0673901dmr3618444fac.24.1736436629164; Thu, 09 Jan 2025
 07:30:29 -0800 (PST)
MIME-Version: 1.0
References: <20250109131515.1757764-1-marmarek@invisiblethingslab.com>
 <d7421558-c2d6-485b-96bf-927992c5c066@suse.com> <47378338-ac05-4041-a055-56045e5ba131@citrix.com>
In-Reply-To: <47378338-ac05-4041-a055-56045e5ba131@citrix.com>
From: Frediano Ziglio <frediano.ziglio@cloud.com>
Date: Thu, 9 Jan 2025 15:30:18 +0000
X-Gm-Features: AbW1kvaJNCGU_fqbt_IeEkewgFAx4IlA-fmf6cQyL5X62d7uRzwuiYTWJfwMo_k
Message-ID: <CACHz=ZjR6dSy_NsrXkhf_VfZpGYE4et6VkQvU_cO9DdAnXBzxQ@mail.gmail.com>
Subject: Re: [PATCH] x86/boot: adjust text gap/diff to work with 64-bytes
 alignment too
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>, 
	=?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= <marmarek@invisiblethingslab.com>, 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
	xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 9, 2025 at 1:44=E2=80=AFPM Andrew Cooper <andrew.cooper3@citrix=
.com> wrote:
>
> On 09/01/2025 1:23 pm, Jan Beulich wrote:
> > On 09.01.2025 14:15, Marek Marczykowski-G=C3=B3recki wrote:
> >> Xen compiled with -mtune=3Dgeneric has .text alignment set to 64-bytes=
.
> >> Having text_diff non-64-bytes-aligned breaks stuff:
> >>
> >>     Traceback (most recent call last):
> >>       File "/builddir/build/BUILD/xen-4.20.0-build/xen-4.20.0-rc0/xen/=
./tools/combine_two_binaries.py", line 96, in <module>
> >>         raise Exception('File sizes do not match')
> >>     Exception: File sizes do not match: 70160 !=3D 4080 + 66048
> >>
> >> Adjust the numbers as suggested by Frediano to work with 64-bytes and
> >> even 128-bytes alignment.
> > And then breaking at 256? As indicated on Matrix, imo we should be able=
 to
> > cope with anything up to at least PAGE_SIZE. Or we should reduce .text
> > alignment before linking.
>
> Do you have a concrete proposal on how to do this?
>
> Because if not, we've had 2 downstreams hit by this build failure, and
> we probably ought to take this patch as a stopgap fix, and see about
> doing the better fix for 4.20.
>

I agree with this, merge this and then leave the improvements for follow up=
(s).

Yesterday I checked the output object file (built-in-32.o) to find
that the output alignment is 1 byte, which is obviously wrong!

There's no current requirement for page alignment. As page management
is done in both 32 and 64 bit code, pages are allocated in other parts
of the sources and handled correctly.

Personally I prefer incremental development with sensible and
self-contained improvements kept separate, instead of adding changes
and changes because somebody touches a piece of code that can be
improved. Usually any piece of code can be improved.

Frediano


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:39:45 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:39:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868814.1280326 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVudK-0002ZT-CH; Thu, 09 Jan 2025 15:39:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868814.1280326; Thu, 09 Jan 2025 15:39:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVudK-0002Yp-7l; Thu, 09 Jan 2025 15:39:42 +0000
Received: by outflank-mailman (input) for mailman id 868814;
 Thu, 09 Jan 2025 15:39:40 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=rr8/=UB=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tVudI-0002Hw-MF
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:39:40 +0000
Received: from mail-ed1-x541.google.com (mail-ed1-x541.google.com
 [2a00:1450:4864:20::541])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id efce0532-ce9f-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 16:39:39 +0100 (CET)
Received: by mail-ed1-x541.google.com with SMTP id
 4fb4d7f45d1cf-5d90a5581fcso1640350a12.1
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 07:39:39 -0800 (PST)
Received: from andrewcoop.eng.citrite.net ([83.105.36.37])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c95aede8sm82723366b.136.2025.01.09.07.39.37
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 09 Jan 2025 07:39:37 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: efce0532-ce9f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736437178; x=1737041978; 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=L3YsgkxCJNhRWuii4lScraZ8R8FAXUDtlUaTp5QBmgQ=;
        b=Wcz/24rrOOSpkctzWZ/Dy66SYzWyAEo3tiv8PiBTv3YNLpkkQ5bFGhrkEdGrjmztu9
         BgekegB6NGD24uVZTIqUVraHmPCeTv9Ci5IFlKC5Y8e6p6LbjXo20zTV7c11tYEeTYEM
         AqOPpwX+3tKP7YROdjI1SAKtFlL6j3d6krVTw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736437178; x=1737041978;
        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=L3YsgkxCJNhRWuii4lScraZ8R8FAXUDtlUaTp5QBmgQ=;
        b=qXpeikXQR9tbLA/ERCtrSvfYpS/RC99qQ4tJTShNOa2lIhwITbSY+3NZx2biIdlrSj
         K7+i4JVl/hLnwHrTxPZ7rzDkFcqXSNcigulKk2ImXsmYixBoGFU8OnmovEvLzv1x9cV2
         6iMRTma/38WxN6rlBFnxCIjcz7Srd93eOcMUC8myQvknvax/J5ZAK1abwl88AgknSyQd
         0MbPPfO/E+P4QmAN7pk3YFXboIYlOUt50z67CkN3gxyHNWFEBKgcNQXJbKGBzEFtBg2I
         O7wwJaLcfcuQyLIR5s/oahSNNSt3T5HgyGlCvZe1PVf7Fti1Jb4hM/CUWalgNpZRqllW
         VJ/w==
X-Gm-Message-State: AOJu0YwO12WU86DsVrGJoH7VdhKc0qqM1GJremqPVz2L6tB5YY/o1Pn+
	dRWfPcx+xGXCJebfi4EP9St3ZIgTGNlPF+3JWHDdueJ52+HoKPnR4/UCk7UBqekv8UIhVCqkOI3
	S7sSb8zqL
X-Gm-Gg: ASbGnctlTw/qzQHB6ur+VBpkYwbg/wY039sGa7idJpRXS3o1Ako6aHr8HMxFdQHqIFG
	VwSHlzeGLbIWk6k1Ja00Pz86LIBNUEhVLg/8hwoXLkv5VG8TwJyv+GKPuGuqXXYCmc0eMGVmUZg
	5wcMswbUF/GpGw9SUa/6xs3oPiu3Kk3sk4bM6dibdqnl96mjVxWTq8JAGeNyuebKeZYaQ4/E/Ek
	1P4Ws/RaMn72nVR52noz2GV2X/9gjsW1nKVksmTRE83BIxKpwZh9Fnxq27PYwpn+sCM37zLEIdA
	i4xLgg==
X-Google-Smtp-Source: AGHT+IG1mAN+AzsRq6EbTZFQRTyMfOZ+1JQC8+kevnPyWaOqa1CNW2p3/eY0QMScXAGTHypqSjJARA==
X-Received: by 2002:a17:907:1b86:b0:ab2:b8c3:be3c with SMTP id a640c23a62f3a-ab2b8c3c336mr447300766b.51.1736437178346;
        Thu, 09 Jan 2025 07:39:38 -0800 (PST)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>
Subject: [PATCH 2/2] Update Xen version to 4.20-rc
Date: Thu,  9 Jan 2025 15:39:21 +0000
Message-Id: <20250109153921.43610-3-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250109153921.43610-1-andrew.cooper3@citrix.com>
References: <20250109153921.43610-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Anthony PERARD <anthony.perard@vates.tech>
CC: Michal Orzel <michal.orzel@amd.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Julien Grall <julien@xen.org>
CC: Roger Pau Monné <roger.pau@citrix.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 README       | 16 ++++++++--------
 SUPPORT.md   |  2 +-
 xen/Makefile |  2 +-
 3 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/README b/README
index 72f6b0fcde47..373885523c8e 100644
--- a/README
+++ b/README
@@ -1,11 +1,11 @@
-############################################################
-__  __                                _        _     _
-\ \/ /___ _ __        _   _ _ __  ___| |_ __ _| |__ | | ___
- \  // _ \ '_ \ _____| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
- /  \  __/ | | |_____| |_| | | | \__ \ || (_| | |_) | |  __/
-/_/\_\___|_| |_|      \__,_|_| |_|___/\__\__,_|_.__/|_|\___|
-
-############################################################
+#####################################################
+__  __            _  _    ____   ___
+\ \/ /___ _ __   | || |  |___ \ / _ \       _ __ ___
+ \  // _ \ '_ \  | || |_   __) | | | |_____| '__/ __|
+ /  \  __/ | | | |__   _| / __/| |_| |_____| | | (__
+/_/\_\___|_| |_|    |_|(_)_____|\___/      |_|  \___|
+
+#####################################################
 
 https://www.xen.org/
 
diff --git a/SUPPORT.md b/SUPPORT.md
index 54c78b722d7a..2bc5bd81ee39 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -9,7 +9,7 @@ for the definitions of the support status levels etc.
 
 # Release Support
 
-    Xen-Version: 4.20-unstable
+    Xen-Version: 4.20-rc
     Initial-Release: n/a
     Supported-Until: TBD
     Security-Support-Until: Unreleased - not yet security-supported
diff --git a/xen/Makefile b/xen/Makefile
index 2e1a925c8417..1eca2bdb4939 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -6,7 +6,7 @@ this-makefile := $(call lastword,$(MAKEFILE_LIST))
 # All other places this is stored (eg. compile.h) should be autogenerated.
 export XEN_VERSION       = 4
 export XEN_SUBVERSION    = 20
-export XEN_EXTRAVERSION ?= -unstable$(XEN_VENDORVERSION)
+export XEN_EXTRAVERSION ?= .0-rc$(XEN_VENDORVERSION)
 export XEN_FULLVERSION   = $(XEN_VERSION).$(XEN_SUBVERSION)$(XEN_EXTRAVERSION)
 -include xen-version
 
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:39:45 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:39:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868813.1280321 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVudK-0002XQ-3d; Thu, 09 Jan 2025 15:39:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868813.1280321; Thu, 09 Jan 2025 15:39:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVudK-0002XJ-02; Thu, 09 Jan 2025 15:39:42 +0000
Received: by outflank-mailman (input) for mailman id 868813;
 Thu, 09 Jan 2025 15:39: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
 <SRS0=rr8/=UB=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tVudI-0002JF-9W
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:39:40 +0000
Received: from mail-ej1-x641.google.com (mail-ej1-x641.google.com
 [2a00:1450:4864:20::641])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id effc5b1d-ce9f-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 16:39:39 +0100 (CET)
Received: by mail-ej1-x641.google.com with SMTP id
 a640c23a62f3a-aab925654d9so223668066b.2
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 07:39:39 -0800 (PST)
Received: from andrewcoop.eng.citrite.net ([83.105.36.37])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c95aede8sm82723366b.136.2025.01.09.07.39.36
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 09 Jan 2025 07:39:37 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: effc5b1d-ce9f-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736437179; x=1737041979; 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=iBELJMfcQLbPtCCptLilrfSS47bvE3E/Zw4kGGrBEv0=;
        b=pqOaBmckgw4XfVenNeUNgITcl3Nr6PdP7Aj2coBsQhW21TmsCEaDTlM6bwIcfzbYRX
         szPIcz0anSKzf6H53Jc4FURdflrZgmbTTYgT8p0rXqpm050Z3/phojCHunPUatEcR3zu
         Wni3coUuJOBBXV65JPRa5bf6DunvjuJuIeVrc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736437179; x=1737041979;
        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=iBELJMfcQLbPtCCptLilrfSS47bvE3E/Zw4kGGrBEv0=;
        b=YKveGjN0cFl6Gy210NzS7FR/W+JmQ21Ax5yC1kjXuXJ72N8T+X30i4yyylJFuPd0i+
         oZM2rF91CWL4E/GAmjSJbx+LwN4l2AOXMkZgANsuVZ2nyP/pXhz1wjqawsxgYzp/9gNP
         ZCTbQ0l9xA6VzniRziaxbWB2llk5MZgBN75i4lbfVy4KriyhyZt1IUsxzv6prYGnB89L
         UNHyJXmdxnvDYSy0jN81Ja5AbJXs5mDTfca0AYszZoiwk72ZsS6uFoi6oJQvvfNyNP8y
         cHZzBiXYBVqK4lMjfaS2eFdIluc+PdB6uwYXDe38SypsHMKjjkkVbyqL0e1+ccXu+Gw5
         0IEw==
X-Gm-Message-State: AOJu0YxgOqScROU6ypdPtTQK3hitH2lJs5TF10oFnCJgjXioC4NpjcFc
	chLPFheSuVnu+uOKU6ddVO7/QG021PrC+3zz+dtElgidPdpvXcwIciv8TE5sXslAuyZYO/mfhc+
	yhQ0zzY1G
X-Gm-Gg: ASbGncvTSxqp4bY3kyaZdnrOSAQKtmIDH0uBRZZNg2hrm+d0WglUEpvFJVojFWPCVEP
	IzCDYSNvhXAI1AGFdrqtFdKLB6pGT8f5Oeh75S3OMgYdP7xw6mhidvrnMLvWDbfb1q8T70x2D4d
	ljQUSxF5XDx1Bzz87aG/+z40l4b/yoBBfH+LM8bh3703UJk/vaFu8XE/8Qkaw0vhokA7ldq1cG6
	6W/Ofyaz53TQTZ0aiS75oZkCg+lEcIU/Oo5al714w+FElQEbQQf8Wu+rcurXRDT4b5HUgRq91f7
	ArBdWw==
X-Google-Smtp-Source: AGHT+IHtP4FOlBZjpbvvefs9nxJn0Hn8juf6phznlEVYdIEpbER1mVFllXQ6UD0UNUGCHrgsTnfjZA==
X-Received: by 2002:a17:907:3d93:b0:aa6:66bc:8788 with SMTP id a640c23a62f3a-ab2abcab45emr684090166b.45.1736437177552;
        Thu, 09 Jan 2025 07:39:37 -0800 (PST)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>
Subject: [PATCH 1/2] Config.mk: Pin QEMU_UPSTREAM_REVISION
Date: Thu,  9 Jan 2025 15:39:20 +0000
Message-Id: <20250109153921.43610-2-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250109153921.43610-1-andrew.cooper3@citrix.com>
References: <20250109153921.43610-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Anthony PERARD <anthony.perard@vates.tech>
CC: Michal Orzel <michal.orzel@amd.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Julien Grall <julien@xen.org>
CC: Roger Pau Monné <roger.pau@citrix.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 Config.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Config.mk b/Config.mk
index fa0414055b93..13aa6ce3ab26 100644
--- a/Config.mk
+++ b/Config.mk
@@ -221,7 +221,7 @@ OVMF_UPSTREAM_URL ?= https://xenbits.xen.org/git-http/ovmf.git
 OVMF_UPSTREAM_REVISION ?= ba91d0292e593df8528b66f99c1b0b14fadc8e16
 
 QEMU_UPSTREAM_URL ?= https://xenbits.xen.org/git-http/qemu-xen.git
-QEMU_UPSTREAM_REVISION ?= master
+QEMU_UPSTREAM_REVISION ?= 3fdb3cd3a27a22a050c7d27126a24807a7a45745
 
 MINIOS_UPSTREAM_URL ?= https://xenbits.xen.org/git-http/mini-os.git
 MINIOS_UPSTREAM_REVISION ?= 6d5159e8410be16a47433bac1627e63f8adc7cd9

base-commit: 40f35d07aa14bde44d7baafad171f7c92b053017
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:39:46 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:39:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868812.1280311 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVudI-0002JY-T4; Thu, 09 Jan 2025 15:39:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868812.1280311; Thu, 09 Jan 2025 15:39:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVudI-0002JR-Q3; Thu, 09 Jan 2025 15:39:40 +0000
Received: by outflank-mailman (input) for mailman id 868812;
 Thu, 09 Jan 2025 15:39:39 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=rr8/=UB=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tVudH-0002Hw-9D
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:39:39 +0000
Received: from mail-ed1-x544.google.com (mail-ed1-x544.google.com
 [2a00:1450:4864:20::544])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id eec35999-ce9f-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 16:39:37 +0100 (CET)
Received: by mail-ed1-x544.google.com with SMTP id
 4fb4d7f45d1cf-5d3f65844deso1597650a12.0
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 07:39:37 -0800 (PST)
Received: from andrewcoop.eng.citrite.net ([83.105.36.37])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c95aede8sm82723366b.136.2025.01.09.07.39.36
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 09 Jan 2025 07:39:36 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: eec35999-ce9f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736437177; x=1737041977; 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=PUHykMg+qTNNNoZ4AzcISeSLhmGpDC7jBb9/QneoS9E=;
        b=vKcxQAOyGRfZf8dOt3pewl3A2cqYg2fzBAYMxosHbaT0RxnZzhfRcTJmexk56/5Cc3
         h24/bwybSVSaq3AHgUaYX80MgkMMRGI4Avl8ihVjwDfEwjjNK6eb7PP/JvQIDbs7S0qV
         7ZrbONPAyRdpHZobRavXUQzc+hCIqA5s7W1iA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736437177; x=1737041977;
        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=PUHykMg+qTNNNoZ4AzcISeSLhmGpDC7jBb9/QneoS9E=;
        b=gHmOmZfSK8/GlFlhUmhcj/TLo8lnwlD4bd3qZOblQmCHNHj30+Xx+L0Nk/FLuqpMPr
         lmJA8o7qtXi2QYotqEingxCTFaZHxPidRjvZoGnffsUFReQjWY4vVL1KNRoXrlh0g6Dl
         EiBmitMx8U8qdLVhqumFTixIstotIHpsAn/FCTL969GAQNSHl7Dv4C5Bje7mjFhZNb3Y
         LFYEK+GkzSF4LXzp6sgDXA4IVhe8nXfF8VcV+zf6yVpJhyk+MVVx+4opFPvMXrf4KZ2E
         RURT0uPUlVqkWTW/pcLeffrNoCOFIrcemrGSc2SbqBUhPtIj1mtNdeDBrioF5NRxnx7g
         zOOA==
X-Gm-Message-State: AOJu0Yx5p5H1Hw39LPxk1e8yfIJ3rM3Gq9hewpndzd63K78mIt+buPgL
	WgH5oW/Obeb8w6sCrAXRsn/FpuHITWL4rNgCNKC5O1c5DjDhoYZfXuzXq4+TXgmC/Hmi6H+0sSM
	lnj2yv2kg
X-Gm-Gg: ASbGnctDhYPI+QZk4hVC5kleMtCuvLsSo2sS9mjnnuj5xaxWK39hPM1DIcC9/+WF9Ry
	P/ayFfGI94VBkjcMixKaBMSekVh3AaFQsZ/owyoR08XlEuNDOMn7ybCB5nUsnX/qDrbB41uCNOQ
	Nmz/vs+1rD7Y4EflXbP4/oK7rlbp+NGNKR3wPuc3ZUubksvWWy3xVQ8cPncODNaH42uoaqW3Gzv
	ETk5NgNzhYo/pasa3Ob316dVOI/6R/PFaQsn8h1kj5DfXasCy47Qx+D3rytssRqGGhvMkCSAN1d
	muMFOg==
X-Google-Smtp-Source: AGHT+IGQWuSJ7jquH1H9yx7VCPn1auv47Z+XoQYe3Mrv64gGl5OysGCMbyo3QQf22ZFvvbnmw+B6nw==
X-Received: by 2002:a17:907:998c:b0:ab2:c2f1:4578 with SMTP id a640c23a62f3a-ab2c2f145fdmr318902666b.4.1736437176619;
        Thu, 09 Jan 2025 07:39:36 -0800 (PST)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>
Subject: [PATCH for-4.20 0/2] Prep for 4.20-rc1
Date: Thu,  9 Jan 2025 15:39:19 +0000
Message-Id: <20250109153921.43610-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

RC1 is scheduled for tomorrow (Jan 10th).

Andrew Cooper (2):
  Config.mk: Pin QEMU_UPSTREAM_REVISION
  Update Xen version to 4.20-rc

 Config.mk    |  2 +-
 README       | 16 ++++++++--------
 SUPPORT.md   |  2 +-
 xen/Makefile |  2 +-
 4 files changed, 11 insertions(+), 11 deletions(-)


base-commit: 40f35d07aa14bde44d7baafad171f7c92b053017
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:44:17 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:44:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868837.1280341 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVuhj-0006PH-Rf; Thu, 09 Jan 2025 15:44:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868837.1280341; Thu, 09 Jan 2025 15:44:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVuhj-0006PA-On; Thu, 09 Jan 2025 15:44:15 +0000
Received: by outflank-mailman (input) for mailman id 868837;
 Thu, 09 Jan 2025 15:44: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 <SRS0=pS5t=UB=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVuhj-0006P4-1t
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:44:15 +0000
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com
 [2a00:1450:4864:20::335])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 93ac9dd7-cea0-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 16:44:14 +0100 (CET)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-43625c4a50dso9062305e9.0
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 07:44:14 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436e2dc0069sm60145395e9.11.2025.01.09.07.44.12
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 07:44:13 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 93ac9dd7-cea0-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736437453; x=1737042253; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=QZNVryZ2V3wnkRwb8LAQRPN50IYrgFAUD6O6S1spCEs=;
        b=I+Hq/JzkKMPF7IDVNkXDCXnnfjcKDcYNPnDQB2Y4iFM0m8nTUcqmyuXTvdinlxR/vD
         cPpwAPjTyGYo1F83fJ/lFyqgkdzey5Rw3RBX0OhfA/H4zGSSsrvUaxuDvpqFWO36WRs+
         I4vIWTyK6yXs1NN+Hxhq6exupweEReHi0nhjKYqMESQOd7wlsX86UazXbHVnxbBc2JLg
         CvmJT7kusdNOVNyMihcvcWztCIA6DrkCmxVRmBO6iq/PT7FDxZDxuN/oTsYDve+QUmFE
         gSg9PDqkSsQiA0k4g6tciBEsLjyki5oTrtsDEKK8xKJwg8B21+OkJYUAyOFsuCXA+wDw
         9IUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736437453; x=1737042253;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=QZNVryZ2V3wnkRwb8LAQRPN50IYrgFAUD6O6S1spCEs=;
        b=epOWnzwU6fjdtSBBgFBQePZ4WgwWfL89owqbyHUL0JLSD3DKB4+qqjQ2B2mcRNCCwi
         JnndAw1fLH+KrG8zVgiGnopuMrUFNCgP9GI+2fRSypBXCWqS50GgW34oxd8Acsfch5b2
         8yIgmfzaKgnygYWj/mWz4qwdNC2SRItTOoSoll0hck4eYU2mly/QsQg96fTOO3VOx4q3
         gr0b9W6RqBRc7UaeZbdQp0aIHDdb3M0kcFZvmkKyJsS1ChrbA7JvyO/dJJBDfA8A/GDA
         4J3olS6S2WGGXNxUEbRNs3ewQOcGeEBRoD5Qa6Tfna7w4I+QWN5fK0Y5p6YXLbkSKVea
         83Pw==
X-Forwarded-Encrypted: i=1; AJvYcCWp9lErlWQUz3HZM/eMKccbJXHxJlrpHyu/UZplarU1hNycJ8w4ip1usKuQ9tgzmzbo9/e0NPAb+3Q=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxByEIrPV1wsLuohk94XOE+g1cIOI9IBFNvFwL7DZgunD6lA/ts
	Qpk9/kISf7aR4BUnFVgVTIVfV7l0q2/FDY5/jPmk65TbvqFwNup9lIZUQ7uAUg==
X-Gm-Gg: ASbGncvUzD85vQeWDrh3kynkMzdF175N2RyF/RvwWAbRjKPb10VQ2UHGKR4F+IGGV5P
	RCFONGkWB2NYL7DWhLJ4WQlfJnpI6koXp7H1L/vPXBzhQCQzVr9y7A+UwBDF9Z4AyUGyHxFHDad
	FRY23Q3YwRe6EAaArdMMvSkcqdIfrkMp7DNKZZ85jbil8AgBqsMiNXEwbAptah94v9lGsc1Ojnk
	bnpVzHAveA78hblAwb4N+9FEn0/pxPpDtLdcCKse16kWdeawYk89PQh6PBKpW7Q7HAYWl56EmHX
	zsXTd3gtfE+ZaSWKbTyDxXqpBg/V9r4bZrO3mQmoQg==
X-Google-Smtp-Source: AGHT+IGxxHi23askfoSi56FozuLIP9LXgYvqyMA+/SYq/1f2WGGFHdb2D19FrfFBE02xsL2M6RfUUw==
X-Received: by 2002:a05:600c:4ed3:b0:434:f7e3:bfbd with SMTP id 5b1f17b1804b1-436e26dda8cmr59490845e9.23.1736437453506;
        Thu, 09 Jan 2025 07:44:13 -0800 (PST)
Message-ID: <67278014-8208-48f2-92ba-7b843a0d373b@suse.com>
Date: Thu, 9 Jan 2025 16:44:11 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/2] Update Xen version to 4.20-rc
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20250109153921.43610-1-andrew.cooper3@citrix.com>
 <20250109153921.43610-3-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250109153921.43610-3-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 09.01.2025 16:39, Andrew Cooper wrote:
> --- a/README
> +++ b/README
> @@ -1,11 +1,11 @@
> -############################################################
> -__  __                                _        _     _
> -\ \/ /___ _ __        _   _ _ __  ___| |_ __ _| |__ | | ___
> - \  // _ \ '_ \ _____| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
> - /  \  __/ | | |_____| |_| | | | \__ \ || (_| | |_) | |  __/
> -/_/\_\___|_| |_|      \__,_|_| |_|___/\__\__,_|_.__/|_|\___|
> -
> -############################################################
> +#####################################################
> +__  __            _  _    ____   ___
> +\ \/ /___ _ __   | || |  |___ \ / _ \       _ __ ___
> + \  // _ \ '_ \  | || |_   __) | | | |_____| '__/ __|
> + /  \  __/ | | | |__   _| / __/| |_| |_____| | | (__
> +/_/\_\___|_| |_|    |_|(_)_____|\___/      |_|  \___|
> +
> +#####################################################
>  
>  https://www.xen.org/
>  
> --- a/SUPPORT.md
> +++ b/SUPPORT.md
> @@ -9,7 +9,7 @@ for the definitions of the support status levels etc.
>  
>  # Release Support
>  
> -    Xen-Version: 4.20-unstable
> +    Xen-Version: 4.20-rc
>      Initial-Release: n/a
>      Supported-Until: TBD
>      Security-Support-Until: Unreleased - not yet security-supported
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -6,7 +6,7 @@ this-makefile := $(call lastword,$(MAKEFILE_LIST))
>  # All other places this is stored (eg. compile.h) should be autogenerated.
>  export XEN_VERSION       = 4
>  export XEN_SUBVERSION    = 20
> -export XEN_EXTRAVERSION ?= -unstable$(XEN_VENDORVERSION)
> +export XEN_EXTRAVERSION ?= .0-rc$(XEN_VENDORVERSION)

Since we'd been there before I take it the .0 in here (which isn't in the
changes to the other two files) is deliberate now? Clearly I continue to
think it shouldn't be put there together with -rc.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:46:17 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:46:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868852.1280351 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVuje-0007XZ-Am; Thu, 09 Jan 2025 15:46:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868852.1280351; Thu, 09 Jan 2025 15:46:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVuje-0007XS-7z; Thu, 09 Jan 2025 15:46:14 +0000
Received: by outflank-mailman (input) for mailman id 868852;
 Thu, 09 Jan 2025 15:46: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 <SRS0=pS5t=UB=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVujd-0007XK-23
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:46:13 +0000
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com
 [2a00:1450:4864:20::42b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d975fe0f-cea0-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 16:46:11 +0100 (CET)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-385f07cd1a4so725046f8f.1
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 07:46:11 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a9407fd62sm318816f8f.92.2025.01.09.07.46.09
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 07:46:10 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: d975fe0f-cea0-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736437570; x=1737042370; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=oQVwmZxbNLLILr1CnM8P4SWHt7jRq2iQ5dx8sauSL5o=;
        b=RO6MA01kyX8wRR9WF6PSyk+EUFcZTPj9hKUPY7YCbSw8k4909sCHmA3cVkqRzNe2ej
         kmYqRt0p++Ns+1qWatRiDhc1sOveM56PggZyifIDMrt8LtBdBHh7uN3G4ee5FBsJswLc
         Ua4MDb6mN1uOZ/ZkI8xrYjjvgSm5Y7hwqRMm56s5IfMj1S8+4JY181d76rQVBJ4rPMCa
         BNb0Mvmq75/sLTC5OvOcP0m2J2UUKYOLsPjI8LMZD+n/56i/CpNWdBgjqydwfMi9d0rW
         7lnjsHT0r48hfZT302bggcXUUcL8CzJKdzzMa2FVZJ7LOqBoSwS6O5CjCFIhIV9V+b4A
         zByA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736437570; x=1737042370;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=oQVwmZxbNLLILr1CnM8P4SWHt7jRq2iQ5dx8sauSL5o=;
        b=AC6g+hpxROnypnyug8JzFUm55dlwLir+AhTRl320MQJJwWOTgjYMoVZ+r0lreuVL43
         z5mrfNbtOmKCvhTTRq0HD/k6xfV0fbU9pug8zCP4HH6ez2YOBUoyIRDI7Ts2WocqHc3l
         loNRj5bIATWS1iuzPbjFQ93mkjjYOj4sP/4kcS/6lFQ1/ZADidHVbG+R3CzagXvSE8YC
         wwBChhuwx3ndaZBWmovme+HE6veWRn1jQ27fT7vX+BDFjciD0CY0kBZHirKw16yk0YBc
         lxn39OXhYsF2Os9KdhaXHRjYowmqaXoLB+rl07/dDnIUMWXK6JVKvQrFn/pgWX9uha6d
         3tQA==
X-Forwarded-Encrypted: i=1; AJvYcCX2NuleMxNgqeWQNMRUAdU8vS/Ai1v1igLRzr9aX3lVsqnr6LXCh2dpsKvhFs787wmzcdsuEwuzTi0=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx5uoBhiibPU+RlXiHp+whFsspjZ6CgtffkpuNk3nHrlPJ1JLCw
	D+/vGhtHHwiP+SwzJa/CwyOmgRvyOcspoAeQwRTovR44U82+6zKJYaCh3TNphw==
X-Gm-Gg: ASbGnct2Nzx6cL8qOoeMgEKyFujmGf8kl18dPvr/Y9Iepdw61rC7oN89vsPeB891T8J
	bJGu+cszvWtZoUP9GX41OTgOVN96h0sbnhn3EEdvpSlVtTlh5kkpe4tQi4etIV7o2C5uudmTax3
	J2AV19uU2QgCXM1Xg5/NdTqRnRskUFsO9WrQj/sktOyj3Tx0ToMIgV3mb2TNiZaxawagjugxAJx
	jDJa286Z4ysRMAfRLYoPsZDNs23bsOwK9wAP58Lkp092MJ6o5H+ylrJ3cithEh4GsPw//J8AwHm
	SIvH05vTyrZLcqfs+cuuMzGhIGR0ihfp7WeKX9ye3Q==
X-Google-Smtp-Source: AGHT+IFr7L4PH8JBbsjr7AdoYXvWdFX0VMLQaxUyz+WwqcnsMDw8Px2hlkDY8NCwPlqSxEvpzJ0wNA==
X-Received: by 2002:adf:b197:0:b0:38a:88b8:99af with SMTP id ffacd0b85a97d-38a88b89a0amr4570426f8f.22.1736437570592;
        Thu, 09 Jan 2025 07:46:10 -0800 (PST)
Message-ID: <cb4fbf1a-df46-4891-9614-f5d87512a654@suse.com>
Date: Thu, 9 Jan 2025 16:46:08 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 1/7] xen/events: fix race with
 set_global_virq_handler()
To: Juergen Gross <jgross@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <20250109105935.23585-1-jgross@suse.com>
 <20250109105935.23585-2-jgross@suse.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250109105935.23585-2-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 09.01.2025 11:59, Juergen Gross wrote:
> There is a possible race scenario between set_global_virq_handler()
> and clear_global_virq_handlers() targeting the same domain, which
> might result in that domain ending as a zombie domain.
> 
> In case set_global_virq_handler() is being called for a domain which
> is just dying, it might happen that clear_global_virq_handlers() is
> running first, resulting in set_global_virq_handler() taking a new
> reference for that domain and entering in the global_virq_handlers[]
> array afterwards. The reference will never be dropped, thus the domain
> will never be freed completely.
> 
> This can be fixed by checking the is_dying state of the domain inside
> the region guarded by global_virq_handlers_lock. In case the domain is
> dying, handle it as if the domain wouldn't exist, which will be the
> case in near future anyway.
> 
> Fixes: 87521589aa6a ("xen: allow global VIRQ handlers to be delegated to other domains")
> Signed-off-by: Juergen Gross <jgross@suse.com>

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




From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:46:51 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:46:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868861.1280360 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVukF-0008Fm-II; Thu, 09 Jan 2025 15:46:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868861.1280360; Thu, 09 Jan 2025 15:46:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVukF-0008Ff-Fd; Thu, 09 Jan 2025 15:46:51 +0000
Received: by outflank-mailman (input) for mailman id 868861;
 Thu, 09 Jan 2025 15:46: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
 <SRS0=rr8/=UB=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tVukE-0008FP-KC
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:46:50 +0000
Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com
 [2a00:1450:4864:20::344])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f0769359-cea0-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 16:46:49 +0100 (CET)
Received: by mail-wm1-x344.google.com with SMTP id
 5b1f17b1804b1-4362bae4d7dso8634715e9.1
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 07:46:49 -0800 (PST)
Received: from [192.168.86.29] ([83.105.36.37])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436e2da65a3sm60119745e9.7.2025.01.09.07.46.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 07:46:48 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f0769359-cea0-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736437609; x=1737042409; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=T2s0FnzdFE2FjkmWbN6mMjF08lODMgKgBLZSCmVE3bE=;
        b=aFtvAPjP5FHRfptpZAR3LgjnCjV558X4EN4RVqh3+dlObbLWf48rUkHyrHyzUrMyyy
         E1zGePkT1zozSDOIMPgonjPWDB72mwKhmceFim0bSGgmMfMAg7TA5A5Sl7d8znKX6IVi
         W7x7w3zEGaO19UOPksYE5f05A3lOs4LXT3P4E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736437609; x=1737042409;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=T2s0FnzdFE2FjkmWbN6mMjF08lODMgKgBLZSCmVE3bE=;
        b=B9u3AXRgtjZ5fWaAFnZsT9I9BV+STscFQPqqLLyEPDMxokaLGRkmzRvYn1qjCzJpWx
         1NieMyDeMvqcmdB6WN6On0JE+jfUzVvKgzGHHC/w94/CfZX7+L58nbvigxloIUfQziyD
         5bqMnFSurJWVfZBKetBG/jwKKte9zLlbPyzns/kywaD06AhnXt+exloGPBaiDCTaHGRa
         W8Rn/+29Rrp5auMAtN5c66PQWCJXIS2SHf4EL43xaFSlhNfUPyUBnaQ7/oL5aTChMzHn
         Sb57ZmR9OK2K0cEfb21GFVj4nqB6PUxVCTCACYWwFS3XRb2LWaZ9whiBTfKjk06xCDmu
         ZY7g==
X-Forwarded-Encrypted: i=1; AJvYcCWuP5D0Vrx17NYHrydFWUFu+KEQAa0V/BgUF3dSPfE8zWwqRTsZnFPv/vTOcY/e19XDJlT9R9xDXTQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyY4LnYaTDIx8yAXNNcqShCG+Kys/D2FhqKpmT2O3p8eVYD0jMn
	fHIM4haPPgQLRzR7MepfyYA6iAYbnZ9wgjhxO6aD1h3AJs6gOIRnGXiDt+CCSbg=
X-Gm-Gg: ASbGncs0S6WQ8ptQMdYuO1An7W6QKG71W2HJ2l7hQfAScfEdLCxB7WcJFhrcQ3EUZUG
	PeNafKg2BUDEfVqxNtcVmCNMnm/aajPFJjCmteEe2BKlSppY+P93oU1b7AV4z07pd4acU4CNxo6
	g5vGcfozTLEXV94oWsRsxsGBZBoTElYlAdBJgQtT5aOHKuYiNsbDTKNRRZxecdUWKNLMnA3ckqx
	YYA59TtozE4SQLRPqVDFy5E99sD2b4tvKpq8xL4QA4sFXNI3/37/GoqP/alkdt8YOw=
X-Google-Smtp-Source: AGHT+IGQUNm8MiT+hldRCbc5yGSkSirzGk5f9HQuktuySCngMzvREuyAL0btlX5C9IVWSY34e5zPKQ==
X-Received: by 2002:a05:600c:4e92:b0:434:fdbc:5ce5 with SMTP id 5b1f17b1804b1-436e2707f4amr64449745e9.29.1736437608771;
        Thu, 09 Jan 2025 07:46:48 -0800 (PST)
Message-ID: <c7eeaa80-a4bd-457f-824e-accd23c2f471@citrix.com>
Date: Thu, 9 Jan 2025 15:46:47 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/2] Update Xen version to 4.20-rc
To: Jan Beulich <jbeulich@suse.com>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20250109153921.43610-1-andrew.cooper3@citrix.com>
 <20250109153921.43610-3-andrew.cooper3@citrix.com>
 <67278014-8208-48f2-92ba-7b843a0d373b@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <67278014-8208-48f2-92ba-7b843a0d373b@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 09/01/2025 3:44 pm, Jan Beulich wrote:
> On 09.01.2025 16:39, Andrew Cooper wrote:
>> --- a/README
>> +++ b/README
>> @@ -1,11 +1,11 @@
>> -############################################################
>> -__  __                                _        _     _
>> -\ \/ /___ _ __        _   _ _ __  ___| |_ __ _| |__ | | ___
>> - \  // _ \ '_ \ _____| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
>> - /  \  __/ | | |_____| |_| | | | \__ \ || (_| | |_) | |  __/
>> -/_/\_\___|_| |_|      \__,_|_| |_|___/\__\__,_|_.__/|_|\___|
>> -
>> -############################################################
>> +#####################################################
>> +__  __            _  _    ____   ___
>> +\ \/ /___ _ __   | || |  |___ \ / _ \       _ __ ___
>> + \  // _ \ '_ \  | || |_   __) | | | |_____| '__/ __|
>> + /  \  __/ | | | |__   _| / __/| |_| |_____| | | (__
>> +/_/\_\___|_| |_|    |_|(_)_____|\___/      |_|  \___|
>> +
>> +#####################################################
>>  
>>  https://www.xen.org/
>>  
>> --- a/SUPPORT.md
>> +++ b/SUPPORT.md
>> @@ -9,7 +9,7 @@ for the definitions of the support status levels etc.
>>  
>>  # Release Support
>>  
>> -    Xen-Version: 4.20-unstable
>> +    Xen-Version: 4.20-rc
>>      Initial-Release: n/a
>>      Supported-Until: TBD
>>      Security-Support-Until: Unreleased - not yet security-supported
>> --- a/xen/Makefile
>> +++ b/xen/Makefile
>> @@ -6,7 +6,7 @@ this-makefile := $(call lastword,$(MAKEFILE_LIST))
>>  # All other places this is stored (eg. compile.h) should be autogenerated.
>>  export XEN_VERSION       = 4
>>  export XEN_SUBVERSION    = 20
>> -export XEN_EXTRAVERSION ?= -unstable$(XEN_VENDORVERSION)
>> +export XEN_EXTRAVERSION ?= .0-rc$(XEN_VENDORVERSION)
> Since we'd been there before I take it the .0 in here (which isn't in the
> changes to the other two files) is deliberate now? Clearly I continue to
> think it shouldn't be put there together with -rc.

Oh, that's because I cribbed this by looking at the recent releases.

The documentation leaves ~everything to be desired...

I can drop the .0 here, although I shan't repost just for that.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:49:10 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:49:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868871.1280371 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVumT-0000yy-UA; Thu, 09 Jan 2025 15:49:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868871.1280371; Thu, 09 Jan 2025 15:49:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVumT-0000yr-Qy; Thu, 09 Jan 2025 15:49:09 +0000
Received: by outflank-mailman (input) for mailman id 868871;
 Thu, 09 Jan 2025 15:49:08 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=pS5t=UB=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVumS-0000yl-Sk
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:49:08 +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 42eb4ed6-cea1-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 16:49:08 +0100 (CET)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-4361e89b6daso8896805e9.3
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 07:49: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
 5b1f17b1804b1-436e2dc05a1sm59878145e9.15.2025.01.09.07.49.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 07:49:07 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 42eb4ed6-cea1-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736437747; x=1737042547; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=yG/3DWoK9VEtxCl3OuIsNNW81fipAg43SNdIHPkcq54=;
        b=DldDiyTvBoDBtD0KgwalFkmW8tUjcpr9WbhwBZkVHGHdNFipMqd/toft5g5jHyBKxP
         uKmK995AGiva09umVhIEkvn6d8iyO3KG+h9Tc1drV5kbWSmJYuCx1+fz/gkm4nYcZvgU
         c9PiXXHoPIRaRlwnGhY5kSBm80ZXN+y/ntphGUVf+U7TeQmS4D8pZqxqax75p+d8XP+L
         IHp4TxgWgmByb+VQXwYb5BWYvglkzIXevHHtSsdQK7XMaA7vgem6o75Q46IocL0mhCbQ
         5HGthco8x0R9wvAzo9JCqynlzBHsYC73C1lf525fCmo/CrlSvIo9I9F8bCB7uPOSbYhA
         MPzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736437747; x=1737042547;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=yG/3DWoK9VEtxCl3OuIsNNW81fipAg43SNdIHPkcq54=;
        b=oZ9xTHH4A0CfZJInU64J75Isc3lFJEu5zfoBRrvF8nsrbflK/yY1erATtzrUXPOpXT
         MVpFJmBbwRM4gFLV39G7WDRHc7IV+T6+Z4q7hBe9PUUMk9zMxiNv1aAxnLamBbcpvr/g
         dG1lTgjt3/OmHMHh7cstNOwMr325hyujSEUTZTdQHOEv1YVz9i2qc0b+X3zg+I4x4Td0
         EVCKkbKrUuzcc6mdPjr2FxfJDXeOZTReNXvPkD+9EkpDv+ab6/UM9RRhMPgsqyz2TVBu
         gZRtJzTJffr/IDwzZfubSPQBMZUhHu3qJOCgJkH/go1MG71olKLod3PQXAONBMUhhas1
         Nlsg==
X-Forwarded-Encrypted: i=1; AJvYcCUTnqMbcxULCHcHWzbTIjElQFy88yvXVEQmvoFC56V5xotimVVtvBipg5uj6luzX7iTYvL6fPyrHog=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz3KaVCpdEJo+CJRTuNziBOjbrw0pHE/CZjF0jsrkenWp2owhEi
	0GQ9rRGjNUnTY5wZDCF4d8J2TIGrzC7QcuHLc5LV84FafiJJsW5ELIwTXGKX2g==
X-Gm-Gg: ASbGncuWlA0UzqbddXIsXxjsWYWo5J6FDI5UaSbN0JCKFVNcrvQnMamG3XNy9it76Ae
	nedjC5GAqRf02YZlSQiNvUFpt6SW66gLsYcqlnDjaePRm4pf+QEjOjLay1XV0B97aqHDVUakAR/
	ICILpvaIJyataN2Hoz9N6dYYKNVfmEiF2+JDV00s+Eq4Z+UaMGR51YE1b37kmvUopWP7ErTS9PD
	8nLg1r0kivFwUvJcN2cg4DqgGPYBQlAkIkX6GkdD5JzCQfycReH7g08G+8wp2t/TJPEbjvyjDQW
	DXPB8o7xBVhYxPTHTvMsGU12U7OL1UHCiSZP47z8Sw==
X-Google-Smtp-Source: AGHT+IEFarfKs0uFSicm2xnT7T6Y3k1iVbTo1cBnqhdcbT4Fv3ygHYyXB40NeXtXImbK364hlPpupA==
X-Received: by 2002:a05:600c:35c1:b0:436:a3a3:a70c with SMTP id 5b1f17b1804b1-436e26ef06cmr50701365e9.28.1736437747524;
        Thu, 09 Jan 2025 07:49:07 -0800 (PST)
Message-ID: <96cd80fe-f4f1-430f-ab7c-2ce0befb20d7@suse.com>
Date: Thu, 9 Jan 2025 16:49:05 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 4/7] xen: add bitmap to indicate per-domain state
 changes
To: Juergen Gross <jgross@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <20250109105935.23585-1-jgross@suse.com>
 <20250109105935.23585-5-jgross@suse.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250109105935.23585-5-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 09.01.2025 11:59, Juergen Gross wrote:
> Add a bitmap with one bit per possible domid indicating the respective
> domain has changed its state (created, deleted, dying, crashed,
> shutdown).
> 
> Registering the VIRQ_DOM_EXC event will result in setting the bits for
> all existing domains and resetting all other bits.
> 
> As the usage of this bitmap is tightly coupled with the VIRQ_DOM_EXC
> event, it is meant to be used only by a single consumer in the system,
> just like the VIRQ_DOM_EXC event.
> 
> Resetting a bit will be done in a future patch.
> 
> This information is needed for Xenstore to keep track of all domains.
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>

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




From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:50:42 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:50:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868848.1280380 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVunx-0002rG-6c; Thu, 09 Jan 2025 15:50:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868848.1280380; Thu, 09 Jan 2025 15:50:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVunx-0002r9-43; Thu, 09 Jan 2025 15:50:41 +0000
Received: by outflank-mailman (input) for mailman id 868848;
 Thu, 09 Jan 2025 15:45:39 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=GFlP=UB=minyard.net=corey@srs-se1.protection.inumbo.net>)
 id 1tVuj5-0007JX-JE
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:45:39 +0000
Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com
 [2607:f8b0:4864:20::333])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c4e9e996-cea0-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 16:45:37 +0100 (CET)
Received: by mail-ot1-x333.google.com with SMTP id
 46e09a7af769-71e35be77b5so294447a34.1
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 07:45:37 -0800 (PST)
Received: from mail.minyard.net ([2001:470:b8f6:1b:9076:47eb:1e0a:16fb])
 by smtp.gmail.com with ESMTPSA id
 006d021491bc7-5f882625f0esm386258eaf.9.2025.01.09.07.45.32
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 09 Jan 2025 07:45:34 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c4e9e996-cea0-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minyard-net.20230601.gappssmtp.com; s=20230601; t=1736437536; x=1737042336; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:reply-to
         :message-id:subject:cc:to:from:date:from:to:cc:subject:date
         :message-id:reply-to;
        bh=cgTp2x21PamB5G5tjbV3jPSQRWSgTUkiJmrzV93coW4=;
        b=q6nwCkV41xW+Fds1LDOZpnbvcSLAMdFpaetYqLXTnzUCx7IQj1j0zYEp0XaWBujad9
         /TRD/k7dj6u5VQUDwALtFgAKVCcj5y7MJGzldjUgilyOdiNGLEh2WKNYyudXRw0HRRtI
         Tr3qqSUUGH17QNsyhJYXYheppJzIeBdvHOW6gHDphl2Q75p4B3PuQXGnwhgGN165ySpU
         p31qsrmHbh+h5Fq119u/tuMZo4mg1UidfiOKuFsePnFsKiuG9b+9MAV859mUZIspuuLW
         sY4HJWxPfQJX7AlAqfZ2Hj9wBxkmR1uJ76+vLbIOJMLa2qhc3wJGQoLpXM2TtUGA+h/a
         jyOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736437536; x=1737042336;
        h=in-reply-to:content-disposition:mime-version:references:reply-to
         :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=cgTp2x21PamB5G5tjbV3jPSQRWSgTUkiJmrzV93coW4=;
        b=uoNjiUNfqla2wiKfIc1CXONzzQtuJkCcZWCXUjRUfkLhhnBL14jDIWTImMrXCANhvb
         2mCZl6fmtHjdpy8L2GQf94UY1seyjiT6w0l7CQUA2iXkrUs/2pj2KajL8d4Tsbkmxka3
         o1wPrB2GbXz9+ZErZvNWY67fDQYZqArNTveOi2XndqTN1FAdXNX3i6mhhZ52MD/FuJ9B
         GGWRRowjKL6n2GXZAU2eae2053XS9YujkNPKtZj4xlLrWndHSdcb+nVL1m9Hx8kPAxgo
         So1ieVMraJOYICqaFsE0ESqbvfxk0z+2RkIgwuxer+eDiJccb6KSph3P7B+HanOTKc6E
         k/Rw==
X-Forwarded-Encrypted: i=1; AJvYcCVlDq5RDGTMoMciWnL1g4NqkxwP07YczMn0I6zC3ruIVyOMz208p9j9gb0BaVChW11rc6Jv5y2E6Nc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxGbeouVWadIuctb4flb5ErHvZ5F6hiHzZmjwZIKmHCLYuYotYy
	FaBaG/Eclpi2VI48QsknFFpf1044n8/SR8aaPSX93gvWYfSK5HgwjZNyW/ZZnAw=
X-Gm-Gg: ASbGncus6Py/kNjQGHTCQJR3+RLtaTUY4Mh11o6rGTymyePxfqZ28JldDue2qrFyqIn
	rH7nesQW7rBDp2+WEh6pIR4CVlZU/+P8+XzKWckg2GCmQHfMffTcCwiAucAlfwnATsPENodbW41
	6RE35Bcsc25dTDdUayrbFFlTPJud/0uUGS6DcymMbZtSDPQBqUyvAAF4ZFnHyPeJK5J6vRRkk0+
	/ugOrqA/TXnMNjeZsdxyY/Aj9U5j1tvXahrwRUFBi16676dAmyOO2GehPo0
X-Google-Smtp-Source: AGHT+IHELUnxP9ZvL+e2Ztemz39I9ORoPYZLTVwEa+XG73J5uz7w7yM0cuXu9KZqTaUsGk+1/+jmGA==
X-Received: by 2002:a05:6830:6610:b0:716:a95d:9ef with SMTP id 46e09a7af769-721e2e000d6mr4949630a34.2.1736437534534;
        Thu, 09 Jan 2025 07:45:34 -0800 (PST)
Date: Thu, 9 Jan 2025 09:45:27 -0600
From: Corey Minyard <corey@minyard.net>
To: Joel Granados <joel.granados@kernel.org>
Cc: Thomas =?utf-8?Q?Wei=C3=9Fschuh?= <linux@weissschuh.net>,
	Kees Cook <kees@kernel.org>, Luis Chamberlain <mcgrof@kernel.org>,
	linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,
	linux-s390@vger.kernel.org, linux-crypto@vger.kernel.org,
	openipmi-developer@lists.sourceforge.net,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	intel-xe@lists.freedesktop.org, linux-hyperv@vger.kernel.org,
	linux-rdma@vger.kernel.org, linux-raid@vger.kernel.org,
	linux-scsi@vger.kernel.org, linux-serial@vger.kernel.org,
	xen-devel@lists.xenproject.org, linux-aio@kvack.org,
	linux-fsdevel@vger.kernel.org, netfs@lists.linux.dev,
	codalist@coda.cs.cmu.edu, linux-mm@kvack.org,
	linux-nfs@vger.kernel.org, ocfs2-devel@lists.linux.dev,
	fsverity@lists.linux.dev, linux-xfs@vger.kernel.org,
	io-uring@vger.kernel.org, bpf@vger.kernel.org,
	kexec@lists.infradead.org, linux-trace-kernel@vger.kernel.org,
	linux-hardening@vger.kernel.org, apparmor@lists.ubuntu.com,
	linux-security-module@vger.kernel.org, keyrings@vger.kernel.org
Subject: Re: [PATCH] treewide: const qualify ctl_tables where applicable
Message-ID: <Z3_vF3I453flXoZv@mail.minyard.net>
Reply-To: corey@minyard.net
References: <20250109-jag-ctl_table_const-v1-1-622aea7230cf@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250109-jag-ctl_table_const-v1-1-622aea7230cf@kernel.org>

On Thu, Jan 09, 2025 at 02:16:39PM +0100, Joel Granados wrote:
> Add the const qualifier to all the ctl_tables in the tree except the
> ones in ./net dir. The "net" sysctl code is special as it modifies the
> arrays before passing it on to the registration function.
> 
...
> diff --git a/drivers/char/ipmi/ipmi_poweroff.c b/drivers/char/ipmi/ipmi_poweroff.c
> index 941d2dcc8c9d..de84f59468a9 100644
> --- a/drivers/char/ipmi/ipmi_poweroff.c
> +++ b/drivers/char/ipmi/ipmi_poweroff.c
> @@ -650,7 +650,7 @@ static struct ipmi_smi_watcher smi_watcher = {
>  #ifdef CONFIG_PROC_FS
>  #include <linux/sysctl.h>
>  
> -static struct ctl_table ipmi_table[] = {
> +static const struct ctl_table ipmi_table[] = {
>  	{ .procname	= "poweroff_powercycle",
>  	  .data		= &poweroff_powercycle,
>  	  .maxlen	= sizeof(poweroff_powercycle),

For the IPMI portion:

Acked-by: Corey Minyard <cminyard@mvista.com>



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:50:54 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:50:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868881.1280391 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVuoA-0003Hd-Ge; Thu, 09 Jan 2025 15:50:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868881.1280391; Thu, 09 Jan 2025 15:50:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVuoA-0003HU-Dc; Thu, 09 Jan 2025 15:50:54 +0000
Received: by outflank-mailman (input) for mailman id 868881;
 Thu, 09 Jan 2025 15:50: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 <SRS0=pS5t=UB=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVuo9-0003BM-JB
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:50:53 +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 80e0e818-cea1-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 16:50:52 +0100 (CET)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-4368a293339so13308045e9.3
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 07:50: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
 5b1f17b1804b1-436e9e6249csm24586165e9.38.2025.01.09.07.50.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 07:50:51 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 80e0e818-cea1-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736437851; x=1737042651; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=/6AbTStBIBSM87HCQWxECtRStNhq5jWk924Q6zyzDWE=;
        b=ZmIxXy39YTLRnpJlkhAqAYUR/w1Zq99aea6Q4rW9qR3l+b4CFqO4x47f+FtYO1cfIM
         Du2aOiP7w2bIA9deVlsvb/VqFCf6uDJ6W9XHIWOUE3ZrgL5jcnYEYfArEmzvVpP7Jixz
         A/BbV4NYT0EU+z6Tpxzm9rJugl/V3K2h6n5OLL1Nwjf2TogMceN9zGgHJPwX6loRA8ik
         ZZtmGrVD8xLJVma1Qob4gfld5a+bVJUHgYQyenvzZGXxWq3wU+hE/ZtvCoVJU1qdYeFB
         f6+Vq6y8GOEOYNuvPZgpMWG87rGULYjhygeEP7WZqYaPV4aR2bTFjQ3Z1Mykl8c53RKw
         b25g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736437851; x=1737042651;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=/6AbTStBIBSM87HCQWxECtRStNhq5jWk924Q6zyzDWE=;
        b=oZWYpGkPWjufv3tu8lFhOjuc+fkcyjAtzDFWg6zK6uhnl8DvrOOYqjsxqGmxkmTgI8
         jltIaoUIV92xRWiVm8cMoucP8JQerUOJoAthCWfPXcNFa5TbI19ztNS1RPqQ+K/J+S0n
         Dck3SwkOwywfIEHYGudRpt9Z9IFyyuemnrhCKh+gM4lP4oKosJChs5CJeyKWmQ+UftVD
         kcoCcDS6RYXBR16ou7zpJhaScwo9pvVv+jHAhHIujWC6YPF/UYYgmNBUcQUrSfWhb+7p
         M1fTsV1x2OdDoliApJBW+YecCwAaMxWIdKq9SI7de/DzT5/a17spcCx2CR4RX+Gl6Ybf
         Ovdg==
X-Forwarded-Encrypted: i=1; AJvYcCUhBZWJFlRr5M/H9WFRt6qndKR7yaQwjVfV5pxgV1DmmnHSOJ4lnANRvw+Xd3RBFgkHDT1rcuAzUqg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwPKoyh7HTSobgxiUsAQ9nL8FYiGKvp4nGbFIk6DWzXqqyPtvD3
	InH4YcYxuy1A3mUi5CpEAS50i6VmF8kO5A/v+kql44wUQMTyCtoz93iur+eh+A==
X-Gm-Gg: ASbGncs0kK4aAhbOgw5PpRI1vDRKhdzyhP5zeOKbVhHDzCRXlAF165aVktDSP7cbwdZ
	gq2kaO/T0rqMqb+jeeNAlRLYbxiUeRR3BunObhXKLnfP3odoZyRc5in/pm9ErtIst/c78POdKGc
	09vH5tsNh53W/THOu2IsmP5ofRs51jZeF4IYxwGkqzZjG17e0VlOrvZKqTATgexETu5V8UMVQq9
	mhMkql039kHxcu90FalAHZ/4RTkHl3CDc0/CJm2UjJBAScriykvLWVFmMJmOTXkTxPcjMrRxDOp
	my38Y/uj+8AKD7J5g2a2yANwO41yTLhdRVRPek9qVg==
X-Google-Smtp-Source: AGHT+IEd2Qcp9nXKYZdraQrUkbzDZJhRjXmjipVtM7bKWkCp5E33NBhLqqnhFzt7UOu5e8mBLEwCCg==
X-Received: by 2002:a05:600c:4ed4:b0:436:1b81:b65c with SMTP id 5b1f17b1804b1-436e26c0a33mr73657725e9.15.1736437851542;
        Thu, 09 Jan 2025 07:50:51 -0800 (PST)
Message-ID: <1d244fe8-96a6-4597-a741-2b4ec15a71fa@suse.com>
Date: Thu, 9 Jan 2025 16:50:49 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 5/7] xen: add new domctl get_changed_domain
To: Juergen Gross <jgross@suse.com>
Cc: "Daniel P. Smith" <dpsmith@apertussolutions.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <20250109105935.23585-1-jgross@suse.com>
 <20250109105935.23585-6-jgross@suse.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250109105935.23585-6-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 09.01.2025 11:59, Juergen Gross wrote:
> Add a new domctl sub-function to get data of a domain having changed
> state (this is needed by Xenstore).
> 
> The returned state just contains the domid, the domain unique id,
> and some flags (existing, shutdown, dying).
> 
> In order to enable Xenstore stubdom being built for multiple Xen
> versions, make this domctl stable.  For stable domctls the
> interface_version is always 0.
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>
> Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com> # non-XSM/Flask




From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:52:02 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:52:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868896.1280400 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVupC-0004Z8-Ot; Thu, 09 Jan 2025 15:51:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868896.1280400; Thu, 09 Jan 2025 15:51:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVupC-0004Z1-M3; Thu, 09 Jan 2025 15:51:58 +0000
Received: by outflank-mailman (input) for mailman id 868896;
 Thu, 09 Jan 2025 15:51:57 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=4O/P=UB=kernel.org=djwong@srs-se1.protection.inumbo.net>)
 id 1tVupB-0004Yt-H4
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:51:57 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a700028d-cea1-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 16:51:56 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id D378CA420AB;
 Thu,  9 Jan 2025 15:50:06 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 07E5AC4CED2;
 Thu,  9 Jan 2025 15:51:55 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a700028d-cea1-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1736437915;
	bh=4PNW5U1RCpwSI6ed5qCmkDfjxSB39XjXAAnaje7o+L4=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=F9BSlQcxUU/kvrDz8ezVoOO+s/YBhBI99DBGbLdRbteRKBcsdBNKhfA6NIrkjDYkC
	 9GtrmQ7VK0dv7qDBCLFFprwhk5flkxmRl+V2FYyKWlDlaQk5dy/y43RuJc1rAObSVE
	 sl7FszvwCJ3ZWmJ3LwoRXHehBmq48TqQ4/nOFcPMPAGWGxlPfP39p5Evt4580Qxykh
	 T6IreW5JxdI40u2aiQRRvDdYRS5jpPoTlnD0T3RTnaN10Mg41YwaqUaSESqRhF+j/w
	 8yWPU7z9RguVCtFoKzz3OeFzncyxzknkL/0P6P7tlQkSO/uCgw6CAfTy6ch0j+etXR
	 6KWhdTwfzx9bw==
Date: Thu, 9 Jan 2025 07:51:54 -0800
From: "Darrick J. Wong" <djwong@kernel.org>
To: Joel Granados <joel.granados@kernel.org>
Cc: Thomas =?iso-8859-1?Q?Wei=DFschuh?= <linux@weissschuh.net>,
	Kees Cook <kees@kernel.org>, Luis Chamberlain <mcgrof@kernel.org>,
	linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,
	linux-s390@vger.kernel.org, linux-crypto@vger.kernel.org,
	openipmi-developer@lists.sourceforge.net,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	intel-xe@lists.freedesktop.org, linux-hyperv@vger.kernel.org,
	linux-rdma@vger.kernel.org, linux-raid@vger.kernel.org,
	linux-scsi@vger.kernel.org, linux-serial@vger.kernel.org,
	xen-devel@lists.xenproject.org, linux-aio@kvack.org,
	linux-fsdevel@vger.kernel.org, netfs@lists.linux.dev,
	codalist@coda.cs.cmu.edu, linux-mm@kvack.org,
	linux-nfs@vger.kernel.org, ocfs2-devel@lists.linux.dev,
	fsverity@lists.linux.dev, linux-xfs@vger.kernel.org,
	io-uring@vger.kernel.org, bpf@vger.kernel.org,
	kexec@lists.infradead.org, linux-trace-kernel@vger.kernel.org,
	linux-hardening@vger.kernel.org, apparmor@lists.ubuntu.com,
	linux-security-module@vger.kernel.org, keyrings@vger.kernel.org
Subject: Re: [PATCH] treewide: const qualify ctl_tables where applicable
Message-ID: <20250109155154.GP1306365@frogsfrogsfrogs>
References: <20250109-jag-ctl_table_const-v1-1-622aea7230cf@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250109-jag-ctl_table_const-v1-1-622aea7230cf@kernel.org>

On Thu, Jan 09, 2025 at 02:16:39PM +0100, Joel Granados wrote:
> Add the const qualifier to all the ctl_tables in the tree except the
> ones in ./net dir. The "net" sysctl code is special as it modifies the
> arrays before passing it on to the registration function.
> 
> Constifying ctl_table structs will prevent the modification of
> proc_handler function pointers as the arrays would reside in .rodata.
> This is made possible after commit 78eb4ea25cd5 ("sysctl: treewide:
> constify the ctl_table argument of proc_handlers") constified all the
> proc_handlers.

Sounds like a good idea,
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> # xfs

--D


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:53:07 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:53:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868902.1280411 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVuqJ-0005uy-2H; Thu, 09 Jan 2025 15:53:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868902.1280411; Thu, 09 Jan 2025 15:53:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVuqI-0005ur-Vm; Thu, 09 Jan 2025 15:53:06 +0000
Received: by outflank-mailman (input) for mailman id 868902;
 Thu, 09 Jan 2025 15:53:06 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=pS5t=UB=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tVuqI-0005ul-42
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:53:06 +0000
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com
 [2a00:1450:4864:20::32e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id cfb1467c-cea1-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 16:53:04 +0100 (CET)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-4363dc916ceso14337645e9.0
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 07:53:04 -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
 ffacd0b85a97d-38a8e38c596sm2172609f8f.51.2025.01.09.07.53.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 07:53:03 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: cfb1467c-cea1-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736437984; x=1737042784; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=t1wBuwyeR3R3NkqT7B/IREcXAKQW7aUL8bc7w4JKv5Y=;
        b=gIfwZFOSV2/2IUhL8s7MLL73w8KGYinwvUHaEnZ1iWgbtJ786PA+jCjQsa8siu8mCN
         pq6GCWYYacdKwkTnyTGbdksw8XCcgJ3N2f0PPfK2DggwCG9ilF3FXC3ffc63uC2Asn4Y
         7opdc1kPVqS0SUy2wkWJR/Pnc8kk60pZzPpZKgwKnJo0QN9yfMsDXpU8h45cAodpnKvq
         h0BgDppUs+sU2qSjchc8KmoQgKWzIH0e2bt+X2deyHuNu+YwziUODU4ljVjKgXS5l0Kg
         vdNtkuFDkBoIx0bplsia5+oA5PoWCnJRbT1hku6PiXVxesVMx4p844RCScp2XgWclNB7
         7M3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736437984; x=1737042784;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=t1wBuwyeR3R3NkqT7B/IREcXAKQW7aUL8bc7w4JKv5Y=;
        b=fU4Euxd7q2TGUd1SRTNVhbMETuerUc4w70VVemjIGGc+ePcj+N8ha7TE5ppMwJD99U
         JgWSNwTR1hiPSLQyAeMUC+K9j7l4AUDGT/l9xoP0SI8mtV3AWLsok0uXxWs+KWda4Itz
         qGp9SQJ/LRtJt76fhWyrtHVYEwc15VNqv6SUYLNME/gou76ANoEyE8aAG6zj+yNYYmyY
         woRslysM2ldpdwokCsehi9J8uwu1k6+995y1LoyY96tOJPiLOaEYijSA7c2LOzMnu2ld
         0b+0wZNXK/J+ATTkSAamBaWQofHGqzEJw3vm0KqoeKYgTX9+Z6CZ/16vauYSXApJrtO8
         lHWA==
X-Forwarded-Encrypted: i=1; AJvYcCVEOvVTEwoS8ZguOr4af7KGPRZ5T7vRJPUI0rrxkL9gRO8Vn8Pm8FkD4HJcX/ZtMWI8b1PjyrJxHeM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwcqaAA18XmN6+x25K1IP8hQyPfGdm6gukXxvCO5U4hwe2brsY0
	4012QblinoUNpvx+ltHzVYK5yWy0p7chwlFHEVHEBbXzwv4b9AtXOJfCt6CeCg==
X-Gm-Gg: ASbGncssiSyGXtzVTPVXBH0EMNfolIKWH9+hkihDGqvMLG6VMdSVdikcXaQoqvbfacY
	HmpbogvN/kuXALUWaGz0I+pLmm4WK2w/52V6g5Kq+Amb/lpUunZ//yyd2NGj2gXG+9KSMB/1gru
	jhqN7VphKQky/2eaAD0l8vFzFRuXNmJpQob6TJ8zdhrBkvMbkt8aWHtRe2pM0jlGvzGfXOad4Vw
	tqkgJb4QWKmlq9JgpB4JIAQD53BH7kxN/IlzRVE8iXN4ql4f/XGPMzeCPZHUXPg0sfRW0e6JjpA
	bTkBpXFQWCprnuntvPmPuDarHIpAPUw56sGLBuGGOQ==
X-Google-Smtp-Source: AGHT+IGWVo9hnAJZzNwnOcsJ0ej5UGM1XlIakU6xJX3QBMHAT0PYzNI1TuiDMuXnBlR+51mundQOUg==
X-Received: by 2002:a05:600c:1d02:b0:434:e69c:d338 with SMTP id 5b1f17b1804b1-436e9d6ff89mr23517775e9.5.1736437983663;
        Thu, 09 Jan 2025 07:53:03 -0800 (PST)
Message-ID: <bdb4a31c-01d1-4f48-82af-f3eb54cd8d69@suse.com>
Date: Thu, 9 Jan 2025 16:53:01 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/2] Update Xen version to 4.20-rc
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20250109153921.43610-1-andrew.cooper3@citrix.com>
 <20250109153921.43610-3-andrew.cooper3@citrix.com>
 <67278014-8208-48f2-92ba-7b843a0d373b@suse.com>
 <c7eeaa80-a4bd-457f-824e-accd23c2f471@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <c7eeaa80-a4bd-457f-824e-accd23c2f471@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 09.01.2025 16:46, Andrew Cooper wrote:
> On 09/01/2025 3:44 pm, Jan Beulich wrote:
>> On 09.01.2025 16:39, Andrew Cooper wrote:
>>> --- a/README
>>> +++ b/README
>>> @@ -1,11 +1,11 @@
>>> -############################################################
>>> -__  __                                _        _     _
>>> -\ \/ /___ _ __        _   _ _ __  ___| |_ __ _| |__ | | ___
>>> - \  // _ \ '_ \ _____| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
>>> - /  \  __/ | | |_____| |_| | | | \__ \ || (_| | |_) | |  __/
>>> -/_/\_\___|_| |_|      \__,_|_| |_|___/\__\__,_|_.__/|_|\___|
>>> -
>>> -############################################################
>>> +#####################################################
>>> +__  __            _  _    ____   ___
>>> +\ \/ /___ _ __   | || |  |___ \ / _ \       _ __ ___
>>> + \  // _ \ '_ \  | || |_   __) | | | |_____| '__/ __|
>>> + /  \  __/ | | | |__   _| / __/| |_| |_____| | | (__
>>> +/_/\_\___|_| |_|    |_|(_)_____|\___/      |_|  \___|
>>> +
>>> +#####################################################
>>>  
>>>  https://www.xen.org/
>>>  
>>> --- a/SUPPORT.md
>>> +++ b/SUPPORT.md
>>> @@ -9,7 +9,7 @@ for the definitions of the support status levels etc.
>>>  
>>>  # Release Support
>>>  
>>> -    Xen-Version: 4.20-unstable
>>> +    Xen-Version: 4.20-rc
>>>      Initial-Release: n/a
>>>      Supported-Until: TBD
>>>      Security-Support-Until: Unreleased - not yet security-supported
>>> --- a/xen/Makefile
>>> +++ b/xen/Makefile
>>> @@ -6,7 +6,7 @@ this-makefile := $(call lastword,$(MAKEFILE_LIST))
>>>  # All other places this is stored (eg. compile.h) should be autogenerated.
>>>  export XEN_VERSION       = 4
>>>  export XEN_SUBVERSION    = 20
>>> -export XEN_EXTRAVERSION ?= -unstable$(XEN_VENDORVERSION)
>>> +export XEN_EXTRAVERSION ?= .0-rc$(XEN_VENDORVERSION)
>> Since we'd been there before I take it the .0 in here (which isn't in the
>> changes to the other two files) is deliberate now? Clearly I continue to
>> think it shouldn't be put there together with -rc.
> 
> Oh, that's because I cribbed this by looking at the recent releases.
> 
> The documentation leaves ~everything to be desired...
> 
> I can drop the .0 here, although I shan't repost just for that.

In case this (both patches) requires any ack:
Acked-by: Jan Beulich <jbeulich@suse.com>

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:53:49 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:53:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868912.1280420 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVuqz-0006di-Al; Thu, 09 Jan 2025 15:53:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868912.1280420; Thu, 09 Jan 2025 15:53:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVuqz-0006db-8B; Thu, 09 Jan 2025 15:53:49 +0000
Received: by outflank-mailman (input) for mailman id 868912;
 Thu, 09 Jan 2025 15:53: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
 <SRS0=iU6M=UB=bounce.vates.tech=bounce-md_30504962.677ff108.v1-93678dbcbe8647bc8544e19a5cbd3011@srs-se1.protection.inumbo.net>)
 id 1tVuqx-0006dV-IO
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:53:47 +0000
Received: from mail178-22.suw51.mandrillapp.com
 (mail178-22.suw51.mandrillapp.com [198.2.178.22])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e850b115-cea1-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 16:53:46 +0100 (CET)
Received: from pmta13.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail178-22.suw51.mandrillapp.com (Mailchimp) with ESMTP id
 4YTTpw5w2qzGlspL3
 for <xen-devel@lists.xenproject.org>; Thu,  9 Jan 2025 15:53:44 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 93678dbcbe8647bc8544e19a5cbd3011; Thu, 09 Jan 2025 15:53:44 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e850b115-cea1-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1736438024; x=1736698524;
	bh=aaXGWiKEjgxDs6iETcyvBhyR1zK3Bd5uz77TWnzIS/4=;
	h=From:Subject:To:Cc:Message-Id:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=W7kmsZe6y21O3Dh+4kPRm3bRBu4KDb4PUJCd+HUrbYBz+T8XAKwsdQbhaQzllMSQX
	 19WJBSJh3dL5qqFbjDX11Lsa92xFt3PDzJ+seXQIF1mvI3mr3GZq5TbZWIivah67Wi
	 nHyhXPqfbdOoud4FS8aMENai3XN6d8FAh7ULdwh2T5NT8PuP+lWwNh1HrfCzLaG5Ae
	 ZeppZIb6apvjUuo2CXnc1DNkkvDEfmOhkwpfEwBZ2CWMooOIGsQl4Bn4y+KroaOWGE
	 IxRdHl0aevXBaaScibI+sIsxVXxyu4ErcrZr+3N1/f3ggjFj4JXh/0bPtWjzwdvXxn
	 iP3vJMMiTdHrA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1736438024; x=1736698524; i=anthony.perard@vates.tech;
	bh=aaXGWiKEjgxDs6iETcyvBhyR1zK3Bd5uz77TWnzIS/4=;
	h=From:Subject:To:Cc:Message-Id:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=Sib1P7WK9hfHPhKr92NRlCbmRWIVsce96EZJQsZYxJWcba0zBqTdMg9sZ1MO2kwdq
	 HaYE86FVTCcAnEI36u2Y/QcEa0TzKFWFPFPyT7Gxlpvv/SH7/zT71eqIsoVqH4sWiU
	 PKpiu3C12nR0zhW6j7ApSWN+lcrBPsRKOZfm+ZrZC2cptfLjCq7e9+MxgffIj/XbvX
	 Rs1idyijlgdG5Bby29yNrXZYgtOrlyiYE6ZV0BS+5s89uU6XBiKbQLo0C3UV0Ahz6G
	 g+fiwqzJEWGNEZH7/EzwzfW+EChUn+jTcL3Jnv4An4r7jhWtZFXO0Wm6xKB+CQRp8i
	 FOoXZ4vPvIlpQ==
From: "Anthony PERARD" <anthony.perard@vates.tech>
Subject: =?utf-8?Q?Re:=20[PATCH=201/2]=20Config.mk:=20Pin=20QEMU=5FUPSTREAM=5FREVISION?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1736438023339
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, "Michal Orzel" <michal.orzel@amd.com>, "Jan Beulich" <jbeulich@suse.com>, "Julien Grall" <julien@xen.org>, "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>, "Stefano Stabellini" <sstabellini@kernel.org>, "Oleksii Kurochko" <oleksii.kurochko@gmail.com>
Message-Id: <Z3_xBjLGs5OJ5neR@l14>
References: <20250109153921.43610-1-andrew.cooper3@citrix.com> <20250109153921.43610-2-andrew.cooper3@citrix.com>
In-Reply-To: <20250109153921.43610-2-andrew.cooper3@citrix.com>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.93678dbcbe8647bc8544e19a5cbd3011?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250109:md
Date: Thu, 09 Jan 2025 15:53:44 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On Thu, Jan 09, 2025 at 03:39:20PM +0000, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Acked-by: Anthony PERARD <anthony.perard@vates.tech>

Thanks,

-- 

Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:55:07 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:55:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868920.1280431 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVusE-0007S8-Ko; Thu, 09 Jan 2025 15:55:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868920.1280431; Thu, 09 Jan 2025 15:55:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVusE-0007S1-I9; Thu, 09 Jan 2025 15:55:06 +0000
Received: by outflank-mailman (input) for mailman id 868920;
 Thu, 09 Jan 2025 15:55: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
 <SRS0=29Hz=UB=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tVusD-0007Rt-8f
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:55:05 +0000
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com
 [2a00:1450:4864:20::22c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 16af444a-cea2-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 16:55:03 +0100 (CET)
Received: by mail-lj1-x22c.google.com with SMTP id
 38308e7fff4ca-300479ca5c6so8808841fa.3
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 07:55:03 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-305ff1ebb63sm2324631fa.96.2025.01.09.07.55.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 07:55:01 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 16af444a-cea2-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736438103; x=1737042903; darn=lists.xenproject.org;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=L8yeQF4QbrMUy3HK3QxSViXwORXCyeEFAzj9Y5YjtRM=;
        b=d2HmGKQBKuV5csUTOe+X3uKXDbD+eLWS2a9DmaXOCQZLCNbffLkSdK/fYLTBKHHvWo
         EIZs/0G3OkRinRcapDvoa1tOPz9o73jjbpDIk5odrWsvFiKTcn6MTBmQ8v8k1dJ2goYb
         oDNYpE4i7FwN+yWVso7sbARqEwenJz4v7cgKT+QKqmzFLHSmmPCU0KRUJdxQuH/r0MAE
         lfIUKc4yJDUpxq3gCRo/s1p6p0Vz4S09aU3Pl4x9kTrRxJtlyQY5sRtXw0EiZqdY6smh
         7IaHTGdHD6Mglynf4AtIiiTnez/nzcfv7T3KsSYpVG3bVxuzH+P6a75cXUyWuzuo6gKs
         Nuvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736438103; x=1737042903;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=L8yeQF4QbrMUy3HK3QxSViXwORXCyeEFAzj9Y5YjtRM=;
        b=b9TDCByM/OeaEsrfzsjIrXMVgwnIJC1alWrnE3VudMr89ZwilVGGPAYGLYTFC3GSJU
         VzW7fhmt6Cj7/CgCwWPgWXK0pDm5IpCFJwmTdEyFZDZi9DHs7kmCN/mlJgKtSF1qh2DZ
         GHL+vlyenPANeF2xLKFqKD/ADKss8mw3jXW8EGgIoD8wRwJ+6aUUFSvkQBHyqaZ4ysug
         dpl+f1vMkUkQJLyDMSmWVbzWjxU3P/EDkFbUGwmze2rw+ObOnNYYy4Q3YhSmJTl7r+6Q
         f7F+nM/LGD4iirW9glp6zO+R4TFh2KI8EsyCiA5Fm6gPOD7m8Fr+F/sk+eo8za5+ehJf
         YbTA==
X-Forwarded-Encrypted: i=1; AJvYcCUlQXXK34DR2mmtw4IZkMizbzpXc4yeu3CTJ1R/bld54p56kJ/SZnXek9tR70xzOPH7axWCkCJQPak=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyUOyJyGPLuLJJZ1KIf8p8zhRwdD4E13CZyM/Q/W6IHm5FMjAAA
	0RmZLcoAZqcdmM8k0yxmoiFjm/V+Q2KCboS36Bym+8Yf4kyFpcZF
X-Gm-Gg: ASbGnctjpN9T7RbQphK8McR0fKkIr7ebUK5tP6Z2+kHo9J4EKS0zDbkA4Z0HdZA5nYN
	FUHJrcqb02j2Inr9eqg3n05q4svHhtcoELX+/aIGo5UQIpL5QGVV3XYPwDwm2GbjhU/0anONWOE
	z6yYi2zV2DHsULzG4KUV+tZyvAWvTAu8UDFtVBgCTYh/sM4PaXmQ6DZOuAv6FGswVbHqST5kuiI
	6PkD6pfAv2jMefnZYLS7LeSrjNX0VVQBr/x3MJwTgATM/B54NIp0sV5nrZ40XtFNHtesw==
X-Google-Smtp-Source: AGHT+IEKfHUWrJDD8bEabRwbJ32SYxsuXkv3gOIqFuCJZBfs0ItVTOoqG1M0qsskIdkgyHqKIvuOKQ==
X-Received: by 2002:a2e:a98f:0:b0:2ff:d49f:dd4b with SMTP id 38308e7fff4ca-305f458a81emr18604901fa.15.1736438102263;
        Thu, 09 Jan 2025 07:55:02 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------9WCPFP1tX0sdya0BKyGT03DO"
Message-ID: <a353258c-ac39-4ac0-b6ca-975b77d0e847@gmail.com>
Date: Thu, 9 Jan 2025 16:55:01 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/2] Update Xen version to 4.20-rc
To: Jan Beulich <jbeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20250109153921.43610-1-andrew.cooper3@citrix.com>
 <20250109153921.43610-3-andrew.cooper3@citrix.com>
 <67278014-8208-48f2-92ba-7b843a0d373b@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <67278014-8208-48f2-92ba-7b843a0d373b@suse.com>

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


On 1/9/25 4:44 PM, Jan Beulich wrote:
> On 09.01.2025 16:39, Andrew Cooper wrote:
>> --- a/README
>> +++ b/README
>> @@ -1,11 +1,11 @@
>> -############################################################
>> -__  __                                _        _     _
>> -\ \/ /___ _ __        _   _ _ __  ___| |_ __ _| |__ | | ___
>> - \  // _ \ '_ \ _____| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
>> - /  \  __/ | | |_____| |_| | | | \__ \ || (_| | |_) | |  __/
>> -/_/\_\___|_| |_|      \__,_|_| |_|___/\__\__,_|_.__/|_|\___|
>> -
>> -############################################################
>> +#####################################################
>> +__  __            _  _    ____   ___
>> +\ \/ /___ _ __   | || |  |___ \ / _ \       _ __ ___
>> + \  // _ \ '_ \  | || |_   __) | | | |_____| '__/ __|
>> + /  \  __/ | | | |__   _| / __/| |_| |_____| | | (__
>> +/_/\_\___|_| |_|    |_|(_)_____|\___/      |_|  \___|
>> +
>> +#####################################################
>>   
>>   https://www.xen.org/
>>   
>> --- a/SUPPORT.md
>> +++ b/SUPPORT.md
>> @@ -9,7 +9,7 @@ for the definitions of the support status levels etc.
>>   
>>   # Release Support
>>   
>> -    Xen-Version: 4.20-unstable
>> +    Xen-Version: 4.20-rc
>>       Initial-Release: n/a
>>       Supported-Until: TBD
>>       Security-Support-Until: Unreleased - not yet security-supported
>> --- a/xen/Makefile
>> +++ b/xen/Makefile
>> @@ -6,7 +6,7 @@ this-makefile := $(call lastword,$(MAKEFILE_LIST))
>>   # All other places this is stored (eg. compile.h) should be autogenerated.
>>   export XEN_VERSION       = 4
>>   export XEN_SUBVERSION    = 20
>> -export XEN_EXTRAVERSION ?= -unstable$(XEN_VENDORVERSION)
>> +export XEN_EXTRAVERSION ?= .0-rc$(XEN_VENDORVERSION)
> Since we'd been there before I take it the .0 in here (which isn't in the
> changes to the other two files) is deliberate now? Clearly I continue to
> think it shouldn't be put there together with -rc.

But in docs/process/{release-technician-checklist, 
xen-release-management}.pandoc .0 is used.

So probably then we have to update docs correspondingly to avoid confusion.

~ Oleksii

>
> Jan
--------------9WCPFP1tX0sdya0BKyGT03DO
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 1/9/25 4:44 PM, Jan Beulich wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:67278014-8208-48f2-92ba-7b843a0d373b@suse.com">
      <pre wrap="" class="moz-quote-pre">On 09.01.2025 16:39, Andrew Cooper wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">--- a/README
+++ b/README
@@ -1,11 +1,11 @@
-############################################################
-__  __                                _        _     _
-\ \/ /___ _ __        _   _ _ __  ___| |_ __ _| |__ | | ___
- \  // _ \ '_ \ _____| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
- /  \  __/ | | |_____| |_| | | | \__ \ || (_| | |_) | |  __/
-/_/\_\___|_| |_|      \__,_|_| |_|___/\__\__,_|_.__/|_|\___|
-
-############################################################
+#####################################################
+__  __            _  _    ____   ___
+\ \/ /___ _ __   | || |  |___ \ / _ \       _ __ ___
+ \  // _ \ '_ \  | || |_   __) | | | |_____| '__/ __|
+ /  \  __/ | | | |__   _| / __/| |_| |_____| | | (__
+/_/\_\___|_| |_|    |_|(_)_____|\___/      |_|  \___|
+
+#####################################################
 
 <a class="moz-txt-link-freetext" href="https://www.xen.org/">https://www.xen.org/</a>
 
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -9,7 +9,7 @@ for the definitions of the support status levels etc.
 
 # Release Support
 
-    Xen-Version: 4.20-unstable
+    Xen-Version: 4.20-rc
     Initial-Release: n/a
     Supported-Until: TBD
     Security-Support-Until: Unreleased - not yet security-supported
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -6,7 +6,7 @@ this-makefile := $(call lastword,$(MAKEFILE_LIST))
 # All other places this is stored (eg. compile.h) should be autogenerated.
 export XEN_VERSION       = 4
 export XEN_SUBVERSION    = 20
-export XEN_EXTRAVERSION ?= -unstable$(XEN_VENDORVERSION)
+export XEN_EXTRAVERSION ?= .0-rc$(XEN_VENDORVERSION)
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
Since we'd been there before I take it the .0 in here (which isn't in the
changes to the other two files) is deliberate now? Clearly I continue to
think it shouldn't be put there together with -rc.</pre>
    </blockquote>
    <pre><font face="monospace">But in docs/process/{release-technician-checklist, xen-release-management}.pandoc .0 is used.</font></pre>
    <pre><font face="monospace">So probably then we have to update docs correspondingly to avoid confusion.</font></pre>
    <pre><font face="monospace">~ Oleksii</font>
</pre>
    <blockquote type="cite"
      cite="mid:67278014-8208-48f2-92ba-7b843a0d373b@suse.com">
      <pre wrap="" class="moz-quote-pre">

Jan
</pre>
    </blockquote>
  </body>
</html>

--------------9WCPFP1tX0sdya0BKyGT03DO--


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 15:58:46 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 15:58:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868934.1280440 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVuvh-0000MT-7Z; Thu, 09 Jan 2025 15:58:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868934.1280440; Thu, 09 Jan 2025 15:58:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVuvh-0000MM-4z; Thu, 09 Jan 2025 15:58:41 +0000
Received: by outflank-mailman (input) for mailman id 868934;
 Thu, 09 Jan 2025 15:58:40 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=29Hz=UB=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tVuvg-0000Kt-I7
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 15:58:40 +0000
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com
 [2a00:1450:4864:20::12d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9702250d-cea2-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 16:58:38 +0100 (CET)
Received: by mail-lf1-x12d.google.com with SMTP id
 2adb3069b0e04-53df80eeeedso1013686e87.2
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 07:58:38 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5428cc9b47esm202657e87.53.2025.01.09.07.58.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 07:58:37 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9702250d-cea2-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736438318; x=1737043118; darn=lists.xenproject.org;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=iAHKsFdVWXQhdOjkYrMh7AQ++xARIkLAhZu2Fb5zcAc=;
        b=WH3h4y/wRikvBK+n3Sscc1vBAYQ2h086ZeJsvYysAvHtPej/dacBJIg/+XVEd97YNs
         pzBm/U7cGdtbdQG3gj/LJtdgSE9qufXWj1gpfH1fcqQHYy+dFLM493omIZU5D7ihO2mE
         6C6pWbvZO4IqJs3a/Y+9n0Lwod5xaXkW5ALgATBnlNCM++A1OT6ML2s2ZFJzf/NNeYc1
         nL0ATG5nONbDhoc9+VHgjd/XfiPF9cI6TGpzjDg9bo3YCbs2hG3ak2jSkYypUn3hLkrw
         v1McOGnEnhldTq6Vn/MwNOIN4TIAXpflMho41JUZ4eG/4zR3ML9FKz3DEdSLJ6a05j9w
         fqYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736438318; x=1737043118;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=iAHKsFdVWXQhdOjkYrMh7AQ++xARIkLAhZu2Fb5zcAc=;
        b=xVaLUptnmmDQZEnZyPQV7jDY7acLQS4V9LJqCDsn2gFw0KH+i/rhDvu1Jqwl7AI9QY
         9dP6ALkufTo6RPPVP8GNPbOpNqeHwfYbpGAP1bGLkLeDg6a7yzEmQkLdNe9T2RWJSlrW
         tl3wf0bLgbeXfKbeFmAbdUdffT0ili0wY/C/TMIMV3RQBIEkhZG9Q55m4GxFn1T6hGWr
         bx+VvxJMyXkLR2OShvZRlUemySQA4pHPjUz2xt5XNx7hqC6oEhfE0YKERKlEh83gRgW3
         458VRqTHx4fze4Jj9DFLrhuKIY+Y537nqAt/Ig+NFt3ZJACP+wWPMPZ4+7gzxlGysAnC
         1mDg==
X-Forwarded-Encrypted: i=1; AJvYcCV7SAuI4PTRJz+Ywn7jwkFHSqavzLEi4u/+Dc5kyy2xezSM2gasfxio3dYXgWez/NN+kqcCYtOW2EY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxeX4t+WMl1/0bpX3OqnyD9K65Y2Ln0b+NjQZEm+X9qWJFD4MAb
	OaATi0F3cKtKukiBwK36YM0PleHQI+WYpWckeOCCDINbZJ5AOqbC
X-Gm-Gg: ASbGncvN+8cQBK+hqMtDCe+nVnCpm2PJiC/yXQZi4EZMR3oO9V6/+Y/mtzpQjQiAmgH
	7qIv5DpCyf75OcmyIohQUzdZGiWYwJWhUryf7iT3ZoW/CDYCVc/NtWJt2ERiUW4xehCx6NhAlpm
	1Bk57XOZw80bUJl8rDeh12NSMbbmtvGPLTLUJU3iok0V/0AsgFfWgFOJUsnscnO6B+AzUYQiraf
	vCETlxNfLkmEoQ7lCsW+BPTjTOvEHm/k82929XLyStph8Nj7HKIUTuTaBomdmIhFyV2Mg==
X-Google-Smtp-Source: AGHT+IFy3uMoCME4UAgRrABbqMHj6lLhtvWZg6/FNarmytPfLSq5sn6tBYc4qkzkmm79V7DiTJ3m6g==
X-Received: by 2002:a05:6512:3d93:b0:542:29a9:4098 with SMTP id 2adb3069b0e04-542844f4060mr2017795e87.5.1736438317652;
        Thu, 09 Jan 2025 07:58:37 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------0d9DW01CeQPbU0he1pDa8Gay"
Message-ID: <c8146158-db57-4ee8-a767-b1266e87baa9@gmail.com>
Date: Thu, 9 Jan 2025 16:58:36 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20 0/2] Prep for 4.20-rc1
To: Andrew Cooper <andrew.cooper3@citrix.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Stefano Stabellini <sstabellini@kernel.org>
References: <20250109153921.43610-1-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <20250109153921.43610-1-andrew.cooper3@citrix.com>

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

Hi Andrew,

LGTM: Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>.

( in case if my Ack is needed )

Thanks.

~ Oleksii


On 1/9/25 4:39 PM, Andrew Cooper wrote:
> RC1 is scheduled for tomorrow (Jan 10th).
>
> Andrew Cooper (2):
>    Config.mk: Pin QEMU_UPSTREAM_REVISION
>    Update Xen version to 4.20-rc
>
>   Config.mk    |  2 +-
>   README       | 16 ++++++++--------
>   SUPPORT.md   |  2 +-
>   xen/Makefile |  2 +-
>   4 files changed, 11 insertions(+), 11 deletions(-)
>
>
> base-commit: 40f35d07aa14bde44d7baafad171f7c92b053017
--------------0d9DW01CeQPbU0he1pDa8Gay
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <pre><font face="monospace">Hi Andrew,</font></pre>
    <pre><font face="monospace">
</font></pre>
    <pre><font face="monospace">LGTM: Release-Acked-by: Oleksii Kurochko <a class="moz-txt-link-rfc2396E" href="mailto:oleksii.kurochko@gmail.com">&lt;oleksii.kurochko@gmail.com&gt;</a>.</font></pre>
    <pre><font face="monospace">( in case if my Ack is needed )</font></pre>
    <pre><font face="monospace">
</font></pre>
    <pre><font face="monospace">Thanks.</font></pre>
    <pre><font face="monospace">
</font></pre>
    <pre><font face="monospace">~ Oleksii</font>
</pre>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 1/9/25 4:39 PM, Andrew Cooper wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:20250109153921.43610-1-andrew.cooper3@citrix.com">
      <pre wrap="" class="moz-quote-pre">RC1 is scheduled for tomorrow (Jan 10th).

Andrew Cooper (2):
  Config.mk: Pin QEMU_UPSTREAM_REVISION
  Update Xen version to 4.20-rc

 Config.mk    |  2 +-
 README       | 16 ++++++++--------
 SUPPORT.md   |  2 +-
 xen/Makefile |  2 +-
 4 files changed, 11 insertions(+), 11 deletions(-)


base-commit: 40f35d07aa14bde44d7baafad171f7c92b053017
</pre>
    </blockquote>
  </body>
</html>

--------------0d9DW01CeQPbU0he1pDa8Gay--


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 16:03:06 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 16:03:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868943.1280450 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVuzw-0003CC-OI; Thu, 09 Jan 2025 16:03:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868943.1280450; Thu, 09 Jan 2025 16:03:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVuzw-0003C5-LW; Thu, 09 Jan 2025 16:03:04 +0000
Received: by outflank-mailman (input) for mailman id 868943;
 Thu, 09 Jan 2025 16:03:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=rr8/=UB=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tVuzw-0003Ab-1K
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 16:03:04 +0000
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [2a00:1450:4864:20::534])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 34041786-cea3-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 17:03:02 +0100 (CET)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-5d647d5df90so1561417a12.2
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 08:03:02 -0800 (PST)
Received: from [192.168.86.29] ([83.105.36.37])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d9903c3328sm741593a12.50.2025.01.09.08.02.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 08:02:59 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 34041786-cea3-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736438581; x=1737043381; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=6HkPOKDwJTT71PqxipilfqxoNZ07pAan+OOcRHn9yvM=;
        b=pYvnO9SXtb91Cl3F/kw1l4ANQSwQKdT+PPjGG6F3R/CDiTOZ24BnwhEQ70LTq+Z1PN
         XJMW0IlQfyETlg65ULz/sqqt7rYAC3PD8xIAVAQ0vl9KkBDD5lua803HxwWz7Ikdgrm9
         LKlHgNoux9N2QbHGqPr4yvrVdzuAbeLvv7rBo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736438581; x=1737043381;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=6HkPOKDwJTT71PqxipilfqxoNZ07pAan+OOcRHn9yvM=;
        b=Bg9M6jPF1hP9ilCVATmTxfzv85MfwThwNllbZC3QbWp3FXt2Apvuy67qA377v1SWgp
         RupRxASlGo+3sqz6EhtJO8ejihNllDYIOxqKQntA2xVl8dI26ZLIrj/dhH6z17Qdqoov
         Buwv/poDg8dzup1e2SSI3isJK6AiavgvKvu1A/NyBRsvCElBhwey1BrCpfin1VTWhiav
         K61TDgEhCHyZGzpI8fY/5AIBtSuIY4v/1rDHwOOLCvAQe5BqA3xhDn1BojaP4yMu8rlj
         dqN31ByN/YONdD4ZQ8zkvejDgiknCgifgIvXshkFlcqEM66A0Lk2XmXz1grAjOsglf0w
         wp7Q==
X-Forwarded-Encrypted: i=1; AJvYcCV+1Q5N8I/4gMCqzN7PmgufkkhMLFrtJhZp+tGZcKmBwtLo4b4OUDe323JGxnXyoGvQrD1K9qWalkM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzIqNtse+feBN/VZ/wB6RySmyvVgyNu2MJdw7I0PD6AhYP2ozzj
	UFcKOPINUW0ob5nJyWqPxho5z7kAZOCyHHdp6cc+Uto4x7VVNGNKy3KEHe/OYp/vMED0d8k6CDA
	NMvRebw==
X-Gm-Gg: ASbGncvIMRNCzkLMEGUcPQQ3AuztEg+PUABA2ZK9DZejHqiAv5guy2/FS+MsY+3GcoF
	CKXlLmofv+hHtP+vy574Wn5DnwUx6HKq6LRvNLo3FyXYvDhKcsSwgkeWJdhJ2nswpX2z9QK9B7o
	JM5xJ0lDcFwooQvHzxeZsbGkg2pyggQIwLnXL1E42NMZIF2CQ9N4ncBdLcz5y2H6fyRzs34Fr3B
	mfmnNs8+jXEGvwy9g8axLlzpZYh/8UhLNvcnQwqI9AlMkPEHVF4cHka/EhfUa4rX/A=
X-Google-Smtp-Source: AGHT+IHuWeIfgs+xUG5AzvntOZBQt8ve/4Fc4X6KAGzzlrcLLB/Pl3k14n33OOD1Ml5EiepJoCpV5g==
X-Received: by 2002:a05:6402:5254:b0:5d3:fc60:a504 with SMTP id 4fb4d7f45d1cf-5d972e17891mr6287880a12.20.1736438580073;
        Thu, 09 Jan 2025 08:03:00 -0800 (PST)
Message-ID: <689e4152-b48b-4808-a407-6c33e6e071e0@citrix.com>
Date: Thu, 9 Jan 2025 16:02:58 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/boot: adjust text gap/diff to work with 64-bytes
 alignment too
To: Frediano Ziglio <frediano.ziglio@cloud.com>
Cc: Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, xen-devel@lists.xenproject.org
References: <20250109131515.1757764-1-marmarek@invisiblethingslab.com>
 <d7421558-c2d6-485b-96bf-927992c5c066@suse.com>
 <47378338-ac05-4041-a055-56045e5ba131@citrix.com>
 <CACHz=ZjR6dSy_NsrXkhf_VfZpGYE4et6VkQvU_cO9DdAnXBzxQ@mail.gmail.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <CACHz=ZjR6dSy_NsrXkhf_VfZpGYE4et6VkQvU_cO9DdAnXBzxQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 09/01/2025 3:30 pm, Frediano Ziglio wrote:
> On Thu, Jan 9, 2025 at 1:44 PM Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 09/01/2025 1:23 pm, Jan Beulich wrote:
>>> On 09.01.2025 14:15, Marek Marczykowski-Górecki wrote:
>>>> Xen compiled with -mtune=generic has .text alignment set to 64-bytes.
>>>> Having text_diff non-64-bytes-aligned breaks stuff:
>>>>
>>>>     Traceback (most recent call last):
>>>>       File "/builddir/build/BUILD/xen-4.20.0-build/xen-4.20.0-rc0/xen/./tools/combine_two_binaries.py", line 96, in <module>
>>>>         raise Exception('File sizes do not match')
>>>>     Exception: File sizes do not match: 70160 != 4080 + 66048
>>>>
>>>> Adjust the numbers as suggested by Frediano to work with 64-bytes and
>>>> even 128-bytes alignment.
>>> And then breaking at 256? As indicated on Matrix, imo we should be able to
>>> cope with anything up to at least PAGE_SIZE. Or we should reduce .text
>>> alignment before linking.
>> Do you have a concrete proposal on how to do this?
>>
>> Because if not, we've had 2 downstreams hit by this build failure, and
>> we probably ought to take this patch as a stopgap fix, and see about
>> doing the better fix for 4.20.
>>
> I agree with this, merge this and then leave the improvements for follow up(s).
>
> Yesterday I checked the output object file (built-in-32.o) to find
> that the output alignment is 1 byte, which is obviously wrong!

No so.  It's perfectly easy to end up with 1 byte alignment on .text,
commonly with -Os.

e.g. In my build, reloc-trampoline.32.o has:

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .group        00000008  00000000  00000000  00000034  2**2
                  CONTENTS, READONLY, GROUP, LINK_ONCE_DISCARD
  1 .text         00000076  00000000  00000000  0000003c  2**0
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  2 .data         00000000  00000000  00000000  000000b2  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  3 .bss          00000000  00000000  00000000  000000b2  2**0
                  ALLOC
  4 .text.__x86.get_pc_thunk.bx 00000004  00000000  00000000  000000b2  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  5 .comment      00000020  00000000  00000000  000000b6  2**0
                  CONTENTS, READONLY
  6 .note.GNU-stack 00000000  00000000  00000000  000000d6  2**0
                  CONTENTS, READONLY

and this is entirely reasonable IMO.

That said, the fact that built-in-32.S does not have at least one .align
directive probably is an issue.

x86 will cope, and there's nothing interesting in this code that's going
to choke on being misaligned.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 16:07:04 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 16:07:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868954.1280460 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVv3k-0004yM-7y; Thu, 09 Jan 2025 16:07:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868954.1280460; Thu, 09 Jan 2025 16:07:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVv3k-0004yF-4y; Thu, 09 Jan 2025 16:07:00 +0000
Received: by outflank-mailman (input) for mailman id 868954;
 Thu, 09 Jan 2025 16:06:59 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=wq9x=UB=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tVv3j-0004y9-4q
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 16:06:59 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c0cf40cf-cea3-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 17:06:58 +0100 (CET)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-aaecf50578eso216851166b.2
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 08:06:58 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c90d9a7dsm85367866b.50.2025.01.09.08.06.55
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 09 Jan 2025 08:06:55 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c0cf40cf-cea3-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736438818; x=1737043618; 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=2ZxKJHt4USamZY7CSfghkQfPog5+4zXIN2+IyM4b7Rk=;
        b=Kb3Mo6QrnPSZpsAToM5R5yovqwgBP+9/sbKMbxNE1M85KrZ84WOhLkjf3ZRu4hBOru
         Iut8qVdKVC3QsJTw0jaddEF7Xbf1tsuKf2SvRmvwLixmXIM086bBprG69wsd1ezGR/Ki
         /OlML+B70CIpFuRVogSGLuQEY2+l9MURS3vPs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736438818; x=1737043618;
        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=2ZxKJHt4USamZY7CSfghkQfPog5+4zXIN2+IyM4b7Rk=;
        b=JF/fi/VHpGe/oFj75yKf26/mevv9Y19eVtLZaxGB3JqCwIIvHOh8BubMO9HH0fVD/c
         i9UsIvW4grsiPRlRU6Sz7LxsDu1Lg7VeNqW/vHE4Amo+RT8nIwt6C3uhk71CsF17a/B3
         XIKmbuTjMGXkkt5gb5H4VL9OUNIgrXp0HlM/md2BUGqpOXib78IIwJdwh1+07GcTqx0J
         sP0sKhqQeRnnA211aWXuxZm5Y8dIA1/Pnmal91QfiUl4+KbWqEXmrJzMpvP4BFUTik3A
         r3lC3ZNsmQv3Rzc/Ik9xKr1W3f1QqDWfBKusMsB/+T3Fz5SOoY9yliKpkjikk2Abnrlo
         Xqqg==
X-Forwarded-Encrypted: i=1; AJvYcCVYdF+bPuw+IpU3SqR7FVP1WkhOQWffa3XIGaDPKSPhh5l+fjDbpxaYcg8fn1i5PBJ8lbRwFUMKBCs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyHZNvaLe+asRIy+dJuHYIsGZldudcKAxySW463CKjCDkHPmZY+
	kU3Qshy4AqFA+FfcgGE2UUtQNW8nphhT6bKoOMO5ddxo8woVWNwFTryOY23O1qI=
X-Gm-Gg: ASbGnctGdO4AIrPopFnw4SkH0flEcHi4trnaTy2SC1/jGkzy+mj0SQoG3AYCBPeS7gG
	616xjTGi9goKtyVcJrDfEcIIXIy0wKv3JwV5Qe8vn65O/WZKpC9mW2k7t4xVej+n4nHuTNpZtyH
	jSP2wdUfS6l37SbQWvA6Se7Hq4nzBZk1cfkAZnN8Rn6vrMfDC932T7dhO6ffKVMLoytzoT5fOgC
	4gll++VBtR7JUL2ldtaI9P/sMDD4QWc6/hxBdVpRs0b7KlDn8qDe4Ptjx7QwA==
X-Google-Smtp-Source: AGHT+IHQCbfJqFT4KaXgnMxTnLcFPSKLuLtytVYJU6DTW8em42L3L0fV3PFS9oWX2MaUMz24eWnApg==
X-Received: by 2002:a17:907:2d94:b0:aa6:7de9:2637 with SMTP id a640c23a62f3a-ab2ab6bfe70mr614603966b.46.1736438816006;
        Thu, 09 Jan 2025 08:06:56 -0800 (PST)
Date: Thu, 9 Jan 2025 17:06:54 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Anthony PERARD <anthony@xenproject.org>
Cc: qemu-devel@nongnu.org, Stefano Stabellini <sstabellini@kernel.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	=?utf-8?Q?Marc-Andr=C3=A9?= Lureau <marcandre.lureau@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH 1/2] xen/console: fix error handling in
 xen_console_device_create()
Message-ID: <Z3_0HpmfpSM3Xw5Q@macbook.local>
References: <20250107093140.86180-1-roger.pau@citrix.com>
 <20250107093140.86180-2-roger.pau@citrix.com>
 <Z3-hWRLyMldV4ZZD@l14>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <Z3-hWRLyMldV4ZZD@l14>

On Thu, Jan 09, 2025 at 11:13:45AM +0100, Anthony PERARD wrote:
> On Tue, Jan 07, 2025 at 10:31:39AM +0100, Roger Pau Monne wrote:
> > The usage of error_prepend() in some of the error contexts of
> > xen_console_device_create() is incorrect, as `errp` hasn't been initialized.
> > This leads to the following segmentation fault on error paths resulting from
> > xenstore reads:
> > 
> > Program terminated with signal SIGSEGV, Segmentation fault.
> > Address not mapped to object.
> >     fmt=0x15c4dfeade42 "failed to read console device type: ", ap=0x15cd0165ab50)
> >     at ../qemu-xen-dir-remote/util/error.c:142
> > 142         g_string_append(newmsg, (*errp)->msg);
> > [...]
> > (gdb) bt
> >     (errp=0x15cd0165ae10, fmt=0x15c4dfeade42 "failed to read console device type: ", ap=0x15cd0165ab50) at ../qemu-xen-dir-remote/util/error.c:142
> >     (errp=0x15cd0165ae10, fmt=0x15c4dfeade42 "failed to read console device type: ")
> >     at ../qemu-xen-dir-remote/util/error.c:152
> >     (backend=0x43944de00660, opts=0x43944c929000, errp=0x15cd0165ae10)
> >     at ../qemu-xen-dir-remote/hw/char/xen_console.c:555
> > 
> > Replace usages of error_prepend() with error_setg() where appropriate.
> > 
> > Fixes: 9b7737469080 ('hw/xen: update Xen console to XenDevice model')
> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> > ---
> >  hw/char/xen_console.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
> > index ef0c2912efa1..af706c7ef440 100644
> > --- a/hw/char/xen_console.c
> > +++ b/hw/char/xen_console.c
> > @@ -551,7 +551,7 @@ static void xen_console_device_create(XenBackendInstance *backend,
> >      }
> >  
> >      if (xs_node_scanf(xsh, XBT_NULL, fe, "type", errp, "%ms", &type) != 1) {
> > -        error_prepend(errp, "failed to read console device type: ");
> > +        error_setg(errp, "failed to read console device type: ");
> 
> According to error_setg() doc, *errp must be NULL but xs_node_scanf may
> set it. Looking at the implementation, error_setg() seems to simply
> discard this new error message if *errp is already set.
> 
> Currently, when there's an I/O error, we get something like:
>     failed to read console device type: failed to read from /xenstore/path: doesn't exist
> and when the format scan failed:
>     SEGV
> 
> With this patch, when there's an I/O error, I think we get something
> like:
>     failed to read from /xenstore/path: doesn't exist
> and when the format scan failed:
>     failed to read console device type: 
> 
> 
> So I think we'll want to distiguish between IO error from
> xs_node_scanf() and format error, first one returns EOF (like vsscanf)
> and second one returns a value >= 0 but we expect exactly 1.

The call to xs_node_scanf() will go away in the next patch replaced by
qemu_xen_xs_read(), at which point errp will never be initialized.

I can change the order of the patches if that makes it easier.

> 
> >          goto fail;
> >      }
> >  
> > @@ -582,7 +582,7 @@ static void xen_console_device_create(XenBackendInstance *backend,
> >      } else if (number) {
> >          cd = serial_hd(number);
> >          if (!cd) {
> > -            error_prepend(errp, "console: No serial device #%ld found: ",
> > +            error_setg(errp, "console: No serial device #%ld found: ",
> >                            number);
> 
> This change looks correct, ableit we could remove ":  " from the end of
> the string since they shouldn't be anything after it.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 16:15:41 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 16:15:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868963.1280471 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVvC3-0002Ry-2Z; Thu, 09 Jan 2025 16:15:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868963.1280471; Thu, 09 Jan 2025 16:15:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVvC2-0002RY-VU; Thu, 09 Jan 2025 16:15:34 +0000
Received: by outflank-mailman (input) for mailman id 868963;
 Thu, 09 Jan 2025 16:15: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
 <SRS0=wq9x=UB=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tVvC1-0002PN-Og
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 16:15:33 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f310c09f-cea4-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 17:15:32 +0100 (CET)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-aaee2c5ee6eso190128566b.1
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 08:15:32 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c9645fddsm83988066b.169.2025.01.09.08.15.30
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 09 Jan 2025 08:15:31 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f310c09f-cea4-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736439331; x=1737044131; 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=k02q0uVqEedz6OethSIEqDgrfhFBHQS0vlrPrSFQJPw=;
        b=OBWyG9N+Bq4yEhhTAGTHMD8D2o5BDGPScbiD+ACpg6kzupqZfGLdyYTbqNIjRL9yba
         4f3O4Pv6V57XrMD/w/DIgVuvyOWSYqgIvLM4NlL3J36qoIM0G632QVet55+o0egJ+37h
         /An5mIWn9TpMyNzfUdJmvMHWXyRAd5a6UC2n4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736439331; x=1737044131;
        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=k02q0uVqEedz6OethSIEqDgrfhFBHQS0vlrPrSFQJPw=;
        b=X7NWm1Phke0xoBlWHfRtPNSUCn+aZSFBpneps3oFui8LGPsGWm8wjdGZ5NrPfprbcR
         /uyRF+++jaH63SzMtmx+K+7Nj9I0q4XDMehW8lZcyKnSYhlVoa4HIR4kFr2x+lS4AxVe
         WeVMlhas7mA3YF7usKWU6tE22DwmkhyE+xuLkffaRxI46NyS8+O4D/3atsyLO5jw667j
         UnLC8dl3YcUeC6qIe8o7gj0E4YlrUfqyIjhidotuUwYHFFbJvUgj1Y7htkwZAS3uF03Z
         K+JbruZOUO2qxP2/0qAE6AOk3WNog6meUBEbXzbrQXk9oukyy1/GLrRhJDKe+5cIp9o8
         qD/w==
X-Forwarded-Encrypted: i=1; AJvYcCXMlscLd1zE00tWBUPH7naMAUl9nb3nu+XzrPNkbQh8BnJxX0HLeWkSACdFOQ6pZkZ1j6G2tv2alio=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyKgNl+WeEdjLCJ9H8OjmYTz93oVXd3cGqFMCCUpzhgqzfxUQR/
	KChEV4hS8iQwwNFPd86NTo2uAXmdvrxyRQ2mIlRzOlyZTTHsr+lKpEmpx0Pa3ac=
X-Gm-Gg: ASbGncs4/E7uZ6sXyvlHVl1uYfFG847urKJGzGfzG08WQDEtYAc+HPplFardV/kttKa
	4rJK3po9UYtGvxWRuMD+1owLYNpSqsur+DsFfbOAd5KWMJUsAwmHtt0egCOR7HoMyyVbQN3tUoi
	YpmbJWzRh96m5xVic9F1G1y0Bd96WDI3OVyvNxXUBP4+fv8r/fp8WbPVxhOdQQFLDtcMNAnl3+e
	NpgWrW7nMLRL7NOwGB6Y5DhteANIeFji5Y7JklUzjvn5csDCsfMy1VTnkJuoA==
X-Google-Smtp-Source: AGHT+IHtOa0K6VX3BliPmhDS5BYi81wa3891u/ccPf61M2Pph9hCJc33gfh7s/tmPgj+pMUjlYaTKA==
X-Received: by 2002:a17:907:d9f:b0:aac:180e:b1d4 with SMTP id a640c23a62f3a-ab2ab6fe016mr651317366b.27.1736439331372;
        Thu, 09 Jan 2025 08:15:31 -0800 (PST)
Date: Thu, 9 Jan 2025 17:15:30 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Anthony PERARD <anthony@xenproject.org>
Cc: qemu-devel@nongnu.org, Stefano Stabellini <sstabellini@kernel.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	=?utf-8?Q?Marc-Andr=C3=A9?= Lureau <marcandre.lureau@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH 2/2] xen: do not use '%ms' scanf specifier
Message-ID: <Z3_2IhGZvpF-5IiX@macbook.local>
References: <20250107093140.86180-1-roger.pau@citrix.com>
 <20250107093140.86180-3-roger.pau@citrix.com>
 <Z3-sJMXpiFUoATHz@l14>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <Z3-sJMXpiFUoATHz@l14>

On Thu, Jan 09, 2025 at 11:59:48AM +0100, Anthony PERARD wrote:
> On Tue, Jan 07, 2025 at 10:31:40AM +0100, Roger Pau Monne wrote:
> > The 'm' parameter used to request auto-allocation of the destination variable
> > is not supported on FreeBSD, and as such leads to failures to parse.
> > 
> > What's more, the current usage of '%ms' with xs_node_scanf() is pointless, as
> > it just leads to a double allocation of the same string.  Instead use
> > qemu_xen_xs_read() to read the whole xenstore node.
> > 
> > Fixes: a783f8ad4ec9 ('xen: add a mechanism to automatically create XenDevice-s...')
> > Fixes: 9b7737469080 ('hw/xen: update Xen console to XenDevice model')
> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> > ---
> >  hw/char/xen_console.c | 11 +++++++++--
> >  hw/xen/xen-bus.c      |  7 +++++--
> >  2 files changed, 14 insertions(+), 4 deletions(-)
> > 
> > diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
> > index af706c7ef440..18afd214c2f6 100644
> > --- a/hw/char/xen_console.c
> > +++ b/hw/char/xen_console.c
> > @@ -531,6 +531,7 @@ static void xen_console_device_create(XenBackendInstance *backend,
> >      const char *name = xen_backend_get_name(backend);
> >      unsigned long number;
> >      char *fe = NULL, *type = NULL, *output = NULL;
> > +    const char *node_path;
> 
> Is "const" correct when we are changing to which string `node_path` is
> pointing at? Also, why "const"? Also, compiler complains that we can't
> free a "const something*".

It's my understanding that the proposed const signals that the pointer
value can change, but the contents of the pointer cannot (iow: the
string cannot be modified).

My build seem to be fine, but I see that g_free() doesn't seem to take
a const pointer.  Will adjust.

> >      char label[32];
> >      XenDevice *xendev = NULL;
> >      XenConsole *con;
> > @@ -550,7 +551,10 @@ static void xen_console_device_create(XenBackendInstance *backend,
> >          goto fail;
> >      }
> >  
> > -    if (xs_node_scanf(xsh, XBT_NULL, fe, "type", errp, "%ms", &type) != 1) {
> > +    node_path = g_strdup_printf("%s/type", fe);
> > +    type = qemu_xen_xs_read(xsh, XBT_NULL, node_path, NULL);
> > +    g_free(node_path);
> 
> I feel like we want "xs_node_read()" which would be similair to
> xs_node_vscanf() but would simply return the result of
> qemu_xen_xs_read(). This would avoid the need format of the node path in
> several place in the code. But it's OK like that as well.

I was about to introduce such, but didn't end up doing.  I can do.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 16:16:01 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 16:16:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868952.1280481 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVvCT-0003Bi-DH; Thu, 09 Jan 2025 16:16:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868952.1280481; Thu, 09 Jan 2025 16:16:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVvCT-0003Bb-Ak; Thu, 09 Jan 2025 16:16:01 +0000
Received: by outflank-mailman (input) for mailman id 868952;
 Thu, 09 Jan 2025 16:06: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
 <SRS0=soqj=UB=intel.com=matthew.auld@srs-se1.protection.inumbo.net>)
 id 1tVv32-0004iX-Q5
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 16:06:17 +0000
Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.7])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a5676a1a-cea3-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 17:06:13 +0100 (CET)
Received: from fmviesa010.fm.intel.com ([10.60.135.150])
 by fmvoesa101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 09 Jan 2025 08:05:55 -0800
Received: from bergbenj-mobl1.ger.corp.intel.com (HELO [10.245.245.241])
 ([10.245.245.241])
 by fmviesa010-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 09 Jan 2025 08:05:50 -0800
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a5676a1a-cea3-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=intel.com; i=@intel.com; q=dns/txt; s=Intel;
  t=1736438774; x=1767974774;
  h=message-id:date:mime-version:subject:to:cc:references:
   from:in-reply-to:content-transfer-encoding;
  bh=p4XkuorIpNoSEU2HBpQ1O27DvwV5LvulfkLyMZfyAfg=;
  b=BV96KLx/GpINYPjtoGCUzPgRdDy35Ezx9iAT4TVVlq/VU5z3poIeLtxd
   XQhs3sidlWwjChJ4sGZciPPiwKLGUDgVjuVaPeUFL3986bSotTV4vR/Za
   N/WKVaMPmmUo0AG5zMiPpvcmzTSTWOXIhXHoX5Wu0Gz/DoeMEuE6TA9PG
   QabMXpOFBwFbWICOhEPkDccQZpV3YxVFW06p+gX+SATv2W6TQr5rgnJmn
   5O6tSIFGD3rwzSYzpxz3bS1S9YzQIoJE2NDN+kqyswP/E6KXYAzyBCaTg
   AVLcVJvWyDVORuulU68w8UOmSsSoa/7y/4nUe5+RqnFZesA3AxxLVt5Gd
   Q==;
X-CSE-ConnectionGUID: nV9CUtq6Q/iikQqV4TSm+w==
X-CSE-MsgGUID: wgG7ghxVQbKfiqqSZWN6+A==
X-IronPort-AV: E=McAfee;i="6700,10204,11310"; a="62086137"
X-IronPort-AV: E=Sophos;i="6.12,301,1728975600"; 
   d="scan'208";a="62086137"
X-CSE-ConnectionGUID: gYM7jUeoQau2+oJbNyjiWQ==
X-CSE-MsgGUID: 8PkbOk3sQpqIzHIL0w463A==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="6.12,301,1728975600"; 
   d="scan'208";a="103967271"
Message-ID: <91c904f8-ba47-4595-be65-6fb57dcc9c64@intel.com>
Date: Thu, 9 Jan 2025 16:05:47 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 23/25] drm/xe: Compute dumb-buffer sizes with
 drm_mode_size_dumb()
To: Thomas Zimmermann <tzimmermann@suse.de>,
 maarten.lankhorst@linux.intel.com, mripard@kernel.org, airlied@gmail.com,
 simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org, linux-mediatek@lists.infradead.org,
 freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
 imx@lists.linux.dev, linux-samsung-soc@vger.kernel.org,
 nouveau@lists.freedesktop.org, virtualization@lists.linux.dev,
 spice-devel@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org,
 linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org,
 intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org,
 Lucas De Marchi <lucas.demarchi@intel.com>,
 =?UTF-8?Q?Thomas_Hellstr=C3=B6m?= <thomas.hellstrom@linux.intel.com>,
 Rodrigo Vivi <rodrigo.vivi@intel.com>
References: <20250109150310.219442-1-tzimmermann@suse.de>
 <20250109150310.219442-24-tzimmermann@suse.de>
Content-Language: en-GB
From: Matthew Auld <matthew.auld@intel.com>
In-Reply-To: <20250109150310.219442-24-tzimmermann@suse.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 09/01/2025 14:57, Thomas Zimmermann wrote:
> Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch
> and buffer size. Align the pitch to a multiple of 8. Align the
> buffer size according to hardware requirements.
> 
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> ---
>   drivers/gpu/drm/xe/xe_bo.c | 8 ++++----
>   1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
> index e6c896ad5602..d75e3c39ab14 100644
> --- a/drivers/gpu/drm/xe/xe_bo.c
> +++ b/drivers/gpu/drm/xe/xe_bo.c
> @@ -8,6 +8,7 @@
>   #include <linux/dma-buf.h>
>   
>   #include <drm/drm_drv.h>
> +#include <drm/drm_dumb_buffers.h>
>   #include <drm/drm_gem_ttm_helper.h>
>   #include <drm/drm_managed.h>
>   #include <drm/ttm/ttm_device.h>
> @@ -2535,14 +2536,13 @@ int xe_bo_dumb_create(struct drm_file *file_priv,
>   	struct xe_device *xe = to_xe_device(dev);
>   	struct xe_bo *bo;
>   	uint32_t handle;
> -	int cpp = DIV_ROUND_UP(args->bpp, 8);
>   	int err;
>   	u32 page_size = max_t(u32, PAGE_SIZE,
>   		xe->info.vram_flags & XE_VRAM_FLAGS_NEED64K ? SZ_64K : SZ_4K);
>   
> -	args->pitch = ALIGN(args->width * cpp, 64);
> -	args->size = ALIGN(mul_u32_u32(args->pitch, args->height),
> -			   page_size);
> +	err = drm_mode_size_dumb(dev, args, SZ_64, page_size);

AFAICT this looks to change the behaviour, where u64 size was 
technically possible and was allowed given that args->size is u64, but 
this helper is limiting the size to u32. Is that intentional? If so, we 
should probably make that clear in the commit message.

> +	if (err)
> +		return err;
>   
>   	bo = xe_bo_create_user(xe, NULL, NULL, args->size,
>   			       DRM_XE_GEM_CPU_CACHING_WC,



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 16:26:42 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 16:26:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.868985.1280490 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVvMa-0001S8-7K; Thu, 09 Jan 2025 16:26:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 868985.1280490; Thu, 09 Jan 2025 16:26:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVvMa-0001S1-4k; Thu, 09 Jan 2025 16:26:28 +0000
Received: by outflank-mailman (input) for mailman id 868985;
 Thu, 09 Jan 2025 16:26:27 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=BoWZ=UB=suse.de=tzimmermann@srs-se1.protection.inumbo.net>)
 id 1tVvMZ-0001Rt-G9
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 16:26:27 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 78fbe494-cea6-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 17:26:26 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id 8BEF71F394;
 Thu,  9 Jan 2025 16:26:25 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 00C48139AB;
 Thu,  9 Jan 2025 16:26:24 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id 9qu0ObD4f2fqBgAAD6G6ig
 (envelope-from <tzimmermann@suse.de>); Thu, 09 Jan 2025 16:26:24 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 78fbe494-cea6-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736439985; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=NRmPm0ZNk/C3mZstvTuhKj0QjfwNtjAVVxCaUxWitUE=;
	b=sbSREeiq9iYjhEjeQW4qdyaKgpxCCvgX4XR/fBFVbBO4pMWr9sS4BXsXIGQmQ85imThdW3
	YEr9PS4vxUj00SkQvkhd+WdDG7ceEvYLGtYIwa15RLNL2aCvQCzad51udAuGukV2DSk9ep
	xC+VFiwxwgPTMZtQGbOekt/679hQbN0=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736439985;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=NRmPm0ZNk/C3mZstvTuhKj0QjfwNtjAVVxCaUxWitUE=;
	b=Lfl2D7OwYEWe79nVY++MQKtG++F9vBKMfMM+7FkArBH4/ckhXi+TbuY3f0MHOm2XwF8VUk
	tzwhYX4d2YyHyaDw==
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736439985; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=NRmPm0ZNk/C3mZstvTuhKj0QjfwNtjAVVxCaUxWitUE=;
	b=sbSREeiq9iYjhEjeQW4qdyaKgpxCCvgX4XR/fBFVbBO4pMWr9sS4BXsXIGQmQ85imThdW3
	YEr9PS4vxUj00SkQvkhd+WdDG7ceEvYLGtYIwa15RLNL2aCvQCzad51udAuGukV2DSk9ep
	xC+VFiwxwgPTMZtQGbOekt/679hQbN0=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736439985;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=NRmPm0ZNk/C3mZstvTuhKj0QjfwNtjAVVxCaUxWitUE=;
	b=Lfl2D7OwYEWe79nVY++MQKtG++F9vBKMfMM+7FkArBH4/ckhXi+TbuY3f0MHOm2XwF8VUk
	tzwhYX4d2YyHyaDw==
Message-ID: <6666af19-a98d-41d7-8329-7b50807c04a9@suse.de>
Date: Thu, 9 Jan 2025 17:26:24 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 23/25] drm/xe: Compute dumb-buffer sizes with
 drm_mode_size_dumb()
To: Matthew Auld <matthew.auld@intel.com>, maarten.lankhorst@linux.intel.com,
 mripard@kernel.org, airlied@gmail.com, simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org, linux-mediatek@lists.infradead.org,
 freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
 imx@lists.linux.dev, linux-samsung-soc@vger.kernel.org,
 nouveau@lists.freedesktop.org, virtualization@lists.linux.dev,
 spice-devel@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org,
 linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org,
 intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org,
 Lucas De Marchi <lucas.demarchi@intel.com>,
 =?UTF-8?Q?Thomas_Hellstr=C3=B6m?= <thomas.hellstrom@linux.intel.com>,
 Rodrigo Vivi <rodrigo.vivi@intel.com>
References: <20250109150310.219442-1-tzimmermann@suse.de>
 <20250109150310.219442-24-tzimmermann@suse.de>
 <91c904f8-ba47-4595-be65-6fb57dcc9c64@intel.com>
Content-Language: en-US
From: Thomas Zimmermann <tzimmermann@suse.de>
Autocrypt: addr=tzimmermann@suse.de; keydata=
 xsBNBFs50uABCADEHPidWt974CaxBVbrIBwqcq/WURinJ3+2WlIrKWspiP83vfZKaXhFYsdg
 XH47fDVbPPj+d6tQrw5lPQCyqjwrCPYnq3WlIBnGPJ4/jreTL6V+qfKRDlGLWFjZcsrPJGE0
 BeB5BbqP5erN1qylK9i3gPoQjXGhpBpQYwRrEyQyjuvk+Ev0K1Jc5tVDeJAuau3TGNgah4Yc
 hdHm3bkPjz9EErV85RwvImQ1dptvx6s7xzwXTgGAsaYZsL8WCwDaTuqFa1d1jjlaxg6+tZsB
 9GluwvIhSezPgnEmimZDkGnZRRSFiGP8yjqTjjWuf0bSj5rUnTGiyLyRZRNGcXmu6hjlABEB
 AAHNJ1Rob21hcyBaaW1tZXJtYW5uIDx0emltbWVybWFubkBzdXNlLmRlPsLAjgQTAQgAOAIb
 AwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftODH
 AAoJEGgNwR1TC3ojx1wH/0hKGWugiqDgLNXLRD/4TfHBEKmxIrmfu9Z5t7vwUKfwhFL6hqvo
 lXPJJKQpQ2z8+X2vZm/slsLn7J1yjrOsoJhKABDi+3QWWSGkaGwRJAdPVVyJMfJRNNNIKwVb
 U6B1BkX2XDKDGffF4TxlOpSQzdtNI/9gleOoUA8+jy8knnDYzjBNOZqLG2FuTdicBXblz0Mf
 vg41gd9kCwYXDnD91rJU8tzylXv03E75NCaTxTM+FBXPmsAVYQ4GYhhgFt8S2UWMoaaABLDe
 7l5FdnLdDEcbmd8uLU2CaG4W2cLrUaI4jz2XbkcPQkqTQ3EB67hYkjiEE6Zy3ggOitiQGcqp
 j//OwE0EWznS4AEIAMYmP4M/V+T5RY5at/g7rUdNsLhWv1APYrh9RQefODYHrNRHUE9eosYb
 T6XMryR9hT8XlGOYRwKWwiQBoWSDiTMo/Xi29jUnn4BXfI2px2DTXwc22LKtLAgTRjP+qbU6
 3Y0xnQN29UGDbYgyyK51DW3H0If2a3JNsheAAK+Xc9baj0LGIc8T9uiEWHBnCH+RdhgATnWW
 GKdDegUR5BkDfDg5O/FISymJBHx2Dyoklv5g4BzkgqTqwmaYzsl8UxZKvbaxq0zbehDda8lv
 hFXodNFMAgTLJlLuDYOGLK2AwbrS3Sp0AEbkpdJBb44qVlGm5bApZouHeJ/+n+7r12+lqdsA
 EQEAAcLAdgQYAQgAIAIbDBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftOH6AAoJEGgNwR1T
 C3ojVSkIALpAPkIJPQoURPb1VWjh34l0HlglmYHvZszJWTXYwavHR8+k6Baa6H7ufXNQtThR
 yIxJrQLW6rV5lm7TjhffEhxVCn37+cg0zZ3j7zIsSS0rx/aMwi6VhFJA5hfn3T0TtrijKP4A
 SAQO9xD1Zk9/61JWk8OysuIh7MXkl0fxbRKWE93XeQBhIJHQfnc+YBLprdnxR446Sh8Wn/2D
 Ya8cavuWf2zrB6cZurs048xe0UbSW5AOSo4V9M0jzYI4nZqTmPxYyXbm30Kvmz0rYVRaitYJ
 4kyYYMhuULvrJDMjZRvaNe52tkKAvMevcGdt38H4KSVXAylqyQOW5zvPc4/sq9c=
In-Reply-To: <91c904f8-ba47-4595-be65-6fb57dcc9c64@intel.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Level: 
X-Spamd-Result: default: False [-2.80 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	FREEMAIL_TO(0.00)[intel.com,linux.intel.com,kernel.org,gmail.com,ffwll.ch];
	TO_DN_SOME(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	FREEMAIL_ENVRCPT(0.00)[gmail.com];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[22];
	RCVD_TLS_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	DBL_BLOCKED_OPENRESOLVER(0.00)[bootlin.com:url,suse.de:email,suse.de:mid]
X-Spam-Score: -2.80
X-Spam-Flag: NO

Hi


Am 09.01.25 um 17:05 schrieb Matthew Auld:
> On 09/01/2025 14:57, Thomas Zimmermann wrote:
>> Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch
>> and buffer size. Align the pitch to a multiple of 8. Align the
>> buffer size according to hardware requirements.
>>
>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>> Cc: Lucas De Marchi <lucas.demarchi@intel.com>
>> Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
>> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
>> ---
>>   drivers/gpu/drm/xe/xe_bo.c | 8 ++++----
>>   1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
>> index e6c896ad5602..d75e3c39ab14 100644
>> --- a/drivers/gpu/drm/xe/xe_bo.c
>> +++ b/drivers/gpu/drm/xe/xe_bo.c
>> @@ -8,6 +8,7 @@
>>   #include <linux/dma-buf.h>
>>     #include <drm/drm_drv.h>
>> +#include <drm/drm_dumb_buffers.h>
>>   #include <drm/drm_gem_ttm_helper.h>
>>   #include <drm/drm_managed.h>
>>   #include <drm/ttm/ttm_device.h>
>> @@ -2535,14 +2536,13 @@ int xe_bo_dumb_create(struct drm_file 
>> *file_priv,
>>       struct xe_device *xe = to_xe_device(dev);
>>       struct xe_bo *bo;
>>       uint32_t handle;
>> -    int cpp = DIV_ROUND_UP(args->bpp, 8);
>>       int err;
>>       u32 page_size = max_t(u32, PAGE_SIZE,
>>           xe->info.vram_flags & XE_VRAM_FLAGS_NEED64K ? SZ_64K : SZ_4K);
>>   -    args->pitch = ALIGN(args->width * cpp, 64);
>> -    args->size = ALIGN(mul_u32_u32(args->pitch, args->height),
>> -               page_size);
>> +    err = drm_mode_size_dumb(dev, args, SZ_64, page_size);
>
> AFAICT this looks to change the behaviour, where u64 size was 
> technically possible and was allowed given that args->size is u64, but 
> this helper is limiting the size to u32. Is that intentional? If so, 
> we should probably make that clear in the commit message.

That's an interesting observation; thanks. The ioctl's internal checks 
have always limited the size to 32 bit. [1] I think it is not supposed 
to be larger than that. We can change the helper to support 64-bit sizes 
as well.

Having said that, is there any use case? Dumb buffers are for software 
rendering only. Allocating more than a few dozen MiB seems like a 
mistake. Maybe we should rather limit the allowed allocation size instead?

Best regards
Thomas

[1] 
https://elixir.bootlin.com/linux/v6.12.6/source/drivers/gpu/drm/drm_dumb_buffers.c#L82

>
>> +    if (err)
>> +        return err;
>>         bo = xe_bo_create_user(xe, NULL, NULL, args->size,
>>                      DRM_XE_GEM_CPU_CACHING_WC,
>

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 16:53:23 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 16:53:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869002.1280509 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVvmT-0007PD-9q; Thu, 09 Jan 2025 16:53:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869002.1280509; Thu, 09 Jan 2025 16:53:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVvmT-0007P3-7M; Thu, 09 Jan 2025 16:53:13 +0000
Received: by outflank-mailman (input) for mailman id 869002;
 Thu, 09 Jan 2025 16:53:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=wq9x=UB=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tVvmR-0007Ox-SN
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 16:53:11 +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 3533833f-ceaa-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 17:53:10 +0100 (CET)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-5d647d5df90so1646467a12.2
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 08:53:10 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d99046d7d5sm738166a12.66.2025.01.09.08.53.09
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 09 Jan 2025 08:53:09 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 3533833f-ceaa-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736441590; x=1737046390; 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=fFPG3vtagIjWQDrIfBWtwD87girSPnIfPZVcnJtDFaI=;
        b=mOA4WLSvjLtllt7zku9qbf/rcEUVm6il8OnTyqSoW37WyYkm5iZjvIJArxucg710Nk
         vIGuJLf/WP1Is0SjQoXGuSLDggVQHepTYK+84fPcV2lKFTYB3fijmm3U7+UfU67YkOxI
         8Tp1sr3tMIDvxk8wu88nW9ZMPSKDrwLzT1WZg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736441590; x=1737046390;
        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=fFPG3vtagIjWQDrIfBWtwD87girSPnIfPZVcnJtDFaI=;
        b=ThYb3IO6H2Hp7aA2g0tOIzl0hqVzyaDNo3DTPAzafLtj+tx5zq+Jp3uE19O1Ri+V1l
         4fndsf+RiRjEl90t6rJnnxXSw4GGtZIxuyxEL9Stkbkl2lGerDo9qA07RX/NiqPDdgOf
         ScvruxIjqRnVdPz4su0lMAxKm8+VRYj2nQpOzZp7YLkBTin5ofJj1Vg3D775zRlfW3Np
         VgzwrjNf8T9VLaup/Pm8di6nfOhAjOOXqlMADKhHDdAcdS8WLgUAlxBtlUZJM5KXbC9n
         hUL6coKmlDq/Sls57WBQbJ2ldng7twmSe7DqHdXg8vvH/HVQrxkyNvodOEFJlOJBnA3P
         HrHQ==
X-Forwarded-Encrypted: i=1; AJvYcCWJYIjas52/rKuYFqb+4tpT4cKGzeJLbt7Z22Vr42jp6hf+bZ/3OlpX7rHQKRKO1apMu1svRlOKRUo=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz9exTz9iknof76jMUvEZD9N7Vo8FlN+edrTf6jodj2iTNYqbgH
	Y0DQsUNaaU9hNCOp9RPB9bam9L81Q1eun0S8LLKPjptA1UEntwxzp20aN5JLPn8=
X-Gm-Gg: ASbGncuruJ3KU6AJUCy2N1jojUnOIEsLBCIe/ZSp/mbyNo6u+wGsV3Es39/H5g8J93s
	p4PI1WlSrC2V1yQ69F9iZXMlVYYucdAZKf9QaBRcIhVoxdHd2NLIpbwHH0dEVOO6IUqJ1wNWtdL
	OHnQroezx13J+b5tQ+HxXPdb+w/DlYNB6siJZOxxANlx2mI3KkQYMaJwCY3i0R/chsAKSlOjVFM
	x4Vj4zpI5U0IW+dDxmERhddF0JnKqWO7XDImv/uomAVgPov18NbRMJWM0w1+uJf/94=
X-Google-Smtp-Source: AGHT+IEz6qx9kQS5GG0suU4+aH8afVchE/kbuaGCek4OwD21/xD8B0SAVRHHt950XLLRsbI8wiVm7A==
X-Received: by 2002:a05:6402:5254:b0:5d3:fc60:a504 with SMTP id 4fb4d7f45d1cf-5d972e17891mr6477983a12.20.1736441589808;
        Thu, 09 Jan 2025 08:53:09 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: qemu-devel@nongnu.org
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	=?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= <marcandre.lureau@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	xen-devel@lists.xenproject.org
Subject: [PATCH v2] xen: do not use '%ms' scanf specifier
Date: Thu,  9 Jan 2025 17:52:39 +0100
Message-ID: <20250109165239.16851-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The 'm' parameter used to request auto-allocation of the destination variable
is not supported on FreeBSD, and as such leads to failures to parse.

What's more, the current usage of '%ms' with xs_node_scanf() is pointless, as
it just leads to a double allocation of the same string.  Instead introduce and
use xs_node_read() to read the whole xenstore node.

Additionally fix the errors paths to not use error_prepend(), as that could
lead to a segmentation fault because xs_node_scanf() only initializes errp when
returning a value smaller than 0:

Program terminated with signal SIGSEGV, Segmentation fault.
Address not mapped to object.
    fmt=0x15c4dfeade42 "failed to read console device type: ", ap=0x15cd0165ab50)
    at ../qemu-xen-dir-remote/util/error.c:142
142         g_string_append(newmsg, (*errp)->msg);
[...]
(gdb) bt
    (errp=0x15cd0165ae10, fmt=0x15c4dfeade42 "failed to read console device type: ", ap=0x15cd0165ab50) at ../qemu-xen-dir-remote/util/error.c:142
    (errp=0x15cd0165ae10, fmt=0x15c4dfeade42 "failed to read console device type: ")
    at ../qemu-xen-dir-remote/util/error.c:152
    (backend=0x43944de00660, opts=0x43944c929000, errp=0x15cd0165ae10)
    at ../qemu-xen-dir-remote/hw/char/xen_console.c:555

With the change to use xs_node_read() instead of xs_node_scanf() errp will
never be initialized, and hence error_setg() should be used unconditionally.

Fixes: a783f8ad4ec9 ('xen: add a mechanism to automatically create XenDevice-s...')
Fixes: 9b7737469080 ('hw/xen: update Xen console to XenDevice model')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Changes since v1:
 - Introduce xs_node_read() helper.
 - Merge with errp fixes.
---
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: Anthony PERARD <anthony@xenproject.org>
Cc: Paul Durrant <paul@xen.org>
Cc: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>
Cc: "Marc-André Lureau" <marcandre.lureau@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: xen-devel@lists.xenproject.org
---
 hw/char/xen_console.c           | 12 +++++++-----
 hw/xen/xen-bus-helper.c         | 12 ++++++++++++
 hw/xen/xen-bus.c                |  4 ++--
 include/hw/xen/xen-bus-helper.h |  2 ++
 4 files changed, 23 insertions(+), 7 deletions(-)

diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
index ef0c2912efa1..a3591df1af2e 100644
--- a/hw/char/xen_console.c
+++ b/hw/char/xen_console.c
@@ -550,8 +550,9 @@ static void xen_console_device_create(XenBackendInstance *backend,
         goto fail;
     }
 
-    if (xs_node_scanf(xsh, XBT_NULL, fe, "type", errp, "%ms", &type) != 1) {
-        error_prepend(errp, "failed to read console device type: ");
+    type = xs_node_read(xsh, XBT_NULL, fe, "type");
+    if (!type) {
+        error_setg(errp, "failed to read console device type");
         goto fail;
     }
 
@@ -568,7 +569,8 @@ static void xen_console_device_create(XenBackendInstance *backend,
 
     snprintf(label, sizeof(label), "xencons%ld", number);
 
-    if (xs_node_scanf(xsh, XBT_NULL, fe, "output", NULL, "%ms", &output) == 1) {
+    output = xs_node_read(xsh, XBT_NULL, fe, "output");
+    if (!output) {
         /*
          * FIXME: sure we want to support implicit
          * muxed monitors here?
@@ -582,8 +584,8 @@ static void xen_console_device_create(XenBackendInstance *backend,
     } else if (number) {
         cd = serial_hd(number);
         if (!cd) {
-            error_prepend(errp, "console: No serial device #%ld found: ",
-                          number);
+            error_setg(errp, "console: No serial device #%ld found",
+                       number);
             goto fail;
         }
     } else {
diff --git a/hw/xen/xen-bus-helper.c b/hw/xen/xen-bus-helper.c
index b2b2cc9c5d5e..115c5b1a8ce8 100644
--- a/hw/xen/xen-bus-helper.c
+++ b/hw/xen/xen-bus-helper.c
@@ -142,6 +142,18 @@ int xs_node_scanf(struct qemu_xs_handle *h,  xs_transaction_t tid,
     return rc;
 }
 
+char *xs_node_read(struct qemu_xs_handle *h, xs_transaction_t tid,
+                   const char *node, const char *key)
+{
+    char *path = (strlen(node) != 0) ? g_strdup_printf("%s/%s", node, key)
+                                     : g_strdup(key);
+    char *value = qemu_xen_xs_read(h, tid, path, NULL);
+
+    g_free(path);
+
+    return value;
+}
+
 struct qemu_xs_watch *xs_node_watch(struct qemu_xs_handle *h, const char *node,
                                     const char *key, xs_watch_fn fn,
                                     void *opaque, Error **errp)
diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c
index adfc4efad035..aaede5d9ecb2 100644
--- a/hw/xen/xen-bus.c
+++ b/hw/xen/xen-bus.c
@@ -156,8 +156,8 @@ again:
             !strcmp(key[i], "hotplug-status"))
             continue;
 
-        if (xs_node_scanf(xenbus->xsh, tid, path, key[i], NULL, "%ms",
-                          &val) == 1) {
+        val = xs_node_read(xenbus->xsh, tid, path, key[i]);
+        if (val) {
             qdict_put_str(opts, key[i], val);
             free(val);
         }
diff --git a/include/hw/xen/xen-bus-helper.h b/include/hw/xen/xen-bus-helper.h
index d8dcc2f0107d..79f0787332ed 100644
--- a/include/hw/xen/xen-bus-helper.h
+++ b/include/hw/xen/xen-bus-helper.h
@@ -37,6 +37,8 @@ int xs_node_scanf(struct qemu_xs_handle *h,  xs_transaction_t tid,
                   const char *node, const char *key, Error **errp,
                   const char *fmt, ...)
     G_GNUC_SCANF(6, 7);
+char *xs_node_read(struct qemu_xs_handle *h, xs_transaction_t tid,
+                   const char *node, const char *key);
 
 /* Watch node/key unless node is empty, in which case watch key */
 struct qemu_xs_watch *xs_node_watch(struct qemu_xs_handle *h, const char *node,
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 16:55:26 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 16:55:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869010.1280518 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVvob-0000TV-L9; Thu, 09 Jan 2025 16:55:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869010.1280518; Thu, 09 Jan 2025 16:55:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVvob-0000TO-IV; Thu, 09 Jan 2025 16:55:25 +0000
Received: by outflank-mailman (input) for mailman id 869010;
 Thu, 09 Jan 2025 16:55:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=wq9x=UB=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tVvoa-0000S8-0T
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 16:55:24 +0000
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [2a00:1450:4864:20::62c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 83a32600-ceaa-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 17:55:22 +0100 (CET)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-aa69107179cso247553666b.0
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 08:55:22 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c9060bccsm87855766b.22.2025.01.09.08.55.21
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 09 Jan 2025 08:55:21 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 83a32600-ceaa-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736441721; x=1737046521; 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=cAZUAQvOu49U0hMeCh88veBnObf9ztRSpbDykRVZvls=;
        b=tf+gYbMOB9Sx8iAXZHRAZi7xIGjU51SWxqjUUCztUdiLgMSS0XoNOzJH9PK7D5z3hL
         nt1KKSwIoOGsPIDix9YteBNcVAGVCuUJ3ulNE5Cz4ZZbUSBW00ipo6TonY9GKF4La5cv
         tfRUxt4d/O/DYxjxWCA5TBuRLT3v7W6y6ByIc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736441721; x=1737046521;
        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=cAZUAQvOu49U0hMeCh88veBnObf9ztRSpbDykRVZvls=;
        b=Mddsg9VDQqiMp9H696xP7ytZ/p7nilXGr5KrzDJWsb95RU47eGl1tW6KbBLhvMKJmM
         xRGFm0p/PtvkTVLGdobtMp96gLP89RcW1C9qco+Vbb8s+2NEZgaOI284DCnqSSKcOgwx
         5vO4q7vttUPKFmBFKw5Z+M4A2Yzuj0dpgMg9rCfceCX1migx+oPJjGrloSh3EElHLx4k
         PHOxWVMCebRaLmkrse5n8EeDVl9gqr1R1w/OQR6QYL0UkggwN/GKutX6T+GmRC3veUv3
         xgtHwblXRfJW2Dn5WwX8ok18c2p1ayS1bs9NJMRb9Iy/4L6RNfdenSSDeEZdF9U5n1vH
         7IBA==
X-Forwarded-Encrypted: i=1; AJvYcCWIYi/zF4TCN2kSvjA2XqrcidFLAxZS2JTPS+RfKk6Ja7As2frYQdpmKRBF1FQrOhCuH7Z5Gpc6HwI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzaIjftoHgVq23yzTlLgXCWEzc3sagiEYxQs3i4NBkMGDpkRQeV
	6F2TX8v7OBSw7y/g9o2czuIK86k0In1Em4lNCnFYcuyxagMiuiiEhsIAB1uG6h0=
X-Gm-Gg: ASbGncsZ/7r4/6rtWS8aykQqD+7vONJEuJnMAj9/u1etCZx1UrMorDM0SoMIIk2scjs
	wwPBilbIruCz+YW6H7y3SksjDQeByp31oustDjs+eoEBDpkwlwZL8nkmdFgrJRZlssH0IyomQVP
	sGOqXWbVt6GyE3tAHrLGWduOLj1Eux42LJno5LLWQqbKeNBY714GFH0djZvOlHn1ytPoDAq1bNA
	6ssyONiUA1xgfbbTctI1g8kn6p88fbCNSJ5Z95KTuQfsnFN0tYGZmNbGPiDk8aJyeM=
X-Google-Smtp-Source: AGHT+IEPfaoIteOnCS1BZkrnCp2XmLg4coGnDJ6lEs9RhKv2NEsZx36bQjMcFZH/VY0iyaYox8xY1g==
X-Received: by 2002:a17:907:1c24:b0:aa6:85d0:1492 with SMTP id a640c23a62f3a-ab2abc6d423mr636122966b.37.1736441721609;
        Thu, 09 Jan 2025 08:55:21 -0800 (PST)
Date: Thu, 9 Jan 2025 17:55:20 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Anthony PERARD <anthony@xenproject.org>, qemu-devel@nongnu.org,
	Stefano Stabellini <sstabellini@kernel.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	=?utf-8?Q?Marc-Andr=C3=A9?= Lureau <marcandre.lureau@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH 2/2] xen: do not use '%ms' scanf specifier
Message-ID: <Z3__eDp4hShe79Pl@macbook.local>
References: <20250107093140.86180-1-roger.pau@citrix.com>
 <20250107093140.86180-3-roger.pau@citrix.com>
 <Z3-sJMXpiFUoATHz@l14>
 <974ab6743d168d34babd458fe5e2e7766bb280b4.camel@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <974ab6743d168d34babd458fe5e2e7766bb280b4.camel@infradead.org>

On Thu, Jan 09, 2025 at 11:25:13AM +0000, David Woodhouse wrote:
> On Thu, 2025-01-09 at 11:59 +0100, Anthony PERARD wrote:
> > 
> > >       char label[32];
> > >       XenDevice *xendev = NULL;
> > >       XenConsole *con;
> > > @@ -550,7 +551,10 @@ static void xen_console_device_create(XenBackendInstance *backend,
> > >           goto fail;
> > >       }
> > >   
> > > -    if (xs_node_scanf(xsh, XBT_NULL, fe, "type", errp, "%ms", &type) != 1) {
> > > +    node_path = g_strdup_printf("%s/type", fe);
> > > +    type = qemu_xen_xs_read(xsh, XBT_NULL, node_path, NULL);
> > > +    g_free(node_path);
> > 
> > I feel like we want "xs_node_read()" which would be similair to
> > xs_node_vscanf() but would simply return the result of
> > qemu_xen_xs_read(). This would avoid the need format of the node path in
> > several place in the code. But it's OK like that as well.
> 
> If you look at the other callers of qemu_xen_xs_read(), it looks like
> the majority of them create the path with snprintf and then pass it in.
> Or with g_strdup_printf(), pass it in, then free it afterwards.
> 
> So perhaps qemu_xen_xs_read() should be a printf-style function too,
> with its last arg(s) being the node name.

I just went with Anthony suggestion and introduced xs_node_read(), as
I didn't want to play with qemu_xen_xs_read().  Not that I think the
suggestion is not valid, just seemed more work than what I wanted to
do right now.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 17:15:40 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 17:15:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869027.1280529 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVw85-0002Fk-Ap; Thu, 09 Jan 2025 17:15:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869027.1280529; Thu, 09 Jan 2025 17:15:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVw85-0002Fd-80; Thu, 09 Jan 2025 17:15:33 +0000
Received: by outflank-mailman (input) for mailman id 869027;
 Thu, 09 Jan 2025 17:15:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=soqj=UB=intel.com=matthew.auld@srs-se1.protection.inumbo.net>)
 id 1tVw82-0002D2-Rv
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 17:15:31 +0000
Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.19])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 51587ae6-cead-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 18:15:27 +0100 (CET)
Received: from orviesa001.jf.intel.com ([10.64.159.141])
 by orvoesa111.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 09 Jan 2025 09:15:26 -0800
Received: from bergbenj-mobl1.ger.corp.intel.com (HELO [10.245.245.241])
 ([10.245.245.241])
 by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 09 Jan 2025 09:15:20 -0800
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 51587ae6-cead-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=intel.com; i=@intel.com; q=dns/txt; s=Intel;
  t=1736442929; x=1767978929;
  h=message-id:date:mime-version:subject:to:cc:references:
   from:in-reply-to:content-transfer-encoding;
  bh=iHe0e5c+fmzIEFb4JwfVINvpf7LWF6/4nvNtj0QRgPQ=;
  b=O4CmsVr9k9c8uZmUYCdhKIHar0KLihH4wSm10xKIyq2fcAl91J3WHFBe
   tDbeKJO+pINS+FtJbV36FI4ykzGduq2sNJezvIgxczBPYUxrEtE650Xlt
   SZOUT43T2svBzL0agIDTojw7zfo/DbMqAfceJPhK4UeC6YeObVS3FnqXh
   p6M13Hk9EoOJpgaMDbKz0c7/ITdExTbjDJU+GScDcJVp6t+HuItmylC6t
   nqZNlAmmEUW4SkNyHPWloviO2GrKwJBpRFSV6+jNjdixwXlARNMhP2qaP
   DicRifRpV9DoAJb6NbjZ/1xx5XFpSPAus6IKBaBFzpowckra8TF8iKP22
   w==;
X-CSE-ConnectionGUID: VP4he6mCRiKtJsv4WD6AAg==
X-CSE-MsgGUID: 2MBZqPk9SL6tFaa9HcG15A==
X-IronPort-AV: E=McAfee;i="6700,10204,11310"; a="36604456"
X-IronPort-AV: E=Sophos;i="6.12,301,1728975600"; 
   d="scan'208";a="36604456"
X-CSE-ConnectionGUID: sCHGnpr3S22msRSMnEsaNw==
X-CSE-MsgGUID: Kiw4VfoXQbSJcARHoMEU4w==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="6.12,224,1728975600"; 
   d="scan'208";a="140776648"
Message-ID: <ec240a46-3fe1-46fa-84bc-2f962d7441ce@intel.com>
Date: Thu, 9 Jan 2025 17:15:17 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 23/25] drm/xe: Compute dumb-buffer sizes with
 drm_mode_size_dumb()
To: Thomas Zimmermann <tzimmermann@suse.de>,
 maarten.lankhorst@linux.intel.com, mripard@kernel.org, airlied@gmail.com,
 simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org, linux-mediatek@lists.infradead.org,
 freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
 imx@lists.linux.dev, linux-samsung-soc@vger.kernel.org,
 nouveau@lists.freedesktop.org, virtualization@lists.linux.dev,
 spice-devel@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org,
 linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org,
 intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org,
 Lucas De Marchi <lucas.demarchi@intel.com>,
 =?UTF-8?Q?Thomas_Hellstr=C3=B6m?= <thomas.hellstrom@linux.intel.com>,
 Rodrigo Vivi <rodrigo.vivi@intel.com>
References: <20250109150310.219442-1-tzimmermann@suse.de>
 <20250109150310.219442-24-tzimmermann@suse.de>
 <91c904f8-ba47-4595-be65-6fb57dcc9c64@intel.com>
 <6666af19-a98d-41d7-8329-7b50807c04a9@suse.de>
Content-Language: en-GB
From: Matthew Auld <matthew.auld@intel.com>
In-Reply-To: <6666af19-a98d-41d7-8329-7b50807c04a9@suse.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 09/01/2025 16:26, Thomas Zimmermann wrote:
> Hi
> 
> 
> Am 09.01.25 um 17:05 schrieb Matthew Auld:
>> On 09/01/2025 14:57, Thomas Zimmermann wrote:
>>> Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch
>>> and buffer size. Align the pitch to a multiple of 8. Align the
>>> buffer size according to hardware requirements.
>>>
>>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>>> Cc: Lucas De Marchi <lucas.demarchi@intel.com>
>>> Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
>>> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
>>> ---
>>>   drivers/gpu/drm/xe/xe_bo.c | 8 ++++----
>>>   1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
>>> index e6c896ad5602..d75e3c39ab14 100644
>>> --- a/drivers/gpu/drm/xe/xe_bo.c
>>> +++ b/drivers/gpu/drm/xe/xe_bo.c
>>> @@ -8,6 +8,7 @@
>>>   #include <linux/dma-buf.h>
>>>     #include <drm/drm_drv.h>
>>> +#include <drm/drm_dumb_buffers.h>
>>>   #include <drm/drm_gem_ttm_helper.h>
>>>   #include <drm/drm_managed.h>
>>>   #include <drm/ttm/ttm_device.h>
>>> @@ -2535,14 +2536,13 @@ int xe_bo_dumb_create(struct drm_file 
>>> *file_priv,
>>>       struct xe_device *xe = to_xe_device(dev);
>>>       struct xe_bo *bo;
>>>       uint32_t handle;
>>> -    int cpp = DIV_ROUND_UP(args->bpp, 8);
>>>       int err;
>>>       u32 page_size = max_t(u32, PAGE_SIZE,
>>>           xe->info.vram_flags & XE_VRAM_FLAGS_NEED64K ? SZ_64K : SZ_4K);
>>>   -    args->pitch = ALIGN(args->width * cpp, 64);
>>> -    args->size = ALIGN(mul_u32_u32(args->pitch, args->height),
>>> -               page_size);
>>> +    err = drm_mode_size_dumb(dev, args, SZ_64, page_size);
>>
>> AFAICT this looks to change the behaviour, where u64 size was 
>> technically possible and was allowed given that args->size is u64, but 
>> this helper is limiting the size to u32. Is that intentional? If so, 
>> we should probably make that clear in the commit message.
> 
> That's an interesting observation; thanks. The ioctl's internal checks 
> have always limited the size to 32 bit. [1] I think it is not supposed 
> to be larger than that. We can change the helper to support 64-bit sizes 
> as well.

Ah, I missed the internal check.

> 
> Having said that, is there any use case? Dumb buffers are for software 
> rendering only. Allocating more than a few dozen MiB seems like a 
> mistake. Maybe we should rather limit the allowed allocation size instead?

Yeah, I doubt there are any real users. Given the existing internal 
check, limiting to u32 makes sense to me.

> 
> Best regards
> Thomas
> 
> [1] https://elixir.bootlin.com/linux/v6.12.6/source/drivers/gpu/drm/ 
> drm_dumb_buffers.c#L82
> 
>>
>>> +    if (err)
>>> +        return err;
>>>         bo = xe_bo_create_user(xe, NULL, NULL, args->size,
>>>                      DRM_XE_GEM_CPU_CACHING_WC,
>>
> 



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 17:34:04 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 17:34:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869040.1280547 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVwPj-0003uS-Nn; Thu, 09 Jan 2025 17:33:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869040.1280547; Thu, 09 Jan 2025 17:33:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVwPj-0003uL-KI; Thu, 09 Jan 2025 17:33:47 +0000
Received: by outflank-mailman (input) for mailman id 869040;
 Thu, 09 Jan 2025 17:33: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
 <SRS0=wq9x=UB=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tVwPi-0003uF-5Z
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 17:33:46 +0000
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
 [2a00:1450:4864:20::531])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e027a893-ceaf-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 18:33:44 +0100 (CET)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-5d7e527becaso1775663a12.3
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 09:33:44 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d99046dbe0sm763662a12.64.2025.01.09.09.33.43
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 09 Jan 2025 09:33:43 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e027a893-ceaf-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736444024; x=1737048824; 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=JzKhBI1cXTVoa2sd7mMp06AWWNZGyM+8VilnqPMT/Co=;
        b=rSAh/eV+SI4uKM0S9yaVXIZgPwPsHBWVuLTTFHHGZNv7OY3OFoYQsMz8OX6rDWJkKc
         814iHMaquY/7+tz5/lIQfmric3CmP6rE7G36ZdB1MFFn4ZhHnzFhCKg+soL9lEIgcxZY
         z+/aS+m7vrPX9I5QcEYUDZA1qnszmK63r47Ss=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736444024; x=1737048824;
        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=JzKhBI1cXTVoa2sd7mMp06AWWNZGyM+8VilnqPMT/Co=;
        b=psHQhi4iz3uosRiyglwY6KypU94bzk2V73VZ9Bfx0SGgP7MHpOSrmWFu0cASoQgsoA
         GwddisW2sewhEWuY5909Cnt5+K8Nk4lAWcW4nDsxOucDzAGSP6prmkzYNUjGw1bI52i7
         M0mhCS6jTCXf+/VWoS7ygtPWvPO8z74GSzzGozdsGi93HKjzcAZi8l8wejQ++QueWYTK
         lPlbXKe/NUqkhKcKk6wkXjYIecR1pL08+lAodx+jtmiJJwsfbAIPSEPG6zLOCp/Bv/yQ
         xdCFbjiQ4RC5h0aqIhOkFoTzYjnVwNCSiGy55lIqE0ilHbLUYeODwQVUk7fsmS6bCdMO
         6yeg==
X-Forwarded-Encrypted: i=1; AJvYcCUhrjAykdhETFYWkCKc/rkYVJAeUIYuSaj8dGBWud7AtqUf5d4XhhWQWAgugt0TmKQyUokBgyPd8ys=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwAcdetttsgxmtwTsHL4WQIk+JIpXvOJy16oVlIpunDSMAsgAmr
	gu4URu+09wHZXLMo85JX+RciL1VpaXQEbiu4EclxqyeBMi/izMdkM8bSVUQK0j4=
X-Gm-Gg: ASbGncttKBMKwACxjGSW2ks0P8m39saa5aGGBIdnf1QZA11CvxipUIx3yRMoPuv8xsB
	YOsXOY2zKyf4SpI5319Pe4NIUTBsqAwfp+aX4cy7fQX+2RmMN2JilBoDPDXRxNpR4IYODMN4gCM
	w1g7T6EmIOBF/LziHYlaS8PXUotLMLURpsCZtmwzGmKUPllgy70IMziIpu4rJrMx6fdD3ko3esp
	cseTjClV2KAZDfkB8itjKMLBhh7tnWxZjvcnm0kIzkyWOgmR76OYVEkAO7yULNRehA=
X-Google-Smtp-Source: AGHT+IG632Ne3S+9lQD60z67EMLW4FmqW81RFNEMU7s1mI5XDYP6woETVH2JPOa3se1waIp0qiWkRg==
X-Received: by 2002:a05:6402:400a:b0:5d2:7199:ac2 with SMTP id 4fb4d7f45d1cf-5d972e00032mr17291084a12.2.1736444024071;
        Thu, 09 Jan 2025 09:33:44 -0800 (PST)
Date: Thu, 9 Jan 2025 18:33:42 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 02/18] x86/domain: limit window where curr_vcpu !=
 current on context switch
Message-ID: <Z4AIdlx7uWcS3cOP@macbook.local>
References: <20250108142659.99490-1-roger.pau@citrix.com>
 <20250108142659.99490-3-roger.pau@citrix.com>
 <46cb0ee0-ea9f-4515-abac-058a9aa846e4@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <46cb0ee0-ea9f-4515-abac-058a9aa846e4@suse.com>

On Thu, Jan 09, 2025 at 09:59:58AM +0100, Jan Beulich wrote:
> On 08.01.2025 15:26, Roger Pau Monne wrote:
> > On x86 Xen will perform lazy context switches to the idle vCPU, where the
> > previously running vCPU context is not overwritten, and only current is updated
> > to point to the idle vCPU.  The state is then disjunct between current and
> > curr_vcpu: current points to the idle vCPU, while curr_vcpu points to the vCPU
> > whose context is loaded on the pCPU.
> > 
> > While on that lazy context switched state, certain calls (like
> > map_domain_page()) will trigger a full synchronization of the pCPU state by
> > forcing a context switch.  Note however how calling any of such functions
> > inside the context switch code itself is very likely to trigger an infinite
> > recursion loop.
> > 
> > Attempt to limit the window where curr_vcpu != current in the context switch
> > code, as to prevent and infinite recursion loop around sync_local_execstate().
> > 
> > This is required for using map_domain_page() in the vCPU context switch code,
> > otherwise using map_domain_page() in that context ends up in a recursive
> > sync_local_execstate() loop:
> 
> Question is whether it's a good idea in the first place to start using
> map_domain_page() from the context switch path. Surely there are possible
> alternatives.

It seemed more natural rather the introducing yet something new to use
in the context switch path.  I'm happy to hear recommendations, but
overall introducing yet another interface to map stuff just for the
context switch path seems worse than extending an existing interface
to work in that context.

> > --- a/xen/arch/x86/domain.c
> > +++ b/xen/arch/x86/domain.c
> > @@ -1982,16 +1982,16 @@ static void load_default_gdt(unsigned int cpu)
> >      per_cpu(full_gdt_loaded, cpu) = false;
> >  }
> >  
> > -static void __context_switch(void)
> > +static void __context_switch(struct vcpu *n)
> >  {
> >      struct cpu_user_regs *stack_regs = guest_cpu_user_regs();
> >      unsigned int          cpu = smp_processor_id();
> >      struct vcpu          *p = per_cpu(curr_vcpu, cpu);
> > -    struct vcpu          *n = current;
> >      struct domain        *pd = p->domain, *nd = n->domain;
> >  
> >      ASSERT(p != n);
> >      ASSERT(!vcpu_cpu_dirty(n));
> > +    ASSERT(p == current);
> >  
> >      if ( !is_idle_domain(pd) )
> >      {
> > @@ -2036,6 +2036,18 @@ static void __context_switch(void)
> >  
> >      write_ptbase(n);
> >  
> > +    /*
> > +     * It's relevant to set both current and curr_vcpu back-to-back, to avoid a
> > +     * window where calls to mapcache_current_vcpu() during the context switch
> > +     * could trigger a recursive loop.
> > +     *
> > +     * Do the current switch immediately after switching to the new guest
> > +     * page-tables, so that current is (almost) always in sync with the
> > +     * currently loaded page-tables.
> > +     */
> > +    set_current(n);
> > +    per_cpu(curr_vcpu, cpu) = n;
> 
> The latter paragraph of the comment states something that so far wasn't intended,
> and imo also shouldn't be going forward. It's curr_vcpu which wants to be in sync
> with the loaded page tables. (Whether pulling ahead its updating is okay is a
> separate question. All of these actions used to be be very carefully placed they
> way they are. Which isn't to say that I can exclude things having gone stale ...)

I've noticed this was all quite carefully placed.  I've also attempted
to take care with the changes I've done here (and tested them
extensively).

> And yes, that has always meant that mapcache_current_vcpu()'s condition for
> calling sync_local_execstate() was building upon the fact that it won't be called
> from context switching contexts.
> 
> Did you consider updating that condition (evaluating curr_cpu) instead?

We cannot safely use map_domain_page() if current != curr_vcpu,
because at any point (as a result of an interrupt) a call to
sync_local_execstate(), and thus remove the mappings created by
map_domain_page() as a result of performing a full context switch to
the idle vCPU (and the idle vCPU page tables).

> 
> > @@ -2048,8 +2060,6 @@ static void __context_switch(void)
> >      if ( pd != nd )
> >          cpumask_clear_cpu(cpu, pd->dirty_cpumask);
> >      write_atomic(&p->dirty_cpu, VCPU_CPU_CLEAN);
> > -
> > -    per_cpu(curr_vcpu, cpu) = n;
> >  }
> >  
> >  void context_switch(struct vcpu *prev, struct vcpu *next)
> > @@ -2081,16 +2091,36 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
> >  
> >      local_irq_disable();
> >  
> > -    set_current(next);
> > -
> >      if ( (per_cpu(curr_vcpu, cpu) == next) ||
> >           (is_idle_domain(nextd) && cpu_online(cpu)) )
> >      {
> > +        /*
> > +         * Lazy context switch to the idle vCPU, set current == idle.  Full
> > +         * context switch happens if/when sync_local_execstate() is called.
> > +         */
> > +        set_current(next);
> >          local_irq_enable();
> 
> The comment is misleading as far as the first half of the if() condition goes:
> No further switching is going to happen in that case, aiui.

Right, I should clarify that comment: this is either a lazy context
switch, or the return from a lazy state to the previously running
vCPU.

> >      }
> >      else
> >      {
> > -        __context_switch();
> > +        /*
> > +         * curr_vcpu will always point to the currently loaded vCPU context, as
> > +         * it's not updated when doing a lazy switch to the idle vCPU.
> > +         */
> > +        struct vcpu *prev_ctx = per_cpu(curr_vcpu, cpu);
> > +
> > +        if ( prev_ctx != current )
> > +        {
> > +            /*
> > +             * Doing a full context switch to a non-idle vCPU from a lazy
> > +             * context switched state.  Adjust current to point to the
> > +             * currently loaded vCPU context.
> > +             */
> > +            ASSERT(current == idle_vcpu[cpu]);
> > +            ASSERT(!is_idle_vcpu(next));
> > +            set_current(prev_ctx);
> 
> This feels wrong, as in "current" then not representing what it should represent,
> for a certain time window. I may be dense, but neither comment not description
> clarify to me why this might be needed. I can see that it's needed to please the
> ASSERT() you add to __context_switch(), yet then I might ask why that assertion
> is put there.

This is done so that when calling __context_switch() current ==
curr_vcpu, and map_domain_page() can be used without getting into an
infinite sync_local_execstate() recursion loop.

> 
> > +        }
> > +        __context_switch(next);
> >  
> >          /* Re-enable interrupts before restoring state which may fault. */
> >          local_irq_enable();
> > @@ -2156,15 +2186,23 @@ int __sync_local_execstate(void)
> >  {
> >      unsigned long flags;
> >      int switch_required;
> > +    unsigned int cpu = smp_processor_id();
> > +    struct vcpu *p;
> >  
> >      local_irq_save(flags);
> >  
> > -    switch_required = (this_cpu(curr_vcpu) != current);
> > +    p = per_cpu(curr_vcpu, cpu);
> > +    switch_required = (p != current);
> >  
> >      if ( switch_required )
> >      {
> > -        ASSERT(current == idle_vcpu[smp_processor_id()]);
> > -        __context_switch();
> > +        ASSERT(current == idle_vcpu[cpu]);
> > +        /*
> > +         * Restore current to the previously running vCPU, __context_switch()
> > +         * will update current together with curr_vcpu.
> > +         */
> > +        set_current(p);
> 
> Similarly here.

Same reason, so that when calling __context_switch() current ==
curr_vcpu and map_domain_page() can be used (and in general
sync_local_execstate() becomes a no-op because a switch is already in
process.)

> 
> > +        __context_switch(idle_vcpu[cpu]);
> >      }
> >  
> >      local_irq_restore(flags);
> > --- a/xen/arch/x86/traps.c
> > +++ b/xen/arch/x86/traps.c
> > @@ -2232,8 +2232,6 @@ void __init trap_init(void)
> >  
> >  void activate_debugregs(const struct vcpu *curr)
> >  {
> > -    ASSERT(curr == current);
> > -
> >      write_debugreg(0, curr->arch.dr[0]);
> >      write_debugreg(1, curr->arch.dr[1]);
> >      write_debugreg(2, curr->arch.dr[2]);
> 
> Why would this assertion go away? If it suddenly triggers, the parameter name
> would now end up being wrong.

Well, at the point where activate_debugregs() gets called (in
paravirt_ctxt_switch_to()), current == previous as a result of this
change, so the assert is no longer true on purpose on that call
path.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 17:39:10 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 17:39:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869049.1280557 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVwUr-0006J3-9c; Thu, 09 Jan 2025 17:39:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869049.1280557; Thu, 09 Jan 2025 17:39:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVwUr-0006Iw-6P; Thu, 09 Jan 2025 17:39:05 +0000
Received: by outflank-mailman (input) for mailman id 869049;
 Thu, 09 Jan 2025 17:39:04 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=wq9x=UB=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tVwUq-0006I8-D7
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 17:39:04 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9e09c4c7-ceb0-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 18:39:03 +0100 (CET)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-5d8c1950da7so1909538a12.3
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 09:39:03 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d9900c3fccsm784206a12.21.2025.01.09.09.39.01
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 09 Jan 2025 09:39:02 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9e09c4c7-ceb0-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736444343; x=1737049143; 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=JywzAdE153bhRxUOUqrnlFE1jMhv4h4kJaSzC2+0ptE=;
        b=sZs8YHPKjzzaDBxIrsW/g1OgLb2vKDawJ5G2735Wmx9JGgv+SK2P3cK9Kiwyvh+pkF
         IDVUM+jnRwKrm0FWI7ITxrd69QxFL1DofXwua3pnpUimOZDhh/L1vsvBn8LQMQUOG4Vd
         aYVbtO5nhRwwgdIANMOcCVkc4jnaODn1LukhI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736444343; x=1737049143;
        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=JywzAdE153bhRxUOUqrnlFE1jMhv4h4kJaSzC2+0ptE=;
        b=mUjSjonbQl7HKA0damkRLq68zDS0DUn251/jRq+lRkVUWpMVLS3iDxQ3YuftB2dlEV
         q1zToIAhbuwkiL6/jsE/CIdJRuMDAcRcFDDYgPILmQGuxAbju85mmD4sYe2TElExHVIC
         tSVwJh2xOzjS30LN1FqYUuOl8O6B5VEkrWRBwnM+QAriTwMJJfAnLkCIUwajH0G6Pgg2
         tkDzKnjoVwzZARdoOXmV8gP5xDpZEU8KsTb0p69uLhwiYt6EfQQBB/w/odPuODQTq24e
         AceHVKLE9mH98VT7bCmEACp9c+oeP4CHldnr9I0xhRohTrWZ/iCn9fEyleoDO+MihvKu
         cB4w==
X-Gm-Message-State: AOJu0YwXFzMGMmkj3VEYf6EwBejXjjkOpAClFd32J4yWlkLwWdhycuMG
	GeqCEGpzdfB99P1XFVG14JqH/bRuNJr/Avj02J6PadRZwQhv56ZDgsAEoDYMHn8p9rT4sdIZ2g6
	V
X-Gm-Gg: ASbGncuU6TxhiQJNDzbsEEIqSUCOWzupJ4v8dBG7+megM5YFkhu+ZxEDBSuo5GBszNs
	fPuTURdHA6idx5vAPDXJNLlgkSMrhWEbMzSCbR3pCf1Xosvvpcx0yANOgrGk0+oT8OpcAGEYdPl
	zgZmLMW5OIeUQ/dglmtOaUcz09MSejXXC8yUagG7uI9Sg2UKAB7qeLsSB85qyrgmEAbkf0MHo3t
	grCfM/yEtv2Wh1C5CAHnohvM6gTglqyv0RZVTwb2Px4InMVMOsYDRHCH8PrSgRkh2Y=
X-Google-Smtp-Source: AGHT+IHLtagGuUDLtnzPNVr6lmDNNFShks4lLDJJsPK1kaVKwe0q6t8NWsFfCbbtJwjpLXYhrLKQ4A==
X-Received: by 2002:a05:6402:2790:b0:5d4:5e4:1555 with SMTP id 4fb4d7f45d1cf-5d972e148dbmr7183201a12.19.1736444342707;
        Thu, 09 Jan 2025 09:39:02 -0800 (PST)
Date: Thu, 9 Jan 2025 18:39:01 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Alejandro Vallejo <alejandro.vallejo@cloud.com>
Cc: xen-devel@lists.xenproject.org, Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v2 02/18] x86/domain: limit window where curr_vcpu !=
 current on context switch
Message-ID: <Z4AJtZhIrRK4vQoe@macbook.local>
References: <20250108142659.99490-1-roger.pau@citrix.com>
 <20250108142659.99490-3-roger.pau@citrix.com>
 <D6WTZES0WLY8.3QDZ5BCM7CEIX@cloud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <D6WTZES0WLY8.3QDZ5BCM7CEIX@cloud.com>

On Wed, Jan 08, 2025 at 04:26:46PM +0000, Alejandro Vallejo wrote:
> This is a net gain even without ASI. Having "current" hold the previous vCPU on
> __context_switch() makes it _a lot_ easier to follow the lazy switch path.
> 
> On Wed Jan 8, 2025 at 2:26 PM GMT, Roger Pau Monne wrote:
> > On x86 Xen will perform lazy context switches to the idle vCPU, where the
> > previously running vCPU context is not overwritten, and only current is updated
> > to point to the idle vCPU.  The state is then disjunct between current and
> > curr_vcpu: current points to the idle vCPU, while curr_vcpu points to the vCPU
> > whose context is loaded on the pCPU.
> >
> > While on that lazy context switched state, certain calls (like
> > map_domain_page()) will trigger a full synchronization of the pCPU state by
> > forcing a context switch.  Note however how calling any of such functions
> > inside the context switch code itself is very likely to trigger an infinite
> > recursion loop.
> >
> > Attempt to limit the window where curr_vcpu != current in the context switch
> > code, as to prevent and infinite recursion loop around sync_local_execstate().
> >
> > This is required for using map_domain_page() in the vCPU context switch code,
> > otherwise using map_domain_page() in that context ends up in a recursive
> > sync_local_execstate() loop:
> >
> > map_domain_page() -> sync_local_execstate() -> map_domain_page() -> ...
> 
> More generally, it's worth mentioning that we want to establish an invariant
> between a per-cpu variable (curr_vcpu) and the currently running page tables.
> That way it can be used as discriminant to know which are the currently active
> per-vCPU mappings.

You kind of already do this by checking curr_vcpu, as with this
changes there's still a window where the vCPU is lazy context
switched, and hence current != curr_vcpu (and curr_vcpu should signal
what page-tables are loaded).

The main point apart from more accurate signaling of the loaded
page-tables is to avoid infinite recursion if sync_local_execstate()
is called inside the context switch path.

> That's essential for implementing FPU hiding as proposed here:
> 
>   https://lore.kernel.org/xen-devel/20241105143310.28301-1-alejandro.vallejo@cloud.com/
> 
> A shorter form of that should probably be mentioned also...
> 
> >
> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> > ---
> > Changes since v1:
> >  - New in this version.
> > ---
> >  xen/arch/x86/domain.c | 58 +++++++++++++++++++++++++++++++++++--------
> >  xen/arch/x86/traps.c  |  2 --
> >  2 files changed, 48 insertions(+), 12 deletions(-)
> >
> > diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> > index 78a13e6812c9..1f680bf176ee 100644
> > --- a/xen/arch/x86/domain.c
> > +++ b/xen/arch/x86/domain.c
> > @@ -1982,16 +1982,16 @@ static void load_default_gdt(unsigned int cpu)
> >      per_cpu(full_gdt_loaded, cpu) = false;
> >  }
> >  
> > -static void __context_switch(void)
> > +static void __context_switch(struct vcpu *n)
> >  {
> >      struct cpu_user_regs *stack_regs = guest_cpu_user_regs();
> >      unsigned int          cpu = smp_processor_id();
> >      struct vcpu          *p = per_cpu(curr_vcpu, cpu);
> > -    struct vcpu          *n = current;
> >      struct domain        *pd = p->domain, *nd = n->domain;
> >  
> >      ASSERT(p != n);
> >      ASSERT(!vcpu_cpu_dirty(n));
> > +    ASSERT(p == current);
> >  
> >      if ( !is_idle_domain(pd) )
> >      {
> > @@ -2036,6 +2036,18 @@ static void __context_switch(void)
> >  
> >      write_ptbase(n);
> >  
> > +    /*
> > +     * It's relevant to set both current and curr_vcpu back-to-back, to avoid a
> > +     * window where calls to mapcache_current_vcpu() during the context switch
> > +     * could trigger a recursive loop.
> > +     *
> > +     * Do the current switch immediately after switching to the new guest
> > +     * page-tables, so that current is (almost) always in sync with the
> > +     * currently loaded page-tables.
> > +     */
> > +    set_current(n);
> > +    per_cpu(curr_vcpu, cpu) = n;
> 
> ... here. So we're not tempted to move these 2 far off from write_ptbase().

I think the "Do the current switch immediately after switching to the
new guest page-tables" sentence already signals that it's important to
keep the setting of current and curr_vcpu as close to the
write_ptbase() call as possible, but I'm open to suggestions for
better wording.

> > +
> >  #ifdef CONFIG_PV
> >      /* Prefetch the VMCB if we expect to use it later in the context switch */
> >      if ( using_svm() && is_pv_64bit_domain(nd) && !is_idle_domain(nd) )
> > @@ -2048,8 +2060,6 @@ static void __context_switch(void)
> >      if ( pd != nd )
> >          cpumask_clear_cpu(cpu, pd->dirty_cpumask);
> >      write_atomic(&p->dirty_cpu, VCPU_CPU_CLEAN);
> > -
> > -    per_cpu(curr_vcpu, cpu) = n;
> >  }
> >  
> >  void context_switch(struct vcpu *prev, struct vcpu *next)
> > @@ -2081,16 +2091,36 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
> >  
> >      local_irq_disable();
> >  
> > -    set_current(next);
> > -
> >      if ( (per_cpu(curr_vcpu, cpu) == next) ||
> >           (is_idle_domain(nextd) && cpu_online(cpu)) )
> >      {
> > +        /*
> > +         * Lazy context switch to the idle vCPU, set current == idle.  Full
> > +         * context switch happens if/when sync_local_execstate() is called.
> > +         */
> > +        set_current(next);
> >          local_irq_enable();
> >      }
> >      else
> >      {
> > -        __context_switch();
> > +        /*
> > +         * curr_vcpu will always point to the currently loaded vCPU context, as
> 
> nit: s/will always point/always points/ ? It's an inconditional invariant,
> after all.

Sure.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 17:51:31 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 17:51:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869064.1280566 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVwgn-0004xc-Ak; Thu, 09 Jan 2025 17:51:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869064.1280566; Thu, 09 Jan 2025 17:51:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVwgn-0004xV-7r; Thu, 09 Jan 2025 17:51:25 +0000
Received: by outflank-mailman (input) for mailman id 869064;
 Thu, 09 Jan 2025 17:51:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=OfsQ=UB=cloud.com=frediano.ziglio@srs-se1.protection.inumbo.net>)
 id 1tVwgm-0004xP-Dd
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 17:51:24 +0000
Received: from mail-oa1-x35.google.com (mail-oa1-x35.google.com
 [2001:4860:4864:20::35])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 55f1ad4e-ceb2-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 18:51:22 +0100 (CET)
Received: by mail-oa1-x35.google.com with SMTP id
 586e51a60fabf-2a7ccb2c618so627958fac.2
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 09:51:22 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 55f1ad4e-ceb2-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736445081; x=1737049881; 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=XPqu2fRRv0rcK37Sh0o8ER+89uB3jH6MwdVNpQzD1Iw=;
        b=PeNZMgyCBu4RWGp5bUxEPjJnQVsHkqg96M150e7qmPyXggTYezjT6jWdkH0FjHi5KS
         dwYsytwjqUoMKCjavfdVy5zXCiF0OyamPbzts/Dd5Mapi5usM8PB1B02RBbX5XfEEy/H
         tjPejrQKty+AYOdwDpMBYcW2ZOf6jSdQ4kb6U=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736445081; x=1737049881;
        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=XPqu2fRRv0rcK37Sh0o8ER+89uB3jH6MwdVNpQzD1Iw=;
        b=cDR1riAIsHYqmFCPVtW0SE6IxJOb3ms8eiZEevBY6ZaOCmrXxj8Z+skxm4UYWvTY/L
         3tJbVQOFZlqDsnCrETsHHhrxnteTUGdsXwLoulVMdEA8nSsIrtqU57J71E7z/UFQO1SX
         cItAByY/PRfwYnDTpe5wBRTq1bwBQ6kCCpCQiIPEJWsoQmsVhgMV46NMlj8CT6hy2y3p
         Ir3YavFK5u/JiK0wX4qEnXV4CEy9zQ0S1ExQQcdQrpKZcRujofPql1eesfUk1QN5TObf
         fPYVR/q9hPyiYOQfue+Pn1lk3kyK8vDcpopTHDmWoHWspXshkZ1Xv/sOSt0K6F2U4MEA
         WxTg==
X-Forwarded-Encrypted: i=1; AJvYcCX5TO+pdtrHA/cPTvhTim3FdYkZjGuJQh0Y3sXrqDFUbvMSZFAHvOIMMCMVAfp6AvzG2xowKbzgZvQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzakQzoVUE6wervrqB1Xaw96/XGK31pHtYyB3vyXoVCHTIjGfVA
	XSQtKm/Udix+ludykp6V0OZURXc/W52HRflFKhXNbO9e1u52uykNu3ow4Xs6uQau+W1WUfKkW7Q
	l0LvR0P2aA7DfS7XiyzU2aS17/8JifJn+f0r5Cw==
X-Gm-Gg: ASbGncs2cjzFuhcOpvMrW0JrVjqSLWNeHSwJQG+Bl7z496mmBdoeTRBt22dRgo7skpI
	DBHzYx01g7jlc8mrspAjnkKd6VTn1V3h5uCG9
X-Google-Smtp-Source: AGHT+IFhT9u8LxvSlR8/dyau0g+emlJTE5xSPO4iK1LdQj7klaRnotVnc9NUHJuW9IACt3fVTPeiQdneFdSKXh9FOq4=
X-Received: by 2002:a05:6870:2dc9:b0:29e:5f1f:152d with SMTP id
 586e51a60fabf-2aa06523f1bmr4039766fac.8.1736445080785; Thu, 09 Jan 2025
 09:51:20 -0800 (PST)
MIME-Version: 1.0
References: <20250109131515.1757764-1-marmarek@invisiblethingslab.com>
 <d7421558-c2d6-485b-96bf-927992c5c066@suse.com> <47378338-ac05-4041-a055-56045e5ba131@citrix.com>
 <CACHz=ZjR6dSy_NsrXkhf_VfZpGYE4et6VkQvU_cO9DdAnXBzxQ@mail.gmail.com> <689e4152-b48b-4808-a407-6c33e6e071e0@citrix.com>
In-Reply-To: <689e4152-b48b-4808-a407-6c33e6e071e0@citrix.com>
From: Frediano Ziglio <frediano.ziglio@cloud.com>
Date: Thu, 9 Jan 2025 17:51:09 +0000
X-Gm-Features: AbW1kvZISLWkjGml4zU4US40joRhgRBZiB67PQahw-3T6uJhjuBQN2eKM6WKhMc
Message-ID: <CACHz=ZgL8xnT1cX+mo-YG0opGvzPNpWQgmLL5XE0rTHA6AZuQw@mail.gmail.com>
Subject: Re: [PATCH] x86/boot: adjust text gap/diff to work with 64-bytes
 alignment too
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>, 
	=?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= <marmarek@invisiblethingslab.com>, 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
	xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 9, 2025 at 4:03=E2=80=AFPM Andrew Cooper <andrew.cooper3@citrix=
.com> wrote:
>
> On 09/01/2025 3:30 pm, Frediano Ziglio wrote:
> > On Thu, Jan 9, 2025 at 1:44=E2=80=AFPM Andrew Cooper <andrew.cooper3@ci=
trix.com> wrote:
> >> On 09/01/2025 1:23 pm, Jan Beulich wrote:
> >>> On 09.01.2025 14:15, Marek Marczykowski-G=C3=B3recki wrote:
> >>>> Xen compiled with -mtune=3Dgeneric has .text alignment set to 64-byt=
es.
> >>>> Having text_diff non-64-bytes-aligned breaks stuff:
> >>>>
> >>>>     Traceback (most recent call last):
> >>>>       File "/builddir/build/BUILD/xen-4.20.0-build/xen-4.20.0-rc0/xe=
n/./tools/combine_two_binaries.py", line 96, in <module>
> >>>>         raise Exception('File sizes do not match')
> >>>>     Exception: File sizes do not match: 70160 !=3D 4080 + 66048
> >>>>
> >>>> Adjust the numbers as suggested by Frediano to work with 64-bytes an=
d
> >>>> even 128-bytes alignment.
> >>> And then breaking at 256? As indicated on Matrix, imo we should be ab=
le to
> >>> cope with anything up to at least PAGE_SIZE. Or we should reduce .tex=
t
> >>> alignment before linking.
> >> Do you have a concrete proposal on how to do this?
> >>
> >> Because if not, we've had 2 downstreams hit by this build failure, and
> >> we probably ought to take this patch as a stopgap fix, and see about
> >> doing the better fix for 4.20.
> >>
> > I agree with this, merge this and then leave the improvements for follo=
w up(s).
> >
> > Yesterday I checked the output object file (built-in-32.o) to find
> > that the output alignment is 1 byte, which is obviously wrong!
>
> No so.  It's perfectly easy to end up with 1 byte alignment on .text,
> commonly with -Os.
>
> e.g. In my build, reloc-trampoline.32.o has:
>
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>   0 .group        00000008  00000000  00000000  00000034  2**2
>                   CONTENTS, READONLY, GROUP, LINK_ONCE_DISCARD
>   1 .text         00000076  00000000  00000000  0000003c  2**0
>                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
>   2 .data         00000000  00000000  00000000  000000b2  2**0
>                   CONTENTS, ALLOC, LOAD, DATA
>   3 .bss          00000000  00000000  00000000  000000b2  2**0
>                   ALLOC
>   4 .text.__x86.get_pc_thunk.bx 00000004  00000000  00000000  000000b2  2=
**0
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>   5 .comment      00000020  00000000  00000000  000000b6  2**0
>                   CONTENTS, READONLY
>   6 .note.GNU-stack 00000000  00000000  00000000  000000d6  2**0
>                   CONTENTS, READONLY
>
> and this is entirely reasonable IMO.
>
> That said, the fact that built-in-32.S does not have at least one .align
> directive probably is an issue.
>
> x86 will cope, and there's nothing interesting in this code that's going
> to choke on being misaligned.
>

What about something like
https://github.com/freddy77/xen/commit/299a1fd70a84e9b52b84d59daff6878a3c42=
a595
?

Frediano


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 18:06:17 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 18:06:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869076.1280577 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVwv4-0003VK-Ml; Thu, 09 Jan 2025 18:06:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869076.1280577; Thu, 09 Jan 2025 18:06:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVwv4-0003VD-J2; Thu, 09 Jan 2025 18:06:10 +0000
Received: by outflank-mailman (input) for mailman id 869076;
 Thu, 09 Jan 2025 18:06:09 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=wQIl=UB=kernel.org=song@srs-se1.protection.inumbo.net>)
 id 1tVwv3-0003V4-3T
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 18:06:09 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org
 [2604:1380:45d1:ec00::3])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 647d5c37-ceb4-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 19:06:05 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id A0981A4253D
 for <xen-devel@lists.xenproject.org>; Thu,  9 Jan 2025 18:04:15 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id C9561C4CEE6
 for <xen-devel@lists.xenproject.org>; Thu,  9 Jan 2025 18:06:03 +0000 (UTC)
Received: by mail-io1-f43.google.com with SMTP id
 ca18e2360f4ac-844e10ef3cfso79573939f.2
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 10:06:03 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 647d5c37-ceb4-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1736445963;
	bh=rp9xKD+8m1msQ0xxbCs9oZzFyU1GURrqUZhq3NbpvyQ=;
	h=References:In-Reply-To:From:Date:Subject:To:Cc:From;
	b=hXJVC9TEna9TWYKbS9F02aIUvOHalq4E7m1+cvMk0ArDdbnyNkOQeESQ7Ur7QTEYq
	 oV3fJnNHiU6ugTU9/tuOjHdJ9qaR831jsML8BcJ2B2+uzRQfA4kpmr3AmZ+XqRvw70
	 BTN8HX8ggLtR2WOIhN2X2Ipa4OKa5qs1wwTNGfy1p+9su4jHqsiWIAwGFmgaxU7Nfw
	 H9Abn1fQ/2SPP2QU6lVw0EYHITfjtwSWp9wIQJbaVZRVNv4TDYE1jWwRNuescPEqI8
	 vYK392uOFALwuMqP1HoC1bERclFcBuYV7fmAeGJqkaXECHPwUoHQw9LVho0fFgK9tk
	 fJ+fXn+JQWXLQ==
X-Forwarded-Encrypted: i=1; AJvYcCWZSQW5bk4oATLhvsc1oDyAnG1SwggSZo+AjYaf7Tg3MeGsPkEhsm+TkHF+f7J+KN/272LGX/BIdhU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzMlj+KvnQUV6T0abWrcFY0Fw84zaMPJDbfpx0bBDelusJm2pzv
	U24/UAQgp8yxrrWsdL5LV9WqfVHsujQAS1Y8xVKZamP7XnuEtS6lEbKymrJa3aMwCH56mmGfeQq
	xpc0pXK8aK+NioK5eof0cjFQkOco=
X-Google-Smtp-Source: AGHT+IHw82IqZn0L3vIWI2GRAE2/Fu1vkOzFuTOkK3ccul7HxPp7E2ac95iMCNTUN8mztI4YyZ2Kf9FZUsicSlonzfg=
X-Received: by 2002:a05:6e02:3048:b0:3a7:6a98:3fdf with SMTP id
 e9e14a558f8ab-3ce3a9da817mr60484875ab.14.1736445963152; Thu, 09 Jan 2025
 10:06:03 -0800 (PST)
MIME-Version: 1.0
References: <20250109-jag-ctl_table_const-v1-1-622aea7230cf@kernel.org>
In-Reply-To: <20250109-jag-ctl_table_const-v1-1-622aea7230cf@kernel.org>
From: Song Liu <song@kernel.org>
Date: Thu, 9 Jan 2025 10:05:51 -0800
X-Gmail-Original-Message-ID: <CAPhsuW5zpA28gkBQYMMuYCUbnDzdeq4pHsd0Mx=PBnDPiHKqHw@mail.gmail.com>
X-Gm-Features: AbW1kvZZD8oqcdTZ9DXv7tEUC7bpyqeBsuw6nnhXboAE2kNg_1eTiibnv93HXj8
Message-ID: <CAPhsuW5zpA28gkBQYMMuYCUbnDzdeq4pHsd0Mx=PBnDPiHKqHw@mail.gmail.com>
Subject: Re: [PATCH] treewide: const qualify ctl_tables where applicable
To: Joel Granados <joel.granados@kernel.org>
Cc: =?UTF-8?Q?Thomas_Wei=C3=9Fschuh?= <linux@weissschuh.net>, 
	Kees Cook <kees@kernel.org>, Luis Chamberlain <mcgrof@kernel.org>, 
	linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, 
	linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, 
	linux-s390@vger.kernel.org, linux-crypto@vger.kernel.org, 
	openipmi-developer@lists.sourceforge.net, intel-gfx@lists.freedesktop.org, 
	dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org, 
	linux-hyperv@vger.kernel.org, linux-rdma@vger.kernel.org, 
	linux-raid@vger.kernel.org, linux-scsi@vger.kernel.org, 
	linux-serial@vger.kernel.org, xen-devel@lists.xenproject.org, 
	linux-aio@kvack.org, linux-fsdevel@vger.kernel.org, netfs@lists.linux.dev, 
	codalist@coda.cs.cmu.edu, linux-mm@kvack.org, linux-nfs@vger.kernel.org, 
	ocfs2-devel@lists.linux.dev, fsverity@lists.linux.dev, 
	linux-xfs@vger.kernel.org, io-uring@vger.kernel.org, bpf@vger.kernel.org, 
	kexec@lists.infradead.org, linux-trace-kernel@vger.kernel.org, 
	linux-hardening@vger.kernel.org, apparmor@lists.ubuntu.com, 
	linux-security-module@vger.kernel.org, keyrings@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 9, 2025 at 5:16=E2=80=AFAM Joel Granados <joel.granados@kernel.=
org> wrote:
>
[...]
>  drivers/base/firmware_loader/fallback_table.c | 2 +-
>  drivers/cdrom/cdrom.c                         | 2 +-
>  drivers/char/hpet.c                           | 2 +-
>  drivers/char/ipmi/ipmi_poweroff.c             | 2 +-
>  drivers/char/random.c                         | 2 +-
>  drivers/gpu/drm/i915/i915_perf.c              | 2 +-
>  drivers/gpu/drm/xe/xe_observation.c           | 2 +-
>  drivers/hv/hv_common.c                        | 2 +-
>  drivers/infiniband/core/iwcm.c                | 2 +-
>  drivers/infiniband/core/ucma.c                | 2 +-
>  drivers/macintosh/mac_hid.c                   | 2 +-
>  drivers/md/md.c                               | 2 +-

For md bits:

Reviewed-by: Song Liu <song@kernel.org>

Thanks,
Song

[...]


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 18:15:36 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 18:15:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869084.1280586 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVx47-0001NB-GN; Thu, 09 Jan 2025 18:15:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869084.1280586; Thu, 09 Jan 2025 18:15:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVx47-0001N4-DI; Thu, 09 Jan 2025 18:15:31 +0000
Received: by outflank-mailman (input) for mailman id 869084;
 Thu, 09 Jan 2025 18:15:30 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=RJAI=UB=raptorengineering.com=sanastasio@srs-se1.protection.inumbo.net>)
 id 1tVx46-0001My-4n
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 18:15:30 +0000
Received: from raptorengineering.com (mail.raptorengineering.com
 [23.155.224.40]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b3104b02-ceb5-11ef-99a4-01e77a169b0f;
 Thu, 09 Jan 2025 19:15:27 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id 5BEEC828562D;
 Thu,  9 Jan 2025 12:15:25 -0600 (CST)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id SMwavqoX7enH; Thu,  9 Jan 2025 12:15:24 -0600 (CST)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id 9EBD18286810;
 Thu,  9 Jan 2025 12:15:24 -0600 (CST)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id DxaI37PkEMZZ; Thu,  9 Jan 2025 12:15:24 -0600 (CST)
Received: from [10.11.0.2] (5.edge.rptsys.com [23.155.224.38])
 by mail.rptsys.com (Postfix) with ESMTPSA id 62566828562D;
 Thu,  9 Jan 2025 12:15:23 -0600 (CST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b3104b02-ceb5-11ef-99a4-01e77a169b0f
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.rptsys.com 9EBD18286810
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=raptorengineering.com; s=B8E824E6-0BE2-11E6-931D-288C65937AAD;
	t=1736446524; bh=l9sclmhBkQtNo/07xKJ37QlYAFduRLqz1UUCTl8OFT8=;
	h=Message-ID:Date:MIME-Version:To:From;
	b=RKPUsW0CwA2JHvpqcnGlEdobqnpN14fBpDyOW1vvIVF4kU/RywmBonNYMi32eWxdZ
	 2/w2LPp+zzlKckI/p7/nYYzSfM2ra/3gWg38mva6zLjPsOhM9VC0Jo9NaunjF8iO73
	 583RN1lkDjVlYs9HYhHniv/7N5+Fv1xC9OiS2+Oc=
X-Virus-Scanned: amavisd-new at rptsys.com
Message-ID: <ddea2ca7-e676-4f40-9d2f-8318f7416654@raptorengineering.com>
Date: Thu, 9 Jan 2025 12:15:22 -0600
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/mm: Introduce per-arch pte_attr_t type for PTE flags
To: Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>
Cc: tpearson@raptorengineering.com, Anthony PERARD
 <anthony.perard@vates.tech>, Michal Orzel <michal.orzel@amd.com>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Stefano Stabellini <sstabellini@kernel.org>,
 "Daniel P. Smith" <dpsmith@apertussolutions.com>,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, xen-devel@lists.xenproject.org
References: <47babd3f9ec00c15738a81aa57926e8a1f08cbe6.1735669493.git.sanastasio@raptorengineering.com>
 <a769ef28-5794-45a0-bb3f-e3dc3e3bcef3@suse.com>
 <d1b55fc3-feac-47e8-beed-5905b67131e4@citrix.com>
Content-Language: en-US
From: Shawn Anastasio <sanastasio@raptorengineering.com>
In-Reply-To: <d1b55fc3-feac-47e8-beed-5905b67131e4@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 1/9/25 4:56 AM, Andrew Cooper wrote:
> Either, arch/mm.h is required to provide the typedef,

This approach seems fine to me. I wanted to avoid changes to other
architectures where possible, but if this is acceptable then this is
probably the route I'd want to go down (see below).

For the reason outlined below, this would also probably mean that the
typedef would go before other includes at the top of arch/mm.h, and I'm
not sure if that would be an issue from a style perspective.
Alternatively, I could have arch/type.h define it on every architecture
if that would be acceptable.

> or we could have a common one as so:
> 
> #ifndef pte_attr_t
> typedef unsigned int pte_attr_t;
> #endif
> 
> which architectures can influence with:
> 
> typedef unsigned long pte_attr_t;
> #define pte_attr_t pte_attr_t
> 
> in the usual way.
>

There seems to be a pretty messy header dependency tree with xen/mm.h
where it #includes arch/mm.h halfway through the file after defining
(among other things) the prototypes for the functions that would need
pte_attr_t. Defining pte_attr_t this late in the file won't work since
the definition also needs to be visible to xen/vmap.h which gets
transitively included by the arch headers.

The kconfig route I went with sidesteps this by allowing the common
definition to not depend on previous header inclusions in its #ifndef
guard, but I agree with yours and Jan's comments about it not being the
best approach.

> 
> One thing however does occur to me.  ARM and RISC-V have systems with
> MPU protections rather than MMU, with Xen already starting to support
> this on ARM.
> 
> Therefore we might want to reconsider the name pte_attr_t to be
> something slightly less pagetable specific.  Then again, I'm not sure
> how much overlap there is between the map* functions and MPUs, where
> mapping is of course not possible.
> 

Without too much familiarity with ARM/RISC-V's MPU situation, at first
glance it seems to me that it would warrant a separate type, even if it
happened to coincide with the flag type used by the MMU on those arches.

> 
> Finally, this wants to be at least 2 patches.  One introducing
> pte_attr_t, and one changing PPC to be unsigned long.
>

Gotcha -- not a problem.

> ~Andrew

Thanks,
Shawn


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 18:16:50 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 18:16:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869093.1280597 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVx5M-0001tD-PY; Thu, 09 Jan 2025 18:16:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869093.1280597; Thu, 09 Jan 2025 18:16:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tVx5M-0001t6-Mr; Thu, 09 Jan 2025 18:16:48 +0000
Received: by outflank-mailman (input) for mailman id 869093;
 Thu, 09 Jan 2025 18:16: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
 <SRS0=RJAI=UB=raptorengineering.com=sanastasio@srs-se1.protection.inumbo.net>)
 id 1tVx5L-0001sw-V0
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 18:16:47 +0000
Received: from raptorengineering.com (mail.raptorengineering.com
 [23.155.224.40]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e05a23f6-ceb5-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 19:16:43 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id B7BB9828562D;
 Thu,  9 Jan 2025 12:16:41 -0600 (CST)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id cumXmu5fu84F; Thu,  9 Jan 2025 12:16:41 -0600 (CST)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id 232718286810;
 Thu,  9 Jan 2025 12:16:41 -0600 (CST)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id XTontW0C5y6j; Thu,  9 Jan 2025 12:16:41 -0600 (CST)
Received: from [10.11.0.2] (5.edge.rptsys.com [23.155.224.38])
 by mail.rptsys.com (Postfix) with ESMTPSA id 8BFF2828562D;
 Thu,  9 Jan 2025 12:16:40 -0600 (CST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e05a23f6-ceb5-11ef-a0df-8be0dac302b0
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.rptsys.com 232718286810
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=raptorengineering.com; s=B8E824E6-0BE2-11E6-931D-288C65937AAD;
	t=1736446601; bh=Q3uOEm76RN+/AKHBCFoMf2Z99IyyQj3ribq2cdcN+Ew=;
	h=Message-ID:Date:MIME-Version:To:From;
	b=U/oourOYFtI9wj9cG3ZHB9zDMSaN/XuAC4HSmodRJsL3Yvl6SqokXMhRiZjzYeJzB
	 pcTBQSuBFDx0zqUDo8ahWZv0PIDAdx0+DDCcR8BEo9+tbOE+Ihuby/vINcBG5L/nAx
	 8+oU3vr9Ke/fbELw4XgH1FclFTDR5GwCFANfWWp4=
X-Virus-Scanned: amavisd-new at rptsys.com
Message-ID: <c7c1ca24-fdfa-4fe0-ae45-c6f609e3d2fb@raptorengineering.com>
Date: Thu, 9 Jan 2025 12:16:40 -0600
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/mm: Introduce per-arch pte_attr_t type for PTE flags
To: Jan Beulich <jbeulich@suse.com>
Cc: tpearson@raptorengineering.com, Andrew Cooper
 <andrew.cooper3@citrix.com>, Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 "Daniel P. Smith" <dpsmith@apertussolutions.com>,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, xen-devel@lists.xenproject.org
References: <47babd3f9ec00c15738a81aa57926e8a1f08cbe6.1735669493.git.sanastasio@raptorengineering.com>
 <a769ef28-5794-45a0-bb3f-e3dc3e3bcef3@suse.com>
Content-Language: en-US
From: Shawn Anastasio <sanastasio@raptorengineering.com>
In-Reply-To: <a769ef28-5794-45a0-bb3f-e3dc3e3bcef3@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 1/9/25 3:15 AM, Jan Beulich wrote:
> On 31.12.2024 19:27, Shawn Anastasio wrote:
>> Xen's memory management APIs map_pages_to_xen, modify_xen_mappings,
>> set_fixmap, ioremap_attr, and __vmap all use an unsigned int to
>> represent architecture-dependent page table entry flags. This assumption
>> does not work on PPC/radix where some flags go past 32-bits, so
>> introduce the pte_attr_t type to allow architectures to opt in to larger
>> types to store PTE flags.
>>
>> Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> Signed-off-by: Shawn Anastasio <sanastasio@raptorengineering.com>
> 
> As iirc Andrew had indicated when suggesting this, what you say for PPC is
> true for x86 as well. Yet still we get around with unsigned int. Hence I
> think the change needs describing differently.
> 

I see what you mean -- I'll reword this to correctly reflect that the
change is not strictly necessary to accomodate architectures with
greater than 32-bit pte flags.

> Jan

Thanks,
Shawn


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 23:00:02 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 23:00:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869135.1280607 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tW1VC-0000g6-Jc; Thu, 09 Jan 2025 22:59:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869135.1280607; Thu, 09 Jan 2025 22:59:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tW1VC-0000fz-G2; Thu, 09 Jan 2025 22:59:46 +0000
Received: by outflank-mailman (input) for mailman id 869135;
 Thu, 09 Jan 2025 22:59:45 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=HHHK=UB=sntech.de=heiko@srs-se1.protection.inumbo.net>)
 id 1tW1VB-0000ft-89
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 22:59:45 +0000
Received: from gloria.sntech.de (gloria.sntech.de [185.11.138.130])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 694596f8-cedd-11ef-a0df-8be0dac302b0;
 Thu, 09 Jan 2025 23:59:42 +0100 (CET)
Received: from i5e860d05.versanet.de ([94.134.13.5] helo=diego.localnet)
 by gloria.sntech.de with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2)
 (envelope-from <heiko@sntech.de>)
 id 1tW1Uq-0005mI-C2; Thu, 09 Jan 2025 23:59:24 +0100
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 694596f8-cedd-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sntech.de;
	s=gloria202408; h=Content-Type:Content-Transfer-Encoding:MIME-Version:
	References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Sender:Reply-To:
	Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
	Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
	List-Subscribe:List-Post:List-Owner:List-Archive;
	bh=5X3Tmvihn3grkA7Jge4RjfqiSvPeilgE9yOD+d9FpVI=; b=s+jwsQH2++ZJTa21jBBjugQMXI
	4bHOZkHr3BtbA6u/uOhHobPv3MGeFWhNFGUl43iw9TYIyTjmoijwv6stOdPuOX44mYtM+Ex4veIlv
	GanP8Ltk9SSPFArY9HIjzDL6w9HBmiDH9lkAf/YRbJ76vQtfeMTBh+9CdrFBgxC6jT1PLksF27MCM
	uT5h6cp1P/vX38GEwJikltALOY4zAv1uVLPRdaX6J8i+zNB6LmK+4A346bu7woaR2Pb1GBGscGht6
	qpjxlF/C8UEv09LkPOGTvCxTCmWsQsAVjWgo7DBUgDUT6zw9zcZF7Od+phqWlT6xPgO3SWYExc5bS
	MfLPLsiA==;
From: Heiko =?ISO-8859-1?Q?St=FCbner?= <heiko@sntech.de>
To: maarten.lankhorst@linux.intel.com, mripard@kernel.org, airlied@gmail.com,
 simona@ffwll.ch, Thomas Zimmermann <tzimmermann@suse.de>
Cc: dri-devel@lists.freedesktop.org, linux-mediatek@lists.infradead.org,
 freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
 imx@lists.linux.dev, linux-samsung-soc@vger.kernel.org,
 nouveau@lists.freedesktop.org, virtualization@lists.linux.dev,
 spice-devel@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org,
 linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org,
 intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org,
 Thomas Zimmermann <tzimmermann@suse.de>, Sandy Huang <hjc@rock-chips.com>,
 Andy Yan <andy.yan@rock-chips.com>
Subject:
 Re: [PATCH v2 19/25] drm/rockchip: Compute dumb-buffer sizes with
 drm_mode_size_dumb()
Date: Thu, 09 Jan 2025 23:59:23 +0100
Message-ID: <3227546.fEcJ0Lxnt5@diego>
In-Reply-To: <20250109150310.219442-20-tzimmermann@suse.de>
References:
 <20250109150310.219442-1-tzimmermann@suse.de>
 <20250109150310.219442-20-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"

Am Donnerstag, 9. Januar 2025, 15:57:13 CET schrieb Thomas Zimmermann:
> Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
> buffer size. Align the pitch to a multiple of 64.
>=20
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Sandy Huang <hjc@rock-chips.com>
> Cc: "Heiko St=FCbner" <heiko@sntech.de>
> Cc: Andy Yan <andy.yan@rock-chips.com>

I've looked up the patch implementing the new functionality - patch2 of
this series [0] and that looks really nice to get proper helpers and not
having many drivers open-coding the same functionality in different ways.

So for the Rockchip adaptation:

Acked-by: Heiko Stuebner <heiko@sntech.de>

and looking forward to this getting merged :-)

Thanks a lot for working on that
Heiko

[0] https://patchwork.kernel.org/project/linux-rockchip/patch/2025010915031=
0.219442-3-tzimmermann@suse.de/

> ---
>  drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
>=20
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c b/drivers/gpu/dr=
m/rockchip/rockchip_drm_gem.c
> index 6330b883efc3..3bd06202e232 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> @@ -9,6 +9,7 @@
>  #include <linux/vmalloc.h>
> =20
>  #include <drm/drm.h>
> +#include <drm/drm_dumb_buffers.h>
>  #include <drm/drm_fb_helper.h>
>  #include <drm/drm_gem.h>
>  #include <drm/drm_gem_dma_helper.h>
> @@ -403,13 +404,12 @@ int rockchip_gem_dumb_create(struct drm_file *file_=
priv,
>  			     struct drm_mode_create_dumb *args)
>  {
>  	struct rockchip_gem_object *rk_obj;
> -	int min_pitch =3D DIV_ROUND_UP(args->width * args->bpp, 8);
> +	int ret;
> =20
> -	/*
> -	 * align to 64 bytes since Mali requires it.
> -	 */
> -	args->pitch =3D ALIGN(min_pitch, 64);
> -	args->size =3D args->pitch * args->height;
> +	/* 64-byte alignment required by Mali */
> +	ret =3D drm_mode_size_dumb(dev, args, SZ_64, 0);
> +	if (ret)
> +		return ret;
> =20
>  	rk_obj =3D rockchip_gem_create_with_handle(file_priv, dev, args->size,
>  						 &args->handle);
>=20






From xen-devel-bounces@lists.xenproject.org Thu Jan 09 23:46:20 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 23:46:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869145.1280617 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tW2E9-0007sX-QP; Thu, 09 Jan 2025 23:46:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869145.1280617; Thu, 09 Jan 2025 23:46:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tW2E9-0007sQ-Nn; Thu, 09 Jan 2025 23:46:13 +0000
Received: by outflank-mailman (input) for mailman id 869145;
 Thu, 09 Jan 2025 23:46: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
 <SRS0=T+E5=UB=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tW2E8-0007sI-2A
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 23:46:12 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e6367312-cee3-11ef-99a4-01e77a169b0f;
 Fri, 10 Jan 2025 00:46:09 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 0105B5C5D07;
 Thu,  9 Jan 2025 23:45:27 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5DA07C4CEDF;
 Thu,  9 Jan 2025 23:46:06 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e6367312-cee3-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1736466367;
	bh=fGDC3ZjmPCzEcicWKiiOjhdCnLx3DEY2jReJHIdpdfU=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=sYYhgISFVL3cLErJRJukbQ85ibx7hEW2CW5dT1a+TiHJeoJaId69QkSIPRJv/xa/3
	 ntuYCDsUosqixbh7xulKp4iMBw/SAIyNA3bf2qQYDiPHkod9kAXtvW80PtABOXBz+3
	 sR7CQrPbFcPSIcMIfXvdpj319NzjFCE/GlD7iQTnCeUBL6FetjNhfPdzSvHrcmljdg
	 xZwHKGsbIRvTLvfrHleUaSPICxHKFcBrWXxkfv1frDwGMVGLgSfjlYD/nXPtPPLdXm
	 iRePyuWy8bWYBAZHdDY7uv2whoOZEYf/DY3T4e7xgr/Lmwoe8JbJPaKsq0KCrypGY+
	 tBX3KFpld4Unw==
Date: Thu, 9 Jan 2025 15:46:05 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
cc: Stefano Stabellini <sstabellini@kernel.org>, 
    Denis Mukhin <dmkhn@proton.me>, Jan Beulich <jbeulich@suse.com>, 
    dmukhin@ford.com, xen-devel@lists.xenproject.org, 
    Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, 
    Bertrand Marquis <bertrand.marquis@arm.com>, 
    Michal Orzel <michal.orzel@amd.com>
Subject: Re: [PATCH v2 20/35] xen/console: introduce console_owner_domid()
In-Reply-To: <Z3-Dcraxc55vi-ur@macbook.local>
Message-ID: <alpine.DEB.2.22.394.2501091534090.133435@ubuntu-linux-20-04-desktop>
References: <8a5a5a0f-72b0-4336-b0d2-142254319242@suse.com> <alpine.DEB.2.22.394.2501061046060.133435@ubuntu-linux-20-04-desktop> <c39c0c6f-2fab-46e8-9563-c91fe890e87f@suse.com> <alpine.DEB.2.22.394.2501071533060.133435@ubuntu-linux-20-04-desktop>
 <a2fa92ff-a5fb-4adc-86aa-1481ebec92fe@suse.com> <Z34xhkNu5YLyEzut@macbook.local> <121ae72e-6229-40a4-8b9f-4f8b0764b712@suse.com> <Z344xgqtpNZIDxHD@macbook.local> <m5iIn0DzBY1VE3oW8MMk5aJD5yovtFe2u7eorkGQVf0czY2gzIYl9k2aKmrdyh1AG6YAgyasVn86Js-vUQyudqjHY7bRYE1hXdCkdFVF0U8=@proton.me>
 <alpine.DEB.2.22.394.2501081615050.133435@ubuntu-linux-20-04-desktop> <Z3-Dcraxc55vi-ur@macbook.local>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-902069907-1736466258=:133435"
Content-ID: <alpine.DEB.2.22.394.2501091544430.133435@ubuntu-linux-20-04-desktop>

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-902069907-1736466258=:133435
Content-Type: text/plain; CHARSET=UTF-8
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine.DEB.2.22.394.2501091544431.133435@ubuntu-linux-20-04-desktop>

On Thu, 9 Jan 2025, Roger Pau Monné wrote:
> On Wed, Jan 08, 2025 at 04:29:24PM -0800, Stefano Stabellini wrote:
> > On Wed, 8 Jan 2025, Denis Mukhin wrote:
> > > On Wednesday, January 8th, 2025 at 12:35 AM, Roger Pau Monné <roger.pau@citrix.com> wrote:
> > > > On Wed, Jan 08, 2025 at 09:13:02AM +0100, Jan Beulich wrote:
> > > > > On 08.01.2025 09:04, Roger Pau Monné wrote:
> > > > > > On Wed, Jan 08, 2025 at 08:28:32AM +0100, Jan Beulich wrote:
> > > > > > > On 08.01.2025 00:40, Stefano Stabellini wrote:
> > > > > > > > On Tue, 7 Jan 2025, Jan Beulich wrote:
> > > > > > > > > On 06.01.2025 19:48, Stefano Stabellini wrote:
> > > > > > > > > > On Mon, 6 Jan 2025, Jan Beulich wrote:
> > > > > > > > > > > On 04.01.2025 05:15, Denis Mukhin wrote:
> > > > > > > > > > > > On Tuesday, December 10th, 2024 at 11:28 PM, Jan Beulich jbeulich@suse.com wrote:
> > > > > > > > > > > > > On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > From: Denis Mukhin dmukhin@ford.com
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > console_owner_domid() is introduced to obtain the "console owner" domain ID.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > The call is used in NS8250 emulator to identify the case when physical xen
> > > > > > > > > > > > > > console focus is owned by the domain w/ NS8250 emulator, in which case,
> > > > > > > > > > > > > > messages from guest OS are formatted w/o '(XEN)' prefix.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Such messages ought to be processed through guest_printk(), which wants a
> > > > > > > > > > > > > domain pointer, not a domid_t anyway. Plus isn't that going to be
> > > > > > > > > > > > > current->domain anyway at the callsite, eliminating the need for such a
> > > > > > > > > > > > > 
> > > > > > > > > > > > > helper altogether?
> > > > > > > > > > > > 
> > > > > > > > > > > > If the current domain is owning the physical console and printing, say, Linux
> > > > > > > > > > > > login prompt, there's no need to add "(XEN)" for every printout; adding timestamps
> > > > > > > > > > > > can be disabled from Xen command line.
> > > > > > > > > > > 
> > > > > > > > > > > Surely there shouldn't be (XEN), but without (d<N>) it'll be ambiguous in a log
> > > > > > > > > > > which domain a message came from. As long as only Dom0 messages are left un-
> > > > > > > > > > > prefixed, that's likely fine. Yet as soon as multiple domains can issue such
> > > > > > > > > > > messages (and have console "focus") I think the prefix needs to be there.
> > > > > > > > > > 
> > > > > > > > > > It looks like we are aligned on the desired behavior,
> > > > > > > > > 
> > > > > > > > > Hmm, no, I don't think we are. I don't ...
> > > > > > > > > 
> > > > > > > > > > but for clarity,
> > > > > > > > > > see https://marc.info/?l=xen-devel&m=173405161613716, also copy/pasted
> > > > > > > > > > here:
> > > > > > > > > > 
> > > > > > > > > > I think we should provide a consistent behavior across architectures.
> > > > > > > > > > The current behavior with vpl011 and dom0less on ARM is the following:
> > > > > > > > > > 
> > > > > > > > > > - no prefix for Dom0 output
> > > > > > > > > > - DOM$NUM for DomUs when not in focus, otherwise no prefix
> > > > > > > > > 
> > > > > > > > > ... view this model as a desirable one. It leaves room for ambiguity.
> > > > > > > > 
> > > > > > > > Adding a few more people in CC for feedback.
> > > > > > > > 
> > > > > > > > My priority is to keep the architectures aligned. It might be OK to
> > > > > > > > change output format, but then let's do it uniformly on ARM as well.
> > > > > > > > 
> > > > > > > > Jan, please clarify what you think would be better than the above. Is it
> > > > > > > > the following? I don't think I understood your preference.
> > > > > > > > 
> > > > > > > > - DOM$NUM for Dom0 and DomUs when not in focus, otherwise no prefix
> > > > > > > 
> > > > > > > No, I mean like we have it with guest_printk() today. (XEN) for Xen's
> > > > > > > own messages, (d<N>) for ordinary domains' ones, and no prefix
> > > > > > > exclusively for the hardware/control domain. What is best to do when
> > > > > > > hardware and control domains are distinct I'm uncertain - I'd be
> > > > > > > inclined to suggest that the hardware domain then stay the one without
> > > > > > > any prefix.
> > > > > > 
> > > > > > One concern I have with this approach is whether the addition of the
> > > > > > (d<N>) prefixes will skew output of interactive applications. So far
> > > > > > the prefix is added to output from all domains different than dom0
> > > > > > because the console is not interactive for them, and hence no input
> > > > > > can be consumed.
> > > > > 
> > > > > Hmm, that's an aspect I have to admit I didn't think of.
> > > > > 
> > > > > > If that changes however, and domains different than dom0 can get input
> > > > > > from the Xen console then I wonder how much the added prefix will skew
> > > > > > output. Another possible option would be to not print the prefix for
> > > > > > the domain that has the console input assigned (current target), and
> > > > > > print it for all other domains (even for dom0 when not in focus).
> > > > > 
> > > > > That's largely what aiui was proposed. My extra requirement there would
> > > > > then be that we make sure a log message is always emitted when console
> > > > > focus shifts, so it's possible to identify the owner for any part of
> > > > > the log.
> > > > 
> > > > 
> > > > Indeed, printing console input shifting should be a requirement
> > > > regardless of how we decide to print the prefix.
> > > 
> > > Console input focus switch is indicated after pressing Crtl+aaa, e.g.:
> > > [[
> > > ...
> > > (XEN) [15359.353038] *** Serial input to Xen (type 'CTRL-aaa' to switch input)
> > > (XEN) [15361.176754] *** Serial input to DOM0 (type 'CTRL-aaa' to switch input)
> > > (XEN) [15711.297202] *** Serial input to DOM1 (type 'CTRL-aaa' to switch input)
> > > ...
> > > ]]
> > 
> > 
> > Roger, Jan, you should use Xen Dom0less more :-) This is the way it
> > already works on ARM. Let me expand on my earlier message that was too
> > terse.
> 
> Hehe, I should use ARM more in general I think :).
> 
> > At boot time, Xen prints messages with the (XEN) prefix as usual:
> > 
> > (XEN) Brought up 4 CPUs
> > 
> > When Dom0 starts, it has not prefix (and has input by default):
> > 
> > [    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
> > 
> > When a DomU starts, it has the following prefix (and doesn't have
> > input):
> > 
> > (XEN) DOM1: [    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
> > 
> > 
> > Eventually, both Linuxes finish booting, you can login into Dom0 as
> > usual. Messages from Dom1, if any, are still printed with (XEN) DOM1 as
> > prefix.
> > 
> > You can switch input to Dom1 with Ctrx-aaa, the same way that you do
> > today to switch between Xen and Dom0. Xen prints a message:
> > 
> > (XEN) *** Serial input to DOM1 (type 'CTRL-a' three times to switch input)
> > 
> > Now, as you type, you send characters to Dom1. And Dom1 doesn't have the
> > DOM1 prefix any longer, while it is still has (XEN) because the message
> > is printed by Xen on behalf of the domain:
> > 
> > (XEN) / # echo hello world
> > (XEN) hello world
> > 
> > If Dom0 prints anything in the backgrounds, it shows without prefixes:
> > 
> > hello world from dom0
> > 
> > If another domain, dom2, prints anything in the background, it shows
> > with (XEN) DOM2 prefix:
> > 
> > (XEN) DOM2: hello from dom2
> > 
> > I think it makes sense to be consistent across architectures and we
> > should default to the same behavior on x86 too. If we want to make
> > improvements, the one thing I could potentially see changing is adding a
> > DOM0 prefix to Dom0 messages when Dom0 does not have input. If we do
> > that, let's do it on both ARM and x86 architectures.
> 
> The usual prefix is (d<domid>) IIRC, that's what guest_printk() uses,
> is there any reason dom0less uses "(XEN) DOM<domid>:" instead of the
> guest_printk() prefix?
> 
> My preference would be use to (d<domid>) prefix for any guest output
> that doesn't belong to the domain that's the recipient of the input
> (iow: not in console input focus).  And drop the (XEN) prefix from
> guest output.
> 
> The rest looks all sensible to me.  I think we should avoid adding any
> prefixes to guest output when it has the console focus, as otherwise
> interactive applications might not work correctly.

I am OK with what you describe, I would kindly ask Denis to also modify
ARM vpl011 to match. Looking at the code, I don't know where the (XEN)
prefix is coming from, but for the DOM<domid> to d<domid> change, it
would be probably something like this:

diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index 1fc3114cce..959d172e96 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -107,7 +107,10 @@ static void vpl011_write_data_xen(struct domain *d, uint8_t data)
             if ( data != '\n' )
                 intf->out[intf->out_prod++] = '\n';
             intf->out[intf->out_prod++] = '\0';
-            printk("DOM%u: %s", d->domain_id, intf->out);
+            if ( in_focus(d) )
+                printk("%s", intf->out);
+            else
+                guest_printk("%s", d, intf->out);
             intf->out_prod = 0;
         }
     }

There is also one additional change needed to add the (d<domid>) prefix
for dom0 when not in focus. The Dom0 print typically comes from
do_console_io, so in pseudocode we would need something like:

diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 7da8c5296f..5d250b642a 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -643,6 +643,9 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer,
             /* Use direct console output as it could be interactive */
             nrspin_lock_irq(&console_lock);
 
+            if ( !in_focus(cd) )
+                add_prefix(kbuf, "(d0) ");
+
             console_serial_puts(kbuf, kcount);
             video_puts(kbuf, kcount);
 
--8323329-902069907-1736466258=:133435--


From xen-devel-bounces@lists.xenproject.org Thu Jan 09 23:56:12 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 23:56:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869160.1280628 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tW2Nk-0001Ir-QP; Thu, 09 Jan 2025 23:56:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869160.1280628; Thu, 09 Jan 2025 23:56:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tW2Nk-0001Ik-MX; Thu, 09 Jan 2025 23:56:08 +0000
Received: by outflank-mailman (input) for mailman id 869160;
 Thu, 09 Jan 2025 23:56:07 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=T+E5=UB=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tW2Nj-0001Ie-IZ
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 23:56:07 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4a126308-cee5-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 00:56:06 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 9030BA426D8;
 Thu,  9 Jan 2025 23:54:16 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 51C85C4CED2;
 Thu,  9 Jan 2025 23:56:03 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 4a126308-cee5-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1736466964;
	bh=7mY3fwX8w+pQrGqvlUkX9hLyyGjRJezHqD3Z97B4E/o=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=aa0Udrm/fUI01Hvf0NW0fTb0vGHn/xkvQtvHVVjda04HkDGNYDjyheARQbnynOw1S
	 z5dj/S3dcmPEj5/4QkTQApJqAKk9oiMAKBtSR8lKHs0aq6ufvGk90INuvlG7MZcCav
	 Z57BWu/uMYA6NvNoL/atLxvD/QPsBGY6laCaX6i3l3TFVFkzkl6RhMYvUKXoCj2ymC
	 W7dwYInSVAWM/6KVEcIALWk76UW7F0Lscw9zaYXCEiZUKx83NHeaPVLHfrfT9m0FAm
	 jwTyuqVCYOa1Y0aRENPaWzpsNlzu1H/fXl0F0g7RKI6b5Ee2JIEy4lxx1yF84654gw
	 Rz3jAM8yNpNQw==
Date: Thu, 9 Jan 2025 15:56:02 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alessandro Zucchelli <alessandro.zucchelli@bugseng.com>
cc: xen-devel@lists.xenproject.org, consulting@bugseng.com, 
    Simone Ballarin <simone.ballarin@bugseng.com>, 
    Doug Goldstein <cardoe@cardoe.com>, 
    Stefano Stabellini <sstabellini@kernel.org>, 
    Andrew Cooper <andrew.cooper3@citrix.com>, 
    Anthony PERARD <anthony.perard@vates.tech>, 
    Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>, 
    Julien Grall <julien@xen.org>, 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Subject: Re: [PATCH v4] misra: add deviation for MISRA C Rule R11.8.
In-Reply-To: <5b8b143207a5dc0478a500cf2d41017bdb982019.1736417750.git.alessandro.zucchelli@bugseng.com>
Message-ID: <alpine.DEB.2.22.394.2501091555550.133435@ubuntu-linux-20-04-desktop>
References: <5b8b143207a5dc0478a500cf2d41017bdb982019.1736417750.git.alessandro.zucchelli@bugseng.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Thu, 9 Jan 2025, Alessandro Zucchelli wrote:
> Rule 11.8 states as following: "A cast shall not remove any `const' or
> `volatile' qualification from the type pointed to by a pointer".
> 
> Function `__hvm_copy' in `xen/arch/x86/hvm/hvm.c' is a double-use
> function, where the parameter needs to not be const because it can be
> set for write or not. As it was decided a new const-only function will
> lead to more developer confusion than it's worth, this violation is
> addressed by deviating the function.
> All cases of casting away const-ness are accompanied with a comment
> explaining why it is safe given the other flags passed in; such comment is used
> by the deviation in order to match the appropriate function call.
> 
> No functional change.
> 
> Signed-off-by: Alessandro Zucchelli <alessandro.zucchelli@bugseng.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>



From xen-devel-bounces@lists.xenproject.org Thu Jan 09 23:57:30 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Jan 2025 23:57:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869168.1280638 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tW2P3-0001p5-4K; Thu, 09 Jan 2025 23:57:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869168.1280638; Thu, 09 Jan 2025 23:57:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tW2P2-0001ow-VZ; Thu, 09 Jan 2025 23:57:28 +0000
Received: by outflank-mailman (input) for mailman id 869168;
 Thu, 09 Jan 2025 23:57:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=T+E5=UB=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tW2P2-0001oq-In
 for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 23:57:28 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7a565540-cee5-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 00:57:27 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id D4ED9A425A2;
 Thu,  9 Jan 2025 23:55:37 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1D166C4CED2;
 Thu,  9 Jan 2025 23:57:25 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 7a565540-cee5-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1736467046;
	bh=BWQ3BYZ6WFNUUMoBCv+lcp5Zz7Jk/R4qFsK2q7sIwKM=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=b8rpB9bnl//RZW5bEl8QfIC2qpjQZwDTV/3YFcKE4cGqasnJuEKDyn2lWn1etv0/9
	 kmezQMjIJVhGGCsSkPja1BbloY70HhNwHdcxiV+VrxNerPHoodDsMoxA03nTpS3od0
	 Z/JU2IgCYmhRt01EaffrKVn0ym2qMuzE08WAbmUmB8wv5tfd7CVrrYdy4eJ09qsjaB
	 ezCY5PV8pMJLE0Bk8bpkUHmlau3jukvG8YFqsCDy1YPmfGCESwat7Iu1ppx2OjOtni
	 /TgDt6gEZWOuLPk5AMQF+9F+8W0e6/lKsRCW0a/ayot29wx9PSHDwkHmdI+BBkyMvN
	 Q9krHMkItdiiA==
Date: Thu, 9 Jan 2025 15:57:24 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Nicola Vetrini <nicola.vetrini@bugseng.com>
cc: Stefano Stabellini <sstabellini@kernel.org>, 
    Jan Beulich <jbeulich@suse.com>, Roger Pau Monne <roger.pau@citrix.com>, 
    Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xenproject.org, 
    consulting@bugseng.com
Subject: Re: [PATCH v2 1/2] x86/uaccess: rework user access speculative harden
 guards
In-Reply-To: <8e31daaf77216534c252d371a3251595@bugseng.com>
Message-ID: <alpine.DEB.2.22.394.2501091556590.133435@ubuntu-linux-20-04-desktop>
References: <20241126093508.6966-1-roger.pau@citrix.com> <20241126093508.6966-2-roger.pau@citrix.com> <cf1f87d1-f616-4944-94fa-69a777249072@suse.com> <e3ec3dad28dc94436c0b330b2f995120@bugseng.com> <alpine.DEB.2.22.394.2501031617280.16425@ubuntu-linux-20-04-desktop>
 <8e31daaf77216534c252d371a3251595@bugseng.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Thu, 9 Jan 2025, Nicola Vetrini wrote:
> On 2025-01-04 01:20, Stefano Stabellini wrote:
> > Hi Nicola, one question below
> > 
> > On Wed, 27 Nov 2024, Nicola Vetrini wrote:
> > > > #define AMD_OSVW_ERRATUM(osvw_id, ...)  osvw_id, __VA_ARGS__, 0
> > > >
> > > > where we're using the C99 form rather than the GNU extension, and where
> > > > hence __VA_ARGS__ would - by extrapolation of the Misra rule - need
> > > > parenthesizing, when it isn't and can't be.
> > > >
> > > > Isn't it rather the case that variable argument macros need a more
> > > general
> > > > deviation, if not an adjustment to the Misra rule? Extending the Cc list
> > > > some ...
> > 
> > Nicola, if you look at the original patch:
> > https://marc.info/?l=xen-devel&m=173261356716876
> > 
> > "The current guards to select whether user accesses should be speculative
> > hardened violate Misra rule 20.7, as the UA_KEEP() macro doesn't (and can't)
> > parenthesize the 'args' argument."
> > 
> > And the very first change in the patch is:
> > 
> > diff --git a/xen/arch/x86/include/asm/uaccess.h
> > b/xen/arch/x86/include/asm/uaccess.h
> > index 2d01669b96..6b8150ac22 100644
> > --- a/xen/arch/x86/include/asm/uaccess.h
> > +++ b/xen/arch/x86/include/asm/uaccess.h
> > @@ -24,9 +24,6 @@ unsigned int copy_from_unsafe_ll(void *to, const void
> > *from, unsigned int n);
> >  void noreturn __get_user_bad(void);
> >  void noreturn __put_user_bad(void);
> > 
> > -#define UA_KEEP(args...) args
> > -#define UA_DROP(args...)
> > -
> >  /**
> >   * get_guest: - Get a simple variable from guest space.
> >   * @x:   Variable to store result.
> > 
> > 
> > Do you think there is any way we could configure Eclair, with or without
> > a deviation, not to detect every use of UA_KEEP as violations?
> 
> I narrowed this violation down to a different treatment of the named variadic
> argument. Since the argument 'args' cannot be parenthesized as a regular
> argument could, the invocations of the 'UA_KEEP' cannot comply with the rule.
> Therefore, as an extension to the rule, ECLAIR currently ignores the use of
> '__VA_ARGS__' in a macro definition, but treats 'args...' as a regular macro
> parameter name, hence the violation.
> 
> To be clear, these two definitions have the same semantics, but one shows a
> violation and the other doesn't
> 
> #define UA_KEEP(args...) args
> #define UA_KEEP(...) __VA_ARGS__
> 
> I will update ECLAIR to treat the two forms as the same, so this patch can be
> dropped. If you think it's helpful I can send a patch spelling out this -
> arbitrary, but reasonable in my opinion - extension to the MISRA rule (which
> does not consider the implications related to the use of GNU exensions) so
> that contributors have a clear picture of the situation.

Thank you Nicola! Yes the patch would be appreciated :-)


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 00:10:40 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 00:10:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869178.1280646 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tW2bX-0005I7-MC; Fri, 10 Jan 2025 00:10:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869178.1280646; Fri, 10 Jan 2025 00:10:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tW2bX-0005I0-Jk; Fri, 10 Jan 2025 00:10:23 +0000
Received: by outflank-mailman (input) for mailman id 869178;
 Fri, 10 Jan 2025 00:10: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
 <SRS0=RTL5=UC=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tW2bW-0005Hs-6e
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 00:10:22 +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 4761351e-cee7-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 01:10:21 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 693E75C0609;
 Fri, 10 Jan 2025 00:09:38 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 74A88C4CED3;
 Fri, 10 Jan 2025 00:10:18 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 4761351e-cee7-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1736467819;
	bh=YgXK+epiYRolqdYN0qTe36OjpW18LYw84dbcfP19S9E=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=puzEKJn6debey9sndXrLunAtEFayzSdYt0SxrXcwuuHxOYrRMIEtevkNzswA9olSY
	 zu/rVcTRsbwKGnGb0p/iA2IYMw5g9HetAK7eXNJGiajmIxt/1KV3+ZJvzVr7TdZumE
	 fS4c97UttIuiAC7gYiShwO9Z+iWfUg085Inbo+5NPJbMXwCIC1yFTyhzyZAAbbUAvk
	 clOnGt0k3EPwDarraA35BGGZyBBfqCTF5cwbbnR+uSN1cgWue0H/sd+FO0E9SqRc7B
	 8jOgHiVREe5sciuaigsCk7FuJ0qM+PlEN87cfLQrISCq3Dt4P3r1UjltWFpIYOdo6R
	 1z6x2W/kUEKbg==
Date: Thu, 9 Jan 2025 16:10:17 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich <jbeulich@suse.com>
cc: Stefano Stabellini <sstabellini@kernel.org>, jgross@suse.com, 
    xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] xen: update pvcalls_front_accept prototype
In-Reply-To: <ec92e932-e3b7-40ad-9ed3-2b3391cc63a7@suse.com>
Message-ID: <alpine.DEB.2.22.394.2501091608090.133435@ubuntu-linux-20-04-desktop>
References: <alpine.DEB.2.22.394.2501061335161.133435@ubuntu-linux-20-04-desktop> <0f8fc348-14f5-40ac-912a-1785caedb675@suse.com> <alpine.DEB.2.22.394.2501071530180.133435@ubuntu-linux-20-04-desktop> <ec92e932-e3b7-40ad-9ed3-2b3391cc63a7@suse.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Wed, 8 Jan 2025, Jan Beulich wrote:
> On 08.01.2025 00:30, Stefano Stabellini wrote:
> > On Tue, 7 Jan 2025, Jan Beulich wrote:
> >> On 06.01.2025 22:36, Stefano Stabellini wrote:
> >>> xen: update pvcalls_front_accept prototype
> >>>
> >>> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
> >>> ---
> >>>
> >>> Changes in v2:
> >>> - also update pvcalls-front.c
> >>
> >> The patch still gives the impression of being incomplete: There's no
> >> caller of the function that you update. However, there's no such caller
> >> in the first place. Why don't you just delete the function then?
> > 
> > It is meant to be called from an out-of-tree module, which has not been
> > upstreamed yet
> 
> And which then would require an EXPORT_SYMBOL() anyway. In Xen, as you're
> well aware, such unreachable code would actually constitute a Misra
> violation.
> 
> Without any in-tree caller, imo the change needs a non-empty description,
> clarifying why the adjustment is wanted / needed.

How about:

---
xen: update pvcalls_front_accept prototype

While currently there are no in-tree callers of these functions, it is
best to keep them up-to-date with the latest network API.

Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 00:27:22 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 00:27:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869187.1280656 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tW2rr-0007bL-1a; Fri, 10 Jan 2025 00:27:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869187.1280656; Fri, 10 Jan 2025 00:27:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tW2rq-0007bE-VK; Fri, 10 Jan 2025 00:27:14 +0000
Received: by outflank-mailman (input) for mailman id 869187;
 Fri, 10 Jan 2025 00:27: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
 <SRS0=RTL5=UC=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tW2rp-0007b8-Ok
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 00:27:13 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a1ab62f1-cee9-11ef-99a4-01e77a169b0f;
 Fri, 10 Jan 2025 01:27:11 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 9033FA410EB;
 Fri, 10 Jan 2025 00:25:21 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id A9EA6C4CED2;
 Fri, 10 Jan 2025 00:27:08 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a1ab62f1-cee9-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1736468829;
	bh=tUdaT03ueTPYhKJvplq88rLYDZSM2aRHSNI4FKJoWsc=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=OhxwIro2ETxoZRUOIkEuP6oKXNI6dHSMqJyU9093r24LM9M3qa0xSBuUJLitMoJrI
	 Ms9nV5iXWhQE7qQTuRdgSVkYfB5VSAHECFT+AvQQqjCzPoDw1BD5G1gVvozK7INMCl
	 2NlRRxAkl6e8+K18cITLt5dRH0d6IShUqQos36Zm9PF4FK3nIioInHRdYIL7cuHIbY
	 3QzlZZj/M2CN4eqCDMoqyEszKoBDYIvOqzMtyhlSJOjGHcPhlZNXY1YFWfNtrN30e7
	 SkBTIoZYneETERCIVAL/79Q2AbpKaxMqYcdmLUdvMuDJ4hHP4Vmt29VNBnVV6B2LiU
	 5K8i61Ug0NVdg==
Date: Thu, 9 Jan 2025 16:27:08 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Mykyta Poturai <Mykyta_Poturai@epam.com>
cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, 
    Oleksandr Andrushchenko <Oleksandr_Andrushchenko@epam.com>, 
    Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, 
    Bertrand Marquis <bertrand.marquis@arm.com>, 
    Michal Orzel <michal.orzel@amd.com>, 
    Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: Re: [PATCH v2 1/2] ARM: ITS: implement quirks and add support for
 Renesas Gen4 ITS
In-Reply-To: <e2544cace3517eb68cdffdc278f347584f93fd63.1736331828.git.mykyta_poturai@epam.com>
Message-ID: <alpine.DEB.2.22.394.2501091619040.133435@ubuntu-linux-20-04-desktop>
References: <cover.1736331828.git.mykyta_poturai@epam.com> <e2544cace3517eb68cdffdc278f347584f93fd63.1736331828.git.mykyta_poturai@epam.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Wed, 8 Jan 2025, Mykyta Poturai wrote:
> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> 
> There are number of ITS implementations exist which are different from
> the base one which have number of functionalities defined as is
> "IMPLEMENTATION DEFINED", e.g. there may exist differences in cacheability,
> shareability and memory requirements and others. This requires
> appropriate handling of such HW requirements which are implemented as
> ITS quirks: GITS_IIDR (ITS Implementer Identification Register) is used to
> differentiate the ITS implementations and select appropriate set of
> quirks if any.
> 
> As an example of such ITSes add quirk implementation for Renesas Gen4 ITS:
> - add possibility to override default cacheability and shareability
> settings used for ITS memory allocations;
> - change relevant memory allocations to alloc_xenheap_pages which allows
> to specify memory access flags, free_xenheap_pages is used to free;
> - add quirks validation to ensure that all ITSes share the same quirks
> in case of multiple ITSes are present in the system;
> 
> The Gen4 ITS memory requirements are not covered in any errata as of yet,
> but observed behavior suggests that they are indeed required.
> 
> The idea of the quirk implementation is inspired by the Linux kernel ITS
> quirk implementation [1].
> 
> Changelog:
> v1 -> v2:
> - switched to using alloc_xenheap_pages/free_xenheap_pages for ITS memory
> allocations;
> - updated declaration of its_quirk_flags;
> - added quirks validation to ensure that all ITSes share the same quirks;
> - removed unnecessary vITS changes;
> 
> 
> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
> 
> [1] https://elixir.bootlin.com/linux/v5.16.1/source/drivers/irqchip/irq-gic-v3-its.c
> ---
>  xen/arch/arm/gic-v3-its.c             | 141 +++++++++++++++++++++++---
>  xen/arch/arm/gic-v3-lpi.c             |  20 ++--
>  xen/arch/arm/include/asm/gic_v3_its.h |   8 ++
>  3 files changed, 150 insertions(+), 19 deletions(-)
> 
> diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
> index 5fd83af25a..8849ac6c4b 100644
> --- a/xen/arch/arm/gic-v3-its.c
> +++ b/xen/arch/arm/gic-v3-its.c
> @@ -42,6 +42,7 @@ struct its_device {
>      struct rb_node rbnode;
>      struct host_its *hw_its;
>      void *itt_addr;
> +    unsigned int itt_order;
>      paddr_t guest_doorbell;             /* Identifies the virtual ITS */
>      uint32_t host_devid;
>      uint32_t guest_devid;
> @@ -50,6 +51,104 @@ struct its_device {
>      struct pending_irq *pend_irqs;      /* One struct per event */
>  };
>  
> +/*
> + * It is unlikely that a platform implements ITSes with different quirks,
> + * so assume they all share the same.
> + */
> +struct its_quirk {
> +    const char *desc;
> +    bool (*init)(struct host_its *hw_its);
> +    uint32_t iidr;
> +    uint32_t mask;
> +};
> +
> +static uint32_t __ro_after_init its_quirk_flags;
> +
> +static bool gicv3_its_enable_quirk_gen4(struct host_its *hw_its)
> +{
> +    its_quirk_flags |= HOST_ITS_WORKAROUND_NC_NS |
> +        HOST_ITS_WORKAROUND_32BIT_ADDR;
> +
> +    return true;
> +}
> +
> +static const struct its_quirk its_quirks[] = {
> +    {
> +        .desc	= "R-Car Gen4",
> +        .iidr	= 0x0201743b,
> +        .mask	= 0xffffffff,
> +        .init	= gicv3_its_enable_quirk_gen4,
> +    },
> +    {
> +        /* Sentinel. */
> +    }
> +};
> +
> +static struct its_quirk* gicv3_its_find_quirk(uint32_t iidr)
> +{
> +    const struct its_quirk *quirks = its_quirks;
> +
> +    for ( ; quirks->desc; quirks++ )
> +    {
> +        if ( quirks->iidr == (quirks->mask & iidr) )
> +            return (struct its_quirk *)quirks;
> +    }
> +
> +    return NULL;
> +}
> +
> +static void gicv3_its_enable_quirks(struct host_its *hw_its)
> +{
> +    uint32_t iidr = readl_relaxed(hw_its->its_base + GITS_IIDR);
> +    const struct its_quirk *quirk = gicv3_its_find_quirk(iidr);
> +
> +    if ( quirk && quirk->init(hw_its) )
> +        printk("GICv3: enabling workaround for ITS: %s\n", quirk->desc);
> +}
> +
> +static void gicv3_its_validate_quirks(void)
> +{
> +    const struct its_quirk *quirk = NULL, *prev = NULL;
> +    const struct host_its *hw_its;
> +
> +    if ( list_empty(&host_its_list) )
> +        return;
> +
> +    hw_its = list_first_entry(&host_its_list, struct host_its, entry);
> +    prev = gicv3_its_find_quirk(readl_relaxed(hw_its->its_base + GITS_IIDR));
> +
> +    list_for_each_entry(hw_its, &host_its_list, entry)
> +    {
> +        quirk = gicv3_its_find_quirk(readl_relaxed(hw_its->its_base + GITS_IIDR));
> +        BUG_ON(quirk != prev);
> +        prev = quirk;
> +    }

I think this is OK


> +}
> +
> +uint64_t gicv3_its_get_cacheability(void)
> +{
> +    if ( its_quirk_flags & HOST_ITS_WORKAROUND_NC_NS )
> +        return GIC_BASER_CACHE_nC;
> +
> +    return GIC_BASER_CACHE_RaWaWb;
> +}
> +
> +uint64_t gicv3_its_get_shareability(void)
> +{
> +    if ( its_quirk_flags & HOST_ITS_WORKAROUND_NC_NS )
> +        return GIC_BASER_NonShareable;
> +
> +    return GIC_BASER_InnerShareable;
> +}
> +
> +unsigned int gicv3_its_get_memflags(void)
> +{
> +    if ( its_quirk_flags & HOST_ITS_WORKAROUND_32BIT_ADDR )
> +        return MEMF_bits(32);
> +
> +    return 0;
> +}
> +
>  bool gicv3_its_host_has_its(void)
>  {
>      return !list_empty(&host_its_list);
> @@ -289,19 +388,23 @@ static void *its_map_cbaser(struct host_its *its)
>  {
>      void __iomem *cbasereg = its->its_base + GITS_CBASER;
>      uint64_t reg;
> +    unsigned int order;
>      void *buffer;
>  
> -    reg  = GIC_BASER_InnerShareable << GITS_BASER_SHAREABILITY_SHIFT;
> +    reg  = gicv3_its_get_shareability() << GITS_BASER_SHAREABILITY_SHIFT;
>      reg |= GIC_BASER_CACHE_SameAsInner << GITS_BASER_OUTER_CACHEABILITY_SHIFT;
> -    reg |= GIC_BASER_CACHE_RaWaWb << GITS_BASER_INNER_CACHEABILITY_SHIFT;
> +    reg |= gicv3_its_get_cacheability() << GITS_BASER_INNER_CACHEABILITY_SHIFT;
>  
> -    buffer = _xzalloc(ITS_CMD_QUEUE_SZ, SZ_64K);
> +    order = get_order_from_bytes(max(ITS_CMD_QUEUE_SZ, SZ_64K));
> +    buffer = alloc_xenheap_pages(order, gicv3_its_get_memflags());
>      if ( !buffer )
>          return NULL;
>  
> +    memset(buffer, 0, PAGE_SIZE << order);
> +
>      if ( virt_to_maddr(buffer) & ~GENMASK(51, 12) )
>      {
> -        xfree(buffer);
> +        free_xenheap_pages(buffer, order);
>          return NULL;
>      }
>  
> @@ -340,11 +443,12 @@ static int its_map_baser(void __iomem *basereg, uint64_t regc,
>      unsigned int entry_size = GITS_BASER_ENTRY_SIZE(regc);
>      unsigned int pagesz = 2;    /* try 64K pages first, then go down. */
>      unsigned int table_size;
> +    unsigned int order;
>      void *buffer;
>  
> -    attr  = GIC_BASER_InnerShareable << GITS_BASER_SHAREABILITY_SHIFT;
> +    attr  = gicv3_its_get_shareability() << GITS_BASER_SHAREABILITY_SHIFT;
>      attr |= GIC_BASER_CACHE_SameAsInner << GITS_BASER_OUTER_CACHEABILITY_SHIFT;
> -    attr |= GIC_BASER_CACHE_RaWaWb << GITS_BASER_INNER_CACHEABILITY_SHIFT;
> +    attr |= gicv3_its_get_cacheability() << GITS_BASER_INNER_CACHEABILITY_SHIFT;
>  
>      /*
>       * Setup the BASE register with the attributes that we like. Then read
> @@ -357,13 +461,16 @@ retry:
>      /* The BASE registers support at most 256 pages. */
>      table_size = min(table_size, 256U << BASER_PAGE_BITS(pagesz));
>  
> -    buffer = _xzalloc(table_size, BIT(BASER_PAGE_BITS(pagesz), UL));
> +    order = get_order_from_bytes(max(table_size, BIT(BASER_PAGE_BITS(pagesz), U)));
> +    buffer = alloc_xenheap_pages(order, gicv3_its_get_memflags());
>      if ( !buffer )
>          return -ENOMEM;
>  
> +    memset(buffer, 0, PAGE_SIZE << order);
> +
>      if ( !check_baser_phys_addr(buffer, BASER_PAGE_BITS(pagesz)) )
>      {
> -        xfree(buffer);
> +        free_xenheap_pages(buffer, order);
>          return -ERANGE;
>      }
>  
> @@ -396,7 +503,7 @@ retry:
>      if ( ((regc >> GITS_BASER_PAGE_SIZE_SHIFT) & 0x3UL) == pagesz )
>          return 0;
>  
> -    xfree(buffer);
> +    free_xenheap_pages(buffer, order);
>  
>      if ( pagesz-- > 0 )
>          goto retry;
> @@ -453,6 +560,8 @@ static int gicv3_its_init_single_its(struct host_its *hw_its)
>      if ( ret )
>          return ret;
>  
> +    gicv3_its_enable_quirks(hw_its);
> +
>      reg = readq_relaxed(hw_its->its_base + GITS_TYPER);
>      hw_its->devid_bits = GITS_TYPER_DEVICE_ID_BITS(reg);
>      hw_its->evid_bits = GITS_TYPER_EVENT_ID_BITS(reg);
> @@ -530,7 +639,7 @@ static int remove_mapped_guest_device(struct its_device *dev)
>          printk(XENLOG_WARNING "Can't unmap host ITS device 0x%x\n",
>                 dev->host_devid);
>  
> -    xfree(dev->itt_addr);
> +    free_xenheap_pages(dev->itt_addr, dev->itt_order);
>      xfree(dev->pend_irqs);
>      xfree(dev->host_lpi_blocks);
>      xfree(dev);
> @@ -619,6 +728,7 @@ int gicv3_its_map_guest_device(struct domain *d,
>      struct its_device *dev = NULL;
>      struct rb_node **new = &d->arch.vgic.its_devices.rb_node, *parent = NULL;
>      int i, ret = -ENOENT;      /* "i" must be signed to check for >= 0 below. */
> +    unsigned int order;
>  
>      hw_its = gicv3_its_find_by_doorbell(host_doorbell);
>      if ( !hw_its )
> @@ -681,10 +791,13 @@ int gicv3_its_map_guest_device(struct domain *d,
>      ret = -ENOMEM;
>  
>      /* An Interrupt Translation Table needs to be 256-byte aligned. */
> -    itt_addr = _xzalloc(nr_events * hw_its->itte_size, 256);
> +    order = get_order_from_bytes(max(nr_events * hw_its->itte_size, (unsigned long)256));
> +    itt_addr = alloc_xenheap_pages(order, gicv3_its_get_memflags());
>      if ( !itt_addr )
>          goto out_unlock;
>  
> +    memset(itt_addr, 0, PAGE_SIZE << order);
> +
>      clean_and_invalidate_dcache_va_range(itt_addr,
>                                           nr_events * hw_its->itte_size);
>  
> @@ -718,6 +831,7 @@ int gicv3_its_map_guest_device(struct domain *d,
>          goto out_unlock;
>  
>      dev->itt_addr = itt_addr;
> +    dev->itt_order = order;
>      dev->hw_its = hw_its;
>      dev->guest_doorbell = guest_doorbell;
>      dev->guest_devid = guest_devid;
> @@ -775,7 +889,8 @@ out:
>          xfree(dev->pend_irqs);
>          xfree(dev->host_lpi_blocks);
>      }
> -    xfree(itt_addr);
> +    if ( itt_addr )
> +        free_xenheap_pages(itt_addr, order);
>      xfree(dev);
>  
>      return ret;
> @@ -1089,6 +1204,8 @@ int gicv3_its_init(void)
>              return ret;
>      }
>  
> +    gicv3_its_validate_quirks();
> +
>      return 0;
>  }
>  
> diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
> index de4b0eb4a4..a8783e7d95 100644
> --- a/xen/arch/arm/gic-v3-lpi.c
> +++ b/xen/arch/arm/gic-v3-lpi.c
> @@ -227,6 +227,7 @@ void gicv3_lpi_update_host_entry(uint32_t host_lpi, int domain_id,
>  static int gicv3_lpi_allocate_pendtable(unsigned int cpu)
>  {
>      void *pendtable;
> +    unsigned int order;
>  
>      if ( per_cpu(lpi_redist, cpu).pending_table )
>          return -EBUSY;
> @@ -237,7 +238,8 @@ static int gicv3_lpi_allocate_pendtable(unsigned int cpu)
>       * The GICv3 imposes a 64KB alignment requirement, also requires
>       * physically contiguous memory.
>       */
> -    pendtable = _xzalloc(lpi_data.max_host_lpi_ids / 8, SZ_64K);
> +    order = get_order_from_bytes(max(lpi_data.max_host_lpi_ids / 8, (unsigned long)SZ_64K));
> +    pendtable = alloc_xenheap_pages(order, gicv3_its_get_memflags());
>      if ( !pendtable )
>          return -ENOMEM;

I think we might need to zero the memory, as we switched from _xzalloc
to alloc_xenheap_pages.


> @@ -272,9 +274,9 @@ static int gicv3_lpi_set_pendtable(void __iomem *rdist_base)
>  
>      ASSERT(!(virt_to_maddr(pendtable) & ~GENMASK(51, 16)));
>  
> -    val  = GIC_BASER_CACHE_RaWaWb << GICR_PENDBASER_INNER_CACHEABILITY_SHIFT;
> +    val  = gicv3_its_get_cacheability() << GICR_PENDBASER_INNER_CACHEABILITY_SHIFT;
>      val |= GIC_BASER_CACHE_SameAsInner << GICR_PENDBASER_OUTER_CACHEABILITY_SHIFT;
> -    val |= GIC_BASER_InnerShareable << GICR_PENDBASER_SHAREABILITY_SHIFT;
> +    val |= gicv3_its_get_shareability() << GICR_PENDBASER_SHAREABILITY_SHIFT;
>      val |= GICR_PENDBASER_PTZ;
>      val |= virt_to_maddr(pendtable);
>  
> @@ -300,10 +302,11 @@ static int gicv3_lpi_set_pendtable(void __iomem *rdist_base)
>  static int gicv3_lpi_set_proptable(void __iomem * rdist_base)
>  {
>      uint64_t reg;
> +    unsigned int order;
>  
> -    reg  = GIC_BASER_CACHE_RaWaWb << GICR_PROPBASER_INNER_CACHEABILITY_SHIFT;
> +    reg  = gicv3_its_get_cacheability() << GICR_PROPBASER_INNER_CACHEABILITY_SHIFT;
>      reg |= GIC_BASER_CACHE_SameAsInner << GICR_PROPBASER_OUTER_CACHEABILITY_SHIFT;
> -    reg |= GIC_BASER_InnerShareable << GICR_PROPBASER_SHAREABILITY_SHIFT;
> +    reg |= gicv3_its_get_shareability() << GICR_PROPBASER_SHAREABILITY_SHIFT;
>  
>      /*
>       * The property table is shared across all redistributors, so allocate
> @@ -312,7 +315,10 @@ static int gicv3_lpi_set_proptable(void __iomem * rdist_base)
>      if ( !lpi_data.lpi_property )
>      {
>          /* The property table holds one byte per LPI. */
> -        void *table = _xmalloc(lpi_data.max_host_lpi_ids, SZ_4K);
> +        void *table;
> +
> +        order = get_order_from_bytes(max(lpi_data.max_host_lpi_ids, (unsigned long)SZ_4K));

NIT: I am curious whether the unsigned long cast is necessary


> +        table = alloc_xenheap_pages(order, gicv3_its_get_memflags());
>  
>          if ( !table )
>              return -ENOMEM;
> @@ -320,7 +326,7 @@ static int gicv3_lpi_set_proptable(void __iomem * rdist_base)
>          /* Make sure the physical address can be encoded in the register. */
>          if ( (virt_to_maddr(table) & ~GENMASK(51, 12)) )
>          {
> -            xfree(table);
> +            free_xenheap_pages(table, order);
>              return -ERANGE;
>          }
>          memset(table, GIC_PRI_IRQ | LPI_PROP_RES1, MAX_NR_HOST_LPIS);
> diff --git a/xen/arch/arm/include/asm/gic_v3_its.h b/xen/arch/arm/include/asm/gic_v3_its.h
> index c24d4752d0..0737e67aa6 100644
> --- a/xen/arch/arm/include/asm/gic_v3_its.h
> +++ b/xen/arch/arm/include/asm/gic_v3_its.h
> @@ -110,6 +110,9 @@
>  #define HOST_ITS_FLUSH_CMD_QUEUE        (1U << 0)
>  #define HOST_ITS_USES_PTA               (1U << 1)
>  
> +#define HOST_ITS_WORKAROUND_NC_NS       (1U << 0)
> +#define HOST_ITS_WORKAROUND_32BIT_ADDR  (1U << 1)
> +
>  /* We allocate LPIs on the hosts in chunks of 32 to reduce handling overhead. */
>  #define LPI_BLOCK                       32U
>  
> @@ -197,6 +200,11 @@ struct pending_irq *gicv3_assign_guest_event(struct domain *d,
>  void gicv3_lpi_update_host_entry(uint32_t host_lpi, int domain_id,
>                                   uint32_t virt_lpi);
>  
> +/* ITS quirks handling. */
> +uint64_t gicv3_its_get_cacheability(void);
> +uint64_t gicv3_its_get_shareability(void);
> +unsigned int gicv3_its_get_memflags(void);
> +
>  #else
>  
>  #ifdef CONFIG_ACPI
> -- 
> 2.34.1
> 


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 01:35:13 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 01:35:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869201.1280666 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tW3vP-0007rV-KT; Fri, 10 Jan 2025 01:34:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869201.1280666; Fri, 10 Jan 2025 01:34:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tW3vP-0007rO-HD; Fri, 10 Jan 2025 01:34:59 +0000
Received: by outflank-mailman (input) for mailman id 869201;
 Fri, 10 Jan 2025 01:34:58 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=CmC5=UC=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tW3vN-0007rI-Fr
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 01:34:58 +0000
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 17f6cf13-cef3-11ef-99a4-01e77a169b0f;
 Fri, 10 Jan 2025 02:34:54 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 17f6cf13-cef3-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1736472893; x=1736732093;
	bh=tLrguJOShqZcXP2ov0aLkOlT3deeWIUvIRvhQQx9OIo=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=WgIW/Gt2NtQTTnW6TxQoEd29eozkNNG/QLvkDII+wwpiZNvW/r/pkLeioPQ3jKOqP
	 dcWkOfPX+bPBSZDWjEcIYyAxn4wf1G75prfpExfyppoS1p+Jl8QnHBH9c5PuKb4qzx
	 e/rIZf9+mtLox2MC8Fqp0mf1RfYYDpnNH2L9htjUIllQQedi5vggHC/YN7rcsbr8ES
	 4meS8dmGK8nh1bBPJtuDqgy4wLrdVswvNlipaJaNpUO7RWqD4KCHbQwLMYLL9dNTwP
	 zIz/6vQhBiTgnawf9xTje9yN1MK+7n+dXsGPaWrlmQU2RMj60MAofGg/aZ9JDZtOFR
	 8JSEBSiMwC46g==
Date: Fri, 10 Jan 2025 01:34:49 +0000
To: Jan Beulich <jbeulich@suse.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: Stefano Stabellini <sstabellini@kernel.org>, dmukhin@ford.com, xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>, Michal Orzel <michal.orzel@amd.com>, =?utf-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Subject: Re: [PATCH v2 20/35] xen/console: introduce console_owner_domid()
Message-ID: <fEu9aEr73Vo1rvovrlR8uVR0cwOfWI1I6EfoFsrF3Vv776ylHUWRC7Asae-btnRTcfagSx9h-FZOtvS0aSa0zkBnRWHBP6sm4jGT8nRTrCk=@proton.me>
In-Reply-To: <e936ebe8-f729-4878-843e-639755b2fefb@suse.com>
References: <20241205-vuart-ns8250-v1-20-e9aa923127eb@ford.com> <c39c0c6f-2fab-46e8-9563-c91fe890e87f@suse.com> <alpine.DEB.2.22.394.2501071533060.133435@ubuntu-linux-20-04-desktop> <a2fa92ff-a5fb-4adc-86aa-1481ebec92fe@suse.com> <Z34xhkNu5YLyEzut@macbook.local> <121ae72e-6229-40a4-8b9f-4f8b0764b712@suse.com> <Z344xgqtpNZIDxHD@macbook.local> <m5iIn0DzBY1VE3oW8MMk5aJD5yovtFe2u7eorkGQVf0czY2gzIYl9k2aKmrdyh1AG6YAgyasVn86Js-vUQyudqjHY7bRYE1hXdCkdFVF0U8=@proton.me> <e936ebe8-f729-4878-843e-639755b2fefb@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 0d08b10c8ce2db5f6d17488f569651accd1a411a
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Thursday, January 9th, 2025 at 12:27 AM, Jan Beulich <jbeulich@suse.com>=
 wrote:

>
>
> On 08.01.2025 23:15, Denis Mukhin wrote:
>
> > On Wednesday, January 8th, 2025 at 12:35 AM, Roger Pau Monn=C3=A9 roger=
.pau@citrix.com wrote:
> >
> > > On Wed, Jan 08, 2025 at 09:13:02AM +0100, Jan Beulich wrote:
> > >
> > > > On 08.01.2025 09:04, Roger Pau Monn=C3=A9 wrote:
> > > >
> > > > > On Wed, Jan 08, 2025 at 08:28:32AM +0100, Jan Beulich wrote:
> > > > >
> > > > > > On 08.01.2025 00:40, Stefano Stabellini wrote:
> > > > > >
> > > > > > > On Tue, 7 Jan 2025, Jan Beulich wrote:
> > > > > > >
> > > > > > > > On 06.01.2025 19:48, Stefano Stabellini wrote:
> > > > > > > >
> > > > > > > > > On Mon, 6 Jan 2025, Jan Beulich wrote:
> > > > > > > > >
> > > > > > > > > > On 04.01.2025 05:15, Denis Mukhin wrote:
> > > > > > > > > >
> > > > > > > > > > > On Tuesday, December 10th, 2024 at 11:28 PM, Jan Beul=
ich jbeulich@suse.com wrote:
> > > > > > > > > > >
> > > > > > > > > > > > On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrot=
e:
> > > > > > > > > > > >
> > > > > > > > > > > > > From: Denis Mukhin dmukhin@ford.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > console_owner_domid() is introduced to obtain the=
 "console owner" domain ID.
> > > > > > > > > > > > >
> > > > > > > > > > > > > The call is used in NS8250 emulator to identify t=
he case when physical xen
> > > > > > > > > > > > > console focus is owned by the domain w/ NS8250 em=
ulator, in which case,
> > > > > > > > > > > > > messages from guest OS are formatted w/o '(XEN)' =
prefix.
> > > > > > > > > > > >
> > > > > > > > > > > > Such messages ought to be processed through guest_p=
rintk(), which wants a
> > > > > > > > > > > > domain pointer, not a domid_t anyway. Plus isn't th=
at going to be
> > > > > > > > > > > > current->domain anyway at the callsite, eliminating=
 the need for such a
> > > > > > > > > > > >
> > > > > > > > > > > > helper altogether?
> > > > > > > > > > >
> > > > > > > > > > > If the current domain is owning the physical console =
and printing, say, Linux
> > > > > > > > > > > login prompt, there's no need to add "(XEN)" for ever=
y printout; adding timestamps
> > > > > > > > > > > can be disabled from Xen command line.
> > > > > > > > > >
> > > > > > > > > > Surely there shouldn't be (XEN), but without (d<N>) it'=
ll be ambiguous in a log
> > > > > > > > > > which domain a message came from. As long as only Dom0 =
messages are left un-
> > > > > > > > > > prefixed, that's likely fine. Yet as soon as multiple d=
omains can issue such
> > > > > > > > > > messages (and have console "focus") I think the prefix =
needs to be there.
> > > > > > > > >
> > > > > > > > > It looks like we are aligned on the desired behavior,
> > > > > > > >
> > > > > > > > Hmm, no, I don't think we are. I don't ...
> > > > > > > >
> > > > > > > > > but for clarity,
> > > > > > > > > see https://marc.info/?l=3Dxen-devel&m=3D173405161613716,=
 also copy/pasted
> > > > > > > > > here:
> > > > > > > > >
> > > > > > > > > I think we should provide a consistent behavior across ar=
chitectures.
> > > > > > > > > The current behavior with vpl011 and dom0less on ARM is t=
he following:
> > > > > > > > >
> > > > > > > > > - no prefix for Dom0 output
> > > > > > > > > - DOM$NUM for DomUs when not in focus, otherwise no prefi=
x
> > > > > > > >
> > > > > > > > ... view this model as a desirable one. It leaves room for =
ambiguity.
> > > > > > >
> > > > > > > Adding a few more people in CC for feedback.
> > > > > > >
> > > > > > > My priority is to keep the architectures aligned. It might be=
 OK to
> > > > > > > change output format, but then let's do it uniformly on ARM a=
s well.
> > > > > > >
> > > > > > > Jan, please clarify what you think would be better than the a=
bove. Is it
> > > > > > > the following? I don't think I understood your preference.
> > > > > > >
> > > > > > > - DOM$NUM for Dom0 and DomUs when not in focus, otherwise no =
prefix
> > > > > >
> > > > > > No, I mean like we have it with guest_printk() today. (XEN) for=
 Xen's
> > > > > > own messages, (d<N>) for ordinary domains' ones, and no prefix
> > > > > > exclusively for the hardware/control domain. What is best to do=
 when
> > > > > > hardware and control domains are distinct I'm uncertain - I'd b=
e
> > > > > > inclined to suggest that the hardware domain then stay the one =
without
> > > > > > any prefix.
> > > > >
> > > > > One concern I have with this approach is whether the addition of =
the
> > > > > (d<N>) prefixes will skew output of interactive applications. So =
far
> > > > > the prefix is added to output from all domains different than dom=
0
> > > > > because the console is not interactive for them, and hence no inp=
ut
> > > > > can be consumed.
> > > >
> > > > Hmm, that's an aspect I have to admit I didn't think of.
> > > >
> > > > > If that changes however, and domains different than dom0 can get =
input
> > > > > from the Xen console then I wonder how much the added prefix will=
 skew
> > > > > output. Another possible option would be to not print the prefix =
for
> > > > > the domain that has the console input assigned (current target), =
and
> > > > > print it for all other domains (even for dom0 when not in focus).
> > > >
> > > > That's largely what aiui was proposed. My extra requirement there w=
ould
> > > > then be that we make sure a log message is always emitted when cons=
ole
> > > > focus shifts, so it's possible to identify the owner for any part o=
f
> > > > the log.
> > >
> > > Indeed, printing console input shifting should be a requirement
> > > regardless of how we decide to print the prefix.
> >
> > Console input focus switch is indicated after pressing Crtl+aaa, e.g.:
> > [[
> > ...
> > (XEN) [15359.353038] *** Serial input to Xen (type 'CTRL-aaa' to switch=
 input)
> > (XEN) [15361.176754] *** Serial input to DOM0 (type 'CTRL-aaa' to switc=
h input)
> > (XEN) [15711.297202] *** Serial input to DOM1 (type 'CTRL-aaa' to switc=
h input)
> > ...
> > ]]
>
>
> And just to double check: These messages aren't affected by "loglvl=3D" s=
ettings,
> i.e. they're always there (as asked for earlier; see context above)?

`loglvl=3Dnone` disables console switch indication (even w/o my patches).
I will fix that.

Thanks!

>
> Jan


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 01:39:44 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 01:39:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869210.1280676 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tW400-0008Rj-3x; Fri, 10 Jan 2025 01:39:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869210.1280676; Fri, 10 Jan 2025 01:39:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tW400-0008Rc-1P; Fri, 10 Jan 2025 01:39:44 +0000
Received: by outflank-mailman (input) for mailman id 869210;
 Fri, 10 Jan 2025 01:39: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 <SRS0=CmC5=UC=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tW3zz-0008RW-4k
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 01:39:43 +0000
Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c2bda1d0-cef3-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 02:39:41 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c2bda1d0-cef3-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1736473179; x=1736732379;
	bh=UZCiOtNyBFgwmB0bA+RI2qQUT6B61jfzP8IOQSKi5jk=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=FAnbUF8d4b0cY9FM57C786UUtlIKNwygMNEyP/BWKpvHudQhleGvdLJikhB89oLyq
	 k/9h/Jp82CjSepAPwqcT6p1uT9hudvez0XEjkyoKPpK/cBqb1yuHeaIXNwqfKkWklw
	 u/chFQFm6HMh71xlQLBD1gwJXuBEgtQrpR8JyEucxSfH6URc8tgHww7PRFjCx0sqHj
	 5evITkFXSwRZFq5v5olv3GnWsg8uWOnpViAijWpMx1pJjgBqIkgLEyrCnKFdkZa+DW
	 CqGYkPIihQPYkp2b7tVARVHxThItAXbCOMzztN9C9T4Fkm5XF3FrVQneAwiT/h26ll
	 yPOXw3tjWzF5A==
Date: Fri, 10 Jan 2025 01:39:36 +0000
To: Stefano Stabellini <sstabellini@kernel.org>
From: Denis Mukhin <dmkhn@proton.me>
Cc: =?utf-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, Jan Beulich <jbeulich@suse.com>, dmukhin@ford.com, xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>, Michal Orzel <michal.orzel@amd.com>
Subject: Re: [PATCH v2 20/35] xen/console: introduce console_owner_domid()
Message-ID: <cKowJ0lJhKcoHoaPgGOX4xdDu6PCcg7MVnhS_y5L4mVGJfNlG-xXJdSGXJkIys5OqdCeSdiYtNQmI4znkjXLaqtqHefgvM33MbvMX700nk0=@proton.me>
In-Reply-To: <alpine.DEB.2.22.394.2501091534090.133435@ubuntu-linux-20-04-desktop>
References: <8a5a5a0f-72b0-4336-b0d2-142254319242@suse.com> <a2fa92ff-a5fb-4adc-86aa-1481ebec92fe@suse.com> <Z34xhkNu5YLyEzut@macbook.local> <121ae72e-6229-40a4-8b9f-4f8b0764b712@suse.com> <Z344xgqtpNZIDxHD@macbook.local> <m5iIn0DzBY1VE3oW8MMk5aJD5yovtFe2u7eorkGQVf0czY2gzIYl9k2aKmrdyh1AG6YAgyasVn86Js-vUQyudqjHY7bRYE1hXdCkdFVF0U8=@proton.me> <alpine.DEB.2.22.394.2501081615050.133435@ubuntu-linux-20-04-desktop> <Z3-Dcraxc55vi-ur@macbook.local> <alpine.DEB.2.22.394.2501091534090.133435@ubuntu-linux-20-04-desktop>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: aebd2e3c7115c982923ac7776c9ea7f0b1dd45be
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


On Thursday, January 9th, 2025 at 3:46 PM, Stefano Stabellini <sstabellini@=
kernel.org> wrote:

>=20
>=20
> On Thu, 9 Jan 2025, Roger Pau Monn=C3=A9 wrote:
>=20
> > On Wed, Jan 08, 2025 at 04:29:24PM -0800, Stefano Stabellini wrote:
> >=20
> > > On Wed, 8 Jan 2025, Denis Mukhin wrote:
> > >=20
> > > > On Wednesday, January 8th, 2025 at 12:35 AM, Roger Pau Monn=C3=
=A9 roger.pau@citrix.com wrote:
> > > >=20
> > > > > On Wed, Jan 08, 2025 at 09:13:02AM +0100, Jan Beulich wrote:
> > > > >=20
> > > > > > On 08.01.2025 09:04, Roger Pau Monn=C3=A9 wrote:
> > > > > >=20
> > > > > > > On Wed, Jan 08, 2025 at 08:28:32AM +0100, Jan Beulich wrote:
> > > > > > >=20
> > > > > > > > On 08.01.2025 00:40, Stefano Stabellini wrote:
> > > > > > > >=20
> > > > > > > > > On Tue, 7 Jan 2025, Jan Beulich wrote:
> > > > > > > > >=20
> > > > > > > > > > On 06.01.2025 19:48, Stefano Stabellini wrote:
> > > > > > > > > >=20
> > > > > > > > > > > On Mon, 6 Jan 2025, Jan Beulich wrote:
> > > > > > > > > > >=20
> > > > > > > > > > > > On 04.01.2025 05:15, Denis Mukhin wrote:
> > > > > > > > > > > >=20
> > > > > > > > > > > > > On Tuesday, December 10th, 2024 at 11:28 PM, Jan =
Beulich jbeulich@suse.com wrote:
> > > > > > > > > > > > >=20
> > > > > > > > > > > > > > On 06.12.2024 05:41, Denis Mukhin via B4 Relay =
wrote:
> > > > > > > > > > > > > >=20
> > > > > > > > > > > > > > > From: Denis Mukhin dmukhin@ford.com
> > > > > > > > > > > > > > >=20
> > > > > > > > > > > > > > > console_owner_domid() is introduced to obtain=
 the "console owner" domain ID.
> > > > > > > > > > > > > > >=20
> > > > > > > > > > > > > > > The call is used in NS8250 emulator to identi=
fy the case when physical xen
> > > > > > > > > > > > > > > console focus is owned by the domain w/ NS825=
0 emulator, in which case,
> > > > > > > > > > > > > > > messages from guest OS are formatted w/o '(XE=
N)' prefix.
> > > > > > > > > > > > > >=20
> > > > > > > > > > > > > > Such messages ought to be processed through gue=
st_printk(), which wants a
> > > > > > > > > > > > > > domain pointer, not a domid_t anyway. Plus isn'=
t that going to be
> > > > > > > > > > > > > > current->domain anyway at the callsite, elimina=
ting the need for such a
> > > > > > > > > > > > > >=20
> > > > > > > > > > > > > > helper altogether?
> > > > > > > > > > > > >=20
> > > > > > > > > > > > > If the current domain is owning the physical cons=
ole and printing, say, Linux
> > > > > > > > > > > > > login prompt, there's no need to add "(XEN)" for =
every printout; adding timestamps
> > > > > > > > > > > > > can be disabled from Xen command line.
> > > > > > > > > > > >=20
> > > > > > > > > > > > Surely there shouldn't be (XEN), but without (d<N>)=
 it'll be ambiguous in a log
> > > > > > > > > > > > which domain a message came from. As long as only D=
om0 messages are left un-
> > > > > > > > > > > > prefixed, that's likely fine. Yet as soon as multip=
le domains can issue such
> > > > > > > > > > > > messages (and have console "focus") I think the pre=
fix needs to be there.
> > > > > > > > > > >=20
> > > > > > > > > > > It looks like we are aligned on the desired behavior,
> > > > > > > > > >=20
> > > > > > > > > > Hmm, no, I don't think we are. I don't ...
> > > > > > > > > >=20
> > > > > > > > > > > but for clarity,
> > > > > > > > > > > see https://marc.info/?l=3Dxen-devel&m=3D173405161613=
716, also copy/pasted
> > > > > > > > > > > here:
> > > > > > > > > > >=20
> > > > > > > > > > > I think we should provide a consistent behavior acros=
s architectures.
> > > > > > > > > > > The current behavior with vpl011 and dom0less on ARM =
is the following:
> > > > > > > > > > >=20
> > > > > > > > > > > - no prefix for Dom0 output
> > > > > > > > > > > - DOM$NUM for DomUs when not in focus, otherwise no p=
refix
> > > > > > > > > >=20
> > > > > > > > > > ... view this model as a desirable one. It leaves room =
for ambiguity.
> > > > > > > > >=20
> > > > > > > > > Adding a few more people in CC for feedback.
> > > > > > > > >=20
> > > > > > > > > My priority is to keep the architectures aligned. It migh=
t be OK to
> > > > > > > > > change output format, but then let's do it uniformly on A=
RM as well.
> > > > > > > > >=20
> > > > > > > > > Jan, please clarify what you think would be better than t=
he above. Is it
> > > > > > > > > the following? I don't think I understood your preference=
.
> > > > > > > > >=20
> > > > > > > > > - DOM$NUM for Dom0 and DomUs when not in focus, otherwise=
 no prefix
> > > > > > > >=20
> > > > > > > > No, I mean like we have it with guest_printk() today. (XEN)=
 for Xen's
> > > > > > > > own messages, (d<N>) for ordinary domains' ones, and no pre=
fix
> > > > > > > > exclusively for the hardware/control domain. What is best t=
o do when
> > > > > > > > hardware and control domains are distinct I'm uncertain - I=
'd be
> > > > > > > > inclined to suggest that the hardware domain then stay the =
one without
> > > > > > > > any prefix.
> > > > > > >=20
> > > > > > > One concern I have with this approach is whether the addition=
 of the
> > > > > > > (d<N>) prefixes will skew output of interactive applications.=
 So far
> > > > > > > the prefix is added to output from all domains different than=
 dom0
> > > > > > > because the console is not interactive for them, and hence no=
 input
> > > > > > > can be consumed.
> > > > > >=20
> > > > > > Hmm, that's an aspect I have to admit I didn't think of.
> > > > > >=20
> > > > > > > If that changes however, and domains different than dom0 can =
get input
> > > > > > > from the Xen console then I wonder how much the added prefix =
will skew
> > > > > > > output. Another possible option would be to not print the pre=
fix for
> > > > > > > the domain that has the console input assigned (current targe=
t), and
> > > > > > > print it for all other domains (even for dom0 when not in foc=
us).
> > > > > >=20
> > > > > > That's largely what aiui was proposed. My extra requirement the=
re would
> > > > > > then be that we make sure a log message is always emitted when =
console
> > > > > > focus shifts, so it's possible to identify the owner for any pa=
rt of
> > > > > > the log.
> > > > >=20
> > > > > Indeed, printing console input shifting should be a requirement
> > > > > regardless of how we decide to print the prefix.
> > > >=20
> > > > Console input focus switch is indicated after pressing Crtl+aaa, e.=
g.:
> > > > [[
> > > > ...
> > > > (XEN) [15359.353038] *** Serial input to Xen (type 'CTRL-aaa' to sw=
itch input)
> > > > (XEN) [15361.176754] *** Serial input to DOM0 (type 'CTRL-aaa' to s=
witch input)
> > > > (XEN) [15711.297202] *** Serial input to DOM1 (type 'CTRL-aaa' to s=
witch input)
> > > > ...
> > > > ]]
> > >=20
> > > Roger, Jan, you should use Xen Dom0less more :-) This is the way it
> > > already works on ARM. Let me expand on my earlier message that was to=
o
> > > terse.
> >=20
> > Hehe, I should use ARM more in general I think :).
> >=20
> > > At boot time, Xen prints messages with the (XEN) prefix as usual:
> > >=20
> > > (XEN) Brought up 4 CPUs
> > >=20
> > > When Dom0 starts, it has not prefix (and has input by default):
> > >=20
> > > [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
> > >=20
> > > When a DomU starts, it has the following prefix (and doesn't have
> > > input):
> > >=20
> > > (XEN) DOM1: [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0=
x410fd034]
> > >=20
> > > Eventually, both Linuxes finish booting, you can login into Dom0 as
> > > usual. Messages from Dom1, if any, are still printed with (XEN) DOM1 =
as
> > > prefix.
> > >=20
> > > You can switch input to Dom1 with Ctrx-aaa, the same way that you do
> > > today to switch between Xen and Dom0. Xen prints a message:
> > >=20
> > > (XEN) *** Serial input to DOM1 (type 'CTRL-a' three times to switch i=
nput)
> > >=20
> > > Now, as you type, you send characters to Dom1. And Dom1 doesn't have =
the
> > > DOM1 prefix any longer, while it is still has (XEN) because the messa=
ge
> > > is printed by Xen on behalf of the domain:
> > >=20
> > > (XEN) / # echo hello world
> > > (XEN) hello world
> > >=20
> > > If Dom0 prints anything in the backgrounds, it shows without prefixes=
:
> > >=20
> > > hello world from dom0
> > >=20
> > > If another domain, dom2, prints anything in the background, it shows
> > > with (XEN) DOM2 prefix:
> > >=20
> > > (XEN) DOM2: hello from dom2
> > >=20
> > > I think it makes sense to be consistent across architectures and we
> > > should default to the same behavior on x86 too. If we want to make
> > > improvements, the one thing I could potentially see changing is addin=
g a
> > > DOM0 prefix to Dom0 messages when Dom0 does not have input. If we do
> > > that, let's do it on both ARM and x86 architectures.
> >=20
> > The usual prefix is (d<domid>) IIRC, that's what guest_printk() uses,
> > is there any reason dom0less uses "(XEN) DOM<domid>:" instead of the
> > guest_printk() prefix?
> >=20
> > My preference would be use to (d<domid>) prefix for any guest output
> > that doesn't belong to the domain that's the recipient of the input
> > (iow: not in console input focus). And drop the (XEN) prefix from
> > guest output.
> >=20
> > The rest looks all sensible to me. I think we should avoid adding any
> > prefixes to guest output when it has the console focus, as otherwise
> > interactive applications might not work correctly.
>=20
>=20
> I am OK with what you describe, I would kindly ask Denis to also modify
> ARM vpl011 to match. Looking at the code, I don't know where the (XEN)
> prefix is coming from, but for the DOM<domid> to d<domid> change, it

Yep, I implemented such logic in v3 iteration of the series:
  https://lore.kernel.org/xen-devel/20250103-vuart-ns8250-v3-v1-24-c5d36b31=
d66c@ford.com/

printk() adds "(XEN)" prefix (drivers/char/console.c)

>=20
> would be probably something like this:
>=20
> diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
> index 1fc3114cce..959d172e96 100644
> --- a/xen/arch/arm/vpl011.c
> +++ b/xen/arch/arm/vpl011.c
> @@ -107,7 +107,10 @@ static void vpl011_write_data_xen(struct domain *d, =
uint8_t data)
> if ( data !=3D '\n' )
> intf->out[intf->out_prod++] =3D '\n';
>=20
> intf->out[intf->out_prod++] =3D '\0';
>=20
> - printk("DOM%u: %s", d->domain_id, intf->out);
>=20
> + if ( in_focus(d) )
> + printk("%s", intf->out);
>=20
> + else
> + guest_printk("%s", d, intf->out);
>=20
> intf->out_prod =3D 0;
>=20
> }
> }
>=20
> There is also one additional change needed to add the (d<domid>) prefix
>=20
> for dom0 when not in focus. The Dom0 print typically comes from

This change I missed. Thanks!

> do_console_io, so in pseudocode we would need something like:
>=20
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index 7da8c5296f..5d250b642a 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -643,6 +643,9 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARA=
M(char) buffer,
> /* Use direct console output as it could be interactive */
> nrspin_lock_irq(&console_lock);
>=20
> + if ( !in_focus(cd) )
> + add_prefix(kbuf, "(d0) ");
> +
> console_serial_puts(kbuf, kcount);
> video_puts(kbuf, kcount);


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 07:10:44 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 07:10:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869232.1280686 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tW9A4-0006jz-1V; Fri, 10 Jan 2025 07:10:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869232.1280686; Fri, 10 Jan 2025 07:10:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tW9A3-0006js-Ue; Fri, 10 Jan 2025 07:10:27 +0000
Received: by outflank-mailman (input) for mailman id 869232;
 Fri, 10 Jan 2025 07:10:26 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=7APX=UC=amd.com=Jiqian.Chen@srs-se1.protection.inumbo.net>)
 id 1tW9A2-0006jm-2C
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 07:10:26 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20602.outbound.protection.outlook.com
 [2a01:111:f403:2415::602])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f59c7edf-cf21-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 08:10:24 +0100 (CET)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by CY5PR12MB6033.namprd12.prod.outlook.com (2603:10b6:930:2f::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8335.11; Fri, 10 Jan
 2025 07:10:20 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285%4]) with mapi id 15.20.8335.011; Fri, 10 Jan 2025
 07:10:20 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f59c7edf-cf21-11ef-a0df-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=U94gknPmAEq7HvszIJhRv4pvp9xt+mZuJYygWjSMXzu+OopoOFcJEdfUEyC0IzrQieLm0aL46NfWD+QVRegpweU7f51mdaEsxeEsUSFUUyVSxX02Gk6Mwb30zs2j0zDQxFyKqq11SA0WCrw7XRs9leI+rUupIjYn1UDqSdRlN3SJ2wcWv4HIx0T2AyESiPyEqfL1WUtZyIt42Hurz8zt3T5crnm/1RbuIpA1ubxicgYWhcb49rUbzD11YLW3VUNkeZr2N+jd+9U0F7II9iNuLHrU6l2haVlOZRjgQwMrKL6GMkLZpEbgJ3ybUOOrPrsfXLUaWYGdjQ1JP/EWZ24Vhw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=c1V2XdQodbknOaVFFS21dJUm31ycTGpj/1JY2ZLwAy8=;
 b=eR6utBJJCoYOfIgN67h4dTl9gMOKPSLcgLjxw8S3fH6jOz7PjKO0xI+754guug9Bs6TtNEN3UnU7yvcRyw46xTBkyDyk/+jGo0YOMotNK4bWO5b0NtXmg4HJKetZHItsxwKDkjobRjO5OUNsbAONAOpVAffYv94mZg3XLko9EXYUv36QIihL9Dx3T+UZUvLZZoFhrbLOCKS7OmoF9IAIgXi2xM431XEJdHnfselFHbpJyLW6eQQSnfbQQLOnQGxcKA9h5QxbPehqXcT30VF8fITYWn1HzVzpSCRdubTQbUn0Bmm+/WeQexZn0603AnW2VY4xFuFutF76ux8pvvy7Yg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=c1V2XdQodbknOaVFFS21dJUm31ycTGpj/1JY2ZLwAy8=;
 b=k6M+pwABLDx4HE0bM6/Qs230zJmQ+QdtEQ1Ss371QkI8HrheVCJz+/B8gm/7wTRKD6nLeF6SWoj/EkqTgvw+VA7pgA2zN5okLf4AYgUv92xTYrMlWYsvpShz1RlfrG4RVXrOKKj9Skw+I/faaKUAb/TS1mjHP3QJvAg9JhdZlh4=
From: "Chen, Jiqian" <Jiqian.Chen@amd.com>
To: Jan Beulich <jbeulich@suse.com>, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	<roger.pau@citrix.com>
CC: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>, "Huang, Ray"
	<Ray.Huang@amd.com>, "xen-devel@lists.xenproject.org"
	<xen-devel@lists.xenproject.org>, "Chen, Jiqian" <Jiqian.Chen@amd.com>
Subject: Re: [PATCH v4] vpci: Add resizable bar support
Thread-Topic: [PATCH v4] vpci: Add resizable bar support
Thread-Index: AQHbUdYKjT75oVKG00CoBVtVLX93obMLM/yAgAUH7YA=
Date: Fri, 10 Jan 2025 07:10:20 +0000
Message-ID:
 <BL1PR12MB5849D215025D7CD9A5DA4B22E71C2@BL1PR12MB5849.namprd12.prod.outlook.com>
References: <20241219052143.3161332-1-Jiqian.Chen@amd.com>
 <d904c816-da83-418a-9bff-9988660af546@suse.com>
In-Reply-To: <d904c816-da83-418a-9bff-9988660af546@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com
 (15.20.8335.010)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|CY5PR12MB6033:EE_
x-ms-office365-filtering-correlation-id: 8bdf3853-4ceb-4bcc-9b4b-08dd3145d855
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?SkQ1WVJiRWhQMFdsMTJhNjIvL1pVcVNLeE9YeXFBRHNiNGRibFp5ZDRoelh5?=
 =?utf-8?B?eU1idXphSkZrZEVYc1VhODAyTTA3SXZiTDBqWllvSTNqMG5DZi9jVGpLVFk5?=
 =?utf-8?B?bWNsOStwV09NOVp3c3JrMWVmSjVkNTZUK0doRjNBMzVmSTZMZG92YUJiTnky?=
 =?utf-8?B?dDlpREx5NHRaYUtmZEhndFNDOG9rZGw0NzRBSkdDdmxyMGhqajBKZEhicm9E?=
 =?utf-8?B?aWc4emN6cGtGOXZFbzlUOUtKQUtOSlZNamRVQkc4bTgyM296R0RWN0JaOTdl?=
 =?utf-8?B?QkN2Y0hIa1FTSm9jMXc1dVppYXg4QnNFT0Mzem82QXpWWXZ0enJDUEJqSmp5?=
 =?utf-8?B?TWRxdGltK1BMRklNR3FXMTV5ZVFsNFRhVmxxZmszQnRpSWFERzUzOENJMW1M?=
 =?utf-8?B?aFp3a3pOVEU4cWFxWEczMmtvanNiclo0cHRYNU9veXV3NXpKRXhIZG1neHQw?=
 =?utf-8?B?N1pnMUFmZ2t3d1BnNjdlMnh3Wkh4MXJlVXpNWkVZNi9PTVZoMVlXTjU4SXMr?=
 =?utf-8?B?TTNFYm1GUFR4bVZiRUJjOUljdVN6dDNpMm54T3FKb3M0WWhVYjJPdTFzOUFC?=
 =?utf-8?B?dVFCZmJPMWliZEE0S1lkaDUwNkJSdm04NnZrbkhpMUY1cUlrakw4L1FhOE04?=
 =?utf-8?B?eWFtNEhISzRkbnVQeHNDOS9GOVZBdHRyWGhuVHIyV21yM3dObG5iWDlsc0h6?=
 =?utf-8?B?cjR6MU0wWTB3Z3YyeUJwWllFT0sza2VCWWRsMU9yZWczdFhZUzhtOFNqV3M0?=
 =?utf-8?B?YlpYazlFNTNNVlVhT1k4NmlFc3JlSUtac3dJTUdGS0lpald6c0RZd3NucjNh?=
 =?utf-8?B?bGU5cE9wMk9MUmI4Yit0akdId25maE1WdnY4SEtDT2hPbk51UDZoaS9HM0F1?=
 =?utf-8?B?ZklDd0h6b1ovcklqWGFkY3VPc0pwZGxUU1ZQWjUxM2NYUUxZRmlvSDkwOVZ0?=
 =?utf-8?B?MzcxVGFlUmhkZjdvckZma0UrbUI2TUlCTjBHTW03SWtkQllsL3pTajNSalR5?=
 =?utf-8?B?cTJVNnpHY0tZTFhCTHlTcitBQUd4QmRzOWJScWVram51R0ZOVzVVSG5UWkcx?=
 =?utf-8?B?UnUzQ2tYRFRPRHlST2RLQ2I2Rm9WSjVKR2drT2ZsREJJR0hremRHNnprNU92?=
 =?utf-8?B?SUpMZENCakhDSzVuV25IZ0xMVXpyWTJmblFWTzFIWUF5NmhCNHlvRy8rSWNF?=
 =?utf-8?B?YTl1WkU2QVc3dDYzRU9BT0JTYWFhY285dlYrUWQ3OWc3SlpweUNDUnRJR1Mw?=
 =?utf-8?B?dWpLNUNwWDFGTlFNb1NwTVdBUUFraHFVRHEyNklhOVlCZ04vMDdwWEo4czRz?=
 =?utf-8?B?ZnZtMnZaUHIzWHhobDBsZ2poQi9ZWWdXYlJCVFJjeEdteFFwUmd2S2VkZlJ0?=
 =?utf-8?B?blRDWDBmejJtS0NZWlhrb3RKVFQwaXVJS0IxKytXM3B6UzlDOXlMbDNkOTJO?=
 =?utf-8?B?S09TcWhlNVE4Vm9MQ1ZkUlVWaVZVR012cnpUbWJxemlheitsc1dXSzA3NVVH?=
 =?utf-8?B?eHU3VWdZamd1OWJZalJuVVBHd3VJc3UyTG1OTjJHWmpjNmJrTDdmRUxTOXgx?=
 =?utf-8?B?cGdaT1JmTVdvS2owcE9UdlB3a3gyUlNRUUVNaEZOZ1NlQllPSnVZOWpFQ3Rx?=
 =?utf-8?B?MU1wYVBZRklTeEg4NW9wSkZ5ZEpSWEdySTIrazdnWFlYYnZIWEtLNFl4cWIx?=
 =?utf-8?B?WmQ0YU12ZlVCMTZBRXNZOFNoVjF6WGJES3NYRlVCWk5sd0NvRnJKaWQ3b1Rv?=
 =?utf-8?B?djdPWjdXRzk5aStIWGJCS3I4ZE1SRnllei9zWEYva3FubzFTWTgvNWpHRlZQ?=
 =?utf-8?B?Y1kzUmh2aEF3S3NMV2hIQk5VeVkxZjlMK0dOSnZJRWw0a1p1WkpiSWxESkNE?=
 =?utf-8?B?aWdKTDhRSFNqQnp6VWx3Y1dQZnQvZFhRKytlS1JyeVdjSk5YUGhGMHMweWV4?=
 =?utf-8?Q?T/9bBZ0BRVSYppPzq88Dx5tMMrM6Rc29?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?S0lIMVIrVkdkUEVBeEgrd2JMMythSlkzRDdqT0pVamRDdTRkaC94SjMzWmpr?=
 =?utf-8?B?VEsxdlNPZXV4enpKUC9Rc1AxMldTUXFjY0VFZUVvbGhBOEg1N21IK3Y2clVx?=
 =?utf-8?B?Tit2bmVDNGx5S0QxS3RqTDhBamduOGwyOUxZK2NhWm9XVUpEVFU3OXB3RHBR?=
 =?utf-8?B?ZC9ydysvNkhYdVRCbU9zdzdTd1JyOHBOemhXcGpvNjQ4V0orak5uZFVCL1l2?=
 =?utf-8?B?ckFyQVFGSjJ0L0lMUy95Y3BKMGpyWG90dHJhcWEycWFHbW81UkYvZkZ6K29y?=
 =?utf-8?B?RDJGU2lTaTg0OGZjRlA1NzRYTVlrQklZS0hCQ3dFNm1EVDg1NGdDU3hrY2xq?=
 =?utf-8?B?Y2pFaHBDUktnS1FCMnN1UjE1UWc1b29DK0E3N0xuN0hVQlVHZ1piaFZPUm1s?=
 =?utf-8?B?Y2pjUjRCWUdCMmxFd09jZDhPbjZaVCtLdTVOVDVyMllFM0psbFU5RXZ4Z3NY?=
 =?utf-8?B?SGcwdEp0RXNJd1BPeDhLM2tLQm1INjhEclZ4RU90VDdlM0FVVW14WDFON0JE?=
 =?utf-8?B?eStKNE9GMWFkWktJU0JwQ0Z2Znh5U29VZENOdGdsODg0NGlQSTNNS1JPWjhH?=
 =?utf-8?B?a0dJRENYVmtjc2EyTlQzVlA4SmpSSktSU3EvSFVwK1pIaWRRNnI0VHZSTVhx?=
 =?utf-8?B?MUJaaWhXMkZRay9vK2dpT2VhekkraVY5RmhLTWU2K2lQU1ZHMmRhVTVwbWVB?=
 =?utf-8?B?VEFSWVpjODZqSmhaQWxqZE1jWVF4Y2w3ZC9nRzIwcDN1RHBjWFdDSVo0ZTRx?=
 =?utf-8?B?N1dNckVpQ2xqNlg0SVdHRkF3Q2xvT3lMZ2JobzJUV050cVFhc3kzdHJyRzZt?=
 =?utf-8?B?OE5ZNldneTNFMHJVUktGSTZZZTA4dDQvVCtxb3J5TW00Q3piNkIvOEpuSGgx?=
 =?utf-8?B?bWUyU3RtdXZnemlIdjgxYXJwaHZqbjR5MjZmQjBra2xNcHFrWm1aN3Q1RnU5?=
 =?utf-8?B?NHdPM2VMUW12bnA1c09sTEUzMUxRSnczdjBaaU5vcERJZTczR2F5YjJYaFpM?=
 =?utf-8?B?QWIzczBRQkJ6TnZaK0ZueGVHNmlFYXIvWFVYaDVjdlZZNFRzM2U3TzVWaEdy?=
 =?utf-8?B?aXlRRTF1UmhKenpWZWQyV2Z5YWdtZnJpdzVIUXpLS0xWTi95QzFVcmt3ZnBm?=
 =?utf-8?B?d20xaFRqUnpXSGV6N0hRdEQveFF3RUgzRklqU3p0R1JSeXJEWFVKOFVhNlhG?=
 =?utf-8?B?anZYYUprUHhKcVExUkhPWEFlNExlTDRTd040VU1xT1pOS1pRUmpqS1BjOHly?=
 =?utf-8?B?UUF3MFk1bFJQSnAzblppVm9tOFVXZUFhQlo0T25xVFptZ0hlbnUwQXpyTzAv?=
 =?utf-8?B?S0hGcklPU3V5N2FubUZrQy85bUZQMUpWQ2l0WmhPSmY0cjZGTGxEejRPMUtQ?=
 =?utf-8?B?ZUwvaHhjanZMODZQeXdkdk5KbWh1TTFmQlZvb3Jud0pwV0VRNC94MDM3MzNS?=
 =?utf-8?B?V1lSNU5pbTBqa2VJNTNyeG9qaGU1L3ZSb29QQXZhYTRudlpDZ0lCelJDSU45?=
 =?utf-8?B?eXBmVG1HeHRtV01VWWtQMzQrVVFBcVo1MG5vR0VFRWc1VmplMnd2MEk2MVFY?=
 =?utf-8?B?Y0h3ZmM2blJ2YTNQeEhBQ1ZvWXBhZldQL1lqUnBjRzJFNGNtNkNQckdIYUYy?=
 =?utf-8?B?bE9ZYldKRUxlVnBCL1o4dVROMkJ3b1ZwUkM3cThxYmdWcTNBeHlCOCtyZHpG?=
 =?utf-8?B?UHJERC8yWFlMd3dqb2dTOGxSL3dhMEVVaE52NmFlMFROdzRTNko1NEpOWlNF?=
 =?utf-8?B?RmtPM0hwY3BrTWxnTXdaZnp3RlBWeERRRXFWNk9FeDMzS054ckxhQXJ1ZFNJ?=
 =?utf-8?B?RFZqUkh3RHFwTU9JellmV2xUV003c2tDc1FYeWx1TXYwVUlPM0YrSFU3T0Z4?=
 =?utf-8?B?U3IrUjVvNGQvcENzakFGN1laTmpLMFZqUFY2UU02VlpRd0JtaFJKQ1JHN292?=
 =?utf-8?B?L1RiSVZsbUNpVmQxU2hvcXN0Vk53WVh6Y2xvN3BWRFcwaUlla1ZSQzUwNWt3?=
 =?utf-8?B?YVU5enFjdEdxMUVFRGc0ZDJ1eUFmUk1TMjB1aTlVbkhPTTRxLzk0Vml2N1RF?=
 =?utf-8?B?QUkwOExQcFFlK0oxN0VCeGJRbFd0WWNHQWFjb04wREo0WjJCRHcrTDRHYllk?=
 =?utf-8?Q?2OMQ=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <72449D8B5DA24D429FD26E21FB605C3B@amdcloud.onmicrosoft.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8bdf3853-4ceb-4bcc-9b4b-08dd3145d855
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2025 07:10:20.7846
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Q/Vu/DclYAPbazSKcf+CRktXsI8JyVO4YQaTMaXunHUV4m/qNXG23EXc3wM084BYcwa/gGVXqCD75/pLTCAcHg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR12MB6033

T24gMjAyNS8xLzcgMTg6MDYsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAxOS4xMi4yMDI0IDA2
OjIxLCBKaXFpYW4gQ2hlbiB3cm90ZToNCj4+IC0tLSAvZGV2L251bGwNCj4+ICsrKyBiL3hlbi9k
cml2ZXJzL3ZwY2kvcmViYXIuYw0KPj4gQEAgLTAsMCArMSwxMzEgQEANCj4+ICsvKiBTUERYLUxp
Y2Vuc2UtSWRlbnRpZmllcjogR1BMLTIuMC1vbmx5ICovDQo+PiArLyoNCj4+ICsgKiBDb3B5cmln
aHQgKEMpIDIwMjQgQWR2YW5jZWQgTWljcm8gRGV2aWNlcywgSW5jLiBBbGwgUmlnaHRzIFJlc2Vy
dmVkLg0KPj4gKyAqDQo+PiArICogQXV0aG9yOiBKaXFpYW4gQ2hlbiA8SmlxaWFuLkNoZW5AYW1k
LmNvbT4NCj4+ICsgKi8NCj4+ICsNCj4+ICsjaW5jbHVkZSA8eGVuL3NjaGVkLmg+DQo+PiArI2lu
Y2x1ZGUgPHhlbi92cGNpLmg+DQo+PiArDQo+PiArc3RhdGljIHZvaWQgY2ZfY2hlY2sgcmViYXJf
Y3RybF93cml0ZShjb25zdCBzdHJ1Y3QgcGNpX2RldiAqcGRldiwNCj4+ICsgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHVuc2lnbmVkIGludCByZWcsDQo+PiArICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCB2YWwsDQo+PiArICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB2b2lkICpkYXRhKQ0KPj4gK3sNCj4+ICsgICAg
c3RydWN0IHZwY2lfYmFyICpiYXIgPSBkYXRhOw0KPj4gKyAgICB1aW50NjRfdCBzaXplID0gUENJ
X1JFQkFSX0NUUkxfU0laRSh2YWwpOw0KPj4gKw0KPj4gKyAgICBpZiAoIGJhci0+ZW5hYmxlZCAp
DQo+PiArICAgIHsNCj4+ICsgICAgICAgIC8qDQo+PiArICAgICAgICAgKiBSZWZ1c2UgdG8gcmVz
aXplIGEgQkFSIHdoaWxlIG1lbW9yeSBkZWNvZGluZyBpcyBlbmFibGVkLCBhcw0KPj4gKyAgICAg
ICAgICogb3RoZXJ3aXNlIHRoZSBzaXplIG9mIHRoZSBtYXBwZWQgcmVnaW9uIGluIHRoZSBwMm0g
d291bGQgYmVjb21lDQo+PiArICAgICAgICAgKiBzdGFsZSB3aXRoIHRoZSBuZXdseSBzZXQgQkFS
IHNpemUsIGFuZCB0aGUgcG9zaXRpb24gb2YgdGhlIEJBUg0KPj4gKyAgICAgICAgICogd291bGQg
YmUgcmVzZXQgdG8gdW5kZWZpbmVkLiAgTm90ZSB0aGUgUENJZSBzcGVjaWZpY2F0aW9uIGFsc28N
Cj4+ICsgICAgICAgICAqIGZvcmJpZHMgcmVzaXppbmcgYSBCQVIgd2l0aCBtZW1vcnkgZGVjb2Rp
bmcgZW5hYmxlZC4NCj4+ICsgICAgICAgICAqLw0KPj4gKyAgICAgICAgaWYgKCBzaXplICE9IGJh
ci0+c2l6ZSApDQo+PiArICAgICAgICAgICAgZ3ByaW50ayhYRU5MT0dfRVJSLA0KPj4gKyAgICAg
ICAgICAgICAgICAgICAgIiVwcDogcmVmdXNlIHRvIHJlc2l6ZSBCQVIgd2l0aCBtZW1vcnkgZGVj
b2RpbmcgZW5hYmxlZFxuIiwNCj4+ICsgICAgICAgICAgICAgICAgICAgICZwZGV2LT5zYmRmKTsN
Cj4+ICsgICAgICAgIHJldHVybjsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICBpZiAoICEoKHNp
emUgPj4gUENJX1JFQkFSX1NJWkVfQklBUykgJiBiYXItPnJlc2l6YWJsZV9zaXplcykgKQ0KPj4g
KyAgICAgICAgZ3ByaW50ayhYRU5MT0dfV0FSTklORywNCj4+ICsgICAgICAgICAgICAgICAgIiVw
cDogbmV3IHNpemUgJSNseCBpcyBub3Qgc3VwcG9ydGVkIGJ5IGhhcmR3YXJlXG4iLA0KPj4gKyAg
ICAgICAgICAgICAgICAmcGRldi0+c2JkZiwgc2l6ZSk7DQo+PiArDQo+PiArICAgIGJhci0+c2l6
ZSA9IHNpemU7DQo+IA0KPiBTaG91bGRuJ3QgYXQgbGVhc3QgdGhpcyBiZSBpbiBhbiAiZWxzZSIg
dG8gdGhlIGlmKCkgYWJvdmU/DQpBZnRlciByZWFkaW5nIHlvdXIgZGlzY3Vzc2lvbiB3aXRoIFJv
Z2VyLiwgaGVyZS4uDQoNCj4gDQo+PiArICAgIGJhci0+YWRkciA9IDA7DQo+IA0KPiBGb3IgbWF4
aW11bSBjb21wYXRpYmlsaXR5IHdpdGggdGhlIGJlaGF2aW9yIG9uIGJhcmUgbWV0YWwsIHdvdWxk
IHdlDQo+IHBlcmhhcHMgYmV0dGVyIC4uLg0KPiANCj4+ICsgICAgYmFyLT5ndWVzdF9hZGRyID0g
MDsNCj4+ICsgICAgcGNpX2NvbmZfd3JpdGUzMihwZGV2LT5zYmRmLCByZWcsIHZhbCk7DQo+IA0K
PiAuLi4gcmUtcmVhZCB0aGUgQkFSIGZyb20gaGFyZHdhcmUgYWZ0ZXIgdGhpcyB3cml0ZT8NCj4g
DQo+IFNpbWlsYXIgY29uc2lkZXJhdGlvbiBtYXkgYXBwbHkgdG8gLT5ndWVzdF9hZGRyOiBEcml2
ZXIgd3JpdGVycyBrbm93aW5nDQo+IGhvdyB0aGVpciBoYXJkd2FyZSBiZWhhdmVzIG1heSBleHBl
Y3QgdGhhdCBtZXJlbHkgc29tZSBvZiB0aGUgYml0cyBvZg0KPiB0aGUgYWRkcmVzcyBnZXQgY2xl
YXJlZCAoaWYgdGhlIHNpemUgaW5jcmVhc2VzKS4NCmFuZCBoZXJlLCBJIG5lZWQgdG8gdXNlIHBj
aV9zaXplX21lbV9iYXIgdG8gcmUtb2J0YWluIGFkZHIgYW5kIHNpemUsIHRoZW4gc2V0IGd1ZXN0
X2FkZHIgdG8gYmUgYWRkci4NCiAgICBwY2lfc2l6ZV9tZW1fYmFyKHBkZXYtPnNiZGYsIHJlZywg
JmJhci0+YWRkciwgJmJhci0+c2l6ZSwgKTsNCiAgICBiYXItPmd1ZXN0X2FkZHIgPSBiYXItPmFk
ZHI7DQoNCg0KPiANCj4+ICtzdGF0aWMgaW50IGNmX2NoZWNrIGluaXRfcmViYXIoc3RydWN0IHBj
aV9kZXYgKnBkZXYpDQo+PiArew0KPj4gKyAgICB1aW50MzJfdCBjdHJsOw0KPj4gKyAgICB1bnNp
Z25lZCBpbnQgbmJhcnM7DQo+PiArICAgIHVuc2lnbmVkIGludCByZWJhcl9vZmZzZXQgPSBwY2lf
ZmluZF9leHRfY2FwYWJpbGl0eShwZGV2LT5zYmRmLA0KPj4gKyAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUENJX0VYVF9DQVBfSURfUkVCQVIp
Ow0KPj4gKw0KPj4gKyAgICBpZiAoICFyZWJhcl9vZmZzZXQgKQ0KPj4gKyAgICAgICAgcmV0dXJu
IDA7DQo+PiArDQo+PiArICAgIGlmICggIWlzX2hhcmR3YXJlX2RvbWFpbihwZGV2LT5kb21haW4p
ICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgcHJpbnRrKFhFTkxPR19FUlIgIiVwcDogcmVzaXph
YmxlIEJBUnMgdW5zdXBwb3J0ZWQgZm9yIHVucHJpdiAlcGRcbiIsDQo+PiArICAgICAgICAgICAg
ICAgJnBkZXYtPnNiZGYsIHBkZXYtPmRvbWFpbik7DQo+PiArICAgICAgICByZXR1cm4gLUVPUE5P
VFNVUFA7DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgY3RybCA9IHBjaV9jb25mX3JlYWQzMihw
ZGV2LT5zYmRmLCByZWJhcl9vZmZzZXQgKyBQQ0lfUkVCQVJfQ1RSTCgwKSk7DQo+PiArICAgIG5i
YXJzID0gTUFTS19FWFRSKGN0cmwsIFBDSV9SRUJBUl9DVFJMX05CQVJfTUFTSyk7DQo+PiArDQo+
PiArICAgIGZvciAoIHVuc2lnbmVkIGludCBpID0gMDsgaSA8IG5iYXJzOyBpKysgKQ0KPj4gKyAg
ICB7DQo+PiArICAgICAgICBpbnQgcmM7DQo+PiArICAgICAgICBzdHJ1Y3QgdnBjaV9iYXIgKmJh
cjsNCj4+ICsgICAgICAgIHVuc2lnbmVkIGludCBpbmRleDsNCj4+ICsNCj4+ICsgICAgICAgIGN0
cmwgPSBwY2lfY29uZl9yZWFkMzIocGRldi0+c2JkZiwgcmViYXJfb2Zmc2V0ICsgUENJX1JFQkFS
X0NUUkwoaSkpOw0KPj4gKyAgICAgICAgaW5kZXggPSBjdHJsICYgUENJX1JFQkFSX0NUUkxfQkFS
X0lEWDs7DQo+IA0KPiBOaXQ6IE5vIGRvdWJsZSBzZW1pY29sb25zIHBsZWFzZS4NCj4gDQo+PiAr
ICAgICAgICBpZiAoIGluZGV4ID49IFBDSV9IRUFERVJfTk9STUFMX05SX0JBUlMgKQ0KPj4gKyAg
ICAgICAgew0KPj4gKyAgICAgICAgICAgIC8qDQo+PiArICAgICAgICAgICAgICogVE9ETzogZm9y
IGZhaWxlZCBwYXRoZXMsIG5lZWQgdG8gaGlkZSBSZUJhciBjYXBhYmlsaXR5DQo+PiArICAgICAg
ICAgICAgICogZnJvbSBoYXJkd2FyZSBkb21haW4gaW5zdGVhZCBvZiByZXR1cm5pbmcgYW4gZXJy
b3IuDQo+PiArICAgICAgICAgICAgICovDQo+PiArICAgICAgICAgICAgcHJpbnRrKFhFTkxPR19F
UlIgIiVwZCAlcHA6IHRvbyBiaWcgQkFSIG51bWJlciAldSBpbiBSRUJBUl9DVFJMXG4iLA0KPj4g
KyAgICAgICAgICAgICAgICAgICBwZGV2LT5kb21haW4sICZwZGV2LT5zYmRmLCBpbmRleCk7DQo+
PiArICAgICAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+IA0KPiBXaXRoIHRoZSBUT0RPIHVuYWRk
cmVzc2VkLCBpcyBpdCBhY3R1YWxseSBhcHByb3ByaWF0ZSB0byByZXR1cm4gYW4gZXJyb3INCj4g
aGVyZT8gU2hvdWxkbid0IHdlIGNvbnRpbnVlIGluIGEgYmVzdCBlZmZvcnQgbWFubmVyPyAoUXVl
c3Rpb24gYWxzbyB0bw0KPiBSb2dlciBhcyB0aGUgbWFpbnRhaW5lci4pDQo+IA0KPj4gKyAgICAg
ICAgfQ0KPj4gKw0KPj4gKyAgICAgICAgYmFyID0gJnBkZXYtPnZwY2ktPmhlYWRlci5iYXJzW2lu
ZGV4XTsNCj4+ICsgICAgICAgIGlmICggYmFyLT50eXBlICE9IFZQQ0lfQkFSX01FTTY0X0xPICYm
IGJhci0+dHlwZSAhPSBWUENJX0JBUl9NRU0zMiApDQo+PiArICAgICAgICB7DQo+PiArICAgICAg
ICAgICAgcHJpbnRrKFhFTkxPR19FUlIgIiVwZCAlcHA6IEJBUiV1IGlzIG5vdCBpbiBtZW1vcnkg
c3BhY2VcbiIsDQo+PiArICAgICAgICAgICAgICAgICAgIHBkZXYtPmRvbWFpbiwgJnBkZXYtPnNi
ZGYsIGluZGV4KTsNCj4+ICsgICAgICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4gDQo+IFNhbWUg
cXVlc3Rpb24gaGVyZSB0aGVuLg0KQWZ0ZXIgcmVhZGluZyB5b3VyIGRpc2N1c3Npb24gd2l0aCBS
b2dlci4gSSB3aWxsIGNoYW5nZSB0byAiY29udGludWUiIGhlcmUgYW5kIGFib3ZlLg0KDQo+IA0K
Pj4gKyAgICAgICAgfQ0KPj4gKw0KPj4gKyAgICAgICAgcmMgPSB2cGNpX2FkZF9yZWdpc3Rlcihw
ZGV2LT52cGNpLCB2cGNpX2h3X3JlYWQzMiwgdnBjaV9od193cml0ZTMyLA0KPj4gKyAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICByZWJhcl9vZmZzZXQgKyBQQ0lfUkVCQVJfQ0FQKGkpLCA0
LCBOVUxMKTsNCj4+ICsgICAgICAgIGlmICggcmMgKQ0KPj4gKyAgICAgICAgew0KPj4gKyAgICAg
ICAgICAgIHByaW50ayhYRU5MT0dfRVJSICIlcGQgJXBwOiBmYWlsIHRvIGFkZCByZWcgb2YgUkVC
QVJfQ0FQIHJjPSVkXG4iLA0KPj4gKyAgICAgICAgICAgICAgICAgICBwZGV2LT5kb21haW4sICZw
ZGV2LT5zYmRmLCByYyk7DQo+PiArICAgICAgICAgICAgcmV0dXJuIHJjOw0KPj4gKyAgICAgICAg
fQ0KPj4gKw0KPj4gKyAgICAgICAgcmMgPSB2cGNpX2FkZF9yZWdpc3RlcihwZGV2LT52cGNpLCB2
cGNpX2h3X3JlYWQzMiwgcmViYXJfY3RybF93cml0ZSwNCj4+ICsgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgcmViYXJfb2Zmc2V0ICsgUENJX1JFQkFSX0NUUkwoaSksIDQsIGJhcik7DQo+
PiArICAgICAgICBpZiAoIHJjICkNCj4+ICsgICAgICAgIHsNCj4+ICsgICAgICAgICAgICBwcmlu
dGsoWEVOTE9HX0VSUiAiJXBkICVwcDogZmFpbCB0byBhZGQgcmVnIG9mIFJFQkFSX0NUUkwgcmM9
JWRcbiIsDQo+PiArICAgICAgICAgICAgICAgICAgIHBkZXYtPmRvbWFpbiwgJnBkZXYtPnNiZGYs
IHJjKTsNCj4+ICsgICAgICAgICAgICByZXR1cm4gcmM7DQo+PiArICAgICAgICB9DQo+PiArDQo+
PiArICAgICAgICBiYXItPnJlc2l6YWJsZV9zaXplcyB8PQ0KPj4gKyAgICAgICAgICAgIChwY2lf
Y29uZl9yZWFkMzIocGRldi0+c2JkZiwgcmViYXJfb2Zmc2V0ICsgUENJX1JFQkFSX0NBUChpKSkg
Pj4NCj4+ICsgICAgICAgICAgICAgUENJX1JFQkFSX0NBUF9TSElGVCk7DQo+IA0KPiBJbW8gdGhp
cyB3b3VsZCBiZXR0ZXIgdXNlID0gaW4gcGxhY2Ugb2YgfD0gYW5kIChzZWUgYWxzbyBiZWxvdykg
d291bGQgYWxzbw0KPiBiZXR0ZXIgdXNlIE1BU0tfRVhUUigpIGp1c3QgbGlrZSAuLi4NCj4gDQo+
PiArICAgICAgICBiYXItPnJlc2l6YWJsZV9zaXplcyB8PQ0KPj4gKyAgICAgICAgICAgICgodWlu
dDY0X3QpTUFTS19FWFRSKGN0cmwsIFBDSV9SRUJBUl9DVFJMX1NJWkVTKSA8PA0KPj4gKyAgICAg
ICAgICAgICAoMzIgLSBQQ0lfUkVCQVJfQ0FQX1NISUZUKSk7DQo+IA0KPiAuLi4gdGhpcyBvbmUg
ZG9lcy4NCkNvbWJpbmUgd2l0aCB5b3VyIGJlbG93IGNvbW1lbnRzIGFib3V0IHRoZSBtYWNybyAi
IFBDSV9SRUJBUl9DQVBfU0hJRlQiIGFuZCAiUENJX1JFQkFSX0NUUkxfU0laRVMgIiwNCkkgd2ls
bCBjaGFuZ2UgIlBDSV9SRUJBUl9DQVBfU0hJRlQgNCIgdG8gIlBDSV9SRUJBUl9DQVBfU0laRVNf
TUFTSyAweEZGRkZGRkYwVSIsDQpjaGFuZ2UgIlBDSV9SRUJBUl9DVFJMX1NJWkVTIDB4RkZGRjAw
MDBVIiB0byAiUENJX1JFQkFSX0NUUkxfU0laRVNfTUFTSyAweEZGRkYwMDAwVSINClRoZW4sIGhl
cmUgd2lsbCBiZToNCiAgICAgICAgYmFyLT5yZXNpemFibGVfc2l6ZXMgPQ0KICAgICAgICAgICAg
TUFTS19FWFRSKHBjaV9jb25mX3JlYWQzMihwZGV2LT5zYmRmLA0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICByZWJhcl9vZmZzZXQgKyBQQ0lfUkVCQVJfQ0FQKGkpKSwNCiAg
ICAgICAgICAgICAgICAgICAgICBQQ0lfUkVCQVJfQ0FQX1NJWkVTX01BU0spOw0KICAgICAgICBi
YXItPnJlc2l6YWJsZV9zaXplcyB8PQ0KICAgICAgICAgICAgKCgodWludDY0X3QpTUFTS19FWFRS
KGN0cmwsIFBDSV9SRUJBUl9DVFJMX1NJWkVTX01BU0spIDw8IDMyKSAvDQogICAgICAgICAgICAg
SVNPTEFURV9MU0IoUENJX1JFQkFSX0NBUF9TSVpFU19NQVNLKSk7DQoNCj4gDQo+IEZ1cnRoZXIg
SSB0aGluayB5b3Ugd2FudCB0byB0cnVuY2F0ZSB0aGUgdmFsdWUgZm9yIDMyLWJpdCBCQVJzLCBz
dWNoIHRoYXQNCj4gcmViYXJfY3RybF93cml0ZSgpIHdvdWxkIHByb3Blcmx5IHJlamVjdCBhdHRl
bXB0cyB0byBzZXQgc2l6ZXMgb2YgNEcgYW5kDQo+IGFib3ZlIGZvciB0aGVtLg0KQWZ0ZXIgcmVh
ZGluZyB5b3VyIGRpc2N1c3Npb24gd2l0aCBSb2dlciwgc2luY2UgSSB3aWxsIGNoYW5nZSB0byBy
ZS1vYnRhaW4gZnJvbSBoYXJkd2FyZSwgc28gSSBjYW4gZG8gbm90aGluZyB3aXRoIHRoaXMgY29t
bWVudC4NCg0KPiANCj4+IC0tLSBhL3hlbi9kcml2ZXJzL3ZwY2kvdnBjaS5jDQo+PiArKysgYi94
ZW4vZHJpdmVycy92cGNpL3ZwY2kuYw0KPj4gQEAgLTIzMiw2ICsyMzIsMTIgQEAgdm9pZCBjZl9j
aGVjayB2cGNpX2h3X3dyaXRlMTYoDQo+PiAgICAgIHBjaV9jb25mX3dyaXRlMTYocGRldi0+c2Jk
ZiwgcmVnLCB2YWwpOw0KPj4gIH0NCj4+ICANCj4+ICt2b2lkIGNmX2NoZWNrIHZwY2lfaHdfd3Jp
dGUzMigNCj4+ICsgICAgY29uc3Qgc3RydWN0IHBjaV9kZXYgKnBkZXYsIHVuc2lnbmVkIGludCBy
ZWcsIHVpbnQzMl90IHZhbCwgdm9pZCAqZGF0YSkNCj4+ICt7DQo+PiArICAgIHBjaV9jb25mX3dy
aXRlMzIocGRldi0+c2JkZiwgcmVnLCB2YWwpOw0KPj4gK30NCj4gDQo+IFRoaXMgZnVuY3Rpb24g
aXMgYmVpbmcgYWRkZWQganVzdCB0byBoYW5kbGUgd3JpdGluZyBvZiBhIHIvbyByZWdpc3Rlci4N
Cj4gQ2FuJ3QgeW91IGJldHRlciByZS11c2UgdnBjaV9pZ25vcmVkX3dyaXRlKCk/DQo+IA0KPj4g
LS0tIGEveGVuL2luY2x1ZGUveGVuL3BjaV9yZWdzLmgNCj4+ICsrKyBiL3hlbi9pbmNsdWRlL3hl
bi9wY2lfcmVncy5oDQo+PiBAQCAtNDU5LDYgKzQ1OSw3IEBADQo+PiAgI2RlZmluZSBQQ0lfRVhU
X0NBUF9JRF9BUkkJMTQNCj4+ICAjZGVmaW5lIFBDSV9FWFRfQ0FQX0lEX0FUUwkxNQ0KPj4gICNk
ZWZpbmUgUENJX0VYVF9DQVBfSURfU1JJT1YJMTYNCj4+ICsjZGVmaW5lIFBDSV9FWFRfQ0FQX0lE
X1JFQkFSCTIxCS8qIFJlc2l6YWJsZSBCQVIgKi8NCj4+ICANCj4+ICAvKiBBZHZhbmNlZCBFcnJv
ciBSZXBvcnRpbmcgKi8NCj4+ICAjZGVmaW5lIFBDSV9FUlJfVU5DT1JfU1RBVFVTCTQJLyogVW5j
b3JyZWN0YWJsZSBFcnJvciBTdGF0dXMgKi8NCj4+IEBAIC01NDEsNiArNTQyLDE5IEBADQo+PiAg
I2RlZmluZSAgUENJX1ZORFJfSEVBREVSX1JFVih4KQkoKCh4KSA+PiAxNikgJiAweGYpDQo+PiAg
I2RlZmluZSAgUENJX1ZORFJfSEVBREVSX0xFTih4KQkoKCh4KSA+PiAyMCkgJiAweGZmZikNCj4+
ICANCj4+ICsvKiBSZXNpemFibGUgQkFScyAqLw0KPj4gKyNkZWZpbmUgUENJX1JFQkFSX1NJWkVf
QklBUwkyMA0KPiANCj4gSSB0aGluayBpdCB3b3VsZCBiZSBiZXN0IGlmIGFsbCByZWdpc3RlciBk
ZWZpbml0aW9ucyBjYW1lIGZpcnN0LCBhbmQNCj4gYXV4aWxpYXJ5IG9uZXMgZm9sbG93ZWQgYWZ0
ZXJ3YXJkcyAobWF5YmUgZXZlbiBzZXBhcmF0ZWQgYnkgYSBicmllZg0KPiBjb21tZW50IGZvciBj
bGFyaXR5KS4NCj4gDQo+PiArI2RlZmluZSBQQ0lfUkVCQVJfQ0FQKG4pICAgIAkoNCArIDggKiAo
bikpCS8qIGNhcGFiaWxpdHkgcmVnaXN0ZXIgKi8NCj4+ICsjZGVmaW5lICBQQ0lfUkVCQVJfQ0FQ
X1NISUZUCQk0CQkvKiBzaGlmdCBmb3Igc3VwcG9ydGVkIEJBUiBzaXplcyAqLw0KPj4gKyNkZWZp
bmUgUENJX1JFQkFSX0NUUkwobikgICAJKDggKyA4ICogKG4pKQkvKiBjb250cm9sIHJlZ2lzdGVy
ICovDQo+IA0KPiBTb21ldGhpbmcncyBvZGQgd2l0aCB0aGUgcGFkZGluZyBoZXJlLiBQbGVhc2Ug
YmUgY29uc2lzdGVudCB3aXRoIHRoZSB1c2UNCj4gb2Ygd2hpdGVzcGFjZSAob3VnaHQgdG8gYmUg
b25seSBoYXJkIHRhYnMgaGVyZSBhZmFpY3QpLg0KU29ycnksIEkgZG9uJ3QgdW5kZXJzdGFuZCBo
b3cgdG8gbW9kaWZ5IGl0IHNwZWNpZmljYWxseS4NCg0KPiANCj4+ICsjZGVmaW5lICBQQ0lfUkVC
QVJfQ1RSTF9CQVJfSURYCTB4MDAwMDAwMDcJLyogQkFSIGluZGV4ICovDQo+PiArI2RlZmluZSAg
UENJX1JFQkFSX0NUUkxfTkJBUl9NQVNLCTB4MDAwMDAwRTAJLyogIyBvZiByZXNpemFibGUgQkFS
cyAqLw0KPj4gKyNkZWZpbmUgIFBDSV9SRUJBUl9DVFJMX0JBUl9TSVpFCTB4MDAwMDFGMDAJLyog
QkFSIHNpemUgKi8NCj4gDQo+IFRoaXMgZmllbGQgaXMgNiBiaXRzIHdpZGUgaW4gdGhlIHNwZWMg
SSdtIGxvb2tpbmcgYXQuIE9yIGVsc2UgQkFSIHNpemVzDQo+IDJeXjUyIGFuZCB1cCBjYW4ndCBi
ZSBlbmNvZGVkLg0KPiANCj4+ICsjZGVmaW5lICBQQ0lfUkVCQVJfQ1RSTF9TSVpFKHYpIFwNCj4+
ICsgICAgICAgICAgICAoMVVMIDw8IChNQVNLX0VYVFIodiwgUENJX1JFQkFSX0NUUkxfQkFSX1NJ
WkUpIFwNCj4+ICsgICAgICAgICAgICAgICAgICAgICArIFBDSV9SRUJBUl9TSVpFX0JJQVMpKQ0K
Pj4gKyNkZWZpbmUgIFBDSV9SRUJBUl9DVFJMX1NJWkVTCQkweEZGRkYwMDAwVQkvKiBzdXBwb3J0
ZWQgQkFSIHNpemVzICovDQo+IA0KPiBQQ0lfUkVCQVJfQ0FQX1NISUZUIGFuZCBQQ0lfUkVCQVJf
Q1RSTF9TSVpFUyBkb24ndCBmaXQgdG9nZXRoZXIgdmVyeSB3ZWxsLg0KPiBJbW8gYm90aCB3YW50
IHJlcHJlc2VudGluZyBhcyBtYXNrcy4NCj4gDQo+IEphbg0KDQotLSANCkJlc3QgcmVnYXJkcywN
CkppcWlhbiBDaGVuLg0K


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 07:28:44 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 07:28:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869244.1280698 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tW9Rc-0000HH-Kt; Fri, 10 Jan 2025 07:28:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869244.1280698; Fri, 10 Jan 2025 07:28:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tW9Rc-0000HA-GG; Fri, 10 Jan 2025 07:28:36 +0000
Received: by outflank-mailman (input) for mailman id 869244;
 Fri, 10 Jan 2025 07:28: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 <SRS0=TYzS=UC=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tW9Rb-0000Gz-83
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 07:28:35 +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 7f8dc00a-cf24-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 08:28:34 +0100 (CET)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-4362f61757fso17317045e9.2
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 23:28: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
 5b1f17b1804b1-436e9e37c17sm43086665e9.27.2025.01.09.23.28.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 23:28:32 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 7f8dc00a-cf24-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736494113; x=1737098913; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ZJRFGM2ZG+coRXTqQCvYs0LKh46U5mjzozm/MQ0XUOY=;
        b=X+clvhukjmjugqwgmKUWIHFhzLTkjvmGDgTqKvCDsJjwHlrpJTkPwCTvCfD+j14lYT
         q5SZRhMdkHZABc17qak+LLLQ5fQnUYN1B3EE3ZUJNdfJ83g3o31tQCtDVUuToyK+bvI/
         natrX5eu20mpY5djWOnxAedJhSDdEGkOjpiZTswXhHWRUPKKMRkPY6jQJuDS0pUGvpsN
         ywJ9M1YC5D9+VqptVrz3bImG2GtGTIVTFH8gfQUFIUu+XQ7HML1Uda5eGdCNEsxZicbZ
         n+Xi2IN027rf3acOI5YtzxDn41fUYmhqSOimhWWGNvVlWbN1siGQP4tNwLv+5RgVtJqx
         yNeg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736494113; x=1737098913;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ZJRFGM2ZG+coRXTqQCvYs0LKh46U5mjzozm/MQ0XUOY=;
        b=DxKACU2B0d/O6Z7mYRFhIYOvpQatOMfBVZiU3hcR7zhDhYWs6hKgqblTnvbZvfpF5Z
         xfM6CROZ4O0HXLAjmpR2+dxGTUHFAusQltnb3ZY2I7j9xMKdh2eoGEGdQpb/A9lVaDkk
         12163JPmL8DlwT2VXvqu4JsbsCHq1oFRNY/5o8Mjgp/3MQhFcwiEwqv6OTs9pKQ7yieh
         x+ILOo9h8m3FtkfSjyFhG1D3EHVW/whAafMx8HqahBxAkqvZHND+wfdaHcGNM7DGUXhu
         8sqcxKdz0acbu+61Nok1/4AZ0x9JxJpJUhb8/uOIeCcgL66jvnUiqYAy0urVJkSZcDAB
         forA==
X-Forwarded-Encrypted: i=1; AJvYcCUTuB1YqLUbIpz4B+GsFauND4kAct/ClhAssFriFUgxUKzWxeIGcbpeSXEZPownkxDqE49sBGjKx5A=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy5BJapPkTUY1koIr8zTXBOApq+tXfv2Py7uRzrzFX8fs5IDmbw
	roSqNe9+4WPvhvJ3pCg4bBebdjTRSd8bhb1rEfhAiWZ3pyBF37IOh0JSNfaEeQ==
X-Gm-Gg: ASbGncshhkujKud0/+VOYQ/RJ+pFIBeurxU7F3oFUgo/6S0iX+dWg7MlCuAyb6LR7w0
	cp+VNyK+bxG4Qnf9NXUM0JJ+5pn4gZ4NioR/MF3bdI8KASMBSF+2EITHFS/SgVrn2vX2/A/QB2y
	hMwCnjzaqWh6SXNzLksfv1jFRCwEwYfCb6kzXhWlMsKeEoVEhDtiohREKiruA/KafdwPcK+hF1j
	Q44lE2C+JRa/CZu2ECwWoC/c8KcaMa2wfTqo/edVn0UGhfsFQfs1Ejeqp4DPOw5F/m1eXcFpI08
	Eto2LJknPUb25p7fO1WgFyc+BXk1lNE+vbeSZc2eww==
X-Google-Smtp-Source: AGHT+IENrB3MhlnYRLXmvbJQZ89EztD+WkABHcrx/ugwLRvqd+MU+lGMtQyjjAiRCrOMAtmOMl/uWw==
X-Received: by 2002:a05:600c:a45:b0:434:a75b:5f59 with SMTP id 5b1f17b1804b1-436e26adfa2mr80816525e9.3.1736494113247;
        Thu, 09 Jan 2025 23:28:33 -0800 (PST)
Message-ID: <4fbf231b-7389-4956-8c7c-6412aa0c4736@suse.com>
Date: Fri, 10 Jan 2025 08:28:30 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] xen: update pvcalls_front_accept prototype
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: jgross@suse.com, xen-devel@lists.xenproject.org,
 linux-kernel@vger.kernel.org
References: <alpine.DEB.2.22.394.2501061335161.133435@ubuntu-linux-20-04-desktop>
 <0f8fc348-14f5-40ac-912a-1785caedb675@suse.com>
 <alpine.DEB.2.22.394.2501071530180.133435@ubuntu-linux-20-04-desktop>
 <ec92e932-e3b7-40ad-9ed3-2b3391cc63a7@suse.com>
 <alpine.DEB.2.22.394.2501091608090.133435@ubuntu-linux-20-04-desktop>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <alpine.DEB.2.22.394.2501091608090.133435@ubuntu-linux-20-04-desktop>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.01.2025 01:10, Stefano Stabellini wrote:
> On Wed, 8 Jan 2025, Jan Beulich wrote:
>> On 08.01.2025 00:30, Stefano Stabellini wrote:
>>> On Tue, 7 Jan 2025, Jan Beulich wrote:
>>>> On 06.01.2025 22:36, Stefano Stabellini wrote:
>>>>> xen: update pvcalls_front_accept prototype
>>>>>
>>>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
>>>>> ---
>>>>>
>>>>> Changes in v2:
>>>>> - also update pvcalls-front.c
>>>>
>>>> The patch still gives the impression of being incomplete: There's no
>>>> caller of the function that you update. However, there's no such caller
>>>> in the first place. Why don't you just delete the function then?
>>>
>>> It is meant to be called from an out-of-tree module, which has not been
>>> upstreamed yet
>>
>> And which then would require an EXPORT_SYMBOL() anyway. In Xen, as you're
>> well aware, such unreachable code would actually constitute a Misra
>> violation.
>>
>> Without any in-tree caller, imo the change needs a non-empty description,
>> clarifying why the adjustment is wanted / needed.
> 
> How about:
> 
> ---
> xen: update pvcalls_front_accept prototype
> 
> While currently there are no in-tree callers of these functions, it is
> best to keep them up-to-date with the latest network API.

SGTM, fwiw.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 07:34:51 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 07:34:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869256.1280714 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tW9Xa-00025L-AF; Fri, 10 Jan 2025 07:34:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869256.1280714; Fri, 10 Jan 2025 07:34:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tW9Xa-00025E-7h; Fri, 10 Jan 2025 07:34:46 +0000
Received: by outflank-mailman (input) for mailman id 869256;
 Fri, 10 Jan 2025 07:34: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 <SRS0=TYzS=UC=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tW9XZ-000258-FP
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 07:34:45 +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 5c85a8ec-cf25-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 08:34:44 +0100 (CET)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-4364a37a1d7so18600225e9.3
 for <xen-devel@lists.xenproject.org>; Thu, 09 Jan 2025 23:34:44 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436e2ddc5f5sm77383205e9.18.2025.01.09.23.34.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 09 Jan 2025 23:34:43 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5c85a8ec-cf25-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736494484; x=1737099284; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=eX3fTpgW5SdYNy8hU9KL1H5X+E/3UO52Nk2AySG6AxA=;
        b=WSaCeNw/1ArLlOlt7Zt13bqZVWZkQU7m8n6oFfobiSfHQxhSDYWRgo9yiZ33eBVj2+
         xQkE9HNbrBPs8fTgfbgNlB4oaaXoa3YQ62udtSwOuHYNwUdB8VsXMfsmtMhOOaicKDYz
         H9RIAuAvjOu5NEAWg+zNU1K6wZK/YmM8gWR2uwb40Ai5keqf1ddAepkB8vHY1O5GhhJ1
         bwk0107OBMMHZrhIPackAvV3//dMvgzNqYdgJOvH0LJgo1rIwT+MWwO4IQyRMRGDFwZG
         /uNjCxjMEe3lJoVX42Lj31M7+6pjEU6W4sa4AvUDeJJvSb61Y7KazCvDCIs2IDwKvl4k
         LcaA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736494484; x=1737099284;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=eX3fTpgW5SdYNy8hU9KL1H5X+E/3UO52Nk2AySG6AxA=;
        b=ZqRtAj+RflWvzCSeeznKt5MeZoxVhp6TJubbc5O4vSrpBpOCmvvjz1+yIf5mdur5GM
         GoFZL4YDSpFK8xBmqdG95ny2LFVL+dFse4D+1ZiIfIOi8JqeTA1TrcH86J9hnI22Nz1+
         8x+Pgz2bWdeskojoqETfslflvFwJf3g0+JYyVE4acJblKMJBymhoFncXl2eYJPRvw7Zt
         I4lwYKbqonZRwOGzuFH1GAAYCW4KbXpjvEnWUAIXeCNPBaNVGRN7BTZOPENbH1ib2H25
         mGza91+Z+GMtUewSGrHHqXIaajpu2Ku7xyS0tt3ygYqAfaifZkCwKL7OeK01movK826E
         67+g==
X-Forwarded-Encrypted: i=1; AJvYcCWwopkvH2xLWjoDzi3AgJbAE6hPw+aAAv67Ss1WNnR2SsJnNGWcE/Lr22JBLooEjXDdhyo3uQqGauo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwcPSNuADJ1xXw0lQky4n63IxJDFnuXYnZ6XyVzVrQrcA7V2Q7d
	iY9E06AuVd4I4cRHSfdjuBrznt4OnzaPGkLr+NytbINbTJv0P+xbJSSfiF4tgg==
X-Gm-Gg: ASbGnctZFU4N63rCFboNxJtT/FNl8urAdwYcE5iL5na8l0xldhhF/csy/lPsyRbcSuS
	haPJ5ENkRehoYqhAMl8h5oT6NdRyguEKBiCnAza/NW4ZnFp0S8wT42u8fa3R1d5CP1qZC4eI+mW
	n01zb5n5Q0JPtwzqESVZ4WTwJVxQl/36MMVvdt8FOFY4SQguiB4PNsTHRkCre5x12Dj3nl+tc+H
	bIHcQecHBr+ogl9mgMmBcFPsldiiBsSOtQnMgDpPFOfLaV3EZ1bBpsAZJEyOOXp4IqodtPcfAkH
	4lDyqjr7HlcvcL2ac3kfL1/a0y+1ZTW21Ep9DvV9Eg==
X-Google-Smtp-Source: AGHT+IGd9Z08J3SLwlHEUHUjToRWT7+JkayOrQwMbFvVtr1ZLDxEk6Ztyg1nkz0Iet5xwe9pS1i4tA==
X-Received: by 2002:a05:600c:5112:b0:434:a386:6cf with SMTP id 5b1f17b1804b1-436e267f77amr85059045e9.2.1736494484093;
        Thu, 09 Jan 2025 23:34:44 -0800 (PST)
Message-ID: <6a03089b-6b91-4c3e-b48b-9d9bb8aa4425@suse.com>
Date: Fri, 10 Jan 2025 08:34:42 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4] vpci: Add resizable bar support
To: "Chen, Jiqian" <Jiqian.Chen@amd.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>, "Huang, Ray"
 <Ray.Huang@amd.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
References: <20241219052143.3161332-1-Jiqian.Chen@amd.com>
 <d904c816-da83-418a-9bff-9988660af546@suse.com>
 <BL1PR12MB5849D215025D7CD9A5DA4B22E71C2@BL1PR12MB5849.namprd12.prod.outlook.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <BL1PR12MB5849D215025D7CD9A5DA4B22E71C2@BL1PR12MB5849.namprd12.prod.outlook.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.01.2025 08:10, Chen, Jiqian wrote:
> On 2025/1/7 18:06, Jan Beulich wrote:
>> On 19.12.2024 06:21, Jiqian Chen wrote:
>>> +#define PCI_REBAR_CAP(n)    	(4 + 8 * (n))	/* capability register */
>>> +#define  PCI_REBAR_CAP_SHIFT		4		/* shift for supported BAR sizes */
>>> +#define PCI_REBAR_CTRL(n)   	(8 + 8 * (n))	/* control register */
>>
>> Something's odd with the padding here. Please be consistent with the use
>> of whitespace (ought to be only hard tabs here afaict).
> Sorry, I don't understand how to modify it specifically.

You surely have noticed that in two of the three quoted lines there are
blanks immediately followed by tabs in the padding. This can hardly ever
be correct. (The overall goal wants to be that "same level" definitions
are column-wise properly aligned with one another. While nested ones,
like you have it for PCI_REBAR_CAP_SHIFT, are properly identified as
being nested. You want to check with other parts of the file if in doubt.)

Jan


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 08:06:48 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 08:06:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869220.1280725 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWA2T-00070Y-CD; Fri, 10 Jan 2025 08:06:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869220.1280725; Fri, 10 Jan 2025 08:06:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWA2T-00070R-9A; Fri, 10 Jan 2025 08:06:41 +0000
Received: by outflank-mailman (input) for mailman id 869220;
 Fri, 10 Jan 2025 01:50: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 <SRS0=5fd/=UC=163.com=andyshrk@srs-se1.protection.inumbo.net>)
 id 1tW4AI-0002ga-54
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 01:50:22 +0000
Received: from m16.mail.163.com (m16.mail.163.com [220.197.31.3])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id 3eaa7ff7-cef5-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 02:50:20 +0100 (CET)
Received: from andyshrk$163.com ( [58.22.7.114] ) by
 ajax-webmail-wmsvr-40-121 (Coremail) ; Fri, 10 Jan 2025 09:49:34 +0800
 (CST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 3eaa7ff7-cef5-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com;
	s=s110527; h=Date:From:Subject:Content-Type:MIME-Version:
	Message-ID; bh=rp/KcRTe1MsmgU0PH0K2oNjpoThGJemgMsEfHLsmXZU=; b=W
	0+7i2RYJnb+IwDKnerRnHxSxLQCjeH0nmPAixXRZJIh73RBq6tWkXMlB8ARB+/jY
	np1B30dwgcuk3AfdfRFVCdiEx8UK+S2MJZD/8WuIfTW+pMd2/CA2ZVtLym/AK7/5
	ZlsIJ8WXsVg/F0EKQPdKfYxTn5KUwLSo/yOl2xLFwA=
X-Originating-IP: [58.22.7.114]
Date: Fri, 10 Jan 2025 09:49:34 +0800 (CST)
From: "Andy Yan" <andyshrk@163.com>
To: "Thomas Zimmermann" <tzimmermann@suse.de>
Cc: maarten.lankhorst@linux.intel.com, mripard@kernel.org, airlied@gmail.com, 
	simona@ffwll.ch, dri-devel@lists.freedesktop.org, 
	linux-mediatek@lists.infradead.org, freedreno@lists.freedesktop.org, 
	linux-arm-msm@vger.kernel.org, imx@lists.linux.dev, 
	linux-samsung-soc@vger.kernel.org, nouveau@lists.freedesktop.org, 
	virtualization@lists.linux.dev, spice-devel@lists.freedesktop.org, 
	linux-renesas-soc@vger.kernel.org, 
	linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org, 
	intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org
Subject: Re:[PATCH v2 02/25] drm/dumb-buffers: Provide helper to set pitch
 and size
X-Priority: 3
X-Mailer: Coremail Webmail Server Version XT5.0.14 build 20240801(9da12a7b)
 Copyright (c) 2002-2025 www.mailtech.cn 163com
In-Reply-To: <20250109150310.219442-3-tzimmermann@suse.de>
References: <20250109150310.219442-1-tzimmermann@suse.de>
 <20250109150310.219442-3-tzimmermann@suse.de>
X-NTES-SC: AL_Qu2YBPicvE8s4iWYYukfmkcVgOw9UcO5v/Qk3oZXOJF8jArp+TAefEJSMWvIws60LDKUmgmGdih16sFZbLt8cLIWf0LCiIohAdHyNGUiBtRGKQ==
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset=UTF-8
MIME-Version: 1.0
Message-ID: <94f78e1.19bf.1944de709b0.Coremail.andyshrk@163.com>
X-Coremail-Locale: zh_CN
X-CM-TRANSID:eSgvCgDnqsWufIBna6lTAA--.18314W
X-CM-SenderInfo: 5dqg52xkunqiywtou0bp/1tbiqBTQXmeAdu58vQABsN
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==

CkhpIFRob21hcywKCkF0IDIwMjUtMDEtMDkgMjI6NTY6NTYsICJUaG9tYXMgWmltbWVybWFubiIg
PHR6aW1tZXJtYW5uQHN1c2UuZGU+IHdyb3RlOgo+QWRkIGRybV9tb2Rlc19zaXplX2R1bWIoKSwg
YSBoZWxwZXIgdG8gY2FsY3VsYXRlIHRoZSBkdW1iLWJ1ZmZlcgo+c2NhbmxpbmUgcGl0Y2ggYW5k
IGFsbG9jYXRpb24gc2l6ZS4gSW1wbGVtZW50YXRpb25zIG9mIHN0cnVjdAo+ZHJtX2RyaXZlci5k
dW1iX2NyZWF0ZSBjYW4gY2FsbCB0aGUgbmV3IGhlbHBlciBmb3IgdGhlaXIgc2l6ZQo+Y29tcHV0
YXRpb25zLiBUaGVyZSdzIGN1cnJlbnRseSBxdWl0ZSBhIGJpdCBvZiBjb2RlIGR1cGxpY2F0aW9u
Cj5hbW9uZyBEUk0ncyBtZW1vcnkgbWFuYWdlcnMuIEVhY2ggY2FsY3VsYXRlcyBzY2FubGluZSBw
aXRjaCBhbmQKPmJ1ZmZlciBzaXplIGZyb20gdGhlIGdpdmVuIGFyZ3VtZW50cywgYnV0IHRoZSBp
bXBsZW1lbnRhdGlvbnMgYXJlCj5pbmNvbnNpc3RlbnQgaW4gaG93IHRoZXkgdHJlYXQgYWxpZ25t
ZW50IGFuZCBmb3JtYXQgc3VwcG9ydC4gTGF0ZXIKPnBhdGNoZXMgd2lsbCB1bmlmeSB0aGlzIGNv
ZGUgb24gdG9wIG9mIGRybV9tb2RlX3NpemVfZHVtYigpIGFzCj5tdWNoIGFzIHBvc3NpYmxlLgo+
Cj5kcm1fbW9kZV9zaXplX2R1bWIoKSB1c2VzIGV4aXN0aW5nIDRDQyBmb3JtYXQgaGVscGVycyB0
byBpbnRlcnByZXQgdGhlCj5naXZlbiBjb2xvciBtb2RlLiBUaGlzIG1ha2VzIHRoZSBkdW1iLWJ1
ZmZlciBpbnRlcmZhY2UgYmVoYXZlIHNpbWlsYXIKPnRoZSBrZXJuZWwncyB2aWRlbz0gcGFyYW1l
dGVyLiBBZ2FpbiwgY3VycmVudCBwZXItZHJpdmVyIGltcGxlbWVudGF0aW9ucwo+bGlrZWx5IGhh
dmUgc3VidGxlIGRpZmZlcmVuY2VzIG9yIGJ1Z3MgaW4gaG93IHRoZXkgc3VwcG9ydCBjb2xvciBt
b2Rlcy4KPgo+RnV0dXJlIGRpcmVjdGlvbnM6IG9uZSBidWcgaXMgcHJlc2VudCBpbiB0aGUgY3Vy
cmVudCBpbnB1dCB2YWxpZGF0aW9uCj5pbiBkcm1fbW9kZV9jcmVhdGVfZHVtYigpLiBUaGUgZHVt
Yi1idWZmZXIgb3ZlcmZsb3cgdGVzdHMgcm91bmQgdXAgYW55Cj5naXZlbiBiaXRzLXBlci1waXhl
bCB2YWx1ZSB0byBhIG11bHRpcGxlIG9mIDguIFNvIGV2ZW4gb25lLWJpdCBmb3JtYXRzLAo+c3Vj
aCBhcyBEUk1fRk9STUFUX0MxLCByZXF1aXJlIDggYml0cyBwZXIgcGl4ZWwuIFdoaWxlIG5vdCBj
b21tb24sCj5sb3ctZW5kIGRpc3BsYXlzIHVzZSBzdWNoIGZvcm1hdHM7IHdpdGggYSBwb3NzaWJs
ZSBvdmVyY29tbWl0bWVudCBvZgo+bWVtb3J5LiBBdCBzb21lIHBvaW50LCB0aGUgdmFsaWRhdGlv
biBsb2dpYyBpbiBkcm1fbW9kZV9zaXplX2R1bWIoKSBpcwo+c3VwcG9zZWQgdG8gcmVwbGFjZSB0
aGUgZXJyb25vdXMgY29kZS4KPgo+U2lnbmVkLW9mZi1ieTogVGhvbWFzIFppbW1lcm1hbm4gPHR6
aW1tZXJtYW5uQHN1c2UuZGU+Cj4tLS0KPiBkcml2ZXJzL2dwdS9kcm0vZHJtX2R1bWJfYnVmZmVy
cy5jIHwgOTMgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrCj4gaW5jbHVkZS9kcm0vZHJt
X2R1bWJfYnVmZmVycy5oICAgICB8IDE0ICsrKysrCj4gMiBmaWxlcyBjaGFuZ2VkLCAxMDcgaW5z
ZXJ0aW9ucygrKQo+IGNyZWF0ZSBtb2RlIDEwMDY0NCBpbmNsdWRlL2RybS9kcm1fZHVtYl9idWZm
ZXJzLmgKPgo+ZGlmZiAtLWdpdCBhL2RyaXZlcnMvZ3B1L2RybS9kcm1fZHVtYl9idWZmZXJzLmMg
Yi9kcml2ZXJzL2dwdS9kcm0vZHJtX2R1bWJfYnVmZmVycy5jCj5pbmRleCA5OTE2YWFmNWIzZjIu
LmZkMzk3MjBiZDYxNyAxMDA2NDQKPi0tLSBhL2RyaXZlcnMvZ3B1L2RybS9kcm1fZHVtYl9idWZm
ZXJzLmMKPisrKyBiL2RyaXZlcnMvZ3B1L2RybS9kcm1fZHVtYl9idWZmZXJzLmMKPkBAIC0yNSw2
ICsyNSw4IEBACj4gCj4gI2luY2x1ZGUgPGRybS9kcm1fZGV2aWNlLmg+Cj4gI2luY2x1ZGUgPGRy
bS9kcm1fZHJ2Lmg+Cj4rI2luY2x1ZGUgPGRybS9kcm1fZHVtYl9idWZmZXJzLmg+Cj4rI2luY2x1
ZGUgPGRybS9kcm1fZm91cmNjLmg+Cj4gI2luY2x1ZGUgPGRybS9kcm1fZ2VtLmg+Cj4gI2luY2x1
ZGUgPGRybS9kcm1fbW9kZS5oPgo+IAo+QEAgLTU3LDYgKzU5LDk3IEBACj4gICogYSBoYXJkd2Fy
ZS1zcGVjaWZpYyBpb2N0bCB0byBhbGxvY2F0ZSBzdWl0YWJsZSBidWZmZXIgb2JqZWN0cy4KPiAg
Ki8KPiAKPitzdGF0aWMgaW50IGRybV9tb2RlX2FsaWduX2R1bWIoc3RydWN0IGRybV9tb2RlX2Ny
ZWF0ZV9kdW1iICphcmdzLAo+KwkJCSAgICAgICB1bnNpZ25lZCBsb25nIHBpdGNoX2FsaWduLAo+
KwkJCSAgICAgICB1bnNpZ25lZCBsb25nIHNpemVfYWxpZ24pCj4rewo+Kwl1MzIgcGl0Y2ggPSBh
cmdzLT5waXRjaDsKPisJdTMyIHNpemU7Cj4rCj4rCWlmICghcGl0Y2gpCj4rCQlyZXR1cm4gLUVJ
TlZBTDsKPisKPisJaWYgKHBpdGNoX2FsaWduKQo+KwkJcGl0Y2ggPSByb3VuZHVwKHBpdGNoLCBw
aXRjaF9hbGlnbik7Cj4rCj4rCS8qIG92ZXJmbG93IGNoZWNrcyBmb3IgMzJiaXQgc2l6ZSBjYWxj
dWxhdGlvbnMgKi8KPisJaWYgKGFyZ3MtPmhlaWdodCA+IFUzMl9NQVggLyBwaXRjaCkKPisJCXJl
dHVybiAtRUlOVkFMOwo+Kwo+KwlpZiAoIXNpemVfYWxpZ24pCj4rCQlzaXplX2FsaWduID0gUEFH
RV9TSVpFOwo+KwllbHNlIGlmICghSVNfQUxJR05FRChzaXplX2FsaWduLCBQQUdFX1NJWkUpKQo+
KwkJcmV0dXJuIC1FSU5WQUw7Cj4rCj4rCXNpemUgPSBBTElHTihhcmdzLT5oZWlnaHQgKiBwaXRj
aCwgc2l6ZV9hbGlnbik7Cj4rCWlmICghc2l6ZSkKPisJCXJldHVybiAtRUlOVkFMOwo+Kwo+Kwlh
cmdzLT5waXRjaCA9IHBpdGNoOwo+KwlhcmdzLT5zaXplID0gc2l6ZTsKPisKPisJcmV0dXJuIDA7
Cj4rfQo+Kwo+Ky8qKgo+KyAqIGRybV9tb2RlX3NpemVfZHVtYiAtIENhbGN1bGF0ZXMgdGhlIHNj
YW5saW5lIGFuZCBidWZmZXIgc2l6ZXMgZm9yIGR1bWIgYnVmZmVycwo+KyAqIEBkZXY6IERSTSBk
ZXZpY2UKPisgKiBAYXJnczogUGFyYW1ldGVycyBmb3IgdGhlIGR1bWIgYnVmZmVyCj4rICogQHBp
dGNoX2FsaWduOiBTY2FubGluZSBhbGlnbm1lbnQgaW4gYnl0ZXMKPisgKiBAc2l6ZV9hbGlnbjog
QnVmZmVyLXNpemUgYWxpZ25tZW50IGluIGJ5dGVzCj4rICoKPisgKiBUaGUgaGVscGVyIGRybV9t
b2RlX3NpemVfZHVtYigpIGNhbGN1bGF0ZXMgdGhlIHNpemUgb2YgdGhlIGJ1ZmZlcgo+KyAqIGFs
bG9jYXRpb24gYW5kIHRoZSBzY2FubGluZSBzaXplIGZvciBhIGR1bWIgYnVmZmVyLiBDYWxsZXJz
IGhhdmUgdG8KPisgKiBzZXQgdGhlIGJ1ZmZlcnMgd2lkdGgsIGhlaWdodCBhbmQgY29sb3IgbW9k
ZSBpbiB0aGUgYXJndW1lbnQgQGFyZy4KPisgKiBUaGUgaGVscGVyIHZhbGlkYXRlcyB0aGUgY29y
cmVjdG5lc3Mgb2YgdGhlIGlucHV0IGFuZCB0ZXN0cyBmb3IKPisgKiBwb3NzaWJsZSBvdmVyZmxv
d3MuIElmIHN1Y2Nlc3NmdWwsIGl0IHJldHVybnMgdGhlIGR1bWIgYnVmZmVyJ3MKPisgKiByZXF1
aXJlZCBzY2FubGluZSBwaXRjaCBhbmQgc2l6ZSBpbiAmYXJncy4KPisgKgo+KyAqIFRoZSBwYXJh
bWV0ZXIgQHBpdGNoX2FsaWduIGFsbG93cyB0aGUgZHJpdmVyIHRvIHNwZWNpZmllcyBhbgo+KyAq
IGFsaWdubWVudCBmb3IgdGhlIHNjYW5saW5lIHBpdGNoLCBpZiB0aGUgaGFyZHdhcmUgcmVxdWly
ZXMgYW55LiBUaGUKPisgKiBjYWxjdWxhdGVkIHBpdGNoIHdpbGwgYmUgYSBtdWx0aXBsZSBvZiB0
aGUgYWxpZ25tZW50LiBUaGUgcGFyYW1ldGVyCj4rICogQHNpemVfYWxpZ24gYWxsb3dzIHRvIHNw
ZWNpZnkgYW4gYWxpZ25tZW50IGZvciBidWZmZXIgc2l6ZXMuIFRoZQo+KyAqIHJldHVybmVkIHNp
emUgaXMgYWx3YXlzIGEgbXVsdGlwbGUgb2YgUEFHRV9TSVpFLgo+KyAqCj4rICogUmV0dXJuczoK
PisgKiBaZXJvIG9uIHN1Y2Nlc3MsIG9yIGEgbmVnYXRpdmUgZXJyb3IgY29kZSBvdGhlcndpc2Uu
Cj4rICovCj4raW50IGRybV9tb2RlX3NpemVfZHVtYihzdHJ1Y3QgZHJtX2RldmljZSAqZGV2LAo+
KwkJICAgICAgIHN0cnVjdCBkcm1fbW9kZV9jcmVhdGVfZHVtYiAqYXJncywKPisJCSAgICAgICB1
bnNpZ25lZCBsb25nIHBpdGNoX2FsaWduLAo+KwkJICAgICAgIHVuc2lnbmVkIGxvbmcgc2l6ZV9h
bGlnbikKPit7Cj4rCXUzMiBmb3VyY2M7Cj4rCWNvbnN0IHN0cnVjdCBkcm1fZm9ybWF0X2luZm8g
KmluZm87Cj4rCXU2NCBwaXRjaDsKPisKPisJLyoKPisJICogVGhlIHNjYW5saW5lIHBpdGNoIGRl
cGVuZHMgb24gdGhlIGJ1ZmZlciB3aWR0aCBhbmQgdGhlIGNvbG9yCj4rCSAqIGZvcm1hdC4gVGhl
IGxhdHRlciBpcyBzcGVjaWZpZWQgYXMgYSBjb2xvci1tb2RlIGNvbnN0YW50IGZvcgo+KwkgKiB3
aGljaCB3ZSBmaXJzdCBoYXZlIHRvIGZpbmQgdGhlIGNvcnJlc3BvbmRpbmcgY29sb3IgZm9ybWF0
Lgo+KwkgKgo+KwkgKiBEaWZmZXJlbnQgY29sb3IgZm9ybWF0cyBjYW4gaGF2ZSB0aGUgc2FtZSBj
b2xvci1tb2RlIGNvbnN0YW50Lgo+KwkgKiBGb3IgZXhhbXBsZSBYUkdCODg4OCBhbmQgQkdSWDg4
ODggYm90aCBoYXZlIGEgY29sb3IgbW9kZSBvZiAzMi4KPisJICogSXQgaXMgcG9zc2libGUgdG8g
dXNlIGRpZmZlcmVudCBmb3JtYXRzIGZvciBkdW1iLWJ1ZmZlciBhbGxvY2F0aW9uCj4rCSAqIGFu
ZCByZW5kZXJpbmcgYXMgbG9uZyBhcyBhbGwgaW52b2x2ZWQgZm9ybWF0cyBzaGFyZSB0aGUgc2Ft
ZQo+KwkgKiBjb2xvci1tb2RlIGNvbnN0YW50Lgo+KwkgKi8KPisJZm91cmNjID0gZHJtX2RyaXZl
cl9jb2xvcl9tb2RlX2Zvcm1hdChkZXYsIGFyZ3MtPmJwcCk7CgpUaGlzIHdpbGwgcmV0dXJuIC1F
SU5WQUwgd2l0aCBicHAgZHJtX21vZGVfbGVnYWN5X2ZiX2Zvcm1hdCBkb2Vzbid0IHN1cHBvcnQs
CnN1Y2ggYXMoTlYxNSwgTlYyMCwgTlYzMCwgYnBwIGlzIDEwKVswXQoKQW5kIHRoZXJlIGFyZSBh
bHNvIHNvbWUgQUZCQyBiYXNlZCBmb3JtYXQgd2l0aCBicHAgY2FuJ3QgYmUgaGFuZGxlZCBoZXJl
LCBzZWU6CnN0YXRpYyBfX3UzMiBkcm1fZ2VtX2FmYmNfZ2V0X2JwcChzdHJ1Y3QgZHJtX2Rldmlj
ZSAqZGV2LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3Qgc3RydWN0IGRy
bV9tb2RlX2ZiX2NtZDIgKm1vZGVfY21kKQp7ICAgICAgICAgICAgICAgCiAgICAgICAgY29uc3Qg
c3RydWN0IGRybV9mb3JtYXRfaW5mbyAqaW5mbzsKICAgICAgICAgICAgICAgIAogICAgICAgIGlu
Zm8gPSBkcm1fZ2V0X2Zvcm1hdF9pbmZvKGRldiwgbW9kZV9jbWQpOwogICAgICAgICAgICAgICAg
CiAgICAgICAgc3dpdGNoIChpbmZvLT5mb3JtYXQpIHsKICAgICAgICBjYXNlIERSTV9GT1JNQVRf
WVVWNDIwXzhCSVQ6ICAgICAgIAogICAgICAgICAgICAgICAgcmV0dXJuIDEyOwogICAgICAgIGNh
c2UgRFJNX0ZPUk1BVF9ZVVY0MjBfMTBCSVQ6ICAgICAgCiAgICAgICAgICAgICAgICByZXR1cm4g
MTU7ICAgICAgICAgICAgICAgICAKICAgICAgICBjYXNlIERSTV9GT1JNQVRfVlVZMTAxMDEwOiAg
ICAgICAgIAogICAgICAgICAgICAgICAgcmV0dXJuIDMwOyAgICAgICAgICAgICAgICAgCiAgICAg
ICAgZGVmYXVsdDoKICAgICAgICAgICAgICAgIHJldHVybiBkcm1fZm9ybWF0X2luZm9fYnBwKGlu
Zm8sIDApOwogICAgICAgIH0KfQoKCgpbMF1odHRwczovL2dpdGxhYi5mcmVlZGVza3RvcC5vcmcv
bWVzYS9kcm0vLS9ibG9iL21haW4vdGVzdHMvbW9kZXRlc3QvYnVmZmVycy5jP3JlZl90eXBlPWhl
YWRzI0wxNTkKClRoaXMgaW50cm9kdWNlIGEgbW9kZXRlc3QgZmFpbHVyZSBvbiByb2NrY2hpcCBw
bGF0Zm9ybToKIyBtb2RldGVzdCAtTSByb2NrY2hpcCAtcyA3MEA2ODoxOTIweDEwODAgLVAgMzJA
Njg6MTkyMHgxMDgwQE5WMzAKc2V0dGluZyBtb2RlIDE5MjB4MTA4MC02MC4wMEh6IG9uIGNvbm5l
Y3RvcnMgNzAsIGNydGMgNjgKdGVzdGluZyAxOTIweDEwODBATlYzMCBvdmVybGF5IHBsYW5lIDMy
CmZhaWxlZCB0byBjcmVhdGUgZHVtYiBidWZmZXI6IEludmFsaWQgYXJndW1lbnQKCkkgdGhpbmsg
b3RoZXIgcGxhdGZvcm0gd2l0aCBicHAgY2FuJ3QgaGFuZGxlciBieSAgZHJtX21vZGVfbGVnYWN5
X2ZiX2Zvcm1hdCB3aWxsCmFsc28gc2VlIHRoaXMga2luZCBvZiBmYWlsdXJlOgoKCgo+KwlpZiAo
Zm91cmNjID09IERSTV9GT1JNQVRfSU5WQUxJRCkKPisJCXJldHVybiAtRUlOVkFMOwo+KwlpbmZv
ID0gZHJtX2Zvcm1hdF9pbmZvKGZvdXJjYyk7Cj4rCWlmICghaW5mbykKPisJCXJldHVybiAtRUlO
VkFMOwo+KwlwaXRjaCA9IGRybV9mb3JtYXRfaW5mb19taW5fcGl0Y2goaW5mbywgMCwgYXJncy0+
d2lkdGgpOwo+KwlpZiAoIXBpdGNoIHx8IHBpdGNoID4gVTMyX01BWCkKPisJCXJldHVybiAtRUlO
VkFMOwo+Kwo+KwlhcmdzLT5waXRjaCA9IHBpdGNoOwo+Kwo+KwlyZXR1cm4gZHJtX21vZGVfYWxp
Z25fZHVtYihhcmdzLCBwaXRjaF9hbGlnbiwgc2l6ZV9hbGlnbik7Cj4rfQo+K0VYUE9SVF9TWU1C
T0woZHJtX21vZGVfc2l6ZV9kdW1iKTsKPisKPiBpbnQgZHJtX21vZGVfY3JlYXRlX2R1bWIoc3Ry
dWN0IGRybV9kZXZpY2UgKmRldiwKPiAJCQkgc3RydWN0IGRybV9tb2RlX2NyZWF0ZV9kdW1iICph
cmdzLAo+IAkJCSBzdHJ1Y3QgZHJtX2ZpbGUgKmZpbGVfcHJpdikKPmRpZmYgLS1naXQgYS9pbmNs
dWRlL2RybS9kcm1fZHVtYl9idWZmZXJzLmggYi9pbmNsdWRlL2RybS9kcm1fZHVtYl9idWZmZXJz
LmgKPm5ldyBmaWxlIG1vZGUgMTAwNjQ0Cj5pbmRleCAwMDAwMDAwMDAwMDAuLjZmZTM2MDA0YjE5
ZAo+LS0tIC9kZXYvbnVsbAo+KysrIGIvaW5jbHVkZS9kcm0vZHJtX2R1bWJfYnVmZmVycy5oCj5A
QCAtMCwwICsxLDE0IEBACj4rLyogU1BEWC1MaWNlbnNlLUlkZW50aWZpZXI6IE1JVCAqLwo+Kwo+
KyNpZm5kZWYgX19EUk1fRFVNQl9CVUZGRVJTX0hfXwo+KyNkZWZpbmUgX19EUk1fRFVNQl9CVUZG
RVJTX0hfXwo+Kwo+K3N0cnVjdCBkcm1fZGV2aWNlOwo+K3N0cnVjdCBkcm1fbW9kZV9jcmVhdGVf
ZHVtYjsKPisKPitpbnQgZHJtX21vZGVfc2l6ZV9kdW1iKHN0cnVjdCBkcm1fZGV2aWNlICpkZXYs
Cj4rCQkgICAgICAgc3RydWN0IGRybV9tb2RlX2NyZWF0ZV9kdW1iICphcmdzLAo+KwkJICAgICAg
IHVuc2lnbmVkIGxvbmcgcGl0Y2hfYWxpZ24sCj4rCQkgICAgICAgdW5zaWduZWQgbG9uZyBzaXpl
X2FsaWduKTsKPisKPisjZW5kaWYKPi0tIAo+Mi40Ny4xCj4KPgo+X19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPkxpbnV4LXJvY2tjaGlwIG1haWxpbmcgbGlz
dAo+TGludXgtcm9ja2NoaXBAbGlzdHMuaW5mcmFkZWFkLm9yZwo+aHR0cDovL2xpc3RzLmluZnJh
ZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1yb2NrY2hpcAo=


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 08:08:20 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 08:08:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869275.1280734 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWA43-0007WG-LT; Fri, 10 Jan 2025 08:08:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869275.1280734; Fri, 10 Jan 2025 08:08:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWA43-0007W9-Ix; Fri, 10 Jan 2025 08:08:19 +0000
Received: by outflank-mailman (input) for mailman id 869275;
 Fri, 10 Jan 2025 08:08:18 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=b62p=UC=casper.srs.infradead.org=BATV+4f8727a5892a49e75626+7810+infradead.org+dwmw2@srs-se1.protection.inumbo.net>)
 id 1tWA41-0007W1-Hz
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 08:08:18 +0000
Received: from casper.infradead.org (casper.infradead.org
 [2001:8b0:10b:1236::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 09c4dbba-cf2a-11ef-99a4-01e77a169b0f;
 Fri, 10 Jan 2025 09:08:13 +0100 (CET)
Received: from 54-240-197-238.amazon.com ([54.240.197.238]
 helo=edge-cache-192.e-lhr50.amazon.com)
 by casper.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux))
 id 1tWA3w-0000000CRMv-0IcJ; Fri, 10 Jan 2025 08:08:12 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 09c4dbba-cf2a-11ef-99a4-01e77a169b0f
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:Cc:To:From:Subject:Message-ID:Sender:Reply-To:
	Content-Transfer-Encoding:Content-ID:Content-Description;
	bh=xjTgIqYHkldm6604nk+rcGuJN2kgAbKbeLYjNOBtiio=; b=FHBgG/AEumQf8aehaZy57AF6kL
	lvaVrDFOSkMLgfG11t+8OcGT7w8cC+fxW+lUNtWPUEOVLgKXh0NXpkT1n7hDVukW2jqDs8DX9/GEN
	wMY08gk8puqH5nG/Qui6n1yWzHnSJaJIGDqrNufbnK7CQ6vQJFo1uk2lfIPgskFWmyyaJQQXTEEeh
	99L27EqZFw1gLxBXz/2+TizcQC6wukRbxZvoPUhzXOQplTzLDZ89/OPXJ/OGydbYDMwOxsL7zDjSp
	2CNRN5Tn+BScUDmKpY9nFjbA8YIcHG/6pPIaR/ImgFpB9U+DaDJRp3MidhuKWWmYCrXvS4Kt1e+bO
	DUNzmnHg==;
Message-ID: <17c134258de9517b677f08a865394f8075d67bdf.camel@infradead.org>
Subject: Re: [PATCH 2/2] xen: do not use '%ms' scanf specifier
From: David Woodhouse <dwmw2@infradead.org>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Cc: Anthony PERARD <anthony@xenproject.org>, qemu-devel@nongnu.org, Stefano
 Stabellini <sstabellini@kernel.org>, Paul Durrant <paul@xen.org>, "Edgar E.
 Iglesias" <edgar.iglesias@gmail.com>, =?ISO-8859-1?Q?Marc-Andr=E9?= Lureau
 <marcandre.lureau@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>, 
 xen-devel@lists.xenproject.org
Date: Fri, 10 Jan 2025 08:08:11 +0000
In-Reply-To: <Z3__eDp4hShe79Pl@macbook.local>
References: <20250107093140.86180-1-roger.pau@citrix.com>
	 <20250107093140.86180-3-roger.pau@citrix.com> <Z3-sJMXpiFUoATHz@l14>
	 <974ab6743d168d34babd458fe5e2e7766bb280b4.camel@infradead.org>
	 <Z3__eDp4hShe79Pl@macbook.local>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-iLcuI+S96c4sAIMas5cS"
User-Agent: Evolution 3.52.3-0ubuntu1 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html


--=-iLcuI+S96c4sAIMas5cS
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2025-01-09 at 17:55 +0100, Roger Pau Monn=C3=A9 wrote:
> On Thu, Jan 09, 2025 at 11:25:13AM +0000, David Woodhouse wrote:
> > On Thu, 2025-01-09 at 11:59 +0100, Anthony PERARD wrote:
> > >=20
> > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 char label[32];
> > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 XenDevice *xendev =3D NULL;
> > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 XenConsole *con;
> > > > @@ -550,7 +551,10 @@ static void xen_console_device_create(XenBacke=
ndInstance *backend,
> > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 goto fail;
> > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
> > > > =C2=A0=20
> > > > -=C2=A0=C2=A0=C2=A0 if (xs_node_scanf(xsh, XBT_NULL, fe, "type", er=
rp, "%ms", &type) !=3D 1) {
> > > > +=C2=A0=C2=A0=C2=A0 node_path =3D g_strdup_printf("%s/type", fe);
> > > > +=C2=A0=C2=A0=C2=A0 type =3D qemu_xen_xs_read(xsh, XBT_NULL, node_p=
ath, NULL);
> > > > +=C2=A0=C2=A0=C2=A0 g_free(node_path);
> > >=20
> > > I feel like we want "xs_node_read()" which would be similair to
> > > xs_node_vscanf() but would simply return the result of
> > > qemu_xen_xs_read(). This would avoid the need format of the node path=
 in
> > > several place in the code. But it's OK like that as well.
> >=20
> > If you look at the other callers of qemu_xen_xs_read(), it looks like
> > the majority of them create the path with snprintf and then pass it in.
> > Or with g_strdup_printf(), pass it in, then free it afterwards.
> >=20
> > So perhaps qemu_xen_xs_read() should be a printf-style function too,
> > with its last arg(s) being the node name.
>=20
> I just went with Anthony suggestion and introduced xs_node_read(), as
> I didn't want to play with qemu_xen_xs_read().=C2=A0 Not that I think the
> suggestion is not valid, just seemed more work than what I wanted to
> do right now.

Makes sense. Something like this=C2=B9?

char *xs_node_read(struct qemu_xs_handle *h, xs_transaction_t tid,
                   Error **errp, unsigned int *len,
                   const char *node_fmt, ...)
    G_GNUC_PRINTF(5, 6);

There's a %ms in hw/xen/xen-block.c too, btw. Did you catch that one?


=C2=B9 https://git.infradead.org/?p=3Dusers/dwmw2/qemu.git;a=3Dcommitdiff;h=
=3Dpercentms;hp=3Dbc6afa1c711da5b4f37c9685a812c77b114d84cb

--=-iLcuI+S96c4sAIMas5cS
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD9Aw
ggSOMIIDdqADAgECAhAOmiw0ECVD4cWj5DqVrT9PMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0yNDAxMzAwMDAwMDBaFw0zMTEx
MDkyMzU5NTlaMEExCzAJBgNVBAYTAkFVMRAwDgYDVQQKEwdWZXJva2V5MSAwHgYDVQQDExdWZXJv
a2V5IFNlY3VyZSBFbWFpbCBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMjvgLKj
jfhCFqxYyRiW8g3cNFAvltDbK5AzcOaR7yVzVGadr4YcCVxjKrEJOgi7WEOH8rUgCNB5cTD8N/Et
GfZI+LGqSv0YtNa54T9D1AWJy08ZKkWvfGGIXN9UFAPMJ6OLLH/UUEgFa+7KlrEvMUupDFGnnR06
aDJAwtycb8yXtILj+TvfhLFhafxroXrflspavejQkEiHjNjtHnwbZ+o43g0/yxjwnarGI3kgcak7
nnI9/8Lqpq79tLHYwLajotwLiGTB71AGN5xK+tzB+D4eN9lXayrjcszgbOv2ZCgzExQUAIt98mre
8EggKs9mwtEuKAhYBIP/0K6WsoMnQCcCAwEAAaOCAVwwggFYMBIGA1UdEwEB/wQIMAYBAf8CAQAw
HQYDVR0OBBYEFIlICOogTndrhuWByNfhjWSEf/xwMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6en
IZ3zbcgPMA4GA1UdDwEB/wQEAwIBhjAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIweQYI
KwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYIKwYB
BQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RD
QS5jcnQwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0
QXNzdXJlZElEUm9vdENBLmNybDARBgNVHSAECjAIMAYGBFUdIAAwDQYJKoZIhvcNAQELBQADggEB
ACiagCqvNVxOfSd0uYfJMiZsOEBXAKIR/kpqRp2YCfrP4Tz7fJogYN4fxNAw7iy/bPZcvpVCfe/H
/CCcp3alXL0I8M/rnEnRlv8ItY4MEF+2T/MkdXI3u1vHy3ua8SxBM8eT9LBQokHZxGUX51cE0kwa
uEOZ+PonVIOnMjuLp29kcNOVnzf8DGKiek+cT51FvGRjV6LbaxXOm2P47/aiaXrDD5O0RF5SiPo6
xD1/ClkCETyyEAE5LRJlXtx288R598koyFcwCSXijeVcRvBB1cNOLEbg7RMSw1AGq14fNe2cH1HG
W7xyduY/ydQt6gv5r21mDOQ5SaZSWC/ZRfLDuEYwggWbMIIEg6ADAgECAhAH5JEPagNRXYDiRPdl
c1vgMA0GCSqGSIb3DQEBCwUAMEExCzAJBgNVBAYTAkFVMRAwDgYDVQQKEwdWZXJva2V5MSAwHgYD
VQQDExdWZXJva2V5IFNlY3VyZSBFbWFpbCBHMjAeFw0yNDEyMzAwMDAwMDBaFw0yODAxMDQyMzU5
NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqGSIb3DQEBAQUAA4IC
DwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZeYAS/SRV6zmfXlXaZ
sNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2zkC9S7/yHDYnqegqt
w4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qGpgFdZEk2/c//ZvUN
i12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41vav1RhZJzYan4a1gU0
kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0cvnO8FM6PTqsnSbcc
0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PWPU6zfQTOMZ9uLQRR
ci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXtREF5lLXxp+CJ6KKS
blPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQrlR0gO3lBzuyPPArV
hvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7IqaAovAX0d+f1YjbmC
VsAwjhLmveFjNwIDAQABo4IBsDCCAawwHwYDVR0jBBgwFoAUiUgI6iBOd2uG5YHI1+GNZIR//HAw
HQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3bXcyQGluZnJhZGVh
ZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEBMA4GA1UdDwEB/wQE
AwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwewYDVR0fBHQwcjA3oDWgM4YxaHR0
cDovL2NybDMuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNybDA3oDWgM4YxaHR0
cDovL2NybDQuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNybDB2BggrBgEFBQcB
AQRqMGgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBABggrBgEFBQcwAoY0
aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNydDANBgkq
hkiG9w0BAQsFAAOCAQEAQXc4FPiPLRnTDvmOABEzkIumojfZAe5SlnuQoeFUfi+LsWCKiB8Uextv
iBAvboKhLuN6eG/NC6WOzOCppn4mkQxRkOdLNThwMHW0d19jrZFEKtEG/epZ/hw/DdScTuZ2m7im
8ppItAT6GXD3aPhXkXnJpC/zTs85uNSQR64cEcBFjjoQDuSsTeJ5DAWf8EMyhMuD8pcbqx5kRvyt
JPsWBQzv1Dsdv2LDPLNd/JUKhHSgr7nbUr4+aAP2PHTXGcEBh8lTeYea9p4d5k969pe0OHYMV5aL
xERqTagmSetuIwolkAuBCzA9vulg8Y49Nz2zrpUGfKGOD0FMqenYxdJHgDCCBZswggSDoAMCAQIC
EAfkkQ9qA1FdgOJE92VzW+AwDQYJKoZIhvcNAQELBQAwQTELMAkGA1UEBhMCQVUxEDAOBgNVBAoT
B1Zlcm9rZXkxIDAeBgNVBAMTF1Zlcm9rZXkgU2VjdXJlIEVtYWlsIEcyMB4XDTI0MTIzMDAwMDAw
MFoXDTI4MDEwNDIzNTk1OVowHjEcMBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzCCAiIwDQYJ
KoZIhvcNAQEBBQADggIPADCCAgoCggIBANqWLse95HW2F7FhfH9bugyT/danKmmXrbMnz5GZNAfj
Jl5gBL9JFXrOZ9eVdpmw04Tp6aDxZctFLoEDvSWKi367Q7Sg+ci+fH4KwwfQ8Pi0IpIKx2n5emEg
nbOQL1Lv/IcNiep6Cq3DiyaSpSp/RZf+CAfUNySHS8eWmhLU6jGpSD6hxTpYKye7PmrmvMWwfGEP
WoamAV1kSTb9z/9m9Q2LXa89aKmTxNwnAfD3Ohn9mtU3JukwILRMewn9QRXK7KzM+01h5hkCE4nj
W9q/VGFknNhqfhrWBTSQoE9CSVylASGrjzCgS7XmKy/BaH3/7mOOHQv5g1o3Qj/+cdKnpT0I5Qb1
nRy+c7wUzo9OqydJtxzSP4ZyHA4dELto/a3m/ay1XHcpum1pgTOLgxAfGb/T4dCkwRUstSKLMmpL
g9Y9TrN9BM4xn24tBFFyL5znGG0wQGzOVAM68RBzIQb6Fz758fjsr4yZnPbVsU1+gHEs/puNHrG0
9e1EQXmUtfGn4InoopJuU8p5VGD9S3Ikd4UoBlc7xl5yjtNlQxUeYrRlnUSmdlucCEoTX1n4UmtA
9CuVHSA7eUHO7I88CtWG9bGOU7tLgOZoSEvNqtaL/N7sQbBZK4jZ4Rr/zNTQg1SwYjjLB7u96lDP
sipoCi8BfR35/ViNuYJWwDCOEua94WM3AgMBAAGjggGwMIIBrDAfBgNVHSMEGDAWgBSJSAjqIE53
a4blgcjX4Y1khH/8cDAdBgNVHQ4EFgQUXGIam3Bs59Y60yTmWgfDu6pZQ6cwMAYDVR0RBCkwJ4ET
ZHdtdzJAaW5mcmFkZWFkLm9yZ4EQZGF2aWRAd29vZGhvdS5zZTAUBgNVHSAEDTALMAkGB2eBDAEF
AQEwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDB7BgNVHR8E
dDByMDegNaAzhjFodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVtYWlsRzIu
Y3JsMDegNaAzhjFodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVtYWlsRzIu
Y3JsMHYGCCsGAQUFBwEBBGowaDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29t
MEAGCCsGAQUFBzAChjRodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVt
YWlsRzIuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQBBdzgU+I8tGdMO+Y4AETOQi6aiN9kB7lKWe5Ch
4VR+L4uxYIqIHxR7G2+IEC9ugqEu43p4b80LpY7M4KmmfiaRDFGQ50s1OHAwdbR3X2OtkUQq0Qb9
6ln+HD8N1JxO5nabuKbymki0BPoZcPdo+FeRecmkL/NOzzm41JBHrhwRwEWOOhAO5KxN4nkMBZ/w
QzKEy4PylxurHmRG/K0k+xYFDO/UOx2/YsM8s138lQqEdKCvudtSvj5oA/Y8dNcZwQGHyVN5h5r2
nh3mT3r2l7Q4dgxXlovERGpNqCZJ624jCiWQC4ELMD2+6WDxjj03PbOulQZ8oY4PQUyp6djF0keA
MYIDuzCCA7cCAQEwVTBBMQswCQYDVQQGEwJBVTEQMA4GA1UEChMHVmVyb2tleTEgMB4GA1UEAxMX
VmVyb2tleSBTZWN1cmUgRW1haWwgRzICEAfkkQ9qA1FdgOJE92VzW+AwDQYJYIZIAWUDBAIBBQCg
ggE3MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTI1MDExMDA4MDgx
MVowLwYJKoZIhvcNAQkEMSIEICtz+7pWplJqxClyKyP/HtqQtPnbsnOjBk/wOKD+Du6mMGQGCSsG
AQQBgjcQBDFXMFUwQTELMAkGA1UEBhMCQVUxEDAOBgNVBAoTB1Zlcm9rZXkxIDAeBgNVBAMTF1Zl
cm9rZXkgU2VjdXJlIEVtYWlsIEcyAhAH5JEPagNRXYDiRPdlc1vgMGYGCyqGSIb3DQEJEAILMVeg
VTBBMQswCQYDVQQGEwJBVTEQMA4GA1UEChMHVmVyb2tleTEgMB4GA1UEAxMXVmVyb2tleSBTZWN1
cmUgRW1haWwgRzICEAfkkQ9qA1FdgOJE92VzW+AwDQYJKoZIhvcNAQEBBQAEggIAp9j0vnVS4aNj
WGSLQvoMz2ZZOohDKsv/1TIXpsD2QcKU1ivXXi8/n/axeJv3KChIIuKJzXquMQAFse9hHWvGJOKk
Rrd4+FHdxvKLeTzobZ3toaoYjKOdzzr4vIiWao0y/E1VTSbfHcdmw0n0LN2ijKsDSkujxXkGzVTo
FcDn3fYWnlt4VZBcNuNhCRWdnjANmKrCVsL+/1rikXo7BmUkSJnCkyndRin1Nqsp0sTfHzt643RP
nwHUjzQCaEB6GRG8fyY7SFcaLK00bKdvjYFApnb05z3EaF50RjjannhDukMs0YdhhKEyOKVKzIX8
QeCt32CLfOejfR0fIiWgXC3vkeb4x9ItwUK5e99Y3i87ha6lPBCWB8nIgqXQIMflPY67MiSB+H3a
KXxswYjM2tCbJDlq/bqMw7VB0cSEnylWxiIoRDjtQRaLPt44cqYWKqoDrLUGBR69tjGjL/MRWP+q
12K9v0BOPdIpCBHNoA5s/0pQ1gKAMHLYe3TrwWhpilloWTZXZVQ5nmKlem89OqT38f0IhgoZtCYc
CsAo9y8wxOVDYN8Hek95KHJ1TrZjxiUIfbMMdE5UjRi2Ad8nvMo+b439aH1RbwWU8H+TNHTHaQcd
xn4QQqm4PMZYhRJ+R0View4Y3qef/i5LQyoIUFRyaDlHxQvL5dZMjCZQFxk63asAAAAAAAA=


--=-iLcuI+S96c4sAIMas5cS--


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 08:15:06 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 08:15:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869286.1280745 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWAAQ-0000vv-GH; Fri, 10 Jan 2025 08:14:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869286.1280745; Fri, 10 Jan 2025 08:14:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWAAQ-0000vo-DL; Fri, 10 Jan 2025 08:14:54 +0000
Received: by outflank-mailman (input) for mailman id 869286;
 Fri, 10 Jan 2025 08:10:59 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=2jJ3=UC=pengutronix.de=p.zabel@srs-se1.protection.inumbo.net>)
 id 1tWA6d-0000rB-Os
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 08:10:59 +0000
Received: from metis.whiteo.stw.pengutronix.de
 (metis.whiteo.stw.pengutronix.de [2a0a:edc0:2:b01:1d::104])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6b5eebdf-cf2a-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 09:10:58 +0100 (CET)
Received: from drehscheibe.grey.stw.pengutronix.de ([2a0a:edc0:0:c01:1d::a2])
 by metis.whiteo.stw.pengutronix.de with esmtps
 (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92)
 (envelope-from <p.zabel@pengutronix.de>)
 id 1tWA1z-0008Lc-0Q; Fri, 10 Jan 2025 09:06:11 +0100
Received: from lupine.office.stw.pengutronix.de ([2a0a:edc0:0:900:1d::4e]
 helo=lupine)
 by drehscheibe.grey.stw.pengutronix.de with esmtps (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from <p.zabel@pengutronix.de>) id 1tWA1x-0007gT-21;
 Fri, 10 Jan 2025 09:06:09 +0100
Received: from pza by lupine with local (Exim 4.96)
 (envelope-from <p.zabel@pengutronix.de>) id 1tWA1x-0001oH-1d;
 Fri, 10 Jan 2025 09:06:09 +0100
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 6b5eebdf-cf2a-11ef-a0df-8be0dac302b0
Message-ID: <abd8ec5ad105d61f2ff372f88d7376bdf245acef.camel@pengutronix.de>
Subject: Re: [PATCH v2 10/25] drm/imx/ipuv3: Compute dumb-buffer sizes with
 drm_mode_size_dumb()
From: Philipp Zabel <p.zabel@pengutronix.de>
To: Thomas Zimmermann <tzimmermann@suse.de>, 
	maarten.lankhorst@linux.intel.com, mripard@kernel.org, airlied@gmail.com, 
	simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org, linux-mediatek@lists.infradead.org, 
	freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org, 
	imx@lists.linux.dev, linux-samsung-soc@vger.kernel.org, 
	nouveau@lists.freedesktop.org, virtualization@lists.linux.dev, 
	spice-devel@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org, 
	linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org, 
	intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org, Shawn Guo
	 <shawnguo@kernel.org>, Sascha Hauer <s.hauer@pengutronix.de>, Pengutronix
	Kernel Team <kernel@pengutronix.de>, Fabio Estevam <festevam@gmail.com>
Date: Fri, 10 Jan 2025 09:06:09 +0100
In-Reply-To: <20250109150310.219442-11-tzimmermann@suse.de>
References: <20250109150310.219442-1-tzimmermann@suse.de>
	 <20250109150310.219442-11-tzimmermann@suse.de>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.46.4-2 
MIME-Version: 1.0
X-SA-Exim-Connect-IP: 2a0a:edc0:0:c01:1d::a2
X-SA-Exim-Mail-From: p.zabel@pengutronix.de
X-SA-Exim-Scanned: No (on metis.whiteo.stw.pengutronix.de); SAEximRunCond expanded to false
X-PTX-Original-Recipient: xen-devel@lists.xenproject.org

On Do, 2025-01-09 at 15:57 +0100, Thomas Zimmermann wrote:
> Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
> buffer size. The hardware requires the framebuffer width to be a
> multiple of 8. The scanline pitch has be large enough to support
> this. Therefore compute the byte size of 8 pixels in the given color
> mode and align the pitch accordingly.
>=20
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> Cc: Fabio Estevam <festevam@gmail.com>

Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>

regards
Philipp


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 08:16:24 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 08:16:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869296.1280755 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWABr-0001RX-Py; Fri, 10 Jan 2025 08:16:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869296.1280755; Fri, 10 Jan 2025 08:16:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWABr-0001RQ-N0; Fri, 10 Jan 2025 08:16:23 +0000
Received: by outflank-mailman (input) for mailman id 869296;
 Fri, 10 Jan 2025 08:16: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 <SRS0=r1rC=UC=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tWABq-0001RI-2S
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 08:16:22 +0000
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com
 [2a00:1450:4864:20::335])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2c9a52cf-cf2b-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 09:16:21 +0100 (CET)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-43634b570c1so13013725e9.0
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 00:16:21 -0800 (PST)
Received: from [192.168.1.74] (88-187-86-199.subs.proxad.net. [88.187.86.199])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436e9e37d46sm44133015e9.25.2025.01.10.00.16.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 10 Jan 2025 00:16:19 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2c9a52cf-cf2b-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1736496980; x=1737101780; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=kv7FKYaMN/WUvTocOgd+87qkT+pqaT6mSOki8l9byUQ=;
        b=k9X8VTAoLa5is4/9AjBQuGfMBnVjYSXKs8xvZ2sZiOQv1mXWdsARrqnikVL13tmo3v
         vPYs+xRthLNGex9xSWupLdrPZj3f/hOWdYrpAEop2JBFwHc2u8qrWIvwtAkzF4HPYYVc
         LXSKDtFJve/YVMqAnz2JyHpYceNwFWQUh4bRjXYuuHpm1Hzwoi2Jd0pLipJAElm6csl7
         oOeCP2TVdUnUgACwbxyM3N3NJ/deydtL5Ae2rGb+5hwNtuDVrzKxA1wrsOtNLmnM0Jji
         LRgaDHYR+Wvc7nSXhi8LPyz/FNsYuoUbJE7nBdgCM5pn0dhzKDb0Dz8F1g8ZOw4K0Mde
         z4Mg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736496980; x=1737101780;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=kv7FKYaMN/WUvTocOgd+87qkT+pqaT6mSOki8l9byUQ=;
        b=Y8b+BJE6Vd7YaaRyVCmBPmrf55wYmfpthqlDLeNv/1tGpqaC+EmOocMFUE/BElawW1
         r1YH0JlG9TxolTCARlbqhuGpHexgbYxvLwB9mfmK7E7Uj4bDDZ2V2TuotiYBrL/7Qqpe
         SNtfKmGC4kyEKmq20V1rSP76rHBd18DZYJDOh5xaZQamEiAcfHsgly7qc96cNr+N33Mi
         1vd7w8+CZV/glESRSFUclB9D+wfBZnpAtTmIvrCWLYa7/iW0nTEDyh60lRsyV2fPxMFn
         ifgQb/ghhL0P6kjB86qOAVlmpxjkpD22X10nSd5NsjDN/VmASdUQI2oEcXWLbKhzXY+O
         IySg==
X-Forwarded-Encrypted: i=1; AJvYcCWWEUqfYru/7gzknHDiG0j0oGq90/QeYbZqOmZ8OpwEogRFscM8SFTWA2XLhwkjGxbu8eeH2rKMKGo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyZBOn2Ntt+yD0MhzNASusnREkWfT8ha952bUcu/hFgCp3TgwlW
	Ab5+oVk7wmljJ8RM8YTLsdSFSZ85t8mrb9r6V5YzdL6dsn74QQfM1fUG9sTKmGg=
X-Gm-Gg: ASbGncufPc3uxIxMIpVKlPxEaQV3TbRNUMixEuoSMUAzKdMLEViukxVVrJomajuznmU
	HlxaapV2qN7TkjyOifjQF6pNxlqDvVrBkz4G9jeu6+St0+khtpjt1euFMYxfOieTSKGGMgbN/HG
	qczb6Wdy3qrEb6BNSN5HrfTDSb82nt0Eewdlhb9JQ+lABNCu0eYykTaEO68ZSbparzt3yehX4xv
	PZkxvfnd4SHSCGpc0bfgEIHT2XnT+bAX4v/PyBXFe+7C53fTYFxZGMvXS0P5Q7ZB59D19YGc//B
	QbvQ8GuRFtCAOMSFfVSJrQNaUSE=
X-Google-Smtp-Source: AGHT+IFVGQx2dSjVmPRIlM+jesEk6scS9hu8M0GdFRKVQxW47gkq6Hxm/JvalF9ICQZy0vXxVeGaqg==
X-Received: by 2002:a05:600c:3149:b0:434:9fac:b158 with SMTP id 5b1f17b1804b1-436e2680c4amr79831195e9.1.1736496980317;
        Fri, 10 Jan 2025 00:16:20 -0800 (PST)
Message-ID: <73307130-f03e-413d-98fb-7e6c05383851@linaro.org>
Date: Fri, 10 Jan 2025 09:16:19 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/2] xen: do not use '%ms' scanf specifier
To: David Woodhouse <dwmw2@infradead.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Cc: Anthony PERARD <anthony@xenproject.org>, qemu-devel@nongnu.org,
 Stefano Stabellini <sstabellini@kernel.org>, Paul Durrant <paul@xen.org>,
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
 =?UTF-8?Q?Marc-Andr=C3=A9_Lureau?= <marcandre.lureau@redhat.com>,
 Paolo Bonzini <pbonzini@redhat.com>, xen-devel@lists.xenproject.org
References: <20250107093140.86180-1-roger.pau@citrix.com>
 <20250107093140.86180-3-roger.pau@citrix.com> <Z3-sJMXpiFUoATHz@l14>
 <974ab6743d168d34babd458fe5e2e7766bb280b4.camel@infradead.org>
 <Z3__eDp4hShe79Pl@macbook.local>
 <17c134258de9517b677f08a865394f8075d67bdf.camel@infradead.org>
Content-Language: en-US
From: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= <philmd@linaro.org>
In-Reply-To: <17c134258de9517b677f08a865394f8075d67bdf.camel@infradead.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 10/1/25 09:08, David Woodhouse wrote:
> On Thu, 2025-01-09 at 17:55 +0100, Roger Pau Monné wrote:
>> On Thu, Jan 09, 2025 at 11:25:13AM +0000, David Woodhouse wrote:
>>> On Thu, 2025-01-09 at 11:59 +0100, Anthony PERARD wrote:
>>>>
>>>>>        char label[32];
>>>>>        XenDevice *xendev = NULL;
>>>>>        XenConsole *con;
>>>>> @@ -550,7 +551,10 @@ static void xen_console_device_create(XenBackendInstance *backend,
>>>>>            goto fail;
>>>>>        }
>>>>>    
>>>>> -    if (xs_node_scanf(xsh, XBT_NULL, fe, "type", errp, "%ms", &type) != 1) {
>>>>> +    node_path = g_strdup_printf("%s/type", fe);
>>>>> +    type = qemu_xen_xs_read(xsh, XBT_NULL, node_path, NULL);
>>>>> +    g_free(node_path);
>>>>
>>>> I feel like we want "xs_node_read()" which would be similair to
>>>> xs_node_vscanf() but would simply return the result of
>>>> qemu_xen_xs_read(). This would avoid the need format of the node path in
>>>> several place in the code. But it's OK like that as well.
>>>
>>> If you look at the other callers of qemu_xen_xs_read(), it looks like
>>> the majority of them create the path with snprintf and then pass it in.
>>> Or with g_strdup_printf(), pass it in, then free it afterwards.
>>>
>>> So perhaps qemu_xen_xs_read() should be a printf-style function too,
>>> with its last arg(s) being the node name.
>>
>> I just went with Anthony suggestion and introduced xs_node_read(), as
>> I didn't want to play with qemu_xen_xs_read().  Not that I think the
>> suggestion is not valid, just seemed more work than what I wanted to
>> do right now.
> 
> Makes sense. Something like this¹?
> 
> char *xs_node_read(struct qemu_xs_handle *h, xs_transaction_t tid,
>                     Error **errp, unsigned int *len,

Maybe switch len <-> errp arg order.

>                     const char *node_fmt, ...)
>      G_GNUC_PRINTF(5, 6);
> 
> There's a %ms in hw/xen/xen-block.c too, btw. Did you catch that one?
> 
> 
> ¹ https://git.infradead.org/?p=users/dwmw2/qemu.git;a=commitdiff;h=percentms;hp=bc6afa1c711da5b4f37c9685a812c77b114d84cb



From xen-devel-bounces@lists.xenproject.org Fri Jan 10 08:22:01 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 08:22:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869306.1280764 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWAH3-0003FE-Ao; Fri, 10 Jan 2025 08:21:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869306.1280764; Fri, 10 Jan 2025 08:21:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWAH3-0003F7-8J; Fri, 10 Jan 2025 08:21:45 +0000
Received: by outflank-mailman (input) for mailman id 869306;
 Fri, 10 Jan 2025 08:21: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
 <SRS0=b62p=UC=casper.srs.infradead.org=BATV+4f8727a5892a49e75626+7810+infradead.org+dwmw2@srs-se1.protection.inumbo.net>)
 id 1tWAH2-0003F1-2B
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 08:21:44 +0000
Received: from casper.infradead.org (casper.infradead.org
 [2001:8b0:10b:1236::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ec4702cb-cf2b-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 09:21:42 +0100 (CET)
Received: from 54-240-197-238.amazon.com ([54.240.197.238]
 helo=edge-cache-192.e-lhr50.amazon.com)
 by casper.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux))
 id 1tWAH0-0000000CSWD-04Zw; Fri, 10 Jan 2025 08:21:42 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ec4702cb-cf2b-11ef-a0df-8be0dac302b0
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:Cc:To:From:Subject:Message-ID:Sender:Reply-To:
	Content-Transfer-Encoding:Content-ID:Content-Description;
	bh=tGMjyQd2+jGi5ezrE20+Dh0F2Vs0fb19lFk8NfL0r9k=; b=TwokirjTExSWPrqRFq3QqI4LtL
	aLG3v/z52LdIDGYh8bWV/V1TUW/bxKkHQBMMuAkXPSffEDoMQ5ynLY95Lu+taBnXozycK5HWqij5m
	7YB5uhxS3bxxq3TxCYWgDaWjWEKCE6DiFzwYViOOxsgrQCsuAL+mV7rNRGMoCBYOmy3H0l/4rLTpY
	M1G5N9fuw+poNG1/pgJ5Z2rTfKSOD7fhYB+i15CxiwbAUTuKB6E5mdzSaL+FAX9xFH4DXY8zFdGpp
	s3/RQ/gmcHRJ8paiStTcg0BV23vYFuYtiBKNfNhuA1VoWwvI+OYjq7IqTrrUJcg8+uoajT0neSG6I
	DvhR0nig==;
Message-ID: <868327eef674cb45d4230f388c1674fe1dced86f.camel@infradead.org>
Subject: Re: [PATCH 2/2] xen: do not use '%ms' scanf specifier
From: David Woodhouse <dwmw2@infradead.org>
To: Philippe =?ISO-8859-1?Q?Mathieu-Daud=E9?= <philmd@linaro.org>, Roger
 Pau =?ISO-8859-1?Q?Monn=E9?=
	 <roger.pau@citrix.com>
Cc: Anthony PERARD <anthony@xenproject.org>, qemu-devel@nongnu.org, Stefano
 Stabellini <sstabellini@kernel.org>, Paul Durrant <paul@xen.org>, "Edgar E.
 Iglesias" <edgar.iglesias@gmail.com>, =?ISO-8859-1?Q?Marc-Andr=E9?= Lureau
 <marcandre.lureau@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>, 
 xen-devel@lists.xenproject.org
Date: Fri, 10 Jan 2025 08:21:41 +0000
In-Reply-To: <73307130-f03e-413d-98fb-7e6c05383851@linaro.org>
References: <20250107093140.86180-1-roger.pau@citrix.com>
	 <20250107093140.86180-3-roger.pau@citrix.com> <Z3-sJMXpiFUoATHz@l14>
	 <974ab6743d168d34babd458fe5e2e7766bb280b4.camel@infradead.org>
	 <Z3__eDp4hShe79Pl@macbook.local>
	 <17c134258de9517b677f08a865394f8075d67bdf.camel@infradead.org>
	 <73307130-f03e-413d-98fb-7e6c05383851@linaro.org>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-LCYR3IEEqcqhJw1BSRXw"
User-Agent: Evolution 3.52.3-0ubuntu1 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html


--=-LCYR3IEEqcqhJw1BSRXw
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2025-01-10 at 09:16 +0100, Philippe Mathieu-Daud=C3=A9 wrote:
> On 10/1/25 09:08, David Woodhouse wrote:
> > On Thu, 2025-01-09 at 17:55 +0100, Roger Pau Monn=C3=A9 wrote:
> > > On Thu, Jan 09, 2025 at 11:25:13AM +0000, David Woodhouse wrote:
> > > > On Thu, 2025-01-09 at 11:59 +0100, Anthony PERARD wrote:
> > > > >=20
> > > > > > =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 char label[32];
> > > > > > =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 XenDevice *xendev =3D NUL=
L;
> > > > > > =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 XenConsole *con;
> > > > > > @@ -550,7 +551,10 @@ static void xen_console_device_create(XenB=
ackendInstance *backend,
> > > > > > =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 g=
oto fail;
> > > > > > =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
> > > > > > =C2=A0=C2=A0=C2=A0=20
> > > > > > -=C2=A0=C2=A0=C2=A0 if (xs_node_scanf(xsh, XBT_NULL, fe, "type"=
, errp, "%ms", &type) !=3D 1) {
> > > > > > +=C2=A0=C2=A0=C2=A0 node_path =3D g_strdup_printf("%s/type", fe=
);
> > > > > > +=C2=A0=C2=A0=C2=A0 type =3D qemu_xen_xs_read(xsh, XBT_NULL, no=
de_path, NULL);
> > > > > > +=C2=A0=C2=A0=C2=A0 g_free(node_path);
> > > > >=20
> > > > > I feel like we want "xs_node_read()" which would be similair to
> > > > > xs_node_vscanf() but would simply return the result of
> > > > > qemu_xen_xs_read(). This would avoid the need format of the node =
path in
> > > > > several place in the code. But it's OK like that as well.
> > > >=20
> > > > If you look at the other callers of qemu_xen_xs_read(), it looks li=
ke
> > > > the majority of them create the path with snprintf and then pass it=
 in.
> > > > Or with g_strdup_printf(), pass it in, then free it afterwards.
> > > >=20
> > > > So perhaps qemu_xen_xs_read() should be a printf-style function too=
,
> > > > with its last arg(s) being the node name.
> > >=20
> > > I just went with Anthony suggestion and introduced xs_node_read(), as
> > > I didn't want to play with qemu_xen_xs_read().=C2=A0 Not that I think=
 the
> > > suggestion is not valid, just seemed more work than what I wanted to
> > > do right now.
> >=20
> > Makes sense. Something like this=C2=B9?
> >=20
> > char *xs_node_read(struct qemu_xs_handle *h, xs_transaction_t tid,
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Error **errp, unsigned =
int *len,
>=20
> Maybe switch len <-> errp arg order.

Ack. Changed in my 'percentms' branch in case Roger wants to use it.

We can then clean up a few users of snprintf+qemu_xen_xs_read() to use
xs_node_read() too.

--=-LCYR3IEEqcqhJw1BSRXw
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD9Aw
ggSOMIIDdqADAgECAhAOmiw0ECVD4cWj5DqVrT9PMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0yNDAxMzAwMDAwMDBaFw0zMTEx
MDkyMzU5NTlaMEExCzAJBgNVBAYTAkFVMRAwDgYDVQQKEwdWZXJva2V5MSAwHgYDVQQDExdWZXJv
a2V5IFNlY3VyZSBFbWFpbCBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMjvgLKj
jfhCFqxYyRiW8g3cNFAvltDbK5AzcOaR7yVzVGadr4YcCVxjKrEJOgi7WEOH8rUgCNB5cTD8N/Et
GfZI+LGqSv0YtNa54T9D1AWJy08ZKkWvfGGIXN9UFAPMJ6OLLH/UUEgFa+7KlrEvMUupDFGnnR06
aDJAwtycb8yXtILj+TvfhLFhafxroXrflspavejQkEiHjNjtHnwbZ+o43g0/yxjwnarGI3kgcak7
nnI9/8Lqpq79tLHYwLajotwLiGTB71AGN5xK+tzB+D4eN9lXayrjcszgbOv2ZCgzExQUAIt98mre
8EggKs9mwtEuKAhYBIP/0K6WsoMnQCcCAwEAAaOCAVwwggFYMBIGA1UdEwEB/wQIMAYBAf8CAQAw
HQYDVR0OBBYEFIlICOogTndrhuWByNfhjWSEf/xwMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6en
IZ3zbcgPMA4GA1UdDwEB/wQEAwIBhjAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIweQYI
KwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYIKwYB
BQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RD
QS5jcnQwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0
QXNzdXJlZElEUm9vdENBLmNybDARBgNVHSAECjAIMAYGBFUdIAAwDQYJKoZIhvcNAQELBQADggEB
ACiagCqvNVxOfSd0uYfJMiZsOEBXAKIR/kpqRp2YCfrP4Tz7fJogYN4fxNAw7iy/bPZcvpVCfe/H
/CCcp3alXL0I8M/rnEnRlv8ItY4MEF+2T/MkdXI3u1vHy3ua8SxBM8eT9LBQokHZxGUX51cE0kwa
uEOZ+PonVIOnMjuLp29kcNOVnzf8DGKiek+cT51FvGRjV6LbaxXOm2P47/aiaXrDD5O0RF5SiPo6
xD1/ClkCETyyEAE5LRJlXtx288R598koyFcwCSXijeVcRvBB1cNOLEbg7RMSw1AGq14fNe2cH1HG
W7xyduY/ydQt6gv5r21mDOQ5SaZSWC/ZRfLDuEYwggWbMIIEg6ADAgECAhAH5JEPagNRXYDiRPdl
c1vgMA0GCSqGSIb3DQEBCwUAMEExCzAJBgNVBAYTAkFVMRAwDgYDVQQKEwdWZXJva2V5MSAwHgYD
VQQDExdWZXJva2V5IFNlY3VyZSBFbWFpbCBHMjAeFw0yNDEyMzAwMDAwMDBaFw0yODAxMDQyMzU5
NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqGSIb3DQEBAQUAA4IC
DwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZeYAS/SRV6zmfXlXaZ
sNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2zkC9S7/yHDYnqegqt
w4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qGpgFdZEk2/c//ZvUN
i12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41vav1RhZJzYan4a1gU0
kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0cvnO8FM6PTqsnSbcc
0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PWPU6zfQTOMZ9uLQRR
ci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXtREF5lLXxp+CJ6KKS
blPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQrlR0gO3lBzuyPPArV
hvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7IqaAovAX0d+f1YjbmC
VsAwjhLmveFjNwIDAQABo4IBsDCCAawwHwYDVR0jBBgwFoAUiUgI6iBOd2uG5YHI1+GNZIR//HAw
HQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3bXcyQGluZnJhZGVh
ZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEBMA4GA1UdDwEB/wQE
AwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwewYDVR0fBHQwcjA3oDWgM4YxaHR0
cDovL2NybDMuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNybDA3oDWgM4YxaHR0
cDovL2NybDQuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNybDB2BggrBgEFBQcB
AQRqMGgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBABggrBgEFBQcwAoY0
aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNydDANBgkq
hkiG9w0BAQsFAAOCAQEAQXc4FPiPLRnTDvmOABEzkIumojfZAe5SlnuQoeFUfi+LsWCKiB8Uextv
iBAvboKhLuN6eG/NC6WOzOCppn4mkQxRkOdLNThwMHW0d19jrZFEKtEG/epZ/hw/DdScTuZ2m7im
8ppItAT6GXD3aPhXkXnJpC/zTs85uNSQR64cEcBFjjoQDuSsTeJ5DAWf8EMyhMuD8pcbqx5kRvyt
JPsWBQzv1Dsdv2LDPLNd/JUKhHSgr7nbUr4+aAP2PHTXGcEBh8lTeYea9p4d5k969pe0OHYMV5aL
xERqTagmSetuIwolkAuBCzA9vulg8Y49Nz2zrpUGfKGOD0FMqenYxdJHgDCCBZswggSDoAMCAQIC
EAfkkQ9qA1FdgOJE92VzW+AwDQYJKoZIhvcNAQELBQAwQTELMAkGA1UEBhMCQVUxEDAOBgNVBAoT
B1Zlcm9rZXkxIDAeBgNVBAMTF1Zlcm9rZXkgU2VjdXJlIEVtYWlsIEcyMB4XDTI0MTIzMDAwMDAw
MFoXDTI4MDEwNDIzNTk1OVowHjEcMBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzCCAiIwDQYJ
KoZIhvcNAQEBBQADggIPADCCAgoCggIBANqWLse95HW2F7FhfH9bugyT/danKmmXrbMnz5GZNAfj
Jl5gBL9JFXrOZ9eVdpmw04Tp6aDxZctFLoEDvSWKi367Q7Sg+ci+fH4KwwfQ8Pi0IpIKx2n5emEg
nbOQL1Lv/IcNiep6Cq3DiyaSpSp/RZf+CAfUNySHS8eWmhLU6jGpSD6hxTpYKye7PmrmvMWwfGEP
WoamAV1kSTb9z/9m9Q2LXa89aKmTxNwnAfD3Ohn9mtU3JukwILRMewn9QRXK7KzM+01h5hkCE4nj
W9q/VGFknNhqfhrWBTSQoE9CSVylASGrjzCgS7XmKy/BaH3/7mOOHQv5g1o3Qj/+cdKnpT0I5Qb1
nRy+c7wUzo9OqydJtxzSP4ZyHA4dELto/a3m/ay1XHcpum1pgTOLgxAfGb/T4dCkwRUstSKLMmpL
g9Y9TrN9BM4xn24tBFFyL5znGG0wQGzOVAM68RBzIQb6Fz758fjsr4yZnPbVsU1+gHEs/puNHrG0
9e1EQXmUtfGn4InoopJuU8p5VGD9S3Ikd4UoBlc7xl5yjtNlQxUeYrRlnUSmdlucCEoTX1n4UmtA
9CuVHSA7eUHO7I88CtWG9bGOU7tLgOZoSEvNqtaL/N7sQbBZK4jZ4Rr/zNTQg1SwYjjLB7u96lDP
sipoCi8BfR35/ViNuYJWwDCOEua94WM3AgMBAAGjggGwMIIBrDAfBgNVHSMEGDAWgBSJSAjqIE53
a4blgcjX4Y1khH/8cDAdBgNVHQ4EFgQUXGIam3Bs59Y60yTmWgfDu6pZQ6cwMAYDVR0RBCkwJ4ET
ZHdtdzJAaW5mcmFkZWFkLm9yZ4EQZGF2aWRAd29vZGhvdS5zZTAUBgNVHSAEDTALMAkGB2eBDAEF
AQEwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDB7BgNVHR8E
dDByMDegNaAzhjFodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVtYWlsRzIu
Y3JsMDegNaAzhjFodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVtYWlsRzIu
Y3JsMHYGCCsGAQUFBwEBBGowaDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29t
MEAGCCsGAQUFBzAChjRodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVt
YWlsRzIuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQBBdzgU+I8tGdMO+Y4AETOQi6aiN9kB7lKWe5Ch
4VR+L4uxYIqIHxR7G2+IEC9ugqEu43p4b80LpY7M4KmmfiaRDFGQ50s1OHAwdbR3X2OtkUQq0Qb9
6ln+HD8N1JxO5nabuKbymki0BPoZcPdo+FeRecmkL/NOzzm41JBHrhwRwEWOOhAO5KxN4nkMBZ/w
QzKEy4PylxurHmRG/K0k+xYFDO/UOx2/YsM8s138lQqEdKCvudtSvj5oA/Y8dNcZwQGHyVN5h5r2
nh3mT3r2l7Q4dgxXlovERGpNqCZJ624jCiWQC4ELMD2+6WDxjj03PbOulQZ8oY4PQUyp6djF0keA
MYIDuzCCA7cCAQEwVTBBMQswCQYDVQQGEwJBVTEQMA4GA1UEChMHVmVyb2tleTEgMB4GA1UEAxMX
VmVyb2tleSBTZWN1cmUgRW1haWwgRzICEAfkkQ9qA1FdgOJE92VzW+AwDQYJYIZIAWUDBAIBBQCg
ggE3MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTI1MDExMDA4MjE0
MVowLwYJKoZIhvcNAQkEMSIEIFSdPAXclUH18tGfOnC/GHFtG2BFOq2oeLX0lN8ZPj7hMGQGCSsG
AQQBgjcQBDFXMFUwQTELMAkGA1UEBhMCQVUxEDAOBgNVBAoTB1Zlcm9rZXkxIDAeBgNVBAMTF1Zl
cm9rZXkgU2VjdXJlIEVtYWlsIEcyAhAH5JEPagNRXYDiRPdlc1vgMGYGCyqGSIb3DQEJEAILMVeg
VTBBMQswCQYDVQQGEwJBVTEQMA4GA1UEChMHVmVyb2tleTEgMB4GA1UEAxMXVmVyb2tleSBTZWN1
cmUgRW1haWwgRzICEAfkkQ9qA1FdgOJE92VzW+AwDQYJKoZIhvcNAQEBBQAEggIAohs9pUWAtc1s
NcpVNygVAe33v9oci8I5lUtGKkNt5Qve8Cavav2P1GZh+FUoFmH93BmEKw82/GT47tqP2XSxVmX9
CSAs4svypEMW737BXzrWwzYKOuesoG8IxMMglz1FkBMHkVwp0v25UFPxm/jnFU9KMoK15yCOIbfH
xu5YId5j/M0XANE6A28NoqaJXq9uyftjzbrnWh7Z42XMD/4/vrlBHJxsREd9vrwCVptwUq/ttjX9
FqztnWikoQcfIEV48u2wwn4k76Qh2l4YqwJauuuw10zr7IPR8QMgBaitlfd8ieTx0dtFiBrpBHL6
N9RdJ6HmhxMRXUo52hTeZ0i34Urdlqt3NdRxUOz8G128XLzoNPkzTxLH2Ch9ltuauO8QeGottbSc
e+VSEv68NN0UoUnqnAk7ovX2zFHVApYm+l7U88NorpaKLcCov6U51kqvOV1gvK6VGIiP0GaeSj3W
LShZ16tUtxuw5l+P0OG48jlMYgu9g7TacDGrBMIfYhCfvrbH6l8N9nLGxp7NmtX/BymwpXvmsXUt
DgKdOoziHpUA+88/wz/GEOpKcmb5ppypGMMr43Ur0SuvT56R7WXzfeiVk3ZEODpk3+MQyoiCsXly
9PqnoQSdxiSw6Eq+pnXIH5QehGBERhCNuQQEoZ64PEMxKFkI1cSlIlTIfmHYAK4AAAAAAAA=


--=-LCYR3IEEqcqhJw1BSRXw--


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 08:29:44 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 08:29:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869319.1280783 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWAOY-00040v-5O; Fri, 10 Jan 2025 08:29:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869319.1280783; Fri, 10 Jan 2025 08:29:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWAOY-00040o-1h; Fri, 10 Jan 2025 08:29:30 +0000
Received: by outflank-mailman (input) for mailman id 869319;
 Fri, 10 Jan 2025 08:29:29 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=J0bo=UC=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tWAOX-00040d-1B
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 08:29:29 +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 01afb03f-cf2d-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 09:29:28 +0100 (CET)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-5d437235769so2796969a12.2
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 00:29:28 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d99008c2d7sm1430082a12.3.2025.01.10.00.29.27
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 10 Jan 2025 00:29:27 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 01afb03f-cf2d-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736497767; x=1737102567; 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=D4ICae/veHvifgIXZmGBCTFTE2MaB92Q6Qd4tbvpzjY=;
        b=BNcfzqjREy6BnJzJssFUzX790xmP2igYjJ5UUvTzOkr6XgHLS6rNOpOMrMJG/UeBOp
         K6wk1lyZe4KLMgtZ0rHzYww7r/AGVICEh+IID6uztP2EHHh6vWYlL/h7LO5CjQVCtY0t
         /zoQtBpDJeUdGpSI9zIw6FL0XO6822GvxTrAs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736497767; x=1737102567;
        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=D4ICae/veHvifgIXZmGBCTFTE2MaB92Q6Qd4tbvpzjY=;
        b=oT2r3jddwJd4tURvagGxFw9PamG9oHp6a8Sn02jhlf61FPd2BCqqpwEb4bVeJKP6xi
         wwB+wc2Pdw3Sx0v21jRBMCPkQrKUiYdKXiMGhGZdK1xYYIzM9cSx24sAPwJv8wR/YM+2
         S0S5S9/8gFic+s3pzLWvjb2L5qwQYfyDEFUGOLL3UkaICGtWOMkUGo6Kbbvjed32h4rf
         jZl9rxYPVu+noi+dT7TBPbzNRbSzyXteqNc9+xKZrCU0b4JAkosEOOB5lLh7MU9ZXNUS
         vvFsL8Yj5s8EoK4iKVLJZ0GPnfkiKiZpqGhAQbaZQ+aBdbH96cgbWW4ujyd70cZmhUfJ
         k2yg==
X-Forwarded-Encrypted: i=1; AJvYcCW98PnLHOCNBCiew8C6IAMVSGDL9tHC1W2jLPReHdhVKDmi7bRLjVU1FWy8zyHAljlBzmqbfJ1FY5E=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy2A5I5Mmqjt9Du2rcDO7bZDOICkk/l7oPf3MiDoozYciIYPsPk
	wMFUobNnr4MSk5Gvm9m0GeA6RJTzFfYUl8o+lnsevHYI2ERp6097sERt5I34NGs=
X-Gm-Gg: ASbGncsNIdjEKpvBhbnx90qytAJK/mchxdeg/3yi605v9EGvgQR6r/EPUtHRxdFp9Cs
	8uvSTQh/5JWDZCPb27BEQrQHtfO/biBmU7kPT7d/Ze6tIKErKGLNnHwLa7Ld+mFjpHzfcya9eLx
	beZ/voxk73bOKPw+DkqHJ6khl0yThio4LMn7dYkgDad9tnNzkgZKSaUWL1U/UnnOBJugOYK8IZS
	mUEcL5BjIWiqTvhidKKCrGL94mxnDv1ypW5lHloxEsSdm6vYZWii8M+5BB6yw==
X-Google-Smtp-Source: AGHT+IGICDCLF7EqLsMeKfdZ3QDCFUtrhTkUmxRZZTYKVsqaXBGBv66eyDQXC5EtBvMGtnHpK1K/dw==
X-Received: by 2002:a05:6402:254d:b0:5d0:81dc:f20e with SMTP id 4fb4d7f45d1cf-5d972e1c5cfmr8993118a12.17.1736497767592;
        Fri, 10 Jan 2025 00:29:27 -0800 (PST)
Date: Fri, 10 Jan 2025 09:29:26 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: Nicola Vetrini <nicola.vetrini@bugseng.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel@lists.xenproject.org, consulting@bugseng.com
Subject: Re: [PATCH v2 1/2] x86/uaccess: rework user access speculative
 harden guards
Message-ID: <Z4DaZlbEDEjxQ6g-@macbook.local>
References: <20241126093508.6966-1-roger.pau@citrix.com>
 <20241126093508.6966-2-roger.pau@citrix.com>
 <cf1f87d1-f616-4944-94fa-69a777249072@suse.com>
 <e3ec3dad28dc94436c0b330b2f995120@bugseng.com>
 <alpine.DEB.2.22.394.2501031617280.16425@ubuntu-linux-20-04-desktop>
 <8e31daaf77216534c252d371a3251595@bugseng.com>
 <alpine.DEB.2.22.394.2501091556590.133435@ubuntu-linux-20-04-desktop>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.22.394.2501091556590.133435@ubuntu-linux-20-04-desktop>

On Thu, Jan 09, 2025 at 03:57:24PM -0800, Stefano Stabellini wrote:
> On Thu, 9 Jan 2025, Nicola Vetrini wrote:
> > On 2025-01-04 01:20, Stefano Stabellini wrote:
> > > Hi Nicola, one question below
> > > 
> > > On Wed, 27 Nov 2024, Nicola Vetrini wrote:
> > > > > #define AMD_OSVW_ERRATUM(osvw_id, ...)  osvw_id, __VA_ARGS__, 0
> > > > >
> > > > > where we're using the C99 form rather than the GNU extension, and where
> > > > > hence __VA_ARGS__ would - by extrapolation of the Misra rule - need
> > > > > parenthesizing, when it isn't and can't be.
> > > > >
> > > > > Isn't it rather the case that variable argument macros need a more
> > > > general
> > > > > deviation, if not an adjustment to the Misra rule? Extending the Cc list
> > > > > some ...
> > > 
> > > Nicola, if you look at the original patch:
> > > https://marc.info/?l=xen-devel&m=173261356716876
> > > 
> > > "The current guards to select whether user accesses should be speculative
> > > hardened violate Misra rule 20.7, as the UA_KEEP() macro doesn't (and can't)
> > > parenthesize the 'args' argument."
> > > 
> > > And the very first change in the patch is:
> > > 
> > > diff --git a/xen/arch/x86/include/asm/uaccess.h
> > > b/xen/arch/x86/include/asm/uaccess.h
> > > index 2d01669b96..6b8150ac22 100644
> > > --- a/xen/arch/x86/include/asm/uaccess.h
> > > +++ b/xen/arch/x86/include/asm/uaccess.h
> > > @@ -24,9 +24,6 @@ unsigned int copy_from_unsafe_ll(void *to, const void
> > > *from, unsigned int n);
> > >  void noreturn __get_user_bad(void);
> > >  void noreturn __put_user_bad(void);
> > > 
> > > -#define UA_KEEP(args...) args
> > > -#define UA_DROP(args...)
> > > -
> > >  /**
> > >   * get_guest: - Get a simple variable from guest space.
> > >   * @x:   Variable to store result.
> > > 
> > > 
> > > Do you think there is any way we could configure Eclair, with or without
> > > a deviation, not to detect every use of UA_KEEP as violations?
> > 
> > I narrowed this violation down to a different treatment of the named variadic
> > argument. Since the argument 'args' cannot be parenthesized as a regular
> > argument could, the invocations of the 'UA_KEEP' cannot comply with the rule.
> > Therefore, as an extension to the rule, ECLAIR currently ignores the use of
> > '__VA_ARGS__' in a macro definition, but treats 'args...' as a regular macro
> > parameter name, hence the violation.
> > 
> > To be clear, these two definitions have the same semantics, but one shows a
> > violation and the other doesn't
> > 
> > #define UA_KEEP(args...) args
> > #define UA_KEEP(...) __VA_ARGS__
> > 
> > I will update ECLAIR to treat the two forms as the same, so this patch can be
> > dropped. If you think it's helpful I can send a patch spelling out this -
> > arbitrary, but reasonable in my opinion - extension to the MISRA rule (which
> > does not consider the implications related to the use of GNU exensions) so
> > that contributors have a clear picture of the situation.
> 
> Thank you Nicola! Yes the patch would be appreciated :-)

So unless the proposed adjustment is considered better for code
readability patch 1 can be dropped, and patch 2 could be applied after
the ECLAIR change is in effect?

How long will it take Nicola to get the ECLAIR change propagated into
the Gitlab runner?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 08:56:21 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 08:56:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869332.1280793 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWAoP-0008RD-8s; Fri, 10 Jan 2025 08:56:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869332.1280793; Fri, 10 Jan 2025 08:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWAoP-0008R6-60; Fri, 10 Jan 2025 08:56:13 +0000
Received: by outflank-mailman (input) for mailman id 869332;
 Fri, 10 Jan 2025 08:56:11 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=yVcS=UC=bugseng.com=nicola.vetrini@srs-se1.protection.inumbo.net>)
 id 1tWAoM-0008R0-CE
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 08:56:11 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bb38d2e8-cf30-11ef-99a4-01e77a169b0f;
 Fri, 10 Jan 2025 09:56:08 +0100 (CET)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 by support.bugseng.com (Postfix) with ESMTPA id 299D14EE0738;
 Fri, 10 Jan 2025 09:56:07 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: bb38d2e8-cf30-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1736499367; bh=vhhd8Bm2l6X7w5OCOM7Za68j+Tx0RW2AOqgQ9FvlmnM=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=OdIw51C/qTAy1iNaIzT4pTcthCy496dBpY5C9Sb4reZM0lkcLZVnaVnHokOAEHbRF
	 dOwSo8ZobWgLacZsXufVXUZrVO8XE5ccneMwYsV+ehuRoKZ9Ldc2eCRTYPJ/g4jxjU
	 eJe4+9Q6P4gt7YVaT+S2LpgLeENavKhUt4Z3mRQ1tfZqi8gk74sbHnolDviQEUMTPF
	 0x/ar4TVxmdj/pzdSjhoTufCOkJJjYXBqDUwyNKqP8JcYltbE4rQnM5XlmeB0BPMHE
	 szzNPqtv0NEoQJhtIqL9nMtSIduV2CEtssR/pEOgppUFZrtgxuhmZV9K7XujrLol21
	 XBuFaQmtRNMPA==
MIME-Version: 1.0
Date: Fri, 10 Jan 2025 09:56:07 +0100
From: Nicola Vetrini <nicola.vetrini@bugseng.com>
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Jan Beulich
 <jbeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 xen-devel@lists.xenproject.org, consulting@bugseng.com
Subject: Re: [PATCH v2 1/2] x86/uaccess: rework user access speculative harden
 guards
In-Reply-To: <Z4DaZlbEDEjxQ6g-@macbook.local>
References: <20241126093508.6966-1-roger.pau@citrix.com>
 <20241126093508.6966-2-roger.pau@citrix.com>
 <cf1f87d1-f616-4944-94fa-69a777249072@suse.com>
 <e3ec3dad28dc94436c0b330b2f995120@bugseng.com>
 <alpine.DEB.2.22.394.2501031617280.16425@ubuntu-linux-20-04-desktop>
 <8e31daaf77216534c252d371a3251595@bugseng.com>
 <alpine.DEB.2.22.394.2501091556590.133435@ubuntu-linux-20-04-desktop>
 <Z4DaZlbEDEjxQ6g-@macbook.local>
Message-ID: <ec0ff4e5654752c7adbe7c4f9402cbd2@bugseng.com>
X-Sender: nicola.vetrini@bugseng.com
Organization: BUGSENG s.r.l.
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit

On 2025-01-10 09:29, Roger Pau Monné wrote:
> On Thu, Jan 09, 2025 at 03:57:24PM -0800, Stefano Stabellini wrote:
>> On Thu, 9 Jan 2025, Nicola Vetrini wrote:
>> > On 2025-01-04 01:20, Stefano Stabellini wrote:
>> > > Hi Nicola, one question below
>> > >
>> > > On Wed, 27 Nov 2024, Nicola Vetrini wrote:
>> > > > > #define AMD_OSVW_ERRATUM(osvw_id, ...)  osvw_id, __VA_ARGS__, 0
>> > > > >
>> > > > > where we're using the C99 form rather than the GNU extension, and where
>> > > > > hence __VA_ARGS__ would - by extrapolation of the Misra rule - need
>> > > > > parenthesizing, when it isn't and can't be.
>> > > > >
>> > > > > Isn't it rather the case that variable argument macros need a more
>> > > > general
>> > > > > deviation, if not an adjustment to the Misra rule? Extending the Cc list
>> > > > > some ...
>> > >
>> > > Nicola, if you look at the original patch:
>> > > https://marc.info/?l=xen-devel&m=173261356716876
>> > >
>> > > "The current guards to select whether user accesses should be speculative
>> > > hardened violate Misra rule 20.7, as the UA_KEEP() macro doesn't (and can't)
>> > > parenthesize the 'args' argument."
>> > >
>> > > And the very first change in the patch is:
>> > >
>> > > diff --git a/xen/arch/x86/include/asm/uaccess.h
>> > > b/xen/arch/x86/include/asm/uaccess.h
>> > > index 2d01669b96..6b8150ac22 100644
>> > > --- a/xen/arch/x86/include/asm/uaccess.h
>> > > +++ b/xen/arch/x86/include/asm/uaccess.h
>> > > @@ -24,9 +24,6 @@ unsigned int copy_from_unsafe_ll(void *to, const void
>> > > *from, unsigned int n);
>> > >  void noreturn __get_user_bad(void);
>> > >  void noreturn __put_user_bad(void);
>> > >
>> > > -#define UA_KEEP(args...) args
>> > > -#define UA_DROP(args...)
>> > > -
>> > >  /**
>> > >   * get_guest: - Get a simple variable from guest space.
>> > >   * @x:   Variable to store result.
>> > >
>> > >
>> > > Do you think there is any way we could configure Eclair, with or without
>> > > a deviation, not to detect every use of UA_KEEP as violations?
>> >
>> > I narrowed this violation down to a different treatment of the named variadic
>> > argument. Since the argument 'args' cannot be parenthesized as a regular
>> > argument could, the invocations of the 'UA_KEEP' cannot comply with the rule.
>> > Therefore, as an extension to the rule, ECLAIR currently ignores the use of
>> > '__VA_ARGS__' in a macro definition, but treats 'args...' as a regular macro
>> > parameter name, hence the violation.
>> >
>> > To be clear, these two definitions have the same semantics, but one shows a
>> > violation and the other doesn't
>> >
>> > #define UA_KEEP(args...) args
>> > #define UA_KEEP(...) __VA_ARGS__
>> >
>> > I will update ECLAIR to treat the two forms as the same, so this patch can be
>> > dropped. If you think it's helpful I can send a patch spelling out this -
>> > arbitrary, but reasonable in my opinion - extension to the MISRA rule (which
>> > does not consider the implications related to the use of GNU exensions) so
>> > that contributors have a clear picture of the situation.
>> 
>> Thank you Nicola! Yes the patch would be appreciated :-)
> 
> So unless the proposed adjustment is considered better for code
> readability patch 1 can be dropped, and patch 2 could be applied after
> the ECLAIR change is in effect?
> 

Yes, exactly

> How long will it take Nicola to get the ECLAIR change propagated into
> the Gitlab runner?
> 
> Thanks, Roger.

We're still fixing the false positive upstream, but it shouldn't take 
too long so I think next week I should be able to refresh the runner.

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 09:36:04 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 09:36:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869350.1280812 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWBQl-0005qK-Ci; Fri, 10 Jan 2025 09:35:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869350.1280812; Fri, 10 Jan 2025 09:35:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWBQl-0005qD-AD; Fri, 10 Jan 2025 09:35:51 +0000
Received: by outflank-mailman (input) for mailman id 869350;
 Fri, 10 Jan 2025 09:35: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
 <SRS0=J0bo=UC=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tWBQk-0005c8-68
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 09:35:50 +0000
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [2a00:1450:4864:20::62c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 46d5f3a5-cf36-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 10:35:49 +0100 (CET)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-aaf6b1a5f2bso551254366b.1
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 01:35:49 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c9562519sm149700166b.132.2025.01.10.01.35.48
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 10 Jan 2025 01:35:48 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 46d5f3a5-cf36-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736501749; x=1737106549; 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=heAlNNCsF7d+p9roHrTGYRStQWTNbLe8js38yKlHKDA=;
        b=Ox1eoZnPJ42O5nX2N6Yazmcl8wHaHdeor61p73hamVJtDfsoNYLqLmDxmIN+SGNbdl
         uS/5vWAKJKpI9aGDJ/asjm70rCZpK3OpXrsz1BBq/z/yZX6FEHy17toUBDzOTUm4nV0k
         gwACi8XT4PqwlfluJYKRqXgRgAFXxlvw848aM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736501749; x=1737106549;
        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=heAlNNCsF7d+p9roHrTGYRStQWTNbLe8js38yKlHKDA=;
        b=ZK9Bu8FDdHjNBc2YF+knlPOAZP0D6kWKwYXtQSDHFwj7DDm7w0c7QbmNPy/p0t5OsP
         zKbDgAR3HkGpLiI1De01dg8R+f3o5AGlQoJ4eKLWWGnv11rE7N1pWMEc9wjzwW7WY7OB
         py1X8Z9bkDkwwqbcGDJoLIB0Y3C1ORll/kcTzy5Bn/8acuJ2ksb4rFUUOJ0M2b1nJLGV
         NRghJTIqAOIOQ+8D5dCMe1VFy7wgvx9elMPq2K98hLecgnH65VVFplJDoJm6AqGfajM8
         xLj8Y07/kXUi38bE/kmsYTygHHYSGmvrl2OmspGJ+Ni9RJ0DlmfqgqqELOP8dv5ejcMz
         uyaw==
X-Forwarded-Encrypted: i=1; AJvYcCWIC2GOGN+4Zl5JMiT55IE9R3e9Fz6PR4kJSRz3XJTrYH526+++rIUFPdOpHbWOLfiHIsWQYm/+/Mw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyvKS9QIFaKPw5KmhdHuV0mERC50CXl8Tn2FIgmkEyw/fa9OzNx
	jcbi7v6AzswKaUOQQyL/Qh2kMiy+F9V4+Qj5WR399wcye8touylFMrQXGKqlbU20WKbvuPWB7id
	F
X-Gm-Gg: ASbGnctOWh+8WHGxebKS2VpeIvk4eMxpeQ0eS6vXWWHYoxLAkNLy632ev69DT0c1MyR
	D094qFjAjng/ziRYmJXbvs9qusmfurvd5pM0afp6WTH8WOX0waHJgi05BaWw9OZkX6Y103fs9NF
	dfxMDLA/MZtvMxpbB8H/bhbg0Ci/AXibWJfHgsYIHHWt7m9MaS2yMXIujqI5mEeR9QPHx18Swjw
	4OWEKyeg3Pd9e93eqst97DkqpzDXAck7UvQy23i2mykKNMzOu+qJMaVA129iysFQs8=
X-Google-Smtp-Source: AGHT+IF9I+Bn1k3Y/QmCjZal+54tLnhYTkVBay0iOh00OvkCwpx1fGD8280XTGNWMnzZIdz6+zIOPQ==
X-Received: by 2002:a17:907:7282:b0:a9a:6c41:50a8 with SMTP id a640c23a62f3a-ab2c3c79cf5mr496036166b.17.1736501749069;
        Fri, 10 Jan 2025 01:35:49 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: qemu-devel@nongnu.org
Cc: David Woodhouse <dwmw@amazon.co.uk>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	xen-devel@lists.xenproject.org
Subject: [PATCH v2 1/2] hw/xen: Add xs_node_read() helper function
Date: Fri, 10 Jan 2025 10:35:30 +0100
Message-ID: <20250110093531.23221-2-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250110093531.23221-1-roger.pau@citrix.com>
References: <20250110093531.23221-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: David Woodhouse <dwmw@amazon.co.uk>

This returns the full contents of the node, having created the node path
from the printf-style format string provided in its arguments.

This will save various callers from having to do so for themselves (and
from using xs_node_scanf() with the non-portable %ms format string.

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
[remove double newline and constify trace parameters]
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: Anthony PERARD <anthony@xenproject.org>
Cc: Paul Durrant <paul@xen.org>
Cc: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>
Cc: xen-devel@lists.xenproject.org
---
 hw/xen/trace-events             |  1 +
 hw/xen/xen-bus-helper.c         | 22 ++++++++++++++++++++++
 include/hw/xen/xen-bus-helper.h |  4 ++++
 3 files changed, 27 insertions(+)

diff --git a/hw/xen/trace-events b/hw/xen/trace-events
index a07fe41c6d3b..461dee7b239f 100644
--- a/hw/xen/trace-events
+++ b/hw/xen/trace-events
@@ -39,6 +39,7 @@ xs_node_create(const char *node) "%s"
 xs_node_destroy(const char *node) "%s"
 xs_node_vprintf(char *path, char *value) "%s %s"
 xs_node_vscanf(char *path, char *value) "%s %s"
+xs_node_read(const char *path, const char *value) "%s %s"
 xs_node_watch(char *path) "%s"
 xs_node_unwatch(char *path) "%s"
 
diff --git a/hw/xen/xen-bus-helper.c b/hw/xen/xen-bus-helper.c
index b2b2cc9c5d5e..0fba7946c55e 100644
--- a/hw/xen/xen-bus-helper.c
+++ b/hw/xen/xen-bus-helper.c
@@ -142,6 +142,28 @@ int xs_node_scanf(struct qemu_xs_handle *h,  xs_transaction_t tid,
     return rc;
 }
 
+char *xs_node_read(struct qemu_xs_handle *h, xs_transaction_t tid,
+                   unsigned int *len, Error **errp,
+                   const char *node_fmt, ...)
+{
+    char *path, *value;
+    va_list ap;
+
+    va_start(ap, node_fmt);
+    path = g_strdup_vprintf(node_fmt, ap);
+    va_end(ap);
+
+    value = qemu_xen_xs_read(h, tid, path, len);
+    trace_xs_node_read(path, value);
+    if (!value) {
+        error_setg_errno(errp, errno, "failed to read from '%s'", path);
+    }
+
+    g_free(path);
+
+    return value;
+}
+
 struct qemu_xs_watch *xs_node_watch(struct qemu_xs_handle *h, const char *node,
                                     const char *key, xs_watch_fn fn,
                                     void *opaque, Error **errp)
diff --git a/include/hw/xen/xen-bus-helper.h b/include/hw/xen/xen-bus-helper.h
index d8dcc2f0107d..6478d25be5e6 100644
--- a/include/hw/xen/xen-bus-helper.h
+++ b/include/hw/xen/xen-bus-helper.h
@@ -37,6 +37,10 @@ int xs_node_scanf(struct qemu_xs_handle *h,  xs_transaction_t tid,
                   const char *node, const char *key, Error **errp,
                   const char *fmt, ...)
     G_GNUC_SCANF(6, 7);
+char *xs_node_read(struct qemu_xs_handle *h, xs_transaction_t tid,
+                   unsigned int *len, Error **errp,
+                   const char *node_fmt, ...)
+    G_GNUC_PRINTF(5, 6);
 
 /* Watch node/key unless node is empty, in which case watch key */
 struct qemu_xs_watch *xs_node_watch(struct qemu_xs_handle *h, const char *node,
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Fri Jan 10 09:36:04 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 09:36:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869349.1280803 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWBQk-0005cL-7M; Fri, 10 Jan 2025 09:35:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869349.1280803; Fri, 10 Jan 2025 09:35:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWBQk-0005cE-45; Fri, 10 Jan 2025 09:35:50 +0000
Received: by outflank-mailman (input) for mailman id 869349;
 Fri, 10 Jan 2025 09:35:49 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=J0bo=UC=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tWBQj-0005c8-62
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 09:35:49 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4600aef5-cf36-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 10:35:48 +0100 (CET)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-aae81f4fdc4so377811166b.0
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 01:35:48 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c905f0c9sm151901366b.19.2025.01.10.01.35.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 10 Jan 2025 01:35:47 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 4600aef5-cf36-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736501748; x=1737106548; 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=pETirQ8gMZHueGENb+NbJKwsttVKoOOQHvJbKrUYGcU=;
        b=aMNoyLAfsKsn8qab8N/nSE9ya1YFy9jMFthMcmSwllkVnUN1hx0QNMfkiWHXy9bggF
         2QXoA7IQmkgmiCE1vMn4LPnw++FY942hHAOZHqUiA7J3S3RnYhU9tBgrxN9XL4fERzGK
         +OqdSTOilRkI3nYNFDOyQm4Dhx28aoKj33eKI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736501748; x=1737106548;
        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=pETirQ8gMZHueGENb+NbJKwsttVKoOOQHvJbKrUYGcU=;
        b=n1HvKTaQWqoJfbxVwzfKoBuUBD9NJIYUW582eseLTuMKVSGXTl8KtibPlC+7QWxGxm
         /HBtkCzbN/1EUg+qG4yxglrb3kH2BGKSvtJJJueVteISDLklYS1rC6r228yo+waz91Bz
         oQf4gAq7lnuWThd52x6oCCytCSv4as6zlGgb5pWoKEx5GnSF4EnJvqEUZW4SktbtEUj9
         pkcvHWqKM8V2eub+NCtkHhgI2bR5gcUZuTr/jpGb5T0bP3GPnTZ/NrhUAfH5+0e9BgMi
         JNIjrOJ7Dxk8PUU8bQAlleTe9DY426hVD6O7+GKn4DkAdJVHW49WUAQ1a9M/5ocos7vT
         EIJw==
X-Forwarded-Encrypted: i=1; AJvYcCXeCUUUrmeP6Y8iptxZIUk55pSgkyxuUYxVL0+lkoU7QKKtqNU9eL0Lq1l23Flt0qjYMvco1q3fAbc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxqtlbQbghByJz9H+sCd8EMsaO0CTxCFj/wrhH8o3CpqqjM2B3p
	s3q/TxWTwIyvAPcWPIeNENg5c3Dk87RGsStW725E3gsBOdRoGBm/uqF1l6yL1j4=
X-Gm-Gg: ASbGncs9OLwwyFR0TCAWcL6AwnRaDARRJJR1UZW87FH6dimUlRUiLv0+u8DOnuu7S+a
	vsjboNaz9XHLRIMi0me/E5NcuFKwK/Shblnjd5wrhY7M5ZBPIFzh7oGuQJIfwqGvInjK/S6FiK4
	JhK0RFk3y2Pj1G5XFZ8xBgnRsVhOqm+p+wTTf6NIjhEBEtSa6+BRFT+6QEYThSjqbw9rm2x+ZMR
	vbRgtSpK1htCaQUhb+4HAnoc8F7V2u4S2TIfq2FzL0fLj8CTn1iqN/wffavVM/JOjg=
X-Google-Smtp-Source: AGHT+IF9Q+tc7zeQFkrp5t8due6zm/61UjY1kpKR16BTxlfnx3CZQHqRQ9rAy0+5QTUyBVAxonI8fw==
X-Received: by 2002:a17:907:3e24:b0:aa6:7737:199c with SMTP id a640c23a62f3a-ab2ab6fd036mr73135066b.15.1736501747665;
        Fri, 10 Jan 2025 01:35:47 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: qemu-devel@nongnu.org
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Kevin Wolf <kwolf@redhat.com>,
	Hanna Reitz <hreitz@redhat.com>,
	=?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= <marcandre.lureau@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	xen-devel@lists.xenproject.org,
	qemu-block@nongnu.org
Subject: [PATCH v2 0/2] xen: error handling and FreeBSD compatibility fixes
Date: Fri, 10 Jan 2025 10:35:29 +0100
Message-ID: <20250110093531.23221-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Hello,

First patch from David introduces a new helper to fetch xenstore nodes,
while second patch removes the usage of scanf related functions with the
"%ms" format specifier, as it's not supported by the FreeBSD scanf libc
implementation.

Thanks, Roger.

David Woodhouse (1):
  hw/xen: Add xs_node_read() helper function

Roger Pau Monné (1):
  xen: do not use '%ms' scanf specifier

 hw/block/xen-block.c            |  3 ++-
 hw/char/xen_console.c           | 14 ++++++++------
 hw/xen/trace-events             |  1 +
 hw/xen/xen-bus-helper.c         | 22 ++++++++++++++++++++++
 hw/xen/xen-bus.c                | 14 ++++++++++++--
 include/hw/xen/xen-bus-helper.h |  4 ++++
 include/hw/xen/xen-bus.h        |  1 +
 7 files changed, 50 insertions(+), 9 deletions(-)

-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Fri Jan 10 09:36:05 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 09:36:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869351.1280824 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWBQn-00065C-Lv; Fri, 10 Jan 2025 09:35:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869351.1280824; Fri, 10 Jan 2025 09:35:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWBQn-000651-HJ; Fri, 10 Jan 2025 09:35:53 +0000
Received: by outflank-mailman (input) for mailman id 869351;
 Fri, 10 Jan 2025 09:35: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
 <SRS0=J0bo=UC=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tWBQm-0005c8-2A
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 09:35:52 +0000
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
 [2a00:1450:4864:20::531])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 47e5df83-cf36-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 10:35:51 +0100 (CET)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-5d9882a936eso3308062a12.3
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 01:35:51 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d9900c98d6sm1406017a12.35.2025.01.10.01.35.49
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 10 Jan 2025 01:35:50 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 47e5df83-cf36-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736501751; x=1737106551; 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=Fl8lgxmL+/V36LVrcdeJiI3S1Q/yOAFdboy4Zc6RdL0=;
        b=A80Ow/3+yMMbfH5HJi1oEoaAQL0xoeIOS6GyIcyrwaHxNcw2WNf1CovI2D10b/T48d
         LIOwMWZONjyNl96kyPpWn34bmWuath6m9e0Uv7GnOb+LtG+rIerXtmdAxPRqodH7HPUr
         nlhQ8VQjC7MHi2zwlh7xYpswxj/inAqJ7oq4M=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736501751; x=1737106551;
        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=Fl8lgxmL+/V36LVrcdeJiI3S1Q/yOAFdboy4Zc6RdL0=;
        b=AbrHBy2qafx7lzlDVoPSuosiJ9gapjar9SJpg9KueqeLAjUAx6GG0ulnKPk/FIMG4W
         ltKSR8uKEyXif5dQYJAEL8i/q6XYGSRwD1i7eJUpuN3N+RxKIcBhN17piY5GWV9FIOUj
         BSl6aY0cOUeZMluJxZl8SsMjwMxJ92c8zs/5U0aK6PwTkjTN0f3WE2Dy3RBaisq9Wz1A
         M+WgivlTXLW8iNyBvsBri2BdCCN/vR/BoRZo/W9/4S/UFYP86F6r+pKEUb9voptQDTl6
         z20jT0DXVFZG8gHF+B3zCGt3gk/93kDcgcB0LksQ0ZHJuxWcTFO08ABffNMRCTpAxmoD
         K8zQ==
X-Forwarded-Encrypted: i=1; AJvYcCVWJWo2FpOq7fVqlAjNrA+Aq//sjNckrGUnSQlDazuRkoesS1x+1yEF0NYdQMmrNATG9MpzVbLkhSI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YydjE6+l83Iy67eBZdAy2EJGRRyi4T+nQxu+7gVW/E5qystcj2P
	Oi6Hx3tQEuwaOI89hJSS4YNzSAjaAwzx6t0P+QCNKKwHP247QdVy3/MA44bnh04=
X-Gm-Gg: ASbGnctkuwyoMcNYdWQtlkkdzit3KzKNGL2PB3pl8zcHUH1J4Hcv+ZBhyW4uC1AMtOT
	3CISd6Rh+M5vL9owIiQXeLSeJy2VwQVkRNPdXoLt7bW4Tw5EZJWs+ZYo3y2DB0EkODapIsHRUNX
	5aiX5GmmUNCSWc2SIFjiEepq2AV13yG30zlBzExGqNvsTLJ2IyHD1kYJI0DsbkiXuVa4Mb8Ygu+
	Ymh18XssMwWjduS/qOUKDudIX/tCURVRR8ewxtpwwp9C0pEwBFK5JYqaT32+YBZd7E=
X-Google-Smtp-Source: AGHT+IEo9mpyvl6MxMhMK3vDEIeyTCqPvEtk3ZTUCN5P4v3M5pMXiIevI2rskGgecot8tg5zTq3PXg==
X-Received: by 2002:a05:6402:50c6:b0:5d3:cfd0:8d3f with SMTP id 4fb4d7f45d1cf-5d972e4cc1amr9661346a12.24.1736501750881;
        Fri, 10 Jan 2025 01:35:50 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: qemu-devel@nongnu.org
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Kevin Wolf <kwolf@redhat.com>,
	Hanna Reitz <hreitz@redhat.com>,
	=?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= <marcandre.lureau@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	xen-devel@lists.xenproject.org,
	qemu-block@nongnu.org
Subject: [PATCH v2 2/2] xen: do not use '%ms' scanf specifier
Date: Fri, 10 Jan 2025 10:35:31 +0100
Message-ID: <20250110093531.23221-3-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250110093531.23221-1-roger.pau@citrix.com>
References: <20250110093531.23221-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The 'm' parameter used to request auto-allocation of the destination variable
is not supported on FreeBSD, and as such leads to failures to parse.

What's more, the current usage of '%ms' with xs_node_scanf() is pointless, as
it just leads to a double allocation of the same string.  Instead use
xs_node_read() to read the whole xenstore node.

Fixes: a783f8ad4ec9 ('xen: add a mechanism to automatically create XenDevice-s...')
Fixes: 9b7737469080 ('hw/xen: update Xen console to XenDevice model')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Changes since v2:
 - New version of xs_node_read().
 - Fix usage of %ms in xen-block.c

Changes since v1:
 - Introduce xs_node_read() helper.
 - Merge with errp fixes.
---
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: Anthony PERARD <anthony@xenproject.org>
Cc: Paul Durrant <paul@xen.org>
Cc: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>
Cc: Kevin Wolf <kwolf@redhat.com>
Cc: Hanna Reitz <hreitz@redhat.com>
Cc: "Marc-André Lureau" <marcandre.lureau@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: xen-devel@lists.xenproject.org
Cc: qemu-block@nongnu.org
---
 hw/block/xen-block.c     |  3 ++-
 hw/char/xen_console.c    |  6 ++++--
 hw/xen/xen-bus.c         | 14 ++++++++++++--
 include/hw/xen/xen-bus.h |  1 +
 4 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/hw/block/xen-block.c b/hw/block/xen-block.c
index 306d38927cf4..034a18b70e28 100644
--- a/hw/block/xen-block.c
+++ b/hw/block/xen-block.c
@@ -239,7 +239,8 @@ static void xen_block_connect(XenDevice *xendev, Error **errp)
         return;
     }
 
-    if (xen_device_frontend_scanf(xendev, "protocol", "%ms", &str) != 1) {
+    str = xen_device_frontend_read(xendev, "protocol");
+    if (!str) {
         /* x86 defaults to the 32-bit protocol even for 64-bit guests. */
         if (object_dynamic_cast(OBJECT(qdev_get_machine()), "x86-machine")) {
             protocol = BLKIF_PROTOCOL_X86_32;
diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
index ef0c2912efa1..989e75fef88f 100644
--- a/hw/char/xen_console.c
+++ b/hw/char/xen_console.c
@@ -550,7 +550,8 @@ static void xen_console_device_create(XenBackendInstance *backend,
         goto fail;
     }
 
-    if (xs_node_scanf(xsh, XBT_NULL, fe, "type", errp, "%ms", &type) != 1) {
+    type = xs_node_read(xsh, XBT_NULL, NULL, errp, "%s/%s", fe, "type");
+    if (!type) {
         error_prepend(errp, "failed to read console device type: ");
         goto fail;
     }
@@ -568,7 +569,8 @@ static void xen_console_device_create(XenBackendInstance *backend,
 
     snprintf(label, sizeof(label), "xencons%ld", number);
 
-    if (xs_node_scanf(xsh, XBT_NULL, fe, "output", NULL, "%ms", &output) == 1) {
+    output = xs_node_read(xsh, XBT_NULL, NULL, errp, "%s/%s", fe, "output");
+    if (output) {
         /*
          * FIXME: sure we want to support implicit
          * muxed monitors here?
diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c
index adfc4efad035..85b92cded4e2 100644
--- a/hw/xen/xen-bus.c
+++ b/hw/xen/xen-bus.c
@@ -156,8 +156,8 @@ again:
             !strcmp(key[i], "hotplug-status"))
             continue;
 
-        if (xs_node_scanf(xenbus->xsh, tid, path, key[i], NULL, "%ms",
-                          &val) == 1) {
+        val = xs_node_read(xenbus->xsh, tid, NULL, NULL, "%s/%s", path, key[i]);
+        if (val) {
             qdict_put_str(opts, key[i], val);
             free(val);
         }
@@ -650,6 +650,16 @@ int xen_device_frontend_scanf(XenDevice *xendev, const char *key,
     return rc;
 }
 
+char *xen_device_frontend_read(XenDevice *xendev, const char *key)
+{
+    XenBus *xenbus = XEN_BUS(qdev_get_parent_bus(DEVICE(xendev)));
+
+    g_assert(xenbus->xsh);
+
+    return xs_node_read(xenbus->xsh, XBT_NULL, NULL, NULL, "%s/%s",
+                        xendev->frontend_path, key);;
+}
+
 static void xen_device_frontend_set_state(XenDevice *xendev,
                                           enum xenbus_state state,
                                           bool publish)
diff --git a/include/hw/xen/xen-bus.h b/include/hw/xen/xen-bus.h
index 38d40afa3798..2adb2af83919 100644
--- a/include/hw/xen/xen-bus.h
+++ b/include/hw/xen/xen-bus.h
@@ -91,6 +91,7 @@ void xen_device_frontend_printf(XenDevice *xendev, const char *key,
 int xen_device_frontend_scanf(XenDevice *xendev, const char *key,
                               const char *fmt, ...)
     G_GNUC_SCANF(3, 4);
+char *xen_device_frontend_read(XenDevice *xendev, const char *key);
 
 void xen_device_set_max_grant_refs(XenDevice *xendev, unsigned int nr_refs,
                                    Error **errp);
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Fri Jan 10 09:56:08 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 09:56:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869375.1280833 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWBkJ-0001WS-5M; Fri, 10 Jan 2025 09:56:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869375.1280833; Fri, 10 Jan 2025 09:56:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWBkJ-0001WL-1j; Fri, 10 Jan 2025 09:56:03 +0000
Received: by outflank-mailman (input) for mailman id 869375;
 Fri, 10 Jan 2025 09:56:02 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=b62p=UC=casper.srs.infradead.org=BATV+4f8727a5892a49e75626+7810+infradead.org+dwmw2@srs-se1.protection.inumbo.net>)
 id 1tWBkH-0001Vw-Iy
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 09:56:02 +0000
Received: from casper.infradead.org (casper.infradead.org
 [2001:8b0:10b:1236::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1884247a-cf39-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 10:56:00 +0100 (CET)
Received: from 54-240-197-238.amazon.com ([54.240.197.238]
 helo=edge-cache-192.e-lhr50.amazon.com)
 by casper.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux))
 id 1tWBkE-0000000CjhZ-3eJO; Fri, 10 Jan 2025 09:55:58 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1884247a-cf39-11ef-a0df-8be0dac302b0
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:Cc:To:From:Subject:Message-ID:Sender:Reply-To:
	Content-Transfer-Encoding:Content-ID:Content-Description;
	bh=Z5Nh+2yckq762MOsfpJkW2r83TK1AAuzk8GDlzKfe1A=; b=nxVaArEN4nTxomP6ZX5WOCnLiW
	6m+s3Ss+rPKeSODhGqGyt1JpOAmVcBosftVRK7UFlS3oBc/KP6pRB8GS5QspbT8N/AclyalIFJ+w9
	XHb0JMVfqIELBlzXK6mGLuJBA/1qUevuaa4qb2uXwfNQ0njVH6KGHSyDd6+AIzT2L9q9w7FtbzKM7
	U3PctHqH8/DX1BX76dgm0SKd6NJ4ifKJZ3f3wGpc8eeIfykBNt6i6jHM2wh0C2TCg/HpzeHFaObV8
	Ibl4WStKlnlOxNcvTEhkeYSpYWvi3T6Ul5D4qk94NiyLPPNkpvFCbmZq/Dh5GiT8zBC+83zbq3Tt0
	AjgGGf3Q==;
Message-ID: <db708ce428d6047b1761d2d11fb25acc8af353a9.camel@infradead.org>
Subject: Re: [PATCH v2 2/2] xen: do not use '%ms' scanf specifier
From: David Woodhouse <dwmw2@infradead.org>
To: Roger Pau Monne <roger.pau@citrix.com>, qemu-devel@nongnu.org
Cc: Stefano Stabellini <sstabellini@kernel.org>, Anthony PERARD
	 <anthony@xenproject.org>, Paul Durrant <paul@xen.org>, "Edgar E. Iglesias"
	 <edgar.iglesias@gmail.com>, Kevin Wolf <kwolf@redhat.com>, Hanna Reitz
	 <hreitz@redhat.com>, =?ISO-8859-1?Q?Marc-Andr=E9?= Lureau
	 <marcandre.lureau@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	xen-devel@lists.xenproject.org, qemu-block@nongnu.org
Date: Fri, 10 Jan 2025 09:55:57 +0000
In-Reply-To: <20250110093531.23221-3-roger.pau@citrix.com>
References: <20250110093531.23221-1-roger.pau@citrix.com>
	 <20250110093531.23221-3-roger.pau@citrix.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-XSq/2LznYTBFSWcDCZ+A"
User-Agent: Evolution 3.52.3-0ubuntu1 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html


--=-XSq/2LznYTBFSWcDCZ+A
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2025-01-10 at 10:35 +0100, Roger Pau Monne wrote:
> The 'm' parameter used to request auto-allocation of the destination vari=
able
> is not supported on FreeBSD, and as such leads to failures to parse.
>=20
> What's more, the current usage of '%ms' with xs_node_scanf() is pointless=
, as
> it just leads to a double allocation of the same string.=C2=A0 Instead us=
e
> xs_node_read() to read the whole xenstore node.
>=20
> Fixes: a783f8ad4ec9 ('xen: add a mechanism to automatically create XenDev=
ice-s...')
> Fixes: 9b7737469080 ('hw/xen: update Xen console to XenDevice model')
> Signed-off-by: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>

Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>

Thanks.


--=-XSq/2LznYTBFSWcDCZ+A
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD9Aw
ggSOMIIDdqADAgECAhAOmiw0ECVD4cWj5DqVrT9PMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0yNDAxMzAwMDAwMDBaFw0zMTEx
MDkyMzU5NTlaMEExCzAJBgNVBAYTAkFVMRAwDgYDVQQKEwdWZXJva2V5MSAwHgYDVQQDExdWZXJv
a2V5IFNlY3VyZSBFbWFpbCBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMjvgLKj
jfhCFqxYyRiW8g3cNFAvltDbK5AzcOaR7yVzVGadr4YcCVxjKrEJOgi7WEOH8rUgCNB5cTD8N/Et
GfZI+LGqSv0YtNa54T9D1AWJy08ZKkWvfGGIXN9UFAPMJ6OLLH/UUEgFa+7KlrEvMUupDFGnnR06
aDJAwtycb8yXtILj+TvfhLFhafxroXrflspavejQkEiHjNjtHnwbZ+o43g0/yxjwnarGI3kgcak7
nnI9/8Lqpq79tLHYwLajotwLiGTB71AGN5xK+tzB+D4eN9lXayrjcszgbOv2ZCgzExQUAIt98mre
8EggKs9mwtEuKAhYBIP/0K6WsoMnQCcCAwEAAaOCAVwwggFYMBIGA1UdEwEB/wQIMAYBAf8CAQAw
HQYDVR0OBBYEFIlICOogTndrhuWByNfhjWSEf/xwMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6en
IZ3zbcgPMA4GA1UdDwEB/wQEAwIBhjAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIweQYI
KwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYIKwYB
BQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RD
QS5jcnQwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0
QXNzdXJlZElEUm9vdENBLmNybDARBgNVHSAECjAIMAYGBFUdIAAwDQYJKoZIhvcNAQELBQADggEB
ACiagCqvNVxOfSd0uYfJMiZsOEBXAKIR/kpqRp2YCfrP4Tz7fJogYN4fxNAw7iy/bPZcvpVCfe/H
/CCcp3alXL0I8M/rnEnRlv8ItY4MEF+2T/MkdXI3u1vHy3ua8SxBM8eT9LBQokHZxGUX51cE0kwa
uEOZ+PonVIOnMjuLp29kcNOVnzf8DGKiek+cT51FvGRjV6LbaxXOm2P47/aiaXrDD5O0RF5SiPo6
xD1/ClkCETyyEAE5LRJlXtx288R598koyFcwCSXijeVcRvBB1cNOLEbg7RMSw1AGq14fNe2cH1HG
W7xyduY/ydQt6gv5r21mDOQ5SaZSWC/ZRfLDuEYwggWbMIIEg6ADAgECAhAH5JEPagNRXYDiRPdl
c1vgMA0GCSqGSIb3DQEBCwUAMEExCzAJBgNVBAYTAkFVMRAwDgYDVQQKEwdWZXJva2V5MSAwHgYD
VQQDExdWZXJva2V5IFNlY3VyZSBFbWFpbCBHMjAeFw0yNDEyMzAwMDAwMDBaFw0yODAxMDQyMzU5
NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqGSIb3DQEBAQUAA4IC
DwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZeYAS/SRV6zmfXlXaZ
sNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2zkC9S7/yHDYnqegqt
w4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qGpgFdZEk2/c//ZvUN
i12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41vav1RhZJzYan4a1gU0
kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0cvnO8FM6PTqsnSbcc
0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PWPU6zfQTOMZ9uLQRR
ci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXtREF5lLXxp+CJ6KKS
blPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQrlR0gO3lBzuyPPArV
hvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7IqaAovAX0d+f1YjbmC
VsAwjhLmveFjNwIDAQABo4IBsDCCAawwHwYDVR0jBBgwFoAUiUgI6iBOd2uG5YHI1+GNZIR//HAw
HQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3bXcyQGluZnJhZGVh
ZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEBMA4GA1UdDwEB/wQE
AwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwewYDVR0fBHQwcjA3oDWgM4YxaHR0
cDovL2NybDMuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNybDA3oDWgM4YxaHR0
cDovL2NybDQuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNybDB2BggrBgEFBQcB
AQRqMGgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBABggrBgEFBQcwAoY0
aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNydDANBgkq
hkiG9w0BAQsFAAOCAQEAQXc4FPiPLRnTDvmOABEzkIumojfZAe5SlnuQoeFUfi+LsWCKiB8Uextv
iBAvboKhLuN6eG/NC6WOzOCppn4mkQxRkOdLNThwMHW0d19jrZFEKtEG/epZ/hw/DdScTuZ2m7im
8ppItAT6GXD3aPhXkXnJpC/zTs85uNSQR64cEcBFjjoQDuSsTeJ5DAWf8EMyhMuD8pcbqx5kRvyt
JPsWBQzv1Dsdv2LDPLNd/JUKhHSgr7nbUr4+aAP2PHTXGcEBh8lTeYea9p4d5k969pe0OHYMV5aL
xERqTagmSetuIwolkAuBCzA9vulg8Y49Nz2zrpUGfKGOD0FMqenYxdJHgDCCBZswggSDoAMCAQIC
EAfkkQ9qA1FdgOJE92VzW+AwDQYJKoZIhvcNAQELBQAwQTELMAkGA1UEBhMCQVUxEDAOBgNVBAoT
B1Zlcm9rZXkxIDAeBgNVBAMTF1Zlcm9rZXkgU2VjdXJlIEVtYWlsIEcyMB4XDTI0MTIzMDAwMDAw
MFoXDTI4MDEwNDIzNTk1OVowHjEcMBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzCCAiIwDQYJ
KoZIhvcNAQEBBQADggIPADCCAgoCggIBANqWLse95HW2F7FhfH9bugyT/danKmmXrbMnz5GZNAfj
Jl5gBL9JFXrOZ9eVdpmw04Tp6aDxZctFLoEDvSWKi367Q7Sg+ci+fH4KwwfQ8Pi0IpIKx2n5emEg
nbOQL1Lv/IcNiep6Cq3DiyaSpSp/RZf+CAfUNySHS8eWmhLU6jGpSD6hxTpYKye7PmrmvMWwfGEP
WoamAV1kSTb9z/9m9Q2LXa89aKmTxNwnAfD3Ohn9mtU3JukwILRMewn9QRXK7KzM+01h5hkCE4nj
W9q/VGFknNhqfhrWBTSQoE9CSVylASGrjzCgS7XmKy/BaH3/7mOOHQv5g1o3Qj/+cdKnpT0I5Qb1
nRy+c7wUzo9OqydJtxzSP4ZyHA4dELto/a3m/ay1XHcpum1pgTOLgxAfGb/T4dCkwRUstSKLMmpL
g9Y9TrN9BM4xn24tBFFyL5znGG0wQGzOVAM68RBzIQb6Fz758fjsr4yZnPbVsU1+gHEs/puNHrG0
9e1EQXmUtfGn4InoopJuU8p5VGD9S3Ikd4UoBlc7xl5yjtNlQxUeYrRlnUSmdlucCEoTX1n4UmtA
9CuVHSA7eUHO7I88CtWG9bGOU7tLgOZoSEvNqtaL/N7sQbBZK4jZ4Rr/zNTQg1SwYjjLB7u96lDP
sipoCi8BfR35/ViNuYJWwDCOEua94WM3AgMBAAGjggGwMIIBrDAfBgNVHSMEGDAWgBSJSAjqIE53
a4blgcjX4Y1khH/8cDAdBgNVHQ4EFgQUXGIam3Bs59Y60yTmWgfDu6pZQ6cwMAYDVR0RBCkwJ4ET
ZHdtdzJAaW5mcmFkZWFkLm9yZ4EQZGF2aWRAd29vZGhvdS5zZTAUBgNVHSAEDTALMAkGB2eBDAEF
AQEwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDB7BgNVHR8E
dDByMDegNaAzhjFodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVtYWlsRzIu
Y3JsMDegNaAzhjFodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVtYWlsRzIu
Y3JsMHYGCCsGAQUFBwEBBGowaDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29t
MEAGCCsGAQUFBzAChjRodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVt
YWlsRzIuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQBBdzgU+I8tGdMO+Y4AETOQi6aiN9kB7lKWe5Ch
4VR+L4uxYIqIHxR7G2+IEC9ugqEu43p4b80LpY7M4KmmfiaRDFGQ50s1OHAwdbR3X2OtkUQq0Qb9
6ln+HD8N1JxO5nabuKbymki0BPoZcPdo+FeRecmkL/NOzzm41JBHrhwRwEWOOhAO5KxN4nkMBZ/w
QzKEy4PylxurHmRG/K0k+xYFDO/UOx2/YsM8s138lQqEdKCvudtSvj5oA/Y8dNcZwQGHyVN5h5r2
nh3mT3r2l7Q4dgxXlovERGpNqCZJ624jCiWQC4ELMD2+6WDxjj03PbOulQZ8oY4PQUyp6djF0keA
MYIDuzCCA7cCAQEwVTBBMQswCQYDVQQGEwJBVTEQMA4GA1UEChMHVmVyb2tleTEgMB4GA1UEAxMX
VmVyb2tleSBTZWN1cmUgRW1haWwgRzICEAfkkQ9qA1FdgOJE92VzW+AwDQYJYIZIAWUDBAIBBQCg
ggE3MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTI1MDExMDA5NTU1
N1owLwYJKoZIhvcNAQkEMSIEIN3MALgsY/OyhtuLPyN/iAmYvwomMt4RuktBFQ2DvTsDMGQGCSsG
AQQBgjcQBDFXMFUwQTELMAkGA1UEBhMCQVUxEDAOBgNVBAoTB1Zlcm9rZXkxIDAeBgNVBAMTF1Zl
cm9rZXkgU2VjdXJlIEVtYWlsIEcyAhAH5JEPagNRXYDiRPdlc1vgMGYGCyqGSIb3DQEJEAILMVeg
VTBBMQswCQYDVQQGEwJBVTEQMA4GA1UEChMHVmVyb2tleTEgMB4GA1UEAxMXVmVyb2tleSBTZWN1
cmUgRW1haWwgRzICEAfkkQ9qA1FdgOJE92VzW+AwDQYJKoZIhvcNAQEBBQAEggIAxp99xYgfx6Hh
IyvhBd0HWKLUqAJ75hYBt+BhTQjg+lGGCA3KbKTPAmRN7KS/yW1jyGDxcF9NUuYE+QVdKTfs9tgD
Es1t4aHT57mQzbCIX1dZkRlvLJLXLIZMcqyjWRjsVwmUOudDXI9I0KFCHuFbZ4txAQOW0vhQgEpZ
bvG92IaknYSPf1f2nPQNfB5FPZc7G5BksjtqM6QrUURChml8Kf7SrW4fhWA6vTkQLyNZLvHWkZfn
YTpUmiwFQR2bjCKrceHVQl8XVdSD2EuOxq8PU0/c43fchtMiZBukwfLs9Mv+3jvdzdlr2/G1t8gX
nzDTbwSbCEOVthf0cAq7aCLMMIe/tp/NiDuHXXti0+LTHjD4kE0K8y8/FiRszqvME+FSGYtQen73
X47qTXzsDDbCqDOimgUVb1lqUoOrL4QD+gE7Q4aNZXNSBy9382LFyncmhILPs4dj48D050k9T9vE
lejIAGunet2IjRTjRAyJQvN+S/Ghlxg9EkjsCf5dX7eMwh10ezdjZtgpFdyynBENr6QbdlM1txBx
r2deapg8I6bav0GLSS3uOJsNfkmz8VJAqyYt/h53mele+NskZu54CLlHmmMV/eaalSMFHyAqZIT+
w5yWXONcZY3uBFToySH/MGaRMrA3valV1MkqoRNRJJn9S64fjPCeJ9oZ6JbBHoAAAAAAAAA=


--=-XSq/2LznYTBFSWcDCZ+A--


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 10:01:24 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 10:01:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869387.1280842 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWBpQ-0003D8-V3; Fri, 10 Jan 2025 10:01:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869387.1280842; Fri, 10 Jan 2025 10:01:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWBpQ-0003D1-ON; Fri, 10 Jan 2025 10:01:20 +0000
Received: by outflank-mailman (input) for mailman id 869387;
 Fri, 10 Jan 2025 10:01:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=r1rC=UC=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tWBpP-0003Ct-3R
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 10:01:19 +0000
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com
 [2a00:1450:4864:20::429])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d52b9f3b-cf39-11ef-99a4-01e77a169b0f;
 Fri, 10 Jan 2025 11:01:17 +0100 (CET)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-385ef8b64b3so1646134f8f.0
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 02:01:17 -0800 (PST)
Received: from [192.168.1.74] (88-187-86-199.subs.proxad.net. [88.187.86.199])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436e9dc895esm46937395e9.13.2025.01.10.02.01.15
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 10 Jan 2025 02:01:15 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: d52b9f3b-cf39-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1736503276; x=1737108076; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=YqNXwsBBjRVrnRTVKDJZnSkj54PnJGjlJvQf7Lwyxzo=;
        b=ldCQHhC9pZq1Xz/7KD7/tpEuMF82HVH2WoZxnzH7Lrfbd0tugArHvHdKYNOGGUk68g
         i4JGYqowgV1zUwJJZrRPHyh8/HwUuQM9LIKFyJqhLPY98wmx1fjmY7ttSwOutn/3WDZC
         aofygu6lJ6J27xYtmzfpuvmct9PbAeoAFPHp5w/TwWODTi7A61Zdgt7nVsNLfbOl6ons
         H1xpR9AUH0XOtjJMBWmbqpfccQJLHhkWDf8+Y03HMLgbjU/ciFlToobsP+uRhbRm5mTS
         sz2mxeiEb+qWj54xl82igOAoFgX77mi001TxKsmn4rGH8vpW5Z4un5F/v4sA6VQ5MIta
         csyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736503276; x=1737108076;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=YqNXwsBBjRVrnRTVKDJZnSkj54PnJGjlJvQf7Lwyxzo=;
        b=jV1IXNoPbR2oszRhF34p9AuzbweGa/mJBkfX3krkvYlRH7zKM1Ppt7bjRSX0DyxoMu
         0qcIdtR16YSkwjk2OBWQowDXCqiHXTyoSHKCkVUT15/F08ru3M3HFnIilAN5BcJyLKa1
         MTtOTu+rPbwH4yGcgfHZzQz86hGd0HJNFZL+rXkBJ+EedJvKBjegrPYrpYMkltHT8DUZ
         JNncGvwpkDGULk9sC0eT30EStuPxZBRTdwCGYVTjq7i6YMQ/RfQF76ek7uneZsy8Bggx
         I27gDBiZRKF/RzZB79S9ZJo3Foge2g0cTypXuVnXtLU33+fohltajOMYt2jgT8IUNrYs
         /JHA==
X-Forwarded-Encrypted: i=1; AJvYcCXPfsb5+wUrQEJ8fdmLR78T37o1mtqCtlafejh7+QMQFcWZIf+uqaeJlCMUi5pHnMhzKrtgfrAzwqY=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw5KO7bBnEuiheBWFv1yoqHh2lRVLS64msgs3a2NRNfyuQiGJ8P
	3ToMsxezL/b6MxLYUOgySa7WuoSLf/HZuv7s+Wy9cVLbuSl7l6t1ycCU43GEixM=
X-Gm-Gg: ASbGnctwX5ep87JiLMAKCkZYJnvrn2pCL5pJH63z8cB3VltHWPDyIEc1KPR13yuNqRF
	9YlxUxU6VJQ9qcW1HKmvtFlOxOvYi/LuIbw+DlpEjAUkO+rzyTq1niKfMdhydCwh/N0Chv1u/P+
	5e+B+TYMpiMlrQNCaVbH5MHywZNUK3P+ufxdNat557SW+Q3N8rnUcdObSOsXOSjI3srbJbnkFIZ
	j2Dt2DYY0HU0A7eCa4W//anIepfLZYtzmn/sxMqirnjyUolRmEvuKLvgk0v+Ghau2wlb4+9sTrw
	2QKo0KJPWp0ctq9lOGvQPw==
X-Google-Smtp-Source: AGHT+IHXWN9Z9dykOvTV6ouEKFxaJmZvNZaGQ9zNkagbHLSAGDh3mtW0ErVxn4BZFrdXHOgFsXu8Zg==
X-Received: by 2002:a05:6000:481e:b0:386:37af:dd9a with SMTP id ffacd0b85a97d-38a872f534dmr9374207f8f.35.1736503276359;
        Fri, 10 Jan 2025 02:01:16 -0800 (PST)
Message-ID: <f4438a42-d8d8-4a46-b89e-d7858da35db5@linaro.org>
Date: Fri, 10 Jan 2025 11:01:14 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/2] hw/xen: Add xs_node_read() helper function
To: Roger Pau Monne <roger.pau@citrix.com>, qemu-devel@nongnu.org
Cc: David Woodhouse <dwmw@amazon.co.uk>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony@xenproject.org>, Paul Durrant <paul@xen.org>,
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
 xen-devel@lists.xenproject.org
References: <20250110093531.23221-1-roger.pau@citrix.com>
 <20250110093531.23221-2-roger.pau@citrix.com>
Content-Language: en-US
From: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= <philmd@linaro.org>
In-Reply-To: <20250110093531.23221-2-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 10/1/25 10:35, Roger Pau Monne wrote:
> From: David Woodhouse <dwmw@amazon.co.uk>
> 
> This returns the full contents of the node, having created the node path
> from the printf-style format string provided in its arguments.
> 
> This will save various callers from having to do so for themselves (and
> from using xs_node_scanf() with the non-portable %ms format string.
> 
> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
> [remove double newline and constify trace parameters]
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> ---
> Cc: Stefano Stabellini <sstabellini@kernel.org>
> Cc: Anthony PERARD <anthony@xenproject.org>
> Cc: Paul Durrant <paul@xen.org>
> Cc: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>
> Cc: xen-devel@lists.xenproject.org
> ---
>   hw/xen/trace-events             |  1 +
>   hw/xen/xen-bus-helper.c         | 22 ++++++++++++++++++++++
>   include/hw/xen/xen-bus-helper.h |  4 ++++
>   3 files changed, 27 insertions(+)
> 
> diff --git a/hw/xen/trace-events b/hw/xen/trace-events
> index a07fe41c6d3b..461dee7b239f 100644
> --- a/hw/xen/trace-events
> +++ b/hw/xen/trace-events
> @@ -39,6 +39,7 @@ xs_node_create(const char *node) "%s"
>   xs_node_destroy(const char *node) "%s"
>   xs_node_vprintf(char *path, char *value) "%s %s"
>   xs_node_vscanf(char *path, char *value) "%s %s"
> +xs_node_read(const char *path, const char *value) "%s %s"
>   xs_node_watch(char *path) "%s"
>   xs_node_unwatch(char *path) "%s"
>   
> diff --git a/hw/xen/xen-bus-helper.c b/hw/xen/xen-bus-helper.c
> index b2b2cc9c5d5e..0fba7946c55e 100644
> --- a/hw/xen/xen-bus-helper.c
> +++ b/hw/xen/xen-bus-helper.c
> @@ -142,6 +142,28 @@ int xs_node_scanf(struct qemu_xs_handle *h,  xs_transaction_t tid,
>       return rc;
>   }
>   
> +char *xs_node_read(struct qemu_xs_handle *h, xs_transaction_t tid,
> +                   unsigned int *len, Error **errp,
> +                   const char *node_fmt, ...)
> +{
> +    char *path, *value;

Alternatively use g_autofree.

> +    va_list ap;
> +
> +    va_start(ap, node_fmt);
> +    path = g_strdup_vprintf(node_fmt, ap);
> +    va_end(ap);
> +
> +    value = qemu_xen_xs_read(h, tid, path, len);
> +    trace_xs_node_read(path, value);
> +    if (!value) {
> +        error_setg_errno(errp, errno, "failed to read from '%s'", path);
> +    }
> +
> +    g_free(path);
> +
> +    return value;
> +}
> +
>   struct qemu_xs_watch *xs_node_watch(struct qemu_xs_handle *h, const char *node,
>                                       const char *key, xs_watch_fn fn,
>                                       void *opaque, Error **errp)
> diff --git a/include/hw/xen/xen-bus-helper.h b/include/hw/xen/xen-bus-helper.h
> index d8dcc2f0107d..6478d25be5e6 100644
> --- a/include/hw/xen/xen-bus-helper.h
> +++ b/include/hw/xen/xen-bus-helper.h
> @@ -37,6 +37,10 @@ int xs_node_scanf(struct qemu_xs_handle *h,  xs_transaction_t tid,
>                     const char *node, const char *key, Error **errp,
>                     const char *fmt, ...)
>       G_GNUC_SCANF(6, 7);

While I suppose the same comment still applies here ("/* Read from
node/key unless node is empty, in which case read from key */"), it
would be nice to precise the returned value.

> +char *xs_node_read(struct qemu_xs_handle *h, xs_transaction_t tid,
> +                   unsigned int *len, Error **errp,
> +                   const char *node_fmt, ...)
> +    G_GNUC_PRINTF(5, 6);
>   
>   /* Watch node/key unless node is empty, in which case watch key */
>   struct qemu_xs_watch *xs_node_watch(struct qemu_xs_handle *h, const char *node,

Mostly nitpicking, otherwise patch LGTM.


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 10:03:02 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 10:03:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869396.1280853 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWBr2-0003rU-A5; Fri, 10 Jan 2025 10:03:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869396.1280853; Fri, 10 Jan 2025 10:03:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWBr2-0003rN-7H; Fri, 10 Jan 2025 10:03:00 +0000
Received: by outflank-mailman (input) for mailman id 869396;
 Fri, 10 Jan 2025 10:02: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
 <SRS0=b62p=UC=casper.srs.infradead.org=BATV+4f8727a5892a49e75626+7810+infradead.org+dwmw2@srs-se1.protection.inumbo.net>)
 id 1tWBr1-0003pZ-Ht
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 10:02:59 +0000
Received: from casper.infradead.org (casper.infradead.org
 [2001:8b0:10b:1236::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0fd6a2e6-cf3a-11ef-99a4-01e77a169b0f;
 Fri, 10 Jan 2025 11:02:55 +0100 (CET)
Received: from 54-240-197-238.amazon.com ([54.240.197.238]
 helo=edge-cache-192.e-lhr50.amazon.com)
 by casper.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux))
 id 1tWBqw-0000000Cl6s-1QqK; Fri, 10 Jan 2025 10:02:54 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 0fd6a2e6-cf3a-11ef-99a4-01e77a169b0f
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:Cc:To:From:Subject:Message-ID:Sender:Reply-To:
	Content-Transfer-Encoding:Content-ID:Content-Description;
	bh=Lzl/fCbT6sRA6c+87JMLUaCMOyZ67nK6sKKgQt6FcjI=; b=ZEr2TWu+MNSbDuhHWLDqGdRDnT
	dGwaRgjIeC6mGufzFnE0MEHrFZS/zGuf3eBTzL/gHfDadtY4upyrx9C70QN6uOv/XuaIsea2Wy+qu
	u0oXIZcuVlnIybYY8wghj4nBIKnr0KIwqL2DTx9fsTHJnwtGq6VuXv/5NkkVkuODfBd3/JxN60+EX
	qi6tBZNzzSLYSGL/viZY0ApPySVjPVtaQcEENTBC9JgnEmd3aWiUTuKtxcd0HtIv0mSyXIO1GY/Bh
	Wz+h09rRolKrpqYQuR0pna/iKKgUWDSFCuczswD9kGIAqySAZ4V689x2XwulmQqOyTzSOuZY/2T5o
	gbPfPj3w==;
Message-ID: <fc9b22c55eaaa79a3ef9829c270bc4b4e93be7a0.camel@infradead.org>
Subject: Re: [PATCH v2 0/2] xen: error handling and FreeBSD compatibility
 fixes
From: David Woodhouse <dwmw2@infradead.org>
To: Roger Pau Monne <roger.pau@citrix.com>, qemu-devel@nongnu.org
Cc: Stefano Stabellini <sstabellini@kernel.org>, Anthony PERARD
	 <anthony@xenproject.org>, Paul Durrant <paul@xen.org>, "Edgar E. Iglesias"
	 <edgar.iglesias@gmail.com>, Kevin Wolf <kwolf@redhat.com>, Hanna Reitz
	 <hreitz@redhat.com>, =?ISO-8859-1?Q?Marc-Andr=E9?= Lureau
	 <marcandre.lureau@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	xen-devel@lists.xenproject.org, qemu-block@nongnu.org
Date: Fri, 10 Jan 2025 10:02:53 +0000
In-Reply-To: <20250110093531.23221-1-roger.pau@citrix.com>
References: <20250110093531.23221-1-roger.pau@citrix.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-se17uZz0Wpb6VPQVNNY0"
User-Agent: Evolution 3.52.3-0ubuntu1 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html


--=-se17uZz0Wpb6VPQVNNY0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2025-01-10 at 10:35 +0100, Roger Pau Monne wrote:
> Hello,
>=20
> First patch from David introduces a new helper to fetch xenstore nodes,
> while second patch removes the usage of scanf related functions with the
> "%ms" format specifier, as it's not supported by the FreeBSD scanf libc
> implementation.
>=20
> Thanks, Roger.

Thanks. I've got a handful of non-bugfix cleanups to use the new
xs_node_read in my tree at
https://git.infradead.org/users/dwmw2/qemu.git/shortlog/refs/heads/xs_node_=
read

David Woodhouse (4):
      hw/xen: Use xs_node_read() from xs_node_vscanf()
      hw/xen: Use xs_node_read() from xen_console_get_name()
      hw/xen: Use xs_node_read() from xen_netdev_get_name()
      hw/xen: Use xs_node_read() from xenstore_read_str() instead of open-c=
oding it

I'm slightly dubious about the last one; xen_pvdev.c didn't previously
use anything from xen-bus-helper.c and even hardcodes zero for
XBT_NULL. And I look at the way it deliberately reallocates the string,
and wonder if we should be doing that in qemu_xen_xs_read() for the
true Xen case. And does it even matter anywhere except Windows?



--=-se17uZz0Wpb6VPQVNNY0
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD9Aw
ggSOMIIDdqADAgECAhAOmiw0ECVD4cWj5DqVrT9PMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0yNDAxMzAwMDAwMDBaFw0zMTEx
MDkyMzU5NTlaMEExCzAJBgNVBAYTAkFVMRAwDgYDVQQKEwdWZXJva2V5MSAwHgYDVQQDExdWZXJv
a2V5IFNlY3VyZSBFbWFpbCBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMjvgLKj
jfhCFqxYyRiW8g3cNFAvltDbK5AzcOaR7yVzVGadr4YcCVxjKrEJOgi7WEOH8rUgCNB5cTD8N/Et
GfZI+LGqSv0YtNa54T9D1AWJy08ZKkWvfGGIXN9UFAPMJ6OLLH/UUEgFa+7KlrEvMUupDFGnnR06
aDJAwtycb8yXtILj+TvfhLFhafxroXrflspavejQkEiHjNjtHnwbZ+o43g0/yxjwnarGI3kgcak7
nnI9/8Lqpq79tLHYwLajotwLiGTB71AGN5xK+tzB+D4eN9lXayrjcszgbOv2ZCgzExQUAIt98mre
8EggKs9mwtEuKAhYBIP/0K6WsoMnQCcCAwEAAaOCAVwwggFYMBIGA1UdEwEB/wQIMAYBAf8CAQAw
HQYDVR0OBBYEFIlICOogTndrhuWByNfhjWSEf/xwMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6en
IZ3zbcgPMA4GA1UdDwEB/wQEAwIBhjAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIweQYI
KwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYIKwYB
BQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RD
QS5jcnQwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0
QXNzdXJlZElEUm9vdENBLmNybDARBgNVHSAECjAIMAYGBFUdIAAwDQYJKoZIhvcNAQELBQADggEB
ACiagCqvNVxOfSd0uYfJMiZsOEBXAKIR/kpqRp2YCfrP4Tz7fJogYN4fxNAw7iy/bPZcvpVCfe/H
/CCcp3alXL0I8M/rnEnRlv8ItY4MEF+2T/MkdXI3u1vHy3ua8SxBM8eT9LBQokHZxGUX51cE0kwa
uEOZ+PonVIOnMjuLp29kcNOVnzf8DGKiek+cT51FvGRjV6LbaxXOm2P47/aiaXrDD5O0RF5SiPo6
xD1/ClkCETyyEAE5LRJlXtx288R598koyFcwCSXijeVcRvBB1cNOLEbg7RMSw1AGq14fNe2cH1HG
W7xyduY/ydQt6gv5r21mDOQ5SaZSWC/ZRfLDuEYwggWbMIIEg6ADAgECAhAH5JEPagNRXYDiRPdl
c1vgMA0GCSqGSIb3DQEBCwUAMEExCzAJBgNVBAYTAkFVMRAwDgYDVQQKEwdWZXJva2V5MSAwHgYD
VQQDExdWZXJva2V5IFNlY3VyZSBFbWFpbCBHMjAeFw0yNDEyMzAwMDAwMDBaFw0yODAxMDQyMzU5
NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqGSIb3DQEBAQUAA4IC
DwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZeYAS/SRV6zmfXlXaZ
sNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2zkC9S7/yHDYnqegqt
w4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qGpgFdZEk2/c//ZvUN
i12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41vav1RhZJzYan4a1gU0
kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0cvnO8FM6PTqsnSbcc
0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PWPU6zfQTOMZ9uLQRR
ci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXtREF5lLXxp+CJ6KKS
blPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQrlR0gO3lBzuyPPArV
hvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7IqaAovAX0d+f1YjbmC
VsAwjhLmveFjNwIDAQABo4IBsDCCAawwHwYDVR0jBBgwFoAUiUgI6iBOd2uG5YHI1+GNZIR//HAw
HQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3bXcyQGluZnJhZGVh
ZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEBMA4GA1UdDwEB/wQE
AwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwewYDVR0fBHQwcjA3oDWgM4YxaHR0
cDovL2NybDMuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNybDA3oDWgM4YxaHR0
cDovL2NybDQuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNybDB2BggrBgEFBQcB
AQRqMGgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBABggrBgEFBQcwAoY0
aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNydDANBgkq
hkiG9w0BAQsFAAOCAQEAQXc4FPiPLRnTDvmOABEzkIumojfZAe5SlnuQoeFUfi+LsWCKiB8Uextv
iBAvboKhLuN6eG/NC6WOzOCppn4mkQxRkOdLNThwMHW0d19jrZFEKtEG/epZ/hw/DdScTuZ2m7im
8ppItAT6GXD3aPhXkXnJpC/zTs85uNSQR64cEcBFjjoQDuSsTeJ5DAWf8EMyhMuD8pcbqx5kRvyt
JPsWBQzv1Dsdv2LDPLNd/JUKhHSgr7nbUr4+aAP2PHTXGcEBh8lTeYea9p4d5k969pe0OHYMV5aL
xERqTagmSetuIwolkAuBCzA9vulg8Y49Nz2zrpUGfKGOD0FMqenYxdJHgDCCBZswggSDoAMCAQIC
EAfkkQ9qA1FdgOJE92VzW+AwDQYJKoZIhvcNAQELBQAwQTELMAkGA1UEBhMCQVUxEDAOBgNVBAoT
B1Zlcm9rZXkxIDAeBgNVBAMTF1Zlcm9rZXkgU2VjdXJlIEVtYWlsIEcyMB4XDTI0MTIzMDAwMDAw
MFoXDTI4MDEwNDIzNTk1OVowHjEcMBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzCCAiIwDQYJ
KoZIhvcNAQEBBQADggIPADCCAgoCggIBANqWLse95HW2F7FhfH9bugyT/danKmmXrbMnz5GZNAfj
Jl5gBL9JFXrOZ9eVdpmw04Tp6aDxZctFLoEDvSWKi367Q7Sg+ci+fH4KwwfQ8Pi0IpIKx2n5emEg
nbOQL1Lv/IcNiep6Cq3DiyaSpSp/RZf+CAfUNySHS8eWmhLU6jGpSD6hxTpYKye7PmrmvMWwfGEP
WoamAV1kSTb9z/9m9Q2LXa89aKmTxNwnAfD3Ohn9mtU3JukwILRMewn9QRXK7KzM+01h5hkCE4nj
W9q/VGFknNhqfhrWBTSQoE9CSVylASGrjzCgS7XmKy/BaH3/7mOOHQv5g1o3Qj/+cdKnpT0I5Qb1
nRy+c7wUzo9OqydJtxzSP4ZyHA4dELto/a3m/ay1XHcpum1pgTOLgxAfGb/T4dCkwRUstSKLMmpL
g9Y9TrN9BM4xn24tBFFyL5znGG0wQGzOVAM68RBzIQb6Fz758fjsr4yZnPbVsU1+gHEs/puNHrG0
9e1EQXmUtfGn4InoopJuU8p5VGD9S3Ikd4UoBlc7xl5yjtNlQxUeYrRlnUSmdlucCEoTX1n4UmtA
9CuVHSA7eUHO7I88CtWG9bGOU7tLgOZoSEvNqtaL/N7sQbBZK4jZ4Rr/zNTQg1SwYjjLB7u96lDP
sipoCi8BfR35/ViNuYJWwDCOEua94WM3AgMBAAGjggGwMIIBrDAfBgNVHSMEGDAWgBSJSAjqIE53
a4blgcjX4Y1khH/8cDAdBgNVHQ4EFgQUXGIam3Bs59Y60yTmWgfDu6pZQ6cwMAYDVR0RBCkwJ4ET
ZHdtdzJAaW5mcmFkZWFkLm9yZ4EQZGF2aWRAd29vZGhvdS5zZTAUBgNVHSAEDTALMAkGB2eBDAEF
AQEwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDB7BgNVHR8E
dDByMDegNaAzhjFodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVtYWlsRzIu
Y3JsMDegNaAzhjFodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVtYWlsRzIu
Y3JsMHYGCCsGAQUFBwEBBGowaDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29t
MEAGCCsGAQUFBzAChjRodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVt
YWlsRzIuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQBBdzgU+I8tGdMO+Y4AETOQi6aiN9kB7lKWe5Ch
4VR+L4uxYIqIHxR7G2+IEC9ugqEu43p4b80LpY7M4KmmfiaRDFGQ50s1OHAwdbR3X2OtkUQq0Qb9
6ln+HD8N1JxO5nabuKbymki0BPoZcPdo+FeRecmkL/NOzzm41JBHrhwRwEWOOhAO5KxN4nkMBZ/w
QzKEy4PylxurHmRG/K0k+xYFDO/UOx2/YsM8s138lQqEdKCvudtSvj5oA/Y8dNcZwQGHyVN5h5r2
nh3mT3r2l7Q4dgxXlovERGpNqCZJ624jCiWQC4ELMD2+6WDxjj03PbOulQZ8oY4PQUyp6djF0keA
MYIDuzCCA7cCAQEwVTBBMQswCQYDVQQGEwJBVTEQMA4GA1UEChMHVmVyb2tleTEgMB4GA1UEAxMX
VmVyb2tleSBTZWN1cmUgRW1haWwgRzICEAfkkQ9qA1FdgOJE92VzW+AwDQYJYIZIAWUDBAIBBQCg
ggE3MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTI1MDExMDEwMDI1
M1owLwYJKoZIhvcNAQkEMSIEIMMbX3zhGrZOKaYrNrEZZhAey8NTKv7N2bYeEhYfriCiMGQGCSsG
AQQBgjcQBDFXMFUwQTELMAkGA1UEBhMCQVUxEDAOBgNVBAoTB1Zlcm9rZXkxIDAeBgNVBAMTF1Zl
cm9rZXkgU2VjdXJlIEVtYWlsIEcyAhAH5JEPagNRXYDiRPdlc1vgMGYGCyqGSIb3DQEJEAILMVeg
VTBBMQswCQYDVQQGEwJBVTEQMA4GA1UEChMHVmVyb2tleTEgMB4GA1UEAxMXVmVyb2tleSBTZWN1
cmUgRW1haWwgRzICEAfkkQ9qA1FdgOJE92VzW+AwDQYJKoZIhvcNAQEBBQAEggIARNSC6KHCvaaC
7uXvJJETYGrn3g9pI45wVXuBr3JCzWOkoNarS5YFS7ghZlZAik6EPUa3RhhuLDmJNU8ms/4xPvCD
MFuaFBQ6GiVMEcIBDCE6UeGJeF64ZTLyIKl2tFPcd2SQyIUcdZd1sZAv3SAgOSlrRksid9N+i8Hd
o8L9UWeSUjqACakySUiYrriWrHooXv9L6FN4bAUZkNblC5F9V+RkdHZpN/jYG9v8vZoPU9l2rNr4
49V+Lz72URpTj3MM0KpqQ88kRnXENGF1vXWFqQYcxdB2Epiz/CWa69EI7H0ff0d2JQMXQdDFlBwQ
E+tjYvHJevM9tq/JECeESi+Vl+mozrbK0UvKIROful0kP42ZxeBt5VYinIUZghujTD+DEp75jvo/
ufU+X+Pk6FgMvHDeu7uYcLUlQziIUrs6JXpw9goCGNWjitsi1yHDmaSiFm6rQv/So81ucj7ZkBmh
acyYZr+zJSE5EEoADGZ0nn1MToy1iqk8sXzvwLdCznKJMm9WTVICDpobmZ67tiDH07izWWFV24AS
ZbptQA7xOgUwe7rB5dTr6dCTyevcvI8QLgh461+m6JGTPYQdPTcehT/bGGlBiWU7yiTsF1aQv6Qq
7jT24BhknT/iPLN2jqbcY4gzM61jNzmkR7j0E6zDcLjGwVvb9IzjL7Mw2gOkTCoAAAAAAAA=


--=-se17uZz0Wpb6VPQVNNY0--


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 10:03:32 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 10:03:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869403.1280867 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWBrY-0004RE-Q9; Fri, 10 Jan 2025 10:03:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869403.1280867; Fri, 10 Jan 2025 10:03:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWBrY-0004Q8-M4; Fri, 10 Jan 2025 10:03:32 +0000
Received: by outflank-mailman (input) for mailman id 869403;
 Fri, 10 Jan 2025 10:03:31 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=/ds0=UC=desiato.srs.infradead.org=BATV+4d36ee5d223a5d86d66e+7810+infradead.org+dwmw2@srs-se1.protection.inumbo.net>)
 id 1tWBrW-0004A1-Pf
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 10:03:31 +0000
Received: from desiato.infradead.org (desiato.infradead.org
 [2001:8b0:10b:1:d65d:64ff:fe57:4e05])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2491f3eb-cf3a-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 11:03:30 +0100 (CET)
Received: from [2001:8b0:10b:1::ebe] (helo=i7.infradead.org)
 by desiato.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux))
 id 1tWBrT-00000009jwm-47GC; Fri, 10 Jan 2025 10:03:28 +0000
Received: from dwoodhou by i7.infradead.org with local (Exim 4.98 #2 (Red Hat
 Linux)) id 1tWBrS-00000002D8J-41Ad; Fri, 10 Jan 2025 10:03:26 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
X-Inumbo-ID: 2491f3eb-cf3a-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding:
	MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:
	Reply-To:Content-Type:Content-ID:Content-Description;
	bh=X9zPJARrpqAjJWmqv/5Ourv8FRQelInhZmfRvKOuCvE=; b=p5CUhAGkiy/Ab65rEyWrr+bC/e
	R4Ww/x6oWNsGbvYIgqh5v++zG7YpiB1LauJCN+l1yK41FHft1fOgE827KN8mn5K86vqq5SjIeuXCd
	bgp7f5nxwT8i+ZnrXi0Y5fEz8FVeKd//w+GOwvb8LQ8dabPvo8a3iIRfpsbIv9PfkJo+S7BvIHFrj
	qJN/KjsRxXLXyaKzrdaOjcZHSkeVLD8Hv372ooE7E/nLi1VrLMX2xwcbIXQYZqsMC/I9QsNnJgAxO
	nOSa7L3UXpZTqvNbm6BCBHR4iiTfk9fWDDIqALBv4mtUQDVA24+8hsBJxzDunP4dqviW7pntf1GuT
	3xsgmF0Q==;
From: David Woodhouse <dwmw2@infradead.org>
To: Roger Pau Monne <roger.pau@citrix.com>,
	qemu-devel@nongnu.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E . Iglesias" <edgar.iglesias@gmail.com>,
	Kevin Wolf <kwolf@redhat.com>,
	Hanna Reitz <hreitz@redhat.com>,
	=?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= <marcandre.lureau@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	xen-devel@lists.xenproject.org,
	qemu-block@nongnu.org
Subject: [PATCH 4/4] hw/xen: Use xs_node_read() from xenstore_read_str() instead of open-coding it
Date: Fri, 10 Jan 2025 10:03:26 +0000
Message-ID: <20250110100326.527101-4-dwmw2@infradead.org>
X-Mailer: git-send-email 2.47.0
In-Reply-To: <20250110100326.527101-1-dwmw2@infradead.org>
References: <fc9b22c55eaaa79a3ef9829c270bc4b4e93be7a0.camel@infradead.org>
 <20250110100326.527101-1-dwmw2@infradead.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: David Woodhouse <dwmw2@infradead.org>
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by desiato.infradead.org. See http://www.infradead.org/rpr.html

From: David Woodhouse <dwmw@amazon.co.uk>

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
 hw/xen/xen_pvdev.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/hw/xen/xen_pvdev.c b/hw/xen/xen_pvdev.c
index c5ad71e8dc..c9143ba259 100644
--- a/hw/xen/xen_pvdev.c
+++ b/hw/xen/xen_pvdev.c
@@ -22,6 +22,7 @@
 #include "qemu/main-loop.h"
 #include "hw/qdev-core.h"
 #include "hw/xen/xen-legacy-backend.h"
+#include "hw/xen/xen-bus-helper.h"
 #include "hw/xen/xen_pvdev.h"
 
 /* private */
@@ -81,12 +82,9 @@ int xenstore_write_str(const char *base, const char *node, const char *val)
 
 char *xenstore_read_str(const char *base, const char *node)
 {
-    char abspath[XEN_BUFSIZE];
-    unsigned int len;
     char *str, *ret = NULL;
 
-    snprintf(abspath, sizeof(abspath), "%s/%s", base, node);
-    str = qemu_xen_xs_read(xenstore, 0, abspath, &len);
+    str = xs_node_read(xenstore, 0, NULL, NULL, "%s/%s", base, node);
     if (str != NULL) {
         /* move to qemu-allocated memory to make sure
          * callers can safely g_free() stuff. */
-- 
2.47.0



From xen-devel-bounces@lists.xenproject.org Fri Jan 10 10:03:32 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 10:03:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869402.1280863 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWBrY-0004Ox-JR; Fri, 10 Jan 2025 10:03:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869402.1280863; Fri, 10 Jan 2025 10:03:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWBrY-0004Oq-Fm; Fri, 10 Jan 2025 10:03:32 +0000
Received: by outflank-mailman (input) for mailman id 869402;
 Fri, 10 Jan 2025 10:03:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=b62p=UC=casper.srs.infradead.org=BATV+4f8727a5892a49e75626+7810+infradead.org+dwmw2@srs-se1.protection.inumbo.net>)
 id 1tWBrX-0003pZ-1i
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 10:03:31 +0000
Received: from casper.infradead.org (casper.infradead.org
 [2001:8b0:10b:1236::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 22f6a86e-cf3a-11ef-99a4-01e77a169b0f;
 Fri, 10 Jan 2025 11:03:27 +0100 (CET)
Received: from [2001:8b0:10b:1::ebe] (helo=i7.infradead.org)
 by casper.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux))
 id 1tWBrT-0000000ClKG-0bv4; Fri, 10 Jan 2025 10:03:27 +0000
Received: from dwoodhou by i7.infradead.org with local (Exim 4.98 #2 (Red Hat
 Linux)) id 1tWBrS-00000002D8B-3mfx; Fri, 10 Jan 2025 10:03:26 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
X-Inumbo-ID: 22f6a86e-cf3a-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=Sender:Content-Transfer-Encoding:
	MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:
	Reply-To:Content-Type:Content-ID:Content-Description;
	bh=/Z+SKExdFg0yRN3g9ep614CHpa/f9VObKzKbkTp0cz4=; b=JixCnxZX+BaMP2NnJM4sbWF8Bo
	ko/UtMZH9wEpewOEOAw7KfknY98ai903BwaCCcOqoR8SiiUmnsygfCGudsLwaoIuOkvDEP6EP/uo9
	09UM6cCA8SpZK9lT8UsvrNPznYNvzqxz+5mRNpZBMhZzDlqamHM4RICQw5ph9GMalXXMMiulOKAi3
	TNIn2h+K2IUejRuuPLFpngzlF5ANtKAn+vJFknwv7UGsyuxTlT+l/OCTjIBH8/eQUPStFCRC7sc1N
	6M0qsPg6HGol0YG65WxcP+e8Gf5Ys1URR3xVczhle/Yhfar+gOYUa2zmeIni61g4XH2y1FAysu/U7
	PCVY3vdg==;
From: David Woodhouse <dwmw2@infradead.org>
To: Roger Pau Monne <roger.pau@citrix.com>,
	qemu-devel@nongnu.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E . Iglesias" <edgar.iglesias@gmail.com>,
	Kevin Wolf <kwolf@redhat.com>,
	Hanna Reitz <hreitz@redhat.com>,
	=?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= <marcandre.lureau@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	xen-devel@lists.xenproject.org,
	qemu-block@nongnu.org
Subject: [PATCH 3/4] hw/xen: Use xs_node_read() from xen_netdev_get_name()
Date: Fri, 10 Jan 2025 10:03:25 +0000
Message-ID: <20250110100326.527101-3-dwmw2@infradead.org>
X-Mailer: git-send-email 2.47.0
In-Reply-To: <20250110100326.527101-1-dwmw2@infradead.org>
References: <fc9b22c55eaaa79a3ef9829c270bc4b4e93be7a0.camel@infradead.org>
 <20250110100326.527101-1-dwmw2@infradead.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: David Woodhouse <dwmw2@infradead.org>
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html

From: David Woodhouse <dwmw@amazon.co.uk>

Now that xs_node_read() can construct a node path, no need to open-code it.

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
 hw/net/xen_nic.c | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/hw/net/xen_nic.c b/hw/net/xen_nic.c
index 97ebd9fa30..5410039490 100644
--- a/hw/net/xen_nic.c
+++ b/hw/net/xen_nic.c
@@ -510,23 +510,22 @@ static char *xen_netdev_get_name(XenDevice *xendev, Error **errp)
 
     if (netdev->dev == -1) {
         XenBus *xenbus = XEN_BUS(qdev_get_parent_bus(DEVICE(xendev)));
-        char fe_path[XENSTORE_ABS_PATH_MAX + 1];
         int idx = (xen_mode == XEN_EMULATE) ? 0 : 1;
+        Error *local_err = NULL;
         char *value;
 
         /* Theoretically we could go up to INT_MAX here but that's overkill */
         while (idx < 100) {
-            snprintf(fe_path, sizeof(fe_path),
-                     "/local/domain/%u/device/vif/%u",
-                     xendev->frontend_id, idx);
-            value = qemu_xen_xs_read(xenbus->xsh, XBT_NULL, fe_path, NULL);
+            value = xs_node_read(xenbus->xsh, XBT_NULL, NULL, &local_err,
+                                 "/local/domain/%u/device/vif/%u",
+                                 xendev->frontend_id, idx);
             if (!value) {
                 if (errno == ENOENT) {
                     netdev->dev = idx;
+                    error_free(local_err);
                     goto found;
                 }
-                error_setg(errp, "cannot read %s: %s", fe_path,
-                           strerror(errno));
+                error_propagate(errp, local_err);
                 return NULL;
             }
             free(value);
-- 
2.47.0



From xen-devel-bounces@lists.xenproject.org Fri Jan 10 10:03:33 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 10:03:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869405.1280873 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWBrZ-0004Wz-7k; Fri, 10 Jan 2025 10:03:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869405.1280873; Fri, 10 Jan 2025 10:03:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWBrY-0004WE-WF; Fri, 10 Jan 2025 10:03:33 +0000
Received: by outflank-mailman (input) for mailman id 869405;
 Fri, 10 Jan 2025 10:03:31 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=/ds0=UC=desiato.srs.infradead.org=BATV+4d36ee5d223a5d86d66e+7810+infradead.org+dwmw2@srs-se1.protection.inumbo.net>)
 id 1tWBrX-0004A1-Pp
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 10:03:31 +0000
Received: from desiato.infradead.org (desiato.infradead.org
 [2001:8b0:10b:1:d65d:64ff:fe57:4e05])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 24910789-cf3a-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 11:03:30 +0100 (CET)
Received: from [2001:8b0:10b:1::ebe] (helo=i7.infradead.org)
 by desiato.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux))
 id 1tWBrT-00000009jwj-47G9; Fri, 10 Jan 2025 10:03:28 +0000
Received: from dwoodhou by i7.infradead.org with local (Exim 4.98 #2 (Red Hat
 Linux)) id 1tWBrS-00000002D80-3VgZ; Fri, 10 Jan 2025 10:03:26 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
X-Inumbo-ID: 24910789-cf3a-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding:
	MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:
	Reply-To:Content-Type:Content-ID:Content-Description;
	bh=KN/vJ32gBbSAX8GZerq/muMhqjU/qftUYdnqn8Z6Yn0=; b=KK+jmkp9uMAfKbBP17zM/QXfAh
	bODMZmPFLFjv6iKOGFosxjVZNvA4lDeColIFClm+nfxYwYJW6jVo1f3vmK4LVD7Vor2WN9ft6yGFS
	H2acwxNQyNkIZhsc7Y1E+Hcd9aZwaBdiqhpPBpzDKA1sRCum8YuvWK2y29C9v9rhaZV+YhgASmgeI
	AsIL+GYs2g/ggXEQnvCimZXqJHfpVIl7Nisvr5J9uHQHHqVuFihdNqCAVCMjw6nQH2pEPq34V93Cj
	PWWaLex2e/v0iNzRQ13NYiMI48qra5xCsCSn29zS5BIA85x0/PVhZkrGhqpTHYN5/HCuzfG42YILW
	1j8WK14Q==;
From: David Woodhouse <dwmw2@infradead.org>
To: Roger Pau Monne <roger.pau@citrix.com>,
	qemu-devel@nongnu.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E . Iglesias" <edgar.iglesias@gmail.com>,
	Kevin Wolf <kwolf@redhat.com>,
	Hanna Reitz <hreitz@redhat.com>,
	=?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= <marcandre.lureau@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	xen-devel@lists.xenproject.org,
	qemu-block@nongnu.org
Subject: [PATCH 1/4] hw/xen: Use xs_node_read() from xs_node_vscanf()
Date: Fri, 10 Jan 2025 10:03:23 +0000
Message-ID: <20250110100326.527101-1-dwmw2@infradead.org>
X-Mailer: git-send-email 2.47.0
In-Reply-To: <fc9b22c55eaaa79a3ef9829c270bc4b4e93be7a0.camel@infradead.org>
References: <fc9b22c55eaaa79a3ef9829c270bc4b4e93be7a0.camel@infradead.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: David Woodhouse <dwmw2@infradead.org>
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by desiato.infradead.org. See http://www.infradead.org/rpr.html

From: David Woodhouse <dwmw@amazon.co.uk>

Reduce some duplication.

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
 hw/xen/trace-events     |  1 -
 hw/xen/xen-bus-helper.c | 15 ++++++---------
 2 files changed, 6 insertions(+), 10 deletions(-)

diff --git a/hw/xen/trace-events b/hw/xen/trace-events
index 461dee7b23..b67942d07b 100644
--- a/hw/xen/trace-events
+++ b/hw/xen/trace-events
@@ -38,7 +38,6 @@ xen_device_remove_watch(const char *type, char *name, const char *node, const ch
 xs_node_create(const char *node) "%s"
 xs_node_destroy(const char *node) "%s"
 xs_node_vprintf(char *path, char *value) "%s %s"
-xs_node_vscanf(char *path, char *value) "%s %s"
 xs_node_read(const char *path, const char *value) "%s %s"
 xs_node_watch(char *path) "%s"
 xs_node_unwatch(char *path) "%s"
diff --git a/hw/xen/xen-bus-helper.c b/hw/xen/xen-bus-helper.c
index 0fba7946c5..57697799f3 100644
--- a/hw/xen/xen-bus-helper.c
+++ b/hw/xen/xen-bus-helper.c
@@ -105,25 +105,22 @@ int xs_node_vscanf(struct qemu_xs_handle *h,  xs_transaction_t tid,
                    const char *node, const char *key, Error **errp,
                    const char *fmt, va_list ap)
 {
-    char *path, *value;
+    char *value;
     int rc;
 
-    path = (strlen(node) != 0) ? g_strdup_printf("%s/%s", node, key) :
-        g_strdup(key);
-    value = qemu_xen_xs_read(h, tid, path, NULL);
-
-    trace_xs_node_vscanf(path, value);
+    if (node && strlen(node) != 0) {
+        value = xs_node_read(h, tid, NULL, errp, "%s/%s", node, key);
+    } else {
+        value = xs_node_read(h, tid, NULL, errp, "%s", key);
+    }
 
     if (value) {
         rc = vsscanf(value, fmt, ap);
     } else {
-        error_setg_errno(errp, errno, "failed to read from '%s'",
-                         path);
         rc = EOF;
     }
 
     free(value);
-    g_free(path);
 
     return rc;
 }
-- 
2.47.0



From xen-devel-bounces@lists.xenproject.org Fri Jan 10 10:03:33 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 10:03:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869407.1280881 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWBrZ-0004jH-MC; Fri, 10 Jan 2025 10:03:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869407.1280881; Fri, 10 Jan 2025 10:03:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWBrZ-0004gv-HY; Fri, 10 Jan 2025 10:03:33 +0000
Received: by outflank-mailman (input) for mailman id 869407;
 Fri, 10 Jan 2025 10:03:32 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=/ds0=UC=desiato.srs.infradead.org=BATV+4d36ee5d223a5d86d66e+7810+infradead.org+dwmw2@srs-se1.protection.inumbo.net>)
 id 1tWBrY-0004A1-Pu
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 10:03:32 +0000
Received: from desiato.infradead.org (desiato.infradead.org
 [2001:8b0:10b:1:d65d:64ff:fe57:4e05])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 24919dca-cf3a-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 11:03:30 +0100 (CET)
Received: from [2001:8b0:10b:1::ebe] (helo=i7.infradead.org)
 by desiato.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux))
 id 1tWBrT-00000009jwk-46jj; Fri, 10 Jan 2025 10:03:28 +0000
Received: from dwoodhou by i7.infradead.org with local (Exim 4.98 #2 (Red Hat
 Linux)) id 1tWBrS-00000002D85-3diG; Fri, 10 Jan 2025 10:03:26 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
X-Inumbo-ID: 24919dca-cf3a-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding:
	MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:
	Reply-To:Content-Type:Content-ID:Content-Description;
	bh=Xoo+xm3Tw2CkYCxIV3PtG0Wlpe8+ZC90junJ+uK4GHw=; b=peyUPkgzt+cH4h/xbt1pVyqhYy
	IJt7rina2x756yrTxng++yuyPDzQZ4pI0XICMTyTy/uRV2ramirDoVa+obGvj1xghHgvGykSTeckP
	+eZrwM4YSO4HeWKqgznC+j6hOf5SQ0M5XcMXuhAyanlOndclQI2AhCfKgDZR2mqxXkPXLvJA6nvLr
	5By/prH62avmOLpsdzv323RBV83Vi9DvbI9qUn7J9CcsbmRo/5fK/boU3EFEHlUKa0ORD9B6IhjCm
	hoPOFZQhLkf56B2mljrClQ8Y0eVTBK75OQqAG0If7pZPbeFcYwdgOKsyEoT6PrZkIstBluJGb+jl7
	Mx+1HBwA==;
From: David Woodhouse <dwmw2@infradead.org>
To: Roger Pau Monne <roger.pau@citrix.com>,
	qemu-devel@nongnu.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E . Iglesias" <edgar.iglesias@gmail.com>,
	Kevin Wolf <kwolf@redhat.com>,
	Hanna Reitz <hreitz@redhat.com>,
	=?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= <marcandre.lureau@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	xen-devel@lists.xenproject.org,
	qemu-block@nongnu.org
Subject: [PATCH 2/4] hw/xen: Use xs_node_read() from xen_console_get_name()
Date: Fri, 10 Jan 2025 10:03:24 +0000
Message-ID: <20250110100326.527101-2-dwmw2@infradead.org>
X-Mailer: git-send-email 2.47.0
In-Reply-To: <20250110100326.527101-1-dwmw2@infradead.org>
References: <fc9b22c55eaaa79a3ef9829c270bc4b4e93be7a0.camel@infradead.org>
 <20250110100326.527101-1-dwmw2@infradead.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: David Woodhouse <dwmw2@infradead.org>
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by desiato.infradead.org. See http://www.infradead.org/rpr.html

From: David Woodhouse <dwmw@amazon.co.uk>

Now that xs_node_read() can construct a node path, no need to open-code it.

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
 hw/char/xen_console.c | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
index 989e75fef8..9338e00473 100644
--- a/hw/char/xen_console.c
+++ b/hw/char/xen_console.c
@@ -367,28 +367,28 @@ static char *xen_console_get_name(XenDevice *xendev, Error **errp)
 
     if (con->dev == -1) {
         XenBus *xenbus = XEN_BUS(qdev_get_parent_bus(DEVICE(xendev)));
-        char fe_path[XENSTORE_ABS_PATH_MAX + 1];
         int idx = (xen_mode == XEN_EMULATE) ? 0 : 1;
+        Error *local_err = NULL;
         char *value;
 
         /* Theoretically we could go up to INT_MAX here but that's overkill */
         while (idx < 100) {
             if (!idx) {
-                snprintf(fe_path, sizeof(fe_path),
-                         "/local/domain/%u/console", xendev->frontend_id);
+                value = xs_node_read(xenbus->xsh, XBT_NULL, NULL, &local_err,
+                                     "/local/domain/%u/console",
+                                     xendev->frontend_id);
             } else {
-                snprintf(fe_path, sizeof(fe_path),
-                         "/local/domain/%u/device/console/%u",
-                         xendev->frontend_id, idx);
+                value = xs_node_read(xenbus->xsh, XBT_NULL, NULL, &local_err,
+                                     "/local/domain/%u/device/console/%u",
+                                     xendev->frontend_id, idx);
             }
-            value = qemu_xen_xs_read(xenbus->xsh, XBT_NULL, fe_path, NULL);
             if (!value) {
                 if (errno == ENOENT) {
                     con->dev = idx;
+                    error_free(local_err);
                     goto found;
                 }
-                error_setg(errp, "cannot read %s: %s", fe_path,
-                           strerror(errno));
+                error_propagate(errp, local_err);
                 return NULL;
             }
             free(value);
-- 
2.47.0



From xen-devel-bounces@lists.xenproject.org Fri Jan 10 11:40:43 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 11:40:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869468.1280902 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWDNI-0004DQ-Hw; Fri, 10 Jan 2025 11:40:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869468.1280902; Fri, 10 Jan 2025 11:40:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWDNI-0004DJ-EQ; Fri, 10 Jan 2025 11:40:24 +0000
Received: by outflank-mailman (input) for mailman id 869468;
 Fri, 10 Jan 2025 11:40: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
 <SRS0=mmVM=UC=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tWDNG-0004DB-W4
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 11:40:23 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ac5057e6-cf47-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 12:40:21 +0100 (CET)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-aaee2c5ee6eso327258466b.1
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 03:40:21 -0800 (PST)
Received: from localhost ([66.81.170.107]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c90da2c8sm160455666b.62.2025.01.10.03.40.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 10 Jan 2025 03:40:20 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ac5057e6-cf47-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736509221; x=1737114021; darn=lists.xenproject.org;
        h=in-reply-to:references:from:subject:cc:to:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=pWNhJ+USbtMq5De5TNW6JSW2YlRcCjhPAv9sMOiVInI=;
        b=egBpkougdHjg2F2+oRSd+RNdZG6/IkqUoIwO3D9pdiT2/eT9EyJLk+JZmDKKUAGDjO
         LzCBtkS26TulVF1odf+5/R/FfMvIlDVEdW2lkOZUIB2PzaRH/LaCwlhcqXnClTa13xmq
         U+lYnM9upXKB07vYGNNpGyLaWRwickiV0PEoE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736509221; x=1737114021;
        h=in-reply-to:references:from:subject:cc:to:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=pWNhJ+USbtMq5De5TNW6JSW2YlRcCjhPAv9sMOiVInI=;
        b=kZWjUQI3LpaZ8VpDTzrAxcKAPI6OvWyOlnpMJHOL9yJ1I1jQ4HF6AF3MKCc5IBF5Fp
         KlM9AgpJ1u3Cs4aoy17+0D1oAPaHQJU/66SHhLQ4Vvq6BJwn+5PTCwJOL1HirDz4qtxw
         I0b0tcRcnnFMG7QakMs/HUct4LYDPoBc4yYlvj6SxGa8VFzidj1D24wIzzdatiWbyxUo
         1C1rANWVcpB57W0fK14gXQrL/V5hEWCHFVVyPqd8e8qavLPPgr3pWjo2FFD2dhDVZHiJ
         ISuP5SPjWxUQyLgoKXE1fgqPG6fPtRHs1R25sN1sigf3bbjvEk1wYEyUbYtuhGFrs51g
         5Oow==
X-Forwarded-Encrypted: i=1; AJvYcCUsXQdumbZmhxG02ROYhsVGenCtC9yCrICLeiZTdxOV83++b/0Bk6Z7+FQHsXGVo4NV8iyqxmBC17o=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwcSiK6jr4y/+wZsZ7+zxDTlYtuJRY4rM8QdhtZr46AvUfpQWl+
	CD3z8dXBzh4X+YnPaXBA5zEWLyVMxn3GP+uLEOzwaBs4svX6fxIEgRWXGvUMCSE=
X-Gm-Gg: ASbGncsfuzQhTabASLymGK+tVGcRQtaQZXbtkQlsY4xsG32W0RHqYSCVwgE6r53ecs5
	nw3AI/gPeQZmTBdzqMO9sC8ozgGzXMi+vYRch4qDCA0culQ9iam74q/T2QaI/xaW6mClxQQd3Wl
	/RCShkqAmwlJH0kVD9yNhD+oXLYpZe4oZd59mcas12CjUderIxok8QL+7yYbUvK+9ktNWTixS+o
	I2idVou5RboKpwK+/zZ8W7uCLPsEPn1T4G0Mzrl+vdYxIlqLCOq8ZCdoVZtxmQ=
X-Google-Smtp-Source: AGHT+IFSvwcBI3JiUS552frjGxJDx4z6XY8CARYI1vKfRa3tJ6aQ5YolVotCuP3M8VNKEkficu7KEQ==
X-Received: by 2002:a17:906:c143:b0:aa6:79fa:b480 with SMTP id a640c23a62f3a-ab2ab670756mr947096666b.10.1736509220710;
        Fri, 10 Jan 2025 03:40:20 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Fri, 10 Jan 2025 11:40:14 +0000
Message-Id: <D6YD543UTJJ5.1OAN0MJ4D1OZG@cloud.com>
To: "Alejandro Vallejo" <alejandro.vallejo@cloud.com>, "Jan Beulich"
 <jbeulich@suse.com>
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>,
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v2 10/13] x86/mpx: Map/unmap xsave area in in
 read_bndcfgu()
From: "Alejandro Vallejo" <alejandro.vallejo@cloud.com>
X-Mailer: aerc 0.18.2
References: <20241105143310.28301-1-alejandro.vallejo@cloud.com>
 <20241105143310.28301-11-alejandro.vallejo@cloud.com>
 <7e36137b-ce1f-4e78-9a41-fbfdbe9c0d87@suse.com>
 <D6D3WWUR75T2.1C5DL8WJGQVNP@cloud.com>
 <def2d398-ae9a-43c8-8de6-22ea01eae196@suse.com>
 <D6D6IAZRJYH5.E1DPQHQSI9CE@cloud.com>
In-Reply-To: <D6D6IAZRJYH5.E1DPQHQSI9CE@cloud.com>

On Mon Dec 16, 2024 at 2:02 PM GMT, Alejandro Vallejo wrote:
> On Mon Dec 16, 2024 at 12:03 PM GMT, Jan Beulich wrote:
> > On 16.12.2024 13:00, Alejandro Vallejo wrote:
> > > On Mon Dec 9, 2024 at 4:30 PM GMT, Jan Beulich wrote:
> > >> On 05.11.2024 15:33, Alejandro Vallejo wrote:
> > >>> --- a/xen/arch/x86/xstate.c
> > >>> +++ b/xen/arch/x86/xstate.c
> > >>> @@ -1022,9 +1022,10 @@ int handle_xsetbv(u32 index, u64 new_bv)
> > >>> =20
> > >>>  uint64_t read_bndcfgu(void)
> > >>>  {
> > >>> +    uint64_t bndcfgu =3D 0;
> > >>>      unsigned long cr0 =3D read_cr0();
> > >>> -    struct xsave_struct *xstate
> > >>> -        =3D idle_vcpu[smp_processor_id()]->arch.xsave_area;
> > >>> +    struct vcpu *v =3D idle_vcpu[smp_processor_id()];
> > >>
> > >> Can this be pointer-to-const? Certainly right now, so the question i=
s rather
> > >> meant to be forward looking.
> > >>
> > >>> +    struct xsave_struct *xstate =3D VCPU_MAP_XSAVE_AREA(v);
> > >>
> > >> This certainly can be pointer-to-const, just like ...
> > >>
> > >>>      const struct xstate_bndcsr *bndcsr;
> > >>
> > >> ... this is.
> > >=20
> > > Yes, those retained non-const because of the now missing patch to zer=
o-out
> > > bndcfgu.
> >
> > I'm afraid this reply is ambiguous as to what's going to happen in the =
next
> > version. I can read both "will change" and "needs to stay" into it.
> >
> > Jan
>
> It was an answer to "Can this be pointer to const?". Yes, I'll put the co=
nst
> back.
>
> Cheers,
> Alejandro

Actually, xstate is the target of the assembly, so it will be written to
(though not from C). It seems like asking for trouble modifying the target =
of a
pointer to non-volatile const from inline assembly.

I'll leave it as-is in the interest of safety.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 12:54:03 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 12:54:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869488.1280912 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWEWL-0004f2-0R; Fri, 10 Jan 2025 12:53:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869488.1280912; Fri, 10 Jan 2025 12:53:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWEWK-0004ev-Ti; Fri, 10 Jan 2025 12:53:48 +0000
Received: by outflank-mailman (input) for mailman id 869488;
 Fri, 10 Jan 2025 12:53: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
 <SRS0=1PUc=UC=eurecom.fr=Ariel.Otilibili-Anieli@srs-se1.protection.inumbo.net>)
 id 1tWEWJ-0004ep-Ag
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 12:53:47 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ed633e96-cf51-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 13:53:46 +0100 (CET)
Received: from quovadis.eurecom.fr ([10.3.2.233])
 by drago1i.eurecom.fr with ESMTP; 10 Jan 2025 13:53:45 +0100
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ed633e96-cf51-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1736513626; x=1768049626;
  h=from:in-reply-to:references:date:cc:to:mime-version:
   message-id:subject:content-transfer-encoding;
  bh=jZrrpoGJiGoVBhLWeWtWJlEZoU28cY8SLk4KvSHoMxM=;
  b=IyLYZgVzH8xYtsUqvIpWpmbr39Zy+5VVwZTrqk4f+p/xZHzW3JFekUD2
   lNpulTiDZRNa79El7gntFWXKP6KAdskmq59rjK5NluQ1aWU3274hoWLjo
   oGxY2z5h47GQaCzVWHrFxleyttL7bIQF7/+Zkf1eoOV9pcMrOiiRxPeP2
   Q=;
X-CSE-ConnectionGUID: PJwYhBCSSHCUYqauNA2TOA==
X-CSE-MsgGUID: GuCH/WsjTxSEnzAlpCM6OQ==
X-IronPort-AV: E=Sophos;i="6.12,303,1728943200"; 
   d="scan'208";a="28474810"
From: "Ariel Otilibili-Anieli" <Ariel.Otilibili-Anieli@eurecom.fr>
In-Reply-To: <alpine.DEB.2.22.394.2501020908160.16425@ubuntu-linux-20-04-desktop>
Content-Type: text/plain; charset="utf-8"
X-Forward: 88.183.119.157
References: <20241218233659.573195-2-Ariel.Otilibili-Anieli@eurecom.fr> <20241218233659.573195-3-Ariel.Otilibili-Anieli@eurecom.fr> <alpine.DEB.2.22.394.2501020908160.16425@ubuntu-linux-20-04-desktop>
Date: Fri, 10 Jan 2025 13:53:45 +0100
Cc: xen-devel@lists.xenproject.org, "Andrew Cooper" <andrew.cooper3@citrix.com>, "Anthony PERARD" <anthony.perard@vates.tech>, "Michal Orzel" <michal.orzel@amd.com>, "Jan Beulich" <jbeulich@suse.com>, "Julien Grall" <julien@xen.org>, =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
To: "Stefano Stabellini" <sstabellini@kernel.org>
MIME-Version: 1.0
Message-ID: <45fd2-67811880-bf-66d99e8@245876410>
Subject: =?utf-8?q?Re=3A?= [PATCH 1/1] =?utf-8?q?xen/common=3A?= Remove dead code
User-Agent: SOGoMail 5.11.1
Content-Transfer-Encoding: quoted-printable
Content-Length: 402

Hi Stefano,

On Thursday, January 02, 2025 18:08 CET, Stefano Stabellini <sstabellin=
i@kernel.org> wrote:

> On Thu, 19 Dec 2024, Ariel Otilibili wrote:
>=20
> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
>=20
>=20
Thanks for having looked into the patch; sorry for the late response, I=
 have had limited access to my mailbox.

I will follow up with an upstream update.

Regards,
Ariel



From xen-devel-bounces@lists.xenproject.org Fri Jan 10 13:24:00 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 13:24:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869498.1280923 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWEzR-0000KP-7z; Fri, 10 Jan 2025 13:23:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869498.1280923; Fri, 10 Jan 2025 13:23:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWEzR-0000KI-4q; Fri, 10 Jan 2025 13:23:53 +0000
Received: by outflank-mailman (input) for mailman id 869498;
 Fri, 10 Jan 2025 13:23: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
 <SRS0=u9QL=UC=suse.de=tzimmermann@srs-se1.protection.inumbo.net>)
 id 1tWEzP-0000K9-Fr
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 13:23:52 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de
 [2a07:de40:b251:101:10:150:64:1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 20bc6933-cf56-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 14:23:49 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id 087B921172;
 Fri, 10 Jan 2025 13:23:49 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 7CB5D13763;
 Fri, 10 Jan 2025 13:23:48 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id zEwkHWQfgWcIXgAAD6G6ig
 (envelope-from <tzimmermann@suse.de>); Fri, 10 Jan 2025 13:23:48 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 20bc6933-cf56-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736515429; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=PrilCMX5C09JO84DVBY8YiEapsTpHUYRcsRbRBep3cA=;
	b=m+6oSc3XjiJxQ7r2O4TIutB8rfN4Sn51k9uRZDknztaHK9SUvXjiQ6+F5InXDkhWZQjx2e
	bEKydpyg4D+gW9I2rZHGRVGFVmNINT6YqOEDsK35alPpZC67b21Ag5WeKkLepzWE0+aED1
	S9lfcFIhJOEC+GNPF38po+TNTa8tJCY=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736515429;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=PrilCMX5C09JO84DVBY8YiEapsTpHUYRcsRbRBep3cA=;
	b=ASsviGnmX5mBcPbnd2R2scx+AS/t4X+QqjIZ1BzhB4fbdnEbKRUxbOVJHsRs2T+pwqFspq
	Yu0sZOw7CnwQ/GCA==
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.de header.s=susede2_rsa header.b=m+6oSc3X;
	dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=ASsviGnm
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736515429; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=PrilCMX5C09JO84DVBY8YiEapsTpHUYRcsRbRBep3cA=;
	b=m+6oSc3XjiJxQ7r2O4TIutB8rfN4Sn51k9uRZDknztaHK9SUvXjiQ6+F5InXDkhWZQjx2e
	bEKydpyg4D+gW9I2rZHGRVGFVmNINT6YqOEDsK35alPpZC67b21Ag5WeKkLepzWE0+aED1
	S9lfcFIhJOEC+GNPF38po+TNTa8tJCY=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736515429;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=PrilCMX5C09JO84DVBY8YiEapsTpHUYRcsRbRBep3cA=;
	b=ASsviGnmX5mBcPbnd2R2scx+AS/t4X+QqjIZ1BzhB4fbdnEbKRUxbOVJHsRs2T+pwqFspq
	Yu0sZOw7CnwQ/GCA==
Content-Type: multipart/mixed; boundary="------------Ak8c05R8qA0Bhl3CK6SC6vGZ"
Message-ID: <e800ebc2-39b5-46d5-89ec-883ed1c7626b@suse.de>
Date: Fri, 10 Jan 2025 14:23:48 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 02/25] drm/dumb-buffers: Provide helper to set pitch
 and size
To: Andy Yan <andyshrk@163.com>
Cc: maarten.lankhorst@linux.intel.com, mripard@kernel.org, airlied@gmail.com,
 simona@ffwll.ch, dri-devel@lists.freedesktop.org,
 linux-mediatek@lists.infradead.org, freedreno@lists.freedesktop.org,
 linux-arm-msm@vger.kernel.org, imx@lists.linux.dev,
 linux-samsung-soc@vger.kernel.org, nouveau@lists.freedesktop.org,
 virtualization@lists.linux.dev, spice-devel@lists.freedesktop.org,
 linux-renesas-soc@vger.kernel.org, linux-rockchip@lists.infradead.org,
 linux-tegra@vger.kernel.org, intel-xe@lists.freedesktop.org,
 xen-devel@lists.xenproject.org
References: <20250109150310.219442-1-tzimmermann@suse.de>
 <20250109150310.219442-3-tzimmermann@suse.de>
 <94f78e1.19bf.1944de709b0.Coremail.andyshrk@163.com>
Content-Language: en-US
From: Thomas Zimmermann <tzimmermann@suse.de>
Autocrypt: addr=tzimmermann@suse.de; keydata=
 xsBNBFs50uABCADEHPidWt974CaxBVbrIBwqcq/WURinJ3+2WlIrKWspiP83vfZKaXhFYsdg
 XH47fDVbPPj+d6tQrw5lPQCyqjwrCPYnq3WlIBnGPJ4/jreTL6V+qfKRDlGLWFjZcsrPJGE0
 BeB5BbqP5erN1qylK9i3gPoQjXGhpBpQYwRrEyQyjuvk+Ev0K1Jc5tVDeJAuau3TGNgah4Yc
 hdHm3bkPjz9EErV85RwvImQ1dptvx6s7xzwXTgGAsaYZsL8WCwDaTuqFa1d1jjlaxg6+tZsB
 9GluwvIhSezPgnEmimZDkGnZRRSFiGP8yjqTjjWuf0bSj5rUnTGiyLyRZRNGcXmu6hjlABEB
 AAHNJ1Rob21hcyBaaW1tZXJtYW5uIDx0emltbWVybWFubkBzdXNlLmRlPsLAjgQTAQgAOAIb
 AwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftODH
 AAoJEGgNwR1TC3ojx1wH/0hKGWugiqDgLNXLRD/4TfHBEKmxIrmfu9Z5t7vwUKfwhFL6hqvo
 lXPJJKQpQ2z8+X2vZm/slsLn7J1yjrOsoJhKABDi+3QWWSGkaGwRJAdPVVyJMfJRNNNIKwVb
 U6B1BkX2XDKDGffF4TxlOpSQzdtNI/9gleOoUA8+jy8knnDYzjBNOZqLG2FuTdicBXblz0Mf
 vg41gd9kCwYXDnD91rJU8tzylXv03E75NCaTxTM+FBXPmsAVYQ4GYhhgFt8S2UWMoaaABLDe
 7l5FdnLdDEcbmd8uLU2CaG4W2cLrUaI4jz2XbkcPQkqTQ3EB67hYkjiEE6Zy3ggOitiQGcqp
 j//OwE0EWznS4AEIAMYmP4M/V+T5RY5at/g7rUdNsLhWv1APYrh9RQefODYHrNRHUE9eosYb
 T6XMryR9hT8XlGOYRwKWwiQBoWSDiTMo/Xi29jUnn4BXfI2px2DTXwc22LKtLAgTRjP+qbU6
 3Y0xnQN29UGDbYgyyK51DW3H0If2a3JNsheAAK+Xc9baj0LGIc8T9uiEWHBnCH+RdhgATnWW
 GKdDegUR5BkDfDg5O/FISymJBHx2Dyoklv5g4BzkgqTqwmaYzsl8UxZKvbaxq0zbehDda8lv
 hFXodNFMAgTLJlLuDYOGLK2AwbrS3Sp0AEbkpdJBb44qVlGm5bApZouHeJ/+n+7r12+lqdsA
 EQEAAcLAdgQYAQgAIAIbDBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftOH6AAoJEGgNwR1T
 C3ojVSkIALpAPkIJPQoURPb1VWjh34l0HlglmYHvZszJWTXYwavHR8+k6Baa6H7ufXNQtThR
 yIxJrQLW6rV5lm7TjhffEhxVCn37+cg0zZ3j7zIsSS0rx/aMwi6VhFJA5hfn3T0TtrijKP4A
 SAQO9xD1Zk9/61JWk8OysuIh7MXkl0fxbRKWE93XeQBhIJHQfnc+YBLprdnxR446Sh8Wn/2D
 Ya8cavuWf2zrB6cZurs048xe0UbSW5AOSo4V9M0jzYI4nZqTmPxYyXbm30Kvmz0rYVRaitYJ
 4kyYYMhuULvrJDMjZRvaNe52tkKAvMevcGdt38H4KSVXAylqyQOW5zvPc4/sq9c=
In-Reply-To: <94f78e1.19bf.1944de709b0.Coremail.andyshrk@163.com>
X-Rspamd-Queue-Id: 087B921172
X-Spam-Level: 
X-Spamd-Result: default: False [-1.91 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MIME_BASE64_TEXT_BOGUS(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_DKIM_ALLOW(-0.20)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[multipart/mixed,text/plain,text/x-patch];
	MIME_BASE64_TEXT(0.10)[];
	MX_GOOD(-0.01)[];
	MIME_TRACE(0.00)[0:+,1:+,2:+];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[19];
	ARC_NA(0.00)[];
	FREEMAIL_TO(0.00)[163.com];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	FREEMAIL_ENVRCPT(0.00)[163.com,gmail.com];
	RCVD_TLS_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	MID_RHS_MATCH_FROM(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DKIM_TRACE(0.00)[suse.de:+];
	ASN(0.00)[asn:25478, ipnet:::/0, country:RU];
	FREEMAIL_CC(0.00)[linux.intel.com,kernel.org,gmail.com,ffwll.ch,lists.freedesktop.org,lists.infradead.org,vger.kernel.org,lists.linux.dev,lists.xenproject.org];
	HAS_ATTACHMENT(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:email,suse.de:dkim,suse.de:mid,infradead.org:email,infradead.org:url]
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Rspamd-Action: no action
X-Spam-Score: -1.91
X-Spam-Flag: NO

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

Hi


Am 10.01.25 um 02:49 schrieb Andy Yan:
> Hi Thomas,
>
> At 2025-01-09 22:56:56, "Thomas Zimmermann" <tzimmermann@suse.de> wrote:
>> Add drm_modes_size_dumb(), a helper to calculate the dumb-buffer
>> scanline pitch and allocation size. Implementations of struct
>> drm_driver.dumb_create can call the new helper for their size
>> computations. There's currently quite a bit of code duplication
>> among DRM's memory managers. Each calculates scanline pitch and
>> buffer size from the given arguments, but the implementations are
>> inconsistent in how they treat alignment and format support. Later
>> patches will unify this code on top of drm_mode_size_dumb() as
>> much as possible.
>>
>> drm_mode_size_dumb() uses existing 4CC format helpers to interpret the
>> given color mode. This makes the dumb-buffer interface behave similar
>> the kernel's video= parameter. Again, current per-driver implementations
>> likely have subtle differences or bugs in how they support color modes.
>>
>> Future directions: one bug is present in the current input validation
>> in drm_mode_create_dumb(). The dumb-buffer overflow tests round up any
>> given bits-per-pixel value to a multiple of 8. So even one-bit formats,
>> such as DRM_FORMAT_C1, require 8 bits per pixel. While not common,
>> low-end displays use such formats; with a possible overcommitment of
>> memory. At some point, the validation logic in drm_mode_size_dumb() is
>> supposed to replace the erronous code.
>>
>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>> ---
>> drivers/gpu/drm/drm_dumb_buffers.c | 93 ++++++++++++++++++++++++++++++
>> include/drm/drm_dumb_buffers.h     | 14 +++++
>> 2 files changed, 107 insertions(+)
>> create mode 100644 include/drm/drm_dumb_buffers.h
>>
>> diff --git a/drivers/gpu/drm/drm_dumb_buffers.c b/drivers/gpu/drm/drm_dumb_buffers.c
>> index 9916aaf5b3f2..fd39720bd617 100644
>> --- a/drivers/gpu/drm/drm_dumb_buffers.c
>> +++ b/drivers/gpu/drm/drm_dumb_buffers.c
>> @@ -25,6 +25,8 @@
>>
>> #include <drm/drm_device.h>
>> #include <drm/drm_drv.h>
>> +#include <drm/drm_dumb_buffers.h>
>> +#include <drm/drm_fourcc.h>
>> #include <drm/drm_gem.h>
>> #include <drm/drm_mode.h>
>>
>> @@ -57,6 +59,97 @@
>>   * a hardware-specific ioctl to allocate suitable buffer objects.
>>   */
>>
>> +static int drm_mode_align_dumb(struct drm_mode_create_dumb *args,
>> +			       unsigned long pitch_align,
>> +			       unsigned long size_align)
>> +{
>> +	u32 pitch = args->pitch;
>> +	u32 size;
>> +
>> +	if (!pitch)
>> +		return -EINVAL;
>> +
>> +	if (pitch_align)
>> +		pitch = roundup(pitch, pitch_align);
>> +
>> +	/* overflow checks for 32bit size calculations */
>> +	if (args->height > U32_MAX / pitch)
>> +		return -EINVAL;
>> +
>> +	if (!size_align)
>> +		size_align = PAGE_SIZE;
>> +	else if (!IS_ALIGNED(size_align, PAGE_SIZE))
>> +		return -EINVAL;
>> +
>> +	size = ALIGN(args->height * pitch, size_align);
>> +	if (!size)
>> +		return -EINVAL;
>> +
>> +	args->pitch = pitch;
>> +	args->size = size;
>> +
>> +	return 0;
>> +}
>> +
>> +/**
>> + * drm_mode_size_dumb - Calculates the scanline and buffer sizes for dumb buffers
>> + * @dev: DRM device
>> + * @args: Parameters for the dumb buffer
>> + * @pitch_align: Scanline alignment in bytes
>> + * @size_align: Buffer-size alignment in bytes
>> + *
>> + * The helper drm_mode_size_dumb() calculates the size of the buffer
>> + * allocation and the scanline size for a dumb buffer. Callers have to
>> + * set the buffers width, height and color mode in the argument @arg.
>> + * The helper validates the correctness of the input and tests for
>> + * possible overflows. If successful, it returns the dumb buffer's
>> + * required scanline pitch and size in &args.
>> + *
>> + * The parameter @pitch_align allows the driver to specifies an
>> + * alignment for the scanline pitch, if the hardware requires any. The
>> + * calculated pitch will be a multiple of the alignment. The parameter
>> + * @size_align allows to specify an alignment for buffer sizes. The
>> + * returned size is always a multiple of PAGE_SIZE.
>> + *
>> + * Returns:
>> + * Zero on success, or a negative error code otherwise.
>> + */
>> +int drm_mode_size_dumb(struct drm_device *dev,
>> +		       struct drm_mode_create_dumb *args,
>> +		       unsigned long pitch_align,
>> +		       unsigned long size_align)
>> +{
>> +	u32 fourcc;
>> +	const struct drm_format_info *info;
>> +	u64 pitch;
>> +
>> +	/*
>> +	 * The scanline pitch depends on the buffer width and the color
>> +	 * format. The latter is specified as a color-mode constant for
>> +	 * which we first have to find the corresponding color format.
>> +	 *
>> +	 * Different color formats can have the same color-mode constant.
>> +	 * For example XRGB8888 and BGRX8888 both have a color mode of 32.
>> +	 * It is possible to use different formats for dumb-buffer allocation
>> +	 * and rendering as long as all involved formats share the same
>> +	 * color-mode constant.
>> +	 */
>> +	fourcc = drm_driver_color_mode_format(dev, args->bpp);
> This will return -EINVAL with bpp drm_mode_legacy_fb_format doesn't support,
> such as(NV15, NV20, NV30, bpp is 10)[0]

Thanks for taking a look. That NV-related code at [0] is a 'somewhat 
non-idiomatic use' of the UAPI. The dumb-buffer interface really just 
supports a single plane. The fix would be a new ioctl that takes a DRM 
4cc constant and returns a buffer handle/pitch/size for each plane. But 
that's separate series throughout the various components.

There's also code XRGB16161616F. This is a viable format for the UAPI, 
but seems not very useful in practice.

>
> And there are also some AFBC based format with bpp can't be handled here, see:
> static __u32 drm_gem_afbc_get_bpp(struct drm_device *dev,
>                                    const struct drm_mode_fb_cmd2 *mode_cmd)
> {
>          const struct drm_format_info *info;
>                  
>          info = drm_get_format_info(dev, mode_cmd);
>                  
>          switch (info->format) {
>          case DRM_FORMAT_YUV420_8BIT:
>                  return 12;
>          case DRM_FORMAT_YUV420_10BIT:
>                  return 15;
>          case DRM_FORMAT_VUY101010:
>                  return 30;
>          default:
>                  return drm_format_info_bpp(info, 0);
>          }
> }

Same problem here. These YUV formats are multi-planar and there should 
be no dumb buffers for them.

As we still have to support these all use cases, I've modified the new 
helper to fallback to computing the pitch from the given bpp value. 
That's what drivers currently do. Could you please apply the attached 
patch on top of the series and report back the result of the test? You 
should see a kernel warning about the unknown color mode, but allocation 
should succeed.

Best regards
Thomas

>
>
> [0]https://gitlab.freedesktop.org/mesa/drm/-/blob/main/tests/modetest/buffers.c?ref_type=heads#L159
>
> This introduce a modetest failure on rockchip platform:
> # modetest -M rockchip -s 70@68:1920x1080 -P 32@68:1920x1080@NV30
> setting mode 1920x1080-60.00Hz on connectors 70, crtc 68
> testing 1920x1080@NV30 overlay plane 32
> failed to create dumb buffer: Invalid argument
>
> I think other platform with bpp can't handler by  drm_mode_legacy_fb_format will
> also see this kind of failure:
>
>
>
>> +	if (fourcc == DRM_FORMAT_INVALID)
>> +		return -EINVAL;
>> +	info = drm_format_info(fourcc);
>> +	if (!info)
>> +		return -EINVAL;
>> +	pitch = drm_format_info_min_pitch(info, 0, args->width);
>> +	if (!pitch || pitch > U32_MAX)
>> +		return -EINVAL;
>> +
>> +	args->pitch = pitch;
>> +
>> +	return drm_mode_align_dumb(args, pitch_align, size_align);
>> +}
>> +EXPORT_SYMBOL(drm_mode_size_dumb);
>> +
>> int drm_mode_create_dumb(struct drm_device *dev,
>> 			 struct drm_mode_create_dumb *args,
>> 			 struct drm_file *file_priv)
>> diff --git a/include/drm/drm_dumb_buffers.h b/include/drm/drm_dumb_buffers.h
>> new file mode 100644
>> index 000000000000..6fe36004b19d
>> --- /dev/null
>> +++ b/include/drm/drm_dumb_buffers.h
>> @@ -0,0 +1,14 @@
>> +/* SPDX-License-Identifier: MIT */
>> +
>> +#ifndef __DRM_DUMB_BUFFERS_H__
>> +#define __DRM_DUMB_BUFFERS_H__
>> +
>> +struct drm_device;
>> +struct drm_mode_create_dumb;
>> +
>> +int drm_mode_size_dumb(struct drm_device *dev,
>> +		       struct drm_mode_create_dumb *args,
>> +		       unsigned long pitch_align,
>> +		       unsigned long size_align);
>> +
>> +#endif
>> -- 
>> 2.47.1
>>
>>
>> _______________________________________________
>> Linux-rockchip mailing list
>> Linux-rockchip@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-rockchip

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)

--------------Ak8c05R8qA0Bhl3CK6SC6vGZ
Content-Type: text/x-patch; charset=UTF-8;
 name="0001-add-fallback-for-unknown-bpp.patch"
Content-Disposition: attachment;
 filename="0001-add-fallback-for-unknown-bpp.patch"
Content-Transfer-Encoding: base64

RnJvbSAyZTcwMDU2NTRkNzZiNzFmNzhmZTA3ZmNmOThhMzU3MDAyMmY1MDM0IE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBUaG9tYXMgWmltbWVybWFubiA8dHppbW1lcm1hbm5A
c3VzZS5kZT4KRGF0ZTogRnJpLCAxMCBKYW4gMjAyNSAwOTozNToxMiArMDEwMApTdWJqZWN0
OiBbUEFUQ0hdIGFkZCBmYWxsYmFjayBmb3IgdW5rbm93biBicHAKCi0tLQogZHJpdmVycy9n
cHUvZHJtL2RybV9kdW1iX2J1ZmZlcnMuYyB8IDI4ICsrKysrKysrKysrKysrKysrKysrLS0t
LS0tLS0KIDEgZmlsZSBjaGFuZ2VkLCAyMCBpbnNlcnRpb25zKCspLCA4IGRlbGV0aW9ucygt
KQoKZGlmZiAtLWdpdCBhL2RyaXZlcnMvZ3B1L2RybS9kcm1fZHVtYl9idWZmZXJzLmMgYi9k
cml2ZXJzL2dwdS9kcm0vZHJtX2R1bWJfYnVmZmVycy5jCmluZGV4IGZkMzk3MjBiZDYxNy4u
NWYyZDAyNmM3NjRjIDEwMDY0NAotLS0gYS9kcml2ZXJzL2dwdS9kcm0vZHJtX2R1bWJfYnVm
ZmVycy5jCisrKyBiL2RyaXZlcnMvZ3B1L2RybS9kcm1fZHVtYl9idWZmZXJzLmMKQEAgLTEx
OSw5ICsxMTksOCBAQCBpbnQgZHJtX21vZGVfc2l6ZV9kdW1iKHN0cnVjdCBkcm1fZGV2aWNl
ICpkZXYsCiAJCSAgICAgICB1bnNpZ25lZCBsb25nIHBpdGNoX2FsaWduLAogCQkgICAgICAg
dW5zaWduZWQgbG9uZyBzaXplX2FsaWduKQogeworCXU2NCBwaXRjaCA9IDA7CiAJdTMyIGZv
dXJjYzsKLQljb25zdCBzdHJ1Y3QgZHJtX2Zvcm1hdF9pbmZvICppbmZvOwotCXU2NCBwaXRj
aDsKIAogCS8qCiAJICogVGhlIHNjYW5saW5lIHBpdGNoIGRlcGVuZHMgb24gdGhlIGJ1ZmZl
ciB3aWR0aCBhbmQgdGhlIGNvbG9yCkBAIC0xMzUsMTIgKzEzNCwyNSBAQCBpbnQgZHJtX21v
ZGVfc2l6ZV9kdW1iKHN0cnVjdCBkcm1fZGV2aWNlICpkZXYsCiAJICogY29sb3ItbW9kZSBj
b25zdGFudC4KIAkgKi8KIAlmb3VyY2MgPSBkcm1fZHJpdmVyX2NvbG9yX21vZGVfZm9ybWF0
KGRldiwgYXJncy0+YnBwKTsKLQlpZiAoZm91cmNjID09IERSTV9GT1JNQVRfSU5WQUxJRCkK
LQkJcmV0dXJuIC1FSU5WQUw7Ci0JaW5mbyA9IGRybV9mb3JtYXRfaW5mbyhmb3VyY2MpOwot
CWlmICghaW5mbykKLQkJcmV0dXJuIC1FSU5WQUw7Ci0JcGl0Y2ggPSBkcm1fZm9ybWF0X2lu
Zm9fbWluX3BpdGNoKGluZm8sIDAsIGFyZ3MtPndpZHRoKTsKKwlpZiAoZm91cmNjICE9IERS
TV9GT1JNQVRfSU5WQUxJRCkgeworCQljb25zdCBzdHJ1Y3QgZHJtX2Zvcm1hdF9pbmZvICpp
bmZvID0gZHJtX2Zvcm1hdF9pbmZvKGZvdXJjYyk7CisKKwkJaWYgKCFpbmZvKQorCQkJcmV0
dXJuIC1FSU5WQUw7CisJCXBpdGNoID0gZHJtX2Zvcm1hdF9pbmZvX21pbl9waXRjaChpbmZv
LCAwLCBhcmdzLT53aWR0aCk7CisJfSBlbHNlIGlmIChhcmdzLT5icHApIHsKKwkJLyoKKwkJ
ICogU29tZSB1c2Vyc3BhY2UgdGhyb3dzIGluIGFyYml0cmFyeSB2YWx1ZXMgZm9yIGJwcCBh
bmQKKwkJICogcmVsaWVzIG9uIHRoZSBrZXJuZWwgdG8gZmlndXJlIGl0IG91dC4gSW4gdGhp
cyBjYXNlIHdlCisJCSAqIGZhbGwgYmFjayB0byB0aGUgb2xkIG1ldGhvZCBvZiB1c2luZyBi
cHAgZGlyZWN0bHkuCisJCSAqLworCQlkcm1fd2FybihkZXYsICJVbmtub3duIGNvbG9yIG1v
ZGUgJWQ7IGd1ZXNzaW5nIGJ1ZmZlciBzaXplLlxuIiwgYXJncy0+YnBwKTsKKwkJaWYgKGFy
Z3MtPmJwcCA8IDgpCisJCQlwaXRjaCA9IERJVl9ST1VORF9VUChhcmdzLT53aWR0aCAqIGFy
Z3MtPmJwcCwgU1pfOCk7CisJCWVsc2UKKwkJCXBpdGNoID0gYXJncy0+d2lkdGggKiBESVZf
Uk9VTkRfVVAoYXJncy0+YnBwLCBTWl84KTsKKwl9CisKIAlpZiAoIXBpdGNoIHx8IHBpdGNo
ID4gVTMyX01BWCkKIAkJcmV0dXJuIC1FSU5WQUw7CiAKLS0gCjIuNDcuMQoK

--------------Ak8c05R8qA0Bhl3CK6SC6vGZ--


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 13:29:08 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 13:29:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869508.1280940 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWF4T-0000zG-5G; Fri, 10 Jan 2025 13:29:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869508.1280940; Fri, 10 Jan 2025 13:29:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWF4S-0000yP-UJ; Fri, 10 Jan 2025 13:29:04 +0000
Received: by outflank-mailman (input) for mailman id 869508;
 Fri, 10 Jan 2025 13:29:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=mmVM=UC=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tWF4S-0000vX-1b
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 13:29:04 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id db40feb3-cf56-11ef-99a4-01e77a169b0f;
 Fri, 10 Jan 2025 14:29:02 +0100 (CET)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-5d3d2a30afcso3398579a12.3
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 05:29:02 -0800 (PST)
Received: from localhost.localdomain ([66.81.170.107])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d9900c98d6sm1589297a12.35.2025.01.10.05.29.00
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 10 Jan 2025 05:29:01 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: db40feb3-cf56-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736515742; x=1737120542; 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=bRQNfKsuvZw+nxO+9fRaGgM5v8xaStyagtWnmxEhbWE=;
        b=M94DQGGKuHNJfq3/ovUirZDCRE6qK/dMMVbdXWjbWclr6RUFwJI3/HKN+s5zNAHMCR
         e/1zisUbrIjspv0DrWEEbHSfFOHwvE4c1TokIHYE71v8kC+H9Pu5H93fQ9sYKzRizSL1
         yhldldxeJVkuBUU70rm3zBVQILnb4Q7SXDuII=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736515742; x=1737120542;
        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=bRQNfKsuvZw+nxO+9fRaGgM5v8xaStyagtWnmxEhbWE=;
        b=Xxc15VoanBE0k5fWLZ0KoRgz45HMKDiMOvwzOLgMnIM4RoaOkusKnZr4xCXXbYhXwL
         0WpZU9J6vW88nPrEQb4FtLaLUQxfAcsfBST2ZW4ga+Uqg6LJrxPh4XJxd5SNbhYBpTs4
         yOa08K0RzWtmeSdJmpgjyW6RVuf5fr2SJSEAcyvXIYrvcjW5N3RQRt9Eyy1PRZQclFw6
         qAWVFD5R62L6JmKHut/Orlo8sMpYnR43TD7i/bviGZXs32h5EpBqZU1cvEN5HmOEKHqv
         acNTyRX7eG6SJLcCimgUSUsQXVUkXlsFCXhxOLG8aHntUdp7Zd5C8swN4pBBJImvA3WE
         YCFg==
X-Gm-Message-State: AOJu0YwwguwnBoS4XOG+l+hDB1MUayoMkNbkfjB5cxtGRkWTHi2KLTNK
	CnIk3kC/NAwnQ+ULVSOKqpD3YF9PAxjhQsc0tVJPvG2P9B4raRqzE0XZtymYkf6QMkpIMU79zUV
	fGUkVKA==
X-Gm-Gg: ASbGncvsFVJcDrNUg1rtIh4Lwwy9M4+oXEZfc6mjPp8ji+yoVCQ1K9Fn/ZWySkEFlyZ
	c0ew44Fu+x0mSikaDZGlY9PmkHhvPP6Nn6tfB3/F8a56lXsJ+bCE1VJJk1sEUFe8wS04lK3/FU6
	9ibmJrgcaSn/gUjedFPdjbPXUP6dY4tQNe8iMw0V7FST6D6Vv/MeGuLKFJ5IvJNaITAZbm6Lwzw
	y5UreXJVQgqMk3ztovtt47u08vAsWp4UBMpeNTanXWibfQ8DVeUO18N2I6CIetYH0FUWB0aDWOa
	WPA=
X-Google-Smtp-Source: AGHT+IGyXX40MA98jKr2GDP3/U+a3JZgqNiBAzNjjB3AtjN0x38sMjEg0t46Ben6q3KxCJNyi6FbXg==
X-Received: by 2002:a05:6402:50c9:b0:5d9:a61:e7c9 with SMTP id 4fb4d7f45d1cf-5d972e1bf6fmr9811622a12.20.1736515741680;
        Fri, 10 Jan 2025 05:29:01 -0800 (PST)
From: Alejandro Vallejo <alejandro.vallejo@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Alejandro Vallejo <alejandro.vallejo@cloud.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PATCH v3 01/12] x86/xstate: Create map/unmap primitives for xsave areas
Date: Fri, 10 Jan 2025 13:28:12 +0000
Message-ID: <20250110132823.24348-2-alejandro.vallejo@cloud.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250110132823.24348-1-alejandro.vallejo@cloud.com>
References: <20250110132823.24348-1-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Add infrastructure to simplify ASI handling. With ASI in the picture
we'll have several different means of accessing the XSAVE area of a
given vCPU, depending on whether a domain is covered by ASI or not and
whether the vCPU is question is scheduled on the current pCPU or not.

Having these complexities exposed at the call sites becomes unwieldy
very fast. These wrappers are intended to be used in a similar way to
map_domain_page() and unmap_domain_page(); The map operation will
dispatch the appropriate pointer for each case in a future patch, while
unmap will remain a no-op where no unmap is required (e.g: when there's
no ASI) and remove the transient maping if one was required.

Follow-up patches replace all uses of raw v->arch.xsave_area by this
mechanism in preparation to add the beforementioned dispatch logic to be
added at a later time.

Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
---
v2->v3:
  * Evaluate `v` in UNMAP (casted to void)

v1->v2:
  * Comment macros more heavily to show their performance characteristics.
  * Addressed various nits in the macro comments.
  * Macro names to uppercase.
---
 xen/arch/x86/include/asm/xstate.h | 42 +++++++++++++++++++++++++++++++
 1 file changed, 42 insertions(+)

diff --git a/xen/arch/x86/include/asm/xstate.h b/xen/arch/x86/include/asm/xstate.h
index 07017cc4edfd..ab81a4c8527e 100644
--- a/xen/arch/x86/include/asm/xstate.h
+++ b/xen/arch/x86/include/asm/xstate.h
@@ -143,4 +143,46 @@ static inline bool xstate_all(const struct vcpu *v)
            (v->arch.xcr0_accum & XSTATE_LAZY & ~XSTATE_FP_SSE);
 }
 
+/*
+ * Fetch a pointer to a vCPU's XSAVE area
+ *
+ * TL;DR: If v == current, the mapping is guaranteed to already exist.
+ *
+ * Despite the name, this macro might not actually map anything. The only case
+ * in which a mutation of page tables is strictly required is when ASI==on &&
+ * v!=current. For everything else the mapping already exists and needs not
+ * be created nor destroyed.
+ *
+ *                         +-----------------+--------------+
+ *                         |   v == current  | v != current |
+ *          +--------------+-----------------+--------------+
+ *          | ASI  enabled | per-vCPU fixmap |  actual map  |
+ *          +--------------+-----------------+--------------+
+ *          | ASI disabled |             directmap          |
+ *          +--------------+--------------------------------+
+ *
+ * There MUST NOT be outstanding maps of XSAVE areas of the non-current vCPU
+ * at the point of context switch. Otherwise, the unmap operation will
+ * misbehave.
+ *
+ * TODO: Expand the macro to the ASI cases after infra to do so is in place.
+ *
+ * @param v Owner of the XSAVE area
+ */
+#define VCPU_MAP_XSAVE_AREA(v) ((v)->arch.xsave_area)
+
+/*
+ * Drops the mapping of a vCPU's XSAVE area and nullifies its pointer on exit
+ *
+ * See VCPU_MAP_XSAVE_AREA() for additional information on the persistence of
+ * these mappings. This macro only tears down the mappings in the ASI=on &&
+ * v!=current case.
+ *
+ * TODO: Expand the macro to the ASI cases after infra to do so is in place.
+ *
+ * @param v Owner of the XSAVE area
+ * @param x XSAVE blob of v
+ */
+#define VCPU_UNMAP_XSAVE_AREA(v, x) do { (void)(v); (x) = NULL; } while(0)
+
 #endif /* __ASM_XSTATE_H */
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Fri Jan 10 13:29:08 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 13:29:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869507.1280933 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWF4S-0000w5-QE; Fri, 10 Jan 2025 13:29:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869507.1280933; Fri, 10 Jan 2025 13:29:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWF4S-0000vy-N4; Fri, 10 Jan 2025 13:29:04 +0000
Received: by outflank-mailman (input) for mailman id 869507;
 Fri, 10 Jan 2025 13:29:02 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=mmVM=UC=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tWF4Q-0000vX-Jk
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 13:29:02 +0000
Received: from mail-ed1-x541.google.com (mail-ed1-x541.google.com
 [2a00:1450:4864:20::541])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id da23ab63-cf56-11ef-99a4-01e77a169b0f;
 Fri, 10 Jan 2025 14:29:00 +0100 (CET)
Received: by mail-ed1-x541.google.com with SMTP id
 4fb4d7f45d1cf-5d3e6274015so3281327a12.0
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 05:29:00 -0800 (PST)
Received: from localhost.localdomain ([66.81.170.107])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d9900c98d6sm1589297a12.35.2025.01.10.05.28.58
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 10 Jan 2025 05:28:58 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: da23ab63-cf56-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736515740; x=1737120540; 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=STJ6EDqaoVOMf2y2CPJp64NZSY2YgtDzimzb+ttUHDw=;
        b=fitzvgooHil/8fPTDgsMud1z+G5LvW9Tjw/GCZ9uEGKVGHIUnYxooFDtcYf6JT/LWv
         RW+isD7gdUjy2TFMISOAwq2ZASDGIK9LneCKSkM1fAA6TZiq2GDa/52QRqBS1f8vP1yG
         By/IXzxRUZK4iUQr+kAV6CMtRDspzF6Ap3Qxg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736515740; x=1737120540;
        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=STJ6EDqaoVOMf2y2CPJp64NZSY2YgtDzimzb+ttUHDw=;
        b=t3kTXopWNdkYLayVoMzJgbfPf0ERKepBx9gGS5MKdDtPPZq+5JwLnV8Hcad2tdkFig
         zaTWznikp7l+1xLp5/TxMVjRwxPTHZNmGVW3iIUepSl6Va8i2Fv34Qsaw5RKQMTWVJot
         kTW2rU/QtSi4Fj7k3VL6D+XAsHlJ0wxp7Use7TUG4GkHhsOujrzSzhLnUPJ0c/9+W1Ip
         kxzsFWSPC+Ki6pbCnVqKSUJ6mzOvdwekgWizuXokZovvujPDh218iCzC6l69VsIendA/
         tNv43B8zBOv9eNxc22Ur1P0EcR0REEk+9SL1fzxagZqMmX8wgPPGbMHWMqiOGOnDb0ln
         F+Yg==
X-Gm-Message-State: AOJu0YwuENHQ9U0DGp8ISBEpOjZ0clGaY3cX2wXQBkPkfKWyZphWdKWv
	t/3MLsHnaNaj2cO5QkFujh3kARvJWKhBWrUqJYQFrfd/zawRHw3f+vTqaegIv8bk72FQeC6CpqV
	Lcq3wG7b3
X-Gm-Gg: ASbGncuthA2u+Nf9FvvsWx0mjBxruO1asyG4EoPkeAjeLyaqzDNQZJkIEWINrl1KcJH
	8guT5ORaNfN7VrNZnws59yOip3h6wVM1NccU2DXj3m8VbwDdLN7/gLtifFoiZt4CL6MpIyQd2NW
	11Q6LTzUyTutsf18+1SqRCdwD/ZdCkRpp6OpEvYD2WUZl+y160zNMSMFfFM+GI96MScyaxyqAI5
	6oxlTlptdOBdyjVoPWgHN3IlD34/DN3O60HezsqY9pPS2d2zffYfjH03n/RRfkR34OKwkiAbejN
	W34=
X-Google-Smtp-Source: AGHT+IFh7Thg1UKXjZPRM5dqlSIZHRmH77Q8K0fYsEOJfpRPNyLE5ktp21z4O1Yq+UbhSwH4K1dWwA==
X-Received: by 2002:a05:6402:2813:b0:5d2:8f70:75f6 with SMTP id 4fb4d7f45d1cf-5d972e6f089mr10686180a12.30.1736515739899;
        Fri, 10 Jan 2025 05:28:59 -0800 (PST)
From: Alejandro Vallejo <alejandro.vallejo@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Alejandro Vallejo <alejandro.vallejo@cloud.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PATCH v3 00/12] x86: Address Space Isolation FPU preparations
Date: Fri, 10 Jan 2025 13:28:11 +0000
Message-ID: <20250110132823.24348-1-alejandro.vallejo@cloud.com>
X-Mailer: git-send-email 2.47.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

See original cover letter in v1

v2: https://lore.kernel.org/xen-devel/20241105143310.28301-1-alejandro.vallejo@cloud.com/
v2->v3:
  * Evaluated `v` argument in UNMAP operation (see patch 1)
  * Fixed bug on (de)compressing xstates by not unmapping them on early return.
  * Constified more when converting (f)xrstor and (f)xsave

v1: https://lore.kernel.org/xen-devel/20241028154932.6797-1-alejandro.vallejo@cloud.com/
v1->v2:
  * Turned v1/patch1 into an assert removal
  * Dropped v1/patch11: "x86/mpx: Adjust read_bndcfgu() to clean after itself"
  * Other minor changes out of feedback. Explained in each patch.

Alejandro Vallejo (12):
  x86/xstate: Create map/unmap primitives for xsave areas
  x86/hvm: Map/unmap xsave area in hvm_save_cpu_ctxt()
  x86/fpu: Map/umap xsave area in vcpu_{reset,setup}_fpu()
  x86/xstate: Map/unmap xsave area in xstate_set_init() and
    handle_setbv()
  x86/hvm: Map/unmap xsave area in hvmemul_{get,put}_fpu()
  x86/domctl: Map/unmap xsave area in arch_get_info_guest()
  x86/xstate: Map/unmap xsave area in {compress,expand}_xsave_states()
  x86/emulator: Refactor FXSAVE_AREA to use wrappers
  x86/mpx: Map/unmap xsave area in in read_bndcfgu()
  x86/fpu: Pass explicit xsave areas to fpu_(f)xsave()
  x86/fpu: Pass explicit xsave areas to fpu_(f)xrstor()
  x86/xstate: Make xstate_all() and vcpu_xsave_mask() take explicit
    xstate

 xen/arch/x86/domctl.c             |  9 ++--
 xen/arch/x86/hvm/emulate.c        | 12 +++++-
 xen/arch/x86/hvm/hvm.c            |  8 ++--
 xen/arch/x86/i387.c               | 69 ++++++++++++++++++++-----------
 xen/arch/x86/include/asm/xstate.h | 51 +++++++++++++++++++++--
 xen/arch/x86/x86_emulate/blk.c    | 11 ++++-
 xen/arch/x86/xstate.c             | 53 +++++++++++++++++-------
 7 files changed, 157 insertions(+), 56 deletions(-)

-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Fri Jan 10 13:29:10 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 13:29:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869509.1280952 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWF4Y-0001Rq-Dc; Fri, 10 Jan 2025 13:29:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869509.1280952; Fri, 10 Jan 2025 13:29:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWF4Y-0001Rj-AM; Fri, 10 Jan 2025 13:29:10 +0000
Received: by outflank-mailman (input) for mailman id 869509;
 Fri, 10 Jan 2025 13:29:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=mmVM=UC=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tWF4X-0001QR-3K
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 13:29:09 +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 de97cd0e-cf56-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 14:29:08 +0100 (CET)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-5d4e2aa7ea9so3927428a12.2
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 05:29:08 -0800 (PST)
Received: from localhost.localdomain ([66.81.170.107])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d9900c98d6sm1589297a12.35.2025.01.10.05.29.04
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 10 Jan 2025 05:29:05 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: de97cd0e-cf56-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736515747; x=1737120547; 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=S28ujRidgdqsUo8KctrJ2mFUS3eNRL5DEkXV5XiQbS4=;
        b=QKaeRnlOYPQCiNTgTugLWYvK8SKLLF7nOu+ApIO6eKY1hjVV7CxmMTGOV8rmT/4RQg
         VAhoeK/uM94PIIsw8XxTCiH6t/bxmCmqjP3Bifxe3EdoR1pUFf3wTrH8GGjCAMkb2m+r
         U2NdnL3G2YzvaCQBiqiohu7oBB417DmTNzCxI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736515747; x=1737120547;
        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=S28ujRidgdqsUo8KctrJ2mFUS3eNRL5DEkXV5XiQbS4=;
        b=mVNFu+M0063MCVDYq5IsIVsPP5TLqPOBD+m2+5sMBYXMQRprr7NOLIzXwQ9hPFXfW8
         ZdunpgESmgyit53PhK68dQ4dvJFPvfdHrxK9Z6MzhVdhAA+clerCnHrEJq/I6SGOmjZc
         BItYaITYhOy4vnntvSevM13cGRUa8IJhOu3CBZ5/8rxwHkRkrfCRNqLK3d9my1A+ZOCa
         11pUROiEOceU6r38iON2cbaDC5pghB7AIdQx3PUA+QVAqWQT31KlQClGd9GVUGrjPZYy
         o5aGXFt05/2y7sGjyHD8+b5nV523CIvFvstwh3Zim30r9zz7ar6ZWSdeJel7zW0ML/as
         3Tmg==
X-Gm-Message-State: AOJu0YyZw/WL4CxeGZTPcqx+RFq5Wksc76ck7kgbIEayA55YU3hydaeV
	4RXdAXNd5k3IoOOjxK4kYiRr5T+xn98JTlOF1OtB4co1k0Hq+nxKiMgmm/L8093WHD+omJZNpPd
	2uH66jA==
X-Gm-Gg: ASbGncvm7lks88ic0Ku5iC+j3+XC/5Kfx0cwPGsJn/u09glFAh1tS3L26gQGK4KO6HR
	YIvI2mjoSuDH3p4yBikhMDAIRTmmBXMUlos2t+9eyVN+yyxFUnqewAEAzDerLjCyAPk4OsThybv
	NqIKpVhE5FAPcKgwvhqmNSrc20BlkaxeKE+5bpb0NMKOST+I9yuwzmjvR8U05CrQrigm7K7UMfK
	RVYORzMEQkbUDPWfPTbqddvEtPqKYr9Lf1v+G3TRHT7K+UAp6o8P6GOkLd3ZxRQjFiGRMKPkdHa
	gy4=
X-Google-Smtp-Source: AGHT+IHo0flgxzQJnpbc2JNOLtTwppT7VEX9vUmyga15KAzYVXXS0m2eQk3iDaRnwtsq76u6Qp3rQw==
X-Received: by 2002:a05:6402:194e:b0:5d8:211a:4d59 with SMTP id 4fb4d7f45d1cf-5d972e178e1mr10632908a12.19.1736515745814;
        Fri, 10 Jan 2025 05:29:05 -0800 (PST)
From: Alejandro Vallejo <alejandro.vallejo@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Alejandro Vallejo <alejandro.vallejo@cloud.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PATCH v3 02/12] x86/hvm: Map/unmap xsave area in hvm_save_cpu_ctxt()
Date: Fri, 10 Jan 2025 13:28:13 +0000
Message-ID: <20250110132823.24348-3-alejandro.vallejo@cloud.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250110132823.24348-1-alejandro.vallejo@cloud.com>
References: <20250110132823.24348-1-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

No functional change.

Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
v2->v3:
  * Added A-by

v1->v2:
  * No change
---
 xen/arch/x86/hvm/hvm.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 922c9b3af64d..884b2b9d32cd 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -914,11 +914,11 @@ static int cf_check hvm_save_cpu_ctxt(struct vcpu *v, hvm_domain_context_t *h)
 
     if ( v->fpu_initialised )
     {
-        BUILD_BUG_ON(sizeof(ctxt.fpu_regs) !=
-                     sizeof(v->arch.xsave_area->fpu_sse));
-        memcpy(ctxt.fpu_regs, &v->arch.xsave_area->fpu_sse,
-               sizeof(ctxt.fpu_regs));
+        const struct xsave_struct *xsave_area = VCPU_MAP_XSAVE_AREA(v);
 
+        BUILD_BUG_ON(sizeof(ctxt.fpu_regs) != sizeof(xsave_area->fpu_sse));
+        memcpy(ctxt.fpu_regs, &xsave_area->fpu_sse, sizeof(ctxt.fpu_regs));
+        VCPU_UNMAP_XSAVE_AREA(v, xsave_area);
         ctxt.flags = XEN_X86_FPU_INITIALISED;
     }
 
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Fri Jan 10 13:29:12 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 13:29:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869511.1280963 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWF4a-0001it-Ly; Fri, 10 Jan 2025 13:29:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869511.1280963; Fri, 10 Jan 2025 13:29:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWF4a-0001ii-If; Fri, 10 Jan 2025 13:29:12 +0000
Received: by outflank-mailman (input) for mailman id 869511;
 Fri, 10 Jan 2025 13:29:10 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=mmVM=UC=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tWF4Y-0001QR-RH
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 13:29:10 +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 dfe7a059-cf56-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 14:29:10 +0100 (CET)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-5d0ac27b412so2537670a12.1
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 05:29:10 -0800 (PST)
Received: from localhost.localdomain ([66.81.170.107])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d9900c98d6sm1589297a12.35.2025.01.10.05.29.07
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 10 Jan 2025 05:29:09 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: dfe7a059-cf56-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736515749; x=1737120549; 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=5O7gLemGUf6JN5FF2lKFWWHjDWg3G1VdwWkZcZUgbRo=;
        b=H+3rDaSRoJ9qfFjKCevTO9Db2au3aLeL3PSMeJGGENCB2svThvFz6H77i906SZF1tj
         flMU2CvdS1XcpQb0sWnu5TQSZDXblQRMMdb1Cn650KEGkda9GsuoPGqVdYQx6ZRRb0mp
         Eck0ivjrA9CJRFAOIC9LpKYtX+PIEmGw/eY8g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736515749; x=1737120549;
        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=5O7gLemGUf6JN5FF2lKFWWHjDWg3G1VdwWkZcZUgbRo=;
        b=DOLvvUVE7w+qJa2HJCgrHnB7PchQ8003xmaU93EZeOD6ydJCIO6SCVBana7n9BRvaY
         9uFnZ/Bolisb0G+aIDXdNfY+1faJH645xLx43+GyIv36fhTyAXqNfL/rOoKlQTAlaw5B
         AD5dmREDpLZP1t0P9LHWjT1J6VN6eWij7hM9nfzsOJTqYW+UH4b52T6jfxPWmZ/vzElQ
         K3JDyiRGgieUtFtIkpxV+5PMbnMf5SoN51fu/KTvY8063t/ilsRfoWOacIwqM5m5aV6R
         UCdv4FCknliuNcxNEjMwa9W3n1gxbFYtb6517Rp4j99/XnZ3aqvf6tXnDcYaChtifJ7C
         UTBw==
X-Gm-Message-State: AOJu0Yyadct4GtAKXBF/i66+vxI5pvgo2UVdfkYvjTiqTb0cCzOAKTTl
	NCLinBwqFdBrvlczabjY0NkuVbu0BYHy7fwYSiWU06AD4r2mkH/R1VDqCMV9iT/zJN+aUbw72+l
	qaCaVEA==
X-Gm-Gg: ASbGncupgDhCzJvAWLqJ7oPTlBL5bk4hMHGnb9KHRwkylvdq49+ZlFhnEK8rn0Wzu3k
	srl7GRwowqQfuyLGUK+XId3j9dZB5NL6dcDJIUjvCQEA1cR6lLGWpviExqIv9tALQQyHvUporEj
	hC0ybO9MURVDZLPtFvfY5OPxMBCS+3x8/mHHlDQLhVMhkPSSea0iJuYZnxoMyiw1k4XjQhFUUis
	ZVU22YlOBdezuvYnXpWeC5Z0/MVsMzQyBTa6Vxf8oe7QaS9QlyRHAyJELA3Oz60cVK271Y6FdM7
	aew=
X-Google-Smtp-Source: AGHT+IFDwVTKHs3K2kJcgyqa3q8O7JLMmDZootiHiSvxM+9IOV5nU8oJOp9UKXOkmTk4hp/wvl9+qw==
X-Received: by 2002:a05:6402:5243:b0:5d9:b84:a01f with SMTP id 4fb4d7f45d1cf-5d972e169a3mr10438762a12.18.1736515749503;
        Fri, 10 Jan 2025 05:29:09 -0800 (PST)
From: Alejandro Vallejo <alejandro.vallejo@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Alejandro Vallejo <alejandro.vallejo@cloud.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PATCH v3 03/12] x86/fpu: Map/umap xsave area in vcpu_{reset,setup}_fpu()
Date: Fri, 10 Jan 2025 13:28:14 +0000
Message-ID: <20250110132823.24348-4-alejandro.vallejo@cloud.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250110132823.24348-1-alejandro.vallejo@cloud.com>
References: <20250110132823.24348-1-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

No functional change.

Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
v2->v3:
  * Added A-by

v1->v2:
  * No change
---
 xen/arch/x86/i387.c | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/i387.c b/xen/arch/x86/i387.c
index 8fba0aef4284..5429531ddd5f 100644
--- a/xen/arch/x86/i387.c
+++ b/xen/arch/x86/i387.c
@@ -304,24 +304,32 @@ int vcpu_init_fpu(struct vcpu *v)
 
 void vcpu_reset_fpu(struct vcpu *v)
 {
+    struct xsave_struct *xsave_area = VCPU_MAP_XSAVE_AREA(v);
+
     v->fpu_initialised = false;
-    *v->arch.xsave_area = (struct xsave_struct) {
+    *xsave_area = (struct xsave_struct) {
         .xsave_hdr.xstate_bv = X86_XCR0_X87,
     };
 
     /* Old gcc doesn't permit these to be part of the initializer. */
-    v->arch.xsave_area->fpu_sse.mxcsr = MXCSR_DEFAULT;
-    v->arch.xsave_area->fpu_sse.fcw = FCW_RESET;
-    v->arch.xsave_area->fpu_sse.ftw = FXSAVE_FTW_RESET;
+    xsave_area->fpu_sse.mxcsr = MXCSR_DEFAULT;
+    xsave_area->fpu_sse.fcw = FCW_RESET;
+    xsave_area->fpu_sse.ftw = FXSAVE_FTW_RESET;
+
+    VCPU_UNMAP_XSAVE_AREA(v, xsave_area);
 }
 
 void vcpu_setup_fpu(struct vcpu *v, const void *data)
 {
+    struct xsave_struct *xsave_area = VCPU_MAP_XSAVE_AREA(v);
+
     v->fpu_initialised = true;
-    *v->arch.xsave_area = (struct xsave_struct) {
+    *xsave_area = (struct xsave_struct) {
         .fpu_sse = *(const fpusse_t*)data,
         .xsave_hdr.xstate_bv = XSTATE_FP_SSE,
     };
+
+    VCPU_UNMAP_XSAVE_AREA(v, xsave_area);
 }
 
 /* Free FPU's context save area */
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Fri Jan 10 13:29:15 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 13:29:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869512.1280973 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWF4d-00020i-0f; Fri, 10 Jan 2025 13:29:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869512.1280973; Fri, 10 Jan 2025 13:29:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWF4c-00020W-Qs; Fri, 10 Jan 2025 13:29:14 +0000
Received: by outflank-mailman (input) for mailman id 869512;
 Fri, 10 Jan 2025 13:29: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
 <SRS0=mmVM=UC=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tWF4a-0000vX-RM
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 13:29:12 +0000
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com
 [2a00:1450:4864:20::52f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e0812746-cf56-11ef-99a4-01e77a169b0f;
 Fri, 10 Jan 2025 14:29:11 +0100 (CET)
Received: by mail-ed1-x52f.google.com with SMTP id
 4fb4d7f45d1cf-5d4e2aa7ea9so3927504a12.2
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 05:29:11 -0800 (PST)
Received: from localhost.localdomain ([66.81.170.107])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d9900c98d6sm1589297a12.35.2025.01.10.05.29.09
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 10 Jan 2025 05:29:10 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e0812746-cf56-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736515750; x=1737120550; 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=Pulx2rJf+eVHBhVEkVLX9BFreaZxFXyF8Is/s9m9sX8=;
        b=L9dv5+jwFLfSlTaXGdnHHqRHWnGd3jiAk6zju2d3S5GCRblIWX6ac+w38Gcj+/kZ62
         EcJy/citFUjUzgVOONMRoljKPJvuyO3aizYfKJPHqkUo1wca7LZKS0pk+O3qG59NNtfI
         Mj0h28MA41aYqJFw4/tQmqEOjwEQZ4HvfPPxE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736515750; x=1737120550;
        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=Pulx2rJf+eVHBhVEkVLX9BFreaZxFXyF8Is/s9m9sX8=;
        b=GkepZzWOopzUomAy3R5v0JQ4H8tDOk7ZExvPDVFtXQFX0yNot8vQUJvGsWKVGVPvgc
         ktgMiuXDq4pI11k62xRS9W+0LMv7dajqV/D6TryfGXRaSXM6oFSVZMvv8h4kiBDo9EKo
         qU02jtv7cLpHDkKk1rlJeR9dM+jIfs1bmX3bHR2VQE/p8vp5XGUO+TtjVmjLYTwL1oIe
         2jy0M5CkO9PqmyaSUxqb9Mbx0+NpdKYJG6KmFpEtPyRWOLO3zsLlKvxbldDZjxczJSoz
         HWEXhL1SlnKTMS24KWgsvODZoZGXn+aIninBTddIyLVQFskQ89kAfSuJMFvtCTr6clQg
         q7jA==
X-Gm-Message-State: AOJu0Yyrl7TL+64/VjY10KI9NabR/vLp6VxSNDUVCzzrJoyPKBKFLV2k
	9T9ivMo8QXgq5fZ8nOxU+CBauBG47SK2hnEiQz96Yd8RRaF//x6CpM3yOx3bKwLUEppQkfNYOIp
	W4ghZZg==
X-Gm-Gg: ASbGncuNpCs6tce9ELJ8eYuhct55+oJCg0Wcqw8ajQo/FobBZc+KmnfrEioRgSb/j18
	oK2nHqQ/847vM5s3oJjWBluUoxgiugb133DCe7aIlUSS/qF7fuvAZdy4dsRpFc6KJje11eHJO0l
	p2uUzcMJvrjg9naRsWCppF8g7DyuPpnU6bo2lriVluZQShrL8ZWw18jXb+515pxqTFwwXd/4B0Y
	u1f2m581gsC9Etru8kaXjR76fJvtdoY/WCR9BBeL5ltsQ/4TA53j++xNepj2aI0rrO4e0eO6te4
	YTo=
X-Google-Smtp-Source: AGHT+IH/zIJhlFB//h5vV6Zg10dAMqVvYLHKKDAVfZ79wH6CqKU5mgDtC7kYIG7zl3p84Kdgmv0bnA==
X-Received: by 2002:a05:6402:5244:b0:5d0:8197:7ab3 with SMTP id 4fb4d7f45d1cf-5d972dfb878mr10087008a12.3.1736515750544;
        Fri, 10 Jan 2025 05:29:10 -0800 (PST)
From: Alejandro Vallejo <alejandro.vallejo@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Alejandro Vallejo <alejandro.vallejo@cloud.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PATCH v3 04/12] x86/xstate: Map/unmap xsave area in xstate_set_init() and handle_setbv()
Date: Fri, 10 Jan 2025 13:28:15 +0000
Message-ID: <20250110132823.24348-5-alejandro.vallejo@cloud.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250110132823.24348-1-alejandro.vallejo@cloud.com>
References: <20250110132823.24348-1-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

No functional change.

Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
v2->v3:
  * style: Capitalized first letter of the comment.
  * Added A-by

v1->v2:
  * Added comment highlighting fastpath for current
---
 xen/arch/x86/xstate.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c
index af9e345a7ace..12004d7db24b 100644
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86/xstate.c
@@ -993,7 +993,13 @@ int handle_xsetbv(u32 index, u64 new_bv)
 
         clts();
         if ( curr->fpu_dirtied )
-            asm ( "stmxcsr %0" : "=m" (curr->arch.xsave_area->fpu_sse.mxcsr) );
+        {
+            /* Has a fastpath for `current`, so there's no actual map */
+            struct xsave_struct *xsave_area = VCPU_MAP_XSAVE_AREA(curr);
+
+            asm ( "stmxcsr %0" : "=m" (xsave_area->fpu_sse.mxcsr) );
+            VCPU_UNMAP_XSAVE_AREA(curr, xsave_area);
+        }
         else if ( xstate_all(curr) )
         {
             /* See the comment in i387.c:vcpu_restore_fpu_eager(). */
@@ -1048,7 +1054,7 @@ void xstate_set_init(uint64_t mask)
     unsigned long cr0 = read_cr0();
     unsigned long xcr0 = this_cpu(xcr0);
     struct vcpu *v = idle_vcpu[smp_processor_id()];
-    struct xsave_struct *xstate = v->arch.xsave_area;
+    struct xsave_struct *xstate;
 
     if ( ~xfeature_mask & mask )
     {
@@ -1061,8 +1067,10 @@ void xstate_set_init(uint64_t mask)
 
     clts();
 
+    xstate = VCPU_MAP_XSAVE_AREA(v);
     memset(&xstate->xsave_hdr, 0, sizeof(xstate->xsave_hdr));
     xrstor(v, mask);
+    VCPU_UNMAP_XSAVE_AREA(v, xstate);
 
     if ( cr0 & X86_CR0_TS )
         write_cr0(cr0);
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Fri Jan 10 13:29:15 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 13:29:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869513.1280978 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWF4d-000243-Aw; Fri, 10 Jan 2025 13:29:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869513.1280978; Fri, 10 Jan 2025 13:29:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWF4d-00023B-5R; Fri, 10 Jan 2025 13:29:15 +0000
Received: by outflank-mailman (input) for mailman id 869513;
 Fri, 10 Jan 2025 13:29: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
 <SRS0=mmVM=UC=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tWF4b-0000vX-Te
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 13:29:13 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e125b8e4-cf56-11ef-99a4-01e77a169b0f;
 Fri, 10 Jan 2025 14:29:12 +0100 (CET)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-5d41848901bso3788211a12.0
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 05:29:12 -0800 (PST)
Received: from localhost.localdomain ([66.81.170.107])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d9900c98d6sm1589297a12.35.2025.01.10.05.29.10
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 10 Jan 2025 05:29:11 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e125b8e4-cf56-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736515751; x=1737120551; 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=zUEO9205Bbujlvio/njapuGkmXsktum9lbTR3dku2CE=;
        b=hZO6ExnZGiX60aGYwqM1OiTBkheEI5vkDcgkTdmjcz2FHxsxCcbxIneG7x+hpcb/jE
         7kL0lqhfU+rXmG3HZWcR/2bPZeGGLv2NsKRt/ijloECBwZ2Ypaq2JjR129ULDQCSFko2
         cHuE7Qn6Ni5B/lHknoi5GpsrEWarlUozyBvKc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736515751; x=1737120551;
        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=zUEO9205Bbujlvio/njapuGkmXsktum9lbTR3dku2CE=;
        b=XgIOfn98hPLq0Mpy/AZJILxpzQLsnCCJk3e1UlCgjKFfR8/d/xADfswc5yUwmLKQue
         HsZVS0LiYl8JFUpmVyH0uwp+00HrH7YGNOS47Cuoiaih8yMM8xWDBagVbUjDtwlo1qlu
         LG7HOKW8l/kngoxAfUJyub2kVO7WRH4bJ8a0XLdLQkHqN315FLcSMjV+wtzR6msoM0V3
         TPwhKZQXZ1PH3TlP+wCm5YN9blHkQcBpKtfdx0pN0JzH2zRDlr0SiBZrk+/oD2OOp4PW
         Eluqmw8HBP4VQU7FqqN3MoTL5mHYIuOOkMyjTivVyt1nwD75QZ//8B1Lb99Qj0pXx38K
         mvdg==
X-Gm-Message-State: AOJu0YxbHpuORyiPtSe9zs1NrCoF9bG0gsoR0h0ZyaP/lL0yUF2Uay8z
	F8iLInB2OvlMLdB927lklV6SvZXwqAC9GwCkfMjXkdUPhL/TXSWOuT+mQYau/QlOW0g+NSGqhsI
	+VUq6mg==
X-Gm-Gg: ASbGnctkcKa1r5ZNBqgXBeHEkijfuVgLzuLqYA8rATILSvxpPl/foqDCNvJyDLSKC+p
	ybbLj5HVmeE3+HDktJDNKh7vrTTvns4v94J0hb+2BvhBWIDH9KjT+4RVeqdyha6oVBSIsdLBkRL
	9T2AzDBqpjmcn3T7GfBDO1fsRRaNunB04PKaByG2dRwD2XIAktZDKRwWT4Uc3xkjfZy3b1FR7zx
	iGxYAzXruuk018D+e6DYFrECNKmu+2BRaXmFrlD/GcySShlbXq2jR0cOAj0ygXXEMwFZPlIAaFX
	njg=
X-Google-Smtp-Source: AGHT+IEoX1iZirm/9+11R/yAmKqYvTojFGbSSLXDzqpQe8R8iEbKo+oGFbWvaPWpr8T4NrAFe7KVoQ==
X-Received: by 2002:a05:6402:3506:b0:5d9:3118:d0b8 with SMTP id 4fb4d7f45d1cf-5d98a27dc65mr5164910a12.8.1736515751604;
        Fri, 10 Jan 2025 05:29:11 -0800 (PST)
From: Alejandro Vallejo <alejandro.vallejo@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Alejandro Vallejo <alejandro.vallejo@cloud.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PATCH v3 05/12] x86/hvm: Map/unmap xsave area in hvmemul_{get,put}_fpu()
Date: Fri, 10 Jan 2025 13:28:16 +0000
Message-ID: <20250110132823.24348-6-alejandro.vallejo@cloud.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250110132823.24348-1-alejandro.vallejo@cloud.com>
References: <20250110132823.24348-1-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

No functional change.

Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
v2->v3:
  * style: Capitalized first letter of the fastpath comment
  * Added A-by

v1->v2:
  * Added comments highlighting fastpath for current
---
 xen/arch/x86/hvm/emulate.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index a1935a174830..d5011612aff0 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -2371,7 +2371,9 @@ static int cf_check hvmemul_get_fpu(
         alternative_vcall(hvm_funcs.fpu_dirty_intercept);
     else if ( type == X86EMUL_FPU_fpu )
     {
-        const fpusse_t *fpu_ctxt = &curr->arch.xsave_area->fpu_sse;
+        /* Has a fastpath for `current`, so there's no actual map */
+        const struct xsave_struct *xsave_area = VCPU_MAP_XSAVE_AREA(curr);
+        const fpusse_t *fpu_ctxt = &xsave_area->fpu_sse;
 
         /*
          * Latch current register state so that we can back out changes
@@ -2397,6 +2399,8 @@ static int cf_check hvmemul_get_fpu(
             else
                 ASSERT(fcw == fpu_ctxt->fcw);
         }
+
+        VCPU_UNMAP_XSAVE_AREA(curr, xsave_area);
     }
 
     return X86EMUL_OKAY;
@@ -2411,7 +2415,9 @@ static void cf_check hvmemul_put_fpu(
 
     if ( aux )
     {
-        fpusse_t *fpu_ctxt = &curr->arch.xsave_area->fpu_sse;
+        /* Has a fastpath for `current`, so there's no actual map */
+        struct xsave_struct *xsave_area = VCPU_MAP_XSAVE_AREA(curr);
+        fpusse_t *fpu_ctxt = &xsave_area->fpu_sse;
         bool dval = aux->dval;
         int mode = hvm_guest_x86_mode(curr);
 
@@ -2467,6 +2473,8 @@ static void cf_check hvmemul_put_fpu(
 
         fpu_ctxt->fop = aux->op;
 
+        VCPU_UNMAP_XSAVE_AREA(curr, xsave_area);
+
         /* Re-use backout code below. */
         backout = X86EMUL_FPU_fpu;
     }
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Fri Jan 10 13:29:16 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 13:29:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869515.1280993 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWF4e-0002V4-OC; Fri, 10 Jan 2025 13:29:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869515.1280993; Fri, 10 Jan 2025 13:29:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWF4e-0002UF-Gm; Fri, 10 Jan 2025 13:29:16 +0000
Received: by outflank-mailman (input) for mailman id 869515;
 Fri, 10 Jan 2025 13:29: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
 <SRS0=mmVM=UC=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tWF4c-0000vX-TU
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 13:29:14 +0000
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
 [2a00:1450:4864:20::52e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e1b0135c-cf56-11ef-99a4-01e77a169b0f;
 Fri, 10 Jan 2025 14:29:13 +0100 (CET)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-5d7e3f1fdafso4034677a12.0
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 05:29:13 -0800 (PST)
Received: from localhost.localdomain ([66.81.170.107])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d9900c98d6sm1589297a12.35.2025.01.10.05.29.11
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 10 Jan 2025 05:29:12 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e1b0135c-cf56-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736515752; x=1737120552; 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=CCX/yh7HycpxvmfWA8KKNWXNQA4qbA28JEl6dZ92/5k=;
        b=eMgrfm00v/DfijO/Z7ZyU+vZPe5C3+0kl6btixzaSIiW5+8/Epbji/YTx9Lrg3UmvV
         M/DEqs/xw3X7deL6pUAoKQaYLtXzSRX7+aAAxeiGXTxbQ2CL5HjgccXj7WbAVy9LZHCh
         MvMoJlR8MMnmcrFDIpDaWAJleqjm3Dg2fvQI8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736515752; x=1737120552;
        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=CCX/yh7HycpxvmfWA8KKNWXNQA4qbA28JEl6dZ92/5k=;
        b=kqUIAPayeKjloHG4QXbKVYcAmFBtxeKJqdlc5Ma2fMhDleEVPmdLErLrQom1RJtC/b
         sOwkvcAjeZmxfGBm/YqHJjRvuroOzXsemw9miC4vJSawL+tRC9yf7GMbiyFIhRsPPLp2
         Akus6zCuHD93niO6obq0/xgD+I2Xml6pWEJSCzc5BTSqCjdbCQQKooTPB4eYTEuNjoCK
         XnCpC7d1lVjlcpMHd8bm45qRoxDD9MSWSceNVLaxzjYJH+NU0sNM04bPjEM01v5jhyBP
         Rsr8QNae4mbvjqwaGfrJry46+pKNzq7HfX9J+83TP2WekNNEvPXJOmoJxU5rZ0xF9pcC
         fO7A==
X-Gm-Message-State: AOJu0YykiBBpPCzMmBIyTzgHmdv2f0n1WmsVMJEo1Tl3Zh6w1fnXIxCQ
	CcUvfzE1X4gfXOo/QTOArJvXEhFRRyG8OA1gzD6aZdmLpsZNZ7F2KsXOczPg91+zVAJi/36B/+w
	gaFMwRg==
X-Gm-Gg: ASbGncu2/7ccdC/3V7MYmiO671v+GGjOTTox6Y2FQP3MiC7flBk3hh67sobrVQHS9ZL
	I0TGJ5a3idQEX4zruPt8OS4R0tKMQTCz+/bnq0ZUSCstZ6gTShukYNZHmoD1qikZrHZbdf5No2Q
	M8FlfIHDWRDFUWDSG0WYYEf2zz4BLEfIZXNUftqFWwZw3x/V+0jdP+vTeBVxTlqDoIMsZYaF4Aa
	midWl+Prq5JXmyEjvGxubWcEAn/rs5VbfE4y5yX1CH+yzQtI2k8CJu0RS9Kac58Vrc3/kAYnmiN
	JKQ=
X-Google-Smtp-Source: AGHT+IFt0+J+MzwzmdDfbFOmSHL+99J1n+bWPWq8Lzmmx0aBwjpOqjzKgIrvM+hZK/x8jYYJOdfbsA==
X-Received: by 2002:a05:6402:430c:b0:5d4:75b:8ced with SMTP id 4fb4d7f45d1cf-5d972e6bdf5mr9861162a12.32.1736515752585;
        Fri, 10 Jan 2025 05:29:12 -0800 (PST)
From: Alejandro Vallejo <alejandro.vallejo@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Alejandro Vallejo <alejandro.vallejo@cloud.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PATCH v3 06/12] x86/domctl: Map/unmap xsave area in arch_get_info_guest()
Date: Fri, 10 Jan 2025 13:28:17 +0000
Message-ID: <20250110132823.24348-7-alejandro.vallejo@cloud.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250110132823.24348-1-alejandro.vallejo@cloud.com>
References: <20250110132823.24348-1-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

No functional change.

Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
v1->v2:
  * Added A-by

v1->v2:
  * No change
---
 xen/arch/x86/domctl.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 5f01111619da..3044f706de1c 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1377,16 +1377,17 @@ void arch_get_info_guest(struct vcpu *v, vcpu_guest_context_u c)
     unsigned int i;
     const struct domain *d = v->domain;
     bool compat = is_pv_32bit_domain(d);
+    const struct xsave_struct *xsave_area;
 #ifdef CONFIG_COMPAT
 #define c(fld) (!compat ? (c.nat->fld) : (c.cmp->fld))
 #else
 #define c(fld) (c.nat->fld)
 #endif
 
-    BUILD_BUG_ON(sizeof(c.nat->fpu_ctxt) !=
-                 sizeof(v->arch.xsave_area->fpu_sse));
-    memcpy(&c.nat->fpu_ctxt, &v->arch.xsave_area->fpu_sse,
-           sizeof(c.nat->fpu_ctxt));
+    xsave_area = VCPU_MAP_XSAVE_AREA(v);
+    BUILD_BUG_ON(sizeof(c.nat->fpu_ctxt) != sizeof(xsave_area->fpu_sse));
+    memcpy(&c.nat->fpu_ctxt, &xsave_area->fpu_sse, sizeof(c.nat->fpu_ctxt));
+    VCPU_UNMAP_XSAVE_AREA(v, xsave_area);
 
     if ( is_pv_domain(d) )
         c(flags = v->arch.pv.vgc_flags & ~(VGCF_i387_valid|VGCF_in_kernel));
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Fri Jan 10 13:29:18 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 13:29:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869517.1281002 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWF4f-0002lq-V1; Fri, 10 Jan 2025 13:29:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869517.1281002; Fri, 10 Jan 2025 13:29:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWF4f-0002l8-Qf; Fri, 10 Jan 2025 13:29:17 +0000
Received: by outflank-mailman (input) for mailman id 869517;
 Fri, 10 Jan 2025 13:29:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=mmVM=UC=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tWF4e-0001QR-GE
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 13:29:16 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e33d4457-cf56-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 14:29:15 +0100 (CET)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-5d3dce16a3dso3707488a12.1
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 05:29:16 -0800 (PST)
Received: from localhost.localdomain ([66.81.170.107])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d9900c98d6sm1589297a12.35.2025.01.10.05.29.13
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 10 Jan 2025 05:29:14 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e33d4457-cf56-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736515755; x=1737120555; 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=RqLvtnGygQhpjVsvp9h9as+dqMu10ap3I0KwRn4gBrU=;
        b=jRGTW/Pc7/13lWxrUuXVe145yOiFaChY8Lq/aS57KiSuX8T0FQsjEzHN9jmMInvum/
         uSa4zbMULN517N0MrAeaa8NR9Y1h1aeHV/Man9Px0hSFtRLkzW6BZM5toyxJaibT4HEN
         qbUDlKvppe/BsZj1dEyWAHQU6gVIiUIfWbi/0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736515755; x=1737120555;
        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=RqLvtnGygQhpjVsvp9h9as+dqMu10ap3I0KwRn4gBrU=;
        b=t0DdO4mQIVZ7wcuoeeG8BOoSaFgaRr25UmqBL/uHBZMap5iN6e/WNUHYhX+R1t6Xaq
         vi9y+eLdoCAWci+6jmEKhMf1sB+u2LnhTpA6iirR3dQPtOYAOlQd8sYbLAIku6o/rYx4
         JQAxj/MkReZwBMZaohrGBcDxiWOgusFBp+IGMsxc+SWbBN+oHQhQDzxeBm1FQqaP3Qnh
         IAm8mQ/25oAat2gjCvlQRQOKoGHVDqEsilkvx7hBcq9+Cp/9pUyWy/PDNTLxKyyemqhX
         ThPk4781aFg7j6EVe2vRVd72Bw6+iQqLBcUq8QeyzPF50PClDMhzJMeYgZALtsIIBokY
         wUEw==
X-Gm-Message-State: AOJu0Yw6+e2XcQ4oG5QsMTOIHO7PAlXMYn2mvZEXUCCFpGUZt13Mhxic
	Xzsfcf/BDfj8bztvWHqQw324tM0XoXtphGzSaAxpZeVUzOS+WU/c2sT0DC16WmdkOrEUN2LmlPT
	SwiY8VQ==
X-Gm-Gg: ASbGnctFfibL85alxTTccO4PG4f03t3EB5yNovyDBhtQ/Hydp9xF68ifpPMLUkMncXH
	jvYmL2rsXgEha0lqhWJVTKVqIca/ZTjFXKB4P1KDbstdMZ+Kv5vYv1ZpSpfTdZ1kI+YxZOskU4H
	R6N94Qf+Z3k9bWn6lPSqjGpy0JwX7Idk6twIQvHT7/wSgNiXz7qa/MsiBbjygYJ2BdpzwWEFo2v
	/K3aJ7ORxFPg7FJHlmXwk1+9vl0SCDNr/ErZXxjN6j8UbIMUqUo87EUnnM935VEbzYl49zUKUQP
	y3w=
X-Google-Smtp-Source: AGHT+IEUzU/9TuxG5IxaDVVK7OZ7dMFL9qCGMhFZl/jaqgzNc7UBjeNpP97oNPvy+m/qQtqKPk4Isw==
X-Received: by 2002:a05:6402:4408:b0:5d3:eb50:4e33 with SMTP id 4fb4d7f45d1cf-5d9861d1511mr6241934a12.5.1736515755264;
        Fri, 10 Jan 2025 05:29:15 -0800 (PST)
From: Alejandro Vallejo <alejandro.vallejo@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Alejandro Vallejo <alejandro.vallejo@cloud.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PATCH v3 08/12] x86/emulator: Refactor FXSAVE_AREA to use wrappers
Date: Fri, 10 Jan 2025 13:28:19 +0000
Message-ID: <20250110132823.24348-9-alejandro.vallejo@cloud.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250110132823.24348-1-alejandro.vallejo@cloud.com>
References: <20250110132823.24348-1-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Adds an UNMAP primitive to make use of vcpu_unmap_xsave_area() when
linked into xen. unmap is a no-op during tests.

Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
---
v2->v3:
  * Fixed typo in first parameter of UNMAP_FXSAVE_AREA.
  * Added Parenthesis around "x" in #else's UNMAP_FXSAVE_AREA(x)

v1->v2:
  * Added comments highlighting fastpath on `current`
---
 xen/arch/x86/x86_emulate/blk.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/x86_emulate/blk.c b/xen/arch/x86/x86_emulate/blk.c
index 08a05f8453f7..11b16aeaec39 100644
--- a/xen/arch/x86/x86_emulate/blk.c
+++ b/xen/arch/x86/x86_emulate/blk.c
@@ -11,9 +11,12 @@
     !defined(X86EMUL_NO_SIMD)
 # ifdef __XEN__
 #  include <asm/xstate.h>
-#  define FXSAVE_AREA ((void *)&current->arch.xsave_area->fpu_sse)
+/* Has a fastpath for `current`, so there's no actual map */
+#  define FXSAVE_AREA ((void *)VCPU_MAP_XSAVE_AREA(current))
+#  define UNMAP_FXSAVE_AREA(x) VCPU_UNMAP_XSAVE_AREA(current, x)
 # else
 #  define FXSAVE_AREA get_fpu_save_area()
+#  define UNMAP_FXSAVE_AREA(x) ((void)(x))
 # endif
 #endif
 
@@ -292,6 +295,9 @@ int x86_emul_blk(
         }
         else
             asm volatile ( "fxrstor %0" :: "m" (*fxsr) );
+
+        UNMAP_FXSAVE_AREA(fxsr);
+
         break;
     }
 
@@ -320,6 +326,9 @@ int x86_emul_blk(
 
         if ( fxsr != ptr ) /* i.e. s->op_bytes < sizeof(*fxsr) */
             memcpy(ptr, fxsr, s->op_bytes);
+
+        UNMAP_FXSAVE_AREA(fxsr);
+
         break;
     }
 
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Fri Jan 10 13:29:18 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 13:29:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869518.1281007 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWF4g-0002un-Hl; Fri, 10 Jan 2025 13:29:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869518.1281007; Fri, 10 Jan 2025 13:29:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWF4g-0002sI-As; Fri, 10 Jan 2025 13:29:18 +0000
Received: by outflank-mailman (input) for mailman id 869518;
 Fri, 10 Jan 2025 13:29:16 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=mmVM=UC=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tWF4e-0000vX-SH
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 13:29:16 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e26119b5-cf56-11ef-99a4-01e77a169b0f;
 Fri, 10 Jan 2025 14:29:14 +0100 (CET)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-5d3f65844deso3159909a12.0
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 05:29:14 -0800 (PST)
Received: from localhost.localdomain ([66.81.170.107])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d9900c98d6sm1589297a12.35.2025.01.10.05.29.12
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 10 Jan 2025 05:29:13 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e26119b5-cf56-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736515754; x=1737120554; 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=NpsXCde4rHvHOBhrjr2xt+9hIK3kXIA7STQqezCkmas=;
        b=QQDe33ZF/gpuVeJpaMcRSdfCHezA0E+kBQRmyfp7wbgJHu8ukOFClTJjRzD5sYyQOn
         KhC+7dEQbQjIFYDaWUZOpKRlHzuhEh/QHFa2vfPp4wvvvto6Jqjej4vu3jDScOx0p6lb
         2aVfMF3z9+fC5x1S3As3Bp0tng03kpWaw6TQ4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736515754; x=1737120554;
        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=NpsXCde4rHvHOBhrjr2xt+9hIK3kXIA7STQqezCkmas=;
        b=AYILJ5lX0CGvMjrp0c8qdbZOx3ewceHQUwx0kEgd4fXVIgED/S4oYWWQHpbkxeO9Qg
         IV0M/7AZstbgxb1d4126rgVhV9ts7P7kQpPjhxDqn8acqjx3junNaK343f1Ebh5CwINM
         ARou/Tpm7gi1Q6lBrGInXJGCCUhvljSGQtiCY4RGcg2YOUxhMm9j+AHYPfnUnmTGU/uU
         OEzKtLtxSIuKjdgjeAuKYxa2pSZ2H1TquibakwInkFjS1hAgKNKvAG/DqAXhyxvaENkw
         aIMJccfmViRK2U04YSrWCYKFImEWtSRh8YaVSdY2Gy4Bmtrm21AnJXnzB53WaN310E0a
         Ocmw==
X-Gm-Message-State: AOJu0Yx5o7Zn1wsj6PzPpfO5U0A9aBdr43aqlYIgMOpldE3Lm6kFTF/A
	TTUFEAIAE/7lvTSL/b73MWtwhcJWGW7vbXGGylM2VnG/AQryXq75Co0Q4nXMShH04nq/Yee5ttw
	d1ftZcA==
X-Gm-Gg: ASbGncvcRTsaAUPU7cDyYALnit5gE6WwUM3yQSu5RHwP41y831tFni8vHBNIQpydi2G
	OPbhQdkfqRJY7GDiha3W1C891RT+TLkc/SCxxq1Rn7hYSW6nyII9BeAUpeit9iATYfYTw4xkLUv
	StVgl8zMhKpzp62xXa8I7RyLUKJfrESPAPglh6/xgms7YnDkmWRh+ncScqOLze7q5v8xXgWfs+h
	vGpotUPxcFIt8dnZ0TPgjkyq//ti3/TLmb5rY0CJ9G+m3UY3I5peBBo9FjgieVk6FQeqw09LtZg
	bRQ=
X-Google-Smtp-Source: AGHT+IHLwTsFfF0iue5H/nDszzLlRu5rCiVcELAIDfNI3h8oJ83PoDm2hkMI53TMpPky9oTecF3DMQ==
X-Received: by 2002:a05:6402:5244:b0:5d0:8197:7ab3 with SMTP id 4fb4d7f45d1cf-5d972dfb878mr10087233a12.3.1736515753650;
        Fri, 10 Jan 2025 05:29:13 -0800 (PST)
From: Alejandro Vallejo <alejandro.vallejo@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Alejandro Vallejo <alejandro.vallejo@cloud.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PATCH v3 07/12] x86/xstate: Map/unmap xsave area in {compress,expand}_xsave_states()
Date: Fri, 10 Jan 2025 13:28:18 +0000
Message-ID: <20250110132823.24348-8-alejandro.vallejo@cloud.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250110132823.24348-1-alejandro.vallejo@cloud.com>
References: <20250110132823.24348-1-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

No functional change.

Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
---
v2->v3:
  * Unmap xsave area also before the early return.

v1->v2:
  * No change
---
 xen/arch/x86/xstate.c | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c
index 12004d7db24b..3d249518a1b7 100644
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86/xstate.c
@@ -177,7 +177,7 @@ static void setup_xstate_comp(uint16_t *comp_offsets,
  */
 void expand_xsave_states(const struct vcpu *v, void *dest, unsigned int size)
 {
-    const struct xsave_struct *xstate = v->arch.xsave_area;
+    const struct xsave_struct *xstate = VCPU_MAP_XSAVE_AREA(v);
     const void *src;
     uint16_t comp_offsets[sizeof(xfeature_mask)*8];
     u64 xstate_bv = xstate->xsave_hdr.xstate_bv;
@@ -191,7 +191,7 @@ void expand_xsave_states(const struct vcpu *v, void *dest, unsigned int size)
     if ( !(xstate->xsave_hdr.xcomp_bv & XSTATE_COMPACTION_ENABLED) )
     {
         memcpy(dest, xstate, size);
-        return;
+        goto out;
     }
 
     ASSERT(xsave_area_compressed(xstate));
@@ -228,6 +228,9 @@ void expand_xsave_states(const struct vcpu *v, void *dest, unsigned int size)
 
         valid &= ~feature;
     }
+
+ out:
+    VCPU_UNMAP_XSAVE_AREA(v, xstate);
 }
 
 /*
@@ -242,7 +245,7 @@ void expand_xsave_states(const struct vcpu *v, void *dest, unsigned int size)
  */
 void compress_xsave_states(struct vcpu *v, const void *src, unsigned int size)
 {
-    struct xsave_struct *xstate = v->arch.xsave_area;
+    struct xsave_struct *xstate = VCPU_MAP_XSAVE_AREA(v);
     void *dest;
     uint16_t comp_offsets[sizeof(xfeature_mask)*8];
     u64 xstate_bv, valid;
@@ -256,7 +259,7 @@ void compress_xsave_states(struct vcpu *v, const void *src, unsigned int size)
     if ( !(v->arch.xcr0_accum & XSTATE_XSAVES_ONLY) )
     {
         memcpy(xstate, src, size);
-        return;
+        goto out;
     }
 
     /*
@@ -294,6 +297,9 @@ void compress_xsave_states(struct vcpu *v, const void *src, unsigned int size)
 
         valid &= ~feature;
     }
+
+ out:
+    VCPU_UNMAP_XSAVE_AREA(v, xstate);
 }
 
 void xsave(struct vcpu *v, uint64_t mask)
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Fri Jan 10 13:29:20 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 13:29:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869519.1281021 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWF4i-0003Ja-50; Fri, 10 Jan 2025 13:29:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869519.1281021; Fri, 10 Jan 2025 13:29:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWF4h-0003Hn-Rz; Fri, 10 Jan 2025 13:29:19 +0000
Received: by outflank-mailman (input) for mailman id 869519;
 Fri, 10 Jan 2025 13:29: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
 <SRS0=mmVM=UC=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tWF4g-0001QR-Lh
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 13:29:18 +0000
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com
 [2a00:1450:4864:20::52d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e4913f05-cf56-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 14:29:18 +0100 (CET)
Received: by mail-ed1-x52d.google.com with SMTP id
 4fb4d7f45d1cf-5d982de9547so3863734a12.2
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 05:29:18 -0800 (PST)
Received: from localhost.localdomain ([66.81.170.107])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d9900c98d6sm1589297a12.35.2025.01.10.05.29.15
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 10 Jan 2025 05:29:16 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e4913f05-cf56-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736515757; x=1737120557; 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=NBkiVpHM8v5vp8P31Jsr5IhRd2sJbMgPGREzQchfE+0=;
        b=USmORQwaLa7l5xaHIvGC5nila+X+hoOxASxsLKn7L1ZzwocqC5d+8F80QxrpbTp2le
         Zbs6QCyN4RpdTy6fgB42x7rWe02U29rXpvg3pH01/z09ZTQwOWYMVNqv66v9bllHgLst
         5mFTdptrcOmG5jVz3mlq2M6tiZamiAYJbQ42A=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736515757; x=1737120557;
        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=NBkiVpHM8v5vp8P31Jsr5IhRd2sJbMgPGREzQchfE+0=;
        b=bjUS2f7QDqSzaVBIwud6AUXRM8+UYvKT7HYjRuf23KCXLfB3pd2usA0h73jtAk0FTg
         W0EstrFc/1FEe4DWqjhSWOFlKgp0EBODzWPp1piKlqIzii0BvRIR2862AJRwcl5ogogD
         u2I2yqhXKY7Eq06TWj9OJyCFDjxQJ1dZAsJZK9WVXrvRcAtQWiMTU2vicUCuWNxJDXY5
         Uaot6SWlgMRz/NBFrWdgvQu/7gdXY39z5HyQroygyPd2h442AwFy9grHxYYC6Uiv8ZFX
         3vRfpbLSANvkIf1gnTWBa8wXS4eMT4jV4ftWEZGWK3Z+C5A5/3AR4Xgl4nnvoDmNiLN8
         34UQ==
X-Gm-Message-State: AOJu0YwtZdliDxWsPBTmRo0jLWZuuzTFv6gEpACffOFCp7Dt5DXStL4z
	wM0yPhzh/mAgZFOQ7SQOCnlzXXgYSR43wvdocKJiXp5qXIxjLRkGqdt+Lkos5m/fmMUKPiM3HER
	dlgP65w==
X-Gm-Gg: ASbGncs8tROJZQpTq/OZ3X4r8xjS1ATha8gtOMMz3PSJ8QJ/JkDu+Zin8aAJlit8MSF
	aNtBDWFZchdupHldistHS7vgKOkRbgrI2sDIEPTLKT4hOjZUej7u578mXUG+KU2dnzlNIx+Q2X9
	w8hunko0lWlOcA4DmIJZfbHXWdJKtuIMoWdty/8EOn4009r7HUHQA/aeNNwgCJyNo3r3uFumqJe
	b+L0YK/d0u/jgy+xRr1ipUs4vlsCMY6O3Gb2eQhRJVm0HWuSqL/b2l7Gb5eL4AmovdTWAte9f9x
	/M4=
X-Google-Smtp-Source: AGHT+IF2kUi1l15Plt8UytnrHFbBfLL+/GMd8KtcoOhar7B79Utam/Ngh0jJKQmV4Jh1Dkwci5S5XA==
X-Received: by 2002:a05:6402:2746:b0:5d9:a85:1a59 with SMTP id 4fb4d7f45d1cf-5d972e4769bmr9812304a12.27.1736515757431;
        Fri, 10 Jan 2025 05:29:17 -0800 (PST)
From: Alejandro Vallejo <alejandro.vallejo@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Alejandro Vallejo <alejandro.vallejo@cloud.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PATCH v3 09/12] x86/mpx: Map/unmap xsave area in in read_bndcfgu()
Date: Fri, 10 Jan 2025 13:28:20 +0000
Message-ID: <20250110132823.24348-10-alejandro.vallejo@cloud.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250110132823.24348-1-alejandro.vallejo@cloud.com>
References: <20250110132823.24348-1-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

No functional change.

Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
---
v2->v3:
  * No change

v1->v2:
  * s/ret/bndcfgu
---
 xen/arch/x86/xstate.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c
index 3d249518a1b7..2003ba664594 100644
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86/xstate.c
@@ -1024,9 +1024,10 @@ int handle_xsetbv(u32 index, u64 new_bv)
 
 uint64_t read_bndcfgu(void)
 {
+    uint64_t bndcfgu = 0;
     unsigned long cr0 = read_cr0();
-    struct xsave_struct *xstate
-        = idle_vcpu[smp_processor_id()]->arch.xsave_area;
+    struct vcpu *v = idle_vcpu[smp_processor_id()];
+    struct xsave_struct *xstate = VCPU_MAP_XSAVE_AREA(v);
     const struct xstate_bndcsr *bndcsr;
 
     ASSERT(cpu_has_mpx);
@@ -1052,7 +1053,12 @@ uint64_t read_bndcfgu(void)
     if ( cr0 & X86_CR0_TS )
         write_cr0(cr0);
 
-    return xstate->xsave_hdr.xstate_bv & X86_XCR0_BNDCSR ? bndcsr->bndcfgu : 0;
+    if ( xstate->xsave_hdr.xstate_bv & X86_XCR0_BNDCSR )
+        bndcfgu = bndcsr->bndcfgu;
+
+    VCPU_UNMAP_XSAVE_AREA(v, xstate);
+
+    return bndcfgu;
 }
 
 void xstate_set_init(uint64_t mask)
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Fri Jan 10 13:29:21 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 13:29:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869521.1281030 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWF4j-0003fx-HJ; Fri, 10 Jan 2025 13:29:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869521.1281030; Fri, 10 Jan 2025 13:29:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWF4j-0003dN-B3; Fri, 10 Jan 2025 13:29:21 +0000
Received: by outflank-mailman (input) for mailman id 869521;
 Fri, 10 Jan 2025 13:29:20 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=mmVM=UC=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tWF4i-0001QR-CU
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 13:29:20 +0000
Received: from mail-ed1-x542.google.com (mail-ed1-x542.google.com
 [2a00:1450:4864:20::542])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e58aad29-cf56-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 14:29:19 +0100 (CET)
Received: by mail-ed1-x542.google.com with SMTP id
 4fb4d7f45d1cf-5d414b8af7bso3534644a12.0
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 05:29:19 -0800 (PST)
Received: from localhost.localdomain ([66.81.170.107])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d9900c98d6sm1589297a12.35.2025.01.10.05.29.17
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 10 Jan 2025 05:29:18 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e58aad29-cf56-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736515759; x=1737120559; 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=f2RsoCzP1jEEvrkQ7ie+7psyxTtmQ+XSlhDRoNh8Ta4=;
        b=GXLxss7JQtIMQ5qxRdi32eG7uMDxBFRlL20VpnyOPep68jhkhOG0Y5jorcTKoRnaW2
         Ho6aREBD+KaGTQuAE+Qzf6uBbYVguACNXEOV0Qn+aMX2zaaIQsg6k1ftBeM7/RB2hWSa
         udW3OIHQXiKAwQh3dOPwL4yzUgpRdFzpD97Xg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736515759; x=1737120559;
        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=f2RsoCzP1jEEvrkQ7ie+7psyxTtmQ+XSlhDRoNh8Ta4=;
        b=MeZ8Oku6qLy93J8cMN3br67vLbasrUScHjHOmDnmsboK0VBXAfFykrGMrC1HFGztmm
         hf64XCsDjoaHNYmE69Ub7VYR0Sgnp7rFwvry0KW8oAAG3ix5tziBm0XQAjnLPUkSQ2EN
         oBxAqD6CDavR8rrW5CCP1sByaWAm3yMPaPZFg2SJ3XZxwEI3FmK0mUbU8e/CnhBUaZ6r
         ctzCkMD7hF+ioL3vErXCpNfDFDN1iS+aeDXdjYbhbC7+tm07FcB6336y+54tJG7rpuQt
         LynyHdztZY3F4bKaM2rvB08XToVlY4DmZ4/bLNb1+3RWbPNkVI7tICsth5Uqe52IYy8Q
         k8bw==
X-Gm-Message-State: AOJu0YwTJa3Fp6QIvBvpGbNguUNP0FJgi1lFDRVZAbxerobips9Y74Ds
	H6kDYH5d5nRHgLf+K0ubUurxREvw7140QdhutRPwiMCWqRNpuJNtF1c9nHnSTQfgdate8O1LbHA
	ATQ734uYa
X-Gm-Gg: ASbGncuJMLzX+Og7uTAeAoRMhLoBSL2vxvFxz3e7oGJRdJ96VHOKFd0OTvdCX9MoiFZ
	pDKMajGtBT1XP29h/QjSV9gD/38bbLzaC/wImPCzR0iTWLT5pGqsvqWrj4S0AisWc/had/mLtov
	wfZ62EbLyADHOvotrLIvW203E8/EPlQfoLyklIbQ/c8rRdVSClzcravwmqow1w2Pu18jgwaKpWL
	x+fOOgzMrBTUGG/6/zWWA4IYyW1LkHrgLeE7kvoqVVGrhpbIry+hrmE5j0DtF4qhjky/HkuuHAk
	7jY=
X-Google-Smtp-Source: AGHT+IF15swdBXE1MFaI32h7Atni7TCGXHlE4Tor2dd8F/fqqD6BOl5NrTMZmikGKgmrRfGNYInbLg==
X-Received: by 2002:a05:6402:448e:b0:5d0:c67e:e263 with SMTP id 4fb4d7f45d1cf-5d972e08663mr9043770a12.8.1736515759088;
        Fri, 10 Jan 2025 05:29:19 -0800 (PST)
From: Alejandro Vallejo <alejandro.vallejo@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Alejandro Vallejo <alejandro.vallejo@cloud.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PATCH v3 10/12] x86/fpu: Pass explicit xsave areas to fpu_(f)xsave()
Date: Fri, 10 Jan 2025 13:28:21 +0000
Message-ID: <20250110132823.24348-11-alejandro.vallejo@cloud.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250110132823.24348-1-alejandro.vallejo@cloud.com>
References: <20250110132823.24348-1-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

No functional change.

Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
---
v2->v3:
  * const-ified v in fpu_fxsave() (missing in v2)

v1->v2:
  * const-ified v
---
 xen/arch/x86/i387.c               | 16 ++++++++++------
 xen/arch/x86/include/asm/xstate.h |  2 +-
 xen/arch/x86/xstate.c             |  3 +--
 3 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/i387.c b/xen/arch/x86/i387.c
index 5429531ddd5f..11d06f921269 100644
--- a/xen/arch/x86/i387.c
+++ b/xen/arch/x86/i387.c
@@ -129,7 +129,7 @@ static inline uint64_t vcpu_xsave_mask(const struct vcpu *v)
 }
 
 /* Save x87 extended state */
-static inline void fpu_xsave(struct vcpu *v)
+static inline void fpu_xsave(const struct vcpu *v, struct xsave_struct *xsave_area)
 {
     bool ok;
     uint64_t mask = vcpu_xsave_mask(v);
@@ -141,15 +141,14 @@ static inline void fpu_xsave(struct vcpu *v)
      */
     ok = set_xcr0(v->arch.xcr0_accum | XSTATE_FP_SSE);
     ASSERT(ok);
-    xsave(v, mask);
+    xsave(v, xsave_area, mask);
     ok = set_xcr0(v->arch.xcr0 ?: XSTATE_FP_SSE);
     ASSERT(ok);
 }
 
 /* Save x87 FPU, MMX, SSE and SSE2 state */
-static inline void fpu_fxsave(struct vcpu *v)
+static inline void fpu_fxsave(const struct vcpu *v, fpusse_t *fpu_ctxt)
 {
-    fpusse_t *fpu_ctxt = &v->arch.xsave_area->fpu_sse;
     unsigned int fip_width = v->domain->arch.x87_fip_width;
 
     if ( fip_width != 4 )
@@ -264,6 +263,8 @@ void vcpu_restore_fpu_lazy(struct vcpu *v)
  */
 static bool _vcpu_save_fpu(struct vcpu *v)
 {
+    struct xsave_struct *xsave_area;
+
     if ( !v->fpu_dirtied && !v->arch.nonlazy_xstate_used )
         return false;
 
@@ -272,11 +273,14 @@ static bool _vcpu_save_fpu(struct vcpu *v)
     /* This can happen, if a paravirtualised guest OS has set its CR0.TS. */
     clts();
 
+    xsave_area = VCPU_MAP_XSAVE_AREA(v);
+
     if ( cpu_has_xsave )
-        fpu_xsave(v);
+        fpu_xsave(v, xsave_area);
     else
-        fpu_fxsave(v);
+        fpu_fxsave(v, &xsave_area->fpu_sse);
 
+    VCPU_UNMAP_XSAVE_AREA(v, xsave_area);
     v->fpu_dirtied = 0;
 
     return true;
diff --git a/xen/arch/x86/include/asm/xstate.h b/xen/arch/x86/include/asm/xstate.h
index ab81a4c8527e..87f05dbca6f4 100644
--- a/xen/arch/x86/include/asm/xstate.h
+++ b/xen/arch/x86/include/asm/xstate.h
@@ -97,7 +97,7 @@ uint64_t get_xcr0(void);
 void set_msr_xss(u64 xss);
 uint64_t get_msr_xss(void);
 uint64_t read_bndcfgu(void);
-void xsave(struct vcpu *v, uint64_t mask);
+void xsave(const struct vcpu *v, struct xsave_struct *ptr, uint64_t mask);
 void xrstor(struct vcpu *v, uint64_t mask);
 void xstate_set_init(uint64_t mask);
 bool xsave_enabled(const struct vcpu *v);
diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c
index 2003ba664594..24053b394200 100644
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86/xstate.c
@@ -302,9 +302,8 @@ void compress_xsave_states(struct vcpu *v, const void *src, unsigned int size)
     VCPU_UNMAP_XSAVE_AREA(v, xstate);
 }
 
-void xsave(struct vcpu *v, uint64_t mask)
+void xsave(const struct vcpu *v, struct xsave_struct *ptr, uint64_t mask)
 {
-    struct xsave_struct *ptr = v->arch.xsave_area;
     uint32_t hmask = mask >> 32;
     uint32_t lmask = mask;
     unsigned int fip_width = v->domain->arch.x87_fip_width;
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Fri Jan 10 13:29:24 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 13:29:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869526.1281043 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWF4m-0004IM-Ps; Fri, 10 Jan 2025 13:29:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869526.1281043; Fri, 10 Jan 2025 13:29:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWF4m-0004I0-Kl; Fri, 10 Jan 2025 13:29:24 +0000
Received: by outflank-mailman (input) for mailman id 869526;
 Fri, 10 Jan 2025 13:29: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
 <SRS0=mmVM=UC=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tWF4l-0001QR-5I
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 13:29:23 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e723c13e-cf56-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 14:29:22 +0100 (CET)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-5d7e3f1fc01so4018560a12.2
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 05:29:22 -0800 (PST)
Received: from localhost.localdomain ([66.81.170.107])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d9900c98d6sm1589297a12.35.2025.01.10.05.29.20
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 10 Jan 2025 05:29:21 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e723c13e-cf56-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736515762; x=1737120562; 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=TGYGQF82WrUmaE3ckte9a2eG993H0v3sPPUj77Kpcmw=;
        b=Cr83ioQvAcp9FvPphkT8iLQsf2VpYo10ZezFRZ9EPAHxub3qbLyUoi1uxGy72TTRvp
         to9aDP776+EKGZn6WzPCxNkn4FBg/EpFFeCr8199osQZBFPoIeXyticOMBtnZFlh3Qzb
         f/2ci0586FJ7pPcmy4+bz+iRP8C8yn45wnwjI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736515762; x=1737120562;
        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=TGYGQF82WrUmaE3ckte9a2eG993H0v3sPPUj77Kpcmw=;
        b=I4EJYEBukDpM4TAOTZlL3sdR01BVTK5ZvMTgD5VKEvm3aTwHFhkkp9oP+otEs3o1Kl
         t5u3ZdXWkI+VBrtOUxjjLNc88kzqsEZM1zXyGLTjKSV6tz7Hf8QdJvCBGJYF/VK1Dv2r
         fmhUn80kC/1PxMtJOgnMno5VqUJ6iZ9oGBLQjEwm0CSwotIMoOT6nszsddsd6ZiQAel6
         lSv/sbkGNBQYjgbs00d7X7Cm7sJhzDW52k8IxFL7UWNL7S7Mmw4d5kobP55QXAuNWVZh
         hVCv+rQFzA0vmNAt7k3dx0qMAck8OkpmXV4y9JdWWzdWHAadjT+ydkV9gZSn9XDKdV1I
         4xdg==
X-Gm-Message-State: AOJu0YzfBkjExomFQVAElE1J2aJQ7cOdn60Zpyco7E9eQXVNwbNbkHdf
	DOr1bbJhrL/gxJMsC2KHjcI4sJKeQnumGFUaXg0rnC1Xj31UkauZjEv9pvNmaCQmklsFyDPyCHn
	lcsOsTA==
X-Gm-Gg: ASbGncsN5s72xdY77DUsQW+uE6sAURCK8zm6qrQNGq67qAfxdOpPjtCecRTNpV7ARyd
	5iW+KzbuxOTep/2w7LAOA2TGgZdMJu5IirLiZM+sQO5QouKgzGCKSyfxZzYt0hKJBhu+L4+le5C
	b1+HA6qBUXWxVWErfS2ZF7dqh6Jo0rYdchoVBihewFvRSe/hJrBU+hHi3PNVA1//KRxPGEzowv9
	NiDekHw3Pm9zmTgGjoJSEVxuFPmDiqpyNXl4OqLRhXn8E0qRYT2ZlT4UCcWRtkpAIofW4sM8qNa
	xG4=
X-Google-Smtp-Source: AGHT+IHm6oaJ8YwWbN8mvMBsk0Ry+E2PKI9C0KwkXDe5NuUIwFuRQ4O/29eudYZew7AzQZ2WhbARTA==
X-Received: by 2002:a17:907:c815:b0:ab2:c78f:e4ae with SMTP id a640c23a62f3a-ab2c78fe63dmr536582966b.20.1736515761703;
        Fri, 10 Jan 2025 05:29:21 -0800 (PST)
From: Alejandro Vallejo <alejandro.vallejo@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Alejandro Vallejo <alejandro.vallejo@cloud.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PATCH v3 12/12] x86/xstate: Make xstate_all() and vcpu_xsave_mask() take explicit xstate
Date: Fri, 10 Jan 2025 13:28:23 +0000
Message-ID: <20250110132823.24348-13-alejandro.vallejo@cloud.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250110132823.24348-1-alejandro.vallejo@cloud.com>
References: <20250110132823.24348-1-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

No functional change.

Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
v2->v3:
  * Added A-by
---
 xen/arch/x86/i387.c               | 9 +++++----
 xen/arch/x86/include/asm/xstate.h | 5 +++--
 xen/arch/x86/xstate.c             | 2 +-
 3 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/i387.c b/xen/arch/x86/i387.c
index 943ae668606f..8120a6a4afc0 100644
--- a/xen/arch/x86/i387.c
+++ b/xen/arch/x86/i387.c
@@ -107,7 +107,8 @@ static inline void fpu_fxrstor(const fpusse_t *fpu_ctxt)
 /*      FPU Save Functions     */
 /*******************************/
 
-static inline uint64_t vcpu_xsave_mask(const struct vcpu *v)
+static inline uint64_t vcpu_xsave_mask(const struct vcpu *v,
+                                       const struct xsave_struct *xsave_area)
 {
     if ( v->fpu_dirtied )
         return v->arch.nonlazy_xstate_used ? XSTATE_ALL : XSTATE_LAZY;
@@ -124,14 +125,14 @@ static inline uint64_t vcpu_xsave_mask(const struct vcpu *v)
      * XSTATE_FP_SSE), vcpu_xsave_mask will return XSTATE_ALL. Otherwise
      * return XSTATE_NONLAZY.
      */
-    return xstate_all(v) ? XSTATE_ALL : XSTATE_NONLAZY;
+    return xstate_all(v, xsave_area) ? XSTATE_ALL : XSTATE_NONLAZY;
 }
 
 /* Save x87 extended state */
 static inline void fpu_xsave(const struct vcpu *v, struct xsave_struct *xsave_area)
 {
     bool ok;
-    uint64_t mask = vcpu_xsave_mask(v);
+    uint64_t mask = vcpu_xsave_mask(v, xsave_area);
 
     ASSERT(mask);
     /*
@@ -211,7 +212,7 @@ void vcpu_restore_fpu_nonlazy(struct vcpu *v, bool need_stts)
      * saving state belonging to another vCPU.
      */
     xsave_area = VCPU_MAP_XSAVE_AREA(v);
-    if ( v->arch.fully_eager_fpu || xstate_all(v) )
+    if ( v->arch.fully_eager_fpu || xstate_all(v, xsave_area) )
     {
         if ( cpu_has_xsave )
             fpu_xrstor(v, xsave_area, XSTATE_ALL);
diff --git a/xen/arch/x86/include/asm/xstate.h b/xen/arch/x86/include/asm/xstate.h
index 7d160d2b54be..a1b188537c15 100644
--- a/xen/arch/x86/include/asm/xstate.h
+++ b/xen/arch/x86/include/asm/xstate.h
@@ -132,14 +132,15 @@ xsave_area_compressed(const struct xsave_struct *xsave_area)
     return xsave_area->xsave_hdr.xcomp_bv & XSTATE_COMPACTION_ENABLED;
 }
 
-static inline bool xstate_all(const struct vcpu *v)
+static inline bool xstate_all(const struct vcpu *v,
+                              const struct xsave_struct *xsave_area)
 {
     /*
      * XSTATE_FP_SSE may be excluded, because the offsets of XSTATE_FP_SSE
      * (in the legacy region of xsave area) are fixed, so saving
      * XSTATE_FP_SSE will not cause overwriting problem with XSAVES/XSAVEC.
      */
-    return xsave_area_compressed(v->arch.xsave_area) &&
+    return xsave_area_compressed(xsave_area) &&
            (v->arch.xcr0_accum & XSTATE_LAZY & ~XSTATE_FP_SSE);
 }
 
diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c
index 3d4fb7664c5f..b204147815c3 100644
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86/xstate.c
@@ -1005,7 +1005,7 @@ int handle_xsetbv(u32 index, u64 new_bv)
             asm ( "stmxcsr %0" : "=m" (xsave_area->fpu_sse.mxcsr) );
             VCPU_UNMAP_XSAVE_AREA(curr, xsave_area);
         }
-        else if ( xstate_all(curr) )
+        else if ( xstate_all(curr, xsave_area) )
         {
             /* See the comment in i387.c:vcpu_restore_fpu_eager(). */
             mask |= XSTATE_LAZY;
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Fri Jan 10 13:29:25 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 13:29:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869527.1281046 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWF4n-0004MG-8v; Fri, 10 Jan 2025 13:29:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869527.1281046; Fri, 10 Jan 2025 13:29:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWF4n-0004Lh-0Z; Fri, 10 Jan 2025 13:29:25 +0000
Received: by outflank-mailman (input) for mailman id 869527;
 Fri, 10 Jan 2025 13:29:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=mmVM=UC=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tWF4l-0000vX-32
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 13:29:23 +0000
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
 [2a00:1450:4864:20::531])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e695ffc9-cf56-11ef-99a4-01e77a169b0f;
 Fri, 10 Jan 2025 14:29:21 +0100 (CET)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-5d3bbb0f09dso3438940a12.2
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 05:29:21 -0800 (PST)
Received: from localhost.localdomain ([66.81.170.107])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d9900c98d6sm1589297a12.35.2025.01.10.05.29.19
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 10 Jan 2025 05:29:19 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e695ffc9-cf56-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736515761; x=1737120561; 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=GI//zXjGi7gOKfBwz6cTp3sciH/k2uuKEBMoWxpEBrQ=;
        b=IVpQF2uNpYLUNdDE8CeswGFQI3fv/YRCcOrUp0gOtsVDJWDzJTTmIVn1xXOcljxreB
         UbML3L8cgBDo+9omI6ZtMV++j9iil/FFy/A8sPAxhmV9zdXL22CWGt1+rLqVVxJp1q9E
         PNGsClpKL0md/7WQLzjcyMv2xi5sA8I8sLPuc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736515761; x=1737120561;
        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=GI//zXjGi7gOKfBwz6cTp3sciH/k2uuKEBMoWxpEBrQ=;
        b=ogTiPP+Ww64VbJgQj3U1ThZmeUu5A2zqO5MvUTWu/eVbUfy/CG+WqjP/ZGVphd/ZbX
         Misnqzk6GiAYKOyqh8kuyNK88OJwTSZWU7NtO1HPdM9yw462x8MW1m8iUk3R9Lb+g0Zl
         lkFouE5bhQ+sVlN1VWR2b8QBdZIt58CezFpnepujR6u1hFYD6kg9qyj+KiHNTxHw/0mu
         ozqFYOt7MATXretl32Ah3rzDBoVTF3sKXq7FkfxLsOSibpoxjLtjNGx9O59ROmto0Z08
         RX7E380JcHnEYRY1vvz6L2aN00SfTGN64HZFJzV3mKSzxuyrLN1YcTbE35YbjmwGP0++
         uYPQ==
X-Gm-Message-State: AOJu0Yw+A3Gh2+A4ThGnxqzxXRuAl6j11rJpL1ccQmI5RoKl07iwLpEw
	3oQ3Stai7VwJUxBeCUy6KBWMHAOlmfPImByXhYcs0DwOezcN3xeFiFBIvSqdYOqNsaN9yY00SAR
	7DPOnMQ==
X-Gm-Gg: ASbGncuG7F/rODQe5BoQ2lOOqvsZ5P9TIjlpgE7KQpsjjCDqEK0qXgQGu0VpwRfX+bJ
	qgils5DhbX76IEUO9rmhg7CZgv3iMii78nLpoqydvcXg92FTf2N25vEesMKL9VBylwTT5CtUjBV
	h0xcuULFEGl2Aih+87R3dsoxTJYgLoFD/09juj8ZgBG1uM32pVDmxwqLBsfk0bNQkwzK/as0EwF
	8K4o5Ih0Z1Q/UCis1rQKfXFVudYq4LTY6FOHVDhhrtULx08UwlHZi+FKwpQAGag6Xp/6Fv16FpB
	xvE=
X-Google-Smtp-Source: AGHT+IHl+QVKSzvBQaSukQzB8NUKHv3g4BYe4c8rMerq7z2zRKYMYXHuIotBpbj7sN26MOkPWBfcVg==
X-Received: by 2002:a05:6402:4414:b0:5d9:a84:d4b6 with SMTP id 4fb4d7f45d1cf-5d972d26ac2mr8691628a12.0.1736515760631;
        Fri, 10 Jan 2025 05:29:20 -0800 (PST)
From: Alejandro Vallejo <alejandro.vallejo@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Alejandro Vallejo <alejandro.vallejo@cloud.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PATCH v3 11/12] x86/fpu: Pass explicit xsave areas to fpu_(f)xrstor()
Date: Fri, 10 Jan 2025 13:28:22 +0000
Message-ID: <20250110132823.24348-12-alejandro.vallejo@cloud.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250110132823.24348-1-alejandro.vallejo@cloud.com>
References: <20250110132823.24348-1-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

No functional change.

Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
---
v2->v3:
  * const-ified v in fpu_xrstor()
  * Removed v in fpu_fxrstor()

v1->v2:
  * const-ified v in xrstor()
    ( it was incorrectly reported in v2 as it being fpu_xrstor() )
---
 xen/arch/x86/i387.c               | 26 ++++++++++++++++----------
 xen/arch/x86/include/asm/xstate.h |  2 +-
 xen/arch/x86/xstate.c             | 10 ++++++----
 3 files changed, 23 insertions(+), 15 deletions(-)

diff --git a/xen/arch/x86/i387.c b/xen/arch/x86/i387.c
index 11d06f921269..943ae668606f 100644
--- a/xen/arch/x86/i387.c
+++ b/xen/arch/x86/i387.c
@@ -20,7 +20,8 @@
 /*     FPU Restore Functions   */
 /*******************************/
 /* Restore x87 extended state */
-static inline void fpu_xrstor(struct vcpu *v, uint64_t mask)
+static inline void fpu_xrstor(const struct vcpu *v,
+                              struct xsave_struct *xsave_area, uint64_t mask)
 {
     bool ok;
 
@@ -30,16 +31,14 @@ static inline void fpu_xrstor(struct vcpu *v, uint64_t mask)
      */
     ok = set_xcr0(v->arch.xcr0_accum | XSTATE_FP_SSE);
     ASSERT(ok);
-    xrstor(v, mask);
+    xrstor(v, xsave_area, mask);
     ok = set_xcr0(v->arch.xcr0 ?: XSTATE_FP_SSE);
     ASSERT(ok);
 }
 
 /* Restore x87 FPU, MMX, SSE and SSE2 state */
-static inline void fpu_fxrstor(struct vcpu *v)
+static inline void fpu_fxrstor(const fpusse_t *fpu_ctxt)
 {
-    const fpusse_t *fpu_ctxt = &v->arch.xsave_area->fpu_sse;
-
     /*
      * Some CPUs don't save/restore FDP/FIP/FOP unless an exception
      * is pending. Clear the x87 state here by setting it to fixed
@@ -195,6 +194,8 @@ static inline void fpu_fxsave(const struct vcpu *v, fpusse_t *fpu_ctxt)
 /* Restore FPU state whenever VCPU is schduled in. */
 void vcpu_restore_fpu_nonlazy(struct vcpu *v, bool need_stts)
 {
+    struct xsave_struct *xsave_area;
+
     /* Restore nonlazy extended state (i.e. parts not tracked by CR0.TS). */
     if ( !v->arch.fully_eager_fpu && !v->arch.nonlazy_xstate_used )
         goto maybe_stts;
@@ -209,12 +210,13 @@ void vcpu_restore_fpu_nonlazy(struct vcpu *v, bool need_stts)
      * above) we also need to restore full state, to prevent subsequently
      * saving state belonging to another vCPU.
      */
+    xsave_area = VCPU_MAP_XSAVE_AREA(v);
     if ( v->arch.fully_eager_fpu || xstate_all(v) )
     {
         if ( cpu_has_xsave )
-            fpu_xrstor(v, XSTATE_ALL);
+            fpu_xrstor(v, xsave_area, XSTATE_ALL);
         else
-            fpu_fxrstor(v);
+            fpu_fxrstor(&xsave_area->fpu_sse);
 
         v->fpu_initialised = 1;
         v->fpu_dirtied = 1;
@@ -224,9 +226,10 @@ void vcpu_restore_fpu_nonlazy(struct vcpu *v, bool need_stts)
     }
     else
     {
-        fpu_xrstor(v, XSTATE_NONLAZY);
+        fpu_xrstor(v, xsave_area, XSTATE_NONLAZY);
         need_stts = true;
     }
+    VCPU_UNMAP_XSAVE_AREA(v, xsave_area);
 
  maybe_stts:
     if ( need_stts )
@@ -238,6 +241,7 @@ void vcpu_restore_fpu_nonlazy(struct vcpu *v, bool need_stts)
  */
 void vcpu_restore_fpu_lazy(struct vcpu *v)
 {
+    struct xsave_struct *xsave_area;
     ASSERT(!is_idle_vcpu(v));
 
     /* Avoid recursion. */
@@ -248,10 +252,12 @@ void vcpu_restore_fpu_lazy(struct vcpu *v)
 
     ASSERT(!v->arch.fully_eager_fpu);
 
+    xsave_area = VCPU_MAP_XSAVE_AREA(v);
     if ( cpu_has_xsave )
-        fpu_xrstor(v, XSTATE_LAZY);
+        fpu_xrstor(v, xsave_area, XSTATE_LAZY);
     else
-        fpu_fxrstor(v);
+        fpu_fxrstor(&xsave_area->fpu_sse);
+    VCPU_UNMAP_XSAVE_AREA(v, xsave_area);
 
     v->fpu_initialised = 1;
     v->fpu_dirtied = 1;
diff --git a/xen/arch/x86/include/asm/xstate.h b/xen/arch/x86/include/asm/xstate.h
index 87f05dbca6f4..7d160d2b54be 100644
--- a/xen/arch/x86/include/asm/xstate.h
+++ b/xen/arch/x86/include/asm/xstate.h
@@ -98,7 +98,7 @@ void set_msr_xss(u64 xss);
 uint64_t get_msr_xss(void);
 uint64_t read_bndcfgu(void);
 void xsave(const struct vcpu *v, struct xsave_struct *ptr, uint64_t mask);
-void xrstor(struct vcpu *v, uint64_t mask);
+void xrstor(const struct vcpu *v, struct xsave_struct *ptr, uint64_t mask);
 void xstate_set_init(uint64_t mask);
 bool xsave_enabled(const struct vcpu *v);
 int __must_check validate_xstate(const struct domain *d,
diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c
index 24053b394200..3d4fb7664c5f 100644
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86/xstate.c
@@ -376,11 +376,10 @@ void xsave(const struct vcpu *v, struct xsave_struct *ptr, uint64_t mask)
         ptr->fpu_sse.x[FPU_WORD_SIZE_OFFSET] = fip_width;
 }
 
-void xrstor(struct vcpu *v, uint64_t mask)
+void xrstor(const struct vcpu *v, struct xsave_struct *ptr, uint64_t mask)
 {
     uint32_t hmask = mask >> 32;
     uint32_t lmask = mask;
-    struct xsave_struct *ptr = v->arch.xsave_area;
     unsigned int faults, prev_faults;
 
     /*
@@ -994,6 +993,7 @@ int handle_xsetbv(u32 index, u64 new_bv)
     mask &= curr->fpu_dirtied ? ~XSTATE_FP_SSE : XSTATE_NONLAZY;
     if ( mask )
     {
+        struct xsave_struct *xsave_area = VCPU_MAP_XSAVE_AREA(curr);
         unsigned long cr0 = read_cr0();
 
         clts();
@@ -1013,7 +1013,9 @@ int handle_xsetbv(u32 index, u64 new_bv)
             curr->fpu_dirtied = 1;
             cr0 &= ~X86_CR0_TS;
         }
-        xrstor(curr, mask);
+        xrstor(curr, xsave_area, mask);
+        VCPU_UNMAP_XSAVE_AREA(curr, xsave_area);
+
         if ( cr0 & X86_CR0_TS )
             write_cr0(cr0);
     }
@@ -1080,7 +1082,7 @@ void xstate_set_init(uint64_t mask)
 
     xstate = VCPU_MAP_XSAVE_AREA(v);
     memset(&xstate->xsave_hdr, 0, sizeof(xstate->xsave_hdr));
-    xrstor(v, mask);
+    xrstor(v, xstate, mask);
     VCPU_UNMAP_XSAVE_AREA(v, xstate);
 
     if ( cr0 & X86_CR0_TS )
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Fri Jan 10 13:37:36 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 13:37:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869620.1281063 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWFCe-0001Tw-G0; Fri, 10 Jan 2025 13:37:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869620.1281063; Fri, 10 Jan 2025 13:37:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWFCe-0001Tp-CS; Fri, 10 Jan 2025 13:37:32 +0000
Received: by outflank-mailman (input) for mailman id 869620;
 Fri, 10 Jan 2025 13:37:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=qOMD=UC=apertussolutions.com=dpsmith@srs-se1.protection.inumbo.net>)
 id 1tWFCd-0001Tj-1n
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 13:37:31 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 07c6283b-cf58-11ef-99a4-01e77a169b0f;
 Fri, 10 Jan 2025 14:37:28 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1736516239821980.5272888487415;
 Fri, 10 Jan 2025 05:37:19 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 07c6283b-cf58-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; t=1736516244; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=iCniKCbNnMJYNjn/ZD0z4IMjel+Tq6tyKRIoM+H2JOvAkABs3BOYwSrNC4sq4pJSd+7+/s2A9m3xjIayK7NwZoCnj5RMMZ3m6gHFPX9+yL9nPQ/blZGo42X0Zf8I+QJqgt1s1fE+HRdPvYMsyQ3ZUw41mUSnN27NVR78JeMerAk=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1736516244; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=lrxUF4Nr7UTugHk+71rew1iL+Fa9qU2pLi+pxaWL6/8=; 
	b=SVWNLvwQRA1eN6caqCwMD8sjJ2FdustrA/g5UhNvMyAlBN6x81ey+rIMUo6Lx1KNa0EHfTuFK7PSOsJMImghS8Z1L4ZpqMba5cZaI+n1SB1ueVqMz054QDFw9afUA07YJZftACC3xcjLebVp/nGAfW5LASNh7RDYmjQIKQL73Dg=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1736516244;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=lrxUF4Nr7UTugHk+71rew1iL+Fa9qU2pLi+pxaWL6/8=;
	b=LxbhPdJsxH1FkPBXM+vNXcPRWJOSMJHrSxp7x2F8Z9O9cWUq8OjPjEZFOBq3NxKM
	O5s+BUOiq61eHDqBYr0U/D0E8m0CDU+cUUmGLzrpqm4t/wiPMTJ5LR+iyCotbUAMZl4
	xNERpYu7+6HZq/tkGEcPCEc6fevXvwpIIAcdNNC8=
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
To: xen-devel@lists.xenproject.org
Cc: openxt@googlegroups.com,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Christopher Clark <christopher.w.clark@gmail.com>
Subject: [PATCH 0/2] Enable the ability to disable/remove gnttabv2
Date: Fri, 10 Jan 2025 13:37:09 +0000
Message-Id: <20250110133711.3958202-1-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

OpenXT has carried a patch for some time that allows the disabling and removal
of the grant table v2 capability. This is a rework of that patch in an attempt
to make an upstreamable series.

The original patch was developed under funding provided by BAE, therefore a
separate Authored-by tag to reflect that is included.

Daniel P. Smith (2):
  gnttab: introduce version agnostic macros
  gnttab: make grant table v2 support configurable

 docs/misc/xen-command-line.pandoc |   4 +-
 xen/common/Kconfig                |  18 +++
 xen/common/compat/grant_table.c   |   4 +
 xen/common/grant_table.c          | 200 +++++++++++++++++++-----------
 4 files changed, 150 insertions(+), 76 deletions(-)

-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Jan 10 13:37:47 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 13:37:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869622.1281073 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWFCt-0001pB-No; Fri, 10 Jan 2025 13:37:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869622.1281073; Fri, 10 Jan 2025 13:37:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWFCt-0001p4-Jv; Fri, 10 Jan 2025 13:37:47 +0000
Received: by outflank-mailman (input) for mailman id 869622;
 Fri, 10 Jan 2025 13:37: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
 <SRS0=qOMD=UC=apertussolutions.com=dpsmith@srs-se1.protection.inumbo.net>)
 id 1tWFCr-0001Tj-Qk
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 13:37:45 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 11371c7b-cf58-11ef-99a4-01e77a169b0f;
 Fri, 10 Jan 2025 14:37:43 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1736516242403449.7374866615795;
 Fri, 10 Jan 2025 05:37:22 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 11371c7b-cf58-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; t=1736516246; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=Ge2D30IO27VeqKRXwsiy17cuGJGBbakTvc8CxdUtzOlVdW76LzLwwNRmctD0/hVq6BK/JtWkQyDsrZY235PkIerA3fhnMoW3fkaoJqffEwb7SG8F58FXTn/NK+Hc7P0BAIoJhIGu1y8fxpe8MfL6TFXQNglMRcBRJ5xMz0tcBWU=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1736516246; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=zaIclZ+P2Am/QS9whECQfa2MB2jJxPcdNJMvnaSU7vM=; 
	b=GNx4exy1z6tTRp/E/vh3fiN0RiHbQhxukSPIIv8i8erugiQthxKaSTKafyHHFmdr9A8AYEtPGkKflz38Znek12cbNu1KKhUdu9aYbCWODrkPQHm7tG5QmcNWKCP9ZSUBvrqx1m+Ku1JKhHY+a5QAaT7sfhFat7iHzcI9mvTZigo=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1736516246;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=zaIclZ+P2Am/QS9whECQfa2MB2jJxPcdNJMvnaSU7vM=;
	b=CAI5rQGUA1zzYGkBfQahJwD4Vd9j4bDMPZIjf1i9GPsAP6fGef+QI5FUcc89Hp62
	4cWN3mdpCmKK6XcfwJICvNI06xgVzN9jm+S4MLTyd4vphdhg+6C3XNU2BkW4aaeXfJc
	7Q8tnDxOoZPf0Ujp/nK9VoTqFEHlhJBbWYYIH8Ck=
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
To: xen-devel@lists.xenproject.org
Cc: openxt@googlegroups.com,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Christopher Clark <christopher.clark6@baesystems.com>,
	Christopher Clark <christopher.w.clark@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH 1/2] gnttab: introduce version agnostic macros
Date: Fri, 10 Jan 2025 13:37:10 +0000
Message-Id: <20250110133711.3958202-2-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250110133711.3958202-1-dpsmith@apertussolutions.com>
References: <20250110133711.3958202-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

Introduce a set of macros that abstract version specifics of the grant table
structures. This lays the ground work for being able to turn off v2 logic and
code.

Authored-by: Christopher Clark <christopher.clark6@baesystems.com>
Signed-off-by: Christopher Clark <christopher.w.clark@gmail.com>
Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
---
 xen/common/grant_table.c | 114 +++++++++++++++++----------------------
 1 file changed, 48 insertions(+), 66 deletions(-)

diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 6c77867f8c..f70a5333d8 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -181,6 +181,7 @@ static int cf_check parse_gnttab_max_maptrack_frames(const char *arg)
 #ifndef GNTTAB_MAX_VERSION
 #define GNTTAB_MAX_VERSION 2
 #endif
+#define get_gt_version(gt) ((gt)->gt_version)
 
 unsigned int __read_mostly opt_gnttab_max_version = GNTTAB_MAX_VERSION;
 static bool __read_mostly opt_transitive_grants = true;
@@ -310,16 +311,30 @@ nr_maptrack_frames(struct grant_table *t)
 #define SHGNT_PER_PAGE_V1 (PAGE_SIZE / sizeof(grant_entry_v1_t))
 #define shared_entry_v1(t, e) \
     ((t)->shared_v1[(e)/SHGNT_PER_PAGE_V1][(e)%SHGNT_PER_PAGE_V1])
+
+/* Operations providing a single interface agnostic to grant table version */
 #define SHGNT_PER_PAGE_V2 (PAGE_SIZE / sizeof(grant_entry_v2_t))
 #define shared_entry_v2(t, e) \
     ((t)->shared_v2[(e)/SHGNT_PER_PAGE_V2][(e)%SHGNT_PER_PAGE_V2])
+
+#define shared_entry_full_frame(gt, ref) \
+    ( get_gt_version(gt) == 1 ? shared_entry_v1((gt), (ref)).frame : \
+                                shared_entry_v2((gt), (ref)).full_page.frame )
+#define set_shared_entry(gt, ref, val) \
+    ( get_gt_version(gt) == 1 ? (shared_entry_v1((gt), (ref)).frame = (val)) : \
+                                (shared_entry_v2((gt), (ref)).full_page.frame = (val)) )
+#define status_addr(gt, ref, flags_addr) \
+    ( evaluate_nospec(get_gt_version(gt) == 1) ? (flags_addr) : &status_entry((gt), (ref)) )
+
 #define STGNT_PER_PAGE (PAGE_SIZE / sizeof(grant_status_t))
 #define status_entry(t, e) \
     ((t)->status[(e)/STGNT_PER_PAGE][(e)%STGNT_PER_PAGE])
+
+
 static grant_entry_header_t *
 shared_entry_header(struct grant_table *t, grant_ref_t ref)
 {
-    switch ( t->gt_version )
+    switch ( get_gt_version(t) )
     {
     case 1:
         /* Returned values should be independent of speculative execution */
@@ -709,7 +724,7 @@ get_maptrack_handle(
 /* Number of grant table entries. Caller must hold d's grant table lock. */
 static unsigned int nr_grant_entries(struct grant_table *gt)
 {
-    switch ( gt->gt_version )
+    switch ( get_gt_version(gt) )
     {
 #define f2e(nr, ver) (((nr) << PAGE_SHIFT) / sizeof(grant_entry_v##ver##_t))
     case 1:
@@ -1090,23 +1105,20 @@ map_grant_ref(
     }
 
     /* Make sure we do not access memory speculatively */
-    status = evaluate_nospec(rgt->gt_version == 1) ? &shah->flags
-                                                   : &status_entry(rgt, ref);
+    status = status_addr(rgt, ref, &shah->flags);
 
     if ( !act->pin ||
          (!(op->flags & GNTMAP_readonly) &&
           !(act->pin & (GNTPIN_hstw_mask|GNTPIN_devw_mask))) )
     {
-        if ( (rc = _set_status(shah, status, rd, rgt->gt_version, act,
+        if ( (rc = _set_status(shah, status, rd, get_gt_version(rgt), act,
                                op->flags & GNTMAP_readonly, 1,
                                ld->domain_id)) != GNTST_okay )
             goto act_release_out;
 
         if ( !act->pin )
         {
-            unsigned long gfn = evaluate_nospec(rgt->gt_version == 1) ?
-                                shared_entry_v1(rgt, ref).frame :
-                                shared_entry_v2(rgt, ref).full_page.frame;
+            unsigned long gfn = shared_entry_full_frame(rgt, ref);
 
             rc = get_paged_frame(gfn, &mfn, &pg,
                                  op->flags & GNTMAP_readonly, rd);
@@ -1603,11 +1615,7 @@ unmap_common_complete(struct gnttab_unmap_common *op)
 
     act = active_entry_acquire(rgt, op->ref);
     sha = shared_entry_header(rgt, op->ref);
-
-    if ( evaluate_nospec(rgt->gt_version == 1) )
-        status = &sha->flags;
-    else
-        status = &status_entry(rgt, op->ref);
+    status = status_addr(rgt, op->ref, &sha->flags);
 
     pg = !is_iomem_page(act->mfn) ? mfn_to_page(op->mfn) : NULL;
 
@@ -1930,7 +1938,7 @@ gnttab_grow_table(struct domain *d, unsigned int req_nr_frames)
     }
 
     /* Status pages - version 2 */
-    if ( evaluate_nospec(gt->gt_version > 1) )
+    if ( evaluate_nospec(get_gt_version(gt) > 1) )
     {
         if ( gnttab_populate_status_frames(d, gt, req_nr_frames) )
             goto shared_alloc_failed;
@@ -2105,7 +2113,7 @@ gnttab_setup_table(
     }
 
     if ( (op.nr_frames > nr_grant_frames(gt) ||
-          ((gt->gt_version > 1) &&
+          ((get_gt_version(gt) > 1) &&
            (grant_to_status_frames(op.nr_frames) > nr_status_frames(gt)))) &&
          gnttab_grow_table(d, op.nr_frames) )
     {
@@ -2267,6 +2275,7 @@ gnttab_transfer(
     mfn_t mfn;
     unsigned int max_bitsize;
     struct active_grant_entry *act;
+    unsigned long frame;
 
     if ( !opt_grant_transfer )
         return -EOPNOTSUPP;
@@ -2354,7 +2363,7 @@ gnttab_transfer(
         }
 
         max_bitsize = domain_clamp_alloc_bitsize(
-            e, e->grant_table->gt_version > 1 || paging_mode_translate(e)
+            e, get_gt_version(e->grant_table) > 1 || paging_mode_translate(e)
                ? BITS_PER_LONG + PAGE_SHIFT : 32 + PAGE_SHIFT);
         if ( max_bitsize < BITS_PER_LONG + PAGE_SHIFT &&
              (mfn_x(mfn) >> (max_bitsize - PAGE_SHIFT)) )
@@ -2452,22 +2461,12 @@ gnttab_transfer(
         grant_read_lock(e->grant_table);
         act = active_entry_acquire(e->grant_table, gop.ref);
 
-        if ( evaluate_nospec(e->grant_table->gt_version == 1) )
-        {
-            grant_entry_v1_t *sha = &shared_entry_v1(e->grant_table, gop.ref);
+        frame = shared_entry_full_frame(e->grant_table, gop.ref);
+        rc = guest_physmap_add_page(e, _gfn(frame), mfn, 0);
 
-            rc = guest_physmap_add_page(e, _gfn(sha->frame), mfn, 0);
-            if ( !paging_mode_translate(e) )
-                sha->frame = mfn_x(mfn);
-        }
-        else
-        {
-            grant_entry_v2_t *sha = &shared_entry_v2(e->grant_table, gop.ref);
+        if ( !paging_mode_translate(e) )
+            set_shared_entry(e->grant_table, gop.ref, mfn_x(mfn));
 
-            rc = guest_physmap_add_page(e, _gfn(sha->full_page.frame), mfn, 0);
-            if ( !paging_mode_translate(e) )
-                sha->full_page.frame = mfn_x(mfn);
-        }
         smp_wmb();
         shared_entry_header(e->grant_table, gop.ref)->flags |=
             GTF_transfer_completed;
@@ -2512,16 +2511,15 @@ release_grant_for_copy(
     act = active_entry_acquire(rgt, gref);
     sha = shared_entry_header(rgt, gref);
     mfn = act->mfn;
+    status = status_addr(rgt, gref, &sha->flags);
 
-    if ( evaluate_nospec(rgt->gt_version == 1) )
+    if ( evaluate_nospec(get_gt_version(rgt) == 1) )
     {
-        status = &sha->flags;
         td = rd;
         trans_gref = gref;
     }
     else
     {
-        status = &status_entry(rgt, gref);
         td = (act->src_domid == rd->domain_id)
              ? rd : knownalive_domain_from_domid(act->src_domid);
         trans_gref = act->trans_gref;
@@ -2573,7 +2571,6 @@ acquire_grant_for_copy(
     struct active_grant_entry *act;
     grant_status_t *status;
     uint32_t old_pin;
-    domid_t trans_domid;
     grant_ref_t trans_gref;
     struct domain *td;
     mfn_t grant_mfn;
@@ -2597,6 +2594,7 @@ acquire_grant_for_copy(
     /* This call also ensures the above check cannot be passed speculatively */
     shah = shared_entry_header(rgt, gref);
     act = active_entry_acquire(rgt, gref);
+    old_pin = act->pin;
 
     /* If already pinned, check the active domid and avoid refcnt overflow. */
     if ( act->pin &&
@@ -2610,7 +2608,7 @@ acquire_grant_for_copy(
         goto unlock_out;
     }
 
-    if ( evaluate_nospec(rgt->gt_version == 1) )
+    if ( evaluate_nospec(get_gt_version(rgt) == 1) )
     {
         sha2 = NULL;
         status = &shah->flags;
@@ -2621,9 +2619,10 @@ acquire_grant_for_copy(
         status = &status_entry(rgt, gref);
     }
 
-    old_pin = act->pin;
     if ( sha2 && (shah->flags & GTF_type_mask) == GTF_transitive )
     {
+        domid_t trans_domid;
+
         if ( (!old_pin || (!readonly &&
                            !(old_pin & (GNTPIN_devw_mask|GNTPIN_hstw_mask)))) &&
              (rc = _set_status_v2(shah, status, rd, act, readonly, 0,
@@ -2752,7 +2751,7 @@ acquire_grant_for_copy(
     else if ( !old_pin ||
               (!readonly && !(old_pin & (GNTPIN_devw_mask|GNTPIN_hstw_mask))) )
     {
-        if ( (rc = _set_status(shah, status, rd, rgt->gt_version, act,
+        if ( (rc = _set_status(shah, status, rd, get_gt_version(rgt), act,
                                readonly, 0, ldom)) != GNTST_okay )
              goto unlock_out;
 
@@ -3406,7 +3405,7 @@ gnttab_get_version(XEN_GUEST_HANDLE_PARAM(gnttab_get_version_t) uop)
         return rc;
     }
 
-    op.version = d->grant_table->gt_version;
+    op.version = get_gt_version(d->grant_table);
 
     rcu_unlock_domain(d);
 
@@ -3464,7 +3463,7 @@ swap_grant_ref(grant_ref_t ref_a, grant_ref_t ref_b)
         goto out;
     }
 
-    if ( evaluate_nospec(gt->gt_version == 1) )
+    if ( evaluate_nospec(get_gt_version(gt) == 1) )
     {
         grant_entry_v1_t shared;
 
@@ -3878,10 +3877,7 @@ int gnttab_release_mappings(struct domain *d)
 
         act = active_entry_acquire(rgt, ref);
         sha = shared_entry_header(rgt, ref);
-        if ( rgt->gt_version == 1 )
-            status = &sha->flags;
-        else
-            status = &status_entry(rgt, ref);
+        status = status_addr(rgt, ref, &sha->flags);
 
         pg = !is_iomem_page(act->mfn) ? mfn_to_page(act->mfn) : NULL;
 
@@ -4047,11 +4043,11 @@ int mem_sharing_gref_to_gfn(struct grant_table *gt, grant_ref_t ref,
 
     grant_read_lock(gt);
 
-    if ( gt->gt_version < 1 )
+    if ( get_gt_version(gt) < 1 )
         rc = -EINVAL;
     else if ( ref >= nr_grant_entries(gt) )
         rc = -ENOENT;
-    else if ( evaluate_nospec(gt->gt_version == 1) )
+    else if ( evaluate_nospec(get_gt_version(gt) == 1) )
     {
         const grant_entry_v1_t *sha1 = &shared_entry_v1(gt, ref);
 
@@ -4072,12 +4068,7 @@ int mem_sharing_gref_to_gfn(struct grant_table *gt, grant_ref_t ref,
     if ( !rc && (flags & GTF_type_mask) != GTF_permit_access )
         rc = -ENXIO;
     else if ( !rc && status )
-    {
-        if ( evaluate_nospec(gt->gt_version == 1) )
-            *status = flags;
-        else
-            *status = status_entry(gt, ref);
-    }
+        *status = *status_addr(gt, ref, &flags);
 
     grant_read_unlock(gt);
 
@@ -4131,7 +4122,7 @@ static int gnttab_get_shared_frame_mfn(struct domain *d,
 {
     const struct grant_table *gt = d->grant_table;
 
-    ASSERT(gt->gt_version != 0);
+    ASSERT(get_gt_version(gt) != 0);
 
     if ( idx >= nr_grant_frames(gt) )
     {
@@ -4204,7 +4195,7 @@ int gnttab_acquire_resource(
         break;
 
     case XENMEM_resource_grant_table_id_status:
-        if ( gt->gt_version != 2 )
+        if ( get_gt_version(gt) != 2 )
             break;
 
         /* Check that void ** is a suitable representation for gt->status. */
@@ -4256,7 +4247,7 @@ int gnttab_map_frame(struct domain *d, unsigned long idx, gfn_t gfn, mfn_t *mfn)
 
     grant_write_lock(gt);
 
-    if ( evaluate_nospec(gt->gt_version == 2) && (idx & XENMAPIDX_grant_table_status) )
+    if ( evaluate_nospec(get_gt_version(gt) == 2) && (idx & XENMAPIDX_grant_table_status) )
     {
         idx &= ~XENMAPIDX_grant_table_status;
         status = true;
@@ -4299,7 +4290,7 @@ static void gnttab_usage_print(struct domain *rd)
 
     printk("grant-table for remote d%d (v%u)\n"
            "  %u frames (%u max), %u maptrack frames (%u max)\n",
-           rd->domain_id, gt->gt_version,
+           rd->domain_id, get_gt_version(gt),
            nr_grant_frames(gt), gt->max_grant_frames,
            nr_maptrack_frames(gt), gt->max_maptrack_frames);
 
@@ -4319,17 +4310,8 @@ static void gnttab_usage_print(struct domain *rd)
         }
 
         sha = shared_entry_header(gt, ref);
-
-        if ( gt->gt_version == 1 )
-        {
-            status = sha->flags;
-            frame = shared_entry_v1(gt, ref).frame;
-        }
-        else
-        {
-            frame = shared_entry_v2(gt, ref).full_page.frame;
-            status = status_entry(gt, ref);
-        }
+        frame = shared_entry_full_frame(gt, ref);
+        status = *status_addr(gt, ref, &sha->flags);
 
         first = 0;
 
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Jan 10 13:38:09 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 13:38:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869631.1281084 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWFDF-0002OB-0f; Fri, 10 Jan 2025 13:38:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869631.1281084; Fri, 10 Jan 2025 13:38:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWFDE-0002O0-SI; Fri, 10 Jan 2025 13:38:08 +0000
Received: by outflank-mailman (input) for mailman id 869631;
 Fri, 10 Jan 2025 13:38:07 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=qOMD=UC=apertussolutions.com=dpsmith@srs-se1.protection.inumbo.net>)
 id 1tWFDD-0001Tj-64
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 13:38:07 +0000
Received: from sender4-of-o55.zoho.com (sender4-of-o55.zoho.com
 [136.143.188.55]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1dec5cbd-cf58-11ef-99a4-01e77a169b0f;
 Fri, 10 Jan 2025 14:38:05 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1736516244589260.226896086339;
 Fri, 10 Jan 2025 05:37:24 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1dec5cbd-cf58-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; t=1736516248; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=bge0Npc/yvPU1apIcJZbnCEPHtSDLNiWHQEes6IXzR11LFr2g+Rer8Mdno4C3hhz+AMo3UyWLb8U961X9X1weRlakrP3ZPJnbl6RsmZg+cWwirBv4UsEqOLh2eqYPs3r2mnvnZy0zK8AWUlA+Po2A1sagQYaz5fxuAXTWq+FWk8=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1736516248; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=TalMMxffA22obSkpHJA9+pUFlwopohYfLzoxicDrWAg=; 
	b=Bus479CXW8jQiMoj/E8VrbpfuMVq2MQnaeAKvoQx64BLfAD0JxSbzv2IU3yJBTDsEbW2jqjRb9XPDhGs1OlXILN43+cP1O32WQAD7lpjdUbfK0AOaRwxbYlYPuUHxpgXhJVMSJql8QDhXEcAWDCEAkDWH/1OIdpAgi/hDtAFkvg=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1736516247;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=TalMMxffA22obSkpHJA9+pUFlwopohYfLzoxicDrWAg=;
	b=EtqP8zZ/pq3H7AitaRFXzFZTH43FLC3HWFT7sJfd/FOg7QNBWH85j+jj77GD863w
	dyYBxwdc/G6IBxFt3GITX+8RWkGrkvPVyHj6RFHFthpJZcGg7gUwIQHW9bHqUqRBXYi
	+zNblgrmL1eKYzXSFggPCviUYRcSZnfdizlrxn7k=
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
To: xen-devel@lists.xenproject.org
Cc: openxt@googlegroups.com,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Christopher Clark <christopher.clark6@baesystems.com>,
	Christopher Clark <christopher.w.clark@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH 2/2] gnttab: make grant table v2 support configurable
Date: Fri, 10 Jan 2025 13:37:11 +0000
Message-Id: <20250110133711.3958202-3-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250110133711.3958202-1-dpsmith@apertussolutions.com>
References: <20250110133711.3958202-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

If the v2 interface support is not required, disabling this option will remove
substantial amounts of unused code in a critical subsystem.

Disables the v2-only GNTTABOP_get_status_frames grant table op.

Authored-by: Christopher Clark <christopher.clark6@baesystems.com>
Signed-off-by: Christopher Clark <christopher.w.clark@gmail.com>
Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
---
 docs/misc/xen-command-line.pandoc |  4 +-
 xen/common/Kconfig                | 18 +++++++
 xen/common/compat/grant_table.c   |  4 ++
 xen/common/grant_table.c          | 86 ++++++++++++++++++++++++++++---
 4 files changed, 102 insertions(+), 10 deletions(-)

diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index 08b0053f9c..61570308c5 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -1278,8 +1278,8 @@ does not provide `VM_ENTRY_LOAD_GUEST_PAT`.
 
 Control various aspects of the grant table behaviour available to guests.
 
-* `max-ver` Select the maximum grant table version to offer to guests.  Valid
-version are 1 and 2.
+* `max-ver` Select the maximum grant table version to offer to guests. Only
+available when CONFIG_GRANT_TABLE_V2 is set. Valid version are 1 and 2.
 * `transitive` Permit or disallow the use of transitive grants.  Note that the
 use of grant table v2 without transitive grants is an ABI breakage from the
 guests point of view.
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 6166327f4d..378436ca2f 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -23,6 +23,24 @@ config GRANT_TABLE
 
 	  If unsure, say Y.
 
+config GRANT_TABLE_V2
+	bool "Grant table version 2 support" if EXPERT
+	depends on GRANT_TABLE && X86
+	help
+	  Grant table interface version 2 is not the default. It has never
+	  been implemented for ARM.
+
+	  The version 2 interface enables support for systems with large amounts
+	  of memory and some exotic grant primitives that are not in use by the
+	  supported PV drivers.
+
+	  Disabling this option reduces the amount of complex security-critical
+	  hypervisor code in a subsystem of Xen responsible for approximately
+	  5% of Xen Security Advisories.
+
+	  If you do not require large memory support, say N.
+	  If you are paranoid, say N. If unsure, say Y.
+
 config PDX_COMPRESSION
 	bool "PDX (Page inDeX) compression" if EXPERT && !X86 && !RISCV
 	default ARM || PPC
diff --git a/xen/common/compat/grant_table.c b/xen/common/compat/grant_table.c
index bbb717bf64..03b99f99dd 100644
--- a/xen/common/compat/grant_table.c
+++ b/xen/common/compat/grant_table.c
@@ -296,6 +296,9 @@ int compat_grant_table_op(
             break;
 
         case GNTTABOP_get_status_frames:
+#ifndef CONFIG_GRANT_TABLE_V2
+            rc = -ENOSYS;
+#else
             if ( count != 1)
             {
                 rc = -EINVAL;
@@ -328,6 +331,7 @@ int compat_grant_table_op(
                 else
                     i = 1;
             }
+#endif
             break;
 
         default:
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index f70a5333d8..3a32e44f24 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -59,11 +59,13 @@ struct grant_table {
     /* Lock protecting the maptrack limit */
     spinlock_t            maptrack_lock;
     unsigned int          max_version;
+#ifdef CONFIG_GRANT_TABLE_V2
     /*
      * Defaults to v1.  May be changed with GNTTABOP_set_version.  All other
      * values are invalid.
      */
     unsigned int          gt_version;
+#endif
     /* Resource limits of the domain. */
     unsigned int          max_grant_frames;
     unsigned int          max_maptrack_frames;
@@ -83,7 +85,9 @@ struct grant_table {
     union {
         void **shared_raw;
         struct grant_entry_v1 **shared_v1;
+#ifdef CONFIG_GRANT_TABLE_V2
         union grant_entry_v2 **shared_v2;
+#endif
     };
     /* State grant table (see include/public/grant_table.h). */
     grant_status_t       **status;
@@ -178,11 +182,20 @@ static int cf_check parse_gnttab_max_maptrack_frames(const char *arg)
                               opt_max_maptrack_frames_val);
 }
 
+#ifdef CONFIG_GRANT_TABLE_V2
+
 #ifndef GNTTAB_MAX_VERSION
 #define GNTTAB_MAX_VERSION 2
 #endif
 #define get_gt_version(gt) ((gt)->gt_version)
 
+#else
+
+#define GNTTAB_MAX_VERSION 1
+#define get_gt_version(gt) 1
+
+#endif
+
 unsigned int __read_mostly opt_gnttab_max_version = GNTTAB_MAX_VERSION;
 static bool __read_mostly opt_transitive_grants = true;
 #ifdef CONFIG_PV
@@ -193,7 +206,7 @@ static bool __ro_after_init opt_grant_transfer = true;
 
 static int __init cf_check parse_gnttab(const char *s)
 {
-    const char *ss, *e;
+    const char *ss;
     int val, rc = 0;
 
     do {
@@ -204,12 +217,17 @@ static int __init cf_check parse_gnttab(const char *s)
         if ( !strncmp(s, "max-ver:", 8) ||
              !strncmp(s, "max_ver:", 8) ) /* Alias for original XSA-226 patch */
         {
+#ifdef CONFIG_GRANT_TABLE_V2
+            const char *e;
             long ver = simple_strtol(s + 8, &e, 10);
 
             if ( e == ss && ver >= 1 && ver <= 2 )
                 opt_gnttab_max_version = ver;
             else
                 rc = -EINVAL;
+#else
+            no_config_param("GRANT_TABLE_V2", "max_ver", s, ss);
+#endif
         }
         else if ( (val = parse_boolean("transitive", s, ss)) >= 0 )
             opt_transitive_grants = val;
@@ -313,6 +331,8 @@ nr_maptrack_frames(struct grant_table *t)
     ((t)->shared_v1[(e)/SHGNT_PER_PAGE_V1][(e)%SHGNT_PER_PAGE_V1])
 
 /* Operations providing a single interface agnostic to grant table version */
+#ifdef CONFIG_GRANT_TABLE_V2
+
 #define SHGNT_PER_PAGE_V2 (PAGE_SIZE / sizeof(grant_entry_v2_t))
 #define shared_entry_v2(t, e) \
     ((t)->shared_v2[(e)/SHGNT_PER_PAGE_V2][(e)%SHGNT_PER_PAGE_V2])
@@ -330,6 +350,14 @@ nr_maptrack_frames(struct grant_table *t)
 #define status_entry(t, e) \
     ((t)->status[(e)/STGNT_PER_PAGE][(e)%STGNT_PER_PAGE])
 
+#else /* CONFIG_GRANT_TABLE_V2 */
+
+#define shared_entry_full_frame(gt, ref) ( shared_entry_v1((gt), (ref)).frame )
+#define set_shared_entry(gt, ref, val) \
+    ( shared_entry_v1((gt), (ref)).frame = (val) )
+#define status_addr(gt, ref, flags_addr) (flags_addr)
+
+#endif /* CONFIG_GRANT_TABLE_V2 */
 
 static grant_entry_header_t *
 shared_entry_header(struct grant_table *t, grant_ref_t ref)
@@ -341,10 +369,12 @@ shared_entry_header(struct grant_table *t, grant_ref_t ref)
         block_speculation();
         return (grant_entry_header_t*)&shared_entry_v1(t, ref);
 
+#ifdef CONFIG_GRANT_TABLE_V2
     case 2:
         /* Returned values should be independent of speculative execution */
         block_speculation();
         return &shared_entry_v2(t, ref).hdr;
+#endif
     }
 
     ASSERT_UNREACHABLE();
@@ -734,7 +764,7 @@ static unsigned int nr_grant_entries(struct grant_table *gt)
         /* Make sure we return a value independently of speculative execution */
         block_speculation();
         return f2e(nr_grant_frames(gt), 1);
-
+#ifdef CONFIG_GRANT_TABLE_V2
     case 2:
         BUILD_BUG_ON(f2e(INITIAL_NR_GRANT_FRAMES, 2) <
                      GNTTAB_NR_RESERVED_ENTRIES);
@@ -742,6 +772,7 @@ static unsigned int nr_grant_entries(struct grant_table *gt)
         /* Make sure we return a value independently of speculative execution */
         block_speculation();
         return f2e(nr_grant_frames(gt), 2);
+#endif
 #undef f2e
     }
 
@@ -834,6 +865,7 @@ done:
     return rc;
 }
 
+#ifdef CONFIG_GRANT_TABLE_V2
 static int _set_status_v2(const grant_entry_header_t *shah,
                           grant_status_t *status,
                           struct domain *rd,
@@ -918,7 +950,7 @@ static int _set_status_v2(const grant_entry_header_t *shah,
 done:
     return rc;
 }
-
+#endif
 
 static int _set_status(const grant_entry_header_t *shah,
                        grant_status_t *status,
@@ -929,11 +961,11 @@ static int _set_status(const grant_entry_header_t *shah,
                        int mapflag,
                        domid_t ldomid)
 {
-
-    if ( evaluate_nospec(rgt_version == 1) )
-        return _set_status_v1(shah, rd, act, readonly, mapflag, ldomid);
-    else
+#ifdef CONFIG_GRANT_TABLE_V2
+    if ( evaluate_nospec(rgt_version != 1) )
         return _set_status_v2(shah, status, rd, act, readonly, mapflag, ldomid);
+#endif
+    return _set_status_v1(shah, rd, act, readonly, mapflag, ldomid);
 }
 
 /*
@@ -1796,6 +1828,12 @@ static int
 gnttab_populate_status_frames(struct domain *d, struct grant_table *gt,
                               unsigned int req_nr_frames)
 {
+#ifndef CONFIG_GRANT_TABLE_V2
+    ASSERT_UNREACHABLE();
+
+    return 0;
+}
+#else
     unsigned int i;
     unsigned int req_status_frames;
 
@@ -1898,6 +1936,7 @@ gnttab_unpopulate_status_frames(struct domain *d, struct grant_table *gt)
 
     return 0;
 }
+#endif
 
 /*
  * Grow the grant table. The caller must hold the grant table's
@@ -2010,7 +2049,9 @@ int grant_table_init(struct domain *d, int max_grant_frames,
     percpu_rwlock_resource_init(&gt->lock, grant_rwlock);
     spin_lock_init(&gt->maptrack_lock);
 
+#ifdef CONFIG_GRANT_TABLE_V2
     gt->gt_version = 1;
+#endif
     gt->max_grant_frames = max_grant_frames;
     gt->max_maptrack_frames = max_maptrack_frames;
     gt->max_version = max_grant_version;
@@ -2518,12 +2559,14 @@ release_grant_for_copy(
         td = rd;
         trans_gref = gref;
     }
+#ifdef CONFIG_GRANT_TABLE_V2
     else
     {
         td = (act->src_domid == rd->domain_id)
              ? rd : knownalive_domain_from_domid(act->src_domid);
         trans_gref = act->trans_gref;
     }
+#endif
 
     if ( readonly )
     {
@@ -2613,6 +2656,7 @@ acquire_grant_for_copy(
         sha2 = NULL;
         status = &shah->flags;
     }
+#ifdef CONFIG_GRANT_TABLE_V2
     else
     {
         sha2 = &shared_entry_v2(rgt, gref);
@@ -2748,7 +2792,9 @@ acquire_grant_for_copy(
             act->is_sub_page = true;
         }
     }
-    else if ( !old_pin ||
+    else
+#endif
+    if ( !old_pin ||
               (!readonly && !(old_pin & (GNTPIN_devw_mask|GNTPIN_hstw_mask))) )
     {
         if ( (rc = _set_status(shah, status, rd, get_gt_version(rgt), act,
@@ -3165,6 +3211,17 @@ static long
 gnttab_set_version(XEN_GUEST_HANDLE_PARAM(gnttab_set_version_t) uop)
 {
     gnttab_set_version_t op;
+#ifndef CONFIG_GRANT_TABLE_V2
+
+    if ( copy_from_guest(&op, uop, 1) )
+        return -EFAULT;
+
+    if ( op.version == 1 )
+        return 0;
+
+    /* Behave as before set_version was introduced. */
+    return -ENOSYS;
+#else
     struct domain *currd = current->domain;
     struct grant_table *gt = currd->grant_table;
     grant_entry_v1_t reserved_entries[GNTTAB_NR_RESERVED_ENTRIES];
@@ -3309,8 +3366,10 @@ gnttab_set_version(XEN_GUEST_HANDLE_PARAM(gnttab_set_version_t) uop)
         res = -EFAULT;
 
     return res;
+#endif
 }
 
+#ifdef CONFIG_GRANT_TABLE_V2
 static long
 gnttab_get_status_frames(XEN_GUEST_HANDLE_PARAM(gnttab_get_status_frames_t) uop,
                          unsigned int count)
@@ -3383,6 +3442,7 @@ gnttab_get_status_frames(XEN_GUEST_HANDLE_PARAM(gnttab_get_status_frames_t) uop,
 
     return 0;
 }
+#endif
 
 static long
 gnttab_get_version(XEN_GUEST_HANDLE_PARAM(gnttab_get_version_t) uop)
@@ -3471,6 +3531,7 @@ swap_grant_ref(grant_ref_t ref_a, grant_ref_t ref_b)
         shared_entry_v1(gt, ref_a) = shared_entry_v1(gt, ref_b);
         shared_entry_v1(gt, ref_b) = shared;
     }
+#ifdef CONFIG_GRANT_TABLE_V2
     else
     {
         grant_entry_v2_t shared;
@@ -3485,6 +3546,7 @@ swap_grant_ref(grant_ref_t ref_a, grant_ref_t ref_b)
         shared_entry_v2(gt, ref_b) = shared;
         status_entry(gt, ref_b) = status;
     }
+#endif
 
 out:
     if ( act_b != NULL )
@@ -3747,10 +3809,12 @@ long do_grant_table_op(
         rc = gnttab_set_version(guest_handle_cast(uop, gnttab_set_version_t));
         break;
 
+#ifdef CONFIG_GRANT_TABLE_V2
     case GNTTABOP_get_status_frames:
         rc = gnttab_get_status_frames(
             guest_handle_cast(uop, gnttab_get_status_frames_t), count);
         break;
+#endif
 
     case GNTTABOP_get_version:
         rc = gnttab_get_version(guest_handle_cast(uop, gnttab_get_version_t));
@@ -4054,6 +4118,7 @@ int mem_sharing_gref_to_gfn(struct grant_table *gt, grant_ref_t ref,
         flags = sha1->flags;
         *gfn = _gfn(sha1->frame);
     }
+#ifdef CONFIG_GRANT_TABLE_V2
     else
     {
         const grant_entry_v2_t *sha2 = &shared_entry_v2(gt, ref);
@@ -4064,6 +4129,7 @@ int mem_sharing_gref_to_gfn(struct grant_table *gt, grant_ref_t ref,
         else
            *gfn = _gfn(sha2->full_page.frame);
     }
+#endif
 
     if ( !rc && (flags & GTF_type_mask) != GTF_permit_access )
         rc = -ENXIO;
@@ -4080,6 +4146,9 @@ int mem_sharing_gref_to_gfn(struct grant_table *gt, grant_ref_t ref,
 static int gnttab_get_status_frame_mfn(struct domain *d,
                                        unsigned int idx, mfn_t *mfn)
 {
+#ifndef CONFIG_GRANT_TABLE_V2
+    ASSERT_UNREACHABLE();
+#else
     const struct grant_table *gt = d->grant_table;
 
     ASSERT(gt->gt_version == 2);
@@ -4113,6 +4182,7 @@ static int gnttab_get_status_frame_mfn(struct domain *d,
     /* Make sure idx is bounded wrt nr_status_frames */
     *mfn = _mfn(virt_to_mfn(
                 gt->status[array_index_nospec(idx, nr_status_frames(gt))]));
+#endif
     return 0;
 }
 
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Jan 10 14:02:10 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 14:02:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869651.1281103 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWFaL-0008Lw-3h; Fri, 10 Jan 2025 14:02:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869651.1281103; Fri, 10 Jan 2025 14:02:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWFaL-0008Lp-0m; Fri, 10 Jan 2025 14:02:01 +0000
Received: by outflank-mailman (input) for mailman id 869651;
 Fri, 10 Jan 2025 14:02:00 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=J0bo=UC=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tWFaK-00087j-HY
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 14:02:00 +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 75d56e1f-cf5b-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 15:01:59 +0100 (CET)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-aaf900cc7fbso396605266b.3
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 06:02:00 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c95af680sm172606166b.141.2025.01.10.06.01.58
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 10 Jan 2025 06:01:58 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 75d56e1f-cf5b-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736517719; x=1737122519; 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=c/I7HoDRHZV0XTx2nTCcpli5SpYI0/lHKSshoL/AVNY=;
        b=QMinFTb7SbAa341SjgNGEyyBkdnnG5yi+3eqU9cWVeAoyldRz6kHfZtrMTHPPNHSVi
         C1XFLytJS6HM3QudySM16wCcgiHcXJHKSrup3U6j+ehsdooENjKcSEjQ8OrpLsVuhT0d
         hDIZCuFMOpqOI55mnNWKBBsh5oeoUDDTSvidc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736517719; x=1737122519;
        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=c/I7HoDRHZV0XTx2nTCcpli5SpYI0/lHKSshoL/AVNY=;
        b=h7iejfp883N1VdvX9UARZ+1C62h/P0dboNePuQXqxRE1MEH9VRZ3yeylNu5M5jRlHF
         ygJgL6OcwlQLtoGq5y5MP9bF2mHgVXs1Uxg9++Fg7T9tZLmD2V6HXyJL86ROtUygG/qf
         JR8PwbTHjPVZ+PocyFH7UmV4FqaoirMlRVVKMNhtGapkkSTlVDPziPsQua3eTf8Fr0Tr
         fCEOgvPy7L9a05ToTKkxg6Rxe/PKa8mvUzlPw5abRUY5mBdUf2MscCMdCSvJR/mHTK1Z
         5rNwQAZpZZYskln1rAUWAOCQZEUx/azVgd32vZq5sTsxrNqSkjOCRUoYafQRSXDh5sKP
         uHsw==
X-Forwarded-Encrypted: i=1; AJvYcCUpZoKL7RkCA9YQwGjQOpDgataz5ls89gWPDQqLSqIvpI2fdQ8v1dbIY5IDDFsObqN+egVB02gvPU8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwOmuG3ctGO8MiO8ZuK+aQx9HPFFs1F9fJ3Pgul6bEujSwrUxiP
	tMT2wNKT+2OJpkbhJ7o57HmcAJXTZzJvGfEU6sI9hwCq7ep3Tj45jdIMyVyFE14=
X-Gm-Gg: ASbGncurGt2Wd22JaTu9/D+uIcq7yzu9F9n4zH8W58Is62WFgwkKM9kwBzYX0Upm6ri
	n6uSkJKxAXpt7UUYFf20ojvjiRMCQcg1xKyudc13Lmmcf2AtFDCadUTmXPpicP/R77ReUT1cf6k
	kvDWmTjTpgAi23Qa6nr5/etWp//5pLlYkVD2DlDOfIyIWoEoPs4Qb1KVyL4opaSfc9TxmXWonkI
	cSwBrS0F89GDyuqq345CyZ81zBC8M3aYBfCRz8Z6OPueOqN5QockFwJhC8ItG4l19A=
X-Google-Smtp-Source: AGHT+IHQABlx0ljsChy/AaNgLOa5tG+fbxwnozWPPmywCwKrdUKAOZN8SDFE4NcVHC8wzrW5y/A8Dw==
X-Received: by 2002:a17:907:c588:b0:ab2:c208:732d with SMTP id a640c23a62f3a-ab2c2087cbbmr743393166b.40.1736517719125;
        Fri, 10 Jan 2025 06:01:59 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: linux-kernel@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	linux-pci@vger.kernel.org
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Nirmal Patel <nirmal.patel@linux.intel.com>,
	Jonathan Derrick <jonathan.derrick@linux.dev>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	=?UTF-8?q?Krzysztof=20Wilczy=C5=84ski?= <kw@linux.com>,
	Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
	Rob Herring <robh@kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>
Subject: [PATCH 2/3] vmd: disable MSI remapping bypass under Xen
Date: Fri, 10 Jan 2025 15:01:49 +0100
Message-ID: <20250110140152.27624-3-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250110140152.27624-1-roger.pau@citrix.com>
References: <20250110140152.27624-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

MSI remapping bypass (directly configuring MSI entries for devices on the VMD
bus) won't work under Xen, as Xen is not aware of devices in such bus, and
hence cannot configure the entries using the pIRQ interface in the PV case, and
in the PVH case traps won't be setup for MSI entries for such devices.

Until Xen is aware of devices in the VMD bus prevent the
VMD_FEAT_CAN_BYPASS_MSI_REMAP capability from being used when running as any
kind of Xen guest.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 drivers/pci/controller/vmd.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
index 264a180403a0..d9b7510ace29 100644
--- a/drivers/pci/controller/vmd.c
+++ b/drivers/pci/controller/vmd.c
@@ -965,6 +965,15 @@ static int vmd_probe(struct pci_dev *dev, const struct pci_device_id *id)
 	struct vmd_dev *vmd;
 	int err;
 
+	if (xen_domain())
+		/*
+		 * Xen doesn't have knowledge about devices in the VMD bus.
+		 * Bypass of MSI remapping won't work in that case as direct
+		 * write to the MSI entries won't result in functional
+		 * interrupts.
+		 */
+		features &= ~VMD_FEAT_CAN_BYPASS_MSI_REMAP;
+
 	if (resource_size(&dev->resource[VMD_CFGBAR]) < (1 << 20))
 		return -ENOMEM;
 
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Fri Jan 10 14:02:10 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 14:02:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869650.1281093 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWFaI-00087w-TS; Fri, 10 Jan 2025 14:01:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869650.1281093; Fri, 10 Jan 2025 14:01:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWFaI-00087p-QR; Fri, 10 Jan 2025 14:01:58 +0000
Received: by outflank-mailman (input) for mailman id 869650;
 Fri, 10 Jan 2025 14:01: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
 <SRS0=J0bo=UC=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tWFaI-00087j-Gi
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 14:01:58 +0000
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com
 [2a00:1450:4864:20::62f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 73e8d95d-cf5b-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 15:01:56 +0100 (CET)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-aa6c0d1833eso440401766b.1
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 06:01:56 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c95b1d5esm170012066b.150.2025.01.10.06.01.55
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 10 Jan 2025 06:01:55 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 73e8d95d-cf5b-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736517716; x=1737122516; 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=Wg/OeKC7JOP+lwGkLt7//94jc+2XfyOiIRB1LLufRSc=;
        b=qOzPR2jrQzJH+BmeetHpWN+LsuhdeHU3Ukcy1QWRn0r9k3NOR+B98jhnzuKhqQD0so
         +mOBCONUzlzNGeY6CVRTJPCtRyoOJ5t+dlHniBMdaRYVJC+S400pyVEBgUDMYVRICcMW
         2+knIscJ6slnMFw4cPo4wptBcVIJTWusm/ZKE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736517716; x=1737122516;
        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=Wg/OeKC7JOP+lwGkLt7//94jc+2XfyOiIRB1LLufRSc=;
        b=rEEosbHuM+nkLQ1b7VTCyztuUx9rtVNbnaWNUBpxbZ0+785o0O6fl4hQRqUe6eNgKd
         GaJTrFg86Z5N8eD+tr3PBZmnXXW7cDTkLKXkfQXRVVUILKjt1Vy2KtvwiZtVLANKZjyu
         3xQwYSq9PmisnXWIY64JT/tw6LrKyDNJso9nr27hT3pMMdjtkpB+tQsEXywxpuqcTnlS
         9hslSrCmu0ptfNyDh+cdxcWw20FbUQIyugJXRBhV/QlKJeeAAo49XhA3jZookZb4VfTA
         0q0mo0a9wNjw51X537VLVVCe2PGjHwE+5Zb1ZPxFg4Q5N+ejircCtsOiadArt1W4mwM/
         go4g==
X-Forwarded-Encrypted: i=1; AJvYcCU1/mAOA9br+Ep75GgCsvJHuv458dtAOlNpbOjU2W9to4LyWuM+X2Yp+7+giwxRlww080GfqdhjJDA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwJuvOHGKGu8fCSSGPfGasmDjhq04u0Wm4684RRlECnhXSViD9G
	KEo8uRrJx2pda6IUjrZbdKNoe0OqYM5MNVpKxOZbT6MndFkyKU2SbGQXfHrs8AU=
X-Gm-Gg: ASbGncsbNtcHs5X+E3b8kxOyAq2/Sw9+ww0ITtSBaDoaC1X+VyvJ4xe5P/IFcx+ANvO
	+wBm7aLFo3IH0h/cu/03WQXECRABsimco31MdiXM4QyvcvgT/2DsPrgpIP4izPnyWGhWX5lKTLf
	02wji0y3vCgwDWqRD1qnw6KRhuGvA9CRfTpJ8f5BgVYRtR56ZD61ZE7+OIm6jyKF2xka7BqsWc2
	Aswo3AUv//Uw724X/Q/VHi9nAuyzo2Q9WKRNF3idzltSYenc1CQTlOBLMQSfjPNtRs=
X-Google-Smtp-Source: AGHT+IF6zKX/JETAEN1y5chRI/4N29iRAkR+x2KPiI4g6LnWuOntCCHsIZUKA7ISZFit2XhqqCxJnA==
X-Received: by 2002:a17:907:980f:b0:aa6:993a:259f with SMTP id a640c23a62f3a-ab2abcac230mr976852166b.40.1736517715855;
        Fri, 10 Jan 2025 06:01:55 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: linux-kernel@vger.kernel.org,
	xen-devel@lists.xenproject.org
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [PATCH 0/3] xen: fix usage of devices behind a VMD bridge
Date: Fri, 10 Jan 2025 15:01:47 +0100
Message-ID: <20250110140152.27624-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Hello,

The following series should fix the usage of devices behind a VMD bridge
when running Linux as a Xen PV hardware domain (dom0).  I've only been
able to test PV. I think PVH should also work but I don't have hardware
capable of testing it right now.

I don't expect the first two patches to be problematic, the last patch
is likely to be more controversial.  I've tested it internally and
didn't see any issues, but my testing of PV mode is mostly limited to
dom0.

Thanks, Roger.

Roger Pau Monne (3):
  xen/pci: do not register devices outside of PCI segment scope
  vmd: disable MSI remapping bypass under Xen
  pci/msi: remove pci_msi_ignore_mask

 arch/x86/pci/xen.c           |  8 ++------
 drivers/pci/controller/vmd.c |  9 +++++++++
 drivers/pci/msi/msi.c        | 36 ++++++++++++++++++++----------------
 drivers/xen/pci.c            | 19 +++++++++++++++++++
 include/linux/msi.h          |  3 ++-
 kernel/irq/msi.c             |  2 +-
 6 files changed, 53 insertions(+), 24 deletions(-)

-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Fri Jan 10 14:02:13 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 14:02:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869652.1281113 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWFaX-0000GW-Aw; Fri, 10 Jan 2025 14:02:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869652.1281113; Fri, 10 Jan 2025 14:02:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWFaX-0000GP-7e; Fri, 10 Jan 2025 14:02:13 +0000
Received: by outflank-mailman (input) for mailman id 869652;
 Fri, 10 Jan 2025 14:02:12 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=J0bo=UC=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tWFaW-00087j-H0
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 14:02:12 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7cf7048a-cf5b-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 15:02:11 +0100 (CET)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-5d3f28a4fccso2788498a12.2
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 06:02:12 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c9645408sm167312266b.166.2025.01.10.06.01.56
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 10 Jan 2025 06:01:56 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 7cf7048a-cf5b-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736517731; x=1737122531; 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=QOPaP/mU6vt7fi9w+3JVCzGSZ59QyAsOxxCexGJ2z2A=;
        b=lgqmdGsm7aX+MHobDZxNnSbI6MFy2MGYFbrvlAudAwgFTdmpJ2oIKGBAXSOqreqtx5
         ob4qyVDIgd7UieAmXi+j9IwJo/4FPSz+bvKgSvS8iz27DfUL9G+33Jt08eaYM5Wf7YZq
         HtJyNZ8HoqXL8m46GWa6CvagUAJZ3Qg70hM2o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736517731; x=1737122531;
        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=QOPaP/mU6vt7fi9w+3JVCzGSZ59QyAsOxxCexGJ2z2A=;
        b=TIkgHSTPhuigIbnHB+xwKExVXZYl1mhIiy38ka6pekRts89S9wn6zZMVoOmoXhdyy0
         t2JXPpAITR3GobdwbY39yDUTGRijdLcxRGy2lzItw39OHO0rgwOAH9NXetwxqmoJwBFl
         7EiGsxF3JIZO3pc8C5nZ4jBVlCRRliEmHQt6VMipmmKW6o8CAfqxatm8P0mc8G/P+HvS
         XYPtGKb8s6PPAlh6E4ZIcjohQUuncDtUrfk6IKkVp+EOl+/uK3YcrJV4qfF6uE4cHgsR
         nKlhW8DBekgDQ3h0Ss4/WJEJzrmITguHMX9AFy3/pT68UTkaJT5jCERZRChycMUIZ1K5
         OGkQ==
X-Forwarded-Encrypted: i=1; AJvYcCXw/ygP3Lh1poDP3r6gXDc4iDZE6iFtPfMELLBmq3rwQyasYGU5z1Frem3D7W8UHYnBZQhQz7bBGqI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxZvf+cnUxrH2vzMkHKimJxX13/Qh007T6wXTQFDXcPs8cy6XGC
	8JVB6D/aDUoHZx87KpYmpq9El21Hv+vYFHLMlXI+/2Py17P2X7+Osq+6b1SxJuCKuHZNByyOXuj
	E
X-Gm-Gg: ASbGncuk+EtZbOaoXkYebP8OTX1oV4vL637gJ9sZ1xAeMV2Ps5Q/E6i7U8tWSvm9b4H
	WWmMhD11gw77kSp5l2exUr95BjInSiYfMIMBqcelVA7K3zwysWy+pDKx+ZRkCvkVHsJUdhE9g6t
	OIiiIvnsrnLPqIA+jckxx18Ir3zSsu2DLYniugWZ+ZONKa1ryI3I4cF9k5lhI6S+SJuerHUjSvs
	vUoODb66OSam5U456/8Rc76X0kboXFRFmS7KLPKT/hr0+kAr5Gzm4a1Ar6H21StlXU=
X-Google-Smtp-Source: AGHT+IHwiF6pZdggWtSRTr6pLMwM8np6twiqSyLvaaV8RNsdWeIBSWUdDT3itr1SN8CI6AcxoSrZBQ==
X-Received: by 2002:a17:907:94c8:b0:aaf:7321:f05a with SMTP id a640c23a62f3a-ab2abc6e773mr980949866b.46.1736517717515;
        Fri, 10 Jan 2025 06:01:57 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: linux-kernel@vger.kernel.org,
	xen-devel@lists.xenproject.org
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Juergen Gross <jgross@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Subject: [PATCH 1/3] xen/pci: do not register devices outside of PCI segment scope
Date: Fri, 10 Jan 2025 15:01:48 +0100
Message-ID: <20250110140152.27624-2-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250110140152.27624-1-roger.pau@citrix.com>
References: <20250110140152.27624-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The PCI segment value is limited to 16 bits, however there are buses like VMD
that fake being part of the PCI topology by adding segment with a number
outside the scope of the PCI firmware specification range (>= 0x10000). The
MCFG ACPI Table "PCI Segment Group Number" field is defined as having a 16 bit
width.

Attempting to register or manage those devices with Xen would result in errors
at best, or overlaps with existing devices living on the truncated equivalent
segment values.

Skip notifying Xen about those devices.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 drivers/xen/pci.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/drivers/xen/pci.c b/drivers/xen/pci.c
index 416f231809cb..08e82fd1263e 100644
--- a/drivers/xen/pci.c
+++ b/drivers/xen/pci.c
@@ -43,6 +43,13 @@ static int xen_add_device(struct device *dev)
 		pci_mcfg_reserved = true;
 	}
 #endif
+
+	if (pci_domain_nr(pci_dev->bus) >> 16) {
+		dev_info(dev,
+			 "not registering with Xen: invalid PCI segment\n");
+		return 0;
+	}
+
 	if (pci_seg_supported) {
 		DEFINE_RAW_FLEX(struct physdev_pci_device_add, add, optarr, 1);
 
@@ -149,6 +156,12 @@ static int xen_remove_device(struct device *dev)
 	int r;
 	struct pci_dev *pci_dev = to_pci_dev(dev);
 
+	if (pci_domain_nr(pci_dev->bus) >> 16) {
+		dev_info(dev,
+			 "not unregistering with Xen: invalid PCI segment\n");
+		return 0;
+	}
+
 	if (pci_seg_supported) {
 		struct physdev_pci_device device = {
 			.seg = pci_domain_nr(pci_dev->bus),
@@ -182,6 +195,12 @@ int xen_reset_device(const struct pci_dev *dev)
 		.flags = PCI_DEVICE_RESET_FLR,
 	};
 
+	if (pci_domain_nr(dev->bus) >> 16) {
+		dev_info(&dev->dev,
+			 "unable to notify Xen of device reset: invalid PCI segment\n");
+		return 0;
+	}
+
 	return HYPERVISOR_physdev_op(PHYSDEVOP_pci_device_reset, &device);
 }
 EXPORT_SYMBOL_GPL(xen_reset_device);
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Fri Jan 10 14:02:36 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 14:02:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869665.1281123 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWFau-0000ww-Hq; Fri, 10 Jan 2025 14:02:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869665.1281123; Fri, 10 Jan 2025 14:02:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWFau-0000wV-ET; Fri, 10 Jan 2025 14:02:36 +0000
Received: by outflank-mailman (input) for mailman id 869665;
 Fri, 10 Jan 2025 14:02:35 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=J0bo=UC=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tWFat-0000qj-84
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 14:02:35 +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 8944a9ad-cf5b-11ef-99a4-01e77a169b0f;
 Fri, 10 Jan 2025 15:02:32 +0100 (CET)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-aaf3c3c104fso350026766b.1
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 06:02:32 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c95b09a6sm168510666b.145.2025.01.10.06.02.01
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 10 Jan 2025 06:02:01 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8944a9ad-cf5b-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736517752; x=1737122552; 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=bXUrrXc7otEMLuPDik4Ot8RLIKG6b+qL1a+y6J/W2hw=;
        b=ZE+h3xjGAwiJ3R84uq9/m644x6SgMeYV7lj0yToJEQxX7r9SyQhVaXR0RZgnsKvabT
         zby3pVpoeXQsddclVE1LK8zc56r9Ndb18Hut/pSbjMAP66fnAp3MtjmpnGXzxWuCD7ti
         nBS047weNMoY2AfdsnPFDcPrY6ctiP1MxNoqQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736517752; x=1737122552;
        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=bXUrrXc7otEMLuPDik4Ot8RLIKG6b+qL1a+y6J/W2hw=;
        b=s9joM2dHgDMZy5430WrymUdTcYU2bOJv89j8lbmFlQspZgUVEQDS89GzYNq7K1T6RP
         R8HKOrtsBdX0YOkAjCzvm5jq5CuGPdB1eMWZqrr+4X5fKYQK3B2WGmHL3WbKZRdxa2Er
         AAZlsyuJhhT3Q9SmMwaUf2mNpKbNy25YWUicAocN/84i+7CEiBCqTo5CVjXNKWRpTWLo
         EdcyOoHUDWjCtCP4g/d9hhpghlKvZlb33eiirR/n88Z26yzUyHdTILQo/m3fmhDNKzYZ
         wRmeH+LD7pv3iI/AZ6urpsU9su61JoKgR7JoayWqC/HxKkyPX3vtOhYo2f2sgFfKcLWd
         ZFFw==
X-Forwarded-Encrypted: i=1; AJvYcCVCo9Kmb5CUA1meC0gg7Da72G+YX819ZpJjtyz3sjCnwd+nI9iwCsa3oATUrKjieLViaN/mctfsx9s=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyVLfxRUr+m4IYV3AwxH5O6PvhWuMqjLWvz4OIqoDlN57PT0T6U
	MN0lcuYZL7CDd9rPOtQHbXINxcI2+AvhsrRKVQNURIRUt8HYLaHpQmP39rOKmt8=
X-Gm-Gg: ASbGnctWGH8U035zXDbgcZXis3IhvNJVBo5qVCO8LZpmOMtneUDp46r8F6hWuluQlTo
	237ZsJG5lsjdMOHShO/LxAoUOyZtl6LI52/Xf5rm3ZrUuPHp1fJYulXdiUHT5lV4PumsUVLhAkr
	+C4U53Cl0YRB4XATWWJgkkib5QA29x49uYR1/O+UGLRgACpaiIHbehtzrAY/TD5mLV+L2fg2LZL
	I1B6x8UAgFpKHiA1xc2tk/tLHpVZO5iE3kuqDWmfm8ONvJvsHbF+qegiq+IgOUQE3E=
X-Google-Smtp-Source: AGHT+IGy+s65n1QI7kpn2XGnPHW44cwj7nn4OvI00oi9CML5cFM7+b0vWH7nmPweruWMP0Y17IUp2g==
X-Received: by 2002:a17:906:7311:b0:a9a:bbcc:5092 with SMTP id a640c23a62f3a-ab2ab6bfb7amr910685366b.39.1736517721914;
        Fri, 10 Jan 2025 06:02:01 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: linux-kernel@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	linux-pci@vger.kernel.org
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Juergen Gross <jgross@suse.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: [PATCH 3/3] pci/msi: remove pci_msi_ignore_mask
Date: Fri, 10 Jan 2025 15:01:50 +0100
Message-ID: <20250110140152.27624-4-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250110140152.27624-1-roger.pau@citrix.com>
References: <20250110140152.27624-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Setting pci_msi_ignore_mask inhibits the toggling of the mask bit for both MSI
and MSI-X entries globally, regardless of the IRQ chip they are using.  Only
Xen sets the pci_msi_ignore_mask when routing physical interrupts over event
channels, to prevent PCI code from attempting to toggle the maskbit, as it's
Xen that controls the bit.

However, the pci_msi_ignore_mask being global will affect devices that use MSI
interrupts but are not routing those interrupts over event channels (not using
the Xen pIRQ chip).  One example is devices behind a VMD PCI bridge.  In that
scenario the VMD bridge configures MSI(-X) using the normal IRQ chip (the pIRQ
one in the Xen case), and devices behind the bridge configure the MSI entries
using indexes into the VMD bridge MSI table.  The VMD bridge then demultiplexes
such interrupts and delivers to the destination device(s).  Having
pci_msi_ignore_mask set in that scenario prevents (un)masking of MSI entries
for devices behind the VMD bridge.

Move the signaling of no entry masking into the MSI domain flags, as that
allows setting it on a per-domain basis.  Set it for the Xen MSI domain that
uses the pIRQ chip, while leaving it unset for the rest of the cases.

Remove pci_msi_ignore_mask at once, since it was only used by Xen code, and
with Xen dropping usage the variable is unneeded.

This fixes using devices behind a VMD bridge on Xen PV hardware domains.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 arch/x86/pci/xen.c    |  8 ++------
 drivers/pci/msi/msi.c | 36 ++++++++++++++++++++----------------
 include/linux/msi.h   |  3 ++-
 kernel/irq/msi.c      |  2 +-
 4 files changed, 25 insertions(+), 24 deletions(-)

diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 0f2fe524f60d..b8755cde2419 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -436,7 +436,8 @@ static struct msi_domain_ops xen_pci_msi_domain_ops = {
 };
 
 static struct msi_domain_info xen_pci_msi_domain_info = {
-	.flags			= MSI_FLAG_PCI_MSIX | MSI_FLAG_FREE_MSI_DESCS | MSI_FLAG_DEV_SYSFS,
+	.flags			= MSI_FLAG_PCI_MSIX | MSI_FLAG_FREE_MSI_DESCS |
+				  MSI_FLAG_DEV_SYSFS | MSI_FLAG_NO_MASK,
 	.ops			= &xen_pci_msi_domain_ops,
 };
 
@@ -484,11 +485,6 @@ static __init void xen_setup_pci_msi(void)
 	 * in allocating the native domain and never use it.
 	 */
 	x86_init.irqs.create_pci_msi_domain = xen_create_pci_msi_domain;
-	/*
-	 * With XEN PIRQ/Eventchannels in use PCI/MSI[-X] masking is solely
-	 * controlled by the hypervisor.
-	 */
-	pci_msi_ignore_mask = 1;
 }
 
 #else /* CONFIG_PCI_MSI */
diff --git a/drivers/pci/msi/msi.c b/drivers/pci/msi/msi.c
index 3a45879d85db..cb42298f6a97 100644
--- a/drivers/pci/msi/msi.c
+++ b/drivers/pci/msi/msi.c
@@ -15,7 +15,6 @@
 #include "msi.h"
 
 int pci_msi_enable = 1;
-int pci_msi_ignore_mask;
 
 /**
  * pci_msi_supported - check whether MSI may be enabled on a device
@@ -285,6 +284,8 @@ static void pci_msi_set_enable(struct pci_dev *dev, int enable)
 static int msi_setup_msi_desc(struct pci_dev *dev, int nvec,
 			      struct irq_affinity_desc *masks)
 {
+	const struct irq_domain *d = dev_get_msi_domain(&dev->dev);
+	const struct msi_domain_info *info = d->host_data;
 	struct msi_desc desc;
 	u16 control;
 
@@ -295,8 +296,7 @@ static int msi_setup_msi_desc(struct pci_dev *dev, int nvec,
 	/* Lies, damned lies, and MSIs */
 	if (dev->dev_flags & PCI_DEV_FLAGS_HAS_MSI_MASKING)
 		control |= PCI_MSI_FLAGS_MASKBIT;
-	/* Respect XEN's mask disabling */
-	if (pci_msi_ignore_mask)
+	if (info->flags & MSI_FLAG_NO_MASK)
 		control &= ~PCI_MSI_FLAGS_MASKBIT;
 
 	desc.nvec_used			= nvec;
@@ -600,12 +600,15 @@ static void __iomem *msix_map_region(struct pci_dev *dev,
  */
 void msix_prepare_msi_desc(struct pci_dev *dev, struct msi_desc *desc)
 {
+	const struct irq_domain *d = dev_get_msi_domain(&dev->dev);
+	const struct msi_domain_info *info = d->host_data;
+
 	desc->nvec_used				= 1;
 	desc->pci.msi_attrib.is_msix		= 1;
 	desc->pci.msi_attrib.is_64		= 1;
 	desc->pci.msi_attrib.default_irq	= dev->irq;
 	desc->pci.mask_base			= dev->msix_base;
-	desc->pci.msi_attrib.can_mask		= !pci_msi_ignore_mask &&
+	desc->pci.msi_attrib.can_mask		= !(info->flags & MSI_FLAG_NO_MASK) &&
 						  !desc->pci.msi_attrib.is_virtual;
 
 	if (desc->pci.msi_attrib.can_mask) {
@@ -655,9 +658,6 @@ static void msix_mask_all(void __iomem *base, int tsize)
 	u32 ctrl = PCI_MSIX_ENTRY_CTRL_MASKBIT;
 	int i;
 
-	if (pci_msi_ignore_mask)
-		return;
-
 	for (i = 0; i < tsize; i++, base += PCI_MSIX_ENTRY_SIZE)
 		writel(ctrl, base + PCI_MSIX_ENTRY_VECTOR_CTRL);
 }
@@ -710,6 +710,8 @@ static int msix_setup_interrupts(struct pci_dev *dev, struct msix_entry *entries
 static int msix_capability_init(struct pci_dev *dev, struct msix_entry *entries,
 				int nvec, struct irq_affinity *affd)
 {
+	const struct irq_domain *d = dev_get_msi_domain(&dev->dev);
+	const struct msi_domain_info *info = d->host_data;
 	int ret, tsize;
 	u16 control;
 
@@ -740,15 +742,17 @@ static int msix_capability_init(struct pci_dev *dev, struct msix_entry *entries,
 	/* Disable INTX */
 	pci_intx_for_msi(dev, 0);
 
-	/*
-	 * Ensure that all table entries are masked to prevent
-	 * stale entries from firing in a crash kernel.
-	 *
-	 * Done late to deal with a broken Marvell NVME device
-	 * which takes the MSI-X mask bits into account even
-	 * when MSI-X is disabled, which prevents MSI delivery.
-	 */
-	msix_mask_all(dev->msix_base, tsize);
+	if (!(info->flags & MSI_FLAG_NO_MASK)) {
+		/*
+		 * Ensure that all table entries are masked to prevent
+		 * stale entries from firing in a crash kernel.
+		 *
+		 * Done late to deal with a broken Marvell NVME device
+		 * which takes the MSI-X mask bits into account even
+		 * when MSI-X is disabled, which prevents MSI delivery.
+		 */
+		msix_mask_all(dev->msix_base, tsize);
+	}
 	pci_msix_clear_and_set_ctrl(dev, PCI_MSIX_FLAGS_MASKALL, 0);
 
 	pcibios_free_irq(dev);
diff --git a/include/linux/msi.h b/include/linux/msi.h
index b10093c4d00e..59a421fc42bf 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -73,7 +73,6 @@ struct msi_msg {
 	};
 };
 
-extern int pci_msi_ignore_mask;
 /* Helper functions */
 struct msi_desc;
 struct pci_dev;
@@ -556,6 +555,8 @@ enum {
 	MSI_FLAG_PCI_MSIX_ALLOC_DYN	= (1 << 20),
 	/* PCI MSIs cannot be steered separately to CPU cores */
 	MSI_FLAG_NO_AFFINITY		= (1 << 21),
+	/* Inhibit usage of entry masking */
+	MSI_FLAG_NO_MASK		= (1 << 22),
 };
 
 /**
diff --git a/kernel/irq/msi.c b/kernel/irq/msi.c
index 396a067a8a56..7682c36cbccc 100644
--- a/kernel/irq/msi.c
+++ b/kernel/irq/msi.c
@@ -1143,7 +1143,7 @@ static bool msi_check_reservation_mode(struct irq_domain *domain,
 	if (!(info->flags & MSI_FLAG_MUST_REACTIVATE))
 		return false;
 
-	if (IS_ENABLED(CONFIG_PCI_MSI) && pci_msi_ignore_mask)
+	if (info->flags & MSI_FLAG_NO_MASK)
 		return false;
 
 	/*
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Fri Jan 10 14:04:04 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 14:04:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869679.1281132 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWFcJ-0001yD-Qq; Fri, 10 Jan 2025 14:04:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869679.1281132; Fri, 10 Jan 2025 14:04:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWFcJ-0001y6-OL; Fri, 10 Jan 2025 14:04:03 +0000
Received: by outflank-mailman (input) for mailman id 869679;
 Fri, 10 Jan 2025 14:04:02 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=qOMD=UC=apertussolutions.com=dpsmith@srs-se1.protection.inumbo.net>)
 id 1tWFcI-0001xu-Nm
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 14:04:02 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bcb38378-cf5b-11ef-99a4-01e77a169b0f;
 Fri, 10 Jan 2025 15:04:00 +0100 (CET)
Received: from mail.zoho.com by mx.zohomail.com
 with SMTP id 1736517829573868.3192042071445;
 Fri, 10 Jan 2025 06:03:49 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: bcb38378-cf5b-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; t=1736517836; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=TJgHbNDERtnMhBUvbXxKLEgQz+940+G8ZWZ6U8E0htBFw+a9WGogdAa+haMZLtixhb7Zz3o9zNg5LaIUN6yNQ56fxlfBTvB8aY98mY5ndBqDpav/OX/VXJhbRhozL3lnwXOEV9iEOV01IemY1dVHeiEvH0vZvn8K3VAYYMN+uHE=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1736517836; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=igYZXyfAvgPFB34XbCdj4dNoIGaNITLAl7eWqXkKCwE=; 
	b=TTd0rTfkO2jtH5tYSPEYPnuRmWX5Wb3rm0Xef1/cJHDrQXSY0MMf+3xn7M3oYwn9x6uRxVjBznEz0uswwYCw1NvVcuN0saoheLxKGvRXXVsxUlavxfci/EaV+w5fxtcfSYOzalc2EU6Kngz6nWHLzqL0N7wlWwZMPYZICaufN2E=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1736517836;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Date:Date:From:From:To:To:Cc:Cc:Message-ID:In-Reply-To:References:Subject:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=igYZXyfAvgPFB34XbCdj4dNoIGaNITLAl7eWqXkKCwE=;
	b=L+Vq/XbmuufSAv5A1fmD1U1aP4MwMgedufuM4tc8a7B2fONWU4qj7xhn2iS+2cH2
	5xLsZpZI/9kxWAVNY71u6rd4GwOBNeqCnU/mnIEHmbTza1K0yizuhYg/KXIugKm+elY
	LAjfbkUH5yCl+s0AGU/GavEMU18g0QR5jvFejs14=
Date: Fri, 10 Jan 2025 09:03:49 -0500
From: Daniel Smith <dpsmith@apertussolutions.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Cc: "openxt" <openxt@googlegroups.com>,
	"Christopher Clark" <christopher.w.clark@gmail.com>,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>
Message-ID: <194508743ac.be65a5e2248998.5521251650313228304@apertussolutions.com>
In-Reply-To: <20250110133711.3958202-1-dpsmith@apertussolutions.com>
References: <20250110133711.3958202-1-dpsmith@apertussolutions.com>
Subject: Re: [PATCH 0/2] Enable the ability to disable/remove gnttabv2
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Importance: Medium
User-Agent: Zoho Mail
X-Mailer: Zoho Mail

---- On Fri, 10 Jan 2025 08:37:09 -0500 Daniel P. Smith  wrote ---

 > OpenXT has carried a patch for some time that allows the disabling and removal 
 > of the grant table v2 capability. This is a rework of that patch in an attempt 
 > to make an upstreamable series. 
 >  
 > The original patch was developed under funding provided by BAE, therefore a 
 > separate Authored-by tag to reflect that is included. 

Apologies as I should have added a "--suppress-cc=misc=by". If you want to avoid bounce messages, I would recommed dropping the BAE address on response.

v/r,
dps




From xen-devel-bounces@lists.xenproject.org Fri Jan 10 14:15:28 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 14:15:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869693.1281142 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWFnH-0005O0-TB; Fri, 10 Jan 2025 14:15:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869693.1281142; Fri, 10 Jan 2025 14:15:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWFnH-0005Nt-Qi; Fri, 10 Jan 2025 14:15:23 +0000
Received: by outflank-mailman (input) for mailman id 869693;
 Fri, 10 Jan 2025 14:15: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
 <SRS0=J0bo=UC=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tWFnG-0005Nn-K2
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 14:15:22 +0000
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [2a00:1450:4864:20::62c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 532d303b-cf5d-11ef-99a4-01e77a169b0f;
 Fri, 10 Jan 2025 15:15:20 +0100 (CET)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-aaeec07b705so340461866b.2
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 06:15:20 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c90e3f54sm169885766b.81.2025.01.10.06.15.19
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 10 Jan 2025 06:15:19 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 532d303b-cf5d-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736518520; x=1737123320; 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=fC5Oc6Gac22Agkm0SWitel5gVMu0x+T+FUciEGk4Umo=;
        b=uPHcmo0hcLiGMqxwGou41nkj6+IHddTy1ABwbgnt8UmaqVNJTaXW4DoAwbNa2C33Uu
         Jdm1hltkz5YgE83OuJ2LNpyhKXGQqe+FO+tJiNkzGQjsAH61SSfO3gs+ETSUNi094TAn
         YSGQtbN4WZvUiGyXF9uB8Bb2dKH1yolJ8/4xI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736518520; x=1737123320;
        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=fC5Oc6Gac22Agkm0SWitel5gVMu0x+T+FUciEGk4Umo=;
        b=GAPAtpX812Q8WE5taOzMrCPd9mwdKj2wdBco4bWM90BjD12NPghpJrkw9sbk7RPaXs
         IjGeecckMTJV5tCx0Lc3cbtfek+Qem7AJoeEi8Hv96i9WhXxr3jlOoGKI3eusLQkN6eG
         9+usvCA7LHUTsSyYBl9CEvOvjlfynoONk+TNuyfQYHM+IEiLkFk/qJ/RkzoHhANcnfj0
         WZWvZUfUEyfUeX/VXNjZ2D18CJyOjDqVITaanft955LzIK8U3Bn56yLYYHnXbScruYfv
         mmXahC8urj1BaTnGatQCPTsEc2dcO23AvFO7zqv3rHatxK4MAX+ZfdzJW7LEdA/sZB/p
         35mg==
X-Forwarded-Encrypted: i=1; AJvYcCUxga2le4JjMGRZqekBXJp4uKj+wz5EORpskltmZfB2f6mOBgfVLs/6XloTIJizy9Lk2hKrcqfUEu4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxasU/NVy+5b00F/5d83odKPG/at+qoLu7TX/5b/Z3NDCfdA0kz
	x3GUQULeZPIaOw4I9sFIeNM2nE6SQYrqF5cIiDhtAgtSuJH61vmAJpdi5LGvj6EqZldfM1Erm9Z
	H
X-Gm-Gg: ASbGncsAyFiSWOsfnW9/cBLfn19wpyYzjXK2aw3YYXKKGoHf+pf4eEv9B5V6vXHdBxv
	9EUnZjmaGOPgd2BCVwrNrLzyx/eBf2pLQ+DtJmvqrqksvWDZ3qP6y/tJyZFkRfOw2Zhq/gWhp2f
	3h9R4HrgkWEatYglRWmDU7C9EXsj61/3fwnqep1OL+g2k+OOvDksjJ0yJ+PdLbVwqyJWILOIOLl
	mQmYE5zT7TogK+tqbN9CpJsDCEoqJTBEWyKT4ciqYUtc+ARKnqAEPZJbbITXV/wCic=
X-Google-Smtp-Source: AGHT+IFuf+JCFti89VlW1nKFznhG3hsua6f/izKUid67fvzcXflAECfSIqn8EdL3NDABpTJvdQAjjQ==
X-Received: by 2002:a17:907:d87:b0:aa6:7ec4:8bac with SMTP id a640c23a62f3a-ab2ab709c68mr1118536466b.17.1736518520009;
        Fri, 10 Jan 2025 06:15:20 -0800 (PST)
Date: Fri, 10 Jan 2025 15:15:18 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 04/18] x86/pv: introduce function to populate
 perdomain area and use it to map Xen GDT
Message-ID: <Z4ErduC-Nmzttbkf@macbook.local>
References: <20250108142659.99490-1-roger.pau@citrix.com>
 <20250108142659.99490-5-roger.pau@citrix.com>
 <031ce31b-0ab5-4964-96eb-642fbea67bfb@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <031ce31b-0ab5-4964-96eb-642fbea67bfb@suse.com>

On Thu, Jan 09, 2025 at 10:10:20AM +0100, Jan Beulich wrote:
> On 08.01.2025 15:26, Roger Pau Monne wrote:
> > The current code to update the Xen part of the GDT when running a PV guest
> > relies on caching the direct map address of all the L1 tables used to map the
> > GDT and LDT, so that entries can be modified.
> > 
> > Introduce a new function that populates the per-domain region, either using the
> > recursive linear mappings when the target vCPU is the current one, or by
> > directly modifying the L1 table of the per-domain region.
> > 
> > Using such function to populate per-domain addresses drops the need to keep a
> > reference to per-domain L1 tables previously used to change the per-domain
> > mappings.
> 
> Well, yes. You now record MFNs instead. And you do so at the expense of about
> 100 lines of new code. I'm afraid I'm lacking justification for this price to
> be paid.

Oh, I should have been more explicit on the commit message probably.
The cover letter kind of covers this, the objective is to remove the
stashing of L1 page-table references in the domain struct.  Currently
the per-vCPU GDT L1 are stored in the domain struct, so PTEs can be
easily manipulated.

When moving the per-domain slot to being per-vCPU this stashing of the
L1 tables will become much more complex, and hence I wanted to get rid
of it.

With the introduction of populate_perdomain_mapping() I'm attempting
to get rid of all those L1 references in the domain struct, by having
a generic function that allows modifying the linea address range that
belongs to the per-domain slot.

See for example how patch 8 gets rid of all the l1_pgentry_t GDT/LDT
references in the domain struct.  And how patch 9 simplifies the
create_perdomain_mapping() interface to be much simpler.  All this is
built upon the addition of the populate_perdomain_mapping() helper and
the dropping of the l1_pgentry_t references in the domain struct.

Hope this helps clarify the intent of the change here.

> > @@ -2219,11 +2219,9 @@ void __init trap_init(void)
> >      init_ler();
> >  
> >      /* Cache {,compat_}gdt_l1e now that physically relocation is done. */
> > -    this_cpu(gdt_l1e) =
> > -        l1e_from_pfn(virt_to_mfn(boot_gdt), __PAGE_HYPERVISOR_RW);
> > +    this_cpu(gdt_mfn) = _mfn(virt_to_mfn(boot_gdt));
> >      if ( IS_ENABLED(CONFIG_PV32) )
> > -        this_cpu(compat_gdt_l1e) =
> > -            l1e_from_pfn(virt_to_mfn(boot_compat_gdt), __PAGE_HYPERVISOR_RW);
> > +        this_cpu(compat_gdt_mfn) = _mfn(virt_to_mfn(boot_compat_gdt));
> 
> The comment's going stale this way.

Right, the cache is still there but using a different field name.  I
can adjust to:

/* Cache {,compat_}gdt_mfn now that physically relocation is done. */

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 14:17:04 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 14:17:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869701.1281152 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWFot-0005u1-7m; Fri, 10 Jan 2025 14:17:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869701.1281152; Fri, 10 Jan 2025 14:17:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWFot-0005tu-58; Fri, 10 Jan 2025 14:17:03 +0000
Received: by outflank-mailman (input) for mailman id 869701;
 Fri, 10 Jan 2025 14:17: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
 <SRS0=fpP+=UC=kernel.org=joel.granados@srs-se1.protection.inumbo.net>)
 id 1tWFor-0005tm-DZ
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 14:17:01 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org
 [2604:1380:45d1:ec00::3])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8d01d9ee-cf5d-11ef-99a4-01e77a169b0f;
 Fri, 10 Jan 2025 15:16:58 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 21317A42086;
 Fri, 10 Jan 2025 14:15:08 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPS id 31FF0C4CED6;
 Fri, 10 Jan 2025 14:16:56 +0000 (UTC)
Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org
 (localhost.localdomain [127.0.0.1])
 by smtp.lore.kernel.org (Postfix) with ESMTP id 2265AE77188;
 Fri, 10 Jan 2025 14:16:56 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8d01d9ee-cf5d-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1736518616;
	bh=xdxiDwpW8t7FJHp+UGef54ilQO1KSY0X4AoeICKx/38=;
	h=From:Date:Subject:To:Cc:From;
	b=pZjD9D3F30Z4UM2wXmAWGdMq/5twEinkYKaTKqPPdSLkH/QkeaVmd5jtVKiYD9F65
	 K3qlCSw7NXKcKvtzf0TOhETuN/YzW2SeLOPweFVyaMz+MUqCyeBRl4vJfaPAMHcpSC
	 gZBPA68fgoEbWmwStFms2FZyjuUfohV4cMJyFyO1RVbYBUMn88jKGiblsawWGBpgxw
	 DWUg7+sZoowhQM45BZ8Xgn3CIFEWOVFeAPj7ot11BN1QsvhP1I6RyeWCfi31QM5UOe
	 S7dz5s7elymdU5IgBsfhk/fSUFvifwiv2f+nc6POJMlK09KgBMK2KwKLv02B96Meqg
	 w88PmVhDmcA0w==
From: Joel Granados <joel.granados@kernel.org>
Date: Fri, 10 Jan 2025 15:16:08 +0100
Subject: [PATCH v2] treewide: const qualify ctl_tables where applicable
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20250110-jag-ctl_table_const-v2-1-0000e1663144@kernel.org>
X-B4-Tracking: v=1; b=H4sIAKgrgWcC/32NQQ7CIBBFr9LMWgxMY6uueg/TNIBDizZggBBNw
 93FHsDle8l/f4NIwVKEa7NBoGyj9a4CHhrQi3QzMXuvDMjxxAW/sIecmU7rlKRaadLexcTas+k
 Uaq2U7KEuX4GMfe/V21h5sTH58NlPsvjZ/70smGAdoiTZY8u1GZ4UHK1HH2YYSylf5wwWYrcAA
 AA=
To: =?utf-8?q?Thomas_Wei=C3=9Fschuh?= <linux@weissschuh.net>, 
 Kees Cook <kees@kernel.org>, Luis Chamberlain <mcgrof@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, 
 linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, 
 linux-s390@vger.kernel.org, linux-crypto@vger.kernel.org, 
 openipmi-developer@lists.sourceforge.net, intel-gfx@lists.freedesktop.org, 
 dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org, 
 linux-hyperv@vger.kernel.org, linux-rdma@vger.kernel.org, 
 linux-raid@vger.kernel.org, linux-scsi@vger.kernel.org, 
 linux-serial@vger.kernel.org, xen-devel@lists.xenproject.org, 
 linux-aio@kvack.org, linux-fsdevel@vger.kernel.org, netfs@lists.linux.dev, 
 codalist@coda.cs.cmu.edu, linux-mm@kvack.org, linux-nfs@vger.kernel.org, 
 ocfs2-devel@lists.linux.dev, fsverity@lists.linux.dev, 
 linux-xfs@vger.kernel.org, io-uring@vger.kernel.org, bpf@vger.kernel.org, 
 kexec@lists.infradead.org, linux-trace-kernel@vger.kernel.org, 
 linux-hardening@vger.kernel.org, apparmor@lists.ubuntu.com, 
 linux-security-module@vger.kernel.org, keyrings@vger.kernel.org, 
 Song Liu <song@kernel.org>, "Steven Rostedt (Google)" <rostedt@goodmis.org>, 
 "Martin K. Petersen" <martin.petersen@oracle.com>, 
 "Darrick J. Wong" <djwong@kernel.org>, Jani Nikula <jani.nikula@intel.com>, 
 Corey Minyard <cminyard@mvista.com>, 
 Joel Granados <joel.granados@kernel.org>
X-Mailer: b4 0.15-dev-00a43
X-Developer-Signature: v=1; a=openpgp-sha256; l=62601;
 i=joel.granados@kernel.org; h=from:subject:message-id;
 bh=xdxiDwpW8t7FJHp+UGef54ilQO1KSY0X4AoeICKx/38=;
 b=owJ4nAHtARL+kA0DAAoBupfNUreWQU8ByyZiAGeBK9ZDAWlcPRl9CFn5pB+ysCRMigrHUZJES
 rTiMh6Z1m31O4kBswQAAQoAHRYhBK5HCVcl5jElzssnkLqXzVK3lkFPBQJngSvWAAoJELqXzVK3
 lkFP/ycL/RJcrcFYliaFVz8aq0WhtnTrhtAW2+Pms1ToLuh6ybnGsuqkbguXoNP5J61guiHc2h/
 niwuz2i1loYxrS3gvghi15QhvBc8Ai22x1Fi9RpvcyqeRZLFk6IuG7qdhD/0lwXagIxz8UK61/H
 zK4tsJpxzFfvEmfkQKXSf4hZVukagM+aGQaA6PN6KMClpzuWXREY6W/AtxAi3opA2/DD7t/7Hj1
 O5FhXLzzF6jA2BGh5v9bZNMyuChJXocWcxrA5xdtUL+oxadso/E9STV0kryn9STJlcot+jBdAvP
 cYgwrLXTRpSIDydSCZ8ryjCNrDNGtwkjgFg26EGrtETV9G410pauDOuIB55jkuVevOOWm7kl1M+
 YkIaGZUuWNRQtEHR4b1ol2k3VkQO3o/Cvc6oKzQMwSzOZ41kRVEfl5s0VrGBJDcBoVWJh7D2MDP
 3d5hViWFyVpQTVfIuTRD+sD7HRg3HXVieou6oTfJrw/Oh73EpwL9FnlAzcsD7EOROG5e2CsDYk7
 eY=
X-Developer-Key: i=joel.granados@kernel.org; a=openpgp;
 fpr=F1F8E46D30F0F6C4A45FF4465895FAAC338C6E77
X-Endpoint-Received: by B4 Relay for joel.granados@kernel.org/default with
 auth_id=239

Add the const qualifier to all the ctl_tables in the tree except for
watchdog_hardlockup_sysctl, memory_allocation_profiling_sysctls,
loadpin_sysctl_table and the ones calling register_net_sysctl (./net,
drivers/inifiniband dirs). These are special cases as they use a
registration function with a non-const qualified ctl_table argument or
modify the arrays before passing them on to the registration function.

Constifying ctl_table structs will prevent the modification of
proc_handler function pointers as the arrays would reside in .rodata.
This is made possible after commit 78eb4ea25cd5 ("sysctl: treewide:
constify the ctl_table argument of proc_handlers") constified all the
proc_handlers.

Created this by running an spatch followed by a sed command:
Spatch:
    virtual patch

    @
    depends on !(file in "net")
    disable optional_qualifier
    @
    identifier table_name != {watchdog_hardlockup_sysctl,iwcm_ctl_table,ucma_ctl_table,memory_allocation_profiling_sysctls,loadpin_sysctl_table};
    @@

    + const
    struct ctl_table table_name [] = { ... };

sed:
    sed --in-place \
      -e "s/struct ctl_table .table = &uts_kern/const struct ctl_table *table = \&uts_kern/" \
      kernel/utsname_sysctl.c

Reviewed-by: Song Liu <song@kernel.org>
Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org> # for kernel/trace/
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> # SCSI
Reviewed-by: Darrick J. Wong <djwong@kernel.org> # xfs
Acked-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Corey Minyard <cminyard@mvista.com>
Signed-off-by: Joel Granados <joel.granados@kernel.org>
---
This treewide commit builds upon the work Thomas began a few releases
ago [1], where he laid the groundwork for constifying ctl_tables. We
implement constification throughout the tree, with the exception of the
ctl_tables in the "net" directory. Those are special in that they treat
the ctl_table as non-const but we can take them at a later point.

Upstreaming:
===========
It is late in the release cycle, but I'm hopeful that we can get this
in for the upcoming merge window and this is why:
1. We don't use linux-next: As with previous treewide changes similar to
   this one [1], we avoid using linux-next in order to avoid unwanted
   merge conflicts
2. This is a non-functional change: which lowers the probability of
   unforeseen errors or regressions.
3. It will have at least 2 weeks to be tested/reviewed: The PULL should
   be sent at the end of the merge window, giving it at least 2 weeks.
   And if there are more release candidates after rc6, there will be
   more time.

Testing:
========
1. Currently being tested in 0-day
2. sysctl self-tests/kunit-tests

Reduced To/Cc:
==============
b4 originally gave me 200 ppl that this should go out to (which seems a
bit overkill from my point of view). So I left the mailing lists and
reduced the To: the ppl previously involved in the effort and sysctl
maintainers. Please tell me if I missed someone important to the
constification effort.

Comments are greatly appreciated.

Changes in v2:
- watchdog_hardlockup_sysctl, memory_allocation_profiling_sysctls,
  loadpin_sysctl_table, iwcm_ctl_table and ucma_ctl_table where removed
  from patchset as they change the sysctl array before registration.
- Added reviewed-by tags
- Link to v1: https://lore.kernel.org/r/20250109-jag-ctl_table_const-v1-1-622aea7230cf@kernel.org
Best

[1] https://lore.kernel.org/20240724210014.mc6nima6cekgiukx@joelS2.panther.com

--
---

---
 arch/arm/kernel/isa.c                         | 2 +-
 arch/arm64/kernel/fpsimd.c                    | 4 ++--
 arch/arm64/kernel/process.c                   | 2 +-
 arch/powerpc/kernel/idle.c                    | 2 +-
 arch/powerpc/platforms/pseries/mobility.c     | 2 +-
 arch/riscv/kernel/process.c                   | 2 +-
 arch/riscv/kernel/vector.c                    | 2 +-
 arch/s390/appldata/appldata_base.c            | 2 +-
 arch/s390/kernel/debug.c                      | 2 +-
 arch/s390/kernel/hiperdispatch.c              | 2 +-
 arch/s390/kernel/topology.c                   | 2 +-
 arch/s390/mm/cmm.c                            | 2 +-
 arch/s390/mm/pgalloc.c                        | 2 +-
 arch/x86/entry/vdso/vdso32-setup.c            | 2 +-
 arch/x86/kernel/cpu/bus_lock.c                | 2 +-
 arch/x86/kernel/itmt.c                        | 2 +-
 crypto/fips.c                                 | 2 +-
 drivers/base/firmware_loader/fallback_table.c | 2 +-
 drivers/cdrom/cdrom.c                         | 2 +-
 drivers/char/hpet.c                           | 2 +-
 drivers/char/ipmi/ipmi_poweroff.c             | 2 +-
 drivers/char/random.c                         | 2 +-
 drivers/gpu/drm/i915/i915_perf.c              | 2 +-
 drivers/gpu/drm/xe/xe_observation.c           | 2 +-
 drivers/hv/hv_common.c                        | 2 +-
 drivers/macintosh/mac_hid.c                   | 2 +-
 drivers/md/md.c                               | 2 +-
 drivers/misc/sgi-xp/xpc_main.c                | 4 ++--
 drivers/perf/arm_pmuv3.c                      | 2 +-
 drivers/perf/riscv_pmu_sbi.c                  | 2 +-
 drivers/scsi/scsi_sysctl.c                    | 2 +-
 drivers/scsi/sg.c                             | 2 +-
 drivers/tty/tty_io.c                          | 2 +-
 drivers/xen/balloon.c                         | 2 +-
 fs/aio.c                                      | 2 +-
 fs/cachefiles/error_inject.c                  | 2 +-
 fs/coda/sysctl.c                              | 2 +-
 fs/coredump.c                                 | 2 +-
 fs/dcache.c                                   | 2 +-
 fs/devpts/inode.c                             | 2 +-
 fs/eventpoll.c                                | 2 +-
 fs/exec.c                                     | 2 +-
 fs/file_table.c                               | 2 +-
 fs/fuse/sysctl.c                              | 2 +-
 fs/inode.c                                    | 2 +-
 fs/lockd/svc.c                                | 2 +-
 fs/locks.c                                    | 2 +-
 fs/namei.c                                    | 2 +-
 fs/namespace.c                                | 2 +-
 fs/nfs/nfs4sysctl.c                           | 2 +-
 fs/nfs/sysctl.c                               | 2 +-
 fs/notify/dnotify/dnotify.c                   | 2 +-
 fs/notify/fanotify/fanotify_user.c            | 2 +-
 fs/notify/inotify/inotify_user.c              | 2 +-
 fs/ocfs2/stackglue.c                          | 2 +-
 fs/pipe.c                                     | 2 +-
 fs/quota/dquot.c                              | 2 +-
 fs/sysctls.c                                  | 2 +-
 fs/userfaultfd.c                              | 2 +-
 fs/verity/init.c                              | 2 +-
 fs/xfs/xfs_sysctl.c                           | 2 +-
 init/do_mounts_initrd.c                       | 2 +-
 io_uring/io_uring.c                           | 2 +-
 ipc/ipc_sysctl.c                              | 2 +-
 ipc/mq_sysctl.c                               | 2 +-
 kernel/acct.c                                 | 2 +-
 kernel/bpf/syscall.c                          | 2 +-
 kernel/delayacct.c                            | 2 +-
 kernel/exit.c                                 | 2 +-
 kernel/hung_task.c                            | 2 +-
 kernel/kexec_core.c                           | 2 +-
 kernel/kprobes.c                              | 2 +-
 kernel/latencytop.c                           | 2 +-
 kernel/locking/lockdep.c                      | 2 +-
 kernel/panic.c                                | 2 +-
 kernel/pid_namespace.c                        | 2 +-
 kernel/pid_sysctl.h                           | 2 +-
 kernel/printk/sysctl.c                        | 2 +-
 kernel/reboot.c                               | 2 +-
 kernel/sched/autogroup.c                      | 2 +-
 kernel/sched/core.c                           | 2 +-
 kernel/sched/deadline.c                       | 2 +-
 kernel/sched/fair.c                           | 2 +-
 kernel/sched/rt.c                             | 2 +-
 kernel/sched/topology.c                       | 2 +-
 kernel/seccomp.c                              | 2 +-
 kernel/signal.c                               | 2 +-
 kernel/stackleak.c                            | 2 +-
 kernel/sysctl-test.c                          | 6 +++---
 kernel/sysctl.c                               | 4 ++--
 kernel/time/timer.c                           | 2 +-
 kernel/trace/ftrace.c                         | 2 +-
 kernel/trace/trace_events_user.c              | 2 +-
 kernel/umh.c                                  | 2 +-
 kernel/utsname_sysctl.c                       | 4 ++--
 kernel/watchdog.c                             | 2 +-
 lib/test_sysctl.c                             | 6 +++---
 mm/compaction.c                               | 2 +-
 mm/hugetlb.c                                  | 2 +-
 mm/hugetlb_vmemmap.c                          | 2 +-
 mm/memory-failure.c                           | 2 +-
 mm/oom_kill.c                                 | 2 +-
 mm/page-writeback.c                           | 2 +-
 mm/page_alloc.c                               | 2 +-
 security/apparmor/lsm.c                       | 2 +-
 security/keys/sysctl.c                        | 2 +-
 security/yama/yama_lsm.c                      | 2 +-
 107 files changed, 115 insertions(+), 115 deletions(-)

diff --git a/arch/arm/kernel/isa.c b/arch/arm/kernel/isa.c
index 905b1b191546..db8be609fab2 100644
--- a/arch/arm/kernel/isa.c
+++ b/arch/arm/kernel/isa.c
@@ -16,7 +16,7 @@
 
 static unsigned int isa_membase, isa_portbase, isa_portshift;
 
-static struct ctl_table ctl_isa_vars[] = {
+static const struct ctl_table ctl_isa_vars[] = {
 	{
 		.procname	= "membase",
 		.data		= &isa_membase, 
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 8c4c1a2186cc..2b601d88762d 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -562,7 +562,7 @@ static int vec_proc_do_default_vl(const struct ctl_table *table, int write,
 	return 0;
 }
 
-static struct ctl_table sve_default_vl_table[] = {
+static const struct ctl_table sve_default_vl_table[] = {
 	{
 		.procname	= "sve_default_vector_length",
 		.mode		= 0644,
@@ -585,7 +585,7 @@ static int __init sve_sysctl_init(void) { return 0; }
 #endif /* ! (CONFIG_ARM64_SVE && CONFIG_SYSCTL) */
 
 #if defined(CONFIG_ARM64_SME) && defined(CONFIG_SYSCTL)
-static struct ctl_table sme_default_vl_table[] = {
+static const struct ctl_table sme_default_vl_table[] = {
 	{
 		.procname	= "sme_default_vector_length",
 		.mode		= 0644,
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 2968a33bb3bc..42faebb7b712 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -859,7 +859,7 @@ long get_tagged_addr_ctrl(struct task_struct *task)
  * disable it for tasks that already opted in to the relaxed ABI.
  */
 
-static struct ctl_table tagged_addr_sysctl_table[] = {
+static const struct ctl_table tagged_addr_sysctl_table[] = {
 	{
 		.procname	= "tagged_addr_disabled",
 		.mode		= 0644,
diff --git a/arch/powerpc/kernel/idle.c b/arch/powerpc/kernel/idle.c
index 30b56c67fa61..e527cd3ef128 100644
--- a/arch/powerpc/kernel/idle.c
+++ b/arch/powerpc/kernel/idle.c
@@ -97,7 +97,7 @@ void power4_idle(void)
 /*
  * Register the sysctl to set/clear powersave_nap.
  */
-static struct ctl_table powersave_nap_ctl_table[] = {
+static const struct ctl_table powersave_nap_ctl_table[] = {
 	{
 		.procname	= "powersave-nap",
 		.data		= &powersave_nap,
diff --git a/arch/powerpc/platforms/pseries/mobility.c b/arch/powerpc/platforms/pseries/mobility.c
index 1798f0f14d58..62bd8e2d5d4c 100644
--- a/arch/powerpc/platforms/pseries/mobility.c
+++ b/arch/powerpc/platforms/pseries/mobility.c
@@ -53,7 +53,7 @@ struct update_props_workarea {
 static unsigned int nmi_wd_lpm_factor = 200;
 
 #ifdef CONFIG_SYSCTL
-static struct ctl_table nmi_wd_lpm_factor_ctl_table[] = {
+static const struct ctl_table nmi_wd_lpm_factor_ctl_table[] = {
 	{
 		.procname	= "nmi_wd_lpm_factor",
 		.data		= &nmi_wd_lpm_factor,
diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c
index 58b6482c2bf6..7891294abf49 100644
--- a/arch/riscv/kernel/process.c
+++ b/arch/riscv/kernel/process.c
@@ -364,7 +364,7 @@ static bool try_to_set_pmm(unsigned long value)
  * disable it for tasks that already opted in to the relaxed ABI.
  */
 
-static struct ctl_table tagged_addr_sysctl_table[] = {
+static const struct ctl_table tagged_addr_sysctl_table[] = {
 	{
 		.procname	= "tagged_addr_disabled",
 		.mode		= 0644,
diff --git a/arch/riscv/kernel/vector.c b/arch/riscv/kernel/vector.c
index 821818886fab..d022b028ac3f 100644
--- a/arch/riscv/kernel/vector.c
+++ b/arch/riscv/kernel/vector.c
@@ -287,7 +287,7 @@ long riscv_v_vstate_ctrl_set_current(unsigned long arg)
 
 #ifdef CONFIG_SYSCTL
 
-static struct ctl_table riscv_v_default_vstate_table[] = {
+static const struct ctl_table riscv_v_default_vstate_table[] = {
 	{
 		.procname	= "riscv_v_default_allow",
 		.data		= &riscv_v_implicit_uacc,
diff --git a/arch/s390/appldata/appldata_base.c b/arch/s390/appldata/appldata_base.c
index 91a30e017d65..dd7ba7587dd5 100644
--- a/arch/s390/appldata/appldata_base.c
+++ b/arch/s390/appldata/appldata_base.c
@@ -52,7 +52,7 @@ static int appldata_interval_handler(const struct ctl_table *ctl, int write,
 				     void *buffer, size_t *lenp, loff_t *ppos);
 
 static struct ctl_table_header *appldata_sysctl_header;
-static struct ctl_table appldata_table[] = {
+static const struct ctl_table appldata_table[] = {
 	{
 		.procname	= "timer",
 		.mode		= S_IRUGO | S_IWUSR,
diff --git a/arch/s390/kernel/debug.c b/arch/s390/kernel/debug.c
index de19fd8a6a95..2c245c2bce4f 100644
--- a/arch/s390/kernel/debug.c
+++ b/arch/s390/kernel/debug.c
@@ -972,7 +972,7 @@ static int s390dbf_procactive(const struct ctl_table *table, int write,
 		return 0;
 }
 
-static struct ctl_table s390dbf_table[] = {
+static const struct ctl_table s390dbf_table[] = {
 	{
 		.procname	= "debug_stoppable",
 		.data		= &debug_stoppable,
diff --git a/arch/s390/kernel/hiperdispatch.c b/arch/s390/kernel/hiperdispatch.c
index 2a99a216ab62..7857a7e8e56c 100644
--- a/arch/s390/kernel/hiperdispatch.c
+++ b/arch/s390/kernel/hiperdispatch.c
@@ -292,7 +292,7 @@ static int hiperdispatch_ctl_handler(const struct ctl_table *ctl, int write,
 	return 0;
 }
 
-static struct ctl_table hiperdispatch_ctl_table[] = {
+static const struct ctl_table hiperdispatch_ctl_table[] = {
 	{
 		.procname	= "hiperdispatch",
 		.mode		= 0644,
diff --git a/arch/s390/kernel/topology.c b/arch/s390/kernel/topology.c
index 4f9c301a705b..5067293ef69d 100644
--- a/arch/s390/kernel/topology.c
+++ b/arch/s390/kernel/topology.c
@@ -662,7 +662,7 @@ static int polarization_ctl_handler(const struct ctl_table *ctl, int write,
 	return set_polarization(polarization);
 }
 
-static struct ctl_table topology_ctl_table[] = {
+static const struct ctl_table topology_ctl_table[] = {
 	{
 		.procname	= "topology",
 		.mode		= 0644,
diff --git a/arch/s390/mm/cmm.c b/arch/s390/mm/cmm.c
index d01724a715d0..939e3bec2db7 100644
--- a/arch/s390/mm/cmm.c
+++ b/arch/s390/mm/cmm.c
@@ -332,7 +332,7 @@ static int cmm_timeout_handler(const struct ctl_table *ctl, int write,
 	return 0;
 }
 
-static struct ctl_table cmm_table[] = {
+static const struct ctl_table cmm_table[] = {
 	{
 		.procname	= "cmm_pages",
 		.mode		= 0644,
diff --git a/arch/s390/mm/pgalloc.c b/arch/s390/mm/pgalloc.c
index 58696a0c4e4a..18d3176e44fb 100644
--- a/arch/s390/mm/pgalloc.c
+++ b/arch/s390/mm/pgalloc.c
@@ -21,7 +21,7 @@
 int page_table_allocate_pgste = 0;
 EXPORT_SYMBOL(page_table_allocate_pgste);
 
-static struct ctl_table page_table_sysctl[] = {
+static const struct ctl_table page_table_sysctl[] = {
 	{
 		.procname	= "allocate_pgste",
 		.data		= &page_table_allocate_pgste,
diff --git a/arch/x86/entry/vdso/vdso32-setup.c b/arch/x86/entry/vdso/vdso32-setup.c
index 76e4e74f35b5..f6d2d8aba643 100644
--- a/arch/x86/entry/vdso/vdso32-setup.c
+++ b/arch/x86/entry/vdso/vdso32-setup.c
@@ -57,7 +57,7 @@ __setup_param("vdso=", vdso_setup, vdso32_setup, 0);
 /* Register vsyscall32 into the ABI table */
 #include <linux/sysctl.h>
 
-static struct ctl_table abi_table2[] = {
+static const struct ctl_table abi_table2[] = {
 	{
 		.procname	= "vsyscall32",
 		.data		= &vdso32_enabled,
diff --git a/arch/x86/kernel/cpu/bus_lock.c b/arch/x86/kernel/cpu/bus_lock.c
index 704e9241b964..6cba85c79d42 100644
--- a/arch/x86/kernel/cpu/bus_lock.c
+++ b/arch/x86/kernel/cpu/bus_lock.c
@@ -49,7 +49,7 @@ static unsigned int sysctl_sld_mitigate = 1;
 static DEFINE_SEMAPHORE(buslock_sem, 1);
 
 #ifdef CONFIG_PROC_SYSCTL
-static struct ctl_table sld_sysctls[] = {
+static const struct ctl_table sld_sysctls[] = {
 	{
 		.procname       = "split_lock_mitigate",
 		.data           = &sysctl_sld_mitigate,
diff --git a/arch/x86/kernel/itmt.c b/arch/x86/kernel/itmt.c
index 51b805c727fc..083d8c4deb2b 100644
--- a/arch/x86/kernel/itmt.c
+++ b/arch/x86/kernel/itmt.c
@@ -64,7 +64,7 @@ static int sched_itmt_update_handler(const struct ctl_table *table, int write,
 	return ret;
 }
 
-static struct ctl_table itmt_kern_table[] = {
+static const struct ctl_table itmt_kern_table[] = {
 	{
 		.procname	= "sched_itmt_enabled",
 		.data		= &sysctl_sched_itmt_enabled,
diff --git a/crypto/fips.c b/crypto/fips.c
index 8a784018ebfc..ec6574596e59 100644
--- a/crypto/fips.c
+++ b/crypto/fips.c
@@ -41,7 +41,7 @@ __setup("fips=", fips_enable);
 static char fips_name[] = FIPS_MODULE_NAME;
 static char fips_version[] = FIPS_MODULE_VERSION;
 
-static struct ctl_table crypto_sysctl_table[] = {
+static const struct ctl_table crypto_sysctl_table[] = {
 	{
 		.procname	= "fips_enabled",
 		.data		= &fips_enabled,
diff --git a/drivers/base/firmware_loader/fallback_table.c b/drivers/base/firmware_loader/fallback_table.c
index ddb70e29eb42..c8afc501a8a4 100644
--- a/drivers/base/firmware_loader/fallback_table.c
+++ b/drivers/base/firmware_loader/fallback_table.c
@@ -25,7 +25,7 @@ struct firmware_fallback_config fw_fallback_config = {
 EXPORT_SYMBOL_NS_GPL(fw_fallback_config, "FIRMWARE_LOADER_PRIVATE");
 
 #ifdef CONFIG_SYSCTL
-static struct ctl_table firmware_config_table[] = {
+static const struct ctl_table firmware_config_table[] = {
 	{
 		.procname	= "force_sysfs_fallback",
 		.data		= &fw_fallback_config.force_sysfs_fallback,
diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
index 51745ed1bbab..b163e043c687 100644
--- a/drivers/cdrom/cdrom.c
+++ b/drivers/cdrom/cdrom.c
@@ -3612,7 +3612,7 @@ static int cdrom_sysctl_handler(const struct ctl_table *ctl, int write,
 }
 
 /* Place files in /proc/sys/dev/cdrom */
-static struct ctl_table cdrom_table[] = {
+static const struct ctl_table cdrom_table[] = {
 	{
 		.procname	= "info",
 		.data		= &cdrom_sysctl_settings.info, 
diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c
index 48fe96ab4649..e110857824fc 100644
--- a/drivers/char/hpet.c
+++ b/drivers/char/hpet.c
@@ -724,7 +724,7 @@ static int hpet_is_known(struct hpet_data *hdp)
 	return 0;
 }
 
-static struct ctl_table hpet_table[] = {
+static const struct ctl_table hpet_table[] = {
 	{
 	 .procname = "max-user-freq",
 	 .data = &hpet_max_freq,
diff --git a/drivers/char/ipmi/ipmi_poweroff.c b/drivers/char/ipmi/ipmi_poweroff.c
index 941d2dcc8c9d..de84f59468a9 100644
--- a/drivers/char/ipmi/ipmi_poweroff.c
+++ b/drivers/char/ipmi/ipmi_poweroff.c
@@ -650,7 +650,7 @@ static struct ipmi_smi_watcher smi_watcher = {
 #ifdef CONFIG_PROC_FS
 #include <linux/sysctl.h>
 
-static struct ctl_table ipmi_table[] = {
+static const struct ctl_table ipmi_table[] = {
 	{ .procname	= "poweroff_powercycle",
 	  .data		= &poweroff_powercycle,
 	  .maxlen	= sizeof(poweroff_powercycle),
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 23ee76bbb4aa..2581186fa61b 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1665,7 +1665,7 @@ static int proc_do_rointvec(const struct ctl_table *table, int write, void *buf,
 	return write ? 0 : proc_dointvec(table, 0, buf, lenp, ppos);
 }
 
-static struct ctl_table random_table[] = {
+static const struct ctl_table random_table[] = {
 	{
 		.procname	= "poolsize",
 		.data		= &sysctl_poolsize,
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 2406cda75b7b..5384d1bb4923 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -4802,7 +4802,7 @@ int i915_perf_remove_config_ioctl(struct drm_device *dev, void *data,
 	return ret;
 }
 
-static struct ctl_table oa_table[] = {
+static const struct ctl_table oa_table[] = {
 	{
 	 .procname = "perf_stream_paranoid",
 	 .data = &i915_perf_stream_paranoid,
diff --git a/drivers/gpu/drm/xe/xe_observation.c b/drivers/gpu/drm/xe/xe_observation.c
index 8ec1b84cbb9e..57cf01efc07f 100644
--- a/drivers/gpu/drm/xe/xe_observation.c
+++ b/drivers/gpu/drm/xe/xe_observation.c
@@ -56,7 +56,7 @@ int xe_observation_ioctl(struct drm_device *dev, void *data, struct drm_file *fi
 	}
 }
 
-static struct ctl_table observation_ctl_table[] = {
+static const struct ctl_table observation_ctl_table[] = {
 	{
 	 .procname = "observation_paranoid",
 	 .data = &xe_observation_paranoid,
diff --git a/drivers/hv/hv_common.c b/drivers/hv/hv_common.c
index 7a35c82976e0..9453f0c26f2a 100644
--- a/drivers/hv/hv_common.c
+++ b/drivers/hv/hv_common.c
@@ -141,7 +141,7 @@ static int sysctl_record_panic_msg = 1;
  * sysctl option to allow the user to control whether kmsg data should be
  * reported to Hyper-V on panic.
  */
-static struct ctl_table hv_ctl_table[] = {
+static const struct ctl_table hv_ctl_table[] = {
 	{
 		.procname	= "hyperv_record_panic_msg",
 		.data		= &sysctl_record_panic_msg,
diff --git a/drivers/macintosh/mac_hid.c b/drivers/macintosh/mac_hid.c
index b461b1bed25b..369d72f59b3c 100644
--- a/drivers/macintosh/mac_hid.c
+++ b/drivers/macintosh/mac_hid.c
@@ -215,7 +215,7 @@ static int mac_hid_toggle_emumouse(const struct ctl_table *table, int write,
 }
 
 /* file(s) in /proc/sys/dev/mac_hid */
-static struct ctl_table mac_hid_files[] = {
+static const struct ctl_table mac_hid_files[] = {
 	{
 		.procname	= "mouse_button_emulation",
 		.data		= &mouse_emulate_buttons,
diff --git a/drivers/md/md.c b/drivers/md/md.c
index aebe12b0ee27..0e06f9027d81 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -294,7 +294,7 @@ void mddev_destroy_serial_pool(struct mddev *mddev, struct md_rdev *rdev)
 
 static struct ctl_table_header *raid_table_header;
 
-static struct ctl_table raid_table[] = {
+static const struct ctl_table raid_table[] = {
 	{
 		.procname	= "speed_limit_min",
 		.data		= &sysctl_speed_limit_min,
diff --git a/drivers/misc/sgi-xp/xpc_main.c b/drivers/misc/sgi-xp/xpc_main.c
index 61b66e318488..7a3c34306de9 100644
--- a/drivers/misc/sgi-xp/xpc_main.c
+++ b/drivers/misc/sgi-xp/xpc_main.c
@@ -93,7 +93,7 @@ int xpc_disengage_timelimit = XPC_DISENGAGE_DEFAULT_TIMELIMIT;
 static int xpc_disengage_min_timelimit;	/* = 0 */
 static int xpc_disengage_max_timelimit = 120;
 
-static struct ctl_table xpc_sys_xpc_hb[] = {
+static const struct ctl_table xpc_sys_xpc_hb[] = {
 	{
 	 .procname = "hb_interval",
 	 .data = &xpc_hb_interval,
@@ -111,7 +111,7 @@ static struct ctl_table xpc_sys_xpc_hb[] = {
 	 .extra1 = &xpc_hb_check_min_interval,
 	 .extra2 = &xpc_hb_check_max_interval},
 };
-static struct ctl_table xpc_sys_xpc[] = {
+static const struct ctl_table xpc_sys_xpc[] = {
 	{
 	 .procname = "disengage_timelimit",
 	 .data = &xpc_disengage_timelimit,
diff --git a/drivers/perf/arm_pmuv3.c b/drivers/perf/arm_pmuv3.c
index b5cc11abc962..0e360feb3432 100644
--- a/drivers/perf/arm_pmuv3.c
+++ b/drivers/perf/arm_pmuv3.c
@@ -1279,7 +1279,7 @@ static int armv8pmu_proc_user_access_handler(const struct ctl_table *table, int
 	return 0;
 }
 
-static struct ctl_table armv8_pmu_sysctl_table[] = {
+static const struct ctl_table armv8_pmu_sysctl_table[] = {
 	{
 		.procname       = "perf_user_access",
 		.data		= &sysctl_perf_user_access,
diff --git a/drivers/perf/riscv_pmu_sbi.c b/drivers/perf/riscv_pmu_sbi.c
index 1aa303f76cc7..ea96c0a88f73 100644
--- a/drivers/perf/riscv_pmu_sbi.c
+++ b/drivers/perf/riscv_pmu_sbi.c
@@ -1315,7 +1315,7 @@ static int riscv_pmu_proc_user_access_handler(const struct ctl_table *table,
 	return 0;
 }
 
-static struct ctl_table sbi_pmu_sysctl_table[] = {
+static const struct ctl_table sbi_pmu_sysctl_table[] = {
 	{
 		.procname       = "perf_user_access",
 		.data		= &sysctl_perf_user_access,
diff --git a/drivers/scsi/scsi_sysctl.c b/drivers/scsi/scsi_sysctl.c
index 093774d77534..be4aef0f4f99 100644
--- a/drivers/scsi/scsi_sysctl.c
+++ b/drivers/scsi/scsi_sysctl.c
@@ -12,7 +12,7 @@
 #include "scsi_priv.h"
 
 
-static struct ctl_table scsi_table[] = {
+static const struct ctl_table scsi_table[] = {
 	{ .procname	= "logging_level",
 	  .data		= &scsi_logging_level,
 	  .maxlen	= sizeof(scsi_logging_level),
diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index 94127868bedf..effb7e768165 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -1639,7 +1639,7 @@ MODULE_PARM_DESC(allow_dio, "allow direct I/O (default: 0 (disallow))");
 #ifdef CONFIG_SYSCTL
 #include <linux/sysctl.h>
 
-static struct ctl_table sg_sysctls[] = {
+static const struct ctl_table sg_sysctls[] = {
 	{
 		.procname	= "sg-big-buff",
 		.data		= &sg_big_buff,
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index dcb1769c3625..0e84677712b4 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -3618,7 +3618,7 @@ void console_sysfs_notify(void)
 		sysfs_notify(&consdev->kobj, NULL, "active");
 }
 
-static struct ctl_table tty_table[] = {
+static const struct ctl_table tty_table[] = {
 	{
 		.procname	= "legacy_tiocsti",
 		.data		= &tty_legacy_tiocsti,
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 528395133b4f..163f7f1d70f1 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -84,7 +84,7 @@ module_param(balloon_boot_timeout, uint, 0444);
 #ifdef CONFIG_XEN_BALLOON_MEMORY_HOTPLUG
 static int xen_hotplug_unpopulated;
 
-static struct ctl_table balloon_table[] = {
+static const struct ctl_table balloon_table[] = {
 	{
 		.procname	= "hotplug_unpopulated",
 		.data		= &xen_hotplug_unpopulated,
diff --git a/fs/aio.c b/fs/aio.c
index 50671640b588..7b976b564cfc 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -224,7 +224,7 @@ static unsigned long aio_nr;		/* current system wide number of aio requests */
 static unsigned long aio_max_nr = 0x10000; /* system wide maximum number of aio requests */
 /*----end sysctl variables---*/
 #ifdef CONFIG_SYSCTL
-static struct ctl_table aio_sysctls[] = {
+static const struct ctl_table aio_sysctls[] = {
 	{
 		.procname	= "aio-nr",
 		.data		= &aio_nr,
diff --git a/fs/cachefiles/error_inject.c b/fs/cachefiles/error_inject.c
index 1715d5ca2b2d..e341ade47dd8 100644
--- a/fs/cachefiles/error_inject.c
+++ b/fs/cachefiles/error_inject.c
@@ -11,7 +11,7 @@
 unsigned int cachefiles_error_injection_state;
 
 static struct ctl_table_header *cachefiles_sysctl;
-static struct ctl_table cachefiles_sysctls[] = {
+static const struct ctl_table cachefiles_sysctls[] = {
 	{
 		.procname	= "error_injection",
 		.data		= &cachefiles_error_injection_state,
diff --git a/fs/coda/sysctl.c b/fs/coda/sysctl.c
index 9f2d5743e2c8..0df46f09b6cc 100644
--- a/fs/coda/sysctl.c
+++ b/fs/coda/sysctl.c
@@ -14,7 +14,7 @@
 
 static struct ctl_table_header *fs_table_header;
 
-static struct ctl_table coda_table[] = {
+static const struct ctl_table coda_table[] = {
 	{
 		.procname	= "timeout",
 		.data		= &coda_timeout,
diff --git a/fs/coredump.c b/fs/coredump.c
index d48edb37bc35..591700e1b2ce 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -995,7 +995,7 @@ static int proc_dostring_coredump(const struct ctl_table *table, int write,
 static const unsigned int core_file_note_size_min = CORE_FILE_NOTE_SIZE_DEFAULT;
 static const unsigned int core_file_note_size_max = CORE_FILE_NOTE_SIZE_MAX;
 
-static struct ctl_table coredump_sysctls[] = {
+static const struct ctl_table coredump_sysctls[] = {
 	{
 		.procname	= "core_uses_pid",
 		.data		= &core_uses_pid,
diff --git a/fs/dcache.c b/fs/dcache.c
index b4d5e9e1e43d..370302d4e488 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -192,7 +192,7 @@ static int proc_nr_dentry(const struct ctl_table *table, int write, void *buffer
 	return proc_doulongvec_minmax(table, write, buffer, lenp, ppos);
 }
 
-static struct ctl_table fs_dcache_sysctls[] = {
+static const struct ctl_table fs_dcache_sysctls[] = {
 	{
 		.procname	= "dentry-state",
 		.data		= &dentry_stat,
diff --git a/fs/devpts/inode.c b/fs/devpts/inode.c
index b20e565b9c5e..1096ff8562fa 100644
--- a/fs/devpts/inode.c
+++ b/fs/devpts/inode.c
@@ -45,7 +45,7 @@ static int pty_limit_min;
 static int pty_limit_max = INT_MAX;
 static atomic_t pty_count = ATOMIC_INIT(0);
 
-static struct ctl_table pty_table[] = {
+static const struct ctl_table pty_table[] = {
 	{
 		.procname	= "max",
 		.maxlen		= sizeof(int),
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index f9898e60dd8b..7c0980db77b3 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -318,7 +318,7 @@ static void unlist_file(struct epitems_head *head)
 static long long_zero;
 static long long_max = LONG_MAX;
 
-static struct ctl_table epoll_table[] = {
+static const struct ctl_table epoll_table[] = {
 	{
 		.procname	= "max_user_watches",
 		.data		= &max_user_watches,
diff --git a/fs/exec.c b/fs/exec.c
index 98cb7ba9983c..96229a6a4dff 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -2142,7 +2142,7 @@ static int proc_dointvec_minmax_coredump(const struct ctl_table *table, int writ
 	return error;
 }
 
-static struct ctl_table fs_exec_sysctls[] = {
+static const struct ctl_table fs_exec_sysctls[] = {
 	{
 		.procname	= "suid_dumpable",
 		.data		= &suid_dumpable,
diff --git a/fs/file_table.c b/fs/file_table.c
index 976736be47cb..70ed0b3a5a0e 100644
--- a/fs/file_table.c
+++ b/fs/file_table.c
@@ -106,7 +106,7 @@ static int proc_nr_files(const struct ctl_table *table, int write, void *buffer,
 	return proc_doulongvec_minmax(table, write, buffer, lenp, ppos);
 }
 
-static struct ctl_table fs_stat_sysctls[] = {
+static const struct ctl_table fs_stat_sysctls[] = {
 	{
 		.procname	= "file-nr",
 		.data		= &files_stat,
diff --git a/fs/fuse/sysctl.c b/fs/fuse/sysctl.c
index b272bb333005..63fb1e5bee30 100644
--- a/fs/fuse/sysctl.c
+++ b/fs/fuse/sysctl.c
@@ -13,7 +13,7 @@ static struct ctl_table_header *fuse_table_header;
 /* Bound by fuse_init_out max_pages, which is a u16 */
 static unsigned int sysctl_fuse_max_pages_limit = 65535;
 
-static struct ctl_table fuse_sysctl_table[] = {
+static const struct ctl_table fuse_sysctl_table[] = {
 	{
 		.procname	= "max_pages_limit",
 		.data		= &fuse_max_pages_limit,
diff --git a/fs/inode.c b/fs/inode.c
index 6b4c77268fc0..5587aabdaa5e 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -184,7 +184,7 @@ static int proc_nr_inodes(const struct ctl_table *table, int write, void *buffer
 	return proc_doulongvec_minmax(table, write, buffer, lenp, ppos);
 }
 
-static struct ctl_table inodes_sysctls[] = {
+static const struct ctl_table inodes_sysctls[] = {
 	{
 		.procname	= "inode-nr",
 		.data		= &inodes_stat,
diff --git a/fs/lockd/svc.c b/fs/lockd/svc.c
index 4ec22c2f2ea3..d6cac1c89c2a 100644
--- a/fs/lockd/svc.c
+++ b/fs/lockd/svc.c
@@ -419,7 +419,7 @@ EXPORT_SYMBOL_GPL(lockd_down);
  * Sysctl parameters (same as module parameters, different interface).
  */
 
-static struct ctl_table nlm_sysctls[] = {
+static const struct ctl_table nlm_sysctls[] = {
 	{
 		.procname	= "nlm_grace_period",
 		.data		= &nlm_grace_period,
diff --git a/fs/locks.c b/fs/locks.c
index 25afc8d9c9d1..1619cddfa7a4 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -97,7 +97,7 @@ static int leases_enable = 1;
 static int lease_break_time = 45;
 
 #ifdef CONFIG_SYSCTL
-static struct ctl_table locks_sysctls[] = {
+static const struct ctl_table locks_sysctls[] = {
 	{
 		.procname	= "leases-enable",
 		.data		= &leases_enable,
diff --git a/fs/namei.c b/fs/namei.c
index 9d30c7aa9aa6..6a18b2ea21b7 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1099,7 +1099,7 @@ static int sysctl_protected_fifos __read_mostly;
 static int sysctl_protected_regular __read_mostly;
 
 #ifdef CONFIG_SYSCTL
-static struct ctl_table namei_sysctls[] = {
+static const struct ctl_table namei_sysctls[] = {
 	{
 		.procname	= "protected_symlinks",
 		.data		= &sysctl_protected_symlinks,
diff --git a/fs/namespace.c b/fs/namespace.c
index 23e81c2a1e3f..3819c322244e 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -5927,7 +5927,7 @@ const struct proc_ns_operations mntns_operations = {
 };
 
 #ifdef CONFIG_SYSCTL
-static struct ctl_table fs_namespace_sysctls[] = {
+static const struct ctl_table fs_namespace_sysctls[] = {
 	{
 		.procname	= "mount-max",
 		.data		= &sysctl_mount_max,
diff --git a/fs/nfs/nfs4sysctl.c b/fs/nfs/nfs4sysctl.c
index 886a7c4c60b3..d1a92d8f8ba4 100644
--- a/fs/nfs/nfs4sysctl.c
+++ b/fs/nfs/nfs4sysctl.c
@@ -17,7 +17,7 @@ static const int nfs_set_port_min;
 static const int nfs_set_port_max = 65535;
 static struct ctl_table_header *nfs4_callback_sysctl_table;
 
-static struct ctl_table nfs4_cb_sysctls[] = {
+static const struct ctl_table nfs4_cb_sysctls[] = {
 	{
 		.procname = "nfs_callback_tcpport",
 		.data = &nfs_callback_set_tcpport,
diff --git a/fs/nfs/sysctl.c b/fs/nfs/sysctl.c
index e645be1a3381..f579df0e8d67 100644
--- a/fs/nfs/sysctl.c
+++ b/fs/nfs/sysctl.c
@@ -14,7 +14,7 @@
 
 static struct ctl_table_header *nfs_callback_sysctl_table;
 
-static struct ctl_table nfs_cb_sysctls[] = {
+static const struct ctl_table nfs_cb_sysctls[] = {
 	{
 		.procname	= "nfs_mountpoint_timeout",
 		.data		= &nfs_mountpoint_expiry_timeout,
diff --git a/fs/notify/dnotify/dnotify.c b/fs/notify/dnotify/dnotify.c
index 6004dfdfdf0f..c4cdaf5fa7ed 100644
--- a/fs/notify/dnotify/dnotify.c
+++ b/fs/notify/dnotify/dnotify.c
@@ -20,7 +20,7 @@
 
 static int dir_notify_enable __read_mostly = 1;
 #ifdef CONFIG_SYSCTL
-static struct ctl_table dnotify_sysctls[] = {
+static const struct ctl_table dnotify_sysctls[] = {
 	{
 		.procname	= "dir-notify-enable",
 		.data		= &dir_notify_enable,
diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c
index 2d85c71717d6..004cfdae1316 100644
--- a/fs/notify/fanotify/fanotify_user.c
+++ b/fs/notify/fanotify/fanotify_user.c
@@ -58,7 +58,7 @@ static int fanotify_max_queued_events __read_mostly;
 static long ft_zero = 0;
 static long ft_int_max = INT_MAX;
 
-static struct ctl_table fanotify_table[] = {
+static const struct ctl_table fanotify_table[] = {
 	{
 		.procname	= "max_user_groups",
 		.data	= &init_user_ns.ucount_max[UCOUNT_FANOTIFY_GROUPS],
diff --git a/fs/notify/inotify/inotify_user.c b/fs/notify/inotify/inotify_user.c
index e0c48956608a..b372fb2c56bd 100644
--- a/fs/notify/inotify/inotify_user.c
+++ b/fs/notify/inotify/inotify_user.c
@@ -58,7 +58,7 @@ struct kmem_cache *inotify_inode_mark_cachep __ro_after_init;
 static long it_zero = 0;
 static long it_int_max = INT_MAX;
 
-static struct ctl_table inotify_table[] = {
+static const struct ctl_table inotify_table[] = {
 	{
 		.procname	= "max_user_instances",
 		.data		= &init_user_ns.ucount_max[UCOUNT_INOTIFY_INSTANCES],
diff --git a/fs/ocfs2/stackglue.c b/fs/ocfs2/stackglue.c
index 20aa37b67cfb..ddd761cf44c8 100644
--- a/fs/ocfs2/stackglue.c
+++ b/fs/ocfs2/stackglue.c
@@ -650,7 +650,7 @@ static int ocfs2_sysfs_init(void)
  * and easier to preserve the name.
  */
 
-static struct ctl_table ocfs2_nm_table[] = {
+static const struct ctl_table ocfs2_nm_table[] = {
 	{
 		.procname	= "hb_ctl_path",
 		.data		= ocfs2_hb_ctl_path,
diff --git a/fs/pipe.c b/fs/pipe.c
index 12b22c2723b7..638fb318e7be 100644
--- a/fs/pipe.c
+++ b/fs/pipe.c
@@ -1477,7 +1477,7 @@ static int proc_dopipe_max_size(const struct ctl_table *table, int write,
 				 do_proc_dopipe_max_size_conv, NULL);
 }
 
-static struct ctl_table fs_pipe_sysctls[] = {
+static const struct ctl_table fs_pipe_sysctls[] = {
 	{
 		.procname	= "pipe-max-size",
 		.data		= &pipe_max_size,
diff --git a/fs/quota/dquot.c b/fs/quota/dquot.c
index f9578918cfb2..825c5c2e0962 100644
--- a/fs/quota/dquot.c
+++ b/fs/quota/dquot.c
@@ -2926,7 +2926,7 @@ static int do_proc_dqstats(const struct ctl_table *table, int write,
 	return proc_doulongvec_minmax(table, write, buffer, lenp, ppos);
 }
 
-static struct ctl_table fs_dqstats_table[] = {
+static const struct ctl_table fs_dqstats_table[] = {
 	{
 		.procname	= "lookups",
 		.data		= &dqstats.stat[DQST_LOOKUPS],
diff --git a/fs/sysctls.c b/fs/sysctls.c
index 8dbde9a802fa..ad429dffeb4b 100644
--- a/fs/sysctls.c
+++ b/fs/sysctls.c
@@ -7,7 +7,7 @@
 #include <linux/init.h>
 #include <linux/sysctl.h>
 
-static struct ctl_table fs_shared_sysctls[] = {
+static const struct ctl_table fs_shared_sysctls[] = {
 	{
 		.procname	= "overflowuid",
 		.data		= &fs_overflowuid,
diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
index 7c0bd0b55f88..97c4d71115d8 100644
--- a/fs/userfaultfd.c
+++ b/fs/userfaultfd.c
@@ -36,7 +36,7 @@
 static int sysctl_unprivileged_userfaultfd __read_mostly;
 
 #ifdef CONFIG_SYSCTL
-static struct ctl_table vm_userfaultfd_table[] = {
+static const struct ctl_table vm_userfaultfd_table[] = {
 	{
 		.procname	= "unprivileged_userfaultfd",
 		.data		= &sysctl_unprivileged_userfaultfd,
diff --git a/fs/verity/init.c b/fs/verity/init.c
index f440f0e61e3e..6e8d33b50240 100644
--- a/fs/verity/init.c
+++ b/fs/verity/init.c
@@ -10,7 +10,7 @@
 #include <linux/ratelimit.h>
 
 #ifdef CONFIG_SYSCTL
-static struct ctl_table fsverity_sysctl_table[] = {
+static const struct ctl_table fsverity_sysctl_table[] = {
 #ifdef CONFIG_FS_VERITY_BUILTIN_SIGNATURES
 	{
 		.procname       = "require_signatures",
diff --git a/fs/xfs/xfs_sysctl.c b/fs/xfs/xfs_sysctl.c
index c84df23b494d..751dc74a3067 100644
--- a/fs/xfs/xfs_sysctl.c
+++ b/fs/xfs/xfs_sysctl.c
@@ -66,7 +66,7 @@ xfs_deprecated_dointvec_minmax(
 	return proc_dointvec_minmax(ctl, write, buffer, lenp, ppos);
 }
 
-static struct ctl_table xfs_table[] = {
+static const struct ctl_table xfs_table[] = {
 	{
 		.procname	= "irix_sgid_inherit",
 		.data		= &xfs_params.sgid_inherit.val,
diff --git a/init/do_mounts_initrd.c b/init/do_mounts_initrd.c
index 22c7f41ff642..903b4d573d3d 100644
--- a/init/do_mounts_initrd.c
+++ b/init/do_mounts_initrd.c
@@ -21,7 +21,7 @@ phys_addr_t phys_initrd_start __initdata;
 unsigned long phys_initrd_size __initdata;
 
 #ifdef CONFIG_SYSCTL
-static struct ctl_table kern_do_mounts_initrd_table[] = {
+static const struct ctl_table kern_do_mounts_initrd_table[] = {
 	{
 		.procname       = "real-root-dev",
 		.data           = &real_root_dev,
diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c
index d3403c8216db..72ad31225fb3 100644
--- a/io_uring/io_uring.c
+++ b/io_uring/io_uring.c
@@ -156,7 +156,7 @@ static int __read_mostly sysctl_io_uring_disabled;
 static int __read_mostly sysctl_io_uring_group = -1;
 
 #ifdef CONFIG_SYSCTL
-static struct ctl_table kernel_io_uring_disabled_table[] = {
+static const struct ctl_table kernel_io_uring_disabled_table[] = {
 	{
 		.procname	= "io_uring_disabled",
 		.data		= &sysctl_io_uring_disabled,
diff --git a/ipc/ipc_sysctl.c b/ipc/ipc_sysctl.c
index 54318e0b4557..15b17e86e198 100644
--- a/ipc/ipc_sysctl.c
+++ b/ipc/ipc_sysctl.c
@@ -73,7 +73,7 @@ int ipc_mni = IPCMNI;
 int ipc_mni_shift = IPCMNI_SHIFT;
 int ipc_min_cycle = RADIX_TREE_MAP_SIZE;
 
-static struct ctl_table ipc_sysctls[] = {
+static const struct ctl_table ipc_sysctls[] = {
 	{
 		.procname	= "shmmax",
 		.data		= &init_ipc_ns.shm_ctlmax,
diff --git a/ipc/mq_sysctl.c b/ipc/mq_sysctl.c
index b70dc2ff22d8..0dd12e1c9f53 100644
--- a/ipc/mq_sysctl.c
+++ b/ipc/mq_sysctl.c
@@ -20,7 +20,7 @@ static int msg_max_limit_max = HARD_MSGMAX;
 static int msg_maxsize_limit_min = MIN_MSGSIZEMAX;
 static int msg_maxsize_limit_max = HARD_MSGSIZEMAX;
 
-static struct ctl_table mq_sysctls[] = {
+static const struct ctl_table mq_sysctls[] = {
 	{
 		.procname	= "queues_max",
 		.data		= &init_ipc_ns.mq_queues_max,
diff --git a/kernel/acct.c b/kernel/acct.c
index 179848ad33e9..31222e8cd534 100644
--- a/kernel/acct.c
+++ b/kernel/acct.c
@@ -76,7 +76,7 @@ static int acct_parm[3] = {4, 2, 30};
 #define ACCT_TIMEOUT	(acct_parm[2])	/* foo second timeout between checks */
 
 #ifdef CONFIG_SYSCTL
-static struct ctl_table kern_acct_table[] = {
+static const struct ctl_table kern_acct_table[] = {
 	{
 		.procname       = "acct",
 		.data           = &acct_parm,
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 5684e8ce132d..fbcf07f98d8b 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -6124,7 +6124,7 @@ static int bpf_unpriv_handler(const struct ctl_table *table, int write,
 	return ret;
 }
 
-static struct ctl_table bpf_syscall_table[] = {
+static const struct ctl_table bpf_syscall_table[] = {
 	{
 		.procname	= "unprivileged_bpf_disabled",
 		.data		= &sysctl_unprivileged_bpf_disabled,
diff --git a/kernel/delayacct.c b/kernel/delayacct.c
index dead51de8eb5..75659ac036cd 100644
--- a/kernel/delayacct.c
+++ b/kernel/delayacct.c
@@ -64,7 +64,7 @@ static int sysctl_delayacct(const struct ctl_table *table, int write, void *buff
 	return err;
 }
 
-static struct ctl_table kern_delayacct_table[] = {
+static const struct ctl_table kern_delayacct_table[] = {
 	{
 		.procname       = "task_delayacct",
 		.data           = NULL,
diff --git a/kernel/exit.c b/kernel/exit.c
index 1dcddfe537ee..3485e5fc499e 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -85,7 +85,7 @@
 static unsigned int oops_limit = 10000;
 
 #ifdef CONFIG_SYSCTL
-static struct ctl_table kern_exit_table[] = {
+static const struct ctl_table kern_exit_table[] = {
 	{
 		.procname       = "oops_limit",
 		.data           = &oops_limit,
diff --git a/kernel/hung_task.c b/kernel/hung_task.c
index c18717189f32..62a5d8927ce9 100644
--- a/kernel/hung_task.c
+++ b/kernel/hung_task.c
@@ -272,7 +272,7 @@ static int proc_dohung_task_timeout_secs(const struct ctl_table *table, int writ
  * and hung_task_check_interval_secs
  */
 static const unsigned long hung_task_timeout_max = (LONG_MAX / HZ);
-static struct ctl_table hung_task_sysctls[] = {
+static const struct ctl_table hung_task_sysctls[] = {
 #ifdef CONFIG_SMP
 	{
 		.procname	= "hung_task_all_cpu_backtrace",
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index c0caa14880c3..71b0809e06d6 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -925,7 +925,7 @@ static int kexec_limit_handler(const struct ctl_table *table, int write,
 	return proc_dointvec(&tmp, write, buffer, lenp, ppos);
 }
 
-static struct ctl_table kexec_core_sysctls[] = {
+static const struct ctl_table kexec_core_sysctls[] = {
 	{
 		.procname	= "kexec_load_disabled",
 		.data		= &kexec_load_disabled,
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index b027a4030976..9a15fb343be8 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -954,7 +954,7 @@ static int proc_kprobes_optimization_handler(const struct ctl_table *table,
 	return ret;
 }
 
-static struct ctl_table kprobe_sysctls[] = {
+static const struct ctl_table kprobe_sysctls[] = {
 	{
 		.procname	= "kprobes-optimization",
 		.data		= &sysctl_kprobes_optimization,
diff --git a/kernel/latencytop.c b/kernel/latencytop.c
index 7a75eab9c179..39a5fcdff9f9 100644
--- a/kernel/latencytop.c
+++ b/kernel/latencytop.c
@@ -77,7 +77,7 @@ static int sysctl_latencytop(const struct ctl_table *table, int write, void *buf
 	return err;
 }
 
-static struct ctl_table latencytop_sysctl[] = {
+static const struct ctl_table latencytop_sysctl[] = {
 	{
 		.procname   = "latencytop",
 		.data       = &latencytop_enabled,
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 2d8ec0351ef9..926b796ba71a 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -79,7 +79,7 @@ module_param(lock_stat, int, 0644);
 #endif
 
 #ifdef CONFIG_SYSCTL
-static struct ctl_table kern_lockdep_table[] = {
+static const struct ctl_table kern_lockdep_table[] = {
 #ifdef CONFIG_PROVE_LOCKING
 	{
 		.procname       = "prove_locking",
diff --git a/kernel/panic.c b/kernel/panic.c
index fbc59b3b64d0..d8635d5cecb2 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -84,7 +84,7 @@ ATOMIC_NOTIFIER_HEAD(panic_notifier_list);
 EXPORT_SYMBOL(panic_notifier_list);
 
 #ifdef CONFIG_SYSCTL
-static struct ctl_table kern_panic_table[] = {
+static const struct ctl_table kern_panic_table[] = {
 #ifdef CONFIG_SMP
 	{
 		.procname       = "oops_all_cpu_backtrace",
diff --git a/kernel/pid_namespace.c b/kernel/pid_namespace.c
index d70ab49d5b4a..0f23285be4f9 100644
--- a/kernel/pid_namespace.c
+++ b/kernel/pid_namespace.c
@@ -282,7 +282,7 @@ static int pid_ns_ctl_handler(const struct ctl_table *table, int write,
 }
 
 extern int pid_max;
-static struct ctl_table pid_ns_ctl_table[] = {
+static const struct ctl_table pid_ns_ctl_table[] = {
 	{
 		.procname = "ns_last_pid",
 		.maxlen = sizeof(int),
diff --git a/kernel/pid_sysctl.h b/kernel/pid_sysctl.h
index 18ecaef6be41..5d8f981de7c5 100644
--- a/kernel/pid_sysctl.h
+++ b/kernel/pid_sysctl.h
@@ -31,7 +31,7 @@ static int pid_mfd_noexec_dointvec_minmax(const struct ctl_table *table,
 	return err;
 }
 
-static struct ctl_table pid_ns_ctl_table_vm[] = {
+static const struct ctl_table pid_ns_ctl_table_vm[] = {
 	{
 		.procname	= "memfd_noexec",
 		.data		= &init_pid_ns.memfd_noexec_scope,
diff --git a/kernel/printk/sysctl.c b/kernel/printk/sysctl.c
index f5072dc85f7a..da77f3f5c1fe 100644
--- a/kernel/printk/sysctl.c
+++ b/kernel/printk/sysctl.c
@@ -20,7 +20,7 @@ static int proc_dointvec_minmax_sysadmin(const struct ctl_table *table, int writ
 	return proc_dointvec_minmax(table, write, buffer, lenp, ppos);
 }
 
-static struct ctl_table printk_sysctls[] = {
+static const struct ctl_table printk_sysctls[] = {
 	{
 		.procname	= "printk",
 		.data		= &console_loglevel,
diff --git a/kernel/reboot.c b/kernel/reboot.c
index a701000bab34..b5a8569e5d81 100644
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -1287,7 +1287,7 @@ static struct attribute *reboot_attrs[] = {
 };
 
 #ifdef CONFIG_SYSCTL
-static struct ctl_table kern_reboot_table[] = {
+static const struct ctl_table kern_reboot_table[] = {
 	{
 		.procname       = "poweroff_cmd",
 		.data           = &poweroff_cmd,
diff --git a/kernel/sched/autogroup.c b/kernel/sched/autogroup.c
index db68a964e34e..83d46b9b8ec8 100644
--- a/kernel/sched/autogroup.c
+++ b/kernel/sched/autogroup.c
@@ -9,7 +9,7 @@ static struct autogroup autogroup_default;
 static atomic_t autogroup_seq_nr;
 
 #ifdef CONFIG_SYSCTL
-static struct ctl_table sched_autogroup_sysctls[] = {
+static const struct ctl_table sched_autogroup_sysctls[] = {
 	{
 		.procname       = "sched_autogroup_enabled",
 		.data           = &sysctl_sched_autogroup_enabled,
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 3e5a6bf587f9..00fea6f32ae5 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -4646,7 +4646,7 @@ static int sysctl_schedstats(const struct ctl_table *table, int write, void *buf
 #endif /* CONFIG_SCHEDSTATS */
 
 #ifdef CONFIG_SYSCTL
-static struct ctl_table sched_core_sysctls[] = {
+static const struct ctl_table sched_core_sysctls[] = {
 #ifdef CONFIG_SCHEDSTATS
 	{
 		.procname       = "sched_schedstats",
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index d94f2ed6d1f4..dab4887d6406 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -26,7 +26,7 @@
 static unsigned int sysctl_sched_dl_period_max = 1 << 22; /* ~4 seconds */
 static unsigned int sysctl_sched_dl_period_min = 100;     /* 100 us */
 #ifdef CONFIG_SYSCTL
-static struct ctl_table sched_dl_sysctls[] = {
+static const struct ctl_table sched_dl_sysctls[] = {
 	{
 		.procname       = "sched_deadline_period_max_us",
 		.data           = &sysctl_sched_dl_period_max,
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 3e9ca38512de..1692dbb67d7a 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -130,7 +130,7 @@ static unsigned int sysctl_numa_balancing_promote_rate_limit = 65536;
 #endif
 
 #ifdef CONFIG_SYSCTL
-static struct ctl_table sched_fair_sysctls[] = {
+static const struct ctl_table sched_fair_sysctls[] = {
 #ifdef CONFIG_CFS_BANDWIDTH
 	{
 		.procname       = "sched_cfs_bandwidth_slice_us",
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index bd66a46b06ac..4b8e33c615b1 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -26,7 +26,7 @@ static int sched_rt_handler(const struct ctl_table *table, int write, void *buff
 		size_t *lenp, loff_t *ppos);
 static int sched_rr_handler(const struct ctl_table *table, int write, void *buffer,
 		size_t *lenp, loff_t *ppos);
-static struct ctl_table sched_rt_sysctls[] = {
+static const struct ctl_table sched_rt_sysctls[] = {
 	{
 		.procname       = "sched_rt_period_us",
 		.data           = &sysctl_sched_rt_period,
diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
index 9748a4c8d668..20d59b0bc928 100644
--- a/kernel/sched/topology.c
+++ b/kernel/sched/topology.c
@@ -312,7 +312,7 @@ static int sched_energy_aware_handler(const struct ctl_table *table, int write,
 	return ret;
 }
 
-static struct ctl_table sched_energy_aware_sysctls[] = {
+static const struct ctl_table sched_energy_aware_sysctls[] = {
 	{
 		.procname       = "sched_energy_aware",
 		.data           = &sysctl_sched_energy_aware,
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index 385d48293a5f..f59381c4a2ff 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -2450,7 +2450,7 @@ static int seccomp_actions_logged_handler(const struct ctl_table *ro_table, int
 	return ret;
 }
 
-static struct ctl_table seccomp_sysctl_table[] = {
+static const struct ctl_table seccomp_sysctl_table[] = {
 	{
 		.procname	= "actions_avail",
 		.data		= (void *) &seccomp_actions_avail,
diff --git a/kernel/signal.c b/kernel/signal.c
index 989b1cc9116a..77f32c2d6ccb 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -4931,7 +4931,7 @@ static inline void siginfo_buildtime_checks(void)
 }
 
 #if defined(CONFIG_SYSCTL)
-static struct ctl_table signal_debug_table[] = {
+static const struct ctl_table signal_debug_table[] = {
 #ifdef CONFIG_SYSCTL_EXCEPTION_TRACE
 	{
 		.procname	= "exception-trace",
diff --git a/kernel/stackleak.c b/kernel/stackleak.c
index 39fd620a7db6..c1bfc14cd36e 100644
--- a/kernel/stackleak.c
+++ b/kernel/stackleak.c
@@ -44,7 +44,7 @@ static int stack_erasing_sysctl(const struct ctl_table *table, int write,
 					state ? "enabled" : "disabled");
 	return ret;
 }
-static struct ctl_table stackleak_sysctls[] = {
+static const struct ctl_table stackleak_sysctls[] = {
 	{
 		.procname	= "stack_erasing",
 		.data		= NULL,
diff --git a/kernel/sysctl-test.c b/kernel/sysctl-test.c
index 3ac98bb7fb82..eb2842bd0557 100644
--- a/kernel/sysctl-test.c
+++ b/kernel/sysctl-test.c
@@ -374,7 +374,7 @@ static void sysctl_test_register_sysctl_sz_invalid_extra_value(
 		struct kunit *test)
 {
 	unsigned char data = 0;
-	struct ctl_table table_foo[] = {
+	const struct ctl_table table_foo[] = {
 		{
 			.procname	= "foo",
 			.data		= &data,
@@ -386,7 +386,7 @@ static void sysctl_test_register_sysctl_sz_invalid_extra_value(
 		},
 	};
 
-	struct ctl_table table_bar[] = {
+	const struct ctl_table table_bar[] = {
 		{
 			.procname	= "bar",
 			.data		= &data,
@@ -398,7 +398,7 @@ static void sysctl_test_register_sysctl_sz_invalid_extra_value(
 		},
 	};
 
-	struct ctl_table table_qux[] = {
+	const struct ctl_table table_qux[] = {
 		{
 			.procname	= "qux",
 			.data		= &data,
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 5c9202cb8f59..3a0132cb0d5d 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1609,7 +1609,7 @@ int proc_do_static_key(const struct ctl_table *table, int write,
 	return ret;
 }
 
-static struct ctl_table kern_table[] = {
+static const struct ctl_table kern_table[] = {
 	{
 		.procname	= "panic",
 		.data		= &panic_timeout,
@@ -2030,7 +2030,7 @@ static struct ctl_table kern_table[] = {
 #endif
 };
 
-static struct ctl_table vm_table[] = {
+static const struct ctl_table vm_table[] = {
 	{
 		.procname	= "overcommit_memory",
 		.data		= &sysctl_overcommit_memory,
diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index a5860bf6d16f..79a1f83d2944 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -301,7 +301,7 @@ static int timer_migration_handler(const struct ctl_table *table, int write,
 	return ret;
 }
 
-static struct ctl_table timer_sysctl[] = {
+static const struct ctl_table timer_sysctl[] = {
 	{
 		.procname	= "timer_migration",
 		.data		= &sysctl_timer_migration,
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 2e113f8b13a2..489cbab3d64c 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -8786,7 +8786,7 @@ ftrace_enable_sysctl(const struct ctl_table *table, int write,
 	return ret;
 }
 
-static struct ctl_table ftrace_sysctls[] = {
+static const struct ctl_table ftrace_sysctls[] = {
 	{
 		.procname       = "ftrace_enabled",
 		.data           = &ftrace_enabled,
diff --git a/kernel/trace/trace_events_user.c b/kernel/trace/trace_events_user.c
index 17bcad8f79de..97325fbd6283 100644
--- a/kernel/trace/trace_events_user.c
+++ b/kernel/trace/trace_events_user.c
@@ -2899,7 +2899,7 @@ static int set_max_user_events_sysctl(const struct ctl_table *table, int write,
 	return ret;
 }
 
-static struct ctl_table user_event_sysctls[] = {
+static const struct ctl_table user_event_sysctls[] = {
 	{
 		.procname	= "user_events_max",
 		.data		= &max_user_events,
diff --git a/kernel/umh.c b/kernel/umh.c
index be9234270777..b4da45a3a7cf 100644
--- a/kernel/umh.c
+++ b/kernel/umh.c
@@ -544,7 +544,7 @@ static int proc_cap_handler(const struct ctl_table *table, int write,
 	return 0;
 }
 
-static struct ctl_table usermodehelper_table[] = {
+static const struct ctl_table usermodehelper_table[] = {
 	{
 		.procname	= "bset",
 		.data		= &usermodehelper_bset,
diff --git a/kernel/utsname_sysctl.c b/kernel/utsname_sysctl.c
index 7282f61a8650..bfbaaecb1dd4 100644
--- a/kernel/utsname_sysctl.c
+++ b/kernel/utsname_sysctl.c
@@ -75,7 +75,7 @@ static DEFINE_CTL_TABLE_POLL(hostname_poll);
 static DEFINE_CTL_TABLE_POLL(domainname_poll);
 
 // Note: update 'enum uts_proc' to match any changes to this table
-static struct ctl_table uts_kern_table[] = {
+static const struct ctl_table uts_kern_table[] = {
 	{
 		.procname	= "arch",
 		.data		= init_uts_ns.name.machine,
@@ -129,7 +129,7 @@ static struct ctl_table uts_kern_table[] = {
  */
 void uts_proc_notify(enum uts_proc proc)
 {
-	struct ctl_table *table = &uts_kern_table[proc];
+	const struct ctl_table *table = &uts_kern_table[proc];
 
 	proc_sys_poll_notify(table->poll);
 }
diff --git a/kernel/watchdog.c b/kernel/watchdog.c
index 41e0f7e9fa35..613e73ef367c 100644
--- a/kernel/watchdog.c
+++ b/kernel/watchdog.c
@@ -1094,7 +1094,7 @@ static int proc_watchdog_cpumask(const struct ctl_table *table, int write,
 
 static const int sixty = 60;
 
-static struct ctl_table watchdog_sysctls[] = {
+static const struct ctl_table watchdog_sysctls[] = {
 	{
 		.procname       = "watchdog",
 		.data		= &watchdog_user_enabled,
diff --git a/lib/test_sysctl.c b/lib/test_sysctl.c
index b6696fa1d426..4249e0cc8aaf 100644
--- a/lib/test_sysctl.c
+++ b/lib/test_sysctl.c
@@ -71,7 +71,7 @@ static struct test_sysctl_data test_data = {
 };
 
 /* These are all under /proc/sys/debug/test_sysctl/ */
-static struct ctl_table test_table[] = {
+static const struct ctl_table test_table[] = {
 	{
 		.procname	= "int_0001",
 		.data		= &test_data.int_0001,
@@ -177,7 +177,7 @@ static int test_sysctl_setup_node_tests(void)
 }
 
 /* Used to test that unregister actually removes the directory */
-static struct ctl_table test_table_unregister[] = {
+static const struct ctl_table test_table_unregister[] = {
 	{
 		.procname	= "unregister_error",
 		.data		= &test_data.int_0001,
@@ -220,7 +220,7 @@ static int test_sysctl_run_register_mount_point(void)
 	return 0;
 }
 
-static struct ctl_table test_table_empty[] = { };
+static const struct ctl_table test_table_empty[] = { };
 
 static int test_sysctl_run_register_empty(void)
 {
diff --git a/mm/compaction.c b/mm/compaction.c
index a2b16b08cbbf..62e8ee230e1c 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -3297,7 +3297,7 @@ static int proc_dointvec_minmax_warn_RT_change(const struct ctl_table *table,
 	return ret;
 }
 
-static struct ctl_table vm_compaction[] = {
+static const struct ctl_table vm_compaction[] = {
 	{
 		.procname	= "compact_memory",
 		.data		= &sysctl_compact_memory,
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index c498874a7170..3857b9d72c84 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -4845,7 +4845,7 @@ static int hugetlb_overcommit_handler(const struct ctl_table *table, int write,
 	return ret;
 }
 
-static struct ctl_table hugetlb_table[] = {
+static const struct ctl_table hugetlb_table[] = {
 	{
 		.procname	= "nr_hugepages",
 		.data		= NULL,
diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c
index 57b7f591eee8..7735972add01 100644
--- a/mm/hugetlb_vmemmap.c
+++ b/mm/hugetlb_vmemmap.c
@@ -693,7 +693,7 @@ void hugetlb_vmemmap_optimize_folios(struct hstate *h, struct list_head *folio_l
 	free_vmemmap_page_list(&vmemmap_pages);
 }
 
-static struct ctl_table hugetlb_vmemmap_sysctls[] = {
+static const struct ctl_table hugetlb_vmemmap_sysctls[] = {
 	{
 		.procname	= "hugetlb_optimize_vmemmap",
 		.data		= &vmemmap_optimize_enabled,
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index a7b8ccd29b6f..995a15eb67e2 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -124,7 +124,7 @@ const struct attribute_group memory_failure_attr_group = {
 	.attrs = memory_failure_attr,
 };
 
-static struct ctl_table memory_failure_table[] = {
+static const struct ctl_table memory_failure_table[] = {
 	{
 		.procname	= "memory_failure_early_kill",
 		.data		= &sysctl_memory_failure_early_kill,
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 1c485beb0b93..c8280a39119c 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -699,7 +699,7 @@ static void queue_oom_reaper(struct task_struct *tsk)
 }
 
 #ifdef CONFIG_SYSCTL
-static struct ctl_table vm_oom_kill_table[] = {
+static const struct ctl_table vm_oom_kill_table[] = {
 	{
 		.procname	= "panic_on_oom",
 		.data		= &sysctl_panic_on_oom,
diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index d213ead95675..fb523107701f 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -2313,7 +2313,7 @@ static int page_writeback_cpu_online(unsigned int cpu)
 /* this is needed for the proc_doulongvec_minmax of vm_dirty_bytes */
 static const unsigned long dirty_bytes_min = 2 * PAGE_SIZE;
 
-static struct ctl_table vm_page_writeback_sysctls[] = {
+static const struct ctl_table vm_page_writeback_sysctls[] = {
 	{
 		.procname   = "dirty_background_ratio",
 		.data       = &dirty_background_ratio,
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index cae7b93864c2..6224a2ab5e86 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6172,7 +6172,7 @@ static int percpu_pagelist_high_fraction_sysctl_handler(const struct ctl_table *
 	return ret;
 }
 
-static struct ctl_table page_alloc_sysctl_table[] = {
+static const struct ctl_table page_alloc_sysctl_table[] = {
 	{
 		.procname	= "min_free_kbytes",
 		.data		= &min_free_kbytes,
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index 1edc12862a7d..9b6c2f157f83 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -2038,7 +2038,7 @@ static int apparmor_dointvec(const struct ctl_table *table, int write,
 	return proc_dointvec(table, write, buffer, lenp, ppos);
 }
 
-static struct ctl_table apparmor_sysctl_table[] = {
+static const struct ctl_table apparmor_sysctl_table[] = {
 #ifdef CONFIG_USER_NS
 	{
 		.procname       = "unprivileged_userns_apparmor_policy",
diff --git a/security/keys/sysctl.c b/security/keys/sysctl.c
index 91f000eef3ad..cde08c478f32 100644
--- a/security/keys/sysctl.c
+++ b/security/keys/sysctl.c
@@ -9,7 +9,7 @@
 #include <linux/sysctl.h>
 #include "internal.h"
 
-static struct ctl_table key_sysctls[] = {
+static const struct ctl_table key_sysctls[] = {
 	{
 		.procname = "maxkeys",
 		.data = &key_quota_maxkeys,
diff --git a/security/yama/yama_lsm.c b/security/yama/yama_lsm.c
index e1a5e13ea269..54bd5f535ac1 100644
--- a/security/yama/yama_lsm.c
+++ b/security/yama/yama_lsm.c
@@ -454,7 +454,7 @@ static int yama_dointvec_minmax(const struct ctl_table *table, int write,
 
 static int max_scope = YAMA_SCOPE_NO_ATTACH;
 
-static struct ctl_table yama_sysctl_table[] = {
+static const struct ctl_table yama_sysctl_table[] = {
 	{
 		.procname       = "ptrace_scope",
 		.data           = &ptrace_scope,

---
base-commit: 9d89551994a430b50c4fffcb1e617a057fa76e20
change-id: 20250109-jag-ctl_table_const-38f6b2ccbba7

Best regards,
-- 
Joel Granados <joel.granados@kernel.org>




From xen-devel-bounces@lists.xenproject.org Fri Jan 10 14:28:46 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 14:28:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869712.1281162 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWG09-0008C1-Av; Fri, 10 Jan 2025 14:28:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869712.1281162; Fri, 10 Jan 2025 14:28:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWG09-0008Bu-82; Fri, 10 Jan 2025 14:28:41 +0000
Received: by outflank-mailman (input) for mailman id 869712;
 Fri, 10 Jan 2025 14:28:39 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=yeU6=UC=linuxfoundation.org=gregkh@srs-se1.protection.inumbo.net>)
 id 1tWG07-0008Bo-9r
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 14:28:39 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2d5ab315-cf5f-11ef-99a4-01e77a169b0f;
 Fri, 10 Jan 2025 15:28:37 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 618085C4B4F;
 Fri, 10 Jan 2025 14:27:54 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id A8B86C4CED6;
 Fri, 10 Jan 2025 14:28:33 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2d5ab315-cf5f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org;
	s=korg; t=1736519315;
	bh=3pBOH7d9tl4Ey6CeHCMF5/wGwbp+k8zOM+QYd5Ry+Vk=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=FN/vx8wlpkwlPM2m3b6cbT2/bOBjkS0UtUXsDQYDOM9MJGdnRhUu6ntgWuEP+hb6I
	 DqTbI13RfuE9Imou7PtxAwDxdfBclNY5CaSyu/d5nGzOInNQaoHv/qn8qsj9L8DXW5
	 YuWIAN2tAS6j1wdzWTSJRniH5DkbkcVfKiOfzSIs=
Date: Fri, 10 Jan 2025 15:28:31 +0100
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Philipp Stanner <pstanner@redhat.com>
Cc: amien Le Moal <dlemoal@kernel.org>, Niklas Cassel <cassel@kernel.org>,
	Basavaraj Natikar <basavaraj.natikar@amd.com>,
	Jiri Kosina <jikos@kernel.org>,
	Benjamin Tissoires <bentiss@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>, Alex Dubov <oakad@yahoo.com>,
	Sudarsana Kalluru <skalluru@marvell.com>,
	Manish Chopra <manishc@marvell.com>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Rasesh Mody <rmody@marvell.com>, GR-Linux-NIC-Dev@marvell.com,
	Igor Mitsyanko <imitsyanko@quantenna.com>,
	Sergey Matyukevich <geomatsi@gmail.com>,
	Kalle Valo <kvalo@kernel.org>, Sanjay R Mehta <sanju.mehta@amd.com>,
	Shyam Sundar S K <Shyam-sundar.S-k@amd.com>,
	Jon Mason <jdmason@kudzu.us>, Dave Jiang <dave.jiang@intel.com>,
	Allen Hubbe <allenbh@gmail.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Juergen Gross <jgross@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
	Mario Limonciello <mario.limonciello@amd.com>,
	Chen Ni <nichen@iscas.ac.cn>, Ricky Wu <ricky_wu@realtek.com>,
	Al Viro <viro@zeniv.linux.org.uk>, Breno Leitao <leitao@debian.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Kevin Tian <kevin.tian@intel.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Mostafa Saleh <smostafa@google.com>, Jason Gunthorpe <jgg@ziepe.ca>,
	Yi Liu <yi.l.liu@intel.com>, Kunwu Chan <chentao@kylinos.cn>,
	Dan Carpenter <dan.carpenter@linaro.org>,
	"Dr. David Alan Gilbert" <linux@treblig.org>,
	Ankit Agrawal <ankita@nvidia.com>,
	Reinette Chatre <reinette.chatre@intel.com>,
	Eric Auger <eric.auger@redhat.com>, Ye Bin <yebin10@huawei.com>,
	linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-input@vger.kernel.org, netdev@vger.kernel.org,
	linux-wireless@vger.kernel.org, ntb@lists.linux.dev,
	linux-pci@vger.kernel.org, kvm@vger.kernel.org,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 05/11] misc: Use never-managed version of pci_intx()
Message-ID: <2025011022-garnet-matriarch-e6a0@gregkh>
References: <20241209130632.132074-2-pstanner@redhat.com>
 <20241209130632.132074-7-pstanner@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20241209130632.132074-7-pstanner@redhat.com>

On Mon, Dec 09, 2024 at 02:06:27PM +0100, Philipp Stanner wrote:
> pci_intx() is a hybrid function which can sometimes be managed through
> devres. To remove this hybrid nature from pci_intx(), it is necessary to
> port users to either an always-managed or a never-managed version.
> 
> cardreader/rtsx_pcr.c and tifm_7xx1.c enable their PCI-Device with
> pci_enable_device(). Thus, they need the never-managed version.
> 
> Replace pci_intx() with pci_intx_unmanaged().
> 
> Signed-off-by: Philipp Stanner <pstanner@redhat.com>
> ---
>  drivers/misc/cardreader/rtsx_pcr.c | 2 +-
>  drivers/misc/tifm_7xx1.c           | 6 +++---
>  2 files changed, 4 insertions(+), 4 deletions(-)

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 14:29:07 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 14:29:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869716.1281173 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWG0Z-0000F1-IO; Fri, 10 Jan 2025 14:29:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869716.1281173; Fri, 10 Jan 2025 14:29:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWG0Z-0000Eu-FR; Fri, 10 Jan 2025 14:29:07 +0000
Received: by outflank-mailman (input) for mailman id 869716;
 Fri, 10 Jan 2025 14:29: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
 <SRS0=J0bo=UC=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tWG0Y-0008To-26
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 14:29:06 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3eb1ce8a-cf5f-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 15:29:05 +0100 (CET)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-aafc9d75f8bso415083166b.2
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 06:29:05 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d99083fbd7sm1703370a12.73.2025.01.10.06.29.03
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 10 Jan 2025 06:29:04 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 3eb1ce8a-cf5f-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736519345; x=1737124145; 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=t7GH8zDE64afytORyeioFULV1nHRsT7BDsc4aRA2bpQ=;
        b=Hfeo1ER0Q0J+03j/QqR2CSv8QpUafSppoUaxErZePEWVZJwIu3rUorefs/OgR5VzRd
         nh2+Y9KiDqGDN6lJdE2zZ+CIAsmbUhokfowfUzO+Gr/I1fJaejOPm6HVwr8QglnvDLec
         XsQA4xHSKu9x5gqVrpYGNepWcEpSNxwV9ubi0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736519345; x=1737124145;
        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=t7GH8zDE64afytORyeioFULV1nHRsT7BDsc4aRA2bpQ=;
        b=iBhKDZsiCFKPkfnctn1bDHC/txWiDMis7m+4Sq43nE8UByPfOvg8wUx0kVe4+mxVdK
         D3BJ1CHd7g1odfoqfvtuu15G6PIzgVRFpPSB4KD9x4nWeo8t4/M6UP6+Jm5wmFlot9nV
         gPuHQE2ugH1cthV2o9LmslLCD+qsfUhWZ+VMehPuZjxmYsQWoKr45TQDumN6FrDCEiaP
         AMo6BFfK9A7Z7ZCy+rMenwTa19iaqMSbP8JoZy3mSyuuQSIbqoJjdlyJsWFmg0/0hrwl
         /bMFCTDbgDiRQwSpOP8XXcGzZrJDB345jNyN2wvcqbMTW0hGUc6jcgejiyclNtPShVVE
         kCkA==
X-Gm-Message-State: AOJu0Yz9vAlzGOrGgNtJ84tZgqFnMLATG5hLWMzhbZOjSHv4KPC7d6Rh
	Ju7FsEFY8lC2svKUbEjWaZc4hevbpsQvYTGxw4JqB3UMuZCYm5avDoCgSD55RpU=
X-Gm-Gg: ASbGncsNSeWozMemnRvHjfhC91bEOLAxwDiVLxOeKRr4SDi4IMHWeQTP0t2dwjVKtB/
	Y/uYI6jqhZ63XZGD9w+u5kVnFBA09luFvMoDXyufaLXtTqmkoHvF1k2lpYh7CXJ5ek1j/f8XYsU
	dA30EaCjgHgoaopTbcgc7qdSZc8xmDZSytIBaj9d/Q7FK1J5tCI0TbwP1V1nBkn103lrn5vqUty
	n+Sf2GMviYOsSpeFyAnXm0QaW0RZpphv11o85mWJJjEEXX1qXL4XYel8Tm4fZs4K9A=
X-Google-Smtp-Source: AGHT+IH8z3nw7Uw5PniYGS+wJaEBWc6x1PYAbUzaopy8H3g0c0ZLhU3ZvlIgd5l7gCyQ+3t5zBtYwg==
X-Received: by 2002:a17:907:7fa7:b0:aa6:423c:8514 with SMTP id a640c23a62f3a-ab2abc94ef2mr878732366b.40.1736519344666;
        Fri, 10 Jan 2025 06:29:04 -0800 (PST)
Date: Fri, 10 Jan 2025 15:29:03 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Alejandro Vallejo <alejandro.vallejo@cloud.com>
Cc: xen-devel@lists.xenproject.org, Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v2 04/18] x86/pv: introduce function to populate
 perdomain area and use it to map Xen GDT
Message-ID: <Z4Eur-PNej2JQAm_@macbook.local>
References: <20250108142659.99490-1-roger.pau@citrix.com>
 <20250108142659.99490-5-roger.pau@citrix.com>
 <D6XGAK96L261.324ZJ1U3UO8LF@cloud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <D6XGAK96L261.324ZJ1U3UO8LF@cloud.com>

On Thu, Jan 09, 2025 at 09:55:44AM +0000, Alejandro Vallejo wrote:
> On Wed Jan 8, 2025 at 2:26 PM GMT, Roger Pau Monne wrote:
> > The current code to update the Xen part of the GDT when running a PV guest
> > relies on caching the direct map address of all the L1 tables used to map the
> > GDT and LDT, so that entries can be modified.
> >
> > Introduce a new function that populates the per-domain region, either using the
> > recursive linear mappings when the target vCPU is the current one, or by
> > directly modifying the L1 table of the per-domain region.
> >
> > Using such function to populate per-domain addresses drops the need to keep a
> > reference to per-domain L1 tables previously used to change the per-domain
> > mappings.
> >
> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> > ---
> >  xen/arch/x86/domain.c                | 11 +++-
> >  xen/arch/x86/include/asm/desc.h      |  6 +-
> >  xen/arch/x86/include/asm/mm.h        |  2 +
> >  xen/arch/x86/include/asm/processor.h |  5 ++
> >  xen/arch/x86/mm.c                    | 88 ++++++++++++++++++++++++++++
> >  xen/arch/x86/smpboot.c               |  6 +-
> >  xen/arch/x86/traps.c                 | 10 ++--
> >  7 files changed, 113 insertions(+), 15 deletions(-)
> >
> > diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> > index 1f680bf176ee..0bd0ef7e40f4 100644
> > --- a/xen/arch/x86/domain.c
> > +++ b/xen/arch/x86/domain.c
> > @@ -1953,9 +1953,14 @@ static always_inline bool need_full_gdt(const struct domain *d)
> >  
> >  static void update_xen_slot_in_full_gdt(const struct vcpu *v, unsigned int cpu)
> >  {
> > -    l1e_write(pv_gdt_ptes(v) + FIRST_RESERVED_GDT_PAGE,
> > -              !is_pv_32bit_vcpu(v) ? per_cpu(gdt_l1e, cpu)
> > -                                   : per_cpu(compat_gdt_l1e, cpu));
> > +    ASSERT(v != current);
> 
> For this assert, and others below. IIUC, curr_vcpu == current when we're
> properly switched. When we're idling current == idle and curr_vcpu == prev_ctx.
> 
> Granted, calling this in the middle of a lazy idle loop would be weird, but
> would it make sense for PT consistency to use curr_vcpu here...

Hm, this function is called in a very specific context, and the assert
intends to reflect that.  TBH I could just drop it, as
populate_perdomain_mapping() will DTRT also when v == current. The
expectation for the context is also that current == curr_vcpu.

Note however that if v == current we would need a flush after the
populate_perdomain_mapping() call, since populate_perdomain_mapping()
doesn't perform any flushing of the modified entries.  The main
purpose of the ASSERT() is to notice this.

> > +
> > +    populate_perdomain_mapping(v,
> > +                               GDT_VIRT_START(v) +
> > +                               (FIRST_RESERVED_GDT_PAGE << PAGE_SHIFT),
> > +                               !is_pv_32bit_vcpu(v) ? &per_cpu(gdt_mfn, cpu)
> > +                                                    : &per_cpu(compat_gdt_mfn,
> > +                                                               cpu), 1);
> >  }
> >  
> >  static void load_full_gdt(const struct vcpu *v, unsigned int cpu)
> > diff --git a/xen/arch/x86/include/asm/desc.h b/xen/arch/x86/include/asm/desc.h
> > index a1e0807d97ed..33981bfca588 100644
> > --- a/xen/arch/x86/include/asm/desc.h
> > +++ b/xen/arch/x86/include/asm/desc.h
> > @@ -44,6 +44,8 @@
> >  
> >  #ifndef __ASSEMBLY__
> >  
> > +#include <xen/mm-frame.h>
> > +
> >  #define GUEST_KERNEL_RPL(d) (is_pv_32bit_domain(d) ? 1 : 3)
> >  
> >  /* Fix up the RPL of a guest segment selector. */
> > @@ -212,10 +214,10 @@ struct __packed desc_ptr {
> >  
> >  extern seg_desc_t boot_gdt[];
> >  DECLARE_PER_CPU(seg_desc_t *, gdt);
> > -DECLARE_PER_CPU(l1_pgentry_t, gdt_l1e);
> > +DECLARE_PER_CPU(mfn_t, gdt_mfn);
> >  extern seg_desc_t boot_compat_gdt[];
> >  DECLARE_PER_CPU(seg_desc_t *, compat_gdt);
> > -DECLARE_PER_CPU(l1_pgentry_t, compat_gdt_l1e);
> > +DECLARE_PER_CPU(mfn_t, compat_gdt_mfn);
> >  DECLARE_PER_CPU(bool, full_gdt_loaded);
> >  
> >  static inline void lgdt(const struct desc_ptr *gdtr)
> > diff --git a/xen/arch/x86/include/asm/mm.h b/xen/arch/x86/include/asm/mm.h
> > index 6c7e66ee21ab..b50a51327b2b 100644
> > --- a/xen/arch/x86/include/asm/mm.h
> > +++ b/xen/arch/x86/include/asm/mm.h
> > @@ -603,6 +603,8 @@ int compat_arch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg);
> >  int create_perdomain_mapping(struct domain *d, unsigned long va,
> >                               unsigned int nr, l1_pgentry_t **pl1tab,
> >                               struct page_info **ppg);
> > +void populate_perdomain_mapping(const struct vcpu *v, unsigned long va,
> > +                                mfn_t *mfn, unsigned long nr);
> >  void destroy_perdomain_mapping(struct domain *d, unsigned long va,
> >                                 unsigned int nr);
> >  void free_perdomain_mappings(struct domain *d);
> > diff --git a/xen/arch/x86/include/asm/processor.h b/xen/arch/x86/include/asm/processor.h
> > index d247ef8dd226..82ee89f736c2 100644
> > --- a/xen/arch/x86/include/asm/processor.h
> > +++ b/xen/arch/x86/include/asm/processor.h
> > @@ -243,6 +243,11 @@ static inline unsigned long cr3_pa(unsigned long cr3)
> >      return cr3 & X86_CR3_ADDR_MASK;
> >  }
> >  
> > +static inline mfn_t cr3_mfn(unsigned long cr3)
> > +{
> > +    return maddr_to_mfn(cr3_pa(cr3));
> > +}
> > +
> >  static inline unsigned int cr3_pcid(unsigned long cr3)
> >  {
> >      return IS_ENABLED(CONFIG_PV) ? cr3 & X86_CR3_PCID_MASK : 0;
> > diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> > index 3d5dd22b6c36..0abea792486c 100644
> > --- a/xen/arch/x86/mm.c
> > +++ b/xen/arch/x86/mm.c
> > @@ -6423,6 +6423,94 @@ int create_perdomain_mapping(struct domain *d, unsigned long va,
> >      return rc;
> >  }
> >  
> > +void populate_perdomain_mapping(const struct vcpu *v, unsigned long va,
> > +                                mfn_t *mfn, unsigned long nr)
> > +{
> > +    l1_pgentry_t *l1tab = NULL, *pl1e;
> > +    const l3_pgentry_t *l3tab;
> > +    const l2_pgentry_t *l2tab;
> > +    struct domain *d = v->domain;
> > +
> > +    ASSERT(va >= PERDOMAIN_VIRT_START &&
> > +           va < PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS));
> > +    ASSERT(!nr || !l3_table_offset(va ^ (va + nr * PAGE_SIZE - 1)));
> > +
> > +    /* Use likely to force the optimization for the fast path. */
> > +    if ( likely(v == current) )
> 
> ... and here? In particular I'd expect using curr_vcpu here means...

I'm afraid not, this is a trap I've fallen originally when doing this
series, as I indeed had v == curr_vcpu here (and no
sync_local_execstate() call).

However as a result of an interrupt, a call to sync_local_execstate()
might happen, at which point the previous check of v == curr_vcpu
becomes stale.

> > +    {
> > +        unsigned int i;
> > +
> > +        /* Ensure page-tables are from current (if current != curr_vcpu). */
> > +        sync_local_execstate();
> 
> ... this should not be needed.

As kind of mentioned above, this is required to ensure the page-tables
are in-sync with the vCPU in current, and cannot change as a result of
an interrupt triggering a call to sync_local_execstate().

Otherwise the page-tables could change while or after the call to
populate_perdomain_mapping(), and the mappings could end up being
created on the wrong page-tables.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 14:30:39 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 14:30:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869727.1281183 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWG22-0001na-SN; Fri, 10 Jan 2025 14:30:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869727.1281183; Fri, 10 Jan 2025 14:30:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWG22-0001nT-Ox; Fri, 10 Jan 2025 14:30:38 +0000
Received: by outflank-mailman (input) for mailman id 869727;
 Fri, 10 Jan 2025 14:30: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
 <SRS0=J0bo=UC=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tWG21-0001nG-24
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 14:30:37 +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 74cfb70b-cf5f-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 15:30:36 +0100 (CET)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-5d3d0205bd5so3042942a12.3
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 06:30:36 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d9904a55f9sm1646074a12.81.2025.01.10.06.30.33
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 10 Jan 2025 06:30:34 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 74cfb70b-cf5f-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736519435; x=1737124235; 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=B8DTASg4jbJWXanhAOi8KUszSGgZ/02wo2hT/AYrVuw=;
        b=LUwJ7nhD42U0c5ljsKXMz6i8AU3nqceq2kzAXsBignvcgeIdvtDYiogy0iHrLHYa6W
         3+Nf+LSgsma6sDa477udqIH/Ef240Dvi40OfKEJIYlnnsxP3IzmvgxFYIAqc44hR3zdE
         k+/Ma+CYEggDqgeuP19jhaaVpxgJt/gg2RhhU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736519435; x=1737124235;
        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=B8DTASg4jbJWXanhAOi8KUszSGgZ/02wo2hT/AYrVuw=;
        b=dCJIhZnLIoZJlUoedgQpwgN15E37Qtxq9EJSVg145tNEzDY81apcFyJU2gufFMhPwA
         KPuu3qO1sGK4jvd+CuT1CUC/j9FaVOdPrEY5hzMb7GT6Vt6pBE/9jjKsYAdqMZGmbUPd
         Jplao8naHSwK/V4sUfF/Offo2Sk/gkywXGtIxeK+CnfdISZJQgADTw0fGStPPgWIAcC0
         p8g7Z9jemNeDAtTpsWk/uwDsINLUoIjoncdOc8pwyXCbASVOIZuQ8ZG96Kik0JBA1R0d
         6K5wnNX5OGzX7pKbNOlUuLI+iaWWM8i0yEMcTffY/eWqWYH+1SuEKkRVXro2YdZOeVIa
         uu6g==
X-Gm-Message-State: AOJu0YxjqxRCzjCyZez6f1WLEVvtbFoYnqW0L2qZ/w9L/mgO18EdfrN7
	eBpGwxyEn/zfsM/XttYf4mgNOZQUTdsNj8LC1xoRPDFCz2G6gCaWryTWpdoD3AY=
X-Gm-Gg: ASbGncuHI5kZ7Tl8JJpwycNqjBNzeDaOuNjYL90uAUB5IhMGZsZxqAsWiTkYp2qYOj7
	TyBRinySyKCBiefp9NH6Q2cA43cMkBke83KGXbPQ5e+ooOqSvjUqZR5MSzyBN3zyxLFWVShxyHd
	U82vpUEfUFQyXybxp66f8DgKuf/fVRfRhMTtWr+JZcVxSBCB5gMjT5//QHGw6znzWBnCmRe4xxM
	sdIRnko0XKigyAVkatIRp3KmAzpLltmPN3LGXVYtNJTwNiyQuRXfCA3Df2NV78zV/A=
X-Google-Smtp-Source: AGHT+IFhQIIy8/LplsGWKcUHIByTMMO22PwTyKoru9A5hZ/izwK5NhnHr//u6mqed5sZBK+tG6AtDw==
X-Received: by 2002:a05:6402:400a:b0:5d4:4143:c082 with SMTP id 4fb4d7f45d1cf-5d972e4e726mr8114422a12.21.1736519435474;
        Fri, 10 Jan 2025 06:30:35 -0800 (PST)
Date: Fri, 10 Jan 2025 15:30:32 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Alejandro Vallejo <alejandro.vallejo@cloud.com>
Cc: xen-devel@lists.xenproject.org, Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v2 05/18] x86/mm: switch destroy_perdomain_mapping()
 parameter from domain to vCPU
Message-ID: <Z4EvCHlGo-svVgHe@macbook.local>
References: <20250108142659.99490-1-roger.pau@citrix.com>
 <20250108142659.99490-6-roger.pau@citrix.com>
 <D6XGFLRRLY4N.3IFSIDMFC4BVJ@cloud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <D6XGFLRRLY4N.3IFSIDMFC4BVJ@cloud.com>

On Thu, Jan 09, 2025 at 10:02:19AM +0000, Alejandro Vallejo wrote:
> On Wed Jan 8, 2025 at 2:26 PM GMT, Roger Pau Monne wrote:
> > In preparation for the per-domain area being populated with per-vCPU mappings
> > change the parameter of destroy_perdomain_mapping() to be a vCPU instead of a
> > domain, and also update the function logic to allow manipulation of per-domain
> > mappings using the linear page table mappings.
> >
> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> > ---
> >  xen/arch/x86/include/asm/mm.h |  2 +-
> >  xen/arch/x86/mm.c             | 24 +++++++++++++++++++++++-
> >  xen/arch/x86/pv/domain.c      |  3 +--
> >  xen/arch/x86/x86_64/mm.c      |  2 +-
> >  4 files changed, 26 insertions(+), 5 deletions(-)
> >
> > diff --git a/xen/arch/x86/include/asm/mm.h b/xen/arch/x86/include/asm/mm.h
> > index b50a51327b2b..65cd751087dc 100644
> > --- a/xen/arch/x86/include/asm/mm.h
> > +++ b/xen/arch/x86/include/asm/mm.h
> > @@ -605,7 +605,7 @@ int create_perdomain_mapping(struct domain *d, unsigned long va,
> >                               struct page_info **ppg);
> >  void populate_perdomain_mapping(const struct vcpu *v, unsigned long va,
> >                                  mfn_t *mfn, unsigned long nr);
> > -void destroy_perdomain_mapping(struct domain *d, unsigned long va,
> > +void destroy_perdomain_mapping(const struct vcpu *v, unsigned long va,
> >                                 unsigned int nr);
> >  void free_perdomain_mappings(struct domain *d);
> >  
> > diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> > index 0abea792486c..713ae8dd6fa3 100644
> > --- a/xen/arch/x86/mm.c
> > +++ b/xen/arch/x86/mm.c
> > @@ -6511,10 +6511,11 @@ void populate_perdomain_mapping(const struct vcpu *v, unsigned long va,
> >      unmap_domain_page(l3tab);
> >  }
> >  
> > -void destroy_perdomain_mapping(struct domain *d, unsigned long va,
> > +void destroy_perdomain_mapping(const struct vcpu *v, unsigned long va,
> >                                 unsigned int nr)
> >  {
> >      const l3_pgentry_t *l3tab, *pl3e;
> > +    const struct domain *d = v->domain;
> >  
> >      ASSERT(va >= PERDOMAIN_VIRT_START &&
> >             va < PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS));
> > @@ -6523,6 +6524,27 @@ void destroy_perdomain_mapping(struct domain *d, unsigned long va,
> >      if ( !d->arch.perdomain_l3_pg )
> >          return;
> >  
> > +    /* Use likely to force the optimization for the fast path. */
> > +    if ( likely(v == current) )
> 
> As in the previous patch, doesn't using curr_vcpu here...
> 
> > +    {
> > +        l1_pgentry_t *pl1e;
> > +
> > +        /* Ensure page-tables are from current (if current != curr_vcpu). */
> > +        sync_local_execstate();
> 
> ... avoid the need for this?

See previous reply and the hazards of curr_vcpu changing as a result
of an interrupt triggering a sync_local_execstate() call.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 14:33:14 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 14:33:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869735.1281192 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWG4X-0002iZ-6k; Fri, 10 Jan 2025 14:33:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869735.1281192; Fri, 10 Jan 2025 14:33:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWG4X-0002iS-4G; Fri, 10 Jan 2025 14:33:13 +0000
Received: by outflank-mailman (input) for mailman id 869735;
 Fri, 10 Jan 2025 14:33:12 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=J0bo=UC=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tWG4W-0002hC-P8
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 14:33:12 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d18dfb01-cf5f-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 15:33:11 +0100 (CET)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-aa67ac42819so309878866b.0
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 06:33:11 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c963d420sm169983366b.167.2025.01.10.06.33.10
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 10 Jan 2025 06:33:10 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: d18dfb01-cf5f-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736519591; x=1737124391; 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=k9rn8CVGsxA2rBOmcskWsCpwJ6ED/zH2v5Bnl7e194M=;
        b=WLhNQ+FYIgCtdBF51t68isjgiaK+JSspbz3KBhr08smcSMfU08l+QtIcMwwMc5Ou2T
         G1iyARpH9EBvcynv3bonMVs02QjRBzCaVTR8oBWcqq62cC4TbA74Ll3gZ8pxyRfLV+fm
         vjnwZO1XfaearapZjZXJtQvruWt2uGV8If404=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736519591; x=1737124391;
        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=k9rn8CVGsxA2rBOmcskWsCpwJ6ED/zH2v5Bnl7e194M=;
        b=hDv9dI/JXVaL2Q0SlWjljlZ78nN8glkRYrvpNv2OfIcY9eGKZs5ldgPefRfVxhDfGn
         jR+3/z2IleGyTIh2kJEfNx6/oeVjGXi+5VMWwLUZtJVmI2oYpU0Rh5VPD0aYUisnb7r6
         mc+CAVcykWykTUfuKyp8zLYtKZORKZCH2TN4UX5P01RRglh13y3149Og5px44uv+1xiU
         BpZzLTjYNjSWW9aTxj3mNxDBr1/wAwoZCFqkSm4AHZOs6uAMLlfiXfIxibmstFSmTCyh
         0R2e3ybj7yzalE6dDql4mSWd/j74SyZ3W9Fho4HPa1IV69ZgNkgboINCJZPTM45/LEaT
         Kq7A==
X-Gm-Message-State: AOJu0YxpJ4AJS1LifN5ogR25iELWHLLOXaMZ/oDdtFRtGmYE7tSgQyYp
	5ClxK9QdtjxZ7mPqKekPEPj1juCBgNJFsLIrRcgdIJTZ/zRYq1gJ6SDT15rNDU8=
X-Gm-Gg: ASbGncsJ8GuiAoQNjP+BY63Oer+FYYCt4qVa+cLcd7Nhh6EjiNEx7DDCBGPlWpFlP+S
	wANpNfb23/9sVPoLmfHWr9BqPgaNgI24as6WXCueJmn9MMPzYY+bCCq2hdWqvLVY8lxQ8fETu3F
	8Yd0ZEL7M31L7j6qUqPR6uomGarjRd4foC+nMaXCEkTrnAD7oSwUa5pkrvivhCc73qPfUF8vmEG
	sSx5iN53jFfc+ZnHCh+WjbiHgCNYN6Ko+9KU+Vc5W4asG0G6iEYLeOzIow/0oa5gPI=
X-Google-Smtp-Source: AGHT+IGW2oi1c7mDJHqFs9oR9kjZVN69KH2hxm2KTrcdGl4An90nQCuP9Z6q5rLeUCkCKTBbo3Wzag==
X-Received: by 2002:a17:907:3d9f:b0:aae:ef24:888d with SMTP id a640c23a62f3a-ab2abc92349mr1000031566b.55.1736519591103;
        Fri, 10 Jan 2025 06:33:11 -0800 (PST)
Date: Fri, 10 Jan 2025 15:33:09 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Alejandro Vallejo <alejandro.vallejo@cloud.com>
Cc: xen-devel@lists.xenproject.org, Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v2.1 06/18] x86/pv: set/clear guest GDT mappings using
 {populate,destroy}_perdomain_mapping()
Message-ID: <Z4EvpVHOy9jyGy9M@macbook.local>
References: <20250108142659.99490-7-roger.pau@citrix.com>
 <20250108151133.858-1-roger.pau@citrix.com>
 <D6XGXLZ2SKUR.3CW1GPXWK3LFC@cloud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <D6XGXLZ2SKUR.3CW1GPXWK3LFC@cloud.com>

On Thu, Jan 09, 2025 at 10:25:50AM +0000, Alejandro Vallejo wrote:
> On Wed Jan 8, 2025 at 3:11 PM GMT, Roger Pau Monne wrote:
> > The pv_{set,destroy}_gdt() functions rely on the L1 table(s) that contain such
> > mappings being stashed in the domain structure, and thus such mappings being
> > modified by merely updating the L1 entries.
> >
> > Switch both pv_{set,destroy}_gdt() to instead use
> > {populate,destory}_perdomain_mapping().
> 
> nit: s/destory/destroy
> 
> How come pv_set_gdt() doesn't need to be reordered here (as opposed to v2)?

In a previous version (that I've never published)
populate_perdomain_mapping() was using v->arch.cr3 as the root pointer
in which to do a page-walk and modify the requested entries.  That
required v->arch.cr3 to be valid when populate_perdomain_mapping() was
called, and hence needed the reordering.

Since populate_perdomain_mapping() no longer uses v->arch.cr3 it
doesn't matter whether the vCPU c3 is valid when calling
populate_perdomain_mapping().

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 14:44:52 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 14:44:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869744.1281203 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWGFi-0005Nu-7i; Fri, 10 Jan 2025 14:44:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869744.1281203; Fri, 10 Jan 2025 14:44:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWGFi-0005Nn-52; Fri, 10 Jan 2025 14:44:46 +0000
Received: by outflank-mailman (input) for mailman id 869744;
 Fri, 10 Jan 2025 14:44: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
 <SRS0=J0bo=UC=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tWGFg-0005Nh-P2
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 14:44:44 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6d7d081b-cf61-11ef-99a4-01e77a169b0f;
 Fri, 10 Jan 2025 15:44:42 +0100 (CET)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-aa69107179cso420933866b.0
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 06:44:42 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c9562e9bsm174346966b.106.2025.01.10.06.44.41
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 10 Jan 2025 06:44:41 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 6d7d081b-cf61-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736520282; x=1737125082; 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=HItyJwYzwWv1aKF+MfvXpMBK2lb5hFQpOOyO9Mxzdag=;
        b=DCd9NN6TDcy2b7/nEPDMHMniPMvSa8PeG7u+CdGgSyiW3DfuR5mYNvv2WqT9Ln0Cof
         Ug/C6j0XW+Ajtm/d4hRUG2Qd4FJpNg79izfrysvnHtW8vxfjKQQjGmGJ7zMRTgggc0Jo
         qfJVuqc1v3k1UeanmKeNgmmovr3yWKNVjh/bA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736520282; x=1737125082;
        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=HItyJwYzwWv1aKF+MfvXpMBK2lb5hFQpOOyO9Mxzdag=;
        b=OnPWQohlkUg4i7HB/2Qb8wBvwizspXOq5M/GVQZE0zfPMwVdZ5ypOGUxjyC5HL13vP
         uzWw6xoB7j09Zxw2emgcKwSPZHa08j+r0kYBLGgEGXTjMlQJmw0NPK7GPcO1EHfHFxTN
         MTmtH+MOVwsCnStg9nevD0X9hx2GSb4PK+69+DxE75GInDLB9azVdnlIZKcDf7xHWZDg
         IxJJkfJd4chUnlSJHFD4S/nHKmxDU8rboX0X8Xv1GnAZpR0GBU6plP6r7lpy1OderhPm
         l8bTjZViknqHJD/S0u+lpo2ursm7fMAdoZKZLP5wpY/tZyQWsktBNFK+ildNIHf15cyS
         wAHw==
X-Gm-Message-State: AOJu0YzR+sJUy+UJFazANP5DhKo8rPVkqyKE0Ji4qOSJJkJbty4QvsYW
	QlSGfUTZ+c+XGp9UI2q0vPV4lN4fQJVZiijdyUKtxOZjnzTjlISzL5rYQH3nmBc=
X-Gm-Gg: ASbGnct3zdcgbGFb0QTOEd2sTgZw9BpfpmUH8URCC3MxumsXUESZBrKsbMgfQFVs2h4
	uvM/2ee/zQ6mp5i32jxpHA+CH3fyp7q+yXVug/gWPa1vFf45XOin/hSAE9i5gbmgvR3wMbX2Ygl
	2FMSIE51WCrwtTzGIh2yT9M3+qtaIr2prcbSrExemFOQXM92G2fQOy6+I9BsLljKAV2+l11HdS3
	rKJz5WCV1XZ5xM1Iuo6X5n5B3TXAorsw08fMxY5f0kn3K5/FbB8wfLoohUIQh8yd1U=
X-Google-Smtp-Source: AGHT+IGdsFUacA3FSvLpjIwIa+cW5xMcQBSRuUNUw0dRL0Ot/VyT65vyNLL/M8TbTV0TjHtmz3SBiA==
X-Received: by 2002:a17:907:c0c:b0:aae:8490:9429 with SMTP id a640c23a62f3a-ab2ab6fd4c3mr761680766b.34.1736520282275;
        Fri, 10 Jan 2025 06:44:42 -0800 (PST)
Date: Fri, 10 Jan 2025 15:44:40 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Alejandro Vallejo <alejandro.vallejo@cloud.com>
Cc: xen-devel@lists.xenproject.org, Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v2 07/18] x86/pv: update guest LDT mappings using the
 linear entries
Message-ID: <Z4EyWLde4lHH-2Sm@macbook.local>
References: <20250108142659.99490-1-roger.pau@citrix.com>
 <20250108142659.99490-8-roger.pau@citrix.com>
 <D6XM7OP0SQPB.3U12X09JAPKU3@cloud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <D6XM7OP0SQPB.3U12X09JAPKU3@cloud.com>

On Thu, Jan 09, 2025 at 02:34:05PM +0000, Alejandro Vallejo wrote:
> On Wed Jan 8, 2025 at 2:26 PM GMT, Roger Pau Monne wrote:
> > The pv_map_ldt_shadow_page() and pv_destroy_ldt() functions rely on the L1
> > table(s) that contain such mappings being stashed in the domain structure, and
> > thus such mappings being modified by merely updating the require L1 entries.
> >
> > Switch pv_map_ldt_shadow_page() to unconditionally use the linear recursive, as
> > that logic is always called while the vCPU is running on the current pCPU.
> >
> > For pv_destroy_ldt() use the linear mappings if the vCPU is the one currently
> > running on the pCPU, otherwise use destroy_mappings().
> >
> > Note this requires keeping an array with the pages currently mapped at the LDT
> > area, as that allows dropping the extra taken page reference when removing the
> > mappings.
> >
> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> > ---
> >  xen/arch/x86/include/asm/domain.h   |  2 ++
> >  xen/arch/x86/pv/descriptor-tables.c | 19 ++++++++++---------
> >  xen/arch/x86/pv/domain.c            |  4 ++++
> >  xen/arch/x86/pv/mm.c                |  3 ++-
> >  4 files changed, 18 insertions(+), 10 deletions(-)
> >
> > diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h
> > index b79d6badd71c..b659cffc7f81 100644
> > --- a/xen/arch/x86/include/asm/domain.h
> > +++ b/xen/arch/x86/include/asm/domain.h
> > @@ -523,6 +523,8 @@ struct pv_vcpu
> >      struct trap_info *trap_ctxt;
> >  
> >      unsigned long gdt_frames[FIRST_RESERVED_GDT_PAGE];
> > +    /* Max LDT entries is 8192, so 8192 * 8 = 64KiB (16 pages). */
> > +    mfn_t ldt_frames[16];
> >      unsigned long ldt_base;
> >      unsigned int gdt_ents, ldt_ents;
> >  
> > diff --git a/xen/arch/x86/pv/descriptor-tables.c b/xen/arch/x86/pv/descriptor-tables.c
> > index 5a79f022ce13..95b598a4c0cf 100644
> > --- a/xen/arch/x86/pv/descriptor-tables.c
> > +++ b/xen/arch/x86/pv/descriptor-tables.c
> > @@ -20,28 +20,29 @@
> >   */
> >  bool pv_destroy_ldt(struct vcpu *v)
> >  {
> > -    l1_pgentry_t *pl1e;
> > +    const unsigned int nr_frames = ARRAY_SIZE(v->arch.pv.ldt_frames);
> >      unsigned int i, mappings_dropped = 0;
> > -    struct page_info *page;
> >  
> >      ASSERT(!in_irq());
> >  
> >      ASSERT(v == current || !vcpu_cpu_dirty(v));
> >  
> > -    pl1e = pv_ldt_ptes(v);
> > +    destroy_perdomain_mapping(v, LDT_VIRT_START(v), nr_frames);
> >  
> > -    for ( i = 0; i < 16; i++ )
> > +    for ( i = 0; i < nr_frames; i++ )
> 
> nit: While at this, can the "unsigned int" be moved here too?

I don't mind much, but I also don't usually do such changes as I think
it adds more noise.

> >      {
> > -        if ( !(l1e_get_flags(pl1e[i]) & _PAGE_PRESENT) )
> > -            continue;
> > +        mfn_t mfn = v->arch.pv.ldt_frames[i];
> > +        struct page_info *page;
> >  
> > -        page = l1e_get_page(pl1e[i]);
> > -        l1e_write(&pl1e[i], l1e_empty());
> > -        mappings_dropped++;
> > +        if ( mfn_eq(mfn, INVALID_MFN) )
> > +            continue;
> 
> Can it really be disjoint? As in, why "continue" and not "break"?. Not that it
> matters in the slightest, and I prefer this form; but I'm curious.

I think so?  The PV guest LDT is populated as a result of page-faults,
so if the guest only happens to use segment descriptors that are on
the third page, the second page might not be mapped?

The continue was there already, and I really didn't dare to change
this, neither asked myself much.  Assumed due to how the guest LDT is
mapped on a page-fault basis it could indeed be disjointly mapped.

> >  
> > +        v->arch.pv.ldt_frames[i] = INVALID_MFN;
> > +        page = mfn_to_page(mfn);
> >          ASSERT_PAGE_IS_TYPE(page, PGT_seg_desc_page);
> >          ASSERT_PAGE_IS_DOMAIN(page, v->domain);
> >          put_page_and_type(page);
> > +        mappings_dropped++;
> >      }
> >  
> >      return mappings_dropped;
> > diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
> > index 7e8bffaae9a0..32d7488cc186 100644
> > --- a/xen/arch/x86/pv/domain.c
> > +++ b/xen/arch/x86/pv/domain.c
> > @@ -303,6 +303,7 @@ void pv_vcpu_destroy(struct vcpu *v)
> >  int pv_vcpu_initialise(struct vcpu *v)
> >  {
> >      struct domain *d = v->domain;
> > +    unsigned int i;
> >      int rc;
> >  
> >      ASSERT(!is_idle_domain(d));
> > @@ -311,6 +312,9 @@ int pv_vcpu_initialise(struct vcpu *v)
> >      if ( rc )
> >          return rc;
> >  
> > +    for ( i = 0; i < ARRAY_SIZE(v->arch.pv.ldt_frames); i++ )
> > +        v->arch.pv.ldt_frames[i] = INVALID_MFN;
> > +
> 
> I think it makes more sense to move this earlier so ldt_frames[] is initialised
> even if pv_vcpu_initialise() fails. It may be benign, but it looks like an
> accident abount to happen.

Right, pv_destroy_gdt_ldt_l1tab() doesn't care at all about the
contents of ldt_frames[], but it will be safe to do change the
ordering in pv_vcpu_initialise().

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 14:45:53 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 14:45:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869753.1281214 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWGGm-00064X-LM; Fri, 10 Jan 2025 14:45:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869753.1281214; Fri, 10 Jan 2025 14:45:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWGGm-00064Q-H3; Fri, 10 Jan 2025 14:45:52 +0000
Received: by outflank-mailman (input) for mailman id 869753;
 Fri, 10 Jan 2025 14:45: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
 <SRS0=J0bo=UC=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tWGGl-00064J-Qw
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 14:45:51 +0000
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
 [2a00:1450:4864:20::531])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 96195ccd-cf61-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 15:45:51 +0100 (CET)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-5d3bbb0f09dso3575611a12.2
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 06:45:51 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d9903c3039sm1779610a12.40.2025.01.10.06.45.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 10 Jan 2025 06:45:47 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 96195ccd-cf61-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736520350; x=1737125150; 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=GYThS8R1KInT4Ntvc/a1r1aZWXtnO76bugL1FsedsPY=;
        b=cZMPa07ofvWhlgoNqZQYESKh0uEGPlt2RKXJHXdVr7FHqcA5jFSU6l8Nu78xghQWYL
         gRLRakFjHcaBr0ET2Qb0Yz3XX5BONyLsTJ6HU32A8kfyPgbYxoSGjw+KaFT4psTCQALw
         3sGyitHb6094X4hVq+2XO0lBBHitOA3WskM6E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736520350; x=1737125150;
        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=GYThS8R1KInT4Ntvc/a1r1aZWXtnO76bugL1FsedsPY=;
        b=Pk5XNNYnWXpDvuHLjG036qF872RyqFdbdHTA9R3uDaJINoPtBtaH9erLeF45f5CGO1
         lBFsyOvNphrcZbHDOsOCMgyRvGUj1V48HEuw8WUUXtXxR8t0b4z2OgPJQCzBKI7ik6+g
         kefYQNrpjNVcTohQsHcavyUOzU55QdYa3b1umHyBnggPGkukSC16rB+dQzQ93Xiooca6
         PLvNxztd9nDF+VKRYvww1OuaxtTzeS7CsTmva6Qb8mxNeUdu7kZP5c0/gEbwUuFXIDcA
         JwQm6H1oVddGHgC16Pnk1OARbEa1JOfXQivza9TvaIOi2m7+//gwdwjiEm/K54g3Hsht
         5+VA==
X-Gm-Message-State: AOJu0Ywmwv0TTRVNXWo4/Ms0q/RuhTRe53a7JgBagsG8v0QBXCjx107A
	/Qd6wtTy9YGvIm7hZQU7jAyuIXJ0MY2hKvaeJnnGJyMLsm+Qu67+Km40EtQCPaMfK2mDVeRuN6o
	U
X-Gm-Gg: ASbGncsmRdLk+6wkKQCvdJ30hkFpwlbZegDa3AVaduC8B9EPEVBCIMwMkKfqCa9Vt8Y
	IcKAri3FZvqvIVhZtEXb+FTiSh/NzP5K2rKMO53CDfByRRGVrNyE4SNsQZLl2fzpBMxuD2znOrb
	SBGjKXU+Ekl0dk0rQ1+gWHPfJPPOWQasWgviO0pw9DZMunItZ8gRPGfxsTQJ08nSs0oK2DmBUyh
	ks71SjF+bmmjDYdEvAPelHSEHpmaR5fiRTrjKK6vGiqm4qPcoVM8RkMpKqJoRoKIVo=
X-Google-Smtp-Source: AGHT+IFHxPu4BiMuNaXHUAetfAgdv9GoM7Qqq/0d4mQq9WDzGUoWk4GhX6amjW9I3bhg8D8oMqLaDg==
X-Received: by 2002:a05:6402:4414:b0:5d9:a84:d4b6 with SMTP id 4fb4d7f45d1cf-5d972d26ac2mr8951480a12.0.1736520350519;
        Fri, 10 Jan 2025 06:45:50 -0800 (PST)
Date: Fri, 10 Jan 2025 15:45:46 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Alejandro Vallejo <alejandro.vallejo@cloud.com>
Cc: xen-devel@lists.xenproject.org, Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v2 09/18] x86/mm: simplify create_perdomain_mapping()
 interface
Message-ID: <Z4EymsQaGq_cJiPP@macbook.local>
References: <20250108142659.99490-1-roger.pau@citrix.com>
 <20250108142659.99490-10-roger.pau@citrix.com>
 <D6XHOJ01P6HV.2IGS7W4SGN07@cloud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <D6XHOJ01P6HV.2IGS7W4SGN07@cloud.com>

On Thu, Jan 09, 2025 at 11:01:00AM +0000, Alejandro Vallejo wrote:
> On Wed Jan 8, 2025 at 2:26 PM GMT, Roger Pau Monne wrote:
> > diff --git a/xen/arch/x86/include/asm/mm.h b/xen/arch/x86/include/asm/mm.h
> > index 65cd751087dc..0c57442c9593 100644
> > --- a/xen/arch/x86/include/asm/mm.h
> > +++ b/xen/arch/x86/include/asm/mm.h
> > @@ -601,8 +601,7 @@ int compat_arch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg);
> >  #define IS_NIL(ptr) (!((uintptr_t)(ptr) + sizeof(*(ptr))))
> 
> Shouldn't IS_NIL() and NIL (out of context) be removed too?

Indeed, yet more cleanup, thanks!

Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 14:56:08 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 14:56:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869762.1281223 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWGQb-00088j-Hf; Fri, 10 Jan 2025 14:56:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869762.1281223; Fri, 10 Jan 2025 14:56:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWGQb-00088c-E5; Fri, 10 Jan 2025 14:56:01 +0000
Received: by outflank-mailman (input) for mailman id 869762;
 Fri, 10 Jan 2025 14:55: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
 <SRS0=J0bo=UC=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tWGQZ-00088W-O5
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 14:55:59 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ffaff272-cf62-11ef-99a4-01e77a169b0f;
 Fri, 10 Jan 2025 15:55:57 +0100 (CET)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-aaeecbb7309so399492766b.0
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 06:55:57 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c905ecb7sm173795666b.26.2025.01.10.06.55.55
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 10 Jan 2025 06:55:56 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ffaff272-cf62-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736520957; x=1737125757; 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=RDPcXxyy2Ta5dtW2V7jkkmgY2NR22UEPefzBYuSQvRg=;
        b=Ou9cVUM7KY0OyS7WYUXT1tYyHS7l64/vH/LnWUfg6N5v8Hxywfwvln7vlnoesk0XdH
         NU70/qNXYzM3lCLEf1TgHAD5UJmShCaRlsteSqn9i2xAgoM9Tn/Elv0E6+eoOMWpgs4i
         WLSCKMTBmJpvM2l6S0Ymv/jMm/+ACO6EMOCe4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736520957; x=1737125757;
        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=RDPcXxyy2Ta5dtW2V7jkkmgY2NR22UEPefzBYuSQvRg=;
        b=Dr5Hju/25TwV0zweFKhF2jKkWQAmXxbiz6ae+z+yuJHThKCGt4RM7ruMn0T2BlovSM
         E/O9swgqOUeNYuIbNfSPU9hDiUzXpONeFOCUpZXzflvSK4tkRx1SGbVZ5YEZoPhmyHyU
         Nv0ow4NoV9tCKcS/eU1qe3VNzDMSyOYwYtmyjmDbOgci6lgSM/CsIjzImh9CUUJLtPOG
         dfNSiYOZM4VqVmLcnkfJ3Gv1yzWAnBZvrGTEvowwJ4qEJnU+nY4r1IedLOHVwfoo/oVd
         bQJG+SCMl3vbaAF9R3jB2g27g9XG+1lhROg/pAe0Kp/ejzBQ7IO8jmANwkh70z83LLxD
         2kYg==
X-Gm-Message-State: AOJu0YzAZPFgJpaMDR9faCrCQGX5KH43gAtg5ajhzNse1q1aZL/BfiWU
	N7sNCZBzzzq2TLWQd4NPVttr8zrUtsHwJmAc5rg77ACcM+DmxJtxDFYgI3hlssI=
X-Gm-Gg: ASbGncvIak9Ht5h1v8ZtWM6bC9g4yL/4SsrRkdyrlVAakUMITWhzL0kfbNtAzF16PzT
	AA/XIw9v/Ab4LN8dTlZKdPYXpZByXXQFm8vIhFGxS6G66t3EHH3ApPxVCB41uoo659rHVIjkH4E
	we3RarNPZtwetHYYAJjtvfGGgGNUy4lsw08Md7imMGmveOneH1GbN9uSMh1h3kM6wuJEJcVuqOM
	Nb+c1qHKQa77AO1D05fMdw+4JHgr3y8XSwbWHeVLDhbTGB+SWs/EcXJjihSX2B5Vkg=
X-Google-Smtp-Source: AGHT+IFici5Pug04ZUP65IU/rev0PsQbFH12k5vwuLldTqQf2Mn+SI3qFq9kOwLZLcZF5RLXHX0iRQ==
X-Received: by 2002:a17:907:809:b0:aaf:117c:e929 with SMTP id a640c23a62f3a-ab2abcb1440mr1002849366b.57.1736520957010;
        Fri, 10 Jan 2025 06:55:57 -0800 (PST)
Date: Fri, 10 Jan 2025 15:55:55 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Alejandro Vallejo <alejandro.vallejo@cloud.com>
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2 13/18] x86/spec-ctrl: introduce Address Space
 Isolation command line option
Message-ID: <Z4E0-5KUWh2AJu50@macbook.local>
References: <20250108142659.99490-1-roger.pau@citrix.com>
 <20250108142659.99490-14-roger.pau@citrix.com>
 <D6XMQD34DXRE.24L7RC2WUI298@cloud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <D6XMQD34DXRE.24L7RC2WUI298@cloud.com>

On Thu, Jan 09, 2025 at 02:58:29PM +0000, Alejandro Vallejo wrote:
> On Wed Jan 8, 2025 at 2:26 PM GMT, Roger Pau Monne wrote:
> > No functional change, as the option is not used.
> >
> > Introduced new so newly added functionality is keyed on the option being
> > enabled, even if the feature is non-functional.
> >
> > When ASI is enabled for PV domains, printing the usage of XPTI might be
> > omitted if it must be uniformly disabled given the usage of ASI.
> >
> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> > ---
> > Changes since v1:
> >  - Improve comments and documentation about what ASI provides.
> >  - Do not print the XPTI information if ASI is used for pv domUs and dom0 is
> >    PVH, or if ASI is used for both domU and dom0.
> >
> > FWIW, I would print the state of XPTI uniformly, as otherwise I find the output
> > might be confusing for user expecting to assert the state of XPTI.
> > ---
> >  docs/misc/xen-command-line.pandoc    |  19 +++++
> >  xen/arch/x86/include/asm/domain.h    |   3 +
> >  xen/arch/x86/include/asm/spec_ctrl.h |   2 +
> >  xen/arch/x86/spec_ctrl.c             | 115 +++++++++++++++++++++++++--
> >  4 files changed, 133 insertions(+), 6 deletions(-)
> >
> > diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
> > index 08b0053f9ced..3c1ad7b5fe7d 100644
> > --- a/docs/misc/xen-command-line.pandoc
> > +++ b/docs/misc/xen-command-line.pandoc
> > @@ -202,6 +202,25 @@ to appropriate auditing by Xen.  Argo is disabled by default.
> >      This option is disabled by default, to protect domains from a DoS by a
> >      buggy or malicious other domain spamming the ring.
> >  
> > +### asi (x86)
> > +> `= List of [ <bool>, {pv,hvm}=<bool>,
> > +               {vcpu-pt}=<bool>|{pv,hvm}=<bool> ]`
> 
> nit: While this grows later, the braces around vcpu-pt aren't strictly needed here.

Since I have to modify the whole line I can indeed add the braces
later.

> > +
> > +Offers control over whether the hypervisor will engage in Address Space
> > +Isolation, by not having potentially sensitive information permanently mapped
> > +in the VMM page-tables.  Using this option might avoid the need to apply
> > +mitigations for certain speculative related attacks, at the cost of mapping
> > +sensitive information on-demand.
> 
> Might be worth mentioning that this provides some defense in depth against
> unmitigated attacks too.

It's IMO a bit too vague to make such promises, but I can add:

Offers control over whether the hypervisor will engage in Address Space
Isolation, by not having potentially sensitive information permanently mapped
in the VMM page-tables.  Using this option might avoid the need to apply
mitigations for certain speculative related attacks, at the cost of mapping
sensitive information on-demand.  It might also offer some protection
against unmitigated speculation-related attacks.

> > +
> > +* `pv=` and `hvm=` sub-options allow enabling for specific guest types.
> > +
> > +**WARNING: manual de-selection of enabled options will invalidate any
> > +protection offered by the feature.  The fine grained options provided below are
> > +meant to be used for debugging purposes only.**
> > +
> > +* `vcpu-pt` ensure each vCPU uses a unique top-level page-table and setup a
> > +  virtual address space region to map memory on a per-vCPU basis.
> > +
> >  ### asid (x86)
> >  > `= <boolean>`
> >  
> > diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
> > index ced84750015c..9463a8624701 100644
> > --- a/xen/arch/x86/spec_ctrl.c
> > +++ b/xen/arch/x86/spec_ctrl.c
> > @@ -2075,6 +2165,19 @@ void __init init_speculation_mitigations(void)
> >           hw_smt_enabled && default_xen_spec_ctrl )
> >          setup_force_cpu_cap(X86_FEATURE_SC_MSR_IDLE);
> >  
> > +    /* Disable all ASI options by default until feature is finished. */
> > +    if ( opt_vcpu_pt_pv == -1 )
> > +        opt_vcpu_pt_pv = 0;
> > +    if ( opt_vcpu_pt_hwdom == -1 )
> > +        opt_vcpu_pt_hwdom = 0;
> > +    if ( opt_vcpu_pt_hvm == -1 )
> > +        opt_vcpu_pt_hvm = 0;
> 
> Why not preinitialise them to zero instead in the static declarations?

Hm, indeed.  I can probably make them booleans then.  I wrongly
recall that checking whether they haven't been initialized was needed
somewhere, but that doesn't seem to be the case.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 15:03:14 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 15:03:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869773.1281238 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWGXN-0001Ww-8y; Fri, 10 Jan 2025 15:03:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869773.1281238; Fri, 10 Jan 2025 15:03:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWGXN-0001Wp-63; Fri, 10 Jan 2025 15:03:01 +0000
Received: by outflank-mailman (input) for mailman id 869773;
 Fri, 10 Jan 2025 15:02:59 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=J0bo=UC=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tWGXL-0001Rg-4t
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 15:02:59 +0000
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com
 [2a00:1450:4864:20::636])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id fa751def-cf63-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 16:02:58 +0100 (CET)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-aa67ac42819so314547766b.0
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 07:02:58 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2e8c753fdsm46555266b.184.2025.01.10.07.02.55
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 10 Jan 2025 07:02:56 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: fa751def-cf63-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736521378; x=1737126178; 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=YqYdDANoSBsS1PjsOKiER1zG2JvS6sj37w22hFPqJfA=;
        b=ipNV7uGz+3vH5MFFAjtuoy/oxfWGGJDKMJ+awuuZ0Xtr7V9xQ25H0CGZJpUyAg/AbX
         Zv8ulboEbp+VCOXbl1UqpKE6KooiyJMsbQl4TFds2wEHq0JdQelgYW8wlN7PNyfz4HUF
         txHtTI09IcAMpxN7/UZm2wO6DKyggK79xKGbE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736521378; x=1737126178;
        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=YqYdDANoSBsS1PjsOKiER1zG2JvS6sj37w22hFPqJfA=;
        b=R6Il8m25chtBM9oeDlwET2YkvkQ+vSDMZguddR+IPK2X60l6YNp6bTbw7hXmXpbqMl
         pugQnWehnLetsyMWFaCVLGK7JfLH81mbxAA7xnStd/Tu6nkl7av2NQ8pzWt/1BjGVJTG
         jZtmnX+nm696uHS9EIgIDlsiile1TxuzqRoj12cKEEUNmKNlxwzPIQrTSLorcwcVWP9d
         K8pOD5y3TmUyA7hPQzgUkgEKJdnhecjz9KPnSyRGvSOhyfrc7ZMq2KpWF3k7ZIy8HCDu
         KVNtHrDSBC8hTUacnAlEo/wlH9Cg+n3EdC4Gj6K81/ssOXB8eXvWhbz7EfdvLCCIImXp
         kzVg==
X-Gm-Message-State: AOJu0YxkhTcn+bNK7xgF5Qul7GgM+NAelHwUpPTqZXZYjowGvQA4NeIb
	geXiD1cIvblmyRkGarvq1C2kHf5hmlNirAtx7TtYSpD/5zBnVvpZOryQFw8y1mk=
X-Gm-Gg: ASbGnct566Yn8NRz3kUyiMyA3MtuVQb+qW8XyTBsOMuhShP0u2Scywo+lx6o6haxUgf
	k29QLnJOAztDX0ZivDLCNHYVVPMbnPVPMS1dYIzsQmfiQ/cuDRF/heaMR8gj7dhegPclcv87XcI
	XSPosnd3o+1RdtL8VOTj/x60A8QtI1SpvJicX+zHHdm8964Opnm6PFEJ7XpeIpiGUtw0qkCbxBk
	+P0+nXQSNappXDsWjbCaGUcpDd5eseMYS56FKV7R3SGbklnLB4Ad70vzsGBZlMaeoM=
X-Google-Smtp-Source: AGHT+IFx6zocR1K8MNQTFTs4PoaU068CTCKcQ2hg8ez/pyhmkoyjZ0XB4u19AMgEISrlB37nmd5sAw==
X-Received: by 2002:a17:907:70c:b0:aa6:9176:61ed with SMTP id a640c23a62f3a-ab2abc6d42emr1035266666b.48.1736521377393;
        Fri, 10 Jan 2025 07:02:57 -0800 (PST)
Date: Fri, 10 Jan 2025 16:02:54 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Alejandro Vallejo <alejandro.vallejo@cloud.com>
Cc: xen-devel@lists.xenproject.org, Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v2 15/18] x86/mm: introduce a per-vCPU mapcache when
 using ASI
Message-ID: <Z4E2nhxxIKO8sWoz@macbook.local>
References: <20250108142659.99490-1-roger.pau@citrix.com>
 <20250108142659.99490-16-roger.pau@citrix.com>
 <D6XMXUBHE5UI.16YI6AVTYXNUM@cloud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <D6XMXUBHE5UI.16YI6AVTYXNUM@cloud.com>

On Thu, Jan 09, 2025 at 03:08:15PM +0000, Alejandro Vallejo wrote:
> On Wed Jan 8, 2025 at 2:26 PM GMT, Roger Pau Monne wrote:
> > When using a unique per-vCPU root page table the per-domain region becomes
> > per-vCPU, and hence the mapcache is no longer shared between all vCPUs of a
> > domain.  Introduce per-vCPU mapcache structures, and modify map_domain_page()
> > to create per-vCPU mappings when possible.  Note the lock is also not needed
> > with using per-vCPU map caches, as the structure is no longer shared.
> >
> > This introduces some duplication in the domain and vcpu structures, as both
> > contain a mapcache field to support running with and without per-vCPU
> > page-tables.
> >
> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> > ---
> >  xen/arch/x86/domain_page.c        | 90 ++++++++++++++++++++-----------
> >  xen/arch/x86/include/asm/domain.h | 20 ++++---
> >  2 files changed, 71 insertions(+), 39 deletions(-)
> >
> > diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c
> > index 1372be20224e..65900d6218f8 100644
> > --- a/xen/arch/x86/domain_page.c
> > +++ b/xen/arch/x86/domain_page.c
> > @@ -74,7 +74,9 @@ void *map_domain_page(mfn_t mfn)
> >      struct vcpu *v;
> >      struct mapcache_domain *dcache;
> >      struct mapcache_vcpu *vcache;
> > +    struct mapcache *cache;
> >      struct vcpu_maphash_entry *hashent;
> > +    struct domain *d;
> >  
> >  #ifdef NDEBUG
> >      if ( mfn_x(mfn) <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) )
> > @@ -85,9 +87,12 @@ void *map_domain_page(mfn_t mfn)
> >      if ( !v || !is_pv_vcpu(v) )
> >          return mfn_to_virt(mfn_x(mfn));
> >  
> > -    dcache = &v->domain->arch.pv.mapcache;
> > +    d = v->domain;
> > +    dcache = &d->arch.pv.mapcache;
> >      vcache = &v->arch.pv.mapcache;
> > -    if ( !dcache->inuse )
> > +    cache = d->arch.vcpu_pt ? &v->arch.pv.mapcache.cache
> > +                            : &d->arch.pv.mapcache.cache;
> > +    if ( !cache->inuse )
> >          return mfn_to_virt(mfn_x(mfn));
> >  
> >      perfc_incr(map_domain_page_count);
> > @@ -98,17 +103,18 @@ void *map_domain_page(mfn_t mfn)
> >      if ( hashent->mfn == mfn_x(mfn) )
> >      {
> >          idx = hashent->idx;
> > -        ASSERT(idx < dcache->entries);
> > +        ASSERT(idx < cache->entries);
> >          hashent->refcnt++;
> >          ASSERT(hashent->refcnt);
> >          ASSERT(mfn_eq(l1e_get_mfn(MAPCACHE_L1ENT(idx)), mfn));
> >          goto out;
> >      }
> >  
> > -    spin_lock(&dcache->lock);
> > +    if ( !d->arch.vcpu_pt )
> > +        spin_lock(&dcache->lock);
> 
> Hmmm. I wonder whether we might not want a nospec here...

Not sure TBH, we have other instances of conditional locking that
doesn't use nospec().  That said I'm not claiming those are correct.
Shouldn't people that care about this kind of speculation into
critical regions just use CONFIG_SPECULATIVE_HARDEN_LOCK?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 15:36:48 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 15:36:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869800.1281255 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWH3x-0007f5-Lh; Fri, 10 Jan 2025 15:36:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869800.1281255; Fri, 10 Jan 2025 15:36:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWH3x-0007ey-Ii; Fri, 10 Jan 2025 15:36:41 +0000
Received: by outflank-mailman (input) for mailman id 869800;
 Fri, 10 Jan 2025 15:36:40 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=mmVM=UC=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tWH3w-0007eo-S3
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 15:36:40 +0000
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com
 [2a00:1450:4864:20::32e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id aecb9e27-cf68-11ef-99a4-01e77a169b0f;
 Fri, 10 Jan 2025 16:36:38 +0100 (CET)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-4361815b96cso16328245e9.1
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 07:36:38 -0800 (PST)
Received: from localhost ([66.81.170.107]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436e9d8fb99sm56218295e9.3.2025.01.10.07.36.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 10 Jan 2025 07:36:37 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: aecb9e27-cf68-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736523398; x=1737128198; darn=lists.xenproject.org;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=S1ryMVl/qZS/jpcFHRhUv6+vaIZhN/DUNPGjMlSR+WE=;
        b=XWRyhYSPLMN0E9x9sEzGpRNtQOJZbydb9MRk9047F6Au/KW6KJOFK/kXMFUTQpZgMk
         gTzFCe8cJJG/1qDCYok86xHca8ULXlqoS8LrXemo7y7t+YczCmA0Jh0du0SKOhjXayQp
         AmD39FixJjlcxEIRgeplVqk3kKy78W1NjgWSg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736523398; x=1737128198;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=S1ryMVl/qZS/jpcFHRhUv6+vaIZhN/DUNPGjMlSR+WE=;
        b=FPOX2P7uQJy9a3o0TwHIoXFI3SJeHchgR8ACwlpLSyGyO58NAhp8lO/Sc9OGJLbhxx
         x6PwlqkfaC4AKZkhC7NLFI2RDILIcQGmNd0EMYatK0fbwi/CHYLYU5O4yUJA+rWX+W/O
         BkPkUPM7iXTWc568hkSZNI/g6BDaD3pX6cT1kHeQU4VNWwqaRfNGI/5WHBfynXvcjzga
         /RqEGryOSSKZbkryMzDJWrepvAajm9PD3NabMiKj+SLLeqBmS4LNDpIOvQX8xY1+7Wkn
         RSS8Ph8Qc6GJK2ihjT8w0VnZQ88Gpdoo1EXP4qivp/611xVWn1JhckJJy3ZxiedoJL9M
         OQBQ==
X-Gm-Message-State: AOJu0Yzku7fdtMVdur+y7wQZVPHC5uW2a7MQvgtS/hw9Eep5OiTVISbk
	x5bkrz9/R3ruW5Ac6jn2Ea0Ptd7/XOR6zinGcIjib5vjDzWyvhxnqJAKp5YlCA4cy+9HtIp1uTf
	3oAl0iQ==
X-Gm-Gg: ASbGncvJtrl52okte4dtGhFoGK7Pt6xEUgM5TMoay5iHhBlWgPusJlsyllAvNnXwJXI
	UtE2cObZu4JD4vzm2yV9kAF0Thtamy7fW8gwMRme+sBhElntr8Eeugb9Fn6JmxcXCKKWDaqpicT
	so8OHZlqpyAqEv4Q8sljFwPsT1cUdnEpsmQvJfwdYlf/OHGc9WvGfMi5AFy48nBB3a550fZv7Qe
	e/qkxGxuAVqHC/b3mDzZIDtG+R5mb54jBO0LgiOKoQC5xbYn+Mac3+v6ojO4/c=
X-Google-Smtp-Source: AGHT+IHvwlY5Mt/EUY+zHxQWGedl1tsYf6CHmFd3cE5G54HJmsba6AyEXR9urMk3pjaFfs7YQHOWyQ==
X-Received: by 2002:a05:6000:4611:b0:38a:624b:e619 with SMTP id ffacd0b85a97d-38a8730e03emr9987576f8f.43.1736523398269;
        Fri, 10 Jan 2025 07:36:38 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Fri, 10 Jan 2025 15:36:35 +0000
Message-Id: <D6YI62UU3U96.1YMORYP5SVE6Z@cloud.com>
Cc: <xen-devel@lists.xenproject.org>, "Jan Beulich" <jbeulich@suse.com>,
 "Andrew Cooper" <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v2 07/18] x86/pv: update guest LDT mappings using the
 linear entries
From: "Alejandro Vallejo" <alejandro.vallejo@cloud.com>
To: =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
X-Mailer: aerc 0.18.2
References: <20250108142659.99490-1-roger.pau@citrix.com>
 <20250108142659.99490-8-roger.pau@citrix.com>
 <D6XM7OP0SQPB.3U12X09JAPKU3@cloud.com> <Z4EyWLde4lHH-2Sm@macbook.local>
In-Reply-To: <Z4EyWLde4lHH-2Sm@macbook.local>

On Fri Jan 10, 2025 at 2:44 PM GMT, Roger Pau Monn=C3=A9 wrote:
> On Thu, Jan 09, 2025 at 02:34:05PM +0000, Alejandro Vallejo wrote:
> > On Wed Jan 8, 2025 at 2:26 PM GMT, Roger Pau Monne wrote:
> > > The pv_map_ldt_shadow_page() and pv_destroy_ldt() functions rely on t=
he L1
> > > table(s) that contain such mappings being stashed in the domain struc=
ture, and
> > > thus such mappings being modified by merely updating the require L1 e=
ntries.
> > >
> > > Switch pv_map_ldt_shadow_page() to unconditionally use the linear rec=
ursive, as
> > > that logic is always called while the vCPU is running on the current =
pCPU.
> > >
> > > For pv_destroy_ldt() use the linear mappings if the vCPU is the one c=
urrently
> > > running on the pCPU, otherwise use destroy_mappings().
> > >
> > > Note this requires keeping an array with the pages currently mapped a=
t the LDT
> > > area, as that allows dropping the extra taken page reference when rem=
oving the
> > > mappings.
> > >
> > > Signed-off-by: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
> > > ---
> > >  xen/arch/x86/include/asm/domain.h   |  2 ++
> > >  xen/arch/x86/pv/descriptor-tables.c | 19 ++++++++++---------
> > >  xen/arch/x86/pv/domain.c            |  4 ++++
> > >  xen/arch/x86/pv/mm.c                |  3 ++-
> > >  4 files changed, 18 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include=
/asm/domain.h
> > > index b79d6badd71c..b659cffc7f81 100644
> > > --- a/xen/arch/x86/include/asm/domain.h
> > > +++ b/xen/arch/x86/include/asm/domain.h
> > > @@ -523,6 +523,8 @@ struct pv_vcpu
> > >      struct trap_info *trap_ctxt;
> > > =20
> > >      unsigned long gdt_frames[FIRST_RESERVED_GDT_PAGE];
> > > +    /* Max LDT entries is 8192, so 8192 * 8 =3D 64KiB (16 pages). */
> > > +    mfn_t ldt_frames[16];
> > >      unsigned long ldt_base;
> > >      unsigned int gdt_ents, ldt_ents;
> > > =20
> > > diff --git a/xen/arch/x86/pv/descriptor-tables.c b/xen/arch/x86/pv/de=
scriptor-tables.c
> > > index 5a79f022ce13..95b598a4c0cf 100644
> > > --- a/xen/arch/x86/pv/descriptor-tables.c
> > > +++ b/xen/arch/x86/pv/descriptor-tables.c
> > > @@ -20,28 +20,29 @@
> > >   */
> > >  bool pv_destroy_ldt(struct vcpu *v)
> > >  {
> > > -    l1_pgentry_t *pl1e;
> > > +    const unsigned int nr_frames =3D ARRAY_SIZE(v->arch.pv.ldt_frame=
s);
> > >      unsigned int i, mappings_dropped =3D 0;
> > > -    struct page_info *page;
> > > =20
> > >      ASSERT(!in_irq());
> > > =20
> > >      ASSERT(v =3D=3D current || !vcpu_cpu_dirty(v));
> > > =20
> > > -    pl1e =3D pv_ldt_ptes(v);
> > > +    destroy_perdomain_mapping(v, LDT_VIRT_START(v), nr_frames);
> > > =20
> > > -    for ( i =3D 0; i < 16; i++ )
> > > +    for ( i =3D 0; i < nr_frames; i++ )
> >=20
> > nit: While at this, can the "unsigned int" be moved here too?
>
> I don't mind much, but I also don't usually do such changes as I think
> it adds more noise.

Fair enough, nvm then.

>
> > >      {
> > > -        if ( !(l1e_get_flags(pl1e[i]) & _PAGE_PRESENT) )
> > > -            continue;
> > > +        mfn_t mfn =3D v->arch.pv.ldt_frames[i];
> > > +        struct page_info *page;
> > > =20
> > > -        page =3D l1e_get_page(pl1e[i]);
> > > -        l1e_write(&pl1e[i], l1e_empty());
> > > -        mappings_dropped++;
> > > +        if ( mfn_eq(mfn, INVALID_MFN) )
> > > +            continue;
> >=20
> > Can it really be disjoint? As in, why "continue" and not "break"?. Not =
that it
> > matters in the slightest, and I prefer this form; but I'm curious.
>
> I think so?  The PV guest LDT is populated as a result of page-faults,
> so if the guest only happens to use segment descriptors that are on
> the third page, the second page might not be mapped?
>
> The continue was there already, and I really didn't dare to change
> this, neither asked myself much.  Assumed due to how the guest LDT is
> mapped on a page-fault basis it could indeed be disjointly mapped.

Ah, I see. That makes sense then. I wouldn't suggest changing it either, I
was just curious :)

>
> > > =20
> > > +        v->arch.pv.ldt_frames[i] =3D INVALID_MFN;
> > > +        page =3D mfn_to_page(mfn);
> > >          ASSERT_PAGE_IS_TYPE(page, PGT_seg_desc_page);
> > >          ASSERT_PAGE_IS_DOMAIN(page, v->domain);
> > >          put_page_and_type(page);
> > > +        mappings_dropped++;
> > >      }
> > > =20
> > >      return mappings_dropped;
> > > diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
> > > index 7e8bffaae9a0..32d7488cc186 100644
> > > --- a/xen/arch/x86/pv/domain.c
> > > +++ b/xen/arch/x86/pv/domain.c
> > > @@ -303,6 +303,7 @@ void pv_vcpu_destroy(struct vcpu *v)
> > >  int pv_vcpu_initialise(struct vcpu *v)
> > >  {
> > >      struct domain *d =3D v->domain;
> > > +    unsigned int i;
> > >      int rc;
> > > =20
> > >      ASSERT(!is_idle_domain(d));
> > > @@ -311,6 +312,9 @@ int pv_vcpu_initialise(struct vcpu *v)
> > >      if ( rc )
> > >          return rc;
> > > =20
> > > +    for ( i =3D 0; i < ARRAY_SIZE(v->arch.pv.ldt_frames); i++ )
> > > +        v->arch.pv.ldt_frames[i] =3D INVALID_MFN;
> > > +
> >=20
> > I think it makes more sense to move this earlier so ldt_frames[] is ini=
tialised
> > even if pv_vcpu_initialise() fails. It may be benign, but it looks like=
 an
> > accident abount to happen.
>
> Right, pv_destroy_gdt_ldt_l1tab() doesn't care at all about the
> contents of ldt_frames[], but it will be safe to do change the
> ordering in pv_vcpu_initialise().
>
> Thanks, Roger.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 15:50:27 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 15:50:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869814.1281265 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWHHB-0002Ky-Um; Fri, 10 Jan 2025 15:50:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869814.1281265; Fri, 10 Jan 2025 15:50:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWHHB-0002Kr-S9; Fri, 10 Jan 2025 15:50:21 +0000
Received: by outflank-mailman (input) for mailman id 869814;
 Fri, 10 Jan 2025 15:50:21 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=mmVM=UC=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tWHHB-0002Kl-2y
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 15:50:21 +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 97db49b0-cf6a-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 16:50:19 +0100 (CET)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-3863c36a731so1627957f8f.1
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 07:50:19 -0800 (PST)
Received: from localhost ([66.81.170.107]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436e9e37d3bsm55461245e9.31.2025.01.10.07.50.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 10 Jan 2025 07:50:18 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 97db49b0-cf6a-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736524219; x=1737129019; darn=lists.xenproject.org;
        h=in-reply-to:references:from:subject:cc:to:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=tUhxXZYEiIjTZLGclIWnxltqQKbyORiavFv7JaFGlNs=;
        b=PAY8c59n38d9cu9/E3q4re++RkjqhAhhoKL2a7Jx2FZ6xL+k4w/ZRatxaY7zSyppH+
         3+jx0yfMuBZeybdlj944W11dGfRja7Sag12wsha0EVSTV+I5PkxZBpexK6WMcoiJ3xZO
         osZTM3rmOKSJkbfvCrYd6QYnuNIRBvsqphtuw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736524219; x=1737129019;
        h=in-reply-to:references:from:subject:cc:to:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=tUhxXZYEiIjTZLGclIWnxltqQKbyORiavFv7JaFGlNs=;
        b=p+RrRFLK8lbEJBp/JLVbXAO6W6norN6/b+8OV+vaYAvTrBCoPNkcWe/Jz7aKTYyFeU
         EHeprTcguT97VjZ164ItFntqja8FxMAg/VajjS7fep9x8oIwIhc1GvEtrai6tKi+6AgR
         EUGV1PbpOw1G54qUJsjiz9uqfs4m9pqNhqpj4KG1cOcrIZ2J7JymPmrr+2GjZuMZjQk8
         Pef48h45LEuNrG3nUtUksgp25cdIm9LDFU7Lq3Qj48vL5dJOgNxzFP6+faGs/rDeQReY
         jMHDHGST8gN1qb2sc4G14Jx2gzonBUrJAX+y8Su23oC8V03XZcQgXl9DDFvN7WvvPB6p
         DeXQ==
X-Gm-Message-State: AOJu0YwxAPtX6LaeBnmbxd+QXN+IxFbWMjWb0zf3BPXEsmxYss2Ucu/y
	Y9u2IsN/1K723aiCplk8OxIF3EKKAQXV1RY2V+OO1mADgJsCMam1BGrzVB8GU+c=
X-Gm-Gg: ASbGncuRx0hLh5jeahyABnIhqUncXi/s5/eHo9T1ZiqUqgJL73Z5RuNHqBVzMSQoh3t
	l7Yj5qd2uGyoGkfG4KwcGzZ0vjwEQNgW+JXNZb8Nm4bNKFGy2u58TxCVHFhdCwBhY9MD6pejkMn
	qDy14ZoNVRmR9p7WTR0MJDFcQTdNDE6AgJlwKiuIz6ulcmsj5FNgOuAAOijuXSSSmBEJeWyMESR
	caLMLBFZxQiRsxqU6SX0AREKEVrFoQO1ycWQA4Jrp5lEBfy/Xb9ajdhCS7idQU=
X-Google-Smtp-Source: AGHT+IFOX73b3dv0QYzSDXgeve5p/cyhZ+80hgt2N6us0ApzB+YFUyV6o7OdOvgJldGH8+zn+rPO5w==
X-Received: by 2002:a5d:6d84:0:b0:385:ecdf:a30a with SMTP id ffacd0b85a97d-38a873140f6mr10342329f8f.33.1736524218821;
        Fri, 10 Jan 2025 07:50:18 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Fri, 10 Jan 2025 15:50:17 +0000
Message-Id: <D6YIGKABLDGN.J7DROWZ0H7BK@cloud.com>
To: =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Cc: <xen-devel@lists.xenproject.org>, "Jan Beulich" <jbeulich@suse.com>,
 "Andrew Cooper" <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v2 04/18] x86/pv: introduce function to populate
 perdomain area and use it to map Xen GDT
From: "Alejandro Vallejo" <alejandro.vallejo@cloud.com>
X-Mailer: aerc 0.18.2
References: <20250108142659.99490-1-roger.pau@citrix.com>
 <20250108142659.99490-5-roger.pau@citrix.com>
 <D6XGAK96L261.324ZJ1U3UO8LF@cloud.com> <Z4Eur-PNej2JQAm_@macbook.local>
In-Reply-To: <Z4Eur-PNej2JQAm_@macbook.local>

On Fri Jan 10, 2025 at 2:29 PM GMT, Roger Pau Monn=C3=A9 wrote:
> On Thu, Jan 09, 2025 at 09:55:44AM +0000, Alejandro Vallejo wrote:
> > On Wed Jan 8, 2025 at 2:26 PM GMT, Roger Pau Monne wrote:
> > > The current code to update the Xen part of the GDT when running a PV =
guest
> > > relies on caching the direct map address of all the L1 tables used to=
 map the
> > > GDT and LDT, so that entries can be modified.
> > >
> > > Introduce a new function that populates the per-domain region, either=
 using the
> > > recursive linear mappings when the target vCPU is the current one, or=
 by
> > > directly modifying the L1 table of the per-domain region.
> > >
> > > Using such function to populate per-domain addresses drops the need t=
o keep a
> > > reference to per-domain L1 tables previously used to change the per-d=
omain
> > > mappings.
> > >
> > > Signed-off-by: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
> > > ---
> > >  xen/arch/x86/domain.c                | 11 +++-
> > >  xen/arch/x86/include/asm/desc.h      |  6 +-
> > >  xen/arch/x86/include/asm/mm.h        |  2 +
> > >  xen/arch/x86/include/asm/processor.h |  5 ++
> > >  xen/arch/x86/mm.c                    | 88 ++++++++++++++++++++++++++=
++
> > >  xen/arch/x86/smpboot.c               |  6 +-
> > >  xen/arch/x86/traps.c                 | 10 ++--
> > >  7 files changed, 113 insertions(+), 15 deletions(-)
> > >
> > > diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> > > index 1f680bf176ee..0bd0ef7e40f4 100644
> > > --- a/xen/arch/x86/domain.c
> > > +++ b/xen/arch/x86/domain.c
> > > @@ -1953,9 +1953,14 @@ static always_inline bool need_full_gdt(const =
struct domain *d)
> > > =20
> > >  static void update_xen_slot_in_full_gdt(const struct vcpu *v, unsign=
ed int cpu)
> > >  {
> > > -    l1e_write(pv_gdt_ptes(v) + FIRST_RESERVED_GDT_PAGE,
> > > -              !is_pv_32bit_vcpu(v) ? per_cpu(gdt_l1e, cpu)
> > > -                                   : per_cpu(compat_gdt_l1e, cpu));
> > > +    ASSERT(v !=3D current);
> >=20
> > For this assert, and others below. IIUC, curr_vcpu =3D=3D current when =
we're
> > properly switched. When we're idling current =3D=3D idle and curr_vcpu =
=3D=3D prev_ctx.
> >=20
> > Granted, calling this in the middle of a lazy idle loop would be weird,=
 but
> > would it make sense for PT consistency to use curr_vcpu here...
>
> Hm, this function is called in a very specific context, and the assert
> intends to reflect that.  TBH I could just drop it, as
> populate_perdomain_mapping() will DTRT also when v =3D=3D current. The
> expectation for the context is also that current =3D=3D curr_vcpu.
>
> Note however that if v =3D=3D current we would need a flush after the
> populate_perdomain_mapping() call, since populate_perdomain_mapping()
> doesn't perform any flushing of the modified entries.  The main
> purpose of the ASSERT() is to notice this.
>
> > > +
> > > +    populate_perdomain_mapping(v,
> > > +                               GDT_VIRT_START(v) +
> > > +                               (FIRST_RESERVED_GDT_PAGE << PAGE_SHIF=
T),
> > > +                               !is_pv_32bit_vcpu(v) ? &per_cpu(gdt_m=
fn, cpu)
> > > +                                                    : &per_cpu(compa=
t_gdt_mfn,
> > > +                                                               cpu),=
 1);
> > >  }
> > > =20
> > >  static void load_full_gdt(const struct vcpu *v, unsigned int cpu)
> > > diff --git a/xen/arch/x86/include/asm/desc.h b/xen/arch/x86/include/a=
sm/desc.h
> > > index a1e0807d97ed..33981bfca588 100644
> > > --- a/xen/arch/x86/include/asm/desc.h
> > > +++ b/xen/arch/x86/include/asm/desc.h
> > > @@ -44,6 +44,8 @@
> > > =20
> > >  #ifndef __ASSEMBLY__
> > > =20
> > > +#include <xen/mm-frame.h>
> > > +
> > >  #define GUEST_KERNEL_RPL(d) (is_pv_32bit_domain(d) ? 1 : 3)
> > > =20
> > >  /* Fix up the RPL of a guest segment selector. */
> > > @@ -212,10 +214,10 @@ struct __packed desc_ptr {
> > > =20
> > >  extern seg_desc_t boot_gdt[];
> > >  DECLARE_PER_CPU(seg_desc_t *, gdt);
> > > -DECLARE_PER_CPU(l1_pgentry_t, gdt_l1e);
> > > +DECLARE_PER_CPU(mfn_t, gdt_mfn);
> > >  extern seg_desc_t boot_compat_gdt[];
> > >  DECLARE_PER_CPU(seg_desc_t *, compat_gdt);
> > > -DECLARE_PER_CPU(l1_pgentry_t, compat_gdt_l1e);
> > > +DECLARE_PER_CPU(mfn_t, compat_gdt_mfn);
> > >  DECLARE_PER_CPU(bool, full_gdt_loaded);
> > > =20
> > >  static inline void lgdt(const struct desc_ptr *gdtr)
> > > diff --git a/xen/arch/x86/include/asm/mm.h b/xen/arch/x86/include/asm=
/mm.h
> > > index 6c7e66ee21ab..b50a51327b2b 100644
> > > --- a/xen/arch/x86/include/asm/mm.h
> > > +++ b/xen/arch/x86/include/asm/mm.h
> > > @@ -603,6 +603,8 @@ int compat_arch_memory_op(unsigned long cmd, XEN_=
GUEST_HANDLE_PARAM(void) arg);
> > >  int create_perdomain_mapping(struct domain *d, unsigned long va,
> > >                               unsigned int nr, l1_pgentry_t **pl1tab,
> > >                               struct page_info **ppg);
> > > +void populate_perdomain_mapping(const struct vcpu *v, unsigned long =
va,
> > > +                                mfn_t *mfn, unsigned long nr);
> > >  void destroy_perdomain_mapping(struct domain *d, unsigned long va,
> > >                                 unsigned int nr);
> > >  void free_perdomain_mappings(struct domain *d);
> > > diff --git a/xen/arch/x86/include/asm/processor.h b/xen/arch/x86/incl=
ude/asm/processor.h
> > > index d247ef8dd226..82ee89f736c2 100644
> > > --- a/xen/arch/x86/include/asm/processor.h
> > > +++ b/xen/arch/x86/include/asm/processor.h
> > > @@ -243,6 +243,11 @@ static inline unsigned long cr3_pa(unsigned long=
 cr3)
> > >      return cr3 & X86_CR3_ADDR_MASK;
> > >  }
> > > =20
> > > +static inline mfn_t cr3_mfn(unsigned long cr3)
> > > +{
> > > +    return maddr_to_mfn(cr3_pa(cr3));
> > > +}
> > > +
> > >  static inline unsigned int cr3_pcid(unsigned long cr3)
> > >  {
> > >      return IS_ENABLED(CONFIG_PV) ? cr3 & X86_CR3_PCID_MASK : 0;
> > > diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> > > index 3d5dd22b6c36..0abea792486c 100644
> > > --- a/xen/arch/x86/mm.c
> > > +++ b/xen/arch/x86/mm.c
> > > @@ -6423,6 +6423,94 @@ int create_perdomain_mapping(struct domain *d,=
 unsigned long va,
> > >      return rc;
> > >  }
> > > =20
> > > +void populate_perdomain_mapping(const struct vcpu *v, unsigned long =
va,
> > > +                                mfn_t *mfn, unsigned long nr)
> > > +{
> > > +    l1_pgentry_t *l1tab =3D NULL, *pl1e;
> > > +    const l3_pgentry_t *l3tab;
> > > +    const l2_pgentry_t *l2tab;
> > > +    struct domain *d =3D v->domain;
> > > +
> > > +    ASSERT(va >=3D PERDOMAIN_VIRT_START &&
> > > +           va < PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS));
> > > +    ASSERT(!nr || !l3_table_offset(va ^ (va + nr * PAGE_SIZE - 1)));
> > > +
> > > +    /* Use likely to force the optimization for the fast path. */
> > > +    if ( likely(v =3D=3D current) )
> >=20
> > ... and here? In particular I'd expect using curr_vcpu here means...
>
> I'm afraid not, this is a trap I've fallen originally when doing this
> series, as I indeed had v =3D=3D curr_vcpu here (and no
> sync_local_execstate() call).
>
> However as a result of an interrupt, a call to sync_local_execstate()
> might happen, at which point the previous check of v =3D=3D curr_vcpu
> becomes stale.

Wow, that's nasty! More than fair enough then. Guess the XSAVE wrappers (an=
d
more generally all vCPU-local memory accessors) will have to take this into
account before poking into the contents of the perdomain region.

>
> > > +    {
> > > +        unsigned int i;
> > > +
> > > +        /* Ensure page-tables are from current (if current !=3D curr=
_vcpu). */
> > > +        sync_local_execstate();
> >=20
> > ... this should not be needed.
>
> As kind of mentioned above, this is required to ensure the page-tables
> are in-sync with the vCPU in current, and cannot change as a result of
> an interrupt triggering a call to sync_local_execstate().
>
> Otherwise the page-tables could change while or after the call to
> populate_perdomain_mapping(), and the mappings could end up being
> created on the wrong page-tables.
>
> Thanks, Roger.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 15:51:45 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 15:51:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869824.1281275 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWHIX-0002tA-89; Fri, 10 Jan 2025 15:51:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869824.1281275; Fri, 10 Jan 2025 15: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 <xen-devel-bounces@lists.xenproject.org>)
	id 1tWHIX-0002t3-4y; Fri, 10 Jan 2025 15:51:45 +0000
Received: by outflank-mailman (input) for mailman id 869824;
 Fri, 10 Jan 2025 15:51: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
 <SRS0=mmVM=UC=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tWHIW-0002sx-7i
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 15:51:44 +0000
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com
 [2a00:1450:4864:20::32d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c99f8644-cf6a-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 16:51:43 +0100 (CET)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-4361fe642ddso23740125e9.2
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 07:51:43 -0800 (PST)
Received: from localhost ([66.81.170.107]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436e2ddd013sm91688465e9.24.2025.01.10.07.51.41
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 10 Jan 2025 07:51:41 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c99f8644-cf6a-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736524302; x=1737129102; darn=lists.xenproject.org;
        h=in-reply-to:references:cc:to:from:subject:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=iwZXzZRO2IyjqibXEh9atU1QSD30JAVCPU+qoFD9bTA=;
        b=dxhaSwB18l4Ml5GoAr71VouL/GxT7ESj+J6EIVirmhwSBCScYyzm0f4CU2jEx9gpzr
         j+i0VDD5V2gjgIN7kPwnOIVx7wDub2noG5rRbbK0P2yImfiKRofWy4jc+f2HaFmG+hHk
         VPQWm1xnVtG4t2AvDuBZ7v8lbv9OKwZN6B2gE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736524302; x=1737129102;
        h=in-reply-to:references:cc:to:from:subject:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=iwZXzZRO2IyjqibXEh9atU1QSD30JAVCPU+qoFD9bTA=;
        b=SQd+E7zWt35N5AuGrRYUc0byHqUJYSoXf+yLl/m4Z4cFERBpM8yJwiPS4YGXI33eE8
         uK33w1cmtcbveOYQnoiiB4fmc6EpLRjzF49QnbZ7B04DI07OwIwCjBv3/nrObkPS5rOq
         ixTftgxXE1j7zWJIEbRASvR8b1/H9NTtetarncnZ4aQshNfMoRHM1Cfd+z0LUz7hVRGV
         QFUaWF2NtukOpG6zVc2/Hv4GOZ7wFe6AByOXHoY4gALkdzdh/h89hsStrjU8k8D7ewQT
         N3ZzJpKzZx7lluzndkqzZRTwEvCOUS8nV069j8nacmpXVl4UZ7QAufd7HTc8u935eEhY
         ucIw==
X-Gm-Message-State: AOJu0YwjceTNCzGZzleRcz4T1D2pBuYnrtaEkVNdrZddjICJ1o1qz92F
	li3yUU5PXtXZhR2RzHX25rhOjHElHisRsqTDoJVw1tpBOHCf2Ij7qnkggJqURJI=
X-Gm-Gg: ASbGnculyFY4HNK14NLAqj0P4zAtvBgBuKd8dQW9IvLqw2NfNDh/dKQWsWq/xxCGoc1
	OW3FltOwOO+tzAu2o9Yna3FUF/RO6wyU5yQB2U/t99OlhWaKvAaz9vWOm+zrjOnhegFPrSMKdiI
	rZBF99FCGK4MrDWPj1AEP6M60mdvS6Vydhvc8Hq+IOlPhWjPn1cTEayBd087MiW0Jx5wu+saIEy
	mvHj5Kbo+5HVPMU5JjzAfl/cSq7Q3NJR//9L5vD7zeQIsc0F9q4ZNjGdFkK/QE=
X-Google-Smtp-Source: AGHT+IHToGuxDjdFJHa5XBo7mCodPJYVNtgYHm3DQgaPGMIV7J8TQGsup6Hb9IX5HyKoSamt9Oo+xQ==
X-Received: by 2002:a05:600c:444d:b0:434:f739:7ce2 with SMTP id 5b1f17b1804b1-436eedef4e5mr32807065e9.8.1736524302357;
        Fri, 10 Jan 2025 07:51:42 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Fri, 10 Jan 2025 15:51:38 +0000
Message-Id: <D6YIHLM1RTKR.3QLY96ZGZD6AG@cloud.com>
Subject: Re: [PATCH v2 13/18] x86/spec-ctrl: introduce Address Space
 Isolation command line option
From: "Alejandro Vallejo" <alejandro.vallejo@cloud.com>
To: =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Cc: <xen-devel@lists.xenproject.org>, "Andrew Cooper"
 <andrew.cooper3@citrix.com>, "Anthony PERARD" <anthony.perard@vates.tech>,
 "Michal Orzel" <michal.orzel@amd.com>, "Jan Beulich" <jbeulich@suse.com>,
 "Julien Grall" <julien@xen.org>, "Stefano Stabellini"
 <sstabellini@kernel.org>
X-Mailer: aerc 0.18.2
References: <20250108142659.99490-1-roger.pau@citrix.com>
 <20250108142659.99490-14-roger.pau@citrix.com>
 <D6XMQD34DXRE.24L7RC2WUI298@cloud.com> <Z4E0-5KUWh2AJu50@macbook.local>
In-Reply-To: <Z4E0-5KUWh2AJu50@macbook.local>

On Fri Jan 10, 2025 at 2:55 PM GMT, Roger Pau Monn=C3=A9 wrote:
> On Thu, Jan 09, 2025 at 02:58:29PM +0000, Alejandro Vallejo wrote:
> > On Wed Jan 8, 2025 at 2:26 PM GMT, Roger Pau Monne wrote:
> > > No functional change, as the option is not used.
> > >
> > > Introduced new so newly added functionality is keyed on the option be=
ing
> > > enabled, even if the feature is non-functional.
> > >
> > > When ASI is enabled for PV domains, printing the usage of XPTI might =
be
> > > omitted if it must be uniformly disabled given the usage of ASI.
> > >
> > > Signed-off-by: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
> > > ---
> > > Changes since v1:
> > >  - Improve comments and documentation about what ASI provides.
> > >  - Do not print the XPTI information if ASI is used for pv domUs and =
dom0 is
> > >    PVH, or if ASI is used for both domU and dom0.
> > >
> > > FWIW, I would print the state of XPTI uniformly, as otherwise I find =
the output
> > > might be confusing for user expecting to assert the state of XPTI.
> > > ---
> > >  docs/misc/xen-command-line.pandoc    |  19 +++++
> > >  xen/arch/x86/include/asm/domain.h    |   3 +
> > >  xen/arch/x86/include/asm/spec_ctrl.h |   2 +
> > >  xen/arch/x86/spec_ctrl.c             | 115 +++++++++++++++++++++++++=
--
> > >  4 files changed, 133 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-comman=
d-line.pandoc
> > > index 08b0053f9ced..3c1ad7b5fe7d 100644
> > > --- a/docs/misc/xen-command-line.pandoc
> > > +++ b/docs/misc/xen-command-line.pandoc
> > > @@ -202,6 +202,25 @@ to appropriate auditing by Xen.  Argo is disable=
d by default.
> > >      This option is disabled by default, to protect domains from a Do=
S by a
> > >      buggy or malicious other domain spamming the ring.
> > > =20
> > > +### asi (x86)
> > > +> `=3D List of [ <bool>, {pv,hvm}=3D<bool>,
> > > +               {vcpu-pt}=3D<bool>|{pv,hvm}=3D<bool> ]`
> >=20
> > nit: While this grows later, the braces around vcpu-pt aren't strictly =
needed here.
>
> Since I have to modify the whole line I can indeed add the braces
> later.
>
> > > +
> > > +Offers control over whether the hypervisor will engage in Address Sp=
ace
> > > +Isolation, by not having potentially sensitive information permanent=
ly mapped
> > > +in the VMM page-tables.  Using this option might avoid the need to a=
pply
> > > +mitigations for certain speculative related attacks, at the cost of =
mapping
> > > +sensitive information on-demand.
> >=20
> > Might be worth mentioning that this provides some defense in depth agai=
nst
> > unmitigated attacks too.
>
> It's IMO a bit too vague to make such promises, but I can add:
>
> Offers control over whether the hypervisor will engage in Address Space
> Isolation, by not having potentially sensitive information permanently ma=
pped
> in the VMM page-tables.  Using this option might avoid the need to apply
> mitigations for certain speculative related attacks, at the cost of mappi=
ng
> sensitive information on-demand.  It might also offer some protection
> against unmitigated speculation-related attacks.

SGTM

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 16:02:41 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 16:02:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869835.1281285 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWHT1-0005Vw-5W; Fri, 10 Jan 2025 16:02:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869835.1281285; Fri, 10 Jan 2025 16:02:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWHT1-0005Vp-2P; Fri, 10 Jan 2025 16:02:35 +0000
Received: by outflank-mailman (input) for mailman id 869835;
 Fri, 10 Jan 2025 16:02: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
 <SRS0=uskN=UC=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tWHSz-0005Vj-Um
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 16:02:33 +0000
Received: from mail-ej1-x644.google.com (mail-ej1-x644.google.com
 [2a00:1450:4864:20::644])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4cb70c02-cf6c-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 17:02:32 +0100 (CET)
Received: by mail-ej1-x644.google.com with SMTP id
 a640c23a62f3a-aaecf50578eso431663066b.2
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 08:02:32 -0800 (PST)
Received: from andrewcoop.eng.citrite.net ([83.105.36.37])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c9562e83sm179816866b.103.2025.01.10.08.02.29
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 10 Jan 2025 08:02:29 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 4cb70c02-cf6c-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736524951; x=1737129751; 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=Btut3VgKxopRo9Q+vGGxptkuYGH3HO6bbe9wnIz9Vu4=;
        b=R68iBpUjQPQY7R3lpptnBnrBlRkAkzhTo+OKB5y2tS87U3ZkbNjaDtdiQhg4WRhLzB
         sMnA+luG5I4Pr4/llcnC4cY7dsYywp6IEULGtXQOzj8Z5W0L6Uth9nYT0rAJqP9XW39C
         COasI2m5x2wDYcfsZIilbHSp2CX4/8X/9GzFI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736524951; x=1737129751;
        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=Btut3VgKxopRo9Q+vGGxptkuYGH3HO6bbe9wnIz9Vu4=;
        b=RiT/n0Qb3+vmEhtwsPSxUD92kNaOkyOjA8iW1TE3tgHJ0v3ByYyqbIzbA1CEWBcpqc
         SoXZ7iArqN0HR3RuLBmZcSNW6hDlUVOQkEQ+IieXXab5PpQOS+9nC3/lOlaWghNwKHVP
         /AatJHSJLfGM+61GIQZC+u9npAoI7zMs6LP5/s7xbnT22qhKArAX+loz1d6rwLttcoFj
         +YIJIwRuqo8aH5Vb1tn6GGjv06FT21xLtrVMolNsHKGyY4NsynIRVLFfashOCb/9NM4l
         fU/Af2iu5o4zlu8+fefXl/ZXnbkw2uw+d7rL8t3e6i+7Pymada+1NA4f3+K/fTYLZski
         7Wxw==
X-Gm-Message-State: AOJu0Yw/zWkCOlCF8pBeLkwZOC29+TC1lkgWaXtUuPLz95wxRJOeqFvg
	6MlfUkxX1VZ1Yes43PpAKnYUimxxcXPRvvM8xbPewJ6+7/+2zlWaLrsNXozJXTW1oW1xAmlURye
	RZ+ObR0MH
X-Gm-Gg: ASbGnct6nWlQ4sKuD1KRkVqRXofqksIsKWu9CXGsR3rvqjAqrfS5wXIVcU/L/uPK62U
	xaHlqxB26RSTj0Trequ3mQf6B1/EBki+APKWhzCJyqUduaXVG7ECupvlFHBtO/jjQjS5uLE/rbW
	gN+r9CBVuwKlhBDgs0yfJUgx3ntMC8KmzW8GXW0BVusn9YqjC3iPWemmMy3C+nWWg9ctGDCwmbR
	gK0C+TGpeKbB1jjhyJ7QzWp9e8W0uNQOJgdWkrjjdIVlLlCAP5Ha3ddfol00BdqYtl0ukpYrvSQ
	A+d24w==
X-Google-Smtp-Source: AGHT+IE2QLjea2OuFYuA4zz1WmBqCuvxXAcg6LNNPwi5qmTXie3oSmJXauGAr7NeRZtUJVFIufXYpw==
X-Received: by 2002:a17:907:6d1a:b0:aaf:ab71:69cd with SMTP id a640c23a62f3a-ab2ab558b75mr1074247266b.20.1736524949936;
        Fri, 10 Jan 2025 08:02:29 -0800 (PST)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>
Subject: [PATCH] CI: Add an x86_64 Clang Randconfig job
Date: Fri, 10 Jan 2025 16:02:17 +0000
Message-Id: <20250110160217.183887-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This was recently identified as a hole in testing.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Roger Pau Monné <roger.pau@citrix.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Anthony PERARD <anthony.perard@vates.tech>
CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>

https://gitlab.com/xen-project/people/andyhhp/xen/-/jobs/8820980201
---
 automation/gitlab-ci/build.yaml | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
index 3abd2a0c6575..cb84f379b754 100644
--- a/automation/gitlab-ci/build.yaml
+++ b/automation/gitlab-ci/build.yaml
@@ -551,6 +551,12 @@ debian-12-x86_64-clang:
   variables:
     CONTAINER: debian:12-x86_64
 
+debian-12-x86_64-clang-randconfig:
+  extends: .clang-x86-64-build
+  variables:
+    CONTAINER: debian:12-x86_64
+    RANDCONFIG: y
+
 debian-12-x86_64-gcc:
   extends: .gcc-x86-64-build
   variables:
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Fri Jan 10 16:13:15 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 16:13:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869844.1281297 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWHd1-0007BK-2h; Fri, 10 Jan 2025 16:12:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869844.1281297; Fri, 10 Jan 2025 16:12:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWHd0-0007BD-Uo; Fri, 10 Jan 2025 16:12:54 +0000
Received: by outflank-mailman (input) for mailman id 869844;
 Fri, 10 Jan 2025 16:12:53 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=mmVM=UC=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tWHcz-0007B7-KA
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 16:12:53 +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 be5cc168-cf6d-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 17:12:52 +0100 (CET)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-385ddcfc97bso1945289f8f.1
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 08:12:52 -0800 (PST)
Received: from localhost ([66.81.170.107]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436e2e89df1sm90048765e9.27.2025.01.10.08.12.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 10 Jan 2025 08:12:51 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: be5cc168-cf6d-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736525572; x=1737130372; darn=lists.xenproject.org;
        h=in-reply-to:references:cc:to:from:subject:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=OMbCry0cF+4t0wc4UfHC0OgU/oMWHaSyqCM3/836NGo=;
        b=UdfFQvP/veL21sXyp5u15pimSF6jFhO/n9kkPNLdPZ5ibM54S27GG9pe4JxTgx4LiZ
         f6VX4Tn1885M5XkUYu8RrrTZPBXwHmeolG98YxVwbR65+/9nvSVtKJ+95sP4jV1fnB4m
         s+sthCqOgBcZE3fJ9YAJVCK1mHfN8Z25RFHKI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736525572; x=1737130372;
        h=in-reply-to:references:cc:to:from:subject:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=OMbCry0cF+4t0wc4UfHC0OgU/oMWHaSyqCM3/836NGo=;
        b=cQX3ZUXZkR9Esp9TeJ6GNMMyW39YLEkty/Nv9JjdtNjYyegKav5hHHiE/JPBuo+RXD
         byrboMIPvRxeTRS8CgMqvUZgnHv1Mb61OqpF07qqN2xHRg+dpKM7dXfHvGRe0gS6yG6c
         BzphcvYLav7ioGX4+EZAvzzdFLWpeJ7UAx+x8unR7pyI76sY4MsU96Vkjg70EppgQdMb
         7FU3mbinYxCKCpbdB+rKde5+gmaSicS6DRF3AFmOJxVjz8l1kR+JyJOxi807lEu3+fBG
         nWJqICdznoeXPpg1QwZipE/tZpjxk4WnCN/+ht8AdepKVfTxaPkkmuad3E8Ebgkycz9U
         oYXQ==
X-Gm-Message-State: AOJu0YzDMVagkLPkE9MsqG4U4wMwfJc2GBSJZKB5ndqMxgur8plHGelA
	p+lxl5It+BTR/oVzTGsuqEU97mqzYTLMZVB+Qp3MP2WBoQ7Iub181834lekCFas=
X-Gm-Gg: ASbGncuwUl6dPSTwZmF3Rbd9y8cidqDteia00xYxDDFDy9Y3WHmxelrzEFRceYl/IOZ
	c/W+y7LqqaKvoi7o1b+fwQvcBlDXFaB47Coypa15wNTztBopd0ZS6FX5afw4LgUyP3r5sBRPmkE
	/juy5Y/zFg/7ogtiLm/dRnbdF0hMpFTNI4ifYDvRPd/1YfUwTRM1oR1DuPpm2Nj/juv+iuAB+M7
	pKPhBcqRa/sxz3zR/sifBwWXjbLloIWb5XHLXWpNSofvGEbeecEOpYJrD1fSQE=
X-Google-Smtp-Source: AGHT+IEf423ZUfWznIkb2tTcPFSSgD9lw+ElDdU4hnIPpjIogre/Qgkx7Yw/WKCojGIUd5GchXnzIg==
X-Received: by 2002:adf:9bc6:0:b0:38a:888c:a727 with SMTP id ffacd0b85a97d-38a888caa54mr8045828f8f.25.1736525571968;
        Fri, 10 Jan 2025 08:12:51 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Fri, 10 Jan 2025 16:12:41 +0000
Message-Id: <D6YIXQ2RO454.RX5K5X216R2D@cloud.com>
Subject: Re: [PATCH v2 15/18] x86/mm: introduce a per-vCPU mapcache when
 using ASI
From: "Alejandro Vallejo" <alejandro.vallejo@cloud.com>
To: =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Cc: <xen-devel@lists.xenproject.org>, "Jan Beulich" <jbeulich@suse.com>,
 "Andrew Cooper" <andrew.cooper3@citrix.com>
X-Mailer: aerc 0.18.2
References: <20250108142659.99490-1-roger.pau@citrix.com>
 <20250108142659.99490-16-roger.pau@citrix.com>
 <D6XMXUBHE5UI.16YI6AVTYXNUM@cloud.com> <Z4E2nhxxIKO8sWoz@macbook.local>
In-Reply-To: <Z4E2nhxxIKO8sWoz@macbook.local>

On Fri Jan 10, 2025 at 3:02 PM GMT, Roger Pau Monn=C3=A9 wrote:
> On Thu, Jan 09, 2025 at 03:08:15PM +0000, Alejandro Vallejo wrote:
> > On Wed Jan 8, 2025 at 2:26 PM GMT, Roger Pau Monne wrote:
> > > When using a unique per-vCPU root page table the per-domain region be=
comes
> > > per-vCPU, and hence the mapcache is no longer shared between all vCPU=
s of a
> > > domain.  Introduce per-vCPU mapcache structures, and modify map_domai=
n_page()
> > > to create per-vCPU mappings when possible.  Note the lock is also not=
 needed
> > > with using per-vCPU map caches, as the structure is no longer shared.
> > >
> > > This introduces some duplication in the domain and vcpu structures, a=
s both
> > > contain a mapcache field to support running with and without per-vCPU
> > > page-tables.
> > >
> > > Signed-off-by: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
> > > ---
> > >  xen/arch/x86/domain_page.c        | 90 ++++++++++++++++++++---------=
--
> > >  xen/arch/x86/include/asm/domain.h | 20 ++++---
> > >  2 files changed, 71 insertions(+), 39 deletions(-)
> > >
> > > diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c
> > > index 1372be20224e..65900d6218f8 100644
> > > --- a/xen/arch/x86/domain_page.c
> > > +++ b/xen/arch/x86/domain_page.c
> > > @@ -74,7 +74,9 @@ void *map_domain_page(mfn_t mfn)
> > >      struct vcpu *v;
> > >      struct mapcache_domain *dcache;
> > >      struct mapcache_vcpu *vcache;
> > > +    struct mapcache *cache;
> > >      struct vcpu_maphash_entry *hashent;
> > > +    struct domain *d;
> > > =20
> > >  #ifdef NDEBUG
> > >      if ( mfn_x(mfn) <=3D PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) )
> > > @@ -85,9 +87,12 @@ void *map_domain_page(mfn_t mfn)
> > >      if ( !v || !is_pv_vcpu(v) )
> > >          return mfn_to_virt(mfn_x(mfn));
> > > =20
> > > -    dcache =3D &v->domain->arch.pv.mapcache;
> > > +    d =3D v->domain;
> > > +    dcache =3D &d->arch.pv.mapcache;
> > >      vcache =3D &v->arch.pv.mapcache;
> > > -    if ( !dcache->inuse )
> > > +    cache =3D d->arch.vcpu_pt ? &v->arch.pv.mapcache.cache
> > > +                            : &d->arch.pv.mapcache.cache;
> > > +    if ( !cache->inuse )
> > >          return mfn_to_virt(mfn_x(mfn));
> > > =20
> > >      perfc_incr(map_domain_page_count);
> > > @@ -98,17 +103,18 @@ void *map_domain_page(mfn_t mfn)
> > >      if ( hashent->mfn =3D=3D mfn_x(mfn) )
> > >      {
> > >          idx =3D hashent->idx;
> > > -        ASSERT(idx < dcache->entries);
> > > +        ASSERT(idx < cache->entries);
> > >          hashent->refcnt++;
> > >          ASSERT(hashent->refcnt);
> > >          ASSERT(mfn_eq(l1e_get_mfn(MAPCACHE_L1ENT(idx)), mfn));
> > >          goto out;
> > >      }
> > > =20
> > > -    spin_lock(&dcache->lock);
> > > +    if ( !d->arch.vcpu_pt )
> > > +        spin_lock(&dcache->lock);
> >=20
> > Hmmm. I wonder whether we might not want a nospec here...
>
> Not sure TBH, we have other instances of conditional locking that
> doesn't use nospec().  That said I'm not claiming those are correct.
> Shouldn't people that care about this kind of speculation into
> critical regions just use CONFIG_SPECULATIVE_HARDEN_LOCK?

Do people that care have a choice though? CONFIG_SPECULATIVE_HARDEN_LOCK on=
ly
blocks speculation in the taken branch here, so the critical region isn't
hardened when the relaxed branch is followed.

I suspect nospec in the condition would be fine perf-wise because the CPU c=
an
still do straight-line-speculation on the underlying function call when
CONFIG_SPECULATIVE_HARDEN_LOCK is not defined.

It's not the end of the world either way.

>
> Thanks, Roger.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 16:19:17 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 16:19:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869856.1281306 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWHj6-0008Hh-QD; Fri, 10 Jan 2025 16:19:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869856.1281306; Fri, 10 Jan 2025 16:19:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWHj6-0008Ha-Mb; Fri, 10 Jan 2025 16:19:12 +0000
Received: by outflank-mailman (input) for mailman id 869856;
 Fri, 10 Jan 2025 16:19:11 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=mmVM=UC=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tWHj5-0008HU-BA
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 16:19:11 +0000
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com
 [2a00:1450:4864:20::32b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9f048a32-cf6e-11ef-99a4-01e77a169b0f;
 Fri, 10 Jan 2025 17:19:09 +0100 (CET)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-436ce2ab251so17072105e9.1
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 08:19:09 -0800 (PST)
Received: from localhost ([66.81.170.107]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436e9e37d7fsm56305855e9.32.2025.01.10.08.19.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 10 Jan 2025 08:19:08 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9f048a32-cf6e-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736525949; x=1737130749; darn=lists.xenproject.org;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=N3lv/NArzrRA7WULk4MemEkjgKybl1dEMHzMPjgZfgY=;
        b=dqSW7X804Cx/Z2w4u8UEfTw04TPFQ/5sATPq/8r2UifMUvvBAisZOK9i3/nUgq1Yr2
         pJG1U2e3A+TaF0dbwCzqQj4Cb0DXFh3j/0rO45yNggPJ7hu33kcRSIq5r7iwr8G701Zp
         ocJ+XBWqQ8UWvRrVDxWzz3yLmYFhEKH7bwPRU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736525949; x=1737130749;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=N3lv/NArzrRA7WULk4MemEkjgKybl1dEMHzMPjgZfgY=;
        b=HdKOGBgfGpV+oZjPYttcWt6/uKIuNDFefhfcy8Ikx0UgaKkeAEAcBUlJMRUQ7UZgb7
         kc5sqWHVr96nCFLKhXSNIrZRwD9KjEsrqoo8ARc9tizrSk+m6QMBCB4QdgcOL6fB6foX
         UYnB34pYttLNEhY+zRif+f8mREX0R9QeTZQdpmJKu7+R4F+6WnNzHXqNdCBWvuMhO7LV
         VHDuMhzi7Vrj0oe6xQuVANgVUAiukFFZ6riVAQOZNZFSe2acEhAG9SrnLt/BD/42Tl2w
         QX619/EPn6dsKO2AJtzr0m/KS5/QfObj4KXCOHvyhJztgKZvZDjQolN0pBZ105Nn6eLc
         ChRg==
X-Gm-Message-State: AOJu0YzTM1GqJiHliGuVe0arxrY9sdRccOWzJN3ToGquGxXAq9lWNtca
	6z1VlnLiLTJKttOwSAwPEvmBgKhv1og0P8fDgLYlPpxrBZ0xk3xmwpcW5o4No7s=
X-Gm-Gg: ASbGncs6vW/MU0/u/NkJjFAxPrgkl8AYaKIDMgIILFNE+pHVKQ8mgeja5vul5MSR1Nn
	Wc2W3mEq4uqmdqL4JrPVPKX3acJgh+4eiMKY7ZwWaegbf3tbrlpnvClhWUvTps9Bszx5ds9gpBD
	pARHb3aVZYos2dSBSMfdlcDE1qx3dlajhi2gAP2GLYXDGxfEk5bEzqr0FnVIzAiM9pnr5mZfdP4
	y8lkeB5RKf7LtgnRKhq5dLH2RfC2713tFljaEAVEv8rl2obzgYvwEsfwbqUNnA=
X-Google-Smtp-Source: AGHT+IFCthcT27edbPU/MEm5ZqnDHi6DgoObRUGwD4EsKTVPYbuQu5jZnCJ9rs9X4ifQc6LVMKBPEQ==
X-Received: by 2002:a05:600c:19ce:b0:42c:bb96:340e with SMTP id 5b1f17b1804b1-436e26f857fmr112068085e9.31.1736525948757;
        Fri, 10 Jan 2025 08:19:08 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Fri, 10 Jan 2025 16:19:03 +0000
Message-Id: <D6YJ2L9AFQOQ.2ZZ5H8O4SK9J4@cloud.com>
Cc: <xen-devel@lists.xenproject.org>, "Jan Beulich" <jbeulich@suse.com>,
 "Andrew Cooper" <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v2 15/18] x86/mm: introduce a per-vCPU mapcache when
 using ASI
From: "Alejandro Vallejo" <alejandro.vallejo@cloud.com>
To: =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
X-Mailer: aerc 0.18.2
References: <20250108142659.99490-1-roger.pau@citrix.com>
 <20250108142659.99490-16-roger.pau@citrix.com>
 <D6XMXUBHE5UI.16YI6AVTYXNUM@cloud.com> <Z4E2nhxxIKO8sWoz@macbook.local>
In-Reply-To: <Z4E2nhxxIKO8sWoz@macbook.local>

On Fri Jan 10, 2025 at 3:02 PM GMT, Roger Pau Monn=C3=A9 wrote:
> On Thu, Jan 09, 2025 at 03:08:15PM +0000, Alejandro Vallejo wrote:
> > On Wed Jan 8, 2025 at 2:26 PM GMT, Roger Pau Monne wrote:
> > > When using a unique per-vCPU root page table the per-domain region be=
comes
> > > per-vCPU, and hence the mapcache is no longer shared between all vCPU=
s of a
> > > domain.  Introduce per-vCPU mapcache structures, and modify map_domai=
n_page()
> > > to create per-vCPU mappings when possible.  Note the lock is also not=
 needed
> > > with using per-vCPU map caches, as the structure is no longer shared.
> > >
> > > This introduces some duplication in the domain and vcpu structures, a=
s both
> > > contain a mapcache field to support running with and without per-vCPU
> > > page-tables.
> > >
> > > Signed-off-by: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
> > > ---
> > >  xen/arch/x86/domain_page.c        | 90 ++++++++++++++++++++---------=
--
> > >  xen/arch/x86/include/asm/domain.h | 20 ++++---
> > >  2 files changed, 71 insertions(+), 39 deletions(-)
> > >
> > > diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c
> > > index 1372be20224e..65900d6218f8 100644
> > > --- a/xen/arch/x86/domain_page.c
> > > +++ b/xen/arch/x86/domain_page.c
> > > @@ -74,7 +74,9 @@ void *map_domain_page(mfn_t mfn)
> > >      struct vcpu *v;
> > >      struct mapcache_domain *dcache;
> > >      struct mapcache_vcpu *vcache;
> > > +    struct mapcache *cache;
> > >      struct vcpu_maphash_entry *hashent;
> > > +    struct domain *d;
> > > =20
> > >  #ifdef NDEBUG
> > >      if ( mfn_x(mfn) <=3D PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) )
> > > @@ -85,9 +87,12 @@ void *map_domain_page(mfn_t mfn)
> > >      if ( !v || !is_pv_vcpu(v) )
> > >          return mfn_to_virt(mfn_x(mfn));
> > > =20
> > > -    dcache =3D &v->domain->arch.pv.mapcache;
> > > +    d =3D v->domain;
> > > +    dcache =3D &d->arch.pv.mapcache;
> > >      vcache =3D &v->arch.pv.mapcache;
> > > -    if ( !dcache->inuse )
> > > +    cache =3D d->arch.vcpu_pt ? &v->arch.pv.mapcache.cache
> > > +                            : &d->arch.pv.mapcache.cache;
> > > +    if ( !cache->inuse )
> > >          return mfn_to_virt(mfn_x(mfn));
> > > =20
> > >      perfc_incr(map_domain_page_count);
> > > @@ -98,17 +103,18 @@ void *map_domain_page(mfn_t mfn)
> > >      if ( hashent->mfn =3D=3D mfn_x(mfn) )
> > >      {
> > >          idx =3D hashent->idx;
> > > -        ASSERT(idx < dcache->entries);
> > > +        ASSERT(idx < cache->entries);
> > >          hashent->refcnt++;
> > >          ASSERT(hashent->refcnt);
> > >          ASSERT(mfn_eq(l1e_get_mfn(MAPCACHE_L1ENT(idx)), mfn));
> > >          goto out;
> > >      }
> > > =20
> > > -    spin_lock(&dcache->lock);
> > > +    if ( !d->arch.vcpu_pt )
> > > +        spin_lock(&dcache->lock);
> >=20
> > Hmmm. I wonder whether we might not want a nospec here...
>
> Not sure TBH, we have other instances of conditional locking that
> doesn't use nospec().  That said I'm not claiming those are correct.
> Shouldn't people that care about this kind of speculation into
> critical regions just use CONFIG_SPECULATIVE_HARDEN_LOCK?
>
> Thanks, Roger.

Actually, to avoid the double lfence, I think this would work too while
avoiding the lfence unconditionally when CONFIG_SPECULATIVE_HARDEN_LOCK is =
not
set.

    if ( !d->arch.vcpu_pt )
        spin_lock(&dcache->lock);
    else
        block_lock_speculation();

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 17:00:27 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 17:00:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869868.1281315 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWIMu-0006bZ-Nx; Fri, 10 Jan 2025 17:00:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869868.1281315; Fri, 10 Jan 2025 17:00:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWIMu-0006bS-LN; Fri, 10 Jan 2025 17:00:20 +0000
Received: by outflank-mailman (input) for mailman id 869868;
 Fri, 10 Jan 2025 17:00:20 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=mmVM=UC=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tWIMu-0006bM-5K
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 17:00:20 +0000
Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com
 [2a00:1450:4864:20::343])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5ea05430-cf74-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 18:00:18 +0100 (CET)
Received: by mail-wm1-x343.google.com with SMTP id
 5b1f17b1804b1-43618283d48so17342915e9.1
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 09:00:18 -0800 (PST)
Received: from localhost ([66.81.170.107]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436e9dc895esm57237825e9.13.2025.01.10.09.00.16
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 10 Jan 2025 09:00:17 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5ea05430-cf74-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736528418; x=1737133218; darn=lists.xenproject.org;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=PBy7MaoemUkmDMZM2GaOX0N85rym2pTWdWimCszo1Gc=;
        b=HL6MtkZFzq+LTsFdXjUcIpFuUCbbOVxaiYP3SXsQ2vEQv4rfG+iiVQZsaCyLmqAya2
         vG1wMVWIFF4YE+xgW96nMOB8mJ0bRMp/EuLrBbf3ifklPDrsR+hi/sHcieMfXbz1oxMZ
         I7Nwh7m+mNBK23EJdEv/yav47Bv6QlJUV7NVI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736528418; x=1737133218;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=PBy7MaoemUkmDMZM2GaOX0N85rym2pTWdWimCszo1Gc=;
        b=lsRfSTPAhDaCNZUlHuSY+NuU2zZl5IU7CNU3i4EjRRrqO8aLpVI9956ex6sU4lh1N7
         12rTHNZ5DXVTojgajIadwQGk5HfOewlrcifpAl3qsy8hOmMh2x+7nKtTz0g63QnwHJAR
         hViHf46FixbumTFK5N+B17Ek4R9ox4/PMrQ2gC/U5Dj9YOE+FqgwNaKHSzJBLCotnMTn
         DJBRhdx0+QVTw9r77bkzvU8TZqGWaiiSyACIoFc8wQHlV7LgzKvpeY8mfDKPER2dj8Z5
         5aF3+Ktzf+UZJ/WcvjDgXprGixoPnAi3CyvY8MQe+RgpgXioaGcGN+DJ6b1XTcljYxnA
         X8Ww==
X-Forwarded-Encrypted: i=1; AJvYcCUpYWpN9eWLo1xn4p3oYJJSNZKX2E850rxtWZGIWMYf7MQFGm3CwZKBqEkDAUJtjA/nCXMDiE1oCqs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxfSnWjqTfwpebqk668bWqOSEJ1cVy8uz27q8T33EGaKcTTFC6f
	7wIzZdoGqHsnTZUoXm0+s4+hZqn4/7vmTWeAePC2fULsM99fjtYOOqi+RDV5B1A=
X-Gm-Gg: ASbGncsKa0jWwourlFZLqTCyUIa5QXmbR6wq6eFaH2aQmAWVtj2m4JdDs5gd1edRxTc
	fid8EoGZ4/l98nuxfYh0VUGpxgLB3uWvIHfOKL69QqFqFGahgS6nfHmqUNKC81ABAfbWWuh754r
	FOT2XpDbucqcIhQgz9gwrvlSB/+mgegFQXsPJ/fHNqRGnjSOiLR4F3CP0+5phJx7kfGezUoFXOc
	dJq22gshyrUiop4ZiC7S52JDWXhcCkIAi6fMPtkM21KYbDsoQ3LMryzlN3g5Is=
X-Google-Smtp-Source: AGHT+IHsPfGH2zq/iR4xUFgiWR4xgEIUyxx91LKPnooORGN7TaXYiCEcbwR70UJ+YGh77EnlhRu3rw==
X-Received: by 2002:a05:600c:1c88:b0:434:a350:207c with SMTP id 5b1f17b1804b1-436e26e5533mr95827995e9.23.1736528417817;
        Fri, 10 Jan 2025 09:00:17 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Fri, 10 Jan 2025 17:00:15 +0000
Message-Id: <D6YJY56LLW9U.1JHBJ5DF1A8UK@cloud.com>
Cc: =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, "Stefano
 Stabellini" <sstabellini@kernel.org>, "Anthony PERARD"
 <anthony.perard@vates.tech>, "Oleksii Kurochko"
 <oleksii.kurochko@gmail.com>
Subject: Re: [PATCH] CI: Add an x86_64 Clang Randconfig job
From: "Alejandro Vallejo" <alejandro.vallejo@cloud.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>, "Xen-devel"
 <xen-devel@lists.xenproject.org>
X-Mailer: aerc 0.18.2
References: <20250110160217.183887-1-andrew.cooper3@citrix.com>
In-Reply-To: <20250110160217.183887-1-andrew.cooper3@citrix.com>

On Fri Jan 10, 2025 at 4:02 PM GMT, Andrew Cooper wrote:
> This was recently identified as a hole in testing.
>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> CC: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
> CC: Stefano Stabellini <sstabellini@kernel.org>
> CC: Anthony PERARD <anthony.perard@vates.tech>
> CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
>
> https://gitlab.com/xen-project/people/andyhhp/xen/-/jobs/8820980201
> ---
>  automation/gitlab-ci/build.yaml | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build=
.yaml
> index 3abd2a0c6575..cb84f379b754 100644
> --- a/automation/gitlab-ci/build.yaml
> +++ b/automation/gitlab-ci/build.yaml
> @@ -551,6 +551,12 @@ debian-12-x86_64-clang:
>    variables:
>      CONTAINER: debian:12-x86_64
> =20
> +debian-12-x86_64-clang-randconfig:
> +  extends: .clang-x86-64-build
> +  variables:
> +    CONTAINER: debian:12-x86_64
> +    RANDCONFIG: y
> +
>  debian-12-x86_64-gcc:
>    extends: .gcc-x86-64-build
>    variables:

  Reviewed-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 17:17:04 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 17:17:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869880.1281333 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWIcs-0000VY-5h; Fri, 10 Jan 2025 17:16:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869880.1281333; Fri, 10 Jan 2025 17:16:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWIcs-0000VR-32; Fri, 10 Jan 2025 17:16:50 +0000
Received: by outflank-mailman (input) for mailman id 869880;
 Fri, 10 Jan 2025 17:16:48 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=uskN=UC=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tWIcq-0000VL-Tb
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 17:16:48 +0000
Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com
 [2a00:1450:4864:20::342])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id abd31dcf-cf76-11ef-99a4-01e77a169b0f;
 Fri, 10 Jan 2025 18:16:46 +0100 (CET)
Received: by mail-wm1-x342.google.com with SMTP id
 5b1f17b1804b1-43635796b48so15130975e9.0
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 09:16:46 -0800 (PST)
Received: from [192.168.86.29] ([83.105.36.37])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a9362947dsm3653964f8f.40.2025.01.10.09.16.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 10 Jan 2025 09:16:45 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: abd31dcf-cf76-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736529406; x=1737134206; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ET3va3W5qodirtlnB3hmd7FzkttgNwj+uXCKjs0LgWw=;
        b=bKbz85SJmOU3yqH2i2agBHSyTxlAGcbXDK3y3UNnAsn/7iQl57AsG3ieoV7TcMKzf+
         jEJ6QyUnBxzvBYwcnM3mfB7Snm0kI661ZV7Wi+tUrUjzkRjguCa12lcBgMSYvqWx9248
         Ia1F6LwSOnWQGrRrQPh+h0vj+KWm/Tqv3qFKo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736529406; x=1737134206;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ET3va3W5qodirtlnB3hmd7FzkttgNwj+uXCKjs0LgWw=;
        b=pfrtGoN166ipaRP4uDpGomsCf7lHo9u3xXX92gHTPLe/o45ia5FnawuOZiuF+f9p7B
         nViF5TxYt/CxwXO7mBm2Z/f5bNVz+nPg9+o4WWGUoP0YMYgkBvhtQEe+4FcPzWXct/2G
         JsssP+/AF9+HTWPEb4VsIIBWNyeoMP+/33h6TEowXAojPEx1vULtMfAvk63UaFlviVDV
         z2fOHAFj7HsjsxBQci8aGqQUDkUrPFptyAxADzjg3xwkR8ItCVsmhjeOadcD+2gmXOJH
         6fJeSN/bMu3rP3XqcWyMWFdkjVWaWVTX5dY/9Lh2n9eewTzrgOm8p/Jh3S99vGdPkPAl
         RaXA==
X-Forwarded-Encrypted: i=1; AJvYcCXHZshsnR2tfE34PE8/eoDUf/wPWYjoiHKXRVycp3PQEFbi8fvn/6H3VT27UZgL9WAMHpgtx9YfyUU=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw9eQ8RbYFl9929WMgUOO1L2IBCoS2UJ6Gtxk9eNXxV7WFp3qRC
	YrghPEektAGEN4LeITcdeN/XfO3Zh1y2bjhEaoBD1Zbep+uZWOdsp1EVDXrukOE=
X-Gm-Gg: ASbGncvOVeBkVCMAEHd/I8MzdQQChYB0dJfsgNDWWw6q3VtCfr3+7tAVxo4cEswOjod
	H7atDOnMHOVVMpn4blClmRqz8q5y1G3otah+TFGJzty44vOEXRfgVuJ4vFXuwltjwKiFSy9jOK8
	hdu6gDcFX2OWnqWW/aR/JHTLtxSB+3CzsFa2sIaZzd7qOcgpwEcV1ISxODiV7R9pFoMdFi57HC9
	z6D/IWuBfGWPjBdexCJx+QZzUs0JY3VwYaeBNv6C+W1+JrQJ06cajhVRRN2f6HqzJo=
X-Google-Smtp-Source: AGHT+IEW+C0UYINtElg6dOB6egZSf2JdQKq3h/6pWVTyxYZL0mnh9eE6xvQOEQkDNwqoeA+457pHig==
X-Received: by 2002:a05:600c:4749:b0:434:f1bd:1e40 with SMTP id 5b1f17b1804b1-436e9d6ff7bmr56536635e9.6.1736529406318;
        Fri, 10 Jan 2025 09:16:46 -0800 (PST)
Message-ID: <10577192-c798-4298-98e5-bb2f33d53cd3@citrix.com>
Date: Fri, 10 Jan 2025 17:16:45 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/2] Update Xen version to 4.20-rc
To: Jan Beulich <jbeulich@suse.com>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20250109153921.43610-1-andrew.cooper3@citrix.com>
 <20250109153921.43610-3-andrew.cooper3@citrix.com>
 <67278014-8208-48f2-92ba-7b843a0d373b@suse.com>
 <c7eeaa80-a4bd-457f-824e-accd23c2f471@citrix.com>
 <bdb4a31c-01d1-4f48-82af-f3eb54cd8d69@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <bdb4a31c-01d1-4f48-82af-f3eb54cd8d69@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 09/01/2025 3:53 pm, Jan Beulich wrote:
> On 09.01.2025 16:46, Andrew Cooper wrote:
>> On 09/01/2025 3:44 pm, Jan Beulich wrote:
>>> On 09.01.2025 16:39, Andrew Cooper wrote:
>>>> --- a/README
>>>> +++ b/README
>>>> @@ -1,11 +1,11 @@
>>>> -############################################################
>>>> -__  __                                _        _     _
>>>> -\ \/ /___ _ __        _   _ _ __  ___| |_ __ _| |__ | | ___
>>>> - \  // _ \ '_ \ _____| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
>>>> - /  \  __/ | | |_____| |_| | | | \__ \ || (_| | |_) | |  __/
>>>> -/_/\_\___|_| |_|      \__,_|_| |_|___/\__\__,_|_.__/|_|\___|
>>>> -
>>>> -############################################################
>>>> +#####################################################
>>>> +__  __            _  _    ____   ___
>>>> +\ \/ /___ _ __   | || |  |___ \ / _ \       _ __ ___
>>>> + \  // _ \ '_ \  | || |_   __) | | | |_____| '__/ __|
>>>> + /  \  __/ | | | |__   _| / __/| |_| |_____| | | (__
>>>> +/_/\_\___|_| |_|    |_|(_)_____|\___/      |_|  \___|
>>>> +
>>>> +#####################################################
>>>>  
>>>>  https://www.xen.org/
>>>>  
>>>> --- a/SUPPORT.md
>>>> +++ b/SUPPORT.md
>>>> @@ -9,7 +9,7 @@ for the definitions of the support status levels etc.
>>>>  
>>>>  # Release Support
>>>>  
>>>> -    Xen-Version: 4.20-unstable
>>>> +    Xen-Version: 4.20-rc
>>>>      Initial-Release: n/a
>>>>      Supported-Until: TBD
>>>>      Security-Support-Until: Unreleased - not yet security-supported
>>>> --- a/xen/Makefile
>>>> +++ b/xen/Makefile
>>>> @@ -6,7 +6,7 @@ this-makefile := $(call lastword,$(MAKEFILE_LIST))
>>>>  # All other places this is stored (eg. compile.h) should be autogenerated.
>>>>  export XEN_VERSION       = 4
>>>>  export XEN_SUBVERSION    = 20
>>>> -export XEN_EXTRAVERSION ?= -unstable$(XEN_VENDORVERSION)
>>>> +export XEN_EXTRAVERSION ?= .0-rc$(XEN_VENDORVERSION)
>>> Since we'd been there before I take it the .0 in here (which isn't in the
>>> changes to the other two files) is deliberate now? Clearly I continue to
>>> think it shouldn't be put there together with -rc.
>> Oh, that's because I cribbed this by looking at the recent releases.
>>
>> The documentation leaves ~everything to be desired...
>>
>> I can drop the .0 here, although I shan't repost just for that.
> In case this (both patches) requires any ack:
> Acked-by: Jan Beulich <jbeulich@suse.com>

It turns out the .0 is necessary to build the tarball in the way the
other tooling expects.  I'm going to bodge it for now to get RC1 out,
but we are going to have to change *somthing* before getting to RC2.

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 17:46:28 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 17:46:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869893.1281343 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWJ5Q-00052C-4v; Fri, 10 Jan 2025 17:46:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869893.1281343; Fri, 10 Jan 2025 17:46:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWJ5Q-000524-2R; Fri, 10 Jan 2025 17:46:20 +0000
Received: by outflank-mailman (input) for mailman id 869893;
 Fri, 10 Jan 2025 17:46:18 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=hl4S=UC=gmail.com=inisider@srs-se1.protection.inumbo.net>)
 id 1tWJ5O-00051g-Te
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 17:46:18 +0000
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com
 [2a00:1450:4864:20::129])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c8698815-cf7a-11ef-99a4-01e77a169b0f;
 Fri, 10 Jan 2025 18:46:14 +0100 (CET)
Received: by mail-lf1-x129.google.com with SMTP id
 2adb3069b0e04-5401bd6ccadso2304638e87.2; 
 Fri, 10 Jan 2025 09:46:12 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5428bec0664sm598754e87.193.2025.01.10.09.46.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 10 Jan 2025 09:46:09 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c8698815-cf7a-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736531172; x=1737135972; darn=lists.xenproject.org;
        h=subject:from:cc:to:content-language:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=2uLwHxKIE8Flro4+3aVb5JHjHe6Cl/VATUVw80eks/o=;
        b=mg1YPqnUhz7+xWQUL8bV0wP3KBNPrghrPR9SYBnvsBPOvFWXHRKCsGOr8DUKGUY5rB
         Bq0fLci/ZSXix9SlhQ7eAzNUOfOkLpMYjNwq4gORahqCrqTJ26Q0UcbwCYty+p3h6uJQ
         5sDrdJVnDLPl4K+05Nt2RuAoFVtbuZBkscDVnpcZeNoeMXaLnwyZCEhyYCZrQheaPe9P
         5iriKawWJNvU+dUpOH5c31Do9cPKGZufQ7uSwPk330dPkN4aygf2NkSiWzqdlTf5vdp6
         OaYa3FiV54IzrdQ3w8QMP18ByczxOrhROBKsYa0MbXi2kd18H6Zk13qofcw3ZdI1wLsE
         qtNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736531172; x=1737135972;
        h=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=2uLwHxKIE8Flro4+3aVb5JHjHe6Cl/VATUVw80eks/o=;
        b=OXxfKLudPjpIIpndWwW5+2+Bff4iXyqdiPFsJC54n4P6YtKB2vsmJlqKnbkWdlzA8R
         wu8vBEpjqzWXNpL66a++nR2uUPXU7gp5iLlhsFO0HhtSF66jgInbjCaeLy8mAfQUgcST
         sJgoLE5UjQBfwtVZWPN5Mi+a3QwJCaWDO0tCfXt4ULXSyEbl//dJLn+pHXEDzWcIlONS
         uTP+oS0Cy0eT4Wi11Pm98uBP0KokggL9m3DuXAiUeYzpDpKCeVVjj2BuQEG8y4uY1m6T
         DlYcZGCKGPhq9XKh+ZFrYnmstEXfCtwirJBx7liF8JSNJ1nRF0n7O2ECx6XDTfRdGGyc
         pYOA==
X-Forwarded-Encrypted: i=1; AJvYcCUlZ6glAvMtQBuC1MqSy1E/09K2uE7Yw00YwqsODg+uyjftAXV2uYSSYKqd1gOr/fYEn6Rj9MmZHkoRaBI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwRWXcvBPvAgLTU7h4uilmUfu0HhJZ/LNz87rRfO0nadl7yl3M+
	806Fx97XuKP7rtNJNfVf+mvhApxxFpb1QefWDbs772m+DekIFtfZLhClyFLt
X-Gm-Gg: ASbGnctxB3NqNORxjpxkLZZ2xw1RUDmcO90oKIpxqqU/3ZHTUIdaum9B3T5Feb4T3Zj
	RCfylL3Y1Cza+3fTaJEyKVTL/nL/w+6B1UgSm3Ss1yuyOzuZSuiyUMMmLU/j260hpClS23NKgWq
	cCa5rlFLXWyoo4tktYu5MeQO5prxoVyssNo6pzfLJJdR80q1GXhjVs7l0sKqnwQ0Pstj36V2Tqf
	iogBXavkx9eQIGd4MCYrsowngHP0tvos7C25mKvuwyEGm1whV7jf22v2eE=
X-Google-Smtp-Source: AGHT+IGQGXMKgnOv4/H/hO3+1TyFo/8EFk6d9QMQZTUbkIGwwKQwomaxbI2SagGkLY/NkWuphbIlXA==
X-Received: by 2002:a05:6512:3049:b0:542:297f:4f65 with SMTP id 2adb3069b0e04-54284450352mr3928821e87.0.1736531171379;
        Fri, 10 Jan 2025 09:46:11 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------R0yv0aq2cjlHE01ISJyTQsiw"
Message-ID: <4c90bca8-997a-43d2-a0e0-963ac5555b93@gmail.com>
Date: Fri, 10 Jan 2025 18:46:07 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: xen-users@lists.xenproject.org, xen-announce@lists.xenproject.org,
 Community Manager <community.manager@xenproject.org>,
 committers@xenproject.org
From: Oleksii Kurochko <inisider@gmail.com>
Subject: [ANNOUNCEMENT] Xen 4.20.0-rc1 is tagged

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

Hi all,

Xen 4.20 rc1 is tagged. You can check that out from xen.git:

git://xenbits.xen.org/xen.git 4.20.0-rc1

For your convenience there is also a tarball and the signature at:
https://downloads.xenproject.org/release/xen/4.20.0-rc1/xen-4.20.0-rc1.tar.gz <https://downloads.xenproject.org/release/xen/4.19.0-rc1/xen-4.19.0-rc1.tar.gz>

And the signature is at:
https://downloads.xenproject.org/release/xen/4.20.0-rc1/xen-4.20.0-rc1.tar.gz.sig <https://downloads.xenproject.org/release/xen/4.19.0-rc1/xen-4.19.0-rc1.tar.gz.sig>

Please send bug reports and test reports to
xen-devel@lists.xenproject.org<mailto:xen-devel@lists.xenproject.org>.
When sending bug reports, please CC relevant maintainers and me
(oleskii.kurochko@gmail.com<mailto:oleskii.kurochko@gmail.com).

Best regards,
  Oleksii

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

<!DOCTYPE html>
<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <pre id="b"
style="font-size: 13px; font-family: monospace; background: rgb(255, 255, 255); color: rgb(0, 0, 51); white-space: pre-wrap; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">Hi all,

Xen 4.20 rc1 is tagged. You can check that out from xen.git:

git://xenbits.xen.org/xen.git 4.20.0-rc1

For your convenience there is also a tarball and the signature at:
<a
href="https://downloads.xenproject.org/release/xen/4.19.0-rc1/xen-4.19.0-rc1.tar.gz"
style="font-size: 13px; font-family: monospace; background: rgb(255, 255, 255); color: rgb(0, 0, 255); text-decoration: none;">https://downloads.xenproject.org/release/xen/4.20.0-rc1/xen-4.20.0-rc1.tar.gz</a>

And the signature is at:
<a
href="https://downloads.xenproject.org/release/xen/4.19.0-rc1/xen-4.19.0-rc1.tar.gz.sig"
style="font-size: 13px; font-family: monospace; background: rgb(255, 255, 255); color: rgb(0, 0, 255); text-decoration: none;">https://downloads.xenproject.org/release/xen/4.20.0-rc1/xen-4.20.0-rc1.tar.gz.sig</a>

Please send bug reports and test reports to
<a class="moz-txt-link-abbreviated" href="mailto:xen-devel@lists.xenproject.org">xen-devel@lists.xenproject.org</a><a class="moz-txt-link-rfc2396E" href="mailto:xen-devel@lists.xenproject.org">&lt;mailto:xen-devel@lists.xenproject.org&gt;</a>.
When sending bug reports, please CC relevant maintainers and me
(<a class="moz-txt-link-abbreviated" href="mailto:oleskii.kurochko@gmail.com">oleskii.kurochko@gmail.com</a>&lt;<a class="moz-txt-link-freetext" href="mailto:oleskii.kurochko@gmail.com">mailto:oleskii.kurochko@gmail.com</a>).

Best regards,
 Oleksii</pre>
    <p></p>
  </body>
</html>

--------------R0yv0aq2cjlHE01ISJyTQsiw--


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 18:28:02 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 18:28:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869928.1281367 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWJjV-0003Qy-Gb; Fri, 10 Jan 2025 18:27:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869928.1281367; Fri, 10 Jan 2025 18:27:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWJjV-0003Qr-B5; Fri, 10 Jan 2025 18:27:45 +0000
Received: by outflank-mailman (input) for mailman id 869928;
 Fri, 10 Jan 2025 18:27: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
 <SRS0=1vlD=UC=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tWJjT-0003QV-DZ
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 18:27:43 +0000
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com
 [2a00:1450:4864:20::12e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9348f1c0-cf80-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 19:27:41 +0100 (CET)
Received: by mail-lf1-x12e.google.com with SMTP id
 2adb3069b0e04-53ff1f7caaeso2403007e87.0; 
 Fri, 10 Jan 2025 10:27:40 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5428be49e18sm600334e87.31.2025.01.10.10.27.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 10 Jan 2025 10:27:39 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9348f1c0-cf80-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736533660; x=1737138460; darn=lists.xenproject.org;
        h=in-reply-to:content-language:references:cc:to:from:subject
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=sJU6nsxiXJxqV9ClbAa3IjgowBH3TtQdk3f7AL4Hbmo=;
        b=U6LDwRWeNOFnRIdvCzWR+elaUezvIdXK9yhoONDcynmQnwdwBAi9jsEbhIQyyD490u
         8nv8TgfAaKQqpcaNwT/DmvJz5gDGzaEqHRpOmWA0tsTtUWo5TmPi33QukURKlxmV/LDl
         1vs2IvvwE8VQ83Pve66on82mop2SK84L9vweRR/x6iVUSpZ7Saen70W17r7cYReE8hHh
         f1+VgypCqcEMM4Ynj3oT0E9WBIdJsBoYO3cmzjd3tQUcHUASQdAuM8sa7TmMf7s0Cdun
         CLDz+sDe0fz5jm0Tebax478Y/QqPS8NhV9vDi8E05gdkj4yksxI5DGfFsx8+sLIY2Zsq
         9+cA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736533660; x=1737138460;
        h=in-reply-to:content-language:references:cc:to:from:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=sJU6nsxiXJxqV9ClbAa3IjgowBH3TtQdk3f7AL4Hbmo=;
        b=JqsJCHdV3f4tutGI5kF0Hro1JSuEjYkcK5BMdfI2kQs5hdmt65F9vlolSurUTe7Keh
         vGLhbZpVnGkraQrjVHBZ0AwmIrywZwqLiQNc08ToPCvcLLDPwZCayrNRsc7qy54rm87e
         CrDR+zZ8jOsVShsNzyXwWwlqvzGANZR90iKxhM+EAQvpNzWcQNf71Rv0AZQSvXtRmokU
         M9u524WMATOCKLqQR4qVUInmF+JW7E92Dc6+ValDiRZ5s9j/8KM88Qb8SPDHFFJ6CnK6
         cstsE8zK85VN840LWqGl2CgIX6eEWg+AVPeE5JwmLKzzvUYHKh3bfkcxXxSx8qZ4Z/gj
         X49Q==
X-Forwarded-Encrypted: i=1; AJvYcCXtQiYqhy4ZvApmZE1GoDzDaj4NrxIqrVzeo3zUgP/8Vul3qg+r8bZCMMy2RubHnBh9GJ8jGWAV75HwQeg=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yypufwswe4pLHWzCperCV/NoeDTC57NqbKKe7vTo1G0Q47CA1xR
	cwHxu7DMO0nchQHjDqY0LYBk8RA4FfAX/XYGOxD7sYVhM5AFNcrHIkQ0Rw==
X-Gm-Gg: ASbGncvzCbcpcKm/vBn8/yAu6hhzZSovMPQ8qNA2Zk9DriJuBqYNZQGqcSeAAYlZxYU
	24BK1KERq1HlSkquZtXvwJ9WohOAbCh03tdkoortiCU5LFAXvpUZ1zs8lvooEi20XUmI8puKwhw
	DEHPLBhnOALeNIm4FkUWGgWaaNBv0IncqakBqES4g55sudxOgchuNk2hpaRkKco6a9RGI5ShHll
	KkvTmT1+eEwkiI6ncB3i7AF9OkIk8xkVKF+YileWRSL5ev05Hm9y+mpfogpA0Mu0TbggA==
X-Google-Smtp-Source: AGHT+IEcQCkVV81W0EPT6eAwxj6CsW3xFoMewrcwmZ23migfLB+tXncZV+lLbRepxQuh9+DG+f00yg==
X-Received: by 2002:a05:6512:23aa:b0:53f:167e:390f with SMTP id 2adb3069b0e04-542845c089cmr3171218e87.53.1736533659603;
        Fri, 10 Jan 2025 10:27:39 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------Qa1tvSDmwNToFT4yR1BXsx6y"
Message-ID: <35db8072-4da2-44dd-9167-fa1211f5e8d5@gmail.com>
Date: Fri, 10 Jan 2025 19:27:38 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [ANNOUNCEMENT] Xen 4.20.0-rc1 is tagged
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: xen-users@lists.xenproject.org, xen-announce@lists.xenproject.org,
 Community Manager <community.manager@xenproject.org>,
 committers@xenproject.org
References: <4c90bca8-997a-43d2-a0e0-963ac5555b93@gmail.com>
Content-Language: en-US
In-Reply-To: <4c90bca8-997a-43d2-a0e0-963ac5555b93@gmail.com>

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

Sorry for inconvenience but I did something wrong with link location in my e-mail application.

Please find the corrected links below:

On 1/10/25 6:46 PM, Oleksii Kurochko wrote:
> Hi all,
>
> Xen 4.20 rc1 is tagged. You can check that out from xen.git:
>
> git://xenbits.xen.org/xen.git 4.20.0-rc1
>
> For your convenience there is also a tarball and the signature at:
> https://downloads.xenproject.org/release/xen/4.20.0-rc1/xen-4.20.0-rc1.tar.gz
>
> And the signature is at:
> https://downloads.xenproject.org/release/xen/4.20.0-rc1/xen-4.20.0-rc1.tar.gz.sig

Corrected links:

For your convenience there is also a tarball and the signature at:
https://downloads.xenproject.org/release/xen/4.20.0-rc1/xen-4.20.0-rc1.tar.gz

And the signature is at:
https://downloads.xenproject.org/release/xen/4.20.0-rc1/xen-4.20.0-rc1.tar.gz.sig

Have a nice weekends.

~ Oleksii

> Please send bug reports and test reports to
> xen-devel@lists.xenproject.org<mailto:xen-devel@lists.xenproject.org>.
> When sending bug reports, please CC relevant maintainers and me
> (oleskii.kurochko@gmail.com<mailto:oleskii.kurochko@gmail.com).
>
> Best regards,
>   Oleksii
--------------Qa1tvSDmwNToFT4yR1BXsx6y
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <pre>Sorry for inconvenience but I did something wrong with link location in my e-mail application.</pre>
    <pre>Please find the corrected links below:

</pre>
    <div class="moz-cite-prefix">On 1/10/25 6:46 PM, Oleksii Kurochko
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:4c90bca8-997a-43d2-a0e0-963ac5555b93@gmail.com">
      <pre id="b"
style="font-size: 13px; font-family: monospace; background: rgb(255, 255, 255); color: rgb(0, 0, 51); white-space: pre-wrap; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">Hi all,

Xen 4.20 rc1 is tagged. You can check that out from xen.git:

git://xenbits.xen.org/xen.git 4.20.0-rc1

For your convenience there is also a tarball and the signature at:
<a
href="https://downloads.xenproject.org/release/xen/4.20.0-rc1/xen-4.20.0-rc1.tar.gz"
style="font-size: 13px; font-family: monospace; background: rgb(255, 255, 255); color: rgb(0, 0, 255); text-decoration: none;"
      class="moz-txt-link-freetext">https://downloads.xenproject.org/release/xen/4.20.0-rc1/xen-4.20.0-rc1.tar.gz</a>

And the signature is at:
<a
href="https://downloads.xenproject.org/release/xen/4.20.0-rc1/xen-4.20.0-rc1.tar.gz.sig"
style="font-size: 13px; font-family: monospace; background: rgb(255, 255, 255); color: rgb(0, 0, 255); text-decoration: none;"
      class="moz-txt-link-freetext">https://downloads.xenproject.org/release/xen/4.20.0-rc1/xen-4.20.0-rc1.tar.gz.sig</a>
</pre>
    </blockquote>
    <pre>Corrected links:</pre>
    <pre id="b"
style="font-size: 13px; font-family: monospace; background: rgb(255, 255, 255); color: rgb(0, 0, 51); white-space: pre-wrap; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">For your convenience there is also a tarball and the signature at:
<a
href="https://downloads.xenproject.org/release/xen/4.20.0-rc1/xen-4.20.0-rc1.tar.gz"
style="font-size: 13px; font-family: monospace; background: rgb(255, 255, 255); color: rgb(0, 0, 255); text-decoration: none;"
    moz-do-not-send="true" class="moz-txt-link-freetext">https://downloads.xenproject.org/release/xen/4.20.0-rc1/xen-4.20.0-rc1.tar.gz</a>

And the signature is at:
<a
href="https://downloads.xenproject.org/release/xen/4.20.0-rc1/xen-4.20.0-rc1.tar.gz.sig"
style="font-size: 13px; font-family: monospace; background: rgb(255, 255, 255); color: rgb(0, 0, 255); text-decoration: none;"
    class="moz-txt-link-freetext">https://downloads.xenproject.org/release/xen/4.20.0-rc1/xen-4.20.0-rc1.tar.gz.sig</a>

Have a nice weekends.

</pre>
    <p></p>
    <pre>~ Oleksii

</pre>
    <blockquote type="cite"
      cite="mid:4c90bca8-997a-43d2-a0e0-963ac5555b93@gmail.com">
      <pre id="b"
style="font-size: 13px; font-family: monospace; background: rgb(255, 255, 255); color: rgb(0, 0, 51); white-space: pre-wrap; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">Please send bug reports and test reports to
<a class="moz-txt-link-abbreviated moz-txt-link-freetext"
      href="mailto:xen-devel@lists.xenproject.org">xen-devel@lists.xenproject.org</a><a
      class="moz-txt-link-rfc2396E"
      href="mailto:xen-devel@lists.xenproject.org">&lt;mailto:xen-devel@lists.xenproject.org&gt;</a>.
When sending bug reports, please CC relevant maintainers and me
(<a class="moz-txt-link-abbreviated moz-txt-link-freetext"
      href="mailto:oleskii.kurochko@gmail.com">oleskii.kurochko@gmail.com</a>&lt;<a
      class="moz-txt-link-freetext"
      href="mailto:oleskii.kurochko@gmail.com">mailto:oleskii.kurochko@gmail.com</a>).

Best regards,
 Oleksii</pre>
    </blockquote>
  </body>
</html>

--------------Qa1tvSDmwNToFT4yR1BXsx6y--


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 18:37:44 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 18:37:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869878.1281376 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWJt6-0005LX-Fi; Fri, 10 Jan 2025 18:37:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869878.1281376; Fri, 10 Jan 2025 18:37:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWJt6-0005LQ-C9; Fri, 10 Jan 2025 18:37:40 +0000
Received: by outflank-mailman (input) for mailman id 869878;
 Fri, 10 Jan 2025 17:14:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Xnyy=UC=intel.com=ashutosh.dixit@srs-se1.protection.inumbo.net>)
 id 1tWIaC-0000KG-1a
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 17:14:04 +0000
Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.21])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 47c8f5bd-cf76-11ef-99a4-01e77a169b0f;
 Fri, 10 Jan 2025 18:14:00 +0100 (CET)
Received: from fmviesa002.fm.intel.com ([10.60.135.142])
 by orvoesa113.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 10 Jan 2025 09:13:58 -0800
Received: from orsosgc001.jf.intel.com (HELO orsosgc001.intel.com)
 ([10.165.21.142])
 by fmviesa002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 10 Jan 2025 09:13:57 -0800
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 47c8f5bd-cf76-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=intel.com; i=@intel.com; q=dns/txt; s=Intel;
  t=1736529240; x=1768065240;
  h=date:message-id:from:to:cc:subject:in-reply-to:
   references:mime-version;
  bh=zCD9wMt7oj+kJBhlIcsVVTGT43QE2wPIyfO0mHZuo3E=;
  b=hWvPm9S9gyyWflhxezAJQ0/Zw5EZKsCuAkNL9pt9ibrxvKhfx8igBLau
   BqAxt/w+4WkhB7JJeGhd2XKu7BTEUI/u+ZCjJZLax3klENzioM0Ogu8lV
   PfZO/Ur9FgiISKQAktuwXDv+fKDWBBLhsHE3nTEvd7HEfk5ILPMEy+C+i
   v7E/Bn3dcZExGuv+WXwcKSpdB8KGwD5qn3eKJp4zYHR+m82wlFlpFSVej
   Zj+F+2HJbkF1YqnKygWuQDJ/VUu15h2UnCLWYzcjwzwNjZ/0bri7MxpqP
   ws6x4YtpsaSIYSiiMKXJNlfXHbNtrSTP7okJPY7QFGY+mFzAY/yI1B5Pm
   Q==;
X-CSE-ConnectionGUID: Oxcoox4ZRIip59qh+Arovg==
X-CSE-MsgGUID: nRtBEkHYQuuOyF8IO0ne4A==
X-IronPort-AV: E=McAfee;i="6700,10204,11311"; a="36712478"
X-IronPort-AV: E=Sophos;i="6.12,303,1728975600"; 
   d="scan'208";a="36712478"
X-CSE-ConnectionGUID: d+N1H3FPQryemumCSoERgQ==
X-CSE-MsgGUID: skCK+1HISZSgobnkHZdoJg==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="6.12,224,1728975600"; 
   d="scan'208";a="127073384"
Date: Fri, 10 Jan 2025 09:13:56 -0800
Message-ID: <8534hqvbfv.wl-ashutosh.dixit@intel.com>
From: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
To: Joel Granados <joel.granados@kernel.org>
Cc: Thomas =?ISO-8859-1?Q?Wei=DFschuh?= <linux@weissschuh.net>,	Kees Cook
 <kees@kernel.org>,	Luis Chamberlain <mcgrof@kernel.org>,
	linux-arm-kernel@lists.infradead.org,	linux-kernel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,	linux-riscv@lists.infradead.org,
	linux-s390@vger.kernel.org,	linux-crypto@vger.kernel.org,
	openipmi-developer@lists.sourceforge.net,	intel-gfx@lists.freedesktop.org,
	dri-devel@lists.freedesktop.org,	intel-xe@lists.freedesktop.org,
	linux-hyperv@vger.kernel.org,	linux-rdma@vger.kernel.org,
	linux-raid@vger.kernel.org,	linux-scsi@vger.kernel.org,
	linux-serial@vger.kernel.org,	xen-devel@lists.xenproject.org,
	linux-aio@kvack.org,	linux-fsdevel@vger.kernel.org,	netfs@lists.linux.dev,
	codalist@coda.cs.cmu.edu,	linux-mm@kvack.org,	linux-nfs@vger.kernel.org,
	ocfs2-devel@lists.linux.dev,	fsverity@lists.linux.dev,
	linux-xfs@vger.kernel.org,	io-uring@vger.kernel.org,	bpf@vger.kernel.org,
	kexec@lists.infradead.org,	linux-trace-kernel@vger.kernel.org,
	linux-hardening@vger.kernel.org,	apparmor@lists.ubuntu.com,
	linux-security-module@vger.kernel.org,	keyrings@vger.kernel.org
Subject: Re: [PATCH] treewide: const qualify ctl_tables where applicable
In-Reply-To: <20250109-jag-ctl_table_const-v1-1-622aea7230cf@kernel.org>
References: <20250109-jag-ctl_table_const-v1-1-622aea7230cf@kernel.org>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue)
 FLIM-LB/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL-LB/10.8 EasyPG/1.0.0
 Emacs/28.2 (x86_64-redhat-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII

On Thu, 09 Jan 2025 05:16:39 -0800, Joel Granados wrote:
>
> diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
> index 2406cda75b7b..5384d1bb4923 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -4802,7 +4802,7 @@ int i915_perf_remove_config_ioctl(struct drm_device *dev, void *data,
>	return ret;
>  }
>
> -static struct ctl_table oa_table[] = {
> +static const struct ctl_table oa_table[] = {
>	{
>	 .procname = "perf_stream_paranoid",
>	 .data = &i915_perf_stream_paranoid,
> diff --git a/drivers/gpu/drm/xe/xe_observation.c b/drivers/gpu/drm/xe/xe_observation.c
> index 8ec1b84cbb9e..57cf01efc07f 100644
> --- a/drivers/gpu/drm/xe/xe_observation.c
> +++ b/drivers/gpu/drm/xe/xe_observation.c
> @@ -56,7 +56,7 @@ int xe_observation_ioctl(struct drm_device *dev, void *data, struct drm_file *fi
>	}
>  }
>
> -static struct ctl_table observation_ctl_table[] = {
> +static const struct ctl_table observation_ctl_table[] = {
>	{
>	 .procname = "observation_paranoid",
>	 .data = &xe_observation_paranoid,

For i915 and xe:

Acked-by: Ashutosh Dixit <ashutosh.dixit@intel.com>


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 18:37:44 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 18:37:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869939.1281389 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWJt7-0005Ve-2v; Fri, 10 Jan 2025 18:37:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869939.1281389; Fri, 10 Jan 2025 18:37:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWJt6-0005T0-Ry; Fri, 10 Jan 2025 18:37:40 +0000
Received: by outflank-mailman (input) for mailman id 869939;
 Fri, 10 Jan 2025 18:29: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
 <SRS0=EndO=UC=oracle.com=anna.schumaker@srs-se1.protection.inumbo.net>)
 id 1tWJld-0003z2-PW
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 18:29:58 +0000
Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com
 [205.220.165.32]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e2388cd4-cf80-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 19:29:54 +0100 (CET)
Received: from pps.filterd (m0246617.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 50AENVpw011181;
 Fri, 10 Jan 2025 18:28:36 GMT
Received: from iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com
 (iadpaimrmta03.appoci.oracle.com [130.35.103.27])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 442gy5tfaa-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Fri, 10 Jan 2025 18:28:35 +0000 (GMT)
Received: from pps.filterd
 (iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
 by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.2/8.18.1.2)
 with ESMTP id 50AI03Ra010741; Fri, 10 Jan 2025 18:28:33 GMT
Received: from nam12-mw2-obe.outbound.protection.outlook.com
 (mail-mw2nam12lp2042.outbound.protection.outlook.com [104.47.66.42])
 by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id
 43xuecmagc-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Fri, 10 Jan 2025 18:28:33 +0000
Received: from BY5PR10MB4290.namprd10.prod.outlook.com (2603:10b6:a03:203::15)
 by SA3PR10MB7070.namprd10.prod.outlook.com (2603:10b6:806:311::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8314.17; Fri, 10 Jan
 2025 18:28:20 +0000
Received: from BY5PR10MB4290.namprd10.prod.outlook.com
 ([fe80::8c24:37e7:b737:8ba5]) by BY5PR10MB4290.namprd10.prod.outlook.com
 ([fe80::8c24:37e7:b737:8ba5%4]) with mapi id 15.20.8335.012; Fri, 10 Jan 2025
 18:28:20 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e2388cd4-cf80-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=
	corp-2023-11-20; bh=W7mtJ3WCcffux8eqMD/ETD2swTMDIpFx4tMiUR+oRt0=; b=
	QIYAEDR4m7xulzGoWGMBZHAq//9iln73Lyrgg5cWT1PnanJccaeFx3dHV19chYTt
	KZ+kZXf2G3Nd5kHses2yyNWfZMDTun0plKqh93cj21FixKBNF3FVN3Dk4S8z5U3p
	wutfd+eBvcj0aAnft9C6RW2T25BtLoDQd1UtgzFoAypcFhZzBmtYjbrr2f31xkBo
	uRHELcc4ymfIW32P9NX7KSRdsQ+BJ+vcjmOOXmxBVJDlwDgrxZLbDMssn2qDxPQx
	Nq9jhTAIIu493S0f4Kq6sD3xWCc5r8smKgYXr1ImFg1iP+6l+8UNqpJfDBH+rzWD
	AmT/fbDAIGdn0i4iuVLTXQ==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=uqS01L7ITl19F1Rdy06zyJECe8yNOk+e9h0rNFukUXxFJDtKDLkFvoodL+YkuANaltHVCqbfFb1R6/VKxVUEO6FBqVetuoBuuGVaWqEP2QyJ5t6u/S9m99mVbNPULN1MIL0a4Y0qmWqeVvpq24y/Ad7i+o+wt/fDIoCDIcj1s8vWXjV+mQ1J2ZsLHWbRijzLvJIa/FvxCafVZM3gfwtlNtkqT6NkChyp8Bd4iMhEJ03DWzxtvpIKV+kIMZW7Vn9tZCh95MHoubVYDD6RpKW+NOHYGQkZKor0p6EVLy8d6KzoJQ76+mWtvIklZZHpmvaybuBCO2JAXvOZTKu9EsY2Jw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=W7mtJ3WCcffux8eqMD/ETD2swTMDIpFx4tMiUR+oRt0=;
 b=JFtHSOXPFImBK1oyOTQqG8S3UZHfDN5PO3ur9o7yaq90JKi+JxZLCW27Pw53aSTXE1+4PXt1dKO+DHUCtpVWbNVUuqIb6tRThuPlKxbdbLfljEy8+wtX5rolArWcCwFoNAexnO4RcPFcc/TSma+42nt8yLak+Owf7Xbo4cserWZ9wO0nymva5HC1A89jM4vbuGPWA17DCT5B/Mn9RawtI1ruc5SZK0HO4lRGLTQEyaDWYebw2+Rwm74p3g6w7sU2VximsN2FPH9sBhADWYOP3H0oNQic3B66CF6pFLoBH2oeofs1wI66CJFNIaDwv5gDLY06Xj3dYp8zPIpr208jiw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
 dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=W7mtJ3WCcffux8eqMD/ETD2swTMDIpFx4tMiUR+oRt0=;
 b=DtgGhm1ZEwE0FIgKigdoEgK7pGcSmJ/XNfQFP/eWgpuhoxf9ihGj3F2Cz02gb94M9pjiamJ5uyLVGeIpUaVvF6Zmo9HFY5Y6odez8lrzE3q8m6dG/CXIBYNiY/Gg4LSlQzW51+3WniYR68gwkaCVY5OiMa8jx21kSJ7HuIZV33Y=
Message-ID: <01938969-7e33-4f0b-9795-902ef820e2b9@oracle.com>
Date: Fri, 10 Jan 2025 13:28:14 -0500
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] treewide: const qualify ctl_tables where applicable
To: Joel Granados <joel.granados@kernel.org>,
        =?UTF-8?Q?Thomas_Wei=C3=9Fschuh?= <linux@weissschuh.net>,
        Kees Cook <kees@kernel.org>, Luis Chamberlain <mcgrof@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
        linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,
        linux-s390@vger.kernel.org, linux-crypto@vger.kernel.org,
        openipmi-developer@lists.sourceforge.net,
        intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
        intel-xe@lists.freedesktop.org, linux-hyperv@vger.kernel.org,
        linux-rdma@vger.kernel.org, linux-raid@vger.kernel.org,
        linux-scsi@vger.kernel.org, linux-serial@vger.kernel.org,
        xen-devel@lists.xenproject.org, linux-aio@kvack.org,
        linux-fsdevel@vger.kernel.org, netfs@lists.linux.dev,
        codalist@coda.cs.cmu.edu, linux-mm@kvack.org,
        linux-nfs@vger.kernel.org, ocfs2-devel@lists.linux.dev,
        fsverity@lists.linux.dev, linux-xfs@vger.kernel.org,
        io-uring@vger.kernel.org, bpf@vger.kernel.org,
        kexec@lists.infradead.org, linux-trace-kernel@vger.kernel.org,
        linux-hardening@vger.kernel.org, apparmor@lists.ubuntu.com,
        linux-security-module@vger.kernel.org, keyrings@vger.kernel.org,
        Song Liu <song@kernel.org>,
        "Steven Rostedt (Google)" <rostedt@goodmis.org>,
        "Martin K. Petersen" <martin.petersen@oracle.com>,
        "Darrick J. Wong" <djwong@kernel.org>,
        Jani Nikula <jani.nikula@intel.com>,
        Corey Minyard <cminyard@mvista.com>
References: <20250110-jag-ctl_table_const-v2-1-0000e1663144@kernel.org>
Content-Language: en-US
From: Anna Schumaker <anna.schumaker@oracle.com>
Organization: Oracle Corporation
In-Reply-To: <20250110-jag-ctl_table_const-v2-1-0000e1663144@kernel.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: CH5P220CA0012.NAMP220.PROD.OUTLOOK.COM
 (2603:10b6:610:1ef::24) To BY5PR10MB4290.namprd10.prod.outlook.com
 (2603:10b6:a03:203::15)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BY5PR10MB4290:EE_|SA3PR10MB7070:EE_
X-MS-Office365-Filtering-Correlation-Id: 4cf3f591-697e-4fec-7b51-08dd31a48ed6
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|1800799024|7416014|366016|10070799003|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?R3FnS01kbzJzK1VNaXlVbkh0Q3JrWlEvQkYvUEhMUVpRVVFLOTV6OWRRWVBt?=
 =?utf-8?B?UG4ySzNCYjZhbDF3Y3lJeDBHc1BxOUl6cU9CY3FMc0kvcURsNEFZa2NoUUdU?=
 =?utf-8?B?c2E3SDZPc0xSOVFWRlVlMGxqL1k4VTREZzNHc2dpK1hlSjZHNEZLVFNvYzVN?=
 =?utf-8?B?QW84NmpTT3ZkMFRWYkR3QzgwY1pLTGJiSlpwSVNlNTBvTC90dFkrY0Y0YnE1?=
 =?utf-8?B?aENWdFh0L09JUUNtaHVTdkZVRVhUNExHWU1nT2xMc1R1RjJMK3lNTHpnMDNw?=
 =?utf-8?B?a3M1TUVOcU9teUxRdUZaYVMyTDRJMGZMWVpYWkFTcUtjTkpGd3dLRGs4VTU2?=
 =?utf-8?B?YU1EVlBQQk41MXJDSW5RdGQybFh6OC9zQW9TSVFHemRheVVFZHcvUVFrV25Z?=
 =?utf-8?B?ZDA5MFV1dzU0ZkxmVEtWZjdlK2I0WHhDK1d0TUNmTFp6bGxiN1kydlhjR285?=
 =?utf-8?B?MXVZU3pjOVpLYndNR2hwUnZZTXFQRUlpVXpXcTlmSUJ1aFg5ZitqT0RyYzU4?=
 =?utf-8?B?aHNJL1dvZ1JjalZVQmx5QzFZa1ZuVFpJVFVvRll1cTJuTkh4UDFHbm1FVVNK?=
 =?utf-8?B?aGNZS2xMMHZLc05uKzc4NXhDUk84dEJvRWdUazZPREVleVhCblZhSVZNdXNm?=
 =?utf-8?B?ZURPSmc4MDBwWkNPaS96Q1dQTDFvYkxXelliY3VCQlpFaUtqYUdxVDQ3TlVo?=
 =?utf-8?B?RzkzRnJHQ0RKaDdjWkxzYUVsd2NDVXBKdjEwS1BMbEdCcExOdkJxdXR6YlhT?=
 =?utf-8?B?ZFhjOTZITGt3c043Y1RZL1JkaXcwYnFsSnB6TFBEZVd3QzI4emhVZ2dZOW1i?=
 =?utf-8?B?TWZWOFBXMk5aUmZjWkpzVHFXdDd5eHBTQm5XRVZCVXFJaS9PanVwWDdCYlU3?=
 =?utf-8?B?WUNEZ2ZKRjlRVWFaUFRkazc2WEUyY1JJVmVsRk1uVzZ0Wm9Ea0Y1cEhIcTZF?=
 =?utf-8?B?OEFsNGZ1L252U1ZRZ2gxck5TdXI3Q3dPSHh4VEJGSW42OGlPWUt3R2dyL0dh?=
 =?utf-8?B?Rlp2WThFOTB5NnNFUmJjYXN0VVREWDU3RDhWVk9qZk5ianNQd2xLWFJMb0FH?=
 =?utf-8?B?L3BaejVSVWdjN3JnSnRQUEx3b2t5K3AvREVsM2gyOU1WenpRZUhhT1RNb3Rl?=
 =?utf-8?B?Uk9zb1lhT0ZKbzVYaDZONVdaRm5GK1VLcVEwNHZTUkxxbHR3MFgvWmRtR0Fn?=
 =?utf-8?B?b0tYZllZV1lkMEVFb1pyMGc1dEQwTWJWZWlObXowM3RwVzI2d0pIcXhGYWxx?=
 =?utf-8?B?U2FOSDZqUHhUeUFkZUpXZWxXMzV4Q2Y1ZCtlUkkyeUF4WmFDS3RjeGk1OS81?=
 =?utf-8?B?ZkR6OTlTQmk3Y2M0dW5PRjZKZS96bk9lbFo2blFyV1A3ckV1ZFhDU0p1aFNG?=
 =?utf-8?B?TDlJUHI5THNBM2Q2TjhpK2NvdVlBQkRXWlJqZWhlRHE5b2tiOGNZT0wxbzNa?=
 =?utf-8?B?Vm5DMjVFazQ0TUp1NUZCSXhHcnE5YzZOajhEUHRLTzY0cExTYXA3czNUZ21U?=
 =?utf-8?B?SlorVWVxODFzeEZWNzFpTkVic3RCamx3NUkyWStqSngxWjg4VVI0TDlDWlFa?=
 =?utf-8?B?OWpiWXl0bUNsdjFqOEs3cnkyM1E3V3JBUVNPMGd5aDBGajUzS2RmZWlhbWdi?=
 =?utf-8?B?a1dnR0dnWnRHWmJQS2x5K21sNmZyeUk0dkdPWjhQRVUrbU1yZnZwQ3Q5VWJ2?=
 =?utf-8?B?OUxxelF4dDVrbVhFVWo0NXQ5MkxNUzhMY2Uwb0RGN29wSG5wSW9KblRCcWpU?=
 =?utf-8?B?Z2pvV3lyZllIdkZmbWNOREFJa2IxYlNlcVc1T0hjNVRXM1Bjbk84K0VkSXdt?=
 =?utf-8?B?YkJ6NkhrWWh6RTJiYkh0bTF5NzQwU2xZMEhaOXlBQm83NEs1L0J2c2JZcDBT?=
 =?utf-8?B?MmpqNVF1ZmF2M3BjNkZCVXJrVmYzcEwrSjJQWjV5QXJmOFE9PQ==?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY5PR10MB4290.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(7416014)(366016)(10070799003)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?RDhsK1BDOVFnekh4UXVGRUNSVjM5UjJmcVFDaXQyNXpYRkNhWmJXY2NWcjVJ?=
 =?utf-8?B?a3lpNTVmeXZpNyt4TTNJU1l1N2c0RHE5dUEyUUlhSVJXdXhpSEk0RjhFeHZY?=
 =?utf-8?B?N0dEcWp5SWhrVm9xTkNWUVFuV0JMNUtYUU56V3VYWWNCWDcrMVBpbXNlWHl6?=
 =?utf-8?B?aWhHem5XNG9WNlRnN0VEb0hrMWlxMHNNNGRBdEJyREFOdkN2QWk2WlNDOC9j?=
 =?utf-8?B?UHpGMCtiakFmb0J2TnhxZXUxQjNQVDgrUmhvM1RDQUZ6YjlWYnVOeDJhTHZY?=
 =?utf-8?B?VHIyTDg5UFR1VktKbXB6NC96Z05ac0ZZaGxXRFRwcXZ4ak9KRDVIaG5JRWdh?=
 =?utf-8?B?Zlk4cmIxSld6V1RtMzlEeGRTVjNMVWozcThJY01QWWNSUFZVSjV2M3VJaWxx?=
 =?utf-8?B?L3hIQjE0VWJPaW4wNzB2cldOVndndFZDVHNkb2cvaFRucHpiekJNVDM5L1ho?=
 =?utf-8?B?Qk84RFFPSDdTVCtZRkJsUlZSeTZVQUNWK1VxVlNSbWszSndjTXJES2dnc2ps?=
 =?utf-8?B?SjhRdHpjdjNsRkFmUEJ6UGE0M01UV3JtQjV2R3haVCtRaFgrcml5SUJZM1JT?=
 =?utf-8?B?Y00vYlRvMm93ZVYydFA1VjVzNFhVZXE2Z3EycStWZjdZVDg1bDFjZnpYRGxF?=
 =?utf-8?B?VWgrMkFvU1dVWXFDWlNvN01lNHArTGQwbUZ6NkJDQzY0c21wR1pLK00va1Vv?=
 =?utf-8?B?SGlxcUdIMlZyMEJrNjNCbFp3dGRQWmFNTzNzaHprckNTNTd0ZHNYOXlXTTN2?=
 =?utf-8?B?Tzk4UGVTYVA3NUpqbHRsblJGUXh5a0VvRXJuWmxjdmw0NzRqMWl4WlVIN01w?=
 =?utf-8?B?N2ZxTWhRS0RLYlFaczROcGoxMldIREZFcDNYaTJzK3RybmRBYjZPVWlSUGJK?=
 =?utf-8?B?Nkc3YzRnYkVEd3dDOWZxa2N6MG5NS1loTDZlWmxiWmQxUVZkVVE2Y2k4TlRy?=
 =?utf-8?B?RFZVSlBxQS9iQzh5cFlialVzTzB4VG13Um02dURjeDlSRGpEeUE1ZmFKL29R?=
 =?utf-8?B?Z0JwbS80Qm1NbEhNQ3BMMlFDU2pITWNyaVVxTnBrSFhzeU9ESzdBdGZEckhK?=
 =?utf-8?B?am1VdmFrVjhlaUo4SXg5NjBpQTVGRmhWajRqMUJRM2lZUDF4RVdYMXlmUHlM?=
 =?utf-8?B?bWl1S242WnhIU3RJdlJtZHZSb2xUQzVHTDVNMmxOMGlmdlhRL25ubUtWT2Rn?=
 =?utf-8?B?Wmo1Mmg3c25QWFpmYjI4WW5SdWpzKzVhMmUvNGR6STJCLzFVb2ZqVTlDUDRX?=
 =?utf-8?B?ZU4yb0hKQkgrYnBzUlVkZFVkVmVPQlVoRjVwb2lMMEU4NVRhUFNBLzZhbjZ3?=
 =?utf-8?B?WllyODZYNUFYVXMyNlF4NmRqaWMycm84NnM4ZVJIb3VEQk1pOVJoVWJYcnJj?=
 =?utf-8?B?T244YUFkdlhaYVhRRlBONXY1MVdwMEhneitad0VRR0t6RGl3cTdYczFjTXRC?=
 =?utf-8?B?Z211SnBTWlRhWlJmcmUwRFV3MWNiWXpCbGxMcmJHOHpDdlk3ckRYd3duVGU3?=
 =?utf-8?B?SHpKdUxQUzd4cm5GbGtuMGN6ZHRKSWRiR0tldWl6a2paVkI3dXVSalhLODR2?=
 =?utf-8?B?eGhDSW1zejFhRE9venJsdWtmZ1R6LzF6VkI1dHZoKzhSL25JT3pCaTFOZ2U5?=
 =?utf-8?B?aDgxL05xbW1zODZ2eExJd2x6T3NpL2ZVMEhWN3lXdVFudnpkQ0NXVjh3cjNx?=
 =?utf-8?B?TStHNjlOY3VDaDBDY0ZNTldMTkhJNkFFMzMyN0RTSmZTSnhxbitnd29DS2Nz?=
 =?utf-8?B?MGM2R3JBUHZNTkdBUUtuaTU1eXQ3M00wNmVoMUY5NDI0WWhPR2laS3RDODA2?=
 =?utf-8?B?SWJnRnpTK0FtWUREcWc5Z01PYktwSXVjalRLM0pvYlJaNHYzall3TjFFTW54?=
 =?utf-8?B?Z2R6WUlVelBiVVdVZ3BCS3FWOE5tTkpaUG9rTk1XbTY3Rjc1K0tuMjZhT01u?=
 =?utf-8?B?QWJSYnAyU0lYb1V6Nzg5KzFKK3R1Zmh4Q0pDNVdTdkdTenJ2SFI0WmllVkR2?=
 =?utf-8?B?RHA1akhQa3huZEdlZDB0SDMyNFNWcExmUzdOeWx4M1hXbVlwM1BBQ0xnc1Ny?=
 =?utf-8?B?eEFSVGJmc3kwNXlKNHE4dHJETEZEQjM4bXNGck1CaHN3eHZZb0FjTkwyNFpy?=
 =?utf-8?B?Q0Q0T212NThOZEdxTHQ2WDYrbHQrSHR3SklyV0dZQXorNzFJYVUwdUNqcy8y?=
 =?utf-8?B?MGlmeFd4RDN0cE5qenNjMU9UbmJoNmdNYzhoS3pCWDN4azNLNEdxdS9iUHpE?=
 =?utf-8?B?aU8yZ2g0TGdHNXdHV2JTVUhvZ3dRPT0=?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	oj7aGN9hcKrPmyEOyr4mR5ddzuJD+2k7kTovztLlPEOioxtOYwiQC+X1Mv0OkMpDAqdNuMpYbELmmEC5npdVBXU8UKMW02gUTWiFkiROZWa9sN86cEfNVwcq4y8D9Gt5vxtJFLx7iNklJBrx4LlHKZ1N4uLmPTl6Ams5/WU8eR9Rrl0QcOsHZFQ4aRQBC7/bRMgaiUYXRLZfXzkG+g9pAL9D0eGeGibbR0cQFhSTvRIoSOKCGylSzqUGP09MwWc70kWa3/UqM/KMLbaVzXD3+P6oqp+NSwOwZkPgCU5ZP8FVp2pgCX5TYCLXmAHSxHuS4cT9wdhzGbjyDQPwyhwlMIuBN/j+WyMA70McO9X38uRMi9PvWSxw0WH6JLaUrGZtrOt8h4F3F9s/ui2vQ8DUh4GaDNkh/yOfWJFNNGXIYvYnaWTmbzQY4u9vLHdJKEV0emLHJkD/NYTfRqe8Os9KI8tiGNkRG7XhbGQzTeVdqerUnHCPOsooU8ZRZ7aC6WkLP9mkK9IJfZqMrn9GiMLLIzM6M3NR1jSYXAXW8zTvPiWVAnnLpaHvXYumSaVjdFIu3V7OZgkzUX95WLHEQKjZpvWp052xvBGSMKgJ46hcwtQ=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4cf3f591-697e-4fec-7b51-08dd31a48ed6
X-MS-Exchange-CrossTenant-AuthSource: BY5PR10MB4290.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jan 2025 18:28:20.0827
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 09dwvkNRrREDFT6C4M8228Qnb5kz8FlskU1Fnh6ttLSD6iS52NqarewETBNNxZ+n1Nm6ZQKQ/ojUOTs9T/AWIAwyjKQ6ywsox4g4wSALHv4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR10MB7070
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34
 definitions=2025-01-10_08,2025-01-10_03,2024-11-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 malwarescore=0
 adultscore=0 mlxlogscore=999 suspectscore=0 mlxscore=0 spamscore=0
 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2411120000 definitions=main-2501100143
X-Proofpoint-GUID: MmnmhWMkijCiFmhVT1K6ZlJGdFi68d7i
X-Proofpoint-ORIG-GUID: MmnmhWMkijCiFmhVT1K6ZlJGdFi68d7i



On 1/10/25 9:16 AM, Joel Granados wrote:
> Add the const qualifier to all the ctl_tables in the tree except for
> watchdog_hardlockup_sysctl, memory_allocation_profiling_sysctls,
> loadpin_sysctl_table and the ones calling register_net_sysctl (./net,
> drivers/inifiniband dirs). These are special cases as they use a
> registration function with a non-const qualified ctl_table argument or
> modify the arrays before passing them on to the registration function.
> 
> Constifying ctl_table structs will prevent the modification of
> proc_handler function pointers as the arrays would reside in .rodata.
> This is made possible after commit 78eb4ea25cd5 ("sysctl: treewide:
> constify the ctl_table argument of proc_handlers") constified all the
> proc_handlers.
> 
> Created this by running an spatch followed by a sed command:
> Spatch:
>     virtual patch
> 
>     @
>     depends on !(file in "net")
>     disable optional_qualifier
>     @
>     identifier table_name != {watchdog_hardlockup_sysctl,iwcm_ctl_table,ucma_ctl_table,memory_allocation_profiling_sysctls,loadpin_sysctl_table};
>     @@
> 
>     + const
>     struct ctl_table table_name [] = { ... };
> 
> sed:
>     sed --in-place \
>       -e "s/struct ctl_table .table = &uts_kern/const struct ctl_table *table = \&uts_kern/" \
>       kernel/utsname_sysctl.c
> 
> Reviewed-by: Song Liu <song@kernel.org>
> Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org> # for kernel/trace/
> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> # SCSI
> Reviewed-by: Darrick J. Wong <djwong@kernel.org> # xfs
> Acked-by: Jani Nikula <jani.nikula@intel.com>
> Acked-by: Corey Minyard <cminyard@mvista.com>
> Signed-off-by: Joel Granados <joel.granados@kernel.org>
> ---
> This treewide commit builds upon the work Thomas began a few releases
> ago [1], where he laid the groundwork for constifying ctl_tables. We
> implement constification throughout the tree, with the exception of the
> ctl_tables in the "net" directory. Those are special in that they treat
> the ctl_table as non-const but we can take them at a later point.
> 
> Upstreaming:
> ===========
> It is late in the release cycle, but I'm hopeful that we can get this
> in for the upcoming merge window and this is why:
> 1. We don't use linux-next: As with previous treewide changes similar to
>    this one [1], we avoid using linux-next in order to avoid unwanted
>    merge conflicts
> 2. This is a non-functional change: which lowers the probability of
>    unforeseen errors or regressions.
> 3. It will have at least 2 weeks to be tested/reviewed: The PULL should
>    be sent at the end of the merge window, giving it at least 2 weeks.
>    And if there are more release candidates after rc6, there will be
>    more time.
> 
> Testing:
> ========
> 1. Currently being tested in 0-day
> 2. sysctl self-tests/kunit-tests
> 
> Reduced To/Cc:
> ==============
> b4 originally gave me 200 ppl that this should go out to (which seems a
> bit overkill from my point of view). So I left the mailing lists and
> reduced the To: the ppl previously involved in the effort and sysctl
> maintainers. Please tell me if I missed someone important to the
> constification effort.
> 
> Comments are greatly appreciated.
> 
> Changes in v2:
> - watchdog_hardlockup_sysctl, memory_allocation_profiling_sysctls,
>   loadpin_sysctl_table, iwcm_ctl_table and ucma_ctl_table where removed
>   from patchset as they change the sysctl array before registration.
> - Added reviewed-by tags
> - Link to v1: https://lore.kernel.org/r/20250109-jag-ctl_table_const-v1-1-622aea7230cf@kernel.org
> Best
> 
> [1] https://lore.kernel.org/20240724210014.mc6nima6cekgiukx@joelS2.panther.com
> 
> --
> ---
> 
> ---
>  arch/arm/kernel/isa.c                         | 2 +-
>  arch/arm64/kernel/fpsimd.c                    | 4 ++--
>  arch/arm64/kernel/process.c                   | 2 +-
>  arch/powerpc/kernel/idle.c                    | 2 +-
>  arch/powerpc/platforms/pseries/mobility.c     | 2 +-
>  arch/riscv/kernel/process.c                   | 2 +-
>  arch/riscv/kernel/vector.c                    | 2 +-
>  arch/s390/appldata/appldata_base.c            | 2 +-
>  arch/s390/kernel/debug.c                      | 2 +-
>  arch/s390/kernel/hiperdispatch.c              | 2 +-
>  arch/s390/kernel/topology.c                   | 2 +-
>  arch/s390/mm/cmm.c                            | 2 +-
>  arch/s390/mm/pgalloc.c                        | 2 +-
>  arch/x86/entry/vdso/vdso32-setup.c            | 2 +-
>  arch/x86/kernel/cpu/bus_lock.c                | 2 +-
>  arch/x86/kernel/itmt.c                        | 2 +-
>  crypto/fips.c                                 | 2 +-
>  drivers/base/firmware_loader/fallback_table.c | 2 +-
>  drivers/cdrom/cdrom.c                         | 2 +-
>  drivers/char/hpet.c                           | 2 +-
>  drivers/char/ipmi/ipmi_poweroff.c             | 2 +-
>  drivers/char/random.c                         | 2 +-
>  drivers/gpu/drm/i915/i915_perf.c              | 2 +-
>  drivers/gpu/drm/xe/xe_observation.c           | 2 +-
>  drivers/hv/hv_common.c                        | 2 +-
>  drivers/macintosh/mac_hid.c                   | 2 +-
>  drivers/md/md.c                               | 2 +-
>  drivers/misc/sgi-xp/xpc_main.c                | 4 ++--
>  drivers/perf/arm_pmuv3.c                      | 2 +-
>  drivers/perf/riscv_pmu_sbi.c                  | 2 +-
>  drivers/scsi/scsi_sysctl.c                    | 2 +-
>  drivers/scsi/sg.c                             | 2 +-
>  drivers/tty/tty_io.c                          | 2 +-
>  drivers/xen/balloon.c                         | 2 +-
>  fs/aio.c                                      | 2 +-
>  fs/cachefiles/error_inject.c                  | 2 +-
>  fs/coda/sysctl.c                              | 2 +-
>  fs/coredump.c                                 | 2 +-
>  fs/dcache.c                                   | 2 +-
>  fs/devpts/inode.c                             | 2 +-
>  fs/eventpoll.c                                | 2 +-
>  fs/exec.c                                     | 2 +-
>  fs/file_table.c                               | 2 +-
>  fs/fuse/sysctl.c                              | 2 +-
>  fs/inode.c                                    | 2 +-
>  fs/lockd/svc.c                                | 2 +-
>  fs/locks.c                                    | 2 +-
>  fs/namei.c                                    | 2 +-
>  fs/namespace.c                                | 2 +-
>  fs/nfs/nfs4sysctl.c                           | 2 +-
>  fs/nfs/sysctl.c                               | 2 +-
>  fs/notify/dnotify/dnotify.c                   | 2 +-
>  fs/notify/fanotify/fanotify_user.c            | 2 +-
>  fs/notify/inotify/inotify_user.c              | 2 +-
>  fs/ocfs2/stackglue.c                          | 2 +-
>  fs/pipe.c                                     | 2 +-
>  fs/quota/dquot.c                              | 2 +-
>  fs/sysctls.c                                  | 2 +-
>  fs/userfaultfd.c                              | 2 +-
>  fs/verity/init.c                              | 2 +-
>  fs/xfs/xfs_sysctl.c                           | 2 +-
>  init/do_mounts_initrd.c                       | 2 +-
>  io_uring/io_uring.c                           | 2 +-
>  ipc/ipc_sysctl.c                              | 2 +-
>  ipc/mq_sysctl.c                               | 2 +-
>  kernel/acct.c                                 | 2 +-
>  kernel/bpf/syscall.c                          | 2 +-
>  kernel/delayacct.c                            | 2 +-
>  kernel/exit.c                                 | 2 +-
>  kernel/hung_task.c                            | 2 +-
>  kernel/kexec_core.c                           | 2 +-
>  kernel/kprobes.c                              | 2 +-
>  kernel/latencytop.c                           | 2 +-
>  kernel/locking/lockdep.c                      | 2 +-
>  kernel/panic.c                                | 2 +-
>  kernel/pid_namespace.c                        | 2 +-
>  kernel/pid_sysctl.h                           | 2 +-
>  kernel/printk/sysctl.c                        | 2 +-
>  kernel/reboot.c                               | 2 +-
>  kernel/sched/autogroup.c                      | 2 +-
>  kernel/sched/core.c                           | 2 +-
>  kernel/sched/deadline.c                       | 2 +-
>  kernel/sched/fair.c                           | 2 +-
>  kernel/sched/rt.c                             | 2 +-
>  kernel/sched/topology.c                       | 2 +-
>  kernel/seccomp.c                              | 2 +-
>  kernel/signal.c                               | 2 +-
>  kernel/stackleak.c                            | 2 +-
>  kernel/sysctl-test.c                          | 6 +++---
>  kernel/sysctl.c                               | 4 ++--
>  kernel/time/timer.c                           | 2 +-
>  kernel/trace/ftrace.c                         | 2 +-
>  kernel/trace/trace_events_user.c              | 2 +-
>  kernel/umh.c                                  | 2 +-
>  kernel/utsname_sysctl.c                       | 4 ++--
>  kernel/watchdog.c                             | 2 +-
>  lib/test_sysctl.c                             | 6 +++---
>  mm/compaction.c                               | 2 +-
>  mm/hugetlb.c                                  | 2 +-
>  mm/hugetlb_vmemmap.c                          | 2 +-
>  mm/memory-failure.c                           | 2 +-
>  mm/oom_kill.c                                 | 2 +-
>  mm/page-writeback.c                           | 2 +-
>  mm/page_alloc.c                               | 2 +-
>  security/apparmor/lsm.c                       | 2 +-
>  security/keys/sysctl.c                        | 2 +-
>  security/yama/yama_lsm.c                      | 2 +-
>  107 files changed, 115 insertions(+), 115 deletions(-)
> 
> diff --git a/arch/arm/kernel/isa.c b/arch/arm/kernel/isa.c
> index 905b1b191546..db8be609fab2 100644
> --- a/arch/arm/kernel/isa.c
> +++ b/arch/arm/kernel/isa.c
> @@ -16,7 +16,7 @@
>  
>  static unsigned int isa_membase, isa_portbase, isa_portshift;
>  
> -static struct ctl_table ctl_isa_vars[] = {
> +static const struct ctl_table ctl_isa_vars[] = {
>  	{
>  		.procname	= "membase",
>  		.data		= &isa_membase, 
> diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> index 8c4c1a2186cc..2b601d88762d 100644
> --- a/arch/arm64/kernel/fpsimd.c
> +++ b/arch/arm64/kernel/fpsimd.c
> @@ -562,7 +562,7 @@ static int vec_proc_do_default_vl(const struct ctl_table *table, int write,
>  	return 0;
>  }
>  
> -static struct ctl_table sve_default_vl_table[] = {
> +static const struct ctl_table sve_default_vl_table[] = {
>  	{
>  		.procname	= "sve_default_vector_length",
>  		.mode		= 0644,
> @@ -585,7 +585,7 @@ static int __init sve_sysctl_init(void) { return 0; }
>  #endif /* ! (CONFIG_ARM64_SVE && CONFIG_SYSCTL) */
>  
>  #if defined(CONFIG_ARM64_SME) && defined(CONFIG_SYSCTL)
> -static struct ctl_table sme_default_vl_table[] = {
> +static const struct ctl_table sme_default_vl_table[] = {
>  	{
>  		.procname	= "sme_default_vector_length",
>  		.mode		= 0644,
> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> index 2968a33bb3bc..42faebb7b712 100644
> --- a/arch/arm64/kernel/process.c
> +++ b/arch/arm64/kernel/process.c
> @@ -859,7 +859,7 @@ long get_tagged_addr_ctrl(struct task_struct *task)
>   * disable it for tasks that already opted in to the relaxed ABI.
>   */
>  
> -static struct ctl_table tagged_addr_sysctl_table[] = {
> +static const struct ctl_table tagged_addr_sysctl_table[] = {
>  	{
>  		.procname	= "tagged_addr_disabled",
>  		.mode		= 0644,
> diff --git a/arch/powerpc/kernel/idle.c b/arch/powerpc/kernel/idle.c
> index 30b56c67fa61..e527cd3ef128 100644
> --- a/arch/powerpc/kernel/idle.c
> +++ b/arch/powerpc/kernel/idle.c
> @@ -97,7 +97,7 @@ void power4_idle(void)
>  /*
>   * Register the sysctl to set/clear powersave_nap.
>   */
> -static struct ctl_table powersave_nap_ctl_table[] = {
> +static const struct ctl_table powersave_nap_ctl_table[] = {
>  	{
>  		.procname	= "powersave-nap",
>  		.data		= &powersave_nap,
> diff --git a/arch/powerpc/platforms/pseries/mobility.c b/arch/powerpc/platforms/pseries/mobility.c
> index 1798f0f14d58..62bd8e2d5d4c 100644
> --- a/arch/powerpc/platforms/pseries/mobility.c
> +++ b/arch/powerpc/platforms/pseries/mobility.c
> @@ -53,7 +53,7 @@ struct update_props_workarea {
>  static unsigned int nmi_wd_lpm_factor = 200;
>  
>  #ifdef CONFIG_SYSCTL
> -static struct ctl_table nmi_wd_lpm_factor_ctl_table[] = {
> +static const struct ctl_table nmi_wd_lpm_factor_ctl_table[] = {
>  	{
>  		.procname	= "nmi_wd_lpm_factor",
>  		.data		= &nmi_wd_lpm_factor,
> diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c
> index 58b6482c2bf6..7891294abf49 100644
> --- a/arch/riscv/kernel/process.c
> +++ b/arch/riscv/kernel/process.c
> @@ -364,7 +364,7 @@ static bool try_to_set_pmm(unsigned long value)
>   * disable it for tasks that already opted in to the relaxed ABI.
>   */
>  
> -static struct ctl_table tagged_addr_sysctl_table[] = {
> +static const struct ctl_table tagged_addr_sysctl_table[] = {
>  	{
>  		.procname	= "tagged_addr_disabled",
>  		.mode		= 0644,
> diff --git a/arch/riscv/kernel/vector.c b/arch/riscv/kernel/vector.c
> index 821818886fab..d022b028ac3f 100644
> --- a/arch/riscv/kernel/vector.c
> +++ b/arch/riscv/kernel/vector.c
> @@ -287,7 +287,7 @@ long riscv_v_vstate_ctrl_set_current(unsigned long arg)
>  
>  #ifdef CONFIG_SYSCTL
>  
> -static struct ctl_table riscv_v_default_vstate_table[] = {
> +static const struct ctl_table riscv_v_default_vstate_table[] = {
>  	{
>  		.procname	= "riscv_v_default_allow",
>  		.data		= &riscv_v_implicit_uacc,
> diff --git a/arch/s390/appldata/appldata_base.c b/arch/s390/appldata/appldata_base.c
> index 91a30e017d65..dd7ba7587dd5 100644
> --- a/arch/s390/appldata/appldata_base.c
> +++ b/arch/s390/appldata/appldata_base.c
> @@ -52,7 +52,7 @@ static int appldata_interval_handler(const struct ctl_table *ctl, int write,
>  				     void *buffer, size_t *lenp, loff_t *ppos);
>  
>  static struct ctl_table_header *appldata_sysctl_header;
> -static struct ctl_table appldata_table[] = {
> +static const struct ctl_table appldata_table[] = {
>  	{
>  		.procname	= "timer",
>  		.mode		= S_IRUGO | S_IWUSR,
> diff --git a/arch/s390/kernel/debug.c b/arch/s390/kernel/debug.c
> index de19fd8a6a95..2c245c2bce4f 100644
> --- a/arch/s390/kernel/debug.c
> +++ b/arch/s390/kernel/debug.c
> @@ -972,7 +972,7 @@ static int s390dbf_procactive(const struct ctl_table *table, int write,
>  		return 0;
>  }
>  
> -static struct ctl_table s390dbf_table[] = {
> +static const struct ctl_table s390dbf_table[] = {
>  	{
>  		.procname	= "debug_stoppable",
>  		.data		= &debug_stoppable,
> diff --git a/arch/s390/kernel/hiperdispatch.c b/arch/s390/kernel/hiperdispatch.c
> index 2a99a216ab62..7857a7e8e56c 100644
> --- a/arch/s390/kernel/hiperdispatch.c
> +++ b/arch/s390/kernel/hiperdispatch.c
> @@ -292,7 +292,7 @@ static int hiperdispatch_ctl_handler(const struct ctl_table *ctl, int write,
>  	return 0;
>  }
>  
> -static struct ctl_table hiperdispatch_ctl_table[] = {
> +static const struct ctl_table hiperdispatch_ctl_table[] = {
>  	{
>  		.procname	= "hiperdispatch",
>  		.mode		= 0644,
> diff --git a/arch/s390/kernel/topology.c b/arch/s390/kernel/topology.c
> index 4f9c301a705b..5067293ef69d 100644
> --- a/arch/s390/kernel/topology.c
> +++ b/arch/s390/kernel/topology.c
> @@ -662,7 +662,7 @@ static int polarization_ctl_handler(const struct ctl_table *ctl, int write,
>  	return set_polarization(polarization);
>  }
>  
> -static struct ctl_table topology_ctl_table[] = {
> +static const struct ctl_table topology_ctl_table[] = {
>  	{
>  		.procname	= "topology",
>  		.mode		= 0644,
> diff --git a/arch/s390/mm/cmm.c b/arch/s390/mm/cmm.c
> index d01724a715d0..939e3bec2db7 100644
> --- a/arch/s390/mm/cmm.c
> +++ b/arch/s390/mm/cmm.c
> @@ -332,7 +332,7 @@ static int cmm_timeout_handler(const struct ctl_table *ctl, int write,
>  	return 0;
>  }
>  
> -static struct ctl_table cmm_table[] = {
> +static const struct ctl_table cmm_table[] = {
>  	{
>  		.procname	= "cmm_pages",
>  		.mode		= 0644,
> diff --git a/arch/s390/mm/pgalloc.c b/arch/s390/mm/pgalloc.c
> index 58696a0c4e4a..18d3176e44fb 100644
> --- a/arch/s390/mm/pgalloc.c
> +++ b/arch/s390/mm/pgalloc.c
> @@ -21,7 +21,7 @@
>  int page_table_allocate_pgste = 0;
>  EXPORT_SYMBOL(page_table_allocate_pgste);
>  
> -static struct ctl_table page_table_sysctl[] = {
> +static const struct ctl_table page_table_sysctl[] = {
>  	{
>  		.procname	= "allocate_pgste",
>  		.data		= &page_table_allocate_pgste,
> diff --git a/arch/x86/entry/vdso/vdso32-setup.c b/arch/x86/entry/vdso/vdso32-setup.c
> index 76e4e74f35b5..f6d2d8aba643 100644
> --- a/arch/x86/entry/vdso/vdso32-setup.c
> +++ b/arch/x86/entry/vdso/vdso32-setup.c
> @@ -57,7 +57,7 @@ __setup_param("vdso=", vdso_setup, vdso32_setup, 0);
>  /* Register vsyscall32 into the ABI table */
>  #include <linux/sysctl.h>
>  
> -static struct ctl_table abi_table2[] = {
> +static const struct ctl_table abi_table2[] = {
>  	{
>  		.procname	= "vsyscall32",
>  		.data		= &vdso32_enabled,
> diff --git a/arch/x86/kernel/cpu/bus_lock.c b/arch/x86/kernel/cpu/bus_lock.c
> index 704e9241b964..6cba85c79d42 100644
> --- a/arch/x86/kernel/cpu/bus_lock.c
> +++ b/arch/x86/kernel/cpu/bus_lock.c
> @@ -49,7 +49,7 @@ static unsigned int sysctl_sld_mitigate = 1;
>  static DEFINE_SEMAPHORE(buslock_sem, 1);
>  
>  #ifdef CONFIG_PROC_SYSCTL
> -static struct ctl_table sld_sysctls[] = {
> +static const struct ctl_table sld_sysctls[] = {
>  	{
>  		.procname       = "split_lock_mitigate",
>  		.data           = &sysctl_sld_mitigate,
> diff --git a/arch/x86/kernel/itmt.c b/arch/x86/kernel/itmt.c
> index 51b805c727fc..083d8c4deb2b 100644
> --- a/arch/x86/kernel/itmt.c
> +++ b/arch/x86/kernel/itmt.c
> @@ -64,7 +64,7 @@ static int sched_itmt_update_handler(const struct ctl_table *table, int write,
>  	return ret;
>  }
>  
> -static struct ctl_table itmt_kern_table[] = {
> +static const struct ctl_table itmt_kern_table[] = {
>  	{
>  		.procname	= "sched_itmt_enabled",
>  		.data		= &sysctl_sched_itmt_enabled,
> diff --git a/crypto/fips.c b/crypto/fips.c
> index 8a784018ebfc..ec6574596e59 100644
> --- a/crypto/fips.c
> +++ b/crypto/fips.c
> @@ -41,7 +41,7 @@ __setup("fips=", fips_enable);
>  static char fips_name[] = FIPS_MODULE_NAME;
>  static char fips_version[] = FIPS_MODULE_VERSION;
>  
> -static struct ctl_table crypto_sysctl_table[] = {
> +static const struct ctl_table crypto_sysctl_table[] = {
>  	{
>  		.procname	= "fips_enabled",
>  		.data		= &fips_enabled,
> diff --git a/drivers/base/firmware_loader/fallback_table.c b/drivers/base/firmware_loader/fallback_table.c
> index ddb70e29eb42..c8afc501a8a4 100644
> --- a/drivers/base/firmware_loader/fallback_table.c
> +++ b/drivers/base/firmware_loader/fallback_table.c
> @@ -25,7 +25,7 @@ struct firmware_fallback_config fw_fallback_config = {
>  EXPORT_SYMBOL_NS_GPL(fw_fallback_config, "FIRMWARE_LOADER_PRIVATE");
>  
>  #ifdef CONFIG_SYSCTL
> -static struct ctl_table firmware_config_table[] = {
> +static const struct ctl_table firmware_config_table[] = {
>  	{
>  		.procname	= "force_sysfs_fallback",
>  		.data		= &fw_fallback_config.force_sysfs_fallback,
> diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
> index 51745ed1bbab..b163e043c687 100644
> --- a/drivers/cdrom/cdrom.c
> +++ b/drivers/cdrom/cdrom.c
> @@ -3612,7 +3612,7 @@ static int cdrom_sysctl_handler(const struct ctl_table *ctl, int write,
>  }
>  
>  /* Place files in /proc/sys/dev/cdrom */
> -static struct ctl_table cdrom_table[] = {
> +static const struct ctl_table cdrom_table[] = {
>  	{
>  		.procname	= "info",
>  		.data		= &cdrom_sysctl_settings.info, 
> diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c
> index 48fe96ab4649..e110857824fc 100644
> --- a/drivers/char/hpet.c
> +++ b/drivers/char/hpet.c
> @@ -724,7 +724,7 @@ static int hpet_is_known(struct hpet_data *hdp)
>  	return 0;
>  }
>  
> -static struct ctl_table hpet_table[] = {
> +static const struct ctl_table hpet_table[] = {
>  	{
>  	 .procname = "max-user-freq",
>  	 .data = &hpet_max_freq,
> diff --git a/drivers/char/ipmi/ipmi_poweroff.c b/drivers/char/ipmi/ipmi_poweroff.c
> index 941d2dcc8c9d..de84f59468a9 100644
> --- a/drivers/char/ipmi/ipmi_poweroff.c
> +++ b/drivers/char/ipmi/ipmi_poweroff.c
> @@ -650,7 +650,7 @@ static struct ipmi_smi_watcher smi_watcher = {
>  #ifdef CONFIG_PROC_FS
>  #include <linux/sysctl.h>
>  
> -static struct ctl_table ipmi_table[] = {
> +static const struct ctl_table ipmi_table[] = {
>  	{ .procname	= "poweroff_powercycle",
>  	  .data		= &poweroff_powercycle,
>  	  .maxlen	= sizeof(poweroff_powercycle),
> diff --git a/drivers/char/random.c b/drivers/char/random.c
> index 23ee76bbb4aa..2581186fa61b 100644
> --- a/drivers/char/random.c
> +++ b/drivers/char/random.c
> @@ -1665,7 +1665,7 @@ static int proc_do_rointvec(const struct ctl_table *table, int write, void *buf,
>  	return write ? 0 : proc_dointvec(table, 0, buf, lenp, ppos);
>  }
>  
> -static struct ctl_table random_table[] = {
> +static const struct ctl_table random_table[] = {
>  	{
>  		.procname	= "poolsize",
>  		.data		= &sysctl_poolsize,
> diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
> index 2406cda75b7b..5384d1bb4923 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -4802,7 +4802,7 @@ int i915_perf_remove_config_ioctl(struct drm_device *dev, void *data,
>  	return ret;
>  }
>  
> -static struct ctl_table oa_table[] = {
> +static const struct ctl_table oa_table[] = {
>  	{
>  	 .procname = "perf_stream_paranoid",
>  	 .data = &i915_perf_stream_paranoid,
> diff --git a/drivers/gpu/drm/xe/xe_observation.c b/drivers/gpu/drm/xe/xe_observation.c
> index 8ec1b84cbb9e..57cf01efc07f 100644
> --- a/drivers/gpu/drm/xe/xe_observation.c
> +++ b/drivers/gpu/drm/xe/xe_observation.c
> @@ -56,7 +56,7 @@ int xe_observation_ioctl(struct drm_device *dev, void *data, struct drm_file *fi
>  	}
>  }
>  
> -static struct ctl_table observation_ctl_table[] = {
> +static const struct ctl_table observation_ctl_table[] = {
>  	{
>  	 .procname = "observation_paranoid",
>  	 .data = &xe_observation_paranoid,
> diff --git a/drivers/hv/hv_common.c b/drivers/hv/hv_common.c
> index 7a35c82976e0..9453f0c26f2a 100644
> --- a/drivers/hv/hv_common.c
> +++ b/drivers/hv/hv_common.c
> @@ -141,7 +141,7 @@ static int sysctl_record_panic_msg = 1;
>   * sysctl option to allow the user to control whether kmsg data should be
>   * reported to Hyper-V on panic.
>   */
> -static struct ctl_table hv_ctl_table[] = {
> +static const struct ctl_table hv_ctl_table[] = {
>  	{
>  		.procname	= "hyperv_record_panic_msg",
>  		.data		= &sysctl_record_panic_msg,
> diff --git a/drivers/macintosh/mac_hid.c b/drivers/macintosh/mac_hid.c
> index b461b1bed25b..369d72f59b3c 100644
> --- a/drivers/macintosh/mac_hid.c
> +++ b/drivers/macintosh/mac_hid.c
> @@ -215,7 +215,7 @@ static int mac_hid_toggle_emumouse(const struct ctl_table *table, int write,
>  }
>  
>  /* file(s) in /proc/sys/dev/mac_hid */
> -static struct ctl_table mac_hid_files[] = {
> +static const struct ctl_table mac_hid_files[] = {
>  	{
>  		.procname	= "mouse_button_emulation",
>  		.data		= &mouse_emulate_buttons,
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index aebe12b0ee27..0e06f9027d81 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -294,7 +294,7 @@ void mddev_destroy_serial_pool(struct mddev *mddev, struct md_rdev *rdev)
>  
>  static struct ctl_table_header *raid_table_header;
>  
> -static struct ctl_table raid_table[] = {
> +static const struct ctl_table raid_table[] = {
>  	{
>  		.procname	= "speed_limit_min",
>  		.data		= &sysctl_speed_limit_min,
> diff --git a/drivers/misc/sgi-xp/xpc_main.c b/drivers/misc/sgi-xp/xpc_main.c
> index 61b66e318488..7a3c34306de9 100644
> --- a/drivers/misc/sgi-xp/xpc_main.c
> +++ b/drivers/misc/sgi-xp/xpc_main.c
> @@ -93,7 +93,7 @@ int xpc_disengage_timelimit = XPC_DISENGAGE_DEFAULT_TIMELIMIT;
>  static int xpc_disengage_min_timelimit;	/* = 0 */
>  static int xpc_disengage_max_timelimit = 120;
>  
> -static struct ctl_table xpc_sys_xpc_hb[] = {
> +static const struct ctl_table xpc_sys_xpc_hb[] = {
>  	{
>  	 .procname = "hb_interval",
>  	 .data = &xpc_hb_interval,
> @@ -111,7 +111,7 @@ static struct ctl_table xpc_sys_xpc_hb[] = {
>  	 .extra1 = &xpc_hb_check_min_interval,
>  	 .extra2 = &xpc_hb_check_max_interval},
>  };
> -static struct ctl_table xpc_sys_xpc[] = {
> +static const struct ctl_table xpc_sys_xpc[] = {
>  	{
>  	 .procname = "disengage_timelimit",
>  	 .data = &xpc_disengage_timelimit,
> diff --git a/drivers/perf/arm_pmuv3.c b/drivers/perf/arm_pmuv3.c
> index b5cc11abc962..0e360feb3432 100644
> --- a/drivers/perf/arm_pmuv3.c
> +++ b/drivers/perf/arm_pmuv3.c
> @@ -1279,7 +1279,7 @@ static int armv8pmu_proc_user_access_handler(const struct ctl_table *table, int
>  	return 0;
>  }
>  
> -static struct ctl_table armv8_pmu_sysctl_table[] = {
> +static const struct ctl_table armv8_pmu_sysctl_table[] = {
>  	{
>  		.procname       = "perf_user_access",
>  		.data		= &sysctl_perf_user_access,
> diff --git a/drivers/perf/riscv_pmu_sbi.c b/drivers/perf/riscv_pmu_sbi.c
> index 1aa303f76cc7..ea96c0a88f73 100644
> --- a/drivers/perf/riscv_pmu_sbi.c
> +++ b/drivers/perf/riscv_pmu_sbi.c
> @@ -1315,7 +1315,7 @@ static int riscv_pmu_proc_user_access_handler(const struct ctl_table *table,
>  	return 0;
>  }
>  
> -static struct ctl_table sbi_pmu_sysctl_table[] = {
> +static const struct ctl_table sbi_pmu_sysctl_table[] = {
>  	{
>  		.procname       = "perf_user_access",
>  		.data		= &sysctl_perf_user_access,
> diff --git a/drivers/scsi/scsi_sysctl.c b/drivers/scsi/scsi_sysctl.c
> index 093774d77534..be4aef0f4f99 100644
> --- a/drivers/scsi/scsi_sysctl.c
> +++ b/drivers/scsi/scsi_sysctl.c
> @@ -12,7 +12,7 @@
>  #include "scsi_priv.h"
>  
>  
> -static struct ctl_table scsi_table[] = {
> +static const struct ctl_table scsi_table[] = {
>  	{ .procname	= "logging_level",
>  	  .data		= &scsi_logging_level,
>  	  .maxlen	= sizeof(scsi_logging_level),
> diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
> index 94127868bedf..effb7e768165 100644
> --- a/drivers/scsi/sg.c
> +++ b/drivers/scsi/sg.c
> @@ -1639,7 +1639,7 @@ MODULE_PARM_DESC(allow_dio, "allow direct I/O (default: 0 (disallow))");
>  #ifdef CONFIG_SYSCTL
>  #include <linux/sysctl.h>
>  
> -static struct ctl_table sg_sysctls[] = {
> +static const struct ctl_table sg_sysctls[] = {
>  	{
>  		.procname	= "sg-big-buff",
>  		.data		= &sg_big_buff,
> diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
> index dcb1769c3625..0e84677712b4 100644
> --- a/drivers/tty/tty_io.c
> +++ b/drivers/tty/tty_io.c
> @@ -3618,7 +3618,7 @@ void console_sysfs_notify(void)
>  		sysfs_notify(&consdev->kobj, NULL, "active");
>  }
>  
> -static struct ctl_table tty_table[] = {
> +static const struct ctl_table tty_table[] = {
>  	{
>  		.procname	= "legacy_tiocsti",
>  		.data		= &tty_legacy_tiocsti,
> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> index 528395133b4f..163f7f1d70f1 100644
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -84,7 +84,7 @@ module_param(balloon_boot_timeout, uint, 0444);
>  #ifdef CONFIG_XEN_BALLOON_MEMORY_HOTPLUG
>  static int xen_hotplug_unpopulated;
>  
> -static struct ctl_table balloon_table[] = {
> +static const struct ctl_table balloon_table[] = {
>  	{
>  		.procname	= "hotplug_unpopulated",
>  		.data		= &xen_hotplug_unpopulated,
> diff --git a/fs/aio.c b/fs/aio.c
> index 50671640b588..7b976b564cfc 100644
> --- a/fs/aio.c
> +++ b/fs/aio.c
> @@ -224,7 +224,7 @@ static unsigned long aio_nr;		/* current system wide number of aio requests */
>  static unsigned long aio_max_nr = 0x10000; /* system wide maximum number of aio requests */
>  /*----end sysctl variables---*/
>  #ifdef CONFIG_SYSCTL
> -static struct ctl_table aio_sysctls[] = {
> +static const struct ctl_table aio_sysctls[] = {
>  	{
>  		.procname	= "aio-nr",
>  		.data		= &aio_nr,
> diff --git a/fs/cachefiles/error_inject.c b/fs/cachefiles/error_inject.c
> index 1715d5ca2b2d..e341ade47dd8 100644
> --- a/fs/cachefiles/error_inject.c
> +++ b/fs/cachefiles/error_inject.c
> @@ -11,7 +11,7 @@
>  unsigned int cachefiles_error_injection_state;
>  
>  static struct ctl_table_header *cachefiles_sysctl;
> -static struct ctl_table cachefiles_sysctls[] = {
> +static const struct ctl_table cachefiles_sysctls[] = {
>  	{
>  		.procname	= "error_injection",
>  		.data		= &cachefiles_error_injection_state,
> diff --git a/fs/coda/sysctl.c b/fs/coda/sysctl.c
> index 9f2d5743e2c8..0df46f09b6cc 100644
> --- a/fs/coda/sysctl.c
> +++ b/fs/coda/sysctl.c
> @@ -14,7 +14,7 @@
>  
>  static struct ctl_table_header *fs_table_header;
>  
> -static struct ctl_table coda_table[] = {
> +static const struct ctl_table coda_table[] = {
>  	{
>  		.procname	= "timeout",
>  		.data		= &coda_timeout,
> diff --git a/fs/coredump.c b/fs/coredump.c
> index d48edb37bc35..591700e1b2ce 100644
> --- a/fs/coredump.c
> +++ b/fs/coredump.c
> @@ -995,7 +995,7 @@ static int proc_dostring_coredump(const struct ctl_table *table, int write,
>  static const unsigned int core_file_note_size_min = CORE_FILE_NOTE_SIZE_DEFAULT;
>  static const unsigned int core_file_note_size_max = CORE_FILE_NOTE_SIZE_MAX;
>  
> -static struct ctl_table coredump_sysctls[] = {
> +static const struct ctl_table coredump_sysctls[] = {
>  	{
>  		.procname	= "core_uses_pid",
>  		.data		= &core_uses_pid,
> diff --git a/fs/dcache.c b/fs/dcache.c
> index b4d5e9e1e43d..370302d4e488 100644
> --- a/fs/dcache.c
> +++ b/fs/dcache.c
> @@ -192,7 +192,7 @@ static int proc_nr_dentry(const struct ctl_table *table, int write, void *buffer
>  	return proc_doulongvec_minmax(table, write, buffer, lenp, ppos);
>  }
>  
> -static struct ctl_table fs_dcache_sysctls[] = {
> +static const struct ctl_table fs_dcache_sysctls[] = {
>  	{
>  		.procname	= "dentry-state",
>  		.data		= &dentry_stat,
> diff --git a/fs/devpts/inode.c b/fs/devpts/inode.c
> index b20e565b9c5e..1096ff8562fa 100644
> --- a/fs/devpts/inode.c
> +++ b/fs/devpts/inode.c
> @@ -45,7 +45,7 @@ static int pty_limit_min;
>  static int pty_limit_max = INT_MAX;
>  static atomic_t pty_count = ATOMIC_INIT(0);
>  
> -static struct ctl_table pty_table[] = {
> +static const struct ctl_table pty_table[] = {
>  	{
>  		.procname	= "max",
>  		.maxlen		= sizeof(int),
> diff --git a/fs/eventpoll.c b/fs/eventpoll.c
> index f9898e60dd8b..7c0980db77b3 100644
> --- a/fs/eventpoll.c
> +++ b/fs/eventpoll.c
> @@ -318,7 +318,7 @@ static void unlist_file(struct epitems_head *head)
>  static long long_zero;
>  static long long_max = LONG_MAX;
>  
> -static struct ctl_table epoll_table[] = {
> +static const struct ctl_table epoll_table[] = {
>  	{
>  		.procname	= "max_user_watches",
>  		.data		= &max_user_watches,
> diff --git a/fs/exec.c b/fs/exec.c
> index 98cb7ba9983c..96229a6a4dff 100644
> --- a/fs/exec.c
> +++ b/fs/exec.c
> @@ -2142,7 +2142,7 @@ static int proc_dointvec_minmax_coredump(const struct ctl_table *table, int writ
>  	return error;
>  }
>  
> -static struct ctl_table fs_exec_sysctls[] = {
> +static const struct ctl_table fs_exec_sysctls[] = {
>  	{
>  		.procname	= "suid_dumpable",
>  		.data		= &suid_dumpable,
> diff --git a/fs/file_table.c b/fs/file_table.c
> index 976736be47cb..70ed0b3a5a0e 100644
> --- a/fs/file_table.c
> +++ b/fs/file_table.c
> @@ -106,7 +106,7 @@ static int proc_nr_files(const struct ctl_table *table, int write, void *buffer,
>  	return proc_doulongvec_minmax(table, write, buffer, lenp, ppos);
>  }
>  
> -static struct ctl_table fs_stat_sysctls[] = {
> +static const struct ctl_table fs_stat_sysctls[] = {
>  	{
>  		.procname	= "file-nr",
>  		.data		= &files_stat,
> diff --git a/fs/fuse/sysctl.c b/fs/fuse/sysctl.c
> index b272bb333005..63fb1e5bee30 100644
> --- a/fs/fuse/sysctl.c
> +++ b/fs/fuse/sysctl.c
> @@ -13,7 +13,7 @@ static struct ctl_table_header *fuse_table_header;
>  /* Bound by fuse_init_out max_pages, which is a u16 */
>  static unsigned int sysctl_fuse_max_pages_limit = 65535;
>  
> -static struct ctl_table fuse_sysctl_table[] = {
> +static const struct ctl_table fuse_sysctl_table[] = {
>  	{
>  		.procname	= "max_pages_limit",
>  		.data		= &fuse_max_pages_limit,
> diff --git a/fs/inode.c b/fs/inode.c
> index 6b4c77268fc0..5587aabdaa5e 100644
> --- a/fs/inode.c
> +++ b/fs/inode.c
> @@ -184,7 +184,7 @@ static int proc_nr_inodes(const struct ctl_table *table, int write, void *buffer
>  	return proc_doulongvec_minmax(table, write, buffer, lenp, ppos);
>  }
>  
> -static struct ctl_table inodes_sysctls[] = {
> +static const struct ctl_table inodes_sysctls[] = {
>  	{
>  		.procname	= "inode-nr",
>  		.data		= &inodes_stat,
> diff --git a/fs/lockd/svc.c b/fs/lockd/svc.c
> index 4ec22c2f2ea3..d6cac1c89c2a 100644
> --- a/fs/lockd/svc.c
> +++ b/fs/lockd/svc.c
> @@ -419,7 +419,7 @@ EXPORT_SYMBOL_GPL(lockd_down);
>   * Sysctl parameters (same as module parameters, different interface).
>   */
>  
> -static struct ctl_table nlm_sysctls[] = {
> +static const struct ctl_table nlm_sysctls[] = {
>  	{
>  		.procname	= "nlm_grace_period",
>  		.data		= &nlm_grace_period,
> diff --git a/fs/locks.c b/fs/locks.c
> index 25afc8d9c9d1..1619cddfa7a4 100644
> --- a/fs/locks.c
> +++ b/fs/locks.c
> @@ -97,7 +97,7 @@ static int leases_enable = 1;
>  static int lease_break_time = 45;
>  
>  #ifdef CONFIG_SYSCTL
> -static struct ctl_table locks_sysctls[] = {
> +static const struct ctl_table locks_sysctls[] = {
>  	{
>  		.procname	= "leases-enable",
>  		.data		= &leases_enable,
> diff --git a/fs/namei.c b/fs/namei.c
> index 9d30c7aa9aa6..6a18b2ea21b7 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -1099,7 +1099,7 @@ static int sysctl_protected_fifos __read_mostly;
>  static int sysctl_protected_regular __read_mostly;
>  
>  #ifdef CONFIG_SYSCTL
> -static struct ctl_table namei_sysctls[] = {
> +static const struct ctl_table namei_sysctls[] = {
>  	{
>  		.procname	= "protected_symlinks",
>  		.data		= &sysctl_protected_symlinks,
> diff --git a/fs/namespace.c b/fs/namespace.c
> index 23e81c2a1e3f..3819c322244e 100644
> --- a/fs/namespace.c
> +++ b/fs/namespace.c
> @@ -5927,7 +5927,7 @@ const struct proc_ns_operations mntns_operations = {
>  };
>  
>  #ifdef CONFIG_SYSCTL
> -static struct ctl_table fs_namespace_sysctls[] = {
> +static const struct ctl_table fs_namespace_sysctls[] = {
>  	{
>  		.procname	= "mount-max",
>  		.data		= &sysctl_mount_max,
> diff --git a/fs/nfs/nfs4sysctl.c b/fs/nfs/nfs4sysctl.c
> index 886a7c4c60b3..d1a92d8f8ba4 100644
> --- a/fs/nfs/nfs4sysctl.c
> +++ b/fs/nfs/nfs4sysctl.c
> @@ -17,7 +17,7 @@ static const int nfs_set_port_min;
>  static const int nfs_set_port_max = 65535;
>  static struct ctl_table_header *nfs4_callback_sysctl_table;
>  
> -static struct ctl_table nfs4_cb_sysctls[] = {
> +static const struct ctl_table nfs4_cb_sysctls[] = {
>  	{
>  		.procname = "nfs_callback_tcpport",
>  		.data = &nfs_callback_set_tcpport,
> diff --git a/fs/nfs/sysctl.c b/fs/nfs/sysctl.c
> index e645be1a3381..f579df0e8d67 100644
> --- a/fs/nfs/sysctl.c
> +++ b/fs/nfs/sysctl.c
> @@ -14,7 +14,7 @@
>  
>  static struct ctl_table_header *nfs_callback_sysctl_table;
>  
> -static struct ctl_table nfs_cb_sysctls[] = {
> +static const struct ctl_table nfs_cb_sysctls[] = {
>  	{
>  		.procname	= "nfs_mountpoint_timeout",
>  		.data		= &nfs_mountpoint_expiry_timeout,

For the nfs bits:
Acked-by: Anna Schumaker <anna.schumaker@oracle.com>

> diff --git a/fs/notify/dnotify/dnotify.c b/fs/notify/dnotify/dnotify.c
> index 6004dfdfdf0f..c4cdaf5fa7ed 100644
> --- a/fs/notify/dnotify/dnotify.c
> +++ b/fs/notify/dnotify/dnotify.c
> @@ -20,7 +20,7 @@
>  
>  static int dir_notify_enable __read_mostly = 1;
>  #ifdef CONFIG_SYSCTL
> -static struct ctl_table dnotify_sysctls[] = {
> +static const struct ctl_table dnotify_sysctls[] = {
>  	{
>  		.procname	= "dir-notify-enable",
>  		.data		= &dir_notify_enable,
> diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c
> index 2d85c71717d6..004cfdae1316 100644
> --- a/fs/notify/fanotify/fanotify_user.c
> +++ b/fs/notify/fanotify/fanotify_user.c
> @@ -58,7 +58,7 @@ static int fanotify_max_queued_events __read_mostly;
>  static long ft_zero = 0;
>  static long ft_int_max = INT_MAX;
>  
> -static struct ctl_table fanotify_table[] = {
> +static const struct ctl_table fanotify_table[] = {
>  	{
>  		.procname	= "max_user_groups",
>  		.data	= &init_user_ns.ucount_max[UCOUNT_FANOTIFY_GROUPS],
> diff --git a/fs/notify/inotify/inotify_user.c b/fs/notify/inotify/inotify_user.c
> index e0c48956608a..b372fb2c56bd 100644
> --- a/fs/notify/inotify/inotify_user.c
> +++ b/fs/notify/inotify/inotify_user.c
> @@ -58,7 +58,7 @@ struct kmem_cache *inotify_inode_mark_cachep __ro_after_init;
>  static long it_zero = 0;
>  static long it_int_max = INT_MAX;
>  
> -static struct ctl_table inotify_table[] = {
> +static const struct ctl_table inotify_table[] = {
>  	{
>  		.procname	= "max_user_instances",
>  		.data		= &init_user_ns.ucount_max[UCOUNT_INOTIFY_INSTANCES],
> diff --git a/fs/ocfs2/stackglue.c b/fs/ocfs2/stackglue.c
> index 20aa37b67cfb..ddd761cf44c8 100644
> --- a/fs/ocfs2/stackglue.c
> +++ b/fs/ocfs2/stackglue.c
> @@ -650,7 +650,7 @@ static int ocfs2_sysfs_init(void)
>   * and easier to preserve the name.
>   */
>  
> -static struct ctl_table ocfs2_nm_table[] = {
> +static const struct ctl_table ocfs2_nm_table[] = {
>  	{
>  		.procname	= "hb_ctl_path",
>  		.data		= ocfs2_hb_ctl_path,
> diff --git a/fs/pipe.c b/fs/pipe.c
> index 12b22c2723b7..638fb318e7be 100644
> --- a/fs/pipe.c
> +++ b/fs/pipe.c
> @@ -1477,7 +1477,7 @@ static int proc_dopipe_max_size(const struct ctl_table *table, int write,
>  				 do_proc_dopipe_max_size_conv, NULL);
>  }
>  
> -static struct ctl_table fs_pipe_sysctls[] = {
> +static const struct ctl_table fs_pipe_sysctls[] = {
>  	{
>  		.procname	= "pipe-max-size",
>  		.data		= &pipe_max_size,
> diff --git a/fs/quota/dquot.c b/fs/quota/dquot.c
> index f9578918cfb2..825c5c2e0962 100644
> --- a/fs/quota/dquot.c
> +++ b/fs/quota/dquot.c
> @@ -2926,7 +2926,7 @@ static int do_proc_dqstats(const struct ctl_table *table, int write,
>  	return proc_doulongvec_minmax(table, write, buffer, lenp, ppos);
>  }
>  
> -static struct ctl_table fs_dqstats_table[] = {
> +static const struct ctl_table fs_dqstats_table[] = {
>  	{
>  		.procname	= "lookups",
>  		.data		= &dqstats.stat[DQST_LOOKUPS],
> diff --git a/fs/sysctls.c b/fs/sysctls.c
> index 8dbde9a802fa..ad429dffeb4b 100644
> --- a/fs/sysctls.c
> +++ b/fs/sysctls.c
> @@ -7,7 +7,7 @@
>  #include <linux/init.h>
>  #include <linux/sysctl.h>
>  
> -static struct ctl_table fs_shared_sysctls[] = {
> +static const struct ctl_table fs_shared_sysctls[] = {
>  	{
>  		.procname	= "overflowuid",
>  		.data		= &fs_overflowuid,
> diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
> index 7c0bd0b55f88..97c4d71115d8 100644
> --- a/fs/userfaultfd.c
> +++ b/fs/userfaultfd.c
> @@ -36,7 +36,7 @@
>  static int sysctl_unprivileged_userfaultfd __read_mostly;
>  
>  #ifdef CONFIG_SYSCTL
> -static struct ctl_table vm_userfaultfd_table[] = {
> +static const struct ctl_table vm_userfaultfd_table[] = {
>  	{
>  		.procname	= "unprivileged_userfaultfd",
>  		.data		= &sysctl_unprivileged_userfaultfd,
> diff --git a/fs/verity/init.c b/fs/verity/init.c
> index f440f0e61e3e..6e8d33b50240 100644
> --- a/fs/verity/init.c
> +++ b/fs/verity/init.c
> @@ -10,7 +10,7 @@
>  #include <linux/ratelimit.h>
>  
>  #ifdef CONFIG_SYSCTL
> -static struct ctl_table fsverity_sysctl_table[] = {
> +static const struct ctl_table fsverity_sysctl_table[] = {
>  #ifdef CONFIG_FS_VERITY_BUILTIN_SIGNATURES
>  	{
>  		.procname       = "require_signatures",
> diff --git a/fs/xfs/xfs_sysctl.c b/fs/xfs/xfs_sysctl.c
> index c84df23b494d..751dc74a3067 100644
> --- a/fs/xfs/xfs_sysctl.c
> +++ b/fs/xfs/xfs_sysctl.c
> @@ -66,7 +66,7 @@ xfs_deprecated_dointvec_minmax(
>  	return proc_dointvec_minmax(ctl, write, buffer, lenp, ppos);
>  }
>  
> -static struct ctl_table xfs_table[] = {
> +static const struct ctl_table xfs_table[] = {
>  	{
>  		.procname	= "irix_sgid_inherit",
>  		.data		= &xfs_params.sgid_inherit.val,
> diff --git a/init/do_mounts_initrd.c b/init/do_mounts_initrd.c
> index 22c7f41ff642..903b4d573d3d 100644
> --- a/init/do_mounts_initrd.c
> +++ b/init/do_mounts_initrd.c
> @@ -21,7 +21,7 @@ phys_addr_t phys_initrd_start __initdata;
>  unsigned long phys_initrd_size __initdata;
>  
>  #ifdef CONFIG_SYSCTL
> -static struct ctl_table kern_do_mounts_initrd_table[] = {
> +static const struct ctl_table kern_do_mounts_initrd_table[] = {
>  	{
>  		.procname       = "real-root-dev",
>  		.data           = &real_root_dev,
> diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c
> index d3403c8216db..72ad31225fb3 100644
> --- a/io_uring/io_uring.c
> +++ b/io_uring/io_uring.c
> @@ -156,7 +156,7 @@ static int __read_mostly sysctl_io_uring_disabled;
>  static int __read_mostly sysctl_io_uring_group = -1;
>  
>  #ifdef CONFIG_SYSCTL
> -static struct ctl_table kernel_io_uring_disabled_table[] = {
> +static const struct ctl_table kernel_io_uring_disabled_table[] = {
>  	{
>  		.procname	= "io_uring_disabled",
>  		.data		= &sysctl_io_uring_disabled,
> diff --git a/ipc/ipc_sysctl.c b/ipc/ipc_sysctl.c
> index 54318e0b4557..15b17e86e198 100644
> --- a/ipc/ipc_sysctl.c
> +++ b/ipc/ipc_sysctl.c
> @@ -73,7 +73,7 @@ int ipc_mni = IPCMNI;
>  int ipc_mni_shift = IPCMNI_SHIFT;
>  int ipc_min_cycle = RADIX_TREE_MAP_SIZE;
>  
> -static struct ctl_table ipc_sysctls[] = {
> +static const struct ctl_table ipc_sysctls[] = {
>  	{
>  		.procname	= "shmmax",
>  		.data		= &init_ipc_ns.shm_ctlmax,
> diff --git a/ipc/mq_sysctl.c b/ipc/mq_sysctl.c
> index b70dc2ff22d8..0dd12e1c9f53 100644
> --- a/ipc/mq_sysctl.c
> +++ b/ipc/mq_sysctl.c
> @@ -20,7 +20,7 @@ static int msg_max_limit_max = HARD_MSGMAX;
>  static int msg_maxsize_limit_min = MIN_MSGSIZEMAX;
>  static int msg_maxsize_limit_max = HARD_MSGSIZEMAX;
>  
> -static struct ctl_table mq_sysctls[] = {
> +static const struct ctl_table mq_sysctls[] = {
>  	{
>  		.procname	= "queues_max",
>  		.data		= &init_ipc_ns.mq_queues_max,
> diff --git a/kernel/acct.c b/kernel/acct.c
> index 179848ad33e9..31222e8cd534 100644
> --- a/kernel/acct.c
> +++ b/kernel/acct.c
> @@ -76,7 +76,7 @@ static int acct_parm[3] = {4, 2, 30};
>  #define ACCT_TIMEOUT	(acct_parm[2])	/* foo second timeout between checks */
>  
>  #ifdef CONFIG_SYSCTL
> -static struct ctl_table kern_acct_table[] = {
> +static const struct ctl_table kern_acct_table[] = {
>  	{
>  		.procname       = "acct",
>  		.data           = &acct_parm,
> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> index 5684e8ce132d..fbcf07f98d8b 100644
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c
> @@ -6124,7 +6124,7 @@ static int bpf_unpriv_handler(const struct ctl_table *table, int write,
>  	return ret;
>  }
>  
> -static struct ctl_table bpf_syscall_table[] = {
> +static const struct ctl_table bpf_syscall_table[] = {
>  	{
>  		.procname	= "unprivileged_bpf_disabled",
>  		.data		= &sysctl_unprivileged_bpf_disabled,
> diff --git a/kernel/delayacct.c b/kernel/delayacct.c
> index dead51de8eb5..75659ac036cd 100644
> --- a/kernel/delayacct.c
> +++ b/kernel/delayacct.c
> @@ -64,7 +64,7 @@ static int sysctl_delayacct(const struct ctl_table *table, int write, void *buff
>  	return err;
>  }
>  
> -static struct ctl_table kern_delayacct_table[] = {
> +static const struct ctl_table kern_delayacct_table[] = {
>  	{
>  		.procname       = "task_delayacct",
>  		.data           = NULL,
> diff --git a/kernel/exit.c b/kernel/exit.c
> index 1dcddfe537ee..3485e5fc499e 100644
> --- a/kernel/exit.c
> +++ b/kernel/exit.c
> @@ -85,7 +85,7 @@
>  static unsigned int oops_limit = 10000;
>  
>  #ifdef CONFIG_SYSCTL
> -static struct ctl_table kern_exit_table[] = {
> +static const struct ctl_table kern_exit_table[] = {
>  	{
>  		.procname       = "oops_limit",
>  		.data           = &oops_limit,
> diff --git a/kernel/hung_task.c b/kernel/hung_task.c
> index c18717189f32..62a5d8927ce9 100644
> --- a/kernel/hung_task.c
> +++ b/kernel/hung_task.c
> @@ -272,7 +272,7 @@ static int proc_dohung_task_timeout_secs(const struct ctl_table *table, int writ
>   * and hung_task_check_interval_secs
>   */
>  static const unsigned long hung_task_timeout_max = (LONG_MAX / HZ);
> -static struct ctl_table hung_task_sysctls[] = {
> +static const struct ctl_table hung_task_sysctls[] = {
>  #ifdef CONFIG_SMP
>  	{
>  		.procname	= "hung_task_all_cpu_backtrace",
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index c0caa14880c3..71b0809e06d6 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -925,7 +925,7 @@ static int kexec_limit_handler(const struct ctl_table *table, int write,
>  	return proc_dointvec(&tmp, write, buffer, lenp, ppos);
>  }
>  
> -static struct ctl_table kexec_core_sysctls[] = {
> +static const struct ctl_table kexec_core_sysctls[] = {
>  	{
>  		.procname	= "kexec_load_disabled",
>  		.data		= &kexec_load_disabled,
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index b027a4030976..9a15fb343be8 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -954,7 +954,7 @@ static int proc_kprobes_optimization_handler(const struct ctl_table *table,
>  	return ret;
>  }
>  
> -static struct ctl_table kprobe_sysctls[] = {
> +static const struct ctl_table kprobe_sysctls[] = {
>  	{
>  		.procname	= "kprobes-optimization",
>  		.data		= &sysctl_kprobes_optimization,
> diff --git a/kernel/latencytop.c b/kernel/latencytop.c
> index 7a75eab9c179..39a5fcdff9f9 100644
> --- a/kernel/latencytop.c
> +++ b/kernel/latencytop.c
> @@ -77,7 +77,7 @@ static int sysctl_latencytop(const struct ctl_table *table, int write, void *buf
>  	return err;
>  }
>  
> -static struct ctl_table latencytop_sysctl[] = {
> +static const struct ctl_table latencytop_sysctl[] = {
>  	{
>  		.procname   = "latencytop",
>  		.data       = &latencytop_enabled,
> diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
> index 2d8ec0351ef9..926b796ba71a 100644
> --- a/kernel/locking/lockdep.c
> +++ b/kernel/locking/lockdep.c
> @@ -79,7 +79,7 @@ module_param(lock_stat, int, 0644);
>  #endif
>  
>  #ifdef CONFIG_SYSCTL
> -static struct ctl_table kern_lockdep_table[] = {
> +static const struct ctl_table kern_lockdep_table[] = {
>  #ifdef CONFIG_PROVE_LOCKING
>  	{
>  		.procname       = "prove_locking",
> diff --git a/kernel/panic.c b/kernel/panic.c
> index fbc59b3b64d0..d8635d5cecb2 100644
> --- a/kernel/panic.c
> +++ b/kernel/panic.c
> @@ -84,7 +84,7 @@ ATOMIC_NOTIFIER_HEAD(panic_notifier_list);
>  EXPORT_SYMBOL(panic_notifier_list);
>  
>  #ifdef CONFIG_SYSCTL
> -static struct ctl_table kern_panic_table[] = {
> +static const struct ctl_table kern_panic_table[] = {
>  #ifdef CONFIG_SMP
>  	{
>  		.procname       = "oops_all_cpu_backtrace",
> diff --git a/kernel/pid_namespace.c b/kernel/pid_namespace.c
> index d70ab49d5b4a..0f23285be4f9 100644
> --- a/kernel/pid_namespace.c
> +++ b/kernel/pid_namespace.c
> @@ -282,7 +282,7 @@ static int pid_ns_ctl_handler(const struct ctl_table *table, int write,
>  }
>  
>  extern int pid_max;
> -static struct ctl_table pid_ns_ctl_table[] = {
> +static const struct ctl_table pid_ns_ctl_table[] = {
>  	{
>  		.procname = "ns_last_pid",
>  		.maxlen = sizeof(int),
> diff --git a/kernel/pid_sysctl.h b/kernel/pid_sysctl.h
> index 18ecaef6be41..5d8f981de7c5 100644
> --- a/kernel/pid_sysctl.h
> +++ b/kernel/pid_sysctl.h
> @@ -31,7 +31,7 @@ static int pid_mfd_noexec_dointvec_minmax(const struct ctl_table *table,
>  	return err;
>  }
>  
> -static struct ctl_table pid_ns_ctl_table_vm[] = {
> +static const struct ctl_table pid_ns_ctl_table_vm[] = {
>  	{
>  		.procname	= "memfd_noexec",
>  		.data		= &init_pid_ns.memfd_noexec_scope,
> diff --git a/kernel/printk/sysctl.c b/kernel/printk/sysctl.c
> index f5072dc85f7a..da77f3f5c1fe 100644
> --- a/kernel/printk/sysctl.c
> +++ b/kernel/printk/sysctl.c
> @@ -20,7 +20,7 @@ static int proc_dointvec_minmax_sysadmin(const struct ctl_table *table, int writ
>  	return proc_dointvec_minmax(table, write, buffer, lenp, ppos);
>  }
>  
> -static struct ctl_table printk_sysctls[] = {
> +static const struct ctl_table printk_sysctls[] = {
>  	{
>  		.procname	= "printk",
>  		.data		= &console_loglevel,
> diff --git a/kernel/reboot.c b/kernel/reboot.c
> index a701000bab34..b5a8569e5d81 100644
> --- a/kernel/reboot.c
> +++ b/kernel/reboot.c
> @@ -1287,7 +1287,7 @@ static struct attribute *reboot_attrs[] = {
>  };
>  
>  #ifdef CONFIG_SYSCTL
> -static struct ctl_table kern_reboot_table[] = {
> +static const struct ctl_table kern_reboot_table[] = {
>  	{
>  		.procname       = "poweroff_cmd",
>  		.data           = &poweroff_cmd,
> diff --git a/kernel/sched/autogroup.c b/kernel/sched/autogroup.c
> index db68a964e34e..83d46b9b8ec8 100644
> --- a/kernel/sched/autogroup.c
> +++ b/kernel/sched/autogroup.c
> @@ -9,7 +9,7 @@ static struct autogroup autogroup_default;
>  static atomic_t autogroup_seq_nr;
>  
>  #ifdef CONFIG_SYSCTL
> -static struct ctl_table sched_autogroup_sysctls[] = {
> +static const struct ctl_table sched_autogroup_sysctls[] = {
>  	{
>  		.procname       = "sched_autogroup_enabled",
>  		.data           = &sysctl_sched_autogroup_enabled,
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 3e5a6bf587f9..00fea6f32ae5 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -4646,7 +4646,7 @@ static int sysctl_schedstats(const struct ctl_table *table, int write, void *buf
>  #endif /* CONFIG_SCHEDSTATS */
>  
>  #ifdef CONFIG_SYSCTL
> -static struct ctl_table sched_core_sysctls[] = {
> +static const struct ctl_table sched_core_sysctls[] = {
>  #ifdef CONFIG_SCHEDSTATS
>  	{
>  		.procname       = "sched_schedstats",
> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index d94f2ed6d1f4..dab4887d6406 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -26,7 +26,7 @@
>  static unsigned int sysctl_sched_dl_period_max = 1 << 22; /* ~4 seconds */
>  static unsigned int sysctl_sched_dl_period_min = 100;     /* 100 us */
>  #ifdef CONFIG_SYSCTL
> -static struct ctl_table sched_dl_sysctls[] = {
> +static const struct ctl_table sched_dl_sysctls[] = {
>  	{
>  		.procname       = "sched_deadline_period_max_us",
>  		.data           = &sysctl_sched_dl_period_max,
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 3e9ca38512de..1692dbb67d7a 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -130,7 +130,7 @@ static unsigned int sysctl_numa_balancing_promote_rate_limit = 65536;
>  #endif
>  
>  #ifdef CONFIG_SYSCTL
> -static struct ctl_table sched_fair_sysctls[] = {
> +static const struct ctl_table sched_fair_sysctls[] = {
>  #ifdef CONFIG_CFS_BANDWIDTH
>  	{
>  		.procname       = "sched_cfs_bandwidth_slice_us",
> diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
> index bd66a46b06ac..4b8e33c615b1 100644
> --- a/kernel/sched/rt.c
> +++ b/kernel/sched/rt.c
> @@ -26,7 +26,7 @@ static int sched_rt_handler(const struct ctl_table *table, int write, void *buff
>  		size_t *lenp, loff_t *ppos);
>  static int sched_rr_handler(const struct ctl_table *table, int write, void *buffer,
>  		size_t *lenp, loff_t *ppos);
> -static struct ctl_table sched_rt_sysctls[] = {
> +static const struct ctl_table sched_rt_sysctls[] = {
>  	{
>  		.procname       = "sched_rt_period_us",
>  		.data           = &sysctl_sched_rt_period,
> diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
> index 9748a4c8d668..20d59b0bc928 100644
> --- a/kernel/sched/topology.c
> +++ b/kernel/sched/topology.c
> @@ -312,7 +312,7 @@ static int sched_energy_aware_handler(const struct ctl_table *table, int write,
>  	return ret;
>  }
>  
> -static struct ctl_table sched_energy_aware_sysctls[] = {
> +static const struct ctl_table sched_energy_aware_sysctls[] = {
>  	{
>  		.procname       = "sched_energy_aware",
>  		.data           = &sysctl_sched_energy_aware,
> diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> index 385d48293a5f..f59381c4a2ff 100644
> --- a/kernel/seccomp.c
> +++ b/kernel/seccomp.c
> @@ -2450,7 +2450,7 @@ static int seccomp_actions_logged_handler(const struct ctl_table *ro_table, int
>  	return ret;
>  }
>  
> -static struct ctl_table seccomp_sysctl_table[] = {
> +static const struct ctl_table seccomp_sysctl_table[] = {
>  	{
>  		.procname	= "actions_avail",
>  		.data		= (void *) &seccomp_actions_avail,
> diff --git a/kernel/signal.c b/kernel/signal.c
> index 989b1cc9116a..77f32c2d6ccb 100644
> --- a/kernel/signal.c
> +++ b/kernel/signal.c
> @@ -4931,7 +4931,7 @@ static inline void siginfo_buildtime_checks(void)
>  }
>  
>  #if defined(CONFIG_SYSCTL)
> -static struct ctl_table signal_debug_table[] = {
> +static const struct ctl_table signal_debug_table[] = {
>  #ifdef CONFIG_SYSCTL_EXCEPTION_TRACE
>  	{
>  		.procname	= "exception-trace",
> diff --git a/kernel/stackleak.c b/kernel/stackleak.c
> index 39fd620a7db6..c1bfc14cd36e 100644
> --- a/kernel/stackleak.c
> +++ b/kernel/stackleak.c
> @@ -44,7 +44,7 @@ static int stack_erasing_sysctl(const struct ctl_table *table, int write,
>  					state ? "enabled" : "disabled");
>  	return ret;
>  }
> -static struct ctl_table stackleak_sysctls[] = {
> +static const struct ctl_table stackleak_sysctls[] = {
>  	{
>  		.procname	= "stack_erasing",
>  		.data		= NULL,
> diff --git a/kernel/sysctl-test.c b/kernel/sysctl-test.c
> index 3ac98bb7fb82..eb2842bd0557 100644
> --- a/kernel/sysctl-test.c
> +++ b/kernel/sysctl-test.c
> @@ -374,7 +374,7 @@ static void sysctl_test_register_sysctl_sz_invalid_extra_value(
>  		struct kunit *test)
>  {
>  	unsigned char data = 0;
> -	struct ctl_table table_foo[] = {
> +	const struct ctl_table table_foo[] = {
>  		{
>  			.procname	= "foo",
>  			.data		= &data,
> @@ -386,7 +386,7 @@ static void sysctl_test_register_sysctl_sz_invalid_extra_value(
>  		},
>  	};
>  
> -	struct ctl_table table_bar[] = {
> +	const struct ctl_table table_bar[] = {
>  		{
>  			.procname	= "bar",
>  			.data		= &data,
> @@ -398,7 +398,7 @@ static void sysctl_test_register_sysctl_sz_invalid_extra_value(
>  		},
>  	};
>  
> -	struct ctl_table table_qux[] = {
> +	const struct ctl_table table_qux[] = {
>  		{
>  			.procname	= "qux",
>  			.data		= &data,
> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> index 5c9202cb8f59..3a0132cb0d5d 100644
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -1609,7 +1609,7 @@ int proc_do_static_key(const struct ctl_table *table, int write,
>  	return ret;
>  }
>  
> -static struct ctl_table kern_table[] = {
> +static const struct ctl_table kern_table[] = {
>  	{
>  		.procname	= "panic",
>  		.data		= &panic_timeout,
> @@ -2030,7 +2030,7 @@ static struct ctl_table kern_table[] = {
>  #endif
>  };
>  
> -static struct ctl_table vm_table[] = {
> +static const struct ctl_table vm_table[] = {
>  	{
>  		.procname	= "overcommit_memory",
>  		.data		= &sysctl_overcommit_memory,
> diff --git a/kernel/time/timer.c b/kernel/time/timer.c
> index a5860bf6d16f..79a1f83d2944 100644
> --- a/kernel/time/timer.c
> +++ b/kernel/time/timer.c
> @@ -301,7 +301,7 @@ static int timer_migration_handler(const struct ctl_table *table, int write,
>  	return ret;
>  }
>  
> -static struct ctl_table timer_sysctl[] = {
> +static const struct ctl_table timer_sysctl[] = {
>  	{
>  		.procname	= "timer_migration",
>  		.data		= &sysctl_timer_migration,
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index 2e113f8b13a2..489cbab3d64c 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -8786,7 +8786,7 @@ ftrace_enable_sysctl(const struct ctl_table *table, int write,
>  	return ret;
>  }
>  
> -static struct ctl_table ftrace_sysctls[] = {
> +static const struct ctl_table ftrace_sysctls[] = {
>  	{
>  		.procname       = "ftrace_enabled",
>  		.data           = &ftrace_enabled,
> diff --git a/kernel/trace/trace_events_user.c b/kernel/trace/trace_events_user.c
> index 17bcad8f79de..97325fbd6283 100644
> --- a/kernel/trace/trace_events_user.c
> +++ b/kernel/trace/trace_events_user.c
> @@ -2899,7 +2899,7 @@ static int set_max_user_events_sysctl(const struct ctl_table *table, int write,
>  	return ret;
>  }
>  
> -static struct ctl_table user_event_sysctls[] = {
> +static const struct ctl_table user_event_sysctls[] = {
>  	{
>  		.procname	= "user_events_max",
>  		.data		= &max_user_events,
> diff --git a/kernel/umh.c b/kernel/umh.c
> index be9234270777..b4da45a3a7cf 100644
> --- a/kernel/umh.c
> +++ b/kernel/umh.c
> @@ -544,7 +544,7 @@ static int proc_cap_handler(const struct ctl_table *table, int write,
>  	return 0;
>  }
>  
> -static struct ctl_table usermodehelper_table[] = {
> +static const struct ctl_table usermodehelper_table[] = {
>  	{
>  		.procname	= "bset",
>  		.data		= &usermodehelper_bset,
> diff --git a/kernel/utsname_sysctl.c b/kernel/utsname_sysctl.c
> index 7282f61a8650..bfbaaecb1dd4 100644
> --- a/kernel/utsname_sysctl.c
> +++ b/kernel/utsname_sysctl.c
> @@ -75,7 +75,7 @@ static DEFINE_CTL_TABLE_POLL(hostname_poll);
>  static DEFINE_CTL_TABLE_POLL(domainname_poll);
>  
>  // Note: update 'enum uts_proc' to match any changes to this table
> -static struct ctl_table uts_kern_table[] = {
> +static const struct ctl_table uts_kern_table[] = {
>  	{
>  		.procname	= "arch",
>  		.data		= init_uts_ns.name.machine,
> @@ -129,7 +129,7 @@ static struct ctl_table uts_kern_table[] = {
>   */
>  void uts_proc_notify(enum uts_proc proc)
>  {
> -	struct ctl_table *table = &uts_kern_table[proc];
> +	const struct ctl_table *table = &uts_kern_table[proc];
>  
>  	proc_sys_poll_notify(table->poll);
>  }
> diff --git a/kernel/watchdog.c b/kernel/watchdog.c
> index 41e0f7e9fa35..613e73ef367c 100644
> --- a/kernel/watchdog.c
> +++ b/kernel/watchdog.c
> @@ -1094,7 +1094,7 @@ static int proc_watchdog_cpumask(const struct ctl_table *table, int write,
>  
>  static const int sixty = 60;
>  
> -static struct ctl_table watchdog_sysctls[] = {
> +static const struct ctl_table watchdog_sysctls[] = {
>  	{
>  		.procname       = "watchdog",
>  		.data		= &watchdog_user_enabled,
> diff --git a/lib/test_sysctl.c b/lib/test_sysctl.c
> index b6696fa1d426..4249e0cc8aaf 100644
> --- a/lib/test_sysctl.c
> +++ b/lib/test_sysctl.c
> @@ -71,7 +71,7 @@ static struct test_sysctl_data test_data = {
>  };
>  
>  /* These are all under /proc/sys/debug/test_sysctl/ */
> -static struct ctl_table test_table[] = {
> +static const struct ctl_table test_table[] = {
>  	{
>  		.procname	= "int_0001",
>  		.data		= &test_data.int_0001,
> @@ -177,7 +177,7 @@ static int test_sysctl_setup_node_tests(void)
>  }
>  
>  /* Used to test that unregister actually removes the directory */
> -static struct ctl_table test_table_unregister[] = {
> +static const struct ctl_table test_table_unregister[] = {
>  	{
>  		.procname	= "unregister_error",
>  		.data		= &test_data.int_0001,
> @@ -220,7 +220,7 @@ static int test_sysctl_run_register_mount_point(void)
>  	return 0;
>  }
>  
> -static struct ctl_table test_table_empty[] = { };
> +static const struct ctl_table test_table_empty[] = { };
>  
>  static int test_sysctl_run_register_empty(void)
>  {
> diff --git a/mm/compaction.c b/mm/compaction.c
> index a2b16b08cbbf..62e8ee230e1c 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -3297,7 +3297,7 @@ static int proc_dointvec_minmax_warn_RT_change(const struct ctl_table *table,
>  	return ret;
>  }
>  
> -static struct ctl_table vm_compaction[] = {
> +static const struct ctl_table vm_compaction[] = {
>  	{
>  		.procname	= "compact_memory",
>  		.data		= &sysctl_compact_memory,
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index c498874a7170..3857b9d72c84 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -4845,7 +4845,7 @@ static int hugetlb_overcommit_handler(const struct ctl_table *table, int write,
>  	return ret;
>  }
>  
> -static struct ctl_table hugetlb_table[] = {
> +static const struct ctl_table hugetlb_table[] = {
>  	{
>  		.procname	= "nr_hugepages",
>  		.data		= NULL,
> diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c
> index 57b7f591eee8..7735972add01 100644
> --- a/mm/hugetlb_vmemmap.c
> +++ b/mm/hugetlb_vmemmap.c
> @@ -693,7 +693,7 @@ void hugetlb_vmemmap_optimize_folios(struct hstate *h, struct list_head *folio_l
>  	free_vmemmap_page_list(&vmemmap_pages);
>  }
>  
> -static struct ctl_table hugetlb_vmemmap_sysctls[] = {
> +static const struct ctl_table hugetlb_vmemmap_sysctls[] = {
>  	{
>  		.procname	= "hugetlb_optimize_vmemmap",
>  		.data		= &vmemmap_optimize_enabled,
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index a7b8ccd29b6f..995a15eb67e2 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -124,7 +124,7 @@ const struct attribute_group memory_failure_attr_group = {
>  	.attrs = memory_failure_attr,
>  };
>  
> -static struct ctl_table memory_failure_table[] = {
> +static const struct ctl_table memory_failure_table[] = {
>  	{
>  		.procname	= "memory_failure_early_kill",
>  		.data		= &sysctl_memory_failure_early_kill,
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index 1c485beb0b93..c8280a39119c 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -699,7 +699,7 @@ static void queue_oom_reaper(struct task_struct *tsk)
>  }
>  
>  #ifdef CONFIG_SYSCTL
> -static struct ctl_table vm_oom_kill_table[] = {
> +static const struct ctl_table vm_oom_kill_table[] = {
>  	{
>  		.procname	= "panic_on_oom",
>  		.data		= &sysctl_panic_on_oom,
> diff --git a/mm/page-writeback.c b/mm/page-writeback.c
> index d213ead95675..fb523107701f 100644
> --- a/mm/page-writeback.c
> +++ b/mm/page-writeback.c
> @@ -2313,7 +2313,7 @@ static int page_writeback_cpu_online(unsigned int cpu)
>  /* this is needed for the proc_doulongvec_minmax of vm_dirty_bytes */
>  static const unsigned long dirty_bytes_min = 2 * PAGE_SIZE;
>  
> -static struct ctl_table vm_page_writeback_sysctls[] = {
> +static const struct ctl_table vm_page_writeback_sysctls[] = {
>  	{
>  		.procname   = "dirty_background_ratio",
>  		.data       = &dirty_background_ratio,
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index cae7b93864c2..6224a2ab5e86 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -6172,7 +6172,7 @@ static int percpu_pagelist_high_fraction_sysctl_handler(const struct ctl_table *
>  	return ret;
>  }
>  
> -static struct ctl_table page_alloc_sysctl_table[] = {
> +static const struct ctl_table page_alloc_sysctl_table[] = {
>  	{
>  		.procname	= "min_free_kbytes",
>  		.data		= &min_free_kbytes,
> diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
> index 1edc12862a7d..9b6c2f157f83 100644
> --- a/security/apparmor/lsm.c
> +++ b/security/apparmor/lsm.c
> @@ -2038,7 +2038,7 @@ static int apparmor_dointvec(const struct ctl_table *table, int write,
>  	return proc_dointvec(table, write, buffer, lenp, ppos);
>  }
>  
> -static struct ctl_table apparmor_sysctl_table[] = {
> +static const struct ctl_table apparmor_sysctl_table[] = {
>  #ifdef CONFIG_USER_NS
>  	{
>  		.procname       = "unprivileged_userns_apparmor_policy",
> diff --git a/security/keys/sysctl.c b/security/keys/sysctl.c
> index 91f000eef3ad..cde08c478f32 100644
> --- a/security/keys/sysctl.c
> +++ b/security/keys/sysctl.c
> @@ -9,7 +9,7 @@
>  #include <linux/sysctl.h>
>  #include "internal.h"
>  
> -static struct ctl_table key_sysctls[] = {
> +static const struct ctl_table key_sysctls[] = {
>  	{
>  		.procname = "maxkeys",
>  		.data = &key_quota_maxkeys,
> diff --git a/security/yama/yama_lsm.c b/security/yama/yama_lsm.c
> index e1a5e13ea269..54bd5f535ac1 100644
> --- a/security/yama/yama_lsm.c
> +++ b/security/yama/yama_lsm.c
> @@ -454,7 +454,7 @@ static int yama_dointvec_minmax(const struct ctl_table *table, int write,
>  
>  static int max_scope = YAMA_SCOPE_NO_ATTACH;
>  
> -static struct ctl_table yama_sysctl_table[] = {
> +static const struct ctl_table yama_sysctl_table[] = {
>  	{
>  		.procname       = "ptrace_scope",
>  		.data           = &ptrace_scope,
> 
> ---
> base-commit: 9d89551994a430b50c4fffcb1e617a057fa76e20
> change-id: 20250109-jag-ctl_table_const-38f6b2ccbba7
> 
> Best regards,



From xen-devel-bounces@lists.xenproject.org Fri Jan 10 18:37:44 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 18:37:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869925.1281380 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWJt6-0005Of-NG; Fri, 10 Jan 2025 18:37:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869925.1281380; Fri, 10 Jan 2025 18:37:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWJt6-0005Nf-JG; Fri, 10 Jan 2025 18:37:40 +0000
Received: by outflank-mailman (input) for mailman id 869925;
 Fri, 10 Jan 2025 18:19: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
 <SRS0=YsBn=UC=broadcom.com=zack.rusin@srs-se1.protection.inumbo.net>)
 id 1tWJb7-00027v-RP
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 18:19:05 +0000
Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com
 [2607:f8b0:4864:20::b2f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5e9d4772-cf7f-11ef-99a4-01e77a169b0f;
 Fri, 10 Jan 2025 19:19:03 +0100 (CET)
Received: by mail-yb1-xb2f.google.com with SMTP id
 3f1490d57ef6-e53aa843a24so4116401276.0
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 10:19:03 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5e9d4772-cf7f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=broadcom.com; s=google; t=1736533142; x=1737137942; 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=yx3EMaFMrWjzw0VsMxL5g/k5qM03FCYSbNf/1h0It2U=;
        b=YQyWYfkdrm+AZN0aQuTS55vF1w1+qdqGxS4FECiO7rTuc3LhFdUaYtADC9nC1ghGdS
         AVGutOcT1idoOuAQJz0dXnnh4Ffe6r/RIYS22b9GE8lXZtqDotfg8R5GzXLn+roT08Tz
         3nc2l39D7Xmk2O78yCHPgEKVbyj4D8vfWdqM8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736533142; x=1737137942;
        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=yx3EMaFMrWjzw0VsMxL5g/k5qM03FCYSbNf/1h0It2U=;
        b=nX8A1s1inivVr89np699R8buzgmcrPlLWJUvzqkcmNEGPdR56Yre1LS60S3UD4OIg6
         kP2KWpH8MVnGbWLvvLrliOGAqW99gpbJ9FZAj4sh1fzZVNYsH5sE1q+b9h2GHQW/eOSz
         v1PMdO61FOU87Rd0dXDZwu2wW51RtUhOoQ0286KQv8nzFfSEl1bZOJ0AwMmKtOLCyiQT
         yUPy9fQjsG08sLl/vtDtIfePPt+l2CH833Na63zFa6UjkF1uFZr43Z7nfYCYqUJgycBy
         t8TT9YFUNMw8shY0AkUyffEn9Hdx9qe9EEUndWk6NPlPraIKhZmn6KUOklJaEpgC3GhN
         tVVA==
X-Forwarded-Encrypted: i=1; AJvYcCXU1EjZ7RnHvXoJn6V5yIr0tLhh0q76+Oo5gitJ7bHak23dY71r8l/DXil/QbwF24avRPa8PfA4ruI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyavNMOHu5sADegheS4n0e4C9saXINGw7iuc6ytreZtnTSHLIzn
	SCGNGPeKrY8C7HYgbhbrAOxpZhoUIL2XtRVknAyQnQ3ZgiwehnNdcwy4cOYs+CWRN1Vun2YneDp
	DtVio9NRcH+e41cGu1OAKP2dcYhMHznBqAGuE
X-Gm-Gg: ASbGnctetMUCOyH51cfigMdu3F9SubIMPZt90xqb52Lk6X+NkjK5VuoWh575tdzdqIh
	y56JutsIvce0yYewmYlE+6rreD/vg1c2qO4Fum/8=
X-Google-Smtp-Source: AGHT+IG68OAzM5b5uf0JyNPYgeB3WMd2S+NO1tRJCMNeoQvnjEeeKIyzy46kXlZoZSJgEjL84r9mcoxyAdeuO7oqkZg=
X-Received: by 2002:a25:c752:0:b0:e48:d191:12b2 with SMTP id
 3f1490d57ef6-e55014be84fmr6061119276.26.1736533142177; Fri, 10 Jan 2025
 10:19:02 -0800 (PST)
MIME-Version: 1.0
References: <20250109150310.219442-1-tzimmermann@suse.de> <20250109150310.219442-23-tzimmermann@suse.de>
In-Reply-To: <20250109150310.219442-23-tzimmermann@suse.de>
From: Zack Rusin <zack.rusin@broadcom.com>
Date: Fri, 10 Jan 2025 13:18:51 -0500
X-Gm-Features: AbW1kvZzlDDKlGMtHGeJyeSoNM836xS8RK3Ch58qMqsRR9RgTi73KCxjkvbAAXU
Message-ID: <CABQX2QPSMnhM-g_bEJQ4k+J0JACQOA1DO4xeUa7+735LNgEoXQ@mail.gmail.com>
Subject: Re: [PATCH v2 22/25] drm/vmwgfx: Compute dumb-buffer sizes with drm_mode_size_dumb()
To: Thomas Zimmermann <tzimmermann@suse.de>
Cc: maarten.lankhorst@linux.intel.com, mripard@kernel.org, airlied@gmail.com, 
	simona@ffwll.ch, dri-devel@lists.freedesktop.org, 
	linux-mediatek@lists.infradead.org, freedreno@lists.freedesktop.org, 
	linux-arm-msm@vger.kernel.org, imx@lists.linux.dev, 
	linux-samsung-soc@vger.kernel.org, nouveau@lists.freedesktop.org, 
	virtualization@lists.linux.dev, spice-devel@lists.freedesktop.org, 
	linux-renesas-soc@vger.kernel.org, linux-rockchip@lists.infradead.org, 
	linux-tegra@vger.kernel.org, intel-xe@lists.freedesktop.org, 
	xen-devel@lists.xenproject.org, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256;
	boundary="0000000000001931a2062b5e21d5"

--0000000000001931a2062b5e21d5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 9, 2025 at 10:03=E2=80=AFAM Thomas Zimmermann <tzimmermann@suse=
.de> wrote:
>
> Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch
> and buffer size. No alignment required.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Zack Rusin <zack.rusin@broadcom.com>
> Cc: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadc=
om.com>
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 21 ++++-----------------
>  1 file changed, 4 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c b/drivers/gpu/drm/vm=
wgfx/vmwgfx_surface.c
> index 5721c74da3e0..a3fbd4148f73 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> @@ -34,6 +34,7 @@
>  #include "vmw_surface_cache.h"
>  #include "device_include/svga3d_surfacedefs.h"
>
> +#include <drm/drm_dumb_buffers.h>
>  #include <drm/ttm/ttm_placement.h>
>
>  #define SVGA3D_FLAGS_64(upper32, lower32) (((uint64_t)upper32 << 32) | l=
ower32)
> @@ -2291,23 +2292,9 @@ int vmw_dumb_create(struct drm_file *file_priv,
>          * contents is going to be rendered guest side.
>          */
>         if (!dev_priv->has_mob || !vmw_supports_3d(dev_priv)) {
> -               int cpp =3D DIV_ROUND_UP(args->bpp, 8);
> -
> -               switch (cpp) {
> -               case 1: /* DRM_FORMAT_C8 */
> -               case 2: /* DRM_FORMAT_RGB565 */
> -               case 4: /* DRM_FORMAT_XRGB8888 */
> -                       break;
> -               default:
> -                       /*
> -                        * Dumb buffers don't allow anything else.
> -                        * This is tested via IGT's dumb_buffers
> -                        */
> -                       return -EINVAL;
> -               }
> -
> -               args->pitch =3D args->width * cpp;
> -               args->size =3D ALIGN(args->pitch * args->height, PAGE_SIZ=
E);
> +               ret =3D drm_mode_size_dumb(dev, args, 0, 0);
> +               if (ret)
> +                       return ret;
>
>                 ret =3D vmw_gem_object_create_with_handle(dev_priv, file_=
priv,
>                                                         args->size, &args=
->handle,
> --
> 2.47.1
>

Ah, that's great. Thanks!

Reviewed-by: Zack Rusin <zack.rusin@broadcom.com>

z

--0000000000001931a2062b5e21d5
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIVLwYJKoZIhvcNAQcCoIIVIDCCFRwCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg
ghKPMIIGqDCCBJCgAwIBAgIQfofDCS7XZu8vIeKo0KeY9DANBgkqhkiG9w0BAQwFADBMMSAwHgYD
VQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSNjETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UE
AxMKR2xvYmFsU2lnbjAeFw0yMzA0MTkwMzUzNTNaFw0yOTA0MTkwMDAwMDBaMFIxCzAJBgNVBAYT
AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSgwJgYDVQQDEx9HbG9iYWxTaWduIEdDQyBS
NiBTTUlNRSBDQSAyMDIzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwjAEbSkPcSyn
26Zn9VtoE/xBvzYmNW29bW1pJZ7jrzKwPJm/GakCvy0IIgObMsx9bpFaq30X1kEJZnLUzuE1/hlc
hatYqyORVBeHlv5V0QRSXY4faR0dCkIhXhoGknZ2O0bUJithcN1IsEADNizZ1AJIaWsWbQ4tYEYj
ytEdvfkxz1WtX3SjtecZR+9wLJLt6HNa4sC//QKdjyfr/NhDCzYrdIzAssoXFnp4t+HcMyQTrj0r
pD8KkPj96sy9axzegLbzte7wgTHbWBeJGp0sKg7BAu+G0Rk6teO1yPd75arbCvfY/NaRRQHk6tmG
71gpLdB1ZhP9IcNYyeTKXIgfMh2tVK9DnXGaksYCyi6WisJa1Oa+poUroX2ESXO6o03lVxiA1xyf
G8lUzpUNZonGVrUjhG5+MdY16/6b0uKejZCLbgu6HLPvIyqdTb9XqF4XWWKu+OMDs/rWyQ64v3mv
Sa0te5Q5tchm4m9K0Pe9LlIKBk/gsgfaOHJDp4hYx4wocDr8DeCZe5d5wCFkxoGc1ckM8ZoMgpUc
4pgkQE5ShxYMmKbPvNRPa5YFzbFtcFn5RMr1Mju8gt8J0c+dxYco2hi7dEW391KKxGhv7MJBcc+0
x3FFTnmhU+5t6+CnkKMlrmzyaoeVryRTvOiH4FnTNHtVKUYDsCM0CLDdMNgoxgkCAwEAAaOCAX4w
ggF6MA4GA1UdDwEB/wQEAwIBhjBMBgNVHSUERTBDBggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQB
gjcUAgIGCisGAQQBgjcKAwwGCisGAQQBgjcKAwQGCSsGAQQBgjcVBjASBgNVHRMBAf8ECDAGAQH/
AgEAMB0GA1UdDgQWBBQAKTaeXHq6D68tUC3boCOFGLCgkjAfBgNVHSMEGDAWgBSubAWjkxPioufi
1xzWx/B/yGdToDB7BggrBgEFBQcBAQRvMG0wLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwMi5nbG9i
YWxzaWduLmNvbS9yb290cjYwOwYIKwYBBQUHMAKGL2h0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5j
b20vY2FjZXJ0L3Jvb3QtcjYuY3J0MDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuZ2xvYmFs
c2lnbi5jb20vcm9vdC1yNi5jcmwwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEBDAUAA4IC
AQCRkUdr1aIDRmkNI5jx5ggapGUThq0KcM2dzpMu314mJne8yKVXwzfKBtqbBjbUNMODnBkhvZcn
bHUStur2/nt1tP3ee8KyNhYxzv4DkI0NbV93JChXipfsan7YjdfEk5vI2Fq+wpbGALyyWBgfy79Y
IgbYWATB158tvEh5UO8kpGpjY95xv+070X3FYuGyeZyIvao26mN872FuxRxYhNLwGHIy38N9ASa1
Q3BTNKSrHrZngadofHglG5W3TMFR11JOEOAUHhUgpbVVvgCYgGA6dSX0y5z7k3rXVyjFOs7KBSXr
dJPKadpl4vqYphH7+P40nzBRcxJHrv5FeXlTrb+drjyXNjZSCmzfkOuCqPspBuJ7vab0/9oeNERg
nz6SLCjLKcDXbMbKcRXgNhFBlzN4OUBqieSBXk80w2Nzx12KvNj758WavxOsXIbX0Zxwo1h3uw75
AI2v8qwFWXNclO8qW2VXoq6kihWpeiuvDmFfSAwRLxwwIjgUuzG9SaQ+pOomuaC7QTKWMI0hL0b4
mEPq9GsPPQq1UmwkcYFJ/Z4I93DZuKcXmKMmuANTS6wxwIEw8Q5MQ6y9fbJxGEOgOgYL4QIqNULb
5CYPnt2LeiIiEnh8Uuh8tawqSjnR0h7Bv5q4mgo3L1Z9QQuexUntWD96t4o0q1jXWLyrpgP7Zcnu
CzCCBYMwggNroAMCAQICDkXmuwODM8OFZUjm/0VRMA0GCSqGSIb3DQEBDAUAMEwxIDAeBgNVBAsT
F0dsb2JhbFNpZ24gUm9vdCBDQSAtIFI2MRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpH
bG9iYWxTaWduMB4XDTE0MTIxMDAwMDAwMFoXDTM0MTIxMDAwMDAwMFowTDEgMB4GA1UECxMXR2xv
YmFsU2lnbiBSb290IENBIC0gUjYxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2Jh
bFNpZ24wggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCVB+hzymb57BTKezz3DQjxtEUL
LIK0SMbrWzyug7hBkjMUpG9/6SrMxrCIa8W2idHGsv8UzlEUIexK3RtaxtaH7k06FQbtZGYLkoDK
RN5zlE7zp4l/T3hjCMgSUG1CZi9NuXkoTVIaihqAtxmBDn7EirxkTCEcQ2jXPTyKxbJm1ZCatzEG
xb7ibTIGph75ueuqo7i/voJjUNDwGInf5A959eqiHyrScC5757yTu21T4kh8jBAHOP9msndhfuDq
jDyqtKT285VKEgdt/Yyyic/QoGF3yFh0sNQjOvddOsqi250J3l1ELZDxgc1Xkvp+vFAEYzTfa5MY
vms2sjnkrCQ2t/DvthwTV5O23rL44oW3c6K4NapF8uCdNqFvVIrxclZuLojFUUJEFZTuo8U4lptO
TloLR/MGNkl3MLxxN+Wm7CEIdfzmYRY/d9XZkZeECmzUAk10wBTt/Tn7g/JeFKEEsAvp/u6P4W4L
sgizYWYJarEGOmWWWcDwNf3J2iiNGhGHcIEKqJp1HZ46hgUAntuA1iX53AWeJ1lMdjlb6vmlodiD
D9H/3zAR+YXPM0j1ym1kFCx6WE/TSwhJxZVkGmMOeT31s4zKWK2cQkV5bg6HGVxUsWW2v4yb3BPp
DW+4LtxnbsmLEbWEFIoAGXCDeZGXkdQaJ783HjIH2BRjPChMrwIDAQABo2MwYTAOBgNVHQ8BAf8E
BAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUrmwFo5MT4qLn4tcc1sfwf8hnU6AwHwYD
VR0jBBgwFoAUrmwFo5MT4qLn4tcc1sfwf8hnU6AwDQYJKoZIhvcNAQEMBQADggIBAIMl7ejR/ZVS
zZ7ABKCRaeZc0ITe3K2iT+hHeNZlmKlbqDyHfAKK0W63FnPmX8BUmNV0vsHN4hGRrSMYPd3hckSW
tJVewHuOmXgWQxNWV7Oiszu1d9xAcqyj65s1PrEIIaHnxEM3eTK+teecLEy8QymZjjDTrCHg4x36
2AczdlQAIiq5TSAucGja5VP8g1zTnfL/RAxEZvLS471GABptArolXY2hMVHdVEYcTduZlu8aHARc
phXveOB5/l3bPqpMVf2aFalv4ab733Aw6cPuQkbtwpMFifp9Y3s/0HGBfADomK4OeDTDJfuvCp8g
a907E48SjOJBGkh6c6B3ace2XH+CyB7+WBsoK6hsrV5twAXSe7frgP4lN/4Cm2isQl3D7vXM3PBQ
ddI2aZzmewTfbgZptt4KCUhZh+t7FGB6ZKppQ++Rx0zsGN1s71MtjJnhXvJyPs9UyL1n7KQPTEX/
07kwIwdMjxC/hpbZmVq0mVccpMy7FYlTuiwFD+TEnhmxGDTVTJ267fcfrySVBHioA7vugeXaX3yL
SqGQdCWnsz5LyCxWvcfI7zjiXJLwefechLp0LWEBIH5+0fJPB1lfiy1DUutGDJTh9WZHeXfVVFsf
rSQ3y0VaTqBESMjYsJnFFYQJ9tZJScBluOYacW6gqPGC6EU+bNYC1wpngwVayaQQMIIGWDCCBECg
AwIBAgIMYT8cPnonh1geNIT5MA0GCSqGSIb3DQEBCwUAMFIxCzAJBgNVBAYTAkJFMRkwFwYDVQQK
ExBHbG9iYWxTaWduIG52LXNhMSgwJgYDVQQDEx9HbG9iYWxTaWduIEdDQyBSNiBTTUlNRSBDQSAy
MDIzMB4XDTI0MTEyODA2NTUwOVoXDTI2MTEyOTA2NTUwOVowgaUxCzAJBgNVBAYTAlVTMRMwEQYD
VQQIEwpDYWxpZm9ybmlhMREwDwYDVQQHEwhTYW4gSm9zZTEZMBcGA1UEYRMQTlRSVVMrREUtNjYx
MDExNzEWMBQGA1UEChMNQlJPQURDT00gSU5DLjETMBEGA1UEAxMKWmFjayBSdXNpbjEmMCQGCSqG
SIb3DQEJARYXemFjay5ydXNpbkBicm9hZGNvbS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQCwQ8KpnuEwUOX0rOrLRj3vS0VImknKwshcmcfA9VtdEQhJHGDQoNjaBEFQHqLqn4Lf
hqEGUo+nKhz2uqGl2MtQFb8oG+yJPCFPgeSvbiRxmeOwSP0jrNADVKpYpy4UApPqS+UfVQXKbwbM
6U6qgI8F5eiKsQyE0HgYrQJx/sDs9LLVZlaNiA3U8M8CgEnb8VhuH3BN/yXphhEQdJXb1TyaJA60
SmHcZdEQZbl4EjwUcs3UIowmI/Mhi7ADQB7VNsO/BaOVBEQk53xH+4djY/cg7jvqTTeliY05j2Yx
uwwXcDC4mWjGzxAT5DVqC8fKQvon1uc2heorHb555+sLdwYxAgMBAAGjggHYMIIB1DAOBgNVHQ8B
Af8EBAMCBaAwgZMGCCsGAQUFBwEBBIGGMIGDMEYGCCsGAQUFBzAChjpodHRwOi8vc2VjdXJlLmds
b2JhbHNpZ24uY29tL2NhY2VydC9nc2djY3I2c21pbWVjYTIwMjMuY3J0MDkGCCsGAQUFBzABhi1o
dHRwOi8vb2NzcC5nbG9iYWxzaWduLmNvbS9nc2djY3I2c21pbWVjYTIwMjMwZQYDVR0gBF4wXDAJ
BgdngQwBBQMBMAsGCSsGAQQBoDIBKDBCBgorBgEEAaAyCgMCMDQwMgYIKwYBBQUHAgEWJmh0dHBz
Oi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMAkGA1UdEwQCMAAwQQYDVR0fBDowODA2
oDSgMoYwaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9nc2djY3I2c21pbWVjYTIwMjMuY3JsMCIG
A1UdEQQbMBmBF3phY2sucnVzaW5AYnJvYWRjb20uY29tMBMGA1UdJQQMMAoGCCsGAQUFBwMEMB8G
A1UdIwQYMBaAFAApNp5ceroPry1QLdugI4UYsKCSMB0GA1UdDgQWBBQNDn2m/OLuDx9YjEqPLCDB
s/VKNTANBgkqhkiG9w0BAQsFAAOCAgEAF463syOLTQkWZmEyyR60W1sM3J1cbnMRrBFUBt3S2NTY
SJ2NAvkTAxbPoOhK6IQdaTyrWi8xdg2tftr5FC1bOSUdxudY6dipq2txe7mEoUE6VlpJid/56Mo4
QJRb6YiykQeIfoJiYMKsyuXWsTB1rhQxlxfnaFxi8Xy3+xKAeX68DcsHG3ZU0h1beBURA44tXcz6
fFDNPQ2k6rWDFz+XNN2YOPqfse2wEm3DXpqNT79ycU7Uva7e51b8XdbmJ6XVzUFmWzhjXy5hvV8z
iF+DvP+KT1/bjO6aNL2/3PWiy1u6xjnWvobHuAYVrXxQ5wzk8aPOnED9Q8pt2nqk/UIzw2f67Cn9
3CxrVqXUKm93J+rupyKVTGgKO9T1ODVPo665aIbM72RxSI9Wsofatm2fo8DWOkrfs29pYfy6eECl
91qfFMl+IzIVfDgIrEX6gSngJ2ZLaG6L+/iNrUxHxxsaUmyDwBbTfjYwr10H6NKES3JaxVRslnpF
06HTTciJNx2wowbYF1c+BFY4r/19LHygijIVa+hZEgNuMrVLyAamaAKZ1AWxTdv8Q/eeNN3Myq61
b1ykTSPCXjBq/03CMF/wT1wly16jYjLDXZ6II/HYyJt34QeqnBENU9zXTc9RopqcuHD2g+ROT7lI
VLi5ffzC8rVliltTltbYPc7F0lAvGKAxggJkMIICYAIBATBiMFIxCzAJBgNVBAYTAkJFMRkwFwYD
VQQKExBHbG9iYWxTaWduIG52LXNhMSgwJgYDVQQDEx9HbG9iYWxTaWduIEdDQyBSNiBTTUlNRSBD
QSAyMDIzAgxhPxw+eieHWB40hPkwDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIF8k
iV8mBqdxbIZzd4Ma5kYkUaB/1B/FFIB8m0a7K2rcMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw
HAYJKoZIhvcNAQkFMQ8XDTI1MDExMDE4MTkwMlowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQME
ASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJ
KoZIhvcNAQEHMAsGCWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQAtXQWXsyXu7oPSja5TTm47
rcmcPO5Jz4cUsDF7thHC75MBBzNP8V5FFgZsyiLhssf8+OPL91MCP/AC9mJ5XPDUQfBWjuDszPan
GvkTcS+Wsaje+VEQrt7EkeyArnOeAAIKz4l/nEOzPpHNqi4X15a6uLuEchMGuXbxJILWfLU+bquO
hgXX3eU0IHy0aKu/20XWSrnQhh5YI6rdaFFis9I86YwuY7kb6nSWGNlSHLCFby/G9ItXj3imTUbA
U1fQdvGr1RhFXxvRPL5xyZ0nGc/TSfW5Npxdxuo3+qyPolJczO1IerOeMkmvXBk4TNWJOjMoNqoo
SE2JFrtDgrqiN5JR
--0000000000001931a2062b5e21d5--


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 18:43:49 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 18:43:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869967.1281406 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWJyy-0008CK-0y; Fri, 10 Jan 2025 18:43:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869967.1281406; Fri, 10 Jan 2025 18:43:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWJyx-0008CD-To; Fri, 10 Jan 2025 18:43:43 +0000
Received: by outflank-mailman (input) for mailman id 869967;
 Fri, 10 Jan 2025 18:43:42 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=J0bo=UC=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tWJyw-0008C5-QQ
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 18:43:42 +0000
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com
 [2a00:1450:4864:20::436])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id cf610183-cf82-11ef-99a4-01e77a169b0f;
 Fri, 10 Jan 2025 19:43:40 +0100 (CET)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-3863703258fso2255835f8f.1
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 10:43:40 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a8e38f176sm5297229f8f.63.2025.01.10.10.43.39
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 10 Jan 2025 10:43:39 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: cf610183-cf82-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736534620; x=1737139420; 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=9RUcgbbd9A2Ysu4ejuh6/L2x2LitZdWVx8FGvddnSeM=;
        b=mOSVgEmcwSYdpL6R6wnoou8KDuwxkDG1PEPhWl6P4lH3aZyURBdCnpLdE4Olrs+lwd
         KD5jp/6Ls2dNTR/vdAKpxgdp2PXbeoEjv5CT/4h6Y5ZP2vCfr+xTolI3QrpUR6CdmMsq
         izjOjCe1ofxYVIlZUdItLl45SolQeSSVoV3aA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736534620; x=1737139420;
        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=9RUcgbbd9A2Ysu4ejuh6/L2x2LitZdWVx8FGvddnSeM=;
        b=I2idBxoioF56MMkRI+IenIrv/uzE/eFkVXDiHCK7EGFMFyX/VkCqJoIORO+h6T/sYq
         1M7os+X0KTCkJiyFKLiUUYL0tZHeKATgYnXtVHa9BscH21TEcbxjbunwyaE9k8h21bn+
         v0KsanpEtmJltBJ0YiGLayU2tMCCtwFV/7mqphFOaleQS+z0d9OQeCVBrNkqTu4CcTG3
         0RPkrNKOHWistK168bUAGlFOK6Y25LI9ufdXz/9ToaSZhzKSLupvP/MhPF06xq+KcRYY
         ot8L3mxF6qAA3jyzO141Tmn22warSZQoiqt+oVgb6AzzTk0/60Q7fa2dUjKKmTHxJJRs
         8tdA==
X-Gm-Message-State: AOJu0YwBPkBDv/NxGgPM9g+INVC04c4/VKxmdrMWeO1aLac67dwrrC9K
	7J/V5xcO1dLttbLUf3sM/kMS9Vex9a7nKeUI9DNwaKNWjoP/EShQaB03YXZWYUU=
X-Gm-Gg: ASbGnctZtT3Ai9MP8nb1P5Uv0sCOWUtr7T26p/EI04OoebbDBlCv1TDa4BAo1kNpEg6
	v+wNGE9NbdVtgTvfVLyFUz/ApIsz6rYsGfoDnt7zL8NNcC1zPkj0jLwG4DOMZL7WCH91keuuXrL
	0QYAhL8cTeY1XJTMg8AzFEQZb9I+Yf2CBSaneVaXaFkE2OhBm/Lnsn7v6dL6Fp9RMNzdOYeZNJO
	siXZ4di1UyUfyGf6oKfOGMvnPkNwEpwP74LyY9pr9+PLkmQsISph3Y/8ao5yA==
X-Google-Smtp-Source: AGHT+IEwPl0S6flCmA6fL+G1MDh2bDhmoJoQTpFxFsc/Kn+K5PV6eReabADsaqtnHYdghASmsasA2w==
X-Received: by 2002:adf:b606:0:b0:38a:8d32:2707 with SMTP id ffacd0b85a97d-38a8d32287cmr5746735f8f.26.1736534620137;
        Fri, 10 Jan 2025 10:43:40 -0800 (PST)
Date: Fri, 10 Jan 2025 19:43:38 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Alejandro Vallejo <alejandro.vallejo@cloud.com>
Cc: xen-devel@lists.xenproject.org, Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v2 15/18] x86/mm: introduce a per-vCPU mapcache when
 using ASI
Message-ID: <Z4FqWkjdmemiJ8Du@macbook.local>
References: <20250108142659.99490-1-roger.pau@citrix.com>
 <20250108142659.99490-16-roger.pau@citrix.com>
 <D6XMXUBHE5UI.16YI6AVTYXNUM@cloud.com>
 <Z4E2nhxxIKO8sWoz@macbook.local>
 <D6YJ2L9AFQOQ.2ZZ5H8O4SK9J4@cloud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <D6YJ2L9AFQOQ.2ZZ5H8O4SK9J4@cloud.com>

On Fri, Jan 10, 2025 at 04:19:03PM +0000, Alejandro Vallejo wrote:
> On Fri Jan 10, 2025 at 3:02 PM GMT, Roger Pau Monné wrote:
> > On Thu, Jan 09, 2025 at 03:08:15PM +0000, Alejandro Vallejo wrote:
> > > On Wed Jan 8, 2025 at 2:26 PM GMT, Roger Pau Monne wrote:
> > > > When using a unique per-vCPU root page table the per-domain region becomes
> > > > per-vCPU, and hence the mapcache is no longer shared between all vCPUs of a
> > > > domain.  Introduce per-vCPU mapcache structures, and modify map_domain_page()
> > > > to create per-vCPU mappings when possible.  Note the lock is also not needed
> > > > with using per-vCPU map caches, as the structure is no longer shared.
> > > >
> > > > This introduces some duplication in the domain and vcpu structures, as both
> > > > contain a mapcache field to support running with and without per-vCPU
> > > > page-tables.
> > > >
> > > > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> > > > ---
> > > >  xen/arch/x86/domain_page.c        | 90 ++++++++++++++++++++-----------
> > > >  xen/arch/x86/include/asm/domain.h | 20 ++++---
> > > >  2 files changed, 71 insertions(+), 39 deletions(-)
> > > >
> > > > diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c
> > > > index 1372be20224e..65900d6218f8 100644
> > > > --- a/xen/arch/x86/domain_page.c
> > > > +++ b/xen/arch/x86/domain_page.c
> > > > @@ -74,7 +74,9 @@ void *map_domain_page(mfn_t mfn)
> > > >      struct vcpu *v;
> > > >      struct mapcache_domain *dcache;
> > > >      struct mapcache_vcpu *vcache;
> > > > +    struct mapcache *cache;
> > > >      struct vcpu_maphash_entry *hashent;
> > > > +    struct domain *d;
> > > >  
> > > >  #ifdef NDEBUG
> > > >      if ( mfn_x(mfn) <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) )
> > > > @@ -85,9 +87,12 @@ void *map_domain_page(mfn_t mfn)
> > > >      if ( !v || !is_pv_vcpu(v) )
> > > >          return mfn_to_virt(mfn_x(mfn));
> > > >  
> > > > -    dcache = &v->domain->arch.pv.mapcache;
> > > > +    d = v->domain;
> > > > +    dcache = &d->arch.pv.mapcache;
> > > >      vcache = &v->arch.pv.mapcache;
> > > > -    if ( !dcache->inuse )
> > > > +    cache = d->arch.vcpu_pt ? &v->arch.pv.mapcache.cache
> > > > +                            : &d->arch.pv.mapcache.cache;
> > > > +    if ( !cache->inuse )
> > > >          return mfn_to_virt(mfn_x(mfn));
> > > >  
> > > >      perfc_incr(map_domain_page_count);
> > > > @@ -98,17 +103,18 @@ void *map_domain_page(mfn_t mfn)
> > > >      if ( hashent->mfn == mfn_x(mfn) )
> > > >      {
> > > >          idx = hashent->idx;
> > > > -        ASSERT(idx < dcache->entries);
> > > > +        ASSERT(idx < cache->entries);
> > > >          hashent->refcnt++;
> > > >          ASSERT(hashent->refcnt);
> > > >          ASSERT(mfn_eq(l1e_get_mfn(MAPCACHE_L1ENT(idx)), mfn));
> > > >          goto out;
> > > >      }
> > > >  
> > > > -    spin_lock(&dcache->lock);
> > > > +    if ( !d->arch.vcpu_pt )
> > > > +        spin_lock(&dcache->lock);
> > > 
> > > Hmmm. I wonder whether we might not want a nospec here...
> >
> > Not sure TBH, we have other instances of conditional locking that
> > doesn't use nospec().  That said I'm not claiming those are correct.
> > Shouldn't people that care about this kind of speculation into
> > critical regions just use CONFIG_SPECULATIVE_HARDEN_LOCK?
> >
> > Thanks, Roger.
> 
> Actually, to avoid the double lfence, I think this would work too while
> avoiding the lfence unconditionally when CONFIG_SPECULATIVE_HARDEN_LOCK is not
> set.
> 
>     if ( !d->arch.vcpu_pt )
>         spin_lock(&dcache->lock);
>     else
>         block_lock_speculation();

We have a spin_lock_if() helper to do that.  I will use it here.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 19:18:22 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 19:18:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869975.1281415 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWKWP-0005rK-55; Fri, 10 Jan 2025 19:18:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869975.1281415; Fri, 10 Jan 2025 19:18:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWKWP-0005rD-2a; Fri, 10 Jan 2025 19:18:17 +0000
Received: by outflank-mailman (input) for mailman id 869975;
 Fri, 10 Jan 2025 19:18:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=RTL5=UC=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tWKWO-0005r7-2w
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 19:18:16 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a30a35ee-cf87-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 20:18:14 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id BA6B8A42937;
 Fri, 10 Jan 2025 19:16:24 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 34466C4CED6;
 Fri, 10 Jan 2025 19:18:12 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a30a35ee-cf87-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1736536692;
	bh=P0rrENVupjljQAdNHY5ftg+WiSq/hBYySSWFBTXPMAs=;
	h=Date:From:To:cc:Subject:From;
	b=o+SkMv+WxyG/EEjY+nQRspih85RUi/osrEszU4HxebVOEBYWvT10dBUx2cmnpyvrf
	 PPtM+dTrVBkxBU2Hl7/VMjtFItbLy7KQ4eB+6lWwHewq/JuWF3qaYHdqHWt+x0spXn
	 dv+COtEnpoCfxPUpsbSjGyegBw1B5gatDG/emduwlg54Pn8q0nuhKK19Q4cAQ9S4Jl
	 eAoDcxEgsPXSdCuLrCzf/DtjvWED31YgPfIn7naAdno+wZEfRG6VUHz8dXK3O+6RC4
	 B92Lf0MPiWTpc7s2MBtg0Ku9u1HJHJAvveOYOERFRd1uN6Xr3qAwlLh0yW53VCkXva
	 nQSIpxgYoBMew==
Date: Fri, 10 Jan 2025 11:18:08 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: linux-kernel@vger.kernel.org
cc: sstabellini@kernel.org, jgross@suse.com, xen-devel@lists.xenproject.org, 
    jbeulich@suse.com
Subject: [PATCH v3] xen: update pvcalls_front_accept prototype
Message-ID: <alpine.DEB.2.22.394.2501101117030.1731534@ubuntu-linux-20-04-desktop>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

While currently there are no in-tree callers of these functions, it is
best to keep them up-to-date with the latest network API.

Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
---
Changes in v3:
expand commit message
---
 drivers/xen/pvcalls-front.c | 5 +++--
 drivers/xen/pvcalls-front.h | 2 +-
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
index b72ee9379d77..cab480059731 100644
--- a/drivers/xen/pvcalls-front.c
+++ b/drivers/xen/pvcalls-front.c
@@ -769,7 +769,8 @@ int pvcalls_front_listen(struct socket *sock, int backlog)
 	return ret;
 }
 
-int pvcalls_front_accept(struct socket *sock, struct socket *newsock, int flags)
+int pvcalls_front_accept(struct socket *sock, struct socket *newsock,
+			 struct proto_accept_arg *arg)
 {
 	struct pvcalls_bedata *bedata;
 	struct sock_mapping *map;
@@ -788,7 +789,7 @@ int pvcalls_front_accept(struct socket *sock, struct socket *newsock, int flags)
 		return -EINVAL;
 	}
 
-	nonblock = flags & SOCK_NONBLOCK;
+	nonblock = arg->flags & SOCK_NONBLOCK;
 	/*
 	 * Backend only supports 1 inflight accept request, will return
 	 * errors for the others
diff --git a/drivers/xen/pvcalls-front.h b/drivers/xen/pvcalls-front.h
index f694ad77379f..881ef14660bc 100644
--- a/drivers/xen/pvcalls-front.h
+++ b/drivers/xen/pvcalls-front.h
@@ -12,7 +12,7 @@ int pvcalls_front_bind(struct socket *sock,
 int pvcalls_front_listen(struct socket *sock, int backlog);
 int pvcalls_front_accept(struct socket *sock,
 			 struct socket *newsock,
-			 int flags);
+			 struct proto_accept_arg *arg);
 int pvcalls_front_sendmsg(struct socket *sock,
 			  struct msghdr *msg,
 			  size_t len);
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Fri Jan 10 19:54:28 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 19:54:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869985.1281426 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWL57-00041m-R8; Fri, 10 Jan 2025 19:54:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869985.1281426; Fri, 10 Jan 2025 19:54:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWL57-00041f-Nn; Fri, 10 Jan 2025 19:54:09 +0000
Received: by outflank-mailman (input) for mailman id 869985;
 Fri, 10 Jan 2025 19:54:08 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=l7mG=UC=amd.com=Jason.Andryuk@srs-se1.protection.inumbo.net>)
 id 1tWL56-0003zb-ED
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 19:54:08 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on20602.outbound.protection.outlook.com
 [2a01:111:f403:2416::602])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a4f0b3bf-cf8c-11ef-99a4-01e77a169b0f;
 Fri, 10 Jan 2025 20:54:05 +0100 (CET)
Received: from MN2PR06CA0015.namprd06.prod.outlook.com (2603:10b6:208:23d::20)
 by PH8PR12MB7351.namprd12.prod.outlook.com (2603:10b6:510:215::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8335.11; Fri, 10 Jan
 2025 19:53:59 +0000
Received: from BN3PEPF0000B06E.namprd21.prod.outlook.com
 (2603:10b6:208:23d:cafe::c6) by MN2PR06CA0015.outlook.office365.com
 (2603:10b6:208:23d::20) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8335.13 via Frontend Transport; Fri,
 10 Jan 2025 19:53:59 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BN3PEPF0000B06E.mail.protection.outlook.com (10.167.243.73) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8377.0 via Frontend Transport; Fri, 10 Jan 2025 19:53:59 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 10 Jan
 2025 13:53:58 -0600
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 10 Jan
 2025 13:53:58 -0600
Received: from [172.31.88.124] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Fri, 10 Jan 2025 13:53:57 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a4f0b3bf-cf8c-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=X872xgXHGfsGM237LvtrTMRk9/0f5dx62JzHSvW5ak+01K8CnFNg7uBcxw7C0pJW8TW3D+EhLRgh/KlzwdiShSkewM7P7/55XGkdHmW1PL54nSrHuwt/Jfe2yghu6yGFP4u9CApHM4twNfD3cjnmDWeNwgEuql6g8QbKsS1Sqmd5R9Wlkhag1SGNdKBUVMmZCYr85/nZB2+ajP2WLIcVSok0DPJl03bTKP+p6FHJO+BJVBvfQv/pGplVZJdouu/2wG0r+smh2S1W7JgDfYxD7jSefWuRS1ubu7Idea07Ve8Ft7+n1F9lGRsTc+FKjgPgvZa+3Tv4Hnaa3NeUrMNVGw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=02oETOlBsWxI1frBbQ+Ht8ybGSP54hNsPPtunB8DhLU=;
 b=VCVsT0kfMGc2QvkuY/pvwkusn351h4Lelg7T0ymdLw7381xN2xWsx3e06TcMKCkhZM2p2/iZmbpcx4ou/QbVdUVjogQ8YDwkxac+LQP6T8DWRt2+OkMrSxljRdtHVtCI2Ai6doRRzP0F+Pi9uIiyfiQeq3IoPWZlzg1mFK1l7EnwBcf9XGF/WsSurOulaOf0n7NHDXRj5aE7iFb2/famk5oOwBXLi5mceYhmNm0eEa9/OYjdUIYn9HrOvT0AWv3EvASmRPuw5Ij6DLV2GQcH+rXY/t+FvN32v7MWmEBezwcc1hGw2hPCW6JZpes9r72LCmd76D204oTZn1O8xPLZbg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=apertussolutions.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=02oETOlBsWxI1frBbQ+Ht8ybGSP54hNsPPtunB8DhLU=;
 b=GXWbV6qW0Tae4+G9Vd28+G3wJyTBu+DobOUV1VmA2bFqDoyhpqZtcljx9lu+aIf2naW7TDQm/nONW36Dt2IS6h++D8iJCu/3LMSavfebtUw1//lMFhAOYpDwJltsIOZYoMlcJ1nr0qM4DxaSGxNkKJ5m6D/U9qCCeK/YsQFEUhM=
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: <508cff3c-3fd4-4ab7-89ef-30a72a267111@amd.com>
Date: Fri, 10 Jan 2025 14:52:57 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 03/15] x86/boot: add cmdline to struct boot_domain
To: "Daniel P. Smith" <dpsmith@apertussolutions.com>,
	<xen-devel@lists.xenproject.org>
CC: <christopher.w.clark@gmail.com>, <stefano.stabellini@amd.com>, Jan Beulich
	<jbeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
 <20241226165740.29812-4-dpsmith@apertussolutions.com>
Content-Language: en-US
From: Jason Andryuk <jason.andryuk@amd.com>
In-Reply-To: <20241226165740.29812-4-dpsmith@apertussolutions.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB05.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN3PEPF0000B06E:EE_|PH8PR12MB7351:EE_
X-MS-Office365-Filtering-Correlation-Id: 4419031b-8f5e-4274-2945-08dd31b08622
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|36860700013|1800799024|376014|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?cWNveTQ1a1NFNjBtUTA3bm53dmdaZjFpQTA0Wlo5ZkR5WVgvUVQxS09FM0hw?=
 =?utf-8?B?Mk8wQlF0ZWtjc1VVbFN1amFnR0U1SjRlSXZvUHhWRTV2U1JYcGYvUlNnOTdm?=
 =?utf-8?B?a0Z0akxoK1dha01GalBmZzgvNUZ4TlM5ZHVUazdHZmlIUGo0Vk1zbHlvVmli?=
 =?utf-8?B?TDdhdmhVRG9QYUtNcmpEc1B3T0I3SUNOUFVCblF3dzZlSjA0TVlyd1Z4bkVx?=
 =?utf-8?B?K2wzbWM4dVZNVlNqeXV5YWJnenM4OXJpUFY0VmJzcHFCUHJLK3ZBb1RtWDB3?=
 =?utf-8?B?R1lTZGtBVEJvOGdobWNjdjZsYmhFdWRiV0RWWGJaWEZadnFGU2MxcmJsNTFJ?=
 =?utf-8?B?T3hJelNlaVZEV1lHNjNTL256UVBOYXROek1aYlZhUS9mcGlEU3J2N3E3N0dU?=
 =?utf-8?B?ZkpzVk1HU3V2c2h1NlUxWDJhQjByaGowWUFHVzdmd1UxUFNCUHhIVko4U1Fa?=
 =?utf-8?B?ZDBmOXRpOU04WGRpRTMwNkIvV1A5b3MvN21JS3V3YU52R2R5cklrbjE1UndI?=
 =?utf-8?B?YXdGNTlrNHpGam1zYU1IRjZiZWZhU0VVTmFGS3RINVQwclF1L2NDOHljUVd2?=
 =?utf-8?B?RmlyNEpmWnRkR3FlTGt0U1R5NENSSXBWeGpOTy9ZckwwQUNia1FzVzVPUWhz?=
 =?utf-8?B?YUI1TmZLR084YTJ3Qm5RbGpzL0hYUGI0WTQvbzdFQ2tjcGRWa1hmTEtFUzMx?=
 =?utf-8?B?YUpoSzAyY3IxSzdQSVd5UCtOUEpNWjlVSUNrcFVjWXFzTkFLQ0JPc1VWYWdV?=
 =?utf-8?B?MlpBWDhVZG95aTU2TUFXL2dJbkFOYVQ5eDJWQzFUTkNGNjBLcEE2WCsvVGJF?=
 =?utf-8?B?bUhUSEdMWERQTjJEYjJQMmtrSmZkdzd4RUlReC85YjFzQXE2NFpZNFlpcUhV?=
 =?utf-8?B?cVFMakZJSUVVUXlqSmlSUE5ZTW1WbFIzdnMyZFNLeWFuZ1hmZDdyWlJ0M05a?=
 =?utf-8?B?TXBwc2hJbldPM0lIa0xVSzg5dUVEQ3hKVXl0WkVwS2lMbGlKd1Zqb0F4VHlP?=
 =?utf-8?B?LzhjUnQ5bVVrSjkyMkF5SWR4citTQ2lGU2E4K1pwNkNDM1dFaVdaY2Voak5t?=
 =?utf-8?B?VU95QmtyU1NRVWNXMm9zWEZPa2RCSDdVdm9HZzlyVVJkSUlwa2ZLM29UNzlP?=
 =?utf-8?B?R1NxczVsWWs5aFRDVG93b3F4aHRiSkxEVFBlbGRMbm9LbkExK1NwVlhJSklH?=
 =?utf-8?B?NkVjb2tJRWVmbWo4UGgzK0k3ZW5lTHFzVElWMlRKMHl0TCtLS3h6cTVWU1NV?=
 =?utf-8?B?czlNQklIbkxSdUNPU20wZW40SGt0RDAyQWlCT0VKWUdud01zekplMmlhN2ZL?=
 =?utf-8?B?cG5ZWTR4YUVJbC90eSthRVZJdFAxSkVNVy93dnlHRzNRMmRaMlNwQ0d5S05L?=
 =?utf-8?B?MDZPZ0d1d2ErSmYyMXk5TmJpL0ZRd3RacWxJTW56QXhnWWVxcmRQb2ZYQW8v?=
 =?utf-8?B?Ynl1TFovRGVES1Z0eDUwd1VHTmlqU0M2RHlybkdtZ2FTZExjQWRTeHpnZUZQ?=
 =?utf-8?B?U0FpOVhNVC9LVFY3cGVqUUYyeWFtMUtrWU40YmJSRUlQYXRuNUxGMEQ4RGMr?=
 =?utf-8?B?c1ViQU12SmQzN1NjWVdZdnpocTJsclgxb2NFd1R5eDI2R1JaMXBtYUZqNzZZ?=
 =?utf-8?B?am8zMEM0YStyTnJFTDRNU0FPTGxxajJVWlhsdlRuQ2c2bUpsQXBOOVNwaFNS?=
 =?utf-8?B?RGovdU93REJydzJibTFFdk84Z1NtZ2k4VWRsYlNSMC81dW45V1dMUUFBT09v?=
 =?utf-8?B?SWNTdUdkTk1PSERsbE4yK1R4MldlRktmQUtaRC9ZZlh6QnExTW5jOG9WRkwy?=
 =?utf-8?B?VE5wT3JBT1lFMERTdWtYVHNJUUowTjV1TER5eVkxa0wxZDR2bWVXd2xvemls?=
 =?utf-8?B?bEQxZGE5VXBhNm9yYkZXdC9YOHVoZUtVNHNQV1lOMU53dXJpNmo0ckZsVDQv?=
 =?utf-8?Q?nJe8wjDZxipqUJvgnrn+ZP0BLbpKUy8e?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(1800799024)(376014)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jan 2025 19:53:59.0244
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 4419031b-8f5e-4274-2945-08dd31b08622
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:
	BN3PEPF0000B06E.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB7351

On 2024-12-26 11:57, Daniel P. Smith wrote:
> Add a container for the "cooked" command line for a domain. This provides for
> the backing memory to be directly associated with the domain being constructed.
> This is done in anticipation that the domain construction path may need to be
> invoked multiple times, thus ensuring each instance had a distinct memory
> allocation.
> 
> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>


> @@ -1018,39 +1037,52 @@ static struct domain *__init create_dom0(struct boot_info *bi)
>           panic("Error creating d%uv0\n", bd->domid);
>   
>       /* Grab the DOM0 command line. */
> -    if ( bd->kernel->cmdline_pa || bi->kextra )
> +    if ( (bd->kernel->cmdline_pa &&
> +          ((char *)__va(bd->kernel->cmdline_pa))[0]) ||
> +         bi->kextra )
>       {
> -        if ( bd->kernel->cmdline_pa )
> -            safe_strcpy(cmdline,
> -                        cmdline_cook(__va(bd->kernel->cmdline_pa), bi->loader));
> +        size_t cmdline_size = domain_cmdline_size(bi, bd);
> +
> +        if ( cmdline_size )
> +        {
> +            if ( !(cmdline = xzalloc_array(char, cmdline_size)) )
> +                panic("Error allocating cmdline buffer for %pd\n", d);

I guess I wasn't clear last time.  Instead of two levels of indent, I 
was thinking at the top level:

     /* Grab the DOM0 command line. */
     cmdline_size = domain_cmdline_size(bi, bd);
     if ( cmdline_size )
     {

domain_cmdline_size() checks all the pointers, so this removes 
duplication and indent.

The rest looks good.

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 19:56:37 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 19:56:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.869993.1281436 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWL7U-0004bL-7Z; Fri, 10 Jan 2025 19:56:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 869993.1281436; Fri, 10 Jan 2025 19:56:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWL7U-0004bE-3r; Fri, 10 Jan 2025 19:56:36 +0000
Received: by outflank-mailman (input) for mailman id 869993;
 Fri, 10 Jan 2025 19:56:34 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=l7mG=UC=amd.com=Jason.Andryuk@srs-se1.protection.inumbo.net>)
 id 1tWL7S-0004b8-EM
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 19:56:34 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20613.outbound.protection.outlook.com
 [2a01:111:f403:2413::613])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id fc897fe7-cf8c-11ef-99a4-01e77a169b0f;
 Fri, 10 Jan 2025 20:56:32 +0100 (CET)
Received: from SJ0PR03CA0234.namprd03.prod.outlook.com (2603:10b6:a03:39f::29)
 by DM6PR12MB4153.namprd12.prod.outlook.com (2603:10b6:5:212::22) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8335.11; Fri, 10 Jan
 2025 19:56:28 +0000
Received: from SJ5PEPF000001F1.namprd05.prod.outlook.com
 (2603:10b6:a03:39f:cafe::27) by SJ0PR03CA0234.outlook.office365.com
 (2603:10b6:a03:39f::29) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8335.13 via Frontend Transport; Fri,
 10 Jan 2025 19:56:28 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ5PEPF000001F1.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.8335.7 via Frontend Transport; Fri, 10 Jan 2025 19:56:28 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 10 Jan
 2025 13:56:27 -0600
Received: from [172.31.88.124] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Fri, 10 Jan 2025 13:56:26 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: fc897fe7-cf8c-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=wBxNjsJIugZot6FyS8CMyh57VvKCPLDDRze4wHoBSSLIevIYrLQNuCFhMTvsPLYYFmDplbaZaDPzg1ug5rlDgDfH+ndGSnUv6iJ4NwfGxkr62HzZuYmjiNNVArK2cJ3HMUxFm0p9UTt3J0dCtq8Lndka8pf4vyvUNjUbODJf6RiJZVbdNZ9rM6XppGuERLNQSA6Sk8IBEG37JcM0yPNdBNujHAddqkM2GP88qFVPbfkrXIR1dKbr8T2vKyd99NaWUuN/qFvmpGFakc0xYQ94wiat8Kr0pHJlOkYCGiYUwkBJ9Kz6XJPFcKr/KpOuo/J9xl7Vx7vWgol+SUP8oSJu0g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=/8ECKsKedir1lyaapobKCltmTVKHm4uNnyTRp+QtJmY=;
 b=I9NFA5fnkOX8S/52nsnjK1UPaKUaprSAov4/H4+fxrK9Mc8yZJA83+24VqPnR++Cg6zgb/DBEa13QeqqdPeQ5ji6/L/9Xz1hGZT0I8G708792CRVWhyHNQd51WdT9TI+BMyO8kA/h1eSCpGQW77VzbIp4jnfD+GCjYCVApJhZkIUV/KOJpF1n2O2dhbtvle1ANpoGkzMuKl9pjfrADaPQhSFs5ay2Lc/B4whqs6I2FSugzVTrfFUku4QZ4CpX1Lolnyf3FJOfRk5udDO/wmxkzZ0CYmX+sDfP+KNLKM4xIM0tkR0HD5nUDxURamDWtprN4wR64xNwdJzG7Cq3VEkdQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=apertussolutions.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=/8ECKsKedir1lyaapobKCltmTVKHm4uNnyTRp+QtJmY=;
 b=dm670yaz7iaiTBjzrlUuxGChd8tvOoDuaPpnXYoOAgki1p4dgxJn+OYlYLUfevvA5yfPx1u6ISOxytkEGKB5u2BgvDVGWgdFBNB1111NGA8tR8+d9BBMN6zTgU1O0fBuuqXPoqp02bpOYy67fkH+DchqcX409Ge376wrOKc0UzI=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <43c0ce53-4b3c-47b6-8b4d-c5278f52d7fe@amd.com>
Date: Fri, 10 Jan 2025 14:55:26 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 05/15] kconfig: introduce domain builder config option
To: "Daniel P. Smith" <dpsmith@apertussolutions.com>,
	<xen-devel@lists.xenproject.org>
CC: <christopher.w.clark@gmail.com>, <stefano.stabellini@amd.com>, Jan Beulich
	<jbeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
 <20241226165740.29812-6-dpsmith@apertussolutions.com>
Content-Language: en-US
From: Jason Andryuk <jason.andryuk@amd.com>
In-Reply-To: <20241226165740.29812-6-dpsmith@apertussolutions.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB04.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001F1:EE_|DM6PR12MB4153:EE_
X-MS-Office365-Filtering-Correlation-Id: c9b11ea1-fe09-45a8-d653-08dd31b0df15
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|36860700013|1800799024|82310400026|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?b3VIUU40M2NrZ3kzS2ZqU3VWQ0RXRWFVNzN3SW9JajJBbDJJTmc1UWV2VkE2?=
 =?utf-8?B?V1JVeGZ2WGw3aDRRalhoMFFFbGlrenIvbWRwQWlnRElkV3hPWEdJSTJTSnZO?=
 =?utf-8?B?eDEyVWJBQ2VtbFdKUTkvTVpkVlZiVHo2aUlISlZDZGlWNmRSNUZuZzdSNDdt?=
 =?utf-8?B?eWFlczhlcGNldlhYOFZMbWduNThjVjhIbnNSTzlHWHhBRThJRXFET2JGQm9S?=
 =?utf-8?B?Z0tWd2RDYkxhVytNRUJqcmhZUXZWTy94Qnl6RVRITGk3UE55NW5mRTRPYUc2?=
 =?utf-8?B?NDNUbGdhQ1Nma2c3QkpnK01nRnZRV3loRjNWbG4zSHRMbnAxZVNKSXdYMm04?=
 =?utf-8?B?RWNHQUtudEZhUXRkZk0rRjRDZFV4MUh1OVUzYWNFTHN2UXd3T2cycVZzNmNq?=
 =?utf-8?B?RzNYWXJZSUdnTXpHV3JabVdHUkxUSC9rWERJQ0VXY040WHdNUDhxNCtXbXFN?=
 =?utf-8?B?U0ZaRlRBVGJrbzFzTWh2YUJHSFlPeGVRckNRQXdJMHZDZ3Q3QmExZ3BZTHA5?=
 =?utf-8?B?REp4RzMvcFpkNkVHRlduTDY2dWk5OVNENHp1aXptOWswSXNpcFhvamNZdXlt?=
 =?utf-8?B?ektSSkpudFVUVG9EdVlLUnhtVUp5MDRobU53ZnVRRzJtcUFPUld2KzNNeXJB?=
 =?utf-8?B?anUzMFZNTEFvcXpqbGdqUGoxN3hIWEJ3UllmSHdaaVdNR0x0a01WTXBRdDFq?=
 =?utf-8?B?VXQ0OHZiSi80c2x3Z09zbE1TenFwY3RYVnlZbUtYakoxRmx0d2FiYVZBSm13?=
 =?utf-8?B?LzdFbDIweXBtUk1BVSszOWIzMzlibktJZWUvcmwvT1VsVFhNRkVNemJKeEl1?=
 =?utf-8?B?SVlPcnpUTVVsR3BDeHYyTUJQSHJMRC9GdVRuaitrK2RUR2dSZjF2ZkQ4dWZv?=
 =?utf-8?B?L21nU1Q4blVRU3EzNzdNZUdOZWpXVzdjOUxGaVROVFdlUnlSMzBoTjREMEdi?=
 =?utf-8?B?MU0rSzN4Z1oxZ0h2Z0gzOTEwNjlkbmcxeUYxdzl4bXNEL3BmQTAzcUpiM3cw?=
 =?utf-8?B?L3VEcWpaNDRnU0RaTHZFN3ZIL3g0SXpXOU1hdS91Nk1rcEhxdk9OcDU2QkRK?=
 =?utf-8?B?ajA1N2dlRWtOWjFHM0E0VHB5eXhtdmpObm5OTWtCaTdub2QyNzg4djFvZ0sw?=
 =?utf-8?B?Y0x6cGFzN2wrSDBLVXEwbHBwN0UyWDh4Mkp1ekhSYWg3R2tXYjBReTVrd0Nl?=
 =?utf-8?B?VEtrMjFTWjEyMXNnOWduNnorc3NJRTBVYjFuU2twbW04aFJ4UThGdjdma0hz?=
 =?utf-8?B?ZFpWOGhwWEU5S3NsYkFPSFY5V0VQbDRMbENMck80Z1NmSzRlVURYODdJbGc2?=
 =?utf-8?B?ZjdnZEUrelVFc2s2NUY1R2ZlM1hqRG5rN1g5RkNIZHorVVRkQ0JnSGlSYWhQ?=
 =?utf-8?B?QVgrNzNWV2hGUXpXTFZISkxnZE1JUDFjem9sWVRtemVxWmU2OW9ka3laSWhX?=
 =?utf-8?B?VUswcFVqdUlIVW5PNTZoL0ZxTDBJR0lxSFJnOC96SWMray9tMWtMcXJ6UERz?=
 =?utf-8?B?Tm1qa0FaQU1GRG9oOXA4VENIUHlUM2V0UmQ5RytKVE1kNEJNRThYaThWdU0x?=
 =?utf-8?B?VldnQTZvalE3Uy9mMy9rWXhFNDZmTENZclFWNmtvQXJBYmV0cWpPWTc1cGpT?=
 =?utf-8?B?a3ZuL3JveWJJNTZ5VEx0djdHUU5ZYVRmbVpseHl0aDBmSFlvR3gxR3gwbzQ1?=
 =?utf-8?B?bVhEQ1phQmNWejA5dkJUWlBUUFNBUjRYSy9BUjlUazNWMG45bXhvU0FsUGZi?=
 =?utf-8?B?a1FERElyek5vb1B1MnJlcWUrZitmTGJ5ZlNkeEhybkFoNERzTU1CMGF6cG9M?=
 =?utf-8?B?cDdHWmV4QzA2V0VSMkl3YmpnTHpjVXlabW9jY2NjZzl3MWZ3SDFpZ1dua2Ur?=
 =?utf-8?B?a1Ntekp6TjU2WHRsVjBNUTM5VXg3cU95WC9qMDIxYzA1Tld6R1lEM3M3a1l2?=
 =?utf-8?B?bjVzd2xUTm5EN09kdmI1NGlUV2pHWi9zQm9nbk9qcUs1dG9ESzJrTFNtaUd0?=
 =?utf-8?Q?FSpMRuODxXr4TxMyuPknW1a6s/h0m0=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700013)(1800799024)(82310400026)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jan 2025 19:56:28.1671
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c9b11ea1-fe09-45a8-d653-08dd31b0df15
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF000001F1.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4153

On 2024-12-26 11:57, Daniel P. Smith wrote:
> Hyperlaunch domain builder will be the consolidated boot time domain building
> logic framework. Introduces the config option to enable this domain builder to
> and turn on the ability to load the domain configuration via a flattened device
> tree.
> 
> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>

> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
> index 9cdd04721afa..25b9b75423c5 100644
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -383,6 +383,8 @@ config ALTP2M
>   
>   	  If unsure, stay with defaults.
>   
> +source "arch/x86/domain_builder/Kconfig"

s/_/-/ ?

With that,

Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 20:11:22 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 20:11:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870003.1281445 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWLLd-0007qM-FY; Fri, 10 Jan 2025 20:11:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870003.1281445; Fri, 10 Jan 2025 20:11:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWLLd-0007qF-Cv; Fri, 10 Jan 2025 20:11:13 +0000
Received: by outflank-mailman (input) for mailman id 870003;
 Fri, 10 Jan 2025 20:11:11 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=RTL5=UC=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tWLLb-0007q7-E9
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 20:11:11 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 058d9265-cf8f-11ef-99a4-01e77a169b0f;
 Fri, 10 Jan 2025 21:11:05 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 50311A4287D;
 Fri, 10 Jan 2025 20:09:16 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 83159C4CED6;
 Fri, 10 Jan 2025 20:11:03 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 058d9265-cf8f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1736539864;
	bh=vyjcdsLa6PRt3lYhW4vysftDH2HNiVW6dG52oxM/ci4=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=axKn1aj7ZwkXX1JVWvtAnAAbxKCvbUPLGLXCAuyv5hs2DMuffuGnlHKJUTgVxc76q
	 uzuVhW9fdPKO9ZkWjKYKqJxe6EXieGnUKGI9LLXdi0FwQsnQgxoxBDNIxcvjQBP93E
	 0p06Oj4kBPgrwDA87EShcCkiroeAzvyhzew7/L7+XXwO2s9DKpdc/q76F17OjAXy9h
	 J+/R6I1C35sl3iheCFPYooZIbNKhVIOV6fYSIDZMaZSw9OBUVtl2av+jVUhwOyoIwM
	 zdVxXpYp7C7VN2383ZJtjk790REx3b3Fd+bgDh8S3k0/wsdi1sx6O97RIGFxuR5mH1
	 8FTHGKZLWmwkg==
Date: Fri, 10 Jan 2025 12:11:02 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo <alejandro.vallejo@cloud.com>
cc: Andrew Cooper <andrew.cooper3@citrix.com>, 
    Xen-devel <xen-devel@lists.xenproject.org>, 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
    Stefano Stabellini <sstabellini@kernel.org>, 
    Anthony PERARD <anthony.perard@vates.tech>, 
    Oleksii Kurochko <oleksii.kurochko@gmail.com>
Subject: Re: [PATCH] CI: Add an x86_64 Clang Randconfig job
In-Reply-To: <D6YJY56LLW9U.1JHBJ5DF1A8UK@cloud.com>
Message-ID: <alpine.DEB.2.22.394.2501101210570.1731534@ubuntu-linux-20-04-desktop>
References: <20250110160217.183887-1-andrew.cooper3@citrix.com> <D6YJY56LLW9U.1JHBJ5DF1A8UK@cloud.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1405474099-1736539864=:1731534"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-1405474099-1736539864=:1731534
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Fri, 10 Jan 2025, Alejandro Vallejo wrote:
> On Fri Jan 10, 2025 at 4:02 PM GMT, Andrew Cooper wrote:
> > This was recently identified as a hole in testing.
> >
> > Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> > ---
> > CC: Roger Pau Monné <roger.pau@citrix.com>
> > CC: Stefano Stabellini <sstabellini@kernel.org>
> > CC: Anthony PERARD <anthony.perard@vates.tech>
> > CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> >
> > https://gitlab.com/xen-project/people/andyhhp/xen/-/jobs/8820980201
> > ---
> >  automation/gitlab-ci/build.yaml | 6 ++++++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
> > index 3abd2a0c6575..cb84f379b754 100644
> > --- a/automation/gitlab-ci/build.yaml
> > +++ b/automation/gitlab-ci/build.yaml
> > @@ -551,6 +551,12 @@ debian-12-x86_64-clang:
> >    variables:
> >      CONTAINER: debian:12-x86_64
> >  
> > +debian-12-x86_64-clang-randconfig:
> > +  extends: .clang-x86-64-build
> > +  variables:
> > +    CONTAINER: debian:12-x86_64
> > +    RANDCONFIG: y
> > +
> >  debian-12-x86_64-gcc:
> >    extends: .gcc-x86-64-build
> >    variables:
> 
>   Reviewed-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>

Acked-by: Stefano Stabellini <sstabellini@kernel.org>
--8323329-1405474099-1736539864=:1731534--


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 21:19:42 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 21:19:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870013.1281462 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWMPj-0008Gz-Jh; Fri, 10 Jan 2025 21:19:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870013.1281462; Fri, 10 Jan 2025 21:19:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWMPj-0008Fn-D8; Fri, 10 Jan 2025 21:19:31 +0000
Received: by outflank-mailman (input) for mailman id 870013;
 Fri, 10 Jan 2025 21:19: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
 <SRS0=qCll=UC=daemonizer.de=maxi@srs-se1.protection.inumbo.net>)
 id 1tWMPi-0008EF-F3
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 21:19:30 +0000
Received: from mx1.somlen.de (typhoon.somlen.de [89.238.64.140])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 92bb8563-cf98-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 22:19:28 +0100 (CET)
Received: by mx1.somlen.de with ESMTPSA id 553B95030E7;
 Fri, 10 Jan 2025 22:19:26 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 92bb8563-cf98-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=daemonizer.de;
	s=202303; t=1736543966;
	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;
	bh=jWZqXIp5bUcmoJ7raF+Sui2s7eMrVNjK2aCR0SvW1XU=;
	b=uk+UYv9svfJr8U5T6duzoCxpjiOyOkhuGe3C8SZlyZeJyooBxHqBpoDpbdVHoXDpfuN2++
	D2BNirGYlrtpckTMbulqpMGSs+BLNQI9/2QprjqtkzMH9NHCPWmIN0H9jdJOvHd4YGWRzA
	M3mgEV59tX3dFe5k7wAcBqw1O9gDtN7piQRkz0lKUgvovnlOUxdjE8s6N8saJLoJPszNtR
	UtRu/YMVQC3EdKTe82/Cosz2hYGqBWxew2nVoUDmqq7xMJltC237Zkpc/Lmd7TJs0ILjuw
	Gr3KehaZRTllmZdjs9S4l3/9rb90oNg/V1hkiVL340PJIoROgXAYLzwWv6K3Gw==
From: Maximilian Engelhardt <maxi@daemonizer.de>
To: xen-devel@lists.xenproject.org
Cc: Maximilian Engelhardt <maxi@daemonizer.de>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: [XEN PATCH 0/1] Bug: Hyperlinks in generated documentation may point to the wrong architecture
Date: Fri, 10 Jan 2025 22:19:02 +0100
Message-Id: <cover.1736542505.git.maxi@daemonizer.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

As suggested by Andrew Cooper in [1], I formally submit this patch for
fixing that documentation hyperlinks may point to the wrong
architecture. This fix also makes building the documentation
reproducible in Debian.

With this patch applied, I still get the following:

/usr/bin/perl -w /build/reproducible-path/xen-4.19.1/docs/xen-headers -O html/hypercall/ppc \
	-T 'arch-ppc - Xen public headers' \
	-X arch-arm -X arch-riscv -X arch-x86_32 -X arch-x86_64 \
	-X xen-arm -X xen-riscv -X xen-x86_32 -X xen-x86_64 \
	-X arch-x86 \
	/build/reproducible-path/xen-4.19.1/docs/../xen include/public include/xen/errno.h
include/public/hvm/dm_op.h:476: multiple definitions of Typedef xen_ulong_t: include/public/arch-ppc.h:55
include/public/hvm/dm_op.h:476: multiple definitions of Typedef xen_ulong_t: include/public/arch-ppc.h:61
include/public/hvm/dm_op.h:476: multiple definitions of Typedef xen_ulong_t: include/public/arch-ppc.h:55
include/public/hvm/dm_op.h:476: multiple definitions of Typedef xen_ulong_t: include/public/arch-ppc.h:61

This seems to happen due to multiple "typedef uint64_t xen_ulong_t;"
in xen/include/public/arch-ppc.h (albeit in different if(n)def blocks).
It does not cause any problems for us at the moment, but probably should
still be addressed somehow.

[1] https://lists.xen.org/archives/html/xen-devel/2025-01/msg00324.html

Maximilian Engelhardt (1):
  docs/Makefile: Add ppc and riscv to DOC_ARCHES

 docs/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Fri Jan 10 21:19:42 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 21:19:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870012.1281457 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWMPj-0008EY-Bl; Fri, 10 Jan 2025 21:19:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870012.1281457; Fri, 10 Jan 2025 21:19:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWMPj-0008ER-6c; Fri, 10 Jan 2025 21:19:31 +0000
Received: by outflank-mailman (input) for mailman id 870012;
 Fri, 10 Jan 2025 21:19:30 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=qCll=UC=daemonizer.de=maxi@srs-se1.protection.inumbo.net>)
 id 1tWMPi-0008EG-6Y
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 21:19:30 +0000
Received: from mx1.somlen.de (breeze.somlen.de [2a00:1828:a019::100:0])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 929ebaa9-cf98-11ef-99a4-01e77a169b0f;
 Fri, 10 Jan 2025 22:19:27 +0100 (CET)
Received: by mx1.somlen.de with ESMTPSA id 99E295030F4;
 Fri, 10 Jan 2025 22:19:26 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 929ebaa9-cf98-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=daemonizer.de;
	s=202303; t=1736543966;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=pgKmm6AVDFKKCXdhODIqgz4Hc2RbX2q3s9xrk82N8Ik=;
	b=jE2nfZ4phlHsxEAnHSQVK4/zsEbsG/KLmtSDtzhAYmdFSxTWs4Ed1h5T84zH4lL+R93JtW
	LDPV3w/4YN2KeMNd1tn04Wyenixnib9Bq14qSXFJqGreqBkOvJacMxK0NB4X0UGGNWethM
	xCi0cnh0wFqqicCxUrcv6+TYQpBNQ6gOFvYYaAe1UhQMxNmkKbrdR27aLyQHBb8CR0r0zQ
	OSD/m8yloizOMk/GnUqTEaADpoM7be8QzTcYvZQKTz2xoX5I8Js4uKKSWwKLrTt+ZokwxB
	Pe0dPKdoekp/zhh/eMAFRCDHJZxjQHcd6zyYlEtDkAvF9p5aTwzchlQ4jotLMQ==
From: Maximilian Engelhardt <maxi@daemonizer.de>
To: xen-devel@lists.xenproject.org
Cc: Maximilian Engelhardt <maxi@daemonizer.de>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: [XEN PATCH 1/1] docs/Makefile: Add ppc and riscv to DOC_ARCHES
Date: Fri, 10 Jan 2025 22:19:03 +0100
Message-Id: <b1d5c6fca18b93e402d229d22763621719964ea7.1736542505.git.maxi@daemonizer.de>
In-Reply-To: <cover.1736542505.git.maxi@daemonizer.de>
References: <cover.1736542505.git.maxi@daemonizer.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Not having ppc and riscv included in DOC_ARCHES causes "multiple
definitions of ..." message on documentation build, similar to the
example shown below:

include/public/arch-ppc.h:91: multiple definitions of Typedef
vcpu_guest_core_regs_t: include/public/arch-arm.h:300
include/public/arch-ppc.h:91: multiple definitions of Typedef
vcpu_guest_core_regs_t: include/public/arch-ppc.h:85

It can also make the generated html documentation link to the header
files of another architecture. This is additionally a problem as it can
randomly make the documentation build non-reproducible.

Signed-off-by: Maximilian Engelhardt <maxi@daemonizer.de>
---
 docs/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/Makefile b/docs/Makefile
index b30cc619f8..9f8ba8acd9 100644
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -5,7 +5,7 @@ include $(XEN_ROOT)/Config.mk
 VERSION		:= $(shell $(MAKE) -C $(XEN_ROOT)/xen --no-print-directory xenversion)
 DATE		:= $(shell date +%Y-%m-%d)
 
-DOC_ARCHES      := arm x86_32 x86_64
+DOC_ARCHES      := arm ppc riscv x86_32 x86_64
 MAN_SECTIONS    := 1 5 7 8
 
 # Documentation sources to build
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Fri Jan 10 21:32:14 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 21:32:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870028.1281476 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWMby-0003Kb-Iq; Fri, 10 Jan 2025 21:32:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870028.1281476; Fri, 10 Jan 2025 21:32:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWMby-0003KU-GC; Fri, 10 Jan 2025 21:32:10 +0000
Received: by outflank-mailman (input) for mailman id 870028;
 Fri, 10 Jan 2025 21:32:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=uskN=UC=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tWMbx-0003K4-CT
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 21:32:09 +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 57fa925e-cf9a-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 22:32:08 +0100 (CET)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-436326dcb1cso18493795e9.0
 for <xen-devel@lists.xenproject.org>; Fri, 10 Jan 2025 13:32:08 -0800 (PST)
Received: from [192.168.86.29] ([83.105.36.37])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436e2df2faesm98812955e9.26.2025.01.10.13.32.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 10 Jan 2025 13:32:07 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 57fa925e-cf9a-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736544727; x=1737149527; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=bF5cgY7m5DZljHXFxQBQ1a72NDsRU6mtLCuqzP8cfcQ=;
        b=YtTtlFTHJEarjUU5QzNHrYMK2RsdQnHwj8djDVztqKnT9g2+MwdEhCEP+PSI5tzCdj
         M7IId/wKqw8JGMu3gA+KFSngBwwy+9LGQdjUOrkTZm4Tp+RDz5pN5bzsWagSNTgSlYma
         3tWg3P6fSsNo3mJMXsy7ti1aV7Y9aZDDCDzTg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736544727; x=1737149527;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=bF5cgY7m5DZljHXFxQBQ1a72NDsRU6mtLCuqzP8cfcQ=;
        b=ClKEQ5Zh+tMvnOm8KF3wwNDd8/k5BtYSWNL5IsrTE9ImGZRZvyaNhTRzymMsfJINEF
         sxt9m7bWPwCik9n/7HoBFRKBKw2gPToRRFjt7azkYt5iuypDa9I6OD9tq3FeydR/mruh
         oIcCocATgjUK1XV2NiAupwYCvrYOp9D0Qoc25XfnmGWlmRg+UlH16u8AtTw5ZY8DqEEd
         VhRxps23wZBOwQwXVGUKGcxVawTrAO12/KMlnSdmlI7YOoL90Eq25NKDUr6aCQFi2/RG
         CJtGqUuSCNOAV4NssxSdC1oKa8YGdiL7xFLF9JaHoW4lx/k5ySTMT+En8lDypqfoSmSF
         xudQ==
X-Forwarded-Encrypted: i=1; AJvYcCXIp1Ddr6eNr7zI3BlZLMUSLEU8aDwFtN4y8oBbM9UWQREXWvaAFNcTaLy3LWMvwpCnFx9n2y7LQWc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxnlDxJ9sxzI1VfXgFq9mWkC6uMxES7jaC6G7f4cgK4vIxTN/KD
	Pu2JWLD+KKzq9CMxtXqAQxQx+kLLKE9FQr4lzXhYpkb0tiToq3K1GV/4l2Qctxj5MmnNOUJKCFQ
	aLwY=
X-Gm-Gg: ASbGncv18210ujLxBlxXhCBJo+73DOfA++RJY4LN9BfhnWApWMiZigw28nhnDdPD7Zk
	af6J5dwOumfT732sOESemeCE7ST5VbeMcPYTDEAl5rZ7NVY1KAUIPjq85Bpm8of5Fagajh6kBy3
	PfSbjCF4oG2/q1bUX4tiZqLtrBQ3Bl4qpM9yIYxziX7XEA/hxjaXmQom/DCLGyy9waLeXiZrNrQ
	C0VnIwbTI3mT50O8LqatR7EZlDU40Ow8NK7xYlaQh09gLvDXf1TbQA4V9rMTOjXpuQ=
X-Google-Smtp-Source: AGHT+IFl9i+s20vSR9nf5hSv9Zst+j7vMzYtd3dq6Y0iOR94/+I5X7TcTj7+bG6xfvLIlo5Gf6AFUA==
X-Received: by 2002:a05:600c:138f:b0:434:a4fe:cd71 with SMTP id 5b1f17b1804b1-436e26a88d9mr121456625e9.12.1736544727346;
        Fri, 10 Jan 2025 13:32:07 -0800 (PST)
Message-ID: <fe71538a-92ed-4ab5-95f7-e5c8d42929d2@citrix.com>
Date: Fri, 10 Jan 2025 21:32:06 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 0/1] Bug: Hyperlinks in generated documentation may
 point to the wrong architecture
To: Maximilian Engelhardt <maxi@daemonizer.de>, xen-devel@lists.xenproject.org
Cc: Anthony PERARD <anthony.perard@vates.tech>
References: <cover.1736542505.git.maxi@daemonizer.de>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <cover.1736542505.git.maxi@daemonizer.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 10/01/2025 9:19 pm, Maximilian Engelhardt wrote:
> As suggested by Andrew Cooper in [1], I formally submit this patch for
> fixing that documentation hyperlinks may point to the wrong
> architecture. This fix also makes building the documentation
> reproducible in Debian.
>
> With this patch applied, I still get the following:
>
> /usr/bin/perl -w /build/reproducible-path/xen-4.19.1/docs/xen-headers -O html/hypercall/ppc \
> 	-T 'arch-ppc - Xen public headers' \
> 	-X arch-arm -X arch-riscv -X arch-x86_32 -X arch-x86_64 \
> 	-X xen-arm -X xen-riscv -X xen-x86_32 -X xen-x86_64 \
> 	-X arch-x86 \
> 	/build/reproducible-path/xen-4.19.1/docs/../xen include/public include/xen/errno.h
> include/public/hvm/dm_op.h:476: multiple definitions of Typedef xen_ulong_t: include/public/arch-ppc.h:55
> include/public/hvm/dm_op.h:476: multiple definitions of Typedef xen_ulong_t: include/public/arch-ppc.h:61
> include/public/hvm/dm_op.h:476: multiple definitions of Typedef xen_ulong_t: include/public/arch-ppc.h:55
> include/public/hvm/dm_op.h:476: multiple definitions of Typedef xen_ulong_t: include/public/arch-ppc.h:61
>
> This seems to happen due to multiple "typedef uint64_t xen_ulong_t;"
> in xen/include/public/arch-ppc.h (albeit in different if(n)def blocks).
> It does not cause any problems for us at the moment, but probably should
> still be addressed somehow.
>
> [1] https://lists.xen.org/archives/html/xen-devel/2025-01/msg00324.html
>
> Maximilian Engelhardt (1):
>   docs/Makefile: Add ppc and riscv to DOC_ARCHES

Thanks for the patch.  I'll commit it in due course.

As an aside though, is there anything we could sensibly do in our own CI
(Gitlab) to not regress this?

https://salsa.debian.org/reproducible-builds/reprotest looks like it
might be good start, but I've never really played in this area before. 
Would this be suitable, or do you have any other suggestion?

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 22:21:38 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 22:21:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870036.1281485 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWNNb-0001p1-Tt; Fri, 10 Jan 2025 22:21:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870036.1281485; Fri, 10 Jan 2025 22:21:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWNNb-0001ou-QX; Fri, 10 Jan 2025 22:21:23 +0000
Received: by outflank-mailman (input) for mailman id 870036;
 Fri, 10 Jan 2025 22:21: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
 <SRS0=l7mG=UC=amd.com=Jason.Andryuk@srs-se1.protection.inumbo.net>)
 id 1tWNNa-0001oo-CP
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 22:21:22 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20610.outbound.protection.outlook.com
 [2a01:111:f403:200a::610])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 36455260-cfa1-11ef-99a4-01e77a169b0f;
 Fri, 10 Jan 2025 23:21:19 +0100 (CET)
Received: from CH0PR08CA0027.namprd08.prod.outlook.com (2603:10b6:610:33::32)
 by DS7PR12MB6288.namprd12.prod.outlook.com (2603:10b6:8:93::7) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8335.10; Fri, 10 Jan 2025 22:21:13 +0000
Received: from CH3PEPF0000000B.namprd04.prod.outlook.com
 (2603:10b6:610:33:cafe::19) by CH0PR08CA0027.outlook.office365.com
 (2603:10b6:610:33::32) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8335.13 via Frontend Transport; Fri,
 10 Jan 2025 22:21:13 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH3PEPF0000000B.mail.protection.outlook.com (10.167.244.38) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8335.7 via Frontend Transport; Fri, 10 Jan 2025 22:21:13 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 10 Jan
 2025 16:21:12 -0600
Received: from [172.31.88.124] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Fri, 10 Jan 2025 16:21:12 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 36455260-cfa1-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ag6eK7gcPQRhcN1YNkG4hjji8u8waUSt7hCb38Wm95GsoLIviVV+YRaHwRdzPAMr9epgOfJMkCVLDKaV1aWnm816s0SBC4C2MPXP1nNldEHpK+DZLaXfmSIsINLtCSwXJAKNX4ZpspLYZCNuoNqUctphqJIzBnGXagtlKK3KDKO2m5DZx6CyNat7yoxE4SnFWIchbEWg7w3GFmb8SQYqcdT4xdG16o0krMwF4dlCUjddhuiMSCZBNNm+AhuGz8/0AvJqMzIgrTjI8uMtNWHO7+XcXfmV+G7OLyRoKWBa6rjpj+ivLPv9pqz3acdQA+oiqVNDih9htbO4+IdWmyVKxA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=oP38IVBNbqZWKbOqOxt0j0fmaPu0MFviVieuQbDEr+M=;
 b=Js8fPhe9wiMpShUZ6l4043QvIP3PSjVB+Dj8+T7eoNGoT7kMlljytxe2qkWIGmdhGyvrceJOF++gUOzjhbYAWr4nryijxlkdJzo0BbsM5L43+7r2up2q4rogXEOdOfGJuFhZ4VCT+Gl0nQKEgpW/x2ceH7W+Lo94V57zUvwI7ZWjjBo1yCO6eYhkWsRJ30h84eFIfQepnXPOCa7cYnNrXwuQG3TAFci4HFuyVHllz7n/TPaTzrJDCsDutyS/X6jO+OPdQVDBKItktU/qCAhtqAlsZRu/I12CgMoEVgDKgBvXZEd+jThvbqEnVSK5BE2dSHaHHD06UKHa8cnM1EuS9w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=apertussolutions.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=oP38IVBNbqZWKbOqOxt0j0fmaPu0MFviVieuQbDEr+M=;
 b=Lg50oDCUxt/X1XfGxSUWBruoXDmbssV1Rsdwg5K6WlQFn8C96EgGWsOAEtBxVESiWGFnw9iMYAe4y1HTUFcRccWxh4tG13VEnDDfSSeE+L8zBkPhwkxEcxubGHzEnaIu+iqGymzpPuM9YpWPMPuoBdKvRqJ+KWdT4EfZiTSaN/A=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <f02d01c0-2860-4645-b0a5-24cdc1415b12@amd.com>
Date: Fri, 10 Jan 2025 17:20:05 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 07/15] x86/hyperlaunch: initial support for hyperlaunch
 device tree
To: "Daniel P. Smith" <dpsmith@apertussolutions.com>,
	<xen-devel@lists.xenproject.org>
CC: <christopher.w.clark@gmail.com>, <stefano.stabellini@amd.com>, Jan Beulich
	<jbeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
 <20241226165740.29812-8-dpsmith@apertussolutions.com>
Content-Language: en-US
From: Jason Andryuk <jason.andryuk@amd.com>
In-Reply-To: <20241226165740.29812-8-dpsmith@apertussolutions.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB04.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH3PEPF0000000B:EE_|DS7PR12MB6288:EE_
X-MS-Office365-Filtering-Correlation-Id: 164f12b3-b277-4b48-31e0-08dd31c517d9
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|1800799024|36860700013|82310400026|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?UEM4aGNFQUg1Rk40c0FuRjVyNlhTdC95bnVVc3NSeVgvcE9sbXhjQ3ByaGRT?=
 =?utf-8?B?a2Z6Uk1LQzlzaHdRTVgzZW1vSDBxVTAyOXVXL2dwTm1zN3lsVnBoNzBmVXps?=
 =?utf-8?B?Qy8wU29OQXZYQ0RZRHIveUtZZkFBcWIvZGVSZWtycVBWeCt2c0YrY2FIT0FD?=
 =?utf-8?B?ZzlkWVFjMjZaTngwT2cybzNGU2MwR1NoT1ozRlBlWTBOcU5lU0tFQytDaUFJ?=
 =?utf-8?B?ckxNQ2pNZnNObzJnVkdRNzBqaUNKU2tjYlRwdEpKRzZyeERseVVjZTZPeHlK?=
 =?utf-8?B?aWNQaERDZHc2OTFyd2gzWjJiRTN6c0xDS2ZaZUZUSm9tQW0vUy96ZzJ1NFgr?=
 =?utf-8?B?YWFPZ3d1eE84L2tNeXk0MlI2ZnZDN2VKVS9CVGI0bEpkd29ndVZHT0xSYzdF?=
 =?utf-8?B?K01zZWVQNmdjdHpVWDIvVHNpeEhWM0VWU05VV09XaFNmNFc5QUtORVJyNTFQ?=
 =?utf-8?B?WFFudWg4OE5KeWk5S01NOGN2c0JXOFI4N1dUS2RVNmRsdUlQWEVJSmtTVVdW?=
 =?utf-8?B?QS9ySE91enQ3M0NXY2htcktETk9aNm5IMzdwMi9pNFErVkdLNk5JY09KbVp3?=
 =?utf-8?B?V0xrYXlNWDJ5bFdhbm9MbjJXeGN4K0ZQTUR4RkxDenVqVldQakluTERKM1Ey?=
 =?utf-8?B?bW1CUjBZRnlCQTVVd0w1TERKZXpIV2tlY1M5UStPRjBKTE9IYjczVG1ONVRY?=
 =?utf-8?B?S1lhY3lFSXJDTmFuYnVJSC9DS2pNYm9PNTlUK1BZenVLZHlJb2hYOXZNK01M?=
 =?utf-8?B?Z0Z3QU9zY1Brc25lK1VoOXRyaTRjUmJSbEFmUUZHTGNsbUo2alI5SkJsVCtE?=
 =?utf-8?B?VUJKYnh5NmtqRGJZeDhjb3VuMHJYS1kxTUJIUWpYa1ZmVzlFOHExbUpqRGt0?=
 =?utf-8?B?NEZib2M1NzhQa3VmVFgzcGpDZWNTSE0vb29kcHlWMCtJKzhvck12anBpVWZL?=
 =?utf-8?B?bkx1ejk3dHZZSEswd3lYV0czSmZhaG1KQXFlY2d4UUR0TzdqQ3A5MDhDa3E2?=
 =?utf-8?B?UEVZZURremFYdy9kVHYyak94VVNvTTQ3ZDh4dU1sYm5JTGhKZmVDYWtxcThZ?=
 =?utf-8?B?enl5NFZIRmIxZDdkcVhPcmZMVk55ZllZQXFKaWlHUTdwclhkS29Ta0NyNFFZ?=
 =?utf-8?B?Wjc3aGVzMnlmd2pkK2pMQjBHZ3d3YW13aXNraWpHM0VWZzExYm5maHYwdk81?=
 =?utf-8?B?QVRRU3h6bHhmaTFIdFRQbEd3dkd4bzVOd2RWRE5CUVdtbnAxYzhGSUNlMHEx?=
 =?utf-8?B?dm1KZURrc0c1bHU2Rm43VXhKK2JaeVVwVUF1c0x0VHFML0RaeWorY1cyRXRz?=
 =?utf-8?B?RERZN0ZFUlNiTjh1YmVSMjRJQmtrRkVhemZ1OFIrVWNyL2RCUm16OEVHL0lu?=
 =?utf-8?B?dURjMWxPNlhoN0llY0RabHE5TkpzWXFYdGdwSzR4d0pmVGhGWGlMZENuNVBP?=
 =?utf-8?B?SU10RS83VWRRU3pJbG5NdFRQTXo5U3VCWENSUmJ1MXY3L24ySTJrYUdBVTVs?=
 =?utf-8?B?Q1VITTQyVnI2SStnbmZWRzN5bFRqME1ENnJiREl2MXJjM0pFZFBDREx3bURk?=
 =?utf-8?B?WVhJVlZlbVM3OWx2Y2pIL1lDTnllQXpKY2g3MHgxdUtBUGxpOTNyM2ZzOGdl?=
 =?utf-8?B?anpzLzErRi9HazJiZittVDMrek5hRjl3Y1N0bTlqL3R2aWJxK21CNG5GTnhG?=
 =?utf-8?B?ZEU4RjlVVytDWTBncytHSXo0UTVENDZTRGtpbmYzQ2lSR2htU1pIeElGOXl2?=
 =?utf-8?B?bGtqaEZsc2hyMHRyNkg1R2R0M08xU3QvMVJNNjNMVnBuRWVORytJaHE3SEpT?=
 =?utf-8?B?NEp5UUxvaUdQVHBid0t2a3pBZERURW0yeFhBY0k5NlgycTlwS1ZMdlZPdndK?=
 =?utf-8?B?NlY2Q0d3RkphRTV2WmtlSmx1QWtuYnFLcExnSGRkaFI1UGxwWkRUVEJOVjcz?=
 =?utf-8?B?MGErRU1RRkRvRGliV1QwY1dvalFDZHFaZHJleGFQU3V5OU9mR0dsZEJKeXY3?=
 =?utf-8?Q?2TKB1BriLnB8mrw1WTryzDHFCdmt+M=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(1800799024)(36860700013)(82310400026)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jan 2025 22:21:13.4125
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 164f12b3-b277-4b48-31e0-08dd31c517d9
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH3PEPF0000000B.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB6288

On 2024-12-26 11:57, Daniel P. Smith wrote:
> Add the ability to detect both a formal hyperlaunch device tree or a dom0less
> device tree. If the hyperlaunch device tree is found, then count the number of
> domain entries, reporting an error if more than one is found.
> 
> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>

> diff --git a/xen/arch/x86/domain-builder/fdt.c b/xen/arch/x86/domain-builder/fdt.c
> index 4a3f80648f86..5793bdc9fd47 100644
> --- a/xen/arch/x86/domain-builder/fdt.c
> +++ b/xen/arch/x86/domain-builder/fdt.c
> @@ -13,14 +13,77 @@
>   
>   #include "fdt.h"
>   
> +static int __init find_hyperlaunch_node(const void *fdt)
> +{
> +    int hv_node = fdt_path_offset(fdt, "/chosen/hypervisor");
> +
> +    if ( hv_node >= 0 )
> +    {
> +        /* Anything other than zero indicates no match */
> +        if ( fdt_node_check_compatible(fdt, hv_node, "hypervisor,xen") )
> +            return -ENODATA;
> +        else
> +            return hv_node;
> +    }
> +    else
> +    {
> +        /* Lood for dom0less config */

Look

> +        int node, chosen_node = fdt_path_offset(fdt, "/chosen");
> +        if ( chosen_node < 0 )
> +            return -ENOENT;
> +
> +        fdt_for_each_subnode(node, fdt, chosen_node)
> +        {
> +            if ( fdt_node_check_compatible(fdt, node, "xen,domain") == 0 )
> +                return chosen_node;
> +        }
> +    }
> +
> +    return -ENODATA;
> +}
> +
>   int __init has_hyperlaunch_fdt(struct boot_info *bi)
>   {
>       int ret = 0;
>       const void *fdt = bootstrap_map_bm(&bi->mods[HYPERLAUNCH_MODULE_IDX]);
>   
> -    if ( fdt_check_header(fdt) < 0 )
> +    if ( !fdt || fdt_check_header(fdt) < 0 )

It seems to me the !fdt check should move into the earlier patch.  What 
do you think?

>           ret = -EINVAL;
> +    else
> +        ret = find_hyperlaunch_node(fdt);
> +
> +    bootstrap_unmap();
> +
> +    return ret < 0 ? ret : 0;
> +}
> +
> +int __init walk_hyperlaunch_fdt(struct boot_info *bi)
> +{
> +    int ret = 0, hv_node, node;
> +    void *fdt = bootstrap_map_bm(&bi->mods[HYPERLAUNCH_MODULE_IDX]);
> +
> +    if ( unlikely(!fdt) )
> +        return -EINVAL;
> +
> +    hv_node = find_hyperlaunch_node(fdt);

You call find_hyperlaunch_node() twice.  It seems like you can just have 
has_hyperlaunch_fdt() return the node and pass it into this function.

Regards,
Jason

> +    if ( hv_node < 0 )
> +    {
> +        ret = hv_node;
> +        goto err_out;
> +    }
> +
> +    fdt_for_each_subnode(node, fdt, hv_node)
> +    {
> +        ret = fdt_node_check_compatible(fdt, node, "xen,domain");
> +        if ( ret == 0 )
> +            bi->nr_domains++;
> +    }
> +
> +    /* Until multi-domain construction is added, throw an error */
> +    if ( !bi->nr_domains || bi->nr_domains > 1 )
> +        printk(XENLOG_ERR "Hyperlaunch only supports dom0 construction\n");
>   
> + err_out:
>       bootstrap_unmap();
>   
>       return ret;


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 22:21:38 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 22:21:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870038.1281495 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWNNm-00026F-7y; Fri, 10 Jan 2025 22:21:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870038.1281495; Fri, 10 Jan 2025 22:21:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWNNm-000268-55; Fri, 10 Jan 2025 22:21:34 +0000
Received: by outflank-mailman (input) for mailman id 870038;
 Fri, 10 Jan 2025 22:21: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
 <SRS0=HMSX=UC=kernel.org=helgaas@srs-se1.protection.inumbo.net>)
 id 1tWNNl-000250-Jh
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 22:21:33 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org
 [2604:1380:45d1:ec00::3])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3e685fb6-cfa1-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 23:21:32 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 90A67A429C3;
 Fri, 10 Jan 2025 22:19:42 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7D2ADC4CED6;
 Fri, 10 Jan 2025 22:21:30 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 3e685fb6-cfa1-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1736547690;
	bh=qRzXS2cPJbaQPT6VO1nJCsDiE6wZHCk69MWbzsLdJlw=;
	h=Date:From:To:Cc:Subject:In-Reply-To:From;
	b=pj+fUwX5Yye14PC5hRy0JgM6ta4tEh6f9nuN2mMCGvoXLDnym0raxlIziHWvKQUMN
	 67SvwmJBIhIkCEd6yyoXvWUuOMzaCdu+TzVQNy6ClhnPpWtAvNPQR2SAy175sIXEnu
	 CBwBPljbt5WTQgSZvQo3A/ATY7wjKy0B7Y0yQnepi9+7dfaw5D7fTyMjyGdch6Quxe
	 iEj89ipnrrqx3zcXrMD3oVTVbqdCV/4leLX4T5DgkB+LMx6eGe/MQLAmrE8VOXkx8l
	 tTHxwCGKhdL5hJqs25kG82FMvhlCrrPzAgfQYkQVvFAwep5M8tnm7HDShvZw62arGO
	 GMonTgtfEnzNw==
Date: Fri, 10 Jan 2025 16:21:29 -0600
From: Bjorn Helgaas <helgaas@kernel.org>
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
	Juergen Gross <jgross@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Subject: Re: [PATCH 1/3] xen/pci: do not register devices outside of PCI
 segment scope
Message-ID: <20250110222129.GA317771@bhelgaas>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250110140152.27624-2-roger.pau@citrix.com>

On Fri, Jan 10, 2025 at 03:01:48PM +0100, Roger Pau Monne wrote:
> The PCI segment value is limited to 16 bits, however there are buses like VMD
> that fake being part of the PCI topology by adding segment with a number
> outside the scope of the PCI firmware specification range (>= 0x10000). The
> MCFG ACPI Table "PCI Segment Group Number" field is defined as having a 16 bit
> width.
>
> Attempting to register or manage those devices with Xen would result in errors
> at best, or overlaps with existing devices living on the truncated equivalent
> segment values.

The ACPI _SEG method (ACPI r6.5, sec 6.5.6) and the corresponding
value in the MCFG table (PCI Firmware r3.3, sec 4.1.2) are clearly
16-bit values.

But otherwise, the segment value is pretty much an arbitrary software
value, and the kernel works fine with the larger domain values from
vmd_find_free_domain(), so this isn't quite enough to explain what the
issue with Xen is.

Does Xen truncate the domain to 16 bits or use it to look up something
in ACPI?

> Skip notifying Xen about those devices.
> 
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> ---
>  drivers/xen/pci.c | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/drivers/xen/pci.c b/drivers/xen/pci.c
> index 416f231809cb..08e82fd1263e 100644
> --- a/drivers/xen/pci.c
> +++ b/drivers/xen/pci.c
> @@ -43,6 +43,13 @@ static int xen_add_device(struct device *dev)
>  		pci_mcfg_reserved = true;
>  	}
>  #endif
> +
> +	if (pci_domain_nr(pci_dev->bus) >> 16) {
> +		dev_info(dev,
> +			 "not registering with Xen: invalid PCI segment\n");
> +		return 0;
> +	}
> +
>  	if (pci_seg_supported) {
>  		DEFINE_RAW_FLEX(struct physdev_pci_device_add, add, optarr, 1);
>  
> @@ -149,6 +156,12 @@ static int xen_remove_device(struct device *dev)
>  	int r;
>  	struct pci_dev *pci_dev = to_pci_dev(dev);
>  
> +	if (pci_domain_nr(pci_dev->bus) >> 16) {
> +		dev_info(dev,
> +			 "not unregistering with Xen: invalid PCI segment\n");
> +		return 0;
> +	}
> +
>  	if (pci_seg_supported) {
>  		struct physdev_pci_device device = {
>  			.seg = pci_domain_nr(pci_dev->bus),
> @@ -182,6 +195,12 @@ int xen_reset_device(const struct pci_dev *dev)
>  		.flags = PCI_DEVICE_RESET_FLR,
>  	};
>  
> +	if (pci_domain_nr(dev->bus) >> 16) {
> +		dev_info(&dev->dev,
> +			 "unable to notify Xen of device reset: invalid PCI segment\n");
> +		return 0;
> +	}
> +
>  	return HYPERVISOR_physdev_op(PHYSDEVOP_pci_device_reset, &device);
>  }
>  EXPORT_SYMBOL_GPL(xen_reset_device);
> -- 
> 2.46.0
> 


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 22:25:30 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 22:25:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870056.1281505 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWNRZ-0002yF-Mz; Fri, 10 Jan 2025 22:25:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870056.1281505; Fri, 10 Jan 2025 22:25:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWNRZ-0002y8-KS; Fri, 10 Jan 2025 22:25:29 +0000
Received: by outflank-mailman (input) for mailman id 870056;
 Fri, 10 Jan 2025 22:25:29 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=HMSX=UC=kernel.org=helgaas@srs-se1.protection.inumbo.net>)
 id 1tWNRZ-0002y2-7A
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 22:25:29 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id cb196a35-cfa1-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 23:25:28 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id CA3CCA426AE;
 Fri, 10 Jan 2025 22:23:38 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 86143C4CED6;
 Fri, 10 Jan 2025 22:25:26 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: cb196a35-cfa1-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1736547926;
	bh=DLEpLG1m5W4R6CL6+4W7/UedZGSkgthe9gS3KngxZLE=;
	h=Date:From:To:Cc:Subject:In-Reply-To:From;
	b=ManuQbqHSTcactyB2Pv88RPe6kmW+6bJ70xOHlALBW8ZaApg7qihBPSgg0MB1XxDP
	 2Sfb1aSG4MEDG2Q5BWaJbM74T9R3ZKbucW1aCtqBIgQJ6t3izk5x6xLe0wm3NfyjX8
	 W6aHyWUpfVkabF0D/bh1JF5E8gC+jMNk2zr2037C54jxn6rEivGg2tfKQVt4UnprQE
	 VUAgT20jki7KtulD/31HTvryTgs5MhyhkVlz7fuqbZlVHT5Dv9ha8+/jX9lFhh1Wlz
	 EKn6/dUuT9e80byAplmUx0Kkp7RPFps29+IhXje/eJo72tFMslKD77CN5Azw1pDnvc
	 +ITR5HQSLkzzg==
Date: Fri, 10 Jan 2025 16:25:25 -0600
From: Bjorn Helgaas <helgaas@kernel.org>
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
	linux-pci@vger.kernel.org,
	Nirmal Patel <nirmal.patel@linux.intel.com>,
	Jonathan Derrick <jonathan.derrick@linux.dev>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= <kw@linux.com>,
	Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
	Rob Herring <robh@kernel.org>, Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [PATCH 2/3] vmd: disable MSI remapping bypass under Xen
Message-ID: <20250110222525.GA318386@bhelgaas>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250110140152.27624-3-roger.pau@citrix.com>

Match historical subject line style for prefix and capitalization:

  PCI: vmd: Set devices to D0 before enabling PM L1 Substates
  PCI: vmd: Add DID 8086:B06F and 8086:B60B for Intel client SKUs
  PCI: vmd: Fix indentation issue in vmd_shutdown()

On Fri, Jan 10, 2025 at 03:01:49PM +0100, Roger Pau Monne wrote:
> MSI remapping bypass (directly configuring MSI entries for devices on the VMD
> bus) won't work under Xen, as Xen is not aware of devices in such bus, and
> hence cannot configure the entries using the pIRQ interface in the PV case, and
> in the PVH case traps won't be setup for MSI entries for such devices.
> 
> Until Xen is aware of devices in the VMD bus prevent the
> VMD_FEAT_CAN_BYPASS_MSI_REMAP capability from being used when running as any
> kind of Xen guest.

Wrap to fit in 75 columns.

Can you include a hint about *why* Xen is not aware of devices below
VMD?  That will help to know whether it's a permanent unfixable
situation or something that could be done eventually.

> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> ---
>  drivers/pci/controller/vmd.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
> index 264a180403a0..d9b7510ace29 100644
> --- a/drivers/pci/controller/vmd.c
> +++ b/drivers/pci/controller/vmd.c
> @@ -965,6 +965,15 @@ static int vmd_probe(struct pci_dev *dev, const struct pci_device_id *id)
>  	struct vmd_dev *vmd;
>  	int err;
>  
> +	if (xen_domain())
> +		/*
> +		 * Xen doesn't have knowledge about devices in the VMD bus.

Also here.

> +		 * Bypass of MSI remapping won't work in that case as direct
> +		 * write to the MSI entries won't result in functional
> +		 * interrupts.
> +		 */
> +		features &= ~VMD_FEAT_CAN_BYPASS_MSI_REMAP;
> +
>  	if (resource_size(&dev->resource[VMD_CFGBAR]) < (1 << 20))
>  		return -ENOMEM;
>  
> -- 
> 2.46.0
> 


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 22:31:07 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 22:31:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870064.1281515 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWNWx-0004XY-9h; Fri, 10 Jan 2025 22:31:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870064.1281515; Fri, 10 Jan 2025 22:31:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWNWx-0004XR-6X; Fri, 10 Jan 2025 22:31:03 +0000
Received: by outflank-mailman (input) for mailman id 870064;
 Fri, 10 Jan 2025 22:31:02 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=HMSX=UC=kernel.org=helgaas@srs-se1.protection.inumbo.net>)
 id 1tWNWw-0004XL-9d
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 22:31:02 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9174ac9e-cfa2-11ef-a0df-8be0dac302b0;
 Fri, 10 Jan 2025 23:31:01 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id CA38F5C4CA7;
 Fri, 10 Jan 2025 22:30:18 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 54BCAC4CED6;
 Fri, 10 Jan 2025 22:30:59 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9174ac9e-cfa2-11ef-a0df-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1736548259;
	bh=9WkF6n5RBjRD1mrwR6nxL/hU9QiyhVm6Z4mOb8csuoU=;
	h=Date:From:To:Cc:Subject:In-Reply-To:From;
	b=rQhgmR2kSJPEviIMFBfSc+Z4Hchk6wciqoxq1D4PiiU2z+OXyngOrFXHmHSoTBD5y
	 sbrreH+lcvENWHkIyIzaxaX8C25ii1YOZqw2VyaaJQfTYL2+gMI4I9rXwiMD2txSUK
	 8QvNBNsuAfy5UaWrcvKFE/XCLn0J7RN7prRrAUcf7/kNHZx/sXU9N8AmIgEDAG9X+p
	 7M1zVVllWvmwGL9AJptwUutps9Txtg/gpYcYE8MwZrAZyS76HmrKZjdykYw0XCp0AT
	 ef3YzF9qvceS75EskXpOYtlaxhQPzb4PXV6UM0tvX810HEQu14+DoOmSEjliUbi0ot
	 T8HFuK07K2Y1Q==
Date: Fri, 10 Jan 2025 16:30:57 -0600
From: Bjorn Helgaas <helgaas@kernel.org>
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
	linux-pci@vger.kernel.org, Juergen Gross <jgross@suse.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH 3/3] pci/msi: remove pci_msi_ignore_mask
Message-ID: <20250110223057.GA318711@bhelgaas>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250110140152.27624-4-roger.pau@citrix.com>

Match subject line style again.

On Fri, Jan 10, 2025 at 03:01:50PM +0100, Roger Pau Monne wrote:
> Setting pci_msi_ignore_mask inhibits the toggling of the mask bit for both MSI
> and MSI-X entries globally, regardless of the IRQ chip they are using.  Only
> Xen sets the pci_msi_ignore_mask when routing physical interrupts over event
> channels, to prevent PCI code from attempting to toggle the maskbit, as it's
> Xen that controls the bit.
> 
> However, the pci_msi_ignore_mask being global will affect devices that use MSI
> interrupts but are not routing those interrupts over event channels (not using
> the Xen pIRQ chip).  One example is devices behind a VMD PCI bridge.  In that
> scenario the VMD bridge configures MSI(-X) using the normal IRQ chip (the pIRQ
> one in the Xen case), and devices behind the bridge configure the MSI entries
> using indexes into the VMD bridge MSI table.  The VMD bridge then demultiplexes
> such interrupts and delivers to the destination device(s).  Having
> pci_msi_ignore_mask set in that scenario prevents (un)masking of MSI entries
> for devices behind the VMD bridge.
> 
> Move the signaling of no entry masking into the MSI domain flags, as that
> allows setting it on a per-domain basis.  Set it for the Xen MSI domain that
> uses the pIRQ chip, while leaving it unset for the rest of the cases.
> 
> Remove pci_msi_ignore_mask at once, since it was only used by Xen code, and
> with Xen dropping usage the variable is unneeded.
> 
> This fixes using devices behind a VMD bridge on Xen PV hardware domains.

Wrap to fit in 75 columns.

The first two patches talk about devices behind VMD not being usable
for Xen, but this one says they now work.  But this doesn't undo the
code changes or comments added by the first two, so the result is a
bit confusing (probably because I know nothing about Xen).

Bjorn


From xen-devel-bounces@lists.xenproject.org Fri Jan 10 23:07:33 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Jan 2025 23:07:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870072.1281525 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWO6A-00011e-S7; Fri, 10 Jan 2025 23:07:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870072.1281525; Fri, 10 Jan 2025 23:07:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWO6A-00011X-Pa; Fri, 10 Jan 2025 23:07:26 +0000
Received: by outflank-mailman (input) for mailman id 870072;
 Fri, 10 Jan 2025 23:07: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
 <SRS0=l7mG=UC=amd.com=Jason.Andryuk@srs-se1.protection.inumbo.net>)
 id 1tWO69-00011R-A8
 for xen-devel@lists.xenproject.org; Fri, 10 Jan 2025 23:07:25 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20614.outbound.protection.outlook.com
 [2a01:111:f403:2417::614])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a6124501-cfa7-11ef-a0df-8be0dac302b0;
 Sat, 11 Jan 2025 00:07:23 +0100 (CET)
Received: from PH2PEPF00003847.namprd17.prod.outlook.com (2603:10b6:518:1::64)
 by DM4PR12MB6446.namprd12.prod.outlook.com (2603:10b6:8:be::7) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8335.10; Fri, 10 Jan 2025 23:07:19 +0000
Received: from SA2PEPF000015C6.namprd03.prod.outlook.com
 (2a01:111:f403:c801::5) by PH2PEPF00003847.outlook.office365.com
 (2603:1036:903:48::3) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8335.12 via Frontend Transport; Fri,
 10 Jan 2025 23:07:18 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SA2PEPF000015C6.mail.protection.outlook.com (10.167.241.196) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8335.7 via Frontend Transport; Fri, 10 Jan 2025 23:07:18 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 10 Jan
 2025 17:07:17 -0600
Received: from [172.31.88.124] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Fri, 10 Jan 2025 17:07:16 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a6124501-cfa7-11ef-a0df-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=yWAlsN17qD+JfrJ4GtOn2ysR2SKaqq6xnk894YFy9ZydxIz5ffGp1otrGnhO6mONyouhQPt4vfZevuP+a4gdcDeZJddSTsoyK23EjFfpUl0J2JXXhxh95YsgOi2zADovKenmaolQxEibE1dPCt++zDM8sWudCagOwX9rSx2F7sDeWWtbwrbIzzKzupyS64BiQfCWRhxIl6JiQSwv7l34MKGX76+t8x1iyA+UWA2Sv7pNLodoEJeX8qtBVvUHYuTzMwPlEpNCF29x+02GhX8nqgsh7D+vjRo8tHSFYWhXZ5kTe9MnjUver0r1cO+cTKP21dUjsiwTERPW8IcZHvWAvA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=FHq90pJkmtfQxQ8Aqrr9UR9evEFgX9UuVNZNytC2qGw=;
 b=DOFGA7hDPnRuPElwrwsBW9hTAM5MMWU6KzcGQtlgWsXYx974rJAOkyglLBiKeSeFA/PzNmyypHVJmnu8gURH0MWoHWASF7baiMk/swNx+LDq3cX432FzYctp/Cwp29m475eJTj6FbokH3NNpqLCIOeQ7VNyapUvr+66TxwIZckl3FR2UBk5fo/1MwXWCLffDXV2PpoYQ3HM+z/b2+OEJ2lhEGzFmSvyQLH2LUKcO6Kc7slPmHQ7eWTrMt8upFKAHsOYHdbAa5NAdx/M5QZ06Fta6x9waWvOd9gq3cNeyrZ4TAqyQ6oqji6yMAzE/rdW1YuAQGJTG1HbrYpSgjgycMw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=apertussolutions.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=FHq90pJkmtfQxQ8Aqrr9UR9evEFgX9UuVNZNytC2qGw=;
 b=Lu0NRhgw1QKa9fBUEnzHkHc1ttlg0Hms2Kk2rseE0s9ZN55gjvl3jLXGvgGYAIM1saSi5jhFKoDzEhh46+naTLRCzL7CeR/R9XaV68vYsy1idZo6xuGL1gm3BamgvEEsH597LyG/FB2RCqGyeWSuUG4kdjNXPN3eKGvr4V5Os/I=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <1fa208ec-f4ba-443a-ac4d-d601274ca5d5@amd.com>
Date: Fri, 10 Jan 2025 18:06:14 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 08/15] x86/hyperlaunch: locate dom0 kernel with
 hyperlaunch
To: "Daniel P. Smith" <dpsmith@apertussolutions.com>,
	<xen-devel@lists.xenproject.org>
CC: <christopher.w.clark@gmail.com>, <stefano.stabellini@amd.com>, Jan Beulich
	<jbeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand Marquis
	<bertrand.marquis@arm.com>, Michal Orzel <michal.orzel@amd.com>
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
 <20241226165740.29812-9-dpsmith@apertussolutions.com>
Content-Language: en-US
From: Jason Andryuk <jason.andryuk@amd.com>
In-Reply-To: <20241226165740.29812-9-dpsmith@apertussolutions.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB04.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SA2PEPF000015C6:EE_|DM4PR12MB6446:EE_
X-MS-Office365-Filtering-Correlation-Id: fd4d974c-0c54-43ec-46d5-08dd31cb87e2
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|376014|1800799024|82310400026|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?cHJLdUQxTHlsR3p1bE4rb2tkZExkeWxodkZqbnY1UnFWOGdDT2VDQVloN2Y4?=
 =?utf-8?B?Z3JmaExJSXFaZ1pxVWVlS0ROeE1jTnZKTFNlTFJiaVZ6S1NEK2NPZ0xZYWlo?=
 =?utf-8?B?VHEvcXdzQ1QydzFWUWZiUkVrWHYvRkJ3ZzBuQjlUeGJqZ1FrNEpZRHlNSElM?=
 =?utf-8?B?YzRWeU9EYXY3R29nQ29BdkZjcmUvNU5WZDF5anJUdkkrV2dIZm9CYWNQYzQ2?=
 =?utf-8?B?VlJjMHFTcGxnOEFrbERrdTdpTGJPQ082ZFcwaFIySUREaTExK0NoYzJOcjVL?=
 =?utf-8?B?RW5RS3BkSjRGZGQ4WFI4RDFhYy9FdFNDSTJFMnl6U2VjRDlkNUpzU3d3VTJn?=
 =?utf-8?B?TmJlREZGYlpCSU9VS3granBMSUpmSHJ3amg5MHpXaTNRRkRZcWlEbDdMMjdN?=
 =?utf-8?B?disvOTR3aWIzV29WeEFpNFdUVG1CVlZNc2YwaE1CWi9uQllSalZYSWxNUjlw?=
 =?utf-8?B?S1MvNVVjRGcrZ0lMV1MzdWpkTEl4cVdGd2QzVTdWWHlWUEU0d3hPR0lBZmg3?=
 =?utf-8?B?ZTNmL2JCV3pJOGw1NkkwKzlidDVoZnJHTGlkdy9aMDRybmNwK3haeldwbmRl?=
 =?utf-8?B?NklMN3BTZTAyVEhxMkNjZk5ZaEdZVCs4QmVacWNLOG5IeEpybU81Vlo2ckFW?=
 =?utf-8?B?SVNiWWswRUhObDliMjAyUnRxbDB5SkI4TENUWFlZOGYxcGhnalBrL1lHRm1R?=
 =?utf-8?B?alBnWUNrWmRMRWRIODIwd050VzBsNWZuZ1U1U3QwbGEzVVlxOTErcjFZSGdX?=
 =?utf-8?B?MDBmMzhHRkRCM3c5Q2pER3QvMkxHaWxMV3FRMml5VmVtdkhzS2pWc2hzaXk5?=
 =?utf-8?B?Rm1JMzZsS2lHZ0ZZUVJtOUZ4TmdJbHdHaSt6Y3pmUjF3eVFnbEtoQVROdkRm?=
 =?utf-8?B?NlZ4ZmZZUHVFamYreUU0ZmMyS1RGOHo0Um01a3RZK3NvTUF2WXR2LzY3bjdU?=
 =?utf-8?B?QlNrOHJLWHdmcUQvTWNaUVRLUjBFN1N0anJPem1GZmFaMWpzcUZ3WXNjTnZJ?=
 =?utf-8?B?WjRPQXMwSEFPMHltM043T0xTUkV1aER3VlpDY0JrWGJoY3ZKY0w5N3FOanZk?=
 =?utf-8?B?WlhadUpNdndNaEFTMHJyRTVWYk9sLzkvZGxJUnhsd1RTZnl1YjJUWVRSZjY2?=
 =?utf-8?B?d1ZOSXhYQytsMWdudDF3Y3V3dmhUQjArdG9kLzFGUTcrc2NOK0s1aEYvbGY5?=
 =?utf-8?B?SXNGRWRQTVdOUjZ2djVPNnpaSkk0bGRxdk9JSjYzWHdDWGpaYkw4dnFkd09t?=
 =?utf-8?B?ZzZOM2JIbHJ5djZjOWpGYjVUNTZKbHd1OGJsa1Q1ZW5rbHpMdHcycUVRMi9C?=
 =?utf-8?B?WE5LbEFxOU9QUEVKRSt2a2Mrck9jc0FINXlZR0c2blZoQWxGYjArMU9PcUM1?=
 =?utf-8?B?eEdoSnV3WTdIVGdkZ3lpT29iVVNFZXladWtIYXBKazdUNU10VDNPa1BadVE1?=
 =?utf-8?B?a3lUK05lbDZma003VDBQN1kvVW0yeEF1MVAwSXFvWm5YNWpQQTJ2TDFySGZs?=
 =?utf-8?B?S0grT0o1ejFXTEpvRmJGOVNLNkt2MGRzaUlLckJXNzFGSnlCcUgyWmFrOXJW?=
 =?utf-8?B?R3lRU3BmelptaUx2d3FqM2VtakNuNXBEQ1MxVXFEUm9MYWVKMDA5MGF2WWJi?=
 =?utf-8?B?TUNoeWJKU1p6cTBjSm5hOTVPRzdIY3ltTDA5NlRpUW04dTQreHJ6MDZuWnNW?=
 =?utf-8?B?bXA3Wk9zNlE1dDJtY2VOYitrdlVFdDl4d0ZmMG5HQzhES05BVlJFZnh3eXJ5?=
 =?utf-8?B?OWh5d0JCaXdkenc0YzM1a3pQV1QyWGdEZVlnQ1Buc1I4YnVVaE9qTVI4QTBJ?=
 =?utf-8?B?V2kyWU5iT3FWaERaUWNyVWx0RWE2M1JsY3FWYWUvUmFaTklTMHU2dXBpaGFu?=
 =?utf-8?B?K095N0p0YWlWMTd5LzZtbEZsb1ZlMGttKzlqRG5SV1NJemtCZkZWU3p5Y2Z5?=
 =?utf-8?B?NjRGdDBqNy96a2Y1TmdVd2JuVDZaNVJaLzNYTlAxOUVQTktjY2d4cmhCMmtR?=
 =?utf-8?Q?3SQqckwHIdLC7Ny+CUsQmzqjHJRTUE=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(1800799024)(82310400026)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jan 2025 23:07:18.3572
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: fd4d974c-0c54-43ec-46d5-08dd31cb87e2
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SA2PEPF000015C6.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6446

On 2024-12-26 11:57, Daniel P. Smith wrote:
> Look for a subnode of type `multiboot,kernel` within a domain node. If found,
> process the reg property for the MB1 module index. If the bootargs property is
> present and there was not an MB1 string, then use the command line from the
> device tree definition.
> 
> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
> Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
> ---
> Changes since v1:
> - moved low-level fdt handlers to libfdt-xen.h
> - coding style changes
> - moved default to "unknown" up to a local declaration
> - moved the general fdt parsing code out to libfdt
> - reworked device tree property parsing for module index
>    - reworked parsers to take index as parameter
>    - parsers now return success or error value
> - added check if kernel was already located, warn and continue
> ---

> diff --git a/xen/arch/x86/domain-builder/fdt.c b/xen/arch/x86/domain-builder/fdt.c
> index 5793bdc9fd47..bcaee50689a6 100644
> --- a/xen/arch/x86/domain-builder/fdt.c
> +++ b/xen/arch/x86/domain-builder/fdt.c
> @@ -13,6 +13,114 @@
>   
>   #include "fdt.h"
>   
> +static int __init hl_module_index(void *fdt, int node, uint32_t *idx)
> +{
> +    int ret = 0;
> +    const struct fdt_property *prop =
> +        fdt_get_property(fdt, node, "module-index", &ret);
> +
> +    /* FDT error or bad idx pointer, translate to -EINVAL */
> +    if ( ret < 0 || idx == NULL )
> +        return -EINVAL;
> +
> +    fdt_cell_as_u32((fdt32_t *)prop->data, idx);

fdt_prop_as_u32() provides a few more checks and would not require the 
cast here.

> +
> +    if ( *idx > MAX_NR_BOOTMODS )
> +        return -ERANGE;
> +
> +    return 0;
> +}
> +
> +static int __init dom0less_module_index(
> +    void *fdt, int node, int size_size, int address_size, uint32_t *idx)
> +{
> +    uint64_t size = ~0UL, addr = ~0UL;
> +    int ret =
> +        fdt_get_reg_prop(fdt, node, address_size, size_size, &addr, &size, 1);
> +
> +    /* FDT error or bad idx pointer, translate to -EINVAL */
> +    if ( ret < 0 || idx == NULL )
> +        return -EINVAL;
> +
> +    /* Convention is that zero size indicates address is an index */
> +    if ( size != 0 )
> +        return -EOPNOTSUPP;

We wanted reg = <addr size> to be converted into a new boot module.

i.e. if the user is using grub - they should use `module-index` to 
specify binaries.  If the binaries are loaded in memory, they must use 
`reg`.

> +
> +    if ( addr > MAX_NR_BOOTMODS )
> +        return -ERANGE;
> +
> +    /*
> +     * MAX_NR_BOOTMODS cannot exceed the max for MB1, represented by a u32,
> +     * thus the cast down to a u32 will be safe due to the prior check.
> +     */
> +    *idx = (uint32_t)addr;
> +
> +    return 0;
> +}
> +
> +static int __init process_domain_node(
> +    struct boot_info *bi, void *fdt, int dom_node)
> +{
> +    int node;
> +    struct boot_domain *bd = &bi->domains[bi->nr_domains];
> +    const char *name = fdt_get_name(fdt, dom_node, NULL) ?: "unknown";
> +
> +    fdt_for_each_subnode(node, fdt, dom_node)
> +    {
> +        if ( fdt_node_check_compatible(fdt, node, "multiboot,kernel") == 0 )
> +        {
> +            unsigned int idx;
> +            int ret = 0;
> +
> +            if ( bd->kernel )
> +            {
> +                printk(XENLOG_ERR "Duplicate kernel module for domain %s)\n",
> +                       name);
> +                continue;
> +            }
> +
> +            /* Try hyperlaunch property, fall back to dom0less property. */
> +            if ( hl_module_index(fdt, node, &idx) < 0 )
> +            {
> +                int address_size = fdt_address_cells(fdt, dom_node);
> +                int size_size = fdt_size_cells(fdt, dom_node);
> +
> +                if ( address_size < 0 || size_size < 0 )
> +                    ret = -EINVAL;
> +                else
> +                    ret = dom0less_module_index(
> +                            fdt, node, size_size, address_size, &idx);
> +            }
> +
> +            if ( ret < 0 )
> +            {
> +                printk("  failed processing kernel module for domain %s)\n",
> +                       name);
> +                return ret;
> +            }
> +
> +            if ( idx > bi->nr_modules )
> +            {
> +                printk("  invalid kernel module index for domain node (%d)\n",
> +                       bi->nr_domains);
> +                return -EINVAL;
> +            }

The earlier MAX_NR_BOOTMODS seem superfluous since this is the one that 
matters.

> +
> +            printk("  kernel: boot module %d\n", idx);
> +            bi->mods[idx].type = BOOTMOD_KERNEL;
> +            bd->kernel = &bi->mods[idx];
> +        }
> +    }
> +
> +    if ( !bd->kernel )
> +    {
> +        printk(XENLOG_ERR "ERR: no kernel assigned to domain\n");
> +        return -EFAULT;
> +    }
> +
> +    return 0;
> +}
> +
>   static int __init find_hyperlaunch_node(const void *fdt)
>   {
>       int hv_node = fdt_path_offset(fdt, "/chosen/hypervisor");

> diff --git a/xen/arch/x86/domain-builder/fdt.h b/xen/arch/x86/domain-builder/fdt.h
> index f5b89cb54b29..0be4ac771bc4 100644
> --- a/xen/arch/x86/domain-builder/fdt.h
> +++ b/xen/arch/x86/domain-builder/fdt.h

> @@ -10,6 +12,7 @@
>   #define HYPERLAUNCH_MODULE_IDX 0
>   
>   #ifdef CONFIG_DOMAIN_BUILDER
> +

This newline should move to a more appropriate patch.

>   int has_hyperlaunch_fdt(struct boot_info *bi);
>   int walk_hyperlaunch_fdt(struct boot_info *bi);
>   #else

> diff --git a/xen/include/xen/libfdt/libfdt-xen.h b/xen/include/xen/libfdt/libfdt-xen.h
> index a5340bc9f4e1..27d23df03af3 100644
> --- a/xen/include/xen/libfdt/libfdt-xen.h
> +++ b/xen/include/xen/libfdt/libfdt-xen.h
> @@ -13,6 +13,82 @@
>   
>   #include <xen/libfdt/libfdt.h>
>   
> +static inline int __init fdt_cell_as_u32(const fdt32_t *cell, uint32_t *val)
> +{
> +    *val = fdt32_to_cpu(*cell);
> +
> +    return 0;
> +}
> +
> +static inline int __init fdt_cell_as_u64(const fdt32_t *cell, uint64_t *val)
> +{
> +    *val = ((uint64_t)fdt32_to_cpu(cell[0]) << 32) |
> +           (uint64_t)fdt32_to_cpu(cell[1]);

A cast isn't needed on cell[1] since it's not shifted.

> +
> +    return 0;
> +}
> +
> +/*
> + * Property: reg
> + *
> + * Defined in Section 2.3.6 of the Device Tree Specification is the "reg"
> + * standard property. The property is a prop-encoded-array that is encoded as
> + * an arbitrary number of (address, length) pairs.
> + */
> +static inline int __init fdt_get_reg_prop(
> +    const void *fdt, int node, unsigned int asize, unsigned int ssize,
> +    uint64_t *addr, uint64_t *size, unsigned int pairs)

Your other function uses address_size and size_size compared to asize 
and ssize here.  While size_size is fun to write, I think addr_cells and 
size_cells are more accurate names.  It's the number of cells to parse 
for the respective values.  device_tree_get_reg() already exists - is 
that not usable?

> +{
> +    int ret;
> +    unsigned int i, count;
> +    const struct fdt_property *prop;
> +    fdt32_t *cell;
> +
> +    /* FDT spec max size is 4 (128bit int), but largest arch int size is 64 */
> +    if ( ssize > 2 || asize > 2 )
> +        return -EINVAL;
> +
> +    prop = fdt_get_property(fdt, node, "reg", &ret);
> +    if ( !prop || ret < sizeof(u32) )
> +        return ret < 0 ? ret : -EINVAL;
> +
> +    /* Get the number of (addr, size) pairs and clamp down. */
> +    count = fdt32_to_cpu(prop->len) / (ssize + asize);

Rounding down seems okay-ish.

> +    count = count < pairs ? count : pairs;

If the caller is asking for "pairs", should it just be an error if there 
aren't enough?

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Sat Jan 11 06:49:42 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 11 Jan 2025 06:49:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870085.1281536 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWVJD-0007eC-S6; Sat, 11 Jan 2025 06:49:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870085.1281536; Sat, 11 Jan 2025 06:49:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWVJD-0007e4-OA; Sat, 11 Jan 2025 06:49:23 +0000
Received: by outflank-mailman (input) for mailman id 870085;
 Sat, 11 Jan 2025 05:02: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
 <SRS0=ctmA=UD=linux.dev=jonathan.derrick@srs-se1.protection.inumbo.net>)
 id 1tWTdY-0003X1-NA
 for xen-devel@lists.xenproject.org; Sat, 11 Jan 2025 05:02:22 +0000
Received: from out-185.mta0.migadu.com (out-185.mta0.migadu.com
 [91.218.175.185]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 377372e2-cfd9-11ef-99a4-01e77a169b0f;
 Sat, 11 Jan 2025 06:02:14 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 377372e2-cfd9-11ef-99a4-01e77a169b0f
Message-ID: <bcb30b80-0902-4561-94f9-a6e451702138@linux.dev>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1;
	t=1736571726;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=87PFbocV5iG/YEPJ261ZyupRxofHWTgUBw6ylFg04/A=;
	b=C0zezy5PH3NjJJ3rja00SNNPSHRoK8WteCqC6PRIpIiAhISp3YUvWQ6F/rB5uExooUh/5q
	P2EgIwDrZfl5AnTomUIUOUbdH0GAEdogAHNXGVJotDgyAgAaSj8KKZ/4nFsHh5KpBP06Dd
	B4MOur/ybskGrVPM4vzws7U/dGEGsbw=
Date: Fri, 10 Jan 2025 22:02:00 -0700
MIME-Version: 1.0
Subject: Re: [PATCH 2/3] vmd: disable MSI remapping bypass under Xen
To: Bjorn Helgaas <helgaas@kernel.org>, Roger Pau Monne <roger.pau@citrix.com>
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
 linux-pci@vger.kernel.org, Nirmal Patel <nirmal.patel@linux.intel.com>,
 Lorenzo Pieralisi <lpieralisi@kernel.org>,
 =?UTF-8?Q?Krzysztof_Wilczy=C5=84ski?= <kw@linux.com>,
 Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
 Rob Herring <robh@kernel.org>, Bjorn Helgaas <bhelgaas@google.com>
References: <20250110222525.GA318386@bhelgaas>
Content-Language: en-US
X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers.
From: Jonathan Derrick <jonathan.derrick@linux.dev>
In-Reply-To: <20250110222525.GA318386@bhelgaas>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Migadu-Flow: FLOW_OUT

Hi Bjorn,

On 1/10/25 3:25 PM, Bjorn Helgaas wrote:
> Match historical subject line style for prefix and capitalization:
> 
>    PCI: vmd: Set devices to D0 before enabling PM L1 Substates
>    PCI: vmd: Add DID 8086:B06F and 8086:B60B for Intel client SKUs
>    PCI: vmd: Fix indentation issue in vmd_shutdown()
> 
> On Fri, Jan 10, 2025 at 03:01:49PM +0100, Roger Pau Monne wrote:
>> MSI remapping bypass (directly configuring MSI entries for devices on the VMD
>> bus) won't work under Xen, as Xen is not aware of devices in such bus, and
>> hence cannot configure the entries using the pIRQ interface in the PV case, and
>> in the PVH case traps won't be setup for MSI entries for such devices.
>>
>> Until Xen is aware of devices in the VMD bus prevent the
>> VMD_FEAT_CAN_BYPASS_MSI_REMAP capability from being used when running as any
>> kind of Xen guest.
> 
> Wrap to fit in 75 columns.
> 
> Can you include a hint about *why* Xen is not aware of devices below
> VMD?  That will help to know whether it's a permanent unfixable
> situation or something that could be done eventually.
> 
I wasn't aware of the Xen issue with VMD but if I had to guess it's 
probably due to the special handling of the downstream device into the 
dmar table.

[1] 4fda230ecddc2
[2] 9b4a824b889e1


>> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
>> ---
>>   drivers/pci/controller/vmd.c | 9 +++++++++
>>   1 file changed, 9 insertions(+)
>>
>> diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
>> index 264a180403a0..d9b7510ace29 100644
>> --- a/drivers/pci/controller/vmd.c
>> +++ b/drivers/pci/controller/vmd.c
>> @@ -965,6 +965,15 @@ static int vmd_probe(struct pci_dev *dev, const struct pci_device_id *id)
>>   	struct vmd_dev *vmd;
>>   	int err;
>>   
>> +	if (xen_domain())
>> +		/*
>> +		 * Xen doesn't have knowledge about devices in the VMD bus.
> 
> Also here.
> 
>> +		 * Bypass of MSI remapping won't work in that case as direct
>> +		 * write to the MSI entries won't result in functional
>> +		 * interrupts.
>> +		 */
>> +		features &= ~VMD_FEAT_CAN_BYPASS_MSI_REMAP;
>> +
>>   	if (resource_size(&dev->resource[VMD_CFGBAR]) < (1 << 20))
>>   		return -ENOMEM;
>>   
>> -- 
>> 2.46.0
>>



From xen-devel-bounces@lists.xenproject.org Sat Jan 11 11:10:08 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 11 Jan 2025 11:10:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870128.1281557 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWZNF-0007cr-2N; Sat, 11 Jan 2025 11:09:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870128.1281557; Sat, 11 Jan 2025 11:09:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWZNE-0007ck-W6; Sat, 11 Jan 2025 11:09:48 +0000
Received: by outflank-mailman (input) for mailman id 870128;
 Sat, 11 Jan 2025 11:09: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 <SRS0=cNkh=UD=intel.com=lkp@srs-se1.protection.inumbo.net>)
 id 1tWZND-0007ce-PO
 for xen-devel@lists.xenproject.org; Sat, 11 Jan 2025 11:09:48 +0000
Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.13])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8f573252-d00c-11ef-a0e0-8be0dac302b0;
 Sat, 11 Jan 2025 12:09:45 +0100 (CET)
Received: from fmviesa008.fm.intel.com ([10.60.135.148])
 by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 11 Jan 2025 03:09:42 -0800
Received: from lkp-server01.sh.intel.com (HELO d63d4d77d921) ([10.239.97.150])
 by fmviesa008.fm.intel.com with ESMTP; 11 Jan 2025 03:09:39 -0800
Received: from kbuild by d63d4d77d921 with local (Exim 4.96)
 (envelope-from <lkp@intel.com>) id 1tWZN2-000KZD-0q;
 Sat, 11 Jan 2025 11:09:36 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8f573252-d00c-11ef-a0e0-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=intel.com; i=@intel.com; q=dns/txt; s=Intel;
  t=1736593786; x=1768129786;
  h=date:from:to:cc:subject:message-id:references:
   mime-version:in-reply-to;
  bh=EPRt+kkcZBvWzhnBv8y7+iUHRzGlu9gQ1lTAJLYHr68=;
  b=HtBJQNxvun8isl+UqGCUWLOhvvgXOVu39uAYppFzLZxWF05Mvj1OGueB
   hFPOhrnndv1P1rRvip05DVKYv0XwGq55kD3QMq3sIpBjRF0cxxd3x9KAu
   h1Kz9I12FO7ssBr3pwLrI5uY6kYRbWq35a5lyyujUGcToZjUeu6Ea0WoM
   LTP2J4s2Jl0OlUqFhlXCR3C+XW3KyvQZK19N8nct03cTJrqkNnN0RXNyX
   oSmTNhZXMtHU3yhUKponat2+H9MEcsEJwziFa3VqojRiPJi823rVKplot
   RVOVeOJ4v1pAde8UlIYcFeXQC1J+ZP3GpZCoAyB56g2B/xhrjiCiQ1Z3P
   Q==;
X-CSE-ConnectionGUID: qNLpvHNAR4ix1ZPsMSe/Hw==
X-CSE-MsgGUID: SfGG0B1ASRWhaWhHuk8I5A==
X-IronPort-AV: E=McAfee;i="6700,10204,11311"; a="39698420"
X-IronPort-AV: E=Sophos;i="6.12,307,1728975600"; 
   d="scan'208";a="39698420"
X-CSE-ConnectionGUID: tgfbQNgiRQWNL1IdbkLGug==
X-CSE-MsgGUID: zWHsp1HuRgmlsZU4b7yXxg==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="6.12,307,1728975600"; 
   d="scan'208";a="104150974"
Date: Sat, 11 Jan 2025 19:08:50 +0800
From: kernel test robot <lkp@intel.com>
To: Roger Pau Monne <roger.pau@citrix.com>, linux-kernel@vger.kernel.org,
	xen-devel@lists.xenproject.org, linux-pci@vger.kernel.org
Cc: llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev,
	Roger Pau Monne <roger.pau@citrix.com>,
	Juergen Gross <jgross@suse.com>, Bjorn Helgaas <helgaas@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH 3/3] pci/msi: remove pci_msi_ignore_mask
Message-ID: <202501111839.HXJGe5FL-lkp@intel.com>
References: <20250110140152.27624-4-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250110140152.27624-4-roger.pau@citrix.com>

Hi Roger,

kernel test robot noticed the following build errors:

[auto build test ERROR on pci/next]
[also build test ERROR on pci/for-linus xen-tip/linux-next tip/irq/core linus/master v6.13-rc6 next-20250110]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Roger-Pau-Monne/xen-pci-do-not-register-devices-outside-of-PCI-segment-scope/20250110-220331
base:   https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git next
patch link:    https://lore.kernel.org/r/20250110140152.27624-4-roger.pau%40citrix.com
patch subject: [PATCH 3/3] pci/msi: remove pci_msi_ignore_mask
config: arm64-randconfig-003-20250111 (https://download.01.org/0day-ci/archive/20250111/202501111839.HXJGe5FL-lkp@intel.com/config)
compiler: clang version 18.1.8 (https://github.com/llvm/llvm-project 3b5b5c1ec4a3095ab096dd780e84d7ab81f3d7ff)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250111/202501111839.HXJGe5FL-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202501111839.HXJGe5FL-lkp@intel.com/

All errors (new ones prefixed by >>):

>> drivers/pci/msi/msi.c:288:40: error: incomplete definition of type 'struct irq_domain'
     288 |         const struct msi_domain_info *info = d->host_data;
         |                                              ~^
   include/linux/irq.h:130:8: note: forward declaration of 'struct irq_domain'
     130 | struct irq_domain;
         |        ^
   drivers/pci/msi/msi.c:604:40: error: incomplete definition of type 'struct irq_domain'
     604 |         const struct msi_domain_info *info = d->host_data;
         |                                              ~^
   include/linux/irq.h:130:8: note: forward declaration of 'struct irq_domain'
     130 | struct irq_domain;
         |        ^
   drivers/pci/msi/msi.c:714:40: error: incomplete definition of type 'struct irq_domain'
     714 |         const struct msi_domain_info *info = d->host_data;
         |                                              ~^
   include/linux/irq.h:130:8: note: forward declaration of 'struct irq_domain'
     130 | struct irq_domain;
         |        ^
   3 errors generated.


vim +288 drivers/pci/msi/msi.c

   283	
   284	static int msi_setup_msi_desc(struct pci_dev *dev, int nvec,
   285				      struct irq_affinity_desc *masks)
   286	{
   287		const struct irq_domain *d = dev_get_msi_domain(&dev->dev);
 > 288		const struct msi_domain_info *info = d->host_data;
   289		struct msi_desc desc;
   290		u16 control;
   291	
   292		/* MSI Entry Initialization */
   293		memset(&desc, 0, sizeof(desc));
   294	
   295		pci_read_config_word(dev, dev->msi_cap + PCI_MSI_FLAGS, &control);
   296		/* Lies, damned lies, and MSIs */
   297		if (dev->dev_flags & PCI_DEV_FLAGS_HAS_MSI_MASKING)
   298			control |= PCI_MSI_FLAGS_MASKBIT;
   299		if (info->flags & MSI_FLAG_NO_MASK)
   300			control &= ~PCI_MSI_FLAGS_MASKBIT;
   301	
   302		desc.nvec_used			= nvec;
   303		desc.pci.msi_attrib.is_64	= !!(control & PCI_MSI_FLAGS_64BIT);
   304		desc.pci.msi_attrib.can_mask	= !!(control & PCI_MSI_FLAGS_MASKBIT);
   305		desc.pci.msi_attrib.default_irq	= dev->irq;
   306		desc.pci.msi_attrib.multi_cap	= FIELD_GET(PCI_MSI_FLAGS_QMASK, control);
   307		desc.pci.msi_attrib.multiple	= ilog2(__roundup_pow_of_two(nvec));
   308		desc.affinity			= masks;
   309	
   310		if (control & PCI_MSI_FLAGS_64BIT)
   311			desc.pci.mask_pos = dev->msi_cap + PCI_MSI_MASK_64;
   312		else
   313			desc.pci.mask_pos = dev->msi_cap + PCI_MSI_MASK_32;
   314	
   315		/* Save the initial mask status */
   316		if (desc.pci.msi_attrib.can_mask)
   317			pci_read_config_dword(dev, desc.pci.mask_pos, &desc.pci.msi_mask);
   318	
   319		return msi_insert_msi_desc(&dev->dev, &desc);
   320	}
   321	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From xen-devel-bounces@lists.xenproject.org Sat Jan 11 12:25:27 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 11 Jan 2025 12:25:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870156.1281567 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWaY8-0001VR-HW; Sat, 11 Jan 2025 12:25:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870156.1281567; Sat, 11 Jan 2025 12:25:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWaY8-0001VK-Ec; Sat, 11 Jan 2025 12:25:08 +0000
Received: by outflank-mailman (input) for mailman id 870156;
 Sat, 11 Jan 2025 12:25: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 <SRS0=cNkh=UD=intel.com=lkp@srs-se1.protection.inumbo.net>)
 id 1tWaY7-0001VE-4N
 for xen-devel@lists.xenproject.org; Sat, 11 Jan 2025 12:25:07 +0000
Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.20])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 13eee5ec-d017-11ef-a0e0-8be0dac302b0;
 Sat, 11 Jan 2025 13:25:04 +0100 (CET)
Received: from fmviesa002.fm.intel.com ([10.60.135.142])
 by orvoesa112.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 11 Jan 2025 04:24:59 -0800
Received: from lkp-server01.sh.intel.com (HELO d63d4d77d921) ([10.239.97.150])
 by fmviesa002.fm.intel.com with ESMTP; 11 Jan 2025 04:24:56 -0800
Received: from kbuild by d63d4d77d921 with local (Exim 4.96)
 (envelope-from <lkp@intel.com>) id 1tWaXu-000Kcp-06;
 Sat, 11 Jan 2025 12:24:54 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 13eee5ec-d017-11ef-a0e0-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=intel.com; i=@intel.com; q=dns/txt; s=Intel;
  t=1736598304; x=1768134304;
  h=date:from:to:cc:subject:message-id:references:
   mime-version:in-reply-to;
  bh=A/8dZvb4PodA5W5f8//xP4ydt9geI9IEAZNNNqDbBBk=;
  b=L4eqZmcGKPClDZE944HDryXMaD3iXVM4vYFdm8xt5j+rVGKS2iUCb5Ua
   Q4oIxfX1hiIgY4Gel14xcdtXKRS4cz6R/x4IOd3JxPrumENrNmQBcnR0C
   wOvzzOIPaiktN70RBfZ6frDK12Sf79REq3RLa/aUfe5KCBgfBhsgHwtx0
   er9lFPIrr95tcT6/boClXr8guXkzEpmLnfUafOg9fFQhDmUylOxYNZKtr
   7mssIjQy3YL1HIFNKQ2+f3dduwDRO9QEUi60rDmLauexB9Of8On9FAXZw
   rMdsVuRupf3V36oGk0zajByUuRx3zkdCB+8YKbBco7jgP85xWIMt7Mjb0
   w==;
X-CSE-ConnectionGUID: m8goT+0WRG+5fPMtKpj2lg==
X-CSE-MsgGUID: ru0qFPFpQj6B+X2cbsxcAg==
X-IronPort-AV: E=McAfee;i="6700,10204,11312"; a="36568771"
X-IronPort-AV: E=Sophos;i="6.12,307,1728975600"; 
   d="scan'208";a="36568771"
X-CSE-ConnectionGUID: s7uiThp/StuhE0Qw+ZroYg==
X-CSE-MsgGUID: wIRlLujDR0CozHf5o3+rzQ==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="6.12,224,1728975600"; 
   d="scan'208";a="127260895"
Date: Sat, 11 Jan 2025 20:24:15 +0800
From: kernel test robot <lkp@intel.com>
To: Roger Pau Monne <roger.pau@citrix.com>, linux-kernel@vger.kernel.org,
	xen-devel@lists.xenproject.org, linux-pci@vger.kernel.org
Cc: llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev,
	Roger Pau Monne <roger.pau@citrix.com>,
	Juergen Gross <jgross@suse.com>, Bjorn Helgaas <helgaas@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH 3/3] pci/msi: remove pci_msi_ignore_mask
Message-ID: <202501112048.6yCFh2ma-lkp@intel.com>
References: <20250110140152.27624-4-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250110140152.27624-4-roger.pau@citrix.com>

Hi Roger,

kernel test robot noticed the following build errors:

[auto build test ERROR on pci/next]
[also build test ERROR on pci/for-linus xen-tip/linux-next tip/irq/core linus/master v6.13-rc6 next-20250110]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Roger-Pau-Monne/xen-pci-do-not-register-devices-outside-of-PCI-segment-scope/20250110-220331
base:   https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git next
patch link:    https://lore.kernel.org/r/20250110140152.27624-4-roger.pau%40citrix.com
patch subject: [PATCH 3/3] pci/msi: remove pci_msi_ignore_mask
config: riscv-defconfig (https://download.01.org/0day-ci/archive/20250111/202501112048.6yCFh2ma-lkp@intel.com/config)
compiler: clang version 19.1.3 (https://github.com/llvm/llvm-project ab51eccf88f5321e7c60591c5546b254b6afab99)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250111/202501112048.6yCFh2ma-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202501112048.6yCFh2ma-lkp@intel.com/

All errors (new ones prefixed by >>):

   In file included from drivers/pci/msi/msi.c:12:
   In file included from include/linux/irq.h:23:
   In file included from arch/riscv/include/asm/irq.h:10:
   In file included from include/linux/interrupt.h:22:
   In file included from arch/riscv/include/asm/sections.h:9:
   In file included from include/linux/mm.h:2223:
   include/linux/vmstat.h:518:36: warning: arithmetic between different enumeration types ('enum node_stat_item' and 'enum lru_list') [-Wenum-enum-conversion]
     518 |         return node_stat_name(NR_LRU_BASE + lru) + 3; // skip "nr_"
         |                               ~~~~~~~~~~~ ^ ~~~
>> drivers/pci/msi/msi.c:288:40: error: incomplete definition of type 'const struct irq_domain'
     288 |         const struct msi_domain_info *info = d->host_data;
         |                                              ~^
   include/linux/irq.h:130:8: note: forward declaration of 'struct irq_domain'
     130 | struct irq_domain;
         |        ^
   drivers/pci/msi/msi.c:604:40: error: incomplete definition of type 'const struct irq_domain'
     604 |         const struct msi_domain_info *info = d->host_data;
         |                                              ~^
   include/linux/irq.h:130:8: note: forward declaration of 'struct irq_domain'
     130 | struct irq_domain;
         |        ^
   drivers/pci/msi/msi.c:714:40: error: incomplete definition of type 'const struct irq_domain'
     714 |         const struct msi_domain_info *info = d->host_data;
         |                                              ~^
   include/linux/irq.h:130:8: note: forward declaration of 'struct irq_domain'
     130 | struct irq_domain;
         |        ^
   1 warning and 3 errors generated.


vim +288 drivers/pci/msi/msi.c

   283	
   284	static int msi_setup_msi_desc(struct pci_dev *dev, int nvec,
   285				      struct irq_affinity_desc *masks)
   286	{
   287		const struct irq_domain *d = dev_get_msi_domain(&dev->dev);
 > 288		const struct msi_domain_info *info = d->host_data;
   289		struct msi_desc desc;
   290		u16 control;
   291	
   292		/* MSI Entry Initialization */
   293		memset(&desc, 0, sizeof(desc));
   294	
   295		pci_read_config_word(dev, dev->msi_cap + PCI_MSI_FLAGS, &control);
   296		/* Lies, damned lies, and MSIs */
   297		if (dev->dev_flags & PCI_DEV_FLAGS_HAS_MSI_MASKING)
   298			control |= PCI_MSI_FLAGS_MASKBIT;
   299		if (info->flags & MSI_FLAG_NO_MASK)
   300			control &= ~PCI_MSI_FLAGS_MASKBIT;
   301	
   302		desc.nvec_used			= nvec;
   303		desc.pci.msi_attrib.is_64	= !!(control & PCI_MSI_FLAGS_64BIT);
   304		desc.pci.msi_attrib.can_mask	= !!(control & PCI_MSI_FLAGS_MASKBIT);
   305		desc.pci.msi_attrib.default_irq	= dev->irq;
   306		desc.pci.msi_attrib.multi_cap	= FIELD_GET(PCI_MSI_FLAGS_QMASK, control);
   307		desc.pci.msi_attrib.multiple	= ilog2(__roundup_pow_of_two(nvec));
   308		desc.affinity			= masks;
   309	
   310		if (control & PCI_MSI_FLAGS_64BIT)
   311			desc.pci.mask_pos = dev->msi_cap + PCI_MSI_MASK_64;
   312		else
   313			desc.pci.mask_pos = dev->msi_cap + PCI_MSI_MASK_32;
   314	
   315		/* Save the initial mask status */
   316		if (desc.pci.msi_attrib.can_mask)
   317			pci_read_config_dword(dev, desc.pci.mask_pos, &desc.pci.msi_mask);
   318	
   319		return msi_insert_msi_desc(&dev->dev, &desc);
   320	}
   321	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From xen-devel-bounces@lists.xenproject.org Sat Jan 11 15:09:28 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 11 Jan 2025 15:09:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870192.1281577 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWd6v-0004x6-Q7; Sat, 11 Jan 2025 15:09:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870192.1281577; Sat, 11 Jan 2025 15:09:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWd6v-0004wz-NH; Sat, 11 Jan 2025 15:09:13 +0000
Received: by outflank-mailman (input) for mailman id 870192;
 Sat, 11 Jan 2025 15:09:12 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=3a6F=UD=bounce.vates.tech=bounce-md_30504962.67828993.v1-4181cfcd335046d1b5a1c2b04b5995fe@srs-se1.protection.inumbo.net>)
 id 1tWd6t-0004wt-UL
 for xen-devel@lists.xenproject.org; Sat, 11 Jan 2025 15:09:12 +0000
Received: from mail128-16.atl41.mandrillapp.com
 (mail128-16.atl41.mandrillapp.com [198.2.128.16])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0143639f-d02e-11ef-99a4-01e77a169b0f;
 Sat, 11 Jan 2025 16:09:09 +0100 (CET)
Received: from pmta08.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail128-16.atl41.mandrillapp.com (Mailchimp) with ESMTP id
 4YVhkW2VFMzRKLrmr
 for <xen-devel@lists.xenproject.org>; Sat, 11 Jan 2025 15:09:07 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 4181cfcd335046d1b5a1c2b04b5995fe; Sat, 11 Jan 2025 15:09:07 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 0143639f-d02e-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1736608147; x=1736868647;
	bh=VLgIzAFyCUuF9Ji1xJT4VnGZDfDS0TmVt9diARf3Sac=;
	h=From:Subject:Message-Id:To:Feedback-ID:Date:MIME-Version:
	 Content-Type:CC:Date:Subject:From;
	b=1dbt7n9/tJbCgmX/xhXl0iOmh4UHQ2NdUC2heV2Fs+x1b2Y61hx8OKA1PthWREt+k
	 HdiNfPr7K0GtE6tJKaHhPlHwj5zglJwZouCCfXSuXg9zPfVphb2dUI69CTfTdEPchD
	 YmTHewUJfAaQbCKVLn4mlVeld7gZ5UAsaBX6bnKX1IurM9ZrF42J1O6U4VfkE8V+tm
	 FVKBl2vT3ksoT9Yo/Ho24rTSx3zXb0uBOreEiUMNF9V5EYAivsBKDF7qOmK6mhxKd6
	 0U8s0kSdl5IyzMH37WaBH3Ga/2xsLEcv/BLRskNwRI8kzrpkU0HKOu/tceVs8YlyBB
	 o7E1/VMHBTI2g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1736608147; x=1736868647; i=olivier.lambert@vates.tech;
	bh=VLgIzAFyCUuF9Ji1xJT4VnGZDfDS0TmVt9diARf3Sac=;
	h=From:Subject:Message-Id:To:Feedback-ID:Date:MIME-Version:
	 Content-Type:CC:Date:Subject:From;
	b=UUquF+vQksOi1c2deg//unEK8ibb00C0mAk7pc6QxX2wGLS5GBvrOuYcISTYpvzzD
	 m2ibTzP1oYF5fgEPi8lqy00EG2d0UOqs4cU0olRRv5oWhPkcpGMGcsLH/fWryBmR2M
	 8KvRsibkHax0apno6P2fRWk9AzXSPwDJsMImnmm8maZgTklLJQYa5enrwzjaXrk+wh
	 8yG86nl4UrXYPFOv2W8SW68D1ZZfz6qXyVsRr2a4NxgkYTiNu0v3dZhoYMUfYc37c2
	 bWqWRmWRJtrO5rAQtnceAdekngsm/BtTMxF71OTjQzXZ0lV2clAlB7PYChUO1qo1pi
	 4zlGmd5+X/YNA==
From: "Olivier Lambert" <olivier.lambert@vates.tech>
Subject: =?utf-8?Q?Xen=20Winter=20Meetup=202025:=20Final=20Countdown=20and=20Important=20Updates!?=
X-Mailer: BlueMind-MailApp-v5
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1736608146214
Message-Id: <m5sbgdoq.17ljxuaaw622o@vates.tech>
To: Xen-devel <xen-devel@lists.xenproject.org>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.4181cfcd335046d1b5a1c2b04b5995fe?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250111:md
Date: Sat, 11 Jan 2025 15:09:07 +0000
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="_av-eg7-eceXNDk7VFvsSVntZw"

--_av-eg7-eceXNDk7VFvsSVntZw
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hello everyone,

The Xen Winter Meetup is just 3 weeks away! We=E2=80=99re in the final lap =
of preparations, and here=E2=80=99s everything you need to know:

 % 
   New Matrix Channel
   To make organizing and event-related questions easier, I=E2=80=99ve set =
up a Matrix channel for all participants. Feel free to join and connect at:
   https://matrix.to/#/#xenwintermeetup2025:matrix.org
   
 % 
   Call for Papers: Final Reminder
   We still have free slots for talks, but only a few days remain before we=
 finalize the program!
   
    * Don=E2=80=99t hesitate to submit your proposals=E2=80=94we=E2=80=99ll=
 ensure no topics are duplicated in the schedule.
    * Submit your talk now at: https://cfp.vates.tech/xen-meetup-2025/ [htt=
ps://cfp.vates.tech/xen-meetup-2025/]
    * The schedule will be published at the end of next week, so this is yo=
ur last chance to be part of the lineup!
    % 
   Event Details
   
    * The main event page is your go-to resource for details about accommod=
ation, travel recommendations, and more:
      https://campaign.vates.tech/xen-project-winter-meetup

We=E2=80=99re excited to see everyone and make this a successful and engagi=
ng Meetup. Don=E2=80=99t miss the chance to contribute, connect, and collab=
orate with the community!

See you soon,



Olivier Lambert | Vates CEO

XCP-ng & Xen Orchestra - Vates solutions
Book a meeting with me: https://cal.vates.tech/olivier.lambert
web: https://vates.tech


--_av-eg7-eceXNDk7VFvsSVntZw
Content-Type: multipart/related; boundary="_av-abgFSrRs5Ha7cpUhVi8I4Q"

--_av-abgFSrRs5Ha7cpUhVi8I4Q
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html>
 <head></head>
 <body>
  <div style=3D"font-family: Verdana, Verdana Ref, Corbel, Lucida Grande, L=
ucida Sans Unicode, Lucida Sans, DejaVu Sans, Liberation Sans, sans-serif; =
font-size: 9.75pt; color: rgb(31, 31, 31);"></div>
  <p>Hello everyone,</p>
  <p>The Xen Winter Meetup is just <strong>3 weeks away</strong>! We=E2=80=
=99re in the final lap of preparations, and here=E2=80=99s everything you n=
eed to know:</p>
  <ol>
   <li>
    <p><strong>New Matrix Channel</strong><br>
      To make organizing and event-related questions easier, I=E2=80=99ve s=
et up a Matrix channel for all participants. Feel free to join and connect =
at:<br><a rel=3D"noopener" target=3D"_new" href=3D"https://matrix.to/#/#xen=
wintermeetup2025:matrix.org"><span>https</span><span>://matrix.to</span><sp=
an>/#/#xenwintermeetup2025</span><span>:matrix</span><span>.org</span></a><=
/p></li>
   <li>
    <p><strong>Call for Papers: Final Reminder</strong><br>
      We still have free slots for talks, but <strong>only a few days remai=
n</strong> before we finalize the program!</p>
    <ul>
     <li>Don=E2=80=99t hesitate to submit your proposals=E2=80=94we=E2=80=
=99ll ensure no topics are duplicated in the schedule.</li>
     <li>Submit your talk now at: <a rel=3D"noopener" target=3D"_new" href=
=3D"https://cfp.vates.tech/xen-meetup-2025/"><span>https</span><span>://cfp=
.vates.tech</span><span>/xen</span><span>-meetup</span><span>-2025/</span><=
/a></li>
     <li>The <strong>schedule will be published at the end of next week</st=
rong>, so this is your last chance to be part of the lineup!</li>
    </ul>
    <div>
     <br>
    </div></li>
   <li>
    <p><strong>Event Details</strong></p>
    <ul>
     <li>The main event page is your go-to resource for details about accom=
modation, travel recommendations, and more:<br><a rel=3D"noopener" target=
=3D"_new" href=3D"https://campaign.vates.tech/xen-project-winter-meetup"><s=
pan>https</span><span>://campaign.vates.tech</span><span>/xen</span><span>-=
project</span><span>-winter</span><span>-meetup</span></a></li>
    </ul></li>
  </ol>
  <p>We=E2=80=99re excited to see everyone and make this a successful and e=
ngaging Meetup. Don=E2=80=99t miss the chance to contribute, connect, and c=
ollaborate with the community!</p>
  <p>See you soon,<br></p>
  <div class=3D"x-disclaimer-668557390">
   <div>
    &nbsp;
   </div>
   <div>
    &nbsp;
   </div>
   <div>
    <div>
     <br>
     <table>
      <tbody>
       <tr>
        <td style=3D"font-size: 10pt;">&nbsp;</td>
        <td style=3D"font-size: 10pt; padding-left: 20px; border-left-color=
: #b42626; border-left-style: solid; border-left-width: 1px;">
         <div>
          <strong> Olivier Lambert | Vates CEO</strong>
         </div>
         <div>
          <strong></strong>
         </div>
         <div>
          <strong>XCP-ng &amp; Xen Orchestra - </strong>Vates solutions
         </div>
         <div>
          <a href=3D"https://cal.vates.tech/olivier.lambert">Book a meeting=
 with me</a><strong><br>
            web:</strong> https://vates.tech
         </div>
         <div>
          <img style=3D"float: left;" src=3D"cid:x-disclaimer-668557390-173=
6608146213.png@bm-disclaimer" alt=3D"" width=3D"174" height=3D"159">
         </div></td>
       </tr>
      </tbody>
     </table>
    </div>
   </div>
  </div>
 <img src=3D"http://bounce.vates.tech/track/open.php?u=3D30504962&id=3D4181=
cfcd335046d1b5a1c2b04b5995fe" height=3D"1" width=3D"1" alt=3D""></body>
</html>


--_av-abgFSrRs5Ha7cpUhVi8I4Q
Content-Type: image/png
Content-Transfer-Encoding: base64
Content-Id: <x-disclaimer-668557390-1736608146213.png@bm-disclaimer>
Content-Disposition: inline

iVBORw0KGgoAAAANSUhEUgAAAK4AAACfCAYAAABgKuLmAAAm4XpUWHRSYXcg
cHJvZmlsZSB0eXBlIGV4aWYAAHjatZxpkmSpcoX/swotgXlYDuBgph1o+foO
kVmva2jZa8lU1VWZFRlxL+DuZ3C47c5//ed1/8GvEYZ3ubReR62eX3nkESff
dP/5Nd/fwef39+el8/Wz8PPrbtyvH0ReSnxNn3/2+vX+79fDjwt8vky+K3+5
UN9fP1g//2Dkr+v3Xy70daOkEUW+se8RfV0oxc8PwtcF5mdavo7e/jqF9TW1
r89/loE/Tn/dHYdeK+vzs1//nRurZ4X7pBhPCsnzd0pfA0j6E12afFP5O6YU
30vvlc7fIcWvkbAgf1qnH7+4rbsaav7jm36Kyo/vfonWGV9r9Gu0cvx6S/pl
keuPr3983YXy56i8pf/LnXP/+i7+/ProMX5G9Mvqv8W/1u+bM7OYubLU9WtS
31N83/E+wpF16+4YWvWNP4VLtPd78LuT1ZtUML/94vcOI0TCdUMOFma44byv
O2yGmONxsfFNjDum92JPLY64iVtIWb/DjS2NZMQxpv3CnlP8MZbwbjv8du9u
nTtb4K0xcLHwkuAf/nb/9AP3qhRC0FoS+vCJb4xabIahyOlv3kZEwv1a1PIW
+Pv3r78U10QEi1ZZJTJY2PW5xCrhX0iQXqATbyx8/dRgaPZ1AZaIWxcGExIR
IGohlVCDbzG2EFjIToAmQ48px0UEQinRGGTMKVVi06NuzUdaeG+NJfKy43XA
jEgUKq4Rm5Emwcq5kD8td3JollRyKaWWVnoZZdZUcy211lYFirOlll0rrbbW
ehtt9tRzL7321nsffY44EqBZRh1t9DHGnNxzcuXJpydvmHPFlVZexa262upr
rLlJn5132XW33ffY06IlAz+sWrNuw+YJh1Q6+ZRTTzv9jDMvqXaTu/mWW2+7
/Y47f0TtK6y//f4HUQtfUYsvUnpj+xE1Xm3t+xJBcFIUMwIWXQ5EvCkEJHRU
zHwPOUdFTjHzA8RLJTLIophZUMSIYD4hlhu+Y+fiJ6KK3P8pbq7ln+IW/7eR
cwrdP4zc73H7U9RMNLRfxD5VqEX1ierj56fP2KfI7revTjNvjRUI8HbqXrdv
xdvlv139mjVY7qcXSmjvnE4bo8XF2Po+56wzNhTXorNcILFSOrVFGe7A9LnF
NK3KmL3OuveqQXFodY9uQGIfkzocZ0Cv8/S0/XDHjzVuYJly3SeNUl+5pphZ
wnA2ydC5/Gms3vWbhUrjhH59OqOcMI3qtTTNBUi/7wWM2upzkzUk28nDkwib
peRNfVeuOYkcWVEWoyHtrJzdejkdFUJybDcy60sGdOZf9xzr7tVPLgZWA7un
pRuJQj8ELu92/SHFjDBxrTEZXWplj7tcjiRQ4D5UgmkAhMlaKocx7HLjJAQl
9VJOmYvI1pLi7gW+inX1OEsjy85pbl7+BXiFxSL5wj8LObqCTULGAjEO1rnn
wFVOKo0ViBEtRMFsS6GXmk+2c1ybjIVsz7WWXfhA8jt3VrhNhlQHFGQzHX4e
ZjUS/aSpW55k96xiSA/L0ABTG6msQIjyQvgR07amtR6O1VNaM4TSYvixPq0R
Q0zGHM3yu8WsA54kRg4as3LTaiSL7RbO1PULaxupwhzbYriRYgtjo35KhXsz
eTLrqYUs3Zv5Uj9uz7vJCkpxmU+FYDZbKIZUQN6Qx76gQSdpxs0I0VlJRj9O
7kq+ESja3fKmRM4l+FVE0ts+FR0WSvOdwJ05zt61BMqn8P6sb3KROvzDV/d3
P+ArI2aAo+Vl5PoF2pjz7GUZf3ZpixEAFndYSd5ZbHu3g7q4hXRf5cRrYeUM
qhAAgn8LRDbvzMHbmoHwGtULYwdAYuUWNffgiHnbCcCpfiRIgpvCkk0IC5MC
djESpKS45mPpSOM23fU0tA24Vcoq2cCj0ljOvraFsVoKBygJaezT7LbGZftN
dsqezHCWvfxRvjLwPQjcpNiJ0J7AyDk1jNJCzGVITzWSgMQPdw6GulgkQwyR
PLycbZGTzOSmaicBIevmmMO8w92FvlpzFWp5VIubWS9KCtSKB4IrI5L2fs9F
nXrrZyYwoTAR4MoD3iFQ9WE4BCJzWaQh6bqbNaqMer0l2WAGm8iV2QLVEU05
xLhPBy9yIFFLPZpF4JaOpSX5gfmRbh8xqzJnaCWBCZV/8zFKB73YMCswBIgc
y5lb8Y+xGtzVUlzH7eZBm7JT2tQxeQBjWa2HdbwR7iqwwRi5Ax/oGWNGK+qe
4ChoR2neDKzG5YI/lfWf5Sq+eofFAEN11Bs1ukG6OOPRrM5B5RbgASIjWTpk
OS4/7cPyJPyeRG7xxA0MrlJmznPtjQFsZfrT4csNvEYSgjFwXVYXSjA+yNio
PXHFudRaXBQjl5IZYI2qRqLAHq7YrYLgc3cIm5QmkKx0hUJUfavDYmQVP9zm
JnFBSPcKas+sFIaCFuIkGFkcdqvkk5HNKz9p3jdTj3B6k468jPV4gAOoLQR6
Znj9dooOfjjiNIqBP/bFpQav+Pm+93/z1f32A+gH4Ukq1JOgssPStw3Jwfyn
whyQiGpvyfDNS6Ch2WTRLdsKR4+3mp04YMjSSbs4Ka8hCaw4g4Z8CJHEihCJ
Qt1INC0iFkMfTMhRY/MuJnzJbjyHl3Bi8XoX1gP6jZrwECpaqwrtKA1WhUEb
vL+mJAjyaTsqdiC1oqgFLO+oPZUQtE3ZiZt46xqinw2tJt6VVRKFNIROU7G2
8cD+uLoo2YFCGIb4AfP6nO1Ax8BvTJXc6wYHpKbvblGt7ZA6tcB4pKuQGMze
3DWMV52icGOw7aiwmrLukCtzCh9JP8ogGQxb6pOFYPm9naWRAVeSXqf0K8U3
iCsY6nKfVW/KAhNgp4IRtc7LgA/xKtQF9YegPNVSrHyu8SKpXtwDcEgEyqIe
9uNXBIJW1b9kgs9IZ2iHeW3kQkbropKAJ+IY4KZMAiC0CBdsM1rjSowX7fnU
BzIuAohIyQbYIQ1hi0l2AyJA4eKGAAGhYLnCEaQ4FEJBb4vNIWgYRPKKu8om
wWngQLKnFA6ITpUjdsXB6Yqtqb0pcRML3M8FVwuQBrIIgASuO/V19R+RQoyg
0akfOB+/la7ZZml5F682FBXw5jsy10Hz2QgSq9tJbCKU14K20MOpUR2dSuk7
XH1EQ5/Q/RVmiwFQ28dmb5J+YNlAId7Hrghw6NI/lkZ6/DtfixlubSy3rQAE
udThFyrPp3Q8UoSlHcd4A3oe1YyER6rHhQIuZGEn6nBDUQZy45VGdSREAR6J
BapWqnTiWU7D45jaIEgVrdtl+CdU2ADjeUVeyw4fWDs+n1SSO6jHLc24Qfk6
FqxNjlNVLXnk32DJK1oYyQuKAHukDjA8MAPoGeCXOidbNwRJmkGfUAicRf3o
dnJESUKZ+k8d82Faki0rSGitzzVwC/sywE61wVitOxZ4oyqhn0SUIAwQDnc0
QAHAjgxgTRa5jtZjhan0+qXUScl+SRR0xOGaLgEhr6GAEQifCt8jI0P0flJk
ngQQHWWxJFtH6zLe4tX3qipkxL8oxkFSTAqWQ9kcALxJBMaSVfckL1kzfTGP
ifK3UPbob0IC65JJwCjv405ze8cIPD4EYAC9kK8suFJW/pRy0GXhfOCIT7CC
Yy6KuU4KH7GLx9hG9clqOIwliQmeLtQw+W31bhCJoXX4dEaWmTVgqEVYB/YA
Z6AnSh0J6GMhqTBUq1IiCMBja9cDTUEHU7MghUBUqTmsgkHYT1QDi4hHJAGQ
vTEkvuYkj5V2yehsNAkLFAwEmRNjsQX4oSL3A54OjbcQa7gh3tQRAbFQ3qTG
9lsgenApESnmgB+jGKAkcAbtjZ6BLzHCAN6BmpBCcwSiTQIrTZFOqaNWD+gH
DuaKo+x2p7N7UVpeFKGhBRyTbkj+XgkzxsK/GDp/GCJmA1RA5EdWTi2wSg4R
NKY27t4SaKgqUtTjkRYpl0UAOxEk4Phc3M5ZCV1MwTI1ZMNDNDIuiJTAsoCI
IGNmarfyXvlRrB0431hcFPcqCETCeNOtuGUuBm2thX5BmB0YGECmGOSy/85+
v68Lw4p5Yf2O76iggwZOMD1qRTl1JbDD83WIURg6S5PB1QaMI94lfMBYCX44
2cslSY61K/6naDCuBY6TkDywKdIAJKZo0eFEGQ6R7BURjryANggvspKA9UEy
IyhYXMQ1ohBEgRzJu1wzMgq9TzGSkMOEQWTERMPAsbAQlA7q9+UX6IFF24ls
BluJt+QVLoscQKHhQQnG1IQdeOszYoOy2RDpwNvqDhQWVjo3y0gguMEQToho
ZJtxV+JUKOw4kCDUKF44uowWRMDkhiGW9qDExF19nxmBm2tCIPVgUBcCt8uS
zLlQWih3ro3iAHgzVhQM52OsCT/Ez6IN+WHHQCw0PDWIcztNmrPydkqJIhJ7
YgrxMxdyRwaPUzHHeeM8wIvbgqwimabmNZ4b6s7PsJJD8ckXiEshRXQPVp2A
dRYiV3WXnDy/YTNPqjgASLmAs9gx8jExJEAUEGhwA4DP2mK8WN9B3cIyov/G
RRaGyQW0RCXeaPCLiwloClz+JSlQORQvNQqg14TyQFpPBA0IBuGRKig0hY2c
mym7NVJsSKfI20gBTNWD4y9oHZVgQEa4INaBYbTMbTqItzCcBulQJLiNlNwH
fEFJ7Gc4H6kUYUIYAlEzkFn5brIfTbdAIuXRAIqPyK2Qm9hww8dRIgnp2ja4
UyWu0IHrUDuIFwgLJ4Ptq6fLE+A9D9mHlInPZmCU0KRSLI14uziWBdAQn0PS
5IjlQUMhVHfWssaGbS/6GzLinixuxloP6PYCc4/Gr3yQw7zjGLH2IBGrsaXK
KOYOJEGRh0msAS+q0plegcRZNwQNkSBdq4WI2kNmOO02NRINR0tCJzCIZV9k
PwUInB2P7CUCFKotNQeh4N0lTTe1g7a+CRoAtR3FRI01WIc0Gr2jeFkhxBWu
EQoCwLpnkkudJNQ6OI7p4q8h9Sr7nkhlVsNRkGgttKIZ3MuNMGUJ6WuMOIA9
3bxQOG4AFoAC+NXOeZ5g7CfOUPOM1pHxH/3V/w4m40SAqB1rPe8plGBuaAem
i+CeRNTIK0cJTYUlHwQhSQ50Y/AoRji5W2bs0MVFOIBGhHKA+SsI7QZVFlHD
i3RqsTksFmOlPvAdkXStYcJ82BByMQYSrNaGYasIGQo43ZZVyVXMBWMEQKKX
68sh/AE1UlId8ELfDK1FDCPrFpkJH5sUASwEBsBTSPuQZeD2JrS2YahANTFV
11dQq1rtWFhWbYUnUkORrggIYnQoVplspLCxL/29CFKkco8ujBrAXxyHNAas
mIZym8TPZig66mdGqQA0a2pVPr0QZ8gy+MDMcH0kKAqg4DqYUVtgdvKoctBT
zVNwgJzSTJFt2Fo8LbxV1RGs6k8EFU6mHGHfirzLwBI4hKpy6jUuxhGylGC9
KH302FNwWtygpUC78FG01lI3ed7LMnbKcUrhCR+gBzfxH5qSqbHNZxF6XVm2
qGx1eOS7jFXrSZtF8v94P0TTaZTQZVA9YGMlIvAp8J7QSXR4tdU7q2oSJAOX
h5jSh8kyMqJUgfRIpC2xEGojxyEN5IubFZ84iXeEp9XO1FrbyqqrCDyk68FX
YEwdAZAtlWcRDnx8yGN0cJKV9w7MuaoyqRRxlzQPQILqgehKUNMG9G5kE5AP
SVR5YGMF8VsgyJYPiLfgRRAH2I09qV34HSETRaymlkhDYvFFu5hhJUA5xtrk
1DtUAHKR1vV5TbV9UOVzHaCWyr3Q7dj26YUaVNn/fcPlfnohyLfhFagX5Bwq
69ELyR4gl9s2KvBOuSVMh3wCmv+1JvZMz/dDBd4aa/xAnSJE4oC461G3evlj
1jjJf6z6IH+xikLGim9eQ9uEbZhrYBgCg7RJmHojSXANmK0Ku3p7TgJjLd6H
1Ej4HUuPBAxUJR0hogL7UmYsNl4ablQXrcqO1NI2iYeO56LIeaRUVa8nT5BB
9hFpjNEbZCQKSY3xJlvsbIbYnjNCi6NDQFJCPZVNGWinvJN6CKR9R0/h1kS0
Er8YaDW2N8KQFPausAo4yIDNmCQ3ghZUIK9kvckR9D2wF1Di0COvRxRxU2NQ
zc+k3l4lwcq6rsULUWGWo5SfkR/oMNxAr0n7PkQnq1OKwmVlgW+GAhYgpyBu
xMDBc0nBZMclcBlUGWasCH1UJ0gSbp7UlED8seLYCcww9R+Upw+PYBKApG2U
YvLpOioc2JLBWTcAH1tdcQQ/YWuRIp0kNuDdwUG5r7f5xDxx6gk9S1HUFRrY
6IKOUeCUcScJfoMpKFuo72ovK4YQqUSkCQlPfjGbpL2HQaYhliCMpZ2GQ5Y6
lhjYR6p5eAiUQnyrpQDqkFP3IFNRM/ACYY/DTGZmdDzF7p4yQlCpFQ4jY2pw
ayjb+LZSKytzyAybS1s4B505IcY91KuBEwFIct7uoZBQN4CTIaMPueuGZ/mo
5whtUNdloSNImaBtUAwLfN1RXyhkBDWwzFi7NBtRB5kRW9pNBRDMaRPvU+65
pf5P2it/LfbVULWvCYrI1/bDSqQ92CajeVrVvugFGZFHmbXqFQ5Gj7PMRBaQ
RmcsVD946d3OR0UMQrxtR5wbpAS0gqirk7QocPDtykVi4utOkCE2Mowzj0dx
TmQBybS40BWBQfpgJ1pD+yiwONhHul3BpxQWV8JaET/lpNcqErTI2jV5/w4Q
uartko6/yIFvhDmUSlj19WJR0WrIs9Rkt1o0VLB62JAg2B8W2hOdbDBMcHVB
MoxUO942t4eb4OKpVl2QImC2FZZWYyyomcEPXjc7elQhxgeZEMHE7ZL21du1
myVqsHOYFxg0IoQQP9R4er0W8iOJ0OJuW0PC9sWtPlqhNFnW46gjZrcZT8eo
Qj1F2nDlcnBh2jBgGIFJYg+RX1fdeXmdzkxmNJjEUOZlNtcRktSwr9ryPt2Q
EqDIwKYgw+L0alDBT0kVTWaC+7vfpcxGiwUyb6nHv7bLGw+HMtM2b/u0WFGj
QAFy+YBfSELlBqZ9HFOLjvIoSwiGTzyIi6RdsX2dUBobL8k3UQ6oNSCLqio7
yVdgqNDUiMaKlg/YaOC3GrBP0EdCg1UqDlaCjpp6HIhwFE/QnimevXtJPRAc
FYdnI/B4CGzb8VQ9ohGoqjDSYiqVG2hbfrhYtTnpXzhNHrYQUpQiA99cs8L7
UTsGUoJTWyjaxIckVsBP5nfYqWMx8P1UCDAGtKyFoJi1AkMF5whVJg3F1OzH
+XkIlNWO+Af4lAVFpvQ7lyQYes/BweCcNijuXmDn7b5AIMSHrK3AQcfzR6/0
yyzr1g5qRGTierT3BU5CX0Cdo+jxORtSUwMfQgNjKobiG1uq/x93VX98df7f
fOP/z4XQrKyQQe24MASGuL9bQst6ZDlvWoAz5SIRTf2zMAAzYFIR92qkqpWF
VcLeC6BY66kyjHh93532mfldIDxpvxi4FgrAi/77EwLqgQF0acSOBLAV8a6F
N5BSaD+kYdJxBKkRtPqtHbjHaSbuRjUBABkfGwgtMgLO9/XsMUgo8VLxfQ2x
LsiXIl4M7+PUw4xxC6j35rMYn/vzvXQraoK5XB2JIR1JUvRSBdxwtQlzTKI6
rx2XEnFDCCYk1YaE0WPYT4EkN3y5LF4Hc3NX7xHEu1jv65EuU3vTOsvjSn0H
TeTqAfqo4zddR4d8ax4PAUYh7aDfO+4AsaI2DMoEC2vdhnAh4wZwW1xSK5DR
MYpf1lAnaj4z67+PmjBCL0YxHCijtusiwhmKxxvKgejzBHVzOXwnqgFwWSh7
BgXnqJrRWVvdfaH2jbkkUMUvHKRwSy6SKUXs5lIcYGSS5vdJ/Wm0o32G5ub3
2H4fmv91cJtcAuFFnB7c53MFAQ1krG5O27m1fgXi9AKxkYdSZ9BqeTs12LjX
isZNI68Qs0AIvJyLyoSgwm9tYI7JhC3KEhgHtbPByXwYDByIsJfbswVc6+wW
CYOivdQS9ApjlSu1GFbxUv4IuJs17iniVpS4vQ2QT4QGCU6ENfxsgDkMTrlU
MQb0aSwdGaNWA1YUAvubvVxkHJUGqOOAQt7kDk5c7RJAq01UA7qfq09yMLhG
NDN1NZP29PuldqeteWPVdjJWMlydNJQ0FpVh/UhezJjISBvjOjekNj/h10kP
yWOsH6uHGMaisgQNAeELYQ77Y3XebjIAoqNA2BsEEIFicXXcB99vmOVV1TNI
F3ZBUuaKsjlSAVtNY+0s4pyRgQSyjXEE32iaDglFirYbFHbx/RdLAkuetpg0
fiYGdCRrq+0rhdNQce0oXnBwgG5ginN5h5zmJhIduV+TEyZqI6ohEQ5Wh2Ed
dcQKLk0t3ZKQ3QDOEjX1Vv3FgUBZpjNRI1MJB60dUP6wok6ZHJgT+Yvqw4lR
+ls722h9fF7QDmel0iNqg4zUDFjsxji6OggHl41fUwdVR0ZC6aQGJIp+EiID
c0ZVNrVEESpk/2Itr3aRieVQMxoTUkSXMm/uuY/8zAlFofPhgixEltqB1xBS
hJJ6azqigp5JF62PHmf28qP5deR4xYHyx9SOydJsQy2UygLwxhGokbMl83LD
6peFYfSGBYBRMKM2Vq7aeqEcC4Ids3TV6H6ZTuBwFPgJmJlvQHxisuCC8bbb
9/DaVB0Zrtbukc5ewQJqjjowt7HWE2hEENi9KKqqTRrZ0hVxZUJF7Pc6W0Lr
6Him2nZZh1/iOwGjVXSBkWBGn6QkSwGZpO4/yhY00XYNCffGCiSkDMChgs8A
+yqGHRxSg9/OTk7aBi80BIdGXiL+qHDmiuNbG76ksMhOLR+ufhMaGVQsKsoO
uESzsZpm4+33+23etBPGL92UpcDCBWU3mNzVtUcbbb1AWeaedbwGB77RqEO9
bjjYRaEXF21SVQxmzBKoc9uwDWt4DiIO2QCJgAng/y6gLZndN+UYcBJN5zDI
I+BK4hL3bzgOcsKrWYnuy20NbCXYRrCKtoPgLTweinn7VXVDzBO5qfM8YzgS
GsOoYyZFB6LgBKCIdDdDbWBzQPLwPDf8XNQZTSA3L/SJzZj8UA3esZf7CLOD
bdPB3D8roqr9Udm3pZ0M+MNQj8MbzN4wFxcnvJyaq0wy6+Rjxv9g8KunsifW
FA/BmIz4Q4TzpIOgzV1nNxEtpWG3prQzAyzDeeqEPMLzok1b40YHiY+kx6NX
Qsi15Wcg6aWhg5yI4FGOfCx1wlC1SiM64lyLjpBpgzm8bT7tg8TedCIRmFrv
VCDABIri+JZ6+OqdtBhuQrlrR+dYd4h7yLcEHSTd6GhVPUU6dIIdc32W6JB5
KhBQChiVcNkrUXTW0ntoIBD46+5YF/jBqlPOSAbgAT4qmExybiIQKSivwwUZ
/wSzUCtXA4euhU4VUCaWKTjA4mR1sK8xsL2eqhusynk9owPwogPTQWZ1vGPQ
CcDdIU7eFhg6NYOmKur5o7goq463YDhXx1gM/MIaa8fXIxp0/C9REs9HRX6r
NwThJWEAljiJ7xw0Cp00xG1TPwfFAHLpKQl/dI6YcL8tacPiwHEnJ4zPq8/4
OrxendSGhXHEEMEAmHudF8bQaopKMfgPfTl0Bkgf2TqdnpG+Jplzs863JTFj
WAcI6w6ppJ0SxHyGjHVqGL4qwiF4DZgD2YAGzF0lsOgwon/1oAjIfjC2nRxX
Uzg40jKMoX8sIicHpP5Xwt+9k3VeUT1oAcHgVoePMRSNFGZ6W1GA3/S47L11
GnRfaYqExmG5UtKR8gdlVGsj/4GloazLDAj6YbaxemTdODqkuxMG0M0MFqu2
SIwTtWfqBRAJrwUyzopVrl6HjRpRIEKv8wE2wKWrHgTJAPsEtfNo0/hFAC3A
Dd6esVEb2lssgzlSYHCgR4Uj+6oIXk6vMo5oBiji8XGQxLWqr6oqyaYjZxVR
ON5OiLW+0HpDMafgxI2FSIOSeppGbSkdgQw6NlGhbAxreMeaO9WMpNGZ0QAJ
AcctHnUVECpqEIfLaMT8XQeug69wUQvomoa9cGkfpRy0HgSo2gdeRY3apOkO
omIKNkoI4Djqj4mLQH6IMenmOg+FRHRfm1YXkiTN/nZHC1WDBtisLtLLr0Ta
a/9rCWYBA234LrUukVZd54x76L7qyaG+Gf+R1D0oCqAJB6LKRyVoPxysQanO
gXyJ0seGzZIgSO9MDzGjng0loxNuL46eGh1oOu1yIowBpV58IwA2H4ztuhje
ojhcifs2ryOIhqeaLOEcOquBqx3ECqbhR+BMzWhHKf6zVmaE2rHWUUuSCWDG
HWXtCZMDSU0BHX+N8EBWGwpNzdB6DFldWk2qFykdMgs80UEFPV4RElS6VnAL
o1d03EQa0MAc9YmpRcJraHxyBeGIEGZygQVbr5BAjl+XwWkd3mkcTd7rMFrL
VZ6yaN80KuSAdWuJggb+NCOdVLMpYmJASKikkqZEdDbD5DtAiKhUnV+7EcA1
LItsaBfd7N/h9AZxdHinvTsl9RPPtNvMReU+agY/jhQbRB8h7SW1PseQgYC/
QcYI4arJJ6+UcZADR5CRdlHaDv9AxWR1RcVi0XMPUl590KTm45MAY/WlE8Y1
Te0Jo5W0CbVsoF7xjy0Z1oWrl/IFaTDeB9ISiPRGQ3VM1vo+VMQ6Bgz3BelR
cU5OJQ17khIVgoZBXQ1j/vgp4jJMx60PAg0FopFXHSSHvX/BUfcTkJazovrr
ADeVeXwt1BdXguOTpChFKoG+u55+MnRgkmMrrIK5ObAAynVZaBKRUbfzJrKO
L0qRv8znzWYPqQ+qAk5d2u7FVq2rJ1h0ejXorNzU0SOdxUchfNr2k4T34zW3
oZyQ/3U379/9dDdEiNSIHnlBA189VVR1RgM8itPrgRLteQ30DTaEbNE5Edwe
0TAdTAe+HrqC76yfd6QsBMfoyHc+CBSqs7LUISAD9pT3bu1PuLAAhKLTVwlU
Oq69XUDyyriYWlIr6qDYVOcB8CezqqaFatDO7tQzEg2hijCLIyxLrFXW6VY1
NKtcjI7HnWY68IPa1uPDUYVXtUcjh4cy0qnTI+Ir/etRC1Dp+0Cn037hMZ3H
BWh6fudXoQ2DjZAgEABGtqFetSGQZPt1bkb9IeEaK7tX0IFFlL8ekEG/qpmv
apOOkAJfcELSqalS9QSOdm6pTuqaCUfspajcK+6EHVGfdR7yneE22SB8xL8y
qGJeH5PgpNsnhYoO0vDm9jmAMtunb4Oiso8XyThe7S/r5HlSH2ZVrPJRSwQx
KfV+f7qX7pTePljXoYwE1zqv1rYe22lBp+fOmDGKei7CVU/qaIOx+dfVwG1o
r1znqV+3cSMATMdaqEamtq72unb13evgWJL1U/97+Pf4VxVibz0uhmYkJUER
zAq6O8hg6/kHaGLrFKueWwHM/e46fagng8DrY6anGfaV4FDL8zA+dC6qwN+q
xpT8MchedXwKh39c0JNoF87ziMrxtcJ/WV/yoSFu4LQGsthmHjAy6by1PYfW
06FrH7MjrlsgtbxBuLpQ1YXa94Xi8xAe5sWLBsKuh7tC8Tr7dpCNkJ2O/Ban
58Z+D3R+GdF+itJVH4zqgEYoJ27WdTRCJ4sA5ekgXC9/iO3QU9wqzS6JjKFH
FCDRCxoFhAgvcXw0dZd0EpbYlxqwhjrjMrHrkyqbpdg7mzY1h+/xa1PqGNZF
zxOyKKbVxfLrUbKLdiHZHy7BVEkPntSHuwnB8g0QQ8ckGqrkarfyqeyLtAJN
sMNaXD2F0CAK7VagxKEj70LQI5RepwcwzGLtGrInq/bRc80jk/aoBPQs5I7O
CP6CmTfFrtPwwDmSTeN0fx7oH8fZPuP8HA75daSSfnok1mIEzScJl7yIcckV
Yt/6x6v9SIsf+RXV+s/Wi/inJu+yTvvoZKwOMGRI8Wh3HJcHStX/cYFr1Olt
nVsPlLjTg+AYvPQNEXt9rfBn1GGzolx+NsGDrqPNdj1yMdfrISRIXgF3wi0d
dQnv2EGbOYK0oANiE7/3+R8ElKwjOkYt6fzJ1rFFCAiunF0n8UH105x6u/2d
s6CueC8aZWLowSdqyy/R6aDGk/oeOvgdYNzp/5L48QOFTl2ydzud290hYIn1
UDbqdH5qoiblpU72j6ND5qHgS1Fs1D1LGEkhYgOLpLXD3GCQThoWSBHmRymq
laltPcjToi549PRbVAcpyhz0jiGfgUigglie5CKUixIbb1cQw6fI7qXnPYcU
NCUStU/lwxZSEr4aV44WMWnLrg5FA8iIdxfWMp20g5HnV3+PNfru7wVpGSbX
1HUrUpZVR9JT1qF9eHRR2k197eFsjIYi9NrllvhHNlxtwUG5V8dZcfWsfHzN
voSEfE8x1iZnhvOyZ9DWTlf7/QxnUjMIh4iIZL5JZ1dJEGgCOga3buO1Tm1V
PYnbSSevTTu15hIXJufV0QLS9ThxgVWv/tcEEF97nRLtRkxZS/8auuTMfhpC
F23Ub1ZTOWtnlDjqqOd7qIvKQ4aOT6niuD+F8Kb5Cpzw4z4/Wxlo3vg6pNpy
YbV0cMnFsHgbUqYundrX8TcdhD9BnZC3Al/X/1z9c23/dfWmq+M8qCLtZcNw
aBltgOgJwaRBH1YTL+vzeyQiqxdWt9ScpZOzMr8h8VLX/75BveU+HHX1lqEh
CFG4lpCG2p0ZMLE0vp7mJXVhx04IR2N9vY6XHD07YnpuRKSxigNXq8zX2xH+
vmrQFnkXk34vw4hSNDuCpkl2IOg5Gj1lgfE8A3PiekNB6Fk+VgJHTnVsMbSa
Fd+XlXq1PpYdibF1SalsH/qa5VOy+SLYS9HxFfWlNtUBs+p8BUyCDvRBZk9t
MSipvP8XRg7azQhJj1kyzLNg213PdTCeTlJTE72mlMZ77GzrkRXBjXb71ipd
55a2Glx6diuj9H1epWHCxJuqvUr4jzr1yKKES1xYftMeI4HzehSydmEette/
p41SVtWwGClRy9pe1lnzBMAyIrTJ0mGLIypX6Lok8ce4EDxdtr3LAgXaTBp6
4Kd1oq4d/2PKkFrRR11PAp7wykec4aGTqFVO611svYfQ9NTppzxIO6FMHDJk
/bwD8Se497gOfF3L0YYBWBBkipUwOuZetBuvDa5P1akzrII4uF21OLWptgZO
6TidysQmyAlcM+0X6lQQmhEIkGBtepZ963jC1tEZkinO9lkJPTvyulkarvtY
AkYshwUpH4nHV0B6qF3PFyQ9w9yE0jonpHOJeuzWH6G8nod4hd0cNbY//SPU
ivS52PKsqh/DhTZQhbdKLSMr9RzK0D4j2ZIMnNl6eNSTqdXpiT+CgEfpLHuT
avpEuuAFlKY6Y+kTSLBAfjSf9uY/R7DexlQNldie5ChkcdeM7+i72nY23H8D
uWZ05wi91FUAAAGEaUNDUElDQyBwcm9maWxlAAB4nH2RPUjDQBzFX1O1IhUH
C4o4ZKhOFqSKOGoVilAh1AqtOphc+iE0aUhSXBwF14KDH4tVBxdnXR1cBUHw
A8TRyUnRRUr8X1JoEePBcT/e3XvcvQOEeplpVsc4oOm2mU4mxGxuRQy9ogsD
iCCEuMwsY1aSUvAdX/cI8PUuxrP8z/05etW8xYCASDzDDNMmXiee2rQNzvvE
EVaSVeJz4jGTLkj8yHXF4zfORZcFnhkxM+k54gixWGxjpY1ZydSIJ4mjqqZT
vpD1WOW8xVkrV1nznvyF4by+vMR1msNIYgGLkCBCQRUbKMNGjFadFAtp2k/4
+Idcv0QuhVwbYOSYRwUaZNcP/ge/u7UKE3EvKZwAOl8c52MECO0CjZrjfB87
TuMECD4DV3rLX6kD05+k11pa9Ajo2wYurluasgdc7gCDT4Zsyq4UpCkUCsD7
GX1TDui/BXpWvd6a+zh9ADLUVeoGODgERouUvebz7u723v490+zvB3gHcqkl
oKXxAAAN/WlUWHRYTUw6Y29tLmFkb2JlLnhtcAAAAAAAPD94cGFja2V0IGJl
Z2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQiPz4KPHg6
eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0iWE1Q
IENvcmUgNC40LjAtRXhpdjIiPgogPHJkZjpSREYgeG1sbnM6cmRmPSJodHRw
Oi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4KICA8
cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAgeG1sbnM6eG1wTU09
Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9tbS8iCiAgICB4bWxuczpz
dEV2dD0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291
cmNlRXZlbnQjIgogICAgeG1sbnM6ZGM9Imh0dHA6Ly9wdXJsLm9yZy9kYy9l
bGVtZW50cy8xLjEvIgogICAgeG1sbnM6R0lNUD0iaHR0cDovL3d3dy5naW1w
Lm9yZy94bXAvIgogICAgeG1sbnM6dGlmZj0iaHR0cDovL25zLmFkb2JlLmNv
bS90aWZmLzEuMC8iCiAgICB4bWxuczp4bXA9Imh0dHA6Ly9ucy5hZG9iZS5j
b20veGFwLzEuMC8iCiAgIHhtcE1NOkRvY3VtZW50SUQ9ImdpbXA6ZG9jaWQ6
Z2ltcDo5NmE3ZjI0MS1lMjNjLTRiMWEtOTdjZS1kNmU2NjliOTk4ZTIiCiAg
IHhtcE1NOkluc3RhbmNlSUQ9InhtcC5paWQ6MGNlZmJjNjYtNjFiMy00ZDZk
LWExYzgtMTg5M2QwNWFjOTg5IgogICB4bXBNTTpPcmlnaW5hbERvY3VtZW50
SUQ9InhtcC5kaWQ6NDIyZDdlNTItOGE2Ny00NmExLWI5MjYtNTJiOGEzMGIx
OGIwIgogICBkYzpGb3JtYXQ9ImltYWdlL3BuZyIKICAgR0lNUDpBUEk9IjIu
MCIKICAgR0lNUDpQbGF0Zm9ybT0iTGludXgiCiAgIEdJTVA6VGltZVN0YW1w
PSIxNjU2MDE0ODk0NDU0Mjg5IgogICBHSU1QOlZlcnNpb249IjIuMTAuMzAi
CiAgIHRpZmY6T3JpZW50YXRpb249IjEiCiAgIHhtcDpDcmVhdG9yVG9vbD0i
R0lNUCAyLjEwIj4KICAgPHhtcE1NOkhpc3Rvcnk+CiAgICA8cmRmOlNlcT4K
ICAgICA8cmRmOmxpCiAgICAgIHN0RXZ0OmFjdGlvbj0ic2F2ZWQiCiAgICAg
IHN0RXZ0OmNoYW5nZWQ9Ii8iCiAgICAgIHN0RXZ0Omluc3RhbmNlSUQ9Inht
cC5paWQ6YTY0MGI4MmMtMDg0My00MjYwLTk3NmMtYTg1ZjA3MDc5ZjcwIgog
ICAgICBzdEV2dDpzb2Z0d2FyZUFnZW50PSJHaW1wIDIuMTAgKExpbnV4KSIK
ICAgICAgc3RFdnQ6d2hlbj0iMjAyMi0wNC0yOVQxMzoyMzo1NCswMjowMCIv
PgogICAgIDxyZGY6bGkKICAgICAgc3RFdnQ6YWN0aW9uPSJzYXZlZCIKICAg
ICAgc3RFdnQ6Y2hhbmdlZD0iLyIKICAgICAgc3RFdnQ6aW5zdGFuY2VJRD0i
eG1wLmlpZDozYTUyMDNkNS04NGRiLTQzNDMtOWZhYy03NjFmZDZmZmFhYjgi
CiAgICAgIHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkdpbXAgMi4xMCAoTGludXgp
IgogICAgICBzdEV2dDp3aGVuPSIyMDIyLTA2LTIzVDIyOjA4OjE0KzAyOjAw
Ii8+CiAgICA8L3JkZjpTZXE+CiAgIDwveG1wTU06SGlzdG9yeT4KICA8L3Jk
ZjpEZXNjcmlwdGlvbj4KIDwvcmRmOlJERj4KPC94OnhtcG1ldGE+CiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg
ICAgICAgICAgICAgICAgICAKPD94cGFja2V0IGVuZD0idyI/PlmiVpAAAAAG
YktHRADwAKIAftw2PhcAAAAJcEhZcwAALiMAAC4jAXilP3YAAAAHdElNRQfm
BhcUCA56CWQaAAAgAElEQVR42ux9Z5gkV3X2e+6tqk4Td3d2epN2tUlhJRSQ
QEKABpFE/ggm2SAMxmBbtjA2/uwPJ2wwGNs8BBuDbTAyOdnYGIEtECMhhISQ
YIXianOc2Z3diR2r7j3fj3sqdO/M7Ehik9TneXq3p7u6uvrWe8894T3nEjry
mOWnT79UFdaUledrUoFPBADWAgzYRoio3rTR2CQfuW/UPuPgdu6M2GMX6gzB
I5MvAuqiN7+8N9/f1Uta94C5xzbCZQCWE/MSUqoLzAFZVrAccWRqNoomOTIj
1vIBT6uDNjTTptqYmtkxOnHR5ntqnVHtAPe4yAcA9aprX3O231N6ktJ6E0Ab
CLyWmc8gYFApBTADlsHWAswgZsAwYC3YMmAsODKwYVSHtXs4srvYmK22GT1g
a817p3cdvOein9871hntDnAfs4x95DeWB+XBl0S18MW1feMbibEUhD4AgAXA
DGYGCVhhOXkNNn7YBMDuISCOH5FpIjKH2JgDpt78cWOy+vWoEd1y/o/ujDp3
oAPcBcn0z79O/uKlJZ6aXG12bX0bwuYvAeiv7DgYmJkagWXAmMEWABxQs6CN
wcqMFKjt/xsHYjY2AbH73xgY2zC18CFTb36Cm9G3olrz0Dk/vqvZuTsd4M4q
tT3f61G54tNA9FoeP/wqs3NLCcagfmgS9f3jIM4CFSBmB073T6phGQDbDHjb
tW1sPlhQon3NUSBGZGEb4RbbjK63jehbY7f85L7LEHa0cAe4Tr4P0OUjt7xA
5XK/CqWv4kp1UfTQPUCjhqjWRGXHKLhpkNW2DsDynMkBVQCdALXNdKDY/s2Y
DWwtyLADa6yBI3kexQA2sI3oAW5G/9mcqn7irLt+uqsD2ycwcOt7vqOY9BqV
L/wx+cGLoPQAIkPhQ/eCx8cAZtT2HUHzyLSAVAZMNC/Hmje2d5E1F6zYuQCx
PE+ctVbTIQYtotgeNmDDgDUpkCMLhKZpm9HOqFr/a2v4c9GRmfDcrQ89YUNr
+gkJ2t3f7qEg9xKVy3+afP/ZINUFIjIj+2EO7AGshak00Dg04bReLC3gjac9
y1NuUwecqoW246ntfOCMCiH3lI5WK5qIFmtPX03Aucr3HvytpUsP//3IKHeA
+0QA7Y5vbaRC/t0IgveS5y0FiKAItlJFtO0hoFEDW0ZjbApmun70CZgyiJsN
gTHwSMwKyiA9A0aOj6UW0B6FYzpqUfSUUptI0ZUKmH7TpHrgk80p0zEVHqdS
ve/LSnV1PY3y+Q/C858KpRVIAUoDDITbt8Ls3ApSCrYRorL9oFu6E13q7AVi
yuCWW7VwxmEjMR1iBy0xGVqiD3GEIXXYkHHYkvdixy1yNm9sPnAzGjfN8PP1
w5U/O3fLA0c6wD3JwibSbK0GW5+NLbCNjA2bDQ6bhqPQchRZNpEtrjlrQctk
9YEv+6pQeBHlCx8nzyuz0gTScMBVsJUaGrffArIWpBTqByfRHJvODBCJkkyX
f7KZEUwiDXL9MTiRcdjaw2aZBEUK3NjObQ2XJeCNDDhiUGQcsCMLNE1omtE3
o0b4e8pXu9bdcfcTwnTwTrULMmFjEVuzni0vh4lK1kTEJiKOIsCaBlszzdZM
sAkPTz949xSHYQXM1Z4nXTbrclm99/NFlcu9SeVzH4BW3dmVGaI8w507wI0m
oBWstQgnKslSziCQ876S5Z8TwLZaDUycrPMxnlODFanZEL+usrpDOa1MBCiV
2gwxyBWBtQLYgKHSL2b4CniF76mSZf59APd2NO4Jlqg6vQTAZTCmLwYsoojY
RMaayMJEPhujOQVzncNwkk1z3IbRITbRyOJnvHAyNQ8+X9CFwrWUy70bnt8L
JaYBacTPbb2J6i03A40aSGuYWhO1fUdafKv5BooZIMqALLZtmVvBl9W0nIn5
xq+bWTSvbYvtGuPeiyMNJmM6GAbl9O3N6fp163545487wD1B0jh4gMjXl7C1
Z7GJFKLIMts9BGxja2esiRgmUjYMCxw2+zkKl9owLLOJijARWRMZNlEdUTRm
w+jhXF80mh/w30aF4l+S9rqgtQNt/CD3f3PvftTvuhPEBqQ1wqkqmmMzqe16
1GAd7Zy1BA1sm/0bZ9CQPncWRzZpkUkNcxa8DDbGxXqtgDR+L5S/TQpgHXgM
ojubk9W3nXnrnT/rmAonxK5tehzaIluj2Rpma7eTUncWVp8Vth06PrX5tgNs
7QMwkeJmY4BNuMZG0UpEUcma6EzYaD1pfR4F/luIkBPPqQ1qTqWaI0fAjRBQ
nNqnQkkEEZjIEWbiMxBnIJzGcuNvOEr7QlQy24y1EM+KTMRBUaqBKY6JMUgp
MDsnEZ4CIoBgwR5l7Q2AGTay5HcFTwl68h/ceeVT3r7m5h9v7wD3OItt1tlG
IWCMYhM12PK+nk2XhLMd23PB0xJdBuAAgAOj//VZn61ZbqNwdXFQvTS3uPBG
Isq1hKJa9KN7bmZmwGEIaAcAHXiIFDkPPrED2j5Oqf3bEpeNTYckOpaJAVNG
UyukSQvKfI2iVr3ODsCkyH0LE6Al2MYK7AGAkRMy2DAsA7rgP5eZ37v1souu
XX/7T490gHscpbj6rGjq53dU2BogipS19hF5x4MvfUMIYFf17n9eqoq5FytP
dR29zvNRhhKDYKMISkLa5Cn4/UUXVbAupcs0Wyx3lvPNYnsxZ4E9WzzXARNW
JgQh0bgOsCxuoYA30bAWBAX24vnrZoM1FirnQxf81+RQOnQj8M7nOnQ/rkSd
UhGFWvWgqVUiU6/6tl7pfcSx2js/PkC++jPy6KzUPIhVIKcevizDYED39jiz
MjJgE4EjA5UPECzpBnn66Ngrs3ATRCPDgpH+zVnGWBwBludHWcYUTx52c4FE
9SqAldPApMhpYqXccy1/a3ccKeVWC3m4cxEo5yld8N941vOe9pbHo8Y9pYDL
YWO/rVWnTK0amGqlPPrNzwcL/ez4v/+5B/BvkadelLC42jJaRyk+ZgTLlwF+
DhxGCXhhDXQxQH55H4LFJaiCB/KUA1qW6WWt8HIFfAkrjJNH1gim9vgZ0tBZ
elnueCKn6V14jEQLKwE2pWBVAGnKAFdWCN+DCrw+rxhct+s5l118/8aN1AHu
cZJFV1wd2Ub9XlurwNSqK2zYGFjoZ/0l3c9Xvn6HI7s4NDHzLIt5JjEAhtff
i/yTNsGGkQNvaMCRAUcRQIygv4TCikXIr+hHfkU/gmX9CAZ64C8qwesrQHcF
8IoBdM6HCjyQryWRHpNonOfPcTQgq30zThqJicCKkjgxqRSryGpgUqlJodwB
DrwO1GzZTTRfQ+W8c3Uh+N2uM5eUOjbu8XTSarVdNmruYWPWsok27f3sRw6u
fMN14Xyfmfzvv1iuct4fgdADy26pzWhVZLQftdu7xCiesxGILGp33gmERixG
9zkLgDwNnfOAonJLM1HCMcjGGBJeQRLGlZBW5GxPjgw4NOBGCNuMYKoNl/iw
6bUloeBsAE4ULospQYpdEoKNHJwlO5D7Lq3Er2RoBK82kfnOtisv+cK6m3/C
HeAeBym//E3R3s999CdsomUcmY0cRTsBbJnr+MOffZf2unJvIOJLnBtunbPC
FiS2KLNuATC1k2ICH8WLNsFbsgi1n26GnZ4Em2YmicCwrKEYYM/ZlaQAaOXA
SgJaUuJXCdJiGyFW8vH5LCdEdI4MTK0JU2nAzFQRzdQltSuJB2KXvYudNY41
NLtMGqwYxNYBWJGjRSoCPC+2PAK/K/eeqBF+F8BoB7jHS+vWa4c5MvewNU+x
xlyx7UPvPrLune+btZDQX1TaCMIbAeQSMncc0FcshYtWNJQAxrLEbV1CF2CQ
VsiduQrByuUIRw8hGhmFnZ4G12tAWAfCJtiGQDNyqWGtQUwg0oCWeC9ZsCzj
1OIJphExzsRsiQHyPZCn4ZXywJIesImBXIep1GBrTZhq08WaORMyY7lyFcfW
4siDcpPVMpSvwYEnsQhenesr/h6AP3g8APeUNdh3fPQ9RRs1n8/GnAFjdrAx
393w7g9VW0yEb/yxTznv3bpU+DOVCwDfB3nuAc8HPA+kPEDLQ2lAe+CWtK9y
z4lApNyQKPc/hyG4EYKbTQhXQlKwkctagUHW2cQEYX+5WDQoioCoCYQNcLPu
PgvKmDApo6w98ZFlidlmCFMPHZCnazCTVXBkMsWYklXLknUiC10K4PcUHYss
ioBmBNsItzanar+0+pu3/qwD3OMoD3/gXQNszP+BMUU25ic2Mnec875/TOqu
xr/yByu9ntLdqpgfoMAD+YGA1nP/ax+kNaB9uJSvgFd5gFIOwEqlXpBSmWVe
ZZIPqjUR0ZIZQyvN0XJS/ZDSFg240QDqVXB1GlyZBlcmgXpVQmwSTrOcOHDc
UuLj+Ak2isDNCNFkBeGRGdh6U0p9suAFYCzIU8gN9gChTZxNbhhj6s0PTNy7
/z2bfn5/2AHucZSH/vTajWzM89gazZG5ka19YNPf/SsDwOTX//B9urv4R5Tz
iQK/ReOS5wlgZ9G6ygMrBVKO2ug0MBBTHSlejikT8CeAWbUl0lqdojTjlbFr
M5oxKWM3wjlo1MEzU+DpCfDMBNCog8M6OGwCRiaAkfhwzMmNARoahNM1B+Bq
A7YRyXnTmrf8qkXuPKERu9nA1sKfR9Xmq1Z99aYtHRv3eCYlKpWtUKqPjbkC
xj7LGtMEsPXwP//mMqXptWBLR3NdnZYisgBZMImjJsTw2CYErLMZrQWRcl67
smCbAShJViqpfKC20FqWdBOHstLXKE4oAGAoB17tJgrl84CfA/UtdsCqVYDq
DOzMJLgyBcxMgK2rTI/TvkkGzdPwe4vwSjmYSgPRVBXRZBW21kiiDCyZwGxZ
kcrx+RSZK3a87BnbzvzPH5y2GbVTvnTnH370M/7NS590iKOwyCZayZFZ/mtn
rR9dvGnJy1TOfwV52leeLPOkkqWf4r/lQXFgNKMhCRLgByVJqzRcRq00B8qE
uxJiubx+lPZFi2kRg7m9Lo3bExGeD8oXobp6QaV+UM8iUL4AGGcvE7ddV3zN
noZXyMEr5qACDxxGYGuhSzmoQCe8oCTRYblP+frLH7pnW9gB7nGUj9+x2fzG
xecesM1oKYxZpjXO6FrV/Xqd99c7G1biq0olYak4ch+HqwAl2ah2AGa8/hha
TKm2nM26mqWSkaid7hh/dyuYqf08NJsmJ5DWYD8AFbug+5aAuvqE+hhJ6CtT
jZEkLBR0zoPXlQdpBXgaKtCZ0qPkWlc2p6r/+eH7dx7oAPc4yz/+5L7oN87f
uIejqKzz6ik67w353UFR5XxQFrixxo0B2wJeJGGjJKqfZNFUGxYpA+A58EuU
wSQfrXUFnDQLIz3W+URHfwFTWyElKVCQg+pdBOruA5QHshZswgT0JMmU2KzQ
+QC6qwjl+RLL5qzWJQDVD/1s6/90gHsC5BObH2q+/bz1I7m+4GkEfpYJDfnd
OajAl4ySSp0rSvP7FCcDkvwpzfL/LG5rsiRTK7E8k5WjozTzLDbwUeDN2MDy
eUosZEoATekMSTW254FK3VClXqhc0dn1Yf1oCgQBKshBFQsg7WK5HEWp4if0
vW5L/dP/1JiMOsA9AfIXb7lC5RcVXmItPzmsNhHVQ/jdeSjfazUXlErDWImN
mzUP6JEHVtiRZx3uCG053xatfrSKbbOFidqOEB1MbYVqbXZ3ch6tnT1c6gEK
3UDYAKIo07OBQYEPFQRuRfI8kOc57oS1IEU6WNXzgw/fs/207IzjnXYXnNNd
5HuXeqUcZkam0RyvYGr7QfSsL8Pv1s4OJAkjkcRBYR14LYNhj4Zqu8mb7dih
tDtPrAI5Trva1AyJqxYSnZkloGcKexTJNcQvKYl6xH4jAVaBlAWzAhQjtYA5
5T+wc7gckTwPpT1QsRt2/BB4bASoVR2NR2vAc+X35DOU2M5mega2Wiv6/T1P
N8w/auzewsrzTX7FWu4A9zgJG7uYPD7Xy2t0repFZf8UGocmMcWM7vXL4fd7
SdM5F+aKg/tGaCyUhMISZRnnYpXYiUoSCETp/6QkR6tS+1ecvZTdZVu1aYsT
lzEbIARxJba1UCIpS9Zjm8SQKWPJZvluBBbwimmwuAyUemCOHALGD4GUA2pM
u4yvxOvuhvG8HFTXUOWhzbfrXK5mrZ2sHdg1rTx/mrQ3HSxaajrA/QXJyJ++
kmy1cb7KeQEsw8/76DqjHzN7J9A4NAUbWXSftRK5xb2upFy0LZEFWwLYIOvX
J0kCBZCSrBepjEWhWioSQKJR4wSFOhrAiPmwMZOrxXrgpM6MbOoTAgAsuetw
vLS2OHEavyXWLcVChEjAy04L5wvQS5eDu3qByjQQ1Y6uygBDI09EXtkcPniW
GlxWBxETUZ1J1UipSnPy8GGl/f1Q6pBX7LId4D6WZMRMhWDNxV5vIUmRenkf
3WuWYGr7ITSPTGPyvl3oPXcNckt6QUYIKCZmTikwmTT5QNwKYEmUOWXHDszK
1X7F3j8RA5bSpEQM7qTVAWcAzWn4jdEaKFZZ8Aq0bEpddCnoWfxFHWvgNJjr
XvdSzjoDVCwBQQnUqMPOjIG4hpTX7swOCuu56P6fPOQtecFegAYYWAqgZIEu
ApYyaKNSQcU0ajtIeztJ6xqRsh3gPkKhyBDXG5tsvQnKec4UsAwv56F34zJM
bT2IxuFpTPxsG3rOX4vC4CLJiMXsKSN+i3GVtko7jaycxkvWZPk74RwoSstq
SIl2zfQHI5VoXmTrx5iOtpvjyshY8yYJihjAbrJRsrirWYMdaVxCZ173Ms9Z
EjAeSPvgyjioNikmkgb5AFvbT4e2e91nXbQFwJbK9vsVrOmDCcsglC3QA3Av
cXARSJ1FpLYx824AE0TEHeAuUKofvRHF33nuRlttQHcX0nZFiqE9B97pXR6q
e49g4qdbYM45E12ry0k4LE6Zoi3k77DHwlXgFFxKA2SkYLLdUROerEo5sQzl
eoslwITUoVHatSaxh9MHIcMFV7H1qqSDjqSiMwBuddg4S6dw3GMwCB7IKHFG
A6BrMeDlgMo4UJ8Rh832kfUWxectrT3XAjgC4Eh9ZPeDMKafQWUAZwC82ILP
I/JXEaktzLydiE5aKE2d6mCtj+wmU68pZu454/ChjWxoma00HLWPWUpiXIBd
eRo9Z5ZRWj0A2wgxde82TG7ZA9NoCgHFpMebTG9aeR3WZB629WEMEEUJQSb5
XKY0B2zSjjNx07qWjuUp26u9lCcFc1pjxkpJuY6W+jJKqJiucFI75yumZyr5
W7KJ8IQdJ6Ew5EugnqWgYj/geyBf++Tp/u/NEhPMl8+wuaUrDoP5frb2BxyF
P+dmI+Sw2cvWXAjgHGb2Ohq3TQ7f8i3f6+3LcxQus1FztQqC/nD8cDcA31Zq
sPUmKPBBSgBnlHOstEbP2mWA1qjsHMX0vdthGyF6zl4Dr5AXe9ZzlQJJVEol
/RJIcRKidT27MrRHZIokk9dj8nhWEzvSOif9QFKOr1DGEo3M1JYuTmzgWJGn
kQ1SGnEfBafHZdlvSWcwCNqNhfFSsyK2bQFQrH2nx4BGtGj1W1/o4Z9vmJW3
ECwpM4CZcGLsHhuFoQI/Ccw+PP9cUmoMrq9FB7h7PvN3XbqrZ9A2aitto7Ay
mpnMgygkoolo/15CFDEzw0xWoUt5p1mMY3WRNQ4QWqPnzGXQ+RymH96HmQd2
IqrU0XveOgS9Pc7WZRcPTcrPFYOUdpW6BJAWABpOQ2TZzBuzA6tSmWVfpd1p
SDmQsZgolh0IkwqJ1AZmUm3ZOk4dPpuaGe7w2AZWAkorZkWbzeuyFK02MWXj
wl0AaSiV6+49R2kA8xJu/L4l3Dw8+qC19gyydoli9qG9VTZsjio/sE9Y4G75
y+uKKpc/N6rW1kB7i0l7PkAVADtJe7t1d+/YzA1fOIejkEEa5vAU7KJuKK0d
aA07+qJQGYkIpWWLofM5TN63A7U9I4iqdfRdsBGFgcWAjp0rKdmKPW4BYtJu
KY7f8izghQLX6+BmE5TLg/J5cdxUxplL7WsYAbXKkH2Yjo7/zpZhE83rSnWk
T69SaTwXypUlJXRKlZCGkigC0kY87u8CYFA0hYVlUIPFg7Y+sntGWX/AMoM8
308Zd08g4N71yueRLuY93du1KZqaebIu2S4QMYFnCPgZaW+LLhQrpjIdBj2L
edfbn+trYwmKwI0Q0dgk/HzgMk1khP1lQWQcMJRCYVEP9JPPxpHNWxEensDh
2+5B30Vno7RyEPDS+C10ppkHuYJKluLHuEmH075WogiM6MgRmIlxhwat4JWX
Q/f1Sz1bHCZTqQdGkoY2nPYlUxkvjV34LO3B0BZPSIIMEus1ovFZzAatUnOA
/JaohQO1zoBYIO55HuuFZf4rW+/N22ZjKVtLyu3vNkpK8xMKuHe8aEhxZFay
MU+31foqMAwIh0F0P4Cfr/nNP6ke9aHIGBibcGjDg5PQfV1Aj4YiI0ATEDMl
jeGCUh5LLjkbE/fvQn3/IRz50WZE561H9/rV0PmcgNJhkiV+y1IUxsSiGeNq
WwJHDYSjo7DTk5msmkK0fx9UoQgKgrRwkjNxWbKpJo4N3JYoBGUa6FFbq9NM
nzIid26F1N5uy7ARuwhJkiaG16px43N52ir/2DCY3HxbzkbhJYrQBWay4P1k
ov358hlPHODePnSZ5mrjEpP3LwNRD1ueAeFuAPec+8FPjc8Zx52oTHOOmIzk
90Mg3D+OIJ+DVQpkLEAuO8baOltWu2Xa830sOm8tprqLmHloN6bueRjhZBW9
m9Yh6OlKa9BYpYWMkgJ2HRstQBqm0UQ4sh92ZsaxupQSLe+0oJ2cgF4y4Mrg
W2K/3NqNJsmypbxdjsNlSrWnupJgbxrG4zQC0RYqAynAatczV6d8iTRtnIJc
53I1v6s0r406fsf3ejiKLmRqrLVsFTGPKvDdhdVnVZ8wUYVbNp1P0Uz9WSrn
XUqEAMxjIHybiHZf8Kl/nzcuSFqFkF4DiBzXwEzMIDo0Bb/cLzHPuDRHHDUY
uUOA0ho9Zy6HXypgYvPDqO3ch2hyGr0XnIVieUmijuLtnYhbkw62XkNz3z7Y
atWV0iglpB6VEHpsZQZ60aKjQJlUWyT9wVRiw7JQL51il++nTOOR2Gywadw5
3RSFUs5DvKsPeTKRbBpliM0FnfkbDPJ0FRqzAvfQ/35Vkx9ssGFzkwL3Wdfg
abtS6q7i+vOnnlgJCLYXcZMutYhyxDwBa79JRHsu+Y/vHnPJMX1do/rIhE28
64jBHCHcNwZVykP36gSsTrM4jetuvnFaUGkUBxfBu/xJGN/8MMIjUzh822aE
561H95krHbdXmoiwZUdUIYat1dDYsxdcr2dirKKNlYDRWlfNa0wCPBaqolva
M8mNtgyaOy4u1HTZvcQkQIZUzi29+49uGKk0iL2M2REbHpyGzrImSRhNHL73
wURh7PviPyjy/EAFuaUcRReBaEDmzIxi3AOih7ufdPlJL/k5ocAdPnNjF4f2
AlguANrA8j0M7HnK8B0LspOoUpuC5SqMKba0V66FaO4YQbB+JXR3UZwXkwEs
UuaxmAFBdwGLLz4bkw/vQW33CCbufgDhVBW9Z62B310UXDGYCaYyjXDvPtha
VSqD40SAaOM4ARD3YoiipFVTmiLmNns21pay1EtLUbKZqg1QUrnAnNbJtdQx
cFsimAiSz209JGMmIILQHS0oFxze8Kf/YHZ/6oMead3PJhokpddzFC2XfOA4
gD0A7ut/+gsmTpUo1InVuIZ7mE0vrCIwmhzZQ0+/e/OCjXuaqVkGdhBjietF
ALDnNv2wk1U0tx9AsHY5dHdJbpLcPM7cPEq3dPLyAfrOWYOgtwuT9+9A5aHt
CCen0XvOWhTKSwBiRGMTiA4cADcbzg6OTYOEtG7FPnbFmSzZtaTal9itDnEo
DUga1aUZCE4IO6wy5TxCoYwrLDiJCLTt5scZaJKX2LwsHc2zh1A8gyOANU+b
ah07Pvae820YrlTAEhD1WgqhgEMgPMxEexpTM2OrXvvrpxRX94QClw1HZGHY
9ZLNwdCiR3YCZgAPwfClSHxsm9h4dmIGzW37E/DGFbGsKWmRy4pb9iRTWqFr
1VJ43UVM/HwrmiNjODI1g9KG1SiUcrCHD8vSLyaBirNaUspOSl6XaIcx7hED
VykJswmIFSXhsKOcNQGw40BQ6nMlnF+VDAOhrchSCA+kc+67rDOLkkN00sAM
1kaIqlWEU9Nh9cDoJjZRFwiaQREYuwG6j5U+gCiqD77iLaccpfHEa1zGEWbe
SeABZtLQ6sKb1569B0Q7rtz2wLFnNBNg7T2OdB0bacq11xQNbMen0XxoN4K1
K6D6ul2TEKSUAdKZ1rmWJdevke/rweJLzsXkfdtR33sQ48N3odKVQ/eKRfAK
OZehk33QXBIh5g64PgxxNIAj2Vw6abEYmwQqWfIpm2WLaZCU6ZZDShJznKmf
UxmHk9JO57GpwORqy5SW3mgaMBGsNa59aqOOaHoG0cw0bK3mtHdopqNqbYKN
GQeww4IeVkqNn3HN756SYD1pwH3W/q3R95etu5UtdRPzuYBdykq9jBTfdvP6
s++/cuuD0/N93uYDpnrzTmoaZw9qm4Z5JIwFTbDTNTTu3wlvxQD0kj5nOgSU
tP+MebbQygFJAyALbS26l/SARw+hVm+iPlWDma6juGoRCv1daYdyss4WTXqP
2dSMEIJO0kshBmQmRew0asbGNZlSdZJMWmJFxHTJjA17VK2RVPAqH6bRhKnX
YWo12FoFplqFqVRgmw0Qu4mqcwWofA4Atk/v3Ptl02ju3vjuD51WRZMnpQXT
95et6wFwKRRdTory0NQkrQ5Aq/tJ0z3PfOC+OQG8+wUXroGxPwZhAFq5BsaZ
Dt0JoUU7WqIq5qC6S9CLeqB6SlCFAijnWjOBXeWrrTZgp2Zgq1Vwo+k27as2
MbN/EmG1AeVr5Ad60LW8HzoXuMWBFjYAACAASURBVEgFpWwtQuqs6cUDCDZu
yPR3oJYGzNmWpMjasi2vZ96LqZMJ+SYO+QE2jGCqNZhKFabWAIcM2wydgxiG
ieZXngevuwdeVze8gtSoKQrZmo/lNz3393AayknrHfb9Zes0QMtBeCYpWgOP
fNKKyVMNeGoHaXU/ebSbfN0gX0Xkeeby4dt599UXLoYxnwXzCxzVT2VayTuw
ZvdNgFauylUKB0kraYCXlrFztl2SjhvguQbJ0yNTaIxX3X4RpQA9Zw4g6CpA
aS39aSk5DykFPbAUwYb1rYBUWQBniDbZluM0W6k8JfYxRxGiag1RtYpopoJo
esZ1kYwpFX4Oygsc1VFp6FIXgr5+B9hiwX2XS9O6lcHYKRs235rf9OyvdID7
aEG8Yv0qUnQ+NK0irfrJUyV4isjXNeWrA+TrfeTrEQq8qXxem77m9LXUDN/l
Uv8OmKwFQPHeCEQOpKJ9Y1AmGlll3lMZjSjAJa0S6mF1oobqwWmYegTyFEor
+lEc6IHO+SkoBZB66VLkNm5odb5UpkGJoqTJM0tTvJSfa2EjA9towDQaMLWG
06bVKrjZTDQ3KQXyPei8W/J1Vw+83n54XT3wu7rhlbqgfD9pPcpxv2B2HGTX
TMTuCyvTl5cuuHpPB7iPNc57xsZuaCqTokHy1HJ4qky+WqwCrSnQlgK/pgJv
qqjt2XkTvlUp5EiRUGMpaTCXhJPYiK8Ta2OVaGPKAjUBcgbEif1KIAWEDYPq
oRnUj1QArRD0FVEq9yHfV0z6OTAAtXgJ/HVrXWdEk5LWbRRJO/1I3pPWn6GB
DSPYZhMcNh1BPjMRSBFUEEB3d8Pr6oIuFaG7itCFAnQuD10swF+0FCqXd90k
kwaASJoAMrfv0G4BE30rWPf0F+M0lVOKjzu0e8s0gOmb1529FZbzsJyD5SJH
djmDliuOBi3z4kbOa2hShxRhpdIeyHcNL5QfPzTI90Gedg9p0USedtmpRLPS
0VNYgArpnRtHHXylUFgH1KbrmNz8AJpHKogqDVSKubRNLgOq+zD03jHJvkma
ldM0MmSXSHdeSlYAUgoUBPAX9cLr6YLuKsHv6oJXKkDl8/I7PChPqhxiTV7s
AgW5tEslZ6riJWyX7V/ivo/YRvgiTmM5JSsgrtz2IAOoyWPiBxddcICY7wYz
gaGbTP19pjlAxv4ye55m4wG+LLWc8lFVzJpSGgh8IPBBfgDlyw45nvTLFQ2X
dHSMCxez8VN57i8l5JcuwfjmB1DfvR/N8UrGPiZopUHVmpgqGqw1yNdQMglU
PgddLMArFqCLBac5i3nnNOVybS2ksi2lkFybc7oAeD5UroCE6xXveJlllVG6
fatLO1uwwQFrzXc6wD3O8oyfbs5uEGYAjO55yaWf5cPVl4LRFwOPfQ34ngOp
74F9B1Yb+KDAAwUBOPBhfR8UOACTp8WRa3XYjuqpgLR5niagf8MqTHOI6t5R
mHrkqt89heKKJShu2gAVBK4tlO9DBb5bCYKg1d4las2mxRuryH4kJCQZNrFp
Y1OWmKegC6WY/wG0tFHN0BaTymVytq17+4sqCKY7wD0Zxvmqvlt4qnYP18Nn
xuVg1Ixca/lGmEQZWMjcnN2hUWvA11JsmLFvdVqU2AoupFqZKFl2CznAW9mP
6lgFjYkabNOgcWQahcggN9CVmANJijjuRB6H0qAc9VGlapLjY1m1lANxhpRD
WkEVSm67AGtTk4dtS+untFNPTNIgEHicib9hGrXTupW+Pl0v/EN3bjfvuGDN
jD1SfSURWnrcU0t3xex+uEiNUes2HoGxbiMS49rNI4qAMBInKkpTuFLpy9ak
LfEBaE3Ideeh8x6iaghTa6IxOY2w3oDfU3ImQmLfZri0nCmOjCmU8ZoS794e
X2uyH7B7UeWL0F09LaZAAk7O7AecCarFf7O1/83G/Gth3TNrHeCeJHn7isFd
0Ux4lTnSWJX2MUhvcKJogKSbdwKGJGXMKcvMWnBoYBoGptqEqYsGR6YSlzOf
SzrDEPy8j6A37wiESiGcmELtwBgoF0DnA+d8MbcCMbPrTgIym6F5Z/cEjr8r
l4fX15+QZ+bKrbc4nXG9mbVTUa3x4fyZV9yB01y803rWDXTVTGQ+HI03nhzt
reeooKALChQoaF+BAg0VKChfupbDAFaWabaJA2aMgY0sTCOCqUWw9QgxQZs0
Qffk4C8qwe/JZ4g2Cqw4Q75R8JRCz7I+2CVLUBufRmP0CCZ+ch9qK5aia80K
FJb0O7ILK+ETuMoJZDgJ2XKflO/gbCFVKMLr6XPfHfdjiHuXcXsTXm7Rxszg
+sTUgfv++pPTNwLBc4Hm6XzvT/uNibe87PKBaNvYv/C+6kuTpVM8fPIJ5JEL
l+WU2w9BkhEMcrFUw8nOOGzRatNm9tBVnkawrAtBXzHT+Ty2mymJCZPvIzhn
A6irhOrBI5h+eA9sowlVLKCwfAA968+AVypKdYRqidei5bVMJk0pqHwe3pIB
UC7naJIUGwFtfX+pNfOWtEY1trnzhps/t+dX37+bBnr/F8AdVx3abk9bpXW6
A/djD+2t/s75a+pcbV6Fui0l4GW4ComIXQ6/bmBqBqZqYGoRTCWCrRlw0+0p
xnHD5vYVl1MurK00oUsBlG6rxM1uJmIMqKcHXm83gp4u5JcuggkNzEwVzcMT
qI2MAbLZCGXolmCb9iKLTZt4c5QggL94idulJ7aTk7BfVg1lgy+ZPdgIgDGf
ffBPPvYJnmluBGEdgJHrq+NjHeCeRHn3bz9vW2PHofU83rgw6cGZ2RAa3L64
tFYSUNZxi6P1LQ2eKXHa2Vj4pVwG3PHewKlzRYEP1dvlSDe+j+LSRdClAjgy
CCdnUN93EM3pGSjPh8r5LusnoE3sYDm3yufhDQxA5fMttiu1zJg0htvSjze2
+a3dwlH0tt0f++oWNCIPwBkAzrym1L/7+ur41Ol4zwmPE3n4FU87I9py6Aa7
p7qplSKY+aUxOVujdfsnTUmrT7e5dDYEhpYlmHyNwooeeKWglTij0nAZFYsI
LjgHqpDLxIYVTDNC/fAEZrbvQzRThcoFyJWXoLR6OfJL+jMpZve/7umGv3QA
FOTld7SxxmKnsn0Xobjw0iF3mg1fx6H5bG71M6KbBtaWALwcwFkAtgH4j6sO
bZ/sAPdk2rtXX/qc6KGxb/CRZgnZJnLZkFGchdJJ+vMo8EK4Dy3HxzFUBfiL
Cigs6ZIYcab+LGObBudthF68SEg86W5AIIIJI8zsOYjKrv1gY6ByAfLlJeje
sBp+VxHwPHh9vfCXLgX5Hlo2giDV+nd7x5tMlx0iGLb286bZvDa/5llJwuGm
gbWLAPwqgH4AwwBuvurQ9tMqrqsfT8C97qK1+8HW2Knm0xGxbp2eWV5C2y46
oKT0uyX+Ge+G094aiQFd8DO75WTf42QjaW9xb2a5To9TWiG/qAe5gX5YY2Gq
dTTHxlHbdxBMQLBsKfIryiBf4WhDti3cNVcozPVZ2myb0bX5Nc8ayR5xfXW8
dk2p/wiAcwGsArD7+ur4eAe4J0k+ev/u6LqL1z1oTbQaU81zwS196Y/aLK/1
ZWpxspKAvXQXz8b02TB0zoP2VGrnirOWJD9qDVBvN1QuSE8qAI7juDoXoDDQ
B18akphGA83KNMJaDdZa6MCHzgetAVmeJU47K355Dxvz9tzqoZ/O9vY1pf4p
AAUAawEMXFPqf+D66vhpo3UfV6ZCYu++9LLV4cNjX7L7ak+N98BLQlvZJTW2
eQkZjkImjKTJTW2NdGMRiYL5fXnk+gqOxK4yfcJUthqiD/65awHPS7ZsJZWp
cohplL4Pb3ARjCJMPrQDtV17HaGnvw/FNavQs2Et/O5uHL0vG6V2b8tmajTO
lt8WVutfL539gjlDXjcNrC0DeDWAATEXvtsB7skG7yuv2Bj+fOTf7Wj93KxS
TR2uzHNFGcpfZlhiuzUGL6UtRVWgUBjscjRDIbS3OmsK5GvotavgLR9ICeoZ
GiM8Dd3bhdwZg1DFHECupq16cByTP38IzUOHwcZCFQvo2rgePRvWwSvmQdpD
a1tzuVb39xQYf2Ii+4n82uccM8lw08Da5wO4AsAEgM9ddWj7wY6pcBLlnetX
HuFA/QhhdBnXTRktMfl5NtDLOnNx909u3x2SwJahfZWYC9QWz4VUHXC1Dirm
HTNMlnnSCrqrAH/5YgTLF4kD5sJqpBSCniK6Vq+Av6gfzAwzNY3qjl2o7NoD
YwzI86DjDQkJ2VDcNJj/xkT8kfy65y4oM3ZNqb8GYBOAbgAz15T6d11fHe8A
92TJR7bsxR+/4YrR5tjM3WDzZK5Gy1oC8nR0PDcFL9DCfYj9nbb9OthaeHk/
w1nIOGixNCOgUgOKeahCDrqvBL/ch2BpP3RXrpX3kLGFSRGC3m4Uly9FbnAA
qlBAc+wwarv2oLp3P5pTFfn+HKTb4gyAP42a9iOF9c9fcDr3mlL/DIDzAPTJ
VN12fXW82QHuSZS/veUBvPuFF+83im9GM7qYq9EKJC0PqSVJQUeBN8OyijNo
3KZ1DaA95TJpQGtbUM7MkjACGjUEq5YgWD0IHVdN2CzZBhnyDSeZOVIEv6uI
wuASlM5cBVXIIzx0BI3Rg6jvO4DKnv2I6o2KtfjjmYMTn7rjkl+qf+4RjNH1
1XFcU+o/B8ASAD6AB6+vjp/yXF3CE0S2XX3JoBmb+ajZPfNS27D5JGLQFv6C
JCCo3ZlL+hu4piIuSUHw8hqF/rw4ZM7WJU+KMD0FlfNAOSH55H34mzYgWLcK
qpRPS3B0WiKUlOTEpUUtSQkNgBDVm5jeuReVnXvRGB07MLNz7Lbp23Y9wJVw
Oxib4Xp9VUCoXXVwOx/DxtUA3iphMQbw6asObd/eAe4pJHtfdXlfuG/qOnOg
cq0day6xyoGXhRye7BopiYW4gXhL+liliQhogDyFfF8OftFH3OeBPAUEGsrP
RBmIQNrtA6xXLIW/cTW88mKokpSOJ7vmqKQaI67MyBJ6EgArbcJ68zu7v3Hz
p/b98TeZBoI1cBvsEYBJALsB7AVwEG4LqMmrDm1vtIG2COBiAFcByImp8Omr
Dm3f0QHuKSb7fv25+fDBg8/kidp77c7KpWziPRkgtEJhESaZMAdQViTWQxxW
EAWpCbrLR7Ck4BIGnk7Da0l1sTDHVCZ0FnjwBpdAryrDX1WG6iqkIE22hFIt
FcdJtQbpcfaCD8HPfyq35oUHbiqv82F4EYAyXCp3A4CSTLWq2L9VABV5biSG
uxjAoIAWcDvofOmqQ9vHOsA9FTXvm5+jzP6JMlea77K7Jt/Ik1E/DChJ+WbS
xUnzOdVmF6us2aDgDxagu4LEXEhitNn4bty4JC4N0uSqkQs5eKtXwD9zOVRP
t9sGy0tAmikvUg1o/x7ki+8C0W25DS9vSRjctHQtgeEDyANYDeAc+b+AlKWR
vffx/bcC6Buh6KdXjW7jDnBPYal84To19oUfPdfunXwnjzeeyhNRLyxad30k
auUraMwKXspp+INFqECnnIWYeKPRymeINXEyMTK1ZINL4K9eDjXQD10qgAp5
kO8beP6DCILPcan/44UNL1kwo+umgbU+gGUAlosp0ScaNo5mNwGMArjnqkPb
93YSEKeRHPi/r+xr3rXzRXam+Toeqz6PRxp+mmnLgFcBRzHPVFopoUoa/qI8
KNAtO0Qm5kJG06avq8z5UzYb5XPQ5QF4a1c9EKw740tU6vpa/uI33v+L+L03
DazNifZlEDWuOrjttCOUd4ArMva3b6bqj7cuhu892R6uvs3uPPICHqkFrj3M
HODNpoYVQB5BFTX8/pyzd7OtneL2ULEJojMApqwNTAxPR7Sof6saGPgEafVt
b9PZu3pfdF2zc5c6wJ1TRt/7RgoPVQLS+qxo3+E3m4dHrsZEY4Aj20PVyGtJ
YChKCTnCayCPoHIKXl8OKqdaTQTp8sjZFLMmKZVX0+QHk7S49261fPCz3hkr
v2PGJ2uLf+NvTOeudID7iOXI1/6yv/K9u59p9h6+gierm9A0a2HsGXy4UsRk
oxW8RIBPIA8gX8HrDaAK4lwRUq2qFVDMMbTeC0/vpEJ+K/UWf6RXL7958Tv+
fktn1DvA/YXKwY++Y3Hjvp0reaK6DL5eg2a4kWcaa2CilVxtLEY+txTVRhGa
FGmX+lWeangF7zAF3gQU7UHg7abA3wZjtqCQO6CXLdnvv/iZ+3oveUtHs3aA
e/xl/N//Sjfu2RZEe8Z8rtV8O1HRKOQ1pisq0azWAgD7pcBQITDkqwg9pVAt
H2gO/MEnw84odqQjHelIRzrSkY50pCMd6UhHOtKRjnSkIx3pSEc60pGOdKQj
HelIRzrSkY50pCMd6UhHOtKRjnSkIx3pSEc60pGOdKQjHelIRzry2OW4FksO
D5bVPN9hh0ZH+GScc3iwTMf47bzQaxseLB+PHsM82zXIdavHeu6h0RG7wN8W
f58H1xyvC67P2BSIDsqGwo/qPj5W8Y4jaPMAPgy3l1a7GACfA3DDIzpneVkJ
zB+D60Q4283+RwA3L+BUlwG4fB7w7gLwtQX8xhyATx+HcawA+CiAn7W9fg2A
5+GxNeSeGh4sv3dodGTXMe7dagBXA3gJgIvgGuel21YyjwO4C8B/DQ+WbwRw
YGh0pHnaA1ekBLery2ySf6TABfOzAfwKXOfsdpkG8EcL1Nh/LgCYS3YND5Zv
Gxod2X+M02n5fb/ocZyUidMO3Ivl+x4LcMcA/INMztnGZy3c5n1vgWuWN5cU
4BrpvQTAdgCfGB4sf2ZodOTQiQCuOo7nbgL4+jzvnz88WF7/CM/5ynlu2o1w
/V2PJRfB7XkwnywG8MIFXtPxaBiX3U16Ia//Is6N4cHyebJqvfsYoG2XtQDe
B+CTw4Pllac1cMWOuh/AfXMcshTA0x+B6bEcwCXzXPNXZbIcS64WYB5rpXjO
8GC58ERxdoYHy4MA/hLAcx6l7+MDeCmAjw4PlntOZ40LAPsA/HCO93oAXC52
4kLkcnEQZpOHAfzsWE6H3JxnIO3APZ/TejFcY+STMYbH02k+yjEV8+n5AP7P
PL/HOWXO/p7PdHougF+Rc56eNu7Q6EhleLD8QwCvFaC2y5MBrITbxXs+wHkA
njaHowcAt8kkOZZslO9ciKwDcMnwYHnz0OjIXH29DID/Fm3DswBkBYAL5/js
NgAPzOOcPdKN8u6Ea9B8LNBOiA3dri3fNs/nDosTeq9M+mcCeAWA4izHdsHt
zv4fCzTdTknnDKJx980B3PMBrB8eLG8/Rkhl2TxmwgyAW4dGR6aPAf4AwBDc
tkgLXY1eCuArcrPnsuPfNs/nXwng7+ewM28A8Bdz/CaeBVzHko8B+J8F2uQT
s9j0F88zOT8K4P1DoyOhjOXXANQAvHkOn+MyUUinL3CHRke2DQ+Wfwa3qUb7
TQoAPBtu6/nGPKc5U5yqucyR2xZwKT0CpNmkMYf58Gy5ARNz/DaeSzPKUjk1
j4NUHRod+UVuEjI5NDryaLczXTZHpCYG+v/EoJXfPT48WP4C3G49g3Pgas3w
YPmuhcaMT0WNGztOL5cQWLu8BMD75wLu8GDZFyeue45BvW9odGQhLeYvBHDB
HO99GsCvzXLz8gBeI0vk41n0McyLFbO8fheA/zfHSqrEKT9uiYkTBdzvybJx
5izvnSWAGp7js3kAL5tnqf76Aq/hrXO8flCW8wvFAWyX1w0Plj94LFPkNJfR
Y4D6ncOD5fuHRkcezGjdaTGjToqcKOBOi7H+zjlm9GvmAe66eeyvIwC+tYBQ
z5kAnjXH2/8DYD+Ab8wB3BUSQvvqaRDSOmY0Yg5f4hBcEmHDHPfnMgBfGx4s
fxzAF+V+mpOR6j1R4bDsYH0ZQDTHIVcPD5a753jvl+aZYN+Yx47MyivnWNIs
gG/LOX4AYLZtwwPMnf07leQ88fbne1wyR2y6KYCcT+tuEgfwHgDvhQtlLjtO
XI1TA7giWwH8eI73Fosj1K5BcuLZz+U0fOlYs354sNwF4AUCwHZ5CMDPxYHY
KSGl2cboQskqncryPlm15nt8Hi5N265YIgD/BuDuBeBlJYD/C+C7cr53DQ+W
L5WQ5eMSuDNwMc/ZpCjgapfL4TZHnk3uxtxx0KxcKnb0bMvoT2WJBIARmViz
xWxXArjycWDLRvO8t0MAudANqAtifr0PwJfg0r1nPe6AK8yh2+cIH2kAF8yS
534hZg9yQ2zbY8VuPYlILJ9jIt0yNDpSzZgzt4i9N5uD+MzhwfKix6t3JqvO
TeJv3A639y8vEENr4ZhrNw4Pll9+IswHdYLH54F5QkvrsuEqAcllmD2+OA6X
dGgc4/uWwsUaZ9O2YwC+3/ba7QD2zHGuZ8BR/U5noWOBd2h05CdwfIXflWjQ
yALPrWV1/EcALzne4FUneFaPALgDwGw7ziwR5yG2RS+QmTyb3ANH4DmWh71e
wN8uDMdt2NJ2fdNys2ZbUpcBuPJE23KPUCn88BiPuwDUF3CfKkOjI/8kjvE1
4ozdfgxTI5ZBONromsdDOCwr/wsX7B+Y5b0r4XidYxICm22JDwH8eAFcWQ9z
Jz2MRDlmky8DuG6OsXk9gH9e4A080fJBGdtj2biHH4GimQDwv8OD5WHRpBsB
/LIAumceDX6BaN2/F8fvcQHcH8pyPBtwLxOwRrI0zzYwk1hYTr57njDWYQDf
meO9ewFsnkNTPxku9XzrKQjcIwuYzI/FP9k/PFg+IPfvQ3DZzhdi7lTxCwF8
8nhN8hMO3KHRkVBIGhfOYqoU4IL9/425ubq7sTBuwksAlOd47z/FOcMc2vgL
cwBXwVUGnIrAfdQyXF7mg7k8h6JgAKNDoyNNcWBDAA8MD5bfKtGEZ83xuXPx
2Co1TinnLJavzGNrvVpMhtnI3hbAfw2NjtTmvRFnrCYAb5xnKfvqHGGvOLrw
XczNCLvqRLH8T6B0i4n01VkeX5ptEkuJzn/Po1GXHE98nSzg7p3Fo4/lfMye
GgZchucLxzx7o3GpzPjZgLsZwEPHSFyMYO4U9GIAL35cwZa5LhGTp8zyuAyO
Tz3Xij2XcpjE44BkM5uD9RUAL5ojrHLmXMpUTIVjyQsxN+n8pgU4KFMSXXjZ
LDemCOD5w4Pl64+l+U+wLJLypmOJBXA4S1MUrTkszudsyu2Vw4Pl7wO4YWh0
pCJRmzXi/M5lDjw416p22gJ3aHTEDg+W7xAQnvEIPvplzB5Ky4bB5ivPmQJw
W5x0mOf6zPBg+W65vvbYLcmqcB5mTxGfLLlOPP5jyQSAP0Rr1UkIx1V4FWZP
jS+FY9B9e3iwvANpFcSl82jcb2FhNYCnlcaNl+ObAbxhgcfvAXDHAojJ52Fu
3u02uDTvQuRe0RqzJR3WAnjq8GD57nnKek60XLjA48bQxm0eGh3h4cHybXCk
pbkiMUvhYrp2ASbmVgDfPl6hsJNp42JodGQSjpFVX+BHbsYxSkGElPPMORw7
A2Dz0OjItgVe39Q810dijvSdjhbtbLbn0OjIEQAfAPCTY9imx8LMtGjn+4/n
j1AneRDvWKDNWodL8U4c47heuErV2aSGBXB32+QGzB02u/IRmjmnvAyNjvwU
wNvh4uThozjFGFyM95+O90p0soF7HxbG8NorID+WXArgSfMM6o2P8Po2z6M5
igB+6VGWYc/X/2w+ITz20vV5zzE0OnIXXCebd8CliBcSGYgE7G8B8Fcnwmn1
TvIMN8OD5X+CY4z58xz6EIjuPYaZQBJJuH6Owb5DzJNH6kR+SGxjmsP8mG9J
3gbHc7WzvPeTR7lCFfHYAvvTcJUj8/3uEbkvXxVF8Hy4FPxaAIuQlrnvgOMw
fBuOPzJxoqoiCCdZFtA5EVhg98RjnIsfZXfIR33OX/T1LHCs8IsYy3m+lzKT
71GPa0c60pGOdKQjHelIRzrSkY50pCMd6UhHOtKRjnTk8S3UGYKOPBaRquc+
KHV46MD+E5aI8DIXkIOr4rwIjrd6B4CDx5MsIe2RngzH2pqY57gyXIn0UwA8
9bHmwuW3FuF6ytpf0G/Jwe0dMX66ZJKGB8sb4Squ/+bR7JYjGbWXAfhtWPt2
OBroY72mM+B2T/rAfFtaeXJwNxy5+GVwvIECHBHkT4cHy9+V5xpaN2BML4Aw
ZsJnvrBXNPjk0OgIDy9bTrC2AKI6mLsBqKHRkfamcmcA+ASAa4YHy3cB8KFU
E9b2A2gMjY7MDJeXebJN1DMBvAdAODxYjs/bBaAuBZgFue4JSGv7odGRppBg
egFEQ6Mj0zLYr5XBed7wYHmfHG/h0pjxcxvv2yU9ehWImkMjB1i0TC+AytDo
SEx7fBVcO6JLhwfLR+AI2SZzjpyMTwNAfP25+Jjh8jIN5l4AtfaJKb8hB6Xq
sLZXXp4UHm3LuGcA1QsgglIVWFuQ87K81wdH8u6D69n2D5nP9QAJ7XQ2YHUL
biaFyxEXru6T/dFivm6XTGIjr3fL39FweRmBuQDH+ssDyEHriaH9+1i+/2oA
H2/DFgBMxb+R5I3Xy418J4i+LwP4DqQbtJ0LR7LwATwVjqjxKTi+agGOef9s
Od+tAK4HUQjm98NtLHIFHGv+63CN6iL53nPh9vN6k1zYs+U7LhEAfgRuP4TP
wxGZbwXw+wB+A66n68UA/lpu0lvlmB/IwO6EK+a7RlYRgiNKPwxHvXsaXB+C
98BVqhblRj4omvPw0OjIl6Ujy9Uyyf4VrlvLtXCdd8bk2rbJOZ8j3/ERuLKk
zUOjI/8hv/UaOJ7w9aIk7pLf+8+iLH4HjsQyKWP07cyNWya/eULGEnDNqON9
5DwAnwXwXzLOvwxHjKnLeGwA8Fcyad4k3zsNx3x7hUy6MRmrIRmrHwC4Pgvg
4cHyi+V4wJFqPgXXTuD1cO32r5HvXwbXjOVOGY83y98/gev4GME1DblLvq8f
wI/gejecAeCbcM0Ot8Ix1a6S7/whgE8OjY5UlcyyV8P1Zht5LAAABqlJREFU
0bpxaORANDQ6clgGOA9XLLcObu+rQG7QDBxZuCxf8DoZyE+K1n4NmEtwNLcN
cDtM3i6TYy7a4SoAvwdHFv9rGYA/guPR/hBuQ7mvyOu/Jtf8kMzkv8pcWwjg
twSsa+B6YX1NburvC8h/CNfG6Xq4yoohAU6fAP4ypK37SSbuFQKUj8P1zP0b
uL6674fr3nKbgOEzMjmubvutl8r3lOA4w++S756Qm9kHtyfEjwH89fBgOdsT
uEdAcbaM5VbRklfLZx+AI4EPyHe8C65m7tNwZf7Xyji9EK7E5wa4nT0vFpBp
uPqxV8tnPgHXmvV1cSul4cHyYri2TLfJuL1IxqQsz7sEYL8s3/0ZuU8fkM98
Uu7F6wRXr5fnXxWF9lbBS0LegavUfp0A+pMyad40PFimmEvah6PLsadkxg7I
zbsHjiB8C4C/E4A8Ha7i9Udw3NotctFPF018BK6c/HY4el8Vs7dljwFyH4Bv
Do2O/FDAtlau4QHRSrfAUQlnBKx/I8vSMnl+swx8XJ7TkKXrQgHJtXC7NW6T
a7ldNIoF8CMQXSugtjiaGhmfZwOADw6Njtws2vpv4cqQtsu1/ihjr7efI/7b
yCT7SwHl+QKGg0ib+V02y/34N1l1viTn+qRcx+dl6V8Pt13TdwF8BkTfk1Vi
XFayF8n5PyOrzafkmj1RQHfClSxtg+MuXyaAhBx3CK6DpoLr7HgnWisqrIzp
fwoYbxXz4IsyWW6QyReIQvq3odGRG+Dq3T4DVysYV5X0yiT8X7me+2VSPx9I
ieQPAtjQtufYWjlJvMFeDek+DVUBblE04JNktr5G1H7cZypE2lExks/PF8mY
RFpg15zlhnPmuCPiOMa/oS72Tw1puc0eAH8mN+YPAfwBWjfbsJn/DwyNHDDy
nNBaNBjvHRzvZ+uKLbVuCmCnM9eXPWeWY5xv+z3xTkOBPK6W8XuVKIltbZO6
nvmNkTwqmbEyojkDub7m0MgBztwryL2qZZp7VDP3tARXr/dquBZL8X0MM8B9
L1x711+RlWbTLBNzKvP7K3I/4r9n5BqVHFsRezqSz/lIucZK/r5Iruc18trt
EIeJZeadB+DPhwfLTx0eLL9ILvLHSLsrXgLg9cOD5U1idyyVyMOtcsJvy2NV
22Adr5BbfN4xGZy3SPPl18qyDLG/3gjXxv/34DbcO0eAVoIreJytQ/ceAE8b
HizHG55cLQP9M1mZfn14sHw2jHmr2LPL5abk4NqRFgV4Vw4Pls8ZHiw/DbN3
xoGM734B0OfEJDobR3dJXMg4hnLPXgjXu+si+f0DAvRb5fUXDw+Wnyz3sU9A
f5N8xw2Z+9jMALsgy/k4gN8W5XEFHhmpPfsbCgDeMDxYfsrwYPnZYgrdn1n5
p2QCB2Lz3ij271hW4/5UbJ+nidr+sCz7fyQgJFkWLhFj+w2yzG2VZWqLLA1f
kxt4Y0bbRpnZWEFr55N42TdyfCWjVUN5j2UAq5llaSZznu1iR70IwL/LcnOP
DPiorCZfkCXyftEYPxAQflhmdDXW0hIe+7RMhv+QSMEd8v6E2M9PlvNdB+Bf
BHxxR8S/kwjI+5FutP0O+b5qRvMY+b4pAL8JV8N2qzgtX0brVrLZcUL7OTLv
N+Umf09Mp8/IdT8k4/lV0VgfFafwiEywUCbNw/Kbvy7A+Z84HDo0OjIjy/Z1
goUV8tsa8t2xhs0Wl9ba/q7LayzPd8q1/Ivcxw9ncBOKP7EbrmXW12X8/2to
dIRbt8ZctlzB2mUApmVAIcb5r4nH/OsxqOSHZMMk/fIDk5DXcHmZD6IoDkwP
l5d5AOzQyAELAMPLVxCs9UjriI0hENTQgQMu4rBsmQJDATAgIjCroZEDLpQC
aBCZbMB7uLwsB+ZeaH0I1moALEt/HC8uktaHrnQhFyTnAQwICgzEx8tnAgCL
oNRhABbMyJzPB9AHosmhkQPNzDXE57RDIwfscHlZAOZ+AEegFIMZ0NrAGA9K
RRL+yQby+0E0PTRyoKWyWM7rAYiGRg64UCNz+reMI7SKhvbt45tXriIOw0UA
6iCqtnx2+QqCMYtBVBHQKQBmaORA/Lk+AdbkbPFoCU8uhivTaQyvWKlgjIJS
BtZqEHjogIzTsuWejJvc0+VOOzuM3Sq4+qFo3/Gh0REeXrGSsuMjwYMuAB6U
mojv+TGXHwHuW8Xof8sCKm070pFjYWqlOPS/OjQ68t3HlDmbR1iWLfP/x0DD
k0lGwYgCX6AjJE8o7eAQU+oy0vJkklEwokpcRuiIwR9yp9wBBiwyY5u0u3MA
AAAASUVORK5CYII=

--_av-abgFSrRs5Ha7cpUhVi8I4Q--

--_av-eg7-eceXNDk7VFvsSVntZw--



From xen-devel-bounces@lists.xenproject.org Sun Jan 12 02:58:42 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 12 Jan 2025 02:58:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870253.1281588 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWoBD-00079Q-5x; Sun, 12 Jan 2025 02:58:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870253.1281588; Sun, 12 Jan 2025 02:58:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWoBC-000798-Vh; Sun, 12 Jan 2025 02:58:22 +0000
Received: by outflank-mailman (input) for mailman id 870253;
 Sun, 12 Jan 2025 02:58:21 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=BgA9=UE=intel.com=lkp@srs-se1.protection.inumbo.net>)
 id 1tWoBB-000792-HD
 for xen-devel@lists.xenproject.org; Sun, 12 Jan 2025 02:58:21 +0000
Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 117bb59a-d091-11ef-a0e1-8be0dac302b0;
 Sun, 12 Jan 2025 03:58:17 +0100 (CET)
Received: from orviesa001.jf.intel.com ([10.64.159.141])
 by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 11 Jan 2025 18:58:14 -0800
Received: from lkp-server01.sh.intel.com (HELO d63d4d77d921) ([10.239.97.150])
 by orviesa001.jf.intel.com with ESMTP; 11 Jan 2025 18:58:12 -0800
Received: from kbuild by d63d4d77d921 with local (Exim 4.96)
 (envelope-from <lkp@intel.com>) id 1tWoAy-000LVj-34;
 Sun, 12 Jan 2025 02:58:08 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 117bb59a-d091-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=intel.com; i=@intel.com; q=dns/txt; s=Intel;
  t=1736650698; x=1768186698;
  h=date:from:to:cc:subject:message-id:references:
   mime-version:in-reply-to;
  bh=P6HmMuEanbN2AbJSaR7/q6oJzdrrcsN9KTJG/tRphkg=;
  b=IoeYaYy++y+nudj/LC5WGmHcDYg8D2gjKTQA4ZTyrS6ybErU+NIcEZ7d
   p/6Wfnbh2VfBHUZP8Dp5sBcPXWWDpzV4CSY3P1eBK+6x+19g/dPlx5eFI
   /YB7PKEWV8dkjOyczNgda8FoGGJJR9EH1DgJXYw2PavP+DSa3mRO/fqiL
   csR1SLAfGYpLaY02BiDUexIEazdyDu4IErMDxwq4V6Z8L+JcLOK1pcg3t
   falI8c6J1+hTT2fEko21qiAv89x8qTQslFmO/1HnhSh7zz1UcxG5dGIXb
   UptENu5t66mYf4xu7BHeyKe1Ty6dA6nF10Wt7tuusE9phqvBeY/nlw1G1
   A==;
X-CSE-ConnectionGUID: jUA6XyM8RrKWBiXaQrP22g==
X-CSE-MsgGUID: u93Tf128TAOJ/jP/qZ/IhA==
X-IronPort-AV: E=McAfee;i="6700,10204,11312"; a="47567860"
X-IronPort-AV: E=Sophos;i="6.12,308,1728975600"; 
   d="scan'208";a="47567860"
X-CSE-ConnectionGUID: /Oq5OKv5Spuy/fOjb2Q2bw==
X-CSE-MsgGUID: 0+LuP4+JQZaN13IodNqk0Q==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="6.12,224,1728975600"; 
   d="scan'208";a="141387405"
Date: Sun, 12 Jan 2025 10:57:27 +0800
From: kernel test robot <lkp@intel.com>
To: Roger Pau Monne <roger.pau@citrix.com>, linux-kernel@vger.kernel.org,
	xen-devel@lists.xenproject.org, linux-pci@vger.kernel.org
Cc: oe-kbuild-all@lists.linux.dev, Roger Pau Monne <roger.pau@citrix.com>,
	Nirmal Patel <nirmal.patel@linux.intel.com>,
	Jonathan Derrick <jonathan.derrick@linux.dev>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= <kw@linux.com>,
	Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
	Rob Herring <robh@kernel.org>, Bjorn Helgaas <helgaas@kernel.org>
Subject: Re: [PATCH 2/3] vmd: disable MSI remapping bypass under Xen
Message-ID: <202501121029.dJk0TBPr-lkp@intel.com>
References: <20250110140152.27624-3-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250110140152.27624-3-roger.pau@citrix.com>

Hi Roger,

kernel test robot noticed the following build errors:

[auto build test ERROR on pci/next]
[also build test ERROR on pci/for-linus tip/irq/core linus/master v6.13-rc6 next-20250110]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Roger-Pau-Monne/xen-pci-do-not-register-devices-outside-of-PCI-segment-scope/20250110-220331
base:   https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git next
patch link:    https://lore.kernel.org/r/20250110140152.27624-3-roger.pau%40citrix.com
patch subject: [PATCH 2/3] vmd: disable MSI remapping bypass under Xen
config: x86_64-buildonly-randconfig-001-20250112 (https://download.01.org/0day-ci/archive/20250112/202501121029.dJk0TBPr-lkp@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250112/202501121029.dJk0TBPr-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202501121029.dJk0TBPr-lkp@intel.com/

All errors (new ones prefixed by >>):

   drivers/pci/controller/vmd.c: In function 'vmd_probe':
>> drivers/pci/controller/vmd.c:973:13: error: implicit declaration of function 'xen_domain' [-Werror=implicit-function-declaration]
     973 |         if (xen_domain())
         |             ^~~~~~~~~~
   cc1: some warnings being treated as errors


vim +/xen_domain +973 drivers/pci/controller/vmd.c

   966	
   967	static int vmd_probe(struct pci_dev *dev, const struct pci_device_id *id)
   968	{
   969		unsigned long features = (unsigned long) id->driver_data;
   970		struct vmd_dev *vmd;
   971		int err;
   972	
 > 973		if (xen_domain())
   974			/*
   975			 * Xen doesn't have knowledge about devices in the VMD bus.
   976			 * Bypass of MSI remapping won't work in that case as direct
   977			 * write to the MSI entries won't result in functional
   978			 * interrupts.
   979			 */
   980			features &= ~VMD_FEAT_CAN_BYPASS_MSI_REMAP;
   981	
   982		if (resource_size(&dev->resource[VMD_CFGBAR]) < (1 << 20))
   983			return -ENOMEM;
   984	
   985		vmd = devm_kzalloc(&dev->dev, sizeof(*vmd), GFP_KERNEL);
   986		if (!vmd)
   987			return -ENOMEM;
   988	
   989		vmd->dev = dev;
   990		vmd->instance = ida_alloc(&vmd_instance_ida, GFP_KERNEL);
   991		if (vmd->instance < 0)
   992			return vmd->instance;
   993	
   994		vmd->name = devm_kasprintf(&dev->dev, GFP_KERNEL, "vmd%d",
   995					   vmd->instance);
   996		if (!vmd->name) {
   997			err = -ENOMEM;
   998			goto out_release_instance;
   999		}
  1000	
  1001		err = pcim_enable_device(dev);
  1002		if (err < 0)
  1003			goto out_release_instance;
  1004	
  1005		vmd->cfgbar = pcim_iomap(dev, VMD_CFGBAR, 0);
  1006		if (!vmd->cfgbar) {
  1007			err = -ENOMEM;
  1008			goto out_release_instance;
  1009		}
  1010	
  1011		pci_set_master(dev);
  1012		if (dma_set_mask_and_coherent(&dev->dev, DMA_BIT_MASK(64)) &&
  1013		    dma_set_mask_and_coherent(&dev->dev, DMA_BIT_MASK(32))) {
  1014			err = -ENODEV;
  1015			goto out_release_instance;
  1016		}
  1017	
  1018		if (features & VMD_FEAT_OFFSET_FIRST_VECTOR)
  1019			vmd->first_vec = 1;
  1020	
  1021		spin_lock_init(&vmd->cfg_lock);
  1022		pci_set_drvdata(dev, vmd);
  1023		err = vmd_enable_domain(vmd, features);
  1024		if (err)
  1025			goto out_release_instance;
  1026	
  1027		dev_info(&vmd->dev->dev, "Bound to PCI domain %04x\n",
  1028			 vmd->sysdata.domain);
  1029		return 0;
  1030	
  1031	 out_release_instance:
  1032		ida_free(&vmd_instance_ida, vmd->instance);
  1033		return err;
  1034	}
  1035	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From xen-devel-bounces@lists.xenproject.org Sun Jan 12 10:37:12 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 12 Jan 2025 10:37:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870362.1281598 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWvKw-0003jq-Kx; Sun, 12 Jan 2025 10:36:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870362.1281598; Sun, 12 Jan 2025 10:36:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tWvKw-0003ji-G6; Sun, 12 Jan 2025 10:36:54 +0000
Received: by outflank-mailman (input) for mailman id 870362;
 Sun, 12 Jan 2025 10:36:53 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=LboG=UE=redhat.com=bhe@srs-se1.protection.inumbo.net>)
 id 1tWvKv-0003jZ-5I
 for xen-devel@lists.xenproject.org; Sun, 12 Jan 2025 10:36:53 +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 20e8c332-d0d1-11ef-99a4-01e77a169b0f;
 Sun, 12 Jan 2025 11:36:50 +0100 (CET)
Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-543-0DSN8VPiNBSr_DA-YHIeIA-1; Sun,
 12 Jan 2025 05:36:43 -0500
Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id A2F3A19560BB; Sun, 12 Jan 2025 10:36:36 +0000 (UTC)
Received: from localhost (unknown [10.72.113.4])
 by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 5808B195608A; Sun, 12 Jan 2025 10:36:31 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 20e8c332-d0d1-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1736678208;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=sjZIf+MqzlX40O8hdTacUc+jXg2UIC0x4trWd6422To=;
	b=JRaeevjZ96oHjJQ1+zlJLKv3PPjA6x4TtwGlVB6Z5mmYMrjQse/nVDRGC38ugLjgwvtMcY
	IL/GrFzptogbiZYIn6bgXf9Q0KtEiDos66j3/Vd+y7nMYvy1aYMLdO15a0bKkMD3+6uPEw
	sH5apmamWA3dNIUA7cIrBCLBBRMCGRs=
X-MC-Unique: 0DSN8VPiNBSr_DA-YHIeIA-1
X-Mimecast-MFC-AGG-ID: 0DSN8VPiNBSr_DA-YHIeIA
Date: Sun, 12 Jan 2025 18:36:27 +0800
From: Baoquan He <bhe@redhat.com>
To: Joel Granados <joel.granados@kernel.org>
Cc: Thomas =?iso-8859-1?Q?Wei=DFschuh?= <linux@weissschuh.net>,
	Kees Cook <kees@kernel.org>, Luis Chamberlain <mcgrof@kernel.org>,
	linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,
	linux-s390@vger.kernel.org, linux-crypto@vger.kernel.org,
	openipmi-developer@lists.sourceforge.net,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	intel-xe@lists.freedesktop.org, linux-hyperv@vger.kernel.org,
	linux-rdma@vger.kernel.org, linux-raid@vger.kernel.org,
	linux-scsi@vger.kernel.org, linux-serial@vger.kernel.org,
	xen-devel@lists.xenproject.org, linux-aio@kvack.org,
	linux-fsdevel@vger.kernel.org, netfs@lists.linux.dev,
	codalist@coda.cs.cmu.edu, linux-mm@kvack.org,
	linux-nfs@vger.kernel.org, ocfs2-devel@lists.linux.dev,
	fsverity@lists.linux.dev, linux-xfs@vger.kernel.org,
	io-uring@vger.kernel.org, bpf@vger.kernel.org,
	kexec@lists.infradead.org, linux-trace-kernel@vger.kernel.org,
	linux-hardening@vger.kernel.org, apparmor@lists.ubuntu.com,
	linux-security-module@vger.kernel.org, keyrings@vger.kernel.org,
	Song Liu <song@kernel.org>,
	"Steven Rostedt (Google)" <rostedt@goodmis.org>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	"Darrick J. Wong" <djwong@kernel.org>,
	Jani Nikula <jani.nikula@intel.com>,
	Corey Minyard <cminyard@mvista.com>
Subject: Re: [PATCH v2] treewide: const qualify ctl_tables where applicable
Message-ID: <Z4ObK5hkQ7qjWgbf@MiWiFi-R3L-srv>
References: <20250110-jag-ctl_table_const-v2-1-0000e1663144@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250110-jag-ctl_table_const-v2-1-0000e1663144@kernel.org>
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15

On 01/10/25 at 03:16pm, Joel Granados wrote:
...snip...
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index c0caa14880c3..71b0809e06d6 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -925,7 +925,7 @@ static int kexec_limit_handler(const struct ctl_table *table, int write,
>  	return proc_dointvec(&tmp, write, buffer, lenp, ppos);
>  }
>  
> -static struct ctl_table kexec_core_sysctls[] = {
> +static const struct ctl_table kexec_core_sysctls[] = {
>  	{
>  		.procname	= "kexec_load_disabled",
>  		.data		= &kexec_load_disabled,

For the kexec/kdump part,

Acked-by: Baoquan He <bhe@redhat.com>
......



From xen-devel-bounces@lists.xenproject.org Mon Jan 13 03:55:25 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Jan 2025 03:55:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870420.1281608 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXBXS-0006dI-M1; Mon, 13 Jan 2025 03:54:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870420.1281608; Mon, 13 Jan 2025 03:54:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXBXS-0006dA-GX; Mon, 13 Jan 2025 03:54:54 +0000
Received: by outflank-mailman (input) for mailman id 870420;
 Mon, 13 Jan 2025 03:54: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 <SRS0=0M65=UF=163.com=andyshrk@srs-se1.protection.inumbo.net>)
 id 1tXBXR-0006d3-Js
 for xen-devel@lists.xenproject.org; Mon, 13 Jan 2025 03:54:53 +0000
Received: from m16.mail.163.com (m16.mail.163.com [220.197.31.3])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id 223f6ade-d162-11ef-99a4-01e77a169b0f;
 Mon, 13 Jan 2025 04:54:50 +0100 (CET)
Received: from andyshrk$163.com ( [103.29.142.67] ) by
 ajax-webmail-wmsvr-40-117 (Coremail) ; Mon, 13 Jan 2025 11:53:59 +0800
 (CST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 223f6ade-d162-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com;
	s=s110527; h=Date:From:Subject:Content-Type:MIME-Version:
	Message-ID; bh=eemiIfpJILwOwTzjnZMeRKg1K3cifJJEv104WN7Ptf8=; b=J
	CISy2Zi4WrKmoei+W04SElMfBUZbXsY2n+xpFOCqDmNHtyexlDrgrdshJr2bSKLl
	P7T4CJE7Qo1SvA9EIwv7dmzQkavXi3jFYVYDqoIHIRZGv1dLejGYHHEfnDQtQRE3
	0VYGm1B27i9cq78tLx+8WoWRmp3FsjWETp5TF+zyWA=
X-Originating-IP: [103.29.142.67]
Date: Mon, 13 Jan 2025 11:53:59 +0800 (CST)
From: "Andy Yan" <andyshrk@163.com>
To: "Thomas Zimmermann" <tzimmermann@suse.de>
Cc: maarten.lankhorst@linux.intel.com, mripard@kernel.org, airlied@gmail.com, 
	simona@ffwll.ch, dri-devel@lists.freedesktop.org, 
	linux-mediatek@lists.infradead.org, freedreno@lists.freedesktop.org, 
	linux-arm-msm@vger.kernel.org, imx@lists.linux.dev, 
	linux-samsung-soc@vger.kernel.org, nouveau@lists.freedesktop.org, 
	virtualization@lists.linux.dev, spice-devel@lists.freedesktop.org, 
	linux-renesas-soc@vger.kernel.org, 
	linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org, 
	intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org
Subject: Re:Re: [PATCH v2 02/25] drm/dumb-buffers: Provide helper to set
 pitch and size
X-Priority: 3
X-Mailer: Coremail Webmail Server Version XT5.0.14 build 20240801(9da12a7b)
 Copyright (c) 2002-2025 www.mailtech.cn 163com
In-Reply-To: <e800ebc2-39b5-46d5-89ec-883ed1c7626b@suse.de>
References: <20250109150310.219442-1-tzimmermann@suse.de>
 <20250109150310.219442-3-tzimmermann@suse.de>
 <94f78e1.19bf.1944de709b0.Coremail.andyshrk@163.com>
 <e800ebc2-39b5-46d5-89ec-883ed1c7626b@suse.de>
X-NTES-SC: AL_Qu2YBPufv0wo7yKeZulS/DNQ2YpmHKvs4olgqcQkZd0qqTHPyz4QZ0BuLUbI3d4WuFSnvoMCEgbKZbJt8QVJ
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset=UTF-8
MIME-Version: 1.0
Message-ID: <443491d4.4087.1945dcc04e3.Coremail.andyshrk@163.com>
X-Coremail-Locale: zh_CN
X-CM-TRANSID:dSgvCgCXH4lXjoRnjolVAA--.27065W
X-CM-SenderInfo: 5dqg52xkunqiywtou0bp/1tbiqAHTXmeEidhe-AACs2
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==

CkhpIFRob21hcywKCkF0IDIwMjUtMDEtMTAgMjE6MjM6NDgsICJUaG9tYXMgWmltbWVybWFubiIg
PHR6aW1tZXJtYW5uQHN1c2UuZGU+IHdyb3RlOgo+SGkKPgo+Cj5BbSAxMC4wMS4yNSB1bSAwMjo0
OSBzY2hyaWViIEFuZHkgWWFuOgo+PiBIaSBUaG9tYXMsCj4+Cj4+IEF0IDIwMjUtMDEtMDkgMjI6
NTY6NTYsICJUaG9tYXMgWmltbWVybWFubiIgPHR6aW1tZXJtYW5uQHN1c2UuZGU+IHdyb3RlOgo+
Pj4gQWRkIGRybV9tb2Rlc19zaXplX2R1bWIoKSwgYSBoZWxwZXIgdG8gY2FsY3VsYXRlIHRoZSBk
dW1iLWJ1ZmZlcgo+Pj4gc2NhbmxpbmUgcGl0Y2ggYW5kIGFsbG9jYXRpb24gc2l6ZS4gSW1wbGVt
ZW50YXRpb25zIG9mIHN0cnVjdAo+Pj4gZHJtX2RyaXZlci5kdW1iX2NyZWF0ZSBjYW4gY2FsbCB0
aGUgbmV3IGhlbHBlciBmb3IgdGhlaXIgc2l6ZQo+Pj4gY29tcHV0YXRpb25zLiBUaGVyZSdzIGN1
cnJlbnRseSBxdWl0ZSBhIGJpdCBvZiBjb2RlIGR1cGxpY2F0aW9uCj4+PiBhbW9uZyBEUk0ncyBt
ZW1vcnkgbWFuYWdlcnMuIEVhY2ggY2FsY3VsYXRlcyBzY2FubGluZSBwaXRjaCBhbmQKPj4+IGJ1
ZmZlciBzaXplIGZyb20gdGhlIGdpdmVuIGFyZ3VtZW50cywgYnV0IHRoZSBpbXBsZW1lbnRhdGlv
bnMgYXJlCj4+PiBpbmNvbnNpc3RlbnQgaW4gaG93IHRoZXkgdHJlYXQgYWxpZ25tZW50IGFuZCBm
b3JtYXQgc3VwcG9ydC4gTGF0ZXIKPj4+IHBhdGNoZXMgd2lsbCB1bmlmeSB0aGlzIGNvZGUgb24g
dG9wIG9mIGRybV9tb2RlX3NpemVfZHVtYigpIGFzCj4+PiBtdWNoIGFzIHBvc3NpYmxlLgo+Pj4K
Pj4+IGRybV9tb2RlX3NpemVfZHVtYigpIHVzZXMgZXhpc3RpbmcgNENDIGZvcm1hdCBoZWxwZXJz
IHRvIGludGVycHJldCB0aGUKPj4+IGdpdmVuIGNvbG9yIG1vZGUuIFRoaXMgbWFrZXMgdGhlIGR1
bWItYnVmZmVyIGludGVyZmFjZSBiZWhhdmUgc2ltaWxhcgo+Pj4gdGhlIGtlcm5lbCdzIHZpZGVv
PSBwYXJhbWV0ZXIuIEFnYWluLCBjdXJyZW50IHBlci1kcml2ZXIgaW1wbGVtZW50YXRpb25zCj4+
PiBsaWtlbHkgaGF2ZSBzdWJ0bGUgZGlmZmVyZW5jZXMgb3IgYnVncyBpbiBob3cgdGhleSBzdXBw
b3J0IGNvbG9yIG1vZGVzLgo+Pj4KPj4+IEZ1dHVyZSBkaXJlY3Rpb25zOiBvbmUgYnVnIGlzIHBy
ZXNlbnQgaW4gdGhlIGN1cnJlbnQgaW5wdXQgdmFsaWRhdGlvbgo+Pj4gaW4gZHJtX21vZGVfY3Jl
YXRlX2R1bWIoKS4gVGhlIGR1bWItYnVmZmVyIG92ZXJmbG93IHRlc3RzIHJvdW5kIHVwIGFueQo+
Pj4gZ2l2ZW4gYml0cy1wZXItcGl4ZWwgdmFsdWUgdG8gYSBtdWx0aXBsZSBvZiA4LiBTbyBldmVu
IG9uZS1iaXQgZm9ybWF0cywKPj4+IHN1Y2ggYXMgRFJNX0ZPUk1BVF9DMSwgcmVxdWlyZSA4IGJp
dHMgcGVyIHBpeGVsLiBXaGlsZSBub3QgY29tbW9uLAo+Pj4gbG93LWVuZCBkaXNwbGF5cyB1c2Ug
c3VjaCBmb3JtYXRzOyB3aXRoIGEgcG9zc2libGUgb3ZlcmNvbW1pdG1lbnQgb2YKPj4+IG1lbW9y
eS4gQXQgc29tZSBwb2ludCwgdGhlIHZhbGlkYXRpb24gbG9naWMgaW4gZHJtX21vZGVfc2l6ZV9k
dW1iKCkgaXMKPj4+IHN1cHBvc2VkIHRvIHJlcGxhY2UgdGhlIGVycm9ub3VzIGNvZGUuCj4+Pgo+
Pj4gU2lnbmVkLW9mZi1ieTogVGhvbWFzIFppbW1lcm1hbm4gPHR6aW1tZXJtYW5uQHN1c2UuZGU+
Cj4+PiAtLS0KPj4+IGRyaXZlcnMvZ3B1L2RybS9kcm1fZHVtYl9idWZmZXJzLmMgfCA5MyArKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysKPj4+IGluY2x1ZGUvZHJtL2RybV9kdW1iX2J1ZmZl
cnMuaCAgICAgfCAxNCArKysrKwo+Pj4gMiBmaWxlcyBjaGFuZ2VkLCAxMDcgaW5zZXJ0aW9ucygr
KQo+Pj4gY3JlYXRlIG1vZGUgMTAwNjQ0IGluY2x1ZGUvZHJtL2RybV9kdW1iX2J1ZmZlcnMuaAo+
Pj4KPj4+IGRpZmYgLS1naXQgYS9kcml2ZXJzL2dwdS9kcm0vZHJtX2R1bWJfYnVmZmVycy5jIGIv
ZHJpdmVycy9ncHUvZHJtL2RybV9kdW1iX2J1ZmZlcnMuYwo+Pj4gaW5kZXggOTkxNmFhZjViM2Yy
Li5mZDM5NzIwYmQ2MTcgMTAwNjQ0Cj4+PiAtLS0gYS9kcml2ZXJzL2dwdS9kcm0vZHJtX2R1bWJf
YnVmZmVycy5jCj4+PiArKysgYi9kcml2ZXJzL2dwdS9kcm0vZHJtX2R1bWJfYnVmZmVycy5jCj4+
PiBAQCAtMjUsNiArMjUsOCBAQAo+Pj4KPj4+ICNpbmNsdWRlIDxkcm0vZHJtX2RldmljZS5oPgo+
Pj4gI2luY2x1ZGUgPGRybS9kcm1fZHJ2Lmg+Cj4+PiArI2luY2x1ZGUgPGRybS9kcm1fZHVtYl9i
dWZmZXJzLmg+Cj4+PiArI2luY2x1ZGUgPGRybS9kcm1fZm91cmNjLmg+Cj4+PiAjaW5jbHVkZSA8
ZHJtL2RybV9nZW0uaD4KPj4+ICNpbmNsdWRlIDxkcm0vZHJtX21vZGUuaD4KPj4+Cj4+PiBAQCAt
NTcsNiArNTksOTcgQEAKPj4+ICAgKiBhIGhhcmR3YXJlLXNwZWNpZmljIGlvY3RsIHRvIGFsbG9j
YXRlIHN1aXRhYmxlIGJ1ZmZlciBvYmplY3RzLgo+Pj4gICAqLwo+Pj4KPj4+ICtzdGF0aWMgaW50
IGRybV9tb2RlX2FsaWduX2R1bWIoc3RydWN0IGRybV9tb2RlX2NyZWF0ZV9kdW1iICphcmdzLAo+
Pj4gKwkJCSAgICAgICB1bnNpZ25lZCBsb25nIHBpdGNoX2FsaWduLAo+Pj4gKwkJCSAgICAgICB1
bnNpZ25lZCBsb25nIHNpemVfYWxpZ24pCj4+PiArewo+Pj4gKwl1MzIgcGl0Y2ggPSBhcmdzLT5w
aXRjaDsKPj4+ICsJdTMyIHNpemU7Cj4+PiArCj4+PiArCWlmICghcGl0Y2gpCj4+PiArCQlyZXR1
cm4gLUVJTlZBTDsKPj4+ICsKPj4+ICsJaWYgKHBpdGNoX2FsaWduKQo+Pj4gKwkJcGl0Y2ggPSBy
b3VuZHVwKHBpdGNoLCBwaXRjaF9hbGlnbik7Cj4+PiArCj4+PiArCS8qIG92ZXJmbG93IGNoZWNr
cyBmb3IgMzJiaXQgc2l6ZSBjYWxjdWxhdGlvbnMgKi8KPj4+ICsJaWYgKGFyZ3MtPmhlaWdodCA+
IFUzMl9NQVggLyBwaXRjaCkKPj4+ICsJCXJldHVybiAtRUlOVkFMOwo+Pj4gKwo+Pj4gKwlpZiAo
IXNpemVfYWxpZ24pCj4+PiArCQlzaXplX2FsaWduID0gUEFHRV9TSVpFOwo+Pj4gKwllbHNlIGlm
ICghSVNfQUxJR05FRChzaXplX2FsaWduLCBQQUdFX1NJWkUpKQo+Pj4gKwkJcmV0dXJuIC1FSU5W
QUw7Cj4+PiArCj4+PiArCXNpemUgPSBBTElHTihhcmdzLT5oZWlnaHQgKiBwaXRjaCwgc2l6ZV9h
bGlnbik7Cj4+PiArCWlmICghc2l6ZSkKPj4+ICsJCXJldHVybiAtRUlOVkFMOwo+Pj4gKwo+Pj4g
KwlhcmdzLT5waXRjaCA9IHBpdGNoOwo+Pj4gKwlhcmdzLT5zaXplID0gc2l6ZTsKPj4+ICsKPj4+
ICsJcmV0dXJuIDA7Cj4+PiArfQo+Pj4gKwo+Pj4gKy8qKgo+Pj4gKyAqIGRybV9tb2RlX3NpemVf
ZHVtYiAtIENhbGN1bGF0ZXMgdGhlIHNjYW5saW5lIGFuZCBidWZmZXIgc2l6ZXMgZm9yIGR1bWIg
YnVmZmVycwo+Pj4gKyAqIEBkZXY6IERSTSBkZXZpY2UKPj4+ICsgKiBAYXJnczogUGFyYW1ldGVy
cyBmb3IgdGhlIGR1bWIgYnVmZmVyCj4+PiArICogQHBpdGNoX2FsaWduOiBTY2FubGluZSBhbGln
bm1lbnQgaW4gYnl0ZXMKPj4+ICsgKiBAc2l6ZV9hbGlnbjogQnVmZmVyLXNpemUgYWxpZ25tZW50
IGluIGJ5dGVzCj4+PiArICoKPj4+ICsgKiBUaGUgaGVscGVyIGRybV9tb2RlX3NpemVfZHVtYigp
IGNhbGN1bGF0ZXMgdGhlIHNpemUgb2YgdGhlIGJ1ZmZlcgo+Pj4gKyAqIGFsbG9jYXRpb24gYW5k
IHRoZSBzY2FubGluZSBzaXplIGZvciBhIGR1bWIgYnVmZmVyLiBDYWxsZXJzIGhhdmUgdG8KPj4+
ICsgKiBzZXQgdGhlIGJ1ZmZlcnMgd2lkdGgsIGhlaWdodCBhbmQgY29sb3IgbW9kZSBpbiB0aGUg
YXJndW1lbnQgQGFyZy4KPj4+ICsgKiBUaGUgaGVscGVyIHZhbGlkYXRlcyB0aGUgY29ycmVjdG5l
c3Mgb2YgdGhlIGlucHV0IGFuZCB0ZXN0cyBmb3IKPj4+ICsgKiBwb3NzaWJsZSBvdmVyZmxvd3Mu
IElmIHN1Y2Nlc3NmdWwsIGl0IHJldHVybnMgdGhlIGR1bWIgYnVmZmVyJ3MKPj4+ICsgKiByZXF1
aXJlZCBzY2FubGluZSBwaXRjaCBhbmQgc2l6ZSBpbiAmYXJncy4KPj4+ICsgKgo+Pj4gKyAqIFRo
ZSBwYXJhbWV0ZXIgQHBpdGNoX2FsaWduIGFsbG93cyB0aGUgZHJpdmVyIHRvIHNwZWNpZmllcyBh
bgo+Pj4gKyAqIGFsaWdubWVudCBmb3IgdGhlIHNjYW5saW5lIHBpdGNoLCBpZiB0aGUgaGFyZHdh
cmUgcmVxdWlyZXMgYW55LiBUaGUKPj4+ICsgKiBjYWxjdWxhdGVkIHBpdGNoIHdpbGwgYmUgYSBt
dWx0aXBsZSBvZiB0aGUgYWxpZ25tZW50LiBUaGUgcGFyYW1ldGVyCj4+PiArICogQHNpemVfYWxp
Z24gYWxsb3dzIHRvIHNwZWNpZnkgYW4gYWxpZ25tZW50IGZvciBidWZmZXIgc2l6ZXMuIFRoZQo+
Pj4gKyAqIHJldHVybmVkIHNpemUgaXMgYWx3YXlzIGEgbXVsdGlwbGUgb2YgUEFHRV9TSVpFLgo+
Pj4gKyAqCj4+PiArICogUmV0dXJuczoKPj4+ICsgKiBaZXJvIG9uIHN1Y2Nlc3MsIG9yIGEgbmVn
YXRpdmUgZXJyb3IgY29kZSBvdGhlcndpc2UuCj4+PiArICovCj4+PiAraW50IGRybV9tb2RlX3Np
emVfZHVtYihzdHJ1Y3QgZHJtX2RldmljZSAqZGV2LAo+Pj4gKwkJICAgICAgIHN0cnVjdCBkcm1f
bW9kZV9jcmVhdGVfZHVtYiAqYXJncywKPj4+ICsJCSAgICAgICB1bnNpZ25lZCBsb25nIHBpdGNo
X2FsaWduLAo+Pj4gKwkJICAgICAgIHVuc2lnbmVkIGxvbmcgc2l6ZV9hbGlnbikKPj4+ICt7Cj4+
PiArCXUzMiBmb3VyY2M7Cj4+PiArCWNvbnN0IHN0cnVjdCBkcm1fZm9ybWF0X2luZm8gKmluZm87
Cj4+PiArCXU2NCBwaXRjaDsKPj4+ICsKPj4+ICsJLyoKPj4+ICsJICogVGhlIHNjYW5saW5lIHBp
dGNoIGRlcGVuZHMgb24gdGhlIGJ1ZmZlciB3aWR0aCBhbmQgdGhlIGNvbG9yCj4+PiArCSAqIGZv
cm1hdC4gVGhlIGxhdHRlciBpcyBzcGVjaWZpZWQgYXMgYSBjb2xvci1tb2RlIGNvbnN0YW50IGZv
cgo+Pj4gKwkgKiB3aGljaCB3ZSBmaXJzdCBoYXZlIHRvIGZpbmQgdGhlIGNvcnJlc3BvbmRpbmcg
Y29sb3IgZm9ybWF0Lgo+Pj4gKwkgKgo+Pj4gKwkgKiBEaWZmZXJlbnQgY29sb3IgZm9ybWF0cyBj
YW4gaGF2ZSB0aGUgc2FtZSBjb2xvci1tb2RlIGNvbnN0YW50Lgo+Pj4gKwkgKiBGb3IgZXhhbXBs
ZSBYUkdCODg4OCBhbmQgQkdSWDg4ODggYm90aCBoYXZlIGEgY29sb3IgbW9kZSBvZiAzMi4KPj4+
ICsJICogSXQgaXMgcG9zc2libGUgdG8gdXNlIGRpZmZlcmVudCBmb3JtYXRzIGZvciBkdW1iLWJ1
ZmZlciBhbGxvY2F0aW9uCj4+PiArCSAqIGFuZCByZW5kZXJpbmcgYXMgbG9uZyBhcyBhbGwgaW52
b2x2ZWQgZm9ybWF0cyBzaGFyZSB0aGUgc2FtZQo+Pj4gKwkgKiBjb2xvci1tb2RlIGNvbnN0YW50
Lgo+Pj4gKwkgKi8KPj4+ICsJZm91cmNjID0gZHJtX2RyaXZlcl9jb2xvcl9tb2RlX2Zvcm1hdChk
ZXYsIGFyZ3MtPmJwcCk7Cj4+IFRoaXMgd2lsbCByZXR1cm4gLUVJTlZBTCB3aXRoIGJwcCBkcm1f
bW9kZV9sZWdhY3lfZmJfZm9ybWF0IGRvZXNuJ3Qgc3VwcG9ydCwKPj4gc3VjaCBhcyhOVjE1LCBO
VjIwLCBOVjMwLCBicHAgaXMgMTApWzBdCj4KPlRoYW5rcyBmb3IgdGFraW5nIGEgbG9vay4gVGhh
dCBOVi1yZWxhdGVkIGNvZGUgYXQgWzBdIGlzIGEgJ3NvbWV3aGF0IAo+bm9uLWlkaW9tYXRpYyB1
c2UnIG9mIHRoZSBVQVBJLiBUaGUgZHVtYi1idWZmZXIgaW50ZXJmYWNlIHJlYWxseSBqdXN0IAo+
c3VwcG9ydHMgYSBzaW5nbGUgcGxhbmUuIFRoZSBmaXggd291bGQgYmUgYSBuZXcgaW9jdGwgdGhh
dCB0YWtlcyBhIERSTSAKPjRjYyBjb25zdGFudCBhbmQgcmV0dXJucyBhIGJ1ZmZlciBoYW5kbGUv
cGl0Y2gvc2l6ZSBmb3IgZWFjaCBwbGFuZS4gQnV0IAo+dGhhdCdzIHNlcGFyYXRlIHNlcmllcyB0
aHJvdWdob3V0IHRoZSB2YXJpb3VzIGNvbXBvbmVudHMuCgpTbyBpcyB0aGVyZSBhIHN0YW5kYXJk
IHdheSB0byBjcmVhdGUgYnVmZmVyIGZvciBOVi1yZWxhdGVkIGZvcm1hdCBub3cgPwpXaXRoIGEg
cXVpY2sgc2VhcmNoLCBJIGNhbiBzZWUgbWFueSB1c2VyIHNwYWNlIHVzZSBkdW1iLWJ1ZmZlciBm
b3IgTlYtcmVsZWF0ZWQKYnVmZmVyIGFsbG9jOgoKWzBdaHR0cHM6Ly9naXRodWIuY29tL3RvbWJh
L2ttc3h4L2Jsb2IvbWFzdGVyL2ttcyUyQiUyQi9zcmMvcGl4ZWxmb3JtYXRzLmNwcApbMV1odHRw
czovL2dpdGxhYi5mcmVlZGVza3RvcC5vcmcvZHJtL2lndC1ncHUtdG9vbHMvLS9ibG9iL21hc3Rl
ci9saWIvaWd0X2ZiLmM/cmVmX3R5cGU9aGVhZHMKWzJdaHR0cHM6Ly9naXRsYWIuZnJlZWRlc2t0
b3Aub3JnL2dzdHJlYW1lci9nc3RyZWFtZXIvLS9ibG9iL21haW4vc3VicHJvamVjdHMvZ3N0LXBs
dWdpbnMtYmFkL3N5cy9rbXMvZ3N0a21zdXRpbHMuYz9yZWZfdHlwZT1oZWFkcyNMMTE2Cgo+Cj5U
aGVyZSdzIGFsc28gY29kZSBYUkdCMTYxNjE2MTZGLiBUaGlzIGlzIGEgdmlhYmxlIGZvcm1hdCBm
b3IgdGhlIFVBUEksIAo+YnV0IHNlZW1zIG5vdCB2ZXJ5IHVzZWZ1bCBpbiBwcmFjdGljZS4KPgo+
Pgo+PiBBbmQgdGhlcmUgYXJlIGFsc28gc29tZSBBRkJDIGJhc2VkIGZvcm1hdCB3aXRoIGJwcCBj
YW4ndCBiZSBoYW5kbGVkIGhlcmUsIHNlZToKPj4gc3RhdGljIF9fdTMyIGRybV9nZW1fYWZiY19n
ZXRfYnBwKHN0cnVjdCBkcm1fZGV2aWNlICpkZXYsCj4+ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgY29uc3Qgc3RydWN0IGRybV9tb2RlX2ZiX2NtZDIgKm1vZGVfY21kKQo+PiB7
Cj4+ICAgICAgICAgIGNvbnN0IHN0cnVjdCBkcm1fZm9ybWF0X2luZm8gKmluZm87Cj4+ICAgICAg
ICAgICAgICAgICAgCj4+ICAgICAgICAgIGluZm8gPSBkcm1fZ2V0X2Zvcm1hdF9pbmZvKGRldiwg
bW9kZV9jbWQpOwo+PiAgICAgICAgICAgICAgICAgIAo+PiAgICAgICAgICBzd2l0Y2ggKGluZm8t
PmZvcm1hdCkgewo+PiAgICAgICAgICBjYXNlIERSTV9GT1JNQVRfWVVWNDIwXzhCSVQ6Cj4+ICAg
ICAgICAgICAgICAgICAgcmV0dXJuIDEyOwo+PiAgICAgICAgICBjYXNlIERSTV9GT1JNQVRfWVVW
NDIwXzEwQklUOgo+PiAgICAgICAgICAgICAgICAgIHJldHVybiAxNTsKPj4gICAgICAgICAgY2Fz
ZSBEUk1fRk9STUFUX1ZVWTEwMTAxMDoKPj4gICAgICAgICAgICAgICAgICByZXR1cm4gMzA7Cj4+
ICAgICAgICAgIGRlZmF1bHQ6Cj4+ICAgICAgICAgICAgICAgICAgcmV0dXJuIGRybV9mb3JtYXRf
aW5mb19icHAoaW5mbywgMCk7Cj4+ICAgICAgICAgIH0KPj4gfQo+Cj5TYW1lIHByb2JsZW0gaGVy
ZS4gVGhlc2UgWVVWIGZvcm1hdHMgYXJlIG11bHRpLXBsYW5hciBhbmQgdGhlcmUgc2hvdWxkIAo+
YmUgbm8gZHVtYiBidWZmZXJzIGZvciB0aGVtLgoKVGhlc2UgYWZiYyBiYXNlZCBmb3JtYXQgYXJl
IG9uZSBwbGFuZSwgc2VlOgoKLyoKICogMS1wbGFuZSBZVVYgNDoyOjAKICogSW4gdGhlc2UgZm9y
bWF0cywgdGhlIGNvbXBvbmVudCBvcmRlcmluZyBpcyBzcGVjaWZpZWQgKFksIGZvbGxvd2VkIGJ5
IFUKICogdGhlbiBWKSwgYnV0IHRoZSBleGFjdCBMaW5lYXIgbGF5b3V0IGlzIHVuZGVmaW5lZC4K
ICogVGhlc2UgZm9ybWF0cyBjYW4gb25seSBiZSB1c2VkIHdpdGggYSBub24tTGluZWFyIG1vZGlm
aWVyLgogKi8KI2RlZmluZSBEUk1fRk9STUFUX1lVVjQyMF84QklUICBmb3VyY2NfY29kZSgnWScs
ICdVJywgJzAnLCAnOCcpCiNkZWZpbmUgRFJNX0ZPUk1BVF9ZVVY0MjBfMTBCSVQgZm91cmNjX2Nv
ZGUoJ1knLCAnVScsICcxJywgJzAnKQoKPgo+QXMgd2Ugc3RpbGwgaGF2ZSB0byBzdXBwb3J0IHRo
ZXNlIGFsbCB1c2UgY2FzZXMsIEkndmUgbW9kaWZpZWQgdGhlIG5ldyAKPmhlbHBlciB0byBmYWxs
YmFjayB0byBjb21wdXRpbmcgdGhlIHBpdGNoIGZyb20gdGhlIGdpdmVuIGJwcCB2YWx1ZS4gCj5U
aGF0J3Mgd2hhdCBkcml2ZXJzIGN1cnJlbnRseSBkby4gQ291bGQgeW91IHBsZWFzZSBhcHBseSB0
aGUgYXR0YWNoZWQgCj5wYXRjaCBvbiB0b3Agb2YgdGhlIHNlcmllcyBhbmQgcmVwb3J0IGJhY2sg
dGhlIHJlc3VsdCBvZiB0aGUgdGVzdD8gWW91IAo+c2hvdWxkIHNlZSBhIGtlcm5lbCB3YXJuaW5n
IGFib3V0IHRoZSB1bmtub3duIGNvbG9yIG1vZGUsIGJ1dCBhbGxvY2F0aW9uIAo+c2hvdWxkIHN1
Y2NlZWQuCgpZZXMsIHRoZSBhdHRhY2hlZCBwYXRjaCB3b3JrcyBmb3IgbXkgdGVzdCBjYXNlLgoK
Pgo+QmVzdCByZWdhcmRzCj5UaG9tYXMKPgo+Pgo+Pgo+PiBbMF1odHRwczovL2dpdGxhYi5mcmVl
ZGVza3RvcC5vcmcvbWVzYS9kcm0vLS9ibG9iL21haW4vdGVzdHMvbW9kZXRlc3QvYnVmZmVycy5j
P3JlZl90eXBlPWhlYWRzI0wxNTkKPj4KPj4gVGhpcyBpbnRyb2R1Y2UgYSBtb2RldGVzdCBmYWls
dXJlIG9uIHJvY2tjaGlwIHBsYXRmb3JtOgo+PiAjIG1vZGV0ZXN0IC1NIHJvY2tjaGlwIC1zIDcw
QDY4OjE5MjB4MTA4MCAtUCAzMkA2ODoxOTIweDEwODBATlYzMAo+PiBzZXR0aW5nIG1vZGUgMTky
MHgxMDgwLTYwLjAwSHogb24gY29ubmVjdG9ycyA3MCwgY3J0YyA2OAo+PiB0ZXN0aW5nIDE5MjB4
MTA4MEBOVjMwIG92ZXJsYXkgcGxhbmUgMzIKPj4gZmFpbGVkIHRvIGNyZWF0ZSBkdW1iIGJ1ZmZl
cjogSW52YWxpZCBhcmd1bWVudAo+Pgo+PiBJIHRoaW5rIG90aGVyIHBsYXRmb3JtIHdpdGggYnBw
IGNhbid0IGhhbmRsZXIgYnkgIGRybV9tb2RlX2xlZ2FjeV9mYl9mb3JtYXQgd2lsbAo+PiBhbHNv
IHNlZSB0aGlzIGtpbmQgb2YgZmFpbHVyZToKPj4KPj4KPj4KPj4+ICsJaWYgKGZvdXJjYyA9PSBE
Uk1fRk9STUFUX0lOVkFMSUQpCj4+PiArCQlyZXR1cm4gLUVJTlZBTDsKPj4+ICsJaW5mbyA9IGRy
bV9mb3JtYXRfaW5mbyhmb3VyY2MpOwo+Pj4gKwlpZiAoIWluZm8pCj4+PiArCQlyZXR1cm4gLUVJ
TlZBTDsKPj4+ICsJcGl0Y2ggPSBkcm1fZm9ybWF0X2luZm9fbWluX3BpdGNoKGluZm8sIDAsIGFy
Z3MtPndpZHRoKTsKPj4+ICsJaWYgKCFwaXRjaCB8fCBwaXRjaCA+IFUzMl9NQVgpCj4+PiArCQly
ZXR1cm4gLUVJTlZBTDsKPj4+ICsKPj4+ICsJYXJncy0+cGl0Y2ggPSBwaXRjaDsKPj4+ICsKPj4+
ICsJcmV0dXJuIGRybV9tb2RlX2FsaWduX2R1bWIoYXJncywgcGl0Y2hfYWxpZ24sIHNpemVfYWxp
Z24pOwo+Pj4gK30KPj4+ICtFWFBPUlRfU1lNQk9MKGRybV9tb2RlX3NpemVfZHVtYik7Cj4+PiAr
Cj4+PiBpbnQgZHJtX21vZGVfY3JlYXRlX2R1bWIoc3RydWN0IGRybV9kZXZpY2UgKmRldiwKPj4+
IAkJCSBzdHJ1Y3QgZHJtX21vZGVfY3JlYXRlX2R1bWIgKmFyZ3MsCj4+PiAJCQkgc3RydWN0IGRy
bV9maWxlICpmaWxlX3ByaXYpCj4+PiBkaWZmIC0tZ2l0IGEvaW5jbHVkZS9kcm0vZHJtX2R1bWJf
YnVmZmVycy5oIGIvaW5jbHVkZS9kcm0vZHJtX2R1bWJfYnVmZmVycy5oCj4+PiBuZXcgZmlsZSBt
b2RlIDEwMDY0NAo+Pj4gaW5kZXggMDAwMDAwMDAwMDAwLi42ZmUzNjAwNGIxOWQKPj4+IC0tLSAv
ZGV2L251bGwKPj4+ICsrKyBiL2luY2x1ZGUvZHJtL2RybV9kdW1iX2J1ZmZlcnMuaAo+Pj4gQEAg
LTAsMCArMSwxNCBAQAo+Pj4gKy8qIFNQRFgtTGljZW5zZS1JZGVudGlmaWVyOiBNSVQgKi8KPj4+
ICsKPj4+ICsjaWZuZGVmIF9fRFJNX0RVTUJfQlVGRkVSU19IX18KPj4+ICsjZGVmaW5lIF9fRFJN
X0RVTUJfQlVGRkVSU19IX18KPj4+ICsKPj4+ICtzdHJ1Y3QgZHJtX2RldmljZTsKPj4+ICtzdHJ1
Y3QgZHJtX21vZGVfY3JlYXRlX2R1bWI7Cj4+PiArCj4+PiAraW50IGRybV9tb2RlX3NpemVfZHVt
YihzdHJ1Y3QgZHJtX2RldmljZSAqZGV2LAo+Pj4gKwkJICAgICAgIHN0cnVjdCBkcm1fbW9kZV9j
cmVhdGVfZHVtYiAqYXJncywKPj4+ICsJCSAgICAgICB1bnNpZ25lZCBsb25nIHBpdGNoX2FsaWdu
LAo+Pj4gKwkJICAgICAgIHVuc2lnbmVkIGxvbmcgc2l6ZV9hbGlnbik7Cj4+PiArCj4+PiArI2Vu
ZGlmCj4+PiAtLSAKPj4+IDIuNDcuMQo+Pj4KPj4+Cj4+PiBfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXwo+Pj4gTGludXgtcm9ja2NoaXAgbWFpbGluZyBsaXN0
Cj4+PiBMaW51eC1yb2NrY2hpcEBsaXN0cy5pbmZyYWRlYWQub3JnCj4+PiBodHRwOi8vbGlzdHMu
aW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LXJvY2tjaGlwCj4KPi0tIAo+LS0K
PlRob21hcyBaaW1tZXJtYW5uCj5HcmFwaGljcyBEcml2ZXIgRGV2ZWxvcGVyCj5TVVNFIFNvZnR3
YXJlIFNvbHV0aW9ucyBHZXJtYW55IEdtYkgKPkZyYW5rZW5zdHJhc3NlIDE0NiwgOTA0NjEgTnVl
cm5iZXJnLCBHZXJtYW55Cj5HRjogSXZvIFRvdGV2LCBBbmRyZXcgTXllcnMsIEFuZHJldyBNY0Rv
bmFsZCwgQm91ZGllbiBNb2VybWFuCj5IUkIgMzY4MDkgKEFHIE51ZXJuYmVyZykK


From xen-devel-bounces@lists.xenproject.org Mon Jan 13 07:17:40 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Jan 2025 07:17:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870430.1281617 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXEhR-00057S-F8; Mon, 13 Jan 2025 07:17:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870430.1281617; Mon, 13 Jan 2025 07:17:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXEhR-00057L-CM; Mon, 13 Jan 2025 07:17:25 +0000
Received: by outflank-mailman (input) for mailman id 870430;
 Mon, 13 Jan 2025 07:17:24 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=p1/W=UF=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tXEhQ-00057F-Mx
 for xen-devel@lists.xenproject.org; Mon, 13 Jan 2025 07:17:24 +0000
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com
 [2a00:1450:4864:20::42e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6e9f98b9-d17e-11ef-a0e1-8be0dac302b0;
 Mon, 13 Jan 2025 08:17:22 +0100 (CET)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-3862f32a33eso1656282f8f.3
 for <xen-devel@lists.xenproject.org>; Sun, 12 Jan 2025 23:17: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
 ffacd0b85a97d-38a8e384054sm11457941f8f.36.2025.01.12.23.17.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 12 Jan 2025 23:17:21 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 6e9f98b9-d17e-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736752642; x=1737357442; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=kzJR6nhn29MJlodNa0cV+GZpT2J7q/F8tz7co/MTkfU=;
        b=WuFK1CK/GcZXXgMIRY1eWMtXgag8txAXiQM/NL0wgJTNbIAn4YAmos1lJ8K6KoFene
         xjI0+DfbDvaz808CI75Pj8I6ctFpsff9plcTMbg8ZK6ENocDSEG/dGGN2qD8hInTOxdd
         EF7cQ4V70V/5nY+KSuYi36Ih5BuILdFwIrwcctthibdF84+t/wIzPHxmf97zT9VC5YWf
         s2KZ++DdjgxifjpoyAwkdVHi1LAGDMIATuOA2C14k7BRmDHxfaxBEiToezpyKPjnmN4X
         oKpdNXtDXIDQS2V52BPBYL7YTFYVsZTrJn3lk2CmBxM5DliucjG7x6IQ3VL7ZJNuR3fl
         8GSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736752642; x=1737357442;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=kzJR6nhn29MJlodNa0cV+GZpT2J7q/F8tz7co/MTkfU=;
        b=TaoOdqykY1BxBas7R0gnzUrFOR7iYhW8367K0fw8SgZGlY72AeaaURuTymwS/JPLH/
         nrziiRdYyY9psPT4p9iOF3ieqjQ3R4Tn5jlzjq+jqBzmrSRbcvDMhQa554HfF/GNHsJe
         E541KHzPi7MfKy+Li8KRmlQi3GGC09Z/p8XR02h8eLbbcNnoDWFtQQvjXAusNGcJG5qs
         WLhEgtCesBnGZ2tgD5Csv2fj4GngcHo6/yCEQxR/bEbSz9HPWDDv9581XCrZ3eyx57xs
         6NgHYBGbUv54XforNxshATo+2PMo5gwW6bCOaYZnX9WRWMC3A8hu252PwbZmr2iOA6QQ
         yC/A==
X-Forwarded-Encrypted: i=1; AJvYcCWY5hopuSpZZHjOdI36KdIF8kAHUd/1vnBjNxMerTDj8XFdiRU9Is11gHea+PRXV4FXJQfqIuc0/bQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwOqr1+dZeZcJvx0Yo1xHFCpwwShJIbusHRtviv/cHyPswKsJ4y
	b+nyaGOlKU8hqccFJCWh5f62vZNsClLBbzk+9JB2ZTSRKn+BPbvXleMqmxb8lg==
X-Gm-Gg: ASbGncsdHDvWqLZdVgKzkNg2ZAb7zNegfW+wlE7FTScbiq+m4hnoNzeviAi4OYWB2yK
	37oFh0pFOyYuVWMWB339mffAvjATleqzNMwHgQdc9nFnuHXXOLFemvjq880G3UPRttZiVfHN3F7
	gJOcBfQWpGZ5uGw0R538uhUfanU2srIzYVLNm1GHvUB5o/zJPDpH52BiN9ACAa6pgj4wTMTxIFz
	Wy1a4CW+cAj0wdSjAoP1M/Mar18+njzinnZkbQL32KCJfueFKMfNtpTWD+Mh2OKJFpXynQqmdxz
	iRz8fPRp/pXw5WwbHHlRFw62Hv4DpFenDzKOOr4sgg==
X-Google-Smtp-Source: AGHT+IEUtbDUyyxuiOe+vuQj6C+0PynMRMmjKBuA9gCbsMAb4ks3o3iel8VcQZlh+TPki2Q8kE5shw==
X-Received: by 2002:a5d:47a6:0:b0:385:f195:2a8 with SMTP id ffacd0b85a97d-38a87312734mr16348956f8f.30.1736752642022;
        Sun, 12 Jan 2025 23:17:22 -0800 (PST)
Message-ID: <28ad828a-0a9a-4637-bf55-59de2f731537@suse.com>
Date: Mon, 13 Jan 2025 08:17:23 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/3] xen/pci: do not register devices outside of PCI
 segment scope
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
 linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org
References: <20250110140152.27624-1-roger.pau@citrix.com>
 <20250110140152.27624-2-roger.pau@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250110140152.27624-2-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.01.2025 15:01, Roger Pau Monne wrote:
> The PCI segment value is limited to 16 bits, however there are buses like VMD
> that fake being part of the PCI topology by adding segment with a number
> outside the scope of the PCI firmware specification range (>= 0x10000). The
> MCFG ACPI Table "PCI Segment Group Number" field is defined as having a 16 bit
> width.
> 
> Attempting to register or manage those devices with Xen would result in errors
> at best, or overlaps with existing devices living on the truncated equivalent
> segment values.
> 
> Skip notifying Xen about those devices.

Hmm, is simply omitting the notification really all it takes? How would Xen
manage MSI / MSI-X, for example, without knowing of the device? As per the
BoF on the summit in Prague(?), I continue to think we need partial driver
logic in Xen for VMD ...

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 13 07:20:36 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Jan 2025 07:20:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870438.1281627 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXEkV-0006kw-Sh; Mon, 13 Jan 2025 07:20:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870438.1281627; Mon, 13 Jan 2025 07:20:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXEkV-0006kp-QA; Mon, 13 Jan 2025 07:20:35 +0000
Received: by outflank-mailman (input) for mailman id 870438;
 Mon, 13 Jan 2025 07:20:35 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=p1/W=UF=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tXEkV-0006kh-2Y
 for xen-devel@lists.xenproject.org; Mon, 13 Jan 2025 07:20:35 +0000
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com
 [2a00:1450:4864:20::336])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id dfb7e36d-d17e-11ef-99a4-01e77a169b0f;
 Mon, 13 Jan 2025 08:20:32 +0100 (CET)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-436281c8a38so27373975e9.3
 for <xen-devel@lists.xenproject.org>; Sun, 12 Jan 2025 23:20:32 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436e2e92dc4sm167300385e9.39.2025.01.12.23.20.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 12 Jan 2025 23:20:31 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: dfb7e36d-d17e-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736752832; x=1737357632; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=1SDKKN4HmdNIWYqyaibttvrx4Bo3thegKgI3FwzuVQ4=;
        b=XCLro7xIrtpyoPghNGIv4jK6IK1hXWw/+3bAHTIC5v7QkcjB7yKtpzVQ8FIh23E4NU
         Hshzv5B3kdEDfAwEfHq//rmtgHNVx0EUea7+OpEPPMBpokrc3zJGSsfWTs5AUZYMBKXs
         Zyr2DNItwc1U4Ir5RPF6HVqMP3pAd4NmbWBv6TcZr3/oA1wszSe1oM+9G18R1GLuWFOO
         iq+kITsijI1z5yBccYEn2SwVUrEOpQSX6hPRBPDfKG9q2JyQ6rjGDM93A+ZNVUTTzk3x
         /NFv8aRJl3ZHZbYGoZ0XcuGoJfxp1IHKOUF957+RX3kdChej9i7Pp8JZZkYP2lQ0c0Yq
         qbrg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736752832; x=1737357632;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=1SDKKN4HmdNIWYqyaibttvrx4Bo3thegKgI3FwzuVQ4=;
        b=PDq3kcQliFvQ1VKkJ4DV+4SFcq2MKa17h0TJoY1xwqaR1lTptCLAAoGLxC/gX9HvQo
         vXwTK+xszx5wBy/bwZanuQmk68pyZWjZRTvJPUkswMQUZUU0MUlqfdU5y9yQ2lY4LuLM
         ZY0Bc5cTBEc0+4P9X+vjytaZrLgm3oaxUX9uuuGchhh15r6dGHUlv1Jm/d3prYeFj3Aj
         eP2rYlWVM+YczDZAIK5bz9ONmPX5s0zVtQAQiQLiJVb7T9DGmujeu1RkEzSAsyRYjGpY
         jB7y1wF/K4Y00r6oHfOxR5lnwhIf55othBPm/dgG3mkXMp0MuG/YAJ+V7Lw7HApEW6v3
         BcIw==
X-Forwarded-Encrypted: i=1; AJvYcCWEr6NY7PwA2C6n9RBAyoz1v8PEm1GMnbzhDKW2IEv3eyft0n/HJzhygZN+ljphNr+0382snPNtGDw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzjjt7zF3R68zlKLHkD7XRFmbe5YuF9IODIkPbiMs/M8ZpHwZIY
	ZhOUi1Apry1rRa8cbAcqivZ775Pb4UMioU57Sv3tDdbDgs91Snm8WWdFhJTmWg==
X-Gm-Gg: ASbGnctxazssq9pOJ0Z/8J/p0u+FQh1ofuqFj5F9xvG7XkxoL/WlJ1Y93FkrdSR0sog
	1WtUqya+aKAAwdWbWBlBmbMUM8iGevU6H37StofOAT8Xr1EUWBbHKMUCszNfDpGqUCaTZGa22iP
	RKeYuKJM8Hl0Xxl7Hu3W8YxF84vy6h8LRUonF5ZA44IFJu83Xia2Hjlkw5jGXAEbJZ7heLVYKe8
	nyEGwqUdP8ha2JBRtW2zZoMcAZ/QDjH9jVJZg72QEPe5GhOqXZs3bwF44qvR+kizJs8VE6TFI6u
	Ee4TDIn3mxN2/NsumH4cAqEUijmWdZniYW10JebdRg==
X-Google-Smtp-Source: AGHT+IH43ppTcJvK46N0WR/AhbN+4+NAtYpn93VBtAvkvsnsz55xa2QYKfB1B7SiqmhmGwePow6L2A==
X-Received: by 2002:a05:600c:3149:b0:434:9fac:b158 with SMTP id 5b1f17b1804b1-436e2680c4amr144180955e9.1.1736752831667;
        Sun, 12 Jan 2025 23:20:31 -0800 (PST)
Message-ID: <d055ed99-8b27-4ff3-af6e-fe66d2f01708@suse.com>
Date: Mon, 13 Jan 2025 08:20:32 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/3] xen/pci: do not register devices outside of PCI
 segment scope
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
 Juergen Gross <jgross@suse.com>, Stefano Stabellini
 <sstabellini@kernel.org>,
 Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
 Roger Pau Monne <roger.pau@citrix.com>
References: <20250110222129.GA317771@bhelgaas>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250110222129.GA317771@bhelgaas>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.01.2025 23:21, Bjorn Helgaas wrote:
> On Fri, Jan 10, 2025 at 03:01:48PM +0100, Roger Pau Monne wrote:
>> The PCI segment value is limited to 16 bits, however there are buses like VMD
>> that fake being part of the PCI topology by adding segment with a number
>> outside the scope of the PCI firmware specification range (>= 0x10000). The
>> MCFG ACPI Table "PCI Segment Group Number" field is defined as having a 16 bit
>> width.
>>
>> Attempting to register or manage those devices with Xen would result in errors
>> at best, or overlaps with existing devices living on the truncated equivalent
>> segment values.
> 
> The ACPI _SEG method (ACPI r6.5, sec 6.5.6) and the corresponding
> value in the MCFG table (PCI Firmware r3.3, sec 4.1.2) are clearly
> 16-bit values.
> 
> But otherwise, the segment value is pretty much an arbitrary software
> value, and the kernel works fine with the larger domain values from
> vmd_find_free_domain(), so this isn't quite enough to explain what the
> issue with Xen is.
> 
> Does Xen truncate the domain to 16 bits or use it to look up something
> in ACPI?

One of the involved public interface structs starts like this:

struct physdev_pci_device_add {
    /* IN */
    uint16_t seg;
    uint8_t bus;
    uint8_t devfn;
    ...

So yes, wider segment values would be truncated. Plus, even if they weren't,
there would need to be coordination between Dom0 and Xen on which devices
gets which segment number, since - as you say - the assignment in Linux is
pretty much arbitrary.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 13 07:52:16 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Jan 2025 07:52:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870454.1281638 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXFF2-0002fB-VQ; Mon, 13 Jan 2025 07:52:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870454.1281638; Mon, 13 Jan 2025 07:52:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXFF2-0002f4-Sn; Mon, 13 Jan 2025 07:52:08 +0000
Received: by outflank-mailman (input) for mailman id 870454;
 Mon, 13 Jan 2025 07:52:07 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=5MxW=UF=suse.de=tzimmermann@srs-se1.protection.inumbo.net>)
 id 1tXFF1-0002ey-DO
 for xen-devel@lists.xenproject.org; Mon, 13 Jan 2025 07:52:07 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4803fe6d-d183-11ef-99a4-01e77a169b0f;
 Mon, 13 Jan 2025 08:52:05 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id A63632116C;
 Mon, 13 Jan 2025 07:52:04 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 320C113310;
 Mon, 13 Jan 2025 07:52:04 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id myLrCiTGhGcsNgAAD6G6ig
 (envelope-from <tzimmermann@suse.de>); Mon, 13 Jan 2025 07:52:04 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 4803fe6d-d183-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736754724; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=ej5S2FqsrLfl2DOy4vNFP4EEenMuOKkjeg5fw8+ryy8=;
	b=UGec6fOBbSuM5/YwhFmAlt57APKx49vUpyhM2dXq1qgH2DoUQhtCvTHDVkyM651h37cY2Q
	uD4kKgyMcjO1ejhDqihQZvOXJQHXYign5PDQ9q3y7owQZu1PjY3kMxXXe+u58a/fXQOt4G
	aR9MrTbpgoH33QqMdIkoQeIltEIWK0E=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736754724;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=ej5S2FqsrLfl2DOy4vNFP4EEenMuOKkjeg5fw8+ryy8=;
	b=wOUzlPapnGL4hQxyY/3aso3HpttkWYzvxJpGlSsgxagHXECdZeo0Rlkl3bAbpwoe5tO7D/
	0F0cjrpaEuMdmxCw==
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736754724; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=ej5S2FqsrLfl2DOy4vNFP4EEenMuOKkjeg5fw8+ryy8=;
	b=UGec6fOBbSuM5/YwhFmAlt57APKx49vUpyhM2dXq1qgH2DoUQhtCvTHDVkyM651h37cY2Q
	uD4kKgyMcjO1ejhDqihQZvOXJQHXYign5PDQ9q3y7owQZu1PjY3kMxXXe+u58a/fXQOt4G
	aR9MrTbpgoH33QqMdIkoQeIltEIWK0E=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736754724;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=ej5S2FqsrLfl2DOy4vNFP4EEenMuOKkjeg5fw8+ryy8=;
	b=wOUzlPapnGL4hQxyY/3aso3HpttkWYzvxJpGlSsgxagHXECdZeo0Rlkl3bAbpwoe5tO7D/
	0F0cjrpaEuMdmxCw==
Message-ID: <44f1170e-ad76-4dae-abae-986b5482dfc6@suse.de>
Date: Mon, 13 Jan 2025 08:52:03 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 02/25] drm/dumb-buffers: Provide helper to set pitch
 and size
To: Andy Yan <andyshrk@163.com>
Cc: maarten.lankhorst@linux.intel.com, mripard@kernel.org, airlied@gmail.com,
 simona@ffwll.ch, dri-devel@lists.freedesktop.org,
 linux-mediatek@lists.infradead.org, freedreno@lists.freedesktop.org,
 linux-arm-msm@vger.kernel.org, imx@lists.linux.dev,
 linux-samsung-soc@vger.kernel.org, nouveau@lists.freedesktop.org,
 virtualization@lists.linux.dev, spice-devel@lists.freedesktop.org,
 linux-renesas-soc@vger.kernel.org, linux-rockchip@lists.infradead.org,
 linux-tegra@vger.kernel.org, intel-xe@lists.freedesktop.org,
 xen-devel@lists.xenproject.org
References: <20250109150310.219442-1-tzimmermann@suse.de>
 <20250109150310.219442-3-tzimmermann@suse.de>
 <94f78e1.19bf.1944de709b0.Coremail.andyshrk@163.com>
 <e800ebc2-39b5-46d5-89ec-883ed1c7626b@suse.de>
 <443491d4.4087.1945dcc04e3.Coremail.andyshrk@163.com>
Content-Language: en-US
From: Thomas Zimmermann <tzimmermann@suse.de>
Autocrypt: addr=tzimmermann@suse.de; keydata=
 xsBNBFs50uABCADEHPidWt974CaxBVbrIBwqcq/WURinJ3+2WlIrKWspiP83vfZKaXhFYsdg
 XH47fDVbPPj+d6tQrw5lPQCyqjwrCPYnq3WlIBnGPJ4/jreTL6V+qfKRDlGLWFjZcsrPJGE0
 BeB5BbqP5erN1qylK9i3gPoQjXGhpBpQYwRrEyQyjuvk+Ev0K1Jc5tVDeJAuau3TGNgah4Yc
 hdHm3bkPjz9EErV85RwvImQ1dptvx6s7xzwXTgGAsaYZsL8WCwDaTuqFa1d1jjlaxg6+tZsB
 9GluwvIhSezPgnEmimZDkGnZRRSFiGP8yjqTjjWuf0bSj5rUnTGiyLyRZRNGcXmu6hjlABEB
 AAHNJ1Rob21hcyBaaW1tZXJtYW5uIDx0emltbWVybWFubkBzdXNlLmRlPsLAjgQTAQgAOAIb
 AwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftODH
 AAoJEGgNwR1TC3ojx1wH/0hKGWugiqDgLNXLRD/4TfHBEKmxIrmfu9Z5t7vwUKfwhFL6hqvo
 lXPJJKQpQ2z8+X2vZm/slsLn7J1yjrOsoJhKABDi+3QWWSGkaGwRJAdPVVyJMfJRNNNIKwVb
 U6B1BkX2XDKDGffF4TxlOpSQzdtNI/9gleOoUA8+jy8knnDYzjBNOZqLG2FuTdicBXblz0Mf
 vg41gd9kCwYXDnD91rJU8tzylXv03E75NCaTxTM+FBXPmsAVYQ4GYhhgFt8S2UWMoaaABLDe
 7l5FdnLdDEcbmd8uLU2CaG4W2cLrUaI4jz2XbkcPQkqTQ3EB67hYkjiEE6Zy3ggOitiQGcqp
 j//OwE0EWznS4AEIAMYmP4M/V+T5RY5at/g7rUdNsLhWv1APYrh9RQefODYHrNRHUE9eosYb
 T6XMryR9hT8XlGOYRwKWwiQBoWSDiTMo/Xi29jUnn4BXfI2px2DTXwc22LKtLAgTRjP+qbU6
 3Y0xnQN29UGDbYgyyK51DW3H0If2a3JNsheAAK+Xc9baj0LGIc8T9uiEWHBnCH+RdhgATnWW
 GKdDegUR5BkDfDg5O/FISymJBHx2Dyoklv5g4BzkgqTqwmaYzsl8UxZKvbaxq0zbehDda8lv
 hFXodNFMAgTLJlLuDYOGLK2AwbrS3Sp0AEbkpdJBb44qVlGm5bApZouHeJ/+n+7r12+lqdsA
 EQEAAcLAdgQYAQgAIAIbDBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftOH6AAoJEGgNwR1T
 C3ojVSkIALpAPkIJPQoURPb1VWjh34l0HlglmYHvZszJWTXYwavHR8+k6Baa6H7ufXNQtThR
 yIxJrQLW6rV5lm7TjhffEhxVCn37+cg0zZ3j7zIsSS0rx/aMwi6VhFJA5hfn3T0TtrijKP4A
 SAQO9xD1Zk9/61JWk8OysuIh7MXkl0fxbRKWE93XeQBhIJHQfnc+YBLprdnxR446Sh8Wn/2D
 Ya8cavuWf2zrB6cZurs048xe0UbSW5AOSo4V9M0jzYI4nZqTmPxYyXbm30Kvmz0rYVRaitYJ
 4kyYYMhuULvrJDMjZRvaNe52tkKAvMevcGdt38H4KSVXAylqyQOW5zvPc4/sq9c=
In-Reply-To: <443491d4.4087.1945dcc04e3.Coremail.andyshrk@163.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Level: 
X-Spamd-Result: default: False [-2.80 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.20)[-0.999];
	MIME_GOOD(-0.10)[text/plain];
	FREEMAIL_TO(0.00)[163.com];
	RCPT_COUNT_TWELVE(0.00)[19];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_ALL(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	FREEMAIL_ENVRCPT(0.00)[163.com,gmail.com];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	FROM_HAS_DN(0.00)[];
	FREEMAIL_CC(0.00)[linux.intel.com,kernel.org,gmail.com,ffwll.ch,lists.freedesktop.org,lists.infradead.org,vger.kernel.org,lists.linux.dev,lists.xenproject.org];
	TO_DN_SOME(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,suse.de:mid]
X-Spam-Score: -2.80
X-Spam-Flag: NO

Hi


Am 13.01.25 um 04:53 schrieb Andy Yan:
[...]
>> Thanks for taking a look. That NV-related code at [0] is a 'somewhat
>> non-idiomatic use' of the UAPI. The dumb-buffer interface really just
>> supports a single plane. The fix would be a new ioctl that takes a DRM
>> 4cc constant and returns a buffer handle/pitch/size for each plane. But
>> that's separate series throughout the various components.
> So is there a standard way to create buffer for NV-related format now ?

I don't know, but it doesn't look like there is. As I outlined, a new 
dumb-buffer interface seems required.

> With a quick search, I can see many user space use dumb-buffer for NV-releated
> buffer alloc:
>
> [0]https://github.com/tomba/kmsxx/blob/master/kms%2B%2B/src/pixelformats.cpp
> [1]https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/blob/master/lib/igt_fb.c?ref_type=heads
> [2]https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-bad/sys/kms/gstkmsutils.c?ref_type=heads#L116
>
>> There's also code XRGB16161616F. This is a viable format for the UAPI,
>> but seems not very useful in practice.
>>
>>> And there are also some AFBC based format with bpp can't be handled here, see:
>>> static __u32 drm_gem_afbc_get_bpp(struct drm_device *dev,
>>>                                     const struct drm_mode_fb_cmd2 *mode_cmd)
>>> {
>>>           const struct drm_format_info *info;
>>>                   
>>>           info = drm_get_format_info(dev, mode_cmd);
>>>                   
>>>           switch (info->format) {
>>>           case DRM_FORMAT_YUV420_8BIT:
>>>                   return 12;
>>>           case DRM_FORMAT_YUV420_10BIT:
>>>                   return 15;
>>>           case DRM_FORMAT_VUY101010:
>>>                   return 30;
>>>           default:
>>>                   return drm_format_info_bpp(info, 0);
>>>           }
>>> }
>> Same problem here. These YUV formats are multi-planar and there should
>> be no dumb buffers for them.
> These afbc based format are one plane, see:

Apologies. I confused them with other YUV formats.

>
> /*
>   * 1-plane YUV 4:2:0
>   * In these formats, the component ordering is specified (Y, followed by U
>   * then V), but the exact Linear layout is undefined.
>   * These formats can only be used with a non-Linear modifier.
>   */
> #define DRM_FORMAT_YUV420_8BIT  fourcc_code('Y', 'U', '0', '8')
> #define DRM_FORMAT_YUV420_10BIT fourcc_code('Y', 'U', '1', '0')
>
>> As we still have to support these all use cases, I've modified the new
>> helper to fallback to computing the pitch from the given bpp value.
>> That's what drivers currently do. Could you please apply the attached
>> patch on top of the series and report back the result of the test? You
>> should see a kernel warning about the unknown color mode, but allocation
>> should succeed.
> Yes, the attached patch works for my test case.

Thanks for testing. I'll include the changes in the patch' next iteration.

Best regards
Thomas

>
>> Best regards
>> Thomas
>>
>>>
>>> [0]https://gitlab.freedesktop.org/mesa/drm/-/blob/main/tests/modetest/buffers.c?ref_type=heads#L159
>>>
>>> This introduce a modetest failure on rockchip platform:
>>> # modetest -M rockchip -s 70@68:1920x1080 -P 32@68:1920x1080@NV30
>>> setting mode 1920x1080-60.00Hz on connectors 70, crtc 68
>>> testing 1920x1080@NV30 overlay plane 32
>>> failed to create dumb buffer: Invalid argument
>>>
>>> I think other platform with bpp can't handler by  drm_mode_legacy_fb_format will
>>> also see this kind of failure:
>>>
>>>
>>>
>>>> +	if (fourcc == DRM_FORMAT_INVALID)
>>>> +		return -EINVAL;
>>>> +	info = drm_format_info(fourcc);
>>>> +	if (!info)
>>>> +		return -EINVAL;
>>>> +	pitch = drm_format_info_min_pitch(info, 0, args->width);
>>>> +	if (!pitch || pitch > U32_MAX)
>>>> +		return -EINVAL;
>>>> +
>>>> +	args->pitch = pitch;
>>>> +
>>>> +	return drm_mode_align_dumb(args, pitch_align, size_align);
>>>> +}
>>>> +EXPORT_SYMBOL(drm_mode_size_dumb);
>>>> +
>>>> int drm_mode_create_dumb(struct drm_device *dev,
>>>> 			 struct drm_mode_create_dumb *args,
>>>> 			 struct drm_file *file_priv)
>>>> diff --git a/include/drm/drm_dumb_buffers.h b/include/drm/drm_dumb_buffers.h
>>>> new file mode 100644
>>>> index 000000000000..6fe36004b19d
>>>> --- /dev/null
>>>> +++ b/include/drm/drm_dumb_buffers.h
>>>> @@ -0,0 +1,14 @@
>>>> +/* SPDX-License-Identifier: MIT */
>>>> +
>>>> +#ifndef __DRM_DUMB_BUFFERS_H__
>>>> +#define __DRM_DUMB_BUFFERS_H__
>>>> +
>>>> +struct drm_device;
>>>> +struct drm_mode_create_dumb;
>>>> +
>>>> +int drm_mode_size_dumb(struct drm_device *dev,
>>>> +		       struct drm_mode_create_dumb *args,
>>>> +		       unsigned long pitch_align,
>>>> +		       unsigned long size_align);
>>>> +
>>>> +#endif
>>>> -- 
>>>> 2.47.1
>>>>
>>>>
>>>> _______________________________________________
>>>> Linux-rockchip mailing list
>>>> Linux-rockchip@lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>> -- 
>> --
>> Thomas Zimmermann
>> Graphics Driver Developer
>> SUSE Software Solutions Germany GmbH
>> Frankenstrasse 146, 90461 Nuernberg, Germany
>> GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
>> HRB 36809 (AG Nuernberg)

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)



From xen-devel-bounces@lists.xenproject.org Mon Jan 13 08:25:31 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Jan 2025 08:25:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870468.1281647 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXFl6-0007gw-BV; Mon, 13 Jan 2025 08:25:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870468.1281647; Mon, 13 Jan 2025 08:25:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXFl6-0007gp-8i; Mon, 13 Jan 2025 08:25:16 +0000
Received: by outflank-mailman (input) for mailman id 870468;
 Mon, 13 Jan 2025 08:25: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
 <SRS0=6oLm=UF=linaro.org=dmitry.baryshkov@srs-se1.protection.inumbo.net>)
 id 1tXFl4-0007gh-R6
 for xen-devel@lists.xenproject.org; Mon, 13 Jan 2025 08:25:15 +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 e8fc0850-d187-11ef-a0e1-8be0dac302b0;
 Mon, 13 Jan 2025 09:25:13 +0100 (CET)
Received: by mail-lf1-x132.google.com with SMTP id
 2adb3069b0e04-5401bd6cdb4so3753548e87.2
 for <xen-devel@lists.xenproject.org>; Mon, 13 Jan 2025 00:25:13 -0800 (PST)
Received: from eriador.lumag.spb.ru
 (2001-14ba-a0c3-3a00--b8c.rev.dnainternet.fi. [2001:14ba:a0c3:3a00::b8c])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5428bec0659sm1286326e87.185.2025.01.13.00.25.11
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 13 Jan 2025 00:25:11 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e8fc0850-d187-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1736756713; x=1737361513; 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=HsOOejTFjVwFwvDCfWyTG69OVT7YoO10LJVJy5N++GA=;
        b=iagtDUSXNw1Q7e1mnXCIJzDIMunFrPSvMkEP4W6KHvqDDCQJs2KcU7D6TcJFsLR6jR
         NeucQIKHJfg+GnJQ4PjbVhEqtmatP7Pk1NAszmc/L0eLRl/sqpckUkohOr8Amo4uvzNw
         NxswZYBVtu433/tMJILhVh0Qe55+p83wK6jZTt8A0OS1Kxu0xIXkumHL53We2nGDSqYQ
         jMLUpjwnoUKkzlVNYIN2bf6gRAY8beD0XQ8lhBBBxz9m+bybCbI/5SSWrv2cH7g7YAkg
         JgoOi+5iT8UacMcA+yPGdNNNsyudFnmmoFmpavFh46X+NFswY7eRFny2I+ezQm6v1Vz+
         Kg/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736756713; x=1737361513;
        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=HsOOejTFjVwFwvDCfWyTG69OVT7YoO10LJVJy5N++GA=;
        b=WX7FLrLu0006ZeU8oF6GdrDWq0K5kk1IgoPoGoxcVA4tSk2O2Jmpcms//XhAm891jC
         1a3Yw93htgBImsSSFOdkxgVaSwA/SluTwxIUxJpHdNc1NDSu3kQO1zuzQhaUNMvnPHJX
         dy3aubsyqTlQpzcyXW+0fFfur1bO0vxERcBGLbvFD/PfULXpZ4RkZLpXkZzxH0YOrS87
         lPDv//ZRm7r597BTUvoasTpfQwXAOx9ewB7kxzUxuEDnsmX/4spSyJuPlo1NYvuTxS9t
         vYbIPmbbbfC3iGb343A1Md2F9u3PqqOz591IXJD6Wtb49uVm1txJqsUdj1ILPpEliYo2
         FtmQ==
X-Forwarded-Encrypted: i=1; AJvYcCXQt0ZXw8tcxKj0trCKW3qvBa+Qc1GHX7PhNfiSziD5ziil3noSYXXZDId1KmfXiajx0mjbanRkob8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YykY/dotjauv662MmNcbnxRmlEwZv4a5yAWSPb6XBIw3dm1ANW+
	ryfKjL+EQpUllPsKJWKtzYVRL7zklKc2A+rLoIEdtLZHkAOHqPUtLVtGCEBTX58=
X-Gm-Gg: ASbGncs9Z/bB3/8p7GGW9E3EkNUSyjIrYTE3ihVlsqaH5ybwUR5LU8bZHNw1WFY+J/C
	gFGHbtTFLb9r7uXhsSYGYVoOdvD/eRDLbhehCr7uWIL4cBwXnglz2c9EaqFe/KSR9OpXfpPlwUG
	UppUptludBj5BuQ+K/2Bf7NA/Q1W3Izgnxzjpwl753H3ywyaIlTCzWjiAr6j1UDhyVaIIQ8GLtV
	ECSHxLs2kJAP2r/2lOLMLtkfpcG8mcTPQM85JpQU4ogJE4Sv3tK8nKocCrgxFy/ps65Qk6cFccg
	0OHPCg9nam5fx2KekvvPsngeszAZGdQ1xVx5
X-Google-Smtp-Source: AGHT+IERZWZtkZrsbkHThnFiBHKfz//tsYW/urMLTgJODZNi9Tp473Grr1NqQ4M0NySCRCOoV5n3Rw==
X-Received: by 2002:a05:6512:138c:b0:540:2188:763c with SMTP id 2adb3069b0e04-542845b0b55mr6338144e87.37.1736756712614;
        Mon, 13 Jan 2025 00:25:12 -0800 (PST)
Date: Mon, 13 Jan 2025 10:25:09 +0200
From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
To: Thomas Zimmermann <tzimmermann@suse.de>
Cc: maarten.lankhorst@linux.intel.com, mripard@kernel.org, 
	airlied@gmail.com, simona@ffwll.ch, dri-devel@lists.freedesktop.org, 
	linux-mediatek@lists.infradead.org, freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org, 
	imx@lists.linux.dev, linux-samsung-soc@vger.kernel.org, nouveau@lists.freedesktop.org, 
	virtualization@lists.linux.dev, spice-devel@lists.freedesktop.org, 
	linux-renesas-soc@vger.kernel.org, linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org, 
	intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org, Rob Clark <robdclark@gmail.com>, 
	Abhinav Kumar <quic_abhinavk@quicinc.com>, Sean Paul <sean@poorly.run>, 
	Marijn Suijten <marijn.suijten@somainline.org>
Subject: Re: [PATCH v2 13/25] drm/msm: Compute dumb-buffer sizes with
 drm_mode_size_dumb()
Message-ID: <bbw2n4ccn5jlq7q7lsw3xdnbieazgexkwkycrqvk5aoiq5q3wx@nz6gd3unwkg4>
References: <20250109150310.219442-1-tzimmermann@suse.de>
 <20250109150310.219442-14-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250109150310.219442-14-tzimmermann@suse.de>

On Thu, Jan 09, 2025 at 03:57:07PM +0100, Thomas Zimmermann wrote:
> Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
> buffer size. The hardware requires the scnaline pitch to be a multiple
> of 32 pixels. Therefore compute the byte size of 32 pixels in the given
> color mode and align the pitch accordingly.

- scanline, not scnaline
- the statement about 32-pixel alignment needs an explanation that it is
  being currently handled by align_pitch().

With that in mind:

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Rob Clark <robdclark@gmail.com>
> Cc: Abhinav Kumar <quic_abhinavk@quicinc.com>
> Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> Cc: Sean Paul <sean@poorly.run>
> Cc: Marijn Suijten <marijn.suijten@somainline.org>
> ---
>  drivers/gpu/drm/msm/msm_gem.c | 27 +++++++++++++++++++++++++--
>  1 file changed, 25 insertions(+), 2 deletions(-)
> 

-- 
With best wishes
Dmitry


From xen-devel-bounces@lists.xenproject.org Mon Jan 13 10:04:19 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Jan 2025 10:04:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870480.1281658 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXHIj-0003nO-41; Mon, 13 Jan 2025 10:04:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870480.1281658; Mon, 13 Jan 2025 10:04:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXHIj-0003nH-17; Mon, 13 Jan 2025 10:04:05 +0000
Received: by outflank-mailman (input) for mailman id 870480;
 Mon, 13 Jan 2025 10:04:03 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=3HK6=UF=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tXHIh-0003nB-Dg
 for xen-devel@lists.xenproject.org; Mon, 13 Jan 2025 10:04:03 +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 b6b4a684-d195-11ef-a0e1-8be0dac302b0;
 Mon, 13 Jan 2025 11:04:01 +0100 (CET)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-5d7e3f1fc01so8263774a12.2
 for <xen-devel@lists.xenproject.org>; Mon, 13 Jan 2025 02:04:01 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c90d9b19sm474988566b.73.2025.01.13.02.03.59
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 13 Jan 2025 02:03:59 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b6b4a684-d195-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736762641; x=1737367441; 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=NAozgVCwe5MTkDq2tRs81RaOUpNYbkuEcwNQ118VObQ=;
        b=BgfHzj7HyluC0vOZGvybgOYkvYCvvWYhX5rFlkzSq/P0QmMDjFm22DnPfIC2keJb57
         Z3WvBSAPj2tNDMk33PxFaIUaR8xjOYuR179UWL1+oCVSwyebwQiKf7ktghSlpgQjvTMY
         rCewtd27S6eKqVefRi57wU09PUqKoD3paQT3k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736762641; x=1737367441;
        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=NAozgVCwe5MTkDq2tRs81RaOUpNYbkuEcwNQ118VObQ=;
        b=p4nhHqF3xeKIt7oBh6VV41MLw3JAH1FwAy+6kXShKd9aaOzSvn067Bvxuck5Rxov1S
         rp1sKH6um7nGPcrdSTfZc/peUDkIYjmPSoJdTJWVN7sN/QY4JcuoLO5sGXYnBaxpuhlv
         8k6ATSr37GRkzw2GJMYesTnMNunJVrl5bPxcka4fS5yIHFMdWulV93+8U55NQME/rEgi
         gM5ciHt55/jKa1i7pXbKwYnTcPIw/j5mpgwZ5pEmA/8oTtSJ2RhhPH2v9Dzf0FINFREL
         CSdcmaRj69Z0ziO/R0wmMOfAUmmBORAobr2VMdOJGrUcNn9+xA90BMUm3WZMyd4/zwPV
         rqMA==
X-Forwarded-Encrypted: i=1; AJvYcCWIdZ0rU087rEGNFJoj6rNYEEDRxUTpgWxXWs3K8+X9ET7dnJ4V+FfDEQ+DZ2zhizh2euMejZAJicc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwxEX5SbieEGj3fJTNz2xlZz1sWZCuGKFgVCZqPlm4PuDgVr0Of
	e5QbsFex2VGcFEvf59Xq4MXRFQNE7XesQggQeCWxzxaf3W/pbbbh3yukWasBjfg=
X-Gm-Gg: ASbGncu8szGXDO1Yv+B2WtvgraYK9PW/WwL7KtMXSUplWYhoBe5bk192Q/D9lX+YEFG
	2DU21if5YGzWGILQpJnJ2D6z0KBuiFgNvGknoDCo/WIWiejjX/UxUrj2nnGIPkolKp7+YBT5qFe
	+snHrfIyYLrT6rHNDtwL6tFlD8QXx1HoYALjNG3rocn0IhZjsSG4ITrfrnwC6C2gwy1cgL/WjLq
	tE5eO3kQY4T9Wc4bYFTqF4uMssBTQg6rLfc9IiOUYRpschTfiO4bPY+wJP1XQ==
X-Google-Smtp-Source: AGHT+IHN6cLAzIHvJBapqtn9TCnnP24m5RjiZPdKHg1bO2RsIgvurTxekJiYNBk5q8SmCTsIwdMt3A==
X-Received: by 2002:a17:907:60cf:b0:aa6:88f5:5fef with SMTP id a640c23a62f3a-ab2ab6fb426mr1905306566b.32.1736762641198;
        Mon, 13 Jan 2025 02:04:01 -0800 (PST)
Date: Mon, 13 Jan 2025 11:03:58 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
	linux-pci@vger.kernel.org,
	Nirmal Patel <nirmal.patel@linux.intel.com>,
	Jonathan Derrick <jonathan.derrick@linux.dev>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= <kw@linux.com>,
	Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
	Rob Herring <robh@kernel.org>, Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [PATCH 2/3] vmd: disable MSI remapping bypass under Xen
Message-ID: <Z4TlDhBNn8TMipdB@macbook.local>
References: <20250110140152.27624-3-roger.pau@citrix.com>
 <20250110222525.GA318386@bhelgaas>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250110222525.GA318386@bhelgaas>

On Fri, Jan 10, 2025 at 04:25:25PM -0600, Bjorn Helgaas wrote:
> Match historical subject line style for prefix and capitalization:
> 
>   PCI: vmd: Set devices to D0 before enabling PM L1 Substates
>   PCI: vmd: Add DID 8086:B06F and 8086:B60B for Intel client SKUs
>   PCI: vmd: Fix indentation issue in vmd_shutdown()
> 
> On Fri, Jan 10, 2025 at 03:01:49PM +0100, Roger Pau Monne wrote:
> > MSI remapping bypass (directly configuring MSI entries for devices on the VMD
> > bus) won't work under Xen, as Xen is not aware of devices in such bus, and
> > hence cannot configure the entries using the pIRQ interface in the PV case, and
> > in the PVH case traps won't be setup for MSI entries for such devices.
> > 
> > Until Xen is aware of devices in the VMD bus prevent the
> > VMD_FEAT_CAN_BYPASS_MSI_REMAP capability from being used when running as any
> > kind of Xen guest.
> 
> Wrap to fit in 75 columns.

Hm, OK, but isn't the limit 80 columns according to the kernel coding
style (Documentation/process/coding-style.rst)?

I don't mind adjusting, but if you are going to ask every submitter to
limit to 75 columns then the coding style document should be updated
to reflect that.

> Can you include a hint about *why* Xen is not aware of devices below
> VMD?  That will help to know whether it's a permanent unfixable
> situation or something that could be done eventually.

Xen would need to be made aware of the devices exposed behind the VMD
bridge, so it can manage them.  For example Xen is the entity that
controls the local APICs, and hence interrupts must be configured by
Xen.  Xen needs knowledge about the devices behind the VMD bridge,
and how to access those devices PCI config space to at least configure
MSI or MSI-X capabilities.  It could possibly be exposed similarly to
how Xen currently deals with ECAM areas.

None of this is present at the moment, could always be added later and
Linux be made aware that the limitation no longer applies.  That would
require changes in both Xen and Linux to propagate the VMD information
into Xen.

> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> > ---
> >  drivers/pci/controller/vmd.c | 9 +++++++++
> >  1 file changed, 9 insertions(+)
> > 
> > diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
> > index 264a180403a0..d9b7510ace29 100644
> > --- a/drivers/pci/controller/vmd.c
> > +++ b/drivers/pci/controller/vmd.c
> > @@ -965,6 +965,15 @@ static int vmd_probe(struct pci_dev *dev, const struct pci_device_id *id)
> >  	struct vmd_dev *vmd;
> >  	int err;
> >  
> > +	if (xen_domain())
> > +		/*
> > +		 * Xen doesn't have knowledge about devices in the VMD bus.
> 
> Also here.

Would you be OK with something like:

"Xen doesn't have knowledge about devices in the VMD bus because the
config space of devices behind the VMD bridge is not known to Xen, and
hence Xen cannot discover or configure them in any way.

Bypass of MSI remapping won't work in that case as direct write by
Linux to the MSI entries won't result in functional interrupts, as
it's Xen the entity that manages the local APIC and must configure
interrupts."

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon Jan 13 10:07:34 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Jan 2025 10:07:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870489.1281668 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXHM4-0004KB-Ht; Mon, 13 Jan 2025 10:07:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870489.1281668; Mon, 13 Jan 2025 10:07:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXHM4-0004K4-E8; Mon, 13 Jan 2025 10:07:32 +0000
Received: by outflank-mailman (input) for mailman id 870489;
 Mon, 13 Jan 2025 10:07:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=3HK6=UF=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tXHM3-0004Jw-BA
 for xen-devel@lists.xenproject.org; Mon, 13 Jan 2025 10:07:31 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 326a8255-d196-11ef-99a4-01e77a169b0f;
 Mon, 13 Jan 2025 11:07:29 +0100 (CET)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-5d90a5581fcso6872314a12.1
 for <xen-devel@lists.xenproject.org>; Mon, 13 Jan 2025 02:07:29 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d99008c2ccsm4765038a12.18.2025.01.13.02.07.27
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 13 Jan 2025 02:07:28 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 326a8255-d196-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736762849; x=1737367649; 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=GQ8hBilHaiJrXdn1x4pZcUJFv7XAxAtU+AZUJTBvXks=;
        b=G85/EtYRQUuY6bjJNjZiDtAfxzGeOEui/aBkr7YzNiA9SkWS+bdciguvU1BaBgtxGB
         7okhVZssV0TgSWxSDs/hyObX5PYll+OBxYolS8HfX/WGhh/3ZECwDg8JBIeM5hTJrQwu
         FF75p4u0rWDP1BWjpYqWCn8nX01GS30UTx9ZU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736762849; x=1737367649;
        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=GQ8hBilHaiJrXdn1x4pZcUJFv7XAxAtU+AZUJTBvXks=;
        b=KHjtSC1dAlKxg8BOpTPkrP/1B34uA87XukXrHehAe4QzoTEBqj8P9FL386b2I9wGpS
         vf1IKSc5nKbZjl02RWfnjNY3CjBM9kpjvWf5ZMs4DIixqFmpKBfFZqPgL7v4rH4/OlyV
         9WR2zFiqb9+KsVu1r8u4WXETfulGdgr4I7dbsfXZhi/4j/FtUjVkmGBKrxIjygBAdpty
         SunpkAtYHi69okQfDq84P3+KYNZpjqSWpQUQ9PTpxHEhzZZ8dP3WcEwC1T4pVP6Fq5vs
         ekl9ZfUG5KtFNQmI04GFlVle0RNcu9JtR2OaJNPfVAMKnIe9s8+eLJeqPD1rsMlt7o5v
         AS/A==
X-Forwarded-Encrypted: i=1; AJvYcCWd1kj7dUNLk6iVED2zwJDL/9zCrkjjbWTtm72EDwmTEFKqrMn3ASII1KdqsMe+k7iJ9VpPZyAxO9c=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw1pkVkKlkHJQzzi6H/0jNA2PRTJ8B5njjWBJAxrOsr7PPl6CBb
	CTRf11MXjndfsF2Iv+mb28nkkUHS4angOCvLr+Q0Vso3+5uEUybJeE24iwos+fNfJCKXR/aRGOD
	V
X-Gm-Gg: ASbGncvUt3MdbRNgevQS+YQ2NCZdWbRTWn0pJqeFnA6XxITp9xIOCnKBNh6e9g1ULZO
	rieSt9yMbGuFFwln8tQsO0KSeP1FlGW3b38xVVyc8cQE549aYgnfvxZiGWs0rRSbNRC1oZdt2uO
	UegNycCDcE9SwnLzQKWPetjP2k0gWgDQmXWw6XkVoQhztSEGkjy7BTJpMgmbWfDqvdYm8EDIVme
	WBNltV727AHHbNnKfeYFuvQTF0wMy6Kf9GqSFgYdEWRgmUCubBQBxzB+JSgUQ==
X-Google-Smtp-Source: AGHT+IG0+0hZDzdp4js5X9Qv1pwIacDTz8sB7g6BrtwD/4COxyJ2JYTA+74n/qblZAnNxdkdxaGgnw==
X-Received: by 2002:a05:6402:50d0:b0:5d6:37e9:8a93 with SMTP id 4fb4d7f45d1cf-5d972dfbbcdmr14241323a12.2.1736762848818;
        Mon, 13 Jan 2025 02:07:28 -0800 (PST)
Date: Mon, 13 Jan 2025 11:07:27 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jonathan Derrick <jonathan.derrick@linux.dev>
Cc: Bjorn Helgaas <helgaas@kernel.org>, linux-kernel@vger.kernel.org,
	xen-devel@lists.xenproject.org, linux-pci@vger.kernel.org,
	Nirmal Patel <nirmal.patel@linux.intel.com>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= <kw@linux.com>,
	Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
	Rob Herring <robh@kernel.org>, Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [PATCH 2/3] vmd: disable MSI remapping bypass under Xen
Message-ID: <Z4Tl33MHEhgrHg1A@macbook.local>
References: <20250110222525.GA318386@bhelgaas>
 <bcb30b80-0902-4561-94f9-a6e451702138@linux.dev>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <bcb30b80-0902-4561-94f9-a6e451702138@linux.dev>

On Fri, Jan 10, 2025 at 10:02:00PM -0700, Jonathan Derrick wrote:
> Hi Bjorn,
> 
> On 1/10/25 3:25 PM, Bjorn Helgaas wrote:
> > Match historical subject line style for prefix and capitalization:
> > 
> >    PCI: vmd: Set devices to D0 before enabling PM L1 Substates
> >    PCI: vmd: Add DID 8086:B06F and 8086:B60B for Intel client SKUs
> >    PCI: vmd: Fix indentation issue in vmd_shutdown()
> > 
> > On Fri, Jan 10, 2025 at 03:01:49PM +0100, Roger Pau Monne wrote:
> > > MSI remapping bypass (directly configuring MSI entries for devices on the VMD
> > > bus) won't work under Xen, as Xen is not aware of devices in such bus, and
> > > hence cannot configure the entries using the pIRQ interface in the PV case, and
> > > in the PVH case traps won't be setup for MSI entries for such devices.
> > > 
> > > Until Xen is aware of devices in the VMD bus prevent the
> > > VMD_FEAT_CAN_BYPASS_MSI_REMAP capability from being used when running as any
> > > kind of Xen guest.
> > 
> > Wrap to fit in 75 columns.
> > 
> > Can you include a hint about *why* Xen is not aware of devices below
> > VMD?  That will help to know whether it's a permanent unfixable
> > situation or something that could be done eventually.
> > 
> I wasn't aware of the Xen issue with VMD but if I had to guess it's probably
> due to the special handling of the downstream device into the dmar table.

Nothing to do with DMAR or IOMMUs, it's just that on a Xen system it
must be Xen the one that configures the MSI entries, and that requires
Xen being aware of the VMD devices and it's MSI or MSI-X
capabilities.

None of this is currently done, as Xen has no visibility at all of
devices behind a VMD bridge because is doesn't even know about VMD
bridges, neither about the exposed ECAM-like region on those
devices.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon Jan 13 10:13:55 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Jan 2025 10:13:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870503.1281677 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXHSC-0006BX-7t; Mon, 13 Jan 2025 10:13:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870503.1281677; Mon, 13 Jan 2025 10:13:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXHSC-0006BQ-4d; Mon, 13 Jan 2025 10:13:52 +0000
Received: by outflank-mailman (input) for mailman id 870503;
 Mon, 13 Jan 2025 10:13: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
 <SRS0=3HK6=UF=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tXHSB-0006BH-6l
 for xen-devel@lists.xenproject.org; Mon, 13 Jan 2025 10:13:51 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 15695c5d-d197-11ef-a0e1-8be0dac302b0;
 Mon, 13 Jan 2025 11:13:50 +0100 (CET)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-5d3e8f64d5dso7953665a12.3
 for <xen-devel@lists.xenproject.org>; Mon, 13 Jan 2025 02:13:50 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c95b20b1sm476929666b.157.2025.01.13.02.13.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 13 Jan 2025 02:13:47 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 15695c5d-d197-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736763230; x=1737368030; 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=D8lTHlEAyEJii3/Mpwsxjw0Vi02XDn0bU6dFc3Qzs4M=;
        b=nGLHNC5u+U5o0CATdiR1v269WmUwccQ+6RrGklclpSGp+V26gU540ggNojhQ0uGISd
         vmjNKXYWxkl+E1SnWiV7B6C6mNq4qD+OjF1AZ4/3oENYOELMgZxqZUd3yjU6rgSiCYVI
         Wmh9KDzIJ42RK8WoN6ZlI7oYlKv/OchY/S2xA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736763230; x=1737368030;
        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=D8lTHlEAyEJii3/Mpwsxjw0Vi02XDn0bU6dFc3Qzs4M=;
        b=D1pCG7FDNMLVJfqX735ufVI+9Gtm/CSBRoLnoGouP30Sas2+hCWrNSEIgQten69Cdd
         SaOkOsrSgbwbjop1LMl3atquaV3JMV0PA3UrUoUErmgMsbIDLrkVJ9PDin0zU9tXzUZx
         rZ9VA2xS+DxJWgVBoFT5MBzhtYBoc3PB6hGAuNKHrbgS3D89+4L8zHC/xlJuPXAJO/x2
         VTh5mn77ut3zRe6FVdW/M7hBMxvUOZ5RqUU2ROb+fJ1gk1GC/L8QFWbRNR8upgnRc3bH
         yvbH0I+92m1Shl+BldoQRwzC2/MYtPmjms7L3myJ2O1JJZsroI/FC9C0tJW+3tiOdqCG
         sM0Q==
X-Forwarded-Encrypted: i=1; AJvYcCVOILAQWEhm2XpJc5U0fDyGT7TiJl6luVZH2nwI1b4h9RFd0m8wGzgS7x0/tmwRxq+eiqUm0CqlK0w=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw71O4HHn09TMC4zb33tDUjcHfhGjj6bf9QhEd4KXFengh9wrKF
	RuH7HHG/6FReH1nGqF2v3WS99XISUHTRTVA7iFmwb7XqbFDEpAKrIdM+fQimL8M=
X-Gm-Gg: ASbGncs6coDLhbVLBEfv5zLvNOZzSz41OYv27Lsexld22yJdGq9oPBaULG+X5nh3SLt
	sv3MNXDi3eMGRikpWXhicYkpnI+KjKvWvkazzSUHRim0Uk6ZwNPa9IgasVEZ0PkQa2Vk5XMEw3G
	X79xHbIWBK3lIH6Vwpn5zLi4CAUuYBs01Z69+42JbyyMJ2pqXTwjiMAL7gUs9563mYg6T2jowKr
	JG1v7/eEQG30mlHqVHD+0hqP+yQRhY0l+svK68hRyxz3+gtTN8zVSb4kv2g1g==
X-Google-Smtp-Source: AGHT+IHQkfbOK7qojKw+VPoB34F3v7yvjSb9eEpH3DVYUTt7SdxJWey3SgTqrE3crVT85gfimKgYaQ==
X-Received: by 2002:a17:907:1998:b0:ab2:c9b8:aaa7 with SMTP id a640c23a62f3a-ab2c9b8ad19mr1517175666b.44.1736763228224;
        Mon, 13 Jan 2025 02:13:48 -0800 (PST)
Date: Mon, 13 Jan 2025 11:13:46 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Juergen Gross <jgross@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org
Subject: Re: [PATCH 1/3] xen/pci: do not register devices outside of PCI
 segment scope
Message-ID: <Z4TnWiijgBK3fThI@macbook.local>
References: <20250110140152.27624-1-roger.pau@citrix.com>
 <20250110140152.27624-2-roger.pau@citrix.com>
 <28ad828a-0a9a-4637-bf55-59de2f731537@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <28ad828a-0a9a-4637-bf55-59de2f731537@suse.com>

On Mon, Jan 13, 2025 at 08:17:23AM +0100, Jan Beulich wrote:
> On 10.01.2025 15:01, Roger Pau Monne wrote:
> > The PCI segment value is limited to 16 bits, however there are buses like VMD
> > that fake being part of the PCI topology by adding segment with a number
> > outside the scope of the PCI firmware specification range (>= 0x10000). The
> > MCFG ACPI Table "PCI Segment Group Number" field is defined as having a 16 bit
> > width.
> > 
> > Attempting to register or manage those devices with Xen would result in errors
> > at best, or overlaps with existing devices living on the truncated equivalent
> > segment values.
> > 
> > Skip notifying Xen about those devices.
> 
> Hmm, is simply omitting the notification really all it takes? How would Xen
> manage MSI / MSI-X, for example, without knowing of the device? As per the
> BoF on the summit in Prague(?), I continue to think we need partial driver
> logic in Xen for VMD ...

The basic mode of operation of devices behind a VMD bridge is to
reference the interrupts of the bridge device in its MSI(-X) entries,
so the VMD bridge acts as a de-multiplexer and forwards the interrupts
to the device behind the VMD bridge.  See vmd_alloc_irqs() (and
calling context) in the VMD driver for a reference about how this is
setup and operates.  Note also that devices behind a VMD bridge
operate using a different MSI domain, that uses a custom
irq_compose_msi_msg hook.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon Jan 13 10:19:05 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Jan 2025 10:19:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870512.1281688 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXHXB-0006mB-QW; Mon, 13 Jan 2025 10:19:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870512.1281688; Mon, 13 Jan 2025 10:19:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXHXB-0006m4-N4; Mon, 13 Jan 2025 10:19:01 +0000
Received: by outflank-mailman (input) for mailman id 870512;
 Mon, 13 Jan 2025 10:19:00 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=3HK6=UF=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tXHXA-0006ly-CE
 for xen-devel@lists.xenproject.org; Mon, 13 Jan 2025 10:19:00 +0000
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com
 [2a00:1450:4864:20::62f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id cdb0161d-d197-11ef-a0e1-8be0dac302b0;
 Mon, 13 Jan 2025 11:18:59 +0100 (CET)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-aa6c0d1833eso72636766b.1
 for <xen-devel@lists.xenproject.org>; Mon, 13 Jan 2025 02:18:59 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c95b1207sm480261466b.153.2025.01.13.02.18.58
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 13 Jan 2025 02:18:58 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: cdb0161d-d197-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736763539; x=1737368339; 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=VrEW9RapkLUvbhwp5lZsmgCTaBubEpv7gR1Du+cFUKw=;
        b=sB1ORh4ISCaXBEepfxjzPLe3xpftzZr0ch/Gqbu0YN9z3LJjsDYfcM3rgriAtJZNJX
         2kgsCDMxCcIVlzuW32APHKIZ2jRp64XfrHvN2yFmZ6MJniJYGYlGkOPQv5f1b8irz8LY
         nYJrucsfvrYaF3ps2Rl4AQtrNMph6Ja1V6g64=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736763539; x=1737368339;
        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=VrEW9RapkLUvbhwp5lZsmgCTaBubEpv7gR1Du+cFUKw=;
        b=g/dRVZxlZqAjxJcHZuLjECiUbK1MKRsIBj9H+v3wbpLlBqzKphFEDVbo6pKbJHhNP9
         AXc8x5/tPqUyKJbKxkPyeqlU+8ucQ6DC3XTFoMkUd8jCFEYEnvzK68BqMwEW5kax6VSN
         H4mQUmilfE6fqhkFAPVGDiMYKV2kF+oJ/zC1sPjIhLpKewGoxHofuVWoCNKhWI8XQS67
         1h29e5M+fIMJWPgFXds1x5wjOqd/Voy9DcECpEp9U+eITvow5ykQO7RxMV0cgFljYC4C
         mWhOUeUBUbMemUKVawzbzE6i0UOX8t/ZoPa2LYkz89Z8KZ5sC5yasb0VcEW3BEWibBtX
         4eDQ==
X-Forwarded-Encrypted: i=1; AJvYcCVsP1MklgwKwP1FBpABpdVNB7EyftJieQJn/PfF584QD2Lf1jnKfNk1SJzGRZLKuWjhMpskS1cZcfI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxFTDjSJn0UbngCF/hRnKhQnK+u452yV0vfcFbevytFWA5w33IY
	hlwjFNeGNNSkTT9IoRxsHctFJZlCfgi8IeXbQXbnKdzMAlY0fyAGJHBapasp1N0=
X-Gm-Gg: ASbGncsMstmXz3jo/Tf/8mSzFsOnQX5FGUnTRqpQKEt5LU9Aw0mVut/h65125ipRTvM
	JP9pjxPFN4N4XOTyLkNGG8aBfZ5enIk2X45TD4PQT8tiTzbDej3bZalAEC/J9p2Nn7w0cjl/whL
	INHdU+/xdLe+UC6WHt1sIIxk1j8v+RWVigIvUtuUDNtfbrnYivGgCP3HECd/U3MdUpU2eVrDg8V
	GLjyju4xiuUyabpN7nH1YlWc3LTEvoLMdRhB9AuKQ8b3WhW3L5QEVKHEv1Tjw==
X-Google-Smtp-Source: AGHT+IFj27FBVfZTJ7AzO9lrawoAO53MNm4jmh4KeKFNibSqpwXUBrNBlB8upGMQuZot38gb5qnfxw==
X-Received: by 2002:a17:907:2d94:b0:aa6:66eb:9c06 with SMTP id a640c23a62f3a-ab2ab6a8e01mr1928797466b.5.1736763538798;
        Mon, 13 Jan 2025 02:18:58 -0800 (PST)
Date: Mon, 13 Jan 2025 11:18:57 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
	Juergen Gross <jgross@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Subject: Re: [PATCH 1/3] xen/pci: do not register devices outside of PCI
 segment scope
Message-ID: <Z4TokbA1s3OyNdjt@macbook.local>
References: <20250110140152.27624-2-roger.pau@citrix.com>
 <20250110222129.GA317771@bhelgaas>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20250110222129.GA317771@bhelgaas>

On Fri, Jan 10, 2025 at 04:21:29PM -0600, Bjorn Helgaas wrote:
> On Fri, Jan 10, 2025 at 03:01:48PM +0100, Roger Pau Monne wrote:
> > The PCI segment value is limited to 16 bits, however there are buses like VMD
> > that fake being part of the PCI topology by adding segment with a number
> > outside the scope of the PCI firmware specification range (>= 0x10000). The
> > MCFG ACPI Table "PCI Segment Group Number" field is defined as having a 16 bit
> > width.
> >
> > Attempting to register or manage those devices with Xen would result in errors
> > at best, or overlaps with existing devices living on the truncated equivalent
> > segment values.
> 
> The ACPI _SEG method (ACPI r6.5, sec 6.5.6) and the corresponding
> value in the MCFG table (PCI Firmware r3.3, sec 4.1.2) are clearly
> 16-bit values.
> 
> But otherwise, the segment value is pretty much an arbitrary software
> value, and the kernel works fine with the larger domain values from
> vmd_find_free_domain(), so this isn't quite enough to explain what the
> issue with Xen is.
> 
> Does Xen truncate the domain to 16 bits or use it to look up something
> in ACPI?

In the interface between Xen and Linux the segment field is 16 bit
width, so with the current interface is not possible to reference
devices that are past the 0xffff segment.

I also wonder whether Xen and Linux (or guest OSes in general) would
agree on how to reference such devices.  AFAICT VMD segment numbers
are purely a software construct, but not something enforced by the
specification.  Could for example FreeBSD assign a different segment
to VMD devices?

If so we would need some kind of specification about how VMD segment
values are assigned so that OSes have a coherent way of referencing
VMD devices without ambiguity.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon Jan 13 10:26:08 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Jan 2025 10:26:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870521.1281698 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXHdy-0000Ex-Eb; Mon, 13 Jan 2025 10:26:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870521.1281698; Mon, 13 Jan 2025 10:26:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXHdy-0000Eq-Bs; Mon, 13 Jan 2025 10:26:02 +0000
Received: by outflank-mailman (input) for mailman id 870521;
 Mon, 13 Jan 2025 10:26:01 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=3HK6=UF=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tXHdx-0000Ek-5y
 for xen-devel@lists.xenproject.org; Mon, 13 Jan 2025 10:26:01 +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 c88e82fb-d198-11ef-a0e1-8be0dac302b0;
 Mon, 13 Jan 2025 11:26:00 +0100 (CET)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-5d932eac638so7865401a12.1
 for <xen-devel@lists.xenproject.org>; Mon, 13 Jan 2025 02:26:00 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d99046a05asm4788651a12.67.2025.01.13.02.25.59
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 13 Jan 2025 02:25:59 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c88e82fb-d198-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736763960; x=1737368760; 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=925HmCk6HSMWdjeEYYDzVrquNKNAs9H/T8Q5GhNYCxE=;
        b=QO8epKrDtZt3c8MMU06kGXmAlNnuM8cDUBFk0Yny4lMxcaW0xbQdsKYx/5PhfQ5D4G
         23wI2Ac0wUf0qQqX7/go5DFjGSjYLww/keHmTjSWEtGPSQILXN0/PjbUdCL+Non2nEqg
         Eynt9U0EvCALSyHzwxEXMjZ/QLv9GOyldrgLA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736763960; x=1737368760;
        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=925HmCk6HSMWdjeEYYDzVrquNKNAs9H/T8Q5GhNYCxE=;
        b=BgMiKXMSh8HifK5ssPjRQV3kT2kZZV5vOaOk+sBAZFaJhl+RpvlmhjvW+w2wUKcXZs
         qktDXMGJA4IaoYclAMlsZXc6txV71Ai4kfaxFogbSQCnd75UJaU1vV4AvbGpbsawC8g3
         eSPB53Z72enqrmx9w9QsQ9IJs+KiWCvQ66vjCddvI0uQ13BYyFuNvBZa3OF+KQnSU2+I
         0Y2QeTEcWryi/nUBxyqRrGt0yyLqMvFa7M53vQOOEnr2rWyLLaOSZr6iefoyygQ2ycmO
         BpqsmtADq0JkgCab0vGVJkq2kNiuoP+p1V9xFyhMIhHMSs8G2IEoHwWmD4ZvW1zTMtVN
         uU8g==
X-Forwarded-Encrypted: i=1; AJvYcCUSLHH74YMCSaGqEvV+46XfDcNvmt2pfKttW5lK+dbkpNShoNCiq0TAIFuiwcKd/I80p3ngapXvmLc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzExH/e3GLORF2wa6FQ3a0+hV76mjMUZGpJt+IpdB8l538JnhLA
	5tDjUCLc2TKaZZdZMKL7z6NBs9o4hEf7l3iDWaefNzOS5oZuT67tJEru0xrWxDw=
X-Gm-Gg: ASbGncsJ81JsS0OPGZ5jiQGYZn+41Eb0DMLt4izxkyULaXnSJi8ry3z2y/Te/tjjDBT
	UXib7MrT+za1q+e1rkuqPxxGnFl6o0h/r49UcaqZ2NIX2a2IFFSTr0wfcybBe3Kh69zV6SynhWM
	2gwMrZ/Ro/hp01dxvL5Srftlwb+qY+AbcSDBig7I+mP43z+JiNof9iZjq0uNLSp9ECIDkQhp5Uo
	gaupYBjuXunBvwBQ2wJjTjCz4l8ecVK7Xt3Xi3/J98taU56aAtQGuK67AyXRg==
X-Google-Smtp-Source: AGHT+IFqQfQXn4x8tYwm9aCoWhJeQj7jQKe/nY36w28hVZGBm5avVQz2Sjl6V/fPorhg+0bEmX3Ptg==
X-Received: by 2002:a05:6402:5006:b0:5d0:e3fa:17ca with SMTP id 4fb4d7f45d1cf-5d972e17902mr18117568a12.15.1736763959654;
        Mon, 13 Jan 2025 02:25:59 -0800 (PST)
Date: Mon, 13 Jan 2025 11:25:58 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
	linux-pci@vger.kernel.org, Juergen Gross <jgross@suse.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH 3/3] pci/msi: remove pci_msi_ignore_mask
Message-ID: <Z4TqNn_RSwGX1TQn@macbook.local>
References: <20250110140152.27624-4-roger.pau@citrix.com>
 <20250110223057.GA318711@bhelgaas>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20250110223057.GA318711@bhelgaas>

On Fri, Jan 10, 2025 at 04:30:57PM -0600, Bjorn Helgaas wrote:
> Match subject line style again.
> 
> On Fri, Jan 10, 2025 at 03:01:50PM +0100, Roger Pau Monne wrote:
> > Setting pci_msi_ignore_mask inhibits the toggling of the mask bit for both MSI
> > and MSI-X entries globally, regardless of the IRQ chip they are using.  Only
> > Xen sets the pci_msi_ignore_mask when routing physical interrupts over event
> > channels, to prevent PCI code from attempting to toggle the maskbit, as it's
> > Xen that controls the bit.
> > 
> > However, the pci_msi_ignore_mask being global will affect devices that use MSI
> > interrupts but are not routing those interrupts over event channels (not using
> > the Xen pIRQ chip).  One example is devices behind a VMD PCI bridge.  In that
> > scenario the VMD bridge configures MSI(-X) using the normal IRQ chip (the pIRQ
> > one in the Xen case), and devices behind the bridge configure the MSI entries
> > using indexes into the VMD bridge MSI table.  The VMD bridge then demultiplexes
> > such interrupts and delivers to the destination device(s).  Having
> > pci_msi_ignore_mask set in that scenario prevents (un)masking of MSI entries
> > for devices behind the VMD bridge.
> > 
> > Move the signaling of no entry masking into the MSI domain flags, as that
> > allows setting it on a per-domain basis.  Set it for the Xen MSI domain that
> > uses the pIRQ chip, while leaving it unset for the rest of the cases.
> > 
> > Remove pci_msi_ignore_mask at once, since it was only used by Xen code, and
> > with Xen dropping usage the variable is unneeded.
> > 
> > This fixes using devices behind a VMD bridge on Xen PV hardware domains.
> 
> Wrap to fit in 75 columns.
> 
> The first two patches talk about devices behind VMD not being usable
> for Xen, but this one says they now work.

Sorry, let me try to clarify:

Devices behind a VMD bridge are not known to Xen, however that doesn't
mean Linux cannot use them.  That's what this series achieves.  By
inhibiting the usage of VMD_FEAT_CAN_BYPASS_MSI_REMAP and the removal
of the pci_msi_ignore_mask bodge devices behind a VMD bridge do work
fine when use from a Linux Xen hardware domain.  That's the whole
point of the series.

> But this doesn't undo the
> code changes or comments added by the first two, so the result is a
> bit confusing (probably because I know nothing about Xen).

All patches are needed.  There's probably some confusion about devices
behind a VMD bridge not being known by Xen vs not being usable by
Linux running under Xen as a hardware domain.

With all three patches applied devices behind a VMD bridge work under
Linux with Xen.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon Jan 13 10:53:35 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Jan 2025 10:53:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870531.1281708 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXI4W-0004oQ-Ff; Mon, 13 Jan 2025 10:53:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870531.1281708; Mon, 13 Jan 2025 10:53:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXI4W-0004oJ-Ci; Mon, 13 Jan 2025 10:53:28 +0000
Received: by outflank-mailman (input) for mailman id 870531;
 Mon, 13 Jan 2025 10:53:27 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=HC3z=UF=epam.com=Mykyta_Poturai@srs-se1.protection.inumbo.net>)
 id 1tXI4U-0004mg-OO
 for xen-devel@lists.xenproject.org; Mon, 13 Jan 2025 10:53:27 +0000
Received: from EUR05-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur05on20601.outbound.protection.outlook.com
 [2a01:111:f403:2613::601])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9c86e111-d19c-11ef-a0e1-8be0dac302b0;
 Mon, 13 Jan 2025 11:53:25 +0100 (CET)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by GV2PR03MB8512.eurprd03.prod.outlook.com
 (2603:10a6:150:a9::14) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8335.15; Mon, 13 Jan
 2025 10:53:21 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971%5]) with mapi id 15.20.8335.017; Mon, 13 Jan 2025
 10:53:21 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9c86e111-d19c-11ef-a0e1-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=iDEc4N99OVC8DPEKcGpH2DCAJseNfYrJL+a+Sl9U7sUKLP2WhehL+Ku6o7/InjApPe4fY3HyhEzB+xhq9q5AwNEMM0zMZiu+ziXXe655XFWUHI0sdkM3TxHXGTUH6LjERhetobjL07+TjGbNW22t+d4PqwzPjRrC+YphvXwq6sOcH6YWoJ3PfSn2WdtY37N6Sxxs8ojsE5v56fQ+XG5FIuMN6QKPyOidhv3QHh3qWg5+jZiuSOfCi4wR+1zvEuNcqBMltSXI7Q0JZVvyJ347M8P3aMAtEeBIkVFiGAYTVoYz0jrzaiicxcOVhUfv92m21lzeV3PvB8EBI4EmPRx0Uw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=/EWAU6LXcPokDDrXcKbdQ2agWQMhsK2RyB1UCiJOR4A=;
 b=sR7/nI97UsWxdr9h9xS219nb6rxX7bujpxEQhGHWvg1cr0iVIfgRWPqUCFW6EyuEFyJhQkCO/zzY6cR7Dhc3tGokhN9sYmsZf0GGbGYhG6zMboWLtNnwi+lThuITwQCV1KgjXO3v6x7wMfHecjmBra6ZSe3CeZFp9aT/yTOnE7mWhTOrrzXxTBJMYdGTZjwUG+JooKzUEG/BJTZCgKHqLfP5wfnFQC+Q/ZfMK6D6niBDAwSeEv7k0DuGScuY0fZnT0OPJcbDi5KIvSbagPCHjG2vjoD0Prb2tpCyn4JsfsAWT8Kido9to3SaQufXSVpKq447fC5G3bvL6/wPwI1VtQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=/EWAU6LXcPokDDrXcKbdQ2agWQMhsK2RyB1UCiJOR4A=;
 b=gYyQ9DKzVLVvljYZ/rCBMb4LyO248Q62/KpW+X9GcTftE5uy5QNN2r2kmuFGSMN3mEHFPXnera9CtA4qxyfSvv+98ldo2r7QhHvXI+B2ieCJA90Fgubw9KKLgf4q3TKbOwzZ72yyG64F1+fYXRDNvamvxOVEMOHQ2hfaFBIBlZyHyjPPqNAf6h3lsBsR1zr6nBLIIyRg8sJDR0sKcCboeSmR+JQSXyDtVxou9l1mpdvkUiBDC/lG/m7TUEDCoUbfDUq9IQ1DRcxv3TzABpWKQA6YGe15bwNgBv29DonqQfB4wK1HP+1NrvhuPYxgjLPsH4eMFHpGdOBD0qpVCrvVSw==
From: Mykyta Poturai <Mykyta_Poturai@epam.com>
To: Stefano Stabellini <sstabellini@kernel.org>
CC: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Oleksandr Andrushchenko <Oleksandr_Andrushchenko@epam.com>, Julien Grall
	<julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>, Michal Orzel
	<michal.orzel@amd.com>, Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: Re: [PATCH v2 1/2] ARM: ITS: implement quirks and add support for
 Renesas Gen4 ITS
Thread-Topic: [PATCH v2 1/2] ARM: ITS: implement quirks and add support for
 Renesas Gen4 ITS
Thread-Index: AQHbYc6JDAhmZxCQ3Eu7Expf0AOQsLMPKSYAgAVl9AA=
Date: Mon, 13 Jan 2025 10:53:21 +0000
Message-ID: <83b0f6f1-1fe5-4ccc-86fa-8ee26def0389@epam.com>
References: <cover.1736331828.git.mykyta_poturai@epam.com>
 <e2544cace3517eb68cdffdc278f347584f93fd63.1736331828.git.mykyta_poturai@epam.com>
 <alpine.DEB.2.22.394.2501091619040.133435@ubuntu-linux-20-04-desktop>
In-Reply-To:
 <alpine.DEB.2.22.394.2501091619040.133435@ubuntu-linux-20-04-desktop>
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=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB10102:EE_|GV2PR03MB8512:EE_
x-ms-office365-filtering-correlation-id: cae3df67-d3f7-4969-defc-08dd33c07ef2
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?dlJWYVQ0OWpzVnp2L05NekRKa29JV3E2MjFVV2hObTYyVGJYbWhWZU4wb1Mr?=
 =?utf-8?B?ZXA4aXZ6Tk40Zy91bHJwWlVPODJlb3BKUjNwWVJ5ZUZLakxwa0xEdk0wMXZG?=
 =?utf-8?B?TFdyL1BkQk5FRWZjdUhxZ3c0ZTNVL2F1UVRpZ2JtVDlCanhVaWxacHFlK1dN?=
 =?utf-8?B?ZnNJZ3JkT1FaSGdRYVEwVXVGK2tPeFBnT3RTTndZWDB6bGRkSE1ITDcraXRs?=
 =?utf-8?B?czQyODFLSG5pcGl0UnRHNzVqcUZiOUFUc05uaVJYQUhtb2daZkJ4SDZDMDFn?=
 =?utf-8?B?YThUZnFObmJQbHMvRmxVa2JBcjFaYVRlMkhxOWU5UnlkdHBrOVBDUnZkSEJr?=
 =?utf-8?B?ZDQvVjluLzZFTnBEVEpwakVCYnlwU2JLUjFQZnlVYVFvSE0rWUVSdGlFcUJR?=
 =?utf-8?B?U2s3NXN3VFNIN1l3L0lDTm9KdkduZUFDZ3dtR0xXUnFlZjZkME5vazFnTlNy?=
 =?utf-8?B?OVFVeGpoNW9HbC9lTXNkWkpQT1FxcWRVQkRQS1R5STdqM2FsdzhYU2JPU1pi?=
 =?utf-8?B?OEltRU9vTjVpOGNKVnQ4S3lRUE1tZTZDajVwTkg0ZmhzWHVXdkU2eTdkc3l0?=
 =?utf-8?B?b2xqUlp4N1BUdEd6LzFkaEtmOS9pR2tQMFVwUEpndDFhU1NieWJSN3hnSzJR?=
 =?utf-8?B?czVNQkUvU0ZyS1Jid1Vac3l6TzNwZUVhaHRuUHNwRW5QY3JOZURqei9yRkwv?=
 =?utf-8?B?TXJZRTRVY2NyU1FoYTVJeUh3QzR0eUVVV3hVWDNIUmpNcXlBRmtXSDh3YkN5?=
 =?utf-8?B?ZWFVY041OTBWdTBQV2p3YnRXZE84cFpudzQ4cFhsdytFU040RUNyQ1VONTli?=
 =?utf-8?B?dXlsMXdIaFVhTGNSSlpreUQzTWJiYlFHZFJCVWtKd3ZraFcyQkt5Z0NIVlI4?=
 =?utf-8?B?RURMWUhQdjRzMVlQN25WYjJPcHNlbnowTW4zZHdFNkpHejRyVzVsbVRkeWw4?=
 =?utf-8?B?TVJidDA5WkNRY0Via1BFRXNXcml2ckdveUpoUUlnVDFEdWdHYng2U3pvQ0hr?=
 =?utf-8?B?V3daRkErSjdINjNSbVBYTFI3T0xQTnRCWHg5LzhabmxXVU1zVmNaSWcwTDkw?=
 =?utf-8?B?dXZaZEFNK3RLb20yV2I2ejFuaUtmVXgzSVQzOTlpVlh6aW1sb3c0bkN5anpn?=
 =?utf-8?B?a0RQQUp0NnNyQU1RcTZRaDZWR2hIVnJPSG9XeE42U3liaktWVExrVENEYlh3?=
 =?utf-8?B?WnQ4STlKL1cwR0pnTHF3WHUzc0FYZmtUay9JTVUzMFpzT0M2L2x1NmJBSG9l?=
 =?utf-8?B?TGNtcGtkazY1RFlIRG9ha3d4RE50dVNLSjQ3NVRNMHJlOVBPeXFMaFY1VU5I?=
 =?utf-8?B?bCtHWXFSWWhBc2J6ZGp6a3pZRVBUWUl0L3JTTkNGdFduNGwya2NlSklVMkpm?=
 =?utf-8?B?YWtINXZFby9rWEdpRFQ0N3JJYy9rTkFXSFMxY2pBdWV5NjlBcys4VzM3VldI?=
 =?utf-8?B?cmlHeUFjTThESWh1bGYrVS9SQkZvb3Bpc1hUK1IvYXhsTDhXN1hnaFA0TCtZ?=
 =?utf-8?B?OTYxQXZDRUZSR1Jid1NBc3hrdThCaW5uVlBhL3ZWVjM4Y0VGbXN6eGl4ZjBC?=
 =?utf-8?B?azYxUktiRm45Q0xJVk1Dai9PMEVCUFdqZmdhbXowbVdyd3dValJjU2x5UXI5?=
 =?utf-8?B?clhGbkNrbThDVU5kZTBVTTJUOEpvd3Q5Yzk0djMxVWtkNVJOWEJqZUVXSjY1?=
 =?utf-8?B?RXdPUVRUOEtJYndpejRRQm1SSDhoMDJ1QmlUdHRHeDlBMjVZOVJVMnZkak5M?=
 =?utf-8?B?Ym9ZNHMwNnAxTTNiZXpoUmtmdFFpR3hUazEyQXhKcmlkYzA1OXBWSCs3T2JM?=
 =?utf-8?B?anQzT2RFUzA2WE1PWFM3Mnh1V0JKQkM4elI1bXQwVXVkNTJDUm1IQVpFUnYz?=
 =?utf-8?Q?zFP3J6hBABZHw?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB10102.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?MlJBSHg0YU5CVzRWZmZJZ2ZEMkdPc0dvUXE5VFJVQVhJNXlHazQyeHVlelhB?=
 =?utf-8?B?MVFkd3pVVEJpTFQ2Q0xsQWFuaGoxNWxEdjFqSnN4ZHNJTmpvZnQvdjh4MlAv?=
 =?utf-8?B?YkhWYytFdkh6cFBCalprUVl2Q0lyMVpXVFIrN3JockFFdndtN09kMHZWUy9z?=
 =?utf-8?B?SSt6REJKdGVnZWtXZEZyNlh6cFMybmZ1TVZaTHFDRGRDZnlyZ2VwUzJ3SXUr?=
 =?utf-8?B?bGp3dmw5UUpJQlArTEpLczhreWo2UElycVY4aUp1b3NiekNjaGtBU1Z1eE5C?=
 =?utf-8?B?YmpySU93b3ZkUWhIR0hWaUcvOFdseFoyQlpvWGZCRTh6ZEQrRDY3dC9rd1By?=
 =?utf-8?B?K2laR1QxM2NHRzlqY3JaYVpqenVQb3BJK1dBamVTYnJuTFBsaFM1WERFcDJR?=
 =?utf-8?B?RlhqUVU5TDhHK2xNRGVGaW5jOXMzT0dvNnBqWnRDTkZXRyszY0JsaU5uNUNR?=
 =?utf-8?B?Syt3Qm40WktEckZXeWFUSXR1ZFdUZUtPOHM3dGhSc2x4eFc4K0FEc0lwYXpO?=
 =?utf-8?B?ajNJeG03N2FJVHZuSXVBdDI1d1FxWVNsSGZZTVhUU2p3NFJsOWVNVnloQjlS?=
 =?utf-8?B?OUxFVk1JR3ZRbnlFQldtTHlQSG9EdTRtcWh0Wnp3cXFmTmVxNmdZWERGSy9W?=
 =?utf-8?B?Y1ZaOEpFRlVpT0hZOEo0TnVuOWZuVmFBT3ZCRU43ZHVQL2p2Y2RRRHhwZ05i?=
 =?utf-8?B?dDZ2SGNEREh4MWg5TG1QclhNY0NEb2IzWDVSSlhrQ3MrR1JScTgzQ002dHIv?=
 =?utf-8?B?YkpEUTVmd1ZwRnJpS0hrZk15Y2srQUdLeER0ZWNDVEhTdmhhV2tld2pkSHBj?=
 =?utf-8?B?TERyc1d6amJiTmRPbWZtR1FqSTlUdkhEY1ZDWld3cVVqbGIvVVBtM3NINXEw?=
 =?utf-8?B?ZGtGNDdDVnpkNUdGS3dtV0gwZ2xVOFp4Smgxa0RPNHpwUXMycng3eUh4cVdL?=
 =?utf-8?B?VkRVODdVdVhQMW9KSUpZUEZzSi9vVjJrRjFFYUFQNjMxazg3dGdvb0tqNjU1?=
 =?utf-8?B?LzlBYUlkc1c4OVVjM1M5WWRQOGxnd1B5M0VSZzVJZkt5Wit6b1Jxa3RvbXBx?=
 =?utf-8?B?NlczZ0J2VmJqVGw2UTZJdmd6VjB0aFZMWkpjcHEzUWk0MUNvamVROTJtaFVj?=
 =?utf-8?B?R2gyZEh6K0I3MU1yczI5MmZoWCtrY3JiQXdlcUFjYWkvZzBFQk5LeGk2UEM0?=
 =?utf-8?B?MUU4dDVZRUFTTkNuZk1Ddm9lSlJvbmhrOE5BaDNkczdBTUl2RlEzeUdhS0Nv?=
 =?utf-8?B?c3I0YTRKWlpLOWJPY2hBQ1VzWGtCR0tYYkVRZWc4VFpGQWZ0NWt5UXdzUVdS?=
 =?utf-8?B?OFZnWUN1dDdGVzI4U1V4dWY2SCtPNjdnTkNUOXU4MmtmU1JPU0JmRGhlcTBv?=
 =?utf-8?B?SmJDREYrcGFhUVJVNHFMRGdtaHg5K1VQV05Pc0pmaVJFQXg1MGlZV1dsL24x?=
 =?utf-8?B?S3RDSzE3cWM5c1phc0ZLa00rRG9vK3ZzdkxLTm5qbUVIOUtpTktEMkg0cGlR?=
 =?utf-8?B?amUvTWtTdFdPOGxhWkJURUxZUExMTW1DeFplSmlTaDZxWFB5eUtDWXdHemdO?=
 =?utf-8?B?YWdHQ2QyZ3JyQmx1K0dKYVJEV2lQVEVMWkpjSW1kazZRSElndmNQREM2ZGpV?=
 =?utf-8?B?eVpwUy9UellPRzZnWGY3SUlCL3h2Y0tWWHpuM1lSTXcyOEFwaGhIUE1takZD?=
 =?utf-8?B?M2VLSHBldSthUm9hOUdzenJxVjBOUm0zVk1nSjV0emlTSm9tdGZHaVZaZU9Q?=
 =?utf-8?B?Z3VpQkRQSGV0MXdjTUVsMEVGd29hdTU2cWhLN1p5WkZBMFNUUUpvS0lxTEE1?=
 =?utf-8?B?QlFqdC9KenhvYlZFWXZaRHU0Z1VSdXNuTTRwM2NNc21JWE03K2lVRlVYZ216?=
 =?utf-8?B?RGtzVjlwSTR6MG9Za3NSK3MyWmEvMlhVVURaaUR6akdIRFRuUnhOblUwMXRw?=
 =?utf-8?B?Q2pMdGgrOVVHcTAzNS84ekloZ3FrenNNQ3psbTJEVFBncWMyak02cERQUGRO?=
 =?utf-8?B?aXk4clhOcnBOZlF4MXpMQ0ZRSnAzZU1pQ0UySUZHZ25rL1dqYXpaS3ViQ2da?=
 =?utf-8?B?cFYxM2xQSkN3UXRuMGdEVjZhUkRCWnlTR0FFTFdrTWhmaXdFQ2sxUzROS2RN?=
 =?utf-8?B?b0IwUksyVGZyK1JIeDZ4bnA5TkFhVWwvNHhNb0dvWHNzY3FuSnE2eDRraEpT?=
 =?utf-8?B?OEE9PQ==?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <214B9D111E00654EA78B6B203CB2316D@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PAVPR03MB10102.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: cae3df67-d3f7-4969-defc-08dd33c07ef2
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2025 10:53:21.2984
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 8E359bgxy2H3hfNgJR3bn+dE4F8vXBaaW+NT2Y3TNOMRB2L0pR00APh1MnzT7KDceZubJNQCUIMAM8rZPaaBSg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR03MB8512

T24gMTAuMDEuMjUgMDI6MjcsIFN0ZWZhbm8gU3RhYmVsbGluaSB3cm90ZToNCj4gT24gV2VkLCA4
IEphbiAyMDI1LCBNeWt5dGEgUG90dXJhaSB3cm90ZToNCj4+IEZyb206IE9sZWtzYW5kciBBbmRy
dXNoY2hlbmtvIDxvbGVrc2FuZHJfYW5kcnVzaGNoZW5rb0BlcGFtLmNvbT4NCj4+DQo+PiBUaGVy
ZSBhcmUgbnVtYmVyIG9mIElUUyBpbXBsZW1lbnRhdGlvbnMgZXhpc3Qgd2hpY2ggYXJlIGRpZmZl
cmVudCBmcm9tDQo+PiB0aGUgYmFzZSBvbmUgd2hpY2ggaGF2ZSBudW1iZXIgb2YgZnVuY3Rpb25h
bGl0aWVzIGRlZmluZWQgYXMgaXMNCj4+ICJJTVBMRU1FTlRBVElPTiBERUZJTkVEIiwgZS5nLiB0
aGVyZSBtYXkgZXhpc3QgZGlmZmVyZW5jZXMgaW4gY2FjaGVhYmlsaXR5LA0KPj4gc2hhcmVhYmls
aXR5IGFuZCBtZW1vcnkgcmVxdWlyZW1lbnRzIGFuZCBvdGhlcnMuIFRoaXMgcmVxdWlyZXMNCj4+
IGFwcHJvcHJpYXRlIGhhbmRsaW5nIG9mIHN1Y2ggSFcgcmVxdWlyZW1lbnRzIHdoaWNoIGFyZSBp
bXBsZW1lbnRlZCBhcw0KPj4gSVRTIHF1aXJrczogR0lUU19JSURSIChJVFMgSW1wbGVtZW50ZXIg
SWRlbnRpZmljYXRpb24gUmVnaXN0ZXIpIGlzIHVzZWQgdG8NCj4+IGRpZmZlcmVudGlhdGUgdGhl
IElUUyBpbXBsZW1lbnRhdGlvbnMgYW5kIHNlbGVjdCBhcHByb3ByaWF0ZSBzZXQgb2YNCj4+IHF1
aXJrcyBpZiBhbnkuDQo+Pg0KPj4gQXMgYW4gZXhhbXBsZSBvZiBzdWNoIElUU2VzIGFkZCBxdWly
ayBpbXBsZW1lbnRhdGlvbiBmb3IgUmVuZXNhcyBHZW40IElUUzoNCj4+IC0gYWRkIHBvc3NpYmls
aXR5IHRvIG92ZXJyaWRlIGRlZmF1bHQgY2FjaGVhYmlsaXR5IGFuZCBzaGFyZWFiaWxpdHkNCj4+
IHNldHRpbmdzIHVzZWQgZm9yIElUUyBtZW1vcnkgYWxsb2NhdGlvbnM7DQo+PiAtIGNoYW5nZSBy
ZWxldmFudCBtZW1vcnkgYWxsb2NhdGlvbnMgdG8gYWxsb2NfeGVuaGVhcF9wYWdlcyB3aGljaCBh
bGxvd3MNCj4+IHRvIHNwZWNpZnkgbWVtb3J5IGFjY2VzcyBmbGFncywgZnJlZV94ZW5oZWFwX3Bh
Z2VzIGlzIHVzZWQgdG8gZnJlZTsNCj4+IC0gYWRkIHF1aXJrcyB2YWxpZGF0aW9uIHRvIGVuc3Vy
ZSB0aGF0IGFsbCBJVFNlcyBzaGFyZSB0aGUgc2FtZSBxdWlya3MNCj4+IGluIGNhc2Ugb2YgbXVs
dGlwbGUgSVRTZXMgYXJlIHByZXNlbnQgaW4gdGhlIHN5c3RlbTsNCj4+DQo+PiBUaGUgR2VuNCBJ
VFMgbWVtb3J5IHJlcXVpcmVtZW50cyBhcmUgbm90IGNvdmVyZWQgaW4gYW55IGVycmF0YSBhcyBv
ZiB5ZXQsDQo+PiBidXQgb2JzZXJ2ZWQgYmVoYXZpb3Igc3VnZ2VzdHMgdGhhdCB0aGV5IGFyZSBp
bmRlZWQgcmVxdWlyZWQuDQo+Pg0KPj4gVGhlIGlkZWEgb2YgdGhlIHF1aXJrIGltcGxlbWVudGF0
aW9uIGlzIGluc3BpcmVkIGJ5IHRoZSBMaW51eCBrZXJuZWwgSVRTDQo+PiBxdWlyayBpbXBsZW1l
bnRhdGlvbiBbMV0uDQo+Pg0KPj4gQ2hhbmdlbG9nOg0KPj4gdjEgLT4gdjI6DQo+PiAtIHN3aXRj
aGVkIHRvIHVzaW5nIGFsbG9jX3hlbmhlYXBfcGFnZXMvZnJlZV94ZW5oZWFwX3BhZ2VzIGZvciBJ
VFMgbWVtb3J5DQo+PiBhbGxvY2F0aW9uczsNCj4+IC0gdXBkYXRlZCBkZWNsYXJhdGlvbiBvZiBp
dHNfcXVpcmtfZmxhZ3M7DQo+PiAtIGFkZGVkIHF1aXJrcyB2YWxpZGF0aW9uIHRvIGVuc3VyZSB0
aGF0IGFsbCBJVFNlcyBzaGFyZSB0aGUgc2FtZSBxdWlya3M7DQo+PiAtIHJlbW92ZWQgdW5uZWNl
c3NhcnkgdklUUyBjaGFuZ2VzOw0KPj4NCj4+DQo+PiBTaWduZWQtb2ZmLWJ5OiBPbGVrc2FuZHIg
QW5kcnVzaGNoZW5rbyA8b2xla3NhbmRyX2FuZHJ1c2hjaGVua29AZXBhbS5jb20+DQo+PiBTaWdu
ZWQtb2ZmLWJ5OiBNeWt5dGEgUG90dXJhaSA8bXlreXRhX3BvdHVyYWlAZXBhbS5jb20+DQo+Pg0K
Pj4gWzFdIGh0dHBzOi8vZWxpeGlyLmJvb3RsaW4uY29tL2xpbnV4L3Y1LjE2LjEvc291cmNlL2Ry
aXZlcnMvaXJxY2hpcC9pcnEtZ2ljLXYzLWl0cy5jDQo+PiAtLS0NCj4+ICAgeGVuL2FyY2gvYXJt
L2dpYy12My1pdHMuYyAgICAgICAgICAgICB8IDE0MSArKysrKysrKysrKysrKysrKysrKysrKy0t
LQ0KPj4gICB4ZW4vYXJjaC9hcm0vZ2ljLXYzLWxwaS5jICAgICAgICAgICAgIHwgIDIwICsrLS0N
Cj4+ICAgeGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2dpY192M19pdHMuaCB8ICAgOCArKw0KPj4g
ICAzIGZpbGVzIGNoYW5nZWQsIDE1MCBpbnNlcnRpb25zKCspLCAxOSBkZWxldGlvbnMoLSkNCj4+
DQo+PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL2dpYy12My1pdHMuYyBiL3hlbi9hcmNoL2Fy
bS9naWMtdjMtaXRzLmMNCj4+IGluZGV4IDVmZDgzYWYyNWEuLjg4NDlhYzZjNGIgMTAwNjQ0DQo+
PiAtLS0gYS94ZW4vYXJjaC9hcm0vZ2ljLXYzLWl0cy5jDQo+PiArKysgYi94ZW4vYXJjaC9hcm0v
Z2ljLXYzLWl0cy5jDQo+PiBAQCAtNDIsNiArNDIsNyBAQCBzdHJ1Y3QgaXRzX2RldmljZSB7DQo+
PiAgICAgICBzdHJ1Y3QgcmJfbm9kZSByYm5vZGU7DQo+PiAgICAgICBzdHJ1Y3QgaG9zdF9pdHMg
Kmh3X2l0czsNCj4+ICAgICAgIHZvaWQgKml0dF9hZGRyOw0KPj4gKyAgICB1bnNpZ25lZCBpbnQg
aXR0X29yZGVyOw0KPj4gICAgICAgcGFkZHJfdCBndWVzdF9kb29yYmVsbDsgICAgICAgICAgICAg
LyogSWRlbnRpZmllcyB0aGUgdmlydHVhbCBJVFMgKi8NCj4+ICAgICAgIHVpbnQzMl90IGhvc3Rf
ZGV2aWQ7DQo+PiAgICAgICB1aW50MzJfdCBndWVzdF9kZXZpZDsNCj4+IEBAIC01MCw2ICs1MSwx
MDQgQEAgc3RydWN0IGl0c19kZXZpY2Ugew0KPj4gICAgICAgc3RydWN0IHBlbmRpbmdfaXJxICpw
ZW5kX2lycXM7ICAgICAgLyogT25lIHN0cnVjdCBwZXIgZXZlbnQgKi8NCj4+ICAgfTsNCj4+DQo+
PiArLyoNCj4+ICsgKiBJdCBpcyB1bmxpa2VseSB0aGF0IGEgcGxhdGZvcm0gaW1wbGVtZW50cyBJ
VFNlcyB3aXRoIGRpZmZlcmVudCBxdWlya3MsDQo+PiArICogc28gYXNzdW1lIHRoZXkgYWxsIHNo
YXJlIHRoZSBzYW1lLg0KPj4gKyAqLw0KPj4gK3N0cnVjdCBpdHNfcXVpcmsgew0KPj4gKyAgICBj
b25zdCBjaGFyICpkZXNjOw0KPj4gKyAgICBib29sICgqaW5pdCkoc3RydWN0IGhvc3RfaXRzICpo
d19pdHMpOw0KPj4gKyAgICB1aW50MzJfdCBpaWRyOw0KPj4gKyAgICB1aW50MzJfdCBtYXNrOw0K
Pj4gK307DQo+PiArDQo+PiArc3RhdGljIHVpbnQzMl90IF9fcm9fYWZ0ZXJfaW5pdCBpdHNfcXVp
cmtfZmxhZ3M7DQo+PiArDQo+PiArc3RhdGljIGJvb2wgZ2ljdjNfaXRzX2VuYWJsZV9xdWlya19n
ZW40KHN0cnVjdCBob3N0X2l0cyAqaHdfaXRzKQ0KPj4gK3sNCj4+ICsgICAgaXRzX3F1aXJrX2Zs
YWdzIHw9IEhPU1RfSVRTX1dPUktBUk9VTkRfTkNfTlMgfA0KPj4gKyAgICAgICAgSE9TVF9JVFNf
V09SS0FST1VORF8zMkJJVF9BRERSOw0KPj4gKw0KPj4gKyAgICByZXR1cm4gdHJ1ZTsNCj4+ICt9
DQo+PiArDQo+PiArc3RhdGljIGNvbnN0IHN0cnVjdCBpdHNfcXVpcmsgaXRzX3F1aXJrc1tdID0g
ew0KPj4gKyAgICB7DQo+PiArICAgICAgICAuZGVzYyAgICAgICA9ICJSLUNhciBHZW40IiwNCj4+
ICsgICAgICAgIC5paWRyICAgICAgID0gMHgwMjAxNzQzYiwNCj4+ICsgICAgICAgIC5tYXNrICAg
ICAgID0gMHhmZmZmZmZmZiwNCj4+ICsgICAgICAgIC5pbml0ICAgICAgID0gZ2ljdjNfaXRzX2Vu
YWJsZV9xdWlya19nZW40LA0KPj4gKyAgICB9LA0KPj4gKyAgICB7DQo+PiArICAgICAgICAvKiBT
ZW50aW5lbC4gKi8NCj4+ICsgICAgfQ0KPj4gK307DQo+PiArDQo+PiArc3RhdGljIHN0cnVjdCBp
dHNfcXVpcmsqIGdpY3YzX2l0c19maW5kX3F1aXJrKHVpbnQzMl90IGlpZHIpDQo+PiArew0KPj4g
KyAgICBjb25zdCBzdHJ1Y3QgaXRzX3F1aXJrICpxdWlya3MgPSBpdHNfcXVpcmtzOw0KPj4gKw0K
Pj4gKyAgICBmb3IgKCA7IHF1aXJrcy0+ZGVzYzsgcXVpcmtzKysgKQ0KPj4gKyAgICB7DQo+PiAr
ICAgICAgICBpZiAoIHF1aXJrcy0+aWlkciA9PSAocXVpcmtzLT5tYXNrICYgaWlkcikgKQ0KPj4g
KyAgICAgICAgICAgIHJldHVybiAoc3RydWN0IGl0c19xdWlyayAqKXF1aXJrczsNCj4+ICsgICAg
fQ0KPj4gKw0KPj4gKyAgICByZXR1cm4gTlVMTDsNCj4+ICt9DQo+PiArDQo+PiArc3RhdGljIHZv
aWQgZ2ljdjNfaXRzX2VuYWJsZV9xdWlya3Moc3RydWN0IGhvc3RfaXRzICpod19pdHMpDQo+PiAr
ew0KPj4gKyAgICB1aW50MzJfdCBpaWRyID0gcmVhZGxfcmVsYXhlZChod19pdHMtPml0c19iYXNl
ICsgR0lUU19JSURSKTsNCj4+ICsgICAgY29uc3Qgc3RydWN0IGl0c19xdWlyayAqcXVpcmsgPSBn
aWN2M19pdHNfZmluZF9xdWlyayhpaWRyKTsNCj4+ICsNCj4+ICsgICAgaWYgKCBxdWlyayAmJiBx
dWlyay0+aW5pdChod19pdHMpICkNCj4+ICsgICAgICAgIHByaW50aygiR0lDdjM6IGVuYWJsaW5n
IHdvcmthcm91bmQgZm9yIElUUzogJXNcbiIsIHF1aXJrLT5kZXNjKTsNCj4+ICt9DQo+PiArDQo+
PiArc3RhdGljIHZvaWQgZ2ljdjNfaXRzX3ZhbGlkYXRlX3F1aXJrcyh2b2lkKQ0KPj4gK3sNCj4+
ICsgICAgY29uc3Qgc3RydWN0IGl0c19xdWlyayAqcXVpcmsgPSBOVUxMLCAqcHJldiA9IE5VTEw7
DQo+PiArICAgIGNvbnN0IHN0cnVjdCBob3N0X2l0cyAqaHdfaXRzOw0KPj4gKw0KPj4gKyAgICBp
ZiAoIGxpc3RfZW1wdHkoJmhvc3RfaXRzX2xpc3QpICkNCj4+ICsgICAgICAgIHJldHVybjsNCj4+
ICsNCj4+ICsgICAgaHdfaXRzID0gbGlzdF9maXJzdF9lbnRyeSgmaG9zdF9pdHNfbGlzdCwgc3Ry
dWN0IGhvc3RfaXRzLCBlbnRyeSk7DQo+PiArICAgIHByZXYgPSBnaWN2M19pdHNfZmluZF9xdWly
ayhyZWFkbF9yZWxheGVkKGh3X2l0cy0+aXRzX2Jhc2UgKyBHSVRTX0lJRFIpKTsNCj4+ICsNCj4+
ICsgICAgbGlzdF9mb3JfZWFjaF9lbnRyeShod19pdHMsICZob3N0X2l0c19saXN0LCBlbnRyeSkN
Cj4+ICsgICAgew0KPj4gKyAgICAgICAgcXVpcmsgPSBnaWN2M19pdHNfZmluZF9xdWlyayhyZWFk
bF9yZWxheGVkKGh3X2l0cy0+aXRzX2Jhc2UgKyBHSVRTX0lJRFIpKTsNCj4+ICsgICAgICAgIEJV
R19PTihxdWlyayAhPSBwcmV2KTsNCj4+ICsgICAgICAgIHByZXYgPSBxdWlyazsNCj4+ICsgICAg
fQ0KPg0KPiBJIHRoaW5rIHRoaXMgaXMgT0sNCj4NCj4NCj4+ICt9DQo+PiArDQo+PiArdWludDY0
X3QgZ2ljdjNfaXRzX2dldF9jYWNoZWFiaWxpdHkodm9pZCkNCj4+ICt7DQo+PiArICAgIGlmICgg
aXRzX3F1aXJrX2ZsYWdzICYgSE9TVF9JVFNfV09SS0FST1VORF9OQ19OUyApDQo+PiArICAgICAg
ICByZXR1cm4gR0lDX0JBU0VSX0NBQ0hFX25DOw0KPj4gKw0KPj4gKyAgICByZXR1cm4gR0lDX0JB
U0VSX0NBQ0hFX1JhV2FXYjsNCj4+ICt9DQo+PiArDQo+PiArdWludDY0X3QgZ2ljdjNfaXRzX2dl
dF9zaGFyZWFiaWxpdHkodm9pZCkNCj4+ICt7DQo+PiArICAgIGlmICggaXRzX3F1aXJrX2ZsYWdz
ICYgSE9TVF9JVFNfV09SS0FST1VORF9OQ19OUyApDQo+PiArICAgICAgICByZXR1cm4gR0lDX0JB
U0VSX05vblNoYXJlYWJsZTsNCj4+ICsNCj4+ICsgICAgcmV0dXJuIEdJQ19CQVNFUl9Jbm5lclNo
YXJlYWJsZTsNCj4+ICt9DQo+PiArDQo+PiArdW5zaWduZWQgaW50IGdpY3YzX2l0c19nZXRfbWVt
ZmxhZ3Modm9pZCkNCj4+ICt7DQo+PiArICAgIGlmICggaXRzX3F1aXJrX2ZsYWdzICYgSE9TVF9J
VFNfV09SS0FST1VORF8zMkJJVF9BRERSICkNCj4+ICsgICAgICAgIHJldHVybiBNRU1GX2JpdHMo
MzIpOw0KPj4gKw0KPj4gKyAgICByZXR1cm4gMDsNCj4+ICt9DQo+PiArDQo+PiAgIGJvb2wgZ2lj
djNfaXRzX2hvc3RfaGFzX2l0cyh2b2lkKQ0KPj4gICB7DQo+PiAgICAgICByZXR1cm4gIWxpc3Rf
ZW1wdHkoJmhvc3RfaXRzX2xpc3QpOw0KPj4gQEAgLTI4OSwxOSArMzg4LDIzIEBAIHN0YXRpYyB2
b2lkICppdHNfbWFwX2NiYXNlcihzdHJ1Y3QgaG9zdF9pdHMgKml0cykNCj4+ICAgew0KPj4gICAg
ICAgdm9pZCBfX2lvbWVtICpjYmFzZXJlZyA9IGl0cy0+aXRzX2Jhc2UgKyBHSVRTX0NCQVNFUjsN
Cj4+ICAgICAgIHVpbnQ2NF90IHJlZzsNCj4+ICsgICAgdW5zaWduZWQgaW50IG9yZGVyOw0KPj4g
ICAgICAgdm9pZCAqYnVmZmVyOw0KPj4NCj4+IC0gICAgcmVnICA9IEdJQ19CQVNFUl9Jbm5lclNo
YXJlYWJsZSA8PCBHSVRTX0JBU0VSX1NIQVJFQUJJTElUWV9TSElGVDsNCj4+ICsgICAgcmVnICA9
IGdpY3YzX2l0c19nZXRfc2hhcmVhYmlsaXR5KCkgPDwgR0lUU19CQVNFUl9TSEFSRUFCSUxJVFlf
U0hJRlQ7DQo+PiAgICAgICByZWcgfD0gR0lDX0JBU0VSX0NBQ0hFX1NhbWVBc0lubmVyIDw8IEdJ
VFNfQkFTRVJfT1VURVJfQ0FDSEVBQklMSVRZX1NISUZUOw0KPj4gLSAgICByZWcgfD0gR0lDX0JB
U0VSX0NBQ0hFX1JhV2FXYiA8PCBHSVRTX0JBU0VSX0lOTkVSX0NBQ0hFQUJJTElUWV9TSElGVDsN
Cj4+ICsgICAgcmVnIHw9IGdpY3YzX2l0c19nZXRfY2FjaGVhYmlsaXR5KCkgPDwgR0lUU19CQVNF
Ul9JTk5FUl9DQUNIRUFCSUxJVFlfU0hJRlQ7DQo+Pg0KPj4gLSAgICBidWZmZXIgPSBfeHphbGxv
YyhJVFNfQ01EX1FVRVVFX1NaLCBTWl82NEspOw0KPj4gKyAgICBvcmRlciA9IGdldF9vcmRlcl9m
cm9tX2J5dGVzKG1heChJVFNfQ01EX1FVRVVFX1NaLCBTWl82NEspKTsNCj4+ICsgICAgYnVmZmVy
ID0gYWxsb2NfeGVuaGVhcF9wYWdlcyhvcmRlciwgZ2ljdjNfaXRzX2dldF9tZW1mbGFncygpKTsN
Cj4+ICAgICAgIGlmICggIWJ1ZmZlciApDQo+PiAgICAgICAgICAgcmV0dXJuIE5VTEw7DQo+Pg0K
Pj4gKyAgICBtZW1zZXQoYnVmZmVyLCAwLCBQQUdFX1NJWkUgPDwgb3JkZXIpOw0KPj4gKw0KPj4g
ICAgICAgaWYgKCB2aXJ0X3RvX21hZGRyKGJ1ZmZlcikgJiB+R0VOTUFTSyg1MSwgMTIpICkNCj4+
ICAgICAgIHsNCj4+IC0gICAgICAgIHhmcmVlKGJ1ZmZlcik7DQo+PiArICAgICAgICBmcmVlX3hl
bmhlYXBfcGFnZXMoYnVmZmVyLCBvcmRlcik7DQo+PiAgICAgICAgICAgcmV0dXJuIE5VTEw7DQo+
PiAgICAgICB9DQo+Pg0KPj4gQEAgLTM0MCwxMSArNDQzLDEyIEBAIHN0YXRpYyBpbnQgaXRzX21h
cF9iYXNlcih2b2lkIF9faW9tZW0gKmJhc2VyZWcsIHVpbnQ2NF90IHJlZ2MsDQo+PiAgICAgICB1
bnNpZ25lZCBpbnQgZW50cnlfc2l6ZSA9IEdJVFNfQkFTRVJfRU5UUllfU0laRShyZWdjKTsNCj4+
ICAgICAgIHVuc2lnbmVkIGludCBwYWdlc3ogPSAyOyAgICAvKiB0cnkgNjRLIHBhZ2VzIGZpcnN0
LCB0aGVuIGdvIGRvd24uICovDQo+PiAgICAgICB1bnNpZ25lZCBpbnQgdGFibGVfc2l6ZTsNCj4+
ICsgICAgdW5zaWduZWQgaW50IG9yZGVyOw0KPj4gICAgICAgdm9pZCAqYnVmZmVyOw0KPj4NCj4+
IC0gICAgYXR0ciAgPSBHSUNfQkFTRVJfSW5uZXJTaGFyZWFibGUgPDwgR0lUU19CQVNFUl9TSEFS
RUFCSUxJVFlfU0hJRlQ7DQo+PiArICAgIGF0dHIgID0gZ2ljdjNfaXRzX2dldF9zaGFyZWFiaWxp
dHkoKSA8PCBHSVRTX0JBU0VSX1NIQVJFQUJJTElUWV9TSElGVDsNCj4+ICAgICAgIGF0dHIgfD0g
R0lDX0JBU0VSX0NBQ0hFX1NhbWVBc0lubmVyIDw8IEdJVFNfQkFTRVJfT1VURVJfQ0FDSEVBQklM
SVRZX1NISUZUOw0KPj4gLSAgICBhdHRyIHw9IEdJQ19CQVNFUl9DQUNIRV9SYVdhV2IgPDwgR0lU
U19CQVNFUl9JTk5FUl9DQUNIRUFCSUxJVFlfU0hJRlQ7DQo+PiArICAgIGF0dHIgfD0gZ2ljdjNf
aXRzX2dldF9jYWNoZWFiaWxpdHkoKSA8PCBHSVRTX0JBU0VSX0lOTkVSX0NBQ0hFQUJJTElUWV9T
SElGVDsNCj4+DQo+PiAgICAgICAvKg0KPj4gICAgICAgICogU2V0dXAgdGhlIEJBU0UgcmVnaXN0
ZXIgd2l0aCB0aGUgYXR0cmlidXRlcyB0aGF0IHdlIGxpa2UuIFRoZW4gcmVhZA0KPj4gQEAgLTM1
NywxMyArNDYxLDE2IEBAIHJldHJ5Og0KPj4gICAgICAgLyogVGhlIEJBU0UgcmVnaXN0ZXJzIHN1
cHBvcnQgYXQgbW9zdCAyNTYgcGFnZXMuICovDQo+PiAgICAgICB0YWJsZV9zaXplID0gbWluKHRh
YmxlX3NpemUsIDI1NlUgPDwgQkFTRVJfUEFHRV9CSVRTKHBhZ2VzeikpOw0KPj4NCj4+IC0gICAg
YnVmZmVyID0gX3h6YWxsb2ModGFibGVfc2l6ZSwgQklUKEJBU0VSX1BBR0VfQklUUyhwYWdlc3op
LCBVTCkpOw0KPj4gKyAgICBvcmRlciA9IGdldF9vcmRlcl9mcm9tX2J5dGVzKG1heCh0YWJsZV9z
aXplLCBCSVQoQkFTRVJfUEFHRV9CSVRTKHBhZ2VzeiksIFUpKSk7DQo+PiArICAgIGJ1ZmZlciA9
IGFsbG9jX3hlbmhlYXBfcGFnZXMob3JkZXIsIGdpY3YzX2l0c19nZXRfbWVtZmxhZ3MoKSk7DQo+
PiAgICAgICBpZiAoICFidWZmZXIgKQ0KPj4gICAgICAgICAgIHJldHVybiAtRU5PTUVNOw0KPj4N
Cj4+ICsgICAgbWVtc2V0KGJ1ZmZlciwgMCwgUEFHRV9TSVpFIDw8IG9yZGVyKTsNCj4+ICsNCj4+
ICAgICAgIGlmICggIWNoZWNrX2Jhc2VyX3BoeXNfYWRkcihidWZmZXIsIEJBU0VSX1BBR0VfQklU
UyhwYWdlc3opKSApDQo+PiAgICAgICB7DQo+PiAtICAgICAgICB4ZnJlZShidWZmZXIpOw0KPj4g
KyAgICAgICAgZnJlZV94ZW5oZWFwX3BhZ2VzKGJ1ZmZlciwgb3JkZXIpOw0KPj4gICAgICAgICAg
IHJldHVybiAtRVJBTkdFOw0KPj4gICAgICAgfQ0KPj4NCj4+IEBAIC0zOTYsNyArNTAzLDcgQEAg
cmV0cnk6DQo+PiAgICAgICBpZiAoICgocmVnYyA+PiBHSVRTX0JBU0VSX1BBR0VfU0laRV9TSElG
VCkgJiAweDNVTCkgPT0gcGFnZXN6ICkNCj4+ICAgICAgICAgICByZXR1cm4gMDsNCj4+DQo+PiAt
ICAgIHhmcmVlKGJ1ZmZlcik7DQo+PiArICAgIGZyZWVfeGVuaGVhcF9wYWdlcyhidWZmZXIsIG9y
ZGVyKTsNCj4+DQo+PiAgICAgICBpZiAoIHBhZ2Vzei0tID4gMCApDQo+PiAgICAgICAgICAgZ290
byByZXRyeTsNCj4+IEBAIC00NTMsNiArNTYwLDggQEAgc3RhdGljIGludCBnaWN2M19pdHNfaW5p
dF9zaW5nbGVfaXRzKHN0cnVjdCBob3N0X2l0cyAqaHdfaXRzKQ0KPj4gICAgICAgaWYgKCByZXQg
KQ0KPj4gICAgICAgICAgIHJldHVybiByZXQ7DQo+Pg0KPj4gKyAgICBnaWN2M19pdHNfZW5hYmxl
X3F1aXJrcyhod19pdHMpOw0KPj4gKw0KPj4gICAgICAgcmVnID0gcmVhZHFfcmVsYXhlZChod19p
dHMtPml0c19iYXNlICsgR0lUU19UWVBFUik7DQo+PiAgICAgICBod19pdHMtPmRldmlkX2JpdHMg
PSBHSVRTX1RZUEVSX0RFVklDRV9JRF9CSVRTKHJlZyk7DQo+PiAgICAgICBod19pdHMtPmV2aWRf
Yml0cyA9IEdJVFNfVFlQRVJfRVZFTlRfSURfQklUUyhyZWcpOw0KPj4gQEAgLTUzMCw3ICs2Mzks
NyBAQCBzdGF0aWMgaW50IHJlbW92ZV9tYXBwZWRfZ3Vlc3RfZGV2aWNlKHN0cnVjdCBpdHNfZGV2
aWNlICpkZXYpDQo+PiAgICAgICAgICAgcHJpbnRrKFhFTkxPR19XQVJOSU5HICJDYW4ndCB1bm1h
cCBob3N0IElUUyBkZXZpY2UgMHgleFxuIiwNCj4+ICAgICAgICAgICAgICAgICAgZGV2LT5ob3N0
X2RldmlkKTsNCj4+DQo+PiAtICAgIHhmcmVlKGRldi0+aXR0X2FkZHIpOw0KPj4gKyAgICBmcmVl
X3hlbmhlYXBfcGFnZXMoZGV2LT5pdHRfYWRkciwgZGV2LT5pdHRfb3JkZXIpOw0KPj4gICAgICAg
eGZyZWUoZGV2LT5wZW5kX2lycXMpOw0KPj4gICAgICAgeGZyZWUoZGV2LT5ob3N0X2xwaV9ibG9j
a3MpOw0KPj4gICAgICAgeGZyZWUoZGV2KTsNCj4+IEBAIC02MTksNiArNzI4LDcgQEAgaW50IGdp
Y3YzX2l0c19tYXBfZ3Vlc3RfZGV2aWNlKHN0cnVjdCBkb21haW4gKmQsDQo+PiAgICAgICBzdHJ1
Y3QgaXRzX2RldmljZSAqZGV2ID0gTlVMTDsNCj4+ICAgICAgIHN0cnVjdCByYl9ub2RlICoqbmV3
ID0gJmQtPmFyY2gudmdpYy5pdHNfZGV2aWNlcy5yYl9ub2RlLCAqcGFyZW50ID0gTlVMTDsNCj4+
ICAgICAgIGludCBpLCByZXQgPSAtRU5PRU5UOyAgICAgIC8qICJpIiBtdXN0IGJlIHNpZ25lZCB0
byBjaGVjayBmb3IgPj0gMCBiZWxvdy4gKi8NCj4+ICsgICAgdW5zaWduZWQgaW50IG9yZGVyOw0K
Pj4NCj4+ICAgICAgIGh3X2l0cyA9IGdpY3YzX2l0c19maW5kX2J5X2Rvb3JiZWxsKGhvc3RfZG9v
cmJlbGwpOw0KPj4gICAgICAgaWYgKCAhaHdfaXRzICkNCj4+IEBAIC02ODEsMTAgKzc5MSwxMyBA
QCBpbnQgZ2ljdjNfaXRzX21hcF9ndWVzdF9kZXZpY2Uoc3RydWN0IGRvbWFpbiAqZCwNCj4+ICAg
ICAgIHJldCA9IC1FTk9NRU07DQo+Pg0KPj4gICAgICAgLyogQW4gSW50ZXJydXB0IFRyYW5zbGF0
aW9uIFRhYmxlIG5lZWRzIHRvIGJlIDI1Ni1ieXRlIGFsaWduZWQuICovDQo+PiAtICAgIGl0dF9h
ZGRyID0gX3h6YWxsb2MobnJfZXZlbnRzICogaHdfaXRzLT5pdHRlX3NpemUsIDI1Nik7DQo+PiAr
ICAgIG9yZGVyID0gZ2V0X29yZGVyX2Zyb21fYnl0ZXMobWF4KG5yX2V2ZW50cyAqIGh3X2l0cy0+
aXR0ZV9zaXplLCAodW5zaWduZWQgbG9uZykyNTYpKTsNCj4+ICsgICAgaXR0X2FkZHIgPSBhbGxv
Y194ZW5oZWFwX3BhZ2VzKG9yZGVyLCBnaWN2M19pdHNfZ2V0X21lbWZsYWdzKCkpOw0KPj4gICAg
ICAgaWYgKCAhaXR0X2FkZHIgKQ0KPj4gICAgICAgICAgIGdvdG8gb3V0X3VubG9jazsNCj4+DQo+
PiArICAgIG1lbXNldChpdHRfYWRkciwgMCwgUEFHRV9TSVpFIDw8IG9yZGVyKTsNCj4+ICsNCj4+
ICAgICAgIGNsZWFuX2FuZF9pbnZhbGlkYXRlX2RjYWNoZV92YV9yYW5nZShpdHRfYWRkciwNCj4+
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBucl9ldmVudHMgKiBo
d19pdHMtPml0dGVfc2l6ZSk7DQo+Pg0KPj4gQEAgLTcxOCw2ICs4MzEsNyBAQCBpbnQgZ2ljdjNf
aXRzX21hcF9ndWVzdF9kZXZpY2Uoc3RydWN0IGRvbWFpbiAqZCwNCj4+ICAgICAgICAgICBnb3Rv
IG91dF91bmxvY2s7DQo+Pg0KPj4gICAgICAgZGV2LT5pdHRfYWRkciA9IGl0dF9hZGRyOw0KPj4g
KyAgICBkZXYtPml0dF9vcmRlciA9IG9yZGVyOw0KPj4gICAgICAgZGV2LT5od19pdHMgPSBod19p
dHM7DQo+PiAgICAgICBkZXYtPmd1ZXN0X2Rvb3JiZWxsID0gZ3Vlc3RfZG9vcmJlbGw7DQo+PiAg
ICAgICBkZXYtPmd1ZXN0X2RldmlkID0gZ3Vlc3RfZGV2aWQ7DQo+PiBAQCAtNzc1LDcgKzg4OSw4
IEBAIG91dDoNCj4+ICAgICAgICAgICB4ZnJlZShkZXYtPnBlbmRfaXJxcyk7DQo+PiAgICAgICAg
ICAgeGZyZWUoZGV2LT5ob3N0X2xwaV9ibG9ja3MpOw0KPj4gICAgICAgfQ0KPj4gLSAgICB4ZnJl
ZShpdHRfYWRkcik7DQo+PiArICAgIGlmICggaXR0X2FkZHIgKQ0KPj4gKyAgICAgICAgZnJlZV94
ZW5oZWFwX3BhZ2VzKGl0dF9hZGRyLCBvcmRlcik7DQo+PiAgICAgICB4ZnJlZShkZXYpOw0KPj4N
Cj4+ICAgICAgIHJldHVybiByZXQ7DQo+PiBAQCAtMTA4OSw2ICsxMjA0LDggQEAgaW50IGdpY3Yz
X2l0c19pbml0KHZvaWQpDQo+PiAgICAgICAgICAgICAgIHJldHVybiByZXQ7DQo+PiAgICAgICB9
DQo+Pg0KPj4gKyAgICBnaWN2M19pdHNfdmFsaWRhdGVfcXVpcmtzKCk7DQo+PiArDQo+PiAgICAg
ICByZXR1cm4gMDsNCj4+ICAgfQ0KPj4NCj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vZ2lj
LXYzLWxwaS5jIGIveGVuL2FyY2gvYXJtL2dpYy12My1scGkuYw0KPj4gaW5kZXggZGU0YjBlYjRh
NC4uYTg3ODNlN2Q5NSAxMDA2NDQNCj4+IC0tLSBhL3hlbi9hcmNoL2FybS9naWMtdjMtbHBpLmMN
Cj4+ICsrKyBiL3hlbi9hcmNoL2FybS9naWMtdjMtbHBpLmMNCj4+IEBAIC0yMjcsNiArMjI3LDcg
QEAgdm9pZCBnaWN2M19scGlfdXBkYXRlX2hvc3RfZW50cnkodWludDMyX3QgaG9zdF9scGksIGlu
dCBkb21haW5faWQsDQo+PiAgIHN0YXRpYyBpbnQgZ2ljdjNfbHBpX2FsbG9jYXRlX3BlbmR0YWJs
ZSh1bnNpZ25lZCBpbnQgY3B1KQ0KPj4gICB7DQo+PiAgICAgICB2b2lkICpwZW5kdGFibGU7DQo+
PiArICAgIHVuc2lnbmVkIGludCBvcmRlcjsNCj4+DQo+PiAgICAgICBpZiAoIHBlcl9jcHUobHBp
X3JlZGlzdCwgY3B1KS5wZW5kaW5nX3RhYmxlICkNCj4+ICAgICAgICAgICByZXR1cm4gLUVCVVNZ
Ow0KPj4gQEAgLTIzNyw3ICsyMzgsOCBAQCBzdGF0aWMgaW50IGdpY3YzX2xwaV9hbGxvY2F0ZV9w
ZW5kdGFibGUodW5zaWduZWQgaW50IGNwdSkNCj4+ICAgICAgICAqIFRoZSBHSUN2MyBpbXBvc2Vz
IGEgNjRLQiBhbGlnbm1lbnQgcmVxdWlyZW1lbnQsIGFsc28gcmVxdWlyZXMNCj4+ICAgICAgICAq
IHBoeXNpY2FsbHkgY29udGlndW91cyBtZW1vcnkuDQo+PiAgICAgICAgKi8NCj4+IC0gICAgcGVu
ZHRhYmxlID0gX3h6YWxsb2MobHBpX2RhdGEubWF4X2hvc3RfbHBpX2lkcyAvIDgsIFNaXzY0Syk7
DQo+PiArICAgIG9yZGVyID0gZ2V0X29yZGVyX2Zyb21fYnl0ZXMobWF4KGxwaV9kYXRhLm1heF9o
b3N0X2xwaV9pZHMgLyA4LCAodW5zaWduZWQgbG9uZylTWl82NEspKTsNCj4+ICsgICAgcGVuZHRh
YmxlID0gYWxsb2NfeGVuaGVhcF9wYWdlcyhvcmRlciwgZ2ljdjNfaXRzX2dldF9tZW1mbGFncygp
KTsNCj4+ICAgICAgIGlmICggIXBlbmR0YWJsZSApDQo+PiAgICAgICAgICAgcmV0dXJuIC1FTk9N
RU07DQo+DQo+IEkgdGhpbmsgd2UgbWlnaHQgbmVlZCB0byB6ZXJvIHRoZSBtZW1vcnksIGFzIHdl
IHN3aXRjaGVkIGZyb20gX3h6YWxsb2MNCj4gdG8gYWxsb2NfeGVuaGVhcF9wYWdlcy4NClNvbWVo
b3cgbWlzc2VkIHRoYXQgb25lLCB3aWxsIGZpeCBpbiB2My4NCg0KPg0KPg0KPj4gQEAgLTI3Miw5
ICsyNzQsOSBAQCBzdGF0aWMgaW50IGdpY3YzX2xwaV9zZXRfcGVuZHRhYmxlKHZvaWQgX19pb21l
bSAqcmRpc3RfYmFzZSkNCj4+DQo+PiAgICAgICBBU1NFUlQoISh2aXJ0X3RvX21hZGRyKHBlbmR0
YWJsZSkgJiB+R0VOTUFTSyg1MSwgMTYpKSk7DQo+Pg0KPj4gLSAgICB2YWwgID0gR0lDX0JBU0VS
X0NBQ0hFX1JhV2FXYiA8PCBHSUNSX1BFTkRCQVNFUl9JTk5FUl9DQUNIRUFCSUxJVFlfU0hJRlQ7
DQo+PiArICAgIHZhbCAgPSBnaWN2M19pdHNfZ2V0X2NhY2hlYWJpbGl0eSgpIDw8IEdJQ1JfUEVO
REJBU0VSX0lOTkVSX0NBQ0hFQUJJTElUWV9TSElGVDsNCj4+ICAgICAgIHZhbCB8PSBHSUNfQkFT
RVJfQ0FDSEVfU2FtZUFzSW5uZXIgPDwgR0lDUl9QRU5EQkFTRVJfT1VURVJfQ0FDSEVBQklMSVRZ
X1NISUZUOw0KPj4gLSAgICB2YWwgfD0gR0lDX0JBU0VSX0lubmVyU2hhcmVhYmxlIDw8IEdJQ1Jf
UEVOREJBU0VSX1NIQVJFQUJJTElUWV9TSElGVDsNCj4+ICsgICAgdmFsIHw9IGdpY3YzX2l0c19n
ZXRfc2hhcmVhYmlsaXR5KCkgPDwgR0lDUl9QRU5EQkFTRVJfU0hBUkVBQklMSVRZX1NISUZUOw0K
Pj4gICAgICAgdmFsIHw9IEdJQ1JfUEVOREJBU0VSX1BUWjsNCj4+ICAgICAgIHZhbCB8PSB2aXJ0
X3RvX21hZGRyKHBlbmR0YWJsZSk7DQo+Pg0KPj4gQEAgLTMwMCwxMCArMzAyLDExIEBAIHN0YXRp
YyBpbnQgZ2ljdjNfbHBpX3NldF9wZW5kdGFibGUodm9pZCBfX2lvbWVtICpyZGlzdF9iYXNlKQ0K
Pj4gICBzdGF0aWMgaW50IGdpY3YzX2xwaV9zZXRfcHJvcHRhYmxlKHZvaWQgX19pb21lbSAqIHJk
aXN0X2Jhc2UpDQo+PiAgIHsNCj4+ICAgICAgIHVpbnQ2NF90IHJlZzsNCj4+ICsgICAgdW5zaWdu
ZWQgaW50IG9yZGVyOw0KPj4NCj4+IC0gICAgcmVnICA9IEdJQ19CQVNFUl9DQUNIRV9SYVdhV2Ig
PDwgR0lDUl9QUk9QQkFTRVJfSU5ORVJfQ0FDSEVBQklMSVRZX1NISUZUOw0KPj4gKyAgICByZWcg
ID0gZ2ljdjNfaXRzX2dldF9jYWNoZWFiaWxpdHkoKSA8PCBHSUNSX1BST1BCQVNFUl9JTk5FUl9D
QUNIRUFCSUxJVFlfU0hJRlQ7DQo+PiAgICAgICByZWcgfD0gR0lDX0JBU0VSX0NBQ0hFX1NhbWVB
c0lubmVyIDw8IEdJQ1JfUFJPUEJBU0VSX09VVEVSX0NBQ0hFQUJJTElUWV9TSElGVDsNCj4+IC0g
ICAgcmVnIHw9IEdJQ19CQVNFUl9Jbm5lclNoYXJlYWJsZSA8PCBHSUNSX1BST1BCQVNFUl9TSEFS
RUFCSUxJVFlfU0hJRlQ7DQo+PiArICAgIHJlZyB8PSBnaWN2M19pdHNfZ2V0X3NoYXJlYWJpbGl0
eSgpIDw8IEdJQ1JfUFJPUEJBU0VSX1NIQVJFQUJJTElUWV9TSElGVDsNCj4+DQo+PiAgICAgICAv
Kg0KPj4gICAgICAgICogVGhlIHByb3BlcnR5IHRhYmxlIGlzIHNoYXJlZCBhY3Jvc3MgYWxsIHJl
ZGlzdHJpYnV0b3JzLCBzbyBhbGxvY2F0ZQ0KPj4gQEAgLTMxMiw3ICszMTUsMTAgQEAgc3RhdGlj
IGludCBnaWN2M19scGlfc2V0X3Byb3B0YWJsZSh2b2lkIF9faW9tZW0gKiByZGlzdF9iYXNlKQ0K
Pj4gICAgICAgaWYgKCAhbHBpX2RhdGEubHBpX3Byb3BlcnR5ICkNCj4+ICAgICAgIHsNCj4+ICAg
ICAgICAgICAvKiBUaGUgcHJvcGVydHkgdGFibGUgaG9sZHMgb25lIGJ5dGUgcGVyIExQSS4gKi8N
Cj4+IC0gICAgICAgIHZvaWQgKnRhYmxlID0gX3htYWxsb2MobHBpX2RhdGEubWF4X2hvc3RfbHBp
X2lkcywgU1pfNEspOw0KPj4gKyAgICAgICAgdm9pZCAqdGFibGU7DQo+PiArDQo+PiArICAgICAg
ICBvcmRlciA9IGdldF9vcmRlcl9mcm9tX2J5dGVzKG1heChscGlfZGF0YS5tYXhfaG9zdF9scGlf
aWRzLCAodW5zaWduZWQgbG9uZylTWl80SykpOw0KPg0KPiBOSVQ6IEkgYW0gY3VyaW91cyB3aGV0
aGVyIHRoZSB1bnNpZ25lZCBsb25nIGNhc3QgaXMgbmVjZXNzYXJ5DQoNClRoZXkgYXJlIG5lZWRl
ZCB0byBzYXRpc2Z5IGV4cGxpY2l0IHR5cGUgY2hlY2tzIGluIG1pbi9tYXggbWFjcm9zLCB3b24n
dA0KY29tcGlsZSB3aXRob3V0IGl0Lg0KDQo+DQo+DQo+PiArICAgICAgICB0YWJsZSA9IGFsbG9j
X3hlbmhlYXBfcGFnZXMob3JkZXIsIGdpY3YzX2l0c19nZXRfbWVtZmxhZ3MoKSk7DQo+Pg0KPj4g
ICAgICAgICAgIGlmICggIXRhYmxlICkNCj4+ICAgICAgICAgICAgICAgcmV0dXJuIC1FTk9NRU07
DQo+PiBAQCAtMzIwLDcgKzMyNiw3IEBAIHN0YXRpYyBpbnQgZ2ljdjNfbHBpX3NldF9wcm9wdGFi
bGUodm9pZCBfX2lvbWVtICogcmRpc3RfYmFzZSkNCj4+ICAgICAgICAgICAvKiBNYWtlIHN1cmUg
dGhlIHBoeXNpY2FsIGFkZHJlc3MgY2FuIGJlIGVuY29kZWQgaW4gdGhlIHJlZ2lzdGVyLiAqLw0K
Pj4gICAgICAgICAgIGlmICggKHZpcnRfdG9fbWFkZHIodGFibGUpICYgfkdFTk1BU0soNTEsIDEy
KSkgKQ0KPj4gICAgICAgICAgIHsNCj4+IC0gICAgICAgICAgICB4ZnJlZSh0YWJsZSk7DQo+PiAr
ICAgICAgICAgICAgZnJlZV94ZW5oZWFwX3BhZ2VzKHRhYmxlLCBvcmRlcik7DQo+PiAgICAgICAg
ICAgICAgIHJldHVybiAtRVJBTkdFOw0KPj4gICAgICAgICAgIH0NCj4+ICAgICAgICAgICBtZW1z
ZXQodGFibGUsIEdJQ19QUklfSVJRIHwgTFBJX1BST1BfUkVTMSwgTUFYX05SX0hPU1RfTFBJUyk7
DQo+PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2dpY192M19pdHMuaCBi
L3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9naWNfdjNfaXRzLmgNCj4+IGluZGV4IGMyNGQ0NzUy
ZDAuLjA3MzdlNjdhYTYgMTAwNjQ0DQo+PiAtLS0gYS94ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20v
Z2ljX3YzX2l0cy5oDQo+PiArKysgYi94ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vZ2ljX3YzX2l0
cy5oDQo+PiBAQCAtMTEwLDYgKzExMCw5IEBADQo+PiAgICNkZWZpbmUgSE9TVF9JVFNfRkxVU0hf
Q01EX1FVRVVFICAgICAgICAoMVUgPDwgMCkNCj4+ICAgI2RlZmluZSBIT1NUX0lUU19VU0VTX1BU
QSAgICAgICAgICAgICAgICgxVSA8PCAxKQ0KPj4NCj4+ICsjZGVmaW5lIEhPU1RfSVRTX1dPUktB
Uk9VTkRfTkNfTlMgICAgICAgKDFVIDw8IDApDQo+PiArI2RlZmluZSBIT1NUX0lUU19XT1JLQVJP
VU5EXzMyQklUX0FERFIgICgxVSA8PCAxKQ0KPj4gKw0KPj4gICAvKiBXZSBhbGxvY2F0ZSBMUElz
IG9uIHRoZSBob3N0cyBpbiBjaHVua3Mgb2YgMzIgdG8gcmVkdWNlIGhhbmRsaW5nIG92ZXJoZWFk
LiAqLw0KPj4gICAjZGVmaW5lIExQSV9CTE9DSyAgICAgICAgICAgICAgICAgICAgICAgMzJVDQo+
Pg0KPj4gQEAgLTE5Nyw2ICsyMDAsMTEgQEAgc3RydWN0IHBlbmRpbmdfaXJxICpnaWN2M19hc3Np
Z25fZ3Vlc3RfZXZlbnQoc3RydWN0IGRvbWFpbiAqZCwNCj4+ICAgdm9pZCBnaWN2M19scGlfdXBk
YXRlX2hvc3RfZW50cnkodWludDMyX3QgaG9zdF9scGksIGludCBkb21haW5faWQsDQo+PiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IHZpcnRfbHBpKTsNCj4+DQo+
PiArLyogSVRTIHF1aXJrcyBoYW5kbGluZy4gKi8NCj4+ICt1aW50NjRfdCBnaWN2M19pdHNfZ2V0
X2NhY2hlYWJpbGl0eSh2b2lkKTsNCj4+ICt1aW50NjRfdCBnaWN2M19pdHNfZ2V0X3NoYXJlYWJp
bGl0eSh2b2lkKTsNCj4+ICt1bnNpZ25lZCBpbnQgZ2ljdjNfaXRzX2dldF9tZW1mbGFncyh2b2lk
KTsNCj4+ICsNCj4+ICAgI2Vsc2UNCj4+DQo+PiAgICNpZmRlZiBDT05GSUdfQUNQSQ0KPj4gLS0N
Cj4+IDIuMzQuMQ0KPj4NCg0K


From xen-devel-bounces@lists.xenproject.org Mon Jan 13 11:17:27 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Jan 2025 11:17:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870545.1281717 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXIRV-000843-F5; Mon, 13 Jan 2025 11:17:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870545.1281717; Mon, 13 Jan 2025 11:17:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXIRV-00083w-CN; Mon, 13 Jan 2025 11:17:13 +0000
Received: by outflank-mailman (input) for mailman id 870545;
 Mon, 13 Jan 2025 11:17:12 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=HC3z=UF=epam.com=Mykyta_Poturai@srs-se1.protection.inumbo.net>)
 id 1tXIRU-00083q-2H
 for xen-devel@lists.xenproject.org; Mon, 13 Jan 2025 11:17:12 +0000
Received: from EUR02-AM0-obe.outbound.protection.outlook.com
 (mail-am0eur02on2061f.outbound.protection.outlook.com
 [2a01:111:f403:2606::61f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ee2dfa50-d19f-11ef-99a4-01e77a169b0f;
 Mon, 13 Jan 2025 12:17:10 +0100 (CET)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by DU4PR03MB10910.eurprd03.prod.outlook.com
 (2603:10a6:10:593::19) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8335.15; Mon, 13 Jan
 2025 11:17:07 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971%5]) with mapi id 15.20.8335.017; Mon, 13 Jan 2025
 11:17:07 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ee2dfa50-d19f-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=mYCaSdGufDsjRiKjx9X+oJDsZGV1Zoymhog0rJmK/CNxwmtHTQibZoRUk2RSje2rIlQFQ2Tsf4Xtrv28jXisA3J8oXTh+W+rpajQuPoIjcJ+ru0Rqh8cCKaDvR1aaPSvMfhsymfeBrj+8vqPN+0lnVOoylLKpH/gXCPZhScVPuNFHTxrxYbtqsONZEVZUx+6YKJd/AfOR6DqgHxqRoafRknNa28r4N14KhiGAPT/suZbei/KAJN9OJgmuJV87IjjJu8WcHyov5bidKQMgTEBavo3/iWuzorUeX+yFci9Bx6I/xTI3uX+iuF9c0GK+6txXe8kCDKh3b/v5YWKt/cvzQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=vgURsy4YwBnvPiRigmAIYMMg7+Fk6RmqJNdDHl5Jio8=;
 b=Xyd9+D768aaAfNfzyE9vB/JyV6B8ZQeWjGibBSYWts5GpdCfnG1r/g2NnTIuThGEcXFP77EnASifO1LSqVpWyparbW3kTQG1EtSM3TK4ReP33oe+PJLP85lXFJJi/Ixc3qv0IU1A2711IZhyLCA4i3K/pGM3/yrLSIjcgloV4QtdXIRFIH1PIRM/zqEKjXAlgEHErilegjYIaZHxdWczb187vFQj/WMUWKUcRqpYzjSIRdDtYZfHMidOuN7cCg20edgBH7WruHJLcfBysfFEKqhRIe5f8KlkGC1ySB+qAaHzUATN9NjLwZ8+mJGXMj1Q/vBH8eTFu24O0SaflC/EAA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=vgURsy4YwBnvPiRigmAIYMMg7+Fk6RmqJNdDHl5Jio8=;
 b=dNAdtvF0Qm/Sq1SZ6p3RSujmnxm1rxvolSVs2viiWttDM2r545NsZDT7Rt+rK4mqpQG98uuArTZkeIv9rR+cY05URKgdeauF5hSCDZuET5thKeChA/gikyRaJhBIAoadwbN2SzAn9RbRXCVeZl9m8T40mRA+kvRrs6n5G4UTMAMS54X35KqoWHG8ZE/GaY4J1RXoynJ9+Ks7Od1AAezgPhD2p/8n7Ca0KeyX6WLK5Vybeh/2lAWRY4UIYUw1hNVixQ4uxSsmaKazGiUoKHQjOU8md+EMXwHlY+FqymPsOljRl9nNxU5UW4QGTTP0F0xDasxRWskWKkbEp3aY5d824A==
From: Mykyta Poturai <Mykyta_Poturai@epam.com>
To: Stewart Hildebrand <stewart.hildebrand@amd.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
	<julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>, Michal Orzel
	<michal.orzel@amd.com>, Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>, Jan
 Beulich <jbeulich@suse.com>, Paul Durrant <paul@xen.org>,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>, Rahul Singh
	<rahul.singh@arm.com>, Andrew Cooper <andrew.cooper3@citrix.com>, George
 Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>
Subject: Re: [PATCH v6 0/9] SMMU handling for PCIe Passthrough on ARM
Thread-Topic: [PATCH v6 0/9] SMMU handling for PCIe Passthrough on ARM
Thread-Index: AQHaEzqaKbzl/PvS3EG/aAIeGF3kObMXMuYA
Date: Mon, 13 Jan 2025 11:17:07 +0000
Message-ID: <9b2740a0-7347-4b91-a687-1e8e4c120288@epam.com>
References: <20231109182716.367119-1-stewart.hildebrand@amd.com>
In-Reply-To: <20231109182716.367119-1-stewart.hildebrand@amd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB10102:EE_|DU4PR03MB10910:EE_
x-ms-office365-filtering-correlation-id: c959017f-bb66-4ba1-4a6a-08dd33c3d0f4
x-ld-processed: b41b72d0-4e9f-4c26-8a69-f949f367c91d,ExtAddr
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|366016|1800799024|376014|7416014|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?RXNubWNNejhGOWE5cHFudUp4b3hpRE9WZXBITThJMThpNlF1NjN1NXdhTzRz?=
 =?utf-8?B?ZjUyQjVMZW14cjAyWkVqOTVvekxHQlMvQWhuY0pwN0FidXZzdUpMVDd2czBB?=
 =?utf-8?B?aFBZM1VkemRqdEhSbDFaVHhoNlVRbHU4dXFyTlVKWTRNT2lHWFlRV0szMklN?=
 =?utf-8?B?OVl4bGRqd0NSTVpXVzVoT1cweGwxejR1b2c2QmxFY0lLZktDbFdEK3BFblN1?=
 =?utf-8?B?bHpHMnJ2U0xkckFKY2FHL3RYbi81R2g2VEYzUjMvTFV6ZjNoOUVNa3BlMjlJ?=
 =?utf-8?B?OVUzemg2Nzh5K2V5RkxJeFNUK241MXFzMnRMYThYUnhSK2kxYmxwbGs4aGcv?=
 =?utf-8?B?elM1ZVN0djNtNmxMM2xoNElkTXlOUHpxNDNrVHdWd1dkMzFpSm5aZ082Si95?=
 =?utf-8?B?RFJ2QnNJZ0JzalRCUlhpRTd4RG80V1VMN1ordHVoYkJMMzVIYXdhK01aMXdR?=
 =?utf-8?B?bWl2Q3F4K1JDS3NCK1czNVFoWEpSOExHOTNzcVpXU1JoOFdZOU1KaDJCeXFy?=
 =?utf-8?B?d0pubDg1NU1na09KKzQvc0NWemFxdHJkR3ErdENoUnZjRUZBblBnY1pLZWFQ?=
 =?utf-8?B?NzZUcWJSRDNNV0x4V0hJNjhpQWJRb0I0SVRtU1djd3hsU1pLUHdUOHA0QW5F?=
 =?utf-8?B?cUowQ0pTVWt0aVVFYlRCRmdjeGgyV21UMmQyRGtJaDhOTExXTC9Ldi94cUkx?=
 =?utf-8?B?Y3hzK0NNdHBuUWhZQ1gyQkxEQzhEOWNndFdQRU9QdFFxUE1nZ2VtODZBR1M2?=
 =?utf-8?B?YzJSRk9YRzk1dnlYWWZRS1JtZG5rR1JnZlNnQ1dQZm9NYTlWRGdsbVJ4bGlv?=
 =?utf-8?B?S0hKWE1lNTdIenRORXQ1ZHAvYWlFc1kvbEFjamZMNENycjAvSUxKbW5JTlJl?=
 =?utf-8?B?b1NMNytxeDhuK0RGbXQyRGIwWVRaTExjMlc3QlNmbXV3TER2enNsRWljS1pS?=
 =?utf-8?B?M3haSWxsZGljTnRrQ1lGMWZRMGNLTjJjZC9qT0Q5VXRLUkpjKzRTWno3Z0gy?=
 =?utf-8?B?LzBMQ20wVjlUc0FSeno0VnpDTkVWb2wvWk1icVpNdlBvWGJtL3BoRnpXUHQx?=
 =?utf-8?B?RURKbEV5S0hremtEdTIxZ0pYbU9aZmNzSnI3OUJkaEwwcGplSU9CWkpDbGVR?=
 =?utf-8?B?Z1doVHFDaTY4dG5Kai9takRVYWpJV2xBeGUySG5JZEpHaGYzN3FIa3FCRTRI?=
 =?utf-8?B?Sm1wak83MktuMGFtWkptekVkUDlGaHRsMmE3Nk14MGlkK281NVpwckdPS0xu?=
 =?utf-8?B?cU1DYjFrenI5NENnUFdranY2VlpoTmx1NkdTaXh6Yms4amZKcStlSno5cHpI?=
 =?utf-8?B?MytxaGhRVkJIVWVvVUR5UTQxWGp0aHp5NENudXNTK3hGeVRwREZZaXdjaHND?=
 =?utf-8?B?bUh0YVBoT1pmZFFlYVhuQ2lBMGc4bFRmNFVXVzRMSm5ZRHZRT0tvS25CNENi?=
 =?utf-8?B?V09IeDhWb3VhVXNxdzNjb1NMcjk0bmg3dkRrU2xoMlpwK0pKM21pcVdXYTg5?=
 =?utf-8?B?Qlg4VTM5MWk3bWM4NkljK1JMMlVIK0UyL3JrQlpKZVMwRzl3N21hK2tiL0M1?=
 =?utf-8?B?RlJMYzlsYXQ5MVR3SkF1dVZzZUVOVHdJbGlicDM5TG4vVlhjZEhYMEcwT3lv?=
 =?utf-8?B?QnUyUjZRbkF0d3oyelVRakJlQ2M0SUwrM1V3T2QxUEliUW1yQWF5dkdieEhK?=
 =?utf-8?B?U0IvWGx1NlhKc2ZMMFQxY24zZEFyUEw0MldYSFRPdjFkREZacVdPeFhyN3RH?=
 =?utf-8?B?YXZsVjRHTkgxYkh6cU94bHNDUjRxOFdkMUpQWnBmRXR2cGpPeFZKRkx5Y0dF?=
 =?utf-8?B?REVoRlZCdDd3ejY1cHQ4ZGNJTjJlTzZCblNPRjBldDY2M0V0U2d5SzJnNGJw?=
 =?utf-8?B?RmM4L0dlMm1NY3NDakZIUHR4Mm1NOVpNRHc5eU1OUE1WVWc9PQ==?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB10102.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(7416014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?SkkwL0pGVGZqczJKRlBUOHdOMTlHMjJRY0t5SXRJdkdlS3hadW90ajFpeUNI?=
 =?utf-8?B?NmFhSWRVSFdSUXIyWFhPZVFyUWUrTng5bklTU1BuSllveEtpNVFvaWRwS1RF?=
 =?utf-8?B?ODVpREFwak9zeDRWWjI5Z3Nqb3dnUFluRWRISXM5MUN4OGRaNU1vMHVqUEFv?=
 =?utf-8?B?WEdDRzNuWFZzQ2JQQklacmRjNi9aVkhna2lqRWgzSUk5WEd2dzZUdyt1cHpZ?=
 =?utf-8?B?VkdUTDdBU0dzazM4V3hDL2NNUVJ5K0RVTmh3YzM0VFNacFFVSFMrV1BzbjZh?=
 =?utf-8?B?NVFQSnB4a1kyY1ZLQm8vN3dIeFhTSGgrSm03MDVZSlYzcXAwMndibFNHc1I4?=
 =?utf-8?B?UE9IeDlUOFBpdTZ2VlQrMEVXUmN3eFFjV2JFd0hWL3J4a0FOZ0Y3OFkydEtG?=
 =?utf-8?B?VjFucG11bWpTelZLa0drVWs0ajVaR0lad3FPUVJ1a0hnK1ZvdWw0M2hnZVJF?=
 =?utf-8?B?Q0xxdjhWcHc3QjkwRlU3Tk91ZGlBUnRNSmd1VlA2NHk1d1RMS3dCd2VPZEJK?=
 =?utf-8?B?c2ZkTENPcmQ2WGx2a3oyYTExc2lvVWdYbzRua1M0UkpyclZleWRwUENwWTlw?=
 =?utf-8?B?S2tyY1g0RVdzbG1zRGVubnRXdVM2ZVBIOWc4VHpGc3pzMGhqc2tuVUNseVNl?=
 =?utf-8?B?d29kN2NaN1I1VGJFZmRFYjZObmdWNmNVMHlwRHovRm5BT1ZqQXRydHdPR0xS?=
 =?utf-8?B?QzFEV0ZMNmlUekY4ZC9hMTk4S1Mvb0J5eTdVOUpKNkYyeFpuY2ZBWGgwY2xn?=
 =?utf-8?B?K0NhTWZqd2g4QSttS3plZHpXMWlUOTdBeTFCbW9xSFFGdmlzMWZNQkFwTjU2?=
 =?utf-8?B?bWRzdHE3K3g4dVNRWDFjbjB6ZEVGb015STUzb0NueGd0NGZteGc5OWFoK25W?=
 =?utf-8?B?YzJIOEs0eU5kOVVXcWN1bzd6Rk5vQUUvRkl2ZWFjZEZMYndtZW5FVmlja0FQ?=
 =?utf-8?B?dnA3QmlyTEMxRVdCYUc1eWhjM2ZwaWpQbVhmTnNnN05YY044MTlYUnNvdTNB?=
 =?utf-8?B?RDg1aklGV3dqbnJ0MUkzbk5sZS85RWVINlFIR1lXQ0VYNSs1eUtyK0M3Ri83?=
 =?utf-8?B?aHJEa05HUGl6bytWazk1RzVLeWw2b0pPU2NpRTJSV2F0TE9oQ2p5b29hZ05a?=
 =?utf-8?B?V3BscWFMd2xIZ1ZaVk1JN05WRVlBQVh3anBRTGd6eW1rWjZlYWNEd1hDSlNk?=
 =?utf-8?B?ZnRCdXJ1SWU1bHY2b0NUY214STFZc01KeEFLamFsNUtxNnR1azBaNVNtTVd1?=
 =?utf-8?B?OWV2R2tkVHp4cURDcGRVQ1BLaDlZSUlWcDdZMUt2R2c4ZG1kdjJ5enpicGM1?=
 =?utf-8?B?SVVxNEV3eDZLVnY0b2F0R0xBZG9Kb2d6Y2hFaTFVNTlhMFhsVHhxRjZJN3Jp?=
 =?utf-8?B?cTFHZWNmU1VjK3JlQmlZRmFsamJ4eVZiRUhZdUlkN0wxbGEvZnBaUXg5dmdY?=
 =?utf-8?B?RFEwZm9RZGRQYUVkWVY4QjhYYU5DQWNYVnA1bGhnandsa3JxQ3YrNm9ZOFlx?=
 =?utf-8?B?ZFV5SEFaQlJESDR1WVlSVWFMcU4zVVBHZ240aWE3aU1icjN6VHh5VEZFQmJS?=
 =?utf-8?B?QVk2MFFTTTU2QUpMbllmd3k3UWU4ZG1IUzBTakcrZEMxcThzVGprR0U0RWVK?=
 =?utf-8?B?R1p3bkFxMHhiUnI0VE9OVVVHdEorQ2dDeDNnOHo5V3RMSXFKaGNpQThSTlpI?=
 =?utf-8?B?aVdIZ2g5VVU4LzZpRUdLZmFydjRBU3hYL3JjcnFDd05FUFFsMWt2RTdjZ0RW?=
 =?utf-8?B?Z3BZVDVlMTBXblo2QStBUFFoL0xkMGsvSVhRSVdUWDFuV2c0cEdyS1V1Y3Jj?=
 =?utf-8?B?ZWxRc0RHUnY0RTlSSFBLcTV5K2c3TFVMQWVGbEdQWitBYi85NjBaM2IyOEUx?=
 =?utf-8?B?eXVtd0pZdTFMaXQreGc3K0pabGZuQXhJSDJ6ZFpicGlqc3R3eG80QVpNKzBm?=
 =?utf-8?B?Z0VESW1QRXUyT3pKVDhHUjZuWjdpUDU5dWREZzJVbFRhSlNuNUNvTVFtblBp?=
 =?utf-8?B?RTVLSVk3OGRlMFFBQjZXWkViVjBWa0xqNzJVeDNMZXNGUWxYZVplRVcyZE44?=
 =?utf-8?B?ZVNnaHdqN2RFQWZEUTZNT1lyVVVsQjNFZi9OMmw2bUVQUUhIRld4N2lnUkta?=
 =?utf-8?B?VUhZRk5zc3FUVUJBNDRVOWc3a3pQdWU0ekxjZ2hDNStDb3NEbnN5ZGpZeThS?=
 =?utf-8?B?VHc9PQ==?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <E13A43D8BF7D2E42BAE76C73886B0AB7@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PAVPR03MB10102.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c959017f-bb66-4ba1-4a6a-08dd33c3d0f4
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2025 11:17:07.3477
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 40rqBCNdZulKEtWh9hXb6HXxxuCA5WSPVAmESWlSRWsC27i2NhkmWsWK17CN2eycOkP19rNiIjfK9ss3/n4G8Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU4PR03MB10910

T24gMDkuMTEuMjMgMjA6MjcsIFN0ZXdhcnQgSGlsZGVicmFuZCB3cm90ZToNCj4gVGhpcyBzZXJp
ZXMgaW50cm9kdWNlcyBTTU1VIGhhbmRsaW5nIGZvciBQQ0llIHBhc3N0aHJvdWdoIG9uIEFSTS4g
VGhlc2UgcGF0Y2hlcw0KPiBzaG91bGQgYmUgYWJsZSB0byBiZSB1cHN0cmVhbWVkIGluZGVwZW5k
ZW50bHkgZnJvbSB0aGUgdlBDSSBzZXJpZXMgWzFdLiBTZWUgWzJdDQo+IGZvciBub3RlcyBhYm91
dCB0ZXN0IGNhc2VzLg0KPiANCj4gWzFdIGh0dHBzOi8vbGlzdHMueGVucHJvamVjdC5vcmcvYXJj
aGl2ZXMvaHRtbC94ZW4tZGV2ZWwvMjAyMy0xMC9tc2cwMDY2MC5odG1sDQo+IFsyXSBodHRwczov
L2xpc3RzLnhlbnByb2plY3Qub3JnL2FyY2hpdmVzL2h0bWwveGVuLWRldmVsLzIwMjMtMDYvbXNn
MDExMzUuaHRtbA0KPiANCj4gdjUtPnY2Og0KPiAqIGRvbid0IHJldmVydCAoInhlbi9hcm06IEFk
ZCBjbWRsaW5lIGJvb3Qgb3B0aW9uICJwY2ktcGFzc3Rocm91Z2ggPSA8Ym9vbGVhbj4iIikNCj4g
KiBhZGQgKCJ4ZW4vYXJtOiBlbmFibGUgZG9tMCB0byB1c2UgUENJIGRldmljZXMgd2l0aCBwY2kt
cGFzc3Rocm91Z2g9bm8iKQ0KPiANCj4gdjQtPnY1Og0KPiAqIGRyb3AgKCJ4ZW4vYXJtOiBJbXBy
b3ZlIHJlYWRhYmlsaXR5IG9mIGNoZWNrIGZvciByZWdpc3RlcmVkIGRldmljZXMiKQ0KPiAqIGRy
b3AgKCJ4ZW4vYXJtOiBNb3ZlIGlzX3Byb3RlY3RlZCBmbGFnIHRvIHN0cnVjdCBkZXZpY2UiKQ0K
PiAqIGFkZCAoInhlbi9hcm06IGRvbid0IHBhc3MgaW9tbXUgcHJvcGVydGllcyB0byBod2RvbSBm
b3IgaW9tbXUtbWFwIikNCj4gKiBhZGQgKCJ4ZW4vYXJtOiBGaXggbWFwcGluZyBmb3IgUENJIGJy
aWRnZSBtbWlvIHJlZ2lvbiIpDQo+ICogcmV2ZXJ0ICgieGVuL2FybTogQWRkIGNtZGxpbmUgYm9v
dCBvcHRpb24gInBjaS1wYXNzdGhyb3VnaCA9IDxib29sZWFuPiIiKQ0KPiAqIGFkZCAoInhlbi9h
cm06IE1hcCBJVFMgZG9vcmJlbGwgcmVnaXN0ZXIgdG8gSU9NTVUgcGFnZSB0YWJsZXMuIikNCj4g
KiBmaXggdGVzdCBjYXNlICMxIHdpdGggUENJIGRldmljZSBpbiBkb20wDQo+IA0KPiB2My0+djQ6
DQo+ICogc3BsaXQgYSBjaGFuZ2UgZnJvbSAoInhlbi9hcm06IE1vdmUgaXNfcHJvdGVjdGVkIGZs
YWcgdG8gc3RydWN0IGRldmljZSIpIGludG8NCj4gICAgYSBuZXcgc2VwYXJhdGUgcGF0Y2gNCj4g
KiBzZWUgaW5kaXZpZHVhbCBwYXRjaGVzIGZvciBmdXJ0aGVyIGRldGFpbHMNCj4gDQo+IHYyLT52
MzoNCj4gKiBkcm9wICJwY2kvYXJtOiBVc2UgaW9tbXVfYWRkX2R0X3BjaV9kZXZpY2UoKSINCj4g
KiBkcm9wICJSRkM6IHBjaS9hcm06IGRvbid0IGRvIGlvbW11IGNhbGwgZm9yIHBoYW50b20gZnVu
Y3Rpb25zIg0KPiAqIG1vdmUgaW52b2NhdGlvbiBvZiBzaWRlYmFuZCBJRCBtYXBwaW5nIGZ1bmN0
aW9uIHRvIGFkZF9kZXZpY2UoKQ0KPiAgICBwbGF0Zm9ybV9vcHMvaW9tbXVfb3BzIGhvb2sNCj4g
DQo+IHYxLT52MjoNCj4gKiBwaGFudG9tIGRldmljZSBoYW5kbGluZw0KPiAqIHNodWZmbGUgYXJv
dW5kIGlvbW11X2FkZF9kdF9wY2lfZGV2aWNlKCkNCj4gDQo+IE9sZWtzYW5kciBBbmRydXNoY2hl
bmtvICgxKToNCj4gICAgeGVuL2FybTogc21tdXYyOiBBZGQgUENJIGRldmljZXMgc3VwcG9ydCBm
b3IgU01NVXYyDQo+IA0KPiBPbGVrc2FuZHIgVHlzaGNoZW5rbyAoMik6DQo+ICAgIGlvbW11L2Fy
bTogQWRkIGlvbW11X2R0X3hsYXRlKCkNCj4gICAgaW9tbXUvYXJtOiBJbnRyb2R1Y2UgaW9tbXVf
YWRkX2R0X3BjaV9zaWRlYmFuZF9pZHMgQVBJDQo+IA0KPiBSYWh1bCBTaW5naCAoMyk6DQo+ICAg
IHhlbi9hcm06IHNtbXV2MzogQWRkIFBDSSBkZXZpY2VzIHN1cHBvcnQgZm9yIFNNTVV2Mw0KPiAg
ICB4ZW4vYXJtOiBGaXggbWFwcGluZyBmb3IgUENJIGJyaWRnZSBtbWlvIHJlZ2lvbg0KPiAgICB4
ZW4vYXJtOiBNYXAgSVRTIGRvb3JiZWxsIHJlZ2lzdGVyIHRvIElPTU1VIHBhZ2UgdGFibGVzDQo+
IA0KPiBTdGV3YXJ0IEhpbGRlYnJhbmQgKDMpOg0KPiAgICB4ZW4vYXJtOiBkb24ndCBwYXNzIGlv
bW11IHByb3BlcnRpZXMgdG8gaHdkb20gZm9yIGlvbW11LW1hcA0KPiAgICBpb21tdS9hcm06IGlv
bW11X2FkZF9kdF9wY2lfc2lkZWJhbmRfaWRzIHBoYW50b20gaGFuZGxpbmcNCj4gICAgeGVuL2Fy
bTogZW5hYmxlIGRvbTAgdG8gdXNlIFBDSSBkZXZpY2VzIHdpdGggcGNpLXBhc3N0aHJvdWdoPW5v
DQo+IA0KPiAgIHhlbi9hcmNoL2FybS9kZXZpY2UuYyAgICAgICAgICAgICAgICAgfCAgIDIgKy0N
Cj4gICB4ZW4vYXJjaC9hcm0vZG9tYWluX2J1aWxkLmMgICAgICAgICAgIHwgICAyICsNCj4gICB4
ZW4vYXJjaC9hcm0vcGNpL3BjaS5jICAgICAgICAgICAgICAgIHwgICAzICstDQo+ICAgeGVuL2Fy
Y2gvYXJtL3ZnaWMtdjMtaXRzLmMgICAgICAgICAgICB8ICAxNSArKw0KPiAgIHhlbi9jb21tb24v
ZGV2aWNlX3RyZWUuYyAgICAgICAgICAgICAgfCAgOTEgKysrKysrKysrKysrDQo+ICAgeGVuL2Ry
aXZlcnMvcGFzc3Rocm91Z2gvYXJtL3NtbXUtdjMuYyB8IDEzMSArKysrKysrKysrKysrKystLQ0K
PiAgIHhlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FybS9zbW11LmMgICAgfCAxOTkgKysrKysrKysr
KysrKysrKysrKysrKy0tLS0NCj4gICB4ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9kZXZpY2VfdHJl
ZS5jIHwgIDk3ICsrKysrKysrKystLS0NCj4gICB4ZW4vZHJpdmVycy9wY2kvcGh5c2Rldi5jICAg
ICAgICAgICAgIHwgICA2IC0NCj4gICB4ZW4vaW5jbHVkZS94ZW4vZGV2aWNlX3RyZWUuaCAgICAg
ICAgIHwgIDIzICsrKw0KPiAgIHhlbi9pbmNsdWRlL3hlbi9pb21tdS5oICAgICAgICAgICAgICAg
fCAgMjYgKysrLQ0KPiAgIDExIGZpbGVzIGNoYW5nZWQsIDUyOCBpbnNlcnRpb25zKCspLCA2NyBk
ZWxldGlvbnMoLSkNCj4gDQo+IA0KPiBiYXNlLWNvbW1pdDogYmVkZTFjN2UzYjc5MGI2M2YxZmYz
ZWEzZWU0ZTQ3NmIwMTJmZGYyYw0KDQpIaSBTdGV3YXJ0LA0KSSBub3RpY2VkIHRoZXJlIHdhcyBu
byBhY3Rpdml0eSBmb3IgdGhpcyBzZXJpZXMgZm9yIHNvbWUgdGltZS4gQXJlIHlvdSANCnN0aWxs
IHdvcmtpbmcgb24gdGhpcyBvciB3b3VsZCBpdCBiZSBva2F5IGlmIEkgdGFrZSB0aGlzIG92ZXIg
YW5kIHN0YXJ0IA0KcHJlcGFyaW5nIHRoZSBWNz8NCg0KLS0gDQpNeWt5dGE=


From xen-devel-bounces@lists.xenproject.org Mon Jan 13 11:43:12 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Jan 2025 11:43:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870555.1281728 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXIqX-00040R-FT; Mon, 13 Jan 2025 11:43:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870555.1281728; Mon, 13 Jan 2025 11:43:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXIqX-00040K-Br; Mon, 13 Jan 2025 11:43:05 +0000
Received: by outflank-mailman (input) for mailman id 870555;
 Mon, 13 Jan 2025 11:43:03 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=+JSt=UF=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tXIqV-00040E-JP
 for xen-devel@lists.xenproject.org; Mon, 13 Jan 2025 11:43:03 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8b6cf6df-d1a3-11ef-a0e1-8be0dac302b0;
 Mon, 13 Jan 2025 12:43:02 +0100 (CET)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-aaf3c3c104fso733103466b.1
 for <xen-devel@lists.xenproject.org>; Mon, 13 Jan 2025 03:43:02 -0800 (PST)
Received: from [10.81.35.177] ([46.149.103.14])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d9903c3206sm5002490a12.46.2025.01.13.03.43.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 13 Jan 2025 03:43:01 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8b6cf6df-d1a3-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736768582; x=1737373382; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=2t/ADShDozWFcdoWpKy1RENT8VgLl7MfOxeVbSDz4uE=;
        b=FAkgC9MMBNAxuw2n6muw7fvghIARwjMZ/RoRuOH/GX/rWpeNURluiaLXWg4Q7FamsB
         g5ph0jLfAUKzO//2Xf/z3c1/MIv9qtpBTHK+7AA+oHrLyndB8OQKXRZMjFjL6G/k+uhj
         cH5zxIsdZ3ZmWjUCZOft0tZq7cLP5KCZidIAI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736768582; x=1737373382;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=2t/ADShDozWFcdoWpKy1RENT8VgLl7MfOxeVbSDz4uE=;
        b=b5PGiK+LQDv8yNHyG3YvMN0L5hkc15I73DTqbVWhIfcyyJQR4EbTggGocOfMwdZbU2
         XCP62UetbG92yoHUzzKDL3h/03uxvZlOScgW1q6RsuzkG0M6HId8efJ/GE4peHk+FKsi
         row8eWR/N/JlS7pqZIWI+MHwXotHjS6ih+5QgqEXFm8lrJ4Sykxj0oqFX/t8gAVvWOB1
         UPXa2xfJzEQco4EFe5aqpNQLTNvSU2tiJ5Xp6qNq0pQgbbqfIWnzyU+d88RJ+GvQksZn
         ICD5K4bEtjGKVG8WiyZcxFu5wKv74hoxhNwnumcoI43TJ/TwLjammBkFbwxdz6IH7MiP
         QPXQ==
X-Forwarded-Encrypted: i=1; AJvYcCUDMQhEQy2mwUCN2c+/nkyKydfEBoz8eHM/izf9Szgs+itS/0cBi3/MNIiIoNNlqv9odxDnT6coSDg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwGOLVfzWbDZm9b9jESgViiicBoxljsdppYk6Uk53ZLnntHBq4+
	5hszmnaX6hYO8rz6T40nPlsf9N0/VgbJWsdV8XdTiEtIEP7krxkTs59mYcT1usY=
X-Gm-Gg: ASbGnctPHE0DNFlfAfc+TaF6YjVnbcBZNm5YDeEj+wkPvCvbtetNAJyeFT6V6e7Wu7q
	CHe0675LAm82o9qcwLJ2zmoXax+veF85pzePL2KmMXcVrc7u4a5oVsnTFBDnguSUXj30/WXAFlk
	8NFAvZ/dagZ224FnBQbp3PNJzlPWFCA6YI9Uw7pnOvxGiC9wD0buM/aZFyOfTiCuGoCB1fQVh91
	THw1tfeYykm5pLc2l9BKtWKXM3/FZm8to4lnJKMyjYeAglfEt9/DtbQCmrxp8Exvdk=
X-Google-Smtp-Source: AGHT+IHTVieikwTqebzCBg4D7H7lOOad+0gFsSfTbe4g2KwvvsOyD/fKYatIv4XlOxZMDuucORGwpw==
X-Received: by 2002:a17:907:1b1c:b0:aab:d8de:217e with SMTP id a640c23a62f3a-ab2ab5f95d0mr1899711066b.26.1736768581629;
        Mon, 13 Jan 2025 03:43:01 -0800 (PST)
Message-ID: <9787ca01-eaf9-4538-9b5a-5d4d1d58f4fc@citrix.com>
Date: Mon, 13 Jan 2025 11:43:00 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 1/1] docs/Makefile: Add ppc and riscv to DOC_ARCHES
To: Maximilian Engelhardt <maxi@daemonizer.de>, xen-devel@lists.xenproject.org
Cc: Anthony PERARD <anthony.perard@vates.tech>
References: <cover.1736542505.git.maxi@daemonizer.de>
 <b1d5c6fca18b93e402d229d22763621719964ea7.1736542505.git.maxi@daemonizer.de>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <b1d5c6fca18b93e402d229d22763621719964ea7.1736542505.git.maxi@daemonizer.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10/01/2025 9:19 pm, Maximilian Engelhardt wrote:
> Not having ppc and riscv included in DOC_ARCHES causes "multiple
> definitions of ..." message on documentation build, similar to the
> example shown below:
>
> include/public/arch-ppc.h:91: multiple definitions of Typedef
> vcpu_guest_core_regs_t: include/public/arch-arm.h:300
> include/public/arch-ppc.h:91: multiple definitions of Typedef
> vcpu_guest_core_regs_t: include/public/arch-ppc.h:85
>
> It can also make the generated html documentation link to the header
> files of another architecture. This is additionally a problem as it can
> randomly make the documentation build non-reproducible.
>
> Signed-off-by: Maximilian Engelhardt <maxi@daemonizer.de>

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>


From xen-devel-bounces@lists.xenproject.org Mon Jan 13 13:46:53 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Jan 2025 13:46:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870577.1281737 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXKm0-0002FD-QM; Mon, 13 Jan 2025 13:46:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870577.1281737; Mon, 13 Jan 2025 13:46:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXKm0-0002F6-Nu; Mon, 13 Jan 2025 13:46:32 +0000
Received: by outflank-mailman (input) for mailman id 870577;
 Mon, 13 Jan 2025 13:46:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=+JSt=UF=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tXKlz-0002F0-7l
 for xen-devel@lists.xenproject.org; Mon, 13 Jan 2025 13:46:31 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ca5399b9-d1b4-11ef-99a4-01e77a169b0f;
 Mon, 13 Jan 2025 14:46:29 +0100 (CET)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-aaedd529ba1so616048066b.1
 for <xen-devel@lists.xenproject.org>; Mon, 13 Jan 2025 05:46:29 -0800 (PST)
Received: from [10.81.35.177] ([46.149.103.14])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c9060c00sm503595766b.41.2025.01.13.05.46.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 13 Jan 2025 05:46:28 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ca5399b9-d1b4-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736775988; x=1737380788; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=/y5rd0Puue2VupoayGh0HYUm9mRYlH6OktBkuFN9j2w=;
        b=iuU7p0AqnrzVIuMduUDUeSKkQVHLdxx49eissvvjMkqfbNdio/g1U7yJDq/yvr4AdP
         53CQ3+TMSLu4U0J+xdZXmVBs8R2o5Wmf4S/h1LzzX56xKSrAL4SLK7UHdzqx2sCnKc5l
         OaXnwFTXZi9L14hPag53TvNWjtpUi6bkHN6FI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736775988; x=1737380788;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=/y5rd0Puue2VupoayGh0HYUm9mRYlH6OktBkuFN9j2w=;
        b=oJUHON2wkY+5JhpyrKaBGOcUZg77lznjGnPcNmp8enbJB/jDG/QcLVvI/2U9otZatI
         jO+FmOwuSvW3medoESumecPD7s1AY3enBzGXfIW7SRk7I0QpQt+imfZGSVRPJ3/PZ17t
         NfU0agPgF1hU202UekJDLMVKp2TIhg/fNSAm+w6nHNUOYeo2gixQNSMcowMVLVJ+ngO3
         RXNvBtPPylQrx2YJV/k95CeVXftGXN35O1L9IReOlPDl6Y9EIPjz4Nf91X+O33ji3d7L
         hM8LmotauYkIR6P514KeppVHg4qZyRr0A5ynzdfvpiDO0++nOIeAI47dDo1qPo8IDbqU
         4gIg==
X-Forwarded-Encrypted: i=1; AJvYcCXFrwdndobLX5eVtPyhHu8UIjttc7g3dh9KUcfme0jh81WwgkvEMQZQiD4I3tuAqw3sP6TkXp/xN9k=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx/v4AvE2YK5o7lSgYQDPZi2MhhWpWawB2JN9QkUfuU2wMyvYce
	OYvVSpNlXBi7EG2VlG5ydmOLY6JZzOquoZiiKgC/e5IGF+jfs/CmT3ftORaQRVD00iJBZTxQkBr
	V
X-Gm-Gg: ASbGncvWVI0qIk0eA/iWMEOF9M9tzAY+knM7lX0wcSaY3Gnwc3njs2YhAHXncCSPXho
	3u+uy2ovp+8qUwijBAEnn0LE5DfFTs1rV5pfMmu2IZO/exPmorO7sycjL4gUI7bzRWCfpUcqwQ2
	oSyJ9aVgXNYdiwDl3MeKA2CYZTljzd3WAPR/p1+Kcrcza6Et/I40bMHgAVD8VaSsTGv7PCIuDX7
	D8B3vDkYLEPK5DmLeL9HDZ+7YfFzQMjv6OcjB0tSCP+/kx8SbfktzBTm/i5EbAaM5c=
X-Google-Smtp-Source: AGHT+IHcn/gZ+61WcMlBT8a9x8xBfwbaJBfza/5ugV/kSkENJRXIKSBEB6+vI++lx8hLWNsN6SC2pg==
X-Received: by 2002:a05:6402:354a:b0:5d2:7396:b0ed with SMTP id 4fb4d7f45d1cf-5d972e0e3abmr45025233a12.14.1736775988514;
        Mon, 13 Jan 2025 05:46:28 -0800 (PST)
Message-ID: <e7cea505-a54e-4094-8335-31b426c485e9@citrix.com>
Date: Mon, 13 Jan 2025 13:46:27 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 2/5] docs: set DATE to SOURCE_DATE_EPOCH if available
To: Maximilian Engelhardt <maxi@daemonizer.de>, xen-devel@lists.xenproject.org
Cc: Anthony PERARD <anthony.perard@vates.tech>
References: <cover.1735585600.git.maxi@daemonizer.de>
 <25f9fabf-1239-4465-92c9-484fc24fc4f7@citrix.com>
 <2637960.Lt9SDvczpP@localhost> <23136765.EfDdHjke4D@localhost>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <23136765.EfDdHjke4D@localhost>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 01/01/2025 7:03 pm, Maximilian Engelhardt wrote:
> On Montag, 30. Dezember 2024 23:28:42 CET Maximilian Engelhardt wrote:
>> On Montag, 30. Dezember 2024 22:38:24 CET Andrew Cooper wrote:
>>> On 30/12/2024 9:00 pm, Maximilian Engelhardt wrote:
>>>> Use the solution described in [1] to replace the call to the 'date'
>>>> command with a version that uses SOURCE_DATE_EPOCH if available. This
>>>> is needed for reproducible builds.
>>>>
>>>> The -d "@..." syntax was introduced in GNU date about 2005 (but only
>>>> added to the docuemntation in 2011), so I assume a version supporting
>>>> this syntax is available, if SOURCE_DATE_EPOCH is defined. If
>>>> SOURCE_DATE_EPOCH is not defined, nothing changes with respect to the
>>>> current behavior.
>>>>
>>>> [1] https://reproducible-builds.org/docs/source-date-epoch/
>>>>
>>>> Signed-off-by: Maximilian Engelhardt <maxi@daemonizer.de>
>>>> ---
>>>>
>>>>  docs/Makefile | 8 +++++++-
>>>>  1 file changed, 7 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/docs/Makefile b/docs/Makefile
>>>> index b30cc619f8..beba02a94f 100644
>>>> --- a/docs/Makefile
>>>> +++ b/docs/Makefile
>>>> @@ -3,7 +3,13 @@ include $(XEN_ROOT)/Config.mk
>>>>
>>>>  -include $(XEN_ROOT)/config/Docs.mk
>>>>  
>>>>  VERSION		:= $(shell $(MAKE) -C $(XEN_ROOT)/xen --no-print-
> directory
>>>>  xenversion)>
>>>>
>>>> -DATE		:= $(shell date +%Y-%m-%d)
>>>> +
>>>> +DATE_FMT	:= +%Y-%m-%d
>>>> +ifdef SOURCE_DATE_EPOCH
>>>> +DATE		:= $(shell date -u -d "@$(SOURCE_DATE_EPOCH)" "$(DATE_FMT)"
>>>> 2>/dev/null || date -u -r "$(SOURCE_DATE_EPOCH)" "$(DATE_FMT)"
>>>> 2>/dev/null || date -u "$(DATE_FMT)") +else
>>>> +DATE		:= $(shell date "$(DATE_FMT)")
>>>> +endif
>>>>
>>>>  DOC_ARCHES      := arm x86_32 x86_64
>>>>  MAN_SECTIONS    := 1 5 7 8
>>> While this looks fine for docs, there's another (identical) use of date
>>> in tools/firmware/hvmloader/Makefile, as well as some differing uses to
>>> construct XEN_BUILD_{DATE,TIME}.  INSTALL talks about VGABIOS_REL_DATE
>>> too.
>>>
>>> Does something like this work for you?  It seems to DTRT for SMBIOS.  It
>>> needs adapting a bit more for vgabios and Xen, but I think having one
>>> common $(date) is going to be better than ad-hoc ones over the tree.
>>>
>>> ~Andrew
>> Hi Andrew,
>>
>> Thanks for your quick reply. Your patch looks fine to me. You can add my
>> Tested-by.
>>
>> We currently use "export XEN_BUILD_{DATE,TIME}=...", "export
>> SMBIOS_REL_DATE=..." and "export VGABIOS_REL_DATE=..." for building xen in
>> Debian, so we did not run into reproducibility problems with these. But
>> having them combined to all use SOURCE_DATE_EPOCH if available sounds like
>> a good idea and would also benefit other downstream users.
>>
>> Maxi
> Hi Andrew,
>
> I extended your patch to also cover the other uses of date. Please check if 
> this look reasonable as I'm not an expert in makefiles. It seems to DTRT in 
> the cases I tested.
>
> What I changed compared to your patch:
>
> * Add LC_ALL=C to all date commands. This was also missing in my original 
> patch, but I think it's a good thing to do and XEN_BUILD_{DATE,TIME} already 
> do it.
>
> * Change the quoting to allow calling the date command without any additional 
> (formatting) arguments.
>
> * Add an include of Config.mk to tools/firmware/vgabios/Makefile and moved the 
> definition of XEN_BUILD_{DATE,TIME} further down in xen/Makefile to have the 
> newly defined date wrapper available.
>
> Does this look reasonable or are there parts that should be done differently?

That looks good to me.

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>


From xen-devel-bounces@lists.xenproject.org Mon Jan 13 14:48:37 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Jan 2025 14:48:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870598.1281760 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXLjm-0001j2-5m; Mon, 13 Jan 2025 14:48:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870598.1281760; Mon, 13 Jan 2025 14:48:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXLjm-0001iv-25; Mon, 13 Jan 2025 14:48:18 +0000
Received: by outflank-mailman (input) for mailman id 870598;
 Mon, 13 Jan 2025 14:48:17 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=uBYe=UF=gmail.com=w1benny@srs-se1.protection.inumbo.net>)
 id 1tXLjl-0001ip-2F
 for xen-devel@lists.xenproject.org; Mon, 13 Jan 2025 14:48:17 +0000
Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com
 [2607:f8b0:4864:20::334])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6a68e7a2-d1bd-11ef-a0e1-8be0dac302b0;
 Mon, 13 Jan 2025 15:48:14 +0100 (CET)
Received: by mail-ot1-x334.google.com with SMTP id
 46e09a7af769-71e15e75717so506405a34.1
 for <xen-devel@lists.xenproject.org>; Mon, 13 Jan 2025 06:48:14 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 6a68e7a2-d1bd-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736779693; x=1737384493; 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=5wed0ovCZrQjH1cGnaVHuR1PDs2srTZ0avB1/jNISbI=;
        b=Bg8YXie3QhqmttZ7yeL7oJf6RM8msSFCEJ2TaUXBnodsbRGJFaHfDkS24uabEDjE9u
         /HaDnqAqesRLuwh0DIeFVSGvwpAAP5QSRcGYQc0xQKiJfu4u7wRPtrUWO8JW+VtRZoPG
         iIYllGGz337VFnXinm80uuW0l+dFx8gziLdSGOfSO5pEHr450x/ih0CSI/1Z/GaSUGzE
         L0v7CiErw6FzSaevC8OgB7GzYasycNB2zCxHhoIVre9m4XDBlH5Ufzam8sEmwS90VGc9
         bVCCdQrFZqtBgR5rm88MJp3Af5pW+m6ZHfIDY2bix/6GtSYZwA7NFr1sSo3Xd77GlJ46
         eXjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736779693; x=1737384493;
        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=5wed0ovCZrQjH1cGnaVHuR1PDs2srTZ0avB1/jNISbI=;
        b=srZ4Zo681oc6pzf4LJlPnTJUuv0B0NkzRZWkXXteBnl4A6yBnqfrJJJPq4QsZgMo53
         lZnkKKkRE2JeT/wjPJaYfuUw0S1smeJ9OWA5y+3KVTZIXoedLSAkMBlwm7S8Lvkdw65a
         gKbX6NBS3hiNZxnHhVOvSfH8psXYYIbp7mfSiFaTQPVYGAbP3kLd6nm0usTXbt/UeAcq
         16DjxXr9EU6HRuxNMHj3o8Yguh/DpKT4xbCWcLERLkPMZb9N8bP/jvtHbNCz0IVIyhkF
         d/DrVDTCscZ8R1vXAak7QphTyp1dQHMNs6lEke8hKUjOxPJ0ZhSPZT80WgYyuMhnAN3B
         DhVA==
X-Forwarded-Encrypted: i=1; AJvYcCWjTa7izJJ2zITVTxaCeFGb3wAXpAcIRKtc73aTHLhyo7ts/Gk4Q0LePVX4Xe2m6AXovD1FUsDmLos=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxUpnBpWBdRre4laYtTTEXIz6JlUJXIhRx6Km673tyYBZHYJxxc
	WHkD3abKr/A7kpLyhY7mLPyJT7qf8TUvW3+mcmSRJ4QJKf1g7sjjprswuheueC55AsdNVmwCVBN
	xe8DWrltJ3iPDQPjk2NZ+KMexYEs=
X-Gm-Gg: ASbGnctxOy1/E6EiPYwgUpkn0Fq608YH/sD1/pu1UDqv32DiYO9VDa+ews4QFTFcPuY
	4w004wXKSMrPMaiz/vC/Ap31OzS95ZmCSGmS+
X-Google-Smtp-Source: AGHT+IHtKCiOI6oZH20Kohs0+BPkqMLSKn5pfXXA0DRTFLEeR3yi1hvkTvOlrdF42TkWAOrce/JGH2UtHewqynYFoQc=
X-Received: by 2002:a05:6870:ce8e:b0:29e:5f79:21b4 with SMTP id
 586e51a60fabf-2aa069c334cmr4221999fac.13.1736779693020; Mon, 13 Jan 2025
 06:48:13 -0800 (PST)
MIME-Version: 1.0
References: <cover.1735837806.git.w1benny@gmail.com> <31a1ff2d5d1e17bb73231e008f1e47c501bb3ce8.1735837806.git.w1benny@gmail.com>
 <d6eb70a7-5895-4471-95b3-609f133fa457@suse.com> <CAKBKdXjJm5194Wa=gy=DikiUEsevrB2Xn-idr+vgfgJMBrfZ-w@mail.gmail.com>
 <b182555c-555e-4efc-94a0-5f383f7d8689@suse.com> <00662cf8-7bff-4963-8b52-5df2e6a75132@citrix.com>
In-Reply-To: <00662cf8-7bff-4963-8b52-5df2e6a75132@citrix.com>
From: =?UTF-8?Q?Petr_Bene=C5=A1?= <w1benny@gmail.com>
Date: Mon, 13 Jan 2025 15:48:01 +0100
X-Gm-Features: AbW1kvbMJbuOi5oYsaMm0TdztLi7CgmFFlBZGuFEJt1A0gTCOpf2b3qvCGR49ak
Message-ID: <CAKBKdXjNRHtpLXFT6J9ZRggK94dKTXBeJAvbJEMG=uLO1-=Hbw@mail.gmail.com>
Subject: Re: [PATCH v3 2/2] x86: Add Support for Paging-Write Feature
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>, Tamas K Lengyel <tamas@tklengyel.com>, 
	Alexandru Isaila <aisaila@bitdefender.com>, Petre Pircalabu <ppircalabu@bitdefender.com>, 
	Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, 
	Bertrand Marquis <bertrand.marquis@arm.com>, Michal Orzel <michal.orzel@amd.com>, 
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>, Anthony PERARD <anthony.perard@vates.tech>, 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
	xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Jan 8, 2025 at 1:23=E2=80=AFPM Andrew Cooper <andrew.cooper3@citrix=
.com> wrote:
> Seeing as this is the only issue, I'm happy to fix on commit?

Fine by me!

P.


From xen-devel-bounces@lists.xenproject.org Mon Jan 13 15:11:32 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Jan 2025 15:11:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870626.1281770 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXM6A-0005im-TC; Mon, 13 Jan 2025 15:11:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870626.1281770; Mon, 13 Jan 2025 15:11:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXM6A-0005if-QC; Mon, 13 Jan 2025 15:11:26 +0000
Received: by outflank-mailman (input) for mailman id 870626;
 Mon, 13 Jan 2025 15:11:25 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=dy7G=UF=kernel.org=kbusch@srs-se1.protection.inumbo.net>)
 id 1tXM69-0005iO-K1
 for xen-devel@lists.xenproject.org; Mon, 13 Jan 2025 15:11:25 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a630cfa8-d1c0-11ef-99a4-01e77a169b0f;
 Mon, 13 Jan 2025 16:11:23 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id C4AC65C5582;
 Mon, 13 Jan 2025 15:10:40 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id C2B86C4CED6;
 Mon, 13 Jan 2025 15:11:20 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a630cfa8-d1c0-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1736781081;
	bh=N6GNEhMlM/EdKo1uVEpkZEePe/ExshF2obnY4wmPz1o=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=sHxgeKpcFZwVtcznd92IQZSVdXQ8zlto0BNw4l/sLVZQNSpZyn1E4TLHG3gGCgL1U
	 N1opb9t+mJLNiG/9W1MkQfowvgkHgxu1Ea+L3iYE68ftFXREMbR2YMwZMWzjMdssnU
	 OOOKGfxwi7RUrWUE4cmhMVOrAfUhJMYzxX7W3hieXoPbbPjlo9CgGAY2dsObjswOpo
	 K/dbm8rpwrflXZO/pDzc6/x5j75DHX2lodXrtLX2mVYxklDZWghYSrwwD8JRLAtLJ6
	 BXRJjgs9C99zzJ1HWogc0nw0scidOo+Jtk5yGxwJEfb29SIJyk5sGLkWtvnhaixEIq
	 OuXm8c2Zm7gAw==
Date: Mon, 13 Jan 2025 08:11:19 -0700
From: Keith Busch <kbusch@kernel.org>
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>, linux-kernel@vger.kernel.org,
	xen-devel@lists.xenproject.org, linux-pci@vger.kernel.org,
	Nirmal Patel <nirmal.patel@linux.intel.com>,
	Jonathan Derrick <jonathan.derrick@linux.dev>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Krzysztof =?iso-8859-1?Q?Wilczy=B4nski?= <kw@linux.com>,
	Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
	Rob Herring <robh@kernel.org>, Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [PATCH 2/3] vmd: disable MSI remapping bypass under Xen
Message-ID: <Z4UtF737b3QFGnY0@kbusch-mbp>
References: <20250110140152.27624-3-roger.pau@citrix.com>
 <20250110222525.GA318386@bhelgaas>
 <Z4TlDhBNn8TMipdB@macbook.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <Z4TlDhBNn8TMipdB@macbook.local>

On Mon, Jan 13, 2025 at 11:03:58AM +0100, Roger Pau Monn� wrote:
> 
> Hm, OK, but isn't the limit 80 columns according to the kernel coding
> style (Documentation/process/coding-style.rst)?

That's the coding style. The commit message style is described in a
different doc:

  https://docs.kernel.org/process/submitting-patches.html#the-canonical-patch-format


From xen-devel-bounces@lists.xenproject.org Mon Jan 13 16:08:31 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Jan 2025 16:08:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870669.1281779 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXMz2-0004PB-WF; Mon, 13 Jan 2025 16:08:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870669.1281779; Mon, 13 Jan 2025 16:08:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXMz2-0004P4-Tc; Mon, 13 Jan 2025 16:08:08 +0000
Received: by outflank-mailman (input) for mailman id 870669;
 Mon, 13 Jan 2025 16:08:07 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=vF2z=UF=invisiblethingslab.com=marmarek@srs-se1.protection.inumbo.net>)
 id 1tXMz1-0004Oy-Fm
 for xen-devel@lists.xenproject.org; Mon, 13 Jan 2025 16:08:07 +0000
Received: from fhigh-a4-smtp.messagingengine.com
 (fhigh-a4-smtp.messagingengine.com [103.168.172.155])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9094ce00-d1c8-11ef-99a4-01e77a169b0f;
 Mon, 13 Jan 2025 17:08:04 +0100 (CET)
Received: from phl-compute-05.internal (phl-compute-05.phl.internal
 [10.202.2.45])
 by mailfhigh.phl.internal (Postfix) with ESMTP id 8E84B11400CC;
 Mon, 13 Jan 2025 11:08:01 -0500 (EST)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-05.internal (MEProxy); Mon, 13 Jan 2025 11:08:01 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
 13 Jan 2025 11:07:58 -0500 (EST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9094ce00-d1c8-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm2; t=1736784481;
	 x=1736870881; bh=leGU5R4gV8gmHI/4wSgtW8YanKa0HgkMUjwwU+SST84=; b=
	Ko1VnU71vwgWHckvtVrYxwju3aqxzbiD2Y0u8GgJr3e+S/lDQhowPc+z58/RsCFG
	qkMbvrdleN0yRgZApy83ht44OzJhCKEBXy1ILwkme8AxATJHktMWPYV/leRpz0He
	hjh6anovPG6Oih5u2HlgTF4RVZGUjH2n64AfrZtZRpM24V2UZ/fnv7kI/GUfsSC+
	UVL9tKxqRa2EbV9arU30TITPXCqhFxK+JpiXYOfmgEiGhtjbP+HsWNqZoAFE1dD5
	2gjOJPOaSA9UI5c3+bKooREQaa/GmbUU4qOch/x3H3+jHcF9ImMWLfSdxtuByIuA
	coyt1e18aS66qGPbyNSRPA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:subject:subject:to
	:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=
	1736784481; x=1736870881; bh=leGU5R4gV8gmHI/4wSgtW8YanKa0HgkMUjw
	wU+SST84=; b=RxWF7v/+8vCvyzQ7MD6vk2Qid872NPOOoXa7cCYfYdgCooInJ4n
	HQNJpz4vijWGxG/BSWcXslvvfeeOeH+p1ak+BpM/HqKDK9AMFYnLsqWetUewc1wA
	+YG5C8nRN6yOxzkzWbgL6Ki4NGSueUBcHY1ik9dwyAzUjT5cB6m5tlJeEKd0juAQ
	FMqVvnMQZ6jFoGgxHwML8LkUzye63b8SvxBdaLJP90oJJZofgkNVz69D06tbCVGj
	6wwgj7CxdGE2oASzKmElfv6hYpzGMVvIo556pfKsI8hzO8du41AjzRH6lX46ETXP
	NG+3PZGMgt62fXDROuhAF2lzrw0DxDONolw==
X-ME-Sender: <xms:YTqFZ2tk9ZoR56qklvAJCXMkjIWr34sjXpxEf_s2fisdNRPJLKxfxQ>
    <xme:YTqFZ7f_TRez_u8rOigSHvK7waQj7Hz8QCKOg2LhN9Uj4toep3QcEDmgG0O3YkDJP
    meub3POdWsBKg>
X-ME-Received: <xmr:YTqFZxyjCGYpf8QBHLNvkkMLmpVety59dWxYZ0joIapqzKEk8pkaD6sfzGdqJnzJpjgBAc2aIxs-bP8poadpD-QQFQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrudehgedgkeegucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
    rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
    htshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtjeen
    ucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomh
    grrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggft
    rfgrthhtvghrnhepgfduleetfeevhfefheeiteeliefhjefhleduveetteekveettddvge
    euteefjedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhho
    mhepmhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnh
    gspghrtghpthhtohepjedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtoheprhhoghgv
    rhdrphgruhestghithhrihigrdgtohhmpdhrtghpthhtohepgigvnhdquggvvhgvlheslh
    hishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdhrtghpthhtohepughpshhmihhthhes
    rghpvghrthhushhsohhluhhtihhonhhsrdgtohhmpdhrtghpthhtoheprghnughrvgifrd
    gtohhophgvrhefsegtihhtrhhigidrtghomhdprhgtphhtthhopehjsggvuhhlihgthhes
    shhushgvrdgtohhmpdhrtghpthhtohepjhhulhhivghnseigvghnrdhorhhgpdhrtghpth
    htohepshhsthgrsggvlhhlihhniheskhgvrhhnvghlrdhorhhg
X-ME-Proxy: <xmx:YTqFZxMH7B5EKxHl4N67eC4iNx144oaScqxmTqnqfqqkzi6UIiu5ew>
    <xmx:YTqFZ2_ZoXTbdmHtGd1xDXjQQjn4ZsxW7DL_iUJirgzB0Dx7YP7IDQ>
    <xmx:YTqFZ5XqfUfT-VPTGgofVcPIDr_Qk0UwRB5GmbNJdUzdBAIrHC7WVQ>
    <xmx:YTqFZ_dQWHseByAKhsF4rDRJKRmGCxntpaHebdkLE1ogNPT3VDblyQ>
    <xmx:YTqFZ7PlIviiItkiXcByjhBOzmG1PFTmF9TO4-OxYPLPRsu4Esst1j1_>
Feedback-ID: i1568416f:Fastmail
Date: Mon, 13 Jan 2025 17:07:55 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: xen-devel@lists.xenproject.org,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v7 1/2] x86/time: introduce command line option to select
 wallclock
Message-ID: <Z4U6WxtmaqGkqOqe@mail-itl>
References: <20240913075907.34460-1-roger.pau@citrix.com>
 <20240913075907.34460-2-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="TrHspJ3XmM5BXBRb"
Content-Disposition: inline
In-Reply-To: <20240913075907.34460-2-roger.pau@citrix.com>


--TrHspJ3XmM5BXBRb
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Mon, 13 Jan 2025 17:07:55 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: xen-devel@lists.xenproject.org,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v7 1/2] x86/time: introduce command line option to select
 wallclock

On Fri, Sep 13, 2024 at 09:59:06AM +0200, Roger Pau Monne wrote:
> Allow setting the used wallclock from the command line.  When the option =
is set
> to a value different than `auto` the probing is bypassed and the selected
> implementation is used (as long as it's available).
>=20
> The `xen` and `efi` options require being booted as a Xen guest (with Xen=
 guest
> supported built-in) or from UEFI firmware respectively.
>=20
> Signed-off-by: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>

Reviewed-by: Marek Marczykowski-G=C3=B3recki <marmarek@invisiblethingslab.c=
om>

> ---
> Changes since v6:
>  - Clarify documentation regarding repeated using of the wallclock comman=
d line
>    option.
>=20
> Changes since v5:
>  - Do EFI run-time services checking after command line parsing.
>=20
> Changes since v3:
>  - Note xen option is only available if Xen guest support it built.
>  - Fix typo.
> ---
>  docs/misc/xen-command-line.pandoc | 21 ++++++++++++++++
>  xen/arch/x86/time.c               | 41 ++++++++++++++++++++++++++++++-
>  2 files changed, 61 insertions(+), 1 deletion(-)
>=20
> diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-li=
ne.pandoc
> index 959cf45b55d9..2a9b3b9b8975 100644
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -2816,6 +2816,27 @@ vwfi to `native` reduces irq latency significantly=
=2E It can also lead to
>  suboptimal scheduling decisions, but only when the system is
>  oversubscribed (i.e., in total there are more vCPUs than pCPUs).
> =20
> +### wallclock (x86)
> +> `=3D auto |=C2=A0xen | cmos | efi`
> +
> +> Default: `auto`
> +
> +Allow forcing the usage of a specific wallclock source.
> +
> + * `auto` let the hypervisor select the clocksource based on internal
> +   heuristics.
> +
> + * `xen` force usage of the Xen shared_info wallclock when booted as a X=
en
> +   guest.  This option is only available if the hypervisor was compiled =
with
> +   `CONFIG_XEN_GUEST` enabled.
> +
> + * `cmos` force usage of the CMOS RTC wallclock.
> +
> + * `efi` force usage of the EFI_GET_TIME run-time method when booted fro=
m EFI
> +   firmware.
> +
> +If the selected option is invalid or not available Xen will default to `=
auto`.
> +
>  ### watchdog (x86)
>  > `=3D force | <boolean>`
> =20
> diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
> index 29b026735e5d..e4751684951e 100644
> --- a/xen/arch/x86/time.c
> +++ b/xen/arch/x86/time.c
> @@ -1552,6 +1552,37 @@ static const char *__init wallclock_type_to_string=
(void)
>      return "";
>  }
> =20
> +static int __init cf_check parse_wallclock(const char *arg)
> +{
> +    wallclock_source =3D WALLCLOCK_UNSET;
> +
> +    if ( !arg )
> +        return -EINVAL;
> +
> +    if ( !strcmp("auto", arg) )
> +        ASSERT(wallclock_source =3D=3D WALLCLOCK_UNSET);
> +    else if ( !strcmp("xen", arg) )
> +    {
> +        if ( !xen_guest )
> +            return -EINVAL;
> +
> +        wallclock_source =3D WALLCLOCK_XEN;
> +    }
> +    else if ( !strcmp("cmos", arg) )
> +        wallclock_source =3D WALLCLOCK_CMOS;
> +    else if ( !strcmp("efi", arg) )
> +        /*
> +         * Checking if run-time services are available must be done after
> +         * command line parsing.
> +         */
> +        wallclock_source =3D WALLCLOCK_EFI;
> +    else
> +        return -EINVAL;
> +
> +    return 0;
> +}
> +custom_param("wallclock", parse_wallclock);
> +
>  static void __init probe_wallclock(void)
>  {
>      ASSERT(wallclock_source =3D=3D WALLCLOCK_UNSET);
> @@ -2527,7 +2558,15 @@ int __init init_xen_time(void)
> =20
>      open_softirq(TIME_CALIBRATE_SOFTIRQ, local_time_calibration);
> =20
> -    probe_wallclock();
> +    /*
> +     * EFI run time services can be disabled from the command line, henc=
e the
> +     * check for them cannot be done as part of the wallclock option par=
sing.
> +     */
> +    if ( wallclock_source =3D=3D WALLCLOCK_EFI && !efi_enabled(EFI_RS) )
> +        wallclock_source =3D WALLCLOCK_UNSET;
> +
> +    if ( wallclock_source =3D=3D WALLCLOCK_UNSET )
> +        probe_wallclock();
> =20
>      printk(XENLOG_INFO "Wallclock source: %s\n", wallclock_type_to_strin=
g());
> =20
> --=20
> 2.46.0
>=20

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

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

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmeFOlsACgkQ24/THMrX
1yy48Qf6AmkcKpsBDzt11yC7G41El4UIzy2LfyRIrowbj6052KMO6I/b8pZ8YWqO
xFBnofR/JxuBAWAZRSuww7QAdul7taKsofLPNWbEjg7rNeHss4i9Fs+J3Fc2tMy4
qob9ZRzMvOEkm35bo3fXu1EVcxbyfZZrJkn1ifXhnUBxntkbzEaBPs/LDURpyJxF
EdbKhSF/SJrmm1LsKhoIlExj/ejHYuUvHQf4uNQYnG1P6AvLEBORktV9fgo4Jlen
bF9VzOvsJXwHqaW+fVCwFyJTJ+2pSqGcnvEuF1mue71AksMlnSPFngu3D+72jZPO
tw/gTe4mUDCoTmGASkac9NZlFFzpSQ==
=+vNt
-----END PGP SIGNATURE-----

--TrHspJ3XmM5BXBRb--


From xen-devel-bounces@lists.xenproject.org Mon Jan 13 16:45:32 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Jan 2025 16:45:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870687.1281789 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXNZ8-00019q-OI; Mon, 13 Jan 2025 16:45:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870687.1281789; Mon, 13 Jan 2025 16:45:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXNZ8-00019j-Ls; Mon, 13 Jan 2025 16:45:26 +0000
Received: by outflank-mailman (input) for mailman id 870687;
 Mon, 13 Jan 2025 16:45:25 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=3HK6=UF=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tXNZ7-00019d-A1
 for xen-devel@lists.xenproject.org; Mon, 13 Jan 2025 16:45:25 +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 c85181cb-d1cd-11ef-99a4-01e77a169b0f;
 Mon, 13 Jan 2025 17:45:23 +0100 (CET)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-aaecf50578eso883921366b.2
 for <xen-devel@lists.xenproject.org>; Mon, 13 Jan 2025 08:45:23 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c95624c1sm524597166b.131.2025.01.13.08.45.21
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 13 Jan 2025 08:45:21 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c85181cb-d1cd-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736786723; x=1737391523; 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=cQhL2mF6OQLPil4TM0uc1EA1az0dYWSLTPiDCCkoP+M=;
        b=bPxQMPXol589v/t8bSkRGh5rzUnnZDeA+bKZVMiWmBb2gi1+OgRrDAU/ubqe+MEQGU
         eMIp16ne2DAiPOXiYrcPrfENJtcc5rOkDSyp6zdIuPfkpgIglSDcUd57ZKaAdqhQQI20
         hdGciFZWoBIH8CJI+pYx6/MkXDKk90/ckP0KQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736786723; x=1737391523;
        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=cQhL2mF6OQLPil4TM0uc1EA1az0dYWSLTPiDCCkoP+M=;
        b=lgiW0ZVnS86rYZ1ubV2/jUY7Ucq2nBeYf+gnzyUNfCJKFascyI8u2V8u1q9PX0k9NR
         8DJkyjk+kRVx+YTGmGFOnWBiyA+3jvat4QSX3kKbbBB1kaaJLiv7szv/wyyIzTUyNpy1
         nDKTGL944+YW0Ajk2KW+OZD/LAEoq42B1vdrDmQVakOKC/dwhAhNdVUxriXDjiQ8OsKy
         UTyImPxOxgWe6GuC7Noy93uu959j1mstjF9rdG0CfGsn+MCOx7q615EI3/BK5OK39sTG
         Dp/5LNP7GshYSW1MWuPmoGFjehg28/u1ir0lrPlSZu1g5GWVKzNlcnIM7Ued7dpApz+s
         5uBA==
X-Forwarded-Encrypted: i=1; AJvYcCVGs8Y/WiIdUovpRgHqJltBhgB6YsY/LvrS+xWEY0wYvWIykxmGTJXROQrQMZmVI2VOSvuJYMKUVXA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyGO8xuriTPA2Ani+eEV2ncJS1m6Zs7/GXfw2GlxImLon0OlcdD
	V9yas4TPsRkeOSeioKjqY/bF4WblZC1uMionKtATezCbnfpmvpVC62YyD8oIL00yYvGCG/3Q5qj
	R
X-Gm-Gg: ASbGnctAub1xF2sbzb1rKyuCG0GPMlAaHSt+vjBv1c0NjPqGAv9/EOf2V6cUobakQa7
	LPX2BdnvLHRdDtQH9i1zdCd7MTM7+NxEvjs5jGVyh5pcrQEDtNKr/1rceePOwCjYT76l4j+Ss3j
	/14fPXv7rigr935TtoPNilH/JXGlE1QYVYdy2+TbhyfaqQMzRmBofnXo1KA2Z1chP5e+It0HmNu
	NgffLwAg+YRH5TDHperGw82naZjryw53Dxi0ImUiSPXCfPQn4Ggwset6neVXTXATnU=
X-Google-Smtp-Source: AGHT+IHboldTatC3Kvev2XggrqHCZW62HtgtMcXWz1/Gh1eCBct54o6sVYa7J7MMTTePNV00zm0xNQ==
X-Received: by 2002:a17:906:6a26:b0:aaf:73e4:e872 with SMTP id a640c23a62f3a-ab2ab16a9bbmr1562074266b.3.1736786722622;
        Mon, 13 Jan 2025 08:45:22 -0800 (PST)
Date: Mon, 13 Jan 2025 17:45:20 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Keith Busch <kbusch@kernel.org>
Cc: Bjorn Helgaas <helgaas@kernel.org>, linux-kernel@vger.kernel.org,
	xen-devel@lists.xenproject.org, linux-pci@vger.kernel.org,
	Nirmal Patel <nirmal.patel@linux.intel.com>,
	Jonathan Derrick <jonathan.derrick@linux.dev>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Krzysztof =?utf-8?Q?Wilczy=C2=B4nski?= <kw@linux.com>,
	Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
	Rob Herring <robh@kernel.org>, Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [PATCH 2/3] vmd: disable MSI remapping bypass under Xen
Message-ID: <Z4VDIPorOWD-FY-9@macbook.local>
References: <20250110140152.27624-3-roger.pau@citrix.com>
 <20250110222525.GA318386@bhelgaas>
 <Z4TlDhBNn8TMipdB@macbook.local>
 <Z4UtF737b3QFGnY0@kbusch-mbp>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <Z4UtF737b3QFGnY0@kbusch-mbp>

On Mon, Jan 13, 2025 at 08:11:19AM -0700, Keith Busch wrote:
> On Mon, Jan 13, 2025 at 11:03:58AM +0100, Roger Pau Monné wrote:
> > 
> > Hm, OK, but isn't the limit 80 columns according to the kernel coding
> > style (Documentation/process/coding-style.rst)?
> 
> That's the coding style. The commit message style is described in a
> different doc:
> 
>   https://docs.kernel.org/process/submitting-patches.html#the-canonical-patch-format

It's quite confusing to have different line length for code vs commit
messages, but my fault for not reading those. Will adjust to 75
columns them.

Regards, Roger.


From xen-devel-bounces@lists.xenproject.org Mon Jan 13 16:53:33 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Jan 2025 16:53:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870696.1281800 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXNgu-0002pR-HS; Mon, 13 Jan 2025 16:53:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870696.1281800; Mon, 13 Jan 2025 16:53:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXNgu-0002pK-EV; Mon, 13 Jan 2025 16:53:28 +0000
Received: by outflank-mailman (input) for mailman id 870696;
 Mon, 13 Jan 2025 16:53:27 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=dy7G=UF=kernel.org=kbusch@srs-se1.protection.inumbo.net>)
 id 1tXNgt-0002oS-An
 for xen-devel@lists.xenproject.org; Mon, 13 Jan 2025 16:53:27 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e796bb56-d1ce-11ef-a0e1-8be0dac302b0;
 Mon, 13 Jan 2025 17:53:26 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 899D05C5455;
 Mon, 13 Jan 2025 16:52:43 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 79E09C4CED6;
 Mon, 13 Jan 2025 16:53:23 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e796bb56-d1ce-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1736787204;
	bh=kkEPT9SH6eZSxMTtRu61LCsuirVhaWyNAb0QZt2aTH8=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=ixZImuDhU4eqfLD1GOd+Zjv7VLJ7M/YVfr7gwJJHegOQeLRM933U4Vosc3YGea+4A
	 45gdLXXOqX5j1GsOYkQ3LdmYnLHuN6iuaUmB4QlFen3TbmizNgV2FdDbaKaHPxe6sd
	 NDcUsXQcn2G5RGFCC3sljs2Cj2js4Lh9o46OwU7uBkvmdR4TN6SzYp0WGhzuQF1P+8
	 A+Us5l3aw/CRsM5IOedIcUFk1AGYlx0ttQcuw8OPyVDlteDSP7X5DdpfqjsxUdiE5o
	 30+X5COU7WXCuaQKr8MgLEDIMIj6Zht56ZubuKHq/Agkb9dtaPNsx3ggXwHWXiichS
	 X/6HWeXngkBZQ==
Date: Mon, 13 Jan 2025 09:53:21 -0700
From: Keith Busch <kbusch@kernel.org>
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>, linux-kernel@vger.kernel.org,
	xen-devel@lists.xenproject.org, linux-pci@vger.kernel.org,
	Nirmal Patel <nirmal.patel@linux.intel.com>,
	Jonathan Derrick <jonathan.derrick@linux.dev>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Krzysztof =?iso-8859-1?Q?Wilczy=B4nski?= <kw@linux.com>,
	Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
	Rob Herring <robh@kernel.org>, Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [PATCH 2/3] vmd: disable MSI remapping bypass under Xen
Message-ID: <Z4VFAZnQ_09cdexm@kbusch-mbp>
References: <20250110140152.27624-3-roger.pau@citrix.com>
 <20250110222525.GA318386@bhelgaas>
 <Z4TlDhBNn8TMipdB@macbook.local>
 <Z4UtF737b3QFGnY0@kbusch-mbp>
 <Z4VDIPorOWD-FY-9@macbook.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <Z4VDIPorOWD-FY-9@macbook.local>

On Mon, Jan 13, 2025 at 05:45:20PM +0100, Roger Pau Monn� wrote:
> On Mon, Jan 13, 2025 at 08:11:19AM -0700, Keith Busch wrote:
> > On Mon, Jan 13, 2025 at 11:03:58AM +0100, Roger Pau Monn� wrote:
> > > 
> > > Hm, OK, but isn't the limit 80 columns according to the kernel coding
> > > style (Documentation/process/coding-style.rst)?
> > 
> > That's the coding style. The commit message style is described in a
> > different doc:
> > 
> >   https://docs.kernel.org/process/submitting-patches.html#the-canonical-patch-format
> 
> It's quite confusing to have different line length for code vs commit
> messages, but my fault for not reading those. Will adjust to 75
> columns them.

The output of 'git log' prepends spaces to the subject and body of the
listed commits. The lower limit for commit messages vs. code makes the
change log look readable in an 80-char terminal.


From xen-devel-bounces@lists.xenproject.org Mon Jan 13 17:12:13 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Jan 2025 17:12:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870772.1281853 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXNyu-00087c-Oo; Mon, 13 Jan 2025 17:12:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870772.1281853; Mon, 13 Jan 2025 17:12:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXNyu-00087V-ME; Mon, 13 Jan 2025 17:12:04 +0000
Received: by outflank-mailman (input) for mailman id 870772;
 Mon, 13 Jan 2025 17:12:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Q7wO=UF=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tXNyt-00086e-R5
 for xen-devel@lists.xenproject.org; Mon, 13 Jan 2025 17:12:04 +0000
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com
 [2a00:1450:4864:20::12f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 810e9e0d-d1d1-11ef-99a4-01e77a169b0f;
 Mon, 13 Jan 2025 18:12:01 +0100 (CET)
Received: by mail-lf1-x12f.google.com with SMTP id
 2adb3069b0e04-54024ecc33dso4745852e87.0
 for <xen-devel@lists.xenproject.org>; Mon, 13 Jan 2025 09:12:01 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5428be53f8bsm1427982e87.89.2025.01.13.09.11.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 13 Jan 2025 09:11:59 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 810e9e0d-d1d1-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736788321; x=1737393121; darn=lists.xenproject.org;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=qOdwM1gjfO/zMPp4QUgzspx2N1qa3y4IrMx8dc6Xikg=;
        b=DQD+NFONEEVmmE82G7ooHKpXSVM0zD7FZafA4BU+DxSYRfiQ5Ek07wMKLutRtVo152
         G0VBH5eDUyJVTF5Ak4JX9xF6UA3LhScmRTGx8fWuF91+iHcLOT39Hw7bKpSmFJjzxhjK
         0aKOwZrcwHGHNHrQRBsaUqZkK3SmtvL2LkCdVwWIBfn5Wr27WeQi6VhuKENCu8Sto/0k
         oZtP5x2YZmaqda+x2lFQcro7jxMIkPmAnjKc5Xrb3NJl4sdmO+TK5PBZxQd8F7pdD9VG
         OdYFEzuSiRdb6gM5+m85+Nmh5sNcK2r9o8OsegVvlvBKERThq2VBorKAbgNL8BAYNOnE
         6Qlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736788321; x=1737393121;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=qOdwM1gjfO/zMPp4QUgzspx2N1qa3y4IrMx8dc6Xikg=;
        b=gbDueT1lQW3bSrb2N2NF77Lfs/xEA/SY/6VYtOdT0Ledbq/pqfU6xOmP7LFUNdHzIO
         OtjlN/pLz/nWNEDvq+Ph8xyDaL8t7JABmEQhZCg3I4Ls+Bt0dYstorVRtnuX9SvVvVZK
         COBObWGwDT/1HnaonH766SGciLg/2Gk4umdCeK+zQlTZ/rcebOC1J7NCNSeO8ddUIeCn
         UgavrgEO+VD5chxG1AGSOL4JrnDs4WAhG6D9t8sdaBnltOK2kNBmOczMgeCs8TWimHYY
         AfSf8LvbtNXIbcgakcUjMijaCOdv/MHv1rlM/aSKX58g+1bknx1A4PHXAk+kMMC/Gs7q
         CZ8w==
X-Forwarded-Encrypted: i=1; AJvYcCUOe5MQKRlWmRAP3SuZW0VvWiUN8LhDM9gtYrqIPBmUXKRWz4d7jXj+h5yCeFaOFA7OOCgJcyrDBWA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyFA5WTwbHzG8FvS0OoeA00L4K06LqouEb6RWa+QVfXcyTVzVIN
	M9ci54edEReAPpUQo93sw+mkDtXeIhwFcKio/ULeZqp1vrlfu2VQ
X-Gm-Gg: ASbGnctpbOogNz6pqjweBoUIQcOEkDHjNng3ishRKixaiNwNA36Sk1YMZZHFwRA9HJL
	W0coIpbG3Aqo9qdiSlIwxPah/3WV56oIz7jtnHA1LZgCVCQHtY8n/KC9sfEcc8aC4dUljUqREMA
	8J4aAufLmtFQA4JdbKRHjJ1rYA5GppO3K6Ah6CpYSH01oSsimQymookp/a04GwkJEZbZvqSqJyB
	MgdCXtMupRcdHrboJYwo4K7NGxGYRdkKce2ZbHLKJHdmxSkjzNTsiv9ZuLvdOQPZHcVXQ==
X-Google-Smtp-Source: AGHT+IHxd0J0j0CYWOeavgrbHmlF5leMUUdc8mUen+NRZopUladGnluD5zUPBkqJw7EKMk1J2B49tw==
X-Received: by 2002:a05:6512:2394:b0:53e:3a22:7a2e with SMTP id 2adb3069b0e04-542845d1265mr7714220e87.47.1736788320052;
        Mon, 13 Jan 2025 09:12:00 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------M8hA5d9ESfqddvD8G6y0PyIq"
Message-ID: <255b0079-4516-404c-81c1-a49e6f7bf5b4@gmail.com>
Date: Mon, 13 Jan 2025 18:11:58 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for 4.21 v1 1/1] xen/riscv: identify specific ISA
 supported by cpu
To: Jan Beulich <jbeulich@suse.com>
Cc: Alistair Francis <alistair.francis@wdc.com>,
 Bob Eshleman <bobbyeshleman@gmail.com>, Connor Davis
 <connojdavis@gmail.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1734957957.git.oleksii.kurochko@gmail.com>
 <ee14c485c6c6402a2d1706278b21bf3fcf821af9.1734957957.git.oleksii.kurochko@gmail.com>
 <bc636259-5586-428c-8a57-f97ba16a14b8@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <bc636259-5586-428c-8a57-f97ba16a14b8@suse.com>

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

On 1/8/25 4:21 PM, Jan Beulich wrote:

> On 23.12.2024 13:55, Oleksii Kurochko wrote:
>> --- /dev/null
>> +++ b/xen/arch/riscv/cpufeature.c
>> @@ -0,0 +1,466 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +/*
>> + * Taken for Linux kernel v6.12-rc3 and modified by
>> + * Oleksii Kurochko<oleksii.kurochko@gmail.com>:
>> + *
>> + * - Drop unconditional setting of {RISCV_ISA_EXT_ZICSR,
>> + *   RISCV_ISA_EXT_ZIFENCEI, RISCV_ISA_EXT_ZICNTR, RISCV_ISA_EXT_ZIHPM} as they
>> + *   are now part of the riscv,isa string.
>> + * - Remove saving of the ISA for each CPU, only the common available ISA is
>> + *   saved.
>> + * - Remove ACPI-related code as ACPI is not supported by Xen.
>> + * - Drop handling of elf_hwcap, since Xen does not provide hwcap to
>> + *   userspace.
>> + * - Replace of_cpu_device_node_get() API, which is not available in Xen,
>> + *   with a combination of dt_for_each_child_node(), dt_device_type_is_equal(),
>> + *   and dt_get_cpuid_from_node() to retrieve cpuid and riscv,isa in
>> + *   riscv_fill_hwcap_from_isa_string().
>> + * - Rename arguments of __RISCV_ISA_EXT_DATA() from _name to ext_name, and
>> + *   _id to ext_id for clarity.
>> + * - Replace instances of __RISCV_ISA_EXT_DATA with RISCV_ISA_EXT_DATA.
>> + * - Replace instances of __riscv_isa_extension_available with
>> + *   riscv_isa_extension_available for consistency.
>> + * - Redefine RISCV_ISA_EXT_DATA() to work only with ext_name and ext_id,
>> + *   as other fields are not used in Xen currently.
>> + * - Add check of first 4 letters of riscv,isa string to
>> + *   riscv_isa_parse_string() as Xen doesn't do this check before so it is
>> + *   necessary to check correctness of riscv,isa string. ( it should start with
>> + *   rv{32,64} with taking into account upper and lower case of "rv").
>> + * - Drop an argument of riscv_fill_hwcap() and riscv_fill_hwcap_from_isa_string()
>> + *   as it isn't used, at the moment.
>> + * - s/pr_info/printk.
>> + * - Apply Xen coding style.
> Having this in the patch description is sufficient imo.
>
>> + * Copyright (C) 2015 ARM Ltd.
>> + * Copyright (C) 2017 SiFive
>> + * Copyright (C) 2024 Vates
>> + */
>> +
>> +#include <xen/acpi.h>
> Didn't you say you dropped the ACPI pieces?

Yes, they are dropped but my intention was to add "panic("%s should be updated correspondingly to support ACPI\n", __func__)"
for the places where ACPI changes should be done in case of ACPI support will be added. And these places are detected by
checking acpi_disabled variable which is in <xen/acpi.h>.

>
>> +#include <xen/bitmap.h>
>> +#include <xen/ctype.h>
>> +#include <xen/device_tree.h>
>> +#include <xen/errno.h>
>> +#include <xen/init.h>
>> +#include <xen/lib.h>
>> +#include <xen/sections.h>
>> +
>> +#include <asm/cpufeature.h>
>> +
>> +struct riscv_isa_ext_data {
>> +    const unsigned int id;
>> +    const char *name;
>> +};
> This is odd - why would the id be const, but not the name? Thus you
> require all instances of the struct to have an initializer. The more
> conventional approach is to apply the const on the instances of the
> structure (e.g. as you already have it for riscv_isa_ext[]).

Agree, not too much sense to have const id, but not the name. Then it should be also "const char * const name".

Lets follow conventional approach and declare riscv_isa_ext_data structure as:
   struct riscv_isa_ext_data {
       unsigned int id;
       const char *name;
   };
name member of riscv_isa_ext_data structure still should be "const char *" to avoid compilation error:
   discarding of `const' qualifier from pointer target type.

An option could be to have a case in macros RISCV_ISA_EXT_DATA():
   #define RISCV_ISA_EXT_DATA(ext_name, ext_id)    \
   {                                               \
       .id = ext_id,                               \
       .name = (char *)#ext_name,                  \
   }
But IMO it is better just to declare riscv_isa_ext_data as suggested above.

>> +static int __init dt_get_cpuid_from_node(const struct dt_device_node *cpu)
>> +{
>> +    const __be32 *prop;
>> +    unsigned int reg_len;
>> +
>> +    if ( dt_n_size_cells(cpu) != 0 )
>> +        printk("cpu node `%s`: #size-cells %d\n",
>> +               dt_node_full_name(cpu), dt_n_size_cells(cpu));
>> +
>> +    prop = dt_get_property(cpu, "reg", &reg_len);
>> +    if ( !prop )
>> +    {
>> +        printk("cpu node `%s`: has no reg property\n", dt_node_full_name(cpu));
>> +        return -EINVAL;
>> +    }
>> +
>> +    if ( reg_len < dt_cells_to_size(dt_n_addr_cells(cpu)) )
>> +    {
>> +        printk("cpu node `%s`: reg property too short\n",
>> +               dt_node_full_name(cpu));
>> +        return -EINVAL;
>> +    }
>> +
>> +    return dt_read_paddr(prop, dt_n_addr_cells(cpu));
>> +}
>> +
>> +/*
>> + * The canonical order of ISA extension names in the ISA string is defined in
>> + * chapter 27 of the unprivileged specification.
>> + *
>> + * Ordinarily, for in-kernel data structures, this order is unimportant but
>> + * isa_ext_arr defines the order of the ISA string in /proc/cpuinfo.
> Inapplicable Linux detail? (If you want to keep it, you'll want to add
> "Linux'es" and avoid mentioning something that looks like a variable
> but then doesn't exist anywhere.)

Agree, no need for this Linux detail, it is not really useful in our case. I will drop it.

>> +    RISCV_ISA_EXT_DATA(i, RISCV_ISA_EXT_i),
>> +    RISCV_ISA_EXT_DATA(m, RISCV_ISA_EXT_m),
>> +    RISCV_ISA_EXT_DATA(a, RISCV_ISA_EXT_a),
>> +    RISCV_ISA_EXT_DATA(f, RISCV_ISA_EXT_f),
>> +    RISCV_ISA_EXT_DATA(d, RISCV_ISA_EXT_d),
>> +    RISCV_ISA_EXT_DATA(q, RISCV_ISA_EXT_q),
>> +    RISCV_ISA_EXT_DATA(h, RISCV_ISA_EXT_h),
>> +    RISCV_ISA_EXT_DATA(zicntr, RISCV_ISA_EXT_ZICNTR),
>> +    RISCV_ISA_EXT_DATA(zicsr, RISCV_ISA_EXT_ZICSR),
>> +    RISCV_ISA_EXT_DATA(zifencei, RISCV_ISA_EXT_ZIFENCEI),
>> +    RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE),
>> +    RISCV_ISA_EXT_DATA(zihpm, RISCV_ISA_EXT_ZIHPM),
>> +    RISCV_ISA_EXT_DATA(zbb, RISCV_ISA_EXT_ZBB),
> Isn't it kind of implied that with the presence of Zbb, B should also be
> present?

My interpretation of the RISC-V Bitmanip Extension spec is that the 'B' extension is essentially a collection of
the Zba, Zbb, Zbs, and other extensions, but it isn't an extension by itself.
The following is mentioned in the spec:
   The bit-manipulation (bitmanip) extension collection is comprised of several component extensions to the base
   RISC-V architecture that are intended to provide some combination of code size reduction, performance
   improvement, and energy reduction. While the instructions are intended to have general use, some instructions
   are more useful in some domains than others. Hence, several smaller bitmanip extensions are provided, rather
   than one large extension. Each of these smaller extensions is grouped by common function and use case, and
   each of which has its own Zb*-extension name.

>> +    RISCV_ISA_EXT_DATA(smaia, RISCV_ISA_EXT_SMAIA),
>> +    RISCV_ISA_EXT_DATA(ssaia, RISCV_ISA_EXT_SSAIA),
>> +};
> Wouldn't the Z and S prefixes better be recorded in upper case here?

I decided that it is always mentioned in lower case in the spec, but it is wrong and Z and S are
used in upper case (https://github.com/riscv/riscv-isa-manual/blob/main/src/naming.adoc#subset-naming-convention ),
and also there is another one reason mentioned in an answer to another your question below. ( it was marked as [1] )

>> +    RISCV_ISA_EXT_DATA(zbb, RISCV_ISA_EXT_ZBB),
>> +    RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE),
>> +};
>> +
>> +static const size_t riscv_isa_ext_count = ARRAY_SIZE(riscv_isa_ext);
> Is this variable really useful to have?

Not really. ( at least, at the moment ) It could be dropped.

>> +    {
>> +        const struct riscv_isa_ext_data *ext = &riscv_isa_ext[i];
>> +
>> +        if ( (name_end - name == strlen(ext->name)) &&
>> +             !strncasecmp(name, ext->name, name_end - name) )
> Does this really need to be a case-insensitive comparison?

[1]:
Considering that we are discussing to use Z and S in upper case then we need to use strncasecmp()
because `name` comes from riscv, isa property of device tree and it means that letters in
the riscv,isa string must be all lowercase (https://elixir.bootlin.com/linux/v6.12.6/source/Documentation/devicetree/bindings/riscv/extensions.yaml#L34 )
so we have to avoid comparison of extension names which could start in upper case with the same extension name which starts
from lower case:
While the isa <https://elixir.bootlin.com/linux/v6.12.6/B/ident/isa> 
strings in ISA specification are case insensitive, letters in the 
riscv,isa string must be all lowercase. And so to avoid comparison of a 
name from riscv_isa_ext[] which could be theoretically starts from upper 
case we have to use strncasecmp() to transform everything to lower case 
before comparison. And it seems it is better to be on a safe side for 
the cases when some accidentally will use upper case or in 
riscv_isa_ext[] or in riscv,isa property of device-tree.

>> +            break;
>> +        }
>> +    }
>> +}
>> +
>> +static int __init riscv_isa_parse_string(const char *isa, unsigned long *out_bitmap)
>> +{
>> +    if ( isa[0] != 'r' && isa[0] != 'R' )
>> +        return -EINVAL;
>> +
>> +    if ( isa[1] != 'v' && isa[1] != 'V' )
>> +        return -EINVAL;
>> +
>> +    if ( isa[2] != '3' && isa[3] != '2' &&
>> +         isa[2] != '6' && isa[3] != '4' )
>> +        return -EINVAL;
> Any reason to accept the (respectively, depending on configuration) wrong
> bitness? Or to accept e.g. RV34?

Good question. I think there is no any reason to accept the wrong bitness and
it is a bug. I'll re-write the last if-condition.

>
>> +    isa += 4;
>> +
>> +    while ( *isa )
>> +    {
>> +        const char *ext = isa++;
>> +        const char *ext_end = isa;
>> +        bool ext_err = false;
>> +
>> +        switch ( *ext )
>> +        {
>> +        case 'x':
>> +        case 'X':
>> +            if ( acpi_disabled )
>> +                printk_once("Vendor extensions are ignored in riscv,isa."
>> +                            "Use riscv,isa-extensions instead\n");
> How's this connected to ACPI? The more that you said there's nothing
> ACPI-ish left.

The same as above just left that for the case if one day someone will add ACPI support.
( but, at the moment, we could drop it or I will update the comment when I wrote about
dropping of ACPI-connected things to something like: "ACPI is almost fully drop and leave
only places where a code should be updated to have ACPI support".

>> +            /*
>> +             * Workaround for invalid single-letter 's' & 'u' (QEMU).
>> +             * No need to set the bit in riscv_isa as 's' & 'u' are
>> +             * not valid ISA extensions. It works unless the first
>> +             * multi-letter extension in the ISA string begins with
>> +             * "Su" and is not prefixed with an underscore.
>> +             */
>> +            if ( ext[-1] != '_' && ext[1] == 'u' )
>> +            {
>> +                ++isa;
>> +                ext_err = true;
>> +                break;
>> +            }
> I'm afraid I don't understand this; the comment raises more questions
> than it answers.

Some details could be found here about these QEMU workaround from LK view:
https://lore.kernel.org/linux-riscv/ae93358e-e117-b43d-faad-772c529f846c@irq.a4lg.com/#t

This leads to the following fix in QEMU:
https://patchwork.kernel.org/project/qemu-devel/patch/dee09d708405075420b29115c1e9e87910b8da55.1648270894.git.research_trasio@irq.a4lg.com/#24792587

Considering QEMU's patch, these workaround isn't needed anymore since QEMU 7.1 ( it has been released30 Aug 2022 ) probably we could update the
QEMU version on our CI and just drop these changes.
Or, at least, update the comment with the links mentioned above and add a message that these changes are needed only for QEMU < 7.1.
Am I right that we don't have something like GCC_VERSION in Xen but for QEMU?

>> +        if ( !dt_device_type_is_equal(cpu, "cpu") )
>> +            continue;
>> +
>> +        cpuid = dt_get_cpuid_from_node(cpu);
>> +        if ( cpuid < 0 )
>> +            continue;
>> +
>> +        if ( cpuid >= NR_CPUS )
>> +        {
>> +            printk_once("%s: dts has more cpu than NR_CPUs\n", __func__);
>> +            continue;
>> +        }
>> +
>> +        if ( dt_property_read_string(cpu, "riscv,isa-extensions", &isa) )
>> +        {
>> +            printk("Unable to find \"riscv,isa-extensions\" devicetree entry "
>> +                   "for cpu%d\n", cpuid);
>> +            continue;
>> +        }
>> +        else
>> +            printk("riscv,isa-extensions isnt supported\n");
> IOW no matter what, a message will be logged. Odd.

I think it should be panic but I confused it with printk...

>
> Also: Preferably no "else" after an if() ending in "continue".

If I understand you correctly, we really can drop here "else" and just
panic("riscv,isa-extensions isnt supported\n"), and it would be enough.

>> +        DECLARE_BITMAP(this_isa, RISCV_ISA_EXT_MAX);
>> +
>> +        if ( !dt_device_type_is_equal(cpu, "cpu") )
>> +            continue;
>> +
>> +        cpuid = dt_get_cpuid_from_node(cpu);
>> +        if ( cpuid < 0 )
>> +            continue;
>> +
>> +        if ( cpuid >= NR_CPUS )
>> +        {
>> +            printk_once("%s: dts has more cpu than NR_CPUs\n", __func__);
> What's "dts"? Did the 's' mean to be in "cpus" instead? Also NR_CPUS
> to avoid confusion.

DTS here means Device Tree Source. It would be more clear to write in the following way:
"CPU id is higher then maximum number of CPUs in Xen."
But I am not sure that his check is correct as it is not clearly defined that CPU ids are
from the range from 0 to NR_CPUS. The following is mentioned in the spec:
   Hart IDs might not necessarily be numbered contiguously in a multiprocessor system,
   but at least one hart must have a hart ID of zero. Hart IDs must be unique within the
   execution environment.
All that it guarantees it is that one of them should be zero and IDs are unique.

I think it would be better just to drop this check.

>> +            panic("there is no support for ACPI\n");
>> +
>> +        riscv_isa_parse_string(isa, this_isa);
>> +
>> +        if ( bitmap_empty(riscv_isa, RISCV_ISA_EXT_MAX) )
>> +            bitmap_copy(riscv_isa, this_isa, RISCV_ISA_EXT_MAX);
>> +        else
>> +            bitmap_and(riscv_isa, riscv_isa, this_isa, RISCV_ISA_EXT_MAX);
> What if the first instance had no extensions at all? You'll then copy what
> the second instance say, ending up with extensions not supported by one of
> the CPUs.

I think that it's impossible that there is no extensions at all and it should be
considered as a bug of provided riscv,isa property. Thereby it should be enough to
add BUG_ON(!bitmap_empty(this_isa, RISCV_ISA_EXT_MAX)) before if-condition.

>> --- /dev/null
>> +++ b/xen/arch/riscv/include/asm/cpufeature.h
>> @@ -0,0 +1,63 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +#ifndef ASM__RISCV__CPUFEATURE_H
>> +#define ASM__RISCV__CPUFEATURE_H
>> +
>> +#ifndef __ASSEMBLY__
>> +
>> +#define RISCV_ISA_EXT_a     ('a' - 'a')
>> +#define RISCV_ISA_EXT_c     ('c' - 'a')
>> +#define RISCV_ISA_EXT_d     ('d' - 'a')
>> +#define RISCV_ISA_EXT_f     ('f' - 'a')
>> +#define RISCV_ISA_EXT_h     ('h' - 'a')
>> +#define RISCV_ISA_EXT_i     ('i' - 'a')
>> +#define RISCV_ISA_EXT_m     ('m' - 'a')
>> +#define RISCV_ISA_EXT_q     ('q' - 'a')
>> +#define RISCV_ISA_EXT_v     ('v' - 'a')
>> +
>> +/*
>> + * Increse this to higher value as kernel support more ISA extensions.
>> + */
>> +#define RISCV_ISA_EXT_MAX   128
> What's this about? Why can't the last element of the enum below go without
> this, thus not needing manual bumping here?

RISCV_ISA_EXT_ID_MAX could be used instead of RISCV_ISA_EXT_MAX. RISCV_ISA_EXT_MAX it
is rudiment from Linux kernel which initially I decided to leave to have more close to
Linux kernel code.

>
>> +#define RISCV_ISA_EXT_SxAIA     RISCV_ISA_EXT_SSAIA
> Why does this expand to RISCV_ISA_EXT_SSAIA and not RISCV_ISA_EXT_SMAIA?
> (Easiest way to address: remove the #define, as it's unused. Yet if it
> is to be kept, the question needs addressing, perhaps by way of a code
> comment.)

I agree that it is better just to drop and I will do in that way.
Initial idea was close to Linux kernel. As Linux kernel could run in M mode
then these define should be *_EXT_SMAIA and if it is run in S mode then *_EXT_SSAIA:
#ifdef CONFIG_RISCV_M_MODE 
<https://elixir.bootlin.com/linux/v6.12.6/K/ident/CONFIG_RISCV_M_MODE> 
#define RISCV_ISA_EXT_SxAIA 
<https://elixir.bootlin.com/linux/v6.12.6/C/ident/RISCV_ISA_EXT_SxAIA> 
RISCV_ISA_EXT_SMAIA 
<https://elixir.bootlin.com/linux/v6.12.6/C/ident/RISCV_ISA_EXT_SMAIA> 
#else #define RISCV_ISA_EXT_SxAIA 
<https://elixir.bootlin.com/linux/v6.12.6/C/ident/RISCV_ISA_EXT_SxAIA> 
RISCV_ISA_EXT_SSAIA 
<https://elixir.bootlin.com/linux/v6.12.6/C/ident/RISCV_ISA_EXT_SSAIA> 
#endif And I thought to something similar with hypervisor ( before 
decided that hypervisor mode is mandatory ).

>
>> +/*
>> + * These macros represent the logical IDs of each multi-letter RISC-V ISA
>> + * extension and are used in the ISA bitmap. The logical IDs start from
>> + * RISCV_ISA_EXT_BASE, which allows the 0-25 range to be reserved for single
>> + * letter extensions. The maximum, RISCV_ISA_EXT_MAX, is defined in order
>> + * to allocate the bitmap and may be increased when necessary.
>> + *
>> + * New extensions should just be added to the bottom, rather than added
>> + * alphabetically, in order to avoid unnecessary shuffling.
>> + */
>> +#define RISCV_ISA_EXT_BASE  26
> The comment living above this #define, it also wants wording to match
> this. Specifically the text starts with describing ...
>
>> +enum riscv_isa_ext_id {
> ... this enum instead (which doesn't consist of any macros).
>
>> +    RISCV_ISA_EXT_ZICNTR = RISCV_ISA_EXT_BASE,
>> +    RISCV_ISA_EXT_ZICSR,
>> +    RISCV_ISA_EXT_ZIFENCEI,
>> +    RISCV_ISA_EXT_ZIHINTPAUSE,
>> +    RISCV_ISA_EXT_ZIHPM,
>> +    RISCV_ISA_EXT_ZBB,
>> +    RISCV_ISA_EXT_SMAIA,
>> +    RISCV_ISA_EXT_SSAIA,
>> +    RISCV_ISA_EXT_ID_MAX = RISCV_ISA_EXT_MAX,
>> +};
> Why can't the single-letter RISCV_ISA_EXT_? be part of this enum as well?

Good point. It could and would be better. Thereby I will refactor that.


>
>> +void riscv_fill_hwcap(void);
>> +
>> +bool riscv_isa_extension_available(const unsigned long *isa_bitmap, int bit);
> A signed bit position? Can negative values be passed in? Actually - can't
> this be enum riscv_isa_ext_id anyway?

No, negative values can't be passed. Extension IDs are always positive.
If we will move everything ( single-letter extensions too ) to enum
riscv_isa_ext_id then we can use enum riscv_isa_ext_id
instead of int here. I think that it would be really better so I will refactor that
accordingly.

Thanks for review!

~ Oleksii

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

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <pre class="moz-cite-prefix">On 1/8/25 4:21 PM, Jan Beulich wrote:
</pre>
    <blockquote type="cite"
      cite="mid:bc636259-5586-428c-8a57-f97ba16a14b8@suse.com">
      <pre wrap="" class="moz-quote-pre">On 23.12.2024 13:55, Oleksii Kurochko wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">--- /dev/null
+++ b/xen/arch/riscv/cpufeature.c
@@ -0,0 +1,466 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Taken for Linux kernel v6.12-rc3 and modified by
+ * Oleksii Kurochko <a class="moz-txt-link-rfc2396E" href="mailto:oleksii.kurochko@gmail.com">&lt;oleksii.kurochko@gmail.com&gt;</a>:
+ *
+ * - Drop unconditional setting of {RISCV_ISA_EXT_ZICSR,
+ *   RISCV_ISA_EXT_ZIFENCEI, RISCV_ISA_EXT_ZICNTR, RISCV_ISA_EXT_ZIHPM} as they
+ *   are now part of the riscv,isa string.
+ * - Remove saving of the ISA for each CPU, only the common available ISA is
+ *   saved.
+ * - Remove ACPI-related code as ACPI is not supported by Xen.
+ * - Drop handling of elf_hwcap, since Xen does not provide hwcap to
+ *   userspace.
+ * - Replace of_cpu_device_node_get() API, which is not available in Xen,
+ *   with a combination of dt_for_each_child_node(), dt_device_type_is_equal(),
+ *   and dt_get_cpuid_from_node() to retrieve cpuid and riscv,isa in
+ *   riscv_fill_hwcap_from_isa_string().
+ * - Rename arguments of __RISCV_ISA_EXT_DATA() from _name to ext_name, and
+ *   _id to ext_id for clarity.
+ * - Replace instances of __RISCV_ISA_EXT_DATA with RISCV_ISA_EXT_DATA.
+ * - Replace instances of __riscv_isa_extension_available with
+ *   riscv_isa_extension_available for consistency.
+ * - Redefine RISCV_ISA_EXT_DATA() to work only with ext_name and ext_id,
+ *   as other fields are not used in Xen currently.
+ * - Add check of first 4 letters of riscv,isa string to
+ *   riscv_isa_parse_string() as Xen doesn't do this check before so it is
+ *   necessary to check correctness of riscv,isa string. ( it should start with
+ *   rv{32,64} with taking into account upper and lower case of "rv").
+ * - Drop an argument of riscv_fill_hwcap() and riscv_fill_hwcap_from_isa_string()
+ *   as it isn't used, at the moment.
+ * - s/pr_info/printk.
+ * - Apply Xen coding style.
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
Having this in the patch description is sufficient imo.

</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">+ * Copyright (C) 2015 ARM Ltd.
+ * Copyright (C) 2017 SiFive
+ * Copyright (C) 2024 Vates
+ */
+
+#include &lt;xen/acpi.h&gt;
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
Didn't you say you dropped the ACPI pieces?</pre>
    </blockquote>
    <pre>Yes, they are dropped but my intention was to add "panic("%s should be updated correspondingly to support ACPI\n", __func__)"
for the places where ACPI changes should be done in case of ACPI support will be added. And these places are detected by
checking acpi_disabled variable which is in &lt;xen/acpi.h&gt;.

</pre>
    <blockquote type="cite"
      cite="mid:bc636259-5586-428c-8a57-f97ba16a14b8@suse.com">
      <pre wrap="" class="moz-quote-pre">

</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">+#include &lt;xen/bitmap.h&gt;
+#include &lt;xen/ctype.h&gt;
+#include &lt;xen/device_tree.h&gt;
+#include &lt;xen/errno.h&gt;
+#include &lt;xen/init.h&gt;
+#include &lt;xen/lib.h&gt;
+#include &lt;xen/sections.h&gt;
+
+#include &lt;asm/cpufeature.h&gt;
+
+struct riscv_isa_ext_data {
+    const unsigned int id;
+    const char *name;
+};
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
This is odd - why would the id be const, but not the name? Thus you
require all instances of the struct to have an initializer. The more
conventional approach is to apply the const on the instances of the
structure (e.g. as you already have it for riscv_isa_ext[]). </pre>
    </blockquote>
    <pre>Agree, not too much sense to have const id, but not the name. Then it should be also "const char * const name".

Lets follow conventional approach and declare riscv_isa_ext_data structure as:
  struct riscv_isa_ext_data {
      unsigned int id;
      const char *name;
  };
name member of riscv_isa_ext_data structure still should be "const char *" to avoid compilation error:
  discarding of `const' qualifier from pointer target type.

An option could be to have a case in macros RISCV_ISA_EXT_DATA():
  #define RISCV_ISA_EXT_DATA(ext_name, ext_id)    \
  {                                               \
      .id = ext_id,                               \
      .name = (char *)#ext_name,                  \
  }
But IMO it is better just to declare riscv_isa_ext_data as suggested above.

</pre>
    <blockquote type="cite"
      cite="mid:bc636259-5586-428c-8a57-f97ba16a14b8@suse.com">
      <pre wrap="" class="moz-quote-pre">
</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">+static int __init dt_get_cpuid_from_node(const struct dt_device_node *cpu)
+{
+    const __be32 *prop;
+    unsigned int reg_len;
+
+    if ( dt_n_size_cells(cpu) != 0 )
+        printk("cpu node `%s`: #size-cells %d\n",
+               dt_node_full_name(cpu), dt_n_size_cells(cpu));
+
+    prop = dt_get_property(cpu, "reg", &amp;reg_len);
+    if ( !prop )
+    {
+        printk("cpu node `%s`: has no reg property\n", dt_node_full_name(cpu));
+        return -EINVAL;
+    }
+
+    if ( reg_len &lt; dt_cells_to_size(dt_n_addr_cells(cpu)) )
+    {
+        printk("cpu node `%s`: reg property too short\n",
+               dt_node_full_name(cpu));
+        return -EINVAL;
+    }
+
+    return dt_read_paddr(prop, dt_n_addr_cells(cpu));
+}
+
+/*
+ * The canonical order of ISA extension names in the ISA string is defined in
+ * chapter 27 of the unprivileged specification.
+ *
+ * Ordinarily, for in-kernel data structures, this order is unimportant but
+ * isa_ext_arr defines the order of the ISA string in /proc/cpuinfo.
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
Inapplicable Linux detail? (If you want to keep it, you'll want to add
"Linux'es" and avoid mentioning something that looks like a variable
but then doesn't exist anywhere.)</pre>
    </blockquote>
    <pre>Agree, no need for this Linux detail, it is not really useful in our case. I will drop it.

</pre>
    <blockquote type="cite"
      cite="mid:bc636259-5586-428c-8a57-f97ba16a14b8@suse.com">
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">+    RISCV_ISA_EXT_DATA(i, RISCV_ISA_EXT_i),
+    RISCV_ISA_EXT_DATA(m, RISCV_ISA_EXT_m),
+    RISCV_ISA_EXT_DATA(a, RISCV_ISA_EXT_a),
+    RISCV_ISA_EXT_DATA(f, RISCV_ISA_EXT_f),
+    RISCV_ISA_EXT_DATA(d, RISCV_ISA_EXT_d),
+    RISCV_ISA_EXT_DATA(q, RISCV_ISA_EXT_q),
+    RISCV_ISA_EXT_DATA(h, RISCV_ISA_EXT_h),
+    RISCV_ISA_EXT_DATA(zicntr, RISCV_ISA_EXT_ZICNTR),
+    RISCV_ISA_EXT_DATA(zicsr, RISCV_ISA_EXT_ZICSR),
+    RISCV_ISA_EXT_DATA(zifencei, RISCV_ISA_EXT_ZIFENCEI),
+    RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE),
+    RISCV_ISA_EXT_DATA(zihpm, RISCV_ISA_EXT_ZIHPM),
+    RISCV_ISA_EXT_DATA(zbb, RISCV_ISA_EXT_ZBB),
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
Isn't it kind of implied that with the presence of Zbb, B should also be
present?
</pre>
    </blockquote>
    <pre>My interpretation of the RISC-V Bitmanip Extension spec is that the 'B' extension is essentially a collection of
the Zba, Zbb, Zbs, and other extensions, but it isn't an extension by itself.
The following is mentioned in the spec:
  The bit-manipulation (bitmanip) extension collection is comprised of several component extensions to the base
  RISC-V architecture that are intended to provide some combination of code size reduction, performance
  improvement, and energy reduction. While the instructions are intended to have general use, some instructions
  are more useful in some domains than others. Hence, several smaller bitmanip extensions are provided, rather
  than one large extension. Each of these smaller extensions is grouped by common function and use case, and
  each of which has its own Zb*-extension name.</pre>
    <blockquote type="cite"
      cite="mid:bc636259-5586-428c-8a57-f97ba16a14b8@suse.com">
      <pre wrap="" class="moz-quote-pre">
</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">+    RISCV_ISA_EXT_DATA(smaia, RISCV_ISA_EXT_SMAIA),
+    RISCV_ISA_EXT_DATA(ssaia, RISCV_ISA_EXT_SSAIA),
+};
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
Wouldn't the Z and S prefixes better be recorded in upper case here?</pre>
    </blockquote>
    <pre>I decided that it is always mentioned in lower case in the spec, but it is wrong and Z and S are
used in upper case ( <a class="moz-txt-link-freetext" href="https://github.com/riscv/riscv-isa-manual/blob/main/src/naming.adoc#subset-naming-convention">https://github.com/riscv/riscv-isa-manual/blob/main/src/naming.adoc#subset-naming-convention</a> ),
and also there is another one reason mentioned in an answer to another your question below. ( it was marked as [1] )

</pre>
    <blockquote type="cite"
      cite="mid:bc636259-5586-428c-8a57-f97ba16a14b8@suse.com">
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">+    RISCV_ISA_EXT_DATA(zbb, RISCV_ISA_EXT_ZBB),
+    RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE),
+};
+
+static const size_t riscv_isa_ext_count = ARRAY_SIZE(riscv_isa_ext);
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
Is this variable really useful to have?</pre>
    </blockquote>
    <pre>Not really. ( at least, at the moment ) It could be dropped.

</pre>
    <blockquote type="cite"
      cite="mid:bc636259-5586-428c-8a57-f97ba16a14b8@suse.com">
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">+    {
+        const struct riscv_isa_ext_data *ext = &amp;riscv_isa_ext[i];
+
+        if ( (name_end - name == strlen(ext-&gt;name)) &amp;&amp;
+             !strncasecmp(name, ext-&gt;name, name_end - name) )
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
Does this really need to be a case-insensitive comparison?
</pre>
    </blockquote>
    <pre>[1]:
Considering that we are discussing to use Z and S in upper case then we need to use strncasecmp()
because `name` comes from riscv, isa property of device tree and it means that letters in
the riscv,isa string must be all lowercase ( <a class="moz-txt-link-freetext" href="https://elixir.bootlin.com/linux/v6.12.6/source/Documentation/devicetree/bindings/riscv/extensions.yaml#L34">https://elixir.bootlin.com/linux/v6.12.6/source/Documentation/devicetree/bindings/riscv/extensions.yaml#L34</a> )
so we have to avoid comparison of extension names which could start in upper case with the same extension name which starts
from lower case:
<span id="codeline-47" class="line-highlight"
style="box-sizing: inherit; background: rgb(248, 237, 195); vertical-align: top; display: block; padding-left: 1em; width: 861.15px; height: 17.275px;"><span
    class="w"
style="box-sizing: inherit; vertical-align: top; color: rgb(187, 187, 187);">      </span><span
    class="l l-Scalar l-Scalar-Plain"
    style="box-sizing: inherit; vertical-align: top;">While the <a
    class="ident"
    href="https://elixir.bootlin.com/linux/v6.12.6/B/ident/isa"
style="box-sizing: inherit; background: linear-gradient(rgba(0, 0, 0, 0) 10%, rgb(244, 246, 255) 10%, rgb(244, 246, 255) 90%, rgba(0, 0, 0, 0) 90%); color: inherit; text-decoration: none; vertical-align: top; font-weight: 700; border-radius: 0.2em;">isa</a> strings in ISA specification are case</span>
</span><span id="codeline-48"
style="box-sizing: inherit; vertical-align: top; display: block; padding-left: 1em;"><span
    class="w"
style="box-sizing: inherit; vertical-align: top; color: rgb(187, 187, 187);">      </span><span
    class="l l-Scalar l-Scalar-Plain"
    style="box-sizing: inherit; vertical-align: top;">insensitive, letters in the riscv,isa string must be all</span>
</span><span id="codeline-49"
style="box-sizing: inherit; vertical-align: top; display: block; padding-left: 1em;"><span
    class="w"
style="box-sizing: inherit; vertical-align: top; color: rgb(187, 187, 187);">      </span><span
    class="l l-Scalar l-Scalar-Plain"
    style="box-sizing: inherit; vertical-align: top;">lowercase.

And so to avoid comparison of a name from riscv_isa_ext[] which could be theoretically starts from upper case
we have to use strncasecmp() to transform everything to lower case before comparison. And it seems it is better
to be on a safe side for the cases when some accidentally will use upper case or in riscv_isa_ext[] or in riscv,isa property
of device-tree.
</span>
</span></pre>
    <blockquote type="cite"
      cite="mid:bc636259-5586-428c-8a57-f97ba16a14b8@suse.com">
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">+            break;
+        }
+    }
+}
+
+static int __init riscv_isa_parse_string(const char *isa, unsigned long *out_bitmap)
+{
+    if ( isa[0] != 'r' &amp;&amp; isa[0] != 'R' )
+        return -EINVAL;
+
+    if ( isa[1] != 'v' &amp;&amp; isa[1] != 'V' )
+        return -EINVAL;
+
+    if ( isa[2] != '3' &amp;&amp; isa[3] != '2' &amp;&amp;
+         isa[2] != '6' &amp;&amp; isa[3] != '4' )
+        return -EINVAL;
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
Any reason to accept the (respectively, depending on configuration) wrong
bitness? Or to accept e.g. RV34?</pre>
    </blockquote>
    <pre>Good question. I think there is no any reason to accept the wrong bitness and
it is a bug. I'll re-write the last if-condition.

</pre>
    <blockquote type="cite"
      cite="mid:bc636259-5586-428c-8a57-f97ba16a14b8@suse.com">
      <pre wrap="" class="moz-quote-pre">

</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">+    isa += 4;
+
+    while ( *isa )
+    {
+        const char *ext = isa++;
+        const char *ext_end = isa;
+        bool ext_err = false;
+
+        switch ( *ext )
+        {
+        case 'x':
+        case 'X':
+            if ( acpi_disabled )
+                printk_once("Vendor extensions are ignored in riscv,isa."
+                            "Use riscv,isa-extensions instead\n");
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
How's this connected to ACPI? The more that you said there's nothing
ACPI-ish left.</pre>
    </blockquote>
    <pre>The same as above just left that for the case if one day someone will add ACPI support.
( but, at the moment, we could drop it or I will update the comment when I wrote about
dropping of ACPI-connected things to something like: "ACPI is almost fully drop and leave
only places where a code should be updated to have ACPI support".</pre>
    <blockquote type="cite"
      cite="mid:bc636259-5586-428c-8a57-f97ba16a14b8@suse.com">
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">+            /*
+             * Workaround for invalid single-letter 's' &amp; 'u' (QEMU).
+             * No need to set the bit in riscv_isa as 's' &amp; 'u' are
+             * not valid ISA extensions. It works unless the first
+             * multi-letter extension in the ISA string begins with
+             * "Su" and is not prefixed with an underscore.
+             */
+            if ( ext[-1] != '_' &amp;&amp; ext[1] == 'u' )
+            {
+                ++isa;
+                ext_err = true;
+                break;
+            }
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
I'm afraid I don't understand this; the comment raises more questions
than it answers.</pre>
    </blockquote>
    <pre>Some details could be found here about these QEMU workaround from LK view:
<a class="moz-txt-link-freetext" href="https://lore.kernel.org/linux-riscv/ae93358e-e117-b43d-faad-772c529f846c@irq.a4lg.com/#t">https://lore.kernel.org/linux-riscv/ae93358e-e117-b43d-faad-772c529f846c@irq.a4lg.com/#t</a>

This leads to the following fix in QEMU:
<a class="moz-txt-link-freetext" href="https://patchwork.kernel.org/project/qemu-devel/patch/dee09d708405075420b29115c1e9e87910b8da55.1648270894.git.research_trasio@irq.a4lg.com/#24792587">https://patchwork.kernel.org/project/qemu-devel/patch/dee09d708405075420b29115c1e9e87910b8da55.1648270894.git.research_trasio@irq.a4lg.com/#24792587</a>

Considering QEMU's patch, these workaround isn't needed anymore since QEMU 7.1 ( it has been released <span
style="font-family: Roboto, sans-serif; font-size: 11.7333px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 300; letter-spacing: 1px; text-align: start; text-indent: 0px; text-transform: uppercase; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; display: inline !important; float: none;">30 Aug 2022</span> ) probably we could update the
QEMU version on our CI and just drop these changes.
Or, at least, update the comment with the links mentioned above and add a message that these changes are needed only for QEMU &lt; 7.1.
Am I right that we don't have something like GCC_VERSION in Xen but for QEMU?
</pre>
    <blockquote type="cite"
      cite="mid:bc636259-5586-428c-8a57-f97ba16a14b8@suse.com">
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">+        if ( !dt_device_type_is_equal(cpu, "cpu") )
+            continue;
+
+        cpuid = dt_get_cpuid_from_node(cpu);
+        if ( cpuid &lt; 0 )
+            continue;
+
+        if ( cpuid &gt;= NR_CPUS )
+        {
+            printk_once("%s: dts has more cpu than NR_CPUs\n", __func__);
+            continue;
+        }
+
+        if ( dt_property_read_string(cpu, "riscv,isa-extensions", &amp;isa) )
+        {
+            printk("Unable to find \"riscv,isa-extensions\" devicetree entry "
+                   "for cpu%d\n", cpuid);
+            continue;
+        }
+        else
+            printk("riscv,isa-extensions isnt supported\n");
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
IOW no matter what, a message will be logged. Odd.</pre>
    </blockquote>
    <pre>I think it should be panic but I confused it with printk...

</pre>
    <blockquote type="cite"
      cite="mid:bc636259-5586-428c-8a57-f97ba16a14b8@suse.com">
      <pre wrap="" class="moz-quote-pre">

Also: Preferably no "else" after an if() ending in "continue".</pre>
    </blockquote>
    <pre>If I understand you correctly, we really can drop here "else" and just
panic("riscv,isa-extensions isnt supported\n"), and it would be enough.</pre>
    <blockquote type="cite"
      cite="mid:bc636259-5586-428c-8a57-f97ba16a14b8@suse.com">
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">+        DECLARE_BITMAP(this_isa, RISCV_ISA_EXT_MAX);
+
+        if ( !dt_device_type_is_equal(cpu, "cpu") )
+            continue;
+
+        cpuid = dt_get_cpuid_from_node(cpu);
+        if ( cpuid &lt; 0 )
+            continue;
+
+        if ( cpuid &gt;= NR_CPUS )
+        {
+            printk_once("%s: dts has more cpu than NR_CPUs\n", __func__);
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
What's "dts"? Did the 's' mean to be in "cpus" instead? Also NR_CPUS
to avoid confusion.</pre>
    </blockquote>
    <pre>DTS here means Device Tree Source. It would be more clear to write in the following way:
"CPU id is higher then maximum number of CPUs in Xen."
But I am not sure that his check is correct as it is not clearly defined that CPU ids are
from the range from 0 to NR_CPUS. The following is mentioned in the spec:
  Hart IDs might not necessarily be numbered contiguously in a multiprocessor system,
  but at least one hart must have a hart ID of zero. Hart IDs must be unique within the
  execution environment.
All that it guarantees it is that one of them should be zero and IDs are unique.

I think it would be better just to drop this check.
</pre>
    <pre>
</pre>
    <blockquote type="cite"
      cite="mid:bc636259-5586-428c-8a57-f97ba16a14b8@suse.com">
      <pre wrap="" class="moz-quote-pre">
</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">+            panic("there is no support for ACPI\n");
+
+        riscv_isa_parse_string(isa, this_isa);
+
+        if ( bitmap_empty(riscv_isa, RISCV_ISA_EXT_MAX) )
+            bitmap_copy(riscv_isa, this_isa, RISCV_ISA_EXT_MAX);
+        else
+            bitmap_and(riscv_isa, riscv_isa, this_isa, RISCV_ISA_EXT_MAX);
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
What if the first instance had no extensions at all? You'll then copy what
the second instance say, ending up with extensions not supported by one of
the CPUs. 
</pre>
    </blockquote>
    <pre>I think that it's impossible that there is no extensions at all and it should be 
considered as a bug of provided riscv,isa property. Thereby it should be enough to
add BUG_ON(!bitmap_empty(this_isa, RISCV_ISA_EXT_MAX)) before if-condition.
</pre>
    <blockquote type="cite"
      cite="mid:bc636259-5586-428c-8a57-f97ba16a14b8@suse.com">
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">--- /dev/null
+++ b/xen/arch/riscv/include/asm/cpufeature.h
@@ -0,0 +1,63 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef ASM__RISCV__CPUFEATURE_H
+#define ASM__RISCV__CPUFEATURE_H
+
+#ifndef __ASSEMBLY__
+
+#define RISCV_ISA_EXT_a     ('a' - 'a')
+#define RISCV_ISA_EXT_c     ('c' - 'a')
+#define RISCV_ISA_EXT_d     ('d' - 'a')
+#define RISCV_ISA_EXT_f     ('f' - 'a')
+#define RISCV_ISA_EXT_h     ('h' - 'a')
+#define RISCV_ISA_EXT_i     ('i' - 'a')
+#define RISCV_ISA_EXT_m     ('m' - 'a')
+#define RISCV_ISA_EXT_q     ('q' - 'a')
+#define RISCV_ISA_EXT_v     ('v' - 'a')
+
+/*
+ * Increse this to higher value as kernel support more ISA extensions.
+ */
+#define RISCV_ISA_EXT_MAX   128
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
What's this about? Why can't the last element of the enum below go without
this, thus not needing manual bumping here?</pre>
    </blockquote>
    <pre>RISCV_ISA_EXT_ID_MAX could be used instead of RISCV_ISA_EXT_MAX. RISCV_ISA_EXT_MAX it
is rudiment from Linux kernel which initially I decided to leave to have more close to
Linux kernel code.

</pre>
    <blockquote type="cite"
      cite="mid:bc636259-5586-428c-8a57-f97ba16a14b8@suse.com">
      <pre wrap="" class="moz-quote-pre">

</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">+#define RISCV_ISA_EXT_SxAIA     RISCV_ISA_EXT_SSAIA
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
Why does this expand to RISCV_ISA_EXT_SSAIA and not RISCV_ISA_EXT_SMAIA?
(Easiest way to address: remove the #define, as it's unused. Yet if it
is to be kept, the question needs addressing, perhaps by way of a code
comment.)</pre>
    </blockquote>
    <pre>I agree that it is better just to drop and I will do in that way.
Initial idea was close to Linux kernel. As Linux kernel could run in M mode
then these define should be *_EXT_SMAIA and if it is run in S mode then *_EXT_SSAIA:
<span id="codeline-102"
style="box-sizing: inherit; vertical-align: top; display: block; padding-left: 1em;"><span
    class="cp"
style="box-sizing: inherit; vertical-align: top; color: rgb(85, 119, 153);">#ifdef <a
    class="ident"
href="https://elixir.bootlin.com/linux/v6.12.6/K/ident/CONFIG_RISCV_M_MODE"
style="box-sizing: inherit; background: linear-gradient(rgba(0, 0, 0, 0) 10%, rgb(244, 246, 255) 10%, rgb(244, 246, 255) 90%, rgba(0, 0, 0, 0) 90%); color: inherit; text-decoration: none; vertical-align: top; font-weight: 700; border-radius: 0.2em;">CONFIG_RISCV_M_MODE</a></span>
</span><span id="codeline-103" class="line-highlight"
style="box-sizing: inherit; background: rgb(248, 237, 195); vertical-align: top; display: block; padding-left: 1em; width: 671.037px; height: 17.275px;"><span
    class="cp"
style="box-sizing: inherit; vertical-align: top; color: rgb(85, 119, 153);">#define <a
    class="ident"
href="https://elixir.bootlin.com/linux/v6.12.6/C/ident/RISCV_ISA_EXT_SxAIA"
style="box-sizing: inherit; background: linear-gradient(rgba(0, 0, 0, 0) 10%, rgb(244, 246, 255) 10%, rgb(244, 246, 255) 90%, rgba(0, 0, 0, 0) 90%); color: inherit; text-decoration: none; vertical-align: top; font-weight: 700; border-radius: 0.2em;">RISCV_ISA_EXT_SxAIA</a>		<a
    class="ident"
href="https://elixir.bootlin.com/linux/v6.12.6/C/ident/RISCV_ISA_EXT_SMAIA"
style="box-sizing: inherit; background: linear-gradient(rgba(0, 0, 0, 0) 10%, rgb(244, 246, 255) 10%, rgb(244, 246, 255) 90%, rgba(0, 0, 0, 0) 90%); color: inherit; text-decoration: none; vertical-align: top; font-weight: 700; border-radius: 0.2em;">RISCV_ISA_EXT_SMAIA</a></span>
</span><span id="codeline-104"
style="box-sizing: inherit; vertical-align: top; display: block; padding-left: 1em;"><span
    class="cp"
style="box-sizing: inherit; vertical-align: top; color: rgb(85, 119, 153);">#else</span>
</span><span id="codeline-105"
style="box-sizing: inherit; vertical-align: top; display: block; padding-left: 1em;"><span
    class="cp"
style="box-sizing: inherit; vertical-align: top; color: rgb(85, 119, 153);">#define <a
    class="ident"
href="https://elixir.bootlin.com/linux/v6.12.6/C/ident/RISCV_ISA_EXT_SxAIA"
style="box-sizing: inherit; background: linear-gradient(rgba(0, 0, 0, 0) 10%, rgb(244, 246, 255) 10%, rgb(244, 246, 255) 90%, rgba(0, 0, 0, 0) 90%); color: inherit; text-decoration: none; vertical-align: top; font-weight: 700; border-radius: 0.2em;">RISCV_ISA_EXT_SxAIA</a>		<a
    class="ident"
href="https://elixir.bootlin.com/linux/v6.12.6/C/ident/RISCV_ISA_EXT_SSAIA"
style="box-sizing: inherit; background: linear-gradient(rgba(0, 0, 0, 0) 10%, rgb(244, 246, 255) 10%, rgb(244, 246, 255) 90%, rgba(0, 0, 0, 0) 90%); color: inherit; text-decoration: none; vertical-align: top; font-weight: 700; border-radius: 0.2em;">RISCV_ISA_EXT_SSAIA</a></span>
</span><span id="codeline-106"
style="box-sizing: inherit; vertical-align: top; display: block; padding-left: 1em;"><span
    class="cp"
style="box-sizing: inherit; vertical-align: top; color: rgb(85, 119, 153);">#endif

</span><span class="cp"
    style="box-sizing: inherit; vertical-align: top;">And I thought to something similar with hypervisor ( before decided that hypervisor mode is mandatory ).
</span></span></pre>
    <blockquote type="cite"
      cite="mid:bc636259-5586-428c-8a57-f97ba16a14b8@suse.com">
      <pre wrap="" class="moz-quote-pre">

</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">+/*
+ * These macros represent the logical IDs of each multi-letter RISC-V ISA
+ * extension and are used in the ISA bitmap. The logical IDs start from
+ * RISCV_ISA_EXT_BASE, which allows the 0-25 range to be reserved for single
+ * letter extensions. The maximum, RISCV_ISA_EXT_MAX, is defined in order
+ * to allocate the bitmap and may be increased when necessary.
+ *
+ * New extensions should just be added to the bottom, rather than added
+ * alphabetically, in order to avoid unnecessary shuffling.
+ */
+#define RISCV_ISA_EXT_BASE  26
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
The comment living above this #define, it also wants wording to match
this. Specifically the text starts with describing ...

</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">+enum riscv_isa_ext_id {
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
... this enum instead (which doesn't consist of any macros).

</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">+    RISCV_ISA_EXT_ZICNTR = RISCV_ISA_EXT_BASE,
+    RISCV_ISA_EXT_ZICSR,
+    RISCV_ISA_EXT_ZIFENCEI,
+    RISCV_ISA_EXT_ZIHINTPAUSE,
+    RISCV_ISA_EXT_ZIHPM,
+    RISCV_ISA_EXT_ZBB,
+    RISCV_ISA_EXT_SMAIA,
+    RISCV_ISA_EXT_SSAIA,
+    RISCV_ISA_EXT_ID_MAX = RISCV_ISA_EXT_MAX,
+};
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
Why can't the single-letter RISCV_ISA_EXT_? be part of this enum as well?</pre>
    </blockquote>
    <pre>Good point. It could and would be better. Thereby I will refactor that.
</pre>
    <p><br>
    </p>
    <blockquote type="cite"
      cite="mid:bc636259-5586-428c-8a57-f97ba16a14b8@suse.com">
      <pre wrap="" class="moz-quote-pre">

</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">+void riscv_fill_hwcap(void);
+
+bool riscv_isa_extension_available(const unsigned long *isa_bitmap, int bit);
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
A signed bit position? Can negative values be passed in? Actually - can't
this be enum riscv_isa_ext_id anyway?</pre>
    </blockquote>
    <pre>No, negative values can't be passed. Extension IDs are always positive.
If we will move everything ( single-letter extensions too ) to enum 
riscv_isa_ext_id then we can use enum riscv_isa_ext_id
instead of int here. I think that it would be really better so I will refactor that
accordingly.

Thanks for review!
</pre>
    <pre>~ Oleksii</pre>
  </body>
</html>

--------------M8hA5d9ESfqddvD8G6y0PyIq--


From xen-devel-bounces@lists.xenproject.org Mon Jan 13 17:18:19 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Jan 2025 17:18:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870792.1281864 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXO4s-0000NT-Ha; Mon, 13 Jan 2025 17:18:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870792.1281864; Mon, 13 Jan 2025 17:18:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXO4s-0000NM-Db; Mon, 13 Jan 2025 17:18:14 +0000
Received: by outflank-mailman (input) for mailman id 870792;
 Mon, 13 Jan 2025 17:18: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
 <SRS0=Q7wO=UF=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tXO4r-0000NG-RT
 for xen-devel@lists.xenproject.org; Mon, 13 Jan 2025 17:18:13 +0000
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com
 [2a00:1450:4864:20::229])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5dbab8fe-d1d2-11ef-99a4-01e77a169b0f;
 Mon, 13 Jan 2025 18:18:11 +0100 (CET)
Received: by mail-lj1-x229.google.com with SMTP id
 38308e7fff4ca-3043e84c687so35049841fa.1
 for <xen-devel@lists.xenproject.org>; Mon, 13 Jan 2025 09:18:11 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-305ff1c7b99sm15606661fa.84.2025.01.13.09.18.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 13 Jan 2025 09:18:10 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5dbab8fe-d1d2-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736788691; x=1737393491; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=O5HjDTBYIqq6mb8lh3R3GImpfBdHQLjRud0GwSs4KM4=;
        b=VX8f834Df31zQBQS01pzZmxPCM6gbbSZwWktQa6vlIqHc0CRmSyMavd2abR2jraC0U
         QHPQSvZAT2lc10ncUf9amp69KRHp9mgBi7O7eC9Ax8sQJkGnmW9PREjw3/4rTq5evLtU
         xDr2EKC3ln49w5UMDuDQ9kNfjKp6UOcfqPm8IFuV9zg7L9dR5Hmh2y4try6Nn7mR8MCR
         mtHY1dtWBKyTLjnuNS0SGFCJHA3qhEGFbumo+wzWuOMBr1UdQd5DCguEtWQczQfkXHpA
         qQpvvtoolV6furOFszgWlyZ/sY2kr19mislI6xuZyjM5SL6Z10F0u9gDnNk7YxqZSbGU
         iYvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736788691; x=1737393491;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=O5HjDTBYIqq6mb8lh3R3GImpfBdHQLjRud0GwSs4KM4=;
        b=Fx+GVyxLDC7XIoxlL0HfNTtuwtCChA+LaW/f94K2h+MAz7N7wOm/OP+TIXOZa30h4+
         VLq1WWnjZmAOi5q4uSQPCE+qsiK188aOtvI5tyoG4IbiCMps3sOrtOeBGCsa2Z7iem/T
         myIJllMHz7kSof9rvh38oJeWLFxNxwfmWfqdmhnHMIpL33vnzdEY0njuMtFGSKug1cni
         TFaIxIY+ZCvYEmibbEAB9Jy08pPSKsc95QySvdENpwI/4Qax7tfxCxOj7iCSDwl4NeQW
         1wm8j3+PeGUHfL6aZEwY4x+BlU1f5jsV81l7ijl8wYLCIfa//nGIFgwBdZGvlKTTBQoC
         68WQ==
X-Forwarded-Encrypted: i=1; AJvYcCVDgIxsvt4CkdJs5JFx/xNGK0zK4c+qeSWA+mbMfFv+fXgSDv6vZisSX7dU03lQsPRN53/8rr3WWuA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwTeDTPGwAQuIkdwPq/kN4FBvDlcnKYt1hviNb7LOlBqyIQlaaA
	nctZH05dPzbF9VbYT7XEdWxyWjy1xV/Vzh5mB+J7xzOrYMdFYhQO
X-Gm-Gg: ASbGncveI5S93T6OWQocFjJIwZMGZPB85VlI+K7LPyF/B6k68S8MPlvPbGqBZwrz0ZE
	oRwPfZx4BnbYaV1tAqVTXSjov1+zT5BbSlAuTB2yxu7WG+NfnhSNr+lWGgju2fE0wkd8T6JRTZ6
	S/+8J5Ak/r0WbWjMffEtpDdDyz5vkV2RJtqIBVjBxInkDevDvnjpY6oIjVQy5PEF2S12hJTLjO6
	qmBlswqJj8l6Gs5qgdzHjw2wT4nZVyZGczserykoDNitPM57G24p0sHMTOfBxvB4DJhUA==
X-Google-Smtp-Source: AGHT+IFOVketSCQTF1nklmx6YCWUutCyFJVZLFbUGrISJS6ggkjSSAxnfOrEEbYfSybBjBwgtEkM+A==
X-Received: by 2002:a2e:a78a:0:b0:300:1f2c:e3cf with SMTP id 38308e7fff4ca-305f454ffabmr75361171fa.13.1736788690955;
        Mon, 13 Jan 2025 09:18:10 -0800 (PST)
Message-ID: <333f50dd-927d-43de-8b49-6865648a9ec5@gmail.com>
Date: Mon, 13 Jan 2025 18:18:09 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 0/2] x86: Add Support for Paging-Write Feature
To: Tamas K Lengyel <tamas@tklengyel.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>
Cc: =?UTF-8?Q?Petr_Bene=C5=A1?= <w1benny@gmail.com>,
 xen-devel@lists.xenproject.org, Alexandru Isaila <aisaila@bitdefender.com>,
 Petre Pircalabu <ppircalabu@bitdefender.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Anthony PERARD <anthony.perard@vates.tech>
References: <cover.1735837806.git.w1benny@gmail.com>
 <4eea61a2-cf56-4ff5-8c43-58f5a20c9cb1@gmail.com>
 <CABfawhmHK_Lg8GuVr9yb1gw82YFs3e1gh76azzH8C98R552dSw@mail.gmail.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <CABfawhmHK_Lg8GuVr9yb1gw82YFs3e1gh76azzH8C98R552dSw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


On 1/9/25 4:25 PM, Tamas K Lengyel wrote:
> On Thu, Jan 9, 2025 at 9:30 AM Oleksii Kurochko
> <oleksii.kurochko@gmail.com> wrote:
>>
>> On 1/2/25 6:13 PM, Petr Beneš wrote:
>>
>> From: Petr Beneš <w1benny@gmail.com>
>>
>> Changes since v2:
>> - Reset entry->pw in all cases in p2m_set_entry, except for p2m_access_r_pw
>>
>> Changes since v1:
>> - Added signed-off-by tags
>>
>> This patch introduces a new XENMEM_access_r_pw permission. Functionally, it is similar to XENMEM_access_r, but for processors with TERTIARY_EXEC_EPT_PAGING_WRITE support (Intel 12th Gen/Alder Lake and later), it also permits the CPU to write to the page during guest page-table walks (e.g., updating A/D bits) without triggering an EPT violation.
>>
>> This behavior works by both enabling the EPT paging-write feature and setting the EPT paging-write flag in the EPT leaf entry.
>>
>> This feature provides a significant performance boost for introspection tools that monitor guest page-table updates. Previously, every page-table modification by the guest—including routine updates like setting A/D bits—triggered an EPT violation, adding unnecessary overhead. The new XENMEM_access_r_pw permission allows these "uninteresting" updates to occur without EPT violations, improving efficiency.
>>
>> Considering that this feature provides a significant performance boost for introspection tools probably we could consider to take it to current release.
>>
>> I see that the patch series was acked-by "Acked-by: Tamas K Lengyel <tamas@tklengyel.com>" but based on the change log it is not clear when exactly
>>
>> before Feature freeze date or not. ( and I don't see any reply from Tamas ).
> I've acked the patch Thu, Dec 19, 2024.

In this case, I believe we should consider including it in the current 
release, as it was technically ready for merging before the Feature 
Freeze deadline.

I would like to kindly ask the x86 maintainers for clarification on why 
this patch series was not merged.

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Mon Jan 13 17:27:57 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Jan 2025 17:27:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870807.1281882 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXOEB-0002Y2-Fs; Mon, 13 Jan 2025 17:27:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870807.1281882; Mon, 13 Jan 2025 17:27:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXOEB-0002Xv-Cv; Mon, 13 Jan 2025 17:27:51 +0000
Received: by outflank-mailman (input) for mailman id 870807;
 Mon, 13 Jan 2025 17:27:49 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=jUGj=UF=amd.com=Stewart.Hildebrand@srs-se1.protection.inumbo.net>)
 id 1tXOE9-0002Xp-Mp
 for xen-devel@lists.xenproject.org; Mon, 13 Jan 2025 17:27:49 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20629.outbound.protection.outlook.com
 [2a01:111:f403:2418::629])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b421c815-d1d3-11ef-a0e1-8be0dac302b0;
 Mon, 13 Jan 2025 18:27:47 +0100 (CET)
Received: from MN0PR05CA0019.namprd05.prod.outlook.com (2603:10b6:208:52c::26)
 by DS7PR12MB8347.namprd12.prod.outlook.com (2603:10b6:8:e5::19) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8335.17; Mon, 13 Jan
 2025 17:27:39 +0000
Received: from BN2PEPF000055DC.namprd21.prod.outlook.com
 (2603:10b6:208:52c:cafe::49) by MN0PR05CA0019.outlook.office365.com
 (2603:10b6:208:52c::26) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8356.10 via Frontend Transport; Mon,
 13 Jan 2025 17:27:39 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN2PEPF000055DC.mail.protection.outlook.com (10.167.245.6) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8377.0 via Frontend Transport; Mon, 13 Jan 2025 17:27:39 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 13 Jan
 2025 11:27:39 -0600
Received: from [172.23.250.255] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Mon, 13 Jan 2025 11:27:37 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b421c815-d1d3-11ef-a0e1-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=SqbBmEXJy1AVnqM40pq3eXJjLqEahAvsBksAS5S19eAyHlWrH/IHPmjNUzX6xryUfBw50QmRYDwxn+bo7tmVoi++4lunrNv8aMMLF1B2zxWeZjIGZC7ab4sOFvKg0GnZENZU6fjT8e7RA17awaA7VdEcOBBkYNGU37vIQRQ6sKXX61qIro96oYNmda0Z4NAJIQMsm691CcgND19GqhSfPNRH5j0KhQsU8dgRFYLvWpwoCesubgomkyAfH6o6da+E1YBBg/lqVrtE9Y5w9Hx2Uc2uAOqNyATLC2ngiZHUq/VKl/2X4R+M/8VOaNd3MvkVk3T41ggTH+2kY6XngtaP2g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=oPF4uZoNZ80Bz21eZPEr3dPX2ojLe9SksvXBnu2Sr2E=;
 b=EBHCKZNbLE6dMNjcVla7w0MDMnKReXhHw73R/1inaPYflgGx5aj6lG4E5dbljMZ5n+X7eIaLMLGu2iMIycFahJUffogOR/9ylntSeAOWv+RB98DuYff/xuiSjgGLQ4MUcO+Ogv+4qicKHLfgRr19CZRmnE1TDSszJ1xIQIvEhFCWYWZfO5qo4+9XjK/7Vb9jEJ1SpD7Fs6TdqdQkh0dSj4YXoqvrBGlErT6oDizsM42um1MPeOQpNISOnnQo69FfR4h8JbB3u2fZ4SiGd/Dc4V/4jTwKlP1E/Cuc7KgUfNhnazpjTo98mBshhiObfJKuF++TcCP9v4fHRRyyq8BGvg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=epam.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=oPF4uZoNZ80Bz21eZPEr3dPX2ojLe9SksvXBnu2Sr2E=;
 b=n6mJZuel2Ly/MVz0yxmI9OZgIw6wfohC7m62cMVRVH1JIfMCmYbDvILeqtQE4YxeUsnUlYlPpLt1YnS42BZ5IyQPxOgps2004hdCVx221sU70j/+OB6qurGut/l6S1uQQEqLIaxG4VBsTttnZqlNeFHQSs4cEVD4uCmH5OruaXQ=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <c455dbd8-7393-46b1-b887-f3ecf5839530@amd.com>
Date: Mon, 13 Jan 2025 12:27:37 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 0/9] SMMU handling for PCIe Passthrough on ARM
To: Mykyta Poturai <Mykyta_Poturai@epam.com>, "xen-devel@lists.xenproject.org"
	<xen-devel@lists.xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
	<julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>, Michal Orzel
	<michal.orzel@amd.com>, Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>, "Jan
 Beulich" <jbeulich@suse.com>, Paul Durrant <paul@xen.org>,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, Rahul Singh
	<rahul.singh@arm.com>, Andrew Cooper <andrew.cooper3@citrix.com>, "George
 Dunlap" <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>
References: <20231109182716.367119-1-stewart.hildebrand@amd.com>
 <9b2740a0-7347-4b91-a687-1e8e4c120288@epam.com>
Content-Language: en-US
From: Stewart Hildebrand <stewart.hildebrand@amd.com>
In-Reply-To: <9b2740a0-7347-4b91-a687-1e8e4c120288@epam.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB04.amd.com: stewart.hildebrand@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN2PEPF000055DC:EE_|DS7PR12MB8347:EE_
X-MS-Office365-Filtering-Correlation-Id: 4f7ffe9a-8123-4539-9c05-08dd33f7947a
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|82310400026|1800799024|376014|7416014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?VDA3SWQ2ZEx5TkJVMlVBc2JLelJNOHpPK2o4NE5pb1VMVnF6cEt1VlgvNUky?=
 =?utf-8?B?N05tTTNrU1gxaUt0TWpwbEhXTzBvOUV5QWxmQmVlQ0NoQTluMGU5dTlzOVJU?=
 =?utf-8?B?aFA4aHpKN1JEaUlqUU96TC9BZU9oMW5ZaU03SnhSeEkrNE9NRGNaOHlyZlJz?=
 =?utf-8?B?VHpZR0pvVnF4NzQ1UitsYjhWZldHNHRSMk5UM2RNeDhGdmYya2hFUE81a1lV?=
 =?utf-8?B?MEZtOVJMVHpDbUJkUER0VDJ5TzZ3UHhhK29OdVd1OFZaNmszbzB6eVE2a25Z?=
 =?utf-8?B?V2dXZm9YMUo5RGtoUnovV0tscEUyYmJHb3FIMUE2b0MvYTQ3b0U0aW5PYllh?=
 =?utf-8?B?R295VEhxcWJTazNOdUFFdnpPYU5nM1JQNC95QlI5R2xkT0xPZ1Mza3lhWUkv?=
 =?utf-8?B?bFFaQWFHN3ZuTk5WelhmUUdWWmJOTDg2YVNDQkpBQ2NEdlphd2YyR0RmbU4y?=
 =?utf-8?B?WUNTaUpRUW5ZL2l6bTNFWTdIY0xRWHBoSmdYZU1FWW9BUE1DWmtKeERCVFhu?=
 =?utf-8?B?R2d5Sm5EYVBickdFT1BBM0N6aXFET1NkZVNSZU5SZmxhdEZxbFRxRGZYZktD?=
 =?utf-8?B?cFJzZmFWUXJKbTdGVnpqRXB3NkNXUlZYRFBZR21TUjhVMktkdGUrMzcrZExM?=
 =?utf-8?B?NUlmM2o1ems1SXBkZUp3VXBTQzR3c1h2WldVNzZUVkVROEpsSkdpWEV3Nkh4?=
 =?utf-8?B?LzI2RzNDZmo5SkhJZU5ZaVpLdFhxcytYTTNlTmdOeDI3VDhpNE1kQ2pKU3B2?=
 =?utf-8?B?TkFIZnppUW1DTjZvNHBrZG81aEFUTU1FZ3A4RWttcGZPbzFDdHpaanAxK2ZU?=
 =?utf-8?B?eU1Za0NmVTRTYU5vMnBISEpudXREN2o4eVFrWkJVbnUzREQ2bVVWUUxxR09G?=
 =?utf-8?B?WDNYQ2ZreEUyNVJXMVBhM21vQjFONmhnSVhLbEFVeHdJYXVDenpQbUhOanJS?=
 =?utf-8?B?akNPT3ZGOTI5UlRsa1ZtVHQ1RW5BVDR0K3NEeE5CWkhrVHh1d0VSR2Urb0Zq?=
 =?utf-8?B?bElyeE9pS2pIdWFSOHVuYW1OVm1vcC94RTRKbktJQWVaeEFQczBuaXlLWVUv?=
 =?utf-8?B?Z25mT2o0cHoyQU9rS2RoaDBlb2NoVmRuUkxuMGt3dXdZdjVCRmlCa0F1UTF3?=
 =?utf-8?B?ZmpEUEJGYVlBY2xCQ2Z4Z1FqREdqb3dGMzVzUkkyVjVnbVQ3RG9UeDI2bGtU?=
 =?utf-8?B?b2U0d3l3bkhrcysrY0ZtUEYvOXFCVWozU2Y1WVIxMjJYOGM1eEJ0eENDRnlh?=
 =?utf-8?B?RlBHczRJaGZ2OHlVamprdWJ1cWlxdlV3eEtMVFR1cFp6elR2alZnNmxYdWdw?=
 =?utf-8?B?UEFSWHdEMTR4Qk0yRGgxU1NTUDZBQUtqL2luWGZ4akFKamMxemgxVi8xcEtu?=
 =?utf-8?B?UCttNTlhTytyK3VLY3FyY1h2QXNTZm8xdC9qQ2dMRllvTURtNXZ3bVdSNWFw?=
 =?utf-8?B?dUhOUnl2M1lPNnBvRTF0eGFrQmRJSFlyVmFKeEV0RGZlSkwyMFhhMHlaaDY2?=
 =?utf-8?B?VDlic0tkWkxqWHQxcy95dGQ2STdRN0VBRWdBOE9CcWZwYk5CYmZiaEV5UUpL?=
 =?utf-8?B?RnBvVWRtNlEzTkVyUnVxbjhyYlN5cmlrYThFNkRBOFZMTzRpUTZvTkI3T0s3?=
 =?utf-8?B?ZGN5UUM2MTZ0eEFVeWVFdmhudlJJeTlIQlpaUzdKVlJlWmdTSnJkWk1yNnVC?=
 =?utf-8?B?aHVCejBPeEpZbUtqT2lkZmlnNXBPRUJNTktOOGFac0ZkRVB5THc5M3V6RjJr?=
 =?utf-8?B?UXVhMDhGeHJvbnZKNEEwdloyNlVMd3RMRUU3dlhmU3ZiWEY2dTdSMm5sQ2lp?=
 =?utf-8?B?WE1XZEV2eUF4eVR2UFFvK3dFWExwWDJQZ2ZYdEs5SUJ3UUlYV3pveVZQWDRh?=
 =?utf-8?B?S0dYVzNVLzlXQVVTdzhJMlBUdXBZMmt3dUVsd0dkSFpIaEcvbjQ5NXN6RGJ4?=
 =?utf-8?Q?EWAqb/cqzdg=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(82310400026)(1800799024)(376014)(7416014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2025 17:27:39.6753
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 4f7ffe9a-8123-4539-9c05-08dd33f7947a
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN2PEPF000055DC.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB8347

On 1/13/25 06:17, Mykyta Poturai wrote:
> On 09.11.23 20:27, Stewart Hildebrand wrote:
>> This series introduces SMMU handling for PCIe passthrough on ARM. These patches
>> should be able to be upstreamed independently from the vPCI series [1]. See [2]
>> for notes about test cases.
>>
>> [1] https://lists.xenproject.org/archives/html/xen-devel/2023-10/msg00660.html
>> [2] https://lists.xenproject.org/archives/html/xen-devel/2023-06/msg01135.html
>>
>> v5->v6:
>> * don't revert ("xen/arm: Add cmdline boot option "pci-passthrough = <boolean>"")
>> * add ("xen/arm: enable dom0 to use PCI devices with pci-passthrough=no")
>>
>> v4->v5:
>> * drop ("xen/arm: Improve readability of check for registered devices")
>> * drop ("xen/arm: Move is_protected flag to struct device")
>> * add ("xen/arm: don't pass iommu properties to hwdom for iommu-map")
>> * add ("xen/arm: Fix mapping for PCI bridge mmio region")
>> * revert ("xen/arm: Add cmdline boot option "pci-passthrough = <boolean>"")
>> * add ("xen/arm: Map ITS doorbell register to IOMMU page tables.")
>> * fix test case #1 with PCI device in dom0
>>
>> v3->v4:
>> * split a change from ("xen/arm: Move is_protected flag to struct device") into
>>    a new separate patch
>> * see individual patches for further details
>>
>> v2->v3:
>> * drop "pci/arm: Use iommu_add_dt_pci_device()"
>> * drop "RFC: pci/arm: don't do iommu call for phantom functions"
>> * move invocation of sideband ID mapping function to add_device()
>>    platform_ops/iommu_ops hook
>>
>> v1->v2:
>> * phantom device handling
>> * shuffle around iommu_add_dt_pci_device()
>>
>> Oleksandr Andrushchenko (1):
>>    xen/arm: smmuv2: Add PCI devices support for SMMUv2
>>
>> Oleksandr Tyshchenko (2):
>>    iommu/arm: Add iommu_dt_xlate()
>>    iommu/arm: Introduce iommu_add_dt_pci_sideband_ids API
>>
>> Rahul Singh (3):
>>    xen/arm: smmuv3: Add PCI devices support for SMMUv3
>>    xen/arm: Fix mapping for PCI bridge mmio region
>>    xen/arm: Map ITS doorbell register to IOMMU page tables
>>
>> Stewart Hildebrand (3):
>>    xen/arm: don't pass iommu properties to hwdom for iommu-map
>>    iommu/arm: iommu_add_dt_pci_sideband_ids phantom handling
>>    xen/arm: enable dom0 to use PCI devices with pci-passthrough=no
>>
>>   xen/arch/arm/device.c                 |   2 +-
>>   xen/arch/arm/domain_build.c           |   2 +
>>   xen/arch/arm/pci/pci.c                |   3 +-
>>   xen/arch/arm/vgic-v3-its.c            |  15 ++
>>   xen/common/device_tree.c              |  91 ++++++++++++
>>   xen/drivers/passthrough/arm/smmu-v3.c | 131 +++++++++++++++--
>>   xen/drivers/passthrough/arm/smmu.c    | 199 ++++++++++++++++++++++----
>>   xen/drivers/passthrough/device_tree.c |  97 ++++++++++---
>>   xen/drivers/pci/physdev.c             |   6 -
>>   xen/include/xen/device_tree.h         |  23 +++
>>   xen/include/xen/iommu.h               |  26 +++-
>>   11 files changed, 528 insertions(+), 67 deletions(-)
>>
>>
>> base-commit: bede1c7e3b790b63f1ff3ea3ee4e476b012fdf2c
> 
> Hi Stewart,
> I noticed there was no activity for this series for some time. Are you 
> still working on this or would it be okay if I take this over and start 
> preparing the V7?
> 

Hi Mykyta,

Go ahead, please feel free to take it over. Your help is very much
appreciated. I made a couple of updates, but the feedback still needs to
be addressed. Please see my latest working branch here:
https://github.com/stewdk/xen/tree/pcie-passthrough-smmu-v7


From xen-devel-bounces@lists.xenproject.org Mon Jan 13 17:53:06 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Jan 2025 17:53:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870821.1281892 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXOcV-0007kB-FD; Mon, 13 Jan 2025 17:52:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870821.1281892; Mon, 13 Jan 2025 17:52:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXOcV-0007k4-BT; Mon, 13 Jan 2025 17:52:59 +0000
Received: by outflank-mailman (input) for mailman id 870821;
 Mon, 13 Jan 2025 17:52:58 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=3HK6=UF=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tXOcU-0007jy-Dm
 for xen-devel@lists.xenproject.org; Mon, 13 Jan 2025 17:52:58 +0000
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com
 [2a00:1450:4864:20::52f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3840d789-d1d7-11ef-99a4-01e77a169b0f;
 Mon, 13 Jan 2025 18:52:56 +0100 (CET)
Received: by mail-ed1-x52f.google.com with SMTP id
 4fb4d7f45d1cf-5d7e527becaso7592931a12.3
 for <xen-devel@lists.xenproject.org>; Mon, 13 Jan 2025 09:52:56 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d9904a411csm5170354a12.72.2025.01.13.09.52.51
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 13 Jan 2025 09:52:51 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 3840d789-d1d7-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736790776; x=1737395576; 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=KWILQ3PPbyXMIG8wb7+GZY3ItNUYUX85+QnBIKw7Ryk=;
        b=vNHtgSo3qiCSD9O+76gi7RNaoEE6/aLv4Anm1/+hC6XVOneSFHtVhYDklmro5peWwl
         YvE3P83YQ2ZxGPG2cwZQ2b/rv52vRWsfz07g84MHWsezkK5az4UBUef9DYOxduvggYlB
         h56/PXEwKLZVcBDk9D71MpLY2DizjfXHhFZ1k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736790776; x=1737395576;
        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=KWILQ3PPbyXMIG8wb7+GZY3ItNUYUX85+QnBIKw7Ryk=;
        b=s7qJSEBxroFYsqzRyI8vCUAs2p981IIibndBcRhW5hdIZlXqqcHzDo+PMks4Ori4lZ
         6txWXgfYkzcOAWHZwJpHIZlEYza28bSx4S2r4dHGfre/vOdMT5Ok3ZzcYp+fRhOjBWuZ
         +G7NpSK5EGIAjoTF21QEtsys4buKQIO7LRLeF4L8wbqRJ4wkikSoIupo+FU1DMsPucpm
         ZAZ0lReVIboAmSEm7VWhk604wPdTjLm08qOr/8SzjSyu04Y5lTvxWtn3/pUmo+dbspsF
         F6hlSxTB6FRfw3USoWXGzUdLaRH+P6Xm5dcJVyHkVgDBPkVv3bzsrsGUn7lzmQkICDpM
         EWrA==
X-Gm-Message-State: AOJu0YxF1gYyUL/9E9WQSYFYcBFY4fIumFdQxrWIIQR/OB8BNQO54LqM
	CwuFz2wpYyQQZR3yitaeCeNsXUHbqtLA1mWjlm9S5J3+nAEr4rL9H2ISk+wA6vi45IMRKvVrRjt
	v
X-Gm-Gg: ASbGncvUtQsBDvVXyQsfejd/ADR5fCKBpCRJQ0zijE763u4WOTeGMq5kzLHgqOsIciU
	DMr4r0p7+f+1u1vc4zEGQ0IBKiuAEmANL1GtBTHSnlw3YScMHiLBFs/DYt0TPeWbK+PTGPt08oL
	MDWdXDaCVaziPLDtMNccxRBQ7IETwIftGdRk1N7TSE+/nIBq8no7GGfI8PtQU8q8YTqe0olflSH
	4zxibkdN3GX3YwWx2DrX0QQu1uz3DgtwGPPFyoTGhkp9fzwTV/KKTY+Tcbahw==
X-Google-Smtp-Source: AGHT+IGIXGgV6jRY+pFOx/xUR9nXrfE6XAM5tV6xrL3yUzmJSHVt5euk/9PhZORjzIJOuVir4w3Rcg==
X-Received: by 2002:a05:6402:26cf:b0:5d4:55e:f99e with SMTP id 4fb4d7f45d1cf-5d972e1d7dfmr53660568a12.18.1736790772567;
        Mon, 13 Jan 2025 09:52:52 -0800 (PST)
Date: Mon, 13 Jan 2025 18:52:51 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: xen-devel@lists.xenproject.org,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v7 1/2] x86/time: introduce command line option to select
 wallclock
Message-ID: <Z4VS88REbzn5uasy@macbook.local>
References: <20240913075907.34460-1-roger.pau@citrix.com>
 <20240913075907.34460-2-roger.pau@citrix.com>
 <Z4U6WxtmaqGkqOqe@mail-itl>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <Z4U6WxtmaqGkqOqe@mail-itl>

On Mon, Jan 13, 2025 at 05:07:55PM +0100, Marek Marczykowski-Górecki wrote:
> On Fri, Sep 13, 2024 at 09:59:06AM +0200, Roger Pau Monne wrote:
> > Allow setting the used wallclock from the command line.  When the option is set
> > to a value different than `auto` the probing is bypassed and the selected
> > implementation is used (as long as it's available).
> > 
> > The `xen` and `efi` options require being booted as a Xen guest (with Xen guest
> > supported built-in) or from UEFI firmware respectively.
> > 
> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> 
> Reviewed-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

Thanks for the review.

Oleksii, can I get your opinion as Release Manager about whether this
(and the following patch) would be suitable for committing to staging
given the current release state?

It's a workaround for broken EFI implementations that many downstreams
carry on their patch queue.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon Jan 13 18:43:03 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Jan 2025 18:43:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870835.1281901 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXPOk-0006pC-0x; Mon, 13 Jan 2025 18:42:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870835.1281901; Mon, 13 Jan 2025 18:42:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXPOj-0006p5-UI; Mon, 13 Jan 2025 18:42:49 +0000
Received: by outflank-mailman (input) for mailman id 870835;
 Mon, 13 Jan 2025 18:42: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
 <SRS0=van2=UF=bounce.vates.tech=bounce-md_30504962.67855ea4.v1-90261c6b92024aab9ae729686576b553@srs-se1.protection.inumbo.net>)
 id 1tXPOi-0006oz-Kq
 for xen-devel@lists.xenproject.org; Mon, 13 Jan 2025 18:42:48 +0000
Received: from mail178-22.suw51.mandrillapp.com
 (mail178-22.suw51.mandrillapp.com [198.2.178.22])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2dc106be-d1de-11ef-a0e1-8be0dac302b0;
 Mon, 13 Jan 2025 19:42:46 +0100 (CET)
Received: from pmta13.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail178-22.suw51.mandrillapp.com (Mailchimp) with ESMTP id
 4YX1N45FqpzGlsp1y
 for <xen-devel@lists.xenproject.org>; Mon, 13 Jan 2025 18:42:44 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 90261c6b92024aab9ae729686576b553; Mon, 13 Jan 2025 18:42:44 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2dc106be-d1de-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1736793764; x=1737054264;
	bh=wg+x7oaTzShFDXw6vWNN7FZ7vOdFvBqAnQZMBsAgMMc=;
	h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version:
	 Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From;
	b=WbmG/egTqkRPEeiavbuDYgKp2RTQQBAvZt9xS3hP3dXQVacRO8LVNCzYwjeC37WjV
	 ryQnFlfKe2UM9rrz2e8lGsTFAQyZ2yfFgyUcuWs+raY9ERp6o2PWavtEJ2CPu/lclT
	 X8NRFnFbmCVm+LsZ3Z0kFAO01uX0DISnE/JBAur7pm/kL4+prPxsWnIuQFACZbFRwf
	 M6THGHfxbpZhWQmBgxUGFFIA9NDCncnuF83sSH3yDI3gzsz7bsh2OFJ4rjLQGedqfk
	 YqPCxokQ7c9Rwr1vq316a3/8bWDVQcWbpeVzojgdJtoEFuuUPTd5QmJiam+ukvNq5i
	 Y19PQb+i055ew==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1736793764; x=1737054264; i=teddy.astie@vates.tech;
	bh=wg+x7oaTzShFDXw6vWNN7FZ7vOdFvBqAnQZMBsAgMMc=;
	h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version:
	 Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From;
	b=X2ZP00huqKE4HYHIQErcoTn1XH0/lD8de53+0JJ5T827vkYF4NWRk3+Xspd2kZepG
	 yUHIQDAUGnZHREbwq70zo45i6MKxVQSvuzBJNoISFYC49J0VHAaS2MF9Ec1oEYxAEx
	 CeWwBiY5IxW1G/chciQDGR2TJSNY1iUlOiYGwaaXIgXo7TYOFvqjP9oPglUiC8EK6M
	 eb5sjIW3fBpQHbv6Q77LYz31qEcOwTGS6xB7AxMxMs1isD8ma+niAyy92Y8zEkwCBE
	 8Y7f6KTIv/2+r4cmTzclE+rf9ypF/YpKnx6PcDA68Sx+OAdGLV0psANg71ymEsFmVP
	 uXFq+ykEY2mfQ==
From: "Teddy Astie" <teddy.astie@vates.tech>
Subject: =?utf-8?Q?[XEN=20PATCH]=20intel/msr:=20Fix=20handling=20of=20MSR=5FRAPL=5FPOWER=5FUNIT?=
X-Mailer: git-send-email 2.45.2
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1736793763637
To: xen-devel@lists.xenproject.org
Cc: "Teddy Astie" <teddy.astie@vates.tech>, "Jan Beulich" <jbeulich@suse.com>, "Andrew Cooper" <andrew.cooper3@citrix.com>, "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>
Message-Id: <0ac778dbcc7ab383447abe672225ff77b0d4802e.1736793323.git.teddy.astie@vates.tech>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.90261c6b92024aab9ae729686576b553?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250113:md
Date: Mon, 13 Jan 2025 18:42:44 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Solaris 11.4 tries to access this MSR on some Intel platforms without properly
setting up a proper #GP handler, which leads to a immediate crash.

Emulate the access of this MSR by giving it a legal value (all values set to
default, as defined by Intel SDM "RAPL Interfaces").

Fixes: 84e848fd7a1 ('x86/hvm: disallow access to unknown MSRs')
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
---
Does it have a risk of negatively affecting other operating systems expecting
this MSR read to fail ?
---
 xen/arch/x86/include/asm/msr-index.h |  2 ++
 xen/arch/x86/msr.c                   | 16 ++++++++++++++++
 2 files changed, 18 insertions(+)

diff --git a/xen/arch/x86/include/asm/msr-index.h b/xen/arch/x86/include/asm/msr-index.h
index 9cdb5b2625..2adcdf344f 100644
--- a/xen/arch/x86/include/asm/msr-index.h
+++ b/xen/arch/x86/include/asm/msr-index.h
@@ -144,6 +144,8 @@
 #define MSR_RTIT_ADDR_A(n)                 (0x00000580 + (n) * 2)
 #define MSR_RTIT_ADDR_B(n)                 (0x00000581 + (n) * 2)
 
+#define MSR_RAPL_POWER_UNIT                 0x00000606
+
 #define MSR_U_CET                           0x000006a0
 #define MSR_S_CET                           0x000006a2
 #define  CET_SHSTK_EN                       (_AC(1, ULL) <<  0)
diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
index 289cf10b78..b14d42dacf 100644
--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -169,6 +169,22 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val)
         if ( likely(!is_cpufreq_controller(d)) || rdmsr_safe(msr, *val) == 0 )
             break;
         goto gp_fault;
+    
+        /*
+         * Solaris 11.4 DomU tries to use read this MSR without setting up a
+         * proper #GP handler leading to a crash. Emulate this MSR by giving a
+         * legal value.
+         */
+    case MSR_RAPL_POWER_UNIT:
+        if ( !(cp->x86_vendor & (X86_VENDOR_INTEL | X86_VENDOR_CENTAUR)) )
+            goto gp_fault;
+
+        /*
+         * Return a legal register content with all default values defined in
+         * Intel Architecture Software Developer Manual 16.10.1 RAPL Interfaces
+         */
+        *val = 0x0000A1003;
+        break;
 
     case MSR_IA32_THERM_STATUS:
         if ( cp->x86_vendor != X86_VENDOR_INTEL )
-- 
2.45.2



Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


From xen-devel-bounces@lists.xenproject.org Mon Jan 13 23:29:52 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Jan 2025 23:29:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870858.1281920 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXTsD-0005Ob-Ig; Mon, 13 Jan 2025 23:29:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870858.1281920; Mon, 13 Jan 2025 23:29:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXTsD-0005OU-ER; Mon, 13 Jan 2025 23:29:33 +0000
Received: by outflank-mailman (input) for mailman id 870858;
 Mon, 13 Jan 2025 23:29:32 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=09kq=UF=kernel.org=helgaas@srs-se1.protection.inumbo.net>)
 id 1tXTsC-0005OO-DN
 for xen-devel@lists.xenproject.org; Mon, 13 Jan 2025 23:29:32 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3c12fd26-d206-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 00:29:30 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 33E04A40169;
 Mon, 13 Jan 2025 23:27:40 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id E4AB5C4CEE2;
 Mon, 13 Jan 2025 23:29:27 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 3c12fd26-d206-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1736810968;
	bh=AYgvKjxUUMQocZwtApGtSj7HO+lGgOyrLK+q7G5z7Fs=;
	h=Date:From:To:Cc:Subject:In-Reply-To:From;
	b=Y1KfpmFD1JgQ52ESL70pewXErRFdGFRomAb+pZFVELWj2LfL9Msq/2+bDJM/YLNFZ
	 BU62SVewks/Oi1WbmzmMHGXpsiCJK08ishrNbJeBiWJeGV+GhTtWdVWCtkB95SwKau
	 qtamJHT0B79ISmPKJSSi/kTgTNcB9bnqX2ojMa9xAuT+31s0Z/41VJ9BZq4G3CU1tb
	 hsGeIbhrK3YJJpo9SjhvzJ7EmlcnbLVRwLhVxVEy/sTdBD8PuoDYaxKIUjH7YCQHtc
	 8/51xEwNPZgI8cXIA5l6dHTNShxGCjYtuH2tnDo8nlQJUxq54kdFbEzz0CyZ4GHSz9
	 1J8ZNfHF02kqQ==
Date: Mon, 13 Jan 2025 17:29:26 -0600
From: Bjorn Helgaas <helgaas@kernel.org>
To: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
	Juergen Gross <jgross@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Subject: Re: [PATCH 1/3] xen/pci: do not register devices outside of PCI
 segment scope
Message-ID: <20250113232926.GA442589@bhelgaas>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <Z4TokbA1s3OyNdjt@macbook.local>

On Mon, Jan 13, 2025 at 11:18:57AM +0100, Roger Pau Monné wrote:
> On Fri, Jan 10, 2025 at 04:21:29PM -0600, Bjorn Helgaas wrote:
> > On Fri, Jan 10, 2025 at 03:01:48PM +0100, Roger Pau Monne wrote:
> > > The PCI segment value is limited to 16 bits, however there are buses like VMD
> > > that fake being part of the PCI topology by adding segment with a number
> > > outside the scope of the PCI firmware specification range (>= 0x10000). The
> > > MCFG ACPI Table "PCI Segment Group Number" field is defined as having a 16 bit
> > > width.
> > >
> > > Attempting to register or manage those devices with Xen would result in errors
> > > at best, or overlaps with existing devices living on the truncated equivalent
> > > segment values.
> > 
> > The ACPI _SEG method (ACPI r6.5, sec 6.5.6) and the corresponding
> > value in the MCFG table (PCI Firmware r3.3, sec 4.1.2) are clearly
> > 16-bit values.
> > 
> > But otherwise, the segment value is pretty much an arbitrary software
> > value, and the kernel works fine with the larger domain values from
> > vmd_find_free_domain(), so this isn't quite enough to explain what the
> > issue with Xen is.
> > 
> > Does Xen truncate the domain to 16 bits or use it to look up something
> > in ACPI?
> 
> In the interface between Xen and Linux the segment field is 16 bit
> width, so with the current interface is not possible to reference
> devices that are past the 0xffff segment.

I think this specific reason (and maybe even struct
physdev_pci_device_add) would be more useful than the ACPI _SEG and
MCFG things, which are not as directly connected here.

Bjorn


From xen-devel-bounces@lists.xenproject.org Mon Jan 13 23:32:53 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Jan 2025 23:32:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870867.1281930 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXTvP-0006vg-V2; Mon, 13 Jan 2025 23:32:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870867.1281930; Mon, 13 Jan 2025 23:32:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXTvP-0006vZ-SF; Mon, 13 Jan 2025 23:32:51 +0000
Received: by outflank-mailman (input) for mailman id 870867;
 Mon, 13 Jan 2025 23:32: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
 <SRS0=09kq=UF=kernel.org=helgaas@srs-se1.protection.inumbo.net>)
 id 1tXTvO-0006vT-6Y
 for xen-devel@lists.xenproject.org; Mon, 13 Jan 2025 23:32:50 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b28afc11-d206-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 00:32:48 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 52B65A40169;
 Mon, 13 Jan 2025 23:30:59 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0C17EC4CEE2;
 Mon, 13 Jan 2025 23:32:46 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b28afc11-d206-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1736811167;
	bh=1jVk4ltA+d5ZhbhdluLbuAMr/zaGiphdqtr5ZLs8t80=;
	h=Date:From:To:Cc:Subject:In-Reply-To:From;
	b=TMQ6G17PrTp0lhrwJTgK+sdfXTdzsz+wfrbAbfgMGesgsasW1zc885f77VJ8+CU8c
	 S9E7OikwGIKzXcUdHMj9jMWX5IQHbT+cxfBWIIopte/FKrEC2DsUogjt+p0QkuuBGQ
	 SIsp30jOpVhwCJiOjipxrUOYFVp4ChIp/PqWLvwwKCUwaf5lf8+RSDfKQ/xexWNoVe
	 LzjU0DTDEI5w+cEbrPDn8VQrM1ouY7m3xkueE0O/YV4uEudlv8UbtMY099seZ4ySLs
	 sg5VmCl8jju91f/jCHRLbT2twapA+WejGgDRWZFiprXnOJznMfPjjwwCvDSUZEDTsh
	 NhnaB1VtjAa6w==
Date: Mon, 13 Jan 2025 17:32:45 -0600
From: Bjorn Helgaas <helgaas@kernel.org>
To: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
	linux-pci@vger.kernel.org, Juergen Gross <jgross@suse.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH 3/3] pci/msi: remove pci_msi_ignore_mask
Message-ID: <20250113233245.GA442694@bhelgaas>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <Z4TqNn_RSwGX1TQn@macbook.local>

On Mon, Jan 13, 2025 at 11:25:58AM +0100, Roger Pau Monné wrote:
> On Fri, Jan 10, 2025 at 04:30:57PM -0600, Bjorn Helgaas wrote:
> > On Fri, Jan 10, 2025 at 03:01:50PM +0100, Roger Pau Monne wrote:
> > > Setting pci_msi_ignore_mask inhibits the toggling of the mask bit for both MSI
> > > and MSI-X entries globally, regardless of the IRQ chip they are using.  Only
> > > Xen sets the pci_msi_ignore_mask when routing physical interrupts over event
> > > channels, to prevent PCI code from attempting to toggle the maskbit, as it's
> > > Xen that controls the bit.
> > > 
> > > However, the pci_msi_ignore_mask being global will affect devices that use MSI
> > > interrupts but are not routing those interrupts over event channels (not using
> > > the Xen pIRQ chip).  One example is devices behind a VMD PCI bridge.  In that
> > > scenario the VMD bridge configures MSI(-X) using the normal IRQ chip (the pIRQ
> > > one in the Xen case), and devices behind the bridge configure the MSI entries
> > > using indexes into the VMD bridge MSI table.  The VMD bridge then demultiplexes
> > > such interrupts and delivers to the destination device(s).  Having
> > > pci_msi_ignore_mask set in that scenario prevents (un)masking of MSI entries
> > > for devices behind the VMD bridge.
> > > 
> > > Move the signaling of no entry masking into the MSI domain flags, as that
> > > allows setting it on a per-domain basis.  Set it for the Xen MSI domain that
> > > uses the pIRQ chip, while leaving it unset for the rest of the cases.
> > > 
> > > Remove pci_msi_ignore_mask at once, since it was only used by Xen code, and
> > > with Xen dropping usage the variable is unneeded.
> > > 
> > > This fixes using devices behind a VMD bridge on Xen PV hardware domains.
> > 
> > Wrap to fit in 75 columns.
> > 
> > The first two patches talk about devices behind VMD not being usable
> > for Xen, but this one says they now work.
> 
> Sorry, let me try to clarify:
> 
> Devices behind a VMD bridge are not known to Xen, however that doesn't
> mean Linux cannot use them.  That's what this series achieves.  By
> inhibiting the usage of VMD_FEAT_CAN_BYPASS_MSI_REMAP and the removal
> of the pci_msi_ignore_mask bodge devices behind a VMD bridge do work
> fine when use from a Linux Xen hardware domain.  That's the whole
> point of the series.
> 
> > But this doesn't undo the
> > code changes or comments added by the first two, so the result is a
> > bit confusing (probably because I know nothing about Xen).
> 
> All patches are needed.  There's probably some confusion about devices
> behind a VMD bridge not being known by Xen vs not being usable by
> Linux running under Xen as a hardware domain.
> 
> With all three patches applied devices behind a VMD bridge work under
> Linux with Xen.

There's certainly confusion in *my* mind because I don't know enough
about Xen to understand the subtlety about devices behind VMD not
being known by Xen but still being usable by Linux running under Xen.

Bjorn


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 03:28:15 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 03:28:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870886.1281940 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXXax-0008Nd-40; Tue, 14 Jan 2025 03:27:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870886.1281940; Tue, 14 Jan 2025 03:27:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXXaw-0008NN-Us; Tue, 14 Jan 2025 03:27:58 +0000
Received: by outflank-mailman (input) for mailman id 870886;
 Tue, 14 Jan 2025 03:27:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=JML1=UG=amd.com=Jiqian.Chen@srs-se1.protection.inumbo.net>)
 id 1tXXau-0008NG-Pl
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 03:27:56 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20630.outbound.protection.outlook.com
 [2a01:111:f403:2009::630])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 89287d56-d227-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 04:27:53 +0100 (CET)
Received: from DS7PR07CA0017.namprd07.prod.outlook.com (2603:10b6:5:3af::14)
 by SN7PR12MB7833.namprd12.prod.outlook.com (2603:10b6:806:344::15) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8335.18; Tue, 14 Jan
 2025 03:27:47 +0000
Received: from CY4PEPF0000FCC2.namprd03.prod.outlook.com
 (2603:10b6:5:3af:cafe::22) by DS7PR07CA0017.outlook.office365.com
 (2603:10b6:5:3af::14) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8335.18 via Frontend Transport; Tue,
 14 Jan 2025 03:27:47 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CY4PEPF0000FCC2.mail.protection.outlook.com (10.167.242.104) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8356.11 via Frontend Transport; Tue, 14 Jan 2025 03:27:46 +0000
Received: from cjq-desktop.amd.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 13 Jan
 2025 21:27:20 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 89287d56-d227-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=VEunC8hn4UwtJzMF9A+8vf/fw4t1OK2JFzhv+ZnFxqicdAzDlSnabZ1Btd+eV1uQLga7893Z7ZcQyMRtXiSuq48Wsc1ZDqZCtnrspvEQnNEy4FNcMrKN8tWTAojgnMV/gOv9rPFarXrSM8qCNg16NKYSaueYv7M8IbI3LIp+C5AbZPumNcUlFhK9fs1uPIGWivNUslcBo7c4nlETyB8o9nZWhuZBOIFTIzXUvISwg2ReljPzcYhrVzbL0ThxRfsPPBBplNABibTqPHwYmqD25z4dEXrib/ROvTQov9yU6WkuhdX7GVJLHoKIgBIxTopWsIHF6GcaC2dJqmb8XA/1ww==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=wX7U8GBnJ8PWa3EmFKKGSuSYosnVk0lX9NFIkR5hmWM=;
 b=Gtw9YfILFAWZGtMXVhJ+sBzJTJHPTxPLtdNLYiojchzg5M9A9UXwQ5G/WJ+v5IyZD0BGxHxRBDmmkzERrfT9rKV3TTC58c2XsNFxbtt2JjzbEDrl/SKibSvlsDB+99/wpAq7Wsr6FWmxKqvPX4NCstDRaqQy4fMPHeeo1SuhhMKtDxVPYClZn5fKbKkZiMBQnEKLKZ+p4HOsGw+vN4pZnIfiDwS+pIIXx9JpG0jZAS9j3XRUjUK9YaOydZNEJsvPHqla5//3EXlJO6RjSwra3CDnPHq+CalgSJ9BcmLSGmzYWNAjLL6S+sa20sZ2cPtVad9ZQ/zPpu5hZCOBrNbxCg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=wX7U8GBnJ8PWa3EmFKKGSuSYosnVk0lX9NFIkR5hmWM=;
 b=q5BjBU9kS/P6DNx8NpHIM1RZmN2iuxZ8PfmMIFQqKjLBOlSSMJNCZjKPBTgnuBizD7qi3s3CY1fN5Nvq1fwS5bHxj7y4oD9PMra6PIld2y+ZvtMipyvycTCxmHWPAb0+ewp/6G4tdlO5oEMMYiPw5RhFpGuQSiWlcA+JYSraB3s=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jiqian Chen <Jiqian.Chen@amd.com>
To: <xen-devel@lists.xenproject.org>
CC: =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>, Andrew Cooper
	<andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>, Julien Grall
	<julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>, Huang Rui
	<ray.huang@amd.com>, Jiqian Chen <Jiqian.Chen@amd.com>
Subject: [PATCH v5] vpci: Add resizable bar support
Date: Tue, 14 Jan 2025 11:26:36 +0800
Message-ID: <20250114032636.3698383-1-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000FCC2:EE_|SN7PR12MB7833:EE_
X-MS-Office365-Filtering-Correlation-Id: c371b143-a06c-49cb-c6d9-08dd344b6a91
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|82310400026|376014|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?xSBtDakRvHSHXqYHqCh70jVR8DNSrU+q+DSh3QOQuZVOPeovtFFFNztFCmdF?=
 =?us-ascii?Q?tFK2jCNuq4DyDYJLdUP83gcQgvyEv2dTXCGFLBzkbjy+yWXu9hA8AQM10kD6?=
 =?us-ascii?Q?S996Q7C0w0rTeJY+eBB/TtrrOiWqohwNYerqQlk2o7UNe7bV5NUoEGmu+EBo?=
 =?us-ascii?Q?jvsR1cdLHMfrkvBTPN6uRq1zSFJvrBFpSPotgYC90M5sWiVbxhMC/qfZ47vb?=
 =?us-ascii?Q?CCWiiHICr9Wf74IBD/6hpw49mHe0WbcPhQYqrvdtHPcXV1aojQ5iQ4TJGUf3?=
 =?us-ascii?Q?qtSLfgrydMcw7oa9sBBHOXHRKZ6Qg1U/9XvLH1uqvlppgI91xDQtX6SiZJDi?=
 =?us-ascii?Q?t2zJMjGAgIKlTHTBcO4MAfo3U5aDmGV8whGS3mvL9XXNY6sq1E0T/djyijtZ?=
 =?us-ascii?Q?5XdLWFbQ8Va2htxJLBmaPU+GMrwTMDyjMn5Mb0k5zu+VG5SJuyf1spm9Ozvm?=
 =?us-ascii?Q?Eujb+GdMdpWRqdYbiTZ+1NKp0wZxQ1LCvnHoqId025XHDxc8z9TleFDutuuG?=
 =?us-ascii?Q?/P9Nhe3zw1GBBw923IW5UmUVq/GBIouJ7U8nkypFEypX+11IKYXPuAbavA3x?=
 =?us-ascii?Q?skQbAWjA8U5VLVjaDdkNxsVVH+byNdrqiDUaLW7HLVvyhmWDwkflU9stAnRh?=
 =?us-ascii?Q?tcBRpmHkZYLXTWhXnYkfPVZrkwfHtWy09qVbuhdLiz6AeVPWxtWd5iIknvqY?=
 =?us-ascii?Q?Vv4gZ3YmTLmxfwHXAKZ3gbugmPtuqfYg6xHTRcfUjQ5+73B7sy0FEYjF0C50?=
 =?us-ascii?Q?KdylcKNDNAni1TzzoRPdM+CPFGJFNc9eu5ge7oig5wFN4GXBzP5TYxTUv0g3?=
 =?us-ascii?Q?qWiONb9RQl37xD3/0hFSGqeh3ryLF229IjMNTvSYx2kG+aI/64FxC4RklGJq?=
 =?us-ascii?Q?0NRWRyXWQySAXoqkDeiGd8qCX0K2ffwxZxWDYAZTYvCf73+cEz3kliN4db3n?=
 =?us-ascii?Q?Z7xlGAlzpKiK+aspApisr48HlGITHL8oGa+VqXh1cjaxXpE6i+N7O8y1MMyL?=
 =?us-ascii?Q?dkx2UiY061MTkfZqZ0iJ4kp2ztKA0taVSvNjXpu42QGjtU2cJmVPr7nf4KAV?=
 =?us-ascii?Q?qsjJ09dEdSDM/mBpEUq2jeM1X64qcoJW6xtrRLX0+5xm9eLSiuFnqfPtCT/7?=
 =?us-ascii?Q?uhBNIgrQ16IlXHTV5f/bUM3l9Z/7rplbdrpu/CeX7ups/i7IQsU5h6Dk2+Tr?=
 =?us-ascii?Q?hoLiHGHhekN5xmuSZTyqSrHRxSO3dl0LFZHl82ATn74chqpSTtjjO4bGcfyT?=
 =?us-ascii?Q?hF8lblV3TveFf2OWP3BRJXGrwAP5bMjtip5prGwvOMPZ1f2PmikeQZLWRNe4?=
 =?us-ascii?Q?e4U8Ifxv/aCHtOnpzNmznwNX5kxKjVvf9lTh8w/x5FwU2e27U4D294Gykoux?=
 =?us-ascii?Q?AYhGit3FXFEOSGtt5vytVeQIrFQv+f4uwpRdZGNroPbDy+g1qR3vRL207j+E?=
 =?us-ascii?Q?olB6iagcZPFsDXZ6gv/teVfuCOxsoWQQuttXPRHIz5ypu8keIzEGP87IZDvT?=
 =?us-ascii?Q?IpDBuaiCFnCi3B8=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(82310400026)(376014)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jan 2025 03:27:46.9733
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c371b143-a06c-49cb-c6d9-08dd344b6a91
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CY4PEPF0000FCC2.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB7833

Some devices, like discrete GPU of amd, support resizable bar
capability, but vpci of Xen doesn't support this feature, so
they fail to resize bars and then cause probing failure.

According to PCIe spec, each bar that supports resizing has
two registers, PCI_REBAR_CAP and PCI_REBAR_CTRL. So, add
handlers for them to support resizing the size of BARs.

Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com>
---
Hi all,
v4->v5 changes:
* Called pci_size_mem_bar in rebar_ctrl_write to get addr and size of BAR instead of setting
  their values directly after writing new size to hardware.
* Changed from "return" to "continue" when index/type of BAR are not correct during initializing
  BAR.
* Corrected the value of PCI_REBAR_CTRL_BAR_SIZE from "0x00001F00" to "0x00003F00".
* Renamed PCI_REBAR_SIZE_BIAS to PCI_REBAR_CTRL_SIZE_BIAS.
* Re-defined "PCI_REBAR_CAP_SHIFT 4" to "PCI_REBAR_CAP_SIZES_MASK 0xFFFFFFF0U".

Best regards,
Jiqian Chen.

v3->v4 changes:
* Removed PCI_REBAR_CAP_SIZES since it was not needed, and added
  PCI_REBAR_CAP_SHIFT and PCI_REBAR_CTRL_SIZES.
* Added parameter resizable_sizes to struct vpci_bar to cache the support resizable sizes and
  added the logic in init_rebar().
* Changed PCI_REBAR_CAP to PCI_REBAR_CAP(n) (4+8*(n)), changed PCI_REBAR_CTRL to
  PCI_REBAR_CTRL(n) (8+8*(n)).
* Added domain info of pci_dev to printings of init_rebar().

v2->v3 changes:
* Used "bar->enabled" to replace "pci_conf_read16(pdev->sbdf, PCI_COMMAND) & PCI_COMMAND_MEMORY",
  and added comments why it needs this check.
* Added "!is_hardware_domain(pdev->domain)" check in init_rebar() to return EOPNOTSUPP for domUs.
* Moved BAR type and index check into init_rebar(), then only need to check once.
* Added 'U' suffix for macro PCI_REBAR_CAP_SIZES.
* Added macro PCI_REBAR_SIZE_BIAS to represent 20.
TODO: need to hide ReBar capability from hardware domain when init_rebar() fails.

v1->v2 changes:
* In rebar_ctrl_write, to check if memory decoding is enabled, and added
  some checks for the type of Bar.
* Added vpci_hw_write32 to handle PCI_REBAR_CAP's write, since there is
  no write limitation of dom0.
* And has many other minor modifications as well.
---
 xen/drivers/vpci/Makefile  |   2 +-
 xen/drivers/vpci/rebar.c   | 135 +++++++++++++++++++++++++++++++++++++
 xen/drivers/vpci/vpci.c    |   6 ++
 xen/include/xen/pci_regs.h |  14 ++++
 xen/include/xen/vpci.h     |   3 +
 5 files changed, 159 insertions(+), 1 deletion(-)
 create mode 100644 xen/drivers/vpci/rebar.c

diff --git a/xen/drivers/vpci/Makefile b/xen/drivers/vpci/Makefile
index 1a1413b93e76..a7c8a30a8956 100644
--- a/xen/drivers/vpci/Makefile
+++ b/xen/drivers/vpci/Makefile
@@ -1,2 +1,2 @@
-obj-y += vpci.o header.o
+obj-y += vpci.o header.o rebar.o
 obj-$(CONFIG_HAS_PCI_MSI) += msi.o msix.o
diff --git a/xen/drivers/vpci/rebar.c b/xen/drivers/vpci/rebar.c
new file mode 100644
index 000000000000..ed22a75e16fd
--- /dev/null
+++ b/xen/drivers/vpci/rebar.c
@@ -0,0 +1,135 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2024 Advanced Micro Devices, Inc. All Rights Reserved.
+ *
+ * Author: Jiqian Chen <Jiqian.Chen@amd.com>
+ */
+
+#include <xen/sched.h>
+#include <xen/vpci.h>
+
+static void cf_check rebar_ctrl_write(const struct pci_dev *pdev,
+                                      unsigned int reg,
+                                      uint32_t val,
+                                      void *data)
+{
+    unsigned int index;
+    struct vpci_bar *bar = data;
+    uint64_t size = PCI_REBAR_CTRL_SIZE(val);
+
+    if ( bar->enabled )
+    {
+        /*
+         * Refuse to resize a BAR while memory decoding is enabled, as
+         * otherwise the size of the mapped region in the p2m would become
+         * stale with the newly set BAR size, and the position of the BAR
+         * would be reset to undefined.  Note the PCIe specification also
+         * forbids resizing a BAR with memory decoding enabled.
+         */
+        if ( size != bar->size )
+            gprintk(XENLOG_ERR,
+                    "%pp: refuse to resize BAR with memory decoding enabled\n",
+                    &pdev->sbdf);
+        return;
+    }
+
+    if ( !((size >> PCI_REBAR_CTRL_SIZE_BIAS) & bar->resizable_sizes) )
+        gprintk(XENLOG_WARNING,
+                "%pp: new size %#lx is not supported by hardware\n",
+                &pdev->sbdf, size);
+
+    pci_conf_write32(pdev->sbdf, reg, val);
+
+    index = pci_conf_read32(pdev->sbdf, reg) & PCI_REBAR_CTRL_BAR_IDX;
+    pci_size_mem_bar(pdev->sbdf, PCI_BASE_ADDRESS_0 + index * 4, &bar->addr,
+                     &bar->size, ((index == PCI_HEADER_NORMAL_NR_BARS - 1) ?
+                                  PCI_BAR_LAST : 0));
+    bar->guest_addr = bar->addr;
+}
+
+static int cf_check init_rebar(struct pci_dev *pdev)
+{
+    uint32_t ctrl;
+    unsigned int nbars;
+    unsigned int rebar_offset = pci_find_ext_capability(pdev->sbdf,
+                                                        PCI_EXT_CAP_ID_REBAR);
+
+    if ( !rebar_offset )
+        return 0;
+
+    if ( !is_hardware_domain(pdev->domain) )
+    {
+        printk(XENLOG_ERR "%pp: resizable BARs unsupported for unpriv %pd\n",
+               &pdev->sbdf, pdev->domain);
+        return -EOPNOTSUPP;
+    }
+
+    ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL(0));
+    nbars = MASK_EXTR(ctrl, PCI_REBAR_CTRL_NBAR_MASK);
+    for ( unsigned int i = 0; i < nbars; i++ )
+    {
+        int rc;
+        struct vpci_bar *bar;
+        unsigned int index;
+
+        ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL(i));
+        index = ctrl & PCI_REBAR_CTRL_BAR_IDX;
+        if ( index >= PCI_HEADER_NORMAL_NR_BARS )
+        {
+            printk(XENLOG_ERR "%pd %pp: too big BAR number %u in REBAR_CTRL\n",
+                   pdev->domain, &pdev->sbdf, index);
+            continue;
+        }
+
+        bar = &pdev->vpci->header.bars[index];
+        if ( bar->type != VPCI_BAR_MEM64_LO && bar->type != VPCI_BAR_MEM32 )
+        {
+            printk(XENLOG_ERR "%pd %pp: BAR%u is not in memory space\n",
+                   pdev->domain, &pdev->sbdf, index);
+            continue;
+        }
+
+        rc = vpci_add_register(pdev->vpci, vpci_hw_read32, vpci_hw_write32,
+                               rebar_offset + PCI_REBAR_CAP(i), 4, NULL);
+        if ( rc )
+        {
+            /*
+             * TODO: for failed pathes, need to hide ReBar capability
+             * from hardware domain instead of returning an error.
+             */
+            printk(XENLOG_ERR "%pd %pp: fail to add reg of REBAR_CAP rc=%d\n",
+                   pdev->domain, &pdev->sbdf, rc);
+            return rc;
+        }
+
+        rc = vpci_add_register(pdev->vpci, vpci_hw_read32, rebar_ctrl_write,
+                               rebar_offset + PCI_REBAR_CTRL(i), 4, bar);
+        if ( rc )
+        {
+            printk(XENLOG_ERR "%pd %pp: fail to add reg of REBAR_CTRL rc=%d\n",
+                   pdev->domain, &pdev->sbdf, rc);
+            return rc;
+        }
+
+        bar->resizable_sizes =
+            MASK_EXTR(pci_conf_read32(pdev->sbdf,
+                                      rebar_offset + PCI_REBAR_CAP(i)),
+                      PCI_REBAR_CAP_SIZES_MASK);
+        bar->resizable_sizes |=
+            (((uint64_t)MASK_EXTR(ctrl, PCI_REBAR_CTRL_SIZES_MASK) << 32) /
+             ISOLATE_LSB(PCI_REBAR_CAP_SIZES_MASK));
+    }
+
+    return 0;
+}
+REGISTER_VPCI_INIT(init_rebar, VPCI_PRIORITY_LOW);
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
index 1e6aa5d799b9..3349b98389b8 100644
--- a/xen/drivers/vpci/vpci.c
+++ b/xen/drivers/vpci/vpci.c
@@ -232,6 +232,12 @@ void cf_check vpci_hw_write16(
     pci_conf_write16(pdev->sbdf, reg, val);
 }
 
+void cf_check vpci_hw_write32(
+    const struct pci_dev *pdev, unsigned int reg, uint32_t val, void *data)
+{
+    pci_conf_write32(pdev->sbdf, reg, val);
+}
+
 int vpci_add_register_mask(struct vpci *vpci, vpci_read_t *read_handler,
                            vpci_write_t *write_handler, unsigned int offset,
                            unsigned int size, void *data, uint32_t ro_mask,
diff --git a/xen/include/xen/pci_regs.h b/xen/include/xen/pci_regs.h
index 250ba106dbd3..65d77624fc73 100644
--- a/xen/include/xen/pci_regs.h
+++ b/xen/include/xen/pci_regs.h
@@ -459,6 +459,7 @@
 #define PCI_EXT_CAP_ID_ARI	14
 #define PCI_EXT_CAP_ID_ATS	15
 #define PCI_EXT_CAP_ID_SRIOV	16
+#define PCI_EXT_CAP_ID_REBAR	21	/* Resizable BAR */
 
 /* Advanced Error Reporting */
 #define PCI_ERR_UNCOR_STATUS	4	/* Uncorrectable Error Status */
@@ -541,6 +542,19 @@
 #define  PCI_VNDR_HEADER_REV(x)	(((x) >> 16) & 0xf)
 #define  PCI_VNDR_HEADER_LEN(x)	(((x) >> 20) & 0xfff)
 
+/* Resizable BARs */
+#define PCI_REBAR_CAP(n)	(4 + 8 * (n))	/* capability register */
+#define  PCI_REBAR_CAP_SIZES_MASK	0xFFFFFFF0U	/* supported BAR sizes in CAP */
+#define PCI_REBAR_CTRL(n)	(8 + 8 * (n))	/* control register */
+#define  PCI_REBAR_CTRL_BAR_IDX		0x00000007	/* BAR index */
+#define  PCI_REBAR_CTRL_NBAR_MASK	0x000000E0	/* # of resizable BARs */
+#define  PCI_REBAR_CTRL_BAR_SIZE	0x00003F00	/* BAR size */
+#define  PCI_REBAR_CTRL_SIZES_MASK	0xFFFF0000U	/* supported BAR sizes in CTRL */
+#define  PCI_REBAR_CTRL_SIZE_BIAS	20
+#define  PCI_REBAR_CTRL_SIZE(v) \
+            (1UL << (MASK_EXTR(v, PCI_REBAR_CTRL_BAR_SIZE) \
+                     + PCI_REBAR_CTRL_SIZE_BIAS))
+
 /*
  * Hypertransport sub capability types
  *
diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h
index 41e7c3bc2791..9d47b8c1a50e 100644
--- a/xen/include/xen/vpci.h
+++ b/xen/include/xen/vpci.h
@@ -78,6 +78,8 @@ uint32_t cf_check vpci_hw_read32(
     const struct pci_dev *pdev, unsigned int reg, void *data);
 void cf_check vpci_hw_write16(
     const struct pci_dev *pdev, unsigned int reg, uint32_t val, void *data);
+void cf_check vpci_hw_write32(
+    const struct pci_dev *pdev, unsigned int reg, uint32_t val, void *data);
 
 /*
  * Check for pending vPCI operations on this vcpu. Returns true if the vcpu
@@ -100,6 +102,7 @@ struct vpci {
             /* Guest address. */
             uint64_t guest_addr;
             uint64_t size;
+            uint64_t resizable_sizes;
             struct rangeset *mem;
             enum {
                 VPCI_BAR_EMPTY,
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 04:26:17 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 04:26:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870902.1281970 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXYVH-0007vp-T0; Tue, 14 Jan 2025 04:26:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870902.1281970; Tue, 14 Jan 2025 04:26:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXYVH-0007vf-PC; Tue, 14 Jan 2025 04:26:11 +0000
Received: by outflank-mailman (input) for mailman id 870902;
 Tue, 14 Jan 2025 04:26: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
 <SRS0=sZa5=UG=epam.com=Volodymyr_Babchuk@srs-se1.protection.inumbo.net>)
 id 1tXYVG-0007T1-8n
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 04:26:10 +0000
Received: from EUR03-AM7-obe.outbound.protection.outlook.com
 (mail-am7eur03on20612.outbound.protection.outlook.com
 [2a01:111:f403:260e::612])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ad7bc3b5-d22f-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 05:26:08 +0100 (CET)
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 (2603:10a6:150:16a::21) by DB8PR03MB6300.eurprd03.prod.outlook.com
 (2603:10a6:10:13f::13) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8356.12; Tue, 14 Jan
 2025 04:25:55 +0000
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e]) by GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e%3]) with mapi id 15.20.8335.015; Tue, 14 Jan 2025
 04:25:55 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ad7bc3b5-d22f-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=fCP3yA6RQOZYd19qQA5DtwPrQ4XZP/OI+bYfOMOJlJaIP6XqeGqeFxRmz/vte+zDF4BsWI+QHZ6mBU0nbjUlbvopZlEXnEosnCrO0ugLUaiZV+B00X2R1PPu4iEI0O0DPCZOLgOAoiHANBeV6t4aWcKgGsT1z5a6Mf2+NZ6/aCruajnbT/utTUxsCw5w5Q9JX9PpU1shrA4jQcAoPAxFbtnyGxnR6732aYgBmtweMtaAFJ9bIxL7g/K4F3YI710RcQPI4TwhRq/PhBefffDuvOOfW1XqZQ1u+8POsUVtwRhf7NqGWoyHftzrWivqFDEPVYbqb2uocBwUYl5Ltzi6gw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=a0nv7W8vVhr0JkTF84nve4JbMYGweEVnfzqPpaJwAmg=;
 b=xbuowyeRzTedra9cx1Sa7+YNMp3Kx9DZLXzZla7KK+dX8hMlNDBeecQ6qgHAfbDASw9dWwnWCfxZLnL7uu0aktbk3lbNtqrNPXG0mBkW69pz85yGutvtQ8vm2GAgb/wkBPZQJ88lKnhl5U2LuMbqf+qPkk+BwiFi8+r81Z2fvNjXfewjZtull3fYGReuc2Eit4JVH/BEqv/QcTm+sz/TZy3oja0IModRhGJ0by5/B/gZqogTpGIISDYMEcFJf0J3OqOe+3xCmG9hwbeBtumGeXegXr8K7p0n+OWzwcC/2B/F0/RB5R/rrXbWhSv3Ue0jgWomMDqiHpr5OsnF1v9Z3w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=a0nv7W8vVhr0JkTF84nve4JbMYGweEVnfzqPpaJwAmg=;
 b=QXw5SkjuIeISF0CFCghjMlzH+R/m2yjTv2yG322fr11BEsFM8mfsiQYotH7gXeQeEKfuOZcPaQE0zH+Zrv1BndbGLbt0IyIadRVC20n+2DbXx6KtnwXmUNQK0KLrC5V9fQ4b3Nfc2d9VFUgxKkgB+6pExBU8V+C32MyqIlxZzkWFHf4oHlxo9lSHSd/4QgYmyKwwtkc1XRxo4ZYWK0viO39VK6yGYWL+R1dETmeerQ49V18eB3uir0V5tdb7G8J4p4+gRyfTgo6Y/u7WEZURYH25fHL406uocWVCzOFPLQYGpPeZfuHWKs5DT3b2tioDd1XezoCq473I9/52ALblnw==
From: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
CC: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>, Andrew Cooper
	<andrew.cooper3@citrix.com>, Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>, Julien
 Grall <julien@xen.org>, =?iso-8859-1?Q?Roger_Pau_Monn=E9?=
	<roger.pau@citrix.com>, Stefano Stabellini <sstabellini@kernel.org>, Samuel
 Thibault <samuel.thibault@ens-lyon.org>, Bertrand Marquis
	<bertrand.marquis@arm.com>, Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>, Community Manager
	<community.manager@xenproject.org>
Subject: [PATCH v4 0/4]  Add/enable stack protector
Thread-Topic: [PATCH v4 0/4]  Add/enable stack protector
Thread-Index: AQHbZjxnT1sWh5IhbkWxtBQPTP3DXA==
Date: Tue, 14 Jan 2025 04:25:55 +0000
Message-ID: <20250114042553.1624831-1-volodymyr_babchuk@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: git-send-email 2.47.1
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: GV1PR03MB10456:EE_|DB8PR03MB6300:EE_
x-ms-office365-filtering-correlation-id: 84d0eeb4-ce40-449e-2aef-08dd345389ee
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|376014|7416014|366016|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?QALWUg29LEbZ6hJgfrDdWYYN6rmnpA4uKmmTqxuAcm+XBZ6/aAGGk17To1?=
 =?iso-8859-1?Q?UWaXvXi3cEDoA48UGNqGejzPZkqaeS9/8WFzUSurLzmK+FxWXzGQNl4EiD?=
 =?iso-8859-1?Q?RJRnjwYt7WcY5eAEkfKoTT/OgCqLbq0S14O6M4H5mgsWbjXsVMPtshY6hh?=
 =?iso-8859-1?Q?BtDzNb57Wa9YlsK8gKVOC5ThGgPRzw3H99ln3g+00IT3WZl7og9tKg8nDS?=
 =?iso-8859-1?Q?xOrWGyIq2z+x+3EApCL3OC7q9+y1GP3oLpSn6iQSavux9aw9LLNGVYovHJ?=
 =?iso-8859-1?Q?v6sMKvXepp2AKbehIMaYgNCaBUtrYrd3plJ2br9UpZOeH8SWRSvdYOiRM6?=
 =?iso-8859-1?Q?ph6WUItZhFHK5HrvKZSKb8iT6Z1znWsZcMmKDrag89I80LCWabDnoLfYN/?=
 =?iso-8859-1?Q?2PrecPPdvrqxxUXrP8dd4PxN7nwX2lKo98MsemWqtv3/aGyl5djU1p7t0Z?=
 =?iso-8859-1?Q?dP63770l/vF8JykxN/JIDK+vZcktK4wB4ES3vZjWXOR96TuaUSe0Xh0HzG?=
 =?iso-8859-1?Q?NJlRS0xqq0r0YgKBJSBz37tzI5pyAnDOu+F6fNJ6+qfrcnkjDpgXMzGytr?=
 =?iso-8859-1?Q?4oki1oeKTvSa3DxsteA7hRZv6zSyJKIZf8pcTnoZO0GWSr/wVPEbisEd7w?=
 =?iso-8859-1?Q?NFOhx+7CU2ZsPXE+b4jE1PRb+rFIdkLCcUmg+oxtmmqv9jYWhxparro2xJ?=
 =?iso-8859-1?Q?rDYhyLvy/yU7nvFNWafbVY3HeXW+C+uBlJAc1dA+b9q35/etTHpk/B56qX?=
 =?iso-8859-1?Q?iozNWESLGIPWpMxP34NL/BN57lg/67364j5jSy4A3oVhCsW/hSXYcyyrbI?=
 =?iso-8859-1?Q?g5pMWT1rOp8PU00+GkDtKUvCRCqJC5ujWTK4tl56AahjfUrC28wQ9GXT5d?=
 =?iso-8859-1?Q?eIQurj27LA3HEDrdnj2QYOwm45UgzHnTjvGo2JJgS6Z6hGdUtld2WXAowy?=
 =?iso-8859-1?Q?G8xWhbucwCj7Cat6oSMSfA7TlKfaMeXubL2fgqHgD+FldCLaATmDzPQT+0?=
 =?iso-8859-1?Q?IvFxACh+SE1Y5y47wRmkCzCJsWeQwIewqFy9G//zqrGt+7khSlGhH0vamd?=
 =?iso-8859-1?Q?l0ub0xXcPWxkWxsGb1a9KyaTS/eeMGo4nEOJk4B/ybWJiskefi1mrSLG+h?=
 =?iso-8859-1?Q?kaPOKmjvbAUDTgUW6sFsvzu3xdw6iTUa1ZtgiEOa5K1ysrXxSGnOFRwWeZ?=
 =?iso-8859-1?Q?bG5lKMFM2/RkNotUpIjYURITKEqIMroeuQAKXWdEOf/+en04WgGwyX0NY5?=
 =?iso-8859-1?Q?SOooUog6PvDxAUEfgI2aYogfUyszyUbhoKefMb0QaevEKLMA0A8kb2UtVJ?=
 =?iso-8859-1?Q?9MOHH+XQWljJPGvW7Nru/x2oR0z4Crjia9cXvK1ICmOhEepxxZtm3U+AW+?=
 =?iso-8859-1?Q?UObrTrMlXCQjVTO3Y7JlGVaTacGmXJ9fBOsgpXJiNssVC1VpkJC7C3LDrX?=
 =?iso-8859-1?Q?uC82EBEdVWLzOKqh1ihIiqQOUrmH5S6dReHHyukGoegl3msEe9zd9uPseN?=
 =?iso-8859-1?Q?FoJ34u2knbwWmAUng2bSj/?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR03MB10456.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(7416014)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?E+OUDI0NEbRb70cRV1yvgELS0JEo6fULvxVL1Umn5+NyxNB0fjlGhL5zIf?=
 =?iso-8859-1?Q?Zw9NM5TZiUh1jv6SOHrLptHk+Rix8UTHE3mYOR+MPO6ijBV9Tdyl5wvTA+?=
 =?iso-8859-1?Q?FelVbCU0xBGgdG3c0fdHDhWA9vO9Q2Vgdf4whkMtwXaGfIzJCn69EPS0JP?=
 =?iso-8859-1?Q?Wh+MSOyGJGPTsMnD7tXx+q2wBORE1xxTGrbev16HjdxJn8sZHFuaON7asu?=
 =?iso-8859-1?Q?5XELpkt97QfxlpstHAvm1dkLB0chBek6inZqrLoCRFIL5zoyZJ8JPyBj3A?=
 =?iso-8859-1?Q?tbImKsUsMnx1vKFxTVLZ4fXTbiH6Lrnh9X05IRxq4PK4pCgWkRM4DWiqf0?=
 =?iso-8859-1?Q?9Abwum2Vru3hFJnntDNmOjKZGGsugsHnePR50+j5dIaDF1e87FNPLY9UGP?=
 =?iso-8859-1?Q?WF3SYKOXj6IgNCXxyXQbDKycE3oonUTWt/Q70XjMLFa4Z1arxUKJvFTxx5?=
 =?iso-8859-1?Q?U5rwwLMEa/XkXeUolX7ff5KZ8e0mOR6yfWs5Anmmq189OgIPeOXZCeTPof?=
 =?iso-8859-1?Q?MOHyETksZ8deka02IrcBMuSsAl93Dw2KdF5KoMUhjDmHBio2N+iI8TpbcC?=
 =?iso-8859-1?Q?6aIM3CM03P+FJnB5/RtsGKvYLfp3eHHJJtAJQehgRBeajbSnNkjQ8X5l/m?=
 =?iso-8859-1?Q?Odyh9bl0JBFaPLxq6B7l+dy1hcScMOBWl66JLyZyInjJMmpGiT9GjTJGiB?=
 =?iso-8859-1?Q?QJD295cjf3R8aKMHb1Q/5gzvMzflrqTxTyYaXnOP6ZEjZ43xZv/Q4c16p5?=
 =?iso-8859-1?Q?AizRAZSIN7fKgqnf1rgXu5vF8JYsllXx9eWs9/Tb0N4f36bt1lGvhPpO4H?=
 =?iso-8859-1?Q?qlRxHVZkeSgg95J9cbqJPuK0/0Fpv2iCiIvEwHuwuvFufiIaRqLPltouga?=
 =?iso-8859-1?Q?hzW2Y25gnNlnqTsEiLDzyUTDKnQL6rk8eJFCZsCDOmaHhpKSUUX/yBkfGT?=
 =?iso-8859-1?Q?nOLnmcAe5zie99DbyHIpqgsS4F7LthfvLzJfaTfd9rDm7AopmymtnzUDL6?=
 =?iso-8859-1?Q?+R0/lGOzP79Su5uaWsvTdTK+is9pxowC7QCEInWNmqsHbd6U49CALJ7lPJ?=
 =?iso-8859-1?Q?NlJZHae5zIjJUPUDZAbyAlbY98p4409EVvkZBjIKbCs7N3CDd/skRugbEA?=
 =?iso-8859-1?Q?Xj87l0r0cIdNqjdK6jdPbMTdez4ImHz96lEQDWK2env6vObk9lPnIP3VUX?=
 =?iso-8859-1?Q?689V8sEIBHXm94flvyPXFREKWyfuZPUWcoZTwT5tB1e+fHRc6YbNjDP4XI?=
 =?iso-8859-1?Q?r3ffgQad/QIWbT05CJ+At/zGV5w34KeBKDjg8/HQjORoT67YRa9+osvNwp?=
 =?iso-8859-1?Q?fhv2gfeEieLJmWfEqNvw9OJfGbcMKutoZcSK7OWw9x3eql7oMZU3c/w6hD?=
 =?iso-8859-1?Q?gnPHC9Or52QBHiZOEZG4D0Bez1yd3AlOneekjvSMjXXKjIexbF6rigS6tH?=
 =?iso-8859-1?Q?o0sVGO8gAOnjckP8JprDjcbey+xauveLRZhBlVaEKqWc53+XSjSEo56f54?=
 =?iso-8859-1?Q?BcEyv7mir9hdOrnBTN9UC872/YKUJOMJHNATyYcuSqx49SxEMCslKunE3s?=
 =?iso-8859-1?Q?Jmcd5HJKlobaYix4yYUvAjfaWIdHMzcCkp3sg5CiGU4IMpZahx1fMm/GdM?=
 =?iso-8859-1?Q?T/fTY2eoDxYqlNCabkIZk7HUNn+CD/JRSkzFjIox2+4KuGf/v6H74BLQ?=
 =?iso-8859-1?Q?=3D=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: GV1PR03MB10456.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 84d0eeb4-ce40-449e-2aef-08dd345389ee
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2025 04:25:55.6860
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ConcDrQK26gT9YPfN+8afmSBi83WAdbur3CuhXD4Hu7wSWRJwmOKI9mF3SQeBfiOzn+XmsmrukDTYLwHPudBplOzHnPJscoIKjrFE4Hzrqw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR03MB6300

Both GCC and Clang support -fstack-protector feature, which add stack
canaries to functions where stack corruption is possible. This series
makes possible to use this feature in Xen. I tested this on ARM64 and
it is working as intended. Tested both with GCC and Clang.

It is hard to enable this feature on x86, as GCC stores stack canary
in %fs:40 by default, but Xen can't use %fs for various reasons. It is
possibly to change stack canary location new newer GCC versions, but
attempt to do this uncovered a whole host problems with GNU ld.
So, this series focus mostly on ARM.

Changes in v4:

 - Added patch to CHANGELOG.md
 - Removed stack-protector.h because we dropped support for
   Xen's built-in RNG code and rely only on own implementation
 - Changes in individual patches are covered in their respect commit
 messages

Changes in v3:

 - Removed patch for riscv
 - Changes in individual patches are covered in their respect commit
 messages

Changes in v2:

 - Patch "xen: common: add ability to enable stack protector" was
   divided into two patches.
 - Rebase onto Andrew's patch that removes -fno-stack-protector-all
 - Tested on RISC-V thanks to Oleksii Kurochko
 - Changes in individual patches covered in their respect commit
 messages


Volodymyr Babchuk (4):
  common: remove -fno-stack-protector from EMBEDDED_EXTRA_CFLAGS
  xen: common: add ability to enable stack protector
  xen: arm: enable stack protector feature
  CHANGELOG.md: Mention stack-protector feature

 CHANGELOG.md                         |  1 +
 Config.mk                            |  2 +-
 stubdom/Makefile                     |  2 ++
 tools/firmware/Rules.mk              |  2 ++
 tools/tests/x86_emulator/testcase.mk |  2 +-
 xen/Makefile                         |  6 ++++
 xen/arch/arm/Kconfig                 |  1 +
 xen/arch/arm/arm64/head.S            |  3 ++
 xen/arch/x86/boot/Makefile           |  1 +
 xen/common/Kconfig                   | 15 ++++++++
 xen/common/Makefile                  |  1 +
 xen/common/stack-protector.c         | 51 ++++++++++++++++++++++++++++
 12 files changed, 85 insertions(+), 2 deletions(-)
 create mode 100644 xen/common/stack-protector.c

--=20
2.47.1


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 04:26:17 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 04:26:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870901.1281960 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXYVG-0007hW-M9; Tue, 14 Jan 2025 04:26:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870901.1281960; Tue, 14 Jan 2025 04:26:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXYVG-0007hN-Im; Tue, 14 Jan 2025 04:26:10 +0000
Received: by outflank-mailman (input) for mailman id 870901;
 Tue, 14 Jan 2025 04:26:09 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=sZa5=UG=epam.com=Volodymyr_Babchuk@srs-se1.protection.inumbo.net>)
 id 1tXYVE-0007T1-SF
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 04:26:08 +0000
Received: from EUR03-AM7-obe.outbound.protection.outlook.com
 (mail-am7eur03on20612.outbound.protection.outlook.com
 [2a01:111:f403:260e::612])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ac958209-d22f-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 05:26:07 +0100 (CET)
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 (2603:10a6:150:16a::21) by DB8PR03MB6300.eurprd03.prod.outlook.com
 (2603:10a6:10:13f::13) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8356.12; Tue, 14 Jan
 2025 04:25:58 +0000
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e]) by GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e%3]) with mapi id 15.20.8335.015; Tue, 14 Jan 2025
 04:25:58 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ac958209-d22f-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=l17/z37zEKElYK7zOeWtDOtfKDD2KmUN35OG5ObTUa8FV46PGEj04e4gwhd+ZPcAcQm1yEfUXY9ue7tiHYpkampDoe5spSOdsFx1arurJspQzhVkYI1wLVHkIaFCO8l3v3+p5K6OmCYZW6mN5E1wBOPJSyKRx0WHPQfPbn3TVnDsd3jLqdlHl7S5xT9f2TXFleG36tWr+aV3i7cQ1tRew3zgyDBjKSQ+f3JOjv5S9lwaAls0GUHNGYH7mQdMjz6I54AFTyHKOBURklq44KDdgOlRQAf20WwLCT6vBGJ5XkWH3kdihi1cVhWpPwEj6B9zv3KoP95qnUSO1p5vS+kzSw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=5MtrRJxarp34S2JOLx/JyEv2kwrG4QQxCgAgsBhf7Ic=;
 b=ud15TjL/x8/iOHm4aAt9ALDKbZo4uQqyhml9iGsjChfeEiftf7Fb1NnPvDWjT+ql83ATVvKgT1Hc+dn4SRRgVyaeDAhPh2ECoyIje529Pn4QcC17QqDaC3NuWriQxf6GRAuGkSEfVg2QwuOXSR36XcmsSS5pUsVtr+SGHkAky28/EE+fYbn4lHkMNWGe5DdYOkmFdv2Z+TKwIJYwyH3m6NnTA4BYoU+UjkSS7tGpJidRL7gZsNXNjGDO99cjodPBkYp/kFS+1mC7Uq7C46Vy7POORINkqgLylHtLtrYaZu5l1OI/98cIdtrEOeGm3aOD0Htu7KSMD93eQ0NJGC9JVQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=5MtrRJxarp34S2JOLx/JyEv2kwrG4QQxCgAgsBhf7Ic=;
 b=UnMBEl1LEJULDOTFiJerc7iC/1+DxsRUMT+wbVpeQg9Upypk00+UzM/+IRzOSVtNCQ444AdKy1P7PFLLcAUThVCr5Aga5/J03xNvwAuhxnUFdaNrgVwn5T11jPx67z1pswaCHjWKfqplqAHnn4KClHFM7GC+dRcdaGjbBkhzPcnuoDg5bexhIgJN2gwopDOt5+rqSwvCai4XbF8akUZTciciXz5Xqj6IKGkKV2YkIulEed0lMeQiIrhLq+D2Pq+Pxvxedb+P2CO/fd6ZA73Cv3g2UJ884y8O52GSaHKUAJNY43aACjp5WFqoaehe5VTjliK5gSSYci/zuZ1MP+6iuQ==
From: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
CC: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>, Andrew Cooper
	<andrew.cooper3@citrix.com>, Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>, Julien
 Grall <julien@xen.org>, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	<roger.pau@citrix.com>, Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v4 2/4] xen: common: add ability to enable stack protector
Thread-Topic: [PATCH v4 2/4] xen: common: add ability to enable stack
 protector
Thread-Index: AQHbZjxnv4AIVf4qZ0m9Cu/vUIISVg==
Date: Tue, 14 Jan 2025 04:25:56 +0000
Message-ID: <20250114042553.1624831-3-volodymyr_babchuk@epam.com>
References: <20250114042553.1624831-1-volodymyr_babchuk@epam.com>
In-Reply-To: <20250114042553.1624831-1-volodymyr_babchuk@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: git-send-email 2.47.1
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: GV1PR03MB10456:EE_|DB8PR03MB6300:EE_
x-ms-office365-filtering-correlation-id: 692dc48c-a424-493a-b2c3-08dd34538baf
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?aVZ2Wk9xMGpEWFoxa3hVYTQxR25jbzVsWGFqcXlpYy9FVEt5ZnpEeHhmN0N2?=
 =?utf-8?B?MUpaamJuU1doSlU2K0dwOG1LZFdxSDI2d0Z3alFlRHA0U2QvNGxYaVVCMGdU?=
 =?utf-8?B?RTVBbDJWTmpwTVpYR2d4WUltQWZDM1A4aE5hT3dEN0puR0xROTNYRUwxSGI0?=
 =?utf-8?B?NW04dDlHd0dSVnZMYzQ4RFNFZytjbEpJYURqeFc1K203Q1lqMzJHb2xaZmxn?=
 =?utf-8?B?ZllhM0NJSVlGNzMzTlQzM0hadm5MQmhPekt0YmZaaTUyOUxIRENQV0RUakQ1?=
 =?utf-8?B?OHpRbzJ3T25BTHpUL1E5cmFLbWtKRzZGL0JWSWs3eTB4T3UwWXJJVnhFN0x0?=
 =?utf-8?B?Z2xCV01ONlY1bUJoVjhXNnArR09yY3JucEtEeWduZTFRMFpWemRVeU44M2d1?=
 =?utf-8?B?Q0luSHh4Z2JoOVNvQW5pSzQwVWtNT2lMZktWT2FLUm9CNlFPaU4yT1RLVDRu?=
 =?utf-8?B?UUlSTlJ4bzJic1NaOHgwQlY2bTk3L2hJTDFWbXFwSmxDSktvbVZvelNFckc0?=
 =?utf-8?B?ZHJ6YUpQcTcvakVGdnJvWmVTVjBUWEdPcUhDUXhwRllRY0lRVFBzL3RhTzR5?=
 =?utf-8?B?VzJ1dmdWN2hlKy9kemtXZmk3MW9EeFhvTk5mTEduQ0xQR0hid3doV3lkREFo?=
 =?utf-8?B?d3A0UTdqWVl5aktlMXBqWEtnNGorM3dEWHVMbVZrbjNtT3JZS0JzV0FTUzBa?=
 =?utf-8?B?ZFI2dHlKU3I4eDJpemRLQVZTRXd2ckUyN2NzbEFBUkkvc1RGYXpNcmt2RFJP?=
 =?utf-8?B?aExqeGdOdnc2VmVSYXNSV05qUGc3K1BZK3Z2N0dCMVVQZWd6TXcrb21Rd0h3?=
 =?utf-8?B?UW9xdFRUTmRxMUNsMXVObUgwNDlwZDBlenE1dmRaMHNUUTRHTDhmZFBwQ3Fw?=
 =?utf-8?B?ZWZ6anRjYlF3VTc5bTY1amxTK2Ivc1R5V3hpbHQwdnJYK0FmNjJxSWVPNDhm?=
 =?utf-8?B?eEhqTnF1c085QlN4N0pGN3k1dHJBTCtvZElVODNUSm96cEYwOE9oVmN2ZFNI?=
 =?utf-8?B?SGNBYzRiREkxV25vSFVUZWZPekxqWEtLVkNVMkZtdkwrREkvWFF5bzhaZEpn?=
 =?utf-8?B?SXR3UnlhdXlvY1I2UjE4ZVA5WlRieitLOE8ycTNEZmlpOVlQUU14RTlZcWVB?=
 =?utf-8?B?Z3V1V2h6ZHpCbEJuZlU5Qk95bWFFeGV0UFd6VXNvMGM2NXVYZnJXQzA0Q2Uw?=
 =?utf-8?B?ckJKNzlkSUN6ekNENkpYclRVR3FwajV2NkQvaXpRNEg1SS9KVzBYZHRhbUtW?=
 =?utf-8?B?Rk1yZGxZMnNZRHR0ekh5akFpNHVNaHFoOTJIeUxIbFZ4MENOSlV5dStrQUc5?=
 =?utf-8?B?cmIrQ01FOVpENHFXTEFzZEZnS3hNU1RRSVhFVjhHNFlvM3hRS0RlN21iS0N0?=
 =?utf-8?B?K1Q4QnYzZFJ0RE5MMWI5eWpVT0hZSURBTkhONU9MRlZiQVhQd3lsYXdpRkR6?=
 =?utf-8?B?cEVUNUVmTnFpTXR2NWRsWHN2TXVFblNoVUNUWmJrblNHcVpvcVRpU3ZXNjBH?=
 =?utf-8?B?OFpyQTVjUDliRDlrdzJ2Zjc5QmIxVG1Ta0Y1aHc5cEtxV3NDY256T0VBWkpa?=
 =?utf-8?B?cFd2UGxIcDNzTHVYRklDL3VXQWdrNWMzTEhhaGJYdVZQdzZTaW1RWkZzU1M5?=
 =?utf-8?B?N3VoMm90cWNqbnBXWFhOWjBnMjFER3FoTXhzRzJVYklUR2ZLN1NVWXMyUDVn?=
 =?utf-8?B?cWRBZHoxSElDZ3dkY1VmbFZ0aTh3Nms1Z0gzc1kyaFZMeDFqY0t2MWRQU3Fs?=
 =?utf-8?B?TFdqd0tnRVI2aktQc2RrdzlPU2hHcWVDY3BZQ3JjcWc4UFdHMGFUQjU1SUov?=
 =?utf-8?B?ZG1OUnZRT2R1ZnpQWEg1UXJsanZhWUZ2ajBqM3R5Q01nQjBIcGxXQmtHUkJD?=
 =?utf-8?B?R2FRajg2L3B0dGRIMDlua0FzbkFNZ0FQc3pwNVZoOTZleUMwcktDUnlyRTRh?=
 =?utf-8?Q?XOXKjP+ZnQcpWvf1nz9lKJuWN2eq69UZ?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR03MB10456.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?VEJuQ1JFQjBBczRjZHVyVmVna25yWGVvTUJBM2VMR1hGcjdPRVROaStGVUEy?=
 =?utf-8?B?NExYRlNEbU9LVEVVZHE2dXZKdmVqTTBTbEhaMlV4NGpwSWZtcmtVQUdxMWxO?=
 =?utf-8?B?aTVrc2RtU013ck9iTkk2K2k4QWozVjkyWHdKdC9vYS95ZHdQTWg4RnhURzdW?=
 =?utf-8?B?VzNmZEJZclpGOFdjc2xMR3NsQk5HQ3hSdlMzeVEzZ3l1NkhwVkpNczJDaWFw?=
 =?utf-8?B?bit4YTVtWmZab1BHbTRwZ2hkU2xEa3dCRElkRVBhS214Vkd6YWh1aUNGUjh6?=
 =?utf-8?B?b2pSLzZ5RFJJUzg0b250Rk5wMFZYQmV0dWoyNE85RHRqYzJjSGV3U2ZFQmlL?=
 =?utf-8?B?V3UyVk5rYkNVYUhYRDdEUDR3bGVDb05EdmRJZnpmUWt5UEJhRWlCeUpCVjRT?=
 =?utf-8?B?TjlyOUxSRlp1L3pDeTBERC9HcDNvbTU2bXpoTWVjUHpVWlVkN3ZmaFY0SnRN?=
 =?utf-8?B?QUF2L3A2UXpyOHVCWmFURy9vMVFuSGpGWktObzdBbmVBZmFlYm4wZkJJbmMz?=
 =?utf-8?B?dXNMZU91Vjd1WXR5RWlzQm12SGdQM3U0WENRUUpITnkvemVaWjZtTFlHUjJ6?=
 =?utf-8?B?bHJTaDQ2MWxTSTFid1VzcG9pVVNOenZla0ZkSlkxZXhxMTFEZG1SQmRRc0VN?=
 =?utf-8?B?UURnYmJPQWlaYzUwYm95SnNEeDZJUUM5cjhnWTRBakMxL0JITXY3QWJMY1RL?=
 =?utf-8?B?eHUzOGN1R3ZRZUZmZ1NFcGYwL29MUDZlR3Q3dFExS29Xa2UrT0tMVDJ5VmNq?=
 =?utf-8?B?UjVOQk1Pd0tnVlZCVkVlUEgrdlBFTkJ0YmtkS0taekdxL1RQY3RaR09yLzlQ?=
 =?utf-8?B?djhMS0YzU05ielBSMmtQVGIxSFFLejAwMzlxaGNWZ0tqMjIyZGgvdVc1c2Ru?=
 =?utf-8?B?d3NlUmRUNGdoZFhlS01DR2FRNU1WWHp2cVhSSGNMYXNFdDJ6VzBqVGZVRjE5?=
 =?utf-8?B?NEhWNWpXUGdNRUNtbWN6WElOTVZBWTkvT25UbmJFV0UvSmFTcFpHL01EdG5K?=
 =?utf-8?B?bDFrcE5GKzRVSlYvc2tNektJNzZYUHpBZVJqaElsU0RZaWNPRVNxUnhWS0dT?=
 =?utf-8?B?azZLVm5MSE01blJEQmo3aERNMzArTUwra2ptVC9FOW1LNzJDOXhHcUIrdVho?=
 =?utf-8?B?S0tjaDlsRWhJUmRkdWpqelVHY2lEMWhMRlc2ZWM1UFVpcS8rVzVKZDljOGsx?=
 =?utf-8?B?d0h5S3R4WlFMSHExTWNrdnJLTVQ2aUp3ZW5NbXdSc2pFVkRoMW1hOGhwL004?=
 =?utf-8?B?RTAwTHJrK0tQc2tIZDhmZ2lYQkxocWgydGg1S003Y0JkcWh3YzhnQVFRdExZ?=
 =?utf-8?B?L3kvNHhaQUk0UmVxdDI5QVVQMWVRRHdnWFAzeE5VK2pyL1h5MTVGRVM2YXQ5?=
 =?utf-8?B?WkNlRWNrSUdZODFFbjlTN1g0RzJkY2RjVUJlL1ZsUkFXMUpvMmxOZWxtemRj?=
 =?utf-8?B?eWJnTG0rV2daZ1ZMQ0MreFRXVFoyU3hKcmYrTUg1VUg0dHB0TTA3bDlsK0Yx?=
 =?utf-8?B?alI0TjZrNVR1ZDZQYWRlem54cWcvOHdXVGlTeUZIUGFDRnZoMVE2TUNaSXc5?=
 =?utf-8?B?TTBSbERmNitLS0d0K2g5YTRVUkcvN0Ercnc4bk9wY1Z5dm0xOVJxODlIZnJo?=
 =?utf-8?B?SmJBNDZtdGFCbWV0V25wWGVpeWNXUGFuNllsTzdNT2xyelZIUHZtU2FqZnlu?=
 =?utf-8?B?WmI2ZG1BaXh1RGRoT0V0b0JWRm9EdnVrUkNzWUlsdjBnckljN3BNM1BLVkNL?=
 =?utf-8?B?NjBZTFFHMmNKSzQ0TEIrMVRwWW1sNmZ2cDVuSjZObE85cVp3MUlRN3Zzd2tn?=
 =?utf-8?B?RzFVbnNqelE1UkZRekpiYkpDZlFDd2Zydk5qKzJjWDFrbmpKQkk1T0ZTN3I5?=
 =?utf-8?B?UjVaOWxFRnFQNHdQanNBazJxaHJtK0Zxd1hvY3kwMDAvak5TMUsxYnRpdndS?=
 =?utf-8?B?cFFYNVlWa053bk9wM0drTHFqK1B4ZlJRbjNySHBhUFdlOWE3QjNNVTZ4Z0FY?=
 =?utf-8?B?Qm1zbjNoa1Q0ejlPL3BOYlFkdVljVks0alg4TlRVUzNDNHhhdTJwUG41eWlC?=
 =?utf-8?B?ZWRBUEE4NDEzVHp3UzRONkZWcjJOaHJsYTNKWWhLWkZNNXJmcmd0RkpBNUNh?=
 =?utf-8?B?VGhmVHQrTEhYRFljMDRXdDB3N3RwaUFoYXZmL3AyVDBJelpCWHBYV1RTOWdh?=
 =?utf-8?B?RFE9PQ==?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <EC61816ED7386E48BCDEA64E087A93CD@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: GV1PR03MB10456.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 692dc48c-a424-493a-b2c3-08dd34538baf
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2025 04:25:56.3138
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: lOPPHbF1PoRrJIxzKkAceFvrnygGLR1CNJlNvqAXLOd8KCfBIYmjb6lxz3+R/K3GiE7GjPwNAG1E5myl+8p0GmEEiLBF5KAO1QK7t7d81xE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR03MB6300

Qm90aCBHQ0MgYW5kIENsYW5nIHN1cHBvcnQgLWZzdGFjay1wcm90ZWN0b3IgZmVhdHVyZSwgd2hp
Y2ggYWRkIHN0YWNrDQpjYW5hcmllcyB0byBmdW5jdGlvbnMgd2hlcmUgc3RhY2sgY29ycnVwdGlv
biBpcyBwb3NzaWJsZS4gVGhpcyBwYXRjaA0KbWFrZXMgZ2VuZXJhbCBwcmVwYXJhdGlvbnMgdG8g
ZW5hYmxlIHRoaXMgZmVhdHVyZSBvbiBkaWZmZXJlbnQNCnN1cHBvcnRlZCBhcmNoaXRlY3R1cmVz
Og0KDQogLSBBZGRlZCBDT05GSUdfSEFTX1NUQUNLX1BST1RFQ1RPUiBvcHRpb24gc28gZWFjaCBh
cmNoaXRlY3R1cmUNCiAgIGNhbiBlbmFibGUgdGhpcyBmZWF0dXJlIGluZGl2aWR1YWxseQ0KIC0g
QWRkZWQgdXNlci1zZWxlY3RhYmxlIENPTkZJR19TVEFDS19QUk9URUNUT1Igb3B0aW9uDQogLSBJ
bXBsZW1lbnRlZCBjb2RlIHRoYXQgc2V0cyB1cCByYW5kb20gc3RhY2sgY2FuYXJ5IGFuZCBhIGJh
c2ljDQogICBoYW5kbGVyIGZvciBzdGFjayBwcm90ZWN0b3IgZmFpbHVyZXMNCg0KU3RhY2sgZ3Vh
cmQgdmFsdWUgaXMgaW5pdGlhbGl6ZWQgaW4gdHdvIHBoYXNlczoNCg0KMS4gUHJlLWRlZmluZWQg
cmFuZG9tbHktc2VsZWN0ZWQgdmFsdWUuDQoNCjIuIE93biBpbXBsZW1lbnRhdGlvbiBsaW5lYXIg
Y29uZ3J1ZW50IHJhbmRvbSBudW1iZXIgZ2VuZXJhdG9yLiBJdA0KcmVsaWVzIG9uIGdldF9jeWNs
ZXMoKSBiZWluZyBhdmFpbGFibGUgdmVyeSBlYXJseS4gSWYgZ2V0X2N5Y2xlcygpDQpyZXR1cm5z
IHplcm8sIGl0IHdvdWxkIGxlYXZlIHByZS1kZWZpbmVkIHZhbHVlIGZyb20gdGhlIHByZXZpb3Vz
DQpzdGVwLg0KDQpTaWduZWQtb2ZmLWJ5OiBWb2xvZHlteXIgQmFiY2h1ayA8dm9sb2R5bXlyX2Jh
YmNodWtAZXBhbS5jb20+DQoNCi0tLQ0KDQpDaGFuZ2VzIGluIHY0Og0KIC0gUmVtb3ZlZCB0aGly
ZCBwaGFzZSBvZiBpbml0aWFsaXphdGlvbiAoaXQgd2FzIHVzaW5nIFhlbidzIFJORykNCiAtIHJl
bW92ZSBzdGFjay1wcm90ZWN0b3IuaCBiZWNhdXNlIGl0IGlzIG5vdCByZXF1aXJlZCBhbnltb3Jl
DQogLSBSZXdvcmRlZCBjb21tZW50cw0KIC0gX19zdGFja19jaGtfZmFpbCgpIG5vdyBkdW1wcyBl
eGVjdXRpb24gc3RhdGUgYmVmb3JlIGNhbGxpbmcgcGFuaWMoKQ0KIC0gIkNvbXBpbGVyIG9wdGlv
biIgS2NvbmZpZyBlbnRyeSByZW5hbWVkIHRvICJPdGhlciBoYXJkZW5pbmciDQoNCkNoYW5nZXMg
aW4gdjM6DQogLSBGaXhlZCBjb2Rpbmcgc3R5bGUgaW4gc3RhY2stcHJvdGVjdG9yLmgNCiAtIEV4
dGVuZGVkIHBhbmljKCkgbWVzc2FnZQ0KIC0gSW5jbHVkZWQgbWlzc2VkIHJhbmRvbS5oDQogLSBS
ZW5hbWVkIEtjb25maWcgb3B0aW9uDQogLSBVc2VkIEFuZHJldydzIHN1Z2dlc3Rpb24gZm9yIHRo
ZSBLY29uZmlnIGhlbHAgdGV4dA0KIC0gQWRkZWQgImFzbWxpbmthZ2UiIGF0dHJpYnV0ZSB0byBf
X3N0YWNrX2Noa19mYWlsKCkgdG8gbWFrZSBFY2xhaXINCiBoYXBweQ0KIC0gSW5pdGlhbCBzdGFj
ayBndWFyZCB2YWx1ZSBpcyByYW5kb20NCiAtIEFkZGVkIExDRyB0byBnZW5lcmF0ZSBzdGFjayBn
dWFyZCB2YWx1ZSBhdCBlYXJseSBib290IHN0YWdlcw0KIC0gQWRkZWQgY29tbWVudCB0byBhc20t
Z2VuZXJpYy9yYW5kb20uaCBhYm91dCBkZXBlbmRlbmNpZXMNCiAtIEV4dGVuZGVkIHRoZSBjb21t
aXQgbWVzc2FnZQ0KDQpDaGFuZ2VzIGluIHYyOg0KIC0gTW92ZWQgY2hhbmdlcyB0byBFTUJFRERF
RF9FWFRSQV9DRkxBR1MgaW50byBzZXBhcmF0ZSBwYXRjaA0KIC0gUmVuYW1lZCBzdGFja19wcm90
ZWN0b3IuYyB0byBzdGFjay1wcm90ZWN0b3IuYw0KIC0gUmVuYW1lZCBzdGFja19wcm90ZWN0b3Iu
aCB0byBzdGFjay1wcm90ZWN0b3IuaA0KIC0gUmVtb3ZlZCAjaWZkZWYgQ09ORklHX1g4NiBpbiBz
dGFjay1wcm90ZWN0b3IuaA0KIC0gVXBkYXRlZCBjb21tZW50IGluIHN0YWNrLXByb3RlY3Rvci5o
DQogICAoYWxzbywgd2UgY2FuJ3QgY2FsbCBib290X3N0YWNrX2Noa19ndWFyZF9zZXR1cCgpIGZy
b20gYXNtIGNvZGUgaW4NCiAgIGdlbmVyYWwgY2FzZSwgYmVjYXVzZSBpdCBjYWxscyBnZXRfcmFu
ZG9tKCkgYW5kIGdldF9yYW5kb20oKSBtYXkNCiAgIGRlcGVuZCBpbiBwZXJfY3B1IGluZnJhc3Ry
dWN0dXJlLCB3aGljaCBpcyBpbml0aWFsaXplZCBsYXRlcikNCiAtIEZpeGVkIGNvZGluZyBzdHls
ZQ0KIC0gTW92ZWQgQ09ORklHX1NUQUNLX1BST1RFQ1RPUiBpbnRvIG5ld2x5IGFkZGVkICJDb21w
aWxlciBvcHRpb25zIg0KIHN1Ym1lbnUNCiAtIE1hcmtlZCBfX3N0YWNrX2Noa19ndWFyZCBhcyBf
X3JvX2FmdGVyX2luaXQNCi0tLQ0KIHhlbi9NYWtlZmlsZSAgICAgICAgICAgICAgICAgfCAgNCAr
KysNCiB4ZW4vY29tbW9uL0tjb25maWcgICAgICAgICAgIHwgMTUgKysrKysrKysrKysNCiB4ZW4v
Y29tbW9uL01ha2VmaWxlICAgICAgICAgIHwgIDEgKw0KIHhlbi9jb21tb24vc3RhY2stcHJvdGVj
dG9yLmMgfCA1MSArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysNCiA0IGZpbGVz
IGNoYW5nZWQsIDcxIGluc2VydGlvbnMoKykNCiBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2NvbW1v
bi9zdGFjay1wcm90ZWN0b3IuYw0KDQpkaWZmIC0tZ2l0IGEveGVuL01ha2VmaWxlIGIveGVuL01h
a2VmaWxlDQppbmRleCBhMGM3NzRhYjdkLi40OGJjMTdjNDE4IDEwMDY0NA0KLS0tIGEveGVuL01h
a2VmaWxlDQorKysgYi94ZW4vTWFrZWZpbGUNCkBAIC00MzUsNyArNDM1LDExIEBAIGVsc2UNCiBD
RkxBR1NfVUJTQU4gOj0NCiBlbmRpZg0KIA0KK2lmZXEgKCQoQ09ORklHX1NUQUNLX1BST1RFQ1RP
UikseSkNCitDRkxBR1MgKz0gLWZzdGFjay1wcm90ZWN0b3INCitlbHNlDQogQ0ZMQUdTICs9IC1m
bm8tc3RhY2stcHJvdGVjdG9yDQorZW5kaWYNCiANCiBpZmVxICgkKENPTkZJR19MVE8pLHkpDQog
Q0ZMQUdTICs9IC1mbHRvDQpkaWZmIC0tZ2l0IGEveGVuL2NvbW1vbi9LY29uZmlnIGIveGVuL2Nv
bW1vbi9LY29uZmlnDQppbmRleCA2MTY2MzI3ZjRkLi5iZDUzZGFlNDNjIDEwMDY0NA0KLS0tIGEv
eGVuL2NvbW1vbi9LY29uZmlnDQorKysgYi94ZW4vY29tbW9uL0tjb25maWcNCkBAIC04Myw2ICs4
Myw5IEBAIGNvbmZpZyBIQVNfUE1BUA0KIGNvbmZpZyBIQVNfU0NIRURfR1JBTlVMQVJJVFkNCiAJ
Ym9vbA0KIA0KK2NvbmZpZyBIQVNfU1RBQ0tfUFJPVEVDVE9SDQorCWJvb2wNCisNCiBjb25maWcg
SEFTX1VCU0FODQogCWJvb2wNCiANCkBAIC0yMTYsNiArMjE5LDE4IEBAIGNvbmZpZyBTUEVDVUxB
VElWRV9IQVJERU5fTE9DSw0KIA0KIGVuZG1lbnUNCiANCittZW51ICJPdGhlciBoYXJkZW5pbmci
DQorDQorY29uZmlnIFNUQUNLX1BST1RFQ1RPUg0KKwlib29sICJTdGFjayBwcm90ZWN0b3IiDQor
CWRlcGVuZHMgb24gSEFTX1NUQUNLX1BST1RFQ1RPUg0KKwloZWxwDQorCSAgRW5hYmxlIHRoZSBT
dGFjayBQcm90ZWN0b3IgY29tcGlsZXIgaGFyZGVuaW5nIG9wdGlvbi4gVGhpcyBpbnNlcnRzIGEN
CisJICBjYW5hcnkgdmFsdWUgaW4gdGhlIHN0YWNrIGZyYW1lIG9mIGZ1bmN0aW9ucywgYW5kIHBl
cmZvcm1zIGFuIGludGVncml0eQ0KKwkgIGNoZWNrIG9uIGZ1bmN0aW9uIGV4aXQuDQorDQorZW5k
bWVudQ0KKw0KIGNvbmZpZyBESVRfREVGQVVMVA0KIAlib29sICJEYXRhIEluZGVwZW5kZW50IFRp
bWluZyBkZWZhdWx0Ig0KIAlkZXBlbmRzIG9uIEhBU19ESVQNCmRpZmYgLS1naXQgYS94ZW4vY29t
bW9uL01ha2VmaWxlIGIveGVuL2NvbW1vbi9NYWtlZmlsZQ0KaW5kZXggY2JhM2IzMjczMy4uOGFk
YmY2YTNiNSAxMDA2NDQNCi0tLSBhL3hlbi9jb21tb24vTWFrZWZpbGUNCisrKyBiL3hlbi9jb21t
b24vTWFrZWZpbGUNCkBAIC00Niw2ICs0Niw3IEBAIG9iai15ICs9IHNodXRkb3duLm8NCiBvYmot
eSArPSBzb2Z0aXJxLm8NCiBvYmoteSArPSBzbXAubw0KIG9iai15ICs9IHNwaW5sb2NrLm8NCitv
YmotJChDT05GSUdfU1RBQ0tfUFJPVEVDVE9SKSArPSBzdGFjay1wcm90ZWN0b3Iubw0KIG9iai15
ICs9IHN0b3BfbWFjaGluZS5vDQogb2JqLXkgKz0gc3ltYm9scy5vDQogb2JqLXkgKz0gdGFza2xl
dC5vDQpkaWZmIC0tZ2l0IGEveGVuL2NvbW1vbi9zdGFjay1wcm90ZWN0b3IuYyBiL3hlbi9jb21t
b24vc3RhY2stcHJvdGVjdG9yLmMNCm5ldyBmaWxlIG1vZGUgMTAwNjQ0DQppbmRleCAwMDAwMDAw
MDAwLi44ZmE5ZjYxNDdmDQotLS0gL2Rldi9udWxsDQorKysgYi94ZW4vY29tbW9uL3N0YWNrLXBy
b3RlY3Rvci5jDQpAQCAtMCwwICsxLDUxIEBADQorLyogU1BEWC1MaWNlbnNlLUlkZW50aWZpZXI6
IEdQTC0yLjAtb25seSAqLw0KKyNpbmNsdWRlIDx4ZW4vaW5pdC5oPg0KKyNpbmNsdWRlIDx4ZW4v
bGliLmg+DQorI2luY2x1ZGUgPHhlbi9yYW5kb20uaD4NCisjaW5jbHVkZSA8eGVuL3RpbWUuaD4N
CisNCisvKg0KKyAqIEluaXRpYWwgdmFsdWUgaXMgY2hvc2VuIGJ5IGEgZmFpciBkaWNlIHJvbGwu
DQorICogSXQgd2lsbCBiZSB1cGRhdGVkIGR1cmluZyBib290IHByb2Nlc3MuDQorICovDQorI2lm
IEJJVFNfUEVSX0xPTkcgPT0gMzINCit1bnNpZ25lZCBsb25nIF9fcm9fYWZ0ZXJfaW5pdCBfX3N0
YWNrX2Noa19ndWFyZCA9IDB4ZGQyY2M5MjdVTDsNCisjZWxzZQ0KK3Vuc2lnbmVkIGxvbmcgX19y
b19hZnRlcl9pbml0IF9fc3RhY2tfY2hrX2d1YXJkID0gMHgyZDg1MzYwNWE0ZDlhMDljVUw7DQor
I2VuZGlmDQorDQorLyoNCisgKiBUaGlzIGZ1bmN0aW9uIHNob3VsZCBiZSBjYWxsZWQgZnJvbSBl
YXJseSBhc20gb3IgZnJvbSBhIEMgZnVuY3Rpb24NCisgKiB0aGF0IGVzY2FwZXMgc3RhY2sgY2Fu
YXJ5IHRyYWNraW5nIChieSBjYWxsaW5nDQorICogcmVzZXRfc3RhY2tfYW5kX2p1bXAoKSBmb3Ig
ZXhhbXBsZSkuDQorICovDQordm9pZCBfX2luaXQgYXNtbGlua2FnZSBib290X3N0YWNrX2Noa19n
dWFyZF9zZXR1cCh2b2lkKQ0KK3sNCisgICAgLyoNCisgICAgICogTGluZWFyIGNvbmdydWVudCBn
ZW5lcmF0b3IgKFhfbisxID0gWF9uICogYSArIGMpLg0KKyAgICAgKg0KKyAgICAgKiBDb25zdGFu
dCBpcyB0YWtlbiBmcm9tICJUYWJsZXMgT2YgTGluZWFyIENvbmdydWVudGlhbA0KKyAgICAgKiBH
ZW5lcmF0b3JzIE9mIERpZmZlcmVudCBTaXplcyBBbmQgR29vZCBMYXR0aWNlIFN0cnVjdHVyZSIg
YnkNCisgICAgICogUGllcnJlIEzigJlFY3V5ZXIuDQorICAgICAqLw0KKyNpZiBCSVRTX1BFUl9M
T05HID09IDMyDQorICAgIGNvbnN0IHVuc2lnbmVkIGxvbmcgYSA9IDI4OTEzMzY0NTNVTDsNCisj
ZWxzZQ0KKyAgICBjb25zdCB1bnNpZ25lZCBsb25nIGEgPSAyODYyOTMzNTU1Nzc3OTQxNzU3VUw7
DQorI2VuZGlmDQorICAgIGNvbnN0IHVuc2lnbmVkIGxvbmcgYyA9IDE7DQorDQorICAgIHVuc2ln
bmVkIGxvbmcgY3ljbGVzID0gZ2V0X2N5Y2xlcygpOw0KKw0KKyAgICAvKiBVc2UgdGhlIGluaXRp
YWwgdmFsdWUgaWYgd2UgY2FuJ3QgZ2VuZXJhdGUgcmFuZG9tIG9uZSAqLw0KKyAgICBpZiAoICFj
eWNsZXMgKQ0KKyAgICAgICAgICAgIHJldHVybjsNCisNCisgICAgX19zdGFja19jaGtfZ3VhcmQg
PSBjeWNsZXMgKiBhICsgYzsNCit9DQorDQordm9pZCBhc21saW5rYWdlIF9fc3RhY2tfY2hrX2Zh
aWwodm9pZCkNCit7DQorICAgIGR1bXBfZXhlY3V0aW9uX3N0YXRlKCk7DQorICAgIHBhbmljKCJT
dGFjayBQcm90ZWN0b3IgaW50ZWdyaXR5IHZpb2xhdGlvbiBpZGVudGlmaWVkXG4iKTsNCit9DQot
LSANCjIuNDcuMQ0K


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 04:26:17 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 04:26:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870900.1281950 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXYVF-0007TP-BE; Tue, 14 Jan 2025 04:26:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870900.1281950; Tue, 14 Jan 2025 04:26:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXYVF-0007TI-82; Tue, 14 Jan 2025 04:26:09 +0000
Received: by outflank-mailman (input) for mailman id 870900;
 Tue, 14 Jan 2025 04:26:07 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=sZa5=UG=epam.com=Volodymyr_Babchuk@srs-se1.protection.inumbo.net>)
 id 1tXYVD-0007T1-Qg
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 04:26:07 +0000
Received: from EUR03-AM7-obe.outbound.protection.outlook.com
 (mail-am7eur03on20612.outbound.protection.outlook.com
 [2a01:111:f403:260e::612])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a8db482b-d22f-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 05:26:01 +0100 (CET)
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 (2603:10a6:150:16a::21) by DB8PR03MB6300.eurprd03.prod.outlook.com
 (2603:10a6:10:13f::13) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8356.12; Tue, 14 Jan
 2025 04:25:58 +0000
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e]) by GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e%3]) with mapi id 15.20.8335.015; Tue, 14 Jan 2025
 04:25:58 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a8db482b-d22f-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=twLS1QJUg53q+bKBQGsnqe7IItYwsHmxgiwkTBLCrvglecOqxHDRxvzJTDtcCUTKzfsE6jYvCb24eCHWlXj0a7e87QSZR2S36Zzf24XoBUuoCkmAeEj5pvA3BEejXxIHnXkwKMnfkrNSBwrZhX7lSfg+xm+hm8vATCnPHQdn+pKitA+9tu1HvmJEcWWTaaWAnzDHi+6jqWD71iPgonj95Ov42ib2dnxIf/bnqMiHBuqoW5AkofuNEJBtvGyaIVlN9mDbUhW8A8F9wbSoVCV5GiHrgW7wFY6my6FW1r26jBHKFY2UrvjfJ+LTWG9TcFn1Sqfht3ktu3Xou00y//kx8Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=oOdNcIAOSgUxY9nIPcgrwfCpmXDyekAM1FEvRJo6MHM=;
 b=OZ5qxIAQY3sIPXf1sT0VPQhwQc84C5GyHdSMB7GX159pdJ08RAgkZC1U5n9tulYujHOO3QXVC6jnS8xsCT2RGIIALsk+Qj5eET3snS8XpfEI3Vyp4zN1qt/HlzJguuKmeyyDhuXNhfB44v/iJAgg5Y84bgdpawKDYLBOqsSZypqUZCTJXNW4dvjKDNzUBstrqsaS9bHNNPZSOUFjCNVhdrxfL9F6kj+UfR4wSE4uw8U5stVlhhtMZexOdggcFg1cKjeiLrSWnFuux26/bjHLhxriMgkD2axk0VT2CH+OnqTgPk5OevflMyO3oJIRSMY0OuZadT42j5zlQ/TL7Jvr5w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=oOdNcIAOSgUxY9nIPcgrwfCpmXDyekAM1FEvRJo6MHM=;
 b=DLsg94Ut0KSS77Z7PLwsfNKYBbo5rEkAGFDsjOPLU6OSkN7aAwdLAMHibx1mmWqVeKFTF39MLcKg/If9QHXA0mQW1mmh/oaCqlXHXxcToHF/o9CKSmWVkWYZWlovFqx9Xrzh6SenT0Fwh6nL/qkBfwzNgdjAbp34EEXoL1+tTnJEZ8sG/pWE2PuHKNTKyxFiloS41IjgprQYIxEui6H5wohQD7+DJ+CF97sLNrOPIFgfzJovZSlNZ6+sdClZv5WIoTSZ73y+cqYVXq+denwQLc5+ExaqzsLr7/HqV37+RxmsR65K3I/7dzxLg1lLi+TsWSVe2LLS/GHt6zQ271jOSg==
From: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
CC: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand Marquis
	<bertrand.marquis@arm.com>, Michal Orzel <michal.orzel@amd.com>, Volodymyr
 Babchuk <Volodymyr_Babchuk@epam.com>
Subject: [PATCH v4 3/4] xen: arm: enable stack protector feature
Thread-Topic: [PATCH v4 3/4] xen: arm: enable stack protector feature
Thread-Index: AQHbZjxnrBLNCau4fk6dLN+QtVmLtA==
Date: Tue, 14 Jan 2025 04:25:56 +0000
Message-ID: <20250114042553.1624831-4-volodymyr_babchuk@epam.com>
References: <20250114042553.1624831-1-volodymyr_babchuk@epam.com>
In-Reply-To: <20250114042553.1624831-1-volodymyr_babchuk@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: git-send-email 2.47.1
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: GV1PR03MB10456:EE_|DB8PR03MB6300:EE_
x-ms-office365-filtering-correlation-id: 94f90734-a613-48c2-47cc-08dd34538bd1
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|366016|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?ZD6Dg1neyJjs7BOLntiqSUddy+Viycyi58r0PQ/kvvxa9WLUCyN4kLZsei?=
 =?iso-8859-1?Q?P7WpSQfRoLZbq2k7QhtFo4F3ND5V7D41BjdhX9mPZoYf7ssNto0vGYsS5q?=
 =?iso-8859-1?Q?VDDkHTu5hmuACIS3x9UIjlQNiQNGP2TTIuFbODnJvZKU1mDZzJlzRjHCI3?=
 =?iso-8859-1?Q?+hUW/RF4l+2QItbU2DIkrCyBjSPOD5SH47DDuTr/kDyBw38eAwz3w+AYR0?=
 =?iso-8859-1?Q?QCGBEDFqIZH+E8Uy8XsGJ1E4NGUczKKURlKPO98eaNlpTviXvJZIwM9gBO?=
 =?iso-8859-1?Q?d+nMwQuoUVHVNvXxs+wkh5kGsOi53kC+fBIy4tEIlAWGMukQ8mgBQOONCb?=
 =?iso-8859-1?Q?3YGYe3qfSrYh1GmvIPhIxPAmINdaYgsWtSafoXdGOW9Xyhnb6QBrYVen+Q?=
 =?iso-8859-1?Q?6o5kMYHjWvmkeaFZcIFyIoE3wcj6lXbh8jHdRrc741ucZ/apayyP2t5T1x?=
 =?iso-8859-1?Q?jtVC+UuIXgOqoS6Mb9yr/jxrWvXj2xAoDJm1QnDIoIY9pCwB4ZJb6mMQKW?=
 =?iso-8859-1?Q?vzhGl4AB7BICQ4P+CQXx33dj35Gl/1J4hDtL0nqkV6F/tsnhgDVfw1eSNc?=
 =?iso-8859-1?Q?0a5+ccnqEf46tZdqhlGULUa3GMgDNyoiklv+uBgZuZFd7QKwR0gLxUt5LN?=
 =?iso-8859-1?Q?LsuurMyWA9cjFsQKNPt86i1DLDWuCQuiMX+tPxc9UMGJFIUZe2nqca9r1C?=
 =?iso-8859-1?Q?g927Z0cWBNQQjjLpRgvGDDAZM4AEme2+V3CE9XINeOdSRyj7NjdenK7dDL?=
 =?iso-8859-1?Q?m9DmBzpbJT78CU1pORSR1HSdf6pJ5wUFRCtzsPcITC+OhTabJKg5PG60r/?=
 =?iso-8859-1?Q?oW+9TywXwliTwMZ1s7YCsuNjJbeRVlF/AcpkjZuRCCH9GC4er+2/KnNhlP?=
 =?iso-8859-1?Q?jDTd32fjYFIKBvjTh7wE80/wrR4KAidAomVERQKf/18HbBQsuqwM5QwyDJ?=
 =?iso-8859-1?Q?4kU4VgtbeidXmSUdPbCZd6ppqLWU1nX2IJmYZSlg77iXV11RO8yXIrB3RK?=
 =?iso-8859-1?Q?N2b1a3ogLcqQfYV0JqT4rQfwan45G16Wk5vd1hdjr5ILhjmlzbiD8QpP1M?=
 =?iso-8859-1?Q?r/x8A+6bUi9phUyDNU3Gv+LUhVpM6+esIB0PxAwx+hu7aP81BmmmVTymi2?=
 =?iso-8859-1?Q?YCeQfeJIndQbjGjV+OtNNOBP86r/wV6rIAjDJ5Mh0uFfCxcMorAWgXkHnR?=
 =?iso-8859-1?Q?mnoC/0FBhmQQSTkIktcrwrdTOBBr2Y5CNDTXPQldcpvGCIRRlSqoDFkirQ?=
 =?iso-8859-1?Q?b9wZcKP7VXtBpoJAZKby4QJTXMe5kHYdoVI09T68bozTkFul34MYqNWpgT?=
 =?iso-8859-1?Q?rgf7ydOOlgK8npaVRQC2qaHLxmWNxAcWTgAmYTiys+0JMFi9FUnmmVd6Xi?=
 =?iso-8859-1?Q?AnUKqBrKalLILZL2V5b++ruciA4TKrf6Dxf/z9S21c5JEyL5ObMuSe1/4R?=
 =?iso-8859-1?Q?ESpkhFSMq5fqS8ZN1Zu+hgL+OEihXG/yPvb5t3KIZfRG9aPLR11voK/+r+?=
 =?iso-8859-1?Q?mEXYksY0VTWBGfGqXgfnB/?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR03MB10456.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?ibo6LQp/izy3ntUh8tLNS535CENi5aR1fdc/avEr4jxaxYH8o5yI3ux2Z/?=
 =?iso-8859-1?Q?VO8IzaS6drbmhLYu8C9qsfPa/9AfTw8NA6W6NFbnNwfLRjqq8poA7jXjaj?=
 =?iso-8859-1?Q?x27b5UbG3AXaTjSHcybnIaG162H93/6TLMKB3q1kPNFLkj96TguqY1o6/R?=
 =?iso-8859-1?Q?bGUczuGmYqBfc9Evry1qbeBqz2fMfwlk14tsoZHzatdhkalpsrcyiXzyQd?=
 =?iso-8859-1?Q?uveXPE5lwNOUNgp8BfsujTifbNina1qXJqpSWXlQ8097n4mTw5hCulPog8?=
 =?iso-8859-1?Q?AB7NbxNbAj3BQUKfQs5ALzn/zmR6VHLsyJQ//xzTkSUkM3MY0YXkSj6900?=
 =?iso-8859-1?Q?ILp0owsd7F3yHcH/xqYPvNf/4Ap8gXRdaYqMzC9zRMVLu15K686C/FzAcP?=
 =?iso-8859-1?Q?jRsn9QIt7lV6JKw2tXFiWIU8AaTm5lzEfJ9ARq0LHCX1yHqo83gtZpqkht?=
 =?iso-8859-1?Q?hyMmrxsUEL86QrhK27losWsF3AiEfPXAQ8uCW4aABgDp3e0nBuknn6Fxsv?=
 =?iso-8859-1?Q?bGIh5PoQkPK93z0mdmFa/+M3uI3/alISKT68vuZ2sAcwxQ+A7pH0tAyIKv?=
 =?iso-8859-1?Q?em+yfKIEadvxnTd7Up5IyOmYTOBZPv228zi94tn34ZJ9n5sWysuV5rsnx/?=
 =?iso-8859-1?Q?Ql95SEEI6MQMst81NbFpwN4khrVii2cHLd8FlQqs3kJ7oQQefB/ZJBFMDp?=
 =?iso-8859-1?Q?a1e99VIfYJ12yZol5mTVDL4Ex4xE+hAPkcuUlCFsRYtj5JavYl4D1N2k7F?=
 =?iso-8859-1?Q?60qO6pc1RfrBZnTWpPl+KLJfr3FYXz6YZteYEEx1lKMJpmSnkLKaQAdwA+?=
 =?iso-8859-1?Q?ugMyO5J1j3Z+N4PwZ7DDAbumS747Xmkolivs+HwGGY9GL7UHlQL66SjG5S?=
 =?iso-8859-1?Q?Us3lnNh5IxCf7iv6JY6XwUwtACYmB6Tkg6JeNArxzAYRecb6qvsOC4cd98?=
 =?iso-8859-1?Q?flW935k977e3k8gisYLeTgYhBhaJoMxi16nPukiIDju1lEvw5QdqZEbUYc?=
 =?iso-8859-1?Q?kelGKO8LczWllS60/AYHCMdzNuIziTwoMLa5fE8jZ+N4gt3Y/l6e3HD9TC?=
 =?iso-8859-1?Q?Wm0Wx0/zpr1qteLLDI+u5XxK8APr+YFvxvMiUGUw6hRMitZhpppTFym07P?=
 =?iso-8859-1?Q?7YPoaP7Dbfu9HFmUYLQdGuDucSnG73V7bpqKu6ezKxmheuxB/MGXwRNooY?=
 =?iso-8859-1?Q?yzxNrPFvAUrghkXpx1xH+xRwhDFkikEgkC7k50wHv9U9TiSpRw+rjf5TBC?=
 =?iso-8859-1?Q?DFf1UgvmszPrIKODCJYecTuITygTt2KmNcVZ3h1CsrkqhAejxiXNjPHQYc?=
 =?iso-8859-1?Q?CKeQlqRyaoTEjqgxNJCVOlYBHUtPGrbHE1tjrXoOX2OfUkUsHWzN4i7jb2?=
 =?iso-8859-1?Q?OE3OZe664CBsQB1bVYnJ1Fp3ohRD3P/Dy4ojWG/3rq+N5/QonFY8DBVx9/?=
 =?iso-8859-1?Q?73kOGvV83yjrShZWgu4U1vk2lV8aGsdEUYCxSWWxbZxMxP+AGrAF1nbiMD?=
 =?iso-8859-1?Q?oA2VnyidisPgUFegG7WWVKTrTPXz/cIDBBbvep95J9dpTAegpub+nCG2/l?=
 =?iso-8859-1?Q?nYPu3ZuSmMMveWaEz0fNHY3JHFQdzdGzMok7He91b8Ir8tXlKUQxV1y9th?=
 =?iso-8859-1?Q?6DlljqgLwDtRY6o7rEd/LBHcLOoLwghh/PwBTISxXGArtpR1vA9eblIA?=
 =?iso-8859-1?Q?=3D=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: GV1PR03MB10456.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 94f90734-a613-48c2-47cc-08dd34538bd1
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2025 04:25:56.6028
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: +lGlImmpjcC2n94+sI9odtBaapSSisdurf1i8RQHmswF74d0JzvhoV5qYBqZ6vYdnTBP4Oc3/c0vzVzQOIh+ER3Sj7foiXWBqOf6AS2c6J8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR03MB6300

Enable previously added CONFIG_STACK_PROTECTOR feature for ARM
platform. We initialize stack protector very early, in head.S using
boot_stack_chk_guard_setup. This ensures that all C code from the very
beginning can use stack protector.

Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>

---
In v4:
 - setup.c does not call boot_stack_chk_guard_setup() anymore, because
   the original implementation was removed and
   boot_stack_chk_guard_setup_early was renamed to boot_stack_chk_guard_set=
up
In v3:
 - Call boot_stack_chk_guard_setup_early from head.S to ensure
   that stack is protected from early boot stages
 - Call boot_stack_chk_guard_setup() later, when time subsystem is
   sufficiently initialized to provide values for the random number
   generator.
In v2:
 - Reordered Kconfig entry
---
 xen/arch/arm/Kconfig      | 1 +
 xen/arch/arm/arm64/head.S | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index a26d3e1182..8f1a3c7d74 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -16,6 +16,7 @@ config ARM
 	select GENERIC_UART_INIT
 	select HAS_ALTERNATIVE if HAS_VMAP
 	select HAS_DEVICE_TREE
+	select HAS_STACK_PROTECTOR
 	select HAS_UBSAN
=20
 config ARCH_DEFCONFIG
diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index 72c7b24498..5cbd62af86 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -250,6 +250,9 @@ real_start_efi:
 #endif
         PRINT("- Boot CPU booting -\r\n")
=20
+#ifdef CONFIG_STACK_PROTECTOR
+        bl    boot_stack_chk_guard_setup
+#endif
         bl    check_cpu_mode
         bl    cpu_init
=20
--=20
2.47.1


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 04:26:17 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 04:26:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870904.1281989 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXYVK-0008Qz-H5; Tue, 14 Jan 2025 04:26:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870904.1281989; Tue, 14 Jan 2025 04:26:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXYVK-0008Qm-Dv; Tue, 14 Jan 2025 04:26:14 +0000
Received: by outflank-mailman (input) for mailman id 870904;
 Tue, 14 Jan 2025 04:26: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
 <SRS0=sZa5=UG=epam.com=Volodymyr_Babchuk@srs-se1.protection.inumbo.net>)
 id 1tXYVJ-0007T1-4L
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 04:26:13 +0000
Received: from EUR03-AM7-obe.outbound.protection.outlook.com
 (mail-am7eur03on20612.outbound.protection.outlook.com
 [2a01:111:f403:260e::612])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id af320c79-d22f-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 05:26:11 +0100 (CET)
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 (2603:10a6:150:16a::21) by DB8PR03MB6300.eurprd03.prod.outlook.com
 (2603:10a6:10:13f::13) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8356.12; Tue, 14 Jan
 2025 04:25:59 +0000
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e]) by GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e%3]) with mapi id 15.20.8335.015; Tue, 14 Jan 2025
 04:25:59 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: af320c79-d22f-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=TSnouGHV/umH4ucsoS7EOUXQE1nqjAB5+yWyt29EwXkyequkZJokk+ZmYXb4DZM37mH5eXQyGk0RvvOmz/N8R3Svxh4ftL7n9WoR+qDlvrHhNoOZZwT+DmjW1cA6WP2DXGBsfPB0Dz31T0p4530AxZqCEvl1X6liAMamSVsVO9tjOcaAFFOd6CRb2wFLiRwwxSAAEAJ65kyOWq9+3KdLBRYw0pTG8WmOifal58VGM+D7WjvwQdXxrgLIXCvV/ZM1GTuf7+nONq3iwLTMZwF8cz7YeRPub+MzRNWQ1SvnWk1BHDbn290/xykPAEepekNlDDrXdToqwao6HpcSz4Ydmg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=Ojki7nJQGFp6MabSULR9hew/zeC1tbVTuB9R0uaCM9w=;
 b=T+ThCKSx37kfsG8zyPOAwJAQwl3RodYQaC834flyQHEgZclGgUTQ0lBnatKDlaewMjZLxYfhJBzZAtB/KYsiapHhjmuNMWFeyW8efr5CtotyckDWXLo/m41dReGcT3wPcZUtd0TPBDU8xoUJoz2TaY0o/TohaqtTTaQmCtNryOBlJ6SQ7SLlv55G+3KsGMpxyhIsPqj3hgrrD/l0vHDUCD3aKZDqhnxmtHbj3Z0H304Kgdgyvw3IquxKC0QKuYGs8zh2Ye3ZvcZrqGsMiRiFGT9MhgWNbWzr3mU4WXvob+YGateBGJ2YDM4GRTtWHEy+px18khLsxOAR+YaB4lqKQA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Ojki7nJQGFp6MabSULR9hew/zeC1tbVTuB9R0uaCM9w=;
 b=o8ZV4NOSIRdWVlmo2KcY1WMFsf142wl+VabodXmTDwrdxoSP4+VRybtln+mZb3QrmqKqSz/jbd03wdUEynz9l4GPdWpT0er9WoeNV443AtpTcmdP3k9K+g77Uzmgtt1JMdG4xlhjIBBxv8hTiDTKg6tOdQsNQkylAtj0lrI1W+G0s9PjN46WpN0xnswfPBe/+KOWtEWusrUjKsavyRu2yQC6nr7Lp4xrL98Tp5JXmGiPti+74e7T0ypwbzPsdfuR/fF9QorMf4L8QW0sQjuUwX/KJA4spHnXqQ+1ZaYjDIly5HaksxMomlTxHnfLT4E6NXeKvcVxmbDEztwKdGLfqQ==
From: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
CC: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>, Oleksii Kurochko
	<oleksii.kurochko@gmail.com>, Community Manager
	<community.manager@xenproject.org>
Subject: [PATCH v4 4/4] CHANGELOG.md: Mention stack-protector feature
Thread-Topic: [PATCH v4 4/4] CHANGELOG.md: Mention stack-protector feature
Thread-Index: AQHbZjxoP9pre94pwUyb17Ngp5RsMQ==
Date: Tue, 14 Jan 2025 04:25:56 +0000
Message-ID: <20250114042553.1624831-5-volodymyr_babchuk@epam.com>
References: <20250114042553.1624831-1-volodymyr_babchuk@epam.com>
In-Reply-To: <20250114042553.1624831-1-volodymyr_babchuk@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: git-send-email 2.47.1
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: GV1PR03MB10456:EE_|DB8PR03MB6300:EE_
x-ms-office365-filtering-correlation-id: b592ae4f-a3b4-4cd1-dbf1-08dd34538bf7
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|366016|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?W5baY+ao0+c7SVyksNryF+SPy4f8HV+NtjpgXuA2tWsdSxnXdqtiBwR5jx?=
 =?iso-8859-1?Q?RnqZICm2Am5VMMv/WJbEhA/BCUBYOqd758ga1Dz13uAAQU4Ab9sHNb1pw3?=
 =?iso-8859-1?Q?KbHgqyMVPrPWbj91WxLeCxHMpnOrVRCEZoB5sTYXuVSGCbp1O1+QZmgXem?=
 =?iso-8859-1?Q?tX/bpw/LjS1kcQaWhjDmYyKwlQaWcQgZ1lCJB/aF7sqytnip3zWjBxGamV?=
 =?iso-8859-1?Q?IEdw7xa3MNOUFBM1SjMxGeSPcTFxZQisl7gR4szxk6UCBMzicYYWo4MF/9?=
 =?iso-8859-1?Q?+X1viIt/rUOVk0FPzVa9cFynCE3+HPGSTeyxza9PVQTCbynJjpSM1J9mJ3?=
 =?iso-8859-1?Q?YToKsw/WsQsITSMncXLL/x1cXoVy6oMt1I5NVgbQZjO+QZJ9rmdSOztWgw?=
 =?iso-8859-1?Q?V+G1dyPUz5jivkHr4veacHwSwt990nM+B7FOBoTNVvz+VIjg0Zf+2Trf/Y?=
 =?iso-8859-1?Q?GNxNVL2i2uIJBaALSOslBlgC31H/SOxWuEArUqMxBmlIZoocIMeKGUDY4k?=
 =?iso-8859-1?Q?Ro6HKNFZAh4EvT+D8ul6BxOJ5wguoSSZ5Wm+lqJdIVShFJHal5wJwYh/2y?=
 =?iso-8859-1?Q?GkyXtUm9qnb6JPXvTnAw0DMKVSoVs4rkSnOrlyDWQbmnWrdwntZmlbMSmV?=
 =?iso-8859-1?Q?uMyAilFrw9/UrhZ1EitVmFaxd0aGZt5AP3Hhe4TzUEjvEH8S185zz/iWvn?=
 =?iso-8859-1?Q?QWk/ZDnzOCjMtuNOh5dV+Z3gZ3ZLve/HBVoP9vP2oVMXg180BL75ZIUPYi?=
 =?iso-8859-1?Q?8iNJdbxtUC49RGyrn7zXUjo8CR1P12Gp4bmPjFKgOjgdB6aZ70m+SaTG3S?=
 =?iso-8859-1?Q?YoptpiDlWyzRe2uIqyc2wSzX/77wqAl/Fkt/DFmKAaFIcnev5m5fX8b2Wz?=
 =?iso-8859-1?Q?C7Pt/KjBW4PKuxSuz2gf2w1URtxk67pbTpMLDuTtQsttxvvo7dbaN2DKbS?=
 =?iso-8859-1?Q?ksOy9VfyGZ7Ve0zLGRmwcjbAsb5tqq/CtzvxmYR0c9TzPXEatmy3KuYYad?=
 =?iso-8859-1?Q?eUweAYlwyH2O71NHjddZ4Jjs/Gh+PEz3i3fpAFqWexr9eMaOWoKcoEdPi/?=
 =?iso-8859-1?Q?gEfituEewWQWCDeakPLgaMV34O6/Haxjp5m95O55DZn7WXcF8yHFKvWvu3?=
 =?iso-8859-1?Q?DLN2I4Bn9wQQrCdjPvFG/bCaEvWybQCG5sAx9r/x7Ex6vDhacA2oIgIVBu?=
 =?iso-8859-1?Q?qnFFn0X4yQRTaZ0a7A91JQMO6oJ3pkryhdBQV2Y/tmTmEcrcm0T8YOUq9R?=
 =?iso-8859-1?Q?qt4t2FYwI3CSwnutGdyEuegoCRtGDfUGx2krCyoAYfsj65D7inWVPKLL80?=
 =?iso-8859-1?Q?aAx4HJpSMY0fFZMkaW9RDI7K6n6YFagBA+pgQ0l3EruZ39v4Bf+u+c/bCO?=
 =?iso-8859-1?Q?8mYKnAjYuIZqbthCCZsDk1wXCPX032sI/+4zcd7+UHbBGBrzsTdbxmoqiW?=
 =?iso-8859-1?Q?dmSr3NIupcjMQFPn?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR03MB10456.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?mpI9arIxDVbscoZdZRiUNb7/xR2jb5cqZidTtdXJoH+B0ZanHKiQLVI39a?=
 =?iso-8859-1?Q?LnN5mJXFq/60gO2L8O64Fzn/I0tINifn9W0Wi3ckurp6Tul2Em86/5JtnA?=
 =?iso-8859-1?Q?4HkZBFid4p/Ra1krzJfWBQKDh+w+p67FXVGLehq25KvherZBGgxUCwl7zl?=
 =?iso-8859-1?Q?JjPCOZRi8XjdpPtbScKVhqh+NR2N87lmo5uDKzdwCDJ5dC5Qtq268yJCFB?=
 =?iso-8859-1?Q?XpzcK1iggP/NRbuuavhhbKV1l0whCeyWiPh6ATMolh2uATTIYIjXlt2pUf?=
 =?iso-8859-1?Q?/SpdiSmQYqc/6udA++TdR69+i9Pjex5HHPWHNk+XfbOwWTphzzbhS4VPub?=
 =?iso-8859-1?Q?zs3jvP2VSZBHa9xvigRJU7zTImOIWyHdQiU7dvztNayBhhkqNkEfp5guiz?=
 =?iso-8859-1?Q?k0YeFqRojdkxQ6TTnhb4oIJAYhXFjTWBE4O9UjfYrCg37WEyWCJ1VQKsAU?=
 =?iso-8859-1?Q?Rk6QhbmAlvrKGWoChhaHSZdUsZJTT348sP2Vgoson9xU/hNkmAV1rHuYwo?=
 =?iso-8859-1?Q?K0HtEO1Bpj2DJSkO1FqVrI+4cYhcK8YVa+BiUgzdC6HvD/riN2XRsstnkB?=
 =?iso-8859-1?Q?Y3suEIpRHtOXhhDmeAhGlT+ufCVVII6CYde7o43su+VXJ3dpVzzPDHGGdS?=
 =?iso-8859-1?Q?OjoDi5cNTN3us9gtX49jaVjZGFGINlwl1Z2eo2U8zbIklmHvGOT74LAmkD?=
 =?iso-8859-1?Q?LLAlD9XRSXIlE8wukHcaLe309eK17g2awBOWTiFRe4BqiH0mq2ALlsm3Xm?=
 =?iso-8859-1?Q?wZ/IhQo2sY250q3Fw9YjZ776/WyBlk+yqaItf6sFz4nqjJ1oYwSJ4v2A7h?=
 =?iso-8859-1?Q?3pJRs0A52Tla7hVaBIZpwTIup/DSI5Q+DlAqDxKGHKUQjuUHBMmuJlDBzM?=
 =?iso-8859-1?Q?fNypPjU00WOHldTDLics4FCmfmuKOV8x0ogC5zh90Q2400kJjZzpe+Ezp1?=
 =?iso-8859-1?Q?+AS+iPwf9bYXoF3lzOqS8duYOyNEdD/pMtSQ1t2I71SWuWznCATkRWsbqD?=
 =?iso-8859-1?Q?xYbTHMfYnFBiEgt8SLfPlcpmjMQSh3zaE+T8MJPLRymOvWG6iDZdN+nm1B?=
 =?iso-8859-1?Q?252fAzmnjehHajYfmfR61z355HzAqlNc1r8GI96hHLZ75ngosvj9dDAGhD?=
 =?iso-8859-1?Q?gnNLtrliFCjvsSYemN6L1scVCz4vZIOzmN2sB5M7DbB/Ye0LebMayV07ou?=
 =?iso-8859-1?Q?QB1+Ayy/U+ZmZoQ4uFPOoqNCKQyN6gVveof1qAK1DkjZZAOklomHiibLFQ?=
 =?iso-8859-1?Q?r8iVSyKW9ewUWkLRFGeZ3cny/MiwubQyvTY4ghO58Sxints4TKOSxjAJs9?=
 =?iso-8859-1?Q?CvLHZX4H2hdQ1B4CZdEWSjQP4/IzOLeS/CAnLhSSzGnOv5miD+SSn2XwlG?=
 =?iso-8859-1?Q?1eYW0O3R9mByHmmGHybfBOD4xKUJY4mZXRKrxskGSOpOd4WLfUfrW+f1lT?=
 =?iso-8859-1?Q?ly6iX80xipWfIk/VxpRZ56nnv1QryMyL0NiJZWRIZFDwyzJamaMBCxFzB7?=
 =?iso-8859-1?Q?vERaCzyWokQIy1deJ46fdR6zMBV2KfuB2vibAa9qclIXeIoPZF3oxfg3Wz?=
 =?iso-8859-1?Q?p9MDTx8Lx0E1msQMSbZiDEiXTCv8+JgQYC/wKBvr8VtFt9Q4C5plIO1roq?=
 =?iso-8859-1?Q?eKShlov15ZUPC2GIKMTK2BA5Rpv2xtf5p84WAugaqD+otYh/tEHPl3iA?=
 =?iso-8859-1?Q?=3D=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: GV1PR03MB10456.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b592ae4f-a3b4-4cd1-dbf1-08dd34538bf7
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2025 04:25:56.9105
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: TEKMDAKVKMjmMFf1NHIGcv8ncuv8qCFJMhXIm3f8MOkXw7863yGYfXrTUsviuYpqkUZGjl6IJLBJBYna8mdhsGlf4zKAkQhn/AnjbV6XwVM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR03MB6300

Stack protector is meant to be enabled on all architectures, but
currently it is tested (and enabled) only on ARM, so mention it in ARM
section.

Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
---
 CHANGELOG.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 8507e6556a..62e6c26aaf 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -22,6 +22,7 @@ The format is based on [Keep a Changelog](https://keepach=
angelog.com/en/1.0.0/)
    - Basic handling for SCMI requests over SMC using Shared Memory, by all=
owing
      forwarding the calls to EL3 FW if coming from hwdom.
    - Support for LLC (Last Level Cache) coloring.
+   - Ability to enable stack protector
  - On x86:
    - xl suspend/resume subcommands.
=20
--=20
2.47.1


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 04:26:17 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 04:26:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870903.1281976 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXYVI-0007zw-81; Tue, 14 Jan 2025 04:26:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870903.1281976; Tue, 14 Jan 2025 04:26:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXYVI-0007z2-41; Tue, 14 Jan 2025 04:26:12 +0000
Received: by outflank-mailman (input) for mailman id 870903;
 Tue, 14 Jan 2025 04:26:11 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=sZa5=UG=epam.com=Volodymyr_Babchuk@srs-se1.protection.inumbo.net>)
 id 1tXYVH-0007T1-O6
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 04:26:11 +0000
Received: from EUR03-AM7-obe.outbound.protection.outlook.com
 (mail-am7eur03on20612.outbound.protection.outlook.com
 [2a01:111:f403:260e::612])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ae50ecf2-d22f-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 05:26:10 +0100 (CET)
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 (2603:10a6:150:16a::21) by DB8PR03MB6300.eurprd03.prod.outlook.com
 (2603:10a6:10:13f::13) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8356.12; Tue, 14 Jan
 2025 04:25:58 +0000
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e]) by GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e%3]) with mapi id 15.20.8335.015; Tue, 14 Jan 2025
 04:25:58 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ae50ecf2-d22f-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=CNXFYZv/i8RoY9DhK1A9DrY4pdXJC1Iapr7z3cc8RK2kZ2J3kPN50KDRnd3UW5VbxLVqDJF5DxIjxlgqrckFs61qOAbY3PFpCTIqyXZ6Jy0uy3pE7Vbs9VD3kIkjkqfgyDmNEM2AYXXalMQuuKtZaHCTSSePJhv0bSRrHFRKHCA2J3FXKZszxVrPvteXwFmi2dMT2aTESpaVENoHSGueuzM9bpobDWBy9jaegG3sMixrX+SdXq8I5r7gvVZAyFjeJWkVuZFLOA2FvIOUnFR5EQCFDACbE6nVTBKgj21mXi9xtrH9olZrkbTic9aZnVFD3YdjwWgxEDoieEY2uemWsw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=F7CrkfKLq5jOHyUUc5QDVCpbIzJ4tC6vRwCVPj0QO1U=;
 b=LDR0TqthiVKH52S6P3gPieScKBeTAJLuS+swq+eSzT7mJeLrCkxZVK4aXmEbUl7ldnGY3zdfFo6tEZASPtL+DDq+PhDmsJuuypZH9+qBmT+NW7LaYLT6Ub5fUsV0QBaz6CEUy2eFh/QwZnUi2LcRi8UwA0KivmtipxwatO7OdZTShyVw8WKGOu2zuIrxD1eAN8X8aWvAFcov+41+n6Po9Khx0aqA/UZC9kXzAXctfPyfDIg3tKlHKtA2zAkOTUe86Ql9YS+orp+tFJNRcN3vOkDR4ZS6Y/OJ733kn3tj66b0yF8DIRFtIldBkkObqXFEgUgR6+syLrM5NdFXtYL9bA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=F7CrkfKLq5jOHyUUc5QDVCpbIzJ4tC6vRwCVPj0QO1U=;
 b=Yn9+xYbbUUVHjoYYDr8g4znus83Mz4T5tf/U07jT5qWt4N5fk1665Ium68fQzpIoyNKvOTgxDaP28hPCcS3MDImyDlt4NvBM+ZBV7Z2Swtu8fmUlaaZA/qInRDfNVq+EyEBvc0VzudQpC+2xh7nuoniHwLzyMbxfK7c67MMooNzzqLRGiCqRy3nNOAsQkBJuQ1EZ7+xVjnkmuZ258/jmeoTf5E8zjzPCx5NJMawa1z2zC4qoGQi9tf2vdDmGElwgNyh5pQ278mjvZblMJuqoXmi/7b9/rM7kcqJSqf/NtbPnvpfqIXPrMukyctYt6RCmxZyCTpDVNdYU3IRMALb0ig==
From: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
CC: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>, Andrew Cooper
	<andrew.cooper3@citrix.com>, Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>, Julien
 Grall <julien@xen.org>, =?iso-8859-1?Q?Roger_Pau_Monn=E9?=
	<roger.pau@citrix.com>, Stefano Stabellini <sstabellini@kernel.org>, Samuel
 Thibault <samuel.thibault@ens-lyon.org>
Subject: [PATCH v4 1/4] common: remove -fno-stack-protector from
 EMBEDDED_EXTRA_CFLAGS
Thread-Topic: [PATCH v4 1/4] common: remove -fno-stack-protector from
 EMBEDDED_EXTRA_CFLAGS
Thread-Index: AQHbZjxnmljcDXAlQke3Qcb/enjdIw==
Date: Tue, 14 Jan 2025 04:25:56 +0000
Message-ID: <20250114042553.1624831-2-volodymyr_babchuk@epam.com>
References: <20250114042553.1624831-1-volodymyr_babchuk@epam.com>
In-Reply-To: <20250114042553.1624831-1-volodymyr_babchuk@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: git-send-email 2.47.1
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: GV1PR03MB10456:EE_|DB8PR03MB6300:EE_
x-ms-office365-filtering-correlation-id: dc1d4bfe-8639-42de-07d5-08dd34538b89
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|366016|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?+beGIrg/eSZhYUmXb9AHSpzeS0Sx9usP25oSeUHNwkRBHLBkJs9qCRscvK?=
 =?iso-8859-1?Q?4+6Ba6NcKan/W4mQjc6GnS/gX17ZIuHx/Do6QhAB+rHyaCtUPw6nI1DLQI?=
 =?iso-8859-1?Q?Xuaj10RP0+LngF6IkhmoCw4Nv1f3aJcpZMIpmNUxTO/AfGI70l66vc2Kou?=
 =?iso-8859-1?Q?8FHgghsAqVj3gfohzR8UvmQueQbxtlaL0dMWiEctHCz9DqDCuRkOUd6btU?=
 =?iso-8859-1?Q?50IfXICBI2lasIDtj8cbHF9G7s00WhcSjVsld2IL7nrtFvzULsiefnX2wU?=
 =?iso-8859-1?Q?vFVZM5nQmSrXZDoFFqOWJO9wT28sBgetWRRRJgTO44j8rzHuj+i3iIt+cz?=
 =?iso-8859-1?Q?8KjDVTCStyOqrU4qPXBTFqlHLp8TIenapkvOJxz6d5M9XnGx+ClY6AqmS9?=
 =?iso-8859-1?Q?jtgUQz6QIrA1eVb1X3Chv1Zbx6R8C4atjsnPt/0/TC+hwZpQPj6d8MG9PT?=
 =?iso-8859-1?Q?ZQJM0s0L+zPn5suO6u3Gaw05NOXpqbcYTMj7ci5flmgN+k6Cj5ws24HSb5?=
 =?iso-8859-1?Q?rfCYHcaC1xgqSpBQlhCylm5jKuAvCLIOSAdK5r+GWXFhlF86t3gTYPsJVA?=
 =?iso-8859-1?Q?TETeQiTAY8kreFyb91E1gh4GpY63ahWAvCJWYw5tHUMHVqECitSxs+q7bi?=
 =?iso-8859-1?Q?hU4LaPwSKnfPGQqZ/507Dl9zlBRYpPr+Ug57NfEMZ79eTjUpm/BSz667pA?=
 =?iso-8859-1?Q?JMbuQLZVTJS/1mJ5cnEZ79mQgDI6UIxe5lXza0ZrkZJaSuAc5xgQ7ZQmpW?=
 =?iso-8859-1?Q?qAwJ+/2465YKiLNZ6xWmzFiEclvCuPRi16UvMsziDdi0JLZh238Wzr7JCD?=
 =?iso-8859-1?Q?Xz4YLMulmNCDnSMNYxPPCeOFgq5fQ9HfAOfFpS+CQhagydRMFy8JmDijA2?=
 =?iso-8859-1?Q?ZnVvUHFw8j6btnb3x+tUALI8xSuVszBpw22zmMRfHMYvL2Kwe08bzWRt1T?=
 =?iso-8859-1?Q?2MNCs3TK+mZzxGiHF1+wE2hkifppWWHgLIwN6vVSUxY8pD/xer6AVrElOA?=
 =?iso-8859-1?Q?9P4oo4vKANGOFLUrSpbeoV35E3vjQh0IgMFxEqMKhYhrH6SeGvF6F1deg8?=
 =?iso-8859-1?Q?ABvBQFbF4P4so/1Zr8Cqe9OctyoU6Qp3VewaQ9dmrLGJC5cKisiXtVtH/J?=
 =?iso-8859-1?Q?t9fSeGtOaEMAmxtsVkzGqKNSf6pB/8W0HhjdUiztKFlmAVWSSwhNGAVpJP?=
 =?iso-8859-1?Q?nZudxmYCH7G5Iu87uV5d1TXNsgdD+G0rHddhmcj4JQ4xln0uPF2pXExYzC?=
 =?iso-8859-1?Q?kjWHe3qXylAPcPe3x930S/JRBKcTIGGds02ONw0bKwJS8hTk/qhxDdPs62?=
 =?iso-8859-1?Q?pYauwalBMMXyn7k5N4zagHJH506Bkd27cGEpkG3l/x7Wd/TeLPgsIcCHxY?=
 =?iso-8859-1?Q?b3L+kV/VFoKUoS9sRMXIYjyYRLZIGHT76WbwSAuKlA33immx/GrHEAtX+8?=
 =?iso-8859-1?Q?XgW9XG4afYassLJC6qGCisNg4zZWNnxMQ0FzVw=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR03MB10456.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?L5wvyISKyJDkP5EF9DgmylbMPPeCpLh5QSGlutY8iOkAFzxpp9FWMIG/KL?=
 =?iso-8859-1?Q?7p5f5egBQKlC3rWHoxaOqr4nihPVv8beG+oX5fQ8bcRkAT4Ge/IJVHWWNB?=
 =?iso-8859-1?Q?MwqqNN+JwFo/yqN+CVCp3hL+VsR5JVhZqe0DxkMfSbbXhnmDPQWN/2tiJQ?=
 =?iso-8859-1?Q?nYdhlknWUzQKWpQK/5m962wYBzkRnBXZsmhmt0/twcBlbspiI9Cs1/XZg4?=
 =?iso-8859-1?Q?08b/vBS3innEUKr2pyWdGg6H+uyKFstrBav2suUV3e+HfK2hQR1H7yuTVa?=
 =?iso-8859-1?Q?ntBjNJl0U1WzHvI0qSl1eAr7JYPm8rD7OwYAsf5dvDAsMe7L8ZNYJyKTYj?=
 =?iso-8859-1?Q?pvEvhP4/qItdBZlUhccxejAA2iTLvnUWVoSNP8wPvGj3sgsmscLbge+KvD?=
 =?iso-8859-1?Q?a/b6vEb/S6yXjTHxuxdYjdbd8VvpFbMMQO/bfiU3KRJfnhRhlJYe1mxH2T?=
 =?iso-8859-1?Q?kvMDzm9T7ys6f9bDU3b3LNl8A4v4nuDL+ie09kinsmHmMkRID+yuMR37wz?=
 =?iso-8859-1?Q?sk5Gt0oI/P/c0R/C+qqli4Wq7JR+751bXDTfuwn9NK1x6JezLYuh4joM2T?=
 =?iso-8859-1?Q?fmh07Erl9EXWkSW/tkx8hp3w4mAWIj5xptNBlnGPQwvhORqjN90pzn7KVP?=
 =?iso-8859-1?Q?WZ3wWKQWBUlFZm8RMC2ZoMO5VFeSj/wuVEMbBrgPx1l9cKxsjM9Ic3AL5V?=
 =?iso-8859-1?Q?yElYs8UifwmAcONicjjAGZC6qhcKXiogpmi6z2N+AJQ/Pp7r25KCPxrbyU?=
 =?iso-8859-1?Q?BBS60jMKgffYdmDjShq9VgKbwton805mn2ZyjD1ItAWPR/S/xF6/fgnpDE?=
 =?iso-8859-1?Q?PKRXpaN8Sj3psJQixuJGwFN0tmHGddLn2iyIDt1Bn6vOZ19+jPk0OgdADr?=
 =?iso-8859-1?Q?7Bb9rdvV/zcM7fRFBU5PFUDo6TstOO3VK3nRFYxP9bAsqL/NdRLSjHLF0s?=
 =?iso-8859-1?Q?gknzs9YZnz9rBhEPAneaz77SNsQEo/KsZiL6xX931Eoz16hJnUKLHcw8l1?=
 =?iso-8859-1?Q?gOol8qpObSg2iCvFFH+lTIXR2g3SZ7tfm4bNTwv9/5XuP0qKiWDbPAXdJU?=
 =?iso-8859-1?Q?t1s+LZusLchtJRJBuPtWiHY/Fz7HaTkdL17H5NjO0RfTmjeAvaAU/2AfzM?=
 =?iso-8859-1?Q?FlD6vimnSlKCNXwHc1FH+EOrcsBhL5e5Ex5Gg9e6nYXsxaqk8HtcjOL+z9?=
 =?iso-8859-1?Q?0XKWvmNCa3sJnZkFVI+oPR1y120gLniOdJXLwaRrvUZG/QkuUazSD/I3/V?=
 =?iso-8859-1?Q?TBrW94sjXVkH1qJAUn6f1+Dz9pBiYzjvoU5AQZ1hp7DxTysb06HCEakc86?=
 =?iso-8859-1?Q?83Ywyp+hdtM+PQL0RInF16Qwaj6fV6ozwjnvhT70RfEWEupr0xkGNjsrRi?=
 =?iso-8859-1?Q?WmlvHVGLwhlQZUodj27VauuOz1Q/JKoWLS4DQ9hmZhHdonJSfUo8+trICx?=
 =?iso-8859-1?Q?l4JqL8wcTx+OsESg9xsnleHRT+Er/tjw3hgLtrunNdF+9nEwSfWeVaN4F5?=
 =?iso-8859-1?Q?qvB8d8ILVH6stqYShRj+jfo+ZhB3t+pl1T+3YH93T5ufPD3nO+tYozFQE2?=
 =?iso-8859-1?Q?xKW/WM2VwBrlwEnu9TL6LJ0jNdW73GHo+H95eJ3/napLoKbmvf3v4VWCC9?=
 =?iso-8859-1?Q?8zBUsL8/q+O3SKi6/Kdk2SeCdQtcgQk1jNclFM0Loz6BBkLVmWab25YQ?=
 =?iso-8859-1?Q?=3D=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: GV1PR03MB10456.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dc1d4bfe-8639-42de-07d5-08dd34538b89
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2025 04:25:56.0171
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: SGhmTuRTaWRYryxHSbYKorYCgpSz2uR2NhfXEYeZLtfCB0vw9DL5a9JxUu89Qi2/dFm0fA0nFPc85AdX2QK6rldFn5uWrcPU1CDq0ZQguec=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR03MB6300

This patch is preparation for making stack protector
configurable. First step is to remove -fno-stack-protector flag from
EMBEDDED_EXTRA_CFLAGS so separate components (Hypervisor in this case)
can enable/disable this feature by themselves.

Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>

---

Changes in v4:
 - Removed stray hunk
 - Added x86_32 CFLAG
 - Added Jan's R-b tag
Changes in v3:
 - Reword commit message
 - Use CFLAGS +=3D instead of cc-optios-add
Changes in v2:
 - New in v2
---
 Config.mk                            | 2 +-
 stubdom/Makefile                     | 2 ++
 tools/firmware/Rules.mk              | 2 ++
 tools/tests/x86_emulator/testcase.mk | 2 +-
 xen/Makefile                         | 2 ++
 xen/arch/x86/boot/Makefile           | 1 +
 6 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/Config.mk b/Config.mk
index 1eb6ed04fe..4dd4b50fdf 100644
--- a/Config.mk
+++ b/Config.mk
@@ -198,7 +198,7 @@ endif
 APPEND_LDFLAGS +=3D $(foreach i, $(APPEND_LIB), -L$(i))
 APPEND_CFLAGS +=3D $(foreach i, $(APPEND_INCLUDES), -I$(i))
=20
-EMBEDDED_EXTRA_CFLAGS :=3D -fno-pie -fno-stack-protector
+EMBEDDED_EXTRA_CFLAGS :=3D -fno-pie
 EMBEDDED_EXTRA_CFLAGS +=3D -fno-exceptions -fno-asynchronous-unwind-tables
=20
 XEN_EXTFILES_URL ?=3D https://xenbits.xen.org/xen-extfiles
diff --git a/stubdom/Makefile b/stubdom/Makefile
index 2a81af28a1..9edcef6e99 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -14,6 +14,8 @@ export debug=3Dy
 # Moved from config/StdGNU.mk
 CFLAGS +=3D -O1 -fno-omit-frame-pointer
=20
+CFLAGS +=3D -fno-stack-protector
+
 ifeq (,$(findstring clean,$(MAKECMDGOALS)))
   ifeq ($(wildcard $(MINI_OS)/Config.mk),)
     $(error Please run 'make mini-os-dir' in top-level directory)
diff --git a/tools/firmware/Rules.mk b/tools/firmware/Rules.mk
index d3482c9ec4..be2692695d 100644
--- a/tools/firmware/Rules.mk
+++ b/tools/firmware/Rules.mk
@@ -11,6 +11,8 @@ ifneq ($(debug),y)
 CFLAGS +=3D -DNDEBUG
 endif
=20
+CFLAGS +=3D -fno-stack-protector
+
 $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
=20
 $(call cc-option-add,CFLAGS,CC,-fcf-protection=3Dnone)
diff --git a/tools/tests/x86_emulator/testcase.mk b/tools/tests/x86_emulato=
r/testcase.mk
index fc95e24589..7875b95d7c 100644
--- a/tools/tests/x86_emulator/testcase.mk
+++ b/tools/tests/x86_emulator/testcase.mk
@@ -4,7 +4,7 @@ include $(XEN_ROOT)/tools/Rules.mk
=20
 $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
=20
-CFLAGS +=3D -fno-builtin -g0 $($(TESTCASE)-cflags)
+CFLAGS +=3D -fno-builtin -fno-stack-protector -g0 $($(TESTCASE)-cflags)
=20
 LDFLAGS_DIRECT +=3D $(shell { $(LD) -v --warn-rwx-segments; } >/dev/null 2=
>&1 && echo --no-warn-rwx-segments)
=20
diff --git a/xen/Makefile b/xen/Makefile
index 65b460e2b4..a0c774ab7d 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -435,6 +435,8 @@ else
 CFLAGS_UBSAN :=3D
 endif
=20
+CFLAGS +=3D -fno-stack-protector
+
 ifeq ($(CONFIG_LTO),y)
 CFLAGS +=3D -flto
 LDFLAGS-$(CONFIG_CC_IS_CLANG) +=3D -plugin LLVMgold.so
diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
index d457876659..ff0d61d7ac 100644
--- a/xen/arch/x86/boot/Makefile
+++ b/xen/arch/x86/boot/Makefile
@@ -17,6 +17,7 @@ obj32 :=3D $(addprefix $(obj)/,$(obj32))
 CFLAGS_x86_32 :=3D $(subst -m64,-m32 -march=3Di686,$(XEN_TREEWIDE_CFLAGS))
 $(call cc-options-add,CFLAGS_x86_32,CC,$(EMBEDDED_EXTRA_CFLAGS))
 CFLAGS_x86_32 +=3D -Werror -fno-builtin -g0 -msoft-float -mregparm=3D3
+CFLAGS_x86_32 +=3D -fno-stack-protector
 CFLAGS_x86_32 +=3D -nostdinc -include $(filter %/include/xen/config.h,$(XE=
N_CFLAGS))
 CFLAGS_x86_32 +=3D $(filter -I% -O%,$(XEN_CFLAGS)) -D__XEN__
=20
--=20
2.47.1


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 07:12:19 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 07:12:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870952.1282000 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXb5n-0005qN-9M; Tue, 14 Jan 2025 07:12:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870952.1282000; Tue, 14 Jan 2025 07:12:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXb5n-0005qG-5T; Tue, 14 Jan 2025 07:12:03 +0000
Received: by outflank-mailman (input) for mailman id 870952;
 Tue, 14 Jan 2025 07:12:02 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/Vp6=UG=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tXb5m-0005pu-B0
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 07:12:02 +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 d904c8d5-d246-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 08:12:00 +0100 (CET)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-436345cc17bso36502115e9.0
 for <xen-devel@lists.xenproject.org>; Mon, 13 Jan 2025 23:12:00 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a8e4b82ddsm13921368f8f.71.2025.01.13.23.11.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 13 Jan 2025 23:11:59 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: d904c8d5-d246-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736838720; x=1737443520; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=t0Hp/Kam9LQwJSG67zKI1k1XxiCYOfg5B6NKJoLfhlg=;
        b=Bj4QHmiCIvg5mj63NHnA//SN9TFBK5jRFNrJ891aSDXxUNNVlDwxS+vifIMC+EJ+GM
         7h/3F2aYMsdMLgZLyHgGxamkP9xmCf6zKnZO+V6lF7pAX/MZovCRw7SzsMIOAaOG6S64
         z9zWEnT7nstge1va55v4LhaKEwHPSdr/jjy2azo6vbuogZSo7dPyOThuXKvjfgMGs9fC
         CgYs5AjuLax/wWgnyIeu2zq8iNP3mNx155n0VtABvDaW/FftU+JivzrlDEP+wnd02tzO
         1yIm2kkg5G2fdylgxDbM7JrPY2NKeqxKM3yAq8GtqnhxvdWoIeVya1v83zc3jyqQ2j5c
         2sNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736838720; x=1737443520;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=t0Hp/Kam9LQwJSG67zKI1k1XxiCYOfg5B6NKJoLfhlg=;
        b=m1qMMP991IqCHvBDfxRz7p9X4TuChnhc82sgQthb99iLkiZVl5J8oMbtqd4K8t3oaM
         MSKka/0gWv4NlD9Yc9HGVQwamCGBX4QTSZZ8cn4e5YSBpxC/iEX/mrN00xCeIo6uJZg9
         lvJN+5rzRS9kFgmdGXSKi4PRadW/ItZKHtbZVRbnCGPL58mPBzdxiDPkUlF1pumaxZz+
         7HPJup+buuDg1p99Whv+p4AxcIE4EZRH53bHaxKzkqAyPpGgyoP4bbWGQoGuRWpTGVXQ
         rw7jSC/9drVTwj+7PE9u45NMDWj+TXsggwS5086Ksp5cRNg/WmN25RGSuO3aDN38m87m
         kfVw==
X-Forwarded-Encrypted: i=1; AJvYcCUU85RejebGYq/KDZ9o+BAPDCzJApMGOcgxOGPfQuII1xEqE7OM8xS6fiFeSE3PFI/V4G1vamo3TjY=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyd3yqJz4PRr7Hq3gZm18/YiEdmuu60LIduXVh8Tnfm0nTVFwL5
	QZ9B+8oerL0aw+C4y2EG9pz5reU6Hqa0ToRswc0PGr12+7H+ENH00rCtgyqPsw==
X-Gm-Gg: ASbGncs5kI90lgI1+l7Rd4GJGGWVur1xeuXoDJDqqjGjwAM2B6NBJHqNetUZWqKAxEA
	qmYU2HSHKyf1AtA42QaEUJ0T8XWXC3VwgA1C4wCOzOy1bImEgfjRlefOJR4WXav3H83yRg6HPXa
	7OMECAhdDRvQT8+eLDyRPQx1aR4OGJD78GHNS0vdpHe2wAiprKTj+Y2EFIaaO3h/L6vcBluoEwr
	2vZUuNnvji/zdYhgPZbrnqPQwXgn3zLYtslHfz5ShtyOwDSQzEVpoPLlWo0mOl3uiCag0lfBlb7
	L9mjx8GU7PVVpgeICAWtvKsRVa6cqXZeFe3s8XRz4A==
X-Google-Smtp-Source: AGHT+IGCLfQ97jTKrIjqc96yNUowEbgezwUf0gmYNLPk65kq3/+zsHp9GtmYC3n+TqYuSRqD7qebvg==
X-Received: by 2002:a5d:5889:0:b0:38a:a074:9f3c with SMTP id ffacd0b85a97d-38aa074a517mr9140082f8f.16.1736838719938;
        Mon, 13 Jan 2025 23:11:59 -0800 (PST)
Message-ID: <91ec5be2-d229-4d51-974a-821d75f7250f@suse.com>
Date: Tue, 14 Jan 2025 08:11:58 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 0/2] x86: Add Support for Paging-Write Feature
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: =?UTF-8?Q?Petr_Bene=C5=A1?= <w1benny@gmail.com>,
 xen-devel@lists.xenproject.org, Alexandru Isaila <aisaila@bitdefender.com>,
 Petre Pircalabu <ppircalabu@bitdefender.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Tamas K Lengyel <tamas@tklengyel.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>
References: <cover.1735837806.git.w1benny@gmail.com>
 <4eea61a2-cf56-4ff5-8c43-58f5a20c9cb1@gmail.com>
 <CABfawhmHK_Lg8GuVr9yb1gw82YFs3e1gh76azzH8C98R552dSw@mail.gmail.com>
 <333f50dd-927d-43de-8b49-6865648a9ec5@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <333f50dd-927d-43de-8b49-6865648a9ec5@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.01.2025 18:18, Oleksii Kurochko wrote:
> I would like to kindly ask the x86 maintainers for clarification on why 
> this patch series was not merged.

v1 of this patch was submitted on Dec 19, when patch submission deadline
was Nov 29.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 07:33:21 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 07:33:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870966.1282009 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXbQH-0000Im-VF; Tue, 14 Jan 2025 07:33:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870966.1282009; Tue, 14 Jan 2025 07:33:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXbQH-0000If-S7; Tue, 14 Jan 2025 07:33:13 +0000
Received: by outflank-mailman (input) for mailman id 870966;
 Tue, 14 Jan 2025 07:33:12 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/Vp6=UG=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tXbQG-0000IZ-JA
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 07:33:12 +0000
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com
 [2a00:1450:4864:20::333])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ce58ef38-d249-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 08:33:11 +0100 (CET)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-43690d4605dso35417605e9.0
 for <xen-devel@lists.xenproject.org>; Mon, 13 Jan 2025 23:33:11 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a8e384f2bsm13964255f8f.41.2025.01.13.23.33.09
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 13 Jan 2025 23:33:10 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ce58ef38-d249-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736839990; x=1737444790; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=t6gAc1nzclt8QkVWMOrljaOOgl/BW7FUR1b0XE0EhEQ=;
        b=EgjgG/lgmONZpxQDOP6xrUGTSx+CqYyU5DGNl7FqUu0uHrYIwYKrw221cuxJYPSP5W
         fBxJWIAC2qJanrsZCW/NVUQDmlzbidNJG8t3ZJs+l5aawVc//LK14C+XfIztxJWM0jtP
         ucpIkwfpYnoleo7gRQHmDcD8a4a6X/vx6YxO9YhLV2XUE5VvXOVt5eF6uXF2GB7W7EFY
         ROEoolAp7om7haIILgGLMILDgj+fJmBIQB6ruNr1Tuyefqr1z74qe7yezhPUfhFW3uid
         nebtwKT9da4L6I5JnDNqQzhH6IRBhSfkbqv1Zgv9qi/8MTFu6I6VQYBytKGx1KXlqfRL
         CkJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736839990; x=1737444790;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=t6gAc1nzclt8QkVWMOrljaOOgl/BW7FUR1b0XE0EhEQ=;
        b=wP39q9XBXI/YJ3AQDXACtE9azqqVA7yPxxeTIyAbIJeHeHxfg9em3GUzfG7zRLk+yR
         BXByUUQc+XEhHv2uruNV2pMAQ2Ssz/wIWnBvGHgYwJZi7AaQLRGRWr7AAnZmuPzMWVFA
         PFK79SAtRB11QBXZRqTrAy9Mvu9g58ofIEq7VWzDB2Ifu+QDJYyG5KC4zHwD/AnAJK7I
         06jn7MCToKCAe6TqDxqFla9rjRq6i2J6wmE3lPavrdA/6wk4gxcj4VZANElRG8xoztJf
         RTUYWc4qvHKUkWaTpdI5bu67P45cIgyjOXHsDrex8WL5hM4KLTdiaqBZgmEMEsnP38DI
         l0BA==
X-Forwarded-Encrypted: i=1; AJvYcCWV7FOQlbn+ARUb9cXXpHe5TmAgwjYWrMCMZCSarx2JuQSdLAlzVlv1jzR6qf2Vv7bQy2QUmD52PdY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyFq6G7rL11m4RvopIiqtLKSnEbYBMfBHDlhFpEV3HlFLl49ZEM
	YCP5AFLFjaAhYz8xMzE6GP3/x5G7/qw+fV09MjvDSLGHcfQIsZP4XK5WpTGKIA==
X-Gm-Gg: ASbGncvf/TXjMlP7ImWsql5YvNd57zUmFVE4Us2Nmm5tfH6CUMD1xpcmzAyrzp61fdm
	R0CUxIn91IBhLngrVLEK0NIBJfJga4bJzw/Z/a2ZouTMhLeQyMG1tg7RT69MmPWQv7NJmYXVyO9
	FrQGE6hDa2KesyTEAkC4P4SMCa29fpvH7hNQGJVGPNToNR74KF7ZZzjnLoacQJrSo6wKi7knxJI
	Am3kEIx8vXEvjKRTj9Lqp5ANGQs4MUKeYMuYzIyeQRZy1ju3A0bptkLthimLVbtbRrzdVYvQMTU
	240VcL6zWEJhbHGQhK8zgiYIdQF6L2A+6+KCsCq7vA==
X-Google-Smtp-Source: AGHT+IF0ApxWrg+S83fw00fBEKPKbmp4S6VuffQGwuQp0x/o461SeAZaBdG85GqaIfbClRIDdauwSg==
X-Received: by 2002:a05:6000:144d:b0:38a:615b:9ec0 with SMTP id ffacd0b85a97d-38a873122edmr21740452f8f.54.1736839990481;
        Mon, 13 Jan 2025 23:33:10 -0800 (PST)
Message-ID: <7cf45091-bf3f-4497-a6e2-72571d7e745e@suse.com>
Date: Tue, 14 Jan 2025 08:33:09 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for 4.21 v1 1/1] xen/riscv: identify specific ISA
 supported by cpu
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Alistair Francis <alistair.francis@wdc.com>,
 Bob Eshleman <bobbyeshleman@gmail.com>, Connor Davis
 <connojdavis@gmail.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1734957957.git.oleksii.kurochko@gmail.com>
 <ee14c485c6c6402a2d1706278b21bf3fcf821af9.1734957957.git.oleksii.kurochko@gmail.com>
 <bc636259-5586-428c-8a57-f97ba16a14b8@suse.com>
 <255b0079-4516-404c-81c1-a49e6f7bf5b4@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <255b0079-4516-404c-81c1-a49e6f7bf5b4@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.01.2025 18:11, Oleksii Kurochko wrote:
> On 1/8/25 4:21 PM, Jan Beulich wrote:
>> On 23.12.2024 13:55, Oleksii Kurochko wrote:
>>> +struct riscv_isa_ext_data {
>>> +    const unsigned int id;
>>> +    const char *name;
>>> +};
>> This is odd - why would the id be const, but not the name? Thus you
>> require all instances of the struct to have an initializer. The more
>> conventional approach is to apply the const on the instances of the
>> structure (e.g. as you already have it for riscv_isa_ext[]).
> 
> Agree, not too much sense to have const id, but not the name. Then it should be also "const char * const name".
> 
> Lets follow conventional approach and declare riscv_isa_ext_data structure as:
>    struct riscv_isa_ext_data {
>        unsigned int id;
>        const char *name;
>    };

Yes, this is what I'd have expected. I'm afraid ...

> name member of riscv_isa_ext_data structure still should be "const char *" to avoid compilation error:
>    discarding of `const' qualifier from pointer target type.
> 
> An option could be to have a case in macros RISCV_ISA_EXT_DATA():
>    #define RISCV_ISA_EXT_DATA(ext_name, ext_id)    \
>    {                                               \
>        .id = ext_id,                               \
>        .name = (char *)#ext_name,                  \
>    }
> But IMO it is better just to declare riscv_isa_ext_data as suggested above.

... I don't really follow all of this. It's clear though that the (char *)
cast is a Misra violation, and hence anything like this is out of question
anyway.

>>> +    RISCV_ISA_EXT_DATA(i, RISCV_ISA_EXT_i),
>>> +    RISCV_ISA_EXT_DATA(m, RISCV_ISA_EXT_m),
>>> +    RISCV_ISA_EXT_DATA(a, RISCV_ISA_EXT_a),
>>> +    RISCV_ISA_EXT_DATA(f, RISCV_ISA_EXT_f),
>>> +    RISCV_ISA_EXT_DATA(d, RISCV_ISA_EXT_d),
>>> +    RISCV_ISA_EXT_DATA(q, RISCV_ISA_EXT_q),
>>> +    RISCV_ISA_EXT_DATA(h, RISCV_ISA_EXT_h),
>>> +    RISCV_ISA_EXT_DATA(zicntr, RISCV_ISA_EXT_ZICNTR),
>>> +    RISCV_ISA_EXT_DATA(zicsr, RISCV_ISA_EXT_ZICSR),
>>> +    RISCV_ISA_EXT_DATA(zifencei, RISCV_ISA_EXT_ZIFENCEI),
>>> +    RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE),
>>> +    RISCV_ISA_EXT_DATA(zihpm, RISCV_ISA_EXT_ZIHPM),
>>> +    RISCV_ISA_EXT_DATA(zbb, RISCV_ISA_EXT_ZBB),
>> Isn't it kind of implied that with the presence of Zbb, B should also be
>> present?
> 
> My interpretation of the RISC-V Bitmanip Extension spec is that the 'B' extension is essentially a collection of
> the Zba, Zbb, Zbs, and other extensions, but it isn't an extension by itself.
> The following is mentioned in the spec:
>    The bit-manipulation (bitmanip) extension collection is comprised of several component extensions to the base
>    RISC-V architecture that are intended to provide some combination of code size reduction, performance
>    improvement, and energy reduction. While the instructions are intended to have general use, some instructions
>    are more useful in some domains than others. Hence, several smaller bitmanip extensions are provided, rather
>    than one large extension. Each of these smaller extensions is grouped by common function and use case, and
>    each of which has its own Zb*-extension name.

Still the doc has '"B" Extension for Bit Manipulation' as the title of the
chapter. And gas accepts B as an extension (e.g. ".option arch, +b").

>>> +            /*
>>> +             * Workaround for invalid single-letter 's' & 'u' (QEMU).
>>> +             * No need to set the bit in riscv_isa as 's' & 'u' are
>>> +             * not valid ISA extensions. It works unless the first
>>> +             * multi-letter extension in the ISA string begins with
>>> +             * "Su" and is not prefixed with an underscore.
>>> +             */
>>> +            if ( ext[-1] != '_' && ext[1] == 'u' )
>>> +            {
>>> +                ++isa;
>>> +                ext_err = true;
>>> +                break;
>>> +            }
>> I'm afraid I don't understand this; the comment raises more questions
>> than it answers.
> 
> Some details could be found here about these QEMU workaround from LK view:
> https://lore.kernel.org/linux-riscv/ae93358e-e117-b43d-faad-772c529f846c@irq.a4lg.com/#t
> 
> This leads to the following fix in QEMU:
> https://patchwork.kernel.org/project/qemu-devel/patch/dee09d708405075420b29115c1e9e87910b8da55.1648270894.git.research_trasio@irq.a4lg.com/#24792587
> 
> Considering QEMU's patch, these workaround isn't needed anymore since QEMU 7.1 ( it has been released30 Aug 2022 ) probably we could update the
> QEMU version on our CI and just drop these changes.
> Or, at least, update the comment with the links mentioned above and add a message that these changes are needed only for QEMU < 7.1.
> Am I right that we don't have something like GCC_VERSION in Xen but for QEMU?

How could there be? At the time of building Xen we know what compiler
version is in use, but we clearly don't know under what qemu versions
it might later be run.

>>> +        riscv_isa_parse_string(isa, this_isa);
>>> +
>>> +        if ( bitmap_empty(riscv_isa, RISCV_ISA_EXT_MAX) )
>>> +            bitmap_copy(riscv_isa, this_isa, RISCV_ISA_EXT_MAX);
>>> +        else
>>> +            bitmap_and(riscv_isa, riscv_isa, this_isa, RISCV_ISA_EXT_MAX);
>> What if the first instance had no extensions at all? You'll then copy what
>> the second instance say, ending up with extensions not supported by one of
>> the CPUs.
> 
> I think that it's impossible that there is no extensions at all and it should be
> considered as a bug of provided riscv,isa property. Thereby it should be enough to
> add BUG_ON(!bitmap_empty(this_isa, RISCV_ISA_EXT_MAX)) before if-condition.

Well, you can of course make such an assumption. I don't think though that
it's technically impossible to have an extension-less environment. Xen
won't be able to run there, though (we'll require H at the very least aiui,
and I'm sure we really also require Zicsr).

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 08:03:21 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 08:03:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870976.1282019 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXbtI-0004rj-6I; Tue, 14 Jan 2025 08:03:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870976.1282019; Tue, 14 Jan 2025 08:03:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXbtI-0004rc-3i; Tue, 14 Jan 2025 08:03:12 +0000
Received: by outflank-mailman (input) for mailman id 870976;
 Tue, 14 Jan 2025 08:03:11 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=xX/k=UG=bugseng.com=nicola.vetrini@srs-se1.protection.inumbo.net>)
 id 1tXbtG-0004rW-J5
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 08:03:11 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id fdad326e-d24d-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 09:03:08 +0100 (CET)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 by support.bugseng.com (Postfix) with ESMTPA id 4B1E54EE0744;
 Tue, 14 Jan 2025 09:03:07 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: fdad326e-d24d-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1736841787; bh=lB5Dbodzl2R3mgxiMRri6BWaGPaB3/93XncFmbd+ax0=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=hZYNHY2iAYkl69zp44q9NZr9AU0QaYJYRVrTqt/v1mOkN/KXN0Iiszz+2aHNf2L5J
	 7PSRDH/fRpPBLc0Lpwfh6UgcgfUk6uKleWdYFE6duq/jLOfFcljOvdRe0HY/5AmKyl
	 RHlUpP4MuOI3fAkYGE1hhPVAWbUxNPDy12oy5PjnGYqMtkiL28idnEv3uTpkU4qUbR
	 uy/nxox3T8EIqAJRFEoA13ToHwM20LxYscmJPTPBjiDjSU+TaGX3pRUd5Ue5oJVGQq
	 SV0fLr2bFt5jhAjFqswnuNWL38RalkKg3zuTVAs1sYcMYffD+0CkzmqQZcCRxuV8RH
	 otOZFsVXEShmw==
MIME-Version: 1.0
Date: Tue, 14 Jan 2025 09:03:07 +0100
From: Nicola Vetrini <nicola.vetrini@bugseng.com>
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Jan Beulich
 <jbeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 xen-devel@lists.xenproject.org, consulting@bugseng.com
Subject: Re: [PATCH v2 1/2] x86/uaccess: rework user access speculative harden
 guards
In-Reply-To: <ec0ff4e5654752c7adbe7c4f9402cbd2@bugseng.com>
References: <20241126093508.6966-1-roger.pau@citrix.com>
 <20241126093508.6966-2-roger.pau@citrix.com>
 <cf1f87d1-f616-4944-94fa-69a777249072@suse.com>
 <e3ec3dad28dc94436c0b330b2f995120@bugseng.com>
 <alpine.DEB.2.22.394.2501031617280.16425@ubuntu-linux-20-04-desktop>
 <8e31daaf77216534c252d371a3251595@bugseng.com>
 <alpine.DEB.2.22.394.2501091556590.133435@ubuntu-linux-20-04-desktop>
 <Z4DaZlbEDEjxQ6g-@macbook.local>
 <ec0ff4e5654752c7adbe7c4f9402cbd2@bugseng.com>
Message-ID: <f6b29634dc4d3c157bedc88207130df8@bugseng.com>
X-Sender: nicola.vetrini@bugseng.com
Organization: BUGSENG s.r.l.
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit

On 2025-01-10 09:56, Nicola Vetrini wrote:
> On 2025-01-10 09:29, Roger Pau Monné wrote:
>> On Thu, Jan 09, 2025 at 03:57:24PM -0800, Stefano Stabellini wrote:
>>> On Thu, 9 Jan 2025, Nicola Vetrini wrote:
>>> > On 2025-01-04 01:20, Stefano Stabellini wrote:
>>> > > Hi Nicola, one question below

>>> >
>>> > I will update ECLAIR to treat the two forms as the same, so this patch can be
>>> > dropped. If you think it's helpful I can send a patch spelling out this -
>>> > arbitrary, but reasonable in my opinion - extension to the MISRA rule (which
>>> > does not consider the implications related to the use of GNU exensions) so
>>> > that contributors have a clear picture of the situation.
>>> 
>>> Thank you Nicola! Yes the patch would be appreciated :-)
>> 
>> So unless the proposed adjustment is considered better for code
>> readability patch 1 can be dropped, and patch 2 could be applied after
>> the ECLAIR change is in effect?
>> 
> 
> Yes, exactly
> 
>> How long will it take Nicola to get the ECLAIR change propagated into
>> the Gitlab runner?
>> 
>> Thanks, Roger.
> 
> We're still fixing the false positive upstream, but it shouldn't take 
> too long so I think next week I should be able to refresh the runner.

Hi Roger,

the runner is updated so, assuming no new violation of Rule 20.7 
appeared in the meantime, the rule should now be clean. In the next few 
days I'll prepare a patch to the docs to document the behaviour.

Thanks,
  Nicola

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 08:12:23 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 08:12:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870986.1282029 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXc1t-0006dz-Vu; Tue, 14 Jan 2025 08:12:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870986.1282029; Tue, 14 Jan 2025 08:12:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXc1t-0006ds-TM; Tue, 14 Jan 2025 08:12:05 +0000
Received: by outflank-mailman (input) for mailman id 870986;
 Tue, 14 Jan 2025 08:12:04 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/Vp6=UG=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tXc1s-0006dW-Bd
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 08:12:04 +0000
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com
 [2a00:1450:4864:20::32e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3c2c17dd-d24f-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 09:12:02 +0100 (CET)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-4361f65ca01so49320805e9.1
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 00:12:02 -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
 ffacd0b85a97d-38a9fcb7a11sm8635485f8f.75.2025.01.14.00.12.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 14 Jan 2025 00:12:01 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 3c2c17dd-d24f-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736842322; x=1737447122; 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=rVPBaSFPjmA2kyXdA9hPx66yC6feJXixJ8t3pYb10Ig=;
        b=b19RBtVwugnt8tmT8kGfhO1f6ZTd82ADT0tFMPkXg/GPdiSo8GtmkE+qg3Gr29eR4o
         OW4abKQxrM+PvLEhUitM4Oz4ogsgXcjlTd3wPKbKAgey7ApcD1p5J7CWxSSOtwNCDNwl
         5+OGERjvTwzIRz/6YV5OgnsvuezI0AaNHvPeDQTujZXd1f5arMw/tzq9KAmNeE2c1D/Q
         QkZ4LuVl9y7AbD8DzlTuDUN7LtEr87UtyVB/+wLz3hBu6++r18ty7SyMc0C6VbQil22o
         JsUzipZxBJzWN1emGMJVUdC4Pnhj5Xh1mXOLFWfcD6Kx/x/t1MJvckxK9DErvg5u0uK3
         Y1Sw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736842322; x=1737447122;
        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=rVPBaSFPjmA2kyXdA9hPx66yC6feJXixJ8t3pYb10Ig=;
        b=MGzel5qWcMK9KeqAbgeAtJ1VJW5lIjEo9AHNAH5rhrOfgi9I9YxNza61NB+FvZkG+F
         NoLrdJZu/aGQG5U/IzRwuWJ07807/Hwfokaew0drsVu4UJeeITA6NnDPGFQftwVXXVXi
         bEQLpF+1YJQWB30V1HuCbOnUN0XwSYNYUxt/yGdBhMT7FeJQEBvZiTHHk1/bfeCxtbLP
         inKRbpW4TBjM2+Ah8wpOkmTf7mq0NYQa6tV2kNE0jCbr+eXV3sntV1xCa2dBYg3hEEjY
         AbnGIrjo143IiM/j0AiCk239olAkwFI55EME332EXrTuHdmN5jaEoDcLhU3sqO/Okws0
         h8xA==
X-Gm-Message-State: AOJu0YyYIWBqijoqmerOz0Ls8erlcGGyNfh3TciUOJ3vlZR26on1nkwT
	8tmitAFjJH0gngzGNIF8zjlb3tkIcdH7WJbepuCrFTals7eIB+kbQaU8PsFgF6flu0h+N7INCs8
	=
X-Gm-Gg: ASbGncs484Rup+5Kl556A9aMkQyymFnTQHVY7nFX+tF7nq6AbCzrHUOypyBKTcN4wwm
	0h9Vf52VxF/9eDeDvRKifkhOeqIDHguzy+vwheAnqaBJKggn2g8EUVFdJXFkfEqeo1M/MPl1RbY
	YaQd8hLbgYGDPEiC9D9ShGroUsLgUZb9qJn5te/bTbqHTQbvNh8vbOThMLvd8DnZ4KUN4RU/9UO
	3c0lTpehPpsfDvkeBmfjzk47JcjGduNsm9ZfL/RX3+RcMwcIkq2dzIJZpPCeysjlKuYo55VyFXs
	FZrfZ8kU/ugGH8b01v3LVcyvFYA0CE4w8pWvhs99eQ==
X-Google-Smtp-Source: AGHT+IESFwavgYsznOM1HhEtPAGrja370bElM2W7yO561xu1E1jsst4LzWlP9213pkRh/c4Xf9EuBg==
X-Received: by 2002:a05:600c:4511:b0:436:5165:f1ec with SMTP id 5b1f17b1804b1-436e271d428mr236428095e9.30.1736842322137;
        Tue, 14 Jan 2025 00:12:02 -0800 (PST)
Message-ID: <f751c5f0-3895-43bb-874b-3611b7916133@suse.com>
Date: Tue, 14 Jan 2025 09:12:01 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH] xl: properly dispose of libxl_dominfo struct instances
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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

The ssid_label field requires separate freeing; make sure to call
libxl_dominfo_dispose(). And then, for good measure, also
libxl_dominfo_init().

Coverity-ID: 1638727
Coverity-ID: 1638728
Fixes: c458c404da16 ("xl: use libxl_domain_info to get the uuid in printf_info")
Fixes: 48dab9767d2e ("tools/xl: use libxl_domain_info to get domain type for vcpu-pin")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
I wasn't quite sure about use of libxl_dominfo_init(): vcpuset(), for
example, doesn't call it.

--- a/tools/xl/xl_sxp.c
+++ b/tools/xl/xl_sxp.c
@@ -45,8 +45,10 @@ void printf_info_sexp(int domid, libxl_d
     /* retrieve the UUID from dominfo, since it is probably generated
      * during parsing and thus does not match the real one
      */
+    libxl_dominfo_init(&info);
     if (libxl_domain_info(ctx, &info, domid) == 0) {
         fprintf(fh, "\t(uuid " LIBXL_UUID_FMT ")\n", LIBXL_UUID_BYTES(info.uuid));
+        libxl_dominfo_dispose(&info);
     } else {
         fprintf(fh, "\t(uuid <unknown>)\n");
     }
--- a/tools/xl/xl_vcpu.c
+++ b/tools/xl/xl_vcpu.c
@@ -286,6 +286,8 @@ int main_vcpupin(int argc, char **argv)
     if (!ignore_masks && hard) {
         libxl_dominfo dominfo;
 
+        libxl_dominfo_init(&dominfo);
+
         if (libxl_domain_info(ctx, &dominfo, domid)) {
             fprintf(stderr, "Could not get domain info\n");
             goto out;
@@ -293,6 +295,8 @@ int main_vcpupin(int argc, char **argv)
 
         /* HVM and PVH domains use the same global affinity mask */
         apply_global_affinity_masks(dominfo.domain_type, hard, 1);
+
+        libxl_dominfo_dispose(&dominfo);
     }
 
     if (force) {


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 08:12:42 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 08:12:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.870992.1282040 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXc2U-00076q-7a; Tue, 14 Jan 2025 08:12:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 870992.1282040; Tue, 14 Jan 2025 08:12:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXc2U-00076j-4W; Tue, 14 Jan 2025 08:12:42 +0000
Received: by outflank-mailman (input) for mailman id 870992;
 Tue, 14 Jan 2025 08:12: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 <SRS0=/Vp6=UG=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tXc2S-00076V-6w
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 08:12:40 +0000
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com
 [2a00:1450:4864:20::335])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 520a06f1-d24f-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 09:12:39 +0100 (CET)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-4361c705434so36644305e9.3
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 00:12:39 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436e9e62133sm166433875e9.33.2025.01.14.00.12.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 14 Jan 2025 00:12:38 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 520a06f1-d24f-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736842359; x=1737447159; darn=lists.xenproject.org;
        h=content-transfer-encoding:autocrypt:content-language:cc:to:subject
         :from:user-agent:mime-version:date:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=3a6aVJIZxGcOGXILo6dS5uJfAibi9kUy3AHZ09t6haQ=;
        b=Mh5zW7r4CpWqTjj/VV4XY3R95ETK7sZzddoBExnNFX/Yty7lTEMjCfshJ5mkJ9ekNV
         s4e1ATZ2XMFDN4D30Lp1tSQFq2FALdF5q1m3yrERzRxtKRKi52POu4+cUb82qpHhqZFD
         8nwN8QQsgrjx4l0cd0/cdDQmN0GfPOiON0IBLRIxxVERpN6YIioUtoPyrYmt7KfkxDfm
         C4jieJj2H1QfSbTfF0pqKD7aJyrnyB5H5F0QA5rNUKpBHpe0WiF2y3WLHJhCUXThS0hg
         FDZh+jemdMX2hFKc7Rw6jaT7+MzrKnnhKbo2BvEBeqqpFqndJD/Kdn99LKQGreyJ5czA
         Z2yg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736842359; x=1737447159;
        h=content-transfer-encoding:autocrypt:content-language:cc:to:subject
         :from:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=3a6aVJIZxGcOGXILo6dS5uJfAibi9kUy3AHZ09t6haQ=;
        b=eRvY174F9eTt9ZaGpxznZYJZYh9JSZdPHY6eku866y9Par87G83ULjWVtvzYLGa4Ql
         9QJQNqetrOgSDfj7BWYia02EbuJIH20cRZKVzaO+fr4hCh2LBPXUD1KumjoLWoa1kiMy
         kfszZ7lVmUvVgfuZMqrVF2F42qybg1K87z/6tOzSrRST1NeXLaaRkNqzsAAVV9E52x37
         SyvRgzK5WWeIR3y6ir/2GPDgtnyCwe7yg2xDjfWAPnZjgSefOjUlEiLjcBruCdHpEwf2
         XXCOW7atUZZGgb84iHeAxZ+XHw22+W63/XVQOn6uJOvclqUKi1ZRt7OuGsNly/E0WdSR
         xz5g==
X-Gm-Message-State: AOJu0YwieKAxDBTCJ7n8v4w71RExj+O7+D7iR8HYn5Xuo45qJwHpYyH3
	Rl+BY18Djm7pogam40E+MovNDECqJVfydSJrxUpVrAwr7h7KPLWEAL0uSnSMzAZ2EhQN8rpwOhc
	=
X-Gm-Gg: ASbGncsGoJdhtYEiQuB9fP3ItU8J0Nrik394TIsYWiciE2NTteFDh3Le/Yq2gwDmCzp
	vEoiZbSImwhQtsMcvK66m6nvzXfjaL6guvq+3vYDibGM1PX9ylCHni/ZIqJY87LWCo1n/ntdnO+
	cFqoQAZdFMJwbmr6olI9OgRVeBPbS58dlMmsMbG7iD409vAQbcOb6nv2FGYGEZHUQbEFbZnn0Fz
	xsXaqDRdZ8m0rkyfCLeVM5PjimgT75LXFss8knPRTqWNWJrNbb1NazQszMPADVzwWwWQkzkoPmQ
	5TSemKw/EdeM3/sotBG9b28dch+Ubm/EpYxzD8LAaA==
X-Google-Smtp-Source: AGHT+IH7utO/GKMqnnOWUbcwkAx7/UIXlSWYIaWovjq/cQVkW4QG5uKaOAVvY1I+9bh/DMYy9E2adQ==
X-Received: by 2002:a05:600c:5848:b0:436:f3f6:9582 with SMTP id 5b1f17b1804b1-436f3f695dfmr107276185e9.8.1736842358792;
        Tue, 14 Jan 2025 00:12:38 -0800 (PST)
Message-ID: <fedf2b9d-a475-4062-b8a4-5e33c7dd6305@suse.com>
Date: Tue, 14 Jan 2025 09:12:37 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH] xentrace: free CPU mask string before overwriting pointer
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

While multiple -c options may be unexpected, we'd still better deal with
them properly.

Also restore the blank line that was bogusly zapped by the same commit.

Coverity-ID: 1638723
Fixes: e4ad2836842a ("xentrace: Implement cpu mask range parsing of human values (-c)")
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/tools/xentrace/xentrace.c
+++ b/tools/xentrace/xentrace.c
@@ -1105,8 +1105,10 @@ static void parse_args(int argc, char **
             break;
 
         case 'c': /* set new cpu mask for filtering (when xch is set). */
+            free(opts.cpu_mask_str);
             opts.cpu_mask_str = strdup(optarg);
             break;
+
         case 'e': /* set new event mask for filtering*/
             parse_evtmask(optarg);
             break;


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 08:13:25 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 08:13:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871002.1282049 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXc38-0007g4-Hb; Tue, 14 Jan 2025 08:13:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871002.1282049; Tue, 14 Jan 2025 08:13:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXc38-0007fx-F0; Tue, 14 Jan 2025 08:13:22 +0000
Received: by outflank-mailman (input) for mailman id 871002;
 Tue, 14 Jan 2025 08:13:21 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/Vp6=UG=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tXc37-0007fh-KW
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 08:13:21 +0000
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com
 [2a00:1450:4864:20::335])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 69429ac2-d24f-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 09:13:18 +0100 (CET)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-4364a37a1d7so53682745e9.3
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 00:13:18 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436e2df3610sm200368795e9.20.2025.01.14.00.13.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 14 Jan 2025 00:13:17 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 69429ac2-d24f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736842398; x=1737447198; darn=lists.xenproject.org;
        h=content-transfer-encoding:autocrypt:content-language:cc:to:subject
         :from:user-agent:mime-version:date:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=JwagmJ2ZAkkmElCxfguveqeewZ+CyIQy8EcKOsWL3NE=;
        b=HNujk0jOglArFy2A4YOmuqsmmRiArzA8vuaCnk5FWxyq/McNFzQSgqx2NBvEPRxYyc
         MxNneS0NGpIYIc/dbNU0xnJm55d82ZvG4B4Dmxlr8b/rWbuglzvxmprJZaULjdGlYmOp
         VOik0vWMv6ZbM5ctnTpYVVN5+nQ21/ewK2rC73vmvrYyTwp0S+6fgD9CvC2g4bU0RGcV
         2Bzhhd8mTc8LSdwH3b76X+0BFCWZ4JF2JyTESTzw7lLd4p5UrubEGiqDUOJdcmi1JQ26
         QhGz88My3BcqmiJZ4XG33z0M1fzEiqcvIHi4l5NuhgMrWL/RVm4i6LiSfLKfnaDgsj5I
         kmgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736842398; x=1737447198;
        h=content-transfer-encoding:autocrypt:content-language:cc:to:subject
         :from:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=JwagmJ2ZAkkmElCxfguveqeewZ+CyIQy8EcKOsWL3NE=;
        b=JuF6Ei72pY0JECZOeHMD6+4Rj/6wchvLTp/X84EoH44u+7j6Oj7VGGGWn+1ZNZjLwK
         FQcpVJPKAqic46NS+xlI/BnCWInWadQ2RH7g02TxeFBU4dzzcWKrDORfgrA3pAUJ+10B
         5njQthR8TUmevGisEaf7KHm4NwfDe6QjkwxA4Jls0hnYTCBVbGeLje4snAdgmvZ/PRPn
         +dXX9DPnq3+fWqSAnIUpsp15dVOucU/MGsYLqthYDQW3XiP292+YNnPvAIu6Gepeo9JT
         gjoJwz2SIihBO8rrQ5xkWTaAE+k3FeD8wJE8f4hOWdtkvIwK7D64ekh6Y64jsQcyU7Mc
         smow==
X-Gm-Message-State: AOJu0YyMn+EFeApZ7Lz1+tBjqOKGsV3Rw+uwHhwAV0/GNNopH1F9LA4G
	ldR59p6OtdCJ8fxBicSdaXMlVORQsxMoFZcyzdk3h0wzkRy8DKq/aRRamahjJOrRR6OoGX4rFM4
	=
X-Gm-Gg: ASbGnctzvXTaQn8Lo3qEbrVGmsTSCzlZHgSlzA+IDm1FLZGS+NaIw9OOf//K0ectfg3
	mF/C41w2rwIHp4KNTHImd6a6QUdwMW4biClV7yKHmqHwz2ft2hdjcKUTre3ibb0wXMFrLTIlDOr
	EO8W8rsVWScfmgdD7yMri00zmi/c5Yg+qcSOWuHNDgA4FbqGr/seSL3klcyXtA4XKv3IkwNh1WG
	2fDJT0/YVeRlkNPP37VjI0VvkS8IBFOYJdn/ZqyjlAeyWprul3siBYwEz0CQca70F/Gi3zKkcuH
	rjSF+rYl7DwSZeX/hGzvh0vAkeDw3TU4/I6KV73W+Q==
X-Google-Smtp-Source: AGHT+IErj72sXb3jhvigDRw0HX1z5VN7aJzdaxPDu0IH+dcPDkVSRWWElIo0FzUAyCkeMqWa4yRUJw==
X-Received: by 2002:a05:6000:402a:b0:38a:418e:1171 with SMTP id ffacd0b85a97d-38a8733063dmr19997415f8f.37.1736842397840;
        Tue, 14 Jan 2025 00:13:17 -0800 (PST)
Message-ID: <73a01ddf-6090-4fda-a8c0-5703e7c9e81b@suse.com>
Date: Tue, 14 Jan 2025 09:13:16 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH] xl: properly dispose of vTPM struct instance
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

The backend_domname field requires separate freeing; make sure to call
libxl_device_vtpm_dispose() also on respective error paths.

Coverity-ID: 1638719
Fixes: dde22055ac3a ("libxl: add vtpm support")
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/tools/xl/xl_vtpm.c
+++ b/tools/xl/xl_vtpm.c
@@ -44,12 +44,14 @@ int main_vtpmattach(int argc, char **arg
         if (MATCH_OPTION("uuid", *argv, oparg)) {
             if(libxl_uuid_from_string(&(vtpm.uuid), oparg)) {
                 fprintf(stderr, "Invalid uuid specified (%s)\n", oparg);
+                libxl_device_vtpm_dispose(&vtpm);
                 return 1;
             }
         } else if (MATCH_OPTION("backend", *argv, oparg)) {
             replace_string(&vtpm.backend_domname, oparg);
         } else {
             fprintf(stderr, "unrecognized argument `%s'\n", *argv);
+            libxl_device_vtpm_dispose(&vtpm);
             return 1;
         }
     }
@@ -65,6 +67,7 @@ int main_vtpmattach(int argc, char **arg
 
     if (libxl_device_vtpm_add(ctx, domid, &vtpm, 0)) {
         fprintf(stderr, "libxl_device_vtpm_add failed.\n");
+        libxl_device_vtpm_dispose(&vtpm);
         return 1;
     }
     libxl_device_vtpm_dispose(&vtpm);


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 09:27:58 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 09:27:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871023.1282059 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXdD2-0000Zh-Ph; Tue, 14 Jan 2025 09:27:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871023.1282059; Tue, 14 Jan 2025 09:27:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXdD2-0000Za-Mb; Tue, 14 Jan 2025 09:27:40 +0000
Received: by outflank-mailman (input) for mailman id 871023;
 Tue, 14 Jan 2025 09:27:39 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=tIyo=UG=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tXdD1-0000ZU-NZ
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 09:27:39 +0000
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com
 [2a00:1450:4864:20::62a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ca026ec4-d259-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 10:27:35 +0100 (CET)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-a9e44654ae3so844289366b.1
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 01:27:35 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c90da8b2sm604410066b.44.2025.01.14.01.27.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 14 Jan 2025 01:27:34 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ca026ec4-d259-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736846855; x=1737451655; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Nyd7dH3RHiKx0E2y9+ZoavS8jdI9kOOhJQh9JbRxM5Q=;
        b=rbJuk+h+dAuUd2Q2m4YN+slBS6l5tiqCWdSg6RUoFq3dJCe+72apkdMzwHuS8rEqvc
         +BqlDqT1tA+j32Ni3N4dDKO4wh3MK4cs3aXRx6uBHcAUVQMhXVNio8Gk7uvxTG67I1DQ
         n6W7T2CXYsripiT7MVbWxR3UWBCoNsTlpVvHg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736846855; x=1737451655;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Nyd7dH3RHiKx0E2y9+ZoavS8jdI9kOOhJQh9JbRxM5Q=;
        b=mx0aNMYkgQwd32zaL/NONQ0r2C8gE0CgqqVqKjb/EenJG5qp0NvAiDHvG0jMb46Itx
         jL5BlculF3qM1oR/bsCoQabffaORzfx9iGnWYWqFcBm9v0xYGkJfx/C2DWwErsnzP8uF
         kVyTILEh9JG8BjvzA0Xf4MzU8HxGPbGFBI2N1ZVBiPkZEnXRpF6MZYX+gHqB2opPbMIb
         7mniZCZC1ObnxRy9cex9nGpNLKd6SfQ3BhWGktvXILNuPlMzCyrLOOIPWp0tZ7DCDP0y
         R1CO46qmsMXdtTjT5Ek5UGTMVcWMKgHwGyObrfEHP1yuBhaTbFZjZYFQhshggH0GXYvO
         zNPw==
X-Forwarded-Encrypted: i=1; AJvYcCUi6JtxyblvePCPMPD/QpHifYfkNx4vX2tjS3igVzRadSfKzY6U+IW1G7MjG8t3f5avv75diVKDaZU=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy61eY2PKU2joHABq+wpB1LCpz9DDKhvuL6T7g1+e8rW3sqGOJR
	AZh2kAaFYR6E98Sr84/5C3xuxokXmF7X0NyELi3E1lC+6n8YvvxNInVzXKeWhAg=
X-Gm-Gg: ASbGncvBlR7TIAneBuwA73odWNwdIihsiHv9ttA8jAbCo+K2oeoRIX3ZUyAv2wQwNvu
	LwUsWburnnTPWCxvMsN//7RceUTBik+AV8UE3U19Z8juGvUTIP0HcnnUrN0sgk4Lc20+9dzaBuX
	mGFdlk8st5c+YlksrVf4+hzvYcdylIHXeo3wICSxcwwiUCd1Ygqwd7LOVBimSiHjOfvf0jYQwiU
	9iznWTbkMtxo6ZSQSmxTU2+e+qLUyHVYGGcuXmAocBzyWxiBX5wQ6eN9Q8MP2lQknixnjJP4cG+
	vMau3ZMZtiqrc7HFJG5e
X-Google-Smtp-Source: AGHT+IH8MfgE39ztq/3hsSseqw32JAQQtYkLXVGYcPntCz+fX0bp3sFv2J4Hd2l4tqrRsPTYLgRESQ==
X-Received: by 2002:a17:907:2cc2:b0:aaf:123a:e4f0 with SMTP id a640c23a62f3a-ab2ab6c002fmr2005744866b.6.1736846855101;
        Tue, 14 Jan 2025 01:27:35 -0800 (PST)
Message-ID: <5e7af388-8b8b-4d81-9429-14a330780b64@citrix.com>
Date: Tue, 14 Jan 2025 09:27:34 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xl: properly dispose of libxl_dominfo struct instances
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>
References: <f751c5f0-3895-43bb-874b-3611b7916133@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <f751c5f0-3895-43bb-874b-3611b7916133@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 14/01/2025 8:12 am, Jan Beulich wrote:
> The ssid_label field requires separate freeing; make sure to call
> libxl_dominfo_dispose(). And then, for good measure, also
> libxl_dominfo_init().
>
> Coverity-ID: 1638727
> Coverity-ID: 1638728
> Fixes: c458c404da16 ("xl: use libxl_domain_info to get the uuid in printf_info")
> Fixes: 48dab9767d2e ("tools/xl: use libxl_domain_info to get domain type for vcpu-pin")
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> I wasn't quite sure about use of libxl_dominfo_init(): vcpuset(), for
> example, doesn't call it.

It's a written requirement (somewhere) that *_init() and *_dispose() do
get called.

Except everyone's lazy with them and plenty of scenarios function
without, which is why it's often Coverity telling us about it (but only
for the instances where there's a real malloc()/free() gone missing).

I expect it would be better to extend this patch to fix up vcpuset()
too.  The changes so far LGTM.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 09:28:16 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 09:28:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871029.1282070 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXdDc-00011p-1Z; Tue, 14 Jan 2025 09:28:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871029.1282070; Tue, 14 Jan 2025 09:28:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXdDb-00011i-UE; Tue, 14 Jan 2025 09:28:15 +0000
Received: by outflank-mailman (input) for mailman id 871029;
 Tue, 14 Jan 2025 09:28: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
 <SRS0=tIyo=UG=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tXdDb-00010S-0r
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 09:28:15 +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 e0d09961-d259-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 10:28:13 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-aaee0b309adso862321366b.3
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 01:28:13 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c95aee31sm605364366b.133.2025.01.14.01.28.12
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 14 Jan 2025 01:28:13 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e0d09961-d259-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736846893; x=1737451693; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=3LmKmsSiV6JZfOVy5DDtZRxAZb3l77AC0bejAyx6pfc=;
        b=Q0vhLb/sKj8d7ifeB3sZJrFBNG3Y4nUorludkcw2Xn08H1rCWLKdrv8HzOkvDSz/yd
         fDQMaSqCtoGwnSF23uAy124QepUBDQuTW9NmqpGInJ0fHSBwoF3Hcm7LrOmEf+1QJ+14
         7emqMfHqXHiIdNxNF0IorI2lZjMFB2TljXCLI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736846893; x=1737451693;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=3LmKmsSiV6JZfOVy5DDtZRxAZb3l77AC0bejAyx6pfc=;
        b=jUe6qCf+BA/31GzYKlA2b+ijfvaNZkSaEce5MthW58SUAEcNZX8A9BoNr2h/bFmbUM
         BwskvSGkkPIbDFqzFmtUGpPsJ6Evw5Fs3yKN2tNXbPJQfmfrIuNmc6UZktzKF2QsRccG
         FGkmfb/vX9ig6oUNf3QXouO35NDyKz8PA5eIaebmv+oGE7GayjgZkYoWgEL3Rs3OAZxy
         ERba/KHbGx9cTrMPa8DGF+7pxIkTdASooHbLiDTaiOnFyah8WtCM9mJhtBDLaQRJoIkv
         a+liRf7PUoJTZiLOLby4Bwt5C4EMieKWjraG7DdK0l4V5BfFZq/DyawmTOfCP1XMpOrs
         B67g==
X-Forwarded-Encrypted: i=1; AJvYcCWKSGjaBSZ7j8oYVjh197bCj6ew6v2SefoCE+9801j9MaPuhnyuAV6ZvceovguGvc/EFj98K+SPraw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz5G6ypVtt7ZjVXzGYjdSUiYvAucfc8sCoy8Wok9PjRAIWz/Zd/
	52Domp57sHG7ZvT5+BJGK/ljRlVTAeNghULPAsuSXgpY28/QZgsrYJODgUzYVIQ=
X-Gm-Gg: ASbGncukBy0MWX+3LSk6zKB5HjYimwQj8MsTHFYHG+MOeDoL0DwxmwOMZSJDeoZjU3x
	ykOs9/89oBWA5Vi4cf1C/nSGgHg4LoqSGEozJXQLm+o3PykZooUQLc4VXzpsJQysE5ceVCfJehF
	gWR7hoyRpLnh+22fh7ubQIknTzxMYrMgebDduJ4z9txR2IWrp6s+W08OuF/P45Kt1XSGA7jqMEN
	RGMuoBiJvFEVYmj3Z49XPsLeRUPsNF42YUccanKGhvFjfT9S+RJWRCunW5bclgbwizCDrZsRh9/
	2DWZVBKX3WzN3szUUYxQ
X-Google-Smtp-Source: AGHT+IGXdO5NUm/saEy9YA+7hraGqILt1gQIjKxJL/n6qVWZ+qkIBhk2rXe3Xid1h57hZioZ/p6fyA==
X-Received: by 2002:a17:906:e098:b0:ab3:33ad:13c6 with SMTP id a640c23a62f3a-ab333ad13f2mr191132566b.28.1736846893312;
        Tue, 14 Jan 2025 01:28:13 -0800 (PST)
Message-ID: <2d461c1c-513a-49c5-8d62-d77969c6b10a@citrix.com>
Date: Tue, 14 Jan 2025 09:28:12 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xentrace: free CPU mask string before overwriting pointer
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>
References: <fedf2b9d-a475-4062-b8a4-5e33c7dd6305@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <fedf2b9d-a475-4062-b8a4-5e33c7dd6305@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14/01/2025 8:12 am, Jan Beulich wrote:
> While multiple -c options may be unexpected, we'd still better deal with
> them properly.
>
> Also restore the blank line that was bogusly zapped by the same commit.
>
> Coverity-ID: 1638723
> Fixes: e4ad2836842a ("xentrace: Implement cpu mask range parsing of human values (-c)")
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 09:28:45 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 09:28:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871037.1282080 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXdE5-0001X2-8Y; Tue, 14 Jan 2025 09:28:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871037.1282080; Tue, 14 Jan 2025 09:28:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXdE5-0001Wv-5T; Tue, 14 Jan 2025 09:28:45 +0000
Received: by outflank-mailman (input) for mailman id 871037;
 Tue, 14 Jan 2025 09:28: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
 <SRS0=tIyo=UG=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tXdE3-00010S-SF
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 09:28:43 +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 f26def67-d259-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 10:28:43 +0100 (CET)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-5d932eac638so10124593a12.1
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 01:28:43 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d99046e048sm5791489a12.71.2025.01.14.01.28.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 14 Jan 2025 01:28:42 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f26def67-d259-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736846923; x=1737451723; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=dT+L1KpIsC7pSYSBbozTyUDtd50clfXUhegf/xEJsJc=;
        b=jmC1H16SN+dd4vIw1RF5lA7fMTs17i2BtL/I9sDpsLRyvBZMCsrl1NH1gUIPh+XUw1
         daKVtsL/bk6tf0Y/wy3+mDZXIpvEfYei50EvH3iA8+cwwN1+YsletsjDu93EjIQPigGl
         hOmdy3ug6kjDgP71qRIGNx76OagLMdoAwlWV4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736846923; x=1737451723;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=dT+L1KpIsC7pSYSBbozTyUDtd50clfXUhegf/xEJsJc=;
        b=h/EQUte4ZCSltnAvDwid1fowQ0Zf7RPNVk3wToBb4iZLT3poqEfOJwp1pAk5JNRfdx
         lKRD8Nb7SyP8pF6znVw2rcLhr9QxGZ2usdLpS+cTBTE+ZUuPyJV5D4h2yBlqi2F6QsgL
         9BFNkahg95RAVpUVM/vSjoF9umFRMTBj72EJ8myZhifWfULtAQ+sVpFpyBjIBPi4pnNU
         OWvNJ4OVl/WDfF2gBWJrxeD4Yu/21Usj8VEqGEmZ3O78RJEVHHJEhGi1hHNfRVikhMYC
         9xXyJhrmXjcSNj4tJp2fRBgpB0ArfQEQ06wl09WDCJi9jTsjTZKEi0vBp0EXDU81JAA2
         LNPw==
X-Forwarded-Encrypted: i=1; AJvYcCWoSZ3lvae4O2DC8tNCEhOP90r3BiRAGw2GTcOyvUrTz5CfND7besi6RYNN46Tobg9KQXS6ARkKmas=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwpvbgbdLNMNYj0NDnVoRZMuTZZdLfvCG3K2jCoX/PkzIVJxPnO
	eo244Vyn0zSPcsreJ1RMLh/5RxXvpEaRpI8PMR1Rs6CqIUDBwZa90hifMQzhL+g=
X-Gm-Gg: ASbGncvG/qnuBf6Ng598S8JCBdVG0SbiKLw4NmR+b+yDkngqy+8Hca/vtHaNbJBPSAu
	8NbbFtCat7xGL8AwQM5LWHUO0j4ctn39voPSlZuylydoxwaQ3bwb2WPzdXVdzhXc+TVJS/JC1RM
	L6GIw3LmS1SXsDKRI4ZUP7xRjbqg+GcL8kVf2hz2aUZwvWmzgzWi+X0OMVtjvmnPs93qOApbGXm
	7pw9OpKhk5UrLFqCHv5UNKd5+TGZfv7JWQJa4lo+KseaUqPBJwFRfOcTjnhbKuRNwpLX5Rfchdc
	sbfMjj47YucJcQnEWUQY
X-Google-Smtp-Source: AGHT+IF0ew/dAuSAc5VRU3cvZR/fpPhrengQ9e4r4043nxek43urQyx32NDHmEUS9dLxL+Is7BQKIQ==
X-Received: by 2002:a05:6402:2681:b0:5d3:bc56:3b24 with SMTP id 4fb4d7f45d1cf-5d972dfcb34mr22797330a12.4.1736846922822;
        Tue, 14 Jan 2025 01:28:42 -0800 (PST)
Message-ID: <e03befec-2c1b-46e4-ab88-3f2a19575149@citrix.com>
Date: Tue, 14 Jan 2025 09:28:42 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xl: properly dispose of vTPM struct instance
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>
References: <73a01ddf-6090-4fda-a8c0-5703e7c9e81b@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <73a01ddf-6090-4fda-a8c0-5703e7c9e81b@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14/01/2025 8:13 am, Jan Beulich wrote:
> The backend_domname field requires separate freeing; make sure to call
> libxl_device_vtpm_dispose() also on respective error paths.
>
> Coverity-ID: 1638719
> Fixes: dde22055ac3a ("libxl: add vtpm support")
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 09:31:57 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 09:31:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871048.1282090 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXdH8-0003Ht-NO; Tue, 14 Jan 2025 09:31:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871048.1282090; Tue, 14 Jan 2025 09:31:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXdH8-0003Hm-Kr; Tue, 14 Jan 2025 09:31:54 +0000
Received: by outflank-mailman (input) for mailman id 871048;
 Tue, 14 Jan 2025 09:31: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
 <SRS0=tIyo=UG=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tXdH8-0003He-81
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 09:31:54 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 62e28ab5-d25a-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 10:31:52 +0100 (CET)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-aaf8f0ea963so1031570766b.3
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 01:31:52 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c905ed3esm604738366b.33.2025.01.14.01.31.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 14 Jan 2025 01:31:51 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 62e28ab5-d25a-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736847112; x=1737451912; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=bfpf5mC3A9tITubeEOg+HMA9r6EKU3Pj+ywED/juqVU=;
        b=Fh8ubhqnl9pFEjGaspwSsPnRaSn9KN/kcmW3MPUujE27S5lN38sRoc0epEqU1hhMB6
         tbxWobVPvsXcFq/3H3bmU3ekZK/bpd/bfCI0bdP6oTx7De9BX3EQIQixx+2zCU6e1sRO
         ekoVkia7fBQLd2dCA4v2fGFRjhZarnsPM28pw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736847112; x=1737451912;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=bfpf5mC3A9tITubeEOg+HMA9r6EKU3Pj+ywED/juqVU=;
        b=GqQ9aLR3SFC2s0w0b8o92IBSzf2yEw8Ywq25IhH1fvpuv9yUtVGujllSVB18fcZpPn
         8LkA4D8WSTg3KtGHxfM+FAJBqWB1dBfeLMh8/6b9NDerRygFw/tWmT4JnvcNhol4jkl/
         4QeSQpHHJhY0168QNxLmpzuPf870nIEjNvAdyLOIxMkcG8KVr6HSp7RUtTIWTYuu993V
         vlWbWyrvsVO5xKpNGTquWZmLRpJwYq0bPdwo5XzBXMSXCtQ7TZq5oXzI1wQzqReG02rU
         6nnHpHPacjEVhULsymUAXDBbjFopoeCsjBgrtjyzBSiei3cHTNHY5joSzkg0SlXiDqz8
         6HyQ==
X-Forwarded-Encrypted: i=1; AJvYcCWek57J4uz2Eq4+ucE16S079lwzmKTI7hNKQ645qS6FgdEBnlYbBRGSx2XwjiK8/I8fW+EJNKScCYI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxjYgaYrUa7B5oqeEKp9EJNjykbi/gbJ/y8DT5YtB8DKZOgmKt3
	7IeWV0e3TKJuynDhCWRJAXyxpBeSjsYkHElDqofFZuSeuvaNC1SBmLMApPgvpYU=
X-Gm-Gg: ASbGncsfCtloCo83TvCc6fXXEdwiMjpbQyiNhyFFKuHalQdn/SLxv74PQNrxI1IT9uN
	OjrtXlcWV5uf1zF5G7bFo+MbrCn4YJJlAi2yuaoxWcxAIJ6Ns+U0gzeFP5FM3/iYmwLXL2/+j1k
	3yjlgTxyDXrEYyPD2mkOuEJ47xA089u+jJ4LqBdSIo14ZVUCCY0UK6wMYHba82P5uz6q+LlfPHS
	PQk/PIk5tdoyQ72CeCN1ii3lrR9/Go+SS4sl6+/d3XKIbYsGu8jeMtAW2N4k3KEEomnvlrDMrlR
	ulYh+tFadI7HsqrDMGZT
X-Google-Smtp-Source: AGHT+IGgywRW1D4kzJynHyfoHVJiJzg5S9rocjnl4bXrSvF3zoGQWu4PTzTjC/K54ZKW44GZTtmeLw==
X-Received: by 2002:a17:907:d24:b0:aa6:7ab9:e24d with SMTP id a640c23a62f3a-ab2abc94efemr2176602666b.57.1736847111728;
        Tue, 14 Jan 2025 01:31:51 -0800 (PST)
Message-ID: <9ab180fa-91c3-416d-9b39-2a9b2970dcf9@citrix.com>
Date: Tue, 14 Jan 2025 09:31:50 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 2/4] xen: common: add ability to enable stack protector
To: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Stefano Stabellini <sstabellini@kernel.org>
References: <20250114042553.1624831-1-volodymyr_babchuk@epam.com>
 <20250114042553.1624831-3-volodymyr_babchuk@epam.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <20250114042553.1624831-3-volodymyr_babchuk@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 14/01/2025 4:25 am, Volodymyr Babchuk wrote:
> diff --git a/xen/common/stack-protector.c b/xen/common/stack-protector.c
> new file mode 100644
> index 0000000000..8fa9f6147f
> --- /dev/null
> +++ b/xen/common/stack-protector.c
> @@ -0,0 +1,51 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#include <xen/init.h>
> +#include <xen/lib.h>
> +#include <xen/random.h>
> +#include <xen/time.h>
> +
> +/*
> + * Initial value is chosen by a fair dice roll.
> + * It will be updated during boot process.
> + */
> +#if BITS_PER_LONG == 32
> +unsigned long __ro_after_init __stack_chk_guard = 0xdd2cc927UL;
> +#else
> +unsigned long __ro_after_init __stack_chk_guard = 0x2d853605a4d9a09cUL;
> +#endif
> +
> +/*
> + * This function should be called from early asm or from a C function
> + * that escapes stack canary tracking (by calling
> + * reset_stack_and_jump() for example).
> + */
> +void __init asmlinkage boot_stack_chk_guard_setup(void)
> +{
> +    /*
> +     * Linear congruent generator (X_n+1 = X_n * a + c).
> +     *
> +     * Constant is taken from "Tables Of Linear Congruential
> +     * Generators Of Different Sizes And Good Lattice Structure" by
> +     * Pierre L’Ecuyer.
> +     */
> +#if BITS_PER_LONG == 32
> +    const unsigned long a = 2891336453UL;
> +#else
> +    const unsigned long a = 2862933555777941757UL;
> +#endif
> +    const unsigned long c = 1;
> +
> +    unsigned long cycles = get_cycles();
> +
> +    /* Use the initial value if we can't generate random one */
> +    if ( !cycles )
> +            return;

Indentation.  Can be fixed on commit.

Everything else LGTM.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 09:32:29 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 09:32:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871059.1282101 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXdHg-0003mL-WC; Tue, 14 Jan 2025 09:32:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871059.1282101; Tue, 14 Jan 2025 09:32:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXdHg-0003mE-S0; Tue, 14 Jan 2025 09:32:28 +0000
Received: by outflank-mailman (input) for mailman id 871059;
 Tue, 14 Jan 2025 09:32:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=iLru=UG=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tXdHg-0003ZR-2Z
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 09:32:28 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 77f9fecd-d25a-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 10:32:27 +0100 (CET)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-5d3d143376dso7529419a12.3
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 01:32:27 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c95af24bsm608344366b.134.2025.01.14.01.32.26
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 14 Jan 2025 01:32:26 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 77f9fecd-d25a-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736847147; x=1737451947; 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=Vc6InP4rrRJV9qMpa0VWNFtyEUnPmljL2ysGpC295uo=;
        b=nRH9PVlFssdFAkXeO2uqFUlrcbP3k4X4m498AizKvdz1hiuFWT9dgmHKYfH6rHQ7DC
         W9aw/lD4xr76F2wgXdXAyk5SXOIuXyKdcrlsuNmSASy+ZGkjfmfXv/j00PuORBF1UaRz
         RLIGpiYka4EzkNGE9hFZCg05Plba+FQgKE9Ds=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736847147; x=1737451947;
        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=Vc6InP4rrRJV9qMpa0VWNFtyEUnPmljL2ysGpC295uo=;
        b=mDzr0c+CA9WcZ5wHr6rZh++23s+nb1kWgv7pMuewqybxe0ot4y6uwvpcXIOjRz1Ycl
         y5qSOy00cSUd8HnEdg3YM1X0zxuk6eAdkwUdmpF90MrzVqCaTyEMAifNqStvfWxze2m9
         0/ff4oHY3xsaNlU4u5zt5rrWxaYtuA9p8PR6hysnYGmUlnYTd+cxhkz1G4D0CnF/1RRU
         K0B+D0M9YO9U8fF3LLfQGyOwj+7lTj/Za+EABaLWmZ2HyO3bZp4CBp8AYqZjkgjXMZ2L
         pukSxIKKLf/ePcUoEyEGTDSIp3MNczv/mqyDVVmOvAjkrEplARD9yNg8lS2Eu0ghF4Tn
         8QZA==
X-Gm-Message-State: AOJu0YzyFczMzlqOnC02DrKHU5frtPcNTr/lccXU5AAibBPSzuq73E47
	2NS23/7KfR5lrNkYQF5Wa2nQVX2aFg9IIrF8V+mzpQNHVFuuUfudN0cLiL1iBzs=
X-Gm-Gg: ASbGncsgumfU7jpeEKWpIHpBA8L8WT3HkDkoX8CbnFCxoXeEMlPQvMPNq9J5YWZNGiw
	cFeHaXikZlWA/F4i1v1xUGvKkb4fm32XzhmP48Q/kvBN6tTNJiXnQsPzuSQIb7sZ+54CukRRaUr
	Rtc9FAFNxJgMr6Y1mkvDk52t9ab4VVlTKyrCbdZFG6RSWG88PjtnxPe4qpZxV11JTmtQDBYQ3Jy
	hJUuIxhgtOgnWhnaL9wPcXeZIeGTOzlyTizRUWqdsxwpmvs8EBJOPPlgZkH5w==
X-Google-Smtp-Source: AGHT+IF5wm/tp9Wah8W7uIa+PYzV45EC6H3HVnVibHi/ZH4Qan4tATQN3VFIZ0Idc+trtm7YCZokHA==
X-Received: by 2002:a17:907:97c3:b0:aae:83c6:c67e with SMTP id a640c23a62f3a-ab2abde5517mr2136513066b.55.1736847146666;
        Tue, 14 Jan 2025 01:32:26 -0800 (PST)
Date: Tue, 14 Jan 2025 10:32:25 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Teddy Astie <teddy.astie@vates.tech>
Cc: xen-devel@lists.xenproject.org, Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [XEN PATCH] intel/msr: Fix handling of MSR_RAPL_POWER_UNIT
Message-ID: <Z4YvKdwtHjmJUVF3@macbook.local>
References: <0ac778dbcc7ab383447abe672225ff77b0d4802e.1736793323.git.teddy.astie@vates.tech>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <0ac778dbcc7ab383447abe672225ff77b0d4802e.1736793323.git.teddy.astie@vates.tech>

On Mon, Jan 13, 2025 at 06:42:44PM +0000, Teddy Astie wrote:
> Solaris 11.4 tries to access this MSR on some Intel platforms without properly
> setting up a proper #GP handler, which leads to a immediate crash.
> 
> Emulate the access of this MSR by giving it a legal value (all values set to
> default, as defined by Intel SDM "RAPL Interfaces").
> 
> Fixes: 84e848fd7a1 ('x86/hvm: disallow access to unknown MSRs')

Hm, 

> Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
> ---
> Does it have a risk of negatively affecting other operating systems expecting
> this MSR read to fail ?
> ---
>  xen/arch/x86/include/asm/msr-index.h |  2 ++
>  xen/arch/x86/msr.c                   | 16 ++++++++++++++++
>  2 files changed, 18 insertions(+)
> 
> diff --git a/xen/arch/x86/include/asm/msr-index.h b/xen/arch/x86/include/asm/msr-index.h
> index 9cdb5b2625..2adcdf344f 100644
> --- a/xen/arch/x86/include/asm/msr-index.h
> +++ b/xen/arch/x86/include/asm/msr-index.h
> @@ -144,6 +144,8 @@
>  #define MSR_RTIT_ADDR_A(n)                 (0x00000580 + (n) * 2)
>  #define MSR_RTIT_ADDR_B(n)                 (0x00000581 + (n) * 2)
>  
> +#define MSR_RAPL_POWER_UNIT                 0x00000606
> +
>  #define MSR_U_CET                           0x000006a0
>  #define MSR_S_CET                           0x000006a2
>  #define  CET_SHSTK_EN                       (_AC(1, ULL) <<  0)
> diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
> index 289cf10b78..b14d42dacf 100644
> --- a/xen/arch/x86/msr.c
> +++ b/xen/arch/x86/msr.c
> @@ -169,6 +169,22 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val)
>          if ( likely(!is_cpufreq_controller(d)) || rdmsr_safe(msr, *val) == 0 )
>              break;
>          goto gp_fault;
> +    

Trailing spaces in the added newline.

> +        /*
> +         * Solaris 11.4 DomU tries to use read this MSR without setting up a
> +         * proper #GP handler leading to a crash. Emulate this MSR by giving a
> +         * legal value.
> +         */

The comment should be after (inside) the case statement IMO (but not
strong opinion.  Could you also raise a bug with Solaris and put a
link to the bug report here, so that we have a reference to it?

> +    case MSR_RAPL_POWER_UNIT:
> +        if ( !(cp->x86_vendor & (X86_VENDOR_INTEL | X86_VENDOR_CENTAUR)) )

Has Centaur ever released a CPU with RAPL?

> +            goto gp_fault;
> +
> +        /*
> +         * Return a legal register content with all default values defined in
> +         * Intel Architecture Software Developer Manual 16.10.1 RAPL Interfaces
> +         */
> +        *val = 0x0000A1003;

The SPR Specification defines the default as 000A0E03h:

* SDM:

Energy Status Units (bits 12:8): Energy related information (in
Joules) is based on the multiplier, 1/2^ESU; where ESU is an unsigned
integer represented by bits 12:8. Default value is 10000b, indicating
energy status unit is in 15.3 micro-Joules increment.

* SPR:

Energy Units (ENERGY_UNIT):
Energy Units used for power control registers.
The actual unit value is calculated by 1 J / Power(2,ENERGY_UNIT).
The default value of 14 corresponds to Ux.14 number.

Note that KVM just returns all 0s [0], so we might consider doing the
same, as otherwise that could lead OSes to poke at further RAPL
related MSRs if the returned value from MSR_RAPL_POWER_UNIT looks
plausible.

[0] https://elixir.bootlin.com/linux/v6.12.6/source/arch/x86/kvm/x86.c#L4236

Thanks.


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 09:32:50 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 09:32:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871064.1282110 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXdI1-0004H0-5w; Tue, 14 Jan 2025 09:32:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871064.1282110; Tue, 14 Jan 2025 09: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 <xen-devel-bounces@lists.xenproject.org>)
	id 1tXdI1-0004Gt-39; Tue, 14 Jan 2025 09:32:49 +0000
Received: by outflank-mailman (input) for mailman id 871064;
 Tue, 14 Jan 2025 09:32: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
 <SRS0=tIyo=UG=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tXdHz-0003ZR-SF
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 09:32:47 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 83dde6de-d25a-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 10:32:47 +0100 (CET)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-ab322ecd75dso120685466b.0
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 01:32:47 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c95b7317sm602044066b.154.2025.01.14.01.32.46
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 14 Jan 2025 01:32:46 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 83dde6de-d25a-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736847167; x=1737451967; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=B9S6pdDsNCp33mtAF7/BbRjeEO4D+sXhz+vsHSrTIR0=;
        b=Zv7GH+WtwUBfrVOE/SsskghlwpSszRchm1HkGfzGqi5eMZigD96gHezqLrsaoLqtMG
         Mmn1wb7fH31I87kpOzi5N9B5I8hiCBb0hOQCKJ09aAmvqbouILjTJhykISF4gDQjPJdJ
         16Wf+ME1NoC+9078dDbJL/eueSZRmHbNKrtgM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736847167; x=1737451967;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=B9S6pdDsNCp33mtAF7/BbRjeEO4D+sXhz+vsHSrTIR0=;
        b=m5mFoJPxzEQSqXaE7I8PbkdE0rCn3lncAVk2IACV4JwyKfsbRv704tIE+LmwikYsln
         4bdppxfs53vWEBAyGLQdongvZLlITljArTr3pQNSNK1zHTSlrwzL6eTtrBkZ6SdRGwmv
         VJVd6yjhj8xHGhPldlBVPCFHoUOCR5Vyo6qRaA6IMqBilIqh0LQSDuc4NAuPGhWU7vRO
         B5Vv+4mIyUuBOkeaE2p6TIGIwCeXLBf+HteOdA0k/WJuT9ggnRi+Tk0GJwhQ5se3GBip
         CZ86DtY+1wePuMmBQWf2UX5fU6b8j48455Kk8ztKNChAELgFt34HuFCMo/P2sB4mR+YI
         54qQ==
X-Forwarded-Encrypted: i=1; AJvYcCV30JxX9pZHI0o4HXp+gcGvm1yvXGb4IakbB+nr3D4A33LBhq94bhDdWeTNr46dlB0q9Dd5nK9dzyE=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx4GZzvAob7iviGFko4JO/vH8JiVkM4bZGYw8ZDhHP4fOi9cKzq
	h5dsGKwQ5Pfn/WeSX2AMm7OqQacst9PW2UJ0wq+m/cBkVoRc5716nK7HwYr3+Hg=
X-Gm-Gg: ASbGncs+084Z3uW6Ken4tgLDBw+DxADMkH4Z8iyfVOHb6bd7R5cSe3noBOQ4cXJmoe/
	0Ia8JcSEXgs4PzrzSwWsXEkQ9Np4LhLDEc2EZAY2H4B+eXrPU0DOm0UibM09JctId7Bc1TcEPOL
	8hVO6bJCvYvJ3eAOqfR5muCfpshKZ691mN4s3CQzLt0q72gnnOBsmD5RmJDFbqm/4OZD5TKA1tn
	bJh75mCuTyCidZQCNjtjGf8misOFumvDRN1wJKF181D8YYsRM0P/y1B4M0ykdLdgvelTgQaXoiq
	EvSfHxOyvqV5sjHMzw7x
X-Google-Smtp-Source: AGHT+IGt/EWC+NrUj3u542WA/piYX6HYdLSvUnDhmt7XC/QzS6Qd60I9LSfv8KeO4rNFoU8q33tDwA==
X-Received: by 2002:a17:907:c1c:b0:aab:882e:921e with SMTP id a640c23a62f3a-ab2c3c63988mr1917154966b.2.1736847166868;
        Tue, 14 Jan 2025 01:32:46 -0800 (PST)
Message-ID: <5b6b1ad2-c0cd-454c-aa7c-b6de37ab39df@citrix.com>
Date: Tue, 14 Jan 2025 09:32:45 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 0/4] Add/enable stack protector
To: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Stefano Stabellini <sstabellini@kernel.org>,
 Samuel Thibault <samuel.thibault@ens-lyon.org>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>,
 Community Manager <community.manager@xenproject.org>
References: <20250114042553.1624831-1-volodymyr_babchuk@epam.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <20250114042553.1624831-1-volodymyr_babchuk@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14/01/2025 4:25 am, Volodymyr Babchuk wrote:
> Volodymyr Babchuk (4):
>   common: remove -fno-stack-protector from EMBEDDED_EXTRA_CFLAGS
>   xen: common: add ability to enable stack protector
>   xen: arm: enable stack protector feature
>   CHANGELOG.md: Mention stack-protector feature

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

There's one minor formatting error which can be fixed on commit.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 09:41:56 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 09:41:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871080.1282119 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXdQl-0006OZ-WB; Tue, 14 Jan 2025 09:41:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871080.1282119; Tue, 14 Jan 2025 09:41:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXdQl-0006OS-TM; Tue, 14 Jan 2025 09:41:51 +0000
Received: by outflank-mailman (input) for mailman id 871080;
 Tue, 14 Jan 2025 09:41:51 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=tIyo=UG=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tXdQl-0006OM-2V
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 09:41:51 +0000
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [2a00:1450:4864:20::529])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c69938eb-d25b-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 10:41:48 +0100 (CET)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-5d7e3f1fdafso10798339a12.0
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 01:41:48 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c95aedf6sm609598166b.138.2025.01.14.01.41.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 14 Jan 2025 01:41:47 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c69938eb-d25b-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736847708; x=1737452508; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=qbKZ/I5/BSf1C9gMrLhzIhsUeM5QTjxrFIgWSD9Ya2c=;
        b=PKjcozhnW0nTv+EcKImYPi88uepsqLP4d1Mn5WzvkVWSeQ/gDeNTEQXVCc7J+9DCjC
         OJZHggS2jDfqjOMv/Rbo9pZ7l4bssxKrW7Ew/IZHt2qJeQ5NbLQoo08etpNULnA6vEZr
         wu8mX6VB1aLUE7kMulFwIm6umetJfcyoqL85g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736847708; x=1737452508;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=qbKZ/I5/BSf1C9gMrLhzIhsUeM5QTjxrFIgWSD9Ya2c=;
        b=XA6WzCTXGp9/XxObUxIfn8x9MBJ9MLfvU0k3pL0sZHeS8NMITOrJYmKqbOjOL4gDF9
         WAxbUPju4QwqjDeqRS0jTy+gHoYPZNl4ra4uwjElGo5BvYQMcwHXOYiSXZYxzgxIycy0
         Q1JAFJQ5NG916yspJCZyV2prSBcPokU1FO8vM1T9Cq9z31YleGiKp+meLRTaSqez4/Us
         9rU3BJC/hVU7GgmUb0cqpG8P9WpnUYBvB64BikZRiKZSVk6xRsIuCmX2haSb7d+FPsfF
         FMjLLvZI+2O07LVzfBCpFF1iolqRpvQlICcs9xTZd594gDM0cSqncWgC8DoIuex+UDIX
         8NOA==
X-Forwarded-Encrypted: i=1; AJvYcCUvvCsr2lRVoTZzfj9SPN61ThnEKcFmMMVqXuX5G2CcjFrBsrpU+xZghKd906k3XY73TU7MeWq3nFM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyA7E0p2lUpcxvNWT4XH8PMNoroyhbXA42b+v5WE3JMTOI9e5q3
	AFvo6mETQtyWGeRsHFaUn6U8r4bFqWtm1Fz3yimnD+EK2cu4cZgwWlVxgxp+oEs=
X-Gm-Gg: ASbGnctLO7sKqZCclzxIzTfENR5Mws5NoT/SvBm99fiSzmBr2p8Vp8fIo/zoih0btno
	k/hIuQ5oa8Xkb2W37Xpxq1vmfao9WXkG2rHzdeMiee6Z5iFpQoeSdrMULkqrxruesMA3rgymoEq
	oLTwzA8RIwXakfMRMbWgZ757taxHGyrJEm+OIsHUu98hEHJ5vtBkfXZyVaV55YrPsmvlQ6mji0m
	kVwyMLZ7FKHfgYAUX/vmK/yTS07HN0IQlmqgfSLSxWEfEFkNTLgmHTjXR2bgIOFBU4OwbM1XWHC
	6rznxWUQVHvggx6KW+E/
X-Google-Smtp-Source: AGHT+IHbY3/lzykXKUtBYmNvnWmFFA6MsHqSTLTSvu6XNPKaAdQeredSGb4Xw6Vbx3Hvehvp2C6a4Q==
X-Received: by 2002:a17:906:6a26:b0:aaf:73e4:e872 with SMTP id a640c23a62f3a-ab2ab16a9bbmr1768494966b.3.1736847708232;
        Tue, 14 Jan 2025 01:41:48 -0800 (PST)
Message-ID: <465406d2-5921-4c52-a95d-b3781b4184e8@citrix.com>
Date: Tue, 14 Jan 2025 09:41:47 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH] intel/msr: Fix handling of MSR_RAPL_POWER_UNIT
To: Teddy Astie <teddy.astie@vates.tech>, xen-devel@lists.xenproject.org
Cc: Jan Beulich <jbeulich@suse.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>
References: <0ac778dbcc7ab383447abe672225ff77b0d4802e.1736793323.git.teddy.astie@vates.tech>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <0ac778dbcc7ab383447abe672225ff77b0d4802e.1736793323.git.teddy.astie@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 13/01/2025 6:42 pm, Teddy Astie wrote:
> Solaris 11.4 tries

Is it only Solaris 11.4, or is the simply the one repro you had?

Have you reported a bug?

>  to access this MSR on some Intel platforms without properly
> setting up a proper #GP handler, which leads to a immediate crash.

Minor grammar note.  Either "without a proper #GP handler" or "without
properly setting up a #GP handler", but having two proper(ly)'s in there
is less than ideal.

> Emulate the access of this MSR by giving it a legal value (all values set to
> default, as defined by Intel SDM "RAPL Interfaces").
>
> Fixes: 84e848fd7a1 ('x86/hvm: disallow access to unknown MSRs')
> Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
> ---
> Does it have a risk of negatively affecting other operating systems expecting
> this MSR read to fail?

It's Complicated.

RAPL is a non-architectural feature (on Intel; AMD did it properly).  It
does not have a CPUID bit to announce the presence of the MSRs. 
Therefore OSes use a mixture of model numbers and {wr,rd}msr_safe() to
probe.

I expect this will change the behaviour of Linux.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 09:59:34 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 09:59:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871091.1282130 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXdhp-000090-Gp; Tue, 14 Jan 2025 09:59:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871091.1282130; Tue, 14 Jan 2025 09:59:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXdhp-00008t-DC; Tue, 14 Jan 2025 09:59:29 +0000
Received: by outflank-mailman (input) for mailman id 871091;
 Tue, 14 Jan 2025 09:59:27 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=s7Sb=UG=cloud.com=frediano.ziglio@srs-se1.protection.inumbo.net>)
 id 1tXdhn-00008n-Ng
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 09:59:27 +0000
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com
 [2a00:1450:4864:20::42b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3cf5f630-d25e-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 10:59:26 +0100 (CET)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-38634c35129so3670314f8f.3
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 01:59:26 -0800 (PST)
Received: from localhost.localdomain (158.79.208.46.dyn.plus.net.
 [46.208.79.158]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a8e37d472sm14122835f8f.1.2025.01.14.01.59.25
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 14 Jan 2025 01:59:25 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 3cf5f630-d25e-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736848766; x=1737453566; 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=a+xrt+pAnmWm6+wI3JBlJF8hkk0OkYfm2j70Ctdabm0=;
        b=APcJtI2qFh4qI/3ABBXd/2k7l6xKvKjA09eN+TE+cIXN7dYw7B/nQcXzUnSaikllzL
         W1m+eu7iReMSZMe2TBGs2oasBh7j142Pmpm3tnj0QdnnPhX9ws4CN8BuioMG1vuTrCIq
         oL/EBaI7jLWP3WW7FtHW+KSB9K8418xndzC3A=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736848766; x=1737453566;
        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=a+xrt+pAnmWm6+wI3JBlJF8hkk0OkYfm2j70Ctdabm0=;
        b=tmZ8nmPv1AioBr6z8R5ONSlMaSNzARGol0wHZz1uEd+hdoYuEqDNmlxwzxQkBpI5tr
         4bTsB13bVXbpy/I6Bj6htPhAjyfcmQ/sUY6WP45ul2wa5mU8T17fiTbnj4tb5pe0xpj7
         LfzsmXOWQd/V2NUdfOI2OyOQ8skwfTd8HbA7e9Z61pcRQWyRoEe/1mgEAyeEYASCHir1
         f8gvS3jUW10HEfiLwhIDF6SgF85He7SFgDBsQFJyYipZFtNOa7TU0I/3/g7hcmZL057Q
         Ifek+SE4UMBOGm9IgNVrIspu2xpT2IjettMsoONREzr8t3zySL43ZHPOm6lDv5fQB4Di
         820Q==
X-Gm-Message-State: AOJu0Yy+BUvR8lPbb+NRTeFeTDj7oMTuC2wohddQfaVckTfTgZEFK3XO
	lrsNTRLe8qXY0OpnGjaH9zBrgOmboUta7RqvqeR1wXYENIDGEn/sQFw+7fD7WU49xqmUfsN/RvU
	8
X-Gm-Gg: ASbGncssLk/Tuu9wlIt5k4unpu5uffKjUB2cvfGS4NHlOC1QCK7TYufwclXQUMllJ/P
	dg4cpGcGNbZw8G6qxZmsvSsa5pZcwC9cWFaOPi5VgHV2YX6Hp7x4/wuZvE5ZQpZk55qVB00ChjY
	v/7kgVYd9oP6MJ11SQodCscoYzf4nlo1AXwteq+bCnu1BNJZaiaWB7ssoW9lTE00/9EkbzSImiV
	ZerITgkWPQ7IlycPRD7TW7hNCw+OV9uH3netgBGy65OeYDpjhj8fDyyWzggbYxmvb9SgC20kJUx
	HtO9KtDmZlS3GYJmsX4YyTjFRpU=
X-Google-Smtp-Source: AGHT+IGIgnAf7V4ePzxUvvDXNDPPDmpTDsb+gCe6d2VFoSE/LHrWCUWBnI/zwIiL18w+NzWoRq9xrg==
X-Received: by 2002:a05:6000:2a2:b0:38a:8906:6b66 with SMTP id ffacd0b85a97d-38a89066f45mr24234071f8f.38.1736848765702;
        Tue, 14 Jan 2025 01:59:25 -0800 (PST)
From: Frediano Ziglio <frediano.ziglio@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio <frediano.ziglio@cloud.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH] x86/boot: Handle better alignment for 32 bit code
Date: Tue, 14 Jan 2025 09:59:14 +0000
Message-Id: <20250114095914.93226-1-frediano.ziglio@cloud.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Output file didn't have correct alignment.
Allows alignment into data or code up to 2mb.

Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
---
 xen/arch/x86/boot/Makefile        | 8 ++++----
 xen/tools/combine_two_binaries.py | 7 ++++++-
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
index 13d4583173..9a8ecba7aa 100644
--- a/xen/arch/x86/boot/Makefile
+++ b/xen/arch/x86/boot/Makefile
@@ -40,8 +40,8 @@ LD32 := $(LD) $(subst x86_64,i386,$(LDFLAGS_DIRECT))
 # are affected by both text_diff and text_gap.  Ensure the sum of gap and diff
 # is greater than 2^16 so that any 16bit relocations if present in the object
 # file turns into a build-time error.
-text_gap := 0x010200
-text_diff := 0x408020
+text_gap := 0x01c240
+text_diff := 0x7e3dc0
 
 $(obj)/build32.base.lds: AFLAGS-y += -DGAP=$(text_gap) -DTEXT_DIFF=$(text_diff)
 $(obj)/build32.offset.lds: AFLAGS-y += -DGAP=$(text_gap) -DTEXT_DIFF=$(text_diff) -DAPPLY_OFFSET
@@ -69,7 +69,6 @@ $(obj)/built-in-32.%.bin: $(obj)/build32.%.lds $(obj)/built-in-32.tmp.o
 	$(LD32) $(orphan-handling-y) -N -T $< -o $(@:bin=o) $(filter %.o,$^)
 	$(NM) -p --format=bsd $(@:bin=o) > $(@:bin=map)
 	$(OBJCOPY) -j .text -O binary $(@:bin=o) $@
-	rm -f $(@:bin=o)
 
 quiet_cmd_combine = GEN     $@
 cmd_combine = \
@@ -80,6 +79,7 @@ cmd_combine = \
               --bin1      $(obj)/built-in-32.base.bin \
               --bin2      $(obj)/built-in-32.offset.bin \
               --map       $(obj)/built-in-32.base.map \
+              --align     $(shell $(OBJDUMP) -h $(obj)/built-in-32.base.o|sed '/text.*2\*\*/ {s/.*2\*\*//;p;}; d') \
               --exports   cmdline_parse_early,reloc,reloc_trampoline32 \
               --output    $@
 
@@ -90,4 +90,4 @@ $(obj)/built-in-32.S: $(obj)/built-in-32.base.bin $(obj)/built-in-32.offset.bin
                       $(srctree)/tools/combine_two_binaries.py FORCE
 	$(call if_changed,combine)
 
-clean-files := built-in-32.*.bin built-in-32.*.map build32.*.lds
+clean-files := built-in-32.*.bin built-in-32.*.map built-in-32.*.o build32.*.lds
diff --git a/xen/tools/combine_two_binaries.py b/xen/tools/combine_two_binaries.py
index 581e57cbc0..8e587c24fb 100755
--- a/xen/tools/combine_two_binaries.py
+++ b/xen/tools/combine_two_binaries.py
@@ -26,6 +26,10 @@ parser.add_argument('--text-diff', dest='text_diff',
                     required=True,
                     type=auto_int,
                     help='Difference between code section start')
+parser.add_argument('--align', dest='align',
+                    default=2,
+                    type=auto_int,
+                    help='Alignment in power of 2')
 parser.add_argument('--output', dest='output',
                     help='Output file')
 parser.add_argument('--map', dest='mapfile',
@@ -93,7 +97,7 @@ if size1 > size2:
     file1, file2 = file2, file1
     size1, size2 = size2, size1
 if size2 != size1 + gap:
-    raise Exception('File sizes do not match')
+    raise Exception('File sizes do not match %d != %d + %d' % (size2, size1, gap))
 del size2
 
 file1.seek(0, 0)
@@ -219,6 +223,7 @@ print('''/*
  * File autogenerated by combine_two_binaries.py DO NOT EDIT
  */''', file=out)
 print('\t' + args.section_header, file=out)
+print('\t.p2align\t' + str(args.align), file=out)
 print('obj32_start:', file=out)
 output(out)
 print('\n\t.section .note.GNU-stack,"",@progbits', file=out)
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 10:34:59 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 10:34:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871107.1282139 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXeG2-0006T0-26; Tue, 14 Jan 2025 10:34:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871107.1282139; Tue, 14 Jan 2025 10:34:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXeG1-0006St-VH; Tue, 14 Jan 2025 10:34:49 +0000
Received: by outflank-mailman (input) for mailman id 871107;
 Tue, 14 Jan 2025 10:34: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
 <SRS0=iLru=UG=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tXeG1-0006Sh-8o
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 10:34:49 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2bc6535e-d263-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 11:34:45 +0100 (CET)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-aab925654d9so298300866b.2
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 02:34:45 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c956479asm611975466b.116.2025.01.14.02.34.43
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 14 Jan 2025 02:34:44 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2bc6535e-d263-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736850885; x=1737455685; 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=wQwSjXI241hYCdXgNAwQNCsum6/0WR1kpNNnkcYE330=;
        b=sCrjstGYfihAhzrp2wvEczUzvmmvwOHwHwSSgja7L94SUTNiYQaGULrXTz0ZK0GIPN
         y+n8v0SPd4jv7WCPEuYcj0oxtb73o0EO81KiBKLjB7pYv9rnCV1wh0Sz9NEU27LqENN/
         fy/UEpm4pDn/mmUGfI50aD5U6zp4rQAO7ppbY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736850885; x=1737455685;
        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=wQwSjXI241hYCdXgNAwQNCsum6/0WR1kpNNnkcYE330=;
        b=Gfn/WGESkCTKGvcKHR8OWSxqp10wh+grrM2Nwvbx1DdJex3vEekNwOGIwD2f38HJAv
         nzMGdv9WRKw1Pz8cpMUzD5/XxWzs2oP3Vmzvqo5u1xNF1AfNhGAq2HsQNjhtV1TAkg6d
         38eHe6oeZXpv3h7vP3R85tXYtm6jNTCdenOSmT7JX9gl6mv6Yklm33k0AnDO7gvM/OAZ
         PSCuPme/ddyy42wsrafiE0WwDJm3kMQBsRoSswBuMMUWqCuxJf3iWR/eaVfdvKK0PeYh
         KbYo6pK1sFAybu5xv3naS87/j4OIC8zetZR2Sb0MIiF1aZExbQhzX+O/FqqqDugwJFVd
         DvQQ==
X-Forwarded-Encrypted: i=1; AJvYcCXeIKSaY+e5zfqBsAwSSICAjPZHohErvSDtBlw1pGSbQgEb5ZPymNkaZPSBIZiFIZND0pxFR9MEvlQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx1ww9YanU5FFynDjXVSNyWxqe8ATRZxGsmMMsv0bqpZP2wHnaB
	Leuf/IBWEzEpMTCloEFlfbK9h6KBSddhxJnkZB5CfdS29IMVkMtkjBQ1Sbg+XQs=
X-Gm-Gg: ASbGncucP59tEC+sGG5lENQJIdA05Dx5BiQWZqFeqB48oOn7Xh6bQLq1hjbnK5WEuQI
	A/9mgEgtCPTmK5pPV/cpMTod4X/MRQ75tvcLGTNWmsu1Xcbpt1wdt5NR+XfXfzhf8Z+FY3JizMV
	4Q0mHrhX8fOkOykzyhdObB10hL4NmCnMTVOHuTN8FUyM8FaJqos3CRtJ/k/vayu4szUfTOEyykP
	WKjKLkrhCYRSIBwVZXfpaVlEYLbovGF2u3I9LVa9FNU8Fvzb4qmNRLSD60Z7MtGRBw=
X-Google-Smtp-Source: AGHT+IGj7ARHxTxMk2ZMpt+SBomtNarwYt9nXspoozduRWM9XmoJhTSEuJ+ewJ9qdrVRqwpHP4I48w==
X-Received: by 2002:a17:907:704:b0:aae:bd36:b198 with SMTP id a640c23a62f3a-ab2abcab421mr2297280466b.47.1736850884836;
        Tue, 14 Jan 2025 02:34:44 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: linux-kernel@vger.kernel.org,
	xen-devel@lists.xenproject.org
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [PATCH v2 0/3] xen: fix usage of devices behind a VMD bridge
Date: Tue, 14 Jan 2025 11:33:10 +0100
Message-ID: <20250114103315.51328-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Hello,

The following series should fix the usage of devices behind a VMD bridge
when running Linux as a Xen PV hardware domain (dom0).  I've only been
able to test PV. I think PVH should also work but I don't have hardware
capable of testing it right now.

I don't expect the first two patches to be problematic, the last patch
is likely to be more controversial.  I've tested it internally and
didn't see any issues, but my testing of PV mode is mostly limited to
dom0.

Thanks, Roger.

Roger Pau Monne (3):
  xen/pci: do not register devices with segments >= 0x10000
  vmd: disable MSI remapping bypass under Xen
  pci/msi: remove pci_msi_ignore_mask

 arch/x86/pci/xen.c           |  8 ++------
 drivers/pci/controller/vmd.c | 19 ++++++++++++++++++
 drivers/pci/msi/msi.c        | 37 ++++++++++++++++++++----------------
 drivers/xen/pci.c            | 19 ++++++++++++++++++
 include/linux/msi.h          |  3 ++-
 kernel/irq/msi.c             |  2 +-
 6 files changed, 64 insertions(+), 24 deletions(-)

-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 10:34:59 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 10:34:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871108.1282145 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXeG2-0006Vr-AR; Tue, 14 Jan 2025 10:34:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871108.1282145; Tue, 14 Jan 2025 10:34:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXeG2-0006UY-5g; Tue, 14 Jan 2025 10:34:50 +0000
Received: by outflank-mailman (input) for mailman id 871108;
 Tue, 14 Jan 2025 10:34: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
 <SRS0=iLru=UG=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tXeG1-0006Sh-Hu
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 10:34:49 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2d233095-d263-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 11:34:47 +0100 (CET)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-aa679ad4265so145273766b.0
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 02:34:47 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c9060533sm614255366b.23.2025.01.14.02.34.45
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 14 Jan 2025 02:34:46 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2d233095-d263-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736850887; x=1737455687; 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=9ZU2rMw7aFNypI2l6diI5iIm2rhPqMg33NxACGe4Tyg=;
        b=GNCyW5FZrA/+lopzbAAbKj6lGKPj88F19h47zBKOERhrsG7f4CRg9OZqD325Xbt2eK
         6muyF5HpzMNWg4Q3a7BlHy4TLINfLqF8hBX9UDyfgiBJCRj6gOFN21sCD+p7EC7zag5a
         ga7m4oPV1jfo7XD0K57GZVjBz1IY0H3kHpKzE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736850887; x=1737455687;
        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=9ZU2rMw7aFNypI2l6diI5iIm2rhPqMg33NxACGe4Tyg=;
        b=DIvPE3yoUMyD/r9GjaOtKb/QS4Lb0C3/sqkEo+veZGiIUmvZyfHy4eeWUpVgDc2yMj
         VHTUyMqC7fSc9XUcGLwoh80ho0GW8Qy0QGeXbqGXCQruAB0YLwd8HEWoYWiyoddek3XV
         mof9vbEJMoyLfwT3RsdYe954gpR2fiyxVeO7cyFFck7IWvsrVOtGH0jsgOe3d+nBcSAf
         WIYOLnrm3yl78cQwQtNV+odkz/v1enTHtbDQw+Qz1IfhwEdyUkjzqX6sx0MtIQh40AVR
         cOP9EAKyAXs7/EaFsd4fg2TD7wZAmLiCbkTVXpfepqAHmSQU/+147MaZiFImOpOz5ml5
         TJ0g==
X-Forwarded-Encrypted: i=1; AJvYcCVEmN7bs+Kkz3nDfI+e/bkDyESn7hCRUeCG5Z7H5rQBy8bxVqqlR9P6elbFlC49cq+Pi/s25dOhR6M=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywp5eiwDcNGHJAULsjRC6TzkEKUH6ccIoTeVP2qlhmrfPpz0nW4
	X+VeDa8x+nhktRkl58d9OpGs7i7mqAg9FSZx0HI2dxFN5eAli7GI85tY+i8kdP0=
X-Gm-Gg: ASbGncu5gX7MoAXzmnwhq8rts2LdN33aXJiO9xrDCiOq/O2fxCXCZlJeQZJMIes6gsu
	0RFoImG4Ymnzx2is5Iqt0IxoCjqkReldQ1n/lVvhZEHC99cu/xgTjxanAiTaAH16DurHyKOd/M6
	E7T10gQDnxnRDxhgS14ADz+k49um7XpI/LwNi3hOnf5mVDY1zGUFckSTaDXLxrUU6yxHQG5m3RE
	9yliW18WOBsx+8H+Jjdz7/8Tn3M2I3Ht5ydWxr2ZBwI1mL9Lt9FXrXsNcWtnYj+HvA=
X-Google-Smtp-Source: AGHT+IGrlgmiY5VqhHCHxlAvhEi6Yk1f8mgu/4U5ZjNErcoWMIXni6SJK+Ov+D9vuAGhmZvwfqL6FQ==
X-Received: by 2002:a17:907:3ea3:b0:aac:333:a0a1 with SMTP id a640c23a62f3a-ab2c3d3e817mr1696220466b.32.1736850887183;
        Tue, 14 Jan 2025 02:34:47 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: linux-kernel@vger.kernel.org,
	xen-devel@lists.xenproject.org
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Juergen Gross <jgross@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Subject: [PATCH v2 1/3] xen/pci: do not register devices with segments >= 0x10000
Date: Tue, 14 Jan 2025 11:33:11 +0100
Message-ID: <20250114103315.51328-2-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250114103315.51328-1-roger.pau@citrix.com>
References: <20250114103315.51328-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The current hypercall interface for doing PCI device operations always uses
a segment field that has a 16 bit width.  However on Linux there are buses
like VMD that hook up devices into the PCI hierarchy at segment >= 0x10000,
after the maximum possible segment enumerated in ACPI.

Attempting to register or manage those devices with Xen would result in
errors at best, or overlaps with existing devices living on the truncated
equivalent segment values.  Note also that the VMD segment numbers are
arbitrarily assigned by the OS, and hence there would need to be some
negotiation between Xen and the OS to agree on how to enumerate VMD
segments and devices behind them.

Skip notifying Xen about those devices.  Given how VMD bridges can
multiplex interrupts on behalf of devices behind them there's no need for
Xen to be aware of such devices for them to be usable by Linux.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Changes since v1:
 - Adjust commit message width to 75 columns.
 - Expand commit message.
---
 drivers/xen/pci.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/drivers/xen/pci.c b/drivers/xen/pci.c
index 416f231809cb..08e82fd1263e 100644
--- a/drivers/xen/pci.c
+++ b/drivers/xen/pci.c
@@ -43,6 +43,13 @@ static int xen_add_device(struct device *dev)
 		pci_mcfg_reserved = true;
 	}
 #endif
+
+	if (pci_domain_nr(pci_dev->bus) >> 16) {
+		dev_info(dev,
+			 "not registering with Xen: invalid PCI segment\n");
+		return 0;
+	}
+
 	if (pci_seg_supported) {
 		DEFINE_RAW_FLEX(struct physdev_pci_device_add, add, optarr, 1);
 
@@ -149,6 +156,12 @@ static int xen_remove_device(struct device *dev)
 	int r;
 	struct pci_dev *pci_dev = to_pci_dev(dev);
 
+	if (pci_domain_nr(pci_dev->bus) >> 16) {
+		dev_info(dev,
+			 "not unregistering with Xen: invalid PCI segment\n");
+		return 0;
+	}
+
 	if (pci_seg_supported) {
 		struct physdev_pci_device device = {
 			.seg = pci_domain_nr(pci_dev->bus),
@@ -182,6 +195,12 @@ int xen_reset_device(const struct pci_dev *dev)
 		.flags = PCI_DEVICE_RESET_FLR,
 	};
 
+	if (pci_domain_nr(dev->bus) >> 16) {
+		dev_info(&dev->dev,
+			 "unable to notify Xen of device reset: invalid PCI segment\n");
+		return 0;
+	}
+
 	return HYPERVISOR_physdev_op(PHYSDEVOP_pci_device_reset, &device);
 }
 EXPORT_SYMBOL_GPL(xen_reset_device);
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 10:34:59 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 10:34:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871109.1282159 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXeG6-0006wB-GN; Tue, 14 Jan 2025 10:34:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871109.1282159; Tue, 14 Jan 2025 10:34:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXeG6-0006w4-Da; Tue, 14 Jan 2025 10:34:54 +0000
Received: by outflank-mailman (input) for mailman id 871109;
 Tue, 14 Jan 2025 10:34:53 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=iLru=UG=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tXeG5-0006up-GI
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 10:34:53 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2e7e0a50-d263-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 11:34:50 +0100 (CET)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-aaee0b309adso873307566b.3
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 02:34:50 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c913605csm608116266b.82.2025.01.14.02.34.48
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 14 Jan 2025 02:34:48 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2e7e0a50-d263-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736850889; x=1737455689; 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=8aKUOtOG9BVgReGI+Nw2NzmnaZPU8conWgd+JDzRbKo=;
        b=PEF0JckHlBB5UuSMXMf3o/TTr0oR4JR/dBXCz6JAonXaY4eAf+XgxG3dMuT9jQIT8i
         BkFJXrnsCPuaQDp9RYaL8h6B0s3bdLwzE6WQ1GC+A01ntBMd/t+3Pig0kAEtQljsMUNq
         hUK84aLw5frsu4tn9+cySDJEoAlivNQQMTaT0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736850889; x=1737455689;
        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=8aKUOtOG9BVgReGI+Nw2NzmnaZPU8conWgd+JDzRbKo=;
        b=Whk7UM1J3zyvEbSnvkm5uKBY3GwCmMzsZA9VQWYl5LtOe6HYyvxjvNuEMdzkmvF9Rc
         Kvzw0eE5Sxak6aRQhre1MRXVKQ/ZtgKjfmhgpsX/UvKUeUIDHWiSmWgGs+7HeXqLztPi
         VbflmSLbpgjZwTZU7o7AqFmQgPmZGoNsAnIbtXLd6DpxT8Ib/DtJs6rSc+ay4AOXNM+h
         lP0VfIJ6bSSBuz0MwD9L7xr75cJFwrWYuPKSrQ8ZwrlOmAq8HIzp8jlBMQuW7OZd7FDr
         WTCsdO7qA0Zish0m9eGxxj+y6umHFeSIjxmYoLXAjvoVjA7xkj7kLuch3yHr8Es1QqNq
         LQ/g==
X-Forwarded-Encrypted: i=1; AJvYcCVgYmn+S0NJTgSP1lHPtLJrTiULiQUyzK0eSkNNR9uFxDuzpw6jpx7ZHVgv8aZGLYSk4oBzi5fHJ0E=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyVAU9uBzVi/5ETPCKzFAd4Oiyo8q9GVrYXmTpPieBULovY/QcZ
	THXwyIz5Cr8BPrKTBrdAlf+SkDWZcotOGU7UdpOBBQ2q8cBJK9z/MLvRBBzkDsM=
X-Gm-Gg: ASbGncu83HbuqOJ+nfOeX9PYv1f4/ijD9/0TGm5V5AdYp2Ibjpx483Fq5/iX0X3M/xB
	skfa77e0eoyCzwI20ARksg7a4iYz6qOi9i9wXxw+56iJ1dq5nzlxTMs+jsV1U0Pm7HyypBckrEh
	OyjDP3pwDpOj9tdFNapgq1TlnyVsax9xIRJsBnPTwRzuH8vr0Hg8TbEoJm5YB0Ek+arzy7/FKI9
	9sBouoUat7MTlSvjJ+GsTlEub1WUs1pDqjfEl2RcBFSlEoJfQp7jDHIxGE5YG8QMFE=
X-Google-Smtp-Source: AGHT+IHu5De2z/QFEQRsmLROwHRAnH4F5r3sr8PBreqTBE5z0L97HWAie9gr7imKD5uPM/cH1y3q+A==
X-Received: by 2002:a17:906:4fcb:b0:ab2:fefe:7156 with SMTP id a640c23a62f3a-ab2fefe94f8mr1052272666b.43.1736850889114;
        Tue, 14 Jan 2025 02:34:49 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: linux-kernel@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	linux-pci@vger.kernel.org
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Nirmal Patel <nirmal.patel@linux.intel.com>,
	Jonathan Derrick <jonathan.derrick@linux.dev>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	=?UTF-8?q?Krzysztof=20Wilczy=C5=84ski?= <kw@linux.com>,
	Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
	Rob Herring <robh@kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>
Subject: [PATCH v2 2/3] vmd: disable MSI remapping bypass under Xen
Date: Tue, 14 Jan 2025 11:33:12 +0100
Message-ID: <20250114103315.51328-3-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250114103315.51328-1-roger.pau@citrix.com>
References: <20250114103315.51328-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

MSI remapping bypass (directly configuring MSI entries for devices on the
VMD bus) won't work under Xen, as Xen is not aware of devices in such bus,
and hence cannot configure the entries using the pIRQ interface in the PV
case, and in the PVH case traps won't be setup for MSI entries for such
devices.

Until Xen is aware of devices in the VMD bus prevent the
VMD_FEAT_CAN_BYPASS_MSI_REMAP capability from being used when running as
any kind of Xen guest.

The MSI remapping bypass is an optional feature of VMD bridges, and hence
when running under Xen it will be masked and devices will be forced to
redirect its interrupts from the VMD bridge.  That mode of operation must
always be supported by VMD bridges and works when Xen is not aware of
devices behind the VMD bridge.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Changes since v1:
 - Add xen header.
 - Expand comment.
---
 drivers/pci/controller/vmd.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
index 264a180403a0..33c9514bd926 100644
--- a/drivers/pci/controller/vmd.c
+++ b/drivers/pci/controller/vmd.c
@@ -17,6 +17,8 @@
 #include <linux/rculist.h>
 #include <linux/rcupdate.h>
 
+#include <xen/xen.h>
+
 #include <asm/irqdomain.h>
 
 #define VMD_CFGBAR	0
@@ -965,6 +967,23 @@ static int vmd_probe(struct pci_dev *dev, const struct pci_device_id *id)
 	struct vmd_dev *vmd;
 	int err;
 
+	if (xen_domain())
+		/*
+		 * Xen doesn't have knowledge about devices in the VMD bus
+		 * because the config space of devices behind the VMD bridge is
+		 * not known to Xen, and hence Xen cannot discover or configure
+		 * them in any way.
+		 *
+		 * Bypass of MSI remapping won't work in that case as direct
+		 * write by Linux to the MSI entries won't result in functional
+		 * interrupts, as it's Xen the entity that manages the host
+		 * interrupt controller and must configure interrupts.
+		 * However multiplexing of interrupts by the VMD bridge will
+		 * work under Xen, so force the usage of that mode which must
+		 * always be supported by VMD bridges.
+		 */
+		features &= ~VMD_FEAT_CAN_BYPASS_MSI_REMAP;
+
 	if (resource_size(&dev->resource[VMD_CFGBAR]) < (1 << 20))
 		return -ENOMEM;
 
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 10:34:59 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 10:34:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871110.1282167 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXeG6-0006zi-RJ; Tue, 14 Jan 2025 10:34:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871110.1282167; Tue, 14 Jan 2025 10:34:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXeG6-0006z1-LT; Tue, 14 Jan 2025 10:34:54 +0000
Received: by outflank-mailman (input) for mailman id 871110;
 Tue, 14 Jan 2025 10:34:53 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=iLru=UG=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tXeG5-0006up-NR
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 10:34:53 +0000
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com
 [2a00:1450:4864:20::62e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 301d3e0f-d263-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 11:34:52 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-aafc9d75f8bso1027303966b.2
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 02:34:52 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c96475besm608318466b.180.2025.01.14.02.34.50
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 14 Jan 2025 02:34:50 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 301d3e0f-d263-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736850892; x=1737455692; 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=pp4xDXQjDMI49K9qEvJ9bqARGwd0TmK51XhdPXSIbuI=;
        b=g0neuc/s4W5PIB1qGre1todaHjpVyFXn6h1Nw5BhFGw/Cq5rBi8ONTWPTVi/oM4dWX
         DMg0RhAa9aVv69zq5iFJvQP8+z9HQhax2QlefENpE3MfkNlszX4Z3hjfRIF229YfUV3w
         tQeGTXronlWpKFfyBcf3+LY93BwBI/HTfR/1E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736850892; x=1737455692;
        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=pp4xDXQjDMI49K9qEvJ9bqARGwd0TmK51XhdPXSIbuI=;
        b=wkkiYj4og+6cuK+/5DwOMbG+F881unaffmjbj7L6+dAtFBOpg95zUKUd0HfMMYBedx
         FDZJsdOCo8pavVH4LKVzw4UzC/i1SL6IKaeAaRr2jSZ3NB2a/q8AOHbfXdwO4xu8Y4c7
         /AXotucnGvBuuutp+R4rD/Lup2OZBNxs+g9PiA81zBh1AufluhK4g7Lu2ZvOPZWez0bt
         ijlTzHdH4U/MYQOriHWndQPOssHG1GUQvkIQCySqNfgDpdzkEu7cN8WVOKkIRnnLW4vi
         P2qWeiebSo0VTfIDT9UIGh3I/JGHsEDAdjE9dc1f5bLpUFlW61jsDkWbBsYR9TbsQTIR
         H39A==
X-Forwarded-Encrypted: i=1; AJvYcCVk2ul940dd+wihq50qganaROArvaYRVJ0vA8GpboK7ePVu7aYd20BrVR1f4XWumFJKNZHLdal+at0=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx6vDQRLZiPqqPIGtjY2lIcNNO+n6z2Qjjx3hg4AIbBTBHFNcmA
	rls3BPLvsD17c/dDpE9+x9xRP8JhY3vQGjmXE1AJL5z1CX6B362Nj/r4amxGXZ8=
X-Gm-Gg: ASbGnctePsKD9cKkstB9kvE9OQOXgH8FlKxNBQmk6d/2CoZwPW0WjEp8iJ5caLzyrlb
	YDVGTRcAvpXzsI0wulYn36to9i9WqNiNl+/1BY4QD8zmf1kEhmzOY/xqPISQBYovj5K59eD1n+b
	kF2DbYaVe6Mw5R+yrNEdVJvk6iLqh+0R/3It+37cybGCBILCx7cLmW71wN44bAJKqRQj3yN/J7C
	D7/ix6+B4FyyCRxxRdqtQ3VTIShEwBT8C6mll0gj5uThUQf1F+F3GhKUEm4Ysvw0bw=
X-Google-Smtp-Source: AGHT+IGXqQ3VAh46MQysKbOAR+DLjCoKyT5Dy9LF7Cz4wRYLy+8kN1pTiCGZzrg1gwpYg14rVYHFOQ==
X-Received: by 2002:a17:907:1c98:b0:ab3:3b81:876f with SMTP id a640c23a62f3a-ab33b818a59mr177651466b.4.1736850891725;
        Tue, 14 Jan 2025 02:34:51 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: linux-kernel@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	linux-pci@vger.kernel.org
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Juergen Gross <jgross@suse.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: [PATCH v2 3/3] pci/msi: remove pci_msi_ignore_mask
Date: Tue, 14 Jan 2025 11:33:13 +0100
Message-ID: <20250114103315.51328-4-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250114103315.51328-1-roger.pau@citrix.com>
References: <20250114103315.51328-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Setting pci_msi_ignore_mask inhibits the toggling of the mask bit for both
MSI and MSI-X entries globally, regardless of the IRQ chip they are using.
Only Xen sets the pci_msi_ignore_mask when routing physical interrupts over
event channels, to prevent PCI code from attempting to toggle the maskbit,
as it's Xen that controls the bit.

However, the pci_msi_ignore_mask being global will affect devices that use
MSI interrupts but are not routing those interrupts over event channels
(not using the Xen pIRQ chip).  One example is devices behind a VMD PCI
bridge.  In that scenario the VMD bridge configures MSI(-X) using the
normal IRQ chip (the pIRQ one in the Xen case), and devices behind the
bridge configure the MSI entries using indexes into the VMD bridge MSI
table.  The VMD bridge then demultiplexes such interrupts and delivers to
the destination device(s).  Having pci_msi_ignore_mask set in that scenario
prevents (un)masking of MSI entries for devices behind the VMD bridge.

Move the signaling of no entry masking into the MSI domain flags, as that
allows setting it on a per-domain basis.  Set it for the Xen MSI domain
that uses the pIRQ chip, while leaving it unset for the rest of the
cases.

Remove pci_msi_ignore_mask at once, since it was only used by Xen code, and
with Xen dropping usage the variable is unneeded.

This fixes using devices behind a VMD bridge on Xen PV hardware domains.

Albeit Devices behind a VMD bridge are not known to Xen, that doesn't mean
Linux cannot use them.  By inhibiting the usage of
VMD_FEAT_CAN_BYPASS_MSI_REMAP and the removal of the pci_msi_ignore_mask
bodge devices behind a VMD bridge do work fine when use from a Linux Xen
hardware domain.  That's the whole point of the series.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Changes since v1:
 - Fix build.
 - Expand commit message.
---
 arch/x86/pci/xen.c    |  8 ++------
 drivers/pci/msi/msi.c | 37 +++++++++++++++++++++----------------
 include/linux/msi.h   |  3 ++-
 kernel/irq/msi.c      |  2 +-
 4 files changed, 26 insertions(+), 24 deletions(-)

diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 0f2fe524f60d..b8755cde2419 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -436,7 +436,8 @@ static struct msi_domain_ops xen_pci_msi_domain_ops = {
 };
 
 static struct msi_domain_info xen_pci_msi_domain_info = {
-	.flags			= MSI_FLAG_PCI_MSIX | MSI_FLAG_FREE_MSI_DESCS | MSI_FLAG_DEV_SYSFS,
+	.flags			= MSI_FLAG_PCI_MSIX | MSI_FLAG_FREE_MSI_DESCS |
+				  MSI_FLAG_DEV_SYSFS | MSI_FLAG_NO_MASK,
 	.ops			= &xen_pci_msi_domain_ops,
 };
 
@@ -484,11 +485,6 @@ static __init void xen_setup_pci_msi(void)
 	 * in allocating the native domain and never use it.
 	 */
 	x86_init.irqs.create_pci_msi_domain = xen_create_pci_msi_domain;
-	/*
-	 * With XEN PIRQ/Eventchannels in use PCI/MSI[-X] masking is solely
-	 * controlled by the hypervisor.
-	 */
-	pci_msi_ignore_mask = 1;
 }
 
 #else /* CONFIG_PCI_MSI */
diff --git a/drivers/pci/msi/msi.c b/drivers/pci/msi/msi.c
index 3a45879d85db..dcbb4f9ac578 100644
--- a/drivers/pci/msi/msi.c
+++ b/drivers/pci/msi/msi.c
@@ -10,12 +10,12 @@
 #include <linux/err.h>
 #include <linux/export.h>
 #include <linux/irq.h>
+#include <linux/irqdomain.h>
 
 #include "../pci.h"
 #include "msi.h"
 
 int pci_msi_enable = 1;
-int pci_msi_ignore_mask;
 
 /**
  * pci_msi_supported - check whether MSI may be enabled on a device
@@ -285,6 +285,8 @@ static void pci_msi_set_enable(struct pci_dev *dev, int enable)
 static int msi_setup_msi_desc(struct pci_dev *dev, int nvec,
 			      struct irq_affinity_desc *masks)
 {
+	const struct irq_domain *d = dev_get_msi_domain(&dev->dev);
+	const struct msi_domain_info *info = d->host_data;
 	struct msi_desc desc;
 	u16 control;
 
@@ -295,8 +297,7 @@ static int msi_setup_msi_desc(struct pci_dev *dev, int nvec,
 	/* Lies, damned lies, and MSIs */
 	if (dev->dev_flags & PCI_DEV_FLAGS_HAS_MSI_MASKING)
 		control |= PCI_MSI_FLAGS_MASKBIT;
-	/* Respect XEN's mask disabling */
-	if (pci_msi_ignore_mask)
+	if (info->flags & MSI_FLAG_NO_MASK)
 		control &= ~PCI_MSI_FLAGS_MASKBIT;
 
 	desc.nvec_used			= nvec;
@@ -600,12 +601,15 @@ static void __iomem *msix_map_region(struct pci_dev *dev,
  */
 void msix_prepare_msi_desc(struct pci_dev *dev, struct msi_desc *desc)
 {
+	const struct irq_domain *d = dev_get_msi_domain(&dev->dev);
+	const struct msi_domain_info *info = d->host_data;
+
 	desc->nvec_used				= 1;
 	desc->pci.msi_attrib.is_msix		= 1;
 	desc->pci.msi_attrib.is_64		= 1;
 	desc->pci.msi_attrib.default_irq	= dev->irq;
 	desc->pci.mask_base			= dev->msix_base;
-	desc->pci.msi_attrib.can_mask		= !pci_msi_ignore_mask &&
+	desc->pci.msi_attrib.can_mask		= !(info->flags & MSI_FLAG_NO_MASK) &&
 						  !desc->pci.msi_attrib.is_virtual;
 
 	if (desc->pci.msi_attrib.can_mask) {
@@ -655,9 +659,6 @@ static void msix_mask_all(void __iomem *base, int tsize)
 	u32 ctrl = PCI_MSIX_ENTRY_CTRL_MASKBIT;
 	int i;
 
-	if (pci_msi_ignore_mask)
-		return;
-
 	for (i = 0; i < tsize; i++, base += PCI_MSIX_ENTRY_SIZE)
 		writel(ctrl, base + PCI_MSIX_ENTRY_VECTOR_CTRL);
 }
@@ -710,6 +711,8 @@ static int msix_setup_interrupts(struct pci_dev *dev, struct msix_entry *entries
 static int msix_capability_init(struct pci_dev *dev, struct msix_entry *entries,
 				int nvec, struct irq_affinity *affd)
 {
+	const struct irq_domain *d = dev_get_msi_domain(&dev->dev);
+	const struct msi_domain_info *info = d->host_data;
 	int ret, tsize;
 	u16 control;
 
@@ -740,15 +743,17 @@ static int msix_capability_init(struct pci_dev *dev, struct msix_entry *entries,
 	/* Disable INTX */
 	pci_intx_for_msi(dev, 0);
 
-	/*
-	 * Ensure that all table entries are masked to prevent
-	 * stale entries from firing in a crash kernel.
-	 *
-	 * Done late to deal with a broken Marvell NVME device
-	 * which takes the MSI-X mask bits into account even
-	 * when MSI-X is disabled, which prevents MSI delivery.
-	 */
-	msix_mask_all(dev->msix_base, tsize);
+	if (!(info->flags & MSI_FLAG_NO_MASK)) {
+		/*
+		 * Ensure that all table entries are masked to prevent
+		 * stale entries from firing in a crash kernel.
+		 *
+		 * Done late to deal with a broken Marvell NVME device
+		 * which takes the MSI-X mask bits into account even
+		 * when MSI-X is disabled, which prevents MSI delivery.
+		 */
+		msix_mask_all(dev->msix_base, tsize);
+	}
 	pci_msix_clear_and_set_ctrl(dev, PCI_MSIX_FLAGS_MASKALL, 0);
 
 	pcibios_free_irq(dev);
diff --git a/include/linux/msi.h b/include/linux/msi.h
index b10093c4d00e..59a421fc42bf 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -73,7 +73,6 @@ struct msi_msg {
 	};
 };
 
-extern int pci_msi_ignore_mask;
 /* Helper functions */
 struct msi_desc;
 struct pci_dev;
@@ -556,6 +555,8 @@ enum {
 	MSI_FLAG_PCI_MSIX_ALLOC_DYN	= (1 << 20),
 	/* PCI MSIs cannot be steered separately to CPU cores */
 	MSI_FLAG_NO_AFFINITY		= (1 << 21),
+	/* Inhibit usage of entry masking */
+	MSI_FLAG_NO_MASK		= (1 << 22),
 };
 
 /**
diff --git a/kernel/irq/msi.c b/kernel/irq/msi.c
index 396a067a8a56..7682c36cbccc 100644
--- a/kernel/irq/msi.c
+++ b/kernel/irq/msi.c
@@ -1143,7 +1143,7 @@ static bool msi_check_reservation_mode(struct irq_domain *domain,
 	if (!(info->flags & MSI_FLAG_MUST_REACTIVATE))
 		return false;
 
-	if (IS_ENABLED(CONFIG_PCI_MSI) && pci_msi_ignore_mask)
+	if (info->flags & MSI_FLAG_NO_MASK)
 		return false;
 
 	/*
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 10:39:00 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 10:39:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871145.1282180 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXeK3-0000Ew-G6; Tue, 14 Jan 2025 10:38:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871145.1282180; Tue, 14 Jan 2025 10:38:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXeK3-0000Ep-DB; Tue, 14 Jan 2025 10:38:59 +0000
Received: by outflank-mailman (input) for mailman id 871145;
 Tue, 14 Jan 2025 10:38:58 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=iLru=UG=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tXeK2-0000Ej-CU
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 10:38:58 +0000
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [2a00:1450:4864:20::535])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c1783583-d263-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 11:38:56 +0100 (CET)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-5d0d32cd31aso7521606a12.0
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 02:38:56 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c9060042sm616105166b.34.2025.01.14.02.38.55
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 14 Jan 2025 02:38:55 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c1783583-d263-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736851136; x=1737455936; 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=CHSX59mn7d2/0XriJfrNxm2tWLEgbWfxepi7Or6imqk=;
        b=rVZPdaISs36yNtst8k3MNBDAtn0ytiay8KIRl2CF7y2YME+muqe3InSf3AraoIgoT0
         1TWNIUJCjY9V9N/NS9UjJhea79kQzk2Dc8gQQheYGRtSnlrY0uNYPIiqataBIxzhNjrC
         w3qIxyWkgMm3VqQLVeJFuW0QmzX4q841F0PDM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736851136; x=1737455936;
        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=CHSX59mn7d2/0XriJfrNxm2tWLEgbWfxepi7Or6imqk=;
        b=lE+owovih0SvyqetJvLOzuCeA/5szSlcoRAtEqnsb7chQ8B3MOz6cGwWsSgvFY4Xye
         yw9J+3egb2GUCwpPpkD6wD2KnQWV45bH7RUNvDbb8UFb59uYDJ+/ahzT1ZAtm+Kp9caB
         ObTvL37K1OKDmbUwuNBico72GvLszIp4ANWlh98xYDZLIyPWRULe46Tn1ZeHgi7h1XN/
         Mk2KBVSjqGHnE38ALfUVr4pHS+DIbgYvtXkiHKu2hfnjMb7kYhAMefng/mBxGHUIT6QZ
         isSq6JMrEcYueCQ7TJts7ddshTq3htd3Cli12MY9ASUIZi3F6Ls5RJmnsdnSO/15mVX0
         movA==
X-Gm-Message-State: AOJu0YwQy+VuGl5qYHulL6Ra142++coZPH3ASn+EnLe8gxIu6mEoQau+
	eoOVmjlyJN1cE0U62jQ1r4pTY4hsIS+7GB+tbIo+gPO8xmyjqx9F7CTBpLogE8I=
X-Gm-Gg: ASbGnctXTy9liyFAFDfg0wo1jF05Sm0I7JS5RGc9Hwzzgldtky2AVi1maSxbWEWONFP
	e10yjWzkiiA32vvZyMtB6b5d/2I8T2hIwrkBB9FTWK82D8HUzVDA7NCCwqBxlyL1TsicET4E+Sd
	7sAtz/+tc/2MMuNQ4tx4yi4h3KJKF1f8dqz6XJpZGEDeO8LPXLJcI9xfz6TrCWbHvwGuPmQNRKT
	ZcBSbQ9GV/+s9IN5Eo9KbcBkY0ZQpGmemitPw4AEYfmqGbjKS4QFEze/huukyopsA8=
X-Google-Smtp-Source: AGHT+IH1xS2EKDWf6Rz5eriCzytkoFdAOGrGwBglDK1tZvJ+azZ32D6CX700BAV2Kys8zZg8Qo0SlQ==
X-Received: by 2002:a05:6402:5194:b0:5d0:fb56:3f with SMTP id 4fb4d7f45d1cf-5d972e0e341mr59033855a12.12.1736851136083;
        Tue, 14 Jan 2025 02:38:56 -0800 (PST)
Date: Tue, 14 Jan 2025 11:38:54 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Teddy Astie <teddy.astie@vates.tech>
Cc: xen-devel@lists.xenproject.org, Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [XEN PATCH] intel/msr: Fix handling of MSR_RAPL_POWER_UNIT
Message-ID: <Z4Y-voWhP1aItFK3@macbook.local>
References: <0ac778dbcc7ab383447abe672225ff77b0d4802e.1736793323.git.teddy.astie@vates.tech>
 <Z4YvKdwtHjmJUVF3@macbook.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <Z4YvKdwtHjmJUVF3@macbook.local>

On Tue, Jan 14, 2025 at 10:32:25AM +0100, Roger Pau Monné wrote:
> On Mon, Jan 13, 2025 at 06:42:44PM +0000, Teddy Astie wrote:
> > Solaris 11.4 tries to access this MSR on some Intel platforms without properly
> > setting up a proper #GP handler, which leads to a immediate crash.
> > 
> > Emulate the access of this MSR by giving it a legal value (all values set to
> > default, as defined by Intel SDM "RAPL Interfaces").
> > 
> > Fixes: 84e848fd7a1 ('x86/hvm: disallow access to unknown MSRs')

Nit: I think we usually use 12 hex character hashes, the above one is
11 characters long.

> 
> Hm, 

Seems like I've sent this too early.

I wanted to say I wasn't convinced this is a fix for the above, but I
can see how the change can be seen as a regression if Solaris booted
before that change in behavior, so I'm fine with leaving the "Fixes:" tag.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 11:03:56 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 11:03:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871153.1282190 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXei6-00056u-9l; Tue, 14 Jan 2025 11:03:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871153.1282190; Tue, 14 Jan 2025 11:03:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXei6-00056n-6W; Tue, 14 Jan 2025 11:03:50 +0000
Received: by outflank-mailman (input) for mailman id 871153;
 Tue, 14 Jan 2025 11:03:49 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=iLru=UG=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tXei4-00056h-VA
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 11:03:48 +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 3aa5bab5-d267-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 12:03:48 +0100 (CET)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-5d414b8af7bso9554418a12.0
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 03:03:48 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c9646bf9sm619310866b.175.2025.01.14.03.03.44
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 14 Jan 2025 03:03:44 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 3aa5bab5-d267-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736852627; x=1737457427; 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=35mB+QjxPdevR8046RphJsKVW0nB2adhW14D5bTUKJg=;
        b=ed/0Yw63WtUIJCtiWXwQb52UAmFq+RrhMkfe8PYpGiYzE4GQrEOcpdTBT/I/Nr64/J
         HiIlrY3Q2fSkTt2rWKCdybIxMBLDOT+OVyhXVD7+JBYOsitj4/ISyJ9elDYZr5Csu6GT
         jJtT1cKivTD+8RY1fW3MWiJQ/RjUcr4+KdDDQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736852627; x=1737457427;
        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=35mB+QjxPdevR8046RphJsKVW0nB2adhW14D5bTUKJg=;
        b=ixIZqpepkvaWbyUx1Sq27xCIb9mpkzvnW9QYnsrZzfMWtrG/xwcwY1fTL+Kod1+s4/
         OoA79RqEuAVhG8edqIteBc3iEZSJvsBN9Sd9Tf5X9MQW4jQt35mLdefsAXd1LAIBTAax
         m/KcOaUEd53wHl3dbh/CqTT7NI4iG46AvQtNXCRM0NQpiFZu3Towof9xhGpZ1/K30XAK
         fw0hC1wAlEPnmwKAVdoq2kfyRfamySoGXjT4Rn7A1Y11T2+09NXn1OZgYE6ddDjz/XRD
         48rtjiwxm+P7aQIErfWhVcFFVLmnRyMa5nIK1kBZ5YqJ5LTsYfBD9dFMdmxZ9+Avf3R5
         5NHw==
X-Forwarded-Encrypted: i=1; AJvYcCUplP+GJF6JSWh8Lj/tHwOXbdLijfPeoiKMIpeu4zH3CW15nZY3ZAua0SiPIQujx8UnRWuDQ2zyOcU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwYyV8SPey15TuywV0ftM8brC0GXyPqtTPJOFVKnfvVIQO/sTxk
	6LU4iMt7VNwpHTEvlnwsz05h3Mp7NGA+hjqQfbkbqZIEMix4y3r9K5sm0UrihYk=
X-Gm-Gg: ASbGncvh5OLKIc3/DtwhFsMbEs81XqiLfaaBp0HjabL4B75BYxZ0sDM9L1TRiTsZ9bP
	WfnWKgBUI2yYGJcrUU1af3GLPDYoJnro4iZ4TAc7R0B+ED2STlzJuigXUDVA4nY4xq//bvM2JGJ
	i/ELG/PjGh1tHA95YH1tuV9FN00CYXV5Hh+KDbD4tLrl5Z+6Bn57i4VoL9q9w1Ynw/QG3BIVF/C
	vKd6ZR9IpUFiXZ9wrtdlzm9p1liQh48PLo6yZdv9TkECwfU5zhxB1bbmEg9GPdMp+E=
X-Google-Smtp-Source: AGHT+IGJNe0LSVA3nGJ258TjPthdYloWMFdub4oksN9mfoT80xGa7EGoGjJP2iGpXQ9PWDACteVGUg==
X-Received: by 2002:a17:907:d89:b0:ab3:3aa6:7d69 with SMTP id a640c23a62f3a-ab33aa681a2mr240126566b.41.1736852625094;
        Tue, 14 Jan 2025 03:03:45 -0800 (PST)
Date: Tue, 14 Jan 2025 12:03:43 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Keith Busch <kbusch@kernel.org>
Cc: Bjorn Helgaas <helgaas@kernel.org>, linux-kernel@vger.kernel.org,
	xen-devel@lists.xenproject.org, linux-pci@vger.kernel.org,
	Nirmal Patel <nirmal.patel@linux.intel.com>,
	Jonathan Derrick <jonathan.derrick@linux.dev>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Krzysztof =?utf-8?Q?Wilczy=C2=B4nski?= <kw@linux.com>,
	Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
	Rob Herring <robh@kernel.org>, Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [PATCH 2/3] vmd: disable MSI remapping bypass under Xen
Message-ID: <Z4ZEj3i71TTPkuwc@macbook.local>
References: <20250110140152.27624-3-roger.pau@citrix.com>
 <20250110222525.GA318386@bhelgaas>
 <Z4TlDhBNn8TMipdB@macbook.local>
 <Z4UtF737b3QFGnY0@kbusch-mbp>
 <Z4VDIPorOWD-FY-9@macbook.local>
 <Z4VFAZnQ_09cdexm@kbusch-mbp>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <Z4VFAZnQ_09cdexm@kbusch-mbp>

On Mon, Jan 13, 2025 at 09:53:21AM -0700, Keith Busch wrote:
> On Mon, Jan 13, 2025 at 05:45:20PM +0100, Roger Pau Monné wrote:
> > On Mon, Jan 13, 2025 at 08:11:19AM -0700, Keith Busch wrote:
> > > On Mon, Jan 13, 2025 at 11:03:58AM +0100, Roger Pau Monné wrote:
> > > > 
> > > > Hm, OK, but isn't the limit 80 columns according to the kernel coding
> > > > style (Documentation/process/coding-style.rst)?
> > > 
> > > That's the coding style. The commit message style is described in a
> > > different doc:
> > > 
> > >   https://docs.kernel.org/process/submitting-patches.html#the-canonical-patch-format
> > 
> > It's quite confusing to have different line length for code vs commit
> > messages, but my fault for not reading those. Will adjust to 75
> > columns them.
> 
> The output of 'git log' prepends spaces to the subject and body of the
> listed commits. The lower limit for commit messages vs. code makes the
> change log look readable in an 80-char terminal.

Oh, I see, thanks for explaining.

The 80 column limit for code mean the resulting diff (and `git log`
output) could have a maximum width of 81 characters (because of the
prepended +,-, ), but since Linux uses hard tabs for indentation this
is not really an issue as it would be if using spaces.

Regards, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 11:12:14 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 11:12:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871162.1282199 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXeq9-0006wt-2g; Tue, 14 Jan 2025 11:12:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871162.1282199; Tue, 14 Jan 2025 11:12:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXeq9-0006wm-07; Tue, 14 Jan 2025 11:12:09 +0000
Received: by outflank-mailman (input) for mailman id 871162;
 Tue, 14 Jan 2025 11:12:07 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=wcbX=UG=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tXeq7-0006wg-SY
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 11:12:07 +0000
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com
 [2a00:1450:4864:20::232])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 63861655-d268-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 12:12:06 +0100 (CET)
Received: by mail-lj1-x232.google.com with SMTP id
 38308e7fff4ca-30615661f98so29568601fa.2
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 03:12:06 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-305ff0f749dsm17164511fa.59.2025.01.14.03.12.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 14 Jan 2025 03:12:04 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 63861655-d268-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736853125; x=1737457925; darn=lists.xenproject.org;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=UJgVkffNfW5g6Y2STd8bV05bXLNIV0U2zEcDWhNpHxk=;
        b=NMlJt+7womNQcXmmfOyP2MApSLAmC5p2j1IJgthf6XOrEMGfCleAuGQV9HiCzG1fSV
         w45g6wqntDiOhzKwWiOddbrsJ9HOFcpkIrZp1Fl2EMxXaEcy8W8PDJgj8FckqCG4TNSk
         cPMWXBOF6+1Q8NQbCd+jVzNOyK1Ie7mOtxhzKV1a4e9qMLHIeAaa9eGYk84K06FawBTf
         qFayP2QeajVToNjlYVA4jnzm8HX/aRyyL6x3vKyjaLGNP9ARxXjGtRLpby+4LNj1WkOy
         9ZJe1oEvco4kNBN5EpErm9h/UmAGXdTSuOEHZzsI8VcaxVshq2xIsilW8tRkLLIUSetY
         TKyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736853125; x=1737457925;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=UJgVkffNfW5g6Y2STd8bV05bXLNIV0U2zEcDWhNpHxk=;
        b=p/MaPwY7MHRilyXWeyP6jXjx6sei6TFp+QfO/s9gRt1GOmTyLByHlg8Er/BbxK5h23
         InKR/cK5Ph41c9yG31BUljwRTuOKV6NzPB4jN7xx3MgLS0XYCAXdEwqjmXaUX24GWk5a
         0a1W4qVn/66u/VLyS727BJ6WWoBfsSNOjOSkSXRbgslF0sYa1Sm6tgtilCYTefnsud4k
         8+qGDxtL1N/JohSwSEPJ7ezxelgBpvN1dQ2+ile0y9hKus9SCwm5u8Swwx3NNYQ9xwCR
         laSHD46qEY0Mtd4UOKG6/z4qujVK3LJpVnOsMvDqhNigQjJvXUJB6nYui/jhz9jhhvSJ
         0BaA==
X-Gm-Message-State: AOJu0YyLg+CISX3KPXbaNJOfUgzSuAwmSkSEIzGpMR4IlIsnCmPf3OH9
	Qnm1EZK3iUM4UPJpFcyvs26CEJrhXf7L+oUGmu2hzzhFUJWoC8Su
X-Gm-Gg: ASbGncuWHFIXDLzLj4/H7MaBIzcAVkG5l1EzdrN8w9ZEcO0q5Cib+Wb+46R6WoYXGqt
	IrckLApsv3IoYzjVvMFbHPvlVoY+7LjgaAXdH6/MdGso8HV4+R16iOClpC1jJ4NhVxiUXGcOsSu
	MBxPUEedxWNx2HRHuw/SFup3c5DodHd9iMbGzkwgw5rhDsxDgjJxWDmCGKzvpXk6UydMVdupO4a
	1kltCe9oOh4tddiJCdfYxOS9dpunhArMv5zdyQZFAmFyteJznl5PwUp01v0TyTaquarjg==
X-Google-Smtp-Source: AGHT+IEu1ECxH5uvD64E2SASd0GS/CfaQ/EE3RE8jLmsD/VYsJ4Z3fRu5Agc895Ov92pXw4q4X1rbw==
X-Received: by 2002:a05:651c:2118:b0:302:1e65:f2a1 with SMTP id 38308e7fff4ca-305f4550c2bmr82313821fa.12.1736853125055;
        Tue, 14 Jan 2025 03:12:05 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------Y37JJYZznLiPdWkkbGeIstdp"
Message-ID: <49a2404f-0c45-4397-9094-a4189131832f@gmail.com>
Date: Tue, 14 Jan 2025 12:12:03 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 1/2] x86/time: introduce command line option to select
 wallclock
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
Cc: xen-devel@lists.xenproject.org,
 "Daniel P. Smith" <dpsmith@apertussolutions.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>
References: <20240913075907.34460-1-roger.pau@citrix.com>
 <20240913075907.34460-2-roger.pau@citrix.com> <Z4U6WxtmaqGkqOqe@mail-itl>
 <Z4VS88REbzn5uasy@macbook.local>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <Z4VS88REbzn5uasy@macbook.local>

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


On 1/13/25 6:52 PM, Roger Pau Monné wrote:
> On Mon, Jan 13, 2025 at 05:07:55PM +0100, Marek Marczykowski-Górecki wrote:
>> On Fri, Sep 13, 2024 at 09:59:06AM +0200, Roger Pau Monne wrote:
>>> Allow setting the used wallclock from the command line.  When the option is set
>>> to a value different than `auto` the probing is bypassed and the selected
>>> implementation is used (as long as it's available).
>>>
>>> The `xen` and `efi` options require being booted as a Xen guest (with Xen guest
>>> supported built-in) or from UEFI firmware respectively.
>>>
>>> Signed-off-by: Roger Pau Monné<roger.pau@citrix.com>
>> Reviewed-by: Marek Marczykowski-Górecki<marmarek@invisiblethingslab.com>
> Thanks for the review.
>
> Oleksii, can I get your opinion as Release Manager about whether this
> (and the following patch) would be suitable for committing to staging
> given the current release state?
>
> It's a workaround for broken EFI implementations that many downstreams
> carry on their patch queue.

Based on your commit message, I understand this as addressing a bug ( but not very critical
as IIUC downstreams have the similar patch on their side ). Therefore, if it has been properly
reviewed and tested, we should consider including it in the current release.

IIUC, setting the wallclock to EFI should align with the behavior Xen had previously.
It might be preferable to use that argument as the default for a while, allowing others to verify the "auto"
value over time. After that, we could consider making "auto" the default.
That said, I am not particularly strict about following this approach.

~ Oleksii


>
> Thanks, Roger.
--------------Y37JJYZznLiPdWkkbGeIstdp
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 1/13/25 6:52 PM, Roger Pau Monné
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:Z4VS88REbzn5uasy@macbook.local">
      <pre wrap="" class="moz-quote-pre">On Mon, Jan 13, 2025 at 05:07:55PM +0100, Marek Marczykowski-Górecki wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">On Fri, Sep 13, 2024 at 09:59:06AM +0200, Roger Pau Monne wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="" class="moz-quote-pre">Allow setting the used wallclock from the command line.  When the option is set
to a value different than `auto` the probing is bypassed and the selected
implementation is used (as long as it's available).

The `xen` and `efi` options require being booted as a Xen guest (with Xen guest
supported built-in) or from UEFI firmware respectively.

Signed-off-by: Roger Pau Monné <a class="moz-txt-link-rfc2396E" href="mailto:roger.pau@citrix.com">&lt;roger.pau@citrix.com&gt;</a>
</pre>
        </blockquote>
        <pre wrap="" class="moz-quote-pre">
Reviewed-by: Marek Marczykowski-Górecki <a class="moz-txt-link-rfc2396E" href="mailto:marmarek@invisiblethingslab.com">&lt;marmarek@invisiblethingslab.com&gt;</a>
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
Thanks for the review.

Oleksii, can I get your opinion as Release Manager about whether this
(and the following patch) would be suitable for committing to staging
given the current release state?

It's a workaround for broken EFI implementations that many downstreams
carry on their patch queue.</pre>
    </blockquote>
    <pre>Based on your commit message, I understand this as addressing a bug ( but not very critical
as IIUC downstreams have the similar patch on their side ). Therefore, if it has been properly
reviewed and tested, we should consider including it in the current release.

IIUC, setting the wallclock to EFI should align with the behavior Xen had previously.
It might be preferable to use that argument as the default for a while, allowing others to verify the "auto"
value over time. After that, we could consider making "auto" the default.
That said, I am not particularly strict about following this approach.</pre>
    <pre>
~ Oleksii
</pre>
    <p><br>
    </p>
    <blockquote type="cite" cite="mid:Z4VS88REbzn5uasy@macbook.local">
      <pre wrap="" class="moz-quote-pre">

Thanks, Roger.
</pre>
    </blockquote>
  </body>
</html>

--------------Y37JJYZznLiPdWkkbGeIstdp--


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 11:22:45 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 11:22:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871175.1282220 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXf0L-0000ha-5M; Tue, 14 Jan 2025 11:22:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871175.1282220; Tue, 14 Jan 2025 11:22:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXf0L-0000hR-2j; Tue, 14 Jan 2025 11:22:41 +0000
Received: by outflank-mailman (input) for mailman id 871175;
 Tue, 14 Jan 2025 11:22:40 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=wcbX=UG=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tXf0K-0000TB-1c
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 11:22:40 +0000
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com
 [2a00:1450:4864:20::135])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id dc7ac95a-d269-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 12:22:38 +0100 (CET)
Received: by mail-lf1-x135.google.com with SMTP id
 2adb3069b0e04-540218726d5so5062547e87.2
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 03:22:38 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5428be49964sm1645231e87.38.2025.01.14.03.22.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 14 Jan 2025 03:22:37 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: dc7ac95a-d269-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736853758; x=1737458558; darn=lists.xenproject.org;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ZE0eR+7uBNj/kmRsNRVFLfxsvTEfL6PGPyd246hdZ1k=;
        b=NnMxwU/G7Ezn1qauaR/NrGRYxYv1eqWJLsCyODXBTrGkxWHkPVm1B3cxRiQdD1Z0ys
         v6nfSPgWcYKtLHBoSn5ksex4M5x/BQLDzeddv8BWg5JfjquifKVM1QKvYK00NLYKUbHD
         otEvhIPBIH5eQ+TxxcDL5MeUVf+1UoXGLZGA3f1DOR6rv3hnegK+Suqfjq1rUEbhQ2k0
         r5GT7F68cabFoFkSvT1RjTTsNEtBHZTwcJmm0+49ir/CqB17mqamA1rvSNuNhJt/J/aG
         rLkU871jl7pOzb21Ds0BRqztlG64TDeX2HgMsPWFZMnRzlJTKg+TKZKmeHMZvkeU6J5W
         fWLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736853758; x=1737458558;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=ZE0eR+7uBNj/kmRsNRVFLfxsvTEfL6PGPyd246hdZ1k=;
        b=ZvURYUeYb50b+OZ+BiPxLTLVDD3+TealgxIyQUk7f1NiSkhWUnga7Y9VIJNAQIhoWy
         0E8qSFOdpoNXPXdrR1yZD/oPqAlPZlai1IGIa/f44Aj+MAVtnVuU7Z5dggccO4X7/ZL5
         YiUxWFLPDFvl9Br8dkCTaJemPs77JzOksgUYnX5Wi47UOlqNEFSseyPeNmfFjyBJ5Wws
         dq08ie3yCAtlu16GqLD9zG+Qaz9vzUvwBLSP2G571wqDLo5pGDPJmy7CgXgHzjQ/N33C
         3vvCrUNBhREFv2DCQLZ0sWRK4hECWkzVkOPLv/urnpNKIqyQjUR+Jl/cSgBuuuJBzWAk
         QNoQ==
X-Forwarded-Encrypted: i=1; AJvYcCVr/XAwEsiFCGhBzPOfr2oI0cQGoa+vVEKlL2S18NbMon3H59KJpYIEMno+V029UO7m9niHCVbKAFU=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz7YBEPHWmEcYLdDs8Q+iZ9s1Vixk9A14IO2k2t9BK1pkK2gmp4
	cAsvneuvPX/0zeMylxdYPfFXkrD+evbWsu6iYHVn/AuN6lLqFy0vgF29ig==
X-Gm-Gg: ASbGncuFGP03alRUyzTE77aQnEIKjxpyS4fsnNErFvd+ZylK0P//pb6Q8N+W8DgVh2g
	klSLYe1lpTk/KF8k0fb9M1FpvvxU14jgXYF0QVAfDvzVuWXVs1ZglbYHMk+DM9MX3FlljZ/RXGp
	NOChvtyZOy5p3hGmScTC9a6J1OomVNvcPmdtjvS7rVM857N6FZlLxGwZvtFx4cLvpecs0Qh5pZe
	ql0lfO7rli1cfSLCKbIXwFNGyDEwBUatN66JcwYSWybKG2m1T2wtIlj1Z1RHYd+5sbG5Q==
X-Google-Smtp-Source: AGHT+IEjQHPA+F1rCR/BY0aszD++P/W6rVYMTu1AFbs/wc71tiodVhsZq+bNfQQN0s+I7RsJVO5k7A==
X-Received: by 2002:a05:6512:3b22:b0:53e:2f9d:6a81 with SMTP id 2adb3069b0e04-54284810c67mr7871096e87.39.1736853757726;
        Tue, 14 Jan 2025 03:22:37 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------EgbGnCA9RLofJckEMMLnNRSi"
Message-ID: <50168d73-0fb7-4dbb-b93e-25d8e7e00733@gmail.com>
Date: Tue, 14 Jan 2025 12:22:37 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xl: properly dispose of libxl_dominfo struct instances
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Anthony PERARD <anthony.perard@vates.tech>
References: <f751c5f0-3895-43bb-874b-3611b7916133@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <f751c5f0-3895-43bb-874b-3611b7916133@suse.com>

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


On 1/14/25 9:12 AM, Jan Beulich wrote:
> The ssid_label field requires separate freeing; make sure to call
> libxl_dominfo_dispose(). And then, for good measure, also
> libxl_dominfo_init().
>
> Coverity-ID: 1638727
> Coverity-ID: 1638728
> Fixes: c458c404da16 ("xl: use libxl_domain_info to get the uuid in printf_info")
> Fixes: 48dab9767d2e ("tools/xl: use libxl_domain_info to get domain type for vcpu-pin")
> Signed-off-by: Jan Beulich<jbeulich@suse.com>

Release-Acked-by: Oleksii Kurochko<oleksii.kurochko@gmail.com>

Thanks.

~ Oleksii

> ---
> I wasn't quite sure about use of libxl_dominfo_init(): vcpuset(), for
> example, doesn't call it.
>
> --- a/tools/xl/xl_sxp.c
> +++ b/tools/xl/xl_sxp.c
> @@ -45,8 +45,10 @@ void printf_info_sexp(int domid, libxl_d
>       /* retrieve the UUID from dominfo, since it is probably generated
>        * during parsing and thus does not match the real one
>        */
> +    libxl_dominfo_init(&info);
>       if (libxl_domain_info(ctx, &info, domid) == 0) {
>           fprintf(fh, "\t(uuid " LIBXL_UUID_FMT ")\n", LIBXL_UUID_BYTES(info.uuid));
> +        libxl_dominfo_dispose(&info);
>       } else {
>           fprintf(fh, "\t(uuid <unknown>)\n");
>       }
> --- a/tools/xl/xl_vcpu.c
> +++ b/tools/xl/xl_vcpu.c
> @@ -286,6 +286,8 @@ int main_vcpupin(int argc, char **argv)
>       if (!ignore_masks && hard) {
>           libxl_dominfo dominfo;
>   
> +        libxl_dominfo_init(&dominfo);
> +
>           if (libxl_domain_info(ctx, &dominfo, domid)) {
>               fprintf(stderr, "Could not get domain info\n");
>               goto out;
> @@ -293,6 +295,8 @@ int main_vcpupin(int argc, char **argv)
>   
>           /* HVM and PVH domains use the same global affinity mask */
>           apply_global_affinity_masks(dominfo.domain_type, hard, 1);
> +
> +        libxl_dominfo_dispose(&dominfo);
>       }
>   
>       if (force) {
--------------EgbGnCA9RLofJckEMMLnNRSi
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 1/14/25 9:12 AM, Jan Beulich wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:f751c5f0-3895-43bb-874b-3611b7916133@suse.com">
      <pre wrap="" class="moz-quote-pre">The ssid_label field requires separate freeing; make sure to call
libxl_dominfo_dispose(). And then, for good measure, also
libxl_dominfo_init().

Coverity-ID: 1638727
Coverity-ID: 1638728
Fixes: c458c404da16 ("xl: use libxl_domain_info to get the uuid in printf_info")
Fixes: 48dab9767d2e ("tools/xl: use libxl_domain_info to get domain type for vcpu-pin")
Signed-off-by: Jan Beulich <a class="moz-txt-link-rfc2396E" href="mailto:jbeulich@suse.com">&lt;jbeulich@suse.com&gt;</a></pre>
    </blockquote>
    <pre>Release-Acked-by: Oleksii Kurochko <a class="moz-txt-link-rfc2396E" href="mailto:oleksii.kurochko@gmail.com">&lt;oleksii.kurochko@gmail.com&gt;</a></pre>
    <pre>Thanks.</pre>
    <pre>~ Oleksii
</pre>
    <blockquote type="cite"
      cite="mid:f751c5f0-3895-43bb-874b-3611b7916133@suse.com">
      <pre wrap="" class="moz-quote-pre">
---
I wasn't quite sure about use of libxl_dominfo_init(): vcpuset(), for
example, doesn't call it.

--- a/tools/xl/xl_sxp.c
+++ b/tools/xl/xl_sxp.c
@@ -45,8 +45,10 @@ void printf_info_sexp(int domid, libxl_d
     /* retrieve the UUID from dominfo, since it is probably generated
      * during parsing and thus does not match the real one
      */
+    libxl_dominfo_init(&amp;info);
     if (libxl_domain_info(ctx, &amp;info, domid) == 0) {
         fprintf(fh, "\t(uuid " LIBXL_UUID_FMT ")\n", LIBXL_UUID_BYTES(info.uuid));
+        libxl_dominfo_dispose(&amp;info);
     } else {
         fprintf(fh, "\t(uuid &lt;unknown&gt;)\n");
     }
--- a/tools/xl/xl_vcpu.c
+++ b/tools/xl/xl_vcpu.c
@@ -286,6 +286,8 @@ int main_vcpupin(int argc, char **argv)
     if (!ignore_masks &amp;&amp; hard) {
         libxl_dominfo dominfo;
 
+        libxl_dominfo_init(&amp;dominfo);
+
         if (libxl_domain_info(ctx, &amp;dominfo, domid)) {
             fprintf(stderr, "Could not get domain info\n");
             goto out;
@@ -293,6 +295,8 @@ int main_vcpupin(int argc, char **argv)
 
         /* HVM and PVH domains use the same global affinity mask */
         apply_global_affinity_masks(dominfo.domain_type, hard, 1);
+
+        libxl_dominfo_dispose(&amp;dominfo);
     }
 
     if (force) {
</pre>
    </blockquote>
  </body>
</html>

--------------EgbGnCA9RLofJckEMMLnNRSi--


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 11:22:45 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 11:22:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871174.1282210 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXf0I-0000TO-Va; Tue, 14 Jan 2025 11:22:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871174.1282210; Tue, 14 Jan 2025 11:22:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXf0I-0000TH-Ss; Tue, 14 Jan 2025 11:22:38 +0000
Received: by outflank-mailman (input) for mailman id 871174;
 Tue, 14 Jan 2025 11:22:37 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=iLru=UG=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tXf0H-0000TB-L2
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 11:22:37 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id da9fc228-d269-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 12:22:35 +0100 (CET)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-ab2e308a99bso168838766b.1
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 03:22:35 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c90dc101sm626226466b.56.2025.01.14.03.22.34
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 14 Jan 2025 03:22:34 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: da9fc228-d269-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736853755; x=1737458555; 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=FxKEzOyq7fH9j9gjempFM9FMHkugp5rbaXRrEYvWN7M=;
        b=I9jrjgf4IiBdszO8PV0Uf0E01acPEB8d1Wg98FCu+6HBfF79msLEoEQB7U9z9zPvXj
         Az7LNmCEzuUJmbJZ6jDlNeoxo0DgR3jKQKqHYn/jB6yaBz3UtvLyEyUVfSDT5XDLG0sr
         bzAWsynX9lqdkNOjS122MVfhUjKvYkZIsAtx4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736853755; x=1737458555;
        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=FxKEzOyq7fH9j9gjempFM9FMHkugp5rbaXRrEYvWN7M=;
        b=EfUIiXMl7vEKLuq0aCFttGTWom1XoNRI9pFTEHdaK1FVWasnf3T8xbectbjvYFGVxy
         JDjVp8sYmhpN+BF0qiuDgRl0ByNKv234d+to8P3TmpP3DSJP+gO6vlf0nhMcbVCqWxQN
         UVgpsxzrklVPu3RW1Vx1TsoTdHew4B9RxgtGYIWRm6IPunpgQZ1ZLne26+6weJtl3TY5
         eOTkolD/DfNi36aeUvEY6GKOzsxEbiQeLUnoDZaA+I6GwE5fK9xXqSWB1F2KwIMQXhKV
         nViuk441HgX51TbloIU5D0n0mnpwJo5isb5xSO7K0wwu7nZDwi7sBOtK5pgeLS4QOPVP
         HHxw==
X-Gm-Message-State: AOJu0Yx74k5HLaR3HbZZc7qxqWl7B8ZR5+NJbu8puE6tzOldkYG5gMRT
	5IHfNNs6ZObjgw7VOJPscN0WlntXyC3MiFrSWRj7YtbbUu6sNQZtNRW3Jf55CTw=
X-Gm-Gg: ASbGncs0vSKu6AuyFWeYIRBRktwxf1EqAEkaY4IOC6ShKXmtfEvivTFEGrXdqfKN074
	XlEVOMMB0lzV48ec7xJlhARt0gsBax7PJLke/GKyZsVbbJ9bANgvM0MgWL9AbRH2W3NDXXhAhuO
	zArkV2jL67gpKl6MgBXPLAjfgvt9ACj+2CJpYzkwVDius2mtfoBGHbdWbTOEutcqc7uegMCAsjU
	+T9p2HvP0TEhRGquuKfJuDBsKuSPfgAylT3ksuoXibImtvvvp2ySKLUShoT7KLHJlc=
X-Google-Smtp-Source: AGHT+IFWKgjRDgw1t2mS1L7ifjdj2QNq0C8y5537bY6dJes6JuS8xQP2NyTD8i147GlkFaFxXlREdg==
X-Received: by 2002:a17:907:1c23:b0:aa6:9d09:b17b with SMTP id a640c23a62f3a-ab2c3daffc0mr1615711366b.28.1736853754887;
        Tue, 14 Jan 2025 03:22:34 -0800 (PST)
Date: Tue, 14 Jan 2025 12:22:33 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: xen-devel@lists.xenproject.org,
	Simone Ballarin <simone.ballarin@bugseng.com>,
	Doug Goldstein <cardoe@cardoe.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v2 2/2] automation/eclair: make Misra rule 20.7 blocking
 for x86 also
Message-ID: <Z4ZI-WfUv73iQLI1@macbook.local>
References: <20241126093508.6966-1-roger.pau@citrix.com>
 <20241126093508.6966-3-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20241126093508.6966-3-roger.pau@citrix.com>

Hello Oleksii,

This is in principle ready to go in now (I'm currently running a
private Eclair scan to ensure the patch is still OK against current
staging).  I would like to ask for a release Ack.

Thanks, Roger.

On Tue, Nov 26, 2024 at 10:35:08AM +0100, Roger Pau Monne wrote:
> There are no violations left, make the rule globally blocking for both x86 and
> ARM.
> 
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
>  automation/eclair_analysis/ECLAIR/tagging.ecl | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl b/automation/eclair_analysis/ECLAIR/tagging.ecl
> index 755ea3271fc9..cb4e233e838d 100644
> --- a/automation/eclair_analysis/ECLAIR/tagging.ecl
> +++ b/automation/eclair_analysis/ECLAIR/tagging.ecl
> @@ -80,6 +80,7 @@ MC3R1.R20.2||
>  MC3R1.R20.3||
>  MC3R1.R20.4||
>  MC3R1.R20.6||
> +MC3R1.R20.7||
>  MC3R1.R20.9||
>  MC3R1.R20.11||
>  MC3R1.R20.12||
> @@ -116,7 +117,7 @@ if(string_equal(target,"x86_64"),
>  )
>  
>  if(string_equal(target,"arm64"),
> -    service_selector({"additional_clean_guidelines","MC3R1.R2.1||MC3R1.R5.3||MC3.R11.2||MC3R1.R16.6||MC3R1.R20.7"})
> +    service_selector({"additional_clean_guidelines","MC3R1.R2.1||MC3R1.R5.3||MC3.R11.2||MC3R1.R16.6"})
>  )
>  
>  -reports+={clean:added,"service(clean_guidelines_common||additional_clean_guidelines)"}
> -- 
> 2.46.0
> 


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 11:24:17 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 11:24:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871194.1282230 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXf1s-0001a1-JN; Tue, 14 Jan 2025 11:24:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871194.1282230; Tue, 14 Jan 2025 11:24:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXf1s-0001Zu-Fg; Tue, 14 Jan 2025 11:24:16 +0000
Received: by outflank-mailman (input) for mailman id 871194;
 Tue, 14 Jan 2025 11:24: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
 <SRS0=wcbX=UG=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tXf1r-0001Zk-UN
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 11:24:15 +0000
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com
 [2a00:1450:4864:20::230])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 157a167b-d26a-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 12:24:14 +0100 (CET)
Received: by mail-lj1-x230.google.com with SMTP id
 38308e7fff4ca-30613802a59so29689311fa.0
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 03:24:14 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-305ff1c7a57sm17694471fa.89.2025.01.14.03.24.12
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 14 Jan 2025 03:24:12 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 157a167b-d26a-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736853853; x=1737458653; darn=lists.xenproject.org;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Ov7SGz9floGkFITp6OmiwsetogpeF9lsC3i30Wh9+/w=;
        b=XKhwHJtIkEwcIRWhglIxFs0ZcGavoBwRruRRury8KYOixOvYGhmBm8T0gjQ9ydujuB
         B9RdXratLB8h1v39il2xTH/UidYgWMO4vDKnuYV6du7CnYX4g38/Hhs9qFTucm69MY+S
         DxnVPZTJu68RrAtbaReXHnRSo5rbo/bXMqZPWoHCX87zIW0Op2P1H6YFIZH151L+BLUm
         hJ4SfP3GrP8jxbU3XqKcFYEVQxdgsV2vEqgJW8y0cnCDqNf8/eEkC3rowDCXADE1oYtr
         NiDl0d/mDQvongvu58Qn8rz9P2OgpmLlFzs4IwyHp+tMkMVlK8vc1/WUXmArhyKhL2XD
         PKZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736853853; x=1737458653;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=Ov7SGz9floGkFITp6OmiwsetogpeF9lsC3i30Wh9+/w=;
        b=C3DSkRx8wxXifUQq0goj38H/8MiNGUrGLRYrMsejNW7KrP8PfFMguwJL35sJPkEQ7G
         iYwmi1263HAq7EdvRJO4baiJbho+GLSkhHcopMSrGsNOBlubSI5JQBNuRVnX52i6fWcq
         3ANvtTW3a2WM57K67X/brsn//cX8L+WLQHdYY/c3GUACJwwLnznmmTxEja2eEUtA3TMG
         nxncnkq/FkBnlkhLBknjqgM6VTw8zJtW/KqavB4L9t4XiI6T1WP2bcCZ+ZjkBVW1Ug7Y
         Ke2SoxY2GWJgUPlNXnhVyF7GxJuUaCv0DiZMCA4mPyYhGWBL2piQAGGIzZ07kJSHDWaN
         UOVQ==
X-Forwarded-Encrypted: i=1; AJvYcCWbWc4lGYHM4H/NsU3Uko1v4rZW8eTxsKEj2nC8CLavfnodpPeCDyj8zYUmQcBoo5zOIsAvKPfog5Y=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz+okZ+EpjJFmi5WJpC9eboJTTU7nnAdz29i2vJuPqsTj75Mggk
	Mm0J+RYIJUq26SoAtxkOe3uscad0Y4DKFAYWZSrdRqjyaC2XcjRsD26l5w==
X-Gm-Gg: ASbGncstVbL0vPllvqs8ohKYM5VOmw7fyricFE7lZsQqRWwwhl2S2G5qMFyC30AfxOo
	CL2KfOf65R64JiQyGfMPmuWb4s54cjLJcBqNgzvXyooR4nlwAoyLMU83yRD6hOXoeg1iPHHd1NC
	DGH9EUY4H6VnPnE3BShyH4n3D9F0UEzNOYF75P+xLBTD6oT82uyCuuChG/e1mWvN8KGdKDGMnBa
	J9RkgsxPFHmCwAar1SO9ol8g+/kQSUtqkYddcUSCdS5DiQVn6RQHu4STP0inJhMNOYF4w==
X-Google-Smtp-Source: AGHT+IEwky2WvzlsN6SIFGHJ/opnNHZSBoFIvdYL9wMAxbCJAe4KJo/jwMJuo35+lTGYSzUXqFvEuw==
X-Received: by 2002:a05:651c:b1f:b0:306:f7:c40a with SMTP id 38308e7fff4ca-30600f7c566mr72289961fa.18.1736853853236;
        Tue, 14 Jan 2025 03:24:13 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------G3qNQP67PgfeNq0TetJoPCYa"
Message-ID: <0a4fb910-14f4-4b89-8ab6-33518cec8b85@gmail.com>
Date: Tue, 14 Jan 2025 12:24:12 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xentrace: free CPU mask string before overwriting pointer
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Anthony PERARD <anthony.perard@vates.tech>
References: <fedf2b9d-a475-4062-b8a4-5e33c7dd6305@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <fedf2b9d-a475-4062-b8a4-5e33c7dd6305@suse.com>

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


On 1/14/25 9:12 AM, Jan Beulich wrote:
> While multiple -c options may be unexpected, we'd still better deal with
> them properly.
>
> Also restore the blank line that was bogusly zapped by the same commit.
>
> Coverity-ID: 1638723
> Fixes: e4ad2836842a ("xentrace: Implement cpu mask range parsing of human values (-c)")
> Signed-off-by: Jan Beulich<jbeulich@suse.com>

R-Acked-by: Oleksii Kurochko<oleksii.kurochko@gmail.com>

Thanks.

~ Oleksii

>
> --- a/tools/xentrace/xentrace.c
> +++ b/tools/xentrace/xentrace.c
> @@ -1105,8 +1105,10 @@ static void parse_args(int argc, char **
>               break;
>   
>           case 'c': /* set new cpu mask for filtering (when xch is set). */
> +            free(opts.cpu_mask_str);
>               opts.cpu_mask_str = strdup(optarg);
>               break;
> +
>           case 'e': /* set new event mask for filtering*/
>               parse_evtmask(optarg);
>               break;
--------------G3qNQP67PgfeNq0TetJoPCYa
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 1/14/25 9:12 AM, Jan Beulich wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:fedf2b9d-a475-4062-b8a4-5e33c7dd6305@suse.com">
      <pre wrap="" class="moz-quote-pre">While multiple -c options may be unexpected, we'd still better deal with
them properly.

Also restore the blank line that was bogusly zapped by the same commit.

Coverity-ID: 1638723
Fixes: e4ad2836842a ("xentrace: Implement cpu mask range parsing of human values (-c)")
Signed-off-by: Jan Beulich <a class="moz-txt-link-rfc2396E" href="mailto:jbeulich@suse.com">&lt;jbeulich@suse.com&gt;</a></pre>
    </blockquote>
    <pre>R-Acked-by: Oleksii Kurochko <a class="moz-txt-link-rfc2396E" href="mailto:oleksii.kurochko@gmail.com">&lt;oleksii.kurochko@gmail.com&gt;</a></pre>
    <pre>Thanks.</pre>
    <pre>~ Oleksii
</pre>
    <blockquote type="cite"
      cite="mid:fedf2b9d-a475-4062-b8a4-5e33c7dd6305@suse.com">
      <pre wrap="" class="moz-quote-pre">

--- a/tools/xentrace/xentrace.c
+++ b/tools/xentrace/xentrace.c
@@ -1105,8 +1105,10 @@ static void parse_args(int argc, char **
             break;
 
         case 'c': /* set new cpu mask for filtering (when xch is set). */
+            free(opts.cpu_mask_str);
             opts.cpu_mask_str = strdup(optarg);
             break;
+
         case 'e': /* set new event mask for filtering*/
             parse_evtmask(optarg);
             break;
</pre>
    </blockquote>
  </body>
</html>

--------------G3qNQP67PgfeNq0TetJoPCYa--


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 11:24:34 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 11:24:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871196.1282241 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXf29-0001xW-Sn; Tue, 14 Jan 2025 11:24:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871196.1282241; Tue, 14 Jan 2025 11:24:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXf29-0001xP-Op; Tue, 14 Jan 2025 11:24:33 +0000
Received: by outflank-mailman (input) for mailman id 871196;
 Tue, 14 Jan 2025 11:24:32 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=xX/k=UG=bugseng.com=nicola.vetrini@srs-se1.protection.inumbo.net>)
 id 1tXf27-0001rd-V4
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 11:24:32 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1f6e324a-d26a-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 12:24:31 +0100 (CET)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 by support.bugseng.com (Postfix) with ESMTPA id 094144EE0744;
 Tue, 14 Jan 2025 12:24:30 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1f6e324a-d26a-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1736853870; bh=pSws+Pj3GYkNKzRRRPKoqIIdaeT4u0bilmb/sAqvtnU=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=koTlI43P6a2gdUFDIUOVdoTKdXHlzKbyEbTXHmKGjRZZLkovW/jcgqcA2Krkg02zz
	 CwDkozrCKezSAmoBYkHMwVDNtlVzBAzTLVqu8Un+rYdaEEK6mu7yoUhm/VVaEVOI0T
	 bYd7w1SNIpTq7mKGVSHciVSwpXi2+7hNv73MHZC6oA5nKl7Q9RTWmdsMgrrTOsKee3
	 jm4RtJ9sey95rGzUZfQBgpDuiVBOdmtygdKyXlEFBqjDhf358LoXzgjiVkxpVt8TZK
	 V6xOfOwOTAXqLCliOT4ZnebhfP+tpUy5Uq/HIkfmmSiw1lG5LrddtqgMZs/cDhBwZ9
	 +QySPGjDMPCcw==
MIME-Version: 1.0
Date: Tue, 14 Jan 2025 12:24:30 +0100
From: Nicola Vetrini <nicola.vetrini@bugseng.com>
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Cc: Oleksii Kurochko <oleksii.kurochko@gmail.com>,
 xen-devel@lists.xenproject.org, Simone Ballarin
 <simone.ballarin@bugseng.com>, Doug Goldstein <cardoe@cardoe.com>, Stefano
 Stabellini <sstabellini@kernel.org>, Andrew Cooper
 <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v2 2/2] automation/eclair: make Misra rule 20.7 blocking
 for x86 also
In-Reply-To: <Z4ZI-WfUv73iQLI1@macbook.local>
References: <20241126093508.6966-1-roger.pau@citrix.com>
 <20241126093508.6966-3-roger.pau@citrix.com>
 <Z4ZI-WfUv73iQLI1@macbook.local>
Message-ID: <54a6f4337e2f9bfc1f295b3c1e9a0897@bugseng.com>
X-Sender: nicola.vetrini@bugseng.com
Organization: BUGSENG s.r.l.
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit

On 2025-01-14 12:22, Roger Pau Monné wrote:
> Hello Oleksii,
> 
> This is in principle ready to go in now (I'm currently running a
> private Eclair scan to ensure the patch is still OK against current
> staging).  I would like to ask for a release Ack.
> 

One nit below, which I overlooked initially

> Thanks, Roger.
> 
> On Tue, Nov 26, 2024 at 10:35:08AM +0100, Roger Pau Monne wrote:
>> There are no violations left, make the rule globally blocking for both 
>> x86 and
>> ARM.
>> 
>> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
>> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> ---
>>  automation/eclair_analysis/ECLAIR/tagging.ecl | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>> 
>> diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl 
>> b/automation/eclair_analysis/ECLAIR/tagging.ecl
>> index 755ea3271fc9..cb4e233e838d 100644
>> --- a/automation/eclair_analysis/ECLAIR/tagging.ecl
>> +++ b/automation/eclair_analysis/ECLAIR/tagging.ecl
>> @@ -80,6 +80,7 @@ MC3R1.R20.2||
>>  MC3R1.R20.3||
>>  MC3R1.R20.4||
>>  MC3R1.R20.6||
>> +MC3R1.R20.7||
>>  MC3R1.R20.9||
>>  MC3R1.R20.11||
>>  MC3R1.R20.12||
>> @@ -116,7 +117,7 @@ if(string_equal(target,"x86_64"),
>>  )

this hunk will not apply because it uses MC3R1, rather than MC3R2. 
Should be an easy fix.

>> 
>>  if(string_equal(target,"arm64"),
>> -    
>> service_selector({"additional_clean_guidelines","MC3R1.R2.1||MC3R1.R5.3||MC3.R11.2||MC3R1.R16.6||MC3R1.R20.7"})
>> +    
>> service_selector({"additional_clean_guidelines","MC3R1.R2.1||MC3R1.R5.3||MC3.R11.2||MC3R1.R16.6"})
>>  )

here as well

>> 
>>  
>> -reports+={clean:added,"service(clean_guidelines_common||additional_clean_guidelines)"}
>> --
>> 2.46.0
>> 

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 11:25:12 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 11:25:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871211.1282250 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXf2m-0002ax-4c; Tue, 14 Jan 2025 11:25:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871211.1282250; Tue, 14 Jan 2025 11:25:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXf2m-0002aq-1B; Tue, 14 Jan 2025 11:25:12 +0000
Received: by outflank-mailman (input) for mailman id 871211;
 Tue, 14 Jan 2025 11:25:11 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=wcbX=UG=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tXf2l-0001Zk-1R
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 11:25:11 +0000
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com
 [2a00:1450:4864:20::230])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 367deef2-d26a-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 12:25:09 +0100 (CET)
Received: by mail-lj1-x230.google.com with SMTP id
 38308e7fff4ca-30034ad2ca3so39280741fa.1
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 03:25:09 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-305ff0f8830sm17704571fa.56.2025.01.14.03.25.08
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 14 Jan 2025 03:25:08 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 367deef2-d26a-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736853909; x=1737458709; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=rxuwXE7Ub93xoW60BGzgtGqv5pjnq4qxOGMwWVH5TvE=;
        b=TIKA/uWW77LG5m9A5Kf8grzD6dBOdyGV16bfll/IQGg0/WLkaUw6/AI+N+Da13yxT6
         yB4yfxsFA7v/rcRvFCheVKMqC1evA5t56DICrV3vZ+c5dIFZPpqCqkQJ1yH8E0EuPefZ
         /6KGmvFaLqGDkl1QSc+kbQUwVL2qfwYhqJwGQJ1jhpquy0hNORT14audiEHQk+z8l8Cx
         PFTBk8Q7bCp/Njnbpj2WFAKQsj3uItuP68qsXuG4vTUvCLVTXU7Xz+b8yxxo5GUdQu1J
         bhH3thnUs8fG7vRfmjRspv00jZL3BMw9L3ehGrponezb0eUskbmwm+N6MJ3SZoq27yA/
         jWEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736853909; x=1737458709;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=rxuwXE7Ub93xoW60BGzgtGqv5pjnq4qxOGMwWVH5TvE=;
        b=XZ6FIx2WidIr2l1Cz5CcBJPWhu7yeG8Jgh8s//Bg5sbyu/ZDlj/siOXiPCbs7lKcbk
         iqSwoXM/sAPfAPU/ivffWWhbiPveePjT2dHf4pvdrSNgSXpP3c3kZPoKOgxnFwzFbtpy
         tPP1YyY7nQwadQI1UOtdGeNn1sMdOTBp6rO/hElV1xpM7vQ6Ir2kuZOby2puBFIGXBDi
         MupMNyEa43vRlRol+rHUlL55iLLjNdvU5dfWDO9bgFHMiXTt3bRqGy9Qgf93etDbh6MC
         BE68H+rigeZbdI5BzIum0Qix6uCrOTDFA3ciw4CerUqF4PKGe7lZ34if7FTUkhqa6VQR
         RNjg==
X-Forwarded-Encrypted: i=1; AJvYcCXba86e5lnBqErxTAfVTHbcB4nCf3aGtOHoOSMNUa9Ct4cQ/inwXUkybAZIZyPyTYEM6N2ZWL75epc=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw67p8d3RWXAXlm4nrgfdNKFhKniaWMAQpIPWq4WrALu9XQIsqB
	h9OQAyXjQRzv4z1SE5gZGpw472ExesBwtDZtQr+qUQzddrIdUi6N
X-Gm-Gg: ASbGncs0VADJ3smlj+qUngP5p7PTgcDo9p3WjsA6orkXiuLktDTm0EJFoYKp1kSnds6
	miGiPgvbfhsmJ5gMEIYleyAr2mIyRAbj8f5Tf8WPo3mL4vVT0ATJ5WaaV7fmkP5AmdjEoywIpE+
	0uAj5UHSxSSlqe7vpbbMtUZb/ed2ySy9p3cx05AZG3Ya5Jha6hPCnggKG9nROQXtVcW1e2GgfUs
	lBeCd48PJvDs/6ZvfdcfCB3iFSSIk9Xlx4hKZbYK9ytAzT4AyPI4eOa5P6p5nK6zF2p4w==
X-Google-Smtp-Source: AGHT+IGXP8yNnZya4l7S4XQv4FSJGBz0Th1oXdgTyujC48B2Q+C0CnMJee6+QtEVSw8eFotLervMgQ==
X-Received: by 2002:a05:651c:b29:b0:302:4147:178d with SMTP id 38308e7fff4ca-305f45dc5b0mr94748041fa.28.1736853908817;
        Tue, 14 Jan 2025 03:25:08 -0800 (PST)
Message-ID: <652d7978-8810-4e10-9a19-e067948a223f@gmail.com>
Date: Tue, 14 Jan 2025 12:25:08 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xl: properly dispose of vTPM struct instance
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Anthony PERARD <anthony.perard@vates.tech>
References: <73a01ddf-6090-4fda-a8c0-5703e7c9e81b@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <73a01ddf-6090-4fda-a8c0-5703e7c9e81b@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 1/14/25 9:13 AM, Jan Beulich wrote:
> The backend_domname field requires separate freeing; make sure to call
> libxl_device_vtpm_dispose() also on respective error paths.
>
> Coverity-ID: 1638719
> Fixes: dde22055ac3a ("libxl: add vtpm support")
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

R-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>

Thanks.

~ Oleksii

>
> --- a/tools/xl/xl_vtpm.c
> +++ b/tools/xl/xl_vtpm.c
> @@ -44,12 +44,14 @@ int main_vtpmattach(int argc, char **arg
>           if (MATCH_OPTION("uuid", *argv, oparg)) {
>               if(libxl_uuid_from_string(&(vtpm.uuid), oparg)) {
>                   fprintf(stderr, "Invalid uuid specified (%s)\n", oparg);
> +                libxl_device_vtpm_dispose(&vtpm);
>                   return 1;
>               }
>           } else if (MATCH_OPTION("backend", *argv, oparg)) {
>               replace_string(&vtpm.backend_domname, oparg);
>           } else {
>               fprintf(stderr, "unrecognized argument `%s'\n", *argv);
> +            libxl_device_vtpm_dispose(&vtpm);
>               return 1;
>           }
>       }
> @@ -65,6 +67,7 @@ int main_vtpmattach(int argc, char **arg
>   
>       if (libxl_device_vtpm_add(ctx, domid, &vtpm, 0)) {
>           fprintf(stderr, "libxl_device_vtpm_add failed.\n");
> +        libxl_device_vtpm_dispose(&vtpm);
>           return 1;
>       }
>       libxl_device_vtpm_dispose(&vtpm);


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 11:27:33 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 11:27:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871223.1282259 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXf52-0003Ck-GA; Tue, 14 Jan 2025 11:27:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871223.1282259; Tue, 14 Jan 2025 11:27:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXf52-0003Cb-DE; Tue, 14 Jan 2025 11:27:32 +0000
Received: by outflank-mailman (input) for mailman id 871223;
 Tue, 14 Jan 2025 11:27:30 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=iLru=UG=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tXf50-0003CV-OA
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 11:27:30 +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 8a23870c-d26a-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 12:27:29 +0100 (CET)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-5d3ecae02beso6927825a12.0
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 03:27:29 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d9900c440bsm5938529a12.26.2025.01.14.03.27.28
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 14 Jan 2025 03:27:28 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8a23870c-d26a-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736854049; x=1737458849; 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=+ldjiazwPH/9g3yJmkdafzgo4e1V47IDF3ZSi2eHgu4=;
        b=JYrrgirfWYvHoU9/BmiRt6rPr8DcyM4yN5iUJb/1hs67eYhj7qqw21gbrrglN89Nnh
         B54DPpIG+zWOjI8//l56YWWIEPlXTu/vFpq9WLXV6VeQDbeQ2rWk3/sdFYK7iMvnHc4a
         rVvnSwFcG2ORuOn5MWjm7CrlUIZOt9m1kNDp4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736854049; x=1737458849;
        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=+ldjiazwPH/9g3yJmkdafzgo4e1V47IDF3ZSi2eHgu4=;
        b=XNkAb0IqMwUFcC2cvlRC901vMHJcvfvGt5BXSrddI/ux2gE4FEsC9i2LCBz+LM8tIF
         te4Tt1rF5T5PEb1h35Lj3rpt2kiBFtOr2VHbF8Z9s0nXiyY2PMbSCHGY7bVQRNbCoi4N
         F3IRV33eJ1I9bRBGK6pdVhf+ff8aIwhuObnRo+2hSTdUHRyCx2GXAT3zVoUbcSAV6swN
         Oy84XuEX9THdd87+I1YQ2DRRVXhOIn8dzCJfZ7EEaZK5ZKSEI8i6z7Ci/f9ZuoXY25N9
         76CPxOlGReCYx8nDXOD5AGQ0j8iDtsXFy9OMvNm7Oh5+2iBMl2k1GtLQGKq5K0rYZRGp
         XPgQ==
X-Forwarded-Encrypted: i=1; AJvYcCXvqLRnqEW3Bu4QLXYdVaBYBtloRuWHQcotPUnswodcabMZv9IW/sF/1TQyS1u6gR5nWrA7EJQkh1s=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwKfolTI3gS9r7DmJMN2/ecFFOdF/EG3NS4GA+XC/s3IPxf2ZKc
	K1ke8RXV+F6TAbEZtwtouemXo9OCF7v0EbJhRo1z9Or5PfVJiuGUboe7CSqfGqE=
X-Gm-Gg: ASbGncs6jhQWZ5q9HDqSJBFs8KxJqo6/E0w9Z3twksEFn510p4/A5pCj8XhAUBzHtMO
	AS93IAUpE55x+se4FYNuxvcypoDvwwhhn62xaIdhv6HjPaYLF3hQ6C60OWlqWVXhb1IaDiJwhqL
	McB9wswx1r42fkkT9mluoOEfvp1tw/WpbuDNYUgj+f+SsRSHuVrLEWgRy82ETNaXDCrQo2D21bX
	LamAhCiLA1LTGemFwtmhtg5WuckGAwIreBv/slVoBX/kQIcnT0Jq/+84cxwUhYM6bg=
X-Google-Smtp-Source: AGHT+IE8eng1kEqFIdvntk1QFXrFAxg4/l8zMJCie8iIQHNaFTnDUyQEYIeGFhqb+qjOsbP31spVoA==
X-Received: by 2002:a05:6402:354b:b0:5d0:bf4a:3dfe with SMTP id 4fb4d7f45d1cf-5d972e4e7b6mr21832791a12.23.1736854049337;
        Tue, 14 Jan 2025 03:27:29 -0800 (PST)
Date: Tue, 14 Jan 2025 12:27:28 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>,
	xen-devel@lists.xenproject.org,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v7 1/2] x86/time: introduce command line option to select
 wallclock
Message-ID: <Z4ZKINmJXw5T2dsM@macbook.local>
References: <20240913075907.34460-1-roger.pau@citrix.com>
 <20240913075907.34460-2-roger.pau@citrix.com>
 <Z4U6WxtmaqGkqOqe@mail-itl>
 <Z4VS88REbzn5uasy@macbook.local>
 <49a2404f-0c45-4397-9094-a4189131832f@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <49a2404f-0c45-4397-9094-a4189131832f@gmail.com>

On Tue, Jan 14, 2025 at 12:12:03PM +0100, Oleksii Kurochko wrote:
> 
> On 1/13/25 6:52 PM, Roger Pau Monné wrote:
> > On Mon, Jan 13, 2025 at 05:07:55PM +0100, Marek Marczykowski-Górecki wrote:
> > > On Fri, Sep 13, 2024 at 09:59:06AM +0200, Roger Pau Monne wrote:
> > > > Allow setting the used wallclock from the command line.  When the option is set
> > > > to a value different than `auto` the probing is bypassed and the selected
> > > > implementation is used (as long as it's available).
> > > > 
> > > > The `xen` and `efi` options require being booted as a Xen guest (with Xen guest
> > > > supported built-in) or from UEFI firmware respectively.
> > > > 
> > > > Signed-off-by: Roger Pau Monné<roger.pau@citrix.com>
> > > Reviewed-by: Marek Marczykowski-Górecki<marmarek@invisiblethingslab.com>
> > Thanks for the review.
> > 
> > Oleksii, can I get your opinion as Release Manager about whether this
> > (and the following patch) would be suitable for committing to staging
> > given the current release state?
> > 
> > It's a workaround for broken EFI implementations that many downstreams
> > carry on their patch queue.
> 
> Based on your commit message, I understand this as addressing a bug ( but not very critical
> as IIUC downstreams have the similar patch on their side ). Therefore, if it has been properly
> reviewed and tested, we should consider including it in the current release.

IIRC at least Qubes, XenServer and XCP-ng have a patch that achieves
the same behavior as proposed here.

> IIUC, setting the wallclock to EFI should align with the behavior Xen had previously.
> It might be preferable to use that argument as the default for a while, allowing others to verify the "auto"
> value over time. After that, we could consider making "auto" the default.
> That said, I am not particularly strict about following this approach.

We cannot really set efi as the default, as it would break when
booting on legacy BIOS systems.

We could take only patch 1 and leave patch 2 after Xen 4.20 has
branched, but at that point I would see little benefit in having just
patch 1.

I don't have a strong opinion, but downstreams have been complaining
about Xen behavior regarding the usage of EFI_GET_TIME, so it might be
good to not ship yet another release with such allegedly broken
behavior.

Let me know what you think, as I would need a formal Release-Ack if
this is to be committed.

Thanks, Roger.

> ~ Oleksii
> 
> 
> > 
> > Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 11:39:28 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 11:39:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871234.1282270 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXfGL-0005b3-Gs; Tue, 14 Jan 2025 11:39:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871234.1282270; Tue, 14 Jan 2025 11:39:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXfGL-0005aw-Dg; Tue, 14 Jan 2025 11:39:13 +0000
Received: by outflank-mailman (input) for mailman id 871234;
 Tue, 14 Jan 2025 11:39:12 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=iLru=UG=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tXfGJ-0005aq-W0
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 11:39:11 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2ba8a9ef-d26c-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 12:39:10 +0100 (CET)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-5d7e3f1fdafso10995227a12.0
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 03:39:10 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d9904a411csm6093109a12.72.2025.01.14.03.39.09
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 14 Jan 2025 03:39:09 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2ba8a9ef-d26c-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736854750; x=1737459550; 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=8L9HH4K3xM0f6COjLZ16d2gapCO+SXHjhH+Cg7BPtVI=;
        b=I55Z6V+UwGtzkzmuevQyirUSkSMYHssKHWzXawJCd5nbxj27+AakLFwDaRe23yC/pC
         7wx4PdbDRXEOKbQQx1NlidDAukb7EyO0fZyzWOTkBSltAV50PKsJFkUjV0j6k/R29Q+8
         TWGmgakAZdBavtMOFFLF0O8ZICXcg5J91Fd7M=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736854750; x=1737459550;
        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=8L9HH4K3xM0f6COjLZ16d2gapCO+SXHjhH+Cg7BPtVI=;
        b=Ms/3wvkFJbtsjTTFeoQvyDVz7N3cxUNp7qynU21cZRwd7+n5GBIxP/okGZVDsHD4pZ
         ZYdMaxHjM9Pz8w67DHxISpua5B6koU51FQSEEOus/nxP84Bd3vw9VSGn7SR3S++zuv+z
         ziuoaNu1zlPyFvZNLC9MBah5KiLCo49uTKQDkbQlvqfdimTqK9mTqX1N06M4psx75eGw
         XH3SfgymCnveI0+2/8iPjxWdDUkWRPDlDCmNz76zXpFtGCjEHYfOpGQM24kMbAkEdpkY
         FnGcLjX1hPy4eQtrzk2vELlsPNo0aI+0pdk6gStbLIDgC9V1OPhM6T+CDdoGM3Z4qqnZ
         nMsg==
X-Forwarded-Encrypted: i=1; AJvYcCXoN3Ndv4i+I05+T0u4Q0nnzVG2O4LK4Cr1xJKEOMLFC6+bSx87dcxH9pcWiFll+rtEH3K4D58O6xk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzpROeIuSNckEEmBezavQWTHWDMtB0CRrUwIWRGwNjekABhKJv4
	sZBlA+Uyjtg+NRTGUx9FLgfyWazDiabUl1C0RCLsJFHz+wUgQngn8ARj4EtOUyYWQpOnda5sXSe
	a
X-Gm-Gg: ASbGncsY6HmYIooI2f+qt2jFBXvTMsPcf04hNOnFJknZr6QFfCrTMMtaMTDzS5WtRZq
	QRRMlpbcqu7Wxt87vxQ8b1oXVHFB36rqOeLK2SN47K4/ALe16szELx1PwhXx/4ZT6O0Dqv56vIU
	fPCq2zFBvke4MzxltTY/pA/kvDdzSU3XVyGBCl9ZlaYB4kRcq5y0HXYxxROtRj6iYVW4bTXnkul
	uoQibExHDpbcJvC0+8k8S/xevGIpBU4x8K2/4wjK6Gglg4bViaiOIuFRPUlnqQHwD8=
X-Google-Smtp-Source: AGHT+IGMmTqPfnaQeOydPkuHGM4z2RFHBAvyZ+jn/83ik0QSga4uqVnrxWWkMxvq4ANA1Ju7kFS18g==
X-Received: by 2002:a05:6402:1ec7:b0:5d0:81af:4a43 with SMTP id 4fb4d7f45d1cf-5d972d2063amr24771773a12.0.1736854749858;
        Tue, 14 Jan 2025 03:39:09 -0800 (PST)
Date: Tue, 14 Jan 2025 12:39:08 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Nicola Vetrini <nicola.vetrini@bugseng.com>
Cc: Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	xen-devel@lists.xenproject.org,
	Simone Ballarin <simone.ballarin@bugseng.com>,
	Doug Goldstein <cardoe@cardoe.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v2 2/2] automation/eclair: make Misra rule 20.7 blocking
 for x86 also
Message-ID: <Z4ZM3Er9dxqiUPNo@macbook.local>
References: <20241126093508.6966-1-roger.pau@citrix.com>
 <20241126093508.6966-3-roger.pau@citrix.com>
 <Z4ZI-WfUv73iQLI1@macbook.local>
 <54a6f4337e2f9bfc1f295b3c1e9a0897@bugseng.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <54a6f4337e2f9bfc1f295b3c1e9a0897@bugseng.com>

On Tue, Jan 14, 2025 at 12:24:30PM +0100, Nicola Vetrini wrote:
> On 2025-01-14 12:22, Roger Pau Monné wrote:
> > Hello Oleksii,
> > 
> > This is in principle ready to go in now (I'm currently running a
> > private Eclair scan to ensure the patch is still OK against current
> > staging).  I would like to ask for a release Ack.
> > 
> 
> One nit below, which I overlooked initially
> 
> > Thanks, Roger.
> > 
> > On Tue, Nov 26, 2024 at 10:35:08AM +0100, Roger Pau Monne wrote:
> > > There are no violations left, make the rule globally blocking for
> > > both x86 and
> > > ARM.
> > > 
> > > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> > > Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
> > > ---
> > >  automation/eclair_analysis/ECLAIR/tagging.ecl | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl
> > > b/automation/eclair_analysis/ECLAIR/tagging.ecl
> > > index 755ea3271fc9..cb4e233e838d 100644
> > > --- a/automation/eclair_analysis/ECLAIR/tagging.ecl
> > > +++ b/automation/eclair_analysis/ECLAIR/tagging.ecl
> > > @@ -80,6 +80,7 @@ MC3R1.R20.2||
> > >  MC3R1.R20.3||
> > >  MC3R1.R20.4||
> > >  MC3R1.R20.6||
> > > +MC3R1.R20.7||
> > >  MC3R1.R20.9||
> > >  MC3R1.R20.11||
> > >  MC3R1.R20.12||
> > > @@ -116,7 +117,7 @@ if(string_equal(target,"x86_64"),
> > >  )
> 
> this hunk will not apply because it uses MC3R1, rather than MC3R2. Should be
> an easy fix.
> 
> > > 
> > >  if(string_equal(target,"arm64"),
> > > -    service_selector({"additional_clean_guidelines","MC3R1.R2.1||MC3R1.R5.3||MC3.R11.2||MC3R1.R16.6||MC3R1.R20.7"})
> > > +    service_selector({"additional_clean_guidelines","MC3R1.R2.1||MC3R1.R5.3||MC3.R11.2||MC3R1.R16.6"})
> > >  )
> 
> here as well

Yeah indeed, I had to rebase the patch:

https://gitlab.com/xen-project/people/royger/xen/-/commit/538439d59dc338ee3861bf1bc056783671ba1fc2

Let's see if Eclair is happy with it, currently running a pipeline.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 11:40:46 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 11:40:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871246.1282280 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXfHp-0007Ac-TH; Tue, 14 Jan 2025 11:40:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871246.1282280; Tue, 14 Jan 2025 11:40:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXfHp-0007AV-Q6; Tue, 14 Jan 2025 11:40:45 +0000
Received: by outflank-mailman (input) for mailman id 871246;
 Tue, 14 Jan 2025 11:40: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
 <SRS0=wcbX=UG=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tXfHp-0007AJ-71
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 11:40:45 +0000
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com
 [2a00:1450:4864:20::12a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 63136440-d26c-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 12:40:43 +0100 (CET)
Received: by mail-lf1-x12a.google.com with SMTP id
 2adb3069b0e04-5401d3ea5a1so5341504e87.3
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 03:40:43 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5428bec3fadsm1660801e87.188.2025.01.14.03.40.41
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 14 Jan 2025 03:40:42 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 63136440-d26c-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736854843; x=1737459643; darn=lists.xenproject.org;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=tCvMpFPg8q0V/9z6iP7kPF9IeHLFD7m7wQT91KigUqE=;
        b=kJ3xbmCjPabQp9TLYVRi6tZpVDBayQpfjyrZU5RYo/xRmxtmCB+1fg/em98eZ00jGj
         WuVwUGcmiekm/IzDudjxJhkQ+4/5paHtaQB914hqZe1xN9KaXoraRO2eKiQN3q855ADx
         p/unM0eBMHg375RIwM4pbRC570eedM9abhImln0KfxM6rDzQgOnJuWYVyjoWG8ETSrHu
         4wCPmh8vMKC0pDiHwYM8nMb7DKLwRRc7O6zJj7GJgL3pxjZt7PNZAdi0cNxyZGuLK1T8
         ToDhTMibIi7RddgtvyU9YzS/r2m+p7buzDmqqSWzrgTN113qsUMteJCQ08V+1mAqHHXz
         yPFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736854843; x=1737459643;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=tCvMpFPg8q0V/9z6iP7kPF9IeHLFD7m7wQT91KigUqE=;
        b=HQfQvUAOCvyZa+tCcP0Q/5EI+Zm+rfloEMGU9/ZTy1nDATw+lmFS2/YOlicKkHV6D3
         /I7AVkim27DYabaS7HLJUpABS+BtZUCnWI6qF8n++Anz+4SAzUl8b8kwZIdzLSspcrmP
         V7JazzILaDqlcUPjUTM2eWAMGA3HMikqv0zB6s+hRptdtvPKooeeNmYUmRnGF0Cs/S0+
         8NMAkDnXjWSdts4OvE1aEQRpVL7T4xOQFZKn96mgxPDcgHmRByg/OrRQTEkE9g4A4cGL
         UlFOCku9zcjYJoJajkk8Q994gwDliFeqp7cgQ6bb/F3au7V50JHdNA1QfXjOJtyc22WG
         VGNA==
X-Forwarded-Encrypted: i=1; AJvYcCXUl0seMpeuKDQy5B45lSPyVpNi9p+fFKqG0gYApkoYXi/mhkY5sqt7HmJrMdOYDJt7XORbwqR0yfY=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxk/KFzr9UDPTfdDutgPRRxRA1JaLWzcId2LEeE9MbJbSwEN8DN
	qWQ+VOzPVgdct+kGTCJc/0TaQKCsD4KN8ecBtXajNXKZ66CAgXJw
X-Gm-Gg: ASbGnctZw5Z3LYc6Bl5616cAaG0g8BgWn/KJ71GG/n7NECPCxuLgJkwFwXHRWgs0IFe
	b0Vidw52s011znEDsiELhsMY402ghKpRagM6UfHgSVu67RyG17lvJb0i3elqXl7PPRwaQG4ynL5
	7Wmc1xN6vVBQPUkkI+btIPwSDmj80ARPLTb2mcQMNIEV5fs8XPqwLyE5ScxH661a2C4nR3xaXIv
	ACYnyBtRvXVlkyPmAqOF4T2A9+/tmSvIp8HjVfBF4u12y108PfgtvvzHfbBoHAQ/c50Eg==
X-Google-Smtp-Source: AGHT+IFhsTBFi9wbj6mU5gdFIFU7RphJ0sneOC8Q6CJx14xr9PcFHXwlJByz3gCR54XhHwyA1d5Z+g==
X-Received: by 2002:a05:6512:3c8c:b0:541:4900:7c42 with SMTP id 2adb3069b0e04-542845b1fffmr8736784e87.43.1736854842462;
        Tue, 14 Jan 2025 03:40:42 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------QZCsQ8CZ0plNpxFsSUBJl0N5"
Message-ID: <78e09ccb-65b7-4022-b9fc-7874e34c1a99@gmail.com>
Date: Tue, 14 Jan 2025 12:40:41 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 1/2] x86/time: introduce command line option to select
 wallclock
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Cc: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, xen-devel@lists.xenproject.org,
 "Daniel P. Smith" <dpsmith@apertussolutions.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>
References: <20240913075907.34460-1-roger.pau@citrix.com>
 <20240913075907.34460-2-roger.pau@citrix.com> <Z4U6WxtmaqGkqOqe@mail-itl>
 <Z4VS88REbzn5uasy@macbook.local>
 <49a2404f-0c45-4397-9094-a4189131832f@gmail.com>
 <Z4ZKINmJXw5T2dsM@macbook.local>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <Z4ZKINmJXw5T2dsM@macbook.local>

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


On 1/14/25 12:27 PM, Roger Pau Monné wrote:
> On Tue, Jan 14, 2025 at 12:12:03PM +0100, Oleksii Kurochko wrote:
>> On 1/13/25 6:52 PM, Roger Pau Monné wrote:
>>> On Mon, Jan 13, 2025 at 05:07:55PM +0100, Marek Marczykowski-Górecki wrote:
>>>> On Fri, Sep 13, 2024 at 09:59:06AM +0200, Roger Pau Monne wrote:
>>>>> Allow setting the used wallclock from the command line.  When the option is set
>>>>> to a value different than `auto` the probing is bypassed and the selected
>>>>> implementation is used (as long as it's available).
>>>>>
>>>>> The `xen` and `efi` options require being booted as a Xen guest (with Xen guest
>>>>> supported built-in) or from UEFI firmware respectively.
>>>>>
>>>>> Signed-off-by: Roger Pau Monné<roger.pau@citrix.com>
>>>> Reviewed-by: Marek Marczykowski-Górecki<marmarek@invisiblethingslab.com>
>>> Thanks for the review.
>>>
>>> Oleksii, can I get your opinion as Release Manager about whether this
>>> (and the following patch) would be suitable for committing to staging
>>> given the current release state?
>>>
>>> It's a workaround for broken EFI implementations that many downstreams
>>> carry on their patch queue.
>> Based on your commit message, I understand this as addressing a bug ( but not very critical
>> as IIUC downstreams have the similar patch on their side ). Therefore, if it has been properly
>> reviewed and tested, we should consider including it in the current release.
> IIRC at least Qubes, XenServer and XCP-ng have a patch that achieves
> the same behavior as proposed here.
>
>> IIUC, setting the wallclock to EFI should align with the behavior Xen had previously.
>> It might be preferable to use that argument as the default for a while, allowing others to verify the "auto"
>> value over time. After that, we could consider making "auto" the default.
>> That said, I am not particularly strict about following this approach.
> We cannot really set efi as the default, as it would break when
> booting on legacy BIOS systems.
>
> We could take only patch 1 and leave patch 2 after Xen 4.20 has
> branched, but at that point I would see little benefit in having just
> patch 1.

I don't see a lot of benefit of comitting only the one patch either.


>
> I don't have a strong opinion, but downstreams have been complaining
> about Xen behavior regarding the usage of EFI_GET_TIME, so it might be
> good to not ship yet another release with such allegedly broken
> behavior.

Agree with that. As  I mentioned above I consider it as a bug and based on
that several mentioned above downstreams have the similar patch I could consider
that as tested approach so ..

>
> Let me know what you think, as I would need a formal Release-Ack if
> this is to be committed.

... R-Acked-by: Oleksii Kurochko<oleksii.kurochko@gmail.com>.

Thanks.

~ Oleksii

>
> Thanks, Roger.
>
>> ~ Oleksii
>>
>>
>>> Thanks, Roger.
--------------QZCsQ8CZ0plNpxFsSUBJl0N5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 1/14/25 12:27 PM, Roger Pau Monné
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:Z4ZKINmJXw5T2dsM@macbook.local">
      <pre wrap="" class="moz-quote-pre">On Tue, Jan 14, 2025 at 12:12:03PM +0100, Oleksii Kurochko wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">
On 1/13/25 6:52 PM, Roger Pau Monné wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="" class="moz-quote-pre">On Mon, Jan 13, 2025 at 05:07:55PM +0100, Marek Marczykowski-Górecki wrote:
</pre>
          <blockquote type="cite">
            <pre wrap="" class="moz-quote-pre">On Fri, Sep 13, 2024 at 09:59:06AM +0200, Roger Pau Monne wrote:
</pre>
            <blockquote type="cite">
              <pre wrap="" class="moz-quote-pre">Allow setting the used wallclock from the command line.  When the option is set
to a value different than `auto` the probing is bypassed and the selected
implementation is used (as long as it's available).

The `xen` and `efi` options require being booted as a Xen guest (with Xen guest
supported built-in) or from UEFI firmware respectively.

Signed-off-by: Roger Pau Monné<a class="moz-txt-link-rfc2396E" href="mailto:roger.pau@citrix.com">&lt;roger.pau@citrix.com&gt;</a>
</pre>
            </blockquote>
            <pre wrap="" class="moz-quote-pre">Reviewed-by: Marek Marczykowski-Górecki<a class="moz-txt-link-rfc2396E" href="mailto:marmarek@invisiblethingslab.com">&lt;marmarek@invisiblethingslab.com&gt;</a>
</pre>
          </blockquote>
          <pre wrap="" class="moz-quote-pre">Thanks for the review.

Oleksii, can I get your opinion as Release Manager about whether this
(and the following patch) would be suitable for committing to staging
given the current release state?

It's a workaround for broken EFI implementations that many downstreams
carry on their patch queue.
</pre>
        </blockquote>
        <pre wrap="" class="moz-quote-pre">
Based on your commit message, I understand this as addressing a bug ( but not very critical
as IIUC downstreams have the similar patch on their side ). Therefore, if it has been properly
reviewed and tested, we should consider including it in the current release.
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
IIRC at least Qubes, XenServer and XCP-ng have a patch that achieves
the same behavior as proposed here.

</pre>
    </blockquote>
    <blockquote type="cite" cite="mid:Z4ZKINmJXw5T2dsM@macbook.local">
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">IIUC, setting the wallclock to EFI should align with the behavior Xen had previously.
It might be preferable to use that argument as the default for a while, allowing others to verify the "auto"
value over time. After that, we could consider making "auto" the default.
That said, I am not particularly strict about following this approach.
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
We cannot really set efi as the default, as it would break when
booting on legacy BIOS systems.

We could take only patch 1 and leave patch 2 after Xen 4.20 has
branched, but at that point I would see little benefit in having just
patch 1.</pre>
    </blockquote>
    <pre>I don't see a lot of benefit of comitting only the one patch either.</pre>
    <p><br>
    </p>
    <blockquote type="cite" cite="mid:Z4ZKINmJXw5T2dsM@macbook.local">
      <pre wrap="" class="moz-quote-pre">

I don't have a strong opinion, but downstreams have been complaining
about Xen behavior regarding the usage of EFI_GET_TIME, so it might be
good to not ship yet another release with such allegedly broken
behavior.</pre>
    </blockquote>
    <pre>Agree with that. As  I mentioned above I consider it as a bug and based on
that several mentioned above downstreams have the similar patch I could consider
that as tested approach so ..
</pre>
    <blockquote type="cite" cite="mid:Z4ZKINmJXw5T2dsM@macbook.local">
      <pre wrap="" class="moz-quote-pre">

Let me know what you think, as I would need a formal Release-Ack if
this is to be committed.</pre>
    </blockquote>
    <pre>... R-Acked-by: Oleksii Kurochko <a class="moz-txt-link-rfc2396E" href="mailto:oleksii.kurochko@gmail.com">&lt;oleksii.kurochko@gmail.com&gt;</a>.

</pre>
    <pre>Thanks.
<pre>
</pre></pre>
    <pre>~ Oleksii
</pre>
    <blockquote type="cite" cite="mid:Z4ZKINmJXw5T2dsM@macbook.local">
      <pre wrap="" class="moz-quote-pre">

Thanks, Roger.

</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">~ Oleksii


</pre>
        <blockquote type="cite">
          <pre wrap="" class="moz-quote-pre">
Thanks, Roger.
</pre>
        </blockquote>
      </blockquote>
    </blockquote>
  </body>
</html>

--------------QZCsQ8CZ0plNpxFsSUBJl0N5--


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 11:41:00 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 11:41:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871248.1282290 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXfI4-0007ch-49; Tue, 14 Jan 2025 11:41:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871248.1282290; Tue, 14 Jan 2025 11:41:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXfI4-0007ca-0s; Tue, 14 Jan 2025 11:41:00 +0000
Received: by outflank-mailman (input) for mailman id 871248;
 Tue, 14 Jan 2025 11:40:59 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/Vp6=UG=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tXfI3-0007Ur-2V
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 11:40:59 +0000
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com
 [2a00:1450:4864:20::333])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6c0b8e78-d26c-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 12:40:58 +0100 (CET)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-436ce2ab251so38405605e9.1
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 03:40:58 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436e2ddd113sm211227465e9.25.2025.01.14.03.40.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 14 Jan 2025 03:40:57 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 6c0b8e78-d26c-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736854858; x=1737459658; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=wYbvAXc7HfoH241Y+kQfPQUVsIwe/U9vO2ClxzNnzJ8=;
        b=ctbL3xQRtFuLtYtCdt6YdEU+mUyHs0BwZEvE7urLPsMDeAwht+AdPnlnXphLyrOqPZ
         JUS2wjtqDZjVHHbaAjo6TZDUUvLvheqsaFF/MxkIVJ47/HPdd3kTCudPj/8npe5072GP
         tDbqd8Qa03AkKntS3URPYRqFRLpPo3yzsmloyg6VQVKNqPVkYJsDLpftW0hyIgL+5unu
         HS4nSHWmxdtl/1+D8mCODprGkdIoxUgd8nvjQ0fIenYygjML4Mrst2XY6P6LLsVxfAOo
         7xAtgO/hAt6M1GOvgodNL7qf5T+Zw4uNHOn8qFYBWx6BNhujuCwzOo5cH9jv+w0/dJDz
         eapw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736854858; x=1737459658;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=wYbvAXc7HfoH241Y+kQfPQUVsIwe/U9vO2ClxzNnzJ8=;
        b=Yo+aAFA7OyOQ1v1rFqP7nOYt1+GIaqr12vg1eWaESDAQKmx0Es/uVoXg5VybHha05E
         Tu6tDPfMDVlZ1OfQLmby5ZoXU3JkB9Y36sVwHj3FL5HkMU0wdQ1D5tojBbG/0mTdErIu
         mY602CB5LY3WhwjX5Im+0npdmhdBMQC6SnSbgh2nb4pXbe2by3xpPwrYHN3ixYa0tQcz
         NTgLInusd40j84CefBiVTGXJDCZnD9oB2Zg2VdKq58hmMJn/Sy6KEGs5oVJWMohyiIGj
         RmSsj1vJJKNST1iPJ6iCM6sFbOahE/yDbGPlbf+rkQSbUhiutUlGbaFF3Q+RqgaazTuD
         6HjQ==
X-Forwarded-Encrypted: i=1; AJvYcCV+1wdOLh0ipMjC5jXKV6ikqiVHh4ou1f+iMffV0tKKNfSLRWdFx6Y9XbMR6NwvlOpPRqbFdS/SdD8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwfbHALQrd2R3YWQw0dNV4tw3mFgllvXEt5OEJ+4CG4b6IJ9aEN
	rzalEYHh4R5pRM8h82sEj+63N/6BhyeNPdMisqOH/n1x8BvSHS3t+beX+OD4Ew==
X-Gm-Gg: ASbGncu4WA3IFKxz6Zd/fn5HlgwyR3X/1ME4EJbyArWHvmCjffiyoUX1TdNSF3OFQZ/
	1kmCOoFUywxtakF4ufFH2eRY//cppNsF5kF7+vpvTg93Q/j5wGJswGAYaPgmn7FahmvUuiAE4vb
	Vs/6B+m1rAmfFse70FUblpsHRob9TpNhn6UAgTB8d8uWdPmv41byUlFQhSbaYFyxwT+XeIFIUAp
	SaKwIRzluP8ivkZW1rhb3fbvR67kAtckvYecKQm/KQa7lpGTZ6xcE02LeB+creyKVXUud+GjVrE
	yxGgGagrtqtdONU7fyTiV5qZxwZBp48PlY3LZhqw3Q==
X-Google-Smtp-Source: AGHT+IE7/Ohg+9Lshbyl63eDzjCYqUM8sVpFOjYhIXbihBFA7aiKB0W/o9L6nZVrI16RV3mcMJ028A==
X-Received: by 2002:a05:600c:a01:b0:434:9c1b:b36a with SMTP id 5b1f17b1804b1-436e269715amr213727235e9.13.1736854857905;
        Tue, 14 Jan 2025 03:40:57 -0800 (PST)
Message-ID: <32141eab-e26b-44f4-ae5a-cbac0bb8ec0e@suse.com>
Date: Tue, 14 Jan 2025 12:40:56 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/boot: Handle better alignment for 32 bit code
To: Frediano Ziglio <frediano.ziglio@cloud.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>,
 xen-devel@lists.xenproject.org
References: <20250114095914.93226-1-frediano.ziglio@cloud.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250114095914.93226-1-frediano.ziglio@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14.01.2025 10:59, Frediano Ziglio wrote:
> Output file didn't have correct alignment.
> Allows alignment into data or code up to 2mb.
> 
> Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>

Afaic this is way too little of a description. For example, ...

> --- a/xen/arch/x86/boot/Makefile
> +++ b/xen/arch/x86/boot/Makefile
> @@ -40,8 +40,8 @@ LD32 := $(LD) $(subst x86_64,i386,$(LDFLAGS_DIRECT))
>  # are affected by both text_diff and text_gap.  Ensure the sum of gap and diff
>  # is greater than 2^16 so that any 16bit relocations if present in the object
>  # file turns into a build-time error.
> -text_gap := 0x010200
> -text_diff := 0x408020
> +text_gap := 0x01c240
> +text_diff := 0x7e3dc0

... how is anyone to derive how we ended up with these magic numbers?
What parts of them are arbitrary, and what parts are required to be the
way they are?

> @@ -69,7 +69,6 @@ $(obj)/built-in-32.%.bin: $(obj)/build32.%.lds $(obj)/built-in-32.tmp.o
>  	$(LD32) $(orphan-handling-y) -N -T $< -o $(@:bin=o) $(filter %.o,$^)
>  	$(NM) -p --format=bsd $(@:bin=o) > $(@:bin=map)
>  	$(OBJCOPY) -j .text -O binary $(@:bin=o) $@
> -	rm -f $(@:bin=o)

This looks like an unrelated change. It may be okay to have here, but
then it needs mentioning in the description.

> @@ -80,6 +79,7 @@ cmd_combine = \
>                --bin1      $(obj)/built-in-32.base.bin \
>                --bin2      $(obj)/built-in-32.offset.bin \
>                --map       $(obj)/built-in-32.base.map \
> +              --align     $(shell $(OBJDUMP) -h $(obj)/built-in-32.base.o|sed '/text.*2\*\*/ {s/.*2\*\*//;p;}; d') \
>                --exports   cmdline_parse_early,reloc,reloc_trampoline32 \
>                --output    $@
>  
> @@ -90,4 +90,4 @@ $(obj)/built-in-32.S: $(obj)/built-in-32.base.bin $(obj)/built-in-32.offset.bin
>                        $(srctree)/tools/combine_two_binaries.py FORCE
>  	$(call if_changed,combine)
>  
> -clean-files := built-in-32.*.bin built-in-32.*.map build32.*.lds
> +clean-files := built-in-32.*.bin built-in-32.*.map built-in-32.*.o build32.*.lds

This looks like it would have been needed already before, if the build
process was interrupted before the "rm" that you remove above.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 11:44:50 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 11:44:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871266.1282299 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXfLg-0000SU-Ja; Tue, 14 Jan 2025 11:44:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871266.1282299; Tue, 14 Jan 2025 11:44:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXfLg-0000SN-Gc; Tue, 14 Jan 2025 11:44:44 +0000
Received: by outflank-mailman (input) for mailman id 871266;
 Tue, 14 Jan 2025 11:44:43 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=wcbX=UG=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tXfLf-0000SF-At
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 11:44:43 +0000
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com
 [2a00:1450:4864:20::22f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f0f9a7d5-d26c-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 12:44:41 +0100 (CET)
Received: by mail-lj1-x22f.google.com with SMTP id
 38308e7fff4ca-3003d7ca01cso49389341fa.0
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 03:44:41 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-305ff0ad5c2sm17625801fa.16.2025.01.14.03.44.40
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 14 Jan 2025 03:44:40 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f0f9a7d5-d26c-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736855081; x=1737459881; darn=lists.xenproject.org;
        h=in-reply-to:content-language:references:cc:to:from:subject
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=+XaYozwTqETsYJe+znD0F5gJuDUetVDR68XOLvdpS2Y=;
        b=JHxFiUI7hT6tp3l0zXsmE0mJR1Uv1kJErsfdSQ7bu32IgZ3jYwoLp3hKrm0jc+3CPa
         axz1LDaRJvQHTQq9qYCtXYw+jAj+qO25cLAEQbBIV5S1FuVV/8LjRx03TxDXMHxVTM/t
         dhiI70MC6U574BWd1OvDvwebWikFtp8g+VdqCq7eQzab85Arj6BNYjY6vhfHIsbwYm8Q
         UnOQXj4OS5aLVwbJjq+Z52CWiOahmjwqCa4A9gIBMvgYHAUb8DNeY4bN4JZwbvaQ4mqU
         OqEHt9icaSKQneQ59z+oXAm0AVhRqpXSIrs2S++4QtX0sb/qqnLXx2RcuvIHHJaVy/ox
         kiNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736855081; x=1737459881;
        h=in-reply-to:content-language:references:cc:to:from:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=+XaYozwTqETsYJe+znD0F5gJuDUetVDR68XOLvdpS2Y=;
        b=GrOQSl+G1j59z205cT+hQ0JjQ4Op0S85g1RYUP0Xp67xN/cAUH5/8YAjHVLknMSQ1f
         bCbGbb9hQXLBeo+bt3cZt+TD7K0P+MxSNcYpGdJMPY2DiWY6tz6+DUzkXeCXlFYJo97o
         RkScPzN3H9ZrBweCwXHff7U47D7jgiJRrX73CLrnNais70ureNMV4iQWdMq9Nqgm1y1h
         u8bKnaqTQzfJoVxUuy8KlErcf7xGYeFVkdjM7Glqj1OfeXaNEWc49DScMbiXgOdXFaqA
         f/D/x5IFPb56RtKUBbDBRnSb6Tqn4VkZPLzDiW9o/dbkiH+3qBSE05PfDRk1KVxnlvNd
         MdeA==
X-Forwarded-Encrypted: i=1; AJvYcCVh8HU4TQ6A6GJ9YafsjN7BzKN2rTPQB1go8nZWurEt/gOBw6JC/gilJBKgYVnwNl/81Tw55g29s1c=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxOBqLbOaM3oKgWlqBmP/7wNUmPfX0fdpMQwCLIT56oj2gtorL+
	wetdUfY9vFOshME0T5uOXfL/CkYVWjF/wJVQHbN9iRM7kOcvtJR2
X-Gm-Gg: ASbGncsjCq/Tf4odgb7yjh1oT7cRG0jnvaGh5haJX4bpHtjkaDknm2QZodYlAYzoPhg
	N5n2GzjisP4w3hZ0VzJurGinYm6Ju+ZFWSg0rDCm4rEXxEWq9Y3GcKmWnPDL4CcFwMvgdpYCmCf
	oqF/66Y4YaZ8Ye5lttPSqHgUheSMeDe98OWkujJgYTcxdEX3yRd62jGKkJks9aEH4Zim68LO2yp
	wnKavc5IuNz0KLEd7DzSO6KovmOj1T/Nd6uBbNckq38NBkcorkSQ3JAY5XvID4DWHXFfQ==
X-Google-Smtp-Source: AGHT+IE3pamJWMiWovbwxdVKpRaABanA9UlGG+eT1TWdP0/jWI7KjAkNYqYLNsajKUIyD7PdmjvkaA==
X-Received: by 2002:a2e:b8c7:0:b0:2fb:58b1:3731 with SMTP id 38308e7fff4ca-305f452ff17mr76337251fa.6.1736855080619;
        Tue, 14 Jan 2025 03:44:40 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------swl03aAHTgQxmDA0OzwO8T1x"
Message-ID: <9288f0de-945f-4056-9934-16b2b1704fb1@gmail.com>
Date: Tue, 14 Jan 2025 12:44:39 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 1/2] x86/time: introduce command line option to select
 wallclock
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Cc: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, xen-devel@lists.xenproject.org,
 "Daniel P. Smith" <dpsmith@apertussolutions.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>
References: <20240913075907.34460-1-roger.pau@citrix.com>
 <20240913075907.34460-2-roger.pau@citrix.com> <Z4U6WxtmaqGkqOqe@mail-itl>
 <Z4VS88REbzn5uasy@macbook.local>
 <49a2404f-0c45-4397-9094-a4189131832f@gmail.com>
 <Z4ZKINmJXw5T2dsM@macbook.local>
 <78e09ccb-65b7-4022-b9fc-7874e34c1a99@gmail.com>
Content-Language: en-US
In-Reply-To: <78e09ccb-65b7-4022-b9fc-7874e34c1a99@gmail.com>

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


On 1/14/25 12:40 PM, Oleksii Kurochko wrote:
>
>
> On 1/14/25 12:27 PM, Roger Pau Monné wrote:
>> On Tue, Jan 14, 2025 at 12:12:03PM +0100, Oleksii Kurochko wrote:
>>> On 1/13/25 6:52 PM, Roger Pau Monné wrote:
>>>> On Mon, Jan 13, 2025 at 05:07:55PM +0100, Marek Marczykowski-Górecki wrote:
>>>>> On Fri, Sep 13, 2024 at 09:59:06AM +0200, Roger Pau Monne wrote:
>>>>>> Allow setting the used wallclock from the command line.  When the option is set
>>>>>> to a value different than `auto` the probing is bypassed and the selected
>>>>>> implementation is used (as long as it's available).
>>>>>>
>>>>>> The `xen` and `efi` options require being booted as a Xen guest (with Xen guest
>>>>>> supported built-in) or from UEFI firmware respectively.
>>>>>>
>>>>>> Signed-off-by: Roger Pau Monné<roger.pau@citrix.com>
>>>>> Reviewed-by: Marek Marczykowski-Górecki<marmarek@invisiblethingslab.com>
>>>> Thanks for the review.
>>>>
>>>> Oleksii, can I get your opinion as Release Manager about whether this
>>>> (and the following patch) would be suitable for committing to staging
>>>> given the current release state?
>>>>
>>>> It's a workaround for broken EFI implementations that many downstreams
>>>> carry on their patch queue.
>>> Based on your commit message, I understand this as addressing a bug ( but not very critical
>>> as IIUC downstreams have the similar patch on their side ). Therefore, if it has been properly
>>> reviewed and tested, we should consider including it in the current release.
>> IIRC at least Qubes, XenServer and XCP-ng have a patch that achieves
>> the same behavior as proposed here.
>>
>>> IIUC, setting the wallclock to EFI should align with the behavior Xen had previously.
>>> It might be preferable to use that argument as the default for a while, allowing others to verify the "auto"
>>> value over time. After that, we could consider making "auto" the default.
>>> That said, I am not particularly strict about following this approach.
>> We cannot really set efi as the default, as it would break when
>> booting on legacy BIOS systems.
>>
>> We could take only patch 1 and leave patch 2 after Xen 4.20 has
>> branched, but at that point I would see little benefit in having just
>> patch 1.
> I don't see a lot of benefit of comitting only the one patch either.
>
>
>> I don't have a strong opinion, but downstreams have been complaining
>> about Xen behavior regarding the usage of EFI_GET_TIME, so it might be
>> good to not ship yet another release with such allegedly broken
>> behavior.
> Agree with that. As  I mentioned above I consider it as a bug and based on
> that several mentioned above downstreams have the similar patch I could consider
> that as tested approach so ..
>> Let me know what you think, as I would need a formal Release-Ack if
>> this is to be committed.
> ... R-Acked-by: Oleksii Kurochko<oleksii.kurochko@gmail.com>.

Sorry for the noise.

I missed to add that it would also be nice to mention IMO ( that now we have wallclock parameter )
in CHANGELOG so downstreams will receive "notification" that Xen provides a workaround for the mentioned
issue in the patch series.

Thanks.

~ Oleksii

>
> Thanks.
> ~ Oleksii
>> Thanks, Roger.
>>
>>> ~ Oleksii
>>>
>>>
>>>> Thanks, Roger.
--------------swl03aAHTgQxmDA0OzwO8T1x
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 1/14/25 12:40 PM, Oleksii Kurochko
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:78e09ccb-65b7-4022-b9fc-7874e34c1a99@gmail.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <p><br>
      </p>
      <div class="moz-cite-prefix">On 1/14/25 12:27 PM, Roger Pau Monné
        wrote:<br>
      </div>
      <blockquote type="cite" cite="mid:Z4ZKINmJXw5T2dsM@macbook.local">
        <pre wrap="" class="moz-quote-pre">On Tue, Jan 14, 2025 at 12:12:03PM +0100, Oleksii Kurochko wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="" class="moz-quote-pre">On 1/13/25 6:52 PM, Roger Pau Monné wrote:
</pre>
          <blockquote type="cite">
            <pre wrap="" class="moz-quote-pre">On Mon, Jan 13, 2025 at 05:07:55PM +0100, Marek Marczykowski-Górecki wrote:
</pre>
            <blockquote type="cite">
              <pre wrap="" class="moz-quote-pre">On Fri, Sep 13, 2024 at 09:59:06AM +0200, Roger Pau Monne wrote:
</pre>
              <blockquote type="cite">
                <pre wrap="" class="moz-quote-pre">Allow setting the used wallclock from the command line.  When the option is set
to a value different than `auto` the probing is bypassed and the selected
implementation is used (as long as it's available).

The `xen` and `efi` options require being booted as a Xen guest (with Xen guest
supported built-in) or from UEFI firmware respectively.

Signed-off-by: Roger Pau Monné<a class="moz-txt-link-rfc2396E"
                href="mailto:roger.pau@citrix.com"
                moz-do-not-send="true">&lt;roger.pau@citrix.com&gt;</a>
</pre>
              </blockquote>
              <pre wrap="" class="moz-quote-pre">Reviewed-by: Marek Marczykowski-Górecki<a
              class="moz-txt-link-rfc2396E"
              href="mailto:marmarek@invisiblethingslab.com"
              moz-do-not-send="true">&lt;marmarek@invisiblethingslab.com&gt;</a>
</pre>
            </blockquote>
            <pre wrap="" class="moz-quote-pre">Thanks for the review.

Oleksii, can I get your opinion as Release Manager about whether this
(and the following patch) would be suitable for committing to staging
given the current release state?

It's a workaround for broken EFI implementations that many downstreams
carry on their patch queue.
</pre>
          </blockquote>
          <pre wrap="" class="moz-quote-pre">Based on your commit message, I understand this as addressing a bug ( but not very critical
as IIUC downstreams have the similar patch on their side ). Therefore, if it has been properly
reviewed and tested, we should consider including it in the current release.
</pre>
        </blockquote>
        <pre wrap="" class="moz-quote-pre">IIRC at least Qubes, XenServer and XCP-ng have a patch that achieves
the same behavior as proposed here.

</pre>
      </blockquote>
      <blockquote type="cite" cite="mid:Z4ZKINmJXw5T2dsM@macbook.local">
        <blockquote type="cite">
          <pre wrap="" class="moz-quote-pre">IIUC, setting the wallclock to EFI should align with the behavior Xen had previously.
It might be preferable to use that argument as the default for a while, allowing others to verify the "auto"
value over time. After that, we could consider making "auto" the default.
That said, I am not particularly strict about following this approach.
</pre>
        </blockquote>
        <pre wrap="" class="moz-quote-pre">We cannot really set efi as the default, as it would break when
booting on legacy BIOS systems.

We could take only patch 1 and leave patch 2 after Xen 4.20 has
branched, but at that point I would see little benefit in having just
patch 1.</pre>
      </blockquote>
      <pre>I don't see a lot of benefit of comitting only the one patch either.</pre>
      <p><br>
      </p>
      <blockquote type="cite" cite="mid:Z4ZKINmJXw5T2dsM@macbook.local">
        <pre wrap="" class="moz-quote-pre">I don't have a strong opinion, but downstreams have been complaining
about Xen behavior regarding the usage of EFI_GET_TIME, so it might be
good to not ship yet another release with such allegedly broken
behavior.</pre>
      </blockquote>
      <pre>Agree with that. As  I mentioned above I consider it as a bug and based on
that several mentioned above downstreams have the similar patch I could consider
that as tested approach so ..
</pre>
      <blockquote type="cite" cite="mid:Z4ZKINmJXw5T2dsM@macbook.local">
        <pre wrap="" class="moz-quote-pre">Let me know what you think, as I would need a formal Release-Ack if
this is to be committed.</pre>
      </blockquote>
      <pre>... R-Acked-by: Oleksii Kurochko <a
      class="moz-txt-link-rfc2396E"
      href="mailto:oleksii.kurochko@gmail.com" moz-do-not-send="true">&lt;oleksii.kurochko@gmail.com&gt;</a>.</pre>
    </blockquote>
    <pre>Sorry for the noise. </pre>
    <pre>
</pre>
    <pre>I missed to add that it would also be nice to mention IMO ( that now we have wallclock parameter )
in CHANGELOG so downstreams will receive "notification" that Xen provides a workaround for the mentioned
issue in the patch series.
</pre>
    <pre>Thanks.
</pre>
    <pre>~ Oleksii
</pre>
    <blockquote type="cite"
      cite="mid:78e09ccb-65b7-4022-b9fc-7874e34c1a99@gmail.com">
      <pre>

</pre>
      <pre>Thanks.
</pre>
      <pre>~ Oleksii
</pre>
      <blockquote type="cite" cite="mid:Z4ZKINmJXw5T2dsM@macbook.local">
        <pre wrap="" class="moz-quote-pre">Thanks, Roger.

</pre>
        <blockquote type="cite">
          <pre wrap="" class="moz-quote-pre">~ Oleksii


</pre>
          <blockquote type="cite">
            <pre wrap="" class="moz-quote-pre">Thanks, Roger.
</pre>
          </blockquote>
        </blockquote>
      </blockquote>
    </blockquote>
  </body>
</html>

--------------swl03aAHTgQxmDA0OzwO8T1x--


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 11:51:31 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 11:51:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871280.1282309 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXfS9-0002Li-DL; Tue, 14 Jan 2025 11:51:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871280.1282309; Tue, 14 Jan 2025 11:51:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXfS9-0002Lb-AL; Tue, 14 Jan 2025 11:51:25 +0000
Received: by outflank-mailman (input) for mailman id 871280;
 Tue, 14 Jan 2025 11:51: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
 <SRS0=wcbX=UG=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tXfS7-0002LV-Jz
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 11:51:23 +0000
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com
 [2a00:1450:4864:20::130])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e00d9f9e-d26d-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 12:51:22 +0100 (CET)
Received: by mail-lf1-x130.google.com with SMTP id
 2adb3069b0e04-54024aa9febso4708520e87.1
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 03:51:22 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5428be53e86sm1695744e87.62.2025.01.14.03.51.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 14 Jan 2025 03:51:21 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e00d9f9e-d26d-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736855482; x=1737460282; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=YlCVUO5UPH5SMzxPMXud7BtfaNUcpBzGyRU6JqESZCs=;
        b=McPaEp49sfVuRwSnXFegyHSH85RQrUS+AxYCNFUZ6ulCDyGQ7Z+hMSdLGOErar/tHw
         gP+H+J0+NtscmZzsPxvyT0hfSHQLANPZ25QkctKTxgAkx16YomFOmPhomU+4FMFDSEYe
         fKue5ZUn17nPvQ7DKdydCZbqlmuUNO9gG3YHtAMCtDu1k2mfJ923T7INEK2o1O8hvpyL
         DTYXLTHnmx+OJma37C64Xjg8staPFbkRFyhrt4J2j1YGfs5dG1WBGJMOBJEDWAcocdeG
         BmzHrbOEYwnV6zo911SgMRxLAevnoIeUKgMSQNnIbEy+mPBNEclRgFz7jZLn53AFCPx8
         6meg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736855482; x=1737460282;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=YlCVUO5UPH5SMzxPMXud7BtfaNUcpBzGyRU6JqESZCs=;
        b=iqda0ze5v8EK+mfjGVuIhAmPLuT84gohZchihW4wwMzs5VLExeWxmQm3Ml6WBo+Vji
         OwQlvCVtSSvtl/lsn3EYUKpmh6MLu3cSnrWjGxbYE5+C/031w2flFg6jEEd7qM3XldV+
         A11t+9wLuVFTpfPtJYSIDJVYqTh+/NaQwl8kcXtS1juc9gBO49BQDpxRBEOH7/CK+2Ol
         rsehu2UrqowSaEkAC0Iee+0YkHh/P/VnBZXfdnmOLhSUDp9wmmFKghoNeLL1RdEm9jHk
         b1oGPMrOUK9hzS/H1BxC2jd4+PRwGJkNxohGXmDIHLtbFS+J8do6+z/dB+QOFiIap2DP
         4Ubw==
X-Gm-Message-State: AOJu0YxX5qn0iZKkn1y52PDHsBowwKy+vVSH6R5Omi/xdjU2pwdcWS/1
	RGpGx/uQMV/mgmd1Jcj37LXRB5qFbBCmBKSu/ogDaUWQAav806JGvZebKw==
X-Gm-Gg: ASbGncv9K90fDg9+PFDLaeRM+sBGlHUNrcIVuJU8rSLSj4FPE3yVEi4eBIcFicupzJA
	MPzKwvI7wlMtTsMpnDtIBuHZgh0GhnjW0M95/kvOupyPY0XWvDJWcDirl8VS1Cm9h4xOszNzeE5
	JLu1/6lPds1y+j1kBk4DNjex1J5wVUy6MsD2C43WyVW/P4mgLi7IfKzraUjJV4yKK66iTQAHoZF
	3txVGjP82lPoKy31g/EBzP4a45XZ7ZXtFwxk+s73hO4nvFWWrIQxdftwXiwj33bxKRuYA==
X-Google-Smtp-Source: AGHT+IELxc2eP8I67QmpikBV7z9BRyJ/WqiixOQhwKv4VmY88ClXjqLLlWEaMQof7T/+mbWnNNJbYA==
X-Received: by 2002:a05:6512:318d:b0:540:2223:9b0b with SMTP id 2adb3069b0e04-54284801dbemr7505398e87.35.1736855481572;
        Tue, 14 Jan 2025 03:51:21 -0800 (PST)
Message-ID: <19dd80e1-deb2-45fa-93e1-3b5952a8ff80@gmail.com>
Date: Tue, 14 Jan 2025 12:51:20 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/2] automation/eclair: make Misra rule 20.7 blocking
 for x86 also
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Cc: xen-devel@lists.xenproject.org,
 Simone Ballarin <simone.ballarin@bugseng.com>,
 Doug Goldstein <cardoe@cardoe.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
References: <20241126093508.6966-1-roger.pau@citrix.com>
 <20241126093508.6966-3-roger.pau@citrix.com> <Z4ZI-WfUv73iQLI1@macbook.local>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <Z4ZI-WfUv73iQLI1@macbook.local>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Roger,

On 1/14/25 12:22 PM, Roger Pau Monné wrote:
> Hello Oleksii,
>
> This is in principle ready to go in now (I'm currently running a
> private Eclair scan to ensure the patch is still OK against current
> staging).  I would like to ask for a release Ack.

R-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

Thanks.

~ Oleksii


>
> Thanks, Roger.
>
> On Tue, Nov 26, 2024 at 10:35:08AM +0100, Roger Pau Monne wrote:
>> There are no violations left, make the rule globally blocking for both x86 and
>> ARM.
>>
>> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
>> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> ---
>>   automation/eclair_analysis/ECLAIR/tagging.ecl | 3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl b/automation/eclair_analysis/ECLAIR/tagging.ecl
>> index 755ea3271fc9..cb4e233e838d 100644
>> --- a/automation/eclair_analysis/ECLAIR/tagging.ecl
>> +++ b/automation/eclair_analysis/ECLAIR/tagging.ecl
>> @@ -80,6 +80,7 @@ MC3R1.R20.2||
>>   MC3R1.R20.3||
>>   MC3R1.R20.4||
>>   MC3R1.R20.6||
>> +MC3R1.R20.7||
>>   MC3R1.R20.9||
>>   MC3R1.R20.11||
>>   MC3R1.R20.12||
>> @@ -116,7 +117,7 @@ if(string_equal(target,"x86_64"),
>>   )
>>   
>>   if(string_equal(target,"arm64"),
>> -    service_selector({"additional_clean_guidelines","MC3R1.R2.1||MC3R1.R5.3||MC3.R11.2||MC3R1.R16.6||MC3R1.R20.7"})
>> +    service_selector({"additional_clean_guidelines","MC3R1.R2.1||MC3R1.R5.3||MC3.R11.2||MC3R1.R16.6"})
>>   )
>>   
>>   -reports+={clean:added,"service(clean_guidelines_common||additional_clean_guidelines)"}
>> -- 
>> 2.46.0
>>


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 11:54:43 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 11:54:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871290.1282320 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXfVK-0003IO-QR; Tue, 14 Jan 2025 11:54:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871290.1282320; Tue, 14 Jan 2025 11:54:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXfVK-0003IH-Nc; Tue, 14 Jan 2025 11:54:42 +0000
Received: by outflank-mailman (input) for mailman id 871290;
 Tue, 14 Jan 2025 11:54:41 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=s7Sb=UG=cloud.com=frediano.ziglio@srs-se1.protection.inumbo.net>)
 id 1tXfVJ-0003IA-0d
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 11:54:41 +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 55b07885-d26e-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 12:54:39 +0100 (CET)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-43625c4a50dso38629945e9.0
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 03:54:39 -0800 (PST)
Received: from localhost.localdomain (158.79.208.46.dyn.plus.net.
 [46.208.79.158]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436ed48f4b2sm160187495e9.24.2025.01.14.03.54.38
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 14 Jan 2025 03:54:38 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 55b07885-d26e-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736855679; x=1737460479; 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=Y85RMcDcdplXx55rxPoCT7LP+dU+Acd11R/HOfjnmew=;
        b=U5+VzOgxIFUKQkrgqDsuudGX7tycZLaHUh6wvdrJ487yLOMbnBk6lUTtJS9MdNe9PT
         1lboh+TP8sC6BTMkHeEF9v2dtQLPcgirWC7/42k0v7my2KUF+fBj+8VKD/OgPAM5MJwh
         qv/yBbP+lQsWa18PJeetFuh4CrYEIi3Flc6FM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736855679; x=1737460479;
        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=Y85RMcDcdplXx55rxPoCT7LP+dU+Acd11R/HOfjnmew=;
        b=UeOFlpM3lUZOv6RaIQlnca1rRpJlG9gSdfdkOPYmzFtN8LCY4hL0LxtFOWLlLz29fi
         q2iKOGlr1qlRIz5ga1WA7WqyAz/BpZoEbPv8BeUFxUk1M9qyFrIRVRYs74ZsZSjlT9N3
         8AfRjwiuHzLuvy0QsFxu2/NMyrKOEV0T1grDKDL1Dnl47RRCPPqMljDk9ftdAxNMkdCm
         0Xw3z5l6AUp+DLeoPCSChYx/suFOh7pTrZ8Dkb3Xx0rgrlhzUFfIb9xCTM1hrfXKey7E
         EyGs4S8BiX70Zv00NtNUezjMJhx2g0iwEWk3G4J7CfX6iRGcdPodF4y6jXBGUAd3kdAi
         DAGg==
X-Gm-Message-State: AOJu0Yz2Nogm2Hl0ckLgcTbcCGfvamBZGWXj8bnJnOsVP2f6u4IWLU8Z
	f2s8nYRsOY4EmF+LgqJnjCMoJQ0V3EtjlsmQbPpIsd3K7m3Osj16XEAD9QX2G4BRPQg5Rz3MjZE
	8
X-Gm-Gg: ASbGncvK48/egECfh51tlTSqF9kHYLoaudLM9ha4ioUU0bRxGH1eX7uQjmHu1TxrZCf
	ho192sKc+vxw08Xm/yD3zAZ8qr13VZZ1IYu7y5U/0gTcOyn+1Ekxq9qbA2ZvAegrQc5/zU4Z8Xh
	To1XJo+naXGZJaf90J2rK5ACkB7wnAtacEg3zeSRHFNPXe2w0lygLV9ZJ+7TP5kRHxtmjZgNfVx
	KEBFFdCThIHMxfGDPeGaPvy/kkVm762sU8uCAgKhPCTmEuArw1XTC39Qa2JyZMg0shoLhejG9bL
	bnEgj2wHJWSgzH+GzrZhz9ajteg=
X-Google-Smtp-Source: AGHT+IGATqBTzThg/NHUDRGkbKgnJSwL/iLwQrLZqisIJB9AcK6h2aIzUMRL6BFym81BO7yJ2o+PVA==
X-Received: by 2002:a05:600c:4713:b0:434:ff08:202b with SMTP id 5b1f17b1804b1-436e26970bcmr230811895e9.12.1736855679019;
        Tue, 14 Jan 2025 03:54:39 -0800 (PST)
From: Frediano Ziglio <frediano.ziglio@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio <frediano.ziglio@cloud.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v2] x86/boot: Handle better alignment for 32 bit code
Date: Tue, 14 Jan 2025 11:54:30 +0000
Message-Id: <20250114115430.104084-1-frediano.ziglio@cloud.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Output file didn't have correct alignment.
Allows alignment into data or code up to 2mb.
Intermediate object files are kept in order to copy alignment
from object produced by the linker and final object (produced
by combine_two_binaries.py script).

Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
---
 xen/arch/x86/boot/Makefile        | 12 ++++++++----
 xen/tools/combine_two_binaries.py |  7 ++++++-
 2 files changed, 14 insertions(+), 5 deletions(-)

Changes since v1:
- Improve comments and description.

diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
index 13d4583173..a56d8a7e0f 100644
--- a/xen/arch/x86/boot/Makefile
+++ b/xen/arch/x86/boot/Makefile
@@ -40,8 +40,12 @@ LD32 := $(LD) $(subst x86_64,i386,$(LDFLAGS_DIRECT))
 # are affected by both text_diff and text_gap.  Ensure the sum of gap and diff
 # is greater than 2^16 so that any 16bit relocations if present in the object
 # file turns into a build-time error.
-text_gap := 0x010200
-text_diff := 0x408020
+# As gap will affect the output section size it should not be huge to avoid the
+# creation of huge files.
+# The sum of gap and diff will affect the possible alignment so should be a
+# multiple of the possible alignment.
+text_gap := 0x01c240
+text_diff := 0x7e3dc0
 
 $(obj)/build32.base.lds: AFLAGS-y += -DGAP=$(text_gap) -DTEXT_DIFF=$(text_diff)
 $(obj)/build32.offset.lds: AFLAGS-y += -DGAP=$(text_gap) -DTEXT_DIFF=$(text_diff) -DAPPLY_OFFSET
@@ -69,7 +73,6 @@ $(obj)/built-in-32.%.bin: $(obj)/build32.%.lds $(obj)/built-in-32.tmp.o
 	$(LD32) $(orphan-handling-y) -N -T $< -o $(@:bin=o) $(filter %.o,$^)
 	$(NM) -p --format=bsd $(@:bin=o) > $(@:bin=map)
 	$(OBJCOPY) -j .text -O binary $(@:bin=o) $@
-	rm -f $(@:bin=o)
 
 quiet_cmd_combine = GEN     $@
 cmd_combine = \
@@ -80,6 +83,7 @@ cmd_combine = \
               --bin1      $(obj)/built-in-32.base.bin \
               --bin2      $(obj)/built-in-32.offset.bin \
               --map       $(obj)/built-in-32.base.map \
+              --align     $(shell $(OBJDUMP) -h $(obj)/built-in-32.base.o|sed '/text.*2\*\*/ {s/.*2\*\*//;p;}; d') \
               --exports   cmdline_parse_early,reloc,reloc_trampoline32 \
               --output    $@
 
@@ -90,4 +94,4 @@ $(obj)/built-in-32.S: $(obj)/built-in-32.base.bin $(obj)/built-in-32.offset.bin
                       $(srctree)/tools/combine_two_binaries.py FORCE
 	$(call if_changed,combine)
 
-clean-files := built-in-32.*.bin built-in-32.*.map build32.*.lds
+clean-files := built-in-32.*.bin built-in-32.*.map built-in-32.*.o build32.*.lds
diff --git a/xen/tools/combine_two_binaries.py b/xen/tools/combine_two_binaries.py
index 581e57cbc0..8e587c24fb 100755
--- a/xen/tools/combine_two_binaries.py
+++ b/xen/tools/combine_two_binaries.py
@@ -26,6 +26,10 @@ parser.add_argument('--text-diff', dest='text_diff',
                     required=True,
                     type=auto_int,
                     help='Difference between code section start')
+parser.add_argument('--align', dest='align',
+                    default=2,
+                    type=auto_int,
+                    help='Alignment in power of 2')
 parser.add_argument('--output', dest='output',
                     help='Output file')
 parser.add_argument('--map', dest='mapfile',
@@ -93,7 +97,7 @@ if size1 > size2:
     file1, file2 = file2, file1
     size1, size2 = size2, size1
 if size2 != size1 + gap:
-    raise Exception('File sizes do not match')
+    raise Exception('File sizes do not match %d != %d + %d' % (size2, size1, gap))
 del size2
 
 file1.seek(0, 0)
@@ -219,6 +223,7 @@ print('''/*
  * File autogenerated by combine_two_binaries.py DO NOT EDIT
  */''', file=out)
 print('\t' + args.section_header, file=out)
+print('\t.p2align\t' + str(args.align), file=out)
 print('obj32_start:', file=out)
 output(out)
 print('\n\t.section .note.GNU-stack,"",@progbits', file=out)
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 12:14:00 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 12:14:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871308.1282329 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXfnu-0007IK-Hu; Tue, 14 Jan 2025 12:13:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871308.1282329; Tue, 14 Jan 2025 12:13:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXfnu-0007ID-FC; Tue, 14 Jan 2025 12:13:54 +0000
Received: by outflank-mailman (input) for mailman id 871308;
 Tue, 14 Jan 2025 12:13:53 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=iLru=UG=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tXfnt-0007I7-MX
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 12:13:53 +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 04adf0e4-d271-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 13:13:52 +0100 (CET)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-5d9f06f8cf2so2470100a12.3
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 04:13:52 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c905e1fesm627620366b.2.2025.01.14.04.13.51
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 14 Jan 2025 04:13:51 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 04adf0e4-d271-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736856832; x=1737461632; 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=UVAvvLm1iFc6Iabd5RJ2uYFUbgoKPkWiZ/vM5RQWmc0=;
        b=hCK9kSTqAiHibZ328w4Ks2C/gOypv5noTh/8DwogRxjChUqgCfapa3az2d/JF6Bxay
         fp2ZpyWuKWESf4075aA4WK7PCnYOtXCxV299cr9pCz7pxupmRW+lC70d9nTfuEhFzaSd
         7NlynGtSYqVAzZuUWxlqh55GJFp9rlhfcEYbQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736856832; x=1737461632;
        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=UVAvvLm1iFc6Iabd5RJ2uYFUbgoKPkWiZ/vM5RQWmc0=;
        b=e8KJ7pJsjMuhwb3h7QACKgPTKWeAx8h8w8vB6NFYbiPlCjRnkkgd/qQyYdSNzjxymv
         Kh4m+cbTaT6tOsOdmjHaqSe/YKBB5/acI7nk3dzj9e7gk8WYLgJ3eNF9RSZrw8zEISsF
         RxycwMpHsXozFLjPZk2SOZgrj1OFDmAhNcb4Y2eAUssHWaz4bViLfO/zjSDxUp45dsb+
         rjo5fOCimXmR039y0Za3Zr1NgukeSc5rb1iquluCklCFG7fF/5xwS5k/Tnlp9RzR0/tH
         RNsb88XqQOYpPIXnzCN7IxkEjETByqPMqwfhFvgWg9DynV4n45vBSQon2Br0rWadygO9
         ML3w==
X-Forwarded-Encrypted: i=1; AJvYcCUMPenzSQtU0fzmIIzBT1LObqnCqOTqDoUaMa26CQ5PRS7HAzKCAyFTglzncrpoTGZxX0JolKMHhLw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzyxbfrtAyIOENEWWcs5sQgQcCS9WqdPvm/ULrIBBnKX/fIrTkb
	KaKRgmKKRfMrxE6L3dx2PNpO6SaEijpOsuD3y+oTmSArrgAutdFzFp/VihhOMfk=
X-Gm-Gg: ASbGncvFid3WTig2rt3mQ6n50T5t+P74NCMA1z9t9iP3Hh9KJPm2PkOPNIezCXNg1uh
	3hdZ3t3Cu19aE5sC+4Q8uMremiZ7T6X9ndJQlybwek+FSHuOyBvpFqHubiABw/wpx79xtQMZ5v6
	1A+HZhWnXuza9VX6HJkYWZiT4aQbrXvVKhmK0VeEo5AtSMholXdCCbh7+2EOSFElNMCkAVnW/eP
	auUxN5IXZAn7rOIuMdhsoOq0B5jqveE2WbKCxDndFDb2pFHHo3mHQ0dmfKz5Q==
X-Google-Smtp-Source: AGHT+IE2RvQNuCq+nFgomferJhDxYHyouh4NfOPv3utVN7kuHiPpwL+KM8t6fS5Xoe/oRM4YsL65kw==
X-Received: by 2002:a17:907:9406:b0:aab:73c5:838 with SMTP id a640c23a62f3a-ab2ab710907mr1943819366b.29.1736856831821;
        Tue, 14 Jan 2025 04:13:51 -0800 (PST)
Date: Tue, 14 Jan 2025 13:13:50 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>,
	xen-devel@lists.xenproject.org,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v7 1/2] x86/time: introduce command line option to select
 wallclock
Message-ID: <Z4ZU_uvCe5lu0aMv@macbook.local>
References: <20240913075907.34460-1-roger.pau@citrix.com>
 <20240913075907.34460-2-roger.pau@citrix.com>
 <Z4U6WxtmaqGkqOqe@mail-itl>
 <Z4VS88REbzn5uasy@macbook.local>
 <49a2404f-0c45-4397-9094-a4189131832f@gmail.com>
 <Z4ZKINmJXw5T2dsM@macbook.local>
 <78e09ccb-65b7-4022-b9fc-7874e34c1a99@gmail.com>
 <9288f0de-945f-4056-9934-16b2b1704fb1@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <9288f0de-945f-4056-9934-16b2b1704fb1@gmail.com>

On Tue, Jan 14, 2025 at 12:44:39PM +0100, Oleksii Kurochko wrote:
> 
> On 1/14/25 12:40 PM, Oleksii Kurochko wrote:
> > 
> > 
> > On 1/14/25 12:27 PM, Roger Pau Monné wrote:
> > > On Tue, Jan 14, 2025 at 12:12:03PM +0100, Oleksii Kurochko wrote:
> > > > On 1/13/25 6:52 PM, Roger Pau Monné wrote:
> > > > > On Mon, Jan 13, 2025 at 05:07:55PM +0100, Marek Marczykowski-Górecki wrote:
> > > > > > On Fri, Sep 13, 2024 at 09:59:06AM +0200, Roger Pau Monne wrote:
> > > > > > > Allow setting the used wallclock from the command line.  When the option is set
> > > > > > > to a value different than `auto` the probing is bypassed and the selected
> > > > > > > implementation is used (as long as it's available).
> > > > > > > 
> > > > > > > The `xen` and `efi` options require being booted as a Xen guest (with Xen guest
> > > > > > > supported built-in) or from UEFI firmware respectively.
> > > > > > > 
> > > > > > > Signed-off-by: Roger Pau Monné<roger.pau@citrix.com>
> > > > > > Reviewed-by: Marek Marczykowski-Górecki<marmarek@invisiblethingslab.com>
> > > > > Thanks for the review.
> > > > > 
> > > > > Oleksii, can I get your opinion as Release Manager about whether this
> > > > > (and the following patch) would be suitable for committing to staging
> > > > > given the current release state?
> > > > > 
> > > > > It's a workaround for broken EFI implementations that many downstreams
> > > > > carry on their patch queue.
> > > > Based on your commit message, I understand this as addressing a bug ( but not very critical
> > > > as IIUC downstreams have the similar patch on their side ). Therefore, if it has been properly
> > > > reviewed and tested, we should consider including it in the current release.
> > > IIRC at least Qubes, XenServer and XCP-ng have a patch that achieves
> > > the same behavior as proposed here.
> > > 
> > > > IIUC, setting the wallclock to EFI should align with the behavior Xen had previously.
> > > > It might be preferable to use that argument as the default for a while, allowing others to verify the "auto"
> > > > value over time. After that, we could consider making "auto" the default.
> > > > That said, I am not particularly strict about following this approach.
> > > We cannot really set efi as the default, as it would break when
> > > booting on legacy BIOS systems.
> > > 
> > > We could take only patch 1 and leave patch 2 after Xen 4.20 has
> > > branched, but at that point I would see little benefit in having just
> > > patch 1.
> > I don't see a lot of benefit of comitting only the one patch either.
> > 
> > 
> > > I don't have a strong opinion, but downstreams have been complaining
> > > about Xen behavior regarding the usage of EFI_GET_TIME, so it might be
> > > good to not ship yet another release with such allegedly broken
> > > behavior.
> > Agree with that. As  I mentioned above I consider it as a bug and based on
> > that several mentioned above downstreams have the similar patch I could consider
> > that as tested approach so ..
> > > Let me know what you think, as I would need a formal Release-Ack if
> > > this is to be committed.
> > ... R-Acked-by: Oleksii Kurochko<oleksii.kurochko@gmail.com>.
> 
> Sorry for the noise.
> 
> I missed to add that it would also be nice to mention IMO ( that now we have wallclock parameter )
> in CHANGELOG so downstreams will receive "notification" that Xen provides a workaround for the mentioned
> issue in the patch series.

Indeed.  Would you be OK with adding the following chunk to patch 2?

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 8507e6556a56..1de1d1eca17f 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -12,6 +12,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
    leaving this to the guest kernel to do in guest context.
  - On x86:
    - Prefer ACPI reboot over UEFI ResetSystem() run time service call.
+   - Prefer CMOS over EFI_GET_TIME as time source.
    - Switched the xAPIC flat driver to use physical destination mode for external
      interrupts instead of logical destination mode.
 
@@ -24,6 +25,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
    - Support for LLC (Last Level Cache) coloring.
  - On x86:
    - xl suspend/resume subcommands.
+   - `wallclock` command line option to select time source.
 
 ### Removed
  - On x86:


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 13:10:32 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 13:10:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871319.1282340 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXggS-0007S7-HH; Tue, 14 Jan 2025 13:10:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871319.1282340; Tue, 14 Jan 2025 13:10:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXggS-0007S0-Dm; Tue, 14 Jan 2025 13:10:16 +0000
Received: by outflank-mailman (input) for mailman id 871319;
 Tue, 14 Jan 2025 13:10: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
 <SRS0=wcbX=UG=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tXggR-0007Ru-1e
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 13:10:15 +0000
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com
 [2a00:1450:4864:20::232])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e3665fa1-d278-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 14:10:12 +0100 (CET)
Received: by mail-lj1-x232.google.com with SMTP id
 38308e7fff4ca-304d757a9c1so50244901fa.0
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 05:10:12 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-305ff0fa064sm17709761fa.66.2025.01.14.05.10.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 14 Jan 2025 05:10:10 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e3665fa1-d278-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736860212; x=1737465012; darn=lists.xenproject.org;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=XCYk/FDIZ1PIGvnaue940QtDZOzM9d25xWtruLovZt4=;
        b=RY8gM4H4hV3ddeycboUQU/drcZl1HrXZxf0qvR9lczYg0lWPOlSkxQlCmcy8eVUN/M
         yev+jnYlAQxD1CLSIVEwSMM7aZFb5H6FmDe3rYklrmFRqDqHwKlEg1OnByblfPuHAQXh
         bG0RYxsFuhA5h6VHo6qIQoVWqrjF10sAO1xOxKTXa/xDfxXdTORkpG2fJLP06KJLl2kx
         CQLQSzN2ZQhxizQvvyJqXTIXLIh96OMJz30Syokb5rXL5phzNwZ73G1vk/BUQSl9B3pa
         ubkijvyJsWTiNKqCKqs9s318NSgbEk7vyQKhlRfLsPd5mFB4pYi5YXDw+Yu7VzoZ8ZeO
         oOow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736860212; x=1737465012;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=XCYk/FDIZ1PIGvnaue940QtDZOzM9d25xWtruLovZt4=;
        b=gg8NHdHCWfl6nqW8/ss7ZeyrxJv/3lLDgOx1SQWP38Q4K7idjKXurOafQLuIaoy8q6
         1HuHmeFvD5Q9NtCROkU51uKsy3bmm2l++CjtyQp28XAPm7gC4ulR/rloWjwRGfxXlLYI
         4eC6YWoxUryqtx75D3Gyh9VGDgTDQXwqay4klSGbBsFmGZBuIpn0ozE6+8hn3cThtYUA
         tqpYkc5/J3ygCOQNBu4wyaW12/cw0Z2C9VvoFNzUQEqLcznircsJHMjLghRQsy3P8VEj
         H0Btm7wcql5mltKeld1IDU/2t9iE1zdMohQDujALQarOSnwstTx8M8TSca+T3wMozN4l
         4y+A==
X-Forwarded-Encrypted: i=1; AJvYcCVnHYulnIMsliWgZ/oWwYm21GW0MkPuJLSHLCsPLsu3Lg25scHk49jjEDg+/UnSos/MuTGwZ1kPU1s=@lists.xenproject.org
X-Gm-Message-State: AOJu0YytbLYBiZ8aJaPvyEfRwRM1AL7ZCxdXtRa+J2jKNXFecJYi1TgZ
	7lMs7SsCYXt5P2EgxV+ITfEjGDPNkjxVynucZXhsqNMcbeiW4unO
X-Gm-Gg: ASbGncuamjxnqbh2TfXvW7wiekeOv624batIwWoV6pO1G/7rzk0i751ycz3RjbYYgdZ
	GxEl0BRlhUBau23CbQnfvWvo7O/jf9+hU7wRZyTh19yX3ms2t36vVWFO4eC8WTuHAHwDFFUrZiw
	7VdP3NAYBdJJtPX1NbFvdRbWCs01OznPvbdAM/C6uDaODlfMyy1h3HhBmWffCGalxS/mU0ymOhE
	pbaHsefdAeefQ8xrlgReAzSd2SnajtDm1C/mmpL23vuKJDW4KlIlRwMLW7YD5FYxXmxEQ==
X-Google-Smtp-Source: AGHT+IGJ9plYS4K6RRrzZyp7ubjYF7yB/j6PG35YTj/znwZQf7xq6Th3fGweNwIk2eVy1sgRSZZAkA==
X-Received: by 2002:a05:651c:4ca:b0:302:2097:392f with SMTP id 38308e7fff4ca-305fcfa3b96mr64728341fa.7.1736860210895;
        Tue, 14 Jan 2025 05:10:10 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------kP9can0595io0wr0tFwwwTop"
Message-ID: <1c1307a2-9c62-4103-bf91-a587664e764a@gmail.com>
Date: Tue, 14 Jan 2025 14:10:09 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for 4.21 v1 1/1] xen/riscv: identify specific ISA
 supported by cpu
To: Jan Beulich <jbeulich@suse.com>
Cc: Alistair Francis <alistair.francis@wdc.com>,
 Bob Eshleman <bobbyeshleman@gmail.com>, Connor Davis
 <connojdavis@gmail.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1734957957.git.oleksii.kurochko@gmail.com>
 <ee14c485c6c6402a2d1706278b21bf3fcf821af9.1734957957.git.oleksii.kurochko@gmail.com>
 <bc636259-5586-428c-8a57-f97ba16a14b8@suse.com>
 <255b0079-4516-404c-81c1-a49e6f7bf5b4@gmail.com>
 <7cf45091-bf3f-4497-a6e2-72571d7e745e@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <7cf45091-bf3f-4497-a6e2-72571d7e745e@suse.com>

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


On 1/14/25 8:33 AM, Jan Beulich wrote:
>>>> +    RISCV_ISA_EXT_DATA(i, RISCV_ISA_EXT_i),
>>>> +    RISCV_ISA_EXT_DATA(m, RISCV_ISA_EXT_m),
>>>> +    RISCV_ISA_EXT_DATA(a, RISCV_ISA_EXT_a),
>>>> +    RISCV_ISA_EXT_DATA(f, RISCV_ISA_EXT_f),
>>>> +    RISCV_ISA_EXT_DATA(d, RISCV_ISA_EXT_d),
>>>> +    RISCV_ISA_EXT_DATA(q, RISCV_ISA_EXT_q),
>>>> +    RISCV_ISA_EXT_DATA(h, RISCV_ISA_EXT_h),
>>>> +    RISCV_ISA_EXT_DATA(zicntr, RISCV_ISA_EXT_ZICNTR),
>>>> +    RISCV_ISA_EXT_DATA(zicsr, RISCV_ISA_EXT_ZICSR),
>>>> +    RISCV_ISA_EXT_DATA(zifencei, RISCV_ISA_EXT_ZIFENCEI),
>>>> +    RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE),
>>>> +    RISCV_ISA_EXT_DATA(zihpm, RISCV_ISA_EXT_ZIHPM),
>>>> +    RISCV_ISA_EXT_DATA(zbb, RISCV_ISA_EXT_ZBB),
>>> Isn't it kind of implied that with the presence of Zbb, B should also be
>>> present?
>> My interpretation of the RISC-V Bitmanip Extension spec is that the 'B' extension is essentially a collection of
>> the Zba, Zbb, Zbs, and other extensions, but it isn't an extension by itself.
>> The following is mentioned in the spec:
>>     The bit-manipulation (bitmanip) extension collection is comprised of several component extensions to the base
>>     RISC-V architecture that are intended to provide some combination of code size reduction, performance
>>     improvement, and energy reduction. While the instructions are intended to have general use, some instructions
>>     are more useful in some domains than others. Hence, several smaller bitmanip extensions are provided, rather
>>     than one large extension. Each of these smaller extensions is grouped by common function and use case, and
>>     each of which has its own Zb*-extension name.
> Still the doc has '"B" Extension for Bit Manipulation' as the title of the
> chapter.
> And gas accepts B as an extension (e.g. ".option arch, +b").

I think it is fine.
B, in this case, just represents Zba, Zbb, Zbc, Zbs and that all of them are supported at the same time.
But I see chips that doesn't have B because it doesn't have one of those extensions.

>
>>>> +            /*
>>>> +             * Workaround for invalid single-letter 's' & 'u' (QEMU).
>>>> +             * No need to set the bit in riscv_isa as 's' & 'u' are
>>>> +             * not valid ISA extensions. It works unless the first
>>>> +             * multi-letter extension in the ISA string begins with
>>>> +             * "Su" and is not prefixed with an underscore.
>>>> +             */
>>>> +            if ( ext[-1] != '_' && ext[1] == 'u' )
>>>> +            {
>>>> +                ++isa;
>>>> +                ext_err = true;
>>>> +                break;
>>>> +            }
>>> I'm afraid I don't understand this; the comment raises more questions
>>> than it answers.
>> Some details could be found here about these QEMU workaround from LK view:
>> https://lore.kernel.org/linux-riscv/ae93358e-e117-b43d-faad-772c529f846c@irq.a4lg.com/#t
>>
>> This leads to the following fix in QEMU:
>> https://patchwork.kernel.org/project/qemu-devel/patch/dee09d708405075420b29115c1e9e87910b8da55.1648270894.git.research_trasio@irq.a4lg.com/#24792587
>>
>> Considering QEMU's patch, these workaround isn't needed anymore since QEMU 7.1 ( it has been released30 Aug 2022 ) probably we could update the
>> QEMU version on our CI and just drop these changes.
>> Or, at least, update the comment with the links mentioned above and add a message that these changes are needed only for QEMU < 7.1.
>> Am I right that we don't have something like GCC_VERSION in Xen but for QEMU?
> How could there be? At the time of building Xen we know what compiler
> version is in use, but we clearly don't know under what qemu versions
> it might later be run.

Agree with that, there is no any sense for having something similar as GCC_VERSIOB but
for QEMU. Then I will just update the comment around this workaround with some clarifications.

>
>>>> +        riscv_isa_parse_string(isa, this_isa);
>>>> +
>>>> +        if ( bitmap_empty(riscv_isa, RISCV_ISA_EXT_MAX) )
>>>> +            bitmap_copy(riscv_isa, this_isa, RISCV_ISA_EXT_MAX);
>>>> +        else
>>>> +            bitmap_and(riscv_isa, riscv_isa, this_isa, RISCV_ISA_EXT_MAX);
>>> What if the first instance had no extensions at all? You'll then copy what
>>> the second instance say, ending up with extensions not supported by one of
>>> the CPUs.
>> I think that it's impossible that there is no extensions at all and it should be
>> considered as a bug of provided riscv,isa property. Thereby it should be enough to
>> add BUG_ON(!bitmap_empty(this_isa, RISCV_ISA_EXT_MAX)) before if-condition.
> Well, you can of course make such an assumption. I don't think though that
> it's technically impossible to have an extension-less environment. Xen
> won't be able to run there, though (we'll require H at the very least aiui,
> and I'm sure we really also require Zicsr).

I would like to clarify some things. I think we are counting by word 'extension' different things.
I am including to this `Base ISA` ( and likely it is incorrect to do so ( or,at least, confusing )
and I will try not to do that in the future. I am using it in this manner because `Base ISA` is
included to the table 74. Standard ISA extension names in Unpriv spec ) then it is impossible to
have an extension-less environment because the spec mentions the following:

     A RISC-V ISA is defined as a base integer ISA, which must be present in any implementation, plus
     optional extensions to the base ISA.

So, at least, r{32,64,128}i should written in riscv,isa property of DTS file and that is the reason why
this_isa can't be empty, and thereby riscv_isa will be initialized with, at least, `i` ending up with only `i`
supported by all CPUs.

But if not count `I` as an extension and just as base ISA then it is really technically possible to come up with
extension-less environment. But anyway as you mentioned we still need for Xen some extensions. ( btw, thanks, I missed to
add Zicsr to required_extensions[] ).

Thanks.

~ Oleksii

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

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 1/14/25 8:33 AM, Jan Beulich wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:7cf45091-bf3f-4497-a6e2-72571d7e745e@suse.com">
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="" class="moz-quote-pre">+    RISCV_ISA_EXT_DATA(i, RISCV_ISA_EXT_i),
+    RISCV_ISA_EXT_DATA(m, RISCV_ISA_EXT_m),
+    RISCV_ISA_EXT_DATA(a, RISCV_ISA_EXT_a),
+    RISCV_ISA_EXT_DATA(f, RISCV_ISA_EXT_f),
+    RISCV_ISA_EXT_DATA(d, RISCV_ISA_EXT_d),
+    RISCV_ISA_EXT_DATA(q, RISCV_ISA_EXT_q),
+    RISCV_ISA_EXT_DATA(h, RISCV_ISA_EXT_h),
+    RISCV_ISA_EXT_DATA(zicntr, RISCV_ISA_EXT_ZICNTR),
+    RISCV_ISA_EXT_DATA(zicsr, RISCV_ISA_EXT_ZICSR),
+    RISCV_ISA_EXT_DATA(zifencei, RISCV_ISA_EXT_ZIFENCEI),
+    RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE),
+    RISCV_ISA_EXT_DATA(zihpm, RISCV_ISA_EXT_ZIHPM),
+    RISCV_ISA_EXT_DATA(zbb, RISCV_ISA_EXT_ZBB),
</pre>
          </blockquote>
          <pre wrap="" class="moz-quote-pre">Isn't it kind of implied that with the presence of Zbb, B should also be
present?
</pre>
        </blockquote>
        <pre wrap="" class="moz-quote-pre">
My interpretation of the RISC-V Bitmanip Extension spec is that the 'B' extension is essentially a collection of
the Zba, Zbb, Zbs, and other extensions, but it isn't an extension by itself.
The following is mentioned in the spec:
   The bit-manipulation (bitmanip) extension collection is comprised of several component extensions to the base
   RISC-V architecture that are intended to provide some combination of code size reduction, performance
   improvement, and energy reduction. While the instructions are intended to have general use, some instructions
   are more useful in some domains than others. Hence, several smaller bitmanip extensions are provided, rather
   than one large extension. Each of these smaller extensions is grouped by common function and use case, and
   each of which has its own Zb*-extension name.
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
Still the doc has '"B" Extension for Bit Manipulation' as the title of the
chapter. </pre>
    </blockquote>
    <blockquote type="cite"
      cite="mid:7cf45091-bf3f-4497-a6e2-72571d7e745e@suse.com">
      <pre wrap="" class="moz-quote-pre">And gas accepts B as an extension (e.g. ".option arch, +b").</pre>
    </blockquote>
    <pre>I think it is fine.
B, in this case, just represents Zba, Zbb, Zbc, Zbs and that all of them are supported at the same time.
But I see chips that doesn't have B because it doesn't have one of those extensions.</pre>
    <blockquote type="cite"
      cite="mid:7cf45091-bf3f-4497-a6e2-72571d7e745e@suse.com">
      <pre wrap="" class="moz-quote-pre">

</pre>
    </blockquote>
    <blockquote type="cite"
      cite="mid:7cf45091-bf3f-4497-a6e2-72571d7e745e@suse.com">
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="" class="moz-quote-pre">+            /*
+             * Workaround for invalid single-letter 's' &amp; 'u' (QEMU).
+             * No need to set the bit in riscv_isa as 's' &amp; 'u' are
+             * not valid ISA extensions. It works unless the first
+             * multi-letter extension in the ISA string begins with
+             * "Su" and is not prefixed with an underscore.
+             */
+            if ( ext[-1] != '_' &amp;&amp; ext[1] == 'u' )
+            {
+                ++isa;
+                ext_err = true;
+                break;
+            }
</pre>
          </blockquote>
          <pre wrap="" class="moz-quote-pre">I'm afraid I don't understand this; the comment raises more questions
than it answers.
</pre>
        </blockquote>
        <pre wrap="" class="moz-quote-pre">
Some details could be found here about these QEMU workaround from LK view:
<a class="moz-txt-link-freetext" href="https://lore.kernel.org/linux-riscv/ae93358e-e117-b43d-faad-772c529f846c@irq.a4lg.com/#t">https://lore.kernel.org/linux-riscv/ae93358e-e117-b43d-faad-772c529f846c@irq.a4lg.com/#t</a>

This leads to the following fix in QEMU:
<a class="moz-txt-link-freetext" href="https://patchwork.kernel.org/project/qemu-devel/patch/dee09d708405075420b29115c1e9e87910b8da55.1648270894.git.research_trasio@irq.a4lg.com/#24792587">https://patchwork.kernel.org/project/qemu-devel/patch/dee09d708405075420b29115c1e9e87910b8da55.1648270894.git.research_trasio@irq.a4lg.com/#24792587</a>

Considering QEMU's patch, these workaround isn't needed anymore since QEMU 7.1 ( it has been released30 Aug 2022 ) probably we could update the
QEMU version on our CI and just drop these changes.
Or, at least, update the comment with the links mentioned above and add a message that these changes are needed only for QEMU &lt; 7.1.
Am I right that we don't have something like GCC_VERSION in Xen but for QEMU?
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
How could there be? At the time of building Xen we know what compiler
version is in use, but we clearly don't know under what qemu versions
it might later be run.</pre>
    </blockquote>
    <pre>Agree with that, there is no any sense for having something similar as GCC_VERSIOB but
for QEMU. Then I will just update the comment around this workaround with some clarifications.</pre>
    <blockquote type="cite"
      cite="mid:7cf45091-bf3f-4497-a6e2-72571d7e745e@suse.com">
      <pre wrap="" class="moz-quote-pre">

</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="" class="moz-quote-pre">+        riscv_isa_parse_string(isa, this_isa);
+
+        if ( bitmap_empty(riscv_isa, RISCV_ISA_EXT_MAX) )
+            bitmap_copy(riscv_isa, this_isa, RISCV_ISA_EXT_MAX);
+        else
+            bitmap_and(riscv_isa, riscv_isa, this_isa, RISCV_ISA_EXT_MAX);
</pre>
          </blockquote>
          <pre wrap="" class="moz-quote-pre">What if the first instance had no extensions at all? You'll then copy what
the second instance say, ending up with extensions not supported by one of
the CPUs.
</pre>
        </blockquote>
        <pre wrap="" class="moz-quote-pre">
I think that it's impossible that there is no extensions at all and it should be
considered as a bug of provided riscv,isa property. Thereby it should be enough to
add BUG_ON(!bitmap_empty(this_isa, RISCV_ISA_EXT_MAX)) before if-condition.
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
Well, you can of course make such an assumption. I don't think though that
it's technically impossible to have an extension-less environment. Xen
won't be able to run there, though (we'll require H at the very least aiui,
and I'm sure we really also require Zicsr).</pre>
    </blockquote>
    <pre>I would like to clarify some things. I think we are counting by word 'extension' different things.
I am including to this `Base ISA` ( and likely it is incorrect to do so ( or,at least, confusing )
and I will try not to do that in the future. I am using it in this manner because `Base ISA` is
included to the table 74. Standard ISA extension names in Unpriv spec ) then it is impossible to
have an extension-less environment because the spec mentions the following:</pre>
    <pre>    A RISC-V ISA is defined as a base integer ISA, which must be present in any implementation, plus
    optional extensions to the base ISA.

So, at least, r{32,64,128}i should written in riscv,isa property of DTS file and that is the reason why
this_isa can't be empty, and thereby riscv_isa will be initialized with, at least, `i` ending up with only `i`
supported by all CPUs.

But if not count `I` as an extension and just as base ISA then it is really technically possible to come up with
extension-less environment. But anyway as you mentioned we still need for Xen some extensions. ( btw, thanks, I missed to
add Zicsr to required_extensions[] ).

Thanks.

~ Oleksii
</pre>
  </body>
</html>

--------------kP9can0595io0wr0tFwwwTop--


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 13:22:16 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 13:22:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871329.1282350 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXgrz-0000zC-HQ; Tue, 14 Jan 2025 13:22:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871329.1282350; Tue, 14 Jan 2025 13:22:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXgrz-0000z5-EN; Tue, 14 Jan 2025 13:22:11 +0000
Received: by outflank-mailman (input) for mailman id 871329;
 Tue, 14 Jan 2025 13:22:10 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/Vp6=UG=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tXgry-0000yz-1Z
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 13:22:10 +0000
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com
 [2a00:1450:4864:20::32a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8e1bdc9b-d27a-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 14:22:08 +0100 (CET)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-4361b6f9faeso33773715e9.1
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 05:22: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
 ffacd0b85a97d-38a8e4b8116sm14728363f8f.79.2025.01.14.05.22.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 14 Jan 2025 05:22:07 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8e1bdc9b-d27a-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736860928; x=1737465728; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=eY2/uzli6cNLqo6ObQz+GqU946E5SzXqhujARKegLUg=;
        b=I/FaTU+7SM7riW/t+TJRDDo2U+WAh9+fAVXveu9Uj36qkt0JfP6h9JNi4I2P8Wl/U6
         ens0v7z4T8gENdivcdFeQBpMoxcGkx1er5erjCu/MsS7vqr7ZEgg8eQXgbIZbiU+8NCj
         n1vgQqex3owomq20BfdUZPVNmZYf7eLyZdDJ3CT7czJxpkl+gx1Scr9EHH7/Akm8SAYl
         e49O93XErCHzeTHTyNSNDj2wQsNtQwPfu3S+FjTidnJuyU/EDZu6dBy5fKJGJMqEvxKl
         eLPv+Q5T5UODr+7+KljJCv6igdbjITxJNNflbgSyD1I7zPZWR9ilAJ6PPg2fNN0p/YlC
         TJ4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736860928; x=1737465728;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=eY2/uzli6cNLqo6ObQz+GqU946E5SzXqhujARKegLUg=;
        b=UhXLkhD8ZgZ0LSo5G27IIhlN/MqLavq4EWBO/UOH2w+IhrmskkM4TNjELFDX5nszcp
         zP3b94gOJq/go7qCx9/TYAiIh4bBvF8pqYA0h3C3AJmTuODSPTQscnOMM4e5PpZJBMXm
         uqP8R+gO9B5iYZPV/0fQ0mX+8O/XyqbHRg4tgFOvJFWL3z/bDKmW4mgdy9bjiN3zR+SD
         JrBcCZu8eQy42ArpwpI2fbQR8MfeCJWWjnjpaIeg0u5S42i4FU0cqP0bLgoILa6beOwn
         4q3VgGzaeaWBJzEtfk6+cL2fxT7VGfWMxtRCqLcg85q+heC7UvF4Gqa7JfLRF2zDB6sz
         6ypw==
X-Forwarded-Encrypted: i=1; AJvYcCVlL4peV/QKGbsfTjpSofaUoh4/xqPUnK5lTFOSrJeAqnp68crKvwsx1axY0n2FSxFC6RcS63WphkA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxuiquKTIHBask2EmLMwSBfAAaEUUg/gKzkgPj14yWVSIDno83Q
	5lSnslFfM1/WomsRI5MU+Fsq0zkvOzLZHJXlKiaBOKJ5zxx3sG3J0P/KHjHQKw==
X-Gm-Gg: ASbGncvCigUuy9akjRYahoy9PyOQTAYjVCGXQoaUY6JzV8zzxJGnEVfX2Lg/pv3MxO7
	JQ7yJUcnrySXNmYr/o+qGR0M59CKmX5l2DYv+iA2zwhjyKcmkv8ZgJUCdxCC/nA/IWjZu7vrI4e
	rLCR707+HYoo3vEoGvltXQiOe55HZe2lkQI1UA8ABD8z5oK2xQtDrJieokT6kk1rReL8BpL+CBy
	5OhtI+PCT9tZdhBEE1m3KDxX9oGw+iOqwhqv0ieL0tc0OUtmZrvw9Jj+Xno8Dm+zb5sVAkGPP83
	MX6X5qcF1abs+EuYRAM8kYKOD3Tg3vlDvjDLyKZXtA==
X-Google-Smtp-Source: AGHT+IFHi/5gAPn9GwxTdtWtJEyzJAy0tizls8+BEPIMdQpu2UIo1PWdS0YPJjccQTEF+tD9T4N/Bw==
X-Received: by 2002:a05:600c:5028:b0:434:fa73:a906 with SMTP id 5b1f17b1804b1-436e9d6fe9emr168224015e9.4.1736860927898;
        Tue, 14 Jan 2025 05:22:07 -0800 (PST)
Message-ID: <c8ed49b1-ffa3-4a40-a006-ee6e01b64367@suse.com>
Date: Tue, 14 Jan 2025 14:22:06 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 0/3] Add stack protector
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Julien Grall <julien@xen.org>, Stefano Stabellini
 <sstabellini@kernel.org>, Anthony PERARD <anthony.perard@vates.tech>,
 Samuel Thibault <samuel.thibault@ens-lyon.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
References: <20241211020424.401614-1-volodymyr_babchuk@epam.com>
 <f1e86e0e-985a-41ae-a94c-979288275257@suse.com> <87pllx3gib.fsf@epam.com>
 <fd9ea545-0eb1-4803-9d1e-df15c5805fa3@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <fd9ea545-0eb1-4803-9d1e-df15c5805fa3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 12.12.2024 02:17, Andrew Cooper wrote:
> On 12/12/2024 12:13 am, Volodymyr Babchuk wrote:
>> Hello Jan,
>>
>> Jan Beulich <jbeulich@suse.com> writes:
>>
>>> On 11.12.2024 03:04, Volodymyr Babchuk wrote:
>>>> Both GCC and Clang support -fstack-protector feature, which add stack
>>>> canaries to functions where stack corruption is possible. This series
>>>> makes possible to use this feature in Xen. I tested this on ARM64 and
>>>> it is working as intended. Tested both with GCC and Clang.
>>>>
>>>> It is hard to enable this feature on x86, as GCC stores stack canary
>>>> in %fs:40 by default, but Xen can't use %fs for various reasons. It is
>>>> possibly to change stack canary location new newer GCC versions, but
>>>> this will change minimal GCC requirement, which is also hard due to
>>>> various reasons. So, this series focus mostly on ARM and RISCV.
>>> Why exactly would it not be possible to offer the feature when new enough
>>> gcc is in use?
>> It is possible to use this feature with a modern enough GCC, yes. Are
>> you suggesting to make HAS_STACK_PROTECTOR dependent on GCC_VERSION for
>> x86 platform?
> 
> (With the knowledge that this is a disputed Kconfig pattern, and will
> need rebasing), the way I want this to work is simply:
> 
> diff --git a/xen/Makefile b/xen/Makefile
> index 0de0101fd0bf..5d0a88fb3c3f 100644
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -434,6 +434,9 @@ endif
>  
>  ifeq ($(CONFIG_STACK_PROTECTOR),y)
>  CFLAGS += -fstack-protector
> +ifeq ($(CONFIG_X86),y)
> +CFLAGS += -mstack-protector-guard=global
> +endif
>  else
>  CFLAGS += -fno-stack-protector
>  endif
> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
> index 9cdd04721afa..7951ca908b36 100644
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -28,6 +28,7 @@ config X86
>         select HAS_PCI_MSI
>         select HAS_PIRQ
>         select HAS_SCHED_GRANULARITY
> +       select HAS_STACK_PROTECTOR if
> $(cc-option,-mstack-protector-guard=global)
>         select HAS_UBSAN
>         select HAS_VMAP
>         select HAS_VPCI if HVM
> 
> 
> 
> Sadly, it doesn't build.  I get a handful of:
> 
> prelink.o: in function `cmdline_parse':
> /home/andrew/xen.git/xen/common/kernel.c:216:(.init.text+0x20f2): failed
> to convert GOTPCREL relocation against '__stack_chk_guard'; relink with
> --no-relax
> /home/andrew/xen.git/xen/common/kernel.c:230:(.init.text+0x246f): failed
> to convert GOTPCREL relocation against '__stack_chk_guard'; relink with
> --no-relax
> 
> which is more toolchain-whispering than I feel like doing tonight.

For reference:
https://sourceware.org/pipermail/binutils/2025-January/138631.html

You didn't enter a gcc bug report yet, did you?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 13:28:26 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 13:28:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871341.1282359 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXgxv-0001dG-BF; Tue, 14 Jan 2025 13:28:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871341.1282359; Tue, 14 Jan 2025 13:28:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXgxv-0001d9-8L; Tue, 14 Jan 2025 13:28:19 +0000
Received: by outflank-mailman (input) for mailman id 871341;
 Tue, 14 Jan 2025 13:28: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
 <SRS0=tIyo=UG=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tXgxu-0001d3-MQ
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 13:28:18 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 69a22987-d27b-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 14:28:17 +0100 (CET)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-aaf60d85238so1008750666b.0
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 05:28:17 -0800 (PST)
Received: from [10.81.35.177] ([46.149.103.15])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c90dc570sm641574866b.51.2025.01.14.05.28.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 14 Jan 2025 05:28:14 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 69a22987-d27b-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736861296; x=1737466096; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=TdGSJ3nvs9AExuCaeWP4D+eIKVCjs6NC8KhswNZjixo=;
        b=PUZS1qW/CXZNECCpb3DLKFQta1U4M8JDGFlsauekIilG3VcN90q76DSGMq7Esctuwg
         z1dImelM6820ynBeMS/DpYhDKFlh9caVlP9BP2GaNwd04mQx4LGJLbRn7Pvw+ngHZt6L
         zj8skvpFyRFIVZxyE4VmEDbZ9e++uv2ATBsNk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736861296; x=1737466096;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=TdGSJ3nvs9AExuCaeWP4D+eIKVCjs6NC8KhswNZjixo=;
        b=mBSSTc2LYF6FW315VEmTezu88a2syLLk/D7vnVd0z/bFHU+t9HfuBFMfKkSuPaWOjH
         LWou/FQBxDNjjxY2qpL5iW+IUab0MS131c0pFBR1wbMlHQzGmNwwD2S+lfVB9hliOFQJ
         cyOnotJRcyd5hV76Od3AX9RkHOa4YPAc4iO6HbOyDWN9MWjF2XPVp+L5ixdtXnc5ZkW3
         wxYywfQz96hx4fbmuXQ6DjOqyfEp4NMIKaKYQbAAXBTGsO3C8lJOKKUwYx2BfN+sEWlb
         pYtmvDAuOIJ9lWwSWcXOeuTDYxOstnvc5nXe8bWY33SAC75m6Lqnr0KN5gEwum1DKYIN
         XGRg==
X-Forwarded-Encrypted: i=1; AJvYcCXnxe5eoGUxmn5zQ9WI6VZLpLKiUSxKaGfPIs9o/scz3ZVWEbtkA1RduTKvHgbLeoK0T8Q4czuXNes=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzgGBQfKbJ3/xAVK3hg/z3UwzSicZTR7yQ/202djRIWTMnFX72V
	weV02eY9JRrCgBEB0pe4sZT+apBtNZGLZOC/fPv35vyawVNKgPQ2NzTfw+WZTiQ=
X-Gm-Gg: ASbGnctnsrItqGmps+6ujuBGOfV6oM7oJU7gFNfM8+bZ43Z38MUkBiNmT8Ka7IOW9pK
	dajkNp8GNsplqmXtALvSVkdQJWTeE5qjMFaPyEXZY/O/fI2fBMW70fCj+4xqewl6KgJfzicHoGg
	tcp368T/WsvzaJvOTD145PXTyIyP1jpL7stKn0jo86xwZCMzOd8qc+Y4Qzkrc0SdVVo2ewbZeiM
	5xW+I5Nlxcu7V+XjNRcN7aClPvV/yKnHU+PfMXbQGMGvUvv5TujrrFtUBA9m6rcI3o=
X-Google-Smtp-Source: AGHT+IHblNCyJzcVr+qSmb8sUGK7d68ZO4vSBf1AQReLWYJ1HjnoH/e8eyDT72HOnmJFMDwP8L5FoQ==
X-Received: by 2002:a17:907:368c:b0:aa6:9624:78fd with SMTP id a640c23a62f3a-ab2abc78a71mr2476651466b.48.1736861294638;
        Tue, 14 Jan 2025 05:28:14 -0800 (PST)
Message-ID: <1622f144-e872-4e3c-8522-2e692f63e8eb@citrix.com>
Date: Tue, 14 Jan 2025 13:28:08 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 0/3] Add stack protector
To: Jan Beulich <jbeulich@suse.com>
Cc: Julien Grall <julien@xen.org>, Stefano Stabellini
 <sstabellini@kernel.org>, Anthony PERARD <anthony.perard@vates.tech>,
 Samuel Thibault <samuel.thibault@ens-lyon.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
References: <20241211020424.401614-1-volodymyr_babchuk@epam.com>
 <f1e86e0e-985a-41ae-a94c-979288275257@suse.com> <87pllx3gib.fsf@epam.com>
 <fd9ea545-0eb1-4803-9d1e-df15c5805fa3@citrix.com>
 <c8ed49b1-ffa3-4a40-a006-ee6e01b64367@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <c8ed49b1-ffa3-4a40-a006-ee6e01b64367@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 14/01/2025 1:22 pm, Jan Beulich wrote:
> On 12.12.2024 02:17, Andrew Cooper wrote:
>> On 12/12/2024 12:13 am, Volodymyr Babchuk wrote:
>>> Hello Jan,
>>>
>>> Jan Beulich <jbeulich@suse.com> writes:
>>>
>>>> On 11.12.2024 03:04, Volodymyr Babchuk wrote:
>>>>> Both GCC and Clang support -fstack-protector feature, which add stack
>>>>> canaries to functions where stack corruption is possible. This series
>>>>> makes possible to use this feature in Xen. I tested this on ARM64 and
>>>>> it is working as intended. Tested both with GCC and Clang.
>>>>>
>>>>> It is hard to enable this feature on x86, as GCC stores stack canary
>>>>> in %fs:40 by default, but Xen can't use %fs for various reasons. It is
>>>>> possibly to change stack canary location new newer GCC versions, but
>>>>> this will change minimal GCC requirement, which is also hard due to
>>>>> various reasons. So, this series focus mostly on ARM and RISCV.
>>>> Why exactly would it not be possible to offer the feature when new enough
>>>> gcc is in use?
>>> It is possible to use this feature with a modern enough GCC, yes. Are
>>> you suggesting to make HAS_STACK_PROTECTOR dependent on GCC_VERSION for
>>> x86 platform?
>> (With the knowledge that this is a disputed Kconfig pattern, and will
>> need rebasing), the way I want this to work is simply:
>>
>> diff --git a/xen/Makefile b/xen/Makefile
>> index 0de0101fd0bf..5d0a88fb3c3f 100644
>> --- a/xen/Makefile
>> +++ b/xen/Makefile
>> @@ -434,6 +434,9 @@ endif
>>  
>>  ifeq ($(CONFIG_STACK_PROTECTOR),y)
>>  CFLAGS += -fstack-protector
>> +ifeq ($(CONFIG_X86),y)
>> +CFLAGS += -mstack-protector-guard=global
>> +endif
>>  else
>>  CFLAGS += -fno-stack-protector
>>  endif
>> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
>> index 9cdd04721afa..7951ca908b36 100644
>> --- a/xen/arch/x86/Kconfig
>> +++ b/xen/arch/x86/Kconfig
>> @@ -28,6 +28,7 @@ config X86
>>         select HAS_PCI_MSI
>>         select HAS_PIRQ
>>         select HAS_SCHED_GRANULARITY
>> +       select HAS_STACK_PROTECTOR if
>> $(cc-option,-mstack-protector-guard=global)
>>         select HAS_UBSAN
>>         select HAS_VMAP
>>         select HAS_VPCI if HVM
>>
>>
>>
>> Sadly, it doesn't build.  I get a handful of:
>>
>> prelink.o: in function `cmdline_parse':
>> /home/andrew/xen.git/xen/common/kernel.c:216:(.init.text+0x20f2): failed
>> to convert GOTPCREL relocation against '__stack_chk_guard'; relink with
>> --no-relax
>> /home/andrew/xen.git/xen/common/kernel.c:230:(.init.text+0x246f): failed
>> to convert GOTPCREL relocation against '__stack_chk_guard'; relink with
>> --no-relax
>>
>> which is more toolchain-whispering than I feel like doing tonight.
> For reference:
> https://sourceware.org/pipermail/binutils/2025-January/138631.html
>
> You didn't enter a gcc bug report yet, did you?

No, not yet.  I'm afraid I've not had the time.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 13:29:16 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 13:29:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871349.1282371 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXgyq-00029D-LN; Tue, 14 Jan 2025 13:29:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871349.1282371; Tue, 14 Jan 2025 13:29:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXgyq-000296-Gr; Tue, 14 Jan 2025 13:29:16 +0000
Received: by outflank-mailman (input) for mailman id 871349;
 Tue, 14 Jan 2025 13:29: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 <SRS0=/Vp6=UG=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tXgyp-000266-MT
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 13:29:15 +0000
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com
 [2a00:1450:4864:20::336])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8bc51aed-d27b-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 14:29:14 +0100 (CET)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-436249df846so37952785e9.3
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 05:29:14 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436e9d8fc67sm177401795e9.8.2025.01.14.05.29.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 14 Jan 2025 05:29:13 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8bc51aed-d27b-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736861353; x=1737466153; darn=lists.xenproject.org;
        h=content-transfer-encoding:autocrypt:content-language:cc:to:subject
         :from:user-agent:mime-version:date:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=Pe4VQOgveIX4YHbU5WTRdB4IC8dE1/l1IYjxf4I6CWs=;
        b=TM7FGRiwYETHUhF4OZfp8wTyLwvCJP4mcZ6zydtxzv74vfyP1nelz3x8z8CVLAhqHj
         Wa/AQQOiVtsJBZeCjuyG45vrldPyp3Mto68hbClb5icNrm8DsAFiJ3OIuAG9+/mxfmA1
         tIPqng/sKwSAXnlRS3rYt76xZmDn1OyPWQJpEMWIQXALvD0y9oXwaTBxrDTUI8jxQkzS
         EgVP7GBdmUs7/Fe6F5P4NZZBuVuxRLS4x6aWuXFOUcBjLOhQvcvJp9uYI9zKsqvkHOpX
         d8d/NBnanAgdHS9hJlNkSnw1c2oH07CGdIkpp2gvfJzwOiuGxngDEYsngquK7+9D41ch
         MrHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736861353; x=1737466153;
        h=content-transfer-encoding:autocrypt:content-language:cc:to:subject
         :from:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=Pe4VQOgveIX4YHbU5WTRdB4IC8dE1/l1IYjxf4I6CWs=;
        b=Y+M6ngymWIe7zL2brvshTvay+jZ5oQxeTY6FdSIll1HIPBqvbdp+0nKv3Og+sTo9yv
         xEBmONZ4V5TKjvxu/KFlTFbYEBk1hY6vS6vASQDZ7t3iR3+Szv3tMAyGZtBDQwJr3TjV
         drAymiaiy2osCjaPewvfq63KE8WryBuAHE3KGoCbqak1o779FViXrwbIhFhysMXzOjOi
         /sMvUCGkVEw88QDDpHHRtN7IVMOyIkoL0WQ8PE7D+X2vRULBnnY5QG3/709UY9c0jTeH
         J2pGq4KcUjyE2ENO2EBLTCg9ncd/jQObSPnRf/1RvQM/muHXYPnBuvsCKjnNvS9S+NCr
         FVWg==
X-Gm-Message-State: AOJu0Yw28oE0DoB19/Ag7W9KX5k7GQiL3aO6QuHTcrYKscOXi2s7WuRh
	3KBZuFbBtCY7ioFJdYyF/6R2wlcpycY5eEG2VqSKgl9UoCGb6jVu//B6hUP6dsq3w1arMj+CEf8
	=
X-Gm-Gg: ASbGncturTaI+D/JRSPBc0AdyjjPYRdwINA74koe0P7CXy1BCGSd0RlIzmO+hUyKzMA
	voKSz9ExceIDDdKlNC3uSPXwYNDXVBGrMYXf7QtH9rOhBml06nFx96Lp87+oSI/mnhWm+iQDndd
	UNSfC1yeq+a0TIiY+OTN37zDKCnriFL3iZQa7WtPodCo7qR1cwu4JluSU9+IEjSM1wqdbOJx20e
	ARpnFTE+IVB5aDxdJFBQLgGSBVFJCLT/4ePUiTZMD6jVE+3ET33x8hXJb0FVmI4imdBAFGBbpCq
	KTasNX0kqWb8aSXGIiBSRxgT8qC87bJBuPMhiKtwNA==
X-Google-Smtp-Source: AGHT+IEyAmgL/Yj6E9y7uylZ4geMqW3DfcOVDcZkLoO7C4L2BwUTprk5Be9QSoyNhp0uT1N4V9zQVQ==
X-Received: by 2002:a05:600c:468f:b0:431:52f5:f48d with SMTP id 5b1f17b1804b1-436e26ebe46mr232191055e9.31.1736861353542;
        Tue, 14 Jan 2025 05:29:13 -0800 (PST)
Message-ID: <4460f13b-03bc-4ca0-aa97-facde3122be4@suse.com>
Date: Tue, 14 Jan 2025 14:29:12 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH v2] xl: properly dispose of libxl_dominfo struct instances
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

The ssid_label field requires separate freeing; make sure to call
libxl_dominfo_dispose() as well as libxl_dominfo_init(). Since vcpuset()
calls only the former, add a call to the latter there at the same time.

Coverity-ID: 1638727
Coverity-ID: 1638728
Fixes: c458c404da16 ("xl: use libxl_domain_info to get the uuid in printf_info")
Fixes: 48dab9767d2e ("tools/xl: use libxl_domain_info to get domain type for vcpu-pin")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Release-Acked-by: Oleksii Kurochko<oleksii.kurochko@gmail.com>
---
v2: Add call to libxl_dominfo_init() to vcpuset().

--- a/tools/xl/xl_sxp.c
+++ b/tools/xl/xl_sxp.c
@@ -45,8 +45,10 @@ void printf_info_sexp(int domid, libxl_d
     /* retrieve the UUID from dominfo, since it is probably generated
      * during parsing and thus does not match the real one
      */
+    libxl_dominfo_init(&info);
     if (libxl_domain_info(ctx, &info, domid) == 0) {
         fprintf(fh, "\t(uuid " LIBXL_UUID_FMT ")\n", LIBXL_UUID_BYTES(info.uuid));
+        libxl_dominfo_dispose(&info);
     } else {
         fprintf(fh, "\t(uuid <unknown>)\n");
     }
--- a/tools/xl/xl_vcpu.c
+++ b/tools/xl/xl_vcpu.c
@@ -286,6 +286,8 @@ int main_vcpupin(int argc, char **argv)
     if (!ignore_masks && hard) {
         libxl_dominfo dominfo;
 
+        libxl_dominfo_init(&dominfo);
+
         if (libxl_domain_info(ctx, &dominfo, domid)) {
             fprintf(stderr, "Could not get domain info\n");
             goto out;
@@ -293,6 +295,8 @@ int main_vcpupin(int argc, char **argv)
 
         /* HVM and PVH domains use the same global affinity mask */
         apply_global_affinity_masks(dominfo.domain_type, hard, 1);
+
+        libxl_dominfo_dispose(&dominfo);
     }
 
     if (force) {
@@ -348,6 +352,7 @@ static int vcpuset(uint32_t domid, const
         unsigned int online_vcpus, host_cpu = libxl_get_max_cpus(ctx);
         libxl_dominfo dominfo;
 
+        libxl_dominfo_init(&dominfo);
         if (libxl_domain_info(ctx, &dominfo, domid))
             return 1;
 


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 13:31:45 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 13:31:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871371.1282379 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXh1D-0003vW-Vf; Tue, 14 Jan 2025 13:31:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871371.1282379; Tue, 14 Jan 2025 13:31:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXh1D-0003vP-T7; Tue, 14 Jan 2025 13:31:43 +0000
Received: by outflank-mailman (input) for mailman id 871371;
 Tue, 14 Jan 2025 13:31:42 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=tIyo=UG=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tXh1C-0003vJ-QF
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 13:31:42 +0000
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com
 [2a00:1450:4864:20::52f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e34c0fdd-d27b-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 14:31:40 +0100 (CET)
Received: by mail-ed1-x52f.google.com with SMTP id
 4fb4d7f45d1cf-5d3dce16a3dso3150306a12.1
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 05:31:40 -0800 (PST)
Received: from [10.81.35.177] ([46.149.103.13])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d99008c371sm6306505a12.11.2025.01.14.05.31.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 14 Jan 2025 05:31:40 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e34c0fdd-d27b-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736861500; x=1737466300; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=1mZ4UKGSguy5EH1X+T6Zge+QtjJs/EqNiKAuaEiMZPo=;
        b=XBvqwdmXXjWoaUxpHXBwEfHBeUO1yFLRuKbKpipfH5REHl6gelMQ18Fh4VTy/Embes
         mVVoEYemjqCEjGny2HYXlbllju3FbkvvvAy7K46fxA7ZjRYhRW2suqKWS4S0z4DQGYxi
         MmzyBeLiC75NdZz4yteU4HyPRnqKedzXwzxj0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736861500; x=1737466300;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=1mZ4UKGSguy5EH1X+T6Zge+QtjJs/EqNiKAuaEiMZPo=;
        b=hLKwzmqddmT49X49F+sRBWqGNbMXg5OSfdBNWqpOI+tFOCiHXF+x8w6QdEnGymJmti
         rre9puwhuSwKGkt8lSALJdSn1jcr19tOGUT7jMh7WzzYKSEsAPJGzMpNuARrdYJhu48U
         6Ts15mDOdJH47SJa41pQDCDsZ5ih0r+kT4tG1QGctlQgVm8v7/UfjdbuOEmYMT7Eq2Ke
         /xDMBkiL+Wu+W/xuEHzH1v2u2Eh7G1shADihCt0UmzGtlGpVr8YqQMY9DCwq2SWNZCS6
         /BBepkEX1daJJCJy20cZpvsczYS12E18w0wW63qqKnuLbcyJguY0zU2L9QZ6SMwmoxdP
         W3sg==
X-Forwarded-Encrypted: i=1; AJvYcCUyqORYaT4/fdWckRSQRYzc2OJASISK0Yzf7l/nUvE/DXsrPI+o+RcHaBFsIUCd6Ik5cuk4IZEvGW4=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzr3kb0KrLPseIgKuuQfwahGllevWR+EhbVOUXez8ijuOMKGw58
	uXHD8DrI9aC5L/XqW2ZZl0yY0y5JXBFA6+Gd7ZR7UlIfOfgnRvAIKdwK6wuteUU=
X-Gm-Gg: ASbGnctbg+Tjvz/nqGc3R3Uj+PZJlmBNLVNKLxbZATd2z/Ko5KVAXphyx27TVc8WzoC
	Pusz1r1MLOEkdR/ZBhVMeQlbFyNFU13bXc30H13zMNEd7meKvDORIBtdgcOtZad0gJS77f5aIHD
	uPfChCsQx3TPftMP2rPDjuOCfEtWGf1qttefj1/HHTHCDtCncWuvhSihASpZRUnhGmKX7Q1hZLq
	tyQG3GBZF4Gk/7dlum73RnRSiJv5Egl1W4HyOXf8WNVhK0Pmd6fapOsQHbvyZHLfvc=
X-Google-Smtp-Source: AGHT+IFwog1UhQPheOAqtdtkToqjWjCmu/jYaKfgfHp/BWMgJbQbJx8chnusOkgGiuW0NkfSCs03jQ==
X-Received: by 2002:a05:6402:3903:b0:5d0:e7a0:154a with SMTP id 4fb4d7f45d1cf-5d9861d6778mr19187939a12.8.1736861500419;
        Tue, 14 Jan 2025 05:31:40 -0800 (PST)
Message-ID: <99a23fc3-3181-4c28-b9e5-8cb98ef907ce@citrix.com>
Date: Tue, 14 Jan 2025 13:31:36 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] xl: properly dispose of libxl_dominfo struct instances
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>
References: <4460f13b-03bc-4ca0-aa97-facde3122be4@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <4460f13b-03bc-4ca0-aa97-facde3122be4@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14/01/2025 1:29 pm, Jan Beulich wrote:
> The ssid_label field requires separate freeing; make sure to call
> libxl_dominfo_dispose() as well as libxl_dominfo_init(). Since vcpuset()
> calls only the former, add a call to the latter there at the same time.
>
> Coverity-ID: 1638727
> Coverity-ID: 1638728
> Fixes: c458c404da16 ("xl: use libxl_domain_info to get the uuid in printf_info")
> Fixes: 48dab9767d2e ("tools/xl: use libxl_domain_info to get domain type for vcpu-pin")
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Release-Acked-by: Oleksii Kurochko<oleksii.kurochko@gmail.com>
> ---
> v2: Add call to libxl_dominfo_init() to vcpuset().

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 13:47:57 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 13:47:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871384.1282390 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXhGm-0005xv-A7; Tue, 14 Jan 2025 13:47:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871384.1282390; Tue, 14 Jan 2025 13:47:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXhGm-0005xo-6n; Tue, 14 Jan 2025 13:47:48 +0000
Received: by outflank-mailman (input) for mailman id 871384;
 Tue, 14 Jan 2025 13:47:46 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/Vp6=UG=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tXhGk-0005xi-HL
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 13:47:46 +0000
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com
 [2a00:1450:4864:20::433])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2198f1a4-d27e-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 14:47:44 +0100 (CET)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-385eed29d17so2718681f8f.0
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 05:47:44 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436e2e89dfesm212000635e9.32.2025.01.14.05.47.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 14 Jan 2025 05:47:43 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2198f1a4-d27e-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736862464; x=1737467264; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=BB02OdBh2RZeclLJ1dGmTsGyvu/vw3frzKY2bGEkmb8=;
        b=DW1X2PF2QrF6Zd/Dz42oMZtLPnodROna9gG8U2s9Xv23naSh2X0nYe3T1kcPoybjPf
         agIrvR79dRog8x8IsplbNctaFCXBQ6iruVlJnfvk5Zu2UygQYnEmVbLvlImMEtZgjBR7
         ruP5vPuwlVcAtJFnCIP1ebmgwMMhL0fPlbK3g5PtJoPG+NxZc9ikyGIK4XYwQ7IQr2Mn
         vGuOyoFycBxwmSgUH2N4KkZYemMGgAaSck7b6dfG8eErF71zY74VrCtcleDwUFSxzA1v
         k/6Y9lNXAGSLD0i7FMMb/4SyYzkzfAdF6bBHN3CA/OeECnc1sGmPC5FSa9PQhY3zo6iP
         RFbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736862464; x=1737467264;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=BB02OdBh2RZeclLJ1dGmTsGyvu/vw3frzKY2bGEkmb8=;
        b=RZJ6IY6uQKOcZ+RnWg2bMX+kBVanNn5wC6fMj9HdBgOgz2lAdn/uQNyCoWQk2iPLfL
         ODq5i36/Bno2NPogxtVQMSESwCpgsg+r5QO+IyrenVis7XQgWUivMdAVFi1Jm0kwv/AT
         J9//eyAIk87GvYtnOA0bqu47w8YpZLf3+ViI9EhbwXdYXkrCcvFt9JlDF7KhM44HRNvx
         D1fnXp1Uy8H0gNwC+eGUy763h4w86xkih8NkAD3qQzZtmXzlGoHwjb9drEqjLKxFLr9T
         GV/e3urNAl4GOJe11/8rrJSjRsg3muaYYqQMzePbgQGl/dXSjLVuRgjBiCw4E3V51b2c
         nbgg==
X-Forwarded-Encrypted: i=1; AJvYcCX6Ks5BIJmQD/rVEB6BtnXwdHmU0ESWBEYv4/hQCjfYKrJx2JoLITaUOqjq7EhtaB/QwyxYpoTUchg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxckuGbJ9Y6Y0TTVstl+Jxsb1Dni0nxLltwmy4FIt+9+zsRF72f
	9+fyYQOpTQxaOb3TBZ2Lv14TEA47VSYJKMede9xThQ+L+RTlRPu0GPxtWJtukQ==
X-Gm-Gg: ASbGncslOd1Ad414gKudeTg+7/g2sOS8Yleli+/6VTTAUhx1Mr59Ulesxt5mYEBL6My
	Jog1VuByWAkCZNqs5pQqaK06u5xDfxtICNqE9F2F+KS3E5GTzQM0hg9foE0YGiK9myPvcUZ5hhD
	M0WLLIsQAAN7+3KLiz2SuI86pHmdd0aI6cD5l797mbADP0Tad1G/7PylWfYm8Yp6vPQyGqUjzTe
	E8FeLVCf3K1gT5vtAsyBO88HNeXHV/VSbTJSGiw7FBGvwJBUv4WJf8hVM++6pdtTPfd01wwWTz4
	zkrJIgm3sJGXWYiWAObolSxlgWHR/arLRdVuu6JqGg==
X-Google-Smtp-Source: AGHT+IGnCNjNZcCfCKXkLT1oY2ZxzsWSxypl5Ni25bQkh5wLmr63ubUtFKXX5C8niMvlig4uys0sXA==
X-Received: by 2002:a05:6000:144f:b0:386:3b93:6cc6 with SMTP id ffacd0b85a97d-38a87303dd6mr23008089f8f.15.1736862463808;
        Tue, 14 Jan 2025 05:47:43 -0800 (PST)
Message-ID: <520803a3-1aed-40d4-93ab-699d1da9250b@suse.com>
Date: Tue, 14 Jan 2025 14:47:42 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 0/3] Add stack protector
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Julien Grall <julien@xen.org>, Stefano Stabellini
 <sstabellini@kernel.org>, Anthony PERARD <anthony.perard@vates.tech>,
 Samuel Thibault <samuel.thibault@ens-lyon.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
References: <20241211020424.401614-1-volodymyr_babchuk@epam.com>
 <f1e86e0e-985a-41ae-a94c-979288275257@suse.com> <87pllx3gib.fsf@epam.com>
 <fd9ea545-0eb1-4803-9d1e-df15c5805fa3@citrix.com>
 <c8ed49b1-ffa3-4a40-a006-ee6e01b64367@suse.com>
 <1622f144-e872-4e3c-8522-2e692f63e8eb@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <1622f144-e872-4e3c-8522-2e692f63e8eb@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 14.01.2025 14:28, Andrew Cooper wrote:
> On 14/01/2025 1:22 pm, Jan Beulich wrote:
>> On 12.12.2024 02:17, Andrew Cooper wrote:
>>> On 12/12/2024 12:13 am, Volodymyr Babchuk wrote:
>>>> Hello Jan,
>>>>
>>>> Jan Beulich <jbeulich@suse.com> writes:
>>>>
>>>>> On 11.12.2024 03:04, Volodymyr Babchuk wrote:
>>>>>> Both GCC and Clang support -fstack-protector feature, which add stack
>>>>>> canaries to functions where stack corruption is possible. This series
>>>>>> makes possible to use this feature in Xen. I tested this on ARM64 and
>>>>>> it is working as intended. Tested both with GCC and Clang.
>>>>>>
>>>>>> It is hard to enable this feature on x86, as GCC stores stack canary
>>>>>> in %fs:40 by default, but Xen can't use %fs for various reasons. It is
>>>>>> possibly to change stack canary location new newer GCC versions, but
>>>>>> this will change minimal GCC requirement, which is also hard due to
>>>>>> various reasons. So, this series focus mostly on ARM and RISCV.
>>>>> Why exactly would it not be possible to offer the feature when new enough
>>>>> gcc is in use?
>>>> It is possible to use this feature with a modern enough GCC, yes. Are
>>>> you suggesting to make HAS_STACK_PROTECTOR dependent on GCC_VERSION for
>>>> x86 platform?
>>> (With the knowledge that this is a disputed Kconfig pattern, and will
>>> need rebasing), the way I want this to work is simply:
>>>
>>> diff --git a/xen/Makefile b/xen/Makefile
>>> index 0de0101fd0bf..5d0a88fb3c3f 100644
>>> --- a/xen/Makefile
>>> +++ b/xen/Makefile
>>> @@ -434,6 +434,9 @@ endif
>>>  
>>>  ifeq ($(CONFIG_STACK_PROTECTOR),y)
>>>  CFLAGS += -fstack-protector
>>> +ifeq ($(CONFIG_X86),y)
>>> +CFLAGS += -mstack-protector-guard=global
>>> +endif
>>>  else
>>>  CFLAGS += -fno-stack-protector
>>>  endif
>>> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
>>> index 9cdd04721afa..7951ca908b36 100644
>>> --- a/xen/arch/x86/Kconfig
>>> +++ b/xen/arch/x86/Kconfig
>>> @@ -28,6 +28,7 @@ config X86
>>>         select HAS_PCI_MSI
>>>         select HAS_PIRQ
>>>         select HAS_SCHED_GRANULARITY
>>> +       select HAS_STACK_PROTECTOR if
>>> $(cc-option,-mstack-protector-guard=global)
>>>         select HAS_UBSAN
>>>         select HAS_VMAP
>>>         select HAS_VPCI if HVM
>>>
>>>
>>>
>>> Sadly, it doesn't build.  I get a handful of:
>>>
>>> prelink.o: in function `cmdline_parse':
>>> /home/andrew/xen.git/xen/common/kernel.c:216:(.init.text+0x20f2): failed
>>> to convert GOTPCREL relocation against '__stack_chk_guard'; relink with
>>> --no-relax
>>> /home/andrew/xen.git/xen/common/kernel.c:230:(.init.text+0x246f): failed
>>> to convert GOTPCREL relocation against '__stack_chk_guard'; relink with
>>> --no-relax
>>>
>>> which is more toolchain-whispering than I feel like doing tonight.
>> For reference:
>> https://sourceware.org/pipermail/binutils/2025-January/138631.html
>>
>> You didn't enter a gcc bug report yet, did you?
> 
> No, not yet.  I'm afraid I've not had the time.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118473

Jan



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 14:09:30 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 14:09:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871397.1282399 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXhbh-0000xl-3z; Tue, 14 Jan 2025 14:09:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871397.1282399; Tue, 14 Jan 2025 14:09:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXhbh-0000xe-1J; Tue, 14 Jan 2025 14:09:25 +0000
Received: by outflank-mailman (input) for mailman id 871397;
 Tue, 14 Jan 2025 14:04:10 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=5FwL=UG=ideasonboard.com=tomi.valkeinen@srs-se1.protection.inumbo.net>)
 id 1tXhWc-0000tM-3e
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 14:04:10 +0000
Received: from perceval.ideasonboard.com (perceval.ideasonboard.com
 [213.167.242.64]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6aa86dfc-d280-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 15:04:06 +0100 (CET)
Received: from [192.168.88.20] (91-158-153-178.elisa-laajakaista.fi
 [91.158.153.178])
 by perceval.ideasonboard.com (Postfix) with ESMTPSA id 31F9BD21;
 Tue, 14 Jan 2025 15:03:06 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 6aa86dfc-d280-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;
	s=mail; t=1736863387;
	bh=jBGGjiAjYD2JOnPDqBA/PIwuCRksQV5KpdLlTR77h4U=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=VUmMPz/TKALedLGdjaIw/OWv6jEHfDPMa8xt4ELJX5I8SbEMhIAPnQ7LMaQ/pxC0d
	 yctQn2J+9Ex5RD5bSpotgdbZkvyy/groI/l05HXur2OCULVTYWkAA3caibRw5fOAxJ
	 rPavCX5KpuNQwwNzE4HXGXO6RbtvlTGy6+Ypgri4=
Message-ID: <c303dcb4-fee9-45d0-aaff-0f5f1fef07f7@ideasonboard.com>
Date: Tue, 14 Jan 2025 16:04:00 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 15/25] drm/omapdrm: Compute dumb-buffer sizes with
 drm_mode_size_dumb()
To: Thomas Zimmermann <tzimmermann@suse.de>
Cc: dri-devel@lists.freedesktop.org, linux-mediatek@lists.infradead.org,
 freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
 imx@lists.linux.dev, linux-samsung-soc@vger.kernel.org,
 nouveau@lists.freedesktop.org, virtualization@lists.linux.dev,
 spice-devel@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org,
 linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org,
 intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org,
 maarten.lankhorst@linux.intel.com, mripard@kernel.org, airlied@gmail.com,
 simona@ffwll.ch
References: <20250109150310.219442-1-tzimmermann@suse.de>
 <20250109150310.219442-16-tzimmermann@suse.de>
Content-Language: en-US
From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Autocrypt: addr=tomi.valkeinen@ideasonboard.com; keydata=
 xsFNBE6ms0cBEACyizowecZqXfMZtnBniOieTuFdErHAUyxVgtmr0f5ZfIi9Z4l+uUN4Zdw2
 wCEZjx3o0Z34diXBaMRJ3rAk9yB90UJAnLtb8A97Oq64DskLF81GCYB2P1i0qrG7UjpASgCA
 Ru0lVvxsWyIwSfoYoLrazbT1wkWRs8YBkkXQFfL7Mn3ZMoGPcpfwYH9O7bV1NslbmyJzRCMO
 eYV258gjCcwYlrkyIratlHCek4GrwV8Z9NQcjD5iLzrONjfafrWPwj6yn2RlL0mQEwt1lOvn
 LnI7QRtB3zxA3yB+FLsT1hx0va6xCHpX3QO2gBsyHCyVafFMrg3c/7IIWkDLngJxFgz6DLiA
 G4ld1QK/jsYqfP2GIMH1mFdjY+iagG4DqOsjip479HCWAptpNxSOCL6z3qxCU8MCz8iNOtZk
 DYXQWVscM5qgYSn+fmMM2qN+eoWlnCGVURZZLDjg387S2E1jT/dNTOsM/IqQj+ZROUZuRcF7
 0RTtuU5q1HnbRNwy+23xeoSGuwmLQ2UsUk7Q5CnrjYfiPo3wHze8avK95JBoSd+WIRmV3uoO
 rXCoYOIRlDhg9XJTrbnQ3Ot5zOa0Y9c4IpyAlut6mDtxtKXr4+8OzjSVFww7tIwadTK3wDQv
 Bus4jxHjS6dz1g2ypT65qnHen6mUUH63lhzewqO9peAHJ0SLrQARAQABzTBUb21pIFZhbGtl
 aW5lbiA8dG9taS52YWxrZWluZW5AaWRlYXNvbmJvYXJkLmNvbT7CwY4EEwEIADgWIQTEOAw+
 ll79gQef86f6PaqMvJYe9QUCX/HruAIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRD6
 PaqMvJYe9WmFD/99NGoD5lBJhlFDHMZvO+Op8vCwnIRZdTsyrtGl72rVh9xRfcSgYPZUvBuT
 VDxE53mY9HaZyu1eGMccYRBaTLJSfCXl/g317CrMNdY0k40b9YeIX10feiRYEWoDIPQ3tMmA
 0nHDygzcnuPiPT68JYZ6tUOvAt7r6OX/litM+m2/E9mtp8xCoWOo/kYO4mOAIoMNvLB8vufi
 uBB4e/AvAjtny4ScuNV5c5q8MkfNIiOyag9QCiQ/JfoAqzXRjVb4VZG72AKaElwipiKCWEcU
 R4+Bu5Qbaxj7Cd36M/bI54OrbWWETJkVVSV1i0tghCd6HHyquTdFl7wYcz6cL1hn/6byVnD+
 sR3BLvSBHYp8WSwv0TCuf6tLiNgHAO1hWiQ1pOoXyMEsxZlgPXT+wb4dbNVunckwqFjGxRbl
 Rz7apFT/ZRwbazEzEzNyrBOfB55xdipG/2+SmFn0oMFqFOBEszXLQVslh64lI0CMJm2OYYe3
 PxHqYaztyeXsx13Bfnq9+bUynAQ4uW1P5DJ3OIRZWKmbQd/Me3Fq6TU57LsvwRgE0Le9PFQs
 dcP2071rMTpqTUteEgODJS4VDf4lXJfY91u32BJkiqM7/62Cqatcz5UWWHq5xeF03MIUTqdE
 qHWk3RJEoWHWQRzQfcx6Fn2fDAUKhAddvoopfcjAHfpAWJ+ENc7BTQROprNHARAAx0aat8GU
 hsusCLc4MIxOQwidecCTRc9Dz/7U2goUwhw2O5j9TPqLtp57VITmHILnvZf6q3QAho2QMQyE
 DDvHubrdtEoqaaSKxKkFie1uhWNNvXPhwkKLYieyL9m2JdU+b88HaDnpzdyTTR4uH7wk0bBa
 KbTSgIFDDe5lXInypewPO30TmYNkFSexnnM3n1PBCqiJXsJahE4ZQ+WnV5FbPUj8T2zXS2xk
 0LZ0+DwKmZ0ZDovvdEWRWrz3UzJ8DLHb7blPpGhmqj3ANXQXC7mb9qJ6J/VSl61GbxIO2Dwb
 xPNkHk8fwnxlUBCOyBti/uD2uSTgKHNdabhVm2dgFNVuS1y3bBHbI/qjC3J7rWE0WiaHWEqy
 UVPk8rsph4rqITsj2RiY70vEW0SKePrChvET7D8P1UPqmveBNNtSS7In+DdZ5kUqLV7rJnM9
 /4cwy+uZUt8cuCZlcA5u8IsBCNJudxEqBG10GHg1B6h1RZIz9Q9XfiBdaqa5+CjyFs8ua01c
 9HmyfkuhXG2OLjfQuK+Ygd56mV3lq0aFdwbaX16DG22c6flkkBSjyWXYepFtHz9KsBS0DaZb
 4IkLmZwEXpZcIOQjQ71fqlpiXkXSIaQ6YMEs8WjBbpP81h7QxWIfWtp+VnwNGc6nq5IQDESH
 mvQcsFS7d3eGVI6eyjCFdcAO8eMAEQEAAcLBXwQYAQIACQUCTqazRwIbDAAKCRD6PaqMvJYe
 9fA7EACS6exUedsBKmt4pT7nqXBcRsqm6YzT6DeCM8PWMTeaVGHiR4TnNFiT3otD5UpYQI7S
 suYxoTdHrrrBzdlKe5rUWpzoZkVK6p0s9OIvGzLT0lrb0HC9iNDWT3JgpYDnk4Z2mFi6tTbq
 xKMtpVFRA6FjviGDRsfkfoURZI51nf2RSAk/A8BEDDZ7lgJHskYoklSpwyrXhkp9FHGMaYII
 m9EKuUTX9JPDG2FTthCBrdsgWYPdJQvM+zscq09vFMQ9Fykbx5N8z/oFEUy3ACyPqW2oyfvU
 CH5WDpWBG0s5BALp1gBJPytIAd/pY/5ZdNoi0Cx3+Z7jaBFEyYJdWy1hGddpkgnMjyOfLI7B
 CFrdecTZbR5upjNSDvQ7RG85SnpYJTIin+SAUazAeA2nS6gTZzumgtdw8XmVXZwdBfF+ICof
 92UkbYcYNbzWO/GHgsNT1WnM4sa9lwCSWH8Fw1o/3bX1VVPEsnESOfxkNdu+gAF5S6+I6n3a
 ueeIlwJl5CpT5l8RpoZXEOVtXYn8zzOJ7oGZYINRV9Pf8qKGLf3Dft7zKBP832I3PQjeok7F
 yjt+9S+KgSFSHP3Pa4E7lsSdWhSlHYNdG/czhoUkSCN09C0rEK93wxACx3vtxPLjXu6RptBw
 3dRq7n+mQChEB1am0BueV1JZaBboIL0AGlSJkm23kw==
In-Reply-To: <20250109150310.219442-16-tzimmermann@suse.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

On 09/01/2025 16:57, Thomas Zimmermann wrote:
> Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
> buffer size. Align the pitch to a multiple of 8.
> 
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> ---
>   drivers/gpu/drm/omapdrm/omap_gem.c | 15 +++++++--------
>   1 file changed, 7 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c b/drivers/gpu/drm/omapdrm/omap_gem.c
> index b9c67e4ca360..b8413a2dcdeb 100644
> --- a/drivers/gpu/drm/omapdrm/omap_gem.c
> +++ b/drivers/gpu/drm/omapdrm/omap_gem.c
> @@ -11,6 +11,7 @@
>   #include <linux/pfn_t.h>
>   #include <linux/vmalloc.h>
>   
> +#include <drm/drm_dumb_buffers.h>
>   #include <drm/drm_prime.h>
>   #include <drm/drm_vma_manager.h>
>   
> @@ -583,15 +584,13 @@ static int omap_gem_object_mmap(struct drm_gem_object *obj, struct vm_area_struc
>   int omap_gem_dumb_create(struct drm_file *file, struct drm_device *dev,
>   		struct drm_mode_create_dumb *args)
>   {
> -	union omap_gem_size gsize;
> -
> -	args->pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
> -
> -	args->size = PAGE_ALIGN(args->pitch * args->height);
> +	union omap_gem_size gsize = { };
> +	int ret;
>   
> -	gsize = (union omap_gem_size){
> -		.bytes = args->size,
> -	};
> +	ret = drm_mode_size_dumb(dev, args, SZ_8, 0);
> +	if (ret)
> +		return ret;
> +	gsize.bytes = args->size;
>   
>   	return omap_gem_new_handle(dev, file, gsize,
>   			OMAP_BO_SCANOUT | OMAP_BO_WC, &args->handle);

Tested on dra76 evm.

Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>

  Tomi



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 14:15:53 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 14:15:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871412.1282409 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXhhh-0002oG-O5; Tue, 14 Jan 2025 14:15:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871412.1282409; Tue, 14 Jan 2025 14:15:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXhhh-0002o9-LZ; Tue, 14 Jan 2025 14:15:37 +0000
Received: by outflank-mailman (input) for mailman id 871412;
 Tue, 14 Jan 2025 14:15:37 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=tIyo=UG=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tXhhg-0002o3-Vi
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 14:15:36 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 04fec8ab-d282-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 15:15:34 +0100 (CET)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-5d3f28a4fccso8038690a12.2
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 06:15:34 -0800 (PST)
Received: from [10.81.35.177] ([46.149.103.9])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d99046a070sm6262492a12.59.2025.01.14.06.15.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 14 Jan 2025 06:15:33 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 04fec8ab-d282-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736864134; x=1737468934; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=7jOWg2dFuRI0+nm0tXCSec8stp9G6L4/2BkM6Ks74Ho=;
        b=KjYzel8ulI4Ft1pXgV5l+rWgVaegBhSsAHp2ArR65y/bfPMeekFu1KktmhbTu6ohlp
         N6XOYJSdLXCiR+Dtbf0u/iqoT3cQkYaOIs75lyiGBcc6PdJ5TqOtFKnmlZI9xM6D9Fg4
         Tx++Bhmf8zNhhKlNaL0JSZLgiEYJAJcBLPe/o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736864134; x=1737468934;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=7jOWg2dFuRI0+nm0tXCSec8stp9G6L4/2BkM6Ks74Ho=;
        b=MnQeMUQs6uz6IwnrYl846FI3YxPYpvBcrqCNnpqB3qWYHJYuMX+yYG+Sh3mJV1J8D4
         wF9fviXorm8AOtj3p/Ha+JLLyNcRCyC/5LQvlR881sjD2QR3eH0rhfO1/UFd/LBeCerL
         jIWxYjpKY5QHey+sckDEh2+ODx78uZyoJKvq2/Xm/CPEvH6QP/KYCwRLAIDjLQV3ZuCE
         YnCaTXyMYp0mPnYJ5mVz2lheFiQHH/0ufmHBbWi4d8TOtqFFiUWP+i2yS7q0Vi+uVLZ0
         LXv0E35eGWNzGpVwCPcolOXm7IzekZ/GFD4tpyjTXNWkh+D07s0OJAmJHSYtoWcdkUFf
         k5bg==
X-Forwarded-Encrypted: i=1; AJvYcCVTRRGNHiVSsSQUWABj7GQ1xJJza2zIDz0TxzNZYJ7rzJdmhJ3/y3uEU4tB3ByAF6/h62e2W5KoMaU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwyMHmay3LE3RA+5Ap7j89sfU/1DUylslQ21jzHk+Bg9i27Av05
	F7d9/f6y5i8dBdgZpBxPqMl0A7gBNUyqsygsMZxqn1Li2HshCc9wdCmDwInkzBk=
X-Gm-Gg: ASbGncsvvqLcajVVZug5hzJcgUmEUW1WywRvKmsNbg4pSL3eGXQUxhnI+pxkCo7TUhS
	h8rK2RGwvdd8finiEFedUZy6lYQuzZTgR9yrkmby0sHDirnefnNi0gth+D74M1fE57YISyVg5nR
	zxgLUCqfdgl6+sYbw45ieSe9dpduoPmgtUPoPK3oGtIF3r0deLSrqCHkBeRkpt8mSIfpUMJeSCk
	YALfHhPJsWJIgOcucZxP3S5Sg6hYE1Q8F2QVXc8G4B43LoaD825t6+/AM9bJuxJ1A==
X-Google-Smtp-Source: AGHT+IGXJVYxVp5ftZ+htjuNJEwVMgkfZ/wxojDEidePaNkzKwS2+2KhrLh1A1BE0L14MReHjmLNsA==
X-Received: by 2002:a05:6402:3888:b0:5d0:b7c5:c3fc with SMTP id 4fb4d7f45d1cf-5d972dfbbb6mr22799298a12.3.1736864133821;
        Tue, 14 Jan 2025 06:15:33 -0800 (PST)
Message-ID: <3bd4a7a0-8339-4a55-8df9-2264faafb54d@citrix.com>
Date: Tue, 14 Jan 2025 14:15:32 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 0/3] Add stack protector
To: Jan Beulich <jbeulich@suse.com>
Cc: Julien Grall <julien@xen.org>, Stefano Stabellini
 <sstabellini@kernel.org>, Anthony PERARD <anthony.perard@vates.tech>,
 Samuel Thibault <samuel.thibault@ens-lyon.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
References: <20241211020424.401614-1-volodymyr_babchuk@epam.com>
 <f1e86e0e-985a-41ae-a94c-979288275257@suse.com> <87pllx3gib.fsf@epam.com>
 <fd9ea545-0eb1-4803-9d1e-df15c5805fa3@citrix.com>
 <c8ed49b1-ffa3-4a40-a006-ee6e01b64367@suse.com>
 <1622f144-e872-4e3c-8522-2e692f63e8eb@citrix.com>
 <520803a3-1aed-40d4-93ab-699d1da9250b@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <520803a3-1aed-40d4-93ab-699d1da9250b@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 14/01/2025 1:47 pm, Jan Beulich wrote:
> On 14.01.2025 14:28, Andrew Cooper wrote:
>> On 14/01/2025 1:22 pm, Jan Beulich wrote:
>>> On 12.12.2024 02:17, Andrew Cooper wrote:
>>>> On 12/12/2024 12:13 am, Volodymyr Babchuk wrote:
>>>>> Hello Jan,
>>>>>
>>>>> Jan Beulich <jbeulich@suse.com> writes:
>>>>>
>>>>>> On 11.12.2024 03:04, Volodymyr Babchuk wrote:
>>>>>>> Both GCC and Clang support -fstack-protector feature, which add stack
>>>>>>> canaries to functions where stack corruption is possible. This series
>>>>>>> makes possible to use this feature in Xen. I tested this on ARM64 and
>>>>>>> it is working as intended. Tested both with GCC and Clang.
>>>>>>>
>>>>>>> It is hard to enable this feature on x86, as GCC stores stack canary
>>>>>>> in %fs:40 by default, but Xen can't use %fs for various reasons. It is
>>>>>>> possibly to change stack canary location new newer GCC versions, but
>>>>>>> this will change minimal GCC requirement, which is also hard due to
>>>>>>> various reasons. So, this series focus mostly on ARM and RISCV.
>>>>>> Why exactly would it not be possible to offer the feature when new enough
>>>>>> gcc is in use?
>>>>> It is possible to use this feature with a modern enough GCC, yes. Are
>>>>> you suggesting to make HAS_STACK_PROTECTOR dependent on GCC_VERSION for
>>>>> x86 platform?
>>>> (With the knowledge that this is a disputed Kconfig pattern, and will
>>>> need rebasing), the way I want this to work is simply:
>>>>
>>>> diff --git a/xen/Makefile b/xen/Makefile
>>>> index 0de0101fd0bf..5d0a88fb3c3f 100644
>>>> --- a/xen/Makefile
>>>> +++ b/xen/Makefile
>>>> @@ -434,6 +434,9 @@ endif
>>>>  
>>>>  ifeq ($(CONFIG_STACK_PROTECTOR),y)
>>>>  CFLAGS += -fstack-protector
>>>> +ifeq ($(CONFIG_X86),y)
>>>> +CFLAGS += -mstack-protector-guard=global
>>>> +endif
>>>>  else
>>>>  CFLAGS += -fno-stack-protector
>>>>  endif
>>>> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
>>>> index 9cdd04721afa..7951ca908b36 100644
>>>> --- a/xen/arch/x86/Kconfig
>>>> +++ b/xen/arch/x86/Kconfig
>>>> @@ -28,6 +28,7 @@ config X86
>>>>         select HAS_PCI_MSI
>>>>         select HAS_PIRQ
>>>>         select HAS_SCHED_GRANULARITY
>>>> +       select HAS_STACK_PROTECTOR if
>>>> $(cc-option,-mstack-protector-guard=global)
>>>>         select HAS_UBSAN
>>>>         select HAS_VMAP
>>>>         select HAS_VPCI if HVM
>>>>
>>>>
>>>>
>>>> Sadly, it doesn't build.  I get a handful of:
>>>>
>>>> prelink.o: in function `cmdline_parse':
>>>> /home/andrew/xen.git/xen/common/kernel.c:216:(.init.text+0x20f2): failed
>>>> to convert GOTPCREL relocation against '__stack_chk_guard'; relink with
>>>> --no-relax
>>>> /home/andrew/xen.git/xen/common/kernel.c:230:(.init.text+0x246f): failed
>>>> to convert GOTPCREL relocation against '__stack_chk_guard'; relink with
>>>> --no-relax
>>>>
>>>> which is more toolchain-whispering than I feel like doing tonight.
>>> For reference:
>>> https://sourceware.org/pipermail/binutils/2025-January/138631.html
>>>
>>> You didn't enter a gcc bug report yet, did you?
>> No, not yet.  I'm afraid I've not had the time.
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118473

Thankyou.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 14:23:29 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 14:23:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871423.1282420 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXhpF-0004eZ-GC; Tue, 14 Jan 2025 14:23:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871423.1282420; Tue, 14 Jan 2025 14:23:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXhpF-0004eS-DI; Tue, 14 Jan 2025 14:23:25 +0000
Received: by outflank-mailman (input) for mailman id 871423;
 Tue, 14 Jan 2025 14:23:24 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=wcbX=UG=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tXhpE-0004eM-Bb
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 14:23:24 +0000
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com
 [2a00:1450:4864:20::22e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1c580b17-d283-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 15:23:23 +0100 (CET)
Received: by mail-lj1-x22e.google.com with SMTP id
 38308e7fff4ca-303548a933aso44692421fa.3
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 06:23:23 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-305ff0ad5d8sm18325431fa.2.2025.01.14.06.23.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 14 Jan 2025 06:23:21 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1c580b17-d283-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736864602; x=1737469402; darn=lists.xenproject.org;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=4dNK0OcUzAFy9rXQSAnafLIpwhZuD4UFqVC5bwji4ws=;
        b=OMDQxN7n2ATe7Do30Wm132fZDaqVGkXR0qBauxsMS8Bco8b2Iorv3KA5mHFqA8B7oK
         JZxH5rX/HAqRezG8esCfKu4GvMt6M//b4CVqZvVnps1/WEQ2BYqQv8QzAXmsE0RIBBE8
         0Yvu80CskTQyOARl7MjI0tnrnLGE50mZyIMGQ/gZCuwTzVS1hVaRQ2fk6nuAIg/kJbd+
         GFjERdTKKhhuxfHo1nKaFrY1CIY9eHaov/8ibLQWouRw6uFHrmzQUychpVig0TiBSc5R
         ePG7cmCApKSUoj4HznpDo6d72tIq9PHKud9EiZ8+nyiK3NpisSQav8TFKNRrYDTmFMnO
         wokw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736864602; x=1737469402;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=4dNK0OcUzAFy9rXQSAnafLIpwhZuD4UFqVC5bwji4ws=;
        b=oNZqI5JtNqobIDL3gduoHWPU0RS/EE2RrdtIDZh/+HjcztdmSIXSevq8OXMdmc1RR0
         FCg66glFlby+YwmapGEdDK4tppZnsR3yPY9cdfEfzMBVzU5XUCrpjXRC7ACS2pCrhWs9
         E1QDOuOoQ2so4IvUefDArb+on+boe0rtx+529L+ntLgpC7XW7fU1QeO8m8sGbruKcJTK
         hJ4eRA2w83F63JO82G20E4v+A1tGW0+G7nHYKlNA8N4HAvPJ17wkrFo+u6AJygN1qyx0
         MnbtsSb1kjuqJN5cWB9bVzpFKQtP1e0PJPokrBWEQ6RNVfU0N5S0ukSnl68WIO3FC9Qd
         IdIA==
X-Forwarded-Encrypted: i=1; AJvYcCU1oWdn3sfBXDjGJlPSXtXsKRVix7Ei8SLtS1psqRtwucAsfajn61McRqzQg7Atsud8fvPNnbfP2bI=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw+/0jhXlLRPyBEAr/ZdLP1yjE4MWsTqVQrkDPpiuozvdZxz97M
	cQpNwg1jZzrwPT+4wwteu1fkuZHLFCRnZltuJJJAJiMTczI6SYsu
X-Gm-Gg: ASbGncsWohequwOfSUmruO4m7eW1+/DbcqQkxHgs0UgmbTC0kX4muUGIxnDKcJFKnXd
	+kzgCH9e0WfN7oCqKkW5YL+E3DMH3hS/gRQcqO50QLc12Oi9hxcxfb2wJk++o/mY4CBQqA68pFD
	/bSQ0jEAkM6G5ua7K8i0lPP3zoR20cCwzxG1GbOMfSc/9xZaPyMAGOTnZiZdQJyfQpl1KKeMFb0
	MYYf6InobNBgApBcAA0QBXHse49ZpOKKVrR9caHZObrYyyB2xrTTeBBhJ/3aI7AvbpLEA==
X-Google-Smtp-Source: AGHT+IGHUEcwKfmAH8Tf32ObzrDAk5bSFKRMcMJYLzyQ1JzwADJYmGBej5QCBE/5EufemQw/jiKmTA==
X-Received: by 2002:a05:651c:b1f:b0:306:f7:c40a with SMTP id 38308e7fff4ca-30600f7c566mr75067681fa.18.1736864602073;
        Tue, 14 Jan 2025 06:23:22 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------mjAnriMAA48UjE7ei24TCGnc"
Message-ID: <481e1955-783a-48d0-8604-ec8554f50fc5@gmail.com>
Date: Tue, 14 Jan 2025 15:23:21 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 1/2] x86/time: introduce command line option to select
 wallclock
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Cc: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, xen-devel@lists.xenproject.org,
 "Daniel P. Smith" <dpsmith@apertussolutions.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>
References: <20240913075907.34460-1-roger.pau@citrix.com>
 <20240913075907.34460-2-roger.pau@citrix.com> <Z4U6WxtmaqGkqOqe@mail-itl>
 <Z4VS88REbzn5uasy@macbook.local>
 <49a2404f-0c45-4397-9094-a4189131832f@gmail.com>
 <Z4ZKINmJXw5T2dsM@macbook.local>
 <78e09ccb-65b7-4022-b9fc-7874e34c1a99@gmail.com>
 <9288f0de-945f-4056-9934-16b2b1704fb1@gmail.com>
 <Z4ZU_uvCe5lu0aMv@macbook.local>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <Z4ZU_uvCe5lu0aMv@macbook.local>

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


On 1/14/25 1:13 PM, Roger Pau Monné wrote:
> On Tue, Jan 14, 2025 at 12:44:39PM +0100, Oleksii Kurochko wrote:
>> On 1/14/25 12:40 PM, Oleksii Kurochko wrote:
>>>
>>> On 1/14/25 12:27 PM, Roger Pau Monné wrote:
>>>> On Tue, Jan 14, 2025 at 12:12:03PM +0100, Oleksii Kurochko wrote:
>>>>> On 1/13/25 6:52 PM, Roger Pau Monné wrote:
>>>>>> On Mon, Jan 13, 2025 at 05:07:55PM +0100, Marek Marczykowski-Górecki wrote:
>>>>>>> On Fri, Sep 13, 2024 at 09:59:06AM +0200, Roger Pau Monne wrote:
>>>>>>>> Allow setting the used wallclock from the command line.  When the option is set
>>>>>>>> to a value different than `auto` the probing is bypassed and the selected
>>>>>>>> implementation is used (as long as it's available).
>>>>>>>>
>>>>>>>> The `xen` and `efi` options require being booted as a Xen guest (with Xen guest
>>>>>>>> supported built-in) or from UEFI firmware respectively.
>>>>>>>>
>>>>>>>> Signed-off-by: Roger Pau Monné<roger.pau@citrix.com>
>>>>>>> Reviewed-by: Marek Marczykowski-Górecki<marmarek@invisiblethingslab.com>
>>>>>> Thanks for the review.
>>>>>>
>>>>>> Oleksii, can I get your opinion as Release Manager about whether this
>>>>>> (and the following patch) would be suitable for committing to staging
>>>>>> given the current release state?
>>>>>>
>>>>>> It's a workaround for broken EFI implementations that many downstreams
>>>>>> carry on their patch queue.
>>>>> Based on your commit message, I understand this as addressing a bug ( but not very critical
>>>>> as IIUC downstreams have the similar patch on their side ). Therefore, if it has been properly
>>>>> reviewed and tested, we should consider including it in the current release.
>>>> IIRC at least Qubes, XenServer and XCP-ng have a patch that achieves
>>>> the same behavior as proposed here.
>>>>
>>>>> IIUC, setting the wallclock to EFI should align with the behavior Xen had previously.
>>>>> It might be preferable to use that argument as the default for a while, allowing others to verify the "auto"
>>>>> value over time. After that, we could consider making "auto" the default.
>>>>> That said, I am not particularly strict about following this approach.
>>>> We cannot really set efi as the default, as it would break when
>>>> booting on legacy BIOS systems.
>>>>
>>>> We could take only patch 1 and leave patch 2 after Xen 4.20 has
>>>> branched, but at that point I would see little benefit in having just
>>>> patch 1.
>>> I don't see a lot of benefit of comitting only the one patch either.
>>>
>>>
>>>> I don't have a strong opinion, but downstreams have been complaining
>>>> about Xen behavior regarding the usage of EFI_GET_TIME, so it might be
>>>> good to not ship yet another release with such allegedly broken
>>>> behavior.
>>> Agree with that. As  I mentioned above I consider it as a bug and based on
>>> that several mentioned above downstreams have the similar patch I could consider
>>> that as tested approach so ..
>>>> Let me know what you think, as I would need a formal Release-Ack if
>>>> this is to be committed.
>>> ... R-Acked-by: Oleksii Kurochko<oleksii.kurochko@gmail.com>.
>> Sorry for the noise.
>>
>> I missed to add that it would also be nice to mention IMO ( that now we have wallclock parameter )
>> in CHANGELOG so downstreams will receive "notification" that Xen provides a workaround for the mentioned
>> issue in the patch series.
> Indeed.  Would you be OK with adding the following chunk to patch 2?
>
> diff --git a/CHANGELOG.md b/CHANGELOG.md
> index 8507e6556a56..1de1d1eca17f 100644
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -12,6 +12,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>      leaving this to the guest kernel to do in guest context.
>    - On x86:
>      - Prefer ACPI reboot over UEFI ResetSystem() run time service call.
> +   - Prefer CMOS over EFI_GET_TIME as time source.
>      - Switched the xAPIC flat driver to use physical destination mode for external
>        interrupts instead of logical destination mode.
>   
> @@ -24,6 +25,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>      - Support for LLC (Last Level Cache) coloring.
>    - On x86:
>      - xl suspend/resume subcommands.
> +   - `wallclock` command line option to select time source.

What about of adding word 'Add' before `wallclock`?

Other LGTM: Acked-By: Oleksii Kurochko<oleksii.kurochko@gmail.com>

Thanks.

~ Oleksii

>   
>   ### Removed
>    - On x86:
--------------mjAnriMAA48UjE7ei24TCGnc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 1/14/25 1:13 PM, Roger Pau Monné
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:Z4ZU_uvCe5lu0aMv@macbook.local">
      <pre wrap="" class="moz-quote-pre">On Tue, Jan 14, 2025 at 12:44:39PM +0100, Oleksii Kurochko wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">
On 1/14/25 12:40 PM, Oleksii Kurochko wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="" class="moz-quote-pre">

On 1/14/25 12:27 PM, Roger Pau Monné wrote:
</pre>
          <blockquote type="cite">
            <pre wrap="" class="moz-quote-pre">On Tue, Jan 14, 2025 at 12:12:03PM +0100, Oleksii Kurochko wrote:
</pre>
            <blockquote type="cite">
              <pre wrap="" class="moz-quote-pre">On 1/13/25 6:52 PM, Roger Pau Monné wrote:
</pre>
              <blockquote type="cite">
                <pre wrap="" class="moz-quote-pre">On Mon, Jan 13, 2025 at 05:07:55PM +0100, Marek Marczykowski-Górecki wrote:
</pre>
                <blockquote type="cite">
                  <pre wrap="" class="moz-quote-pre">On Fri, Sep 13, 2024 at 09:59:06AM +0200, Roger Pau Monne wrote:
</pre>
                  <blockquote type="cite">
                    <pre wrap="" class="moz-quote-pre">Allow setting the used wallclock from the command line.  When the option is set
to a value different than `auto` the probing is bypassed and the selected
implementation is used (as long as it's available).

The `xen` and `efi` options require being booted as a Xen guest (with Xen guest
supported built-in) or from UEFI firmware respectively.

Signed-off-by: Roger Pau Monné<a class="moz-txt-link-rfc2396E" href="mailto:roger.pau@citrix.com">&lt;roger.pau@citrix.com&gt;</a>
</pre>
                  </blockquote>
                  <pre wrap="" class="moz-quote-pre">Reviewed-by: Marek Marczykowski-Górecki<a class="moz-txt-link-rfc2396E" href="mailto:marmarek@invisiblethingslab.com">&lt;marmarek@invisiblethingslab.com&gt;</a>
</pre>
                </blockquote>
                <pre wrap="" class="moz-quote-pre">Thanks for the review.

Oleksii, can I get your opinion as Release Manager about whether this
(and the following patch) would be suitable for committing to staging
given the current release state?

It's a workaround for broken EFI implementations that many downstreams
carry on their patch queue.
</pre>
              </blockquote>
              <pre wrap="" class="moz-quote-pre">Based on your commit message, I understand this as addressing a bug ( but not very critical
as IIUC downstreams have the similar patch on their side ). Therefore, if it has been properly
reviewed and tested, we should consider including it in the current release.
</pre>
            </blockquote>
            <pre wrap="" class="moz-quote-pre">IIRC at least Qubes, XenServer and XCP-ng have a patch that achieves
the same behavior as proposed here.

</pre>
            <blockquote type="cite">
              <pre wrap="" class="moz-quote-pre">IIUC, setting the wallclock to EFI should align with the behavior Xen had previously.
It might be preferable to use that argument as the default for a while, allowing others to verify the "auto"
value over time. After that, we could consider making "auto" the default.
That said, I am not particularly strict about following this approach.
</pre>
            </blockquote>
            <pre wrap="" class="moz-quote-pre">We cannot really set efi as the default, as it would break when
booting on legacy BIOS systems.

We could take only patch 1 and leave patch 2 after Xen 4.20 has
branched, but at that point I would see little benefit in having just
patch 1.
</pre>
          </blockquote>
          <pre wrap="" class="moz-quote-pre">I don't see a lot of benefit of comitting only the one patch either.


</pre>
          <blockquote type="cite">
            <pre wrap="" class="moz-quote-pre">I don't have a strong opinion, but downstreams have been complaining
about Xen behavior regarding the usage of EFI_GET_TIME, so it might be
good to not ship yet another release with such allegedly broken
behavior.
</pre>
          </blockquote>
          <pre wrap="" class="moz-quote-pre">Agree with that. As  I mentioned above I consider it as a bug and based on
that several mentioned above downstreams have the similar patch I could consider
that as tested approach so ..
</pre>
          <blockquote type="cite">
            <pre wrap="" class="moz-quote-pre">Let me know what you think, as I would need a formal Release-Ack if
this is to be committed.
</pre>
          </blockquote>
          <pre wrap="" class="moz-quote-pre">... R-Acked-by: Oleksii Kurochko<a class="moz-txt-link-rfc2396E" href="mailto:oleksii.kurochko@gmail.com">&lt;oleksii.kurochko@gmail.com&gt;</a>.
</pre>
        </blockquote>
        <pre wrap="" class="moz-quote-pre">
Sorry for the noise.

I missed to add that it would also be nice to mention IMO ( that now we have wallclock parameter )
in CHANGELOG so downstreams will receive "notification" that Xen provides a workaround for the mentioned
issue in the patch series.
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
Indeed.  Would you be OK with adding the following chunk to patch 2?

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 8507e6556a56..1de1d1eca17f 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -12,6 +12,7 @@ The format is based on [Keep a Changelog](<a class="moz-txt-link-freetext" href="https://keepachangelog.com/en/1.0.0/">https://keepachangelog.com/en/1.0.0/</a>)
    leaving this to the guest kernel to do in guest context.
  - On x86:
    - Prefer ACPI reboot over UEFI ResetSystem() run time service call.
+   - Prefer CMOS over EFI_GET_TIME as time source.
    - Switched the xAPIC flat driver to use physical destination mode for external
      interrupts instead of logical destination mode.
 
@@ -24,6 +25,7 @@ The format is based on [Keep a Changelog](<a class="moz-txt-link-freetext" href="https://keepachangelog.com/en/1.0.0/">https://keepachangelog.com/en/1.0.0/</a>)
    - Support for LLC (Last Level Cache) coloring.
  - On x86:
    - xl suspend/resume subcommands.
+   - `wallclock` command line option to select time source.</pre>
    </blockquote>
    <pre>What about of adding word 'Add' before `wallclock`?

Other LGTM: Acked-By: Oleksii Kurochko <a class="moz-txt-link-rfc2396E" href="mailto:oleksii.kurochko@gmail.com">&lt;oleksii.kurochko@gmail.com&gt;</a>

Thanks.

~ Oleksii
</pre>
    <blockquote type="cite" cite="mid:Z4ZU_uvCe5lu0aMv@macbook.local">
      <pre wrap="" class="moz-quote-pre">
 
 ### Removed
  - On x86:
</pre>
    </blockquote>
  </body>
</html>

--------------mjAnriMAA48UjE7ei24TCGnc--


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 14:49:13 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 14:49:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871440.1282430 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXiE7-0008BW-I5; Tue, 14 Jan 2025 14:49:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871440.1282430; Tue, 14 Jan 2025 14:49:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXiE7-0008BP-Ey; Tue, 14 Jan 2025 14:49:07 +0000
Received: by outflank-mailman (input) for mailman id 871440;
 Tue, 14 Jan 2025 14:49:06 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=xX/k=UG=bugseng.com=nicola.vetrini@srs-se1.protection.inumbo.net>)
 id 1tXiE5-0008BJ-QW
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 14:49:06 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b28315a3-d286-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 15:49:03 +0100 (CET)
Received: from nico.bugseng.com (unknown [46.228.253.214])
 by support.bugseng.com (Postfix) with ESMTPSA id 61BBA4EE0744;
 Tue, 14 Jan 2025 15:49:01 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b28315a3-d286-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1736866142; bh=DJ6jpLTmOUZYj3qjLrzX6AalQlIrFW29F8p7tbjACOY=;
	h=From:To:Cc:Subject:Date:From;
	b=ObCQxmbDnkUk46KAJj/I/dnKkruCH/3vGnQ1PxaHMs3K57zI12cyjM0FLUTGLaFx6
	 vW3pWZSapvH6mfAeE3FmSGu5olMOKmjCk/ZggJ6gzNth013dM2JZmr76bbB1HeqYVh
	 dJu69vTEPGl8+40UP3kar6bNBQ9rMGalbDv3fLL3N47TrenNaAh/ZP3dVkjYPA4zeI
	 iy0PdUT/pvkLNqe46PQL5jsmdZ+8bJVxFTvg3pIY9LHwTYndEHNVFBb7FekZBJnGtX
	 +Gm5ULOeHbSUXV4qQoz00U1D0DnDPG2WywB5fvV7fFJv6xL+4OhL2P1dq/KVsnfbRP
	 TNFXQdZt9I9sg==
From: Nicola Vetrini <nicola.vetrini@bugseng.com>
To: xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	michal.orzel@amd.com,
	xenia.ragiadakou@amd.com,
	ayan.kumar.halder@amd.com,
	consulting@bugseng.com,
	Nicola Vetrini <nicola.vetrini@bugseng.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [XEN PATCH] MAINTAINERS: Change reviewer of the ECLAIR integration
Date: Tue, 14 Jan 2025 15:48:54 +0100
Message-ID: <8c370ced911457c883360836bd5afda747426a13.1736856521.git.nicola.vetrini@bugseng.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Simone Ballarin is no longer actively involved in reviewing
the ECLAIR integration for Xen. I am stepping up as a reviewer.

Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 392f780f7617..c11b82eca98f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -297,7 +297,7 @@ F:	xen/include/xen/device_tree.h
 F:	xen/drivers/passthrough/device_tree.c
 
 ECLAIR
-R:	Simone Ballarin <simone.ballarin@bugseng.com>
+R:	Nicola Vetrini <nicola.vetrini@bugseng.com>
 S:	Supported
 F:	automation/eclair_analysis/
 F:	automation/scripts/eclair
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 14:58:48 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 14:58:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871450.1282440 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXiNP-0001eF-DO; Tue, 14 Jan 2025 14:58:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871450.1282440; Tue, 14 Jan 2025 14:58:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXiNP-0001e8-9y; Tue, 14 Jan 2025 14:58:43 +0000
Received: by outflank-mailman (input) for mailman id 871450;
 Tue, 14 Jan 2025 14:58: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
 <SRS0=iLru=UG=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tXiNO-0001e2-Jr
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 14:58:42 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0a738c4e-d288-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 15:58:41 +0100 (CET)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-5d9f0a6adb4so2933652a12.1
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 06:58:40 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c905f0b3sm636754266b.21.2025.01.14.06.58.39
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 14 Jan 2025 06:58:39 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 0a738c4e-d288-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736866720; x=1737471520; 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=UoLRmHzqLuX1KEnrPA06X9xkODfSUFTM9ow3hNLjjDA=;
        b=nU9JkQEq5x9BpOaRv40i6QBK8e71KISLh4sfvko+taH+JNkiEUVZf9lHIPDNryMc8K
         s7oYl4q6f4wJcfSU33fUwfR4h2B/wH1H5PgRgDSLp+sVjuN3lA5g0YRGshzwyG8EFwnu
         NSP7e0vLRDCtmdbek+l5ctVD513mhrxgxudnI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736866720; x=1737471520;
        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=UoLRmHzqLuX1KEnrPA06X9xkODfSUFTM9ow3hNLjjDA=;
        b=D91htbHjWoJkyCAp3IR3QLQRffyXE/sry7Wcl7euVeukwW6uPS7sEWByqyrMDCSLYb
         CUf8CMrbmuwJn8ndSZqxVdiUsmTtCvWHg4XQ/Q3vJlHRxD+iXnBT4PmMKZ1v61HQt0Iu
         1daPWvjMLIz2SbE2AyB2psisTBsTJfvyVh1Cp9C88Vrd5x9Wu/m4SriqXuifpdqLLTrF
         fkkgNQAS2jYoIVPQRFKorFw2IqHUsby3deg1bY2ZDRhjCLA035OUh0zuxKrMZIwU/zj9
         NIeHTwv9nHypQ2HYOwNgoasWt0L3+qm75uZxoARnHHfGhTIeHih5+PjqUecMWTDdVFDy
         LCbw==
X-Forwarded-Encrypted: i=1; AJvYcCUE1SIGUPEM0F1L7bkZW9ss3muDfZmKf1rrehCTguZVwjGWbaWIUDUEpDo13iv8BbXSZnSndigHJi4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyoLd6fZOD+Z5jJ/2O1nfKTP6OQLkZEpcodLXhxViWZIlElgJ6X
	Ax40dk9i7fVTqhn6fl5kx+fwOzaL/bIaM7iv8bUz4tpIkXcAO3yZ4jrcnAFPGGw=
X-Gm-Gg: ASbGncstHM2AWMsBXoq/EFLU0W65sHEUi4A/PrqfsV5QOJaD9/djfTsp5w0+sST2sSt
	tQ6hsisAhVa7pC5zL1BX4WUVlwX0qeuAVoiMHX47Em0EmF0EApClhep3gVu0BTwWqczpQCJjysu
	PDngL0z5vud4X1nOENO7zb0uD3p7klUPxl3a5Ns2wUl1ifPWj257+qCXheG2yRvC21P8JdJV5HK
	z5WjFda8TkbfYOploOOTSZQQRbejqBwodVBm64WU7C+TN9tDL1S1laiy1/eGg==
X-Google-Smtp-Source: AGHT+IG6mhN/XZYcbgvOjXoI2wpDb4WCMM8HX+x7QIiY7TISjkYK3twnu890dAKxdxFAX1Br6CbMow==
X-Received: by 2002:a17:906:9c8c:b0:ab2:c3ef:ed1e with SMTP id a640c23a62f3a-ab2c3efee73mr1894055966b.10.1736866719884;
        Tue, 14 Jan 2025 06:58:39 -0800 (PST)
Date: Tue, 14 Jan 2025 15:58:38 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>,
	xen-devel@lists.xenproject.org,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v7 1/2] x86/time: introduce command line option to select
 wallclock
Message-ID: <Z4Z7njl5RBznoaxM@macbook.local>
References: <20240913075907.34460-1-roger.pau@citrix.com>
 <20240913075907.34460-2-roger.pau@citrix.com>
 <Z4U6WxtmaqGkqOqe@mail-itl>
 <Z4VS88REbzn5uasy@macbook.local>
 <49a2404f-0c45-4397-9094-a4189131832f@gmail.com>
 <Z4ZKINmJXw5T2dsM@macbook.local>
 <78e09ccb-65b7-4022-b9fc-7874e34c1a99@gmail.com>
 <9288f0de-945f-4056-9934-16b2b1704fb1@gmail.com>
 <Z4ZU_uvCe5lu0aMv@macbook.local>
 <481e1955-783a-48d0-8604-ec8554f50fc5@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <481e1955-783a-48d0-8604-ec8554f50fc5@gmail.com>

On Tue, Jan 14, 2025 at 03:23:21PM +0100, Oleksii Kurochko wrote:
> 
> On 1/14/25 1:13 PM, Roger Pau Monné wrote:
> > On Tue, Jan 14, 2025 at 12:44:39PM +0100, Oleksii Kurochko wrote:
> > > On 1/14/25 12:40 PM, Oleksii Kurochko wrote:
> > > > 
> > > > On 1/14/25 12:27 PM, Roger Pau Monné wrote:
> > > > > On Tue, Jan 14, 2025 at 12:12:03PM +0100, Oleksii Kurochko wrote:
> > > > > > On 1/13/25 6:52 PM, Roger Pau Monné wrote:
> > > > > > > On Mon, Jan 13, 2025 at 05:07:55PM +0100, Marek Marczykowski-Górecki wrote:
> > > > > > > > On Fri, Sep 13, 2024 at 09:59:06AM +0200, Roger Pau Monne wrote:
> > > > > > > > > Allow setting the used wallclock from the command line.  When the option is set
> > > > > > > > > to a value different than `auto` the probing is bypassed and the selected
> > > > > > > > > implementation is used (as long as it's available).
> > > > > > > > > 
> > > > > > > > > The `xen` and `efi` options require being booted as a Xen guest (with Xen guest
> > > > > > > > > supported built-in) or from UEFI firmware respectively.
> > > > > > > > > 
> > > > > > > > > Signed-off-by: Roger Pau Monné<roger.pau@citrix.com>
> > > > > > > > Reviewed-by: Marek Marczykowski-Górecki<marmarek@invisiblethingslab.com>
> > > > > > > Thanks for the review.
> > > > > > > 
> > > > > > > Oleksii, can I get your opinion as Release Manager about whether this
> > > > > > > (and the following patch) would be suitable for committing to staging
> > > > > > > given the current release state?
> > > > > > > 
> > > > > > > It's a workaround for broken EFI implementations that many downstreams
> > > > > > > carry on their patch queue.
> > > > > > Based on your commit message, I understand this as addressing a bug ( but not very critical
> > > > > > as IIUC downstreams have the similar patch on their side ). Therefore, if it has been properly
> > > > > > reviewed and tested, we should consider including it in the current release.
> > > > > IIRC at least Qubes, XenServer and XCP-ng have a patch that achieves
> > > > > the same behavior as proposed here.
> > > > > 
> > > > > > IIUC, setting the wallclock to EFI should align with the behavior Xen had previously.
> > > > > > It might be preferable to use that argument as the default for a while, allowing others to verify the "auto"
> > > > > > value over time. After that, we could consider making "auto" the default.
> > > > > > That said, I am not particularly strict about following this approach.
> > > > > We cannot really set efi as the default, as it would break when
> > > > > booting on legacy BIOS systems.
> > > > > 
> > > > > We could take only patch 1 and leave patch 2 after Xen 4.20 has
> > > > > branched, but at that point I would see little benefit in having just
> > > > > patch 1.
> > > > I don't see a lot of benefit of comitting only the one patch either.
> > > > 
> > > > 
> > > > > I don't have a strong opinion, but downstreams have been complaining
> > > > > about Xen behavior regarding the usage of EFI_GET_TIME, so it might be
> > > > > good to not ship yet another release with such allegedly broken
> > > > > behavior.
> > > > Agree with that. As  I mentioned above I consider it as a bug and based on
> > > > that several mentioned above downstreams have the similar patch I could consider
> > > > that as tested approach so ..
> > > > > Let me know what you think, as I would need a formal Release-Ack if
> > > > > this is to be committed.
> > > > ... R-Acked-by: Oleksii Kurochko<oleksii.kurochko@gmail.com>.
> > > Sorry for the noise.
> > > 
> > > I missed to add that it would also be nice to mention IMO ( that now we have wallclock parameter )
> > > in CHANGELOG so downstreams will receive "notification" that Xen provides a workaround for the mentioned
> > > issue in the patch series.
> > Indeed.  Would you be OK with adding the following chunk to patch 2?
> > 
> > diff --git a/CHANGELOG.md b/CHANGELOG.md
> > index 8507e6556a56..1de1d1eca17f 100644
> > --- a/CHANGELOG.md
> > +++ b/CHANGELOG.md
> > @@ -12,6 +12,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
> >      leaving this to the guest kernel to do in guest context.
> >    - On x86:
> >      - Prefer ACPI reboot over UEFI ResetSystem() run time service call.
> > +   - Prefer CMOS over EFI_GET_TIME as time source.
> >      - Switched the xAPIC flat driver to use physical destination mode for external
> >        interrupts instead of logical destination mode.
> > @@ -24,6 +25,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
> >      - Support for LLC (Last Level Cache) coloring.
> >    - On x86:
> >      - xl suspend/resume subcommands.
> > +   - `wallclock` command line option to select time source.
> 
> What about of adding word 'Add' before `wallclock`?

It's in the "Added" section, so I thought it would be redundant.

> Other LGTM: Acked-By: Oleksii Kurochko<oleksii.kurochko@gmail.com>

Let me know if you would still like me to prepend "Add" to the above
item.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 15:00:57 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 15:00:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871458.1282450 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXiPX-0003CB-Nu; Tue, 14 Jan 2025 15:00:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871458.1282450; Tue, 14 Jan 2025 15:00:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXiPX-0003C4-LP; Tue, 14 Jan 2025 15:00:55 +0000
Received: by outflank-mailman (input) for mailman id 871458;
 Tue, 14 Jan 2025 15:00: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
 <SRS0=iLru=UG=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tXiPW-0003By-Ff
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 15:00:54 +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 59251c2d-d288-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 16:00:52 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-aafc9d75f8bso1075347666b.2
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 07:00:52 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c913430esm640002466b.88.2025.01.14.07.00.48
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 14 Jan 2025 07:00:49 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 59251c2d-d288-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736866852; x=1737471652; 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=UT+J0hyKbo5O63MAKSTu2gx8xHI6peacL+LV+11S1JY=;
        b=rPZdnMt133FV3XroeoSj9ijP34K0oy+p2p4IIUZ9aZ3TVKbBfhgLiTxO72PqfYA9jK
         Rgd0WSdYdUe+X0AH0Jx6fe84LODMLpdrMH0cY0/Z+9gM3/f+QmLm270tiuh+j/DXx4ti
         H6g7R8WUmkO+W6iwpXxCvDgOy789WurpytCb4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736866852; x=1737471652;
        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=UT+J0hyKbo5O63MAKSTu2gx8xHI6peacL+LV+11S1JY=;
        b=byPe+0G5+xZZ1vH8oIIB0hCHZ4Kwi8afB63gn28vNrF14uRkHIO9PJ4Ww+Pum3lDum
         aBdpO5i2wZak7k5UTtp9pUVHLMrxi80pnnP3Z9fMeFyucQ3shmfuKDe8bpZEVxn3jcgl
         1zDoKgLzpIHp09cKQvJScdK56Prv0W4ToZoXJWp7okNphBAmhU4+H64lYCfHo+bq6d4T
         T89PeI0m6qYvfQaKqMyPS+MQWyyI1K6hksb1Gut5Oc60U8aCFGdioxoISikePwGzjQOZ
         j82kVC/E74JWPa2yyxA4so10UZ1pMHm3adg4dF3H4GUXBw5EqheEJtkkWZx9YQQboZA0
         lF3Q==
X-Gm-Message-State: AOJu0YxJ/mxuVIHfFW9UZ+ShcN3ZcFSziBpGb+jmwMEiraOI7eLWJdKl
	dQ/vHxW9yBfVQoeHqfpozZmWtecRLE6uHQ1CF6y57e69gfcHKE5G1iOR6cj9+i0=
X-Gm-Gg: ASbGncvJaxEWII3vtsTv0gcDkJhyX37ilwbkhhGow7f7eObDv3gE5q9dxzFRcmjIlNI
	jPWLFdfdpNNSwSZdqT2K5PrXHG5TeKtJKcxM2eeJpyBsy2bF2cmtlkb7k3ajvtKTNo3gn/zSutA
	ED8/NW71fY8QH+Fl6LUnJiT61FyJiewjJ/O37jxKcZSZFEHR3BRNidrbMNhiRs5RZ3PlUp60igt
	5WkjVowVcotqLKW2Q5K2Jqnt44OoOU4rfb8BaUVv6XkmQrvKSYQK75zEA7Awg==
X-Google-Smtp-Source: AGHT+IHuMTezd1ZH5mS5+k+duj0AyKIKCXUfx92Ckc2VgbuZA6swxtJxxN8jrPZT3/CG4VNE1ASV9A==
X-Received: by 2002:a17:906:f59a:b0:aa6:9503:aa73 with SMTP id a640c23a62f3a-ab2abcb1135mr2491453766b.51.1736866850064;
        Tue, 14 Jan 2025 07:00:50 -0800 (PST)
Date: Tue, 14 Jan 2025 16:00:48 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Nicola Vetrini <nicola.vetrini@bugseng.com>
Cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org,
	michal.orzel@amd.com, xenia.ragiadakou@amd.com,
	ayan.kumar.halder@amd.com, consulting@bugseng.com,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>,
	Simone Ballarin <simone.ballarin@bugseng.com>
Subject: Re: [XEN PATCH] MAINTAINERS: Change reviewer of the ECLAIR
 integration
Message-ID: <Z4Z8IMWuz0UqldN9@macbook.local>
References: <8c370ced911457c883360836bd5afda747426a13.1736856521.git.nicola.vetrini@bugseng.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <8c370ced911457c883360836bd5afda747426a13.1736856521.git.nicola.vetrini@bugseng.com>

On Tue, Jan 14, 2025 at 03:48:54PM +0100, Nicola Vetrini wrote:
> Simone Ballarin is no longer actively involved in reviewing
> the ECLAIR integration for Xen. I am stepping up as a reviewer.
> 
> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>

Acked-by: Roger Pau Monné <roger.pau@citrix.com>

Adding Simone to the Cc list, it would be helpful if he can also
provide an Ack to signal he is OK with begin removed.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 15:02:08 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 15:02:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871467.1282460 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXiQg-0003oM-2F; Tue, 14 Jan 2025 15:02:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871467.1282460; Tue, 14 Jan 2025 15:02:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXiQf-0003oF-Ub; Tue, 14 Jan 2025 15:02:05 +0000
Received: by outflank-mailman (input) for mailman id 871467;
 Tue, 14 Jan 2025 15:02:05 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/Vp6=UG=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tXiQe-0003o8-Uv
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 15:02:04 +0000
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com
 [2a00:1450:4864:20::334])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8383a50f-d288-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 16:02:03 +0100 (CET)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-4361c705434so40126475e9.3
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 07:02:03 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436e2e89df1sm211552115e9.27.2025.01.14.07.02.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 14 Jan 2025 07:02:01 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8383a50f-d288-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736866923; x=1737471723; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=+y5xQkwrI3izGnMbJbaJUFiYT/ZYalok8ANyM4JHUX4=;
        b=XzmnSqZqERTiM4FzMG/Wts57HsZcG0dfxC8JozQ+6987rKGgrsplvoha+E26HSlIwz
         DwmTmAoVEx+aeDdLBMnC44bQ8IC9tTNXASwpq3BdJF+qfIeDTBYlW4lYsp6IOjvpNdUW
         oupmA5fekwO8z3eXorMXDHyEBNwV20D+uzkaMPQ30wdjynwEUb3ys7neYBmnVRQeU/s7
         jFlrcCOeGLU7eb1MEiMOWIZy4nOf+wkFW8cnMTJL//Rm97ru/unE84vOqO3de3Ftmpqr
         NfH4Dfr/B+RymbTxXMaJGgx/gQoKpQgw+ffILIWuylL4MaGGkHi+CpJcOjBTc88lfhf7
         ZwRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736866923; x=1737471723;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=+y5xQkwrI3izGnMbJbaJUFiYT/ZYalok8ANyM4JHUX4=;
        b=jySVA9Hma8oJO4rm6DjfBXnwU5Q67s45DylJSIH6Tl9PpCkY25HovztgqIb/3scYzz
         byrnuTv17YwokQUAsZBG4XeubMi7PyABoZQwASMXd7qUYeuEI29Y5wbbhMj/jq7wKQD/
         HwokQvws7GjG3YjpZbcPvQ7J1pBnuzYj/4UUke9iOqiecsyxcSmwxiP9xDCdqQhEi33q
         9svJP7vLOK9F4h4pzCHqgCE4QNt0O6AyhoMSTauapNQrrkQu8XhlqjtqALLv8h+5Sh/E
         H3f4qie5qf7pIPBZ7OPXmvYPIgBqNDruqBPc9brwWZyia+18/xoq8GzAgFQnoPVEgg6F
         N21w==
X-Forwarded-Encrypted: i=1; AJvYcCVlDn9JvXOqNkVoqFdYvgVLBMyIMtfKE7efuFj43CwqXSd9pEDc9tUupSUp7MFL+75wsVcl6zzRvIM=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz9iDkQkXVOgvSjByG59bufCOSfkxRXSBODSudLjir//s4v1TKK
	8S0qBuVdI4P1MQAN1Z8atQ+2DUkkZ8v0n66A2dtYyFCBU5ePy3YDnaapp7TjKA==
X-Gm-Gg: ASbGncsM8H61VXCVM9CBHep1dNFgXeSUC2UStCShlSX6ExcEfDhcLkJTBevSxFiBuA1
	/3ggbaVaekh0vEX7MMbpqXoY3zO5mljCQIQFFJyXPbLCf6VkClD1YWw78JtAsG6smZqUh/feDaz
	+B2YrTKXYck1qQTSacLxy0ODoeJArBwOYTx5aartU7GGwwATGagINX2JuMjs3xV/pyNtia2Tbfe
	+gEoLYLpbnt/BPGOBtWX2kJ0R2m4Tf0O9ytsDTZ2dklHB6CVlk0FgTEKFGBQAFeAtvs0D4wRf9A
	HbJRHEurcfieDMEeqjTBlbU4sLk3I4A0mp9vA+SwyQ==
X-Google-Smtp-Source: AGHT+IF1FlKQAM4ZXL3OpzuuSEiCSUhuSm7fOBhqbQZdDWsjKy5J1jjwavrxIW4GC3y5o/vn5Ldk4g==
X-Received: by 2002:a05:600c:3114:b0:434:f609:1af7 with SMTP id 5b1f17b1804b1-436e2677361mr224792005e9.4.1736866922667;
        Tue, 14 Jan 2025 07:02:02 -0800 (PST)
Message-ID: <153425e6-a17d-48d2-a1d7-a9b0bf3167dd@suse.com>
Date: Tue, 14 Jan 2025 16:02:01 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 02/18] x86/domain: limit window where curr_vcpu !=
 current on context switch
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xenproject.org
References: <20250108142659.99490-1-roger.pau@citrix.com>
 <20250108142659.99490-3-roger.pau@citrix.com>
 <46cb0ee0-ea9f-4515-abac-058a9aa846e4@suse.com>
 <Z4AIdlx7uWcS3cOP@macbook.local>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <Z4AIdlx7uWcS3cOP@macbook.local>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 09.01.2025 18:33, Roger Pau Monné wrote:
> On Thu, Jan 09, 2025 at 09:59:58AM +0100, Jan Beulich wrote:
>> On 08.01.2025 15:26, Roger Pau Monne wrote:
>>> @@ -2048,8 +2060,6 @@ static void __context_switch(void)
>>>      if ( pd != nd )
>>>          cpumask_clear_cpu(cpu, pd->dirty_cpumask);
>>>      write_atomic(&p->dirty_cpu, VCPU_CPU_CLEAN);
>>> -
>>> -    per_cpu(curr_vcpu, cpu) = n;
>>>  }
>>>  
>>>  void context_switch(struct vcpu *prev, struct vcpu *next)
>>> @@ -2081,16 +2091,36 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
>>>  
>>>      local_irq_disable();
>>>  
>>> -    set_current(next);
>>> -
>>>      if ( (per_cpu(curr_vcpu, cpu) == next) ||
>>>           (is_idle_domain(nextd) && cpu_online(cpu)) )
>>>      {
>>> +        /*
>>> +         * Lazy context switch to the idle vCPU, set current == idle.  Full
>>> +         * context switch happens if/when sync_local_execstate() is called.
>>> +         */
>>> +        set_current(next);
>>>          local_irq_enable();
>>
>> The comment is misleading as far as the first half of the if() condition goes:
>> No further switching is going to happen in that case, aiui.
> 
> Right, I should clarify that comment: this is either a lazy context
> switch, or the return from a lazy state to the previously running
> vCPU.
> 
>>>      }
>>>      else
>>>      {
>>> -        __context_switch();
>>> +        /*
>>> +         * curr_vcpu will always point to the currently loaded vCPU context, as
>>> +         * it's not updated when doing a lazy switch to the idle vCPU.
>>> +         */
>>> +        struct vcpu *prev_ctx = per_cpu(curr_vcpu, cpu);
>>> +
>>> +        if ( prev_ctx != current )
>>> +        {
>>> +            /*
>>> +             * Doing a full context switch to a non-idle vCPU from a lazy
>>> +             * context switched state.  Adjust current to point to the
>>> +             * currently loaded vCPU context.
>>> +             */
>>> +            ASSERT(current == idle_vcpu[cpu]);
>>> +            ASSERT(!is_idle_vcpu(next));
>>> +            set_current(prev_ctx);
>>
>> This feels wrong, as in "current" then not representing what it should represent,
>> for a certain time window. I may be dense, but neither comment not description
>> clarify to me why this might be needed. I can see that it's needed to please the
>> ASSERT() you add to __context_switch(), yet then I might ask why that assertion
>> is put there.
> 
> This is done so that when calling __context_switch() current ==
> curr_vcpu, and map_domain_page() can be used without getting into an
> infinite sync_local_execstate() recursion loop.

Yet it's the purpose of __context_switch() to bring curr_vcpu in sync
with current. IOW both matching up is supposed to be an exit condition
of the function, not an entry one.

Plus, as indicated when we were talking this through yesterday, the
set_current() here make "current" no longer point at what - from the
scheduler's perspective - is (supposed to be) the current vCPU.

Aiui this adjustment is the reason for ...

>>> --- a/xen/arch/x86/traps.c
>>> +++ b/xen/arch/x86/traps.c
>>> @@ -2232,8 +2232,6 @@ void __init trap_init(void)
>>>  
>>>  void activate_debugregs(const struct vcpu *curr)
>>>  {
>>> -    ASSERT(curr == current);
>>> -
>>>      write_debugreg(0, curr->arch.dr[0]);
>>>      write_debugreg(1, curr->arch.dr[1]);
>>>      write_debugreg(2, curr->arch.dr[2]);
>>
>> Why would this assertion go away? If it suddenly triggers, the parameter name
>> would now end up being wrong.
> 
> Well, at the point where activate_debugregs() gets called (in
> paravirt_ctxt_switch_to()), current == previous as a result of this
> change, so the assert is no longer true on purpose on that call
> path.

... this behavior. Which, as said, feels wrong the latest when "curr" was
renamed to no longer suggest it actually is cached "current". At that point
it'll be dubious whose ->arch.dr[] are actually written into the CPU
registers.

Also let's not forget that there's a 2nd call here, where I very much hope
it continues to be "current" that's being passed in.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 15:30:41 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 15:30:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871480.1282470 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXis7-0008KA-54; Tue, 14 Jan 2025 15:30:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871480.1282470; Tue, 14 Jan 2025 15:30:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXis7-0008K3-18; Tue, 14 Jan 2025 15:30:27 +0000
Received: by outflank-mailman (input) for mailman id 871480;
 Tue, 14 Jan 2025 15:30:26 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/Vp6=UG=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tXis6-0008Jv-0b
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 15:30:26 +0000
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com
 [2a00:1450:4864:20::336])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7786b86c-d28c-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 16:30:21 +0100 (CET)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-43634b570c1so40613865e9.0
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 07:30: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
 ffacd0b85a97d-38a8e3853b6sm14995598f8f.44.2025.01.14.07.30.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 14 Jan 2025 07:30:20 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 7786b86c-d28c-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736868621; x=1737473421; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=pcfmpAgzk9ixb/ApUpSQ84RZ2MGK8LnCK+xilUkeWj8=;
        b=P/tUKKCjy6xEk8kPvNHhvKNHsqmAJpppzzyRRdvqFx2KdDnX0/+dpzux7wzEQ3kzUn
         dVLmvUDeDSeHRzQloqhfFeCHs0CkwZ0wlkL0xpusrvTE0oWIFQPap3qOcRfEAz2+x/k8
         0JPbin08VKrroozEp1kUeXs4zCVtXIfPeKTSvo/PKoGcqQquvDGr/PZoxV/P9gS5NeVP
         vPuaK9QTIPCl/e8NmG9cWuZbtkwB9HXEYeE6HW6uqZYnl1JBFogfjbk+PWTnhxkbvkEs
         7iVyP/O9OAC78N1NH0D8XRzt6/vveZSGG72Hz8UGWr22fGiOQNsU09lUdCqRTcXwcmRJ
         XUHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736868621; x=1737473421;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=pcfmpAgzk9ixb/ApUpSQ84RZ2MGK8LnCK+xilUkeWj8=;
        b=PLkvtTj4ZqjabsRfcS1qpoNqhKQkpN36Yuy0M+vOLIbxg2NE0lB6KOnf3Os24jRF7h
         nbzc/3ZezgFMJ4UqLGygm5DpB4ahs+XnEnvbjT7x/tvIWRnAGZ2Sr7A4/WIQA9QKjADw
         VhFiD+mwzU9IujsuhW/a0T3NSowEoqDAp/z4jR6nlOrUz7oQXA7Xab40sUEwbBSJgKxa
         jCZtNoOosUWwVauc+ADV1Cm4JAxnRlwr7QuR0spiI4KngBoKPsXp3CFfONAWHmpEw+Tu
         VUss+LtYCU5VjmRKQNxVfYFwALBaiCqoSVk3d1D8F3ZOk0TFqOA3LbrImG8ZxZd7Mf3S
         sl5Q==
X-Forwarded-Encrypted: i=1; AJvYcCVyu5Q+89wV+JSP1+CZD3DRRu6dak26/Nd8KVLhGw96+FMhjJ0Pcz9Jf4jAAeM3hiBxy6+QS7hqlQo=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy1etMd5LLfCn/gS+GWJi5KoJfNAFj6/Nf5o1Zwqc19T7EYAOin
	WAR8Q7EkcJ50YmDZ7vUR9C+MTJAqZt6U8DFtzdTtqsHWI757AG3kNPa0QTtZCysgsDBKbDpYOFc
	=
X-Gm-Gg: ASbGncv4/0ROdUEpUyqaiAnPe7CLcQV+BtKJ2NG/5rrCqd0WxAng0HLG0OtezTd5mOi
	JZDsXFUhO7WB20+JvxcT28QbMjeNUv3Am0xZWi+y6B0Nds66V1kpLBE94fCwexnfKuxizp3RF7M
	dmemiKNcmiJvn6qspK3b3h5L56zFu3Zo29BTi02d9Ul6P3Tq+KXQj8OKHtmsJBbP/yhgpdS4XYV
	z8LfHoEf4yFZMsXHcpFke0h6DFFxoP6Yrly0PZX12IJ1P7hsTMggD+fPF6bVL6qTXpuHuvZXNDo
	qmxS3WKCKL6VgM+lldHA5Iq2VlnTU76cAfSpBCvUNw==
X-Google-Smtp-Source: AGHT+IFaxdXQ/rbRXKnOeN56OsWuH7yzR0ZP9r53IpXTJHN40rVW4ipVSikA7DUhTnQozVvhwSLZPQ==
X-Received: by 2002:a05:6000:1acd:b0:38a:8b0a:78da with SMTP id ffacd0b85a97d-38a8b0a7b87mr19242800f8f.42.1736868620902;
        Tue, 14 Jan 2025 07:30:20 -0800 (PST)
Message-ID: <7a05d031-d664-47a9-a9c0-5579fe4cfd9f@suse.com>
Date: Tue, 14 Jan 2025 16:30:19 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2.1 06/18] x86/pv: set/clear guest GDT mappings using
 {populate,destroy}_perdomain_mapping()
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xenproject.org
References: <20250108142659.99490-7-roger.pau@citrix.com>
 <20250108151133.858-1-roger.pau@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250108151133.858-1-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 08.01.2025 16:11, Roger Pau Monne wrote:
> The pv_{set,destroy}_gdt() functions rely on the L1 table(s) that contain such
> mappings being stashed in the domain structure, and thus such mappings being
> modified by merely updating the L1 entries.
> 
> Switch both pv_{set,destroy}_gdt() to instead use
> {populate,destory}_perdomain_mapping().

Like for an earlier patch it doesn't really become clear why what is being done
wants / needs doing. I might guess that it's the "stashed in the domain structure"
that you ultimately want to get rid of?

> --- a/xen/arch/x86/pv/descriptor-tables.c
> +++ b/xen/arch/x86/pv/descriptor-tables.c
> @@ -49,23 +49,20 @@ bool pv_destroy_ldt(struct vcpu *v)
>  
>  void pv_destroy_gdt(struct vcpu *v)
>  {
> -    l1_pgentry_t *pl1e = pv_gdt_ptes(v);
> -    mfn_t zero_mfn = _mfn(virt_to_mfn(zero_page));
> -    l1_pgentry_t zero_l1e = l1e_from_mfn(zero_mfn, __PAGE_HYPERVISOR_RO);
>      unsigned int i;
>  
>      ASSERT(v == current || !vcpu_cpu_dirty(v));
>  
> -    v->arch.pv.gdt_ents = 0;

How can this validly go away?

> -    for ( i = 0; i < FIRST_RESERVED_GDT_PAGE; i++ )
> -    {
> -        mfn_t mfn = l1e_get_mfn(pl1e[i]);
> +    if ( v->arch.cr3 )
> +        destroy_perdomain_mapping(v, GDT_VIRT_START(v),
> +                                  ARRAY_SIZE(v->arch.pv.gdt_frames));

How is v->arch.cr3 being non-zero related to the GDT area needing
destroying?

> -        if ( (l1e_get_flags(pl1e[i]) & _PAGE_PRESENT) &&
> -             !mfn_eq(mfn, zero_mfn) )
> -            put_page_and_type(mfn_to_page(mfn));
> +    for ( i = 0; i < ARRAY_SIZE(v->arch.pv.gdt_frames); i++)
> +    {
> +        if ( !v->arch.pv.gdt_frames[i] )
> +            break;
>  
> -        l1e_write(&pl1e[i], zero_l1e);
> +        put_page_and_type(mfn_to_page(_mfn(v->arch.pv.gdt_frames[i])));
>          v->arch.pv.gdt_frames[i] = 0;
>      }
>  }
> @@ -74,8 +71,8 @@ int pv_set_gdt(struct vcpu *v, const unsigned long frames[],
>                 unsigned int entries)
>  {
>      struct domain *d = v->domain;
> -    l1_pgentry_t *pl1e;
>      unsigned int i, nr_frames = DIV_ROUND_UP(entries, 512);
> +    mfn_t mfns[ARRAY_SIZE(v->arch.pv.gdt_frames)];

Having this array is kind of odd - it'll hold all the same values as
frames[], just under a different type. Considering the further copying
done ...

> @@ -90,6 +87,8 @@ int pv_set_gdt(struct vcpu *v, const unsigned long frames[],
>          if ( !mfn_valid(mfn) ||
>               !get_page_and_type(mfn_to_page(mfn), d, PGT_seg_desc_page) )
>              goto fail;
> +
> +        mfns[i] = mfn;
>      }
>  
>      /* Tear down the old GDT. */
> @@ -97,12 +96,9 @@ int pv_set_gdt(struct vcpu *v, const unsigned long frames[],
>  
>      /* Install the new GDT. */
>      v->arch.pv.gdt_ents = entries;
> -    pl1e = pv_gdt_ptes(v);
>      for ( i = 0; i < nr_frames; i++ )
> -    {
>          v->arch.pv.gdt_frames[i] = frames[i];

... here, would it perhaps be an option to change ->arch.pv.gdt_frames[]
to mfn_t[], thus allowing ...

> -        l1e_write(&pl1e[i], l1e_from_pfn(frames[i], __PAGE_HYPERVISOR_RW));
> -    }
> +    populate_perdomain_mapping(v, GDT_VIRT_START(v), mfns, nr_frames);

... that array to be passed into here?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 15:38:12 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 15:38:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871492.1282480 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXizW-0000q7-WA; Tue, 14 Jan 2025 15:38:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871492.1282480; Tue, 14 Jan 2025 15:38:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXizW-0000q0-Rs; Tue, 14 Jan 2025 15:38:06 +0000
Received: by outflank-mailman (input) for mailman id 871492;
 Tue, 14 Jan 2025 15:38: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
 <SRS0=wcbX=UG=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tXizV-0000pu-LX
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 15:38:05 +0000
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com
 [2a00:1450:4864:20::22b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8b024ff0-d28d-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 16:38:03 +0100 (CET)
Received: by mail-lj1-x22b.google.com with SMTP id
 38308e7fff4ca-3002c324e7eso54242061fa.3
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 07:38:03 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-305ff1ec5f1sm18095691fa.114.2025.01.14.07.38.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 14 Jan 2025 07:38:02 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8b024ff0-d28d-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736869083; x=1737473883; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=Q4b34nAxZ7CFnodXRCrt9g3A/ALUH9rexvcutaqZqTM=;
        b=HuN4yiLQTFpLQdh5yC6zRtMQY63zBydRT7e4FO4WmW29w5D5tEFuENhlDFaEXONL25
         P6lCJYwLEHPl0zYYU400Obw5z0d/l5cE6iPKKjS0nJcLKSZpAFSGlg/3fhfX+FNEi4Bb
         BmA0CEJCpzWZWK8sDqcrgF+9G3fyUZ+mlcllEFu0KWWZK6yQ1RZ4Tb1ZRG/Sq/IYd/u4
         2m+VK+xPPshj6yWQEFGlfoA8ZVeeDQGSCe/uTbqSPiNYcx1lO6cenYGNoHdTsAU67Xk/
         4V5/15fEbC6AnoSbARVQjwzQBnBRBKHROGDeXHb7QHyJjNCfX9dCnHAZ9BCAYDnxVn25
         wRxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736869083; x=1737473883;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Q4b34nAxZ7CFnodXRCrt9g3A/ALUH9rexvcutaqZqTM=;
        b=ftTtuuZgLJAHKAgQ6UFLRuOOk0TaNyAxWOqSwoNpp4Ku1cdwEO7c+aqwTG7GeVJxhH
         MsKbg3xWuJBsGw+C0eQY4vU8IwDMJJyr1irS/MTSx6fjrAx+2OfvHNjjCwAsTDtXKH5O
         AhaDCh36fDrSfOCAH2ECvP1Kd2O+tX74xac+qt7B44UlpdixdYOdYYhVb3TvTtA1WUpg
         5+a27VNBf3T/aGNfUCcfrQhHsQCi4YJoQMzniGcJPbVHippeAwT/At6WLBBTYyfSGMuc
         ysXkLjw6aEC8hV7sWSGVIYCRBBdHo87xO27rkTsuuMfIGYMKtXFmLP81JFfQ5/mrccMF
         ChSQ==
X-Forwarded-Encrypted: i=1; AJvYcCWAlugDFZ2fKry+tlgPLorBeMEQae6TOAsIPC0C53ZrmsNWgIQtqUChk068JgiqGWmsHwz53sRoYBI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzTCl443/afqNgLbVcWLclFFb0X9UEhcXJE+x2HcXuRpYa5B12T
	ENp0KGqHrsT1wIrT0V/B7kP41wQsk/xpGYWPTvkXHZ5hv1WHwpgz
X-Gm-Gg: ASbGncu0vDsSX2gM8WZFSqFyQe6KxXUZOqq//T0x0sMRKwHQH33hL0re/zrKWl8vImQ
	SSJQAjkkQ+ERETMj2KK1A01dr8IWx9+UkR1de9NbmQaaYOnGsnB7FfQvFnE5S+5heLHVznQ+f1Y
	ybfIZPovzkJAJTUY+BN1E7MJ93op4Sklr2QsHdA10Wy1SkwlZVO9QC588kVmCpT9h3tE8fjTHQh
	oXZy85daFPS6S1LkXKR7Jyd4tRDcbE3kvFjp+g1bIcfChOKGvkoUQ+Eecu8AOnIdStU8w==
X-Google-Smtp-Source: AGHT+IGdowyEZWIdX6u1oX4/ugzTZwG6SnWifIv9qoxq5GLrBjjUjBEkpRf1y0F+sf/eZhKFB91VcQ==
X-Received: by 2002:a05:651c:1a0c:b0:302:1cdd:73c6 with SMTP id 38308e7fff4ca-305f456851fmr82909581fa.20.1736869082748;
        Tue, 14 Jan 2025 07:38:02 -0800 (PST)
Message-ID: <3822fa19-5b28-44a7-a3ef-af13aca34830@gmail.com>
Date: Tue, 14 Jan 2025 16:38:01 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 1/2] x86/time: introduce command line option to select
 wallclock
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Cc: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, xen-devel@lists.xenproject.org,
 "Daniel P. Smith" <dpsmith@apertussolutions.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>
References: <20240913075907.34460-1-roger.pau@citrix.com>
 <20240913075907.34460-2-roger.pau@citrix.com> <Z4U6WxtmaqGkqOqe@mail-itl>
 <Z4VS88REbzn5uasy@macbook.local>
 <49a2404f-0c45-4397-9094-a4189131832f@gmail.com>
 <Z4ZKINmJXw5T2dsM@macbook.local>
 <78e09ccb-65b7-4022-b9fc-7874e34c1a99@gmail.com>
 <9288f0de-945f-4056-9934-16b2b1704fb1@gmail.com>
 <Z4ZU_uvCe5lu0aMv@macbook.local>
 <481e1955-783a-48d0-8604-ec8554f50fc5@gmail.com>
 <Z4Z7njl5RBznoaxM@macbook.local>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <Z4Z7njl5RBznoaxM@macbook.local>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


On 1/14/25 3:58 PM, Roger Pau Monné wrote:
> On Tue, Jan 14, 2025 at 03:23:21PM +0100, Oleksii Kurochko wrote:
>> On 1/14/25 1:13 PM, Roger Pau Monné wrote:
>>> On Tue, Jan 14, 2025 at 12:44:39PM +0100, Oleksii Kurochko wrote:
>>>> On 1/14/25 12:40 PM, Oleksii Kurochko wrote:
>>>>> On 1/14/25 12:27 PM, Roger Pau Monné wrote:
>>>>>> On Tue, Jan 14, 2025 at 12:12:03PM +0100, Oleksii Kurochko wrote:
>>>>>>> On 1/13/25 6:52 PM, Roger Pau Monné wrote:
>>>>>>>> On Mon, Jan 13, 2025 at 05:07:55PM +0100, Marek Marczykowski-Górecki wrote:
>>>>>>>>> On Fri, Sep 13, 2024 at 09:59:06AM +0200, Roger Pau Monne wrote:
>>>>>>>>>> Allow setting the used wallclock from the command line.  When the option is set
>>>>>>>>>> to a value different than `auto` the probing is bypassed and the selected
>>>>>>>>>> implementation is used (as long as it's available).
>>>>>>>>>>
>>>>>>>>>> The `xen` and `efi` options require being booted as a Xen guest (with Xen guest
>>>>>>>>>> supported built-in) or from UEFI firmware respectively.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Roger Pau Monné<roger.pau@citrix.com>
>>>>>>>>> Reviewed-by: Marek Marczykowski-Górecki<marmarek@invisiblethingslab.com>
>>>>>>>> Thanks for the review.
>>>>>>>>
>>>>>>>> Oleksii, can I get your opinion as Release Manager about whether this
>>>>>>>> (and the following patch) would be suitable for committing to staging
>>>>>>>> given the current release state?
>>>>>>>>
>>>>>>>> It's a workaround for broken EFI implementations that many downstreams
>>>>>>>> carry on their patch queue.
>>>>>>> Based on your commit message, I understand this as addressing a bug ( but not very critical
>>>>>>> as IIUC downstreams have the similar patch on their side ). Therefore, if it has been properly
>>>>>>> reviewed and tested, we should consider including it in the current release.
>>>>>> IIRC at least Qubes, XenServer and XCP-ng have a patch that achieves
>>>>>> the same behavior as proposed here.
>>>>>>
>>>>>>> IIUC, setting the wallclock to EFI should align with the behavior Xen had previously.
>>>>>>> It might be preferable to use that argument as the default for a while, allowing others to verify the "auto"
>>>>>>> value over time. After that, we could consider making "auto" the default.
>>>>>>> That said, I am not particularly strict about following this approach.
>>>>>> We cannot really set efi as the default, as it would break when
>>>>>> booting on legacy BIOS systems.
>>>>>>
>>>>>> We could take only patch 1 and leave patch 2 after Xen 4.20 has
>>>>>> branched, but at that point I would see little benefit in having just
>>>>>> patch 1.
>>>>> I don't see a lot of benefit of comitting only the one patch either.
>>>>>
>>>>>
>>>>>> I don't have a strong opinion, but downstreams have been complaining
>>>>>> about Xen behavior regarding the usage of EFI_GET_TIME, so it might be
>>>>>> good to not ship yet another release with such allegedly broken
>>>>>> behavior.
>>>>> Agree with that. As  I mentioned above I consider it as a bug and based on
>>>>> that several mentioned above downstreams have the similar patch I could consider
>>>>> that as tested approach so ..
>>>>>> Let me know what you think, as I would need a formal Release-Ack if
>>>>>> this is to be committed.
>>>>> ... R-Acked-by: Oleksii Kurochko<oleksii.kurochko@gmail.com>.
>>>> Sorry for the noise.
>>>>
>>>> I missed to add that it would also be nice to mention IMO ( that now we have wallclock parameter )
>>>> in CHANGELOG so downstreams will receive "notification" that Xen provides a workaround for the mentioned
>>>> issue in the patch series.
>>> Indeed.  Would you be OK with adding the following chunk to patch 2?
>>>
>>> diff --git a/CHANGELOG.md b/CHANGELOG.md
>>> index 8507e6556a56..1de1d1eca17f 100644
>>> --- a/CHANGELOG.md
>>> +++ b/CHANGELOG.md
>>> @@ -12,6 +12,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>>>       leaving this to the guest kernel to do in guest context.
>>>     - On x86:
>>>       - Prefer ACPI reboot over UEFI ResetSystem() run time service call.
>>> +   - Prefer CMOS over EFI_GET_TIME as time source.
>>>       - Switched the xAPIC flat driver to use physical destination mode for external
>>>         interrupts instead of logical destination mode.
>>> @@ -24,6 +25,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>>>       - Support for LLC (Last Level Cache) coloring.
>>>     - On x86:
>>>       - xl suspend/resume subcommands.
>>> +   - `wallclock` command line option to select time source.
>> What about of adding word 'Add' before `wallclock`?
> It's in the "Added" section, so I thought it would be redundant.
>
>> Other LGTM: Acked-By: Oleksii Kurochko<oleksii.kurochko@gmail.com>
> Let me know if you would still like me to prepend "Add" to the above
> item.

Oh, then it makes sense. We can go without "Add" then.


~ Oleksii

>
> Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 15:42:30 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 15:42:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871503.1282490 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXj3k-0002hB-Gg; Tue, 14 Jan 2025 15:42:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871503.1282490; Tue, 14 Jan 2025 15:42:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXj3k-0002h4-Cr; Tue, 14 Jan 2025 15:42:28 +0000
Received: by outflank-mailman (input) for mailman id 871503;
 Tue, 14 Jan 2025 15:42:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/Vp6=UG=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tXj3j-0002gy-WC
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 15:42:28 +0000
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com
 [2a00:1450:4864:20::335])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 277ccca6-d28e-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 16:42:26 +0100 (CET)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-43675b1155bso64365295e9.2
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 07:42:26 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436ed48f4b2sm167221445e9.24.2025.01.14.07.42.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 14 Jan 2025 07:42:25 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 277ccca6-d28e-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736869346; x=1737474146; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=eLiDO3ismwtrppCqpxX2FCvdXubF0r5RXeiDtVs58x0=;
        b=ahoK8SlF+fiF58fm2GBGFmvmT2T/5v8ceolWrWQ/MQK12f03xA+PPStw5XLqpCfLuu
         9woUKFpI6Dhsf9rPhTijE1PaPTyPGx4xvJkaru/cxwkVt+ieiYGf/lFiFCTlo9WLJmUe
         L/BAi+ByNCB2jtRV08OZ4Te02OpJZ9DSTWNFQK6+5d4UDjNRDx9EyCEwyaQpBcKNaOJJ
         oLot0LFIhO1kNYRsm5GBtVbcJbGzznqjiNnYjG77CZy8ofxVHIwvwkayfVIvdCNc+TYs
         zs1eixNVseoyEAuNeVoeq3NeMnpct4L0BpuiRcTLcTRbqNgsuiNlfy3+bJ+d1kXI8cLC
         IqrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736869346; x=1737474146;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=eLiDO3ismwtrppCqpxX2FCvdXubF0r5RXeiDtVs58x0=;
        b=MZ7DKgjju6eSBY9cpLERYr/kpeDmifd0ZVm79Uj7uMSt69h+IMMfnbrY4s6WKwNR8y
         Lfgzrtz+Y2VC09nSJVc+M3ZHMsXnfi43/lgGUmZeOF7UWrocQ3uveNGrTrY5PXFE5o2g
         HcHZawO0e2OTEHWG+ok55BdjSxYuuLLqsPIES266eO5gsiGassnGB16OgoUTWKcmT2nO
         YFuQOh1l1D+kJpd+TxPe5rG1lQxr7OuAx/BmzRC5MP/kUAkHIuRIe9koIcqR3MOd9EWS
         xqj8bFgfEsbkeVId6Q+2SXG9YuPgZmHHFlb1dJ8/MQKCIg3tqpe43rytkzSUZui+pHPp
         U0ow==
X-Forwarded-Encrypted: i=1; AJvYcCV1acydnGGEtfDxHNwXVACUDwlMRtYva0ibtCXLqbj4/g1nSM5ucnQWRkjV/AbkgRQ9vKmmIVeHh3M=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyG+QyhGPoS3LwSrbrv3jONugadjrMQyLTsU9IdQJ5XCiIIztSf
	goWc/mGC2C2+efmQe/xgtad1BXtvScMWmSrFenxCqJkyVQeMcdHQbzybYPGDhQ==
X-Gm-Gg: ASbGncvWDjERfhq+8ubusGi6g78iqjrl8UIkgFAXai+a9duVkd+ojeTz9oPZuc7j6dl
	qcEjF7+aO1oSB6ripXj/RVPyNfJzcsqOmU8WOEtQYpnblkjomnbLucscT5EltDd/L2mFVsMj1ls
	98dLee1Akm5gPYe7fc2DlQuH2KQGaIzbUMVhCiwfYTjcXDaa1duWqNQ8bbPaXrzpucgL6FkyvJ6
	CR7Umbren5zQC/8eG82BJawgSyUm/WVqEA+01g3CswT/4ImtzTU7joisj86eqnCuSdOm0XT/XBE
	fQDB3buxGQ9zi3kfAlyKZuI96dIcG5R9RPJn+3Pv/A==
X-Google-Smtp-Source: AGHT+IEFCfbL0d689LAqqHYE0ZD7Sl8QnhEDe8VelXv9il10+7V3TAx3LXCL8BfLlEtcEVWtn/bSPA==
X-Received: by 2002:a05:600c:3b08:b0:436:18e5:6917 with SMTP id 5b1f17b1804b1-436e255ffd6mr250907395e9.0.1736869345636;
        Tue, 14 Jan 2025 07:42:25 -0800 (PST)
Message-ID: <3e6046e1-f224-49e2-aee3-b39170a4f89e@suse.com>
Date: Tue, 14 Jan 2025 16:42:24 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 07/18] x86/pv: update guest LDT mappings using the
 linear entries
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xenproject.org
References: <20250108142659.99490-1-roger.pau@citrix.com>
 <20250108142659.99490-8-roger.pau@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250108142659.99490-8-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 08.01.2025 15:26, Roger Pau Monne wrote:
> The pv_map_ldt_shadow_page() and pv_destroy_ldt() functions rely on the L1
> table(s) that contain such mappings being stashed in the domain structure, and
> thus such mappings being modified by merely updating the require L1 entries.
> 
> Switch pv_map_ldt_shadow_page() to unconditionally use the linear recursive, as
> that logic is always called while the vCPU is running on the current pCPU.
> 
> For pv_destroy_ldt() use the linear mappings if the vCPU is the one currently
> running on the pCPU, otherwise use destroy_mappings().
> 
> Note this requires keeping an array with the pages currently mapped at the LDT
> area, as that allows dropping the extra taken page reference when removing the
> mappings.

I'm confused by the wording of this paragraph: It reads as if you were
changing reference obtaining / dropping, yet it all looks to stay the
same. If I'm not mistaken you use the array to replace the acquiring of
the MFNs in question from the L1 page table entries. If so, I think it
would be nice if this could be described in a more direct way. Perhaps
first and foremost by replacing "allows" and getting rid of "extra".

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 16:11:14 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 16:11:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871516.1282500 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXjVT-0007ik-GX; Tue, 14 Jan 2025 16:11:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871516.1282500; Tue, 14 Jan 2025 16:11:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXjVT-0007id-DZ; Tue, 14 Jan 2025 16:11:07 +0000
Received: by outflank-mailman (input) for mailman id 871516;
 Tue, 14 Jan 2025 16:11: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
 <SRS0=6x8O=UG=gmail.com=milandjokic1995@srs-se1.protection.inumbo.net>)
 id 1tXjVS-0007iX-Nt
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 16:11:06 +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 27a418d1-d292-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 17:11:04 +0100 (CET)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-4361b0ec57aso54560925e9.0
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 08:11:04 -0800 (PST)
Received: from RTRKN418-LIN.domain.local ([89.216.37.146])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38bddbf50a2sm4812812f8f.43.2025.01.14.08.11.02
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 14 Jan 2025 08:11:02 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 27a418d1-d292-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736871064; x=1737475864; 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=NTHO6ORbJHu4Fft/9aF8Dega/+gwwgtxpWn3kQGQUvA=;
        b=URTbAiczX+lhNujMTN8lB0kYEDWp1iMPave02r0cxlR9lUx/722S+McR6lZKRTi4xo
         AEy4hftTD+RGABo6vc2s37GCEPefmwf2Q4BcsX1NVqGMRquDDvHB4I91F6jTEndMsisH
         xT2SUdN9u0TmexzzbYYGoP+LnCoiG7lLnKp5pHk5Tw90GwZOwhQ1onj3YSawlU8vScWx
         R3AVUIwEgfyp2K7wbJVvg33/KKM8pI619vqUILL4YiS5QXIB0UnIRYM/VrjTvsviARoY
         0pKSwxDmIZWX6XVjWBvvjsUmacZocLoc/BoyY5TjjaPyX/qmheRgT3mi4v2U06eKYHgj
         Ns/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736871064; x=1737475864;
        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=NTHO6ORbJHu4Fft/9aF8Dega/+gwwgtxpWn3kQGQUvA=;
        b=iPILosnLomc5KL7anTMd6iNQ86jeEkQ3Yd2fYEGoHZIzIbWrHAvjTaoJwixgyDzB2g
         pvogyLEIPRITnkZzzYV7gPSShnqzY67+a8ufpuWMpbEi6r1JQHKUWkRzYxVAclpVaI1Q
         Riy9iFZiGwCGAKH5wwjx3gmBVtGbppQBLONVjBCevt6UlMT3gvab3Ys4iRIh3i2CxrVc
         wdVRqHjBdENPCwVgsctcdy0FEk0EQAcyP4J4okNpAZEUDchU+vAgoatYUwqoROEwCIB1
         ec3YxEqIqmmxhWTVMb88jdhWZI78MzqsLK1tFwB7hzI1/j+6TPCTUib5Ve5dqJJh4koN
         Emog==
X-Forwarded-Encrypted: i=1; AJvYcCV2EigAOcSM1dEmU8KSbxa1rOKVKSC3ZYKIY3XXC9kiVzeOi5x7c1fThRP4Gd20EUEIYTAaraMSJJc=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzukuy5ZDZ+p2s03d7mO4CgwG0lR5WOgyaVlX1h7KY/FLCxSwzW
	z6J3fBax9nL9E7cIk/FNc4SCdTCWKCCoqUIwY5XRjQSeXeWADYE+
X-Gm-Gg: ASbGncvIcMNP+3/U6hruGwnuVpJZCjVgEt94dreFpWddmh306x+o0frs/990cixwM1j
	/xjSI0j6ftf+kjoOaHlAwnijPN4zTb60LlMjfL8NquuxT99ayZKnKgnujvhjhPogXLl4+qWyPOz
	lZFOF/vbdMonrmUgRQocZWlBDwNKzDbYN9kecMIrDfXGLqv0JQ05EPh8tusIsD0vnvCsiyeQLgK
	rKr7eUyyGQOC7DGjrbAhkwCfa61JHzNQLDw4Pyom/Pee3HndGHvpjRRVWLWPIH/xIY4M9x+ETwF
	hZnWzg==
X-Google-Smtp-Source: AGHT+IEkkv0RUPmhyicxqkBxmhOobZ5p48nMpzZapAIFwHFVu/2/9jKyyv0rb4O/+ZjNNPQ4Ul9LXw==
X-Received: by 2002:a05:600c:4e8c:b0:434:f5c0:3288 with SMTP id 5b1f17b1804b1-436e271d355mr233324995e9.29.1736871063354;
        Tue, 14 Jan 2025 08:11:03 -0800 (PST)
From: Milan Djokic <milandjokic1995@gmail.com>
To: linux-riscv@lists.infradead.org
Cc: paul.walmsley@sifive.com,
	palmer@dabbelt.com,
	aou@eecs.berkeley.edu,
	jgross@suse.com,
	sstabellini@kernel.org,
	oleksandr_tyshchenko@epam.com,
	Slavisa.Petrovic@rt-rk.com,
	Milan.Djokic@rt-rk.com,
	rafael.j.wysocki@intel.com,
	sunilvl@ventanamicro.com,
	takakura@valinux.co.jp,
	linux-kernel@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	iommu@lists.linux.dev
Subject: [PATCH] riscv: Add initial Xen guest support for RISC-V
Date: Tue, 14 Jan 2025 17:09:36 +0100
Message-ID: <e4a649a7fdfc8fcf5f48a0bc4e76e5d546078083.1736868605.git.Slavisa.Petrovic@rt-rk.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Slavisa Petrovic <Slavisa.Petrovic@rt-rk.com>

This patch introduces initial support for running RISC-V as a Xen guest.
It provides the necessary infrastructure and stubs for Xen-specific
operations. Key changes include:

- Modifications to the RISC-V kernel to integrate Xen-specific hypercalls
  and interfaces, with function implementations stubbed for future work.
- Introduction of Xen-specific headers for RISC-V, including event
  handling, hypervisor interaction, and page management. Functions are
  defined but not yet implemented.
- Stub implementations for memory management, grant tables, and context
  switching in the Xen environment, allowing further development and
  integration.

Signed-off-by: Milan Djokic <Milan.Djokic@rt-rk.com>
Signed-off-by: Slavisa Petrovic <Slavisa.Petrovic@rt-rk.com>
---
 arch/riscv/Kbuild                        |   1 +
 arch/riscv/Kconfig                       |  19 +++
 arch/riscv/include/asm/cpu.h             |   1 +
 arch/riscv/include/asm/hypervisor.h      |   9 ++
 arch/riscv/include/asm/irq.h             |   5 +
 arch/riscv/include/asm/sync_bitops.h     |  27 ++++
 arch/riscv/include/asm/xen/events.h      |  28 ++++
 arch/riscv/include/asm/xen/hypercall.h   |   2 +
 arch/riscv/include/asm/xen/hypervisor.h  |   2 +
 arch/riscv/include/asm/xen/interface.h   |   2 +
 arch/riscv/include/asm/xen/page.h        |   3 +
 arch/riscv/include/asm/xen/swiotlb-xen.h |   2 +
 arch/riscv/xen/Makefile                  |   2 +
 arch/riscv/xen/enlighten.c               | 164 +++++++++++++++++++++++
 arch/riscv/xen/grant-table.c             |  57 ++++++++
 arch/riscv/xen/hypercall.S               |  71 ++++++++++
 arch/riscv/xen/p2m.c                     |  76 +++++++++++
 include/xen/interface/io/protocols.h     |   3 +
 include/xen/riscv/hypercall.h            |  71 ++++++++++
 include/xen/riscv/hypervisor.h           |  26 ++++
 include/xen/riscv/interface.h            |  85 ++++++++++++
 include/xen/riscv/page.h                 | 106 +++++++++++++++
 include/xen/riscv/swiotlb-xen.h          |  13 ++
 test.txt                                 |  21 +++
 24 files changed, 796 insertions(+)
 create mode 100644 arch/riscv/include/asm/hypervisor.h
 create mode 100644 arch/riscv/include/asm/sync_bitops.h
 create mode 100644 arch/riscv/include/asm/xen/events.h
 create mode 100644 arch/riscv/include/asm/xen/hypercall.h
 create mode 100644 arch/riscv/include/asm/xen/hypervisor.h
 create mode 100644 arch/riscv/include/asm/xen/interface.h
 create mode 100644 arch/riscv/include/asm/xen/page.h
 create mode 100644 arch/riscv/include/asm/xen/swiotlb-xen.h
 create mode 100644 arch/riscv/xen/Makefile
 create mode 100644 arch/riscv/xen/enlighten.c
 create mode 100644 arch/riscv/xen/grant-table.c
 create mode 100644 arch/riscv/xen/hypercall.S
 create mode 100644 arch/riscv/xen/p2m.c
 create mode 100644 include/xen/riscv/hypercall.h
 create mode 100644 include/xen/riscv/hypervisor.h
 create mode 100644 include/xen/riscv/interface.h
 create mode 100644 include/xen/riscv/page.h
 create mode 100644 include/xen/riscv/swiotlb-xen.h
 create mode 100644 test.txt

diff --git a/arch/riscv/Kbuild b/arch/riscv/Kbuild
index 2c585f7a0b6e..d9b71deed2cd 100644
--- a/arch/riscv/Kbuild
+++ b/arch/riscv/Kbuild
@@ -5,6 +5,7 @@ obj-$(CONFIG_BUILTIN_DTB) += boot/dts/
 obj-$(CONFIG_CRYPTO) += crypto/
 obj-y += errata/
 obj-$(CONFIG_KVM) += kvm/
+obj-$(CONFIG_XEN) += xen/

 obj-$(CONFIG_ARCH_SUPPORTS_KEXEC_PURGATORY) += purgatory/

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index d4a7ca0388c0..13ea75221524 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -1071,6 +1071,25 @@ config PARAVIRT_TIME_ACCOUNTING

 	  If in doubt, say N here.

+config XEN_DOM0
+	def_bool y
+	depends on XEN
+
+config XEN
+	bool "Xen guest support on RISCV"
+	depends on RISCV && OF
+	select PARAVIRT
+	help
+	  Enables support for running Linux as a Xen guest on RISC-V.
+
+	  Xen is a type-1 hypervisor that allows multiple operating systems
+	  to run on the same hardware. Enabling this option allows the kernel
+	  to function as a guest under the Xen hypervisor on RISC-V platforms.
+
+	  Say Y if you want to run this kernel as a guest under Xen on RISC-V.
+
+	  If unsure, say N.
+
 config RELOCATABLE
 	bool "Build a relocatable kernel"
 	depends on MMU && 64BIT && !XIP_KERNEL
diff --git a/arch/riscv/include/asm/cpu.h b/arch/riscv/include/asm/cpu.h
index 28d45a6678ce..fb2aac6a068e 100644
--- a/arch/riscv/include/asm/cpu.h
+++ b/arch/riscv/include/asm/cpu.h
@@ -4,5 +4,6 @@
 #define _ASM_CPU_H

 /* This header is required unconditionally by the ACPI core */
+#include <linux/cpu.h>

 #endif /* _ASM_CPU_H */
diff --git a/arch/riscv/include/asm/hypervisor.h b/arch/riscv/include/asm/hypervisor.h
new file mode 100644
index 000000000000..3a117afe57f0
--- /dev/null
+++ b/arch/riscv/include/asm/hypervisor.h
@@ -0,0 +1,9 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_RISCV_HYPERVISOR_H
+#define _ASM_RISCV_HYPERVISOR_H
+
+#include <asm/xen/hypervisor.h>
+
+void kvm_init_hyp_services(void);
+
+#endif
diff --git a/arch/riscv/include/asm/irq.h b/arch/riscv/include/asm/irq.h
index 7b038f3b7cb0..b14621848eae 100644
--- a/arch/riscv/include/asm/irq.h
+++ b/arch/riscv/include/asm/irq.h
@@ -23,6 +23,11 @@ void riscv_set_intc_hwnode_fn(struct fwnode_handle *(*fn)(void));

 struct fwnode_handle *riscv_get_intc_hwnode(void);

+static inline int nr_legacy_irqs(void)
+{
+	return 0;
+}
+
 #ifdef CONFIG_ACPI

 enum riscv_irqchip_type {
diff --git a/arch/riscv/include/asm/sync_bitops.h b/arch/riscv/include/asm/sync_bitops.h
new file mode 100644
index 000000000000..28e3c64ba852
--- /dev/null
+++ b/arch/riscv/include/asm/sync_bitops.h
@@ -0,0 +1,27 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __ASM_SYNC_BITOPS_H__
+#define __ASM_SYNC_BITOPS_H__
+
+#include <asm/bitops.h>
+#include <asm/cmpxchg.h>
+
+/* sync_bitops functions are equivalent to the SMP implementation of the
+ * original functions, independently from CONFIG_SMP being defined.
+ *
+ * We need them because _set_bit etc are not SMP safe if !CONFIG_SMP. But
+ * under Xen you might be communicating with a completely external entity
+ * who might be on another CPU (e.g. two uniprocessor guests communicating
+ * via event channels and grant tables). So we need a variant of the bit
+ * ops which are SMP safe even on a UP kernel.
+ */
+
+#define sync_set_bit(nr, p)             set_bit(nr, p)
+#define sync_clear_bit(nr, p)           clear_bit(nr, p)
+#define sync_change_bit(nr, p)          change_bit(nr, p)
+#define sync_test_and_set_bit(nr, p)    test_and_set_bit(nr, p)
+#define sync_test_and_clear_bit(nr, p)  test_and_clear_bit(nr, p)
+#define sync_test_and_change_bit(nr, p) test_and_change_bit(nr, p)
+#define sync_test_bit(nr, addr)         test_bit(nr, addr)
+#define arch_sync_cmpxchg               arch_cmpxchg
+
+#endif
diff --git a/arch/riscv/include/asm/xen/events.h b/arch/riscv/include/asm/xen/events.h
new file mode 100644
index 000000000000..a3d0332ca46c
--- /dev/null
+++ b/arch/riscv/include/asm/xen/events.h
@@ -0,0 +1,28 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_RISCV_XEN_EVENTS_H
+#define _ASM_RISCV_XEN_EVENTS_H
+
+#include <asm/ptrace.h>
+#include <asm/atomic.h>
+
+enum ipi_vector {
+	XEN_PLACEHOLDER_VECTOR,
+
+	/* Xen IPIs go here */
+	XEN_NR_IPIS,
+};
+
+static inline int xen_irqs_disabled(struct pt_regs *regs)
+{
+	return 0;
+}
+
+#define xchg_xen_ulong(ptr, val) xchg((ptr), (val))
+
+/* Rebind event channel is supported by default */
+static inline bool xen_support_evtchn_rebind(void)
+{
+	return true;
+}
+
+#endif /* _ASM_RISCV_XEN_EVENTS_H */
diff --git a/arch/riscv/include/asm/xen/hypercall.h b/arch/riscv/include/asm/xen/hypercall.h
new file mode 100644
index 000000000000..0841ba1f0835
--- /dev/null
+++ b/arch/riscv/include/asm/xen/hypercall.h
@@ -0,0 +1,2 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#include <xen/riscv/hypercall.h>
diff --git a/arch/riscv/include/asm/xen/hypervisor.h b/arch/riscv/include/asm/xen/hypervisor.h
new file mode 100644
index 000000000000..05b7c834d0a9
--- /dev/null
+++ b/arch/riscv/include/asm/xen/hypervisor.h
@@ -0,0 +1,2 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#include <xen/riscv/hypervisor.h>
diff --git a/arch/riscv/include/asm/xen/interface.h b/arch/riscv/include/asm/xen/interface.h
new file mode 100644
index 000000000000..9f30b1d7e77c
--- /dev/null
+++ b/arch/riscv/include/asm/xen/interface.h
@@ -0,0 +1,2 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#include <xen/riscv/interface.h>
diff --git a/arch/riscv/include/asm/xen/page.h b/arch/riscv/include/asm/xen/page.h
new file mode 100644
index 000000000000..c8f5b873445b
--- /dev/null
+++ b/arch/riscv/include/asm/xen/page.h
@@ -0,0 +1,3 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#include <xen/riscv/page.h>
+#include <asm/mmu.h>
diff --git a/arch/riscv/include/asm/xen/swiotlb-xen.h b/arch/riscv/include/asm/xen/swiotlb-xen.h
new file mode 100644
index 000000000000..aa3bc339df03
--- /dev/null
+++ b/arch/riscv/include/asm/xen/swiotlb-xen.h
@@ -0,0 +1,2 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#include <xen/riscv/swiotlb-xen.h>
diff --git a/arch/riscv/xen/Makefile b/arch/riscv/xen/Makefile
new file mode 100644
index 000000000000..f6d3a357e4c7
--- /dev/null
+++ b/arch/riscv/xen/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0-only
+obj-y := enlighten.o p2m.o grant-table.o hypercall.o
diff --git a/arch/riscv/xen/enlighten.c b/arch/riscv/xen/enlighten.c
new file mode 100644
index 000000000000..28bd66c288f9
--- /dev/null
+++ b/arch/riscv/xen/enlighten.c
@@ -0,0 +1,164 @@
+// SPDX-License-Identifier: GPL-2.0-only
+#include <xen/xen.h>
+#include <xen/events.h>
+#include <xen/grant_table.h>
+#include <xen/hvm.h>
+#include <xen/interface/vcpu.h>
+#include <xen/interface/xen.h>
+#include <xen/interface/memory.h>
+#include <xen/interface/hvm/params.h>
+#include <xen/features.h>
+#include <xen/platform_pci.h>
+#include <xen/xenbus.h>
+#include <xen/page.h>
+#include <xen/interface/sched.h>
+#include <xen/xen-ops.h>
+#include <asm/xen/hypervisor.h>
+#include <asm/xen/hypercall.h>
+#include <asm/efi.h>
+#include <linux/interrupt.h>
+#include <linux/irqreturn.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_fdt.h>
+#include <linux/of_irq.h>
+#include <linux/of_address.h>
+#include <linux/cpuidle.h>
+#include <linux/cpufreq.h>
+#include <linux/cpu.h>
+#include <linux/console.h>
+#include <linux/pvclock_gtod.h>
+#include <linux/reboot.h>
+#include <linux/time64.h>
+#include <linux/timekeeping.h>
+#include <linux/timekeeper_internal.h>
+#include <linux/acpi.h>
+#include <linux/virtio_anchor.h>
+
+#include <linux/mm.h>
+
+static struct start_info _xen_start_info;
+struct start_info *xen_start_info = &_xen_start_info;
+EXPORT_SYMBOL(xen_start_info);
+
+enum xen_domain_type xen_domain_type = XEN_NATIVE;
+EXPORT_SYMBOL(xen_domain_type);
+
+struct shared_info xen_dummy_shared_info;
+struct shared_info *HYPERVISOR_shared_info = (void *)&xen_dummy_shared_info;
+
+DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu);
+static struct vcpu_info __percpu *xen_vcpu_info;
+
+/* Linux <-> Xen vCPU id mapping */
+DEFINE_PER_CPU(uint32_t, xen_vcpu_id);
+EXPORT_PER_CPU_SYMBOL(xen_vcpu_id);
+
+/* These are unused until we support booting "pre-ballooned" */
+unsigned long xen_released_pages;
+struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata;
+
+static __read_mostly unsigned int xen_events_irq;
+static __read_mostly phys_addr_t xen_grant_frames;
+
+#define GRANT_TABLE_INDEX   0
+#define EXT_REGION_INDEX    1
+
+uint32_t xen_start_flags;
+EXPORT_SYMBOL(xen_start_flags);
+
+int xen_unmap_domain_gfn_range(struct vm_area_struct *vma,
+					int nr, struct page **pages)
+{
+	return 0;
+}
+EXPORT_SYMBOL_GPL(xen_unmap_domain_gfn_range);
+
+static void xen_read_wallclock(struct timespec64 *ts)
+{
+}
+
+static int xen_pvclock_gtod_notify(struct notifier_block *nb,
+					unsigned long was_set, void *priv)
+{
+	return 0;
+}
+
+static struct notifier_block xen_pvclock_gtod_notifier = {
+	.notifier_call = xen_pvclock_gtod_notify,
+};
+
+static int xen_starting_cpu(unsigned int cpu)
+{
+	return 0;
+}
+
+static int xen_dying_cpu(unsigned int cpu)
+{
+	return 0;
+}
+
+void xen_reboot(int reason)
+{
+}
+
+static int xen_restart(struct notifier_block *nb, unsigned long action,
+					void *data)
+{
+	return 0;
+}
+
+static struct notifier_block xen_restart_nb = {
+	.notifier_call = xen_restart,
+	.priority = 192,
+};
+
+static void xen_power_off(void)
+{
+}
+
+static __initdata struct {
+	const char *compat;
+	const char *prefix;
+	const char *version;
+	bool found;
+} hyper_node = {"xen,xen", "xen,xen-", NULL, false};
+
+static int __init fdt_find_hyper_node(unsigned long node, const char *uname,
+					int depth, void *data)
+{
+	return 0;
+}
+
+void __init xen_early_init(void)
+{
+}
+
+static void __init xen_dt_guest_init(void)
+{
+}
+
+static int __init xen_guest_init(void)
+{
+	return 0;
+}
+early_initcall(xen_guest_init);
+
+static int xen_starting_runstate_cpu(unsigned int cpu)
+{
+	return 0;
+}
+
+static int __init xen_late_init(void)
+{
+	return 0;
+}
+late_initcall(xen_late_init);
+
+
+/* empty stubs */
+void xen_arch_pre_suspend(void) { }
+void xen_arch_post_suspend(int suspend_cancelled) { }
+void xen_timer_resume(void) { }
+void xen_arch_resume(void) { }
+void xen_arch_suspend(void) { }
diff --git a/arch/riscv/xen/grant-table.c b/arch/riscv/xen/grant-table.c
new file mode 100644
index 000000000000..9dd0cea74360
--- /dev/null
+++ b/arch/riscv/xen/grant-table.c
@@ -0,0 +1,57 @@
+// SPDX-License-Identifier: GPL-2.0
+/******************************************************************************
+ * grant_table.c
+ *
+ * Granting foreign access to our memory reservation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include <xen/interface/xen.h>
+#include <xen/page.h>
+#include <xen/grant_table.h>
+
+int arch_gnttab_map_shared(xen_pfn_t *frames, unsigned long nr_gframes,
+					unsigned long max_nr_gframes,
+					void **__shared)
+{
+	return 0;
+}
+
+void arch_gnttab_unmap(void *shared, unsigned long nr_gframes)
+{
+}
+
+int arch_gnttab_map_status(uint64_t *frames, unsigned long nr_gframes,
+					unsigned long max_nr_gframes,
+					grant_status_t **__shared)
+{
+	return 0;
+}
+
+int arch_gnttab_init(unsigned long nr_shared, unsigned long nr_status)
+{
+	return 0;
+}
diff --git a/arch/riscv/xen/hypercall.S b/arch/riscv/xen/hypercall.S
new file mode 100644
index 000000000000..a81afd2a11c4
--- /dev/null
+++ b/arch/riscv/xen/hypercall.S
@@ -0,0 +1,71 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#include <linux/linkage.h>
+#include <asm/assembler.h>
+#include <xen/interface/xen.h>
+EXPORT_SYMBOL_GPL(HYPERVISOR_event_channel_op);
+EXPORT_SYMBOL_GPL(HYPERVISOR_grant_table_op);
+EXPORT_SYMBOL_GPL(HYPERVISOR_xen_version);
+EXPORT_SYMBOL_GPL(HYPERVISOR_console_io);
+EXPORT_SYMBOL_GPL(HYPERVISOR_sched_op);
+EXPORT_SYMBOL_GPL(HYPERVISOR_hvm_op);
+EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
+EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
+EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
+EXPORT_SYMBOL_GPL(HYPERVISOR_platform_op_raw);
+EXPORT_SYMBOL_GPL(HYPERVISOR_multicall);
+EXPORT_SYMBOL_GPL(HYPERVISOR_vm_assist);
+EXPORT_SYMBOL_GPL(HYPERVISOR_dm_op);
+EXPORT_SYMBOL_GPL(privcmd_call);
+#define SBI_ECALL 0xE
+
+    .data
+
+#define HYPERCALL_SIMPLE(hypercall) \
+SYM_FUNC_START(HYPERVISOR_##hypercall) \
+    li a6, __HYPERVISOR_##hypercall; \
+    li a7, SBI_ECALL; \
+    mv a5, a4; \
+    mv a4, a3; \
+    mv a3, a2; \
+    mv a2, a1; \
+    mv a1, a0; \
+    li a0, 0; \
+    ecall; \
+    ret; \
+SYM_FUNC_END(HYPERVISOR_##hypercall)
+
+#define HYPERCALL0 HYPERCALL_SIMPLE
+#define HYPERCALL1 HYPERCALL_SIMPLE
+#define HYPERCALL2 HYPERCALL_SIMPLE
+#define HYPERCALL3 HYPERCALL_SIMPLE
+#define HYPERCALL4 HYPERCALL_SIMPLE
+#define HYPERCALL5 HYPERCALL_SIMPLE
+
+    .text
+
+HYPERCALL2(xen_version);
+HYPERCALL3(console_io);
+HYPERCALL3(grant_table_op);
+HYPERCALL2(sched_op);
+HYPERCALL2(event_channel_op);
+HYPERCALL2(hvm_op);
+HYPERCALL2(memory_op);
+HYPERCALL2(physdev_op);
+HYPERCALL3(vcpu_op);
+HYPERCALL1(platform_op_raw);
+HYPERCALL2(multicall);
+HYPERCALL2(vm_assist);
+HYPERCALL3(dm_op);
+
+SYM_FUNC_START(privcmd_call)
+    mv a6, a0
+    li a7, SBI_ECALL
+    mv a5, a4;
+    mv a4, a3;
+    mv a3, a2;
+    mv a2, a1;
+    mv a1, a0;
+    li a0, 0;
+    ecall
+    ret
+SYM_FUNC_END(privcmd_call);
diff --git a/arch/riscv/xen/p2m.c b/arch/riscv/xen/p2m.c
new file mode 100644
index 000000000000..7ce75e52d7c4
--- /dev/null
+++ b/arch/riscv/xen/p2m.c
@@ -0,0 +1,76 @@
+// SPDX-License-Identifier: GPL-2.0-only
+#include <linux/memblock.h>
+#include <linux/gfp.h>
+#include <linux/export.h>
+#include <linux/spinlock.h>
+#include <linux/slab.h>
+#include <linux/types.h>
+#include <linux/dma-mapping.h>
+#include <linux/vmalloc.h>
+#include <linux/swiotlb.h>
+
+#include <xen/xen.h>
+#include <xen/interface/memory.h>
+#include <xen/grant_table.h>
+#include <xen/page.h>
+#include <xen/swiotlb-xen.h>
+
+#include <asm/cacheflush.h>
+#include <asm/xen/hypercall.h>
+#include <asm/xen/interface.h>
+
+struct xen_p2m_entry {
+	unsigned long pfn;
+	unsigned long mfn;
+	unsigned long nr_pages;
+	struct rb_node rbnode_phys;
+};
+
+static rwlock_t p2m_lock;
+struct rb_root phys_to_mach = RB_ROOT;
+EXPORT_SYMBOL_GPL(phys_to_mach);
+
+static int xen_add_phys_to_mach_entry(struct xen_p2m_entry *new)
+{
+
+	return 0;
+}
+
+unsigned long __pfn_to_mfn(unsigned long pfn)
+{
+	return 0;
+}
+EXPORT_SYMBOL_GPL(__pfn_to_mfn);
+
+int set_foreign_p2m_mapping(struct gnttab_map_grant_ref *map_ops,
+					struct gnttab_map_grant_ref *kmap_ops,
+					struct page **pages, unsigned int count)
+{
+	return 0;
+}
+
+int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
+					struct gnttab_unmap_grant_ref *kunmap_ops,
+					struct page **pages, unsigned int count)
+{
+	return 0;
+}
+
+bool __set_phys_to_machine_multi(unsigned long pfn,
+					unsigned long mfn, unsigned long nr_pages)
+{
+	return true;
+}
+EXPORT_SYMBOL_GPL(__set_phys_to_machine_multi);
+
+bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
+{
+	return true;
+}
+EXPORT_SYMBOL_GPL(__set_phys_to_machine);
+
+static int p2m_init(void)
+{
+	return 0;
+}
+arch_initcall(p2m_init);
diff --git a/include/xen/interface/io/protocols.h b/include/xen/interface/io/protocols.h
index 22099bb4079f..6c6317462be0 100644
--- a/include/xen/interface/io/protocols.h
+++ b/include/xen/interface/io/protocols.h
@@ -6,6 +6,7 @@
 #define XEN_IO_PROTO_ABI_X86_64     "x86_64-abi"
 #define XEN_IO_PROTO_ABI_POWERPC64  "powerpc64-abi"
 #define XEN_IO_PROTO_ABI_ARM        "arm-abi"
+#define XEN_IO_PROTO_ABI_RISCV      "riscv-abi"

 #if defined(__i386__)
 # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_X86_32
@@ -15,6 +16,8 @@
 # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_POWERPC64
 #elif defined(__arm__) || defined(__aarch64__)
 # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_ARM
+#elif defined(__riscv)
+# define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_RISCV
 #else
 # error arch fixup needed here
 #endif
diff --git a/include/xen/riscv/hypercall.h b/include/xen/riscv/hypercall.h
new file mode 100644
index 000000000000..f76d8a018f26
--- /dev/null
+++ b/include/xen/riscv/hypercall.h
@@ -0,0 +1,71 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/******************************************************************************
+ * hypercall.h
+ *
+ * Linux-specific hypervisor handling.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#ifndef _ASM_RISCV_XEN_HYPERCALL_H
+#define _ASM_RISCV_XEN_HYPERCALL_H
+
+#include <linux/bug.h>
+
+#include <xen/interface/xen.h>
+#include <xen/interface/sched.h>
+#include <xen/interface/platform.h>
+
+struct xen_dm_op_buf;
+
+long privcmd_call(unsigned int call, unsigned long a1,
+		unsigned long a2, unsigned long a3,
+		unsigned long a4, unsigned long a5);
+int HYPERVISOR_xen_version(int cmd, void *arg);
+int HYPERVISOR_console_io(int cmd, int count, char *str);
+int HYPERVISOR_grant_table_op(unsigned int cmd, void *uop, unsigned int count);
+int HYPERVISOR_sched_op(int cmd, void *arg);
+int HYPERVISOR_event_channel_op(int cmd, void *arg);
+unsigned long HYPERVISOR_hvm_op(int op, void *arg);
+int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
+int HYPERVISOR_physdev_op(int cmd, void *arg);
+int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
+int HYPERVISOR_vm_assist(unsigned int cmd, unsigned int type);
+int HYPERVISOR_dm_op(domid_t domid, unsigned int nr_bufs,
+			 struct xen_dm_op_buf *bufs);
+int HYPERVISOR_platform_op_raw(void *arg);
+static inline int HYPERVISOR_platform_op(struct xen_platform_op *op)
+{
+	return 0;
+}
+int HYPERVISOR_multicall(struct multicall_entry *calls, uint32_t nr);
+
+static inline int
+HYPERVISOR_suspend(unsigned long start_info_mfn)
+{
+	return 0;
+}
+
+#endif /* _ASM_RISCV_XEN_HYPERCALL_H */
diff --git a/include/xen/riscv/hypervisor.h b/include/xen/riscv/hypervisor.h
new file mode 100644
index 000000000000..2c1f9625be80
--- /dev/null
+++ b/include/xen/riscv/hypervisor.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_RISCV_XEN_HYPERVISOR_H
+#define _ASM_RISCV_XEN_HYPERVISOR_H
+
+#include <linux/init.h>
+
+extern struct shared_info *HYPERVISOR_shared_info;
+extern struct start_info *xen_start_info;
+
+#ifdef CONFIG_XEN
+void __init xen_early_init(void);
+#else
+static inline void xen_early_init(void) { return; }
+#endif
+
+#ifdef CONFIG_HOTPLUG_CPU
+static inline void xen_arch_register_cpu(int num)
+{
+}
+
+static inline void xen_arch_unregister_cpu(int num)
+{
+}
+#endif
+
+#endif /* _ASM_RISCV_XEN_HYPERVISOR_H */
diff --git a/include/xen/riscv/interface.h b/include/xen/riscv/interface.h
new file mode 100644
index 000000000000..6769b5b39cba
--- /dev/null
+++ b/include/xen/riscv/interface.h
@@ -0,0 +1,85 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/******************************************************************************
+ * Guest OS interface to RISCV Xen.
+ *
+ */
+
+#ifndef _ASM_RISCV_XEN_INTERFACE_H
+#define _ASM_RISCV_XEN_INTERFACE_H
+
+#include <linux/types.h>
+
+#define uint64_aligned_t uint64_t __aligned(8)
+
+#define __DEFINE_GUEST_HANDLE(name, type) \
+	typedef struct { union { type * p; uint64_aligned_t q; }; }  \
+		__guest_handle_ ## name
+
+#define DEFINE_GUEST_HANDLE_STRUCT(name) \
+	__DEFINE_GUEST_HANDLE(name, struct name)
+#define DEFINE_GUEST_HANDLE(name) __DEFINE_GUEST_HANDLE(name, name)
+#define GUEST_HANDLE(name)        __guest_handle_ ## name
+
+#define set_xen_guest_handle(hnd, val)			\
+	do {						\
+		if (sizeof(hnd) == 8)			\
+			*(uint64_t *)&(hnd) = 0;	\
+		(hnd).p = val;				\
+	} while (0)
+
+#define __HYPERVISOR_platform_op_raw __HYPERVISOR_platform_op
+
+#ifndef __ASSEMBLY__
+/* Explicitly size integers that represent pfns in the interface with
+ * Xen so that we can have one ABI that works for 32 and 64 bit guests.
+ * Note that this means that the xen_pfn_t type may be capable of
+ * representing pfn's which the guest cannot represent in its own pfn
+ * type. However since pfn space is controlled by the guest this is
+ * fine since it simply wouldn't be able to create any sure pfns in
+ * the first place.
+ */
+typedef uint64_t xen_pfn_t;
+#define PRI_xen_pfn "llx"
+typedef uint64_t xen_ulong_t;
+#define PRI_xen_ulong "llx"
+typedef int64_t xen_long_t;
+#define PRI_xen_long "llx"
+/* Guest handles for primitive C types. */
+__DEFINE_GUEST_HANDLE(uchar, unsigned char);
+__DEFINE_GUEST_HANDLE(uint,  unsigned int);
+DEFINE_GUEST_HANDLE(char);
+DEFINE_GUEST_HANDLE(int);
+DEFINE_GUEST_HANDLE(void);
+DEFINE_GUEST_HANDLE(uint64_t);
+DEFINE_GUEST_HANDLE(uint32_t);
+DEFINE_GUEST_HANDLE(xen_pfn_t);
+DEFINE_GUEST_HANDLE(xen_ulong_t);
+
+/* Maximum number of virtual CPUs in multi-processor guests. */
+#define MAX_VIRT_CPUS 1
+
+struct arch_vcpu_info { };
+struct arch_shared_info { };
+
+/* TODO: Move pvclock definitions some place arch independent */
+struct pvclock_vcpu_time_info {
+	u32   version;
+	u32   pad0;
+	u64   tsc_timestamp;
+	u64   system_time;
+	u32   tsc_to_system_mul;
+	s8    tsc_shift;
+	u8    flags;
+	u8    pad[2];
+} __packed; /* 32 bytes */
+
+/* It is OK to have a 12 bytes struct with no padding because it is packed */
+struct pvclock_wall_clock {
+	u32   version;
+	u32   sec;
+	u32   nsec;
+	u32   sec_hi;
+} __packed;
+#endif
+
+#endif /* _ASM_RISCV_XEN_INTERFACE_H */
diff --git a/include/xen/riscv/page.h b/include/xen/riscv/page.h
new file mode 100644
index 000000000000..fe07a9bffa7e
--- /dev/null
+++ b/include/xen/riscv/page.h
@@ -0,0 +1,106 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_RISCV_XEN_PAGE_H
+#define _ASM_RISCV_XEN_PAGE_H
+
+#include <asm/page.h>
+
+#include <linux/pfn.h>
+#include <linux/types.h>
+#include <linux/dma-mapping.h>
+#include <linux/pgtable.h>
+
+#include <xen/xen.h>
+#include <xen/interface/grant_table.h>
+
+/* Xen machine address */
+struct xmaddr {
+	phys_addr_t maddr;
+};
+
+/* Xen pseudo-physical address */
+struct xpaddr {
+	phys_addr_t paddr;
+};
+
+#define XMADDR(x)	((struct xmaddr) { .maddr = (x) })
+#define XPADDR(x)	((struct xpaddr) { .paddr = (x) })
+
+#define INVALID_P2M_ENTRY      (~0UL)
+
+/*
+ * The pseudo-physical frame (pfn) used in all the helpers is always based
+ * on Xen page granularity (i.e 4KB).
+ *
+ * A Linux page may be split across multiple non-contiguous Xen page so we
+ * have to keep track with frame based on 4KB page granularity.
+ *
+ * PV drivers should never make a direct usage of those helpers (particularly
+ * pfn_to_gfn and gfn_to_pfn).
+ */
+
+unsigned long __pfn_to_mfn(unsigned long pfn);
+extern struct rb_root phys_to_mach;
+
+/* Pseudo-physical <-> Guest conversion */
+static inline unsigned long pfn_to_gfn(unsigned long pfn)
+{
+	return 0;
+}
+
+static inline unsigned long gfn_to_pfn(unsigned long gfn)
+{
+	return 0;
+}
+
+/* Pseudo-physical <-> BUS conversion */
+static inline unsigned long pfn_to_bfn(unsigned long pfn)
+{
+	return 0;
+}
+
+static inline unsigned long bfn_to_pfn(unsigned long bfn)
+{
+	return 0;
+}
+
+#define bfn_to_local_pfn(bfn)	bfn_to_pfn(bfn)
+
+/* VIRT <-> GUEST conversion */
+#define virt_to_gfn(v)                                                         \
+	({                                                                     \
+		WARN_ON_ONCE(!virt_addr_valid(v));                              \
+		pfn_to_gfn(virt_to_phys(v) >> XEN_PAGE_SHIFT);                 \
+	})
+#define gfn_to_virt(m)		(__va(gfn_to_pfn(m) << XEN_PAGE_SHIFT))
+
+#define percpu_to_gfn(v)	\
+	(pfn_to_gfn(per_cpu_ptr_to_phys(v) >> XEN_PAGE_SHIFT))
+
+static inline struct xmaddr arbitrary_virt_to_machine(void *vaddr)
+{
+	WARN_ON_ONCE(1);
+	return (struct xmaddr){0};
+}
+
+extern int set_foreign_p2m_mapping(struct gnttab_map_grant_ref *map_ops,
+				   struct gnttab_map_grant_ref *kmap_ops,
+				   struct page **pages, unsigned int count);
+
+extern int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
+					 struct gnttab_unmap_grant_ref *kunmap_ops,
+					 struct page **pages, unsigned int count);
+
+bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn);
+bool __set_phys_to_machine_multi(unsigned long pfn, unsigned long mfn,
+		unsigned long nr_pages);
+
+static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
+{
+	return 0;
+}
+
+bool xen_arch_need_swiotlb(struct device *dev,
+			   phys_addr_t phys,
+			   dma_addr_t dev_addr);
+
+#endif /* _ASM_RISCV_XEN_PAGE_H */
diff --git a/include/xen/riscv/swiotlb-xen.h b/include/xen/riscv/swiotlb-xen.h
new file mode 100644
index 000000000000..97ecd8cbbc2d
--- /dev/null
+++ b/include/xen/riscv/swiotlb-xen.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_RISCV_SWIOTLB_XEN_H
+#define _ASM_RISCV_SWIOTLB_XEN_H
+
+#include <xen/features.h>
+#include <xen/xen.h>
+
+static inline int xen_swiotlb_detect(void)
+{
+	return 0;
+}
+
+#endif /* _ASM_RISCV_SWIOTLB_XEN_H */
diff --git a/test.txt b/test.txt
new file mode 100644
index 000000000000..e54267998982
--- /dev/null
+++ b/test.txt
@@ -0,0 +1,21 @@
+WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
+#120:
+new file mode 100644
+
+WARNING: do not add new typedefs
+#808: FILE: include/xen/riscv/interface.h:15:
++	typedef struct { union { type * p; uint64_aligned_t q; }; }  \
+
+WARNING: please, no spaces at the start of a line
+#1006: FILE: include/xen/riscv/swiotlb-xen.h:10:
++    return 0;$
+
+total: 0 errors, 3 warnings, 810 lines checked
+
+NOTE: For some of the reported defects, checkpatch may be able to
+      mechanically convert to the typical style using --fix or --fix-inplace.
+
+0001-riscv-Add-initial-Xen-guest-support-for-RISC-V.patch has style problems, please review.
+
+NOTE: If any of the errors are false positives, please report
+      them to the maintainer, see CHECKPATCH in MAINTAINERS.
--
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 16:20:14 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 16:20:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871529.1282510 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXjeE-0000y2-FB; Tue, 14 Jan 2025 16:20:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871529.1282510; Tue, 14 Jan 2025 16:20:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXjeE-0000xv-C3; Tue, 14 Jan 2025 16:20:10 +0000
Received: by outflank-mailman (input) for mailman id 871529;
 Tue, 14 Jan 2025 16:20:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/Vp6=UG=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tXjeD-0000xZ-0q
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 16:20:09 +0000
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com
 [2a00:1450:4864:20::334])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6ae88e69-d293-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 17:20:06 +0100 (CET)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-436281c8a38so41018585e9.3
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 08:20:06 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436e2da66d9sm218053575e9.1.2025.01.14.08.20.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 14 Jan 2025 08:20:05 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 6ae88e69-d293-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736871606; x=1737476406; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Twn88yhZHElt+klK+h9O0Ttpc2hs3GRfZNqbUhuX5DE=;
        b=C8IX7uxPSprklmJFWmNWe1rbnhEEnKHpGIs+XaVTqSv09phR8pgmuW26KK7heBDSpS
         YAYrNoPgaJGOpHdIe705yBNmTUBJI/r/m0F7SAFdf4HdQg6lSVwAKzXVjP9PMqP1iHHq
         2t79d8gkfsrMzhJQezVumcUBePSq9Imund6Aa0akVI/s8AuPXrBrmPIfzlSXXZNMo28K
         G7Ii6UkiT/u1Tno77Br/zB6FNVWxiNSJHgdPRGLjIGL+MDd2XE8Xkbcq8JoqZD0yAsvN
         35GHBbAFnKCpAZ82cXcPpHO21YB3KJQTMjZklQqHWRkpxtVCkr5WumUya4ApctEXB0K4
         WafA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736871606; x=1737476406;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Twn88yhZHElt+klK+h9O0Ttpc2hs3GRfZNqbUhuX5DE=;
        b=X8sN9NK4bq+nRXisxkPABHNK61l3gMH5lsvRKQV7O2bCnQPsvvVBftH2FwA0HjqBgs
         d6Pk9CmpuVVaqILn92CyKlV3fhW9zlAUjUI1lwUT4kViyeOvfhLOwr8Z4uHC0gV33nRF
         LNxdZJi+GL0GC205WnNDKxQDYHWI8qhGyvroy98W/6puWPRUml/1iyKrh94KH4FuM5r4
         vmwnIbt5tM3XNAvFaQdcEceFO4tiSHYiXmzgjx/t15rpCdpIvETFipAX5Zw745rISQ1j
         Y/Dp+EwEIKByJ2orDKrtRtUU1/by2dIgFvDiqclROb0qbm9YdHfxJLE2IJ8Yn8Q8m7Vc
         wezA==
X-Forwarded-Encrypted: i=1; AJvYcCVB8EB9H8ODyV3nndSMHCTg+nJwJir1eDIiQhbpMiL/Jj/loUcD7hTTiR0p0vQTscOAgEsV3TQs5kc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzJb6hLpkB+5dNC0NUMgzc0/3CSYkzRDNyHkkI7Ot0ReOJHGcIK
	tSUhUtOJEASZb+a5zkXvSHULglxQ3ysFka68/ze5xEioxB/BYrLYkav2Yx+mYw==
X-Gm-Gg: ASbGncu9ptiXRJy8DasV1DRmmSYbHcF3XnFfDJquhI1gT01ezp0Hf0100I7vpiQjjDc
	pgsvhWm2ZaotQNmJ9e+Gdk7LWcmRi7pIF3VvmCy7+L9fm+NCxuFI8boogcZ5Y70D2T3WGf2DP4H
	XB5IWxcs5IMt3o0lJh0EkgF1gCExB5p3tcSS1caSAp/VZZoleho0CIGOgYA6HRmRhItojHvzAzG
	oCzHLoCxAzFRR5Mrfhze4LQsUi4PclQXQW+U4Fb0WrbtxdxVOnr+oTKwI8mQGiOl5ziqJkRVFCV
	ELVUqsXXeQKOP3KFSNST3hPNdJPPqpoMWLbpceomlQ==
X-Google-Smtp-Source: AGHT+IFd9fa6cj6AvrcIVRf8blnbam9aEbg+KF75J/1rKjObvoJG07sfJdfGML4knS1Z2Nc6zxl08g==
X-Received: by 2002:a5d:59af:0:b0:385:f677:859b with SMTP id ffacd0b85a97d-38a872f7fbdmr24891945f8f.10.1736871606248;
        Tue, 14 Jan 2025 08:20:06 -0800 (PST)
Message-ID: <8064a526-3525-4c48-8926-6ea99a8312a6@suse.com>
Date: Tue, 14 Jan 2025 17:20:04 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 00/18] x86: adventures in Address Space Isolation
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>, Tim Deegan <tim@xen.org>,
 xen-devel@lists.xenproject.org
References: <20250108142659.99490-1-roger.pau@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250108142659.99490-1-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 08.01.2025 15:26, Roger Pau Monne wrote:
> Hello,
> 
> The aim of this series is to introduce the functionality required to
> create linear mappings visible to a single pCPU.
> 
> Doing so requires having a per-vCPU root page-table (L4), and hence
> requires shadowing the guest selected L4 on PV guests.  As follow ups
> (and partially to ensure the per-CPU mappings work fine) the CPU stacks
> are switched to use per-CPU mappings, so that remote stack contents are
> not by default mapped on all page-tables (note: for this to be true the
> directmap entries for the stack pages would need to be removed also).
> 
> There's one known shortcoming with the presented code: migration of PV
> guests using per-vCPU root page-tables is not working.  I need to
> introduce extra logic to deal with PV shadow mode when using unique root
> page-tables.  I don't think this should block the series however, such
> missing functionality can always be added as follow up work.
> paging_domctl() is adjusted to reflect this restriction.
> 
> The main differences compared to v1 are the usage of per-vCPU root page
> tables (as opposed to per-pCPU), and the usage of the existing perdomain
> family of functions to manage the mappings in the per-domain slot, that
> now becomes per-vCPU.
> 
> All patches until 17 are mostly preparatory, I think there's a nice
> cleanup and generalization of the creation and managing of per-domain
> mappings, by no longer storing references to L1 page-tables in the vCPU
> or domain struct.

Since you referred me to the cover letter, I've looked back here after
making some more progress with the series. Along with my earlier comment
towards the need or ultimate goal, ...

> Patch 13 introduces the command line option, and would need discussion
> and integration with the sparse direct map series.  IMO we should get
> consensus on how we want the command line to look ASAP, so that we can
> basic parsing logic in place to be used by both the work here and the
> direct map removal series.
> 
> As part of this series the map_domain_page() helpers are also switched
> to create per-vCPU mappings (see patch 15), which converts an existing
> interface into creating per-vCPU mappings.  Such interface can be used
> to hide (map per-vCPU) further data that we don't want to be part of the
> direct map, or even shared between vCPUs of the same domain.  Also all
> existing users of the interface will already create per-vCPU mappings
> without needing additional changes.
> 
> Note that none of the logic introduced in the series removes entries for
> the directmap, so even when creating the per-CPU mappings the underlying
> physical addresses are fully accessible when using it's direct map
> entries.
> 
> I also haven't done any benchmarking.  Doesn't seem to cripple
> performance up to the point that XenRT jobs would timeout before
> finishing, that the only objective reference I can provide at the
> moment.
> 
> The series has been extensively tested on XenRT, but that doesn't cover
> all possible use-cases, so it's likely to still have some rough edges,
> handle with care.
> 
> Thanks, Roger.
> 
> Roger Pau Monne (18):
>   x86/mm: purge unneeded destroy_perdomain_mapping()
>   x86/domain: limit window where curr_vcpu != current on context switch
>   x86/mm: introduce helper to detect per-domain L1 entries that need
>     freeing
>   x86/pv: introduce function to populate perdomain area and use it to
>     map Xen GDT
>   x86/mm: switch destroy_perdomain_mapping() parameter from domain to
>     vCPU
>   x86/pv: set/clear guest GDT mappings using
>     {populate,destroy}_perdomain_mapping()
>   x86/pv: update guest LDT mappings using the linear entries
>   x86/pv: remove stashing of GDT/LDT L1 page-tables
>   x86/mm: simplify create_perdomain_mapping() interface
>   x86/mm: switch {create,destroy}_perdomain_mapping() domain parameter
>     to vCPU
>   x86/pv: untie issuing FLUSH_ROOT_PGTBL from XPTI
>   x86/mm: move FLUSH_ROOT_PGTBL handling before TLB flush
>   x86/spec-ctrl: introduce Address Space Isolation command line option
>   x86/mm: introduce per-vCPU L3 page-table
>   x86/mm: introduce a per-vCPU mapcache when using ASI
>   x86/pv: allow using a unique per-pCPU root page table (L4)
>   x86/mm: switch to a per-CPU mapped stack when using ASI
>   x86/mm: zero stack on context switch
> 
>  docs/misc/xen-command-line.pandoc    |  24 +++
>  xen/arch/x86/cpu/mcheck/mce.c        |   4 +
>  xen/arch/x86/domain.c                | 157 +++++++++++----
>  xen/arch/x86/domain_page.c           | 105 ++++++----
>  xen/arch/x86/flushtlb.c              |  28 ++-
>  xen/arch/x86/hvm/hvm.c               |   6 -
>  xen/arch/x86/include/asm/config.h    |  16 +-
>  xen/arch/x86/include/asm/current.h   |  58 +++++-
>  xen/arch/x86/include/asm/desc.h      |   6 +-
>  xen/arch/x86/include/asm/domain.h    |  50 +++--
>  xen/arch/x86/include/asm/flushtlb.h  |   2 +-
>  xen/arch/x86/include/asm/mm.h        |  15 +-
>  xen/arch/x86/include/asm/processor.h |   5 +
>  xen/arch/x86/include/asm/pv/mm.h     |   5 +
>  xen/arch/x86/include/asm/smp.h       |  12 ++
>  xen/arch/x86/include/asm/spec_ctrl.h |   4 +
>  xen/arch/x86/mm.c                    | 291 +++++++++++++++++++++------
>  xen/arch/x86/mm/hap/hap.c            |   2 +-
>  xen/arch/x86/mm/paging.c             |   6 +
>  xen/arch/x86/mm/shadow/hvm.c         |   2 +-
>  xen/arch/x86/mm/shadow/multi.c       |   2 +-
>  xen/arch/x86/pv/descriptor-tables.c  |  47 ++---
>  xen/arch/x86/pv/dom0_build.c         |  12 +-
>  xen/arch/x86/pv/domain.c             |  57 ++++--
>  xen/arch/x86/pv/mm.c                 |  43 +++-
>  xen/arch/x86/setup.c                 |  32 ++-
>  xen/arch/x86/smp.c                   |  39 ++++
>  xen/arch/x86/smpboot.c               |  26 ++-
>  xen/arch/x86/spec_ctrl.c             | 205 ++++++++++++++++++-
>  xen/arch/x86/traps.c                 |  25 ++-
>  xen/arch/x86/x86_64/mm.c             |   7 +-
>  xen/common/smp.c                     |  10 +
>  xen/common/stop_machine.c            |  10 +
>  xen/include/xen/smp.h                |   8 +
>  34 files changed, 1052 insertions(+), 269 deletions(-)

... this diffstat (even after subtracting out the contribution of the last two
patches in the series) doesn't really look like a cleanup / simplification.
Things becoming slightly slower (because of the L1 no longer directly available
to modify) may, otoh, not be a significant issue, if we assume that GDT/LDT
manipulation isn't normally a very frequent operation.

IOW my earlier request stands: Can you please try to make more clear (in the
patch descriptions) what exactly the motivation for these changes is? Just
doing things differently with more code overall can't be it, I don't think.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 16:27:36 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 16:27:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871540.1282519 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXjlJ-0001mH-5E; Tue, 14 Jan 2025 16:27:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871540.1282519; Tue, 14 Jan 2025 16:27:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXjlJ-0001mA-2C; Tue, 14 Jan 2025 16:27:29 +0000
Received: by outflank-mailman (input) for mailman id 871540;
 Tue, 14 Jan 2025 16:27:28 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/Vp6=UG=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tXjlI-0001m4-27
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 16:27:28 +0000
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com
 [2a00:1450:4864:20::32b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7038a62f-d294-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 17:27:26 +0100 (CET)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-436202dd7f6so65315295e9.0
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 08:27:25 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436e9e62116sm179020555e9.35.2025.01.14.08.27.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 14 Jan 2025 08:27:24 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 7038a62f-d294-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736872045; x=1737476845; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=YHrfyOk1ENYEzmtT86LPgo2XXs5I/hTYURLr4R/eJE4=;
        b=AOknAaNSx7QAuQY5SBTLvI1F68cRo1mqegVqCBiQWCIxB7b4jlaMedVYyT4h5jIg8X
         HHhsDAF51USbUjlMxk4m56kx7PTokuEM9LSXZ8tT3wNRAjlSY5NGpdi6qq0nsxqnqYZ/
         D8VBb1WhV5aInCd2bZJZoUWfFOOnV3Wi7eMfuQEwuXY/COvAO6Xrk33o+f0xNBqcR6Tm
         wFqIrn+Yk9nkvvQhfF7xsmRplxjOCM4xo7AHl9o0rvwkJCnEomUhzDUh86Cs9pUVvhzw
         tdb0TNu3crpsaI2X5zVoss5GgmWsH+MlmPUSGrWRL4KAv/T04J74cMSBaKO8OC5K5xLm
         bVhw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736872045; x=1737476845;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=YHrfyOk1ENYEzmtT86LPgo2XXs5I/hTYURLr4R/eJE4=;
        b=M3GqQqt0mLkmRnLFxY00y1bk66CZ6bOCU7dwzWVcXQuL7OdUMRETXTkNPzfyDe9CbK
         W+/WN8/jl1z85fePTDvAbyGhnWrLg3SerNN8XIAL5cER3P9GNGCa/oW+d7nodYUUg0GT
         fL2AKfXaNPrPUsIFQ6VaarJa/hzcTU/y84B/bKJh1W1acBOBQszsd0l6PFB5fNv5GnXS
         YjZaRh2VYEOVvJntFLLQfXGs+dRrHwnMAL7vPSnDfDsR5UoyJPNK3hycDkJyrk/oXOtn
         mNkC0DLEfdqB7TaM6ZHKI0xGNsSNXjrskrQKq9yYix5fdYRyM0yf4cdNQOu3fD8HAAl5
         V20A==
X-Forwarded-Encrypted: i=1; AJvYcCVHSxyz8pAEe8CIxMlqmkW2FYGeSvBa0kwaxwEjV5xQC8I1T0XtlE8sAD48FiRJ66ti+/voCs6Jvtc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxCrs5XT9mV6n8HKbczVG37oBJu9+dyCDtUgwcUpwa5LSAMFv0o
	D82S7byy1hESY0AmuzFjC3ZO5iDtwYmSt1oimjj4h7oFP4aavr9Fj20DSKHUQw==
X-Gm-Gg: ASbGncuLyXYM3SftKvi4W6kmrBRwp6kkf1FjRt0DQDixdpRU7z5fnklE9pl6NtcNLG/
	EQhdWqhItI7XrMW7knA8hB/t8cmlp48wgxT3clAJ/hpccLgk08gbPuV22dRrq6lbQeQ067nEE91
	JKzHQgg6XW32vh/m+sTI5+/98rs7qeKbkjGbRNT8FrfmLW9GZuzQ1BgCUSmg1mkT2fi2C5J04Zg
	sykuz8FYiZpGh1+JSea+vFFWK55byEz6+6TPcwFUP/T3AuLS+wY3xaDbTL9svwnEw495mFhoh9T
	JwTr8Hk6IhAwhyUOTUmeoV57MaEuTdRAYypLPZH7oQ==
X-Google-Smtp-Source: AGHT+IEFP/EDS5aAPJEmQXt0Svz4TaXuDrmkYU0KaLgSJHo+7kTsbp9W0+QFlr6Zu61PO9/LNQ/CVw==
X-Received: by 2002:a05:6000:1542:b0:38a:a047:6c0b with SMTP id ffacd0b85a97d-38aa0476d5amr14447163f8f.35.1736872044753;
        Tue, 14 Jan 2025 08:27:24 -0800 (PST)
Message-ID: <e42f9215-b65e-44cf-8b57-1bd782bf1d52@suse.com>
Date: Tue, 14 Jan 2025 17:27:23 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 10/18] x86/mm: switch
 {create,destroy}_perdomain_mapping() domain parameter to vCPU
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xenproject.org
References: <20250108142659.99490-1-roger.pau@citrix.com>
 <20250108142659.99490-11-roger.pau@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250108142659.99490-11-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 08.01.2025 15:26, Roger Pau Monne wrote:
> In preparation for the per-domain area being per-vCPU.  This requires moving
> some of the {create,destroy}_perdomain_mapping() calls to the domain
> initialization and tear down paths into vCPU initialization and tear down.

Am I confused or DYM "s/ to / from /"?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 16:35:55 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 16:35:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871549.1282529 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXjtG-0003YE-SM; Tue, 14 Jan 2025 16:35:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871549.1282529; Tue, 14 Jan 2025 16: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 <xen-devel-bounces@lists.xenproject.org>)
	id 1tXjtG-0003Y7-Pu; Tue, 14 Jan 2025 16:35:42 +0000
Received: by outflank-mailman (input) for mailman id 871549;
 Tue, 14 Jan 2025 16:35:41 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/Vp6=UG=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tXjtF-0003Y1-8A
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 16:35:41 +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 959ba7ca-d295-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 17:35:37 +0100 (CET)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-436a39e4891so40005625e9.1
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 08:35:37 -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
 5b1f17b1804b1-436e9e03f49sm178365645e9.19.2025.01.14.08.35.36
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 14 Jan 2025 08:35:36 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 959ba7ca-d295-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736872537; x=1737477337; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=eLI6m1UyCV7Fxc+m0Jv39LxsjApB+SjT9xf81IjrwbI=;
        b=P4PJFS1BnOuUOuz+5fFTu2TYU2LPiw8Ktx0sGB5mpYX0a8QbqMk7gBCNW8zATn/Wpi
         CcwhZ8cZ3v9lwWX7B1u73kUnXuWtvjGOpWDAiG9Y/vHYK67PNVGgDlLLKvpDb5P7wxLN
         s8eemn3MTnZva7hvDgtnaKZCjT6my9T6l6Hqrplj/8H+r5I2LP2WSRGamj21VDOJjJgQ
         IbPKmtJ6m51kgaAcO5wsf+9kZdaSaxGPZmThtlLhSDC5nlil1DRImiQU/tIbyBKaXlhD
         i0anj3iJPnRVZRgvrMK20NOhcMGyAzi0aot/v4yUDz8ZNcjVR674d6ykJXyMTDzO6+fv
         nQag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736872537; x=1737477337;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=eLI6m1UyCV7Fxc+m0Jv39LxsjApB+SjT9xf81IjrwbI=;
        b=tX0LQjAOxLjH+nhDGzF/sUL/ZU4/Jgas9Aa+JDDPXx3e+H0q3EOtpHD8xKVX37AWYQ
         botGR1VTWTLYPeDQ84WDMgpROxmK3NIXyiyNPZ0b5Y1qNgWSbKlT1U1sNkmNUCjvWTwP
         3c8MN97tMd9CUaFDT9cFpk1iDLpj+4+LYiSarNZnuWfVfQotoIU6/YUE+nf3Cdm0Bnfc
         IeziC1Hj50OQZdi6TGDo+NvIDS2CjinFn8xdTkAOfVKNBaJLpdr1iEn76FuEVpdIRI6Y
         LfTs8qvDg5rMJn79ZQfjPQS2mgateAYRpksjMV9NsjCpzF5vqu/CDeuAhSKPJTkTdKDS
         1fLQ==
X-Forwarded-Encrypted: i=1; AJvYcCUGgjcJthP6fANHD9b+4IV43PKakfIRqn73femJSFE890Jw6EdeuHJz40MJtimCB8qBSyR6mlcK3QE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyWnFYlbT8rzY78g4uAhBJNalIt7bWg80c3F7jCegCMzTxqsrBp
	i5PZysoJvnIK4p02Yhf1EYpHS2pWk2ovZJdvM5XCPzH8H2u2FXIVPEKb0A1QFQ==
X-Gm-Gg: ASbGncuuNeuuV0mdxvVjEl+WCTMahdIaxSkjzx0aMjlZFzk533/3L3t+O6ItpUFG3cY
	tnZUQaPKyswXbQOuQp+/MZ2gxb/WGzp+EkRBbuN3gGtgGusUtoHg1sYwM1j6MM64w4Woak2Q1wF
	qEbsSR4p0OTr5jmQkvwNllb0qJ6+ejlUitw70lmjIN8N/dmnIXwsW3OeEXwRy03aWeoNe2NE1cj
	UwYUwkDmT/mSGZZcsgAVm85H4pMd2LaM1RzEysz5qBKsFagpHRgsG/KkfH7/S7u8Z+or5bzBDQP
	pUiVbntCIo+dxPAR8DbLduXNOoYUgvZj5KMCTZD3VA==
X-Google-Smtp-Source: AGHT+IFWrEjVUgojsr4W9QTXEJ1E6lgio1O8cSKKVgOuYzWq+8dbeA+FOdkGxyqk2SF2cHBXDiT8hg==
X-Received: by 2002:a05:600c:354e:b0:431:5aea:95f with SMTP id 5b1f17b1804b1-436e26a175cmr281915275e9.16.1736872536961;
        Tue, 14 Jan 2025 08:35:36 -0800 (PST)
Message-ID: <ca1bb9dc-a63f-4704-98bb-351f81aa6718@suse.com>
Date: Tue, 14 Jan 2025 17:35:35 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v2 01/10] x86: Add architectural LBR definitions
To: Tu Dinh <ngoc-tu.dinh@vates.tech>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Juergen Gross <jgross@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20250102084413.102-1-ngoc-tu.dinh@vates.tech>
 <20250102084413.102-2-ngoc-tu.dinh@vates.tech>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250102084413.102-2-ngoc-tu.dinh@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 02.01.2025 09:45, Tu Dinh wrote:
> --- a/xen/arch/x86/include/asm/msr-index.h
> +++ b/xen/arch/x86/include/asm/msr-index.h
> @@ -112,6 +112,8 @@
>  #define  MCU_OPT_CTRL_GDS_MIT_DIS           (_AC(1, ULL) <<  4)
>  #define  MCU_OPT_CTRL_GDS_MIT_LOCK          (_AC(1, ULL) <<  5)
>  
> +#define MSR_LER_INFO                        0x000001e0
> +
>  #define MSR_RTIT_OUTPUT_BASE                0x00000560
>  #define MSR_RTIT_OUTPUT_MASK                0x00000561
>  #define MSR_RTIT_CTL                        0x00000570
> @@ -193,6 +195,16 @@
>  #define MSR_UARCH_MISC_CTRL                 0x00001b01
>  #define  UARCH_CTRL_DOITM                   (_AC(1, ULL) <<  0)
>  
> +/* Architectural LBR state MSRs */
> +#define MSR_LBR_INFO(n)                     (0x00001200 + (n))
> +#define MSR_LBR_CTL                         0x000014ce
> +#define  LBR_CTL_VALID                      _AC(0x7f000f, ULL)

While I can see that such a value may be useful at some point, I think it wants
introducing when needed and composing of definitions for the individual bits.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 16:38:40 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 16:38:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871557.1282539 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXjw6-000479-9x; Tue, 14 Jan 2025 16:38:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871557.1282539; Tue, 14 Jan 2025 16:38:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXjw6-000472-7J; Tue, 14 Jan 2025 16:38:38 +0000
Received: by outflank-mailman (input) for mailman id 871557;
 Tue, 14 Jan 2025 16:38: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 <SRS0=/Vp6=UG=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tXjw5-00046w-9S
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 16:38:37 +0000
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com
 [2a00:1450:4864:20::431])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 002fb163-d296-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 17:38:36 +0100 (CET)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-385e27c75f4so4083943f8f.2
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 08:38:36 -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
 ffacd0b85a97d-38a8e37ce18sm15696788f8f.14.2025.01.14.08.38.35
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 14 Jan 2025 08:38:35 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 002fb163-d296-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736872716; x=1737477516; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=33cG8TAy1yXoE6WfMcHrDS9CszqIIS5Qlc7uPt+BH2U=;
        b=KXw9S3WJWw6e1fz0qMP1ZS7IYUyYglB7v5D4oBUHtUGVH71v9M2DsvTLkhoHc9w1Xz
         SakIjehEDFoNdmy7Hp/mRX0aa7eP28REYBWjn+i7pnydkE3h3a4ii9jURUrylCFD7qTN
         i4IjvNEJ8VGxc4i/Yl53ctB2dmnoo0Rw7VFXzIBJjYibOyWRwFuxi4yBv2JE4ukRccc4
         y8MUGQ7iM3LiW46FU38UxS3ILW5jTIL18uZQjGItoXqbVEjY3/h0c48mlx7/WCLG6dL3
         NMUQM5419skJ/OtCz39hgl0juzjMZj56fCmaHmeJSdwsJqApj5ynHJmfvpcWpDhpN23r
         IMRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736872716; x=1737477516;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=33cG8TAy1yXoE6WfMcHrDS9CszqIIS5Qlc7uPt+BH2U=;
        b=quNDeDRwlxXC3Sr6234W9thAbKn4SeU4rcfD5eV92r5U94Sm+alomOxU1q8lwHuzVu
         ko87sRY6okk6XAFXB6L3pF22JAqa/qxipxVbMQfLUCcAhdmqPL+Q/d+zbn2mlPEcanhm
         9MQf9ogZgeaEe6PguhT3pqmALk2VTozmocipkWhX0azBOI0d0IeUJXrsRBjzwXubiJNX
         dutyo9lz3vINAHoaqiN81c++RmSDsOiIKFk5dkUSTLRyeJ8s7ssCgTDC0cDC12QULHUk
         VlIO4S+HJZqtSGnCj1gCJRA8fk6Gd5xnOS8XnBm4KIougSSh6IQtz+tcoRLBECIr00oe
         4taA==
X-Forwarded-Encrypted: i=1; AJvYcCX5OOGyhujbqlzZ87PS9d0IY0NU11xzS+pgaNTqsTysMxVYWNzQM55eRsCZ7/WSDs495v7RPiX2YNk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyKJjopssFIwT5kbDskQh6r1gzqnPHHJCfCcAeFb9cRCu6k2kS5
	+oGPz1I1v5sWzl2cajH7H2+49cD8GlGk+D/ZcL2Bw71wZn2E+9Bsu+1CpBtD8Q==
X-Gm-Gg: ASbGnctgL+iYRllFW7Pa7qnxj1+1K3LsDImPE54P7ohGgk2xoVoSZrRxaxu4lrtcxpP
	p+y1Uw0w8eIqWLnBSZ74xgX18UgwrEzzBn/6Af6AUkTE7j2aVn7jOx+tmyDbQTF7IaLD2J/xWG+
	mC9KqJK9T/LbAeA5Q8ByhOBW0engrL9b0KsBQaGvD3Efca+R57Z1BJadehYtSzOH60db+i81U0R
	N9xoIqMUB/BTAv7fczBQrIxb1HqWSmCfcHz8tWGjV3rUcr5zcS1ukA6kc0/0l4xFWc2P2zq4iFT
	C4IXAVZrmv4NxTjzcdxk01xeH6Krflup2tM0lJFFoQ==
X-Google-Smtp-Source: AGHT+IHym6q2Rw+sf3nG9Fu23vu/8FfExuXg0AeUy5Hy8vAaNFPRlhPLLoUQ7U553RxSmV055y/qtQ==
X-Received: by 2002:a05:6000:4a11:b0:385:e1f5:476f with SMTP id ffacd0b85a97d-38a873305bemr25457149f8f.39.1736872715735;
        Tue, 14 Jan 2025 08:38:35 -0800 (PST)
Message-ID: <ef78ac4e-8cb7-48a9-bff8-c1c17411246a@suse.com>
Date: Tue, 14 Jan 2025 17:38:34 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v2 03/10] tools: Add arch LBR feature bits
To: Tu Dinh <ngoc-tu.dinh@vates.tech>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Juergen Gross <jgross@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20250102084413.102-1-ngoc-tu.dinh@vates.tech>
 <20250102084413.102-4-ngoc-tu.dinh@vates.tech>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250102084413.102-4-ngoc-tu.dinh@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 02.01.2025 09:45, Tu Dinh wrote:
> Signed-off-by: Tu Dinh <ngoc-tu.dinh@vates.tech>
> ---
>  tools/libs/light/libxl_cpuid.c | 3 +++
>  tools/misc/xen-cpuid.c         | 3 +++
>  2 files changed, 6 insertions(+)
> 
> diff --git a/tools/libs/light/libxl_cpuid.c b/tools/libs/light/libxl_cpuid.c
> index 063fe86eb7..05be36f258 100644
> --- a/tools/libs/light/libxl_cpuid.c
> +++ b/tools/libs/light/libxl_cpuid.c
> @@ -342,6 +342,9 @@ int libxl_cpuid_parse_config(libxl_cpuid_policy_list *policy, const char* str)
>          CPUID_ENTRY(0x00000007,  1, CPUID_REG_EDX),
>          MSR_ENTRY(0x10a, CPUID_REG_EAX),
>          MSR_ENTRY(0x10a, CPUID_REG_EDX),
> +        CPUID_ENTRY(0x0000001C, NA, CPUID_REG_EAX),
> +        CPUID_ENTRY(0x0000001C, NA, CPUID_REG_EBX),
> +        CPUID_ENTRY(0x0000001C, NA, CPUID_REG_ECX),
>  #undef MSR_ENTRY
>  #undef CPUID_ENTRY
>      };
> diff --git a/tools/misc/xen-cpuid.c b/tools/misc/xen-cpuid.c
> index 4c4593528d..4f0fb0a6ea 100644
> --- a/tools/misc/xen-cpuid.c
> +++ b/tools/misc/xen-cpuid.c
> @@ -37,6 +37,9 @@ static const struct {
>      { "CPUID 0x00000007:1.edx",     "7d1" },
>      { "MSR_ARCH_CAPS.lo",         "m10Al" },
>      { "MSR_ARCH_CAPS.hi",         "m10Ah" },
> +    { "CPUID 0x0000001c.eax",       "1Ca" },
> +    { "CPUID 0x0000001c.ebx",       "1Cb" },
> +    { "CPUID 0x0000001c.ecx",       "1Cc" },
>  };
>  
>  #define COL_ALIGN "24"

I think this needs folding into patch 2. These tables want to stay in sync at all
times with what the public interface has.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 16:49:45 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 16:49:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871572.1282550 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXk6m-000649-DD; Tue, 14 Jan 2025 16:49:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871572.1282550; Tue, 14 Jan 2025 16:49:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXk6m-000642-96; Tue, 14 Jan 2025 16:49:40 +0000
Received: by outflank-mailman (input) for mailman id 871572;
 Tue, 14 Jan 2025 16:49:38 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/Vp6=UG=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tXk6k-00063w-SX
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 16:49:38 +0000
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com
 [2a00:1450:4864:20::333])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 89bc92b1-d297-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 17:49:36 +0100 (CET)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-436ce2ab251so41316005e9.1
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 08:49:36 -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
 ffacd0b85a97d-38a8e383965sm15589078f8f.31.2025.01.14.08.49.35
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 14 Jan 2025 08:49:35 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 89bc92b1-d297-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736873376; x=1737478176; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=UZk66YKJtRTqx3KwmPWZCxM4nkt3s6xtpbLoFnnm1G8=;
        b=QQi6Lw9Zx+XliYPk1NE/8PRBn0MWDo7HeRpZUZUZ1JW8d8v5nd7Ilcq5+4vUu32IdL
         HgN/X1D/5IQdsrMCCkEJfzh/TREgqbloGuhAt/2KcMwv2qqTya2d6HoMFJwucwjSFH3z
         OEDpzsGskvx2wOMrfLUhsQsZH/Rb8TLRUGUzolkDc8rmSvuzNvCCWYe4X7rBfTyp7jt8
         MLhSFmln+3yMgVhK7wzM4ijSz3BxCNLabQ/24JpWDEqhrREHV3RPfP5vIRPCrS8dI2rg
         8if+f407VoLCUaLyXh6RfgAvINMF6YLMSurIqQT6pRynubuZpgEJeQcZwtRJWm2+IFDm
         iVAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736873376; x=1737478176;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=UZk66YKJtRTqx3KwmPWZCxM4nkt3s6xtpbLoFnnm1G8=;
        b=uJnH2mKniWrLw7VnQjksAsPurHgK0+liZBtS5aJfULaVZCX6QghtGFBENryNNhejYq
         QQ0gcwSc1xGLX4pNqfy21467Lg1VJaHdtW5iFgGTv1na8onU470L/qjiSnEbZBhRMSK3
         M40/lsqbRpiOkaQWhM8mRfVhM7tnrZCFDwhSjd3TcOwrk/EBBpO1DEFSHP+SXTjZpChK
         pPWWs+lI2oficv227IxFM4opHK88uQzHYeCTijsQdDcYTxYZuERZYzx+Ka7l3wMbPjsG
         SbN/HmgxhIOstQgXpO27Ptl+MAtQjls8sdtATg170PqJUeEwCfVWjEwndw7zZf3piGFB
         91qg==
X-Forwarded-Encrypted: i=1; AJvYcCX3OmgTjf/onsM1Jn39AaMu+DPxWIB2+6gXABi7C1MmIXEjwGGZdqzo4kdKYVQVjy0ugRSQKm7GyHs=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzh6H2FT8433PXwd0NRZQAO+bty//5V6SFp4Ujuom4KJw4W+gH3
	SRuRL2m8upiYb/wHVSeuI5Gx+ElNGH9YtSZDaLkc/1lCD5Tz6VJRIoOUkheYXQ==
X-Gm-Gg: ASbGncuEzxl/WybEmYti9mxvuEoPCK9rAYOuTHlmZxi0tW9k2/8JqsKK6boYQTmTAyS
	N7bwpbpZqSH8niOVxEth4P0Yg53Am6AWFs7IKQUKIy5fWSq5SzbjhS/L1SyyEmlh5xmUoYz4lFg
	PqodbrH0u14Y6MsYI+NwGgGZxQKeVhI5f4jbyZ7Mme+v9a26VNIM+BcdiS363c1+9oQUk4cayHf
	P8ftaZQO1NLzzx4v7TLDfIgAXYw4gdHMPJsUkSvJMdfVqwYeE1IYirOIcHy2j+7FMahvDyIq0eU
	ASW/H6DmRltJ0VChjF/c5yp4v3MQbI9Tc+lGe0Qn4g==
X-Google-Smtp-Source: AGHT+IElQs/Bg5F1uMHJc19crJm0wlZXCUP+SpClRo3IEA7ZA69jF4bPJhjtmtMhf7aTJ5MxluIrmQ==
X-Received: by 2002:a05:600c:19ce:b0:42c:bb96:340e with SMTP id 5b1f17b1804b1-436e26f857fmr236536335e9.31.1736873375948;
        Tue, 14 Jan 2025 08:49:35 -0800 (PST)
Message-ID: <0ec9f311-803a-4af2-9b3e-7225fbbadfef@suse.com>
Date: Tue, 14 Jan 2025 17:49:34 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v2 02/10] x86: Define arch LBR feature bits
To: Tu Dinh <ngoc-tu.dinh@vates.tech>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Juergen Gross <jgross@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20250102084413.102-1-ngoc-tu.dinh@vates.tech>
 <20250102084413.102-3-ngoc-tu.dinh@vates.tech>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250102084413.102-3-ngoc-tu.dinh@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 02.01.2025 09:45, Tu Dinh wrote:
> --- a/xen/arch/x86/include/asm/cpufeature.h
> +++ b/xen/arch/x86/include/asm/cpufeature.h
> @@ -219,6 +219,11 @@ static inline bool boot_cpu_has(unsigned int feat)
>  #define cpu_has_rfds_no         boot_cpu_has(X86_FEATURE_RFDS_NO)
>  #define cpu_has_rfds_clear      boot_cpu_has(X86_FEATURE_RFDS_CLEAR)
>  
> +/* CPUID level 0x0000001c.eax */
> +
> +#define current_cpu_has_lbr_lip cpu_has(&current_cpu_data, \
> +                                        X86_FEATURE_LBR_LIP);

Why would this, unlike all other similar constructs, need to use
current_cpu_data rather than boot_cpu_has()? If there is a reason, it almost
certainly wants naming in the description.

> --- a/xen/include/public/arch-x86/cpufeatureset.h
> +++ b/xen/include/public/arch-x86/cpufeatureset.h
> @@ -284,7 +284,7 @@ XEN_CPUFEATURE(SERIALIZE,     9*32+14) /*A  SERIALIZE insn */
>  XEN_CPUFEATURE(HYBRID,        9*32+15) /*   Heterogeneous platform */
>  XEN_CPUFEATURE(TSXLDTRK,      9*32+16) /*a  TSX load tracking suspend/resume insns */
>  XEN_CPUFEATURE(PCONFIG,       9*32+18) /*   PCONFIG instruction */
> -XEN_CPUFEATURE(ARCH_LBR,      9*32+19) /*   Architectural Last Branch Record */
> +XEN_CPUFEATURE(ARCH_LBR,      9*32+19) /*s  Architectural Last Branch Record */

The 's' here (and below) may only be added once all of the respective handling is
complete.

> --- a/xen/include/xen/lib/x86/cpu-policy.h
> +++ b/xen/include/xen/lib/x86/cpu-policy.h
> @@ -22,6 +22,9 @@
>  #define FEATURESET_7d1       15 /* 0x00000007:1.edx    */
>  #define FEATURESET_m10Al     16 /* 0x0000010a.eax      */
>  #define FEATURESET_m10Ah     17 /* 0x0000010a.edx      */
> +#define FEATURESET_1Ca       18 /* 0x0000001c.eax      */
> +#define FEATURESET_1Cb       19 /* 0x0000001c.ebx      */
> +#define FEATURESET_1Cc       20 /* 0x0000001c.ecx      */
>  
>  struct cpuid_leaf
>  {
> @@ -85,7 +88,7 @@ unsigned int x86_cpuid_lookup_vendor(uint32_t ebx, uint32_t ecx, uint32_t edx);
>   */
>  const char *x86_cpuid_vendor_to_str(unsigned int vendor);
>  
> -#define CPUID_GUEST_NR_BASIC      (0xdu + 1)
> +#define CPUID_GUEST_NR_BASIC      (0x1cu + 1)

Are you sure this can be done with no other prep work? I've been sitting
on AMX and AVX10 patches where I need to bump this, too. Yet I continue
to think that something along the lines of the 3-patch series at [1] is
necessary up front.

> @@ -158,6 +161,52 @@ struct cpu_policy
>              uint64_t :64, :64; /* Leaf 0xb - Topology. */
>              uint64_t :64, :64; /* Leaf 0xc - rsvd */
>              uint64_t :64, :64; /* Leaf 0xd - XSTATE. */
> +
> +            uint64_t :64, :64; /* Leaf 0xe - rsvd */
> +            uint64_t :64, :64; /* Leaf 0xf - rsvd */
> +            uint64_t :64, :64; /* Leaf 0x10 - rsvd */
> +            uint64_t :64, :64; /* Leaf 0x11 - rsvd */
> +            uint64_t :64, :64; /* Leaf 0x12 - rsvd */
> +            uint64_t :64, :64; /* Leaf 0x13 - rsvd */
> +            uint64_t :64, :64; /* Leaf 0x14 - rsvd */
> +            uint64_t :64, :64; /* Leaf 0x15 - rsvd */
> +            uint64_t :64, :64; /* Leaf 0x16 - rsvd */
> +            uint64_t :64, :64; /* Leaf 0x17 - rsvd */
> +            uint64_t :64, :64; /* Leaf 0x18 - rsvd */
> +            uint64_t :64, :64; /* Leaf 0x19 - rsvd */
> +            uint64_t :64, :64; /* Leaf 0x1a - rsvd */
> +            uint64_t :64, :64; /* Leaf 0x1b - rsvd */
> +
> +            union {
> +                uint32_t _1Ca;
> +                struct {
> +                    uint32_t supported_depths:8;

According to XEN_CPUFEATURE(LBR_DEPTH_...) further up these are 8 individual
bits. Further, is there a reason you don't use here what the additions there
produce in the generated header, but you rather re-define the fields from
scratch?

Jan

[1] https://lists.xen.org/archives/html/xen-devel/2024-08/msg00591.html


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 16:55:49 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 16:55:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871581.1282559 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXkCe-0007s1-W1; Tue, 14 Jan 2025 16:55:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871581.1282559; Tue, 14 Jan 2025 16:55:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXkCe-0007ru-TS; Tue, 14 Jan 2025 16:55:44 +0000
Received: by outflank-mailman (input) for mailman id 871581;
 Tue, 14 Jan 2025 16:55: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 <SRS0=/Vp6=UG=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tXkCe-0007ro-8a
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 16:55:44 +0000
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com
 [2a00:1450:4864:20::333])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 63d19fa8-d298-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 17:55:42 +0100 (CET)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-43618283dedso54863585e9.3
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 08:55:42 -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
 5b1f17b1804b1-436e2e92f60sm216490695e9.40.2025.01.14.08.55.41
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 14 Jan 2025 08:55:41 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 63d19fa8-d298-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736873742; x=1737478542; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=rFemZztPxAtbSNdSi9bGcpqJA38Lw/RzqbtiIYXoaKA=;
        b=CN4yIQHnUGpDjSyxr/KnIEAv8ZXCbqbEr9BmdHigVHaNTfz7iVJWBLCEgXOk2PTRh+
         xn39dfEOfRsMlrt9m78NsM6kWAVn9oMMFhcVHD2mkDFYjK8GarRYA6KQWoVRhVFiwUh+
         0k00rsS5fyo3wDGfwFWK/7CgUdQW6lRb1HjvCMeELpRbtNpFodajsgu7F4TSibdYCJur
         8nuANxGuFQO+2oxut4fY0xBDXh9rnTKTfAfA1PH4Q5hrLJZmbpVEuVs2DsJOOTk6PoSG
         IE4Bj5O4CbSWXMhGONUvrEMm4l5qTp7NIKrUpDe7MOeGVvyVnYg4jESzFgZODGS1y37j
         F2cg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736873742; x=1737478542;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=rFemZztPxAtbSNdSi9bGcpqJA38Lw/RzqbtiIYXoaKA=;
        b=deY3OG3fOA9493ze76O3m7pJ+ssgOIQU1XBdszba2KJahpy99NhjHHrKUDcvmhW0gG
         fu93hlg5yTy193CovyrLBMy0VIM6LOq273p7QVT6Hb7bXQUfXJMNFluB94u7GgtWoI1O
         pVFTHJQSTEAnTT6c/gLRXwCqBWvXQ5sG/duMSxPzhAiTcF9stvQ3AN//N4EyAh6vFOKc
         J+3B3E2wS1zeZHw4RyVcORjRfMqglUtvR+V3go8wk12zX7ulq3pb0pe3DfiyoEAGLlYq
         PsvxE/3kn7FI12WxNfeQjdjinTGnu0VDkBkAdm19flcL4tylOCuoP2ScxYswOcisVhDX
         Kmug==
X-Forwarded-Encrypted: i=1; AJvYcCWGR4Mlb2sAurIBvPWG9Iu00HEB2R7lJYAbB5aqzVarXc5UXgC6lmgkLdWXg4oyJmkvStG9XX1D2pQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwMeslwu0DJ0ngbrVrvfh4m5hVJG6aOKjC7OZwM1MZWwREdobIG
	JttUMbCy2mx0lmEwCJkoqLpyERz0d++thbCg2hyGdp6lqJ/UruAzQdYOdSsrmQ==
X-Gm-Gg: ASbGncuV4cm4gMmwN+0mTNhCORvvpksnm0vQTtK3e2qkrCi3dLpIOo4ldzgJiMd0tSP
	tJy2iFfISrT4nnUoN1QzVZx/vPHFoP6CjGv1IpHLsc6dmB9BD0LcMnUKYYUnW9tO6gzrlxs5OKl
	fKccHL66Kz937abnBNTjavRoaUYomxgBKYsrZ5xQl7XB/9aQ61zVnAMsMGw4nNilugaffq5GVy2
	hTTYLZV8d3WKzVngVBWwFxtYExjdsk8h0y2yFINLlieP/gr2vuYIlXQ4XYXt3w9MaTyAl126I8a
	KdmgVWY32PV9PAC/BzjMhN7dIQfPjCJaijT47YFhRQ==
X-Google-Smtp-Source: AGHT+IHziQXbEtY1wLT6yDpOI88o26Jdy0S0Ahn1+ZkSyP9lFeIrHbJ4RfASssu9MZ+Ja6NLFpWw6g==
X-Received: by 2002:a05:600c:4383:b0:436:fb9e:26c with SMTP id 5b1f17b1804b1-436fb9e0497mr88381895e9.17.1736873741904;
        Tue, 14 Jan 2025 08:55:41 -0800 (PST)
Message-ID: <02749804-4346-4eb5-a874-afb53b86a866@suse.com>
Date: Tue, 14 Jan 2025 17:55:40 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v2 04/10] x86: Calculate arch LBR CPUID policies
To: Tu Dinh <ngoc-tu.dinh@vates.tech>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Juergen Gross <jgross@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20250102084413.102-1-ngoc-tu.dinh@vates.tech>
 <20250102084413.102-5-ngoc-tu.dinh@vates.tech>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250102084413.102-5-ngoc-tu.dinh@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 02.01.2025 09:45, Tu Dinh wrote:
> --- a/xen/arch/x86/cpu-policy.c
> +++ b/xen/arch/x86/cpu-policy.c
> @@ -190,6 +190,16 @@ static void sanitise_featureset(uint32_t *fs)
>      }
>  }
>  
> +static void recalculate_arch_lbr(struct cpu_policy *p)
> +{
> +    if ( p->basic.max_leaf < 0x1c ||
> +         !(cpu_policy_xstates(&host_cpu_policy) & X86_XSS_LBR) ||

A reference to the host policy looks questionable here. If you ...

> +         p->basic.lbr_1Ca.supported_depths == 0)
> +        p->feat.arch_lbr = 0;
> +    if ( !p->feat.arch_lbr )
> +        p->basic.raw[0x1c] = EMPTY_LEAF;
> +}
> +
>  static void recalculate_xstate(struct cpu_policy *p)
>  {
>      uint64_t xstates = XSTATE_FP_SSE;
> @@ -219,6 +229,9 @@ static void recalculate_xstate(struct cpu_policy *p)
>      if ( p->feat.amx_tile )
>          xstates |= X86_XCR0_TILE_CFG | X86_XCR0_TILE_DATA;
>  
> +    if ( p->feat.arch_lbr )
> +        xstates |= X86_XSS_LBR;
> +
>      /* Subleaf 0 */
>      p->xstate.max_size =
>          xstate_uncompressed_size(xstates & ~XSTATE_XSAVES_ONLY);
> @@ -271,6 +284,8 @@ static void recalculate_misc(struct cpu_policy *p)
>  
>      p->basic.raw[0xc] = EMPTY_LEAF;
>  
> +    zero_leaves(p->basic.raw, 0xe, 0x1b);
> +
>      p->extd.e1d &= ~CPUID_COMMON_1D_FEATURES;
>  
>      /* Most of Power/RAS hidden from guests. */
> @@ -630,6 +645,7 @@ static void __init calculate_pv_max_policy(void)
>  
>      sanitise_featureset(fs);
>      x86_cpu_featureset_to_policy(fs, p);
> +    recalculate_arch_lbr(p);
>      recalculate_xstate(p);

... flipped the order of these calls, couldn't you use the respective bit
from the correct policy? Then again you need p->feat.arch_lbr to actually
set X86_XSS_LBR. Still the aspect in recalculate_arch_lbr() wants sorting
somehow.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 16:57:03 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 16:57:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871589.1282571 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXkDt-0008OO-BB; Tue, 14 Jan 2025 16:57:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871589.1282571; Tue, 14 Jan 2025 16:57:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXkDt-0008OH-6z; Tue, 14 Jan 2025 16:57:01 +0000
Received: by outflank-mailman (input) for mailman id 871589;
 Tue, 14 Jan 2025 16:56:59 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/Vp6=UG=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tXkDr-0008OB-Cn
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 16:56:59 +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 90e9c336-d298-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 17:56:58 +0100 (CET)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-4362f61757fso54894955e9.2
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 08:56:58 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a8e4c1daasm15679433f8f.93.2025.01.14.08.56.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 14 Jan 2025 08:56:57 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 90e9c336-d298-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736873817; x=1737478617; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=fsYkyPf0OJ11AWgZ7jqNzBkpW0COvJea9qX0Bwx3hLE=;
        b=RqXTicFbCj18E/vp8AU43JGFnkRRe8FD9SgTNee9SMZ5NZjvjwG1Of+gupbbU2iOQX
         Tjrw7EGQjRyR5V0WpHuGfjMSb4ycInR5CKvAufozoxbZZq8h9RqfWohu4bo27pIpIweJ
         yfvBANnkmX952bqciX4qSnuf5WXmlbh6uj0y8Y4Sp/3cJWN6eVYE3UNTyRN5BDZnjaJd
         +SPQOYXJfa3nBBlrBdoyGJyYz+9izFYq0dvh5AgI+JFwO3tsuDTgWMfb1zNWQTxI3n/9
         ataKxdynAMaUOvGrm4DtrgPG2hrrJD6EEkoLXSg362xwpawGzO2EKQtYMeyJkBbgGXM4
         QFYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736873817; x=1737478617;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=fsYkyPf0OJ11AWgZ7jqNzBkpW0COvJea9qX0Bwx3hLE=;
        b=f+feyfJTy55v1QJBEHG/HcHh6t4+irH7El17/f0ABScywszcPNYCPexISBitce7e5O
         RDIcysR6tX3IRtfhchyYFDD+KEyrRbwywQoqLMwZkBq1wlSpYrdXFQO9NBrJg/8mr6xu
         NmBm3HEM61AgkGhtrNnsI802wO6CkXZXfu2Na2K4L5Jvk9XRV1grYO8AZuydToyQn+w+
         rRaxGWYiBjl7pz2MH3ttDwvVABi+ys4vcbtmYzCAGtT/CC2Iwoziw/E9z5Z1TQvDo8Pu
         hmUt5HKPyCKS/BK0FTuj7JreFZE7pD1vxm/h11i5IG0tTeXKUmkCG3LJJk9Hzw/Jf7VI
         Oq+A==
X-Forwarded-Encrypted: i=1; AJvYcCUDOHRCjfQBn0Q1AcCm4vw2RQPSSNhiUNEf6C5uj9nNirjKeKEE5etDslVXBZBwzGgD789nQ70aQhE=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy526ZIjiP3rUyiBil6mc5sDsnamHM+M2d9KgS6hbWRpJTDokWs
	X5PxXcbf+EbyWuUFaQYlvoa+tCTPbL7vbRS7XZTpk6r2HVxss5HB0cmSRvXu6g==
X-Gm-Gg: ASbGncurwjb1GO2uK92gROCG5DRWUBajL5MQXaVl5rCmgD1dPZFemf54i11OEIyhS8F
	rE+vqdcS3r5FrSKnknAovd16uk54ZH1CfFjXtg2MKSYrrtCmCwoTd/I0CB7xC8uK2YviVmR7rHQ
	sJCBvyVUjTboWSMa47ZBejWmTH4/4ybBHpvf1rY/2Zwc2GcEYkYTtpZBbk2EihRy0NcOMkhVYdd
	0ETMFxEzaGX5VBJ8KVbR984N76bt71jYubrwQ6xTh1QxrZHnmltBkONhKlfivyV7/6j89HobWT6
	Jz2l/+nDuqgmWhjOK26DJ5mDEjeLTUkldcA1H1I5+A==
X-Google-Smtp-Source: AGHT+IEYG1PkfV8jXB0AFC3HZkRpTziO2r6hZAiCX0quFY7kwBl5cNLw61gnz+EuVXqPBjbnR8XK0g==
X-Received: by 2002:a05:600c:1d9e:b0:436:8a6f:b6db with SMTP id 5b1f17b1804b1-436e2707c41mr204119145e9.22.1736873817626;
        Tue, 14 Jan 2025 08:56:57 -0800 (PST)
Message-ID: <f375f3c0-5b73-4eaf-afc6-9d394fc4346f@suse.com>
Date: Tue, 14 Jan 2025 17:56:56 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v2 05/10] x86: Keep a copy of XSAVE area size
To: Tu Dinh <ngoc-tu.dinh@vates.tech>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Juergen Gross <jgross@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20250102084413.102-1-ngoc-tu.dinh@vates.tech>
 <20250102084413.102-6-ngoc-tu.dinh@vates.tech>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250102084413.102-6-ngoc-tu.dinh@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 02.01.2025 09:45, Tu Dinh wrote:
> Signed-off-by: Tu Dinh <ngoc-tu.dinh@vates.tech>

This needs a non-empty description to clarify why this would be needed.

Jan

> --- a/xen/arch/x86/include/asm/domain.h
> +++ b/xen/arch/x86/include/asm/domain.h
> @@ -638,6 +638,7 @@ struct arch_vcpu
>       * #NM handler, we XRSTOR the states we XSAVE-ed;
>       */
>      struct xsave_struct *xsave_area;
> +    unsigned int xsave_area_size;
>      uint64_t xcr0;
>      /* Accumulated eXtended features mask for using XSAVE/XRESTORE by Xen
>       * itself, as we can never know whether guest OS depends on content
> diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c
> index af9e345a7a..baae8e1a13 100644
> --- a/xen/arch/x86/xstate.c
> +++ b/xen/arch/x86/xstate.c
> @@ -550,6 +550,7 @@ int xstate_alloc_save_area(struct vcpu *v)
>      save_area->fpu_sse.mxcsr = MXCSR_DEFAULT;
>  
>      v->arch.xsave_area = save_area;
> +    v->arch.xsave_area_size = size;
>      v->arch.xcr0 = 0;
>      v->arch.xcr0_accum = 0;
>  



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 17:00:13 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 17:00:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871569.1282580 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXkGx-0001Tl-Nh; Tue, 14 Jan 2025 17:00:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871569.1282580; Tue, 14 Jan 2025 17:00:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXkGx-0001Te-KV; Tue, 14 Jan 2025 17:00:11 +0000
Received: by outflank-mailman (input) for mailman id 871569;
 Tue, 14 Jan 2025 16:41:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=LTc1=UG=brainfault.org=anup@srs-se1.protection.inumbo.net>)
 id 1tXjyW-0005us-NB
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 16:41:09 +0000
Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com
 [2607:f8b0:4864:20::d31])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 58ef6946-d296-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 17:41:05 +0100 (CET)
Received: by mail-io1-xd31.google.com with SMTP id
 ca18e2360f4ac-84a012f7232so213192939f.0
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 08:41:05 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 58ef6946-d296-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=brainfault-org.20230601.gappssmtp.com; s=20230601; t=1736872864; x=1737477664; 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=PYYy9/uR4iy35ySnvh+St9PKv34OGy3mNjqnkv7qxQw=;
        b=y2w9l2X4/ptMvCqUpIoW2kjkdG6ma/fweFNizjQrAoWUR1av7h7K6lD4ExODMx9XgE
         VesyPzAnZfOYbV5q0WvvxovYoD8sugHSJQ9yyWuuREdr7tg/3tscZtj8Gg5qH4x/HCQW
         8OMPlk0S+keRNMl1uichVDFXey0GyVREKJE/i+6SaBhd30LuItvQziLYq/sIbPBb28PM
         xMATAW/8g2a88w6JqHn0SL80kgiI3Fr3qSd+LZ4jKjI4ENtWJUQYglHPbywg5JnFZaXq
         dQKhP73ch8hSF8d3x3JHVnqfHMFFh/KJMI6fLWqsiBVkRXuJWcCbiCr4U+PKPJqU7J77
         U0/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736872864; x=1737477664;
        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=PYYy9/uR4iy35ySnvh+St9PKv34OGy3mNjqnkv7qxQw=;
        b=OQIklB+pRjwwtrN95ge8kmjtlcr8YVrw0YF5ARCAMDpwMFnEFi3/Y6mfxurWaKDzjU
         2xBXuNeG1qDRUPZT+umSGYvcXLIm8VIkBWvzPBRsHH1bGA4mNpGk6l851iot74/r7thQ
         ZF3l3DLc524r6i1BGrlhI1DbdgByTrgN9zayLQCmr4VooKxhfJpUtnh69ZAOw2VGAf6M
         VLzTtKiKj3mtELHsfBk08wxDdpqIj2oMFaiUq36dNpl8qqiQLiw2gqvoFNF2/q0DjlEZ
         VxMi7HjCuayUjubmN5k9254ziFFOyb1kgUElCvILTgIRf5RKoD9PP114W1dopVMFuS4D
         eDwQ==
X-Forwarded-Encrypted: i=1; AJvYcCVZ3JKNZNFZSjMSkmrjTkFtBktL+VsDa8ElvLnaYArNwuxZAs+G2No79vm7Bq9RvtTy3G3VK+zW/Gc=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywc1fCTMSmpabpYsUDTAnroM0jLcxfaHzj9jrmIBDUT+qG1J0vq
	boADlDBIQtrY97WNmJ0t4sDokr5PCIWhjjebfTYUuZ3PZGizfb6T2pS57uZP+UyqZOV2ox0+5fa
	PF9vHDwOKvkl60jHscGjTobW1q3yUoddPK0CjWQ==
X-Gm-Gg: ASbGncvdd4UqnVE0nMXc8SITqvUOM4F9Un3cvTw0an9zil63PeEIj4qdbq9IW8WZ5QC
	h/6OWcsnELBJsxPhXzQmpc9JTN3nWTttoW6YDsow=
X-Google-Smtp-Source: AGHT+IGayyMTLiwTPodEFqs3shB7Qhb2StAITjyDm4y5doOqNDLF2JdCpPToaFxsLfQt91MNsMWXze1BX4KyGJIjLMQ=
X-Received: by 2002:a05:6e02:1f05:b0:3ce:7b33:8c3b with SMTP id
 e9e14a558f8ab-3ce7b339029mr26680325ab.5.1736872864228; Tue, 14 Jan 2025
 08:41:04 -0800 (PST)
MIME-Version: 1.0
References: <e4a649a7fdfc8fcf5f48a0bc4e76e5d546078083.1736868605.git.Slavisa.Petrovic@rt-rk.com>
In-Reply-To: <e4a649a7fdfc8fcf5f48a0bc4e76e5d546078083.1736868605.git.Slavisa.Petrovic@rt-rk.com>
From: Anup Patel <anup@brainfault.org>
Date: Tue, 14 Jan 2025 22:10:52 +0530
X-Gm-Features: AbW1kvZAYWhkxIlWxJiEL0gBDLMmDf6ZNuh0dZnQTSt_rnq6EtQLVaI7jznNB7M
Message-ID: <CAAhSdy2rfbNT6tTK7i7rV6M1kNs2bFOQtN5QZpJ2xPrJx6WXjw@mail.gmail.com>
Subject: Re: [PATCH] riscv: Add initial Xen guest support for RISC-V
To: Milan Djokic <milandjokic1995@gmail.com>
Cc: linux-riscv@lists.infradead.org, paul.walmsley@sifive.com, 
	palmer@dabbelt.com, aou@eecs.berkeley.edu, jgross@suse.com, 
	sstabellini@kernel.org, oleksandr_tyshchenko@epam.com, 
	Slavisa.Petrovic@rt-rk.com, Milan.Djokic@rt-rk.com, 
	rafael.j.wysocki@intel.com, sunilvl@ventanamicro.com, takakura@valinux.co.jp, 
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, 
	iommu@lists.linux.dev
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 14, 2025 at 9:41=E2=80=AFPM Milan Djokic <milandjokic1995@gmail=
.com> wrote:
>
> From: Slavisa Petrovic <Slavisa.Petrovic@rt-rk.com>
>
> This patch introduces initial support for running RISC-V as a Xen guest.
> It provides the necessary infrastructure and stubs for Xen-specific
> operations. Key changes include:
>
> - Modifications to the RISC-V kernel to integrate Xen-specific hypercalls
>   and interfaces, with function implementations stubbed for future work.
> - Introduction of Xen-specific headers for RISC-V, including event
>   handling, hypervisor interaction, and page management. Functions are
>   defined but not yet implemented.
> - Stub implementations for memory management, grant tables, and context
>   switching in the Xen environment, allowing further development and
>   integration.
>
> Signed-off-by: Milan Djokic <Milan.Djokic@rt-rk.com>
> Signed-off-by: Slavisa Petrovic <Slavisa.Petrovic@rt-rk.com>

A single patch with many changes is hard to review.

Please convert this patch into a series with smaller patches.
Also, include a cover letter in the series explaining how to
test Xen on RISC-V.

Regards,
Anup

> ---
>  arch/riscv/Kbuild                        |   1 +
>  arch/riscv/Kconfig                       |  19 +++
>  arch/riscv/include/asm/cpu.h             |   1 +
>  arch/riscv/include/asm/hypervisor.h      |   9 ++
>  arch/riscv/include/asm/irq.h             |   5 +
>  arch/riscv/include/asm/sync_bitops.h     |  27 ++++
>  arch/riscv/include/asm/xen/events.h      |  28 ++++
>  arch/riscv/include/asm/xen/hypercall.h   |   2 +
>  arch/riscv/include/asm/xen/hypervisor.h  |   2 +
>  arch/riscv/include/asm/xen/interface.h   |   2 +
>  arch/riscv/include/asm/xen/page.h        |   3 +
>  arch/riscv/include/asm/xen/swiotlb-xen.h |   2 +
>  arch/riscv/xen/Makefile                  |   2 +
>  arch/riscv/xen/enlighten.c               | 164 +++++++++++++++++++++++
>  arch/riscv/xen/grant-table.c             |  57 ++++++++
>  arch/riscv/xen/hypercall.S               |  71 ++++++++++
>  arch/riscv/xen/p2m.c                     |  76 +++++++++++
>  include/xen/interface/io/protocols.h     |   3 +
>  include/xen/riscv/hypercall.h            |  71 ++++++++++
>  include/xen/riscv/hypervisor.h           |  26 ++++
>  include/xen/riscv/interface.h            |  85 ++++++++++++
>  include/xen/riscv/page.h                 | 106 +++++++++++++++
>  include/xen/riscv/swiotlb-xen.h          |  13 ++
>  test.txt                                 |  21 +++
>  24 files changed, 796 insertions(+)
>  create mode 100644 arch/riscv/include/asm/hypervisor.h
>  create mode 100644 arch/riscv/include/asm/sync_bitops.h
>  create mode 100644 arch/riscv/include/asm/xen/events.h
>  create mode 100644 arch/riscv/include/asm/xen/hypercall.h
>  create mode 100644 arch/riscv/include/asm/xen/hypervisor.h
>  create mode 100644 arch/riscv/include/asm/xen/interface.h
>  create mode 100644 arch/riscv/include/asm/xen/page.h
>  create mode 100644 arch/riscv/include/asm/xen/swiotlb-xen.h
>  create mode 100644 arch/riscv/xen/Makefile
>  create mode 100644 arch/riscv/xen/enlighten.c
>  create mode 100644 arch/riscv/xen/grant-table.c
>  create mode 100644 arch/riscv/xen/hypercall.S
>  create mode 100644 arch/riscv/xen/p2m.c
>  create mode 100644 include/xen/riscv/hypercall.h
>  create mode 100644 include/xen/riscv/hypervisor.h
>  create mode 100644 include/xen/riscv/interface.h
>  create mode 100644 include/xen/riscv/page.h
>  create mode 100644 include/xen/riscv/swiotlb-xen.h
>  create mode 100644 test.txt
>
> diff --git a/arch/riscv/Kbuild b/arch/riscv/Kbuild
> index 2c585f7a0b6e..d9b71deed2cd 100644
> --- a/arch/riscv/Kbuild
> +++ b/arch/riscv/Kbuild
> @@ -5,6 +5,7 @@ obj-$(CONFIG_BUILTIN_DTB) +=3D boot/dts/
>  obj-$(CONFIG_CRYPTO) +=3D crypto/
>  obj-y +=3D errata/
>  obj-$(CONFIG_KVM) +=3D kvm/
> +obj-$(CONFIG_XEN) +=3D xen/
>
>  obj-$(CONFIG_ARCH_SUPPORTS_KEXEC_PURGATORY) +=3D purgatory/
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index d4a7ca0388c0..13ea75221524 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -1071,6 +1071,25 @@ config PARAVIRT_TIME_ACCOUNTING
>
>           If in doubt, say N here.
>
> +config XEN_DOM0
> +       def_bool y
> +       depends on XEN
> +
> +config XEN
> +       bool "Xen guest support on RISCV"
> +       depends on RISCV && OF
> +       select PARAVIRT
> +       help
> +         Enables support for running Linux as a Xen guest on RISC-V.
> +
> +         Xen is a type-1 hypervisor that allows multiple operating syste=
ms
> +         to run on the same hardware. Enabling this option allows the ke=
rnel
> +         to function as a guest under the Xen hypervisor on RISC-V platf=
orms.
> +
> +         Say Y if you want to run this kernel as a guest under Xen on RI=
SC-V.
> +
> +         If unsure, say N.
> +
>  config RELOCATABLE
>         bool "Build a relocatable kernel"
>         depends on MMU && 64BIT && !XIP_KERNEL
> diff --git a/arch/riscv/include/asm/cpu.h b/arch/riscv/include/asm/cpu.h
> index 28d45a6678ce..fb2aac6a068e 100644
> --- a/arch/riscv/include/asm/cpu.h
> +++ b/arch/riscv/include/asm/cpu.h
> @@ -4,5 +4,6 @@
>  #define _ASM_CPU_H
>
>  /* This header is required unconditionally by the ACPI core */
> +#include <linux/cpu.h>
>
>  #endif /* _ASM_CPU_H */
> diff --git a/arch/riscv/include/asm/hypervisor.h b/arch/riscv/include/asm=
/hypervisor.h
> new file mode 100644
> index 000000000000..3a117afe57f0
> --- /dev/null
> +++ b/arch/riscv/include/asm/hypervisor.h
> @@ -0,0 +1,9 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _ASM_RISCV_HYPERVISOR_H
> +#define _ASM_RISCV_HYPERVISOR_H
> +
> +#include <asm/xen/hypervisor.h>
> +
> +void kvm_init_hyp_services(void);
> +
> +#endif
> diff --git a/arch/riscv/include/asm/irq.h b/arch/riscv/include/asm/irq.h
> index 7b038f3b7cb0..b14621848eae 100644
> --- a/arch/riscv/include/asm/irq.h
> +++ b/arch/riscv/include/asm/irq.h
> @@ -23,6 +23,11 @@ void riscv_set_intc_hwnode_fn(struct fwnode_handle *(*=
fn)(void));
>
>  struct fwnode_handle *riscv_get_intc_hwnode(void);
>
> +static inline int nr_legacy_irqs(void)
> +{
> +       return 0;
> +}
> +
>  #ifdef CONFIG_ACPI
>
>  enum riscv_irqchip_type {
> diff --git a/arch/riscv/include/asm/sync_bitops.h b/arch/riscv/include/as=
m/sync_bitops.h
> new file mode 100644
> index 000000000000..28e3c64ba852
> --- /dev/null
> +++ b/arch/riscv/include/asm/sync_bitops.h
> @@ -0,0 +1,27 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef __ASM_SYNC_BITOPS_H__
> +#define __ASM_SYNC_BITOPS_H__
> +
> +#include <asm/bitops.h>
> +#include <asm/cmpxchg.h>
> +
> +/* sync_bitops functions are equivalent to the SMP implementation of the
> + * original functions, independently from CONFIG_SMP being defined.
> + *
> + * We need them because _set_bit etc are not SMP safe if !CONFIG_SMP. Bu=
t
> + * under Xen you might be communicating with a completely external entit=
y
> + * who might be on another CPU (e.g. two uniprocessor guests communicati=
ng
> + * via event channels and grant tables). So we need a variant of the bit
> + * ops which are SMP safe even on a UP kernel.
> + */
> +
> +#define sync_set_bit(nr, p)             set_bit(nr, p)
> +#define sync_clear_bit(nr, p)           clear_bit(nr, p)
> +#define sync_change_bit(nr, p)          change_bit(nr, p)
> +#define sync_test_and_set_bit(nr, p)    test_and_set_bit(nr, p)
> +#define sync_test_and_clear_bit(nr, p)  test_and_clear_bit(nr, p)
> +#define sync_test_and_change_bit(nr, p) test_and_change_bit(nr, p)
> +#define sync_test_bit(nr, addr)         test_bit(nr, addr)
> +#define arch_sync_cmpxchg               arch_cmpxchg
> +
> +#endif
> diff --git a/arch/riscv/include/asm/xen/events.h b/arch/riscv/include/asm=
/xen/events.h
> new file mode 100644
> index 000000000000..a3d0332ca46c
> --- /dev/null
> +++ b/arch/riscv/include/asm/xen/events.h
> @@ -0,0 +1,28 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _ASM_RISCV_XEN_EVENTS_H
> +#define _ASM_RISCV_XEN_EVENTS_H
> +
> +#include <asm/ptrace.h>
> +#include <asm/atomic.h>
> +
> +enum ipi_vector {
> +       XEN_PLACEHOLDER_VECTOR,
> +
> +       /* Xen IPIs go here */
> +       XEN_NR_IPIS,
> +};
> +
> +static inline int xen_irqs_disabled(struct pt_regs *regs)
> +{
> +       return 0;
> +}
> +
> +#define xchg_xen_ulong(ptr, val) xchg((ptr), (val))
> +
> +/* Rebind event channel is supported by default */
> +static inline bool xen_support_evtchn_rebind(void)
> +{
> +       return true;
> +}
> +
> +#endif /* _ASM_RISCV_XEN_EVENTS_H */
> diff --git a/arch/riscv/include/asm/xen/hypercall.h b/arch/riscv/include/=
asm/xen/hypercall.h
> new file mode 100644
> index 000000000000..0841ba1f0835
> --- /dev/null
> +++ b/arch/riscv/include/asm/xen/hypercall.h
> @@ -0,0 +1,2 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#include <xen/riscv/hypercall.h>
> diff --git a/arch/riscv/include/asm/xen/hypervisor.h b/arch/riscv/include=
/asm/xen/hypervisor.h
> new file mode 100644
> index 000000000000..05b7c834d0a9
> --- /dev/null
> +++ b/arch/riscv/include/asm/xen/hypervisor.h
> @@ -0,0 +1,2 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#include <xen/riscv/hypervisor.h>
> diff --git a/arch/riscv/include/asm/xen/interface.h b/arch/riscv/include/=
asm/xen/interface.h
> new file mode 100644
> index 000000000000..9f30b1d7e77c
> --- /dev/null
> +++ b/arch/riscv/include/asm/xen/interface.h
> @@ -0,0 +1,2 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#include <xen/riscv/interface.h>
> diff --git a/arch/riscv/include/asm/xen/page.h b/arch/riscv/include/asm/x=
en/page.h
> new file mode 100644
> index 000000000000..c8f5b873445b
> --- /dev/null
> +++ b/arch/riscv/include/asm/xen/page.h
> @@ -0,0 +1,3 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#include <xen/riscv/page.h>
> +#include <asm/mmu.h>
> diff --git a/arch/riscv/include/asm/xen/swiotlb-xen.h b/arch/riscv/includ=
e/asm/xen/swiotlb-xen.h
> new file mode 100644
> index 000000000000..aa3bc339df03
> --- /dev/null
> +++ b/arch/riscv/include/asm/xen/swiotlb-xen.h
> @@ -0,0 +1,2 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#include <xen/riscv/swiotlb-xen.h>
> diff --git a/arch/riscv/xen/Makefile b/arch/riscv/xen/Makefile
> new file mode 100644
> index 000000000000..f6d3a357e4c7
> --- /dev/null
> +++ b/arch/riscv/xen/Makefile
> @@ -0,0 +1,2 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +obj-y :=3D enlighten.o p2m.o grant-table.o hypercall.o
> diff --git a/arch/riscv/xen/enlighten.c b/arch/riscv/xen/enlighten.c
> new file mode 100644
> index 000000000000..28bd66c288f9
> --- /dev/null
> +++ b/arch/riscv/xen/enlighten.c
> @@ -0,0 +1,164 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +#include <xen/xen.h>
> +#include <xen/events.h>
> +#include <xen/grant_table.h>
> +#include <xen/hvm.h>
> +#include <xen/interface/vcpu.h>
> +#include <xen/interface/xen.h>
> +#include <xen/interface/memory.h>
> +#include <xen/interface/hvm/params.h>
> +#include <xen/features.h>
> +#include <xen/platform_pci.h>
> +#include <xen/xenbus.h>
> +#include <xen/page.h>
> +#include <xen/interface/sched.h>
> +#include <xen/xen-ops.h>
> +#include <asm/xen/hypervisor.h>
> +#include <asm/xen/hypercall.h>
> +#include <asm/efi.h>
> +#include <linux/interrupt.h>
> +#include <linux/irqreturn.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_fdt.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_address.h>
> +#include <linux/cpuidle.h>
> +#include <linux/cpufreq.h>
> +#include <linux/cpu.h>
> +#include <linux/console.h>
> +#include <linux/pvclock_gtod.h>
> +#include <linux/reboot.h>
> +#include <linux/time64.h>
> +#include <linux/timekeeping.h>
> +#include <linux/timekeeper_internal.h>
> +#include <linux/acpi.h>
> +#include <linux/virtio_anchor.h>
> +
> +#include <linux/mm.h>
> +
> +static struct start_info _xen_start_info;
> +struct start_info *xen_start_info =3D &_xen_start_info;
> +EXPORT_SYMBOL(xen_start_info);
> +
> +enum xen_domain_type xen_domain_type =3D XEN_NATIVE;
> +EXPORT_SYMBOL(xen_domain_type);
> +
> +struct shared_info xen_dummy_shared_info;
> +struct shared_info *HYPERVISOR_shared_info =3D (void *)&xen_dummy_shared=
_info;
> +
> +DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu);
> +static struct vcpu_info __percpu *xen_vcpu_info;
> +
> +/* Linux <-> Xen vCPU id mapping */
> +DEFINE_PER_CPU(uint32_t, xen_vcpu_id);
> +EXPORT_PER_CPU_SYMBOL(xen_vcpu_id);
> +
> +/* These are unused until we support booting "pre-ballooned" */
> +unsigned long xen_released_pages;
> +struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __init=
data;
> +
> +static __read_mostly unsigned int xen_events_irq;
> +static __read_mostly phys_addr_t xen_grant_frames;
> +
> +#define GRANT_TABLE_INDEX   0
> +#define EXT_REGION_INDEX    1
> +
> +uint32_t xen_start_flags;
> +EXPORT_SYMBOL(xen_start_flags);
> +
> +int xen_unmap_domain_gfn_range(struct vm_area_struct *vma,
> +                                       int nr, struct page **pages)
> +{
> +       return 0;
> +}
> +EXPORT_SYMBOL_GPL(xen_unmap_domain_gfn_range);
> +
> +static void xen_read_wallclock(struct timespec64 *ts)
> +{
> +}
> +
> +static int xen_pvclock_gtod_notify(struct notifier_block *nb,
> +                                       unsigned long was_set, void *priv=
)
> +{
> +       return 0;
> +}
> +
> +static struct notifier_block xen_pvclock_gtod_notifier =3D {
> +       .notifier_call =3D xen_pvclock_gtod_notify,
> +};
> +
> +static int xen_starting_cpu(unsigned int cpu)
> +{
> +       return 0;
> +}
> +
> +static int xen_dying_cpu(unsigned int cpu)
> +{
> +       return 0;
> +}
> +
> +void xen_reboot(int reason)
> +{
> +}
> +
> +static int xen_restart(struct notifier_block *nb, unsigned long action,
> +                                       void *data)
> +{
> +       return 0;
> +}
> +
> +static struct notifier_block xen_restart_nb =3D {
> +       .notifier_call =3D xen_restart,
> +       .priority =3D 192,
> +};
> +
> +static void xen_power_off(void)
> +{
> +}
> +
> +static __initdata struct {
> +       const char *compat;
> +       const char *prefix;
> +       const char *version;
> +       bool found;
> +} hyper_node =3D {"xen,xen", "xen,xen-", NULL, false};
> +
> +static int __init fdt_find_hyper_node(unsigned long node, const char *un=
ame,
> +                                       int depth, void *data)
> +{
> +       return 0;
> +}
> +
> +void __init xen_early_init(void)
> +{
> +}
> +
> +static void __init xen_dt_guest_init(void)
> +{
> +}
> +
> +static int __init xen_guest_init(void)
> +{
> +       return 0;
> +}
> +early_initcall(xen_guest_init);
> +
> +static int xen_starting_runstate_cpu(unsigned int cpu)
> +{
> +       return 0;
> +}
> +
> +static int __init xen_late_init(void)
> +{
> +       return 0;
> +}
> +late_initcall(xen_late_init);
> +
> +
> +/* empty stubs */
> +void xen_arch_pre_suspend(void) { }
> +void xen_arch_post_suspend(int suspend_cancelled) { }
> +void xen_timer_resume(void) { }
> +void xen_arch_resume(void) { }
> +void xen_arch_suspend(void) { }
> diff --git a/arch/riscv/xen/grant-table.c b/arch/riscv/xen/grant-table.c
> new file mode 100644
> index 000000000000..9dd0cea74360
> --- /dev/null
> +++ b/arch/riscv/xen/grant-table.c
> @@ -0,0 +1,57 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/***********************************************************************=
*******
> + * grant_table.c
> + *
> + * Granting foreign access to our memory reservation.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version 2
> + * as published by the Free Software Foundation; or, when distributed
> + * separately from the Linux kernel or incorporated into other
> + * software packages, subject to the following license:
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining=
 a copy
> + * of this source file (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use, copy, mo=
dify,
> + * merge, publish, distribute, sublicense, and/or sell copies of the Sof=
tware,
> + * and to permit persons to whom the Software is furnished to do so, sub=
ject to
> + * the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be includ=
ed in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRE=
SS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILI=
TY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHA=
LL THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHE=
R
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISI=
NG
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER D=
EALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +#include <xen/interface/xen.h>
> +#include <xen/page.h>
> +#include <xen/grant_table.h>
> +
> +int arch_gnttab_map_shared(xen_pfn_t *frames, unsigned long nr_gframes,
> +                                       unsigned long max_nr_gframes,
> +                                       void **__shared)
> +{
> +       return 0;
> +}
> +
> +void arch_gnttab_unmap(void *shared, unsigned long nr_gframes)
> +{
> +}
> +
> +int arch_gnttab_map_status(uint64_t *frames, unsigned long nr_gframes,
> +                                       unsigned long max_nr_gframes,
> +                                       grant_status_t **__shared)
> +{
> +       return 0;
> +}
> +
> +int arch_gnttab_init(unsigned long nr_shared, unsigned long nr_status)
> +{
> +       return 0;
> +}
> diff --git a/arch/riscv/xen/hypercall.S b/arch/riscv/xen/hypercall.S
> new file mode 100644
> index 000000000000..a81afd2a11c4
> --- /dev/null
> +++ b/arch/riscv/xen/hypercall.S
> @@ -0,0 +1,71 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#include <linux/linkage.h>
> +#include <asm/assembler.h>
> +#include <xen/interface/xen.h>
> +EXPORT_SYMBOL_GPL(HYPERVISOR_event_channel_op);
> +EXPORT_SYMBOL_GPL(HYPERVISOR_grant_table_op);
> +EXPORT_SYMBOL_GPL(HYPERVISOR_xen_version);
> +EXPORT_SYMBOL_GPL(HYPERVISOR_console_io);
> +EXPORT_SYMBOL_GPL(HYPERVISOR_sched_op);
> +EXPORT_SYMBOL_GPL(HYPERVISOR_hvm_op);
> +EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
> +EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
> +EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
> +EXPORT_SYMBOL_GPL(HYPERVISOR_platform_op_raw);
> +EXPORT_SYMBOL_GPL(HYPERVISOR_multicall);
> +EXPORT_SYMBOL_GPL(HYPERVISOR_vm_assist);
> +EXPORT_SYMBOL_GPL(HYPERVISOR_dm_op);
> +EXPORT_SYMBOL_GPL(privcmd_call);
> +#define SBI_ECALL 0xE
> +
> +    .data
> +
> +#define HYPERCALL_SIMPLE(hypercall) \
> +SYM_FUNC_START(HYPERVISOR_##hypercall) \
> +    li a6, __HYPERVISOR_##hypercall; \
> +    li a7, SBI_ECALL; \
> +    mv a5, a4; \
> +    mv a4, a3; \
> +    mv a3, a2; \
> +    mv a2, a1; \
> +    mv a1, a0; \
> +    li a0, 0; \
> +    ecall; \
> +    ret; \
> +SYM_FUNC_END(HYPERVISOR_##hypercall)
> +
> +#define HYPERCALL0 HYPERCALL_SIMPLE
> +#define HYPERCALL1 HYPERCALL_SIMPLE
> +#define HYPERCALL2 HYPERCALL_SIMPLE
> +#define HYPERCALL3 HYPERCALL_SIMPLE
> +#define HYPERCALL4 HYPERCALL_SIMPLE
> +#define HYPERCALL5 HYPERCALL_SIMPLE
> +
> +    .text
> +
> +HYPERCALL2(xen_version);
> +HYPERCALL3(console_io);
> +HYPERCALL3(grant_table_op);
> +HYPERCALL2(sched_op);
> +HYPERCALL2(event_channel_op);
> +HYPERCALL2(hvm_op);
> +HYPERCALL2(memory_op);
> +HYPERCALL2(physdev_op);
> +HYPERCALL3(vcpu_op);
> +HYPERCALL1(platform_op_raw);
> +HYPERCALL2(multicall);
> +HYPERCALL2(vm_assist);
> +HYPERCALL3(dm_op);
> +
> +SYM_FUNC_START(privcmd_call)
> +    mv a6, a0
> +    li a7, SBI_ECALL
> +    mv a5, a4;
> +    mv a4, a3;
> +    mv a3, a2;
> +    mv a2, a1;
> +    mv a1, a0;
> +    li a0, 0;
> +    ecall
> +    ret
> +SYM_FUNC_END(privcmd_call);
> diff --git a/arch/riscv/xen/p2m.c b/arch/riscv/xen/p2m.c
> new file mode 100644
> index 000000000000..7ce75e52d7c4
> --- /dev/null
> +++ b/arch/riscv/xen/p2m.c
> @@ -0,0 +1,76 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +#include <linux/memblock.h>
> +#include <linux/gfp.h>
> +#include <linux/export.h>
> +#include <linux/spinlock.h>
> +#include <linux/slab.h>
> +#include <linux/types.h>
> +#include <linux/dma-mapping.h>
> +#include <linux/vmalloc.h>
> +#include <linux/swiotlb.h>
> +
> +#include <xen/xen.h>
> +#include <xen/interface/memory.h>
> +#include <xen/grant_table.h>
> +#include <xen/page.h>
> +#include <xen/swiotlb-xen.h>
> +
> +#include <asm/cacheflush.h>
> +#include <asm/xen/hypercall.h>
> +#include <asm/xen/interface.h>
> +
> +struct xen_p2m_entry {
> +       unsigned long pfn;
> +       unsigned long mfn;
> +       unsigned long nr_pages;
> +       struct rb_node rbnode_phys;
> +};
> +
> +static rwlock_t p2m_lock;
> +struct rb_root phys_to_mach =3D RB_ROOT;
> +EXPORT_SYMBOL_GPL(phys_to_mach);
> +
> +static int xen_add_phys_to_mach_entry(struct xen_p2m_entry *new)
> +{
> +
> +       return 0;
> +}
> +
> +unsigned long __pfn_to_mfn(unsigned long pfn)
> +{
> +       return 0;
> +}
> +EXPORT_SYMBOL_GPL(__pfn_to_mfn);
> +
> +int set_foreign_p2m_mapping(struct gnttab_map_grant_ref *map_ops,
> +                                       struct gnttab_map_grant_ref *kmap=
_ops,
> +                                       struct page **pages, unsigned int=
 count)
> +{
> +       return 0;
> +}
> +
> +int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
> +                                       struct gnttab_unmap_grant_ref *ku=
nmap_ops,
> +                                       struct page **pages, unsigned int=
 count)
> +{
> +       return 0;
> +}
> +
> +bool __set_phys_to_machine_multi(unsigned long pfn,
> +                                       unsigned long mfn, unsigned long =
nr_pages)
> +{
> +       return true;
> +}
> +EXPORT_SYMBOL_GPL(__set_phys_to_machine_multi);
> +
> +bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
> +{
> +       return true;
> +}
> +EXPORT_SYMBOL_GPL(__set_phys_to_machine);
> +
> +static int p2m_init(void)
> +{
> +       return 0;
> +}
> +arch_initcall(p2m_init);
> diff --git a/include/xen/interface/io/protocols.h b/include/xen/interface=
/io/protocols.h
> index 22099bb4079f..6c6317462be0 100644
> --- a/include/xen/interface/io/protocols.h
> +++ b/include/xen/interface/io/protocols.h
> @@ -6,6 +6,7 @@
>  #define XEN_IO_PROTO_ABI_X86_64     "x86_64-abi"
>  #define XEN_IO_PROTO_ABI_POWERPC64  "powerpc64-abi"
>  #define XEN_IO_PROTO_ABI_ARM        "arm-abi"
> +#define XEN_IO_PROTO_ABI_RISCV      "riscv-abi"
>
>  #if defined(__i386__)
>  # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_X86_32
> @@ -15,6 +16,8 @@
>  # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_POWERPC64
>  #elif defined(__arm__) || defined(__aarch64__)
>  # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_ARM
> +#elif defined(__riscv)
> +# define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_RISCV
>  #else
>  # error arch fixup needed here
>  #endif
> diff --git a/include/xen/riscv/hypercall.h b/include/xen/riscv/hypercall.=
h
> new file mode 100644
> index 000000000000..f76d8a018f26
> --- /dev/null
> +++ b/include/xen/riscv/hypercall.h
> @@ -0,0 +1,71 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/***********************************************************************=
*******
> + * hypercall.h
> + *
> + * Linux-specific hypervisor handling.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version 2
> + * as published by the Free Software Foundation; or, when distributed
> + * separately from the Linux kernel or incorporated into other
> + * software packages, subject to the following license:
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining=
 a copy
> + * of this source file (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use, copy, mo=
dify,
> + * merge, publish, distribute, sublicense, and/or sell copies of the Sof=
tware,
> + * and to permit persons to whom the Software is furnished to do so, sub=
ject to
> + * the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be includ=
ed in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRE=
SS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILI=
TY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHA=
LL THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHE=
R
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISI=
NG
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER D=
EALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +#ifndef _ASM_RISCV_XEN_HYPERCALL_H
> +#define _ASM_RISCV_XEN_HYPERCALL_H
> +
> +#include <linux/bug.h>
> +
> +#include <xen/interface/xen.h>
> +#include <xen/interface/sched.h>
> +#include <xen/interface/platform.h>
> +
> +struct xen_dm_op_buf;
> +
> +long privcmd_call(unsigned int call, unsigned long a1,
> +               unsigned long a2, unsigned long a3,
> +               unsigned long a4, unsigned long a5);
> +int HYPERVISOR_xen_version(int cmd, void *arg);
> +int HYPERVISOR_console_io(int cmd, int count, char *str);
> +int HYPERVISOR_grant_table_op(unsigned int cmd, void *uop, unsigned int =
count);
> +int HYPERVISOR_sched_op(int cmd, void *arg);
> +int HYPERVISOR_event_channel_op(int cmd, void *arg);
> +unsigned long HYPERVISOR_hvm_op(int op, void *arg);
> +int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
> +int HYPERVISOR_physdev_op(int cmd, void *arg);
> +int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
> +int HYPERVISOR_vm_assist(unsigned int cmd, unsigned int type);
> +int HYPERVISOR_dm_op(domid_t domid, unsigned int nr_bufs,
> +                        struct xen_dm_op_buf *bufs);
> +int HYPERVISOR_platform_op_raw(void *arg);
> +static inline int HYPERVISOR_platform_op(struct xen_platform_op *op)
> +{
> +       return 0;
> +}
> +int HYPERVISOR_multicall(struct multicall_entry *calls, uint32_t nr);
> +
> +static inline int
> +HYPERVISOR_suspend(unsigned long start_info_mfn)
> +{
> +       return 0;
> +}
> +
> +#endif /* _ASM_RISCV_XEN_HYPERCALL_H */
> diff --git a/include/xen/riscv/hypervisor.h b/include/xen/riscv/hyperviso=
r.h
> new file mode 100644
> index 000000000000..2c1f9625be80
> --- /dev/null
> +++ b/include/xen/riscv/hypervisor.h
> @@ -0,0 +1,26 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _ASM_RISCV_XEN_HYPERVISOR_H
> +#define _ASM_RISCV_XEN_HYPERVISOR_H
> +
> +#include <linux/init.h>
> +
> +extern struct shared_info *HYPERVISOR_shared_info;
> +extern struct start_info *xen_start_info;
> +
> +#ifdef CONFIG_XEN
> +void __init xen_early_init(void);
> +#else
> +static inline void xen_early_init(void) { return; }
> +#endif
> +
> +#ifdef CONFIG_HOTPLUG_CPU
> +static inline void xen_arch_register_cpu(int num)
> +{
> +}
> +
> +static inline void xen_arch_unregister_cpu(int num)
> +{
> +}
> +#endif
> +
> +#endif /* _ASM_RISCV_XEN_HYPERVISOR_H */
> diff --git a/include/xen/riscv/interface.h b/include/xen/riscv/interface.=
h
> new file mode 100644
> index 000000000000..6769b5b39cba
> --- /dev/null
> +++ b/include/xen/riscv/interface.h
> @@ -0,0 +1,85 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/***********************************************************************=
*******
> + * Guest OS interface to RISCV Xen.
> + *
> + */
> +
> +#ifndef _ASM_RISCV_XEN_INTERFACE_H
> +#define _ASM_RISCV_XEN_INTERFACE_H
> +
> +#include <linux/types.h>
> +
> +#define uint64_aligned_t uint64_t __aligned(8)
> +
> +#define __DEFINE_GUEST_HANDLE(name, type) \
> +       typedef struct { union { type * p; uint64_aligned_t q; }; }  \
> +               __guest_handle_ ## name
> +
> +#define DEFINE_GUEST_HANDLE_STRUCT(name) \
> +       __DEFINE_GUEST_HANDLE(name, struct name)
> +#define DEFINE_GUEST_HANDLE(name) __DEFINE_GUEST_HANDLE(name, name)
> +#define GUEST_HANDLE(name)        __guest_handle_ ## name
> +
> +#define set_xen_guest_handle(hnd, val)                 \
> +       do {                                            \
> +               if (sizeof(hnd) =3D=3D 8)                   \
> +                       *(uint64_t *)&(hnd) =3D 0;        \
> +               (hnd).p =3D val;                          \
> +       } while (0)
> +
> +#define __HYPERVISOR_platform_op_raw __HYPERVISOR_platform_op
> +
> +#ifndef __ASSEMBLY__
> +/* Explicitly size integers that represent pfns in the interface with
> + * Xen so that we can have one ABI that works for 32 and 64 bit guests.
> + * Note that this means that the xen_pfn_t type may be capable of
> + * representing pfn's which the guest cannot represent in its own pfn
> + * type. However since pfn space is controlled by the guest this is
> + * fine since it simply wouldn't be able to create any sure pfns in
> + * the first place.
> + */
> +typedef uint64_t xen_pfn_t;
> +#define PRI_xen_pfn "llx"
> +typedef uint64_t xen_ulong_t;
> +#define PRI_xen_ulong "llx"
> +typedef int64_t xen_long_t;
> +#define PRI_xen_long "llx"
> +/* Guest handles for primitive C types. */
> +__DEFINE_GUEST_HANDLE(uchar, unsigned char);
> +__DEFINE_GUEST_HANDLE(uint,  unsigned int);
> +DEFINE_GUEST_HANDLE(char);
> +DEFINE_GUEST_HANDLE(int);
> +DEFINE_GUEST_HANDLE(void);
> +DEFINE_GUEST_HANDLE(uint64_t);
> +DEFINE_GUEST_HANDLE(uint32_t);
> +DEFINE_GUEST_HANDLE(xen_pfn_t);
> +DEFINE_GUEST_HANDLE(xen_ulong_t);
> +
> +/* Maximum number of virtual CPUs in multi-processor guests. */
> +#define MAX_VIRT_CPUS 1
> +
> +struct arch_vcpu_info { };
> +struct arch_shared_info { };
> +
> +/* TODO: Move pvclock definitions some place arch independent */
> +struct pvclock_vcpu_time_info {
> +       u32   version;
> +       u32   pad0;
> +       u64   tsc_timestamp;
> +       u64   system_time;
> +       u32   tsc_to_system_mul;
> +       s8    tsc_shift;
> +       u8    flags;
> +       u8    pad[2];
> +} __packed; /* 32 bytes */
> +
> +/* It is OK to have a 12 bytes struct with no padding because it is pack=
ed */
> +struct pvclock_wall_clock {
> +       u32   version;
> +       u32   sec;
> +       u32   nsec;
> +       u32   sec_hi;
> +} __packed;
> +#endif
> +
> +#endif /* _ASM_RISCV_XEN_INTERFACE_H */
> diff --git a/include/xen/riscv/page.h b/include/xen/riscv/page.h
> new file mode 100644
> index 000000000000..fe07a9bffa7e
> --- /dev/null
> +++ b/include/xen/riscv/page.h
> @@ -0,0 +1,106 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _ASM_RISCV_XEN_PAGE_H
> +#define _ASM_RISCV_XEN_PAGE_H
> +
> +#include <asm/page.h>
> +
> +#include <linux/pfn.h>
> +#include <linux/types.h>
> +#include <linux/dma-mapping.h>
> +#include <linux/pgtable.h>
> +
> +#include <xen/xen.h>
> +#include <xen/interface/grant_table.h>
> +
> +/* Xen machine address */
> +struct xmaddr {
> +       phys_addr_t maddr;
> +};
> +
> +/* Xen pseudo-physical address */
> +struct xpaddr {
> +       phys_addr_t paddr;
> +};
> +
> +#define XMADDR(x)      ((struct xmaddr) { .maddr =3D (x) })
> +#define XPADDR(x)      ((struct xpaddr) { .paddr =3D (x) })
> +
> +#define INVALID_P2M_ENTRY      (~0UL)
> +
> +/*
> + * The pseudo-physical frame (pfn) used in all the helpers is always bas=
ed
> + * on Xen page granularity (i.e 4KB).
> + *
> + * A Linux page may be split across multiple non-contiguous Xen page so =
we
> + * have to keep track with frame based on 4KB page granularity.
> + *
> + * PV drivers should never make a direct usage of those helpers (particu=
larly
> + * pfn_to_gfn and gfn_to_pfn).
> + */
> +
> +unsigned long __pfn_to_mfn(unsigned long pfn);
> +extern struct rb_root phys_to_mach;
> +
> +/* Pseudo-physical <-> Guest conversion */
> +static inline unsigned long pfn_to_gfn(unsigned long pfn)
> +{
> +       return 0;
> +}
> +
> +static inline unsigned long gfn_to_pfn(unsigned long gfn)
> +{
> +       return 0;
> +}
> +
> +/* Pseudo-physical <-> BUS conversion */
> +static inline unsigned long pfn_to_bfn(unsigned long pfn)
> +{
> +       return 0;
> +}
> +
> +static inline unsigned long bfn_to_pfn(unsigned long bfn)
> +{
> +       return 0;
> +}
> +
> +#define bfn_to_local_pfn(bfn)  bfn_to_pfn(bfn)
> +
> +/* VIRT <-> GUEST conversion */
> +#define virt_to_gfn(v)                                                  =
       \
> +       ({                                                               =
      \
> +               WARN_ON_ONCE(!virt_addr_valid(v));                       =
       \
> +               pfn_to_gfn(virt_to_phys(v) >> XEN_PAGE_SHIFT);           =
      \
> +       })
> +#define gfn_to_virt(m)         (__va(gfn_to_pfn(m) << XEN_PAGE_SHIFT))
> +
> +#define percpu_to_gfn(v)       \
> +       (pfn_to_gfn(per_cpu_ptr_to_phys(v) >> XEN_PAGE_SHIFT))
> +
> +static inline struct xmaddr arbitrary_virt_to_machine(void *vaddr)
> +{
> +       WARN_ON_ONCE(1);
> +       return (struct xmaddr){0};
> +}
> +
> +extern int set_foreign_p2m_mapping(struct gnttab_map_grant_ref *map_ops,
> +                                  struct gnttab_map_grant_ref *kmap_ops,
> +                                  struct page **pages, unsigned int coun=
t);
> +
> +extern int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unma=
p_ops,
> +                                        struct gnttab_unmap_grant_ref *k=
unmap_ops,
> +                                        struct page **pages, unsigned in=
t count);
> +
> +bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn);
> +bool __set_phys_to_machine_multi(unsigned long pfn, unsigned long mfn,
> +               unsigned long nr_pages);
> +
> +static inline bool set_phys_to_machine(unsigned long pfn, unsigned long =
mfn)
> +{
> +       return 0;
> +}
> +
> +bool xen_arch_need_swiotlb(struct device *dev,
> +                          phys_addr_t phys,
> +                          dma_addr_t dev_addr);
> +
> +#endif /* _ASM_RISCV_XEN_PAGE_H */
> diff --git a/include/xen/riscv/swiotlb-xen.h b/include/xen/riscv/swiotlb-=
xen.h
> new file mode 100644
> index 000000000000..97ecd8cbbc2d
> --- /dev/null
> +++ b/include/xen/riscv/swiotlb-xen.h
> @@ -0,0 +1,13 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _ASM_RISCV_SWIOTLB_XEN_H
> +#define _ASM_RISCV_SWIOTLB_XEN_H
> +
> +#include <xen/features.h>
> +#include <xen/xen.h>
> +
> +static inline int xen_swiotlb_detect(void)
> +{
> +       return 0;
> +}
> +
> +#endif /* _ASM_RISCV_SWIOTLB_XEN_H */
> diff --git a/test.txt b/test.txt
> new file mode 100644
> index 000000000000..e54267998982
> --- /dev/null
> +++ b/test.txt
> @@ -0,0 +1,21 @@
> +WARNING: added, moved or deleted file(s), does MAINTAINERS need updating=
?
> +#120:
> +new file mode 100644
> +
> +WARNING: do not add new typedefs
> +#808: FILE: include/xen/riscv/interface.h:15:
> ++      typedef struct { union { type * p; uint64_aligned_t q; }; }  \
> +
> +WARNING: please, no spaces at the start of a line
> +#1006: FILE: include/xen/riscv/swiotlb-xen.h:10:
> ++    return 0;$
> +
> +total: 0 errors, 3 warnings, 810 lines checked
> +
> +NOTE: For some of the reported defects, checkpatch may be able to
> +      mechanically convert to the typical style using --fix or --fix-inp=
lace.
> +
> +0001-riscv-Add-initial-Xen-guest-support-for-RISC-V.patch has style prob=
lems, please review.
> +
> +NOTE: If any of the errors are false positives, please report
> +      them to the maintainer, see CHECKPATCH in MAINTAINERS.
> --
> 2.43.0
>
>


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 17:07:41 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 17:07:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871611.1282590 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXkO8-0002Zj-Iu; Tue, 14 Jan 2025 17:07:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871611.1282590; Tue, 14 Jan 2025 17:07:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXkO8-0002Zc-En; Tue, 14 Jan 2025 17:07:36 +0000
Received: by outflank-mailman (input) for mailman id 871611;
 Tue, 14 Jan 2025 17:07: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
 <SRS0=ZRbf=UG=bugseng.com=simone.ballarin@srs-se1.protection.inumbo.net>)
 id 1tXkO7-0002ZW-AU
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 17:07:35 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0bc271be-d29a-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 18:07:33 +0100 (CET)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 by support.bugseng.com (Postfix) with ESMTPA id D43CD4EEC6EE;
 Tue, 14 Jan 2025 18:07:32 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 0bc271be-d29a-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1736874453; bh=HlJzU5W9ek/W+SStPI2l2dbgaZAUTJslVv8+FWFX00M=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=Dfx01khs1ewOS05sIsn7m9ibSjAmZh711HY/ZmZcSsqSej02ZTkRQEQvKySQ2bIBw
	 hOFN5lt5rVI0gDDGUvx8ApOY/OzkLY+mBq0puSaet0Oai+yYIttlFiWHIU2XSXENHz
	 VCm71UjCQECnkHp1UHuCNCuPT35i+FLyMg5DcRoV5bXm4GNZ0tVKCtVw7vZOHuFZGm
	 YQJvFQqwGkUiWCAa2eZDpwNMxedI69G0QTaAE4C2DpGNNJyRNy1U2IB9lnK/9fSKns
	 Zbf/SnU7l9zi7lVS59xS1xe+A2yR0VAumuwz29kvx4CrdaXlXDqqeGSAMo62rQx7Xu
	 PvZGITxUMZjqA==
MIME-Version: 1.0
Date: Tue, 14 Jan 2025 18:07:32 +0100
From: Simone Ballarin <simone.ballarin@bugseng.com>
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org,
 michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com,
 consulting@bugseng.com, Andrew Cooper <andrew.cooper3@citrix.com>, Anthony
 PERARD <anthony.perard@vates.tech>, Jan Beulich <jbeulich@suse.com>, Julien
 Grall <julien@xen.org>, Simone Ballarin <simone.ballarin@bugseng.com>,
 Nicola Vetrini <nicola.vetrini@bugseng.com>
Subject: Re: [XEN PATCH] MAINTAINERS: Change reviewer of the ECLAIR
 integration
In-Reply-To: <Z4Z8IMWuz0UqldN9@macbook.local>
References: <8c370ced911457c883360836bd5afda747426a13.1736856521.git.nicola.vetrini@bugseng.com>
 <Z4Z8IMWuz0UqldN9@macbook.local>
Message-ID: <31259db8185522b14a61ac021f76d6fd@bugseng.com>
X-Sender: simone.ballarin@bugseng.com
Organization: BUGSENG
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit

On 2025-01-14 16:00, Roger Pau Monné wrote:
> On Tue, Jan 14, 2025 at 03:48:54PM +0100, Nicola Vetrini wrote:
>> Simone Ballarin is no longer actively involved in reviewing
>> the ECLAIR integration for Xen. I am stepping up as a reviewer.
>> 
>> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
> 
> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
> 

Acked-by: Simone Ballarin <simone.ballarin@bugseng.com>

> Adding Simone to the Cc list, it would be helpful if he can also
> provide an Ack to signal he is OK with begin removed.
> 
> Thanks, Roger.



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 17:44:09 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 17:44:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871622.1282601 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXkxH-00008E-45; Tue, 14 Jan 2025 17:43:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871622.1282601; Tue, 14 Jan 2025 17:43:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXkxG-000084-Vb; Tue, 14 Jan 2025 17:43:54 +0000
Received: by outflank-mailman (input) for mailman id 871622;
 Tue, 14 Jan 2025 17:43: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
 <SRS0=iLru=UG=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tXkxG-00007t-6M
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 17:43:54 +0000
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com
 [2a00:1450:4864:20::52b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1d292456-d29f-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 18:43:50 +0100 (CET)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-5d3d143376dso8301655a12.3
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 09:43:50 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d9900c435bsm6318583a12.27.2025.01.14.09.43.48
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 14 Jan 2025 09:43:48 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1d292456-d29f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736876629; x=1737481429; 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=S7G4MlUHu1n7J9U4fkD7VebSjvuwWh3bWJV+pig280U=;
        b=hof4V73YjmqTXXTI9tzvABzGIu6T7uDjQT+JuJu3EgI9dnpj3/zWkpLMDiT0tlzkUl
         Regn58l5wck9XAczaxEYp18PhFsQ0W3r5e3wzch4594krkoPCfFqgTuRrmp+glA+7L0B
         M7C1f7sZm3hrNO+W3CLJeUc134pkpxladszeM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736876629; x=1737481429;
        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=S7G4MlUHu1n7J9U4fkD7VebSjvuwWh3bWJV+pig280U=;
        b=r7WvltvfssAMTXAf3s6HSnoaeadnxmMbkPxsGsJUAaEdXGtbB5/P1ki6Reso/JyvDj
         +YiQW5MQiAbPcs/Xk5StlCIACsqCqArTQ9k5DN8eAZrCxkSvZdexeewqsSGwCdpX0BhF
         70TwIHKjUaUPYbwolFD//judjtEjMYQhdGnz7mumizIAkoW9zf7fLp667DP5YzwpWdM4
         KvwenHBv2so3/tKRr5gERRK12iREhi0ETu6rcDnonRcxbKdPiOhu1WaKmnC5a71wMY6i
         myWdzHHtxnso5j+4Bxl3qq9ayIDtnaEINcUNAkTqpcUe+w8rBzCd9nhjnnu/a5fQAPuJ
         kx4w==
X-Gm-Message-State: AOJu0Yza6r+q5sM+esURj2LNUeX1JjvPcHKFxOLexLO/nJ2+QT01EuDY
	fG3W4ipl1JJVPVEcS9CQoZJMb6Myx8J++1tofqveZLktTe7Z/XevqLCctqiP11+/iDoCChtd/8z
	X
X-Gm-Gg: ASbGncsqsgAjDQmaHUvcBWS5yOsSnN9RUukB59qSeDmuRYeWGNWt8OTtnLE4Um7Y50z
	hcpBPEJasAjiKSjVo3Syck6yYcP17OBc5EGxe0Wit3fZBRJGzNsYRdU7AhvVfrTxqdyFP141Jen
	+amMSWb96OyJ5FQswHX7tmL8o37+G5UOUl7Xck1CS2JQGXqGvYzYsoFUQCp5anjuP+VqP10jtSE
	ypaR/PdAjpjnBMMDKK+Gfp1cgWpwkW67PRMEpLXWysIdH2taxKV2F52PwP2Cg==
X-Google-Smtp-Source: AGHT+IEx8Jfszc85JWJM/EvBe/xXV9e9+9ZgxMTMo4OKPAi2BEw7HdLUb+heJNOppBqLInqGUaF5+w==
X-Received: by 2002:a05:6402:2808:b0:5d3:ba42:ea03 with SMTP id 4fb4d7f45d1cf-5d972e0674bmr21290563a12.8.1736876629486;
        Tue, 14 Jan 2025 09:43:49 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Doug Goldstein <cardoe@cardoe.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>
Subject: [PATCH for-4.20] automation/gitlab: disable coverage from clang randconfig
Date: Tue, 14 Jan 2025 18:43:45 +0100
Message-ID: <20250114174345.60887-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

If randconfig enables coverage support the build times out due to GNU LD
taking too long.  For the time being prevent coverage from being enabled in
clang randconfig job.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Cc: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
I will fix the orphaned section stuff separately, as I'm considering just
removing LLVM coverage support because the llvm coverage format is not
stable, and the code to dump it has already become stale.  However I need
to think about it, and in the short term disabling coverage support from
randconfig is more straightforward.
---
 automation/gitlab-ci/build.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
index cb84f379b754..bc4a8a5ad20c 100644
--- a/automation/gitlab-ci/build.yaml
+++ b/automation/gitlab-ci/build.yaml
@@ -556,6 +556,8 @@ debian-12-x86_64-clang-randconfig:
   variables:
     CONTAINER: debian:12-x86_64
     RANDCONFIG: y
+    EXTRA_FIXED_RANDCONFIG: |
+      CONFIG_COVERAGE=n # Disable coverage otherwise build times out.
 
 debian-12-x86_64-gcc:
   extends: .gcc-x86-64-build
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 17:48:26 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 17:48:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871631.1282609 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXl1d-0000hL-IG; Tue, 14 Jan 2025 17:48:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871631.1282609; Tue, 14 Jan 2025 17:48:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXl1d-0000hE-Fi; Tue, 14 Jan 2025 17:48:25 +0000
Received: by outflank-mailman (input) for mailman id 871631;
 Tue, 14 Jan 2025 17:48:24 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=tIyo=UG=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tXl1c-0000h8-2A
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 17:48:24 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bf166675-d29f-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 18:48:22 +0100 (CET)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-aaf0f1adef8so1220212866b.3
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 09:48:22 -0800 (PST)
Received: from [10.81.35.177] ([46.149.103.14])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c95b1bb6sm655502766b.159.2025.01.14.09.48.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 14 Jan 2025 09:48:21 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: bf166675-d29f-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736876901; x=1737481701; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=r6oNJN1eINmgsqALrqyDnvakvimZUgWCgoqWrsJsb9U=;
        b=PhTGXfX2XeVbkEhTCWGnBG5ejhKbAxY8td1aqSs7MMWnR2MiQdT3Nop9bBxbOtw8wM
         4wHX6ozd7rs3TKks4X7C+m1Ue3mC715vvcaUgV0HO+2FvN02GG6m8DoXjHEtB0CtwuI4
         ifRkUCEfvlEOTRiKj/eCyh7aDi/Bwnv275KnM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736876901; x=1737481701;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=r6oNJN1eINmgsqALrqyDnvakvimZUgWCgoqWrsJsb9U=;
        b=sSNyQxm7jmT2hJKDEK0OAZGAHj2uQK63/c4mOMpERwg5hSgWG0/rBoM9Og74wVpQeF
         ciQbvKYhdQkURHB6qxYY7b5rfuvnFcw3HEg81F/dmMU3EaZ/WoVlgOMCZBKUuVz4aIqU
         cqIj7BHLUDSi4Pa10SPRrKKdNMvR6noGejhbAxBYHi92iVgHip5YRUWDg7UZPNoS1XBC
         PLFCb9mEd3Pdo1P0dfRpb63NVZkExV4vV7ft7Y9PFlduAaWuaMR2nuhanyy5Orz072IB
         lqk0m4IOrYYTC3QvJPMRv2J5kiLYSnBwA/pOFjt8boPMFdXKWsjdqPGEFocOL4uuVngi
         FmgA==
X-Forwarded-Encrypted: i=1; AJvYcCW5DRUX8gWWpwPoeFmKFoGyxaHahEaq/8t2h/MuDcjmWFDVL9GHLZSmAyuJw1AJilvME1HR/aPvctk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwlI6HsLcnO+r7aIGtE6yv2cJVTbdUX4OqCsKFSsLAzPagmsMeh
	+oOP4rgInjYPxzk7GY4xHzB+EqGkw8nA9Q68rE8ywy+6mC7unuA7jBls+jNgRZ2qWLe0Hviv2JN
	B
X-Gm-Gg: ASbGncuz9WR6pLgL4U/mTnY7RwNl4FIpJ43SU84RPj/lsCI5OxibufXkAev0UWspGsR
	ltwmtXaDGeibTIRjftGgVVTwgL2CyX/sF8RA5f2v4YHX+fjPEbRtVuQuYI9rE7MAbfOhX7Pi/B/
	gzldxeCCn6gBpgntudRXhAC+QUQmfIKEu2lyoahJi4owtZYr0eWgLtPttqV/+QGGNSIyU1y+Cxb
	fwE3VkWWBublVsXBRlcGc7fci7h3sXoxAxNy8blvOz5jgWqjVX0E8zP4cpaYObGgK0=
X-Google-Smtp-Source: AGHT+IE9hjYI4wc/tvpZ86gYpx14zl0zxXPjfrc+VndMXGhVgy6UjyJLrb918EYw4/FsYhpcPUEoTg==
X-Received: by 2002:a17:907:3f26:b0:ab2:da92:d0bc with SMTP id a640c23a62f3a-ab2da92d9cemr1918284366b.3.1736876901471;
        Tue, 14 Jan 2025 09:48:21 -0800 (PST)
Message-ID: <c715348e-0f40-4ac4-b38e-1aead29cde52@citrix.com>
Date: Tue, 14 Jan 2025 17:48:20 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20] automation/gitlab: disable coverage from clang
 randconfig
To: Roger Pau Monne <roger.pau@citrix.com>, xen-devel@lists.xenproject.org
Cc: Doug Goldstein <cardoe@cardoe.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>
References: <20250114174345.60887-1-roger.pau@citrix.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <20250114174345.60887-1-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 14/01/2025 5:43 pm, Roger Pau Monne wrote:
> If randconfig enables coverage support the build times out due to GNU LD
> taking too long.  For the time being prevent coverage from being enabled in
> clang randconfig job.
>
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

> ---
> Cc: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> ---
> I will fix the orphaned section stuff separately, as I'm considering just
> removing LLVM coverage support because the llvm coverage format is not
> stable, and the code to dump it has already become stale.  However I need
> to think about it, and in the short term disabling coverage support from
> randconfig is more straightforward.

Oh, so it's broken too?  Unless the fix is trivial, we should have a
Kconfig level disable on it.  No point letting people turn on something
that's broken.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 17:52:03 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 17:52:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871640.1282619 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXl56-0002YE-0P; Tue, 14 Jan 2025 17:52:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871640.1282619; Tue, 14 Jan 2025 17:51:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXl55-0002Y7-Ts; Tue, 14 Jan 2025 17:51:59 +0000
Received: by outflank-mailman (input) for mailman id 871640;
 Tue, 14 Jan 2025 17:51:58 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=OE6R=UG=bounce.vates.tech=bounce-md_30504962.6786a43a.v1-16d5f6469727431f935812596bcb2286@srs-se1.protection.inumbo.net>)
 id 1tXl54-0002Xz-Al
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 17:51:58 +0000
Received: from mail128-16.atl41.mandrillapp.com
 (mail128-16.atl41.mandrillapp.com [198.2.128.16])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3e808a9a-d2a0-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 18:51:56 +0100 (CET)
Received: from pmta08.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail128-16.atl41.mandrillapp.com (Mailchimp) with ESMTP id
 4YXcBy5nJdzRKLlGc
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 17:51:54 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 16d5f6469727431f935812596bcb2286; Tue, 14 Jan 2025 17:51:54 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 3e808a9a-d2a0-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1736877114; x=1737137614;
	bh=az8rpG0APRcxLiWSmI+/bj3xR4gqvWnpdGPbdfScdrk=;
	h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=VlGpXUuJn8Jz2oaK/ZJTwN0W9aMXf793YJWAokZMUSmPjFJwKM8j/ByKpeZs5AUZk
	 zczuJj22N4ZDbsYtqv6N0Y7z58wHQqXthFQ1i3rtL51OtZS1/DlIGM7j6l3mR9C2Su
	 Aw3BZtrqrJo9Tn+E4Uq04wtcaCTFAONz5GFLdvCCnpB3ZkAATbxB7v0Oj31Oek6e6s
	 bQzdKxZ0319KbTJEaEayqB3AP6GUPxGLMj8keOxoUvzzDPNEZ6iG3Fq2o5QLQzyX4X
	 /BwVD+rhyCqLbirP979/6RTnsBwU8jWJAJ7H5E+O1spqWT0sp2TLbkqUVlLhDgerhX
	 xxBZfSjcoLYAw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1736877114; x=1737137614; i=teddy.astie@vates.tech;
	bh=az8rpG0APRcxLiWSmI+/bj3xR4gqvWnpdGPbdfScdrk=;
	h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=YyNTQjEFcCrEpflceEe0lOYeKaDMVTiRW5SXUCaIVTzXPQvxMrr+yUI5zDB/4e97w
	 4vo58Y7uwgZL+Jw/0bXI1f3nP6+xQIR8ehKzWQipHfQ1tKpUvMgDmBGkOU7S5RfpR0
	 jlkdZlV30mgo9BvdgGtMW2sq1deCDjzg1e7OWDmsci1qriVm01I3SYCqHwdF1bGFli
	 Jxu7PIsBn59BI8XWp8sILKz/eMoaWTLhdlKRJd2k5zxUZH8trrOkMzGN06NXzoOwTK
	 irQfj7NJDURr/rEM6MviOfkPW0eyg2U9Td5iaVdkGEedSTOHYSFreTbj5Hg/uhvSR8
	 /1aXJF9knFBYQ==
From: "Teddy Astie" <teddy.astie@vates.tech>
Subject: =?utf-8?Q?Re:=20[PATCH]=20riscv:=20Add=20initial=20Xen=20guest=20support=20for=20RISC-V?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1736877112710
Message-Id: <0cac0b13-128c-4d8b-b235-09d7b440ad8e@vates.tech>
To: "Milan Djokic" <milandjokic1995@gmail.com>, linux-riscv@lists.infradead.org
Cc: paul.walmsley@sifive.com, palmer@dabbelt.com, aou@eecs.berkeley.edu, jgross@suse.com, sstabellini@kernel.org, oleksandr_tyshchenko@epam.com, Slavisa.Petrovic@rt-rk.com, Milan.Djokic@rt-rk.com, rafael.j.wysocki@intel.com, sunilvl@ventanamicro.com, takakura@valinux.co.jp, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, iommu@lists.linux.dev
References: <e4a649a7fdfc8fcf5f48a0bc4e76e5d546078083.1736868605.git.Slavisa.Petrovic@rt-rk.com>
In-Reply-To: <e4a649a7fdfc8fcf5f48a0bc4e76e5d546078083.1736868605.git.Slavisa.Petrovic@rt-rk.com>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.16d5f6469727431f935812596bcb2286?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250114:md
Date: Tue, 14 Jan 2025 17:51:54 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Le 14/01/2025 =C3=A0 17:13, Milan Djokic a =C3=A9crit=C2=A0:
> diff --git a/test.txt b/test.txt
> new file mode 100644
> index 000000000000..e54267998982
> --- /dev/null
> +++ b/test.txt
> @@ -0,0 +1,21 @@
> +WARNING: added, moved or deleted file(s), does MAINTAINERS need updating=
?
> +#120:
> +new file mode 100644
> +
> +WARNING: do not add new typedefs
> +#808: FILE: include/xen/riscv/interface.h:15:
> ++=09typedef struct { union { type * p; uint64_aligned_t q; }; }  \
> +
> +WARNING: please, no spaces at the start of a line
> +#1006: FILE: include/xen/riscv/swiotlb-xen.h:10:
> ++    return 0;$
> +
> +total: 0 errors, 3 warnings, 810 lines checked
> +
> +NOTE: For some of the reported defects, checkpatch may be able to
> +      mechanically convert to the typical style using --fix or --fix-inp=
lace.
> +
> +0001-riscv-Add-initial-Xen-guest-support-for-RISC-V.patch has style prob=
lems, please review.
> +
> +NOTE: If any of the errors are false positives, please report
> +      them to the maintainer, see CHECKPATCH in MAINTAINERS.

I am not sure you want this here.

 > diff --git a/arch/riscv/include/asm/hypervisor.h 
b/arch/riscv/include/> asm/hypervisor.h
 > new file mode 100644
 > index 000000000000..3a117afe57f0
 > --- /dev/null
 > +++ b/arch/riscv/include/asm/hypervisor.h
 > @@ -0,0 +1,9 @@
 > +/* SPDX-License-Identifier: GPL-2.0 */
 > +#ifndef _ASM_RISCV_HYPERVISOR_H
 > +#define _ASM_RISCV_HYPERVISOR_H
 > +
 > +#include <asm/xen/hypervisor.h>
 > +
 > +void kvm_init_hyp_services(void);
 > +
 > +#endif

kvm_init_hyp_services seems KVM-specific and doesn't seem to exist (yet) 
for RISC-V.

Teddy


Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 17:58:53 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 17:58:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871650.1282636 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlBi-0003Ll-PY; Tue, 14 Jan 2025 17:58:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871650.1282636; Tue, 14 Jan 2025 17:58:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlBi-0003KG-KI; Tue, 14 Jan 2025 17:58:50 +0000
Received: by outflank-mailman (input) for mailman id 871650;
 Tue, 14 Jan 2025 17:53:29 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=5Qro=UG=redhat.com=vschneid@srs-se1.protection.inumbo.net>)
 id 1tXl6X-00036s-7P
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 17:53:29 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 745ba2d5-d2a0-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 18:53:27 +0100 (CET)
Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-118-EPzVHimUPgaLyL-8ZboJxw-1; Tue,
 14 Jan 2025 12:53:20 -0500
Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 4B02F19560B2; Tue, 14 Jan 2025 17:53:14 +0000 (UTC)
Received: from vschneid-thinkpadt14sgen2i.remote.csb (unknown [10.39.192.55])
 by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix)
 with ESMTPS id 8C28819560B7; Tue, 14 Jan 2025 17:52:48 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 745ba2d5-d2a0-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1736877205;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=fONXSYmqO3wil+TvuZe7xaKAIHytdle1lhLahiVcjdY=;
	b=NDeWe24rEVylwuBHvK5ep6/9Tw2LGkVF82qmuXq2mBuIi/pQvFfKeT4nMR4BZqoO5hCKYt
	oqcSFYcfBOlz9jGvEFvTLVDeiU6q7YTbCZc6dPtD3wlwZgkM7AFWtmYLkvIi6YapdM6SQO
	U86H2e61eJNBKZdX3HgyTtwBeyDFQVQ=
X-MC-Unique: EPzVHimUPgaLyL-8ZboJxw-1
X-Mimecast-MFC-AGG-ID: EPzVHimUPgaLyL-8ZboJxw
From: Valentin Schneider <vschneid@redhat.com>
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	virtualization@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	loongarch@lists.linux.dev,
	linux-riscv@lists.infradead.org,
	linux-perf-users@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	kvm@vger.kernel.org,
	linux-arch@vger.kernel.org,
	rcu@vger.kernel.org,
	linux-hardening@vger.kernel.org,
	linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org,
	bpf@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com
Cc: Josh Poimboeuf <jpoimboe@kernel.org>,
	Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.amakhalov@broadcom.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andy Lutomirski <luto@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Clark Williams <williams@redhat.com>,
	Yair Podemsky <ypodemsk@redhat.com>,
	Tomas Glozar <tglozar@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>,
	Mel Gorman <mgorman@suse.de>,
	Kees Cook <kees@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Shuah Khan <shuah@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Alice Ryhl <aliceryhl@google.com>,
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
	Samuel Holland <samuel.holland@sifive.com>,
	Rong Xu <xur@google.com>,
	Nicolas Saenz Julienne <nsaenzju@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Yosry Ahmed <yosryahmed@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Jinghao Jia <jinghao7@illinois.edu>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: [PATCH v4 01/30] objtool: Make validate_call() recognize indirect calls to pv_ops[]
Date: Tue, 14 Jan 2025 18:51:14 +0100
Message-ID: <20250114175143.81438-2-vschneid@redhat.com>
In-Reply-To: <20250114175143.81438-1-vschneid@redhat.com>
References: <20250114175143.81438-1-vschneid@redhat.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15

call_dest_name() does not get passed the file pointer of validate_call(),
which means its invocation of insn_reloc() will always return NULL. Make it
take a file pointer.

While at it, make sure call_dest_name() uses arch_dest_reloc_offset(),
otherwise it gets the pv_ops[] offset wrong.

Fabricating an intentional warning shows the change; previously:

  vmlinux.o: warning: objtool: __flush_tlb_all_noinstr+0x4: call to {dynamic}() leaves .noinstr.text section

now:

  vmlinux.o: warning: objtool: __flush_tlb_all_noinstr+0x4: call to pv_ops[1]() leaves .noinstr.text section

Signed-off-by: Valentin Schneider <vschneid@redhat.com>
Acked-by: Josh Poimboeuf <jpoimboe@kernel.org>
---
 tools/objtool/check.c | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 76060da755b5c..b35763f05a548 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -3448,7 +3448,7 @@ static inline bool func_uaccess_safe(struct symbol *func)
 	return false;
 }
 
-static inline const char *call_dest_name(struct instruction *insn)
+static inline const char *call_dest_name(struct objtool_file *file, struct instruction *insn)
 {
 	static char pvname[19];
 	struct reloc *reloc;
@@ -3457,9 +3457,9 @@ static inline const char *call_dest_name(struct instruction *insn)
 	if (insn_call_dest(insn))
 		return insn_call_dest(insn)->name;
 
-	reloc = insn_reloc(NULL, insn);
+	reloc = insn_reloc(file, insn);
 	if (reloc && !strcmp(reloc->sym->name, "pv_ops")) {
-		idx = (reloc_addend(reloc) / sizeof(void *));
+		idx = (arch_dest_reloc_offset(reloc_addend(reloc)) / sizeof(void *));
 		snprintf(pvname, sizeof(pvname), "pv_ops[%d]", idx);
 		return pvname;
 	}
@@ -3538,17 +3538,19 @@ static int validate_call(struct objtool_file *file,
 {
 	if (state->noinstr && state->instr <= 0 &&
 	    !noinstr_call_dest(file, insn, insn_call_dest(insn))) {
-		WARN_INSN(insn, "call to %s() leaves .noinstr.text section", call_dest_name(insn));
+		WARN_INSN(insn, "call to %s() leaves .noinstr.text section", call_dest_name(file, insn));
 		return 1;
 	}
 
 	if (state->uaccess && !func_uaccess_safe(insn_call_dest(insn))) {
-		WARN_INSN(insn, "call to %s() with UACCESS enabled", call_dest_name(insn));
+		WARN_INSN(insn, "call to %s() with UACCESS enabled",
+			  call_dest_name(file, insn));
 		return 1;
 	}
 
 	if (state->df) {
-		WARN_INSN(insn, "call to %s() with DF set", call_dest_name(insn));
+		WARN_INSN(insn, "call to %s() with DF set",
+			  call_dest_name(file, insn));
 		return 1;
 	}
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 17:58:53 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 17:58:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871663.1282679 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlBl-00043t-6O; Tue, 14 Jan 2025 17:58:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871663.1282679; Tue, 14 Jan 2025 17:58:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlBk-00042L-OK; Tue, 14 Jan 2025 17:58:52 +0000
Received: by outflank-mailman (input) for mailman id 871663;
 Tue, 14 Jan 2025 17:56:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=5Qro=UG=redhat.com=vschneid@srs-se1.protection.inumbo.net>)
 id 1tXl92-0003Bm-RN
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 17:56:04 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d142d210-d2a0-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 18:56:02 +0100 (CET)
Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-20-jE76dcsZPt-31fHWsIhMBg-1; Tue,
 14 Jan 2025 12:55:57 -0500
Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 47A70195609E; Tue, 14 Jan 2025 17:55:53 +0000 (UTC)
Received: from vschneid-thinkpadt14sgen2i.remote.csb (unknown [10.39.192.55])
 by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix)
 with ESMTPS id 6703A195608A; Tue, 14 Jan 2025 17:55:28 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: d142d210-d2a0-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1736877361;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=P7DcLPe7N47ORcKkDkopF1lM4hKgrpRYFpILYCZNJJ8=;
	b=Y8bq5zS9poTwPOOLX/87Ai62n1gNtjuD+qKZs9wZ2f1MI5UPpAPNe2yWOJMwInm9qleWlQ
	IrsMbwNWkLbKkyxmWbcFYDuL7ldiaiHBlnnMI+m0y0MJkxEn2MUq8RYFZDHzZZosjdeD90
	hrXofc3s0DU17aYkucrM/wKa4rWuwvk=
X-MC-Unique: jE76dcsZPt-31fHWsIhMBg-1
X-Mimecast-MFC-AGG-ID: jE76dcsZPt-31fHWsIhMBg
From: Valentin Schneider <vschneid@redhat.com>
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	virtualization@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	loongarch@lists.linux.dev,
	linux-riscv@lists.infradead.org,
	linux-perf-users@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	kvm@vger.kernel.org,
	linux-arch@vger.kernel.org,
	rcu@vger.kernel.org,
	linux-hardening@vger.kernel.org,
	linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org,
	bpf@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com
Cc: Josh Poimboeuf <jpoimboe@kernel.org>,
	Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.amakhalov@broadcom.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andy Lutomirski <luto@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Clark Williams <williams@redhat.com>,
	Yair Podemsky <ypodemsk@redhat.com>,
	Tomas Glozar <tglozar@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>,
	Mel Gorman <mgorman@suse.de>,
	Kees Cook <kees@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Shuah Khan <shuah@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Alice Ryhl <aliceryhl@google.com>,
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
	Samuel Holland <samuel.holland@sifive.com>,
	Rong Xu <xur@google.com>,
	Nicolas Saenz Julienne <nsaenzju@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Yosry Ahmed <yosryahmed@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Jinghao Jia <jinghao7@illinois.edu>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: [PATCH v4 07/30] x86/paravirt: Mark pv_sched_clock static call as __ro_after_init
Date: Tue, 14 Jan 2025 18:51:20 +0100
Message-ID: <20250114175143.81438-8-vschneid@redhat.com>
In-Reply-To: <20250114175143.81438-1-vschneid@redhat.com>
References: <20250114175143.81438-1-vschneid@redhat.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15

Later commits will cause objtool to warn about static calls being used in
.noinstr sections in order to safely defer instruction patching IPIs
targeted at NOHZ_FULL CPUs.

pv_sched_clock is updated in:
o __init vmware_paravirt_ops_setup()
o __init xen_init_time_common()
o kvm_sched_clock_init() <- __init kvmclock_init()
o hv_setup_sched_clock() <- __init hv_init_tsc_clocksource()

IOW purely init context, and can thus be marked as __ro_after_init.

Reported-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Valentin Schneider <vschneid@redhat.com>
---
 arch/x86/kernel/paravirt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index fec3815335558..ae6675167877b 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -73,7 +73,7 @@ static u64 native_steal_clock(int cpu)
 }
 
 DEFINE_STATIC_CALL(pv_steal_clock, native_steal_clock);
-DEFINE_STATIC_CALL(pv_sched_clock, native_sched_clock);
+DEFINE_STATIC_CALL_RO(pv_sched_clock, native_sched_clock);
 
 void paravirt_set_sched_clock(u64 (*func)(void))
 {
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 17:58:54 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 17:58:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871648.1282631 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlBi-0003IL-HY; Tue, 14 Jan 2025 17:58:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871648.1282631; Tue, 14 Jan 2025 17:58:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlBi-0003IE-C7; Tue, 14 Jan 2025 17:58:50 +0000
Received: by outflank-mailman (input) for mailman id 871648;
 Tue, 14 Jan 2025 17:52:59 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=5Qro=UG=redhat.com=vschneid@srs-se1.protection.inumbo.net>)
 id 1tXl63-0002zS-9K
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 17:52:59 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.129.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 62a28cdc-d2a0-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 18:52:57 +0100 (CET)
Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-523-VoXCR5IgO0KVO9YPu5k6sw-1; Tue,
 14 Jan 2025 12:52:53 -0500
Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id F1D241956059; Tue, 14 Jan 2025 17:52:47 +0000 (UTC)
Received: from vschneid-thinkpadt14sgen2i.remote.csb (unknown [10.39.192.55])
 by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix)
 with ESMTPS id 62E9C195608A; Tue, 14 Jan 2025 17:52:18 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 62a28cdc-d2a0-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1736877176;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding;
	bh=eUZWh6RdpXqevgtwM7GO1PdkjkoPSVHNTkFKZr43JQk=;
	b=MwR6VkooiosStphOPkbg3KeNs/Jb6S49cVlzo5bGtXU2OJOO/Ii8ad184aGVcGp747LTpo
	3+37WW8zK3zIzl/RLQd3m10N63mhDOxQpyKdu4SoJSNFda3i6p4PjrGsuKjOv+b2w+11Cr
	whXJt04z8T3Aahn/X+lFJ68pUO2BQkE=
X-MC-Unique: VoXCR5IgO0KVO9YPu5k6sw-1
X-Mimecast-MFC-AGG-ID: VoXCR5IgO0KVO9YPu5k6sw
From: Valentin Schneider <vschneid@redhat.com>
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	virtualization@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	loongarch@lists.linux.dev,
	linux-riscv@lists.infradead.org,
	linux-perf-users@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	kvm@vger.kernel.org,
	linux-arch@vger.kernel.org,
	rcu@vger.kernel.org,
	linux-hardening@vger.kernel.org,
	linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org,
	bpf@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com
Cc: Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.amakhalov@broadcom.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andy Lutomirski <luto@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Clark Williams <williams@redhat.com>,
	Yair Podemsky <ypodemsk@redhat.com>,
	Tomas Glozar <tglozar@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>,
	Mel Gorman <mgorman@suse.de>,
	Kees Cook <kees@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Shuah Khan <shuah@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Alice Ryhl <aliceryhl@google.com>,
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
	Samuel Holland <samuel.holland@sifive.com>,
	Rong Xu <xur@google.com>,
	Nicolas Saenz Julienne <nsaenzju@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Yosry Ahmed <yosryahmed@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Jinghao Jia <jinghao7@illinois.edu>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: [PATCH v4 00/30] context_tracking,x86: Defer some IPIs until a user->kernel transition
Date: Tue, 14 Jan 2025 18:51:13 +0100
Message-ID: <20250114175143.81438-1-vschneid@redhat.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15

Context
=======

We've observed within Red Hat that isolated, NOHZ_FULL CPUs running a
pure-userspace application get regularly interrupted by IPIs sent from
housekeeping CPUs. Those IPIs are caused by activity on the housekeeping CPUs
leading to various on_each_cpu() calls, e.g.:

  64359.052209596    NetworkManager       0    1405     smp_call_function_many_cond (cpu=0, func=do_kernel_range_flush)
    smp_call_function_many_cond+0x1
    smp_call_function+0x39
    on_each_cpu+0x2a
    flush_tlb_kernel_range+0x7b
    __purge_vmap_area_lazy+0x70
    _vm_unmap_aliases.part.42+0xdf
    change_page_attr_set_clr+0x16a
    set_memory_ro+0x26
    bpf_int_jit_compile+0x2f9
    bpf_prog_select_runtime+0xc6
    bpf_prepare_filter+0x523
    sk_attach_filter+0x13
    sock_setsockopt+0x92c
    __sys_setsockopt+0x16a
    __x64_sys_setsockopt+0x20
    do_syscall_64+0x87
    entry_SYSCALL_64_after_hwframe+0x65

The heart of this series is the thought that while we cannot remove NOHZ_FULL
CPUs from the list of CPUs targeted by these IPIs, they may not have to execute
the callbacks immediately. Anything that only affects kernelspace can wait
until the next user->kernel transition, providing it can be executed "early
enough" in the entry code.

The original implementation is from Peter [1]. Nicolas then added kernel TLB
invalidation deferral to that [2], and I picked it up from there.

Deferral approach
=================

Storing each and every callback, like a secondary call_single_queue turned out
to be a no-go: the whole point of deferral is to keep NOHZ_FULL CPUs in
userspace for as long as possible - no signal of any form would be sent when
deferring an IPI. This means that any form of queuing for deferred callbacks
would end up as a convoluted memory leak.

Deferred IPIs must thus be coalesced, which this series achieves by assigning
IPIs a "type" and having a mapping of IPI type to callback, leveraged upon
kernel entry.

What about IPIs whose callback take a parameter, you may ask?

Peter suggested during OSPM23 [3] that since on_each_cpu() targets
housekeeping CPUs *and* isolated CPUs, isolated CPUs can access either global or
housekeeping-CPU-local state to "reconstruct" the data that would have been sent
via the IPI.

This series does not affect any IPI callback that requires an argument, but the
approach would remain the same (one coalescable callback executed on kernel
entry).

Kernel entry vs execution of the deferred operation
===================================================

This is what I've referred to as the "Danger Zone" during my LPC24 talk [4].

There is a non-zero length of code that is executed upon kernel entry before the
deferred operation can be itself executed (i.e. before we start getting into
context_tracking.c proper), i.e.:

  idtentry_func_foo()                <--- we're in the kernel
    irqentry_enter()
      enter_from_user_mode()
	__ct_user_exit()
	    ct_kernel_enter_state()
	      ct_work_flush()        <--- deferred operation is executed here

This means one must take extra care to what can happen in the early entry code,
and that <bad things> cannot happen. For instance, we really don't want to hit
instructions that have been modified by a remote text_poke() while we're on our
way to execute a deferred sync_core(). Patches doing the actual deferral have
more detail on this.

Patches
=======

o Patches 1-2 are standalone objtool cleanups.

o Patches 3-4 add an RCU testing feature.

o Patches 5-6 add infrastructure for annotating static keys and static calls
  that may be used in noinstr code (courtesy of Josh).
o Patches 7-19 use said annotations on relevant keys / calls.
o Patch 20 enforces proper usage of said annotations (courtesy of Josh).

o Patches 21-23 fiddle with CT_STATE* within context tracking

o Patches 24-29 add the actual IPI deferral faff

o Patch 30 adds a freebie: deferring IPIs for NOHZ_IDLE. Not tested that much!
  if you care about battery-powered devices and energy consumption, go give it
  a try!

Patches are also available at:
https://gitlab.com/vschneid/linux.git -b redhat/isolirq/defer/v4

Stuff I'd like eyes and neurons on
==================================

Context-tracking vs idle. Patch 22 "improves" the situation by adding an
IDLE->KERNEL transition when getting an IRQ while idle, but it leaves the
following window:

  ~> IRQ
  ct_nmi_enter()
    state = state + CT_STATE_KERNEL - CT_STATE_IDLE

  [...]

  ct_nmi_exit()
    state = state - CT_STATE_KERNEL + CT_STATE_IDLE

  [...] /!\ CT_STATE_IDLE here while we're really in kernelspace! /!\

  ct_cpuidle_exit()
    state = state + CT_STATE_KERNEL - CT_STATE_IDLE

Said window is contained within cpu_idle_poll() and the cpuidle call within
cpuidle_enter_state(), both being noinstr (the former is __cpuidle which is
noinstr itself). Thus objtool will consider it as early entry and will warn
accordingly of any static key / call misuse, so the damage is somewhat
contained, but it's not ideal.

I tried fiddling with this but idle polling likes being annoying, as it is
shaped like so:

	ct_cpuidle_enter();

	raw_local_irq_enable();
	while (!tif_need_resched() &&
	       (cpu_idle_force_poll || tick_check_broadcast_expired()))
		cpu_relax();
	raw_local_irq_disable();

	ct_cpuidle_exit();

IOW, getting an IRQ that doesn't end up setting NEED_RESCHED while idle-polling
doesn't come near ct_cpuidle_exit(), which prevents me from having the outermost
ct_nmi_exit() leave the state as CT_STATE_KERNEL (rather than CT_STATE_IDLE).

Testing
=======

Xeon E5-2699 system with SMToff, NOHZ_FULL, isolated CPUs.
RHEL9 userspace.

Workload is using rteval (kernel compilation + hackbench) on housekeeping CPUs
and a dummy stay-in-userspace loop on the isolated CPUs. The main invocation is:

$ trace-cmd record -e "csd_queue_cpu" -f "cpu & CPUS{$ISOL_CPUS}" \
 	           -e "ipi_send_cpumask" -f "cpumask & CPUS{$ISOL_CPUS}" \
	           -e "ipi_send_cpu"     -f "cpu & CPUS{$ISOL_CPUS}" \
		   rteval --onlyload --loads-cpulist=$HK_CPUS \
		   --hackbench-runlowmem=True --duration=$DURATION

This only records IPIs sent to isolated CPUs, so any event there is interference
(with a bit of fuzz at the start/end of the workload when spawning the
processes). All tests were done with a duration of 6 hours.

v6.13-rc6
# This is the actual IPI count
$ trace-cmd report | grep callback | awk '{ print $(NF) }' | sort | uniq -c | sort -nr
    531 callback=generic_smp_call_function_single_interrupt+0x0

# These are the different CSD's that caused IPIs    
$ trace-cmd report | grep csd_queue | awk '{ print $(NF-1) }' | sort | uniq -c | sort -nr
  12818 func=do_flush_tlb_all
    910 func=do_kernel_range_flush
     78 func=do_sync_core

v6.13-rc6 + patches:
# This is the actual IPI count
$ trace-cmd report | grep callback | awk '{ print $(NF) }' | sort | uniq -c | sort -nr
# Zilch!

# These are the different CSD's that caused IPIs          
$ trace-cmd report | grep csd_queue | awk '{ print $(NF-1) }' | sort | uniq -c | sort -nr
# Nada!

Note that tlb_remove_table_smp_sync() showed up during testing of v3, and has
gone as mysteriously as it showed up. Yair had a series adressing this [5] which
would be worth revisiting.

Acknowledgements
================

Special thanks to:
o Clark Williams for listening to my ramblings about this and throwing ideas my way
o Josh Poimboeuf for all his help with everything objtool-related
o All of the folks who attended various (too many?) talks about this and
  provided precious feedback.  

Links
=====

[1]: https://lore.kernel.org/all/20210929151723.162004989@infradead.org/
[2]: https://github.com/vianpl/linux.git -b ct-work-defer-wip
[3]: https://youtu.be/0vjE6fjoVVE
[4]: https://lpc.events/event/18/contributions/1889/
[5]: https://lore.kernel.org/lkml/20230620144618.125703-1-ypodemsk@redhat.com/

Revisions
=========

RFCv3 -> v4
++++++++++++++

o Rebased onto v6.13-rc6

o New objtool patches from Josh
o More .noinstr static key/call patches
o Static calls now handled as well (again thanks to Josh)

o Fixed clearing the work bits on kernel exit
o Messed with IRQ hitting an idle CPU vs context tracking
o Various comment and naming cleanups

o Made RCU_DYNTICKS_TORTURE depend on !COMPILE_TEST (PeterZ)
o Fixed the CT_STATE_KERNEL check when setting a deferred work (Frederic)
o Cleaned up the __flush_tlb_all() mess thanks to PeterZ

RFCv2 -> RFCv3
++++++++++++++

o Rebased onto v6.12-rc6

o Added objtool documentation for the new warning (Josh)
o Added low-size RCU watching counter to TREE04 torture scenario (Paul)
o Added FORCEFUL jump label and static key types
o Added noinstr-compliant helpers for tlb flush deferral


RFCv1 -> RFCv2
++++++++++++++

o Rebased onto v6.5-rc1

o Updated the trace filter patches (Steven)

o Fixed __ro_after_init keys used in modules (Peter)
o Dropped the extra context_tracking atomic, squashed the new bits in the
  existing .state field (Peter, Frederic)
  
o Added an RCU_EXPERT config for the RCU dynticks counter size, and added an
  rcutorture case for a low-size counter (Paul) 

o Fixed flush_tlb_kernel_range_deferrable() definition

Josh Poimboeuf (3):
  jump_label: Add annotations for validating noinstr usage
  static_call: Add read-only-after-init static calls
  objtool: Add noinstr validation for static branches/calls

Peter Zijlstra (1):
  x86,tlb: Make __flush_tlb_global() noinstr-compliant

Valentin Schneider (26):
  objtool: Make validate_call() recognize indirect calls to pv_ops[]
  objtool: Flesh out warning related to pv_ops[] calls
  rcu: Add a small-width RCU watching counter debug option
  rcutorture: Make TREE04 use CONFIG_RCU_DYNTICKS_TORTURE
  x86/paravirt: Mark pv_sched_clock static call as __ro_after_init
  x86/idle: Mark x86_idle static call as __ro_after_init
  x86/paravirt: Mark pv_steal_clock static call as __ro_after_init
  riscv/paravirt: Mark pv_steal_clock static call as __ro_after_init
  loongarch/paravirt: Mark pv_steal_clock static call as __ro_after_init
  arm64/paravirt: Mark pv_steal_clock static call as __ro_after_init
  arm/paravirt: Mark pv_steal_clock static call as __ro_after_init
  perf/x86/amd: Mark perf_lopwr_cb static call as __ro_after_init
  sched/clock: Mark sched_clock_running key as __ro_after_init
  x86/speculation/mds: Mark mds_idle_clear key as allowed in .noinstr
  sched/clock, x86: Mark __sched_clock_stable key as allowed in .noinstr
  x86/kvm/vmx: Mark vmx_l1d_should flush and vmx_l1d_flush_cond keys as
    allowed in .noinstr
  stackleack: Mark stack_erasing_bypass key as allowed in .noinstr
  context_tracking: Explicitely use CT_STATE_KERNEL where it is missing
  context_tracking: Exit CT_STATE_IDLE upon irq/nmi entry
  context_tracking: Turn CT_STATE_* into bits
  context-tracking: Introduce work deferral infrastructure
  context_tracking,x86: Defer kernel text patching IPIs
  x86/tlb: Make __flush_tlb_local() noinstr-compliant
  x86/tlb: Make __flush_tlb_all() noinstr
  x86/mm, mm/vmalloc: Defer flush_tlb_kernel_range() targeting NOHZ_FULL
    CPUs
  context-tracking: Add a Kconfig to enable IPI deferral for NO_HZ_IDLE

 arch/Kconfig                                  |   9 ++
 arch/arm/kernel/paravirt.c                    |   2 +-
 arch/arm64/kernel/paravirt.c                  |   2 +-
 arch/loongarch/kernel/paravirt.c              |   2 +-
 arch/riscv/kernel/paravirt.c                  |   2 +-
 arch/x86/Kconfig                              |   1 +
 arch/x86/events/amd/brs.c                     |   2 +-
 arch/x86/include/asm/context_tracking_work.h  |  22 ++++
 arch/x86/include/asm/invpcid.h                |  13 +--
 arch/x86/include/asm/paravirt.h               |   4 +-
 arch/x86/include/asm/text-patching.h          |   1 +
 arch/x86/include/asm/tlbflush.h               |   3 +-
 arch/x86/include/asm/xen/hypercall.h          |  11 +-
 arch/x86/kernel/alternative.c                 |  38 ++++++-
 arch/x86/kernel/cpu/bugs.c                    |   9 +-
 arch/x86/kernel/kprobes/core.c                |   4 +-
 arch/x86/kernel/kprobes/opt.c                 |   4 +-
 arch/x86/kernel/module.c                      |   2 +-
 arch/x86/kernel/paravirt.c                    |   4 +-
 arch/x86/kernel/process.c                     |   2 +-
 arch/x86/kvm/vmx/vmx.c                        |  11 +-
 arch/x86/mm/tlb.c                             |  46 ++++++--
 arch/x86/xen/mmu_pv.c                         |  10 +-
 arch/x86/xen/xen-ops.h                        |  12 +-
 include/asm-generic/sections.h                |  15 +++
 include/linux/context_tracking.h              |  21 ++++
 include/linux/context_tracking_state.h        |  64 +++++++++--
 include/linux/context_tracking_work.h         |  28 +++++
 include/linux/jump_label.h                    |  30 ++++-
 include/linux/objtool.h                       |   7 ++
 include/linux/static_call.h                   |  19 ++++
 kernel/context_tracking.c                     |  98 ++++++++++++++--
 kernel/rcu/Kconfig.debug                      |  15 +++
 kernel/sched/clock.c                          |   7 +-
 kernel/stackleak.c                            |   6 +-
 kernel/time/Kconfig                           |  19 ++++
 mm/vmalloc.c                                  |  35 +++++-
 tools/objtool/Documentation/objtool.txt       |  34 ++++++
 tools/objtool/check.c                         | 106 +++++++++++++++---
 tools/objtool/include/objtool/check.h         |   1 +
 tools/objtool/include/objtool/elf.h           |   1 +
 tools/objtool/include/objtool/special.h       |   1 +
 tools/objtool/special.c                       |  18 ++-
 .../selftests/rcutorture/configs/rcu/TREE04   |   1 +
 44 files changed, 635 insertions(+), 107 deletions(-)
 create mode 100644 arch/x86/include/asm/context_tracking_work.h
 create mode 100644 include/linux/context_tracking_work.h

--
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 17:58:53 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 17:58:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871652.1282641 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlBj-0003Ot-5A; Tue, 14 Jan 2025 17:58:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871652.1282641; Tue, 14 Jan 2025 17:58:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlBi-0003Ms-Rw; Tue, 14 Jan 2025 17:58:50 +0000
Received: by outflank-mailman (input) for mailman id 871652;
 Tue, 14 Jan 2025 17:53: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
 <SRS0=5Qro=UG=redhat.com=vschneid@srs-se1.protection.inumbo.net>)
 id 1tXl6v-00036s-DB
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 17:53:53 +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 8300704a-d2a0-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 18:53:51 +0100 (CET)
Received: from mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-269-5yEXaqhRNsqIKNRsVS1Lsw-1; Tue,
 14 Jan 2025 12:53:46 -0500
Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 91E941955D80; Tue, 14 Jan 2025 17:53:42 +0000 (UTC)
Received: from vschneid-thinkpadt14sgen2i.remote.csb (unknown [10.39.192.55])
 by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix)
 with ESMTPS id BE4B5195608A; Tue, 14 Jan 2025 17:53:14 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8300704a-d2a0-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1736877230;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=BIPe4J+MPkclOG0fZ/T6Ew0fi09A38ofFGJkEjEgffw=;
	b=RLVWfI37RN8n7WJ8HlkibxYjd7W0A13i/jpwkf19SDUK05V5oFRBish7S9SLz+x1RbjR36
	WWnC4cYmSu+wBe+/198POSqD3d3XJblc3oTlLTRRP52X7RiXwO4uGtUyisbxFkvHlRAtOm
	h4sR3fhjRylWDIaX0ScssYCQjKJdqbA=
X-MC-Unique: 5yEXaqhRNsqIKNRsVS1Lsw-1
X-Mimecast-MFC-AGG-ID: 5yEXaqhRNsqIKNRsVS1Lsw
From: Valentin Schneider <vschneid@redhat.com>
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	virtualization@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	loongarch@lists.linux.dev,
	linux-riscv@lists.infradead.org,
	linux-perf-users@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	kvm@vger.kernel.org,
	linux-arch@vger.kernel.org,
	rcu@vger.kernel.org,
	linux-hardening@vger.kernel.org,
	linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org,
	bpf@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com
Cc: Josh Poimboeuf <jpoimboe@kernel.org>,
	Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.amakhalov@broadcom.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andy Lutomirski <luto@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Clark Williams <williams@redhat.com>,
	Yair Podemsky <ypodemsk@redhat.com>,
	Tomas Glozar <tglozar@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>,
	Mel Gorman <mgorman@suse.de>,
	Kees Cook <kees@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Shuah Khan <shuah@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Alice Ryhl <aliceryhl@google.com>,
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
	Samuel Holland <samuel.holland@sifive.com>,
	Rong Xu <xur@google.com>,
	Nicolas Saenz Julienne <nsaenzju@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Yosry Ahmed <yosryahmed@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Jinghao Jia <jinghao7@illinois.edu>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: [PATCH v4 02/30] objtool: Flesh out warning related to pv_ops[] calls
Date: Tue, 14 Jan 2025 18:51:15 +0100
Message-ID: <20250114175143.81438-3-vschneid@redhat.com>
In-Reply-To: <20250114175143.81438-1-vschneid@redhat.com>
References: <20250114175143.81438-1-vschneid@redhat.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15

I had to look into objtool itself to understand what this warning was
about; make it more explicit.

Signed-off-by: Valentin Schneider <vschneid@redhat.com>
Acked-by: Josh Poimboeuf <jpoimboe@kernel.org>
---
 tools/objtool/check.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index b35763f05a548..6aa9259fc9940 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -3486,7 +3486,7 @@ static bool pv_call_dest(struct objtool_file *file, struct instruction *insn)
 
 	list_for_each_entry(target, &file->pv_ops[idx].targets, pv_target) {
 		if (!target->sec->noinstr) {
-			WARN("pv_ops[%d]: %s", idx, target->name);
+			WARN("pv_ops[%d]: indirect call to %s() leaves .noinstr.text section", idx, target->name);
 			file->pv_ops[idx].clean = false;
 		}
 	}
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 17:58:54 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 17:58:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871657.1282653 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlBj-0003aw-Oc; Tue, 14 Jan 2025 17:58:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871657.1282653; Tue, 14 Jan 2025 17:58:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlBj-0003Yi-Fb; Tue, 14 Jan 2025 17:58:51 +0000
Received: by outflank-mailman (input) for mailman id 871657;
 Tue, 14 Jan 2025 17:54:46 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=5Qro=UG=redhat.com=vschneid@srs-se1.protection.inumbo.net>)
 id 1tXl7m-00039h-5X
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 17:54:46 +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 a28a3177-d2a0-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 18:54:44 +0100 (CET)
Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-217-NTn38snjMKqDKDXKnJ2usQ-1; Tue,
 14 Jan 2025 12:54:39 -0500
Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id C835019560B8; Tue, 14 Jan 2025 17:54:35 +0000 (UTC)
Received: from vschneid-thinkpadt14sgen2i.remote.csb (unknown [10.39.192.55])
 by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix)
 with ESMTPS id 151C7195608A; Tue, 14 Jan 2025 17:54:09 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a28a3177-d2a0-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1736877283;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=sXsyWlIRHxUaG616jNoO6fTMagUzfNCGxp09271a4iI=;
	b=NcxdypVyNu+XipMn7CzdxJzN56AyGlzt0+tFUPAeXIZ5gdSYyHTTEt+A7euttxd6FeGaLX
	pni1Y3GrCi7XgWChDPuvNtYrACUZt2bTPzmb2DhkVSWY3hc1wYvZNyZ4U0K3RbwbpYtHpE
	9QGoum5kzy/B7PYmktoX/w/yAfuVBCo=
X-MC-Unique: NTn38snjMKqDKDXKnJ2usQ-1
X-Mimecast-MFC-AGG-ID: NTn38snjMKqDKDXKnJ2usQ
From: Valentin Schneider <vschneid@redhat.com>
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	virtualization@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	loongarch@lists.linux.dev,
	linux-riscv@lists.infradead.org,
	linux-perf-users@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	kvm@vger.kernel.org,
	linux-arch@vger.kernel.org,
	rcu@vger.kernel.org,
	linux-hardening@vger.kernel.org,
	linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org,
	bpf@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com
Cc: "Paul E . McKenney" <paulmck@kernel.org>,
	Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.amakhalov@broadcom.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andy Lutomirski <luto@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Clark Williams <williams@redhat.com>,
	Yair Podemsky <ypodemsk@redhat.com>,
	Tomas Glozar <tglozar@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>,
	Mel Gorman <mgorman@suse.de>,
	Kees Cook <kees@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Shuah Khan <shuah@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Alice Ryhl <aliceryhl@google.com>,
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
	Samuel Holland <samuel.holland@sifive.com>,
	Rong Xu <xur@google.com>,
	Nicolas Saenz Julienne <nsaenzju@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Yosry Ahmed <yosryahmed@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Jinghao Jia <jinghao7@illinois.edu>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: [PATCH v4 04/30] rcutorture: Make TREE04 use CONFIG_RCU_DYNTICKS_TORTURE
Date: Tue, 14 Jan 2025 18:51:17 +0100
Message-ID: <20250114175143.81438-5-vschneid@redhat.com>
In-Reply-To: <20250114175143.81438-1-vschneid@redhat.com>
References: <20250114175143.81438-1-vschneid@redhat.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15

We now have an RCU_EXPERT config for testing small-sized RCU dynticks
counter:  CONFIG_RCU_DYNTICKS_TORTURE.

Modify scenario TREE04 to exercise to use this config in order to test a
ridiculously small counter (2 bits).

Link: http://lore.kernel.org/r/4c2cb573-168f-4806-b1d9-164e8276e66a@paulmck-laptop
Suggested-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Valentin Schneider <vschneid@redhat.com>
Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
---
 tools/testing/selftests/rcutorture/configs/rcu/TREE04 | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/testing/selftests/rcutorture/configs/rcu/TREE04 b/tools/testing/selftests/rcutorture/configs/rcu/TREE04
index dc4985064b3ad..67caf4276bb01 100644
--- a/tools/testing/selftests/rcutorture/configs/rcu/TREE04
+++ b/tools/testing/selftests/rcutorture/configs/rcu/TREE04
@@ -16,3 +16,4 @@ CONFIG_DEBUG_OBJECTS_RCU_HEAD=n
 CONFIG_RCU_EXPERT=y
 CONFIG_RCU_EQS_DEBUG=y
 CONFIG_RCU_LAZY=y
+CONFIG_RCU_DYNTICKS_TORTURE=y
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 17:58:53 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 17:58:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871654.1282648 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlBj-0003Uj-Ev; Tue, 14 Jan 2025 17:58:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871654.1282648; Tue, 14 Jan 2025 17:58:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlBj-0003SQ-4e; Tue, 14 Jan 2025 17:58:51 +0000
Received: by outflank-mailman (input) for mailman id 871654;
 Tue, 14 Jan 2025 17:54:20 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=5Qro=UG=redhat.com=vschneid@srs-se1.protection.inumbo.net>)
 id 1tXl7M-000394-5J
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 17:54:20 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 93124b9e-d2a0-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 18:54:19 +0100 (CET)
Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-634-wEhSLQHTPt2u7JUQ3JJxhQ-1; Tue,
 14 Jan 2025 12:54:13 -0500
Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 9298319560A1; Tue, 14 Jan 2025 17:54:09 +0000 (UTC)
Received: from vschneid-thinkpadt14sgen2i.remote.csb (unknown [10.39.192.55])
 by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix)
 with ESMTPS id 10A8519560AB; Tue, 14 Jan 2025 17:53:42 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 93124b9e-d2a0-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1736877257;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=8uAN/SDgGjGVODi/Lh1/HC+8cnSPzXhphDSd8KqRTwQ=;
	b=jVQiNTM1RorR9GkQKxdfDKsqQCCqxBupmO0I+Et8fLTjR9pJk5wARJAOxkBCkz13iZNkrw
	javtQtfpfvOXN+bogkWKmTWWTfYrLgZGFAYjeKyqfkX8S/uQrPqYvhLGK/Vz/v6IVbLO8u
	8+FIbtTDGPE4rFo9wlEj2UhJShODh4E=
X-MC-Unique: wEhSLQHTPt2u7JUQ3JJxhQ-1
X-Mimecast-MFC-AGG-ID: wEhSLQHTPt2u7JUQ3JJxhQ
From: Valentin Schneider <vschneid@redhat.com>
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	virtualization@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	loongarch@lists.linux.dev,
	linux-riscv@lists.infradead.org,
	linux-perf-users@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	kvm@vger.kernel.org,
	linux-arch@vger.kernel.org,
	rcu@vger.kernel.org,
	linux-hardening@vger.kernel.org,
	linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org,
	bpf@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com
Cc: "Paul E . McKenney" <paulmck@kernel.org>,
	Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.amakhalov@broadcom.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andy Lutomirski <luto@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Clark Williams <williams@redhat.com>,
	Yair Podemsky <ypodemsk@redhat.com>,
	Tomas Glozar <tglozar@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>,
	Mel Gorman <mgorman@suse.de>,
	Kees Cook <kees@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Shuah Khan <shuah@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Alice Ryhl <aliceryhl@google.com>,
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
	Samuel Holland <samuel.holland@sifive.com>,
	Rong Xu <xur@google.com>,
	Nicolas Saenz Julienne <nsaenzju@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Yosry Ahmed <yosryahmed@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Jinghao Jia <jinghao7@illinois.edu>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: [PATCH v4 03/30] rcu: Add a small-width RCU watching counter debug option
Date: Tue, 14 Jan 2025 18:51:16 +0100
Message-ID: <20250114175143.81438-4-vschneid@redhat.com>
In-Reply-To: <20250114175143.81438-1-vschneid@redhat.com>
References: <20250114175143.81438-1-vschneid@redhat.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15

A later commit will reduce the size of the RCU watching counter to free up
some bits for another purpose. Paul suggested adding a config option to
test the extreme case where the counter is reduced to its minimum usable
width for rcutorture to poke at, so do that.

Make it only configurable under RCU_EXPERT. While at it, add a comment to
explain the layout of context_tracking->state.

Link: http://lore.kernel.org/r/4c2cb573-168f-4806-b1d9-164e8276e66a@paulmck-laptop
Suggested-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Valentin Schneider <vschneid@redhat.com>
Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
---
 include/linux/context_tracking_state.h | 44 ++++++++++++++++++++++----
 kernel/rcu/Kconfig.debug               | 15 +++++++++
 2 files changed, 52 insertions(+), 7 deletions(-)

diff --git a/include/linux/context_tracking_state.h b/include/linux/context_tracking_state.h
index 7b8433d5a8efe..0b81248aa03e2 100644
--- a/include/linux/context_tracking_state.h
+++ b/include/linux/context_tracking_state.h
@@ -18,12 +18,6 @@ enum ctx_state {
 	CT_STATE_MAX		= 4,
 };
 
-/* Odd value for watching, else even. */
-#define CT_RCU_WATCHING CT_STATE_MAX
-
-#define CT_STATE_MASK (CT_STATE_MAX - 1)
-#define CT_RCU_WATCHING_MASK (~CT_STATE_MASK)
-
 struct context_tracking {
 #ifdef CONFIG_CONTEXT_TRACKING_USER
 	/*
@@ -44,9 +38,45 @@ struct context_tracking {
 #endif
 };
 
+/*
+ * We cram two different things within the same atomic variable:
+ *
+ *                     CT_RCU_WATCHING_START  CT_STATE_START
+ *                                |                |
+ *                                v                v
+ *     MSB [ RCU watching counter ][ context_state ] LSB
+ *         ^                       ^
+ *         |                       |
+ * CT_RCU_WATCHING_END        CT_STATE_END
+ *
+ * Bits are used from the LSB upwards, so unused bits (if any) will always be in
+ * upper bits of the variable.
+ */
 #ifdef CONFIG_CONTEXT_TRACKING
+#define CT_SIZE (sizeof(((struct context_tracking *)0)->state) * BITS_PER_BYTE)
+
+#define CT_STATE_WIDTH bits_per(CT_STATE_MAX - 1)
+#define CT_STATE_START 0
+#define CT_STATE_END   (CT_STATE_START + CT_STATE_WIDTH - 1)
+
+#define CT_RCU_WATCHING_MAX_WIDTH (CT_SIZE - CT_STATE_WIDTH)
+#define CT_RCU_WATCHING_WIDTH     (IS_ENABLED(CONFIG_RCU_DYNTICKS_TORTURE) ? 2 : CT_RCU_WATCHING_MAX_WIDTH)
+#define CT_RCU_WATCHING_START     (CT_STATE_END + 1)
+#define CT_RCU_WATCHING_END       (CT_RCU_WATCHING_START + CT_RCU_WATCHING_WIDTH - 1)
+#define CT_RCU_WATCHING           BIT(CT_RCU_WATCHING_START)
+
+#define CT_STATE_MASK        GENMASK(CT_STATE_END,        CT_STATE_START)
+#define CT_RCU_WATCHING_MASK GENMASK(CT_RCU_WATCHING_END, CT_RCU_WATCHING_START)
+
+#define CT_UNUSED_WIDTH (CT_RCU_WATCHING_MAX_WIDTH - CT_RCU_WATCHING_WIDTH)
+
+static_assert(CT_STATE_WIDTH        +
+	      CT_RCU_WATCHING_WIDTH +
+	      CT_UNUSED_WIDTH       ==
+	      CT_SIZE);
+
 DECLARE_PER_CPU(struct context_tracking, context_tracking);
-#endif
+#endif	/* CONFIG_CONTEXT_TRACKING */
 
 #ifdef CONFIG_CONTEXT_TRACKING_USER
 static __always_inline int __ct_state(void)
diff --git a/kernel/rcu/Kconfig.debug b/kernel/rcu/Kconfig.debug
index 9b0b52e1836fa..ea36953803a1e 100644
--- a/kernel/rcu/Kconfig.debug
+++ b/kernel/rcu/Kconfig.debug
@@ -168,4 +168,19 @@ config RCU_STRICT_GRACE_PERIOD
 	  when looking for certain types of RCU usage bugs, for example,
 	  too-short RCU read-side critical sections.
 
+
+config RCU_DYNTICKS_TORTURE
+	bool "Minimize RCU dynticks counter size"
+	depends on RCU_EXPERT && !COMPILE_TEST
+	default n
+	help
+	  This option sets the width of the dynticks counter to its
+	  minimum usable value.  This minimum width greatly increases
+	  the probability of flushing out bugs involving counter wrap,
+	  but it also increases the probability of extending grace period
+	  durations.  This Kconfig option should therefore be avoided in
+	  production due to the consequent increased probability of OOMs.
+
+	  This has no value for production and is only for testing.
+
 endmenu # "RCU Debugging"
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 17:58:53 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 17:58:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871661.1282669 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlBk-0003ti-Pm; Tue, 14 Jan 2025 17:58:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871661.1282669; Tue, 14 Jan 2025 17:58:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlBk-0003r8-B2; Tue, 14 Jan 2025 17:58:52 +0000
Received: by outflank-mailman (input) for mailman id 871661;
 Tue, 14 Jan 2025 17:55: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
 <SRS0=5Qro=UG=redhat.com=vschneid@srs-se1.protection.inumbo.net>)
 id 1tXl8Y-0003B8-Vo
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 17:55:34 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bfed8535-d2a0-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 18:55:34 +0100 (CET)
Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-346-TCnp728BMva_I5fFAbpK4A-1; Tue,
 14 Jan 2025 12:55:31 -0500
Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id CC0371956053; Tue, 14 Jan 2025 17:55:27 +0000 (UTC)
Received: from vschneid-thinkpadt14sgen2i.remote.csb (unknown [10.39.192.55])
 by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix)
 with ESMTPS id 7D2BD195608A; Tue, 14 Jan 2025 17:55:02 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: bfed8535-d2a0-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1736877332;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=yW4eDMpnPb09nDVWkM9p9gFnBpCcE/XnyyFFoIpXh9k=;
	b=aumpFdCNIUo3PjNZscbIrPbaTkMNK/4rnF5jsuCQYqc3tdpO3Q+KAARz/a5Kc0WR/subUa
	FWKKcTiVvJNJlttB5rUtp+T7ygl9PIn991zURzcb2ywyAeLSJ3VYaow8ecLf8eaobZaW6D
	gRP88zuo6BuAYhD9yweFo36E2Ub5WOU=
X-MC-Unique: TCnp728BMva_I5fFAbpK4A-1
X-Mimecast-MFC-AGG-ID: TCnp728BMva_I5fFAbpK4A
From: Valentin Schneider <vschneid@redhat.com>
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	virtualization@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	loongarch@lists.linux.dev,
	linux-riscv@lists.infradead.org,
	linux-perf-users@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	kvm@vger.kernel.org,
	linux-arch@vger.kernel.org,
	rcu@vger.kernel.org,
	linux-hardening@vger.kernel.org,
	linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org,
	bpf@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com
Cc: Josh Poimboeuf <jpoimboe@kernel.org>,
	Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.amakhalov@broadcom.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andy Lutomirski <luto@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Clark Williams <williams@redhat.com>,
	Yair Podemsky <ypodemsk@redhat.com>,
	Tomas Glozar <tglozar@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>,
	Mel Gorman <mgorman@suse.de>,
	Kees Cook <kees@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Shuah Khan <shuah@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Alice Ryhl <aliceryhl@google.com>,
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
	Samuel Holland <samuel.holland@sifive.com>,
	Rong Xu <xur@google.com>,
	Nicolas Saenz Julienne <nsaenzju@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Yosry Ahmed <yosryahmed@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Jinghao Jia <jinghao7@illinois.edu>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: [PATCH v4 06/30] static_call: Add read-only-after-init static calls
Date: Tue, 14 Jan 2025 18:51:19 +0100
Message-ID: <20250114175143.81438-7-vschneid@redhat.com>
In-Reply-To: <20250114175143.81438-1-vschneid@redhat.com>
References: <20250114175143.81438-1-vschneid@redhat.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15

From: Josh Poimboeuf <jpoimboe@kernel.org>

Deferring a code patching IPI is unsafe if the patched code is in a
noinstr region.  In that case the text poke code must trigger an
immediate IPI to all CPUs, which can rudely interrupt an isolated NO_HZ
CPU running in userspace.

If a noinstr static call only needs to be patched during boot, its key
can be made ro-after-init to ensure it will never be patched at runtime.

Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
---
 include/linux/static_call.h | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/include/linux/static_call.h b/include/linux/static_call.h
index 78a77a4ae0ea8..ea6ca57e2a829 100644
--- a/include/linux/static_call.h
+++ b/include/linux/static_call.h
@@ -192,6 +192,14 @@ extern long __static_call_return0(void);
 	};								\
 	ARCH_DEFINE_STATIC_CALL_TRAMP(name, _func)
 
+#define DEFINE_STATIC_CALL_RO(name, _func)				\
+	DECLARE_STATIC_CALL(name, _func);				\
+	struct static_call_key __ro_after_init STATIC_CALL_KEY(name) = {\
+		.func = _func,						\
+		.type = 1,						\
+	};								\
+	ARCH_DEFINE_STATIC_CALL_TRAMP(name, _func)
+
 #define DEFINE_STATIC_CALL_NULL(name, _func)				\
 	DECLARE_STATIC_CALL(name, _func);				\
 	struct static_call_key STATIC_CALL_KEY(name) = {		\
@@ -200,6 +208,14 @@ extern long __static_call_return0(void);
 	};								\
 	ARCH_DEFINE_STATIC_CALL_NULL_TRAMP(name)
 
+#define DEFINE_STATIC_CALL_NULL_RO(name, _func)				\
+	DECLARE_STATIC_CALL(name, _func);				\
+	struct static_call_key __ro_after_init STATIC_CALL_KEY(name) = {\
+		.func = NULL,						\
+		.type = 1,						\
+	};								\
+	ARCH_DEFINE_STATIC_CALL_NULL_TRAMP(name)
+
 #define DEFINE_STATIC_CALL_RET0(name, _func)				\
 	DECLARE_STATIC_CALL(name, _func);				\
 	struct static_call_key STATIC_CALL_KEY(name) = {		\
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 17:58:54 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 17:58:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871659.1282660 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlBk-0003k6-5H; Tue, 14 Jan 2025 17:58:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871659.1282660; Tue, 14 Jan 2025 17:58:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlBj-0003hI-S6; Tue, 14 Jan 2025 17:58:51 +0000
Received: by outflank-mailman (input) for mailman id 871659;
 Tue, 14 Jan 2025 17:55: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
 <SRS0=5Qro=UG=redhat.com=vschneid@srs-se1.protection.inumbo.net>)
 id 1tXl8D-00039h-0g
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 17:55:13 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b2a2abec-d2a0-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 18:55:11 +0100 (CET)
Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-526-rasDThuXPT-KkBXykuo6Cg-1; Tue,
 14 Jan 2025 12:55:06 -0500
Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id F41581955F67; Tue, 14 Jan 2025 17:55:01 +0000 (UTC)
Received: from vschneid-thinkpadt14sgen2i.remote.csb (unknown [10.39.192.55])
 by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix)
 with ESMTPS id 594CC19560AB; Tue, 14 Jan 2025 17:54:36 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b2a2abec-d2a0-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1736877310;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=tq2pU6+Sz+OC+aH2F2609vpzg9lrw/4sZVW/JKS6LBM=;
	b=jTcnElGVl+HCTOWay4u9OobIOl315VUnU7YWfp2W4fp93e167H/VVl7AiMJFEmF0Wk8YWC
	w8H2nYT9gI+4L1/IH3K2PePx6WxozFP/IsPKhY4RlLqc+l5nojxmRsHU8HCZXF0j/TdL+I
	Vd5Q5wv1RbJXmjNF5hSuFt950CWNll0=
X-MC-Unique: rasDThuXPT-KkBXykuo6Cg-1
X-Mimecast-MFC-AGG-ID: rasDThuXPT-KkBXykuo6Cg
From: Valentin Schneider <vschneid@redhat.com>
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	virtualization@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	loongarch@lists.linux.dev,
	linux-riscv@lists.infradead.org,
	linux-perf-users@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	kvm@vger.kernel.org,
	linux-arch@vger.kernel.org,
	rcu@vger.kernel.org,
	linux-hardening@vger.kernel.org,
	linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org,
	bpf@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com
Cc: Josh Poimboeuf <jpoimboe@kernel.org>,
	Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.amakhalov@broadcom.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andy Lutomirski <luto@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Clark Williams <williams@redhat.com>,
	Yair Podemsky <ypodemsk@redhat.com>,
	Tomas Glozar <tglozar@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>,
	Mel Gorman <mgorman@suse.de>,
	Kees Cook <kees@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Shuah Khan <shuah@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Alice Ryhl <aliceryhl@google.com>,
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
	Samuel Holland <samuel.holland@sifive.com>,
	Rong Xu <xur@google.com>,
	Nicolas Saenz Julienne <nsaenzju@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Yosry Ahmed <yosryahmed@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Jinghao Jia <jinghao7@illinois.edu>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: [PATCH v4 05/30] jump_label: Add annotations for validating noinstr usage
Date: Tue, 14 Jan 2025 18:51:18 +0100
Message-ID: <20250114175143.81438-6-vschneid@redhat.com>
In-Reply-To: <20250114175143.81438-1-vschneid@redhat.com>
References: <20250114175143.81438-1-vschneid@redhat.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15

From: Josh Poimboeuf <jpoimboe@kernel.org>

Deferring a code patching IPI is unsafe if the patched code is in a
noinstr region.  In that case the text poke code must trigger an
immediate IPI to all CPUs, which can rudely interrupt an isolated NO_HZ
CPU running in userspace.

Some noinstr static branches may really need to be patched at runtime,
despite the resulting disruption.  Add DEFINE_STATIC_KEY_*_NOINSTR()
variants for those.  They don't do anything special yet; that will come
later.

Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
---
 include/linux/jump_label.h | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
index f5a2727ca4a9a..88bb6e32fdcbc 100644
--- a/include/linux/jump_label.h
+++ b/include/linux/jump_label.h
@@ -385,6 +385,23 @@ struct static_key_false {
 #define DEFINE_STATIC_KEY_FALSE_RO(name)	\
 	struct static_key_false name __ro_after_init = STATIC_KEY_FALSE_INIT
 
+/*
+ * The _NOINSTR variants are used to tell objtool the static key is allowed to
+ * be used in noinstr code.
+ *
+ * They should almost never be used, as they prevent code patching IPIs from
+ * being deferred, which can be problematic for isolated NOHZ_FULL CPUs running
+ * in pure userspace.
+ *
+ * If using one of these _NOINSTR variants, please add a comment above the
+ * definition with the rationale.
+ */
+#define DEFINE_STATIC_KEY_TRUE_NOINSTR(name)					\
+	DEFINE_STATIC_KEY_TRUE(name)
+
+#define DEFINE_STATIC_KEY_FALSE_NOINSTR(name)					\
+	DEFINE_STATIC_KEY_FALSE(name)
+
 #define DECLARE_STATIC_KEY_FALSE(name)	\
 	extern struct static_key_false name
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 17:58:54 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 17:58:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871665.1282685 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlBl-0004Dn-Jh; Tue, 14 Jan 2025 17:58:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871665.1282685; Tue, 14 Jan 2025 17:58:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlBl-00049t-8Z; Tue, 14 Jan 2025 17:58:53 +0000
Received: by outflank-mailman (input) for mailman id 871665;
 Tue, 14 Jan 2025 17:56:27 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=5Qro=UG=redhat.com=vschneid@srs-se1.protection.inumbo.net>)
 id 1tXl9P-0003Ck-PF
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 17:56:27 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.129.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id dfa863b0-d2a0-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 18:56:26 +0100 (CET)
Received: from mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-663-ULU7yixpNjKqcQQdXKvPwg-1; Tue,
 14 Jan 2025 12:56:22 -0500
Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 83AA919560B4; Tue, 14 Jan 2025 17:56:18 +0000 (UTC)
Received: from vschneid-thinkpadt14sgen2i.remote.csb (unknown [10.39.192.55])
 by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix)
 with ESMTPS id AE8F1195608A; Tue, 14 Jan 2025 17:55:53 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: dfa863b0-d2a0-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1736877385;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=upN6bWUdwddcYtCDglXcedCwjwFydQLGp2NkOO9id+w=;
	b=imD6509S0mofvP0Fye2E1b4akDZ9GKKr/j/BMp2D+xURbibnlr+wzwU9/tv22rtaFOfJiH
	x0pK1Wpoal4UHgJekZl25NFSIbJUJGm4Pf6ZLuuR2st6znbg8kB4FkgRS6c1kIXSqfg+qq
	LMOiT01QRv3VFvKoddzpC4Rf51xDKFc=
X-MC-Unique: ULU7yixpNjKqcQQdXKvPwg-1
X-Mimecast-MFC-AGG-ID: ULU7yixpNjKqcQQdXKvPwg
From: Valentin Schneider <vschneid@redhat.com>
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	virtualization@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	loongarch@lists.linux.dev,
	linux-riscv@lists.infradead.org,
	linux-perf-users@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	kvm@vger.kernel.org,
	linux-arch@vger.kernel.org,
	rcu@vger.kernel.org,
	linux-hardening@vger.kernel.org,
	linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org,
	bpf@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com
Cc: Josh Poimboeuf <jpoimboe@kernel.org>,
	Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.amakhalov@broadcom.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andy Lutomirski <luto@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Clark Williams <williams@redhat.com>,
	Yair Podemsky <ypodemsk@redhat.com>,
	Tomas Glozar <tglozar@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>,
	Mel Gorman <mgorman@suse.de>,
	Kees Cook <kees@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Shuah Khan <shuah@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Alice Ryhl <aliceryhl@google.com>,
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
	Samuel Holland <samuel.holland@sifive.com>,
	Rong Xu <xur@google.com>,
	Nicolas Saenz Julienne <nsaenzju@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Yosry Ahmed <yosryahmed@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Jinghao Jia <jinghao7@illinois.edu>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: [PATCH v4 08/30] x86/idle: Mark x86_idle static call as __ro_after_init
Date: Tue, 14 Jan 2025 18:51:21 +0100
Message-ID: <20250114175143.81438-9-vschneid@redhat.com>
In-Reply-To: <20250114175143.81438-1-vschneid@redhat.com>
References: <20250114175143.81438-1-vschneid@redhat.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15

Later commits will cause objtool to warn about static calls being used in
.noinstr sections in order to safely defer instruction patching IPIs
targeted at NOHZ_FULL CPUs.

x86_idle is updated in:
o xen_set_default_idle() <- __init xen_arch_setup()
o __init select_idle_routine()

IOW purely init context, and can thus be marked as __ro_after_init.

Reported-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Valentin Schneider <vschneid@redhat.com>
---
 arch/x86/kernel/process.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index f63f8fd00a91f..85cd62f61d633 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -746,7 +746,7 @@ void __cpuidle default_idle(void)
 EXPORT_SYMBOL(default_idle);
 #endif
 
-DEFINE_STATIC_CALL_NULL(x86_idle, default_idle);
+DEFINE_STATIC_CALL_NULL_RO(x86_idle, default_idle);
 
 static bool x86_idle_set(void)
 {
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 17:58:55 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 17:58:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871667.1282699 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlBm-0004TW-Nj; Tue, 14 Jan 2025 17:58:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871667.1282699; Tue, 14 Jan 2025 17:58:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlBl-0004QS-Ql; Tue, 14 Jan 2025 17:58:53 +0000
Received: by outflank-mailman (input) for mailman id 871667;
 Tue, 14 Jan 2025 17:56:53 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=5Qro=UG=redhat.com=vschneid@srs-se1.protection.inumbo.net>)
 id 1tXl9p-0003Ck-2G
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 17:56:53 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.129.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id eeeba8ca-d2a0-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 18:56:52 +0100 (CET)
Received: from mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-83-lu3mCN1QPVqlwCLkY5ofog-1; Tue,
 14 Jan 2025 12:56:48 -0500
Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 03C901955DCC; Tue, 14 Jan 2025 17:56:45 +0000 (UTC)
Received: from vschneid-thinkpadt14sgen2i.remote.csb (unknown [10.39.192.55])
 by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix)
 with ESMTPS id 1AEB019560B7; Tue, 14 Jan 2025 17:56:18 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: eeeba8ca-d2a0-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1736877411;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=a7Wvwh2A2o47NLG/+LsYYIZxdlkCdbCUHu9ph/pgaME=;
	b=EIM4yOUweAtkFV8v2bXWr2FCV6bBZ8vtS8NMoVwZ8oMU3xf4rXGqwyGlqdwoqpe4bOT+bx
	rasiQjuy83/3vN0j3gNVp7Tf2BPQkrn2RJ3biOqYNlfgeEY55k+LbFsPf0aF2EBeM5Vohq
	Bjsv7hGOQgZDt32M7GIm4vGpGI3T2x4=
X-MC-Unique: lu3mCN1QPVqlwCLkY5ofog-1
X-Mimecast-MFC-AGG-ID: lu3mCN1QPVqlwCLkY5ofog
From: Valentin Schneider <vschneid@redhat.com>
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	virtualization@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	loongarch@lists.linux.dev,
	linux-riscv@lists.infradead.org,
	linux-perf-users@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	kvm@vger.kernel.org,
	linux-arch@vger.kernel.org,
	rcu@vger.kernel.org,
	linux-hardening@vger.kernel.org,
	linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org,
	bpf@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com
Cc: Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.amakhalov@broadcom.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andy Lutomirski <luto@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Clark Williams <williams@redhat.com>,
	Yair Podemsky <ypodemsk@redhat.com>,
	Tomas Glozar <tglozar@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>,
	Mel Gorman <mgorman@suse.de>,
	Kees Cook <kees@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Shuah Khan <shuah@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Alice Ryhl <aliceryhl@google.com>,
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
	Samuel Holland <samuel.holland@sifive.com>,
	Rong Xu <xur@google.com>,
	Nicolas Saenz Julienne <nsaenzju@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Yosry Ahmed <yosryahmed@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Jinghao Jia <jinghao7@illinois.edu>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: [PATCH v4 09/30] x86/paravirt: Mark pv_steal_clock static call as __ro_after_init
Date: Tue, 14 Jan 2025 18:51:22 +0100
Message-ID: <20250114175143.81438-10-vschneid@redhat.com>
In-Reply-To: <20250114175143.81438-1-vschneid@redhat.com>
References: <20250114175143.81438-1-vschneid@redhat.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15

The static call is only ever updated in

  __init pv_time_init()
  __init xen_init_time_common()
  __init vmware_paravirt_ops_setup()
  __init xen_time_setup_guest(

so mark it appropriately as __ro_after_init.

Signed-off-by: Valentin Schneider <vschneid@redhat.com>
---
 arch/x86/kernel/paravirt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index ae6675167877b..a19b0002b18d8 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -72,7 +72,7 @@ static u64 native_steal_clock(int cpu)
 	return 0;
 }
 
-DEFINE_STATIC_CALL(pv_steal_clock, native_steal_clock);
+DEFINE_STATIC_CALL_RO(pv_steal_clock, native_steal_clock);
 DEFINE_STATIC_CALL_RO(pv_sched_clock, native_sched_clock);
 
 void paravirt_set_sched_clock(u64 (*func)(void))
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 17:58:55 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 17:58:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871669.1282702 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlBm-0004f9-Vt; Tue, 14 Jan 2025 17:58:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871669.1282702; Tue, 14 Jan 2025 17:58:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlBm-0004a7-FS; Tue, 14 Jan 2025 17:58:54 +0000
Received: by outflank-mailman (input) for mailman id 871669;
 Tue, 14 Jan 2025 17:57: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
 <SRS0=5Qro=UG=redhat.com=vschneid@srs-se1.protection.inumbo.net>)
 id 1tXlAI-0003EI-6P
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 17:57:22 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ff732833-d2a0-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 18:57:20 +0100 (CET)
Received: from mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-504-EHMljfk1PzCiodKs1Rlu3g-1; Tue,
 14 Jan 2025 12:57:14 -0500
Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id E80561955DC9; Tue, 14 Jan 2025 17:57:10 +0000 (UTC)
Received: from vschneid-thinkpadt14sgen2i.remote.csb (unknown [10.39.192.55])
 by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix)
 with ESMTPS id 76727195608A; Tue, 14 Jan 2025 17:56:45 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ff732833-d2a0-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1736877439;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=IsiFsDssoC7X6eXx4w8a2ZnGZKlFjYm7iqHh1lVo3b0=;
	b=SadqJetZTBnptK3304daffmRJ/e6rEnGX7aPh98n+bOa2okXXn5W8euhbxS5QddIhOZmDc
	4om1WLwu43sM9qYYd14+85IdmKIzxqxz/yaEb2hBhcWhy35L+3rDJ1ntdkDkMMFutAemNZ
	/NUjDfNvnuuH1Ss7inEh5QiAWHKdUIY=
X-MC-Unique: EHMljfk1PzCiodKs1Rlu3g-1
X-Mimecast-MFC-AGG-ID: EHMljfk1PzCiodKs1Rlu3g
From: Valentin Schneider <vschneid@redhat.com>
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	virtualization@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	loongarch@lists.linux.dev,
	linux-riscv@lists.infradead.org,
	linux-perf-users@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	kvm@vger.kernel.org,
	linux-arch@vger.kernel.org,
	rcu@vger.kernel.org,
	linux-hardening@vger.kernel.org,
	linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org,
	bpf@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com
Cc: Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.amakhalov@broadcom.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andy Lutomirski <luto@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Clark Williams <williams@redhat.com>,
	Yair Podemsky <ypodemsk@redhat.com>,
	Tomas Glozar <tglozar@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>,
	Mel Gorman <mgorman@suse.de>,
	Kees Cook <kees@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Shuah Khan <shuah@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Alice Ryhl <aliceryhl@google.com>,
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
	Samuel Holland <samuel.holland@sifive.com>,
	Rong Xu <xur@google.com>,
	Nicolas Saenz Julienne <nsaenzju@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Yosry Ahmed <yosryahmed@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Jinghao Jia <jinghao7@illinois.edu>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: [PATCH v4 10/30] riscv/paravirt: Mark pv_steal_clock static call as __ro_after_init
Date: Tue, 14 Jan 2025 18:51:23 +0100
Message-ID: <20250114175143.81438-11-vschneid@redhat.com>
In-Reply-To: <20250114175143.81438-1-vschneid@redhat.com>
References: <20250114175143.81438-1-vschneid@redhat.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15

The static call is only ever updated in:

  __init pv_time_init()
  __init xen_time_setup_guest()

so mark it appropriately as __ro_after_init.

Signed-off-by: Valentin Schneider <vschneid@redhat.com>
---
 arch/riscv/kernel/paravirt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/riscv/kernel/paravirt.c b/arch/riscv/kernel/paravirt.c
index fa6b0339a65de..dfe8808016fd8 100644
--- a/arch/riscv/kernel/paravirt.c
+++ b/arch/riscv/kernel/paravirt.c
@@ -30,7 +30,7 @@ static u64 native_steal_clock(int cpu)
 	return 0;
 }
 
-DEFINE_STATIC_CALL(pv_steal_clock, native_steal_clock);
+DEFINE_STATIC_CALL_RO(pv_steal_clock, native_steal_clock);
 
 static bool steal_acc = true;
 static int __init parse_no_stealacc(char *arg)
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 17:58:56 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 17:58:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871671.1282716 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlBo-00050d-Dj; Tue, 14 Jan 2025 17:58:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871671.1282716; Tue, 14 Jan 2025 17:58:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlBn-0004xI-MG; Tue, 14 Jan 2025 17:58:55 +0000
Received: by outflank-mailman (input) for mailman id 871671;
 Tue, 14 Jan 2025 17:57: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
 <SRS0=5Qro=UG=redhat.com=vschneid@srs-se1.protection.inumbo.net>)
 id 1tXlAi-0003Eo-3r
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 17:57:48 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.129.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0f332de7-d2a1-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 18:57:46 +0100 (CET)
Received: from mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-487-MPFxqqEtNGCUUE7KC7NLrg-1; Tue,
 14 Jan 2025 12:57:42 -0500
Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 2C9851955DC6; Tue, 14 Jan 2025 17:57:37 +0000 (UTC)
Received: from vschneid-thinkpadt14sgen2i.remote.csb (unknown [10.39.192.55])
 by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix)
 with ESMTPS id 69120195608A; Tue, 14 Jan 2025 17:57:11 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 0f332de7-d2a1-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1736877465;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=Gy6UStH5/TBRQ5eoVZhQAO0glKmQfzTIxzfOHtHv+oU=;
	b=i9YCqHqHRbaEO7LbKGWwOZF8BeWjzgC/fqJzL8S0kTDO/wGpG2aBtrj/+jmum4McieHDlu
	KX38ONfSxWCh83SMxMXNH9dee1mxzZno5OkkUiiMGI2ywF6/pGRx4HxwS8Q+OYRzMzrTZv
	vZSI99Bing6cp6bHhhqZQyOyc16Cnzk=
X-MC-Unique: MPFxqqEtNGCUUE7KC7NLrg-1
X-Mimecast-MFC-AGG-ID: MPFxqqEtNGCUUE7KC7NLrg
From: Valentin Schneider <vschneid@redhat.com>
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	virtualization@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	loongarch@lists.linux.dev,
	linux-riscv@lists.infradead.org,
	linux-perf-users@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	kvm@vger.kernel.org,
	linux-arch@vger.kernel.org,
	rcu@vger.kernel.org,
	linux-hardening@vger.kernel.org,
	linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org,
	bpf@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com
Cc: Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.amakhalov@broadcom.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andy Lutomirski <luto@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Clark Williams <williams@redhat.com>,
	Yair Podemsky <ypodemsk@redhat.com>,
	Tomas Glozar <tglozar@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>,
	Mel Gorman <mgorman@suse.de>,
	Kees Cook <kees@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Shuah Khan <shuah@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Alice Ryhl <aliceryhl@google.com>,
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
	Samuel Holland <samuel.holland@sifive.com>,
	Rong Xu <xur@google.com>,
	Nicolas Saenz Julienne <nsaenzju@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Yosry Ahmed <yosryahmed@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Jinghao Jia <jinghao7@illinois.edu>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: [PATCH v4 11/30] loongarch/paravirt: Mark pv_steal_clock static call as __ro_after_init
Date: Tue, 14 Jan 2025 18:51:24 +0100
Message-ID: <20250114175143.81438-12-vschneid@redhat.com>
In-Reply-To: <20250114175143.81438-1-vschneid@redhat.com>
References: <20250114175143.81438-1-vschneid@redhat.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15

The static call is only ever updated in

  __init pv_time_init()
  __init xen_time_setup_guest()

so mark it appropriately as __ro_after_init.

Signed-off-by: Valentin Schneider <vschneid@redhat.com>
---
 arch/loongarch/kernel/paravirt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/loongarch/kernel/paravirt.c b/arch/loongarch/kernel/paravirt.c
index e5a39bbad0780..b011578d3e931 100644
--- a/arch/loongarch/kernel/paravirt.c
+++ b/arch/loongarch/kernel/paravirt.c
@@ -20,7 +20,7 @@ static u64 native_steal_clock(int cpu)
 	return 0;
 }
 
-DEFINE_STATIC_CALL(pv_steal_clock, native_steal_clock);
+DEFINE_STATIC_CALL_RO(pv_steal_clock, native_steal_clock);
 
 static bool steal_acc = true;
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 17:58:57 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 17:58:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871673.1282725 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlBp-0005Cm-EZ; Tue, 14 Jan 2025 17:58:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871673.1282725; Tue, 14 Jan 2025 17:58:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlBo-000597-Ia; Tue, 14 Jan 2025 17:58:56 +0000
Received: by outflank-mailman (input) for mailman id 871673;
 Tue, 14 Jan 2025 17:58:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=5Qro=UG=redhat.com=vschneid@srs-se1.protection.inumbo.net>)
 id 1tXlB3-0003Eo-Fl
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 17:58:09 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1c6d49b2-d2a1-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 18:58:08 +0100 (CET)
Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-26-MmrH9LTtO6KBV4tfRF2CNQ-1; Tue,
 14 Jan 2025 12:58:06 -0500
Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id A1F7F195608A; Tue, 14 Jan 2025 17:58:02 +0000 (UTC)
Received: from vschneid-thinkpadt14sgen2i.remote.csb (unknown [10.39.192.55])
 by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix)
 with ESMTPS id 9E84C19560AB; Tue, 14 Jan 2025 17:57:37 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1c6d49b2-d2a1-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1736877487;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=qXsyEmzNJ/sfD0UVcKoaU7D3OtZ64iLWu1bVWX+toF8=;
	b=VTA28UlRthQJZ94mwi9S1nHzW4ylSeT4A+V/LIIv5mY8vAoA8R9QvSuGZOq9GH25Dz/+Bs
	tr3qixeTBpnFNXGDMuAANVKhD/KMxL8ZrWpkSFClHAdRxJO3fepoLWaQEpa6sV2A/wOFYk
	MaDoEEHTs855rVssEbyL3uqn6yQEVYU=
X-MC-Unique: MmrH9LTtO6KBV4tfRF2CNQ-1
X-Mimecast-MFC-AGG-ID: MmrH9LTtO6KBV4tfRF2CNQ
From: Valentin Schneider <vschneid@redhat.com>
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	virtualization@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	loongarch@lists.linux.dev,
	linux-riscv@lists.infradead.org,
	linux-perf-users@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	kvm@vger.kernel.org,
	linux-arch@vger.kernel.org,
	rcu@vger.kernel.org,
	linux-hardening@vger.kernel.org,
	linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org,
	bpf@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com
Cc: Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.amakhalov@broadcom.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andy Lutomirski <luto@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Clark Williams <williams@redhat.com>,
	Yair Podemsky <ypodemsk@redhat.com>,
	Tomas Glozar <tglozar@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>,
	Mel Gorman <mgorman@suse.de>,
	Kees Cook <kees@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Shuah Khan <shuah@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Alice Ryhl <aliceryhl@google.com>,
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
	Samuel Holland <samuel.holland@sifive.com>,
	Rong Xu <xur@google.com>,
	Nicolas Saenz Julienne <nsaenzju@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Yosry Ahmed <yosryahmed@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Jinghao Jia <jinghao7@illinois.edu>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: [PATCH v4 12/30] arm64/paravirt: Mark pv_steal_clock static call as __ro_after_init
Date: Tue, 14 Jan 2025 18:51:25 +0100
Message-ID: <20250114175143.81438-13-vschneid@redhat.com>
In-Reply-To: <20250114175143.81438-1-vschneid@redhat.com>
References: <20250114175143.81438-1-vschneid@redhat.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15

The static call is only ever updated in

  __init pv_time_init()
  __init xen_time_setup_guest()

so mark it appropriately as __ro_after_init.

Signed-off-by: Valentin Schneider <vschneid@redhat.com>
---
 arch/arm64/kernel/paravirt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/paravirt.c b/arch/arm64/kernel/paravirt.c
index aa718d6a9274a..ad28fa23c9228 100644
--- a/arch/arm64/kernel/paravirt.c
+++ b/arch/arm64/kernel/paravirt.c
@@ -32,7 +32,7 @@ static u64 native_steal_clock(int cpu)
 	return 0;
 }
 
-DEFINE_STATIC_CALL(pv_steal_clock, native_steal_clock);
+DEFINE_STATIC_CALL_RO(pv_steal_clock, native_steal_clock);
 
 struct pv_time_stolen_time_region {
 	struct pvclock_vcpu_stolen_time __rcu *kaddr;
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 17:58:59 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 17:58:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871675.1282737 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlBr-0005fq-0E; Tue, 14 Jan 2025 17:58:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871675.1282737; Tue, 14 Jan 2025 17:58:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlBq-0005d1-AU; Tue, 14 Jan 2025 17:58:58 +0000
Received: by outflank-mailman (input) for mailman id 871675;
 Tue, 14 Jan 2025 17:58:38 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=5Qro=UG=redhat.com=vschneid@srs-se1.protection.inumbo.net>)
 id 1tXlBW-0003Eo-HD
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 17:58:38 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.129.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2db33f18-d2a1-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 18:58:38 +0100 (CET)
Received: from mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-297-eJ1DsfOqOJaNqmHoHG6xCQ-1; Tue,
 14 Jan 2025 12:58:32 -0500
Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id F05721955DDE; Tue, 14 Jan 2025 17:58:28 +0000 (UTC)
Received: from vschneid-thinkpadt14sgen2i.remote.csb (unknown [10.39.192.55])
 by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix)
 with ESMTPS id 3D327195608A; Tue, 14 Jan 2025 17:58:02 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2db33f18-d2a1-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1736877516;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=Y5k5J5CPy2ktlmHvQwq2Ty9MVy4yNi4aG70MTyc3QHM=;
	b=bVbp4r9Fr/jUDS3bDqjrPjDJURjE5a1iBF6jEK94uVeeEyk6806FZykl8jIi+Iti3Zj6ol
	DyvBDAVna/Uu8uwk9FUxRSTqmxqAyK//2wWkRzJg2zorVk9xVAnkJC4WhdAfM+RZC3rZAv
	KjcRzW9KPwO7PyFTEfT5+yUCNyaQHag=
X-MC-Unique: eJ1DsfOqOJaNqmHoHG6xCQ-1
X-Mimecast-MFC-AGG-ID: eJ1DsfOqOJaNqmHoHG6xCQ
From: Valentin Schneider <vschneid@redhat.com>
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	virtualization@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	loongarch@lists.linux.dev,
	linux-riscv@lists.infradead.org,
	linux-perf-users@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	kvm@vger.kernel.org,
	linux-arch@vger.kernel.org,
	rcu@vger.kernel.org,
	linux-hardening@vger.kernel.org,
	linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org,
	bpf@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com
Cc: Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.amakhalov@broadcom.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andy Lutomirski <luto@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Clark Williams <williams@redhat.com>,
	Yair Podemsky <ypodemsk@redhat.com>,
	Tomas Glozar <tglozar@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>,
	Mel Gorman <mgorman@suse.de>,
	Kees Cook <kees@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Shuah Khan <shuah@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Alice Ryhl <aliceryhl@google.com>,
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
	Samuel Holland <samuel.holland@sifive.com>,
	Rong Xu <xur@google.com>,
	Nicolas Saenz Julienne <nsaenzju@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Yosry Ahmed <yosryahmed@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Jinghao Jia <jinghao7@illinois.edu>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: [PATCH v4 13/30] arm/paravirt: Mark pv_steal_clock static call as __ro_after_init
Date: Tue, 14 Jan 2025 18:51:26 +0100
Message-ID: <20250114175143.81438-14-vschneid@redhat.com>
In-Reply-To: <20250114175143.81438-1-vschneid@redhat.com>
References: <20250114175143.81438-1-vschneid@redhat.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15

The static call is only ever updated in

  __init xen_time_setup_guest()

so mark it appropriately as __ro_after_init.

Signed-off-by: Valentin Schneider <vschneid@redhat.com>
---
 arch/arm/kernel/paravirt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/kernel/paravirt.c b/arch/arm/kernel/paravirt.c
index 7dd9806369fb0..632d8d5e06db3 100644
--- a/arch/arm/kernel/paravirt.c
+++ b/arch/arm/kernel/paravirt.c
@@ -20,4 +20,4 @@ static u64 native_steal_clock(int cpu)
 	return 0;
 }
 
-DEFINE_STATIC_CALL(pv_steal_clock, native_steal_clock);
+DEFINE_STATIC_CALL_RO(pv_steal_clock, native_steal_clock);
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 17:59:06 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 17:59:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871687.1282769 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlBy-0007Od-96; Tue, 14 Jan 2025 17:59:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871687.1282769; Tue, 14 Jan 2025 17:59:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlBx-0007NU-WA; Tue, 14 Jan 2025 17:59:06 +0000
Received: by outflank-mailman (input) for mailman id 871687;
 Tue, 14 Jan 2025 17:59:04 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=5Qro=UG=redhat.com=vschneid@srs-se1.protection.inumbo.net>)
 id 1tXlBw-0003Eo-DI
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 17:59:04 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3d238942-d2a1-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 18:59:03 +0100 (CET)
Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-682-oI0zUiW-N3iwUtCDbN7ROA-1; Tue,
 14 Jan 2025 12:58:58 -0500
Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id BC5491956059; Tue, 14 Jan 2025 17:58:54 +0000 (UTC)
Received: from vschneid-thinkpadt14sgen2i.remote.csb (unknown [10.39.192.55])
 by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix)
 with ESMTPS id 8B17C195608A; Tue, 14 Jan 2025 17:58:29 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 3d238942-d2a1-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1736877542;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=qMGrs2zO6mJ5O7oOgt8NAfFjs5VkJpcxP/Ef9nOpYpY=;
	b=BFAx/1KpK7OrC3LaEvdXdnfK5gEbla+8nebQxxo/bDk1/b0lOj/k+iBji3oAjYwB5DInKY
	3JWupUjgKM2XvdXC3zzx8Q5y+JZdYgJzh2Fp8DBw2VNzfv0Kv3kn8Hiw4rzMRtA7Mxb9e0
	+PXWqNQuv0GsVOSJcKlp36yqj4Im6xg=
X-MC-Unique: oI0zUiW-N3iwUtCDbN7ROA-1
X-Mimecast-MFC-AGG-ID: oI0zUiW-N3iwUtCDbN7ROA
From: Valentin Schneider <vschneid@redhat.com>
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	virtualization@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	loongarch@lists.linux.dev,
	linux-riscv@lists.infradead.org,
	linux-perf-users@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	kvm@vger.kernel.org,
	linux-arch@vger.kernel.org,
	rcu@vger.kernel.org,
	linux-hardening@vger.kernel.org,
	linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org,
	bpf@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com
Cc: Josh Poimboeuf <jpoimboe@kernel.org>,
	Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.amakhalov@broadcom.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andy Lutomirski <luto@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Clark Williams <williams@redhat.com>,
	Yair Podemsky <ypodemsk@redhat.com>,
	Tomas Glozar <tglozar@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>,
	Mel Gorman <mgorman@suse.de>,
	Kees Cook <kees@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Shuah Khan <shuah@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Alice Ryhl <aliceryhl@google.com>,
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
	Samuel Holland <samuel.holland@sifive.com>,
	Rong Xu <xur@google.com>,
	Nicolas Saenz Julienne <nsaenzju@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Yosry Ahmed <yosryahmed@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Jinghao Jia <jinghao7@illinois.edu>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: [PATCH v4 14/30] perf/x86/amd: Mark perf_lopwr_cb static call as __ro_after_init
Date: Tue, 14 Jan 2025 18:51:27 +0100
Message-ID: <20250114175143.81438-15-vschneid@redhat.com>
In-Reply-To: <20250114175143.81438-1-vschneid@redhat.com>
References: <20250114175143.81438-1-vschneid@redhat.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15

Later commits will cause objtool to warn about static calls being used in
.noinstr sections in order to safely defer instruction patching IPIs
targeted at NOHZ_FULL CPUs.

perf_lopwr_cb is used in .noinstr code, but is only ever updated in __init
amd_brs_lopwr_init(), and can thus be marked as __ro_after_init.

Reported-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Valentin Schneider <vschneid@redhat.com>
---
 arch/x86/events/amd/brs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/events/amd/brs.c b/arch/x86/events/amd/brs.c
index 780acd3dff22a..e2ff03af15d82 100644
--- a/arch/x86/events/amd/brs.c
+++ b/arch/x86/events/amd/brs.c
@@ -422,7 +422,7 @@ void noinstr perf_amd_brs_lopwr_cb(bool lopwr_in)
 	}
 }
 
-DEFINE_STATIC_CALL_NULL(perf_lopwr_cb, perf_amd_brs_lopwr_cb);
+DEFINE_STATIC_CALL_NULL_RO(perf_lopwr_cb, perf_amd_brs_lopwr_cb);
 EXPORT_STATIC_CALL_TRAMP_GPL(perf_lopwr_cb);
 
 void __init amd_brs_lopwr_init(void)
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 18:00:33 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 18:00:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871743.1282780 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlDM-0003pI-F8; Tue, 14 Jan 2025 18:00:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871743.1282780; Tue, 14 Jan 2025 18:00:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlDM-0003pB-CX; Tue, 14 Jan 2025 18:00:32 +0000
Received: by outflank-mailman (input) for mailman id 871743;
 Tue, 14 Jan 2025 18:00:31 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=5Qro=UG=redhat.com=vschneid@srs-se1.protection.inumbo.net>)
 id 1tXlCi-0003Eo-EH
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 17:59:52 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.129.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 59d424af-d2a1-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 18:59:51 +0100 (CET)
Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-83-jmSM7AxOMj2WDdft3VwBHw-1; Tue,
 14 Jan 2025 12:59:49 -0500
Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id D8B751955F79; Tue, 14 Jan 2025 17:59:45 +0000 (UTC)
Received: from vschneid-thinkpadt14sgen2i.remote.csb (unknown [10.39.192.55])
 by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix)
 with ESMTPS id 6685F195608A; Tue, 14 Jan 2025 17:59:20 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 59d424af-d2a1-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1736877590;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=Fzzncw7C2q7Oj32JE4D69orayDnnAM5XMqXCZgIYhoQ=;
	b=Up6ERI1ArX2PRfjDuOyyz0ZkKXWbUHl9DFm+7XpDGtyl5LM4lDnomzjZIjk0eKhBX0dW9w
	vah8CxRgKWW6h1hIoFvUDmwmJOS7VmlmoAPnOF7ACaNDqiw/WSyiFSr//ryLzCWLOxOf1k
	Y7nu7Aq9HScCbOHAU19LkmOj1E3Lt3U=
X-MC-Unique: jmSM7AxOMj2WDdft3VwBHw-1
X-Mimecast-MFC-AGG-ID: jmSM7AxOMj2WDdft3VwBHw
From: Valentin Schneider <vschneid@redhat.com>
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	virtualization@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	loongarch@lists.linux.dev,
	linux-riscv@lists.infradead.org,
	linux-perf-users@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	kvm@vger.kernel.org,
	linux-arch@vger.kernel.org,
	rcu@vger.kernel.org,
	linux-hardening@vger.kernel.org,
	linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org,
	bpf@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com
Cc: Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.amakhalov@broadcom.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andy Lutomirski <luto@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Clark Williams <williams@redhat.com>,
	Yair Podemsky <ypodemsk@redhat.com>,
	Tomas Glozar <tglozar@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>,
	Mel Gorman <mgorman@suse.de>,
	Kees Cook <kees@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Shuah Khan <shuah@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Alice Ryhl <aliceryhl@google.com>,
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
	Samuel Holland <samuel.holland@sifive.com>,
	Rong Xu <xur@google.com>,
	Nicolas Saenz Julienne <nsaenzju@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Yosry Ahmed <yosryahmed@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Jinghao Jia <jinghao7@illinois.edu>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: [PATCH v4 16/30] x86/speculation/mds: Mark mds_idle_clear key as allowed in .noinstr
Date: Tue, 14 Jan 2025 18:51:29 +0100
Message-ID: <20250114175143.81438-17-vschneid@redhat.com>
In-Reply-To: <20250114175143.81438-1-vschneid@redhat.com>
References: <20250114175143.81438-1-vschneid@redhat.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15

Later commits will cause objtool to warn about static keys being used in
.noinstr sections in order to safely defer instruction patching IPIs
targeted at NOHZ_FULL CPUs.

mds_idle_clear is used in .noinstr code, and can be modified at
runtime (SMT hotplug). Suppressing the text_poke_sync() IPI has little
benefits for this key, as hotplug implies eventually going through
takedown_cpu() -> stop_machine_cpuslocked() which is going to cause
interference on all online CPUs anyway.

Mark it to let objtool know not to warn about it.

Signed-off-by: Valentin Schneider <vschneid@redhat.com>
---
 arch/x86/kernel/cpu/bugs.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 47a01d4028f60..acad84dcfc3cd 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -113,8 +113,13 @@ DEFINE_STATIC_KEY_FALSE(switch_mm_cond_ibpb);
 /* Control unconditional IBPB in switch_mm() */
 DEFINE_STATIC_KEY_FALSE(switch_mm_always_ibpb);
 
-/* Control MDS CPU buffer clear before idling (halt, mwait) */
-DEFINE_STATIC_KEY_FALSE(mds_idle_clear);
+/*
+ * Control MDS CPU buffer clear before idling (halt, mwait)
+ *
+ * Allowed in .noinstr as this key is updated during hotplug which comes with
+ * more interference than just the text patching IPI.
+ */
+DEFINE_STATIC_KEY_FALSE_NOINSTR(mds_idle_clear);
 EXPORT_SYMBOL_GPL(mds_idle_clear);
 
 /*
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 18:00:45 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 18:00:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871748.1282790 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlDZ-0004JG-Nx; Tue, 14 Jan 2025 18:00:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871748.1282790; Tue, 14 Jan 2025 18:00:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlDZ-0004J4-K0; Tue, 14 Jan 2025 18:00:45 +0000
Received: by outflank-mailman (input) for mailman id 871748;
 Tue, 14 Jan 2025 18:00: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
 <SRS0=5Qro=UG=redhat.com=vschneid@srs-se1.protection.inumbo.net>)
 id 1tXlDZ-0003bz-4P
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 18:00:45 +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 789de557-d2a1-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 19:00:43 +0100 (CET)
Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-617-15QLd5xpPJuBfkaI0jxIcg-1; Tue,
 14 Jan 2025 13:00:36 -0500
Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 7DD041954195; Tue, 14 Jan 2025 18:00:33 +0000 (UTC)
Received: from vschneid-thinkpadt14sgen2i.remote.csb (unknown [10.39.192.55])
 by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix)
 with ESMTPS id 3F89B195608A; Tue, 14 Jan 2025 18:00:11 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 789de557-d2a1-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1736877642;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=1xC4OsvuHAy+Ds3sLAPsZ084bYad84WLBsAT/g0G1RM=;
	b=EfU1XYMdtIwBz1aphjtPxE+cwGPgr0zNTdzY5WWzTtShVLJTZVWHb13KwSg/Ri5bPvKqa1
	B/klpiQqMk4eQaSvKx9WihjD6ZjuduXdLr5JRBCeOMdmh6onLz6f7kRBZjCow19S1x61Qe
	ycLMeJkZWKw6jDjMfUvTPmIj+ghEXqE=
X-MC-Unique: 15QLd5xpPJuBfkaI0jxIcg-1
X-Mimecast-MFC-AGG-ID: 15QLd5xpPJuBfkaI0jxIcg
From: Valentin Schneider <vschneid@redhat.com>
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	virtualization@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	loongarch@lists.linux.dev,
	linux-riscv@lists.infradead.org,
	linux-perf-users@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	kvm@vger.kernel.org,
	linux-arch@vger.kernel.org,
	rcu@vger.kernel.org,
	linux-hardening@vger.kernel.org,
	linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org,
	bpf@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com
Cc: Josh Poimboeuf <jpoimboe@kernel.org>,
	Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.amakhalov@broadcom.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andy Lutomirski <luto@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Clark Williams <williams@redhat.com>,
	Yair Podemsky <ypodemsk@redhat.com>,
	Tomas Glozar <tglozar@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>,
	Mel Gorman <mgorman@suse.de>,
	Kees Cook <kees@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Shuah Khan <shuah@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Alice Ryhl <aliceryhl@google.com>,
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
	Samuel Holland <samuel.holland@sifive.com>,
	Rong Xu <xur@google.com>,
	Nicolas Saenz Julienne <nsaenzju@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Yosry Ahmed <yosryahmed@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Jinghao Jia <jinghao7@illinois.edu>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: [PATCH v4 18/30] x86/kvm/vmx: Mark vmx_l1d_should flush and vmx_l1d_flush_cond keys as allowed in .noinstr
Date: Tue, 14 Jan 2025 18:51:31 +0100
Message-ID: <20250114175143.81438-19-vschneid@redhat.com>
In-Reply-To: <20250114175143.81438-1-vschneid@redhat.com>
References: <20250114175143.81438-1-vschneid@redhat.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15

Later commits will cause objtool to warn about static keys being used in
.noinstr sections in order to safely defer instruction patching IPIs
targeted at NOHZ_FULL CPUs.

These keys are used in .noinstr code, and can be modified at runtime
(/proc/kernel/vmx* write). However it is not expected that they will be
flipped during latency-sensitive operations, and thus shouldn't be a source
of interference wrt the text patching IPI.

Mark it to let objtool know not to warn about it.

Reported-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Valentin Schneider <vschneid@redhat.com>
---
 arch/x86/kvm/vmx/vmx.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 893366e537322..a028c38f44e02 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -225,8 +225,15 @@ module_param(pt_mode, int, S_IRUGO);
 
 struct x86_pmu_lbr __ro_after_init vmx_lbr_caps;
 
-static DEFINE_STATIC_KEY_FALSE(vmx_l1d_should_flush);
-static DEFINE_STATIC_KEY_FALSE(vmx_l1d_flush_cond);
+/*
+ * Both of these static keys end up being used in .noinstr sections, however
+ * they are only modified:
+ * - at init
+ * - from a /proc/kernel/vmx* write
+ * thus during latency-sensitive operations they should remain stable.
+ */
+static DEFINE_STATIC_KEY_FALSE_NOINSTR(vmx_l1d_should_flush);
+static DEFINE_STATIC_KEY_FALSE_NOINSTR(vmx_l1d_flush_cond);
 static DEFINE_MUTEX(vmx_l1d_flush_mutex);
 
 /* Storage for pre module init parameter parsing */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 18:01:08 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 18:01:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871759.1282801 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlDw-00054A-1f; Tue, 14 Jan 2025 18:01:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871759.1282801; Tue, 14 Jan 2025 18:01:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlDv-000543-Sf; Tue, 14 Jan 2025 18:01:07 +0000
Received: by outflank-mailman (input) for mailman id 871759;
 Tue, 14 Jan 2025 18:01: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
 <SRS0=5Qro=UG=redhat.com=vschneid@srs-se1.protection.inumbo.net>)
 id 1tXlDu-0004pK-Kd
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 18:01:06 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 85fbee9b-d2a1-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 19:01:06 +0100 (CET)
Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-180-l9crDhjEN0CU5mOOpfPM-A-1; Tue,
 14 Jan 2025 13:01:02 -0500
Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 734481954190; Tue, 14 Jan 2025 18:00:56 +0000 (UTC)
Received: from vschneid-thinkpadt14sgen2i.remote.csb (unknown [10.39.192.55])
 by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix)
 with ESMTPS id F38CE195608A; Tue, 14 Jan 2025 18:00:33 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 85fbee9b-d2a1-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1736877664;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=GQSPZLQ3FmvxIu57q6qI2psmX9IZ2horrf+PeQlNWuI=;
	b=e4NdWv9XiX5E0gif/3A0cDammbayQb384yeK+jDqJX7Fm+iR5mIfU4oNXGh751kYrGN/6G
	+RlFzgLqLw+7sA8EHiFYoZI6cGtBbtB4SZxLfdacgEmt8o2lFKeZ2J48Ik7k9X22YdZ5H5
	SZgeUlKHzROY7cppUQUC0vkfTuXZOKU=
X-MC-Unique: l9crDhjEN0CU5mOOpfPM-A-1
X-Mimecast-MFC-AGG-ID: l9crDhjEN0CU5mOOpfPM-A
From: Valentin Schneider <vschneid@redhat.com>
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	virtualization@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	loongarch@lists.linux.dev,
	linux-riscv@lists.infradead.org,
	linux-perf-users@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	kvm@vger.kernel.org,
	linux-arch@vger.kernel.org,
	rcu@vger.kernel.org,
	linux-hardening@vger.kernel.org,
	linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org,
	bpf@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com
Cc: Josh Poimboeuf <jpoimboe@kernel.org>,
	Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.amakhalov@broadcom.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andy Lutomirski <luto@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Clark Williams <williams@redhat.com>,
	Yair Podemsky <ypodemsk@redhat.com>,
	Tomas Glozar <tglozar@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>,
	Mel Gorman <mgorman@suse.de>,
	Kees Cook <kees@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Shuah Khan <shuah@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Alice Ryhl <aliceryhl@google.com>,
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
	Samuel Holland <samuel.holland@sifive.com>,
	Rong Xu <xur@google.com>,
	Nicolas Saenz Julienne <nsaenzju@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Yosry Ahmed <yosryahmed@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Jinghao Jia <jinghao7@illinois.edu>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: [PATCH v4 19/30] stackleack: Mark stack_erasing_bypass key as allowed in .noinstr
Date: Tue, 14 Jan 2025 18:51:32 +0100
Message-ID: <20250114175143.81438-20-vschneid@redhat.com>
In-Reply-To: <20250114175143.81438-1-vschneid@redhat.com>
References: <20250114175143.81438-1-vschneid@redhat.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15

Later commits will cause objtool to warn about static keys being used in
.noinstr sections in order to safely defer instruction patching IPIs
targeted at NOHZ_FULL CPUs.

stack_erasing_bypass is used in .noinstr code, and can be modified at runtime
(proc/sys/kernel/stack_erasing write). However it is not expected that it
will be  flipped during latency-sensitive operations, and thus shouldn't be
a source of interference wrt the text patching IPI.

Mark it to let objtool know not to warn about it.

Reported-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Valentin Schneider <vschneid@redhat.com>
---
 kernel/stackleak.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/kernel/stackleak.c b/kernel/stackleak.c
index 39fd620a7db6f..a4f07fbc13f61 100644
--- a/kernel/stackleak.c
+++ b/kernel/stackleak.c
@@ -18,7 +18,11 @@
 #include <linux/sysctl.h>
 #include <linux/init.h>
 
-static DEFINE_STATIC_KEY_FALSE(stack_erasing_bypass);
+/*
+ * This static key can only be modified via its sysctl interface. It is
+ * expected it will remain stable during latency-senstive operations.
+ */
+static DEFINE_STATIC_KEY_FALSE_NOINSTR(stack_erasing_bypass);
 
 #ifdef CONFIG_SYSCTL
 static int stack_erasing_sysctl(const struct ctl_table *table, int write,
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 18:01:54 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 18:01:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871819.1282810 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlEf-0006lE-DD; Tue, 14 Jan 2025 18:01:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871819.1282810; Tue, 14 Jan 2025 18:01:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlEf-0006l7-8x; Tue, 14 Jan 2025 18:01:53 +0000
Received: by outflank-mailman (input) for mailman id 871819;
 Tue, 14 Jan 2025 18:01: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
 <SRS0=5Qro=UG=redhat.com=vschneid@srs-se1.protection.inumbo.net>)
 id 1tXlEe-0004pK-7i
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 18:01:52 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a0e55e0d-d2a1-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 19:01:51 +0100 (CET)
Received: from mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-418-yr-DHzXkMTap-bgFsYDaSw-1; Tue,
 14 Jan 2025 13:01:44 -0500
Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 2A8ED1A445CE; Tue, 14 Jan 2025 18:01:23 +0000 (UTC)
Received: from vschneid-thinkpadt14sgen2i.remote.csb (unknown [10.39.192.55])
 by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix)
 with ESMTPS id E8F64195608A; Tue, 14 Jan 2025 18:00:56 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a0e55e0d-d2a1-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1736877710;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=e8MD/yxknvCsMYBCjJmdeKziBGiIOE307eysnVgCl2M=;
	b=FsV4OvuOID+gy5MmC8vT4fGL4OMZlx0Xx2NpxbTKzpgHvOl2FBRmhe0ad+fGkKLpT4fR5Y
	gETBiQxpGBrOjIk9E1ozu3kQwCZCv6vwSVPSlzKQ3lhe3gx9mgA7KADLQeTielTVL4w2tn
	lnTZFLvv9AefxETnwjDxmHmxdQ5PkjU=
X-MC-Unique: yr-DHzXkMTap-bgFsYDaSw-1
X-Mimecast-MFC-AGG-ID: yr-DHzXkMTap-bgFsYDaSw
From: Valentin Schneider <vschneid@redhat.com>
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	virtualization@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	loongarch@lists.linux.dev,
	linux-riscv@lists.infradead.org,
	linux-perf-users@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	kvm@vger.kernel.org,
	linux-arch@vger.kernel.org,
	rcu@vger.kernel.org,
	linux-hardening@vger.kernel.org,
	linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org,
	bpf@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com
Cc: Josh Poimboeuf <jpoimboe@kernel.org>,
	Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.amakhalov@broadcom.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andy Lutomirski <luto@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Clark Williams <williams@redhat.com>,
	Yair Podemsky <ypodemsk@redhat.com>,
	Tomas Glozar <tglozar@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>,
	Mel Gorman <mgorman@suse.de>,
	Kees Cook <kees@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Shuah Khan <shuah@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Alice Ryhl <aliceryhl@google.com>,
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
	Samuel Holland <samuel.holland@sifive.com>,
	Rong Xu <xur@google.com>,
	Nicolas Saenz Julienne <nsaenzju@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Yosry Ahmed <yosryahmed@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Jinghao Jia <jinghao7@illinois.edu>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: [PATCH v4 20/30] objtool: Add noinstr validation for static branches/calls
Date: Tue, 14 Jan 2025 18:51:33 +0100
Message-ID: <20250114175143.81438-21-vschneid@redhat.com>
In-Reply-To: <20250114175143.81438-1-vschneid@redhat.com>
References: <20250114175143.81438-1-vschneid@redhat.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15

From: Josh Poimboeuf <jpoimboe@kernel.org>

Warn about static branches/calls in noinstr regions, unless the
corresponding key is RO-after-init or has been manually whitelisted with
DEFINE_STATIC_KEY_*_NOINSTR(().

Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
[Added NULL check for insn_call_dest() return value]
Signed-off-by: Valentin Schneider <vschneid@redhat.com>
---
 include/linux/jump_label.h              | 17 +++--
 include/linux/objtool.h                 |  7 ++
 include/linux/static_call.h             |  3 +
 tools/objtool/Documentation/objtool.txt | 34 +++++++++
 tools/objtool/check.c                   | 92 ++++++++++++++++++++++---
 tools/objtool/include/objtool/check.h   |  1 +
 tools/objtool/include/objtool/elf.h     |  1 +
 tools/objtool/include/objtool/special.h |  1 +
 tools/objtool/special.c                 | 18 ++++-
 9 files changed, 156 insertions(+), 18 deletions(-)

diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
index 88bb6e32fdcbc..dc8a82a62c109 100644
--- a/include/linux/jump_label.h
+++ b/include/linux/jump_label.h
@@ -75,6 +75,7 @@
 
 #include <linux/types.h>
 #include <linux/compiler.h>
+#include <linux/objtool.h>
 
 extern bool static_key_initialized;
 
@@ -373,8 +374,9 @@ struct static_key_false {
 #define DEFINE_STATIC_KEY_TRUE(name)	\
 	struct static_key_true name = STATIC_KEY_TRUE_INIT
 
-#define DEFINE_STATIC_KEY_TRUE_RO(name)	\
-	struct static_key_true name __ro_after_init = STATIC_KEY_TRUE_INIT
+#define DEFINE_STATIC_KEY_TRUE_RO(name)						\
+	struct static_key_true name __ro_after_init = STATIC_KEY_TRUE_INIT;	\
+	ANNOTATE_NOINSTR_ALLOWED(name)
 
 #define DECLARE_STATIC_KEY_TRUE(name)	\
 	extern struct static_key_true name
@@ -382,8 +384,9 @@ struct static_key_false {
 #define DEFINE_STATIC_KEY_FALSE(name)	\
 	struct static_key_false name = STATIC_KEY_FALSE_INIT
 
-#define DEFINE_STATIC_KEY_FALSE_RO(name)	\
-	struct static_key_false name __ro_after_init = STATIC_KEY_FALSE_INIT
+#define DEFINE_STATIC_KEY_FALSE_RO(name)					\
+	struct static_key_false name __ro_after_init = STATIC_KEY_FALSE_INIT;	\
+	ANNOTATE_NOINSTR_ALLOWED(name)
 
 /*
  * The _NOINSTR variants are used to tell objtool the static key is allowed to
@@ -397,10 +400,12 @@ struct static_key_false {
  * definition with the rationale.
  */
 #define DEFINE_STATIC_KEY_TRUE_NOINSTR(name)					\
-	DEFINE_STATIC_KEY_TRUE(name)
+	DEFINE_STATIC_KEY_TRUE(name);						\
+	ANNOTATE_NOINSTR_ALLOWED(name)
 
 #define DEFINE_STATIC_KEY_FALSE_NOINSTR(name)					\
-	DEFINE_STATIC_KEY_FALSE(name)
+	DEFINE_STATIC_KEY_FALSE(name);						\
+	ANNOTATE_NOINSTR_ALLOWED(name)
 
 #define DECLARE_STATIC_KEY_FALSE(name)	\
 	extern struct static_key_false name
diff --git a/include/linux/objtool.h b/include/linux/objtool.h
index b3b8d3dab52d5..1a7389f273063 100644
--- a/include/linux/objtool.h
+++ b/include/linux/objtool.h
@@ -34,6 +34,12 @@
 	static void __used __section(".discard.func_stack_frame_non_standard") \
 		*__func_stack_frame_non_standard_##func = func
 
+#define __ANNOTATE_NOINSTR_ALLOWED(key) \
+	static void __used __section(".discard.noinstr_allowed") \
+		*__annotate_noinstr_allowed_##key = &key
+
+#define ANNOTATE_NOINSTR_ALLOWED(key) __ANNOTATE_NOINSTR_ALLOWED(key)
+
 /*
  * STACK_FRAME_NON_STANDARD_FP() is a frame-pointer-specific function ignore
  * for the case where a function is intentionally missing frame pointer setup,
@@ -157,6 +163,7 @@
 #define STACK_FRAME_NON_STANDARD_FP(func)
 #define ANNOTATE_NOENDBR
 #define ASM_REACHABLE
+#define ANNOTATE_NOINSTR_ALLOWED(key)
 #else
 #define ANNOTATE_INTRA_FUNCTION_CALL
 .macro UNWIND_HINT type:req sp_reg=0 sp_offset=0 signal=0
diff --git a/include/linux/static_call.h b/include/linux/static_call.h
index ea6ca57e2a829..0d4b16d348501 100644
--- a/include/linux/static_call.h
+++ b/include/linux/static_call.h
@@ -133,6 +133,7 @@
 
 #include <linux/types.h>
 #include <linux/cpu.h>
+#include <linux/objtool.h>
 #include <linux/static_call_types.h>
 
 #ifdef CONFIG_HAVE_STATIC_CALL
@@ -198,6 +199,7 @@ extern long __static_call_return0(void);
 		.func = _func,						\
 		.type = 1,						\
 	};								\
+	ANNOTATE_NOINSTR_ALLOWED(STATIC_CALL_TRAMP(name));		\
 	ARCH_DEFINE_STATIC_CALL_TRAMP(name, _func)
 
 #define DEFINE_STATIC_CALL_NULL(name, _func)				\
@@ -214,6 +216,7 @@ extern long __static_call_return0(void);
 		.func = NULL,						\
 		.type = 1,						\
 	};								\
+	ANNOTATE_NOINSTR_ALLOWED(STATIC_CALL_TRAMP(name));		\
 	ARCH_DEFINE_STATIC_CALL_NULL_TRAMP(name)
 
 #define DEFINE_STATIC_CALL_RET0(name, _func)				\
diff --git a/tools/objtool/Documentation/objtool.txt b/tools/objtool/Documentation/objtool.txt
index 7c3ee959b63c7..922d3b41541d0 100644
--- a/tools/objtool/Documentation/objtool.txt
+++ b/tools/objtool/Documentation/objtool.txt
@@ -447,6 +447,40 @@ the objtool maintainers.
    names and does not use module_init() / module_exit() macros to create
    them.
 
+13. file.o: warning: func()+0x2a: key: non-RO static key usage in noinstr code
+    file.o: warning: func()+0x2a: key: non-RO static call usage in noinstr code
+
+  This means that noinstr function func() uses a static key or
+  static call named 'key' which can be modified at runtime.  This is
+  discouraged because it prevents code patching IPIs from being
+  deferred.
+
+  You have the following options:
+
+  1) Check whether the static key/call in question is only modified
+     during init.  If so, define it as read-only-after-init with
+     DEFINE_STATIC_KEY_*_RO() or DEFINE_STATIC_CALL_RO().
+
+  2) Avoid the runtime patching.  For static keys this can be done by
+     using static_key_enabled() or by getting rid of the static key
+     altogether if performance is not a concern.
+
+     For static calls, something like the following could be done:
+
+       target = static_call_query(foo);
+       if (target == func1)
+	       func1();
+	else if (target == func2)
+		func2();
+	...
+
+  3) Silence the warning by defining the static key/call with
+     DEFINE_STATIC_*_NOINSTR().  This decision should not
+     be taken lightly as it may result in code patching IPIs getting
+     sent to isolated NOHZ_FULL CPUs running in pure userspace.  A
+     comment should be added above the definition explaining the
+     rationale for the decision.
+
 
 If the error doesn't seem to make sense, it could be a bug in objtool.
 Feel free to ask the objtool maintainer for help.
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 6aa9259fc9940..24219538c1587 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -1068,6 +1068,45 @@ static int create_direct_call_sections(struct objtool_file *file)
 	return 0;
 }
 
+static int read_noinstr_allowed(struct objtool_file *file)
+{
+	struct section *rsec;
+	struct symbol *sym;
+	struct reloc *reloc;
+
+	rsec = find_section_by_name(file->elf, ".rela.discard.noinstr_allowed");
+	if (!rsec)
+		return 0;
+
+	for_each_reloc(rsec, reloc) {
+		switch (reloc->sym->type) {
+		case STT_OBJECT:
+		case STT_FUNC:
+			sym = reloc->sym;
+			break;
+
+		case STT_SECTION:
+			sym = find_symbol_by_offset(reloc->sym->sec,
+						    reloc_addend(reloc));
+			if (!sym) {
+				WARN_FUNC("can't find static key/call symbol",
+					  reloc->sym->sec, reloc_addend(reloc));
+				return -1;
+			}
+			break;
+
+		default:
+			WARN("unexpected relocation symbol type in %s: %d",
+			     rsec->name, reloc->sym->type);
+			return -1;
+		}
+
+		sym->noinstr_allowed = 1;
+	}
+
+	return 0;
+}
+
 /*
  * Warnings shouldn't be reported for ignored functions.
  */
@@ -1955,6 +1994,8 @@ static int handle_jump_alt(struct objtool_file *file,
 		return -1;
 	}
 
+	orig_insn->key = special_alt->key;
+
 	if (opts.hack_jump_label && special_alt->key_addend & 2) {
 		struct reloc *reloc = insn_reloc(file, orig_insn);
 
@@ -2731,6 +2772,10 @@ static int decode_sections(struct objtool_file *file)
 	if (ret)
 		return ret;
 
+	ret = read_noinstr_allowed(file);
+	if (ret)
+		return ret;
+
 	return 0;
 }
 
@@ -3494,9 +3539,9 @@ static bool pv_call_dest(struct objtool_file *file, struct instruction *insn)
 	return file->pv_ops[idx].clean;
 }
 
-static inline bool noinstr_call_dest(struct objtool_file *file,
-				     struct instruction *insn,
-				     struct symbol *func)
+static inline bool noinstr_call_allowed(struct objtool_file *file,
+					struct instruction *insn,
+					struct symbol *func)
 {
 	/*
 	 * We can't deal with indirect function calls at present;
@@ -3516,10 +3561,10 @@ static inline bool noinstr_call_dest(struct objtool_file *file,
 		return true;
 
 	/*
-	 * If the symbol is a static_call trampoline, we can't tell.
+	 * Only DEFINE_STATIC_CALL_*_RO allowed.
 	 */
 	if (func->static_call_tramp)
-		return true;
+		return func->noinstr_allowed;
 
 	/*
 	 * The __ubsan_handle_*() calls are like WARN(), they only happen when
@@ -3532,14 +3577,29 @@ static inline bool noinstr_call_dest(struct objtool_file *file,
 	return false;
 }
 
+static char *static_call_name(struct symbol *func)
+{
+	return func->name + strlen("__SCT__");
+}
+
 static int validate_call(struct objtool_file *file,
 			 struct instruction *insn,
 			 struct insn_state *state)
 {
-	if (state->noinstr && state->instr <= 0 &&
-	    !noinstr_call_dest(file, insn, insn_call_dest(insn))) {
-		WARN_INSN(insn, "call to %s() leaves .noinstr.text section", call_dest_name(file, insn));
-		return 1;
+	if (state->noinstr && state->instr <= 0) {
+		struct symbol *dest = insn_call_dest(insn);
+
+		if (dest && dest->static_call_tramp) {
+			if (!dest->noinstr_allowed) {
+				WARN_INSN(insn, "%s: non-RO static call usage in noinstr",
+					  static_call_name(dest));
+			}
+
+		} else if (dest && !noinstr_call_allowed(file, insn, dest)) {
+			WARN_INSN(insn, "call to %s() leaves .noinstr.text section",
+				  call_dest_name(file, insn));
+			return 1;
+		}
 	}
 
 	if (state->uaccess && !func_uaccess_safe(insn_call_dest(insn))) {
@@ -3604,6 +3664,17 @@ static int validate_return(struct symbol *func, struct instruction *insn, struct
 	return 0;
 }
 
+static int validate_static_key(struct instruction *insn, struct insn_state *state)
+{
+	if (state->noinstr && state->instr <= 0 && !insn->key->noinstr_allowed) {
+		WARN_INSN(insn, "%s: non-RO static key usage in noinstr",
+			  insn->key->name);
+		return 1;
+	}
+
+	return 0;
+}
+
 static struct instruction *next_insn_to_validate(struct objtool_file *file,
 						 struct instruction *insn)
 {
@@ -3765,6 +3836,9 @@ static int validate_branch(struct objtool_file *file, struct symbol *func,
 		if (handle_insn_ops(insn, next_insn, &state))
 			return 1;
 
+		if (insn->key)
+			validate_static_key(insn, &state);
+
 		switch (insn->type) {
 
 		case INSN_RETURN:
diff --git a/tools/objtool/include/objtool/check.h b/tools/objtool/include/objtool/check.h
index daa46f1f0965a..c0da7246eac7b 100644
--- a/tools/objtool/include/objtool/check.h
+++ b/tools/objtool/include/objtool/check.h
@@ -77,6 +77,7 @@ struct instruction {
 	struct symbol *sym;
 	struct stack_op *stack_ops;
 	struct cfi_state *cfi;
+	struct symbol *key;
 };
 
 static inline struct symbol *insn_func(struct instruction *insn)
diff --git a/tools/objtool/include/objtool/elf.h b/tools/objtool/include/objtool/elf.h
index d7e815c2fd156..0cb79931262bb 100644
--- a/tools/objtool/include/objtool/elf.h
+++ b/tools/objtool/include/objtool/elf.h
@@ -69,6 +69,7 @@ struct symbol {
 	u8 embedded_insn     : 1;
 	u8 local_label       : 1;
 	u8 frame_pointer     : 1;
+	u8 noinstr_allowed   : 1;
 	struct list_head pv_target;
 	struct reloc *relocs;
 };
diff --git a/tools/objtool/include/objtool/special.h b/tools/objtool/include/objtool/special.h
index 86d4af9c5aa9d..ce4759358ec48 100644
--- a/tools/objtool/include/objtool/special.h
+++ b/tools/objtool/include/objtool/special.h
@@ -20,6 +20,7 @@ struct special_alt {
 	bool skip_alt;
 	bool jump_or_nop;
 	u8 key_addend;
+	struct symbol *key;
 
 	struct section *orig_sec;
 	unsigned long orig_off;
diff --git a/tools/objtool/special.c b/tools/objtool/special.c
index 097a69db82a0e..982d5cb55e1bb 100644
--- a/tools/objtool/special.c
+++ b/tools/objtool/special.c
@@ -119,14 +119,26 @@ static int get_alt_entry(struct elf *elf, const struct special_entry *entry,
 
 	if (entry->key) {
 		struct reloc *key_reloc;
+		struct symbol *key;
+		s64 key_addend;
 
 		key_reloc = find_reloc_by_dest(elf, sec, offset + entry->key);
 		if (!key_reloc) {
-			WARN_FUNC("can't find key reloc",
-				  sec, offset + entry->key);
+			WARN_FUNC("can't find key reloc", sec, offset + entry->key);
 			return -1;
 		}
-		alt->key_addend = reloc_addend(key_reloc);
+
+		key = key_reloc->sym;
+		key_addend = reloc_addend(key_reloc);
+
+		if (key->type == STT_SECTION)
+			key = find_symbol_by_offset(key->sec, key_addend & ~3);
+
+		/* embedded keys not supported */
+		if (key) {
+			alt->key = key;
+			alt->key_addend = key_addend;
+		}
 	}
 
 	return 0;
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 18:02:14 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 18:02:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871828.1282820 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlF0-0007TQ-JI; Tue, 14 Jan 2025 18:02:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871828.1282820; Tue, 14 Jan 2025 18:02:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlF0-0007TJ-Gh; Tue, 14 Jan 2025 18:02:14 +0000
Received: by outflank-mailman (input) for mailman id 871828;
 Tue, 14 Jan 2025 18:02:12 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=5Qro=UG=redhat.com=vschneid@srs-se1.protection.inumbo.net>)
 id 1tXlEy-0007Qx-NJ
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 18:02:12 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ac7e49a9-d2a1-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 19:02:10 +0100 (CET)
Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-518-cs0jRgydMTW_3xbdYVeS2w-1; Tue,
 14 Jan 2025 13:02:03 -0500
Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id E1CD319772CA; Tue, 14 Jan 2025 18:01:45 +0000 (UTC)
Received: from vschneid-thinkpadt14sgen2i.remote.csb (unknown [10.39.192.55])
 by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix)
 with ESMTPS id 8F01A195E3EA; Tue, 14 Jan 2025 18:01:23 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ac7e49a9-d2a1-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1736877729;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=KdPtt6PQsN+ylVvy58F0NcuUnOqkUWc+oSjD61c8P1k=;
	b=NHQka2a3xWLe7fk7zsz/YQF3jNUinioLx76Cc3vh6FmHptDDS2rAlgLqsHANha/cQvzRzc
	akq+cE32FvV/nM+ZwL8hrQ4efJ9Kkjr5IJAzN1dmu6DHkzp3vXZAwy6Ssowh5eD76SFdEr
	sljkwS6ozl1Xmw10SjBxP8JWIGwSh8E=
X-MC-Unique: cs0jRgydMTW_3xbdYVeS2w-1
X-Mimecast-MFC-AGG-ID: cs0jRgydMTW_3xbdYVeS2w
From: Valentin Schneider <vschneid@redhat.com>
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	virtualization@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	loongarch@lists.linux.dev,
	linux-riscv@lists.infradead.org,
	linux-perf-users@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	kvm@vger.kernel.org,
	linux-arch@vger.kernel.org,
	rcu@vger.kernel.org,
	linux-hardening@vger.kernel.org,
	linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org,
	bpf@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com
Cc: Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.amakhalov@broadcom.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andy Lutomirski <luto@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Clark Williams <williams@redhat.com>,
	Yair Podemsky <ypodemsk@redhat.com>,
	Tomas Glozar <tglozar@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>,
	Mel Gorman <mgorman@suse.de>,
	Kees Cook <kees@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Shuah Khan <shuah@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Alice Ryhl <aliceryhl@google.com>,
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
	Samuel Holland <samuel.holland@sifive.com>,
	Rong Xu <xur@google.com>,
	Nicolas Saenz Julienne <nsaenzju@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Yosry Ahmed <yosryahmed@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Jinghao Jia <jinghao7@illinois.edu>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: [PATCH v4 21/30] context_tracking: Explicitely use CT_STATE_KERNEL where it is missing
Date: Tue, 14 Jan 2025 18:51:34 +0100
Message-ID: <20250114175143.81438-22-vschneid@redhat.com>
In-Reply-To: <20250114175143.81438-1-vschneid@redhat.com>
References: <20250114175143.81438-1-vschneid@redhat.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15

CT_STATE_KERNEL being zero means it can be (and is) omitted in a handful of
places. A later patch will change CT_STATE_KERNEL into a non-zero value,
prepare that by using it where it should be:

o In the initial CT state
o At kernel entry / exit

No change in functionality intended.

Signed-off-by: Valentin Schneider <vschneid@redhat.com>
---
 kernel/context_tracking.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/kernel/context_tracking.c b/kernel/context_tracking.c
index 938c48952d265..a61498a8425e2 100644
--- a/kernel/context_tracking.c
+++ b/kernel/context_tracking.c
@@ -31,7 +31,7 @@ DEFINE_PER_CPU(struct context_tracking, context_tracking) = {
 	.nesting = 1,
 	.nmi_nesting = CT_NESTING_IRQ_NONIDLE,
 #endif
-	.state = ATOMIC_INIT(CT_RCU_WATCHING),
+	.state = ATOMIC_INIT(CT_RCU_WATCHING | CT_STATE_KERNEL),
 };
 EXPORT_SYMBOL_GPL(context_tracking);
 
@@ -147,7 +147,7 @@ static void noinstr ct_kernel_exit(bool user, int offset)
 	instrumentation_end();
 	WRITE_ONCE(ct->nesting, 0); /* Avoid irq-access tearing. */
 	// RCU is watching here ...
-	ct_kernel_exit_state(offset);
+	ct_kernel_exit_state(offset - CT_STATE_KERNEL);
 	// ... but is no longer watching here.
 	rcu_task_exit();
 }
@@ -175,7 +175,7 @@ static void noinstr ct_kernel_enter(bool user, int offset)
 	}
 	rcu_task_enter();
 	// RCU is not watching here ...
-	ct_kernel_enter_state(offset);
+	ct_kernel_enter_state(offset + CT_STATE_KERNEL);
 	// ... but is watching here.
 	instrumentation_begin();
 
@@ -537,7 +537,7 @@ void noinstr __ct_user_enter(enum ctx_state state)
 				 * RCU only requires CT_RCU_WATCHING increments to be fully
 				 * ordered.
 				 */
-				raw_atomic_add(state, &ct->state);
+				raw_atomic_add(state - CT_STATE_KERNEL, &ct->state);
 			}
 		}
 	}
@@ -647,7 +647,7 @@ void noinstr __ct_user_exit(enum ctx_state state)
 				 * RCU only requires CT_RCU_WATCHING increments to be fully
 				 * ordered.
 				 */
-				raw_atomic_sub(state, &ct->state);
+				raw_atomic_sub(state - CT_STATE_KERNEL, &ct->state);
 			}
 		}
 	}
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 18:02:20 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 18:02:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871832.1282829 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlF6-0007q1-Qb; Tue, 14 Jan 2025 18:02:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871832.1282829; Tue, 14 Jan 2025 18: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 <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlF6-0007pu-Mh; Tue, 14 Jan 2025 18:02:20 +0000
Received: by outflank-mailman (input) for mailman id 871832;
 Tue, 14 Jan 2025 18:02:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=5Qro=UG=redhat.com=vschneid@srs-se1.protection.inumbo.net>)
 id 1tXlF5-0007Qx-IE
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 18:02:19 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b0e3d60c-d2a1-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 19:02:18 +0100 (CET)
Received: from mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-230-RjarLQpsMFScdKhdOdyibw-1; Tue,
 14 Jan 2025 13:02:13 -0500
Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id E0C941955DBA; Tue, 14 Jan 2025 18:02:08 +0000 (UTC)
Received: from vschneid-thinkpadt14sgen2i.remote.csb (unknown [10.39.192.55])
 by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix)
 with ESMTPS id 61C7C195608A; Tue, 14 Jan 2025 18:01:46 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b0e3d60c-d2a1-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1736877736;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=cNwCh5fgGoJuTFO9fvGqFny78uJkIQRICFisC3zeCIo=;
	b=BLl8kuU2hvNfhc/Roltba9jIH/B2bgETmsKpR3nlSe79cQRz9io6Rdd1iVhHQ4oiJIqlb2
	/g9pANjokos4yKv/cXXWBk6Y6EpgLNlkbW0g47v1g6BgkghdBDPMq/FZ0NxoTYwUAdbTAh
	Z2RCNCni0UNx2fb9tNzYZcNlhJKy3qg=
X-MC-Unique: RjarLQpsMFScdKhdOdyibw-1
X-Mimecast-MFC-AGG-ID: RjarLQpsMFScdKhdOdyibw
From: Valentin Schneider <vschneid@redhat.com>
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	virtualization@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	loongarch@lists.linux.dev,
	linux-riscv@lists.infradead.org,
	linux-perf-users@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	kvm@vger.kernel.org,
	linux-arch@vger.kernel.org,
	rcu@vger.kernel.org,
	linux-hardening@vger.kernel.org,
	linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org,
	bpf@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com
Cc: Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.amakhalov@broadcom.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andy Lutomirski <luto@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Clark Williams <williams@redhat.com>,
	Yair Podemsky <ypodemsk@redhat.com>,
	Tomas Glozar <tglozar@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>,
	Mel Gorman <mgorman@suse.de>,
	Kees Cook <kees@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Shuah Khan <shuah@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Alice Ryhl <aliceryhl@google.com>,
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
	Samuel Holland <samuel.holland@sifive.com>,
	Rong Xu <xur@google.com>,
	Nicolas Saenz Julienne <nsaenzju@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Yosry Ahmed <yosryahmed@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Jinghao Jia <jinghao7@illinois.edu>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: [PATCH v4 22/30] context_tracking: Exit CT_STATE_IDLE upon irq/nmi entry
Date: Tue, 14 Jan 2025 18:51:35 +0100
Message-ID: <20250114175143.81438-23-vschneid@redhat.com>
In-Reply-To: <20250114175143.81438-1-vschneid@redhat.com>
References: <20250114175143.81438-1-vschneid@redhat.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15

ct_nmi_{enter, exit}() only touches the RCU watching counter and doesn't
modify the actual CT state part context_tracking.state. This means that
upon receiving an IRQ when idle, the CT_STATE_IDLE->CT_STATE_KERNEL
transition only happens in ct_idle_exit().

One can note that ct_nmi_enter() can only ever be entered with the CT state
as either CT_STATE_KERNEL or CT_STATE_IDLE, as an IRQ/NMI happenning in the
CT_STATE_USER or CT_STATE_GUEST states will be routed down to ct_user_exit().

Add/remove CT_STATE_IDLE from the context tracking state as needed in
ct_nmi_{enter, exit}().

Note that this leaves the following window where the CPU is executing code
in kernelspace, but the context tracking state is CT_STATE_IDLE:

  ~> IRQ
  ct_nmi_enter()
    state = state + CT_STATE_KERNEL - CT_STATE_IDLE

  [...]

  ct_nmi_exit()
    state = state - CT_STATE_KERNEL + CT_STATE_IDLE

  [...] /!\ CT_STATE_IDLE here while we're really in kernelspace! /!\

  ct_cpuidle_exit()
    state = state + CT_STATE_KERNEL - CT_STATE_IDLE

Signed-off-by: Valentin Schneider <vschneid@redhat.com>
---
 kernel/context_tracking.c | 22 +++++++++++++++++++---
 1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/kernel/context_tracking.c b/kernel/context_tracking.c
index a61498a8425e2..15f10ddec8cbe 100644
--- a/kernel/context_tracking.c
+++ b/kernel/context_tracking.c
@@ -236,7 +236,9 @@ void noinstr ct_nmi_exit(void)
 	instrumentation_end();
 
 	// RCU is watching here ...
-	ct_kernel_exit_state(CT_RCU_WATCHING);
+	ct_kernel_exit_state(CT_RCU_WATCHING -
+			     CT_STATE_KERNEL +
+			     CT_STATE_IDLE);
 	// ... but is no longer watching here.
 
 	if (!in_nmi())
@@ -259,6 +261,7 @@ void noinstr ct_nmi_enter(void)
 {
 	long incby = 2;
 	struct context_tracking *ct = this_cpu_ptr(&context_tracking);
+	int curr_state;
 
 	/* Complain about underflow. */
 	WARN_ON_ONCE(ct_nmi_nesting() < 0);
@@ -271,13 +274,26 @@ void noinstr ct_nmi_enter(void)
 	 * to be in the outermost NMI handler that interrupted an RCU-idle
 	 * period (observation due to Andy Lutomirski).
 	 */
-	if (!rcu_is_watching_curr_cpu()) {
+	curr_state = raw_atomic_read(this_cpu_ptr(&context_tracking.state));
+	if (!(curr_state & CT_RCU_WATCHING)) {
 
 		if (!in_nmi())
 			rcu_task_enter();
 
+		/*
+		 * RCU isn't watching, so we're one of
+		 * CT_STATE_IDLE
+		 * CT_STATE_USER
+		 * CT_STATE_GUEST
+		 * guest/user entry is handled by ct_user_enter(), so this has
+		 * to be idle entry.
+		 */
+		WARN_ON_ONCE((curr_state & CT_STATE_MASK) != CT_STATE_IDLE);
+
 		// RCU is not watching here ...
-		ct_kernel_enter_state(CT_RCU_WATCHING);
+		ct_kernel_enter_state(CT_RCU_WATCHING +
+				      CT_STATE_KERNEL -
+				      CT_STATE_IDLE);
 		// ... but is watching here.
 
 		instrumentation_begin();
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 18:02:40 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 18:02:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871845.1282840 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlFQ-0000P5-5D; Tue, 14 Jan 2025 18:02:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871845.1282840; Tue, 14 Jan 2025 18:02:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlFQ-0000OF-2A; Tue, 14 Jan 2025 18:02:40 +0000
Received: by outflank-mailman (input) for mailman id 871845;
 Tue, 14 Jan 2025 18:02:39 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=5Qro=UG=redhat.com=vschneid@srs-se1.protection.inumbo.net>)
 id 1tXlCN-0005qL-GN
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 17:59:31 +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 4b55a646-d2a1-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 18:59:27 +0100 (CET)
Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-317-domFoMd6N8WvyrMSzp1fqA-1; Tue,
 14 Jan 2025 12:59:23 -0500
Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id E586919560B7; Tue, 14 Jan 2025 17:59:19 +0000 (UTC)
Received: from vschneid-thinkpadt14sgen2i.remote.csb (unknown [10.39.192.55])
 by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix)
 with ESMTPS id 21066195608A; Tue, 14 Jan 2025 17:58:54 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 4b55a646-d2a1-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1736877566;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=vzSk9ZzswXx0ijJl+1BL1pcjLYKU11Wq/W2Kyfj2Pb8=;
	b=iHxf/dIi55mPvEiN2Zs2NJNlVrAbi41lkr+hiDzpaKama2WELF4e5+/nchX8jPdrdfs9v7
	IkbIa886dP0LuThAEz7kGPJsoIywwQTl+pzc3gJjoy68tkoc55mHEg9ylNjcC8GNslvi5a
	w0Pt/c+ZztZcu4M3/Mt+Z0b2qPJRWcI=
X-MC-Unique: domFoMd6N8WvyrMSzp1fqA-1
X-Mimecast-MFC-AGG-ID: domFoMd6N8WvyrMSzp1fqA
From: Valentin Schneider <vschneid@redhat.com>
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	virtualization@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	loongarch@lists.linux.dev,
	linux-riscv@lists.infradead.org,
	linux-perf-users@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	kvm@vger.kernel.org,
	linux-arch@vger.kernel.org,
	rcu@vger.kernel.org,
	linux-hardening@vger.kernel.org,
	linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org,
	bpf@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com
Cc: Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.amakhalov@broadcom.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andy Lutomirski <luto@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Clark Williams <williams@redhat.com>,
	Yair Podemsky <ypodemsk@redhat.com>,
	Tomas Glozar <tglozar@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>,
	Mel Gorman <mgorman@suse.de>,
	Kees Cook <kees@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Shuah Khan <shuah@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Alice Ryhl <aliceryhl@google.com>,
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
	Samuel Holland <samuel.holland@sifive.com>,
	Rong Xu <xur@google.com>,
	Nicolas Saenz Julienne <nsaenzju@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Yosry Ahmed <yosryahmed@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Jinghao Jia <jinghao7@illinois.edu>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: [PATCH v4 15/30] sched/clock: Mark sched_clock_running key as __ro_after_init
Date: Tue, 14 Jan 2025 18:51:28 +0100
Message-ID: <20250114175143.81438-16-vschneid@redhat.com>
In-Reply-To: <20250114175143.81438-1-vschneid@redhat.com>
References: <20250114175143.81438-1-vschneid@redhat.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15

sched_clock_running is only ever enabled in the __init functions
sched_clock_init() and sched_clock_init_late(), and is never disabled. Mark
it __ro_after_init.

Signed-off-by: Valentin Schneider <vschneid@redhat.com>
---
 kernel/sched/clock.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/clock.c b/kernel/sched/clock.c
index a09655b481402..200e5568b9894 100644
--- a/kernel/sched/clock.c
+++ b/kernel/sched/clock.c
@@ -66,7 +66,7 @@ notrace unsigned long long __weak sched_clock(void)
 }
 EXPORT_SYMBOL_GPL(sched_clock);
 
-static DEFINE_STATIC_KEY_FALSE(sched_clock_running);
+static DEFINE_STATIC_KEY_FALSE_RO(sched_clock_running);
 
 #ifdef CONFIG_HAVE_UNSTABLE_SCHED_CLOCK
 /*
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 18:02:40 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 18:02:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871846.1282845 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlFQ-0000UE-HB; Tue, 14 Jan 2025 18:02:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871846.1282845; Tue, 14 Jan 2025 18:02:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlFQ-0000T0-9V; Tue, 14 Jan 2025 18:02:40 +0000
Received: by outflank-mailman (input) for mailman id 871846;
 Tue, 14 Jan 2025 18:02: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
 <SRS0=5Qro=UG=redhat.com=vschneid@srs-se1.protection.inumbo.net>)
 id 1tXlDC-0003Eo-94
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 18:00:22 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.129.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6afc6d12-d2a1-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 19:00:20 +0100 (CET)
Received: from mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-113-k3wLyZ7iPkiQIoWyV-6PFw-1; Tue,
 14 Jan 2025 13:00:14 -0500
Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id BD2A51955DE0; Tue, 14 Jan 2025 18:00:10 +0000 (UTC)
Received: from vschneid-thinkpadt14sgen2i.remote.csb (unknown [10.39.192.55])
 by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix)
 with ESMTPS id 79BA9195E3E0; Tue, 14 Jan 2025 17:59:46 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 6afc6d12-d2a1-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1736877619;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=oEa6Jvbfjlidl4MXGQFSAZ9P76MqELccnrf7elTRMWU=;
	b=NRl+6MoNTIWNe2+aYksDm9CbWvaZYeQSgCc56F60q0bHR/eiC7JeMihvCji9EGzQrR6lpp
	mZl5CaUMXVIR6gdULu1eAQ0yDQMTXZ23sILPWR91CK2OEhSm0Dh7a22eseGtNva6UMBpy4
	RiokD6VQ5LLE+Arp3NVUGBWKE2VFn68=
X-MC-Unique: k3wLyZ7iPkiQIoWyV-6PFw-1
X-Mimecast-MFC-AGG-ID: k3wLyZ7iPkiQIoWyV-6PFw
From: Valentin Schneider <vschneid@redhat.com>
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	virtualization@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	loongarch@lists.linux.dev,
	linux-riscv@lists.infradead.org,
	linux-perf-users@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	kvm@vger.kernel.org,
	linux-arch@vger.kernel.org,
	rcu@vger.kernel.org,
	linux-hardening@vger.kernel.org,
	linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org,
	bpf@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com
Cc: Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.amakhalov@broadcom.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andy Lutomirski <luto@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Clark Williams <williams@redhat.com>,
	Yair Podemsky <ypodemsk@redhat.com>,
	Tomas Glozar <tglozar@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>,
	Mel Gorman <mgorman@suse.de>,
	Kees Cook <kees@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Shuah Khan <shuah@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Alice Ryhl <aliceryhl@google.com>,
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
	Samuel Holland <samuel.holland@sifive.com>,
	Rong Xu <xur@google.com>,
	Nicolas Saenz Julienne <nsaenzju@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Yosry Ahmed <yosryahmed@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Jinghao Jia <jinghao7@illinois.edu>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: [PATCH v4 17/30] sched/clock, x86: Mark __sched_clock_stable key as allowed in .noinstr
Date: Tue, 14 Jan 2025 18:51:30 +0100
Message-ID: <20250114175143.81438-18-vschneid@redhat.com>
In-Reply-To: <20250114175143.81438-1-vschneid@redhat.com>
References: <20250114175143.81438-1-vschneid@redhat.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15

Later commits will cause objtool to warn about static keys being used in
.noinstr sections in order to safely defer instruction patching IPIs
targeted at NOHZ_FULL CPUs.

__sched_clock_stable is used in .noinstr code, and can be modified at
runtime (e.g. time_cpufreq_notifier()). Suppressing the text_poke_sync()
IPI has little benefits for this key, as NOHZ_FULL is incompatible with an
unstable TSC anyway.

Mark it to let objtool know not to warn about it.

Signed-off-by: Valentin Schneider <vschneid@redhat.com>
---
 kernel/sched/clock.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/kernel/sched/clock.c b/kernel/sched/clock.c
index 200e5568b9894..e59986bc14a43 100644
--- a/kernel/sched/clock.c
+++ b/kernel/sched/clock.c
@@ -75,8 +75,11 @@ static DEFINE_STATIC_KEY_FALSE_RO(sched_clock_running);
  *
  * Similarly we start with __sched_clock_stable_early, thereby assuming we
  * will become stable, such that there's only a single 1 -> 0 transition.
+ *
+ * Allowed in .noinstr as an unstable TLC is incompatible with NOHZ_FULL,
+ * thus the text patching IPI would be the least of our concerns.
  */
-static DEFINE_STATIC_KEY_FALSE(__sched_clock_stable);
+static DEFINE_STATIC_KEY_FALSE_NOINSTR(__sched_clock_stable);
 static int __sched_clock_stable_early = 1;
 
 /*
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 18:03:56 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 18:03:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871868.1282859 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlGY-00021C-NR; Tue, 14 Jan 2025 18:03:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871868.1282859; Tue, 14 Jan 2025 18:03:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlGY-000215-Ku; Tue, 14 Jan 2025 18:03:50 +0000
Received: by outflank-mailman (input) for mailman id 871868;
 Tue, 14 Jan 2025 18:03: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
 <SRS0=5Qro=UG=redhat.com=vschneid@srs-se1.protection.inumbo.net>)
 id 1tXlGW-00020k-VQ
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 18:03:48 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e5c83772-d2a1-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 19:03:46 +0100 (CET)
Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-412-RjogcdnCPlS1FV6yZ4Sprw-1; Tue,
 14 Jan 2025 13:03:43 -0500
Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 3C8EC19560B3; Tue, 14 Jan 2025 18:03:39 +0000 (UTC)
Received: from vschneid-thinkpadt14sgen2i.remote.csb (unknown [10.39.192.55])
 by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix)
 with ESMTPS id 2905C195608A; Tue, 14 Jan 2025 18:03:16 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e5c83772-d2a1-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1736877825;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=le8UIdWvg/w/MVcf7PTpfkO3a8bfCjcr6cLgmw3M858=;
	b=DNZqEs2YY90KWegLtUNMKTwGRPETPz7uCY9w/Jl4tAw8gybvD7b4bi/cWIqw/SuBJbNp7i
	yVj1xOiIOjCmvBJAvMr3WjQO/v0r9DOwvBiK8rQUtX2Sy+QytQV4Nst4RLwqpYrvj7rvxO
	Uv0Gq9b9D4k9p6dc95qGs2pBbe0XxHM=
X-MC-Unique: RjogcdnCPlS1FV6yZ4Sprw-1
X-Mimecast-MFC-AGG-ID: RjogcdnCPlS1FV6yZ4Sprw
From: Valentin Schneider <vschneid@redhat.com>
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	virtualization@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	loongarch@lists.linux.dev,
	linux-riscv@lists.infradead.org,
	linux-perf-users@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	kvm@vger.kernel.org,
	linux-arch@vger.kernel.org,
	rcu@vger.kernel.org,
	linux-hardening@vger.kernel.org,
	linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org,
	bpf@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com
Cc: Peter Zijlstra <peterz@infradead.org>,
	Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.amakhalov@broadcom.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andy Lutomirski <luto@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Clark Williams <williams@redhat.com>,
	Yair Podemsky <ypodemsk@redhat.com>,
	Tomas Glozar <tglozar@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>,
	Mel Gorman <mgorman@suse.de>,
	Kees Cook <kees@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Shuah Khan <shuah@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Alice Ryhl <aliceryhl@google.com>,
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
	Samuel Holland <samuel.holland@sifive.com>,
	Rong Xu <xur@google.com>,
	Nicolas Saenz Julienne <nsaenzju@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Yosry Ahmed <yosryahmed@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Jinghao Jia <jinghao7@illinois.edu>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: [PATCH v4 26/30] x86,tlb: Make __flush_tlb_global() noinstr-compliant
Date: Tue, 14 Jan 2025 18:51:39 +0100
Message-ID: <20250114175143.81438-27-vschneid@redhat.com>
In-Reply-To: <20250114175143.81438-1-vschneid@redhat.com>
References: <20250114175143.81438-1-vschneid@redhat.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15

From: Peter Zijlstra <peterz@infradead.org>

Later patches will require issuing a __flush_tlb_all() from noinstr code.
This requires making both __flush_tlb_local() and __flush_tlb_global()
noinstr-compliant.

For __flush_tlb_global(), both native_flush_tlb_global() and xen_flush_tlb()
need to be made noinstr.

Forgo using __native_flush_tlb_global() / native_write_cr4() and have the
ASM directly inlined in the native function. For the Xen stuff,
__always_inline a handful of helpers.

Not-signed-off-by: Peter Zijlstra <peterz@infradead.org>
[Changelog faff]
Signed-off-by: Valentin Schneider <vschneid@redhat.com>
---
 arch/x86/include/asm/invpcid.h       | 13 ++++++-------
 arch/x86/include/asm/paravirt.h      |  2 +-
 arch/x86/include/asm/xen/hypercall.h | 11 +++++++++--
 arch/x86/mm/tlb.c                    | 15 +++++++++++----
 arch/x86/xen/mmu_pv.c                | 10 +++++-----
 arch/x86/xen/xen-ops.h               | 12 ++++++++----
 6 files changed, 40 insertions(+), 23 deletions(-)

diff --git a/arch/x86/include/asm/invpcid.h b/arch/x86/include/asm/invpcid.h
index 734482afbf81d..ff26136fcd9c6 100644
--- a/arch/x86/include/asm/invpcid.h
+++ b/arch/x86/include/asm/invpcid.h
@@ -2,7 +2,7 @@
 #ifndef _ASM_X86_INVPCID
 #define _ASM_X86_INVPCID
 
-static inline void __invpcid(unsigned long pcid, unsigned long addr,
+static __always_inline void __invpcid(unsigned long pcid, unsigned long addr,
 			     unsigned long type)
 {
 	struct { u64 d[2]; } desc = { { pcid, addr } };
@@ -13,7 +13,7 @@ static inline void __invpcid(unsigned long pcid, unsigned long addr,
 	 * mappings, we don't want the compiler to reorder any subsequent
 	 * memory accesses before the TLB flush.
 	 */
-	asm volatile("invpcid %[desc], %[type]"
+	asm_inline volatile("invpcid %[desc], %[type]"
 		     :: [desc] "m" (desc), [type] "r" (type) : "memory");
 }
 
@@ -23,26 +23,25 @@ static inline void __invpcid(unsigned long pcid, unsigned long addr,
 #define INVPCID_TYPE_ALL_NON_GLOBAL	3
 
 /* Flush all mappings for a given pcid and addr, not including globals. */
-static inline void invpcid_flush_one(unsigned long pcid,
-				     unsigned long addr)
+static __always_inline void invpcid_flush_one(unsigned long pcid, unsigned long addr)
 {
 	__invpcid(pcid, addr, INVPCID_TYPE_INDIV_ADDR);
 }
 
 /* Flush all mappings for a given PCID, not including globals. */
-static inline void invpcid_flush_single_context(unsigned long pcid)
+static __always_inline void invpcid_flush_single_context(unsigned long pcid)
 {
 	__invpcid(pcid, 0, INVPCID_TYPE_SINGLE_CTXT);
 }
 
 /* Flush all mappings, including globals, for all PCIDs. */
-static inline void invpcid_flush_all(void)
+static __always_inline void invpcid_flush_all(void)
 {
 	__invpcid(0, 0, INVPCID_TYPE_ALL_INCL_GLOBAL);
 }
 
 /* Flush all mappings for all PCIDs except globals. */
-static inline void invpcid_flush_all_nonglobals(void)
+static __always_inline void invpcid_flush_all_nonglobals(void)
 {
 	__invpcid(0, 0, INVPCID_TYPE_ALL_NON_GLOBAL);
 }
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index d4eb9e1d61b8e..b3daee3d46677 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -75,7 +75,7 @@ static inline void __flush_tlb_local(void)
 	PVOP_VCALL0(mmu.flush_tlb_user);
 }
 
-static inline void __flush_tlb_global(void)
+static __always_inline void __flush_tlb_global(void)
 {
 	PVOP_VCALL0(mmu.flush_tlb_kernel);
 }
diff --git a/arch/x86/include/asm/xen/hypercall.h b/arch/x86/include/asm/xen/hypercall.h
index 97771b9d33af3..291e9f8006f62 100644
--- a/arch/x86/include/asm/xen/hypercall.h
+++ b/arch/x86/include/asm/xen/hypercall.h
@@ -365,8 +365,8 @@ MULTI_mmu_update(struct multicall_entry *mcl, struct mmu_update *req,
 	trace_xen_mc_entry(mcl, 4);
 }
 
-static inline void
-MULTI_mmuext_op(struct multicall_entry *mcl, struct mmuext_op *op, int count,
+static __always_inline void
+__MULTI_mmuext_op(struct multicall_entry *mcl, struct mmuext_op *op, int count,
 		int *success_count, domid_t domid)
 {
 	mcl->op = __HYPERVISOR_mmuext_op;
@@ -374,6 +374,13 @@ MULTI_mmuext_op(struct multicall_entry *mcl, struct mmuext_op *op, int count,
 	mcl->args[1] = count;
 	mcl->args[2] = (unsigned long)success_count;
 	mcl->args[3] = domid;
+}
+
+static inline void
+MULTI_mmuext_op(struct multicall_entry *mcl, struct mmuext_op *op, int count,
+		int *success_count, domid_t domid)
+{
+	__MULTI_mmuext_op(mcl, op, count, success_count, domid);
 
 	trace_xen_mc_entry(mcl, 4);
 }
diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index a2becb85bea79..2d2ab3e221f0c 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -1169,9 +1169,10 @@ void flush_tlb_one_user(unsigned long addr)
 /*
  * Flush everything
  */
-STATIC_NOPV void native_flush_tlb_global(void)
+STATIC_NOPV noinstr void native_flush_tlb_global(void)
 {
 	unsigned long flags;
+	unsigned long cr4;
 
 	if (static_cpu_has(X86_FEATURE_INVPCID)) {
 		/*
@@ -1190,9 +1191,15 @@ STATIC_NOPV void native_flush_tlb_global(void)
 	 * be called from deep inside debugging code.)
 	 */
 	raw_local_irq_save(flags);
-
-	__native_tlb_flush_global(this_cpu_read(cpu_tlbstate.cr4));
-
+	cr4 = this_cpu_read(cpu_tlbstate.cr4);
+	asm volatile("mov %0,%%cr4": : "r" (cr4 ^ X86_CR4_PGE) : "memory");
+	asm volatile("mov %0,%%cr4": : "r" (cr4) : "memory");
+	/*
+	 * In lieu of not having the pinning crap, hard fail if CR4 doesn't
+	 * match the expected value. This ensures that anybody doing dodgy gets
+	 * the fallthrough check.
+	 */
+	BUG_ON(cr4 != this_cpu_read(cpu_tlbstate.cr4));
 	raw_local_irq_restore(flags);
 }
 
diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
index 55a4996d0c04f..4eb265eb867af 100644
--- a/arch/x86/xen/mmu_pv.c
+++ b/arch/x86/xen/mmu_pv.c
@@ -1231,22 +1231,22 @@ static noinstr void xen_write_cr2(unsigned long cr2)
 	this_cpu_read(xen_vcpu)->arch.cr2 = cr2;
 }
 
-static noinline void xen_flush_tlb(void)
+static noinline noinstr void xen_flush_tlb(void)
 {
 	struct mmuext_op *op;
 	struct multicall_space mcs;
 
-	preempt_disable();
+	preempt_disable_notrace();
 
 	mcs = xen_mc_entry(sizeof(*op));
 
 	op = mcs.args;
 	op->cmd = MMUEXT_TLB_FLUSH_LOCAL;
-	MULTI_mmuext_op(mcs.mc, op, 1, NULL, DOMID_SELF);
+	__MULTI_mmuext_op(mcs.mc, op, 1, NULL, DOMID_SELF);
 
-	xen_mc_issue(XEN_LAZY_MMU);
+	__xen_mc_issue(XEN_LAZY_MMU);
 
-	preempt_enable();
+	preempt_enable_notrace();
 }
 
 static void xen_flush_tlb_one_user(unsigned long addr)
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 63c13a2ccf556..effb1a54afbd1 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -235,15 +235,19 @@ static inline struct multicall_space xen_mc_entry(size_t args)
 void xen_mc_flush(void);
 
 /* Issue a multicall if we're not in a lazy mode */
-static inline void xen_mc_issue(unsigned mode)
+static __always_inline void __xen_mc_issue(unsigned mode)
 {
-	trace_xen_mc_issue(mode);
-
 	if ((xen_get_lazy_mode() & mode) == 0)
 		xen_mc_flush();
 
 	/* restore flags saved in xen_mc_batch */
-	local_irq_restore(this_cpu_read(xen_mc_irq_flags));
+	raw_local_irq_restore(this_cpu_read(xen_mc_irq_flags));
+}
+
+static inline void xen_mc_issue(unsigned mode)
+{
+	trace_xen_mc_issue(mode);
+	__xen_mc_issue(mode);
 }
 
 /* Set up a callback to be called when the current batch is flushed */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 18:04:16 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 18:04:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871873.1282869 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlGw-0002Qc-Vn; Tue, 14 Jan 2025 18:04:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871873.1282869; Tue, 14 Jan 2025 18:04:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlGw-0002QQ-Su; Tue, 14 Jan 2025 18:04:14 +0000
Received: by outflank-mailman (input) for mailman id 871873;
 Tue, 14 Jan 2025 18:04: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
 <SRS0=5Qro=UG=redhat.com=vschneid@srs-se1.protection.inumbo.net>)
 id 1tXlGv-00020k-Kc
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 18:04:13 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f4e7a2ba-d2a1-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 19:04:12 +0100 (CET)
Received: from mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-686-2bGxv9G8MbqEpONYIM0Pig-1; Tue,
 14 Jan 2025 13:04:06 -0500
Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id EBCE81955D4F; Tue, 14 Jan 2025 18:04:02 +0000 (UTC)
Received: from vschneid-thinkpadt14sgen2i.remote.csb (unknown [10.39.192.55])
 by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix)
 with ESMTPS id B2065195608A; Tue, 14 Jan 2025 18:03:39 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f4e7a2ba-d2a1-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1736877851;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=qfGcbREmcisg82Rx6e546I8mjQ8z9ythW/HTCaSXKy0=;
	b=WLV+BK04usADxOLWfM+FvX0hhi9YK47HjESrIAefdVzMVpkjseURyvf7b6NqaPGMlT7fhL
	lNeCY7vRtpnRW067G8oTvjsu0fhG0qDioYE/XSc8jZ1gFgdBiKum1yva36xCAhixGXG3AX
	fbqBbXixeNCjANrnsFebsn46YZyJq0I=
X-MC-Unique: 2bGxv9G8MbqEpONYIM0Pig-1
X-Mimecast-MFC-AGG-ID: 2bGxv9G8MbqEpONYIM0Pig
From: Valentin Schneider <vschneid@redhat.com>
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	virtualization@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	loongarch@lists.linux.dev,
	linux-riscv@lists.infradead.org,
	linux-perf-users@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	kvm@vger.kernel.org,
	linux-arch@vger.kernel.org,
	rcu@vger.kernel.org,
	linux-hardening@vger.kernel.org,
	linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org,
	bpf@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com
Cc: Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.amakhalov@broadcom.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andy Lutomirski <luto@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Clark Williams <williams@redhat.com>,
	Yair Podemsky <ypodemsk@redhat.com>,
	Tomas Glozar <tglozar@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>,
	Mel Gorman <mgorman@suse.de>,
	Kees Cook <kees@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Shuah Khan <shuah@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Alice Ryhl <aliceryhl@google.com>,
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
	Samuel Holland <samuel.holland@sifive.com>,
	Rong Xu <xur@google.com>,
	Nicolas Saenz Julienne <nsaenzju@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Yosry Ahmed <yosryahmed@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Jinghao Jia <jinghao7@illinois.edu>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: [PATCH v4 27/30] x86/tlb: Make __flush_tlb_local() noinstr-compliant
Date: Tue, 14 Jan 2025 18:51:40 +0100
Message-ID: <20250114175143.81438-28-vschneid@redhat.com>
In-Reply-To: <20250114175143.81438-1-vschneid@redhat.com>
References: <20250114175143.81438-1-vschneid@redhat.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15

Later patches will require issuing a __flush_tlb_all() from noinstr code.
This requires making both __flush_tlb_local() and __flush_tlb_global()
noinstr-compliant.

For __flush_tlb_local(), xen_flush_tlb() has already been made noinstr, so
it's just native_flush_tlb_global(), and simply __always_inline'ing
invalidate_user_asid() gets us there

Signed-off-by: Valentin Schneider <vschneid@redhat.com>
---
 arch/x86/include/asm/paravirt.h | 2 +-
 arch/x86/mm/tlb.c               | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index b3daee3d46677..0c0dd186c03e6 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -70,7 +70,7 @@ void native_flush_tlb_one_user(unsigned long addr);
 void native_flush_tlb_multi(const struct cpumask *cpumask,
 			     const struct flush_tlb_info *info);
 
-static inline void __flush_tlb_local(void)
+static __always_inline void __flush_tlb_local(void)
 {
 	PVOP_VCALL0(mmu.flush_tlb_user);
 }
diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index 2d2ab3e221f0c..18b40bbc2fa15 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -257,7 +257,7 @@ static void choose_new_asid(struct mm_struct *next, u64 next_tlb_gen,
  *
  * See SWITCH_TO_USER_CR3.
  */
-static inline void invalidate_user_asid(u16 asid)
+static __always_inline void invalidate_user_asid(u16 asid)
 {
 	/* There is no user ASID if address space separation is off */
 	if (!IS_ENABLED(CONFIG_MITIGATION_PAGE_TABLE_ISOLATION))
@@ -1206,7 +1206,7 @@ STATIC_NOPV noinstr void native_flush_tlb_global(void)
 /*
  * Flush the entire current user mapping
  */
-STATIC_NOPV void native_flush_tlb_local(void)
+STATIC_NOPV noinstr void native_flush_tlb_local(void)
 {
 	/*
 	 * Preemption or interrupts must be disabled to protect the access
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 18:04:35 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 18:04:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871885.1282880 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlHH-0002wD-DA; Tue, 14 Jan 2025 18:04:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871885.1282880; Tue, 14 Jan 2025 18:04:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlHH-0002w6-9s; Tue, 14 Jan 2025 18:04:35 +0000
Received: by outflank-mailman (input) for mailman id 871885;
 Tue, 14 Jan 2025 18:04:34 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=5Qro=UG=redhat.com=vschneid@srs-se1.protection.inumbo.net>)
 id 1tXlHG-00020k-FT
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 18:04:34 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 014e6ad5-d2a2-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 19:04:32 +0100 (CET)
Received: from mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-442-YsncyNivNYmsu48rkVhymA-1; Tue,
 14 Jan 2025 13:04:29 -0500
Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id A7D431955DCF; Tue, 14 Jan 2025 18:04:25 +0000 (UTC)
Received: from vschneid-thinkpadt14sgen2i.remote.csb (unknown [10.39.192.55])
 by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix)
 with ESMTPS id 6C14D195608A; Tue, 14 Jan 2025 18:04:03 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 014e6ad5-d2a2-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1736877871;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=uZZLtjs3Zw6jRIC16nznFhpiKaBBT8sXvDLj8C27htE=;
	b=IRLYbPE1iQ7D+oFw/E8QsjMOw9Aa5YcdjjYc0ucb2YmBi3FfcGKPkSK+QVEtA5VwwC0LIo
	dWkG6gFS0hT0GrZISpcM/Q7gq3HCrcMmzMa7JDI8nUdxvNxpVlMHorK7H8jKtphBXq8IB/
	q+6XdhmiOX1j0S69BgsghHtyBJnc81Y=
X-MC-Unique: YsncyNivNYmsu48rkVhymA-1
X-Mimecast-MFC-AGG-ID: YsncyNivNYmsu48rkVhymA
From: Valentin Schneider <vschneid@redhat.com>
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	virtualization@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	loongarch@lists.linux.dev,
	linux-riscv@lists.infradead.org,
	linux-perf-users@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	kvm@vger.kernel.org,
	linux-arch@vger.kernel.org,
	rcu@vger.kernel.org,
	linux-hardening@vger.kernel.org,
	linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org,
	bpf@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com
Cc: Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.amakhalov@broadcom.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andy Lutomirski <luto@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Clark Williams <williams@redhat.com>,
	Yair Podemsky <ypodemsk@redhat.com>,
	Tomas Glozar <tglozar@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>,
	Mel Gorman <mgorman@suse.de>,
	Kees Cook <kees@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Shuah Khan <shuah@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Alice Ryhl <aliceryhl@google.com>,
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
	Samuel Holland <samuel.holland@sifive.com>,
	Rong Xu <xur@google.com>,
	Nicolas Saenz Julienne <nsaenzju@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Yosry Ahmed <yosryahmed@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Jinghao Jia <jinghao7@illinois.edu>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: [PATCH v4 28/30] x86/tlb: Make __flush_tlb_all() noinstr
Date: Tue, 14 Jan 2025 18:51:41 +0100
Message-ID: <20250114175143.81438-29-vschneid@redhat.com>
In-Reply-To: <20250114175143.81438-1-vschneid@redhat.com>
References: <20250114175143.81438-1-vschneid@redhat.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15

Later patches will require issuing a __flush_tlb_all() from noinstr code.
Both __flush_tlb_local() and __flush_tlb_global() are now
noinstr-compliant, so __flush_tlb_all() can be made noinstr itself.

Signed-off-by: Valentin Schneider <vschneid@redhat.com>
---
 arch/x86/include/asm/tlbflush.h | 2 +-
 arch/x86/mm/tlb.c               | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
index 69e79fff41b80..4d11396250999 100644
--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -17,7 +17,7 @@
 
 DECLARE_PER_CPU(u64, tlbstate_untag_mask);
 
-void __flush_tlb_all(void);
+noinstr void __flush_tlb_all(void);
 
 #define TLB_FLUSH_ALL	-1UL
 #define TLB_GENERATION_INVALID	0
diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index 18b40bbc2fa15..119765772ab11 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -1229,7 +1229,7 @@ void flush_tlb_local(void)
 /*
  * Flush everything
  */
-void __flush_tlb_all(void)
+noinstr void __flush_tlb_all(void)
 {
 	/*
 	 * This is to catch users with enabled preemption and the PGE feature
@@ -1243,7 +1243,7 @@ void __flush_tlb_all(void)
 		/*
 		 * !PGE -> !PCID (setup_pcid()), thus every flush is total.
 		 */
-		flush_tlb_local();
+		__flush_tlb_local();
 	}
 }
 EXPORT_SYMBOL_GPL(__flush_tlb_all);
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 18:05:02 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 18:05:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871896.1282890 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlHg-0003VT-Kd; Tue, 14 Jan 2025 18:05:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871896.1282890; Tue, 14 Jan 2025 18:05:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlHg-0003VM-Hk; Tue, 14 Jan 2025 18:05:00 +0000
Received: by outflank-mailman (input) for mailman id 871896;
 Tue, 14 Jan 2025 18:04: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
 <SRS0=5Qro=UG=redhat.com=vschneid@srs-se1.protection.inumbo.net>)
 id 1tXlHf-00020k-Hd
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 18:04:59 +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 0ffdb93f-d2a2-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 19:04:57 +0100 (CET)
Received: from mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-665-qGEuL7tjNvSDQHBRs9YUmQ-1; Tue,
 14 Jan 2025 13:04:52 -0500
Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 69F741955D53; Tue, 14 Jan 2025 18:04:49 +0000 (UTC)
Received: from vschneid-thinkpadt14sgen2i.remote.csb (unknown [10.39.192.55])
 by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix)
 with ESMTPS id 2A353195608A; Tue, 14 Jan 2025 18:04:25 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 0ffdb93f-d2a2-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1736877896;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=qclZNz9KUbrYZjVF2oHux5/JPahdxImvR1KpALrIQ34=;
	b=U3/4lIPSpHv5yUv/D1OpO6sBQIbkc1hbS4mHYvWBFPlIzKmMsSg9jEZ56Vfx4H1CdGE3Ds
	zxnoTBaQiq48+MSEYiM6o9zxjIANJPtI5GFD8cTaV2ECsYgYNWbl8ZIRikcq+ctTNVjTZF
	c/w3TxEUB5SEuJMIdWcDQDPoUJy+AOU=
X-MC-Unique: qGEuL7tjNvSDQHBRs9YUmQ-1
X-Mimecast-MFC-AGG-ID: qGEuL7tjNvSDQHBRs9YUmQ
From: Valentin Schneider <vschneid@redhat.com>
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	virtualization@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	loongarch@lists.linux.dev,
	linux-riscv@lists.infradead.org,
	linux-perf-users@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	kvm@vger.kernel.org,
	linux-arch@vger.kernel.org,
	rcu@vger.kernel.org,
	linux-hardening@vger.kernel.org,
	linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org,
	bpf@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com
Cc: Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.amakhalov@broadcom.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andy Lutomirski <luto@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Clark Williams <williams@redhat.com>,
	Yair Podemsky <ypodemsk@redhat.com>,
	Tomas Glozar <tglozar@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>,
	Mel Gorman <mgorman@suse.de>,
	Kees Cook <kees@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Shuah Khan <shuah@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Alice Ryhl <aliceryhl@google.com>,
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
	Samuel Holland <samuel.holland@sifive.com>,
	Rong Xu <xur@google.com>,
	Nicolas Saenz Julienne <nsaenzju@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Yosry Ahmed <yosryahmed@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Jinghao Jia <jinghao7@illinois.edu>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: [PATCH v4 29/30] x86/mm, mm/vmalloc: Defer flush_tlb_kernel_range() targeting NOHZ_FULL CPUs
Date: Tue, 14 Jan 2025 18:51:42 +0100
Message-ID: <20250114175143.81438-30-vschneid@redhat.com>
In-Reply-To: <20250114175143.81438-1-vschneid@redhat.com>
References: <20250114175143.81438-1-vschneid@redhat.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15

vunmap()'s issued from housekeeping CPUs are a relatively common source of
interference for isolated NOHZ_FULL CPUs, as they are hit by the
flush_tlb_kernel_range() IPIs.

Given that CPUs executing in userspace do not access data in the vmalloc
range, these IPIs could be deferred until their next kernel entry.

Deferral vs early entry danger zone
===================================

This requires a guarantee that nothing in the vmalloc range can be vunmap'd
and then accessed in early entry code.

Vmalloc uses are, as reported by vmallocinfo:

  $ cat /proc/vmallocinfo | awk '{ print $3 }' | sort | uniq
  __pci_enable_msix_range+0x32b/0x560
  acpi_os_map_iomem+0x22d/0x250
  bpf_prog_alloc_no_stats+0x34/0x140
  fork_idle+0x79/0x120
  gen_pool_add_owner+0x3e/0xb0          ?
  hpet_enable+0xbf/0x470
  irq_init_percpu_irqstack+0x129/0x160
  kernel_clone+0xab/0x3b0
  memremap+0x164/0x330
  n_tty_open+0x18/0xa0
  pcpu_create_chunk+0x4e/0x1b0
  pcpu_create_chunk+0x75/0x1b0
  pcpu_get_vm_areas+0x0/0x1100
  unpurged
  vp_modern_map_capability+0x140/0x270
  zisofs_init+0x16/0x30

I've categorized these as:

a) Device or percpu mappings

   For these to be unmapped, the device (or CPU) has to be removed and an
   eventual IRQ freed. Even if the IRQ isn't freed, context tracking entry
   happens before handling the IRQ itself, per irqentry_enter() usage.

   __pci_enable_msix_range()
   acpi_os_map_iomem()
   irq_init_percpu_irqstack() (not even unmapped when CPU is hot-unplugged!)
   memremap()
   n_tty_open()
   pcpu_create_chunk()
   pcpu_get_vm_areas()
   vp_modern_map_capability()

b) CONFIG_VMAP_STACK

  fork_idle() & kernel_clone()

  vmalloc'd kernel stacks are AFAICT a safe example, as a task running in
  userspace needs to enter kernelspace to execute do_exit() before its
  stack can be vfree'd.

c) Non-issues

  bpf_prog_alloc_no_stats() - early entry is noinstr, no BPF!
  hpet_enable() - hpet_clear_mapping() is only called if __init function
		  fails, no runtime worries
  zisofs_init () - used for zisofs block decompression, that's way past
		   context tracking entry

d) I'm not sure, have a look?

  gen_pool_add_owner() - AIUI this is mainly for PCI / DMA stuff, which
			 again I wouldn't expect to be accessed before
			 context tracking entry.

Changes
======

Blindly deferring any and all flush of the kernel mappings is a risky move,
so introduce a variant of flush_tlb_kernel_range() that explicitly allows
deferral. Use it for vunmap flushes.

Note that while flush_tlb_kernel_range() may end up issuing a full
flush (including user mappings), this only happens when reaching a
invalidation range threshold where it is cheaper to do a full flush than to
individually invalidate each page in the range via INVLPG. IOW, it doesn't
*require* invalidating user mappings, and thus remains safe to defer until
a later kernel entry.

Signed-off-by: Valentin Schneider <vschneid@redhat.com>
---
 arch/x86/include/asm/context_tracking_work.h |  4 +++
 arch/x86/include/asm/tlbflush.h              |  1 +
 arch/x86/mm/tlb.c                            | 23 +++++++++++--
 include/linux/context_tracking_work.h        |  4 ++-
 mm/vmalloc.c                                 | 35 +++++++++++++++++---
 5 files changed, 58 insertions(+), 9 deletions(-)

diff --git a/arch/x86/include/asm/context_tracking_work.h b/arch/x86/include/asm/context_tracking_work.h
index 485b32881fde5..da3d270289836 100644
--- a/arch/x86/include/asm/context_tracking_work.h
+++ b/arch/x86/include/asm/context_tracking_work.h
@@ -3,6 +3,7 @@
 #define _ASM_X86_CONTEXT_TRACKING_WORK_H
 
 #include <asm/sync_core.h>
+#include <asm/tlbflush.h>
 
 static __always_inline void arch_context_tracking_work(enum ct_work work)
 {
@@ -10,6 +11,9 @@ static __always_inline void arch_context_tracking_work(enum ct_work work)
 	case CT_WORK_SYNC:
 		sync_core();
 		break;
+	case CT_WORK_TLBI:
+		__flush_tlb_all();
+		break;
 	case CT_WORK_MAX:
 		WARN_ON_ONCE(true);
 	}
diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
index 4d11396250999..6e690acc35e53 100644
--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -248,6 +248,7 @@ extern void flush_tlb_mm_range(struct mm_struct *mm, unsigned long start,
 				unsigned long end, unsigned int stride_shift,
 				bool freed_tables);
 extern void flush_tlb_kernel_range(unsigned long start, unsigned long end);
+extern void flush_tlb_kernel_range_deferrable(unsigned long start, unsigned long end);
 
 static inline void flush_tlb_page(struct vm_area_struct *vma, unsigned long a)
 {
diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index 119765772ab11..47fb437acf52a 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -12,6 +12,7 @@
 #include <linux/task_work.h>
 #include <linux/mmu_notifier.h>
 #include <linux/mmu_context.h>
+#include <linux/context_tracking.h>
 
 #include <asm/tlbflush.h>
 #include <asm/mmu_context.h>
@@ -1042,6 +1043,11 @@ static void do_flush_tlb_all(void *info)
 	__flush_tlb_all();
 }
 
+static bool do_kernel_flush_defer_cond(int cpu, void *info)
+{
+	return !ct_set_cpu_work(cpu, CT_WORK_TLBI);
+}
+
 void flush_tlb_all(void)
 {
 	count_vm_tlb_event(NR_TLB_REMOTE_FLUSH);
@@ -1058,12 +1064,13 @@ static void do_kernel_range_flush(void *info)
 		flush_tlb_one_kernel(addr);
 }
 
-void flush_tlb_kernel_range(unsigned long start, unsigned long end)
+static inline void
+__flush_tlb_kernel_range(smp_cond_func_t cond_func, unsigned long start, unsigned long end)
 {
 	/* Balance as user space task's flush, a bit conservative */
 	if (end == TLB_FLUSH_ALL ||
 	    (end - start) > tlb_single_page_flush_ceiling << PAGE_SHIFT) {
-		on_each_cpu(do_flush_tlb_all, NULL, 1);
+		on_each_cpu_cond(cond_func, do_flush_tlb_all, NULL, 1);
 	} else {
 		struct flush_tlb_info *info;
 
@@ -1071,13 +1078,23 @@ void flush_tlb_kernel_range(unsigned long start, unsigned long end)
 		info = get_flush_tlb_info(NULL, start, end, 0, false,
 					  TLB_GENERATION_INVALID);
 
-		on_each_cpu(do_kernel_range_flush, info, 1);
+		on_each_cpu_cond(cond_func, do_kernel_range_flush, info, 1);
 
 		put_flush_tlb_info();
 		preempt_enable();
 	}
 }
 
+void flush_tlb_kernel_range(unsigned long start, unsigned long end)
+{
+	__flush_tlb_kernel_range(NULL, start, end);
+}
+
+void flush_tlb_kernel_range_deferrable(unsigned long start, unsigned long end)
+{
+	__flush_tlb_kernel_range(do_kernel_flush_defer_cond, start, end);
+}
+
 /*
  * This can be used from process context to figure out what the value of
  * CR3 is without needing to do a (slow) __read_cr3().
diff --git a/include/linux/context_tracking_work.h b/include/linux/context_tracking_work.h
index 931ade1dcbcc2..1be60c64cdeca 100644
--- a/include/linux/context_tracking_work.h
+++ b/include/linux/context_tracking_work.h
@@ -5,12 +5,14 @@
 #include <linux/bitops.h>
 
 enum {
-	CT_WORK_SYNC,
+	CT_WORK_SYNC_OFFSET,
+	CT_WORK_TLBI_OFFSET,
 	CT_WORK_MAX_OFFSET
 };
 
 enum ct_work {
 	CT_WORK_SYNC     = BIT(CT_WORK_SYNC_OFFSET),
+	CT_WORK_TLBI     = BIT(CT_WORK_TLBI_OFFSET),
 	CT_WORK_MAX      = BIT(CT_WORK_MAX_OFFSET)
 };
 
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 5c88d0e90c209..e8aad4d55e955 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -467,6 +467,31 @@ void vunmap_range_noflush(unsigned long start, unsigned long end)
 	__vunmap_range_noflush(start, end);
 }
 
+#ifdef CONFIG_CONTEXT_TRACKING_WORK
+/*
+ * !!! BIG FAT WARNING !!!
+ *
+ * The CPU is free to cache any part of the paging hierarchy it wants at any
+ * time. It's also free to set accessed and dirty bits at any time, even for
+ * instructions that may never execute architecturally.
+ *
+ * This means that deferring a TLB flush affecting freed page-table-pages (IOW,
+ * keeping them in a CPU's paging hierarchy cache) is akin to dancing in a
+ * minefield.
+ *
+ * This isn't a problem for deferral of TLB flushes in vmalloc, because
+ * page-table-pages used for vmap() mappings are never freed - see how
+ * __vunmap_range_noflush() walks the whole mapping but only clears the leaf PTEs.
+ * If this ever changes, TLB flush deferral will cause misery.
+ */
+void __weak flush_tlb_kernel_range_deferrable(unsigned long start, unsigned long end)
+{
+	flush_tlb_kernel_range(start, end);
+}
+#else
+#define flush_tlb_kernel_range_deferrable(start, end) flush_tlb_kernel_range(start, end)
+#endif
+
 /**
  * vunmap_range - unmap kernel virtual addresses
  * @addr: start of the VM area to unmap
@@ -480,7 +505,7 @@ void vunmap_range(unsigned long addr, unsigned long end)
 {
 	flush_cache_vunmap(addr, end);
 	vunmap_range_noflush(addr, end);
-	flush_tlb_kernel_range(addr, end);
+	flush_tlb_kernel_range_deferrable(addr, end);
 }
 
 static int vmap_pages_pte_range(pmd_t *pmd, unsigned long addr,
@@ -2281,7 +2306,7 @@ static bool __purge_vmap_area_lazy(unsigned long start, unsigned long end,
 
 	nr_purge_nodes = cpumask_weight(&purge_nodes);
 	if (nr_purge_nodes > 0) {
-		flush_tlb_kernel_range(start, end);
+		flush_tlb_kernel_range_deferrable(start, end);
 
 		/* One extra worker is per a lazy_max_pages() full set minus one. */
 		nr_purge_helpers = atomic_long_read(&vmap_lazy_nr) / lazy_max_pages();
@@ -2384,7 +2409,7 @@ static void free_unmap_vmap_area(struct vmap_area *va)
 	flush_cache_vunmap(va->va_start, va->va_end);
 	vunmap_range_noflush(va->va_start, va->va_end);
 	if (debug_pagealloc_enabled_static())
-		flush_tlb_kernel_range(va->va_start, va->va_end);
+		flush_tlb_kernel_range_deferrable(va->va_start, va->va_end);
 
 	free_vmap_area_noflush(va);
 }
@@ -2832,7 +2857,7 @@ static void vb_free(unsigned long addr, unsigned long size)
 	vunmap_range_noflush(addr, addr + size);
 
 	if (debug_pagealloc_enabled_static())
-		flush_tlb_kernel_range(addr, addr + size);
+		flush_tlb_kernel_range_deferrable(addr, addr + size);
 
 	spin_lock(&vb->lock);
 
@@ -2897,7 +2922,7 @@ static void _vm_unmap_aliases(unsigned long start, unsigned long end, int flush)
 	free_purged_blocks(&purge_list);
 
 	if (!__purge_vmap_area_lazy(start, end, false) && flush)
-		flush_tlb_kernel_range(start, end);
+		flush_tlb_kernel_range_deferrable(start, end);
 	mutex_unlock(&vmap_purge_lock);
 }
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 18:05:24 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 18:05:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871904.1282900 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlI3-00044m-SV; Tue, 14 Jan 2025 18:05:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871904.1282900; Tue, 14 Jan 2025 18:05:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlI3-00044d-Pq; Tue, 14 Jan 2025 18:05:23 +0000
Received: by outflank-mailman (input) for mailman id 871904;
 Tue, 14 Jan 2025 18:05: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
 <SRS0=5Qro=UG=redhat.com=vschneid@srs-se1.protection.inumbo.net>)
 id 1tXlI2-0002j5-Ka
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 18:05:22 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1e6dd968-d2a2-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 19:05:21 +0100 (CET)
Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-660-8ogZguOiNnCawOG8JxolMw-1; Tue,
 14 Jan 2025 13:05:15 -0500
Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id F0F9F1956050; Tue, 14 Jan 2025 18:05:11 +0000 (UTC)
Received: from vschneid-thinkpadt14sgen2i.remote.csb (unknown [10.39.192.55])
 by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix)
 with ESMTPS id DFA25195608A; Tue, 14 Jan 2025 18:04:49 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1e6dd968-d2a2-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1736877920;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=hBnzPr+bF01eZ/FcGt3b6YBzs+ceSVKdSHsMFlRMR5E=;
	b=T/Au40gFQxYBonlC4vGKMMsMz3qKg/AlgJUJ/VZiksPljqVurqVg1toKahXVWVejkSSFJL
	9Rp9eGuHVJgw3kjR0WX4Vh7FW1lec6QFV86KFWOb3xNyFuQtEUY9bWL12T9y/YwZw0bdoR
	f05IcEGSy05xRvh4+9egEa0aDcylGjk=
X-MC-Unique: 8ogZguOiNnCawOG8JxolMw-1
X-Mimecast-MFC-AGG-ID: 8ogZguOiNnCawOG8JxolMw
From: Valentin Schneider <vschneid@redhat.com>
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	virtualization@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	loongarch@lists.linux.dev,
	linux-riscv@lists.infradead.org,
	linux-perf-users@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	kvm@vger.kernel.org,
	linux-arch@vger.kernel.org,
	rcu@vger.kernel.org,
	linux-hardening@vger.kernel.org,
	linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org,
	bpf@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com
Cc: Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.amakhalov@broadcom.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andy Lutomirski <luto@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Clark Williams <williams@redhat.com>,
	Yair Podemsky <ypodemsk@redhat.com>,
	Tomas Glozar <tglozar@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>,
	Mel Gorman <mgorman@suse.de>,
	Kees Cook <kees@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Shuah Khan <shuah@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Alice Ryhl <aliceryhl@google.com>,
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
	Samuel Holland <samuel.holland@sifive.com>,
	Rong Xu <xur@google.com>,
	Nicolas Saenz Julienne <nsaenzju@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Yosry Ahmed <yosryahmed@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Jinghao Jia <jinghao7@illinois.edu>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: [PATCH v4 30/30] context-tracking: Add a Kconfig to enable IPI deferral for NO_HZ_IDLE
Date: Tue, 14 Jan 2025 18:51:43 +0100
Message-ID: <20250114175143.81438-31-vschneid@redhat.com>
In-Reply-To: <20250114175143.81438-1-vschneid@redhat.com>
References: <20250114175143.81438-1-vschneid@redhat.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15

With NO_HZ_IDLE, we get CONTEXT_TRACKING_IDLE, so we get these
transitions:

  ct_idle_enter()
    ct_kernel_exit()
      ct_state_inc_clear_work()

  ct_idle_exit()
    ct_kernel_enter()
      ct_work_flush()

With just CONTEXT_TRACKING_IDLE, ct_state_inc_clear_work() is just
ct_state_inc() and ct_work_flush() is a no-op. However, making them be
functional as if under CONTEXT_TRACKING_WORK would allow NO_HZ_IDLE to
leverage IPI deferral to keep idle CPUs idle longer.

Having this enabled for NO_HZ_IDLE is a different argument than for having
it for NO_HZ_FULL (power savings vs latency/performance), but the backing
mechanism is identical.

Add a default-no option to enable IPI deferral with NO_HZ_IDLE.

Signed-off-by: Valentin Schneider <vschneid@redhat.com>
---
 kernel/time/Kconfig | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/kernel/time/Kconfig b/kernel/time/Kconfig
index 7e8106a0d981f..c7398fe5382a0 100644
--- a/kernel/time/Kconfig
+++ b/kernel/time/Kconfig
@@ -183,9 +183,23 @@ config CONTEXT_TRACKING_USER_FORCE
 
 config CONTEXT_TRACKING_WORK
 	bool
-	depends on HAVE_CONTEXT_TRACKING_WORK && CONTEXT_TRACKING_USER
+	depends on HAVE_CONTEXT_TRACKING_WORK && (CONTEXT_TRACKING_USER || CONTEXT_TRACKING_WORK_IDLE)
 	default y
 
+config CONTEXT_TRACKING_WORK_IDLE
+       bool
+       depends on HAVE_CONTEXT_TRACKING_WORK && CONTEXT_TRACKING_IDLE && !CONTEXT_TRACKING_USER
+       default n
+       help
+	 This option enables deferral of some IPIs when they are targeted at CPUs
+	 that are idle. This can help keep CPUs idle longer, but induces some
+	 extra overhead to idle <-> kernel transitions and to IPI sending.
+
+	 Say Y if the power improvements are worth more to you than the added
+	 overheads.
+
+	 Say N otherwise.
+
 config NO_HZ
 	bool "Old Idle dynticks config"
 	help
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 18:11:34 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 18:11:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871919.1282909 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlNw-000637-JO; Tue, 14 Jan 2025 18:11:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871919.1282909; Tue, 14 Jan 2025 18:11:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlNw-000630-Gw; Tue, 14 Jan 2025 18:11:28 +0000
Received: by outflank-mailman (input) for mailman id 871919;
 Tue, 14 Jan 2025 18:11:26 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=5Qro=UG=redhat.com=vschneid@srs-se1.protection.inumbo.net>)
 id 1tXlFP-0004pK-LX
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 18:02:39 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.129.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bd7c1816-d2a1-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 19:02:39 +0100 (CET)
Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-125-79n9fhnhPJ65-rfaOeT4Rg-1; Tue,
 14 Jan 2025 13:02:34 -0500
Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 69EBE19560AA; Tue, 14 Jan 2025 18:02:31 +0000 (UTC)
Received: from vschneid-thinkpadt14sgen2i.remote.csb (unknown [10.39.192.55])
 by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix)
 with ESMTPS id 60C94195608A; Tue, 14 Jan 2025 18:02:09 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: bd7c1816-d2a1-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1736877758;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=vO7Dcae3S+ckJLBtr7bo/IIVyHg02LNyvWNatP3bxFA=;
	b=J0SSJxTCxKRkZ/S/2VWkd1V2bL1JUlWAErlQkwH28yPYoEFvZ16g6s/lgaN8mWZZ6wJqZ1
	qLIhPppnJftNW9e2g3SbTn492NKdm1a00pBM0KZKVU9ilfMUPrac3LCkJrWxmyhKXtIEoq
	HxLlE5sNM6zOSACJ+SF7h/+T00QPb3s=
X-MC-Unique: 79n9fhnhPJ65-rfaOeT4Rg-1
X-Mimecast-MFC-AGG-ID: 79n9fhnhPJ65-rfaOeT4Rg
From: Valentin Schneider <vschneid@redhat.com>
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	virtualization@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	loongarch@lists.linux.dev,
	linux-riscv@lists.infradead.org,
	linux-perf-users@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	kvm@vger.kernel.org,
	linux-arch@vger.kernel.org,
	rcu@vger.kernel.org,
	linux-hardening@vger.kernel.org,
	linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org,
	bpf@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com
Cc: Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.amakhalov@broadcom.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andy Lutomirski <luto@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Clark Williams <williams@redhat.com>,
	Yair Podemsky <ypodemsk@redhat.com>,
	Tomas Glozar <tglozar@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>,
	Mel Gorman <mgorman@suse.de>,
	Kees Cook <kees@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Shuah Khan <shuah@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Alice Ryhl <aliceryhl@google.com>,
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
	Samuel Holland <samuel.holland@sifive.com>,
	Rong Xu <xur@google.com>,
	Nicolas Saenz Julienne <nsaenzju@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Yosry Ahmed <yosryahmed@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Jinghao Jia <jinghao7@illinois.edu>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: [PATCH v4 23/30] context_tracking: Turn CT_STATE_* into bits
Date: Tue, 14 Jan 2025 18:51:36 +0100
Message-ID: <20250114175143.81438-24-vschneid@redhat.com>
In-Reply-To: <20250114175143.81438-1-vschneid@redhat.com>
References: <20250114175143.81438-1-vschneid@redhat.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15

A later patch will require to easily exclude CT_STATE_KERNEL from a genuine
a ct->state read CT_STATE_KERNEL, which requires that value being non-zero
and exclusive with the other CT_STATE_* values.

This increases the size of the CT_STATE region of the ct->state variable by
two bits.

Signed-off-by: Valentin Schneider <vschneid@redhat.com>
---
 include/linux/context_tracking_state.h | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/linux/context_tracking_state.h b/include/linux/context_tracking_state.h
index 0b81248aa03e2..eb2149b20baef 100644
--- a/include/linux/context_tracking_state.h
+++ b/include/linux/context_tracking_state.h
@@ -11,11 +11,11 @@
 
 enum ctx_state {
 	CT_STATE_DISABLED	= -1,	/* returned by ct_state() if unknown */
-	CT_STATE_KERNEL		= 0,
-	CT_STATE_IDLE		= 1,
-	CT_STATE_USER		= 2,
-	CT_STATE_GUEST		= 3,
-	CT_STATE_MAX		= 4,
+	CT_STATE_KERNEL		= 1,
+	CT_STATE_IDLE		= 2,
+	CT_STATE_USER		= 4,
+	CT_STATE_GUEST		= 8,
+	CT_STATE_MAX		= 9,
 };
 
 struct context_tracking {
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 18:13:46 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 18:13:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871928.1282920 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlQA-00079d-0C; Tue, 14 Jan 2025 18:13:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871928.1282920; Tue, 14 Jan 2025 18:13:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlQ9-00079W-Sp; Tue, 14 Jan 2025 18:13:45 +0000
Received: by outflank-mailman (input) for mailman id 871928;
 Tue, 14 Jan 2025 18:13: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
 <SRS0=5Qro=UG=redhat.com=vschneid@srs-se1.protection.inumbo.net>)
 id 1tXlG8-0004pK-0N
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 18:03:24 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.129.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d79492b2-d2a1-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 19:03:22 +0100 (CET)
Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-25-Kq2Q4fXhOu2lJRR6wkpJZw-1; Tue,
 14 Jan 2025 13:03:20 -0500
Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id A57A91956054; Tue, 14 Jan 2025 18:03:16 +0000 (UTC)
Received: from vschneid-thinkpadt14sgen2i.remote.csb (unknown [10.39.192.55])
 by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix)
 with ESMTPS id 5C6D619560B7; Tue, 14 Jan 2025 18:02:54 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: d79492b2-d2a1-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1736877801;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=gOYbvMechf4Tk3QrOwIKHHFKhIz7g8W0C2CEkfk0nCI=;
	b=IGXT1+kRC8bpT6C1YhEFAU2/gBjuGYVCILc36df0WEKPJgz+A/IV9z52g/95hruNV/O0cc
	InzOlC9xePFIi3Phg3L8Q6iL/oC1vGQJ+84qGBjq9JGFCOP798ko3FnDMo6DFbW/6d6IUW
	WgnMM8iRzD3LQmq/MS8oAbBuJIzMcy4=
X-MC-Unique: Kq2Q4fXhOu2lJRR6wkpJZw-1
X-Mimecast-MFC-AGG-ID: Kq2Q4fXhOu2lJRR6wkpJZw
From: Valentin Schneider <vschneid@redhat.com>
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	virtualization@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	loongarch@lists.linux.dev,
	linux-riscv@lists.infradead.org,
	linux-perf-users@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	kvm@vger.kernel.org,
	linux-arch@vger.kernel.org,
	rcu@vger.kernel.org,
	linux-hardening@vger.kernel.org,
	linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org,
	bpf@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com
Cc: Peter Zijlstra <peterz@infradead.org>,
	Nicolas Saenz Julienne <nsaenzju@redhat.com>,
	Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.amakhalov@broadcom.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andy Lutomirski <luto@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Clark Williams <williams@redhat.com>,
	Yair Podemsky <ypodemsk@redhat.com>,
	Tomas Glozar <tglozar@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>,
	Mel Gorman <mgorman@suse.de>,
	Kees Cook <kees@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Shuah Khan <shuah@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Alice Ryhl <aliceryhl@google.com>,
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
	Samuel Holland <samuel.holland@sifive.com>,
	Rong Xu <xur@google.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Yosry Ahmed <yosryahmed@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Jinghao Jia <jinghao7@illinois.edu>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: [PATCH v4 25/30] context_tracking,x86: Defer kernel text patching IPIs
Date: Tue, 14 Jan 2025 18:51:38 +0100
Message-ID: <20250114175143.81438-26-vschneid@redhat.com>
In-Reply-To: <20250114175143.81438-1-vschneid@redhat.com>
References: <20250114175143.81438-1-vschneid@redhat.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15

text_poke_bp_batch() sends IPIs to all online CPUs to synchronize
them vs the newly patched instruction. CPUs that are executing in userspace
do not need this synchronization to happen immediately, and this is
actually harmful interference for NOHZ_FULL CPUs.

As the synchronization IPIs are sent using a blocking call, returning from
text_poke_bp_batch() implies all CPUs will observe the patched
instruction(s), and this should be preserved even if the IPI is deferred.
In other words, to safely defer this synchronization, any kernel
instruction leading to the execution of the deferred instruction
sync (ct_work_flush()) must *not* be mutable (patchable) at runtime.

This means we must pay attention to mutable instructions in the early entry
code:
- alternatives
- static keys
- static calls
- all sorts of probes (kprobes/ftrace/bpf/???)

The early entry code leading to ct_work_flush() is noinstr, which gets rid
of the probes.

Alternatives are safe, because it's boot-time patching (before SMP is
even brought up) which is before any IPI deferral can happen.

This leaves us with static keys and static calls.

Any static key used in early entry code should be only forever-enabled at
boot time, IOW __ro_after_init (pretty much like alternatives). Exceptions
are explicitly marked as allowed in .noinstr and will always generate an
IPI when flipped.

The same applies to static calls - they should be only updated at boot
time, or manually marked as an exception.

Objtool is now able to point at static keys/calls that don't respect this,
and all static keys/calls used in early entry code have now been verified
as behaving appropriately.

Leverage the new context_tracking infrastructure to defer sync_core() IPIs
to a target CPU's next kernel entry.

Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Nicolas Saenz Julienne <nsaenzju@redhat.com>
Signed-off-by: Valentin Schneider <vschneid@redhat.com>
---
 arch/x86/include/asm/context_tracking_work.h |  6 ++--
 arch/x86/include/asm/text-patching.h         |  1 +
 arch/x86/kernel/alternative.c                | 38 ++++++++++++++++----
 arch/x86/kernel/kprobes/core.c               |  4 +--
 arch/x86/kernel/kprobes/opt.c                |  4 +--
 arch/x86/kernel/module.c                     |  2 +-
 include/asm-generic/sections.h               | 15 ++++++++
 include/linux/context_tracking_work.h        |  4 +--
 8 files changed, 59 insertions(+), 15 deletions(-)

diff --git a/arch/x86/include/asm/context_tracking_work.h b/arch/x86/include/asm/context_tracking_work.h
index 5f3b2d0977235..485b32881fde5 100644
--- a/arch/x86/include/asm/context_tracking_work.h
+++ b/arch/x86/include/asm/context_tracking_work.h
@@ -2,11 +2,13 @@
 #ifndef _ASM_X86_CONTEXT_TRACKING_WORK_H
 #define _ASM_X86_CONTEXT_TRACKING_WORK_H
 
+#include <asm/sync_core.h>
+
 static __always_inline void arch_context_tracking_work(enum ct_work work)
 {
 	switch (work) {
-	case CT_WORK_n:
-		// Do work...
+	case CT_WORK_SYNC:
+		sync_core();
 		break;
 	case CT_WORK_MAX:
 		WARN_ON_ONCE(true);
diff --git a/arch/x86/include/asm/text-patching.h b/arch/x86/include/asm/text-patching.h
index ab9e143ec9fea..9dfa46f721c1d 100644
--- a/arch/x86/include/asm/text-patching.h
+++ b/arch/x86/include/asm/text-patching.h
@@ -33,6 +33,7 @@ extern void apply_relocation(u8 *buf, const u8 * const instr, size_t instrlen, u
  */
 extern void *text_poke(void *addr, const void *opcode, size_t len);
 extern void text_poke_sync(void);
+extern void text_poke_sync_deferrable(void);
 extern void *text_poke_kgdb(void *addr, const void *opcode, size_t len);
 extern void *text_poke_copy(void *addr, const void *opcode, size_t len);
 #define text_poke_copy text_poke_copy
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index 243843e44e89d..633deea8a89cb 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -18,6 +18,7 @@
 #include <linux/mmu_context.h>
 #include <linux/bsearch.h>
 #include <linux/sync_core.h>
+#include <linux/context_tracking.h>
 #include <asm/text-patching.h>
 #include <asm/alternative.h>
 #include <asm/sections.h>
@@ -2109,9 +2110,24 @@ static void do_sync_core(void *info)
 	sync_core();
 }
 
+static bool do_sync_core_defer_cond(int cpu, void *info)
+{
+	return !ct_set_cpu_work(cpu, CT_WORK_SYNC);
+}
+
+static void __text_poke_sync(smp_cond_func_t cond_func)
+{
+	on_each_cpu_cond(cond_func, do_sync_core, NULL, 1);
+}
+
 void text_poke_sync(void)
 {
-	on_each_cpu(do_sync_core, NULL, 1);
+	__text_poke_sync(NULL);
+}
+
+void text_poke_sync_deferrable(void)
+{
+	__text_poke_sync(do_sync_core_defer_cond);
 }
 
 /*
@@ -2282,6 +2298,7 @@ static int tp_vec_nr;
  */
 static void text_poke_bp_batch(struct text_poke_loc *tp, unsigned int nr_entries)
 {
+	smp_cond_func_t cond = do_sync_core_defer_cond;
 	unsigned char int3 = INT3_INSN_OPCODE;
 	unsigned int i;
 	int do_sync;
@@ -2317,11 +2334,20 @@ static void text_poke_bp_batch(struct text_poke_loc *tp, unsigned int nr_entries
 	 * First step: add a int3 trap to the address that will be patched.
 	 */
 	for (i = 0; i < nr_entries; i++) {
-		tp[i].old = *(u8 *)text_poke_addr(&tp[i]);
-		text_poke(text_poke_addr(&tp[i]), &int3, INT3_INSN_SIZE);
+		void *addr = text_poke_addr(&tp[i]);
+
+		/*
+		 * There's no safe way to defer IPIs for patching text in
+		 * .noinstr, record whether there is at least one such poke.
+		 */
+		if (is_kernel_noinstr_text((unsigned long)addr))
+			cond = NULL;
+
+		tp[i].old = *((u8 *)addr);
+		text_poke(addr, &int3, INT3_INSN_SIZE);
 	}
 
-	text_poke_sync();
+	__text_poke_sync(cond);
 
 	/*
 	 * Second step: update all but the first byte of the patched range.
@@ -2383,7 +2409,7 @@ static void text_poke_bp_batch(struct text_poke_loc *tp, unsigned int nr_entries
 		 * not necessary and we'd be safe even without it. But
 		 * better safe than sorry (plus there's not only Intel).
 		 */
-		text_poke_sync();
+		__text_poke_sync(cond);
 	}
 
 	/*
@@ -2404,7 +2430,7 @@ static void text_poke_bp_batch(struct text_poke_loc *tp, unsigned int nr_entries
 	}
 
 	if (do_sync)
-		text_poke_sync();
+		__text_poke_sync(cond);
 
 	/*
 	 * Remove and wait for refs to be zero.
diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
index 72e6a45e7ec24..c2fd2578fd5fc 100644
--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -817,7 +817,7 @@ void arch_arm_kprobe(struct kprobe *p)
 	u8 int3 = INT3_INSN_OPCODE;
 
 	text_poke(p->addr, &int3, 1);
-	text_poke_sync();
+	text_poke_sync_deferrable();
 	perf_event_text_poke(p->addr, &p->opcode, 1, &int3, 1);
 }
 
@@ -827,7 +827,7 @@ void arch_disarm_kprobe(struct kprobe *p)
 
 	perf_event_text_poke(p->addr, &int3, 1, &p->opcode, 1);
 	text_poke(p->addr, &p->opcode, 1);
-	text_poke_sync();
+	text_poke_sync_deferrable();
 }
 
 void arch_remove_kprobe(struct kprobe *p)
diff --git a/arch/x86/kernel/kprobes/opt.c b/arch/x86/kernel/kprobes/opt.c
index 36d6809c6c9e1..b2ce4d9c3ba56 100644
--- a/arch/x86/kernel/kprobes/opt.c
+++ b/arch/x86/kernel/kprobes/opt.c
@@ -513,11 +513,11 @@ void arch_unoptimize_kprobe(struct optimized_kprobe *op)
 	       JMP32_INSN_SIZE - INT3_INSN_SIZE);
 
 	text_poke(addr, new, INT3_INSN_SIZE);
-	text_poke_sync();
+	text_poke_sync_deferrable();
 	text_poke(addr + INT3_INSN_SIZE,
 		  new + INT3_INSN_SIZE,
 		  JMP32_INSN_SIZE - INT3_INSN_SIZE);
-	text_poke_sync();
+	text_poke_sync_deferrable();
 
 	perf_event_text_poke(op->kp.addr, old, JMP32_INSN_SIZE, new, JMP32_INSN_SIZE);
 }
diff --git a/arch/x86/kernel/module.c b/arch/x86/kernel/module.c
index 8984abd91c001..acc810150b76c 100644
--- a/arch/x86/kernel/module.c
+++ b/arch/x86/kernel/module.c
@@ -194,7 +194,7 @@ static int write_relocate_add(Elf64_Shdr *sechdrs,
 				   write, apply);
 
 	if (!early) {
-		text_poke_sync();
+		text_poke_sync_deferrable();
 		mutex_unlock(&text_mutex);
 	}
 
diff --git a/include/asm-generic/sections.h b/include/asm-generic/sections.h
index c768de6f19a9a..1b3ba3084fd2f 100644
--- a/include/asm-generic/sections.h
+++ b/include/asm-generic/sections.h
@@ -199,6 +199,21 @@ static inline bool is_kernel_inittext(unsigned long addr)
 	       addr < (unsigned long)_einittext;
 }
 
+
+/**
+ * is_kernel_noinstr_text - checks if the pointer address is located in the
+ *                    .noinstr section
+ *
+ * @addr: address to check
+ *
+ * Returns: true if the address is located in .noinstr, false otherwise.
+ */
+static inline bool is_kernel_noinstr_text(unsigned long addr)
+{
+	return addr >= (unsigned long)__noinstr_text_start &&
+	       addr < (unsigned long)__noinstr_text_end;
+}
+
 /**
  * __is_kernel_text - checks if the pointer address is located in the
  *                    .text section
diff --git a/include/linux/context_tracking_work.h b/include/linux/context_tracking_work.h
index c68245f8d77c5..931ade1dcbcc2 100644
--- a/include/linux/context_tracking_work.h
+++ b/include/linux/context_tracking_work.h
@@ -5,12 +5,12 @@
 #include <linux/bitops.h>
 
 enum {
-	CT_WORK_n_OFFSET,
+	CT_WORK_SYNC,
 	CT_WORK_MAX_OFFSET
 };
 
 enum ct_work {
-	CT_WORK_n        = BIT(CT_WORK_n_OFFSET),
+	CT_WORK_SYNC     = BIT(CT_WORK_SYNC_OFFSET),
 	CT_WORK_MAX      = BIT(CT_WORK_MAX_OFFSET)
 };
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 18:17:28 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 18:17:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871941.1282929 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlTg-00009S-E8; Tue, 14 Jan 2025 18:17:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871941.1282929; Tue, 14 Jan 2025 18:17:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlTg-00009L-Bb; Tue, 14 Jan 2025 18:17:24 +0000
Received: by outflank-mailman (input) for mailman id 871941;
 Tue, 14 Jan 2025 18:17:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=yccS=UG=google.com=jannh@srs-se1.protection.inumbo.net>)
 id 1tXlTf-00009F-Jb
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 18:17:23 +0000
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com
 [2a00:1450:4864:20::52d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id cbf8ccbe-d2a3-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 19:17:21 +0100 (CET)
Received: by mail-ed1-x52d.google.com with SMTP id
 4fb4d7f45d1cf-5d3e638e1b4so8517a12.1
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 10:17:21 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: cbf8ccbe-d2a3-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20230601; t=1736878641; x=1737483441; 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=I0aYHuk99JA9dU0puEhTqa+Ivu5XtOv7dOMzqH0MLLU=;
        b=BIde5BjQRjl9MFLHci8sFoYtjcxRrQegPbbNYqo5v16Coo4X0ZV4wC8vOjlo+guQUP
         HAycaWUUlUWUEYBrl48xF4gdaPOOpytha8ipxhEFuDTDllm/m9ZlAppy+PjQfw/yM2nU
         9K2/qQmIUWKlqjWDytYCmuPT1IE9fH/mCfRnjykR/BSv9+lFrkbCokDeCXA8RQ7Qy5PS
         acjmEQbYKDvt7n1AItp8XQhhEI+Pg4qWwPND0z3NZ0edup9YMBTKJXzpfqR+eVdniq6e
         HyTXD7iA36V8wc2NEA3BSz0RjfLreNvIccQ9sLorM/2QovxxEkieiNTfBeQ095cDgMWf
         Dv0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736878641; x=1737483441;
        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=I0aYHuk99JA9dU0puEhTqa+Ivu5XtOv7dOMzqH0MLLU=;
        b=T4Qm3SZ2/BdVJ8MGozqTFrZsG1FkhFyWlHQ2UWL0SkbsPS6UtcvghoQlmfm5x2iUzD
         s0CWPz/wYCXGBBApqWST8GW7M7a1fp18hmakilfS1fCyNkDVyMJ5HE1XtJu+Xn9ix+bK
         f8oLipoGEIEsN3cQPdImXZAsW0+ricFEYWCTWcQvh5tEAmEE8rtolmxxq3++dJgQAdVm
         2gQ5UUojpvLr87vueyW15EOPQHYBhC87sOs/GMuAy3kJlzlLnbaF+VpWTmiy/i/fnEDw
         SE5ZbD2QoVWXAass9S31YaJRS/gePD/i90JneL9w8tpTIN9sYDh09lBj6VAmxAFmv5RQ
         hyOQ==
X-Forwarded-Encrypted: i=1; AJvYcCXPraFji+G0QpKtO77paZ+pYTgNxMxWwCV3idYOGhNn+jmbZvTHPoeG/cs3JRwZeRUkygpBsZ0xuu0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzN04KlMM+DyoteHkKchstE6ICXg5zbozIow8T/E4UaVBQwjRlU
	pK24t+oSAwdEwwuU+VSjhr5tA0lD+HtylJQ3ERsPr6/+NkzH5S8jVE5WeRtWZR+AltFk/1CvB9p
	Yo5N7F30/uwJeaJoxMoU3kfuOIF/OE6XsZ7Zi
X-Gm-Gg: ASbGncua5UqDH5LTtar/juhw3uMJE+PAjKuTfN/3iy9EOALljh2+K2dUqqwm0O1ffjL
	4E4K7D0Xe2kI+6wwywv+NtfVUZI9WNtt3qWuj458M/BOjUUd6GL+G5Mc9x/Xfxbh0tg==
X-Google-Smtp-Source: AGHT+IFOWOuSvDhgzEqoKb2CNkVmA/sXHofQ9hZDfWF+l4vbbQk0RN2k51cQSZIijLzKAw1RUyxlH5Nb9O1wedqOjko=
X-Received: by 2002:a50:d4d2:0:b0:5d1:22e1:7458 with SMTP id
 4fb4d7f45d1cf-5d9f695dda7mr124694a12.4.1736878640478; Tue, 14 Jan 2025
 10:17:20 -0800 (PST)
MIME-Version: 1.0
References: <20250114175143.81438-1-vschneid@redhat.com> <20250114175143.81438-30-vschneid@redhat.com>
In-Reply-To: <20250114175143.81438-30-vschneid@redhat.com>
From: Jann Horn <jannh@google.com>
Date: Tue, 14 Jan 2025 19:16:44 +0100
X-Gm-Features: AbW1kvY7dNxOnvBqE7JSPz560QoJfBjiwfsZgS18MpZMQ07ZRC1TBr6Zwl5A-60
Message-ID: <CAG48ez1Mh+DOy0ysOo7Qioxh1W7xWQyK9CLGNU9TGOsLXbg=gQ@mail.gmail.com>
Subject: Re: [PATCH v4 29/30] x86/mm, mm/vmalloc: Defer flush_tlb_kernel_range()
 targeting NOHZ_FULL CPUs
To: Valentin Schneider <vschneid@redhat.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org, 
	virtualization@lists.linux.dev, linux-arm-kernel@lists.infradead.org, 
	loongarch@lists.linux.dev, linux-riscv@lists.infradead.org, 
	linux-perf-users@vger.kernel.org, xen-devel@lists.xenproject.org, 
	kvm@vger.kernel.org, linux-arch@vger.kernel.org, rcu@vger.kernel.org, 
	linux-hardening@vger.kernel.org, linux-mm@kvack.org, 
	linux-kselftest@vger.kernel.org, bpf@vger.kernel.org, 
	bcm-kernel-feedback-list@broadcom.com, Juergen Gross <jgross@suse.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.amakhalov@broadcom.com>, 
	Russell King <linux@armlinux.org.uk>, Catalin Marinas <catalin.marinas@arm.com>, 
	Will Deacon <will@kernel.org>, Huacai Chen <chenhuacai@kernel.org>, WANG Xuerui <kernel@xen0n.name>, 
	Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, 
	Albert Ou <aou@eecs.berkeley.edu>, Thomas Gleixner <tglx@linutronix.de>, 
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, 
	Dave Hansen <dave.hansen@linux.intel.com>, "H. Peter Anvin" <hpa@zytor.com>, 
	Peter Zijlstra <peterz@infradead.org>, Arnaldo Carvalho de Melo <acme@kernel.org>, 
	Namhyung Kim <namhyung@kernel.org>, Mark Rutland <mark.rutland@arm.com>, 
	Alexander Shishkin <alexander.shishkin@linux.intel.com>, Jiri Olsa <jolsa@kernel.org>, 
	Ian Rogers <irogers@google.com>, Adrian Hunter <adrian.hunter@intel.com>, 
	"Liang, Kan" <kan.liang@linux.intel.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>, 
	Josh Poimboeuf <jpoimboe@kernel.org>, Pawan Gupta <pawan.kumar.gupta@linux.intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	Andy Lutomirski <luto@kernel.org>, Arnd Bergmann <arnd@arndb.de>, 
	Frederic Weisbecker <frederic@kernel.org>, "Paul E. McKenney" <paulmck@kernel.org>, 
	Jason Baron <jbaron@akamai.com>, Steven Rostedt <rostedt@goodmis.org>, 
	Ard Biesheuvel <ardb@kernel.org>, Neeraj Upadhyay <neeraj.upadhyay@kernel.org>, 
	Joel Fernandes <joel@joelfernandes.org>, Josh Triplett <josh@joshtriplett.org>, 
	Boqun Feng <boqun.feng@gmail.com>, Uladzislau Rezki <urezki@gmail.com>, 
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>, Lai Jiangshan <jiangshanlai@gmail.com>, 
	Zqiang <qiang.zhang1211@gmail.com>, Juri Lelli <juri.lelli@redhat.com>, 
	Clark Williams <williams@redhat.com>, Yair Podemsky <ypodemsk@redhat.com>, 
	Tomas Glozar <tglozar@redhat.com>, Vincent Guittot <vincent.guittot@linaro.org>, 
	Dietmar Eggemann <dietmar.eggemann@arm.com>, Ben Segall <bsegall@google.com>, 
	Mel Gorman <mgorman@suse.de>, Kees Cook <kees@kernel.org>, 
	Andrew Morton <akpm@linux-foundation.org>, Christoph Hellwig <hch@infradead.org>, 
	Shuah Khan <shuah@kernel.org>, Sami Tolvanen <samitolvanen@google.com>, 
	Miguel Ojeda <ojeda@kernel.org>, Alice Ryhl <aliceryhl@google.com>, 
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>, Samuel Holland <samuel.holland@sifive.com>, Rong Xu <xur@google.com>, 
	Nicolas Saenz Julienne <nsaenzju@redhat.com>, Geert Uytterhoeven <geert@linux-m68k.org>, 
	Yosry Ahmed <yosryahmed@google.com>, 
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>, 
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>, Jinghao Jia <jinghao7@illinois.edu>, 
	Luis Chamberlain <mcgrof@kernel.org>, Randy Dunlap <rdunlap@infradead.org>, 
	Tiezhu Yang <yangtiezhu@loongson.cn>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 14, 2025 at 6:51=E2=80=AFPM Valentin Schneider <vschneid@redhat=
.com> wrote:
> vunmap()'s issued from housekeeping CPUs are a relatively common source o=
f
> interference for isolated NOHZ_FULL CPUs, as they are hit by the
> flush_tlb_kernel_range() IPIs.
>
> Given that CPUs executing in userspace do not access data in the vmalloc
> range, these IPIs could be deferred until their next kernel entry.
>
> Deferral vs early entry danger zone
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> This requires a guarantee that nothing in the vmalloc range can be vunmap=
'd
> and then accessed in early entry code.

In other words, it needs a guarantee that no vmalloc allocations that
have been created in the vmalloc region while the CPU was idle can
then be accessed during early entry, right?


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 18:29:00 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 18:29:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871967.1282940 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXleo-0005yS-JO; Tue, 14 Jan 2025 18:28:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871967.1282940; Tue, 14 Jan 2025 18:28:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXleo-0005yL-GW; Tue, 14 Jan 2025 18:28:54 +0000
Received: by outflank-mailman (input) for mailman id 871967;
 Tue, 14 Jan 2025 18:28:52 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=5Qro=UG=redhat.com=vschneid@srs-se1.protection.inumbo.net>)
 id 1tXlFp-0007Qx-Hd
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 18:03:05 +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 cc15048a-d2a1-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 19:03:03 +0100 (CET)
Received: from mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-557-hmcuI36TM9u3E6tRKSsWWQ-1; Tue,
 14 Jan 2025 13:02:57 -0500
Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id DD5C41955DD7; Tue, 14 Jan 2025 18:02:53 +0000 (UTC)
Received: from vschneid-thinkpadt14sgen2i.remote.csb (unknown [10.39.192.55])
 by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix)
 with ESMTPS id DE7CA19560AB; Tue, 14 Jan 2025 18:02:31 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: cc15048a-d2a1-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1736877782;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=cj0SVgwm0Gb22+xO5luDoQDcDRqoe4OsVd+MUCyw+y0=;
	b=VbTwmz+HwkNgRJRkL9nt5UDlB0xEJzt5kNipIfJm7CLiLtJHrz5FaNY59sL8cbUqCyiNeo
	UQYXQeGqBz8m0UxtSkPXJje/djcsKsnm7c2JjPoGhI2bQXXxmz+bNCvy3aNAa9et53HHnb
	rBk9uxVSFFcVVcs2lcIWTe/EoZ0iEA0=
X-MC-Unique: hmcuI36TM9u3E6tRKSsWWQ-1
X-Mimecast-MFC-AGG-ID: hmcuI36TM9u3E6tRKSsWWQ
From: Valentin Schneider <vschneid@redhat.com>
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	virtualization@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	loongarch@lists.linux.dev,
	linux-riscv@lists.infradead.org,
	linux-perf-users@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	kvm@vger.kernel.org,
	linux-arch@vger.kernel.org,
	rcu@vger.kernel.org,
	linux-hardening@vger.kernel.org,
	linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org,
	bpf@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com
Cc: Nicolas Saenz Julienne <nsaenzju@redhat.com>,
	Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.amakhalov@broadcom.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andy Lutomirski <luto@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Clark Williams <williams@redhat.com>,
	Yair Podemsky <ypodemsk@redhat.com>,
	Tomas Glozar <tglozar@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>,
	Mel Gorman <mgorman@suse.de>,
	Kees Cook <kees@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Shuah Khan <shuah@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Alice Ryhl <aliceryhl@google.com>,
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
	Samuel Holland <samuel.holland@sifive.com>,
	Rong Xu <xur@google.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Yosry Ahmed <yosryahmed@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Jinghao Jia <jinghao7@illinois.edu>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: [PATCH v4 24/30] context-tracking: Introduce work deferral infrastructure
Date: Tue, 14 Jan 2025 18:51:37 +0100
Message-ID: <20250114175143.81438-25-vschneid@redhat.com>
In-Reply-To: <20250114175143.81438-1-vschneid@redhat.com>
References: <20250114175143.81438-1-vschneid@redhat.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15

smp_call_function() & friends have the unfortunate habit of sending IPIs to
isolated, NOHZ_FULL, in-userspace CPUs, as they blindly target all online
CPUs.

Some callsites can be bent into doing the right, such as done by commit:

  cc9e303c91f5 ("x86/cpu: Disable frequency requests via aperfmperf IPI for nohz_full CPUs")

Unfortunately, not all SMP callbacks can be omitted in this
fashion. However, some of them only affect execution in kernelspace, which
means they don't have to be executed *immediately* if the target CPU is in
userspace: stashing the callback and executing it upon the next kernel entry
would suffice. x86 kernel instruction patching or kernel TLB invalidation
are prime examples of it.

Reduce the RCU dynticks counter width to free up some bits to be used as a
deferred callback bitmask. Add some build-time checks to validate that
setup.

Presence of CT_STATE_KERNEL in the ct_state prevents queuing deferred work.

Later commits introduce the bit:callback mappings.

Link: https://lore.kernel.org/all/20210929151723.162004989@infradead.org/
Signed-off-by: Nicolas Saenz Julienne <nsaenzju@redhat.com>
Signed-off-by: Valentin Schneider <vschneid@redhat.com>
---
 arch/Kconfig                                 |  9 +++
 arch/x86/Kconfig                             |  1 +
 arch/x86/include/asm/context_tracking_work.h | 16 +++++
 include/linux/context_tracking.h             | 21 +++++++
 include/linux/context_tracking_state.h       | 30 ++++++---
 include/linux/context_tracking_work.h        | 26 ++++++++
 kernel/context_tracking.c                    | 66 +++++++++++++++++++-
 kernel/time/Kconfig                          |  5 ++
 8 files changed, 162 insertions(+), 12 deletions(-)
 create mode 100644 arch/x86/include/asm/context_tracking_work.h
 create mode 100644 include/linux/context_tracking_work.h

diff --git a/arch/Kconfig b/arch/Kconfig
index 6682b2a53e342..b637f20f0fc68 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -952,6 +952,15 @@ config HAVE_CONTEXT_TRACKING_USER_OFFSTACK
 	  - No use of instrumentation, unless instrumentation_begin() got
 	    called.
 
+config HAVE_CONTEXT_TRACKING_WORK
+	bool
+	help
+	  Architecture supports deferring work while not in kernel context.
+	  This is especially useful on setups with isolated CPUs that might
+	  want to avoid being interrupted to perform housekeeping tasks (for
+	  ex. TLB invalidation or icache invalidation). The housekeeping
+	  operations are performed upon re-entering the kernel.
+
 config HAVE_TIF_NOHZ
 	bool
 	help
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 9d7bd0ae48c42..ca5dd4cfc354b 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -216,6 +216,7 @@ config X86
 	select HAVE_CMPXCHG_LOCAL
 	select HAVE_CONTEXT_TRACKING_USER		if X86_64
 	select HAVE_CONTEXT_TRACKING_USER_OFFSTACK	if HAVE_CONTEXT_TRACKING_USER
+	select HAVE_CONTEXT_TRACKING_WORK		if X86_64
 	select HAVE_C_RECORDMCOUNT
 	select HAVE_OBJTOOL_MCOUNT		if HAVE_OBJTOOL
 	select HAVE_OBJTOOL_NOP_MCOUNT		if HAVE_OBJTOOL_MCOUNT
diff --git a/arch/x86/include/asm/context_tracking_work.h b/arch/x86/include/asm/context_tracking_work.h
new file mode 100644
index 0000000000000..5f3b2d0977235
--- /dev/null
+++ b/arch/x86/include/asm/context_tracking_work.h
@@ -0,0 +1,16 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_X86_CONTEXT_TRACKING_WORK_H
+#define _ASM_X86_CONTEXT_TRACKING_WORK_H
+
+static __always_inline void arch_context_tracking_work(enum ct_work work)
+{
+	switch (work) {
+	case CT_WORK_n:
+		// Do work...
+		break;
+	case CT_WORK_MAX:
+		WARN_ON_ONCE(true);
+	}
+}
+
+#endif
diff --git a/include/linux/context_tracking.h b/include/linux/context_tracking.h
index af9fe87a09225..0b0faa040e9b5 100644
--- a/include/linux/context_tracking.h
+++ b/include/linux/context_tracking.h
@@ -5,6 +5,7 @@
 #include <linux/sched.h>
 #include <linux/vtime.h>
 #include <linux/context_tracking_state.h>
+#include <linux/context_tracking_work.h>
 #include <linux/instrumentation.h>
 
 #include <asm/ptrace.h>
@@ -137,6 +138,26 @@ static __always_inline unsigned long ct_state_inc(int incby)
 	return raw_atomic_add_return(incby, this_cpu_ptr(&context_tracking.state));
 }
 
+#ifdef CONFIG_CONTEXT_TRACKING_WORK
+static __always_inline unsigned long ct_state_inc_clear_work(int incby)
+{
+	struct context_tracking *ct = this_cpu_ptr(&context_tracking);
+	unsigned long new, old, state;
+
+	state = arch_atomic_read(&ct->state);
+	do {
+		old = state;
+		new = old & ~CT_WORK_MASK;
+		new += incby;
+		state = arch_atomic_cmpxchg(&ct->state, old, new);
+	} while (old != state);
+
+	return new;
+}
+#else
+#define ct_state_inc_clear_work(x) ct_state_inc(x)
+#endif
+
 static __always_inline bool warn_rcu_enter(void)
 {
 	bool ret = false;
diff --git a/include/linux/context_tracking_state.h b/include/linux/context_tracking_state.h
index eb2149b20baef..b6ddfccba9714 100644
--- a/include/linux/context_tracking_state.h
+++ b/include/linux/context_tracking_state.h
@@ -5,6 +5,7 @@
 #include <linux/percpu.h>
 #include <linux/static_key.h>
 #include <linux/context_tracking_irq.h>
+#include <linux/context_tracking_work.h>
 
 /* Offset to allow distinguishing irq vs. task-based idle entry/exit. */
 #define CT_NESTING_IRQ_NONIDLE	((LONG_MAX / 2) + 1)
@@ -39,16 +40,19 @@ struct context_tracking {
 };
 
 /*
- * We cram two different things within the same atomic variable:
+ * We cram up to three different things within the same atomic variable:
  *
- *                     CT_RCU_WATCHING_START  CT_STATE_START
- *                                |                |
- *                                v                v
- *     MSB [ RCU watching counter ][ context_state ] LSB
- *         ^                       ^
- *         |                       |
- * CT_RCU_WATCHING_END        CT_STATE_END
+ *                     CT_RCU_WATCHING_START                  CT_STATE_START
+ *                                |         CT_WORK_START          |
+ *                                |               |                |
+ *                                v               v                v
+ *     MSB [ RCU watching counter ][ context work ][ context_state ] LSB
+ *         ^                       ^               ^
+ *         |                       |               |
+ *         |                  CT_WORK_END          |
+ * CT_RCU_WATCHING_END                        CT_STATE_END
  *
+ * The [ context work ] region spans 0 bits if CONFIG_CONTEXT_WORK=n
  * Bits are used from the LSB upwards, so unused bits (if any) will always be in
  * upper bits of the variable.
  */
@@ -59,18 +63,24 @@ struct context_tracking {
 #define CT_STATE_START 0
 #define CT_STATE_END   (CT_STATE_START + CT_STATE_WIDTH - 1)
 
-#define CT_RCU_WATCHING_MAX_WIDTH (CT_SIZE - CT_STATE_WIDTH)
+#define CT_WORK_WIDTH (IS_ENABLED(CONFIG_CONTEXT_TRACKING_WORK) ? CT_WORK_MAX_OFFSET : 0)
+#define	CT_WORK_START (CT_STATE_END + 1)
+#define CT_WORK_END   (CT_WORK_START + CT_WORK_WIDTH - 1)
+
+#define CT_RCU_WATCHING_MAX_WIDTH (CT_SIZE - CT_WORK_WIDTH - CT_STATE_WIDTH)
 #define CT_RCU_WATCHING_WIDTH     (IS_ENABLED(CONFIG_RCU_DYNTICKS_TORTURE) ? 2 : CT_RCU_WATCHING_MAX_WIDTH)
-#define CT_RCU_WATCHING_START     (CT_STATE_END + 1)
+#define CT_RCU_WATCHING_START     (CT_WORK_END + 1)
 #define CT_RCU_WATCHING_END       (CT_RCU_WATCHING_START + CT_RCU_WATCHING_WIDTH - 1)
 #define CT_RCU_WATCHING           BIT(CT_RCU_WATCHING_START)
 
 #define CT_STATE_MASK        GENMASK(CT_STATE_END,        CT_STATE_START)
+#define CT_WORK_MASK         GENMASK(CT_WORK_END,         CT_WORK_START)
 #define CT_RCU_WATCHING_MASK GENMASK(CT_RCU_WATCHING_END, CT_RCU_WATCHING_START)
 
 #define CT_UNUSED_WIDTH (CT_RCU_WATCHING_MAX_WIDTH - CT_RCU_WATCHING_WIDTH)
 
 static_assert(CT_STATE_WIDTH        +
+	      CT_WORK_WIDTH         +
 	      CT_RCU_WATCHING_WIDTH +
 	      CT_UNUSED_WIDTH       ==
 	      CT_SIZE);
diff --git a/include/linux/context_tracking_work.h b/include/linux/context_tracking_work.h
new file mode 100644
index 0000000000000..c68245f8d77c5
--- /dev/null
+++ b/include/linux/context_tracking_work.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_CONTEXT_TRACKING_WORK_H
+#define _LINUX_CONTEXT_TRACKING_WORK_H
+
+#include <linux/bitops.h>
+
+enum {
+	CT_WORK_n_OFFSET,
+	CT_WORK_MAX_OFFSET
+};
+
+enum ct_work {
+	CT_WORK_n        = BIT(CT_WORK_n_OFFSET),
+	CT_WORK_MAX      = BIT(CT_WORK_MAX_OFFSET)
+};
+
+#include <asm/context_tracking_work.h>
+
+#ifdef CONFIG_CONTEXT_TRACKING_WORK
+extern bool ct_set_cpu_work(unsigned int cpu, enum ct_work work);
+#else
+static inline bool
+ct_set_cpu_work(unsigned int cpu, unsigned int work) { return false; }
+#endif
+
+#endif
diff --git a/kernel/context_tracking.c b/kernel/context_tracking.c
index 15f10ddec8cbe..f7019c12269f9 100644
--- a/kernel/context_tracking.c
+++ b/kernel/context_tracking.c
@@ -72,6 +72,67 @@ static __always_inline void rcu_task_trace_heavyweight_exit(void)
 #endif /* #ifdef CONFIG_TASKS_TRACE_RCU */
 }
 
+#ifdef CONFIG_CONTEXT_TRACKING_WORK
+static noinstr void ct_work_flush(unsigned long seq)
+{
+	int bit;
+
+	seq = (seq & CT_WORK_MASK) >> CT_WORK_START;
+
+	/*
+	 * arch_context_tracking_work() must be noinstr, non-blocking,
+	 * and NMI safe.
+	 */
+	for_each_set_bit(bit, &seq, CT_WORK_MAX)
+		arch_context_tracking_work(BIT(bit));
+}
+
+/**
+ * ct_set_cpu_work - set work to be run at next kernel context entry
+ *
+ * If @cpu is not currently executing in kernelspace, it will execute the
+ * callback mapped to @work (see arch_context_tracking_work()) at its next
+ * transition to CT_KERNEL_STATE.
+ *
+ * If it is already in CT_KERNEL_STATE, this will be a no-op.
+ */
+bool ct_set_cpu_work(unsigned int cpu, enum ct_work work)
+{
+	struct context_tracking *ct = per_cpu_ptr(&context_tracking, cpu);
+	unsigned int old;
+	bool ret = false;
+
+	if (!ct->active)
+		return false;
+
+	preempt_disable();
+
+	old = atomic_read(&ct->state);
+
+	/*
+	 * We only want to set the work bit if the target CPU is not in
+	 * kernelspace, so we clear the KERNEL bit here and let the cmpxchg do
+	 * the check for us - the state could change between the atomic_read() and
+	 * the cmpxchg().
+	 */
+	old &= ~CT_STATE_KERNEL;
+	/*
+	 * Try setting the work until either
+	 * - the target CPU has entered kernelspace
+	 * - the work has been set
+	 */
+	do {
+		ret = atomic_try_cmpxchg(&ct->state, &old, old | (work << CT_WORK_START));
+	} while (!ret && ((old & CT_STATE_MASK) != CT_STATE_KERNEL));
+
+	preempt_enable();
+	return ret;
+}
+#else
+static __always_inline void ct_work_flush(unsigned long work) { }
+static __always_inline void ct_work_clear(struct context_tracking *ct) { }
+#endif
+
 /*
  * Record entry into an extended quiescent state.  This is only to be
  * called when not already in an extended quiescent state, that is,
@@ -88,7 +149,7 @@ static noinstr void ct_kernel_exit_state(int offset)
 	 * next idle sojourn.
 	 */
 	rcu_task_trace_heavyweight_enter();  // Before CT state update!
-	seq = ct_state_inc(offset);
+	seq = ct_state_inc_clear_work(offset);
 	// RCU is no longer watching.  Better be in extended quiescent state!
 	WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) && (seq & CT_RCU_WATCHING));
 }
@@ -100,7 +161,7 @@ static noinstr void ct_kernel_exit_state(int offset)
  */
 static noinstr void ct_kernel_enter_state(int offset)
 {
-	int seq;
+	unsigned long seq;
 
 	/*
 	 * CPUs seeing atomic_add_return() must see prior idle sojourns,
@@ -108,6 +169,7 @@ static noinstr void ct_kernel_enter_state(int offset)
 	 * critical section.
 	 */
 	seq = ct_state_inc(offset);
+	ct_work_flush(seq);
 	// RCU is now watching.  Better not be in an extended quiescent state!
 	rcu_task_trace_heavyweight_exit();  // After CT state update!
 	WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) && !(seq & CT_RCU_WATCHING));
diff --git a/kernel/time/Kconfig b/kernel/time/Kconfig
index b0b97a60aaa6f..7e8106a0d981f 100644
--- a/kernel/time/Kconfig
+++ b/kernel/time/Kconfig
@@ -181,6 +181,11 @@ config CONTEXT_TRACKING_USER_FORCE
 	  Say N otherwise, this option brings an overhead that you
 	  don't want in production.
 
+config CONTEXT_TRACKING_WORK
+	bool
+	depends on HAVE_CONTEXT_TRACKING_WORK && CONTEXT_TRACKING_USER
+	default y
+
 config NO_HZ
 	bool "Old Idle dynticks config"
 	help
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 18:38:18 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 18:38:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871955.1282950 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlnq-00049P-FZ; Tue, 14 Jan 2025 18:38:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871955.1282950; Tue, 14 Jan 2025 18:38:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlnq-00049I-CH; Tue, 14 Jan 2025 18:38:14 +0000
Received: by outflank-mailman (input) for mailman id 871955;
 Tue, 14 Jan 2025 18:18: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
 <SRS0=WU/d=UG=ventanamicro.com=ajones@srs-se1.protection.inumbo.net>)
 id 1tXlUZ-0000tr-NK
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 18:18:20 +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 ed0e52eb-d2a3-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 19:18:17 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-ab2b29dfc65so892906466b.1
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 10:18:17 -0800 (PST)
Received: from localhost (2001-1ae9-1c2-4c00-20f-c6b4-1e57-7965.ip6.tmcz.cz.
 [2001:1ae9:1c2:4c00:20f:c6b4:1e57:7965])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d99008c3cdsm6567186a12.1.2025.01.14.10.18.14
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 14 Jan 2025 10:18:15 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ed0e52eb-d2a3-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=ventanamicro.com; s=google; t=1736878696; x=1737483496; 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=XEC/hblRhTLzuH9MgaKfGSbxrEegcBhKm+VDz1FH1LM=;
        b=i7RdUpo2gL9+w3iIFDCZ4ZAIV1ozJvD0f7lc109vtWk9mzvlFh2c7E9EbVFOso4Ul9
         zyyxCdeA3p1j/3NbtRDYl0ZmVZSmW8tYAHs+Xw9+Grsu8NMvKQj6RdCzY8yvfOrbrnJd
         avPAyKvDpCebGAyDbzkE0eKzLN8ldeSk66bwBunFgb7laNgi1nI9PdesUvt3zUiOZWVS
         JLKhBgqKZqQ5tblrxWl2HlRs3+s8OQu77A9DW/1WecWGzIjqVyTUOBawtRcyHwcVstP3
         hy6ta94NcepFZoMz2AWNg/5nq2CA6Waf0qYWQIJSqcWitfyTa8zCPFi1N5XfZgInFjVm
         uqIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736878696; x=1737483496;
        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=XEC/hblRhTLzuH9MgaKfGSbxrEegcBhKm+VDz1FH1LM=;
        b=V3e8Okb7G9Chd2Ha0DEak+4nBrcE8Xudy9dtGsMke8XTrioupZifG6zlSm++JCQ9pT
         O3wpmeYfBHjzrBF75c+bMo/utrvk0nYOhhK+mMZnPOapzcpemsuhtylX32FBBVeF0UnU
         zP+97CxhEy2lU3fZMIRAG996O2AP3RT84B6Ko6ziVb38EiKbpEOD45jYO7SIuPlH6D9O
         eM0P/ohvIdKQou3JQ4etoq3emKLMzfkfJEXAf6xl9EuxomBfle8EYq/XMhwm0fxECZEy
         iqpYkG5pGrC8t/XrwqQPLMDoJvCPvBzgc4XE51NbJRG9bFB4J/zZCUSk3rP2robY3rFv
         2wNA==
X-Forwarded-Encrypted: i=1; AJvYcCV3pHgtJeN7qxXd2mdeCC+UItc/Z5n/Jtg2f9nzN5X+CJvIjW4ha5UHHEsirzq0LGIgWeYSRqJieeM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzyYYwS2wQeMeF5hZKFu8I0peHfJVYwDlrwJvZusd5ReycRYf4a
	RQ4QKnvJoHgkqFBvkJI7YnFGV2zr9dYPz/n0AHVlyO9yvcY+ziqRmk+j/kiYD+Q=
X-Gm-Gg: ASbGncuLfxKd9Sd3/Y/ZlkCgZVw5k2U1wKJ1Q3CYJH7Yhb1avsA6wnB71NzgFs07Ccb
	7kgi04IF9ODNRRIGHtUcRpKWeEKlsNKLF5W/ieoHRdPXqLRzvU1Mf4Bg6G3trVCKDHQqu1xaWSa
	KcHaZ2KtO/Y4Q/a6P6hEiLP2cs6UWKL+8+VT2FKlMkgtAMBRZejfY8Kq8QxsRQQe0aTl845gVAC
	BI93XQkff50Pr4Z0h4CRnV0F8Niiy6u4mvu0y9BjyEdP5WDzpre3FYfC5OpY/4Jnf3Ll/4kamc7
	61nuZcGTfE84oKPtyYpzNHiPdrdjnFy++t3q4fzehQ==
X-Google-Smtp-Source: AGHT+IE94rMIJSL5eilIn677JkErdvBr0wH4kZG9obPcAbkaQOPu6vITYiCNybw5efE22ndc/IGOKw==
X-Received: by 2002:a17:907:2d8f:b0:aae:82b4:4691 with SMTP id a640c23a62f3a-ab2ab73b32amr2138572166b.25.1736878696177;
        Tue, 14 Jan 2025 10:18:16 -0800 (PST)
Date: Tue, 14 Jan 2025 19:18:14 +0100
From: Andrew Jones <ajones@ventanamicro.com>
To: Milan Djokic <milandjokic1995@gmail.com>
Cc: linux-riscv@lists.infradead.org, jgross@suse.com, 
	aou@eecs.berkeley.edu, Milan.Djokic@rt-rk.com, rafael.j.wysocki@intel.com, 
	linux-kernel@vger.kernel.org, oleksandr_tyshchenko@epam.com, iommu@lists.linux.dev, 
	sstabellini@kernel.org, palmer@dabbelt.com, paul.walmsley@sifive.com, 
	xen-devel@lists.xenproject.org, Slavisa.Petrovic@rt-rk.com, takakura@valinux.co.jp
Subject: Re: [PATCH] riscv: Add initial Xen guest support for RISC-V
Message-ID: <20250114-316084c962eb867c0b681043@orel>
References: <e4a649a7fdfc8fcf5f48a0bc4e76e5d546078083.1736868605.git.Slavisa.Petrovic@rt-rk.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <e4a649a7fdfc8fcf5f48a0bc4e76e5d546078083.1736868605.git.Slavisa.Petrovic@rt-rk.com>

On Tue, Jan 14, 2025 at 05:09:36PM +0100, Milan Djokic wrote:
> From: Slavisa Petrovic <Slavisa.Petrovic@rt-rk.com>
> 
> This patch introduces initial support for running RISC-V as a Xen guest.
> It provides the necessary infrastructure and stubs for Xen-specific
> operations. Key changes include:
> 
> - Modifications to the RISC-V kernel to integrate Xen-specific hypercalls
>   and interfaces, with function implementations stubbed for future work.
> - Introduction of Xen-specific headers for RISC-V, including event
>   handling, hypervisor interaction, and page management. Functions are
>   defined but not yet implemented.
> - Stub implementations for memory management, grant tables, and context
>   switching in the Xen environment, allowing further development and
>   integration.
> 
> Signed-off-by: Milan Djokic <Milan.Djokic@rt-rk.com>
> Signed-off-by: Slavisa Petrovic <Slavisa.Petrovic@rt-rk.com>
> ---
>  arch/riscv/Kbuild                        |   1 +
>  arch/riscv/Kconfig                       |  19 +++
>  arch/riscv/include/asm/cpu.h             |   1 +
>  arch/riscv/include/asm/hypervisor.h      |   9 ++
>  arch/riscv/include/asm/irq.h             |   5 +
>  arch/riscv/include/asm/sync_bitops.h     |  27 ++++
>  arch/riscv/include/asm/xen/events.h      |  28 ++++
>  arch/riscv/include/asm/xen/hypercall.h   |   2 +
>  arch/riscv/include/asm/xen/hypervisor.h  |   2 +
>  arch/riscv/include/asm/xen/interface.h   |   2 +
>  arch/riscv/include/asm/xen/page.h        |   3 +
>  arch/riscv/include/asm/xen/swiotlb-xen.h |   2 +
>  arch/riscv/xen/Makefile                  |   2 +
>  arch/riscv/xen/enlighten.c               | 164 +++++++++++++++++++++++
>  arch/riscv/xen/grant-table.c             |  57 ++++++++
>  arch/riscv/xen/hypercall.S               |  71 ++++++++++
>  arch/riscv/xen/p2m.c                     |  76 +++++++++++
>  include/xen/interface/io/protocols.h     |   3 +
>  include/xen/riscv/hypercall.h            |  71 ++++++++++
>  include/xen/riscv/hypervisor.h           |  26 ++++
>  include/xen/riscv/interface.h            |  85 ++++++++++++
>  include/xen/riscv/page.h                 | 106 +++++++++++++++
>  include/xen/riscv/swiotlb-xen.h          |  13 ++
>  test.txt                                 |  21 +++
>  24 files changed, 796 insertions(+)
>  create mode 100644 arch/riscv/include/asm/hypervisor.h
>  create mode 100644 arch/riscv/include/asm/sync_bitops.h
>  create mode 100644 arch/riscv/include/asm/xen/events.h
>  create mode 100644 arch/riscv/include/asm/xen/hypercall.h
>  create mode 100644 arch/riscv/include/asm/xen/hypervisor.h
>  create mode 100644 arch/riscv/include/asm/xen/interface.h
>  create mode 100644 arch/riscv/include/asm/xen/page.h
>  create mode 100644 arch/riscv/include/asm/xen/swiotlb-xen.h
>  create mode 100644 arch/riscv/xen/Makefile
>  create mode 100644 arch/riscv/xen/enlighten.c
>  create mode 100644 arch/riscv/xen/grant-table.c
>  create mode 100644 arch/riscv/xen/hypercall.S
>  create mode 100644 arch/riscv/xen/p2m.c
>  create mode 100644 include/xen/riscv/hypercall.h
>  create mode 100644 include/xen/riscv/hypervisor.h
>  create mode 100644 include/xen/riscv/interface.h
>  create mode 100644 include/xen/riscv/page.h
>  create mode 100644 include/xen/riscv/swiotlb-xen.h
>  create mode 100644 test.txt
> 
> diff --git a/arch/riscv/Kbuild b/arch/riscv/Kbuild
> index 2c585f7a0b6e..d9b71deed2cd 100644
> --- a/arch/riscv/Kbuild
> +++ b/arch/riscv/Kbuild
> @@ -5,6 +5,7 @@ obj-$(CONFIG_BUILTIN_DTB) += boot/dts/
>  obj-$(CONFIG_CRYPTO) += crypto/
>  obj-y += errata/
>  obj-$(CONFIG_KVM) += kvm/
> +obj-$(CONFIG_XEN) += xen/
> 
>  obj-$(CONFIG_ARCH_SUPPORTS_KEXEC_PURGATORY) += purgatory/
> 
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index d4a7ca0388c0..13ea75221524 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -1071,6 +1071,25 @@ config PARAVIRT_TIME_ACCOUNTING
> 
>  	  If in doubt, say N here.
> 
> +config XEN_DOM0
> +	def_bool y
> +	depends on XEN
> +
> +config XEN
> +	bool "Xen guest support on RISCV"
> +	depends on RISCV && OF
> +	select PARAVIRT
> +	help
> +	  Enables support for running Linux as a Xen guest on RISC-V.
> +
> +	  Xen is a type-1 hypervisor that allows multiple operating systems
> +	  to run on the same hardware. Enabling this option allows the kernel
> +	  to function as a guest under the Xen hypervisor on RISC-V platforms.
> +
> +	  Say Y if you want to run this kernel as a guest under Xen on RISC-V.
> +
> +	  If unsure, say N.
> +
>  config RELOCATABLE
>  	bool "Build a relocatable kernel"
>  	depends on MMU && 64BIT && !XIP_KERNEL
> diff --git a/arch/riscv/include/asm/cpu.h b/arch/riscv/include/asm/cpu.h
> index 28d45a6678ce..fb2aac6a068e 100644
> --- a/arch/riscv/include/asm/cpu.h
> +++ b/arch/riscv/include/asm/cpu.h
> @@ -4,5 +4,6 @@
>  #define _ASM_CPU_H
> 
>  /* This header is required unconditionally by the ACPI core */
> +#include <linux/cpu.h>
> 
>  #endif /* _ASM_CPU_H */
> diff --git a/arch/riscv/include/asm/hypervisor.h b/arch/riscv/include/asm/hypervisor.h
> new file mode 100644
> index 000000000000..3a117afe57f0
> --- /dev/null
> +++ b/arch/riscv/include/asm/hypervisor.h
> @@ -0,0 +1,9 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _ASM_RISCV_HYPERVISOR_H
> +#define _ASM_RISCV_HYPERVISOR_H
> +
> +#include <asm/xen/hypervisor.h>
> +
> +void kvm_init_hyp_services(void);

riscv doesn't have kvm_init_hyp_services(), which is why it didn't have
asm/hypervisor.h. I also didn't see where asm/hypervisor.h is getting
included in this patch, so this hunk should be dropped.

> +
> +#endif
> diff --git a/arch/riscv/include/asm/irq.h b/arch/riscv/include/asm/irq.h
> index 7b038f3b7cb0..b14621848eae 100644
> --- a/arch/riscv/include/asm/irq.h
> +++ b/arch/riscv/include/asm/irq.h
> @@ -23,6 +23,11 @@ void riscv_set_intc_hwnode_fn(struct fwnode_handle *(*fn)(void));
> 
>  struct fwnode_handle *riscv_get_intc_hwnode(void);
> 
> +static inline int nr_legacy_irqs(void)
> +{
> +	return 0;
> +}
> +
>  #ifdef CONFIG_ACPI
> 
>  enum riscv_irqchip_type {
> diff --git a/arch/riscv/include/asm/sync_bitops.h b/arch/riscv/include/asm/sync_bitops.h
> new file mode 100644
> index 000000000000..28e3c64ba852
> --- /dev/null
> +++ b/arch/riscv/include/asm/sync_bitops.h
> @@ -0,0 +1,27 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef __ASM_SYNC_BITOPS_H__
> +#define __ASM_SYNC_BITOPS_H__
> +
> +#include <asm/bitops.h>
> +#include <asm/cmpxchg.h>
> +
> +/* sync_bitops functions are equivalent to the SMP implementation of the
> + * original functions, independently from CONFIG_SMP being defined.
> + *
> + * We need them because _set_bit etc are not SMP safe if !CONFIG_SMP. But
> + * under Xen you might be communicating with a completely external entity
> + * who might be on another CPU (e.g. two uniprocessor guests communicating
> + * via event channels and grant tables). So we need a variant of the bit
> + * ops which are SMP safe even on a UP kernel.
> + */
> +
> +#define sync_set_bit(nr, p)             set_bit(nr, p)
> +#define sync_clear_bit(nr, p)           clear_bit(nr, p)
> +#define sync_change_bit(nr, p)          change_bit(nr, p)
> +#define sync_test_and_set_bit(nr, p)    test_and_set_bit(nr, p)
> +#define sync_test_and_clear_bit(nr, p)  test_and_clear_bit(nr, p)
> +#define sync_test_and_change_bit(nr, p) test_and_change_bit(nr, p)
> +#define sync_test_bit(nr, addr)         test_bit(nr, addr)
> +#define arch_sync_cmpxchg               arch_cmpxchg
> +
> +#endif
> diff --git a/arch/riscv/include/asm/xen/events.h b/arch/riscv/include/asm/xen/events.h
> new file mode 100644
> index 000000000000..a3d0332ca46c
> --- /dev/null
> +++ b/arch/riscv/include/asm/xen/events.h
> @@ -0,0 +1,28 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _ASM_RISCV_XEN_EVENTS_H
> +#define _ASM_RISCV_XEN_EVENTS_H
> +
> +#include <asm/ptrace.h>
> +#include <asm/atomic.h>
> +
> +enum ipi_vector {
> +	XEN_PLACEHOLDER_VECTOR,
> +
> +	/* Xen IPIs go here */
> +	XEN_NR_IPIS,
> +};
> +
> +static inline int xen_irqs_disabled(struct pt_regs *regs)
> +{
> +	return 0;
> +}
> +
> +#define xchg_xen_ulong(ptr, val) xchg((ptr), (val))
> +
> +/* Rebind event channel is supported by default */
> +static inline bool xen_support_evtchn_rebind(void)
> +{
> +	return true;
> +}
> +
> +#endif /* _ASM_RISCV_XEN_EVENTS_H */
> diff --git a/arch/riscv/include/asm/xen/hypercall.h b/arch/riscv/include/asm/xen/hypercall.h
> new file mode 100644
> index 000000000000..0841ba1f0835
> --- /dev/null
> +++ b/arch/riscv/include/asm/xen/hypercall.h
> @@ -0,0 +1,2 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#include <xen/riscv/hypercall.h>
> diff --git a/arch/riscv/include/asm/xen/hypervisor.h b/arch/riscv/include/asm/xen/hypervisor.h
> new file mode 100644
> index 000000000000..05b7c834d0a9
> --- /dev/null
> +++ b/arch/riscv/include/asm/xen/hypervisor.h
> @@ -0,0 +1,2 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#include <xen/riscv/hypervisor.h>
> diff --git a/arch/riscv/include/asm/xen/interface.h b/arch/riscv/include/asm/xen/interface.h
> new file mode 100644
> index 000000000000..9f30b1d7e77c
> --- /dev/null
> +++ b/arch/riscv/include/asm/xen/interface.h
> @@ -0,0 +1,2 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#include <xen/riscv/interface.h>
> diff --git a/arch/riscv/include/asm/xen/page.h b/arch/riscv/include/asm/xen/page.h
> new file mode 100644
> index 000000000000..c8f5b873445b
> --- /dev/null
> +++ b/arch/riscv/include/asm/xen/page.h
> @@ -0,0 +1,3 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#include <xen/riscv/page.h>
> +#include <asm/mmu.h>
> diff --git a/arch/riscv/include/asm/xen/swiotlb-xen.h b/arch/riscv/include/asm/xen/swiotlb-xen.h
> new file mode 100644
> index 000000000000..aa3bc339df03
> --- /dev/null
> +++ b/arch/riscv/include/asm/xen/swiotlb-xen.h
> @@ -0,0 +1,2 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#include <xen/riscv/swiotlb-xen.h>
> diff --git a/arch/riscv/xen/Makefile b/arch/riscv/xen/Makefile
> new file mode 100644
> index 000000000000..f6d3a357e4c7
> --- /dev/null
> +++ b/arch/riscv/xen/Makefile
> @@ -0,0 +1,2 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +obj-y := enlighten.o p2m.o grant-table.o hypercall.o
> diff --git a/arch/riscv/xen/enlighten.c b/arch/riscv/xen/enlighten.c
> new file mode 100644
> index 000000000000..28bd66c288f9
> --- /dev/null
> +++ b/arch/riscv/xen/enlighten.c
> @@ -0,0 +1,164 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +#include <xen/xen.h>
> +#include <xen/events.h>
> +#include <xen/grant_table.h>
> +#include <xen/hvm.h>
> +#include <xen/interface/vcpu.h>
> +#include <xen/interface/xen.h>
> +#include <xen/interface/memory.h>
> +#include <xen/interface/hvm/params.h>
> +#include <xen/features.h>
> +#include <xen/platform_pci.h>
> +#include <xen/xenbus.h>
> +#include <xen/page.h>
> +#include <xen/interface/sched.h>
> +#include <xen/xen-ops.h>
> +#include <asm/xen/hypervisor.h>
> +#include <asm/xen/hypercall.h>
> +#include <asm/efi.h>
> +#include <linux/interrupt.h>
> +#include <linux/irqreturn.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_fdt.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_address.h>
> +#include <linux/cpuidle.h>
> +#include <linux/cpufreq.h>
> +#include <linux/cpu.h>
> +#include <linux/console.h>
> +#include <linux/pvclock_gtod.h>
> +#include <linux/reboot.h>
> +#include <linux/time64.h>
> +#include <linux/timekeeping.h>
> +#include <linux/timekeeper_internal.h>
> +#include <linux/acpi.h>
> +#include <linux/virtio_anchor.h>
> +
> +#include <linux/mm.h>
> +
> +static struct start_info _xen_start_info;
> +struct start_info *xen_start_info = &_xen_start_info;
> +EXPORT_SYMBOL(xen_start_info);
> +
> +enum xen_domain_type xen_domain_type = XEN_NATIVE;
> +EXPORT_SYMBOL(xen_domain_type);
> +
> +struct shared_info xen_dummy_shared_info;
> +struct shared_info *HYPERVISOR_shared_info = (void *)&xen_dummy_shared_info;
> +
> +DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu);
> +static struct vcpu_info __percpu *xen_vcpu_info;
> +
> +/* Linux <-> Xen vCPU id mapping */
> +DEFINE_PER_CPU(uint32_t, xen_vcpu_id);
> +EXPORT_PER_CPU_SYMBOL(xen_vcpu_id);
> +
> +/* These are unused until we support booting "pre-ballooned" */
> +unsigned long xen_released_pages;
> +struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata;
> +
> +static __read_mostly unsigned int xen_events_irq;
> +static __read_mostly phys_addr_t xen_grant_frames;
> +
> +#define GRANT_TABLE_INDEX   0
> +#define EXT_REGION_INDEX    1
> +
> +uint32_t xen_start_flags;
> +EXPORT_SYMBOL(xen_start_flags);
> +
> +int xen_unmap_domain_gfn_range(struct vm_area_struct *vma,
> +					int nr, struct page **pages)
> +{
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(xen_unmap_domain_gfn_range);
> +
> +static void xen_read_wallclock(struct timespec64 *ts)
> +{
> +}
> +
> +static int xen_pvclock_gtod_notify(struct notifier_block *nb,
> +					unsigned long was_set, void *priv)
> +{
> +	return 0;
> +}
> +
> +static struct notifier_block xen_pvclock_gtod_notifier = {
> +	.notifier_call = xen_pvclock_gtod_notify,
> +};
> +
> +static int xen_starting_cpu(unsigned int cpu)
> +{
> +	return 0;
> +}
> +
> +static int xen_dying_cpu(unsigned int cpu)
> +{
> +	return 0;
> +}
> +
> +void xen_reboot(int reason)
> +{
> +}
> +
> +static int xen_restart(struct notifier_block *nb, unsigned long action,
> +					void *data)
> +{
> +	return 0;
> +}
> +
> +static struct notifier_block xen_restart_nb = {
> +	.notifier_call = xen_restart,
> +	.priority = 192,
> +};
> +
> +static void xen_power_off(void)
> +{
> +}
> +
> +static __initdata struct {
> +	const char *compat;
> +	const char *prefix;
> +	const char *version;
> +	bool found;
> +} hyper_node = {"xen,xen", "xen,xen-", NULL, false};
> +
> +static int __init fdt_find_hyper_node(unsigned long node, const char *uname,
> +					int depth, void *data)
> +{
> +	return 0;
> +}
> +
> +void __init xen_early_init(void)
> +{
> +}
> +
> +static void __init xen_dt_guest_init(void)
> +{
> +}
> +
> +static int __init xen_guest_init(void)
> +{
> +	return 0;
> +}
> +early_initcall(xen_guest_init);
> +
> +static int xen_starting_runstate_cpu(unsigned int cpu)
> +{
> +	return 0;
> +}
> +
> +static int __init xen_late_init(void)
> +{
> +	return 0;
> +}
> +late_initcall(xen_late_init);
> +
> +
> +/* empty stubs */
> +void xen_arch_pre_suspend(void) { }
> +void xen_arch_post_suspend(int suspend_cancelled) { }
> +void xen_timer_resume(void) { }
> +void xen_arch_resume(void) { }
> +void xen_arch_suspend(void) { }

I don't see the point of creating arch/riscv/xen/enlighten.c by what looks
like copying arm's version and then deleting all the function
implementations. Much of arm's implementations look generic, so why not
keep them?

> diff --git a/arch/riscv/xen/grant-table.c b/arch/riscv/xen/grant-table.c
> new file mode 100644
> index 000000000000..9dd0cea74360
> --- /dev/null
> +++ b/arch/riscv/xen/grant-table.c
> @@ -0,0 +1,57 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/******************************************************************************
> + * grant_table.c
> + *
> + * Granting foreign access to our memory reservation.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version 2
> + * as published by the Free Software Foundation; or, when distributed
> + * separately from the Linux kernel or incorporated into other
> + * software packages, subject to the following license:
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> + * of this source file (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use, copy, modify,
> + * merge, publish, distribute, sublicense, and/or sell copies of the Software,
> + * and to permit persons to whom the Software is furnished to do so, subject to
> + * the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +#include <xen/interface/xen.h>
> +#include <xen/page.h>
> +#include <xen/grant_table.h>
> +
> +int arch_gnttab_map_shared(xen_pfn_t *frames, unsigned long nr_gframes,
> +					unsigned long max_nr_gframes,
> +					void **__shared)
> +{
> +	return 0;

should return -ENOSYS. arm returns that even now.

> +}
> +
> +void arch_gnttab_unmap(void *shared, unsigned long nr_gframes)
> +{
> +}
> +
> +int arch_gnttab_map_status(uint64_t *frames, unsigned long nr_gframes,
> +					unsigned long max_nr_gframes,
> +					grant_status_t **__shared)
> +{
> +	return 0;

should return -ENOSYS. arm returns that even now.

> +}
> +
> +int arch_gnttab_init(unsigned long nr_shared, unsigned long nr_status)
> +{
> +	return 0;
> +}
> diff --git a/arch/riscv/xen/hypercall.S b/arch/riscv/xen/hypercall.S
> new file mode 100644
> index 000000000000..a81afd2a11c4
> --- /dev/null
> +++ b/arch/riscv/xen/hypercall.S
> @@ -0,0 +1,71 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#include <linux/linkage.h>
> +#include <asm/assembler.h>
> +#include <xen/interface/xen.h>
> +EXPORT_SYMBOL_GPL(HYPERVISOR_event_channel_op);
> +EXPORT_SYMBOL_GPL(HYPERVISOR_grant_table_op);
> +EXPORT_SYMBOL_GPL(HYPERVISOR_xen_version);
> +EXPORT_SYMBOL_GPL(HYPERVISOR_console_io);
> +EXPORT_SYMBOL_GPL(HYPERVISOR_sched_op);
> +EXPORT_SYMBOL_GPL(HYPERVISOR_hvm_op);
> +EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
> +EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
> +EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
> +EXPORT_SYMBOL_GPL(HYPERVISOR_platform_op_raw);
> +EXPORT_SYMBOL_GPL(HYPERVISOR_multicall);
> +EXPORT_SYMBOL_GPL(HYPERVISOR_vm_assist);
> +EXPORT_SYMBOL_GPL(HYPERVISOR_dm_op);
> +EXPORT_SYMBOL_GPL(privcmd_call);
> +#define SBI_ECALL 0xE

Shouldn't this be 0xA000007, i.e. the SBI firmware specific extension
for Xen. Otherwise why refer to SBI? Note, '0xE' is an invalid, legacy
extension ID in SBI.

> +
> +    .data
> +
> +#define HYPERCALL_SIMPLE(hypercall) \
> +SYM_FUNC_START(HYPERVISOR_##hypercall) \
> +    li a6, __HYPERVISOR_##hypercall; \
> +    li a7, SBI_ECALL; \
> +    mv a5, a4; \
> +    mv a4, a3; \
> +    mv a3, a2; \
> +    mv a2, a1; \
> +    mv a1, a0; \
> +    li a0, 0; \

Assuming a0 has to be zero, then we should look for a solution to avoid
all the register shifting. Either some wrapper functions for the
hypercalls that convince the compiler to do the right thing or at
least use the HYPERCALL{0,1,2,...} defines to reduce the amount of
shifting to the minimum.

> +    ecall; \
> +    ret; \
> +SYM_FUNC_END(HYPERVISOR_##hypercall)
> +
> +#define HYPERCALL0 HYPERCALL_SIMPLE
> +#define HYPERCALL1 HYPERCALL_SIMPLE
> +#define HYPERCALL2 HYPERCALL_SIMPLE
> +#define HYPERCALL3 HYPERCALL_SIMPLE
> +#define HYPERCALL4 HYPERCALL_SIMPLE
> +#define HYPERCALL5 HYPERCALL_SIMPLE
> +
> +    .text
> +
> +HYPERCALL2(xen_version);
> +HYPERCALL3(console_io);
> +HYPERCALL3(grant_table_op);
> +HYPERCALL2(sched_op);
> +HYPERCALL2(event_channel_op);
> +HYPERCALL2(hvm_op);
> +HYPERCALL2(memory_op);
> +HYPERCALL2(physdev_op);
> +HYPERCALL3(vcpu_op);
> +HYPERCALL1(platform_op_raw);
> +HYPERCALL2(multicall);
> +HYPERCALL2(vm_assist);
> +HYPERCALL3(dm_op);
> +
> +SYM_FUNC_START(privcmd_call)
> +    mv a6, a0
> +    li a7, SBI_ECALL
> +    mv a5, a4;
> +    mv a4, a3;
> +    mv a3, a2;
> +    mv a2, a1;
> +    mv a1, a0;
> +    li a0, 0;

same comments as above

> +    ecall
> +    ret
> +SYM_FUNC_END(privcmd_call);
> diff --git a/arch/riscv/xen/p2m.c b/arch/riscv/xen/p2m.c
> new file mode 100644
> index 000000000000..7ce75e52d7c4
> --- /dev/null
> +++ b/arch/riscv/xen/p2m.c
> @@ -0,0 +1,76 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +#include <linux/memblock.h>
> +#include <linux/gfp.h>
> +#include <linux/export.h>
> +#include <linux/spinlock.h>
> +#include <linux/slab.h>
> +#include <linux/types.h>
> +#include <linux/dma-mapping.h>
> +#include <linux/vmalloc.h>
> +#include <linux/swiotlb.h>
> +
> +#include <xen/xen.h>
> +#include <xen/interface/memory.h>
> +#include <xen/grant_table.h>
> +#include <xen/page.h>
> +#include <xen/swiotlb-xen.h>
> +
> +#include <asm/cacheflush.h>
> +#include <asm/xen/hypercall.h>
> +#include <asm/xen/interface.h>
> +
> +struct xen_p2m_entry {
> +	unsigned long pfn;
> +	unsigned long mfn;
> +	unsigned long nr_pages;
> +	struct rb_node rbnode_phys;
> +};
> +
> +static rwlock_t p2m_lock;
> +struct rb_root phys_to_mach = RB_ROOT;
> +EXPORT_SYMBOL_GPL(phys_to_mach);
> +
> +static int xen_add_phys_to_mach_entry(struct xen_p2m_entry *new)
> +{
> +
> +	return 0;
> +}
> +
> +unsigned long __pfn_to_mfn(unsigned long pfn)
> +{
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(__pfn_to_mfn);
> +
> +int set_foreign_p2m_mapping(struct gnttab_map_grant_ref *map_ops,
> +					struct gnttab_map_grant_ref *kmap_ops,
> +					struct page **pages, unsigned int count)
> +{
> +	return 0;
> +}
> +
> +int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
> +					struct gnttab_unmap_grant_ref *kunmap_ops,
> +					struct page **pages, unsigned int count)
> +{
> +	return 0;
> +}
> +
> +bool __set_phys_to_machine_multi(unsigned long pfn,
> +					unsigned long mfn, unsigned long nr_pages)
> +{
> +	return true;
> +}
> +EXPORT_SYMBOL_GPL(__set_phys_to_machine_multi);
> +
> +bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
> +{
> +	return true;
> +}
> +EXPORT_SYMBOL_GPL(__set_phys_to_machine);
> +
> +static int p2m_init(void)
> +{
> +	return 0;
> +}
> +arch_initcall(p2m_init);

Again, I'm not sure what the point of copying functions from arm without
their (what appear to be generic) implementations is.

> diff --git a/include/xen/interface/io/protocols.h b/include/xen/interface/io/protocols.h
> index 22099bb4079f..6c6317462be0 100644
> --- a/include/xen/interface/io/protocols.h
> +++ b/include/xen/interface/io/protocols.h
> @@ -6,6 +6,7 @@
>  #define XEN_IO_PROTO_ABI_X86_64     "x86_64-abi"
>  #define XEN_IO_PROTO_ABI_POWERPC64  "powerpc64-abi"
>  #define XEN_IO_PROTO_ABI_ARM        "arm-abi"
> +#define XEN_IO_PROTO_ABI_RISCV      "riscv-abi"
> 
>  #if defined(__i386__)
>  # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_X86_32
> @@ -15,6 +16,8 @@
>  # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_POWERPC64
>  #elif defined(__arm__) || defined(__aarch64__)
>  # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_ARM
> +#elif defined(__riscv)
> +# define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_RISCV
>  #else
>  # error arch fixup needed here
>  #endif
> diff --git a/include/xen/riscv/hypercall.h b/include/xen/riscv/hypercall.h
> new file mode 100644
> index 000000000000..f76d8a018f26
> --- /dev/null
> +++ b/include/xen/riscv/hypercall.h
> @@ -0,0 +1,71 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/******************************************************************************
> + * hypercall.h
> + *
> + * Linux-specific hypervisor handling.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version 2
> + * as published by the Free Software Foundation; or, when distributed
> + * separately from the Linux kernel or incorporated into other
> + * software packages, subject to the following license:
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> + * of this source file (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use, copy, modify,
> + * merge, publish, distribute, sublicense, and/or sell copies of the Software,
> + * and to permit persons to whom the Software is furnished to do so, subject to
> + * the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
> + * IN THE SOFTWARE.
> + */

Just the SPDX should be sufficient.

> +
> +#ifndef _ASM_RISCV_XEN_HYPERCALL_H
> +#define _ASM_RISCV_XEN_HYPERCALL_H
> +
> +#include <linux/bug.h>
> +
> +#include <xen/interface/xen.h>
> +#include <xen/interface/sched.h>
> +#include <xen/interface/platform.h>
> +
> +struct xen_dm_op_buf;
> +
> +long privcmd_call(unsigned int call, unsigned long a1,
> +		unsigned long a2, unsigned long a3,
> +		unsigned long a4, unsigned long a5);
> +int HYPERVISOR_xen_version(int cmd, void *arg);
> +int HYPERVISOR_console_io(int cmd, int count, char *str);
> +int HYPERVISOR_grant_table_op(unsigned int cmd, void *uop, unsigned int count);
> +int HYPERVISOR_sched_op(int cmd, void *arg);
> +int HYPERVISOR_event_channel_op(int cmd, void *arg);
> +unsigned long HYPERVISOR_hvm_op(int op, void *arg);
> +int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
> +int HYPERVISOR_physdev_op(int cmd, void *arg);
> +int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
> +int HYPERVISOR_vm_assist(unsigned int cmd, unsigned int type);
> +int HYPERVISOR_dm_op(domid_t domid, unsigned int nr_bufs,
> +			 struct xen_dm_op_buf *bufs);
> +int HYPERVISOR_platform_op_raw(void *arg);
> +static inline int HYPERVISOR_platform_op(struct xen_platform_op *op)
> +{
> +	return 0;
> +}
> +int HYPERVISOR_multicall(struct multicall_entry *calls, uint32_t nr);
> +
> +static inline int
> +HYPERVISOR_suspend(unsigned long start_info_mfn)

Don't wrap this function definition

> +{
> +	return 0;
> +}
> +
> +#endif /* _ASM_RISCV_XEN_HYPERCALL_H */
> diff --git a/include/xen/riscv/hypervisor.h b/include/xen/riscv/hypervisor.h
> new file mode 100644
> index 000000000000..2c1f9625be80
> --- /dev/null
> +++ b/include/xen/riscv/hypervisor.h
> @@ -0,0 +1,26 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _ASM_RISCV_XEN_HYPERVISOR_H
> +#define _ASM_RISCV_XEN_HYPERVISOR_H
> +
> +#include <linux/init.h>
> +
> +extern struct shared_info *HYPERVISOR_shared_info;
> +extern struct start_info *xen_start_info;
> +
> +#ifdef CONFIG_XEN
> +void __init xen_early_init(void);
> +#else
> +static inline void xen_early_init(void) { return; }
> +#endif
> +
> +#ifdef CONFIG_HOTPLUG_CPU
> +static inline void xen_arch_register_cpu(int num)
> +{
> +}
> +
> +static inline void xen_arch_unregister_cpu(int num)
> +{
> +}
> +#endif
> +
> +#endif /* _ASM_RISCV_XEN_HYPERVISOR_H */
> diff --git a/include/xen/riscv/interface.h b/include/xen/riscv/interface.h
> new file mode 100644
> index 000000000000..6769b5b39cba
> --- /dev/null
> +++ b/include/xen/riscv/interface.h
> @@ -0,0 +1,85 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/******************************************************************************
> + * Guest OS interface to RISCV Xen.
> + *
> + */
> +
> +#ifndef _ASM_RISCV_XEN_INTERFACE_H
> +#define _ASM_RISCV_XEN_INTERFACE_H
> +
> +#include <linux/types.h>
> +
> +#define uint64_aligned_t uint64_t __aligned(8)
> +
> +#define __DEFINE_GUEST_HANDLE(name, type) \
> +	typedef struct { union { type * p; uint64_aligned_t q; }; }  \
> +		__guest_handle_ ## name
> +
> +#define DEFINE_GUEST_HANDLE_STRUCT(name) \
> +	__DEFINE_GUEST_HANDLE(name, struct name)
> +#define DEFINE_GUEST_HANDLE(name) __DEFINE_GUEST_HANDLE(name, name)
> +#define GUEST_HANDLE(name)        __guest_handle_ ## name
> +
> +#define set_xen_guest_handle(hnd, val)			\
> +	do {						\
> +		if (sizeof(hnd) == 8)			\
> +			*(uint64_t *)&(hnd) = 0;	\
> +		(hnd).p = val;				\
> +	} while (0)
> +
> +#define __HYPERVISOR_platform_op_raw __HYPERVISOR_platform_op
> +
> +#ifndef __ASSEMBLY__
> +/* Explicitly size integers that represent pfns in the interface with
> + * Xen so that we can have one ABI that works for 32 and 64 bit guests.
> + * Note that this means that the xen_pfn_t type may be capable of
> + * representing pfn's which the guest cannot represent in its own pfn
> + * type. However since pfn space is controlled by the guest this is
> + * fine since it simply wouldn't be able to create any sure pfns in
> + * the first place.
> + */
> +typedef uint64_t xen_pfn_t;
> +#define PRI_xen_pfn "llx"
> +typedef uint64_t xen_ulong_t;
> +#define PRI_xen_ulong "llx"
> +typedef int64_t xen_long_t;
> +#define PRI_xen_long "llx"
> +/* Guest handles for primitive C types. */
> +__DEFINE_GUEST_HANDLE(uchar, unsigned char);
> +__DEFINE_GUEST_HANDLE(uint,  unsigned int);
> +DEFINE_GUEST_HANDLE(char);
> +DEFINE_GUEST_HANDLE(int);
> +DEFINE_GUEST_HANDLE(void);
> +DEFINE_GUEST_HANDLE(uint64_t);
> +DEFINE_GUEST_HANDLE(uint32_t);
> +DEFINE_GUEST_HANDLE(xen_pfn_t);
> +DEFINE_GUEST_HANDLE(xen_ulong_t);
> +
> +/* Maximum number of virtual CPUs in multi-processor guests. */
> +#define MAX_VIRT_CPUS 1
> +
> +struct arch_vcpu_info { };
> +struct arch_shared_info { };
> +
> +/* TODO: Move pvclock definitions some place arch independent */
> +struct pvclock_vcpu_time_info {
> +	u32   version;
> +	u32   pad0;
> +	u64   tsc_timestamp;
> +	u64   system_time;
> +	u32   tsc_to_system_mul;
> +	s8    tsc_shift;
> +	u8    flags;
> +	u8    pad[2];
> +} __packed; /* 32 bytes */
> +
> +/* It is OK to have a 12 bytes struct with no padding because it is packed */
> +struct pvclock_wall_clock {
> +	u32   version;
> +	u32   sec;
> +	u32   nsec;
> +	u32   sec_hi;
> +} __packed;
> +#endif
> +
> +#endif /* _ASM_RISCV_XEN_INTERFACE_H */
> diff --git a/include/xen/riscv/page.h b/include/xen/riscv/page.h
> new file mode 100644
> index 000000000000..fe07a9bffa7e
> --- /dev/null
> +++ b/include/xen/riscv/page.h
> @@ -0,0 +1,106 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _ASM_RISCV_XEN_PAGE_H
> +#define _ASM_RISCV_XEN_PAGE_H
> +
> +#include <asm/page.h>
> +
> +#include <linux/pfn.h>
> +#include <linux/types.h>
> +#include <linux/dma-mapping.h>
> +#include <linux/pgtable.h>
> +
> +#include <xen/xen.h>
> +#include <xen/interface/grant_table.h>
> +
> +/* Xen machine address */
> +struct xmaddr {
> +	phys_addr_t maddr;
> +};
> +
> +/* Xen pseudo-physical address */
> +struct xpaddr {
> +	phys_addr_t paddr;
> +};
> +
> +#define XMADDR(x)	((struct xmaddr) { .maddr = (x) })
> +#define XPADDR(x)	((struct xpaddr) { .paddr = (x) })
> +
> +#define INVALID_P2M_ENTRY      (~0UL)
> +
> +/*
> + * The pseudo-physical frame (pfn) used in all the helpers is always based
> + * on Xen page granularity (i.e 4KB).
> + *
> + * A Linux page may be split across multiple non-contiguous Xen page so we
> + * have to keep track with frame based on 4KB page granularity.
> + *
> + * PV drivers should never make a direct usage of those helpers (particularly
> + * pfn_to_gfn and gfn_to_pfn).
> + */
> +
> +unsigned long __pfn_to_mfn(unsigned long pfn);
> +extern struct rb_root phys_to_mach;
> +
> +/* Pseudo-physical <-> Guest conversion */
> +static inline unsigned long pfn_to_gfn(unsigned long pfn)
> +{
> +	return 0;
> +}
> +
> +static inline unsigned long gfn_to_pfn(unsigned long gfn)
> +{
> +	return 0;
> +}
> +
> +/* Pseudo-physical <-> BUS conversion */
> +static inline unsigned long pfn_to_bfn(unsigned long pfn)
> +{
> +	return 0;
> +}
> +
> +static inline unsigned long bfn_to_pfn(unsigned long bfn)
> +{
> +	return 0;
> +}
> +
> +#define bfn_to_local_pfn(bfn)	bfn_to_pfn(bfn)
> +
> +/* VIRT <-> GUEST conversion */
> +#define virt_to_gfn(v)                                                         \
> +	({                                                                     \
> +		WARN_ON_ONCE(!virt_addr_valid(v));                              \
> +		pfn_to_gfn(virt_to_phys(v) >> XEN_PAGE_SHIFT);                 \
> +	})
> +#define gfn_to_virt(m)		(__va(gfn_to_pfn(m) << XEN_PAGE_SHIFT))
> +
> +#define percpu_to_gfn(v)	\
> +	(pfn_to_gfn(per_cpu_ptr_to_phys(v) >> XEN_PAGE_SHIFT))
> +
> +static inline struct xmaddr arbitrary_virt_to_machine(void *vaddr)
> +{
> +	WARN_ON_ONCE(1);
> +	return (struct xmaddr){0};
> +}
> +
> +extern int set_foreign_p2m_mapping(struct gnttab_map_grant_ref *map_ops,
> +				   struct gnttab_map_grant_ref *kmap_ops,
> +				   struct page **pages, unsigned int count);
> +
> +extern int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
> +					 struct gnttab_unmap_grant_ref *kunmap_ops,
> +					 struct page **pages, unsigned int count);
> +
> +bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn);
> +bool __set_phys_to_machine_multi(unsigned long pfn, unsigned long mfn,
> +		unsigned long nr_pages);
> +
> +static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
> +{
> +	return 0;
> +}
> +
> +bool xen_arch_need_swiotlb(struct device *dev,
> +			   phys_addr_t phys,
> +			   dma_addr_t dev_addr);
> +
> +#endif /* _ASM_RISCV_XEN_PAGE_H */
> diff --git a/include/xen/riscv/swiotlb-xen.h b/include/xen/riscv/swiotlb-xen.h
> new file mode 100644
> index 000000000000..97ecd8cbbc2d
> --- /dev/null
> +++ b/include/xen/riscv/swiotlb-xen.h
> @@ -0,0 +1,13 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _ASM_RISCV_SWIOTLB_XEN_H
> +#define _ASM_RISCV_SWIOTLB_XEN_H
> +
> +#include <xen/features.h>
> +#include <xen/xen.h>
> +
> +static inline int xen_swiotlb_detect(void)
> +{
> +	return 0;
> +}
> +
> +#endif /* _ASM_RISCV_SWIOTLB_XEN_H */
> diff --git a/test.txt b/test.txt
> new file mode 100644
> index 000000000000..e54267998982
> --- /dev/null
> +++ b/test.txt
> @@ -0,0 +1,21 @@
> +WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
> +#120:
> +new file mode 100644
> +
> +WARNING: do not add new typedefs
> +#808: FILE: include/xen/riscv/interface.h:15:
> ++	typedef struct { union { type * p; uint64_aligned_t q; }; }  \
> +
> +WARNING: please, no spaces at the start of a line
> +#1006: FILE: include/xen/riscv/swiotlb-xen.h:10:
> ++    return 0;$
> +
> +total: 0 errors, 3 warnings, 810 lines checked
> +
> +NOTE: For some of the reported defects, checkpatch may be able to
> +      mechanically convert to the typical style using --fix or --fix-inplace.
> +
> +0001-riscv-Add-initial-Xen-guest-support-for-RISC-V.patch has style problems, please review.
> +
> +NOTE: If any of the errors are false positives, please report
> +      them to the maintainer, see CHECKPATCH in MAINTAINERS.

You obviously added this file by accident. Please proof read patches
before sending them.

I'm glad to see interest in getting Xen support upstream, but this isn't
the right approach. For starters, the patch is clearly missing the 'RFC'
it should have in its prefix, but it also doesn't make sense to post
(much less merge) a bunch of stubs, at least not without another patch
in the same series filling most or all those stubs in with tested code.
Also, anything that is generic should either be copied in the first go
(rather than deleting it just to add it back later) or, even better, it
should be factored out of the other architecture specific code into a
common place where it can be shared.

Thanks,
drew


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 18:38:18 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 18:38:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.871973.1282955 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlnq-0004Cd-Mi; Tue, 14 Jan 2025 18:38:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 871973.1282955; Tue, 14 Jan 2025 18:38:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXlnq-0004BQ-Ir; Tue, 14 Jan 2025 18:38:14 +0000
Received: by outflank-mailman (input) for mailman id 871973;
 Tue, 14 Jan 2025 18:29:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=WU/d=UG=ventanamicro.com=ajones@srs-se1.protection.inumbo.net>)
 id 1tXlfI-0006QE-JV
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 18:29:24 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 79fa8977-d2a5-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 19:29:23 +0100 (CET)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-aaf57c2e0beso1181202366b.3
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 10:29:23 -0800 (PST)
Received: from localhost (2001-1ae9-1c2-4c00-20f-c6b4-1e57-7965.ip6.tmcz.cz.
 [2001:1ae9:1c2:4c00:20f:c6b4:1e57:7965])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c905f04fsm659166066b.27.2025.01.14.10.29.21
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 14 Jan 2025 10:29:21 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 79fa8977-d2a5-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=ventanamicro.com; s=google; t=1736879362; x=1737484162; 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=+L6x2g4BC/d/+jfoDGOj0pMskOpzz9VGXCLG5E4WwRY=;
        b=Q4fNJChVVfTDoghLoPnFISsues+0b5KhMOlwWIZXesd6qczxoWf7bEsWpLx06yo/WI
         nhwVdw5Gr3aWOJZHNu4mM5Vf6dqeQGQPGNyFJZ6vFIi4ysbyOIi4GUPmpvEqUeekK8gg
         j2e21TgH0RiYiEro0qBSgTQUJN/E8sZqQpS7xMz7cvQHoeymuFKnod8wocE59BoXqTCa
         z+YOaRqLu3/8xvtd2mhUNIEyC+Ugyx+t/9MwH/y1kHEVFPOMmR3GTcBGEiisa02+DWb5
         dS0CEL6lXXcr9B4nndHj/WZSnPgJoxdHMTcbel55bRGB7DCUOH4V7OaCTdrTv3ab+ztt
         0eTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736879362; x=1737484162;
        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=+L6x2g4BC/d/+jfoDGOj0pMskOpzz9VGXCLG5E4WwRY=;
        b=EsNkDx2ssajfJXy59YSuUFvi7f4JJtezzq98DDFe4K3h03XCFBMPWj/vRX4UY+t7ld
         A7NO27rkmb2bpVUORmoHpHRpH0Rh751KJv5a7XkueakJ2PzI3XDVZu62Zlv20x6an1Vi
         gLOetZTdGtl2vcy7B3/3ZsohYiVaI2c/Xx+kmLY4MwFVlExRnvjm+JcCm6ABeuAmV1Vk
         Si90f0y6VKQs7qK6R5e+HdXGQgsG1cqWf+tqFkCviJFIyPkpNE05rzXP74a/R8HS5QCa
         nw2BdruCOzW9Z8P8WtM2E53H91WwbOBYosALrjpSNw3sKlJYB7VWqDQIccrMVbQtytFz
         k3yw==
X-Forwarded-Encrypted: i=1; AJvYcCWMWs7SBiCQmN/9KtbE9XN34/133lVggSgfKhwAEJWcWhAfxT72c43gdLNI05MZLZMMBYMV6HK47ZU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyPxQWnD8+HVOpMfeYV5Y3gygemHSrk3V/bN9qUCI1qtVQOxmDs
	85aDyXYUunA+VMGSUl2+U80PVErYjDg+YXaj59uhEVZr8WxDYsXCWM3vyNwqVy8=
X-Gm-Gg: ASbGncvptFHrfOP59rzmMFSpRPeo5bQrqgWtjrHXMLDcy4amHiZU7nkQXCrzYX8XcdX
	N19xsn3sp1ohMfscwCug8VEskdIAr6QP/44nsU82/YP88i4mDXoD/kW++2wOrbg7v2SGcX2n1FE
	vwouxdnGmuwKNald00hDwjNmSguMcaZf8+7nD/+t+Gle4aIeJluTJPhXX5gJb20UroW1MQ8pv7n
	5j8D34br/Xi0XdrRRgsV/JRM/2k2y4tmFw6tGU8y4kUyaPItbYFrIqlVWxdZTbiy8IHZIyvMGc1
	1qJpID9Ab4LHUTSBTb988ZLeoznVcScmr8/3kG/U3w==
X-Google-Smtp-Source: AGHT+IElLRyBSSFsvDLttv+1rxbirlHss1/zCBNTWvitDc/Y1ed9oUs4kNSXL7wHp3+sai4oSrFAlg==
X-Received: by 2002:a17:907:96a7:b0:aa6:2c18:aaa2 with SMTP id a640c23a62f3a-ab2ab73e7dbmr2340049566b.27.1736879362392;
        Tue, 14 Jan 2025 10:29:22 -0800 (PST)
Date: Tue, 14 Jan 2025 19:29:21 +0100
From: Andrew Jones <ajones@ventanamicro.com>
To: Valentin Schneider <vschneid@redhat.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org, 
	virtualization@lists.linux.dev, linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev, 
	linux-riscv@lists.infradead.org, linux-perf-users@vger.kernel.org, xen-devel@lists.xenproject.org, 
	kvm@vger.kernel.org, linux-arch@vger.kernel.org, rcu@vger.kernel.org, 
	linux-hardening@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, 
	bpf@vger.kernel.org, bcm-kernel-feedback-list@broadcom.com, 
	Juergen Gross <jgross@suse.com>, Ajay Kaher <ajay.kaher@broadcom.com>, 
	Alexey Makhalov <alexey.amakhalov@broadcom.com>, Russell King <linux@armlinux.org.uk>, 
	Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, 
	Huacai Chen <chenhuacai@kernel.org>, WANG Xuerui <kernel@xen0n.name>, 
	Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, 
	Albert Ou <aou@eecs.berkeley.edu>, Thomas Gleixner <tglx@linutronix.de>, 
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, 
	Dave Hansen <dave.hansen@linux.intel.com>, "H. Peter Anvin" <hpa@zytor.com>, 
	Peter Zijlstra <peterz@infradead.org>, Arnaldo Carvalho de Melo <acme@kernel.org>, 
	Namhyung Kim <namhyung@kernel.org>, Mark Rutland <mark.rutland@arm.com>, 
	Alexander Shishkin <alexander.shishkin@linux.intel.com>, Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>, 
	Adrian Hunter <adrian.hunter@intel.com>, "Liang, Kan" <kan.liang@linux.intel.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Josh Poimboeuf <jpoimboe@kernel.org>, 
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>, Sean Christopherson <seanjc@google.com>, 
	Paolo Bonzini <pbonzini@redhat.com>, Andy Lutomirski <luto@kernel.org>, Arnd Bergmann <arnd@arndb.de>, 
	Frederic Weisbecker <frederic@kernel.org>, "Paul E. McKenney" <paulmck@kernel.org>, 
	Jason Baron <jbaron@akamai.com>, Steven Rostedt <rostedt@goodmis.org>, 
	Ard Biesheuvel <ardb@kernel.org>, Neeraj Upadhyay <neeraj.upadhyay@kernel.org>, 
	Joel Fernandes <joel@joelfernandes.org>, Josh Triplett <josh@joshtriplett.org>, 
	Boqun Feng <boqun.feng@gmail.com>, Uladzislau Rezki <urezki@gmail.com>, 
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>, Lai Jiangshan <jiangshanlai@gmail.com>, 
	Zqiang <qiang.zhang1211@gmail.com>, Juri Lelli <juri.lelli@redhat.com>, 
	Clark Williams <williams@redhat.com>, Yair Podemsky <ypodemsk@redhat.com>, 
	Tomas Glozar <tglozar@redhat.com>, Vincent Guittot <vincent.guittot@linaro.org>, 
	Dietmar Eggemann <dietmar.eggemann@arm.com>, Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>, 
	Kees Cook <kees@kernel.org>, Andrew Morton <akpm@linux-foundation.org>, 
	Christoph Hellwig <hch@infradead.org>, Shuah Khan <shuah@kernel.org>, 
	Sami Tolvanen <samitolvanen@google.com>, Miguel Ojeda <ojeda@kernel.org>, 
	Alice Ryhl <aliceryhl@google.com>, "Mike Rapoport (Microsoft)" <rppt@kernel.org>, 
	Samuel Holland <samuel.holland@sifive.com>, Rong Xu <xur@google.com>, 
	Nicolas Saenz Julienne <nsaenzju@redhat.com>, Geert Uytterhoeven <geert@linux-m68k.org>, 
	Yosry Ahmed <yosryahmed@google.com>, "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>, 
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>, Jinghao Jia <jinghao7@illinois.edu>, 
	Luis Chamberlain <mcgrof@kernel.org>, Randy Dunlap <rdunlap@infradead.org>, 
	Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: Re: [PATCH v4 10/30] riscv/paravirt: Mark pv_steal_clock static call
 as __ro_after_init
Message-ID: <20250114-7fc0ed577ee91b6813f92806@orel>
References: <20250114175143.81438-1-vschneid@redhat.com>
 <20250114175143.81438-11-vschneid@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250114175143.81438-11-vschneid@redhat.com>

On Tue, Jan 14, 2025 at 06:51:23PM +0100, Valentin Schneider wrote:
> The static call is only ever updated in:
> 
>   __init pv_time_init()
>   __init xen_time_setup_guest()
> 
> so mark it appropriately as __ro_after_init.
> 
> Signed-off-by: Valentin Schneider <vschneid@redhat.com>
> ---
>  arch/riscv/kernel/paravirt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/riscv/kernel/paravirt.c b/arch/riscv/kernel/paravirt.c
> index fa6b0339a65de..dfe8808016fd8 100644
> --- a/arch/riscv/kernel/paravirt.c
> +++ b/arch/riscv/kernel/paravirt.c
> @@ -30,7 +30,7 @@ static u64 native_steal_clock(int cpu)
>  	return 0;
>  }
>  
> -DEFINE_STATIC_CALL(pv_steal_clock, native_steal_clock);
> +DEFINE_STATIC_CALL_RO(pv_steal_clock, native_steal_clock);
>  
>  static bool steal_acc = true;
>  static int __init parse_no_stealacc(char *arg)
> -- 
> 2.43.0
>

Reviewed-by: Andrew Jones <ajones@ventanamicro.com>


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 18:57:38 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 18:57:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872002.1282969 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXm6O-0007rw-Ba; Tue, 14 Jan 2025 18:57:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872002.1282969; Tue, 14 Jan 2025 18:57:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXm6O-0007rp-90; Tue, 14 Jan 2025 18:57:24 +0000
Received: by outflank-mailman (input) for mailman id 872002;
 Tue, 14 Jan 2025 18:57:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=dohy=UG=amd.com=ayan.kumar.halder@srs-se1.protection.inumbo.net>)
 id 1tXm6N-0007qS-EN
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 18:57:23 +0000
Received: from NAM02-DM3-obe.outbound.protection.outlook.com
 (mail-dm3nam02on2061a.outbound.protection.outlook.com
 [2a01:111:f403:2405::61a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 615f1a77-d2a9-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 19:57:20 +0100 (CET)
Received: from BN9PR03CA0727.namprd03.prod.outlook.com (2603:10b6:408:110::12)
 by SN7PR12MB8026.namprd12.prod.outlook.com (2603:10b6:806:34b::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8335.18; Tue, 14 Jan
 2025 18:57:15 +0000
Received: from BN2PEPF000055DE.namprd21.prod.outlook.com
 (2603:10b6:408:110:cafe::fc) by BN9PR03CA0727.outlook.office365.com
 (2603:10b6:408:110::12) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8335.18 via Frontend Transport; Tue,
 14 Jan 2025 18:57:15 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN2PEPF000055DE.mail.protection.outlook.com (10.167.245.8) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8377.0 via Frontend Transport; Tue, 14 Jan 2025 18:57:15 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 14 Jan
 2025 12:57:14 -0600
Received: from xcbayankuma40.xilinx.com (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via
 Frontend Transport; Tue, 14 Jan 2025 12:57:13 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 615f1a77-d2a9-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Mmr8MXbAwENZkyKTHNs0pPPXdBqwvAiipm1hKGeEA1vI/hG86JUZArI/QNV9S5X+RkoliLqskoKk1mBtcQ7CRgIZIqjPyY2YIo74mrjSSezZ/RJ11YA0wPXee/kZHAB9DfAdI1pjYvj9aNJG/e6/nL/tiLZYMAznadLHdcnHInuD3VpZZaxADc/fRNN7oKWrOq7JLKPctUAPDdaWvt9xN4KnNbAniALMH7fzNCZ5h0+m6PCctO3xJvMVpQQLVIQvEfnqDI61azP2n7J6rHBqHcWAFRwrrqQTjMreRO6V3/RIWP3RibzRsdO0p6xIzyxhm9q0AQF9sWjDMdJor6wIvw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=KSX8u7kgRxqQsAkDUZACV08DYvo5axEZDtDDpGJj2EM=;
 b=NFDJzhLo4s1tPwKuy05hg34DSwjKsUF1bGeaqYl/M5R4beUV88U8jK93c0gh5LYUD/63ACuG0KiV6SY3Ph7QV5UAeXKrFr4OxavgxNT9vUoaA2Q4xBFUcaKkARbpBsJ8sqJZchpioKz8qLFsUkkgHF6nNONeyOlDpgrQTlafaPgnMbM5oIQ0c19xj2BWy/2s+24Ndik1lydaSmH4u4yXPENmEV16LIKxQEA0XTFzV7JRZtCtYTqmIGIkXxmjoZRwBz89uee63ju6bO1VWQzZADRiq0LoKZEamLjuEX6iPuudXphCyRRaqlI04WrdyFNyWKDjinFInOWTWjubai+M/w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=KSX8u7kgRxqQsAkDUZACV08DYvo5axEZDtDDpGJj2EM=;
 b=wqijbo724tPOqmL2+LXgPtL36BHyrgvCCaTj0AXK3npw5pG4gCL+dmjRLgKIrB4FEgmctcK/iOyN7LtiokkgjBHaqLQp9QHyjYgMLpA+Zzmnouf0unrSNAykVVt758TbmuwWgYlIDkXF82gYiIYM1E3lHPWOIn20S5wiDwh1mjs=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
To: <xen-devel@lists.xenproject.org>
CC: Ayan Kumar Halder <ayan.kumar.halder@amd.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Bertrand Marquis <bertrand.marquis@arm.com>,
	"Michal Orzel" <michal.orzel@amd.com>, Artem Mygaiev <artem_mygaiev@epam.com>
Subject: [PATCH] docs: fusa: Fix OFT tags for the design requirements
Date: Tue, 14 Jan 2025 18:57:07 +0000
Message-ID: <20250114185707.3376960-1-ayan.kumar.halder@amd.com>
X-Mailer: git-send-email 2.25.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB04.amd.com: ayan.kumar.halder@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN2PEPF000055DE:EE_|SN7PR12MB8026:EE_
X-MS-Office365-Filtering-Correlation-Id: 81d26bbe-d154-4021-4151-08dd34cd42e3
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|82310400026|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?JMCcfBsQ2p8gbpaMXlDSjjsROivEFU2jQ2RrOE1IZO35vxA1RIWPl0ybxEEY?=
 =?us-ascii?Q?+7g+t4KeiblSolVD3Khxwz78LpMjTz09mqQIVsyroql9qBwZt/qxVcxAVS/q?=
 =?us-ascii?Q?N5frd/3jTIf0+OvDF/KyMFcQtLs/+a1ieq/U8sTQ4Twap5AKSjVZgfLXTGcB?=
 =?us-ascii?Q?iqPhlcMyBi13ym91XGQZZizcQH0h5NI+KBK+97BiiC9Brnlk4ZKEpmHPjxnW?=
 =?us-ascii?Q?nXgek6GdDO5a8D3fufhBxGJPkfRhLugOeDbs8U0IlKdVCFh/BEDyLaRUwErC?=
 =?us-ascii?Q?cgNnL3Une7Bs8g0OpA2IFw2sLmHAaSK+wtehmEFcGrb8dY4j7q2nERKLBw9V?=
 =?us-ascii?Q?pxVin4dpCbVX+5sAeUz52G+IoFU52v55ORi0Qz82f0zJficxUqVZhsYgh+y4?=
 =?us-ascii?Q?pxDR5vSgwfzs2S/JA1ypjOFQh6Vqu87tB8SxUYpRumdyGSuLOdZEBz+B610d?=
 =?us-ascii?Q?St0lUj0F7Cap1CyJsrhwNgNDtWynpqOaBwlWS9RAiPQsS3KCZNOfCTt5xYp4?=
 =?us-ascii?Q?LOfxr20uo6F18CQ49eGCE1AbgH+6ddEcgTgeYoCn3oUU+jtNf0qt34ZEzyQ/?=
 =?us-ascii?Q?xW6y3M+t6WbvOElwmk9zdvUSBSC9HI95x7ynXvjEYbzBM2Lj7S2J0dgVlNZ3?=
 =?us-ascii?Q?Sk9w+PwjsPK3SZ7GXIVCqlVwwSdPDFeqRUaeXs/Wi+vu61nsOcTrYnS/TKRX?=
 =?us-ascii?Q?D5cB30cNYcSUHq4I8XtSLT/qwdkCbDuU0+ckRXAjuntZB/rdIQp3skIOvaYa?=
 =?us-ascii?Q?fyd+tuMt6kNYHMXOM6891O65QI9Zz5VEAkGaGGOKzt0oF2C3WJzzlsrXfsuZ?=
 =?us-ascii?Q?/KeitTWTQH3Y2CrGodsHjmAr4vtN4C1rzCCiqw3NtyO24OghtzhPUutj1vnO?=
 =?us-ascii?Q?3sqJrrXG7Pxi4kM/66ax+pdF0JuvXGP/zhEqEN00pqqkB/k3RMtJSZYpv4Vz?=
 =?us-ascii?Q?0WcZkMgtp/la8zO3JQ0+VCblLAIw9+OE9Mh+AImS3N4DDh0PHBMNflMN02vl?=
 =?us-ascii?Q?Rs7sQGhYvIQXLVBQT8wmal3gOxrqVOrr8DRZksUJAXKR4To1TAvPmPa9wwCk?=
 =?us-ascii?Q?R5rowpZPOLHoEVuMnZP8WjjTR9sROirx6i9M+vBYrhypi9LwXap7yFTewxT0?=
 =?us-ascii?Q?2pdRgpFNprFLizcnn9QHG7X8ZlKrcjhXbzjBQHAHuskIBN7zd4XHqVZPhwbh?=
 =?us-ascii?Q?kAj5KmO5eXpwi6McPAqDnwMN547b0nhfMJ7sWvCcS/o3Ki8LyCCjVsLOlgE8?=
 =?us-ascii?Q?whvJ/5hbrc4LSobbvH90/Resrpnb5UD36bdU83V6Jy6LujBpZTxUHjc7L7wU?=
 =?us-ascii?Q?2XLMGZ4gqsQL8XUoZnnEFqRXTgTPrgxBx2ffdfQ/PAv9mVBongP5+81+S59g?=
 =?us-ascii?Q?vbZplHcJpBDZboN/2ZVgb7T+K4dFT6b+q3ApjA12ecQyR1phI5qbfyPyTHGT?=
 =?us-ascii?Q?f67OaaJVMA82/EHApTb/WWgEk8Iql05J?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(376014)(82310400026)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jan 2025 18:57:15.0983
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 81d26bbe-d154-4021-4151-08dd34cd42e3
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN2PEPF000055DE.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB8026

The OFT tags for the design requirements are updated.

Fixes: b9f9b396452 ("docs: fusa: Add dom0less domain configuration requirements")
Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
---
 .../reqs/design-reqs/arm64/generic-timer.rst  | 16 +++++-----
 .../fusa/reqs/design-reqs/arm64/sbsa-uart.rst | 30 +++++++++----------
 2 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/docs/fusa/reqs/design-reqs/arm64/generic-timer.rst b/docs/fusa/reqs/design-reqs/arm64/generic-timer.rst
index 9d2a5a8085..745e755638 100644
--- a/docs/fusa/reqs/design-reqs/arm64/generic-timer.rst
+++ b/docs/fusa/reqs/design-reqs/arm64/generic-timer.rst
@@ -21,7 +21,7 @@ Comments:
 Domains can detect the presence of the Generic Timer device tree node.
 
 Covers:
- - `XenProd~emulated_timer~1`
+ - `XenProd~arm64_emulated_timer~1`
 
 Read system counter frequency
 -----------------------------
@@ -37,7 +37,7 @@ Rationale:
 Comments:
 
 Covers:
- - `XenProd~emulated_timer~1`
+ - `XenProd~arm64_emulated_timer~1`
 
 Access CNTKCTL_EL1 system register from a domain
 ------------------------------------------------
@@ -53,7 +53,7 @@ Rationale:
 Comments:
 
 Covers:
- - `XenProd~emulated_timer~1`
+ - `XenProd~arm64_emulated_timer~1`
 
 Access virtual timer from a domain
 ----------------------------------
@@ -69,7 +69,7 @@ Rationale:
 Comments:
 
 Covers:
- - `XenProd~emulated_timer~1`
+ - `XenProd~arm64_emulated_timer~1`
 
 Access physical timer from a domain
 -----------------------------------
@@ -85,7 +85,7 @@ Rationale:
 Comments:
 
 Covers:
- - `XenProd~emulated_timer~1`
+ - `XenProd~arm64_emulated_timer~1`
 
 Trigger the virtual timer interrupt from a domain
 -------------------------------------------------
@@ -101,7 +101,7 @@ Rationale:
 Comments:
 
 Covers:
- - `XenProd~emulated_timer~1`
+ - `XenProd~arm64_emulated_timer~1`
 
 Trigger the physical timer interrupt from a domain
 --------------------------------------------------
@@ -117,7 +117,7 @@ Rationale:
 Comments:
 
 Covers:
- - `XenProd~emulated_timer~1`
+ - `XenProd~arm64_emulated_timer~1`
 
 Assumption of Use on the Platform
 =================================
@@ -139,7 +139,7 @@ While there is a provision to get this value by reading the "clock-frequency"
 dt property [2], the use of this property is strongly discouraged.
 
 Covers:
- - `XenProd~emulated_timer~1`
+ - `XenProd~arm64_emulated_timer~1`
 
 [1] Arm Architecture Reference Manual for A-profile architecture, Chapter 11
 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
diff --git a/docs/fusa/reqs/design-reqs/arm64/sbsa-uart.rst b/docs/fusa/reqs/design-reqs/arm64/sbsa-uart.rst
index 89598fa8a5..9aaf081f16 100644
--- a/docs/fusa/reqs/design-reqs/arm64/sbsa-uart.rst
+++ b/docs/fusa/reqs/design-reqs/arm64/sbsa-uart.rst
@@ -21,7 +21,7 @@ Comments:
 Domains can detect the presence of the SBSA UART device tree node.
 
 Covers:
- - `XenProd~emulated_uart~1`
+ - `XenProd~arm64_emulated_uart~1`
 
 Transmit data in software polling mode
 --------------------------------------
@@ -36,7 +36,7 @@ Rationale:
 Comments:
 
 Covers:
- - `XenProd~emulated_uart~1`
+ - `XenProd~arm64_emulated_uart~1`
 
 Transmit data in interrupt driven mode
 --------------------------------------
@@ -51,7 +51,7 @@ Rationale:
 Comments:
 
 Covers:
- - `XenProd~emulated_uart~1`
+ - `XenProd~arm64_emulated_uart~1`
 
 Receive data in software polling mode
 -------------------------------------
@@ -66,7 +66,7 @@ Rationale:
 Comments:
 
 Covers:
- - `XenProd~emulated_uart~1`
+ - `XenProd~arm64_emulated_uart~1`
 
 Receive data in interrupt driven mode
 -------------------------------------
@@ -81,7 +81,7 @@ Rationale:
 Comments:
 
 Covers:
- - `XenProd~emulated_uart~1`
+ - `XenProd~arm64_emulated_uart~1`
 
 Access UART data register
 -------------------------
@@ -96,7 +96,7 @@ Rationale:
 Comments:
 
 Covers:
- - `XenProd~emulated_uart~1`
+ - `XenProd~arm64_emulated_uart~1`
 
 Access UART receive status register
 -----------------------------------
@@ -111,7 +111,7 @@ Rationale:
 Comments:
 
 Covers:
- - `XenProd~emulated_uart~1`
+ - `XenProd~arm64_emulated_uart~1`
 
 Access UART flag register
 -------------------------
@@ -126,7 +126,7 @@ Rationale:
 Comments:
 
 Covers:
- - `XenProd~emulated_uart~1`
+ - `XenProd~arm64_emulated_uart~1`
 
 Access UART mask set/clear register
 -----------------------------------
@@ -141,7 +141,7 @@ Rationale:
 Comments:
 
 Covers:
- - `XenProd~emulated_uart~1`
+ - `XenProd~arm64_emulated_uart~1`
 
 Access UART raw interrupt status register
 -----------------------------------------
@@ -156,7 +156,7 @@ Rationale:
 Comments:
 
 Covers:
- - `XenProd~emulated_uart~1`
+ - `XenProd~arm64_emulated_uart~1`
 
 Access UART masked interrupt status register
 --------------------------------------------
@@ -171,7 +171,7 @@ Rationale:
 Comments:
 
 Covers:
- - `XenProd~emulated_uart~1`
+ - `XenProd~arm64_emulated_uart~1`
 
 Access UART interrupt clear register
 ------------------------------------
@@ -186,7 +186,7 @@ Rationale:
 Comments:
 
 Covers:
- - `XenProd~emulated_uart~1`
+ - `XenProd~arm64_emulated_uart~1`
 
 Receive UART TX interrupt
 -------------------------
@@ -202,7 +202,7 @@ Rationale:
 Comments:
 
 Covers:
- - `XenProd~emulated_uart~1`
+ - `XenProd~arm64_emulated_uart~1`
 
 Receive UART RX interrupt reception
 -----------------------------------
@@ -218,7 +218,7 @@ Rationale:
 Comments:
 
 Covers:
- - `XenProd~emulated_uart~1`
+ - `XenProd~arm64_emulated_uart~1`
 
 [1] Arm Base System Architecture, chapter B
-[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt
\ No newline at end of file
+[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 19:50:34 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 19:50:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872017.1282979 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXmvk-000399-6J; Tue, 14 Jan 2025 19:50:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872017.1282979; Tue, 14 Jan 2025 19:50:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXmvk-000392-3K; Tue, 14 Jan 2025 19:50:28 +0000
Received: by outflank-mailman (input) for mailman id 872017;
 Tue, 14 Jan 2025 19:50:26 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=dohy=UG=amd.com=ayan.kumar.halder@srs-se1.protection.inumbo.net>)
 id 1tXmvi-00038w-Q8
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 19:50:26 +0000
Received: from NAM02-BN1-obe.outbound.protection.outlook.com
 (mail-bn1nam02on20607.outbound.protection.outlook.com
 [2a01:111:f403:2407::607])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id cacb52ec-d2b0-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 20:50:24 +0100 (CET)
Received: from BL0PR05CA0016.namprd05.prod.outlook.com (2603:10b6:208:91::26)
 by CY8PR12MB8244.namprd12.prod.outlook.com (2603:10b6:930:72::7) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8335.18; Tue, 14 Jan
 2025 19:50:18 +0000
Received: from BN3PEPF0000B36F.namprd21.prod.outlook.com
 (2603:10b6:208:91:cafe::97) by BL0PR05CA0016.outlook.office365.com
 (2603:10b6:208:91::26) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8356.13 via Frontend Transport; Tue,
 14 Jan 2025 19:50:18 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BN3PEPF0000B36F.mail.protection.outlook.com (10.167.243.166) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8377.0 via Frontend Transport; Tue, 14 Jan 2025 19:50:16 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 14 Jan
 2025 13:50:15 -0600
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 14 Jan
 2025 13:50:15 -0600
Received: from xcbayankuma40.xilinx.com (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via
 Frontend Transport; Tue, 14 Jan 2025 13:50:14 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: cacb52ec-d2b0-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=d/d3zzxAjJ9UW6CfVzp2wm2rmFdyP2YSZSkxxi7myjWl8xP1c7ybo6ZlGx3wajEVq70Uv/Ryg6r/pUN6enEk86llOPLIiYHr55B+/Us9vXYqZO8KpU+Tg6anuRTN0zzN9b5zLPqmVjVXHA6+Cfdkb+dkAe7B2NxmMfj3a7WS8ki8vTOun8vNRICyPB7/A/3WPNwfBE385ZyrMA3Qs66Axa4wQ0zN2j2akn06QmV5aY5nP3saP8LLrgMe+FxWLfY/2BaUP4Igxe0T6Yc4Hbq+bvSMyTEewUZabU/mA1IbYUInpn8iOHNNhXxs5euPkxQp4Twgh0VYtg7dSqIn+fYMxA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=2/7ezLuGnWQStEHWeolIPlkR+XtMyUq4aP0dO47yG0w=;
 b=KMM721HISwLkKlXTdLf0kaAIszZ7CF9ArsCkcroaEOppLVWlhvpj4Rb4mPyMSrfSBmI/k08mcvyI6LG5hOE5e/LCXQouj7LNgXVThJXycbdJuHs2MztPoABVh3LRc8MkebzwLCn8YVSvsjAFP6x5hq3Ul2H8i7rct0C1s6cZCZhjsKKXcyaTk9QAf2c/D4caMJC75gLlpYUSYLKSc4QvGHs7StoDRArTlxWDg2hrWVD2rHWpLuOTTE4KOPcebijbLHij45IVAabS//GSTGUb6hpFJBMudUD4s18EDR4vDvFevEn+UBnelkJ5TCxTW3RiFbEinVhKi+mYHmMI+o5wnA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=2/7ezLuGnWQStEHWeolIPlkR+XtMyUq4aP0dO47yG0w=;
 b=vBN9KWJFb69PAIL2C4MVgujImd9HGKq01EoV2p7F5npqyDafzR6soLgPC05RBZJrVc8hsNRCJ3t1sVcfpiane502qe2gtywMELyK7bFa/xL7Oy8Vot7RAGTPss8S/nu6ycUidJ8WktV5pzaGZcIRI8xaApJ9TCgTQuEKM1log88=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
From: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
To: <xen-devel@lists.xenproject.org>
CC: Ayan Kumar Halder <ayan.kumar.halder@amd.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Bertrand Marquis <bertrand.marquis@arm.com>, Michal
 Orzel <michal.orzel@amd.com>, Artem Mygaiev <artem_mygaiev@epam.com>
Subject: [PATCH v1 1/2] docs: fusa: Define the requirements for XEN_VERSION hypercall.
Date: Tue, 14 Jan 2025 19:50:09 +0000
Message-ID: <20250114195010.3409094-1-ayan.kumar.halder@amd.com>
X-Mailer: git-send-email 2.25.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB05.amd.com: ayan.kumar.halder@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN3PEPF0000B36F:EE_|CY8PR12MB8244:EE_
X-MS-Office365-Filtering-Correlation-Id: 979af28c-05ac-44d7-e768-08dd34d4ab4c
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|36860700013|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?L/PnU4/BOd7XD689euvjLR8sD1xefta5ic17lCRAIfuDyfdpjIwJuxIqDx3p?=
 =?us-ascii?Q?9WvkuP3MI+EIsV+kjR/L7QjYkQizkKpaVHR4PuFztzeip+ggXbbrHLrzDWNV?=
 =?us-ascii?Q?kCcqWpEdlfC6XC7A4FdOVamnbaJeImbpaC2Y0qHn5JLciHdXYPJ09f8a5rHS?=
 =?us-ascii?Q?ZDk6wh20TDYpYzF2jmhpuQlG2GIg+hDtQSo9c14lbxcMhzG1niDXLjXHVX1F?=
 =?us-ascii?Q?jkmj800SUBJmwg+9knJVrAKI/xHo3lo9YgH2+kYaGN7eq0w9eD4Km/MdAIoj?=
 =?us-ascii?Q?6HxM/nvdK1//SrArNZ1mUwHDpjHe8EqfgPmf/+gmpnkMOvOApA4OGsCVxq81?=
 =?us-ascii?Q?U50OGwKzC7+OziTDlmLnEmpRkxiOSyGIVGOxoF6Xv1P1iUAlfOJJWCQv2d+A?=
 =?us-ascii?Q?mOW4SqtOLVHie9tTdwTRdEnDgu3STC9clZhFWv89XY9dmdpPwNM2i2TrKEKr?=
 =?us-ascii?Q?0ZAtRFAIAm1jg22DXtUJRwD5ecwEIdXlSA5r4Z43X/8xeZSbwu5BWsPn8Tf5?=
 =?us-ascii?Q?XWhcblDun+ZI0YzhIEknUhqb6hf2UdybPzH3gQjd+EWRLLsn4drJ/anid4gL?=
 =?us-ascii?Q?hI8QV0wD7sWlxC7wJUgnNzxKfbbff/IVG1towHbtqxyPrj1aQ47++1E+TN7A?=
 =?us-ascii?Q?jSUzFgXmu4OUzNog8G2YAMx01lwMSkDst3GazGaJsn2vecyBd3kOm1eYylXU?=
 =?us-ascii?Q?Rx4oOGQb/5jwnonTkXEmzXX45zAcUA+5syOYZfffPAMaA8yTi/JTr56qIV3G?=
 =?us-ascii?Q?LvmXvwsZ/9C+Vzm/dx9+evrMHrYta+KPNV2Ag6AcFuSvFXMUfJFGj3Pfo1dZ?=
 =?us-ascii?Q?qvgj68bAnAEjuH0aSI8G49lQds+woGcErcDLt6OUtAWhkHhJdaGe96Tu8SD+?=
 =?us-ascii?Q?TfweE2sVbYBH6nUW0ziyxpYio34uOB7RBrM4I0mEDOq1LsXBk0emVPauUurP?=
 =?us-ascii?Q?Y1VNSfBOtzW+aODEyJHVtC5oHaRJba2fQWsBQkoMGkpz7ofh6bJvROVBD0nV?=
 =?us-ascii?Q?eZmfAcGTPGNtgoHemkSi2ENwrWiIzs0AwS0Ccl+30XsWq/nRwQFV6/Yuf4lK?=
 =?us-ascii?Q?EJXKubQAdOl2XJfI3z5IJ1Ozq/1nETA3AFAsS9ncMWjKfo0LkZSeHn9Tx006?=
 =?us-ascii?Q?WRC4+3pAcsvOU6ym+1JzTm25THXCkbt6hO6EGiqx5AarbywceK5/NnmuZ/zP?=
 =?us-ascii?Q?bYfqLI1Y83ytubjvK/q/cIKp8EN/ixXP46bB8fGvlHObDKH8Ka4kjBtsJoeN?=
 =?us-ascii?Q?QxA72Enuw0lCwLYpUn7S7PI0QCtU/I+HSrjU7JdVWZKQAihyRnFEuWE75i8i?=
 =?us-ascii?Q?vZ4fKyDkNqzd7VorstTnawUJc39IF0D1wy6EAy+5k9HudGQBorYn/DLJCsn1?=
 =?us-ascii?Q?2QIPj4ZDGQ3gDMgvzw2VHrGDX82BvnvG4ymf5arVaY+/5uVmsIJufTQRR4If?=
 =?us-ascii?Q?hZuDkb6kjz0=3D?=
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:(13230040)(82310400026)(36860700013)(1800799024)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jan 2025 19:50:16.6727
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 979af28c-05ac-44d7-e768-08dd34d4ab4c
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:
	BN3PEPF0000B36F.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB8244

In the current patch, we have defined the requirements which are common for
all the commands.

Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
---
 .../fusa/reqs/design-reqs/arm64/hypercall.rst | 52 ++++++++++++++++
 docs/fusa/reqs/index.rst                      |  2 +
 docs/fusa/reqs/market-reqs/reqs.rst           | 16 +++++
 .../reqs/product-reqs/version_hypercall.rst   | 61 +++++++++++++++++++
 4 files changed, 131 insertions(+)
 create mode 100644 docs/fusa/reqs/design-reqs/arm64/hypercall.rst
 create mode 100644 docs/fusa/reqs/product-reqs/version_hypercall.rst

diff --git a/docs/fusa/reqs/design-reqs/arm64/hypercall.rst b/docs/fusa/reqs/design-reqs/arm64/hypercall.rst
new file mode 100644
index 0000000000..66dbcc3026
--- /dev/null
+++ b/docs/fusa/reqs/design-reqs/arm64/hypercall.rst
@@ -0,0 +1,52 @@
+.. SPDX-License-Identifier: CC-BY-4.0
+
+Hypercall
+=========
+
+Instruction
+-----------
+
+`XenSwdgn~arm64_hyp_instr~1`
+
+Description:
+Domains shall use the Arm instruction 'hvc' to interact with Xen.
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenProd~version_hyp_first_param~1`
+ - `XenProd~version_hyp_second_param~1`
+
+Parameters
+----------
+
+`XenSwdgn~arm64_hyp_param~1`
+
+Description:
+Domains shall use register x0 to pass first parameter, x1 to pass second
+parameter and so on.
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenProd~version_hyp_first_param~1`
+ - `XenProd~version_hyp_second_param~1`
+
+Return value
+------------
+
+`XenSwdgn~arm64_ret_val~1`
+
+Description:
+Xen shall store the return value in x0 register.
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenProd~version_hyp_ret_val~1`
diff --git a/docs/fusa/reqs/index.rst b/docs/fusa/reqs/index.rst
index 1088a51d52..d8683edce7 100644
--- a/docs/fusa/reqs/index.rst
+++ b/docs/fusa/reqs/index.rst
@@ -10,5 +10,7 @@ Requirements documentation
    market-reqs/reqs
    product-reqs/reqs
    product-reqs/arm64/reqs
+   product-reqs/version_hypercall
    design-reqs/arm64/generic-timer
    design-reqs/arm64/sbsa-uart
+   design-reqs/arm64/hypercall
diff --git a/docs/fusa/reqs/market-reqs/reqs.rst b/docs/fusa/reqs/market-reqs/reqs.rst
index 2d297ecc13..0e29fe5362 100644
--- a/docs/fusa/reqs/market-reqs/reqs.rst
+++ b/docs/fusa/reqs/market-reqs/reqs.rst
@@ -79,3 +79,19 @@ Comments:
 
 Needs:
  - XenProd
+
+Version hypercall
+-----------------
+
+`XenMkt~version_hypercall~1`
+
+Description:
+Xen shall provide an interface for the domains to retrieve Xen's version, type
+and compilation information.
+
+Rationale:
+
+Comments:
+
+Needs:
+ - XenProd
diff --git a/docs/fusa/reqs/product-reqs/version_hypercall.rst b/docs/fusa/reqs/product-reqs/version_hypercall.rst
new file mode 100644
index 0000000000..fdb8da04e1
--- /dev/null
+++ b/docs/fusa/reqs/product-reqs/version_hypercall.rst
@@ -0,0 +1,61 @@
+.. SPDX-License-Identifier: CC-BY-4.0
+
+Version hypercall
+=================
+
+First Parameter
+---------------
+
+`XenProd~version_hyp_first_param~1`
+
+Description:
+Domain shall pass the first argument (as an integer) to denote the command
+number for the hypercall.
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenMkt~version_hypercall~1`
+
+Needs:
+ - XenSwdgn
+
+Second Parameter
+----------------
+
+`XenProd~version_hyp_second_param~1`
+
+Description:
+Domain shall pass the second argument as a pointer to buffer in guest memory.
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenMkt~version_hypercall~1`
+
+Needs:
+ - XenSwdgn
+
+Return Value
+------------
+
+`XenProd~version_hyp_ret_val~1`
+
+Description:
+Xen shall return 0 in case of success or one of the error codes as defined in
+https://man7.org/linux/man-pages/man3/errno.3.html.
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenMkt~version_hypercall~1`
+
+Needs:
+ - XenSwdgn
+
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 19:50:34 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 19:50:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872018.1282990 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXmvm-0003Pz-GD; Tue, 14 Jan 2025 19:50:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872018.1282990; Tue, 14 Jan 2025 19:50:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXmvm-0003Pq-DF; Tue, 14 Jan 2025 19:50:30 +0000
Received: by outflank-mailman (input) for mailman id 872018;
 Tue, 14 Jan 2025 19:50:29 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=dohy=UG=amd.com=ayan.kumar.halder@srs-se1.protection.inumbo.net>)
 id 1tXmvl-0003Ik-2m
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 19:50:29 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on20608.outbound.protection.outlook.com
 [2a01:111:f403:2416::608])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id cd46bc19-d2b0-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 20:50:27 +0100 (CET)
Received: from BL0PR05CA0017.namprd05.prod.outlook.com (2603:10b6:208:91::27)
 by CY8PR12MB7755.namprd12.prod.outlook.com (2603:10b6:930:87::8) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8335.18; Tue, 14 Jan
 2025 19:50:20 +0000
Received: from BN3PEPF0000B36F.namprd21.prod.outlook.com
 (2603:10b6:208:91:cafe::84) by BL0PR05CA0017.outlook.office365.com
 (2603:10b6:208:91::27) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8356.12 via Frontend Transport; Tue,
 14 Jan 2025 19:50:20 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BN3PEPF0000B36F.mail.protection.outlook.com (10.167.243.166) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8377.0 via Frontend Transport; Tue, 14 Jan 2025 19:50:20 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 14 Jan
 2025 13:50:19 -0600
Received: from xcbayankuma40.xilinx.com (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via
 Frontend Transport; Tue, 14 Jan 2025 13:50:19 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: cd46bc19-d2b0-11ef-a0e1-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=JTRYrwAzstKmWNEDBnY4lMxqq/ln7Xazc+qnPnQM7aJXjupOmkz5Y0lQbWUnKbLOmiFI70P0ufOq33XHyQaduEFvDemmGc5K3ZSzIZgppVphZCJ/WngkgjrFgEDo/pdHXqA2q754u8k9KCvCIuBTeIG7ZdWGrt0BCvq/OXmFe9Oc/R49Vj8qbfFUgiAMpmIbF3dt02198s4Ku/dKmqrHn5WqzjZmXe/PpewnqbeTLUCft+eDe5wHKpRLj/kG182EE7IBnI0dCP8Bf2UWbALi/PqDAePY9x398o7qLgrvAWoaAM4FgZBx/xd/D7OioAb4Aiw4gy1ORt1uq+If73n4mA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=4YxDwFIkH0z2drf37uvGHzceTBs7Yq/7eJMrWxhBsB8=;
 b=ib8cAeL6QVWRBvdIIyQnAVlFw9gzlSeRFy2FqMu9SloyGmnQ5V55uCKxGaj8FaxmRd+7EOItwQYQVJ0GRDUI+0veyIMxPR4mgRzi2nNG0rp6JMlJlgR9Ph4lnyY4NvJiHvpqrX+EyNVHkprXOBGNfwF+MmDFhdRV5gBR9WX3Gp0/mqvA1oxlqMsaXAEAR+z/p8rQRdVeMkSwn6DnOnyrgloluLO9Jjat/3r5PVvXo++c0S5qBUHeME07vnQP7njD9z0rqx85iRZNX8TTryv4ReXUfYj+BAWvj6769wvL7HrF604eG9UEBGCj18fXTOoMU/eClx0Qt4xiTbC6VZPTRA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=4YxDwFIkH0z2drf37uvGHzceTBs7Yq/7eJMrWxhBsB8=;
 b=FmgLWZIxNb+yzvAR+rYJBo18MdFN3x1G8HdJ7gT/jl1xAdvFFJSL1sSlDHPt65IglKmnW5D2o723mntrdKRSCJKfdN3EKsSQBx6s4b7yuwFCb4dfwsC6ZnMEQX4caL40ef9bL758T0ejz7gsQfYjnnlaVpmCAGhJgi0n6uzZzV4=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
From: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
To: <xen-devel@lists.xenproject.org>
CC: Ayan Kumar Halder <ayan.kumar.halder@amd.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Bertrand Marquis <bertrand.marquis@arm.com>,
	"Michal Orzel" <michal.orzel@amd.com>, Artem Mygaiev <artem_mygaiev@epam.com>
Subject: [PATCH v1 2/2] docs: fusa: Add the requirements for some of the commands of XEN_VERSION
Date: Tue, 14 Jan 2025 19:50:10 +0000
Message-ID: <20250114195010.3409094-2-ayan.kumar.halder@amd.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <20250114195010.3409094-1-ayan.kumar.halder@amd.com>
References: <20250114195010.3409094-1-ayan.kumar.halder@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB03.amd.com: ayan.kumar.halder@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN3PEPF0000B36F:EE_|CY8PR12MB7755:EE_
X-MS-Office365-Filtering-Correlation-Id: 3af46883-1f9d-4fad-cf38-08dd34d4ad5b
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|82310400026|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?SxfrybhYvG5AoSawq7ECrpwD35JIoXWcytXF0LzYhD1iF3t07QiBbFMyk5f5?=
 =?us-ascii?Q?70M9IEqP6Rcniih+ZVnmCNaKAQeklTmgRWmnePrZbm8bwSkYZdlHOAQadmKJ?=
 =?us-ascii?Q?c0Vjg1sLKAsCh5t2QF3ngUgQQ5B8L3QDXAcy12wjaAScIHRUazbFT4CwaUIP?=
 =?us-ascii?Q?3jvmwwEGLNhKdnZqkdvuRr/M1Cg9DAYFw8zuWy0EfMTjaq8YCvjQSbbj9Keh?=
 =?us-ascii?Q?4Nr80fvyQ2tqK62P/fse0dZ3MvPfxdbWI2f7/vYR4MnW7mIiYOufkKVeN6Ie?=
 =?us-ascii?Q?X7qHxwlSfWfHI1NB5ticAWgu8iG2lpRNNVZ/5qXMV/Vs2hvGQAs+1Gu6YUO1?=
 =?us-ascii?Q?QBVLqkuTUeBNcokL29KTfcFznlWkGnRzz9u2++8weo0VWmYahyUSnc7khUtD?=
 =?us-ascii?Q?geCi0ZTSMd3yRVD+zi8n51cb9prBVvU3r+Oc0+sqkEEI6VNOi0VHTOVVtKbV?=
 =?us-ascii?Q?9zz3nddYfdse4DPQVUk6Me3JkTC7Qxb5Waf9V+fhxDLoVZworYy1KJe2xcK3?=
 =?us-ascii?Q?E4a49b1Wbrc8ajgbehxv+NZmsahkjk5V8XUf3vZ5y6OVXofGFbZnOgR/QCpF?=
 =?us-ascii?Q?dkkGZoOTv4B4PQuoEDEzVj9bktgUGr9G9mduY+uzWk0Y/QwPmtCG+c/uqA42?=
 =?us-ascii?Q?27WoMLT9T1wNGn4wtKNlgEniQbD9k3X95NGvYQvmeizvB43t2Px1RikCtrDv?=
 =?us-ascii?Q?GNW1rLxQ8x4MUfqQoPQwKVFi5+mI+ppaitPesAb4I2re6fPZj1Ml3JJz9Sar?=
 =?us-ascii?Q?zGct226dcelXqM2rrnJf0uFBkqkV8YZ+lfzjdofoZV09psoWJbO/brvzoB+8?=
 =?us-ascii?Q?P3wu5QMtCktK05xOz4L/PKIbYLIAXxTuuoqYN6/K8KSSp737zXc8FG364k6Z?=
 =?us-ascii?Q?6p4usfuDlAJg521Win1XuFZsmVYObeuMdhpFcv7iYO3D7tby3RG70fnr6Fx4?=
 =?us-ascii?Q?zrmQPw8eoT1XyECmuLYDcBP2CzOWI8bOLYM+kgMur7a7rU0uCoTGicP9wNet?=
 =?us-ascii?Q?oynTneeI4ZnSHAMkyGZqpdXCNxJJlSek63ibzJJKT+/srplpG683MMnWbRI7?=
 =?us-ascii?Q?ukUyfgGbubB06P8FHRfCgFlo4TywRMI02VK8UFhLiIkYYTgldnbrpcN7zZYV?=
 =?us-ascii?Q?qN4j1GNeGoKbPsQfUKdAwSt/kcgZftz4sXtYRm6PFl4QcaRAtArU7jiqCPoY?=
 =?us-ascii?Q?uu0abNwMAQGkWPF1lvG7a3sMsUnQjcFdS9jKsstu6QtR28DJy5wyghpN12cB?=
 =?us-ascii?Q?zT0hINDXgUwGDHjzvhOiEUiNG/TX4PorrgB6WfLP/X7sBOGdwhqNYFvkWD1X?=
 =?us-ascii?Q?hDKeQYHIqhMQFeag6xr6QDExlc7JhjL7UJx9wJQWsEmI7sD5rDgpnasJ0MRl?=
 =?us-ascii?Q?QZKfDGrB5GS3sYi8r7XbUSY2bSz0h/Hqz5XhPFpwDoODBHJD67e76o+gGB8O?=
 =?us-ascii?Q?RRm5VqJSG1481yQe1mb2CdhZ9k50QTDIcqdOKH/Z4d+B7Gg8jtoQ8+VdXeA4?=
 =?us-ascii?Q?10i95lIEMa/phfg=3D?=
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:(13230040)(1800799024)(376014)(82310400026)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jan 2025 19:50:20.1883
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 3af46883-1f9d-4fad-cf38-08dd34d4ad5b
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:
	BN3PEPF0000B36F.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7755

We have written the requirements for some of the commands of the XEN_VERSION
hypercall.

Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
---
 .../design-reqs/arm64/version_hypercall.rst   | 33 ++++++++
 .../reqs/design-reqs/version_hypercall.rst    | 65 +++++++++++++++
 docs/fusa/reqs/index.rst                      |  2 +
 .../reqs/product-reqs/version_hypercall.rst   | 82 +++++++++++++++++++
 4 files changed, 182 insertions(+)
 create mode 100644 docs/fusa/reqs/design-reqs/arm64/version_hypercall.rst
 create mode 100644 docs/fusa/reqs/design-reqs/version_hypercall.rst

diff --git a/docs/fusa/reqs/design-reqs/arm64/version_hypercall.rst b/docs/fusa/reqs/design-reqs/arm64/version_hypercall.rst
new file mode 100644
index 0000000000..1dad2b84c2
--- /dev/null
+++ b/docs/fusa/reqs/design-reqs/arm64/version_hypercall.rst
@@ -0,0 +1,33 @@
+.. SPDX-License-Identifier: CC-BY-4.0
+
+Capabilities
+------------
+
+`XenSwdgn~arm64_capabilities~1`
+
+Description:
+Xen shall have a internal constant string storing "xen-3.0-aarch64".
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenProd~version_hyp_capabilities_cmd~1`
+
+Capabilities AArch32
+--------------------
+
+`XenSwdgn~arm64_capabilities_aarch32~1`
+
+Description:
+Xen shall have a internal constant string storing "xen-3.0-armv7l" when it
+detects that the cpu is running in AArch32 mode.
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenProd~version_hyp_capabilities_cmd~1`
+
diff --git a/docs/fusa/reqs/design-reqs/version_hypercall.rst b/docs/fusa/reqs/design-reqs/version_hypercall.rst
new file mode 100644
index 0000000000..8bb7a66576
--- /dev/null
+++ b/docs/fusa/reqs/design-reqs/version_hypercall.rst
@@ -0,0 +1,65 @@
+.. SPDX-License-Identifier: CC-BY-4.0
+
+Version
+-------
+
+`XenSwdgn~version~1`
+
+Description:
+Xen shall have a internal constant storing the version number coming from the
+Makefile.
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenProd~version_hyp_version_cmd~1`
+
+Subversion
+----------
+
+`XenSwdgn~subversion~1`
+
+Description:
+Xen shall have a internal constant storing the sub version number coming from
+the Makefile.
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenProd~version_hyp_version_cmd~1`
+
+Extraversion
+------------
+
+`XenSwdgn~extraversion~1`
+
+Description:
+Xen shall have a internal constant string storing the extraversion coming from
+the build environment.
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenProd~version_hyp_extraversion_cmd~1`
+
+Changeset
+---------
+
+`XenSwdgn~changeset~1`
+
+Description:
+Xen shall have a internal constant string storing the date, time and git hash
+of the last change made to Xen's codebase.
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenProd~version_hyp_changeset_cmd~1`
diff --git a/docs/fusa/reqs/index.rst b/docs/fusa/reqs/index.rst
index d8683edce7..b85af19d19 100644
--- a/docs/fusa/reqs/index.rst
+++ b/docs/fusa/reqs/index.rst
@@ -14,3 +14,5 @@ Requirements documentation
    design-reqs/arm64/generic-timer
    design-reqs/arm64/sbsa-uart
    design-reqs/arm64/hypercall
+   design-reqs/arm64/version_hypercall
+   design-reqs/version_hypercall
diff --git a/docs/fusa/reqs/product-reqs/version_hypercall.rst b/docs/fusa/reqs/product-reqs/version_hypercall.rst
index fdb8da04e1..10bc7b6e87 100644
--- a/docs/fusa/reqs/product-reqs/version_hypercall.rst
+++ b/docs/fusa/reqs/product-reqs/version_hypercall.rst
@@ -59,3 +59,85 @@ Covers:
 Needs:
  - XenSwdgn
 
+Version command
+---------------
+
+`XenProd~version_hyp_version_cmd~1`
+
+Description:
+Xen shall provide a command (num 0) for  hypercall (num 17) to retrieve Xen's
+version in the domain's x0 register.
+
+Rationale:
+
+Comments:
+Xen version is composed of major and minor number.
+
+Covers:
+ - `XenMkt~version_hypercall~1`
+
+Needs:
+ - XenSwdgn
+
+Extraversion command
+--------------------
+
+`XenProd~version_hyp_extraversion_cmd~1`
+
+Description:
+Xen shall provide a command (num 1) for hypercall (num 17) to copy its
+extraversion in the domain's buffer.
+
+Rationale:
+
+Comments:
+Xen's extra version consists of a string passed with 'XEN_VENDORVERSION' command
+line parameter while building Xen.
+
+Covers:
+ - `XenMkt~version_hypercall~1`
+
+Needs:
+ - XenSwdgn
+
+Capabilities command
+--------------------
+
+`XenProd~version_hyp_capabilities_cmd~1`
+
+Description:
+Xen shall provide a command (num 3) for hypercall (num 17) to copy its
+capabilities to the domain's buffer.
+
+Rationale:
+
+Comments:
+Capabilities related information is represented by char[1024].
+For Arm64, the capabilities should contain "xen-3.0-aarch64" string.
+
+Covers:
+ - `XenMkt~version_hypercall~1`
+
+Needs:
+ - XenSwdgn
+
+Changeset command
+-----------------
+
+`XenProd~version_hyp_changeset_cmd~1`
+
+Description:
+Xen shall provide a command (num 4) for hypercall (num 17) to copy changeset
+to the domain's buffer.
+
+Rationale:
+
+Comments:
+Changeset is string denoting the date, time and git hash of the last change
+made to Xen's codebase.
+
+Covers:
+ - `XenMkt~version_hypercall~1`
+
+Needs:
+ - XenSwdgn
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Tue Jan 14 20:15:43 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 20:15:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872041.1282999 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXnJx-0000Pw-9c; Tue, 14 Jan 2025 20:15:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872041.1282999; Tue, 14 Jan 2025 20:15:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXnJx-0000Pp-6v; Tue, 14 Jan 2025 20:15:29 +0000
Received: by outflank-mailman (input) for mailman id 872041;
 Tue, 14 Jan 2025 20:15:27 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=tIyo=UG=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tXnJv-0000NL-6F
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 20:15:27 +0000
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com
 [2a00:1450:4864:20::336])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4921bd37-d2b4-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 21:15:23 +0100 (CET)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-4361c705434so42685065e9.3
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 12:15:23 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436e9e37d46sm185145725e9.25.2025.01.14.12.15.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 14 Jan 2025 12:15:22 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 4921bd37-d2b4-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736885723; x=1737490523; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=qvA3U4uXT67r8lnIiNLurU6RtyPs5q+KYerySYrGgb4=;
        b=CYdHOcYCJtuHr//GODCP45Y1Ff5Qkb4oRm5mExFcrubUyfW7YPU2mf6PmWh2rI3I/d
         VJ7ENYxseoQP90Lx/sKyJ4GT6mcSwQupicOu40oUuyCa9ycYxN4APmjFrU+dLge+aprq
         aCzoCKrAtDwf+QFhSKd0fbJVQuNQ4e+qs2f6o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736885723; x=1737490523;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=qvA3U4uXT67r8lnIiNLurU6RtyPs5q+KYerySYrGgb4=;
        b=IEF9aATpR96uU8K2/muggde3ML4QlRLBW0Ur0TL2sBo7OSf5pZ+DGjRWR5KH3UOquF
         CoijgmHoaEFRuJvxRUEeuqjHz2+Vn0kJR1Spr8oDCyjeMYjs8zIuJeLrX4LwucViyXSl
         qkZ3JfbFU2Rlze52ZYT3y1IrHrhunOVGhq+dlwloLtLw2Rf0V4QqA2qq2LEQ7OPk1uiI
         aES+QuXiuRvYdQVAcl6MZrjM++ZzSLgATsvCgKLbCdaDkJrA5XnzMiCHCpsXT/cqdd6n
         Nwq6eVmUdWOGMSvq4yit4CLulUSoyD83P8ikuh+616mNWzA+WhTt/F5dw92siruoB/uG
         Wdbg==
X-Forwarded-Encrypted: i=1; AJvYcCWd8F9kEU+BYujIkUawjmhjcdJF8Rmle9MjpmOnFQI3fW4FW/kEXXS2QkwzRP6iNTVxsSTxuST05yA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxuCP5qTCVHiwMdXGWe5EKNBVSL39Os8PzmLRJZi0202hYqhJpA
	PKHieUKSAjhoSN1oO6eoraOxDlHO+OFvFuBicRm8/CqtMx7tyfeTCqpF5qw3KSI=
X-Gm-Gg: ASbGncv65dJtKuffqSWNN8uHHYtqdutSUH64mAL9T6gEjSeA3/fzEvLaZ/B45HSUehD
	lvI+I7Ft08qVuOrANcwpCdNeP8dWwhNbAMIEDFXt83fdFHjbiK9uqI6NBoTBCvUb8by0hUEnBOf
	1hxjva94ZGGlfZ4iHDyZOzdXixCnzfR0imn2Q9IkH+RlQjCT/xA35uTBaT45TI+dOShT7PmhonJ
	xisBoG+/1FR6IWEynXutjb5XDYXVLSqmPx5Dv7LJIj1Eqogj0ckk5UkVV9Cp7nbI0QANJhBHvQk
	vtlRYXgyBh710W21X87X
X-Google-Smtp-Source: AGHT+IEe8K9GFenhmBXmR6QQlxjs+MiB0OffvKNqBEkcuBl6cjZ/v0v8/oC7jyxa1m4hfHmJsmirOA==
X-Received: by 2002:a05:600c:450d:b0:434:a711:ace4 with SMTP id 5b1f17b1804b1-436e26a9510mr256291775e9.17.1736885723032;
        Tue, 14 Jan 2025 12:15:23 -0800 (PST)
Message-ID: <9653ccc0-203a-4bec-ba79-57870ed08ea0@citrix.com>
Date: Tue, 14 Jan 2025 20:15:21 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 1/2] docs: fusa: Define the requirements for
 XEN_VERSION hypercall.
To: Ayan Kumar Halder <ayan.kumar.halder@amd.com>,
 xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>, Artem Mygaiev <artem_mygaiev@epam.com>
References: <20250114195010.3409094-1-ayan.kumar.halder@amd.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <20250114195010.3409094-1-ayan.kumar.halder@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 14/01/2025 7:50 pm, Ayan Kumar Halder wrote:
> diff --git a/docs/fusa/reqs/product-reqs/version_hypercall.rst b/docs/fusa/reqs/product-reqs/version_hypercall.rst
> new file mode 100644
> index 0000000000..fdb8da04e1
> --- /dev/null
> +++ b/docs/fusa/reqs/product-reqs/version_hypercall.rst
> @@ -0,0 +1,61 @@
> +Return Value
> +------------
> +
> +`XenProd~version_hyp_ret_val~1`
> +
> +Description:
> +Xen shall return 0 in case of success or one of the error codes as defined in
> +https://man7.org/linux/man-pages/man3/errno.3.html.

Xen's errors live in public/errno.h

They share a lot in common with Linux (for historical reasons), but they
are critically not Linux errnos because Xen supports OSes which aren't
Linux.  xenstored for example sends errors as text rather than numbers.

Also, that's not the return value ABI of __HYPERVISOR_xen_version.  Some
subops return a positive value instead of 0 on success.

And if you're wondering "hey, isn't that ambiguous in extreme cases",
yes it is.  Xen's hypercall API/ABI are a disaster.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 21:14:09 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 21:14:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872049.1283010 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXoEd-0007fH-FB; Tue, 14 Jan 2025 21:14:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872049.1283010; Tue, 14 Jan 2025 21:14:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXoEd-0007fA-BM; Tue, 14 Jan 2025 21:14:03 +0000
Received: by outflank-mailman (input) for mailman id 872049;
 Tue, 14 Jan 2025 21:14:02 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=eXvd=UG=flex--seanjc.bounces.google.com=3ltOGZwYKCZsN95IE7BJJBG9.7JHS9I-89Q9GGDNON.S9IKMJE97O.JMB@srs-se1.protection.inumbo.net>)
 id 1tXoEc-0007dq-R7
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 21:14:02 +0000
Received: from mail-pj1-x1049.google.com (mail-pj1-x1049.google.com
 [2607:f8b0:4864:20::1049])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 78f4ff90-d2bc-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 22:14:00 +0100 (CET)
Received: by mail-pj1-x1049.google.com with SMTP id
 98e67ed59e1d1-2ee9f66cb12so10679950a91.1
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 13:14:00 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 78f4ff90-d2bc-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20230601; t=1736889239; x=1737494039; darn=lists.xenproject.org;
        h=cc:to:from:subject:message-id:references:mime-version:in-reply-to
         :date:from:to:cc:subject:date:message-id:reply-to;
        bh=d9cRGGic7Te5o12Iwy1M3OB31drPOXRp+PHli2u04Fc=;
        b=AmmEf5wmUY4Q8eyjg0u0n+GempsHdqd743WDW2Ym8VrABy/52oRM6fRPF6yMV8wgUY
         q1bTqJ3e51I/cs0nid/dXUX1YQWlHptpoxJ50wUluMfziprPElQ08SkkQi88HqwA5/lV
         EixpOebsr2fHvjOdqHvdZxHbvuyZbocbiRv9tUtU9ftvk61DF8F+xwzMtg0OOfNwNhn9
         OjNEDRJOoAQL3Y6J9n3S1+XeqoUP5Kvw8WmWlVJKNzNp0UhsvvTkMjYhX3XGhlwkCMgn
         S59zudW/vS2RJjXByMsc4oLQhX07/3XQiNMXsU6oLPo27FewmqPWO0BcZ+nB/gZYQQeG
         Lk6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736889239; x=1737494039;
        h=cc:to:from:subject:message-id:references:mime-version:in-reply-to
         :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=d9cRGGic7Te5o12Iwy1M3OB31drPOXRp+PHli2u04Fc=;
        b=O3QtQcVQtYqQ1/5si7gNuGMWqBYqhBkYOAY+ViFiXdRTbIvA8NmVNz/Jy0W2Ca3Io7
         sfNTsjOAxhbAeSkHe3b7ceO9J8WvmasTAFkXta/Z5SraD7hQ5JLSOOH+DwkW+ORKdmdh
         OfIKSVTLp8RmuRoQ8ib++4bgy2YBQKtNnEeWDZKRVcEFCkqxMVag4klz+kVme1YOtit2
         9MXlZ01gO77nj5s3Cpo2VejV3PMjPT4AFRowxqb1xjSWMLPLKZfPaSRM3M/BQWhzJj1T
         0kRY8QsInHjgbsQEu3rMWTDxGNAy7ZPLQTTm5jUJsf23/q07amviG4rGNiIS6YApk0/Q
         //pQ==
X-Forwarded-Encrypted: i=1; AJvYcCXaD4bfaMBsS2NDT6/724QhpUSI0bJEE8/kFO9Wxio2RLFUqDtfqSiBl0TJO0Cnx3ZC65icPI24XCo=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxz7qfhp8obGxd5Ncc54J30Go2BIU4dOK4bmYnsZJQxdI2aTdBJ
	FKW5pqXePnBHW0QOy5YUG3f8cRV+bmW6hn+3XeuiTy6r3By/DKc5VKLNh0bh2k5NZ34MW5MSc4s
	A/A==
X-Google-Smtp-Source: AGHT+IFnD8IBYtaFLZfmn+yp8faKF4j5W1D2QQ93HaiFkyR3KITtNCKyHKA+6Vtw5k/ROipPB4Gea/5UJbQ=
X-Received: from pjbsn8.prod.google.com ([2002:a17:90b:2e88:b0:2f4:465d:5c61])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:1f8b:b0:2ee:bf84:4fe8
 with SMTP id 98e67ed59e1d1-2f548f1d44cmr36656404a91.30.1736889238866; Tue, 14
 Jan 2025 13:13:58 -0800 (PST)
Date: Tue, 14 Jan 2025 13:13:57 -0800
In-Reply-To: <20250114175143.81438-26-vschneid@redhat.com>
Mime-Version: 1.0
References: <20250114175143.81438-1-vschneid@redhat.com> <20250114175143.81438-26-vschneid@redhat.com>
Message-ID: <Z4bTlZkqihaAyGb4@google.com>
Subject: Re: [PATCH v4 25/30] context_tracking,x86: Defer kernel text patching IPIs
From: Sean Christopherson <seanjc@google.com>
To: Valentin Schneider <vschneid@redhat.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org, 
	virtualization@lists.linux.dev, linux-arm-kernel@lists.infradead.org, 
	loongarch@lists.linux.dev, linux-riscv@lists.infradead.org, 
	linux-perf-users@vger.kernel.org, xen-devel@lists.xenproject.org, 
	kvm@vger.kernel.org, linux-arch@vger.kernel.org, rcu@vger.kernel.org, 
	linux-hardening@vger.kernel.org, linux-mm@kvack.org, 
	linux-kselftest@vger.kernel.org, bpf@vger.kernel.org, 
	bcm-kernel-feedback-list@broadcom.com, Peter Zijlstra <peterz@infradead.org>, 
	Nicolas Saenz Julienne <nsaenzju@redhat.com>, Juergen Gross <jgross@suse.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.amakhalov@broadcom.com>, 
	Russell King <linux@armlinux.org.uk>, Catalin Marinas <catalin.marinas@arm.com>, 
	Will Deacon <will@kernel.org>, Huacai Chen <chenhuacai@kernel.org>, WANG Xuerui <kernel@xen0n.name>, 
	Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, 
	Albert Ou <aou@eecs.berkeley.edu>, Thomas Gleixner <tglx@linutronix.de>, 
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, 
	Dave Hansen <dave.hansen@linux.intel.com>, "H. Peter Anvin" <hpa@zytor.com>, 
	Arnaldo Carvalho de Melo <acme@kernel.org>, Namhyung Kim <namhyung@kernel.org>, 
	Mark Rutland <mark.rutland@arm.com>, 
	Alexander Shishkin <alexander.shishkin@linux.intel.com>, Jiri Olsa <jolsa@kernel.org>, 
	Ian Rogers <irogers@google.com>, Adrian Hunter <adrian.hunter@intel.com>, 
	Kan Liang <kan.liang@linux.intel.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>, 
	Josh Poimboeuf <jpoimboe@kernel.org>, Pawan Gupta <pawan.kumar.gupta@linux.intel.com>, 
	Paolo Bonzini <pbonzini@redhat.com>, Andy Lutomirski <luto@kernel.org>, Arnd Bergmann <arnd@arndb.de>, 
	Frederic Weisbecker <frederic@kernel.org>, "Paul E. McKenney" <paulmck@kernel.org>, 
	Jason Baron <jbaron@akamai.com>, Steven Rostedt <rostedt@goodmis.org>, 
	Ard Biesheuvel <ardb@kernel.org>, Neeraj Upadhyay <neeraj.upadhyay@kernel.org>, 
	Joel Fernandes <joel@joelfernandes.org>, Josh Triplett <josh@joshtriplett.org>, 
	Boqun Feng <boqun.feng@gmail.com>, Uladzislau Rezki <urezki@gmail.com>, 
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>, Lai Jiangshan <jiangshanlai@gmail.com>, 
	Zqiang <qiang.zhang1211@gmail.com>, Juri Lelli <juri.lelli@redhat.com>, 
	Clark Williams <williams@redhat.com>, Yair Podemsky <ypodemsk@redhat.com>, 
	Tomas Glozar <tglozar@redhat.com>, Vincent Guittot <vincent.guittot@linaro.org>, 
	Dietmar Eggemann <dietmar.eggemann@arm.com>, Ben Segall <bsegall@google.com>, 
	Mel Gorman <mgorman@suse.de>, Kees Cook <kees@kernel.org>, 
	Andrew Morton <akpm@linux-foundation.org>, Christoph Hellwig <hch@infradead.org>, 
	Shuah Khan <shuah@kernel.org>, Sami Tolvanen <samitolvanen@google.com>, 
	Miguel Ojeda <ojeda@kernel.org>, Alice Ryhl <aliceryhl@google.com>, 
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>, Samuel Holland <samuel.holland@sifive.com>, Rong Xu <xur@google.com>, 
	Geert Uytterhoeven <geert@linux-m68k.org>, Yosry Ahmed <yosryahmed@google.com>, 
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>, 
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>, Jinghao Jia <jinghao7@illinois.edu>, 
	Luis Chamberlain <mcgrof@kernel.org>, Randy Dunlap <rdunlap@infradead.org>, 
	Tiezhu Yang <yangtiezhu@loongson.cn>
Content-Type: text/plain; charset="us-ascii"

On Tue, Jan 14, 2025, Valentin Schneider wrote:
> text_poke_bp_batch() sends IPIs to all online CPUs to synchronize
> them vs the newly patched instruction. CPUs that are executing in userspace
> do not need this synchronization to happen immediately, and this is
> actually harmful interference for NOHZ_FULL CPUs.

...

> This leaves us with static keys and static calls.

...

> @@ -2317,11 +2334,20 @@ static void text_poke_bp_batch(struct text_poke_loc *tp, unsigned int nr_entries
>  	 * First step: add a int3 trap to the address that will be patched.
>  	 */
>  	for (i = 0; i < nr_entries; i++) {
> -		tp[i].old = *(u8 *)text_poke_addr(&tp[i]);
> -		text_poke(text_poke_addr(&tp[i]), &int3, INT3_INSN_SIZE);
> +		void *addr = text_poke_addr(&tp[i]);
> +
> +		/*
> +		 * There's no safe way to defer IPIs for patching text in
> +		 * .noinstr, record whether there is at least one such poke.
> +		 */
> +		if (is_kernel_noinstr_text((unsigned long)addr))
> +			cond = NULL;

Maybe pre-check "cond", especially if multiple ranges need to be checked?  I.e.

		if (cond && is_kernel_noinstr_text(...))
> +
> +		tp[i].old = *((u8 *)addr);
> +		text_poke(addr, &int3, INT3_INSN_SIZE);
>  	}
>  
> -	text_poke_sync();
> +	__text_poke_sync(cond);
>  
>  	/*
>  	 * Second step: update all but the first byte of the patched range.

...

> +/**
> + * is_kernel_noinstr_text - checks if the pointer address is located in the
> + *                    .noinstr section
> + *
> + * @addr: address to check
> + *
> + * Returns: true if the address is located in .noinstr, false otherwise.
> + */
> +static inline bool is_kernel_noinstr_text(unsigned long addr)
> +{
> +	return addr >= (unsigned long)__noinstr_text_start &&
> +	       addr < (unsigned long)__noinstr_text_end;
> +}

This doesn't do the right thing for modules, which matters because KVM can be
built as a module on x86, and because context tracking understands transitions
to GUEST mode, i.e. CPUs that are running in a KVM guest will be treated as not
being in the kernel, and thus will have IPIs deferred.  If KVM uses a static key
or branch between guest_state_enter_irqoff() and guest_state_exit_irqoff(), the
patching code won't wait for CPUs to exit guest mode, i.e. KVM could theoretically
use the wrong static path.

I don't expect this to ever cause problems in practice, because patching code in
KVM's VM-Enter/VM-Exit path that has *functional* implications, while CPUs are
actively running guest code, would be all kinds of crazy.  But I do think we
should plug the hole.

If this issue is unique to KVM, i.e. is not a generic problem for all modules (I
assume module code generally isn't allowed in the entry path, even via NMI?), one
idea would be to let KVM register its noinstr section for text poking.


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 21:19:45 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 21:19:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872062.1283019 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXoJs-00022z-3g; Tue, 14 Jan 2025 21:19:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872062.1283019; Tue, 14 Jan 2025 21:19:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXoJs-00022s-0y; Tue, 14 Jan 2025 21:19:28 +0000
Received: by outflank-mailman (input) for mailman id 872062;
 Tue, 14 Jan 2025 21:19:27 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=CHe5=UG=flex--seanjc.bounces.google.com=33NSGZwYKCeMXJFSOHLTTLQJ.HTRcJS-IJaJQQNXYX.cJSUWTOJHY.TWL@srs-se1.protection.inumbo.net>)
 id 1tXoJr-00022m-CH
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 21:19:27 +0000
Received: from mail-pl1-x649.google.com (mail-pl1-x649.google.com
 [2607:f8b0:4864:20::649])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3b28b874-d2bd-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 22:19:26 +0100 (CET)
Received: by mail-pl1-x649.google.com with SMTP id
 d9443c01a7336-218cf85639eso161292945ad.3
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 13:19:26 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 3b28b874-d2bd-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20230601; t=1736889565; x=1737494365; darn=lists.xenproject.org;
        h=cc:to:from:subject:message-id:references:mime-version:in-reply-to
         :date:from:to:cc:subject:date:message-id:reply-to;
        bh=XVbipT56M6kECF5Qh7elLUxboyXWurLrq3UYAkefsoQ=;
        b=1D5IPF1T1gcxEz6ccH7neY3tzgEXJ88Df7W6jKKVAoX4D0XHuIdcif9yNYdSZHBmro
         2XdMtHIKjBTzZmFW+wvYP98qQIgvYksTelCv7rXG3dssiK+ozpq1t6hvX2GLcIrbyFFJ
         QnE8CQYDcnP1B6Icmd5oKpakameZWnuStbq64xAfCMS8aUVFNAksoFivG7vLe5gpEq9Z
         h0oFOrXkr2suVxe1DGi9ZoXtsELXnHqcgX0rROk73dMvghWpwOeSJvNV+pr4hekZ/dk8
         /QhNI9UZFhNrLobP88HdtOzY7HbudN9nAND6YP+WsMhfb6cXh3j6QWmmI6zIebrlvV7A
         0KXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736889565; x=1737494365;
        h=cc:to:from:subject:message-id:references:mime-version:in-reply-to
         :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=XVbipT56M6kECF5Qh7elLUxboyXWurLrq3UYAkefsoQ=;
        b=MFK5KjKBMGCdVjwpW7hVbJwX2X/tiXTg99EONqLZKZkv8tgOWhpHYmD5jVVWhBuirK
         BeZIjrEscRQG6STmEdQF6mA1YjEneUnP0EbToX63lng9SqqBQgva8QJNzUvpirYdST0C
         aJYA8D9v5n8KEOCBI62wwhDnuDBz9YlZSjFYthkbsV0qiJMqrVz2A1wqK3eylxtjJmOY
         U53wci36T0wNDlegyjFcUylVa8c04PoLj1rzSm4Qqh44oc+c/jmzEB8fYSI3WCcIWALv
         Z9xl8kiXaUSxsKvDIQ+cdhGI0MC1v+I4z9WxMsAlRu6davafiQtpxNAhvT86v+/Hf/wV
         pA/A==
X-Forwarded-Encrypted: i=1; AJvYcCXVBxRYMMvRd+ta4SZK5gQfHSJG5I5AIZlY30I6Ft6t+YQgyPzxQTGuP6U4VLZePHWnOJPKaaDRRaI=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw/+FAMRpb042CAJNZCUGPMSyHqMBT1SOyxKYA+qZyHpp/JjDd0
	aVQB1tJgEfJng8/2y8tg8Y7eQBZpgVdfKa0NNrfTOKgeH5ezk/EQbCciT/bA5Blf0XgI0ibWtwQ
	eFA==
X-Google-Smtp-Source: AGHT+IGTMIc2Hr+w/ebVVGGlbFAB7WFV7TbQJLIjfH34Jlhrw+YYPMlrag1B602JmLWOQ4sU4fLE9W3Pz50=
X-Received: from plap13.prod.google.com ([2002:a17:902:f08d:b0:217:8109:e87])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:902:cec1:b0:216:3dc5:1230
 with SMTP id d9443c01a7336-21a83ffc1dbmr401799985ad.42.1736889564696; Tue, 14
 Jan 2025 13:19:24 -0800 (PST)
Date: Tue, 14 Jan 2025 13:19:23 -0800
In-Reply-To: <20250114175143.81438-19-vschneid@redhat.com>
Mime-Version: 1.0
References: <20250114175143.81438-1-vschneid@redhat.com> <20250114175143.81438-19-vschneid@redhat.com>
Message-ID: <Z4bU2xlZXh53lgH6@google.com>
Subject: Re: [PATCH v4 18/30] x86/kvm/vmx: Mark vmx_l1d_should flush and
 vmx_l1d_flush_cond keys as allowed in .noinstr
From: Sean Christopherson <seanjc@google.com>
To: Valentin Schneider <vschneid@redhat.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org, 
	virtualization@lists.linux.dev, linux-arm-kernel@lists.infradead.org, 
	loongarch@lists.linux.dev, linux-riscv@lists.infradead.org, 
	linux-perf-users@vger.kernel.org, xen-devel@lists.xenproject.org, 
	kvm@vger.kernel.org, linux-arch@vger.kernel.org, rcu@vger.kernel.org, 
	linux-hardening@vger.kernel.org, linux-mm@kvack.org, 
	linux-kselftest@vger.kernel.org, bpf@vger.kernel.org, 
	bcm-kernel-feedback-list@broadcom.com, Josh Poimboeuf <jpoimboe@kernel.org>, 
	Juergen Gross <jgross@suse.com>, Ajay Kaher <ajay.kaher@broadcom.com>, 
	Alexey Makhalov <alexey.amakhalov@broadcom.com>, Russell King <linux@armlinux.org.uk>, 
	Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, 
	Huacai Chen <chenhuacai@kernel.org>, WANG Xuerui <kernel@xen0n.name>, 
	Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, 
	Albert Ou <aou@eecs.berkeley.edu>, Thomas Gleixner <tglx@linutronix.de>, 
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, 
	Dave Hansen <dave.hansen@linux.intel.com>, "H. Peter Anvin" <hpa@zytor.com>, 
	Peter Zijlstra <peterz@infradead.org>, Arnaldo Carvalho de Melo <acme@kernel.org>, 
	Namhyung Kim <namhyung@kernel.org>, Mark Rutland <mark.rutland@arm.com>, 
	Alexander Shishkin <alexander.shishkin@linux.intel.com>, Jiri Olsa <jolsa@kernel.org>, 
	Ian Rogers <irogers@google.com>, Adrian Hunter <adrian.hunter@intel.com>, 
	Kan Liang <kan.liang@linux.intel.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>, 
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	Andy Lutomirski <luto@kernel.org>, Arnd Bergmann <arnd@arndb.de>, 
	Frederic Weisbecker <frederic@kernel.org>, "Paul E. McKenney" <paulmck@kernel.org>, 
	Jason Baron <jbaron@akamai.com>, Steven Rostedt <rostedt@goodmis.org>, 
	Ard Biesheuvel <ardb@kernel.org>, Neeraj Upadhyay <neeraj.upadhyay@kernel.org>, 
	Joel Fernandes <joel@joelfernandes.org>, Josh Triplett <josh@joshtriplett.org>, 
	Boqun Feng <boqun.feng@gmail.com>, Uladzislau Rezki <urezki@gmail.com>, 
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>, Lai Jiangshan <jiangshanlai@gmail.com>, 
	Zqiang <qiang.zhang1211@gmail.com>, Juri Lelli <juri.lelli@redhat.com>, 
	Clark Williams <williams@redhat.com>, Yair Podemsky <ypodemsk@redhat.com>, 
	Tomas Glozar <tglozar@redhat.com>, Vincent Guittot <vincent.guittot@linaro.org>, 
	Dietmar Eggemann <dietmar.eggemann@arm.com>, Ben Segall <bsegall@google.com>, 
	Mel Gorman <mgorman@suse.de>, Kees Cook <kees@kernel.org>, 
	Andrew Morton <akpm@linux-foundation.org>, Christoph Hellwig <hch@infradead.org>, 
	Shuah Khan <shuah@kernel.org>, Sami Tolvanen <samitolvanen@google.com>, 
	Miguel Ojeda <ojeda@kernel.org>, Alice Ryhl <aliceryhl@google.com>, 
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>, Samuel Holland <samuel.holland@sifive.com>, Rong Xu <xur@google.com>, 
	Nicolas Saenz Julienne <nsaenzju@redhat.com>, Geert Uytterhoeven <geert@linux-m68k.org>, 
	Yosry Ahmed <yosryahmed@google.com>, 
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>, 
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>, Jinghao Jia <jinghao7@illinois.edu>, 
	Luis Chamberlain <mcgrof@kernel.org>, Randy Dunlap <rdunlap@infradead.org>, 
	Tiezhu Yang <yangtiezhu@loongson.cn>
Content-Type: text/plain; charset="us-ascii"

Please use "KVM: VMX:" for the scope.

On Tue, Jan 14, 2025, Valentin Schneider wrote:
> Later commits will cause objtool to warn about static keys being used in
> .noinstr sections in order to safely defer instruction patching IPIs
> targeted at NOHZ_FULL CPUs.
> 
> These keys are used in .noinstr code, and can be modified at runtime
> (/proc/kernel/vmx* write). However it is not expected that they will be
> flipped during latency-sensitive operations, and thus shouldn't be a source
> of interference wrt the text patching IPI.

This misses KVM's static key that's buried behind CONFIG_HYPERV=m|y.

vmlinux.o: warning: objtool: vmx_vcpu_enter_exit+0x241: __kvm_is_using_evmcs: non-RO static key usage in noinstr
vmlinux.o: warning: objtool: vmx_update_host_rsp+0x13: __kvm_is_using_evmcs: non-RO static key usage in noinstr

Side topic, it's super annoying that "objtool --noinstr" only runs on vmlinux.o.
I realize objtool doesn't have the visilibity to validate cross-object calls,
but couldn't objtool validates calls and static key/branch usage so long as the
target or key/branch is defined in the same object?


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 21:24:28 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 21:24:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872073.1283030 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXoOg-0006BP-Lj; Tue, 14 Jan 2025 21:24:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872073.1283030; Tue, 14 Jan 2025 21:24:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXoOg-0006BI-Hg; Tue, 14 Jan 2025 21:24:26 +0000
Received: by outflank-mailman (input) for mailman id 872073;
 Tue, 14 Jan 2025 21:24: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
 <SRS0=OOos=UG=flex--seanjc.bounces.google.com=3BtaGZwYKCRE9vr40tx55x2v.t53Ev4-uvCv22z9A9.Ev46850vtA.58x@srs-se1.protection.inumbo.net>)
 id 1tXoOf-00069s-Av
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 21:24:25 +0000
Received: from mail-pj1-x104a.google.com (mail-pj1-x104a.google.com
 [2607:f8b0:4864:20::104a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id eca66abf-d2bd-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 22:24:24 +0100 (CET)
Received: by mail-pj1-x104a.google.com with SMTP id
 98e67ed59e1d1-2ef728e36d5so10811988a91.3
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 13:24:24 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: eca66abf-d2bd-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20230601; t=1736889862; x=1737494662; darn=lists.xenproject.org;
        h=cc:to:from:subject:message-id:references:mime-version:in-reply-to
         :date:from:to:cc:subject:date:message-id:reply-to;
        bh=8cSsXdzV+ZwQOEMikMUZ9KmnzJy+D1+up+g+W/Xr/ho=;
        b=H9a96cYICFO7kEmOsxa5Xzs9FtwiJHiV019pxSVh5nilsv/vGtaMSXk49e/D8NHbQz
         bCq/VeLAq1vsf7FL0TXwaAlOdLVjgSwUgnJBxMrDs4ZfZbYRvwmgajlRmoJKbqu5ngee
         bWmaIYwO30Ll3Dd5ndHZ0jQjnJyV3MReyy805BSn4Dg2IA1Np/ZyEB2wYrw82vmVC/rV
         +fCLIINprd4JBl6g8ZPBYb02VtSP9YgizfqRyFx/rnQCHdt1bJNdEgbGVUfptspxogdy
         V3fScghZyGIVqAyp/7duRdQqK2hN+vcsK/zmYd0zC8kM9/4pdpIqDZSNPSgfJyeWCiAf
         mMxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736889862; x=1737494662;
        h=cc:to:from:subject:message-id:references:mime-version:in-reply-to
         :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=8cSsXdzV+ZwQOEMikMUZ9KmnzJy+D1+up+g+W/Xr/ho=;
        b=F4M+/Gkm1tb8uD2adTs4+rI5plzRQB1lSUaOlbDt3LoVITykuz9CFQLe9hcZkXXZD3
         4ThKkXWWlP+m19ezFuwsl8A9/5/LDbOoKwGOzYa73Uy0Hkg40lqbXEtZce7AiF6cQvvb
         mqJRnvRACQxvi7M8eGWK4RN1g75DAx06onHYGdUr6RXkvRLA4InPbGHp2lZylOjasJm6
         sRr/Xe8FW0at/OmgqUe368J/8fMptcKNbmOVlyx4fT0BGW9yxsIMmvk/oJiYCWIG+ypc
         rpKXKTgA9MaBXBl6eCjXdKTlecn4fg8g/76EJuiWxkj4NaOBTuhEY9KPbxeoVQwnRYz9
         JNYQ==
X-Forwarded-Encrypted: i=1; AJvYcCWGoZPQZTmbsB8/dYtcSIz1OnsVfDcE0/4eHa6qu7O1OUyuOElW5dA6QTs0zs8VocQsG41uaZNn498=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz38+Q6fT+Cn9Xr+VPtJzNDnBb/LfTsWSv89U3eIdvzb9ueRDQ2
	9IE935Pt+nE6zgmmlrUZEApAjjBcNW81CFmVV1ZZS8IoDWQLlxIjEicYiyYQA9a9QStn7GEt0Au
	VjQ==
X-Google-Smtp-Source: AGHT+IGaqEwoic7xvDyznY8cDg+F7K5+qe11MRhfXOt+1PBXtCG3HV5nSK8yv8Q3/q/HTXMyOsqLmKxvwkg=
X-Received: from pjbtc8.prod.google.com ([2002:a17:90b:5408:b0:2ef:abba:8bfd])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:2b87:b0:2ee:8031:cdbc
 with SMTP id 98e67ed59e1d1-2f548f1ec3fmr32208440a91.23.1736889862547; Tue, 14
 Jan 2025 13:24:22 -0800 (PST)
Date: Tue, 14 Jan 2025 13:24:21 -0800
In-Reply-To: <20250114175143.81438-28-vschneid@redhat.com>
Mime-Version: 1.0
References: <20250114175143.81438-1-vschneid@redhat.com> <20250114175143.81438-28-vschneid@redhat.com>
Message-ID: <Z4bWBUGUH34qLUt0@google.com>
Subject: Re: [PATCH v4 27/30] x86/tlb: Make __flush_tlb_local() noinstr-compliant
From: Sean Christopherson <seanjc@google.com>
To: Valentin Schneider <vschneid@redhat.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org, 
	virtualization@lists.linux.dev, linux-arm-kernel@lists.infradead.org, 
	loongarch@lists.linux.dev, linux-riscv@lists.infradead.org, 
	linux-perf-users@vger.kernel.org, xen-devel@lists.xenproject.org, 
	kvm@vger.kernel.org, linux-arch@vger.kernel.org, rcu@vger.kernel.org, 
	linux-hardening@vger.kernel.org, linux-mm@kvack.org, 
	linux-kselftest@vger.kernel.org, bpf@vger.kernel.org, 
	bcm-kernel-feedback-list@broadcom.com, Juergen Gross <jgross@suse.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.amakhalov@broadcom.com>, 
	Russell King <linux@armlinux.org.uk>, Catalin Marinas <catalin.marinas@arm.com>, 
	Will Deacon <will@kernel.org>, Huacai Chen <chenhuacai@kernel.org>, WANG Xuerui <kernel@xen0n.name>, 
	Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, 
	Albert Ou <aou@eecs.berkeley.edu>, Thomas Gleixner <tglx@linutronix.de>, 
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, 
	Dave Hansen <dave.hansen@linux.intel.com>, "H. Peter Anvin" <hpa@zytor.com>, 
	Peter Zijlstra <peterz@infradead.org>, Arnaldo Carvalho de Melo <acme@kernel.org>, 
	Namhyung Kim <namhyung@kernel.org>, Mark Rutland <mark.rutland@arm.com>, 
	Alexander Shishkin <alexander.shishkin@linux.intel.com>, Jiri Olsa <jolsa@kernel.org>, 
	Ian Rogers <irogers@google.com>, Adrian Hunter <adrian.hunter@intel.com>, 
	Kan Liang <kan.liang@linux.intel.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>, 
	Josh Poimboeuf <jpoimboe@kernel.org>, Pawan Gupta <pawan.kumar.gupta@linux.intel.com>, 
	Paolo Bonzini <pbonzini@redhat.com>, Andy Lutomirski <luto@kernel.org>, Arnd Bergmann <arnd@arndb.de>, 
	Frederic Weisbecker <frederic@kernel.org>, "Paul E. McKenney" <paulmck@kernel.org>, 
	Jason Baron <jbaron@akamai.com>, Steven Rostedt <rostedt@goodmis.org>, 
	Ard Biesheuvel <ardb@kernel.org>, Neeraj Upadhyay <neeraj.upadhyay@kernel.org>, 
	Joel Fernandes <joel@joelfernandes.org>, Josh Triplett <josh@joshtriplett.org>, 
	Boqun Feng <boqun.feng@gmail.com>, Uladzislau Rezki <urezki@gmail.com>, 
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>, Lai Jiangshan <jiangshanlai@gmail.com>, 
	Zqiang <qiang.zhang1211@gmail.com>, Juri Lelli <juri.lelli@redhat.com>, 
	Clark Williams <williams@redhat.com>, Yair Podemsky <ypodemsk@redhat.com>, 
	Tomas Glozar <tglozar@redhat.com>, Vincent Guittot <vincent.guittot@linaro.org>, 
	Dietmar Eggemann <dietmar.eggemann@arm.com>, Ben Segall <bsegall@google.com>, 
	Mel Gorman <mgorman@suse.de>, Kees Cook <kees@kernel.org>, 
	Andrew Morton <akpm@linux-foundation.org>, Christoph Hellwig <hch@infradead.org>, 
	Shuah Khan <shuah@kernel.org>, Sami Tolvanen <samitolvanen@google.com>, 
	Miguel Ojeda <ojeda@kernel.org>, Alice Ryhl <aliceryhl@google.com>, 
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>, Samuel Holland <samuel.holland@sifive.com>, Rong Xu <xur@google.com>, 
	Nicolas Saenz Julienne <nsaenzju@redhat.com>, Geert Uytterhoeven <geert@linux-m68k.org>, 
	Yosry Ahmed <yosryahmed@google.com>, 
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>, 
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>, Jinghao Jia <jinghao7@illinois.edu>, 
	Luis Chamberlain <mcgrof@kernel.org>, Randy Dunlap <rdunlap@infradead.org>, 
	Tiezhu Yang <yangtiezhu@loongson.cn>
Content-Type: text/plain; charset="us-ascii"

On Tue, Jan 14, 2025, Valentin Schneider wrote:
> Later patches will require issuing a __flush_tlb_all() from noinstr code.
> This requires making both __flush_tlb_local() and __flush_tlb_global()
> noinstr-compliant.
> 
> For __flush_tlb_local(), xen_flush_tlb() has already been made noinstr, so
> it's just native_flush_tlb_global(), and simply __always_inline'ing
> invalidate_user_asid() gets us there
> 
> Signed-off-by: Valentin Schneider <vschneid@redhat.com>
> ---

...

> @@ -1206,7 +1206,7 @@ STATIC_NOPV noinstr void native_flush_tlb_global(void)
>  /*
>   * Flush the entire current user mapping
>   */
> -STATIC_NOPV void native_flush_tlb_local(void)
> +STATIC_NOPV noinstr void native_flush_tlb_local(void)

native_write_cr3() and __native_read_cr3() need to be __always_inline.

vmlinux.o: warning: objtool: native_flush_tlb_local+0x8: call to __native_read_cr3() leaves .noinstr.text section


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 21:27:04 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 21:27:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872083.1283040 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXoRA-0007dV-2E; Tue, 14 Jan 2025 21:27:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872083.1283040; Tue, 14 Jan 2025 21:27:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXoR9-0007dO-UY; Tue, 14 Jan 2025 21:26:59 +0000
Received: by outflank-mailman (input) for mailman id 872083;
 Tue, 14 Jan 2025 21:26:58 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=qKc7=UG=flex--seanjc.bounces.google.com=3n9aGZwYKCaocOKXTMQYYQVO.MYWhOX-NOfOVVScdc.hOXZbYTOMd.YbQ@srs-se1.protection.inumbo.net>)
 id 1tXoR8-0007UQ-6Q
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 21:26:58 +0000
Received: from mail-pj1-x104a.google.com (mail-pj1-x104a.google.com
 [2607:f8b0:4864:20::104a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 478996c4-d2be-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 22:26:56 +0100 (CET)
Received: by mail-pj1-x104a.google.com with SMTP id
 98e67ed59e1d1-2ee46799961so15462460a91.2
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 13:26:56 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 478996c4-d2be-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20230601; t=1736890015; x=1737494815; darn=lists.xenproject.org;
        h=cc:to:from:subject:message-id:references:mime-version:in-reply-to
         :date:from:to:cc:subject:date:message-id:reply-to;
        bh=V8zpuNawVjToL3i20ZYrbUddkmOaJHAfbCZJnZQ478w=;
        b=l/cByV5YV07DSwPirarW6Wdhb+ZbNSKN8G7fXC69yBrtZMne658PF6ItI9OtAaoFJP
         EiTkrHgvvJJCmGH6Snu79G3hUXEt3mi/M/b261oGQUlLh7gayCNGxcBAaXzD9bqVf67k
         jB/qCgmi3pxATMyVf1bdZdIRgceKcv7k0FfiVBnBeI/+s6sqgsZbhzLcSGuareMvW7cx
         vhcrkWVWk5z/i1Yj0uaMuFrtTtrXDPjUOC19CQ9jHmUNwG2mwsDZVzbLxtX4hp0WwpWW
         /poGE+xhsqYYA0w8d//ZVpRhCy7p1QkyvRa+brtw9E2Kk67Id2xMgQz5xMJ6THUY6kMq
         pVnw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736890015; x=1737494815;
        h=cc:to:from:subject:message-id:references:mime-version:in-reply-to
         :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=V8zpuNawVjToL3i20ZYrbUddkmOaJHAfbCZJnZQ478w=;
        b=HJ5SBLPvYpq1GT4WxbG5J3cEhyPWih4TfCrwRPn1H3mUSKUdY3FTHHiEQwC2VVRbv4
         BKzGg/lNqxlf+hIzagLsJk4VE1UMaXvYGH4eYl627PNDZnsIlFThAFOBiEUQi1ZHsKRy
         z281HAuRF1LwssEwj+u4WPYLI9V9HcB8gRMEcyVTg8u1ZqahARPScza+u/xEAlHxfDc0
         aA5Rs+IA1t0n5k8+7AbtFdokjQ3rypiCrBFObYMaowgcZOarkzVLKL7RXrBjKNxXcQLe
         iUl0DAdIfHhBFAA9J/OgMbs8N7fZUY0Mb/i23bt42Q9PnjDo1ucHjWAdigN0C78p5YZN
         IcIQ==
X-Forwarded-Encrypted: i=1; AJvYcCXgSG9dQuoredaxMKOV3KOB8KzjVmFpfj1qnk5W4RsgmBddPBSAcqTkp0bL3mzKu0X/V0Iaoclx4M4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwTNq2LWtJJq+KBVqKDUDPH1jcOkXASLD1GyJoy00KydfAGildg
	vyX6pvhtiK4haVqE3VbxiJxZ8YBSKNlpdGy9LmVdlCR9F4Du4/1IP50ONmF8J1xHWrilO5KgruK
	pqA==
X-Google-Smtp-Source: AGHT+IGDv4Ej+tMoSohr/AoTazwT/WbetgA7Nr8qE8BLNxmtc1cUUDk0TRGuDLxFKlrZpHzOjZy+L7iCKdA=
X-Received: from pjbsx15.prod.google.com ([2002:a17:90b:2ccf:b0:2ef:8ef8:2701])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:544b:b0:2ee:9902:18b4
 with SMTP id 98e67ed59e1d1-2f548f61fe6mr37131771a91.27.1736890015061; Tue, 14
 Jan 2025 13:26:55 -0800 (PST)
Date: Tue, 14 Jan 2025 13:26:53 -0800
In-Reply-To: <20250114175143.81438-26-vschneid@redhat.com>
Mime-Version: 1.0
References: <20250114175143.81438-1-vschneid@redhat.com> <20250114175143.81438-26-vschneid@redhat.com>
Message-ID: <Z4bWnWYqu1LaD-JG@google.com>
Subject: Re: [PATCH v4 25/30] context_tracking,x86: Defer kernel text patching IPIs
From: Sean Christopherson <seanjc@google.com>
To: Valentin Schneider <vschneid@redhat.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org, 
	virtualization@lists.linux.dev, linux-arm-kernel@lists.infradead.org, 
	loongarch@lists.linux.dev, linux-riscv@lists.infradead.org, 
	linux-perf-users@vger.kernel.org, xen-devel@lists.xenproject.org, 
	kvm@vger.kernel.org, linux-arch@vger.kernel.org, rcu@vger.kernel.org, 
	linux-hardening@vger.kernel.org, linux-mm@kvack.org, 
	linux-kselftest@vger.kernel.org, bpf@vger.kernel.org, 
	bcm-kernel-feedback-list@broadcom.com, Peter Zijlstra <peterz@infradead.org>, 
	Nicolas Saenz Julienne <nsaenzju@redhat.com>, Juergen Gross <jgross@suse.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.amakhalov@broadcom.com>, 
	Russell King <linux@armlinux.org.uk>, Catalin Marinas <catalin.marinas@arm.com>, 
	Will Deacon <will@kernel.org>, Huacai Chen <chenhuacai@kernel.org>, WANG Xuerui <kernel@xen0n.name>, 
	Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, 
	Albert Ou <aou@eecs.berkeley.edu>, Thomas Gleixner <tglx@linutronix.de>, 
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, 
	Dave Hansen <dave.hansen@linux.intel.com>, "H. Peter Anvin" <hpa@zytor.com>, 
	Arnaldo Carvalho de Melo <acme@kernel.org>, Namhyung Kim <namhyung@kernel.org>, 
	Mark Rutland <mark.rutland@arm.com>, 
	Alexander Shishkin <alexander.shishkin@linux.intel.com>, Jiri Olsa <jolsa@kernel.org>, 
	Ian Rogers <irogers@google.com>, Adrian Hunter <adrian.hunter@intel.com>, 
	Kan Liang <kan.liang@linux.intel.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>, 
	Josh Poimboeuf <jpoimboe@kernel.org>, Pawan Gupta <pawan.kumar.gupta@linux.intel.com>, 
	Paolo Bonzini <pbonzini@redhat.com>, Andy Lutomirski <luto@kernel.org>, Arnd Bergmann <arnd@arndb.de>, 
	Frederic Weisbecker <frederic@kernel.org>, "Paul E. McKenney" <paulmck@kernel.org>, 
	Jason Baron <jbaron@akamai.com>, Steven Rostedt <rostedt@goodmis.org>, 
	Ard Biesheuvel <ardb@kernel.org>, Neeraj Upadhyay <neeraj.upadhyay@kernel.org>, 
	Joel Fernandes <joel@joelfernandes.org>, Josh Triplett <josh@joshtriplett.org>, 
	Boqun Feng <boqun.feng@gmail.com>, Uladzislau Rezki <urezki@gmail.com>, 
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>, Lai Jiangshan <jiangshanlai@gmail.com>, 
	Zqiang <qiang.zhang1211@gmail.com>, Juri Lelli <juri.lelli@redhat.com>, 
	Clark Williams <williams@redhat.com>, Yair Podemsky <ypodemsk@redhat.com>, 
	Tomas Glozar <tglozar@redhat.com>, Vincent Guittot <vincent.guittot@linaro.org>, 
	Dietmar Eggemann <dietmar.eggemann@arm.com>, Ben Segall <bsegall@google.com>, 
	Mel Gorman <mgorman@suse.de>, Kees Cook <kees@kernel.org>, 
	Andrew Morton <akpm@linux-foundation.org>, Christoph Hellwig <hch@infradead.org>, 
	Shuah Khan <shuah@kernel.org>, Sami Tolvanen <samitolvanen@google.com>, 
	Miguel Ojeda <ojeda@kernel.org>, Alice Ryhl <aliceryhl@google.com>, 
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>, Samuel Holland <samuel.holland@sifive.com>, Rong Xu <xur@google.com>, 
	Geert Uytterhoeven <geert@linux-m68k.org>, Yosry Ahmed <yosryahmed@google.com>, 
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>, 
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>, Jinghao Jia <jinghao7@illinois.edu>, 
	Luis Chamberlain <mcgrof@kernel.org>, Randy Dunlap <rdunlap@infradead.org>, 
	Tiezhu Yang <yangtiezhu@loongson.cn>
Content-Type: text/plain; charset="us-ascii"

On Tue, Jan 14, 2025, Valentin Schneider wrote:
>  static __always_inline void arch_context_tracking_work(enum ct_work work)
>  {
>  	switch (work) {
> -	case CT_WORK_n:
> -		// Do work...
> +	case CT_WORK_SYNC:
> +		sync_core();

Not your bug, but serialize() needs to be __always_inline.  Not sure what exactly
caused it to be uninlined, but this is the obvious new usage.

vmlinux.o: warning: objtool: __static_call_update_early+0x4e: call to serialize() leaves .noinstr.text section
vmlinux.o: warning: objtool: ct_work_flush+0x69: call to serialize() leaves .noinstr.text section


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 21:45:59 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 21:45:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872094.1283049 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXojS-0002IN-H4; Tue, 14 Jan 2025 21:45:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872094.1283049; Tue, 14 Jan 2025 21:45:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXojS-0002IG-Dn; Tue, 14 Jan 2025 21:45:54 +0000
Received: by outflank-mailman (input) for mailman id 872094;
 Tue, 14 Jan 2025 21:45:53 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=v/+J=UG=intel.com=dave.hansen@srs-se1.protection.inumbo.net>)
 id 1tXojQ-0002Gw-N5
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 21:45:53 +0000
Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id eaacbd48-d2c0-11ef-a0e1-8be0dac302b0;
 Tue, 14 Jan 2025 22:45:50 +0100 (CET)
Received: from orviesa007.jf.intel.com ([10.64.159.147])
 by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 14 Jan 2025 13:45:47 -0800
Received: from ssimmeri-mobl2.amr.corp.intel.com (HELO [10.124.223.199])
 ([10.124.223.199])
 by orviesa007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 14 Jan 2025 13:45:42 -0800
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: eaacbd48-d2c0-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=intel.com; i=@intel.com; q=dns/txt; s=Intel;
  t=1736891151; x=1768427151;
  h=message-id:date:mime-version:subject:to:cc:references:
   from:in-reply-to;
  bh=FiKf+CBG14D8HJTJEsGFPQ/VuBsXxEyfgK3jkw1jBxs=;
  b=DPZFgt3KBClQEz3NrDsQRToHSeBuGhGyPwPUc0VipYKX1U2lSZrNhvpG
   /QvWEFRxD3ioKErBDgDNzUHNomjyDby+1LOgJPzcgFloyizbpZUdgm5Mp
   lCuEA7UD0TihfNfZ0P85FZRI/T8uScJL9EGrTPwrscaZe4WZqBuLgozrK
   nZQcdDE2OZNra/i/0RBv45gnAzGS+wBYyFcmb8PAK+zH28EtXNAhaS+po
   9ts0mV6VzXuCMwDZ1LXFohFpKm/UMpHJdaTmaLNsPUZYra7g1PyzZMURt
   WAseHSTw1vwqf40yeKKhA438uZ8gxWhuh/KZTqYTIFyyMh2qvZaxGNQB3
   g==;
X-CSE-ConnectionGUID: L86KXOKtRfK+Va0vMQ+jDg==
X-CSE-MsgGUID: Ci0A0mUVRBuOLZX9X56WKQ==
X-IronPort-AV: E=McAfee;i="6700,10204,11315"; a="47874059"
X-IronPort-AV: E=Sophos;i="6.12,315,1728975600"; 
   d="scan'208";a="47874059"
X-CSE-ConnectionGUID: wClD8OzMQai+UBG5Nw361Q==
X-CSE-MsgGUID: vzPbyt3kQ96Xavq3f7i4kA==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="6.12,224,1728975600"; 
   d="scan'208";a="105422933"
Content-Type: multipart/mixed; boundary="------------n0n6ZXEhGiQA3ZVqsLB2u14D"
Message-ID: <52311c3d-83cf-4dc4-bbcb-5fbca8eb249c@intel.com>
Date: Tue, 14 Jan 2025 13:45:39 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 26/30] x86,tlb: Make __flush_tlb_global()
 noinstr-compliant
To: Valentin Schneider <vschneid@redhat.com>, linux-kernel@vger.kernel.org,
 x86@kernel.org, virtualization@lists.linux.dev,
 linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev,
 linux-riscv@lists.infradead.org, linux-perf-users@vger.kernel.org,
 xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
 linux-arch@vger.kernel.org, rcu@vger.kernel.org,
 linux-hardening@vger.kernel.org, linux-mm@kvack.org,
 linux-kselftest@vger.kernel.org, bpf@vger.kernel.org,
 bcm-kernel-feedback-list@broadcom.com
Cc: Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>,
 Ajay Kaher <ajay.kaher@broadcom.com>,
 Alexey Makhalov <alexey.amakhalov@broadcom.com>,
 Russell King <linux@armlinux.org.uk>,
 Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>,
 Huacai Chen <chenhuacai@kernel.org>, WANG Xuerui <kernel@xen0n.name>,
 Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt
 <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>,
 Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>,
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>,
 "H. Peter Anvin" <hpa@zytor.com>, Arnaldo Carvalho de Melo
 <acme@kernel.org>, Namhyung Kim <namhyung@kernel.org>,
 Mark Rutland <mark.rutland@arm.com>,
 Alexander Shishkin <alexander.shishkin@linux.intel.com>,
 Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
 Adrian Hunter <adrian.hunter@intel.com>,
 "Liang, Kan" <kan.liang@linux.intel.com>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 Josh Poimboeuf <jpoimboe@kernel.org>,
 Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
 Sean Christopherson <seanjc@google.com>, Paolo Bonzini
 <pbonzini@redhat.com>, Andy Lutomirski <luto@kernel.org>,
 Arnd Bergmann <arnd@arndb.de>, Frederic Weisbecker <frederic@kernel.org>,
 "Paul E. McKenney" <paulmck@kernel.org>, Jason Baron <jbaron@akamai.com>,
 Steven Rostedt <rostedt@goodmis.org>, Ard Biesheuvel <ardb@kernel.org>,
 Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
 Joel Fernandes <joel@joelfernandes.org>,
 Josh Triplett <josh@joshtriplett.org>, Boqun Feng <boqun.feng@gmail.com>,
 Uladzislau Rezki <urezki@gmail.com>,
 Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
 Lai Jiangshan <jiangshanlai@gmail.com>, Zqiang <qiang.zhang1211@gmail.com>,
 Juri Lelli <juri.lelli@redhat.com>, Clark Williams <williams@redhat.com>,
 Yair Podemsky <ypodemsk@redhat.com>, Tomas Glozar <tglozar@redhat.com>,
 Vincent Guittot <vincent.guittot@linaro.org>,
 Dietmar Eggemann <dietmar.eggemann@arm.com>, Ben Segall
 <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
 Kees Cook <kees@kernel.org>, Andrew Morton <akpm@linux-foundation.org>,
 Christoph Hellwig <hch@infradead.org>, Shuah Khan <shuah@kernel.org>,
 Sami Tolvanen <samitolvanen@google.com>, Miguel Ojeda <ojeda@kernel.org>,
 Alice Ryhl <aliceryhl@google.com>,
 "Mike Rapoport (Microsoft)" <rppt@kernel.org>,
 Samuel Holland <samuel.holland@sifive.com>, Rong Xu <xur@google.com>,
 Nicolas Saenz Julienne <nsaenzju@redhat.com>,
 Geert Uytterhoeven <geert@linux-m68k.org>,
 Yosry Ahmed <yosryahmed@google.com>,
 "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
 "Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
 Jinghao Jia <jinghao7@illinois.edu>, Luis Chamberlain <mcgrof@kernel.org>,
 Randy Dunlap <rdunlap@infradead.org>, Tiezhu Yang <yangtiezhu@loongson.cn>
References: <20250114175143.81438-1-vschneid@redhat.com>
 <20250114175143.81438-27-vschneid@redhat.com>
From: Dave Hansen <dave.hansen@intel.com>
Content-Language: en-US
Autocrypt: addr=dave.hansen@intel.com; keydata=
 xsFNBE6HMP0BEADIMA3XYkQfF3dwHlj58Yjsc4E5y5G67cfbt8dvaUq2fx1lR0K9h1bOI6fC
 oAiUXvGAOxPDsB/P6UEOISPpLl5IuYsSwAeZGkdQ5g6m1xq7AlDJQZddhr/1DC/nMVa/2BoY
 2UnKuZuSBu7lgOE193+7Uks3416N2hTkyKUSNkduyoZ9F5twiBhxPJwPtn/wnch6n5RsoXsb
 ygOEDxLEsSk/7eyFycjE+btUtAWZtx+HseyaGfqkZK0Z9bT1lsaHecmB203xShwCPT49Blxz
 VOab8668QpaEOdLGhtvrVYVK7x4skyT3nGWcgDCl5/Vp3TWA4K+IofwvXzX2ON/Mj7aQwf5W
 iC+3nWC7q0uxKwwsddJ0Nu+dpA/UORQWa1NiAftEoSpk5+nUUi0WE+5DRm0H+TXKBWMGNCFn
 c6+EKg5zQaa8KqymHcOrSXNPmzJuXvDQ8uj2J8XuzCZfK4uy1+YdIr0yyEMI7mdh4KX50LO1
 pmowEqDh7dLShTOif/7UtQYrzYq9cPnjU2ZW4qd5Qz2joSGTG9eCXLz5PRe5SqHxv6ljk8mb
 ApNuY7bOXO/A7T2j5RwXIlcmssqIjBcxsRRoIbpCwWWGjkYjzYCjgsNFL6rt4OL11OUF37wL
 QcTl7fbCGv53KfKPdYD5hcbguLKi/aCccJK18ZwNjFhqr4MliQARAQABzUVEYXZpZCBDaHJp
 c3RvcGhlciBIYW5zZW4gKEludGVsIFdvcmsgQWRkcmVzcykgPGRhdmUuaGFuc2VuQGludGVs
 LmNvbT7CwXgEEwECACIFAlQ+9J0CGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEGg1
 lTBwyZKwLZUP/0dnbhDc229u2u6WtK1s1cSd9WsflGXGagkR6liJ4um3XCfYWDHvIdkHYC1t
 MNcVHFBwmQkawxsYvgO8kXT3SaFZe4ISfB4K4CL2qp4JO+nJdlFUbZI7cz/Td9z8nHjMcWYF
 IQuTsWOLs/LBMTs+ANumibtw6UkiGVD3dfHJAOPNApjVr+M0P/lVmTeP8w0uVcd2syiaU5jB
 aht9CYATn+ytFGWZnBEEQFnqcibIaOrmoBLu2b3fKJEd8Jp7NHDSIdrvrMjYynmc6sZKUqH2
 I1qOevaa8jUg7wlLJAWGfIqnu85kkqrVOkbNbk4TPub7VOqA6qG5GCNEIv6ZY7HLYd/vAkVY
 E8Plzq/NwLAuOWxvGrOl7OPuwVeR4hBDfcrNb990MFPpjGgACzAZyjdmYoMu8j3/MAEW4P0z
 F5+EYJAOZ+z212y1pchNNauehORXgjrNKsZwxwKpPY9qb84E3O9KYpwfATsqOoQ6tTgr+1BR
 CCwP712H+E9U5HJ0iibN/CDZFVPL1bRerHziuwuQuvE0qWg0+0SChFe9oq0KAwEkVs6ZDMB2
 P16MieEEQ6StQRlvy2YBv80L1TMl3T90Bo1UUn6ARXEpcbFE0/aORH/jEXcRteb+vuik5UGY
 5TsyLYdPur3TXm7XDBdmmyQVJjnJKYK9AQxj95KlXLVO38lczsFNBFRjzmoBEACyAxbvUEhd
 GDGNg0JhDdezyTdN8C9BFsdxyTLnSH31NRiyp1QtuxvcqGZjb2trDVuCbIzRrgMZLVgo3upr
 MIOx1CXEgmn23Zhh0EpdVHM8IKx9Z7V0r+rrpRWFE8/wQZngKYVi49PGoZj50ZEifEJ5qn/H
 Nsp2+Y+bTUjDdgWMATg9DiFMyv8fvoqgNsNyrrZTnSgoLzdxr89FGHZCoSoAK8gfgFHuO54B
 lI8QOfPDG9WDPJ66HCodjTlBEr/Cwq6GruxS5i2Y33YVqxvFvDa1tUtl+iJ2SWKS9kCai2DR
 3BwVONJEYSDQaven/EHMlY1q8Vln3lGPsS11vSUK3QcNJjmrgYxH5KsVsf6PNRj9mp8Z1kIG
 qjRx08+nnyStWC0gZH6NrYyS9rpqH3j+hA2WcI7De51L4Rv9pFwzp161mvtc6eC/GxaiUGuH
 BNAVP0PY0fqvIC68p3rLIAW3f97uv4ce2RSQ7LbsPsimOeCo/5vgS6YQsj83E+AipPr09Caj
 0hloj+hFoqiticNpmsxdWKoOsV0PftcQvBCCYuhKbZV9s5hjt9qn8CE86A5g5KqDf83Fxqm/
 vXKgHNFHE5zgXGZnrmaf6resQzbvJHO0Fb0CcIohzrpPaL3YepcLDoCCgElGMGQjdCcSQ+Ci
 FCRl0Bvyj1YZUql+ZkptgGjikQARAQABwsFfBBgBAgAJBQJUY85qAhsMAAoJEGg1lTBwyZKw
 l4IQAIKHs/9po4spZDFyfDjunimEhVHqlUt7ggR1Hsl/tkvTSze8pI1P6dGp2XW6AnH1iayn
 yRcoyT0ZJ+Zmm4xAH1zqKjWplzqdb/dO28qk0bPso8+1oPO8oDhLm1+tY+cOvufXkBTm+whm
 +AyNTjaCRt6aSMnA/QHVGSJ8grrTJCoACVNhnXg/R0g90g8iV8Q+IBZyDkG0tBThaDdw1B2l
 asInUTeb9EiVfL/Zjdg5VWiF9LL7iS+9hTeVdR09vThQ/DhVbCNxVk+DtyBHsjOKifrVsYep
 WpRGBIAu3bK8eXtyvrw1igWTNs2wazJ71+0z2jMzbclKAyRHKU9JdN6Hkkgr2nPb561yjcB8
 sIq1pFXKyO+nKy6SZYxOvHxCcjk2fkw6UmPU6/j/nQlj2lfOAgNVKuDLothIxzi8pndB8Jju
 KktE5HJqUUMXePkAYIxEQ0mMc8Po7tuXdejgPMwgP7x65xtfEqI0RuzbUioFltsp1jUaRwQZ
 MTsCeQDdjpgHsj+P2ZDeEKCbma4m6Ez/YWs4+zDm1X8uZDkZcfQlD9NldbKDJEXLIjYWo1PH
 hYepSffIWPyvBMBTW2W5FRjJ4vLRrJSUoEfJuPQ3vW9Y73foyo/qFoURHO48AinGPZ7PC7TF
 vUaNOTjKedrqHkaOcqB185ahG2had0xnFsDPlx5y
In-Reply-To: <20250114175143.81438-27-vschneid@redhat.com>

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

On 1/14/25 09:51, Valentin Schneider wrote:
> +	cr4 = this_cpu_read(cpu_tlbstate.cr4);
> +	asm volatile("mov %0,%%cr4": : "r" (cr4 ^ X86_CR4_PGE) : "memory");
> +	asm volatile("mov %0,%%cr4": : "r" (cr4) : "memory");
> +	/*
> +	 * In lieu of not having the pinning crap, hard fail if CR4 doesn't
> +	 * match the expected value. This ensures that anybody doing dodgy gets
> +	 * the fallthrough check.
> +	 */
> +	BUG_ON(cr4 != this_cpu_read(cpu_tlbstate.cr4));

Let's say someone managed to write to cpu_tlbstate.cr4 where they
cleared one of the pinned bits.

Before this patch, CR4 pinning would WARN_ONCE() about it pretty quickly
and also reset the cleared bits.

After this patch, the first native_flush_tlb_global() can clear pinned
bits, at least until native_write_cr4() gets called the next time. That
seems like it'll undermine CR4 pinning at least somewhat.

What keeps native_write_cr4() from being noinstr-compliant now? Is it
just the WARN_ONCE()?

If so, I'd kinda rather have a native_write_cr4_nowarn() that's
noinstr-compliant but retains all the other CR4 pinning behavior. Would
something like the attached patch be _worse_?
--------------n0n6ZXEhGiQA3ZVqsLB2u14D
Content-Type: text/x-patch; charset=UTF-8; name="cr4.patch"
Content-Disposition: attachment; filename="cr4.patch"
Content-Transfer-Encoding: base64

ZGlmZiAtLWdpdCBhL2FyY2gveDg2L2tlcm5lbC9jcHUvY29tbW9uLmMgYi9hcmNoL3g4Ni9r
ZXJuZWwvY3B1L2NvbW1vbi5jCmluZGV4IDNlOTAzNzY5MDgxNC4uMjA0NGQ1MTZmMDZmIDEw
MDY0NAotLS0gYS9hcmNoL3g4Ni9rZXJuZWwvY3B1L2NvbW1vbi5jCisrKyBiL2FyY2gveDg2
L2tlcm5lbC9jcHUvY29tbW9uLmMKQEAgLTQyMywyNCArNDIzLDQwIEBAIHZvaWQgbmF0aXZl
X3dyaXRlX2NyMCh1bnNpZ25lZCBsb25nIHZhbCkKIH0KIEVYUE9SVF9TWU1CT0wobmF0aXZl
X3dyaXRlX2NyMCk7CiAKLXZvaWQgX19ub19wcm9maWxlIG5hdGl2ZV93cml0ZV9jcjQodW5z
aWduZWQgbG9uZyB2YWwpCit2b2lkIF9fbm9fcHJvZmlsZSBfX25hdGl2ZV93cml0ZV9jcjQo
dW5zaWduZWQgbG9uZyB2YWwsIHVuc2lnbmVkIGxvbmcgKmJpdHNfY2hhbmdlZCkKIHsKLQl1
bnNpZ25lZCBsb25nIGJpdHNfY2hhbmdlZCA9IDA7Ci0KIHNldF9yZWdpc3RlcjoKIAlhc20g
dm9sYXRpbGUoIm1vdiAlMCwlJWNyNCI6ICIrciIgKHZhbCkgOiA6ICJtZW1vcnkiKTsKIAog
CWlmIChzdGF0aWNfYnJhbmNoX2xpa2VseSgmY3JfcGlubmluZykpIHsKIAkJaWYgKHVubGlr
ZWx5KCh2YWwgJiBjcjRfcGlubmVkX21hc2spICE9IGNyNF9waW5uZWRfYml0cykpIHsKLQkJ
CWJpdHNfY2hhbmdlZCA9ICh2YWwgJiBjcjRfcGlubmVkX21hc2spIF4gY3I0X3Bpbm5lZF9i
aXRzOworCQkJKmJpdHNfY2hhbmdlZCA9ICh2YWwgJiBjcjRfcGlubmVkX21hc2spIF4gY3I0
X3Bpbm5lZF9iaXRzOwogCQkJdmFsID0gKHZhbCAmIH5jcjRfcGlubmVkX21hc2spIHwgY3I0
X3Bpbm5lZF9iaXRzOwogCQkJZ290byBzZXRfcmVnaXN0ZXI7CiAJCX0KLQkJLyogV2FybiBh
ZnRlciB3ZSd2ZSBjb3JyZWN0ZWQgdGhlIGNoYW5nZWQgYml0cy4gKi8KLQkJV0FSTl9PTkNF
KGJpdHNfY2hhbmdlZCwgInBpbm5lZCBDUjQgYml0cyBjaGFuZ2VkOiAweCVseCE/XG4iLAot
CQkJICBiaXRzX2NoYW5nZWQpOwogCX0KIH0KKwordm9pZCBfX25vX3Byb2ZpbGUgbmF0aXZl
X3dyaXRlX2NyNCh1bnNpZ25lZCBsb25nIHZhbCkKK3sKKwl1bnNpZ25lZCBsb25nIGJpdHNf
Y2hhbmdlZCA9IDA7CisKKwlfX25hdGl2ZV93cml0ZV9jcjQodmFsLCAmYml0c19jaGFuZ2Vk
KTsKKworCWlmICghYml0c19jaGFuZ2VkKQorCQlyZXR1cm4KKworCVdBUk5fT05DRShiaXRz
X2NoYW5nZWQsICJwaW5uZWQgQ1I0IGJpdHMgY2hhbmdlZDogMHglbHghP1xuIiwKKwkJICBi
aXRzX2NoYW5nZWQpOworfQorCit2b2lkIF9fbm9fcHJvZmlsZSBuYXRpdmVfd3JpdGVfY3I0
X25vd2Fybih1bnNpZ25lZCBsb25nIHZhbCkKK3sKKwl1bnNpZ25lZCBsb25nIGJpdHNfY2hh
bmdlZCA9IDA7CisKKwlfX25hdGl2ZV93cml0ZV9jcjQodmFsLCAmYml0c19jaGFuZ2VkKTsK
K30KKwogI2lmIElTX01PRFVMRShDT05GSUdfTEtEVE0pCiBFWFBPUlRfU1lNQk9MX0dQTChu
YXRpdmVfd3JpdGVfY3I0KTsKICNlbmRpZgo=

--------------n0n6ZXEhGiQA3ZVqsLB2u14D--


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 21:48:55 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 21:48:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872104.1283059 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXomN-0003Ml-23; Tue, 14 Jan 2025 21:48:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872104.1283059; Tue, 14 Jan 2025 21:48:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXomM-0003Me-Ve; Tue, 14 Jan 2025 21:48:54 +0000
Received: by outflank-mailman (input) for mailman id 872104;
 Tue, 14 Jan 2025 21:48: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
 <SRS0=yd6S=UG=flex--seanjc.bounces.google.com=3wtuGZwYKCdcL73GC59HH9E7.5HFQ7G-67O7EEBLML.Q7GIKHC75M.HK9@srs-se1.protection.inumbo.net>)
 id 1tXomL-0003MY-LP
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 21:48:53 +0000
Received: from mail-pj1-x104a.google.com (mail-pj1-x104a.google.com
 [2607:f8b0:4864:20::104a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5764e6c1-d2c1-11ef-99a4-01e77a169b0f;
 Tue, 14 Jan 2025 22:48:51 +0100 (CET)
Received: by mail-pj1-x104a.google.com with SMTP id
 98e67ed59e1d1-2f5538a2356so10422580a91.2
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 13:48:51 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5764e6c1-d2c1-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20230601; t=1736891330; x=1737496130; darn=lists.xenproject.org;
        h=cc:to:from:subject:message-id:references:mime-version:in-reply-to
         :date:from:to:cc:subject:date:message-id:reply-to;
        bh=SY5ohLi34L7dYoduVlaYy23kjKtiA3foJ9V2Q6nj8Ew=;
        b=u5nWWMlvhRXnCwgbCcMadkd2WRLHOEnETc3L19fmyYljDs2qvfuke/bcVdC+xZ2997
         2v01xolJ/LjXL0gX73zTwsIVbrcR6SMPVP6Nm5FXzB1yg3HQeZYzTsgx29VQimRwUSBE
         997Fs5l5Hb1SWEyCSA+XRT5z3SPKLVYelje+oVuKH79JJpnQhuwSiIie9tEGOAw5Ij64
         Gt97dxXwB/Xx6EGJryNjGDRGdNKbL/MXncNhY1SsxUtPOUJcyebgGIGgEyDO5SyLOhFo
         psAbms9XVbgl5NsYYvo7BP8eT6yaGULYNv5oqLhP8+WLHZkEzjVCf0DMQfiwBR3hJ0NL
         cu/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736891330; x=1737496130;
        h=cc:to:from:subject:message-id:references:mime-version:in-reply-to
         :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=SY5ohLi34L7dYoduVlaYy23kjKtiA3foJ9V2Q6nj8Ew=;
        b=ThE0gZiWruH032R3hi7IxA+Z120R6l4djeFhHaGoB6GScHlyLpQ81xTz69ElLSchZW
         rL/qMqtZihM8NxyUmTwmVTLh8XtmHjffYjiB3yWS32CsHstX2iFYM5pfJkFxp7GLylHv
         W8jyYcyNuhvO72xGqTkjlF488nxhLehquyb32rHRtUHNeHxz0oLt+W1fQxbuPS37oKkb
         yHojNhSRSqf2+a7l8/uIVU/kYgaJrnb0kApza82Bx9GqRIWgfcTjRXzwaR2g45gIUBme
         ON+JGUKHALBdlJ4fpS6JWp0RldgZrix/VYXB+/CIe8cnImuSf4fLuOFhhTgbFxAv7uXk
         viuQ==
X-Forwarded-Encrypted: i=1; AJvYcCUCJGHrRFvnPrriVJTZPgPyjEr19QWZRq3uKgQWv7hKAi6Vtp+4PPIz5dD4Zb6QpZYHNvUBGX4lOtg=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywm7lvguYzJTYAhGV133Qj1Fo6VaLsFBdaM07E2i9fh+hEW/F/x
	2eKu3dJg05L+8T44/v5ApIOZorG16KiA+j9lsBXFbsN6A5uG5VoAI3HQnbyDJrB2zTpbTA6MPCN
	iYA==
X-Google-Smtp-Source: AGHT+IGwfpH2TIl0yoCx6tHXuYKAWJYGIodcKzr2p0TmFaGwbmX4878qRqYpxqFQD7ygsze3Eu4GllOh0sY=
X-Received: from pjbtc14.prod.google.com ([2002:a17:90b:540e:b0:2f2:ea3f:34c3])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90a:d00b:b0:2ee:d63f:d8f
 with SMTP id 98e67ed59e1d1-2f548ebf53cmr37053651a91.13.1736891330040; Tue, 14
 Jan 2025 13:48:50 -0800 (PST)
Date: Tue, 14 Jan 2025 13:48:48 -0800
In-Reply-To: <Z4bTlZkqihaAyGb4@google.com>
Mime-Version: 1.0
References: <20250114175143.81438-1-vschneid@redhat.com> <20250114175143.81438-26-vschneid@redhat.com>
 <Z4bTlZkqihaAyGb4@google.com>
Message-ID: <Z4bbwE8yfg349gBx@google.com>
Subject: Re: [PATCH v4 25/30] context_tracking,x86: Defer kernel text patching IPIs
From: Sean Christopherson <seanjc@google.com>
To: Valentin Schneider <vschneid@redhat.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org, 
	virtualization@lists.linux.dev, linux-arm-kernel@lists.infradead.org, 
	loongarch@lists.linux.dev, linux-riscv@lists.infradead.org, 
	linux-perf-users@vger.kernel.org, xen-devel@lists.xenproject.org, 
	kvm@vger.kernel.org, linux-arch@vger.kernel.org, rcu@vger.kernel.org, 
	linux-hardening@vger.kernel.org, linux-mm@kvack.org, 
	linux-kselftest@vger.kernel.org, bpf@vger.kernel.org, 
	bcm-kernel-feedback-list@broadcom.com, Peter Zijlstra <peterz@infradead.org>, 
	Nicolas Saenz Julienne <nsaenzju@redhat.com>, Juergen Gross <jgross@suse.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.amakhalov@broadcom.com>, 
	Russell King <linux@armlinux.org.uk>, Catalin Marinas <catalin.marinas@arm.com>, 
	Will Deacon <will@kernel.org>, Huacai Chen <chenhuacai@kernel.org>, WANG Xuerui <kernel@xen0n.name>, 
	Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, 
	Albert Ou <aou@eecs.berkeley.edu>, Thomas Gleixner <tglx@linutronix.de>, 
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, 
	Dave Hansen <dave.hansen@linux.intel.com>, "H. Peter Anvin" <hpa@zytor.com>, 
	Arnaldo Carvalho de Melo <acme@kernel.org>, Namhyung Kim <namhyung@kernel.org>, 
	Mark Rutland <mark.rutland@arm.com>, 
	Alexander Shishkin <alexander.shishkin@linux.intel.com>, Jiri Olsa <jolsa@kernel.org>, 
	Ian Rogers <irogers@google.com>, Adrian Hunter <adrian.hunter@intel.com>, 
	Kan Liang <kan.liang@linux.intel.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>, 
	Josh Poimboeuf <jpoimboe@kernel.org>, Pawan Gupta <pawan.kumar.gupta@linux.intel.com>, 
	Paolo Bonzini <pbonzini@redhat.com>, Andy Lutomirski <luto@kernel.org>, Arnd Bergmann <arnd@arndb.de>, 
	Frederic Weisbecker <frederic@kernel.org>, "Paul E. McKenney" <paulmck@kernel.org>, 
	Jason Baron <jbaron@akamai.com>, Steven Rostedt <rostedt@goodmis.org>, 
	Ard Biesheuvel <ardb@kernel.org>, Neeraj Upadhyay <neeraj.upadhyay@kernel.org>, 
	Joel Fernandes <joel@joelfernandes.org>, Josh Triplett <josh@joshtriplett.org>, 
	Boqun Feng <boqun.feng@gmail.com>, Uladzislau Rezki <urezki@gmail.com>, 
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>, Lai Jiangshan <jiangshanlai@gmail.com>, 
	Zqiang <qiang.zhang1211@gmail.com>, Juri Lelli <juri.lelli@redhat.com>, 
	Clark Williams <williams@redhat.com>, Yair Podemsky <ypodemsk@redhat.com>, 
	Tomas Glozar <tglozar@redhat.com>, Vincent Guittot <vincent.guittot@linaro.org>, 
	Dietmar Eggemann <dietmar.eggemann@arm.com>, Ben Segall <bsegall@google.com>, 
	Mel Gorman <mgorman@suse.de>, Kees Cook <kees@kernel.org>, 
	Andrew Morton <akpm@linux-foundation.org>, Christoph Hellwig <hch@infradead.org>, 
	Shuah Khan <shuah@kernel.org>, Sami Tolvanen <samitolvanen@google.com>, 
	Miguel Ojeda <ojeda@kernel.org>, Alice Ryhl <aliceryhl@google.com>, 
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>, Samuel Holland <samuel.holland@sifive.com>, Rong Xu <xur@google.com>, 
	Geert Uytterhoeven <geert@linux-m68k.org>, Yosry Ahmed <yosryahmed@google.com>, 
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>, 
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>, Jinghao Jia <jinghao7@illinois.edu>, 
	Luis Chamberlain <mcgrof@kernel.org>, Randy Dunlap <rdunlap@infradead.org>, 
	Tiezhu Yang <yangtiezhu@loongson.cn>
Content-Type: text/plain; charset="us-ascii"

On Tue, Jan 14, 2025, Sean Christopherson wrote:
> On Tue, Jan 14, 2025, Valentin Schneider wrote:
> > +/**
> > + * is_kernel_noinstr_text - checks if the pointer address is located in the
> > + *                    .noinstr section
> > + *
> > + * @addr: address to check
> > + *
> > + * Returns: true if the address is located in .noinstr, false otherwise.
> > + */
> > +static inline bool is_kernel_noinstr_text(unsigned long addr)
> > +{
> > +	return addr >= (unsigned long)__noinstr_text_start &&
> > +	       addr < (unsigned long)__noinstr_text_end;
> > +}
> 
> This doesn't do the right thing for modules, which matters because KVM can be
> built as a module on x86, and because context tracking understands transitions
> to GUEST mode, i.e. CPUs that are running in a KVM guest will be treated as not
> being in the kernel, and thus will have IPIs deferred.  If KVM uses a static key
> or branch between guest_state_enter_irqoff() and guest_state_exit_irqoff(), the
> patching code won't wait for CPUs to exit guest mode, i.e. KVM could theoretically
> use the wrong static path.
> 
> I don't expect this to ever cause problems in practice, because patching code in
> KVM's VM-Enter/VM-Exit path that has *functional* implications, while CPUs are
> actively running guest code, would be all kinds of crazy.  But I do think we
> should plug the hole.
> 
> If this issue is unique to KVM, i.e. is not a generic problem for all modules (I
> assume module code generally isn't allowed in the entry path, even via NMI?), one
> idea would be to let KVM register its noinstr section for text poking.

Another idea would be to track which keys/branches are tagged noinstr, i.e. generate
the information at compile time instead of doing lookups at runtime.  The biggest
downside I can think of is that it would require plumbing in the information to
text_poke_bp_batch().


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 23:49:29 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 23:49:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872121.1283069 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXqeo-0006Lt-A9; Tue, 14 Jan 2025 23:49:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872121.1283069; Tue, 14 Jan 2025 23:49:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXqeo-0006Lm-7J; Tue, 14 Jan 2025 23:49:14 +0000
Received: by outflank-mailman (input) for mailman id 872121;
 Tue, 14 Jan 2025 23:49:13 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=weCb=UG=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tXqem-0006LN-UG
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 23:49:12 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org
 [2604:1380:45d1:ec00::3])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 262f3d8d-d2d2-11ef-a0e1-8be0dac302b0;
 Wed, 15 Jan 2025 00:49:10 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 0D91DA41C6D;
 Tue, 14 Jan 2025 23:47:21 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3214EC4CEDD;
 Tue, 14 Jan 2025 23:49:07 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 262f3d8d-d2d2-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1736898548;
	bh=RgPg59Ts7B4pYtXzdyHWtz3olTjWe0YNR0pHfGm1NuA=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=k3+YolcGBxmgS7CUpCZHwKyRpYOW2lN8GxMFJ+BAjdkQdjRYlka1V2Aw/vHsGZyPO
	 tO+9HC7tErg5J1uTt9Tv1mgWW5/xGoBbo13TOz9vV7af6NC1BBJl5J6S9MOrspOwjX
	 U/RYskYpYfrnntys0JEDyt5fLv+xWjx3HQKE5kWjE48joHz4LJAcMKEzVA5OagTNbb
	 QAVfuPlyG3/ujglL+9S67UR1YizQ88UrIC4S365bnQXOZCkHmE+Q45JHtejb4SdXpw
	 OXnzZcgIiSu7FPUfjpk97pahQ6HKIbzkoNkc9Zpkfne5LW6UUQDRfB+OFE1onaAI3a
	 VyIf4MSRTIQIQ==
Date: Tue, 14 Jan 2025 15:49:01 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Simone Ballarin <simone.ballarin@bugseng.com>
cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
    xen-devel@lists.xenproject.org, sstabellini@kernel.org, 
    michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, 
    consulting@bugseng.com, Andrew Cooper <andrew.cooper3@citrix.com>, 
    Anthony PERARD <anthony.perard@vates.tech>, 
    Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>, 
    Nicola Vetrini <nicola.vetrini@bugseng.com>
Subject: Re: [XEN PATCH] MAINTAINERS: Change reviewer of the ECLAIR
 integration
In-Reply-To: <31259db8185522b14a61ac021f76d6fd@bugseng.com>
Message-ID: <alpine.DEB.2.22.394.2501141548550.2684657@ubuntu-linux-20-04-desktop>
References: <8c370ced911457c883360836bd5afda747426a13.1736856521.git.nicola.vetrini@bugseng.com> <Z4Z8IMWuz0UqldN9@macbook.local> <31259db8185522b14a61ac021f76d6fd@bugseng.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-2022425227-1736898548=:2684657"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-2022425227-1736898548=:2684657
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Tue, 14 Jan 2025, Simone Ballarin wrote:
> On 2025-01-14 16:00, Roger Pau Monné wrote:
> > On Tue, Jan 14, 2025 at 03:48:54PM +0100, Nicola Vetrini wrote:
> > > Simone Ballarin is no longer actively involved in reviewing
> > > the ECLAIR integration for Xen. I am stepping up as a reviewer.
> > > 
> > > Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
> > 
> > Acked-by: Roger Pau Monné <roger.pau@citrix.com>
> > 
> 
> Acked-by: Simone Ballarin <simone.ballarin@bugseng.com>

Acked-by: Stefano Stabellini <sstabellini@kernel.org>
--8323329-2022425227-1736898548=:2684657--


From xen-devel-bounces@lists.xenproject.org Tue Jan 14 23:50:03 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Jan 2025 23:50:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872128.1283080 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXqfb-0007BM-Ju; Tue, 14 Jan 2025 23:50:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872128.1283080; Tue, 14 Jan 2025 23:50:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXqfb-0007Al-FI; Tue, 14 Jan 2025 23:50:03 +0000
Received: by outflank-mailman (input) for mailman id 872128;
 Tue, 14 Jan 2025 23:50: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
 <SRS0=weCb=UG=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tXqfZ-0006o9-NS
 for xen-devel@lists.xenproject.org; Tue, 14 Jan 2025 23:50:01 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 428ed675-d2d2-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 00:49:57 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id E2C55A41DBA;
 Tue, 14 Jan 2025 23:48:08 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id C2C4BC4CEDD;
 Tue, 14 Jan 2025 23:49:55 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 428ed675-d2d2-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1736898596;
	bh=JD9NzxRFWErx3OXTgkffv3WN8CHR5a0OqAXtNpc3WnU=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=S59B7bAa0T4esnWzMsc/5Ya5m75I3cJdc3ATOHx63X5PifK3PFld7o09tf/tXY9W5
	 9C0+KRRenW2kHUuZ6A5WXgW1DuauUaVxmemroZeN/QL7N5l8GrMy25y9BHnnc/SDhh
	 6JQyO8MiHbYG84JTJl+eKDOwXOvbZ+3Ha856gj3YUdmgsB5PH2tprOAipyMRu+fxk2
	 oq30JGaDi9qUt/EeIYWosBX/S1ynE3HaD5c9EolKwMq9v6AHHds1sXxEfeXPHb5dz0
	 7LN1KRtsY6d89nIKGkhyqBcYTCtsAw7/2tq9pRBj5NaO+xlvjwNlUYaoC9L9eJ7P4b
	 UyQCl2DFtfKlw==
Date: Tue, 14 Jan 2025 15:49:54 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Andrew Cooper <andrew.cooper3@citrix.com>
cc: Roger Pau Monne <roger.pau@citrix.com>, xen-devel@lists.xenproject.org, 
    Doug Goldstein <cardoe@cardoe.com>, 
    Stefano Stabellini <sstabellini@kernel.org>, 
    Oleksii Kurochko <oleksii.kurochko@gmail.com>
Subject: Re: [PATCH for-4.20] automation/gitlab: disable coverage from clang
 randconfig
In-Reply-To: <c715348e-0f40-4ac4-b38e-1aead29cde52@citrix.com>
Message-ID: <alpine.DEB.2.22.394.2501141549460.2684657@ubuntu-linux-20-04-desktop>
References: <20250114174345.60887-1-roger.pau@citrix.com> <c715348e-0f40-4ac4-b38e-1aead29cde52@citrix.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1865805318-1736898596=:2684657"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-1865805318-1736898596=:2684657
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Tue, 14 Jan 2025, Andrew Cooper wrote:
> On 14/01/2025 5:43 pm, Roger Pau Monne wrote:
> > If randconfig enables coverage support the build times out due to GNU LD
> > taking too long.  For the time being prevent coverage from being enabled in
> > clang randconfig job.
> >
> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> 
> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

Acked-by: Stefano Stabellini <sstabellini@kernel.org>
--8323329-1865805318-1736898596=:2684657--


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 00:01:53 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 00:01:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872137.1283090 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXqqz-0006LM-5u; Wed, 15 Jan 2025 00:01:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872137.1283090; Wed, 15 Jan 2025 00:01:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXqqz-0006LF-2P; Wed, 15 Jan 2025 00:01:49 +0000
Received: by outflank-mailman (input) for mailman id 872137;
 Wed, 15 Jan 2025 00:01:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=9vXr=UH=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tXqqx-0006L9-Re
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 00:01:47 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e85b26fa-d2d3-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 01:01:45 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 3E331A41DF6;
 Tue, 14 Jan 2025 23:59:56 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id E1727C4CEDD;
 Wed, 15 Jan 2025 00:01:41 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e85b26fa-d2d3-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1736899304;
	bh=R5zLWF7CbOxpfboysM0ptUUtByEdQJcyaoamCb44Zic=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=AlM6PkkFCtHnMVVMSXFes10U94llQpl5jo1qnvjauWoEc/xd/Gi3pJJ8dpzMyOJkB
	 wTLYlybnW3hO+v9f8sIEOuaoRJoZRdh/cYVePR1YICKJyPGWCXopf8y9Wg0hVvIUhz
	 T7uvmjDQ9KQUkvyzZlJ2Q415HpZpyHJnmojbzHdTS3Hh/zvpUMoD1fIhbAKdQ4L2zd
	 q3qooO+8XJE9gowk3hWuMbzU99ZBXgqgW1ThEWyoHG+mmLa+XRPzi7kSYm7cNzZrD+
	 gj78gZrv2RsUo2wD/AUyFn/6p/hrrPsXf77+qZak86YY9DIlYAMVF7Tr4HUEnxBgin
	 MNvHxfndnkYew==
Date: Tue, 14 Jan 2025 16:01:40 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Milan Djokic <milandjokic1995@gmail.com>
cc: linux-riscv@lists.infradead.org, paul.walmsley@sifive.com, 
    palmer@dabbelt.com, aou@eecs.berkeley.edu, jgross@suse.com, 
    sstabellini@kernel.org, oleksandr_tyshchenko@epam.com, 
    Slavisa.Petrovic@rt-rk.com, Milan.Djokic@rt-rk.com, 
    rafael.j.wysocki@intel.com, sunilvl@ventanamicro.com, 
    takakura@valinux.co.jp, linux-kernel@vger.kernel.org, 
    xen-devel@lists.xenproject.org, iommu@lists.linux.dev, 
    oleksii.kurochko@gmail.com
Subject: Re: [PATCH] riscv: Add initial Xen guest support for RISC-V
In-Reply-To: <e4a649a7fdfc8fcf5f48a0bc4e76e5d546078083.1736868605.git.Slavisa.Petrovic@rt-rk.com>
Message-ID: <alpine.DEB.2.22.394.2501141554170.2684657@ubuntu-linux-20-04-desktop>
References: <e4a649a7fdfc8fcf5f48a0bc4e76e5d546078083.1736868605.git.Slavisa.Petrovic@rt-rk.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

+Oleksii

On Tue, 14 Jan 2025, Milan Djokic wrote:
> From: Slavisa Petrovic <Slavisa.Petrovic@rt-rk.com>
> 
> This patch introduces initial support for running RISC-V as a Xen guest.
> It provides the necessary infrastructure and stubs for Xen-specific
> operations. Key changes include:
> 
> - Modifications to the RISC-V kernel to integrate Xen-specific hypercalls
>   and interfaces, with function implementations stubbed for future work.
> - Introduction of Xen-specific headers for RISC-V, including event
>   handling, hypervisor interaction, and page management. Functions are
>   defined but not yet implemented.
> - Stub implementations for memory management, grant tables, and context
>   switching in the Xen environment, allowing further development and
>   integration.
> 
> Signed-off-by: Milan Djokic <Milan.Djokic@rt-rk.com>
> Signed-off-by: Slavisa Petrovic <Slavisa.Petrovic@rt-rk.com>

Hi Milan, Slavisa,

Thank you very much for your contribution! Which Xen tree are you using
for development? I am asking because RISC-V support in Xen is still in
the process of being upstreamed, and [1] is the tree that consolidates
all patches currently on the to-be-upstreamed list.  

While the specific Xen tree you are using is not particularly important
at this stage, and using [1] is not a requirement, I am asking because
it is essential to align on the hypervisor ABI, especially regarding any
details that have not yet been upstreamed. Specifically, is there
anything in this patch series that relies on features not yet upstream
in Xen?  

[1] https://gitlab.com/xen-project/people/olkur/xen/-/tree/latest?ref_type=heads


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 01:21:10 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 01:21:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872146.1283099 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXs5V-0003df-Ms; Wed, 15 Jan 2025 01:20:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872146.1283099; Wed, 15 Jan 2025 01:20:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXs5V-0003dY-KQ; Wed, 15 Jan 2025 01:20:53 +0000
Received: by outflank-mailman (input) for mailman id 872146;
 Wed, 15 Jan 2025 01:20:52 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=9vXr=UH=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tXs5U-0003Zb-Hb
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 01:20:52 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org
 [2604:1380:4641:c500::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f32d5789-d2de-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 02:20:48 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id BDD2D5C5A51;
 Wed, 15 Jan 2025 01:20:05 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 36952C4CEDD;
 Wed, 15 Jan 2025 01:20:45 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f32d5789-d2de-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1736904046;
	bh=ViiLC0GwU5LMLuDCizfF1e2xq5a/X9rUrRZGpA7LkhQ=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=pf9K8GRpaoM5VdrS2+Gg8HC4abfchCegNVHTuHowzWpGLSdIh5oGFqOxh34tqVvLI
	 p0ufFBPlZZU3O7B5PK9BtWSJ7ytkjd9UNiTnsulXue6PhMSg2Kjf3R4MRheC+DmPNT
	 hzCe74phPBKuzCw4Tod9dQCZ9/ZFjC9KJcb9uFUrT460MPtbEDz+3wXkgOvQqIuLQg
	 IGM9FxMT47vBzMPyX9NA/uI6Cpmr19gq97g2eyUzLNznUVnYbwIkYSBM3cs7jZGSVR
	 /0Hf5If5e2kX/DiDGblC/92ggv+43wHokXS+UEVVq8ftW6DmtwvEPl1sn75Je/xy6W
	 aNH3g8yNFxDww==
Date: Tue, 14 Jan 2025 17:20:43 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
cc: xen-devel@lists.xenproject.org, 
    Stefano Stabellini <sstabellini@kernel.org>, 
    Bertrand Marquis <bertrand.marquis@arm.com>, 
    Michal Orzel <michal.orzel@amd.com>, 
    Artem Mygaiev <artem_mygaiev@epam.com>
Subject: Re: [PATCH] docs: fusa: Fix OFT tags for the design requirements
In-Reply-To: <20250114185707.3376960-1-ayan.kumar.halder@amd.com>
Message-ID: <alpine.DEB.2.22.394.2501141720280.2684657@ubuntu-linux-20-04-desktop>
References: <20250114185707.3376960-1-ayan.kumar.halder@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Tue, 14 Jan 2025, Ayan Kumar Halder wrote:
> The OFT tags for the design requirements are updated.
> 
> Fixes: b9f9b396452 ("docs: fusa: Add dom0less domain configuration requirements")
> Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>


Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
>  .../reqs/design-reqs/arm64/generic-timer.rst  | 16 +++++-----
>  .../fusa/reqs/design-reqs/arm64/sbsa-uart.rst | 30 +++++++++----------
>  2 files changed, 23 insertions(+), 23 deletions(-)
> 
> diff --git a/docs/fusa/reqs/design-reqs/arm64/generic-timer.rst b/docs/fusa/reqs/design-reqs/arm64/generic-timer.rst
> index 9d2a5a8085..745e755638 100644
> --- a/docs/fusa/reqs/design-reqs/arm64/generic-timer.rst
> +++ b/docs/fusa/reqs/design-reqs/arm64/generic-timer.rst
> @@ -21,7 +21,7 @@ Comments:
>  Domains can detect the presence of the Generic Timer device tree node.
>  
>  Covers:
> - - `XenProd~emulated_timer~1`
> + - `XenProd~arm64_emulated_timer~1`
>  
>  Read system counter frequency
>  -----------------------------
> @@ -37,7 +37,7 @@ Rationale:
>  Comments:
>  
>  Covers:
> - - `XenProd~emulated_timer~1`
> + - `XenProd~arm64_emulated_timer~1`
>  
>  Access CNTKCTL_EL1 system register from a domain
>  ------------------------------------------------
> @@ -53,7 +53,7 @@ Rationale:
>  Comments:
>  
>  Covers:
> - - `XenProd~emulated_timer~1`
> + - `XenProd~arm64_emulated_timer~1`
>  
>  Access virtual timer from a domain
>  ----------------------------------
> @@ -69,7 +69,7 @@ Rationale:
>  Comments:
>  
>  Covers:
> - - `XenProd~emulated_timer~1`
> + - `XenProd~arm64_emulated_timer~1`
>  
>  Access physical timer from a domain
>  -----------------------------------
> @@ -85,7 +85,7 @@ Rationale:
>  Comments:
>  
>  Covers:
> - - `XenProd~emulated_timer~1`
> + - `XenProd~arm64_emulated_timer~1`
>  
>  Trigger the virtual timer interrupt from a domain
>  -------------------------------------------------
> @@ -101,7 +101,7 @@ Rationale:
>  Comments:
>  
>  Covers:
> - - `XenProd~emulated_timer~1`
> + - `XenProd~arm64_emulated_timer~1`
>  
>  Trigger the physical timer interrupt from a domain
>  --------------------------------------------------
> @@ -117,7 +117,7 @@ Rationale:
>  Comments:
>  
>  Covers:
> - - `XenProd~emulated_timer~1`
> + - `XenProd~arm64_emulated_timer~1`
>  
>  Assumption of Use on the Platform
>  =================================
> @@ -139,7 +139,7 @@ While there is a provision to get this value by reading the "clock-frequency"
>  dt property [2], the use of this property is strongly discouraged.
>  
>  Covers:
> - - `XenProd~emulated_timer~1`
> + - `XenProd~arm64_emulated_timer~1`
>  
>  [1] Arm Architecture Reference Manual for A-profile architecture, Chapter 11
>  [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
> diff --git a/docs/fusa/reqs/design-reqs/arm64/sbsa-uart.rst b/docs/fusa/reqs/design-reqs/arm64/sbsa-uart.rst
> index 89598fa8a5..9aaf081f16 100644
> --- a/docs/fusa/reqs/design-reqs/arm64/sbsa-uart.rst
> +++ b/docs/fusa/reqs/design-reqs/arm64/sbsa-uart.rst
> @@ -21,7 +21,7 @@ Comments:
>  Domains can detect the presence of the SBSA UART device tree node.
>  
>  Covers:
> - - `XenProd~emulated_uart~1`
> + - `XenProd~arm64_emulated_uart~1`
>  
>  Transmit data in software polling mode
>  --------------------------------------
> @@ -36,7 +36,7 @@ Rationale:
>  Comments:
>  
>  Covers:
> - - `XenProd~emulated_uart~1`
> + - `XenProd~arm64_emulated_uart~1`
>  
>  Transmit data in interrupt driven mode
>  --------------------------------------
> @@ -51,7 +51,7 @@ Rationale:
>  Comments:
>  
>  Covers:
> - - `XenProd~emulated_uart~1`
> + - `XenProd~arm64_emulated_uart~1`
>  
>  Receive data in software polling mode
>  -------------------------------------
> @@ -66,7 +66,7 @@ Rationale:
>  Comments:
>  
>  Covers:
> - - `XenProd~emulated_uart~1`
> + - `XenProd~arm64_emulated_uart~1`
>  
>  Receive data in interrupt driven mode
>  -------------------------------------
> @@ -81,7 +81,7 @@ Rationale:
>  Comments:
>  
>  Covers:
> - - `XenProd~emulated_uart~1`
> + - `XenProd~arm64_emulated_uart~1`
>  
>  Access UART data register
>  -------------------------
> @@ -96,7 +96,7 @@ Rationale:
>  Comments:
>  
>  Covers:
> - - `XenProd~emulated_uart~1`
> + - `XenProd~arm64_emulated_uart~1`
>  
>  Access UART receive status register
>  -----------------------------------
> @@ -111,7 +111,7 @@ Rationale:
>  Comments:
>  
>  Covers:
> - - `XenProd~emulated_uart~1`
> + - `XenProd~arm64_emulated_uart~1`
>  
>  Access UART flag register
>  -------------------------
> @@ -126,7 +126,7 @@ Rationale:
>  Comments:
>  
>  Covers:
> - - `XenProd~emulated_uart~1`
> + - `XenProd~arm64_emulated_uart~1`
>  
>  Access UART mask set/clear register
>  -----------------------------------
> @@ -141,7 +141,7 @@ Rationale:
>  Comments:
>  
>  Covers:
> - - `XenProd~emulated_uart~1`
> + - `XenProd~arm64_emulated_uart~1`
>  
>  Access UART raw interrupt status register
>  -----------------------------------------
> @@ -156,7 +156,7 @@ Rationale:
>  Comments:
>  
>  Covers:
> - - `XenProd~emulated_uart~1`
> + - `XenProd~arm64_emulated_uart~1`
>  
>  Access UART masked interrupt status register
>  --------------------------------------------
> @@ -171,7 +171,7 @@ Rationale:
>  Comments:
>  
>  Covers:
> - - `XenProd~emulated_uart~1`
> + - `XenProd~arm64_emulated_uart~1`
>  
>  Access UART interrupt clear register
>  ------------------------------------
> @@ -186,7 +186,7 @@ Rationale:
>  Comments:
>  
>  Covers:
> - - `XenProd~emulated_uart~1`
> + - `XenProd~arm64_emulated_uart~1`
>  
>  Receive UART TX interrupt
>  -------------------------
> @@ -202,7 +202,7 @@ Rationale:
>  Comments:
>  
>  Covers:
> - - `XenProd~emulated_uart~1`
> + - `XenProd~arm64_emulated_uart~1`
>  
>  Receive UART RX interrupt reception
>  -----------------------------------
> @@ -218,7 +218,7 @@ Rationale:
>  Comments:
>  
>  Covers:
> - - `XenProd~emulated_uart~1`
> + - `XenProd~arm64_emulated_uart~1`
>  
>  [1] Arm Base System Architecture, chapter B
> -[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt
> \ No newline at end of file
> +[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt
> -- 
> 2.25.1
> 


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 05:34:25 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 05:34:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872160.1283109 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXw2V-0007jc-P3; Wed, 15 Jan 2025 05:34:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872160.1283109; Wed, 15 Jan 2025 05:34:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXw2V-0007jV-MU; Wed, 15 Jan 2025 05:34:03 +0000
Received: by outflank-mailman (input) for mailman id 872160;
 Wed, 15 Jan 2025 05:34:02 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=9Lts=UH=amd.com=penny.zheng@srs-se1.protection.inumbo.net>)
 id 1tXw2U-0007jP-9e
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 05:34:02 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on2061b.outbound.protection.outlook.com
 [2a01:111:f403:2417::61b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 517b03be-d302-11ef-a0e1-8be0dac302b0;
 Wed, 15 Jan 2025 06:33:59 +0100 (CET)
Received: from IA1PR12MB8467.namprd12.prod.outlook.com (2603:10b6:208:448::9)
 by CH3PR12MB8281.namprd12.prod.outlook.com (2603:10b6:610:128::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8335.18; Wed, 15 Jan
 2025 05:33:56 +0000
Received: from IA1PR12MB8467.namprd12.prod.outlook.com
 ([fe80::1633:cc45:8177:a91e]) by IA1PR12MB8467.namprd12.prod.outlook.com
 ([fe80::1633:cc45:8177:a91e%4]) with mapi id 15.20.8335.017; Wed, 15 Jan 2025
 05:33:56 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 517b03be-d302-11ef-a0e1-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=pusByhohct6tRpMjzJpj485YPg1W4pEr/tMTgo0XNCoR6y+pFitnbsyxZTd3Bj8q6uvTAJ1JCJygGLeqGYInY4AkOpORsxwOP8qa+rmMi8WW56abfMPMwlj1N3F7+bLmpBHqHvIvB6SWF9WWpcYQWoKxOS+qvfF6QDm9KkQSOXV5bbVSTFGtfUC4YL+qjYBseQ9HR3boT+qtQuDCrT/rkU/nNjA2Qk9fl//IJamWaLS+QSqcmQA89UjE+BZCjjUp8EHH609qhuMku0RS0a7wYga264KdLPTe3wOrfYtUZHDZyJW4GX4w8qWcw4yhyDDavbGa7jyJtcbc4NCIMugr2A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=GmBL8C0qz1FweHezhzswXvl8N3X3qqe7gyaWPaO8p4c=;
 b=SDIGtHq9qHUHUdYCA+21xA67wpozR8wvSUxueBZNucd/HIkDQMz0WGKjVs6vv0gaIXx93YETzdADsVj1QpZWD8YBkVAu1UEzS8e7INbFJav8ejQ4rrDZ2DXV5kgEF6ZNCc3aD/fSw3qPfLCZRMi7XhotjyB+KU/dqt7f9GA97R2UByL9T2T14Wt+6hlaxcVcEMvQhgyziq8SYhPoFBvEh1MQM4HBSxuvA4dUfw0Qajo/zJmSfG6vBq16fuGbsfILtzrheeNrD0w8wLuOASgtbnnqEE/8UTpFlwrwvZy55cBHynx6RFBnFgaTp2MCoUN+Gjl+5ldTH2PuuPerOt8mVg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=GmBL8C0qz1FweHezhzswXvl8N3X3qqe7gyaWPaO8p4c=;
 b=mHyJQZl7yZgv2CNWpeXP84XahdrkWyuESWed0SOdt8T9bPpw4SKOT2emPD/uOD3WpPj2zRYG4DLyK4uPZBySn1WXqxWj+3Wt0H9wV+0E4DEbTG1NwrnFN0is8pF4vadfn8HDWYlzPsBKE/pf4DxZbug1VVIIfPfBnQE1lTnPK48=
From: "Penny, Zheng" <penny.zheng@amd.com>
To: Jan Beulich <jbeulich@suse.com>
CC: "Stabellini, Stefano" <stefano.stabellini@amd.com>, "Huang, Ray"
	<Ray.Huang@amd.com>, "Ragiadakou, Xenia" <Xenia.Ragiadakou@amd.com>,
	"Andryuk, Jason" <Jason.Andryuk@amd.com>, Andrew Cooper
	<andrew.cooper3@citrix.com>, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	<roger.pau@citrix.com>, Julien Grall <julien@xen.org>, Stefano Stabellini
	<sstabellini@kernel.org>, "xen-devel@lists.xenproject.org"
	<xen-devel@lists.xenproject.org>
Subject: RE: [PATCH v1 02/11] xen/x86: introduce new sub-hypercall to get CPPC
 data
Thread-Topic: [PATCH v1 02/11] xen/x86: introduce new sub-hypercall to get
 CPPC data
Thread-Index: AQHbRVx2Xy1QS0W8Lk2Jl10Jg0sbebMOa8AAgAEtx8A=
Date: Wed, 15 Jan 2025 05:33:56 +0000
Message-ID:
 <IA1PR12MB84679A0D60CD4219E9C1A01FE1192@IA1PR12MB8467.namprd12.prod.outlook.com>
References: <20241203081111.463400-1-Penny.Zheng@amd.com>
 <20241203081111.463400-3-Penny.Zheng@amd.com>
 <95183589-1a83-4c99-ade4-d37873b85e0a@suse.com>
In-Reply-To: <95183589-1a83-4c99-ade4-d37873b85e0a@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_ActionId=ac772a5a-ee3f-4b7f-b727-a76e3ee3232a;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_ContentBits=0;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_Enabled=true;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_Method=Standard;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_Name=AMD
 Internal Distribution
 Only;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_SetDate=2025-01-10T03:45:44Z;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: IA1PR12MB8467:EE_|CH3PR12MB8281:EE_
x-ms-office365-filtering-correlation-id: c5983e2d-f26e-47eb-f837-08dd35263488
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?K3Q1aTRpRUxTNjR4Vm8wRUJCN0lDbnRJNkNqaFpGa0RKWU9VVzV1Um8wS1NP?=
 =?utf-8?B?OXhYV215cUd5c3ZsMkVSYjNYWVdjZDlmSnZVRjEvTklzYUw2ZEFkS2tkZzdl?=
 =?utf-8?B?V0t4ZC9LQjkzRllCaGZ6ZnBHR1JaWVNMTGUxVGVORXltbUJkanZMMEVSemtv?=
 =?utf-8?B?NFJrcnQ3SXhacVJmTzdKL2lCVFJicFRkMGNYV0xEQlFabVUwQjcrODNaMzBX?=
 =?utf-8?B?Z0JBWnNBSGJod0FJTXBPeUh2bWliMkRub0NIbkdYVDBqczZPYi9nQUwwSlBH?=
 =?utf-8?B?ZXhLdTN3N3JUUmhacGYrQkFPTGgwT29kTGRGMWtyV1Q0V1I2QVZWVlMwUG1s?=
 =?utf-8?B?aUUvN3RJU25NVXEwK1BRQUJNM0l5ZlcyR2JXTkNGS1IrMVRPSWpjZWIxZk5Y?=
 =?utf-8?B?MG04a2NITTZNVjFvNTVOdmxRa2dHYUphWEordzBoQUhRazBOZ2c4OEpYRUg5?=
 =?utf-8?B?U0Y0SkYvMTJMQ3RGMWMrVnhLRVpjQ2x0NXVsYnZOTVF2UC9xMTl0V2RHRDNu?=
 =?utf-8?B?ampueGNwU3ZyMU1uRUtnbzJoUVpZNCtRMnN2RnYxMFJYcHZkZkJXdllIdXJq?=
 =?utf-8?B?Sk4wWlAwWGN6RUJWcGs4TXB6VW1CVHhaK1pldjlKT2xnbm1pTjc5cW5DbFM1?=
 =?utf-8?B?WEVxT2doNllocWZ5eUhBTU5tMGRYbnZEN0lhVmZxekIzK25CSlhKUjBmRkhN?=
 =?utf-8?B?NHVkanVMK3FydWUxTUdEZ29QYkR0ZXJEMzZ6cE9VUllSamFqMzV4SVllR2t1?=
 =?utf-8?B?Q0xZcW85MWlSOFVmaFJDOE1ydE5LeVU4Y2tHN0JLQWJTeG9jL25sM05wMUw3?=
 =?utf-8?B?Yk5Ed3BnZTV6R0VQMW43OUZ2VWxaN0p3T05zWFdWSWlnS1A1MkRmN2NFd2gr?=
 =?utf-8?B?S3UxNlBSY1pPVmpiYkNiWTlhNHd6NjltbmdYU3EwRG1pRGFIMmsxZHdKWjdj?=
 =?utf-8?B?QkhwZHFEM0xFS0RoNHhRckEvWkNlak1ER3dna3kzMlZhTndiNVB0eGF0VE12?=
 =?utf-8?B?bWxOT25Qb250Y3JCMmtnajd3bVVQUFZSQ2lKL2xMQjZXQjlSK0h5VTFYbkYv?=
 =?utf-8?B?VEhmQUF0d09lMU9zL2drN0xQUjBIOGxYMG8vZHEwSEd4NjY0MldtSVVNZjFa?=
 =?utf-8?B?Q0NNcG90VmdDckxDVGlGK0thU1o1eENRa3BhWXVlNjJIU1J3OFlGME90clQy?=
 =?utf-8?B?NUhTNjhwMHVoTThPNDJxelByVUU4eG9Wa3AwaG1LTGttbGxtYlhmVnlEbUx4?=
 =?utf-8?B?Mi8vQmt0RWh0RmRqUnovdnhWT1Ywb1JPbGtpejVmZ0FtVmFGeHcvOXBwOVdx?=
 =?utf-8?B?ZWh2TFEvRjRWUnVKSTdiUHErdFZtaG81U2p0K2VSS1h4OGYwWktsUDBjMkZ2?=
 =?utf-8?B?WFBNU1M3REQxWDlxNHhLOEQvdGVJSGZTZXEwL2NzZDZFMEtBQkRTQUM2UVpN?=
 =?utf-8?B?RTRsNnBnRWtjMDBoRWZNckJ4ZHFtYXV6SEd1K0RHSVlnVTlKTkNaMzJyK3V2?=
 =?utf-8?B?OVVRcjZjamQxRlRzN3k5UU5jeFFhTEp4OFBZSlRybUZBMkxFd1owQm9xY0ti?=
 =?utf-8?B?d3k1VndPUlYra2J2RC9RRFNiVS9aL3czVnpsVmFpbytvdzV1N2JSSmtQZGlV?=
 =?utf-8?B?TGdIQytTR3BaOTVBUEQ4R2pLWE44eHp2RHRqSHA1NzdRZm50RDhNUTlJVVY3?=
 =?utf-8?B?MHRhalN1K20xK2JXdFBlTnExRll3VTRsWTBhdkxxRUJZMHY4cmF1T25Iemo0?=
 =?utf-8?B?TVMra0JWeExSWVVCc01wVCtVVzV4eU5tNEtETnpVdmE5dUt0K2ovNDNxUGZV?=
 =?utf-8?B?MFVIYXdVOEI5anQwb29mbVFEYnhlZ3lJZFVJNWc5WEJCdjBES1pOYTZWNW9J?=
 =?utf-8?B?ZWZIekw5ZEhtL3VWNzVxcGVtV1BFYXdMeit6b29aQUt1S3NSeFM3UDZpT3hx?=
 =?utf-8?Q?zRIIpzld0PZe3VQvApKnhBsKiw/8MG5D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:IA1PR12MB8467.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?UUxIemJIOGpFOVpjMnJQUW82ekN2SWFjcUlHdDZ2YlUrWHhtbDJTKzRhWk1J?=
 =?utf-8?B?bG05Smgwa0FDVTFJall2SW0xb1M4aEhCdHAzanBIbC9qV1Yvdy9YSDBwNTVE?=
 =?utf-8?B?VnlxS2NrZEFvWHYwVGY3ZlBmTk56Y3NtL2RDUDd4MGMrcnpod1Jab1lOcW5t?=
 =?utf-8?B?RkVSQURtNVJtYWlIeTkwVFJDRFBIajVpWG1HT3p3bjA4bDZhVXVEWDZ0WWJ5?=
 =?utf-8?B?VDh2dGwxOTBXb3FhbjEzaXZKeVNWdE1VdTNXOTRWS2hVaDdEQXJSQUVGMVIv?=
 =?utf-8?B?L3VKR01lRlZldUlTeG0rMWZ6OUl5Um0zUTY0b0NmeXgwNTRQL3hQa1pIUmdC?=
 =?utf-8?B?dXgrYXdZUFhKYXpZY2swcXoxQ2l2cDV6WlByM1ZiOVJPcW5tMmYrTFJGTnRn?=
 =?utf-8?B?OUpQS05MM2JzRzNUZkRFRjhUZWxsVklhUkdQYVVDU2xZZ0kwdEZlZVFvakVr?=
 =?utf-8?B?dFd0bHpoV1BGMm03OVhPOWVmWWMvU3AwaUt2b0R6L1ZmMlR0b29JTDlVZDBG?=
 =?utf-8?B?Rmowd1BFSEtUUEdqSHFDNlFHY2VVOHdqQ1UrcUxqT21ySy8zTkhFaG5PcTU5?=
 =?utf-8?B?Tnk4VG8xWksxaE5wMUNoWFJtcHNscTFCeHRhMlBYeE13bzl5MlpEaW9BQ3Mr?=
 =?utf-8?B?OGMvYXVOTW0zMlF0VWtWcmt3STA5a3BzbzlFR0VYQzlqT2U1N2g2MlB5MUgx?=
 =?utf-8?B?YjBjMEVURnV0WDBNTmZndjFtajE1NFd3VU15YTJYaXUrRUpRUHFwYjVNWEVZ?=
 =?utf-8?B?Q2ZpdDhtdU1xNU5GZHAyeXNNeURUTm5NWVd6bGpjOFEyVmdXTXNMNDVVMmZm?=
 =?utf-8?B?dVpmRW1Tb3dqZ1RqY0Nlem1FY3NDTEtISUtMbUpHc3FBdmk0cGE5NE9LMUZB?=
 =?utf-8?B?RnJZOEhsMkovRDlrTElzSmIyN1NCNHRDWGE3VHpuVURONDNjMEtOMVNQZ2ZG?=
 =?utf-8?B?Vi80Rlc1aTBxSnVRUzUvZmcyWnlUUU1sM1RDR2Z2Ykt5RGEremhrMVl2UjRi?=
 =?utf-8?B?U0VkLzM5ZjZKbjFaOVlWL2VoVndITStSV0xSbkNzREpoL3RLMzBQTVJkeWls?=
 =?utf-8?B?UVM1M1BqQ2dxbXNYK2VucUhueGl0T01BeFhQZWdqUVpOdVYvVTA4Y2Z0b2l6?=
 =?utf-8?B?VmIvMUZnYkQ4MmRsNUNxUDduaWJkMWFYRnJjMmxHemtoK1lJTzdsYXBHSnRU?=
 =?utf-8?B?eC9YdG9XVkl3elBUM1pwVUdqMXkwVG55eU5xdWozcE9CQmYvVWNMeDZNcTNS?=
 =?utf-8?B?ZnlSRGFINTRtRUlMcTlWd3VpWWdIMzVJT3U4MUlOd2FYQ3lzNE5paHI3MGhE?=
 =?utf-8?B?WG1oc1VwWW1zTVNrdUp6MEpadHIxWjdRRHRLNE5qd0QxY2l4LzdWbUwzWW9v?=
 =?utf-8?B?U2JsSkpmOFhjelVValdSU0ZUWkRGUWdWM2JSNFJKbVgrb3VjdUp3Q3Z1c05C?=
 =?utf-8?B?NFFIVCtSSmhUU1F1RmcvaXdvNXNGaG5SckhpRW5JTmE3NG9jYUlGVWt4RU1W?=
 =?utf-8?B?Z2lTRlFVRWVYQ3doR1U5ZkhBZmpsYjRMN2ZTb0JTWDZodGFqTHFsU1YreU1n?=
 =?utf-8?B?M2xodnZzb1FWZmtGZTNrM09UNWl3eUtmT0tLK3NJMFdXdHA2VzY3aG5DbEUx?=
 =?utf-8?B?dVZEaE5sLy9WbTlETktycFVDT1ZaaS9Ga0VMOTNLYVlKcE15RkhTNm5OdnVH?=
 =?utf-8?B?VFE0NC9qT2Rub0h6U09WTkJvSStwUGF5MXpIcHhDU0U2VXZYUjdhNU9qT0ta?=
 =?utf-8?B?WW5mU3VlaXI5cEVUM1JuR2lVYWJ1VUs2S0E4dU45eXVPeXB4VCtQclpieTZU?=
 =?utf-8?B?RG53djJCYkovZDlVdWRDWE81R1ZCOERZMnpqZVNKZTNURDExYzJncTZKU0RG?=
 =?utf-8?B?YjJEOWpYMXV3SDVzbGFuUk5SNTJkNW1EMjJEREFRK0drbjRDNTFsMVJudENs?=
 =?utf-8?B?c082YTB4U0h1RnR4U0plYkt0UlJrT1B0SC9SenU3dWtYN0hzNlA0MDlKWjBa?=
 =?utf-8?B?MGRxbHVjaFBzNmxkWWdzU09UbURTZysraDRCTVRNdVZuYmFBNno4VjdBYkZi?=
 =?utf-8?B?SmpOUmlrT2FZSTlMbDdiLzU0ZEp6YzVHMmprLzFiYldtT21sNkFUZzhEbklt?=
 =?utf-8?Q?makk=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: IA1PR12MB8467.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c5983e2d-f26e-47eb-f837-08dd35263488
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2025 05:33:56.2280
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: msJkVMj6t/GvDZxOaBTvCDwPtqdDRXA+hjKmx+p2F0FnPO3vEQE3HnusMg7SnUFOZhENDoh8ovDsmpAsqe9ANQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB8281

W0FNRCBPZmZpY2lhbCBVc2UgT25seSAtIEFNRCBJbnRlcm5hbCBEaXN0cmlidXRpb24gT25seV0N
Cg0KSGksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSmFuIEJldWxp
Y2ggPGpiZXVsaWNoQHN1c2UuY29tPg0KPiBTZW50OiBUaHVyc2RheSwgSmFudWFyeSA5LCAyMDI1
IDU6NDYgUE0NCj4gVG86IFBlbm55LCBaaGVuZyA8cGVubnkuemhlbmdAYW1kLmNvbT4NCj4gQ2M6
IFN0YWJlbGxpbmksIFN0ZWZhbm8gPHN0ZWZhbm8uc3RhYmVsbGluaUBhbWQuY29tPjsgSHVhbmcs
IFJheQ0KPiA8UmF5Lkh1YW5nQGFtZC5jb20+OyBSYWdpYWRha291LCBYZW5pYSA8WGVuaWEuUmFn
aWFkYWtvdUBhbWQuY29tPjsNCj4gQW5kcnl1aywgSmFzb24gPEphc29uLkFuZHJ5dWtAYW1kLmNv
bT47IEFuZHJldyBDb29wZXINCj4gPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+OyBSb2dlciBQ
YXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT47IEp1bGllbg0KPiBHcmFsbCA8anVsaWVu
QHhlbi5vcmc+OyBTdGVmYW5vIFN0YWJlbGxpbmkgPHNzdGFiZWxsaW5pQGtlcm5lbC5vcmc+OyB4
ZW4tDQo+IGRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0gg
djEgMDIvMTFdIHhlbi94ODY6IGludHJvZHVjZSBuZXcgc3ViLWh5cGVyY2FsbCB0byBnZXQgQ1BQ
Qw0KPiBkYXRhDQo+DQo+IE9uIDAzLjEyLjIwMjQgMDk6MTEsIFBlbm55IFpoZW5nIHdyb3RlOg0K
PiA+IEluIG9yZGVyIHRvIHByb3ZpZGUgYmFja3dhcmQgY29tcGF0aWJpbGl0eSB3aXRoIGV4aXN0
aW5nIGdvdmVybm9ycw0KPiA+IHRoYXQgcmVwcmVzZW50IHBlcmZvcm1hbmNlIGFzIGZyZXF1ZW5j
aWVzLCBsaWtlIG9uZGVtYW5kLCB0aGUgX0NQQw0KPiA+IHRhYmxlIGNhbiBvcHRpb25hbGx5IHBy
b3ZpZGUgcHJvY2Vzc29yIGZyZXF1ZW5jeSByYW5nZSB2YWx1ZXMsIExvd2VzdA0KPiA+IGZyZXF1
ZW5jeSBhbmQgTm9ybWluYWwgZnJlcXVlbmN5LCB0byBsZXQgT1MgdXNlIExvd2VzdCBGcmVxdWVu
Y3kvDQo+ID4gUGVyZm9ybWFuY2UgYW5kIE5vbWluYWwgRnJlcXVlbmN5L1BlcmZvcm1hbmNlIGFz
IGFuY2hvciBwb2ludHMgdG8NCj4gPiBjcmVhdGUgbGluZWFyIG1hcHBpbmcgb2YgQ1BQQyBhYnN0
cmFjdCBwZXJmb3JtYW5jZSB0byBDUFUgZnJlcXVlbmN5Lg0KPiA+DQo+ID4gQXMgWGVuIGlzIHVu
Y2FwYWJsZSBvZiBwYXJzaW5nIHRoZSBBQ1BJIGR5bmFtaWMgdGFibGUsIHRoaXMgY29tbWl0DQo+
ID4gaW50cm9kdWNlcyBhIG5ldyBzdWItaHlwZXJjYWxsIHRvIGdldCByZXF1aXJlZCBDUFBDIGRh
dGEgZnJvbQ0KPiA+IGRvbTAga2VybmVsLg0KPg0KPiAiZ2V0IiBhcyB1c2VkIGJvdGggaGVyZSBh
bmQgaW4gdGhlIHRpdGxlIGlzLCB0byBtZSwgc29tZXRoaW5nIGFuIGVudGl0eSBkb2VzIGFjdGl2
ZWx5Lg0KPiBYZW4gaXMgZW50aXJlbHkgcGFzc2l2ZSBoZXJlLCB0aG91Z2guIChSZWFkaW5nIHRo
ZSB0aXRsZSBJIHdhcyBmaXJzdCBhc3N1bWluZyB0aGlzIGlzDQo+IGFib3V0IGEgc3ViLW9wIHRv
IGdldCBjZXJ0YWluIGRhdGEgb3V0IG9mDQo+IFhlbi4pDQoNCkhvdyBhYm91dCAiYSBuZXcgc3Vi
LWh5cGVyY2FsbCB0byBwYXNzL2RlbGl2ZXIgQ1BQQyB0byBYZW4iPyBvciBhbnkgYmV0dGVyIHN1
Z2dlc3Rpb25zPw0KDQo+DQo+ID4gLS0tIGEveGVuL2FyY2gveDg2L3BsYXRmb3JtX2h5cGVyY2Fs
bC5jDQo+ID4gKysrIGIveGVuL2FyY2gveDg2L3BsYXRmb3JtX2h5cGVyY2FsbC5jDQo+ID4gQEAg
LTU3Miw2ICs1NzIsMTIgQEAgcmV0X3QgZG9fcGxhdGZvcm1fb3AoDQo+ID4gICAgICAgICAgICAg
IGJyZWFrOw0KPiA+ICAgICAgICAgIH0NCj4gPg0KPiA+ICsgICAgICAgIGNhc2UgWEVOX1BNX0NQ
UEM6DQo+ID4gKyAgICAgICAgew0KPiA+ICsgICAgICAgICAgICByZXQgPSBzZXRfY3BwY19wbWlu
Zm8ob3AtPnUuc2V0X3BtaW5mby5pZCwgJm9wLQ0KPiA+dS5zZXRfcG1pbmZvLnUuY3BwY19kYXRh
KTsNCj4gPiArICAgICAgICB9DQo+ID4gKyAgICAgICAgYnJlYWs7DQo+DQo+IE5vIHN1Y2ggdW5u
ZWNlc3NhcnkgZmlndXJlIGJyYWNlcyBwbGVhc2UsIHdoaWNoIC0gb25jZSBkcm9wcGVkIC0gd2ls
bCBhbHNvIGNhbGwgZm9yDQo+ICJicmVhayIgdG8gYmUgaW5kZW50ZWQgb25lIGxldmVsIGRlZXBl
ci4NCg0KVW5kZXJzdG9vZC4NCg0KPg0KPiA+IC0tLSBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvY3B1
ZnJlcS5jDQo+ID4gKysrIGIveGVuL2FyY2gveDg2L3g4Nl82NC9jcHVmcmVxLmMNCj4gPiBAQCAt
NTQsMyArNTQsMjEgQEAgaW50IGNvbXBhdF9zZXRfcHhfcG1pbmZvKHVpbnQzMl90IGFjcGlfaWQs
DQo+ID4NCj4gPiAgICAgIHJldHVybiBzZXRfcHhfcG1pbmZvKGFjcGlfaWQsIHhlbl9wZXJmKTsg
IH0NCj4gPiArDQo+ID4gK2ludCBjb21wYXRfc2V0X2NwcGNfcG1pbmZvKHVpbnQzMl90IGFjcGlf
aWQsDQo+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0cnVjdCBjb21wYXRfcHJvY2Vz
c29yX2NwcGMgKmNwcGNfZGF0YSkgew0KPiA+ICsgICAgc3RydWN0IHhlbl9wcm9jZXNzb3JfY3Bw
YyAqeGVuX2NwcGM7DQo+ID4gKyAgICB1bnNpZ25lZCBsb25nIHhsYXRfcGFnZV9jdXJyZW50Ow0K
PiA+ICsNCj4gPiArICAgIHhsYXRfbWFsbG9jX2luaXQoeGxhdF9wYWdlX2N1cnJlbnQpOw0KPiA+
ICsNCj4gPiArICAgIHhlbl9jcHBjID0geGxhdF9tYWxsb2NfYXJyYXkoeGxhdF9wYWdlX2N1cnJl
bnQsDQo+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0cnVjdCB4ZW5f
cHJvY2Vzc29yX2NwcGMsIDEpOw0KPiA+ICsgICAgaWYgKCB1bmxpa2VseSh4ZW5fY3BwYyA9PSBO
VUxMKSApDQo+ID4gKyAgICAgICAgcmV0dXJuIC1FRkFVTFQ7DQo+ID4gKw0KPiA+ICsgICAgWExB
VF9wcm9jZXNzb3JfY3BwYyh4ZW5fY3BwYywgY3BwY19kYXRhKTsNCj4gPiArDQo+ID4gKyAgICBy
ZXR1cm4gc2V0X2NwcGNfcG1pbmZvKGFjcGlfaWQsIHhlbl9jcHBjKTsgfQ0KPg0KPiBXaHkncyB0
aGlzIG5lZWRlZD8gVGhlIHN0cnVjdHVyZSAtIGZvciBub3cgYXQgbGVhc3QgLSBjb25zaXN0cyBv
ZiBvbmx5IHVpbnQzMl90LXMsDQo+IGFuZCBoZW5jZSBoYXMgaWRlbnRpY2FsIGxheW91dCBmb3Ig
Y29tcGF0IGNhbGxlcnMuDQo+DQoNClVuZGVyc3Rvb2QuIE5vdCBmYW1pbGlhciB3aXRoIHRoZSBj
b21wYXQgZnJhbWV3b3JrDQoNCj4gPiAtLS0gYS94ZW4vZHJpdmVycy9jcHVmcmVxL2NwdWZyZXEu
Yw0KPiA+ICsrKyBiL3hlbi9kcml2ZXJzL2NwdWZyZXEvY3B1ZnJlcS5jDQo+ID4gQEAgLTQ1OCw2
ICs0NTgsNTYgQEAgc3RhdGljIHZvaWQgcHJpbnRfUFBDKHVuc2lnbmVkIGludCBwbGF0Zm9ybV9s
aW1pdCkNCj4gPiAgICAgIHByaW50aygiXHRfUFBDOiAlZFxuIiwgcGxhdGZvcm1fbGltaXQpOyAg
fQ0KPiA+DQo+ID4gK3N0YXRpYyB2b2lkIHByaW50X0NQUEMoc3RydWN0IHhlbl9wcm9jZXNzb3Jf
Y3BwYyAqY3BwY19kYXRhKQ0KPg0KPiBQb2ludGVyLXRvLWNvbnN0Pw0KPg0KDQpTdXJlLg0KDQo+
ID4gK3sNCj4gPiArICAgIHByaW50aygiXHRfQ1BDOiBoaWdoZXN0X3BlcmY9JXUsIGxvd2VzdF9w
ZXJmPSV1LCAiDQo+ID4gKyAgICAgICAgICAgIm5vbWluYWxfcGVyZj0ldSwgbG93ZXN0X25vbmxp
bmVhcl9wZXJmPSV1LCAiDQo+ID4gKyAgICAgICAgICAgIm5vbWluYWxfZnJlcT0ldU1oeiwgbG93
ZXN0X2ZyZXE9JXVNaHpcbiIsDQo+ID4gKyAgICAgICAgICAgY3BwY19kYXRhLT5oaWdoZXN0X3Bl
cmYsIGNwcGNfZGF0YS0+bG93ZXN0X3BlcmYsDQo+ID4gKyAgICAgICAgICAgY3BwY19kYXRhLT5u
b21pbmFsX3BlcmYsIGNwcGNfZGF0YS0+bG93ZXN0X25vbmxpbmVhcl9wZXJmLA0KPiA+ICsgICAg
ICAgICAgIGNwcGNfZGF0YS0+bm9taW5hbF9mcmVxLCBjcHBjX2RhdGEtPmxvd2VzdF9mcmVxKTsg
fQ0KPiA+ICsNCj4gPiAraW50IHNldF9jcHBjX3BtaW5mbyh1aW50MzJfdCBhY3BpX2lkLCBzdHJ1
Y3QgeGVuX3Byb2Nlc3Nvcl9jcHBjDQo+ID4gKypjcHBjX2RhdGEpDQo+DQo+IFBvaW50ZXItdG8t
Y29uc3Q/DQo+DQoNClN1cmUuDQoNCj4gPiArew0KPiA+ICsgICAgaW50IHJldCA9IDAsIGNwdWlk
Ow0KPiA+ICsgICAgc3RydWN0IHByb2Nlc3Nvcl9wbWluZm8gKnBtX2luZm87DQo+ID4gKw0KPiA+
ICsgICAgY3B1aWQgPSBnZXRfY3B1X2lkKGFjcGlfaWQpOw0KPiA+ICsgICAgaWYgKCBjcHVpZCA8
IDAgfHwgIWNwcGNfZGF0YSApDQo+ID4gKyAgICB7DQo+ID4gKyAgICAgICAgcmV0ID0gLUVJTlZB
TDsNCj4gPiArICAgICAgICBnb3RvIG91dDsNCj4gPiArICAgIH0NCj4gPiArICAgIGlmICggY3B1
ZnJlcV92ZXJib3NlICkNCj4gPiArICAgICAgICBwcmludGsoIlNldCBDUFUgYWNwaV9pZCglZCkg
Y3B1aWQoJWQpIENQUEMgU3RhdGUgaW5mbzpcbiIsDQo+ID4gKyAgICAgICAgICAgICAgIGFjcGlf
aWQsIGNwdWlkKTsNCj4gPiArDQo+ID4gKyAgICBwbV9pbmZvID0gcHJvY2Vzc29yX3BtaW5mb1tj
cHVpZF07DQo+ID4gKyAgICBpZiAoICFwbV9pbmZvICkNCj4gPiArICAgIHsNCj4gPiArICAgICAg
ICBwbV9pbmZvID0geHphbGxvYyhzdHJ1Y3QgcHJvY2Vzc29yX3BtaW5mbyk7DQo+DQo+IFBsZWFz
ZSBiZSBhd2FyZSB0aGF0IG5ldyBjb2RlIGlzIHN1cHBvc2VkIHRvIGJlIHVzaW5nIHh2bWFsbG9j
KCkuDQoNClRoYW5rcyBmb3IgdGhlIHVwZGF0ZS4NCg0KPg0KPiA+ICsgICAgICAgIGlmICggIXBt
X2luZm8gKQ0KPiA+ICsgICAgICAgIHsNCj4gPiArICAgICAgICAgICAgcmV0ID0gLUVOT01FTTsN
Cj4gPiArICAgICAgICAgICAgZ290byBvdXQ7DQo+ID4gKyAgICAgICAgfQ0KPiA+ICsgICAgICAg
IHByb2Nlc3Nvcl9wbWluZm9bY3B1aWRdID0gcG1faW5mbzsNCj4gPiArICAgIH0NCj4gPiArICAg
IHBtX2luZm8tPmFjcGlfaWQgPSBhY3BpX2lkOw0KPiA+ICsgICAgcG1faW5mby0+aWQgPSBjcHVp
ZDsNCj4gPiArDQo+ID4gKyAgICBtZW1jcHkgKCh2b2lkICopJnBtX2luZm8tPmNwcGNfZGF0YSwN
Cj4gPiArICAgICAgICAgICAgKHZvaWQgKiljcHBjX2RhdGEsDQo+ID4gKyAgICAgICAgICAgIHNp
emVvZihzdHJ1Y3QgeGVuX3Byb2Nlc3Nvcl9jcHBjKSk7DQo+DQo+IFdoYXQgdXNlIGFyZSB0aGVz
ZSBjYXN0cz8gQWxzbyBwbGVhc2Ugbm8gYmxhbmsgYmVmb3JlIHRoZSBvcGVuaW5nIHBhcmVudGhl
c2lzIG9mDQo+IGEgZnVuY3Rpb24gY2FsbCwgYW5kIHBsZWFzZSBzaXplb2YoKmNwcGNfZGF0YSku
IFlldCB0aGVuIC0gd2h5IG1lbWNweSgpIGluIHRoZSBmaXJzdA0KPiBwbGFjZT8gVGhpcyBjYW4g
YmUgYSAodHlwZSBzYWZlKSBzdHJ1Y3R1cmUgYXNzaWdubWVudCwgY2FuJ3QgaXQ/DQo+DQoNClll
cywgaXQgY2FuIGJlIGEgKHR5cGUgc2FmZSkgc3RydWN0dXJlIGFzc2lnbm1lbnQNCg0KPiA+IC0t
LSBhL3hlbi9pbmNsdWRlL3B1YmxpYy9wbGF0Zm9ybS5oDQo+ID4gKysrIGIveGVuL2luY2x1ZGUv
cHVibGljL3BsYXRmb3JtLmgNCj4gPiBAQCAtMzYzLDYgKzM2Myw3IEBAIERFRklORV9YRU5fR1VF
U1RfSEFORExFKHhlbnBmX2dldGlkbGV0aW1lX3QpOw0KPiA+ICAjZGVmaW5lIFhFTl9QTV9QWCAg
IDENCj4gPiAgI2RlZmluZSBYRU5fUE1fVFggICAyDQo+ID4gICNkZWZpbmUgWEVOX1BNX1BEQyAg
Mw0KPiA+ICsjZGVmaW5lIFhFTl9QTV9DUFBDIDQNCj4gPg0KPiA+ICAvKiBQeCBzdWIgaW5mbyB0
eXBlICovDQo+ID4gICNkZWZpbmUgWEVOX1BYX1BDVCAgIDENCj4gPiBAQCAtNDMyLDYgKzQzMywx
NSBAQCBzdHJ1Y3QgeGVuX3Byb2Nlc3Nvcl9weCB7ICB0eXBlZGVmIHN0cnVjdA0KPiA+IHhlbl9w
cm9jZXNzb3JfcHggeGVuX3Byb2Nlc3Nvcl9weF90Ow0KPiA+IERFRklORV9YRU5fR1VFU1RfSEFO
RExFKHhlbl9wcm9jZXNzb3JfcHhfdCk7DQo+ID4NCj4gPiArc3RydWN0IHhlbl9wcm9jZXNzb3Jf
Y3BwYyB7DQo+ID4gKyAgICB1aW50MzJfdCBoaWdoZXN0X3BlcmY7DQo+ID4gKyAgICB1aW50MzJf
dCBub21pbmFsX3BlcmY7DQo+ID4gKyAgICB1aW50MzJfdCBsb3dlc3RfcGVyZjsNCj4gPiArICAg
IHVpbnQzMl90IGxvd2VzdF9ub25saW5lYXJfcGVyZjsNCj4gPiArICAgIHVpbnQzMl90IGxvd2Vz
dF9mcmVxOw0KPiA+ICsgICAgdWludDMyX3Qgbm9taW5hbF9mcmVxOw0KPiA+ICt9Ow0KPg0KPiBf
Q1BDIGNvbnRhaW5zIGEgbG90IG1vcmUgZGF0YS4gUGxlYXNlIGNsYXJpZnkgb24gd2hhdCBiYXNp
cyB0aGlzIHN1YnNldCB3YXMNCj4gY2hvc2VuLiAoS2VlcGluZyB0aGUgY2hvc2VuIGZpZWxkcyBp
biB0aGUgb3JkZXIgX0NQQyBoYXMgdGhlbSBtaWdodCBhbHNvIGJlIGENCj4gZ29vZCBpZGVhLikN
Cj4NCg0KSSdsbCBjb21tZW50IHdpdGggIg0KLyogU3Vic2V0IGZpZWxkcyB1c2VmdWwgZm9yIENQ
UEMtY29tcGF0aWJsZSBjcHVmcmVxIGRyaXZlcidzIGluaXRpYWxpemF0aW9uICovDQoiDQpJJ2xs
IHN0YXkgdGhlIHNhbWUgb3JkZXIgd2l0aCB0aGUgX0NQQyBoYXMgdGhlbQ0KDQo+ID4gLS0tIGEv
eGVuL2luY2x1ZGUveGxhdC5sc3QNCj4gPiArKysgYi94ZW4vaW5jbHVkZS94bGF0LmxzdA0KPiA+
IEBAIC0xNjYsNiArMTY2LDcgQEANCj4gPiAgISAgcHJvY2Vzc29yX2N4ICAgICAgICAgICAgICAg
ICAgICBwbGF0Zm9ybS5oDQo+ID4gICEgIHByb2Nlc3Nvcl9mbGFncyAgICAgICAgICAgICAgICAg
cGxhdGZvcm0uaA0KPiA+ICAhICBwcm9jZXNzb3JfcGVyZm9ybWFuY2UgICAgICAgICAgIHBsYXRm
b3JtLmgNCj4gPiArISAgcHJvY2Vzc29yX2NwcGMgICAgICAgICAgICAgICAgICBwbGF0Zm9ybS5o
DQo+ID4gICEgIHByb2Nlc3Nvcl9wb3dlciAgICAgICAgICAgICAgICAgcGxhdGZvcm0uaA0KPiA+
ICA/ICBwcm9jZXNzb3JfcHggICAgICAgICAgICAgICAgICAgIHBsYXRmb3JtLmgNCj4gPiAgISAg
cHNkX3BhY2thZ2UgICAgICAgICAgICAgICAgICAgICBwbGF0Zm9ybS5oDQo+DQo+IFBsZWFzZSBv
YmV5IHRvIGFscGhhYmV0aWMgc29ydGluZy4gQXMgcGVyIGFuIGVhcmxpZXIgY29tbWVudCBJIGFs
c28gZXhwZWN0IHRoaXMNCj4gd2FudHMgdG8gYmUgdXNpbmcgJz8nIGluIHBsYWNlIG9mICchJy4N
Cj4NCg0KU3VyZS4NCg0KPiBKYW4NCg0KTWFueSB0aGFua3MNClBlbm55DQo=


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 06:57:26 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 06:57:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872158.1283119 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXxKx-0002U9-KE; Wed, 15 Jan 2025 06:57:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872158.1283119; Wed, 15 Jan 2025 06: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 <xen-devel-bounces@lists.xenproject.org>)
	id 1tXxKx-0002U2-HR; Wed, 15 Jan 2025 06:57:11 +0000
Received: by outflank-mailman (input) for mailman id 872158;
 Wed, 15 Jan 2025 03:50:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Fxu6=UH=linux.dev=sui.jingfeng@srs-se1.protection.inumbo.net>)
 id 1tXuQW-0006lr-IF
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 03:50:47 +0000
Received: from out-183.mta0.migadu.com (out-183.mta0.migadu.com
 [2001:41d0:1004:224b::b7])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e38b6f67-d2f3-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 04:50:41 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e38b6f67-d2f3-11ef-99a4-01e77a169b0f
Message-ID: <078ddd52-1d04-4aad-935a-67c12ebf569a@linux.dev>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1;
	t=1736913034;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=jVhN80lSe9/RJE7xTb/gBfGOBNDnLQWNn0HdoXTdJX4=;
	b=teidT1Fw63fY1UplJo7A5bi9iE7QpymiDozRtg4zga+cfodcNKCHBs5xeOi588P6Xgf2QP
	CYp1SqpJZNtGd/fHLlyHIgbHFs46Z3aoqpduhurkaP+sGXJgpt1fvAeSbcUUllSz8kx3vA
	np+KZYyxC2PBSgowDFD5qMH7M7wgWl8=
Date: Wed, 15 Jan 2025 11:50:20 +0800
MIME-Version: 1.0
Subject: Re: [PATCH v2 11/25] drm/loongson: Compute dumb-buffer sizes with
 drm_mode_size_dumb()
To: Thomas Zimmermann <tzimmermann@suse.de>,
 maarten.lankhorst@linux.intel.com, mripard@kernel.org, airlied@gmail.com,
 simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org, linux-mediatek@lists.infradead.org,
 freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
 imx@lists.linux.dev, linux-samsung-soc@vger.kernel.org,
 nouveau@lists.freedesktop.org, virtualization@lists.linux.dev,
 spice-devel@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org,
 linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org,
 intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org,
 Sui Jingfeng <suijingfeng@loongson.cn>
References: <20250109150310.219442-1-tzimmermann@suse.de>
 <20250109150310.219442-12-tzimmermann@suse.de>
Content-Language: en-US
X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers.
From: Sui Jingfeng <sui.jingfeng@linux.dev>
In-Reply-To: <20250109150310.219442-12-tzimmermann@suse.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Migadu-Flow: FLOW_OUT

Hi,

On 2025/1/9 22:57, Thomas Zimmermann wrote:
> Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
> buffer size. Align the pitch according to hardware requirements.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Sui Jingfeng <suijingfeng@loongson.cn>
> Cc: Sui Jingfeng <sui.jingfeng@linux.dev>


Reviewed-by: Sui Jingfeng <sui.jingfeng@linux.dev>


> ---
>   drivers/gpu/drm/loongson/lsdc_gem.c | 29 ++++++++---------------------
>   1 file changed, 8 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/loongson/lsdc_gem.c b/drivers/gpu/drm/loongson/lsdc_gem.c
> index a720d8f53209..9f982b85301f 100644
> --- a/drivers/gpu/drm/loongson/lsdc_gem.c
> +++ b/drivers/gpu/drm/loongson/lsdc_gem.c
> @@ -6,6 +6,7 @@
>   #include <linux/dma-buf.h>
>   
>   #include <drm/drm_debugfs.h>
> +#include <drm/drm_dumb_buffers.h>
>   #include <drm/drm_file.h>
>   #include <drm/drm_gem.h>
>   #include <drm/drm_prime.h>
> @@ -204,45 +205,31 @@ int lsdc_dumb_create(struct drm_file *file, struct drm_device *ddev,
>   	const struct lsdc_desc *descp = ldev->descp;
>   	u32 domain = LSDC_GEM_DOMAIN_VRAM;
>   	struct drm_gem_object *gobj;
> -	size_t size;
> -	u32 pitch;
> -	u32 handle;
>   	int ret;
>   
> -	if (!args->width || !args->height)
> -		return -EINVAL;
> -
> -	if (args->bpp != 32 && args->bpp != 16)
> -		return -EINVAL;
> -
> -	pitch = args->width * args->bpp / 8;
> -	pitch = ALIGN(pitch, descp->pitch_align);
> -	size = pitch * args->height;
> -	size = ALIGN(size, PAGE_SIZE);
> +	ret = drm_mode_size_dumb(ddev, args, descp->pitch_align, 0);
> +	if (ret)
> +		return ret;
>   
>   	/* Maximum single bo size allowed is the half vram size available */
> -	if (size > ldev->vram_size / 2) {
> -		drm_err(ddev, "Requesting(%zuMiB) failed\n", size >> 20);
> +	if (args->size > ldev->vram_size / 2) {
> +		drm_err(ddev, "Requesting(%zuMiB) failed\n", (size_t)(args->size >> PAGE_SHIFT));
>   		return -ENOMEM;
>   	}
>   
> -	gobj = lsdc_gem_object_create(ddev, domain, size, false, NULL, NULL);
> +	gobj = lsdc_gem_object_create(ddev, domain, args->size, false, NULL, NULL);
>   	if (IS_ERR(gobj)) {
>   		drm_err(ddev, "Failed to create gem object\n");
>   		return PTR_ERR(gobj);
>   	}
>   
> -	ret = drm_gem_handle_create(file, gobj, &handle);
> +	ret = drm_gem_handle_create(file, gobj, &args->handle);
>   
>   	/* drop reference from allocate, handle holds it now */
>   	drm_gem_object_put(gobj);
>   	if (ret)
>   		return ret;
>   
> -	args->pitch = pitch;
> -	args->size = size;
> -	args->handle = handle;
> -
>   	return 0;
>   }
>   

-- 
Best regards,
Sui



From xen-devel-bounces@lists.xenproject.org Wed Jan 15 07:08:57 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 07:08:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872178.1283129 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXxWG-0004Qi-KW; Wed, 15 Jan 2025 07:08:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872178.1283129; Wed, 15 Jan 2025 07:08:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXxWG-0004Qb-HB; Wed, 15 Jan 2025 07:08:52 +0000
Received: by outflank-mailman (input) for mailman id 872178;
 Wed, 15 Jan 2025 07:08: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 <SRS0=dCnP=UH=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tXxWF-0004QS-1N
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 07:08:51 +0000
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com
 [2a00:1450:4864:20::32d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 91d8ad6c-d30f-11ef-a0e1-8be0dac302b0;
 Wed, 15 Jan 2025 08:08:49 +0100 (CET)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-4361c705434so44979095e9.3
 for <xen-devel@lists.xenproject.org>; Tue, 14 Jan 2025 23:08:49 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-437c74d8e06sm12673145e9.31.2025.01.14.23.08.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 14 Jan 2025 23:08:48 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 91d8ad6c-d30f-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736924929; x=1737529729; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=2Tjzwy0ANnVvnzMWfqKM9EbGCl+dzTJ3aQNsD/tdEVc=;
        b=BoQgh+gKh1jXWnP8jCxqNKUwAEmmvc4QW0gtfMj9RIJqpQdT4aL3JI8Za/ZzqIyUqx
         Dwcq7+26cFJ4yLSu7l+UgjHNctNPExpOlJsDYuXK+q9v4IP7Zfx1KRzhLlsUAYwimxHO
         gl8bywHxmi60sHeLrwajmERLVllOPhnVcAXlJ+mbxQYIW4TFjcblX5NUnL7e2tzfaUH/
         aaS+TmPaS6cjReNnGPYA8uDEjFRIL5ZbPThJ/aBUg0GxPmmmzA+60yiLw1rdcIY0n2N+
         +vXcgbH75raciRn+Ydjz5yAdaT1QPPkHzaF3aEVzwcW7e4iAzK+OlL/CwfzjONb4MS6U
         Sc0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736924929; x=1737529729;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=2Tjzwy0ANnVvnzMWfqKM9EbGCl+dzTJ3aQNsD/tdEVc=;
        b=uMzdcM9DfJy1iDSWKba1RCCMP4XF/tGJbs4vrJGJm9UATtfdZ1Sc7WUK4pGeklbbLb
         Lrvk6mruUExdUhgUHwVDCXDPd2zus2zfnkk/ZokzJLdgtE5TLsJJtJoP2Vtg6s1iLaEh
         gZ7Prl/tE0Ldf8nDJ3IJV6V+9aduHuTL+zP5BITEfQXShJecnYdJhVSM/eRnozHXEdnD
         Sonmrbcibo/koFVWQm/qWxVDb6ZWPTJ5PY1/fHChPu+QTVHx13p35G2DovRicUbk+Y41
         fbn+rAGOxSz4M7FcGqCdbDkZ48DcEOMnTUY1fzO8WP4jvyDPbaWYkzYaJSw2H6WV610B
         ABVQ==
X-Forwarded-Encrypted: i=1; AJvYcCXzflVXeuSH87VcMZieAv+LE1zfIV65JR5uQ5wFOu6BrVx/HvVT25Y1Ln53kNGnxC9pzLCeZrRUpfA=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyd48qGCa8wIytPNUeugmi/Rg/VbqPcWR7LvydaWf3cutMzvuSC
	LtH51TS0b15K+S+12oX9KN4/JZi/fiTO3yTvzQkWchN60bP/3VKEG1C+vm8xZg==
X-Gm-Gg: ASbGnctpk+jSKSjFsHq9GxI7+Re/FoQ2oVnfXzAMh+qZJK011EGpt6GBp+B7SdcPsHv
	ZjYoopNYyckQQIw646S/xI3KIxoJu8QUVtmV1giOaj86RjxfLTFnntJIflB9+Wb36alGpWCZ4DW
	9Ld65XvPcKPeYSFTPGjuwl+M4y50wCov6IiU1DhNiuMW35qB2jCHs+E3f4Rh4lSpnvHVCY2GoQ2
	Wo3Hrf644umRr3LpJ2+BIcvHl9uDmW94mbrpHVdKnpUvzZRLKTyTGZlE6GIO86bmsCWn0pmWzup
	9LD4S9Rp/KWkZqDbOvx99hrXBQWTsplekdSYjcIoOg==
X-Google-Smtp-Source: AGHT+IE9qgl3Nva7YXiZkdebfXUXVUgZn8LDkXRWosJClnf+ToYOM6H+2yoxWWhK5MNKuza5lw7/Hg==
X-Received: by 2002:a05:600c:4684:b0:434:f917:2b11 with SMTP id 5b1f17b1804b1-436e26e50c9mr213670185e9.21.1736924928794;
        Tue, 14 Jan 2025 23:08:48 -0800 (PST)
Message-ID: <94a5ec6a-c216-4aaa-9870-317132b7fb93@suse.com>
Date: Wed, 15 Jan 2025 08:08:46 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 02/11] xen/x86: introduce new sub-hypercall to get CPPC
 data
To: "Penny, Zheng" <penny.zheng@amd.com>
Cc: "Stabellini, Stefano" <stefano.stabellini@amd.com>,
 "Huang, Ray" <Ray.Huang@amd.com>,
 "Ragiadakou, Xenia" <Xenia.Ragiadakou@amd.com>,
 "Andryuk, Jason" <Jason.Andryuk@amd.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <20241203081111.463400-1-Penny.Zheng@amd.com>
 <20241203081111.463400-3-Penny.Zheng@amd.com>
 <95183589-1a83-4c99-ade4-d37873b85e0a@suse.com>
 <IA1PR12MB84679A0D60CD4219E9C1A01FE1192@IA1PR12MB8467.namprd12.prod.outlook.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <IA1PR12MB84679A0D60CD4219E9C1A01FE1192@IA1PR12MB8467.namprd12.prod.outlook.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15.01.2025 06:33, Penny, Zheng wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Thursday, January 9, 2025 5:46 PM
>>
>> On 03.12.2024 09:11, Penny Zheng wrote:
>>> In order to provide backward compatibility with existing governors
>>> that represent performance as frequencies, like ondemand, the _CPC
>>> table can optionally provide processor frequency range values, Lowest
>>> frequency and Norminal frequency, to let OS use Lowest Frequency/
>>> Performance and Nominal Frequency/Performance as anchor points to
>>> create linear mapping of CPPC abstract performance to CPU frequency.
>>>
>>> As Xen is uncapable of parsing the ACPI dynamic table, this commit
>>> introduces a new sub-hypercall to get required CPPC data from
>>> dom0 kernel.
>>
>> "get" as used both here and in the title is, to me, something an entity does actively.
>> Xen is entirely passive here, though. (Reading the title I was first assuming this is
>> about a sub-op to get certain data out of
>> Xen.)
> 
> How about "a new sub-hypercall to pass/deliver CPPC to Xen"? or any better suggestions?

That or "propagate" or "report" (and perhaps there are yet more alternatives).

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 08:17:37 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 08:17:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872191.1283139 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXyaT-0006Sb-Lu; Wed, 15 Jan 2025 08:17:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872191.1283139; Wed, 15 Jan 2025 08:17:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXyaT-0006SU-I6; Wed, 15 Jan 2025 08:17:17 +0000
Received: by outflank-mailman (input) for mailman id 872191;
 Wed, 15 Jan 2025 08:17: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
 <SRS0=KZm5=UH=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tXyaR-0006SO-Hp
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 08:17:15 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1fffa9d3-d319-11ef-a0e1-8be0dac302b0;
 Wed, 15 Jan 2025 09:17:14 +0100 (CET)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-aa6c0dbce1fso925418766b.2
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 00:17:13 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c9563b06sm732264866b.100.2025.01.15.00.17.12
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 15 Jan 2025 00:17:12 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1fffa9d3-d319-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736929033; x=1737533833; 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=wxDylGD/rECUaKXH5DNosILSAYVcMAnuYQqFeSShHhs=;
        b=MqPceTk3pnTSy3Cy5KOvf6uDqYCXQ2WGjrkqGRz6IiVRkZGgtR1CKonvwXWIc4A1nq
         xg7Y6VF26EQvfGu9UU8J39HYqAwwCg8ze5mYAlcrBCrC8Xb8jdU/igcIWyMzzzc6GDEb
         p9qGG9UYy9E59MiGiMGkFDlg6YbdGw5cvo7x0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736929033; x=1737533833;
        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=wxDylGD/rECUaKXH5DNosILSAYVcMAnuYQqFeSShHhs=;
        b=IHtPx7xrcLSc5616W88RRC7Ps2msgAdyxSsT19DxBtLKMmK9hjrAv4WxEqAp/VZ134
         b8gd+g9ahvAGIMjLM2wBlP6E4Hk8nhb2xu7Uo+KCaP11FVVYDmqHQuFT5RbNuP6FeBtu
         s++GEB6nozibklOYROBVlchOEH9QYU0eoxx7eBnrXizr09TDtoWsi+y3c4NE+NBP6Z9x
         Ivgq8nFh3OkcKZw2rYNxw0X9C7tTFKnUnjA8QLHTWTW9K/hdyCfUM4dHCxMZtkPcclHk
         cAzNuELPbeg/CwAToL6qRI1PgTQY/IwhrI3T798688E1sA9SpY8skZOmvB4neeK0NLEt
         TB5A==
X-Gm-Message-State: AOJu0YwRLW0GQ7z/UY4s0caGLiHhY66DrV+gBPfm9T1w4VJwv5rdZSMp
	MbygEhZnUpAyXlmuYVsYcvv6/MKfYsyvVDLig4nClBHg1hEcqpJLj1qd2NBiz7E=
X-Gm-Gg: ASbGncvFzNYl5yZsa88OCXC+jXx7vrhslnph56kub5vtDBcuFaiawo+LyAN8Hb4K/lN
	svaY69HxWdFwMdkfxCP8yVpTZMl7CncY1K8/+zQuU+9mPPoDt+aH8mti/68aC6KzmCFM/VdhgzP
	pwZabCIShKrC9G+ozpV9qGdgeo2T+wzNGfM5TZdUFw4huYUHOASOIu3o0Rgp6scWucX1N0sZPit
	G4vYjnRF8y5EZY9K2a6wzry03IH+hH9NZruS4GaM6dZgrcdJ6q/CRu/E5WBFoPp8+E=
X-Google-Smtp-Source: AGHT+IF2xXggUp2JiT/pL1wOOaIc21O4ZetVBDo4hyq6ucbyLmpWBql2I6pjC1JF/I3H+bvtc+KLRQ==
X-Received: by 2002:a50:858c:0:b0:5d9:857e:b259 with SMTP id 4fb4d7f45d1cf-5d9857eb31cmr44638768a12.31.1736929033065;
        Wed, 15 Jan 2025 00:17:13 -0800 (PST)
Date: Wed, 15 Jan 2025 09:17:11 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: xen-devel@lists.xenproject.org, Doug Goldstein <cardoe@cardoe.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>
Subject: Re: [PATCH for-4.20] automation/gitlab: disable coverage from clang
 randconfig
Message-ID: <Z4dvBxuB9gl-Y_yL@macbook.local>
References: <20250114174345.60887-1-roger.pau@citrix.com>
 <c715348e-0f40-4ac4-b38e-1aead29cde52@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <c715348e-0f40-4ac4-b38e-1aead29cde52@citrix.com>

On Tue, Jan 14, 2025 at 05:48:20PM +0000, Andrew Cooper wrote:
> On 14/01/2025 5:43 pm, Roger Pau Monne wrote:
> > If randconfig enables coverage support the build times out due to GNU LD
> > taking too long.  For the time being prevent coverage from being enabled in
> > clang randconfig job.
> >
> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> 
> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

Thanks.

> > ---
> > Cc: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> > ---
> > I will fix the orphaned section stuff separately, as I'm considering just
> > removing LLVM coverage support because the llvm coverage format is not
> > stable, and the code to dump it has already become stale.  However I need
> > to think about it, and in the short term disabling coverage support from
> > randconfig is more straightforward.
> 
> Oh, so it's broken too?  Unless the fix is trivial, we should have a
> Kconfig level disable on it.  No point letting people turn on something
> that's broken.

It's not build time broken, but the format of the buffer that we
return in llvm.c dump() function has gotten out of sync with the
native format in modern clang versions, and hence coverage tools will
refuse to parse it.

I think newer versions of llvm/clang have now included an internal
function to dump the buffer, so that we no longer have to attempt to
generate it from Xen, I need to see whether that works.  Otherwise the
only remaining option is to convert the llvm data into gcov format
(which is stable), IIRC this is what Linux did.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 08:18:33 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 08:18:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872199.1283150 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXybg-0006yL-To; Wed, 15 Jan 2025 08:18:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872199.1283150; Wed, 15 Jan 2025 08:18:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXybg-0006yE-RF; Wed, 15 Jan 2025 08:18:32 +0000
Received: by outflank-mailman (input) for mailman id 872199;
 Wed, 15 Jan 2025 08:18:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=9Lts=UH=amd.com=penny.zheng@srs-se1.protection.inumbo.net>)
 id 1tXybf-0006vG-6S
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 08:18:31 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on2062f.outbound.protection.outlook.com
 [2a01:111:f403:2418::62f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4c82eb77-d319-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 09:18:29 +0100 (CET)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 DM6PR12MB4371.namprd12.prod.outlook.com (2603:10b6:5:2a3::23) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8356.13; Wed, 15 Jan 2025 08:18:25 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%4]) with mapi id 15.20.8356.010; Wed, 15 Jan 2025
 08:18:25 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 4c82eb77-d319-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ynto8wkk5LP+uh8S0IKiETHxxYxLGAhrKIF3y55SF9hxDtsdrbADwJwUqZf+fEcwIGB1y8YLSWjvGtjEfxB7DFISeuRgnwhdfLb6n9IVnuOwhWkN50A/TzsSTXP3/YByj1H85QHPLz5tf4kdXIrJZWusj6tie9N7QER5w62voaLoYkVl+yQ38FexfKr6oaG2hv1r2V5Z/YVwBxCG+uqhDkbO9ry5DDjiEXLgOmiVM86Sx6zeqj8P6dOqbQf0+NsWrQo0dgX1LIPuD4i7seSKtNrblvG6PAeaM2lHg2bCl3SxHM1y3NMKjziMZEfsI3wy4AmGl6kQTAqJNe0jaGJJhg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=un9NIh0Ntbgut6g7kr8wapghiWutZgAzAANKgdnw29s=;
 b=bxvmYQocORRH5ga/wCKei53WIFXHR9Osj8Z/nYR/CC0nA6KQtE4EAVkk2oG32kyVucKCohOq9rGDO7RYlTCywRwLzyfFOf0I/0wWi6+0cpDIHMI1HBLnY01YDtzaGk27JHH999RKLJ0QS7P5nFxzgIL5hBp81pvdy13b9XkHL+/Jpc6bvf4g8gRKHdZIs2uHrHQR95qEtiQq1opLkxhck5/YIfKh2P0SSgNMSXaezBU4fkIcYRrj334tSbDJWnpD1HZgqwwGcQbOZVQoadHPDzzxvcl36JXApLzrRlYWamWDSzLqL09rDHLmLVmuuyN4IJwinUtCUVZ/pO0EETdodg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=un9NIh0Ntbgut6g7kr8wapghiWutZgAzAANKgdnw29s=;
 b=IKr4xNYyHpEJicGCbInj1MlgnNxAgoObedsmTV7BnkyJwwM4jLqTLUCJPciAdtwwXyFGuMIgWqm0f2ROGpF0RLK/9sutzjjOMg1NB1E8ilLa7I+B/sJr2jGYARzF4SdcBAL+5hVFP7kOexDfpbvmyGTyJNkUZG0v+IxC3JVYyho=
From: "Penny, Zheng" <penny.zheng@amd.com>
To: Jan Beulich <jbeulich@suse.com>
CC: "Stabellini, Stefano" <stefano.stabellini@amd.com>, "Huang, Ray"
	<Ray.Huang@amd.com>, "Ragiadakou, Xenia" <Xenia.Ragiadakou@amd.com>,
	"Andryuk, Jason" <Jason.Andryuk@amd.com>, Andrew Cooper
	<andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, Stefano
 Stabellini <sstabellini@kernel.org>, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	<roger.pau@citrix.com>, "xen-devel@lists.xenproject.org"
	<xen-devel@lists.xenproject.org>
Subject: RE: [PATCH v1 03/11] xen/x86: introduce "cpufreq=amd-pstate" xen
 cmdline
Thread-Topic: [PATCH v1 03/11] xen/x86: introduce "cpufreq=amd-pstate" xen
 cmdline
Thread-Index: AQHbRVx5dnEd/G58t0eEMeNox50YY7MOb2uAgAksanA=
Date: Wed, 15 Jan 2025 08:18:25 +0000
Message-ID:
 <DM4PR12MB8451AF14F5B8609E54312F8DE1192@DM4PR12MB8451.namprd12.prod.outlook.com>
References: <20241203081111.463400-1-Penny.Zheng@amd.com>
 <20241203081111.463400-4-Penny.Zheng@amd.com>
 <e7f1b3c3-dce4-4a0e-b1cf-c6ba8af95290@suse.com>
In-Reply-To: <e7f1b3c3-dce4-4a0e-b1cf-c6ba8af95290@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_ActionId=05087760-f5be-4c84-b0b8-e9e4fb3eee1a;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_ContentBits=0;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_Enabled=true;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_Method=Standard;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_Name=AMD
 Internal Distribution
 Only;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_SetDate=2025-01-15T06:04:03Z;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DM4PR12MB8451:EE_|DM6PR12MB4371:EE_
x-ms-office365-filtering-correlation-id: 9691198e-62cc-4ed3-37e5-08dd353d2edf
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?eU4ralU2U2lad2pnNUZxMzkvOEovYjRXZ0VpTmhlaGc1dTMrWFJqRlpKblFa?=
 =?utf-8?B?RWRqMFFrZkhzaVk3aFhuMHljNmV3TXJDU3FZU2dERWtTc05MbE5kUzJxeWhj?=
 =?utf-8?B?UzE4SSsyWWpRTXhTeFFNZnUrdVp4QThmMUUzMGk4V3JjNnhxdDRnbEFUOEhr?=
 =?utf-8?B?bmVzK2NIeXl6UmJFV1VnWXJUMk4xLzlMRjhNczJ2WDVYbnEwTjl1S1B3TWh0?=
 =?utf-8?B?cEVYYm0vblNjRjJJcmV3RDVMeHVBNUt4TkJvODdLRDgxZS84QlpOVTVDZjhX?=
 =?utf-8?B?SkFTUG5HUEVSRFZpN3doWHZ3QkhRNVRlOTQwUEQ4aEVLQ3phRTFsV3hmTURa?=
 =?utf-8?B?Q3RCZjAvSkpwSVRPbmMyRnBGekNqQTRuR0JoS0xwbVRMY01ZZHgzRVNobisx?=
 =?utf-8?B?VTNRSDZzOFA3cllsMEFQOXl4cThBYjlnZVpvVGxyb0xIeWNFZEQ2ek5JNlFL?=
 =?utf-8?B?UEc2N2gyeXFoUDBOaWorNlA0NDgvSFlyZ2ZVbFNlSFhjTEU5anQ5NXRZN3pM?=
 =?utf-8?B?VW9jOC9GZ0U1RitwYlIraUxsSVZleDE2dktocXRXb3B6dmFwQURqYnRDZ3RM?=
 =?utf-8?B?d3BJcWFvT0M5U2I2ak1uWWZadFFSZitidFBkNXpTRE9ES0o0bHFqOHJqQ0Vi?=
 =?utf-8?B?VFNLV2tNZG9qYjczMHh1dUQvSiszcEtQRUt3eG44TnlQTGt2QldaMVdpcmhG?=
 =?utf-8?B?QWlxMXdEUHp6TkRSY0FjNzRyWVZOMHludjkwWEc0MWh2R2hqb3BWZDV3VGZl?=
 =?utf-8?B?cjloNDhGUVJzeHhjNVM5TXUrQkVtRzBRTjQySkVka3hPMU02WVQ2TkovZ1BH?=
 =?utf-8?B?NlJLd2hPaHJhUVA1YzhReWk3dnV6Q0wxQmxySzAxeXMzYXdQK0lCbnh1cHV5?=
 =?utf-8?B?NXdCL1F3UGwyamI3RGd0VTdMVXd5RWNXTkJ0YmJuZmx3STNGUTJHK0JjREp1?=
 =?utf-8?B?ZFUyYURiQzFVSEhxMXdWRG1YMGdTRkZyYkhUVFBOcEhpWU5XR2pxLzRuanBS?=
 =?utf-8?B?SUVrZUl4WWtmL20wYnpxVmJrZk1kTlgxRDN1bDREcXU1TktkOC8wZFJUWkQz?=
 =?utf-8?B?WnVJOG5rVVpOd0FWbGR1ckpHbStBYjVSYmMxVS9LV0JORXN3YldyNGlTVjMy?=
 =?utf-8?B?Yi9BRTYxb3dOaURKN3JpUlVhL2h6SkprWnc1NEk3cDM4ZE85ZWlrN3ptV2dr?=
 =?utf-8?B?L0pzMW1MVU1lVkxpVUtEdU1ZeExzU24zK25PcysxczhGVFh0cDNiZ2YvOUZ3?=
 =?utf-8?B?czZ1VUNQSlVsSjQrNnc1dTkxZWRJRWFQa3M1T0h4YlhUOUpxdnF6cHF6L2wx?=
 =?utf-8?B?R1pLblNCNEplVGZON2FFY0liekpzRjBFSGdSUlY2VXk4UnAxbFJ0NGFvNjBM?=
 =?utf-8?B?QVA0SlQzS1RDazc4eEtGa1BleHQ4bzZsL01BMEhZQStQM0JkZHBHSUVoSzVB?=
 =?utf-8?B?WHhSYWVvSzBnQ2taK2x2cTQ1TFM0THEyKzNJM2JyZEZQZlR0T3R0dS9qQ2hS?=
 =?utf-8?B?V29oZU1zUXk0Q0lJYjZMSTQ3dXRKUXFmVkwxTjJJcDV6K1pvbzY2dzBUTm9C?=
 =?utf-8?B?cmFoTzlpcDFBYkhWM21ZWEtmQlhpelE4YzJDdjIrTnhrL3lTWFhwbVh6NGE2?=
 =?utf-8?B?Y1RNSXNOc1JjVVBoYlppbE9CYVliWnVFcmp6ampJMHBRNjZUR2ZKTEQvMSty?=
 =?utf-8?B?VWFIL3NrK3VUSjNIUURGTEJOb1dmZWxta2gzSEtaUVZobUk5WTJZUjdRMHpY?=
 =?utf-8?B?WUhHTi9LTDB5WDFxOFJkcG81azFrL3ROOTFBdXQ2WGh4N1hRa0kzbCtTdlFI?=
 =?utf-8?B?S1pqSUNkQmRRMnpsYjhBSVZzQzVaa3lCTUYySVk0UG5yL21jMm8yem91NmZz?=
 =?utf-8?B?SCs4WElLUFYyVUNuNFZFSU9hdThZV3JCZzd4N3orNkxhMHVCeUNZQWQvU05w?=
 =?utf-8?Q?kfYsr8JInv0KnZznc9dzBySWGHwQPZVQ?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB8451.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?L1A2QXVtSEJ6bXhCMThjeUcvYkZ2aG1DMUxwUjFTdlc1aFVhOHdvSzhzamM1?=
 =?utf-8?B?ckpFSGdaczJIa1JUNDBBc2MyQ2duemZKQVlVWVcvbjJUNUk3Ykd4UFBIVXAv?=
 =?utf-8?B?L3kvd0JSS01jRTFRVEZYSHVFeWZueUFCQzBGWWVmWitPdFAweGhTUm5ZZVhw?=
 =?utf-8?B?RmU4UUZJb0Z2N1NmZVBSeVh3bkl6Ukx6M1A4a0sxNUtaaGJObGxwNWhUMUlR?=
 =?utf-8?B?amVXSElPMVRvM0FOci9aakFOVndJejc3NU1Rc0JoYWprSTIwSTZSajhlZVp1?=
 =?utf-8?B?cnBLQWJPUDM3SXZ6Z3NvSWI3cENzMXVpRWU4OU1PemtsZDZKRjF5ZFIzNHpO?=
 =?utf-8?B?R0d4YXgvRURxdGtYcW5kWlFxUVExbXZYMHBWSEdUUGlheUNqMVYra29PVzFo?=
 =?utf-8?B?Nm1haXgyUGFaK24ySFlsdm1ZaEZyZUt4LzYzWUwvZjQ0UzB5dHV2and2aGhO?=
 =?utf-8?B?WDgza0ZFdm1iMFhoYml5Sjg4WnFzQjliRGRPaXBjczQvMHIxYnMvcHpFeHFU?=
 =?utf-8?B?SURiR2VYZUdpbGVJZkdzV2ErWFRqenVET09qcHZMQm1qYStidlJIMUdSc21T?=
 =?utf-8?B?SysrdnNGT3pleDVHZC9kS0dmVjZWSS9NQzFycnpCRHFlRUNVYmY5OEVLQWZw?=
 =?utf-8?B?YnliRStCSVRqaWtTK08xR0xiK3Btejg3dW41WlNsdW1hWnBNYWNGUEZxdGFP?=
 =?utf-8?B?RFRjTXhJbmltdlJOMWRFNG04cDRqcGowTjkxNjZqWnlObTJvM0x5VU5GcGVC?=
 =?utf-8?B?cUFscURMMWRuQkh4YTBpRGc5Q3JzRWplbGpsNllEcmhWSytOcGlhN2s5ci8z?=
 =?utf-8?B?cVVja003VGF0dTJPWUo1N2JoSVRlRmFoQVlpSjUyN0E3aWxFWHA3YWsyZm9n?=
 =?utf-8?B?VVNuY3BEblpxWTQraWdJUVZFL1JVNy9lUlkvWkFrd3N4b1kwVjhRM3JWcFA2?=
 =?utf-8?B?cjBQRlhpSTBxeEwvWTdYb2E4VE9hRi9jaWhsc00yN1JvVERmcjlEY1lXSHVV?=
 =?utf-8?B?UWRBak9OT3VWOU1UVU9NVmcyU2V3bVRrVTZQMjdWekVUVmh0bVhxZ0lKWVVN?=
 =?utf-8?B?L2ZoUXA3c2FzcW9vd0t5WGRabGIyb2owOG1MWEdyc0w1cSt6ZnZyUW51b2Vp?=
 =?utf-8?B?MHFFL1dsaEc1K1ZEV1hhTDNpMERaVHl6aC9xNWpxN1dtbnVKVnZOQ2ltZ2Fn?=
 =?utf-8?B?UEd0SzA1SE1uN1RNT1cvME5PeEhMOW9scWdBdUc4RWRROG4zR0YyanFhdGN5?=
 =?utf-8?B?aUI2N3NId3V1YlhtVy9XU0RMSTJObm5PeThGblFmQjVkQmJSeTR0dkpZb052?=
 =?utf-8?B?c2wxT05OanU0SSsrbmFSdm9KVlZkckhGZnNxSzJtVWhDYTZiWE5RUDgySFQ4?=
 =?utf-8?B?djRmK0hTcFA3WWpHelZFdW5mTkkycGFJeVdBZ0JrQVNFckRyb2tkRHdQK0NC?=
 =?utf-8?B?Z3pZeVE1UmRBVHJZc0hmaE9zRkU5VGkwVFNQN2MrVVJUTHlrcVh5cnI2T0RS?=
 =?utf-8?B?OVBYbWRJakRSQkdzUGxYVFlTSzAxek1VelRsSHpmeVN4RGU1MmFpaFJhbG41?=
 =?utf-8?B?QlY0b2p2TllEOGtBdlRxRGRiT0lIcWZOdWI0NTJHbW94L0tNVTZvUzlLTTdK?=
 =?utf-8?B?RFJKLzJ3ZlJIY1gySkFzY3FsNE5QamhPT1hTcnl2QjdYT2V1bWdpTXVKMlps?=
 =?utf-8?B?TURyRk9jcnB0K2kyMk9TL0grb2lVeGl3WmNJU1ZPYWZKVkVIZ0FleitBQm9O?=
 =?utf-8?B?c1JuM1d1bWV0SDV5ZUpkYjU1WlpjeTVwNHk4MWxmSEZ6c0FBMmFKcGYvVUNF?=
 =?utf-8?B?Qll5a211NktHTktQcXhkalJXQk1mYnVmQUd1MGJYVWQvSElqTjVzcEs1TkZw?=
 =?utf-8?B?MWhFb0V4N1FUZHNsU1RHd1FRWGF4YUFnSmJidXNLUkxXUUdXTzNEWlVoT2l2?=
 =?utf-8?B?TFI2NS9VKzF0cTlPQ0djWk5yNDJIRmZOQmtJWGY0RjdaK0ltU1A5QjhJQUJt?=
 =?utf-8?B?TUFNcW9rcjFhdDY4TXBObnNZYnVmTUJXMk1JYlBLUE56ZUJwNkZTYjdVWUtB?=
 =?utf-8?B?R0hSVi9YaXBkMzdOTGRFWnFhelF3UUZVdVlJamphNGFlb1UvbW8xMU1hd0hZ?=
 =?utf-8?Q?zw/g=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB8451.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9691198e-62cc-4ed3-37e5-08dd353d2edf
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2025 08:18:25.1921
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: TS1WnkxxIzXik4mknND6BfUZyi+mbPWAweo6h0P9rAqohje6kgnNwrZ0sIZBag59Y+SBzkNX5KFFC1awK8u2EQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4371

W0FNRCBPZmZpY2lhbCBVc2UgT25seSAtIEFNRCBJbnRlcm5hbCBEaXN0cmlidXRpb24gT25seV0N
Cg0KSGksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSmFuIEJldWxp
Y2ggPGpiZXVsaWNoQHN1c2UuY29tPg0KPiBTZW50OiBUaHVyc2RheSwgSmFudWFyeSA5LCAyMDI1
IDU6NTkgUE0NCj4gVG86IFBlbm55LCBaaGVuZyA8cGVubnkuemhlbmdAYW1kLmNvbT4NCj4gQ2M6
IFN0YWJlbGxpbmksIFN0ZWZhbm8gPHN0ZWZhbm8uc3RhYmVsbGluaUBhbWQuY29tPjsgSHVhbmcs
IFJheQ0KPiA8UmF5Lkh1YW5nQGFtZC5jb20+OyBSYWdpYWRha291LCBYZW5pYSA8WGVuaWEuUmFn
aWFkYWtvdUBhbWQuY29tPjsNCj4gQW5kcnl1aywgSmFzb24gPEphc29uLkFuZHJ5dWtAYW1kLmNv
bT47IEFuZHJldyBDb29wZXINCj4gPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+OyBKdWxpZW4g
R3JhbGwgPGp1bGllbkB4ZW4ub3JnPjsgU3RlZmFubyBTdGFiZWxsaW5pDQo+IDxzc3RhYmVsbGlu
aUBrZXJuZWwub3JnPjsgUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+OyB4
ZW4tDQo+IGRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0gg
djEgMDMvMTFdIHhlbi94ODY6IGludHJvZHVjZSAiY3B1ZnJlcT1hbWQtcHN0YXRlIiB4ZW4NCj4g
Y21kbGluZQ0KPg0KPiBPbiAwMy4xMi4yMDI0IDA5OjExLCBQZW5ueSBaaGVuZyB3cm90ZToNCj4g
PiAtLS0gYS94ZW4vYXJjaC94ODYvYWNwaS9jcHVmcmVxL01ha2VmaWxlDQo+ID4gKysrIGIveGVu
L2FyY2gveDg2L2FjcGkvY3B1ZnJlcS9NYWtlZmlsZQ0KPiA+IEBAIC0xLDQgKzEsNSBAQA0KPiA+
ICBvYmotJChDT05GSUdfSU5URUwpICs9IGFjcGkubw0KPiA+ICBvYmoteSArPSBjcHVmcmVxLm8N
Cj4gPiArb2JqLXkgKz0gYW1kLXBzdGF0ZS5vDQo+ID4gIG9iai0kKENPTkZJR19JTlRFTCkgKz0g
aHdwLm8NCj4gPiAgb2JqLSQoQ09ORklHX0FNRCkgKz0gcG93ZXJub3cubw0KPg0KPiBQbGVhc2Ug
b2JleSB0byBhbHBoYWJldGljIHNvcnRpbmcuDQoNClN1cmUsIGFuZCBJJ2xsIGFsc28gc3RyaWN0
IGl0IHdpdGggQ09ORklHX0FNRA0KDQo+DQo+ID4gLS0tIC9kZXYvbnVsbA0KPiA+ICsrKyBiL3hl
bi9hcmNoL3g4Ni9hY3BpL2NwdWZyZXEvYW1kLXBzdGF0ZS5jDQo+ID4gQEAgLTAsMCArMSw2NiBA
QA0KPiA+ICsvKiBTUERYLUxpY2Vuc2UtSWRlbnRpZmllcjogR1BMLTIuMC1vbmx5ICovDQo+ID4g
Ky8qDQo+ID4gKyAqIGFtZC1wc3RhdGUuYyAtIEFNRCBQcm9jZXNzb3IgUC1zdGF0ZSBGcmVxdWVu
Y3kgRHJpdmVyDQo+ID4gKyAqDQo+ID4gKyAqIENvcHlyaWdodCAoQykgMjAyNCBBZHZhbmNlZCBN
aWNybyBEZXZpY2VzLCBJbmMuIEFsbCBSaWdodHMgUmVzZXJ2ZWQuDQo+ID4gKyAqDQo+ID4gKyAq
IEF1dGhvcjogUGVubnkgWmhlbmcgPHBlbm55LnpoZW5nQGFtZC5jb20+DQo+ID4gKyAqDQo+ID4g
KyAqIEFNRCBQLVN0YXRlIGludHJvZHVjZXMgYSBuZXcgQ1BVIHBlcmZvcm1hbmNlIHNjYWxpbmcg
ZGVzaWduIGZvcg0KPiA+ICtBTUQNCj4gPiArICogcHJvY2Vzc29ycyB1c2luZyB0aGUgQUNQSSBD
b2xsYWJvcmF0aXZlIFBlcmZvcm1hbmNlIGFuZCBQb3dlcg0KPiA+ICtDb250cm9sIChDUFBDKQ0K
PiA+ICsgKiBmZWF0dXJlIHdoaWNoIHByb3ZpZGVzIGEgZmluZXIgZ3JhaW5lZCBmcmVxdWVuY3kg
Y29udHJvbCByYW5nZS4NCj4gPiArICoNCj4gPiArICovDQo+DQo+IE5pdDogVW5uZWNlc3Nhcnkg
ZW1wdHkgY29tbWVudCBsaW5lIGF0IHRoZSBlbmQuDQoNCkFjaw0KDQo+DQo+ID4gKyNpbmNsdWRl
IDx4ZW4vaW5pdC5oPg0KPiA+ICsjaW5jbHVkZSA8eGVuL3BhcmFtLmg+DQo+ID4gKyNpbmNsdWRl
IDxhY3BpL2NwdWZyZXEvY3B1ZnJlcS5oPg0KPiA+ICsNCj4gPiArdWludDE2X3QgX19yZWFkX21v
c3RseSBkbWlfbWF4X3NwZWVkX21oejsNCj4gPiArDQo+ID4gK3N0YXRpYyBib29sIF9faW5pdCBh
bWRfcHN0YXRlX2hhbmRsZV9vcHRpb24oY29uc3QgY2hhciAqcywgY29uc3QgY2hhcg0KPiA+ICsq
ZW5kKSB7DQo+ID4gKyAgICBpbnQgcmV0Ow0KPiA+ICsNCj4gPiArICAgIHJldCA9IHBhcnNlX2Jv
b2xlYW4oInZlcmJvc2UiLCBzLCBlbmQpOw0KPiA+ICsgICAgaWYgKCByZXQgPj0gMCApDQo+ID4g
KyAgICB7DQo+ID4gKyAgICAgICAgY3B1ZnJlcV92ZXJib3NlID0gcmV0Ow0KPiA+ICsgICAgICAg
IHJldHVybiB0cnVlOw0KPiA+ICsgICAgfQ0KPiA+ICsNCj4gPiArICAgIHJldHVybiBmYWxzZTsN
Cj4gPiArfQ0KPiA+ICsNCj4gPiAraW50IF9faW5pdCBhbWRfcHN0YXRlX2NtZGxpbmVfcGFyc2Uo
Y29uc3QgY2hhciAqcywgY29uc3QgY2hhciAqZSkgew0KPiA+ICsgICAgZG8NCj4gPiArICAgIHsN
Cj4gPiArICAgICAgICBjb25zdCBjaGFyICplbmQgPSBzdHJwYnJrKHMsICIsOyIpOw0KPiA+ICsN
Cj4gPiArICAgICAgICBpZiAoICFhbWRfcHN0YXRlX2hhbmRsZV9vcHRpb24ocywgZW5kKSApDQo+
ID4gKyAgICAgICAgew0KPiA+ICsgICAgICAgICAgICBwcmludGsoWEVOTE9HX1dBUk5JTkcgImNw
dWZyZXEvYW1kLXBzdGF0ZTogb3B0aW9uICclLipzJyBub3QNCj4gcmVjb2duaXplZFxuIiwNCj4g
PiArICAgICAgICAgICAgICAgICAgIChpbnQpKChlbmQgPzogZSkgLSBzKSwgcyk7DQo+ID4gKw0K
PiA+ICsgICAgICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4gPiArICAgICAgICB9DQo+ID4gKw0K
PiA+ICsgICAgICAgIHMgPSBlbmQgPyArK2VuZCA6IGVuZDsNCj4gPiArICAgIH0gd2hpbGUgKCBz
ICYmIHMgPCBlICk7DQo+ID4gKw0KPiA+ICsgICAgcmV0dXJuIDA7DQo+ID4gK30NCj4gPiArDQo+
ID4gK3N0YXRpYyBjb25zdCBzdHJ1Y3QgY3B1ZnJlcV9kcml2ZXIgX19pbml0Y29uc3RyZWwNCj4g
PiArYW1kX3BzdGF0ZV9jcHVmcmVxX2RyaXZlciA9DQo+DQo+IF9faW5pdGNvbnN0X2NmX2Nsb2Ji
ZXINCj4NCg0KQWNrDQoNCj4gPiAtLS0gYS94ZW4vYXJjaC94ODYvYWNwaS9jcHVmcmVxL2NwdWZy
ZXEuYw0KPiA+ICsrKyBiL3hlbi9hcmNoL3g4Ni9hY3BpL2NwdWZyZXEvY3B1ZnJlcS5jDQo+ID4g
QEAgLTE0OCw2ICsxNDgsOSBAQCBzdGF0aWMgaW50IF9faW5pdCBjZl9jaGVjayBjcHVmcmVxX2Ry
aXZlcl9pbml0KHZvaWQpDQo+ID4gICAgICAgICAgICAgICAgICBjYXNlIENQVUZSRVFfbm9uZToN
Cj4gPiAgICAgICAgICAgICAgICAgICAgICByZXQgPSAwOw0KPiA+ICAgICAgICAgICAgICAgICAg
ICAgIGJyZWFrOw0KPiA+ICsgICAgICAgICAgICAgICAgZGVmYXVsdDoNCj4gPiArICAgICAgICAg
ICAgICAgICAgICBwcmludGsoWEVOTE9HX1dBUk5JTkcgIlVuc3VwcG9ydGVkIGNwdWZyZXEgZHJp
dmVyDQo+ID4gKyBmb3IgdmVuZG9yIEludGVsXG4iKTsNCj4NCj4gVG9vIGxvbmcgbGluZSAodGhl
IGZvcm1hdCBzdHJpbmcgaXRzZWxmIHNoYWxsIGJlIGtlcHQgYWxsIG9uIG9uZSBsaW5lLCBidXQg
dGhlDQo+IFhFTkxPR19XQVJOSU5HIGRvZXNuJ3QgbmVlZCB0bykuDQo+DQoNClVuZGVyc3Rvb2QN
Cg0KPiA+IEBAIC0xNTYsNiArMTU5LDMxIEBAIHN0YXRpYyBpbnQgX19pbml0IGNmX2NoZWNrIGNw
dWZyZXFfZHJpdmVyX2luaXQodm9pZCkNCj4gPiAgICAgICAgICAgICAgYnJlYWs7DQo+ID4NCj4g
PiAgICAgICAgICBjYXNlIFg4Nl9WRU5ET1JfQU1EOg0KPiA+ICsgICAgICAgICAgICByZXQgPSAt
RU5PRU5UOw0KPiA+ICsNCj4gPiArICAgICAgICAgICAgZm9yICggdW5zaWduZWQgaW50IGkgPSAw
OyBpIDwgY3B1ZnJlcV94ZW5fY250OyBpKysgKQ0KPiA+ICsgICAgICAgICAgICB7DQo+ID4gKyAg
ICAgICAgICAgICAgICBzd2l0Y2ggKCBjcHVmcmVxX3hlbl9vcHRzW2ldICkNCj4gPiArICAgICAg
ICAgICAgICAgIHsNCj4gPiArICAgICAgICAgICAgICAgIGNhc2UgQ1BVRlJFUV94ZW46DQo+ID4g
KyAgICAgICAgICAgICAgICAgICAgcmV0ID0gcG93ZXJub3dfcmVnaXN0ZXJfZHJpdmVyKCk7DQo+
ID4gKyAgICAgICAgICAgICAgICAgICAgYnJlYWs7DQo+ID4gKyAgICAgICAgICAgICAgICBjYXNl
IENQVUZSRVFfYW1kX3BzdGF0ZToNCj4gPiArICAgICAgICAgICAgICAgICAgICByZXQgPSBhbWRf
cHN0YXRlX3JlZ2lzdGVyX2RyaXZlcigpOw0KPiA+ICsgICAgICAgICAgICAgICAgICAgIGJyZWFr
Ow0KPiA+ICsgICAgICAgICAgICAgICAgY2FzZSBDUFVGUkVRX25vbmU6DQo+ID4gKyAgICAgICAg
ICAgICAgICAgICAgcmV0ID0gMDsNCj4gPiArICAgICAgICAgICAgICAgICAgICBicmVhazsNCj4g
PiArICAgICAgICAgICAgICAgIGRlZmF1bHQ6DQo+ID4gKyAgICAgICAgICAgICAgICAgICAgcHJp
bnRrKFhFTkxPR19XQVJOSU5HICJVbnN1cHBvcnRlZCBjcHVmcmVxIGRyaXZlciBmb3INCj4gdmVu
ZG9yIEFNRFxuIik7DQo+ID4gKyAgICAgICAgICAgICAgICAgICAgYnJlYWs7DQo+ID4gKyAgICAg
ICAgICAgICAgICB9DQo+ID4gKw0KPiA+ICsgICAgICAgICAgICAgICAgaWYgKCByZXQgIT0gLUVO
T0RFViApDQo+ID4gKyAgICAgICAgICAgICAgICAgICAgYnJlYWs7DQo+ID4gKyAgICAgICAgICAg
IH0NCj4gPiArICAgICAgICAgICAgYnJlYWs7DQo+ID4gKw0KPiA+ICAgICAgICAgIGNhc2UgWDg2
X1ZFTkRPUl9IWUdPTjoNCj4gPiAgICAgICAgICAgICAgcmV0ID0gSVNfRU5BQkxFRChDT05GSUdf
QU1EKSA/IHBvd2Vybm93X3JlZ2lzdGVyX2RyaXZlcigpIDogLQ0KPiBFTk9ERVY7DQo+ID4gICAg
ICAgICAgICAgIGJyZWFrOw0KPg0KPiBJcyB0aGUgY29kZSB0byBoYW5kbGUgQ1BQQyBub3QgYXBw
bGljYWJsZSB0byBIeWdvbiBDUFVzPw0KPg0KPiBXaGF0IGFib3V0IHRoZSBJU19FTkFCTEVEKENP
TkZJR19BTUQpIHRoYXQgdGhlIG9yaWdpbmFsIGNvZGUgaGFkPyBEb24ndA0KPiB5b3UgbmVlZCB0
byBtaXJyb3IgdGhpcyBpbiBzb21lIHdheT8NCj4NCg0KR29vZ2xpbmcgdGhlIEh5Z29uIGNwdSwg
YXMgaXQgaXMgYmFzZWQgb24gWmVuIHNlcmllIGFuZCBhbHNvIGFtZC1wc3RhdGUNCmZlYXR1cmUg
aXMgZGV2ZWxvcGVkIGZvciBaZW4gc2VyaWUgZm9yIHRoZSBmaXJzdCBwbGFjZSwgdGhlIG5ldyBz
d2l0Y2gtY2FzZSBjb2RlIHNoYWxsDQphcHBseSB0byBIeWdvbiBDUFVzIHRvbw0KDQo+ID4gLS0t
IGEveGVuL2FyY2gveDg2L3BsYXRmb3JtX2h5cGVyY2FsbC5jDQo+ID4gKysrIGIveGVuL2FyY2gv
eDg2L3BsYXRmb3JtX2h5cGVyY2FsbC5jDQo+ID4gQEAgLTU3NCw2ICs1NzQsMTIgQEAgcmV0X3Qg
ZG9fcGxhdGZvcm1fb3AoDQo+ID4NCj4gPiAgICAgICAgICBjYXNlIFhFTl9QTV9DUFBDOg0KPiA+
ICAgICAgICAgIHsNCj4gPiArICAgICAgICAgICAgaWYgKCAhKHhlbl9wcm9jZXNzb3JfcG1iaXRz
ICYgWEVOX1BST0NFU1NPUl9QTV9DUFBDKSApDQo+ID4gKyAgICAgICAgICAgIHsNCj4gPiArICAg
ICAgICAgICAgICAgIHJldCA9IC1FTk9TWVM7DQo+DQo+IEVOT1NZUyBpc24ndCBhcHByb3ByaWF0
ZSBmb3Igc3VjaCBhIHNpdHVhdGlvbi4NCj4NCg0KSSd2ZSBtaXJyb3JlZCB0aGUgcmV0dXJuIHZh
bHVlLCBzbyBtYXliZSAtRUlOVkFMIGlzIGJldHRlcj8NCg0KPiA+IC0tLSBhL3hlbi9kcml2ZXJz
L2NwdWZyZXEvY3B1ZnJlcS5jDQo+ID4gKysrIGIveGVuL2RyaXZlcnMvY3B1ZnJlcS9jcHVmcmVx
LmMNCj4gPiBAQCAtODQsNyArODQsNyBAQCBzdGF0aWMgaW50IF9faW5pdCBjZl9jaGVjaw0KPiA+
IHNldHVwX2NwdWZyZXFfb3B0aW9uKGNvbnN0IGNoYXIgKnN0cikNCj4gPg0KPiA+ICAgICAgaWYg
KCBjaG9pY2UgPCAwICYmICFjbWRsaW5lX3N0cmNtcChzdHIsICJkb20wLWtlcm5lbCIpICkNCj4g
PiAgICAgIHsNCj4gPiAtICAgICAgICB4ZW5fcHJvY2Vzc29yX3BtYml0cyAmPSB+WEVOX1BST0NF
U1NPUl9QTV9QWDsNCj4gPiArICAgICAgICB4ZW5fcHJvY2Vzc29yX3BtYml0cyAmPQ0KPiA+ICsg
fihYRU5fUFJPQ0VTU09SX1BNX1BYfFhFTl9QUk9DRVNTT1JfUE1fQ1BQQyk7DQo+ID4gICAgICAg
ICAgY3B1ZnJlcV9jb250cm9sbGVyID0gRlJFUUNUTF9kb20wX2tlcm5lbDsNCj4gPiAgICAgICAg
ICBvcHRfZG9tMF92Y3B1c19waW4gPSAxOw0KPiA+ICAgICAgICAgIHJldHVybiAwOw0KPiA+IEBA
IC05Miw3ICs5Miw3IEBAIHN0YXRpYyBpbnQgX19pbml0IGNmX2NoZWNrDQo+ID4gc2V0dXBfY3B1
ZnJlcV9vcHRpb24oY29uc3QgY2hhciAqc3RyKQ0KPiA+DQo+ID4gICAgICBpZiAoIGNob2ljZSA9
PSAwIHx8ICFjbWRsaW5lX3N0cmNtcChzdHIsICJub25lIikgKQ0KPiA+ICAgICAgew0KPiA+IC0g
ICAgICAgIHhlbl9wcm9jZXNzb3JfcG1iaXRzICY9IH5YRU5fUFJPQ0VTU09SX1BNX1BYOw0KPiA+
ICsgICAgICAgIHhlbl9wcm9jZXNzb3JfcG1iaXRzICY9DQo+ID4gKyB+KFhFTl9QUk9DRVNTT1Jf
UE1fUFh8WEVOX1BST0NFU1NPUl9QTV9DUFBDKTsNCj4NCj4gTml0IChzdHlsZSk6IEJsYW5rcyBw
bGVhc2UgYXJvdW5kIGJpbmFyeSBvcGVyYXRvcnMuDQoNCkFjaw0KDQo+DQo+ID4gLS0tIGEveGVu
L2luY2x1ZGUvYWNwaS9jcHVmcmVxL2NwdWZyZXEuaA0KPiA+ICsrKyBiL3hlbi9pbmNsdWRlL2Fj
cGkvY3B1ZnJlcS9jcHVmcmVxLmgNCj4gPiBAQCAtMjgsNiArMjgsNyBAQCBlbnVtIGNwdWZyZXFf
eGVuX29wdCB7DQo+ID4gICAgICBDUFVGUkVRX25vbmUsDQo+ID4gICAgICBDUFVGUkVRX3hlbiwN
Cj4gPiAgICAgIENQVUZSRVFfaHdwLA0KPiA+ICsgICAgQ1BVRlJFUV9hbWRfcHN0YXRlLA0KPg0K
PiBNaWdodCB0aGlzIGJldHRlciBiZSBDUFVGUkVRX2FtZF9jcHBjPyAicHN0YXRlIiBtYXkgbWVh
biB2YXJpb3VzIG1ldGhvZHMuDQo+DQoNCk9rYXkuIEknbGwgY2hhbmdlIGFsbCBhbWRfLy1wc3Rh
dGUgZGVmaW5lZCB2YWx1ZXMgdG8gYW1kXy8tY3BwYw0KDQo+ID4gLS0tIGEveGVuL2luY2x1ZGUv
cHVibGljL3N5c2N0bC5oDQo+ID4gKysrIGIveGVuL2luY2x1ZGUvcHVibGljL3N5c2N0bC5oDQo+
ID4gQEAgLTQyNCw2ICs0MjQsNyBAQCBzdHJ1Y3QgeGVuX3NldF9jcHBjX3BhcmEgeyAgfTsNCj4g
Pg0KPiA+ICAjZGVmaW5lIFhFTl9IV1BfRFJJVkVSX05BTUUgImh3cCINCj4gPiArI2RlZmluZSBY
RU5fQU1EX1BTVEFURV9EUklWRVJfTkFNRSAiYW1kLXBzdGF0ZSINCj4NCj4gU2ltaWxhcmx5IGhl
cmUuDQo+DQoNCkFjaw0KDQo+IEphbg0KDQpNYW50IHRoYW5rcw0KUGVubnkNCg==


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 08:19:35 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 08:19:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872207.1283161 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXycg-0007Uk-85; Wed, 15 Jan 2025 08:19:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872207.1283161; Wed, 15 Jan 2025 08:19:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXycg-0007Ud-43; Wed, 15 Jan 2025 08:19:34 +0000
Received: by outflank-mailman (input) for mailman id 872207;
 Wed, 15 Jan 2025 08:19:33 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=dCnP=UH=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tXycf-0007UX-1j
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 08:19:33 +0000
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com
 [2a00:1450:4864:20::32a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 71cc4331-d319-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 09:19:31 +0100 (CET)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-4363ae65100so67138975e9.0
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 00:19:31 -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
 5b1f17b1804b1-437c74c57ebsm14398015e9.20.2025.01.15.00.19.29
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 15 Jan 2025 00:19:30 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 71cc4331-d319-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736929170; x=1737533970; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=SWIJ4rNrIdrGkzef1P2uLOe488T87vh+0e7FW7DNfAk=;
        b=KeOPn9Oz8mk6++DSvDd8E7nf1M89fHCawqYH4is+HxkmtmZbFXYcl1kLeI955GZxOC
         n06YzPhF/a/tz5bsZON5PWlQjSabAzTUcEitvjBE/nGxuhMQb4O2hRW4qi3TwDL+t++1
         xV5tKFExb0qc83WhzV5Xo/tYOEhpafAGGK6qHtit3Rqn12tv0hJMV1rT0cRoufstZWby
         SagfadaA486cvyqnBWLx43lfEYAAcfoq6ePYYXeEuqk4R3Az6YZ+sfLxrLKl6N5BXYyZ
         kZhY94+OJZtjteudEizD6K0OTX8GUuYo+HgOgf0J/Gt3kEOHbrFh7MdeaiBSLzVECVh4
         WipA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736929170; x=1737533970;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=SWIJ4rNrIdrGkzef1P2uLOe488T87vh+0e7FW7DNfAk=;
        b=kPCCtW/pB60Gq+8A6kvrQW4lXB2wWLu6kt9eiZTTuNGHCALXdRC7qgHLuU3WuzVKdK
         5/J79ap6LO6+sN1T5UczxrPOhy3uZIHd2wlg+a94+IfiW1oYxkiR2UYOhD0rMZ1w9zMC
         1YnjLVjn3LAsGyhIdCLTnQss6ObaJE11EH13ocjG+3LN+FFUH0z3RmtwrK0lmCHm7Ci3
         C8J2bGGYHhUosVy+Dvg+lHcHqermwKJeQ/Oh1irV04cxg1ObagbKC4RbzXmZWoe5e1zU
         UukZCdpj8xgbtjIaw17jPW+1iTxtly8nKr7ZTIfXwqOOqQy1nDmxSuZwhAhPYArrwe8w
         A5iQ==
X-Forwarded-Encrypted: i=1; AJvYcCU0bcmA7Ovg1BiZH9yK9JtCc6Nwypaqp9ZfvzEXRKQTJyqkFfRfmHDz0pWEOopE+x2ywki5wlqRjtg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzZeLfTDlkn2sCv875r2T5ZO+hVSzqU9YAiMixAydxN1ZRe4KkQ
	mf2c9/6ym4IFnY6QUpTZvx7Vz6k/iAEo51VOIB2vxZN2MDRIpya5CBQjDWoUNw==
X-Gm-Gg: ASbGnct5cc6BE2QPcHZw9BHGgwQygZ48ngJErYF8lJgxPjOKodpo84i+g7FbE7QPSnG
	NJfHtpXSvTBkrLFNpv6GRnQHk8UmtDNTJkGdAGo3v7J49UbX87tDwl2pIL3Fms99A/zSIF+hp59
	uu8ir7VXB3bqSwK9eskrd1ZCZfkLgXpqJ5BH0b7xwXyLiIqzdKW0UetiQ6gCZfSp+3UMwb68dyW
	WSgQCCbSNFZg9YmNqS9M+YgIL4yuGeWpKp3cXUvqNipr1vQZJv1j8P/EEM/bKI0lPxBofiviuEL
	p8X58VprAvNW9f7e7/OBf2HztMdmxybFJVxPmJMmyA==
X-Google-Smtp-Source: AGHT+IHUwvxfYNxiTzO3MmA6MqwXjG6rhzQfK2yXe+D1nfIhjI4XT1IDPk+uc68GrdHbi88xBIHfhg==
X-Received: by 2002:a05:600c:4f4e:b0:436:1ac2:1acf with SMTP id 5b1f17b1804b1-436e26e28cemr245292725e9.20.1736929170460;
        Wed, 15 Jan 2025 00:19:30 -0800 (PST)
Message-ID: <e55b8b77-e97d-4952-a995-b566e7974da6@suse.com>
Date: Wed, 15 Jan 2025 09:19:29 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20] automation/gitlab: disable coverage from clang
 randconfig
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: Doug Goldstein <cardoe@cardoe.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>, xen-devel@lists.xenproject.org
References: <20250114174345.60887-1-roger.pau@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250114174345.60887-1-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14.01.2025 18:43, Roger Pau Monne wrote:
> If randconfig enables coverage support the build times out due to GNU LD
> taking too long.  For the time being prevent coverage from being enabled in
> clang randconfig job.

Just curious: How long is "too long" in this case?

Jan



From xen-devel-bounces@lists.xenproject.org Wed Jan 15 08:32:37 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 08:32:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872220.1283170 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXypC-0002S4-Dx; Wed, 15 Jan 2025 08:32:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872220.1283170; Wed, 15 Jan 2025 08:32:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXypC-0002Rx-B6; Wed, 15 Jan 2025 08:32:30 +0000
Received: by outflank-mailman (input) for mailman id 872220;
 Wed, 15 Jan 2025 08:32:29 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=dCnP=UH=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tXypB-0002Rr-1w
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 08:32:29 +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 40ffdbc7-d31b-11ef-a0e1-8be0dac302b0;
 Wed, 15 Jan 2025 09:32:28 +0100 (CET)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-43625c4a50dso45721765e9.0
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 00:32:28 -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
 ffacd0b85a97d-38a8e3834fbsm16784078f8f.26.2025.01.15.00.32.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 15 Jan 2025 00:32:27 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 40ffdbc7-d31b-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736929947; x=1737534747; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=6qCLVnBEHpF1uDdnaIR4GaCRmAKrcju4TeWNLPlBjFQ=;
        b=UMMp0aCqhRfXabiuvsThiLdITEUw4RlVvbjiUtIkcNm5oZS72TfYCrT//g+qqiDB0j
         MYUQl+3+YMlxMWCWVt3CVSIuj5xyhPq+xXpRW8XHtFPAWP9CtrRLnEhs/ju2Nypucll4
         7CWVG02wsN6yeT8nxehjrb/T2gUVvTCY3kRZRRV6e185KST0VxEuWf76s2KNack7lAVH
         AV6ZaWl5y8cfczet1UuMSn7l7Vo199VkHKgofpZhXOdJlcCtQP+4rDTaZ0f+VTgQGKwZ
         F4lrEGNUi0E980qoOdeRjn+w05PYk0PDa5l25zMJ60dkcQ4MDpLx6hs5RMoDHkzMjtpp
         tNEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736929947; x=1737534747;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=6qCLVnBEHpF1uDdnaIR4GaCRmAKrcju4TeWNLPlBjFQ=;
        b=qa2tTkWuH99EozYzspav6hjAtSadUhGghwG8XjBDy8OJpPRfLGsxx1rDWRWqpQrFWO
         HFogkt+TWNapRWLTz2ZP7Hp4LAdV9IoRDHCLeWJZ2a/NheeoIxaXb8cF3KPMEInN3ilj
         g2CaDS2JuhZ6muxx0lD3AKNvaRlq++u0x+Kdo+Pq3kDedh4gp22Xnxa5chGFUsouEEGk
         Bun+aQlZany6JVfexFCHSnVrBQ7syLjhy3YnFZgyYn1XqpRhC0vk1xE+5d9hdh2+ibUv
         4g2TBLhg/7LqYgP5VJNeQFOzZceg0DI8jgErjYhwAcaSL+mUhcbRFx4W4m3H+oe2p5S8
         07XQ==
X-Forwarded-Encrypted: i=1; AJvYcCVcAY0OLKtHZbV5gErf357iUnW3fZM3DemG7oEo457XWKP9c+Y9OSYru7j23LOsCgGFW3ifRdT4nec=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxTfkNUt22HbJHPORRqsdT4fJoZ88v8bNNW7XY6Rd0gpYi1/5qS
	8FY0i7CZb2P9q01Vn0i87Ghy73GdC2urxiDhwy06lstPySrRN/a3h2iOT0ZNnA==
X-Gm-Gg: ASbGnctklnFzRBBgsqWMbPCeVNwsZYL/TknaoJN5Qu2JbDryIp+QniCh3PqE+Byelir
	lJxLVymYxbPw5bwTT6PidjtF1B6xpfSPfOIu/ZxkcLf/FSXuD4AJskYIz+oPh5e+Ibxsi4A/3sV
	9KL/SP1KpGWdT5w6msZPxdl8lclQVN/YCJvsaoBpHX4oaeasNUiC91QnX0x2xuk5CLOL753KzRe
	L8XFeAOEfcAeYvrp7VDslLpRsyPndtSYDnfgLDuUgR593+1gelIk+IupVzfMqV2FJxJoWs4Mulo
	06+2+T/RWnv0RYqMKV1vC68+sX7Kcz7IGeqqJ59q8A==
X-Google-Smtp-Source: AGHT+IFygbadXDWwWxfe8yuZemjT0loOm1T5xqvNYzQJzPlHntxDo+b9ESgM8Gj3uUrcwCKeYbFaNw==
X-Received: by 2002:a5d:47a6:0:b0:385:f195:2a8 with SMTP id ffacd0b85a97d-38a87312734mr23712996f8f.30.1736929947512;
        Wed, 15 Jan 2025 00:32:27 -0800 (PST)
Message-ID: <af88f6db-f8db-4a2c-b6a7-7955071dd10b@suse.com>
Date: Wed, 15 Jan 2025 09:32:26 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 03/11] xen/x86: introduce "cpufreq=amd-pstate" xen
 cmdline
To: "Penny, Zheng" <penny.zheng@amd.com>
Cc: "Stabellini, Stefano" <stefano.stabellini@amd.com>,
 "Huang, Ray" <Ray.Huang@amd.com>,
 "Ragiadakou, Xenia" <Xenia.Ragiadakou@amd.com>,
 "Andryuk, Jason" <Jason.Andryuk@amd.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <20241203081111.463400-1-Penny.Zheng@amd.com>
 <20241203081111.463400-4-Penny.Zheng@amd.com>
 <e7f1b3c3-dce4-4a0e-b1cf-c6ba8af95290@suse.com>
 <DM4PR12MB8451AF14F5B8609E54312F8DE1192@DM4PR12MB8451.namprd12.prod.outlook.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <DM4PR12MB8451AF14F5B8609E54312F8DE1192@DM4PR12MB8451.namprd12.prod.outlook.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15.01.2025 09:18, Penny, Zheng wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Thursday, January 9, 2025 5:59 PM
>>
>> On 03.12.2024 09:11, Penny Zheng wrote:
>>> --- a/xen/arch/x86/platform_hypercall.c
>>> +++ b/xen/arch/x86/platform_hypercall.c
>>> @@ -574,6 +574,12 @@ ret_t do_platform_op(
>>>
>>>          case XEN_PM_CPPC:
>>>          {
>>> +            if ( !(xen_processor_pmbits & XEN_PROCESSOR_PM_CPPC) )
>>> +            {
>>> +                ret = -ENOSYS;
>>
>> ENOSYS isn't appropriate for such a situation.
> 
> I've mirrored the return value, so maybe -EINVAL is better?

Generally most wrong uses of ENOSYS want replacing by EOPNOTSUPP.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 08:34:08 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 08:34:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872227.1283180 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXyqj-0002za-Nj; Wed, 15 Jan 2025 08:34:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872227.1283180; Wed, 15 Jan 2025 08:34:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXyqj-0002zT-KL; Wed, 15 Jan 2025 08:34:05 +0000
Received: by outflank-mailman (input) for mailman id 872227;
 Wed, 15 Jan 2025 08:34:04 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=9Lts=UH=amd.com=penny.zheng@srs-se1.protection.inumbo.net>)
 id 1tXyqi-0002zL-PN
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 08:34:04 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20605.outbound.protection.outlook.com
 [2a01:111:f403:2415::605])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 797360ef-d31b-11ef-a0e1-8be0dac302b0;
 Wed, 15 Jan 2025 09:34:03 +0100 (CET)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 MW4PR12MB5642.namprd12.prod.outlook.com (2603:10b6:303:187::9) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8335.19; Wed, 15 Jan 2025 08:33:59 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%4]) with mapi id 15.20.8356.010; Wed, 15 Jan 2025
 08:33:59 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 797360ef-d31b-11ef-a0e1-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=KNGq1jYmAJPfCpPkG7MGHWPDJ91q27EORSGzBhxKDu6uQnW8uiAksh0yKNanl1dUbPZ9a6kQM/44l60IauQhHH6xKWYPNm1O+125Iy2w8a+SRx5NWRvtcfs2KvJHVxePKPu/ahyaFSt8l/25F+1w0RLuE/NmYEVq+zhgiqj6p3v1CcndxAxUZp+2jeDx2hQpqzow66SMxzIRbZ6zhzY7JW6DkaWUOEhEb0WlCXdFt9PIgMF74LYTW47VF2aYTFB7F4AGadjFdptoL2+aCp8SlzbYTbUurP1CXfHhF4TR7NIZmlbdulAQAD1yf3i0U+P2wnXcTD2dg2x+0GI952F1yg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=Btj5LjQxhrhR8/qfl/ax6KRztoFP6CkgKvKhOv3tAfI=;
 b=driehf/hxvDhOhzS4kmxctiePN4h2A64Pcqmloq86Y62EX6rXAuxHNnszRF9u2O7Bsa1fh8pUM4I9CuD3ICcjJTXWk7L4scGHkVhuHLeSCGCFIuoUg7cHN2YwQTPNCoqLgBd/qYi7sTGu3xHGbhD0y2eg6uNgFOUThjPmumluy5EoYaBaO4JBdUwL7dSMU2Sb4vZjFU/OmGMuP6Xxblr2KScBg3zmxJCSoLa9cIPrI19wYZqt4di0HzPNxMusYQI48tdMXnL+ry+nAY+eg1zA/xftSghNmU+xQ4H5AinyLtwLo5L7hlcslCP3Rvf40MN2kNsa2/Ooh4SDkuNmorRDA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Btj5LjQxhrhR8/qfl/ax6KRztoFP6CkgKvKhOv3tAfI=;
 b=zYhOSX8ReNmgoClGZM2zsOqwnmvvKaUWhZSotuoI1PhAd7tUrQYgAv2Uoi02MssJ+QPnjKEeMtk/H8owLWYN9FwoZHzY66NcoFazVWgp+r5+PLF9JXFTPM9k76IHLOBVV4SgRxp66MOsxsig2Ub0NDCkdgSQkW3ZD4f8PD9hj1o=
From: "Penny, Zheng" <penny.zheng@amd.com>
To: Jan Beulich <jbeulich@suse.com>
CC: "Stabellini, Stefano" <stefano.stabellini@amd.com>, "Huang, Ray"
	<Ray.Huang@amd.com>, "Ragiadakou, Xenia" <Xenia.Ragiadakou@amd.com>,
	"Andryuk, Jason" <Jason.Andryuk@amd.com>, Andrew Cooper
	<andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, Stefano
 Stabellini <sstabellini@kernel.org>, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	<roger.pau@citrix.com>, "xen-devel@lists.xenproject.org"
	<xen-devel@lists.xenproject.org>
Subject: RE: [PATCH v1 03/11] xen/x86: introduce "cpufreq=amd-pstate" xen
 cmdline
Thread-Topic: [PATCH v1 03/11] xen/x86: introduce "cpufreq=amd-pstate" xen
 cmdline
Thread-Index: AQHbRVx5dnEd/G58t0eEMeNox50YY7MOb2uAgAksanCAACl1AIAAADlg
Date: Wed, 15 Jan 2025 08:33:58 +0000
Message-ID:
 <DM4PR12MB8451D50371F83C20123F4636E1192@DM4PR12MB8451.namprd12.prod.outlook.com>
References: <20241203081111.463400-1-Penny.Zheng@amd.com>
 <20241203081111.463400-4-Penny.Zheng@amd.com>
 <e7f1b3c3-dce4-4a0e-b1cf-c6ba8af95290@suse.com>
 <DM4PR12MB8451AF14F5B8609E54312F8DE1192@DM4PR12MB8451.namprd12.prod.outlook.com>
 <af88f6db-f8db-4a2c-b6a7-7955071dd10b@suse.com>
In-Reply-To: <af88f6db-f8db-4a2c-b6a7-7955071dd10b@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_ActionId=2345f288-ffe9-442a-bbb2-449ebf3f8be9;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_ContentBits=0;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_Enabled=true;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_Method=Standard;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_Name=AMD
 Internal Distribution
 Only;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_SetDate=2025-01-15T08:33:14Z;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DM4PR12MB8451:EE_|MW4PR12MB5642:EE_
x-ms-office365-filtering-correlation-id: 3239d0b1-3a92-4589-f87c-08dd353f5b72
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?M1VyU1lQQVRBQXMvdUYwNllvUll3RENhZjh3bVhXby9ldFVjV3JtSUhxLytE?=
 =?utf-8?B?Y1hJQUJXdDA0Smx0NGNuSGkyRnhuTC9kdWtZekZ4RWtPTVVia1Z3a1lQaFlE?=
 =?utf-8?B?YXF3QUMwUmU2YjhMaVRLZnNOQjFSZFlmZ0Q2NVNlaG4yeXYrRmppdVA5OFpr?=
 =?utf-8?B?MksyL3RxR2tEcGxCU3lURzM1dENSUjVFRnZmT1Q4cXBFSHhWc0s1b0V4ZXo1?=
 =?utf-8?B?dVFneEFJRU93L2JIYVExdXE0anJWeVpqcEtvK3dTNUZBMUpCQm05ZERqNm9B?=
 =?utf-8?B?dTFubWxlWTJhZkY1MWJ1Y3BvV1B5aVhIbWluLzVLa2VhWVdGbGJZaVNBL3FT?=
 =?utf-8?B?aitkNkFSeXkyN21BR2gvQmJKRE5WeElTOGFrWHdRZ25USnZmUFdKQkJYYlVh?=
 =?utf-8?B?UVVteDNVWWNYeU1XRkxjamJqQTVjZGJDOUJlTjR4UDMrcm5UaTlvYnQ4cVo0?=
 =?utf-8?B?ZjlzN2pBNkgyUGgvRmxudDBhbVoxLzJ6eVd1ZXlEenJMTDhVSm9wdEJpRU1j?=
 =?utf-8?B?SXN4TUQ5cE9obVJpSUZlUVZabkxNK3M1cGEzOHh0N1RRYUN4QWd5V2lreHIz?=
 =?utf-8?B?TmNDWGYzK1c5ZjdkQ0hURGJ1UVVzMXh5Q0MrOXZFQkZ3ZkZ3cGZ0N2hya0li?=
 =?utf-8?B?SkoyK2w5U0wvL1l6TVY1eEFoNEI1MlpsUXc0VXE1YURBNnkwQ1BUZGplWVE3?=
 =?utf-8?B?NFByVDFvc2lwWm1CeS9Iaml1NldxR2lES3czSnJGbUdZS21XSDdJU1ZsZzdH?=
 =?utf-8?B?K3YyZ0g2N1BIVHBmd1ROV3IzcFhmcnJNVHo0eFhaM3dsK2F5cGhWVkZUdmFI?=
 =?utf-8?B?NmxMRmFBVTl5TmpVN29yMVRURHR0NTB3anFudEhwazVMUVc0c1k3Mmt1c1p4?=
 =?utf-8?B?d0Z6bWw0WnRGQXFFUzRuRmhoVW9WRHY0dHR4bldqcDRGb1pWb1oxT29jSGtL?=
 =?utf-8?B?OTR5aVM1Uzc5cHBQU0QrQ0RTMG9Fb1MwcW5zRFN3dGVadUtzWDBiQWhVTHRP?=
 =?utf-8?B?ZjBHOFFEMVltUGNUVW4xN1BpOTVvRVZzVklONHNPUUFZMy9TNUJmOUdCTXdS?=
 =?utf-8?B?UFNsdFlVM1RKb3BjVGZNR09ieS9nWDZ3dEJVSjNBa1kzTlBPeFN6Und4TUgv?=
 =?utf-8?B?N3o4NFNTcGlvcjBqZXdaMFFiNTVpY0x5cWFhd2doYXk4dEU2aDBhOWZXdTBr?=
 =?utf-8?B?S1oySWp6YW1DREk2by9QcjJ4Q21OZ2hjMXFIMktQdm9QVzlTbDFTRGFVTDRw?=
 =?utf-8?B?Zjgrekl4N01VUjlQc1B5Mm5YOENlUXZpc1B5MkZ5dU9uLzlUTGk1eHVPcFlU?=
 =?utf-8?B?TzNnNXpBblNFbEdFbzZnYkJhT0JjKzBncnF6QTY3LzhteThCZXA1cHZ5WGtC?=
 =?utf-8?B?WlcvbHNJay9hNEoyNVJUT1c4WkpGekV1TFRhb2N0amlJZXNrY1pnVnJraXJm?=
 =?utf-8?B?WVdnSksyZ0VkeWN5U1QvM3FrNERKZG1lNDZERWNCSlprNlBPeGxGTkZKZURP?=
 =?utf-8?B?RXFEeXE5c0s1VmVSL1piNXQ1Vmc0Rlg4TnVGd3ZQRm54T1RBanIwNWRyVmVT?=
 =?utf-8?B?UExmaWRYaVE0TjBuT2IweEhOZVlHeTUzU3pCWjJaTXI0ek55Qm9LUzNRcnJq?=
 =?utf-8?B?RWhPNGZONFNoejVlVHpDVmg1L002Q3ZtRWpWS1YxUHVwUS9hQitTYnhJR2hP?=
 =?utf-8?B?QUtzV2JYZW1uSTcrS2JHWHhxWGlFVjVqa0ZrRTdZNmhEN1hwaFFRNHduZEtm?=
 =?utf-8?B?OGhCKzloaEJWL1l0UFpsa0IwcTRpcjRuQ2RodG5ZMTRqQTA3ajd5VGVqZ3lm?=
 =?utf-8?B?dlBWTUhaUXFxRWRYRlIyWkZlQlNSZElEUWE3ZVIyR0w4QXJZR1FLR0JoajZk?=
 =?utf-8?B?Ni9lUm5aOTdjaTZrRXJvOHNpZWYyS2tVZE8rUWt4VU1PUktBNmF3TUVOZlFY?=
 =?utf-8?Q?Wk0O18CMv6B7voNUThp4EYIIrtB00pV+?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB8451.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?Y0gveWtoS3FDbHVGOXFKQ2k2UXBxdkFycGY1OHBoeW5ST3V0aUZzTVp2NlFG?=
 =?utf-8?B?UWFCTWtML09XOE9DczFaRGhhOVVJaUh2dHIyKys2aGQ2bytZSTJxWWZGVVox?=
 =?utf-8?B?anpIQ25vN3Voa2c2TEc5WXhlajV2b3kwRnVuUFRMUkJaNWY0R0h2SXVvdy96?=
 =?utf-8?B?a0oyeEhWNzhmZi9CMFFxbmJDemd1dzFMY2kwbTBORStqUkl0ejhBSVJqVUNQ?=
 =?utf-8?B?d2RDa1NrcVE4VW05YVpLSHU0bTMxd3NFdGxjQmwvU3duWUlCUkJLSHEzYUt2?=
 =?utf-8?B?UERYNW9JQk9YMk1WSk1MSExKOEc3RHY3dXpEazd0WG5pMHBGYWxRYndzMXVI?=
 =?utf-8?B?SDhsNzJKWkxKSVlPQkdTQ1hBQTNJbVQ4Z1RPWVVBVDQyd3VmbExUdHJzOVNO?=
 =?utf-8?B?U29sSjdYeVQySVRSSDlJcVk4a1N1alRtR2V0TWdtekNDbC8xMW4zN3JiU1V5?=
 =?utf-8?B?Q2FKdVhFb3pUZ0toNkhMNjlibW0rTlVUUHp6MEVZUkhxL1N3WjcxYlU1SUV6?=
 =?utf-8?B?OE5SR3k4R2JVVm5xaVI0SzR5ODA2dllLUGJXWlBaR1gwcEJ1VGVodlQ3MFBC?=
 =?utf-8?B?QlhJM3htNW5GeENFS1FKWUJBaUI0NVpFZ1ZiakoyaWorcmFLWEtPWHliM012?=
 =?utf-8?B?cS9CVVQvSGlRZUEzQmZwL3ZHdlpITU9OaHVoVitPVzZsZmJHTk9FMERLWDJO?=
 =?utf-8?B?c0RaTTc0YkxaWjJrRFBDcTFoV0ZoREk4cFdFeDlPWENUT0dwWk40R0N2Nm5B?=
 =?utf-8?B?dmxtMEpnZVlYVHJVTmpkdmxjMitmUFh0SGhwZnVMcC9RUU5FWWo1Q2tvdGw4?=
 =?utf-8?B?K2J0VGErWEk3QW1rYlF3Q242WGhBODBFakppNzlkV3NVTjhmR1JvNVNjRGFJ?=
 =?utf-8?B?WGUza0dCaW9sTWliTitzVDJqTmlCMHIwZUp3M1hXUU1BWWhZUmhHNkZxaW4z?=
 =?utf-8?B?THBYTE13TTE3NmlRM2JsQ2FQRnczU2p6dTJqd2d1YWdmYXI0MkFKVk1ZSU5K?=
 =?utf-8?B?VnRNZkZudk91OUhlRFp2K1F1aTk2STdDRjRkZytFNXNPeGRrQ2k2Mm5sMjdP?=
 =?utf-8?B?aHQzNzhUbFI4ZHRHS1lNZ05KTDk0eDczOVNaZXFLNnZiK29IWTErUEJaSHJl?=
 =?utf-8?B?eGNGbVMzMmNwenl4b3IxaEo1cDJFbXVZR3hjTXRyM1VleWc1R0xtREFxSElx?=
 =?utf-8?B?S2ZUNXpuVkh3WkxHdDRSS2FzUFFZbDk5Y2hNcWo0VC9jSmJoQXZ2RHU1WSsy?=
 =?utf-8?B?VnN0dGRQWUQvRHF4bmdmd3BEdVh4MFkvSzV0VmNwSU5GajhadHNVY0JYcHNN?=
 =?utf-8?B?eXpLQUl1dDZqQ05IWFBBQ0pJR2w5VWRNWnFnRmxUUHJ0cWNjbWoyQ3lpdC9D?=
 =?utf-8?B?K04yWDVLSHNlTExLNzYwTE1DOEN6eko0NE4rVzJkSTY3N3JKTjVaa0pWRURC?=
 =?utf-8?B?TkNVYVhxKzRIOEV6UTVQK3M5N1lHWi92eUJ2anliQTNTYjhrbFIzaUJvSzVh?=
 =?utf-8?B?M0NzK3pPTzNQcUxsZ3ozR2Q1S3RtUW5JZFowY2E0TWI3cTYrd0dKVE9zcHNt?=
 =?utf-8?B?dkVHcU02L2ZWeEQzNHoxRWRRd01HU3RxVEUzdDdqeEZ5SVY4R3hhK2hpUFNF?=
 =?utf-8?B?a2hhbmYvY0hUQlZENDIrSlcvOCtxekh1OFZGTTdHYmF5Z21IWmx1enpncTRz?=
 =?utf-8?B?RzdtWHdieHo5U3lKOTNOVGJ5aWJXRGh3RncyeGQ5c3FZbGd6b0g5OHhXZXdP?=
 =?utf-8?B?SVhaSjhVQkxIV0lxTjY5dVRtZTFrOWt5aTErQUp3S0pwNUY5MmRnQi9SNHVG?=
 =?utf-8?B?UVZacXpSaUxWTHNkMzZXNTlPN0F4b0p3VDNJdEo5MVZwZEtKdmlNZ0tOS09R?=
 =?utf-8?B?Q1FnMDRsenNkQkJiQ0pEVUhNOWw2TzYvZjFYNVFVSkhIVUNOeWVjV05LZEx1?=
 =?utf-8?B?bU5CNjlNbENSVnVrR0xNWFRQek1SUFZHZkZwelltS2lSQjYrdWcrZ2RLWlNl?=
 =?utf-8?B?Qk1PQm5UVklnZ0NmN05ITEVla2dUcnF2TXZZd0RiVlVvM0s1UjdCSkdiZDhT?=
 =?utf-8?B?dTJSTkJaN1JEQ3kyQURsbS8rYXVWSzVEa24zakNOLzZrdnc3US9meEw3dEo1?=
 =?utf-8?Q?6RQ0=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB8451.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3239d0b1-3a92-4589-f87c-08dd353f5b72
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2025 08:33:58.9418
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: HKltqlwq0/20LrsfeuqiV5grC00Yd07bbXXU1gXOpWdRxBgLhZhFSVfQe9Ot97ULYrSihtKLMwY3H8O+h+itsg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR12MB5642

W0FNRCBPZmZpY2lhbCBVc2UgT25seSAtIEFNRCBJbnRlcm5hbCBEaXN0cmlidXRpb24gT25seV0N
Cg0KSGksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSmFuIEJldWxp
Y2ggPGpiZXVsaWNoQHN1c2UuY29tPg0KPiBTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMTUsIDIw
MjUgNDozMiBQTQ0KPiBUbzogUGVubnksIFpoZW5nIDxwZW5ueS56aGVuZ0BhbWQuY29tPg0KPiBD
YzogU3RhYmVsbGluaSwgU3RlZmFubyA8c3RlZmFuby5zdGFiZWxsaW5pQGFtZC5jb20+OyBIdWFu
ZywgUmF5DQo+IDxSYXkuSHVhbmdAYW1kLmNvbT47IFJhZ2lhZGFrb3UsIFhlbmlhIDxYZW5pYS5S
YWdpYWRha291QGFtZC5jb20+Ow0KPiBBbmRyeXVrLCBKYXNvbiA8SmFzb24uQW5kcnl1a0BhbWQu
Y29tPjsgQW5kcmV3IENvb3Blcg0KPiA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT47IEp1bGll
biBHcmFsbCA8anVsaWVuQHhlbi5vcmc+OyBTdGVmYW5vIFN0YWJlbGxpbmkNCj4gPHNzdGFiZWxs
aW5pQGtlcm5lbC5vcmc+OyBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT47
IHhlbi0NCj4gZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcNCj4gU3ViamVjdDogUmU6IFtQQVRD
SCB2MSAwMy8xMV0geGVuL3g4NjogaW50cm9kdWNlICJjcHVmcmVxPWFtZC1wc3RhdGUiIHhlbg0K
PiBjbWRsaW5lDQo+DQo+IE9uIDE1LjAxLjIwMjUgMDk6MTgsIFBlbm55LCBaaGVuZyB3cm90ZToN
Cj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogSmFuIEJldWxpY2gg
PGpiZXVsaWNoQHN1c2UuY29tPg0KPiA+PiBTZW50OiBUaHVyc2RheSwgSmFudWFyeSA5LCAyMDI1
IDU6NTkgUE0NCj4gPj4NCj4gPj4gT24gMDMuMTIuMjAyNCAwOToxMSwgUGVubnkgWmhlbmcgd3Jv
dGU6DQo+ID4+PiAtLS0gYS94ZW4vYXJjaC94ODYvcGxhdGZvcm1faHlwZXJjYWxsLmMNCj4gPj4+
ICsrKyBiL3hlbi9hcmNoL3g4Ni9wbGF0Zm9ybV9oeXBlcmNhbGwuYw0KPiA+Pj4gQEAgLTU3NCw2
ICs1NzQsMTIgQEAgcmV0X3QgZG9fcGxhdGZvcm1fb3AoDQo+ID4+Pg0KPiA+Pj4gICAgICAgICAg
Y2FzZSBYRU5fUE1fQ1BQQzoNCj4gPj4+ICAgICAgICAgIHsNCj4gPj4+ICsgICAgICAgICAgICBp
ZiAoICEoeGVuX3Byb2Nlc3Nvcl9wbWJpdHMgJiBYRU5fUFJPQ0VTU09SX1BNX0NQUEMpICkNCj4g
Pj4+ICsgICAgICAgICAgICB7DQo+ID4+PiArICAgICAgICAgICAgICAgIHJldCA9IC1FTk9TWVM7
DQo+ID4+DQo+ID4+IEVOT1NZUyBpc24ndCBhcHByb3ByaWF0ZSBmb3Igc3VjaCBhIHNpdHVhdGlv
bi4NCj4gPg0KPiA+IEkndmUgbWlycm9yZWQgdGhlIHJldHVybiB2YWx1ZSwgc28gbWF5YmUgLUVJ
TlZBTCBpcyBiZXR0ZXI/DQo+DQo+IEdlbmVyYWxseSBtb3N0IHdyb25nIHVzZXMgb2YgRU5PU1lT
IHdhbnQgcmVwbGFjaW5nIGJ5IEVPUE5PVFNVUFAuDQoNCk9oLCB1bmRlcnN0b29kLg0KDQo+DQo+
IEphbg0KDQpNYW55IHRoYW5rcywNClBlbm55DQo=


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 08:34:30 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 08:34:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872234.1283189 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXyr7-0003T3-VA; Wed, 15 Jan 2025 08:34:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872234.1283189; Wed, 15 Jan 2025 08:34:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXyr7-0003Sw-Sb; Wed, 15 Jan 2025 08:34:29 +0000
Received: by outflank-mailman (input) for mailman id 872234;
 Wed, 15 Jan 2025 08:34:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=hmQ5=UH=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tXyr6-0002zL-6r
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 08:34:28 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 87cc6902-d31b-11ef-a0e1-8be0dac302b0;
 Wed, 15 Jan 2025 09:34:26 +0100 (CET)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-aae81f4fdc4so1217576066b.0
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 00:34:26 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c90d7432sm723493266b.49.2025.01.15.00.34.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 15 Jan 2025 00:34:25 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 87cc6902-d31b-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736930066; x=1737534866; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=z2ysLbEI7X584EpDVqE9nJ0x3U18niFArgjG0UQN44k=;
        b=YcYtC5gkayrXsOF5sA+Gl6WDoMJXYfXzD6wrYUMgqOuO37e5rKpprcg4gpedanFrVU
         7DHKR2qNdqDl0n1SLX2VeZw86HU1x5qCLYDgKNJ2tMcN+vJcC9UyGK+1inmsJhGHxBq7
         B6Mz5SFQrOI8unREeLVac9TqM1sWJz5bz7Pu0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736930066; x=1737534866;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=z2ysLbEI7X584EpDVqE9nJ0x3U18niFArgjG0UQN44k=;
        b=r1VLHgWQxLmfj3/1Wb937LoWmXwko8aBPlxuOJ9xGumO19f6mzZ9dOJ3XrSlqyUiB7
         a44aRfFDNl+aQ11dem4Bo5ZneGbExbtEvUYWyBPthH6Jhenxlo8E10dzGfYC/U1j0liC
         k4eOrPQzDJUhFkCr5lg8a8tH6AZCt2UCEftiLojZ3SQiqrBgmdcndbB+cQCu9hSYsVR8
         zL53QV8K5kQsGEaThLN9gg4JbqQi8vZcpS13AsX3+9VUWpplM6kD7bv6P9nBc3XG1lMP
         WIqBrmUleH0EDzcsKDDMY6ohbnhT9hS4pztGo5HPWCzkLI85JGANxUicmoAeOFqSCZGC
         632Q==
X-Forwarded-Encrypted: i=1; AJvYcCUDzUWYIUwPsfD+PfcCfdkP269hnN0uPXhuN1VgdWEgxy2tCzW4792bUzJ4136Zy0/qc2snhfUUhsQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwVy2kwh6xjB1sM7Kd4SF/oU+0V1kOv+NtOIaJupHv85NiAHwH9
	2dw7xXPZr00XQyTZO6eA4YfeB/IsldjwJbe4xsfAk6lbzwpwPVKlgELYNATZzmI=
X-Gm-Gg: ASbGncvugW96PlpXZX55fiae5yuYqucrYbGc1sTKm/WlSQZgHfrHGKmfIlZnY/08TVK
	2EIpv9JB27b0cs33K2A7pBX5wbxyzW/01zIjEhpvShi/kj5jE7fKSKEuov9+xD3H2oJ9DrVYGlE
	lEVoheT+30LGtAtf5xD8LF1OyE+fpXDN2ZjUbzZzgMWmZOAZNEKigVietkuL385NPQOLVRJoufH
	WV5D5mrFuOaotwVzJHrvxzl5a8oRZLHcwp0l8yPFA8/So9dM0y4k8fcmqmRiwRmmOv1EKW4e93N
	QRiS311o9KyHHrpIm3Xn
X-Google-Smtp-Source: AGHT+IHY6Q8LOH1M4ArROFPA/UvB6WVYMaL32D/K5ffZv/60IPmdh99R/ZS0u5UWpp7XWb2lI0mITQ==
X-Received: by 2002:a17:907:3da3:b0:aa6:33cf:b389 with SMTP id a640c23a62f3a-ab2ab748baamr2413942766b.34.1736930066215;
        Wed, 15 Jan 2025 00:34:26 -0800 (PST)
Message-ID: <f9e56fb4-0ed7-46ad-b0cc-55c95cebaaad@citrix.com>
Date: Wed, 15 Jan 2025 08:34:25 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20] automation/gitlab: disable coverage from clang
 randconfig
To: Jan Beulich <jbeulich@suse.com>, Roger Pau Monne <roger.pau@citrix.com>
Cc: Doug Goldstein <cardoe@cardoe.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>, xen-devel@lists.xenproject.org
References: <20250114174345.60887-1-roger.pau@citrix.com>
 <e55b8b77-e97d-4952-a995-b566e7974da6@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <e55b8b77-e97d-4952-a995-b566e7974da6@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15/01/2025 8:19 am, Jan Beulich wrote:
> On 14.01.2025 18:43, Roger Pau Monne wrote:
>> If randconfig enables coverage support the build times out due to GNU LD
>> taking too long.  For the time being prevent coverage from being enabled in
>> clang randconfig job.
> Just curious: How long is "too long" in this case?

Timeout is currently at 1h, for what is a single build of the hypervisor.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 08:56:22 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 08:56:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872245.1283199 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXzCB-0006zT-K4; Wed, 15 Jan 2025 08:56:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872245.1283199; Wed, 15 Jan 2025 08:56:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXzCB-0006zM-HU; Wed, 15 Jan 2025 08:56:15 +0000
Received: by outflank-mailman (input) for mailman id 872245;
 Wed, 15 Jan 2025 08:56:13 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=KZm5=UH=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tXzC9-0006zG-EJ
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 08:56:13 +0000
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com
 [2a00:1450:4864:20::629])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 91da539e-d31e-11ef-a0e1-8be0dac302b0;
 Wed, 15 Jan 2025 09:56:12 +0100 (CET)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-aaec61d0f65so1283013366b.1
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 00:56:12 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c913804esm723625766b.84.2025.01.15.00.56.10
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 15 Jan 2025 00:56:11 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 91da539e-d31e-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736931372; x=1737536172; 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=fioy/FUik1U4ok29Gy4Oa9UKfgKtHdmTQoTlkcW/IFY=;
        b=t4BYtyg9PC/qeTAjVAJzjQ4X4FgiadLO4cgAwyrd7l7F/5NFyVR35lmhI7LppfzmI4
         9Q4/L+I3/1mVyVdcLVIT0iV7IEBhaXamsm21VDZhfVjzrBJd1h2nIGL/sDTALukjn696
         lqAMwYsC1Awy38Nr1RGlLofVlyZUQYVq4PqBw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736931372; x=1737536172;
        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=fioy/FUik1U4ok29Gy4Oa9UKfgKtHdmTQoTlkcW/IFY=;
        b=hF328OHEXJ4k54qWdEmZX1Ad+tMW6nSAun07uW5q/E1sT8u/M+/PLQ886lvtiEQGi+
         X1KKqASwbRvpWd9UM7CY48hUPhQk4d29DuzJfn4Gv1+TxJhBumszumdA1VkwVE43jkXN
         9Ai6PiBTX1+jW9IRmeD6M22FSDOTG1sL1j7m29YSfwtUoSuO15Or7aReUhimBF2NUwYo
         n/Yf9LJ9L35zNoHtxJ3xjjKWVLkjEKJ9v3ozSoCDKV8jBprBR9eOqx+61Ph9VwZxVczD
         xthsZPJIrXzSRzJCdVUwiK49mN2ca917B6sNxk79kW0YlubqoZt/uO/mEdUuxd9cMRpA
         0rng==
X-Forwarded-Encrypted: i=1; AJvYcCUoaH+I8nP+urRWMMQ+Mi63hAw+Y4V6KwZ0oLN5GPEwuG2X2SX1NZbDtgneRyF4veKuG0E9hdaur4A=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyK6M8B425eRb67KahWyCkcr3N6I62JE0xZMh5AIqtx5OWTUbqk
	TsEKw0rAJlnrZQ9JIOGp8EcmgnShqP3lfaE04Yd6fQg+XnCKDA+vq3JF4l+sh9Q=
X-Gm-Gg: ASbGncurwfVHfTuc2gO4+/JIOISvshBPJKk2o2NueN3pTufRHYgJ+G9UCUJUY3LqmL4
	j0/SeL9GYCOXbcc+U60UgZJCBwPC9K8qKMvMhRdQqmlBYO5bo17ooj+G68p3NXILy2vfS7IbUix
	6KEzqK8tfxsOVXOZrjfH4ayq+Ca0ezNuGn9IANQZf1VNNw0XZEAPIcXw9KET60i3YAweLAQ1KH/
	mMRqeb4216qMnhbfhyPcPhcNntOKAP+NPwaChCGSCn8PuTj8dy6CwaOOecKI0MZQDI=
X-Google-Smtp-Source: AGHT+IGe8uDXQGcM0q4llbxcAFJnfhNSgJoCzWBFrsNg0mtR2DuuDm3DrzGUnjQUh3j+tRSzyWYuBQ==
X-Received: by 2002:a17:907:2dac:b0:aa6:7785:5485 with SMTP id a640c23a62f3a-ab2abc6e1c7mr2466889066b.38.1736931371685;
        Wed, 15 Jan 2025 00:56:11 -0800 (PST)
Date: Wed, 15 Jan 2025 09:56:09 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Doug Goldstein <cardoe@cardoe.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH for-4.20] automation/gitlab: disable coverage from clang
 randconfig
Message-ID: <Z4d4KXMOtmfOOq8i@macbook.local>
References: <20250114174345.60887-1-roger.pau@citrix.com>
 <e55b8b77-e97d-4952-a995-b566e7974da6@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <e55b8b77-e97d-4952-a995-b566e7974da6@suse.com>

On Wed, Jan 15, 2025 at 09:19:29AM +0100, Jan Beulich wrote:
> On 14.01.2025 18:43, Roger Pau Monne wrote:
> > If randconfig enables coverage support the build times out due to GNU LD
> > taking too long.  For the time being prevent coverage from being enabled in
> > clang randconfig job.
> 
> Just curious: How long is "too long" in this case?

Left it for >30min stuck on the final linker invocation IIRC and it
hadn't finished, so no idea really.  This was also running on a docker
x86-64 container on my ARM mac, so there was an extra layer of
emulation.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 09:21:57 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 09:21:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872256.1283215 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXzau-0003OG-Ut; Wed, 15 Jan 2025 09:21:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872256.1283215; Wed, 15 Jan 2025 09:21:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXzau-0003NU-QS; Wed, 15 Jan 2025 09:21:48 +0000
Received: by outflank-mailman (input) for mailman id 872256;
 Wed, 15 Jan 2025 09:21: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
 <SRS0=kbvD=UH=epam.com=Mykyta_Poturai@srs-se1.protection.inumbo.net>)
 id 1tXzat-0003Ki-N5
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 09:21:47 +0000
Received: from DUZPR83CU001.outbound.protection.outlook.com
 (mail-northeuropeazlp170130004.outbound.protection.outlook.com
 [2a01:111:f403:c200::4])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2460b1c2-d322-11ef-a0e1-8be0dac302b0;
 Wed, 15 Jan 2025 10:21:46 +0100 (CET)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by DBBPR03MB6795.eurprd03.prod.outlook.com
 (2603:10a6:10:208::19) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8356.12; Wed, 15 Jan
 2025 09:21:44 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971%5]) with mapi id 15.20.8335.017; Wed, 15 Jan 2025
 09:21:44 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2460b1c2-d322-11ef-a0e1-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Y47soDzYjxppb1ccVqFExjnQnp1jsBg/bqv5UW3iEezZfPQxrhzUrn0FN/SxDNtsjuzqXY9J/ZfLKCGzOe5xaMnuGzHlUm/d5axwMXZs4WIKcYSOMXKAW9U52yns67kjflM9tO+5rBe1/CFUGdpd+n7O8nauNBnPdWy8lZ2C9cmTDt9wVCp8Ao3hNExq48tDh4lhLdP2fH9SV316jZhGOvclUC3sCsVNkwX5l/FHFxmOysyritu86TQDu3GJGUvtSRZkv1wowmdw9sdgkqpFdv6Gz3090Iz1aUXcrGbzwm0buxv8iguBZ4Y2dCbOhg6JGgsiqBnAWHWNQFflqIQUtg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=eFrATFgoRJ6d7ziVWdmSYdnPpEDIZasMI6cQcXBIx4o=;
 b=n8tX68oIpvHYg1ZCeflSG70/qtgvEZmRo6H+JiUysS+rSQe+fLD2Yk4tmjKz+BcxbfzDOBEZiEB8lvhfDoSA+gC0jTNCaNf4zHgyqVXrfRzr8gZhG2VrMZUcf+SyVr02Gf4dWdRrHdqzIUrrfJmxszE3OkfNO+oOh/1pdhunJy2hwtxkg5hvKjaWq708Srkl7SZvamZ+ZZV7GECuZ2xcT5UCcRQqiYlR6iJZAN7LlvsW6EXmCOtRIDoismMSav90IeQvPTrXxFLWc+4kMPlzylMOT7JlHiM4s89n51qKUpASr54X9ZgVrE+hIm6+VyKdEBY6zeE/jGKG54+7RAKpvw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=eFrATFgoRJ6d7ziVWdmSYdnPpEDIZasMI6cQcXBIx4o=;
 b=a4Md77JYkJk3gAFLISq0ArsCsviQXa6q1QgekP8VEum32pAsqRMeYVBHJNCC46193s23uCTZe2HlG/3CPlgSI5zv0WD2c1JMZ5WVcKCgCLQ71nfZQRhIxrRGsYrcMp3Bm19vKjrY4UXMyykQAmhlbWvzSrweii2QLFIq2vNtfTF51ELpKQ8t4wrZeyJWyOUPGKEdm41kUqRQrVy+I07dKdv8wzVED9Jozpgkw96QxhvABAVkwH2j4lQCSwkkWTah27TShEyD5OfVciW6iVGIrzIDF6n2ky+P3IzvGWduEM03efNDG8o0kfnXNzkj7WjIdV0neL8j8vw/BjCm0NxLwA==
From: Mykyta Poturai <Mykyta_Poturai@epam.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
CC: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@epam.com>, Stefano
 Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand
 Marquis <bertrand.marquis@arm.com>, Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>, Volodymyr Babchuk
	<Volodymyr_Babchuk@epam.com>, Mykyta Poturai <Mykyta_Poturai@epam.com>
Subject: [PATCH v3 2/2] xen/arm: platform: Add support for R-Car Gen4
Thread-Topic: [PATCH v3 2/2] xen/arm: platform: Add support for R-Car Gen4
Thread-Index: AQHbZy7k98WxcNwle0+yx5zuTI6nBw==
Date: Wed, 15 Jan 2025 09:21:43 +0000
Message-ID:
 <c09059f745c33b1f10f0d1b6cb790a50b1126392.1736931052.git.mykyta_poturai@epam.com>
References: <cover.1736931052.git.mykyta_poturai@epam.com>
In-Reply-To: <cover.1736931052.git.mykyta_poturai@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB10102:EE_|DBBPR03MB6795:EE_
x-ms-office365-filtering-correlation-id: bfd9ba29-8dc3-4963-73ca-08dd35460728
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?kDMEFbZCFZaEHvJJ9jpECctJXAxFOFJReT12kZ8k4X/BuO25Yhac7Kyk3N?=
 =?iso-8859-1?Q?GgecFmsfDDLIz6+y0mJjiEp3Uy8wP28m87bFoR7Wt6P8qWLDTbItIsNumF?=
 =?iso-8859-1?Q?3PiyvLiQpZfVNaf3RKe+pTbxcPjsQHEzpR3rLMkV1KPo+4mUlMDTiBI7XK?=
 =?iso-8859-1?Q?6HAlsyK9+w/qImNfpsiG1mZ3vtphfk1uzEigC5Ey9vBBlRQO4gE+jTNFkt?=
 =?iso-8859-1?Q?qvHTOu5j2xYFJl2BQ7KEwSLI7tuoVyh0iqxuSTzIHYXjx8+Z8HTnMrjso6?=
 =?iso-8859-1?Q?UasYhWIZEhXbuxdpH2k1fQ1Mm1U6U9WFTjw720dExh5SCGvyQ5wQnYVnYG?=
 =?iso-8859-1?Q?D21ofsA2Uqi/C46Onhk3hwivR00WepO6C4CS8OPaBKqJDyrc+eb3bEflbs?=
 =?iso-8859-1?Q?VFUXy3DRuX84kXRxo6uV7tgKyv5V4mtyywQk0QCAsQGfwhEuli3N+1F4XO?=
 =?iso-8859-1?Q?vN04O7UDigRhaptf1wNFi50mphF2ySWtlg5sx+GYtzxBE8BlQVAlvpfEi3?=
 =?iso-8859-1?Q?ajXcTlLMj4XllY72VCQwsJ4AURdarwz8ZAecbAjeX4OnGvIwyi2WI1tyBg?=
 =?iso-8859-1?Q?Spxk2G1udSF2lARKzPvrKoviCqRuDBZz7uQURV+R7laVITI1rDpF8rc4O+?=
 =?iso-8859-1?Q?2f8s5li9CmKDnJXoGz4oMpesklMbIZfZWVqQyv6qhmFfipTgPDeC+xMMaM?=
 =?iso-8859-1?Q?WrW4gz4mpNkAERMcNc5yMXwqvUpXbPtFodBXdyxDVwiUPk2Fj8Z93PV/lN?=
 =?iso-8859-1?Q?GQB4FhYYZcqNci2d0u3lU643Og4/A0Dw3i6gPkIE13ALgHt+KQ3V8QDBWC?=
 =?iso-8859-1?Q?hDafspIy4mPBJNSwCu74wGCwAqWXZMpWu19Qn20gxvEa+crwH605jkUktc?=
 =?iso-8859-1?Q?Z6hF2OmhSIKiOrVshvQk9rgKpdEPNWURtj/xoQpv4kUbbQa1vUvFOxPTo0?=
 =?iso-8859-1?Q?mZ834ZXfFbDieSeCx2ucihgfdMD7BNUrQ11XYrO3S0c2RXHF89M3G2pcov?=
 =?iso-8859-1?Q?HSQjXxv07+sWUEwEaU0/uWS9CkRRcWyeOaJUUDUXwqvoA0Wh4JEWvZrp0Z?=
 =?iso-8859-1?Q?HPpuuor4n2tdaFGD3HwVuz59GnLeEhXzG41tunDglj7kKQ/dOllMpkNSS4?=
 =?iso-8859-1?Q?qRYPmyetetqEsn35JUQ4ap7OjaJZ/BXcWr0QniPz6IVEWelP0ayFsFSfTO?=
 =?iso-8859-1?Q?hZZroiTIapDM6mEO6opIEzKWz789xFwz3j9tvKzBEnlCZQO5vrWIO7bef0?=
 =?iso-8859-1?Q?KdYI56PJ/8IzW1bAPk68oFB+4DmJ2w3+xZRGQ7cjF6b+i6WhIhy3bD2oiW?=
 =?iso-8859-1?Q?2Cg3Sy/DxAHkOXGg/LD6SyHtb/VAOU2Zg2D19IGsAxpcoIFE4V8b1On/8O?=
 =?iso-8859-1?Q?bfkXGNE8dTQuvl6HuCkLGibZn+njHj8LLv5nv3eihhEtyPwi1yRLFv0eAK?=
 =?iso-8859-1?Q?oLhypUmMKAzHuapJuXzemG3/nQtTWAmaWbp9BX99O7HwyrC5m1ti+gSxBM?=
 =?iso-8859-1?Q?lH/zQL1MVPX/RsBIGyGw+C?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB10102.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?0WKYk7reOnB9XnzDolECMk8r9zw0OFW6Tth3nY6MOMB7ANo+d9yjduMWIr?=
 =?iso-8859-1?Q?eIWQRRCF6cr6YiO1YEY8qs8oUwW4IoEm2EG5SalAollhyD1TUpUWUcNYYO?=
 =?iso-8859-1?Q?v/7V/Z+t2nYsLWv1cpiN6EpDrhjZPKEXkNSjJNOnGmjgh3ege8QXw7s1Ay?=
 =?iso-8859-1?Q?Obr/1eF5vYoSj9iJRlmLXaMR98jlGlL5+Yoyl66gxeRXayNcXOJL5yoprX?=
 =?iso-8859-1?Q?t2sfWUuVhz8fa+5VEWpBACNwLtyxf8JgaJUdtPZA9afKgb09wj7lew2xbS?=
 =?iso-8859-1?Q?4HwrgYWwe05mlDtsG15MJN3vyyAiK1YcaSA1ckJ1U4M9q9a5DlXDxIfQ5a?=
 =?iso-8859-1?Q?6VCxR8Pok1hBt7hgYzdyKFS3DuYICrV6uRWDszQW0MUKgN3R3grXP2TeL/?=
 =?iso-8859-1?Q?gjHJMi/OQgigjpRs/k4ab2FuBTZ2HxKDn91v0hfvtEK8Vi7hYAwurQN+Na?=
 =?iso-8859-1?Q?Vm6vRu89tq1vMHDz9EK1e6982lwk8bbF3Yb6gjOW07MaNjuNR51KRWi5yt?=
 =?iso-8859-1?Q?yeHBa80Am/eCO134G8WlrxGZBwnQChbXtu45V/njX3vfZtnmNM3cpxut5s?=
 =?iso-8859-1?Q?JjoozfgIfLlXkm8Aq2MhsCszKRHtDfCUu1i62AT83h1+jHEJ6xojrC293b?=
 =?iso-8859-1?Q?zdYwK4GoTRIW+64pjAMQu6rRCgUYENGp8NTgW49vFr72IXYaITcWBPUpoo?=
 =?iso-8859-1?Q?eHMhB+5XmfjcQX8yKgaJbyogAZ2bPkNkkg4qV8Ta6IKll9aVgJhJw8dm7K?=
 =?iso-8859-1?Q?8IdNJr503yHe/a9sUBHI+pXi7XPVVnv91Sq1E5RUzoE83LNyDjJxkuNt9N?=
 =?iso-8859-1?Q?4TgN6yIhZD+TgXZm2HELb+1Jb1pfuHm8omIDB7YcIpKngEhfmSVPLMU8Jw?=
 =?iso-8859-1?Q?V5zwFxv5r1y9UwBh4yZps/JrjR+R+VG2OkrqB7C0vQxs8FIAlY7s6bQdjz?=
 =?iso-8859-1?Q?NQLU3q4QXcCFgLycb7HYPLnf6m7lzZmuLTS92TcokcfplcTX5Zod7D3mfI?=
 =?iso-8859-1?Q?rriPRK9b2qdn1EXO7pkaFUJCVuGKqhRybBIAuQWQ40rh9AcJSV8y8duCc6?=
 =?iso-8859-1?Q?ZshjsfIjjiml+lMUEiPqqpDFPavKGbgW9AOgRJoU9P9K0D2mqxlOvVujMa?=
 =?iso-8859-1?Q?OIzDGpbw/jWYXEP2Np4vpol20kiNBXRwvGnJWS7gfk2FMZa5Nzhk4NxgyM?=
 =?iso-8859-1?Q?JkwSz+GVeSVsR+L9AOITSMVQ17ybznmtz0/sa40TSXOVVl625ofGRayHOC?=
 =?iso-8859-1?Q?msb+ha5VbY81YLWfkZe/f10Sn0N+aOBu68fD/M0+zsnBjJKWudLvFYFIxr?=
 =?iso-8859-1?Q?54IGYQInc3iVQ63GsFHW8S9ijmdlvOj68QcW6vxIbqjEtKabxzKEUSAGlD?=
 =?iso-8859-1?Q?fqiV8x+N0sH86TbAQC3Su7J6GZmyafA65IR3gNBm7b7L7cfvw78s7ziBBt?=
 =?iso-8859-1?Q?ifAjwsMr+/XDuWQuEhFTmrZmdM0FEVJ7o9zBNKmuvnLpg6hRumuyt5zEwD?=
 =?iso-8859-1?Q?2Z/f0AkgYvYe8GhgwRja+iua9Qq+s1SLH4Hiww+velvBeD0ArsJDBa6iNu?=
 =?iso-8859-1?Q?aD/bNZ8r/iv7xY03YKFOOLXNrdbSrsG6vPvz8m+3UdQcE3tAObdqr27KkG?=
 =?iso-8859-1?Q?N80X85Hx93sN5KV71xIbwaFqQ+03c6TraDX6ZtvTwBlpycb3jI4ndzJA?=
 =?iso-8859-1?Q?=3D=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PAVPR03MB10102.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: bfd9ba29-8dc3-4963-73ca-08dd35460728
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2025 09:21:44.0040
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: NvNJHuS3oYckyXUhF82nt2Zf5CVB/NyzqGkoBYYPu+/bN7F486AE+99yjF+MztAVdGo0hKqoWcfN3qHxbMHGMA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR03MB6795

From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>

Add Rcar Gen4 platform choice to Kconfig to select all required
drivers automatically.

Changelog:
v1 -> v2:
- Added RB from Stefano Stabellini

Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
---
 xen/arch/arm/platforms/Kconfig | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kconfi=
g
index 02322c259c..8785c168bd 100644
--- a/xen/arch/arm/platforms/Kconfig
+++ b/xen/arch/arm/platforms/Kconfig
@@ -29,6 +29,15 @@ config RCAR3
 	help
 	Enable all the required drivers for Renesas RCar3
=20
+config RCAR4
+	bool "Renesas RCar4 support"
+	depends on ARM_64
+	select HAS_SCIF
+	select HAS_ITS
+	select IPMMU_VMSA
+	help
+	Enable all the required drivers for Renesas RCar4
+
 config MPSOC
 	bool "Xilinx Ultrascale+ MPSoC support"
 	depends on ARM_64
@@ -55,4 +64,3 @@ config ALL32_PLAT
 config MPSOC_PLATFORM
 	bool
 	default (ALL64_PLAT || MPSOC)
-
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 09:21:57 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 09:21:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872257.1283230 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXzaw-0003mr-4p; Wed, 15 Jan 2025 09:21:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872257.1283230; Wed, 15 Jan 2025 09:21:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXzaw-0003mk-1B; Wed, 15 Jan 2025 09:21:50 +0000
Received: by outflank-mailman (input) for mailman id 872257;
 Wed, 15 Jan 2025 09:21: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
 <SRS0=kbvD=UH=epam.com=Mykyta_Poturai@srs-se1.protection.inumbo.net>)
 id 1tXzau-0003Ki-DE
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 09:21:48 +0000
Received: from DUZPR83CU001.outbound.protection.outlook.com
 (mail-northeuropeazlp170130004.outbound.protection.outlook.com
 [2a01:111:f403:c200::4])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 24b53aca-d322-11ef-a0e1-8be0dac302b0;
 Wed, 15 Jan 2025 10:21:47 +0100 (CET)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by DBBPR03MB6795.eurprd03.prod.outlook.com
 (2603:10a6:10:208::19) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8356.12; Wed, 15 Jan
 2025 09:21:43 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971%5]) with mapi id 15.20.8335.017; Wed, 15 Jan 2025
 09:21:43 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 24b53aca-d322-11ef-a0e1-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=iWzviWzG+wdPPdJZsdtIlik8R9N5TZX1rV3/DkR3bnV9cZKB0/dYKHGF3fkuQT3Y8b3GsgCXSAoJorC8j266V58fsq5sR7dStIDdivmB/o+TWhRoKTRvbeJgEyXYkmfWqBRrc0HUTjYjJc4hFZKYx/dTKh5145cluBYziQoFKjycmu8GUiE4AUN5N68QxPX5pa4L00ZV0FAr/8qhApcjzYIMasnfKGeh5K25ZJSGeO2h6nsEcdgW1GAdM/dRFU3OlSexXJ6lviuZC6Hc4diAoWFFLITYiNFUnQGgQyu6UTAgF9HIr7VD8gJPW9lpuYHg5T1xsrNffhGkhNilQs7foA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=wKsl8GcaXqAmsTB43yLP50Hu8RNut9fYbLp+jWITYjE=;
 b=L4Ik0Yd5/GnbUsCxzA1cl/0sjMoZq37rlTtgp2TeGIEPuk7eR47kzu7HFV6MoboyQ3oDCTAZKK0dvO2+5ONiuMoe4hiaSn1bZFt7vM3r6gZwVE0YtJMnMFjhYJWc0hMdJOjhhVvdlNGR0Tjlp01fZQsIWS9V/MmnJYW9PPKYxQkGrfY86MD9ji3NL4ag516PwcCEWSTMaUZiyYmb4zruDHA/KPXQuPp20KP7TToQU69uMRKKVqlIUWStvRWz3MU7ma9R3B7oEe3exPncd4An0Hek7uHWH9LVYa8/HIE4EflYJDl7/5c5A2jvyRBJFIjmlEuYF5VoNV79BnqkGLwFKA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=wKsl8GcaXqAmsTB43yLP50Hu8RNut9fYbLp+jWITYjE=;
 b=Mv1+Cwmyto61WUSAleAvM8rDqvB9vg4r6wqrjnYYQRZbw4EOKXlqgFIHRUCtWYARjb/HFa/GiAdK2uMfXEAGhNvm9NFdNIVfU5NTfhlLDII2SOzu2M2Pr/RKhyt6a8NqNqkcAuhlKrIge8RU+PCj9lp0Ly69087MHz6PkgiS8KgGltNOGkOhtMS8hdjRpSYNUzd2rNW3PyJS/289/T1iMZx2wIkLIcj0CDrFQKprjUJ9c3ZLIdE3+p9YfrAC9dvN6IlGCJj0kV63sXjIi4lbvHHCyDRPNV1mCWjqzlj+hWLMGJK1h+5wEkEyfSsfWQKwpSMgCpdJkpfWlh/kAVA/fw==
From: Mykyta Poturai <Mykyta_Poturai@epam.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
CC: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@epam.com>, Stefano
 Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand
 Marquis <bertrand.marquis@arm.com>, Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>, Mykyta Poturai
	<Mykyta_Poturai@epam.com>
Subject: [PATCH v3 1/2] ARM: ITS: implement quirks and add support for Renesas
 Gen4 ITS
Thread-Topic: [PATCH v3 1/2] ARM: ITS: implement quirks and add support for
 Renesas Gen4 ITS
Thread-Index: AQHbZy7kqk67VXALTEqusTd56sWExg==
Date: Wed, 15 Jan 2025 09:21:43 +0000
Message-ID:
 <f165108869cc485ff45fbe870005040c23e83b6c.1736931052.git.mykyta_poturai@epam.com>
References: <cover.1736931052.git.mykyta_poturai@epam.com>
In-Reply-To: <cover.1736931052.git.mykyta_poturai@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB10102:EE_|DBBPR03MB6795:EE_
x-ms-office365-filtering-correlation-id: 1224ea3a-acf0-41c5-f229-08dd354606ee
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?HbgOEWomBsVMblGomYzUQN9mpmgnEV633AyiOW1O8uqR9DfAJP5O9huIxz?=
 =?iso-8859-1?Q?OOT1OfgIMLkKC2QEDkHrileXrdoxVIpqoa/na/qD74BM11dlHk8bVd2d2R?=
 =?iso-8859-1?Q?fmdf6YWXh0jZu6GPGiV77my/eUEZJx1anBNQQQB8g3Ng7cdDq/BjuUpC01?=
 =?iso-8859-1?Q?mdTsbdT45DWRmG8sXEkqz6lCMZPIsMyE6VqV6mD5oxfu/vUiflibo7JPwZ?=
 =?iso-8859-1?Q?I0reefUe3vbacDG89EJWAspHetzs1q2GXrlSFObuyw7IE+174IHuOtyye8?=
 =?iso-8859-1?Q?r9r8Y0H6RJKBOqM17gy6HBbEkdfv5xT5oNfuvvOubpIY/VHRJeMInjPTSg?=
 =?iso-8859-1?Q?MhcGgl1+bX7WWG5u1PG51wLQPqlZTGfLwd+fSa4O2tRnGcfxZJXKkwcw1u?=
 =?iso-8859-1?Q?5rXpnNzaMUFw7JS0LtYIFhwclClYkmnABzO4eykQWPKTNKL4QnuFa5OHmG?=
 =?iso-8859-1?Q?XQyM9Zlhk6hwdbVe3oUklRqpya6Dbtv6pNd1jGkwH4oGSA3vlgLlJ+GbYd?=
 =?iso-8859-1?Q?xmgY4yK64ZoFdlKnfqSAVk7YeZV3ICC95b4xGTUlxl2biWYPVHaQqZaQV7?=
 =?iso-8859-1?Q?unsx07Tb0fE/HJoU6urVITnoudYQ+cjYPjvbvv6aiOxAmmHlxgz7NoHXV3?=
 =?iso-8859-1?Q?lozKtdbzYRJIaqQDpoxcGk11UJ/t9NJiLu6d3HfhQjvW5VBKX+HUtivck2?=
 =?iso-8859-1?Q?ut8oTfip91I+e4K2jlnNGwspT2AmbUeOOCJaRXG8OZSIISJx4U2TWc5Aqa?=
 =?iso-8859-1?Q?1GMBxhkDtBjeBqnlZizHGUmbzDqRiTyNToFUBOuqUcGfFUYmnlvM8CdBST?=
 =?iso-8859-1?Q?C+DwmT1FGdo7fOqjMn/+1S3ppO5OEHi2AXxLi+Q52yI2WNH8EUvUpE+/oH?=
 =?iso-8859-1?Q?0SWdldS4JhfP08pROq64LI6IISV4GIyVm41C6s9rsgFSv7vsKksBaT9+Xj?=
 =?iso-8859-1?Q?Q3F85P+HMCTRuYIgUVYVb2f1l5qfEOxMjViWaew23gRE5RbdIA9TuWihiG?=
 =?iso-8859-1?Q?YYO7wlNz12uNZCoR4q0ePO23UCDa0g+BYaTa0rwLVnsWdON1KjbwE2lZgw?=
 =?iso-8859-1?Q?15Brwi9YbGIIdpcnUoOE9U+WEK9KSiw5JIOxM0gSyHNI0xd0/xi1oI/Bvg?=
 =?iso-8859-1?Q?UpPhwfz0i0ssJl6FvpQUXcuIflvRvfhI9gXlo07elS//WdEkd1ATC1FSoh?=
 =?iso-8859-1?Q?EA0qY2kUZj2uWCnjI18zqv2l+ZjUArEyC/fmCj0vmrNYQA3kbKS8DFyLUh?=
 =?iso-8859-1?Q?s+8T2WpKbn5rGHbGXckx99beafl5m1Jmwjh3o1J3GCrEOVwEChVayKaD04?=
 =?iso-8859-1?Q?lhcHqk9jST2MGv4mQS+5IDNH/W2XytDyUTIbZE+AHX3RklpjN6S7IA0tU7?=
 =?iso-8859-1?Q?GEmec4CWdK8JP/Wm72wjZ77/8MwbiYiG2bTFKRKS6aNtzFT0FHtJUGLsbU?=
 =?iso-8859-1?Q?H6jB9AhrUb2mxlrB?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB10102.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?QrYtzkbOaeJ2DpFy2888KO17nrDD3n64CvsklMem0WWJuVWzO8LWJBhW5y?=
 =?iso-8859-1?Q?gQOLcCXgEEWKok1bd9MFEyxVre2ZBSq2gLOCDcWoJD484TPtT7BkASMOKZ?=
 =?iso-8859-1?Q?pDLjFP6LT+9kBd2ntp5yane1m2EB9nfpbqXcx2y8UGcYLtaEEgApy5K5kf?=
 =?iso-8859-1?Q?F0brdWuLxby7rt5NPbDLTtDHa30EWvu/xjO0bFy1mOX/hEAycQZ2DYNoaZ?=
 =?iso-8859-1?Q?5ahShhaKa1942pZL4Dg9ebFg6tGNWTIDULXNSRN/X6dP54x3JoEQ66KSc0?=
 =?iso-8859-1?Q?k1+dNnSHONvWkS87WeRHsG4B5a9lp3InM+1jk7ZiUK65RiMCuOfZsyIVAe?=
 =?iso-8859-1?Q?eAZoXz5ioljiUGNbAqGfly2h04Lrq9oiyDDyy7a5/1dePdShVthbkZIdSn?=
 =?iso-8859-1?Q?er1LG2VZ13iipO0z41TP6LGk70HwRJvKW8FXh3S7QdwSqDvwHZ68dN9cUr?=
 =?iso-8859-1?Q?Q1ct4H90NZ6Pb3jAu0YUeObCi4C50atPZ6kPwyzbOUGfZWrxd9jUmAm31W?=
 =?iso-8859-1?Q?lwhXj006WaZXHfyfU2/5UYL2oT+tyD/jNvZfutUGxatJuHDv1rBfcV9njh?=
 =?iso-8859-1?Q?ZcWX8AtkQycMZ0i2r6ufJA7zmkeOjov2WBdXuoqPXQe6X/ee01Uv2tRJ7O?=
 =?iso-8859-1?Q?AELWbNyVznbwstj7OJP3archzimbSRi04cDEKA64sHADEz2xJz+T+BQLgv?=
 =?iso-8859-1?Q?+RI0ZJWpmNny8Lelo9vRnTAvxiPWAwAYMeGzTGbGf730H87hFEKc6BD+I7?=
 =?iso-8859-1?Q?Lp8/T8rK5MBOb7WdoBAu5XXgHqJVi22Ll2EHakmWBb3vymhJeGyYIRw375?=
 =?iso-8859-1?Q?8f1XymKs1N6MYDIsNuA6iAEUVteQHclNPF7sfPZK2cJtcqKfE4HU/BBa4G?=
 =?iso-8859-1?Q?lQIOSYkofEjLTVDpsrHRiBtG8dk4cMDWK7HPqv45qFEk7qjdLRFoHjIYXS?=
 =?iso-8859-1?Q?rcVHso4Q3Tdwppj7g2ZZFaQZMwfsvK7JSHZ04hiWwVIEqrr70BNjkhc2mO?=
 =?iso-8859-1?Q?iNwiMWgxarzRUwhZSnKL0ziIYosio0rC0OPim0UC5Y96hbTzorKbuc+O5J?=
 =?iso-8859-1?Q?AIUwpoatz/K3vQhWcPctngQ0E2zwudvzGdf/56y3jJw+LdwxGudJexYbQ3?=
 =?iso-8859-1?Q?y8JOaXIeXb0WG0iuRRHE+7O+REqx/avaD9d7fFjrPHB81FS3JkhyoGAZOb?=
 =?iso-8859-1?Q?qZiP6UTiyxUvj/Tu0FATOV4wKmOBnoV7gQwGuVG1+b9NtpsC/7JJlw7UBD?=
 =?iso-8859-1?Q?xzYUOholFbeseaCkX0eINkPa3Bz33+viUxAESF1AxcJUGUeJk0HY5JO7WR?=
 =?iso-8859-1?Q?w0YQRGGgwfyxu/tnSk0+nmcXfmCZVJl8kK6s6OmSkp7v+AeH+HQ2Ox/Jqp?=
 =?iso-8859-1?Q?9KFvXlXeAdhUvc++RvSAdQMUQditdk2OqrPc26oBhFQTJyuniQQ83zBHYV?=
 =?iso-8859-1?Q?Ddam5KMyIDaLFrKFzSlTiB692AwTnYXI2d1nELNUAAIhCGasoKJJoQNl4A?=
 =?iso-8859-1?Q?PvGBU24bK9zKrWGnVF2P5CFlPgofcEOizOUd95S+z4KngWWOFHtb5WNvOn?=
 =?iso-8859-1?Q?7OvJ52SRAZmfxklG8x6sXGonv8VTXXv4g53t6HslfES8SfmYLTjfMaespS?=
 =?iso-8859-1?Q?ImVJl5M1WoLnX4NTarXjGa3hxDIErxwgGqA30WC7xrI0oR/IEc8ljVpg?=
 =?iso-8859-1?Q?=3D=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PAVPR03MB10102.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1224ea3a-acf0-41c5-f229-08dd354606ee
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2025 09:21:43.6250
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: q2hCCpJITGd90GKrR0UV5sRy3T0t2+19nuXSMQF0giCwTqgvhAvJnlBNexSNkIBNFFO0lprElGTGqKOaNkSZYg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR03MB6795

From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>

There are number of ITS implementations exist which are different from
the base one which have number of functionalities defined as is
"IMPLEMENTATION DEFINED", e.g. there may exist differences in cacheability,
shareability and memory requirements and others. This requires
appropriate handling of such HW requirements which are implemented as
ITS quirks: GITS_IIDR (ITS Implementer Identification Register) is used to
differentiate the ITS implementations and select appropriate set of
quirks if any.

As an example of such ITSes add quirk implementation for Renesas Gen4 ITS:
- add possibility to override default cacheability and shareability
settings used for ITS memory allocations;
- change relevant memory allocations to alloc_xenheap_pages which allows
to specify memory access flags, free_xenheap_pages is used to free;
- add quirks validation to ensure that all ITSes share the same quirks
in case of multiple ITSes are present in the system;

The Gen4 ITS memory requirements are not covered in any errata as of yet,
but observed behavior suggests that they are indeed required.

The idea of the quirk implementation is inspired by the Linux kernel ITS
quirk implementation [1].

Changelog:
v2 -> v3:
- added missing memset;
v1 -> v2:
- switched to using alloc_xenheap_pages/free_xenheap_pages for ITS memory
allocations;
- updated declaration of its_quirk_flags;
- added quirks validation to ensure that all ITSes share the same quirks;
- removed unnecessary vITS changes;


Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>

[1] https://elixir.bootlin.com/linux/v5.16.1/source/drivers/irqchip/irq-gic=
-v3-its.c
---
 xen/arch/arm/gic-v3-its.c             | 141 +++++++++++++++++++++++---
 xen/arch/arm/gic-v3-lpi.c             |  23 +++--
 xen/arch/arm/include/asm/gic_v3_its.h |   8 ++
 3 files changed, 152 insertions(+), 20 deletions(-)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 5fd83af25a..34833166ad 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -42,6 +42,7 @@ struct its_device {
     struct rb_node rbnode;
     struct host_its *hw_its;
     void *itt_addr;
+    unsigned int itt_order;
     paddr_t guest_doorbell;             /* Identifies the virtual ITS */
     uint32_t host_devid;
     uint32_t guest_devid;
@@ -50,6 +51,104 @@ struct its_device {
     struct pending_irq *pend_irqs;      /* One struct per event */
 };
=20
+/*
+ * It is unlikely that a platform implements ITSes with different quirks,
+ * so assume they all share the same.
+ */
+struct its_quirk {
+    const char *desc;
+    bool (*init)(struct host_its *hw_its);
+    uint32_t iidr;
+    uint32_t mask;
+};
+
+static uint32_t __ro_after_init its_quirk_flags;
+
+static bool gicv3_its_enable_quirk_gen4(struct host_its *hw_its)
+{
+    its_quirk_flags |=3D HOST_ITS_WORKAROUND_NC_NS |
+        HOST_ITS_WORKAROUND_32BIT_ADDR;
+
+    return true;
+}
+
+static const struct its_quirk its_quirks[] =3D {
+    {
+        .desc	=3D "R-Car Gen4",
+        .iidr	=3D 0x0201743b,
+        .mask	=3D 0xffffffff,
+        .init	=3D gicv3_its_enable_quirk_gen4,
+    },
+    {
+        /* Sentinel. */
+    }
+};
+
+static struct its_quirk* gicv3_its_find_quirk(uint32_t iidr)
+{
+    const struct its_quirk *quirks =3D its_quirks;
+
+    for ( ; quirks->desc; quirks++ )
+    {
+        if ( quirks->iidr =3D=3D (quirks->mask & iidr) )
+            return (struct its_quirk *)quirks;
+    }
+
+    return NULL;
+}
+
+static void gicv3_its_enable_quirks(struct host_its *hw_its)
+{
+    uint32_t iidr =3D readl_relaxed(hw_its->its_base + GITS_IIDR);
+    const struct its_quirk *quirk =3D gicv3_its_find_quirk(iidr);
+
+    if ( quirk && quirk->init(hw_its) )
+        printk("GICv3: enabling workaround for ITS: %s\n", quirk->desc);
+}
+
+static void gicv3_its_validate_quirks(void)
+{
+    const struct its_quirk *quirk =3D NULL, *prev =3D NULL;
+    const struct host_its *hw_its;
+
+    if ( list_empty(&host_its_list) )
+        return;
+
+    hw_its =3D list_first_entry(&host_its_list, struct host_its, entry);
+    prev =3D gicv3_its_find_quirk(readl_relaxed(hw_its->its_base + GITS_II=
DR));
+
+    list_for_each_entry(hw_its, &host_its_list, entry)
+    {
+        quirk =3D gicv3_its_find_quirk(readl_relaxed(hw_its->its_base + GI=
TS_IIDR));
+        BUG_ON(quirk !=3D prev);
+        prev =3D quirk;
+    }
+}
+
+uint64_t gicv3_its_get_cacheability(void)
+{
+    if ( its_quirk_flags & HOST_ITS_WORKAROUND_NC_NS )
+        return GIC_BASER_CACHE_nC;
+
+    return GIC_BASER_CACHE_RaWaWb;
+}
+
+uint64_t gicv3_its_get_shareability(void)
+{
+    if ( its_quirk_flags & HOST_ITS_WORKAROUND_NC_NS )
+        return GIC_BASER_NonShareable;
+
+    return GIC_BASER_InnerShareable;
+}
+
+unsigned int gicv3_its_get_memflags(void)
+{
+    if ( its_quirk_flags & HOST_ITS_WORKAROUND_32BIT_ADDR )
+        return MEMF_bits(32);
+
+    return 0;
+}
+
 bool gicv3_its_host_has_its(void)
 {
     return !list_empty(&host_its_list);
@@ -289,19 +388,23 @@ static void *its_map_cbaser(struct host_its *its)
 {
     void __iomem *cbasereg =3D its->its_base + GITS_CBASER;
     uint64_t reg;
+    unsigned int order;
     void *buffer;
=20
-    reg  =3D GIC_BASER_InnerShareable << GITS_BASER_SHAREABILITY_SHIFT;
+    reg  =3D gicv3_its_get_shareability() << GITS_BASER_SHAREABILITY_SHIFT=
;
     reg |=3D GIC_BASER_CACHE_SameAsInner << GITS_BASER_OUTER_CACHEABILITY_=
SHIFT;
-    reg |=3D GIC_BASER_CACHE_RaWaWb << GITS_BASER_INNER_CACHEABILITY_SHIFT=
;
+    reg |=3D gicv3_its_get_cacheability() << GITS_BASER_INNER_CACHEABILITY=
_SHIFT;
=20
-    buffer =3D _xzalloc(ITS_CMD_QUEUE_SZ, SZ_64K);
+    order =3D get_order_from_bytes(max(ITS_CMD_QUEUE_SZ, SZ_64K));
+    buffer =3D alloc_xenheap_pages(order, gicv3_its_get_memflags());
     if ( !buffer )
         return NULL;
=20
+    memset(buffer, 0, PAGE_SIZE << order);
+
     if ( virt_to_maddr(buffer) & ~GENMASK(51, 12) )
     {
-        xfree(buffer);
+        free_xenheap_pages(buffer, order);
         return NULL;
     }
=20
@@ -340,11 +443,12 @@ static int its_map_baser(void __iomem *basereg, uint6=
4_t regc,
     unsigned int entry_size =3D GITS_BASER_ENTRY_SIZE(regc);
     unsigned int pagesz =3D 2;    /* try 64K pages first, then go down. */
     unsigned int table_size;
+    unsigned int order;
     void *buffer;
=20
-    attr  =3D GIC_BASER_InnerShareable << GITS_BASER_SHAREABILITY_SHIFT;
+    attr  =3D gicv3_its_get_shareability() << GITS_BASER_SHAREABILITY_SHIF=
T;
     attr |=3D GIC_BASER_CACHE_SameAsInner << GITS_BASER_OUTER_CACHEABILITY=
_SHIFT;
-    attr |=3D GIC_BASER_CACHE_RaWaWb << GITS_BASER_INNER_CACHEABILITY_SHIF=
T;
+    attr |=3D gicv3_its_get_cacheability() << GITS_BASER_INNER_CACHEABILIT=
Y_SHIFT;
=20
     /*
      * Setup the BASE register with the attributes that we like. Then read
@@ -357,13 +461,16 @@ retry:
     /* The BASE registers support at most 256 pages. */
     table_size =3D min(table_size, 256U << BASER_PAGE_BITS(pagesz));
=20
-    buffer =3D _xzalloc(table_size, BIT(BASER_PAGE_BITS(pagesz), UL));
+    order =3D get_order_from_bytes(max(table_size, BIT(BASER_PAGE_BITS(pag=
esz), U)));
+    buffer =3D alloc_xenheap_pages(order, gicv3_its_get_memflags());
     if ( !buffer )
         return -ENOMEM;
=20
+    memset(buffer, 0, PAGE_SIZE << order);
+
     if ( !check_baser_phys_addr(buffer, BASER_PAGE_BITS(pagesz)) )
     {
-        xfree(buffer);
+        free_xenheap_pages(buffer, order);
         return -ERANGE;
     }
=20
@@ -396,7 +503,7 @@ retry:
     if ( ((regc >> GITS_BASER_PAGE_SIZE_SHIFT) & 0x3UL) =3D=3D pagesz )
         return 0;
=20
-    xfree(buffer);
+    free_xenheap_pages(buffer, order);
=20
     if ( pagesz-- > 0 )
         goto retry;
@@ -453,6 +560,8 @@ static int gicv3_its_init_single_its(struct host_its *h=
w_its)
     if ( ret )
         return ret;
=20
+    gicv3_its_enable_quirks(hw_its);
+
     reg =3D readq_relaxed(hw_its->its_base + GITS_TYPER);
     hw_its->devid_bits =3D GITS_TYPER_DEVICE_ID_BITS(reg);
     hw_its->evid_bits =3D GITS_TYPER_EVENT_ID_BITS(reg);
@@ -530,7 +639,7 @@ static int remove_mapped_guest_device(struct its_device=
 *dev)
         printk(XENLOG_WARNING "Can't unmap host ITS device 0x%x\n",
                dev->host_devid);
=20
-    xfree(dev->itt_addr);
+    free_xenheap_pages(dev->itt_addr, dev->itt_order);
     xfree(dev->pend_irqs);
     xfree(dev->host_lpi_blocks);
     xfree(dev);
@@ -619,6 +728,7 @@ int gicv3_its_map_guest_device(struct domain *d,
     struct its_device *dev =3D NULL;
     struct rb_node **new =3D &d->arch.vgic.its_devices.rb_node, *parent =
=3D NULL;
     int i, ret =3D -ENOENT;      /* "i" must be signed to check for >=3D 0=
 below. */
+    unsigned int order;
=20
     hw_its =3D gicv3_its_find_by_doorbell(host_doorbell);
     if ( !hw_its )
@@ -681,10 +791,13 @@ int gicv3_its_map_guest_device(struct domain *d,
     ret =3D -ENOMEM;
=20
     /* An Interrupt Translation Table needs to be 256-byte aligned. */
-    itt_addr =3D _xzalloc(nr_events * hw_its->itte_size, 256);
+    order =3D get_order_from_bytes(max(nr_events * hw_its->itte_size, 256U=
L));
+    itt_addr =3D alloc_xenheap_pages(order, gicv3_its_get_memflags());
     if ( !itt_addr )
         goto out_unlock;
=20
+    memset(itt_addr, 0, PAGE_SIZE << order);
+
     clean_and_invalidate_dcache_va_range(itt_addr,
                                          nr_events * hw_its->itte_size);
=20
@@ -718,6 +831,7 @@ int gicv3_its_map_guest_device(struct domain *d,
         goto out_unlock;
=20
     dev->itt_addr =3D itt_addr;
+    dev->itt_order =3D order;
     dev->hw_its =3D hw_its;
     dev->guest_doorbell =3D guest_doorbell;
     dev->guest_devid =3D guest_devid;
@@ -775,7 +889,8 @@ out:
         xfree(dev->pend_irqs);
         xfree(dev->host_lpi_blocks);
     }
-    xfree(itt_addr);
+    if ( itt_addr )
+        free_xenheap_pages(itt_addr, order);
     xfree(dev);
=20
     return ret;
@@ -1089,6 +1204,8 @@ int gicv3_its_init(void)
             return ret;
     }
=20
+    gicv3_its_validate_quirks();
+
     return 0;
 }
=20
diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
index de4b0eb4a4..de5052e5cf 100644
--- a/xen/arch/arm/gic-v3-lpi.c
+++ b/xen/arch/arm/gic-v3-lpi.c
@@ -227,6 +227,7 @@ void gicv3_lpi_update_host_entry(uint32_t host_lpi, int=
 domain_id,
 static int gicv3_lpi_allocate_pendtable(unsigned int cpu)
 {
     void *pendtable;
+    unsigned int order;
=20
     if ( per_cpu(lpi_redist, cpu).pending_table )
         return -EBUSY;
@@ -237,14 +238,16 @@ static int gicv3_lpi_allocate_pendtable(unsigned int =
cpu)
      * The GICv3 imposes a 64KB alignment requirement, also requires
      * physically contiguous memory.
      */
-    pendtable =3D _xzalloc(lpi_data.max_host_lpi_ids / 8, SZ_64K);
+    order =3D get_order_from_bytes(max(lpi_data.max_host_lpi_ids / 8, (uns=
igned long)SZ_64K));
+    pendtable =3D alloc_xenheap_pages(order, gicv3_its_get_memflags());
     if ( !pendtable )
         return -ENOMEM;
=20
+    memset(pendtable, 0, PAGE_SIZE << order);
     /* Make sure the physical address can be encoded in the register. */
     if ( virt_to_maddr(pendtable) & ~GENMASK(51, 16) )
     {
-        xfree(pendtable);
+        free_xenheap_pages(pendtable, order);
         return -ERANGE;
     }
     clean_and_invalidate_dcache_va_range(pendtable,
@@ -272,9 +275,9 @@ static int gicv3_lpi_set_pendtable(void __iomem *rdist_=
base)
=20
     ASSERT(!(virt_to_maddr(pendtable) & ~GENMASK(51, 16)));
=20
-    val  =3D GIC_BASER_CACHE_RaWaWb << GICR_PENDBASER_INNER_CACHEABILITY_S=
HIFT;
+    val  =3D gicv3_its_get_cacheability() << GICR_PENDBASER_INNER_CACHEABI=
LITY_SHIFT;
     val |=3D GIC_BASER_CACHE_SameAsInner << GICR_PENDBASER_OUTER_CACHEABIL=
ITY_SHIFT;
-    val |=3D GIC_BASER_InnerShareable << GICR_PENDBASER_SHAREABILITY_SHIFT=
;
+    val |=3D gicv3_its_get_shareability() << GICR_PENDBASER_SHAREABILITY_S=
HIFT;
     val |=3D GICR_PENDBASER_PTZ;
     val |=3D virt_to_maddr(pendtable);
=20
@@ -300,10 +303,11 @@ static int gicv3_lpi_set_pendtable(void __iomem *rdis=
t_base)
 static int gicv3_lpi_set_proptable(void __iomem * rdist_base)
 {
     uint64_t reg;
+    unsigned int order;
=20
-    reg  =3D GIC_BASER_CACHE_RaWaWb << GICR_PROPBASER_INNER_CACHEABILITY_S=
HIFT;
+    reg  =3D gicv3_its_get_cacheability() << GICR_PROPBASER_INNER_CACHEABI=
LITY_SHIFT;
     reg |=3D GIC_BASER_CACHE_SameAsInner << GICR_PROPBASER_OUTER_CACHEABIL=
ITY_SHIFT;
-    reg |=3D GIC_BASER_InnerShareable << GICR_PROPBASER_SHAREABILITY_SHIFT=
;
+    reg |=3D gicv3_its_get_shareability() << GICR_PROPBASER_SHAREABILITY_S=
HIFT;
=20
     /*
      * The property table is shared across all redistributors, so allocate
@@ -312,7 +316,10 @@ static int gicv3_lpi_set_proptable(void __iomem * rdis=
t_base)
     if ( !lpi_data.lpi_property )
     {
         /* The property table holds one byte per LPI. */
-        void *table =3D _xmalloc(lpi_data.max_host_lpi_ids, SZ_4K);
+        void *table;
+
+        order =3D get_order_from_bytes(max(lpi_data.max_host_lpi_ids, (uns=
igned long)SZ_4K));
+        table =3D alloc_xenheap_pages(order, gicv3_its_get_memflags());
=20
         if ( !table )
             return -ENOMEM;
@@ -320,7 +327,7 @@ static int gicv3_lpi_set_proptable(void __iomem * rdist=
_base)
         /* Make sure the physical address can be encoded in the register. =
*/
         if ( (virt_to_maddr(table) & ~GENMASK(51, 12)) )
         {
-            xfree(table);
+            free_xenheap_pages(table, order);
             return -ERANGE;
         }
         memset(table, GIC_PRI_IRQ | LPI_PROP_RES1, MAX_NR_HOST_LPIS);
diff --git a/xen/arch/arm/include/asm/gic_v3_its.h b/xen/arch/arm/include/a=
sm/gic_v3_its.h
index c24d4752d0..0737e67aa6 100644
--- a/xen/arch/arm/include/asm/gic_v3_its.h
+++ b/xen/arch/arm/include/asm/gic_v3_its.h
@@ -110,6 +110,9 @@
 #define HOST_ITS_FLUSH_CMD_QUEUE        (1U << 0)
 #define HOST_ITS_USES_PTA               (1U << 1)
=20
+#define HOST_ITS_WORKAROUND_NC_NS       (1U << 0)
+#define HOST_ITS_WORKAROUND_32BIT_ADDR  (1U << 1)
+
 /* We allocate LPIs on the hosts in chunks of 32 to reduce handling overhe=
ad. */
 #define LPI_BLOCK                       32U
=20
@@ -197,6 +200,11 @@ struct pending_irq *gicv3_assign_guest_event(struct do=
main *d,
 void gicv3_lpi_update_host_entry(uint32_t host_lpi, int domain_id,
                                  uint32_t virt_lpi);
=20
+/* ITS quirks handling. */
+uint64_t gicv3_its_get_cacheability(void);
+uint64_t gicv3_its_get_shareability(void);
+unsigned int gicv3_its_get_memflags(void);
+
 #else
=20
 #ifdef CONFIG_ACPI
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 09:21:57 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 09:21:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872255.1283210 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXzau-0003L4-N9; Wed, 15 Jan 2025 09:21:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872255.1283210; Wed, 15 Jan 2025 09:21:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXzau-0003Kx-Jb; Wed, 15 Jan 2025 09:21:48 +0000
Received: by outflank-mailman (input) for mailman id 872255;
 Wed, 15 Jan 2025 09:21: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
 <SRS0=kbvD=UH=epam.com=Mykyta_Poturai@srs-se1.protection.inumbo.net>)
 id 1tXzat-0003Ki-Eq
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 09:21:47 +0000
Received: from DU2PR03CU002.outbound.protection.outlook.com
 (mail-northeuropeazlp170120003.outbound.protection.outlook.com
 [2a01:111:f403:c200::3])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 239256af-d322-11ef-a0e1-8be0dac302b0;
 Wed, 15 Jan 2025 10:21:45 +0100 (CET)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by DBBPR03MB6795.eurprd03.prod.outlook.com
 (2603:10a6:10:208::19) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8356.12; Wed, 15 Jan
 2025 09:21:43 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971%5]) with mapi id 15.20.8335.017; Wed, 15 Jan 2025
 09:21:43 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 239256af-d322-11ef-a0e1-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=AGLBaHj/qSdH/A9Evnyc9piWdqjr3roME8y6giycGP4wJ5jozdpUSI7z8BXFtH5grFlLoBkO4gta5e3CcarJrL9/G8yY9Eou8IcurnUrdD6VikFeHhwfItsSo6XPGx/dWYGs/4mif+pSLn177wLnxY65/A6jc/3kUa+PgT6yQdGopEqNNIJSUjCtqxLyrvKVU2TzhVbZrcmW0oOqDYexUAMvuHLc/NCB1zfb0wm2K2DYJ+rdrFkHB4/fT846ic0LbxBgvKGy2W6kgE7tAyKaVMoBk3xNkz3FokeMCeClhQowPaYy0GPp4Mw/wHKgel2IqlmMpcudF096MuEapA5H2A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=6Top9evq/WihGHQvxwO1jBz6G7LcEAMOiyT0Vi4ojDk=;
 b=LgOx8xd38JzrJiarpWuFjF+EcoYunU/x6Dfy6pXVBmbOhA4AjcMfMXUYxIZHTaaBiqCnAaQYlghYFDdkVQWVXQa+CCWIk30vzBOMe6HdrtpJZvyv7JCYgCWPsK8axaadgkvUFKL//P5IMK7a8M01UHBrGahskptCJZwXENg3AaHdb062Hs23SIWVTMYWkGf85lGyErmQ5b+gbgg2B0jB8MkuSHTXVMqaHgcxDTXeUwxcyUb527FJZTg+sfGpIjhOP0cJ9/CbIbfS7oL2mSu8xna6oZvrfms0SJcClILEbemW0+ri3w8m2d+VvEwa2fuUYoiwBiurCsoalrp1q+7Buw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=6Top9evq/WihGHQvxwO1jBz6G7LcEAMOiyT0Vi4ojDk=;
 b=XGboKKkymnE2Y/pHxwxRLvtjkuIGDMcml4bmRExV9VVFlk3xtNJdOblvb2ypbkfXOtS2M9mDFmui4zAwIackD2mR/dsbgksBM4hfCNpNIGIDxvnGB5WVuUrvbdAQwc5XkSh78caeH87au4+2LGhmC8ru7/98IgeDwRmlFTnwcGlKHMb+RYeRtnWLoZKMjGp+Feba5aA1ceLdAJtNk4oyl4XP8Iu6C0IpsnNt+5AqZsk313TLzOp68o1Jy8XjYok3LkDnM+5+iA69L63CQ7Lh59JZ+YMJPwwsEgcREISf5gbDC9oHz0Aq2XXskJfKBCl64Rt+45QnVShqpNw9uq7qPQ==
From: Mykyta Poturai <Mykyta_Poturai@epam.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
CC: Mykyta Poturai <Mykyta_Poturai@epam.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand Marquis
	<bertrand.marquis@arm.com>, Michal Orzel <michal.orzel@amd.com>, Volodymyr
 Babchuk <Volodymyr_Babchuk@epam.com>
Subject: [PATCH v3 0/2] Add support for Renesas R-Car Gen4
Thread-Topic: [PATCH v3 0/2] Add support for Renesas R-Car Gen4
Thread-Index: AQHbZy7kXq2K+/rUoEWFgqp6M1ngYA==
Date: Wed, 15 Jan 2025 09:21:43 +0000
Message-ID: <cover.1736931052.git.mykyta_poturai@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB10102:EE_|DBBPR03MB6795:EE_
x-ms-office365-filtering-correlation-id: 22c62564-d34e-4326-abd0-08dd354606a2
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?01dOzkZA/YHEKwhQg7zFSxe9OWnG5craFNXzYz26Noeuq3JqcxdGRv92F2?=
 =?iso-8859-1?Q?ztCUoQKwKZLA/ql6DDI+k9ubT2IQ6Kypqeu2Gjmv0gl1zKrWx8VtDe/3wR?=
 =?iso-8859-1?Q?5aw5sacdOuFbtjMQk5u7y9kNUdA0af4iH8WRxlTo/OtkAZTJhsrGPyinia?=
 =?iso-8859-1?Q?+m49QPX/hmuea2W5vYalg8CKa54DFD9ZVuCDQDSlEJ4cDlAdBQtEiTTZH0?=
 =?iso-8859-1?Q?ZnjbWbQXV5xJu71mpmvPjaSQY1KWL6R971EUwA/bHE5Et+vPqoPkZQwBtS?=
 =?iso-8859-1?Q?iIcKPmwI3dW8GJsfshv1mje57b7AcSVje9yDg/+0m775/kmr8zApgMN0n6?=
 =?iso-8859-1?Q?mxbrDw3uKeKdxPZKhp+QW+VdD7IH/iAeCYl0+AEaKy0f7h09eIAw8QKywV?=
 =?iso-8859-1?Q?d4JzufCUW5AtsksCSMW47SxvT2ZTHt9po9QBVAeXHChUx5imh4W6FVzSxa?=
 =?iso-8859-1?Q?UeyoCXO2kSi3giPtBrsDhPMtx3VdwikFfz35lG7DWv5+SfXSx+8JEsJnDA?=
 =?iso-8859-1?Q?blAPmRferbpwM33JgNybgRSyxAHJm7hiVxMh/p7ApG21iYYJONMD7z2uFV?=
 =?iso-8859-1?Q?OFfhgp/4O7gT/eaZxSmXEHJ54ugyUk9KDBEL4PkOSd1yQiZCrb1cJWi5Xg?=
 =?iso-8859-1?Q?E8MtsADAej+Re3F0gV294Ru8hVFloiy3bR5gKkm2MyDEvDOEMXO/5CZpYD?=
 =?iso-8859-1?Q?Ftj/z737TgyW7HNyxQljAbvB8PfL/tjTb04atZkPgTWjarYbbs+IVkCqJP?=
 =?iso-8859-1?Q?Fnsy1WyZlqEG2Co3s8zwRisIVPDv2FecconbDaw43i2qvzskyFIdqusvhN?=
 =?iso-8859-1?Q?D3rSgC5OCUnqLqdHANgeTHNnNzHU75FMLyYx791kRy6OMpfAPktRniFqRu?=
 =?iso-8859-1?Q?YPzYrWuEMX10u+lCf+4LyW9uiCI+TtyzmwmDhs668gYyNi9eINRqKtnrVi?=
 =?iso-8859-1?Q?WFABQyliNN7v0vSUDUS/IvvweD4XxC+aJVhMmMLMl8IZtLvG1SP0v54PXz?=
 =?iso-8859-1?Q?PFrCfi0BUaOmXgspeRm7Ci6G3Q4trP3X4pr2x56drUZU32OQe32hjG4AMN?=
 =?iso-8859-1?Q?6YMn+JHz/XkCFsY1su9wis4A2GNgFm0M/7xr3Rib12WkfRCZNBhhz00uud?=
 =?iso-8859-1?Q?ni0h0g7m2lqsiKG32+xibcpNoclHBfwrIOlPXzb8/MSExrUSeugDDJtFVM?=
 =?iso-8859-1?Q?5XO0rWxjUgmeqsNiYT4qaBGPnGSdPhXKa5cHnohy+WH9UF0Ip+WEoZdSG9?=
 =?iso-8859-1?Q?6pnhqXun4paxQwLq/Jtst/t22jN7xXZFlqp3gJWl675yjyU0A2bQmrf/JO?=
 =?iso-8859-1?Q?8cBDls8yPtu0w5tIUQ7nq7loonKrqRL3NISV/qAg+qKa//Z6GXdSxdzOKr?=
 =?iso-8859-1?Q?O757MC7uJrm0+GgAoazLFFU6wtfTcTr0fd8xMzMpLs+RQ4OYia9FCYwE85?=
 =?iso-8859-1?Q?0mg+YB+bb7+0q1JtUVn1PWfTVw6Kn3Ed4Uaevw=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB10102.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?u7hM/nKXg8WhGY79fzUwksM/RHDa6HcW2jIGepER29ous1/q1km93GlIJT?=
 =?iso-8859-1?Q?dee8IcXKMH4txc/sRck06CyL9+RApKvbv4CTMu184mLYNVJLhysz6MuxWq?=
 =?iso-8859-1?Q?B22X01WpAyDI7TuKprz+UmNZqkJ1VFb101yEwqKA/XExfcgZizZKoXCugT?=
 =?iso-8859-1?Q?DLO9b8jhUpYBKMkYtsBL1yt8/6su/HcGvVSs8xmk2a6b1DJlvoI/BstTZq?=
 =?iso-8859-1?Q?JjFR4t5x5i7l2omvmVw9B0NxNdawrhOfsuXogwHbXhlOqsRVIp7zLbTNu2?=
 =?iso-8859-1?Q?YpWjwd+6XuOa963qPH0zFaoO8jthGQboWjoKRzSFdrJTNv1w8M/7CG1JrN?=
 =?iso-8859-1?Q?bAOals2F3LKpmnux19mvnHLfq1MdOsCttJwtZ7gCp2Nv1KT/02833yzPIz?=
 =?iso-8859-1?Q?uqqsw1oJyvKoWhh6/XV6L4qkRo8MY/dV2+I6y7VOnVfZRLg++Ct3/gWkLe?=
 =?iso-8859-1?Q?80LFNcEBWJfwf44/1yyXO9GFtQRns8OatA2Tyn6TzEge19xmrOZ6+gzaPm?=
 =?iso-8859-1?Q?hKJNwebk1VQaD+ZMQanK/vNLeg0KpBUUNw2+UuIc0F64qhXt/MW3WEO+wN?=
 =?iso-8859-1?Q?l7u/ISvfSH//PhXYfggCeGaVfzS9679VJGmnwf0xPk6z9ZR1la/X/suBcS?=
 =?iso-8859-1?Q?90cuMw0s1ojKtGyNDJi1nR/P6smJz6rHrQstjiz3I9EMhXL7m21RgSNeqv?=
 =?iso-8859-1?Q?r16rl5vfExF5VWzHU24YmSlLY36yeqeoIt7X/ldt1mjfqenPtyufMkCPYG?=
 =?iso-8859-1?Q?1EO+wfM5ea5iMc3H7zkWyNLa24oJJb3YHJgIHEmnfA9QveWZ4gnFEFmbnH?=
 =?iso-8859-1?Q?HAxzE1LhVchsoKAz1SfeIaLwcJ0DRJk+VmgXNjcxCeB6zxcx6M1lkLX66v?=
 =?iso-8859-1?Q?Lj16zU8q0xRTAn5zZubFpjwS588784X4EBGwoqfPvzWZ/m/cujjv84RE0U?=
 =?iso-8859-1?Q?y2Rq64qRxg7y17HzkNCqFT380Dl8JiG8z565bUGDIuqtGz27mJ4X/ohWs5?=
 =?iso-8859-1?Q?pGrU1zwLdeE9zxkzrNlBSyel9T0umjKFR/ebLVFHeIPhHNVseOVtwj73Gm?=
 =?iso-8859-1?Q?n3sp5DcFjBCHGZH8qvfGhl7Ie6YkQfEM0B/TVNYAAXwoILfNEXjDu7GtY2?=
 =?iso-8859-1?Q?Ykd5rb9cfpaZm9wDqgig9fs0y6xcsB+IiQwbOvXoH4nuIkjBK6xkuyJO2T?=
 =?iso-8859-1?Q?1JQPxzAqvLougmRIVx6mqq9zwmbTK+r6RtlHYiz95WanG/5l5J2lZ3CLFC?=
 =?iso-8859-1?Q?GnQI7+Y+m8oVcxl/yDqMtSguejrGUPNBuq0tBCgjKIw8ckzWIggnpFTdnm?=
 =?iso-8859-1?Q?YAgd8peijg0x7v67SauAiHI40dUEYG8uUFIfjFDmdy0HEUx/KqDnsv17Bv?=
 =?iso-8859-1?Q?fh/O6GqbBaoASyZQyCwH5oZJDhIgzf1kPYu0Uq+OlsKEPGV6t35iBvdoM0?=
 =?iso-8859-1?Q?w0SVTHPTogwDwc3YWALEcFkSa1RjSFUf7efjjtshWduucWBKVWg1bsOvie?=
 =?iso-8859-1?Q?gP5K4AZBmDjRXd2jAPM2X2tcDJfp9LIvSdhwnGSAE2xV8b5Ajz0OliAgM6?=
 =?iso-8859-1?Q?qDkOmiUKVLTl80tkVlbK2Hs7kc0E1q9XUhQLAg3BXjeUe/H0tJR8uuJyEZ?=
 =?iso-8859-1?Q?mVySln4mMrTeW5kiE9MbtA29+E0uDeVHyWC498C1bQNR3s3fRhYvH6wQ?=
 =?iso-8859-1?Q?=3D=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PAVPR03MB10102.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 22c62564-d34e-4326-abd0-08dd354606a2
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2025 09:21:43.1709
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: owqCvx+UtBcQPTV3LEypmJggwTxvfAteG8KMZPDMDuNBk9ye/rLkmFkbp1/fGxVKlnKP4mwbDFREiA7c01zUTQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR03MB6795

Add support for Renesas Gen4 boards such as S4[1] and V4H[2] by adding the
appropriate confing option, and support for the Gen4 ITS.
Tested on Renesas R-Car V4H board.

[1]: https://www.renesas.com/en/products/automotive-products/automotive-sys=
tem-chips-socs/r-car-s4-automotive-system-chip-soc-car-servercommunication-=
gateway
[2]: https://www.renesas.com/en/products/automotive-products/automotive-sys=
tem-chips-socs/r-car-v4h-best-class-deep-learning-very-low-power-system-chi=
p-automated-driving-level-2level-3

Oleksandr Andrushchenko (2):
  ARM: ITS: implement quirks and add support for Renesas Gen4 ITS
  xen/arm: platform: Add support for R-Car Gen4

 xen/arch/arm/gic-v3-its.c             | 141 +++++++++++++++++++++++---
 xen/arch/arm/gic-v3-lpi.c             |  23 +++--
 xen/arch/arm/include/asm/gic_v3_its.h |   8 ++
 xen/arch/arm/platforms/Kconfig        |  10 +-
 4 files changed, 161 insertions(+), 21 deletions(-)

--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 09:35:15 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 09:35:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872283.1283239 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXznq-0006a3-8f; Wed, 15 Jan 2025 09:35:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872283.1283239; Wed, 15 Jan 2025 09:35:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tXznq-0006Zw-65; Wed, 15 Jan 2025 09:35:10 +0000
Received: by outflank-mailman (input) for mailman id 872283;
 Wed, 15 Jan 2025 09:35:08 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=P4PG=UH=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tXzno-0006Zq-Qb
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 09:35:08 +0000
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com
 [2a00:1450:4864:20::129])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 01e4200a-d324-11ef-a0e1-8be0dac302b0;
 Wed, 15 Jan 2025 10:35:07 +0100 (CET)
Received: by mail-lf1-x129.google.com with SMTP id
 2adb3069b0e04-53ff1f7caaeso6199513e87.0
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 01:35:07 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5428be55eb2sm1999104e87.63.2025.01.15.01.35.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 15 Jan 2025 01:35:06 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 01e4200a-d324-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736933707; x=1737538507; darn=lists.xenproject.org;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=MVUGBHsOaBRGW60iOI7JTNbwhnMQ5aNfUJ+W80MQNRM=;
        b=E5+6gibVM1VtXBTxNVTzK29HlyOA3iILWwPcViBBvCzyriuEcV7JaSuoykOHXeyW0C
         SOSNCFwy3ei/ZyLKzgAR1APpO2Yb+wCUV1p2EY/OxE58NhO+un0IIeO5XZbYvu/cr9Tb
         /+GYJWjBtYwrB1Z81j9VgcQDvSQVeX3B6MEymJYVvLcMOyhNJcYuytHP+5WjECwrr/v6
         p0v3PoIjYhqR1PRRjHq/bC8rZFett5StoXw4muEDVJFaVfeC8UfdSSU9MCOaHCwd71aS
         IKcYEAgCePlhKRfYAUubzJMRvgd4XpowboXQ5CxkZWuy3MtluuM9tnhhNQZa/04lmdbH
         ekKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736933707; x=1737538507;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=MVUGBHsOaBRGW60iOI7JTNbwhnMQ5aNfUJ+W80MQNRM=;
        b=NWniODtu0RvGEVvMlWsvropz+B2GAEYninRaerX6/8DlJUzPsi//BQOolVoDf0dU44
         eqm6f2G4bB9OZl3e36XI4ft6yYeMEEEyPlkaiZF5SBLP59M8pDcm9RG9DJQXcVSGyYDi
         uV82fuKMoAT4PuGezbk4JE9BTADTs+3Tv5sn2pzqnVh8ndIjfSJ6CTkyjYsNpF0tCE7j
         dqO6Vnrs/kxlSZ24P0H8IYGkiVLQNuhT9yfrxa0mV3PyvjTQJAkjIz5y3W1pWMqnaE7Z
         YxCKHNYVKfQy1ujaCjhV9wCCrKw80pIR7TfrZ8CxkUlPZHY+JnxoGDZ+XDNv0ImZtSeY
         XM7g==
X-Forwarded-Encrypted: i=1; AJvYcCWdlsXu8mApR0/w1Gre4CbJ6eXM9qTp/aVhB/dSdcuZ2CiJyWPBkd/yNqtHTCWTumrnbyZE6KKWBc8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxvajKrvsDZX/LHfioQ+RxibuROofWKSSaJwlwDFPPfeJnlb3si
	IOFSJ26ccsNOmx6jGi5cwE11M5aZo7sFZvBMoJiKmMSX05T8kNe4
X-Gm-Gg: ASbGncvf8GBLtwAM95FIThNGUKYTvogOfv6c+w2zOqZgvG4+tHVqMmWoblAu9DCJBLC
	zJl6JtwjCZ9gl0FLo+4fzVCzmiifMoqFNHfgcuh0yOoEBgWnQ7m1tdDDYgVr21tZW+lR6bzvYvZ
	mDs97tL0fsNTVllqMgeJrZJzXaGO+/6JH8qqZNLqfdt9NCWskWoIq71mZVVD/B/65nx7ydFrbu0
	W2orCUetQjgfwJHnm4DmLJNVmv4B+eXPj1CkMJwCQpWqGyfZBzhP7cqh8TmKitairLwtg==
X-Google-Smtp-Source: AGHT+IH/J8kGBVm0+Pi5FXEcCR+0m/XhdVTAKV+QbJPBxNakCQfIj/xKvLYEFmzvHLQ4pjBpJylbNQ==
X-Received: by 2002:a05:6512:3d27:b0:542:2388:3f09 with SMTP id 2adb3069b0e04-542845b20bdmr8930899e87.37.1736933706733;
        Wed, 15 Jan 2025 01:35:06 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------m4ybZ1lbGe0P6uFPUc0udfX2"
Message-ID: <98adc1a4-e82f-4be4-a4c0-5d578884cf60@gmail.com>
Date: Wed, 15 Jan 2025 10:35:05 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20] automation/gitlab: disable coverage from clang
 randconfig
To: Roger Pau Monne <roger.pau@citrix.com>, xen-devel@lists.xenproject.org
Cc: Doug Goldstein <cardoe@cardoe.com>,
 Stefano Stabellini <sstabellini@kernel.org>
References: <20250114174345.60887-1-roger.pau@citrix.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <20250114174345.60887-1-roger.pau@citrix.com>

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


On 1/14/25 6:43 PM, Roger Pau Monne wrote:
> If randconfig enables coverage support the build times out due to GNU LD
> taking too long.  For the time being prevent coverage from being enabled in
> clang randconfig job.
>
> Signed-off-by: Roger Pau Monné<roger.pau@citrix.com>

R-Acked-by: Oleksii Kurochko<oleksii.kurochko@gmail.com>

~ Oleksii

> ---
> Cc: Oleksii Kurochko<oleksii.kurochko@gmail.com>
> ---
> I will fix the orphaned section stuff separately, as I'm considering just
> removing LLVM coverage support because the llvm coverage format is not
> stable, and the code to dump it has already become stale.  However I need
> to think about it, and in the short term disabling coverage support from
> randconfig is more straightforward.
> ---
>   automation/gitlab-ci/build.yaml | 2 ++
>   1 file changed, 2 insertions(+)
>
> diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
> index cb84f379b754..bc4a8a5ad20c 100644
> --- a/automation/gitlab-ci/build.yaml
> +++ b/automation/gitlab-ci/build.yaml
> @@ -556,6 +556,8 @@ debian-12-x86_64-clang-randconfig:
>     variables:
>       CONTAINER: debian:12-x86_64
>       RANDCONFIG: y
> +    EXTRA_FIXED_RANDCONFIG: |
> +      CONFIG_COVERAGE=n # Disable coverage otherwise build times out.
>   
>   debian-12-x86_64-gcc:
>     extends: .gcc-x86-64-build
--------------m4ybZ1lbGe0P6uFPUc0udfX2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 1/14/25 6:43 PM, Roger Pau Monne
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:20250114174345.60887-1-roger.pau@citrix.com">
      <pre wrap="" class="moz-quote-pre">If randconfig enables coverage support the build times out due to GNU LD
taking too long.  For the time being prevent coverage from being enabled in
clang randconfig job.

Signed-off-by: Roger Pau Monné <a class="moz-txt-link-rfc2396E" href="mailto:roger.pau@citrix.com">&lt;roger.pau@citrix.com&gt;</a></pre>
    </blockquote>
    <pre>R-Acked-by: Oleksii Kurochko <a class="moz-txt-link-rfc2396E" href="mailto:oleksii.kurochko@gmail.com">&lt;oleksii.kurochko@gmail.com&gt;</a></pre>
    <pre>~ Oleksii
</pre>
    <blockquote type="cite"
      cite="mid:20250114174345.60887-1-roger.pau@citrix.com">
      <pre wrap="" class="moz-quote-pre">
---
Cc: Oleksii Kurochko <a class="moz-txt-link-rfc2396E" href="mailto:oleksii.kurochko@gmail.com">&lt;oleksii.kurochko@gmail.com&gt;</a>
---
I will fix the orphaned section stuff separately, as I'm considering just
removing LLVM coverage support because the llvm coverage format is not
stable, and the code to dump it has already become stale.  However I need
to think about it, and in the short term disabling coverage support from
randconfig is more straightforward.
---
 automation/gitlab-ci/build.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
index cb84f379b754..bc4a8a5ad20c 100644
--- a/automation/gitlab-ci/build.yaml
+++ b/automation/gitlab-ci/build.yaml
@@ -556,6 +556,8 @@ debian-12-x86_64-clang-randconfig:
   variables:
     CONTAINER: debian:12-x86_64
     RANDCONFIG: y
+    EXTRA_FIXED_RANDCONFIG: |
+      CONFIG_COVERAGE=n # Disable coverage otherwise build times out.
 
 debian-12-x86_64-gcc:
   extends: .gcc-x86-64-build
</pre>
    </blockquote>
  </body>
</html>

--------------m4ybZ1lbGe0P6uFPUc0udfX2--


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 10:14:18 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 10:14:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872293.1283249 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY0PO-0004WW-3p; Wed, 15 Jan 2025 10:13:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872293.1283249; Wed, 15 Jan 2025 10: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 <xen-devel-bounces@lists.xenproject.org>)
	id 1tY0PO-0004WP-0r; Wed, 15 Jan 2025 10:13:58 +0000
Received: by outflank-mailman (input) for mailman id 872293;
 Wed, 15 Jan 2025 10:13:57 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=MxfB=UH=ideasonboard.com=tomi.valkeinen@srs-se1.protection.inumbo.net>)
 id 1tY0PN-0004W9-3f
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 10:13:57 +0000
Received: from perceval.ideasonboard.com (perceval.ideasonboard.com
 [213.167.242.64]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6cb58e80-d329-11ef-a0e1-8be0dac302b0;
 Wed, 15 Jan 2025 11:13:54 +0100 (CET)
Received: from [192.168.88.20] (91-158-153-178.elisa-laajakaista.fi
 [91.158.153.178])
 by perceval.ideasonboard.com (Postfix) with ESMTPSA id A30BD22E;
 Wed, 15 Jan 2025 11:12:54 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 6cb58e80-d329-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;
	s=mail; t=1736935975;
	bh=A0uT2PZu2vMEF9l8RixHcuD7XJQCUpNHinaQ0kfDHhA=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=pmR2bdALx1oQyukLslwEK4I+DzAJ+sQ7jabs2IStX4+lbodFhHRKpbzD2TbgjeFIq
	 wvGaKkMawbqcDlftYcVj6Xwl5RO6AMISn5ADly0zRVsc0cmRz82fdiURAcZKwFjw2x
	 puw3h1fl2vbnDQxZ0v1561h2shhHO4y1sRLg8SKI=
Message-ID: <cdbe483d-0895-47aa-8c83-1c28220f4a02@ideasonboard.com>
Date: Wed, 15 Jan 2025 12:13:48 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with
 drm_mode_size_dumb()
To: Thomas Zimmermann <tzimmermann@suse.de>,
 maarten.lankhorst@linux.intel.com, mripard@kernel.org, airlied@gmail.com,
 simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org, linux-mediatek@lists.infradead.org,
 freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
 imx@lists.linux.dev, linux-samsung-soc@vger.kernel.org,
 nouveau@lists.freedesktop.org, virtualization@lists.linux.dev,
 spice-devel@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org,
 linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org,
 intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org,
 Laurent Pinchart <laurent.pinchart@ideasonboard.com>
References: <20250109150310.219442-1-tzimmermann@suse.de>
 <20250109150310.219442-26-tzimmermann@suse.de>
Content-Language: en-US
From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Autocrypt: addr=tomi.valkeinen@ideasonboard.com; keydata=
 xsFNBE6ms0cBEACyizowecZqXfMZtnBniOieTuFdErHAUyxVgtmr0f5ZfIi9Z4l+uUN4Zdw2
 wCEZjx3o0Z34diXBaMRJ3rAk9yB90UJAnLtb8A97Oq64DskLF81GCYB2P1i0qrG7UjpASgCA
 Ru0lVvxsWyIwSfoYoLrazbT1wkWRs8YBkkXQFfL7Mn3ZMoGPcpfwYH9O7bV1NslbmyJzRCMO
 eYV258gjCcwYlrkyIratlHCek4GrwV8Z9NQcjD5iLzrONjfafrWPwj6yn2RlL0mQEwt1lOvn
 LnI7QRtB3zxA3yB+FLsT1hx0va6xCHpX3QO2gBsyHCyVafFMrg3c/7IIWkDLngJxFgz6DLiA
 G4ld1QK/jsYqfP2GIMH1mFdjY+iagG4DqOsjip479HCWAptpNxSOCL6z3qxCU8MCz8iNOtZk
 DYXQWVscM5qgYSn+fmMM2qN+eoWlnCGVURZZLDjg387S2E1jT/dNTOsM/IqQj+ZROUZuRcF7
 0RTtuU5q1HnbRNwy+23xeoSGuwmLQ2UsUk7Q5CnrjYfiPo3wHze8avK95JBoSd+WIRmV3uoO
 rXCoYOIRlDhg9XJTrbnQ3Ot5zOa0Y9c4IpyAlut6mDtxtKXr4+8OzjSVFww7tIwadTK3wDQv
 Bus4jxHjS6dz1g2ypT65qnHen6mUUH63lhzewqO9peAHJ0SLrQARAQABzTBUb21pIFZhbGtl
 aW5lbiA8dG9taS52YWxrZWluZW5AaWRlYXNvbmJvYXJkLmNvbT7CwY4EEwEIADgWIQTEOAw+
 ll79gQef86f6PaqMvJYe9QUCX/HruAIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRD6
 PaqMvJYe9WmFD/99NGoD5lBJhlFDHMZvO+Op8vCwnIRZdTsyrtGl72rVh9xRfcSgYPZUvBuT
 VDxE53mY9HaZyu1eGMccYRBaTLJSfCXl/g317CrMNdY0k40b9YeIX10feiRYEWoDIPQ3tMmA
 0nHDygzcnuPiPT68JYZ6tUOvAt7r6OX/litM+m2/E9mtp8xCoWOo/kYO4mOAIoMNvLB8vufi
 uBB4e/AvAjtny4ScuNV5c5q8MkfNIiOyag9QCiQ/JfoAqzXRjVb4VZG72AKaElwipiKCWEcU
 R4+Bu5Qbaxj7Cd36M/bI54OrbWWETJkVVSV1i0tghCd6HHyquTdFl7wYcz6cL1hn/6byVnD+
 sR3BLvSBHYp8WSwv0TCuf6tLiNgHAO1hWiQ1pOoXyMEsxZlgPXT+wb4dbNVunckwqFjGxRbl
 Rz7apFT/ZRwbazEzEzNyrBOfB55xdipG/2+SmFn0oMFqFOBEszXLQVslh64lI0CMJm2OYYe3
 PxHqYaztyeXsx13Bfnq9+bUynAQ4uW1P5DJ3OIRZWKmbQd/Me3Fq6TU57LsvwRgE0Le9PFQs
 dcP2071rMTpqTUteEgODJS4VDf4lXJfY91u32BJkiqM7/62Cqatcz5UWWHq5xeF03MIUTqdE
 qHWk3RJEoWHWQRzQfcx6Fn2fDAUKhAddvoopfcjAHfpAWJ+ENc7BTQROprNHARAAx0aat8GU
 hsusCLc4MIxOQwidecCTRc9Dz/7U2goUwhw2O5j9TPqLtp57VITmHILnvZf6q3QAho2QMQyE
 DDvHubrdtEoqaaSKxKkFie1uhWNNvXPhwkKLYieyL9m2JdU+b88HaDnpzdyTTR4uH7wk0bBa
 KbTSgIFDDe5lXInypewPO30TmYNkFSexnnM3n1PBCqiJXsJahE4ZQ+WnV5FbPUj8T2zXS2xk
 0LZ0+DwKmZ0ZDovvdEWRWrz3UzJ8DLHb7blPpGhmqj3ANXQXC7mb9qJ6J/VSl61GbxIO2Dwb
 xPNkHk8fwnxlUBCOyBti/uD2uSTgKHNdabhVm2dgFNVuS1y3bBHbI/qjC3J7rWE0WiaHWEqy
 UVPk8rsph4rqITsj2RiY70vEW0SKePrChvET7D8P1UPqmveBNNtSS7In+DdZ5kUqLV7rJnM9
 /4cwy+uZUt8cuCZlcA5u8IsBCNJudxEqBG10GHg1B6h1RZIz9Q9XfiBdaqa5+CjyFs8ua01c
 9HmyfkuhXG2OLjfQuK+Ygd56mV3lq0aFdwbaX16DG22c6flkkBSjyWXYepFtHz9KsBS0DaZb
 4IkLmZwEXpZcIOQjQ71fqlpiXkXSIaQ6YMEs8WjBbpP81h7QxWIfWtp+VnwNGc6nq5IQDESH
 mvQcsFS7d3eGVI6eyjCFdcAO8eMAEQEAAcLBXwQYAQIACQUCTqazRwIbDAAKCRD6PaqMvJYe
 9fA7EACS6exUedsBKmt4pT7nqXBcRsqm6YzT6DeCM8PWMTeaVGHiR4TnNFiT3otD5UpYQI7S
 suYxoTdHrrrBzdlKe5rUWpzoZkVK6p0s9OIvGzLT0lrb0HC9iNDWT3JgpYDnk4Z2mFi6tTbq
 xKMtpVFRA6FjviGDRsfkfoURZI51nf2RSAk/A8BEDDZ7lgJHskYoklSpwyrXhkp9FHGMaYII
 m9EKuUTX9JPDG2FTthCBrdsgWYPdJQvM+zscq09vFMQ9Fykbx5N8z/oFEUy3ACyPqW2oyfvU
 CH5WDpWBG0s5BALp1gBJPytIAd/pY/5ZdNoi0Cx3+Z7jaBFEyYJdWy1hGddpkgnMjyOfLI7B
 CFrdecTZbR5upjNSDvQ7RG85SnpYJTIin+SAUazAeA2nS6gTZzumgtdw8XmVXZwdBfF+ICof
 92UkbYcYNbzWO/GHgsNT1WnM4sa9lwCSWH8Fw1o/3bX1VVPEsnESOfxkNdu+gAF5S6+I6n3a
 ueeIlwJl5CpT5l8RpoZXEOVtXYn8zzOJ7oGZYINRV9Pf8qKGLf3Dft7zKBP832I3PQjeok7F
 yjt+9S+KgSFSHP3Pa4E7lsSdWhSlHYNdG/czhoUkSCN09C0rEK93wxACx3vtxPLjXu6RptBw
 3dRq7n+mQChEB1am0BueV1JZaBboIL0AGlSJkm23kw==
In-Reply-To: <20250109150310.219442-26-tzimmermann@suse.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi!

On 09/01/2025 16:57, Thomas Zimmermann wrote:
> Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
> buffer size. Align the pitch according to hardware requirements.
> 
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> ---
>   drivers/gpu/drm/xlnx/zynqmp_kms.c | 7 +++++--
>   1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c b/drivers/gpu/drm/xlnx/zynqmp_kms.c
> index b47463473472..7ea0cd4f71d3 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_kms.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_kms.c
> @@ -19,6 +19,7 @@
>   #include <drm/drm_crtc.h>
>   #include <drm/drm_device.h>
>   #include <drm/drm_drv.h>
> +#include <drm/drm_dumb_buffers.h>
>   #include <drm/drm_encoder.h>
>   #include <drm/drm_fbdev_dma.h>
>   #include <drm/drm_fourcc.h>
> @@ -363,10 +364,12 @@ static int zynqmp_dpsub_dumb_create(struct drm_file *file_priv,
>   				    struct drm_mode_create_dumb *args)
>   {
>   	struct zynqmp_dpsub *dpsub = to_zynqmp_dpsub(drm);
> -	unsigned int pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
> +	int ret;
>   
>   	/* Enforce the alignment constraints of the DMA engine. */
> -	args->pitch = ALIGN(pitch, dpsub->dma_align);
> +	ret = drm_mode_size_dumb(drm, args, dpsub->dma_align, 0);
> +	if (ret)
> +		return ret;
>   
>   	return drm_gem_dma_dumb_create_internal(file_priv, drm, args);
>   }

I have some trouble with this one.

I have sent a series to add some pixel formats:

https://lore.kernel.org/all/20250115-xilinx-formats-v2-0-160327ca652a@ideasonboard.com/

Let's look at XV15. It's similar to NV12, but 10 bits per component, and 
some packing and padding.

First plane: 3 pixels in a 32 bit group
Second plane: 3 pixels in a 64 bit group, 2x2 subsampled

So, on average, a pixel on the first plane takes 32 / 3 = 10.666... bits 
on a line. That's not a usable number for the DRM_IOCTL_MODE_CREATE_DUMB 
ioctl.

What I did was to use the pixel group size as "bpp" for 
DRM_IOCTL_MODE_CREATE_DUMB. So, e.g., for 720 x 576:

Stride for first plane: 720 * (32 / 3) / 8 = 960 bytes
Stride for second plane: 720 / 2 * (64 / 3) / 8 = 960 bytes

First plane: 720 / 3 = 240 pixel groups
Second plane: 720 / 2 / 3 = 120 pixel groups

So I allocated the two planes with:
240 x 576 with 32 bitspp
120 x 288 with 64 bitspp

This worked, and if I look at the DRM_IOCTL_MODE_CREATE_DUMB in the 
docs, I can't right away see anything there that says my tactic was not 
allowed.

The above doesn't work anymore with this patch, as the code calls 
drm_driver_color_mode_format(), which fails for 64 bitspp. It feels a 
bit odd that DRM_IOCTL_MODE_CREATE_DUMB will try to guess the RGB fourcc 
for a dumb buffer allocation.

So, what to do here? Am I doing something silly? What's the correct way 
to allocate the buffers for XV15? Should I just use 32 bitspp for the 
plane 2 too, and double the width (this works)?

Is DRM_IOCTL_MODE_CREATE_DUMB only meant for simple RGB formats? The 
xilinx driver can, of course, just not use drm_mode_size_dumb(). But if 
so, I guess the limitations of drm_mode_size_dumb() should be documented.

Do we need a new dumb-alloc ioctl that takes the format and plane number 
as parameters? Or alternatively a simpler dumb-alloc that doesn't have 
width and bpp, but instead takes a stride and height as parameters? I 
think those would be easier for the userspace to use, instead of trying 
to adjust the parameters to be suitable for the kernel.

  Tomi



From xen-devel-bounces@lists.xenproject.org Wed Jan 15 10:26:25 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 10:26:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872303.1283260 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY0bD-0006mu-1n; Wed, 15 Jan 2025 10:26:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872303.1283260; Wed, 15 Jan 2025 10:26:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY0bC-0006mn-V8; Wed, 15 Jan 2025 10:26:10 +0000
Received: by outflank-mailman (input) for mailman id 872303;
 Wed, 15 Jan 2025 10:26:10 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=AzvQ=UH=suse.de=tzimmermann@srs-se1.protection.inumbo.net>)
 id 1tY0bB-0006mV-Qt
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 10:26:09 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1fa15300-d32b-11ef-a0e1-8be0dac302b0;
 Wed, 15 Jan 2025 11:26:04 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id 3A60921285;
 Wed, 15 Jan 2025 10:26:03 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id B2519139CB;
 Wed, 15 Jan 2025 10:26:02 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id yds5KjqNh2dqKAAAD6G6ig
 (envelope-from <tzimmermann@suse.de>); Wed, 15 Jan 2025 10:26:02 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1fa15300-d32b-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736936763; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=o5OaTSBvndaqL7pmKVkJ0tKcrkXR4wXg7zZA1xwdifc=;
	b=Mljgl0DvQXsyKMdMzmz5ZwZ3V789zCdVdhgaCjuMtwHrT61J2CLPcsqyigpgNfMgt5s9ED
	NQBLa2bFnxQBC6Lh8kmGl4ElL6IbxkHaMKnpSDKgAWvZ5RgKmpAEVOTkk2jS/7Dqz07SiL
	vCLaFHZP1mmjRXmvQ/ScFe4UhJimBB4=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736936763;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=o5OaTSBvndaqL7pmKVkJ0tKcrkXR4wXg7zZA1xwdifc=;
	b=qI2Y6oN0l9JxGfh+RN+mqlivvJYcBaYsV/e1PTdXmK0ZMZeCqm75AAiZVcbCx5W/dssHYm
	9npljUHucuH2iADw==
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736936763; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=o5OaTSBvndaqL7pmKVkJ0tKcrkXR4wXg7zZA1xwdifc=;
	b=Mljgl0DvQXsyKMdMzmz5ZwZ3V789zCdVdhgaCjuMtwHrT61J2CLPcsqyigpgNfMgt5s9ED
	NQBLa2bFnxQBC6Lh8kmGl4ElL6IbxkHaMKnpSDKgAWvZ5RgKmpAEVOTkk2jS/7Dqz07SiL
	vCLaFHZP1mmjRXmvQ/ScFe4UhJimBB4=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736936763;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=o5OaTSBvndaqL7pmKVkJ0tKcrkXR4wXg7zZA1xwdifc=;
	b=qI2Y6oN0l9JxGfh+RN+mqlivvJYcBaYsV/e1PTdXmK0ZMZeCqm75AAiZVcbCx5W/dssHYm
	9npljUHucuH2iADw==
Message-ID: <bc97b92e-7f8a-4b92-af8a-20fa165ead55@suse.de>
Date: Wed, 15 Jan 2025 11:26:02 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with
 drm_mode_size_dumb()
To: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>,
 maarten.lankhorst@linux.intel.com, mripard@kernel.org, airlied@gmail.com,
 simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org, linux-mediatek@lists.infradead.org,
 freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
 imx@lists.linux.dev, linux-samsung-soc@vger.kernel.org,
 nouveau@lists.freedesktop.org, virtualization@lists.linux.dev,
 spice-devel@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org,
 linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org,
 intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org,
 Laurent Pinchart <laurent.pinchart@ideasonboard.com>
References: <20250109150310.219442-1-tzimmermann@suse.de>
 <20250109150310.219442-26-tzimmermann@suse.de>
 <cdbe483d-0895-47aa-8c83-1c28220f4a02@ideasonboard.com>
Content-Language: en-US
From: Thomas Zimmermann <tzimmermann@suse.de>
Autocrypt: addr=tzimmermann@suse.de; keydata=
 xsBNBFs50uABCADEHPidWt974CaxBVbrIBwqcq/WURinJ3+2WlIrKWspiP83vfZKaXhFYsdg
 XH47fDVbPPj+d6tQrw5lPQCyqjwrCPYnq3WlIBnGPJ4/jreTL6V+qfKRDlGLWFjZcsrPJGE0
 BeB5BbqP5erN1qylK9i3gPoQjXGhpBpQYwRrEyQyjuvk+Ev0K1Jc5tVDeJAuau3TGNgah4Yc
 hdHm3bkPjz9EErV85RwvImQ1dptvx6s7xzwXTgGAsaYZsL8WCwDaTuqFa1d1jjlaxg6+tZsB
 9GluwvIhSezPgnEmimZDkGnZRRSFiGP8yjqTjjWuf0bSj5rUnTGiyLyRZRNGcXmu6hjlABEB
 AAHNJ1Rob21hcyBaaW1tZXJtYW5uIDx0emltbWVybWFubkBzdXNlLmRlPsLAjgQTAQgAOAIb
 AwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftODH
 AAoJEGgNwR1TC3ojx1wH/0hKGWugiqDgLNXLRD/4TfHBEKmxIrmfu9Z5t7vwUKfwhFL6hqvo
 lXPJJKQpQ2z8+X2vZm/slsLn7J1yjrOsoJhKABDi+3QWWSGkaGwRJAdPVVyJMfJRNNNIKwVb
 U6B1BkX2XDKDGffF4TxlOpSQzdtNI/9gleOoUA8+jy8knnDYzjBNOZqLG2FuTdicBXblz0Mf
 vg41gd9kCwYXDnD91rJU8tzylXv03E75NCaTxTM+FBXPmsAVYQ4GYhhgFt8S2UWMoaaABLDe
 7l5FdnLdDEcbmd8uLU2CaG4W2cLrUaI4jz2XbkcPQkqTQ3EB67hYkjiEE6Zy3ggOitiQGcqp
 j//OwE0EWznS4AEIAMYmP4M/V+T5RY5at/g7rUdNsLhWv1APYrh9RQefODYHrNRHUE9eosYb
 T6XMryR9hT8XlGOYRwKWwiQBoWSDiTMo/Xi29jUnn4BXfI2px2DTXwc22LKtLAgTRjP+qbU6
 3Y0xnQN29UGDbYgyyK51DW3H0If2a3JNsheAAK+Xc9baj0LGIc8T9uiEWHBnCH+RdhgATnWW
 GKdDegUR5BkDfDg5O/FISymJBHx2Dyoklv5g4BzkgqTqwmaYzsl8UxZKvbaxq0zbehDda8lv
 hFXodNFMAgTLJlLuDYOGLK2AwbrS3Sp0AEbkpdJBb44qVlGm5bApZouHeJ/+n+7r12+lqdsA
 EQEAAcLAdgQYAQgAIAIbDBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftOH6AAoJEGgNwR1T
 C3ojVSkIALpAPkIJPQoURPb1VWjh34l0HlglmYHvZszJWTXYwavHR8+k6Baa6H7ufXNQtThR
 yIxJrQLW6rV5lm7TjhffEhxVCn37+cg0zZ3j7zIsSS0rx/aMwi6VhFJA5hfn3T0TtrijKP4A
 SAQO9xD1Zk9/61JWk8OysuIh7MXkl0fxbRKWE93XeQBhIJHQfnc+YBLprdnxR446Sh8Wn/2D
 Ya8cavuWf2zrB6cZurs048xe0UbSW5AOSo4V9M0jzYI4nZqTmPxYyXbm30Kvmz0rYVRaitYJ
 4kyYYMhuULvrJDMjZRvaNe52tkKAvMevcGdt38H4KSVXAylqyQOW5zvPc4/sq9c=
In-Reply-To: <cdbe483d-0895-47aa-8c83-1c28220f4a02@ideasonboard.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Level: 
X-Spamd-Result: default: False [-2.80 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	FREEMAIL_TO(0.00)[ideasonboard.com,linux.intel.com,kernel.org,gmail.com,ffwll.ch];
	RCPT_COUNT_TWELVE(0.00)[20];
	MIME_TRACE(0.00)[0:+];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	FREEMAIL_ENVRCPT(0.00)[gmail.com];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:email,suse.de:mid]
X-Spam-Score: -2.80
X-Spam-Flag: NO

Hi


Am 15.01.25 um 11:13 schrieb Tomi Valkeinen:
> Hi!
>
> On 09/01/2025 16:57, Thomas Zimmermann wrote:
>> Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
>> buffer size. Align the pitch according to hardware requirements.
>>
>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>> Cc: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
>> ---
>>   drivers/gpu/drm/xlnx/zynqmp_kms.c | 7 +++++--
>>   1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c 
>> b/drivers/gpu/drm/xlnx/zynqmp_kms.c
>> index b47463473472..7ea0cd4f71d3 100644
>> --- a/drivers/gpu/drm/xlnx/zynqmp_kms.c
>> +++ b/drivers/gpu/drm/xlnx/zynqmp_kms.c
>> @@ -19,6 +19,7 @@
>>   #include <drm/drm_crtc.h>
>>   #include <drm/drm_device.h>
>>   #include <drm/drm_drv.h>
>> +#include <drm/drm_dumb_buffers.h>
>>   #include <drm/drm_encoder.h>
>>   #include <drm/drm_fbdev_dma.h>
>>   #include <drm/drm_fourcc.h>
>> @@ -363,10 +364,12 @@ static int zynqmp_dpsub_dumb_create(struct 
>> drm_file *file_priv,
>>                       struct drm_mode_create_dumb *args)
>>   {
>>       struct zynqmp_dpsub *dpsub = to_zynqmp_dpsub(drm);
>> -    unsigned int pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
>> +    int ret;
>>         /* Enforce the alignment constraints of the DMA engine. */
>> -    args->pitch = ALIGN(pitch, dpsub->dma_align);
>> +    ret = drm_mode_size_dumb(drm, args, dpsub->dma_align, 0);
>> +    if (ret)
>> +        return ret;
>>         return drm_gem_dma_dumb_create_internal(file_priv, drm, args);
>>   }
>
> I have some trouble with this one.
>
> I have sent a series to add some pixel formats:
>
> https://lore.kernel.org/all/20250115-xilinx-formats-v2-0-160327ca652a@ideasonboard.com/ 
>
>
> Let's look at XV15. It's similar to NV12, but 10 bits per component, 
> and some packing and padding.
>
> First plane: 3 pixels in a 32 bit group
> Second plane: 3 pixels in a 64 bit group, 2x2 subsampled
>
> So, on average, a pixel on the first plane takes 32 / 3 = 10.666... 
> bits on a line. That's not a usable number for the 
> DRM_IOCTL_MODE_CREATE_DUMB ioctl.
>
> What I did was to use the pixel group size as "bpp" for 
> DRM_IOCTL_MODE_CREATE_DUMB. So, e.g., for 720 x 576:
>
> Stride for first plane: 720 * (32 / 3) / 8 = 960 bytes
> Stride for second plane: 720 / 2 * (64 / 3) / 8 = 960 bytes
>
> First plane: 720 / 3 = 240 pixel groups
> Second plane: 720 / 2 / 3 = 120 pixel groups
>
> So I allocated the two planes with:
> 240 x 576 with 32 bitspp
> 120 x 288 with 64 bitspp
>
> This worked, and if I look at the DRM_IOCTL_MODE_CREATE_DUMB in the 
> docs, I can't right away see anything there that says my tactic was 
> not allowed.
>
> The above doesn't work anymore with this patch, as the code calls 
> drm_driver_color_mode_format(), which fails for 64 bitspp. It feels a 
> bit odd that DRM_IOCTL_MODE_CREATE_DUMB will try to guess the RGB 
> fourcc for a dumb buffer allocation.
>
> So, what to do here? Am I doing something silly? What's the correct 
> way to allocate the buffers for XV15? Should I just use 32 bitspp for 
> the plane 2 too, and double the width (this works)?
>
> Is DRM_IOCTL_MODE_CREATE_DUMB only meant for simple RGB formats? The 
> xilinx driver can, of course, just not use drm_mode_size_dumb(). But 
> if so, I guess the limitations of drm_mode_size_dumb() should be 
> documented.
>
> Do we need a new dumb-alloc ioctl that takes the format and plane 
> number as parameters? Or alternatively a simpler dumb-alloc that 
> doesn't have width and bpp, but instead takes a stride and height as 
> parameters? I think those would be easier for the userspace to use, 
> instead of trying to adjust the parameters to be suitable for the kernel.

These are all good points. Did you read my discussion with Andy on patch 
2? I think it resolves all the points you have. The current CREATE_DUMB 
ioctl is unsuited for anything but the simple RGB formats. The bpp 
parameter is not very precise. The solution would be a new ioctl call 
that receives the DRM format and returns a buffer for each individual plane.

I provided a workaround patch that uses the bpp value directly if 
drm_driver_color_mode_format() does not support the bpp value. 
User-space code has to allocate a large enough buffer via the current 
CREATE_DUMB and compute the individual planes itself. See [1] for an 
example. [1] 
https://gitlab.freedesktop.org/mesa/drm/-/blob/main/tests/modetest/buffers.c?ref_type=heads#L302 
Does this work for you? Otherwise, I guess we should be talking about a 
possible CREATE_DUMB2 that fixes these shortcomings. Best regards Thomas
>
>  Tomi
>

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)



From xen-devel-bounces@lists.xenproject.org Wed Jan 15 10:43:13 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 10:43:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872316.1283270 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY0ra-0001qQ-HX; Wed, 15 Jan 2025 10:43:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872316.1283270; Wed, 15 Jan 2025 10:43:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY0ra-0001qJ-DK; Wed, 15 Jan 2025 10:43:06 +0000
Received: by outflank-mailman (input) for mailman id 872316;
 Wed, 15 Jan 2025 10:43:05 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=4o+i=UH=cloud.com=bernhard.kaindl@srs-se1.protection.inumbo.net>)
 id 1tY0rZ-0001qD-2a
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 10:43:05 +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 7f753389-d32d-11ef-a0e1-8be0dac302b0;
 Wed, 15 Jan 2025 11:43:03 +0100 (CET)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-4362bae4d7dso46613355e9.1
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 02:43:03 -0800 (PST)
Received: from localhost ([185.68.248.203]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a8e37d154sm17643663f8f.10.2025.01.15.02.43.02
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 15 Jan 2025 02:43:02 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 7f753389-d32d-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736937783; x=1737542583; 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=uOXIkpl9nUkKoAlwzI7JQ7MlkyqR4hdJY0tA9XuuqEw=;
        b=KUOlvW+yj/MXpjsIqLVsHfxcS25j/KzRW4ALYGrgByUcED8r7SJQnlRxoAhIu7JnyM
         mfYnPdwC7nGBpcWAaL3RPhKtMGOg0m6GWZuVy4PVRdfsy43XUul1cgBMOCq1arMu4cG1
         hhx4ZoCzIDXIfxlyZcYqD81wwPxDdRE7oy9XY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736937783; x=1737542583;
        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=uOXIkpl9nUkKoAlwzI7JQ7MlkyqR4hdJY0tA9XuuqEw=;
        b=VItrNZNdWRaCjjcgYUaXp+ynESwRjXU9rUUOjqehLFcAjOxglJl9t8Zz+KrqmKanV2
         pHU6M7VlCLyBqO7Uxmfy47wt8UvOd8lP3ueDBysnk9jmhIZKrQpz+wf110P6rgX4Ekjy
         X8g3to75NYX0TcKF2j73K10KemAA1wHDyZ5d8Sqa5qJIT92w6iu7PWaITo2udN7qgGz5
         yHrUt8zPrJAmND1xYR/QGo6e1E96pFT4NlnzAqSCWn2MSn6PEwilvLnVCNRboZtwGdSZ
         o+Ez5zFGsRvx9ZzwRn/XMjaKyuav2LHJj0fnrnU6fMbXNEH+SHCjIxsldDGS/TC7Slf9
         jrkA==
X-Gm-Message-State: AOJu0Yy5cctOjPcY2m/ANYahLStOhT7zbRPNoVdUBYL13q88XDa3bIDW
	kLGow+SuWYVkNNoIUuj4gYlBf2qWmd3fyHxx3jqR+LLRHdXq1UOR9EpfuHvvcdISpU17193P7Lu
	4bZgcew==
X-Gm-Gg: ASbGncvz+Py62prAJcCEwCde3TMlBw3rpNXalfCs5VGzOivcccVQ9Tuk3RIr/ZbePhC
	YYCcEX0OC4xCsRkgQ53N9aB7HFiIu5MSa6xYKcAke+Oq9rb/NO/DMBrIGU015difmS4kUUBvAfz
	DlgH8U8r7ynzJaXpGTEmyMpcunSBFmhn8cxEpSLYWWX4AHyZC1oaf0DqDYDsPlO7FrOedrt8kBW
	IVFsub2aPNxEBxInP7DqyJmkcJATRNsOUTdk+25NL/T4XiN7lVKQlg+gQ3aPA==
X-Google-Smtp-Source: AGHT+IEBSyUCZdFS+5yN4BDhICeSingrg6DKfYFQe8b/tGnIOwFiHV0ZkEWXBEE9skJxTaRA67lZaQ==
X-Received: by 2002:a05:600c:3551:b0:434:effb:9f8a with SMTP id 5b1f17b1804b1-436e26b8be2mr277621495e9.15.1736937782974;
        Wed, 15 Jan 2025 02:43:02 -0800 (PST)
From: Bernhard Kaindl <bernhard.kaindl@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Bernhard Kaindl <bernhard.kaindl@cloud.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Ross Lagerwall <ross.lagerwall@citrix.com>
Subject: [PATCH] docs: Improve spelling of few cases in the documentation
Date: Wed, 15 Jan 2025 11:42:59 +0100
Message-ID: <504170a4a195551072c14141e28ef554ac1cad2c.1736937491.git.bernhard.kaindl@cloud.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Skimming the docs, I came across a few places for spelling improvements.
I checked using dictionaries to be sure.

Signed-off-by: Bernhard Kaindl <bernhard.kaindl@cloud.com>
---
 docs/admin-guide/microcode-loading.rst    | 4 ++--
 docs/designs/non-cooperative-migration.md | 4 ++--
 docs/designs/qemu-deprivilege.md          | 2 +-
 docs/guest-guide/x86/hypercall-abi.rst    | 2 +-
 docs/man/xl.conf.5.pod.in                 | 2 +-
 docs/misc/livepatch.pandoc                | 2 +-
 6 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/docs/admin-guide/microcode-loading.rst b/docs/admin-guide/microcode-loading.rst
index a07e25802f..f9b2b73d17 100644
--- a/docs/admin-guide/microcode-loading.rst
+++ b/docs/admin-guide/microcode-loading.rst
@@ -20,7 +20,7 @@ distro guidance for microcode loading.
 Microcode can make almost arbitrary changes to the processor, including to
 software visible features.  This includes removing features (e.g. the Haswell
 TSX errata which necessitated disabling the feature entirely), or the addition
-of brand new features (e.g. the Spectre v2 controls to work around speculative
+of brand-new features (e.g. the Spectre v2 controls to work around speculative
 execution vulnerabilities).
 
 
@@ -40,7 +40,7 @@ Xen will report during boot if it performed a microcode update::
   (XEN) microcode: CPU6 updated from revision 0x1a to 0x25, date = 2018-04-02
 
 The exact details printed are system and microcode specific.  After boot, the
-current microcode version can obtained from with dom0::
+current microcode version can be obtained from with dom0::
 
   [root@host ~]# head /proc/cpuinfo
   processor    : 0
diff --git a/docs/designs/non-cooperative-migration.md b/docs/designs/non-cooperative-migration.md
index 4b876d809f..54496892ed 100644
--- a/docs/designs/non-cooperative-migration.md
+++ b/docs/designs/non-cooperative-migration.md
@@ -112,7 +112,7 @@ because the guest can sample its own domid from the frontend area and use
 it in hypercalls (e.g. HVMOP_set_param) rather than DOMID_SELF, the guest
 domid must also be preserved to maintain the ABI.
 
-Furthermore, it will necessary to modify backend drivers to re-establish
+Furthermore, it will be necessary to modify backend drivers to re-establish
 communication with frontend drivers without perturbing the content of the
 backend area or requiring any changes to the values of the xenstore state
 nodes.
@@ -259,7 +259,7 @@ Essentially this should skip the check to see if PV drivers and migrate as
 if there are none present, but also enabling the extra save records. Note
 that at least some of the extra records should only form part of a
 non-cooperative migration stream. For example, migrating event channel
-state would be counter productive in a normal migration as this will
+state would be counter-productive in a normal migration as this will
 essentially leak event channel objects at the receiving end. Others, such
 as grant table state, could potentially harmlessly form part of a normal
 migration stream.
diff --git a/docs/designs/qemu-deprivilege.md b/docs/designs/qemu-deprivilege.md
index 81a5f5c05d..f12b1a3ae3 100644
--- a/docs/designs/qemu-deprivilege.md
+++ b/docs/designs/qemu-deprivilege.md
@@ -3,7 +3,7 @@
 The goal of deprilvileging qemu is this: Even if there is a bug (for
 example in qemu) which permits a domain to gain control of the device
 model, the compromised device model process is prevented from
-violating the system's overall security properties.  Ie, a guest
+violating the system's overall security properties.  I.e., a guest
 cannot "escape" from the virtualisation by using a qemu bug.
 
 This document lists the various technical measures which we either
diff --git a/docs/guest-guide/x86/hypercall-abi.rst b/docs/guest-guide/x86/hypercall-abi.rst
index 745fbbb64a..e52ed453bc 100644
--- a/docs/guest-guide/x86/hypercall-abi.rst
+++ b/docs/guest-guide/x86/hypercall-abi.rst
@@ -109,7 +109,7 @@ abstracting away the details of how it is currently running.
 Creating Hypercall Pages
 ------------------------
 
-Guests which are started using the PV boot protocol may set set
+Guests which are started using the PV boot protocol may set
 ``XEN_ELFNOTE_HYPERCALL_PAGE`` to have the nominated page written as a
 hypercall page during construction.  This mechanism is common for PV guests,
 and allows hypercalls to be issued with no additional setup.
diff --git a/docs/man/xl.conf.5.pod.in b/docs/man/xl.conf.5.pod.in
index 44738b80bf..0cfec8587c 100644
--- a/docs/man/xl.conf.5.pod.in
+++ b/docs/man/xl.conf.5.pod.in
@@ -4,7 +4,7 @@
 
 =head1 DESCRIPTION
 
-The F<xl.conf> file allows configuration of hostwide C<xl> toolstack
+The F<xl.conf> file allows configuration of host-wide C<xl> toolstack
 options.
 
 For details of per-domain configuration options please see
diff --git a/docs/misc/livepatch.pandoc b/docs/misc/livepatch.pandoc
index a94fb57eb5..43010227e5 100644
--- a/docs/misc/livepatch.pandoc
+++ b/docs/misc/livepatch.pandoc
@@ -2,7 +2,7 @@
 
 ## Rationale
 
-A mechanism is required to binarily patch the running hypervisor with new
+A mechanism is required to binary-patch the running hypervisor with new
 opcodes that have come about due to primarily security updates.
 
 This document describes the design of the API that would allow us to
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Jan 15 10:59:06 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 10:59:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872325.1283280 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY16w-0003uc-QA; Wed, 15 Jan 2025 10:58:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872325.1283280; Wed, 15 Jan 2025 10:58:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY16w-0003uV-NP; Wed, 15 Jan 2025 10:58:58 +0000
Received: by outflank-mailman (input) for mailman id 872325;
 Wed, 15 Jan 2025 10:58:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=MxfB=UH=ideasonboard.com=tomi.valkeinen@srs-se1.protection.inumbo.net>)
 id 1tY16v-0003uP-Ah
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 10:58:57 +0000
Received: from perceval.ideasonboard.com (perceval.ideasonboard.com
 [213.167.242.64]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b5e90f11-d32f-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 11:58:54 +0100 (CET)
Received: from [192.168.88.20] (91-158-153-178.elisa-laajakaista.fi
 [91.158.153.178])
 by perceval.ideasonboard.com (Postfix) with ESMTPSA id 8E93E4AD;
 Wed, 15 Jan 2025 11:57:54 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b5e90f11-d32f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;
	s=mail; t=1736938675;
	bh=PHvyrlfL90DWijiSoft7XP7rReZoqz0LHMvPolG3eVc=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=lzo3SM0Jh0gt3jMLAaQUsepDmw7eYUBnlka5hbbPJnOVGveG2GsivekYsCC/wVcWM
	 Fpv1tfAAWSv7Wahb71B2n7RvzSXmVxJHOI1MGlNmaSR3eC23tKmnhwmEeri17hRi+x
	 h9NpTRQ9X4CPbC+pYA0xfkGmK5O2KaoBdQa05y/Q=
Message-ID: <f3ba05c7-6e49-4641-a3f9-ba418ebdb7c3@ideasonboard.com>
Date: Wed, 15 Jan 2025 12:58:48 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with
 drm_mode_size_dumb()
To: Thomas Zimmermann <tzimmermann@suse.de>,
 maarten.lankhorst@linux.intel.com, mripard@kernel.org, airlied@gmail.com,
 simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org, linux-mediatek@lists.infradead.org,
 freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
 imx@lists.linux.dev, linux-samsung-soc@vger.kernel.org,
 nouveau@lists.freedesktop.org, virtualization@lists.linux.dev,
 spice-devel@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org,
 linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org,
 intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org,
 Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
 Andy Yan <andyshrk@163.com>
References: <20250109150310.219442-1-tzimmermann@suse.de>
 <20250109150310.219442-26-tzimmermann@suse.de>
 <cdbe483d-0895-47aa-8c83-1c28220f4a02@ideasonboard.com>
 <bc97b92e-7f8a-4b92-af8a-20fa165ead55@suse.de>
Content-Language: en-US
From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Autocrypt: addr=tomi.valkeinen@ideasonboard.com; keydata=
 xsFNBE6ms0cBEACyizowecZqXfMZtnBniOieTuFdErHAUyxVgtmr0f5ZfIi9Z4l+uUN4Zdw2
 wCEZjx3o0Z34diXBaMRJ3rAk9yB90UJAnLtb8A97Oq64DskLF81GCYB2P1i0qrG7UjpASgCA
 Ru0lVvxsWyIwSfoYoLrazbT1wkWRs8YBkkXQFfL7Mn3ZMoGPcpfwYH9O7bV1NslbmyJzRCMO
 eYV258gjCcwYlrkyIratlHCek4GrwV8Z9NQcjD5iLzrONjfafrWPwj6yn2RlL0mQEwt1lOvn
 LnI7QRtB3zxA3yB+FLsT1hx0va6xCHpX3QO2gBsyHCyVafFMrg3c/7IIWkDLngJxFgz6DLiA
 G4ld1QK/jsYqfP2GIMH1mFdjY+iagG4DqOsjip479HCWAptpNxSOCL6z3qxCU8MCz8iNOtZk
 DYXQWVscM5qgYSn+fmMM2qN+eoWlnCGVURZZLDjg387S2E1jT/dNTOsM/IqQj+ZROUZuRcF7
 0RTtuU5q1HnbRNwy+23xeoSGuwmLQ2UsUk7Q5CnrjYfiPo3wHze8avK95JBoSd+WIRmV3uoO
 rXCoYOIRlDhg9XJTrbnQ3Ot5zOa0Y9c4IpyAlut6mDtxtKXr4+8OzjSVFww7tIwadTK3wDQv
 Bus4jxHjS6dz1g2ypT65qnHen6mUUH63lhzewqO9peAHJ0SLrQARAQABzTBUb21pIFZhbGtl
 aW5lbiA8dG9taS52YWxrZWluZW5AaWRlYXNvbmJvYXJkLmNvbT7CwY4EEwEIADgWIQTEOAw+
 ll79gQef86f6PaqMvJYe9QUCX/HruAIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRD6
 PaqMvJYe9WmFD/99NGoD5lBJhlFDHMZvO+Op8vCwnIRZdTsyrtGl72rVh9xRfcSgYPZUvBuT
 VDxE53mY9HaZyu1eGMccYRBaTLJSfCXl/g317CrMNdY0k40b9YeIX10feiRYEWoDIPQ3tMmA
 0nHDygzcnuPiPT68JYZ6tUOvAt7r6OX/litM+m2/E9mtp8xCoWOo/kYO4mOAIoMNvLB8vufi
 uBB4e/AvAjtny4ScuNV5c5q8MkfNIiOyag9QCiQ/JfoAqzXRjVb4VZG72AKaElwipiKCWEcU
 R4+Bu5Qbaxj7Cd36M/bI54OrbWWETJkVVSV1i0tghCd6HHyquTdFl7wYcz6cL1hn/6byVnD+
 sR3BLvSBHYp8WSwv0TCuf6tLiNgHAO1hWiQ1pOoXyMEsxZlgPXT+wb4dbNVunckwqFjGxRbl
 Rz7apFT/ZRwbazEzEzNyrBOfB55xdipG/2+SmFn0oMFqFOBEszXLQVslh64lI0CMJm2OYYe3
 PxHqYaztyeXsx13Bfnq9+bUynAQ4uW1P5DJ3OIRZWKmbQd/Me3Fq6TU57LsvwRgE0Le9PFQs
 dcP2071rMTpqTUteEgODJS4VDf4lXJfY91u32BJkiqM7/62Cqatcz5UWWHq5xeF03MIUTqdE
 qHWk3RJEoWHWQRzQfcx6Fn2fDAUKhAddvoopfcjAHfpAWJ+ENc7BTQROprNHARAAx0aat8GU
 hsusCLc4MIxOQwidecCTRc9Dz/7U2goUwhw2O5j9TPqLtp57VITmHILnvZf6q3QAho2QMQyE
 DDvHubrdtEoqaaSKxKkFie1uhWNNvXPhwkKLYieyL9m2JdU+b88HaDnpzdyTTR4uH7wk0bBa
 KbTSgIFDDe5lXInypewPO30TmYNkFSexnnM3n1PBCqiJXsJahE4ZQ+WnV5FbPUj8T2zXS2xk
 0LZ0+DwKmZ0ZDovvdEWRWrz3UzJ8DLHb7blPpGhmqj3ANXQXC7mb9qJ6J/VSl61GbxIO2Dwb
 xPNkHk8fwnxlUBCOyBti/uD2uSTgKHNdabhVm2dgFNVuS1y3bBHbI/qjC3J7rWE0WiaHWEqy
 UVPk8rsph4rqITsj2RiY70vEW0SKePrChvET7D8P1UPqmveBNNtSS7In+DdZ5kUqLV7rJnM9
 /4cwy+uZUt8cuCZlcA5u8IsBCNJudxEqBG10GHg1B6h1RZIz9Q9XfiBdaqa5+CjyFs8ua01c
 9HmyfkuhXG2OLjfQuK+Ygd56mV3lq0aFdwbaX16DG22c6flkkBSjyWXYepFtHz9KsBS0DaZb
 4IkLmZwEXpZcIOQjQ71fqlpiXkXSIaQ6YMEs8WjBbpP81h7QxWIfWtp+VnwNGc6nq5IQDESH
 mvQcsFS7d3eGVI6eyjCFdcAO8eMAEQEAAcLBXwQYAQIACQUCTqazRwIbDAAKCRD6PaqMvJYe
 9fA7EACS6exUedsBKmt4pT7nqXBcRsqm6YzT6DeCM8PWMTeaVGHiR4TnNFiT3otD5UpYQI7S
 suYxoTdHrrrBzdlKe5rUWpzoZkVK6p0s9OIvGzLT0lrb0HC9iNDWT3JgpYDnk4Z2mFi6tTbq
 xKMtpVFRA6FjviGDRsfkfoURZI51nf2RSAk/A8BEDDZ7lgJHskYoklSpwyrXhkp9FHGMaYII
 m9EKuUTX9JPDG2FTthCBrdsgWYPdJQvM+zscq09vFMQ9Fykbx5N8z/oFEUy3ACyPqW2oyfvU
 CH5WDpWBG0s5BALp1gBJPytIAd/pY/5ZdNoi0Cx3+Z7jaBFEyYJdWy1hGddpkgnMjyOfLI7B
 CFrdecTZbR5upjNSDvQ7RG85SnpYJTIin+SAUazAeA2nS6gTZzumgtdw8XmVXZwdBfF+ICof
 92UkbYcYNbzWO/GHgsNT1WnM4sa9lwCSWH8Fw1o/3bX1VVPEsnESOfxkNdu+gAF5S6+I6n3a
 ueeIlwJl5CpT5l8RpoZXEOVtXYn8zzOJ7oGZYINRV9Pf8qKGLf3Dft7zKBP832I3PQjeok7F
 yjt+9S+KgSFSHP3Pa4E7lsSdWhSlHYNdG/czhoUkSCN09C0rEK93wxACx3vtxPLjXu6RptBw
 3dRq7n+mQChEB1am0BueV1JZaBboIL0AGlSJkm23kw==
In-Reply-To: <bc97b92e-7f8a-4b92-af8a-20fa165ead55@suse.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi,

On 15/01/2025 12:26, Thomas Zimmermann wrote:
> Hi
> 
> 
> Am 15.01.25 um 11:13 schrieb Tomi Valkeinen:
>> Hi!
>>
>> On 09/01/2025 16:57, Thomas Zimmermann wrote:
>>> Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
>>> buffer size. Align the pitch according to hardware requirements.
>>>
>>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>>> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>>> Cc: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
>>> ---
>>>   drivers/gpu/drm/xlnx/zynqmp_kms.c | 7 +++++--
>>>   1 file changed, 5 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c b/drivers/gpu/drm/ 
>>> xlnx/zynqmp_kms.c
>>> index b47463473472..7ea0cd4f71d3 100644
>>> --- a/drivers/gpu/drm/xlnx/zynqmp_kms.c
>>> +++ b/drivers/gpu/drm/xlnx/zynqmp_kms.c
>>> @@ -19,6 +19,7 @@
>>>   #include <drm/drm_crtc.h>
>>>   #include <drm/drm_device.h>
>>>   #include <drm/drm_drv.h>
>>> +#include <drm/drm_dumb_buffers.h>
>>>   #include <drm/drm_encoder.h>
>>>   #include <drm/drm_fbdev_dma.h>
>>>   #include <drm/drm_fourcc.h>
>>> @@ -363,10 +364,12 @@ static int zynqmp_dpsub_dumb_create(struct 
>>> drm_file *file_priv,
>>>                       struct drm_mode_create_dumb *args)
>>>   {
>>>       struct zynqmp_dpsub *dpsub = to_zynqmp_dpsub(drm);
>>> -    unsigned int pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
>>> +    int ret;
>>>         /* Enforce the alignment constraints of the DMA engine. */
>>> -    args->pitch = ALIGN(pitch, dpsub->dma_align);
>>> +    ret = drm_mode_size_dumb(drm, args, dpsub->dma_align, 0);
>>> +    if (ret)
>>> +        return ret;
>>>         return drm_gem_dma_dumb_create_internal(file_priv, drm, args);
>>>   }
>>
>> I have some trouble with this one.
>>
>> I have sent a series to add some pixel formats:
>>
>> https://lore.kernel.org/all/20250115-xilinx-formats- 
>> v2-0-160327ca652a@ideasonboard.com/
>>
>> Let's look at XV15. It's similar to NV12, but 10 bits per component, 
>> and some packing and padding.
>>
>> First plane: 3 pixels in a 32 bit group
>> Second plane: 3 pixels in a 64 bit group, 2x2 subsampled
>>
>> So, on average, a pixel on the first plane takes 32 / 3 = 10.666... 
>> bits on a line. That's not a usable number for the 
>> DRM_IOCTL_MODE_CREATE_DUMB ioctl.
>>
>> What I did was to use the pixel group size as "bpp" for 
>> DRM_IOCTL_MODE_CREATE_DUMB. So, e.g., for 720 x 576:
>>
>> Stride for first plane: 720 * (32 / 3) / 8 = 960 bytes
>> Stride for second plane: 720 / 2 * (64 / 3) / 8 = 960 bytes
>>
>> First plane: 720 / 3 = 240 pixel groups
>> Second plane: 720 / 2 / 3 = 120 pixel groups
>>
>> So I allocated the two planes with:
>> 240 x 576 with 32 bitspp
>> 120 x 288 with 64 bitspp
>>
>> This worked, and if I look at the DRM_IOCTL_MODE_CREATE_DUMB in the 
>> docs, I can't right away see anything there that says my tactic was 
>> not allowed.
>>
>> The above doesn't work anymore with this patch, as the code calls 
>> drm_driver_color_mode_format(), which fails for 64 bitspp. It feels a 
>> bit odd that DRM_IOCTL_MODE_CREATE_DUMB will try to guess the RGB 
>> fourcc for a dumb buffer allocation.
>>
>> So, what to do here? Am I doing something silly? What's the correct 
>> way to allocate the buffers for XV15? Should I just use 32 bitspp for 
>> the plane 2 too, and double the width (this works)?
>>
>> Is DRM_IOCTL_MODE_CREATE_DUMB only meant for simple RGB formats? The 
>> xilinx driver can, of course, just not use drm_mode_size_dumb(). But 
>> if so, I guess the limitations of drm_mode_size_dumb() should be 
>> documented.
>>
>> Do we need a new dumb-alloc ioctl that takes the format and plane 
>> number as parameters? Or alternatively a simpler dumb-alloc that 
>> doesn't have width and bpp, but instead takes a stride and height as 
>> parameters? I think those would be easier for the userspace to use, 
>> instead of trying to adjust the parameters to be suitable for the kernel.
> 
> These are all good points. Did you read my discussion with Andy on patch 
> 2? I think it resolves all the points you have. The current CREATE_DUMB 

I had missed the discussion, and, indeed, the patch you attached fixes 
the problem on Xilinx.

> ioctl is unsuited for anything but the simple RGB formats. The bpp 

It's a bit difficult to use, but is it really unsuited? bitsperpixel, 
width and height do give an exact pitch and size, do they not? It does 
require the userspace to handle the subsampling and planes, though, so 
far from perfect.

So, I'm all for a new ioctl, but I don't right away see why the current 
ioctl couldn't be used. Which makes me wonder about the drm_warn() in 
your patch, and the "userspace throws in arbitrary values for bpp and 
relies on the kernel to figure it out". Maybe I'm missing something here.

> parameter is not very precise. The solution would be a new ioctl call 
> that receives the DRM format and returns a buffer for each individual 
> plane.

Yes, I think that makes sense. That's a long road, though =). So my 
question is, is CREATE_DUMB really unsuitable for other than simple RGB 
formats, or can it be suitable if we just define how the userspace 
should use it for multiplanar, subsampled formats?

  Tomi



From xen-devel-bounces@lists.xenproject.org Wed Jan 15 11:27:54 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 11:27:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872335.1283290 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY1Yh-0000IB-UD; Wed, 15 Jan 2025 11:27:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872335.1283290; Wed, 15 Jan 2025 11:27:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY1Yh-0000Hv-Qx; Wed, 15 Jan 2025 11:27:39 +0000
Received: by outflank-mailman (input) for mailman id 872335;
 Wed, 15 Jan 2025 11:27:38 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=dCnP=UH=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tY1Yg-0000Hn-L5
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 11:27:38 +0000
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com
 [2a00:1450:4864:20::42b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b770b583-d333-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 12:27:34 +0100 (CET)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-385dece873cso3247769f8f.0
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 03:27: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
 ffacd0b85a97d-38a8e38c7aesm17684196f8f.53.2025.01.15.03.27.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 15 Jan 2025 03:27:33 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b770b583-d333-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736940454; x=1737545254; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=HvkUa5uLY3YQ3D0vXDKbpRMD1APss4Lft9Dt22j368c=;
        b=BIzDcUQW1wE3cya7rMFvN2dPzyT2Sfd6nNS4QPurnl9gi6CmCRwFHMaA5kaanFFOgR
         w6kS5vOtwdjGmwDDta2lgu84AEUkfa8n0wF105Z8Sh3F6Ua8mdm/HFDrkj6XY8IAbvwr
         BqqCXtNOE/sOKUJ0L4RTGP1E06vZY9BuoJc7Wv/s2UVuRsp4MMbzMrd1k+6Ge0qBzqKo
         pHQgNq4B6Nur/Wu7tlGX5+JsufW2Y+rjkIDnuEvVy3EoGLj0NwauEeY6+y6aTTbE/epJ
         9cIuccpAvWNO28nNOsyPkx/3mR/5+5FMqIlFw7gDou3O+YMQxsYeNomBEby1N8/fsDp0
         63GQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736940454; x=1737545254;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=HvkUa5uLY3YQ3D0vXDKbpRMD1APss4Lft9Dt22j368c=;
        b=VE4dbKIZF3jq49Y4nxtYPs6FwVZjJVgWnlszr/W5UtMYHWqjj5Fv2LqWk6b41DK7iZ
         XaGzl3rUwFXk4NhK9gnd45ezSSkpDhs23BWKPIs9yJ35R5Wws66VlxuoLRwn+AfJ5AgU
         xs/UqPYk/9/Djj9VpvuDNM1l237uu4iWTWYuy6TuzKSKJWmUcZBpk979Uc52nXxhM4gg
         d/RuSNkTX8dxh4Wucea8fji3t0+fQtIFbrf4VCPSwZLTeuHKbmQMtaL77ARHg2UGv/4d
         9sNnKA1pj1C19HzHVHG3NzOjlyZrcLW/JZOWllQsxqWDOBaTdbD2qU88IS9GTWVJxQgB
         T4Jg==
X-Forwarded-Encrypted: i=1; AJvYcCVetJxF5daLIApfBxhQh/gro0bRaN8CEnxrbqJK7uJITXoxEgeVXNoCvpqLnYv2x6vdU41tUT+7Ar8=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzm7mWGq7KkaWE1NCBRMC3dclgxpmK506q4cBFKB6VdXf+p1UT7
	ZcYVPFQKZGyeqam9eQS8NQzwyscQLwlgCHWpG7nFy0SmR9E6xT0Uey8HjoWtKA==
X-Gm-Gg: ASbGnctgOsPh5sJWUmmDCIby+KQhFOXIbdEAqePzxI6fWDtoRU7Mrw2GkZa+eR+sfS5
	MxPjvHrR2VZKp4VrFOhXPavbPAd0Y4hZhSMAXhXuJrliDrXL/3tbZLdYoqBrVEjyDEZFG4UIKN9
	PlXVymmk7L/6RB2uqceTHayD6hf7xOme7rlfETXchjLQf14Zq+jOe7xJxxKZi1x7EShVXGKy4i6
	GV1Ja4Xwu0jVXVd0lAI7jvBO0QDpA/gtVa29oFvlbdsrloAejpBGGgAv1VqCyMZj6nzTc6wvilO
	SSOMEBGgOfGOU4Vea7DjLU8Rpva2uMfacXDvft9p+Q==
X-Google-Smtp-Source: AGHT+IGvoFT1TYXP+jF4uviKjArsdzgjKC/XtpYsjOqHZlLgt3z4fpgkbk7UHrIctiSwyWtK98vGuA==
X-Received: by 2002:a5d:47c4:0:b0:385:f892:c8fe with SMTP id ffacd0b85a97d-38a87306ddcmr30536352f8f.21.1736940454207;
        Wed, 15 Jan 2025 03:27:34 -0800 (PST)
Message-ID: <2658a15b-16dc-4953-97c0-94bec5283f10@suse.com>
Date: Wed, 15 Jan 2025 12:27:32 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] docs: Improve spelling of few cases in the documentation
To: Bernhard Kaindl <bernhard.kaindl@cloud.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Stefano Stabellini <sstabellini@kernel.org>,
 Ross Lagerwall <ross.lagerwall@citrix.com>
References: <504170a4a195551072c14141e28ef554ac1cad2c.1736937491.git.bernhard.kaindl@cloud.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <504170a4a195551072c14141e28ef554ac1cad2c.1736937491.git.bernhard.kaindl@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15.01.2025 11:42, Bernhard Kaindl wrote:
> --- a/docs/admin-guide/microcode-loading.rst
> +++ b/docs/admin-guide/microcode-loading.rst
> @@ -20,7 +20,7 @@ distro guidance for microcode loading.
>  Microcode can make almost arbitrary changes to the processor, including to
>  software visible features.  This includes removing features (e.g. the Haswell
>  TSX errata which necessitated disabling the feature entirely), or the addition
> -of brand new features (e.g. the Spectre v2 controls to work around speculative
> +of brand-new features (e.g. the Spectre v2 controls to work around speculative
>  execution vulnerabilities).

This having been written by a native speaker, I'm uncertain of the strict need
for a dash (also in one or two further places you touch).

> @@ -40,7 +40,7 @@ Xen will report during boot if it performed a microcode update::
>    (XEN) microcode: CPU6 updated from revision 0x1a to 0x25, date = 2018-04-02
>  
>  The exact details printed are system and microcode specific.  After boot, the
> -current microcode version can obtained from with dom0::
> +current microcode version can be obtained from with dom0::

Pretty certainly then also s/with/within/ ?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 11:37:15 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 11:37:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872343.1283300 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY1hu-0002CS-Oj; Wed, 15 Jan 2025 11:37:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872343.1283300; Wed, 15 Jan 2025 11:37:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY1hu-0002CL-LB; Wed, 15 Jan 2025 11:37:10 +0000
Received: by outflank-mailman (input) for mailman id 872343;
 Wed, 15 Jan 2025 11:37:09 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=AzvQ=UH=suse.de=tzimmermann@srs-se1.protection.inumbo.net>)
 id 1tY1ht-0002CF-5U
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 11:37:09 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0c8b71d8-d335-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 12:37:07 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id 5F4BA2128E;
 Wed, 15 Jan 2025 11:37:06 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 224B613A6F;
 Wed, 15 Jan 2025 11:37:05 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id ZKHjBuGdh2fsPAAAD6G6ig
 (envelope-from <tzimmermann@suse.de>); Wed, 15 Jan 2025 11:37:05 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 0c8b71d8-d335-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736941026; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=41xWq7JaLoV6WimVJ2B8CLfq711kNJtLM2yFKO4NnDE=;
	b=gue6OANAY5sQA5om7qd2aiBlXV4Er7BqteagVRDSWhaTKaDzwiKecLQ5J6ruJo1P1BUJte
	C6ziHtnVsFja8iX2g6jfIuTmYxNKhidEfMRQnEO+DQx5PPSyNWjtFfEgbufND/2GjuAngC
	xzbpdVr3u1o3wOw7USgSD8ebeUbf0Y8=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736941026;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=41xWq7JaLoV6WimVJ2B8CLfq711kNJtLM2yFKO4NnDE=;
	b=pBIzUrsOdWDvVqFMQ4+GGfQIAfVqufpdFuB8NrwD1Dec489JuoXPDm0qkn0XUzaFOp5Olp
	5dUOE9gHR+gf/OCw==
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.de header.s=susede2_rsa header.b=gue6OANA;
	dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=pBIzUrsO
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736941026; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=41xWq7JaLoV6WimVJ2B8CLfq711kNJtLM2yFKO4NnDE=;
	b=gue6OANAY5sQA5om7qd2aiBlXV4Er7BqteagVRDSWhaTKaDzwiKecLQ5J6ruJo1P1BUJte
	C6ziHtnVsFja8iX2g6jfIuTmYxNKhidEfMRQnEO+DQx5PPSyNWjtFfEgbufND/2GjuAngC
	xzbpdVr3u1o3wOw7USgSD8ebeUbf0Y8=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736941026;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=41xWq7JaLoV6WimVJ2B8CLfq711kNJtLM2yFKO4NnDE=;
	b=pBIzUrsOdWDvVqFMQ4+GGfQIAfVqufpdFuB8NrwD1Dec489JuoXPDm0qkn0XUzaFOp5Olp
	5dUOE9gHR+gf/OCw==
Message-ID: <c6735280-7c32-4319-8ca9-a7305d8117c3@suse.de>
Date: Wed, 15 Jan 2025 12:37:04 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with
 drm_mode_size_dumb()
To: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>,
 maarten.lankhorst@linux.intel.com, mripard@kernel.org, airlied@gmail.com,
 simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org, linux-mediatek@lists.infradead.org,
 freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
 imx@lists.linux.dev, linux-samsung-soc@vger.kernel.org,
 nouveau@lists.freedesktop.org, virtualization@lists.linux.dev,
 spice-devel@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org,
 linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org,
 intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org,
 Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
 Andy Yan <andyshrk@163.com>
References: <20250109150310.219442-1-tzimmermann@suse.de>
 <20250109150310.219442-26-tzimmermann@suse.de>
 <cdbe483d-0895-47aa-8c83-1c28220f4a02@ideasonboard.com>
 <bc97b92e-7f8a-4b92-af8a-20fa165ead55@suse.de>
 <f3ba05c7-6e49-4641-a3f9-ba418ebdb7c3@ideasonboard.com>
Content-Language: en-US
From: Thomas Zimmermann <tzimmermann@suse.de>
Autocrypt: addr=tzimmermann@suse.de; keydata=
 xsBNBFs50uABCADEHPidWt974CaxBVbrIBwqcq/WURinJ3+2WlIrKWspiP83vfZKaXhFYsdg
 XH47fDVbPPj+d6tQrw5lPQCyqjwrCPYnq3WlIBnGPJ4/jreTL6V+qfKRDlGLWFjZcsrPJGE0
 BeB5BbqP5erN1qylK9i3gPoQjXGhpBpQYwRrEyQyjuvk+Ev0K1Jc5tVDeJAuau3TGNgah4Yc
 hdHm3bkPjz9EErV85RwvImQ1dptvx6s7xzwXTgGAsaYZsL8WCwDaTuqFa1d1jjlaxg6+tZsB
 9GluwvIhSezPgnEmimZDkGnZRRSFiGP8yjqTjjWuf0bSj5rUnTGiyLyRZRNGcXmu6hjlABEB
 AAHNJ1Rob21hcyBaaW1tZXJtYW5uIDx0emltbWVybWFubkBzdXNlLmRlPsLAjgQTAQgAOAIb
 AwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftODH
 AAoJEGgNwR1TC3ojx1wH/0hKGWugiqDgLNXLRD/4TfHBEKmxIrmfu9Z5t7vwUKfwhFL6hqvo
 lXPJJKQpQ2z8+X2vZm/slsLn7J1yjrOsoJhKABDi+3QWWSGkaGwRJAdPVVyJMfJRNNNIKwVb
 U6B1BkX2XDKDGffF4TxlOpSQzdtNI/9gleOoUA8+jy8knnDYzjBNOZqLG2FuTdicBXblz0Mf
 vg41gd9kCwYXDnD91rJU8tzylXv03E75NCaTxTM+FBXPmsAVYQ4GYhhgFt8S2UWMoaaABLDe
 7l5FdnLdDEcbmd8uLU2CaG4W2cLrUaI4jz2XbkcPQkqTQ3EB67hYkjiEE6Zy3ggOitiQGcqp
 j//OwE0EWznS4AEIAMYmP4M/V+T5RY5at/g7rUdNsLhWv1APYrh9RQefODYHrNRHUE9eosYb
 T6XMryR9hT8XlGOYRwKWwiQBoWSDiTMo/Xi29jUnn4BXfI2px2DTXwc22LKtLAgTRjP+qbU6
 3Y0xnQN29UGDbYgyyK51DW3H0If2a3JNsheAAK+Xc9baj0LGIc8T9uiEWHBnCH+RdhgATnWW
 GKdDegUR5BkDfDg5O/FISymJBHx2Dyoklv5g4BzkgqTqwmaYzsl8UxZKvbaxq0zbehDda8lv
 hFXodNFMAgTLJlLuDYOGLK2AwbrS3Sp0AEbkpdJBb44qVlGm5bApZouHeJ/+n+7r12+lqdsA
 EQEAAcLAdgQYAQgAIAIbDBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftOH6AAoJEGgNwR1T
 C3ojVSkIALpAPkIJPQoURPb1VWjh34l0HlglmYHvZszJWTXYwavHR8+k6Baa6H7ufXNQtThR
 yIxJrQLW6rV5lm7TjhffEhxVCn37+cg0zZ3j7zIsSS0rx/aMwi6VhFJA5hfn3T0TtrijKP4A
 SAQO9xD1Zk9/61JWk8OysuIh7MXkl0fxbRKWE93XeQBhIJHQfnc+YBLprdnxR446Sh8Wn/2D
 Ya8cavuWf2zrB6cZurs048xe0UbSW5AOSo4V9M0jzYI4nZqTmPxYyXbm30Kvmz0rYVRaitYJ
 4kyYYMhuULvrJDMjZRvaNe52tkKAvMevcGdt38H4KSVXAylqyQOW5zvPc4/sq9c=
In-Reply-To: <f3ba05c7-6e49-4641-a3f9-ba418ebdb7c3@ideasonboard.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 5F4BA2128E
X-Spam-Level: 
X-Spamd-Result: default: False [-3.01 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_DKIM_ALLOW(-0.20)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[21];
	FREEMAIL_TO(0.00)[ideasonboard.com,linux.intel.com,kernel.org,gmail.com,ffwll.ch];
	MIME_TRACE(0.00)[0:+];
	SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FREEMAIL_ENVRCPT(0.00)[163.com,gmail.com];
	FREEMAIL_CC(0.00)[lists.freedesktop.org,lists.infradead.org,vger.kernel.org,lists.linux.dev,lists.xenproject.org,ideasonboard.com,163.com];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received];
	RCVD_TLS_ALL(0.00)[];
	DKIM_TRACE(0.00)[suse.de:+];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns,suse.de:dkim,suse.de:mid]
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Rspamd-Action: no action
X-Spam-Score: -3.01
X-Spam-Flag: NO

Hi


Am 15.01.25 um 11:58 schrieb Tomi Valkeinen:
[...]
>> These are all good points. Did you read my discussion with Andy on 
>> patch 2? I think it resolves all the points you have. The current 
>> CREATE_DUMB 
>
> I had missed the discussion, and, indeed, the patch you attached fixes 
> the problem on Xilinx.

Great. Thanks for testing.

>
>> ioctl is unsuited for anything but the simple RGB formats. The bpp 
>
> It's a bit difficult to use, but is it really unsuited? bitsperpixel, 
> width and height do give an exact pitch and size, do they not? It does 
> require the userspace to handle the subsampling and planes, though, so 
> far from perfect.

The bpp value sets the number of bits per pixel; except for bpp==15 
(XRGB1555), where it sets the color depth. OR bpp is the color depth; 
except for bpp==32 (XRGB8888), where it is the number of bits per pixel. 
It's therefore best to interpret it like a color-mode enum.

>
> So, I'm all for a new ioctl, but I don't right away see why the 
> current ioctl couldn't be used. Which makes me wonder about the 
> drm_warn() in your patch, and the "userspace throws in arbitrary 
> values for bpp and relies on the kernel to figure it out". Maybe I'm 
> missing something here.

I was unsure about the drm_warn() as well. It's not really wrong to have 
odd bpp values, but handing in an unknown bpp value might point to a 
user-space error. At least there should be a drm_dbg().

>
>> parameter is not very precise. The solution would be a new ioctl call 
>> that receives the DRM format and returns a buffer for each individual 
>> plane.
>
> Yes, I think that makes sense. That's a long road, though =). So my 
> question is, is CREATE_DUMB really unsuitable for other than simple 
> RGB formats, or can it be suitable if we just define how the userspace 
> should use it for multiplanar, subsampled formats?

That would duplicate format and hardware information in user-space. Some 
hardware might have odd per-plane limitations that only the driver knows 
about. For example, there's another discussion on dri-devel about 
pitch-alignment requirements of DRM_FORMAT_MOD_LINEAR on various 
hardware. That affects dumb buffers as well. I don't think that there's 
an immediate need for a CREATE_DUMB2, but it seems worth to keep in mind.

Best regards
Thomas

>
>  Tomi
>

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)



From xen-devel-bounces@lists.xenproject.org Wed Jan 15 12:01:49 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 12:01:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872360.1283322 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY25i-00072u-6R; Wed, 15 Jan 2025 12:01:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872360.1283322; Wed, 15 Jan 2025 12:01:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY25i-00072L-2t; Wed, 15 Jan 2025 12:01:46 +0000
Received: by outflank-mailman (input) for mailman id 872360;
 Wed, 15 Jan 2025 12:01: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
 <SRS0=/dV/=UH=bounce.vates.tech=bounce-md_30504962.6787a3a6.v1-459e1497e09c44cfaf7939bcbed7c19c@srs-se1.protection.inumbo.net>)
 id 1tY25g-0006sC-VV
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 12:01:44 +0000
Received: from mail178-22.suw51.mandrillapp.com
 (mail178-22.suw51.mandrillapp.com [198.2.178.22])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7cad6df2-d338-11ef-a0e1-8be0dac302b0;
 Wed, 15 Jan 2025 13:01:44 +0100 (CET)
Received: from pmta13.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail178-22.suw51.mandrillapp.com (Mailchimp) with ESMTP id
 4YY4NR08QSzGlswbx
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 12:01:43 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 459e1497e09c44cfaf7939bcbed7c19c; Wed, 15 Jan 2025 12:01:42 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 7cad6df2-d338-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1736942503; x=1737203003;
	bh=SJZqpLVK5lRKoNHTtQYPQ46S9ECIypf9UDo76kpZLus=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=mw6kFFBnMGCWsg0ygL6EDAnUpoS911v5IahgLuoMyUiHeN8KU2YWbeBWQku4vahgq
	 +wUNpDznywc5LD66Eyax1m5mL7zuygjBbquttnG5T5grCXldAQCektd462M0r1YWob
	 NUYS7RyXvEHXEtFAqezYTsSKkv6TFkaBt1mAseT2SE6qP1dG4v1AfX+M1thZgNN4EG
	 UMkTwpKUE/uHP02XHIE4+2tzuyULcSWMJXkcN5T9WIUAFmMoB/eQIMFxLQ1DKbO3IU
	 59Etup7c+Hthgmrb4tfYcmap6xdarLLVpabntXEN5AK1kSXonCI10vBhPP9+YYk24s
	 Mo2/902lBieSw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1736942503; x=1737203003; i=yann.dirson@vates.tech;
	bh=SJZqpLVK5lRKoNHTtQYPQ46S9ECIypf9UDo76kpZLus=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=fWzAbwF+vGT9aomHUOP1oRKcYAKKs4I+z3L/ISfVQm5wnW7ndrOdKI2E6NKZsWwSh
	 qM6ZG+Qernbb8/npQmlSkqqm4gLKljPEEJcsNjIgtjFbTp9WNbGqjHI8USzeb3hbCH
	 2EZlxB+maCOtv3j8Ewwc0WdiWlhNSigCsoGTPqhfviQRAMuiCepHAGt+c2Mn3xtdyY
	 kNSDsssINdKTbKRuSEq3CnIvJgA9YUfLvndICVItetpW2U9Xoh+Uz2Iis2P13IWOk4
	 KrBK1tJee/P0y6ey22Dt+ngXLJZMRfx/JbDaNHRRqEw+1WFwW5uiEgHswnV5O32j6K
	 FjClJgDbzLpvw==
From: "Yann Dirson" <yann.dirson@vates.tech>
Subject: =?utf-8?Q?[XEN=20PATCH=202/2]=20docs/sphinx:=20gitignore=20generated=20files?=
X-Mailer: git-send-email 2.39.5
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1736942499879
To: xen-devel@lists.xenproject.org
Cc: "Yann Dirson" <yann.dirson@vates.tech>, "Andrew Cooper" <andrew.cooper3@citrix.com>, "Anthony PERARD" <anthony.perard@vates.tech>, "Michal Orzel" <michal.orzel@amd.com>, "Jan Beulich" <jbeulich@suse.com>, "Julien Grall" <julien@xen.org>, "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>, "Stefano Stabellini" <sstabellini@kernel.org>
Message-Id: <cc6e4e8e5fe08c7b4bb183535b7e302bfba41058.1736941628.git.yann.dirson@vates.tech>
In-Reply-To: <cover.1736941628.git.yann.dirson@vates.tech>
References: <cover.1736941628.git.yann.dirson@vates.tech>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.459e1497e09c44cfaf7939bcbed7c19c?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250115:md
Date: Wed, 15 Jan 2025 12:01:42 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Signed-off-by: Yann Dirson <yann.dirson@vates.tech>
---
 .gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.gitignore b/.gitignore
index 25484a8fd8..404590c36a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -62,6 +62,7 @@ docs/man5/
 docs/man7/
 docs/man8/
 docs/pdf/
+docs/sphinx/
 docs/txt/
 extras/
 install/*
-- 
2.39.5



Yann Dirson | Vates Platform Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 12:01:49 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 12:01:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872358.1283309 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY25h-0006sa-L8; Wed, 15 Jan 2025 12:01:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872358.1283309; Wed, 15 Jan 2025 12:01:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY25h-0006sT-Ic; Wed, 15 Jan 2025 12:01:45 +0000
Received: by outflank-mailman (input) for mailman id 872358;
 Wed, 15 Jan 2025 12:01: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
 <SRS0=SrcS=UH=bounce.vates.tech=bounce-md_30504962.6787a3a4.v1-2b7afc3f0d0a4991a2d3cb57dfff2308@srs-se1.protection.inumbo.net>)
 id 1tY25g-0006sD-Av
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 12:01:44 +0000
Received: from mail178-22.suw51.mandrillapp.com
 (mail178-22.suw51.mandrillapp.com [198.2.178.22])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7b6a374b-d338-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 13:01:42 +0100 (CET)
Received: from pmta13.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail178-22.suw51.mandrillapp.com (Mailchimp) with ESMTP id
 4YY4NN49wjzGlsvph
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 12:01:40 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 2b7afc3f0d0a4991a2d3cb57dfff2308; Wed, 15 Jan 2025 12:01:40 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 7b6a374b-d338-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1736942500; x=1737203000;
	bh=dT6H1d3lSfM7i3eONNGGvJiawvNhcMTrSJaz4H8aMWY=;
	h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version:
	 Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From;
	b=Sgc22EjKIX9FTWzI+3UWNKgg+Wm3TXhi7MSl6ZNK13unT2T1ATGPcdT2ZW8sVC4Gt
	 +TsooqOwyA8plnW33vIZ6VShKdLg3r/kw4nVbulQLBJD8SShmk1pPFHp0kVf6p9EIG
	 1y/sWB7egdMR7dZZL8y56BHCg17uCVZXYT+8Esm1kLmMC+LQFu+blKkGIIPCFVHVQ4
	 SkJlOEu412zT489XhhA6layrFFVlrUPvQDlbMWx+QNPh08WyKvi5+W4cunZn7AZ3be
	 vgUtTt8qnP7WRgbwIZFKgk4mahCn/Y1QDvPppCo92F45VeNweWocAdzIQDo5zMiTiS
	 ohTO5FqarwwVw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1736942500; x=1737203000; i=yann.dirson@vates.tech;
	bh=dT6H1d3lSfM7i3eONNGGvJiawvNhcMTrSJaz4H8aMWY=;
	h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version:
	 Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From;
	b=kMGS9TPx2qV8m34dW4GZLWAXy3atoejhrtE3bxei6O/ojBHrSbN1W2Os0gjoCGTPE
	 mr9RJ6+b/3/9RWiCURpXyEtKEK6e2IPeHmRiiXPQNWZ2DHAGX6LrJukGJsDJz+bLiF
	 H/Qsip6eztTFaRd4dGMoogckf8MvcgCRT38z8iqNW7tiSsQZDROaKud7EskjeNuUXG
	 6koHgRwy2Npj6nQzDAqTCQhaKJLGSt+D3noCfZ/L53f3IwjRU9zH8Lo6vkNdiVQUrb
	 UYumCVxaAXoY9bjpFHwI/kew2Fj/84Ojwyj+VIjJHkgkkhvA5txpPAz70JAqF28Pp7
	 NVzyJmLU9UjdA==
From: "Yann Dirson" <yann.dirson@vates.tech>
Subject: =?utf-8?Q?[XEN=20PATCH=200/2]=20trivial=20improvements=20to=20sphinx=20doc=20tooling?=
X-Mailer: git-send-email 2.39.5
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1736942499221
To: xen-devel@lists.xenproject.org
Cc: "Yann Dirson" <yann.dirson@vates.tech>, "Andrew Cooper" <andrew.cooper3@citrix.com>, "Anthony PERARD" <anthony.perard@vates.tech>, "Michal Orzel" <michal.orzel@amd.com>, "Jan Beulich" <jbeulich@suse.com>, "Julien Grall" <julien@xen.org>, "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>, "Stefano Stabellini" <sstabellini@kernel.org>
Message-Id: <cover.1736941628.git.yann.dirson@vates.tech>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.2b7afc3f0d0a4991a2d3cb57dfff2308?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250115:md
Date: Wed, 15 Jan 2025 12:01:40 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Yann Dirson (2):
  docs/sphinx: import sys for error reporting
  docs/sphinx: gitignore generated files

 .gitignore   | 1 +
 docs/conf.py | 1 +
 2 files changed, 2 insertions(+)

-- 
2.39.5



Yann Dirson | Vates Platform Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 12:01:49 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 12:01:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872359.1283316 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY25h-0006up-VB; Wed, 15 Jan 2025 12:01:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872359.1283316; Wed, 15 Jan 2025 12:01:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY25h-0006ty-PH; Wed, 15 Jan 2025 12:01:45 +0000
Received: by outflank-mailman (input) for mailman id 872359;
 Wed, 15 Jan 2025 12:01:44 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=upcn=UH=bounce.vates.tech=bounce-md_30504962.6787a3a4.v1-a36f03077cb44856beaf73225104620f@srs-se1.protection.inumbo.net>)
 id 1tY25g-0006sC-Ak
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 12:01:44 +0000
Received: from mail128-16.atl41.mandrillapp.com
 (mail128-16.atl41.mandrillapp.com [198.2.128.16])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7bdbe9bc-d338-11ef-a0e1-8be0dac302b0;
 Wed, 15 Jan 2025 13:01:42 +0100 (CET)
Received: from pmta08.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail128-16.atl41.mandrillapp.com (Mailchimp) with ESMTP id
 4YY4NN5TR7zRKLkSQ
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 12:01:40 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 a36f03077cb44856beaf73225104620f; Wed, 15 Jan 2025 12:01:40 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 7bdbe9bc-d338-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1736942500; x=1737203000;
	bh=Db/LuC4xapSUnG1ySxTlxVaodR1FXGRDI/gyqoUcYJg=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=VZHBEuProRzYC2QYTcXH+HHo7NwPzXVj9CuxOuSAnmyMxbawdk+UeIVKB1wz9ajCB
	 w11bOJUYZwfPTGw/YPYHzkYWHazSRcbux8Wap3CZuSyw8iFJ3yicKjpHhQhwOLduEP
	 jpaXoAne/rUxZl3q3lhZLkF7rcI+5Z0mGsWsr2bSqyZOqUg73sWiGmbhN73IUVT7aa
	 hbiVhE4xChYKdIl5tRrTd69P679hGyKRk+G3zWuBmHclW/X1qpEqm6Wk/13bIH0f1z
	 +n2d+y2C0qGz8wj5Je66ARrQNxHzz6LNBJUCcpZLOdbNZb+zbed8ei/Kl8LqzgsEa6
	 2MQRk9v0TdE/Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1736942500; x=1737203000; i=yann.dirson@vates.tech;
	bh=Db/LuC4xapSUnG1ySxTlxVaodR1FXGRDI/gyqoUcYJg=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=eoSdnuly8aFsDQF7mq5BYEmJDw0iZ7uk8GGaPApZ2p4SsBOY/RFaWqC1qIQhOBGrK
	 5nh2YN89ZYdWuP9OT7+7fw0hc9+NTSCLGQehyXiHyLLKeYXGcLIO6WhJE54hwuDq69
	 s87qnsFX8OwfQCmK1o79OrM0XtNLPEViHJ3kSMaYlATjN7An7NJy4Ju0jVds2R3/Sx
	 w2Yj/94b9BaQ7WhElKjuAsNUHvzB4mC9An1KTO8kKyklrQpr3+QgqxR+9RIuz35aGw
	 UcGNXoZctrraPeLpHJtLSVV2nPwMM22Sog9ZkZoozhSBm7keuZgWCu+5aQv32JHnHx
	 DaYg1oAz9Z9Gg==
From: "Yann Dirson" <yann.dirson@vates.tech>
Subject: =?utf-8?Q?[XEN=20PATCH=201/2]=20docs/sphinx:=20import=20sys=20for=20error=20reporting?=
X-Mailer: git-send-email 2.39.5
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1736942499555
To: xen-devel@lists.xenproject.org
Cc: "Yann Dirson" <yann.dirson@vates.tech>, "Andrew Cooper" <andrew.cooper3@citrix.com>, "Anthony PERARD" <anthony.perard@vates.tech>, "Michal Orzel" <michal.orzel@amd.com>, "Jan Beulich" <jbeulich@suse.com>, "Julien Grall" <julien@xen.org>, "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>, "Stefano Stabellini" <sstabellini@kernel.org>
Message-Id: <4b7de1b9a5b0eec8cb1803e59b0027092c43c126.1736941628.git.yann.dirson@vates.tech>
In-Reply-To: <cover.1736941628.git.yann.dirson@vates.tech>
References: <cover.1736941628.git.yann.dirson@vates.tech>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.a36f03077cb44856beaf73225104620f?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250115:md
Date: Wed, 15 Jan 2025 12:01:40 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Signed-off-by: Yann Dirson <yann.dirson@vates.tech>
---
 docs/conf.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/docs/conf.py b/docs/conf.py
index 5d2e979449..84bec024e7 100644
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -21,6 +21,7 @@
 # https://www.sphinx-doc.org/en/master/usage/configuration.html#project-information
 
 import sphinx
+import sys
 
 project = u'Xen'
 copyright = u'2019-%Y, The Xen development community'
-- 
2.39.5



Yann Dirson | Vates Platform Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 12:03:33 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 12:03:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872379.1283341 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY27Q-0008OY-J9; Wed, 15 Jan 2025 12:03:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872379.1283341; Wed, 15 Jan 2025 12:03:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY27Q-0008OR-EA; Wed, 15 Jan 2025 12:03:32 +0000
Received: by outflank-mailman (input) for mailman id 872379;
 Wed, 15 Jan 2025 12:03:31 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=hmQ5=UH=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tY27P-0008OL-3D
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 12:03:31 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bc1b8e0f-d338-11ef-a0e1-8be0dac302b0;
 Wed, 15 Jan 2025 13:03:30 +0100 (CET)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-aafc9d75f8bso1257976266b.2
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 04:03:30 -0800 (PST)
Received: from [10.81.35.177] ([46.149.103.11])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab33d6254ffsm184939966b.6.2025.01.15.04.03.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 15 Jan 2025 04:03:26 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: bc1b8e0f-d338-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736942609; x=1737547409; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=oMdOmaOjPflgDDMUOURG61lsCfEO1OuZP7nTavK4yu0=;
        b=my91PUnS26QML+KTK6GJbiZB6Z6jslPKoevvfD9XVJq8HrLrDrtiH5dXHivkSE8HpL
         UA/bOAT0nO/twK6u4mkaJn6umJsWgBAKRq7bemevDPHrNDBT6/Kw9P5e1Q6Bdk/nPro6
         ByorVB7gDzRSPmPPGvhFrjO9CCI3C+6jTUBOc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736942609; x=1737547409;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=oMdOmaOjPflgDDMUOURG61lsCfEO1OuZP7nTavK4yu0=;
        b=vLxCvEfyWqmGshnlGzerkf86YTTaCJxSL28cRsNOQh/PNIrhVtV++bS0k1Rs80HGWu
         +nZDGq4pajc950TSFtGlL3UeTJUvLZvv9DlvYzX3utWATQrJQHnsIH03pEzEMUqI6wHZ
         8IOYQ/dSz6TaIDgyRcXOemrc8GRy43IxsNgSKfhTm2peMwN5sKhZ5qd9jxX3Nllny/Nm
         R6J3PjpQG2woLsJ9nAld/ozPDVHP3YU0ZQGdirQRtL0sHxl4wffvksRLwJL1DT4wBvvR
         pUFVrOmKW2rMz80qmZh+seRDHes1oqhgeSiiyR9HNtNmqzOjjHrfCFHY3uOb0hJfTznC
         IcqQ==
X-Forwarded-Encrypted: i=1; AJvYcCWPXJqsvHAfzgLE6OvIe7X9uMScJcB0/1KYT2XnMY3IGQykdnsl+pS+EA2liTixjYHWNamY1Toq7v4=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy/+E6AE+IBM7XQpXR0fuOLSpHMyLGwpmgBGWpQ/pXMnmd6Z36t
	xPyWNSK3SSI5ILbHfC6xigVnj1k+fr2c8kC0uAeP/pI1g27tZ6tqW1vpJTv3RnA=
X-Gm-Gg: ASbGncvfFA7SQ/cuYFMfxO8UlD/EuE7E8wykg0f32bh93NE+oN3aQiR8BLj98CrYzXp
	JKPCYnydTaEPZC815BF7kcGWUwgsunaOF2psML0N88YbWIcotRb4s7kJCWVyGZk6RoPhYTR1/Vz
	yleNI+rIOAM3ZjJ2vcK/wiw4HP+h9sQoPjnTdXanvKpX26gsicfPu1w6YUjvfXLtcaB0U81acaW
	oF22LAriXANELFHa9Esa2S4kqDllej2yQQl+pkpeR7mleMBsaopJpph6HRAxBRtpGc=
X-Google-Smtp-Source: AGHT+IEv1zTUXDm95B/lXkAxOHGy1GFixgbas1bls0SsG65khNtsFLCMNbtvt3yUTamHmir7DqLmkg==
X-Received: by 2002:a17:907:36c8:b0:aa6:4494:e354 with SMTP id a640c23a62f3a-ab2abc92570mr2928342866b.42.1736942606745;
        Wed, 15 Jan 2025 04:03:26 -0800 (PST)
Message-ID: <b3d8bdf3-96ee-418a-b053-355138a71564@citrix.com>
Date: Wed, 15 Jan 2025 12:03:25 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] docs: Improve spelling of few cases in the documentation
To: Jan Beulich <jbeulich@suse.com>,
 Bernhard Kaindl <bernhard.kaindl@cloud.com>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Stefano Stabellini <sstabellini@kernel.org>,
 Ross Lagerwall <ross.lagerwall@citrix.com>
References: <504170a4a195551072c14141e28ef554ac1cad2c.1736937491.git.bernhard.kaindl@cloud.com>
 <2658a15b-16dc-4953-97c0-94bec5283f10@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <2658a15b-16dc-4953-97c0-94bec5283f10@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 15/01/2025 11:27 am, Jan Beulich wrote:
> On 15.01.2025 11:42, Bernhard Kaindl wrote:
>> --- a/docs/admin-guide/microcode-loading.rst
>> +++ b/docs/admin-guide/microcode-loading.rst
>> @@ -20,7 +20,7 @@ distro guidance for microcode loading.
>>  Microcode can make almost arbitrary changes to the processor, including to
>>  software visible features.  This includes removing features (e.g. the Haswell
>>  TSX errata which necessitated disabling the feature entirely), or the addition
>> -of brand new features (e.g. the Spectre v2 controls to work around speculative
>> +of brand-new features (e.g. the Spectre v2 controls to work around speculative
>>  execution vulnerabilities).
> This having been written by a native speaker, I'm uncertain of the strict need
> for a dash (also in one or two further places you touch).

Both are fine, but without a dash is more common.  I'd leave it as it was.

>
>> @@ -40,7 +40,7 @@ Xen will report during boot if it performed a microcode update::
>>    (XEN) microcode: CPU6 updated from revision 0x1a to 0x25, date = 2018-04-02
>>  
>>  The exact details printed are system and microcode specific.  After boot, the
>> -current microcode version can obtained from with dom0::
>> +current microcode version can be obtained from with dom0::
> Pretty certainly then also s/with/within/ ?

Oh, this is slightly stale now we print the BSP microcode version on
boot, and also since xen-ucode can be used to find the revision.

I'll do a larger update to this paragraph, including both fixes on this
line.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 12:06:30 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 12:06:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872390.1283350 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY2AG-0000Yi-UL; Wed, 15 Jan 2025 12:06:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872390.1283350; Wed, 15 Jan 2025 12:06:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY2AG-0000Yb-RX; Wed, 15 Jan 2025 12:06:28 +0000
Received: by outflank-mailman (input) for mailman id 872390;
 Wed, 15 Jan 2025 12:06:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=MxfB=UH=ideasonboard.com=tomi.valkeinen@srs-se1.protection.inumbo.net>)
 id 1tY2AG-0000YV-De
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 12:06:28 +0000
Received: from perceval.ideasonboard.com (perceval.ideasonboard.com
 [213.167.242.64]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 25adc8fb-d339-11ef-a0e1-8be0dac302b0;
 Wed, 15 Jan 2025 13:06:27 +0100 (CET)
Received: from [192.168.88.20] (91-158-153-178.elisa-laajakaista.fi
 [91.158.153.178])
 by perceval.ideasonboard.com (Postfix) with ESMTPSA id 72820526;
 Wed, 15 Jan 2025 13:05:27 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 25adc8fb-d339-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;
	s=mail; t=1736942728;
	bh=FuDytT435iHRivsE/G04kLqYkdgsyGU+ZJ0WGc8aFpo=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=hIJC7ZXPZtRflk6LODVFXfISeh41qkSpg6phZpn+jJNh/hs7pxM5vBSXBXByWBzS8
	 LX7kPPllqXqVJXAFomHjs+y2IACUieKV5ZLUGSlreuMdvgLHTwTHVy0dYbnXKnxipV
	 qOeqzpf4NDSnnVcvegNZjPfUH6Ys4KcU5utGuoQo=
Message-ID: <d67adb03-5cd0-4ac9-af58-cf4446dacee3@ideasonboard.com>
Date: Wed, 15 Jan 2025 14:06:22 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with
 drm_mode_size_dumb()
To: Thomas Zimmermann <tzimmermann@suse.de>,
 maarten.lankhorst@linux.intel.com, mripard@kernel.org, airlied@gmail.com,
 simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org, linux-mediatek@lists.infradead.org,
 freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
 imx@lists.linux.dev, linux-samsung-soc@vger.kernel.org,
 nouveau@lists.freedesktop.org, virtualization@lists.linux.dev,
 spice-devel@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org,
 linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org,
 intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org,
 Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
 Andy Yan <andyshrk@163.com>
References: <20250109150310.219442-1-tzimmermann@suse.de>
 <20250109150310.219442-26-tzimmermann@suse.de>
 <cdbe483d-0895-47aa-8c83-1c28220f4a02@ideasonboard.com>
 <bc97b92e-7f8a-4b92-af8a-20fa165ead55@suse.de>
 <f3ba05c7-6e49-4641-a3f9-ba418ebdb7c3@ideasonboard.com>
 <c6735280-7c32-4319-8ca9-a7305d8117c3@suse.de>
Content-Language: en-US
From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Autocrypt: addr=tomi.valkeinen@ideasonboard.com; keydata=
 xsFNBE6ms0cBEACyizowecZqXfMZtnBniOieTuFdErHAUyxVgtmr0f5ZfIi9Z4l+uUN4Zdw2
 wCEZjx3o0Z34diXBaMRJ3rAk9yB90UJAnLtb8A97Oq64DskLF81GCYB2P1i0qrG7UjpASgCA
 Ru0lVvxsWyIwSfoYoLrazbT1wkWRs8YBkkXQFfL7Mn3ZMoGPcpfwYH9O7bV1NslbmyJzRCMO
 eYV258gjCcwYlrkyIratlHCek4GrwV8Z9NQcjD5iLzrONjfafrWPwj6yn2RlL0mQEwt1lOvn
 LnI7QRtB3zxA3yB+FLsT1hx0va6xCHpX3QO2gBsyHCyVafFMrg3c/7IIWkDLngJxFgz6DLiA
 G4ld1QK/jsYqfP2GIMH1mFdjY+iagG4DqOsjip479HCWAptpNxSOCL6z3qxCU8MCz8iNOtZk
 DYXQWVscM5qgYSn+fmMM2qN+eoWlnCGVURZZLDjg387S2E1jT/dNTOsM/IqQj+ZROUZuRcF7
 0RTtuU5q1HnbRNwy+23xeoSGuwmLQ2UsUk7Q5CnrjYfiPo3wHze8avK95JBoSd+WIRmV3uoO
 rXCoYOIRlDhg9XJTrbnQ3Ot5zOa0Y9c4IpyAlut6mDtxtKXr4+8OzjSVFww7tIwadTK3wDQv
 Bus4jxHjS6dz1g2ypT65qnHen6mUUH63lhzewqO9peAHJ0SLrQARAQABzTBUb21pIFZhbGtl
 aW5lbiA8dG9taS52YWxrZWluZW5AaWRlYXNvbmJvYXJkLmNvbT7CwY4EEwEIADgWIQTEOAw+
 ll79gQef86f6PaqMvJYe9QUCX/HruAIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRD6
 PaqMvJYe9WmFD/99NGoD5lBJhlFDHMZvO+Op8vCwnIRZdTsyrtGl72rVh9xRfcSgYPZUvBuT
 VDxE53mY9HaZyu1eGMccYRBaTLJSfCXl/g317CrMNdY0k40b9YeIX10feiRYEWoDIPQ3tMmA
 0nHDygzcnuPiPT68JYZ6tUOvAt7r6OX/litM+m2/E9mtp8xCoWOo/kYO4mOAIoMNvLB8vufi
 uBB4e/AvAjtny4ScuNV5c5q8MkfNIiOyag9QCiQ/JfoAqzXRjVb4VZG72AKaElwipiKCWEcU
 R4+Bu5Qbaxj7Cd36M/bI54OrbWWETJkVVSV1i0tghCd6HHyquTdFl7wYcz6cL1hn/6byVnD+
 sR3BLvSBHYp8WSwv0TCuf6tLiNgHAO1hWiQ1pOoXyMEsxZlgPXT+wb4dbNVunckwqFjGxRbl
 Rz7apFT/ZRwbazEzEzNyrBOfB55xdipG/2+SmFn0oMFqFOBEszXLQVslh64lI0CMJm2OYYe3
 PxHqYaztyeXsx13Bfnq9+bUynAQ4uW1P5DJ3OIRZWKmbQd/Me3Fq6TU57LsvwRgE0Le9PFQs
 dcP2071rMTpqTUteEgODJS4VDf4lXJfY91u32BJkiqM7/62Cqatcz5UWWHq5xeF03MIUTqdE
 qHWk3RJEoWHWQRzQfcx6Fn2fDAUKhAddvoopfcjAHfpAWJ+ENc7BTQROprNHARAAx0aat8GU
 hsusCLc4MIxOQwidecCTRc9Dz/7U2goUwhw2O5j9TPqLtp57VITmHILnvZf6q3QAho2QMQyE
 DDvHubrdtEoqaaSKxKkFie1uhWNNvXPhwkKLYieyL9m2JdU+b88HaDnpzdyTTR4uH7wk0bBa
 KbTSgIFDDe5lXInypewPO30TmYNkFSexnnM3n1PBCqiJXsJahE4ZQ+WnV5FbPUj8T2zXS2xk
 0LZ0+DwKmZ0ZDovvdEWRWrz3UzJ8DLHb7blPpGhmqj3ANXQXC7mb9qJ6J/VSl61GbxIO2Dwb
 xPNkHk8fwnxlUBCOyBti/uD2uSTgKHNdabhVm2dgFNVuS1y3bBHbI/qjC3J7rWE0WiaHWEqy
 UVPk8rsph4rqITsj2RiY70vEW0SKePrChvET7D8P1UPqmveBNNtSS7In+DdZ5kUqLV7rJnM9
 /4cwy+uZUt8cuCZlcA5u8IsBCNJudxEqBG10GHg1B6h1RZIz9Q9XfiBdaqa5+CjyFs8ua01c
 9HmyfkuhXG2OLjfQuK+Ygd56mV3lq0aFdwbaX16DG22c6flkkBSjyWXYepFtHz9KsBS0DaZb
 4IkLmZwEXpZcIOQjQ71fqlpiXkXSIaQ6YMEs8WjBbpP81h7QxWIfWtp+VnwNGc6nq5IQDESH
 mvQcsFS7d3eGVI6eyjCFdcAO8eMAEQEAAcLBXwQYAQIACQUCTqazRwIbDAAKCRD6PaqMvJYe
 9fA7EACS6exUedsBKmt4pT7nqXBcRsqm6YzT6DeCM8PWMTeaVGHiR4TnNFiT3otD5UpYQI7S
 suYxoTdHrrrBzdlKe5rUWpzoZkVK6p0s9OIvGzLT0lrb0HC9iNDWT3JgpYDnk4Z2mFi6tTbq
 xKMtpVFRA6FjviGDRsfkfoURZI51nf2RSAk/A8BEDDZ7lgJHskYoklSpwyrXhkp9FHGMaYII
 m9EKuUTX9JPDG2FTthCBrdsgWYPdJQvM+zscq09vFMQ9Fykbx5N8z/oFEUy3ACyPqW2oyfvU
 CH5WDpWBG0s5BALp1gBJPytIAd/pY/5ZdNoi0Cx3+Z7jaBFEyYJdWy1hGddpkgnMjyOfLI7B
 CFrdecTZbR5upjNSDvQ7RG85SnpYJTIin+SAUazAeA2nS6gTZzumgtdw8XmVXZwdBfF+ICof
 92UkbYcYNbzWO/GHgsNT1WnM4sa9lwCSWH8Fw1o/3bX1VVPEsnESOfxkNdu+gAF5S6+I6n3a
 ueeIlwJl5CpT5l8RpoZXEOVtXYn8zzOJ7oGZYINRV9Pf8qKGLf3Dft7zKBP832I3PQjeok7F
 yjt+9S+KgSFSHP3Pa4E7lsSdWhSlHYNdG/czhoUkSCN09C0rEK93wxACx3vtxPLjXu6RptBw
 3dRq7n+mQChEB1am0BueV1JZaBboIL0AGlSJkm23kw==
In-Reply-To: <c6735280-7c32-4319-8ca9-a7305d8117c3@suse.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

On 15/01/2025 13:37, Thomas Zimmermann wrote:
> Hi
> 
> 
> Am 15.01.25 um 11:58 schrieb Tomi Valkeinen:
> [...]
>>> These are all good points. Did you read my discussion with Andy on 
>>> patch 2? I think it resolves all the points you have. The current 
>>> CREATE_DUMB 
>>
>> I had missed the discussion, and, indeed, the patch you attached fixes 
>> the problem on Xilinx.
> 
> Great. Thanks for testing.
> 
>>
>>> ioctl is unsuited for anything but the simple RGB formats. The bpp 
>>
>> It's a bit difficult to use, but is it really unsuited? bitsperpixel, 
>> width and height do give an exact pitch and size, do they not? It does 
>> require the userspace to handle the subsampling and planes, though, so 
>> far from perfect.
> 
> The bpp value sets the number of bits per pixel; except for bpp==15 
> (XRGB1555), where it sets the color depth. OR bpp is the color depth; 
> except for bpp==32 (XRGB8888), where it is the number of bits per pixel. 
> It's therefore best to interpret it like a color-mode enum.

Ah, right... That's horrible =).

And I assume it's not really possible to define the bpp to mean bits per 
pixel, except for a few special cases like 15?

Why do we even really care about color depth here? We're just allocating 
memory. Doesn't DIV_ROUND_UP(args->bpp, SZ_8) work fine for XRGB1555 too?

>> So, I'm all for a new ioctl, but I don't right away see why the 
>> current ioctl couldn't be used. Which makes me wonder about the 
>> drm_warn() in your patch, and the "userspace throws in arbitrary 
>> values for bpp and relies on the kernel to figure it out". Maybe I'm 
>> missing something here.
> 
> I was unsure about the drm_warn() as well. It's not really wrong to have 
> odd bpp values, but handing in an unknown bpp value might point to a 
> user-space error. At least there should be a drm_dbg().
> 
>>
>>> parameter is not very precise. The solution would be a new ioctl call 
>>> that receives the DRM format and returns a buffer for each individual 
>>> plane.
>>
>> Yes, I think that makes sense. That's a long road, though =). So my 
>> question is, is CREATE_DUMB really unsuitable for other than simple 
>> RGB formats, or can it be suitable if we just define how the userspace 
>> should use it for multiplanar, subsampled formats?
> 
> That would duplicate format and hardware information in user-space. Some 

But we already have that, don't we? We have drivers and userspace that 
support, say, NV12 via dumb buffers. But (correct me if I'm wrong) we 
don't document how CREATE_DUMB has to be used to allocate multiplanar 
subsampled buffers, so the userspace devs have to "guess".

> hardware might have odd per-plane limitations that only the driver knows 
> about. For example, there's another discussion on dri-devel about pitch- 
> alignment requirements of DRM_FORMAT_MOD_LINEAR on various hardware. 
> That affects dumb buffers as well. I don't think that there's an 
> immediate need for a CREATE_DUMB2, but it seems worth to keep in mind.

Yes, the current CREATE_DUMB can't cover all the hardware. We do need 
CREATE_DUMB2, sooner or later. I just hope we can define and document a 
set of rules that allows using CREATE_DUMB for the cases where it 
sensibly works (and is already being used).

  Tomi



From xen-devel-bounces@lists.xenproject.org Wed Jan 15 12:07:26 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 12:07:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872400.1283360 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY2B8-00018W-8y; Wed, 15 Jan 2025 12:07:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872400.1283360; Wed, 15 Jan 2025 12:07:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY2B8-00018P-6O; Wed, 15 Jan 2025 12:07:22 +0000
Received: by outflank-mailman (input) for mailman id 872400;
 Wed, 15 Jan 2025 12:07:21 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=YH9L=UH=bounce.vates.tech=bounce-md_30504962.6787a4f6.v1-0d89a930d31f4b1bad54b7c4cf30f140@srs-se1.protection.inumbo.net>)
 id 1tY2B7-00017y-6q
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 12:07:21 +0000
Received: from mail128-16.atl41.mandrillapp.com
 (mail128-16.atl41.mandrillapp.com [198.2.128.16])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 44d890eb-d339-11ef-a0e1-8be0dac302b0;
 Wed, 15 Jan 2025 13:07:20 +0100 (CET)
Received: from pmta08.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail128-16.atl41.mandrillapp.com (Mailchimp) with ESMTP id
 4YY4Vt60fKzRKLfTN
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 12:07:18 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 0d89a930d31f4b1bad54b7c4cf30f140; Wed, 15 Jan 2025 12:07:18 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 44d890eb-d339-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1736942838; x=1737203338;
	bh=s0FW0PEvsl3YOTChC3rgiB7tdBYKznuK7W4tmzXbvNM=;
	h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version:
	 Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From;
	b=HwwFtq8Dg9/YJabp+q0zIOFVFwrmp4ptGIU6WqR5KPwQPH6p3qyy5HNBffVnvKZYb
	 Mht4z6r3T0uu9hZPF24KD9XQDtXEZ01brMe31Nf9+NJsf62XReqFcUI6ADRYyQ02WN
	 302O7TSNPZq3YnkOZwWYQ530IBCWxFNLO9ui/8wvg1kebzi8cEcm4lexMZ5ZSyPeEX
	 f27I+82N4e2iX4ePIY+bpQdAHNgB3eTmyCEfzOOWUq3IkG7l78wb8ju/3nLru86u3k
	 fmb/nDQaof8KrIlt45Y8A2q/9Pz4E3Waw/g+BGZA6lNB4pNrdCA1gzrTcAE42lP1XD
	 t0NmLQHypa8vQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1736942838; x=1737203338; i=yann.dirson@vates.tech;
	bh=s0FW0PEvsl3YOTChC3rgiB7tdBYKznuK7W4tmzXbvNM=;
	h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version:
	 Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From;
	b=1qwgkbPjH34P5/nWBpK3IXYJI9iRqx66XtaYXz31s2NjaP5DArUgAnUGJe/4MVfQI
	 6BO+A1lUmpsKEDBsO9c8+ud9bfjlVURkugNEIadZdCoOiAWCvi8C+nlJprOgYpjDzO
	 KbUcV1XUn3UOinsf8yLRSBveZ9880Vv6MjnNPkKR3CefFFf7Fif1S0MnXZ4RiHTUZh
	 NdB5Z60HfOHhSVmxxCJ7iDwuRFHQ6t+YTlUQlJB3BvAq8adMR57lCiq4PViliXiMlI
	 pBIWibjmBJwHAkbX3P0tqOgkKFmISYyk32HxOwVVabTuNmmEzJ1Cnr6E1qs/Zeaoo+
	 Uy/FbzSIP6w2Q==
From: "Yann Dirson" <yann.dirson@vates.tech>
Subject: =?utf-8?Q?[XEN=20PATCH]=20docs/sphinx:=20overview=20of=20serial=20consoles?=
X-Mailer: git-send-email 2.39.5
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1736942837465
To: xen-devel@lists.xenproject.org
Cc: "Yann Dirson" <yann.dirson@vates.tech>, "Andrew Cooper" <andrew.cooper3@citrix.com>, "Anthony PERARD" <anthony.perard@vates.tech>, "Michal Orzel" <michal.orzel@amd.com>, "Jan Beulich" <jbeulich@suse.com>, "Julien Grall" <julien@xen.org>, "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>, "Stefano Stabellini" <sstabellini@kernel.org>
Message-Id: <d40643bf0730c2f227f2dfbc7985ba0b5f8878cf.1736942790.git.yann.dirson@vates.tech>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.0d89a930d31f4b1bad54b7c4cf30f140?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250115:md
Date: Wed, 15 Jan 2025 12:07:18 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

---

Notes:
    This is a very preliminar first draft for comments:
    
    - would this structuration be adequate?
    
    - Is my basic understanding correct, are those first enumerations
    correct? (some of it come solely from console.txt, which has already
    proven to be seriously outdated on many aspects)
    
    - is there some doc about the qemu/ioemu backend I missed?  Is it able to
    deal with PV consoles, or is it just for virtual UARTS?

 docs/admin-guide/console.rst | 37 ++++++++++++++++++++++++++++++++++++
 docs/admin-guide/index.rst   |  1 +
 2 files changed, 38 insertions(+)
 create mode 100644 docs/admin-guide/console.rst

diff --git a/docs/admin-guide/console.rst b/docs/admin-guide/console.rst
new file mode 100644
index 0000000000..7f82a368f9
--- /dev/null
+++ b/docs/admin-guide/console.rst
@@ -0,0 +1,37 @@
+.. SPDX-License-Identifier: CC-BY-4.0
+
+Xen console
+===========
+
+Overview
+--------
+
+Xen provides several alternatives to provide the functionality of a
+real machine's serial console, which are seen by the guest as one of:
+
+* PV consoles (``/dev/hvc$N`` in a Linux guest)
+* Virtual SBSA UART (on ARM only?, ``/dev/ttyAMA0`` in a Linux guest)
+
+In dom0, different backends can be used to communicate with those
+guest devices:
+
+* xenconsoled: a ``xenconsoled`` daemon in dom0 takes are of the
+  communication with the guest driver, and provides a pty interface.
+  The ``xenconsole`` tool can be used to connect to this pty.
+  Limitation: can only be used for the first PV or virtual UART
+  console.
+* qemu? ioemu?: FIXME: describe
+
+Configuration
+-------------
+
+TBW
+
+Gory details
+------------
+
+While not strictly useful for administration of a Xen machine, some
+xenstore entries internal to the toolstack are visible, intermingled
+with usual dom0/guest communication.
+
+TBW
diff --git a/docs/admin-guide/index.rst b/docs/admin-guide/index.rst
index 54e6f65de3..8a1ea1741e 100644
--- a/docs/admin-guide/index.rst
+++ b/docs/admin-guide/index.rst
@@ -6,3 +6,4 @@ Admin Guide
 .. toctree::
    introduction
    microcode-loading
+   console
-- 
2.39.5



Yann Dirson | Vates Platform Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 12:08:12 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 12:08:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872408.1283370 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY2Bu-0001du-JL; Wed, 15 Jan 2025 12:08:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872408.1283370; Wed, 15 Jan 2025 12:08:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY2Bu-0001dn-GH; Wed, 15 Jan 2025 12:08:10 +0000
Received: by outflank-mailman (input) for mailman id 872408;
 Wed, 15 Jan 2025 12:08:09 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=hmQ5=UH=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tY2Bt-0001da-ER
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 12:08:09 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 618e1cef-d339-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 13:08:07 +0100 (CET)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-ab322ecd75dso146704566b.0
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 04:08:07 -0800 (PST)
Received: from [10.81.35.177] ([46.149.103.12])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab337d71352sm210298966b.54.2025.01.15.04.08.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 15 Jan 2025 04:08:06 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 618e1cef-d339-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736942887; x=1737547687; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Kmeyu+qUWKTXZ4Mksi6zjGxNuSb/SWYG3CoZy2oFHhc=;
        b=IDh8wNgSFE4Tez6aImdGnF4Pq5y920fYs9b61GG2I+FIdq3skj99QShDVvyzS/SF9M
         uqH9l8qKWWYVEy/PZlKStDSbge9HWv09zLrDIpJs5lj9PYz6DEqX34ntVHzDh3tby8c5
         SgrE9k9XCP+1hSCEmVsQfM/C81zrRZIptUq8Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736942887; x=1737547687;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Kmeyu+qUWKTXZ4Mksi6zjGxNuSb/SWYG3CoZy2oFHhc=;
        b=BJMx6GAMFhVH+s90wYToPfNgBAP2jFAYuSuvOixzF7n7Tul9hxWlQ1ojUVAskdvIDx
         /gZzRDZFUBqd94hnLQldliFx4D3HaEdkxr0vMskQrPRm4d1WXLpgHmObnKEjRuooZxTD
         22xXvAGxCa/cTrSymvWI8U5Usbja5KgLEIGZdFjO80lqp0xR+8dDYw7Mm09cApgK+soH
         A2vzuFxWsRPWAd0Zq081BaMl2PDrGLev40VvUebcYRUcY2wIMSZ9qkMpePAKExtvmXtE
         HXaJmfjw7/N7RQ16WoVU1za3hzCJc3Lg+uYKV7+PL4offTdZLgfNxPOWHfuBFDLEOQeF
         8Efw==
X-Forwarded-Encrypted: i=1; AJvYcCW8qSNbI/lrkB4OREDxMcXfC4tbXIx4DV5IuVvFZa76PsXkGouYbu8ZFa+cQVk9TO5J7TJb+n+OimY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzaN4ySTUfhQDIQdgcpMyzHGMKnmD36u6mvKKm8bEQpHlBNgn+k
	4y2bdrjOZxd2UgbyTNR9/mniwhksRa1ZEoZ1ZXSS7nHU48pkMqIM3pO4o00ifoSk8kTRkfOHBuy
	/
X-Gm-Gg: ASbGnctJ46v+Rbmii8j9CarCI6dtiqi6YjE08Ip2pNrwKpBdxpRDr7qiFmuZTaZjtj3
	vngMN4I8De4xnbpE+1LdHJpBcAgYpL0jRuaYzr1nDm1gO3bwF3qUIDpiuVJ4b4346BrZFnJT/CX
	GLpRh7aDJYGzroUvDKnCb215PBaK675yB6r+qiYuLjoZqCq9ZfqG4o39Zbjv9imEEtCPmzho0NA
	FI/RSZNwn2jfn3hW2t65vM2Bai4N3tD587rxVR3pDTUwXdyKWULr7AaJI8cw6paQCw=
X-Google-Smtp-Source: AGHT+IG3atfQuhtdKGLp5p5I6WBJ7QsLnJX/echZTu4U6xtiE/UhGBCuljohL0c6hqDta35asty+Iw==
X-Received: by 2002:a17:907:7252:b0:aae:e52f:3d2b with SMTP id a640c23a62f3a-ab2c3d1927fmr1683809866b.28.1736942887049;
        Wed, 15 Jan 2025 04:08:07 -0800 (PST)
Message-ID: <a936f720-818e-41d8-bd68-b35bc2bce7b6@citrix.com>
Date: Wed, 15 Jan 2025 12:08:05 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 1/2] docs/sphinx: import sys for error reporting
To: Yann Dirson <yann.dirson@vates.tech>, xen-devel@lists.xenproject.org
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Stefano Stabellini <sstabellini@kernel.org>
References: <cover.1736941628.git.yann.dirson@vates.tech>
 <4b7de1b9a5b0eec8cb1803e59b0027092c43c126.1736941628.git.yann.dirson@vates.tech>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <4b7de1b9a5b0eec8cb1803e59b0027092c43c126.1736941628.git.yann.dirson@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 15/01/2025 12:01 pm, Yann Dirson wrote:
> Signed-off-by: Yann Dirson <yann.dirson@vates.tech>
> ---
>  docs/conf.py | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/docs/conf.py b/docs/conf.py
> index 5d2e979449..84bec024e7 100644
> --- a/docs/conf.py
> +++ b/docs/conf.py
> @@ -21,6 +21,7 @@
>  # https://www.sphinx-doc.org/en/master/usage/configuration.html#project-information
>  
>  import sphinx
> +import sys
>  
>  project = u'Xen'
>  copyright = u'2019-%Y, The Xen development community'

Oh, that's awkward.  Older sphinx must have had sys in context, because
it did work when I initially added that check.

Any chance this can go up above the "Path setup" section, and drop the
commented out line?

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 12:12:45 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 12:12:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872419.1283380 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY2GG-0003mR-4W; Wed, 15 Jan 2025 12:12:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872419.1283380; Wed, 15 Jan 2025 12:12:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY2GG-0003mK-1Z; Wed, 15 Jan 2025 12:12:40 +0000
Received: by outflank-mailman (input) for mailman id 872419;
 Wed, 15 Jan 2025 12:12:38 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=hmQ5=UH=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tY2GE-0003mE-6X
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 12:12:38 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 01c17541-d33a-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 13:12:36 +0100 (CET)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-5d4e2aa7ea9so13189606a12.2
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 04:12:36 -0800 (PST)
Received: from [10.81.35.177] ([46.149.103.15])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d990469e5asm7387896a12.55.2025.01.15.04.12.35
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 15 Jan 2025 04:12:35 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 01c17541-d33a-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736943156; x=1737547956; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=3vkw3KoLLYwhNznF2w6gk+7TEpb52hT3vRDnAAAOlaI=;
        b=S3HmaVfbTS+ptbvF/E0jz+NQlecNmu0CQ75J1IJ1eZqIS+ju5Gj5LtV5l3Zh18dYJJ
         kaWW/Wt/zIpwa018eYwEDkbfzxWmlCgFK4E+zf009IPekD2PbpCnHcL8CuVmlYNe98YM
         c7MZKadTmmjg+rSL7raKSSV6fJ9ITabm/0V+U=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736943156; x=1737547956;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=3vkw3KoLLYwhNznF2w6gk+7TEpb52hT3vRDnAAAOlaI=;
        b=AaGfDvFMNR2XDVo1yb8L1w/W3cRuWJ8aGmygV0dpVORvIzYWfSQLKf5Kgp9OM9rKPT
         pMyDnsQx3Sju15S1+NGGU+7B6S7GIWEoIyEeaJpw/Y+7XduqC0IjpJAxuOJPXWKfMQRw
         q5Z5PU2ur5Bhv/XCugAKc5NgoNK9zpg8cRRWkOzX8aeejAl5cc7dxl1Pvoo8CZPINsWH
         S/nGbQp7wJC25EfZk13zI+rScXxC46S0HwGTqb7/vUyOvnuxhIhdD1Pap4lsVlPaASyA
         oarzA3Vc96pLHsrHEJuj6gK3lEtjlgOs9BKXbkwpmr7ZIebijzyBOdxBNfSeQrWBwe35
         jJ+g==
X-Forwarded-Encrypted: i=1; AJvYcCUiDuEyKe8sWYW9fPlm8q9JFoq8zU8gp3XXie9QXw69K53TKlX4QrssfLbdRtFgebIL8WGkY7H/Tu8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyqCBoPSX59BHmv/19aCobTtfqC978iC0mG28n2AW2Vf0Ny0T49
	nVAoJ/npnCPTdPv+4v2sIaJjEdlL0qk2t/Osr/PaBazqjnNY4cd695W0BB0MVdk=
X-Gm-Gg: ASbGnct6K90XljKgH6D6OCh7+/aiE1uJZA4bjLt7ksImjRXiV787eNjXe6sWv8DeXRu
	Lql0pDaMe1ag0NauS8M3ywZ/GbOOWbQRi9jN9RV7HEOlKRAWvddqQIFwj6K712peKnS+OGCEgRV
	1I3wZiiYJ1ElQWZiunyi3suFT5204tAxtStOAg+pUOvoHoIHPmWil8METS0tSNt4+JBPc8jxH+c
	zvJboJJ6YZg29ih7/lfKWQ+PrydYwKO/EIGhEb1UOzjaVFNB3FJPbQVy8lzyBr1QNs=
X-Google-Smtp-Source: AGHT+IEl0RdV8CHNPhnWQ3AQHNm5IHq1fcGxKoV4ARJvLcZgbWpj4PmyoufeKysPmv2kgj4YiVcYLw==
X-Received: by 2002:a05:6402:268c:b0:5d2:d72a:77e4 with SMTP id 4fb4d7f45d1cf-5d972e6c9b0mr29734636a12.28.1736943155859;
        Wed, 15 Jan 2025 04:12:35 -0800 (PST)
Message-ID: <391f5a96-769d-4dfb-8966-b3d6c255422b@citrix.com>
Date: Wed, 15 Jan 2025 12:12:34 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 2/2] docs/sphinx: gitignore generated files
To: Yann Dirson <yann.dirson@vates.tech>, xen-devel@lists.xenproject.org
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Stefano Stabellini <sstabellini@kernel.org>
References: <cover.1736941628.git.yann.dirson@vates.tech>
 <cc6e4e8e5fe08c7b4bb183535b7e302bfba41058.1736941628.git.yann.dirson@vates.tech>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <cc6e4e8e5fe08c7b4bb183535b7e302bfba41058.1736941628.git.yann.dirson@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 15/01/2025 12:01 pm, Yann Dirson wrote:
> Signed-off-by: Yann Dirson <yann.dirson@vates.tech>
> ---
>  .gitignore | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/.gitignore b/.gitignore
> index 25484a8fd8..404590c36a 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -62,6 +62,7 @@ docs/man5/
>  docs/man7/
>  docs/man8/
>  docs/pdf/
> +docs/sphinx/
>  docs/txt/
>  extras/
>  install/*

Thanks, although we're transitioning to per-dir .gitignore files.

Can this move into docs/.gitignore and become sphinx/ as the pattern?

If you fancy fixing all of them, that would be excellent too.  See c/s
0a15b7695bd983f "tools/ocaml: Rationalise .gitignore" as an example.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 12:24:05 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 12:24:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872427.1283390 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY2RE-00063j-34; Wed, 15 Jan 2025 12:24:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872427.1283390; Wed, 15 Jan 2025 12:24:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY2RE-00063c-0P; Wed, 15 Jan 2025 12:24:00 +0000
Received: by outflank-mailman (input) for mailman id 872427;
 Wed, 15 Jan 2025 12:23: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
 <SRS0=SR+c=UH=amd.com=ayan.kumar.halder@srs-se1.protection.inumbo.net>)
 id 1tY2RC-00063W-Bu
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 12:23:58 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20615.outbound.protection.outlook.com
 [2a01:111:f403:2418::615])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9722d257-d33b-11ef-a0e1-8be0dac302b0;
 Wed, 15 Jan 2025 13:23:56 +0100 (CET)
Received: from PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7)
 by CY5PR12MB6600.namprd12.prod.outlook.com (2603:10b6:930:40::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8356.13; Wed, 15 Jan
 2025 12:23:53 +0000
Received: from PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264]) by PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264%6]) with mapi id 15.20.8356.010; Wed, 15 Jan 2025
 12:23:52 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9722d257-d33b-11ef-a0e1-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=jdxVbm6IXvzzegzMjHAZzyBPpxVyE7u3QV/J5SW6NjRCt99hH25JMPxBmn6+fFEHZIfyUKchoA0/03v9budkLHBZ7ctnoCozR9+0AEbo66yil0ge+f658Itnqm3DSSSJrDRYvtQpDYogWHppzlr3jD/Td72YNUDYz+/Y0WIRkvWKS5qzoyOkgoACbsT43WOUep2XqJ5CaYlHSz/RVnu76bKYu82Lhf6lB0GjYNJFgpwd990hKZ7p1ewB7mSThh0xbXaaz2Bw1BxmBYbvmniI5DhBVoQWRhgZ3IUZ3tjHygLaas5HMx9/fkyVIS04D0+UcEIAVbSyOEGL4K/iUcaNSQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=BAgF3iUkqDSJ+A2tIPb5Cz9QL1wgJdBbdt94dBXwqMg=;
 b=bfRCRKVLki8iAE9vy6yOdXdkmCA0Yj/Dbmihev2wZsWpZWOWgNhrRU2Ybocvwm/QC2H437megySencfp30R/mlxa7lqboO0Vgc4gZsnfXtdS2oV9GM7TY0KV79A+yoZBkHKMMowFxCdwj/4hICKxSf6wOskJHNVfFhLLhE19RS6dMSjAaM7u+khVOvfHanIcOsjBvZu8B7Npjn8Bt+jzWvYVa/odB4FP9cZDpISH+Vyl+1XKEWy54Euf+iAkE3gBog3dpNgtSSp5EUGdVzRMvsDqdMxJVT6U4eiwOwn2Qymy4Kko3em9Ze/pn/mU8hVMzqN3qmNRLlfa5EgP4RQZEA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=BAgF3iUkqDSJ+A2tIPb5Cz9QL1wgJdBbdt94dBXwqMg=;
 b=5KGmh5f5AblFEj3wtYHzutt3tZKm2qF80i6oF4GVirNFHjrCzm8z4I1C8MzR9W6nLw+SxmY+oJO2GYyzaCmne8EKc+gQo1VcVOu5Ud2LAxf1VlsS3aLxm41HsBUI09jxWAuBdcYH9lcRxLpVjdiZATSZP4jjThsXN0NWrFv4Kog=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <57ab92fc-b1cf-4966-8794-cac8df8ce25e@amd.com>
Date: Wed, 15 Jan 2025 12:23:47 +0000
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 1/2] docs: fusa: Define the requirements for
 XEN_VERSION hypercall.
To: Andrew Cooper <andrew.cooper3@citrix.com>,
 Ayan Kumar Halder <ayan.kumar.halder@amd.com>, xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>, Artem Mygaiev <artem_mygaiev@epam.com>
References: <20250114195010.3409094-1-ayan.kumar.halder@amd.com>
 <9653ccc0-203a-4bec-ba79-57870ed08ea0@citrix.com>
Content-Language: en-GB
From: Ayan Kumar Halder <ayankuma@amd.com>
In-Reply-To: <9653ccc0-203a-4bec-ba79-57870ed08ea0@citrix.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: DB8PR04CA0029.eurprd04.prod.outlook.com
 (2603:10a6:10:110::39) To PH8PR12MB7326.namprd12.prod.outlook.com
 (2603:10b6:510:216::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH8PR12MB7326:EE_|CY5PR12MB6600:EE_
X-MS-Office365-Filtering-Correlation-Id: da7c516c-9f71-4ffe-9112-08dd355f78c6
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?RXp2S0JES2tkcU55N1FIWmQ0L3F6bDVpR3BEQU9ZajhzQm9STlhCNkY5SXZF?=
 =?utf-8?B?NE0ydXJrRjRjRHdBc0REQ1pmQ1VhajdPanc4RVgyQkZBRm02eVNsMXB6Zy82?=
 =?utf-8?B?WllyRXFtcFI3OVcrdWw4dG5DeERCVzI0ajMzOEdMN0VQY2N2QkxKRU96YWdV?=
 =?utf-8?B?T1NzcSt6ZFhsUnEyT3ZrSGgzMGFwUDczUXZLK1hZQWE4endkb283MFBibjFP?=
 =?utf-8?B?UFU5a2RrWVR6NTg4TmJtWTRKcTdJS2oyQ2VNb2N0WVJhV1BnbkIwazY2UHlB?=
 =?utf-8?B?VzZJUkZKYUtrSCtJQ21wWU5GRGxydndiUW1oZUdocllWUUtma2xUbDRYV1pV?=
 =?utf-8?B?LzJ5MUZkNll5cXR2WG0zdHp4d3RtMXViT0w5WmxGWkp6U3Q5MGpXcytFcjRZ?=
 =?utf-8?B?cnoxcDB4QVBBTy9ab0poTDIwM2RZS0xjTU1pYjJ1NVhadzhSL0k0SHhwSm9T?=
 =?utf-8?B?cGkyUkhocSs4RnN3K1VpbEx0UDl5ME5tTFdyRWREN2ZYWThabHpuUzg1bFFX?=
 =?utf-8?B?d0ZyUG9wbXFNWll4cUZPcXowdmYxVExhMGZTdWtaOUo1VTIwNE5jUkVGYVh3?=
 =?utf-8?B?MDFIYnV1ZkdobkMvb1BvcHQ0bVRucDVUU3gvNXJkMU5OaFowR3FWV0ZidGpD?=
 =?utf-8?B?cW5sMUkzQitDUGU2Z2x4eGRmTWw2SnIzRnJaWW9CVXBwcURaTEMxTEVpRnd4?=
 =?utf-8?B?Zzlmejcrd2tqdnJrWU5ZeWNtVEswZFIyemkzenRJMkh5YjAzampBdSsvL2Zy?=
 =?utf-8?B?WFdmc204VmY1SDNLMk1XQ1FEcDJXZnI5R05oQ3h3VUUrV093b2NUclFZZFN2?=
 =?utf-8?B?bHJjTzBEVjMxSVB1bkwvdVBTRlNQdE43aVp6R3JsKzZ1N3lqa09VTXo5Zi9z?=
 =?utf-8?B?ejFRTzNGK09kRGdaM3pQYnNPQ2ZreXYvMmIvR0tnVi84ZlhvRUZkcW9FTTMy?=
 =?utf-8?B?TEVaZjBxV1hZa0Z4Z3RYWlhOYWp3NldlUlhHdlArMCtxTG55bGtWTDlXWnJa?=
 =?utf-8?B?VWlOS1dpS1BOWlk5UDh1K3I4MGEyK2ZqME8wQjRIdzRKRS95akduVEY4R2JV?=
 =?utf-8?B?ZXM5RDNPQTVYdzZPdUlUUnVBbTN4a254YnZacGFwRWo5OHlzaVJ2MHprUVFG?=
 =?utf-8?B?a1I2T2VWUnd2dXFGNEcvZzJrN3l6b3VXU09XQXVzVEZoazgzeEdCWjJmb1VH?=
 =?utf-8?B?T3daSW5iV0s5eWg1YUJiK2lwS0tZa3g5WjJwQXZXVXMya3JYL3dUak95bmU1?=
 =?utf-8?B?ZXc4T3FoeEpRZVhYSHpGMWdPS2JGUFhTbUtGVE1LT05vSlJCYlhOTnluUzM2?=
 =?utf-8?B?MWQ5cmRTVFpPR1MrM3NZTCtCdjFvUk9xV2crdngzeFRlMU5MMjdsWnJGRHd1?=
 =?utf-8?B?MXVjUUN2alVtaFFocVk1NWZXZWZYN1dRbXBnL2RnVW9jbSttYUg5Uk5HY1pH?=
 =?utf-8?B?a3VpTTRGeUlHbDZoZ2JHN3NSeTlubWp3bmNUQ2ZlV1VzRkFuVzZpc1NmSC9G?=
 =?utf-8?B?NjB0T2lkdUJqc21rVGwybVNIa2ZrWk05WWxRZ0lNNlZtd2RubjFSc0xEY3FQ?=
 =?utf-8?B?OStoN21SZk50WVBxc2ZnMDFhWVhIRXl5dXN5aWt3dlBDb0RpWWZZNVJaZUQr?=
 =?utf-8?B?amU3T1BMdm5RRG1ab1k3bkc5SXc4citVenZJRkJMVFl1QktVMnVKZjNKakM3?=
 =?utf-8?B?OGoxekl0RGpyNEd4V3BIWitSOTVyUnY1V3RLOGU4V2xQY3NMem5maG04WkE0?=
 =?utf-8?B?Zy9jUXAzODdINExmRmF2Wmd3N3dQcFQ1MjE4NHRPQ2VoeXNDVGJPT0QwVmd2?=
 =?utf-8?B?M2JpTTRDZXJuZ2hJLzV6dz09?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH8PR12MB7326.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?dEpQRzZ3ejNHeVQ3T3ZUZDdPb1lxTDdUVGZnMFkwY3Y2YzJHNjJLdFM2YzFz?=
 =?utf-8?B?YkplaXlXaVFnQnI5MUtwOHdQbU9jTkJYYUJDNGplaDVLcmt0MW1BVkdtUVM3?=
 =?utf-8?B?bnk4U09tWU1tSGpNd1hSSzFxUFB4VGgxWGwybkJOcFhXTWdubXJFZ1Q1UzR4?=
 =?utf-8?B?UE83Y3RRaTYycStvNlpPbjJXV0tyQ2NBNFBQZE90TlFaSk8xS3JCd3JoUkpK?=
 =?utf-8?B?NHQxM3JGNi8ydlE5ZkFodTh2QmZ3TjlIWm5oY2NiWG80ZVBybDBvVWtnV2xo?=
 =?utf-8?B?M2RUSnJ6ZHBoRjJocmlsUENhS0hmOGcwUVl1dG9LYzFSY1gzdndBcm9tUFFU?=
 =?utf-8?B?WElpYmIrbVNXTGlFTVNSMlJBQWxvdHVOZEZNYzRLczJTeFVRdGlPOEV0d0xz?=
 =?utf-8?B?NXdLSzZlVmZhTDB5cDBpdHBIR0ROY2E2NEFPVlF0ZHNlTkVocDBKL0tKYk8y?=
 =?utf-8?B?bXlSOXZoS0NQY3dsSytHZ0lYR0JVTG1ZY0EzUDA5NDVmQzFTbGNLMEdZNlRp?=
 =?utf-8?B?QTRjWUVuV0RBTkd6akh0bk1zM2ViMnJtWmtRSnpWK0NmRG9JdDJya09vZlV5?=
 =?utf-8?B?SDhmUURNUCtUaEdhYVZWZmZ4ZnlDRmVyYXZGMEVHbWFIZUhaLzlDZG5wZyt4?=
 =?utf-8?B?eE9sZXp3N1Zib2l0YXJaNFdPdTdzUGJuMVA0TlhhRXVPYk1BaytHL3lTcGZM?=
 =?utf-8?B?cStzS2xZenNyZVBUZ2txNWdNSUJzdndMb0RFbGRVSUR3eGd0a0UvTFEwR0NI?=
 =?utf-8?B?VTJDdzNIWndxSTVzMmtpUjFIUGJmTDFSaGM0eDhnUVJCSDY3T2VUM1pnSC9U?=
 =?utf-8?B?UkNnTEtUV2Y1ZExuek96ZkJwcldpb3g2b2x3MUNWczdpYnNjcUlHMGNNbXpr?=
 =?utf-8?B?QlVuanV5SysrazRKY1FmNi9FdHlSbE0xREtqTERhWlhuMkpoanJOL0VVa2wr?=
 =?utf-8?B?V0VBMVhIZDJ1RXN3SDRUTVh0QmRHUll4T25jNGh2ZFh5dTFiajhIQ1BEOTBE?=
 =?utf-8?B?Z2Z1anhLWDNLOUJHSEZkcmhZZ0o4NWdKbExSWUFRTktPbjc2bjVIeUdkWGFB?=
 =?utf-8?B?OWo5QUlsSG4wTHZZeC85bkFIV2pOVFVKdXV1bENPd1hxWjVSR1h1RTNKMXJF?=
 =?utf-8?B?aUpzQWREbmNmcUNHMmdiTXMzeGRWOFZ3aGZ1UGFwRHF2bUZGM2tGcGFsUHFK?=
 =?utf-8?B?ZXFEd2VybTBkSzFtZGM1bGZIbjZUendtQUtNMkY1aUJDaFAxUFI0OGU2NnJt?=
 =?utf-8?B?cE1tQk8remorTWdVL2xwZlA5OHdKTTZFdWtsYkRrVHJDZURTMWo0TGozSlEz?=
 =?utf-8?B?SjlsUjB5ZFg3MG5JM3V4RHNqNjBFa2M0RW1qMjBnc2JDRFZwb0x3ZUJKVjJ3?=
 =?utf-8?B?VzNGN1JGWjJNNERJbnoyMTZJYU44b1FzTmhtWHFiSTlENldZTWhUYkFxODBY?=
 =?utf-8?B?SGhmNkNhbzVMUzZWQnNma3VyN1BUWjdBaUptQThhWVV4dng0OG9PT3lJbjFu?=
 =?utf-8?B?SGZyS3BKa1NvZWVldkN4OEVaQ2srSkpRKzZ4SG1HRjZVd0dLZmxxVXY1bEp0?=
 =?utf-8?B?b0tPak1BYlBUbjJHRHg2Rm1VVkYwa1htTXVZL0kyU2J5aUFSTVlUeW5TL3My?=
 =?utf-8?B?Qk03aDBGa1NSQVgvRlFXZE0vN1Z5VDNRMnNNMDBTb1p1N1Q5Tzh1eWFHNkVE?=
 =?utf-8?B?YjM2OUIyN08rNHhWbmFSQ000K2RheXQ4YjRGa3lManV6cHNHMXlWcUFKQVhX?=
 =?utf-8?B?VElwUHRKSmNrZlplRFgrRXdZa0NTUlY1ZXlPTEoxd2Y5VG93ckQ1UmVLTUJi?=
 =?utf-8?B?azVNVjRZdVFCVnZ6dzlzOW1Yd00ycmNneDB2TG1VQnNvWDVsVXp3UVJ6eW1k?=
 =?utf-8?B?TGNxWjljMGxMNVlCSmRQeE9oaVlGNHBkWmU0U1oyeWVTS2pvaC9lbmgxaTBl?=
 =?utf-8?B?OTMwVVNVZGVwMDB3eC9Ha3NKTnBWUWw5OE56RWlRVDhNeGEvRHFsNjNkSlJt?=
 =?utf-8?B?ck1odmkzdFVKZThhSkp2RlM4eDR2b093ZldIVWtsSEJ0d3lwRC9LOG5reG9k?=
 =?utf-8?B?dDEzRitMMmxvMGxyK1REZHpncWpxV2pXVXhLYzltaFRkVUk0OWpqZUloanFV?=
 =?utf-8?Q?RcvYp0BvfMRKZ2XGGLTFv/LoN?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: da7c516c-9f71-4ffe-9112-08dd355f78c6
X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7326.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2025 12:23:52.3153
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: p5jymNJJDGfLzlFUV1WSQAuVbY37J7uUCwyrQ076KuSDj02p4mlcDzuvt4Nr2JchQM3eAjQhlOowyem14C37ow==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR12MB6600

Hi Andrew,

On 14/01/2025 20:15, Andrew Cooper wrote:
> On 14/01/2025 7:50 pm, Ayan Kumar Halder wrote:
>> diff --git a/docs/fusa/reqs/product-reqs/version_hypercall.rst b/docs/fusa/reqs/product-reqs/version_hypercall.rst
>> new file mode 100644
>> index 0000000000..fdb8da04e1
>> --- /dev/null
>> +++ b/docs/fusa/reqs/product-reqs/version_hypercall.rst
>> @@ -0,0 +1,61 @@
>> +Return Value
>> +------------
>> +
>> +`XenProd~version_hyp_ret_val~1`
>> +
>> +Description:
>> +Xen shall return 0 in case of success or one of the error codes as defined in
>> +https://man7.org/linux/man-pages/man3/errno.3.html.
> Xen's errors live in public/errno.h
Ack.
>
> They share a lot in common with Linux (for historical reasons), but they
> are critically not Linux errnos because Xen supports OSes which aren't
> Linux.  xenstored for example sends errors as text rather than numbers.
>
> Also, that's not the return value ABI of __HYPERVISOR_xen_version.  Some
> subops return a positive value instead of 0 on success.

Yes, my bad. 'XENVER_version' cmd will return the actual version number 
on success. I should reword this as

"Xen shall use the error codes defined in xen/include/public/errno.h , 
as a return value in case of failure."

And a separate requirement will be

"Xen shall return a non negative value in case of success."

Let me know if this sounds ok.

>
> And if you're wondering "hey, isn't that ambiguous in extreme cases",
> yes it is.  Xen's hypercall API/ABI are a disaster.

Ack. :)

- Ayan

>
> ~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 12:28:07 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 12:28:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872442.1283430 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY2V9-0007Mh-Cr; Wed, 15 Jan 2025 12:28:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872442.1283430; Wed, 15 Jan 2025 12:28:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY2V9-0007MQ-9o; Wed, 15 Jan 2025 12:28:03 +0000
Received: by outflank-mailman (input) for mailman id 872442;
 Wed, 15 Jan 2025 12:28: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
 <SRS0=WDCk=UH=bounce.vates.tech=bounce-md_30504962.6787a9cc.v1-8efef2ade84749499ffccea0abd79f50@srs-se1.protection.inumbo.net>)
 id 1tY2V7-0006fG-MR
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 12:28:01 +0000
Received: from mail128-16.atl41.mandrillapp.com
 (mail128-16.atl41.mandrillapp.com [198.2.128.16])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 268a449e-d33c-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 13:27:57 +0100 (CET)
Received: from pmta08.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail128-16.atl41.mandrillapp.com (Mailchimp) with ESMTP id
 4YY4yh3rrqzRKbjGW
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 12:27:56 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 8efef2ade84749499ffccea0abd79f50; Wed, 15 Jan 2025 12:27:56 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 268a449e-d33c-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1736944076; x=1737204576;
	bh=rD0TZYM4EFPHaYU8mIWlW5dHR2cgOw47UUmTX3U9tk8=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=tIWPzN5RSojyiDFWRLsFOqvdd+YczZrT9cjwQavBtyDHdMKVZouHMs2GtwucQbBj5
	 YFrv8s3r9AzPO+Zg3+K9mCWLYlVSH638zZ/spvPrYG4+lWXYXjShIrWy9lHADlDJ+B
	 bfxrpd9l2F+8t/1yBD+3GAOaoiBNeVYOxiga1tly1QSVXPZWOuUxTqIcy2YtHFHBav
	 qdir7stGD59jUH1ahdtAwq9WJkTFQW1vHdVPxFD9/+dQlQ5zmacsg+/lrC08w6aotP
	 90s2H9F97DnmPFZb9RkY6WIBdTZgnHRJHp2qLh+hnGC9aj3ERJhwEpWqmAzpXFGtt/
	 MerVDirPZGxDQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1736944076; x=1737204576; i=yann.dirson@vates.tech;
	bh=rD0TZYM4EFPHaYU8mIWlW5dHR2cgOw47UUmTX3U9tk8=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=ZaibYpU+i37ILH2TF9fFP6/QUCPenhqahN3H3szktJ5Vf4tK+gR1NB+01L/PnFGZV
	 OOv/O8dmCVKlrmpwAbTNVURbw8EV+tVAyTHCkpp0bWhl6ExmVvEbzKKckpwbK4XyXM
	 8XpxhUFOY7KRQz4eStLNs7B8zTblkCbDMHdpfmguY8XkapKE/sjtMNOOSabysEFs2t
	 e56ACM5wR/cjS+kuUIbuoM2uQRkIuqIwZQ/L0qo8iQ6c6MaO21D+BSdYnlStROiYac
	 HOVkkuX2duhk/uG2CUc1BFCbBIN2JC9ipzfa+qZCoSV5/s7hgYUxonKCqcJQ0Pk+tB
	 jqbO5SGTH7I6g==
From: "Yann Dirson" <yann.dirson@vates.tech>
Subject: =?utf-8?Q?[XEN=20PATCH=20v2=202/3]=20docs:=20rationalise=20.gitignore?=
X-Mailer: git-send-email 2.39.5
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1736944075408
To: xen-devel@lists.xenproject.org
Cc: "Yann Dirson" <yann.dirson@vates.tech>, "Andrew Cooper" <andrew.cooper3@citrix.com>, "Anthony PERARD" <anthony.perard@vates.tech>, "Michal Orzel" <michal.orzel@amd.com>, "Jan Beulich" <jbeulich@suse.com>, "Julien Grall" <julien@xen.org>, "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>, "Stefano Stabellini" <sstabellini@kernel.org>
Message-Id: <c3f6a2d8fd7a1df487a6fce99e8e0f785ac4fc75.1736943927.git.yann.dirson@vates.tech>
In-Reply-To: <cover.1736943927.git.yann.dirson@vates.tech>
References: <cover.1736943927.git.yann.dirson@vates.tech>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.8efef2ade84749499ffccea0abd79f50?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250115:md
Date: Wed, 15 Jan 2025 12:27:56 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Note I did not transplant the patterns under doc/txt/ (since the whole
dir is ignored already), and adjusted sort order to be fully
alphabetical.

Signed-off-by: Yann Dirson <yann.dirson@vates.tech>
---
 .gitignore      | 17 -----------------
 docs/.gitignore | 14 ++++++++++++++
 2 files changed, 14 insertions(+), 17 deletions(-)
 create mode 100644 docs/.gitignore

diff --git a/.gitignore b/.gitignore
index 25484a8fd8..53f5df0003 100644
--- a/.gitignore
+++ b/.gitignore
@@ -50,19 +50,6 @@ config/Toplevel.mk
 config/Paths.mk
 
 dist/*
-docs/tmp.*
-docs/html/
-docs/man/xl.cfg.5.pod
-docs/man/xl-disk-configuration.5.pod
-docs/man/xl-network-configuration.5.pod
-docs/man/xl.1.pod
-docs/man/xl.conf.5.pod
-docs/man1/
-docs/man5/
-docs/man7/
-docs/man8/
-docs/pdf/
-docs/txt/
 extras/
 install/*
 
@@ -302,7 +289,3 @@ tools/debugger/kdd/kdd
 tools/firmware/etherboot/ipxe.tar.gz
 tools/firmware/etherboot/ipxe/
 tools/xl/xl
-
-docs/txt/misc/*.txt
-docs/txt/man/*.txt
-docs/figs/*.png
diff --git a/docs/.gitignore b/docs/.gitignore
new file mode 100644
index 0000000000..0727c6d7cf
--- /dev/null
+++ b/docs/.gitignore
@@ -0,0 +1,14 @@
+/figs/*.png
+/html/
+/man/xl.cfg.5.pod
+/man/xl-disk-configuration.5.pod
+/man/xl-network-configuration.5.pod
+/man/xl.1.pod
+/man/xl.conf.5.pod
+/man1/
+/man5/
+/man7/
+/man8/
+/pdf/
+/tmp.*
+/txt/
-- 
2.39.5



Yann Dirson | Vates Platform Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 12:28:07 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 12:28:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872439.1283399 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY2V6-0006fT-Ly; Wed, 15 Jan 2025 12:28:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872439.1283399; Wed, 15 Jan 2025 12:28:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY2V6-0006fM-JI; Wed, 15 Jan 2025 12:28:00 +0000
Received: by outflank-mailman (input) for mailman id 872439;
 Wed, 15 Jan 2025 12:27:59 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=qL8v=UH=bounce.vates.tech=bounce-md_30504962.6787a9cc.v1-b10fa3bdf01f49df8ad680db5b8dd259@srs-se1.protection.inumbo.net>)
 id 1tY2V5-0006fA-4n
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 12:27:59 +0000
Received: from mail178-22.suw51.mandrillapp.com
 (mail178-22.suw51.mandrillapp.com [198.2.178.22])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2662181e-d33c-11ef-a0e1-8be0dac302b0;
 Wed, 15 Jan 2025 13:27:57 +0100 (CET)
Received: from pmta13.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail178-22.suw51.mandrillapp.com (Mailchimp) with ESMTP id
 4YY4yh3JxmzGlswDS
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 12:27:56 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 b10fa3bdf01f49df8ad680db5b8dd259; Wed, 15 Jan 2025 12:27:56 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2662181e-d33c-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1736944076; x=1737204576;
	bh=dOOsXTP8OwZy3WWvkB1+qNS07astUnM7jHkXX3lf6hk=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=HeliYDg3NKwqCdzz1gIh6RgY8SydW43TLhRFuYsGP6k/77zcfo95NQtYXoFlYOzH4
	 VEWVCr+WI6daDUOna7IgX2ZJdMUlx5+JRFKGYbfyjEVHDBpdFBCypc6VOFvT8LLLC3
	 koTzePMWy9XhIYg3HrIoftf0Ol2D9ltQRQHPwaaL/Qe6TL7G2pmUroRng+XZhBMrwD
	 i3W9uATmYauecK8pTeTYJOM8KhNbItC9x5Gf/H9wIA7gyI6EFNJJB5kNOzy3JENEOi
	 s/bi5NO2ezPfuIwvq9ap35zGyEvtj0KDPSIuLX86VhJ0kqqzT7Y5DKry9LEZ9AtLdz
	 MF4b82P0AD4jw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1736944076; x=1737204576; i=yann.dirson@vates.tech;
	bh=dOOsXTP8OwZy3WWvkB1+qNS07astUnM7jHkXX3lf6hk=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=hqIDJuSrCTWIB8JKlo/i6oWbtFi7+3uodcHqhEpIvjvXoU4FFbPtRGwJBYVm35w4y
	 3LpFGF8XkdkTj0GDLYHvfw0IQe7O+nFzum1s5H+F9ldfpDcaLVTkMmkidl4p/lY0kd
	 1zX3mAEpidmgvCQZOq5eo1SJpIaXCrDuT8GVRZ7LffmLTd4TE3fk1Xa31uTJXXPYdR
	 CbrzUNLA/jSBVFl7fBteMCZyYnjvsuKye+R6b0KMLG05hxivnug8u4wDsY6MUx7qx5
	 YFx7bbkvSpzeL5sZgXgIy9xm9br7viaH0/uFZA0BhX+p9/LEuQzRBvSb2D+5FQfV68
	 LD7XurmtXo/Nw==
From: "Yann Dirson" <yann.dirson@vates.tech>
Subject: =?utf-8?Q?[XEN=20PATCH=20v2=201/3]=20docs/sphinx:=20import=20sys=20for=20error=20reporting?=
X-Mailer: git-send-email 2.39.5
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1736944075175
To: xen-devel@lists.xenproject.org
Cc: "Yann Dirson" <yann.dirson@vates.tech>, "Andrew Cooper" <andrew.cooper3@citrix.com>, "Anthony PERARD" <anthony.perard@vates.tech>, "Michal Orzel" <michal.orzel@amd.com>, "Jan Beulich" <jbeulich@suse.com>, "Julien Grall" <julien@xen.org>, "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>, "Stefano Stabellini" <sstabellini@kernel.org>
Message-Id: <8f3a1914d135657e5d98ac5fad6c7b0e13974bf6.1736943927.git.yann.dirson@vates.tech>
In-Reply-To: <cover.1736943927.git.yann.dirson@vates.tech>
References: <cover.1736943927.git.yann.dirson@vates.tech>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.b10fa3bdf01f49df8ad680db5b8dd259?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250115:md
Date: Wed, 15 Jan 2025 12:27:56 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Signed-off-by: Yann Dirson <yann.dirson@vates.tech>
---
 docs/conf.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/docs/conf.py b/docs/conf.py
index 5d2e979449..2fb8bafe65 100644
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -6,6 +6,8 @@
 # For the full list of built-in configuration values, see the documentation:
 # https://www.sphinx-doc.org/en/master/usage/configuration.html
 
+import sys
+
 # -- Path setup --------------------------------------------------------------
 
 # If extensions (or modules to document with autodoc) are in another directory,
@@ -13,7 +15,6 @@
 # documentation root, use os.path.abspath to make it absolute, like shown here.
 #
 # import os
-# import sys
 # sys.path.insert(0, os.path.abspath('.'))
 
 
-- 
2.39.5



Yann Dirson | Vates Platform Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 12:28:07 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 12:28:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872441.1283420 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY2V8-00077V-5R; Wed, 15 Jan 2025 12:28:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872441.1283420; Wed, 15 Jan 2025 12:28:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY2V8-00077M-1z; Wed, 15 Jan 2025 12:28:02 +0000
Received: by outflank-mailman (input) for mailman id 872441;
 Wed, 15 Jan 2025 12:28:00 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=emy9=UH=bounce.vates.tech=bounce-md_30504962.6787a9cc.v1-01978c670a2740c9a2057090fc5bb0de@srs-se1.protection.inumbo.net>)
 id 1tY2V6-0006fA-Qs
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 12:28:00 +0000
Received: from mail178-22.suw51.mandrillapp.com
 (mail178-22.suw51.mandrillapp.com [198.2.178.22])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 26b51770-d33c-11ef-a0e1-8be0dac302b0;
 Wed, 15 Jan 2025 13:27:58 +0100 (CET)
Received: from pmta13.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail178-22.suw51.mandrillapp.com (Mailchimp) with ESMTP id
 4YY4yh6WpnzGlswDW
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 12:27:56 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 01978c670a2740c9a2057090fc5bb0de; Wed, 15 Jan 2025 12:27:56 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 26b51770-d33c-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1736944076; x=1737204576;
	bh=UBbT0pa4mHPutb6jsuj67GiXKP61nGVqjVTJVp4vaoQ=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=ExUCFpqeXMHcs8IjkSw8YmUBB8hpx8dfVEEThsgQ2MUYQAheOc2PrGfTpnHQRQHzf
	 cBwkhgDINtnMWW5TYTml473RCUESprwo2hmzGsd9SZvl8/fL46xrlREpatqPberhvu
	 5GekSukRGaqJyAEYT8BWxDffqUQxR5VzNXAGK/niScAjh/u7asVQB1Tw3R3I7WUtpa
	 fCuRdI9XjvISAbH3hgrLWEmufdE+x5/9CEz0prrBzarYe553i7OmrG81YbwHH8GxCx
	 V70Yc9urEwcuxAMHXB4US51xWM0ANL9t+L8x5U8cDBuOA25gj65W+uZNMzZQnUwg40
	 ueAhxD/u98beQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1736944076; x=1737204576; i=yann.dirson@vates.tech;
	bh=UBbT0pa4mHPutb6jsuj67GiXKP61nGVqjVTJVp4vaoQ=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=s8waA4eO5T1PYMJlUDBDBxXKYpA2oL59YAV/jb4XWZtvD/LbdlDvinXquMuiWwzAM
	 2izaCSCfXAtHiPW+WoA4ceC/6LRmLBD6XZFLEEoChOHSKU9tGvEEatOJ1K3kFXbCUa
	 ta21s/kMoOKoZeNEz1QP7sn5LA3eIhc2SjQZXkJ1auVsCI0BjxV0cugf3HVQh/YCAZ
	 IpiPJ+sbK3ODNk6EIDTN63csBCHLhntU153pd4lHHEp+k7ht1KktCjmxFHrsiycKOD
	 FUdJDhOFCzma2Wtg+R2U+yfc2ep9dwqO2UkVovdcd0I326CVsBX/Fm2gbdgVDVtGKr
	 odb9pdlTFCm5g==
From: "Yann Dirson" <yann.dirson@vates.tech>
Subject: =?utf-8?Q?[XEN=20PATCH=20v2=203/3]=20docs/sphinx:=20gitignore=20generated=20files?=
X-Mailer: git-send-email 2.39.5
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1736944075627
To: xen-devel@lists.xenproject.org
Cc: "Yann Dirson" <yann.dirson@vates.tech>, "Andrew Cooper" <andrew.cooper3@citrix.com>, "Anthony PERARD" <anthony.perard@vates.tech>, "Michal Orzel" <michal.orzel@amd.com>, "Jan Beulich" <jbeulich@suse.com>, "Julien Grall" <julien@xen.org>, "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>, "Stefano Stabellini" <sstabellini@kernel.org>
Message-Id: <a2e4647d1e1a601dbeb4d59348815f7fd3935d67.1736943927.git.yann.dirson@vates.tech>
In-Reply-To: <cover.1736943927.git.yann.dirson@vates.tech>
References: <cover.1736943927.git.yann.dirson@vates.tech>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.01978c670a2740c9a2057090fc5bb0de?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250115:md
Date: Wed, 15 Jan 2025 12:27:56 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Signed-off-by: Yann Dirson <yann.dirson@vates.tech>
---
 docs/.gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/docs/.gitignore b/docs/.gitignore
index 0727c6d7cf..e87b12890a 100644
--- a/docs/.gitignore
+++ b/docs/.gitignore
@@ -10,5 +10,6 @@
 /man7/
 /man8/
 /pdf/
+/sphinx/
 /tmp.*
 /txt/
-- 
2.39.5



Yann Dirson | Vates Platform Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 12:28:07 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 12:28:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872440.1283403 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY2V6-0006i2-St; Wed, 15 Jan 2025 12:28:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872440.1283403; Wed, 15 Jan 2025 12:28:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY2V6-0006gt-Pv; Wed, 15 Jan 2025 12:28:00 +0000
Received: by outflank-mailman (input) for mailman id 872440;
 Wed, 15 Jan 2025 12:27:59 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=sIR8=UH=bounce.vates.tech=bounce-md_30504962.6787a9cc.v1-44f8893ad68c486d8daeed9e3a93f6d1@srs-se1.protection.inumbo.net>)
 id 1tY2V5-0006fA-Qi
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 12:27:59 +0000
Received: from mail128-16.atl41.mandrillapp.com
 (mail128-16.atl41.mandrillapp.com [198.2.128.16])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 26681694-d33c-11ef-a0e1-8be0dac302b0;
 Wed, 15 Jan 2025 13:27:57 +0100 (CET)
Received: from pmta08.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail128-16.atl41.mandrillapp.com (Mailchimp) with ESMTP id
 4YY4yh34dlzRKLfRQ
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 12:27:56 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 44f8893ad68c486d8daeed9e3a93f6d1; Wed, 15 Jan 2025 12:27:56 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 26681694-d33c-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1736944076; x=1737204576;
	bh=Se/x1iatsUypc3gc3kN2O/xnGmWhnUx/0YvOnWGnfFE=;
	h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version:
	 Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From;
	b=ya1P6DKPrJE4tpEYhIpIShHEwXOD4jENg4GIgHY+uunCMJ3PLd3DC4fSdF7zZrZt8
	 k2Y53a3Qy2ml94ou2+e6sRxuWjBfP2sxMTdnS7rU8HscfAfu/eEv2V/te8eu+T+uuc
	 ptSWut1YaD0ArkgwEi3euUG7+TQSBjsCwMsd7z6xnjgJAzrHJJ9B7zO1FZW8A23vML
	 AbgNtxSsjYPBsT4P1Bi03dORT+aEEzMPN7N0SSOEvnZL+7T+3qZZv7JgSyDipAm0OB
	 zRnck5GUwRYHV13dHRhCNl4K5RKY/bq7fU2sjMrOTm1hQb2TAp0kQRQoTdf6PqTPys
	 KLJ2nbc5Rd2pQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1736944076; x=1737204576; i=yann.dirson@vates.tech;
	bh=Se/x1iatsUypc3gc3kN2O/xnGmWhnUx/0YvOnWGnfFE=;
	h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version:
	 Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From;
	b=vSJsKCfUbrUFJVjW29ogjOz7vGS90H4kDDQ13Y6AYPYOShpaGoZkf3UC8PAqd7REw
	 OPmhwLEKKM6CcrxrPgMhQ9pFVLR1un/gQGhOCkFrQfNGzrLIGn04mP6Doomq5kr27D
	 u8N5fzg/12feNt2DnJZQwVAUbcXSw8aeE7bXEBXFKpciKvVMNisRZ6GyWqw7wIXPC0
	 dCY732r8g8teBn2TVyBuTy7P5S8W9DLsF2PQZyt6UJ3QO5AfRPpbrolk9X1D/kepMJ
	 mefjdemk8yASyF9FAMsnFj1s4tUuIraGXPVV8q5Jt9JpLrIuH0S2NUy2PhERRK70o7
	 CcMi9SkvpxYXQ==
From: "Yann Dirson" <yann.dirson@vates.tech>
Subject: =?utf-8?Q?[XEN=20PATCH=20v2=200/3]=20trivial=20improvements=20to=20sphinx=20doc=20tooling?=
X-Mailer: git-send-email 2.39.5
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1736944074998
To: xen-devel@lists.xenproject.org
Cc: "Yann Dirson" <yann.dirson@vates.tech>, "Andrew Cooper" <andrew.cooper3@citrix.com>, "Anthony PERARD" <anthony.perard@vates.tech>, "Michal Orzel" <michal.orzel@amd.com>, "Jan Beulich" <jbeulich@suse.com>, "Julien Grall" <julien@xen.org>, "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>, "Stefano Stabellini" <sstabellini@kernel.org>
Message-Id: <cover.1736943927.git.yann.dirson@vates.tech>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.44f8893ad68c486d8daeed9e3a93f6d1?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250115:md
Date: Wed, 15 Jan 2025 12:27:56 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

changes:
v2:
* move import up and adjust "path setup" instructions
* new patch for .gitignore rationalisation

Yann Dirson (3):
  docs/sphinx: import sys for error reporting
  docs: rationalise .gitignore
  docs/sphinx: gitignore generated files

 .gitignore      | 17 -----------------
 docs/.gitignore | 15 +++++++++++++++
 docs/conf.py    |  3 ++-
 3 files changed, 17 insertions(+), 18 deletions(-)
 create mode 100644 docs/.gitignore

-- 
2.39.5



Yann Dirson | Vates Platform Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 12:34:23 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 12:34:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872474.1283440 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY2bC-00023e-1B; Wed, 15 Jan 2025 12:34:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872474.1283440; Wed, 15 Jan 2025 12:34:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY2bB-00023X-UY; Wed, 15 Jan 2025 12:34:17 +0000
Received: by outflank-mailman (input) for mailman id 872474;
 Wed, 15 Jan 2025 12:34: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
 <SRS0=AzvQ=UH=suse.de=tzimmermann@srs-se1.protection.inumbo.net>)
 id 1tY2b9-00023R-M6
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 12:34:15 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 06ec4f89-d33d-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 13:34:13 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id 0911921268;
 Wed, 15 Jan 2025 12:34:13 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 767F4139CB;
 Wed, 15 Jan 2025 12:34:12 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id E28IG0Srh2cCTwAAD6G6ig
 (envelope-from <tzimmermann@suse.de>); Wed, 15 Jan 2025 12:34:12 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 06ec4f89-d33d-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736944453; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=6rF2/Nds9jaSABjY+tPpNsWja3s7il8oCoGTgAQg7zI=;
	b=fgWXXkrFkmGejWhD5fjTSv1Ssa3J0/Rq3i+ng8TxEKD1eRYuiFNmbUfuajMGofr3s/t2eZ
	KUgh6Bm/awPn8TV8uJkhGaXDHQR6CWgT/hcaXY1q2efHMbV/wmhjhMEy29fROVqCvSDkdz
	6tQTVjC5fOWCKOgJQRgT1JzzUj6MBJw=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736944453;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=6rF2/Nds9jaSABjY+tPpNsWja3s7il8oCoGTgAQg7zI=;
	b=y94aRJ3hTl+xAqZyjbuOx6P3Fm9fL5u2Qm278Eu98uKnVjQZVMuFhA5M1heZuojCir6spI
	Y/ZF6lkgng5FbRAA==
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736944453; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=6rF2/Nds9jaSABjY+tPpNsWja3s7il8oCoGTgAQg7zI=;
	b=fgWXXkrFkmGejWhD5fjTSv1Ssa3J0/Rq3i+ng8TxEKD1eRYuiFNmbUfuajMGofr3s/t2eZ
	KUgh6Bm/awPn8TV8uJkhGaXDHQR6CWgT/hcaXY1q2efHMbV/wmhjhMEy29fROVqCvSDkdz
	6tQTVjC5fOWCKOgJQRgT1JzzUj6MBJw=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736944453;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=6rF2/Nds9jaSABjY+tPpNsWja3s7il8oCoGTgAQg7zI=;
	b=y94aRJ3hTl+xAqZyjbuOx6P3Fm9fL5u2Qm278Eu98uKnVjQZVMuFhA5M1heZuojCir6spI
	Y/ZF6lkgng5FbRAA==
Message-ID: <0ea6be58-0e04-4172-87cd-064a3e4a43bc@suse.de>
Date: Wed, 15 Jan 2025 13:34:12 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with
 drm_mode_size_dumb()
To: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>,
 maarten.lankhorst@linux.intel.com, mripard@kernel.org, airlied@gmail.com,
 simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org, linux-mediatek@lists.infradead.org,
 freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
 imx@lists.linux.dev, linux-samsung-soc@vger.kernel.org,
 nouveau@lists.freedesktop.org, virtualization@lists.linux.dev,
 spice-devel@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org,
 linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org,
 intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org,
 Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
 Andy Yan <andyshrk@163.com>
References: <20250109150310.219442-1-tzimmermann@suse.de>
 <20250109150310.219442-26-tzimmermann@suse.de>
 <cdbe483d-0895-47aa-8c83-1c28220f4a02@ideasonboard.com>
 <bc97b92e-7f8a-4b92-af8a-20fa165ead55@suse.de>
 <f3ba05c7-6e49-4641-a3f9-ba418ebdb7c3@ideasonboard.com>
 <c6735280-7c32-4319-8ca9-a7305d8117c3@suse.de>
 <d67adb03-5cd0-4ac9-af58-cf4446dacee3@ideasonboard.com>
Content-Language: en-US
From: Thomas Zimmermann <tzimmermann@suse.de>
Autocrypt: addr=tzimmermann@suse.de; keydata=
 xsBNBFs50uABCADEHPidWt974CaxBVbrIBwqcq/WURinJ3+2WlIrKWspiP83vfZKaXhFYsdg
 XH47fDVbPPj+d6tQrw5lPQCyqjwrCPYnq3WlIBnGPJ4/jreTL6V+qfKRDlGLWFjZcsrPJGE0
 BeB5BbqP5erN1qylK9i3gPoQjXGhpBpQYwRrEyQyjuvk+Ev0K1Jc5tVDeJAuau3TGNgah4Yc
 hdHm3bkPjz9EErV85RwvImQ1dptvx6s7xzwXTgGAsaYZsL8WCwDaTuqFa1d1jjlaxg6+tZsB
 9GluwvIhSezPgnEmimZDkGnZRRSFiGP8yjqTjjWuf0bSj5rUnTGiyLyRZRNGcXmu6hjlABEB
 AAHNJ1Rob21hcyBaaW1tZXJtYW5uIDx0emltbWVybWFubkBzdXNlLmRlPsLAjgQTAQgAOAIb
 AwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftODH
 AAoJEGgNwR1TC3ojx1wH/0hKGWugiqDgLNXLRD/4TfHBEKmxIrmfu9Z5t7vwUKfwhFL6hqvo
 lXPJJKQpQ2z8+X2vZm/slsLn7J1yjrOsoJhKABDi+3QWWSGkaGwRJAdPVVyJMfJRNNNIKwVb
 U6B1BkX2XDKDGffF4TxlOpSQzdtNI/9gleOoUA8+jy8knnDYzjBNOZqLG2FuTdicBXblz0Mf
 vg41gd9kCwYXDnD91rJU8tzylXv03E75NCaTxTM+FBXPmsAVYQ4GYhhgFt8S2UWMoaaABLDe
 7l5FdnLdDEcbmd8uLU2CaG4W2cLrUaI4jz2XbkcPQkqTQ3EB67hYkjiEE6Zy3ggOitiQGcqp
 j//OwE0EWznS4AEIAMYmP4M/V+T5RY5at/g7rUdNsLhWv1APYrh9RQefODYHrNRHUE9eosYb
 T6XMryR9hT8XlGOYRwKWwiQBoWSDiTMo/Xi29jUnn4BXfI2px2DTXwc22LKtLAgTRjP+qbU6
 3Y0xnQN29UGDbYgyyK51DW3H0If2a3JNsheAAK+Xc9baj0LGIc8T9uiEWHBnCH+RdhgATnWW
 GKdDegUR5BkDfDg5O/FISymJBHx2Dyoklv5g4BzkgqTqwmaYzsl8UxZKvbaxq0zbehDda8lv
 hFXodNFMAgTLJlLuDYOGLK2AwbrS3Sp0AEbkpdJBb44qVlGm5bApZouHeJ/+n+7r12+lqdsA
 EQEAAcLAdgQYAQgAIAIbDBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftOH6AAoJEGgNwR1T
 C3ojVSkIALpAPkIJPQoURPb1VWjh34l0HlglmYHvZszJWTXYwavHR8+k6Baa6H7ufXNQtThR
 yIxJrQLW6rV5lm7TjhffEhxVCn37+cg0zZ3j7zIsSS0rx/aMwi6VhFJA5hfn3T0TtrijKP4A
 SAQO9xD1Zk9/61JWk8OysuIh7MXkl0fxbRKWE93XeQBhIJHQfnc+YBLprdnxR446Sh8Wn/2D
 Ya8cavuWf2zrB6cZurs048xe0UbSW5AOSo4V9M0jzYI4nZqTmPxYyXbm30Kvmz0rYVRaitYJ
 4kyYYMhuULvrJDMjZRvaNe52tkKAvMevcGdt38H4KSVXAylqyQOW5zvPc4/sq9c=
In-Reply-To: <d67adb03-5cd0-4ac9-af58-cf4446dacee3@ideasonboard.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.80
X-Spamd-Result: default: False [-2.80 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.20)[-0.999];
	MIME_GOOD(-0.10)[text/plain];
	FREEMAIL_TO(0.00)[ideasonboard.com,linux.intel.com,kernel.org,gmail.com,ffwll.ch];
	RCPT_COUNT_TWELVE(0.00)[21];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_ALL(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	FREEMAIL_ENVRCPT(0.00)[163.com,gmail.com];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	FROM_HAS_DN(0.00)[];
	FREEMAIL_CC(0.00)[lists.freedesktop.org,lists.infradead.org,vger.kernel.org,lists.linux.dev,lists.xenproject.org,ideasonboard.com,163.com];
	TO_DN_SOME(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,suse.de:mid]
X-Spam-Flag: NO
X-Spam-Level: 

Hi


Am 15.01.25 um 13:06 schrieb Tomi Valkeinen:
> Hi,
>
> On 15/01/2025 13:37, Thomas Zimmermann wrote:
>> Hi
>>
>>
>> Am 15.01.25 um 11:58 schrieb Tomi Valkeinen:
>> [...]
>>>> These are all good points. Did you read my discussion with Andy on 
>>>> patch 2? I think it resolves all the points you have. The current 
>>>> CREATE_DUMB 
>>>
>>> I had missed the discussion, and, indeed, the patch you attached 
>>> fixes the problem on Xilinx.
>>
>> Great. Thanks for testing.
>>
>>>
>>>> ioctl is unsuited for anything but the simple RGB formats. The bpp 
>>>
>>> It's a bit difficult to use, but is it really unsuited? 
>>> bitsperpixel, width and height do give an exact pitch and size, do 
>>> they not? It does require the userspace to handle the subsampling 
>>> and planes, though, so far from perfect.
>>
>> The bpp value sets the number of bits per pixel; except for bpp==15 
>> (XRGB1555), where it sets the color depth. OR bpp is the color depth; 
>> except for bpp==32 (XRGB8888), where it is the number of bits per 
>> pixel. It's therefore best to interpret it like a color-mode enum.
>
> Ah, right... That's horrible =).
>
> And I assume it's not really possible to define the bpp to mean bits 
> per pixel, except for a few special cases like 15?
>
> Why do we even really care about color depth here? We're just 
> allocating memory. Doesn't DIV_ROUND_UP(args->bpp, SZ_8) work fine for 
> XRGB1555 too?

Drivers always did that, but it does not work correctly for (bpp < 8). 
As we already have helpers to deal with bpp, it makes sense to use 
them.  This also aligns dumb buffers with the kernel's video= parameter, 
which as the same odd semantics. The fallback that uses bpp directly 
will hopefully be the exception.

>
>>> So, I'm all for a new ioctl, but I don't right away see why the 
>>> current ioctl couldn't be used. Which makes me wonder about the 
>>> drm_warn() in your patch, and the "userspace throws in arbitrary 
>>> values for bpp and relies on the kernel to figure it out". Maybe I'm 
>>> missing something here.
>>
>> I was unsure about the drm_warn() as well. It's not really wrong to 
>> have odd bpp values, but handing in an unknown bpp value might point 
>> to a user-space error. At least there should be a drm_dbg().
>>
>>>
>>>> parameter is not very precise. The solution would be a new ioctl 
>>>> call that receives the DRM format and returns a buffer for each 
>>>> individual plane.
>>>
>>> Yes, I think that makes sense. That's a long road, though =). So my 
>>> question is, is CREATE_DUMB really unsuitable for other than simple 
>>> RGB formats, or can it be suitable if we just define how the 
>>> userspace should use it for multiplanar, subsampled formats?
>>
>> That would duplicate format and hardware information in user-space. Some 
>
> But we already have that, don't we? We have drivers and userspace that 
> support, say, NV12 via dumb buffers. But (correct me if I'm wrong) we 
> don't document how CREATE_DUMB has to be used to allocate multiplanar 
> subsampled buffers, so the userspace devs have to "guess".

Yeah, there are constrains in the scanline and buffer alignments and 
orientation. And if we say that bpp==12 means NV12, it will be a problem 
for all other cases where bpp==12 makes sense.

Best regards
Thomas

>
>> hardware might have odd per-plane limitations that only the driver 
>> knows about. For example, there's another discussion on dri-devel 
>> about pitch- alignment requirements of DRM_FORMAT_MOD_LINEAR on 
>> various hardware. That affects dumb buffers as well. I don't think 
>> that there's an immediate need for a CREATE_DUMB2, but it seems worth 
>> to keep in mind.
>
> Yes, the current CREATE_DUMB can't cover all the hardware. We do need 
> CREATE_DUMB2, sooner or later. I just hope we can define and document 
> a set of rules that allows using CREATE_DUMB for the cases where it 
> sensibly works (and is already being used).
>
>  Tomi
>

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)



From xen-devel-bounces@lists.xenproject.org Wed Jan 15 12:47:18 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 12:47:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872487.1283450 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY2ng-0004V7-7F; Wed, 15 Jan 2025 12:47:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872487.1283450; Wed, 15 Jan 2025 12:47:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY2ng-0004V0-4P; Wed, 15 Jan 2025 12:47:12 +0000
Received: by outflank-mailman (input) for mailman id 872487;
 Wed, 15 Jan 2025 12:47: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
 <SRS0=4o+i=UH=cloud.com=bernhard.kaindl@srs-se1.protection.inumbo.net>)
 id 1tY2ne-0004Uu-Qb
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 12:47:10 +0000
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com
 [2a00:1450:4864:20::431])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d4ffdf7f-d33e-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 13:47:08 +0100 (CET)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-386329da1d9so3412982f8f.1
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 04:47:08 -0800 (PST)
Received: from localhost ([185.68.248.203]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a8e38f0eesm17806171f8f.61.2025.01.15.04.47.07
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 15 Jan 2025 04:47:07 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: d4ffdf7f-d33e-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736945228; x=1737550028; 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=yiLnvDkMCVfk/JEHp3old2hwqfuuFu8S2Iv1v5+6Iyc=;
        b=IRsNbVaBzkYtpxc/fyHdzQf8Wa6ZeBOZoefBIR7HvUFEm3vGIqh4aNEQpf1LRZht8x
         Pd1KQxXiKeTnlK5iKsHbBILTjcbKSbz5nPUHHJWKNi9njCsfMNqcN8UQXfShKLmCCvcI
         9kYYRB17PdZVlJ10gmV4fO7QMxxyM2VhUx7OQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736945228; x=1737550028;
        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=yiLnvDkMCVfk/JEHp3old2hwqfuuFu8S2Iv1v5+6Iyc=;
        b=lDqghvliz1cPgVK+woMHTTIeWMxJ+s+beeesZuTHJ65rkbcTeMks6ZHfP+j/T+hOSe
         5IIsx1BRqplowcsmO9p0RGMb+jdUhq4gZaSyACN56l8Zu8k6gfJDsFWO13FcH4MFSzRN
         T9uE+lcnj5GHGdsZLs9a6mfxDc3KRhW5p11SUM2ckd9gnCU3rIm5aLelLsGKqf8OgVN2
         yAoMrncbMSoab6GsAp704f+Eylx7zSVM/bVkgcgl2Oc6FRLGsq1zwNMGkHIVC7Bp2zxA
         327xb5Dn2z46ReyrX9AgO73BNYcdOgYvV+A6DA4HV0OT7j48D8vZg3PF1i93hraM+Ko4
         BItQ==
X-Gm-Message-State: AOJu0YxgBGjsBNgDbWLEBcYjt32nsjOpUGdgAxPtnW8B0qFPGXAaW0p0
	pNa+W9ipeJ3WYVcvEohnuIb96Kvr4tq7xBl+ku6OMEHKhofKstBrWX1PKe5tC2w7R9xP3miRzt6
	7leB8ow==
X-Gm-Gg: ASbGnctrLGSbp6Qy6wwSR9z/ZATRiOkrp0glXqXFwkcB50LaLHKaORz5FYPIfZWi1jJ
	UPWJdOj75g/6jOAwhIU+tkWXU+Qlks2ZocWST1UO2Sy8evLpgjHQsomgegCoKCvrft5BbGkwhGM
	Rj++FPF4IQdbRLsdzb/eHedZuJ6Dhqx1yWc+iVyBHOQm5rn4ff+bhtxiXIwo+bGcCC2rXHg6J8E
	k1aqOp5hGgB1IoAxXcdslKoIrlrSLObNfRw942l9Lxzvwr7Vg3+pBwVoT31XA==
X-Google-Smtp-Source: AGHT+IFNMgxpjui+KOK88z2kypCOVXsvoA2X64Fs5IdKU/ikFNnFWgJ5ZLmYdG2VgLhUOxm12r2KUQ==
X-Received: by 2002:a5d:6c68:0:b0:38a:82a3:395f with SMTP id ffacd0b85a97d-38a872c93f9mr20693302f8f.9.1736945228032;
        Wed, 15 Jan 2025 04:47:08 -0800 (PST)
From: Bernhard Kaindl <bernhard.kaindl@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Bernhard Kaindl <bernhard.kaindl@cloud.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Ross Lagerwall <ross.lagerwall@citrix.com>
Subject: [PATCH v2] docs: Improve spelling of few cases in the documentation
Date: Wed, 15 Jan 2025 13:47:02 +0100
Message-ID: <2c20751e64552ec69686aa26304710bce975bca5.1736945126.git.bernhard.kaindl@cloud.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Skimming the docs, I came across a few places for spelling improvements.

Signed-off-by: Bernhard Kaindl <bernhard.kaindl@cloud.com>
---
Changes in v2:
- Apply review of v1: Leave "brand new" and omit changes that Andy will do.
- "binary-patch" -> "binary patch" ("binarily patch" is okay but uncommon)
---
 docs/designs/non-cooperative-migration.md | 4 ++--
 docs/designs/qemu-deprivilege.md          | 2 +-
 docs/guest-guide/x86/hypercall-abi.rst    | 2 +-
 docs/man/xl.conf.5.pod.in                 | 2 +-
 docs/misc/livepatch.pandoc                | 2 +-
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/docs/designs/non-cooperative-migration.md b/docs/designs/non-cooperative-migration.md
index 4b876d809f..54496892ed 100644
--- a/docs/designs/non-cooperative-migration.md
+++ b/docs/designs/non-cooperative-migration.md
@@ -112,7 +112,7 @@ because the guest can sample its own domid from the frontend area and use
 it in hypercalls (e.g. HVMOP_set_param) rather than DOMID_SELF, the guest
 domid must also be preserved to maintain the ABI.
 
-Furthermore, it will necessary to modify backend drivers to re-establish
+Furthermore, it will be necessary to modify backend drivers to re-establish
 communication with frontend drivers without perturbing the content of the
 backend area or requiring any changes to the values of the xenstore state
 nodes.
@@ -259,7 +259,7 @@ Essentially this should skip the check to see if PV drivers and migrate as
 if there are none present, but also enabling the extra save records. Note
 that at least some of the extra records should only form part of a
 non-cooperative migration stream. For example, migrating event channel
-state would be counter productive in a normal migration as this will
+state would be counter-productive in a normal migration as this will
 essentially leak event channel objects at the receiving end. Others, such
 as grant table state, could potentially harmlessly form part of a normal
 migration stream.
diff --git a/docs/designs/qemu-deprivilege.md b/docs/designs/qemu-deprivilege.md
index 81a5f5c05d..f12b1a3ae3 100644
--- a/docs/designs/qemu-deprivilege.md
+++ b/docs/designs/qemu-deprivilege.md
@@ -3,7 +3,7 @@
 The goal of deprilvileging qemu is this: Even if there is a bug (for
 example in qemu) which permits a domain to gain control of the device
 model, the compromised device model process is prevented from
-violating the system's overall security properties.  Ie, a guest
+violating the system's overall security properties.  I.e., a guest
 cannot "escape" from the virtualisation by using a qemu bug.
 
 This document lists the various technical measures which we either
diff --git a/docs/guest-guide/x86/hypercall-abi.rst b/docs/guest-guide/x86/hypercall-abi.rst
index 745fbbb64a..e52ed453bc 100644
--- a/docs/guest-guide/x86/hypercall-abi.rst
+++ b/docs/guest-guide/x86/hypercall-abi.rst
@@ -109,7 +109,7 @@ abstracting away the details of how it is currently running.
 Creating Hypercall Pages
 ------------------------
 
-Guests which are started using the PV boot protocol may set set
+Guests which are started using the PV boot protocol may set
 ``XEN_ELFNOTE_HYPERCALL_PAGE`` to have the nominated page written as a
 hypercall page during construction.  This mechanism is common for PV guests,
 and allows hypercalls to be issued with no additional setup.
diff --git a/docs/man/xl.conf.5.pod.in b/docs/man/xl.conf.5.pod.in
index 44738b80bf..0cfec8587c 100644
--- a/docs/man/xl.conf.5.pod.in
+++ b/docs/man/xl.conf.5.pod.in
@@ -4,7 +4,7 @@
 
 =head1 DESCRIPTION
 
-The F<xl.conf> file allows configuration of hostwide C<xl> toolstack
+The F<xl.conf> file allows configuration of host-wide C<xl> toolstack
 options.
 
 For details of per-domain configuration options please see
diff --git a/docs/misc/livepatch.pandoc b/docs/misc/livepatch.pandoc
index a94fb57eb5..4a0b4fd6d8 100644
--- a/docs/misc/livepatch.pandoc
+++ b/docs/misc/livepatch.pandoc
@@ -2,7 +2,7 @@
 
 ## Rationale
 
-A mechanism is required to binarily patch the running hypervisor with new
+A mechanism is required to binary patch the running hypervisor with new
 opcodes that have come about due to primarily security updates.
 
 This document describes the design of the API that would allow us to
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Jan 15 12:49:34 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 12:49:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872496.1283459 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY2px-00054S-J7; Wed, 15 Jan 2025 12:49:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872496.1283459; Wed, 15 Jan 2025 12:49:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY2px-00054L-Gd; Wed, 15 Jan 2025 12:49:33 +0000
Received: by outflank-mailman (input) for mailman id 872496;
 Wed, 15 Jan 2025 12:49:32 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=/1j5=UH=bounce.vates.tech=bounce-md_30504962.6787aed8.v1-d67a2728358243fda3b10060ba8dc933@srs-se1.protection.inumbo.net>)
 id 1tY2pw-00054F-96
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 12:49:32 +0000
Received: from mail128-16.atl41.mandrillapp.com
 (mail128-16.atl41.mandrillapp.com [198.2.128.16])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2902f50a-d33f-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 13:49:30 +0100 (CET)
Received: from pmta08.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail128-16.atl41.mandrillapp.com (Mailchimp) with ESMTP id
 4YY5RX4zmFzRKLksS
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 12:49:28 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 d67a2728358243fda3b10060ba8dc933; Wed, 15 Jan 2025 12:49:28 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2902f50a-d33f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1736945368; x=1737205868;
	bh=ouzQwij4o4a18W/BqmyqWTKXE0e0aWIWkzIz4grj4Os=;
	h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=HmGKtOKe2WOlb6kUZ9gd1U/0l2dr47X+iEtn1h6PXbcc7F6SPGuTqYWJEetDfHKfe
	 fmrRDfnIsUtMZuarq69TWZzUNg+ddurUX87zrnGRe+RlgUI3OM+Jjgnx7MgqXkxOxY
	 s6AFiXuDhmPAoG0Xe29wEe2qJfBfy3i5asnW6ET0InxmB6XKT+Zmzyd93OitYJOVOI
	 mFu2u4SyfiO0fMEVg7TOITR+xI67Tjgv2khHpg0VHoZzmeDimcs2sb08rMUKtPlHFG
	 BSvAwfc6JpNmzupLvkU/hMJn6EPRuakypVmjFFr1FvZ1soapon89BElIqovPpUGg1i
	 iLtHSxgKpSPWw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1736945368; x=1737205868; i=yann.dirson@vates.tech;
	bh=ouzQwij4o4a18W/BqmyqWTKXE0e0aWIWkzIz4grj4Os=;
	h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=Te3PADkbbnsLhmcbzasLscufaFtGp+DcnbnJqUHTSFMjoltLsIpVW05VPvME3VIa/
	 NhlkJ7QKrlxjvp7AE0IR60jlDhj8TiIMVCcSW334EsfznazY3WL0rfBGpBKZBXytF9
	 0MMaQLkx8bnY25WsxYBhOFVFX5+r0uW5+xksA10v2U0Ht+d0EJxlaOTjJYbEmLIHPB
	 yT1WcbksXNSn5LQDhzku2RjabuS+S9XUzavgn9FALd7g6RhzFd3PdkRmP58fXd+gjX
	 yk7caiBo0GLf3ASmz4GJCzWcAq4teGwpmM1V4T24T8ZFz0pdb+3F+I5Pa0/qorT4gO
	 zxUZMQdQbGt4g==
From: "Yann Dirson" <yann.dirson@vates.tech>
Subject: =?utf-8?Q?Re:=20[PATCH=20v3=202/3]=20xen:=20common:=20add=20ability=20to=20enable=20stack=20protector?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1736945367490
Message-Id: <b90911b1-88c5-48df-89ca-d1ee755d01a2@vates.tech>
To: "Volodymyr Babchuk" <Volodymyr_Babchuk@epam.com>, xen-devel@lists.xenproject.org
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>, "Jan Beulich" <jbeulich@suse.com>, "Julien Grall" <julien@xen.org>, "Stefano Stabellini" <sstabellini@kernel.org>
References: <20241211020424.401614-1-volodymyr_babchuk@epam.com> <20241211020424.401614-3-volodymyr_babchuk@epam.com>
In-Reply-To: <20241211020424.401614-3-volodymyr_babchuk@epam.com>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.d67a2728358243fda3b10060ba8dc933?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250115:md
Date: Wed, 15 Jan 2025 12:49:28 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On 12/11/24 03:04, Volodymyr Babchuk wrote:
> +menu "Compiler options"
> +
> +config STACK_PROTECTOR
> +	bool "Stack protector"
> +	depends on HAS_STACK_PROTECTOR
> +	help
> +	  Enable the Stack Protector compiler hardening option. This inserts a
> +	  canary value in the stack frame of functions, and performs an integrity
> +	  check on exit.
> +
> +endmenu
> +

Since the previous patch lets room for other components to add Stack 
Protector support, wouldn't it be useful to make it more obvious what 
the scope of this option is?



Yann Dirson | Vates Platform Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 12:58:29 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 12:58:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872504.1283470 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY2yV-0007Ku-DZ; Wed, 15 Jan 2025 12:58:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872504.1283470; Wed, 15 Jan 2025 12:58:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY2yV-0007Kn-AM; Wed, 15 Jan 2025 12:58:23 +0000
Received: by outflank-mailman (input) for mailman id 872504;
 Wed, 15 Jan 2025 12:58: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
 <SRS0=hmQ5=UH=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tY2yU-0007KR-CN
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 12:58:22 +0000
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [2a00:1450:4864:20::62c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 654d443b-d340-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 13:58:20 +0100 (CET)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-aaee2c5ee6eso1170782466b.1
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 04:58:20 -0800 (PST)
Received: from [10.81.35.177] ([46.149.103.13])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c95b1ccasm751872566b.158.2025.01.15.04.58.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 15 Jan 2025 04:58:19 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 654d443b-d340-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736945900; x=1737550700; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=np12L4/yKQo3OFdzi79z++CTU5XeU4vXmPQn/3gU3yg=;
        b=WMpnACz0iuQWfJs/KTBgKXWtFwFmtU0QYd2jKPDqHxxaKQVSqH61p/5fgmC+NRWC6S
         T3ariC9+oOWgE3lTugACVsV08TMar4qLGrB04TBzoFzt3pOMPWBEVAfG65q8DMw4moe1
         Efkr3B5ukzFZprKMNkhKs0ArjIOR+vcc/sz4k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736945900; x=1737550700;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=np12L4/yKQo3OFdzi79z++CTU5XeU4vXmPQn/3gU3yg=;
        b=YlgVTf8v9ZBwiDb9vhYV7ky3ifBreYhrH/wySdBvf3VDfZghJUxz+MtiJ61k+ouokn
         7LxVth2iHyYR8FZ1ISqlCmOtY1OyrtKWTc5Lf+1T/IvIL++Y/IDDoCJgCehD/qOOQUCe
         q96T7xe0AnDn2coLQ8pU/KWi9ogRsHeYtaKBpz3S7WBh+gnsxW990LHj4i9Xufrjuf48
         ZWVfcl83Ieq4nKdK+ALrbKtju5qEA+3Whp6+Dk353qfkpixvVX+mt2sEUMVOLdXivzHG
         l+0Z61l6hGLRFfIL8ieomKqUM+tXlmbdUbYb6ah6Xjf2qUcABNsp7dNKp3Dv3WLrYuLM
         ddzg==
X-Forwarded-Encrypted: i=1; AJvYcCXxzqkv33TvZNYi1rC7WlYpXjB2lUdv0AeIO4D4RILunugIpUO72I7quT/4TYH46FSnc4qs5k/83JM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxosAxBhzDZcuLZPNoHjueSksf2YHA3ZezFUML1jZU77cN1NSZJ
	o1WOhVMpF6V/u8kKZaPc0yU+IKI++Xj7k5UfFnXfsLq7YS9ySdqmAbb7Rygym2w=
X-Gm-Gg: ASbGncu513fTCk3wtLdUnpQgtXozijgGNb9wvoZVZdcm9nf5iK8Rl39w6tDxvnPlcfm
	wrEZabgn8OlWopkU8cgj+lT2lLROu7c/a1VeS+pwhiQcOYq18kIX+g4fc2zqExh4+ZoO2EnSom3
	z75iFFFUXmqTO+JZp/3MNu81mW85ntLKoykPTtzKRwRvmqHW8EtIOTVDmLBgmjkfiPZvuFEV0/e
	zWO2C5QYp2nWMiHrPngeHxdFkjkgHpMXAfQolY2zjEZf2v5vTIzG4jfN9dPmezdujg=
X-Google-Smtp-Source: AGHT+IH1vTj851rgiy9IkwL/TvtsP4eD8IV4SeFtls5rCuJdkkxoekj7BFZbTt8p2zLb5DWHZzCKRg==
X-Received: by 2002:a17:906:6a19:b0:a9e:d4a9:2c28 with SMTP id a640c23a62f3a-ab2abc920abmr2936076866b.53.1736945899861;
        Wed, 15 Jan 2025 04:58:19 -0800 (PST)
Message-ID: <fa278a0e-105c-4849-af8f-881e98d5e4d5@citrix.com>
Date: Wed, 15 Jan 2025 12:58:18 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] docs: Improve spelling of few cases in the
 documentation
To: Bernhard Kaindl <bernhard.kaindl@cloud.com>,
 xen-devel@lists.xenproject.org
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Stefano Stabellini <sstabellini@kernel.org>,
 Ross Lagerwall <ross.lagerwall@citrix.com>
References: <2c20751e64552ec69686aa26304710bce975bca5.1736945126.git.bernhard.kaindl@cloud.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <2c20751e64552ec69686aa26304710bce975bca5.1736945126.git.bernhard.kaindl@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15/01/2025 12:47 pm, Bernhard Kaindl wrote:
> Skimming the docs, I came across a few places for spelling improvements.
>
> Signed-off-by: Bernhard Kaindl <bernhard.kaindl@cloud.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 13:27:33 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 13:27:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872515.1283479 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY3Qe-0004Lb-Hm; Wed, 15 Jan 2025 13:27:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872515.1283479; Wed, 15 Jan 2025 13:27:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY3Qe-0004LU-Ey; Wed, 15 Jan 2025 13:27:28 +0000
Received: by outflank-mailman (input) for mailman id 872515;
 Wed, 15 Jan 2025 13:27:27 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=hmQ5=UH=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tY3Qd-0004LO-5J
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 13:27:27 +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 7526f7ec-d344-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 14:27:25 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-aaef00ab172so1052857666b.3
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 05:27:25 -0800 (PST)
Received: from [10.81.35.177] ([46.149.103.13])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d9f05e49b0sm2657973a12.31.2025.01.15.05.27.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 15 Jan 2025 05:27:24 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 7526f7ec-d344-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736947644; x=1737552444; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=aHhxcREsfGZyleKSVFR/y7WX9/MFFJRW+aRQ3iohxSU=;
        b=n23+bXzJGdIuI43qzoXI+DWS++uv1eO8jhngvH0d1nP3QEAjTHL+J5szYOe3ne2q8T
         i+KKhOnrvDjg4Bo8bcPNLEorMMlCfKsn4vfMeDW3vbk5tl5TfWdt+OXFmG2NZur08r6w
         0XtinWCj2OgtMbiz2uQystf4/DbzLRfHf7Pew=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736947644; x=1737552444;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=aHhxcREsfGZyleKSVFR/y7WX9/MFFJRW+aRQ3iohxSU=;
        b=AGytIwQLHHR0bwDQeEV+yMURUXwTOrr7qQFpHJorTjH2Cs5QZb9pZnxJ+p/QIkuWfD
         CURSr97DBYxNAiH/8CaubracdI6cAd+s49WJV4QcQkH5U3JQ9Z6RMvTJVpLnG+nPpkaE
         SZ8Gdr6lvegre7u1Q3dYVcifTKE8Xt4hgmwFzGlSk6ySKl5s5sM3or7s6VUhUKnFZe7D
         tKIgvzSTiWt0D4aA4JLOVm/Rn2wTkroE0ukRoh4pAstdVHAXMHV76VsUBDdo3L6Fxuzr
         zoVx86Rbox7Zsj3j/D4HYwP4toX0NdoFvYNcuMFrGmpfJSmfTvuHLLgL6ITOWkSn/X/v
         wEnA==
X-Forwarded-Encrypted: i=1; AJvYcCVhEfuySM2n23G1SYGo4iNUOzDRdY/D55EKMg8BUiP4o7fPwxIZK5sX2IFjIJPZpThEDNkyY6/lxos=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwTOFJt/dc9YNt18SmDaug/921o9Sq1Ns7zF3x35GKhEqWOL46T
	8vbdVAKCJ6mcKw5/8bYGVQoH/Hw/06Y8UtvaQYQ4Lp4PxzvAw+ISsa0XMSDud3A=
X-Gm-Gg: ASbGncuoPEbmolnM6Mi1ompLzAtNMkiBY3atgMJ49/teKu+QUlCNRbg9auq91PPo3uW
	/JyTT7/Bv9QjTDONFYgzusNufk78vEC1kLvkNLO+2/RjeJYee+fGXBNViExS+fei2Mc0lKNJubk
	G0g04aoU4csIGgToeHsyoR68fybjSMinucxtCe2V0SzX1Fh1NXtA+MIPg/whwBtyxZb7w4pIv2y
	9yPg/8Oi69OfzZ94Q8KSc8OgcWNHYVvOWIX2TJYdRmTKq8qOK8MWaGA+4paX29j9UQ=
X-Google-Smtp-Source: AGHT+IH+uQ7oPWouRNdX53TEi7/Skmbuh/GksPosBEh4IogWkPLHcO82CHeHbj4C8NAyL2Q4yOgPbQ==
X-Received: by 2002:a05:6402:84f:b0:5d0:d3eb:a78f with SMTP id 4fb4d7f45d1cf-5d972d26e91mr73190035a12.0.1736947644451;
        Wed, 15 Jan 2025 05:27:24 -0800 (PST)
Message-ID: <58753517-26b6-47cc-a060-e8b5a88639bd@citrix.com>
Date: Wed, 15 Jan 2025 13:27:23 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH] docs/sphinx: overview of serial consoles
To: Yann Dirson <yann.dirson@vates.tech>, xen-devel@lists.xenproject.org
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Stefano Stabellini <sstabellini@kernel.org>
References: <d40643bf0730c2f227f2dfbc7985ba0b5f8878cf.1736942790.git.yann.dirson@vates.tech>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <d40643bf0730c2f227f2dfbc7985ba0b5f8878cf.1736942790.git.yann.dirson@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 15/01/2025 12:07 pm, Yann Dirson wrote:
> ---
>
> Notes:
>     This is a very preliminar first draft for comments:
>     
>     - would this structuration be adequate?
>     
>     - Is my basic understanding correct, are those first enumerations
>     correct? (some of it come solely from console.txt, which has already
>     proven to be seriously outdated on many aspects)
>     
>     - is there some doc about the qemu/ioemu backend I missed?  Is it able to
>     deal with PV consoles, or is it just for virtual UARTS?

Consoles are probably one of the harder areas to get started.

First, we need to distinguish between host consoles and guest consoles,
because admin-guide/console could be either/both.

Host consoles are mostly UARTs, but we have several flavours including
usb2 and usb3 flavours.  ARM has extensive early printk support, which
RISC-V/PPC are borrowing too.  Xen is also capable of using
hypervisor-provided consoles too.

For guest consoles, there's the plain CONSOLEIO hypercalls, and whether
they do anything interesting depend on whether you're dom0 and/or the
CONFIG_VERBOSE build setting.  ARM has the ability to mutiplex output
from different guests onto the host console.  There's also the
xenconsoled, things emulated by Qemu or other emulators, and even the
in-Xen UART emulator currently on list.


Then, for specific guests, they've got different console options
available.  e.g. Linux has a dedicated earlyconsole option for Xen (uses
CONSOLEIO) as well as an hvc driver.


And ideally we want all this information documented nicely, between "how
do I set up debugging for my guest" and how do I write a driver for
xenconsoled.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 13:33:22 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 13:33:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872527.1283492 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY3W8-0006He-A3; Wed, 15 Jan 2025 13:33:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872527.1283492; Wed, 15 Jan 2025 13:33:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY3W8-0006HX-7D; Wed, 15 Jan 2025 13:33:08 +0000
Received: by outflank-mailman (input) for mailman id 872527;
 Wed, 15 Jan 2025 13:33: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
 <SRS0=hmQ5=UH=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tY3W7-0006HR-1e
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 13:33:07 +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 40870794-d345-11ef-a0e1-8be0dac302b0;
 Wed, 15 Jan 2025 14:33:06 +0100 (CET)
Received: by mail-ed1-x52f.google.com with SMTP id
 4fb4d7f45d1cf-5d0ac27b412so9035121a12.1
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 05:33:06 -0800 (PST)
Received: from [10.81.35.177] ([46.149.103.14])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d990469ef5sm7455361a12.58.2025.01.15.05.33.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 15 Jan 2025 05:33:05 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 40870794-d345-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736947985; x=1737552785; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=nm7xH7cC7y2xt6ry/V2kf5OL6Yumca5DQ2prPpi2D60=;
        b=q1g6QITOasbhhSbqOVx7x/g9stnlbGy1XzD31vUP/Ac2qfz8Zzu15FJLQTTHvOVSsm
         Y6aGMqZIQ6+FbcOMzXUkGejrwS28EFDcn4YguQaKzdOVeBEGz/46UGALuMuifdOhA04O
         GzoazNu68vtAsUSGtJ0oyZ7YDkiUXdNyBHRC4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736947985; x=1737552785;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=nm7xH7cC7y2xt6ry/V2kf5OL6Yumca5DQ2prPpi2D60=;
        b=ShDnV19SbsjaU9SkT7b9n5Cq53oBDWy2/ZRBmh3vPf54YuuRE/0ampWK9rfcdzjzZh
         XWkmDNlF5M49UeiZwYqX559Yc824iJhtU7SVaizWvKpvkz5rCeDUSO1PWYnvNG/DPqNI
         77pjB27WfYKBB+dWFf/8busDpNAtxIoEqepWwSzErg0S0G3++aJtgk6H3ARhK+1efrPO
         TQAsmkyyM2F2jPrt1D3dJmSZKHHhcB4dj7m4aG01mRQP1ItVTGfwVSwALVtH066fYJ+a
         u3tGCum+KESe9QeuM8qebRLVE3bKkAF8FCCUHZekqCEyBwnI7LkFwBIwLWszyWmWwOoP
         dcNw==
X-Forwarded-Encrypted: i=1; AJvYcCVDryB1rfQyhmI0tp5BpdVBYr+DIciPKSf5J/lYcDYqPGG0eVDJxKgVYpGSUIktuDvaGwU2KEQJ1Go=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxMh9s+I18ioVo8lhXWxvc9sgVs0GT4RlCq1IJsk+fKqAcj9gKa
	NeqVgryCpKm9xk/YOaTLGpJITYStJtuebFmL1FH7y9hNKLvYxfpqHRRuZ405RUs=
X-Gm-Gg: ASbGncuG6tOhNnKPLoFyo6VAjfUR5MG3Myk/gw8atAR2zkkvZfHKtTEQjY6ILQQwzZI
	rStRQL9o4z3TB9MAQR/tsYP3CJsra+XEE6j83zCk3K0H5LuPWVZZqposKhp3VY8xapmkS/XPM5N
	Z/xMb5nBJoM/iLs5YnZ61SaTv3/xLMEt+pgsoNHKR4SBcv/IouPf8Z4EFJXGXk/Mmpo7emYwKl5
	fc1mX86q9XSwQEfvuHdSzdg2Kd9P8elkMlNeEcoiFM4NH5iFfDEEbmdj8z06OnQjIc=
X-Google-Smtp-Source: AGHT+IGlSKvL0owmOrqZVL44ojMLf28WGaG1Aune8QvP+M8I/gkmykYjxje8LhBqh0FzDbuX2RgX3w==
X-Received: by 2002:a05:6402:3554:b0:5da:d16:7387 with SMTP id 4fb4d7f45d1cf-5da0d1675b6mr2384736a12.24.1736947985510;
        Wed, 15 Jan 2025 05:33:05 -0800 (PST)
Message-ID: <5c55541f-f4d3-4c5b-8016-42722238f018@citrix.com>
Date: Wed, 15 Jan 2025 13:33:04 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v2 0/3] trivial improvements to sphinx doc tooling
To: Yann Dirson <yann.dirson@vates.tech>, xen-devel@lists.xenproject.org
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Stefano Stabellini <sstabellini@kernel.org>
References: <cover.1736943927.git.yann.dirson@vates.tech>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <cover.1736943927.git.yann.dirson@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15/01/2025 12:27 pm, Yann Dirson wrote:
> changes:
> v2:
> * move import up and adjust "path setup" instructions
> * new patch for .gitignore rationalisation
>
> Yann Dirson (3):
>   docs/sphinx: import sys for error reporting
>   docs: rationalise .gitignore
>   docs/sphinx: gitignore generated files

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 13:33:23 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 13:33:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872529.1283503 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY3WN-0006av-Ge; Wed, 15 Jan 2025 13:33:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872529.1283503; Wed, 15 Jan 2025 13:33:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY3WN-0006ao-Dv; Wed, 15 Jan 2025 13:33:23 +0000
Received: by outflank-mailman (input) for mailman id 872529;
 Wed, 15 Jan 2025 13:33: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
 <SRS0=MxfB=UH=ideasonboard.com=tomi.valkeinen@srs-se1.protection.inumbo.net>)
 id 1tY3WM-0006HR-Pl
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 13:33:22 +0000
Received: from perceval.ideasonboard.com (perceval.ideasonboard.com
 [2001:4b98:dc2:55:216:3eff:fef7:d647])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4979e972-d345-11ef-a0e1-8be0dac302b0;
 Wed, 15 Jan 2025 14:33:22 +0100 (CET)
Received: from [192.168.88.20] (91-158-153-178.elisa-laajakaista.fi
 [91.158.153.178])
 by perceval.ideasonboard.com (Postfix) with ESMTPSA id 7F882526;
 Wed, 15 Jan 2025 14:32:21 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 4979e972-d345-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;
	s=mail; t=1736947942;
	bh=8JOGQGcW2ZWewo/KKlUGVpyO0dsZu2+5fVZtMSIarrA=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=fDhitdAEpi4x4vI7U/E5YZVaek0gB2u/TTS45eMq+neSseTaQ0kQaj+uu9f7l7jDp
	 PzJ1EUx8yuUkcwotUbBDGDcB1oEBlwlwINzVJ8Eopn/oXZ75oGAykk4lrfsdw/sOXw
	 Y9PORlJ7sPyTjNaCzaBAbXIft918iSL0pYK+YitM=
Message-ID: <f35cb350-6be9-48ca-ad7e-e9dd418281d5@ideasonboard.com>
Date: Wed, 15 Jan 2025 15:33:16 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with
 drm_mode_size_dumb()
To: Thomas Zimmermann <tzimmermann@suse.de>,
 maarten.lankhorst@linux.intel.com, mripard@kernel.org, airlied@gmail.com,
 simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org, linux-mediatek@lists.infradead.org,
 freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
 imx@lists.linux.dev, linux-samsung-soc@vger.kernel.org,
 nouveau@lists.freedesktop.org, virtualization@lists.linux.dev,
 spice-devel@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org,
 linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org,
 intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org,
 Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
 Andy Yan <andyshrk@163.com>
References: <20250109150310.219442-1-tzimmermann@suse.de>
 <20250109150310.219442-26-tzimmermann@suse.de>
 <cdbe483d-0895-47aa-8c83-1c28220f4a02@ideasonboard.com>
 <bc97b92e-7f8a-4b92-af8a-20fa165ead55@suse.de>
 <f3ba05c7-6e49-4641-a3f9-ba418ebdb7c3@ideasonboard.com>
 <c6735280-7c32-4319-8ca9-a7305d8117c3@suse.de>
 <d67adb03-5cd0-4ac9-af58-cf4446dacee3@ideasonboard.com>
 <0ea6be58-0e04-4172-87cd-064a3e4a43bc@suse.de>
Content-Language: en-US
From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Autocrypt: addr=tomi.valkeinen@ideasonboard.com; keydata=
 xsFNBE6ms0cBEACyizowecZqXfMZtnBniOieTuFdErHAUyxVgtmr0f5ZfIi9Z4l+uUN4Zdw2
 wCEZjx3o0Z34diXBaMRJ3rAk9yB90UJAnLtb8A97Oq64DskLF81GCYB2P1i0qrG7UjpASgCA
 Ru0lVvxsWyIwSfoYoLrazbT1wkWRs8YBkkXQFfL7Mn3ZMoGPcpfwYH9O7bV1NslbmyJzRCMO
 eYV258gjCcwYlrkyIratlHCek4GrwV8Z9NQcjD5iLzrONjfafrWPwj6yn2RlL0mQEwt1lOvn
 LnI7QRtB3zxA3yB+FLsT1hx0va6xCHpX3QO2gBsyHCyVafFMrg3c/7IIWkDLngJxFgz6DLiA
 G4ld1QK/jsYqfP2GIMH1mFdjY+iagG4DqOsjip479HCWAptpNxSOCL6z3qxCU8MCz8iNOtZk
 DYXQWVscM5qgYSn+fmMM2qN+eoWlnCGVURZZLDjg387S2E1jT/dNTOsM/IqQj+ZROUZuRcF7
 0RTtuU5q1HnbRNwy+23xeoSGuwmLQ2UsUk7Q5CnrjYfiPo3wHze8avK95JBoSd+WIRmV3uoO
 rXCoYOIRlDhg9XJTrbnQ3Ot5zOa0Y9c4IpyAlut6mDtxtKXr4+8OzjSVFww7tIwadTK3wDQv
 Bus4jxHjS6dz1g2ypT65qnHen6mUUH63lhzewqO9peAHJ0SLrQARAQABzTBUb21pIFZhbGtl
 aW5lbiA8dG9taS52YWxrZWluZW5AaWRlYXNvbmJvYXJkLmNvbT7CwY4EEwEIADgWIQTEOAw+
 ll79gQef86f6PaqMvJYe9QUCX/HruAIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRD6
 PaqMvJYe9WmFD/99NGoD5lBJhlFDHMZvO+Op8vCwnIRZdTsyrtGl72rVh9xRfcSgYPZUvBuT
 VDxE53mY9HaZyu1eGMccYRBaTLJSfCXl/g317CrMNdY0k40b9YeIX10feiRYEWoDIPQ3tMmA
 0nHDygzcnuPiPT68JYZ6tUOvAt7r6OX/litM+m2/E9mtp8xCoWOo/kYO4mOAIoMNvLB8vufi
 uBB4e/AvAjtny4ScuNV5c5q8MkfNIiOyag9QCiQ/JfoAqzXRjVb4VZG72AKaElwipiKCWEcU
 R4+Bu5Qbaxj7Cd36M/bI54OrbWWETJkVVSV1i0tghCd6HHyquTdFl7wYcz6cL1hn/6byVnD+
 sR3BLvSBHYp8WSwv0TCuf6tLiNgHAO1hWiQ1pOoXyMEsxZlgPXT+wb4dbNVunckwqFjGxRbl
 Rz7apFT/ZRwbazEzEzNyrBOfB55xdipG/2+SmFn0oMFqFOBEszXLQVslh64lI0CMJm2OYYe3
 PxHqYaztyeXsx13Bfnq9+bUynAQ4uW1P5DJ3OIRZWKmbQd/Me3Fq6TU57LsvwRgE0Le9PFQs
 dcP2071rMTpqTUteEgODJS4VDf4lXJfY91u32BJkiqM7/62Cqatcz5UWWHq5xeF03MIUTqdE
 qHWk3RJEoWHWQRzQfcx6Fn2fDAUKhAddvoopfcjAHfpAWJ+ENc7BTQROprNHARAAx0aat8GU
 hsusCLc4MIxOQwidecCTRc9Dz/7U2goUwhw2O5j9TPqLtp57VITmHILnvZf6q3QAho2QMQyE
 DDvHubrdtEoqaaSKxKkFie1uhWNNvXPhwkKLYieyL9m2JdU+b88HaDnpzdyTTR4uH7wk0bBa
 KbTSgIFDDe5lXInypewPO30TmYNkFSexnnM3n1PBCqiJXsJahE4ZQ+WnV5FbPUj8T2zXS2xk
 0LZ0+DwKmZ0ZDovvdEWRWrz3UzJ8DLHb7blPpGhmqj3ANXQXC7mb9qJ6J/VSl61GbxIO2Dwb
 xPNkHk8fwnxlUBCOyBti/uD2uSTgKHNdabhVm2dgFNVuS1y3bBHbI/qjC3J7rWE0WiaHWEqy
 UVPk8rsph4rqITsj2RiY70vEW0SKePrChvET7D8P1UPqmveBNNtSS7In+DdZ5kUqLV7rJnM9
 /4cwy+uZUt8cuCZlcA5u8IsBCNJudxEqBG10GHg1B6h1RZIz9Q9XfiBdaqa5+CjyFs8ua01c
 9HmyfkuhXG2OLjfQuK+Ygd56mV3lq0aFdwbaX16DG22c6flkkBSjyWXYepFtHz9KsBS0DaZb
 4IkLmZwEXpZcIOQjQ71fqlpiXkXSIaQ6YMEs8WjBbpP81h7QxWIfWtp+VnwNGc6nq5IQDESH
 mvQcsFS7d3eGVI6eyjCFdcAO8eMAEQEAAcLBXwQYAQIACQUCTqazRwIbDAAKCRD6PaqMvJYe
 9fA7EACS6exUedsBKmt4pT7nqXBcRsqm6YzT6DeCM8PWMTeaVGHiR4TnNFiT3otD5UpYQI7S
 suYxoTdHrrrBzdlKe5rUWpzoZkVK6p0s9OIvGzLT0lrb0HC9iNDWT3JgpYDnk4Z2mFi6tTbq
 xKMtpVFRA6FjviGDRsfkfoURZI51nf2RSAk/A8BEDDZ7lgJHskYoklSpwyrXhkp9FHGMaYII
 m9EKuUTX9JPDG2FTthCBrdsgWYPdJQvM+zscq09vFMQ9Fykbx5N8z/oFEUy3ACyPqW2oyfvU
 CH5WDpWBG0s5BALp1gBJPytIAd/pY/5ZdNoi0Cx3+Z7jaBFEyYJdWy1hGddpkgnMjyOfLI7B
 CFrdecTZbR5upjNSDvQ7RG85SnpYJTIin+SAUazAeA2nS6gTZzumgtdw8XmVXZwdBfF+ICof
 92UkbYcYNbzWO/GHgsNT1WnM4sa9lwCSWH8Fw1o/3bX1VVPEsnESOfxkNdu+gAF5S6+I6n3a
 ueeIlwJl5CpT5l8RpoZXEOVtXYn8zzOJ7oGZYINRV9Pf8qKGLf3Dft7zKBP832I3PQjeok7F
 yjt+9S+KgSFSHP3Pa4E7lsSdWhSlHYNdG/czhoUkSCN09C0rEK93wxACx3vtxPLjXu6RptBw
 3dRq7n+mQChEB1am0BueV1JZaBboIL0AGlSJkm23kw==
In-Reply-To: <0ea6be58-0e04-4172-87cd-064a3e4a43bc@suse.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi,

On 15/01/2025 14:34, Thomas Zimmermann wrote:
> Hi
> 
> 
> Am 15.01.25 um 13:06 schrieb Tomi Valkeinen:
>> Hi,
>>
>> On 15/01/2025 13:37, Thomas Zimmermann wrote:
>>> Hi
>>>
>>>
>>> Am 15.01.25 um 11:58 schrieb Tomi Valkeinen:
>>> [...]
>>>>> These are all good points. Did you read my discussion with Andy on 
>>>>> patch 2? I think it resolves all the points you have. The current 
>>>>> CREATE_DUMB 
>>>>
>>>> I had missed the discussion, and, indeed, the patch you attached 
>>>> fixes the problem on Xilinx.
>>>
>>> Great. Thanks for testing.
>>>
>>>>
>>>>> ioctl is unsuited for anything but the simple RGB formats. The bpp 
>>>>
>>>> It's a bit difficult to use, but is it really unsuited? 
>>>> bitsperpixel, width and height do give an exact pitch and size, do 
>>>> they not? It does require the userspace to handle the subsampling 
>>>> and planes, though, so far from perfect.
>>>
>>> The bpp value sets the number of bits per pixel; except for bpp==15 
>>> (XRGB1555), where it sets the color depth. OR bpp is the color depth; 
>>> except for bpp==32 (XRGB8888), where it is the number of bits per 
>>> pixel. It's therefore best to interpret it like a color-mode enum.
>>
>> Ah, right... That's horrible =).
>>
>> And I assume it's not really possible to define the bpp to mean bits 
>> per pixel, except for a few special cases like 15?
>>
>> Why do we even really care about color depth here? We're just 
>> allocating memory. Doesn't DIV_ROUND_UP(args->bpp, SZ_8) work fine for 
>> XRGB1555 too?
> 
> Drivers always did that, but it does not work correctly for (bpp < 8). 
> As we already have helpers to deal with bpp, it makes sense to use 
> them.  This also aligns dumb buffers with the kernel's video= parameter, 
> which as the same odd semantics. The fallback that uses bpp directly 
> will hopefully be the exception.

Hmm, well... If we had a 64-bit RGB format in the list of "legacy fb 
formats", I wouldn't have noticed anything. And if I would just use 32 
as the bpp, and adjust width accordingly, it would also have worked. So, 
I expect the fallback to be an exception,

And by working I mean that I can run my apps fine, but the internal 
operation would sure be odd: allocating any YUV buffer will cause 
drm_mode_size_dumb() to get an RGB format from 
drm_driver_color_mode_format(), and get a drm_format_info_min_pitch() 
for an RGB format.

>>>> So, I'm all for a new ioctl, but I don't right away see why the 
>>>> current ioctl couldn't be used. Which makes me wonder about the 
>>>> drm_warn() in your patch, and the "userspace throws in arbitrary 
>>>> values for bpp and relies on the kernel to figure it out". Maybe I'm 
>>>> missing something here.
>>>
>>> I was unsure about the drm_warn() as well. It's not really wrong to 
>>> have odd bpp values, but handing in an unknown bpp value might point 
>>> to a user-space error. At least there should be a drm_dbg().
>>>
>>>>
>>>>> parameter is not very precise. The solution would be a new ioctl 
>>>>> call that receives the DRM format and returns a buffer for each 
>>>>> individual plane.
>>>>
>>>> Yes, I think that makes sense. That's a long road, though =). So my 
>>>> question is, is CREATE_DUMB really unsuitable for other than simple 
>>>> RGB formats, or can it be suitable if we just define how the 
>>>> userspace should use it for multiplanar, subsampled formats?
>>>
>>> That would duplicate format and hardware information in user-space. Some 
>>
>> But we already have that, don't we? We have drivers and userspace that 
>> support, say, NV12 via dumb buffers. But (correct me if I'm wrong) we 
>> don't document how CREATE_DUMB has to be used to allocate multiplanar 
>> subsampled buffers, so the userspace devs have to "guess".
> 
> Yeah, there are constrains in the scanline and buffer alignments and 
> orientation. And if we say that bpp==12 means NV12, it will be a problem 
> for all other cases where bpp==12 makes sense.

I feel I still don't quite understand. Can't we define and document 
CREATE_DUMB like this:

If (bpp < 8 || is_power_of_two(bpp))
	bpp means bitsperpixel
	pitch is args->width * args->bpp / 8, aligned up to driver-specific-align
else
	bpp is a legacy parameter, and we deal with it case by case.
	list the cases and what they mean

And describe that when allocating subsampled buffers, the caller must 
adjust the width and height accordingly. And that the bpp and width can 
also refer to pixel groups.

Or if the currently existing code prevents the above for 16 and 32 bpps, 
how about defining that any non-RGB or not-simple buffer has to be 
allocated with bpp=8, and the userspace has to align the pitch correctly 
according to the format and platform's hw restrictions?

  Tomi



From xen-devel-bounces@lists.xenproject.org Wed Jan 15 13:41:59 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 13:41:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872544.1283514 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY3ed-0000IX-Bb; Wed, 15 Jan 2025 13:41:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872544.1283514; Wed, 15 Jan 2025 13:41:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY3ed-0000IQ-6L; Wed, 15 Jan 2025 13:41:55 +0000
Received: by outflank-mailman (input) for mailman id 872544;
 Wed, 15 Jan 2025 13:41:53 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Wvqr=UH=bounce.vates.tech=bounce-md_30504962.6787bb1b.v1-9919a5251a274e66bc5c60372eae440b@srs-se1.protection.inumbo.net>)
 id 1tY3eb-0000ID-I8
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 13:41:53 +0000
Received: from mail178-22.suw51.mandrillapp.com
 (mail178-22.suw51.mandrillapp.com [198.2.178.22])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7862ea71-d346-11ef-a0e1-8be0dac302b0;
 Wed, 15 Jan 2025 14:41:50 +0100 (CET)
Received: from pmta13.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail178-22.suw51.mandrillapp.com (Mailchimp) with ESMTP id
 4YY6bv5XS2zGlswDW
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 13:41:47 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 9919a5251a274e66bc5c60372eae440b; Wed, 15 Jan 2025 13:41:47 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 7862ea71-d346-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1736948507; x=1737209007;
	bh=ege9jiwZ4C5yykyiqHT3wU0a3MG1WEBInyWyycWHsOU=;
	h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=GHVpzdlk6Yd1Wtmg2ocFRc7hMM4rK22TzMr+9yODNYieJl3kmSspHvgYTZv5mrZWp
	 S9rxiaydZ9Q05I773e/rTqKr8rqqC0A916h3e70ach+HJikum/MYpQkNUTw17i7jjG
	 +EgumntSOGaW0N0wS1IYUS1aTGR4rSA+h9+7ouuXgYpsS5gnDgPFG66frb3uI12cs+
	 brYwLckLWNO/JY51STCwYTzgnQZHwAw7AT89rbwRgvOA7pOwr9WJmW+t8Tt9tzec6O
	 NGnLzaTOOacBNsxxSy5GeywVLWxMUGOY7wfrrl3cHTSWrKSCUTsNR/b2UdUPC7lYq9
	 QEqQE9gKdM7Rg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1736948507; x=1737209007; i=yann.dirson@vates.tech;
	bh=ege9jiwZ4C5yykyiqHT3wU0a3MG1WEBInyWyycWHsOU=;
	h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=v5EJp8N6B8MOiA3ZYeLTEq9FkveJo8x90bttEScgGQlCocHb9skw8YVDt1RVMR1Dq
	 /Wj887x7ZMsItLSNMvKwT39rN2alDN0PmCLnQbMNEl0QtbrKQ9tFdyl96kgt/vD8ZZ
	 ARAd/dwx9GeIELg3ZxgFfLIg9XDEm9iBy4OY3x3avFYocYoN3McTPmhoA0SE45Zj3p
	 4S1CnkbJC6F8FofGJmMuRgGNoC7sTe9gYRfrq+jG8UXP8+D0MDAT+AjCzF2JY1IDhh
	 42f8gy8Co1+21otCjTAvD3Y60dvJHnAveDVONcjioAe6kM2gFRYAWWCLFM6p63vGaa
	 1kpt72XocPGNA==
From: "Yann Dirson" <yann.dirson@vates.tech>
Subject: =?utf-8?Q?Re:=20[XEN=20PATCH]=20docs/sphinx:=20overview=20of=20serial=20consoles?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1736948505670
Message-Id: <15b4e4f6-eb79-4f67-850e-deb2c0659826@vates.tech>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>, xen-devel@lists.xenproject.org
Cc: "Anthony PERARD" <anthony.perard@vates.tech>, "Michal Orzel" <michal.orzel@amd.com>, "Jan Beulich" <jbeulich@suse.com>, "Julien Grall" <julien@xen.org>, "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>, "Stefano Stabellini" <sstabellini@kernel.org>
References: <d40643bf0730c2f227f2dfbc7985ba0b5f8878cf.1736942790.git.yann.dirson@vates.tech> <58753517-26b6-47cc-a060-e8b5a88639bd@citrix.com>
In-Reply-To: <58753517-26b6-47cc-a060-e8b5a88639bd@citrix.com>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.9919a5251a274e66bc5c60372eae440b?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250115:md
Date: Wed, 15 Jan 2025 13:41:47 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 1/15/25 14:27, Andrew Cooper wrote:
> On 15/01/2025 12:07 pm, Yann Dirson wrote:
>> ---
>>
>> Notes:
>>      This is a very preliminar first draft for comments:
>>      
>>      - would this structuration be adequate?
>>      
>>      - Is my basic understanding correct, are those first enumerations
>>      correct? (some of it come solely from console.txt, which has alread=
y
>>      proven to be seriously outdated on many aspects)
>>      
>>      - is there some doc about the qemu/ioemu backend I missed?  Is it a=
ble to
>>      deal with PV consoles, or is it just for virtual UARTS?
> 
> Consoles are probably one of the harder areas to get started.
> 
> First, we need to distinguish between host consoles and guest consoles,
> because admin-guide/console could be either/both.

OK, so this would rather be admin-guide/guest-console or even 
admin-guide/guest-serial-console.

> 
> Host consoles are mostly UARTs, but we have several flavours including
> usb2 and usb3 flavours.=C2=A0 ARM has extensive early printk support, whi=
ch
> RISC-V/PPC are borrowing too.=C2=A0 Xen is also capable of using
> hypervisor-provided consoles too.

Let's leave this for a later admin-guide/host-console :)

> For guest consoles, there's the plain CONSOLEIO hypercalls, and whether
> they do anything interesting depend on whether you're dom0 and/or the
> CONFIG_VERBOSE build setting.

I would see that part in something like guest-guide/serial-console.

>=C2=A0 ARM has the ability to mutiplex output
> from different guests onto the host console.=C2=A0 There's also the
> xenconsoled, things emulated by Qemu or other emulators, and even the
> in-Xen UART emulator currently on list.
> 
> Then, for specific guests, they've got different console options
> available.=C2=A0 e.g. Linux has a dedicated earlyconsole option for Xen (=
uses
> CONSOLEIO) as well as an hvc driver.

Those definitely seem in the scope for the doc I was thinking about

> And ideally we want all this information documented nicely, between "how
> do I set up debugging for my guest"

Debugging is an obvious superset, would hint to a "Guest debugging" 
section.  Maybe it would be enough to add admin-guide/guest-debugging as 
intermediate level, but not be necessary to create an additional level 
of subdir for the contents?

 > and how do I write a driver for xenconsoled.

That one does not really fit in either of admin-guide, guest-guide, and 
hypervisor-guide.  Something like toolstack-implementation-guide?



Yann Dirson | Vates Platform Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech



From xen-devel-bounces@lists.xenproject.org Wed Jan 15 13:45:05 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 13:45:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872554.1283523 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY3hg-0000rY-NC; Wed, 15 Jan 2025 13:45:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872554.1283523; Wed, 15 Jan 2025 13:45:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY3hg-0000rR-Ja; Wed, 15 Jan 2025 13:45:04 +0000
Received: by outflank-mailman (input) for mailman id 872554;
 Wed, 15 Jan 2025 13:45:03 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=4o+i=UH=cloud.com=bernhard.kaindl@srs-se1.protection.inumbo.net>)
 id 1tY3he-0000rL-V5
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 13:45:03 +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 ea87a20e-d346-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 14:45:00 +0100 (CET)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-43618283dedso64761265e9.3
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 05:45:00 -0800 (PST)
Received: from localhost ([185.68.248.203]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a8e4b80c9sm17489552f8f.84.2025.01.15.05.44.59
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 15 Jan 2025 05:44:59 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ea87a20e-d346-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736948700; x=1737553500; 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=yOnHHZIX8J37zXnZstGifH2YDQRYPB0JvqGcQB48250=;
        b=jfSh1U1yYWjX29Gk0+ZlFK8pLbUovSByYUNpxe4oovWPlV0f7/ELDKqnVX027FmVtD
         +SQ0/Il6SPr3fvkW4Hrg6tGwSnjShU8ZmoideLbrWtmkkun8hA0fZKC7LJFVAXaJB/vI
         /d9RKQqHVlh6925LpPRpd2Gp4ec+wMDSRO/+w=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736948700; x=1737553500;
        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=yOnHHZIX8J37zXnZstGifH2YDQRYPB0JvqGcQB48250=;
        b=hKpp6ExOL3ub80nX8Rwyf9wL0Th+07DAfrsgZBNQidgWz/WY2vM9IpN0jH4onq/3V/
         2hYEHmZUreYZa+5QZEaMXKsJsbsj05CfCyHZy/39zTfN1wMi6WRq1x6y6QDL9ZckNrdp
         qeDxlscafuonmkgtIORuhdQBYAGYE3fKIUX0oopAnAMLOchUiLc16eB1R/jmyUIxE5Z/
         jBd1OIc8p2WG065iNEzhuHIZDlPme6US3t9hrURTySwPtfBzVmO1fnxqyVqzfQhlo70W
         p4Rycv7fCzsNBmzO77wa7f761iwGYHSxniHH+3reRMjzv31w3Yz4ouNb/I6/Q9gO0y41
         GtGQ==
X-Gm-Message-State: AOJu0YxCvHiS1gooV5wyOkuMczizynEvGj16U5d5fG33ZqL/Cqe2Wn5G
	lK38xj8v+llFsDnsb6XljZ5SZEl5Cj4KYbAPz2oARsZbryU38ieO3j+QotcMsPPrAcLJ2g5zYqZ
	AcGXpSg==
X-Gm-Gg: ASbGncubTE+dxNbdvr+uXLhkHOMpyj+4fkSgYcAnBZkudXuXiI+5mmxb2JxIDWAtMix
	5r/nxpFogtRTAH1rbJEeskHLP6Wo2MxFMFIkREktXJE0gWweqC0VSgiBBMtpqi2xmE54QQOX9pL
	aQSxjxhE+jaxaOJSn8fJcchoW9sZ2KU+S317R3KyutbwSrtC1AHBquvTSLZeAO95XxP/0QKLFMI
	WNHNSEifA0m3eVHtTpnM8VelK/+3CfzZAwzUP3sT9uRL/akHvc9uEP7oF1e6g==
X-Google-Smtp-Source: AGHT+IFpyYKuiVL5NbAKLI2ifsePSYAUGvl21jANUA+UTH3GPyBbIF7X8iDUcSfDCiueLjDGTxDNxw==
X-Received: by 2002:a05:600c:5117:b0:434:fe62:28c1 with SMTP id 5b1f17b1804b1-436e26cfe5cmr127768285e9.18.1736948700035;
        Wed, 15 Jan 2025 05:45:00 -0800 (PST)
From: Bernhard Kaindl <bernhard.kaindl@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Bernhard Kaindl <bernhard.kaindl@cloud.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH] Design docs: Fix some typos in the design docs
Date: Wed, 15 Jan 2025 14:44:55 +0100
Message-ID: <692dabc63953fb0d33536f87e4c5c147ba6ce11c.1736948633.git.bernhard.kaindl@cloud.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Skimming through the design docs, I saw some typos that needed fixing.

---
Comments for reviewers (not for the commit message itself):

Sample typos (some are not easy to spot):
- heirarchical: (ei->ie)
- implementaiton: (it->ti)
- comprimised: (i->o)
- contol->control (r)

PS: I did the fixes using LTeX in an IDE and re-checked the mail too.

Signed-off-by: Bernhard Kaindl <bernhard.kaindl@cloud.com>
---
 docs/designs/argo.pandoc                |  4 ++--
 docs/designs/nested-svm-cpu-features.md | 12 ++++++------
 docs/designs/qemu-deprivilege.md        |  8 ++++----
 docs/designs/xenstore-migration.md      |  2 +-
 docs/features/qemu-deprivilege.pandoc   |  2 +-
 5 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/docs/designs/argo.pandoc b/docs/designs/argo.pandoc
index e18aacea7c..cd854d2a7a 100644
--- a/docs/designs/argo.pandoc
+++ b/docs/designs/argo.pandoc
@@ -58,7 +58,7 @@ concurrency.
 
 Avoidance of deadlock is essential and since state must frequently be updated
 that pertains to more than one domain, a locking protocol defines which locks
-are needed and the order of their acquistion.
+are needed and the order of their acquisition.
 
 ## Structure
 
@@ -127,7 +127,7 @@ by the domain.
 
 ## Hierarchical Locking Model and Protocol
 
-The locking discipline within the Argo code is heirarchical and utilizes
+The locking discipline within the Argo code is hierarchical and utilizes
 reader/writer locks to enable increased concurrency when operations do not
 conflict. None of the Argo locks are reentrant.
 
diff --git a/docs/designs/nested-svm-cpu-features.md b/docs/designs/nested-svm-cpu-features.md
index 837a96df05..c855748141 100644
--- a/docs/designs/nested-svm-cpu-features.md
+++ b/docs/designs/nested-svm-cpu-features.md
@@ -22,7 +22,7 @@ leaf 8000000A:edx
   from the L1 hypervisor's perspective to be as close as possible to
   the original hardware.  In particular, the behavior of the hardware
   on error paths 1) is not easy to understand or test, 2) can be the
-  source of surprising vulnerabiliies.  (See XSA-7 for an example of a
+  source of surprising vulnerabilities.  (See XSA-7 for an example of a
   case where subtle error-handling differences can open up a privilege
   escalation.)  We should avoid emulating any bit of the hardware with
   complex error paths if we can at all help it.
@@ -59,11 +59,11 @@ leaf 8000000A:edx
 
 - 2 `SVML` *SVM Lock*: Not required for L0, not provided to L1
 
-  Seems to be aboult enabling an operating system to prevent "blue
+  Seems to be about enabling an operating system to prevent "blue
   pill" attacks against itself.
 
   Xen doesn't use it, nor provide it; so it would need to be
-  implementend.  The best way to protect a guest OS is to leave nested
+  implemented.  The best way to protect a guest OS is to leave nested
   virt disabled in the tools.
 
 - 3 `NRIPS` NRIP Save: Require for both L0 and L1
@@ -78,8 +78,8 @@ leaf 8000000A:edx
   The main putative use for this would be trying to maintain an
   invariant TSC across cores with different clock speeds, or after a
   migrate.  Unlike others, this doesn't have an error path to worry
-  about compatibility-wise; and according to tests done when nestedSVM
-  was first implemented, it's actually faster to emliate TscRateMSR in
+  about compatibility-wise; and according to tests done when nested SVM
+  was first implemented, it's actually faster to emulate TscRateMSR in
   the L0 hypervisor than for L1 to attempt to emulate it itself.
 
   However, using this properly in L0 will take some implementation
@@ -89,7 +89,7 @@ leaf 8000000A:edx
  - 5 `VmcbClean`: VMCB Clean Bits: Not required by L0, provide to L1
 
   This is a pure optimization, both on the side of the L0 and L1.  The
-  implementaiton for L1 is entirely Xen-side, so can be provided even
+  implementation for L1 is entirely Xen-side, so can be provided even
   on hardware that doesn't provide it.  And it's purely an
   optimization, so could be "implemented" by ignoring the bits
   entirely.
diff --git a/docs/designs/qemu-deprivilege.md b/docs/designs/qemu-deprivilege.md
index f12b1a3ae3..603491f24d 100644
--- a/docs/designs/qemu-deprivilege.md
+++ b/docs/designs/qemu-deprivilege.md
@@ -22,7 +22,7 @@ The following restrictions are currently implemented.
 '''Description''': As mentioned above, having QEMU switch to a
 non-root user, one per domain id.  Not being the root user limits what
 a compromised QEMU process can do to the system, and having one user
-per domain id limits what a comprimised QEMU process can do to the
+per domain id limits what a compromised QEMU process can do to the
 QEMU processes of other VMs.
 
 '''Implementation''': The toolstack adds the following to the qemu command-line:
@@ -79,8 +79,8 @@ Then adds the following to the qemu command-line:
 ## Namespaces for unused functionality (Linux only)
 
 '''Description''': QEMU doesn't use the functionality associated with
-mount and IPC namespaces. (IPC namespaces contol non-file-based IPC
-mechanisms within the kernel; unix and network sockets are not
+mount and IPC namespaces. (IPC namespaces control non-file-based IPC
+mechanisms within the kernel; Unix and network sockets are not
 affected by this.)  Making separate namespaces for these for QEMU
 won't affect normal operation, but it does mean that even if other
 restrictions fail, the process won't be able to even name system mount
@@ -251,7 +251,7 @@ executing QEMU.  (But this would then require other changes to create
 the QMP socket, VNC socket, and so on).
 
 It should be noted that `-sandbox` is implemented as a blacklist, not
-a whitelist; that is, it disables known-unsed functionality which may
+a whitelist; that is, it disables known-unused functionality which may
 be harmful, rather than disabling all functionality except that known
 to be safe and needed.  This is unfortunately necessary since qemu
 doesn't know what system calls libraries might end up making.  (See
diff --git a/docs/designs/xenstore-migration.md b/docs/designs/xenstore-migration.md
index 5022268386..082314bf72 100644
--- a/docs/designs/xenstore-migration.md
+++ b/docs/designs/xenstore-migration.md
@@ -372,7 +372,7 @@ or modified by a transaction for which there is also a `TRANSACTION_DATA`
 record previously present).
 
 Each _committed_ node in the stream is required to have an already known parent
-node. A parent node is known if it was either in the node data base before the
+node. A parent node is known if it was either in the node database before the
 stream was started to be processed, or if a `NODE_DATA` record for that parent
 node has already been processed in the stream.
 
diff --git a/docs/features/qemu-deprivilege.pandoc b/docs/features/qemu-deprivilege.pandoc
index 4ef119c821..915e38d8c9 100644
--- a/docs/features/qemu-deprivilege.pandoc
+++ b/docs/features/qemu-deprivilege.pandoc
@@ -25,7 +25,7 @@ dm_restrict is a set of operations to restrict QEMU running in domain
 
  1. Mechanisms to restrict QEMU to only being able to affect its own
 domain
- 2. Mechanisms to restruct QEMU's ability to interact with domain 0.
+ 2. Mechanisms to restrict QEMU's ability to interact with domain 0.
 
 # User details
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Jan 15 13:45:57 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 13:45:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872564.1283533 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY3iX-0001QI-3m; Wed, 15 Jan 2025 13:45:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872564.1283533; Wed, 15 Jan 2025 13:45:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY3iX-0001QB-0d; Wed, 15 Jan 2025 13:45:57 +0000
Received: by outflank-mailman (input) for mailman id 872564;
 Wed, 15 Jan 2025 13:45:55 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=AzvQ=UH=suse.de=tzimmermann@srs-se1.protection.inumbo.net>)
 id 1tY3iV-0001Pz-Bj
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 13:45:55 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de
 [2a07:de40:b251:101:10:150:64:1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0a21543e-d347-11ef-a0e1-8be0dac302b0;
 Wed, 15 Jan 2025 14:45:54 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id 49A6821249;
 Wed, 15 Jan 2025 13:45:53 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id C332E139CB;
 Wed, 15 Jan 2025 13:45:52 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id ctv9LRC8h2cUZgAAD6G6ig
 (envelope-from <tzimmermann@suse.de>); Wed, 15 Jan 2025 13:45:52 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 0a21543e-d347-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736948753; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=RYyfSaVw6g5xMH+JMHghdrGYmdnvDx9Zhz3pv4DK3Xw=;
	b=TFLFJF3XySI2ZDMNWqLtnYi9I2CkKelN5grA2a/4kQ0P1TqzT7tSXr4h7/8Ne+Qn4kV+7e
	tAGkQWxCqwepai1cL8InSYizan9Cfu381FxyhQuTclpqleEGeeZqfcFFnvdBZ7J8flDV0C
	llifefl5Ww7OTjsLlhec4er0F+GluGU=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736948753;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=RYyfSaVw6g5xMH+JMHghdrGYmdnvDx9Zhz3pv4DK3Xw=;
	b=qSe023yuize08pZVM2Q7kCwRc6uXGuV4ZJmU+N6SFdTO1SX53lQO+DbJQKBt7UwMutw4m7
	wijvbfZ3D9R6vCBA==
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.de header.s=susede2_rsa header.b=TFLFJF3X;
	dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=qSe023yu
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1736948753; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=RYyfSaVw6g5xMH+JMHghdrGYmdnvDx9Zhz3pv4DK3Xw=;
	b=TFLFJF3XySI2ZDMNWqLtnYi9I2CkKelN5grA2a/4kQ0P1TqzT7tSXr4h7/8Ne+Qn4kV+7e
	tAGkQWxCqwepai1cL8InSYizan9Cfu381FxyhQuTclpqleEGeeZqfcFFnvdBZ7J8flDV0C
	llifefl5Ww7OTjsLlhec4er0F+GluGU=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1736948753;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=RYyfSaVw6g5xMH+JMHghdrGYmdnvDx9Zhz3pv4DK3Xw=;
	b=qSe023yuize08pZVM2Q7kCwRc6uXGuV4ZJmU+N6SFdTO1SX53lQO+DbJQKBt7UwMutw4m7
	wijvbfZ3D9R6vCBA==
Message-ID: <4af0b6a7-c16a-4187-bbf5-365a9c86de21@suse.de>
Date: Wed, 15 Jan 2025 14:45:51 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with
 drm_mode_size_dumb()
To: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>,
 maarten.lankhorst@linux.intel.com, mripard@kernel.org, airlied@gmail.com,
 simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org, linux-mediatek@lists.infradead.org,
 freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
 imx@lists.linux.dev, linux-samsung-soc@vger.kernel.org,
 nouveau@lists.freedesktop.org, virtualization@lists.linux.dev,
 spice-devel@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org,
 linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org,
 intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org,
 Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
 Andy Yan <andyshrk@163.com>
References: <20250109150310.219442-1-tzimmermann@suse.de>
 <20250109150310.219442-26-tzimmermann@suse.de>
 <cdbe483d-0895-47aa-8c83-1c28220f4a02@ideasonboard.com>
 <bc97b92e-7f8a-4b92-af8a-20fa165ead55@suse.de>
 <f3ba05c7-6e49-4641-a3f9-ba418ebdb7c3@ideasonboard.com>
 <c6735280-7c32-4319-8ca9-a7305d8117c3@suse.de>
 <d67adb03-5cd0-4ac9-af58-cf4446dacee3@ideasonboard.com>
 <0ea6be58-0e04-4172-87cd-064a3e4a43bc@suse.de>
 <f35cb350-6be9-48ca-ad7e-e9dd418281d5@ideasonboard.com>
Content-Language: en-US
From: Thomas Zimmermann <tzimmermann@suse.de>
Autocrypt: addr=tzimmermann@suse.de; keydata=
 xsBNBFs50uABCADEHPidWt974CaxBVbrIBwqcq/WURinJ3+2WlIrKWspiP83vfZKaXhFYsdg
 XH47fDVbPPj+d6tQrw5lPQCyqjwrCPYnq3WlIBnGPJ4/jreTL6V+qfKRDlGLWFjZcsrPJGE0
 BeB5BbqP5erN1qylK9i3gPoQjXGhpBpQYwRrEyQyjuvk+Ev0K1Jc5tVDeJAuau3TGNgah4Yc
 hdHm3bkPjz9EErV85RwvImQ1dptvx6s7xzwXTgGAsaYZsL8WCwDaTuqFa1d1jjlaxg6+tZsB
 9GluwvIhSezPgnEmimZDkGnZRRSFiGP8yjqTjjWuf0bSj5rUnTGiyLyRZRNGcXmu6hjlABEB
 AAHNJ1Rob21hcyBaaW1tZXJtYW5uIDx0emltbWVybWFubkBzdXNlLmRlPsLAjgQTAQgAOAIb
 AwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftODH
 AAoJEGgNwR1TC3ojx1wH/0hKGWugiqDgLNXLRD/4TfHBEKmxIrmfu9Z5t7vwUKfwhFL6hqvo
 lXPJJKQpQ2z8+X2vZm/slsLn7J1yjrOsoJhKABDi+3QWWSGkaGwRJAdPVVyJMfJRNNNIKwVb
 U6B1BkX2XDKDGffF4TxlOpSQzdtNI/9gleOoUA8+jy8knnDYzjBNOZqLG2FuTdicBXblz0Mf
 vg41gd9kCwYXDnD91rJU8tzylXv03E75NCaTxTM+FBXPmsAVYQ4GYhhgFt8S2UWMoaaABLDe
 7l5FdnLdDEcbmd8uLU2CaG4W2cLrUaI4jz2XbkcPQkqTQ3EB67hYkjiEE6Zy3ggOitiQGcqp
 j//OwE0EWznS4AEIAMYmP4M/V+T5RY5at/g7rUdNsLhWv1APYrh9RQefODYHrNRHUE9eosYb
 T6XMryR9hT8XlGOYRwKWwiQBoWSDiTMo/Xi29jUnn4BXfI2px2DTXwc22LKtLAgTRjP+qbU6
 3Y0xnQN29UGDbYgyyK51DW3H0If2a3JNsheAAK+Xc9baj0LGIc8T9uiEWHBnCH+RdhgATnWW
 GKdDegUR5BkDfDg5O/FISymJBHx2Dyoklv5g4BzkgqTqwmaYzsl8UxZKvbaxq0zbehDda8lv
 hFXodNFMAgTLJlLuDYOGLK2AwbrS3Sp0AEbkpdJBb44qVlGm5bApZouHeJ/+n+7r12+lqdsA
 EQEAAcLAdgQYAQgAIAIbDBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftOH6AAoJEGgNwR1T
 C3ojVSkIALpAPkIJPQoURPb1VWjh34l0HlglmYHvZszJWTXYwavHR8+k6Baa6H7ufXNQtThR
 yIxJrQLW6rV5lm7TjhffEhxVCn37+cg0zZ3j7zIsSS0rx/aMwi6VhFJA5hfn3T0TtrijKP4A
 SAQO9xD1Zk9/61JWk8OysuIh7MXkl0fxbRKWE93XeQBhIJHQfnc+YBLprdnxR446Sh8Wn/2D
 Ya8cavuWf2zrB6cZurs048xe0UbSW5AOSo4V9M0jzYI4nZqTmPxYyXbm30Kvmz0rYVRaitYJ
 4kyYYMhuULvrJDMjZRvaNe52tkKAvMevcGdt38H4KSVXAylqyQOW5zvPc4/sq9c=
In-Reply-To: <f35cb350-6be9-48ca-ad7e-e9dd418281d5@ideasonboard.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 49A6821249
X-Spam-Level: 
X-Spamd-Result: default: False [-3.01 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_DKIM_ALLOW(-0.20)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	URIBL_BLOCKED(0.00)[suse.de:dkim,suse.de:mid];
	MIME_TRACE(0.00)[0:+];
	RCPT_COUNT_TWELVE(0.00)[21];
	ARC_NA(0.00)[];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	FREEMAIL_TO(0.00)[ideasonboard.com,linux.intel.com,kernel.org,gmail.com,ffwll.ch];
	RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	FREEMAIL_ENVRCPT(0.00)[163.com,gmail.com];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	MID_RHS_MATCH_FROM(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received];
	DKIM_TRACE(0.00)[suse.de:+];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FREEMAIL_CC(0.00)[lists.freedesktop.org,lists.infradead.org,vger.kernel.org,lists.linux.dev,lists.xenproject.org,ideasonboard.com,163.com];
	RCVD_TLS_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:dkim,suse.de:mid,imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns]
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Rspamd-Action: no action
X-Spam-Score: -3.01
X-Spam-Flag: NO

Hi


Am 15.01.25 um 14:33 schrieb Tomi Valkeinen:
[...]
>> Yeah, there are constrains in the scanline and buffer alignments and 
>> orientation. And if we say that bpp==12 means NV12, it will be a 
>> problem for all other cases where bpp==12 makes sense.
>
> I feel I still don't quite understand. Can't we define and document 
> CREATE_DUMB like this:
>
> If (bpp < 8 || is_power_of_two(bpp))
>     bpp means bitsperpixel
>     pitch is args->width * args->bpp / 8, aligned up to 
> driver-specific-align
> else
>     bpp is a legacy parameter, and we deal with it case by case.
>     list the cases and what they mean
>
> And describe that when allocating subsampled buffers, the caller must 
> adjust the width and height accordingly. And that the bpp and width 
> can also refer to pixel groups.
>
> Or if the currently existing code prevents the above for 16 and 32 
> bpps, how about defining that any non-RGB or not-simple buffer has to 
> be allocated with bpp=8, and the userspace has to align the pitch 
> correctly according to the format and platform's hw restrictions?

What if a hardware requires certain per-format alignments? Or requires 
certain alignments for each plane? Or only supports tile modes? Or has 
strict limits on the maximum buffer size?

It is not possible to encode all this in a simple 32-bit value. So 
user-space code has to be aware of all this and tweak bpp-based 
allocation to make it work. Obviously you can use the current UAPI for 
your use case. It's just not optimal or future proof.

Best regards
Thomas

>
>
>  Tomi
>

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)



From xen-devel-bounces@lists.xenproject.org Wed Jan 15 13:58:09 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 13:58:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872575.1283542 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY3uD-0003Vt-4O; Wed, 15 Jan 2025 13:58:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872575.1283542; Wed, 15 Jan 2025 13:58:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY3uD-0003Vm-1o; Wed, 15 Jan 2025 13:58:01 +0000
Received: by outflank-mailman (input) for mailman id 872575;
 Wed, 15 Jan 2025 13:58:00 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=4o+i=UH=cloud.com=bernhard.kaindl@srs-se1.protection.inumbo.net>)
 id 1tY3uC-0003Vg-LJ
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 13:58:00 +0000
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com
 [2a00:1450:4864:20::32a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b9f61f37-d348-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 14:57:58 +0100 (CET)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-43622267b2eso69939195e9.0
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 05:57:58 -0800 (PST)
Received: from localhost ([185.68.248.203]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-437c755004dsm24744045e9.40.2025.01.15.05.57.56
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 15 Jan 2025 05:57:57 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b9f61f37-d348-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736949478; x=1737554278; 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=NVYFuC6PVZUV0deiVHJWehXQseTiVDXXhyBaRkG7Lt4=;
        b=XTAvJ/JwljL7gMkMMxBPbqU80oWaKadjhWrw/XgipGYNXwDxOTiM3Mxvw9g32WzcMI
         1HvRc0uuQ3cNNiWpuIEY4GwSVa09a8GzjT625+Ocx/21/mYusFZ/2SNIkteOJCL101l4
         ioEnWhKKWEzsb8AeyaC2pUeLecT42AYn5EjC4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736949478; x=1737554278;
        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=NVYFuC6PVZUV0deiVHJWehXQseTiVDXXhyBaRkG7Lt4=;
        b=jaJxLnScsCdsdINzcDoI2gKNbi+KAz4C7g+knGP2Nvteir8Xn459ymDJ7qZb12ZqcG
         GlJwRFU5s8Fi/Q5WQWndQ2nspVe+dWv7RZ+HMUruwA5ESccjU1W5EGI0ClImIEbT3oG7
         ytFZ4nDr3BnQKUS/o3Ug/ZSuCY+kxQNLdS5xRy69sTU/lHu39QdliNuHlxO+viK3BVQq
         qaqD+QEY9yrYghaXoUu7KPRcwNabiUdIaKYpFQK/A24+7TB7VPqi5CZMSJJXyqddpUpI
         4MtIpe9g09RtnS6I5Tk3n2eOatsxljB0Cqp6IJqhY/+TplsIMq1npJWP6vR1KHx5wGt2
         wt+A==
X-Gm-Message-State: AOJu0YxqUro4jisfdJZsJFT5Mwcg14HrWwQ8LlSHQm5VXuHDUnP9rSGu
	+5DfoTAsrPPbUd3+ezchAgLLmZhO9ytIOTezo6H+HzWahAFXiA3gOP+SnXi5IHFOZzWz6UWWsTy
	dt7JBBQ==
X-Gm-Gg: ASbGncsVWd/fbIzvVJRZNqZrSjxiBTgWEvCY7HaY0YSKzM6HEW9Wk8Qz6bXpqTAVdQf
	/F8dSDYNZBi7OWCrQWlw7kK1cw5U/I6turkvLlsEmecQSBLPVu/jj9CMH//qlfMUFHrRIXJsKy4
	1oXbKUaM3M9JiyHLNrcmVePSdn+tYkQizVNWrTXKLI2nk759gfQ1dhOSuQ2bAsEHDTr+HN7E/Pz
	khNCfHwEyLklDqcD3kyvfc7JRfQw1F9uOLq/Stph/DDkhEp1dF0I4RMtlYd8Q==
X-Google-Smtp-Source: AGHT+IFP7zeDNGf9Z5t4SqMLgfP9iINqrDeVFQCSEK1fNRUxn7VhctDM7Kwl+EJdlZgdJCB47mhTwg==
X-Received: by 2002:a05:600c:1e09:b0:436:e751:e445 with SMTP id 5b1f17b1804b1-436e751e61fmr280515055e9.5.1736949477597;
        Wed, 15 Jan 2025 05:57:57 -0800 (PST)
From: Bernhard Kaindl <bernhard.kaindl@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Bernhard Kaindl <bernhard.kaindl@cloud.com>,
	Anthony PERARD <anthony.perard@vates.tech>
Subject: [PATCH] Manual pages: Fix a few typos
Date: Wed, 15 Jan 2025 14:57:54 +0100
Message-ID: <3093091e43220a0e6f698f7b3f5dafc5eba2d021.1736949423.git.bernhard.kaindl@cloud.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

While skimming through the manual pages, I spotted a few typos.

Signed-off-by: Bernhard Kaindl <bernhard.kaindl@cloud.com>
---
 docs/man/xen-vtpmmgr.7.pod       | 2 +-
 docs/man/xl-numa-placement.7.pod | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/docs/man/xen-vtpmmgr.7.pod b/docs/man/xen-vtpmmgr.7.pod
index 3286954568..95854adb08 100644
--- a/docs/man/xen-vtpmmgr.7.pod
+++ b/docs/man/xen-vtpmmgr.7.pod
@@ -297,7 +297,7 @@ extra option to launch vtpmmgr-stubdom domain on TPM 2.0, and ignore it on TPM
     |   Primary Seed   |
     +------------------+
 
-Now the secrets for the vTPMs are only being bound to the presence of thephysical
+Now the secrets for the vTPMs are only being bound to the presence of the physical
 TPM 2.0. Since using PCRs to seal the data can be an important security feature
 that users of the vtpmmgr rely on. I will replace TPM2_Bind/TPM2_Unbind with
 TPM2_Seal/TPM2_Unseal to provide as much security as it did for TPM 1.2 in later
diff --git a/docs/man/xl-numa-placement.7.pod b/docs/man/xl-numa-placement.7.pod
index 802f33060b..4d83f26d41 100644
--- a/docs/man/xl-numa-placement.7.pod
+++ b/docs/man/xl-numa-placement.7.pod
@@ -45,7 +45,7 @@ user, via the proper libxl calls or xl config item, it will be computed
 basing on the vCPUs' scheduling affinity.
 
 Notice that, even if the node affinity of a domain may change on-line,
-it is very important to "place" the domain correctly when it is fist
+it is very important to "place" the domain correctly when it is first
 created, as the most of its memory is allocated at that time and can
 not (for now) be moved easily.
 
@@ -94,7 +94,7 @@ this reason, NUMA aware scheduling has the potential of bringing
 substantial performances benefits, although this will depend on the
 workload.
 
-Notice that, for each vCPU, the following three scenarios are possbile:
+Notice that, for each vCPU, the following three scenarios are possible:
 
 =over
 
@@ -102,7 +102,7 @@ Notice that, for each vCPU, the following three scenarios are possbile:
 
 a vCPU I<is pinned> to some pCPUs and I<does not have> any soft affinity
 In this case, the vCPU is always scheduled on one of the pCPUs to which
-it is pinned, without any specific peference among them.
+it is pinned, without any specific preference among them.
 
 
 =item *
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Jan 15 14:07:57 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 14:07:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872585.1283552 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY43l-0005e1-1a; Wed, 15 Jan 2025 14:07:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872585.1283552; Wed, 15 Jan 2025 14:07:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY43k-0005du-Uy; Wed, 15 Jan 2025 14:07:52 +0000
Received: by outflank-mailman (input) for mailman id 872585;
 Wed, 15 Jan 2025 14:07:51 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <anthony@xenproject.org>) id 1tY43j-0005do-NP
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 14:07:51 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <anthony@xenproject.org>) id 1tY43c-0060qZ-2j;
 Wed, 15 Jan 2025 14:07:45 +0000
Received: from [2a01:e0a:1da:8420:b77:bd5:6e45:7633] (helo=l14)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from <anthony@xenproject.org>) id 1tY43c-006QEO-2K;
 Wed, 15 Jan 2025 14:07:44 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:
	References:Message-ID:Subject:Cc:To:From:Date;
	bh=armD6io0RmDqTc+/mOgyLi04ESlkXMV9/yglO9pLXw0=; b=ELCdo7gswT3tSOyYzBii/HjChq
	OL9zDBqY86FBvnzXED86mSomHdsc2VVW1LFbTGv0eUdGIjl0yD0mMmublkZJMWaagkKz5v+oYJ9i9
	HkrzVV0PhTYOIf2eR8nOY0GzWAu6qjR7uDtIwgmBQkQpLXIj5YrBYovgztrj6v/uZjpI=;
Date: Wed, 15 Jan 2025 15:07:40 +0100
From: Anthony PERARD <anthony@xenproject.org>
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: qemu-devel@nongnu.org, David Woodhouse <dwmw@amazon.co.uk>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 1/2] hw/xen: Add xs_node_read() helper function
Message-ID: <Z4fBLEig8GlAPCv2@l14>
References: <20250110093531.23221-1-roger.pau@citrix.com>
 <20250110093531.23221-2-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250110093531.23221-2-roger.pau@citrix.com>

On Fri, Jan 10, 2025 at 10:35:30AM +0100, Roger Pau Monne wrote:
> diff --git a/include/hw/xen/xen-bus-helper.h b/include/hw/xen/xen-bus-helper.h
> index d8dcc2f0107d..6478d25be5e6 100644
> --- a/include/hw/xen/xen-bus-helper.h
> +++ b/include/hw/xen/xen-bus-helper.h
> @@ -37,6 +37,10 @@ int xs_node_scanf(struct qemu_xs_handle *h,  xs_transaction_t tid,
>                    const char *node, const char *key, Error **errp,
>                    const char *fmt, ...)
>      G_GNUC_SCANF(6, 7);
> +char *xs_node_read(struct qemu_xs_handle *h, xs_transaction_t tid,
> +                   unsigned int *len, Error **errp,
> +                   const char *node_fmt, ...)
> +    G_GNUC_PRINTF(5, 6);

Could you add a comment about this new functions? It's quite different
from every other function in this header which deal with a xenstore
path. Every other function use "${node}/${key}" (As explain in the
comment above xs_node_vscanf()), but this one uses a printf format in
`node_fmt` (which could probably better be named `path_fmt` instead).

Otherwise, patch looks fine to me.

Cheers,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 14:11:30 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 14:11:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872594.1283563 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY47E-0007Y9-Gi; Wed, 15 Jan 2025 14:11:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872594.1283563; Wed, 15 Jan 2025 14:11:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY47E-0007Y2-De; Wed, 15 Jan 2025 14:11:28 +0000
Received: by outflank-mailman (input) for mailman id 872594;
 Wed, 15 Jan 2025 14:11:27 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=hmQ5=UH=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tY47D-0007Xw-7i
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 14:11:27 +0000
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com
 [2a00:1450:4864:20::533])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9ae3a6a3-d34a-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 15:11:25 +0100 (CET)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-5d3dce16a3dso1815205a12.1
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 06:11:25 -0800 (PST)
Received: from [10.81.35.177] ([46.149.103.15])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d99046a17fsm7355801a12.62.2025.01.15.06.11.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 15 Jan 2025 06:11:24 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9ae3a6a3-d34a-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736950285; x=1737555085; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=tIShKaRA+jgQz8dMNnf/9Ad7rDpwHLH3jtsJ0kxgsVM=;
        b=dmT1x8yaemM9lm+FLCuv6tpbg0WOckKUQcEr1+CqhmN0vQaLyRUyJ52jWRCTGfbnSZ
         y28m0E6PemgowuDWD1O1fxZx8Nzr3va7VyTGMlVMWuUqhcM5k2zlsEfWwezNOXb1R5Zn
         BK/GNjgGzPAbIb57iauEVrw9oOFGCvMBK6ho4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736950285; x=1737555085;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=tIShKaRA+jgQz8dMNnf/9Ad7rDpwHLH3jtsJ0kxgsVM=;
        b=pI+nJtO1Tjt9TgbfjGdsa7SzaxBin50nCT5Y1qwRu1b2r0mnhv2KGKG+/omwlSxkQl
         ZLA8i0Q9GXNeKY18pLd2RYCvRm3Tjevb6KMVLz9AOj6SJ0SEAGY8lCyXLDcKKKIzMVw6
         FN8/f3KTZ4TlME4Vg55tNIgpTWwvuOQIIATp1YAxc+WbRcR0NylV0+V0QOMYciLkK3p5
         iq/7L5aVH5u7Z7fTYiYhjGXfNLLXstF/CE51Zgi1zp4ux3veShY03aohjEHvg+IzXlI+
         hPKW8PNXF+OGxK/9iA4YGjsBl1aozPkV/vE3OdoTDhhP3x/4FPc7QPDbE11BgBCo4VZF
         lNjg==
X-Forwarded-Encrypted: i=1; AJvYcCWDzuAwxYRqftFAZf4ceOpu7H4kfog7A0qnzqJ7BMpiSYDNg9cbIbJvUUF/2jSuI8SAV6TaDuNsvHo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyU/HWH/O36ZwWHfBnVR6qtRQ6TyjrgDrQVkKG87dRZzvcGqPjO
	zFHfQfxeUohI5Y+Ay7lC4TQnOZfX1d7bGVxBGszAqCIeE7PTyNpHztTz2NBoii4=
X-Gm-Gg: ASbGncvKIcraKf1z8Oo71gou1cCKCNWy+3V6qFi8LKCzA1k7IoYgZ8TV/HH4khJTrPd
	sihxCz23FwcUutxMpDomVfeLuLc0mu4bbGARhRs1WynsymEbwBlttvsv94xzicWadWpI8XtD7Pd
	b8+K4K441n17Vd+4N2J3v/40YlmiKwlK+CiUwDwXGDqwpJXIK++ihgXoKy7x1yRhU3WDCiLAqrD
	OjRE4a3FfaLH3BU9lBDLEmxQNQT/czp8Vpe02qswj4LcPNnx6IGJVbnZSYN2RW7KCo=
X-Google-Smtp-Source: AGHT+IG/Ca10GucOt5OvDYBg/CrWfISkdeZ/fB5wkMRyTDfBgbjoZXzPUSyZIp0F3iUwde5XUeli4Q==
X-Received: by 2002:a05:6402:350a:b0:5d0:e7a0:154a with SMTP id 4fb4d7f45d1cf-5da0c2c2872mr2688734a12.8.1736950284715;
        Wed, 15 Jan 2025 06:11:24 -0800 (PST)
Message-ID: <e4b72c12-126b-4783-9a61-707894fbbae0@citrix.com>
Date: Wed, 15 Jan 2025 14:11:23 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v2 2/3] docs: rationalise .gitignore
To: Yann Dirson <yann.dirson@vates.tech>, xen-devel@lists.xenproject.org
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Stefano Stabellini <sstabellini@kernel.org>
References: <cover.1736943927.git.yann.dirson@vates.tech>
 <c3f6a2d8fd7a1df487a6fce99e8e0f785ac4fc75.1736943927.git.yann.dirson@vates.tech>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <c3f6a2d8fd7a1df487a6fce99e8e0f785ac4fc75.1736943927.git.yann.dirson@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 15/01/2025 12:27 pm, Yann Dirson wrote:
> diff --git a/docs/.gitignore b/docs/.gitignore
> new file mode 100644
> index 0000000000..0727c6d7cf
> --- /dev/null
> +++ b/docs/.gitignore
> @@ -0,0 +1,14 @@
> +/figs/*.png
> +/html/
> +/man/xl.cfg.5.pod
> +/man/xl-disk-configuration.5.pod
> +/man/xl-network-configuration.5.pod
> +/man/xl.1.pod
> +/man/xl.conf.5.pod
> +/man1/
> +/man5/
> +/man7/
> +/man8/
> +/pdf/
> +/tmp.*
> +/txt/

I'm reasonably sure tmp.* is stale now.  I can't find anything that
references it now.

Also, the manpages ought to be /man[1-9]/ to use a single pattern and
cover all reasonable eventualities.

I can fix these on commit.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 14:20:31 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 14:20:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872603.1283573 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY4Fv-0000eg-9n; Wed, 15 Jan 2025 14:20:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872603.1283573; Wed, 15 Jan 2025 14:20:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY4Fv-0000eZ-6m; Wed, 15 Jan 2025 14:20:27 +0000
Received: by outflank-mailman (input) for mailman id 872603;
 Wed, 15 Jan 2025 14:20:26 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=MxfB=UH=ideasonboard.com=tomi.valkeinen@srs-se1.protection.inumbo.net>)
 id 1tY4Fu-0000eT-0D
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 14:20:26 +0000
Received: from perceval.ideasonboard.com (perceval.ideasonboard.com
 [213.167.242.64]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id dc71513b-d34b-11ef-a0e1-8be0dac302b0;
 Wed, 15 Jan 2025 15:20:24 +0100 (CET)
Received: from [192.168.88.20] (91-158-153-178.elisa-laajakaista.fi
 [91.158.153.178])
 by perceval.ideasonboard.com (Postfix) with ESMTPSA id 15D16526;
 Wed, 15 Jan 2025 15:19:24 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: dc71513b-d34b-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;
	s=mail; t=1736950766;
	bh=7qiyO+wfBrEyDk/AoXCj+nFogFQS7ryzGCzAqhdWb38=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=FNEnqs8pIxmzmXTlNZ5aoLcVlgUYO4x7tjA2Y+EpzVZYLe4hGm7k1eU8rP1U9FwYK
	 RPx9CD1DBq9txbEDtdRq2erdoqbqnEGp7lnsvla38haKmYWSWUKigfw6gmUqEA/ioo
	 GsAPA1Hr9rXNsFdn2I8B1WzDBAcDit9zy8TZ7Wrw=
Message-ID: <e327ad84-b5c9-4480-b873-dc3aca605538@ideasonboard.com>
Date: Wed, 15 Jan 2025 16:20:19 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with
 drm_mode_size_dumb()
To: Thomas Zimmermann <tzimmermann@suse.de>,
 maarten.lankhorst@linux.intel.com, mripard@kernel.org, airlied@gmail.com,
 simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org, linux-mediatek@lists.infradead.org,
 freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
 imx@lists.linux.dev, linux-samsung-soc@vger.kernel.org,
 nouveau@lists.freedesktop.org, virtualization@lists.linux.dev,
 spice-devel@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org,
 linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org,
 intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org,
 Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
 Andy Yan <andyshrk@163.com>
References: <20250109150310.219442-1-tzimmermann@suse.de>
 <20250109150310.219442-26-tzimmermann@suse.de>
 <cdbe483d-0895-47aa-8c83-1c28220f4a02@ideasonboard.com>
 <bc97b92e-7f8a-4b92-af8a-20fa165ead55@suse.de>
 <f3ba05c7-6e49-4641-a3f9-ba418ebdb7c3@ideasonboard.com>
 <c6735280-7c32-4319-8ca9-a7305d8117c3@suse.de>
 <d67adb03-5cd0-4ac9-af58-cf4446dacee3@ideasonboard.com>
 <0ea6be58-0e04-4172-87cd-064a3e4a43bc@suse.de>
 <f35cb350-6be9-48ca-ad7e-e9dd418281d5@ideasonboard.com>
 <4af0b6a7-c16a-4187-bbf5-365a9c86de21@suse.de>
Content-Language: en-US
From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Autocrypt: addr=tomi.valkeinen@ideasonboard.com; keydata=
 xsFNBE6ms0cBEACyizowecZqXfMZtnBniOieTuFdErHAUyxVgtmr0f5ZfIi9Z4l+uUN4Zdw2
 wCEZjx3o0Z34diXBaMRJ3rAk9yB90UJAnLtb8A97Oq64DskLF81GCYB2P1i0qrG7UjpASgCA
 Ru0lVvxsWyIwSfoYoLrazbT1wkWRs8YBkkXQFfL7Mn3ZMoGPcpfwYH9O7bV1NslbmyJzRCMO
 eYV258gjCcwYlrkyIratlHCek4GrwV8Z9NQcjD5iLzrONjfafrWPwj6yn2RlL0mQEwt1lOvn
 LnI7QRtB3zxA3yB+FLsT1hx0va6xCHpX3QO2gBsyHCyVafFMrg3c/7IIWkDLngJxFgz6DLiA
 G4ld1QK/jsYqfP2GIMH1mFdjY+iagG4DqOsjip479HCWAptpNxSOCL6z3qxCU8MCz8iNOtZk
 DYXQWVscM5qgYSn+fmMM2qN+eoWlnCGVURZZLDjg387S2E1jT/dNTOsM/IqQj+ZROUZuRcF7
 0RTtuU5q1HnbRNwy+23xeoSGuwmLQ2UsUk7Q5CnrjYfiPo3wHze8avK95JBoSd+WIRmV3uoO
 rXCoYOIRlDhg9XJTrbnQ3Ot5zOa0Y9c4IpyAlut6mDtxtKXr4+8OzjSVFww7tIwadTK3wDQv
 Bus4jxHjS6dz1g2ypT65qnHen6mUUH63lhzewqO9peAHJ0SLrQARAQABzTBUb21pIFZhbGtl
 aW5lbiA8dG9taS52YWxrZWluZW5AaWRlYXNvbmJvYXJkLmNvbT7CwY4EEwEIADgWIQTEOAw+
 ll79gQef86f6PaqMvJYe9QUCX/HruAIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRD6
 PaqMvJYe9WmFD/99NGoD5lBJhlFDHMZvO+Op8vCwnIRZdTsyrtGl72rVh9xRfcSgYPZUvBuT
 VDxE53mY9HaZyu1eGMccYRBaTLJSfCXl/g317CrMNdY0k40b9YeIX10feiRYEWoDIPQ3tMmA
 0nHDygzcnuPiPT68JYZ6tUOvAt7r6OX/litM+m2/E9mtp8xCoWOo/kYO4mOAIoMNvLB8vufi
 uBB4e/AvAjtny4ScuNV5c5q8MkfNIiOyag9QCiQ/JfoAqzXRjVb4VZG72AKaElwipiKCWEcU
 R4+Bu5Qbaxj7Cd36M/bI54OrbWWETJkVVSV1i0tghCd6HHyquTdFl7wYcz6cL1hn/6byVnD+
 sR3BLvSBHYp8WSwv0TCuf6tLiNgHAO1hWiQ1pOoXyMEsxZlgPXT+wb4dbNVunckwqFjGxRbl
 Rz7apFT/ZRwbazEzEzNyrBOfB55xdipG/2+SmFn0oMFqFOBEszXLQVslh64lI0CMJm2OYYe3
 PxHqYaztyeXsx13Bfnq9+bUynAQ4uW1P5DJ3OIRZWKmbQd/Me3Fq6TU57LsvwRgE0Le9PFQs
 dcP2071rMTpqTUteEgODJS4VDf4lXJfY91u32BJkiqM7/62Cqatcz5UWWHq5xeF03MIUTqdE
 qHWk3RJEoWHWQRzQfcx6Fn2fDAUKhAddvoopfcjAHfpAWJ+ENc7BTQROprNHARAAx0aat8GU
 hsusCLc4MIxOQwidecCTRc9Dz/7U2goUwhw2O5j9TPqLtp57VITmHILnvZf6q3QAho2QMQyE
 DDvHubrdtEoqaaSKxKkFie1uhWNNvXPhwkKLYieyL9m2JdU+b88HaDnpzdyTTR4uH7wk0bBa
 KbTSgIFDDe5lXInypewPO30TmYNkFSexnnM3n1PBCqiJXsJahE4ZQ+WnV5FbPUj8T2zXS2xk
 0LZ0+DwKmZ0ZDovvdEWRWrz3UzJ8DLHb7blPpGhmqj3ANXQXC7mb9qJ6J/VSl61GbxIO2Dwb
 xPNkHk8fwnxlUBCOyBti/uD2uSTgKHNdabhVm2dgFNVuS1y3bBHbI/qjC3J7rWE0WiaHWEqy
 UVPk8rsph4rqITsj2RiY70vEW0SKePrChvET7D8P1UPqmveBNNtSS7In+DdZ5kUqLV7rJnM9
 /4cwy+uZUt8cuCZlcA5u8IsBCNJudxEqBG10GHg1B6h1RZIz9Q9XfiBdaqa5+CjyFs8ua01c
 9HmyfkuhXG2OLjfQuK+Ygd56mV3lq0aFdwbaX16DG22c6flkkBSjyWXYepFtHz9KsBS0DaZb
 4IkLmZwEXpZcIOQjQ71fqlpiXkXSIaQ6YMEs8WjBbpP81h7QxWIfWtp+VnwNGc6nq5IQDESH
 mvQcsFS7d3eGVI6eyjCFdcAO8eMAEQEAAcLBXwQYAQIACQUCTqazRwIbDAAKCRD6PaqMvJYe
 9fA7EACS6exUedsBKmt4pT7nqXBcRsqm6YzT6DeCM8PWMTeaVGHiR4TnNFiT3otD5UpYQI7S
 suYxoTdHrrrBzdlKe5rUWpzoZkVK6p0s9OIvGzLT0lrb0HC9iNDWT3JgpYDnk4Z2mFi6tTbq
 xKMtpVFRA6FjviGDRsfkfoURZI51nf2RSAk/A8BEDDZ7lgJHskYoklSpwyrXhkp9FHGMaYII
 m9EKuUTX9JPDG2FTthCBrdsgWYPdJQvM+zscq09vFMQ9Fykbx5N8z/oFEUy3ACyPqW2oyfvU
 CH5WDpWBG0s5BALp1gBJPytIAd/pY/5ZdNoi0Cx3+Z7jaBFEyYJdWy1hGddpkgnMjyOfLI7B
 CFrdecTZbR5upjNSDvQ7RG85SnpYJTIin+SAUazAeA2nS6gTZzumgtdw8XmVXZwdBfF+ICof
 92UkbYcYNbzWO/GHgsNT1WnM4sa9lwCSWH8Fw1o/3bX1VVPEsnESOfxkNdu+gAF5S6+I6n3a
 ueeIlwJl5CpT5l8RpoZXEOVtXYn8zzOJ7oGZYINRV9Pf8qKGLf3Dft7zKBP832I3PQjeok7F
 yjt+9S+KgSFSHP3Pa4E7lsSdWhSlHYNdG/czhoUkSCN09C0rEK93wxACx3vtxPLjXu6RptBw
 3dRq7n+mQChEB1am0BueV1JZaBboIL0AGlSJkm23kw==
In-Reply-To: <4af0b6a7-c16a-4187-bbf5-365a9c86de21@suse.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 15/01/2025 15:45, Thomas Zimmermann wrote:
> Hi
> 
> 
> Am 15.01.25 um 14:33 schrieb Tomi Valkeinen:
> [...]
>>> Yeah, there are constrains in the scanline and buffer alignments and 
>>> orientation. And if we say that bpp==12 means NV12, it will be a 
>>> problem for all other cases where bpp==12 makes sense.
>>
>> I feel I still don't quite understand. Can't we define and document 
>> CREATE_DUMB like this:
>>
>> If (bpp < 8 || is_power_of_two(bpp))
>>     bpp means bitsperpixel
>>     pitch is args->width * args->bpp / 8, aligned up to driver- 
>> specific-align
>> else
>>     bpp is a legacy parameter, and we deal with it case by case.
>>     list the cases and what they mean
>>
>> And describe that when allocating subsampled buffers, the caller must 
>> adjust the width and height accordingly. And that the bpp and width 
>> can also refer to pixel groups.
>>
>> Or if the currently existing code prevents the above for 16 and 32 
>> bpps, how about defining that any non-RGB or not-simple buffer has to 
>> be allocated with bpp=8, and the userspace has to align the pitch 
>> correctly according to the format and platform's hw restrictions?
> 
> What if a hardware requires certain per-format alignments? Or requires 
> certain alignments for each plane? Or only supports tile modes? Or has 
> strict limits on the maximum buffer size?
> 
> It is not possible to encode all this in a simple 32-bit value. So user- 
> space code has to be aware of all this and tweak bpp-based allocation to 
> make it work. Obviously you can use the current UAPI for your use case. 
> It's just not optimal or future proof.

No disagreement there, we need CREATE_DUMB2.

My point is that we have the current UAPI, and we have userspace using 
it, but we don't have clear rules what the ioctl does with specific 
parameters, and we don't document how it has to be used.

Perhaps the situation is bad, and all we can really say is that 
CREATE_DUMB only works for use with simple RGB formats, and the behavior 
for all other formats is platform specific. But I think even that would 
be valuable in the UAPI docs.

Thinking about this, I wonder if this change is good for omapdrm or 
xilinx (probably other platforms too that support non-simple non-RGB 
formats via dumb buffers): without this patch, in both drivers, the 
pitch calculations just take the bpp as bit-per-pixels, align it up, and 
that's it.

With this patch we end up using drm_driver_color_mode_format(), and 
aligning buffers according to RGB formats figured out via heuristics. It 
does happen to work, for the formats I tested, but it sounds like 
something that might easily not work, as it's doing adjustments based on 
wrong format.

Should we have another version of drm_mode_size_dumb() which just 
calculates using the bpp, without the drm_driver_color_mode_format() 
path? Or does the drm_driver_color_mode_format() path provide some value 
for the drivers that do not currently do anything similar?

  Tomi



From xen-devel-bounces@lists.xenproject.org Wed Jan 15 14:34:45 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 14:34:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872615.1283583 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY4TX-0003Ga-Ic; Wed, 15 Jan 2025 14:34:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872615.1283583; Wed, 15 Jan 2025 14:34:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY4TX-0003GT-F2; Wed, 15 Jan 2025 14:34:31 +0000
Received: by outflank-mailman (input) for mailman id 872615;
 Wed, 15 Jan 2025 14:34:30 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=KZm5=UH=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tY4TW-0003GN-1T
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 14:34:30 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d270db67-d34d-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 15:34:27 +0100 (CET)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-aa6b4cc7270so972277466b.0
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 06:34:27 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c95624ccsm758876866b.126.2025.01.15.06.34.24
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 15 Jan 2025 06:34:24 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: d270db67-d34d-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736951666; x=1737556466; 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=7++nirqBdRkMi+YWr9wvpdbbsVplcj+nbvkw0Rns88Y=;
        b=ji2Q7BzULZwShqJp6EfFrtyTttkWo7puNXu9aYtE4hLfiyWv8olLBBhvOyjoNvALcA
         V7fu2l5jH/TJcIcNb8c/gELQ+sYo+1CsDPx0tZASQlfAy9YNZtu7HzS7BPF6AjTR6SlY
         KU3KYSuJW8zv9KzKsFqJGl7pR/SxTXTC04CzQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736951666; x=1737556466;
        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=7++nirqBdRkMi+YWr9wvpdbbsVplcj+nbvkw0Rns88Y=;
        b=u6pt6adhXraRsb1a4RKy3nBs9OUBsADApxMK3lyujagtXZOaCklx98S16ejgUJO+Zr
         QgBtxNLeYEoEsxTHwUngBbGInrcTcpnFioZziqt2Sw44n/jKxIa1pnhUMHrLUyjmGDDg
         r3lZ3x0Pb/9ac2OeN2MndSQibpZmyRDfxjT4pPtBxhuLhwo0VXe8F+dHSPDT+edxEmBB
         RfweULSHJjXiOyBXYCS+2UEQ5qHGgyxcgg3vD1WU+PebNWEynKggYqyv2u1+8Dlm1AJb
         LPMg96LBcJ5fVo/mDjbKO+b7rV95uu1IaUk7SR58XyZf/WGjmYdQXXDnjY2f6b2f5GIX
         3BEg==
X-Forwarded-Encrypted: i=1; AJvYcCWotLYo++wWMlJ+YR5Mzu8ukGFBIHrHXF/9h6OxO3xpTsiOrDaONvxTyrC+IPJpTrZF/+hFKcXuHi4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwNB+cT5bFyZdxfRexXmX/uDnMxbikqpXAb/8LLWkRptWwjEojB
	/BMfG5C1JjT58p8eV1FZCxRElKHA/KQZg26dCGM5GxrtKMPJB7HB7fgg8cmbrCQ=
X-Gm-Gg: ASbGnctJob44Q7sq/L8s9TWZxxdGQqs3lk6xF71dEfY3HyeFdHCkJGo31EDNGZRKT8a
	zzNoPCs6sFxTXwxsFl9OoAPkKb/1vllva65Jfg6Vnkc9RgJY79FxyzB3t9l0ovkMBtHgl23jeIx
	Qzt37VZd6wSC1kBaoWiYxJFrbwLiHnYXHf/OyFNo+R3bQ/sxuY+5RVpKcOYLUfNk9hUtkq/lqH5
	yUXCCKc4Pwg626JZQ+nGKLcadGD3nyW/ba9dwcE9q123chL7hmn8PZ6ZGkE5A==
X-Google-Smtp-Source: AGHT+IEROnS06Is+yJ/NYS7Lbm9RMq3n6vCGKiNQG/awRliXEYcSaYzplNZMMZfLGBtWkxyV4wv/kg==
X-Received: by 2002:a05:6402:2746:b0:5d0:c697:1f02 with SMTP id 4fb4d7f45d1cf-5d972e1c54emr74030348a12.17.1736951664916;
        Wed, 15 Jan 2025 06:34:24 -0800 (PST)
Date: Wed, 15 Jan 2025 15:34:23 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: qemu-devel@nongnu.org, Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Kevin Wolf <kwolf@redhat.com>, Hanna Reitz <hreitz@redhat.com>,
	=?utf-8?Q?Marc-Andr=C3=A9?= Lureau <marcandre.lureau@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>, xen-devel@lists.xenproject.org,
	qemu-block@nongnu.org
Subject: Re: [PATCH v2 0/2] xen: error handling and FreeBSD compatibility
 fixes
Message-ID: <Z4fHbzgSmV9E5DR4@macbook.local>
References: <20250110093531.23221-1-roger.pau@citrix.com>
 <fc9b22c55eaaa79a3ef9829c270bc4b4e93be7a0.camel@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <fc9b22c55eaaa79a3ef9829c270bc4b4e93be7a0.camel@infradead.org>

On Fri, Jan 10, 2025 at 10:02:53AM +0000, David Woodhouse wrote:
> On Fri, 2025-01-10 at 10:35 +0100, Roger Pau Monne wrote:
> > Hello,
> > 
> > First patch from David introduces a new helper to fetch xenstore nodes,
> > while second patch removes the usage of scanf related functions with the
> > "%ms" format specifier, as it's not supported by the FreeBSD scanf libc
> > implementation.
> > 
> > Thanks, Roger.
> 
> Thanks. I've got a handful of non-bugfix cleanups to use the new
> xs_node_read in my tree at
> https://git.infradead.org/users/dwmw2/qemu.git/shortlog/refs/heads/xs_node_read
> 
> David Woodhouse (4):
>       hw/xen: Use xs_node_read() from xs_node_vscanf()
>       hw/xen: Use xs_node_read() from xen_console_get_name()
>       hw/xen: Use xs_node_read() from xen_netdev_get_name()
>       hw/xen: Use xs_node_read() from xenstore_read_str() instead of open-coding it

Acked-by: Roger Pau Monné <roger.pau@citrix.com>

> I'm slightly dubious about the last one; xen_pvdev.c didn't previously
> use anything from xen-bus-helper.c and even hardcodes zero for
> XBT_NULL. And I look at the way it deliberately reallocates the string,
> and wonder if we should be doing that in qemu_xen_xs_read() for the
> true Xen case. And does it even matter anywhere except Windows?

I would take the opportunity to use XBT_NULL instead of 0 on
xen_pvdev.c for the transaction.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 14:36:10 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 14:36:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872625.1283592 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY4V7-0003mL-U6; Wed, 15 Jan 2025 14:36:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872625.1283592; Wed, 15 Jan 2025 14:36:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY4V7-0003mE-RN; Wed, 15 Jan 2025 14:36:09 +0000
Received: by outflank-mailman (input) for mailman id 872625;
 Wed, 15 Jan 2025 14:36:08 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <anthony@xenproject.org>) id 1tY4V6-0003m3-Ma
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 14:36:08 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <anthony@xenproject.org>) id 1tY4V0-0061ge-2w;
 Wed, 15 Jan 2025 14:36:03 +0000
Received: from [2a01:e0a:1da:8420:b77:bd5:6e45:7633] (helo=l14)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from <anthony@xenproject.org>) id 1tY4V0-006U5Y-2l;
 Wed, 15 Jan 2025 14:36:03 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:
	References:Message-ID:Subject:Cc:To:From:Date;
	bh=BzHVI2QHsblFL3UdSqVJ+hb2V1l2T08WDs3ev7B3rhU=; b=xX5GMUOF7fb6dPESjNoX3BU1Pt
	xYQSp1DvKS8gZEuQnyeqmVK43oN0bHMO89pCSUnersCo3ye9upzNNr0g7dwu0UGn6aXcbOJo54QgE
	DAIyQtU2LBsbuxLKVdygZtPrXLA8xez8lKro5Q/a6/+TMqipsB3nGXAKKT2wZU0mOA4s=;
Date: Wed, 15 Jan 2025 15:36:00 +0100
From: Anthony PERARD <anthony@xenproject.org>
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: qemu-devel@nongnu.org, Stefano Stabellini <sstabellini@kernel.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Kevin Wolf <kwolf@redhat.com>, Hanna Reitz <hreitz@redhat.com>,
	=?iso-8859-1?Q?Marc-Andr=E9?= Lureau <marcandre.lureau@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>, xen-devel@lists.xenproject.org,
	qemu-block@nongnu.org
Subject: Re: [PATCH v2 2/2] xen: do not use '%ms' scanf specifier
Message-ID: <Z4fH0NwPEmjryqoG@l14>
References: <20250110093531.23221-1-roger.pau@citrix.com>
 <20250110093531.23221-3-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250110093531.23221-3-roger.pau@citrix.com>

On Fri, Jan 10, 2025 at 10:35:31AM +0100, Roger Pau Monne wrote:
> diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
> index ef0c2912efa1..989e75fef88f 100644
> --- a/hw/char/xen_console.c
> +++ b/hw/char/xen_console.c
> @@ -550,7 +550,8 @@ static void xen_console_device_create(XenBackendInstance *backend,
>          goto fail;
>      }
>  
> -    if (xs_node_scanf(xsh, XBT_NULL, fe, "type", errp, "%ms", &type) != 1) {
> +    type = xs_node_read(xsh, XBT_NULL, NULL, errp, "%s/%s", fe, "type");
> +    if (!type) {
>          error_prepend(errp, "failed to read console device type: ");
>          goto fail;
>      }
> @@ -568,7 +569,8 @@ static void xen_console_device_create(XenBackendInstance *backend,
>  
>      snprintf(label, sizeof(label), "xencons%ld", number);
>  
> -    if (xs_node_scanf(xsh, XBT_NULL, fe, "output", NULL, "%ms", &output) == 1) {
> +    output = xs_node_read(xsh, XBT_NULL, NULL, errp, "%s/%s", fe, "output");

This now set `errp` on error, when `output == NULL`. In case `output` is
NULL, we check for `number` instead and may generate an error message
that probably doesn't really make sense.
    "console: No serial device #2 found: failed to read from /frontend_path/output"
And if number == 0, we tried to create a null device, and if that
failed, the error message will just be about the missing xenstore path
as error_setg() will not set `errp` again.

Could you keep ignoring errors from xs_node_read() like it was done with
xs_node_scanf() (I mean pass `NULL` instead of `errp`)? And we will need
another patch to fix the wrong use of `error_prepend()` and use
`error_setg` instead when `serial_hd()` fails.

> +    if (output) {
>          /*
>           * FIXME: sure we want to support implicit
>           * muxed monitors here?

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 14:37:02 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 14:37:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872632.1283603 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY4Vy-0004IU-6Y; Wed, 15 Jan 2025 14:37:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872632.1283603; Wed, 15 Jan 2025 14:37:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY4Vy-0004IN-3d; Wed, 15 Jan 2025 14:37:02 +0000
Received: by outflank-mailman (input) for mailman id 872632;
 Wed, 15 Jan 2025 14:37: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
 <SRS0=rWPo=UH=casper.srs.infradead.org=BATV+fb641630334796bb9467+7815+infradead.org+dwmw2@srs-se1.protection.inumbo.net>)
 id 1tY4Vw-0004I7-Ai
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 14:37:01 +0000
Received: from casper.infradead.org (casper.infradead.org
 [2001:8b0:10b:1236::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2b03187d-d34e-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 15:36:56 +0100 (CET)
Received: from [54.240.197.234] (helo=freeip.amazon.com)
 by casper.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux))
 id 1tY4Vq-0000000Ejmc-1oFx; Wed, 15 Jan 2025 14:36:54 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2b03187d-d34e-11ef-99a4-01e77a169b0f
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:Cc:To:From:Subject:Message-ID:Sender:Reply-To:
	Content-Transfer-Encoding:Content-ID:Content-Description;
	bh=olriidv7A3tyM6bmljEpUfHKcxoBpc5a3UJhy4JiR84=; b=T6IS/uAOiRU1edlwgoFko6UDPx
	4q+J6nTt9Lj7QK9SWF7lZedZLerCvD86RItaO11b1dJMaH0cxC+sattftNweGYpGqZrXNhRPmJ0Hw
	Y2V8JzKtnEu+x+uOgizfwJDGLuzvlGBOeteF2ztXG88U+wontcblj79tZX6W6iLkKWT60OWVoAJC+
	z96tg7bnbpc0FDtZ0et5UX37cNl9ugLfo9erOPI891JwM+RzDN8GDfVKcdCw7zDil80EyY6/DjvmX
	53/XF4nCvWuCCenqwcy7+Gd7XGjp8/mpvSQwiCiqOwSzX5lMKuuFQs935hYn9Dy8I36UG3HyMZcqz
	i5YebbYg==;
Message-ID: <70fb48c6d8516a4c4fe9318d20066fa78b72c4cb.camel@infradead.org>
Subject: Re: [PATCH v2 0/2] xen: error handling and FreeBSD compatibility
 fixes
From: David Woodhouse <dwmw2@infradead.org>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Cc: qemu-devel@nongnu.org, Stefano Stabellini <sstabellini@kernel.org>, 
 Anthony PERARD <anthony@xenproject.org>, Paul Durrant <paul@xen.org>,
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>, Kevin Wolf
 <kwolf@redhat.com>, Hanna Reitz <hreitz@redhat.com>,
 =?ISO-8859-1?Q?Marc-Andr=E9?= Lureau <marcandre.lureau@redhat.com>, Paolo
 Bonzini <pbonzini@redhat.com>,  xen-devel@lists.xenproject.org,
 qemu-block@nongnu.org
Date: Wed, 15 Jan 2025 15:36:53 +0100
In-Reply-To: <Z4fHbzgSmV9E5DR4@macbook.local>
References: <20250110093531.23221-1-roger.pau@citrix.com>
	 <fc9b22c55eaaa79a3ef9829c270bc4b4e93be7a0.camel@infradead.org>
	 <Z4fHbzgSmV9E5DR4@macbook.local>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-O/SC296LeBTMCgTutiLq"
User-Agent: Evolution 3.52.3-0ubuntu1 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html


--=-O/SC296LeBTMCgTutiLq
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2025-01-15 at 15:34 +0100, Roger Pau Monn=C3=A9 wrote:
> On Fri, Jan 10, 2025 at 10:02:53AM +0000, David Woodhouse wrote:
> > On Fri, 2025-01-10 at 10:35 +0100, Roger Pau Monne wrote:
> > > Hello,
> > >=20
> > > First patch from David introduces a new helper to fetch xenstore node=
s,
> > > while second patch removes the usage of scanf related functions with =
the
> > > "%ms" format specifier, as it's not supported by the FreeBSD scanf li=
bc
> > > implementation.
> > >=20
> > > Thanks, Roger.
> >=20
> > Thanks. I've got a handful of non-bugfix cleanups to use the new
> > xs_node_read in my tree at
> > https://git.infradead.org/users/dwmw2/qemu.git/shortlog/refs/heads/xs_n=
ode_read
> >=20
> > David Woodhouse (4):
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 hw/xen: Use xs_node_read() from xs_node_=
vscanf()
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 hw/xen: Use xs_node_read() from xen_cons=
ole_get_name()
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 hw/xen: Use xs_node_read() from xen_netd=
ev_get_name()
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 hw/xen: Use xs_node_read() from xenstore=
_read_str() instead of open-coding it
>=20
> Acked-by: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>

Thanks. I'll add that on each of the four.

> > I'm slightly dubious about the last one; xen_pvdev.c didn't previously
> > use anything from xen-bus-helper.c and even hardcodes zero for
> > XBT_NULL. And I look at the way it deliberately reallocates the string,
> > and wonder if we should be doing that in qemu_xen_xs_read() for the
> > true Xen case. And does it even matter anywhere except Windows?
>=20
> I would take the opportunity to use XBT_NULL instead of 0 on
> xen_pvdev.c for the transaction.

Yeah, probably a separate patch.

--=-O/SC296LeBTMCgTutiLq
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD9Aw
ggSOMIIDdqADAgECAhAOmiw0ECVD4cWj5DqVrT9PMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0yNDAxMzAwMDAwMDBaFw0zMTEx
MDkyMzU5NTlaMEExCzAJBgNVBAYTAkFVMRAwDgYDVQQKEwdWZXJva2V5MSAwHgYDVQQDExdWZXJv
a2V5IFNlY3VyZSBFbWFpbCBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMjvgLKj
jfhCFqxYyRiW8g3cNFAvltDbK5AzcOaR7yVzVGadr4YcCVxjKrEJOgi7WEOH8rUgCNB5cTD8N/Et
GfZI+LGqSv0YtNa54T9D1AWJy08ZKkWvfGGIXN9UFAPMJ6OLLH/UUEgFa+7KlrEvMUupDFGnnR06
aDJAwtycb8yXtILj+TvfhLFhafxroXrflspavejQkEiHjNjtHnwbZ+o43g0/yxjwnarGI3kgcak7
nnI9/8Lqpq79tLHYwLajotwLiGTB71AGN5xK+tzB+D4eN9lXayrjcszgbOv2ZCgzExQUAIt98mre
8EggKs9mwtEuKAhYBIP/0K6WsoMnQCcCAwEAAaOCAVwwggFYMBIGA1UdEwEB/wQIMAYBAf8CAQAw
HQYDVR0OBBYEFIlICOogTndrhuWByNfhjWSEf/xwMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6en
IZ3zbcgPMA4GA1UdDwEB/wQEAwIBhjAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIweQYI
KwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYIKwYB
BQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RD
QS5jcnQwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0
QXNzdXJlZElEUm9vdENBLmNybDARBgNVHSAECjAIMAYGBFUdIAAwDQYJKoZIhvcNAQELBQADggEB
ACiagCqvNVxOfSd0uYfJMiZsOEBXAKIR/kpqRp2YCfrP4Tz7fJogYN4fxNAw7iy/bPZcvpVCfe/H
/CCcp3alXL0I8M/rnEnRlv8ItY4MEF+2T/MkdXI3u1vHy3ua8SxBM8eT9LBQokHZxGUX51cE0kwa
uEOZ+PonVIOnMjuLp29kcNOVnzf8DGKiek+cT51FvGRjV6LbaxXOm2P47/aiaXrDD5O0RF5SiPo6
xD1/ClkCETyyEAE5LRJlXtx288R598koyFcwCSXijeVcRvBB1cNOLEbg7RMSw1AGq14fNe2cH1HG
W7xyduY/ydQt6gv5r21mDOQ5SaZSWC/ZRfLDuEYwggWbMIIEg6ADAgECAhAH5JEPagNRXYDiRPdl
c1vgMA0GCSqGSIb3DQEBCwUAMEExCzAJBgNVBAYTAkFVMRAwDgYDVQQKEwdWZXJva2V5MSAwHgYD
VQQDExdWZXJva2V5IFNlY3VyZSBFbWFpbCBHMjAeFw0yNDEyMzAwMDAwMDBaFw0yODAxMDQyMzU5
NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqGSIb3DQEBAQUAA4IC
DwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZeYAS/SRV6zmfXlXaZ
sNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2zkC9S7/yHDYnqegqt
w4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qGpgFdZEk2/c//ZvUN
i12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41vav1RhZJzYan4a1gU0
kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0cvnO8FM6PTqsnSbcc
0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PWPU6zfQTOMZ9uLQRR
ci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXtREF5lLXxp+CJ6KKS
blPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQrlR0gO3lBzuyPPArV
hvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7IqaAovAX0d+f1YjbmC
VsAwjhLmveFjNwIDAQABo4IBsDCCAawwHwYDVR0jBBgwFoAUiUgI6iBOd2uG5YHI1+GNZIR//HAw
HQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3bXcyQGluZnJhZGVh
ZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEBMA4GA1UdDwEB/wQE
AwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwewYDVR0fBHQwcjA3oDWgM4YxaHR0
cDovL2NybDMuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNybDA3oDWgM4YxaHR0
cDovL2NybDQuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNybDB2BggrBgEFBQcB
AQRqMGgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBABggrBgEFBQcwAoY0
aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNydDANBgkq
hkiG9w0BAQsFAAOCAQEAQXc4FPiPLRnTDvmOABEzkIumojfZAe5SlnuQoeFUfi+LsWCKiB8Uextv
iBAvboKhLuN6eG/NC6WOzOCppn4mkQxRkOdLNThwMHW0d19jrZFEKtEG/epZ/hw/DdScTuZ2m7im
8ppItAT6GXD3aPhXkXnJpC/zTs85uNSQR64cEcBFjjoQDuSsTeJ5DAWf8EMyhMuD8pcbqx5kRvyt
JPsWBQzv1Dsdv2LDPLNd/JUKhHSgr7nbUr4+aAP2PHTXGcEBh8lTeYea9p4d5k969pe0OHYMV5aL
xERqTagmSetuIwolkAuBCzA9vulg8Y49Nz2zrpUGfKGOD0FMqenYxdJHgDCCBZswggSDoAMCAQIC
EAfkkQ9qA1FdgOJE92VzW+AwDQYJKoZIhvcNAQELBQAwQTELMAkGA1UEBhMCQVUxEDAOBgNVBAoT
B1Zlcm9rZXkxIDAeBgNVBAMTF1Zlcm9rZXkgU2VjdXJlIEVtYWlsIEcyMB4XDTI0MTIzMDAwMDAw
MFoXDTI4MDEwNDIzNTk1OVowHjEcMBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzCCAiIwDQYJ
KoZIhvcNAQEBBQADggIPADCCAgoCggIBANqWLse95HW2F7FhfH9bugyT/danKmmXrbMnz5GZNAfj
Jl5gBL9JFXrOZ9eVdpmw04Tp6aDxZctFLoEDvSWKi367Q7Sg+ci+fH4KwwfQ8Pi0IpIKx2n5emEg
nbOQL1Lv/IcNiep6Cq3DiyaSpSp/RZf+CAfUNySHS8eWmhLU6jGpSD6hxTpYKye7PmrmvMWwfGEP
WoamAV1kSTb9z/9m9Q2LXa89aKmTxNwnAfD3Ohn9mtU3JukwILRMewn9QRXK7KzM+01h5hkCE4nj
W9q/VGFknNhqfhrWBTSQoE9CSVylASGrjzCgS7XmKy/BaH3/7mOOHQv5g1o3Qj/+cdKnpT0I5Qb1
nRy+c7wUzo9OqydJtxzSP4ZyHA4dELto/a3m/ay1XHcpum1pgTOLgxAfGb/T4dCkwRUstSKLMmpL
g9Y9TrN9BM4xn24tBFFyL5znGG0wQGzOVAM68RBzIQb6Fz758fjsr4yZnPbVsU1+gHEs/puNHrG0
9e1EQXmUtfGn4InoopJuU8p5VGD9S3Ikd4UoBlc7xl5yjtNlQxUeYrRlnUSmdlucCEoTX1n4UmtA
9CuVHSA7eUHO7I88CtWG9bGOU7tLgOZoSEvNqtaL/N7sQbBZK4jZ4Rr/zNTQg1SwYjjLB7u96lDP
sipoCi8BfR35/ViNuYJWwDCOEua94WM3AgMBAAGjggGwMIIBrDAfBgNVHSMEGDAWgBSJSAjqIE53
a4blgcjX4Y1khH/8cDAdBgNVHQ4EFgQUXGIam3Bs59Y60yTmWgfDu6pZQ6cwMAYDVR0RBCkwJ4ET
ZHdtdzJAaW5mcmFkZWFkLm9yZ4EQZGF2aWRAd29vZGhvdS5zZTAUBgNVHSAEDTALMAkGB2eBDAEF
AQEwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDB7BgNVHR8E
dDByMDegNaAzhjFodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVtYWlsRzIu
Y3JsMDegNaAzhjFodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVtYWlsRzIu
Y3JsMHYGCCsGAQUFBwEBBGowaDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29t
MEAGCCsGAQUFBzAChjRodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVt
YWlsRzIuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQBBdzgU+I8tGdMO+Y4AETOQi6aiN9kB7lKWe5Ch
4VR+L4uxYIqIHxR7G2+IEC9ugqEu43p4b80LpY7M4KmmfiaRDFGQ50s1OHAwdbR3X2OtkUQq0Qb9
6ln+HD8N1JxO5nabuKbymki0BPoZcPdo+FeRecmkL/NOzzm41JBHrhwRwEWOOhAO5KxN4nkMBZ/w
QzKEy4PylxurHmRG/K0k+xYFDO/UOx2/YsM8s138lQqEdKCvudtSvj5oA/Y8dNcZwQGHyVN5h5r2
nh3mT3r2l7Q4dgxXlovERGpNqCZJ624jCiWQC4ELMD2+6WDxjj03PbOulQZ8oY4PQUyp6djF0keA
MYIDuzCCA7cCAQEwVTBBMQswCQYDVQQGEwJBVTEQMA4GA1UEChMHVmVyb2tleTEgMB4GA1UEAxMX
VmVyb2tleSBTZWN1cmUgRW1haWwgRzICEAfkkQ9qA1FdgOJE92VzW+AwDQYJYIZIAWUDBAIBBQCg
ggE3MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTI1MDExNTE0MzY1
M1owLwYJKoZIhvcNAQkEMSIEIBtaUpOytkTDYMZ1nZK6KEox2iBVRjkrfhbinAJiHw7eMGQGCSsG
AQQBgjcQBDFXMFUwQTELMAkGA1UEBhMCQVUxEDAOBgNVBAoTB1Zlcm9rZXkxIDAeBgNVBAMTF1Zl
cm9rZXkgU2VjdXJlIEVtYWlsIEcyAhAH5JEPagNRXYDiRPdlc1vgMGYGCyqGSIb3DQEJEAILMVeg
VTBBMQswCQYDVQQGEwJBVTEQMA4GA1UEChMHVmVyb2tleTEgMB4GA1UEAxMXVmVyb2tleSBTZWN1
cmUgRW1haWwgRzICEAfkkQ9qA1FdgOJE92VzW+AwDQYJKoZIhvcNAQEBBQAEggIAqCCkrmQNk7mN
fUhOxU9QSKz+sJV2g022Ymt2cCxzxNnhMZaBmrd36KAMY5gNmpK6ay7fl1kr36oJkH/kSOJG1Agm
JstQLV3hnGIiheTl8ZgVpfDHKgB3dwvR3XBRjOsBYePTzEAzNWDM23pg5/+ZR5mdEtPbykeKCKOs
kVf7LAt8W7RlAh/IULbGz7O+16HlMUxERkDIprzydPYvdUh/xpta6wOpSAyHdsCLWzy9I23/gviv
dOJR2viYkrKJMPMa7P4ahQgMtQ7yqB4jQBies51gt07xjSFRxDmBSqS5e6GQLrH6s25DjsFQylfS
SM9xufiQGNThCRAiiEAveFWSs6dON7XBdMWc5ZnvMnhXo5GO+7VS/hiYH0UL4TfRuTIAbdlg6P7q
3efTZHXrf6N7FxIaQxVsR7gKT2MvQe1Zvch+58wrWxnpejrkeeHpbo+tNogewRFq7RKErXfy4QcZ
06kByxWWxsmOmi6mmqSQlxkHJHRU8VXcjZ0+XFLuZY/VzdnczjjvMq6WM7JPXk0pIKi6v8f5aAcY
PqhJyX7SfLyz53UTqrNi+cOyOQJFKe9WObFHSXurX5WSeiC4SV41vJdg3NBixfCgzz8WYr2kJz4x
1k2G+90M5C5w8UKJK2t7LwTbCpBPZ7Me8EmNU44gDqE8RMFdZKQe5SequDcifz8AAAAAAAA=


--=-O/SC296LeBTMCgTutiLq--


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 14:37:19 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 14:37:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872617.1283613 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY4WE-0004cO-Cd; Wed, 15 Jan 2025 14:37:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872617.1283613; Wed, 15 Jan 2025 14:37:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY4WE-0004cF-9x; Wed, 15 Jan 2025 14:37:18 +0000
Received: by outflank-mailman (input) for mailman id 872617;
 Wed, 15 Jan 2025 14:34:41 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=zshn=UH=fooishbar.org=daniel@srs-se1.protection.inumbo.net>)
 id 1tY4Tg-0003GN-NP
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 14:34:40 +0000
Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com
 [2607:f8b0:4864:20::f33])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d9574c04-d34d-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 15:34:39 +0100 (CET)
Received: by mail-qv1-xf33.google.com with SMTP id
 6a1803df08f44-6d89a727a19so9128686d6.0
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 06:34:39 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: d9574c04-d34d-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=fooishbar.org; s=google; t=1736951678; x=1737556478; 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=wgpCbUXuk0fjx7PlpFBa3YSbnvvXmj+DNx/eEdB8F5M=;
        b=UEMMsoOdwnHr2n3YDjjvNiiZ+vvOAjWjL8RrL+194tlXk1RX69aXuyF0bGYP21X8HY
         g04PKV2ktGIdFZR9BzivX2KAY88ylfq4Ha43mOxhEJ0Z9juSqP4gM5ybL+RwdeTqpWXu
         sfoRZuWK0pIUHBfeH0KJm47+8zmREQ3FpmH7DmUCAqxTDRY+mZ9cJ7g9g1RJkCTWAE8f
         1OQF+1WhdHZnFv9Gzx8AJrDTMFczux+QhboaxUA2YUdBqEI2i1G2C3+GWWSOPNxRDHEh
         z8o3tnQ7MQ1UFZ6CafEoVd/x0Vv7E/m2zR4NeWhLn5wTX3gpFjcM8M92UTiNOVanmpLy
         lmwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736951678; x=1737556478;
        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=wgpCbUXuk0fjx7PlpFBa3YSbnvvXmj+DNx/eEdB8F5M=;
        b=I11Q55wIOPDHHNDO/eafvjC6UMromxBfWHJEzgCeJfL58bhPmLGlQVL0CJvdySq6nr
         MJz+YBLm1UCiy6HxL2FEHtEON9dj4J1SjXEDYRsj5F8wPSrIdm2/zWK7d/UBz6X0FT+p
         r5TLx+WD9h2OT9Z4yKhDgvJgp2jRQsjye6wt1lWKR4A59mEtMqgaUopOqDpqtiMWr2fj
         y2V/TdwnpwrqeQTXVvh9gQ7ti/+zvgAfZ+Hws74ypqJf1VYEJSMY5uA1rlXJ0bzVfvAS
         ie4MjhlOZhZNNGEBvQQDDgLW3639myANzzhtHKHTK7tQqg7wwONSTykk/Rec1zqByxeV
         Xpjw==
X-Forwarded-Encrypted: i=1; AJvYcCWNSoZ4IcE7Mv+oQzu3ADaoH1CNq0vQquzHZ9kqXNTajXLpG5/cydGmZ8kn9OzKB/fSoZn0E0SG9YE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwQufZk1LAMc3T6rOWw0fjYRH2h+MHKE5BRZcAu+FntTsia33bS
	r476MpMAx/mUXUAHlBUgE//Edha0MODTPT9zNwHYgP9TXOTH8FBCQ3AX/TKvOIAOT22PTO51a9t
	U3REHU7oLYYrlOK5zIvSHI9ZVoztIcvJf9JA/9w==
X-Gm-Gg: ASbGncvRHcsPUNWjAWv3tUlOUn15A9pyzk8Mgn3ovYqAyLAaFMI7BkwuOgTQ7DUorN6
	rGgYACq86dJjC5nvuW6aGKHNWuTWhytCHJ80=
X-Google-Smtp-Source: AGHT+IFPz9fbMcvhhyZZGYYuWLUwXCRTy8s+kBCbi69J2hIRU1+TB7begqOpM0+xy1s6GqB+nx1X6ZJAR0totDSXOwo=
X-Received: by 2002:a05:6214:486:b0:6d8:e7c9:ffa0 with SMTP id
 6a1803df08f44-6e192c73ef5mr43851476d6.19.1736951677902; Wed, 15 Jan 2025
 06:34:37 -0800 (PST)
MIME-Version: 1.0
References: <20250109150310.219442-1-tzimmermann@suse.de> <20250109150310.219442-26-tzimmermann@suse.de>
 <cdbe483d-0895-47aa-8c83-1c28220f4a02@ideasonboard.com> <bc97b92e-7f8a-4b92-af8a-20fa165ead55@suse.de>
 <f3ba05c7-6e49-4641-a3f9-ba418ebdb7c3@ideasonboard.com> <c6735280-7c32-4319-8ca9-a7305d8117c3@suse.de>
 <d67adb03-5cd0-4ac9-af58-cf4446dacee3@ideasonboard.com> <0ea6be58-0e04-4172-87cd-064a3e4a43bc@suse.de>
 <f35cb350-6be9-48ca-ad7e-e9dd418281d5@ideasonboard.com> <4af0b6a7-c16a-4187-bbf5-365a9c86de21@suse.de>
 <e327ad84-b5c9-4480-b873-dc3aca605538@ideasonboard.com>
In-Reply-To: <e327ad84-b5c9-4480-b873-dc3aca605538@ideasonboard.com>
From: Daniel Stone <daniel@fooishbar.org>
Date: Wed, 15 Jan 2025 14:34:26 +0000
X-Gm-Features: AbW1kvZOqZIfsgr5MQqIuf1jKNJtcUmkb-2ddanRpBEhDxEw_Wl931RGN2rzkA8
Message-ID: <CAPj87rOn=RQ615zyaEdFT2ADfPztU7+heVi0G34Rdg-=QO1cCw@mail.gmail.com>
Subject: Re: [PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with drm_mode_size_dumb()
To: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>, maarten.lankhorst@linux.intel.com, 
	mripard@kernel.org, airlied@gmail.com, simona@ffwll.ch, 
	dri-devel@lists.freedesktop.org, linux-mediatek@lists.infradead.org, 
	freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org, 
	imx@lists.linux.dev, linux-samsung-soc@vger.kernel.org, 
	nouveau@lists.freedesktop.org, virtualization@lists.linux.dev, 
	spice-devel@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org, 
	linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org, 
	intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org, 
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Andy Yan <andyshrk@163.com>
Content-Type: text/plain; charset="UTF-8"

On Wed, 15 Jan 2025 at 14:20, Tomi Valkeinen
<tomi.valkeinen@ideasonboard.com> wrote:
> No disagreement there, we need CREATE_DUMB2.
>
> My point is that we have the current UAPI, and we have userspace using
> it, but we don't have clear rules what the ioctl does with specific
> parameters, and we don't document how it has to be used.
>
> Perhaps the situation is bad, and all we can really say is that
> CREATE_DUMB only works for use with simple RGB formats, and the behavior
> for all other formats is platform specific. But I think even that would
> be valuable in the UAPI docs.

Yeah, CREATE_DUMB only works for use with simple RGB formats in a
linear layout. Not monochrome or YUV or tiled or displayed rotated or
whatever.

If it happens to accidentally work for other uses, that's fine, but
it's not generically reliable for anything other than simple linear
RGB. It's intended to let you do splash screens, consoles, recovery
password entries, and software-rendered compositors if you really
want. Anything more than that isn't 'dumb'.

Cheers,
Daniel


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 14:55:41 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 14:55:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872650.1283622 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY4nu-0008Sm-Rj; Wed, 15 Jan 2025 14:55:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872650.1283622; Wed, 15 Jan 2025 14:55:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY4nu-0008Sf-Nt; Wed, 15 Jan 2025 14:55:34 +0000
Received: by outflank-mailman (input) for mailman id 872650;
 Wed, 15 Jan 2025 14:55:33 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=IgWj=UH=cloud.com=frediano.ziglio@srs-se1.protection.inumbo.net>)
 id 1tY4nt-0008SZ-NF
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 14:55:33 +0000
Received: from mail-oa1-x30.google.com (mail-oa1-x30.google.com
 [2001:4860:4864:20::30])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c3c9867c-d350-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 15:55:31 +0100 (CET)
Received: by mail-oa1-x30.google.com with SMTP id
 586e51a60fabf-29fe7ff65e6so2442946fac.0
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 06:55:31 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c3c9867c-d350-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736952930; x=1737557730; 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=lH4HvbP72tXI20f7Q5FuOMRplx3WULjkOFfrQE0VGtc=;
        b=bujWJZxGfII55fT2P9h5Ipm4kK6VDQGm8bo/c0uPqp3NE70jreBgyRn8MTD7kyA/DZ
         6OLGadqXTP4qgNZU5ztzYpzHou9nATw8X+4w/tKoiZxTZTbcjz6xDWfgkJsCpSjVMnCL
         elVNg7/LARShCBK4VMpa+cSDjSP+ajokszYIE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736952930; x=1737557730;
        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=lH4HvbP72tXI20f7Q5FuOMRplx3WULjkOFfrQE0VGtc=;
        b=UBH1rD1WeyHm8Ou88e6XA441MyOizwkhOInzFHZz10jd8AgSF6yLJYnHeldKdVXULT
         CZ4RpwLNdI2yTAeUrW27xFZaMDHXGYOt7HzXeDa4OkHcrz1Jk2s7DvtQkWv4eo32Xzuk
         XcdeDqjtYoL8NKy2z1weraNOMNj29Ki+mfZkNk2qtM1DJyWZaLY7Q2TUD7VyD6bhSwGc
         67OG+WopbPTsO5Ge3vwITN07sH6lWgB2beC53K9jwU1gZc6SLd3oFf1+bZDUElqwkwWJ
         +vtfvGodltuRn/Y6I44AR/I1uYV9TbG8kQHASHN1d2yQWbCwO3SIWGgWmQcADy4iP3D+
         JSwA==
X-Gm-Message-State: AOJu0YyG397uK+uzmpaXf00RQP1Mh1/tXnvqHJZa/R2KciueiMZzJeWZ
	tlF7DtfJn133i1wQ4lvpY9fZ4kd7T1yZiMcxXXGNLtXtBkF1VF1SG5uf90IppAcGJki3bLT2Fvx
	79doWJci00PdPj0LKHwLYYDkdS6Y4epsnZ+QSNg==
X-Gm-Gg: ASbGncu79UqTfeHjF6KEdneveFgsnYrMQjKC4cpa3Vqns3JdeFo40mxOOluXLuC2H3F
	Fi74BIJUBKnySfn2IdgRbmLkamCNVZQKHb+Fs+ipe
X-Google-Smtp-Source: AGHT+IFW8GHGlmE7c2n9H34hEj3KYMkRZaErmvd6Hr7R0ezAWD1t4iaVAlY1ADgjVLqSKRc0GSFsllHMYELet8Cf0tQ=
X-Received: by 2002:a05:6870:2dc9:b0:29f:f1cc:12a5 with SMTP id
 586e51a60fabf-2aa06922d18mr17574654fac.31.1736952930090; Wed, 15 Jan 2025
 06:55:30 -0800 (PST)
MIME-Version: 1.0
References: <692dabc63953fb0d33536f87e4c5c147ba6ce11c.1736948633.git.bernhard.kaindl@cloud.com>
In-Reply-To: <692dabc63953fb0d33536f87e4c5c147ba6ce11c.1736948633.git.bernhard.kaindl@cloud.com>
From: Frediano Ziglio <frediano.ziglio@cloud.com>
Date: Wed, 15 Jan 2025 14:55:19 +0000
X-Gm-Features: AbW1kvYgZ5JcRSI-PosffDfZftCmvnHqB8uzkwtPgICHiU2n9Oq3o9EFhZKi7vE
Message-ID: <CACHz=ZjgkDUsxSL1vS09A6E3QmPXQTYO3aaoijNUTdoyBK7abg@mail.gmail.com>
Subject: Re: [PATCH] Design docs: Fix some typos in the design docs
To: Bernhard Kaindl <bernhard.kaindl@cloud.com>
Cc: xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, 
	Anthony PERARD <anthony.perard@vates.tech>, Michal Orzel <michal.orzel@amd.com>, 
	Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>, 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
	Stefano Stabellini <sstabellini@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Jan 15, 2025 at 1:45=E2=80=AFPM Bernhard Kaindl
<bernhard.kaindl@cloud.com> wrote:
>
> Skimming through the design docs, I saw some typos that needed fixing.
>
> ---
> Comments for reviewers (not for the commit message itself):
>
> Sample typos (some are not easy to spot):
> - heirarchical: (ei->ie)
> - implementaiton: (it->ti)
> - comprimised: (i->o)
> - contol->control (r)
>
> PS: I did the fixes using LTeX in an IDE and re-checked the mail too.
>
> Signed-off-by: Bernhard Kaindl <bernhard.kaindl@cloud.com>
> ---
>  docs/designs/argo.pandoc                |  4 ++--
>  docs/designs/nested-svm-cpu-features.md | 12 ++++++------
>  docs/designs/qemu-deprivilege.md        |  8 ++++----
>  docs/designs/xenstore-migration.md      |  2 +-
>  docs/features/qemu-deprivilege.pandoc   |  2 +-
>  5 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/docs/designs/argo.pandoc b/docs/designs/argo.pandoc
> index e18aacea7c..cd854d2a7a 100644
> --- a/docs/designs/argo.pandoc
> +++ b/docs/designs/argo.pandoc
> @@ -58,7 +58,7 @@ concurrency.
>
>  Avoidance of deadlock is essential and since state must frequently be up=
dated
>  that pertains to more than one domain, a locking protocol defines which =
locks
> -are needed and the order of their acquistion.
> +are needed and the order of their acquisition.
>
>  ## Structure
>
> @@ -127,7 +127,7 @@ by the domain.
>
>  ## Hierarchical Locking Model and Protocol
>
> -The locking discipline within the Argo code is heirarchical and utilizes
> +The locking discipline within the Argo code is hierarchical and utilizes
>  reader/writer locks to enable increased concurrency when operations do n=
ot
>  conflict. None of the Argo locks are reentrant.
>
> diff --git a/docs/designs/nested-svm-cpu-features.md b/docs/designs/neste=
d-svm-cpu-features.md
> index 837a96df05..c855748141 100644
> --- a/docs/designs/nested-svm-cpu-features.md
> +++ b/docs/designs/nested-svm-cpu-features.md
> @@ -22,7 +22,7 @@ leaf 8000000A:edx
>    from the L1 hypervisor's perspective to be as close as possible to
>    the original hardware.  In particular, the behavior of the hardware
>    on error paths 1) is not easy to understand or test, 2) can be the
> -  source of surprising vulnerabiliies.  (See XSA-7 for an example of a
> +  source of surprising vulnerabilities.  (See XSA-7 for an example of a
>    case where subtle error-handling differences can open up a privilege
>    escalation.)  We should avoid emulating any bit of the hardware with
>    complex error paths if we can at all help it.
> @@ -59,11 +59,11 @@ leaf 8000000A:edx
>
>  - 2 `SVML` *SVM Lock*: Not required for L0, not provided to L1
>
> -  Seems to be aboult enabling an operating system to prevent "blue
> +  Seems to be about enabling an operating system to prevent "blue
>    pill" attacks against itself.
>
>    Xen doesn't use it, nor provide it; so it would need to be
> -  implementend.  The best way to protect a guest OS is to leave nested
> +  implemented.  The best way to protect a guest OS is to leave nested
>    virt disabled in the tools.
>
>  - 3 `NRIPS` NRIP Save: Require for both L0 and L1
> @@ -78,8 +78,8 @@ leaf 8000000A:edx
>    The main putative use for this would be trying to maintain an
>    invariant TSC across cores with different clock speeds, or after a
>    migrate.  Unlike others, this doesn't have an error path to worry
> -  about compatibility-wise; and according to tests done when nestedSVM
> -  was first implemented, it's actually faster to emliate TscRateMSR in
> +  about compatibility-wise; and according to tests done when nested SVM
> +  was first implemented, it's actually faster to emulate TscRateMSR in
>    the L0 hypervisor than for L1 to attempt to emulate it itself.
>
>    However, using this properly in L0 will take some implementation
> @@ -89,7 +89,7 @@ leaf 8000000A:edx
>   - 5 `VmcbClean`: VMCB Clean Bits: Not required by L0, provide to L1
>
>    This is a pure optimization, both on the side of the L0 and L1.  The
> -  implementaiton for L1 is entirely Xen-side, so can be provided even
> +  implementation for L1 is entirely Xen-side, so can be provided even
>    on hardware that doesn't provide it.  And it's purely an
>    optimization, so could be "implemented" by ignoring the bits
>    entirely.
> diff --git a/docs/designs/qemu-deprivilege.md b/docs/designs/qemu-deprivi=
lege.md
> index f12b1a3ae3..603491f24d 100644
> --- a/docs/designs/qemu-deprivilege.md
> +++ b/docs/designs/qemu-deprivilege.md
> @@ -22,7 +22,7 @@ The following restrictions are currently implemented.
>  '''Description''': As mentioned above, having QEMU switch to a
>  non-root user, one per domain id.  Not being the root user limits what
>  a compromised QEMU process can do to the system, and having one user
> -per domain id limits what a comprimised QEMU process can do to the
> +per domain id limits what a compromised QEMU process can do to the
>  QEMU processes of other VMs.
>
>  '''Implementation''': The toolstack adds the following to the qemu comma=
nd-line:
> @@ -79,8 +79,8 @@ Then adds the following to the qemu command-line:
>  ## Namespaces for unused functionality (Linux only)
>
>  '''Description''': QEMU doesn't use the functionality associated with
> -mount and IPC namespaces. (IPC namespaces contol non-file-based IPC
> -mechanisms within the kernel; unix and network sockets are not
> +mount and IPC namespaces. (IPC namespaces control non-file-based IPC
> +mechanisms within the kernel; Unix and network sockets are not
>  affected by this.)  Making separate namespaces for these for QEMU
>  won't affect normal operation, but it does mean that even if other
>  restrictions fail, the process won't be able to even name system mount
> @@ -251,7 +251,7 @@ executing QEMU.  (But this would then require other c=
hanges to create
>  the QMP socket, VNC socket, and so on).
>
>  It should be noted that `-sandbox` is implemented as a blacklist, not
> -a whitelist; that is, it disables known-unsed functionality which may
> +a whitelist; that is, it disables known-unused functionality which may
>  be harmful, rather than disabling all functionality except that known
>  to be safe and needed.  This is unfortunately necessary since qemu
>  doesn't know what system calls libraries might end up making.  (See
> diff --git a/docs/designs/xenstore-migration.md b/docs/designs/xenstore-m=
igration.md
> index 5022268386..082314bf72 100644
> --- a/docs/designs/xenstore-migration.md
> +++ b/docs/designs/xenstore-migration.md
> @@ -372,7 +372,7 @@ or modified by a transaction for which there is also =
a `TRANSACTION_DATA`
>  record previously present).
>
>  Each _committed_ node in the stream is required to have an already known=
 parent
> -node. A parent node is known if it was either in the node data base befo=
re the
> +node. A parent node is known if it was either in the node database befor=
e the
>  stream was started to be processed, or if a `NODE_DATA` record for that =
parent
>  node has already been processed in the stream.
>
> diff --git a/docs/features/qemu-deprivilege.pandoc b/docs/features/qemu-d=
eprivilege.pandoc
> index 4ef119c821..915e38d8c9 100644
> --- a/docs/features/qemu-deprivilege.pandoc
> +++ b/docs/features/qemu-deprivilege.pandoc
> @@ -25,7 +25,7 @@ dm_restrict is a set of operations to restrict QEMU run=
ning in domain
>
>   1. Mechanisms to restrict QEMU to only being able to affect its own
>  domain
> - 2. Mechanisms to restruct QEMU's ability to interact with domain 0.
> + 2. Mechanisms to restrict QEMU's ability to interact with domain 0.
>
>  # User details
>

Reviewed-by: Frediano Ziglio <frediano.ziglio@cloud.com>

Frediano


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 14:56:48 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 14:56:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872660.1283633 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY4p5-0000bP-8V; Wed, 15 Jan 2025 14:56:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872660.1283633; Wed, 15 Jan 2025 14:56:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY4p5-0000bI-5g; Wed, 15 Jan 2025 14:56:47 +0000
Received: by outflank-mailman (input) for mailman id 872660;
 Wed, 15 Jan 2025 14:56:45 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <anthony@xenproject.org>) id 1tY4p3-0000av-Cc
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 14:56:45 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <anthony@xenproject.org>) id 1tY4ou-0062Go-03;
 Wed, 15 Jan 2025 14:56:36 +0000
Received: from [2a01:e0a:1da:8420:b77:bd5:6e45:7633] (helo=l14)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from <anthony@xenproject.org>) id 1tY4ot-006YOe-34;
 Wed, 15 Jan 2025 14:56:36 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:
	References:Message-ID:Subject:Cc:To:From:Date;
	bh=2JGUJAMLL1XKv0Y7qTfGRdis3gVj47RCSAUZ8iaqpRs=; b=dnZHGZbRIFD4tBW8WgvIjPKAXe
	gYSQ/HTPRq9n/pzTRAwCVPBWd6WJtlsaBfRB47d7KDwTxTu/OVgU2+R+JzRbICKWznlUz1U9Yl60r
	o/WzMEMp/l0EJyXnf1i6s5+i60gg+HK7mdwlfFqyC45R2MlTZ8VsJThHrU53Efs+ca7Q=;
Date: Wed, 15 Jan 2025 15:56:33 +0100
From: Anthony PERARD <anthony@xenproject.org>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Roger Pau Monne <roger.pau@citrix.com>, qemu-devel@nongnu.org,
	Stefano Stabellini <sstabellini@kernel.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E . Iglesias" <edgar.iglesias@gmail.com>,
	Kevin Wolf <kwolf@redhat.com>, Hanna Reitz <hreitz@redhat.com>,
	=?iso-8859-1?Q?Marc-Andr=E9?= Lureau <marcandre.lureau@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>, xen-devel@lists.xenproject.org,
	qemu-block@nongnu.org
Subject: Re: [PATCH 1/4] hw/xen: Use xs_node_read() from xs_node_vscanf()
Message-ID: <Z4fMoSQwPX8j_OdB@l14>
References: <fc9b22c55eaaa79a3ef9829c270bc4b4e93be7a0.camel@infradead.org>
 <20250110100326.527101-1-dwmw2@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250110100326.527101-1-dwmw2@infradead.org>

On Fri, Jan 10, 2025 at 10:03:23AM +0000, David Woodhouse wrote:
> From: David Woodhouse <dwmw@amazon.co.uk>
> 
> Reduce some duplication.
> 
> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>

Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 14:57:03 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 14:57:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872663.1283642 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY4pL-000106-FE; Wed, 15 Jan 2025 14:57:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872663.1283642; Wed, 15 Jan 2025 14:57:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY4pL-0000zz-CO; Wed, 15 Jan 2025 14:57:03 +0000
Received: by outflank-mailman (input) for mailman id 872663;
 Wed, 15 Jan 2025 14:57:02 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <anthony@xenproject.org>) id 1tY4pK-0000yV-Dl
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 14:57:02 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <anthony@xenproject.org>) id 1tY4pD-0062HZ-33;
 Wed, 15 Jan 2025 14:56:56 +0000
Received: from [2a01:e0a:1da:8420:b77:bd5:6e45:7633] (helo=l14)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from <anthony@xenproject.org>) id 1tY4pD-006YTf-2v;
 Wed, 15 Jan 2025 14:56:56 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:
	References:Message-ID:Subject:Cc:To:From:Date;
	bh=AnhBRDX48bJviOKiysfUJNF9u44GXhj3N5I2+RGwuNM=; b=MAhuCqUDxqg04iMgtvdP95bRxN
	ctoK9w49K28ZFSK9MXMOyXeHTKzGj3juTMJRXjhN6zcfMCukj3ssLlNRi1vEcQ+OID5tUc3rcmpvE
	WMIKRE69F0KeMJR+XTaGiwKa6wawOxjPcIoE6X1B14HLDvcXHD/0nDSiBQrE285FR0lU=;
Date: Wed, 15 Jan 2025 15:56:53 +0100
From: Anthony PERARD <anthony@xenproject.org>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Roger Pau Monne <roger.pau@citrix.com>, qemu-devel@nongnu.org,
	Stefano Stabellini <sstabellini@kernel.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E . Iglesias" <edgar.iglesias@gmail.com>,
	Kevin Wolf <kwolf@redhat.com>, Hanna Reitz <hreitz@redhat.com>,
	=?iso-8859-1?Q?Marc-Andr=E9?= Lureau <marcandre.lureau@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>, xen-devel@lists.xenproject.org,
	qemu-block@nongnu.org
Subject: Re: [PATCH 2/4] hw/xen: Use xs_node_read() from
 xen_console_get_name()
Message-ID: <Z4fMtS-a_AwMh2N1@l14>
References: <fc9b22c55eaaa79a3ef9829c270bc4b4e93be7a0.camel@infradead.org>
 <20250110100326.527101-1-dwmw2@infradead.org>
 <20250110100326.527101-2-dwmw2@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250110100326.527101-2-dwmw2@infradead.org>

On Fri, Jan 10, 2025 at 10:03:24AM +0000, David Woodhouse wrote:
> From: David Woodhouse <dwmw@amazon.co.uk>
> 
> Now that xs_node_read() can construct a node path, no need to open-code it.
> 
> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>

Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 14:59:27 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 14:59:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872677.1283652 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY4re-0001hz-Ra; Wed, 15 Jan 2025 14:59:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872677.1283652; Wed, 15 Jan 2025 14:59:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY4re-0001hs-P4; Wed, 15 Jan 2025 14:59:26 +0000
Received: by outflank-mailman (input) for mailman id 872677;
 Wed, 15 Jan 2025 14:59:25 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <anthony@xenproject.org>) id 1tY4rd-0001hm-HT
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 14:59:25 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <anthony@xenproject.org>) id 1tY4rX-0062OJ-12;
 Wed, 15 Jan 2025 14:59:19 +0000
Received: from [2a01:e0a:1da:8420:b77:bd5:6e45:7633] (helo=l14)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from <anthony@xenproject.org>) id 1tY4rX-006YdT-14;
 Wed, 15 Jan 2025 14:59:19 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:
	References:Message-ID:Subject:Cc:To:From:Date;
	bh=g6ZccKN3Kv3NK06xynw/0uxO3uPMnSlSJGwP6KYqqZs=; b=2+KpnbdwkNahfVqDBjZWAm5bAx
	vyY72fWuZTi7YeGogBEkEv4ksh3u3wPc0Zmg9U9/ELiFGmdLaubhHk58xSw2/ShT0Wk6PaBu5RTeC
	7jag/X/NfGJdw0UnZB5Mjqt5kfw7xUFZEr0JHb2Yw262zmjr07zb1s2WVxikc5319Mf4=;
Date: Wed, 15 Jan 2025 15:59:17 +0100
From: Anthony PERARD <anthony@xenproject.org>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Roger Pau Monne <roger.pau@citrix.com>, qemu-devel@nongnu.org,
	Stefano Stabellini <sstabellini@kernel.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E . Iglesias" <edgar.iglesias@gmail.com>,
	Kevin Wolf <kwolf@redhat.com>, Hanna Reitz <hreitz@redhat.com>,
	=?iso-8859-1?Q?Marc-Andr=E9?= Lureau <marcandre.lureau@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>, xen-devel@lists.xenproject.org,
	qemu-block@nongnu.org
Subject: Re: [PATCH 3/4] hw/xen: Use xs_node_read() from xen_netdev_get_name()
Message-ID: <Z4fNRZUwa5hTmo6q@l14>
References: <fc9b22c55eaaa79a3ef9829c270bc4b4e93be7a0.camel@infradead.org>
 <20250110100326.527101-1-dwmw2@infradead.org>
 <20250110100326.527101-3-dwmw2@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250110100326.527101-3-dwmw2@infradead.org>

On Fri, Jan 10, 2025 at 10:03:25AM +0000, David Woodhouse wrote:
> From: David Woodhouse <dwmw@amazon.co.uk>
> 
> Now that xs_node_read() can construct a node path, no need to open-code it.
> 
> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>

Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 15:03:54 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 15:03:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872688.1283663 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY4vr-0003gd-93; Wed, 15 Jan 2025 15:03:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872688.1283663; Wed, 15 Jan 2025 15:03:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY4vr-0003gW-6X; Wed, 15 Jan 2025 15:03:47 +0000
Received: by outflank-mailman (input) for mailman id 872688;
 Wed, 15 Jan 2025 15:03:46 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=hmQ5=UH=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tY4vq-0003gO-CP
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 15:03:46 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ea06bf42-d351-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 16:03:44 +0100 (CET)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-aa689a37dd4so1305339266b.3
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 07:03:44 -0800 (PST)
Received: from andrew-laptop.. ([46.149.103.11])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c95af7besm778137966b.143.2025.01.15.07.03.43
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 15 Jan 2025 07:03:43 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ea06bf42-d351-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736953424; x=1737558224; 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=rKiJKRVfHVQ9bFVeIoVGgxmC6qz+HqDIbmFOHXUpcyk=;
        b=GRa6VdgPwq93/IJuGLd0LWjHLfKvn/PTl6Km0UEY2yFw15Tq7NyCnLJ+ERUlYQxt+i
         SIID4hArEd6R558pzJCCcP5exY7my264FxoHBNySNAIFTdt+B7s1nwEHMEJc7PGGGzPx
         8tCbfStuCDU7LthQDvRu4ZFfUtfxrk0wdt6b8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736953424; x=1737558224;
        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=rKiJKRVfHVQ9bFVeIoVGgxmC6qz+HqDIbmFOHXUpcyk=;
        b=m9glMBo/0ku2xUcCMfjATgjpB4V8pLrha9FMCBbByH6RFdMb7MUj9hMR9H83ahPswk
         2hY5mm2tPhhqLe2P9SsytvpeEbEYgpehlnvZVVvxN0o3gsg8+feRTX5Agek5rIjNuhXD
         DWj3NaRwUeU9JcHtnlwTgHpcEshnE+ytEc7HifvWGlgNru1t/hh98S9gPQc8fv7fe3uC
         6QhlDdunIEdI5gYs6AEJOS2D00lDv3vpbfGmoiSr+ac044+KSoEFJiuq7KwHmGWwcGTQ
         lwXu/6H9doY6F6fJYcIGrv2Gb5fdSDsixY2Rhv5WkWdBgsNoH/Hgu1ZdWPbp737aE8Kk
         b2lQ==
X-Gm-Message-State: AOJu0YzQ0ynsgjZE3/M39aRMh6TcHO+lvLnzXdIdDkeb329cqx4oFpQD
	cZCfH0noYSSQUZA4PUdUbHbhvirZkGGP/YPJJlOROHpN6lJShAf9sNlYajIHY/qs8YQ0uwdgRSY
	+xjM=
X-Gm-Gg: ASbGncs3PLM9EPg5dTWXDfwlu4fbPMy1hcp+YGpV7gDPagMhQCPGplzOb3x6LXgbh7k
	W6GSh6ZBx6UxwrIkrNKLD669Wn1QnC+CwxiU6jgOtIKqN/9W0XUr3TGlktt0UwhSjrf2wUGopWP
	pBB3KOGkemR2ZTKGdvGx3PDjuOiGPeeJ0suj3QCJqUN8FxJkXNG/QlzrC8Yz2seMfePY1uDA5zU
	C4I4XFT62tE4PCB3YpOuA3mDFmI9Q4wA7OiveDi1usjWPvi3sr82tdt8LuTNoVNOkhZ
X-Google-Smtp-Source: AGHT+IEzi8m1j62lmsQ0TX5gR5F7sOxFs318coxNOl6AszDGbySxU71ZvCDormRX9P8mdPvmmJX3LQ==
X-Received: by 2002:a17:907:60cf:b0:aa6:8b38:52a3 with SMTP id a640c23a62f3a-ab2abcb07e9mr3022667966b.50.1736953423587;
        Wed, 15 Jan 2025 07:03:43 -0800 (PST)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Shawn Anastasio <sanastasio@raptorengineering.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH] xen/ppc: Fix double xen_ulong_t typedef in public/arch-ppc.h
Date: Wed, 15 Jan 2025 15:03:39 +0000
Message-Id: <20250115150339.53931-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

public/arch-ppc.h contains two adjacent #ifndef __ASSEMBLY__ blocks.

With these merged, it becomes very obvious that there's a duplicate
definition of xen_ulong_t, which is also noticed by the docs build:

  /usr/bin/perl -w /local/xen.git/docs/xen-headers -O html/hypercall/ppc \
          -T 'arch-ppc - Xen public headers' \
          -X arch-arm -X arch-riscv -X arch-x86_32 -X arch-x86_64 \
          -X xen-arm -X xen-riscv -X xen-x86_32 -X xen-x86_64 \
          -X arch-x86 \
          /local/xen.git/docs/../xen include/public include/xen/errno.h
  include/public/memory.h:63: multiple definitions of Typedef xen_ulong_t: include/public/arch-ppc.h:55
  include/public/memory.h:63: multiple definitions of Typedef xen_ulong_t: include/public/arch-ppc.h:61
  include/public/memory.h:63: multiple definitions of Typedef xen_ulong_t: include/public/arch-ppc.h:61
  include/public/memory.h:63: multiple definitions of Typedef xen_ulong_t: include/public/arch-ppc.h:55

Drop the second typedef.  Finally, annotate the #endif so it's clear
what it refers to.

Fixes: 08c192cc1127 ("xen/ppc: Add public/arch-ppc.h")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Shawn Anastasio <sanastasio@raptorengineering.com>
CC: Anthony PERARD <anthony.perard@vates.tech>
CC: Michal Orzel <michal.orzel@amd.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Julien Grall <julien@xen.org>
CC: "Roger Pau Monné" <roger.pau@citrix.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
---
 xen/include/public/arch-ppc.h | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/xen/include/public/arch-ppc.h b/xen/include/public/arch-ppc.h
index 33a24e379551..4ca453a2841e 100644
--- a/xen/include/public/arch-ppc.h
+++ b/xen/include/public/arch-ppc.h
@@ -54,11 +54,6 @@ typedef uint64_t xen_pfn_t;
 
 typedef uint64_t xen_ulong_t;
 #define PRI_xen_ulong PRIx64
-#endif
-
-#ifndef __ASSEMBLY__
-
-typedef uint64_t xen_ulong_t;
 
 /*
  * User-accessible registers: most of these need to be saved/restored
@@ -107,6 +102,6 @@ struct xen_arch_domainconfig {
 
 typedef struct xen_pmu_arch { uint8_t dummy; } xen_pmu_arch_t;
 
-#endif
+#endif /* !__ASSEMBLY__ */
 
 #endif /* __XEN_PUBLIC_ARCH_PPC_H__ */
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Jan 15 15:05:25 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 15:05:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872696.1283672 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY4xP-0004CF-IE; Wed, 15 Jan 2025 15:05:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872696.1283672; Wed, 15 Jan 2025 15:05:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY4xP-0004C8-Fb; Wed, 15 Jan 2025 15:05:23 +0000
Received: by outflank-mailman (input) for mailman id 872696;
 Wed, 15 Jan 2025 15:05:22 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <anthony@xenproject.org>) id 1tY4xO-0004C0-Ky
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 15:05:22 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <anthony@xenproject.org>) id 1tY4xJ-0062aL-2b;
 Wed, 15 Jan 2025 15:05:18 +0000
Received: from [2a01:e0a:1da:8420:b77:bd5:6e45:7633] (helo=l14)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from <anthony@xenproject.org>) id 1tY4xJ-006ZVK-2c;
 Wed, 15 Jan 2025 15:05:18 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:
	References:Message-ID:Subject:Cc:To:From:Date;
	bh=vxU56dDafaB9f7pGV0rRAG3uArAQoTOK3XVg8j78Nzs=; b=gIq/iJCEBw/Q62KhDndJkJzity
	ocqigIsgafSERWlqfs3VlIoxEp1iCTeQxAZbArfTmdaAwsHn41oFLPWgfwvK8YHOuDwkmNAWNhv9U
	Zb1ufdLlIqImcPzruD+H68ukvObpRRaQ1jppHW+BYwZSw4c5pl15xn6W9J1kX2sEE18Y=;
Date: Wed, 15 Jan 2025 16:05:14 +0100
From: Anthony PERARD <anthony@xenproject.org>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Roger Pau Monne <roger.pau@citrix.com>, qemu-devel@nongnu.org,
	Stefano Stabellini <sstabellini@kernel.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E . Iglesias" <edgar.iglesias@gmail.com>,
	Kevin Wolf <kwolf@redhat.com>, Hanna Reitz <hreitz@redhat.com>,
	=?iso-8859-1?Q?Marc-Andr=E9?= Lureau <marcandre.lureau@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>, xen-devel@lists.xenproject.org,
	qemu-block@nongnu.org
Subject: Re: [PATCH 4/4] hw/xen: Use xs_node_read() from xenstore_read_str()
 instead of open-coding it
Message-ID: <Z4fOqgffMsQ4xR-B@l14>
References: <fc9b22c55eaaa79a3ef9829c270bc4b4e93be7a0.camel@infradead.org>
 <20250110100326.527101-1-dwmw2@infradead.org>
 <20250110100326.527101-4-dwmw2@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250110100326.527101-4-dwmw2@infradead.org>

On Fri, Jan 10, 2025 at 10:03:26AM +0000, David Woodhouse wrote:
> From: David Woodhouse <dwmw@amazon.co.uk>
> 
> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>

Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 15:06:56 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 15:06:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872704.1283683 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY4ys-0004kX-Tg; Wed, 15 Jan 2025 15:06:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872704.1283683; Wed, 15 Jan 2025 15:06:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY4ys-0004kQ-PP; Wed, 15 Jan 2025 15:06:54 +0000
Received: by outflank-mailman (input) for mailman id 872704;
 Wed, 15 Jan 2025 15:06:53 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=dCnP=UH=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tY4yr-0004kG-9U
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 15:06:53 +0000
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com
 [2a00:1450:4864:20::329])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 59361bc6-d352-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 16:06:51 +0100 (CET)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-436345cc17bso49319625e9.0
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 07:06:51 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-437c74ac221sm25832325e9.11.2025.01.15.07.06.49
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 15 Jan 2025 07:06:50 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 59361bc6-d352-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1736953610; x=1737558410; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=/9x7n8Nj7/KmGswwOkmdXcJc8JRIk694v+DXVaWg5Kc=;
        b=LNJwqwnIriwbiexx6f9a67wrbZ1ZWJkU9hIHBciVsmoC2s9JkCCLi1PGon0UHQR/aa
         +1bRIsPWa2Xt9z1SYx0RVqsXBlbmeLIX7rDLTLS0fk32Ie7hslcRK+CRaAqA7EH+AiBp
         VyZm9DnxbunXCOs6hxLx9jHo94vTrBu30P/l1z7+rLKP8KjpoMGDGWLmfm7K0nOHeUeM
         xd1X2aQujeLIy/7UO9Q0y1XyLVxHzVXxvVKOaLl/CWP7bzGomLSalOE12B6m1xe2R/J1
         zPvM40s1nUwOa5dT7vk8dcV3LB1w1eBx0YGjzfsxgWJQ/ExGlp5Q6WpWkKjI+cpJJSaW
         mb9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736953610; x=1737558410;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=/9x7n8Nj7/KmGswwOkmdXcJc8JRIk694v+DXVaWg5Kc=;
        b=rBL+MukW1/HgNj2lICur2hZlqM2ZCJFE9obi0We+gUhFq2PNhoWwBffmHPEHFaQG13
         nPtS2mdtWjM6FSnQH3OCfAlDeG4tNf9kS4VBV+Y8qqnLT6DI/HhGJFDCjtQGsN5MDPHZ
         hMTBhHEJl8E5Tp6CWUdzNdAg14LV2fe6xDiaUqDq9EmHDr4j2lYwTsruHRzZkkvn/zxF
         2sOKNiCSVMZOc/X2bQL1UwAlXI+QtRPmfTB3QsRxA9sM+40kQc7SGFKimQjmQFeMRpz6
         IvdbprzNivRNHIKfJMugB+7m0vyRchpIDYwHfmG8sa5wRBrjcI9BKavegXQZOlulc3/n
         Y5Ew==
X-Forwarded-Encrypted: i=1; AJvYcCWcVNLHARBqv4yaypctSsqOx/2fzUk9Pz0iCpF5n1nwibef0DCZvPUBIaAgmO32E/gFdHDmOmJeXMs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyzzCJ/YrvTkxxSTAYqx27wtYt/dEetcfjco/JkcZlBZ/8JyEUZ
	hEMcG/CMkp+WaV40JVHhC1FAyJjzLbnH8swA5HKjwzrnL6FLo6T+1FVEDn0Yzg==
X-Gm-Gg: ASbGncuRhOnoy5O/qtzXnsaYZCYfBF5uKjNpLVK4D1sDizbvtgTTpJNwmyxsqYP/V8e
	Ix6tdamSDk2nQrGqxhPvHPyCwNPFAJIqccQlNJ3ip8EOHDLSP2f0YUkbU4cCmKcRb/3NhsXlaT6
	6grws690ChKSoguW6DYY7U45He0Shg0MNneLsAzbQs5BUwWRt2qGTxbdHoYYourmn+GjmLyoa4N
	x0vP23f0Qwd+8ObXkglWC9+8oAN+qK1/DPbZHWOAnKtGeMj3watVfuGVz9EVaWc4tiYXSJntWcI
	kkFMKOn7yDFFEkqvLERImpgb8P1og8gvnu1RQG3WQA==
X-Google-Smtp-Source: AGHT+IFsiu1KRaWL1i05xrnLoX9hwxvCIVvqwAxC5IyMv/dI0s2Ai/UtjcHwsmSQsVEAVp+VMKRRnQ==
X-Received: by 2002:a05:600c:450d:b0:434:a711:ace4 with SMTP id 5b1f17b1804b1-436e26a9510mr287410195e9.17.1736953610395;
        Wed, 15 Jan 2025 07:06:50 -0800 (PST)
Message-ID: <0bb26991-9310-445d-8eee-8cb421f18543@suse.com>
Date: Wed, 15 Jan 2025 16:06:49 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/ppc: Fix double xen_ulong_t typedef in
 public/arch-ppc.h
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Shawn Anastasio <sanastasio@raptorengineering.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <20250115150339.53931-1-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250115150339.53931-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15.01.2025 16:03, Andrew Cooper wrote:
> public/arch-ppc.h contains two adjacent #ifndef __ASSEMBLY__ blocks.
> 
> With these merged, it becomes very obvious that there's a duplicate
> definition of xen_ulong_t, which is also noticed by the docs build:
> 
>   /usr/bin/perl -w /local/xen.git/docs/xen-headers -O html/hypercall/ppc \
>           -T 'arch-ppc - Xen public headers' \
>           -X arch-arm -X arch-riscv -X arch-x86_32 -X arch-x86_64 \
>           -X xen-arm -X xen-riscv -X xen-x86_32 -X xen-x86_64 \
>           -X arch-x86 \
>           /local/xen.git/docs/../xen include/public include/xen/errno.h
>   include/public/memory.h:63: multiple definitions of Typedef xen_ulong_t: include/public/arch-ppc.h:55
>   include/public/memory.h:63: multiple definitions of Typedef xen_ulong_t: include/public/arch-ppc.h:61
>   include/public/memory.h:63: multiple definitions of Typedef xen_ulong_t: include/public/arch-ppc.h:61
>   include/public/memory.h:63: multiple definitions of Typedef xen_ulong_t: include/public/arch-ppc.h:55
> 
> Drop the second typedef.  Finally, annotate the #endif so it's clear
> what it refers to.
> 
> Fixes: 08c192cc1127 ("xen/ppc: Add public/arch-ppc.h")
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

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




From xen-devel-bounces@lists.xenproject.org Wed Jan 15 15:09:16 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 15:09:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872713.1283692 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY515-0005JX-7J; Wed, 15 Jan 2025 15:09:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872713.1283692; Wed, 15 Jan 2025 15:09:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY515-0005JQ-4m; Wed, 15 Jan 2025 15:09:11 +0000
Received: by outflank-mailman (input) for mailman id 872713;
 Wed, 15 Jan 2025 15:09: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
 <SRS0=4o+i=UH=cloud.com=bernhard.kaindl@srs-se1.protection.inumbo.net>)
 id 1tY514-0005JK-16
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 15:09:10 +0000
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com
 [2a00:1450:4864:20::334])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id aae0f255-d352-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 16:09:08 +0100 (CET)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-436202dd730so49161075e9.2
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 07:09:08 -0800 (PST)
Received: from localhost ([185.68.248.203]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-437c74d8e06sm26718535e9.31.2025.01.15.07.09.06
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 15 Jan 2025 07:09:06 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: aae0f255-d352-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736953747; x=1737558547; 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=FM1nUjDiePbUjnEKMcMFCsNEpDocEMi4X6ouoLCy73c=;
        b=k5twQMaOiqOUe/ZjdhWgj2d+Zn49JFA7B+PlK0XT3IyIRrlLLOnfgnV9mWfYiEMTj8
         /u0XAPC2A8ylg9ApRhouohQdXApN3pk0eNLnqHdF57zehgz/0xqBB9sLjLsgSWtyuomf
         YpB0nCLFjSM1LkR14kyKklPB4qTcBkjfJCac4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736953747; x=1737558547;
        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=FM1nUjDiePbUjnEKMcMFCsNEpDocEMi4X6ouoLCy73c=;
        b=Ako9+nFe2b+kpG1F3NWwQd0Vxf4a/QF38U638OZKNXd+y4jcJQB8R/VHiVZeWgvjVt
         DHJTmE0b4ViM/MykGJ8X142KVva14VIydzFpPVnn+pH7Dksad9v6Nfk6EMsOse/MTf9h
         Mz816YD0OWD9gAzrfN8jZ+z1vdEtS2+D5YMu2hqx6KZ3BoorgYckgNqrhUEBAT6mTMHv
         vgIDQvmn7zW49/klJ0PmqmHUPXqZI2D3MHlaYkjPLvFRWPfZxUretOJTsCtAC5LDgn6f
         qsjj2mfwxf9NvxBUbfGwCN7Nzu1uPMfWCs7c8n5y3L7qSr7f6xq+IZQndu5yzIfhoPj/
         zw/A==
X-Gm-Message-State: AOJu0Yx45wgNIwhz6PnwwTaaIlWFVHG06VxCrbdss5BBHlii8rEUhPe1
	a+B/yvqMhCRKCILWie7UCx2vwkarn+Ow8FDeLdCaXxIwuz1mJ9QPgYMGnVUHHc0r0jSjHjBO7Qq
	JimEOWA==
X-Gm-Gg: ASbGncsJWvwWXcRoEmOAxdLp0MZxQkbapjhta/TsPR3OUskPqJSmNUaBFEnQ6HDPfUX
	HkmfN/WtZqE6qI157kowbvWZNTQipA5iatzHD3Ie6Da4VzJZz9F4vEPIYlKzUmXq65GOVYT9pDx
	4XhAFDsisOCTFq9ofW3Bqdf3k9ANCYfgj5XfLE6aK461uKorK+fVdA7bs8v0atp0JqT3NjP8ygm
	eMty7VX5g/+5jUSAGcrDkQjs5U+uZUBXTK6M9HMzX7u1IyrqEx3NHvrGi0UUQ==
X-Google-Smtp-Source: AGHT+IEWf3YrPFwQJP4KWvTSkEMRT7ziqadr9R1A2EpqwHuPg747bX7FzrNPeP4dc5Pi6K8sxIPFXA==
X-Received: by 2002:a05:600c:4586:b0:434:9e1d:7626 with SMTP id 5b1f17b1804b1-436e26f4b91mr233179465e9.25.1736953747285;
        Wed, 15 Jan 2025 07:09:07 -0800 (PST)
From: Bernhard Kaindl <bernhard.kaindl@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Bernhard Kaindl <bernhard.kaindl@cloud.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Ross Lagerwall <ross.lagerwall@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH] docs/misc: Fix a few typos
Date: Wed, 15 Jan 2025 16:09:04 +0100
Message-ID: <5ab7cdad0c275dc2de900568ae3105be60f32db5.1736953714.git.bernhard.kaindl@cloud.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

While skimming through the misc docs, I spotted a few typos.

Signed-off-by: Bernhard Kaindl <bernhard.kaindl@cloud.com>
---
 docs/misc/livepatch.pandoc            |  8 ++++----
 docs/misc/netif-staging-grants.pandoc | 10 +++++-----
 docs/misc/printk-formats.txt          |  2 +-
 3 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/docs/misc/livepatch.pandoc b/docs/misc/livepatch.pandoc
index 43010227e5..cbd63d0af8 100644
--- a/docs/misc/livepatch.pandoc
+++ b/docs/misc/livepatch.pandoc
@@ -539,13 +539,13 @@ The type definition of the function are as follow:
 ### .livepatch.xen_depends, .livepatch.depends and .note.gnu.build-id
 
 To support dependencies checking and safe loading (to load the
-appropiate payload against the right hypervisor) there is a need
-to embbed an build-id dependency.
+appropriate payload against the right hypervisor) there is a need
+to embed a build-id dependency.
 
 This is done by the payload containing sections `.livepatch.xen_depends`
 and `.livepatch.depends` which follow the format of an ELF Note.
 The contents of these (name, and description) are specific to the linker
-utilized to build the hypevisor and payload.
+utilized to build the hypervisor and payload.
 
 If GNU linker is used then the name is `GNU` and the description
 is a NT_GNU_BUILD_ID type ID. The description can be an SHA1
@@ -639,7 +639,7 @@ The `name` could be an UUID that stays fixed forever for a given
 payload. It can be embedded into the ELF payload at creation time
 and extracted by tools.
 
-The return value is zero if the payload was succesfully uploaded.
+The return value is zero if the payload was successfully uploaded.
 Otherwise an -XEN_EXX return value is provided. Duplicate `name` are not supported.
 
 The `payload` is the ELF payload as mentioned in the `Payload format` section.
diff --git a/docs/misc/netif-staging-grants.pandoc b/docs/misc/netif-staging-grants.pandoc
index cb33028adc..d7ef4db63a 100644
--- a/docs/misc/netif-staging-grants.pandoc
+++ b/docs/misc/netif-staging-grants.pandoc
@@ -317,7 +317,7 @@ In essence the steps for receiving of a packet in a Linux frontend is as
  process the actual like the steps below. This thread has the purpose of
  aggregating as much copies as possible.]
 
-2) Checks if there are enough rx ring slots that can accomodate the packet.
+2) Checks if there are enough rx ring slots that can accommodate the packet.
 
 3) Gets a request from the ring for the first data slot and fetches the `gref`
    from it.
@@ -375,7 +375,7 @@ In essence the steps for receiving of a packet in a Linux frontend is as
 
 24) Call packet into the network stack.
 
-25) Allocate new pages and any necessary packet metadata strutures to new
+25) Allocate new pages and any necessary packet metadata structures to new
     requests. These requests will then be used in step 1) and so forth.
 
 26) Update the request producer index (`req_prod`)
@@ -391,7 +391,7 @@ In essence the steps for receiving of a packet in a Linux frontend is as
 
 This proposal aims at replacing step 4), 12) and  22) with memcpy if the
 grefs on the Rx ring were requested to be mapped by the guest. Frontend may use
-strategies to allow fast recycling of grants for replinishing the ring,
+strategies to allow fast recycling of grants for replenishing the ring,
 hence letting Domain-0 replace the grant copies with  memcpy instead, which is
 faster.
 
@@ -400,8 +400,8 @@ would need to aggregate as much as grant ops as possible (step 1) and could
 transmit the packet on the transmit function (e.g. Linux ```ndo_start_xmit```)
 as previously proposed
 here\[[0](http://lists.xenproject.org/archives/html/xen-devel/2015-05/msg01504.html)\].
-This would heavily improve efficiency specifially for smaller packets. Which in
-return would decrease RTT, having data being acknoledged much quicker.
+This would heavily improve efficiency specifically for smaller packets. Which in
+return would decrease RTT, having data being acknowledged much quicker.
 
 \clearpage
 
diff --git a/docs/misc/printk-formats.txt b/docs/misc/printk-formats.txt
index 8f666f696a..ce32829dae 100644
--- a/docs/misc/printk-formats.txt
+++ b/docs/misc/printk-formats.txt
@@ -11,7 +11,7 @@ Raw buffer as hex string:
        %*phN   000102 ... 3f
 
        Up to 64 characters.  Buffer length expected via the field_width
-       paramter. i.e. printk("%*ph", 8, buffer);
+       parameter. i.e. printk("%*ph", 8, buffer);
 
 Bitmaps (e.g. cpumask/nodemask):
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Jan 15 16:05:19 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 16:05:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872737.1283726 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY5t8-0007CT-Ia; Wed, 15 Jan 2025 16:05:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872737.1283726; Wed, 15 Jan 2025 16:05:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY5t8-0007CM-G6; Wed, 15 Jan 2025 16:05:02 +0000
Received: by outflank-mailman (input) for mailman id 872737;
 Wed, 15 Jan 2025 16:05: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
 <SRS0=rWPo=UH=casper.srs.infradead.org=BATV+fb641630334796bb9467+7815+infradead.org+dwmw2@srs-se1.protection.inumbo.net>)
 id 1tY5t6-0007CG-Ai
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 16:05:01 +0000
Received: from casper.infradead.org (casper.infradead.org
 [2001:8b0:10b:1236::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7675f05c-d35a-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 17:04:56 +0100 (CET)
Received: from 54-240-197-226.amazon.com ([54.240.197.226]
 helo=freeip.amazon.com)
 by casper.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux))
 id 1tY5t0-0000000FpPP-3M4A; Wed, 15 Jan 2025 16:04:54 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 7675f05c-d35a-11ef-99a4-01e77a169b0f
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:Cc:To:From:Subject:Message-ID:Sender:Reply-To:
	Content-Transfer-Encoding:Content-ID:Content-Description;
	bh=zh4pjrW91hnVRk9ncvSX5fKSLJI2W3pr0C11ZvYhgkw=; b=COaHH0NTaQ4zOSTa5AXhRocW7A
	ffmBNndmpvC1e60QUgXUnCaSKwV4dfe2QWH8ZT0ZXW69d9wUHgXa7XUfC86YvO29/NGdJDJraVLGE
	Pb88o0E6TqZdHZchVZ2Cd4VAjQD9+INywYpfBTPWS70kAUTE4JFTWsR7M8hfj1FyQQBGqay6GOpYi
	CQa0ijnotBUHWbXoEdD1rxesrXATsr/dAybFfGEH5Xeo572ihxnQ8Z5gPFl6LdKOpjCxypw3oTcOc
	J3f5oxXaU8ceGr031bas1X1Dua5UJlQbGb0W+zl2HJSDRF44pCIhDnyn5Lb1Gl/uqcOB4TOm1ByIX
	9GSQiNhg==;
Message-ID: <82d7c9d49843afd44ddb7d14f518551646b921bc.camel@infradead.org>
Subject: Re: [PATCH v2 2/2] xen: do not use '%ms' scanf specifier
From: David Woodhouse <dwmw2@infradead.org>
To: Anthony PERARD <anthony@xenproject.org>, Roger Pau Monne
	 <roger.pau@citrix.com>
Cc: qemu-devel@nongnu.org, Stefano Stabellini <sstabellini@kernel.org>, Paul
 Durrant <paul@xen.org>, "Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
 Kevin Wolf <kwolf@redhat.com>, Hanna Reitz <hreitz@redhat.com>, 
 =?ISO-8859-1?Q?Marc-Andr=E9?= Lureau <marcandre.lureau@redhat.com>, Paolo
 Bonzini <pbonzini@redhat.com>,  xen-devel@lists.xenproject.org,
 qemu-block@nongnu.org
Date: Wed, 15 Jan 2025 17:04:53 +0100
In-Reply-To: <Z4fH0NwPEmjryqoG@l14>
References: <20250110093531.23221-1-roger.pau@citrix.com>
	 <20250110093531.23221-3-roger.pau@citrix.com> <Z4fH0NwPEmjryqoG@l14>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-crBTpTo/dZrAlrKCg/Kg"
User-Agent: Evolution 3.52.3-0ubuntu1 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html


--=-crBTpTo/dZrAlrKCg/Kg
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2025-01-15 at 15:36 +0100, Anthony PERARD wrote:
> On Fri, Jan 10, 2025 at 10:35:31AM +0100, Roger Pau Monne wrote:
> > diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
> > index ef0c2912efa1..989e75fef88f 100644
> > --- a/hw/char/xen_console.c
> > +++ b/hw/char/xen_console.c
> > @@ -550,7 +550,8 @@ static void xen_console_device_create(XenBackendIns=
tance *backend,
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 goto fail;
> > =C2=A0=C2=A0=C2=A0=C2=A0 }
> > =C2=A0
> > -=C2=A0=C2=A0=C2=A0 if (xs_node_scanf(xsh, XBT_NULL, fe, "type", errp, =
"%ms", &type) !=3D 1) {
> > +=C2=A0=C2=A0=C2=A0 type =3D xs_node_read(xsh, XBT_NULL, NULL, errp, "%=
s/%s", fe, "type");
> > +=C2=A0=C2=A0=C2=A0 if (!type) {
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 error_prepend(errp, "f=
ailed to read console device type: ");
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 goto fail;
> > =C2=A0=C2=A0=C2=A0=C2=A0 }
> > @@ -568,7 +569,8 @@ static void xen_console_device_create(XenBackendIns=
tance *backend,
> > =C2=A0
> > =C2=A0=C2=A0=C2=A0=C2=A0 snprintf(label, sizeof(label), "xencons%ld", n=
umber);
> > =C2=A0
> > -=C2=A0=C2=A0=C2=A0 if (xs_node_scanf(xsh, XBT_NULL, fe, "output", NULL=
, "%ms", &output) =3D=3D 1) {
> > +=C2=A0=C2=A0=C2=A0 output =3D xs_node_read(xsh, XBT_NULL, NULL, errp, =
"%s/%s", fe, "output");
>=20
> This now set `errp` on error, when `output =3D=3D NULL`. In case `output`=
 is
> NULL, we check for `number` instead and may generate an error message
> that probably doesn't really make sense.
> =C2=A0=C2=A0=C2=A0 "console: No serial device #2 found: failed to read fr=
om /frontend_path/output"
> And if number =3D=3D 0, we tried to create a null device, and if that
> failed, the error message will just be about the missing xenstore path
> as error_setg() will not set `errp` again.
>=20
> Could you keep ignoring errors from xs_node_read() like it was done with
> xs_node_scanf() (I mean pass `NULL` instead of `errp`)? And we will need
> another patch to fix the wrong use of `error_prepend()` and use
> `error_setg` instead when `serial_hd()` fails.

Ack. I'll make that s/errp/NULL/ change in the original patch, and then
add something like this on top...

=46rom c6ea20c9055f6c5cdd44a56fd6f7f82d301412d1 Mon Sep 17 00:00:00 2001
From: David Woodhouse <dwmw@amazon.co.uk>
Date: Wed, 15 Jan 2025 15:46:06 +0000
Subject: [PATCH] hw/xen: Fix errp handling in xen_console

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
 hw/char/xen_console.c | 32 ++++++++++++++++++++------------
 1 file changed, 20 insertions(+), 12 deletions(-)

diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
index 9338e00473..9e7f6da343 100644
--- a/hw/char/xen_console.c
+++ b/hw/char/xen_console.c
@@ -569,7 +569,7 @@ static void xen_console_device_create(XenBackendInstanc=
e *backend,
=20
     snprintf(label, sizeof(label), "xencons%ld", number);
=20
-    output =3D xs_node_read(xsh, XBT_NULL, NULL, NULL, "%s/%s", fe, "outpu=
t");
+    output =3D xs_node_read(xsh, XBT_NULL, NULL, errp, "%s/%s", fe, "outpu=
t");
     if (output) {
         /*
          * FIXME: sure we want to support implicit

@@ -581,19 +581,27 @@ static void xen_console_device_create(XenBackendInsta=
nce *backend,
                        output);
             goto fail;
         }
-    } else if (number) {
-        cd =3D serial_hd(number);
-        if (!cd) {
-            error_prepend(errp, "console: No serial device #%ld found: ",
-                          number);
-            goto fail;
-        }
+    } else if (errno !=3D ENOENT) {
+        error_prepend(errp, "console: No valid chardev found: ");
+        goto fail;
     } else {
-        /* No 'output' node on primary console: use null. */
-        cd =3D qemu_chr_new(label, "null", NULL);
-        if (!cd) {
-            error_setg(errp, "console: failed to create null device");
-            goto fail;
+        if (errp) {
+            error_free(*errp);
+        }
+        if (number) {
+            cd =3D serial_hd(number);
+            if (!cd) {
+                error_setg(errp, "console: No serial device #%ld found: ",
+                           number);
+                goto fail;
+            }
+        } else {
+            /* No 'output' node on primary console: use null. */
+            cd =3D qemu_chr_new(label, "null", NULL);
+            if (!cd) {
+                error_setg(errp, "console: failed to create null device");
+                goto fail;
+            }
         }
     }
=20
--=20
2.47.0



--=-crBTpTo/dZrAlrKCg/Kg
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD9Aw
ggSOMIIDdqADAgECAhAOmiw0ECVD4cWj5DqVrT9PMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0yNDAxMzAwMDAwMDBaFw0zMTEx
MDkyMzU5NTlaMEExCzAJBgNVBAYTAkFVMRAwDgYDVQQKEwdWZXJva2V5MSAwHgYDVQQDExdWZXJv
a2V5IFNlY3VyZSBFbWFpbCBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMjvgLKj
jfhCFqxYyRiW8g3cNFAvltDbK5AzcOaR7yVzVGadr4YcCVxjKrEJOgi7WEOH8rUgCNB5cTD8N/Et
GfZI+LGqSv0YtNa54T9D1AWJy08ZKkWvfGGIXN9UFAPMJ6OLLH/UUEgFa+7KlrEvMUupDFGnnR06
aDJAwtycb8yXtILj+TvfhLFhafxroXrflspavejQkEiHjNjtHnwbZ+o43g0/yxjwnarGI3kgcak7
nnI9/8Lqpq79tLHYwLajotwLiGTB71AGN5xK+tzB+D4eN9lXayrjcszgbOv2ZCgzExQUAIt98mre
8EggKs9mwtEuKAhYBIP/0K6WsoMnQCcCAwEAAaOCAVwwggFYMBIGA1UdEwEB/wQIMAYBAf8CAQAw
HQYDVR0OBBYEFIlICOogTndrhuWByNfhjWSEf/xwMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6en
IZ3zbcgPMA4GA1UdDwEB/wQEAwIBhjAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIweQYI
KwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYIKwYB
BQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RD
QS5jcnQwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0
QXNzdXJlZElEUm9vdENBLmNybDARBgNVHSAECjAIMAYGBFUdIAAwDQYJKoZIhvcNAQELBQADggEB
ACiagCqvNVxOfSd0uYfJMiZsOEBXAKIR/kpqRp2YCfrP4Tz7fJogYN4fxNAw7iy/bPZcvpVCfe/H
/CCcp3alXL0I8M/rnEnRlv8ItY4MEF+2T/MkdXI3u1vHy3ua8SxBM8eT9LBQokHZxGUX51cE0kwa
uEOZ+PonVIOnMjuLp29kcNOVnzf8DGKiek+cT51FvGRjV6LbaxXOm2P47/aiaXrDD5O0RF5SiPo6
xD1/ClkCETyyEAE5LRJlXtx288R598koyFcwCSXijeVcRvBB1cNOLEbg7RMSw1AGq14fNe2cH1HG
W7xyduY/ydQt6gv5r21mDOQ5SaZSWC/ZRfLDuEYwggWbMIIEg6ADAgECAhAH5JEPagNRXYDiRPdl
c1vgMA0GCSqGSIb3DQEBCwUAMEExCzAJBgNVBAYTAkFVMRAwDgYDVQQKEwdWZXJva2V5MSAwHgYD
VQQDExdWZXJva2V5IFNlY3VyZSBFbWFpbCBHMjAeFw0yNDEyMzAwMDAwMDBaFw0yODAxMDQyMzU5
NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqGSIb3DQEBAQUAA4IC
DwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZeYAS/SRV6zmfXlXaZ
sNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2zkC9S7/yHDYnqegqt
w4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qGpgFdZEk2/c//ZvUN
i12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41vav1RhZJzYan4a1gU0
kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0cvnO8FM6PTqsnSbcc
0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PWPU6zfQTOMZ9uLQRR
ci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXtREF5lLXxp+CJ6KKS
blPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQrlR0gO3lBzuyPPArV
hvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7IqaAovAX0d+f1YjbmC
VsAwjhLmveFjNwIDAQABo4IBsDCCAawwHwYDVR0jBBgwFoAUiUgI6iBOd2uG5YHI1+GNZIR//HAw
HQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3bXcyQGluZnJhZGVh
ZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEBMA4GA1UdDwEB/wQE
AwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwewYDVR0fBHQwcjA3oDWgM4YxaHR0
cDovL2NybDMuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNybDA3oDWgM4YxaHR0
cDovL2NybDQuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNybDB2BggrBgEFBQcB
AQRqMGgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBABggrBgEFBQcwAoY0
aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNydDANBgkq
hkiG9w0BAQsFAAOCAQEAQXc4FPiPLRnTDvmOABEzkIumojfZAe5SlnuQoeFUfi+LsWCKiB8Uextv
iBAvboKhLuN6eG/NC6WOzOCppn4mkQxRkOdLNThwMHW0d19jrZFEKtEG/epZ/hw/DdScTuZ2m7im
8ppItAT6GXD3aPhXkXnJpC/zTs85uNSQR64cEcBFjjoQDuSsTeJ5DAWf8EMyhMuD8pcbqx5kRvyt
JPsWBQzv1Dsdv2LDPLNd/JUKhHSgr7nbUr4+aAP2PHTXGcEBh8lTeYea9p4d5k969pe0OHYMV5aL
xERqTagmSetuIwolkAuBCzA9vulg8Y49Nz2zrpUGfKGOD0FMqenYxdJHgDCCBZswggSDoAMCAQIC
EAfkkQ9qA1FdgOJE92VzW+AwDQYJKoZIhvcNAQELBQAwQTELMAkGA1UEBhMCQVUxEDAOBgNVBAoT
B1Zlcm9rZXkxIDAeBgNVBAMTF1Zlcm9rZXkgU2VjdXJlIEVtYWlsIEcyMB4XDTI0MTIzMDAwMDAw
MFoXDTI4MDEwNDIzNTk1OVowHjEcMBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzCCAiIwDQYJ
KoZIhvcNAQEBBQADggIPADCCAgoCggIBANqWLse95HW2F7FhfH9bugyT/danKmmXrbMnz5GZNAfj
Jl5gBL9JFXrOZ9eVdpmw04Tp6aDxZctFLoEDvSWKi367Q7Sg+ci+fH4KwwfQ8Pi0IpIKx2n5emEg
nbOQL1Lv/IcNiep6Cq3DiyaSpSp/RZf+CAfUNySHS8eWmhLU6jGpSD6hxTpYKye7PmrmvMWwfGEP
WoamAV1kSTb9z/9m9Q2LXa89aKmTxNwnAfD3Ohn9mtU3JukwILRMewn9QRXK7KzM+01h5hkCE4nj
W9q/VGFknNhqfhrWBTSQoE9CSVylASGrjzCgS7XmKy/BaH3/7mOOHQv5g1o3Qj/+cdKnpT0I5Qb1
nRy+c7wUzo9OqydJtxzSP4ZyHA4dELto/a3m/ay1XHcpum1pgTOLgxAfGb/T4dCkwRUstSKLMmpL
g9Y9TrN9BM4xn24tBFFyL5znGG0wQGzOVAM68RBzIQb6Fz758fjsr4yZnPbVsU1+gHEs/puNHrG0
9e1EQXmUtfGn4InoopJuU8p5VGD9S3Ikd4UoBlc7xl5yjtNlQxUeYrRlnUSmdlucCEoTX1n4UmtA
9CuVHSA7eUHO7I88CtWG9bGOU7tLgOZoSEvNqtaL/N7sQbBZK4jZ4Rr/zNTQg1SwYjjLB7u96lDP
sipoCi8BfR35/ViNuYJWwDCOEua94WM3AgMBAAGjggGwMIIBrDAfBgNVHSMEGDAWgBSJSAjqIE53
a4blgcjX4Y1khH/8cDAdBgNVHQ4EFgQUXGIam3Bs59Y60yTmWgfDu6pZQ6cwMAYDVR0RBCkwJ4ET
ZHdtdzJAaW5mcmFkZWFkLm9yZ4EQZGF2aWRAd29vZGhvdS5zZTAUBgNVHSAEDTALMAkGB2eBDAEF
AQEwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDB7BgNVHR8E
dDByMDegNaAzhjFodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVtYWlsRzIu
Y3JsMDegNaAzhjFodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVtYWlsRzIu
Y3JsMHYGCCsGAQUFBwEBBGowaDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29t
MEAGCCsGAQUFBzAChjRodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVt
YWlsRzIuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQBBdzgU+I8tGdMO+Y4AETOQi6aiN9kB7lKWe5Ch
4VR+L4uxYIqIHxR7G2+IEC9ugqEu43p4b80LpY7M4KmmfiaRDFGQ50s1OHAwdbR3X2OtkUQq0Qb9
6ln+HD8N1JxO5nabuKbymki0BPoZcPdo+FeRecmkL/NOzzm41JBHrhwRwEWOOhAO5KxN4nkMBZ/w
QzKEy4PylxurHmRG/K0k+xYFDO/UOx2/YsM8s138lQqEdKCvudtSvj5oA/Y8dNcZwQGHyVN5h5r2
nh3mT3r2l7Q4dgxXlovERGpNqCZJ624jCiWQC4ELMD2+6WDxjj03PbOulQZ8oY4PQUyp6djF0keA
MYIDuzCCA7cCAQEwVTBBMQswCQYDVQQGEwJBVTEQMA4GA1UEChMHVmVyb2tleTEgMB4GA1UEAxMX
VmVyb2tleSBTZWN1cmUgRW1haWwgRzICEAfkkQ9qA1FdgOJE92VzW+AwDQYJYIZIAWUDBAIBBQCg
ggE3MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTI1MDExNTE2MDQ1
M1owLwYJKoZIhvcNAQkEMSIEIPSSazb4uD5mR6Adn3HoITo277uHzV3rkKh1qlPSDqmzMGQGCSsG
AQQBgjcQBDFXMFUwQTELMAkGA1UEBhMCQVUxEDAOBgNVBAoTB1Zlcm9rZXkxIDAeBgNVBAMTF1Zl
cm9rZXkgU2VjdXJlIEVtYWlsIEcyAhAH5JEPagNRXYDiRPdlc1vgMGYGCyqGSIb3DQEJEAILMVeg
VTBBMQswCQYDVQQGEwJBVTEQMA4GA1UEChMHVmVyb2tleTEgMB4GA1UEAxMXVmVyb2tleSBTZWN1
cmUgRW1haWwgRzICEAfkkQ9qA1FdgOJE92VzW+AwDQYJKoZIhvcNAQEBBQAEggIAHdtZFMM743TS
m1Cd4vhQKFuzzHtuSRDfheZ4UHkkF9pQQFMCq7Se5IeDnkwSycrJNQXopkk73BZ7XKQwkukzLNuV
533igSA8IrdgTzH+ImKfmClrN1SQonSgnS/5thDUFcn7k0dKO9e6LOuDYbjQa/r2eIArsYJznCTS
SkzK+mLUy5pSJep0qNBisaltwNIRdcjXQZpiCOlEkZRcxFsCIWLhTslE9PBpezE43NABP62PsNVE
BJE1db+OC16AmDQYnMXcTkl2IrQA8hlKd4BTkBY+kUfLekBEc+FzMxVtiVdVioK1pF1Ra9coG1/V
sQdJrGedMggjznPwXqayJZzPw1IONmc2Twd8eIyjbVFc12B/MEAJ5sHbbt+07u9Zgr7uGDEkbLFr
FOi/juxYvHRWZZQIvndaR+XmTnjBxjTDd0SyktZ+u8A25NzDvWgIvxqsayZea1g3aOEMCQLIVW7O
6Xcz7lKeIWqqcov0r7oQn9M3+28cKaRWmHnVOGbZaDQa1qqheRh0w2jSe8zHxTOszfRrve+bij5g
I+OGfW9jh1KN+axAZ/Lpy9p24Amtl0lTPhYR3Wh7lufX+SfyvvSRkaI8PzhQ/cwN3999qDcnhU0T
1DAvAnXy4rNRFGr+GbLuap0QwxCWZZixOdiYn0S7Va0YC763C1dXIKrrnoQnOdIAAAAAAAA=


--=-crBTpTo/dZrAlrKCg/Kg--


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 16:31:08 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 16:31:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872747.1283737 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY6II-0002vg-Hl; Wed, 15 Jan 2025 16:31:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872747.1283737; Wed, 15 Jan 2025 16:31:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY6II-0002vZ-Eq; Wed, 15 Jan 2025 16:31:02 +0000
Received: by outflank-mailman (input) for mailman id 872747;
 Wed, 15 Jan 2025 16:31:01 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=P4PG=UH=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tY6IH-0002vT-5b
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 16:31:01 +0000
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com
 [2a00:1450:4864:20::12f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1a7c5f2f-d35e-11ef-a0e1-8be0dac302b0;
 Wed, 15 Jan 2025 17:31:00 +0100 (CET)
Received: by mail-lf1-x12f.google.com with SMTP id
 2adb3069b0e04-54026562221so7149113e87.1
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 08:31:00 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5428becb15dsm2022132e87.238.2025.01.15.08.30.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 15 Jan 2025 08:30:58 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1a7c5f2f-d35e-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736958659; x=1737563459; darn=lists.xenproject.org;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=w0hDi3ZdVEye7prLvwhTXtSTlQyM6lv0uwFu2SMg7ww=;
        b=P0MkPG5svlEx/nbwOuvdS/jXv1RlcwSQ6gvDUpaqMvFUwskGSOmnr15sm9nAJ2lvYd
         Id6FJyVmALsI76bF5fyT0s2I5mu7t9P2LTMNuZSaRt4DrjHwPIkjO7yZ+E5hSVnI6KgT
         y7Y531hM6MVnz5th6zSyimkZgW7/s1C+sOR7FUM5H24B5b5TkxXyw+uGpQqPO1KAMWDS
         i+29CRA6l0JHUz2sderSDufWTMFPkR/8E+ClZgVwrLrbZK16uyttcVDnsYCjCFuOXaqR
         /O2No0/vfd8rD0aPTHUB1A8jWZNBIHhMR8cimEUkrv+JKre2/wyMyIve04lZL3x+FUNg
         8FBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736958659; x=1737563459;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=w0hDi3ZdVEye7prLvwhTXtSTlQyM6lv0uwFu2SMg7ww=;
        b=bB+faOzNgZwfrrHmbOkzdZkNzmMkTr2fYuoyzZOddc7gygS350hvPODJfwhrQGB2R+
         C9vJ6LS7mQXQge9tdRBXm7V+tuQov0jAsMrqB+hErneeBbIVlH5D4unYqERRoYMWOtSx
         edohCGU44tuhgv+28WF+H6gWIIlGU/E/tbEj8rrA6PSpni4si1bBZnOBsDzdbvEXKqic
         7zY4c2w3r/mnwb6CB/eNIt9BTMnEAScAIc5Q7a8JoGhQZLQixNdgj3izY9jP2XpgObxP
         4Ia7ivcylQVlwc6ZcfLXiHPMNAVN552pRxDzPQ6BDKfOI2KNWMzvuH0KmzCU0Z5fW4t5
         OVuw==
X-Forwarded-Encrypted: i=1; AJvYcCXPT2oIuKB5qHuYhAEyDsHVZkNlLV3gE02M+sfaMQrYT8Z0UKZg4MPwVhNfDhwftZPa2HB9ZuSXCqc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzGw7xlQjXD9cISluayyY1mdgROoJoAx4rps+CGU3SPew9uzAx7
	TR4NQOQuTrZlLEMy+3Gh5Pel3f+nhxFkStVxKqRHVLls0zsopw3C
X-Gm-Gg: ASbGncvtJ1vO2PDICVMJQOfh93fM8Dy55NJKy+JOH3DHlUDSg+QjFdc93ERREGvgYAx
	pPUdlzipGgypA40RUczZYEqRYOWP63MS0NjaAcobmWzGIYc9t9GzR5pBxmCZyK65pFW4ydfOYEO
	RPUQW4BLviCPBgtRtXpDKYpACAYuAtj+nFZw9dkonMrQULH1hcv9evTk2jgw+iWFTDREu/txlWS
	hqJqsnt3qLaaW+GkmFjQsJih0ne71W2UrHpYLnP7M8cdzDJeLfrBteaiXtL0lqiSg4DqQ==
X-Google-Smtp-Source: AGHT+IHqozlGT7lRatYG/bFCqt5LMNZZ3aQleXcw/cpbHBKijQLeRzTlMzhNdZa156V1ZZj+PMgB1w==
X-Received: by 2002:a05:6512:4020:b0:542:9987:6ead with SMTP id 2adb3069b0e04-54299877201mr5024807e87.5.1736958658596;
        Wed, 15 Jan 2025 08:30:58 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------Ci2H156EfJ7OyKE0RBG3P315"
Message-ID: <2f1432e6-0d27-48fd-b034-475284f14233@gmail.com>
Date: Wed, 15 Jan 2025 17:30:57 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] riscv: Add initial Xen guest support for RISC-V
To: Stefano Stabellini <sstabellini@kernel.org>,
 Milan Djokic <milandjokic1995@gmail.com>
Cc: linux-riscv@lists.infradead.org, paul.walmsley@sifive.com,
 palmer@dabbelt.com, aou@eecs.berkeley.edu, jgross@suse.com,
 oleksandr_tyshchenko@epam.com, Slavisa.Petrovic@rt-rk.com,
 Milan.Djokic@rt-rk.com, rafael.j.wysocki@intel.com,
 sunilvl@ventanamicro.com, takakura@valinux.co.jp,
 linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
 iommu@lists.linux.dev
References: <e4a649a7fdfc8fcf5f48a0bc4e76e5d546078083.1736868605.git.Slavisa.Petrovic@rt-rk.com>
 <alpine.DEB.2.22.394.2501141554170.2684657@ubuntu-linux-20-04-desktop>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <alpine.DEB.2.22.394.2501141554170.2684657@ubuntu-linux-20-04-desktop>

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

Hi Stefano,

On 1/15/25 1:01 AM, Stefano Stabellini wrote:
> +Oleksii
>
> On Tue, 14 Jan 2025, Milan Djokic wrote:
>> From: Slavisa Petrovic<Slavisa.Petrovic@rt-rk.com>
>>
>> This patch introduces initial support for running RISC-V as a Xen guest.
>> It provides the necessary infrastructure and stubs for Xen-specific
>> operations. Key changes include:
>>
>> - Modifications to the RISC-V kernel to integrate Xen-specific hypercalls
>>    and interfaces, with function implementations stubbed for future work.
>> - Introduction of Xen-specific headers for RISC-V, including event
>>    handling, hypervisor interaction, and page management. Functions are
>>    defined but not yet implemented.
>> - Stub implementations for memory management, grant tables, and context
>>    switching in the Xen environment, allowing further development and
>>    integration.
>>
>> Signed-off-by: Milan Djokic<Milan.Djokic@rt-rk.com>
>> Signed-off-by: Slavisa Petrovic<Slavisa.Petrovic@rt-rk.com>
> Hi Milan, Slavisa,
>
> Thank you very much for your contribution! Which Xen tree are you using
> for development?

They are using [1] and have separate branches on top of latest. So we are in
sync. Also, if you are interested we have created a task/epics for this feature in
[1] so you could also check there some details:
1.https://gitlab.com/groups/xen-project/people/olkur/-/epics/5
2.https://gitlab.com/xen-project/people/olkur/xen/-/issues/12

>   I am asking because RISC-V support in Xen is still in
> the process of being upstreamed, and [1] is the tree that consolidates
> all patches currently on the to-be-upstreamed list.
>
> While the specific Xen tree you are using is not particularly important
> at this stage, and using [1] is not a requirement, I am asking because
> it is essential to align on the hypervisor ABI, especially regarding any
> details that have not yet been upstreamed. Specifically, is there
> anything in this patch series that relies on features not yet upstream
> in Xen?

There are few features but some things which are Rt-Tk's branch in [1] could go
without waiting for these features to be upstreamed.

Thanks.

~ Oleksii

>
> [1]https://gitlab.com/xen-project/people/olkur/xen/-/tree/latest?ref_type=heads
--------------Ci2H156EfJ7OyKE0RBG3P315
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <pre>Hi Stefano,
</pre>
    <div class="moz-cite-prefix">On 1/15/25 1:01 AM, Stefano Stabellini
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:alpine.DEB.2.22.394.2501141554170.2684657@ubuntu-linux-20-04-desktop">
      <pre wrap="" class="moz-quote-pre">+Oleksii

On Tue, 14 Jan 2025, Milan Djokic wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">From: Slavisa Petrovic <a class="moz-txt-link-rfc2396E" href="mailto:Slavisa.Petrovic@rt-rk.com">&lt;Slavisa.Petrovic@rt-rk.com&gt;</a>

This patch introduces initial support for running RISC-V as a Xen guest.
It provides the necessary infrastructure and stubs for Xen-specific
operations. Key changes include:

- Modifications to the RISC-V kernel to integrate Xen-specific hypercalls
  and interfaces, with function implementations stubbed for future work.
- Introduction of Xen-specific headers for RISC-V, including event
  handling, hypervisor interaction, and page management. Functions are
  defined but not yet implemented.
- Stub implementations for memory management, grant tables, and context
  switching in the Xen environment, allowing further development and
  integration.

Signed-off-by: Milan Djokic <a class="moz-txt-link-rfc2396E" href="mailto:Milan.Djokic@rt-rk.com">&lt;Milan.Djokic@rt-rk.com&gt;</a>
Signed-off-by: Slavisa Petrovic <a class="moz-txt-link-rfc2396E" href="mailto:Slavisa.Petrovic@rt-rk.com">&lt;Slavisa.Petrovic@rt-rk.com&gt;</a>
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
Hi Milan, Slavisa,

Thank you very much for your contribution! Which Xen tree are you using
for development?</pre>
    </blockquote>
    <pre>They are using [1] and have separate branches on top of latest. So we are in
sync. Also, if you are interested we have created a task/epics for this feature in
[1] so you could also check there some details:
1. <a class="moz-txt-link-freetext" href="https://gitlab.com/groups/xen-project/people/olkur/-/epics/5">https://gitlab.com/groups/xen-project/people/olkur/-/epics/5</a>
2. <a class="moz-txt-link-freetext" href="https://gitlab.com/xen-project/people/olkur/xen/-/issues/12">https://gitlab.com/xen-project/people/olkur/xen/-/issues/12</a>

</pre>
    <blockquote type="cite"
cite="mid:alpine.DEB.2.22.394.2501141554170.2684657@ubuntu-linux-20-04-desktop">
      <pre wrap="" class="moz-quote-pre"> I am asking because RISC-V support in Xen is still in
the process of being upstreamed, and [1] is the tree that consolidates
all patches currently on the to-be-upstreamed list.  

While the specific Xen tree you are using is not particularly important
at this stage, and using [1] is not a requirement, I am asking because
it is essential to align on the hypervisor ABI, especially regarding any
details that have not yet been upstreamed. Specifically, is there
anything in this patch series that relies on features not yet upstream
in Xen?  </pre>
    </blockquote>
    <pre>There are few features but some things which are Rt-Tk's branch in [1] could go
without waiting for these features to be upstreamed.

Thanks.

~ Oleksii
</pre>
    <blockquote type="cite"
cite="mid:alpine.DEB.2.22.394.2501141554170.2684657@ubuntu-linux-20-04-desktop">
      <pre wrap="" class="moz-quote-pre">

[1] <a class="moz-txt-link-freetext" href="https://gitlab.com/xen-project/people/olkur/xen/-/tree/latest?ref_type=heads">https://gitlab.com/xen-project/people/olkur/xen/-/tree/latest?ref_type=heads</a>
</pre>
    </blockquote>
  </body>
</html>

--------------Ci2H156EfJ7OyKE0RBG3P315--


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 16:35:51 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 16:35:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872759.1283761 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY6Mw-0003o2-Pa; Wed, 15 Jan 2025 16:35:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872759.1283761; Wed, 15 Jan 2025 16:35:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY6Mw-0003mO-Kc; Wed, 15 Jan 2025 16:35:50 +0000
Received: by outflank-mailman (input) for mailman id 872759;
 Wed, 15 Jan 2025 16:35: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
 <SRS0=mU8/=UH=desiato.srs.infradead.org=BATV+7322ae3fcc6f32da564c+7815+infradead.org+dwmw2@srs-se1.protection.inumbo.net>)
 id 1tY6Mu-0003VS-Cf
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 16:35:50 +0000
Received: from desiato.infradead.org (desiato.infradead.org
 [2001:8b0:10b:1:d65d:64ff:fe57:4e05])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c5f8f984-d35e-11ef-a0e1-8be0dac302b0;
 Wed, 15 Jan 2025 17:35:47 +0100 (CET)
Received: from [2001:8b0:10b:1::ebe] (helo=i7.infradead.org)
 by desiato.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux))
 id 1tY6Mr-0000000Atae-15pM; Wed, 15 Jan 2025 16:35:45 +0000
Received: from dwoodhou by i7.infradead.org with local (Exim 4.98 #2 (Red Hat
 Linux)) id 1tY6Mp-00000001Hhg-3xaR; Wed, 15 Jan 2025 16:35:43 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
X-Inumbo-ID: c5f8f984-d35e-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding:
	Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:
	To:From:Reply-To:Content-ID:Content-Description;
	bh=j2gaDkDHKbVHS9ffxI7464SULQ6IWC/ZhoSg1yVGsXA=; b=PeIQDQ2Os1lTg7OqknjIA7QozH
	r95h74GMusKTSGt5oYuE2CJm7MFHLsNnioMi5oraYSOUyq2eiNWLidPTDZPa06ES/C3TpOrK2P6H0
	cMJj25O2dCrELtMJGXa/49tD/ukdrqsn6ntY7FPX11zBM82g4cFYj+7k5yhHbYvjqvCBCu8cv2dTN
	QDh77Wr1fACIYff6jDWxXVqAiQ0ggtVbtTTppfk8JqUbibrB2RxwMJS7f/1cYpULjjelQyRG4mSBt
	TwBg3LhhWI1eN1HgeXj/o0hY84N+Ply2TwazP6gH5e5Uyv4X0vIOEMruvEIe8mgM2vx1La6qFTCKX
	tUPDR49A==;
From: David Woodhouse <dwmw2@infradead.org>
To: qemu-devel@nongnu.org,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Kevin Wolf <kwolf@redhat.com>,
	Hanna Reitz <hreitz@redhat.com>,
	=?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= <marcandre.lureau@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	xen-devel@lists.xenproject.org,
	qemu-block@nongnu.org
Subject: [PATCH v3 3/7] hw/xen: Use xs_node_read() from xs_node_vscanf()
Date: Wed, 15 Jan 2025 16:27:21 +0000
Message-ID: <20250115163542.291424-4-dwmw2@infradead.org>
X-Mailer: git-send-email 2.47.0
In-Reply-To: <20250115163542.291424-1-dwmw2@infradead.org>
References: <20250115163542.291424-1-dwmw2@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Sender: David Woodhouse <dwmw2@infradead.org>
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by desiato.infradead.org. See http://www.infradead.org/rpr.html

From: David Woodhouse <dwmw@amazon.co.uk>

Reduce some duplication.

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
---
 hw/xen/trace-events     |  1 -
 hw/xen/xen-bus-helper.c | 15 ++++++---------
 2 files changed, 6 insertions(+), 10 deletions(-)

diff --git a/hw/xen/trace-events b/hw/xen/trace-events
index 461dee7b23..b67942d07b 100644
--- a/hw/xen/trace-events
+++ b/hw/xen/trace-events
@@ -38,7 +38,6 @@ xen_device_remove_watch(const char *type, char *name, const char *node, const ch
 xs_node_create(const char *node) "%s"
 xs_node_destroy(const char *node) "%s"
 xs_node_vprintf(char *path, char *value) "%s %s"
-xs_node_vscanf(char *path, char *value) "%s %s"
 xs_node_read(const char *path, const char *value) "%s %s"
 xs_node_watch(char *path) "%s"
 xs_node_unwatch(char *path) "%s"
diff --git a/hw/xen/xen-bus-helper.c b/hw/xen/xen-bus-helper.c
index 22fd2f6c1a..288fad422b 100644
--- a/hw/xen/xen-bus-helper.c
+++ b/hw/xen/xen-bus-helper.c
@@ -105,25 +105,22 @@ int xs_node_vscanf(struct qemu_xs_handle *h,  xs_transaction_t tid,
                    const char *node, const char *key, Error **errp,
                    const char *fmt, va_list ap)
 {
-    char *path, *value;
+    char *value;
     int rc;
 
-    path = (strlen(node) != 0) ? g_strdup_printf("%s/%s", node, key) :
-        g_strdup(key);
-    value = qemu_xen_xs_read(h, tid, path, NULL);
-
-    trace_xs_node_vscanf(path, value);
+    if (node && strlen(node) != 0) {
+        value = xs_node_read(h, tid, NULL, errp, "%s/%s", node, key);
+    } else {
+        value = xs_node_read(h, tid, NULL, errp, "%s", key);
+    }
 
     if (value) {
         rc = vsscanf(value, fmt, ap);
     } else {
-        error_setg_errno(errp, errno, "failed to read from '%s'",
-                         path);
         rc = EOF;
     }
 
     free(value);
-    g_free(path);
 
     return rc;
 }
-- 
2.47.0



From xen-devel-bounces@lists.xenproject.org Wed Jan 15 16:35:51 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 16:35:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872757.1283746 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY6Mv-0003Vf-1f; Wed, 15 Jan 2025 16:35:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872757.1283746; Wed, 15 Jan 2025 16:35:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY6Mu-0003VY-VH; Wed, 15 Jan 2025 16:35:48 +0000
Received: by outflank-mailman (input) for mailman id 872757;
 Wed, 15 Jan 2025 16:35: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
 <SRS0=rWPo=UH=casper.srs.infradead.org=BATV+fb641630334796bb9467+7815+infradead.org+dwmw2@srs-se1.protection.inumbo.net>)
 id 1tY6Mt-0003VS-Mx
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 16:35:47 +0000
Received: from casper.infradead.org (casper.infradead.org
 [2001:8b0:10b:1236::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c4ca686c-d35e-11ef-a0e1-8be0dac302b0;
 Wed, 15 Jan 2025 17:35:46 +0100 (CET)
Received: from [2001:8b0:10b:1::ebe] (helo=i7.infradead.org)
 by casper.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux))
 id 1tY6Mq-0000000GF6c-1V3F; Wed, 15 Jan 2025 16:35:44 +0000
Received: from dwoodhou by i7.infradead.org with local (Exim 4.98 #2 (Red Hat
 Linux)) id 1tY6Mq-00000001Hhz-0SV5; Wed, 15 Jan 2025 16:35:44 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
X-Inumbo-ID: c4ca686c-d35e-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=Sender:Content-Transfer-Encoding:
	Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:
	To:From:Reply-To:Content-ID:Content-Description;
	bh=9YnMqT9L5zpcIdMPGD+T5rZV+9M0PECfN24dS3f5adI=; b=HBCwutm0sGscO7FRumhreu04mi
	eCz0n7Ffb2F8brtPqDvF8E7RDAbGm1ok0tZslQVFmdeTfMtnqdYSuPx2VHbzK3mlJgy7dCI7gF9l8
	J886BsSw/7sDOVHHH1+N/nDL0vISpjdui07wy6kzL62PW1sx9TyIYJ6H0pGGtIF00TRzw33B9LiUs
	JobEo03D0Wdls0BhRwE/Px7ABwcKZ0hSsSLNm/r9IimyjscHWgCMV91j0hEq4EffYt5no5ryM6sM9
	/wC2w/GcThMYonDt5+CjNzqTMAyX4LtCFAAa5eKF0ISogQB+x8haCB/B65629/kFvZ3OKWHhJSPnz
	ZCepR7/w==;
From: David Woodhouse <dwmw2@infradead.org>
To: qemu-devel@nongnu.org,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Kevin Wolf <kwolf@redhat.com>,
	Hanna Reitz <hreitz@redhat.com>,
	=?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= <marcandre.lureau@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	xen-devel@lists.xenproject.org,
	qemu-block@nongnu.org
Subject: [PATCH v3 6/7] hw/xen: Use xs_node_read() from xenstore_read_str() instead of open-coding it
Date: Wed, 15 Jan 2025 16:27:24 +0000
Message-ID: <20250115163542.291424-7-dwmw2@infradead.org>
X-Mailer: git-send-email 2.47.0
In-Reply-To: <20250115163542.291424-1-dwmw2@infradead.org>
References: <20250115163542.291424-1-dwmw2@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Sender: David Woodhouse <dwmw2@infradead.org>
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html

From: David Woodhouse <dwmw@amazon.co.uk>

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
---
 hw/xen/xen_pvdev.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/hw/xen/xen_pvdev.c b/hw/xen/xen_pvdev.c
index c5ad71e8dc..c9143ba259 100644
--- a/hw/xen/xen_pvdev.c
+++ b/hw/xen/xen_pvdev.c
@@ -22,6 +22,7 @@
 #include "qemu/main-loop.h"
 #include "hw/qdev-core.h"
 #include "hw/xen/xen-legacy-backend.h"
+#include "hw/xen/xen-bus-helper.h"
 #include "hw/xen/xen_pvdev.h"
 
 /* private */
@@ -81,12 +82,9 @@ int xenstore_write_str(const char *base, const char *node, const char *val)
 
 char *xenstore_read_str(const char *base, const char *node)
 {
-    char abspath[XEN_BUFSIZE];
-    unsigned int len;
     char *str, *ret = NULL;
 
-    snprintf(abspath, sizeof(abspath), "%s/%s", base, node);
-    str = qemu_xen_xs_read(xenstore, 0, abspath, &len);
+    str = xs_node_read(xenstore, 0, NULL, NULL, "%s/%s", base, node);
     if (str != NULL) {
         /* move to qemu-allocated memory to make sure
          * callers can safely g_free() stuff. */
-- 
2.47.0



From xen-devel-bounces@lists.xenproject.org Wed Jan 15 16:35:51 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 16:35:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872758.1283757 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY6Mw-0003kD-Dx; Wed, 15 Jan 2025 16:35:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872758.1283757; Wed, 15 Jan 2025 16:35:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY6Mw-0003k6-9E; Wed, 15 Jan 2025 16:35:50 +0000
Received: by outflank-mailman (input) for mailman id 872758;
 Wed, 15 Jan 2025 16:35: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
 <SRS0=rWPo=UH=casper.srs.infradead.org=BATV+fb641630334796bb9467+7815+infradead.org+dwmw2@srs-se1.protection.inumbo.net>)
 id 1tY6Mv-0003cf-LS
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 16:35:49 +0000
Received: from casper.infradead.org (casper.infradead.org
 [2001:8b0:10b:1236::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c4c7f037-d35e-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 17:35:45 +0100 (CET)
Received: from [2001:8b0:10b:1::ebe] (helo=i7.infradead.org)
 by casper.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux))
 id 1tY6Mq-0000000GF6a-1Lq6; Wed, 15 Jan 2025 16:35:44 +0000
Received: from dwoodhou by i7.infradead.org with local (Exim 4.98 #2 (Red Hat
 Linux)) id 1tY6Mq-00000001Hhs-0FQz; Wed, 15 Jan 2025 16:35:44 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
X-Inumbo-ID: c4c7f037-d35e-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=Sender:Content-Transfer-Encoding:
	Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:
	To:From:Reply-To:Content-ID:Content-Description;
	bh=ZBKlQ7iGXowmo3aHS0zEEFjY8wis7AgQV7Ky19BXiPo=; b=v+j+b5C54V/5qtSTWFitM1LOig
	VUP6QQ086swlIfI7NeyYM79sSX2bf/bFUNF2uaTdGfY8Mwawe4vZ0KQHd2uxkncVpxK2BQUM8QEbi
	YCLpad1+7YpceLqwSu4nr2ZToIEZP+BddtKkOrHcI5exDsaqYW32UIettmlB1L6ur+IqCIxSryuQZ
	EJ3NG7b4fkOk2gX8IGEXM6niJv1pYM8G08XFPr3ZbG+OtmFmgRqYTbc7VF/h+NdLbyrCBQ7XdVJ+A
	islX7Wlf+9QnEVZVfsYszl4RPcVJC65twfweZgp4rDWyB+dph8iS/NFULAvIoBLy9hnhiCAxUBBZs
	jZrkB0GQ==;
From: David Woodhouse <dwmw2@infradead.org>
To: qemu-devel@nongnu.org,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Kevin Wolf <kwolf@redhat.com>,
	Hanna Reitz <hreitz@redhat.com>,
	=?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= <marcandre.lureau@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	xen-devel@lists.xenproject.org,
	qemu-block@nongnu.org
Subject: [PATCH v3 5/7] hw/xen: Use xs_node_read() from xen_netdev_get_name()
Date: Wed, 15 Jan 2025 16:27:23 +0000
Message-ID: <20250115163542.291424-6-dwmw2@infradead.org>
X-Mailer: git-send-email 2.47.0
In-Reply-To: <20250115163542.291424-1-dwmw2@infradead.org>
References: <20250115163542.291424-1-dwmw2@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Sender: David Woodhouse <dwmw2@infradead.org>
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html

From: David Woodhouse <dwmw@amazon.co.uk>

Now that xs_node_read() can construct a node path, no need to open-code it.

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
---
 hw/net/xen_nic.c | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/hw/net/xen_nic.c b/hw/net/xen_nic.c
index 97ebd9fa30..5410039490 100644
--- a/hw/net/xen_nic.c
+++ b/hw/net/xen_nic.c
@@ -510,23 +510,22 @@ static char *xen_netdev_get_name(XenDevice *xendev, Error **errp)
 
     if (netdev->dev == -1) {
         XenBus *xenbus = XEN_BUS(qdev_get_parent_bus(DEVICE(xendev)));
-        char fe_path[XENSTORE_ABS_PATH_MAX + 1];
         int idx = (xen_mode == XEN_EMULATE) ? 0 : 1;
+        Error *local_err = NULL;
         char *value;
 
         /* Theoretically we could go up to INT_MAX here but that's overkill */
         while (idx < 100) {
-            snprintf(fe_path, sizeof(fe_path),
-                     "/local/domain/%u/device/vif/%u",
-                     xendev->frontend_id, idx);
-            value = qemu_xen_xs_read(xenbus->xsh, XBT_NULL, fe_path, NULL);
+            value = xs_node_read(xenbus->xsh, XBT_NULL, NULL, &local_err,
+                                 "/local/domain/%u/device/vif/%u",
+                                 xendev->frontend_id, idx);
             if (!value) {
                 if (errno == ENOENT) {
                     netdev->dev = idx;
+                    error_free(local_err);
                     goto found;
                 }
-                error_setg(errp, "cannot read %s: %s", fe_path,
-                           strerror(errno));
+                error_propagate(errp, local_err);
                 return NULL;
             }
             free(value);
-- 
2.47.0



From xen-devel-bounces@lists.xenproject.org Wed Jan 15 16:35:52 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 16:35:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872760.1283777 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY6Mx-0004EE-WE; Wed, 15 Jan 2025 16:35:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872760.1283777; Wed, 15 Jan 2025 16:35:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY6Mx-0004DL-T2; Wed, 15 Jan 2025 16:35:51 +0000
Received: by outflank-mailman (input) for mailman id 872760;
 Wed, 15 Jan 2025 16:35: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
 <SRS0=mU8/=UH=desiato.srs.infradead.org=BATV+7322ae3fcc6f32da564c+7815+infradead.org+dwmw2@srs-se1.protection.inumbo.net>)
 id 1tY6Mw-0003VS-81
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 16:35:50 +0000
Received: from desiato.infradead.org (desiato.infradead.org
 [2001:8b0:10b:1:d65d:64ff:fe57:4e05])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c5f91422-d35e-11ef-a0e1-8be0dac302b0;
 Wed, 15 Jan 2025 17:35:47 +0100 (CET)
Received: from [2001:8b0:10b:1::ebe] (helo=i7.infradead.org)
 by desiato.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux))
 id 1tY6Mr-0000000Ataf-15Qx; Wed, 15 Jan 2025 16:35:45 +0000
Received: from dwoodhou by i7.infradead.org with local (Exim 4.98 #2 (Red Hat
 Linux)) id 1tY6Mq-00000001Hi4-0h5i; Wed, 15 Jan 2025 16:35:44 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
X-Inumbo-ID: c5f91422-d35e-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding:
	MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:
	Reply-To:Content-Type:Content-ID:Content-Description;
	bh=1aNikVIiBjTeQOc5N3unG1HCtdVZT5mT/c2k8TAmHbo=; b=g7RIvTdwfF6e4rW5vzi8S7NKNH
	XHUKR9LWw4GRosTHdZgCh+g/KQs3mO9W1vMr5526JtvQXPCRQJ24U09J3573Z6Yb509OZNq9rV/DW
	SQr2ejpnTxb4jWrBPDBwZlqtN2nSyAGH3syIaN0jptlD7ROWmrYOv3hKC5weTQIMWbhB9i0eaivqK
	wQ1uEpf9xHO5kNd04T2ZiUw1eZdqCbH5L/AiN8UOhPSKj8qt9UFd9hYSHNLvTM2MuoFGAtnD1Nr+n
	lJAdLxQdNiGd6MDj64GxGPGlAoGOypw1w1xyS/EUl1zKii6goQ1qG06Ljnur8MWHk8ZbJ/EfBapOl
	iT7Y85ZA==;
From: David Woodhouse <dwmw2@infradead.org>
To: qemu-devel@nongnu.org,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Kevin Wolf <kwolf@redhat.com>,
	Hanna Reitz <hreitz@redhat.com>,
	=?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= <marcandre.lureau@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	xen-devel@lists.xenproject.org,
	qemu-block@nongnu.org
Subject: [PATCH v3 7/7] hw/xen: Fix errp handling in xen_console
Date: Wed, 15 Jan 2025 16:27:25 +0000
Message-ID: <20250115163542.291424-8-dwmw2@infradead.org>
X-Mailer: git-send-email 2.47.0
In-Reply-To: <20250115163542.291424-1-dwmw2@infradead.org>
References: <20250115163542.291424-1-dwmw2@infradead.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: David Woodhouse <dwmw2@infradead.org>
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by desiato.infradead.org. See http://www.infradead.org/rpr.html

From: David Woodhouse <dwmw@amazon.co.uk>

When attempting to read the 'output' node, interpret any error *other*
than ENOENT as a fatal error. For ENOENT, fall back to serial_hd() to
find a character device, or create a null device.

Do not attempt to prepend to errp when serial_hd() fails; the error
isn't relevant (and prior to this change, wasn't set anyway).

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
 hw/char/xen_console.c | 34 +++++++++++++++++++++-------------
 1 file changed, 21 insertions(+), 13 deletions(-)

diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
index e61902461b..9e7f6da343 100644
--- a/hw/char/xen_console.c
+++ b/hw/char/xen_console.c
@@ -569,7 +569,7 @@ static void xen_console_device_create(XenBackendInstance *backend,
 
     snprintf(label, sizeof(label), "xencons%ld", number);
 
-    output = xs_node_read(xsh, XBT_NULL, NULL, NULL, "%s/%s", fe, "output");
+    output = xs_node_read(xsh, XBT_NULL, NULL, errp, "%s/%s", fe, "output");
     if (output) {
         /*
          * FIXME: sure we want to support implicit
@@ -581,19 +581,27 @@ static void xen_console_device_create(XenBackendInstance *backend,
                        output);
             goto fail;
         }
-    } else if (number) {
-        cd = serial_hd(number);
-        if (!cd) {
-            error_prepend(errp, "console: No serial device #%ld found: ",
-                          number);
-            goto fail;
-        }
+    } else if (errno != ENOENT) {
+        error_prepend(errp, "console: No valid chardev found: ");
+        goto fail;
     } else {
-        /* No 'output' node on primary console: use null. */
-        cd = qemu_chr_new(label, "null", NULL);
-        if (!cd) {
-            error_setg(errp, "console: failed to create null device");
-            goto fail;
+        if (errp) {
+            error_free(*errp);
+        }
+        if (number) {
+            cd = serial_hd(number);
+            if (!cd) {
+                error_setg(errp, "console: No serial device #%ld found: ",
+                           number);
+                goto fail;
+            }
+        } else {
+            /* No 'output' node on primary console: use null. */
+            cd = qemu_chr_new(label, "null", NULL);
+            if (!cd) {
+                error_setg(errp, "console: failed to create null device");
+                goto fail;
+            }
         }
     }
 
-- 
2.47.0



From xen-devel-bounces@lists.xenproject.org Wed Jan 15 16:35:52 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 16:35:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872761.1283782 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY6My-0004Gp-B1; Wed, 15 Jan 2025 16:35:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872761.1283782; Wed, 15 Jan 2025 16:35:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY6My-0004Fb-3f; Wed, 15 Jan 2025 16:35:52 +0000
Received: by outflank-mailman (input) for mailman id 872761;
 Wed, 15 Jan 2025 16:35:50 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=rWPo=UH=casper.srs.infradead.org=BATV+fb641630334796bb9467+7815+infradead.org+dwmw2@srs-se1.protection.inumbo.net>)
 id 1tY6Mw-0003cf-BM
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 16:35:50 +0000
Received: from casper.infradead.org (casper.infradead.org
 [2001:8b0:10b:1236::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c4c9988f-d35e-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 17:35:45 +0100 (CET)
Received: from [2001:8b0:10b:1::ebe] (helo=i7.infradead.org)
 by casper.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux))
 id 1tY6Mq-0000000GF6F-0HXR; Wed, 15 Jan 2025 16:35:44 +0000
Received: from dwoodhou by i7.infradead.org with local (Exim 4.98 #2 (Red Hat
 Linux)) id 1tY6Mp-00000001HhI-3F67; Wed, 15 Jan 2025 16:35:43 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
X-Inumbo-ID: c4c9988f-d35e-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=Sender:Content-Transfer-Encoding:
	Content-Type:MIME-Version:Message-ID:Date:Subject:Cc:To:From:Reply-To:
	Content-ID:Content-Description:In-Reply-To:References;
	bh=rrBZA8lyQEOQWQ/8jP8VTP1JvBxjDjQmwbWIQpBZfxo=; b=bNgCieMNDffHCdWjm/68OAkXTG
	d5w+ofW/5y5gRlSK97lAC1R66Sg+L2TSKt30Vt0HN8TGF8l8ThTmrOYOR5YdWa8FJLXSwEx/p7+p1
	mdJUyZaRDzrbtOj01paIYHTzyYiqftFNDGQZie3ihQvnI8v8BEv+sb7c1JME9/etOAgBvD1lO1y7d
	+CxQKnbgM6P5aRh+Gl7jzfnnWkIUHpDOg8FYO1ySbUU2+sOd4YmD3otlB7IuxlIevQ+Z39rjP1LKP
	S5phfA9zv3PP2u+MrYdadmzCGy35rL1VR2fvUvulJxgUz2qYu4ah8uc6cIdzD/yh0iUix+aI38HXa
	j/my6YBQ==;
From: David Woodhouse <dwmw2@infradead.org>
To: qemu-devel@nongnu.org,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Kevin Wolf <kwolf@redhat.com>,
	Hanna Reitz <hreitz@redhat.com>,
	=?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= <marcandre.lureau@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	xen-devel@lists.xenproject.org,
	qemu-block@nongnu.org
Subject: [PATCH v3 1/7] xen: error handling and FreeBSD compatibility fixes
Date: Wed, 15 Jan 2025 16:27:18 +0000
Message-ID: <20250115163542.291424-1-dwmw2@infradead.org>
X-Mailer: git-send-email 2.47.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Sender: David Woodhouse <dwmw2@infradead.org>
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html

Add a new xs_node_read() helper function which constructs the node path 
using a printf format string, and use it where appropriate.

In particular, use it to eliminate the use of the %ms format specifier 
for scanf(), which doesn't exist in FreeBSD.

v3:
 • Further cleanups using xs_node_read().
 • Clean up errp handling for xen-console 'output' node.
 • Improve comment for xs_node_read().

v2:
 • Add xs_node_read() helper.
 • Also fix usage of %ms in xen-block.c

David Woodhouse (6):
      hw/xen: Add xs_node_read() helper function
      hw/xen: Use xs_node_read() from xs_node_vscanf()
      hw/xen: Use xs_node_read() from xen_console_get_name()
      hw/xen: Use xs_node_read() from xen_netdev_get_name()
      hw/xen: Use xs_node_read() from xenstore_read_str() instead of open-coding it
      hw/xen: Fix errp handling in xen_console

Roger Pau Monné (1):
      xen: do not use '%ms' scanf specifier

 hw/block/xen-block.c            |  3 ++-
 hw/char/xen_console.c           | 56 ++++++++++++++++++++++++-----------------
 hw/net/xen_nic.c                | 13 +++++-----
 hw/xen/trace-events             |  2 +-
 hw/xen/xen-bus-helper.c         | 37 ++++++++++++++++++++-------
 hw/xen/xen-bus.c                | 14 +++++++++--
 hw/xen/xen_pvdev.c              |  6 ++---
 include/hw/xen/xen-bus-helper.h |  9 +++++++
 include/hw/xen/xen-bus.h        |  1 +
 9 files changed, 94 insertions(+), 47 deletions(-)



From xen-devel-bounces@lists.xenproject.org Wed Jan 15 16:35:53 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 16:35:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872762.1283796 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY6Mz-0004es-HI; Wed, 15 Jan 2025 16:35:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872762.1283796; Wed, 15 Jan 2025 16:35:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY6Mz-0004dw-CN; Wed, 15 Jan 2025 16:35:53 +0000
Received: by outflank-mailman (input) for mailman id 872762;
 Wed, 15 Jan 2025 16:35:51 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=rWPo=UH=casper.srs.infradead.org=BATV+fb641630334796bb9467+7815+infradead.org+dwmw2@srs-se1.protection.inumbo.net>)
 id 1tY6Mx-0003cf-BN
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 16:35:51 +0000
Received: from casper.infradead.org (casper.infradead.org
 [2001:8b0:10b:1236::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c4c99897-d35e-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 17:35:45 +0100 (CET)
Received: from [2001:8b0:10b:1::ebe] (helo=i7.infradead.org)
 by casper.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux))
 id 1tY6Mq-0000000GF6P-148j; Wed, 15 Jan 2025 16:35:44 +0000
Received: from dwoodhou by i7.infradead.org with local (Exim 4.98 #2 (Red Hat
 Linux)) id 1tY6Mq-00000001Hhn-00TQ; Wed, 15 Jan 2025 16:35:44 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
X-Inumbo-ID: c4c99897-d35e-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=Sender:Content-Transfer-Encoding:
	Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:
	To:From:Reply-To:Content-ID:Content-Description;
	bh=9nRlgfR/HkbXdsVZN1RJ5s3wIYDMgIRx7AVyt9JqyRI=; b=EyF73ntA9nNRs2USmFs3VhSFpr
	jNl690oAvAmfPoM3d9Lc2BGc1l1/s1/SeknFPeuJTpxrf1A7JrWVzvlQVDsOj8a+dRPFzbNaLKfAO
	j2WHAFN3Nr8xuSB9VGGQDHCWq5KJ/qkkMZ2jVCLwxPvkJkUdNMMJeg7knUUa+/YPzo2+VwEESoAFK
	dNaXDRzPMj19LMHea3hONYRgsJN3CMHRQBl2M0zn8N29N77J4yU9eQbTo/7OQhdX7ZE6KAFTAofUj
	XtLavELYf7LC08zgEem/hTcCPhKKoUEEmBaZ3rZkt0vw8s9Tz8tyDcbsrOICPyDnOxtVeDiDXWNhn
	dMfyec3g==;
From: David Woodhouse <dwmw2@infradead.org>
To: qemu-devel@nongnu.org,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Kevin Wolf <kwolf@redhat.com>,
	Hanna Reitz <hreitz@redhat.com>,
	=?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= <marcandre.lureau@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	xen-devel@lists.xenproject.org,
	qemu-block@nongnu.org
Subject: [PATCH v3 4/7] hw/xen: Use xs_node_read() from xen_console_get_name()
Date: Wed, 15 Jan 2025 16:27:22 +0000
Message-ID: <20250115163542.291424-5-dwmw2@infradead.org>
X-Mailer: git-send-email 2.47.0
In-Reply-To: <20250115163542.291424-1-dwmw2@infradead.org>
References: <20250115163542.291424-1-dwmw2@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Sender: David Woodhouse <dwmw2@infradead.org>
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html

From: David Woodhouse <dwmw@amazon.co.uk>

Now that xs_node_read() can construct a node path, no need to open-code it.

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
---
 hw/char/xen_console.c | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
index cb39b21504..e61902461b 100644
--- a/hw/char/xen_console.c
+++ b/hw/char/xen_console.c
@@ -367,28 +367,28 @@ static char *xen_console_get_name(XenDevice *xendev, Error **errp)
 
     if (con->dev == -1) {
         XenBus *xenbus = XEN_BUS(qdev_get_parent_bus(DEVICE(xendev)));
-        char fe_path[XENSTORE_ABS_PATH_MAX + 1];
         int idx = (xen_mode == XEN_EMULATE) ? 0 : 1;
+        Error *local_err = NULL;
         char *value;
 
         /* Theoretically we could go up to INT_MAX here but that's overkill */
         while (idx < 100) {
             if (!idx) {
-                snprintf(fe_path, sizeof(fe_path),
-                         "/local/domain/%u/console", xendev->frontend_id);
+                value = xs_node_read(xenbus->xsh, XBT_NULL, NULL, &local_err,
+                                     "/local/domain/%u/console",
+                                     xendev->frontend_id);
             } else {
-                snprintf(fe_path, sizeof(fe_path),
-                         "/local/domain/%u/device/console/%u",
-                         xendev->frontend_id, idx);
+                value = xs_node_read(xenbus->xsh, XBT_NULL, NULL, &local_err,
+                                     "/local/domain/%u/device/console/%u",
+                                     xendev->frontend_id, idx);
             }
-            value = qemu_xen_xs_read(xenbus->xsh, XBT_NULL, fe_path, NULL);
             if (!value) {
                 if (errno == ENOENT) {
                     con->dev = idx;
+                    error_free(local_err);
                     goto found;
                 }
-                error_setg(errp, "cannot read %s: %s", fe_path,
-                           strerror(errno));
+                error_propagate(errp, local_err);
                 return NULL;
             }
             free(value);
-- 
2.47.0



From xen-devel-bounces@lists.xenproject.org Wed Jan 15 16:35:54 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 16:35:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872763.1283803 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY6N0-0004lK-1q; Wed, 15 Jan 2025 16:35:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872763.1283803; Wed, 15 Jan 2025 16:35:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY6Mz-0004k9-Oy; Wed, 15 Jan 2025 16:35:53 +0000
Received: by outflank-mailman (input) for mailman id 872763;
 Wed, 15 Jan 2025 16:35:52 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=rWPo=UH=casper.srs.infradead.org=BATV+fb641630334796bb9467+7815+infradead.org+dwmw2@srs-se1.protection.inumbo.net>)
 id 1tY6My-0003cf-BP
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 16:35:52 +0000
Received: from casper.infradead.org (casper.infradead.org
 [2001:8b0:10b:1236::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c4c93598-d35e-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 17:35:45 +0100 (CET)
Received: from [2001:8b0:10b:1::ebe] (helo=i7.infradead.org)
 by casper.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux))
 id 1tY6Mq-0000000GF6I-0fLC; Wed, 15 Jan 2025 16:35:44 +0000
Received: from dwoodhou by i7.infradead.org with local (Exim 4.98 #2 (Red Hat
 Linux)) id 1tY6Mp-00000001HhY-3icT; Wed, 15 Jan 2025 16:35:43 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
X-Inumbo-ID: c4c93598-d35e-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=Sender:Content-Transfer-Encoding:
	Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:
	To:From:Reply-To:Content-ID:Content-Description;
	bh=SDBjrinVc9mPM0Vf+Qh/Z25AxdVrPNHQdK2BMqfVAvY=; b=HSSPQup0WPxXmqL6G1JSX0Iytw
	Qg6gnJ5oiwf1F4ohSrXaK555HbOv4Q+jhfGx4nGwy6l3+9xlDjNgYBI7q6u9VsG9tdTQdpPfFEC67
	y/lglPtrF1E5x3TzUFrqD/ovG8dBbQGiJn1Gswlrd9HGMbzAXrxj9e1Y8Ft5JRaODxrKnYGODIs2s
	vL0OprNhQjzLYJ2HTQPpqO66PdeQjPxch8XXLVsky49x1fDl3HveLZb199nrUyls/69joB0nuhJ8+
	zweaKoqxodp0kOS06KvAfWVjKZPyoQCs8QThNHxBsL0qEu7Mh8XdNaGqkBMfR/bCTS3h/ef4jZ2RE
	tyy/w9dA==;
From: David Woodhouse <dwmw2@infradead.org>
To: qemu-devel@nongnu.org,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Kevin Wolf <kwolf@redhat.com>,
	Hanna Reitz <hreitz@redhat.com>,
	=?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= <marcandre.lureau@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	xen-devel@lists.xenproject.org,
	qemu-block@nongnu.org
Subject: [PATCH v3 2/7] xen: do not use '%ms' scanf specifier
Date: Wed, 15 Jan 2025 16:27:20 +0000
Message-ID: <20250115163542.291424-3-dwmw2@infradead.org>
X-Mailer: git-send-email 2.47.0
In-Reply-To: <20250115163542.291424-1-dwmw2@infradead.org>
References: <20250115163542.291424-1-dwmw2@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Sender: David Woodhouse <dwmw2@infradead.org>
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html

From: Roger Pau Monne <roger.pau@citrix.com>

The 'm' parameter used to request auto-allocation of the destination variable
is not supported on FreeBSD, and as such leads to failures to parse.

What's more, the current usage of '%ms' with xs_node_scanf() is pointless, as
it just leads to a double allocation of the same string.  Instead use
xs_node_read() to read the whole xenstore node.

Fixes: a783f8ad4ec9 ('xen: add a mechanism to automatically create XenDevice-s...')
Fixes: 9b7737469080 ('hw/xen: update Xen console to XenDevice model')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
 hw/block/xen-block.c     |  3 ++-
 hw/char/xen_console.c    |  6 ++++--
 hw/xen/xen-bus.c         | 14 ++++++++++++--
 include/hw/xen/xen-bus.h |  1 +
 4 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/hw/block/xen-block.c b/hw/block/xen-block.c
index 306d38927c..034a18b70e 100644
--- a/hw/block/xen-block.c
+++ b/hw/block/xen-block.c
@@ -239,7 +239,8 @@ static void xen_block_connect(XenDevice *xendev, Error **errp)
         return;
     }
 
-    if (xen_device_frontend_scanf(xendev, "protocol", "%ms", &str) != 1) {
+    str = xen_device_frontend_read(xendev, "protocol");
+    if (!str) {
         /* x86 defaults to the 32-bit protocol even for 64-bit guests. */
         if (object_dynamic_cast(OBJECT(qdev_get_machine()), "x86-machine")) {
             protocol = BLKIF_PROTOCOL_X86_32;
diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
index ef0c2912ef..cb39b21504 100644
--- a/hw/char/xen_console.c
+++ b/hw/char/xen_console.c
@@ -550,7 +550,8 @@ static void xen_console_device_create(XenBackendInstance *backend,
         goto fail;
     }
 
-    if (xs_node_scanf(xsh, XBT_NULL, fe, "type", errp, "%ms", &type) != 1) {
+    type = xs_node_read(xsh, XBT_NULL, NULL, errp, "%s/%s", fe, "type");
+    if (!type) {
         error_prepend(errp, "failed to read console device type: ");
         goto fail;
     }
@@ -568,7 +569,8 @@ static void xen_console_device_create(XenBackendInstance *backend,
 
     snprintf(label, sizeof(label), "xencons%ld", number);
 
-    if (xs_node_scanf(xsh, XBT_NULL, fe, "output", NULL, "%ms", &output) == 1) {
+    output = xs_node_read(xsh, XBT_NULL, NULL, NULL, "%s/%s", fe, "output");
+    if (output) {
         /*
          * FIXME: sure we want to support implicit
          * muxed monitors here?
diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c
index adfc4efad0..85b92cded4 100644
--- a/hw/xen/xen-bus.c
+++ b/hw/xen/xen-bus.c
@@ -156,8 +156,8 @@ again:
             !strcmp(key[i], "hotplug-status"))
             continue;
 
-        if (xs_node_scanf(xenbus->xsh, tid, path, key[i], NULL, "%ms",
-                          &val) == 1) {
+        val = xs_node_read(xenbus->xsh, tid, NULL, NULL, "%s/%s", path, key[i]);
+        if (val) {
             qdict_put_str(opts, key[i], val);
             free(val);
         }
@@ -650,6 +650,16 @@ int xen_device_frontend_scanf(XenDevice *xendev, const char *key,
     return rc;
 }
 
+char *xen_device_frontend_read(XenDevice *xendev, const char *key)
+{
+    XenBus *xenbus = XEN_BUS(qdev_get_parent_bus(DEVICE(xendev)));
+
+    g_assert(xenbus->xsh);
+
+    return xs_node_read(xenbus->xsh, XBT_NULL, NULL, NULL, "%s/%s",
+                        xendev->frontend_path, key);;
+}
+
 static void xen_device_frontend_set_state(XenDevice *xendev,
                                           enum xenbus_state state,
                                           bool publish)
diff --git a/include/hw/xen/xen-bus.h b/include/hw/xen/xen-bus.h
index 38d40afa37..2adb2af839 100644
--- a/include/hw/xen/xen-bus.h
+++ b/include/hw/xen/xen-bus.h
@@ -91,6 +91,7 @@ void xen_device_frontend_printf(XenDevice *xendev, const char *key,
 int xen_device_frontend_scanf(XenDevice *xendev, const char *key,
                               const char *fmt, ...)
     G_GNUC_SCANF(3, 4);
+char *xen_device_frontend_read(XenDevice *xendev, const char *key);
 
 void xen_device_set_max_grant_refs(XenDevice *xendev, unsigned int nr_refs,
                                    Error **errp);
-- 
2.47.0



From xen-devel-bounces@lists.xenproject.org Wed Jan 15 16:35:55 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 16:35:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872764.1283818 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY6N1-0005DL-H2; Wed, 15 Jan 2025 16:35:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872764.1283818; Wed, 15 Jan 2025 16:35:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY6N1-0005C3-7Y; Wed, 15 Jan 2025 16:35:55 +0000
Received: by outflank-mailman (input) for mailman id 872764;
 Wed, 15 Jan 2025 16:35: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
 <SRS0=rWPo=UH=casper.srs.infradead.org=BATV+fb641630334796bb9467+7815+infradead.org+dwmw2@srs-se1.protection.inumbo.net>)
 id 1tY6Mz-0003cf-Bo
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 16:35:53 +0000
Received: from casper.infradead.org (casper.infradead.org
 [2001:8b0:10b:1236::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c4c87df8-d35e-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 17:35:45 +0100 (CET)
Received: from [2001:8b0:10b:1::ebe] (helo=i7.infradead.org)
 by casper.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux))
 id 1tY6Mq-0000000GF6G-0R8I; Wed, 15 Jan 2025 16:35:44 +0000
Received: from dwoodhou by i7.infradead.org with local (Exim 4.98 #2 (Red Hat
 Linux)) id 1tY6Mp-00000001HhS-3ZNZ; Wed, 15 Jan 2025 16:35:43 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
X-Inumbo-ID: c4c87df8-d35e-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=Sender:Content-Transfer-Encoding:
	Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:
	To:From:Reply-To:Content-ID:Content-Description;
	bh=avIVcNVqQ6j0evk6/rCF7dghJGKxSFwtADzqzgfr/dc=; b=CMCvmvfDcdm9LD61HoKq/cRAPv
	i6lBUIect+qUzZMx/qDM3KhyWioS+yXn+XWAZxssNT97ml+5q5DZC/AKzXMmJbi+/BlnOfOZivDTj
	HRfOd4rOdFig6oPCfbzUXV0s3QNqA/ysEzwU/Imm3xaE6/KQlHUFGkL4S6HYGjeS60Tc9F2ms70Z/
	4onciy0CBnQLh5londT61eAMmpkN0ZJaXemMhdglNNsB8MNbqsCH8E1qykMJAfYqBNgnU3KqIzUTN
	H4RS6tbm6SAKmEPNVN6eayfhLuSoDQptjwvM7gYIhDXN7OeqJoyzPrIayk7FTLz4AI6aR0aJaTqqT
	mwOiMB6A==;
From: David Woodhouse <dwmw2@infradead.org>
To: qemu-devel@nongnu.org,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Kevin Wolf <kwolf@redhat.com>,
	Hanna Reitz <hreitz@redhat.com>,
	=?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= <marcandre.lureau@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	xen-devel@lists.xenproject.org,
	qemu-block@nongnu.org
Subject: [PATCH v3 1/7] hw/xen: Add xs_node_read() helper function
Date: Wed, 15 Jan 2025 16:27:19 +0000
Message-ID: <20250115163542.291424-2-dwmw2@infradead.org>
X-Mailer: git-send-email 2.47.0
In-Reply-To: <20250115163542.291424-1-dwmw2@infradead.org>
References: <20250115163542.291424-1-dwmw2@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Sender: David Woodhouse <dwmw2@infradead.org>
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html

From: David Woodhouse <dwmw@amazon.co.uk>

This returns the full contents of the node, having created the node path
from the printf-style format string provided in its arguments.

This will save various callers from having to do so for themselves (and
from using xs_node_scanf() with the non-portable %ms format string.

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
[remove double newline and constify trace parameters]
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 hw/xen/trace-events             |  1 +
 hw/xen/xen-bus-helper.c         | 22 ++++++++++++++++++++++
 include/hw/xen/xen-bus-helper.h |  9 +++++++++
 3 files changed, 32 insertions(+)

diff --git a/hw/xen/trace-events b/hw/xen/trace-events
index a07fe41c6d..461dee7b23 100644
--- a/hw/xen/trace-events
+++ b/hw/xen/trace-events
@@ -39,6 +39,7 @@ xs_node_create(const char *node) "%s"
 xs_node_destroy(const char *node) "%s"
 xs_node_vprintf(char *path, char *value) "%s %s"
 xs_node_vscanf(char *path, char *value) "%s %s"
+xs_node_read(const char *path, const char *value) "%s %s"
 xs_node_watch(char *path) "%s"
 xs_node_unwatch(char *path) "%s"
 
diff --git a/hw/xen/xen-bus-helper.c b/hw/xen/xen-bus-helper.c
index b2b2cc9c5d..22fd2f6c1a 100644
--- a/hw/xen/xen-bus-helper.c
+++ b/hw/xen/xen-bus-helper.c
@@ -142,6 +142,28 @@ int xs_node_scanf(struct qemu_xs_handle *h,  xs_transaction_t tid,
     return rc;
 }
 
+char *xs_node_read(struct qemu_xs_handle *h, xs_transaction_t tid,
+                   unsigned int *len, Error **errp,
+                   const char *path_fmt, ...)
+{
+    char *path, *value;
+    va_list ap;
+
+    va_start(ap, path_fmt);
+    path = g_strdup_vprintf(path_fmt, ap);
+    va_end(ap);
+
+    value = qemu_xen_xs_read(h, tid, path, len);
+    trace_xs_node_read(path, value);
+    if (!value) {
+        error_setg_errno(errp, errno, "failed to read from '%s'", path);
+    }
+
+    g_free(path);
+
+    return value;
+}
+
 struct qemu_xs_watch *xs_node_watch(struct qemu_xs_handle *h, const char *node,
                                     const char *key, xs_watch_fn fn,
                                     void *opaque, Error **errp)
diff --git a/include/hw/xen/xen-bus-helper.h b/include/hw/xen/xen-bus-helper.h
index d8dcc2f010..e9911115b3 100644
--- a/include/hw/xen/xen-bus-helper.h
+++ b/include/hw/xen/xen-bus-helper.h
@@ -38,6 +38,15 @@ int xs_node_scanf(struct qemu_xs_handle *h,  xs_transaction_t tid,
                   const char *fmt, ...)
     G_GNUC_SCANF(6, 7);
 
+/*
+ * Unlike other functions here, the printf-formatted path_fmt is for
+ * the XenStore path, not the contents of the node.
+ */
+char *xs_node_read(struct qemu_xs_handle *h, xs_transaction_t tid,
+                   unsigned int *len, Error **errp,
+                   const char *path_fmt, ...)
+    G_GNUC_PRINTF(5, 6);
+
 /* Watch node/key unless node is empty, in which case watch key */
 struct qemu_xs_watch *xs_node_watch(struct qemu_xs_handle *h, const char *node,
                                     const char *key, xs_watch_fn fn,
-- 
2.47.0



From xen-devel-bounces@lists.xenproject.org Wed Jan 15 16:37:04 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 16:37:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872799.1283827 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY6O4-0007ct-No; Wed, 15 Jan 2025 16:37:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872799.1283827; Wed, 15 Jan 2025 16:37:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY6O4-0007cm-KC; Wed, 15 Jan 2025 16:37:00 +0000
Received: by outflank-mailman (input) for mailman id 872799;
 Wed, 15 Jan 2025 16:36:58 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=P4PG=UH=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tY6O2-0007cK-Gr
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 16:36:58 +0000
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com
 [2a00:1450:4864:20::135])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id eef072b6-d35e-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 17:36:56 +0100 (CET)
Received: by mail-lf1-x135.google.com with SMTP id
 2adb3069b0e04-53e399e3310so7168538e87.1
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 08:36:56 -0800 (PST)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5428becb27csm2032564e87.251.2025.01.15.08.36.54
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 15 Jan 2025 08:36:54 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: eef072b6-d35e-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736959015; x=1737563815; 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=E63x/z9jkgyvj2/eMGJ3oEP7WQXMUe2ctgd9S/svLA4=;
        b=QehZ+rbq+JCcgXEqWHJUbHsqoUyE59c3C/3Q7H4ETU7aRQYD4B078yWUhc4YQiML7V
         2fU7rrpKne7mmdD9AgQ09ct6gFYolxaxbZRfm5zOZYT+Om3vC8KLZ9e+36PwjtbUjSeo
         3dAgGghJvCrUnfxFpiosNCLUNNxxs8Ra6Pgbe9P+cacsTkwiXYTsAvSlceeJ/W8MQq2G
         wNmVJ+BcOk6+2tRy6lAoxOCRG7HQq5atIwTRNt5X/BmNNPXdVCM2wO8sKfbzJqnxwukp
         1amQDMvYPZvkbhLbmmfpEgtawcOhvVVaBi59T9MpV/CTCP8NCND97wVhKbG2gpFsI+WJ
         JByw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736959015; x=1737563815;
        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=E63x/z9jkgyvj2/eMGJ3oEP7WQXMUe2ctgd9S/svLA4=;
        b=OXUlcbbRiTS2+/9as1OqXQYUn1UDtiQ5ToiiLmj35chMpMOuGa/3LJyGFzd+yIpUEz
         vD7W5B4DBRJqKzY0pErIE1Xatk6A49YQpR+WoiGvNBjwyqzgAGGioYdwYnKBPw4mC3YY
         wKRGZisFKjUkAW9TdugmQz4OQIq0rTpe4GcPt7W8r6pm+1z0wL1MPdHgjzzS0NAYlUL3
         +x9ezr/j31KgV/fdZtJMRUKkWznnGc7pfhsK4IkumhkTUux3Ly58VHI35qLlcVmpDdzI
         3I+5kEcP1pndCDIzZ+H0/nopeJrpbxcPzaIlwup8TE8C6skGFKjt7qAqcD+6ZRPe2FyS
         fSOQ==
X-Gm-Message-State: AOJu0YztrEuFc3gzIuYi5A8TS8ig0IfmNcapkvVtdea0RurwRA15Oz1J
	pl0la4KxLq62QxCdzrEtsqlLLOErZ5qusYyv0Vj/GJQGLFz4KmSOsr9obg==
X-Gm-Gg: ASbGnctI4DThw/RN8XfaUKQIed2DDW7dp2zJ69xNi+2gV4pJz6sDpU6Y0T4NMayTygs
	aXr/PFEcMuTp10P7M3Gmj+LYl+Zl7KYSjsZubjAdZ9R1u8qmnkJqquej26ZdLqxY+Xu6bWkUmPy
	dSmRgVvdJoDRYOXxhCFLJcUXKwVI5KSxLnAgnrl/tXQU608FXSwpIV5Z0rf4rImXFXMreWpZorT
	sLL17d/Goi5C5gs0wl4VRJRzvPgz6BJBcISyPUyhJk8DHamfPZlolpUWw==
X-Google-Smtp-Source: AGHT+IE8ccFyrGtHYgh7RHy/mo4w4v+yUPZ8mIjrAjc9RTmNELYGYC2Ar5wDAN7uU6iyXCslFGS5gw==
X-Received: by 2002:a05:6512:3188:b0:542:98e9:63b1 with SMTP id 2adb3069b0e04-54298e965fcmr6338838e87.31.1736959014837;
        Wed, 15 Jan 2025 08:36:54 -0800 (PST)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Bob Eshleman <bobbyeshleman@gmail.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v2] xen/riscv: identify specific ISA supported by cpu
Date: Wed, 15 Jan 2025 17:36:52 +0100
Message-ID: <0a6562ae1e22e3fe607054b33df3467c12d0b276.1736956861.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.47.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Supported ISA extensions are specified in the device tree within the CPU
node, using two properties: `riscv,isa-extensions` and `riscv,isa`.

Currently, Xen does not support the `riscv,isa-extensions` property, as
all available device tree source (DTS) files in the Linux kernel (v6.12-rc3)
and DTBs generated by QEMU use only the `riscv,isa` property.
Therefore, only `riscv,isa` parsing is implemented.

The `riscv,isa` property is parsed for each CPU, and the common extensions
are stored in the `host_riscv_isa` bitmap.
This bitmap is then used by `riscv_isa_extension_available()` to check
if a specific extension is supported.

The current implementation is based on Linux kernel v6.12-rc3
implementation with the following changes:
 - Drop unconditional setting of {RISCV_ISA_EXT_ZICSR,
   RISCV_ISA_EXT_ZIFENCEI, RISCV_ISA_EXT_ZICNTR, RISCV_ISA_EXT_ZIHPM} as they
   are now part of the riscv,isa string.
 - Remove saving of the ISA for each CPU, only the common available ISA is
   saved.
 - Remove ACPI-related code as ACPI is not supported by Xen.
 - Drop handling of elf_hwcap, since Xen does not provide hwcap to
   userspace.
 - Replace of_cpu_device_node_get() API, which is not available in Xen,
   with a combination of dt_for_each_child_node(), dt_device_type_is_equal(),
   and dt_get_cpuid_from_node() to retrieve cpuid and riscv,isa in
   riscv_fill_hwcap_from_isa_string().
 - Rename arguments of __RISCV_ISA_EXT_DATA() from _name to ext_name, and
   _id to ext_id for clarity.
 - Replace instances of __RISCV_ISA_EXT_DATA with RISCV_ISA_EXT_DATA.
 - Replace instances of __riscv_isa_extension_available with
   riscv_isa_extension_available for consistency. Also, update the type of
   `bit` argument of riscv_isa_extension_available().
 - Redefine RISCV_ISA_EXT_DATA() to work only with ext_name and ext_id,
   as other fields are not used in Xen currently.
 - Add check of first 4 letters of riscv,isa string to
   riscv_isa_parse_string() as Xen doesn't do this check before so it is
   necessary to check correctness of riscv,isa string. ( it should start with
   rv{32,64} with taking into account upper and lower case of "rv").
 - Drop an argument of riscv_fill_hwcap() and riscv_fill_hwcap_from_isa_string()
   as it isn't used, at the moment.
 - Update the comment message about QEMU workaround.
 - Apply Xen coding style.
 - s/pr_info/printk.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
Changes in V2:
- Update the list of changes in comparison with Linux on the top of
  cpufeature.c.
- Now really drop all ACPI-related stuff.
  Add #ifdef CONFIG_ACPI #error ... #endif instead.
- Make `id` ( member of riscv_isa_ext_data structure ) not const.
- s/__read_mostly/__ro_after_init for riscv_isa bitmap.
- Update the comment above riscv_isa_ext[] declaration:
  - Drop Linux details.
  - Revised the numbering of the ordering rules for RISC-V ISA extensions.
  - Add comment that extension name must be all lowercase according to
    device tree binding.
- Add __initconst for declarations of riscv_isa_ext[] and
  required_extensions[].
- Move riscv_isa_ext_count for global declaration to match_isa_ext where
  it is really used.
- Add new function is_lowercase_extension_name().
- Updates for match_isa_ext():
  - Move last argument of match_isa_ext() to new line to not violate line
    length.
  - s/int/unsigned int for cycle varible `i`.
  - s/set_bit/__set_bit as no need for atomicity at this stage of boot.
  - Add ASSERT() to be sure that extension name is in lowercase.
  - s/strncasecmp/strncasecmp as extension name must be in a lowercase.
- Updates for riscv_isa_parse_string():
  - Move last argument of riscv_isa_parse_string() to new line to not violate
    line length.
  - Update the checks at the start of the function. Now if CONFIG_RISCV_32=y
    the only rv32 is accepted, or rv64 for CONFIG_RISCV_64=y.
  - Drop ACPI-related stuff.
  - Add blank lines between non-fall-through case blocks.
  - Add blanks in `for loops` before ')'.
  - Update the comment about QEMU workaround for invalid single-letter
    's' & 'u'.
- Updates for riscv_fill_hwcap_from_ext_list():
  - Drop initilizer of cpuid inside dt_for_each_child_node() {...}.
  - Introduce res and return it instead of -EINVAL.
  - Drop `else` and change printk("riscv,isa-extensions isnt supported\n")
    to panic("riscv,isa-extensions isnt supported\n").
  - Drop ( cpuid >= NR_CPUS ) check as cpuid technically could be any
    number. Only cpuid=0 is guaranteed to be.
- Updates for riscv_fill_hwcap_from_isa_string():
  - move cpuid and isa variables to dt_for_each_child_node() {...}.
  - Drop initilizer of cpuid inside dt_for_each_child_node() {...}.
  - Drop ( cpuid >= NR_CPUS ) check as cpuid technically could be any
    number. Only cpuid=0 is guaranteed to be.
  - Add ASSERT() to be sure that `this_isa` isn't null to prevent ending up
    with extensions not supported by one of the CPUs.
- Updates for riscv_isa_extension_available():
  - Code style fixes.
  - Drop conditional operator used in return as functions returns bool.
- s/extenstion/extensions, s/extenstion/extenstion.
- Drop RISCV_ISA_EXT_SxAIA as it isn't used.
- Move definitions of RISCV_ISA_EXT_{a,c,d,...,v} to enum riscv_isa_ext_id.
- Move macros RISCV_ISA_EXT_MAX to enum riscv_isa_ext_id.
- Update the comment above definition of RISCV_ISA_EXT_BASE.
- Fix code style ( violation of line length ) for
  riscv_isa_extension_available().
- Sync commit message with the comment on the start of cpufeature.c
---
 xen/arch/riscv/Makefile                 |   1 +
 xen/arch/riscv/cpufeature.c             | 506 ++++++++++++++++++++++++
 xen/arch/riscv/include/asm/cpufeature.h |  57 +++
 xen/arch/riscv/setup.c                  |   3 +
 4 files changed, 567 insertions(+)
 create mode 100644 xen/arch/riscv/cpufeature.c
 create mode 100644 xen/arch/riscv/include/asm/cpufeature.h

diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
index a5eb2aed4b..b0c8270a99 100644
--- a/xen/arch/riscv/Makefile
+++ b/xen/arch/riscv/Makefile
@@ -1,3 +1,4 @@
+obj-y += cpufeature.o
 obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
 obj-y += entry.o
 obj-y += mm.o
diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c
new file mode 100644
index 0000000000..2e43551189
--- /dev/null
+++ b/xen/arch/riscv/cpufeature.c
@@ -0,0 +1,506 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Taken for Linux kernel v6.12-rc3 and modified by
+ * Oleksii Kurochko <oleksii.kurochko@gmail.com>:
+ *
+ * - Drop unconditional setting of {RISCV_ISA_EXT_ZICSR,
+ *   RISCV_ISA_EXT_ZIFENCEI, RISCV_ISA_EXT_ZICNTR, RISCV_ISA_EXT_ZIHPM} as they
+ *   are now part of the riscv,isa string.
+ * - Remove saving of the ISA for each CPU, only the common available ISA is
+ *   saved.
+ * - Remove ACPI-related code as ACPI is not supported by Xen.
+ * - Drop handling of elf_hwcap, since Xen does not provide hwcap to
+ *   userspace.
+ * - Replace of_cpu_device_node_get() API, which is not available in Xen,
+ *   with a combination of dt_for_each_child_node(), dt_device_type_is_equal(),
+ *   and dt_get_cpuid_from_node() to retrieve cpuid and riscv,isa in
+ *   riscv_fill_hwcap_from_isa_string().
+ * - Rename arguments of __RISCV_ISA_EXT_DATA() from _name to ext_name, and
+ *   _id to ext_id for clarity.
+ * - Replace instances of __RISCV_ISA_EXT_DATA with RISCV_ISA_EXT_DATA.
+ * - Replace instances of __riscv_isa_extension_available with
+ *   riscv_isa_extension_available for consistency. Also, update the type of
+ *   `bit` argument of riscv_isa_extension_available().
+ * - Redefine RISCV_ISA_EXT_DATA() to work only with ext_name and ext_id,
+ *   as other fields are not used in Xen currently.
+ * - Add check of first 4 letters of riscv,isa string to
+ *   riscv_isa_parse_string() as Xen doesn't do this check before so it is
+ *   necessary to check correctness of riscv,isa string. ( it should start with
+ *   rv{32,64} with taking into account lower case of "rv").
+ * - Drop an argument of riscv_fill_hwcap() and riscv_fill_hwcap_from_isa_string()
+ *   as it isn't used, at the moment.
+ * - Update the comment message about QEMU workaround.
+ * - s/pr_info/printk.
+ *
+ * Copyright (C) 2015 ARM Ltd.
+ * Copyright (C) 2017 SiFive
+ * Copyright (C) 2024 Vates
+ */
+
+#include <xen/bitmap.h>
+#include <xen/ctype.h>
+#include <xen/device_tree.h>
+#include <xen/errno.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/sections.h>
+
+#include <asm/cpufeature.h>
+
+#ifdef CONFIG_ACPI
+#error "cpufeature.c functions should be updated to support ACPI"
+#endif
+
+struct riscv_isa_ext_data {
+    unsigned int id;
+    const char *name;
+};
+
+#define RISCV_ISA_EXT_DATA(ext_name, ext_id)    \
+{                                               \
+    .id = ext_id,                               \
+    .name = #ext_name,                          \
+}
+
+/* Host ISA bitmap */
+static __ro_after_init DECLARE_BITMAP(riscv_isa, RISCV_ISA_EXT_MAX);
+
+static int __init dt_get_cpuid_from_node(const struct dt_device_node *cpu)
+{
+    const __be32 *prop;
+    unsigned int reg_len;
+
+    if ( dt_n_size_cells(cpu) != 0 )
+        printk("cpu node `%s`: #size-cells %d\n",
+               dt_node_full_name(cpu), dt_n_size_cells(cpu));
+
+    prop = dt_get_property(cpu, "reg", &reg_len);
+    if ( !prop )
+    {
+        printk("cpu node `%s`: has no reg property\n", dt_node_full_name(cpu));
+        return -EINVAL;
+    }
+
+    if ( reg_len < dt_cells_to_size(dt_n_addr_cells(cpu)) )
+    {
+        printk("cpu node `%s`: reg property too short\n",
+               dt_node_full_name(cpu));
+        return -EINVAL;
+    }
+
+    return dt_read_paddr(prop, dt_n_addr_cells(cpu));
+}
+
+/*
+ * The canonical order of ISA extension names in the ISA string is defined in
+ * chapter 27 of the unprivileged specification.
+ *
+ * The specification uses vague wording, such as should, when it comes to
+ * ordering, so for our purposes the following rules apply:
+ *
+ * 1. All multi-letter extensions must be separated from other extensions by an
+ *    underscore.
+ *
+ * 2. Additional standard extensions (starting with 'Z') must be sorted after
+ *    single-letter extensions and before any higher-privileged extensions.
+ *
+ * 3. The first letter following the 'Z' conventionally indicates the most
+ *    closely related alphabetical extension category, IMAFDQLCBKJTPVH.
+ *    If multiple 'Z' extensions are named, they must be ordered first by
+ *    category, then alphabetically within a category.
+ *
+ * 4. Standard supervisor-level extensions (starting with 'S') must be listed
+ *    after standard unprivileged extensions.  If multiple supervisor-level
+ *    extensions are listed, they must be ordered alphabetically.
+ *
+ * 5. Standard machine-level extensions (starting with 'Zxm') must be listed
+ *    after any lower-privileged, standard extensions.  If multiple
+ *    machine-level extensions are listed, they must be ordered
+ *    alphabetically.
+ *
+ * 6. Non-standard extensions (starting with 'X') must be listed after all
+ *    standard extensions. If multiple non-standard extensions are listed, they
+ *    must be ordered alphabetically.
+ *
+ * An example string following the order is:
+ *    rv64imadc_zifoo_zigoo_zafoo_sbar_scar_zxmbaz_xqux_xrux
+ *
+ * New entries to this struct should follow the ordering rules described above.
+ *
+ * Extension name must be all lowercase ( according to device-tree binding )
+ * and strncmp() is used in match_isa_ext() to compare extension names instead
+ * of strncasecmp().
+ */
+const struct riscv_isa_ext_data __initconst riscv_isa_ext[] = {
+    RISCV_ISA_EXT_DATA(i, RISCV_ISA_EXT_i),
+    RISCV_ISA_EXT_DATA(m, RISCV_ISA_EXT_m),
+    RISCV_ISA_EXT_DATA(a, RISCV_ISA_EXT_a),
+    RISCV_ISA_EXT_DATA(f, RISCV_ISA_EXT_f),
+    RISCV_ISA_EXT_DATA(d, RISCV_ISA_EXT_d),
+    RISCV_ISA_EXT_DATA(q, RISCV_ISA_EXT_q),
+    RISCV_ISA_EXT_DATA(h, RISCV_ISA_EXT_h),
+    RISCV_ISA_EXT_DATA(zicntr, RISCV_ISA_EXT_ZICNTR),
+    RISCV_ISA_EXT_DATA(zicsr, RISCV_ISA_EXT_ZICSR),
+    RISCV_ISA_EXT_DATA(zifencei, RISCV_ISA_EXT_ZIFENCEI),
+    RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE),
+    RISCV_ISA_EXT_DATA(zihpm, RISCV_ISA_EXT_ZIHPM),
+    RISCV_ISA_EXT_DATA(zbb, RISCV_ISA_EXT_ZBB),
+    RISCV_ISA_EXT_DATA(smaia, RISCV_ISA_EXT_SMAIA),
+    RISCV_ISA_EXT_DATA(ssaia, RISCV_ISA_EXT_SSAIA),
+};
+
+static const struct riscv_isa_ext_data __initconst required_extensions[] = {
+    RISCV_ISA_EXT_DATA(zbb, RISCV_ISA_EXT_ZBB),
+    RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE),
+};
+
+static bool is_lowercase_extension_name(const char *str)
+{
+    if ( !str )
+        return false;
+
+    for ( unsigned int i = 0; (str[i] != '\0') && (str[i] != '_'); i++ )
+        if ( !islower(str[i]) )
+            return false;
+
+    return true;
+}
+
+static void __init match_isa_ext(const char *name, const char *name_end,
+                                 unsigned long *bitmap)
+{
+    const size_t riscv_isa_ext_count = ARRAY_SIZE(riscv_isa_ext);
+
+    for ( unsigned int i = 0; i < riscv_isa_ext_count; i++ )
+    {
+        const struct riscv_isa_ext_data *ext = &riscv_isa_ext[i];
+
+        /*
+         * `name` ( according to device tree binding ) and
+         * `ext->name` ( according to initialization of riscv_isa_ext[]
+         * elements must be all in lowercase.
+         *
+         * Just to be sure that it is true, ASSERT() are added.
+         */
+        ASSERT(is_lowercase_extension_name(name) &&
+               is_lowercase_extension_name(ext->name));
+
+        if ( (name_end - name == strlen(ext->name)) &&
+             !strncmp(name, ext->name, name_end - name) )
+        {
+            __set_bit(ext->id, bitmap);
+            break;
+        }
+    }
+}
+
+static int __init riscv_isa_parse_string(const char *isa,
+                                         unsigned long *out_bitmap)
+{
+    /*
+     * According to RISC-V device tree binding isa string must be all
+     * lowercase.
+     * To be sure that this is true, ASSERT below is added.
+     */
+    ASSERT(islower(isa[0]) && islower(isa[1]));
+
+    if ( (isa[0] != 'r') && (isa[1] != 'v') )
+        return -EINVAL;
+
+#if defined(CONFIG_RISCV_32)
+    if ( isa[2] != '3' && isa[3] != '2' )
+        return -EINVAL;
+#elif defined(CONFIG_RISCV_64)
+    if ( isa[2] != '6' && isa[3] != '4' )
+        return -EINVAL;
+#else
+    #error "unsupported RISC-V bitness"
+#endif
+
+    isa += 4;
+
+    while ( *isa )
+    {
+        const char *ext = isa++;
+        const char *ext_end = isa;
+        bool ext_err = false;
+
+        switch ( *ext )
+        {
+        case 'x':
+        case 'X':
+            printk_once("Vendor extensions are ignored in riscv,isa."
+                        "Use riscv,isa-extensions instead\n");
+            /*
+             * To skip an extension, we find its end.
+             * As multi-letter extensions must be split from other multi-letter
+             * extensions with an "_", the end of a multi-letter extension will
+             * either be the null character or the "_" at the start of the next
+             * multi-letter extension.
+             */
+            for ( ; *isa && *isa != '_'; ++isa )
+                ;
+            ext_err = true;
+            break;
+
+        case 's':
+            /*
+             * Workaround for invalid single-letter 's' & 'u' (QEMU):
+             *   Before QEMU 7.1 it was an issue with misa to ISA string
+             *   conversion:
+             *     https://patchwork.kernel.org/project/qemu-devel/patch/dee09d708405075420b29115c1e9e87910b8da55.1648270894.git.research_trasio@irq.a4lg.com/#24792587
+             *   Additional details of the workaround on Linux kernel side:
+             *     https://lore.kernel.org/linux-riscv/ae93358e-e117-b43d-faad-772c529f846c@irq.a4lg.com/#t
+             *
+             * No need to set the bit in riscv_isa as 's' & 'u' are
+             * not valid ISA extensions. It works unless the first
+             * multi-letter extension in the ISA string begins with
+             * "Su" and is not prefixed with an underscore.
+             */
+            if ( ext[-1] != '_' && ext[1] == 'u' )
+            {
+                ++isa;
+                ext_err = true;
+                break;
+            }
+            fallthrough;
+        case 'S':
+        case 'z':
+        case 'Z':
+            /*
+             * Before attempting to parse the extension itself, we find its end.
+             * As multi-letter extensions must be split from other multi-letter
+             * extensions with an "_", the end of a multi-letter extension will
+             * either be the null character or the "_" at the start of the next
+             * multi-letter extension.
+             *
+             * Next, as the extensions version is currently ignored, we
+             * eliminate that portion. This is done by parsing backwards from
+             * the end of the extension, removing any numbers. This may be a
+             * major or minor number however, so the process is repeated if a
+             * minor number was found.
+             *
+             * ext_end is intended to represent the first character *after* the
+             * name portion of an extension, but will be decremented to the last
+             * character itself while eliminating the extensions version number.
+             * A simple re-increment solves this problem.
+             */
+            for ( ; *isa && *isa != '_'; ++isa )
+                if ( unlikely(!isalnum(*isa)) )
+                    ext_err = true;
+
+            ext_end = isa;
+            if ( unlikely(ext_err) )
+                break;
+
+            if ( !isdigit(ext_end[-1]) )
+                break;
+
+            while ( isdigit(*--ext_end) )
+                ;
+
+            if ( tolower(ext_end[0]) != 'p' || !isdigit(ext_end[-1]) )
+            {
+                ++ext_end;
+                break;
+            }
+
+            while ( isdigit(*--ext_end) )
+                ;
+
+            ++ext_end;
+            break;
+
+        default:
+            /*
+             * Things are a little easier for single-letter extensions, as they
+             * are parsed forwards.
+             *
+             * After checking that our starting position is valid, we need to
+             * ensure that, when isa was incremented at the start of the loop,
+             * that it arrived at the start of the next extension.
+             *
+             * If we are already on a non-digit, there is nothing to do. Either
+             * we have a multi-letter extension's _, or the start of an
+             * extension.
+             *
+             * Otherwise we have found the current extension's major version
+             * number. Parse past it, and a subsequent p/minor version number
+             * if present. The `p` extension must not appear immediately after
+             * a number, so there is no fear of missing it.
+             */
+            if ( unlikely(!isalpha(*ext)) )
+            {
+                ext_err = true;
+                break;
+            }
+
+            if ( !isdigit(*isa) )
+                break;
+
+            while ( isdigit(*++isa) )
+                ;
+
+            if ( tolower(*isa) != 'p' )
+                break;
+
+            if ( !isdigit(*++isa) )
+            {
+                --isa;
+                break;
+            }
+
+            while ( isdigit(*++isa) )
+                ;
+
+            break;
+        }
+
+        /*
+         * The parser expects that at the start of an iteration isa points to the
+         * first character of the next extension. As we stop parsing an extension
+         * on meeting a non-alphanumeric character, an extra increment is needed
+         * where the succeeding extension is a multi-letter prefixed with an "_".
+         */
+        if ( *isa == '_' )
+            ++isa;
+
+        if ( unlikely(ext_err) )
+            continue;
+
+        match_isa_ext(ext, ext_end, out_bitmap);
+    }
+
+    return 0;
+}
+
+static int __init riscv_fill_hwcap_from_ext_list(void)
+{
+    const struct dt_device_node *cpus = dt_find_node_by_path("/cpus");
+    const struct dt_device_node *cpu;
+    int res = -EINVAL;
+
+    if ( !cpus )
+    {
+        printk("Missing /cpus node in the device tree?\n");
+        return -EINVAL;
+    }
+
+    dt_for_each_child_node(cpus, cpu)
+    {
+        const char *isa;
+        int cpuid;
+
+        if ( !dt_device_type_is_equal(cpu, "cpu") )
+            continue;
+
+        cpuid = dt_get_cpuid_from_node(cpu);
+        if ( cpuid < 0 )
+            continue;
+
+        if ( dt_property_read_string(cpu, "riscv,isa-extensions", &isa) )
+        {
+            printk("Unable to find \"riscv,isa-extensions\" devicetree entry "
+                   "for cpu%d\n", cpuid);
+            res = -EINVAL;
+            continue;
+        }
+
+        panic("riscv,isa-extensions isnt supported\n");
+    }
+
+    return res;
+}
+
+static void __init riscv_fill_hwcap_from_isa_string(void)
+{
+    const struct dt_device_node *cpus = dt_find_node_by_path("/cpus");
+    const struct dt_device_node *cpu;
+
+    if ( !cpus )
+    {
+        printk("Missing /cpus node in the device tree?\n");
+        return;
+    }
+
+    dt_for_each_child_node(cpus, cpu)
+    {
+        DECLARE_BITMAP(this_isa, RISCV_ISA_EXT_MAX);
+        const char *isa;
+        int cpuid;
+
+        if ( !dt_device_type_is_equal(cpu, "cpu") )
+            continue;
+
+        cpuid = dt_get_cpuid_from_node(cpu);
+        if ( cpuid < 0 )
+            continue;
+
+        if ( dt_property_read_string(cpu, "riscv,isa", &isa) )
+        {
+            printk("Unable to find \"riscv,isa\" devicetree entry\n");
+            continue;
+        }
+
+        riscv_isa_parse_string(isa, this_isa);
+
+        /*
+         * In the unpriv. spec is mentioned:
+         *   A RISC-V ISA is defined as a base integer ISA, which must be
+         *   present in any implementation, plus optional extensions to
+         *   the base ISA.
+         * What means that isa should contain, at least, I or E thereby
+         * this_isa can't be empty too.
+         *
+         * Ensure that this_isa is not empty, so riscv_isa won't be empty
+         * during initialization. This prevents ending up with extensions
+         * not supported by one of the CPUs.
+         */
+        ASSERT(!bitmap_empty(this_isa, RISCV_ISA_EXT_MAX));
+
+        if ( bitmap_empty(riscv_isa, RISCV_ISA_EXT_MAX) )
+            bitmap_copy(riscv_isa, this_isa, RISCV_ISA_EXT_MAX);
+        else
+            bitmap_and(riscv_isa, riscv_isa, this_isa, RISCV_ISA_EXT_MAX);
+    }
+}
+
+bool riscv_isa_extension_available(const unsigned long *isa_bitmap,
+                                   enum riscv_isa_ext_id bit)
+{
+    const unsigned long *bmap = (isa_bitmap) ? isa_bitmap : riscv_isa;
+
+    if ( bit >= RISCV_ISA_EXT_MAX )
+        return false;
+
+    return test_bit(bit, bmap);
+}
+
+void __init riscv_fill_hwcap(void)
+{
+    unsigned int i;
+    size_t req_extns_amount = ARRAY_SIZE(required_extensions);
+    bool all_extns_available = true;
+
+    int ret = riscv_fill_hwcap_from_ext_list();
+
+    if ( ret )
+    {
+        printk("Falling back to deprecated \"riscv,isa\"\n");
+        riscv_fill_hwcap_from_isa_string();
+    }
+
+    for ( i = 0; i < req_extns_amount; i++ )
+    {
+        const struct riscv_isa_ext_data ext = required_extensions[i];
+
+        if ( !riscv_isa_extension_available(NULL, ext.id) )
+        {
+            printk("Xen requires extension: %s\n", ext.name);
+            all_extns_available = false;
+        }
+    }
+
+    if ( !all_extns_available )
+        panic("Look why the extensions above are needed in booting.txt\n");
+}
diff --git a/xen/arch/riscv/include/asm/cpufeature.h b/xen/arch/riscv/include/asm/cpufeature.h
new file mode 100644
index 0000000000..835bdd6264
--- /dev/null
+++ b/xen/arch/riscv/include/asm/cpufeature.h
@@ -0,0 +1,57 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef ASM__RISCV__CPUFEATURE_H
+#define ASM__RISCV__CPUFEATURE_H
+
+#ifndef __ASSEMBLY__
+
+#include <xen/stdbool.h>
+
+/*
+ * These macros represent the logical IDs of each multi-letter RISC-V ISA
+ * extension and are used in the ISA bitmap. The logical IDs start from
+ * RISCV_ISA_EXT_BASE, which allows the 0-25 range to be reserved for single
+ * letter extensions and are used in enum riscv_isa_ext_id.
+ *
+ * New extensions should just be added to the bottom, rather than added
+ * alphabetically, in order to avoid unnecessary shuffling.
+ */
+#define RISCV_ISA_EXT_BASE  26
+
+enum riscv_isa_ext_id {
+    RISCV_ISA_EXT_a,
+    RISCV_ISA_EXT_c,
+    RISCV_ISA_EXT_d,
+    RISCV_ISA_EXT_f,
+    RISCV_ISA_EXT_h,
+    RISCV_ISA_EXT_i,
+    RISCV_ISA_EXT_m,
+    RISCV_ISA_EXT_q,
+    RISCV_ISA_EXT_v,
+    RISCV_ISA_EXT_ZICNTR = RISCV_ISA_EXT_BASE,
+    RISCV_ISA_EXT_ZICSR,
+    RISCV_ISA_EXT_ZIFENCEI,
+    RISCV_ISA_EXT_ZIHINTPAUSE,
+    RISCV_ISA_EXT_ZIHPM,
+    RISCV_ISA_EXT_ZBB,
+    RISCV_ISA_EXT_SMAIA,
+    RISCV_ISA_EXT_SSAIA,
+    RISCV_ISA_EXT_MAX
+};
+
+void riscv_fill_hwcap(void);
+
+bool riscv_isa_extension_available(const unsigned long *isa_bitmap,
+                                   enum riscv_isa_ext_id bit);
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* ASM__RISCV__CPUFEATURE_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index 38ca4f3baa..380461a054 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -13,6 +13,7 @@
 
 #include <public/version.h>
 
+#include <asm/cpufeature.h>
 #include <asm/early_printk.h>
 #include <asm/fixmap.h>
 #include <asm/sbi.h>
@@ -121,6 +122,8 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
         panic("Booting using ACPI isn't supported\n");
     }
 
+    riscv_fill_hwcap();
+
     printk("All set up\n");
 
     machine_halt();
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Wed Jan 15 16:38:22 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 16:38:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872812.1283836 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY6PO-0008JW-4S; Wed, 15 Jan 2025 16:38:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872812.1283836; Wed, 15 Jan 2025 16:38:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY6PO-0008JP-1X; Wed, 15 Jan 2025 16:38:22 +0000
Received: by outflank-mailman (input) for mailman id 872812;
 Wed, 15 Jan 2025 16:38:20 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=ppZO=UH=amd.com=Jason.Andryuk@srs-se1.protection.inumbo.net>)
 id 1tY6PM-0008JC-Ov
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 16:38:20 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20628.outbound.protection.outlook.com
 [2a01:111:f403:2417::628])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1fd4c370-d35f-11ef-a0e1-8be0dac302b0;
 Wed, 15 Jan 2025 17:38:19 +0100 (CET)
Received: from BN9PR03CA0039.namprd03.prod.outlook.com (2603:10b6:408:fb::14)
 by LV2PR12MB5893.namprd12.prod.outlook.com (2603:10b6:408:175::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8356.13; Wed, 15 Jan
 2025 16:38:12 +0000
Received: from BL02EPF0001A105.namprd05.prod.outlook.com
 (2603:10b6:408:fb:cafe::e9) by BN9PR03CA0039.outlook.office365.com
 (2603:10b6:408:fb::14) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.18 via Frontend Transport; Wed,
 15 Jan 2025 16:38:12 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BL02EPF0001A105.mail.protection.outlook.com (10.167.241.137) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8356.11 via Frontend Transport; Wed, 15 Jan 2025 16:38:12 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 15 Jan
 2025 10:38:11 -0600
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 15 Jan
 2025 10:38:11 -0600
Received: from [172.27.3.102] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Wed, 15 Jan 2025 10:38:10 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1fd4c370-d35f-11ef-a0e1-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=i/7NX37+dhNKPyqUQXTCRZ/4Hi0poI7w5lp+XG0J3nirTBypvcg3Kb5DDSH5KypUoYcegnP1L0GR45Yte+MkB5qMYkRnR5r75QF5ZD/9h7HkywDNG7FU+i/kom2gwckumWV2CEjAEszX9dWUD/wNMpmiunbZVqKu2A6pgTwfkV6frWugDoypx/u1yFZ3o3L9RmILeraLu13p8hY5Je3nG84fRr9Hzqx1dS8/GybSLpd8Egg11ZUqVLZt7gQHJ+2Ek1MRxi2eEOXzDTYzyDUeEe1byNz4GZZOILblQnE8If4KxF6kmaGtjvXvvZefxlA9FODbsELFPsgxNiC8W4ZOeQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=aUXXusSk24drhfYsuct6vcK2Za6M9r1k0aIHaTia3Wk=;
 b=UdvxvULq8KFZqwCPbamVnJA81Yq5f/BNbJkoHJiu4Qebx4rh+68v6vcDDBuO8Y84Sg/3VAKEAB44u86dpVqd93XOdSGDgjsnuzqiWv7gtGXg+5OA55vJ8vS/uXUMojdW2k15cP8LKDgVy35NjXu20+srdZbQigM3Il3gpgv4tWOx7uOUeqElQbTnalXWonGc5fisF6FOjfNkw9I9noLxRHonjlFOpOXywY6uuII51PiGbZBo0EmPiIcsJsaRe+r+00Jd5wRzxK+ePwWdyqNToC2D097wjGh65XQZKJbr4+T8+KZxgsiCPqI/fhMbsiwr/RBzbpQns8mgA6J/kcg4zw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=apertussolutions.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=aUXXusSk24drhfYsuct6vcK2Za6M9r1k0aIHaTia3Wk=;
 b=Ukj5cqRxbevJIsehS7X1jzP/NIforfysGfngMQlG11ouvgsjRFT4f1JhwJRUw+f4DlNEebiB+8rFa0wXU4TKwOT4pOQmLCOCLV+Q2ap7Uz4L2XUkHtJqAjERriTzKQTVxJYIRxvJGvTvLNv9Rs536kkH6tTDr7R9UbGVEahHDxU=
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: <ed6b3a99-a48a-4a8b-9028-dbb4012fe848@amd.com>
Date: Wed, 15 Jan 2025 11:38:10 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Jason Andryuk <jason.andryuk@amd.com>
Subject: Re: [PATCH v2 09/15] x86/hyperlaunch: obtain cmdline from device tree
To: "Daniel P. Smith" <dpsmith@apertussolutions.com>,
	<xen-devel@lists.xenproject.org>
CC: <christopher.w.clark@gmail.com>, <stefano.stabellini@amd.com>, Jan Beulich
	<jbeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand Marquis
	<bertrand.marquis@arm.com>, Michal Orzel <michal.orzel@amd.com>
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
 <20241226165740.29812-10-dpsmith@apertussolutions.com>
Content-Language: en-US
In-Reply-To: <20241226165740.29812-10-dpsmith@apertussolutions.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB05.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL02EPF0001A105:EE_|LV2PR12MB5893:EE_
X-MS-Office365-Filtering-Correlation-Id: 24d71e30-33bb-45ef-08e5-08dd35830096
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|82310400026|1800799024|36860700013|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?SzBVdnV5bldlejErRTIyeE9NTncvTkZyUG9YMGV1SFI4ZHFJQnczbm45bXE2?=
 =?utf-8?B?Zm4zNjVkOWNMNG01Mk85SzNGSjhDdEpZNjhJR0lSY1Y2Umc2bkg4RnBwTFgw?=
 =?utf-8?B?Lyt0N0FTS1lOcFNKUVRUWjVCeGpoRXlBUVJ5NzMyZ0gxV1owdUpZbERJeWw0?=
 =?utf-8?B?dXVxYStEaDYzb0U5bVEwS1NSUVlVL3FFREhDVEpuc2k2c0wzQkhlZEp2Z0VL?=
 =?utf-8?B?VCsrNlFKeU5GaTJyVmZoU1JCT0V3SWZtUENoN3dIM3JrNHFRSWtadUx4cHUw?=
 =?utf-8?B?MnBMY2FHQVR5c1lqVFNjMnRqV0N3dDdTbEJZaC9kTm9UYjNrOHdyamJBTEha?=
 =?utf-8?B?UEtVSm1VNFZzU3oybitEc2FUN1prbGVsYW15K2ZIbDRRdlJmMjI2UzZBMlhl?=
 =?utf-8?B?Sk1IaENhandVckg0MThBWmZaRk9Vc2d5OE15YWxQSEpqKzhZQi9CL29ORkRV?=
 =?utf-8?B?WGFua25UV2JjRGltL2J5ekpuL1VjL3AxN25BV04ra2w4OVRGS1hxb08yNkZU?=
 =?utf-8?B?LytSb1RNODcrVWt6WVQ4b0lKRjFjUWRZWDhrYUFDU1F1QTRGd0d4TDFLaDVB?=
 =?utf-8?B?RThBVEZndURoRzBKWEIxWVJIVlN3MHBzOEU3UEJkdUU2V3g4d3FKS1ErZ1Er?=
 =?utf-8?B?L0M3a3JaUlRkVnh4SHpjSWx3dUs5Q0t5bWl1MitqT0pxVDJ0bFZUdzRtZitz?=
 =?utf-8?B?RjUveU1abmVobURqejV3QzFsbG8vQkJnVGdNWUJMWUgyMDhNdURrdXlKNFNN?=
 =?utf-8?B?b0cySnY0WTZIOFRHNzNrVWlCT3g2c1lLWmdqRGkwUDdQb0o4dmkzUER2TWdL?=
 =?utf-8?B?SU9zWjBjV01ObDlmOU5naldKMjF3WEM5aXVWbGRrUzhqNldNQmRPYTdQazFq?=
 =?utf-8?B?alczQWhFREQwUGVSeG5FdjRCaGtnS1RzdmZtSUdseWxTNmJlWEQxdE5oV3N0?=
 =?utf-8?B?dGRWbmNWL3VGTkFGbWdLSDFnbks3V0lwWFRjekoybEdoenpQekxuS3hxMU1h?=
 =?utf-8?B?elJobUs4OUgrNE0zUDNwRjQ5eC9zK3lZYVlVMUE4QWM3WnR3VjNNOTBTaTV2?=
 =?utf-8?B?L1NmdlRrWU1YOUVhRG1WV3FFN3REakZ1RDFUM3htSHkyWW9PSmkzelhBM1hJ?=
 =?utf-8?B?Z01hV1JzSHNrMDIzYVhOYnJBLzdSQVZ2WEg5eWF6aTFmZGVGSDBIYXVDaWZ3?=
 =?utf-8?B?OG1SV1lWMnZOc1BhbHd5T3JreXV5bFVBL1AzclZ0TUNsV05uUFg5T0hoeHls?=
 =?utf-8?B?bkVlQzhaUUIzb0FSQ1pYWVBzaUZTTytKc2ZtQVVaUG5vUjl1bC9rZ0tDUEdt?=
 =?utf-8?B?anZGdHFwNlhJM2ZjWENjb2Y1TXhmWEE3SmtHOHdDZUtFbzNwVlBlMVlCUEJS?=
 =?utf-8?B?RDgycWpFbEMwaDd0OHFWMlNkakcvNHN1bkdnN0dpQXUzNEpnTC93cTZSQjdx?=
 =?utf-8?B?S2RQWmhvTktTY3hLRmR0WExxdUZBNlBMWHpIb3k3SFVnM09tVkgwc3k3cVZB?=
 =?utf-8?B?VjBSWGtPd243dmt4d1lxaFZQcjlIZjU1TEJKQnlJVExRRGJ1cmRBK0dJN05y?=
 =?utf-8?B?ZzE3RXB0OGNXM0lFZnhKVW9IR09iRitDUlltMFIyRVR2RVBWRW5ZMjhSdFY3?=
 =?utf-8?B?Sk5KSGRwOUFTUWlQc2VjTDV6cTNqVzZCWjU4bkdyRUZRR2xWK2NkaU9QVzdN?=
 =?utf-8?B?K21YU1pzdzZxVmVjOW8vMHFuSkl0NDQ2bGhTQll4T3NQVkZBWUMxNUdpcngz?=
 =?utf-8?B?QjdFWU1iaEFxRTYxZytJV3JUVWxHbk1EcTVSRjdBemsyWEV6ZlRmK3FiZlpv?=
 =?utf-8?B?YzNBN0FuZ1ZYemk3RW5HK3dyb09qT2x2V0dVRTgweUFZM3hOQml4c1c3VytF?=
 =?utf-8?B?YXMrQ1NqQUVJZnd3ZEVZbzNFa1RETDVWSXJ1Q3FqYVhJV0UxMGdYeUZGZzdN?=
 =?utf-8?B?VkludGl1TGlndFcyTHdOVitabzlXMEhBaGcvcVduemFrOHBOSmdCNWtlWGxn?=
 =?utf-8?Q?6jJuXvVQZ3v0tMDZzCgSRdJGdsglGA=3D?=
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:(13230040)(376014)(82310400026)(1800799024)(36860700013)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2025 16:38:12.2517
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 24d71e30-33bb-45ef-08e5-08dd35830096
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:
	BL02EPF0001A105.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV2PR12MB5893

On 2024-12-26 11:57, Daniel P. Smith wrote:
> If a command line is not provided through the bootloader's mechanism, e.g.
> muiltboot module string field, then use one from the device tree if present.
> The device tree command line is located in the bootargs property of the
> `multiboot,kernel` node.
> 
> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
> Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
> ---
> Changes since v1:
> - moved common fdt functions to libfdt
> - rename prop_as_offset to more correct prop_by_offset

> diff --git a/xen/include/xen/libfdt/libfdt-xen.h b/xen/include/xen/libfdt/libfdt-xen.h
> index 27d23df03af3..0e54aeeb6cc2 100644
> --- a/xen/include/xen/libfdt/libfdt-xen.h
> +++ b/xen/include/xen/libfdt/libfdt-xen.h
> @@ -28,6 +28,30 @@ static inline int __init fdt_cell_as_u64(const fdt32_t *cell, uint64_t *val)
>       return 0;
>   }
>   
> +static inline int __init fdt_get_prop_by_offset(

I think fdt_get_prop_offset() is a better name.  The point of this 
function is to return the offset in the fdt of the named property.  "by" 
or "as" confuses the purpose, at least to me.

Compare the existing fdt_get_property_by_offset() which is performing a 
property looking by consulting the offset.

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 16:44:14 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 16:44:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872857.1283847 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY6V0-0002RZ-Pm; Wed, 15 Jan 2025 16:44:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872857.1283847; Wed, 15 Jan 2025 16:44:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY6V0-0002RS-LX; Wed, 15 Jan 2025 16:44:10 +0000
Received: by outflank-mailman (input) for mailman id 872857;
 Wed, 15 Jan 2025 16:44:09 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=ppZO=UH=amd.com=Jason.Andryuk@srs-se1.protection.inumbo.net>)
 id 1tY6Uz-0002RM-SS
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 16:44:09 +0000
Received: from NAM02-SN1-obe.outbound.protection.outlook.com
 (mail-sn1nam02on20619.outbound.protection.outlook.com
 [2a01:111:f403:2406::619])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ef96ce88-d35f-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 17:44:07 +0100 (CET)
Received: from MW4PR04CA0192.namprd04.prod.outlook.com (2603:10b6:303:86::17)
 by DS0PR12MB7900.namprd12.prod.outlook.com (2603:10b6:8:14e::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8356.12; Wed, 15 Jan
 2025 16:44:02 +0000
Received: from MWH0EPF000989E6.namprd02.prod.outlook.com
 (2603:10b6:303:86:cafe::bc) by MW4PR04CA0192.outlook.office365.com
 (2603:10b6:303:86::17) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8356.13 via Frontend Transport; Wed,
 15 Jan 2025 16:44:02 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 MWH0EPF000989E6.mail.protection.outlook.com (10.167.241.133) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8356.11 via Frontend Transport; Wed, 15 Jan 2025 16:44:01 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 15 Jan
 2025 10:44:01 -0600
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 15 Jan
 2025 10:44:00 -0600
Received: from [172.27.3.102] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Wed, 15 Jan 2025 10:44:00 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ef96ce88-d35f-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=xQU4mGOhNS13pgpnG5yq9pC7o+IveirGuNnk+48phq8TMEsLhLEagS9HmcnH6mPxcqwdkQJd8mr715k8sFb3HHO0yecyhpAoczNNijkxfi3amAWuklFUC/NwBrBv59UUX1O/e367SvX3kzztKshPwGY6RDKYnj7JfuqGvRBE2jXPJMuEVrJOd5ejARLq1j8dXgDMwFYk5N0D+3Y6XJPMZRJYABlK66YlhdXj1DX424kwEF3Q9wNoeTXHSxRHVYK1PNkiHsIICxGpAzeCtFHjBZW4wqm26g0HmBoz+9M4Oa0Huca853JqYJLd1fLKbncpkm/eybECA8LeyXhzxMj80A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=Cko+wENQ4hiN1t9FapAtca+2BCIFrcWK1gLMVkYQU+s=;
 b=L3l74cDL8QA4c/Y587DAxm0eDkft0PassY1vRj8gKPwG+GRV5WthykwiUpaZI0etqoNLd3GPM4e7nJCV0Yx3az3S7O9hR/zHujOJAwZ4X1K7SBKcNSbHU9ozJL+rXr+SW8g7kLS2O8TrIlQvVA37CvxRE82mT+bQ1eil6BzxwzkGWVv2omPoUSl9aPHP4DAYvKreFaPs2cs/QF0x27n8zWDXa8zfzts7ZWf2Wzh1jV/pJT6n4wKPAHoxmSWO0i4TBibnXpvniwlzW3HSCdBvEjsnbbDOUTheRHnlXXwzxxY7luiQsQBDtRDK2RASytZaWHFODrsiR+T+bauKZe0y+g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=apertussolutions.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=Cko+wENQ4hiN1t9FapAtca+2BCIFrcWK1gLMVkYQU+s=;
 b=GlOshT3O+iEMCnFbdD1lijjXauTymwdUm0LEQpyBfTLgUTiWdz5jSSDh6n3aW2ysmhzPZQBZUAQKnI1Xm9mcd3JnwA5HoIbGeCJ6hi7TJSBjzhr3X8OBRRCnoPz+akBJn5bigo9uL3pPdfV4At6e8zcwkDuEbthJUJ9LQAihbEk=
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: <6a57fb93-5172-485e-b4e1-7c545aca871f@amd.com>
Date: Wed, 15 Jan 2025 11:43:54 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 10/15] x86/hyperlaunch: locate dom0 initrd with
 hyperlaunch
To: "Daniel P. Smith" <dpsmith@apertussolutions.com>,
	<xen-devel@lists.xenproject.org>
CC: <christopher.w.clark@gmail.com>, <stefano.stabellini@amd.com>, Jan Beulich
	<jbeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
 <20241226165740.29812-11-dpsmith@apertussolutions.com>
Content-Language: en-US
From: Jason Andryuk <jason.andryuk@amd.com>
In-Reply-To: <20241226165740.29812-11-dpsmith@apertussolutions.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB05.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MWH0EPF000989E6:EE_|DS0PR12MB7900:EE_
X-MS-Office365-Filtering-Correlation-Id: 7f52f5c6-2fb8-4047-0e62-08dd3583d0fc
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|36860700013|1800799024|376014|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?TXN0aHpjNDh2YVA1eDBiMENyZVViNm1DUWVrZjgwakZxb3JPbHdYckg5SjlU?=
 =?utf-8?B?dk1lS3RVeXJ4cTAzK2lsQjM0RG9ma2ZPbi9taElJYk9KQmZna0NwUlhQRWQv?=
 =?utf-8?B?S21RbjBUY2RZYis2Yy8wMWNkTGRIY0tEbWVIcHNCQm9DcWpzYmxHcnpXOTNF?=
 =?utf-8?B?ajVKeFM0U2szd3RFcVVCcHo4R05NNysxMUtrY0dncnE5NG13b245TlVhTURs?=
 =?utf-8?B?U3p6bEVVR1ZqS1JZWTlHajAybWZkY25YZVlpck9sZjNxU1FNdzhBZ1k0VmI5?=
 =?utf-8?B?OTJYR1ZHNktTZEdHa1JVRitGZlVuZGloMmt3UW13K3JNWXRUcnJ4MVZQYVhi?=
 =?utf-8?B?Z1p5ZXVrRERGZEZtOWdLMGtjRnpOQjZjSVNTVndaTVg0am5TVkIvbjR0OFhJ?=
 =?utf-8?B?d2t5TzV5R21QUjlSRnVKdE9hMTAzUVdHZ0t0aFFsd1U4akZwY290ZWpDQksw?=
 =?utf-8?B?RmJJMUhidURoRXlYamhwZWdlTGllRTFsRlN6cytJcXFaVVNlNGoxVFNKUVZB?=
 =?utf-8?B?NWZKTGdVNlF4aEFmRFVjaXN1YlRhOG5lbitJY1BaWFZVYW5EYTlEYWtERWxm?=
 =?utf-8?B?VUJBVzhFL0RDbEJnLzFJcTBqcElqbjFVME53cHdZU0NsYmFyU0dkWnpNSENV?=
 =?utf-8?B?cGF3Y0RNYUVMOXZPT0d6V2xPcS9EUVVYQjRlelp6dnBDbmdMU2x1MVI5WUlJ?=
 =?utf-8?B?RjZ4RkJ1RnVreW1MQTFkUXNlOTNrU20zenVLUE1yMEh2d0wvTUVIc2VIbEhQ?=
 =?utf-8?B?YVhuWVJrNmZiUnpxNEkyN25ROEdoQ0F3NndHeWZHSmJCOUx0bWpVN2NSTGE1?=
 =?utf-8?B?eEVGcTdIM1VWTmFBVG10bFNnUmR6ay8vdUsxY2tkMlN2QS9YeHVHZnpOakVZ?=
 =?utf-8?B?aEMyWGV1NVNOT1dWYzB4VXJKTnU5dGZ2MlptTXozaC9veWFJYWlZSHZWbllT?=
 =?utf-8?B?RHM4VjQyTTZiaHowSkU1bFg2eExEMnlFKzZqTzN3T2VDMkZudGhXSEptajRU?=
 =?utf-8?B?bWc5TGltRDNCODFGM3RKcDBqVHRGU0M2Y0FYdHhXSE12RnNCMS80NjRXSU9F?=
 =?utf-8?B?dTJ0YmtvVzRoTHNBZmRWZHNjQktxT1pWODNPNjBBSDE5SUtEb1NzbWNGNnpZ?=
 =?utf-8?B?MENWUjM5Uk51NFh6blNqSFZINlR6SDRVNmlnUzdjZHlIZUR5U1NMQ2NFR1Mv?=
 =?utf-8?B?NTkwZnpBYkJ1dFRNdDVDYnkrV2R2cm83TEM3cU81QWoyNHcwdW44RDl0RE9t?=
 =?utf-8?B?cTM1QnVMWlRYZmpsak5tU3Axa2ZmdzNRMk9IOE5FclpQTXVyeFRtYk1sVXpC?=
 =?utf-8?B?Q0J0b1kzZWRKK0hSMDNMOXFDYkphSU50VzVLVUYxTWFaeVpCQktNU0NPZ2h0?=
 =?utf-8?B?N2N0UU9JWHB4cGNQc1dvRkNSa1F3bWp3c2w5dDdTOE54RHh6eW01cS9IY3B4?=
 =?utf-8?B?WXdPYWpIYmtPVm9FblIzOXllVGhtY3N6cG80bDVka0V6elhkRGZQMjNOblN3?=
 =?utf-8?B?cUJTVmE5d0d2bzRCV2wyNUNleGhpK0Q1RHlGc1pwWnZwalNkeUdaV0plTWFM?=
 =?utf-8?B?M0FQWU95QjEza3RyYVd2NEtZMlBoSmx1VStoVHZxelVjRW5STTJtMFRCcVN0?=
 =?utf-8?B?RW91N1NaN3h0RzdxbC9vUDFsZDhUZTEyVVcva3Rkd1dWY1k4K1NwenJtWEtI?=
 =?utf-8?B?V2djQmcvckFJcEcxQUVzaXJpeFB1SXYySkdtajM4KzFPUHFnRjhCVGNyTVRv?=
 =?utf-8?B?MklsY1pqdWs4dzlFUFhNN1NuNUVKYmhER0IySnNTcG9OL2FLenJ3QlNRNmpH?=
 =?utf-8?B?d2FqRzlwcGJITktaN1U5bytaR0hOZHdlN082Wkl2dTN1UHFjNDd5Q25tdXZT?=
 =?utf-8?B?Rk5aNE1VdGd0UkNFK0oydW9hb2pCbmpHYXFIT0FvU05uZjhRRlg2dGloTGo4?=
 =?utf-8?B?RVVIeEgzS1VTOVB2UmRCS0owcGxORUtYZXNZM2tnS0NldWhycDA3RlNaZUVC?=
 =?utf-8?Q?ffNTP8S7udXWkyg1REzAEYLGTtxOAU=3D?=
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:(13230040)(82310400026)(36860700013)(1800799024)(376014)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2025 16:44:01.7927
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 7f52f5c6-2fb8-4047-0e62-08dd3583d0fc
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:
	MWH0EPF000989E6.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB7900

On 2024-12-26 11:57, Daniel P. Smith wrote:
> Look for a subnode of type `multiboot,ramdisk` within a domain node. If
> found, process the reg property for the MB1 module index.
> 
> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
> ---
> Changes since v1:
> - switch to nested else/if
> - dropped ternary name selection
> ---
>   xen/arch/x86/domain-builder/fdt.c | 26 +++++++++++++++++++++++
>   xen/arch/x86/setup.c              | 35 +++++++++++++++++--------------
>   2 files changed, 45 insertions(+), 16 deletions(-)
> 
> diff --git a/xen/arch/x86/domain-builder/fdt.c b/xen/arch/x86/domain-builder/fdt.c
> index 1094c8dc8838..27bc37ad45c9 100644
> --- a/xen/arch/x86/domain-builder/fdt.c
> +++ b/xen/arch/x86/domain-builder/fdt.c
> @@ -119,6 +119,32 @@ static int __init process_domain_node(
>                   if ( ret > 0 )
>                       bd->kernel->fdt_cmdline = true;
>               }
> +
> +            continue;
> +        }
> +        else if (
> +            fdt_node_check_compatible(fdt, node, "multiboot,ramdisk") == 0 )
> +        {
> +            int idx = dom0less_module_node(fdt, node, size_size, address_size);

Your next patch has the hl_module_index() parsing you want moved into 
this patch.

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 16:44:26 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 16:44:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872860.1283857 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY6VF-0002lh-W0; Wed, 15 Jan 2025 16:44:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872860.1283857; Wed, 15 Jan 2025 16:44:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY6VF-0002la-T1; Wed, 15 Jan 2025 16:44:25 +0000
Received: by outflank-mailman (input) for mailman id 872860;
 Wed, 15 Jan 2025 16:44:25 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <anthony@xenproject.org>) id 1tY6VF-0002lI-2C
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 16:44:25 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <anthony@xenproject.org>) id 1tY6V5-0065vB-1a;
 Wed, 15 Jan 2025 16:44:15 +0000
Received: from [2a01:e0a:1da:8420:b77:bd5:6e45:7633] (helo=l14)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from <anthony@xenproject.org>) id 1tY6V5-006iNM-1O;
 Wed, 15 Jan 2025 16:44:15 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding:
	Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date;
	bh=SMDQ4zCFk0wf00K4czERKQpp4UcFPfCXWNTi2lvuzbE=; b=dwpgvUrbPKs+KkSUi/d15INanp
	hhHvqdXX6LMeyBQZzrjsT1YJuuYeAhYmfGTwFpif8Yvtc/aXGcPZLNTBwznJ62mLSiHpHraWqTb8I
	LB97K7NSQoBwu4ARGVZkW+8RPao4zvCTTCGE80J92xQEOmWOuR5MYysQQ6YydsPzGFq0=;
Date: Wed, 15 Jan 2025 17:44:13 +0100
From: Anthony PERARD <anthony@xenproject.org>
To: David Woodhouse <dwmw2@infradead.org>
Cc: qemu-devel@nongnu.org,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Kevin Wolf <kwolf@redhat.com>, Hanna Reitz <hreitz@redhat.com>,
	=?iso-8859-1?Q?Marc-Andr=E9?= Lureau <marcandre.lureau@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Jason Wang <jasowang@redhat.com>, xen-devel@lists.xenproject.org,
	qemu-block@nongnu.org
Subject: Re: [PATCH v3 1/7] hw/xen: Add xs_node_read() helper function
Message-ID: <Z4fl3ZeDyOr1wZNw@l14>
References: <20250115163542.291424-1-dwmw2@infradead.org>
 <20250115163542.291424-2-dwmw2@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250115163542.291424-2-dwmw2@infradead.org>

On Wed, Jan 15, 2025 at 04:27:19PM +0000, David Woodhouse wrote:
> From: David Woodhouse <dwmw@amazon.co.uk>
> 
> This returns the full contents of the node, having created the node path
> from the printf-style format string provided in its arguments.
> 
> This will save various callers from having to do so for themselves (and
> from using xs_node_scanf() with the non-portable %ms format string.
> 
> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
> [remove double newline and constify trace parameters]
> Signed-off-by: Roger Pau Monn� <roger.pau@citrix.com>

Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 16:45:13 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 16:45:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872872.1283867 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY6W1-0003Qm-6t; Wed, 15 Jan 2025 16:45:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872872.1283867; Wed, 15 Jan 2025 16:45:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY6W1-0003Qd-48; Wed, 15 Jan 2025 16:45:13 +0000
Received: by outflank-mailman (input) for mailman id 872872;
 Wed, 15 Jan 2025 16:45:11 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <anthony@xenproject.org>) id 1tY6Vz-0003QO-RB
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 16:45:11 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <anthony@xenproject.org>) id 1tY6Vt-0065wR-1g;
 Wed, 15 Jan 2025 16:45:05 +0000
Received: from [2a01:e0a:1da:8420:b77:bd5:6e45:7633] (helo=l14)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from <anthony@xenproject.org>) id 1tY6Vt-006iO1-1e;
 Wed, 15 Jan 2025 16:45:05 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding:
	Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date;
	bh=mE4R8+YTkUIJeVfdLLew/uk/d+X6/7I/F+ktrfhdB34=; b=hycstYFjE+x9opHmSL+Hw+dL1k
	Cf9dDsO5u8RWbhp5/o9R61t5i10CALhnKICc04e+uQp1KRmynCawCifCrIqculUPlcL6WBl7/40qa
	JAzMp3npCKhlPmQMB7aqgcRlaNYvYlGB8kx6SeSxIGpw2OMXlNQL3emr9mjpeY2PDs+A=;
Date: Wed, 15 Jan 2025 17:45:03 +0100
From: Anthony PERARD <anthony@xenproject.org>
To: David Woodhouse <dwmw2@infradead.org>
Cc: qemu-devel@nongnu.org,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Kevin Wolf <kwolf@redhat.com>, Hanna Reitz <hreitz@redhat.com>,
	=?iso-8859-1?Q?Marc-Andr=E9?= Lureau <marcandre.lureau@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Jason Wang <jasowang@redhat.com>, xen-devel@lists.xenproject.org,
	qemu-block@nongnu.org
Subject: Re: [PATCH v3 2/7] xen: do not use '%ms' scanf specifier
Message-ID: <Z4fmD4UZPcSdfEE8@l14>
References: <20250115163542.291424-1-dwmw2@infradead.org>
 <20250115163542.291424-3-dwmw2@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250115163542.291424-3-dwmw2@infradead.org>

On Wed, Jan 15, 2025 at 04:27:20PM +0000, David Woodhouse wrote:
> From: Roger Pau Monne <roger.pau@citrix.com>
> 
> The 'm' parameter used to request auto-allocation of the destination variable
> is not supported on FreeBSD, and as such leads to failures to parse.
> 
> What's more, the current usage of '%ms' with xs_node_scanf() is pointless, as
> it just leads to a double allocation of the same string.  Instead use
> xs_node_read() to read the whole xenstore node.
> 
> Fixes: a783f8ad4ec9 ('xen: add a mechanism to automatically create XenDevice-s...')
> Fixes: 9b7737469080 ('hw/xen: update Xen console to XenDevice model')
> Signed-off-by: Roger Pau Monn� <roger.pau@citrix.com>
> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>

Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 16:46:26 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 16:46:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872879.1283877 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY6XB-0003zv-Hw; Wed, 15 Jan 2025 16:46:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872879.1283877; Wed, 15 Jan 2025 16:46:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY6XB-0003zo-EI; Wed, 15 Jan 2025 16:46:25 +0000
Received: by outflank-mailman (input) for mailman id 872879;
 Wed, 15 Jan 2025 16:46:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=hmQ5=UH=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tY6X9-0003zO-HI
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 16:46:23 +0000
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
 [2a00:1450:4864:20::52e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3fe74697-d360-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 17:46:21 +0100 (CET)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-5d4e2aa7ea9so13830814a12.2
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 08:46:21 -0800 (PST)
Received: from [10.81.35.177] ([46.149.103.9])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d99046a195sm7385437a12.57.2025.01.15.08.46.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 15 Jan 2025 08:46:20 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 3fe74697-d360-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736959581; x=1737564381; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=jfVZOgROECUa2tEcjDX9j+CT/akKl22KV7shucLuS+o=;
        b=jBPNXPXJGJauaJT75t05N2GPAqgwUg0uqBwkTf9N9HeliQP40pptpNNGT9heB3oxE2
         uQkcjiJQhK+fYubfGKy/KAMdfKBnEQc9wAelCG4MauYDDRzdyI94+KAKPbMjbaQwJFvd
         APeg6e9caMdJuUhiomoQM2JujDgvaCADkPPPE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736959581; x=1737564381;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=jfVZOgROECUa2tEcjDX9j+CT/akKl22KV7shucLuS+o=;
        b=Y/PNpywE4wu99hfF/q0RM82DF3S9O2hoh7glJ8/LcxwbFN8wQjd68MxPSvMb/fdpwe
         0eXBETI5doYRh4i4XD/ol3pSTMLx8f90de79sM2cSm5GeropV4LYt/SzdLS4RnL5aS2P
         kHPWxZ6lIsKeQ/fKn+Iq383xWluGDjPBgImGwIEGCNaWtOVZ0AtbHLYl2TYQm8/AEzsG
         IPz6SC+YbvR9ODa9zhT+mzy7y5bq16rmV8Qa722InOeA9L0ciS4eqCoU36GS8c256C9A
         WUNpPjun/EzvvKIDenAdh11MKwgleXWbX9UEEzhJQpZ9Boxawe20LlKZWSwwyD28CL+6
         Xq7g==
X-Forwarded-Encrypted: i=1; AJvYcCVYAuu0TMYo6VIw8WehW+w9JQwLgyRG4FnfQFTwTo1KDE8Gb1YftwO95Whb4psPYHh2TmwmEe9+U6s=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwAIXPI11IEFfCH/dASOcN5X8DDFvA5wiA2mL3U23W70dhw8rwa
	yIRKWeTpP1UH2Pcq7No5cBuv9jHTMInP3XIDhXP5aDGE2WJ3cJcon85r+jBvdro=
X-Gm-Gg: ASbGnctKovo9gKzHAvb6qcwTyB5VHoX1U8rjlXEmvxsR3hWmjInMtlzXd4vZFV9u3fn
	2DUsSpzs6BTounQL5UTmG99L+Sgx647Y/kczqSNNZTxnQReR2A9qxsUOHW68Tb6d19HvqvxLPZv
	RLCOBHavAIm3CIImygsYfjgti7R21+r/xEQ8lJY74blLIRKEMerlLKfYhNdoWiv4TeVyeeIdWqy
	VU4trE6N77kqg0cOduG+dnubp7cp7OqxyHvRj7vR/vfVdyp86w12dvX4391fNCClw==
X-Google-Smtp-Source: AGHT+IG9fwelL/D1La5pjNNAMd5O1WUger0zgOHHaIfFhCoUhFkGEau2NPSm8M/aLbMcdXbqStHbhg==
X-Received: by 2002:a05:6402:254b:b0:5d8:a46f:110b with SMTP id 4fb4d7f45d1cf-5d972e17033mr29190036a12.17.1736959580989;
        Wed, 15 Jan 2025 08:46:20 -0800 (PST)
Message-ID: <43161e04-a32e-4ef5-a310-84b7bfc9d50d@citrix.com>
Date: Wed, 15 Jan 2025 16:46:19 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/7] xen: do not use '%ms' scanf specifier
To: David Woodhouse <dwmw2@infradead.org>, qemu-devel@nongnu.org,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony@xenproject.org>, Paul Durrant <paul@xen.org>,
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>, Kevin Wolf
 <kwolf@redhat.com>, Hanna Reitz <hreitz@redhat.com>,
 =?UTF-8?Q?Marc-Andr=C3=A9_Lureau?= <marcandre.lureau@redhat.com>,
 Paolo Bonzini <pbonzini@redhat.com>, Jason Wang <jasowang@redhat.com>,
 xen-devel@lists.xenproject.org, qemu-block@nongnu.org
References: <20250115163542.291424-1-dwmw2@infradead.org>
 <20250115163542.291424-3-dwmw2@infradead.org>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <20250115163542.291424-3-dwmw2@infradead.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15/01/2025 4:27 pm, David Woodhouse wrote:
> diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c
> index adfc4efad0..85b92cded4 100644
> --- a/hw/xen/xen-bus.c
> +++ b/hw/xen/xen-bus.c
> @@ -650,6 +650,16 @@ int xen_device_frontend_scanf(XenDevice *xendev, const char *key,
>      return rc;
>  }
>  
> +char *xen_device_frontend_read(XenDevice *xendev, const char *key)
> +{
> +    XenBus *xenbus = XEN_BUS(qdev_get_parent_bus(DEVICE(xendev)));
> +
> +    g_assert(xenbus->xsh);
> +
> +    return xs_node_read(xenbus->xsh, XBT_NULL, NULL, NULL, "%s/%s",
> +                        xendev->frontend_path, key);;

Double ;;

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 16:49:46 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 16:49:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872894.1283887 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY6aL-0004e2-44; Wed, 15 Jan 2025 16:49:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872894.1283887; Wed, 15 Jan 2025 16:49:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY6aL-0004dv-0m; Wed, 15 Jan 2025 16:49:41 +0000
Received: by outflank-mailman (input) for mailman id 872894;
 Wed, 15 Jan 2025 16:49:39 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=4o+i=UH=cloud.com=bernhard.kaindl@srs-se1.protection.inumbo.net>)
 id 1tY6aJ-0004dp-Lg
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 16:49:39 +0000
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [2a00:1450:4864:20::529])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b4e9a9b8-d360-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 17:49:37 +0100 (CET)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-5da135d3162so1277047a12.3
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 08:49:37 -0800 (PST)
Received: from localhost ([185.68.248.203]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d99008c523sm7695114a12.8.2025.01.15.08.49.35
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 15 Jan 2025 08:49:35 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b4e9a9b8-d360-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736959777; x=1737564577; 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=5pRNe8wbi9tZ0aom2g5sJEKlIHFZvI7gb4bs1jk9GL8=;
        b=Q+kl4iFOw4uVhiwa61N7mgIp9kG1X2qSS5JNxYMex32/0UO8+mUQjbEz6xyIScHoWv
         WGbfGPiWUA6QUV4c8VQhqJhvldbIsukQ46dbhDzMToYixi1hR11lFpkIOpT830Vz1tg+
         /9IwKvA7xwcCDgiHAYLPVN2lcF365Fd4rxI9A=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736959777; x=1737564577;
        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=5pRNe8wbi9tZ0aom2g5sJEKlIHFZvI7gb4bs1jk9GL8=;
        b=FaYwwji+n2vRfiYiS6mEWq1MB9OpyBcXfePdI29IIFkdJ+UmBJX6Rkl4TN9Kcvw/NW
         3qdM7hBmqhkr2vPul2ljsKCsIZfZujJanruxl2IFgrGfaqOWKhKqychK8QYAz9SHJ/Yh
         fH0Z4SK6ZOmZOqf+Tsl77B3rWV1HqkDnEKvoIlFXvf2v/ICEZH+WEC6m3aE0uJ3rIfMb
         EPH7THU/9BiccZ5ZnI+dbRoMxLKDNahI4VKeXdNtOOAyk4vDvB1w/Wg6GNPXVNlTmVnW
         6SGmgutVwKf75vO0gvxThoZedxTWoVDsQG5tguCPpI+KwG+X91jQvsp63x0zde/tYwxH
         TUFw==
X-Gm-Message-State: AOJu0YwB5aY1NspS1RdzXDeWMN15j9wV+Bhkfor7n8DJWIYg9An0HEPg
	R4/X0cZF/9vm3RgHnFaDqP/QGQt8lqnkMl5ogLTtw/AEmNQzwQG/FWekJo98zPmrcOylzt7MuAI
	NK76aCA==
X-Gm-Gg: ASbGnctr4hr714tTbfI3uOT+xCfrybmq9JbzwmthAQ3t1d8jdUXba0kD7y/VtgpHrO4
	6sPhkLwPNotuDRrCZyTXBC5YUBhWashMnpXwk7eSG347VXOTW6iuq6QW64QDou8jMyKIQLioByi
	SaGlWlKZDtG5jwoJiNB9Tr3Zz05H5rhDhPUEPAgba//xUrpW28XLy6nE7/XvrwsbHIK7sOLfzhf
	wJae6jJtBbAoLsLGrMJIMOHNl724aPGRfpzYLDyy3u5kRXDdtm3zhX0HJQ67w==
X-Google-Smtp-Source: AGHT+IGFhYGLOGx+UEZg9b6vDmOlXgVAdHkfCiSIaunmxo/b1LC9C0Nj3yPvU3hrP2S1tiSZTo3qpQ==
X-Received: by 2002:a05:6402:3514:b0:5da:105b:86c2 with SMTP id 4fb4d7f45d1cf-5da105b87d5mr2107346a12.20.1736959777044;
        Wed, 15 Jan 2025 08:49:37 -0800 (PST)
From: Bernhard Kaindl <bernhard.kaindl@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Bernhard Kaindl <bernhard.kaindl@cloud.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH] docs: Fix spaces and capitalisation of proper nouns and abbreviations
Date: Wed, 15 Jan 2025 17:49:32 +0100
Message-ID: <cf18d0a24e393191ec243bb67aecfd7631429576.1736959522.git.bernhard.kaindl@cloud.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Signed-off-by: Bernhard Kaindl <bernhard.kaindl@cloud.com>
---
 SUPPORT.md                       | 18 +++++++++---------
 docs/designs/qemu-deprivilege.md |  2 +-
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/SUPPORT.md b/SUPPORT.md
index 2bc5bd81ee..9478b70b1b 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -258,7 +258,7 @@ Go (golang) bindings for libxl
 
 ### Linux device model stubdomains
 
-Support for running qemu-xen device model in a linux stubdomain.
+Support for running the qemu-xen device model in a Linux stubdomain.
 
     Status: Tech Preview
 
@@ -626,7 +626,7 @@ Guest-side driver capable of speaking the Xen 9pfs protocol
 
 ### PVCalls (frontend)
 
-Guest-side driver capable of making pv system calls
+Guest-side driver capable of making PV system calls
 
     Status, Linux: Tech Preview
 
@@ -1060,8 +1060,8 @@ This file contains prose, and machine-readable fragments.
 The data in a machine-readable fragment relate to
 the section and subsection in which it is found.
 
-The file is in markdown format.
-The machine-readable fragments are markdown literals
+The file is in Markdown format.
+The machine-readable fragments are Markdown literals
 containing RFC-822-like (deb822-like) data.
 
 In each case, descriptions which expand on the name of a feature as
@@ -1125,7 +1125,7 @@ in such a case this feature may be described as "Stable / Interface not stable".
 
 Does it behave like a fully functional feature?
 Does it work on all expected platforms,
-or does it only work for a very specific sub-case?
+or does it only work for a very specific subcase?
 Does it have a sensible UI,
 or do you have to have a deep understanding of the internals
 to get it to work properly?
@@ -1168,7 +1168,7 @@ will they still work when I upgrade to the next version?
 
   * **Stable**
 
-    We will try very hard to avoid breaking backwards  compatibility,
+    We will try very hard to avoid breaking backwards compatibility,
     and to fix any regressions that are reported.
 
 ### Security supported
@@ -1200,7 +1200,7 @@ are given the following labels:
   * **Supported, Security support external**
 
     This feature is security supported
-    by a different organization (not the XenProject).
+    by a different organization (not the Xen Project).
     The extent of support is defined by that organization.
     It might be limited, e.g. like described in **Supported, with caveats**
     below.
@@ -1221,8 +1221,8 @@ Some features are only for HVM guests; some don't work with migration, &c.
 
 ### External security support
 
-The XenProject security team
-provides security support for XenProject projects.
+The Xen Project security team
+provides security support for the various projects of the Xen Project.
 
 We also provide security support for Xen-related code in Linux,
 which is an external project but doesn't have its own security process.
diff --git a/docs/designs/qemu-deprivilege.md b/docs/designs/qemu-deprivilege.md
index 603491f24d..3be33adf6a 100644
--- a/docs/designs/qemu-deprivilege.md
+++ b/docs/designs/qemu-deprivilege.md
@@ -297,7 +297,7 @@ namespaces):
     unshare(CLONE_NEWNET);
 
 QEMU does actually use the network namespace as a Xen DM for two
-purposes: 1) To set up network tap devices 2) To open vnc connections.
+purposes: 1) To set up network tap devices 2) To open VNC connections.
 
 #### Network
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Jan 15 16:49:46 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 16:49:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872895.1283897 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY6aQ-0004ue-Br; Wed, 15 Jan 2025 16:49:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872895.1283897; Wed, 15 Jan 2025 16:49:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY6aQ-0004uX-8o; Wed, 15 Jan 2025 16:49:46 +0000
Received: by outflank-mailman (input) for mailman id 872895;
 Wed, 15 Jan 2025 16:49:45 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <anthony@xenproject.org>) id 1tY6aP-0004tm-3Q
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 16:49:45 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <anthony@xenproject.org>) id 1tY6aJ-00666Q-2D;
 Wed, 15 Jan 2025 16:49:39 +0000
Received: from [2a01:e0a:1da:8420:b77:bd5:6e45:7633] (helo=l14)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from <anthony@xenproject.org>) id 1tY6aJ-006iXJ-2B;
 Wed, 15 Jan 2025 16:49:39 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:
	References:Message-ID:Subject:Cc:To:From:Date;
	bh=giFZVBXvBz5ocUI8W7ZNYz1JX4g1+Rv5di62MVhfyX0=; b=YNYy+BDsm6/M7B/b0tosWcIXKC
	WK7Btz8FRB1hHViajVZHZPyqAFTJEtuiOtLQUlQsZKgKtjh3kYm4T+dVaIKBoW7l9BF/F/aoTp+SY
	9KoQ5g0mtUCo1n8wA6+r+xPqpfYbLGYC5dnF4yvkKFtC0wF35YTO2O4tdA7EymioQ4LY=;
Date: Wed, 15 Jan 2025 17:49:37 +0100
From: Anthony PERARD <anthony@xenproject.org>
To: David Woodhouse <dwmw2@infradead.org>
Cc: qemu-devel@nongnu.org,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Kevin Wolf <kwolf@redhat.com>, Hanna Reitz <hreitz@redhat.com>,
	=?iso-8859-1?Q?Marc-Andr=E9?= Lureau <marcandre.lureau@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Jason Wang <jasowang@redhat.com>, xen-devel@lists.xenproject.org,
	qemu-block@nongnu.org
Subject: Re: [PATCH v3 7/7] hw/xen: Fix errp handling in xen_console
Message-ID: <Z4fnIQ8YbTP_i0U9@l14>
References: <20250115163542.291424-1-dwmw2@infradead.org>
 <20250115163542.291424-8-dwmw2@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250115163542.291424-8-dwmw2@infradead.org>

On Wed, Jan 15, 2025 at 04:27:25PM +0000, David Woodhouse wrote:
> diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
> index e61902461b..9e7f6da343 100644
> --- a/hw/char/xen_console.c
> +++ b/hw/char/xen_console.c
> @@ -581,19 +581,27 @@ static void xen_console_device_create(XenBackendInstance *backend,
>                         output);
>              goto fail;
>          }
> -    } else if (number) {
> -        cd = serial_hd(number);
> -        if (!cd) {
> -            error_prepend(errp, "console: No serial device #%ld found: ",
> -                          number);
> -            goto fail;
> -        }
> +    } else if (errno != ENOENT) {
> +        error_prepend(errp, "console: No valid chardev found: ");
> +        goto fail;
>      } else {
> -        /* No 'output' node on primary console: use null. */
> -        cd = qemu_chr_new(label, "null", NULL);
> -        if (!cd) {
> -            error_setg(errp, "console: failed to create null device");
> -            goto fail;
> +        if (errp) {

I don't think you need this check, with ERRP_GUARD() macro `errp` is
never NULL.

> +            error_free(*errp);

After this, I think you still need
    *errp = NULL;

> +        }
> +        if (number) {
> +            cd = serial_hd(number);
> +            if (!cd) {
> +                error_setg(errp, "console: No serial device #%ld found: ",

That error message doesn't need the ": " at the end anymore.

With those fixed: Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>

Cheers,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 16:56:04 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 16:56:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872912.1283906 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY6gR-0007ma-VJ; Wed, 15 Jan 2025 16:55:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872912.1283906; Wed, 15 Jan 2025 16:55:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY6gR-0007mT-Sh; Wed, 15 Jan 2025 16:55:59 +0000
Received: by outflank-mailman (input) for mailman id 872912;
 Wed, 15 Jan 2025 16:55: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
 <SRS0=ppZO=UH=amd.com=Jason.Andryuk@srs-se1.protection.inumbo.net>)
 id 1tY6gR-0007mH-20
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 16:55:59 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on2061e.outbound.protection.outlook.com
 [2a01:111:f403:2413::61e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 91335e55-d361-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 17:55:48 +0100 (CET)
Received: from PH8PR21CA0015.namprd21.prod.outlook.com (2603:10b6:510:2ce::12)
 by CH2PR12MB9460.namprd12.prod.outlook.com (2603:10b6:610:27f::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8356.13; Wed, 15 Jan
 2025 16:55:44 +0000
Received: from SJ1PEPF00001CE0.namprd05.prod.outlook.com
 (2603:10b6:510:2ce:cafe::3b) by PH8PR21CA0015.outlook.office365.com
 (2603:10b6:510:2ce::12) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8356.8 via Frontend Transport; Wed,
 15 Jan 2025 16:55:43 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SJ1PEPF00001CE0.mail.protection.outlook.com (10.167.242.8) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8356.11 via Frontend Transport; Wed, 15 Jan 2025 16:55:43 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 15 Jan
 2025 10:55:42 -0600
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 15 Jan
 2025 10:55:42 -0600
Received: from [172.27.3.102] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Wed, 15 Jan 2025 10:55:41 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 91335e55-d361-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=cU6yn63JYUT2lhDwqiDcDqh06TD+gVaCAGsjiDctryCjXujfM2CH5dN6zl3ESkcUMdNyYpb1kRPOGaF1cHwaAuHj4IqKy91FQZGlwOZYg0ACq15p8CGXNjPx2qCnztm2WlaXe45z8iejQq3uIOC/sCOdu2kF3R/OHzl9Ky6lCYTAzIKH5/VvuGiXBYVjmAL4ykGeTgGyCRmYis7KM6CjWVGuHOph7TGtWpLZZmW4a5T9VTKXvh+x+dMo5/CoAF/G5KpyniyV6pFq2BrzPDCEw/agtBpek9eVpZ0jkZaWJJJ8y7FckjPVdudrg86BcYtFWSC+7AXjRibO5y0jFiEipQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=B0PKYXo3UQpMtUn9vNyPhmzpYAnpUNlYmbDApzfUiow=;
 b=H+oAPymXIeohUBVJrO5XFEl/QfqSC0jxcgBvz6OqmdZo4Zc5IPlSpEufAeZfyQr6Fo1y15L5iABOelBucto1PhDxMp2IKMwxl19c3N0sn9B59sIh55eOtG2me1YdCNCF5mdMSwIHhxB0qIcqzUlflJDIAjGVhyydUuQeiYPFDGzcmwMFLIS6xoOiaYcYYLEVWM7efTdDrasNJlQmImdYYpNiGJ961too5Y10OB+4urJn9q8ylNR3Xr8aUpHhjs5H6jxy+ynhQ+vFKIxoWM+a0N9VWPcSpV3hghdqeFwmcGP8oRbv95m9EBStg2Ox/VIuIY6nVrUlX/etG2lXizjKOQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=apertussolutions.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=B0PKYXo3UQpMtUn9vNyPhmzpYAnpUNlYmbDApzfUiow=;
 b=GInGRGM22YtHJm3mhlASjtOW9HSVnTcnvCm0usSXYh03QDKEf+ILDX/Yuf7QGvrMP61wWJqRVhTxabWYOgWe1xpgRPB/m2LH4Rs/7/8zD4sPKhG+KPPgXV71IlrZ6vcIENrfdHHI4S8Dg7yrv24J55w2DEgC+apHnutgmA+PpIQ=
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: <7aa994e5-2878-4dd0-ab2b-349dff44b478@amd.com>
Date: Wed, 15 Jan 2025 11:55:40 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 13/15] x86/hyperlaunch: add memory parsing to domain
 config
To: "Daniel P. Smith" <dpsmith@apertussolutions.com>,
	<xen-devel@lists.xenproject.org>
CC: <christopher.w.clark@gmail.com>, <stefano.stabellini@amd.com>, Jan Beulich
	<jbeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand Marquis
	<bertrand.marquis@arm.com>, Michal Orzel <michal.orzel@amd.com>
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
 <20241226165740.29812-14-dpsmith@apertussolutions.com>
Content-Language: en-US
From: Jason Andryuk <jason.andryuk@amd.com>
In-Reply-To: <20241226165740.29812-14-dpsmith@apertussolutions.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB05.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF00001CE0:EE_|CH2PR12MB9460:EE_
X-MS-Office365-Filtering-Correlation-Id: 8f748009-66ee-49fe-0245-08dd3585735d
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|1800799024|36860700013|82310400026|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?NkJ4SU0xb3hUUjQ1RDNZVDQ0eTRpbEN0MzBocFZhZVNJVEhQZkVPeEVtWm9m?=
 =?utf-8?B?N3dZSEZMU1EwUmFELzZmbnZ1cmdEdDQzSEh6MEtLRWNxQWVacjh4STFEcThq?=
 =?utf-8?B?dVhSbGQ4MlZhRkJLcGdJTlB6MC9xUXNpOWwxVzF4c3IwOWF4dEwvWWNNdVFk?=
 =?utf-8?B?K1ZEdkxUY04wcUlNVk5WbXVwN0l2cVFCWEk3RkxMbVBIVWZydTRSQit3YmR2?=
 =?utf-8?B?MmwxL1VtTnhVcHZrSlJTZnJyLzFxcHBBdVQ2YVZWeitHWlA0L3l5UDlkdlpn?=
 =?utf-8?B?Z3BDSzJldVhBTU5VTkZhOWl4QXV2a3oxdnl6WEU5dTFoeVA5V01pUGhFWWFs?=
 =?utf-8?B?ZFAzYVB0bmZBWlRQcWdqbHRQcER0by9MT2N3aS9BK1RLM0FMOUFmbEJnazAv?=
 =?utf-8?B?SXp5VUU3S1hob0REbkt4Z1V3NGZmNU50aE12dkRLT3JDSjQxWVNMNWZWZU5n?=
 =?utf-8?B?TGYyS1RpRThMZmpMQ2hBbEFkMkpyVCtGV29LaTIyRmpreTNQcVlPTXVEUlha?=
 =?utf-8?B?SzN4Rmp4akJoR1lpS2M0Q053dnRJVSs2bGN3MTZTNjZQeXNJTVAwV2hFNXcx?=
 =?utf-8?B?MDJNMFFwK21BTEN2YWlpM2RuMzZLdThoczVMQW1vYVhOOWIwTzNuU0M4WkhB?=
 =?utf-8?B?MEJ2bjN3TnNlMXkwcERjcE5rQnJyREpROVJyNVZhZ0xYd1Z0NmJlTkc2WFg1?=
 =?utf-8?B?WkJqdXdOZHJTbGh1T2toS3lQWFA1c3ZHOE1vcWQzdzVQc2lHTm1LbjErWVRH?=
 =?utf-8?B?eXRYaFMybzJtSnY5d1hQaTdadTBtditRcHVYcnJpdVJGcTZTcjV6SzRDYTg0?=
 =?utf-8?B?N0xYempuWVNoVWo1bVNabTlEc3ZTUldrdkduUUhMUnJtVFNHaklhMTJMbllm?=
 =?utf-8?B?SzBQMFd6bk5DTUIzcndrR2FkdG81TW5EWSsrdjBNb2VwT28vbnE5S2NhSm1s?=
 =?utf-8?B?MUErbnQwVUhyK2dYZHBDdFpncVNhb2hqTWtvdmswNTZiSVZtYkVIME9wQyt1?=
 =?utf-8?B?aWVSbjJPcGdMYkt6dkdqRzltK21rVXhZNjIwSGJHV0p6TFVVNmlIdXBIYzAr?=
 =?utf-8?B?WWJnWkYwSFlkZEh0TDE0RGVSREEzY3h5KzRueGdCZWtpbEVyNks3eUZlb3RC?=
 =?utf-8?B?b0FnWFBSK3poSFlCdkFzNCtUbWVTNDdXYjBEUDlCTDRnczVnNXFRVGo0WGJI?=
 =?utf-8?B?MENwaVJkSWZIanJacmI1YmpDSGxRdW9pc0pJOXNhOGFGZWxocE9DckZBUURJ?=
 =?utf-8?B?V2lZSjVyaHdZNEZHUFJ0N0NzV1RseFFESng3Y1lmVUd2dU1yZEZSTERyYWNX?=
 =?utf-8?B?T3JYdHpHRDVpRjJBS3REODlCRm16UU53RnMzY3k5ZDM2VmRuRXZ0czJ5S1pR?=
 =?utf-8?B?ajhiL0lJc0diblREUy80WGQrZjFWS1hsNDh1NEVSR2FTZUE2bnBuNXJPbU54?=
 =?utf-8?B?NGpTcnVQVmN1UFZocW5iUGx5RHFGT3FwdjkyNU8vWGNoTTY2UHFUbkJmV1pN?=
 =?utf-8?B?UnVTcDlsaXYyTFpxQnBuTFpWUC9WVE5iVC9CemtHbVVmSTY0NXZwc3FKVVRU?=
 =?utf-8?B?Qytqc0VjcmJNbFhnMDQ3VW9TQ1FQZ1hqSUdOcXg0RkpUS3VWMGF4eUpoL2p2?=
 =?utf-8?B?eTczUFVCd2Vib3F6T2Q2TXdNSmpvVkdBS0NyVi9QTnVDNHRXSEpsMmtHbUpp?=
 =?utf-8?B?cCt6SXUyMzNKZ0M3QzZMZHV2ZjRqY0kxbEMxYVhkT05XVVNKK2ZuSkV3WEcv?=
 =?utf-8?B?ckQ0L0s5RE5ISU5UV2J5WlIwQmNqcU9xYjJ2cWoyclliTE9IMjZZdUFuRGMv?=
 =?utf-8?B?TC95ZXpvelgrR3k3MnRQS3VaRmsreWRMSjh5VmZQNzJRU21teXNQeGpoNkpW?=
 =?utf-8?B?VUpSZU90cmx3SkdoQ2NnKzJtbW1ac2xaUS9vU2VTN0tDMHVsWGUwNi9RWCt1?=
 =?utf-8?B?MjlaT3k3L2w5ODJmdVE3TC80Y0ExNWV1ZzFEZXlxTk1SYmJsN2lxS3hHRU1k?=
 =?utf-8?Q?I/fIbXjmSxNqxg7shgnlPOulba+b/w=3D?=
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:(13230040)(376014)(1800799024)(36860700013)(82310400026)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2025 16:55:43.7313
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 8f748009-66ee-49fe-0245-08dd3585735d
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:
	SJ1PEPF00001CE0.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB9460

On 2024-12-26 11:57, Daniel P. Smith wrote:
> Add three properties, memory, mem-min, and mem-max, to the domain node device
> tree parsing to define the memory allocation for a domain. All three fields are
> expressed in kb and written as a u64 in the device tree entries.
> 
> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>

> diff --git a/xen/arch/x86/domain-builder/fdt.c b/xen/arch/x86/domain-builder/fdt.c
> index db584ba78e92..aff1b8c3235d 100644
> --- a/xen/arch/x86/domain-builder/fdt.c
> +++ b/xen/arch/x86/domain-builder/fdt.c
> @@ -6,6 +6,7 @@
>   #include <xen/init.h>
>   #include <xen/lib.h>
>   #include <xen/libfdt/libfdt.h>
> +#include <xen/sizes.h>
>   
>   #include <asm/bootinfo.h>
>   #include <asm/guest.h>
> @@ -113,6 +114,39 @@ static int __init process_domain_node(
>               else
>                   printk("PV\n");
>           }
> +        else if ( strncmp(prop_name, "memory", name_len) == 0 )
> +        {
> +            uint64_t kb;
> +            if ( fdt_prop_as_u64(prop, &kb) != 0 )
> +            {
> +                printk("  failed processing memory for domain %s\n", name);
> +                return -EINVAL;
> +            }
> +            bd->mem_pages = PFN_DOWN(kb * SZ_1K);
> +            printk("  memory: %ld kb\n", kb);
> +        }
> +        else if ( strncmp(prop_name, "mem-min", name_len) == 0 )
> +        {
> +            uint64_t kb;
> +            if ( fdt_prop_as_u64(prop, &kb) != 0 )
> +            {
> +                printk("  failed processing memory for domain %s\n", name);

s/memory/mem-min/

> +                return -EINVAL;
> +            }
> +            bd->min_pages = PFN_DOWN(kb * SZ_1K);
> +            printk("  min memory: %ld kb\n", kb);
> +        }
> +        else if ( strncmp(prop_name, "mem-max", name_len) == 0 )
> +        {
> +            uint64_t kb;
> +            if ( fdt_prop_as_u64(prop, &kb) != 0 )
> +            {
> +                printk("  failed processing memory for domain %s\n", name);

s/memory/mem-max/

With that,

Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>

> +                return -EINVAL;
> +            }
> +            bd->max_pages = PFN_DOWN(kb * SZ_1K);
> +            printk("  max memory: %ld kb\n", kb);
> +        }
>       }
>   
>       fdt_for_each_subnode(node, fdt, dom_node)


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 17:23:22 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 17:23:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872922.1283917 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY76j-0005ZR-2s; Wed, 15 Jan 2025 17:23:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872922.1283917; Wed, 15 Jan 2025 17:23:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY76i-0005ZK-V5; Wed, 15 Jan 2025 17:23:08 +0000
Received: by outflank-mailman (input) for mailman id 872922;
 Wed, 15 Jan 2025 17:23:07 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=3mb0=UH=apertussolutions.com=dpsmith@srs-se1.protection.inumbo.net>)
 id 1tY76g-0005ZE-H0
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 17:23:07 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5ff96936-d365-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 18:23:04 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1736961774356471.16132186163145;
 Wed, 15 Jan 2025 09:22:54 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5ff96936-d365-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; t=1736961777; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=JPJ53sX8UMHZxHB/qZhg0MDM871WOR2U3dcHIByM1BJ7ggYA1+diM90NF9jw/7VZ/d0aHRDrAf/7+JRdNc4HYOOnVujqQhei6EMRwcL3Iwx+T4oaC37iDLWloU8L2sunHHeXdiwZ26Gei4k/jhO9TFiBGZwQCWbjILeXiAiXktQ=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1736961777; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=lIXwxXJ8lS/esOK+izgmugOLHWpMoMlSbUHnye4+k4Q=; 
	b=TNBl30c3NevlYfa5E7/0gdWO+e15+sjpR3TAbgZZNx3QGzifAW9f6EDsSYrVdfGtJJe1cFB0/j7aMNIY2bt7zvPDg7cOfLX5hKuO+T9V9AeXvqD7sWXxfG0WhfKbZJVITKLdsLRHb3nzrxRXOKZmP6COl+dxdwzemPPFAanhFGk=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1736961776;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=lIXwxXJ8lS/esOK+izgmugOLHWpMoMlSbUHnye4+k4Q=;
	b=XXo34WAhzsdnh6OP4FSEm+qwdKaVU0N58lrrVSIfXxcZHNC6KeBhlsA/xGJZxICw
	beNajCFQByL/UWBrB9weCs9U9FSJq8QWWLd/hZbuPR7wcX9V9MX6IG7OeyPaeNf2F+K
	9S1JqET2YK0AfAxNeIOd/LAqf4llomHTtgM/eO9I=
Message-ID: <245a2a00-98c0-498f-8a9e-ca62dbe59a71@apertussolutions.com>
Date: Wed, 15 Jan 2025 12:22:53 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 03/15] x86/boot: add cmdline to struct boot_domain
To: Jason Andryuk <jason.andryuk@amd.com>, xen-devel@lists.xenproject.org
Cc: christopher.w.clark@gmail.com, stefano.stabellini@amd.com,
 Jan Beulich <jbeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
 <20241226165740.29812-4-dpsmith@apertussolutions.com>
 <508cff3c-3fd4-4ab7-89ef-30a72a267111@amd.com>
Content-Language: en-US
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
In-Reply-To: <508cff3c-3fd4-4ab7-89ef-30a72a267111@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

On 1/10/25 14:52, Jason Andryuk wrote:
> On 2024-12-26 11:57, Daniel P. Smith wrote:
>> Add a container for the "cooked" command line for a domain. This 
>> provides for
>> the backing memory to be directly associated with the domain being 
>> constructed.
>> This is done in anticipation that the domain construction path may 
>> need to be
>> invoked multiple times, thus ensuring each instance had a distinct memory
>> allocation.
>>
>> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
> 
> 
>> @@ -1018,39 +1037,52 @@ static struct domain *__init 
>> create_dom0(struct boot_info *bi)
>>           panic("Error creating d%uv0\n", bd->domid);
>>       /* Grab the DOM0 command line. */
>> -    if ( bd->kernel->cmdline_pa || bi->kextra )
>> +    if ( (bd->kernel->cmdline_pa &&
>> +          ((char *)__va(bd->kernel->cmdline_pa))[0]) ||
>> +         bi->kextra )
>>       {
>> -        if ( bd->kernel->cmdline_pa )
>> -            safe_strcpy(cmdline,
>> -                        cmdline_cook(__va(bd->kernel->cmdline_pa), 
>> bi->loader));
>> +        size_t cmdline_size = domain_cmdline_size(bi, bd);
>> +
>> +        if ( cmdline_size )
>> +        {
>> +            if ( !(cmdline = xzalloc_array(char, cmdline_size)) )
>> +                panic("Error allocating cmdline buffer for %pd\n", d);
> 
> I guess I wasn't clear last time.  Instead of two levels of indent, I 
> was thinking at the top level:
> 
>      /* Grab the DOM0 command line. */
>      cmdline_size = domain_cmdline_size(bi, bd);
>      if ( cmdline_size )
>      {
> 
> domain_cmdline_size() checks all the pointers, so this removes 
> duplication and indent.

But it is possible for there to be no command line, thus there is a 
legitimate case where cmdline_size will be 0. If it is 0, there is no 
reason to go through all of this logic.

v/r,
dps


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 17:24:33 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 17:24:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872929.1283927 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY784-00065S-Bk; Wed, 15 Jan 2025 17:24:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872929.1283927; Wed, 15 Jan 2025 17:24:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY784-00065L-8H; Wed, 15 Jan 2025 17:24:32 +0000
Received: by outflank-mailman (input) for mailman id 872929;
 Wed, 15 Jan 2025 17:24: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
 <SRS0=3mb0=UH=apertussolutions.com=dpsmith@srs-se1.protection.inumbo.net>)
 id 1tY782-00065D-Oq
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 17:24:30 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 92c2fb2d-d365-11ef-a0e1-8be0dac302b0;
 Wed, 15 Jan 2025 18:24:29 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1736961858619464.6083482162387;
 Wed, 15 Jan 2025 09:24:18 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 92c2fb2d-d365-11ef-a0e1-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1736961861; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=XAu2r15hSwso5dZOXyFyFxRLX4vEIwKNhmBhaOqr6GDO5MN6sViyHA0R0UZyjRcBWbXfeYb9H4L4ME2vBm30/fnuWKICy2lXwI1TSihG7bA8HBnGC4J8fav6VBjyaJRC9FT6+EKGFmJWrlRai+ruQ7BUD1nRU7xwzP4LuwhQS+0=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1736961861; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=h+VVkBJPBeYEKvx1sLgmKR302+785QZO/5qA+TWHgas=; 
	b=FqDPrh664HrnKBTN+13S/r1C7yM44SSRXQpQjt+VwaSu8VDykiWgjP0xehEqXvIeJ+FECtGiE7LntfsGs0QZPilZLoS8c5/jvsPgAibRUJBYMDunOrrckGgeNXOD3oI1Cjuc6XWJvAWeD8HMzp6fO4tPe5ykHiP8RKwedlZ72dw=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1736961860;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=h+VVkBJPBeYEKvx1sLgmKR302+785QZO/5qA+TWHgas=;
	b=W7SjeCdfmKcuNn5cUA8R0PGyV79i0tkVzrc73iWOutGPvqoBZ+uP3C7rz2wWUjei
	XkzAgJ+pTdRJzT4LhVAtnPFRwPZb8jTzsUFLoNUMI/U5RFkZ6jGJvcrEAShHvUqoULh
	n24JTUEtlsUeOkYDVaJgVDwsJMB+Bm1XcFjAyhfA=
Message-ID: <0932dc87-edae-4b68-a4b2-bf2aa39ab64e@apertussolutions.com>
Date: Wed, 15 Jan 2025 12:24:17 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 05/15] kconfig: introduce domain builder config option
To: Jason Andryuk <jason.andryuk@amd.com>, xen-devel@lists.xenproject.org
Cc: christopher.w.clark@gmail.com, stefano.stabellini@amd.com,
 Jan Beulich <jbeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
 <20241226165740.29812-6-dpsmith@apertussolutions.com>
 <43c0ce53-4b3c-47b6-8b4d-c5278f52d7fe@amd.com>
Content-Language: en-US
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
In-Reply-To: <43c0ce53-4b3c-47b6-8b4d-c5278f52d7fe@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

On 1/10/25 14:55, Jason Andryuk wrote:
> On 2024-12-26 11:57, Daniel P. Smith wrote:
>> Hyperlaunch domain builder will be the consolidated boot time domain 
>> building
>> logic framework. Introduces the config option to enable this domain 
>> builder to
>> and turn on the ability to load the domain configuration via a 
>> flattened device
>> tree.
>>
>> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
> 
>> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
>> index 9cdd04721afa..25b9b75423c5 100644
>> --- a/xen/arch/x86/Kconfig
>> +++ b/xen/arch/x86/Kconfig
>> @@ -383,6 +383,8 @@ config ALTP2M
>>         If unsure, stay with defaults.
>> +source "arch/x86/domain_builder/Kconfig"
> 
> s/_/-/ ?

Ack.

> With that,
> 
> Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>

Thanks!

v/r,
dps


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 17:26:21 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 17:26:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872940.1283937 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY79n-0006h8-Q9; Wed, 15 Jan 2025 17:26:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872940.1283937; Wed, 15 Jan 2025 17:26:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY79n-0006h1-NG; Wed, 15 Jan 2025 17:26:19 +0000
Received: by outflank-mailman (input) for mailman id 872940;
 Wed, 15 Jan 2025 17:26:19 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=3mb0=UH=apertussolutions.com=dpsmith@srs-se1.protection.inumbo.net>)
 id 1tY79n-0006gq-5m
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 17:26:19 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ce1e5407-d365-11ef-a0e1-8be0dac302b0;
 Wed, 15 Jan 2025 18:26:16 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1736961951913170.49136125974746;
 Wed, 15 Jan 2025 09:25:51 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ce1e5407-d365-11ef-a0e1-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1736961955; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=JWo/AL4MILPlxOfA67ddLaVtzGN2xgxVdUqCzYBoK9eYpE65JiykH+/9DtPs67wFIykw3vFkjatLZhsFIkEWsPMvXtmet7jxr7wR7tVUxJNkZ0IMdzehL/WvIPy8bWz1vNvG26F2bRfp9+ioLIS4QBdN4j5vwME+FTECI83gZz8=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1736961955; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=fy+DIUmUOKoZIHNqVEZaQ3xT6N2YzcU+DcPNi2zQD3E=; 
	b=Ut/HneLEffkByqQx15V28BqBojGcNjs4NQLBy+GjsCwO8jVGIZAcFSti9EXxhysA98gcirZNB8JSd9T2OiwXGhnkMn6KeqIZnP3ftb3K7loJsojk8DAG8e2P3aqChua73D/YmsxyD0YKz3UOrQOnGrpdqYf6zn8jpbjvFhHF9b0=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1736961955;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=fy+DIUmUOKoZIHNqVEZaQ3xT6N2YzcU+DcPNi2zQD3E=;
	b=M73pzxBu7I5TtquNzxd9g2oPnwGGwqo/QO4IzVhnQTXi57f0X4FCTAUIaDg05QN2
	0U5+iEtbouECMxRJMYFxWZCsAMt8zMSpqHgz4ruyPsBniD4sRWyi2aOPoKCwJsjkdAD
	GnlYtkFSfBHH5L8MN35rRaeCO8hYaqTVnpUe6euY=
Message-ID: <6e22a62a-cf33-4d44-b646-947bf8edab61@apertussolutions.com>
Date: Wed, 15 Jan 2025 12:25:51 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 06/15] x86/hyperlaunch: introduce the domain builder
To: Jason Andryuk <jason.andryuk@amd.com>, xen-devel@lists.xenproject.org
Cc: christopher.w.clark@gmail.com, stefano.stabellini@amd.com,
 Jan Beulich <jbeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
 <20241226165740.29812-7-dpsmith@apertussolutions.com>
 <c39d6c7b-0cd8-4b71-965f-1fd0d49b5221@amd.com>
Content-Language: en-US
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
In-Reply-To: <c39d6c7b-0cd8-4b71-965f-1fd0d49b5221@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External

On 1/8/25 16:54, Jason Andryuk wrote:
> On 2024-12-26 11:57, Daniel P. Smith wrote:
>> Introduce the domain builder which is capable of consuming a device 
>> tree as the
>> first boot module. If it finds a device tree as the first boot module, 
>> it will
>> set its type to BOOTMOD_FDT. This change only detects the boot module and
>> continues to boot with slight change to the boot convention that the dom0
>> kernel is no longer first boot module but is the second.
>>
>> No functional change intended.
>>
>> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
>> Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
> 
>> diff --git a/xen/arch/x86/domain-builder/Makefile b/xen/arch/x86/ 
>> domain-builder/Makefile
>> new file mode 100644
>> index 000000000000..309a0c4bdd9e
>> --- /dev/null
>> +++ b/xen/arch/x86/domain-builder/Makefile
>> @@ -0,0 +1,3 @@
>> +obj-$(CONFIG_DOMAIN_BUILDER) += fdt.init.o
>> +obj-y += core.init.o
>> +
> 
> When I git am-ed this series, git warned:
> Applying: x86/hyperlaunch: introduce the domain builder
> .git/rebase-apply/patch:59: new blank line at EOF.
> +
> warning: 1 line adds whitespace errors.
> 
> I think that is here.

Ack.

v/r,
dps



From xen-devel-bounces@lists.xenproject.org Wed Jan 15 17:42:01 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 17:42:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872953.1283946 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY7Ot-0002Q2-1u; Wed, 15 Jan 2025 17:41:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872953.1283946; Wed, 15 Jan 2025 17:41:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY7Os-0002Pv-Vb; Wed, 15 Jan 2025 17:41:54 +0000
Received: by outflank-mailman (input) for mailman id 872953;
 Wed, 15 Jan 2025 17:41: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
 <SRS0=Aa7S=UH=raptorengineering.com=sanastasio@srs-se1.protection.inumbo.net>)
 id 1tY7Or-0002Pn-9p
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 17:41:53 +0000
Received: from raptorengineering.com (mail.raptorengineering.com
 [23.155.224.40]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ff46574f-d367-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 18:41:50 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id 6037C8286736;
 Wed, 15 Jan 2025 11:41:48 -0600 (CST)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id gny4TwPY2_Qb; Wed, 15 Jan 2025 11:41:47 -0600 (CST)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id 898538286868;
 Wed, 15 Jan 2025 11:41:47 -0600 (CST)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id qDxMNjvKEPwZ; Wed, 15 Jan 2025 11:41:47 -0600 (CST)
Received: from [10.11.0.2] (5.edge.rptsys.com [23.155.224.38])
 by mail.rptsys.com (Postfix) with ESMTPSA id E2EAA8286736;
 Wed, 15 Jan 2025 11:41:46 -0600 (CST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ff46574f-d367-11ef-99a4-01e77a169b0f
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.rptsys.com 898538286868
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=raptorengineering.com; s=B8E824E6-0BE2-11E6-931D-288C65937AAD;
	t=1736962907; bh=ByQYVunuVRpGxjkALScEYlY/PYEI+s0b6B6Z0C93INM=;
	h=Message-ID:Date:MIME-Version:To:From;
	b=d1M1HBVb9X+EcHuvQ1BRNtm85ZKrp3SSy1Q6YYhEg1vU5L9NwMG4wcNeqB2uHGAFw
	 tj3OZv6nOVPy0XZ2RiuJqbxIhkCrXgJmCeXfrvc/f9S8bCybFGnGJWf4RApwBZGmdW
	 EZKqNrzuNnz1w2wNr7Hn3BmolkM5o9gcAn/mSFlU=
X-Virus-Scanned: amavisd-new at rptsys.com
Message-ID: <502aafe5-1e92-4119-b5ff-c4402f2a0822@raptorengineering.com>
Date: Wed, 15 Jan 2025 11:41:46 -0600
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/ppc: Fix double xen_ulong_t typedef in
 public/arch-ppc.h
To: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xenproject.org
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Stefano Stabellini <sstabellini@kernel.org>
References: <20250115150339.53931-1-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Shawn Anastasio <sanastasio@raptorengineering.com>
In-Reply-To: <20250115150339.53931-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi Andrew,

On 1/15/25 9:03 AM, Andrew Cooper wrote:
> public/arch-ppc.h contains two adjacent #ifndef __ASSEMBLY__ blocks.
> 
> With these merged, it becomes very obvious that there's a duplicate
> definition of xen_ulong_t, which is also noticed by the docs build:
> 
>   /usr/bin/perl -w /local/xen.git/docs/xen-headers -O html/hypercall/ppc \
>           -T 'arch-ppc - Xen public headers' \
>           -X arch-arm -X arch-riscv -X arch-x86_32 -X arch-x86_64 \
>           -X xen-arm -X xen-riscv -X xen-x86_32 -X xen-x86_64 \
>           -X arch-x86 \
>           /local/xen.git/docs/../xen include/public include/xen/errno.h
>   include/public/memory.h:63: multiple definitions of Typedef xen_ulong_t: include/public/arch-ppc.h:55
>   include/public/memory.h:63: multiple definitions of Typedef xen_ulong_t: include/public/arch-ppc.h:61
>   include/public/memory.h:63: multiple definitions of Typedef xen_ulong_t: include/public/arch-ppc.h:61
>   include/public/memory.h:63: multiple definitions of Typedef xen_ulong_t: include/public/arch-ppc.h:55
> 
> Drop the second typedef.  Finally, annotate the #endif so it's clear
> what it refers to.
> 
> Fixes: 08c192cc1127 ("xen/ppc: Add public/arch-ppc.h")
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Reviewed-by: Shawn Anastasio <sanastasio@raptorengineering.com>

Thanks,
Shawn


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 17:44:33 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 17:44:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872961.1283958 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY7RQ-0002yx-Gi; Wed, 15 Jan 2025 17:44:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872961.1283958; Wed, 15 Jan 2025 17:44:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY7RQ-0002yq-Bf; Wed, 15 Jan 2025 17:44:32 +0000
Received: by outflank-mailman (input) for mailman id 872961;
 Wed, 15 Jan 2025 17:44:30 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=rWPo=UH=casper.srs.infradead.org=BATV+fb641630334796bb9467+7815+infradead.org+dwmw2@srs-se1.protection.inumbo.net>)
 id 1tY7RN-0002yd-VF
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 17:44:30 +0000
Received: from casper.infradead.org (casper.infradead.org
 [2001:8b0:10b:1236::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5c60c5c5-d368-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 18:44:25 +0100 (CET)
Received: from 54-240-197-234.amazon.com ([54.240.197.234]
 helo=freeip.amazon.com)
 by casper.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux))
 id 1tY7RH-0000000Gz0R-3aqu; Wed, 15 Jan 2025 17:44:24 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5c60c5c5-d368-11ef-99a4-01e77a169b0f
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:Cc:To:From:Subject:Message-ID:Sender:Reply-To:
	Content-Transfer-Encoding:Content-ID:Content-Description;
	bh=nr1w0HMnYTbUG16M788RJVriNHteT9a5YyCdF9NcA5Y=; b=QLBRekgutO+jUH4VQcQZGr5Za3
	WldofV5kM0xk55Lx/5AyTYBDx3vzV5waalhViy/5UapGwTl0l/eRECW/BXtCb+lX10JSnsV7hPTOk
	nXj/Tx/qNrkOt1I129a2T6DRzI9lqHBFYByXBUexYv3QVH0XjOpTy+3/mpYoJjs1DHRsdlkmrPZlU
	8CFMzSRwQnSFSAQPYrXwGYkv87qrpRzPSGWLyInoc7H2Gc93SWhXishyrnSB97XPiOsqxPRvl362M
	RMsvmX+8fBSd+vTV53pyrNu8kdGAbKigpvMxCpQNHNb99nlC+c8jeI5VgC8eaSb2RzNxSqwTP6YBQ
	Ol2eKVhA==;
Message-ID: <e3a0a04e867514d33e434804fd6a9c48936b9e72.camel@infradead.org>
Subject: Re: [PATCH v3 7/7] hw/xen: Fix errp handling in xen_console
From: David Woodhouse <dwmw2@infradead.org>
To: Anthony PERARD <anthony@xenproject.org>
Cc: qemu-devel@nongnu.org, Roger Pau =?ISO-8859-1?Q?Monn=E9?=
 <roger.pau@citrix.com>, Stefano Stabellini <sstabellini@kernel.org>, Paul
 Durrant <paul@xen.org>, "Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
 Kevin Wolf <kwolf@redhat.com>, Hanna Reitz <hreitz@redhat.com>, 
 =?ISO-8859-1?Q?Marc-Andr=E9?= Lureau <marcandre.lureau@redhat.com>, Paolo
 Bonzini <pbonzini@redhat.com>, Jason Wang <jasowang@redhat.com>,
 xen-devel@lists.xenproject.org, qemu-block@nongnu.org
Date: Wed, 15 Jan 2025 18:44:22 +0100
In-Reply-To: <Z4fnIQ8YbTP_i0U9@l14>
References: <20250115163542.291424-1-dwmw2@infradead.org>
	 <20250115163542.291424-8-dwmw2@infradead.org> <Z4fnIQ8YbTP_i0U9@l14>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-6iKf1h7eQmpGaijurTmn"
User-Agent: Evolution 3.52.3-0ubuntu1 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html


--=-6iKf1h7eQmpGaijurTmn
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2025-01-15 at 17:49 +0100, Anthony PERARD wrote:
>=20
> With those fixed: Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>

Thanks. I've pushed those changes and am watching the pipeline at
https://gitlab.com/dwmw2/qemu/-/pipelines/1626804720

I'll probably send a pull request tomorrow. The patch now looks like
this:

=46rom 8b44a3e39f36540818d99ef8cf79e64bba1ed9c3 Mon Sep 17 00:00:00 2001
From: David Woodhouse <dwmw@amazon.co.uk>
Date: Wed, 15 Jan 2025 15:46:06 +0000
Subject: [PATCH] hw/xen: Fix errp handling in xen_console

When attempting to read the 'output' node, interpret any error *other*
than ENOENT as a fatal error. For ENOENT, fall back to serial_hd() to
find a character device, or create a null device.

Do not attempt to prepend to errp when serial_hd() fails; the error
isn't relevant (and prior to this change, wasn't set anyway).

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
---
 hw/char/xen_console.c | 34 +++++++++++++++++++++-------------
 1 file changed, 21 insertions(+), 13 deletions(-)

diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
index e61902461b..d03c188d1d 100644
--- a/hw/char/xen_console.c
+++ b/hw/char/xen_console.c
@@ -569,7 +569,7 @@ static void xen_console_device_create(XenBackendInstanc=
e *backend,
=20
     snprintf(label, sizeof(label), "xencons%ld", number);
=20
-    output =3D xs_node_read(xsh, XBT_NULL, NULL, NULL, "%s/%s", fe, "outpu=
t");
+    output =3D xs_node_read(xsh, XBT_NULL, NULL, errp, "%s/%s", fe, "outpu=
t");
     if (output) {
         /*
          * FIXME: sure we want to support implicit
@@ -581,19 +581,27 @@ static void xen_console_device_create(XenBackendInsta=
nce *backend,
                        output);
             goto fail;
         }
-    } else if (number) {
-        cd =3D serial_hd(number);
-        if (!cd) {
-            error_prepend(errp, "console: No serial device #%ld found: ",
-                          number);
-            goto fail;
-        }
+    } else if (errno !=3D ENOENT) {
+        error_prepend(errp, "console: No valid chardev found: ");
+        goto fail;
     } else {
-        /* No 'output' node on primary console: use null. */
-        cd =3D qemu_chr_new(label, "null", NULL);
-        if (!cd) {
-            error_setg(errp, "console: failed to create null device");
-            goto fail;
+        error_free(*errp);
+        *errp =3D NULL;
+
+        if (number) {
+            cd =3D serial_hd(number);
+            if (!cd) {
+                error_setg(errp, "console: No serial device #%ld found",
+                           number);
+                goto fail;
+            }
+        } else {
+            /* No 'output' node on primary console: use null. */
+            cd =3D qemu_chr_new(label, "null", NULL);
+            if (!cd) {
+                error_setg(errp, "console: failed to create null device");
+                goto fail;
+            }
         }
     }
=20
--=20
2.47.0



--=-6iKf1h7eQmpGaijurTmn
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD9Aw
ggSOMIIDdqADAgECAhAOmiw0ECVD4cWj5DqVrT9PMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0yNDAxMzAwMDAwMDBaFw0zMTEx
MDkyMzU5NTlaMEExCzAJBgNVBAYTAkFVMRAwDgYDVQQKEwdWZXJva2V5MSAwHgYDVQQDExdWZXJv
a2V5IFNlY3VyZSBFbWFpbCBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMjvgLKj
jfhCFqxYyRiW8g3cNFAvltDbK5AzcOaR7yVzVGadr4YcCVxjKrEJOgi7WEOH8rUgCNB5cTD8N/Et
GfZI+LGqSv0YtNa54T9D1AWJy08ZKkWvfGGIXN9UFAPMJ6OLLH/UUEgFa+7KlrEvMUupDFGnnR06
aDJAwtycb8yXtILj+TvfhLFhafxroXrflspavejQkEiHjNjtHnwbZ+o43g0/yxjwnarGI3kgcak7
nnI9/8Lqpq79tLHYwLajotwLiGTB71AGN5xK+tzB+D4eN9lXayrjcszgbOv2ZCgzExQUAIt98mre
8EggKs9mwtEuKAhYBIP/0K6WsoMnQCcCAwEAAaOCAVwwggFYMBIGA1UdEwEB/wQIMAYBAf8CAQAw
HQYDVR0OBBYEFIlICOogTndrhuWByNfhjWSEf/xwMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6en
IZ3zbcgPMA4GA1UdDwEB/wQEAwIBhjAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIweQYI
KwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYIKwYB
BQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RD
QS5jcnQwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0
QXNzdXJlZElEUm9vdENBLmNybDARBgNVHSAECjAIMAYGBFUdIAAwDQYJKoZIhvcNAQELBQADggEB
ACiagCqvNVxOfSd0uYfJMiZsOEBXAKIR/kpqRp2YCfrP4Tz7fJogYN4fxNAw7iy/bPZcvpVCfe/H
/CCcp3alXL0I8M/rnEnRlv8ItY4MEF+2T/MkdXI3u1vHy3ua8SxBM8eT9LBQokHZxGUX51cE0kwa
uEOZ+PonVIOnMjuLp29kcNOVnzf8DGKiek+cT51FvGRjV6LbaxXOm2P47/aiaXrDD5O0RF5SiPo6
xD1/ClkCETyyEAE5LRJlXtx288R598koyFcwCSXijeVcRvBB1cNOLEbg7RMSw1AGq14fNe2cH1HG
W7xyduY/ydQt6gv5r21mDOQ5SaZSWC/ZRfLDuEYwggWbMIIEg6ADAgECAhAH5JEPagNRXYDiRPdl
c1vgMA0GCSqGSIb3DQEBCwUAMEExCzAJBgNVBAYTAkFVMRAwDgYDVQQKEwdWZXJva2V5MSAwHgYD
VQQDExdWZXJva2V5IFNlY3VyZSBFbWFpbCBHMjAeFw0yNDEyMzAwMDAwMDBaFw0yODAxMDQyMzU5
NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqGSIb3DQEBAQUAA4IC
DwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZeYAS/SRV6zmfXlXaZ
sNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2zkC9S7/yHDYnqegqt
w4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qGpgFdZEk2/c//ZvUN
i12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41vav1RhZJzYan4a1gU0
kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0cvnO8FM6PTqsnSbcc
0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PWPU6zfQTOMZ9uLQRR
ci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXtREF5lLXxp+CJ6KKS
blPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQrlR0gO3lBzuyPPArV
hvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7IqaAovAX0d+f1YjbmC
VsAwjhLmveFjNwIDAQABo4IBsDCCAawwHwYDVR0jBBgwFoAUiUgI6iBOd2uG5YHI1+GNZIR//HAw
HQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3bXcyQGluZnJhZGVh
ZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEBMA4GA1UdDwEB/wQE
AwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwewYDVR0fBHQwcjA3oDWgM4YxaHR0
cDovL2NybDMuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNybDA3oDWgM4YxaHR0
cDovL2NybDQuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNybDB2BggrBgEFBQcB
AQRqMGgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBABggrBgEFBQcwAoY0
aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNydDANBgkq
hkiG9w0BAQsFAAOCAQEAQXc4FPiPLRnTDvmOABEzkIumojfZAe5SlnuQoeFUfi+LsWCKiB8Uextv
iBAvboKhLuN6eG/NC6WOzOCppn4mkQxRkOdLNThwMHW0d19jrZFEKtEG/epZ/hw/DdScTuZ2m7im
8ppItAT6GXD3aPhXkXnJpC/zTs85uNSQR64cEcBFjjoQDuSsTeJ5DAWf8EMyhMuD8pcbqx5kRvyt
JPsWBQzv1Dsdv2LDPLNd/JUKhHSgr7nbUr4+aAP2PHTXGcEBh8lTeYea9p4d5k969pe0OHYMV5aL
xERqTagmSetuIwolkAuBCzA9vulg8Y49Nz2zrpUGfKGOD0FMqenYxdJHgDCCBZswggSDoAMCAQIC
EAfkkQ9qA1FdgOJE92VzW+AwDQYJKoZIhvcNAQELBQAwQTELMAkGA1UEBhMCQVUxEDAOBgNVBAoT
B1Zlcm9rZXkxIDAeBgNVBAMTF1Zlcm9rZXkgU2VjdXJlIEVtYWlsIEcyMB4XDTI0MTIzMDAwMDAw
MFoXDTI4MDEwNDIzNTk1OVowHjEcMBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzCCAiIwDQYJ
KoZIhvcNAQEBBQADggIPADCCAgoCggIBANqWLse95HW2F7FhfH9bugyT/danKmmXrbMnz5GZNAfj
Jl5gBL9JFXrOZ9eVdpmw04Tp6aDxZctFLoEDvSWKi367Q7Sg+ci+fH4KwwfQ8Pi0IpIKx2n5emEg
nbOQL1Lv/IcNiep6Cq3DiyaSpSp/RZf+CAfUNySHS8eWmhLU6jGpSD6hxTpYKye7PmrmvMWwfGEP
WoamAV1kSTb9z/9m9Q2LXa89aKmTxNwnAfD3Ohn9mtU3JukwILRMewn9QRXK7KzM+01h5hkCE4nj
W9q/VGFknNhqfhrWBTSQoE9CSVylASGrjzCgS7XmKy/BaH3/7mOOHQv5g1o3Qj/+cdKnpT0I5Qb1
nRy+c7wUzo9OqydJtxzSP4ZyHA4dELto/a3m/ay1XHcpum1pgTOLgxAfGb/T4dCkwRUstSKLMmpL
g9Y9TrN9BM4xn24tBFFyL5znGG0wQGzOVAM68RBzIQb6Fz758fjsr4yZnPbVsU1+gHEs/puNHrG0
9e1EQXmUtfGn4InoopJuU8p5VGD9S3Ikd4UoBlc7xl5yjtNlQxUeYrRlnUSmdlucCEoTX1n4UmtA
9CuVHSA7eUHO7I88CtWG9bGOU7tLgOZoSEvNqtaL/N7sQbBZK4jZ4Rr/zNTQg1SwYjjLB7u96lDP
sipoCi8BfR35/ViNuYJWwDCOEua94WM3AgMBAAGjggGwMIIBrDAfBgNVHSMEGDAWgBSJSAjqIE53
a4blgcjX4Y1khH/8cDAdBgNVHQ4EFgQUXGIam3Bs59Y60yTmWgfDu6pZQ6cwMAYDVR0RBCkwJ4ET
ZHdtdzJAaW5mcmFkZWFkLm9yZ4EQZGF2aWRAd29vZGhvdS5zZTAUBgNVHSAEDTALMAkGB2eBDAEF
AQEwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDB7BgNVHR8E
dDByMDegNaAzhjFodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVtYWlsRzIu
Y3JsMDegNaAzhjFodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVtYWlsRzIu
Y3JsMHYGCCsGAQUFBwEBBGowaDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29t
MEAGCCsGAQUFBzAChjRodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVt
YWlsRzIuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQBBdzgU+I8tGdMO+Y4AETOQi6aiN9kB7lKWe5Ch
4VR+L4uxYIqIHxR7G2+IEC9ugqEu43p4b80LpY7M4KmmfiaRDFGQ50s1OHAwdbR3X2OtkUQq0Qb9
6ln+HD8N1JxO5nabuKbymki0BPoZcPdo+FeRecmkL/NOzzm41JBHrhwRwEWOOhAO5KxN4nkMBZ/w
QzKEy4PylxurHmRG/K0k+xYFDO/UOx2/YsM8s138lQqEdKCvudtSvj5oA/Y8dNcZwQGHyVN5h5r2
nh3mT3r2l7Q4dgxXlovERGpNqCZJ624jCiWQC4ELMD2+6WDxjj03PbOulQZ8oY4PQUyp6djF0keA
MYIDuzCCA7cCAQEwVTBBMQswCQYDVQQGEwJBVTEQMA4GA1UEChMHVmVyb2tleTEgMB4GA1UEAxMX
VmVyb2tleSBTZWN1cmUgRW1haWwgRzICEAfkkQ9qA1FdgOJE92VzW+AwDQYJYIZIAWUDBAIBBQCg
ggE3MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTI1MDExNTE3NDQy
MlowLwYJKoZIhvcNAQkEMSIEIKALmnpjA0+bZOSSBCkUBKjkN8GBxsmKKwQsn9EyMN+8MGQGCSsG
AQQBgjcQBDFXMFUwQTELMAkGA1UEBhMCQVUxEDAOBgNVBAoTB1Zlcm9rZXkxIDAeBgNVBAMTF1Zl
cm9rZXkgU2VjdXJlIEVtYWlsIEcyAhAH5JEPagNRXYDiRPdlc1vgMGYGCyqGSIb3DQEJEAILMVeg
VTBBMQswCQYDVQQGEwJBVTEQMA4GA1UEChMHVmVyb2tleTEgMB4GA1UEAxMXVmVyb2tleSBTZWN1
cmUgRW1haWwgRzICEAfkkQ9qA1FdgOJE92VzW+AwDQYJKoZIhvcNAQEBBQAEggIAxUsoY6KSALQC
sU1yu5jkGVAheCAMC6FDFjoOPGGR1VkC2T+/ENKuolZhM8XQrp/FoIzaBWfXsVU+bCnrsRmAvs/9
XEKis7Dhg3iuE8lMcxT+dh4HtID+lmGsIO2qwocZ3iqdRQ5jdUBBxWIyFXRFQ/S81LNaOGyQ1BzG
ZkMHaxcHWNLRx4CEcUt6dVFz4EnCRCJ9wSyw/x9GnydwyIjKOfTXpf8ELoFbpgj9zWA0CY1vHG8W
5OrveLIf2n9RvenASwqy6r9uXa+PpWN/cPkPy+jZeRy1SQnsXXcxxMXbl9I4jBt06SeqT/6myaIQ
s8GxfHstSfotncQUsgE2NmEgEaBCoHF1jnSL/IRluq7Umq7JNQy/odxcaxHvFk8J/7BgYQe+CNdV
3PDYDhx0xqr4EkaXRUC9VMjF8VZK3H7kuKMlxYCmCi3RV6GaL+nGBQWgLSCgnV4hUBYqWwqi/I9F
osnOuHaN+tQFyLGbgN1LYw/AdQHYYo/T1E5sr3PytcbXtHVR6PM9v4sTFsedcOifv5aDZBKPGr3h
FoGOY4koT8B+DO09tszQpljWokh+52516ihknC/BviuuJg//yi6e5NTRlcw+RPCgAz+U5pk6SEaQ
HYqIUB7f/5ruqmG7W6GplvSCXKrRhRvEcjOTfu86/OqOvh95M4HMqX6owKWcGRYAAAAAAAA=


--=-6iKf1h7eQmpGaijurTmn--


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 17:47:53 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 17:47:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872971.1283966 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY7Ub-0003Xu-SG; Wed, 15 Jan 2025 17:47:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872971.1283966; Wed, 15 Jan 2025 17:47:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY7Ub-0003Xn-PF; Wed, 15 Jan 2025 17:47:49 +0000
Received: by outflank-mailman (input) for mailman id 872971;
 Wed, 15 Jan 2025 17:47: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
 <SRS0=3mb0=UH=apertussolutions.com=dpsmith@srs-se1.protection.inumbo.net>)
 id 1tY7Ua-0003Xh-6X
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 17:47:48 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d31eb316-d368-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 18:47:45 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1736963259126220.9793921436053;
 Wed, 15 Jan 2025 09:47:39 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: d31eb316-d368-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; t=1736963261; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=JYWIOhZqImmzpqoVH6gpdDeE5eXipdmf3zhuhChtHW9peHmAp+TNaaTRMYI3pVIqisG8ILw7uzQ/kkEYYmOhkjQqY2CbGAChrqTIhm/1NHOABvfAAyDCyFo1ySM+omlMxSi2RXagQ/sQB2UN18lcJum2+//aLQfguilIgVC6Z10=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1736963261; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=f0hX9slKCdmAZPrw4d9Mc8tP6Sq7M8FYgsZIfrlpNqQ=; 
	b=Oaei4Kz4r3EzK1SAwlYyl2Jpe+RwEC3UcqcSuah9nMm8JDh0JdjLEHird38NtVvn64w8NRbG+u06NeuEUzeQ2Cb2QFumav6fIoQAqg9k3rZ6yJnC+DU9Zs3q8xs9nds1zl3rVSvvCAc5FFpc/U1TmHEeQtU2z188jYxtdU+04eU=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1736963261;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=f0hX9slKCdmAZPrw4d9Mc8tP6Sq7M8FYgsZIfrlpNqQ=;
	b=ruha0R5Oh506enUDt/gBgzB0lq/LqP7kN6lJAhzIsEoJV9yNKQXnoWtpLKwoUqOj
	9P4X2jYZckbeRyNKyttZhz0UjrVhpBbGt0eJA88p4WAHR0tx9ogb8M0RIwVhMFwUvuX
	G3i/64IlMwjkAdTxvWPZe3bzDWn9PGfT9PU9ZBQA=
Message-ID: <3f82f214-7a99-4b08-a494-347bbdb88ebd@apertussolutions.com>
Date: Wed, 15 Jan 2025 12:47:38 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 07/15] x86/hyperlaunch: initial support for hyperlaunch
 device tree
To: Jason Andryuk <jason.andryuk@amd.com>, xen-devel@lists.xenproject.org
Cc: christopher.w.clark@gmail.com, stefano.stabellini@amd.com,
 Jan Beulich <jbeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
 <20241226165740.29812-8-dpsmith@apertussolutions.com>
 <f02d01c0-2860-4645-b0a5-24cdc1415b12@amd.com>
Content-Language: en-US
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
In-Reply-To: <f02d01c0-2860-4645-b0a5-24cdc1415b12@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

On 1/10/25 17:20, Jason Andryuk wrote:
> On 2024-12-26 11:57, Daniel P. Smith wrote:
>> Add the ability to detect both a formal hyperlaunch device tree or a 
>> dom0less
>> device tree. If the hyperlaunch device tree is found, then count the 
>> number of
>> domain entries, reporting an error if more than one is found.
>>
>> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
> 
>> diff --git a/xen/arch/x86/domain-builder/fdt.c b/xen/arch/x86/domain- 
>> builder/fdt.c
>> index 4a3f80648f86..5793bdc9fd47 100644
>> --- a/xen/arch/x86/domain-builder/fdt.c
>> +++ b/xen/arch/x86/domain-builder/fdt.c
>> @@ -13,14 +13,77 @@
>>   #include "fdt.h"
>> +static int __init find_hyperlaunch_node(const void *fdt)
>> +{
>> +    int hv_node = fdt_path_offset(fdt, "/chosen/hypervisor");
>> +
>> +    if ( hv_node >= 0 )
>> +    {
>> +        /* Anything other than zero indicates no match */
>> +        if ( fdt_node_check_compatible(fdt, hv_node, "hypervisor,xen") )
>> +            return -ENODATA;
>> +        else
>> +            return hv_node;
>> +    }
>> +    else
>> +    {
>> +        /* Lood for dom0less config */
> 
> Look

Ack.

>> +        int node, chosen_node = fdt_path_offset(fdt, "/chosen");
>> +        if ( chosen_node < 0 )
>> +            return -ENOENT;
>> +
>> +        fdt_for_each_subnode(node, fdt, chosen_node)
>> +        {
>> +            if ( fdt_node_check_compatible(fdt, node, "xen,domain") 
>> == 0 )
>> +                return chosen_node;
>> +        }
>> +    }
>> +
>> +    return -ENODATA;
>> +}
>> +
>>   int __init has_hyperlaunch_fdt(struct boot_info *bi)
>>   {
>>       int ret = 0;
>>       const void *fdt = bootstrap_map_bm(&bi- 
>> >mods[HYPERLAUNCH_MODULE_IDX]);
>> -    if ( fdt_check_header(fdt) < 0 )
>> +    if ( !fdt || fdt_check_header(fdt) < 0 )
> 
> It seems to me the !fdt check should move into the earlier patch.  What 
> do you think?

You are correct, the two conditions should have been added together.


>>           ret = -EINVAL;
>> +    else
>> +        ret = find_hyperlaunch_node(fdt);
>> +
>> +    bootstrap_unmap();
>> +
>> +    return ret < 0 ? ret : 0;
>> +}
>> +
>> +int __init walk_hyperlaunch_fdt(struct boot_info *bi)
>> +{
>> +    int ret = 0, hv_node, node;
>> +    void *fdt = bootstrap_map_bm(&bi->mods[HYPERLAUNCH_MODULE_IDX]);
>> +
>> +    if ( unlikely(!fdt) )
>> +        return -EINVAL;
>> +
>> +    hv_node = find_hyperlaunch_node(fdt);
> 
> You call find_hyperlaunch_node() twice.  It seems like you can just have 
> has_hyperlaunch_fdt() return the node and pass it into this function.

Can do.

v/r,
dps


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 17:52:47 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 17:52:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872981.1283977 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY7ZN-0005sn-DF; Wed, 15 Jan 2025 17:52:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872981.1283977; Wed, 15 Jan 2025 17:52:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY7ZN-0005sg-A6; Wed, 15 Jan 2025 17:52:45 +0000
Received: by outflank-mailman (input) for mailman id 872981;
 Wed, 15 Jan 2025 17:52: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
 <SRS0=p+DL=UH=linutronix.de=tglx@srs-se1.protection.inumbo.net>)
 id 1tY7ZL-0005sa-U0
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 17:52:44 +0000
Received: from galois.linutronix.de (galois.linutronix.de
 [2a0a:51c0:0:12e:550::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 84b171ba-d369-11ef-a0e1-8be0dac302b0;
 Wed, 15 Jan 2025 18:52:42 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 84b171ba-d369-11ef-a0e1-8be0dac302b0
From: Thomas Gleixner <tglx@linutronix.de>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de;
	s=2020; t=1736963561;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=HoxPdbGDiDXMZjZ2YzakPSB0m74gINsG6VFgtuazYj8=;
	b=O59TkAiVIoh/kyWqt3sD2QUaiElCxlt4joNfsm5Vy47rl6VB5TFRsEG8yyBoGzvY2r/6mY
	lQrxl2KFOtZwXB8o2yGswqA28AwPR3ILexVj+8YMlHNoNTQyAqrecm5DQu43fEOAoeu1zB
	AUUJUV3mFLL/jKj4Q1eejS9vRnjN/1NreJFiVLN6lXCv97Xxmp1pRrzkdAR4+8k7oYySE3
	EjRlx3bwRLZ1kPZatpooq203bOQXFsUoJ5K9wvWgIoGkzYbbWPFekFpYB6FKtIibo4IGCl
	3qtrgWckX7984+Okk9ULQbx1KIxKVOK20qnnIXjJMWBsTxDlkgtJ8kE9XE9ROg==
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de;
	s=2020e; t=1736963561;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=HoxPdbGDiDXMZjZ2YzakPSB0m74gINsG6VFgtuazYj8=;
	b=fzGlQJbELsuQf/TIokTn215dpIYwMgfAYRUXgXNteW1TJ/rfCFCi40yte9UtrzUzNBp68H
	ns68VXLDVpNCEbAA==
To: Joel Granados <joel.granados@kernel.org>, Thomas =?utf-8?Q?Wei=C3=9Fsc?=
 =?utf-8?Q?huh?=
 <linux@weissschuh.net>, Kees Cook <kees@kernel.org>, Luis Chamberlain
 <mcgrof@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
 linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,
 linux-s390@vger.kernel.org, linux-crypto@vger.kernel.org,
 openipmi-developer@lists.sourceforge.net, intel-gfx@lists.freedesktop.org,
 dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
 linux-hyperv@vger.kernel.org, linux-rdma@vger.kernel.org,
 linux-raid@vger.kernel.org, linux-scsi@vger.kernel.org,
 linux-serial@vger.kernel.org, xen-devel@lists.xenproject.org,
 linux-aio@kvack.org, linux-fsdevel@vger.kernel.org, netfs@lists.linux.dev,
 codalist@coda.cs.cmu.edu, linux-mm@kvack.org, linux-nfs@vger.kernel.org,
 ocfs2-devel@lists.linux.dev, fsverity@lists.linux.dev,
 linux-xfs@vger.kernel.org, io-uring@vger.kernel.org, bpf@vger.kernel.org,
 kexec@lists.infradead.org, linux-trace-kernel@vger.kernel.org,
 linux-hardening@vger.kernel.org, apparmor@lists.ubuntu.com,
 linux-security-module@vger.kernel.org, keyrings@vger.kernel.org, Song Liu
 <song@kernel.org>, "Steven Rostedt (Google)" <rostedt@goodmis.org>,
 "Martin K. Petersen" <martin.petersen@oracle.com>, "Darrick J. Wong"
 <djwong@kernel.org>, Jani Nikula <jani.nikula@intel.com>, Corey Minyard
 <cminyard@mvista.com>, Joel Granados <joel.granados@kernel.org>
Subject: Re: [PATCH v2] treewide: const qualify ctl_tables where applicable
In-Reply-To: <20250110-jag-ctl_table_const-v2-1-0000e1663144@kernel.org>
References: <20250110-jag-ctl_table_const-v2-1-0000e1663144@kernel.org>
Date: Wed, 15 Jan 2025 18:52:40 +0100
Message-ID: <87jzawarrr.ffs@tglx>
MIME-Version: 1.0
Content-Type: text/plain

On Fri, Jan 10 2025 at 15:16, Joel Granados wrote:
> sed:
>     sed --in-place \
>       -e "s/struct ctl_table .table = &uts_kern/const struct ctl_table *table = \&uts_kern/" \
>       kernel/utsname_sysctl.c
>
> Reviewed-by: Song Liu <song@kernel.org>
> Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org> # for kernel/trace/
> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> # SCSI
> Reviewed-by: Darrick J. Wong <djwong@kernel.org> # xfs
> Acked-by: Jani Nikula <jani.nikula@intel.com>
> Acked-by: Corey Minyard <cminyard@mvista.com>
> Signed-off-by: Joel Granados <joel.granados@kernel.org>

Acked-by: Thomas Gleixner <tglx@linutronix.de>


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 18:06:28 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 18:06:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.872997.1283987 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY7mY-0008OL-Jn; Wed, 15 Jan 2025 18:06:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 872997.1283987; Wed, 15 Jan 2025 18:06:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY7mY-0008OE-Gw; Wed, 15 Jan 2025 18:06:22 +0000
Received: by outflank-mailman (input) for mailman id 872997;
 Wed, 15 Jan 2025 18:06:21 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=4o+i=UH=cloud.com=bernhard.kaindl@srs-se1.protection.inumbo.net>)
 id 1tY7mX-0008O8-HV
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 18:06:21 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6bbd00ee-d36b-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 19:06:19 +0100 (CET)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-ab2bb0822a4so11345666b.3
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 10:06:19 -0800 (PST)
Received: from localhost ([185.68.248.203]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c906005csm789043866b.3.2025.01.15.10.06.17
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 15 Jan 2025 10:06:18 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 6bbd00ee-d36b-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1736964379; x=1737569179; 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=pDIlhf6xp1rAQ7F54paIPqTjBOmTMHyr5SYWOsuAcFE=;
        b=WwERcvM6pPnaFsLZD/+IrpDV7nNAxX0apndyfY74UE1b9Oupt/AwTa1bG0NpTCpxPA
         VCpsw2zZMBY3i23Eu8042l4HhilPOKZbeNtB/PhBrZ3uuCVTVEa2EdxjlrQ7dP7sGeGs
         UOjR4EILYo3r9X88lRF7umMP73UZDAL24hQMo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736964379; x=1737569179;
        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=pDIlhf6xp1rAQ7F54paIPqTjBOmTMHyr5SYWOsuAcFE=;
        b=JDcTdd2GdCm/YM9l2CR6TfD5R1t7TGrFu6sYxGA+U/NCycCGn63PnQ9rN12cxfENet
         +MJTOiXFw1cdMXrEjmLJyDaBFsgTymkCig9LbNBGDZBc1AbQkdXFiNasDksva3VQuatu
         v5DO0AdIhniSSyvmXDIgs5d3ee4Dogv3EhVxhK46ra8Kbi6aaS4esfobClhbnoHZs3OI
         zDioxoxMmocnaLayPMcN/440GZUeQlGLmDJl9xRvN7tSF0g3BaoZEGE5jsyIWOCvjC3M
         LyR5w1Q5osOPuMsIVkMU+AiKjwcZTQrPyKdc1YMIgV2JMDOHXQISSluKN0aPpT98I4dK
         36MA==
X-Gm-Message-State: AOJu0Yw8BUuyMpzy3Sjq5FWL8oWETolgylhQv3edDdfF9PSsua7UFayW
	W2kXjbvOVHC9UE3rj8A0LWMBjYcsq9BJmThkYDLZbjESyzSw+tB0/I9HyCAGEUEbYqyVP/vW4aj
	4hcVANw==
X-Gm-Gg: ASbGncsV5kikm1mC3vD/zMGeiV3KGggu+oGlVmI/jrtyu7Mt+X9FgCpy26KSqHg4rb7
	MNmHrST7JiNBV2wH7/YKTNLwo5+OOQLjFrqFa+o29RTKgDbsyjxz4t5iiNMlxRC5Ihm0odPlPab
	2HrXR76WUBht/9hY2LibSSGDnTwNd+U9UFG0Z6CyvCTL5ZeaNQxyvfvegZ0BlsPLlO2DvByQS1/
	+JGUKN6godJQSM1ZeQGqRQRAv/5jwheTk5wmGYHVEnUT5RejPx6hadHyKX01g==
X-Google-Smtp-Source: AGHT+IEnDXDhsV5ZqXjtE6AmfjQfat6Utds7NZnekDEWjvyHh36k6fHnb1XveKvUXH0gi0S9m+LksA==
X-Received: by 2002:a17:907:6d20:b0:aa6:800a:1291 with SMTP id a640c23a62f3a-ab2ab167fb7mr2716565766b.7.1736964378724;
        Wed, 15 Jan 2025 10:06:18 -0800 (PST)
From: Bernhard Kaindl <bernhard.kaindl@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Bernhard Kaindl <bernhard.kaindl@cloud.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH] docs: Punctuation: Add missing commas after linking adverbs as intros
Date: Wed, 15 Jan 2025 19:06:15 +0100
Message-ID: <ad9d1d7db8d43c82a02f64b8a317d7ae6522dd62.1736964253.git.bernhard.kaindl@cloud.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Fix missing commas after linking adverbs such as currently, fortunately,
hence, instead, and thus, when used as linking adverbs at the beginning
of sentences. I saw them with LTeX; other checkers have this rule too.

Signed-off-by: Bernhard Kaindl <bernhard.kaindl@cloud.com>
---
 SUPPORT.md                                |  2 +-
 docs/designs/non-cooperative-migration.md | 10 +++++-----
 docs/designs/qemu-deprivilege.md          |  4 ++--
 docs/designs/xenstore-migration.md        |  4 ++--
 docs/man/xl.cfg.5.pod.in                  |  2 +-
 docs/misc/cache-coloring.rst              |  2 +-
 6 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/SUPPORT.md b/SUPPORT.md
index 9478b70b1b..019b49157e 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -453,7 +453,7 @@ A periodically repeating fixed timeslice scheduler.
 
     Status: Supported
 
-Currently only single-vcpu domains are supported.
+Currently, only single-vcpu domains are supported.
 
 ### Null Scheduler
 
diff --git a/docs/designs/non-cooperative-migration.md b/docs/designs/non-cooperative-migration.md
index 54496892ed..28c9301748 100644
--- a/docs/designs/non-cooperative-migration.md
+++ b/docs/designs/non-cooperative-migration.md
@@ -124,7 +124,7 @@ nodes.
 Because the console and store protocol shared pages are actually part of
 the guest memory image (in an E820 reserved region just below 4G in x86
 VMs) then the content will get migrated as part of the guest memory image.
-Hence no additional code is require to prevent any guest visible change in
+Hence, no additional code is required to prevent any guest visible change in
 the content.
 
 ### Shared Info
@@ -189,7 +189,7 @@ this fashion frontend and backend drivers can use the event channel as a
 *mailbox* to notify each other when a shared ring has been updated with new
 requests or response structures.
 
-Currently no event channel state is preserved on migration, requiring
+Currently, no event channel state is preserved on migration, requiring
 frontend and backend drivers to create and bind a complete new set of event
 channels in order to re-establish a protocol connection. Hence, one or more
 new save records will be required to transfer event channel state in order
@@ -222,12 +222,12 @@ The guest is responsible for managing its own grant table. No hypercall is
 required to grant a memory page to another domain. It is sufficient to find
 an unused grant entry and set bits in the entry to give read and/or write
 access to a remote domain also specified in the entry along with the page
-frame number. Thus the layout and content of the grant table logically
+frame number. Thus, the layout and content of the grant table logically
 forms part of the guest state.
 
-Currently no grant table state is migrated, requiring a guest to separately
+Currently, no grant table state is migrated, requiring a guest to separately
 maintain any state that it wishes to persist elsewhere in its memory image
-and then restore it after migration. Thus to avoid the need for such
+and then restore it after migration. Thus, to avoid the need for such
 explicit action by the guest, one or more new save records will be required
 to migrate the contents of the grant table.
 
diff --git a/docs/designs/qemu-deprivilege.md b/docs/designs/qemu-deprivilege.md
index 3be33adf6a..97ad35ec0e 100644
--- a/docs/designs/qemu-deprivilege.md
+++ b/docs/designs/qemu-deprivilege.md
@@ -179,7 +179,7 @@ being killed by the target process:
             kill(-1, 9);
     }
 
-Fortunately there is an assymetry we can take advantage of.  From the
+Fortunately, there is an asymmetry we can take advantage of.  From the
 POSIX spec:
 
 > For a process to have permission to send a signal to a process
@@ -269,7 +269,7 @@ environments.  We therefore need to either:
 The chroot (and seccomp?) happens late enough such that QEMU can
 initialize itself and open its disks. If you want to add a disk at run
 time via or insert a CD, you can't pass a path because QEMU is
-chrooted. Instead use the add-fd QMP command and use
+chrooted. Instead, use the add-fd QMP command and use
 /dev/fdset/<fdset-id> as the path.
 
 A further layer of restriction could be to set RLIMIT_NOFILES to '0',
diff --git a/docs/designs/xenstore-migration.md b/docs/designs/xenstore-migration.md
index 082314bf72..824aed9557 100644
--- a/docs/designs/xenstore-migration.md
+++ b/docs/designs/xenstore-migration.md
@@ -140,7 +140,7 @@ xenstored state that needs to be restored.
 | `evtchn-fd`    | The file descriptor used to communicate with |
 |                | the event channel driver                     |
 
-xenstored will resume in the original process context. Hence `rw-socket-fd`
+xenstored will resume in the original process context. Hence, `rw-socket-fd`
 simply specifies the file descriptor of the socket. Sockets are not always
 used, however, and so -1 will be used to denote an unused socket.
 
@@ -245,7 +245,7 @@ For `socket` connections it is as follows:
 | `socket-fd` | The file descriptor of the connected socket     |
 
 This type of connection is only relevant for live update, where the xenstored
-resumes in the original process context. Hence `socket-fd` simply specify
+resumes in the original process context. Hence, `socket-fd` simply specify
 the file descriptor of the socket connection.
 
 \pagebreak
diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index 8e1422104e..e3cb930cef 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -506,7 +506,7 @@ Load the specified file as firmware for the guest.
 
 =head4 PVH guest options
 
-Currently there's no firmware available for PVH guests, they should be
+Currently, there's no firmware available for PVH guests, they should be
 booted using the B<Direct Kernel Boot> method or the B<bootloader> option.
 
 =over 4
diff --git a/docs/misc/cache-coloring.rst b/docs/misc/cache-coloring.rst
index e156062aa2..022ed1f3da 100644
--- a/docs/misc/cache-coloring.rst
+++ b/docs/misc/cache-coloring.rst
@@ -4,7 +4,7 @@ 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.
+partitions for Dom0, DomUs and Xen itself. Currently, only ARM64 is supported.
 Cache coloring realizes per-set cache partitioning in software and is applicable
 to shared LLCs as implemented in Cortex-A53, Cortex-A72 and similar CPUs.
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Jan 15 18:08:25 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 18:08:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873005.1283997 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY7oV-0000Th-VB; Wed, 15 Jan 2025 18:08:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873005.1283997; Wed, 15 Jan 2025 18:08:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY7oV-0000Ta-SU; Wed, 15 Jan 2025 18:08:23 +0000
Received: by outflank-mailman (input) for mailman id 873005;
 Wed, 15 Jan 2025 18:08: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
 <SRS0=guqY=UH=gmail.com=milandjokic1995@srs-se1.protection.inumbo.net>)
 id 1tY7oU-0000TU-Rc
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 18:08:22 +0000
Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com
 [2607:f8b0:4864:20::f31])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b44d023d-d36b-11ef-a0e1-8be0dac302b0;
 Wed, 15 Jan 2025 19:08:22 +0100 (CET)
Received: by mail-qv1-xf31.google.com with SMTP id
 6a1803df08f44-6dd43aa1558so1356996d6.0
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 10:08:21 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b44d023d-d36b-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736964500; x=1737569300; 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=eVAxd3zBy5y7f7CQ/DxNy1wYULNrzX1ZLzl4D6RE/Uo=;
        b=UdIstHW3M779gwMoA1WCA/JX3osnLyfawZFJUZO3SPvVwoV4+xgVYHXEbiScOlGP/U
         lrDy1md9PTOcA+ngR6ex/OMKjYObuoEFa9c8X9fdfwQi3Q+ln/hxd1mfk5sWeMIUWYL2
         7iPm7mp9pibC/XP8m42NFlwEq0v/C3bYvLY015r1nGqKT0k/CcQvW3G0HzA9xN/xfIDM
         qX7XBA+cj5CIcWvYuBOyOQ2GZAMFmzz+qsESQzwWlmuhKdbfbfKH1DW1RyqQe6BSXlvf
         6DzWsW8jOuHUwP1VDulSlaYNn5s7JRq4wMc27F7y4Sl3ZMr5pOWM7NX4XbFlqvNvbToJ
         V9MA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736964501; x=1737569301;
        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=eVAxd3zBy5y7f7CQ/DxNy1wYULNrzX1ZLzl4D6RE/Uo=;
        b=NUc0zXe30CkZPRETxgzvQ1biHH8BKlCECkfA10AVSIGorLPvBPZBdS8v+2RGau+78J
         oV/ZVI1jVS7DQr2r+MFxWz6ASLmL9gZ3QDJFYaCUW+/Vc8QGH9YHtjDncm7Eau+n6YL1
         viHmJoZTJWVSVcRkFgQKgzERSAy+759C0/94pbGUmPmZHP1nyw7xz1Ptcj33U36sc0zd
         K7JDV5Tu3h4mOBncPwA7W96YHmtTV2rJwxbjjFgiYCz7c8fCvyKsxa7LFfbRR1VqPNQk
         UKdS4RVfwoPEfnza7WC7PzlgTpVFELam6yOEDJkiuKVa9UzvFkoz7ffE6umpN/5oM7MR
         wSjw==
X-Forwarded-Encrypted: i=1; AJvYcCVchR9o010LhgulcsaBDZyqsb5b+WZXIP8WXwOlT+EEtlYWC9qDIpNgRb1YVb9rr4t/0FUsdFttBpQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy0K7RQmfxzN0G6+s9XGfK/0eRjTxjFvZ/MlL52ZmJmbWZhOSWA
	30sMyIxCl/HVtrW5iFvlJzfMkgIwQsZL6Q1L0vINtYpw1Xlu3rKp1UL0TFzR/sTkC+KaXFXr4Vr
	uRmkj/wqf9POvDS+q9d5I1gAh/y8=
X-Gm-Gg: ASbGncvjkEfQ9nU9qXcPzsPCDtVo+dkqFONv2GBacnt5Fbn7kz5ew+Cf5EkJRXwwxq2
	FpuqiGlq4wsvavI3MyULM3n5NHkJmfhadO7Kp3g==
X-Google-Smtp-Source: AGHT+IGFU6Cpsmr7C29OyQc7heB1EWXPIOaqr8NIc91ZyH2jiYN8FoqP3+W/ADTqDwyc+/xzyTGsbdLQtFh2zzoJMIE=
X-Received: by 2002:a05:6214:5bc2:b0:6d8:a730:110d with SMTP id
 6a1803df08f44-6df9b0eea41mr463994756d6.0.1736964500692; Wed, 15 Jan 2025
 10:08:20 -0800 (PST)
MIME-Version: 1.0
References: <e4a649a7fdfc8fcf5f48a0bc4e76e5d546078083.1736868605.git.Slavisa.Petrovic@rt-rk.com>
 <CAAhSdy2rfbNT6tTK7i7rV6M1kNs2bFOQtN5QZpJ2xPrJx6WXjw@mail.gmail.com>
In-Reply-To: <CAAhSdy2rfbNT6tTK7i7rV6M1kNs2bFOQtN5QZpJ2xPrJx6WXjw@mail.gmail.com>
From: =?UTF-8?B?TWlsYW4gxJBva2nEhw==?= <milandjokic1995@gmail.com>
Date: Wed, 15 Jan 2025 19:08:10 +0100
X-Gm-Features: AbW1kvaLrXlpYISDcragOXfUEvYS3I_dYhZbSgLg1Ehoz_myWQJSREjiwkAvkNc
Message-ID: <CAKp59VGvJ6dOU06BhLVU30ioWTShWyo-0Ngty9MM_aH1rKYoWA@mail.gmail.com>
Subject: Re: [PATCH] riscv: Add initial Xen guest support for RISC-V
To: Anup Patel <anup@brainfault.org>
Cc: linux-riscv@lists.infradead.org, paul.walmsley@sifive.com, 
	palmer@dabbelt.com, aou@eecs.berkeley.edu, jgross@suse.com, 
	sstabellini@kernel.org, oleksandr_tyshchenko@epam.com, 
	Slavisa.Petrovic@rt-rk.com, Milan.Djokic@rt-rk.com, 
	rafael.j.wysocki@intel.com, sunilvl@ventanamicro.com, takakura@valinux.co.jp, 
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, 
	iommu@lists.linux.dev
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 14, 2025 at 5:41=E2=80=AFPM Anup Patel <anup@brainfault.org> wr=
ote:
>
> On Tue, Jan 14, 2025 at 9:41=E2=80=AFPM Milan Djokic <milandjokic1995@gma=
il.com> wrote:
> >
> > From: Slavisa Petrovic <Slavisa.Petrovic@rt-rk.com>
> >
> > This patch introduces initial support for running RISC-V as a Xen guest=
.
> > It provides the necessary infrastructure and stubs for Xen-specific
> > operations. Key changes include:
> >
> > - Modifications to the RISC-V kernel to integrate Xen-specific hypercal=
ls
> >   and interfaces, with function implementations stubbed for future work=
.
> > - Introduction of Xen-specific headers for RISC-V, including event
> >   handling, hypervisor interaction, and page management. Functions are
> >   defined but not yet implemented.
> > - Stub implementations for memory management, grant tables, and context
> >   switching in the Xen environment, allowing further development and
> >   integration.
> >
> > Signed-off-by: Milan Djokic <Milan.Djokic@rt-rk.com>
> > Signed-off-by: Slavisa Petrovic <Slavisa.Petrovic@rt-rk.com>
>
> A single patch with many changes is hard to review.
>
> Please convert this patch into a series with smaller patches.
> Also, include a cover letter in the series explaining how to
> test Xen on RISC-V.
>
> Regards,
> Anup
>
Hello Anup,

We're currently working on patch breakdown in smaller logical parts.
Will be converted into patch series in the next revision.

BR,
Milan


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 18:26:30 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 18:26:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873022.1284006 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY85p-0004M4-BC; Wed, 15 Jan 2025 18:26:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873022.1284006; Wed, 15 Jan 2025 18:26:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY85p-0004Lx-8H; Wed, 15 Jan 2025 18:26:17 +0000
Received: by outflank-mailman (input) for mailman id 873022;
 Wed, 15 Jan 2025 18:26: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
 <SRS0=guqY=UH=gmail.com=milandjokic1995@srs-se1.protection.inumbo.net>)
 id 1tY85n-0004Lp-Qb
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 18:26:15 +0000
Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com
 [2607:f8b0:4864:20::f35])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 33d4f5a2-d36e-11ef-a0e1-8be0dac302b0;
 Wed, 15 Jan 2025 19:26:14 +0100 (CET)
Received: by mail-qv1-xf35.google.com with SMTP id
 6a1803df08f44-6e17d3e92d9so1149796d6.1
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 10:26:14 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 33d4f5a2-d36e-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736965573; x=1737570373; 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=56NS9QFu3nqyt2X92cCfR3Efbv5GWPlnT7v7XAEeafM=;
        b=Gt4Ew70L2dkkCW64S5yjgBsF9o9mZ4Dj2dpysi+U4j3GUHW8XyHsbBrlgm0n95uCSf
         0jdP8OZFgFRgDLkv/HxQzVZ4t1/xMrNsS+M5hFFrOkEUBT6uGNWURv9PgZ4LDeJw2Z3/
         m8V2iCq3KiDndE5et8287PUkMqNbj6j1+QybertmvYUH6ZooG9Ts4Xi5IRXMfsuFeBVe
         OqEmwfgMyCc6h1Ex5Eda9KTSuilEieWw/3AW2BXrZg1apJa0s6uiZW60jfXnov4QHX43
         onwB40BJ8fsX1gBb7uNvFfBL/5y2qo7ItaW3CwoJ9fxgY8OqKo4k8M+gG3jGNYYBkf9g
         xnNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736965573; x=1737570373;
        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=56NS9QFu3nqyt2X92cCfR3Efbv5GWPlnT7v7XAEeafM=;
        b=YAMInJ4URGPw7jYuB00fnVr8hpUixpNJexRztim7dF7FAIBvEqqVVlhyvso7bgWI/R
         uTHMj2wRKMBLAhTDH8feuofOTH1SoyxDbUGtQonB7zdzuCNGSVxcPT/29b7M9Zwu8s2w
         lGgdHiIE43CbgoiMuRrgDi7qfN2/vQC4dzINuJnXqEc6pjXuSlszc4CCxJHzoi/xn2P9
         9PO/gsLC6Aw/kpW+hitZ9uA32eXKPy+c2lYhsMdrZ7QknR81r42RyejKp7jaOWcYNVCp
         sZfhBxQ7iu9tX3EJYeQNxNk4pV8qfPw0gJtoL4DvG6WR9EeUsJmZ/AvyFlpNbnQtTeDO
         nxRA==
X-Forwarded-Encrypted: i=1; AJvYcCWiPlAh8I8CW5SwjLKYPoz6zD0t4ded0YPL45N3cxCwIdpVw1aoVV5sD0JBafv+szWbhHafAJRxk0s=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzGqk78F02ioJcveNqUcmoSvjEjEiR6GgWP2J7zRiNOi+SxueJF
	ATW3feV6Eyfb4cyGCwgaiqUTwlEFE99+v6y72chOZ6yshQ6budfPVehYd7AIG8tNpkZ7SwMsgR4
	CTXgbuUYUJGGSkbK4e4GpVhmILtM=
X-Gm-Gg: ASbGncvaNqx1njxeI20b9DeqRNaKNEBShBwKT3wFbL51roYCk3FYYSsWrDI4dv4C2SS
	YKwC/mfIig8f1bj8mIP8zfqABk0m+B7ROyj7Mwg==
X-Google-Smtp-Source: AGHT+IFZ7LDpCgk+/ixdVgpNuaVhVLnP72hjhsHZcggTnKpcAZNiZOdxIC0i/Y0rcAWUWwUH/WEMoeQpL02BdxVsSe4=
X-Received: by 2002:a05:6214:5bc2:b0:6d8:a730:110d with SMTP id
 6a1803df08f44-6df9b0eea41mr464717506d6.0.1736965573650; Wed, 15 Jan 2025
 10:26:13 -0800 (PST)
MIME-Version: 1.0
References: <e4a649a7fdfc8fcf5f48a0bc4e76e5d546078083.1736868605.git.Slavisa.Petrovic@rt-rk.com>
 <0cac0b13-128c-4d8b-b235-09d7b440ad8e@vates.tech>
In-Reply-To: <0cac0b13-128c-4d8b-b235-09d7b440ad8e@vates.tech>
From: =?UTF-8?B?TWlsYW4gxJBva2nEhw==?= <milandjokic1995@gmail.com>
Date: Wed, 15 Jan 2025 19:26:03 +0100
X-Gm-Features: AbW1kvamvNb2xBNlt0NnBIzllhDKyUtK5Hh8vPP6WZ7rdE4FF79WjPfZk5asYMA
Message-ID: <CAKp59VHBLtpxk7MD3StO8v8M5vdqbWU7AZaoxukzYPFCmSF91w@mail.gmail.com>
Subject: Re: [PATCH] riscv: Add initial Xen guest support for RISC-V
To: Teddy Astie <teddy.astie@vates.tech>
Cc: linux-riscv@lists.infradead.org, paul.walmsley@sifive.com, 
	palmer@dabbelt.com, aou@eecs.berkeley.edu, jgross@suse.com, 
	sstabellini@kernel.org, oleksandr_tyshchenko@epam.com, 
	Slavisa.Petrovic@rt-rk.com, Milan.Djokic@rt-rk.com, 
	rafael.j.wysocki@intel.com, sunilvl@ventanamicro.com, takakura@valinux.co.jp, 
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, 
	iommu@lists.linux.dev
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Teddy,

On Tue, Jan 14, 2025 at 6:51=E2=80=AFPM Teddy Astie <teddy.astie@vates.tech=
> wrote:
>
> Le 14/01/2025 =C3=A0 17:13, Milan Djokic a =C3=A9crit :
> > diff --git a/test.txt b/test.txt
> > new file mode 100644
> > index 000000000000..e54267998982
> > --- /dev/null
> > +++ b/test.txt
> > @@ -0,0 +1,21 @@
> > +WARNING: added, moved or deleted file(s), does MAINTAINERS need updati=
ng?
> > +#120:
> > +new file mode 100644
> > +
> > +WARNING: do not add new typedefs
> > +#808: FILE: include/xen/riscv/interface.h:15:
> > ++    typedef struct { union { type * p; uint64_aligned_t q; }; }  \
> > +
> > +WARNING: please, no spaces at the start of a line
> > +#1006: FILE: include/xen/riscv/swiotlb-xen.h:10:
> > ++    return 0;$
> > +
> > +total: 0 errors, 3 warnings, 810 lines checked
> > +
> > +NOTE: For some of the reported defects, checkpatch may be able to
> > +      mechanically convert to the typical style using --fix or --fix-i=
nplace.
> > +
> > +0001-riscv-Add-initial-Xen-guest-support-for-RISC-V.patch has style pr=
oblems, please review.
> > +
> > +NOTE: If any of the errors are false positives, please report
> > +      them to the maintainer, see CHECKPATCH in MAINTAINERS.
>
> I am not sure you want this here.
>
Sorry, this one is added by accident. Will be removed.

>  > diff --git a/arch/riscv/include/asm/hypervisor.h
> b/arch/riscv/include/> asm/hypervisor.h
>  > new file mode 100644
>  > index 000000000000..3a117afe57f0
>  > --- /dev/null
>  > +++ b/arch/riscv/include/asm/hypervisor.h
>  > @@ -0,0 +1,9 @@
>  > +/* SPDX-License-Identifier: GPL-2.0 */
>  > +#ifndef _ASM_RISCV_HYPERVISOR_H
>  > +#define _ASM_RISCV_HYPERVISOR_H
>  > +
>  > +#include <asm/xen/hypervisor.h>
>  > +
>  > +void kvm_init_hyp_services(void);
>  > +
>  > +#endif
>
> kvm_init_hyp_services seems KVM-specific and doesn't seem to exist (yet)
> for RISC-V.
>
Yes, we'll remove it in the next revision.

BR,
Milan


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 19:04:33 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 19:04:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873032.1284018 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY8gm-0002Mc-3V; Wed, 15 Jan 2025 19:04:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873032.1284018; Wed, 15 Jan 2025 19:04:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY8gl-0002MV-Ux; Wed, 15 Jan 2025 19:04:27 +0000
Received: by outflank-mailman (input) for mailman id 873032;
 Wed, 15 Jan 2025 19:04:26 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=guqY=UH=gmail.com=milandjokic1995@srs-se1.protection.inumbo.net>)
 id 1tY8gj-0002M8-Rh
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 19:04:26 +0000
Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com
 [2607:f8b0:4864:20::f36])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 842bc959-d373-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 20:04:17 +0100 (CET)
Received: by mail-qv1-xf36.google.com with SMTP id
 6a1803df08f44-6dcc42b5e30so2225326d6.1
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 11:04:17 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 842bc959-d373-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736967856; x=1737572656; 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=+2dlMEtOJskblto9AGvzKoxpcm8HKf9fuXxAXAIcY3s=;
        b=nM4EtD1br2RIu4+iUAmSwcJRzQ/cA9IZmtzLoVvphdTLZM5avNqbrZ19JCbvjleTic
         ghP1oKaZ0EFrzAopMhZILCC7ZQgNBVC6FwHRMgmj1CZ6eCYNZAkEmxn0FE9U2i3lB4dF
         otXgjIjXZFh1q8meHtE+aUhbf/HSjT7mzd3GMm+2r0M+cpOSTTQdixhZJ0iVKywOZb9a
         97zeQ5UCeuzn6tnLQgODnnfRwkcO2qonJOTIHVExWiGkaw1OM/+A24HZVK19gLH0Iqd1
         z0LXgnH38nJ4AGw/x7wPBg6FXpjGrCHDHNE6uwJmMiCyR049ZRZvh0ehNL3pJyb2+stY
         3eig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736967856; x=1737572656;
        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=+2dlMEtOJskblto9AGvzKoxpcm8HKf9fuXxAXAIcY3s=;
        b=Z7zVkyoBH62mZJ3cKLe7WhX5N24zglqAaxjD5t1ZXEyq5ggrSYtfEoxWYPkeBkSTXQ
         LS1FFgqeP11Q13zlu+bT534D9cIpPbxR0jz7mZhIU1RB+s+1l+Rysp6Htbh1C+MnkPxR
         FdW7luMV2ScxSl9qLWxnfCbbNhLF5nDRYkAjhMRiboI7d6rJV31M5xkkM0EuPeTZx3bT
         5mRe5BId66A9a0VQ8p+6KanAQ+ZovzbM4arSGGpK8xqg0BUU+kP6fbaNd55Xe9Qdrxzz
         ZkqDz7XJ8kYGmOxH26JX8rPdJba3DPGodNmKlfLNNtbnAlFKKanbAo6EQvLf9kn0VNZI
         ukpQ==
X-Forwarded-Encrypted: i=1; AJvYcCU2Lh48Ac1MJ9PDwMt4877GoBuVy7cW/QtE6UvzNvgD3Ifm/dO7bOYkImeuu95TUYs7bHvj2Udrd2Q=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwQOO9/9zU5ZPglkTkL45kbfKbrb5i2trEqeQnjiI0Tc3NvsbrQ
	JvwVUuM4lzH2o8fsjxkitTUJ1g7Yi4rp8t548DfPiDcKGsv4pKLZLfDS4N3KOPQZv2FJ15hmnbt
	P1kEk2bQOlJOA219qj90eX5OZ5PE=
X-Gm-Gg: ASbGncsoz32xpWua7ZAvNmrCYPscNlcN8MGR3A1Ve/YGXn82W7v8Z7252ZUXSZa5GV+
	z0Z7PRn7YG94M4MIUkYmy3mgdjp5UZzd9n5uCig==
X-Google-Smtp-Source: AGHT+IGI4lcUdJPCHCFHjdkAyUI2JT5pbfIvrQN74Czf9iKGrpxdSkFJqH3k13WWqStXFxsqsIyrTVU1n2W/n6qOEaQ=
X-Received: by 2002:a05:6214:5f11:b0:6cb:99db:bdd5 with SMTP id
 6a1803df08f44-6df9b322cbfmr520265646d6.39.1736967855591; Wed, 15 Jan 2025
 11:04:15 -0800 (PST)
MIME-Version: 1.0
References: <e4a649a7fdfc8fcf5f48a0bc4e76e5d546078083.1736868605.git.Slavisa.Petrovic@rt-rk.com>
 <20250114-316084c962eb867c0b681043@orel>
In-Reply-To: <20250114-316084c962eb867c0b681043@orel>
From: =?UTF-8?B?TWlsYW4gxJBva2nEhw==?= <milandjokic1995@gmail.com>
Date: Wed, 15 Jan 2025 20:04:05 +0100
X-Gm-Features: AbW1kvaMAW7oB9KE2lT6kR3aXE4HRswev5V9GEAXJ6SpYYM-nTsHfEPp3Mi3MHc
Message-ID: <CAKp59VFkW8F2xHsgAxiw138ZrpQJL8R5cTkF8f9vY40iEoRbWg@mail.gmail.com>
Subject: Re: [PATCH] riscv: Add initial Xen guest support for RISC-V
To: Andrew Jones <ajones@ventanamicro.com>
Cc: linux-riscv@lists.infradead.org, jgross@suse.com, aou@eecs.berkeley.edu, 
	Milan.Djokic@rt-rk.com, rafael.j.wysocki@intel.com, 
	linux-kernel@vger.kernel.org, oleksandr_tyshchenko@epam.com, 
	iommu@lists.linux.dev, sstabellini@kernel.org, palmer@dabbelt.com, 
	paul.walmsley@sifive.com, xen-devel@lists.xenproject.org, 
	Slavisa.Petrovic@rt-rk.com, takakura@valinux.co.jp
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Andrew,

On Tue, Jan 14, 2025 at 7:18=E2=80=AFPM Andrew Jones <ajones@ventanamicro.c=
om> wrote:
>
> On Tue, Jan 14, 2025 at 05:09:36PM +0100, Milan Djokic wrote:
> > From: Slavisa Petrovic <Slavisa.Petrovic@rt-rk.com>
> >
> > This patch introduces initial support for running RISC-V as a Xen guest=
.
> > It provides the necessary infrastructure and stubs for Xen-specific
> > operations. Key changes include:
> >
> > - Modifications to the RISC-V kernel to integrate Xen-specific hypercal=
ls
> >   and interfaces, with function implementations stubbed for future work=
.
> > - Introduction of Xen-specific headers for RISC-V, including event
> >   handling, hypervisor interaction, and page management. Functions are
> >   defined but not yet implemented.
> > - Stub implementations for memory management, grant tables, and context
> >   switching in the Xen environment, allowing further development and
> >   integration.
> >
> > Signed-off-by: Milan Djokic <Milan.Djokic@rt-rk.com>
> > Signed-off-by: Slavisa Petrovic <Slavisa.Petrovic@rt-rk.com>
> > ---
> >  arch/riscv/Kbuild                        |   1 +
> >  arch/riscv/Kconfig                       |  19 +++
> >  arch/riscv/include/asm/cpu.h             |   1 +
> >  arch/riscv/include/asm/hypervisor.h      |   9 ++
> >  arch/riscv/include/asm/irq.h             |   5 +
> >  arch/riscv/include/asm/sync_bitops.h     |  27 ++++
> >  arch/riscv/include/asm/xen/events.h      |  28 ++++
> >  arch/riscv/include/asm/xen/hypercall.h   |   2 +
> >  arch/riscv/include/asm/xen/hypervisor.h  |   2 +
> >  arch/riscv/include/asm/xen/interface.h   |   2 +
> >  arch/riscv/include/asm/xen/page.h        |   3 +
> >  arch/riscv/include/asm/xen/swiotlb-xen.h |   2 +
> >  arch/riscv/xen/Makefile                  |   2 +
> >  arch/riscv/xen/enlighten.c               | 164 +++++++++++++++++++++++
> >  arch/riscv/xen/grant-table.c             |  57 ++++++++
> >  arch/riscv/xen/hypercall.S               |  71 ++++++++++
> >  arch/riscv/xen/p2m.c                     |  76 +++++++++++
> >  include/xen/interface/io/protocols.h     |   3 +
> >  include/xen/riscv/hypercall.h            |  71 ++++++++++
> >  include/xen/riscv/hypervisor.h           |  26 ++++
> >  include/xen/riscv/interface.h            |  85 ++++++++++++
> >  include/xen/riscv/page.h                 | 106 +++++++++++++++
> >  include/xen/riscv/swiotlb-xen.h          |  13 ++
> >  test.txt                                 |  21 +++
> >  24 files changed, 796 insertions(+)
> >  create mode 100644 arch/riscv/include/asm/hypervisor.h
> >  create mode 100644 arch/riscv/include/asm/sync_bitops.h
> >  create mode 100644 arch/riscv/include/asm/xen/events.h
> >  create mode 100644 arch/riscv/include/asm/xen/hypercall.h
> >  create mode 100644 arch/riscv/include/asm/xen/hypervisor.h
> >  create mode 100644 arch/riscv/include/asm/xen/interface.h
> >  create mode 100644 arch/riscv/include/asm/xen/page.h
> >  create mode 100644 arch/riscv/include/asm/xen/swiotlb-xen.h
> >  create mode 100644 arch/riscv/xen/Makefile
> >  create mode 100644 arch/riscv/xen/enlighten.c
> >  create mode 100644 arch/riscv/xen/grant-table.c
> >  create mode 100644 arch/riscv/xen/hypercall.S
> >  create mode 100644 arch/riscv/xen/p2m.c
> >  create mode 100644 include/xen/riscv/hypercall.h
> >  create mode 100644 include/xen/riscv/hypervisor.h
> >  create mode 100644 include/xen/riscv/interface.h
> >  create mode 100644 include/xen/riscv/page.h
> >  create mode 100644 include/xen/riscv/swiotlb-xen.h
> >  create mode 100644 test.txt
> >
> > diff --git a/arch/riscv/Kbuild b/arch/riscv/Kbuild
> > index 2c585f7a0b6e..d9b71deed2cd 100644
> > --- a/arch/riscv/Kbuild
> > +++ b/arch/riscv/Kbuild
> > @@ -5,6 +5,7 @@ obj-$(CONFIG_BUILTIN_DTB) +=3D boot/dts/
> >  obj-$(CONFIG_CRYPTO) +=3D crypto/
> >  obj-y +=3D errata/
> >  obj-$(CONFIG_KVM) +=3D kvm/
> > +obj-$(CONFIG_XEN) +=3D xen/
> >
> >  obj-$(CONFIG_ARCH_SUPPORTS_KEXEC_PURGATORY) +=3D purgatory/
> >
> > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > index d4a7ca0388c0..13ea75221524 100644
> > --- a/arch/riscv/Kconfig
> > +++ b/arch/riscv/Kconfig
> > @@ -1071,6 +1071,25 @@ config PARAVIRT_TIME_ACCOUNTING
> >
> >         If in doubt, say N here.
> >
> > +config XEN_DOM0
> > +     def_bool y
> > +     depends on XEN
> > +
> > +config XEN
> > +     bool "Xen guest support on RISCV"
> > +     depends on RISCV && OF
> > +     select PARAVIRT
> > +     help
> > +       Enables support for running Linux as a Xen guest on RISC-V.
> > +
> > +       Xen is a type-1 hypervisor that allows multiple operating syste=
ms
> > +       to run on the same hardware. Enabling this option allows the ke=
rnel
> > +       to function as a guest under the Xen hypervisor on RISC-V platf=
orms.
> > +
> > +       Say Y if you want to run this kernel as a guest under Xen on RI=
SC-V.
> > +
> > +       If unsure, say N.
> > +
> >  config RELOCATABLE
> >       bool "Build a relocatable kernel"
> >       depends on MMU && 64BIT && !XIP_KERNEL
> > diff --git a/arch/riscv/include/asm/cpu.h b/arch/riscv/include/asm/cpu.=
h
> > index 28d45a6678ce..fb2aac6a068e 100644
> > --- a/arch/riscv/include/asm/cpu.h
> > +++ b/arch/riscv/include/asm/cpu.h
> > @@ -4,5 +4,6 @@
> >  #define _ASM_CPU_H
> >
> >  /* This header is required unconditionally by the ACPI core */
> > +#include <linux/cpu.h>
> >
> >  #endif /* _ASM_CPU_H */
> > diff --git a/arch/riscv/include/asm/hypervisor.h b/arch/riscv/include/a=
sm/hypervisor.h
> > new file mode 100644
> > index 000000000000..3a117afe57f0
> > --- /dev/null
> > +++ b/arch/riscv/include/asm/hypervisor.h
> > @@ -0,0 +1,9 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +#ifndef _ASM_RISCV_HYPERVISOR_H
> > +#define _ASM_RISCV_HYPERVISOR_H
> > +
> > +#include <asm/xen/hypervisor.h>
> > +
> > +void kvm_init_hyp_services(void);
>
> riscv doesn't have kvm_init_hyp_services(), which is why it didn't have
> asm/hypervisor.h. I also didn't see where asm/hypervisor.h is getting
> included in this patch, so this hunk should be dropped.
>
We initially added this file because xenbus implementation includes it
(xenbus_probe_backend.c). Although xenbus is also not yet functional
for RISC-V, we can remove this file, I understand that it's not
relevant at this point.

> > +
> > +#endif
> > diff --git a/arch/riscv/include/asm/irq.h b/arch/riscv/include/asm/irq.=
h
> > index 7b038f3b7cb0..b14621848eae 100644
> > --- a/arch/riscv/include/asm/irq.h
> > +++ b/arch/riscv/include/asm/irq.h
> > @@ -23,6 +23,11 @@ void riscv_set_intc_hwnode_fn(struct fwnode_handle *=
(*fn)(void));
> >
> >  struct fwnode_handle *riscv_get_intc_hwnode(void);
> >
> > +static inline int nr_legacy_irqs(void)
> > +{
> > +     return 0;
> > +}
> > +
> >  #ifdef CONFIG_ACPI
> >
> >  enum riscv_irqchip_type {
> > diff --git a/arch/riscv/include/asm/sync_bitops.h b/arch/riscv/include/=
asm/sync_bitops.h
> > new file mode 100644
> > index 000000000000..28e3c64ba852
> > --- /dev/null
> > +++ b/arch/riscv/include/asm/sync_bitops.h
> > @@ -0,0 +1,27 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +#ifndef __ASM_SYNC_BITOPS_H__
> > +#define __ASM_SYNC_BITOPS_H__
> > +
> > +#include <asm/bitops.h>
> > +#include <asm/cmpxchg.h>
> > +
> > +/* sync_bitops functions are equivalent to the SMP implementation of t=
he
> > + * original functions, independently from CONFIG_SMP being defined.
> > + *
> > + * We need them because _set_bit etc are not SMP safe if !CONFIG_SMP. =
But
> > + * under Xen you might be communicating with a completely external ent=
ity
> > + * who might be on another CPU (e.g. two uniprocessor guests communica=
ting
> > + * via event channels and grant tables). So we need a variant of the b=
it
> > + * ops which are SMP safe even on a UP kernel.
> > + */
> > +
> > +#define sync_set_bit(nr, p)             set_bit(nr, p)
> > +#define sync_clear_bit(nr, p)           clear_bit(nr, p)
> > +#define sync_change_bit(nr, p)          change_bit(nr, p)
> > +#define sync_test_and_set_bit(nr, p)    test_and_set_bit(nr, p)
> > +#define sync_test_and_clear_bit(nr, p)  test_and_clear_bit(nr, p)
> > +#define sync_test_and_change_bit(nr, p) test_and_change_bit(nr, p)
> > +#define sync_test_bit(nr, addr)         test_bit(nr, addr)
> > +#define arch_sync_cmpxchg               arch_cmpxchg
> > +
> > +#endif
> > diff --git a/arch/riscv/include/asm/xen/events.h b/arch/riscv/include/a=
sm/xen/events.h
> > new file mode 100644
> > index 000000000000..a3d0332ca46c
> > --- /dev/null
> > +++ b/arch/riscv/include/asm/xen/events.h
> > @@ -0,0 +1,28 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +#ifndef _ASM_RISCV_XEN_EVENTS_H
> > +#define _ASM_RISCV_XEN_EVENTS_H
> > +
> > +#include <asm/ptrace.h>
> > +#include <asm/atomic.h>
> > +
> > +enum ipi_vector {
> > +     XEN_PLACEHOLDER_VECTOR,
> > +
> > +     /* Xen IPIs go here */
> > +     XEN_NR_IPIS,
> > +};
> > +
> > +static inline int xen_irqs_disabled(struct pt_regs *regs)
> > +{
> > +     return 0;
> > +}
> > +
> > +#define xchg_xen_ulong(ptr, val) xchg((ptr), (val))
> > +
> > +/* Rebind event channel is supported by default */
> > +static inline bool xen_support_evtchn_rebind(void)
> > +{
> > +     return true;
> > +}
> > +
> > +#endif /* _ASM_RISCV_XEN_EVENTS_H */
> > diff --git a/arch/riscv/include/asm/xen/hypercall.h b/arch/riscv/includ=
e/asm/xen/hypercall.h
> > new file mode 100644
> > index 000000000000..0841ba1f0835
> > --- /dev/null
> > +++ b/arch/riscv/include/asm/xen/hypercall.h
> > @@ -0,0 +1,2 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +#include <xen/riscv/hypercall.h>
> > diff --git a/arch/riscv/include/asm/xen/hypervisor.h b/arch/riscv/inclu=
de/asm/xen/hypervisor.h
> > new file mode 100644
> > index 000000000000..05b7c834d0a9
> > --- /dev/null
> > +++ b/arch/riscv/include/asm/xen/hypervisor.h
> > @@ -0,0 +1,2 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +#include <xen/riscv/hypervisor.h>
> > diff --git a/arch/riscv/include/asm/xen/interface.h b/arch/riscv/includ=
e/asm/xen/interface.h
> > new file mode 100644
> > index 000000000000..9f30b1d7e77c
> > --- /dev/null
> > +++ b/arch/riscv/include/asm/xen/interface.h
> > @@ -0,0 +1,2 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +#include <xen/riscv/interface.h>
> > diff --git a/arch/riscv/include/asm/xen/page.h b/arch/riscv/include/asm=
/xen/page.h
> > new file mode 100644
> > index 000000000000..c8f5b873445b
> > --- /dev/null
> > +++ b/arch/riscv/include/asm/xen/page.h
> > @@ -0,0 +1,3 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +#include <xen/riscv/page.h>
> > +#include <asm/mmu.h>
> > diff --git a/arch/riscv/include/asm/xen/swiotlb-xen.h b/arch/riscv/incl=
ude/asm/xen/swiotlb-xen.h
> > new file mode 100644
> > index 000000000000..aa3bc339df03
> > --- /dev/null
> > +++ b/arch/riscv/include/asm/xen/swiotlb-xen.h
> > @@ -0,0 +1,2 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +#include <xen/riscv/swiotlb-xen.h>
> > diff --git a/arch/riscv/xen/Makefile b/arch/riscv/xen/Makefile
> > new file mode 100644
> > index 000000000000..f6d3a357e4c7
> > --- /dev/null
> > +++ b/arch/riscv/xen/Makefile
> > @@ -0,0 +1,2 @@
> > +# SPDX-License-Identifier: GPL-2.0-only
> > +obj-y :=3D enlighten.o p2m.o grant-table.o hypercall.o
> > diff --git a/arch/riscv/xen/enlighten.c b/arch/riscv/xen/enlighten.c
> > new file mode 100644
> > index 000000000000..28bd66c288f9
> > --- /dev/null
> > +++ b/arch/riscv/xen/enlighten.c
> > @@ -0,0 +1,164 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +#include <xen/xen.h>
> > +#include <xen/events.h>
> > +#include <xen/grant_table.h>
> > +#include <xen/hvm.h>
> > +#include <xen/interface/vcpu.h>
> > +#include <xen/interface/xen.h>
> > +#include <xen/interface/memory.h>
> > +#include <xen/interface/hvm/params.h>
> > +#include <xen/features.h>
> > +#include <xen/platform_pci.h>
> > +#include <xen/xenbus.h>
> > +#include <xen/page.h>
> > +#include <xen/interface/sched.h>
> > +#include <xen/xen-ops.h>
> > +#include <asm/xen/hypervisor.h>
> > +#include <asm/xen/hypercall.h>
> > +#include <asm/efi.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/irqreturn.h>
> > +#include <linux/module.h>
> > +#include <linux/of.h>
> > +#include <linux/of_fdt.h>
> > +#include <linux/of_irq.h>
> > +#include <linux/of_address.h>
> > +#include <linux/cpuidle.h>
> > +#include <linux/cpufreq.h>
> > +#include <linux/cpu.h>
> > +#include <linux/console.h>
> > +#include <linux/pvclock_gtod.h>
> > +#include <linux/reboot.h>
> > +#include <linux/time64.h>
> > +#include <linux/timekeeping.h>
> > +#include <linux/timekeeper_internal.h>
> > +#include <linux/acpi.h>
> > +#include <linux/virtio_anchor.h>
> > +
> > +#include <linux/mm.h>
> > +
> > +static struct start_info _xen_start_info;
> > +struct start_info *xen_start_info =3D &_xen_start_info;
> > +EXPORT_SYMBOL(xen_start_info);
> > +
> > +enum xen_domain_type xen_domain_type =3D XEN_NATIVE;
> > +EXPORT_SYMBOL(xen_domain_type);
> > +
> > +struct shared_info xen_dummy_shared_info;
> > +struct shared_info *HYPERVISOR_shared_info =3D (void *)&xen_dummy_shar=
ed_info;
> > +
> > +DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu);
> > +static struct vcpu_info __percpu *xen_vcpu_info;
> > +
> > +/* Linux <-> Xen vCPU id mapping */
> > +DEFINE_PER_CPU(uint32_t, xen_vcpu_id);
> > +EXPORT_PER_CPU_SYMBOL(xen_vcpu_id);
> > +
> > +/* These are unused until we support booting "pre-ballooned" */
> > +unsigned long xen_released_pages;
> > +struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __in=
itdata;
> > +
> > +static __read_mostly unsigned int xen_events_irq;
> > +static __read_mostly phys_addr_t xen_grant_frames;
> > +
> > +#define GRANT_TABLE_INDEX   0
> > +#define EXT_REGION_INDEX    1
> > +
> > +uint32_t xen_start_flags;
> > +EXPORT_SYMBOL(xen_start_flags);
> > +
> > +int xen_unmap_domain_gfn_range(struct vm_area_struct *vma,
> > +                                     int nr, struct page **pages)
> > +{
> > +     return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(xen_unmap_domain_gfn_range);
> > +
> > +static void xen_read_wallclock(struct timespec64 *ts)
> > +{
> > +}
> > +
> > +static int xen_pvclock_gtod_notify(struct notifier_block *nb,
> > +                                     unsigned long was_set, void *priv=
)
> > +{
> > +     return 0;
> > +}
> > +
> > +static struct notifier_block xen_pvclock_gtod_notifier =3D {
> > +     .notifier_call =3D xen_pvclock_gtod_notify,
> > +};
> > +
> > +static int xen_starting_cpu(unsigned int cpu)
> > +{
> > +     return 0;
> > +}
> > +
> > +static int xen_dying_cpu(unsigned int cpu)
> > +{
> > +     return 0;
> > +}
> > +
> > +void xen_reboot(int reason)
> > +{
> > +}
> > +
> > +static int xen_restart(struct notifier_block *nb, unsigned long action=
,
> > +                                     void *data)
> > +{
> > +     return 0;
> > +}
> > +
> > +static struct notifier_block xen_restart_nb =3D {
> > +     .notifier_call =3D xen_restart,
> > +     .priority =3D 192,
> > +};
> > +
> > +static void xen_power_off(void)
> > +{
> > +}
> > +
> > +static __initdata struct {
> > +     const char *compat;
> > +     const char *prefix;
> > +     const char *version;
> > +     bool found;
> > +} hyper_node =3D {"xen,xen", "xen,xen-", NULL, false};
> > +
> > +static int __init fdt_find_hyper_node(unsigned long node, const char *=
uname,
> > +                                     int depth, void *data)
> > +{
> > +     return 0;
> > +}
> > +
> > +void __init xen_early_init(void)
> > +{
> > +}
> > +
> > +static void __init xen_dt_guest_init(void)
> > +{
> > +}
> > +
> > +static int __init xen_guest_init(void)
> > +{
> > +     return 0;
> > +}
> > +early_initcall(xen_guest_init);
> > +
> > +static int xen_starting_runstate_cpu(unsigned int cpu)
> > +{
> > +     return 0;
> > +}
> > +
> > +static int __init xen_late_init(void)
> > +{
> > +     return 0;
> > +}
> > +late_initcall(xen_late_init);
> > +
> > +
> > +/* empty stubs */
> > +void xen_arch_pre_suspend(void) { }
> > +void xen_arch_post_suspend(int suspend_cancelled) { }
> > +void xen_timer_resume(void) { }
> > +void xen_arch_resume(void) { }
> > +void xen_arch_suspend(void) { }
>
> I don't see the point of creating arch/riscv/xen/enlighten.c by what look=
s
> like copying arm's version and then deleting all the function
> implementations. Much of arm's implementations look generic, so why not
> keep them?
>
We'll reduce this file to only necessary functions and try to reuse
them completely from arm implementation if possible.

> > diff --git a/arch/riscv/xen/grant-table.c b/arch/riscv/xen/grant-table.=
c
> > new file mode 100644
> > index 000000000000..9dd0cea74360
> > --- /dev/null
> > +++ b/arch/riscv/xen/grant-table.c
> > @@ -0,0 +1,57 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*********************************************************************=
*********
> > + * grant_table.c
> > + *
> > + * Granting foreign access to our memory reservation.
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License version=
 2
> > + * as published by the Free Software Foundation; or, when distributed
> > + * separately from the Linux kernel or incorporated into other
> > + * software packages, subject to the following license:
> > + *
> > + * Permission is hereby granted, free of charge, to any person obtaini=
ng a copy
> > + * of this source file (the "Software"), to deal in the Software witho=
ut
> > + * restriction, including without limitation the rights to use, copy, =
modify,
> > + * merge, publish, distribute, sublicense, and/or sell copies of the S=
oftware,
> > + * and to permit persons to whom the Software is furnished to do so, s=
ubject to
> > + * the following conditions:
> > + *
> > + * The above copyright notice and this permission notice shall be incl=
uded in
> > + * all copies or substantial portions of the Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXP=
RESS OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABI=
LITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT S=
HALL THE
> > + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OT=
HER
> > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARI=
SING
> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER=
 DEALINGS
> > + * IN THE SOFTWARE.
> > + */
> > +
> > +#include <xen/interface/xen.h>
> > +#include <xen/page.h>
> > +#include <xen/grant_table.h>
> > +
> > +int arch_gnttab_map_shared(xen_pfn_t *frames, unsigned long nr_gframes=
,
> > +                                     unsigned long max_nr_gframes,
> > +                                     void **__shared)
> > +{
> > +     return 0;
>
> should return -ENOSYS. arm returns that even now.
>
Will be fixed in the new patch version.

> > +}
> > +
> > +void arch_gnttab_unmap(void *shared, unsigned long nr_gframes)
> > +{
> > +}
> > +
> > +int arch_gnttab_map_status(uint64_t *frames, unsigned long nr_gframes,
> > +                                     unsigned long max_nr_gframes,
> > +                                     grant_status_t **__shared)
> > +{
> > +     return 0;
>
> should return -ENOSYS. arm returns that even now.
>
> > +}
> > +
> > +int arch_gnttab_init(unsigned long nr_shared, unsigned long nr_status)
> > +{
> > +     return 0;
> > +}
> > diff --git a/arch/riscv/xen/hypercall.S b/arch/riscv/xen/hypercall.S
> > new file mode 100644
> > index 000000000000..a81afd2a11c4
> > --- /dev/null
> > +++ b/arch/riscv/xen/hypercall.S
> > @@ -0,0 +1,71 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +#include <linux/linkage.h>
> > +#include <asm/assembler.h>
> > +#include <xen/interface/xen.h>
> > +EXPORT_SYMBOL_GPL(HYPERVISOR_event_channel_op);
> > +EXPORT_SYMBOL_GPL(HYPERVISOR_grant_table_op);
> > +EXPORT_SYMBOL_GPL(HYPERVISOR_xen_version);
> > +EXPORT_SYMBOL_GPL(HYPERVISOR_console_io);
> > +EXPORT_SYMBOL_GPL(HYPERVISOR_sched_op);
> > +EXPORT_SYMBOL_GPL(HYPERVISOR_hvm_op);
> > +EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
> > +EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
> > +EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
> > +EXPORT_SYMBOL_GPL(HYPERVISOR_platform_op_raw);
> > +EXPORT_SYMBOL_GPL(HYPERVISOR_multicall);
> > +EXPORT_SYMBOL_GPL(HYPERVISOR_vm_assist);
> > +EXPORT_SYMBOL_GPL(HYPERVISOR_dm_op);
> > +EXPORT_SYMBOL_GPL(privcmd_call);
> > +#define SBI_ECALL 0xE
>
> Shouldn't this be 0xA000007, i.e. the SBI firmware specific extension
> for Xen. Otherwise why refer to SBI? Note, '0xE' is an invalid, legacy
> extension ID in SBI.
>
Hypercall is triggered through SBI and we defined 0xE just as an
SBI_ECALL ID on Xen side for hypercall handling (among other operation
IDs), so we're not referring to some standard /legacy ID here, just
utilizing SBI for hypercall handling.
Is this specific ID (0xE) not allowed to be used on the kernel side
for some reason? If that is the case, we can use any other ID,
including the one which you suggested.

> > +
> > +    .data
> > +
> > +#define HYPERCALL_SIMPLE(hypercall) \
> > +SYM_FUNC_START(HYPERVISOR_##hypercall) \
> > +    li a6, __HYPERVISOR_##hypercall; \
> > +    li a7, SBI_ECALL; \
> > +    mv a5, a4; \
> > +    mv a4, a3; \
> > +    mv a3, a2; \
> > +    mv a2, a1; \
> > +    mv a1, a0; \
> > +    li a0, 0; \
>
> Assuming a0 has to be zero, then we should look for a solution to avoid
> all the register shifting. Either some wrapper functions for the
> hypercalls that convince the compiler to do the right thing or at
> least use the HYPERCALL{0,1,2,...} defines to reduce the amount of
> shifting to the minimum.
>
Fixed for the next patch version, it turned out that we do not need
all these register shifting in the end.

> > +    ecall; \
> > +    ret; \
> > +SYM_FUNC_END(HYPERVISOR_##hypercall)
> > +
> > +#define HYPERCALL0 HYPERCALL_SIMPLE
> > +#define HYPERCALL1 HYPERCALL_SIMPLE
> > +#define HYPERCALL2 HYPERCALL_SIMPLE
> > +#define HYPERCALL3 HYPERCALL_SIMPLE
> > +#define HYPERCALL4 HYPERCALL_SIMPLE
> > +#define HYPERCALL5 HYPERCALL_SIMPLE
> > +
> > +    .text
> > +
> > +HYPERCALL2(xen_version);
> > +HYPERCALL3(console_io);
> > +HYPERCALL3(grant_table_op);
> > +HYPERCALL2(sched_op);
> > +HYPERCALL2(event_channel_op);
> > +HYPERCALL2(hvm_op);
> > +HYPERCALL2(memory_op);
> > +HYPERCALL2(physdev_op);
> > +HYPERCALL3(vcpu_op);
> > +HYPERCALL1(platform_op_raw);
> > +HYPERCALL2(multicall);
> > +HYPERCALL2(vm_assist);
> > +HYPERCALL3(dm_op);
> > +
> > +SYM_FUNC_START(privcmd_call)
> > +    mv a6, a0
> > +    li a7, SBI_ECALL
> > +    mv a5, a4;
> > +    mv a4, a3;
> > +    mv a3, a2;
> > +    mv a2, a1;
> > +    mv a1, a0;
> > +    li a0, 0;
>
> same comments as above
>
Fixed

> > +    ecall
> > +    ret
> > +SYM_FUNC_END(privcmd_call);
> > diff --git a/arch/riscv/xen/p2m.c b/arch/riscv/xen/p2m.c
> > new file mode 100644
> > index 000000000000..7ce75e52d7c4
> > --- /dev/null
> > +++ b/arch/riscv/xen/p2m.c
> > @@ -0,0 +1,76 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +#include <linux/memblock.h>
> > +#include <linux/gfp.h>
> > +#include <linux/export.h>
> > +#include <linux/spinlock.h>
> > +#include <linux/slab.h>
> > +#include <linux/types.h>
> > +#include <linux/dma-mapping.h>
> > +#include <linux/vmalloc.h>
> > +#include <linux/swiotlb.h>
> > +
> > +#include <xen/xen.h>
> > +#include <xen/interface/memory.h>
> > +#include <xen/grant_table.h>
> > +#include <xen/page.h>
> > +#include <xen/swiotlb-xen.h>
> > +
> > +#include <asm/cacheflush.h>
> > +#include <asm/xen/hypercall.h>
> > +#include <asm/xen/interface.h>
> > +
> > +struct xen_p2m_entry {
> > +     unsigned long pfn;
> > +     unsigned long mfn;
> > +     unsigned long nr_pages;
> > +     struct rb_node rbnode_phys;
> > +};
> > +
> > +static rwlock_t p2m_lock;
> > +struct rb_root phys_to_mach =3D RB_ROOT;
> > +EXPORT_SYMBOL_GPL(phys_to_mach);
> > +
> > +static int xen_add_phys_to_mach_entry(struct xen_p2m_entry *new)
> > +{
> > +
> > +     return 0;
> > +}
> > +
> > +unsigned long __pfn_to_mfn(unsigned long pfn)
> > +{
> > +     return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(__pfn_to_mfn);
> > +
> > +int set_foreign_p2m_mapping(struct gnttab_map_grant_ref *map_ops,
> > +                                     struct gnttab_map_grant_ref *kmap=
_ops,
> > +                                     struct page **pages, unsigned int=
 count)
> > +{
> > +     return 0;
> > +}
> > +
> > +int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops=
,
> > +                                     struct gnttab_unmap_grant_ref *ku=
nmap_ops,
> > +                                     struct page **pages, unsigned int=
 count)
> > +{
> > +     return 0;
> > +}
> > +
> > +bool __set_phys_to_machine_multi(unsigned long pfn,
> > +                                     unsigned long mfn, unsigned long =
nr_pages)
> > +{
> > +     return true;
> > +}
> > +EXPORT_SYMBOL_GPL(__set_phys_to_machine_multi);
> > +
> > +bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
> > +{
> > +     return true;
> > +}
> > +EXPORT_SYMBOL_GPL(__set_phys_to_machine);
> > +
> > +static int p2m_init(void)
> > +{
> > +     return 0;
> > +}
> > +arch_initcall(p2m_init);
>
> Again, I'm not sure what the point of copying functions from arm without
> their (what appear to be generic) implementations is.
>
> > diff --git a/include/xen/interface/io/protocols.h b/include/xen/interfa=
ce/io/protocols.h
> > index 22099bb4079f..6c6317462be0 100644
> > --- a/include/xen/interface/io/protocols.h
> > +++ b/include/xen/interface/io/protocols.h
> > @@ -6,6 +6,7 @@
> >  #define XEN_IO_PROTO_ABI_X86_64     "x86_64-abi"
> >  #define XEN_IO_PROTO_ABI_POWERPC64  "powerpc64-abi"
> >  #define XEN_IO_PROTO_ABI_ARM        "arm-abi"
> > +#define XEN_IO_PROTO_ABI_RISCV      "riscv-abi"
> >
> >  #if defined(__i386__)
> >  # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_X86_32
> > @@ -15,6 +16,8 @@
> >  # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_POWERPC64
> >  #elif defined(__arm__) || defined(__aarch64__)
> >  # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_ARM
> > +#elif defined(__riscv)
> > +# define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_RISCV
> >  #else
> >  # error arch fixup needed here
> >  #endif
> > diff --git a/include/xen/riscv/hypercall.h b/include/xen/riscv/hypercal=
l.h
> > new file mode 100644
> > index 000000000000..f76d8a018f26
> > --- /dev/null
> > +++ b/include/xen/riscv/hypercall.h
> > @@ -0,0 +1,71 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*********************************************************************=
*********
> > + * hypercall.h
> > + *
> > + * Linux-specific hypervisor handling.
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License version=
 2
> > + * as published by the Free Software Foundation; or, when distributed
> > + * separately from the Linux kernel or incorporated into other
> > + * software packages, subject to the following license:
> > + *
> > + * Permission is hereby granted, free of charge, to any person obtaini=
ng a copy
> > + * of this source file (the "Software"), to deal in the Software witho=
ut
> > + * restriction, including without limitation the rights to use, copy, =
modify,
> > + * merge, publish, distribute, sublicense, and/or sell copies of the S=
oftware,
> > + * and to permit persons to whom the Software is furnished to do so, s=
ubject to
> > + * the following conditions:
> > + *
> > + * The above copyright notice and this permission notice shall be incl=
uded in
> > + * all copies or substantial portions of the Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXP=
RESS OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABI=
LITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT S=
HALL THE
> > + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OT=
HER
> > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARI=
SING
> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER=
 DEALINGS
> > + * IN THE SOFTWARE.
> > + */
>
> Just the SPDX should be sufficient.
>
> > +
> > +#ifndef _ASM_RISCV_XEN_HYPERCALL_H
> > +#define _ASM_RISCV_XEN_HYPERCALL_H
> > +
> > +#include <linux/bug.h>
> > +
> > +#include <xen/interface/xen.h>
> > +#include <xen/interface/sched.h>
> > +#include <xen/interface/platform.h>
> > +
> > +struct xen_dm_op_buf;
> > +
> > +long privcmd_call(unsigned int call, unsigned long a1,
> > +             unsigned long a2, unsigned long a3,
> > +             unsigned long a4, unsigned long a5);
> > +int HYPERVISOR_xen_version(int cmd, void *arg);
> > +int HYPERVISOR_console_io(int cmd, int count, char *str);
> > +int HYPERVISOR_grant_table_op(unsigned int cmd, void *uop, unsigned in=
t count);
> > +int HYPERVISOR_sched_op(int cmd, void *arg);
> > +int HYPERVISOR_event_channel_op(int cmd, void *arg);
> > +unsigned long HYPERVISOR_hvm_op(int op, void *arg);
> > +int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
> > +int HYPERVISOR_physdev_op(int cmd, void *arg);
> > +int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
> > +int HYPERVISOR_vm_assist(unsigned int cmd, unsigned int type);
> > +int HYPERVISOR_dm_op(domid_t domid, unsigned int nr_bufs,
> > +                      struct xen_dm_op_buf *bufs);
> > +int HYPERVISOR_platform_op_raw(void *arg);
> > +static inline int HYPERVISOR_platform_op(struct xen_platform_op *op)
> > +{
> > +     return 0;
> > +}
> > +int HYPERVISOR_multicall(struct multicall_entry *calls, uint32_t nr);
> > +
> > +static inline int
> > +HYPERVISOR_suspend(unsigned long start_info_mfn)
>
> Don't wrap this function definition
>
> > +{
> > +     return 0;
> > +}
> > +
> > +#endif /* _ASM_RISCV_XEN_HYPERCALL_H */
> > diff --git a/include/xen/riscv/hypervisor.h b/include/xen/riscv/hypervi=
sor.h
> > new file mode 100644
> > index 000000000000..2c1f9625be80
> > --- /dev/null
> > +++ b/include/xen/riscv/hypervisor.h
> > @@ -0,0 +1,26 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +#ifndef _ASM_RISCV_XEN_HYPERVISOR_H
> > +#define _ASM_RISCV_XEN_HYPERVISOR_H
> > +
> > +#include <linux/init.h>
> > +
> > +extern struct shared_info *HYPERVISOR_shared_info;
> > +extern struct start_info *xen_start_info;
> > +
> > +#ifdef CONFIG_XEN
> > +void __init xen_early_init(void);
> > +#else
> > +static inline void xen_early_init(void) { return; }
> > +#endif
> > +
> > +#ifdef CONFIG_HOTPLUG_CPU
> > +static inline void xen_arch_register_cpu(int num)
> > +{
> > +}
> > +
> > +static inline void xen_arch_unregister_cpu(int num)
> > +{
> > +}
> > +#endif
> > +
> > +#endif /* _ASM_RISCV_XEN_HYPERVISOR_H */
> > diff --git a/include/xen/riscv/interface.h b/include/xen/riscv/interfac=
e.h
> > new file mode 100644
> > index 000000000000..6769b5b39cba
> > --- /dev/null
> > +++ b/include/xen/riscv/interface.h
> > @@ -0,0 +1,85 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*********************************************************************=
*********
> > + * Guest OS interface to RISCV Xen.
> > + *
> > + */
> > +
> > +#ifndef _ASM_RISCV_XEN_INTERFACE_H
> > +#define _ASM_RISCV_XEN_INTERFACE_H
> > +
> > +#include <linux/types.h>
> > +
> > +#define uint64_aligned_t uint64_t __aligned(8)
> > +
> > +#define __DEFINE_GUEST_HANDLE(name, type) \
> > +     typedef struct { union { type * p; uint64_aligned_t q; }; }  \
> > +             __guest_handle_ ## name
> > +
> > +#define DEFINE_GUEST_HANDLE_STRUCT(name) \
> > +     __DEFINE_GUEST_HANDLE(name, struct name)
> > +#define DEFINE_GUEST_HANDLE(name) __DEFINE_GUEST_HANDLE(name, name)
> > +#define GUEST_HANDLE(name)        __guest_handle_ ## name
> > +
> > +#define set_xen_guest_handle(hnd, val)                       \
> > +     do {                                            \
> > +             if (sizeof(hnd) =3D=3D 8)                   \
> > +                     *(uint64_t *)&(hnd) =3D 0;        \
> > +             (hnd).p =3D val;                          \
> > +     } while (0)
> > +
> > +#define __HYPERVISOR_platform_op_raw __HYPERVISOR_platform_op
> > +
> > +#ifndef __ASSEMBLY__
> > +/* Explicitly size integers that represent pfns in the interface with
> > + * Xen so that we can have one ABI that works for 32 and 64 bit guests=
.
> > + * Note that this means that the xen_pfn_t type may be capable of
> > + * representing pfn's which the guest cannot represent in its own pfn
> > + * type. However since pfn space is controlled by the guest this is
> > + * fine since it simply wouldn't be able to create any sure pfns in
> > + * the first place.
> > + */
> > +typedef uint64_t xen_pfn_t;
> > +#define PRI_xen_pfn "llx"
> > +typedef uint64_t xen_ulong_t;
> > +#define PRI_xen_ulong "llx"
> > +typedef int64_t xen_long_t;
> > +#define PRI_xen_long "llx"
> > +/* Guest handles for primitive C types. */
> > +__DEFINE_GUEST_HANDLE(uchar, unsigned char);
> > +__DEFINE_GUEST_HANDLE(uint,  unsigned int);
> > +DEFINE_GUEST_HANDLE(char);
> > +DEFINE_GUEST_HANDLE(int);
> > +DEFINE_GUEST_HANDLE(void);
> > +DEFINE_GUEST_HANDLE(uint64_t);
> > +DEFINE_GUEST_HANDLE(uint32_t);
> > +DEFINE_GUEST_HANDLE(xen_pfn_t);
> > +DEFINE_GUEST_HANDLE(xen_ulong_t);
> > +
> > +/* Maximum number of virtual CPUs in multi-processor guests. */
> > +#define MAX_VIRT_CPUS 1
> > +
> > +struct arch_vcpu_info { };
> > +struct arch_shared_info { };
> > +
> > +/* TODO: Move pvclock definitions some place arch independent */
> > +struct pvclock_vcpu_time_info {
> > +     u32   version;
> > +     u32   pad0;
> > +     u64   tsc_timestamp;
> > +     u64   system_time;
> > +     u32   tsc_to_system_mul;
> > +     s8    tsc_shift;
> > +     u8    flags;
> > +     u8    pad[2];
> > +} __packed; /* 32 bytes */
> > +
> > +/* It is OK to have a 12 bytes struct with no padding because it is pa=
cked */
> > +struct pvclock_wall_clock {
> > +     u32   version;
> > +     u32   sec;
> > +     u32   nsec;
> > +     u32   sec_hi;
> > +} __packed;
> > +#endif
> > +
> > +#endif /* _ASM_RISCV_XEN_INTERFACE_H */
> > diff --git a/include/xen/riscv/page.h b/include/xen/riscv/page.h
> > new file mode 100644
> > index 000000000000..fe07a9bffa7e
> > --- /dev/null
> > +++ b/include/xen/riscv/page.h
> > @@ -0,0 +1,106 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +#ifndef _ASM_RISCV_XEN_PAGE_H
> > +#define _ASM_RISCV_XEN_PAGE_H
> > +
> > +#include <asm/page.h>
> > +
> > +#include <linux/pfn.h>
> > +#include <linux/types.h>
> > +#include <linux/dma-mapping.h>
> > +#include <linux/pgtable.h>
> > +
> > +#include <xen/xen.h>
> > +#include <xen/interface/grant_table.h>
> > +
> > +/* Xen machine address */
> > +struct xmaddr {
> > +     phys_addr_t maddr;
> > +};
> > +
> > +/* Xen pseudo-physical address */
> > +struct xpaddr {
> > +     phys_addr_t paddr;
> > +};
> > +
> > +#define XMADDR(x)    ((struct xmaddr) { .maddr =3D (x) })
> > +#define XPADDR(x)    ((struct xpaddr) { .paddr =3D (x) })
> > +
> > +#define INVALID_P2M_ENTRY      (~0UL)
> > +
> > +/*
> > + * The pseudo-physical frame (pfn) used in all the helpers is always b=
ased
> > + * on Xen page granularity (i.e 4KB).
> > + *
> > + * A Linux page may be split across multiple non-contiguous Xen page s=
o we
> > + * have to keep track with frame based on 4KB page granularity.
> > + *
> > + * PV drivers should never make a direct usage of those helpers (parti=
cularly
> > + * pfn_to_gfn and gfn_to_pfn).
> > + */
> > +
> > +unsigned long __pfn_to_mfn(unsigned long pfn);
> > +extern struct rb_root phys_to_mach;
> > +
> > +/* Pseudo-physical <-> Guest conversion */
> > +static inline unsigned long pfn_to_gfn(unsigned long pfn)
> > +{
> > +     return 0;
> > +}
> > +
> > +static inline unsigned long gfn_to_pfn(unsigned long gfn)
> > +{
> > +     return 0;
> > +}
> > +
> > +/* Pseudo-physical <-> BUS conversion */
> > +static inline unsigned long pfn_to_bfn(unsigned long pfn)
> > +{
> > +     return 0;
> > +}
> > +
> > +static inline unsigned long bfn_to_pfn(unsigned long bfn)
> > +{
> > +     return 0;
> > +}
> > +
> > +#define bfn_to_local_pfn(bfn)        bfn_to_pfn(bfn)
> > +
> > +/* VIRT <-> GUEST conversion */
> > +#define virt_to_gfn(v)                                                =
         \
> > +     ({                                                               =
      \
> > +             WARN_ON_ONCE(!virt_addr_valid(v));                       =
       \
> > +             pfn_to_gfn(virt_to_phys(v) >> XEN_PAGE_SHIFT);           =
      \
> > +     })
> > +#define gfn_to_virt(m)               (__va(gfn_to_pfn(m) << XEN_PAGE_S=
HIFT))
> > +
> > +#define percpu_to_gfn(v)     \
> > +     (pfn_to_gfn(per_cpu_ptr_to_phys(v) >> XEN_PAGE_SHIFT))
> > +
> > +static inline struct xmaddr arbitrary_virt_to_machine(void *vaddr)
> > +{
> > +     WARN_ON_ONCE(1);
> > +     return (struct xmaddr){0};
> > +}
> > +
> > +extern int set_foreign_p2m_mapping(struct gnttab_map_grant_ref *map_op=
s,
> > +                                struct gnttab_map_grant_ref *kmap_ops,
> > +                                struct page **pages, unsigned int coun=
t);
> > +
> > +extern int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *un=
map_ops,
> > +                                      struct gnttab_unmap_grant_ref *k=
unmap_ops,
> > +                                      struct page **pages, unsigned in=
t count);
> > +
> > +bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn);
> > +bool __set_phys_to_machine_multi(unsigned long pfn, unsigned long mfn,
> > +             unsigned long nr_pages);
> > +
> > +static inline bool set_phys_to_machine(unsigned long pfn, unsigned lon=
g mfn)
> > +{
> > +     return 0;
> > +}
> > +
> > +bool xen_arch_need_swiotlb(struct device *dev,
> > +                        phys_addr_t phys,
> > +                        dma_addr_t dev_addr);
> > +
> > +#endif /* _ASM_RISCV_XEN_PAGE_H */
> > diff --git a/include/xen/riscv/swiotlb-xen.h b/include/xen/riscv/swiotl=
b-xen.h
> > new file mode 100644
> > index 000000000000..97ecd8cbbc2d
> > --- /dev/null
> > +++ b/include/xen/riscv/swiotlb-xen.h
> > @@ -0,0 +1,13 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +#ifndef _ASM_RISCV_SWIOTLB_XEN_H
> > +#define _ASM_RISCV_SWIOTLB_XEN_H
> > +
> > +#include <xen/features.h>
> > +#include <xen/xen.h>
> > +
> > +static inline int xen_swiotlb_detect(void)
> > +{
> > +     return 0;
> > +}
> > +
> > +#endif /* _ASM_RISCV_SWIOTLB_XEN_H */
> > diff --git a/test.txt b/test.txt
> > new file mode 100644
> > index 000000000000..e54267998982
> > --- /dev/null
> > +++ b/test.txt
> > @@ -0,0 +1,21 @@
> > +WARNING: added, moved or deleted file(s), does MAINTAINERS need updati=
ng?
> > +#120:
> > +new file mode 100644
> > +
> > +WARNING: do not add new typedefs
> > +#808: FILE: include/xen/riscv/interface.h:15:
> > ++    typedef struct { union { type * p; uint64_aligned_t q; }; }  \
> > +
> > +WARNING: please, no spaces at the start of a line
> > +#1006: FILE: include/xen/riscv/swiotlb-xen.h:10:
> > ++    return 0;$
> > +
> > +total: 0 errors, 3 warnings, 810 lines checked
> > +
> > +NOTE: For some of the reported defects, checkpatch may be able to
> > +      mechanically convert to the typical style using --fix or --fix-i=
nplace.
> > +
> > +0001-riscv-Add-initial-Xen-guest-support-for-RISC-V.patch has style pr=
oblems, please review.
> > +
> > +NOTE: If any of the errors are false positives, please report
> > +      them to the maintainer, see CHECKPATCH in MAINTAINERS.
>
> You obviously added this file by accident. Please proof read patches
> before sending them.
>
> I'm glad to see interest in getting Xen support upstream, but this isn't
> the right approach. For starters, the patch is clearly missing the 'RFC'
> it should have in its prefix, but it also doesn't make sense to post
> (much less merge) a bunch of stubs, at least not without another patch
> in the same series filling most or all those stubs in with tested code.
> Also, anything that is generic should either be copied in the first go
> (rather than deleting it just to add it back later) or, even better, it
> should be factored out of the other architecture specific code into a
> common place where it can be shared.
>
We'll restructure the patch into smaller parts and keep only necessary
functions for hypercall proper functionality. Thanks.

BR,
Milan


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 19:20:18 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 19:20:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873045.1284026 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY8w1-0005J2-CZ; Wed, 15 Jan 2025 19:20:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873045.1284026; Wed, 15 Jan 2025 19:20:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY8w1-0005Iv-A1; Wed, 15 Jan 2025 19:20:13 +0000
Received: by outflank-mailman (input) for mailman id 873045;
 Wed, 15 Jan 2025 19:20:12 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=guqY=UH=gmail.com=milandjokic1995@srs-se1.protection.inumbo.net>)
 id 1tY8w0-0005Ip-Ep
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 19:20:12 +0000
Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com
 [2607:f8b0:4864:20::f31])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bd00a0df-d375-11ef-a0e1-8be0dac302b0;
 Wed, 15 Jan 2025 20:20:11 +0100 (CET)
Received: by mail-qv1-xf31.google.com with SMTP id
 6a1803df08f44-6dcf63155b0so1281306d6.1
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 11:20:11 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: bd00a0df-d375-11ef-a0e1-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736968810; x=1737573610; 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=yxOLisM/r2vqci17iimcnJ3+oT6PlH7eXAcAxS9wH8I=;
        b=KEPBTSGlJC6LEauC2mrchv/U+wDt8X7qpTAxpGvkdkb93Fvh2wetPxrbkcE8YYU6w9
         rRrKNTQKLf1VUody96LFSLG5cbsPfKXlqefpJapFz888QzW6M2rdbLz4A27zqkK4qRrA
         VJxl9F7Cb8aqe8waqPtaxtGpqMDiWh0cDvk043QtVlpR7326tJDgpGMNa2621022leZa
         QnDBTYo3AD8A/Csg4wA80MUACfwXQu++p8qURBWXhiQ0hH8txUTBAVP9udrNu5j7TWHw
         t+eJc0YCyWCcRQJDaaNUfv/qamVpJq2FfyVsBypnuoaYfI9n9U5DDPPOUnLBFhGpl87W
         gzEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736968810; x=1737573610;
        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=yxOLisM/r2vqci17iimcnJ3+oT6PlH7eXAcAxS9wH8I=;
        b=v+uVxBRh6mNpSkEYmBMfGXVvInNO+Kif2Oy7hsPVrj9raUYZcp8/Lav0aaG2UKDeZq
         THzZNOwbo4U364n8k4Ka8b1ySc+rE6p/1CJ9e2d0otlHh+753mFMkx31W36sXgvfWfnr
         z0y+nwlIpWEebA1rrVyhlum6chvyVqeoltEtF71CXZ01DzEXAfH9MCA3VtdBl1ovFryS
         60y7378ItTICbUMXLOUG3xZO1aoqtF58g2pKHaCbtg5OngZvbwtOG7MC4apZqeRPdSdN
         Qah3bGzySLyMnGQSOmeoKEBZQH4QSy0eAZiD8GIj4Nyzw7daLQLj310wiEE8eEWms1V/
         Ad4w==
X-Forwarded-Encrypted: i=1; AJvYcCUEvQ5RdqCBDELrJ/xr+L6lRcCfExKfiqIyyR65pMp/UJOQTIj6JpUtOPtcWVcJTnarANHhwh49KyM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxAKfyIneWN9YXFkCH2LK9HYIvIlsh9eQppA26vdQOz/1EfYG+p
	cc7aKJ4VkuPYdEpDkvVL2IA70nsPCZmwIyN9xjV4m2T59xFi7jN/M4NcArcm346Y83D9cbBZqoK
	2FqwyTGpt48d7uRhh6CDHPGyiTqE=
X-Gm-Gg: ASbGnctHaliuHQxJm/28qs08pAp+aKNOekbg5oCU1BwWnnQBiLzEH1nXV1H71y/aq3D
	WM5C1ikbw3iF1N7bAAZkhGmddogBI9gNpAUzXSQ==
X-Google-Smtp-Source: AGHT+IGcOD+cwuWLZQkHOERr/i/5IgCk1JWHnGSSNWX5DKVOVQdU9aSL/egf0MIChEkPIlmVmG4Q/k0vSx6KgLYio+A=
X-Received: by 2002:a05:6214:3c8c:b0:6df:8c25:2c81 with SMTP id
 6a1803df08f44-6df9b1d0b5emr530159576d6.5.1736968810243; Wed, 15 Jan 2025
 11:20:10 -0800 (PST)
MIME-Version: 1.0
References: <e4a649a7fdfc8fcf5f48a0bc4e76e5d546078083.1736868605.git.Slavisa.Petrovic@rt-rk.com>
 <alpine.DEB.2.22.394.2501141554170.2684657@ubuntu-linux-20-04-desktop> <2f1432e6-0d27-48fd-b034-475284f14233@gmail.com>
In-Reply-To: <2f1432e6-0d27-48fd-b034-475284f14233@gmail.com>
From: =?UTF-8?B?TWlsYW4gxJBva2nEhw==?= <milandjokic1995@gmail.com>
Date: Wed, 15 Jan 2025 20:20:00 +0100
X-Gm-Features: AbW1kvYPm3yU6yFTdo5RO9-y77hSL0M_d4qB1E2QaVvMAqTHQihGuVHlucVKfps
Message-ID: <CAKp59VEOiXo+OKwPNiomtXNCsfDURCXaDktooi5JSoTSdhc90w@mail.gmail.com>
Subject: Re: [PATCH] riscv: Add initial Xen guest support for RISC-V
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>, Stefano Stabellini <sstabellini@kernel.org>
Cc: linux-riscv@lists.infradead.org, paul.walmsley@sifive.com, 
	palmer@dabbelt.com, aou@eecs.berkeley.edu, jgross@suse.com, 
	oleksandr_tyshchenko@epam.com, Slavisa.Petrovic@rt-rk.com, 
	Milan.Djokic@rt-rk.com, rafael.j.wysocki@intel.com, sunilvl@ventanamicro.com, 
	takakura@valinux.co.jp, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, iommu@lists.linux.dev
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Stefano, Oleksii

On Wed, Jan 15, 2025 at 5:30=E2=80=AFPM Oleksii Kurochko
<oleksii.kurochko@gmail.com> wrote:
>
> Hi Stefano,
>
> On 1/15/25 1:01 AM, Stefano Stabellini wrote:
>
> +Oleksii
>
> On Tue, 14 Jan 2025, Milan Djokic wrote:
>
> From: Slavisa Petrovic <Slavisa.Petrovic@rt-rk.com>
>
> This patch introduces initial support for running RISC-V as a Xen guest.
> It provides the necessary infrastructure and stubs for Xen-specific
> operations. Key changes include:
>
> - Modifications to the RISC-V kernel to integrate Xen-specific hypercalls
>   and interfaces, with function implementations stubbed for future work.
> - Introduction of Xen-specific headers for RISC-V, including event
>   handling, hypervisor interaction, and page management. Functions are
>   defined but not yet implemented.
> - Stub implementations for memory management, grant tables, and context
>   switching in the Xen environment, allowing further development and
>   integration.
>
> Signed-off-by: Milan Djokic <Milan.Djokic@rt-rk.com>
> Signed-off-by: Slavisa Petrovic <Slavisa.Petrovic@rt-rk.com>
>
> Hi Milan, Slavisa,
>
> Thank you very much for your contribution! Which Xen tree are you using
> for development?
>
> They are using [1] and have separate branches on top of latest. So we are=
 in
> sync. Also, if you are interested we have created a task/epics for this f=
eature in
> [1] so you could also check there some details:
> 1. https://gitlab.com/groups/xen-project/people/olkur/-/epics/5
> 2. https://gitlab.com/xen-project/people/olkur/xen/-/issues/12
>
>  I am asking because RISC-V support in Xen is still in
> the process of being upstreamed, and [1] is the tree that consolidates
> all patches currently on the to-be-upstreamed list.
>
> While the specific Xen tree you are using is not particularly important
> at this stage, and using [1] is not a requirement, I am asking because
> it is essential to align on the hypervisor ABI, especially regarding any
> details that have not yet been upstreamed. Specifically, is there
> anything in this patch series that relies on features not yet upstream
> in Xen?
>
> There are few features but some things which are Rt-Tk's branch in [1] co=
uld go
> without waiting for these features to be upstreamed.
>
> Thanks.
>
> ~ Oleksii
>
> [1] https://gitlab.com/xen-project/people/olkur/xen/-/tree/latest?ref_typ=
e=3Dheads

As Oleksii already explained, we are working in sync with his latest
branch where most of the risc port is done.
I would just add that this patch introduces kernel risc-v hypercall
support on which only our branch on xen tree depends on. Therefore, it
won't disrupt any functionality with current upstream Xen, it will
just introduce kernel functionality which is not used from Xen side
until our branch is merged upstream.

Best regards,
Milan


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 19:40:41 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 19:40:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873056.1284036 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY9Fc-0000Bp-UN; Wed, 15 Jan 2025 19:40:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873056.1284036; Wed, 15 Jan 2025 19:40:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY9Fc-0000Bi-Rn; Wed, 15 Jan 2025 19:40:28 +0000
Received: by outflank-mailman (input) for mailman id 873056;
 Wed, 15 Jan 2025 19:40:27 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=ppZO=UH=amd.com=Jason.Andryuk@srs-se1.protection.inumbo.net>)
 id 1tY9Fb-0000Bc-HD
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 19:40:27 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on2060f.outbound.protection.outlook.com
 [2a01:111:f403:2416::60f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8ff76f51-d378-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 20:40:25 +0100 (CET)
Received: from DS7PR03CA0181.namprd03.prod.outlook.com (2603:10b6:5:3b6::6) by
 DS7PR12MB6141.namprd12.prod.outlook.com (2603:10b6:8:9b::15) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8356.13; Wed, 15 Jan 2025 19:40:19 +0000
Received: from CY4PEPF0000E9D2.namprd03.prod.outlook.com
 (2603:10b6:5:3b6:cafe::50) by DS7PR03CA0181.outlook.office365.com
 (2603:10b6:5:3b6::6) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8356.13 via Frontend Transport; Wed,
 15 Jan 2025 19:40:19 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CY4PEPF0000E9D2.mail.protection.outlook.com (10.167.241.137) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8356.11 via Frontend Transport; Wed, 15 Jan 2025 19:40:19 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 15 Jan
 2025 13:40:18 -0600
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 15 Jan
 2025 13:40:18 -0600
Received: from [172.27.3.102] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Wed, 15 Jan 2025 13:40:18 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8ff76f51-d378-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=kghExDesPkVx+i/z4CqhbWzKEk0uDhzmc+qtnfNbVMX9cgWPfw2E7JbEoO4NLyJPqNmslSSZ+CQSvPvNUERV6tmBiAaLdcGLnawBTXWnOIG14Vd/qxxCmI87sozKsj/WeqZe+psouLktM+5Nnu0FSzT0sWEjM/tsPDPHgsR7i6lV5+MyH+mpuuVD92+Jx7kbO74Vz2+uqA8GnDFKu+/ZslwEClAX4WGV9W5tGgudgeIOsRLoZuM9SkjXsHMK9n/vnPr7amoA1VTFV/WgwdG+8cGRdI+/EN0bNhS+ljj8Z9FW2S4ZrYWrpKR6xWuDH8TlBoYsYd8BE6f5h/z/ByXmIg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=udt1fbaIw7+u/kBiW+PlOwvsGK27pKZIQeuT72Zs2hg=;
 b=PGqnS2Od4j+3SkJmgW3p0sAx0X7ii4QIV0xl2fRnUoeL2z2aVCro1qaZpktgUJOym1mVFhoP4yitcf7kLmBgpvDUBEhriGxWvLgQJFZWt39bwTNJQgaRo7h1z+m3JmuSAI0rSFLoWMsrH6HWBPz8FJt3mSde/mvyLY24b6dOLsx4hTWc2ZgNAsD/27dxCoRAp4N04YrOeIU4HlyZLEZH0JpjlbpMrh1+i+DXduoxqj2Tuz4CpJxUwlvSmrxL8Y7K5U30OuwZ+JuSbTMVswqJ4b2yFiKsxEizR3lJ1s+Hx/A81LEA0+1X29KnHbt5dFiwCDIQA6w/v5k2c6uIbMSxdQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=apertussolutions.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=udt1fbaIw7+u/kBiW+PlOwvsGK27pKZIQeuT72Zs2hg=;
 b=1ybeAh5SRvca/9EykacDDBzD4t92ADx2JvmG9O67lfvMmkGKrP+1hmVjwkNUHMMkbUrP6z7p+v7dUgxIzh2voZ8VnKmN/wpTPg6QOWzVu9Rri6bp1+1zJDnOHwrdbE2nfopwr0MYlZ+D+4tlkwrbpuKqHbRXTq/dk7BXrVhGUng=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <f9fc3f4a-f5ff-4974-aafc-8229ed46b7d2@amd.com>
Date: Wed, 15 Jan 2025 14:40:17 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 14/15] x86/hyperlaunch: add max vcpu parsing of
 hyperlaunch device tree
To: "Daniel P. Smith" <dpsmith@apertussolutions.com>,
	<xen-devel@lists.xenproject.org>
CC: <christopher.w.clark@gmail.com>, <stefano.stabellini@amd.com>, Jan Beulich
	<jbeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
 <20241226165740.29812-15-dpsmith@apertussolutions.com>
Content-Language: en-US
From: Jason Andryuk <jason.andryuk@amd.com>
In-Reply-To: <20241226165740.29812-15-dpsmith@apertussolutions.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB05.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000E9D2:EE_|DS7PR12MB6141:EE_
X-MS-Office365-Filtering-Correlation-Id: d576f32c-7c9e-4c31-b94b-08dd359c71ce
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|82310400026|1800799024|36860700013|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?MTlpRDFQMVNRZnpqbk1WYUs5TXViMnRwTG9SUi9Gb3BLbDVva05SQldOOERn?=
 =?utf-8?B?dEZZWHZ4d3J2YWtWbHR1U3ZyQysvODVhZzRROEdmN1ZKcnZ1dlJnb0RFTEVU?=
 =?utf-8?B?WkMreDRwT29qSzFOaFM2WUJVQkE5VVBjeTcvVjlYSVpCMGVJRHBRdGtZekdR?=
 =?utf-8?B?eWlhQ01pZFEwOExEMDZEdmQ3bkFtcndXM3Jtc1Vvb2hHejVZblRmYTUrWndw?=
 =?utf-8?B?SzYvM3d3MFNlL2ozUFdxMktaR2dJRUZPOCtqMnFQNmNHR2o4azV5aUhPR2w4?=
 =?utf-8?B?SjM0aGJPUlJoZHczTDRyVGxVamZYUTNaNS9Gdi9iMW1MeFVSVXJ2TWRwTlJq?=
 =?utf-8?B?RCthTFJRQzhhQzF6cnRaZTRWT3dGcUFjOFNhQ1BhMkNlaUFYWkw4a1pBNDY3?=
 =?utf-8?B?c2twR3V5YnhvcnBqemtxZTBqUzRraHgrUnNRQlZFeThXejhJR2UvYU5BY2p1?=
 =?utf-8?B?c1BWY1hMTUs1S2dFTDg3bnUrbXZSWXdPT3pGMzNydTZlRDhZa2JGUVFnMmFH?=
 =?utf-8?B?d1FCYmJsTnVzei9ZeDNNOFVidE5TQ3V4S0F6eFo1K1F3bUgwZ3Q0eHlHZUx1?=
 =?utf-8?B?dTdSQ3hITkoxUlRsN1FRb2VObSs3MGhrUE1tRjU5eUJaYmRBQWlCWGZsaHVj?=
 =?utf-8?B?bVJ5REpTbWpPSEViTEo1NWJET255alVRRmdwdTVpZnUwcTN1aHhkM3NRaGdN?=
 =?utf-8?B?eXcvd1ZyeWNNZkRDRXVHa3RTRzJkSWRHRkQ4WmsvbUJvdGJtajk3MjFXRGtK?=
 =?utf-8?B?SFRGMk81cy96QVpxcWVLR1BNaGhtMFVVZm4zNGF6VHk3SzdXWkYwaHVZdytp?=
 =?utf-8?B?N0J4RTRjSElVbmhlNU9FbW1OQUw0VjBnVWdkdUZpRFR3QW1zTkdseE1zQjVR?=
 =?utf-8?B?VTY3SDd5eTlsWDYreXhYRHkrcjQrdWt6Kzg2aGVrSWZsQlhLT0NFS1dXbmtB?=
 =?utf-8?B?dlJLMzM4RitBVStuOTFjY3hNbjVBMVUrQjRnK0RMenI2cjBLTENkUjhZQlhT?=
 =?utf-8?B?WlFvc0laZ1Vra2tIaEowQUR1WHVNeTFSUyswWjFlZ2dtTmJNVXNzcEZhcmdx?=
 =?utf-8?B?bUpZUGh5NGt6d2VLeTNNUGdlRHpjQUk2RkhGSHNMd3d2QjdxT2hFZzV3YmpD?=
 =?utf-8?B?ZXFLcXltaC92NVUvdktKMm5OZFEwMlEzMUFnUkJnOTNCVlBSeTZ5Tlk5UnNT?=
 =?utf-8?B?THdTUzJoLzBTNk0zS2JWc2tuSjk1Y2dWem5iejZmbWV6aS9lUkt1K1VqVTRm?=
 =?utf-8?B?R1h0Ukgrb09jL2swMzExdGY5UFZJUHJlSm1QR1VUSjJiN1pIK21XQ1ZPa09x?=
 =?utf-8?B?WFg4ME93QllTM0wvVkM1QUQyY2FoQXdobHU3aG9VcDgyOWlZcnB3bHRnZy9D?=
 =?utf-8?B?SzIwaGRnbFJSb3VSWVhrYUs5eXRLSEpoRnRPMmdwNndrVWxwZ1FLM1M5dkNr?=
 =?utf-8?B?YUNRT2psK2EzNEFOTk9PYnFCbU1IeS9kNStyekpZNHhHUS9ZSkFneHc0a0xO?=
 =?utf-8?B?UFR1blRNVFhwakNMMW9wQWNXTEpQYjJZL3dZSU12MGMxTnltRWhJNmtFSDA4?=
 =?utf-8?B?dE9HMUhIYTYwOStQYXdOUDlKS3QrZ0FnaStXbXhHUUZXdlRzd3p0aElZV1JT?=
 =?utf-8?B?aWt2ak92WFVCZDhoWGN1QlVOY1lwam5ObjJLcTBJTWdoMTFUcUtwZGRwTm5N?=
 =?utf-8?B?QldZNXZCVi9WREZVdHVFRHp1WU02cW1FcjFEbzJoekhtb2dVOEwvTWtaWU1M?=
 =?utf-8?B?cU9UeGw2RzdQcjdZOExPU05hVXhNbU85VlZmaWlieDFNYVpWdnNZbExjVHN1?=
 =?utf-8?B?R2h0N3NDVFlqbTdxUFhLTnRrTWtVTWRlUlBKVEN6cHRnenhoQXh0Um1rMEtQ?=
 =?utf-8?B?WWRWeTloK2I2UElXNlQ2dGVEdTJXSGVJazZCT3ZEdm9rU2FVS2VIek05aWlj?=
 =?utf-8?B?cWtuTnZUb0t5UzJrS3N0NkZyb2o0RHR5Mm9tK0c2azRKKzBMMXV0S0Z3YUZU?=
 =?utf-8?Q?xUJNxJDNMUPDWQGjafxlFWjqlSMsm0=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(1800799024)(36860700013)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2025 19:40:19.5303
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d576f32c-7c9e-4c31-b94b-08dd359c71ce
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CY4PEPF0000E9D2.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB6141

On 2024-12-26 11:57, Daniel P. Smith wrote:
> Introduce the `cpus` property, named as such for dom0less compatibility, that
> represents the maximum number of vpcus to allocate for a domain. In the device
> tree, it will be encoded as a u32 value.

s/vpcus/vcpus/

I would remove "maximum".  Today, the DT only has `cpus`, and you get 
all of them.  So implicitly cpus=max_vcpus.

I could see a future max_vcpus property.  In that case, you would get 
`cpus` online and the rest offline.

> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
> Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>

> diff --git a/xen/arch/x86/domain-builder/fdt.c b/xen/arch/x86/domain-builder/fdt.c
> index aff1b8c3235d..70a793db199b 100644
> --- a/xen/arch/x86/domain-builder/fdt.c
> +++ b/xen/arch/x86/domain-builder/fdt.c
> @@ -147,6 +147,17 @@ static int __init process_domain_node(
>               bd->max_pages = PFN_DOWN(kb * SZ_1K);
>               printk("  max memory: %ld kb\n", kb);
>           }
> +        else if ( strncmp(prop_name, "cpus", name_len) == 0 )
> +        {
> +            uint32_t val = UINT_MAX;
> +            if ( fdt_prop_as_u32(prop, &val) != 0 )
> +            {
> +                printk("  failed processing max_vcpus for domain %s\n", name);

s/max_vcpus/cpus/

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 19:43:10 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 19:43:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873064.1284047 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY9ID-00012s-AL; Wed, 15 Jan 2025 19:43:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873064.1284047; Wed, 15 Jan 2025 19:43:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY9ID-00012l-7K; Wed, 15 Jan 2025 19:43:09 +0000
Received: by outflank-mailman (input) for mailman id 873064;
 Wed, 15 Jan 2025 19:43:08 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=ppZO=UH=amd.com=Jason.Andryuk@srs-se1.protection.inumbo.net>)
 id 1tY9IC-00012d-3A
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 19:43:08 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20610.outbound.protection.outlook.com
 [2a01:111:f403:2417::610])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f0724c83-d378-11ef-a0e1-8be0dac302b0;
 Wed, 15 Jan 2025 20:43:06 +0100 (CET)
Received: from DS7PR03CA0186.namprd03.prod.outlook.com (2603:10b6:5:3b6::11)
 by IA1PR12MB8334.namprd12.prod.outlook.com (2603:10b6:208:3ff::11) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8335.18; Wed, 15 Jan
 2025 19:43:03 +0000
Received: from CY4PEPF0000E9D2.namprd03.prod.outlook.com
 (2603:10b6:5:3b6:cafe::e0) by DS7PR03CA0186.outlook.office365.com
 (2603:10b6:5:3b6::11) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8356.14 via Frontend Transport; Wed,
 15 Jan 2025 19:43:02 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CY4PEPF0000E9D2.mail.protection.outlook.com (10.167.241.137) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8356.11 via Frontend Transport; Wed, 15 Jan 2025 19:43:02 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 15 Jan
 2025 13:43:01 -0600
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 15 Jan
 2025 13:43:01 -0600
Received: from [172.27.3.102] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Wed, 15 Jan 2025 13:43:01 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f0724c83-d378-11ef-a0e1-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=JAV3akHcAslZ6+jagTdzvQjH/FHHqIxj4UxlxddywRimrvsmCQEU3jMbosqoQBZzxrftEjusVNG/35M+savWJZFzk1UfN3Qsut4c8MGQlsfJzb65jU/OXXFv8oWoWIkoG2SDBxUNWzrr8bvSMDeFUqsYRYlXH7BEkM2504cmWWdKrdozgGxq6aaJbWOqpZXpq2wQjOgTKXyNgBlc9f6rjI2GKCh8PkxzlUhm0bX0nrM9ekpzEnXNhAl1qhhzbyQor7XIdXa/+JaE7pf6vm4MQqFqaGSxCFTkGFQaMDe2n3sMkvrImsJ6EmOakI4SEzwlycyF4FWsBcf8IHJWZ2VAqg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=C4smHa1qGEBB9avk0ZbJBURnL+T92NB2xIiCHq9iiOQ=;
 b=qPXNddzg/whl1OLP94sP7Q46m2V+SIdBYS3Ps6ZPctjc/efEBufewu9ajsOq2CqppArEYzlW2hsR/uDsoBpIIibij/hjOVxZn9LZA7slsy+lQAQJRzrUNzcXWiZiGoGw4veKL+dPO9tKCSqbMtjII4fHMUYVcU2dW/aV1MZtAORRuHjb8dSr3fZIfVbIuFv8GBgzoWvwXb4N0izp9R265LtXw/BgDfqVGureaRFgW01Jun69CAu9jpbjKxddGbckEERfF6t3CDD3ZlZvXf3g3Jip4AOYPkjpVpGEcQ7+skVeTDLULlBXKEv/VVNTPOMEZFWZ1KPQuj/oyvngZW4xcg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=apertussolutions.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=C4smHa1qGEBB9avk0ZbJBURnL+T92NB2xIiCHq9iiOQ=;
 b=QgTZleaN42aXwOvoYR9eQkNkh6jcK34QfcE8imHeKtA06uYzCwi4Lz2a9rcLPybb/hSrsOHfF0QwnHzElAfXmpDzZiRBGkmubPf9fdkNop3Yf1tDb/JMLBeB3CK0ffu8lsaLz7gIt5/b1XVoBwayrIQUJec0cNUZOzOaWDT4xC8=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <aa9b0bf9-5d71-4fc0-a11f-3c0d0e9649ca@amd.com>
Date: Wed, 15 Jan 2025 14:42:57 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 12/15] x86/hyperlaunch: specify dom0 mode with device
 tree
To: "Daniel P. Smith" <dpsmith@apertussolutions.com>,
	<xen-devel@lists.xenproject.org>
CC: <christopher.w.clark@gmail.com>, <stefano.stabellini@amd.com>, Jan Beulich
	<jbeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
 <20241226165740.29812-13-dpsmith@apertussolutions.com>
Content-Language: en-US
From: Jason Andryuk <jason.andryuk@amd.com>
In-Reply-To: <20241226165740.29812-13-dpsmith@apertussolutions.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB05.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000E9D2:EE_|IA1PR12MB8334:EE_
X-MS-Office365-Filtering-Correlation-Id: eb7f30f8-45a6-428c-aecb-08dd359cd2f6
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|82310400026|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?TXA2cExYYTNpTFVJNjhRSGtaN2drU2txQisxL0JobHZWME1MeGM5Vk5Bdkk2?=
 =?utf-8?B?NWtvOVZocWVwbGo3dS94eDdDdEdraTJNZlZRY2w0RkxkbzA5NlRVZUNNdWFy?=
 =?utf-8?B?NVhaVnRVYU95djh2anZkYjdLMWtkK1Qxc3RhOWdITC9kcXB0UHlwUHJka2VL?=
 =?utf-8?B?YnlSKyt0eit5UUYrUkVDZFIyVkdDWDJTSThJYmNOdEd6Z2EyeGUrRzd0V05V?=
 =?utf-8?B?Z0Q1cDZLVnBCcHBtNlRYbFE4Y1RiU2duL1ROb2NPWGpodjdvQmpKVlV6Sk5V?=
 =?utf-8?B?bjMzc1paNzNRWUo3cTdzZnZpZCs1ZldFRC84MWdlYTVEcWpGM1dab2o5YWNY?=
 =?utf-8?B?c0s0U0dSdGFoZ3czR2NQWUhmd3R6cVJvdngyMEJ5SnJHdTVPeFpwOHo5MEll?=
 =?utf-8?B?blJaY2J5dHpER3JVRlRUd2dCYnJFQzhVQkdtV1gwbFZzb0hDWGEvWm90R3Fk?=
 =?utf-8?B?blBXMHVsWTR3RkttZGd6TGRZbWJrUDFxblgyREFNUEtnTzVzbHlNcEdwbXM2?=
 =?utf-8?B?NWd5MHlmbEdiTzV2TFg5VkIvWTZXbWNlcU4yZUN3RHYxb1BxQ01sNEdmeUtQ?=
 =?utf-8?B?eW5ITWh0L2VoSXpldXVIbGhrTE9vR1pVcnZSakhjaCtjYmkwOWt6RlNET1Fp?=
 =?utf-8?B?YVptWU5aaURrM3h1cGpCc0ltVnJZZzBkYW40SktHNkZqL1F1enBmRTBWc3JK?=
 =?utf-8?B?cENVeFI3WFkrOElac0E3RzljYWxRUTBCN0lPSm9FVk16U0lqUDQ1UkdWdXR2?=
 =?utf-8?B?aURrM21DQ0poTUtDaFhmK0xoNHhkamtWMmxsVVQ1YW8yWmkrKzJ0TkVHZ3Vz?=
 =?utf-8?B?bHAyU2dwNUg0YUNQa3lyeXlQWjNDQVgwUGZnMC8ybnlUbVhwczNWS2MxL1RE?=
 =?utf-8?B?Y0tZeXhObWl1ZHhnSFBnVEdwMGt6bWR2OWNsT0poVVpuZWZTa3VYUTNMRTI5?=
 =?utf-8?B?T0k1RDNMZ01RM1pFeTAvTEx4RTNtdjZlTlBZVzZwb0UvQ3kya3BKWW0rdVNF?=
 =?utf-8?B?cjFGSWVLQVArOEV5RFZJbTZQV1pmclJZMlp4dEhjTFBBdmQ4aFRmbVk5N1I0?=
 =?utf-8?B?M3ZLMkRBSVFwdzR6NjRnMGhFRXQxUXAvR3hScGdmSVh4WkYrajZ6TjBnT0w4?=
 =?utf-8?B?YXlpNHZ3VU9wTDdIQjBxWnZQMksxeGdxeXJueDBTQUtQUXFlc2Rhdmh2K1g4?=
 =?utf-8?B?Y3ZPbUQ2OFBTL1VPRjRSQ0dxZEpMd3daSUVlVDB0S0J2OUNkQU94dWdrWGxH?=
 =?utf-8?B?UFphd3Q4UWRqQWpRUXB1K1AycEhpLzFOMHY3WVBBL3UxbW54MWUvZW1FdjNE?=
 =?utf-8?B?cGx2RldzNytVckRaUWIxeVlLKzZ4VDZoYmtkeWVKWUc5aktuaVZaRkVtUUFL?=
 =?utf-8?B?R1RSY2N2M2RkNkdDY1JaQ0lLc0FPTTBIZ1VoYU5QVm05SlJFUXYzRndpTUdS?=
 =?utf-8?B?VkIwK25ndU9uQ3I3R0RXVjFNNnhlMjVvZXA0em91L1ZzbFMra0t3aGhMT1k4?=
 =?utf-8?B?Z3RUbS9iNEZpeDRlOWt6ejlDTFMrdVZXazJuZ1M4ZVZEQVg4VVhJOTlKY3V0?=
 =?utf-8?B?Z1BDNzhIeVJOTW50aGdkOHRxVDJxUnJaRGV5ZC9kWEgwTFlBVHBMV3Vod1Mz?=
 =?utf-8?B?YU4zaDM0WHZmdjhFdWkwdWdRTDVnY1JSeEVJaU9TaFo0SHJadTFNL3RudnJN?=
 =?utf-8?B?UFBzVTBqcnQ2NUVVWDJKcWxPL1FTK3F2RmN1WjBheXFNM3lJbU9OSFBoR2ts?=
 =?utf-8?B?MnNpMzlMN1hUQTJoUWdQNlhaYmI0eExoZStpRkJRTGl3N3Z0U3IrUXNOdG91?=
 =?utf-8?B?ckw3YUJmcUFka2tFL2JiR3lDcU1CbzY5N0htWDlUQ0pHNVVFUGhPakxOQXpi?=
 =?utf-8?B?Tmd4cm1Td1c2bVByQm53UVl5K0x1Smx4ai8rN1JlU2E1dkZ5b0FTQXhDdEJj?=
 =?utf-8?B?TzhSei8xVSswK05JeEpJM0laajVoUTRXbjRJWjR6ZEpiOWViNkc4UEszTWxL?=
 =?utf-8?Q?suMjKOsNiiLhastRlBLKJbS953d/0Q=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(82310400026)(1800799024)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2025 19:43:02.5311
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: eb7f30f8-45a6-428c-aecb-08dd359cd2f6
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CY4PEPF0000E9D2.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB8334

On 2024-12-26 11:57, Daniel P. Smith wrote:
> Enable selecting the mode in which the domain will be built and ran. This

s/built and ran/built and run/

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 19:51:09 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 19:51:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873074.1284056 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY9Ps-00030C-2C; Wed, 15 Jan 2025 19:51:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873074.1284056; Wed, 15 Jan 2025 19:51:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY9Pr-000305-Vg; Wed, 15 Jan 2025 19:51:03 +0000
Received: by outflank-mailman (input) for mailman id 873074;
 Wed, 15 Jan 2025 19:51:02 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=ppZO=UH=amd.com=Jason.Andryuk@srs-se1.protection.inumbo.net>)
 id 1tY9Pq-0002zz-76
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 19:51:02 +0000
Received: from NAM04-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam04on20601.outbound.protection.outlook.com
 [2a01:111:f403:2409::601])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0b1ae9e3-d37a-11ef-a0e2-8be0dac302b0;
 Wed, 15 Jan 2025 20:51:01 +0100 (CET)
Received: from PH7PR17CA0001.namprd17.prod.outlook.com (2603:10b6:510:324::25)
 by PH8PR12MB7373.namprd12.prod.outlook.com (2603:10b6:510:217::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8335.21; Wed, 15 Jan
 2025 19:50:55 +0000
Received: from SN1PEPF000397B4.namprd05.prod.outlook.com
 (2603:10b6:510:324:cafe::ef) by PH7PR17CA0001.outlook.office365.com
 (2603:10b6:510:324::25) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8356.13 via Frontend Transport; Wed,
 15 Jan 2025 19:50:54 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SN1PEPF000397B4.mail.protection.outlook.com (10.167.248.58) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8356.11 via Frontend Transport; Wed, 15 Jan 2025 19:50:54 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 15 Jan
 2025 13:50:54 -0600
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 15 Jan
 2025 13:50:54 -0600
Received: from [172.27.3.102] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Wed, 15 Jan 2025 13:50:53 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 0b1ae9e3-d37a-11ef-a0e2-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Wt3GjgMtIe5Cu4iSL79/8dEJyl26YEwHgofulbGVwdF08CDjKZlmAErlseHbmBs/e8tDg96PbMGgE0vgjKJl+2MBGxxu1zoLZK12c6yXOZb2+UXKiluNjz2b08XAS3Iccyg7teusAiH5RKmwybXG3V1lDvS+1yXrppg+pUJ47lh58HR+QkYLs9tkGAWcwh7YmbKgFb14+RFU2MuY1kXHoYGnioNr31ctepZA/w9yrH7tC484PiJzULWHaDTPEn7SuXU6NFWXyOk+3hee4+YbGfR3W7l/m3PGKgY3DQRWG4oanJwWYTDgKBMQVEKBliJ4d8xSgFYK5nGOqY1b+1MfBg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=seD+oyU96rm9OHwuiSKSM0dOceEInH33mH+S6spoIzM=;
 b=uhv21AuooVyd6Rwehg1NCxIACETacphnC474EnyXpdtjHeIZuDA3UkZtT5FkjHk+pXBJg2zECcPVc+aFRrpYzukvcPGdsYdFUzt9oZaE6tv0jUvVnR+BEOp+mrF5sDnCI+LznRBhea3wo3WmgYC691m1KtEY6FONhWJHqbSjAL6rMAA0vpcWwvC/ewTK40Jk6PHsFqulJeYsPyw933kDIoyOnuoRcPhLrAw4x9kBp9mJ/dW+s+jaD/g2MXcOuYSd4hT0Q2d6NnmrHq7Kq/hSQmIB1riPmEFknWRjmhbIe/TpZlSllSRmnlwCCKqxPAy4b1FR6CMcAMwtb5AdZFGYDg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=apertussolutions.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=seD+oyU96rm9OHwuiSKSM0dOceEInH33mH+S6spoIzM=;
 b=q3wpiaUfmpj+DZxBaTvJXiLgHEehgeso90XOq8cJG89AeMWowsA/KcPdYq5+02a9U5eLZvj6tcf7YmPT7xQAq/FQWg1CI7fCFRLwOGqJdV3Xgdscryt6dQMCmWzIGALLDtUcSAXd++30UuJcKRtan/hZl365hm7gtfTdk5rNykE=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <8b2f2a42-58cb-46dd-a278-069ccc03a4ad@amd.com>
Date: Wed, 15 Jan 2025 14:50:50 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 03/15] x86/boot: add cmdline to struct boot_domain
To: "Daniel P. Smith" <dpsmith@apertussolutions.com>,
	<xen-devel@lists.xenproject.org>
CC: <christopher.w.clark@gmail.com>, <stefano.stabellini@amd.com>, Jan Beulich
	<jbeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
 <20241226165740.29812-4-dpsmith@apertussolutions.com>
 <508cff3c-3fd4-4ab7-89ef-30a72a267111@amd.com>
 <245a2a00-98c0-498f-8a9e-ca62dbe59a71@apertussolutions.com>
Content-Language: en-US
From: Jason Andryuk <jason.andryuk@amd.com>
In-Reply-To: <245a2a00-98c0-498f-8a9e-ca62dbe59a71@apertussolutions.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Received-SPF: None (SATLEXMB05.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF000397B4:EE_|PH8PR12MB7373:EE_
X-MS-Office365-Filtering-Correlation-Id: 1919d656-b119-44b7-0a53-08dd359dec60
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|36860700013|82310400026|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?bElDOHJQUWIvRWRENWxUTzgydkZnUHF6VDNTa2lWZHA3cWttNERmaHdBbUhY?=
 =?utf-8?B?UzhqQUUxUW84d1pFbThKelh5MDFVcmhQeUZ3TmNVQU9XU0p4Z0cxdGhFelAz?=
 =?utf-8?B?NnYzMmRHWWNicjZEUXlpSE9UQUFRZGZDN0swZFhhdVNueUdoNVhLb2ZZTDdk?=
 =?utf-8?B?NjM1ajdFWTEwSStkelQ1U1FvV2k0YjlqWXkwcGt1NGpZb1FUc1BKRDhxQUdB?=
 =?utf-8?B?MEV0SDNOTWNjZHE4S1RnaENRUVd3c1RxSEhHekpoREVqR01YZTFiaFdHdXNU?=
 =?utf-8?B?M05xSVFSOWQzMDNUU1NVWFdUVytCcDd2VjRjT0JWbityd0ppS2V5QXhjWUFw?=
 =?utf-8?B?S3F2Qmh2SVVSeUpZTU4vbW9nTkdXdUNpTGtIZnJ6c2s2dnJia1I2alNpenVH?=
 =?utf-8?B?aDF4TitQcWR5QmdkRm9XVlEwUm5PTit1SnQyY1ZDaDBGRWRZMWNCWWVqc003?=
 =?utf-8?B?RWJqeDVBRTRncVUxTzdFZm1UTTBjM1dHQWZJUzVMR2JhMnNlcUlSSVVXSWRT?=
 =?utf-8?B?eFhxdk9KckxPS3NiMlFBYXdYK3lRQ1VCY2xZL0dvdzJCT0Y2Wi9aQUYvaGpl?=
 =?utf-8?B?TzBjb004bDlEb1Y1Y1E1bmtMT1ZocUJsZFpoSlpXRW11ZmtWRThBN080Vndh?=
 =?utf-8?B?R0NxN3NLdDA2UDBjbXpYaUNoOG5scHEyRlRlT3d0L2dVSE80cnJFUW83QW9u?=
 =?utf-8?B?bHcrcmxrOVpVdGxmRERhbFpNdFZKV3Q0VXRNM0FwVEhNOVdBcUlnN2hsbDhU?=
 =?utf-8?B?aFJXcnhVZnA4WnJtZ291TWI1dG41MWpYYUNLRDhIeGFLWE81bGoyaUdRczlm?=
 =?utf-8?B?bWhBUW9rd1RPbGo4TDVlTzhDZU5rZ3FjT2MzbVFCRDZadU1vTWZkMTFmYmhv?=
 =?utf-8?B?ZEJFTEJRWUpyYWxoeENDVUpnU0hSaW1mZnF4U2Y5ZjM2QVI1MlF5UEpHRG9O?=
 =?utf-8?B?U25RQUlUcUIzcVRpZXc2QjF1T1RhemNXajh4OWxJYVFPSkpJVCsvdWNVK0l2?=
 =?utf-8?B?OFBDNUxWVW5IZ2J5Rm1lRER2aEJodTZkU2M3TlFjY1VZQ3pCRjdYN1FIYjZi?=
 =?utf-8?B?WGhuWnJOeGVJK0R2TzR2UmdYQ3RpVnBvVGZvSmltVnIyOWhPL2tVZnVnQld6?=
 =?utf-8?B?eGYxS0V3TDVWUnBuREpweGZuZFNGcnJaQ0JGb2UzSWFYVGFzMzZTNnl4NDVY?=
 =?utf-8?B?c2dlRUVRTm50dEpEWHE3Q3liNG56KzJPZTlUckFQd2U4SkJRdnZHamdNY3Ur?=
 =?utf-8?B?Nmp3Slh4TVpoM2h0N2U4VDFZc1dBNmE1aWVBeDNhU0Y0dk9DNGduK1JPaFkz?=
 =?utf-8?B?ekVFYW1NbTZneVc1aklaOUFIWmhEZXZlcitoT3MvZXJJNk96L0gyS3Urd0Z4?=
 =?utf-8?B?V1ppTVhGUVV1bGpwUFBIMm9BSVhTVFFBMHNDVWtPUHc5cDBTWHNwelFqUWJH?=
 =?utf-8?B?SHByKy82V0pzOGJUUlk5eGt2dkZVOHN5bk1KM0xOOU9ObTFEM0U3bkZQRERT?=
 =?utf-8?B?V2toY3Q5QWVBQUVPKytKcWFwYjBwVkprSzc2bXU4ZUY5UU9MczgxQmllYjVm?=
 =?utf-8?B?VHl6aTB5SHZaem00ZityZDBuMzJlL0JkcGtYalZYUisyU0lhTk43aHpGWFNT?=
 =?utf-8?B?NU5UVzJ0eElyYUhyYlNJckJTNGhBWm44b1BlTXM4OXVlVTNGUjVQaFhxNVBO?=
 =?utf-8?B?aUhUUml6UnA2cFd1RWsxaDNYMHBsdEpaT0tVZ2VEMlo2WFhncnlrYzNSTVdX?=
 =?utf-8?B?UUJWZDFsUW43ZTJvMmQrZDJJMzlqM29Na3M0TU41N25YSkhmTjE5Q25aVTdn?=
 =?utf-8?B?amsyMTh0ZkRldnpYNTRsQVV2K2JzMVVSYzhuY0F5VTBwUGgxN3dOV2FZQmxi?=
 =?utf-8?B?elI1d1k1d0RFTmJDTktZZjZkbmgyRTNyQmZNREV5UGlVRjFuT2ZsRlJabjhP?=
 =?utf-8?B?MFRmVzFhRm91WDlyMXdsZ0swL2UrTVBPRTJNSWw3L21SUFYyQzhRSlo0MU9O?=
 =?utf-8?Q?DoTyQ789a6QVWmRnjpY120mFH0upt4=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(376014)(36860700013)(82310400026)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2025 19:50:54.7551
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1919d656-b119-44b7-0a53-08dd359dec60
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF000397B4.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB7373

On 2025-01-15 12:22, Daniel P. Smith wrote:
> On 1/10/25 14:52, Jason Andryuk wrote:
>> On 2024-12-26 11:57, Daniel P. Smith wrote:
>>> Add a container for the "cooked" command line for a domain. This 
>>> provides for
>>> the backing memory to be directly associated with the domain being 
>>> constructed.
>>> This is done in anticipation that the domain construction path may 
>>> need to be
>>> invoked multiple times, thus ensuring each instance had a distinct 
>>> memory
>>> allocation.
>>>
>>> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
>>
>>
>>> @@ -1018,39 +1037,52 @@ static struct domain *__init 
>>> create_dom0(struct boot_info *bi)
>>>           panic("Error creating d%uv0\n", bd->domid);
>>>       /* Grab the DOM0 command line. */
>>> -    if ( bd->kernel->cmdline_pa || bi->kextra )
>>> +    if ( (bd->kernel->cmdline_pa &&
>>> +          ((char *)__va(bd->kernel->cmdline_pa))[0]) ||
>>> +         bi->kextra )
>>>       {
>>> -        if ( bd->kernel->cmdline_pa )
>>> -            safe_strcpy(cmdline,
>>> -                        cmdline_cook(__va(bd->kernel->cmdline_pa), 
>>> bi->loader));
>>> +        size_t cmdline_size = domain_cmdline_size(bi, bd);
>>> +
>>> +        if ( cmdline_size )
>>> +        {
>>> +            if ( !(cmdline = xzalloc_array(char, cmdline_size)) )
>>> +                panic("Error allocating cmdline buffer for %pd\n", d);
>>
>> I guess I wasn't clear last time.  Instead of two levels of indent, I 
>> was thinking at the top level:
>>
>>      /* Grab the DOM0 command line. */
>>      cmdline_size = domain_cmdline_size(bi, bd);
>>      if ( cmdline_size )
>>      {
>>
>> domain_cmdline_size() checks all the pointers, so this removes 
>> duplication and indent.
> 
> But it is possible for there to be no command line, thus there is a 
> legitimate case where cmdline_size will be 0. If it is 0, there is no 
> reason to go through all of this logic.

Sure, but domain_cmdline_size() already handles an empty command line 
and returns 0 for that.  So I think this logic is still skipped in that 
case.

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 20:09:41 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 20:09:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873087.1284067 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY9hn-0005Fn-JR; Wed, 15 Jan 2025 20:09:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873087.1284067; Wed, 15 Jan 2025 20:09:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tY9hn-0005Fg-Fu; Wed, 15 Jan 2025 20:09:35 +0000
Received: by outflank-mailman (input) for mailman id 873087;
 Wed, 15 Jan 2025 20:09:33 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=8EWj=UH=kernel.org=wei.liu@srs-se1.protection.inumbo.net>)
 id 1tY9hl-0005FE-SB
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 20:09:33 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9df69bfc-d37c-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 21:09:25 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 41F7BA42164;
 Wed, 15 Jan 2025 20:07:36 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id D9A6BC4CED1;
 Wed, 15 Jan 2025 20:09:22 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9df69bfc-d37c-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1736971763;
	bh=HKd2BYN0EJzvcqr3Xx3Vueop4tDJh+K1d/v1F43ixq4=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=mMh7oPcJEGeeR1CbLFNvT6sYm/PkFQwDWfBsQ90yztglpZ3/YZEBVnarQ1AC7szWo
	 7TIaoC/5Ds9yuqwsCSv511HrZQrz9DYKTCs5teywBQChtbtwCLdUU15B57wDXyESFf
	 A/x13wKP5lj3nSG+MtRjOv+yVwR6g+BlMg1RaQLmyhmo5lqJ4XKmsH9giN7zUcgT0G
	 JjdlmRxxbsFDdoqRPMfd7BNNsEMs0mR8Cyqj/oCkFnsbRsTmQflWeOU3bRrVWJH9mq
	 wFz46x9sk38sYnuYTKWOXCW+bAgDPbIH7khSU1whNzE/e3Hn5P+2qU6Lun6bUVc/Ly
	 lJaxe0RpKwpyA==
Date: Wed, 15 Jan 2025 20:09:21 +0000
From: Wei Liu <wei.liu@kernel.org>
To: Joel Granados <joel.granados@kernel.org>
Cc: Thomas =?iso-8859-1?Q?Wei=DFschuh?= <linux@weissschuh.net>,
	Kees Cook <kees@kernel.org>, Luis Chamberlain <mcgrof@kernel.org>,
	linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,
	linux-s390@vger.kernel.org, linux-crypto@vger.kernel.org,
	openipmi-developer@lists.sourceforge.net,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	intel-xe@lists.freedesktop.org, linux-hyperv@vger.kernel.org,
	linux-rdma@vger.kernel.org, linux-raid@vger.kernel.org,
	linux-scsi@vger.kernel.org, linux-serial@vger.kernel.org,
	xen-devel@lists.xenproject.org, linux-aio@kvack.org,
	linux-fsdevel@vger.kernel.org, netfs@lists.linux.dev,
	codalist@coda.cs.cmu.edu, linux-mm@kvack.org,
	linux-nfs@vger.kernel.org, ocfs2-devel@lists.linux.dev,
	fsverity@lists.linux.dev, linux-xfs@vger.kernel.org,
	io-uring@vger.kernel.org, bpf@vger.kernel.org,
	kexec@lists.infradead.org, linux-trace-kernel@vger.kernel.org,
	linux-hardening@vger.kernel.org, apparmor@lists.ubuntu.com,
	linux-security-module@vger.kernel.org, keyrings@vger.kernel.org,
	Song Liu <song@kernel.org>,
	"Steven Rostedt (Google)" <rostedt@goodmis.org>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	"Darrick J. Wong" <djwong@kernel.org>,
	Jani Nikula <jani.nikula@intel.com>,
	Corey Minyard <cminyard@mvista.com>, Wei Liu <wei.liu@kernel.org>
Subject: Re: [PATCH v2] treewide: const qualify ctl_tables where applicable
Message-ID: <Z4gV8QNnafm-iCC4@liuwe-devbox-debian-v2>
References: <20250110-jag-ctl_table_const-v2-1-0000e1663144@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250110-jag-ctl_table_const-v2-1-0000e1663144@kernel.org>

On Fri, Jan 10, 2025 at 03:16:08PM +0100, Joel Granados wrote:
[...]
> diff --git a/drivers/hv/hv_common.c b/drivers/hv/hv_common.c
> index 7a35c82976e0..9453f0c26f2a 100644
> --- a/drivers/hv/hv_common.c
> +++ b/drivers/hv/hv_common.c
> @@ -141,7 +141,7 @@ static int sysctl_record_panic_msg = 1;
>   * sysctl option to allow the user to control whether kmsg data should be
>   * reported to Hyper-V on panic.
>   */
> -static struct ctl_table hv_ctl_table[] = {
> +static const struct ctl_table hv_ctl_table[] = {
>  	{
>  		.procname	= "hyperv_record_panic_msg",
>  		.data		= &sysctl_record_panic_msg,

Acked-by: Wei Liu <wei.liu@kernel.org>


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 21:14:31 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 21:14:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873102.1284077 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYAiN-0006c0-2s; Wed, 15 Jan 2025 21:14:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873102.1284077; Wed, 15 Jan 2025 21:14:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYAiM-0006bt-W9; Wed, 15 Jan 2025 21:14:14 +0000
Received: by outflank-mailman (input) for mailman id 873102;
 Wed, 15 Jan 2025 21:14:13 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=9vXr=UH=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tYAiL-0006bn-0l
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 21:14:13 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a8c99e82-d385-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 22:14:09 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id DEC06A4257D;
 Wed, 15 Jan 2025 21:12:19 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 92BD8C4CED1;
 Wed, 15 Jan 2025 21:14:05 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a8c99e82-d385-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1736975647;
	bh=GSZxHIs9dp+FZg5P9WqYYWNg3o6iXgaDEmNeunkFR5Y=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=nz+0ZO0maeYDVcdt4IttvrH2VJaySUaTh81HiQqvbLgKFaMmS1uL2pL/Uw4t1WsYn
	 OTPVtWL2eGn7MjzNyhaa+VC+Uh0qlCf0NbTXY5Gz3QGG9KjotVxVOwUSn2FzB0j7j7
	 aBN7rpbhTnuPNM7obnAGq40hj9BQNt08yq6MqJTZ7Aqw+5dIAH9+PKcH4lksL/s18I
	 i2P/D/fWusSFAAl0Hk5499Cn7yFXuMIrSmGEQ7PLT3ijyVGjYu4j9iaSzjz+Dz1I8P
	 97s3QmeMQfRReqzhMPt84KOKdTBjDVmMfhkgQrF66yoot6y+9S61dS0xhdoD/mvKha
	 8r4xsGMI4q/mw==
Date: Wed, 15 Jan 2025 13:14:04 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: =?UTF-8?Q?Milan_=C4=90oki=C4=87?= <milandjokic1995@gmail.com>
cc: Oleksii Kurochko <oleksii.kurochko@gmail.com>, 
    Stefano Stabellini <sstabellini@kernel.org>, 
    linux-riscv@lists.infradead.org, paul.walmsley@sifive.com, 
    palmer@dabbelt.com, aou@eecs.berkeley.edu, jgross@suse.com, 
    oleksandr_tyshchenko@epam.com, Slavisa.Petrovic@rt-rk.com, 
    Milan.Djokic@rt-rk.com, rafael.j.wysocki@intel.com, 
    sunilvl@ventanamicro.com, takakura@valinux.co.jp, 
    linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, 
    iommu@lists.linux.dev
Subject: Re: [PATCH] riscv: Add initial Xen guest support for RISC-Vgh
In-Reply-To: <CAKp59VEOiXo+OKwPNiomtXNCsfDURCXaDktooi5JSoTSdhc90w@mail.gmail.com>
Message-ID: <alpine.DEB.2.22.394.2501151313590.2684657@ubuntu-linux-20-04-desktop>
References: <e4a649a7fdfc8fcf5f48a0bc4e76e5d546078083.1736868605.git.Slavisa.Petrovic@rt-rk.com> <alpine.DEB.2.22.394.2501141554170.2684657@ubuntu-linux-20-04-desktop> <2f1432e6-0d27-48fd-b034-475284f14233@gmail.com>
 <CAKp59VEOiXo+OKwPNiomtXNCsfDURCXaDktooi5JSoTSdhc90w@mail.gmail.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-1821502211-1736975200=:2684657"
Content-ID: <alpine.DEB.2.22.394.2501151307240.2684657@ubuntu-linux-20-04-desktop>

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-1821502211-1736975200=:2684657
Content-Type: text/plain; CHARSET=UTF-8
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine.DEB.2.22.394.2501151307241.2684657@ubuntu-linux-20-04-desktop>

On Wed, 15 Jan 2025, Milan Đokić wrote:
> Hello Stefano, Oleksii
> 
> On Wed, Jan 15, 2025 at 5:30 PM Oleksii Kurochko
> <oleksii.kurochko@gmail.com> wrote:
> >
> > Hi Stefano,
> >
> > On 1/15/25 1:01 AM, Stefano Stabellini wrote:
> >
> > +Oleksii
> >
> > On Tue, 14 Jan 2025, Milan Djokic wrote:
> >
> > From: Slavisa Petrovic <Slavisa.Petrovic@rt-rk.com>
> >
> > This patch introduces initial support for running RISC-V as a Xen guest.
> > It provides the necessary infrastructure and stubs for Xen-specific
> > operations. Key changes include:
> >
> > - Modifications to the RISC-V kernel to integrate Xen-specific hypercalls
> >   and interfaces, with function implementations stubbed for future work.
> > - Introduction of Xen-specific headers for RISC-V, including event
> >   handling, hypervisor interaction, and page management. Functions are
> >   defined but not yet implemented.
> > - Stub implementations for memory management, grant tables, and context
> >   switching in the Xen environment, allowing further development and
> >   integration.
> >
> > Signed-off-by: Milan Djokic <Milan.Djokic@rt-rk.com>
> > Signed-off-by: Slavisa Petrovic <Slavisa.Petrovic@rt-rk.com>
> >
> > Hi Milan, Slavisa,
> >
> > Thank you very much for your contribution! Which Xen tree are you using
> > for development?
> >
> > They are using [1] and have separate branches on top of latest. So we are in
> > sync. Also, if you are interested we have created a task/epics for this feature in
> > [1] so you could also check there some details:
> > 1. https://gitlab.com/groups/xen-project/people/olkur/-/epics/5
> > 2. https://gitlab.com/xen-project/people/olkur/xen/-/issues/12
> >
> >  I am asking because RISC-V support in Xen is still in
> > the process of being upstreamed, and [1] is the tree that consolidates
> > all patches currently on the to-be-upstreamed list.
> >
> > While the specific Xen tree you are using is not particularly important
> > at this stage, and using [1] is not a requirement, I am asking because
> > it is essential to align on the hypervisor ABI, especially regarding any
> > details that have not yet been upstreamed. Specifically, is there
> > anything in this patch series that relies on features not yet upstream
> > in Xen?
> >
> > There are few features but some things which are Rt-Tk's branch in [1] could go
> > without waiting for these features to be upstreamed.
> >
> > Thanks.
> >
> > ~ Oleksii
> >
> > [1] https://gitlab.com/xen-project/people/olkur/xen/-/tree/latest?ref_type=heads
> 
> As Oleksii already explained, we are working in sync with his latest
> branch where most of the risc port is done.

Perfect, I was hoping you'd say that! :-)
It is great to have you on board.


> I would just add that this patch introduces kernel risc-v hypercall
> support on which only our branch on xen tree depends on. Therefore, it
> won't disrupt any functionality with current upstream Xen, it will
> just introduce kernel functionality which is not used from Xen side
> until our branch is merged upstream.

Ideally, we should upstream the Xen side of an interface first to Xen,
then add support for the interface to Linux. Let me make a concrete
example. Let's say that you upstream hypercall support to Linux first,
using SBI_ECALL defined as 0xE. Then, during the upstreaming process,
the Xen community decides to change SBI_ECALL to 0XEA1 to make it the
same as ARM. You'd have to change the Linux code again to fix it. To
avoid this, it is best to wait upstreaming the Linux side, until the Xen
side is Acked.

This was just an example, and Andrew is right that the SBI
Implementation ID for Xen is reserved to 0x7, see the SBI specification.
--8323329-1821502211-1736975200=:2684657--


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 21:16:39 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 21:16:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873110.1284087 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYAkf-00079F-F1; Wed, 15 Jan 2025 21:16:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873110.1284087; Wed, 15 Jan 2025 21:16:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYAkf-000798-BJ; Wed, 15 Jan 2025 21:16:37 +0000
Received: by outflank-mailman (input) for mailman id 873110;
 Wed, 15 Jan 2025 21:16:36 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=9vXr=UH=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tYAke-000791-3P
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 21:16:36 +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 ff4cbffe-d385-11ef-a0e2-8be0dac302b0;
 Wed, 15 Jan 2025 22:16:34 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 81EA15C5EBC;
 Wed, 15 Jan 2025 21:15:52 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id ABDFBC4CED1;
 Wed, 15 Jan 2025 21:16:31 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ff4cbffe-d385-11ef-a0e2-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1736975793;
	bh=Z1FkJy2ZJlX5J2H6d8Cx6I2J1RaILxhF7JAP7P6Pmi0=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=g95udV+RaCe8TPuhEW6NvdUba+PsCldWRK7BonznA7pa3OHxkKC6Sc0sdjMBI/kIU
	 uMw/XZB1V25bE3AzUivUnrer3DGhFNTE0hHLxhD1QdFPv4JdQ1WLPX3km/1pmEcNfj
	 2LiRd0ZI+2WA6z3rALP1AS5cRVfur8uDOhm/zk/VXFnbvLwgttgD25m0kaQtoAx6d2
	 73UxNCYGgzBSQc3mmIpmwty/i0I6r2NWcYrsUNrMsvNyhHaXJ1bGde1RK90v5OMhwF
	 ZtOAKSS3QzMeKi2iZtd9y78cLD8QP7AmbYQmlF/HP0f4BBpHP41B0FGFu2xD+bJPzU
	 xE4JOrWngauQw==
Date: Wed, 15 Jan 2025 13:16:30 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Frediano Ziglio <frediano.ziglio@cloud.com>
cc: Bernhard Kaindl <bernhard.kaindl@cloud.com>, 
    xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, 
    Anthony PERARD <anthony.perard@vates.tech>, 
    Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>, 
    Julien Grall <julien@xen.org>, 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
    Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH] Design docs: Fix some typos in the design docs
In-Reply-To: <CACHz=ZjgkDUsxSL1vS09A6E3QmPXQTYO3aaoijNUTdoyBK7abg@mail.gmail.com>
Message-ID: <alpine.DEB.2.22.394.2501151316230.2684657@ubuntu-linux-20-04-desktop>
References: <692dabc63953fb0d33536f87e4c5c147ba6ce11c.1736948633.git.bernhard.kaindl@cloud.com> <CACHz=ZjgkDUsxSL1vS09A6E3QmPXQTYO3aaoijNUTdoyBK7abg@mail.gmail.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-699952963-1736975793=:2684657"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-699952963-1736975793=:2684657
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Wed, 15 Jan 2025, Frediano Ziglio wrote:
> On Wed, Jan 15, 2025 at 1:45 PM Bernhard Kaindl
> <bernhard.kaindl@cloud.com> wrote:
> >
> > Skimming through the design docs, I saw some typos that needed fixing.
> >
> > ---
> > Comments for reviewers (not for the commit message itself):
> >
> > Sample typos (some are not easy to spot):
> > - heirarchical: (ei->ie)
> > - implementaiton: (it->ti)
> > - comprimised: (i->o)
> > - contol->control (r)
> >
> > PS: I did the fixes using LTeX in an IDE and re-checked the mail too.
> >
> > Signed-off-by: Bernhard Kaindl <bernhard.kaindl@cloud.com>
> > ---
> >  docs/designs/argo.pandoc                |  4 ++--
> >  docs/designs/nested-svm-cpu-features.md | 12 ++++++------
> >  docs/designs/qemu-deprivilege.md        |  8 ++++----
> >  docs/designs/xenstore-migration.md      |  2 +-
> >  docs/features/qemu-deprivilege.pandoc   |  2 +-
> >  5 files changed, 14 insertions(+), 14 deletions(-)
> >
> > diff --git a/docs/designs/argo.pandoc b/docs/designs/argo.pandoc
> > index e18aacea7c..cd854d2a7a 100644
> > --- a/docs/designs/argo.pandoc
> > +++ b/docs/designs/argo.pandoc
> > @@ -58,7 +58,7 @@ concurrency.
> >
> >  Avoidance of deadlock is essential and since state must frequently be updated
> >  that pertains to more than one domain, a locking protocol defines which locks
> > -are needed and the order of their acquistion.
> > +are needed and the order of their acquisition.
> >
> >  ## Structure
> >
> > @@ -127,7 +127,7 @@ by the domain.
> >
> >  ## Hierarchical Locking Model and Protocol
> >
> > -The locking discipline within the Argo code is heirarchical and utilizes
> > +The locking discipline within the Argo code is hierarchical and utilizes
> >  reader/writer locks to enable increased concurrency when operations do not
> >  conflict. None of the Argo locks are reentrant.
> >
> > diff --git a/docs/designs/nested-svm-cpu-features.md b/docs/designs/nested-svm-cpu-features.md
> > index 837a96df05..c855748141 100644
> > --- a/docs/designs/nested-svm-cpu-features.md
> > +++ b/docs/designs/nested-svm-cpu-features.md
> > @@ -22,7 +22,7 @@ leaf 8000000A:edx
> >    from the L1 hypervisor's perspective to be as close as possible to
> >    the original hardware.  In particular, the behavior of the hardware
> >    on error paths 1) is not easy to understand or test, 2) can be the
> > -  source of surprising vulnerabiliies.  (See XSA-7 for an example of a
> > +  source of surprising vulnerabilities.  (See XSA-7 for an example of a
> >    case where subtle error-handling differences can open up a privilege
> >    escalation.)  We should avoid emulating any bit of the hardware with
> >    complex error paths if we can at all help it.
> > @@ -59,11 +59,11 @@ leaf 8000000A:edx
> >
> >  - 2 `SVML` *SVM Lock*: Not required for L0, not provided to L1
> >
> > -  Seems to be aboult enabling an operating system to prevent "blue
> > +  Seems to be about enabling an operating system to prevent "blue
> >    pill" attacks against itself.
> >
> >    Xen doesn't use it, nor provide it; so it would need to be
> > -  implementend.  The best way to protect a guest OS is to leave nested
> > +  implemented.  The best way to protect a guest OS is to leave nested
> >    virt disabled in the tools.
> >
> >  - 3 `NRIPS` NRIP Save: Require for both L0 and L1
> > @@ -78,8 +78,8 @@ leaf 8000000A:edx
> >    The main putative use for this would be trying to maintain an
> >    invariant TSC across cores with different clock speeds, or after a
> >    migrate.  Unlike others, this doesn't have an error path to worry
> > -  about compatibility-wise; and according to tests done when nestedSVM
> > -  was first implemented, it's actually faster to emliate TscRateMSR in
> > +  about compatibility-wise; and according to tests done when nested SVM
> > +  was first implemented, it's actually faster to emulate TscRateMSR in
> >    the L0 hypervisor than for L1 to attempt to emulate it itself.
> >
> >    However, using this properly in L0 will take some implementation
> > @@ -89,7 +89,7 @@ leaf 8000000A:edx
> >   - 5 `VmcbClean`: VMCB Clean Bits: Not required by L0, provide to L1
> >
> >    This is a pure optimization, both on the side of the L0 and L1.  The
> > -  implementaiton for L1 is entirely Xen-side, so can be provided even
> > +  implementation for L1 is entirely Xen-side, so can be provided even
> >    on hardware that doesn't provide it.  And it's purely an
> >    optimization, so could be "implemented" by ignoring the bits
> >    entirely.
> > diff --git a/docs/designs/qemu-deprivilege.md b/docs/designs/qemu-deprivilege.md
> > index f12b1a3ae3..603491f24d 100644
> > --- a/docs/designs/qemu-deprivilege.md
> > +++ b/docs/designs/qemu-deprivilege.md
> > @@ -22,7 +22,7 @@ The following restrictions are currently implemented.
> >  '''Description''': As mentioned above, having QEMU switch to a
> >  non-root user, one per domain id.  Not being the root user limits what
> >  a compromised QEMU process can do to the system, and having one user
> > -per domain id limits what a comprimised QEMU process can do to the
> > +per domain id limits what a compromised QEMU process can do to the
> >  QEMU processes of other VMs.
> >
> >  '''Implementation''': The toolstack adds the following to the qemu command-line:
> > @@ -79,8 +79,8 @@ Then adds the following to the qemu command-line:
> >  ## Namespaces for unused functionality (Linux only)
> >
> >  '''Description''': QEMU doesn't use the functionality associated with
> > -mount and IPC namespaces. (IPC namespaces contol non-file-based IPC
> > -mechanisms within the kernel; unix and network sockets are not
> > +mount and IPC namespaces. (IPC namespaces control non-file-based IPC
> > +mechanisms within the kernel; Unix and network sockets are not
> >  affected by this.)  Making separate namespaces for these for QEMU
> >  won't affect normal operation, but it does mean that even if other
> >  restrictions fail, the process won't be able to even name system mount
> > @@ -251,7 +251,7 @@ executing QEMU.  (But this would then require other changes to create
> >  the QMP socket, VNC socket, and so on).
> >
> >  It should be noted that `-sandbox` is implemented as a blacklist, not
> > -a whitelist; that is, it disables known-unsed functionality which may
> > +a whitelist; that is, it disables known-unused functionality which may
> >  be harmful, rather than disabling all functionality except that known
> >  to be safe and needed.  This is unfortunately necessary since qemu
> >  doesn't know what system calls libraries might end up making.  (See
> > diff --git a/docs/designs/xenstore-migration.md b/docs/designs/xenstore-migration.md
> > index 5022268386..082314bf72 100644
> > --- a/docs/designs/xenstore-migration.md
> > +++ b/docs/designs/xenstore-migration.md
> > @@ -372,7 +372,7 @@ or modified by a transaction for which there is also a `TRANSACTION_DATA`
> >  record previously present).
> >
> >  Each _committed_ node in the stream is required to have an already known parent
> > -node. A parent node is known if it was either in the node data base before the
> > +node. A parent node is known if it was either in the node database before the
> >  stream was started to be processed, or if a `NODE_DATA` record for that parent
> >  node has already been processed in the stream.
> >
> > diff --git a/docs/features/qemu-deprivilege.pandoc b/docs/features/qemu-deprivilege.pandoc
> > index 4ef119c821..915e38d8c9 100644
> > --- a/docs/features/qemu-deprivilege.pandoc
> > +++ b/docs/features/qemu-deprivilege.pandoc
> > @@ -25,7 +25,7 @@ dm_restrict is a set of operations to restrict QEMU running in domain
> >
> >   1. Mechanisms to restrict QEMU to only being able to affect its own
> >  domain
> > - 2. Mechanisms to restruct QEMU's ability to interact with domain 0.
> > + 2. Mechanisms to restrict QEMU's ability to interact with domain 0.
> >
> >  # User details
> >
> 
> Reviewed-by: Frediano Ziglio <frediano.ziglio@cloud.com>

Acked-by: Stefano Stabellini <sstabellini@kernel.org>
--8323329-699952963-1736975793=:2684657--


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 21:36:17 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 21:36:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873120.1284097 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYB3c-0001ls-04; Wed, 15 Jan 2025 21:36:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873120.1284097; Wed, 15 Jan 2025 21:36:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYB3b-0001ll-Sj; Wed, 15 Jan 2025 21:36:11 +0000
Received: by outflank-mailman (input) for mailman id 873120;
 Wed, 15 Jan 2025 21:36:11 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=9vXr=UH=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tYB3b-0001lf-2O
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 21:36:11 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b96fc402-d388-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 22:36:06 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id CA39A5C5EF5;
 Wed, 15 Jan 2025 21:35:23 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2E6B3C4CED1;
 Wed, 15 Jan 2025 21:36:03 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b96fc402-d388-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1736976964;
	bh=gaOMzhOuu+3umqXl7QKIx0voC6OUu11F0HSUJr97jWk=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=PhdZe0HehXgI82aCeEQ/CS57XEGQqKc1yRYLzSYAxjjWgJJNNTmbHvf3zKBwNdFIE
	 Zlo646sZ5Cw4EWO8f/7mcmJIdeSuLUdhOiEXtU55n/2Dw2e4R2zrbzpZ3uURHNQVHH
	 WXsO1cNPE03RhG/wUQW9aVDHZR6BoleaMNOeeP/Dr1GrJRhqkenN0XfMHLxp99L+rF
	 Prb4VUEPSsAANQp58p2oLUdLby4GFic+yDeM3YswQRkDAW46b2+8pvRyvNcXdnTnyT
	 JZcqR1x8hvqGG5TReyaFo+b2RaEJK0s86sfGQ1IXCkqSlLVpbd0iFGEP2UMPOBONg5
	 KxwPG6y4xsdLg==
Date: Wed, 15 Jan 2025 13:36:01 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Bernhard Kaindl <bernhard.kaindl@cloud.com>
cc: xen-devel@lists.xenproject.org, 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
    Ross Lagerwall <ross.lagerwall@citrix.com>, 
    Andrew Cooper <andrew.cooper3@citrix.com>, 
    Anthony PERARD <anthony.perard@vates.tech>, 
    Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>, 
    Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH] docs/misc: Fix a few typos
In-Reply-To: <5ab7cdad0c275dc2de900568ae3105be60f32db5.1736953714.git.bernhard.kaindl@cloud.com>
Message-ID: <alpine.DEB.2.22.394.2501151335550.2684657@ubuntu-linux-20-04-desktop>
References: <5ab7cdad0c275dc2de900568ae3105be60f32db5.1736953714.git.bernhard.kaindl@cloud.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Wed, 15 Jan 2025, Bernhard Kaindl wrote:
> While skimming through the misc docs, I spotted a few typos.
> 
> Signed-off-by: Bernhard Kaindl <bernhard.kaindl@cloud.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>



From xen-devel-bounces@lists.xenproject.org Wed Jan 15 21:37:50 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 21:37:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873127.1284106 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYB5B-0002I3-9e; Wed, 15 Jan 2025 21:37:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873127.1284106; Wed, 15 Jan 2025 21:37:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYB5B-0002Hw-79; Wed, 15 Jan 2025 21:37:49 +0000
Received: by outflank-mailman (input) for mailman id 873127;
 Wed, 15 Jan 2025 21:37:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=9vXr=UH=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tYB59-0002Hm-UE
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 21:37:47 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f4da79c4-d388-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 22:37:45 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id CFFE35C5822;
 Wed, 15 Jan 2025 21:37:03 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 18924C4CED1;
 Wed, 15 Jan 2025 21:37:42 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f4da79c4-d388-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1736977064;
	bh=h6T6n/hRBdp/pmqQFy+2ZowVL/nO6QdHGjI01JApREk=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=l0KLZxlHfi3s/oe2zWCF94jvD6Fd+sGRIYD2r8DMub5ruohoWigbTGJom68iqodIp
	 RDim/0brHpfh9EU338yu3TrKus5U2dOl0XQ/2XhSof461o7bTe2KMI+wDUd+EWQUBy
	 2f7o3QH1fLBYQ4R5XeE8ay42ljZ3G+YN4JBQ5O1nUKjUWlyWmiOeIqwQzYyE4lkgNI
	 /pTNofdcAMEe+Ahr35ipp3RMl+qdkd9ZQY1NAM55tElFlQlkPf5nSZEyG7cmR5RWa4
	 ihxXkRxCq7RmgypOWA2Ec5VK4Mg0RQ7feKIHGjAxgACOhTKFu3mmgqt9ONCh3qlqI1
	 q26ibWFYJaEcw==
Date: Wed, 15 Jan 2025 13:37:41 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Bernhard Kaindl <bernhard.kaindl@cloud.com>
cc: xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, 
    Anthony PERARD <anthony.perard@vates.tech>, 
    Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>, 
    Julien Grall <julien@xen.org>, 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
    Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH] docs: Fix spaces and capitalisation of proper nouns and
 abbreviations
In-Reply-To: <cf18d0a24e393191ec243bb67aecfd7631429576.1736959522.git.bernhard.kaindl@cloud.com>
Message-ID: <alpine.DEB.2.22.394.2501151336460.2684657@ubuntu-linux-20-04-desktop>
References: <cf18d0a24e393191ec243bb67aecfd7631429576.1736959522.git.bernhard.kaindl@cloud.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Wed, 15 Jan 2025, Bernhard Kaindl wrote:
> Signed-off-by: Bernhard Kaindl <bernhard.kaindl@cloud.com>
> ---
>  SUPPORT.md                       | 18 +++++++++---------
>  docs/designs/qemu-deprivilege.md |  2 +-
>  2 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/SUPPORT.md b/SUPPORT.md
> index 2bc5bd81ee..9478b70b1b 100644
> --- a/SUPPORT.md
> +++ b/SUPPORT.md
> @@ -258,7 +258,7 @@ Go (golang) bindings for libxl
>  
>  ### Linux device model stubdomains
>  
> -Support for running qemu-xen device model in a linux stubdomain.
> +Support for running the qemu-xen device model in a Linux stubdomain.
>  
>      Status: Tech Preview
>  
> @@ -626,7 +626,7 @@ Guest-side driver capable of speaking the Xen 9pfs protocol
>  
>  ### PVCalls (frontend)
>  
> -Guest-side driver capable of making pv system calls
> +Guest-side driver capable of making PV system calls
>  
>      Status, Linux: Tech Preview
>  
> @@ -1060,8 +1060,8 @@ This file contains prose, and machine-readable fragments.
>  The data in a machine-readable fragment relate to
>  the section and subsection in which it is found.
>  
> -The file is in markdown format.
> -The machine-readable fragments are markdown literals
> +The file is in Markdown format.
> +The machine-readable fragments are Markdown literals
>  containing RFC-822-like (deb822-like) data.
>  
>  In each case, descriptions which expand on the name of a feature as
> @@ -1125,7 +1125,7 @@ in such a case this feature may be described as "Stable / Interface not stable".
>  
>  Does it behave like a fully functional feature?
>  Does it work on all expected platforms,
> -or does it only work for a very specific sub-case?
> +or does it only work for a very specific subcase?
>  Does it have a sensible UI,
>  or do you have to have a deep understanding of the internals
>  to get it to work properly?
> @@ -1168,7 +1168,7 @@ will they still work when I upgrade to the next version?
>  
>    * **Stable**
>  
> -    We will try very hard to avoid breaking backwards  compatibility,
> +    We will try very hard to avoid breaking backwards compatibility,
>      and to fix any regressions that are reported.
>  
>  ### Security supported
> @@ -1200,7 +1200,7 @@ are given the following labels:
>    * **Supported, Security support external**
>  
>      This feature is security supported
> -    by a different organization (not the XenProject).
> +    by a different organization (not the Xen Project).
>      The extent of support is defined by that organization.
>      It might be limited, e.g. like described in **Supported, with caveats**
>      below.
> @@ -1221,8 +1221,8 @@ Some features are only for HVM guests; some don't work with migration, &c.
>  
>  ### External security support
>  
> -The XenProject security team
> -provides security support for XenProject projects.
> +The Xen Project security team
> +provides security support for the various projects of the Xen Project.

We called sub-projects, I am not sure with or without the dash:

provides security support for the various sub-projects part of the Xen Project.


>  We also provide security support for Xen-related code in Linux,
>  which is an external project but doesn't have its own security process.
> diff --git a/docs/designs/qemu-deprivilege.md b/docs/designs/qemu-deprivilege.md
> index 603491f24d..3be33adf6a 100644
> --- a/docs/designs/qemu-deprivilege.md
> +++ b/docs/designs/qemu-deprivilege.md
> @@ -297,7 +297,7 @@ namespaces):
>      unshare(CLONE_NEWNET);
>  
>  QEMU does actually use the network namespace as a Xen DM for two
> -purposes: 1) To set up network tap devices 2) To open vnc connections.
> +purposes: 1) To set up network tap devices 2) To open VNC connections.
>  
>  #### Network
>  
> -- 
> 2.43.0
> 


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 21:38:43 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 21:38:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873138.1284118 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYB63-0002t1-MM; Wed, 15 Jan 2025 21:38:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873138.1284118; Wed, 15 Jan 2025 21:38:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYB63-0002su-IB; Wed, 15 Jan 2025 21:38:43 +0000
Received: by outflank-mailman (input) for mailman id 873138;
 Wed, 15 Jan 2025 21:38:42 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=9vXr=UH=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tYB62-0002Hm-1E
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 21:38:42 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org
 [2604:1380:45d1:ec00::3])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 158ae7a2-d389-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 22:38:40 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 41C49A424EE;
 Wed, 15 Jan 2025 21:36:51 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id D995CC4CED1;
 Wed, 15 Jan 2025 21:38:37 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 158ae7a2-d389-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1736977119;
	bh=gIV+iYssSHhdqs1CVtSAqPvQ3+jmqt5x0b6ibhD9PFg=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=u+FJpHGs26C+NGToMI4AIhkOlEVhikJmPQuHlZuAWWYuglac/azss4OXQ3K1cjMcT
	 VGnZYxkCe/4LMftTuUWkb0rCxWFZSMtK4u7RPDFFW+5J8pepwlPUqVn+t6aUgbKoni
	 4JY5Lazisswhy5tTI1/klPoVwBDfMdEggP9+v0yKEwMr4OqbwZgn3nTHivGC18Sg3q
	 cqzSue1J9wiv4ZSGcNoijWl5skwYK0zhgIOfq5yh1XsEOxwc/NbB5BCqkrO2PsKEDX
	 mvFNxTUK+MrFQHAz6q3bneaGSadayszVhd12KLxVlhVtTyuNszlAhDx2d/CoulgU+F
	 lgZScnn/KXWjA==
Date: Wed, 15 Jan 2025 13:38:36 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Bernhard Kaindl <bernhard.kaindl@cloud.com>
cc: xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, 
    Anthony PERARD <anthony.perard@vates.tech>, 
    Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>, 
    Julien Grall <julien@xen.org>, 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
    Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH] docs: Punctuation: Add missing commas after linking
 adverbs as intros
In-Reply-To: <ad9d1d7db8d43c82a02f64b8a317d7ae6522dd62.1736964253.git.bernhard.kaindl@cloud.com>
Message-ID: <alpine.DEB.2.22.394.2501151338300.2684657@ubuntu-linux-20-04-desktop>
References: <ad9d1d7db8d43c82a02f64b8a317d7ae6522dd62.1736964253.git.bernhard.kaindl@cloud.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Wed, 15 Jan 2025, Bernhard Kaindl wrote:
> Fix missing commas after linking adverbs such as currently, fortunately,
> hence, instead, and thus, when used as linking adverbs at the beginning
> of sentences. I saw them with LTeX; other checkers have this rule too.
> 
> Signed-off-by: Bernhard Kaindl <bernhard.kaindl@cloud.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 21:42:41 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 21:42:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873148.1284127 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYB9o-0004mN-3O; Wed, 15 Jan 2025 21:42:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873148.1284127; Wed, 15 Jan 2025 21:42:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYB9o-0004mG-0T; Wed, 15 Jan 2025 21:42:36 +0000
Received: by outflank-mailman (input) for mailman id 873148;
 Wed, 15 Jan 2025 21:42:35 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=9vXr=UH=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tYB9n-0004mA-7A
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 21:42:35 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a06a4db4-d389-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 22:42:33 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 5B3F7A4259C;
 Wed, 15 Jan 2025 21:40:44 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 00249C4CED1;
 Wed, 15 Jan 2025 21:42:30 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a06a4db4-d389-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1736977352;
	bh=Nk2mXVaQ1JVNfZEWArSFIIuKPAJ+ylEmBweqLgrdQ1w=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=JiRu1jTzg1v7MssrwcFbGgfgR8f893pMaOlZNWRpNjVvLjyGqGKER/dmUAPclCb0R
	 7Mo8c6HgwbVd7VaHqX+FSTFdfgqzg4ghGk4m1mO6FmIQoBaLWN34jOErMZEJmayApq
	 dEQDGkSNUHYSVKHmiOgbGXMqxL89wRf1oMTzUBtHaQ2C0e6m8t6SO7777t+8RbdmGz
	 cKrWoeFBo7TjOllZQGerxoYVltlrC2Kl77cweGf3ASWF4OCx7piZtMxX6gOhH+voC6
	 pFCekeAM/BY8yJ0kglWUxiSzdiRYdO+5ilCYPOhOwJyB91hqC8rYiQiQ1K8h9l3b7s
	 8oluk6yawwb2Q==
Date: Wed, 15 Jan 2025 13:42:29 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Mykyta Poturai <Mykyta_Poturai@epam.com>
cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, 
    Oleksandr Andrushchenko <Oleksandr_Andrushchenko@epam.com>, 
    Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, 
    Bertrand Marquis <bertrand.marquis@arm.com>, 
    Michal Orzel <michal.orzel@amd.com>, 
    Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: Re: [PATCH v3 1/2] ARM: ITS: implement quirks and add support for
 Renesas Gen4 ITS
In-Reply-To: <f165108869cc485ff45fbe870005040c23e83b6c.1736931052.git.mykyta_poturai@epam.com>
Message-ID: <alpine.DEB.2.22.394.2501151342200.2684657@ubuntu-linux-20-04-desktop>
References: <cover.1736931052.git.mykyta_poturai@epam.com> <f165108869cc485ff45fbe870005040c23e83b6c.1736931052.git.mykyta_poturai@epam.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Wed, 15 Jan 2025, Mykyta Poturai wrote:
> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> 
> There are number of ITS implementations exist which are different from
> the base one which have number of functionalities defined as is
> "IMPLEMENTATION DEFINED", e.g. there may exist differences in cacheability,
> shareability and memory requirements and others. This requires
> appropriate handling of such HW requirements which are implemented as
> ITS quirks: GITS_IIDR (ITS Implementer Identification Register) is used to
> differentiate the ITS implementations and select appropriate set of
> quirks if any.
> 
> As an example of such ITSes add quirk implementation for Renesas Gen4 ITS:
> - add possibility to override default cacheability and shareability
> settings used for ITS memory allocations;
> - change relevant memory allocations to alloc_xenheap_pages which allows
> to specify memory access flags, free_xenheap_pages is used to free;
> - add quirks validation to ensure that all ITSes share the same quirks
> in case of multiple ITSes are present in the system;
> 
> The Gen4 ITS memory requirements are not covered in any errata as of yet,
> but observed behavior suggests that they are indeed required.
> 
> The idea of the quirk implementation is inspired by the Linux kernel ITS
> quirk implementation [1].
> 
> Changelog:
> v2 -> v3:
> - added missing memset;
> v1 -> v2:
> - switched to using alloc_xenheap_pages/free_xenheap_pages for ITS memory
> allocations;
> - updated declaration of its_quirk_flags;
> - added quirks validation to ensure that all ITSes share the same quirks;
> - removed unnecessary vITS changes;
> 
> 
> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
> 
> [1] https://elixir.bootlin.com/linux/v5.16.1/source/drivers/irqchip/irq-gic-v3-its.c

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>



From xen-devel-bounces@lists.xenproject.org Wed Jan 15 21:46:58 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 21:46:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873157.1284137 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYBE0-0005M3-Jl; Wed, 15 Jan 2025 21:46:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873157.1284137; Wed, 15 Jan 2025 21:46:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYBE0-0005Lw-Gd; Wed, 15 Jan 2025 21:46:56 +0000
Received: by outflank-mailman (input) for mailman id 873157;
 Wed, 15 Jan 2025 21:46:55 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=hmQ5=UH=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tYBDz-0005Lq-9W
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 21:46:55 +0000
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com
 [2a00:1450:4864:20::32e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3b777ab1-d38a-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 22:46:53 +0100 (CET)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-4363ae65100so1786015e9.0
 for <xen-devel@lists.xenproject.org>; Wed, 15 Jan 2025 13:46:53 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-437c74c5b2esm36275995e9.23.2025.01.15.13.46.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 15 Jan 2025 13:46:52 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 3b777ab1-d38a-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1736977612; x=1737582412; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=DDdtenWdSdK6ENY5ykURKTlyyLw2SFSAn8y2xee8074=;
        b=gJ4LDmR+BWhz/+M6Dq72gSCEJqNuxZhf5kWzUOR2NKXdbYHhk+7syT92hxSCkdVxH1
         tm05WMWq+Hd03yh2SH1Qh8ooGnvEXbKM/4N6zgAW74gSPeduBwhvgZ69YfNWP5Za7sXM
         3XgBuR1fbexpk4TXo/nMyuxQ8GIwjyL69V5jE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736977612; x=1737582412;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=DDdtenWdSdK6ENY5ykURKTlyyLw2SFSAn8y2xee8074=;
        b=RvsqXt2OSnZN0PLCuLR+4QlADIvHlHPmPZc8APsUzGdYzRnH0eLfF2DX04EcLhZGEn
         vxzVYpbtERy7Z6MYLATtul2u5ZlkjUGWn00MvLiPsTg8IfziQIWS8+N+EdoqjR/Z0RZW
         7B/w9vYYuskJuT/Hpk7P5z5uMzhP6G1jTrZWoeFhysan/ENk9OeCUhrDVvkmR1AA5Alp
         CQoIgTZ3sH3KZQfKHNRbTLzbuQhg0FivwHMvlYLU/BvF/f/TVFRJ9fOXzUgcPU1xM5uP
         BPJ8fZde/XZW9jb/giWjFGndW+LDZQT6vLg3SRh00FPda1lc3I7IYU457OrjZ1EJtE3/
         B9SQ==
X-Forwarded-Encrypted: i=1; AJvYcCVPit4lA3POkVEw1Gm+60cDdODZu7aA5p5606c/AznE6y5Tqh60kp8AgWk1NBpieRcxhqd5+nQPVTM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwpBwcnvewZXxeT7MoHkFNDTw/q5GreNSfHXc0iHC7Kdm3M1eSz
	2RPY/Fo0+Xtt5DgRRAKKmVFXgJdQRYmGepAFRWiMa5Gh3INb/+PWnSFNxuwrPgs=
X-Gm-Gg: ASbGncsNIEvzQjr9wn/xfYwgNWdlu8/Sksj9Eh9ZGLwXQG1LZxSfXUXa7O0By+9w+2k
	RWMkwC0KOnmDJTHgHY0vaEstRC7JcwYbB6KXzT5sB779RSYf3D7CW5DObGCTz4d0qu07Z3MsK7p
	khVhPbvM8Z06VoPQ4WfkIuDwCkKjK6kchhsyOhHP6CY++R6pYB4deULG9aVPEzxEVB9ibwAf9zt
	QqzyOkbUwY3vXP25hQ6EA6YCLOjXooywsl8tA23wD/ok/K0iptUti8aQjN+IX0jiNgvtApN1SkZ
	00aVmHAPS6Y7cAOxJEyV
X-Google-Smtp-Source: AGHT+IHs2+H09qffluvc90VJ3c5lBwGcNqLK7wWHRr99T7ni1+ngRSHanPWVWXuEOsDirWCMBTV0vA==
X-Received: by 2002:a05:600c:4f47:b0:431:542d:2599 with SMTP id 5b1f17b1804b1-436e26e1f6dmr266533645e9.22.1736977612441;
        Wed, 15 Jan 2025 13:46:52 -0800 (PST)
Message-ID: <7c8a06bf-8558-4f14-9298-95e803cc674a@citrix.com>
Date: Wed, 15 Jan 2025 21:46:51 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] Manual pages: Fix a few typos
To: Bernhard Kaindl <bernhard.kaindl@cloud.com>,
 xen-devel@lists.xenproject.org
Cc: Anthony PERARD <anthony.perard@vates.tech>
References: <3093091e43220a0e6f698f7b3f5dafc5eba2d021.1736949423.git.bernhard.kaindl@cloud.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <3093091e43220a0e6f698f7b3f5dafc5eba2d021.1736949423.git.bernhard.kaindl@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15/01/2025 1:57 pm, Bernhard Kaindl wrote:
> While skimming through the manual pages, I spotted a few typos.
>
> Signed-off-by: Bernhard Kaindl <bernhard.kaindl@cloud.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>


From xen-devel-bounces@lists.xenproject.org Wed Jan 15 22:39:40 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Jan 2025 22:39:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873173.1284147 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYC2n-0004Zx-FX; Wed, 15 Jan 2025 22:39:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873173.1284147; Wed, 15 Jan 2025 22:39:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYC2n-0004Zq-BW; Wed, 15 Jan 2025 22:39:25 +0000
Received: by outflank-mailman (input) for mailman id 873173;
 Wed, 15 Jan 2025 22:39:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=ppZO=UH=amd.com=Jason.Andryuk@srs-se1.protection.inumbo.net>)
 id 1tYC2l-0004Zk-KT
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 22:39:23 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20619.outbound.protection.outlook.com
 [2a01:111:f403:2413::619])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8f456c6f-d391-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 23:39:21 +0100 (CET)
Received: from DM6PR11CA0054.namprd11.prod.outlook.com (2603:10b6:5:14c::31)
 by DM4PR12MB6397.namprd12.prod.outlook.com (2603:10b6:8:b4::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8335.18; Wed, 15 Jan
 2025 22:39:17 +0000
Received: from DS1PEPF00017099.namprd05.prod.outlook.com
 (2603:10b6:5:14c:cafe::50) by DM6PR11CA0054.outlook.office365.com
 (2603:10b6:5:14c::31) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8356.13 via Frontend Transport; Wed,
 15 Jan 2025 22:39:17 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 DS1PEPF00017099.mail.protection.outlook.com (10.167.18.103) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8356.11 via Frontend Transport; Wed, 15 Jan 2025 22:39:16 +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.39; Wed, 15 Jan
 2025 16:39:16 -0600
Received: from [172.27.3.102] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Wed, 15 Jan 2025 16:39:15 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8f456c6f-d391-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=M4KC35UOV7Yz71w8Rkohp2rhCHRH+ERCdutMsqT0ukp6b7dJ8jYqLVLWbCauAdjlYiymlKGdENe9YNHoApIiXYbFU7J3Tf7m5gGCB7sxXt3F+gNJU3ABccl43Ypi1uTAGDh2ExpYpFlHk7ZkkNTpbqpAqt5korZi1EwVSxOm+ukryDo4tNUGmA7jCDvzKkX+8UuCKCu9Dv1KpRKQwvj+KKh9tOsFKyHnGlMOffY3HzPe2i08hPeuYlKa5QxrAjsH107vyrkhnFKzsrDKX0uZOkjSVC55FY6iLPVJAzcRigw5nMKyH9lZiIbuZJhA4h5zTbZnNBxGOQO51Ie250cWAA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=Qyh+kwTWXZitFLG254D8m7l/ECF0ZTZ2RmGeERoGQNU=;
 b=Q3lr4oGEORtD3sDU5c/rJS6Ny1+1Q+OrBNlR2Zq3TOwoSTyNQ9a+zpRKLey37Zc1b9LDwOBgneUyzw68Z2ORMxYmcLThyy3mV1UwcnYy9zlQ4NuapxxtN76FpMCY032o2CUStk/Lz65jBeDnfOEY51wE11IiQr4hAMZgxI7+p5QTLM4jQrvzGSKsht7j/TO33OzjXA715/yCR4hgfrvupuM8d98+btobjtLMofiKbJPKBnsqKOMjDeEle5zVyiG5usu9i+WJjX12G71XvnLfoAwCOzm8Cx7i5jtKDXzi8W2BerNAjfwQNoVK6/K+veoEdXXmymJfLk4WMGB77zFg+w==
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=Qyh+kwTWXZitFLG254D8m7l/ECF0ZTZ2RmGeERoGQNU=;
 b=JLLKkDSi0XHyGulaeS+Goinfuht73EvjaZ6x0pX6wOtQB+KFKTTY+Ap/D3wQw5LjJ/FLGco+GysjtKAIlWTuuXMgQixKI/Q++C9CXFk+++Nn861AOcfGQ8Ol4aJeD6SCiQvzJAEZy/RJRNW+a9qn+T5Ox3HkjZdmr8sMP9gFtnw=
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: <8e7bca41-46cd-4143-90cb-d3361e865522@amd.com>
Date: Wed, 15 Jan 2025 17:39:15 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/4] xen/cppc: get xen-required cppc perf caps data
To: Penny Zheng <Penny.Zheng@amd.com>, Juergen Gross <jgross@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>, Oleksandr Tyshchenko
	<oleksandr_tyshchenko@epam.com>
CC: Ray Huang <Ray.Huang@amd.com>, Xenia Ragiadakou
	<Xenia.Ragiadakou@amd.com>, <xen-devel@lists.xenproject.org>,
	<linux-kernel@vger.kernel.org>
References: <20241205054252.471761-1-Penny.Zheng@amd.com>
 <20241205054252.471761-4-Penny.Zheng@amd.com>
Content-Language: en-US
From: Jason Andryuk <jason.andryuk@amd.com>
In-Reply-To: <20241205054252.471761-4-Penny.Zheng@amd.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB03.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS1PEPF00017099:EE_|DM4PR12MB6397:EE_
X-MS-Office365-Filtering-Correlation-Id: 57e0772b-d94f-4b5a-32ca-08dd35b571c5
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|82310400026|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?RkV4R0FuVzQvQUxROGVqc0FmemFFMVBaZkU5d2lHNDBZR2l4SGZ6NG5LNUw1?=
 =?utf-8?B?QmJWaTNpUEZiZFVWclMrUHJueU1tZnQ1T1lUa3A0Zm9aNngyYlQ2dElVY1k1?=
 =?utf-8?B?RmlPZExkQ2VwUjFqQi9hK3VaSHlzUHlxUzV4all0WG11eFhZV2NiZi8rN2RK?=
 =?utf-8?B?K0ZuNGJxeWlRS3JPdVIxeitQNmgweUZvVEdiNkdPU1pJdGlkaU1FYkpwY0Zq?=
 =?utf-8?B?TCsyVjZOeUZQZ0I4V2R5d1lPdVBsMDdtT1FEak5iK09zZldydDhDU2NYUTlB?=
 =?utf-8?B?NHV6MzlIbHdxVk9ZMFFPWnJ0TWJLb2c3Q05KK010dmJybnJiRU1QTXlzd1N0?=
 =?utf-8?B?NFpjSDZ3RVhCK3p1SDBvVlh4TEE5SEVyZ2g1L2E5SndnanY1TUJSc0FhdzZk?=
 =?utf-8?B?OFNLdGtCdGJQUGhzUms5SVVldUtyN2owSlI2L2ZRU1JkYThPMUZvakhzejkw?=
 =?utf-8?B?cXJhSHE2eDVWNDFCWWxwbkZ6ZUQvdVVJTlpPZ1BHbFVqMzRpbFlHb1JVNzJE?=
 =?utf-8?B?UktEV1NSelk1bEVQYk03cTZGUkF3a0c5WjdPOEt1aEFhOEI5MFQyZXdhSGsv?=
 =?utf-8?B?ekJSTklKRngrbERZMXFIc3pnQVpoUGoyeFdOQW5jWmtqemtsc0lPTitKeXFr?=
 =?utf-8?B?YnlXZTc0cm9hZm1FMEllanVMKy9hSHVXVnhXbkEybzdLKzlHbWllQWlUemUr?=
 =?utf-8?B?a0JoZUpPNHhTVHZQWTc1cDZaTG5XRllPc2c5ZE9ONUV6UHo0QzdDVVFBd3hl?=
 =?utf-8?B?WmdORFZ2SDJ6QnB2ei9qZysrNnRJYTJKbDFHTE1HNUxaZkwxOXlraTVwd2Rr?=
 =?utf-8?B?akk2bHpFcGd5OHBGaTBTbDB0V3duN0hGUlVjOWx3TmJMTWVKalFGNzNYV3Vi?=
 =?utf-8?B?bzdjQ0h6VlR3UnR0OTlRL2I1dGNvZ00rSnI2a0s4TmNVMmZVbzZVa1p5Ymx5?=
 =?utf-8?B?UjVXMFo4eFBJS0ZpU1I0aXc4KzY0OW1wVndLUUtFRzZQdTVtVnNEQXo3UXE3?=
 =?utf-8?B?elY3dTlrZnl0eGtnYzFqZXZVSjNwQXdldjFDc21Nd3l1LytlMm1TT3h2d05s?=
 =?utf-8?B?aWlwK2hEblRuODZNT2taMDJTOHd5K2JULytqQS9JdjJ1UnlSM25ycWZ2Q1pj?=
 =?utf-8?B?Smh6Z091UUplb0FaUnp1TEh4VjNRRmJ2N2NwVjdSSE43QS9GVzhaT2dVdXMx?=
 =?utf-8?B?L3dVL2xnRHZjUm1SSnFyTXREWWJ0YjZLbkZaN25lNDJCQnZVVW83a3dFY2xn?=
 =?utf-8?B?bTVYd1RycG9GY2ZyRk0rdmpiTkY0NDg0bGJBR3RVWTlxNXQ2cjdOMHJsY2w4?=
 =?utf-8?B?WjNNMC9UKytnTHNuWDdneCtVOXFENG5TRDFneUFQRGUxL2ZzRzVUbmdHc0M0?=
 =?utf-8?B?Sk9LRTR3OXMyc2tyZ3VQK1o0NTFyNlNHV3piWU5hV0ZVRWQxMzVCa0Z1WC9p?=
 =?utf-8?B?ZlpLTExEcXpDK1QwYkNWeW1ITmN1TjJGVU80WG95TVkwTWlXQUZUcWhKRExq?=
 =?utf-8?B?ZXlaYVhycmNUUFViZFd5LzJ0NjE2dWZWc0tUUFUxMDVjZVJ1N0VxajdnT3RZ?=
 =?utf-8?B?SnVXRXg3Znk1NkFOL3NicytTR0xJY1AxTjU3RTdDQTdudWxkYTBQY0dzUjRu?=
 =?utf-8?B?eU9hbFNtbVFtZDk3R3pQZmFEQ2ZXR3pzMW5XSWF1cXVic0hXNWdZZC85VU02?=
 =?utf-8?B?RkJINHQ1TFRQNjRzcHBHUzBON2ErdmxFTlNvMlBMZVd1Q3NERzlJV0VRZS9a?=
 =?utf-8?B?Wkd2dlBTUCswZHY0cXFEcUNyOEhZU3gzRUN1SnpKQVRBUXNlTWkxdXZocDdI?=
 =?utf-8?B?aGtvNlF5NnBhY1FDTzIyMG5zc0hwdlNkdG1OaXQyVHpSSFYycEdQQUtDOFVR?=
 =?utf-8?B?a2pvWUtTVTJvZ3Jma05BUE1MbUtvRkl4ejVuOFl2d0FqTFNtemEreFJhaG1m?=
 =?utf-8?B?YTBLY25waVBxTFhwaFovV3ZMQTRCQkpxTEJCQXNMRThxazM0ODdOSkJsUXZ6?=
 =?utf-8?Q?/AgoIIFEZYVCAIrAoujTfrCLON/oBA=3D?=
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:(13230040)(36860700013)(82310400026)(1800799024)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2025 22:39:16.9486
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 57e0772b-d94f-4b5a-32ca-08dd35b571c5
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:
	DS1PEPF00017099.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6397

Hi Penny,

On 2024-12-05 00:42, Penny Zheng wrote:

> diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
> index 13d6ff84a1e9..3a436591da07 100644
> --- a/drivers/acpi/cppc_acpi.c
> +++ b/drivers/acpi/cppc_acpi.c

> +	if (!high || !low || !nom || !min_nonlinear)
> +		pr_warn("CPPC: read zero cpc register value for Xen Processor %d"
> +			"highest_reg: %llu, lowest_reg: %llu"
> +			"nominal_reg: %llu, lowest_non_linear_reg: %llu\n",

The string lacks separation before highest and nominal and the preceding 
number.  Also, I think it could probably be consolidated to:

pr_warn("zero register for Xen CPU %d highest: %llu"
         " lowest: %llu nominal: %llu, non_linear: %llu\n,

pr_fmt is already "ACPI CPPC: ", and "_reg" doesn't add much value.

Regards,
Jason



From xen-devel-bounces@lists.xenproject.org Thu Jan 16 05:58:40 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 05:58:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873100.1284157 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYItX-0007OF-Jm; Thu, 16 Jan 2025 05:58:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873100.1284157; Thu, 16 Jan 2025 05:58:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYItX-0007O7-E1; Thu, 16 Jan 2025 05:58:19 +0000
Received: by outflank-mailman (input) for mailman id 873100;
 Wed, 15 Jan 2025 20:30:29 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=0fHg=UH=redhat.com=bodonnel@srs-se1.protection.inumbo.net>)
 id 1tYA20-00015j-Np
 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2025 20:30:29 +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 8c7bbf1f-d37f-11ef-99a4-01e77a169b0f;
 Wed, 15 Jan 2025 21:30:25 +0100 (CET)
Received: from mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-637-Z6SPIm02MSKKYG6SPwRX3g-1; Wed,
 15 Jan 2025 15:30:20 -0500
Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 5A4991955DC8; Wed, 15 Jan 2025 20:30:13 +0000 (UTC)
Received: from redhat.com (unknown [10.22.89.185])
 by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id C2F09195608A; Wed, 15 Jan 2025 20:30:02 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8c7bbf1f-d37f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1736973024;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=D+jmT165dsLbbDGyFZRdHkP5avOBczmV2tO5rd78/5A=;
	b=fQaHPofFP+LjAv054wKydKfbFQ66GJk2UG/vUhtOkX/4Fzx4a/TPCxqwCQ1spKWfk7RuQ1
	rK+qFgavJlSVswSnsRJvSExb0sKMONU0Xcmct2bsVsooUc+59rTocfa7gJhUdlKv/kOg+q
	7dZb1eLMIgcjmFmS3ByhANKApulbmns=
X-MC-Unique: Z6SPIm02MSKKYG6SPwRX3g-1
X-Mimecast-MFC-AGG-ID: Z6SPIm02MSKKYG6SPwRX3g
Date: Wed, 15 Jan 2025 14:30:00 -0600
From: Bill O'Donnell <bodonnel@redhat.com>
To: Joel Granados <joel.granados@kernel.org>
Cc: Thomas =?iso-8859-1?Q?Wei=DFschuh?= <linux@weissschuh.net>,
	Kees Cook <kees@kernel.org>, Luis Chamberlain <mcgrof@kernel.org>,
	linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,
	linux-s390@vger.kernel.org, linux-crypto@vger.kernel.org,
	openipmi-developer@lists.sourceforge.net,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	intel-xe@lists.freedesktop.org, linux-hyperv@vger.kernel.org,
	linux-rdma@vger.kernel.org, linux-raid@vger.kernel.org,
	linux-scsi@vger.kernel.org, linux-serial@vger.kernel.org,
	xen-devel@lists.xenproject.org, linux-aio@kvack.org,
	linux-fsdevel@vger.kernel.org, netfs@lists.linux.dev,
	codalist@coda.cs.cmu.edu, linux-mm@kvack.org,
	linux-nfs@vger.kernel.org, ocfs2-devel@lists.linux.dev,
	fsverity@lists.linux.dev, linux-xfs@vger.kernel.org,
	io-uring@vger.kernel.org, bpf@vger.kernel.org,
	kexec@lists.infradead.org, linux-trace-kernel@vger.kernel.org,
	linux-hardening@vger.kernel.org, apparmor@lists.ubuntu.com,
	linux-security-module@vger.kernel.org, keyrings@vger.kernel.org,
	Song Liu <song@kernel.org>,
	"Steven Rostedt (Google)" <rostedt@goodmis.org>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	"Darrick J. Wong" <djwong@kernel.org>,
	Jani Nikula <jani.nikula@intel.com>,
	Corey Minyard <cminyard@mvista.com>
Subject: Re: [PATCH v2] treewide: const qualify ctl_tables where applicable
Message-ID: <Z4gayPSrRIWYKgCn@redhat.com>
References: <20250110-jag-ctl_table_const-v2-1-0000e1663144@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250110-jag-ctl_table_const-v2-1-0000e1663144@kernel.org>
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15

On Fri, Jan 10, 2025 at 03:16:08PM +0100, Joel Granados wrote:
> Add the const qualifier to all the ctl_tables in the tree except for
> watchdog_hardlockup_sysctl, memory_allocation_profiling_sysctls,
> loadpin_sysctl_table and the ones calling register_net_sysctl (./net,
> drivers/inifiniband dirs). These are special cases as they use a
> registration function with a non-const qualified ctl_table argument or
> modify the arrays before passing them on to the registration function.
> 
> Constifying ctl_table structs will prevent the modification of
> proc_handler function pointers as the arrays would reside in .rodata.
> This is made possible after commit 78eb4ea25cd5 ("sysctl: treewide:
> constify the ctl_table argument of proc_handlers") constified all the
> proc_handlers.
> 
> Created this by running an spatch followed by a sed command:
> Spatch:
>     virtual patch
> 
>     @
>     depends on !(file in "net")
>     disable optional_qualifier
>     @
>     identifier table_name != {watchdog_hardlockup_sysctl,iwcm_ctl_table,ucma_ctl_table,memory_allocation_profiling_sysctls,loadpin_sysctl_table};
>     @@
> 
>     + const
>     struct ctl_table table_name [] = { ... };
> 
> sed:
>     sed --in-place \
>       -e "s/struct ctl_table .table = &uts_kern/const struct ctl_table *table = \&uts_kern/" \
>       kernel/utsname_sysctl.c
> 
> Reviewed-by: Song Liu <song@kernel.org>
> Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org> # for kernel/trace/
> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> # SCSI
> Reviewed-by: Darrick J. Wong <djwong@kernel.org> # xfs
> Acked-by: Jani Nikula <jani.nikula@intel.com>
> Acked-by: Corey Minyard <cminyard@mvista.com>
> Signed-off-by: Joel Granados <joel.granados@kernel.org>
> ---

For xfs bits...
Reviewed-by: Bill O'Donnell <bodonnel@redhat.com>


> This treewide commit builds upon the work Thomas began a few releases
> ago [1], where he laid the groundwork for constifying ctl_tables. We
> implement constification throughout the tree, with the exception of the
> ctl_tables in the "net" directory. Those are special in that they treat
> the ctl_table as non-const but we can take them at a later point.
> 
> Upstreaming:
> ===========
> It is late in the release cycle, but I'm hopeful that we can get this
> in for the upcoming merge window and this is why:
> 1. We don't use linux-next: As with previous treewide changes similar to
>    this one [1], we avoid using linux-next in order to avoid unwanted
>    merge conflicts
> 2. This is a non-functional change: which lowers the probability of
>    unforeseen errors or regressions.
> 3. It will have at least 2 weeks to be tested/reviewed: The PULL should
>    be sent at the end of the merge window, giving it at least 2 weeks.
>    And if there are more release candidates after rc6, there will be
>    more time.
> 
> Testing:
> ========
> 1. Currently being tested in 0-day
> 2. sysctl self-tests/kunit-tests
> 
> Reduced To/Cc:
> ==============
> b4 originally gave me 200 ppl that this should go out to (which seems a
> bit overkill from my point of view). So I left the mailing lists and
> reduced the To: the ppl previously involved in the effort and sysctl
> maintainers. Please tell me if I missed someone important to the
> constification effort.
> 
> Comments are greatly appreciated.
> 
> Changes in v2:
> - watchdog_hardlockup_sysctl, memory_allocation_profiling_sysctls,
>   loadpin_sysctl_table, iwcm_ctl_table and ucma_ctl_table where removed
>   from patchset as they change the sysctl array before registration.
> - Added reviewed-by tags
> - Link to v1: https://lore.kernel.org/r/20250109-jag-ctl_table_const-v1-1-622aea7230cf@kernel.org
> Best
> 
> [1] https://lore.kernel.org/20240724210014.mc6nima6cekgiukx@joelS2.panther.com
> 
> --
> ---
> 
> ---
>  arch/arm/kernel/isa.c                         | 2 +-
>  arch/arm64/kernel/fpsimd.c                    | 4 ++--
>  arch/arm64/kernel/process.c                   | 2 +-
>  arch/powerpc/kernel/idle.c                    | 2 +-
>  arch/powerpc/platforms/pseries/mobility.c     | 2 +-
>  arch/riscv/kernel/process.c                   | 2 +-
>  arch/riscv/kernel/vector.c                    | 2 +-
>  arch/s390/appldata/appldata_base.c            | 2 +-
>  arch/s390/kernel/debug.c                      | 2 +-
>  arch/s390/kernel/hiperdispatch.c              | 2 +-
>  arch/s390/kernel/topology.c                   | 2 +-
>  arch/s390/mm/cmm.c                            | 2 +-
>  arch/s390/mm/pgalloc.c                        | 2 +-
>  arch/x86/entry/vdso/vdso32-setup.c            | 2 +-
>  arch/x86/kernel/cpu/bus_lock.c                | 2 +-
>  arch/x86/kernel/itmt.c                        | 2 +-
>  crypto/fips.c                                 | 2 +-
>  drivers/base/firmware_loader/fallback_table.c | 2 +-
>  drivers/cdrom/cdrom.c                         | 2 +-
>  drivers/char/hpet.c                           | 2 +-
>  drivers/char/ipmi/ipmi_poweroff.c             | 2 +-
>  drivers/char/random.c                         | 2 +-
>  drivers/gpu/drm/i915/i915_perf.c              | 2 +-
>  drivers/gpu/drm/xe/xe_observation.c           | 2 +-
>  drivers/hv/hv_common.c                        | 2 +-
>  drivers/macintosh/mac_hid.c                   | 2 +-
>  drivers/md/md.c                               | 2 +-
>  drivers/misc/sgi-xp/xpc_main.c                | 4 ++--
>  drivers/perf/arm_pmuv3.c                      | 2 +-
>  drivers/perf/riscv_pmu_sbi.c                  | 2 +-
>  drivers/scsi/scsi_sysctl.c                    | 2 +-
>  drivers/scsi/sg.c                             | 2 +-
>  drivers/tty/tty_io.c                          | 2 +-
>  drivers/xen/balloon.c                         | 2 +-
>  fs/aio.c                                      | 2 +-
>  fs/cachefiles/error_inject.c                  | 2 +-
>  fs/coda/sysctl.c                              | 2 +-
>  fs/coredump.c                                 | 2 +-
>  fs/dcache.c                                   | 2 +-
>  fs/devpts/inode.c                             | 2 +-
>  fs/eventpoll.c                                | 2 +-
>  fs/exec.c                                     | 2 +-
>  fs/file_table.c                               | 2 +-
>  fs/fuse/sysctl.c                              | 2 +-
>  fs/inode.c                                    | 2 +-
>  fs/lockd/svc.c                                | 2 +-
>  fs/locks.c                                    | 2 +-
>  fs/namei.c                                    | 2 +-
>  fs/namespace.c                                | 2 +-
>  fs/nfs/nfs4sysctl.c                           | 2 +-
>  fs/nfs/sysctl.c                               | 2 +-
>  fs/notify/dnotify/dnotify.c                   | 2 +-
>  fs/notify/fanotify/fanotify_user.c            | 2 +-
>  fs/notify/inotify/inotify_user.c              | 2 +-
>  fs/ocfs2/stackglue.c                          | 2 +-
>  fs/pipe.c                                     | 2 +-
>  fs/quota/dquot.c                              | 2 +-
>  fs/sysctls.c                                  | 2 +-
>  fs/userfaultfd.c                              | 2 +-
>  fs/verity/init.c                              | 2 +-
>  fs/xfs/xfs_sysctl.c                           | 2 +-
>  init/do_mounts_initrd.c                       | 2 +-
>  io_uring/io_uring.c                           | 2 +-
>  ipc/ipc_sysctl.c                              | 2 +-
>  ipc/mq_sysctl.c                               | 2 +-
>  kernel/acct.c                                 | 2 +-
>  kernel/bpf/syscall.c                          | 2 +-
>  kernel/delayacct.c                            | 2 +-
>  kernel/exit.c                                 | 2 +-
>  kernel/hung_task.c                            | 2 +-
>  kernel/kexec_core.c                           | 2 +-
>  kernel/kprobes.c                              | 2 +-
>  kernel/latencytop.c                           | 2 +-
>  kernel/locking/lockdep.c                      | 2 +-
>  kernel/panic.c                                | 2 +-
>  kernel/pid_namespace.c                        | 2 +-
>  kernel/pid_sysctl.h                           | 2 +-
>  kernel/printk/sysctl.c                        | 2 +-
>  kernel/reboot.c                               | 2 +-
>  kernel/sched/autogroup.c                      | 2 +-
>  kernel/sched/core.c                           | 2 +-
>  kernel/sched/deadline.c                       | 2 +-
>  kernel/sched/fair.c                           | 2 +-
>  kernel/sched/rt.c                             | 2 +-
>  kernel/sched/topology.c                       | 2 +-
>  kernel/seccomp.c                              | 2 +-
>  kernel/signal.c                               | 2 +-
>  kernel/stackleak.c                            | 2 +-
>  kernel/sysctl-test.c                          | 6 +++---
>  kernel/sysctl.c                               | 4 ++--
>  kernel/time/timer.c                           | 2 +-
>  kernel/trace/ftrace.c                         | 2 +-
>  kernel/trace/trace_events_user.c              | 2 +-
>  kernel/umh.c                                  | 2 +-
>  kernel/utsname_sysctl.c                       | 4 ++--
>  kernel/watchdog.c                             | 2 +-
>  lib/test_sysctl.c                             | 6 +++---
>  mm/compaction.c                               | 2 +-
>  mm/hugetlb.c                                  | 2 +-
>  mm/hugetlb_vmemmap.c                          | 2 +-
>  mm/memory-failure.c                           | 2 +-
>  mm/oom_kill.c                                 | 2 +-
>  mm/page-writeback.c                           | 2 +-
>  mm/page_alloc.c                               | 2 +-
>  security/apparmor/lsm.c                       | 2 +-
>  security/keys/sysctl.c                        | 2 +-
>  security/yama/yama_lsm.c                      | 2 +-
>  107 files changed, 115 insertions(+), 115 deletions(-)
> 
> diff --git a/arch/arm/kernel/isa.c b/arch/arm/kernel/isa.c
> index 905b1b191546..db8be609fab2 100644
> --- a/arch/arm/kernel/isa.c
> +++ b/arch/arm/kernel/isa.c
> @@ -16,7 +16,7 @@
>  
>  static unsigned int isa_membase, isa_portbase, isa_portshift;
>  
> -static struct ctl_table ctl_isa_vars[] = {
> +static const struct ctl_table ctl_isa_vars[] = {
>  	{
>  		.procname	= "membase",
>  		.data		= &isa_membase, 
> diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> index 8c4c1a2186cc..2b601d88762d 100644
> --- a/arch/arm64/kernel/fpsimd.c
> +++ b/arch/arm64/kernel/fpsimd.c
> @@ -562,7 +562,7 @@ static int vec_proc_do_default_vl(const struct ctl_table *table, int write,
>  	return 0;
>  }
>  
> -static struct ctl_table sve_default_vl_table[] = {
> +static const struct ctl_table sve_default_vl_table[] = {
>  	{
>  		.procname	= "sve_default_vector_length",
>  		.mode		= 0644,
> @@ -585,7 +585,7 @@ static int __init sve_sysctl_init(void) { return 0; }
>  #endif /* ! (CONFIG_ARM64_SVE && CONFIG_SYSCTL) */
>  
>  #if defined(CONFIG_ARM64_SME) && defined(CONFIG_SYSCTL)
> -static struct ctl_table sme_default_vl_table[] = {
> +static const struct ctl_table sme_default_vl_table[] = {
>  	{
>  		.procname	= "sme_default_vector_length",
>  		.mode		= 0644,
> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> index 2968a33bb3bc..42faebb7b712 100644
> --- a/arch/arm64/kernel/process.c
> +++ b/arch/arm64/kernel/process.c
> @@ -859,7 +859,7 @@ long get_tagged_addr_ctrl(struct task_struct *task)
>   * disable it for tasks that already opted in to the relaxed ABI.
>   */
>  
> -static struct ctl_table tagged_addr_sysctl_table[] = {
> +static const struct ctl_table tagged_addr_sysctl_table[] = {
>  	{
>  		.procname	= "tagged_addr_disabled",
>  		.mode		= 0644,
> diff --git a/arch/powerpc/kernel/idle.c b/arch/powerpc/kernel/idle.c
> index 30b56c67fa61..e527cd3ef128 100644
> --- a/arch/powerpc/kernel/idle.c
> +++ b/arch/powerpc/kernel/idle.c
> @@ -97,7 +97,7 @@ void power4_idle(void)
>  /*
>   * Register the sysctl to set/clear powersave_nap.
>   */
> -static struct ctl_table powersave_nap_ctl_table[] = {
> +static const struct ctl_table powersave_nap_ctl_table[] = {
>  	{
>  		.procname	= "powersave-nap",
>  		.data		= &powersave_nap,
> diff --git a/arch/powerpc/platforms/pseries/mobility.c b/arch/powerpc/platforms/pseries/mobility.c
> index 1798f0f14d58..62bd8e2d5d4c 100644
> --- a/arch/powerpc/platforms/pseries/mobility.c
> +++ b/arch/powerpc/platforms/pseries/mobility.c
> @@ -53,7 +53,7 @@ struct update_props_workarea {
>  static unsigned int nmi_wd_lpm_factor = 200;
>  
>  #ifdef CONFIG_SYSCTL
> -static struct ctl_table nmi_wd_lpm_factor_ctl_table[] = {
> +static const struct ctl_table nmi_wd_lpm_factor_ctl_table[] = {
>  	{
>  		.procname	= "nmi_wd_lpm_factor",
>  		.data		= &nmi_wd_lpm_factor,
> diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c
> index 58b6482c2bf6..7891294abf49 100644
> --- a/arch/riscv/kernel/process.c
> +++ b/arch/riscv/kernel/process.c
> @@ -364,7 +364,7 @@ static bool try_to_set_pmm(unsigned long value)
>   * disable it for tasks that already opted in to the relaxed ABI.
>   */
>  
> -static struct ctl_table tagged_addr_sysctl_table[] = {
> +static const struct ctl_table tagged_addr_sysctl_table[] = {
>  	{
>  		.procname	= "tagged_addr_disabled",
>  		.mode		= 0644,
> diff --git a/arch/riscv/kernel/vector.c b/arch/riscv/kernel/vector.c
> index 821818886fab..d022b028ac3f 100644
> --- a/arch/riscv/kernel/vector.c
> +++ b/arch/riscv/kernel/vector.c
> @@ -287,7 +287,7 @@ long riscv_v_vstate_ctrl_set_current(unsigned long arg)
>  
>  #ifdef CONFIG_SYSCTL
>  
> -static struct ctl_table riscv_v_default_vstate_table[] = {
> +static const struct ctl_table riscv_v_default_vstate_table[] = {
>  	{
>  		.procname	= "riscv_v_default_allow",
>  		.data		= &riscv_v_implicit_uacc,
> diff --git a/arch/s390/appldata/appldata_base.c b/arch/s390/appldata/appldata_base.c
> index 91a30e017d65..dd7ba7587dd5 100644
> --- a/arch/s390/appldata/appldata_base.c
> +++ b/arch/s390/appldata/appldata_base.c
> @@ -52,7 +52,7 @@ static int appldata_interval_handler(const struct ctl_table *ctl, int write,
>  				     void *buffer, size_t *lenp, loff_t *ppos);
>  
>  static struct ctl_table_header *appldata_sysctl_header;
> -static struct ctl_table appldata_table[] = {
> +static const struct ctl_table appldata_table[] = {
>  	{
>  		.procname	= "timer",
>  		.mode		= S_IRUGO | S_IWUSR,
> diff --git a/arch/s390/kernel/debug.c b/arch/s390/kernel/debug.c
> index de19fd8a6a95..2c245c2bce4f 100644
> --- a/arch/s390/kernel/debug.c
> +++ b/arch/s390/kernel/debug.c
> @@ -972,7 +972,7 @@ static int s390dbf_procactive(const struct ctl_table *table, int write,
>  		return 0;
>  }
>  
> -static struct ctl_table s390dbf_table[] = {
> +static const struct ctl_table s390dbf_table[] = {
>  	{
>  		.procname	= "debug_stoppable",
>  		.data		= &debug_stoppable,
> diff --git a/arch/s390/kernel/hiperdispatch.c b/arch/s390/kernel/hiperdispatch.c
> index 2a99a216ab62..7857a7e8e56c 100644
> --- a/arch/s390/kernel/hiperdispatch.c
> +++ b/arch/s390/kernel/hiperdispatch.c
> @@ -292,7 +292,7 @@ static int hiperdispatch_ctl_handler(const struct ctl_table *ctl, int write,
>  	return 0;
>  }
>  
> -static struct ctl_table hiperdispatch_ctl_table[] = {
> +static const struct ctl_table hiperdispatch_ctl_table[] = {
>  	{
>  		.procname	= "hiperdispatch",
>  		.mode		= 0644,
> diff --git a/arch/s390/kernel/topology.c b/arch/s390/kernel/topology.c
> index 4f9c301a705b..5067293ef69d 100644
> --- a/arch/s390/kernel/topology.c
> +++ b/arch/s390/kernel/topology.c
> @@ -662,7 +662,7 @@ static int polarization_ctl_handler(const struct ctl_table *ctl, int write,
>  	return set_polarization(polarization);
>  }
>  
> -static struct ctl_table topology_ctl_table[] = {
> +static const struct ctl_table topology_ctl_table[] = {
>  	{
>  		.procname	= "topology",
>  		.mode		= 0644,
> diff --git a/arch/s390/mm/cmm.c b/arch/s390/mm/cmm.c
> index d01724a715d0..939e3bec2db7 100644
> --- a/arch/s390/mm/cmm.c
> +++ b/arch/s390/mm/cmm.c
> @@ -332,7 +332,7 @@ static int cmm_timeout_handler(const struct ctl_table *ctl, int write,
>  	return 0;
>  }
>  
> -static struct ctl_table cmm_table[] = {
> +static const struct ctl_table cmm_table[] = {
>  	{
>  		.procname	= "cmm_pages",
>  		.mode		= 0644,
> diff --git a/arch/s390/mm/pgalloc.c b/arch/s390/mm/pgalloc.c
> index 58696a0c4e4a..18d3176e44fb 100644
> --- a/arch/s390/mm/pgalloc.c
> +++ b/arch/s390/mm/pgalloc.c
> @@ -21,7 +21,7 @@
>  int page_table_allocate_pgste = 0;
>  EXPORT_SYMBOL(page_table_allocate_pgste);
>  
> -static struct ctl_table page_table_sysctl[] = {
> +static const struct ctl_table page_table_sysctl[] = {
>  	{
>  		.procname	= "allocate_pgste",
>  		.data		= &page_table_allocate_pgste,
> diff --git a/arch/x86/entry/vdso/vdso32-setup.c b/arch/x86/entry/vdso/vdso32-setup.c
> index 76e4e74f35b5..f6d2d8aba643 100644
> --- a/arch/x86/entry/vdso/vdso32-setup.c
> +++ b/arch/x86/entry/vdso/vdso32-setup.c
> @@ -57,7 +57,7 @@ __setup_param("vdso=", vdso_setup, vdso32_setup, 0);
>  /* Register vsyscall32 into the ABI table */
>  #include <linux/sysctl.h>
>  
> -static struct ctl_table abi_table2[] = {
> +static const struct ctl_table abi_table2[] = {
>  	{
>  		.procname	= "vsyscall32",
>  		.data		= &vdso32_enabled,
> diff --git a/arch/x86/kernel/cpu/bus_lock.c b/arch/x86/kernel/cpu/bus_lock.c
> index 704e9241b964..6cba85c79d42 100644
> --- a/arch/x86/kernel/cpu/bus_lock.c
> +++ b/arch/x86/kernel/cpu/bus_lock.c
> @@ -49,7 +49,7 @@ static unsigned int sysctl_sld_mitigate = 1;
>  static DEFINE_SEMAPHORE(buslock_sem, 1);
>  
>  #ifdef CONFIG_PROC_SYSCTL
> -static struct ctl_table sld_sysctls[] = {
> +static const struct ctl_table sld_sysctls[] = {
>  	{
>  		.procname       = "split_lock_mitigate",
>  		.data           = &sysctl_sld_mitigate,
> diff --git a/arch/x86/kernel/itmt.c b/arch/x86/kernel/itmt.c
> index 51b805c727fc..083d8c4deb2b 100644
> --- a/arch/x86/kernel/itmt.c
> +++ b/arch/x86/kernel/itmt.c
> @@ -64,7 +64,7 @@ static int sched_itmt_update_handler(const struct ctl_table *table, int write,
>  	return ret;
>  }
>  
> -static struct ctl_table itmt_kern_table[] = {
> +static const struct ctl_table itmt_kern_table[] = {
>  	{
>  		.procname	= "sched_itmt_enabled",
>  		.data		= &sysctl_sched_itmt_enabled,
> diff --git a/crypto/fips.c b/crypto/fips.c
> index 8a784018ebfc..ec6574596e59 100644
> --- a/crypto/fips.c
> +++ b/crypto/fips.c
> @@ -41,7 +41,7 @@ __setup("fips=", fips_enable);
>  static char fips_name[] = FIPS_MODULE_NAME;
>  static char fips_version[] = FIPS_MODULE_VERSION;
>  
> -static struct ctl_table crypto_sysctl_table[] = {
> +static const struct ctl_table crypto_sysctl_table[] = {
>  	{
>  		.procname	= "fips_enabled",
>  		.data		= &fips_enabled,
> diff --git a/drivers/base/firmware_loader/fallback_table.c b/drivers/base/firmware_loader/fallback_table.c
> index ddb70e29eb42..c8afc501a8a4 100644
> --- a/drivers/base/firmware_loader/fallback_table.c
> +++ b/drivers/base/firmware_loader/fallback_table.c
> @@ -25,7 +25,7 @@ struct firmware_fallback_config fw_fallback_config = {
>  EXPORT_SYMBOL_NS_GPL(fw_fallback_config, "FIRMWARE_LOADER_PRIVATE");
>  
>  #ifdef CONFIG_SYSCTL
> -static struct ctl_table firmware_config_table[] = {
> +static const struct ctl_table firmware_config_table[] = {
>  	{
>  		.procname	= "force_sysfs_fallback",
>  		.data		= &fw_fallback_config.force_sysfs_fallback,
> diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
> index 51745ed1bbab..b163e043c687 100644
> --- a/drivers/cdrom/cdrom.c
> +++ b/drivers/cdrom/cdrom.c
> @@ -3612,7 +3612,7 @@ static int cdrom_sysctl_handler(const struct ctl_table *ctl, int write,
>  }
>  
>  /* Place files in /proc/sys/dev/cdrom */
> -static struct ctl_table cdrom_table[] = {
> +static const struct ctl_table cdrom_table[] = {
>  	{
>  		.procname	= "info",
>  		.data		= &cdrom_sysctl_settings.info, 
> diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c
> index 48fe96ab4649..e110857824fc 100644
> --- a/drivers/char/hpet.c
> +++ b/drivers/char/hpet.c
> @@ -724,7 +724,7 @@ static int hpet_is_known(struct hpet_data *hdp)
>  	return 0;
>  }
>  
> -static struct ctl_table hpet_table[] = {
> +static const struct ctl_table hpet_table[] = {
>  	{
>  	 .procname = "max-user-freq",
>  	 .data = &hpet_max_freq,
> diff --git a/drivers/char/ipmi/ipmi_poweroff.c b/drivers/char/ipmi/ipmi_poweroff.c
> index 941d2dcc8c9d..de84f59468a9 100644
> --- a/drivers/char/ipmi/ipmi_poweroff.c
> +++ b/drivers/char/ipmi/ipmi_poweroff.c
> @@ -650,7 +650,7 @@ static struct ipmi_smi_watcher smi_watcher = {
>  #ifdef CONFIG_PROC_FS
>  #include <linux/sysctl.h>
>  
> -static struct ctl_table ipmi_table[] = {
> +static const struct ctl_table ipmi_table[] = {
>  	{ .procname	= "poweroff_powercycle",
>  	  .data		= &poweroff_powercycle,
>  	  .maxlen	= sizeof(poweroff_powercycle),
> diff --git a/drivers/char/random.c b/drivers/char/random.c
> index 23ee76bbb4aa..2581186fa61b 100644
> --- a/drivers/char/random.c
> +++ b/drivers/char/random.c
> @@ -1665,7 +1665,7 @@ static int proc_do_rointvec(const struct ctl_table *table, int write, void *buf,
>  	return write ? 0 : proc_dointvec(table, 0, buf, lenp, ppos);
>  }
>  
> -static struct ctl_table random_table[] = {
> +static const struct ctl_table random_table[] = {
>  	{
>  		.procname	= "poolsize",
>  		.data		= &sysctl_poolsize,
> diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
> index 2406cda75b7b..5384d1bb4923 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -4802,7 +4802,7 @@ int i915_perf_remove_config_ioctl(struct drm_device *dev, void *data,
>  	return ret;
>  }
>  
> -static struct ctl_table oa_table[] = {
> +static const struct ctl_table oa_table[] = {
>  	{
>  	 .procname = "perf_stream_paranoid",
>  	 .data = &i915_perf_stream_paranoid,
> diff --git a/drivers/gpu/drm/xe/xe_observation.c b/drivers/gpu/drm/xe/xe_observation.c
> index 8ec1b84cbb9e..57cf01efc07f 100644
> --- a/drivers/gpu/drm/xe/xe_observation.c
> +++ b/drivers/gpu/drm/xe/xe_observation.c
> @@ -56,7 +56,7 @@ int xe_observation_ioctl(struct drm_device *dev, void *data, struct drm_file *fi
>  	}
>  }
>  
> -static struct ctl_table observation_ctl_table[] = {
> +static const struct ctl_table observation_ctl_table[] = {
>  	{
>  	 .procname = "observation_paranoid",
>  	 .data = &xe_observation_paranoid,
> diff --git a/drivers/hv/hv_common.c b/drivers/hv/hv_common.c
> index 7a35c82976e0..9453f0c26f2a 100644
> --- a/drivers/hv/hv_common.c
> +++ b/drivers/hv/hv_common.c
> @@ -141,7 +141,7 @@ static int sysctl_record_panic_msg = 1;
>   * sysctl option to allow the user to control whether kmsg data should be
>   * reported to Hyper-V on panic.
>   */
> -static struct ctl_table hv_ctl_table[] = {
> +static const struct ctl_table hv_ctl_table[] = {
>  	{
>  		.procname	= "hyperv_record_panic_msg",
>  		.data		= &sysctl_record_panic_msg,
> diff --git a/drivers/macintosh/mac_hid.c b/drivers/macintosh/mac_hid.c
> index b461b1bed25b..369d72f59b3c 100644
> --- a/drivers/macintosh/mac_hid.c
> +++ b/drivers/macintosh/mac_hid.c
> @@ -215,7 +215,7 @@ static int mac_hid_toggle_emumouse(const struct ctl_table *table, int write,
>  }
>  
>  /* file(s) in /proc/sys/dev/mac_hid */
> -static struct ctl_table mac_hid_files[] = {
> +static const struct ctl_table mac_hid_files[] = {
>  	{
>  		.procname	= "mouse_button_emulation",
>  		.data		= &mouse_emulate_buttons,
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index aebe12b0ee27..0e06f9027d81 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -294,7 +294,7 @@ void mddev_destroy_serial_pool(struct mddev *mddev, struct md_rdev *rdev)
>  
>  static struct ctl_table_header *raid_table_header;
>  
> -static struct ctl_table raid_table[] = {
> +static const struct ctl_table raid_table[] = {
>  	{
>  		.procname	= "speed_limit_min",
>  		.data		= &sysctl_speed_limit_min,
> diff --git a/drivers/misc/sgi-xp/xpc_main.c b/drivers/misc/sgi-xp/xpc_main.c
> index 61b66e318488..7a3c34306de9 100644
> --- a/drivers/misc/sgi-xp/xpc_main.c
> +++ b/drivers/misc/sgi-xp/xpc_main.c
> @@ -93,7 +93,7 @@ int xpc_disengage_timelimit = XPC_DISENGAGE_DEFAULT_TIMELIMIT;
>  static int xpc_disengage_min_timelimit;	/* = 0 */
>  static int xpc_disengage_max_timelimit = 120;
>  
> -static struct ctl_table xpc_sys_xpc_hb[] = {
> +static const struct ctl_table xpc_sys_xpc_hb[] = {
>  	{
>  	 .procname = "hb_interval",
>  	 .data = &xpc_hb_interval,
> @@ -111,7 +111,7 @@ static struct ctl_table xpc_sys_xpc_hb[] = {
>  	 .extra1 = &xpc_hb_check_min_interval,
>  	 .extra2 = &xpc_hb_check_max_interval},
>  };
> -static struct ctl_table xpc_sys_xpc[] = {
> +static const struct ctl_table xpc_sys_xpc[] = {
>  	{
>  	 .procname = "disengage_timelimit",
>  	 .data = &xpc_disengage_timelimit,
> diff --git a/drivers/perf/arm_pmuv3.c b/drivers/perf/arm_pmuv3.c
> index b5cc11abc962..0e360feb3432 100644
> --- a/drivers/perf/arm_pmuv3.c
> +++ b/drivers/perf/arm_pmuv3.c
> @@ -1279,7 +1279,7 @@ static int armv8pmu_proc_user_access_handler(const struct ctl_table *table, int
>  	return 0;
>  }
>  
> -static struct ctl_table armv8_pmu_sysctl_table[] = {
> +static const struct ctl_table armv8_pmu_sysctl_table[] = {
>  	{
>  		.procname       = "perf_user_access",
>  		.data		= &sysctl_perf_user_access,
> diff --git a/drivers/perf/riscv_pmu_sbi.c b/drivers/perf/riscv_pmu_sbi.c
> index 1aa303f76cc7..ea96c0a88f73 100644
> --- a/drivers/perf/riscv_pmu_sbi.c
> +++ b/drivers/perf/riscv_pmu_sbi.c
> @@ -1315,7 +1315,7 @@ static int riscv_pmu_proc_user_access_handler(const struct ctl_table *table,
>  	return 0;
>  }
>  
> -static struct ctl_table sbi_pmu_sysctl_table[] = {
> +static const struct ctl_table sbi_pmu_sysctl_table[] = {
>  	{
>  		.procname       = "perf_user_access",
>  		.data		= &sysctl_perf_user_access,
> diff --git a/drivers/scsi/scsi_sysctl.c b/drivers/scsi/scsi_sysctl.c
> index 093774d77534..be4aef0f4f99 100644
> --- a/drivers/scsi/scsi_sysctl.c
> +++ b/drivers/scsi/scsi_sysctl.c
> @@ -12,7 +12,7 @@
>  #include "scsi_priv.h"
>  
>  
> -static struct ctl_table scsi_table[] = {
> +static const struct ctl_table scsi_table[] = {
>  	{ .procname	= "logging_level",
>  	  .data		= &scsi_logging_level,
>  	  .maxlen	= sizeof(scsi_logging_level),
> diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
> index 94127868bedf..effb7e768165 100644
> --- a/drivers/scsi/sg.c
> +++ b/drivers/scsi/sg.c
> @@ -1639,7 +1639,7 @@ MODULE_PARM_DESC(allow_dio, "allow direct I/O (default: 0 (disallow))");
>  #ifdef CONFIG_SYSCTL
>  #include <linux/sysctl.h>
>  
> -static struct ctl_table sg_sysctls[] = {
> +static const struct ctl_table sg_sysctls[] = {
>  	{
>  		.procname	= "sg-big-buff",
>  		.data		= &sg_big_buff,
> diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
> index dcb1769c3625..0e84677712b4 100644
> --- a/drivers/tty/tty_io.c
> +++ b/drivers/tty/tty_io.c
> @@ -3618,7 +3618,7 @@ void console_sysfs_notify(void)
>  		sysfs_notify(&consdev->kobj, NULL, "active");
>  }
>  
> -static struct ctl_table tty_table[] = {
> +static const struct ctl_table tty_table[] = {
>  	{
>  		.procname	= "legacy_tiocsti",
>  		.data		= &tty_legacy_tiocsti,
> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> index 528395133b4f..163f7f1d70f1 100644
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -84,7 +84,7 @@ module_param(balloon_boot_timeout, uint, 0444);
>  #ifdef CONFIG_XEN_BALLOON_MEMORY_HOTPLUG
>  static int xen_hotplug_unpopulated;
>  
> -static struct ctl_table balloon_table[] = {
> +static const struct ctl_table balloon_table[] = {
>  	{
>  		.procname	= "hotplug_unpopulated",
>  		.data		= &xen_hotplug_unpopulated,
> diff --git a/fs/aio.c b/fs/aio.c
> index 50671640b588..7b976b564cfc 100644
> --- a/fs/aio.c
> +++ b/fs/aio.c
> @@ -224,7 +224,7 @@ static unsigned long aio_nr;		/* current system wide number of aio requests */
>  static unsigned long aio_max_nr = 0x10000; /* system wide maximum number of aio requests */
>  /*----end sysctl variables---*/
>  #ifdef CONFIG_SYSCTL
> -static struct ctl_table aio_sysctls[] = {
> +static const struct ctl_table aio_sysctls[] = {
>  	{
>  		.procname	= "aio-nr",
>  		.data		= &aio_nr,
> diff --git a/fs/cachefiles/error_inject.c b/fs/cachefiles/error_inject.c
> index 1715d5ca2b2d..e341ade47dd8 100644
> --- a/fs/cachefiles/error_inject.c
> +++ b/fs/cachefiles/error_inject.c
> @@ -11,7 +11,7 @@
>  unsigned int cachefiles_error_injection_state;
>  
>  static struct ctl_table_header *cachefiles_sysctl;
> -static struct ctl_table cachefiles_sysctls[] = {
> +static const struct ctl_table cachefiles_sysctls[] = {
>  	{
>  		.procname	= "error_injection",
>  		.data		= &cachefiles_error_injection_state,
> diff --git a/fs/coda/sysctl.c b/fs/coda/sysctl.c
> index 9f2d5743e2c8..0df46f09b6cc 100644
> --- a/fs/coda/sysctl.c
> +++ b/fs/coda/sysctl.c
> @@ -14,7 +14,7 @@
>  
>  static struct ctl_table_header *fs_table_header;
>  
> -static struct ctl_table coda_table[] = {
> +static const struct ctl_table coda_table[] = {
>  	{
>  		.procname	= "timeout",
>  		.data		= &coda_timeout,
> diff --git a/fs/coredump.c b/fs/coredump.c
> index d48edb37bc35..591700e1b2ce 100644
> --- a/fs/coredump.c
> +++ b/fs/coredump.c
> @@ -995,7 +995,7 @@ static int proc_dostring_coredump(const struct ctl_table *table, int write,
>  static const unsigned int core_file_note_size_min = CORE_FILE_NOTE_SIZE_DEFAULT;
>  static const unsigned int core_file_note_size_max = CORE_FILE_NOTE_SIZE_MAX;
>  
> -static struct ctl_table coredump_sysctls[] = {
> +static const struct ctl_table coredump_sysctls[] = {
>  	{
>  		.procname	= "core_uses_pid",
>  		.data		= &core_uses_pid,
> diff --git a/fs/dcache.c b/fs/dcache.c
> index b4d5e9e1e43d..370302d4e488 100644
> --- a/fs/dcache.c
> +++ b/fs/dcache.c
> @@ -192,7 +192,7 @@ static int proc_nr_dentry(const struct ctl_table *table, int write, void *buffer
>  	return proc_doulongvec_minmax(table, write, buffer, lenp, ppos);
>  }
>  
> -static struct ctl_table fs_dcache_sysctls[] = {
> +static const struct ctl_table fs_dcache_sysctls[] = {
>  	{
>  		.procname	= "dentry-state",
>  		.data		= &dentry_stat,
> diff --git a/fs/devpts/inode.c b/fs/devpts/inode.c
> index b20e565b9c5e..1096ff8562fa 100644
> --- a/fs/devpts/inode.c
> +++ b/fs/devpts/inode.c
> @@ -45,7 +45,7 @@ static int pty_limit_min;
>  static int pty_limit_max = INT_MAX;
>  static atomic_t pty_count = ATOMIC_INIT(0);
>  
> -static struct ctl_table pty_table[] = {
> +static const struct ctl_table pty_table[] = {
>  	{
>  		.procname	= "max",
>  		.maxlen		= sizeof(int),
> diff --git a/fs/eventpoll.c b/fs/eventpoll.c
> index f9898e60dd8b..7c0980db77b3 100644
> --- a/fs/eventpoll.c
> +++ b/fs/eventpoll.c
> @@ -318,7 +318,7 @@ static void unlist_file(struct epitems_head *head)
>  static long long_zero;
>  static long long_max = LONG_MAX;
>  
> -static struct ctl_table epoll_table[] = {
> +static const struct ctl_table epoll_table[] = {
>  	{
>  		.procname	= "max_user_watches",
>  		.data		= &max_user_watches,
> diff --git a/fs/exec.c b/fs/exec.c
> index 98cb7ba9983c..96229a6a4dff 100644
> --- a/fs/exec.c
> +++ b/fs/exec.c
> @@ -2142,7 +2142,7 @@ static int proc_dointvec_minmax_coredump(const struct ctl_table *table, int writ
>  	return error;
>  }
>  
> -static struct ctl_table fs_exec_sysctls[] = {
> +static const struct ctl_table fs_exec_sysctls[] = {
>  	{
>  		.procname	= "suid_dumpable",
>  		.data		= &suid_dumpable,
> diff --git a/fs/file_table.c b/fs/file_table.c
> index 976736be47cb..70ed0b3a5a0e 100644
> --- a/fs/file_table.c
> +++ b/fs/file_table.c
> @@ -106,7 +106,7 @@ static int proc_nr_files(const struct ctl_table *table, int write, void *buffer,
>  	return proc_doulongvec_minmax(table, write, buffer, lenp, ppos);
>  }
>  
> -static struct ctl_table fs_stat_sysctls[] = {
> +static const struct ctl_table fs_stat_sysctls[] = {
>  	{
>  		.procname	= "file-nr",
>  		.data		= &files_stat,
> diff --git a/fs/fuse/sysctl.c b/fs/fuse/sysctl.c
> index b272bb333005..63fb1e5bee30 100644
> --- a/fs/fuse/sysctl.c
> +++ b/fs/fuse/sysctl.c
> @@ -13,7 +13,7 @@ static struct ctl_table_header *fuse_table_header;
>  /* Bound by fuse_init_out max_pages, which is a u16 */
>  static unsigned int sysctl_fuse_max_pages_limit = 65535;
>  
> -static struct ctl_table fuse_sysctl_table[] = {
> +static const struct ctl_table fuse_sysctl_table[] = {
>  	{
>  		.procname	= "max_pages_limit",
>  		.data		= &fuse_max_pages_limit,
> diff --git a/fs/inode.c b/fs/inode.c
> index 6b4c77268fc0..5587aabdaa5e 100644
> --- a/fs/inode.c
> +++ b/fs/inode.c
> @@ -184,7 +184,7 @@ static int proc_nr_inodes(const struct ctl_table *table, int write, void *buffer
>  	return proc_doulongvec_minmax(table, write, buffer, lenp, ppos);
>  }
>  
> -static struct ctl_table inodes_sysctls[] = {
> +static const struct ctl_table inodes_sysctls[] = {
>  	{
>  		.procname	= "inode-nr",
>  		.data		= &inodes_stat,
> diff --git a/fs/lockd/svc.c b/fs/lockd/svc.c
> index 4ec22c2f2ea3..d6cac1c89c2a 100644
> --- a/fs/lockd/svc.c
> +++ b/fs/lockd/svc.c
> @@ -419,7 +419,7 @@ EXPORT_SYMBOL_GPL(lockd_down);
>   * Sysctl parameters (same as module parameters, different interface).
>   */
>  
> -static struct ctl_table nlm_sysctls[] = {
> +static const struct ctl_table nlm_sysctls[] = {
>  	{
>  		.procname	= "nlm_grace_period",
>  		.data		= &nlm_grace_period,
> diff --git a/fs/locks.c b/fs/locks.c
> index 25afc8d9c9d1..1619cddfa7a4 100644
> --- a/fs/locks.c
> +++ b/fs/locks.c
> @@ -97,7 +97,7 @@ static int leases_enable = 1;
>  static int lease_break_time = 45;
>  
>  #ifdef CONFIG_SYSCTL
> -static struct ctl_table locks_sysctls[] = {
> +static const struct ctl_table locks_sysctls[] = {
>  	{
>  		.procname	= "leases-enable",
>  		.data		= &leases_enable,
> diff --git a/fs/namei.c b/fs/namei.c
> index 9d30c7aa9aa6..6a18b2ea21b7 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -1099,7 +1099,7 @@ static int sysctl_protected_fifos __read_mostly;
>  static int sysctl_protected_regular __read_mostly;
>  
>  #ifdef CONFIG_SYSCTL
> -static struct ctl_table namei_sysctls[] = {
> +static const struct ctl_table namei_sysctls[] = {
>  	{
>  		.procname	= "protected_symlinks",
>  		.data		= &sysctl_protected_symlinks,
> diff --git a/fs/namespace.c b/fs/namespace.c
> index 23e81c2a1e3f..3819c322244e 100644
> --- a/fs/namespace.c
> +++ b/fs/namespace.c
> @@ -5927,7 +5927,7 @@ const struct proc_ns_operations mntns_operations = {
>  };
>  
>  #ifdef CONFIG_SYSCTL
> -static struct ctl_table fs_namespace_sysctls[] = {
> +static const struct ctl_table fs_namespace_sysctls[] = {
>  	{
>  		.procname	= "mount-max",
>  		.data		= &sysctl_mount_max,
> diff --git a/fs/nfs/nfs4sysctl.c b/fs/nfs/nfs4sysctl.c
> index 886a7c4c60b3..d1a92d8f8ba4 100644
> --- a/fs/nfs/nfs4sysctl.c
> +++ b/fs/nfs/nfs4sysctl.c
> @@ -17,7 +17,7 @@ static const int nfs_set_port_min;
>  static const int nfs_set_port_max = 65535;
>  static struct ctl_table_header *nfs4_callback_sysctl_table;
>  
> -static struct ctl_table nfs4_cb_sysctls[] = {
> +static const struct ctl_table nfs4_cb_sysctls[] = {
>  	{
>  		.procname = "nfs_callback_tcpport",
>  		.data = &nfs_callback_set_tcpport,
> diff --git a/fs/nfs/sysctl.c b/fs/nfs/sysctl.c
> index e645be1a3381..f579df0e8d67 100644
> --- a/fs/nfs/sysctl.c
> +++ b/fs/nfs/sysctl.c
> @@ -14,7 +14,7 @@
>  
>  static struct ctl_table_header *nfs_callback_sysctl_table;
>  
> -static struct ctl_table nfs_cb_sysctls[] = {
> +static const struct ctl_table nfs_cb_sysctls[] = {
>  	{
>  		.procname	= "nfs_mountpoint_timeout",
>  		.data		= &nfs_mountpoint_expiry_timeout,
> diff --git a/fs/notify/dnotify/dnotify.c b/fs/notify/dnotify/dnotify.c
> index 6004dfdfdf0f..c4cdaf5fa7ed 100644
> --- a/fs/notify/dnotify/dnotify.c
> +++ b/fs/notify/dnotify/dnotify.c
> @@ -20,7 +20,7 @@
>  
>  static int dir_notify_enable __read_mostly = 1;
>  #ifdef CONFIG_SYSCTL
> -static struct ctl_table dnotify_sysctls[] = {
> +static const struct ctl_table dnotify_sysctls[] = {
>  	{
>  		.procname	= "dir-notify-enable",
>  		.data		= &dir_notify_enable,
> diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c
> index 2d85c71717d6..004cfdae1316 100644
> --- a/fs/notify/fanotify/fanotify_user.c
> +++ b/fs/notify/fanotify/fanotify_user.c
> @@ -58,7 +58,7 @@ static int fanotify_max_queued_events __read_mostly;
>  static long ft_zero = 0;
>  static long ft_int_max = INT_MAX;
>  
> -static struct ctl_table fanotify_table[] = {
> +static const struct ctl_table fanotify_table[] = {
>  	{
>  		.procname	= "max_user_groups",
>  		.data	= &init_user_ns.ucount_max[UCOUNT_FANOTIFY_GROUPS],
> diff --git a/fs/notify/inotify/inotify_user.c b/fs/notify/inotify/inotify_user.c
> index e0c48956608a..b372fb2c56bd 100644
> --- a/fs/notify/inotify/inotify_user.c
> +++ b/fs/notify/inotify/inotify_user.c
> @@ -58,7 +58,7 @@ struct kmem_cache *inotify_inode_mark_cachep __ro_after_init;
>  static long it_zero = 0;
>  static long it_int_max = INT_MAX;
>  
> -static struct ctl_table inotify_table[] = {
> +static const struct ctl_table inotify_table[] = {
>  	{
>  		.procname	= "max_user_instances",
>  		.data		= &init_user_ns.ucount_max[UCOUNT_INOTIFY_INSTANCES],
> diff --git a/fs/ocfs2/stackglue.c b/fs/ocfs2/stackglue.c
> index 20aa37b67cfb..ddd761cf44c8 100644
> --- a/fs/ocfs2/stackglue.c
> +++ b/fs/ocfs2/stackglue.c
> @@ -650,7 +650,7 @@ static int ocfs2_sysfs_init(void)
>   * and easier to preserve the name.
>   */
>  
> -static struct ctl_table ocfs2_nm_table[] = {
> +static const struct ctl_table ocfs2_nm_table[] = {
>  	{
>  		.procname	= "hb_ctl_path",
>  		.data		= ocfs2_hb_ctl_path,
> diff --git a/fs/pipe.c b/fs/pipe.c
> index 12b22c2723b7..638fb318e7be 100644
> --- a/fs/pipe.c
> +++ b/fs/pipe.c
> @@ -1477,7 +1477,7 @@ static int proc_dopipe_max_size(const struct ctl_table *table, int write,
>  				 do_proc_dopipe_max_size_conv, NULL);
>  }
>  
> -static struct ctl_table fs_pipe_sysctls[] = {
> +static const struct ctl_table fs_pipe_sysctls[] = {
>  	{
>  		.procname	= "pipe-max-size",
>  		.data		= &pipe_max_size,
> diff --git a/fs/quota/dquot.c b/fs/quota/dquot.c
> index f9578918cfb2..825c5c2e0962 100644
> --- a/fs/quota/dquot.c
> +++ b/fs/quota/dquot.c
> @@ -2926,7 +2926,7 @@ static int do_proc_dqstats(const struct ctl_table *table, int write,
>  	return proc_doulongvec_minmax(table, write, buffer, lenp, ppos);
>  }
>  
> -static struct ctl_table fs_dqstats_table[] = {
> +static const struct ctl_table fs_dqstats_table[] = {
>  	{
>  		.procname	= "lookups",
>  		.data		= &dqstats.stat[DQST_LOOKUPS],
> diff --git a/fs/sysctls.c b/fs/sysctls.c
> index 8dbde9a802fa..ad429dffeb4b 100644
> --- a/fs/sysctls.c
> +++ b/fs/sysctls.c
> @@ -7,7 +7,7 @@
>  #include <linux/init.h>
>  #include <linux/sysctl.h>
>  
> -static struct ctl_table fs_shared_sysctls[] = {
> +static const struct ctl_table fs_shared_sysctls[] = {
>  	{
>  		.procname	= "overflowuid",
>  		.data		= &fs_overflowuid,
> diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
> index 7c0bd0b55f88..97c4d71115d8 100644
> --- a/fs/userfaultfd.c
> +++ b/fs/userfaultfd.c
> @@ -36,7 +36,7 @@
>  static int sysctl_unprivileged_userfaultfd __read_mostly;
>  
>  #ifdef CONFIG_SYSCTL
> -static struct ctl_table vm_userfaultfd_table[] = {
> +static const struct ctl_table vm_userfaultfd_table[] = {
>  	{
>  		.procname	= "unprivileged_userfaultfd",
>  		.data		= &sysctl_unprivileged_userfaultfd,
> diff --git a/fs/verity/init.c b/fs/verity/init.c
> index f440f0e61e3e..6e8d33b50240 100644
> --- a/fs/verity/init.c
> +++ b/fs/verity/init.c
> @@ -10,7 +10,7 @@
>  #include <linux/ratelimit.h>
>  
>  #ifdef CONFIG_SYSCTL
> -static struct ctl_table fsverity_sysctl_table[] = {
> +static const struct ctl_table fsverity_sysctl_table[] = {
>  #ifdef CONFIG_FS_VERITY_BUILTIN_SIGNATURES
>  	{
>  		.procname       = "require_signatures",
> diff --git a/fs/xfs/xfs_sysctl.c b/fs/xfs/xfs_sysctl.c
> index c84df23b494d..751dc74a3067 100644
> --- a/fs/xfs/xfs_sysctl.c
> +++ b/fs/xfs/xfs_sysctl.c
> @@ -66,7 +66,7 @@ xfs_deprecated_dointvec_minmax(
>  	return proc_dointvec_minmax(ctl, write, buffer, lenp, ppos);
>  }
>  
> -static struct ctl_table xfs_table[] = {
> +static const struct ctl_table xfs_table[] = {
>  	{
>  		.procname	= "irix_sgid_inherit",
>  		.data		= &xfs_params.sgid_inherit.val,
> diff --git a/init/do_mounts_initrd.c b/init/do_mounts_initrd.c
> index 22c7f41ff642..903b4d573d3d 100644
> --- a/init/do_mounts_initrd.c
> +++ b/init/do_mounts_initrd.c
> @@ -21,7 +21,7 @@ phys_addr_t phys_initrd_start __initdata;
>  unsigned long phys_initrd_size __initdata;
>  
>  #ifdef CONFIG_SYSCTL
> -static struct ctl_table kern_do_mounts_initrd_table[] = {
> +static const struct ctl_table kern_do_mounts_initrd_table[] = {
>  	{
>  		.procname       = "real-root-dev",
>  		.data           = &real_root_dev,
> diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c
> index d3403c8216db..72ad31225fb3 100644
> --- a/io_uring/io_uring.c
> +++ b/io_uring/io_uring.c
> @@ -156,7 +156,7 @@ static int __read_mostly sysctl_io_uring_disabled;
>  static int __read_mostly sysctl_io_uring_group = -1;
>  
>  #ifdef CONFIG_SYSCTL
> -static struct ctl_table kernel_io_uring_disabled_table[] = {
> +static const struct ctl_table kernel_io_uring_disabled_table[] = {
>  	{
>  		.procname	= "io_uring_disabled",
>  		.data		= &sysctl_io_uring_disabled,
> diff --git a/ipc/ipc_sysctl.c b/ipc/ipc_sysctl.c
> index 54318e0b4557..15b17e86e198 100644
> --- a/ipc/ipc_sysctl.c
> +++ b/ipc/ipc_sysctl.c
> @@ -73,7 +73,7 @@ int ipc_mni = IPCMNI;
>  int ipc_mni_shift = IPCMNI_SHIFT;
>  int ipc_min_cycle = RADIX_TREE_MAP_SIZE;
>  
> -static struct ctl_table ipc_sysctls[] = {
> +static const struct ctl_table ipc_sysctls[] = {
>  	{
>  		.procname	= "shmmax",
>  		.data		= &init_ipc_ns.shm_ctlmax,
> diff --git a/ipc/mq_sysctl.c b/ipc/mq_sysctl.c
> index b70dc2ff22d8..0dd12e1c9f53 100644
> --- a/ipc/mq_sysctl.c
> +++ b/ipc/mq_sysctl.c
> @@ -20,7 +20,7 @@ static int msg_max_limit_max = HARD_MSGMAX;
>  static int msg_maxsize_limit_min = MIN_MSGSIZEMAX;
>  static int msg_maxsize_limit_max = HARD_MSGSIZEMAX;
>  
> -static struct ctl_table mq_sysctls[] = {
> +static const struct ctl_table mq_sysctls[] = {
>  	{
>  		.procname	= "queues_max",
>  		.data		= &init_ipc_ns.mq_queues_max,
> diff --git a/kernel/acct.c b/kernel/acct.c
> index 179848ad33e9..31222e8cd534 100644
> --- a/kernel/acct.c
> +++ b/kernel/acct.c
> @@ -76,7 +76,7 @@ static int acct_parm[3] = {4, 2, 30};
>  #define ACCT_TIMEOUT	(acct_parm[2])	/* foo second timeout between checks */
>  
>  #ifdef CONFIG_SYSCTL
> -static struct ctl_table kern_acct_table[] = {
> +static const struct ctl_table kern_acct_table[] = {
>  	{
>  		.procname       = "acct",
>  		.data           = &acct_parm,
> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> index 5684e8ce132d..fbcf07f98d8b 100644
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c
> @@ -6124,7 +6124,7 @@ static int bpf_unpriv_handler(const struct ctl_table *table, int write,
>  	return ret;
>  }
>  
> -static struct ctl_table bpf_syscall_table[] = {
> +static const struct ctl_table bpf_syscall_table[] = {
>  	{
>  		.procname	= "unprivileged_bpf_disabled",
>  		.data		= &sysctl_unprivileged_bpf_disabled,
> diff --git a/kernel/delayacct.c b/kernel/delayacct.c
> index dead51de8eb5..75659ac036cd 100644
> --- a/kernel/delayacct.c
> +++ b/kernel/delayacct.c
> @@ -64,7 +64,7 @@ static int sysctl_delayacct(const struct ctl_table *table, int write, void *buff
>  	return err;
>  }
>  
> -static struct ctl_table kern_delayacct_table[] = {
> +static const struct ctl_table kern_delayacct_table[] = {
>  	{
>  		.procname       = "task_delayacct",
>  		.data           = NULL,
> diff --git a/kernel/exit.c b/kernel/exit.c
> index 1dcddfe537ee..3485e5fc499e 100644
> --- a/kernel/exit.c
> +++ b/kernel/exit.c
> @@ -85,7 +85,7 @@
>  static unsigned int oops_limit = 10000;
>  
>  #ifdef CONFIG_SYSCTL
> -static struct ctl_table kern_exit_table[] = {
> +static const struct ctl_table kern_exit_table[] = {
>  	{
>  		.procname       = "oops_limit",
>  		.data           = &oops_limit,
> diff --git a/kernel/hung_task.c b/kernel/hung_task.c
> index c18717189f32..62a5d8927ce9 100644
> --- a/kernel/hung_task.c
> +++ b/kernel/hung_task.c
> @@ -272,7 +272,7 @@ static int proc_dohung_task_timeout_secs(const struct ctl_table *table, int writ
>   * and hung_task_check_interval_secs
>   */
>  static const unsigned long hung_task_timeout_max = (LONG_MAX / HZ);
> -static struct ctl_table hung_task_sysctls[] = {
> +static const struct ctl_table hung_task_sysctls[] = {
>  #ifdef CONFIG_SMP
>  	{
>  		.procname	= "hung_task_all_cpu_backtrace",
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index c0caa14880c3..71b0809e06d6 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -925,7 +925,7 @@ static int kexec_limit_handler(const struct ctl_table *table, int write,
>  	return proc_dointvec(&tmp, write, buffer, lenp, ppos);
>  }
>  
> -static struct ctl_table kexec_core_sysctls[] = {
> +static const struct ctl_table kexec_core_sysctls[] = {
>  	{
>  		.procname	= "kexec_load_disabled",
>  		.data		= &kexec_load_disabled,
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index b027a4030976..9a15fb343be8 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -954,7 +954,7 @@ static int proc_kprobes_optimization_handler(const struct ctl_table *table,
>  	return ret;
>  }
>  
> -static struct ctl_table kprobe_sysctls[] = {
> +static const struct ctl_table kprobe_sysctls[] = {
>  	{
>  		.procname	= "kprobes-optimization",
>  		.data		= &sysctl_kprobes_optimization,
> diff --git a/kernel/latencytop.c b/kernel/latencytop.c
> index 7a75eab9c179..39a5fcdff9f9 100644
> --- a/kernel/latencytop.c
> +++ b/kernel/latencytop.c
> @@ -77,7 +77,7 @@ static int sysctl_latencytop(const struct ctl_table *table, int write, void *buf
>  	return err;
>  }
>  
> -static struct ctl_table latencytop_sysctl[] = {
> +static const struct ctl_table latencytop_sysctl[] = {
>  	{
>  		.procname   = "latencytop",
>  		.data       = &latencytop_enabled,
> diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
> index 2d8ec0351ef9..926b796ba71a 100644
> --- a/kernel/locking/lockdep.c
> +++ b/kernel/locking/lockdep.c
> @@ -79,7 +79,7 @@ module_param(lock_stat, int, 0644);
>  #endif
>  
>  #ifdef CONFIG_SYSCTL
> -static struct ctl_table kern_lockdep_table[] = {
> +static const struct ctl_table kern_lockdep_table[] = {
>  #ifdef CONFIG_PROVE_LOCKING
>  	{
>  		.procname       = "prove_locking",
> diff --git a/kernel/panic.c b/kernel/panic.c
> index fbc59b3b64d0..d8635d5cecb2 100644
> --- a/kernel/panic.c
> +++ b/kernel/panic.c
> @@ -84,7 +84,7 @@ ATOMIC_NOTIFIER_HEAD(panic_notifier_list);
>  EXPORT_SYMBOL(panic_notifier_list);
>  
>  #ifdef CONFIG_SYSCTL
> -static struct ctl_table kern_panic_table[] = {
> +static const struct ctl_table kern_panic_table[] = {
>  #ifdef CONFIG_SMP
>  	{
>  		.procname       = "oops_all_cpu_backtrace",
> diff --git a/kernel/pid_namespace.c b/kernel/pid_namespace.c
> index d70ab49d5b4a..0f23285be4f9 100644
> --- a/kernel/pid_namespace.c
> +++ b/kernel/pid_namespace.c
> @@ -282,7 +282,7 @@ static int pid_ns_ctl_handler(const struct ctl_table *table, int write,
>  }
>  
>  extern int pid_max;
> -static struct ctl_table pid_ns_ctl_table[] = {
> +static const struct ctl_table pid_ns_ctl_table[] = {
>  	{
>  		.procname = "ns_last_pid",
>  		.maxlen = sizeof(int),
> diff --git a/kernel/pid_sysctl.h b/kernel/pid_sysctl.h
> index 18ecaef6be41..5d8f981de7c5 100644
> --- a/kernel/pid_sysctl.h
> +++ b/kernel/pid_sysctl.h
> @@ -31,7 +31,7 @@ static int pid_mfd_noexec_dointvec_minmax(const struct ctl_table *table,
>  	return err;
>  }
>  
> -static struct ctl_table pid_ns_ctl_table_vm[] = {
> +static const struct ctl_table pid_ns_ctl_table_vm[] = {
>  	{
>  		.procname	= "memfd_noexec",
>  		.data		= &init_pid_ns.memfd_noexec_scope,
> diff --git a/kernel/printk/sysctl.c b/kernel/printk/sysctl.c
> index f5072dc85f7a..da77f3f5c1fe 100644
> --- a/kernel/printk/sysctl.c
> +++ b/kernel/printk/sysctl.c
> @@ -20,7 +20,7 @@ static int proc_dointvec_minmax_sysadmin(const struct ctl_table *table, int writ
>  	return proc_dointvec_minmax(table, write, buffer, lenp, ppos);
>  }
>  
> -static struct ctl_table printk_sysctls[] = {
> +static const struct ctl_table printk_sysctls[] = {
>  	{
>  		.procname	= "printk",
>  		.data		= &console_loglevel,
> diff --git a/kernel/reboot.c b/kernel/reboot.c
> index a701000bab34..b5a8569e5d81 100644
> --- a/kernel/reboot.c
> +++ b/kernel/reboot.c
> @@ -1287,7 +1287,7 @@ static struct attribute *reboot_attrs[] = {
>  };
>  
>  #ifdef CONFIG_SYSCTL
> -static struct ctl_table kern_reboot_table[] = {
> +static const struct ctl_table kern_reboot_table[] = {
>  	{
>  		.procname       = "poweroff_cmd",
>  		.data           = &poweroff_cmd,
> diff --git a/kernel/sched/autogroup.c b/kernel/sched/autogroup.c
> index db68a964e34e..83d46b9b8ec8 100644
> --- a/kernel/sched/autogroup.c
> +++ b/kernel/sched/autogroup.c
> @@ -9,7 +9,7 @@ static struct autogroup autogroup_default;
>  static atomic_t autogroup_seq_nr;
>  
>  #ifdef CONFIG_SYSCTL
> -static struct ctl_table sched_autogroup_sysctls[] = {
> +static const struct ctl_table sched_autogroup_sysctls[] = {
>  	{
>  		.procname       = "sched_autogroup_enabled",
>  		.data           = &sysctl_sched_autogroup_enabled,
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 3e5a6bf587f9..00fea6f32ae5 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -4646,7 +4646,7 @@ static int sysctl_schedstats(const struct ctl_table *table, int write, void *buf
>  #endif /* CONFIG_SCHEDSTATS */
>  
>  #ifdef CONFIG_SYSCTL
> -static struct ctl_table sched_core_sysctls[] = {
> +static const struct ctl_table sched_core_sysctls[] = {
>  #ifdef CONFIG_SCHEDSTATS
>  	{
>  		.procname       = "sched_schedstats",
> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index d94f2ed6d1f4..dab4887d6406 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -26,7 +26,7 @@
>  static unsigned int sysctl_sched_dl_period_max = 1 << 22; /* ~4 seconds */
>  static unsigned int sysctl_sched_dl_period_min = 100;     /* 100 us */
>  #ifdef CONFIG_SYSCTL
> -static struct ctl_table sched_dl_sysctls[] = {
> +static const struct ctl_table sched_dl_sysctls[] = {
>  	{
>  		.procname       = "sched_deadline_period_max_us",
>  		.data           = &sysctl_sched_dl_period_max,
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 3e9ca38512de..1692dbb67d7a 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -130,7 +130,7 @@ static unsigned int sysctl_numa_balancing_promote_rate_limit = 65536;
>  #endif
>  
>  #ifdef CONFIG_SYSCTL
> -static struct ctl_table sched_fair_sysctls[] = {
> +static const struct ctl_table sched_fair_sysctls[] = {
>  #ifdef CONFIG_CFS_BANDWIDTH
>  	{
>  		.procname       = "sched_cfs_bandwidth_slice_us",
> diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
> index bd66a46b06ac..4b8e33c615b1 100644
> --- a/kernel/sched/rt.c
> +++ b/kernel/sched/rt.c
> @@ -26,7 +26,7 @@ static int sched_rt_handler(const struct ctl_table *table, int write, void *buff
>  		size_t *lenp, loff_t *ppos);
>  static int sched_rr_handler(const struct ctl_table *table, int write, void *buffer,
>  		size_t *lenp, loff_t *ppos);
> -static struct ctl_table sched_rt_sysctls[] = {
> +static const struct ctl_table sched_rt_sysctls[] = {
>  	{
>  		.procname       = "sched_rt_period_us",
>  		.data           = &sysctl_sched_rt_period,
> diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
> index 9748a4c8d668..20d59b0bc928 100644
> --- a/kernel/sched/topology.c
> +++ b/kernel/sched/topology.c
> @@ -312,7 +312,7 @@ static int sched_energy_aware_handler(const struct ctl_table *table, int write,
>  	return ret;
>  }
>  
> -static struct ctl_table sched_energy_aware_sysctls[] = {
> +static const struct ctl_table sched_energy_aware_sysctls[] = {
>  	{
>  		.procname       = "sched_energy_aware",
>  		.data           = &sysctl_sched_energy_aware,
> diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> index 385d48293a5f..f59381c4a2ff 100644
> --- a/kernel/seccomp.c
> +++ b/kernel/seccomp.c
> @@ -2450,7 +2450,7 @@ static int seccomp_actions_logged_handler(const struct ctl_table *ro_table, int
>  	return ret;
>  }
>  
> -static struct ctl_table seccomp_sysctl_table[] = {
> +static const struct ctl_table seccomp_sysctl_table[] = {
>  	{
>  		.procname	= "actions_avail",
>  		.data		= (void *) &seccomp_actions_avail,
> diff --git a/kernel/signal.c b/kernel/signal.c
> index 989b1cc9116a..77f32c2d6ccb 100644
> --- a/kernel/signal.c
> +++ b/kernel/signal.c
> @@ -4931,7 +4931,7 @@ static inline void siginfo_buildtime_checks(void)
>  }
>  
>  #if defined(CONFIG_SYSCTL)
> -static struct ctl_table signal_debug_table[] = {
> +static const struct ctl_table signal_debug_table[] = {
>  #ifdef CONFIG_SYSCTL_EXCEPTION_TRACE
>  	{
>  		.procname	= "exception-trace",
> diff --git a/kernel/stackleak.c b/kernel/stackleak.c
> index 39fd620a7db6..c1bfc14cd36e 100644
> --- a/kernel/stackleak.c
> +++ b/kernel/stackleak.c
> @@ -44,7 +44,7 @@ static int stack_erasing_sysctl(const struct ctl_table *table, int write,
>  					state ? "enabled" : "disabled");
>  	return ret;
>  }
> -static struct ctl_table stackleak_sysctls[] = {
> +static const struct ctl_table stackleak_sysctls[] = {
>  	{
>  		.procname	= "stack_erasing",
>  		.data		= NULL,
> diff --git a/kernel/sysctl-test.c b/kernel/sysctl-test.c
> index 3ac98bb7fb82..eb2842bd0557 100644
> --- a/kernel/sysctl-test.c
> +++ b/kernel/sysctl-test.c
> @@ -374,7 +374,7 @@ static void sysctl_test_register_sysctl_sz_invalid_extra_value(
>  		struct kunit *test)
>  {
>  	unsigned char data = 0;
> -	struct ctl_table table_foo[] = {
> +	const struct ctl_table table_foo[] = {
>  		{
>  			.procname	= "foo",
>  			.data		= &data,
> @@ -386,7 +386,7 @@ static void sysctl_test_register_sysctl_sz_invalid_extra_value(
>  		},
>  	};
>  
> -	struct ctl_table table_bar[] = {
> +	const struct ctl_table table_bar[] = {
>  		{
>  			.procname	= "bar",
>  			.data		= &data,
> @@ -398,7 +398,7 @@ static void sysctl_test_register_sysctl_sz_invalid_extra_value(
>  		},
>  	};
>  
> -	struct ctl_table table_qux[] = {
> +	const struct ctl_table table_qux[] = {
>  		{
>  			.procname	= "qux",
>  			.data		= &data,
> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> index 5c9202cb8f59..3a0132cb0d5d 100644
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -1609,7 +1609,7 @@ int proc_do_static_key(const struct ctl_table *table, int write,
>  	return ret;
>  }
>  
> -static struct ctl_table kern_table[] = {
> +static const struct ctl_table kern_table[] = {
>  	{
>  		.procname	= "panic",
>  		.data		= &panic_timeout,
> @@ -2030,7 +2030,7 @@ static struct ctl_table kern_table[] = {
>  #endif
>  };
>  
> -static struct ctl_table vm_table[] = {
> +static const struct ctl_table vm_table[] = {
>  	{
>  		.procname	= "overcommit_memory",
>  		.data		= &sysctl_overcommit_memory,
> diff --git a/kernel/time/timer.c b/kernel/time/timer.c
> index a5860bf6d16f..79a1f83d2944 100644
> --- a/kernel/time/timer.c
> +++ b/kernel/time/timer.c
> @@ -301,7 +301,7 @@ static int timer_migration_handler(const struct ctl_table *table, int write,
>  	return ret;
>  }
>  
> -static struct ctl_table timer_sysctl[] = {
> +static const struct ctl_table timer_sysctl[] = {
>  	{
>  		.procname	= "timer_migration",
>  		.data		= &sysctl_timer_migration,
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index 2e113f8b13a2..489cbab3d64c 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -8786,7 +8786,7 @@ ftrace_enable_sysctl(const struct ctl_table *table, int write,
>  	return ret;
>  }
>  
> -static struct ctl_table ftrace_sysctls[] = {
> +static const struct ctl_table ftrace_sysctls[] = {
>  	{
>  		.procname       = "ftrace_enabled",
>  		.data           = &ftrace_enabled,
> diff --git a/kernel/trace/trace_events_user.c b/kernel/trace/trace_events_user.c
> index 17bcad8f79de..97325fbd6283 100644
> --- a/kernel/trace/trace_events_user.c
> +++ b/kernel/trace/trace_events_user.c
> @@ -2899,7 +2899,7 @@ static int set_max_user_events_sysctl(const struct ctl_table *table, int write,
>  	return ret;
>  }
>  
> -static struct ctl_table user_event_sysctls[] = {
> +static const struct ctl_table user_event_sysctls[] = {
>  	{
>  		.procname	= "user_events_max",
>  		.data		= &max_user_events,
> diff --git a/kernel/umh.c b/kernel/umh.c
> index be9234270777..b4da45a3a7cf 100644
> --- a/kernel/umh.c
> +++ b/kernel/umh.c
> @@ -544,7 +544,7 @@ static int proc_cap_handler(const struct ctl_table *table, int write,
>  	return 0;
>  }
>  
> -static struct ctl_table usermodehelper_table[] = {
> +static const struct ctl_table usermodehelper_table[] = {
>  	{
>  		.procname	= "bset",
>  		.data		= &usermodehelper_bset,
> diff --git a/kernel/utsname_sysctl.c b/kernel/utsname_sysctl.c
> index 7282f61a8650..bfbaaecb1dd4 100644
> --- a/kernel/utsname_sysctl.c
> +++ b/kernel/utsname_sysctl.c
> @@ -75,7 +75,7 @@ static DEFINE_CTL_TABLE_POLL(hostname_poll);
>  static DEFINE_CTL_TABLE_POLL(domainname_poll);
>  
>  // Note: update 'enum uts_proc' to match any changes to this table
> -static struct ctl_table uts_kern_table[] = {
> +static const struct ctl_table uts_kern_table[] = {
>  	{
>  		.procname	= "arch",
>  		.data		= init_uts_ns.name.machine,
> @@ -129,7 +129,7 @@ static struct ctl_table uts_kern_table[] = {
>   */
>  void uts_proc_notify(enum uts_proc proc)
>  {
> -	struct ctl_table *table = &uts_kern_table[proc];
> +	const struct ctl_table *table = &uts_kern_table[proc];
>  
>  	proc_sys_poll_notify(table->poll);
>  }
> diff --git a/kernel/watchdog.c b/kernel/watchdog.c
> index 41e0f7e9fa35..613e73ef367c 100644
> --- a/kernel/watchdog.c
> +++ b/kernel/watchdog.c
> @@ -1094,7 +1094,7 @@ static int proc_watchdog_cpumask(const struct ctl_table *table, int write,
>  
>  static const int sixty = 60;
>  
> -static struct ctl_table watchdog_sysctls[] = {
> +static const struct ctl_table watchdog_sysctls[] = {
>  	{
>  		.procname       = "watchdog",
>  		.data		= &watchdog_user_enabled,
> diff --git a/lib/test_sysctl.c b/lib/test_sysctl.c
> index b6696fa1d426..4249e0cc8aaf 100644
> --- a/lib/test_sysctl.c
> +++ b/lib/test_sysctl.c
> @@ -71,7 +71,7 @@ static struct test_sysctl_data test_data = {
>  };
>  
>  /* These are all under /proc/sys/debug/test_sysctl/ */
> -static struct ctl_table test_table[] = {
> +static const struct ctl_table test_table[] = {
>  	{
>  		.procname	= "int_0001",
>  		.data		= &test_data.int_0001,
> @@ -177,7 +177,7 @@ static int test_sysctl_setup_node_tests(void)
>  }
>  
>  /* Used to test that unregister actually removes the directory */
> -static struct ctl_table test_table_unregister[] = {
> +static const struct ctl_table test_table_unregister[] = {
>  	{
>  		.procname	= "unregister_error",
>  		.data		= &test_data.int_0001,
> @@ -220,7 +220,7 @@ static int test_sysctl_run_register_mount_point(void)
>  	return 0;
>  }
>  
> -static struct ctl_table test_table_empty[] = { };
> +static const struct ctl_table test_table_empty[] = { };
>  
>  static int test_sysctl_run_register_empty(void)
>  {
> diff --git a/mm/compaction.c b/mm/compaction.c
> index a2b16b08cbbf..62e8ee230e1c 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -3297,7 +3297,7 @@ static int proc_dointvec_minmax_warn_RT_change(const struct ctl_table *table,
>  	return ret;
>  }
>  
> -static struct ctl_table vm_compaction[] = {
> +static const struct ctl_table vm_compaction[] = {
>  	{
>  		.procname	= "compact_memory",
>  		.data		= &sysctl_compact_memory,
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index c498874a7170..3857b9d72c84 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -4845,7 +4845,7 @@ static int hugetlb_overcommit_handler(const struct ctl_table *table, int write,
>  	return ret;
>  }
>  
> -static struct ctl_table hugetlb_table[] = {
> +static const struct ctl_table hugetlb_table[] = {
>  	{
>  		.procname	= "nr_hugepages",
>  		.data		= NULL,
> diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c
> index 57b7f591eee8..7735972add01 100644
> --- a/mm/hugetlb_vmemmap.c
> +++ b/mm/hugetlb_vmemmap.c
> @@ -693,7 +693,7 @@ void hugetlb_vmemmap_optimize_folios(struct hstate *h, struct list_head *folio_l
>  	free_vmemmap_page_list(&vmemmap_pages);
>  }
>  
> -static struct ctl_table hugetlb_vmemmap_sysctls[] = {
> +static const struct ctl_table hugetlb_vmemmap_sysctls[] = {
>  	{
>  		.procname	= "hugetlb_optimize_vmemmap",
>  		.data		= &vmemmap_optimize_enabled,
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index a7b8ccd29b6f..995a15eb67e2 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -124,7 +124,7 @@ const struct attribute_group memory_failure_attr_group = {
>  	.attrs = memory_failure_attr,
>  };
>  
> -static struct ctl_table memory_failure_table[] = {
> +static const struct ctl_table memory_failure_table[] = {
>  	{
>  		.procname	= "memory_failure_early_kill",
>  		.data		= &sysctl_memory_failure_early_kill,
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index 1c485beb0b93..c8280a39119c 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -699,7 +699,7 @@ static void queue_oom_reaper(struct task_struct *tsk)
>  }
>  
>  #ifdef CONFIG_SYSCTL
> -static struct ctl_table vm_oom_kill_table[] = {
> +static const struct ctl_table vm_oom_kill_table[] = {
>  	{
>  		.procname	= "panic_on_oom",
>  		.data		= &sysctl_panic_on_oom,
> diff --git a/mm/page-writeback.c b/mm/page-writeback.c
> index d213ead95675..fb523107701f 100644
> --- a/mm/page-writeback.c
> +++ b/mm/page-writeback.c
> @@ -2313,7 +2313,7 @@ static int page_writeback_cpu_online(unsigned int cpu)
>  /* this is needed for the proc_doulongvec_minmax of vm_dirty_bytes */
>  static const unsigned long dirty_bytes_min = 2 * PAGE_SIZE;
>  
> -static struct ctl_table vm_page_writeback_sysctls[] = {
> +static const struct ctl_table vm_page_writeback_sysctls[] = {
>  	{
>  		.procname   = "dirty_background_ratio",
>  		.data       = &dirty_background_ratio,
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index cae7b93864c2..6224a2ab5e86 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -6172,7 +6172,7 @@ static int percpu_pagelist_high_fraction_sysctl_handler(const struct ctl_table *
>  	return ret;
>  }
>  
> -static struct ctl_table page_alloc_sysctl_table[] = {
> +static const struct ctl_table page_alloc_sysctl_table[] = {
>  	{
>  		.procname	= "min_free_kbytes",
>  		.data		= &min_free_kbytes,
> diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
> index 1edc12862a7d..9b6c2f157f83 100644
> --- a/security/apparmor/lsm.c
> +++ b/security/apparmor/lsm.c
> @@ -2038,7 +2038,7 @@ static int apparmor_dointvec(const struct ctl_table *table, int write,
>  	return proc_dointvec(table, write, buffer, lenp, ppos);
>  }
>  
> -static struct ctl_table apparmor_sysctl_table[] = {
> +static const struct ctl_table apparmor_sysctl_table[] = {
>  #ifdef CONFIG_USER_NS
>  	{
>  		.procname       = "unprivileged_userns_apparmor_policy",
> diff --git a/security/keys/sysctl.c b/security/keys/sysctl.c
> index 91f000eef3ad..cde08c478f32 100644
> --- a/security/keys/sysctl.c
> +++ b/security/keys/sysctl.c
> @@ -9,7 +9,7 @@
>  #include <linux/sysctl.h>
>  #include "internal.h"
>  
> -static struct ctl_table key_sysctls[] = {
> +static const struct ctl_table key_sysctls[] = {
>  	{
>  		.procname = "maxkeys",
>  		.data = &key_quota_maxkeys,
> diff --git a/security/yama/yama_lsm.c b/security/yama/yama_lsm.c
> index e1a5e13ea269..54bd5f535ac1 100644
> --- a/security/yama/yama_lsm.c
> +++ b/security/yama/yama_lsm.c
> @@ -454,7 +454,7 @@ static int yama_dointvec_minmax(const struct ctl_table *table, int write,
>  
>  static int max_scope = YAMA_SCOPE_NO_ATTACH;
>  
> -static struct ctl_table yama_sysctl_table[] = {
> +static const struct ctl_table yama_sysctl_table[] = {
>  	{
>  		.procname       = "ptrace_scope",
>  		.data           = &ptrace_scope,
> 
> ---
> base-commit: 9d89551994a430b50c4fffcb1e617a057fa76e20
> change-id: 20250109-jag-ctl_table_const-38f6b2ccbba7
> 
> Best regards,
> -- 
> Joel Granados <joel.granados@kernel.org>
> 
> 
> 



From xen-devel-bounces@lists.xenproject.org Thu Jan 16 08:09:39 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 08:09:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873225.1284166 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYKwQ-0007K2-FR; Thu, 16 Jan 2025 08:09:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873225.1284166; Thu, 16 Jan 2025 08:09:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYKwQ-0007Jv-Cs; Thu, 16 Jan 2025 08:09:26 +0000
Received: by outflank-mailman (input) for mailman id 873225;
 Thu, 16 Jan 2025 08:09:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=cy/c=UI=suse.de=tzimmermann@srs-se1.protection.inumbo.net>)
 id 1tYKwO-0007Jp-Dv
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 08:09:24 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 31689369-d3e1-11ef-99a4-01e77a169b0f;
 Thu, 16 Jan 2025 09:09:22 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id AF679211D2;
 Thu, 16 Jan 2025 08:09:21 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 3205713A57;
 Thu, 16 Jan 2025 08:09:21 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id 3VTFCrG+iGf+BAAAD6G6ig
 (envelope-from <tzimmermann@suse.de>); Thu, 16 Jan 2025 08:09:21 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 31689369-d3e1-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1737014961; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=xcxRML23Nx7RFNokQB2O02aJnU9nWJlVXpAUoW6/DUc=;
	b=guL7z/7g3EcabgvnEePbbCuZQv7xD8Nwr9UitmLW0HdQwyFjV2SSCQgHXiJw8V8gnCT1K2
	PWtPwlEQencxyOkZzRFYa02U7TT7cyGEKiFsdqSu4Fbz6rTKbBaplstwxqYo2gR84TVDZg
	EoU34+EHEiZW91gRDl+FfWH9McSLkvo=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1737014961;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=xcxRML23Nx7RFNokQB2O02aJnU9nWJlVXpAUoW6/DUc=;
	b=QhcTxwz2tTYoCTzfudp0U1RC65EHxbTx4mcJuk8sOgRjhjNV0lXRty1p1dQWnKcwWKutz2
	DR+iY8oRFsTbZEBQ==
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1737014961; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=xcxRML23Nx7RFNokQB2O02aJnU9nWJlVXpAUoW6/DUc=;
	b=guL7z/7g3EcabgvnEePbbCuZQv7xD8Nwr9UitmLW0HdQwyFjV2SSCQgHXiJw8V8gnCT1K2
	PWtPwlEQencxyOkZzRFYa02U7TT7cyGEKiFsdqSu4Fbz6rTKbBaplstwxqYo2gR84TVDZg
	EoU34+EHEiZW91gRDl+FfWH9McSLkvo=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1737014961;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=xcxRML23Nx7RFNokQB2O02aJnU9nWJlVXpAUoW6/DUc=;
	b=QhcTxwz2tTYoCTzfudp0U1RC65EHxbTx4mcJuk8sOgRjhjNV0lXRty1p1dQWnKcwWKutz2
	DR+iY8oRFsTbZEBQ==
Message-ID: <a2bbeb47-2569-4ee0-9265-92bab139bdc6@suse.de>
Date: Thu, 16 Jan 2025 09:09:20 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with
 drm_mode_size_dumb()
To: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>,
 maarten.lankhorst@linux.intel.com, mripard@kernel.org, airlied@gmail.com,
 simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org, linux-mediatek@lists.infradead.org,
 freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
 imx@lists.linux.dev, linux-samsung-soc@vger.kernel.org,
 nouveau@lists.freedesktop.org, virtualization@lists.linux.dev,
 spice-devel@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org,
 linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org,
 intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org,
 Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
 Andy Yan <andyshrk@163.com>
References: <20250109150310.219442-1-tzimmermann@suse.de>
 <20250109150310.219442-26-tzimmermann@suse.de>
 <cdbe483d-0895-47aa-8c83-1c28220f4a02@ideasonboard.com>
 <bc97b92e-7f8a-4b92-af8a-20fa165ead55@suse.de>
 <f3ba05c7-6e49-4641-a3f9-ba418ebdb7c3@ideasonboard.com>
 <c6735280-7c32-4319-8ca9-a7305d8117c3@suse.de>
 <d67adb03-5cd0-4ac9-af58-cf4446dacee3@ideasonboard.com>
 <0ea6be58-0e04-4172-87cd-064a3e4a43bc@suse.de>
 <f35cb350-6be9-48ca-ad7e-e9dd418281d5@ideasonboard.com>
 <4af0b6a7-c16a-4187-bbf5-365a9c86de21@suse.de>
 <e327ad84-b5c9-4480-b873-dc3aca605538@ideasonboard.com>
Content-Language: en-US
From: Thomas Zimmermann <tzimmermann@suse.de>
Autocrypt: addr=tzimmermann@suse.de; keydata=
 xsBNBFs50uABCADEHPidWt974CaxBVbrIBwqcq/WURinJ3+2WlIrKWspiP83vfZKaXhFYsdg
 XH47fDVbPPj+d6tQrw5lPQCyqjwrCPYnq3WlIBnGPJ4/jreTL6V+qfKRDlGLWFjZcsrPJGE0
 BeB5BbqP5erN1qylK9i3gPoQjXGhpBpQYwRrEyQyjuvk+Ev0K1Jc5tVDeJAuau3TGNgah4Yc
 hdHm3bkPjz9EErV85RwvImQ1dptvx6s7xzwXTgGAsaYZsL8WCwDaTuqFa1d1jjlaxg6+tZsB
 9GluwvIhSezPgnEmimZDkGnZRRSFiGP8yjqTjjWuf0bSj5rUnTGiyLyRZRNGcXmu6hjlABEB
 AAHNJ1Rob21hcyBaaW1tZXJtYW5uIDx0emltbWVybWFubkBzdXNlLmRlPsLAjgQTAQgAOAIb
 AwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftODH
 AAoJEGgNwR1TC3ojx1wH/0hKGWugiqDgLNXLRD/4TfHBEKmxIrmfu9Z5t7vwUKfwhFL6hqvo
 lXPJJKQpQ2z8+X2vZm/slsLn7J1yjrOsoJhKABDi+3QWWSGkaGwRJAdPVVyJMfJRNNNIKwVb
 U6B1BkX2XDKDGffF4TxlOpSQzdtNI/9gleOoUA8+jy8knnDYzjBNOZqLG2FuTdicBXblz0Mf
 vg41gd9kCwYXDnD91rJU8tzylXv03E75NCaTxTM+FBXPmsAVYQ4GYhhgFt8S2UWMoaaABLDe
 7l5FdnLdDEcbmd8uLU2CaG4W2cLrUaI4jz2XbkcPQkqTQ3EB67hYkjiEE6Zy3ggOitiQGcqp
 j//OwE0EWznS4AEIAMYmP4M/V+T5RY5at/g7rUdNsLhWv1APYrh9RQefODYHrNRHUE9eosYb
 T6XMryR9hT8XlGOYRwKWwiQBoWSDiTMo/Xi29jUnn4BXfI2px2DTXwc22LKtLAgTRjP+qbU6
 3Y0xnQN29UGDbYgyyK51DW3H0If2a3JNsheAAK+Xc9baj0LGIc8T9uiEWHBnCH+RdhgATnWW
 GKdDegUR5BkDfDg5O/FISymJBHx2Dyoklv5g4BzkgqTqwmaYzsl8UxZKvbaxq0zbehDda8lv
 hFXodNFMAgTLJlLuDYOGLK2AwbrS3Sp0AEbkpdJBb44qVlGm5bApZouHeJ/+n+7r12+lqdsA
 EQEAAcLAdgQYAQgAIAIbDBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftOH6AAoJEGgNwR1T
 C3ojVSkIALpAPkIJPQoURPb1VWjh34l0HlglmYHvZszJWTXYwavHR8+k6Baa6H7ufXNQtThR
 yIxJrQLW6rV5lm7TjhffEhxVCn37+cg0zZ3j7zIsSS0rx/aMwi6VhFJA5hfn3T0TtrijKP4A
 SAQO9xD1Zk9/61JWk8OysuIh7MXkl0fxbRKWE93XeQBhIJHQfnc+YBLprdnxR446Sh8Wn/2D
 Ya8cavuWf2zrB6cZurs048xe0UbSW5AOSo4V9M0jzYI4nZqTmPxYyXbm30Kvmz0rYVRaitYJ
 4kyYYMhuULvrJDMjZRvaNe52tkKAvMevcGdt38H4KSVXAylqyQOW5zvPc4/sq9c=
In-Reply-To: <e327ad84-b5c9-4480-b873-dc3aca605538@ideasonboard.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Level: 
X-Spamd-Result: default: False [-2.80 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	FREEMAIL_TO(0.00)[ideasonboard.com,linux.intel.com,kernel.org,gmail.com,ffwll.ch];
	RCPT_COUNT_TWELVE(0.00)[21];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_ALL(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	FREEMAIL_ENVRCPT(0.00)[163.com,gmail.com];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	FROM_HAS_DN(0.00)[];
	FREEMAIL_CC(0.00)[lists.freedesktop.org,lists.infradead.org,vger.kernel.org,lists.linux.dev,lists.xenproject.org,ideasonboard.com,163.com];
	TO_DN_SOME(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:mid]
X-Spam-Score: -2.80
X-Spam-Flag: NO

Hi


Am 15.01.25 um 15:20 schrieb Tomi Valkeinen:
[...]
>
> My point is that we have the current UAPI, and we have userspace using 
> it, but we don't have clear rules what the ioctl does with specific 
> parameters, and we don't document how it has to be used.
>
> Perhaps the situation is bad, and all we can really say is that 
> CREATE_DUMB only works for use with simple RGB formats, and the 
> behavior for all other formats is platform specific. But I think even 
> that would be valuable in the UAPI docs.

To be honest, I would not want to specify behavior for anything but the 
linear RGB formats. If anything, I'd take Daniel's reply mail for 
documentation as-is. Anyone stretching the UAPI beyond RGB is on their own.

>
> Thinking about this, I wonder if this change is good for omapdrm or 
> xilinx (probably other platforms too that support non-simple non-RGB 
> formats via dumb buffers): without this patch, in both drivers, the 
> pitch calculations just take the bpp as bit-per-pixels, align it up, 
> and that's it.
>
> With this patch we end up using drm_driver_color_mode_format(), and 
> aligning buffers according to RGB formats figured out via heuristics. 
> It does happen to work, for the formats I tested, but it sounds like 
> something that might easily not work, as it's doing adjustments based 
> on wrong format.
>
> Should we have another version of drm_mode_size_dumb() which just 
> calculates using the bpp, without the drm_driver_color_mode_format() 
> path? Or does the drm_driver_color_mode_format() path provide some 
> value for the drivers that do not currently do anything similar?

With the RGB-only rule, using drm_driver_color_mode_format() makes 
sense. It aligns dumb buffers and video=, provides error checking, and 
overall harmonizes code. The fallback is only required because of the 
existing odd cases that already bend the UAPI's rules.

Best regards
Thomas

>
>  Tomi
>

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)



From xen-devel-bounces@lists.xenproject.org Thu Jan 16 08:43:55 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 08:43:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873240.1284222 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYLTm-0004vP-Ec; Thu, 16 Jan 2025 08:43:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873240.1284222; Thu, 16 Jan 2025 08:43:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYLTm-0004th-2v; Thu, 16 Jan 2025 08:43:54 +0000
Received: by outflank-mailman (input) for mailman id 873240;
 Thu, 16 Jan 2025 08:43:51 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=8jK+=UI=casper.srs.infradead.org=BATV+cabf69696ff47aa9dee2+7816+infradead.org+dwmw2@srs-se1.protection.inumbo.net>)
 id 1tYLTj-0004BJ-Ee
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 08:43:51 +0000
Received: from casper.infradead.org (casper.infradead.org
 [2001:8b0:10b:1236::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ff7a2145-d3e5-11ef-99a4-01e77a169b0f;
 Thu, 16 Jan 2025 09:43:47 +0100 (CET)
Received: from [2001:8b0:10b:1::ebe] (helo=i7.infradead.org)
 by casper.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux))
 id 1tYLTd-0000000AkbX-0VhX; Thu, 16 Jan 2025 08:43:45 +0000
Received: from dwoodhou by i7.infradead.org with local (Exim 4.98 #2 (Red Hat
 Linux)) id 1tYLTc-00000007pIG-3SiW; Thu, 16 Jan 2025 08:43:44 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
X-Inumbo-ID: ff7a2145-d3e5-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=Sender:Content-Transfer-Encoding:
	MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:
	Reply-To:Content-Type:Content-ID:Content-Description;
	bh=rf4XQLZvATxaJ4ZS360lOa75wV7gwRBU9Wx/NrfpNKM=; b=sFlr5bcNd4N4BJ5gR3Jk2RMuSZ
	5ueFpFbkgmzLDSSjXJ4F7E+VBxywP+JIRlQoRKp3wkAY8M1RXh+2AgFkdaR0I+RJ/HbnrYMA+Z0zU
	2lmxNsy2Qy/lJdQ9rSRQOyDus7jTuvUOxbVmPxnvd+PQKO1ZzaiVWnoNH0DVgLxdULgr2CX7e6mvu
	QrD2RyTvgL5O6bdVak0nEQCYiMG6AHb8ODInb95f1z/eiaN9PgRwMoW9LxHdxLVJTzHvEJkOKa99m
	RL0y+rCcqZpKVNodam5HJp2Ry+5gdt3tdeSL9bekAURJVRyjXefSwKZWd44xr0u1/xBMze+9o1USG
	+58fvVNg==;
From: David Woodhouse <dwmw2@infradead.org>
To: Stefan Hajnoczi <stefanha@redhat.com>,
	qemu-devel@nongnu.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Kevin Wolf <kwolf@redhat.com>,
	Hanna Reitz <hreitz@redhat.com>,
	=?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= <marcandre.lureau@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	xen-devel@lists.xenproject.org,
	qemu-block@nongnu.org,
	Phil Dennis-Jordan <phil@philjordan.eu>,
	David Woodhouse <dwmw@amazon.co.uk>,
	Anthony PERARD <anthony.perard@vates.tech>
Subject: [PULL 7/8] hw/xen: Fix errp handling in xen_console
Date: Thu, 16 Jan 2025 08:43:31 +0000
Message-ID: <20250116084332.1864967-8-dwmw2@infradead.org>
X-Mailer: git-send-email 2.47.0
In-Reply-To: <20250116084332.1864967-1-dwmw2@infradead.org>
References: <20250116084332.1864967-1-dwmw2@infradead.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: David Woodhouse <dwmw2@infradead.org>
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html

From: David Woodhouse <dwmw@amazon.co.uk>

When attempting to read the 'output' node, interpret any error *other*
than ENOENT as a fatal error. For ENOENT, fall back to serial_hd() to
find a character device, or create a null device.

Do not attempt to prepend to errp when serial_hd() fails; the error
isn't relevant (and prior to this change, wasn't set anyway).

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
---
 hw/char/xen_console.c | 34 +++++++++++++++++++++-------------
 1 file changed, 21 insertions(+), 13 deletions(-)

diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
index e61902461b..d03c188d1d 100644
--- a/hw/char/xen_console.c
+++ b/hw/char/xen_console.c
@@ -569,7 +569,7 @@ static void xen_console_device_create(XenBackendInstance *backend,
 
     snprintf(label, sizeof(label), "xencons%ld", number);
 
-    output = xs_node_read(xsh, XBT_NULL, NULL, NULL, "%s/%s", fe, "output");
+    output = xs_node_read(xsh, XBT_NULL, NULL, errp, "%s/%s", fe, "output");
     if (output) {
         /*
          * FIXME: sure we want to support implicit
@@ -581,19 +581,27 @@ static void xen_console_device_create(XenBackendInstance *backend,
                        output);
             goto fail;
         }
-    } else if (number) {
-        cd = serial_hd(number);
-        if (!cd) {
-            error_prepend(errp, "console: No serial device #%ld found: ",
-                          number);
-            goto fail;
-        }
+    } else if (errno != ENOENT) {
+        error_prepend(errp, "console: No valid chardev found: ");
+        goto fail;
     } else {
-        /* No 'output' node on primary console: use null. */
-        cd = qemu_chr_new(label, "null", NULL);
-        if (!cd) {
-            error_setg(errp, "console: failed to create null device");
-            goto fail;
+        error_free(*errp);
+        *errp = NULL;
+
+        if (number) {
+            cd = serial_hd(number);
+            if (!cd) {
+                error_setg(errp, "console: No serial device #%ld found",
+                           number);
+                goto fail;
+            }
+        } else {
+            /* No 'output' node on primary console: use null. */
+            cd = qemu_chr_new(label, "null", NULL);
+            if (!cd) {
+                error_setg(errp, "console: failed to create null device");
+                goto fail;
+            }
         }
     }
 
-- 
2.47.0



From xen-devel-bounces@lists.xenproject.org Thu Jan 16 08:43:55 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 08:43:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873242.1284242 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYLTn-0005JY-Mi; Thu, 16 Jan 2025 08:43:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873242.1284242; Thu, 16 Jan 2025 08:43:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYLTn-0005Gn-41; Thu, 16 Jan 2025 08:43:55 +0000
Received: by outflank-mailman (input) for mailman id 873242;
 Thu, 16 Jan 2025 08:43: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
 <SRS0=8jK+=UI=casper.srs.infradead.org=BATV+cabf69696ff47aa9dee2+7816+infradead.org+dwmw2@srs-se1.protection.inumbo.net>)
 id 1tYLTk-0004BI-8O
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 08:43:52 +0000
Received: from casper.infradead.org (casper.infradead.org
 [2001:8b0:10b:1236::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ff9d8e82-d3e5-11ef-a0e2-8be0dac302b0;
 Thu, 16 Jan 2025 09:43:46 +0100 (CET)
Received: from [2001:8b0:10b:1::ebe] (helo=i7.infradead.org)
 by casper.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux))
 id 1tYLTc-0000000AkbB-3O43; Thu, 16 Jan 2025 08:43:44 +0000
Received: from dwoodhou by i7.infradead.org with local (Exim 4.98 #2 (Red Hat
 Linux)) id 1tYLTc-00000007pHc-2AtI; Thu, 16 Jan 2025 08:43:44 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
X-Inumbo-ID: ff9d8e82-d3e5-11ef-a0e2-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=Sender:Content-Transfer-Encoding:
	Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:
	To:From:Reply-To:Content-ID:Content-Description;
	bh=OYFjBLn6xVJHbZhWxQv4vOgSmuf1vV6rSJAY+96mfc8=; b=d+U5EkTgZ5pFrvJohXFqCoGsqb
	LR3vJ3gOBwJ+0J6fy0xJm8d4BKL1KooTEOJ2xy7zbQKYY4XgJ75GINFidKcmUeuCG0mzPik75R7JP
	bpwGynA4tfUP/lwO7T26CRU8/RIocs2rbRMhJt5jZ4fxizIJARvdfYDlo7wOwyoc7JZeD7+Te+Ncq
	R+eKMT2TlTC0/rYD3Ez3u547HJVZzJBH/1KpR4A3yu00ogCWOoQuGN+YA1O9IFN8k0VgH1zW4m1gD
	y6O3lNIeQr60Z0SVcUZ3gwqOFZ8wfWF+hAfRWOjR9LICx2bvjW2H/L87Kcu5jMEFkR8lP104NiSRc
	f7bL0PCA==;
From: David Woodhouse <dwmw2@infradead.org>
To: Stefan Hajnoczi <stefanha@redhat.com>,
	qemu-devel@nongnu.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Kevin Wolf <kwolf@redhat.com>,
	Hanna Reitz <hreitz@redhat.com>,
	=?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= <marcandre.lureau@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	xen-devel@lists.xenproject.org,
	qemu-block@nongnu.org,
	Phil Dennis-Jordan <phil@philjordan.eu>,
	David Woodhouse <dwmw@amazon.co.uk>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>
Subject: [PULL 1/8] hw/xen: Add xs_node_read() helper function
Date: Thu, 16 Jan 2025 08:43:25 +0000
Message-ID: <20250116084332.1864967-2-dwmw2@infradead.org>
X-Mailer: git-send-email 2.47.0
In-Reply-To: <20250116084332.1864967-1-dwmw2@infradead.org>
References: <20250116084332.1864967-1-dwmw2@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Sender: David Woodhouse <dwmw2@infradead.org>
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html

From: David Woodhouse <dwmw@amazon.co.uk>

This returns the full contents of the node, having created the node path
from the printf-style format string provided in its arguments.

This will save various callers from having to do so for themselves (and
from using xs_node_scanf() with the non-portable %ms format string.

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
[remove double newline and constify trace parameters]
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
---
 hw/xen/trace-events             |  1 +
 hw/xen/xen-bus-helper.c         | 22 ++++++++++++++++++++++
 include/hw/xen/xen-bus-helper.h |  9 +++++++++
 3 files changed, 32 insertions(+)

diff --git a/hw/xen/trace-events b/hw/xen/trace-events
index a07fe41c6d..461dee7b23 100644
--- a/hw/xen/trace-events
+++ b/hw/xen/trace-events
@@ -39,6 +39,7 @@ xs_node_create(const char *node) "%s"
 xs_node_destroy(const char *node) "%s"
 xs_node_vprintf(char *path, char *value) "%s %s"
 xs_node_vscanf(char *path, char *value) "%s %s"
+xs_node_read(const char *path, const char *value) "%s %s"
 xs_node_watch(char *path) "%s"
 xs_node_unwatch(char *path) "%s"
 
diff --git a/hw/xen/xen-bus-helper.c b/hw/xen/xen-bus-helper.c
index b2b2cc9c5d..22fd2f6c1a 100644
--- a/hw/xen/xen-bus-helper.c
+++ b/hw/xen/xen-bus-helper.c
@@ -142,6 +142,28 @@ int xs_node_scanf(struct qemu_xs_handle *h,  xs_transaction_t tid,
     return rc;
 }
 
+char *xs_node_read(struct qemu_xs_handle *h, xs_transaction_t tid,
+                   unsigned int *len, Error **errp,
+                   const char *path_fmt, ...)
+{
+    char *path, *value;
+    va_list ap;
+
+    va_start(ap, path_fmt);
+    path = g_strdup_vprintf(path_fmt, ap);
+    va_end(ap);
+
+    value = qemu_xen_xs_read(h, tid, path, len);
+    trace_xs_node_read(path, value);
+    if (!value) {
+        error_setg_errno(errp, errno, "failed to read from '%s'", path);
+    }
+
+    g_free(path);
+
+    return value;
+}
+
 struct qemu_xs_watch *xs_node_watch(struct qemu_xs_handle *h, const char *node,
                                     const char *key, xs_watch_fn fn,
                                     void *opaque, Error **errp)
diff --git a/include/hw/xen/xen-bus-helper.h b/include/hw/xen/xen-bus-helper.h
index d8dcc2f010..e9911115b3 100644
--- a/include/hw/xen/xen-bus-helper.h
+++ b/include/hw/xen/xen-bus-helper.h
@@ -38,6 +38,15 @@ int xs_node_scanf(struct qemu_xs_handle *h,  xs_transaction_t tid,
                   const char *fmt, ...)
     G_GNUC_SCANF(6, 7);
 
+/*
+ * Unlike other functions here, the printf-formatted path_fmt is for
+ * the XenStore path, not the contents of the node.
+ */
+char *xs_node_read(struct qemu_xs_handle *h, xs_transaction_t tid,
+                   unsigned int *len, Error **errp,
+                   const char *path_fmt, ...)
+    G_GNUC_PRINTF(5, 6);
+
 /* Watch node/key unless node is empty, in which case watch key */
 struct qemu_xs_watch *xs_node_watch(struct qemu_xs_handle *h, const char *node,
                                     const char *key, xs_watch_fn fn,
-- 
2.47.0



From xen-devel-bounces@lists.xenproject.org Thu Jan 16 08:43:55 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 08:43:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873234.1284177 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYLTk-0004C3-1q; Thu, 16 Jan 2025 08:43:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873234.1284177; Thu, 16 Jan 2025 08:43:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYLTj-0004Bw-UC; Thu, 16 Jan 2025 08:43:51 +0000
Received: by outflank-mailman (input) for mailman id 873234;
 Thu, 16 Jan 2025 08:43: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
 <SRS0=8jK+=UI=casper.srs.infradead.org=BATV+cabf69696ff47aa9dee2+7816+infradead.org+dwmw2@srs-se1.protection.inumbo.net>)
 id 1tYLTg-0004BI-S8
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 08:43:50 +0000
Received: from casper.infradead.org (casper.infradead.org
 [2001:8b0:10b:1236::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ff9e2857-d3e5-11ef-a0e2-8be0dac302b0;
 Thu, 16 Jan 2025 09:43:46 +0100 (CET)
Received: from [2001:8b0:10b:1::ebe] (helo=i7.infradead.org)
 by casper.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux))
 id 1tYLTc-0000000AkbC-3UJK; Thu, 16 Jan 2025 08:43:44 +0000
Received: from dwoodhou by i7.infradead.org with local (Exim 4.98 #2 (Red Hat
 Linux)) id 1tYLTc-00000007pHh-2K0i; Thu, 16 Jan 2025 08:43:44 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
X-Inumbo-ID: ff9e2857-d3e5-11ef-a0e2-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=Sender:Content-Transfer-Encoding:
	Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:
	To:From:Reply-To:Content-ID:Content-Description;
	bh=DR5mFAf4m4LBhzxhAqxWzplLWjQI40VGtvjtZ6+t6c4=; b=RWoIb912hQmTElYRyXcO6i7n/6
	7aQ9mKlddz4vnYA/tzUwlragwZcQDpyLdZkOYQnx8QY0PAzPrbo/hFyjICLNx3nX5LK9sdaCEnkYc
	ibJ5bH5g9pycHzKmZKbT669twWv62Tj28hLXUCyVEebvwnvm4GnObo2c7OOK+s6st3nY9Lb6MQSI6
	F3DZ2j8vrn+TZ1sBjPjnYFrB5ZG3DYRJrH8+zBq3keHAVzKms0GxU7ZR241ztLkCkdifRfCxHVOho
	erHBwyIjIDYQMok8bacin7Vczk5KiVXXyGBZczbCYCUG1+gk3lHW2T01z7ILoGDU/kIJ4kjcQmLYW
	PsynnlsQ==;
From: David Woodhouse <dwmw2@infradead.org>
To: Stefan Hajnoczi <stefanha@redhat.com>,
	qemu-devel@nongnu.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Kevin Wolf <kwolf@redhat.com>,
	Hanna Reitz <hreitz@redhat.com>,
	=?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= <marcandre.lureau@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	xen-devel@lists.xenproject.org,
	qemu-block@nongnu.org,
	Phil Dennis-Jordan <phil@philjordan.eu>,
	Roger Pau Monne <roger.pau@citrix.com>,
	David Woodhouse <dwmw@amazon.co.uk>,
	Anthony PERARD <anthony.perard@vates.tech>
Subject: [PULL 2/8] xen: do not use '%ms' scanf specifier
Date: Thu, 16 Jan 2025 08:43:26 +0000
Message-ID: <20250116084332.1864967-3-dwmw2@infradead.org>
X-Mailer: git-send-email 2.47.0
In-Reply-To: <20250116084332.1864967-1-dwmw2@infradead.org>
References: <20250116084332.1864967-1-dwmw2@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Sender: David Woodhouse <dwmw2@infradead.org>
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html

From: Roger Pau Monne <roger.pau@citrix.com>

The 'm' parameter used to request auto-allocation of the destination variable
is not supported on FreeBSD, and as such leads to failures to parse.

What's more, the current usage of '%ms' with xs_node_scanf() is pointless, as
it just leads to a double allocation of the same string.  Instead use
xs_node_read() to read the whole xenstore node.

Fixes: a783f8ad4ec9 ('xen: add a mechanism to automatically create XenDevice-s...')
Fixes: 9b7737469080 ('hw/xen: update Xen console to XenDevice model')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
---
 hw/block/xen-block.c     |  3 ++-
 hw/char/xen_console.c    |  6 ++++--
 hw/xen/xen-bus.c         | 14 ++++++++++++--
 include/hw/xen/xen-bus.h |  1 +
 4 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/hw/block/xen-block.c b/hw/block/xen-block.c
index 306d38927c..034a18b70e 100644
--- a/hw/block/xen-block.c
+++ b/hw/block/xen-block.c
@@ -239,7 +239,8 @@ static void xen_block_connect(XenDevice *xendev, Error **errp)
         return;
     }
 
-    if (xen_device_frontend_scanf(xendev, "protocol", "%ms", &str) != 1) {
+    str = xen_device_frontend_read(xendev, "protocol");
+    if (!str) {
         /* x86 defaults to the 32-bit protocol even for 64-bit guests. */
         if (object_dynamic_cast(OBJECT(qdev_get_machine()), "x86-machine")) {
             protocol = BLKIF_PROTOCOL_X86_32;
diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
index ef0c2912ef..cb39b21504 100644
--- a/hw/char/xen_console.c
+++ b/hw/char/xen_console.c
@@ -550,7 +550,8 @@ static void xen_console_device_create(XenBackendInstance *backend,
         goto fail;
     }
 
-    if (xs_node_scanf(xsh, XBT_NULL, fe, "type", errp, "%ms", &type) != 1) {
+    type = xs_node_read(xsh, XBT_NULL, NULL, errp, "%s/%s", fe, "type");
+    if (!type) {
         error_prepend(errp, "failed to read console device type: ");
         goto fail;
     }
@@ -568,7 +569,8 @@ static void xen_console_device_create(XenBackendInstance *backend,
 
     snprintf(label, sizeof(label), "xencons%ld", number);
 
-    if (xs_node_scanf(xsh, XBT_NULL, fe, "output", NULL, "%ms", &output) == 1) {
+    output = xs_node_read(xsh, XBT_NULL, NULL, NULL, "%s/%s", fe, "output");
+    if (output) {
         /*
          * FIXME: sure we want to support implicit
          * muxed monitors here?
diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c
index adfc4efad0..feeb612681 100644
--- a/hw/xen/xen-bus.c
+++ b/hw/xen/xen-bus.c
@@ -156,8 +156,8 @@ again:
             !strcmp(key[i], "hotplug-status"))
             continue;
 
-        if (xs_node_scanf(xenbus->xsh, tid, path, key[i], NULL, "%ms",
-                          &val) == 1) {
+        val = xs_node_read(xenbus->xsh, tid, NULL, NULL, "%s/%s", path, key[i]);
+        if (val) {
             qdict_put_str(opts, key[i], val);
             free(val);
         }
@@ -650,6 +650,16 @@ int xen_device_frontend_scanf(XenDevice *xendev, const char *key,
     return rc;
 }
 
+char *xen_device_frontend_read(XenDevice *xendev, const char *key)
+{
+    XenBus *xenbus = XEN_BUS(qdev_get_parent_bus(DEVICE(xendev)));
+
+    g_assert(xenbus->xsh);
+
+    return xs_node_read(xenbus->xsh, XBT_NULL, NULL, NULL, "%s/%s",
+                        xendev->frontend_path, key);
+}
+
 static void xen_device_frontend_set_state(XenDevice *xendev,
                                           enum xenbus_state state,
                                           bool publish)
diff --git a/include/hw/xen/xen-bus.h b/include/hw/xen/xen-bus.h
index 38d40afa37..2adb2af839 100644
--- a/include/hw/xen/xen-bus.h
+++ b/include/hw/xen/xen-bus.h
@@ -91,6 +91,7 @@ void xen_device_frontend_printf(XenDevice *xendev, const char *key,
 int xen_device_frontend_scanf(XenDevice *xendev, const char *key,
                               const char *fmt, ...)
     G_GNUC_SCANF(3, 4);
+char *xen_device_frontend_read(XenDevice *xendev, const char *key);
 
 void xen_device_set_max_grant_refs(XenDevice *xendev, unsigned int nr_refs,
                                    Error **errp);
-- 
2.47.0



From xen-devel-bounces@lists.xenproject.org Thu Jan 16 08:43:55 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 08:43:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873238.1284207 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYLTl-0004g4-KF; Thu, 16 Jan 2025 08:43:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873238.1284207; Thu, 16 Jan 2025 08:43:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYLTl-0004ds-9D; Thu, 16 Jan 2025 08:43:53 +0000
Received: by outflank-mailman (input) for mailman id 873238;
 Thu, 16 Jan 2025 08:43:51 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=8jK+=UI=casper.srs.infradead.org=BATV+cabf69696ff47aa9dee2+7816+infradead.org+dwmw2@srs-se1.protection.inumbo.net>)
 id 1tYLTj-0004BJ-7j
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 08:43:51 +0000
Received: from casper.infradead.org (casper.infradead.org
 [2001:8b0:10b:1236::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ff78101a-d3e5-11ef-99a4-01e77a169b0f;
 Thu, 16 Jan 2025 09:43:47 +0100 (CET)
Received: from [2001:8b0:10b:1::ebe] (helo=i7.infradead.org)
 by casper.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux))
 id 1tYLTc-0000000AkbG-3qV4; Thu, 16 Jan 2025 08:43:44 +0000
Received: from dwoodhou by i7.infradead.org with local (Exim 4.98 #2 (Red Hat
 Linux)) id 1tYLTc-00000007pHr-2YxY; Thu, 16 Jan 2025 08:43:44 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
X-Inumbo-ID: ff78101a-d3e5-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=Sender:Content-Transfer-Encoding:
	Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:
	To:From:Reply-To:Content-ID:Content-Description;
	bh=j2gaDkDHKbVHS9ffxI7464SULQ6IWC/ZhoSg1yVGsXA=; b=Ci966gPsNiepcNsWTJ3GrGxX2P
	iialW0rMgLpBYD00Go26JxJJvqqeUCPGWYQzcP/ngxL7HnddZg4utfVp3x8eKOq1hPwziktycPn/3
	NsZnFK1OFps5OssGxvWZ5VqxLPztx4JSS334JvdHY6YUarq8Mw7guJELf87g+sV1TtP6PWVjCh5Ni
	QCmEfZsrFVQTqVy7sPEdmhL/AnkwlBTWItxTEDKFn1CllnAPHAIRuzobBxrakQttQ2CJQ6aNb7iLJ
	0jCSgu+Fb8NJQz9i5dSgRXmsDNqJvbG/jSVvEgjeMt8mFFqdN/RGkeiUBzLR4h82m4RX/TU7w2yNP
	4FmN4YwA==;
From: David Woodhouse <dwmw2@infradead.org>
To: Stefan Hajnoczi <stefanha@redhat.com>,
	qemu-devel@nongnu.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Kevin Wolf <kwolf@redhat.com>,
	Hanna Reitz <hreitz@redhat.com>,
	=?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= <marcandre.lureau@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	xen-devel@lists.xenproject.org,
	qemu-block@nongnu.org,
	Phil Dennis-Jordan <phil@philjordan.eu>,
	David Woodhouse <dwmw@amazon.co.uk>,
	Anthony PERARD <anthony.perard@vates.tech>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PULL 3/8] hw/xen: Use xs_node_read() from xs_node_vscanf()
Date: Thu, 16 Jan 2025 08:43:27 +0000
Message-ID: <20250116084332.1864967-4-dwmw2@infradead.org>
X-Mailer: git-send-email 2.47.0
In-Reply-To: <20250116084332.1864967-1-dwmw2@infradead.org>
References: <20250116084332.1864967-1-dwmw2@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Sender: David Woodhouse <dwmw2@infradead.org>
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html

From: David Woodhouse <dwmw@amazon.co.uk>

Reduce some duplication.

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
---
 hw/xen/trace-events     |  1 -
 hw/xen/xen-bus-helper.c | 15 ++++++---------
 2 files changed, 6 insertions(+), 10 deletions(-)

diff --git a/hw/xen/trace-events b/hw/xen/trace-events
index 461dee7b23..b67942d07b 100644
--- a/hw/xen/trace-events
+++ b/hw/xen/trace-events
@@ -38,7 +38,6 @@ xen_device_remove_watch(const char *type, char *name, const char *node, const ch
 xs_node_create(const char *node) "%s"
 xs_node_destroy(const char *node) "%s"
 xs_node_vprintf(char *path, char *value) "%s %s"
-xs_node_vscanf(char *path, char *value) "%s %s"
 xs_node_read(const char *path, const char *value) "%s %s"
 xs_node_watch(char *path) "%s"
 xs_node_unwatch(char *path) "%s"
diff --git a/hw/xen/xen-bus-helper.c b/hw/xen/xen-bus-helper.c
index 22fd2f6c1a..288fad422b 100644
--- a/hw/xen/xen-bus-helper.c
+++ b/hw/xen/xen-bus-helper.c
@@ -105,25 +105,22 @@ int xs_node_vscanf(struct qemu_xs_handle *h,  xs_transaction_t tid,
                    const char *node, const char *key, Error **errp,
                    const char *fmt, va_list ap)
 {
-    char *path, *value;
+    char *value;
     int rc;
 
-    path = (strlen(node) != 0) ? g_strdup_printf("%s/%s", node, key) :
-        g_strdup(key);
-    value = qemu_xen_xs_read(h, tid, path, NULL);
-
-    trace_xs_node_vscanf(path, value);
+    if (node && strlen(node) != 0) {
+        value = xs_node_read(h, tid, NULL, errp, "%s/%s", node, key);
+    } else {
+        value = xs_node_read(h, tid, NULL, errp, "%s", key);
+    }
 
     if (value) {
         rc = vsscanf(value, fmt, ap);
     } else {
-        error_setg_errno(errp, errno, "failed to read from '%s'",
-                         path);
         rc = EOF;
     }
 
     free(value);
-    g_free(path);
 
     return rc;
 }
-- 
2.47.0



From xen-devel-bounces@lists.xenproject.org Thu Jan 16 08:43:55 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 08:43:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873235.1284184 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYLTk-0004FA-DG; Thu, 16 Jan 2025 08:43:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873235.1284184; Thu, 16 Jan 2025 08:43:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYLTk-0004E3-4P; Thu, 16 Jan 2025 08:43:52 +0000
Received: by outflank-mailman (input) for mailman id 873235;
 Thu, 16 Jan 2025 08:43: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
 <SRS0=8jK+=UI=casper.srs.infradead.org=BATV+cabf69696ff47aa9dee2+7816+infradead.org+dwmw2@srs-se1.protection.inumbo.net>)
 id 1tYLTi-0004BI-7o
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 08:43:50 +0000
Received: from casper.infradead.org (casper.infradead.org
 [2001:8b0:10b:1236::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ff9ddd88-d3e5-11ef-a0e2-8be0dac302b0;
 Thu, 16 Jan 2025 09:43:46 +0100 (CET)
Received: from [2001:8b0:10b:1::ebe] (helo=i7.infradead.org)
 by casper.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux))
 id 1tYLTc-0000000AkbM-452f; Thu, 16 Jan 2025 08:43:45 +0000
Received: from dwoodhou by i7.infradead.org with local (Exim 4.98 #2 (Red Hat
 Linux)) id 1tYLTc-00000007pHw-2j0P; Thu, 16 Jan 2025 08:43:44 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
X-Inumbo-ID: ff9ddd88-d3e5-11ef-a0e2-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=Sender:Content-Transfer-Encoding:
	Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:
	To:From:Reply-To:Content-ID:Content-Description;
	bh=9nRlgfR/HkbXdsVZN1RJ5s3wIYDMgIRx7AVyt9JqyRI=; b=GV4GsiKfcPaha4Yfg/SPTwsYVB
	VXyP5feW8Uhc+l6Y1k5Sx/MHGVdLm4y7dVanuxoy+bz9LmSQ4o1b1F/FZ2Proo9odrcvD7p2BBiDU
	D7owT//iz7tqe9F3dxW+m19/t/cDaJzaIm/92hrv5dsFy86rW+1kOkVWDTC9VOds/TgE7exako0lU
	hckl7d9vFnB73icw7IWpAMAcZRVFVXhd4+HgEvfYTGLfzdjkZ1QNwAFrEHcnfOAi9/ILYoM/JPQ/+
	Cet8xQcgTObu1BR7oNJwHrk9qF8pLPegEQQ/yVbXMjO/dGU45nDyBpueNecte2Z5oAWRkkUcA6t+o
	cHxn96pw==;
From: David Woodhouse <dwmw2@infradead.org>
To: Stefan Hajnoczi <stefanha@redhat.com>,
	qemu-devel@nongnu.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Kevin Wolf <kwolf@redhat.com>,
	Hanna Reitz <hreitz@redhat.com>,
	=?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= <marcandre.lureau@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	xen-devel@lists.xenproject.org,
	qemu-block@nongnu.org,
	Phil Dennis-Jordan <phil@philjordan.eu>,
	David Woodhouse <dwmw@amazon.co.uk>,
	Anthony PERARD <anthony.perard@vates.tech>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PULL 4/8] hw/xen: Use xs_node_read() from xen_console_get_name()
Date: Thu, 16 Jan 2025 08:43:28 +0000
Message-ID: <20250116084332.1864967-5-dwmw2@infradead.org>
X-Mailer: git-send-email 2.47.0
In-Reply-To: <20250116084332.1864967-1-dwmw2@infradead.org>
References: <20250116084332.1864967-1-dwmw2@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Sender: David Woodhouse <dwmw2@infradead.org>
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html

From: David Woodhouse <dwmw@amazon.co.uk>

Now that xs_node_read() can construct a node path, no need to open-code it.

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
---
 hw/char/xen_console.c | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
index cb39b21504..e61902461b 100644
--- a/hw/char/xen_console.c
+++ b/hw/char/xen_console.c
@@ -367,28 +367,28 @@ static char *xen_console_get_name(XenDevice *xendev, Error **errp)
 
     if (con->dev == -1) {
         XenBus *xenbus = XEN_BUS(qdev_get_parent_bus(DEVICE(xendev)));
-        char fe_path[XENSTORE_ABS_PATH_MAX + 1];
         int idx = (xen_mode == XEN_EMULATE) ? 0 : 1;
+        Error *local_err = NULL;
         char *value;
 
         /* Theoretically we could go up to INT_MAX here but that's overkill */
         while (idx < 100) {
             if (!idx) {
-                snprintf(fe_path, sizeof(fe_path),
-                         "/local/domain/%u/console", xendev->frontend_id);
+                value = xs_node_read(xenbus->xsh, XBT_NULL, NULL, &local_err,
+                                     "/local/domain/%u/console",
+                                     xendev->frontend_id);
             } else {
-                snprintf(fe_path, sizeof(fe_path),
-                         "/local/domain/%u/device/console/%u",
-                         xendev->frontend_id, idx);
+                value = xs_node_read(xenbus->xsh, XBT_NULL, NULL, &local_err,
+                                     "/local/domain/%u/device/console/%u",
+                                     xendev->frontend_id, idx);
             }
-            value = qemu_xen_xs_read(xenbus->xsh, XBT_NULL, fe_path, NULL);
             if (!value) {
                 if (errno == ENOENT) {
                     con->dev = idx;
+                    error_free(local_err);
                     goto found;
                 }
-                error_setg(errp, "cannot read %s: %s", fe_path,
-                           strerror(errno));
+                error_propagate(errp, local_err);
                 return NULL;
             }
             free(value);
-- 
2.47.0



From xen-devel-bounces@lists.xenproject.org Thu Jan 16 08:43:56 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 08:43:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873236.1284189 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYLTk-0004L7-LS; Thu, 16 Jan 2025 08:43:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873236.1284189; Thu, 16 Jan 2025 08:43:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYLTk-0004Kj-Fr; Thu, 16 Jan 2025 08:43:52 +0000
Received: by outflank-mailman (input) for mailman id 873236;
 Thu, 16 Jan 2025 08:43:50 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=8XGS=UI=ideasonboard.com=laurent.pinchart@srs-se1.protection.inumbo.net>)
 id 1tYLTi-0004BJ-BU
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 08:43:50 +0000
Received: from perceval.ideasonboard.com (perceval.ideasonboard.com
 [213.167.242.64]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ffc7e940-d3e5-11ef-99a4-01e77a169b0f;
 Thu, 16 Jan 2025 09:43:46 +0100 (CET)
Received: from pendragon.ideasonboard.com (unknown [193.209.96.36])
 by perceval.ideasonboard.com (Postfix) with ESMTPSA id 1CDD7169;
 Thu, 16 Jan 2025 09:42:47 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ffc7e940-d3e5-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;
	s=mail; t=1737016967;
	bh=YBJYqGqQ2U3g/glMhqBtVA7c9PNcNKm2bF2hwWN3X/8=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=LEeZiJfRiaftp5JL3OuhSGJ31fbSk67YMrTfIULuryGPguJN8dhwOq+oPh23KD4oZ
	 oDgG9Q7qiklC025s5e31jn5W8DZrWY3XLnKdac3TlZaKlReDu0jJF+McdlL4rZbfey
	 vio2zbz4p7HYes9E+SH0Bj1kP+VRYA2cki8/bjIo=
Date: Thu, 16 Jan 2025 10:43:40 +0200
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Daniel Stone <daniel@fooishbar.org>
Cc: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	maarten.lankhorst@linux.intel.com, mripard@kernel.org,
	airlied@gmail.com, simona@ffwll.ch, dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org, freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org, imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org, nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev, spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org,
	Andy Yan <andyshrk@163.com>
Subject: Re: [PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with
 drm_mode_size_dumb()
Message-ID: <20250116084340.GF6754@pendragon.ideasonboard.com>
References: <cdbe483d-0895-47aa-8c83-1c28220f4a02@ideasonboard.com>
 <bc97b92e-7f8a-4b92-af8a-20fa165ead55@suse.de>
 <f3ba05c7-6e49-4641-a3f9-ba418ebdb7c3@ideasonboard.com>
 <c6735280-7c32-4319-8ca9-a7305d8117c3@suse.de>
 <d67adb03-5cd0-4ac9-af58-cf4446dacee3@ideasonboard.com>
 <0ea6be58-0e04-4172-87cd-064a3e4a43bc@suse.de>
 <f35cb350-6be9-48ca-ad7e-e9dd418281d5@ideasonboard.com>
 <4af0b6a7-c16a-4187-bbf5-365a9c86de21@suse.de>
 <e327ad84-b5c9-4480-b873-dc3aca605538@ideasonboard.com>
 <CAPj87rOn=RQ615zyaEdFT2ADfPztU7+heVi0G34Rdg-=QO1cCw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CAPj87rOn=RQ615zyaEdFT2ADfPztU7+heVi0G34Rdg-=QO1cCw@mail.gmail.com>

On Wed, Jan 15, 2025 at 02:34:26PM +0000, Daniel Stone wrote:
> On Wed, 15 Jan 2025 at 14:20, Tomi Valkeinen wrote:
> > No disagreement there, we need CREATE_DUMB2.
> >
> > My point is that we have the current UAPI, and we have userspace using
> > it, but we don't have clear rules what the ioctl does with specific
> > parameters, and we don't document how it has to be used.
> >
> > Perhaps the situation is bad, and all we can really say is that
> > CREATE_DUMB only works for use with simple RGB formats, and the behavior
> > for all other formats is platform specific. But I think even that would
> > be valuable in the UAPI docs.
> 
> Yeah, CREATE_DUMB only works for use with simple RGB formats in a
> linear layout. Not monochrome or YUV or tiled or displayed rotated or
> whatever.
> 
> If it happens to accidentally work for other uses, that's fine, but
> it's not generically reliable for anything other than simple linear
> RGB. It's intended to let you do splash screens, consoles, recovery
> password entries, and software-rendered compositors if you really
> want. Anything more than that isn't 'dumb'.

We have lots of software out there that rely on CREATE_DUMB supporting
YUV linear formats, and lots of drivers (mostly on Arm I suppose) that
implement YUV support in CREATE_DUMB. I'm fine replacing it with
something better, but I think we need a standard ioctl that can create
linear YUV buffers. I've been told many times that DRM doesn't want to
standardize buffer allocation further than what CREATE_DUMB is made for.
Can we reconsider this rule then ?

-- 
Regards,

Laurent Pinchart


From xen-devel-bounces@lists.xenproject.org Thu Jan 16 08:43:55 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 08:43:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873239.1284210 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYLTl-0004mH-S6; Thu, 16 Jan 2025 08:43:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873239.1284210; Thu, 16 Jan 2025 08:43:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYLTl-0004kw-Le; Thu, 16 Jan 2025 08:43:53 +0000
Received: by outflank-mailman (input) for mailman id 873239;
 Thu, 16 Jan 2025 08:43: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
 <SRS0=8jK+=UI=casper.srs.infradead.org=BATV+cabf69696ff47aa9dee2+7816+infradead.org+dwmw2@srs-se1.protection.inumbo.net>)
 id 1tYLTj-0004BI-87
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 08:43:51 +0000
Received: from casper.infradead.org (casper.infradead.org
 [2001:8b0:10b:1236::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ff9e0e15-d3e5-11ef-a0e2-8be0dac302b0;
 Thu, 16 Jan 2025 09:43:46 +0100 (CET)
Received: from [2001:8b0:10b:1::ebe] (helo=i7.infradead.org)
 by casper.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux))
 id 1tYLTd-0000000Akbc-0hzA; Thu, 16 Jan 2025 08:43:45 +0000
Received: from dwoodhou by i7.infradead.org with local (Exim 4.98 #2 (Red Hat
 Linux)) id 1tYLTc-00000007pIP-3i2w; Thu, 16 Jan 2025 08:43:44 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
X-Inumbo-ID: ff9e0e15-d3e5-11ef-a0e2-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=Sender:Content-Transfer-Encoding:
	MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:
	Reply-To:Content-Type:Content-ID:Content-Description;
	bh=tjqHi7zeaRi1ZPcfAv+eUnMUtGpd7kq8NDwOvC3nsVk=; b=bSv6dzL1vdg3gqEa+FP0eVjouM
	j1nwqH+kRmJ+mY1u3/gaLep/NqlwSpdMpOcYt1dytUykeQJVgUuDnW4v49K4RgJNc1dx01+0jassk
	JhfKQKY5znnu+hthvlM4rlvAL7lOcloj9F/r3RlWMgiPSzFm/nh/QaAZWfD39v3o2hNz6zOeabUBz
	iOU0OF5os3V/ZMvjShsLmfv83KQ99Fhq7pJ/v1xsw+hZYc7c0qoRIKFqE2/q5yXXsUWMrvUMsP4l4
	VDN+WWnfDRy1TysjP3lpzq4ulph49cnnjXzdy+j4ZY6W56keXvTz9FkFo8EXnhsclB1dGNdfwLaZO
	I9gZjIXw==;
From: David Woodhouse <dwmw2@infradead.org>
To: Stefan Hajnoczi <stefanha@redhat.com>,
	qemu-devel@nongnu.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Kevin Wolf <kwolf@redhat.com>,
	Hanna Reitz <hreitz@redhat.com>,
	=?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= <marcandre.lureau@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	xen-devel@lists.xenproject.org,
	qemu-block@nongnu.org,
	Phil Dennis-Jordan <phil@philjordan.eu>,
	David Woodhouse <dwmw@amazon.co.uk>
Subject: [PULL 8/8] system/runstate: Fix regression, clarify BQL status of exit notifiers
Date: Thu, 16 Jan 2025 08:43:32 +0000
Message-ID: <20250116084332.1864967-9-dwmw2@infradead.org>
X-Mailer: git-send-email 2.47.0
In-Reply-To: <20250116084332.1864967-1-dwmw2@infradead.org>
References: <20250116084332.1864967-1-dwmw2@infradead.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: David Woodhouse <dwmw2@infradead.org>
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html

From: Phil Dennis-Jordan <phil@philjordan.eu>

By changing the way the main QEMU event loop is invoked, I inadvertently
changed the BQL status of exit notifiers: some of them implicitly
assumed they would be called with the BQL held; the BQL is however
not held during the exit(status) call in qemu_default_main().

Instead of attempting to ensuring we always call exit() from the BQL -
including any transitive calls - this change adds a BQL lock guard to
qemu_run_exit_notifiers, ensuring the BQL will always be held in the
exit notifiers.

Additionally, the BQL promise is now documented at the
qemu_{add,remove}_exit_notifier() declarations.

Fixes: f5ab12caba4f ("ui & main loop: Redesign of system-specific main
thread event handling")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2771
Reported-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu>
Tested-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
 include/system/system.h | 1 +
 system/runstate.c       | 1 +
 2 files changed, 2 insertions(+)

diff --git a/include/system/system.h b/include/system/system.h
index 5364ad4f27..0cbb43ec30 100644
--- a/include/system/system.h
+++ b/include/system/system.h
@@ -15,6 +15,7 @@ extern bool qemu_uuid_set;
 
 const char *qemu_get_vm_name(void);
 
+/* Exit notifiers will run with BQL held. */
 void qemu_add_exit_notifier(Notifier *notify);
 void qemu_remove_exit_notifier(Notifier *notify);
 
diff --git a/system/runstate.c b/system/runstate.c
index 3a8fe866bc..272801d307 100644
--- a/system/runstate.c
+++ b/system/runstate.c
@@ -850,6 +850,7 @@ void qemu_remove_exit_notifier(Notifier *notify)
 
 static void qemu_run_exit_notifiers(void)
 {
+    BQL_LOCK_GUARD();
     notifier_list_notify(&exit_notifiers, NULL);
 }
 
-- 
2.47.0



From xen-devel-bounces@lists.xenproject.org Thu Jan 16 08:43:55 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 08:43:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873237.1284196 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYLTk-0004St-Vj; Thu, 16 Jan 2025 08:43:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873237.1284196; Thu, 16 Jan 2025 08:43:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYLTk-0004QW-P5; Thu, 16 Jan 2025 08:43:52 +0000
Received: by outflank-mailman (input) for mailman id 873237;
 Thu, 16 Jan 2025 08:43: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
 <SRS0=8jK+=UI=casper.srs.infradead.org=BATV+cabf69696ff47aa9dee2+7816+infradead.org+dwmw2@srs-se1.protection.inumbo.net>)
 id 1tYLTi-0004BI-Ex
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 08:43:50 +0000
Received: from casper.infradead.org (casper.infradead.org
 [2001:8b0:10b:1236::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ff9d8e86-d3e5-11ef-a0e2-8be0dac302b0;
 Thu, 16 Jan 2025 09:43:46 +0100 (CET)
Received: from [2001:8b0:10b:1::ebe] (helo=i7.infradead.org)
 by casper.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux))
 id 1tYLTd-0000000AkbV-0JOu; Thu, 16 Jan 2025 08:43:45 +0000
Received: from dwoodhou by i7.infradead.org with local (Exim 4.98 #2 (Red Hat
 Linux)) id 1tYLTc-00000007pI8-3Dc0; Thu, 16 Jan 2025 08:43:44 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
X-Inumbo-ID: ff9d8e86-d3e5-11ef-a0e2-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=Sender:Content-Transfer-Encoding:
	Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:
	To:From:Reply-To:Content-ID:Content-Description;
	bh=9YnMqT9L5zpcIdMPGD+T5rZV+9M0PECfN24dS3f5adI=; b=QAhTn+9luHDcx4ZBpcWeH90OPD
	kUrxeCoetP1gumKPKrYKI0tOm+chuyObKhh8XsUWhf15Snreba/gTrp9g4OmorKfNLsrOLHPEUpWP
	PQ+WEsNZikrHtjPm+i/8KmuA1lmh2mEXDeBieo3/4G2hhT/FN+eykSgP6+rjuBL2ftHX8UAtx8ih5
	Bfcijh2bcxhKSL53SrxjdJIdyfwH/zccZnOt15oaxu+YZqIvHSP3CQoRNquwqLGot4MaBi9TKU+2A
	Uuz7NHdmOX8hnCLRLt6l7tmi54R1Ra25u9P6DxwUasWLonC7win3ViRVG9hZPpALXtbzuGHC9Y1cH
	T3091e/A==;
From: David Woodhouse <dwmw2@infradead.org>
To: Stefan Hajnoczi <stefanha@redhat.com>,
	qemu-devel@nongnu.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Kevin Wolf <kwolf@redhat.com>,
	Hanna Reitz <hreitz@redhat.com>,
	=?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= <marcandre.lureau@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	xen-devel@lists.xenproject.org,
	qemu-block@nongnu.org,
	Phil Dennis-Jordan <phil@philjordan.eu>,
	David Woodhouse <dwmw@amazon.co.uk>,
	Anthony PERARD <anthony.perard@vates.tech>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PULL 6/8] hw/xen: Use xs_node_read() from xenstore_read_str() instead of open-coding it
Date: Thu, 16 Jan 2025 08:43:30 +0000
Message-ID: <20250116084332.1864967-7-dwmw2@infradead.org>
X-Mailer: git-send-email 2.47.0
In-Reply-To: <20250116084332.1864967-1-dwmw2@infradead.org>
References: <20250116084332.1864967-1-dwmw2@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Sender: David Woodhouse <dwmw2@infradead.org>
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html

From: David Woodhouse <dwmw@amazon.co.uk>

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
---
 hw/xen/xen_pvdev.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/hw/xen/xen_pvdev.c b/hw/xen/xen_pvdev.c
index c5ad71e8dc..c9143ba259 100644
--- a/hw/xen/xen_pvdev.c
+++ b/hw/xen/xen_pvdev.c
@@ -22,6 +22,7 @@
 #include "qemu/main-loop.h"
 #include "hw/qdev-core.h"
 #include "hw/xen/xen-legacy-backend.h"
+#include "hw/xen/xen-bus-helper.h"
 #include "hw/xen/xen_pvdev.h"
 
 /* private */
@@ -81,12 +82,9 @@ int xenstore_write_str(const char *base, const char *node, const char *val)
 
 char *xenstore_read_str(const char *base, const char *node)
 {
-    char abspath[XEN_BUFSIZE];
-    unsigned int len;
     char *str, *ret = NULL;
 
-    snprintf(abspath, sizeof(abspath), "%s/%s", base, node);
-    str = qemu_xen_xs_read(xenstore, 0, abspath, &len);
+    str = xs_node_read(xenstore, 0, NULL, NULL, "%s/%s", base, node);
     if (str != NULL) {
         /* move to qemu-allocated memory to make sure
          * callers can safely g_free() stuff. */
-- 
2.47.0



From xen-devel-bounces@lists.xenproject.org Thu Jan 16 08:43:56 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 08:43:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873241.1284230 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYLTn-00057G-1J; Thu, 16 Jan 2025 08:43:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873241.1284230; Thu, 16 Jan 2025 08:43:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYLTm-00055X-I3; Thu, 16 Jan 2025 08:43:54 +0000
Received: by outflank-mailman (input) for mailman id 873241;
 Thu, 16 Jan 2025 08:43:52 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=8jK+=UI=casper.srs.infradead.org=BATV+cabf69696ff47aa9dee2+7816+infradead.org+dwmw2@srs-se1.protection.inumbo.net>)
 id 1tYLTk-0004BJ-81
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 08:43:52 +0000
Received: from casper.infradead.org (casper.infradead.org
 [2001:8b0:10b:1236::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ff7906a6-d3e5-11ef-99a4-01e77a169b0f;
 Thu, 16 Jan 2025 09:43:47 +0100 (CET)
Received: from [2001:8b0:10b:1::ebe] (helo=i7.infradead.org)
 by casper.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux))
 id 1tYLTd-0000000AkbP-02Qr; Thu, 16 Jan 2025 08:43:45 +0000
Received: from dwoodhou by i7.infradead.org with local (Exim 4.98 #2 (Red Hat
 Linux)) id 1tYLTc-00000007pI3-2yCA; Thu, 16 Jan 2025 08:43:44 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
X-Inumbo-ID: ff7906a6-d3e5-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=Sender:Content-Transfer-Encoding:
	Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:
	To:From:Reply-To:Content-ID:Content-Description;
	bh=ZBKlQ7iGXowmo3aHS0zEEFjY8wis7AgQV7Ky19BXiPo=; b=YbwhsJicNuvRKaM7mZLvcVWK6x
	WiVFjSENH4z5Pkik/TbbBGKMRfokc5n3AnYla8b8TFya79gei5DGXoFPyNtEYDuoSbPEvASAzUe7s
	/Okku4GLLdh7ZIL8/95IXpTsU/ufviN5uegG73LLfNVBGmmo9yc08EgZA/7pCEqFQVNkHvfd1eaAT
	uMcjr7k3BZPtzBzzpGoQsPxEIArLFfbtmXn+/6XPkKmtZ8YokNBXePazZ5GcK744aKhRDmDrlbUl/
	9xSpFhIshTG4A/stggqsUQoqVTd1+in6ftZfGoH5NjzvWbDV4Q4x7VbLT7Vo0voq4syaI0/+Emwej
	65f7SNhg==;
From: David Woodhouse <dwmw2@infradead.org>
To: Stefan Hajnoczi <stefanha@redhat.com>,
	qemu-devel@nongnu.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Kevin Wolf <kwolf@redhat.com>,
	Hanna Reitz <hreitz@redhat.com>,
	=?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= <marcandre.lureau@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	xen-devel@lists.xenproject.org,
	qemu-block@nongnu.org,
	Phil Dennis-Jordan <phil@philjordan.eu>,
	David Woodhouse <dwmw@amazon.co.uk>,
	Anthony PERARD <anthony.perard@vates.tech>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PULL 5/8] hw/xen: Use xs_node_read() from xen_netdev_get_name()
Date: Thu, 16 Jan 2025 08:43:29 +0000
Message-ID: <20250116084332.1864967-6-dwmw2@infradead.org>
X-Mailer: git-send-email 2.47.0
In-Reply-To: <20250116084332.1864967-1-dwmw2@infradead.org>
References: <20250116084332.1864967-1-dwmw2@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Sender: David Woodhouse <dwmw2@infradead.org>
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html

From: David Woodhouse <dwmw@amazon.co.uk>

Now that xs_node_read() can construct a node path, no need to open-code it.

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
---
 hw/net/xen_nic.c | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/hw/net/xen_nic.c b/hw/net/xen_nic.c
index 97ebd9fa30..5410039490 100644
--- a/hw/net/xen_nic.c
+++ b/hw/net/xen_nic.c
@@ -510,23 +510,22 @@ static char *xen_netdev_get_name(XenDevice *xendev, Error **errp)
 
     if (netdev->dev == -1) {
         XenBus *xenbus = XEN_BUS(qdev_get_parent_bus(DEVICE(xendev)));
-        char fe_path[XENSTORE_ABS_PATH_MAX + 1];
         int idx = (xen_mode == XEN_EMULATE) ? 0 : 1;
+        Error *local_err = NULL;
         char *value;
 
         /* Theoretically we could go up to INT_MAX here but that's overkill */
         while (idx < 100) {
-            snprintf(fe_path, sizeof(fe_path),
-                     "/local/domain/%u/device/vif/%u",
-                     xendev->frontend_id, idx);
-            value = qemu_xen_xs_read(xenbus->xsh, XBT_NULL, fe_path, NULL);
+            value = xs_node_read(xenbus->xsh, XBT_NULL, NULL, &local_err,
+                                 "/local/domain/%u/device/vif/%u",
+                                 xendev->frontend_id, idx);
             if (!value) {
                 if (errno == ENOENT) {
                     netdev->dev = idx;
+                    error_free(local_err);
                     goto found;
                 }
-                error_setg(errp, "cannot read %s: %s", fe_path,
-                           strerror(errno));
+                error_propagate(errp, local_err);
                 return NULL;
             }
             free(value);
-- 
2.47.0



From xen-devel-bounces@lists.xenproject.org Thu Jan 16 08:43:56 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 08:43:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873243.1284247 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYLTo-0005Xn-8c; Thu, 16 Jan 2025 08:43:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873243.1284247; Thu, 16 Jan 2025 08:43:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYLTn-0005VY-Pn; Thu, 16 Jan 2025 08:43:55 +0000
Received: by outflank-mailman (input) for mailman id 873243;
 Thu, 16 Jan 2025 08:43:53 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=SegZ=UI=desiato.srs.infradead.org=BATV+b63efa7a8ebec188a7bb+7816+infradead.org+dwmw2@srs-se1.protection.inumbo.net>)
 id 1tYLTl-0004BI-8i
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 08:43:53 +0000
Received: from desiato.infradead.org (desiato.infradead.org
 [2001:8b0:10b:1:d65d:64ff:fe57:4e05])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 00b8a977-d3e6-11ef-a0e2-8be0dac302b0;
 Thu, 16 Jan 2025 09:43:49 +0100 (CET)
Received: from [2001:8b0:10b:1::ebe] (helo=i7.infradead.org)
 by desiato.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux))
 id 1tYLTe-0000000B1PZ-02zV; Thu, 16 Jan 2025 08:43:46 +0000
Received: from dwoodhou by i7.infradead.org with local (Exim 4.98 #2 (Red Hat
 Linux)) id 1tYLTc-00000007pHU-1vM7; Thu, 16 Jan 2025 08:43:44 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
X-Inumbo-ID: 00b8a977-d3e6-11ef-a0e2-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding:
	Content-Type:MIME-Version:Message-ID:Date:Subject:Cc:To:From:Reply-To:
	Content-ID:Content-Description:In-Reply-To:References;
	bh=cRHcaJ8qr8tMPnLKEmxRjL10dz3nijScrW9hqSSprGI=; b=a0JdykAwXTVMSDZdFhhN4Z7cfQ
	+hkqZYOFUzj70KfuL/shYChBrPpS9OMTKdQKym7SM9hE75EgIt1beZsZ0VBiTWMBI1q73n2/jeldh
	vAyBP6Ntre/VpAlcAU3eiPuyy5qA+jQDwXdNq9JuAEyohhdwg3ByFzsHqoGk9rO54aFoxmtz2SyuI
	u871I5zV6ZqIPcS/EyGJfbpuJvQy+1ZQOdWvTJ9iELFBkqicl4xAcN3C2b9ooQu696jWtHhpgL56+
	xGUEtMxgXnjleq3ScpuIxnmoVy21iSD4zLs19jrJgW9gRgdLYTZj9x6/4z7LYj1Lhz0ANBOHl2keZ
	915QaGmQ==;
From: David Woodhouse <dwmw2@infradead.org>
To: Stefan Hajnoczi <stefanha@redhat.com>,
	qemu-devel@nongnu.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Kevin Wolf <kwolf@redhat.com>,
	Hanna Reitz <hreitz@redhat.com>,
	=?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= <marcandre.lureau@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	xen-devel@lists.xenproject.org,
	qemu-block@nongnu.org,
	Phil Dennis-Jordan <phil@philjordan.eu>,
	David Woodhouse <dwmw@amazon.co.uk>
Subject: [PULL 0/8] Xen regression fixes and cleanups
Date: Thu, 16 Jan 2025 08:43:24 +0000
Message-ID: <20250116084332.1864967-1-dwmw2@infradead.org>
X-Mailer: git-send-email 2.47.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Sender: David Woodhouse <dwmw2@infradead.org>
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by desiato.infradead.org. See http://www.infradead.org/rpr.html

From: David Woodhouse <dwmw@amazon.co.uk>

The following changes since commit 7433709a147706ad7d1956b15669279933d0f82b:

  Merge tag 'hw-misc-20250113' of https://github.com/philmd/qemu into staging (2025-01-14 12:46:56 -0500)

are available in the Git repository at:

  git://git.infradead.org/users/dwmw2/qemu.git tags/pull-xenfv-20250116

for you to fetch changes up to e7bc0204e57836b3df611b73d2decc56ed698c4a:

  system/runstate: Fix regression, clarify BQL status of exit notifiers (2025-01-15 18:05:19 +0000)

----------------------------------------------------------------
Xen regression fixes and cleanups

----------------------------------------------------------------
David Woodhouse (6):
      hw/xen: Add xs_node_read() helper function
      hw/xen: Use xs_node_read() from xs_node_vscanf()
      hw/xen: Use xs_node_read() from xen_console_get_name()
      hw/xen: Use xs_node_read() from xen_netdev_get_name()
      hw/xen: Use xs_node_read() from xenstore_read_str() instead of open-coding it
      hw/xen: Fix errp handling in xen_console

Phil Dennis-Jordan (1):
      system/runstate: Fix regression, clarify BQL status of exit notifiers

Roger Pau Monné (1):
      xen: do not use '%ms' scanf specifier

 hw/block/xen-block.c            |  3 ++-
 hw/char/xen_console.c           | 56 ++++++++++++++++++++++++-----------------
 hw/net/xen_nic.c                | 13 +++++-----
 hw/xen/trace-events             |  2 +-
 hw/xen/xen-bus-helper.c         | 37 ++++++++++++++++++++-------
 hw/xen/xen-bus.c                | 14 +++++++++--
 hw/xen/xen_pvdev.c              |  6 ++---
 include/hw/xen/xen-bus-helper.h |  9 +++++++
 include/hw/xen/xen-bus.h        |  1 +
 include/system/system.h         |  1 +
 system/runstate.c               |  1 +
 11 files changed, 96 insertions(+), 47 deletions(-)


From xen-devel-bounces@lists.xenproject.org Thu Jan 16 08:51:33 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 08:51:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873334.1284293 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYLb7-0003IK-F9; Thu, 16 Jan 2025 08:51:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873334.1284293; Thu, 16 Jan 2025 08:51:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYLb7-0003ID-CO; Thu, 16 Jan 2025 08:51:29 +0000
Received: by outflank-mailman (input) for mailman id 873334;
 Thu, 16 Jan 2025 08:51:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=oQTT=UI=ventanamicro.com=ajones@srs-se1.protection.inumbo.net>)
 id 1tYLb5-0003I7-Ve
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 08:51:28 +0000
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com
 [2a00:1450:4864:20::434])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 12319c9a-d3e7-11ef-a0e2-8be0dac302b0;
 Thu, 16 Jan 2025 09:51:26 +0100 (CET)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-38637614567so324350f8f.3
 for <xen-devel@lists.xenproject.org>; Thu, 16 Jan 2025 00:51:26 -0800 (PST)
Received: from localhost (2001-1ae9-1c2-4c00-20f-c6b4-1e57-7965.ip6.tmcz.cz.
 [2001:1ae9:1c2:4c00:20f:c6b4:1e57:7965])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a8e4c3428sm19402764f8f.87.2025.01.16.00.51.25
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 16 Jan 2025 00:51:25 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 12319c9a-d3e7-11ef-a0e2-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=ventanamicro.com; s=google; t=1737017486; x=1737622286; 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=vdYGACSqmD06pBhAeXOqTAZ8uvEoU3CDJANNyc9PH5I=;
        b=jBMgE8kWWFrRlmsPe0saWqUMRYedVc5KxBS70Ce6sKRkrvHiLDD6yY17ndN7ruFPmT
         7YRENDkwuAJKOr7E4NtRGyhDmmD4h+cN3PgzpwP+rc18ObNHaoa8B0dFjIJizHVp2bvC
         vkJqF4EenFchglQ1+LX4tnMQQsJ74FqsDOHyJcnGzMMPVt55ogiWU9clm/dGxpYMru4I
         hNNOxFGFyj5NvYiELUbvtAQ8oC/PrtEJ5+1YXGFcE7dE9iH09tqGyWliBSKVygOGsZNv
         hoUB/yD72xmSd4IoW02jLYpNEJWVlU0MVaPJRgLcLJxRNtTP08sDEBRSObrsRE4+Vbzg
         2ibQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737017486; x=1737622286;
        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=vdYGACSqmD06pBhAeXOqTAZ8uvEoU3CDJANNyc9PH5I=;
        b=dy+LBKlwa1i0QpDx15W16iakYi2+Hl25BCEIX3Z8IVPABUlrFLrJBxffB8PS3oj9Sp
         b0oBY7U4BUdqMgZVfecxEEBxYcs3IpfgpRJnUgowfV2snLkIAw9fmxw3S2gVCcpxjNgR
         s4KTMhR2B0FASK8dx143S6cJT4drv+tJZZgUAQ13REpLzyBF1ThCBuQtMD35mE8rzCRP
         F81virNTe3lswQ3uWkCOn+puksDK3UGW+Q1zzQbuk1t6miJqFTogX06xwluvfy7cSBn+
         sc+/anVcWYZCZ3JtqjKQYssqrlmTtMure9N2hIKFGrXgtAvzp/7+QEPtj73T0qp88gam
         pcrA==
X-Forwarded-Encrypted: i=1; AJvYcCXyLNZTE7Zz0+0E2ki0k4yGBXohvOw4pzKtrzj21lNhzfRwnPq1fsxbNNHcdaRZwAgdCXs8l13RkSk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzyBLroQ7XkotKtwhLS672QJW2y9mSQQSNJ+uIRyJTTsl4zIKHY
	1v9cOab/K4lIgoeE/D2LAvPdZaHt/ld/I4UOVl3Zbmcp60g51UbYC7Mj48WpQAk=
X-Gm-Gg: ASbGncs+clIxJHGrkBVF168OrCcAhr8vcj8fiiIF+Enwo2ag8jzKig6wVm8i4Wqe3p3
	B47JWM+hFv5a9Ph+9hYZhHtMzotUafCG19bPakye9LZ2Ibi6xgeBh63uoZ14tlo54Yibnconjow
	89xgeTAB5DVe9BGtpd1FphAFGs48t7Aj+lkZ+zrBOEkBhYmBNt70IbvgvFQ4fFV52gWHyFKO4Zn
	8UaBn4GFpQQpQ8Vzms2UO1zRLqyHeAzEwn3ij/fSgRS6JSZbHQmUWfB1pvdHqpmGIfcjJF/Ll5H
	ZZysPMAkO+/MbTIue+WwTsh5OsqucLlE6AmGqqLebA==
X-Google-Smtp-Source: AGHT+IEsbulHh7PZVHSAEnmDh38IVvfobmbwOpTAusRtk5MN3iwIfCnGsZ4ArTaC23pmkWtqt4FHJQ==
X-Received: by 2002:a5d:47c4:0:b0:385:ed16:c8b with SMTP id ffacd0b85a97d-38a87309d21mr11955948f8f.23.1737017486382;
        Thu, 16 Jan 2025 00:51:26 -0800 (PST)
Date: Thu, 16 Jan 2025 09:51:25 +0100
From: Andrew Jones <ajones@ventanamicro.com>
To: Milan =?utf-8?B?xJBva2nEhw==?= <milandjokic1995@gmail.com>
Cc: linux-riscv@lists.infradead.org, jgross@suse.com, 
	aou@eecs.berkeley.edu, Milan.Djokic@rt-rk.com, rafael.j.wysocki@intel.com, 
	linux-kernel@vger.kernel.org, oleksandr_tyshchenko@epam.com, iommu@lists.linux.dev, 
	sstabellini@kernel.org, palmer@dabbelt.com, paul.walmsley@sifive.com, 
	xen-devel@lists.xenproject.org, Slavisa.Petrovic@rt-rk.com, takakura@valinux.co.jp
Subject: Re: [PATCH] riscv: Add initial Xen guest support for RISC-V
Message-ID: <20250116-aa9eadde9279e66dbc01c705@orel>
References: <e4a649a7fdfc8fcf5f48a0bc4e76e5d546078083.1736868605.git.Slavisa.Petrovic@rt-rk.com>
 <20250114-316084c962eb867c0b681043@orel>
 <CAKp59VFkW8F2xHsgAxiw138ZrpQJL8R5cTkF8f9vY40iEoRbWg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAKp59VFkW8F2xHsgAxiw138ZrpQJL8R5cTkF8f9vY40iEoRbWg@mail.gmail.com>

On Wed, Jan 15, 2025 at 08:04:05PM +0100, Milan Đokić wrote:
> Hello Andrew,
> 
> On Tue, Jan 14, 2025 at 7:18 PM Andrew Jones <ajones@ventanamicro.com> wrote:
> >
> > On Tue, Jan 14, 2025 at 05:09:36PM +0100, Milan Djokic wrote:
...
> > > +++ b/arch/riscv/xen/hypercall.S
> > > @@ -0,0 +1,71 @@
> > > +/* SPDX-License-Identifier: GPL-2.0 */
> > > +#include <linux/linkage.h>
> > > +#include <asm/assembler.h>
> > > +#include <xen/interface/xen.h>
> > > +EXPORT_SYMBOL_GPL(HYPERVISOR_event_channel_op);
> > > +EXPORT_SYMBOL_GPL(HYPERVISOR_grant_table_op);
> > > +EXPORT_SYMBOL_GPL(HYPERVISOR_xen_version);
> > > +EXPORT_SYMBOL_GPL(HYPERVISOR_console_io);
> > > +EXPORT_SYMBOL_GPL(HYPERVISOR_sched_op);
> > > +EXPORT_SYMBOL_GPL(HYPERVISOR_hvm_op);
> > > +EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
> > > +EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
> > > +EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
> > > +EXPORT_SYMBOL_GPL(HYPERVISOR_platform_op_raw);
> > > +EXPORT_SYMBOL_GPL(HYPERVISOR_multicall);
> > > +EXPORT_SYMBOL_GPL(HYPERVISOR_vm_assist);
> > > +EXPORT_SYMBOL_GPL(HYPERVISOR_dm_op);
> > > +EXPORT_SYMBOL_GPL(privcmd_call);
> > > +#define SBI_ECALL 0xE
> >
> > Shouldn't this be 0xA000007, i.e. the SBI firmware specific extension
> > for Xen. Otherwise why refer to SBI? Note, '0xE' is an invalid, legacy
> > extension ID in SBI.
> >
> Hypercall is triggered through SBI and we defined 0xE just as an
> SBI_ECALL ID on Xen side for hypercall handling (among other operation
> IDs), so we're not referring to some standard /legacy ID here, just
> utilizing SBI for hypercall handling.

If the SBI specified EIDs and binary encoding aren't used, then the
hypercalls aren't "triggered through SBI", Xen is just doing its own
thing on an ecall. Xen doesn't have to implement SBI at all, but if
it wants to provide SBI services, as well as its own hypercalls, then
the hypercalls should be encoded in the same way as SBI functions and
an EID allowed by the SBI specification for hypervisor-specific
functions should be used. For Xen, that EID is already specified and
it's 0xA000007.

> Is this specific ID (0xE) not allowed to be used on the kernel side
> for some reason? If that is the case, we can use any other ID,
> including the one which you suggested.
>

Linux can use any ID, and Xen can decide what that ID is, but, if Xen
wants to implement SBI, then Xen can't use 0xE, because that EID is
not allowed by the spec for the purpose of hypercalls.

Thanks,
drew


From xen-devel-bounces@lists.xenproject.org Thu Jan 16 08:59:06 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 08:59:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873343.1284302 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYLiP-0003uz-4x; Thu, 16 Jan 2025 08:59:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873343.1284302; Thu, 16 Jan 2025 08:59:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYLiP-0003us-1n; Thu, 16 Jan 2025 08:59:01 +0000
Received: by outflank-mailman (input) for mailman id 873343;
 Thu, 16 Jan 2025 08:59:00 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=PV9y=UI=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tYLiO-0003um-MQ
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 08:59:00 +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 1f4540b1-d3e8-11ef-99a4-01e77a169b0f;
 Thu, 16 Jan 2025 09:58:58 +0100 (CET)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-43618283d48so3541045e9.1
 for <xen-devel@lists.xenproject.org>; Thu, 16 Jan 2025 00:58:58 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a8e384054sm19942478f8f.36.2025.01.16.00.58.56
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 16 Jan 2025 00:58:56 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1f4540b1-d3e8-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737017937; x=1737622737; 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=X3QCn3jOgn/JvfbmhCVngGXb1tZ7Fz8blJiUHxCaYbk=;
        b=P/yMbAvMfskrO6r42lYODW5HGp1OoN8l9Qkxqhe0ZzI0DjP3rRuSrgQmhuhcFNNhh8
         AKbWkCPvVO1Y7IHtUF6BOjSnPcLVfi7+hol6leqmte/tumu0JZ22p2TcTyXBtRFbeILJ
         Fivj1IIzBvc76EAALe0offRqXxSH/hpkLgy3w=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737017937; x=1737622737;
        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=X3QCn3jOgn/JvfbmhCVngGXb1tZ7Fz8blJiUHxCaYbk=;
        b=MiwHxSnoHiw9Cv4rVskmQBsjSJ1z2ffPc7Bk2PDQZL6BX4+raKgLXLp+ZBl9MNIOc1
         sV+ecuZNpMDJFOC6BWYGIZ+LvEwm0TNm33akobEBZLSmtToVPEQif7or56rN/3GnqzaX
         p7FjTfieJuDQDtQN5BSvT8Gj1IHIGH+/cjvITCAMFICYzvr56I3Plg7B/FhBUC7akZ1U
         wbe8bWFCaFd6G+0p+1LsldunORc6LzjWYKANhyR3BlUz03bycm6aDceF1dOn96jh2MEP
         qRKiL7Al1+U6KCdCKJbsGCDEif2Iz2pK55jdQm0pY0eFmkjSyp+9vV5bsc5Eev/sooCG
         OEkw==
X-Gm-Message-State: AOJu0Yyk1CtNTXcbdKXjt3H+GLciDeu6OXc9pLHtgm/XRMm7fe15LjY6
	ndaER+2eFqEKkdB1cX8rGJjHj0UN0xGIZNwQP7uKmIvhsHUSnDRe7puYaQDPbXrE36TTIlra557
	W
X-Gm-Gg: ASbGncv43epOtrhR4MUyWaUhAFRhjZEnsrLPPmDxYuvI89AIgXTHyynPJRho1AWr0sx
	eYRfpbMClofnqI70hi2yZ15FR08A4qcXurn/f7Gfd1Jab9MniF+gOfCLwllwkxM2FRMkMlZc4I4
	cr9hCLBwGuKqbEAG+ylM4m+N0yQtKES1K1ZDNIqUNDOv8oDGP0FNeXZm3/nMt1BlJm4FdT5Yxi4
	GwCxbWUgkoGbNIf8J1PYUuJ95TREruBYQhUcwdl2FKI+emYFZRs7TX9FRWdEbSrdEI=
X-Google-Smtp-Source: AGHT+IEFf6bLRJ5IOz2NyFKmkR9yiutCHHyj93HGEM9ATj7GP3hPmZmCKqizb9HCNAnQK7hoa0bfbQ==
X-Received: by 2002:a05:600c:1e0b:b0:431:5044:e388 with SMTP id 5b1f17b1804b1-436e26e4c61mr265211845e9.22.1737017937230;
        Thu, 16 Jan 2025 00:58:57 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH for-4.20 1/2] automation/cirrus-ci: update FreeBSD to 13.4
Date: Thu, 16 Jan 2025 09:58:50 +0100
Message-ID: <20250116085852.78273-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 .cirrus.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.cirrus.yml b/.cirrus.yml
index 4a120fad41b2..ee80152890f2 100644
--- a/.cirrus.yml
+++ b/.cirrus.yml
@@ -18,7 +18,7 @@ freebsd_template: &FREEBSD_TEMPLATE
 task:
   name: 'FreeBSD 13'
   freebsd_instance:
-    image_family: freebsd-13-3
+    image_family: freebsd-13-4
   << : *FREEBSD_TEMPLATE
 
 task:
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Thu Jan 16 08:59:06 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 08:59:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873344.1284313 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYLiQ-00049L-Di; Thu, 16 Jan 2025 08:59:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873344.1284313; Thu, 16 Jan 2025 08:59:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYLiQ-00049E-8y; Thu, 16 Jan 2025 08:59:02 +0000
Received: by outflank-mailman (input) for mailman id 873344;
 Thu, 16 Jan 2025 08:59: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
 <SRS0=PV9y=UI=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tYLiP-0003um-Ic
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 08:59:01 +0000
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com
 [2a00:1450:4864:20::435])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2014eea3-d3e8-11ef-99a4-01e77a169b0f;
 Thu, 16 Jan 2025 09:58:59 +0100 (CET)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-385d7b4da2bso594853f8f.1
 for <xen-devel@lists.xenproject.org>; Thu, 16 Jan 2025 00:59:00 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a8e383882sm20023637f8f.34.2025.01.16.00.58.57
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 16 Jan 2025 00:58:58 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2014eea3-d3e8-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737017939; x=1737622739; 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=fWuBh6NbZj0G7Aav5UDhxeeK6hgEHL+iGW447R+C6nc=;
        b=SyvRILaMg0F7QeQTsDyPFLXfj2h8xQ1JcKHFBNAXB7Gxtrc1TYSF+nCFhoNMN+sfPh
         3wUGSWfcdKMcN6wfD7CX3jA//zHUeuGFD1WYkB4bbC20Ts45BF60wssfCzkSnVcst5bu
         cvBPs9ChRJ0QglBA2Uyk07ET/wHKL6qeqvDPU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737017939; x=1737622739;
        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=fWuBh6NbZj0G7Aav5UDhxeeK6hgEHL+iGW447R+C6nc=;
        b=cw0gr4E6WH1R/5h96r9EeeVYAnQiG+et6TNeP83Wydxu7oh/bvTieHpYiyx0i0GyWn
         udU7dQugDzCdaON7mxVLGEwMll2PnE3fZYKohzDqhNGF09UtYpyahJoP55E4BqZjb9Qt
         z+QHUMl8+jhHY/4ugo1CXZZ0I7sKjsiX/4V2ZTb9W0Wu41KNSVubDPJAGP1rBj1e1wsk
         sOoAVtPT7/iY713e0VkHFvWTuxlBQgXCva0PFqJyKkg985RsnBiMH2qZ8DKF8LjQ0mlV
         2b3EdyckpVNscykvSSWS7QGCSzgssz3gO+NTs1FucF2q+Xa5AMJwAIyJ0LNnDtjhIPvB
         7uMQ==
X-Gm-Message-State: AOJu0Yz5oIMR88ewO2uFGaOtPGWkstcGQkk+YpRLvov/goaAxEI1oXdm
	QDIyALlByALJfl4tokln/gq5o0TD2K43AkwBpZUWpxerWse4ObGJmCR2chlV/lGPL4iguknNjaj
	6
X-Gm-Gg: ASbGncsD/GktMF2yVxq42OLpJRMtwk8SmhmmSkTaoq4O4BJxPGafXVavtd46LcKwFH0
	7Y6vebW0GkT4iTKa2nys0pblP5/fYiF3nAflDaQ4pFdztSg5SiZGtzPrtKYv91t4TFFg3Cdm1O9
	741lU/1pPZjB+gPVUxyA7sGsFozlgF1cuN7gOEYXeQct2A4MW5T0HturinLXu5fJPPp0I+c3Er1
	ivZeGYMrUX/SneT6lErlDL0mtee8c8pO0P4F0qbAZLQBu/49EC/BCDYiDGatqFLZzs=
X-Google-Smtp-Source: AGHT+IF4+4FlyXkEnXHTctrloTCmtrIYFnJLn9eEyputKWuDkHbUuyqvN0VEVtIOoYCqt1X0VCwIFw==
X-Received: by 2002:a5d:47c9:0:b0:385:f66a:4271 with SMTP id ffacd0b85a97d-38a872fbcefmr23189409f8f.4.1737017938641;
        Thu, 16 Jan 2025 00:58:58 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH for-4.20 2/2] automation/cirrus-ci: introduce FreeBSD randconfig builds
Date: Thu, 16 Jan 2025 09:58:51 +0100
Message-ID: <20250116085852.78273-2-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250116085852.78273-1-roger.pau@citrix.com>
References: <20250116085852.78273-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Add a new randconfig job for each FreeBSD version.  This requires some
rework of the template so common parts can be shared between the full and
the randconfig builds.  Such randconfig builds are relevant because FreeBSD
is the only tested system that has a full non-GNU toolchain.

While there remove the stale `python` package install in the full build
case: this is no longer needed if `python311` is also specified.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 .cirrus.yml | 64 +++++++++++++++++++++++++++++++++++++++++------------
 1 file changed, 50 insertions(+), 14 deletions(-)

diff --git a/.cirrus.yml b/.cirrus.yml
index ee80152890f2..f3ea29102cbf 100644
--- a/.cirrus.yml
+++ b/.cirrus.yml
@@ -1,11 +1,24 @@
 # https://cirrus-ci.org/guide/tips-and-tricks/#sharing-configuration-between-tasks
-freebsd_template: &FREEBSD_TEMPLATE
+freebsd_13: &FREEBSD_13
+  freebsd_instance:
+    image_family: freebsd-13-4
+freebsd_14: &FREEBSD_14
+  freebsd_instance:
+    image_family: freebsd-14-2
+freebsd_15: &FREEBSD_15
+  freebsd_instance:
+    image_family: freebsd-15-0-snap
+
+freebsd_template: &FREEBSD_ENV
   environment:
     APPEND_LIB: /usr/local/lib
     APPEND_INCLUDES: /usr/local/include
 
+freebsd_full_build_template: &FREEBSD_FULL_BUILD_TEMPLATE
+  << : *FREEBSD_ENV
+
   install_script: pkg install -y seabios gmake ninja bash
-                                 pkgconf python bison perl5
+                                 pkgconf bison perl5
                                  yajl lzo2 pixman argp-standalone
                                  libxml2 glib git python311
 
@@ -15,20 +28,43 @@ freebsd_template: &FREEBSD_TEMPLATE
     - ./configure --with-system-seabios=/usr/local/share/seabios/bios.bin
     - gmake -j`sysctl -n hw.ncpu` clang=y
 
+freebsd_randconfig_template: &FREEBSD_RANDCONFIG_TEMPLATE
+  << : *FREEBSD_ENV
+
+  install_script: pkg install -y gmake python bison
+
+  build_script:
+    - cc --version
+    - gmake -j`sysctl -n hw.ncpu` -C xen clang=y \
+            KCONFIG_ALLCONFIG=tools/kconfig/allrandom.config randconfig
+    - gmake -j`sysctl -n hw.ncpu` build-xen clang=y
+
 task:
-  name: 'FreeBSD 13'
-  freebsd_instance:
-    image_family: freebsd-13-4
-  << : *FREEBSD_TEMPLATE
+  name: 'FreeBSD 13: full build'
+  << : *FREEBSD_13
+  << : *FREEBSD_FULL_BUILD_TEMPLATE
 
 task:
-  name: 'FreeBSD 14'
-  freebsd_instance:
-    image_family: freebsd-14-2
-  << : *FREEBSD_TEMPLATE
+  name: 'FreeBSD 14: full build'
+  << : *FREEBSD_14
+  << : *FREEBSD_FULL_BUILD_TEMPLATE
 
 task:
-  name: 'FreeBSD 15'
-  freebsd_instance:
-    image_family: freebsd-15-0-snap
-  << : *FREEBSD_TEMPLATE
+  name: 'FreeBSD 15: full build'
+  << : *FREEBSD_15
+  << : *FREEBSD_FULL_BUILD_TEMPLATE
+
+task:
+  name: 'FreeBSD 13: randconfig'
+  << : *FREEBSD_13
+  << : *FREEBSD_RANDCONFIG_TEMPLATE
+
+task:
+  name: 'FreeBSD 14: randconfig'
+  << : *FREEBSD_14
+  << : *FREEBSD_RANDCONFIG_TEMPLATE
+
+task:
+  name: 'FreeBSD 15: randconfig'
+  << : *FREEBSD_15
+  << : *FREEBSD_RANDCONFIG_TEMPLATE
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Thu Jan 16 09:02:17 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 09:02:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873360.1284322 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYLlX-0006JW-Oc; Thu, 16 Jan 2025 09:02:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873360.1284322; Thu, 16 Jan 2025 09: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 <xen-devel-bounces@lists.xenproject.org>)
	id 1tYLlX-0006JP-Ll; Thu, 16 Jan 2025 09:02:15 +0000
Received: by outflank-mailman (input) for mailman id 873360;
 Thu, 16 Jan 2025 09:02:14 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=EPy+=UI=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tYLlW-0006JJ-6Q
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 09:02:14 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 92b9d992-d3e8-11ef-99a4-01e77a169b0f;
 Thu, 16 Jan 2025 10:02:12 +0100 (CET)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-aaf8f0ea963so131597166b.3
 for <xen-devel@lists.xenproject.org>; Thu, 16 Jan 2025 01:02:12 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c956479asm876454866b.116.2025.01.16.01.02.11
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 16 Jan 2025 01:02:11 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 92b9d992-d3e8-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737018132; x=1737622932; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=5qY00DLTAsy2Nhuq24P31bpZ2CJJ0d1NokZCMwVaE90=;
        b=LKoN3qfvEevW1mwRrSJzkoyR8pWZ9K87zMAHVZKd4KIodSXou88YkR2kRto23zL4XB
         ucqqx0VzhWDOk1HzR3pzwGGQ3l7p7rJEmMxExIJRLcOFcd0GSeKW0l/YwKk2sP/6nNmc
         WcVIIOcNUmVNWlbXfx+Hz3CC3L37dE162wD4I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737018132; x=1737622932;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=5qY00DLTAsy2Nhuq24P31bpZ2CJJ0d1NokZCMwVaE90=;
        b=wgjAOQj/tT/ZVPL9dz3yw2NEywOZvaWi8YaldvdJy9xAWg4TmIsBRd+k1wnJ43D3y8
         yaXcEDxr1ZBISPh/IYL7D4ywzME649GEgZA8Unst+4InMoWVV7fe8PDbmVzQFhcCrRXv
         cioMXFNH+k6iEKTP+mawaA0eqzvMnq5OedDljnUbazfK8tcL0xTxhlEO7s6O74Oo3iGJ
         0uNcmeLaXYeEnviKfHNoBCTJqCEZxNK/Qr0VlrSRjTjHucVc7CCqSNfnkyTeG7s0hTx3
         +LfMpEddbb1Cs+Hr3kPdqpsV2+GT99vOuUfd4qcKM7Jy8Y9L/aLaMYNW25zLWeZPhKiB
         yr7Q==
X-Forwarded-Encrypted: i=1; AJvYcCVyOWw6OMAN8xGgnkHZw+9v8iYqpNN32hliFBjmAiGsHQhdj29CBKX0HSXV6ZzwaSYe8xYUFNYTiXA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxzCcsIe/tS+YgJIXZYZbuk8HydxFAeOfWEC8M5vzjn8sgcCy57
	nzdPshJVQmFTQXxKN06NFPsrUrRF6mjA04VgSA9AP4Bz3tnufumtqYNf/LC5wvfBeLpP+M9kLYy
	x0w0+0Q==
X-Gm-Gg: ASbGnctLxNS+KKb4EK00bmdZmz2DJ5o02eraRopCUxo4Zjg6bnJv1nVsBeqm8FZLH6A
	XWIVgCmdZ8H00FR/lys121UqX6qPC8QyOIUq3s+fk3IFam2O8DcLtyxFNZq0oq5lFSTrZcUaKSl
	edN49/p0yd7dTk3XsR3n/Zw8535qXG/0XIOV2xNlkXawM0YXx3gtglt9XbLx8xAzlEd+r0Js/0a
	uwdYK8UqJ5Vl+xfdS1MumZ6D1EEzQZCAHyi0NxZW5IA6R16nFvt6/x67m0qIUgsHYtqYcOVa+PF
	xKis/eNR2ImCXcWqp0B0
X-Google-Smtp-Source: AGHT+IGhZcHIAPT3ogkKcoxbKl/IA6IjUO3PpHVVMAKqAs62V0oVXpaCvuxHBdFXBrlO9X6esTt/8A==
X-Received: by 2002:a17:907:c815:b0:ab2:c78f:e4ae with SMTP id a640c23a62f3a-ab2c78fe63dmr2267247266b.20.1737018131779;
        Thu, 16 Jan 2025 01:02:11 -0800 (PST)
Message-ID: <df3cf93f-2250-497a-9200-65716bdf9547@citrix.com>
Date: Thu, 16 Jan 2025 09:02:10 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20 1/2] automation/cirrus-ci: update FreeBSD to 13.4
To: Roger Pau Monne <roger.pau@citrix.com>, xen-devel@lists.xenproject.org
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>
References: <20250116085852.78273-1-roger.pau@citrix.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <20250116085852.78273-1-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 16/01/2025 8:58 am, Roger Pau Monne wrote:
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>


From xen-devel-bounces@lists.xenproject.org Thu Jan 16 09:31:32 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 09:31:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873369.1284333 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYMDZ-000561-Rh; Thu, 16 Jan 2025 09:31:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873369.1284333; Thu, 16 Jan 2025 09:31:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYMDZ-00055u-OW; Thu, 16 Jan 2025 09:31:13 +0000
Received: by outflank-mailman (input) for mailman id 873369;
 Thu, 16 Jan 2025 09:31: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
 <SRS0=WMgP=UI=bugseng.com=nicola.vetrini@srs-se1.protection.inumbo.net>)
 id 1tYMDX-00055l-P7
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 09:31:12 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9dffa93a-d3ec-11ef-99a4-01e77a169b0f;
 Thu, 16 Jan 2025 10:31:09 +0100 (CET)
Received: from nico.bugseng.com (unknown [46.228.253.214])
 by support.bugseng.com (Postfix) with ESMTPSA id B9FED4EED422;
 Thu, 16 Jan 2025 10:31:06 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9dffa93a-d3ec-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1737019868; bh=VPfiKdifsI4B8yVlKwmfWHnWIVmO3aBtXYXj03GolT8=;
	h=From:To:Cc:Subject:Date:From;
	b=OXKw1ZcIH4J1+S86++YLiHdQf/RMTz5KA2m5sFoJ7eql6MNnvuZCoBUQbhi3O9+Ok
	 KJwIQhLR3YUR0pwrOwJgX4L7TrQrdv4MkgJBZKb1Y3NjxRKi9J7hBVrDAiTQPDjWZG
	 eDgR585h1EP4qcftCworH1BoMn4AbMa4ZYe3C+r40UhE8fBuVjAVtzsXHV9XHdWjWD
	 sP2M+Mg6R/pHN5Ez7zZ9h7SHvJratCvkxkKv1ESoVG+LPAPnboNhtDXhpxzauJb2TQ
	 1+q2yy3RBqKcD2I6jLHpRUsaKj1pbGZaD/uqhbGHpA9YleSkWceMtt97oakTs0xaWj
	 tpGbIwxLCf2Tw==
From: Nicola Vetrini <nicola.vetrini@bugseng.com>
To: xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	michal.orzel@amd.com,
	xenia.ragiadakou@amd.com,
	ayan.kumar.halder@amd.com,
	consulting@bugseng.com,
	Nicola Vetrini <nicola.vetrini@bugseng.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [XEN PATCH] docs/misra: Document ECLAIR extension to Rule 20.7
Date: Thu, 16 Jan 2025 10:31:01 +0100
Message-ID: <77354513a986a14c37ec2dfc45cf3534b08b5e85.1736972547.git.nicola.vetrini@bugseng.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

MISRA C Rule 20.7 states:
"Expressions resulting from the expansion of macro parameters shall
be enclosed in parentheses".

Document the behaviour of ECLAIR with respect to the CPP extension
that allows variable macro arguments to be named.

Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
---
 docs/misra/rules.rst | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
index e7763795b826..13890f6d8852 100644
--- a/docs/misra/rules.rst
+++ b/docs/misra/rules.rst
@@ -671,7 +671,14 @@ maintainers if you want to suggest a change.
        shall be enclosed in parentheses
      - Extra parentheses are not required when macro parameters are used
        as function arguments, as macro arguments, array indices, lhs in
-       assignments or as initializers in initalizer lists.
+       assignments or as initializers in initalizer lists. In addition,
+       the use of a named variable argument in a macro that would constitute
+       a violation of the rule is allowed by ECLAIR as an extension of the
+       MISRA, since it may not always be possible to parenthesize such
+       argument and the feature is non-standard::
+
+         #define M(args...) args
+         #if M(1) + 0 
 
    * - `Rule 20.9 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_20_09.c>`_
      - Required
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jan 16 09:39:07 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 09:39:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873381.1284343 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYML9-0006U8-MH; Thu, 16 Jan 2025 09:39:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873381.1284343; Thu, 16 Jan 2025 09:39:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYML9-0006U1-Jf; Thu, 16 Jan 2025 09:39:03 +0000
Received: by outflank-mailman (input) for mailman id 873381;
 Thu, 16 Jan 2025 09:39:02 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=8XGS=UI=ideasonboard.com=laurent.pinchart@srs-se1.protection.inumbo.net>)
 id 1tYML8-0006Tv-FL
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 09:39:02 +0000
Received: from perceval.ideasonboard.com (perceval.ideasonboard.com
 [2001:4b98:dc2:55:216:3eff:fef7:d647])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b745a5c7-d3ed-11ef-a0e2-8be0dac302b0;
 Thu, 16 Jan 2025 10:39:01 +0100 (CET)
Received: from pendragon.ideasonboard.com (unknown [193.209.96.36])
 by perceval.ideasonboard.com (Postfix) with ESMTPSA id 12F276B5;
 Thu, 16 Jan 2025 10:38:01 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b745a5c7-d3ed-11ef-a0e2-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;
	s=mail; t=1737020281;
	bh=Sz7XGsB0jJiCVcgAYNC5ZZi+VkFA4hXqTcdj3HBGvi4=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=n0BH+gjPklcJM4K7npyiN+OizL+So166OYOAFCGwmyI31sasdC0hnhksHO/5bLnfw
	 HMc/eoseS5N2gVokQXXsjM5itCkOuGjpNUxwyWy3Ek6SdEbjqi0yC6yW0imGRrqVj1
	 1fRnvPVpWPsdUJLy5MKa4eyuKZRKjUpaQVwa4Knc=
Date: Thu, 16 Jan 2025 11:38:54 +0200
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Daniel Stone <daniel@fooishbar.org>
Cc: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	maarten.lankhorst@linux.intel.com, mripard@kernel.org,
	airlied@gmail.com, simona@ffwll.ch, dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org, freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org, imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org, nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev, spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org,
	Andy Yan <andyshrk@163.com>
Subject: Re: [PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with
 drm_mode_size_dumb()
Message-ID: <20250116093854.GG6754@pendragon.ideasonboard.com>
References: <bc97b92e-7f8a-4b92-af8a-20fa165ead55@suse.de>
 <f3ba05c7-6e49-4641-a3f9-ba418ebdb7c3@ideasonboard.com>
 <c6735280-7c32-4319-8ca9-a7305d8117c3@suse.de>
 <d67adb03-5cd0-4ac9-af58-cf4446dacee3@ideasonboard.com>
 <0ea6be58-0e04-4172-87cd-064a3e4a43bc@suse.de>
 <f35cb350-6be9-48ca-ad7e-e9dd418281d5@ideasonboard.com>
 <4af0b6a7-c16a-4187-bbf5-365a9c86de21@suse.de>
 <e327ad84-b5c9-4480-b873-dc3aca605538@ideasonboard.com>
 <CAPj87rOn=RQ615zyaEdFT2ADfPztU7+heVi0G34Rdg-=QO1cCw@mail.gmail.com>
 <20250116084340.GF6754@pendragon.ideasonboard.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20250116084340.GF6754@pendragon.ideasonboard.com>

On Thu, Jan 16, 2025 at 10:43:40AM +0200, Laurent Pinchart wrote:
> On Wed, Jan 15, 2025 at 02:34:26PM +0000, Daniel Stone wrote:
> > On Wed, 15 Jan 2025 at 14:20, Tomi Valkeinen wrote:
> > > No disagreement there, we need CREATE_DUMB2.
> > >
> > > My point is that we have the current UAPI, and we have userspace using
> > > it, but we don't have clear rules what the ioctl does with specific
> > > parameters, and we don't document how it has to be used.
> > >
> > > Perhaps the situation is bad, and all we can really say is that
> > > CREATE_DUMB only works for use with simple RGB formats, and the behavior
> > > for all other formats is platform specific. But I think even that would
> > > be valuable in the UAPI docs.
> > 
> > Yeah, CREATE_DUMB only works for use with simple RGB formats in a
> > linear layout. Not monochrome or YUV or tiled or displayed rotated or
> > whatever.
> > 
> > If it happens to accidentally work for other uses, that's fine, but
> > it's not generically reliable for anything other than simple linear
> > RGB. It's intended to let you do splash screens, consoles, recovery
> > password entries, and software-rendered compositors if you really
> > want. Anything more than that isn't 'dumb'.
> 
> We have lots of software out there that rely on CREATE_DUMB supporting
> YUV linear formats, and lots of drivers (mostly on Arm I suppose) that
> implement YUV support in CREATE_DUMB. I'm fine replacing it with
> something better, but I think we need a standard ioctl that can create
> linear YUV buffers. I've been told many times that DRM doesn't want to
> standardize buffer allocation further than what CREATE_DUMB is made for.
> Can we reconsider this rule then ?

Actually... Instead of adding a CREATE_DUMB2, it would be best on trying
to leverage DMA heaps and deprecate allocating from the KMS device.

-- 
Regards,

Laurent Pinchart


From xen-devel-bounces@lists.xenproject.org Thu Jan 16 09:46:43 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 09:46:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873391.1284363 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYMSY-0000jo-JA; Thu, 16 Jan 2025 09:46:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873391.1284363; Thu, 16 Jan 2025 09:46:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYMSY-0000jh-GQ; Thu, 16 Jan 2025 09:46:42 +0000
Received: by outflank-mailman (input) for mailman id 873391;
 Thu, 16 Jan 2025 09:46:42 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=kdRh=UI=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tYMSY-0000fm-2u
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 09:46:42 +0000
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com
 [2a00:1450:4864:20::335])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c74e3a22-d3ee-11ef-99a4-01e77a169b0f;
 Thu, 16 Jan 2025 10:46:37 +0100 (CET)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-436281c8a38so3917895e9.3
 for <xen-devel@lists.xenproject.org>; Thu, 16 Jan 2025 01:46:37 -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
 5b1f17b1804b1-437c74d793asm54098165e9.26.2025.01.16.01.46.36
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 16 Jan 2025 01:46:36 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c74e3a22-d3ee-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737020797; x=1737625597; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=mHoQVHY+Ti5jQNpxHMNa4O4n39gR0vUk8HNRiaABC68=;
        b=FZbBlrLZ7EFWlSXbUFwNylq0Raa7cimOLHFuAS0p6jeGA1fYgRsOSUD+hnSvaCZ1CD
         Mpcch91QHHvqA633xbUjo6I2erwMl7yM2+2w19wTAHV62qZBEvP0QCWx08Nspksz08Ay
         1A0InFI5/0jPF5LNriBTiDLqHPjF+J+Qt1i9gpNDZbin3Cx2d82SP0HolloZdAbVqpwy
         a5CkszztLxgl7UznXtiETZxtqMmcCxZElwVtmZwFXC+X+eC367Z4r4yt5cL7mgJ7fCB4
         98g+VhOJcUhIn6jdmbrndumb4a2w+FOdy/vB7EHOp7MF15FZpRG2yTUyWBQLr2h6w+eQ
         d5uA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737020797; x=1737625597;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=mHoQVHY+Ti5jQNpxHMNa4O4n39gR0vUk8HNRiaABC68=;
        b=Rggu0VF0b4oMAykGFOhLb4oFp1PK8L6Fb9dLElBCXAueQo7d2+6vSjgMnsezDlczmg
         6Ub5g0go1ulDYrjN/vtX3B2dX8EtT26f8228LV1ClizYHVtoS/hIjdnD8aF0MNY7104Z
         eE1OixjpiU4d900klqCVBdeH5Qq1Aq4MEWG5x1T9y2FpTuV8QfccKY7p4RV2yfMhIFFk
         qCkzuIfvoTYNcUCDDhYZHgRRWHltfd9QzNVg7m8WpTubezIiG7jjcKc2qdF9OtkuPqf3
         nxXNIGBE9u+EYIUEw86H+demWTQ8FT4Ru37PsmHw2H4vhK9TBCN1RALZWVkKdvM7shtB
         0JhQ==
X-Forwarded-Encrypted: i=1; AJvYcCVUUwVGJ/nAtQP9sIc/jPgAusLLDPHkDbaTlEOwSsyoDUdBwzj5OyBY9z4aX7FOVy7JPpiXV3riz5E=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxObPxwc+nudUoxfhq1cHicVPxWhxxFo8d3ula1F71B/z7Eh1Rq
	znIjZTKKBjx8AWVlIo4TGPxhkUbylEhQVAIHnr/yzHIbNZorqFrebTW3nOlGpQ==
X-Gm-Gg: ASbGncusrhFOJw/LshQt94f4QbPrTgoKryiFYcbn0HGRiTU8dSF8dlZdjkEhyvDfWGx
	ilXeDuv8TiwiKMOvdFzn2f7Gwf3icoAtPB+E9UjFiD0XEjpiLCkApuHNWCcMPo29FpLOlp1UNzi
	CnnQncvEHnnPDi6U9T95XS+0iGp5j8iusQEUC087LuYmIyax3gDNeHBS2Ci2idI96MQ6dmkH3p8
	CIRnaed//KwiIezKtDJpBrnqTsO7QIsqoRaI78Fhpq9skZQlwFEF3nlUJxxHIRAClyLmIdeYMea
	BJWRrLVz/sYYY4JoyiNmdAzkev8lJDI+s67TOAmI7g==
X-Google-Smtp-Source: AGHT+IGNhwuHn6UOpG0HxAcQiI7ub0UIWXiJYKns5kjq3hCTuYtGpMyn99a3Z305jbt+4el1H1At4A==
X-Received: by 2002:a05:600c:4449:b0:435:192:63ca with SMTP id 5b1f17b1804b1-436e26f481dmr166209105e9.21.1737020796804;
        Thu, 16 Jan 2025 01:46:36 -0800 (PST)
Message-ID: <0d2e9617-e4cf-4b34-954a-a790c4bfda0a@suse.com>
Date: Thu, 16 Jan 2025 10:46:35 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] docs: Punctuation: Add missing commas after linking
 adverbs as intros
To: Bernhard Kaindl <bernhard.kaindl@cloud.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <ad9d1d7db8d43c82a02f64b8a317d7ae6522dd62.1736964253.git.bernhard.kaindl@cloud.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <ad9d1d7db8d43c82a02f64b8a317d7ae6522dd62.1736964253.git.bernhard.kaindl@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15.01.2025 19:06, Bernhard Kaindl wrote:
> Fix missing commas after linking adverbs such as currently, fortunately,
> hence, instead, and thus, when used as linking adverbs at the beginning
> of sentences. I saw them with LTeX; other checkers have this rule too.

I'm unconvinced, and despite Stefano's R-b (Stefano, please don't feel
offended) I'd like this to be commented on by a native speaker. It is my
understanding that commas in such situations are optional.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 16 09:46:43 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 09:46:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873390.1284353 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYMSU-0000VE-Cf; Thu, 16 Jan 2025 09:46:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873390.1284353; Thu, 16 Jan 2025 09:46:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYMSU-0000V7-A6; Thu, 16 Jan 2025 09:46:38 +0000
Received: by outflank-mailman (input) for mailman id 873390;
 Thu, 16 Jan 2025 09:46:36 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=EPy+=UI=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tYMSS-0000V1-Qw
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 09:46:36 +0000
Received: from mail-ej1-x644.google.com (mail-ej1-x644.google.com
 [2a00:1450:4864:20::644])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c601f7b3-d3ee-11ef-a0e2-8be0dac302b0;
 Thu, 16 Jan 2025 10:46:35 +0100 (CET)
Received: by mail-ej1-x644.google.com with SMTP id
 a640c23a62f3a-aafc9d75f8bso129322766b.2
 for <xen-devel@lists.xenproject.org>; Thu, 16 Jan 2025 01:46:35 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c95af7besm896403266b.143.2025.01.16.01.46.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 16 Jan 2025 01:46:34 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c601f7b3-d3ee-11ef-a0e2-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737020794; x=1737625594; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=VIwPoNhHywa1w9kcouUWgx2Kas2F5uNyWXSuZbapdhI=;
        b=YCbGd1IIGkFF/8L68nKwyGg6lvE8DYkivVWde8MMAOL275/pf0QJqhpg3+PhrFe1Rr
         S42UG7fdlmLdZKsP6LDsZFv6X7YzoNaNZYSfQiDis0XioXQ/8eQU9k1i5UEunFD+Y737
         MGiYv/D2D5FQGX0WlRxoY6CLElnQjCumF4eNU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737020794; x=1737625594;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=VIwPoNhHywa1w9kcouUWgx2Kas2F5uNyWXSuZbapdhI=;
        b=KEgsRavliAqZlu3kVAiGZJ0rIg1XqDibaFpytk8Ntu30DN3DIU4qUev7VHkXO5UKDn
         Bln5X+xazobIUpdgmop0LKX6aVOBemuS5SOnIiuAD5+RPKMcSYXCIqbNZTI4PByMRGPZ
         OLDg7ncqbEGjhVUXxZ4AagV0l2FxV5Y2yFWf/iOVgC4nEZ/kpWkUxDy7Dmt9vdFL58X8
         Nl+Q5PGeV29YRub4NnvmowCnBxnasmgf4t/vyoprNHV+Pl00W1V+YN+A1fVvEfcxoEiB
         v0V1X2IFfLMUlScD3GKINJ5Zb5f4jcZEXU8ZpXbWNMH3UgH4I6P+eG4ts8mMcxvFCtI4
         wzpQ==
X-Forwarded-Encrypted: i=1; AJvYcCUDAEXcTMtC8t89cIL/BQ5wP9yoVhhjpTZNbH/eg9NbjNEBJcfLXYPCUVbfhAJ7sX5dNluRVlKi3FI=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz+ZCLonI0gn5FlQ4V3nd9kJ1p6l3Kgw/78cLTiMJtbVN3jHvdF
	juIUOzjsseiJ9RtBso4eFJgSJYwhuayU7pduDc8+LqxellDxZJMjRZnBFHOP194=
X-Gm-Gg: ASbGnctYbe+L+UZ5fbxktaqS5+y8mHgJaCgHcrhx5q6+PCpZhZ0AhZVpzyIIp/XK+PA
	+XFWyOqufLxmJOGjG71/du+ILT9UNdKojeydLHQQexcH8CFbd44LQ0Re7V4ewucb6MhyK9AnoqH
	xeVRUArq8J/yPDVExKFd6ymklVaSkq2mgIqEtk1mTqHgOmBt0ZnU77KfAo899PeeTiz35lrAh9Q
	yL9HJdqu6C+bkYNHTs9mx212KXt+IjiQuj27qO5i2V/e6vX6p3+l3y/jratNUBBAi8nV2aigDlA
	ecDwlq6Vc0wgwJPXVw3j
X-Google-Smtp-Source: AGHT+IHBbqUIzhTFw2aIFGuf4dG458UqjTq9i9/Ui6iMvzkHiNDF6KmFGvqVLIVyhbahG0SW6d0D6A==
X-Received: by 2002:a17:907:36c8:b0:aa6:4494:e354 with SMTP id a640c23a62f3a-ab2abc92570mr3297558966b.42.1737020794373;
        Thu, 16 Jan 2025 01:46:34 -0800 (PST)
Message-ID: <7984d25d-66ac-4791-929b-a3ce037e960c@citrix.com>
Date: Thu, 16 Jan 2025 09:46:33 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20 2/2] automation/cirrus-ci: introduce FreeBSD
 randconfig builds
To: Roger Pau Monne <roger.pau@citrix.com>, xen-devel@lists.xenproject.org
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>
References: <20250116085852.78273-1-roger.pau@citrix.com>
 <20250116085852.78273-2-roger.pau@citrix.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <20250116085852.78273-2-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 16/01/2025 8:58 am, Roger Pau Monne wrote:
> Add a new randconfig job for each FreeBSD version.  This requires some
> rework of the template so common parts can be shared between the full and
> the randconfig builds.  Such randconfig builds are relevant because FreeBSD
> is the only tested system that has a full non-GNU toolchain.
>
> While there remove the stale `python` package install in the full build
> case: this is no longer needed if `python311` is also specified.
>
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> ---
>  .cirrus.yml | 64 +++++++++++++++++++++++++++++++++++++++++------------
>  1 file changed, 50 insertions(+), 14 deletions(-)
>
> diff --git a/.cirrus.yml b/.cirrus.yml
> index ee80152890f2..f3ea29102cbf 100644
> --- a/.cirrus.yml
> +++ b/.cirrus.yml
> @@ -1,11 +1,24 @@
>  # https://cirrus-ci.org/guide/tips-and-tricks/#sharing-configuration-between-tasks
> -freebsd_template: &FREEBSD_TEMPLATE
> +freebsd_13: &FREEBSD_13
> +  freebsd_instance:
> +    image_family: freebsd-13-4
> +freebsd_14: &FREEBSD_14
> +  freebsd_instance:
> +    image_family: freebsd-14-2
> +freebsd_15: &FREEBSD_15
> +  freebsd_instance:
> +    image_family: freebsd-15-0-snap
> +
> +freebsd_template: &FREEBSD_ENV
>    environment:
>      APPEND_LIB: /usr/local/lib
>      APPEND_INCLUDES: /usr/local/include
>  
> +freebsd_full_build_template: &FREEBSD_FULL_BUILD_TEMPLATE
> +  << : *FREEBSD_ENV
> +
>    install_script: pkg install -y seabios gmake ninja bash
> -                                 pkgconf python bison perl5
> +                                 pkgconf bison perl5
>                                   yajl lzo2 pixman argp-standalone
>                                   libxml2 glib git python311
>  
> @@ -15,20 +28,43 @@ freebsd_template: &FREEBSD_TEMPLATE
>      - ./configure --with-system-seabios=/usr/local/share/seabios/bios.bin
>      - gmake -j`sysctl -n hw.ncpu` clang=y
>  
> +freebsd_randconfig_template: &FREEBSD_RANDCONFIG_TEMPLATE
> +  << : *FREEBSD_ENV
> +
> +  install_script: pkg install -y gmake python bison

It's odd having python311 for the full build but only python for the
randconfig build.

IIRC, it's just for Qemu, so there is a split based on whether we build
tools or not.

What will happen when python becomes 3.12?  Does pkg have a way of
asking "I want any python as long as it's 3.11 or later" ?

Relatedly, how likely is python to transform into 3.12 in a bump to the
minor FreeBSD versions?

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Jan 16 09:51:07 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 09:51:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873411.1284373 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYMWo-0002fG-5D; Thu, 16 Jan 2025 09:51:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873411.1284373; Thu, 16 Jan 2025 09: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 <xen-devel-bounces@lists.xenproject.org>)
	id 1tYMWo-0002f9-1S; Thu, 16 Jan 2025 09:51:06 +0000
Received: by outflank-mailman (input) for mailman id 873411;
 Thu, 16 Jan 2025 09:51:05 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=kdRh=UI=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tYMWm-0002dP-Ut
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 09:51:04 +0000
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com
 [2a00:1450:4864:20::32f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 66420048-d3ef-11ef-a0e2-8be0dac302b0;
 Thu, 16 Jan 2025 10:51:03 +0100 (CET)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-4361f65ca01so6230375e9.1
 for <xen-devel@lists.xenproject.org>; Thu, 16 Jan 2025 01:51:03 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-437c7499942sm52962605e9.6.2025.01.16.01.51.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 16 Jan 2025 01:51:03 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 66420048-d3ef-11ef-a0e2-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737021063; x=1737625863; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=2Q2TkjmnTaEB5x8Xl171g0+JkKKOeL7dJhCQLqhZYRE=;
        b=hG9OvHCCVAS1iefrlTlY9Cda3iaz4Fo5oUCZH2Lh+unqknvL3SyZy3p+9+fjeyMCoX
         rimFtsoxX2tUDQfCvITdrzgkFOdsIxwPFB0DVDMsjSGFhYeBrbL19l/bGJWjoUSEswUH
         o7GPhkiy0b4d8pjhvHvfh7pKEVZ5WoXnGlFxWVoD5XZ7mq5Ze7CRol0DabULNkrxCh3U
         4jbbnhaBQ2TDqxiGqYM2BPXITPulJ+f/RXv7X8XzOOmnl5EXABsjGXxclQnxBKWj+nrI
         ADtgDw/zQ4hHkXgtV756HvBafx1uLhWi1J8I4DY2ZMkdhXqKrUgbNdQW9WxWVMW8QjB0
         BiKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737021063; x=1737625863;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=2Q2TkjmnTaEB5x8Xl171g0+JkKKOeL7dJhCQLqhZYRE=;
        b=MuB94ZW0VTvAE/ROAKNiuSgyOztsGZPhv0GHowE2TD0Z9+Ch5kgaN133RW5viGq8u1
         M5M10UjXzNkoTxFJ3n5BjQFS867C5CmiYt3u/IOfmrjNc2dd3ggSUUvdKYValRK/aBZq
         8qsO6ifUUndVklDgVcv4KUFwMC2Sjh8xBcsKNl1OYmDS3uYqHt3lvlu1/po17ipkn2Y/
         unVpUMU1drepO8lIZkX33ZNyr2bSVH3fV8dPPhKjvSwu9FVG90c6gAdgR0vTv+k7K5qr
         HjMjM2p1sEQHvfFhuVn290aYmIysd0pwRwtByRbAod+kx9+E7In0hDZ8r5fJc39Zqpp0
         ybrw==
X-Forwarded-Encrypted: i=1; AJvYcCXeP0cF1FFxAVX7tihSk1oWd4++1f7T/040CuHDICJxp+zMCFsdD/coAd9ZquBJlVPapCGQFTBtPfY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwI29nOWYAjdYX1PFTlAGDzC0F8fO5PverWIJq0EivikNJLLpza
	N7uWLq6tte9hIjjpdfcRwMUGLpHWNM9J8iXPSnucOW8w+0WtnQwGRImK4TjAqA==
X-Gm-Gg: ASbGncth+TdcKo8ZQkGxM8PKi+Uj9OHIUpnN+qaLV6SDnvduIlwSYlt3uuuk//jYjPz
	vWqN+IV4ozvDBD+Q/FwkudV92MjT0BavH9YOzQ40Wo8x0T0BClutAp7yz3finMJqvbog6qeAM2Z
	m0dItlHCZs0r1xUQrxtVWhXChox1eSr6CiSRTK6YcrRJXyR3lHK3CByRwUmrejwFN4VQZSZtNom
	jUpQXiaGKDXcoIssxs7/PN3amM6rORmM457L7nV6+Ssb8qtVlwqlYKW4ygmMuGoXqnQwGKxymEH
	Nt2otl+ymZo2Fzkzu8fyvPHGk9c4kHwHP6lisMbj4g==
X-Google-Smtp-Source: AGHT+IEnNZLOrVVu69pYB6p5VD9Sv8RPKa9TAefsGgjmEy4icwJqKrArwoufuE3pCxDJZiK350Uflg==
X-Received: by 2002:a05:600c:4e8c:b0:434:f5c0:3288 with SMTP id 5b1f17b1804b1-436e271d355mr299560085e9.29.1737021063311;
        Thu, 16 Jan 2025 01:51:03 -0800 (PST)
Message-ID: <d90e5496-cccf-4670-8332-8d2e5f482c5e@suse.com>
Date: Thu, 16 Jan 2025 10:51:01 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH] docs/misra: Document ECLAIR extension to Rule 20.7
To: Nicola Vetrini <nicola.vetrini@bugseng.com>
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <77354513a986a14c37ec2dfc45cf3534b08b5e85.1736972547.git.nicola.vetrini@bugseng.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <77354513a986a14c37ec2dfc45cf3534b08b5e85.1736972547.git.nicola.vetrini@bugseng.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 16.01.2025 10:31, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states:
> "Expressions resulting from the expansion of macro parameters shall
> be enclosed in parentheses".
> 
> Document the behaviour of ECLAIR with respect to the CPP extension
> that allows variable macro arguments to be named.
> 
> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
> ---
>  docs/misra/rules.rst | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
> index e7763795b826..13890f6d8852 100644
> --- a/docs/misra/rules.rst
> +++ b/docs/misra/rules.rst
> @@ -671,7 +671,14 @@ maintainers if you want to suggest a change.
>         shall be enclosed in parentheses
>       - Extra parentheses are not required when macro parameters are used
>         as function arguments, as macro arguments, array indices, lhs in
> -       assignments or as initializers in initalizer lists.
> +       assignments or as initializers in initalizer lists. In addition,
> +       the use of a named variable argument in a macro that would constitute
> +       a violation of the rule is allowed by ECLAIR as an extension of the
> +       MISRA, since it may not always be possible to parenthesize such

Just one nit / question (addressable while committing, if desired): I
wouldn't have expected "the" before "MISRA". Is that conventional wording
in your environment?

Jan

> +       argument and the feature is non-standard::
> +
> +         #define M(args...) args
> +         #if M(1) + 0 
>  
>     * - `Rule 20.9 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_20_09.c>`_
>       - Required



From xen-devel-bounces@lists.xenproject.org Thu Jan 16 10:03:39 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 10:03:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873423.1284382 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYMir-00061V-9F; Thu, 16 Jan 2025 10:03:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873423.1284382; Thu, 16 Jan 2025 10:03:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYMir-00061O-6L; Thu, 16 Jan 2025 10:03:33 +0000
Received: by outflank-mailman (input) for mailman id 873423;
 Thu, 16 Jan 2025 10:03:32 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=FBKk=UI=ideasonboard.com=tomi.valkeinen@srs-se1.protection.inumbo.net>)
 id 1tYMiq-00061I-0l
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 10:03:32 +0000
Received: from perceval.ideasonboard.com (perceval.ideasonboard.com
 [213.167.242.64]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2292925e-d3f1-11ef-99a4-01e77a169b0f;
 Thu, 16 Jan 2025 11:03:29 +0100 (CET)
Received: from [192.168.88.20] (91-158-153-178.elisa-laajakaista.fi
 [91.158.153.178])
 by perceval.ideasonboard.com (Postfix) with ESMTPSA id 085BA169;
 Thu, 16 Jan 2025 11:02:28 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2292925e-d3f1-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;
	s=mail; t=1737021750;
	bh=pDCn29EEpKKZmA/7wLT0kxJDOJjy+GBkcl8gJzeWG9U=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=TpMcZ3vrr5WxdAEfA+KEwE9cjRspY009CslXy4aVUd/cpLOBovT4SoXU8HmhjIGPb
	 iQv3DAMmKDjPdAPDkGgISGzmuaecYxfXd+2i6QJIXZUvFkO2JlhAz3qM3EvGY0UO9+
	 RrYPfH1a+aisEgq3rXdGVFbOpeHxWfquF5lfzis8=
Message-ID: <f3833771-fcd7-45dc-9019-1525fef34429@ideasonboard.com>
Date: Thu, 16 Jan 2025 12:03:24 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with
 drm_mode_size_dumb()
To: Thomas Zimmermann <tzimmermann@suse.de>,
 maarten.lankhorst@linux.intel.com, mripard@kernel.org, airlied@gmail.com,
 simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org, linux-mediatek@lists.infradead.org,
 freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
 imx@lists.linux.dev, linux-samsung-soc@vger.kernel.org,
 nouveau@lists.freedesktop.org, virtualization@lists.linux.dev,
 spice-devel@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org,
 linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org,
 intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org,
 Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
 Andy Yan <andyshrk@163.com>, Daniel Stone <daniel@fooishbar.org>
References: <20250109150310.219442-1-tzimmermann@suse.de>
 <20250109150310.219442-26-tzimmermann@suse.de>
 <cdbe483d-0895-47aa-8c83-1c28220f4a02@ideasonboard.com>
 <bc97b92e-7f8a-4b92-af8a-20fa165ead55@suse.de>
 <f3ba05c7-6e49-4641-a3f9-ba418ebdb7c3@ideasonboard.com>
 <c6735280-7c32-4319-8ca9-a7305d8117c3@suse.de>
 <d67adb03-5cd0-4ac9-af58-cf4446dacee3@ideasonboard.com>
 <0ea6be58-0e04-4172-87cd-064a3e4a43bc@suse.de>
 <f35cb350-6be9-48ca-ad7e-e9dd418281d5@ideasonboard.com>
 <4af0b6a7-c16a-4187-bbf5-365a9c86de21@suse.de>
 <e327ad84-b5c9-4480-b873-dc3aca605538@ideasonboard.com>
 <a2bbeb47-2569-4ee0-9265-92bab139bdc6@suse.de>
Content-Language: en-US
From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Autocrypt: addr=tomi.valkeinen@ideasonboard.com; keydata=
 xsFNBE6ms0cBEACyizowecZqXfMZtnBniOieTuFdErHAUyxVgtmr0f5ZfIi9Z4l+uUN4Zdw2
 wCEZjx3o0Z34diXBaMRJ3rAk9yB90UJAnLtb8A97Oq64DskLF81GCYB2P1i0qrG7UjpASgCA
 Ru0lVvxsWyIwSfoYoLrazbT1wkWRs8YBkkXQFfL7Mn3ZMoGPcpfwYH9O7bV1NslbmyJzRCMO
 eYV258gjCcwYlrkyIratlHCek4GrwV8Z9NQcjD5iLzrONjfafrWPwj6yn2RlL0mQEwt1lOvn
 LnI7QRtB3zxA3yB+FLsT1hx0va6xCHpX3QO2gBsyHCyVafFMrg3c/7IIWkDLngJxFgz6DLiA
 G4ld1QK/jsYqfP2GIMH1mFdjY+iagG4DqOsjip479HCWAptpNxSOCL6z3qxCU8MCz8iNOtZk
 DYXQWVscM5qgYSn+fmMM2qN+eoWlnCGVURZZLDjg387S2E1jT/dNTOsM/IqQj+ZROUZuRcF7
 0RTtuU5q1HnbRNwy+23xeoSGuwmLQ2UsUk7Q5CnrjYfiPo3wHze8avK95JBoSd+WIRmV3uoO
 rXCoYOIRlDhg9XJTrbnQ3Ot5zOa0Y9c4IpyAlut6mDtxtKXr4+8OzjSVFww7tIwadTK3wDQv
 Bus4jxHjS6dz1g2ypT65qnHen6mUUH63lhzewqO9peAHJ0SLrQARAQABzTBUb21pIFZhbGtl
 aW5lbiA8dG9taS52YWxrZWluZW5AaWRlYXNvbmJvYXJkLmNvbT7CwY4EEwEIADgWIQTEOAw+
 ll79gQef86f6PaqMvJYe9QUCX/HruAIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRD6
 PaqMvJYe9WmFD/99NGoD5lBJhlFDHMZvO+Op8vCwnIRZdTsyrtGl72rVh9xRfcSgYPZUvBuT
 VDxE53mY9HaZyu1eGMccYRBaTLJSfCXl/g317CrMNdY0k40b9YeIX10feiRYEWoDIPQ3tMmA
 0nHDygzcnuPiPT68JYZ6tUOvAt7r6OX/litM+m2/E9mtp8xCoWOo/kYO4mOAIoMNvLB8vufi
 uBB4e/AvAjtny4ScuNV5c5q8MkfNIiOyag9QCiQ/JfoAqzXRjVb4VZG72AKaElwipiKCWEcU
 R4+Bu5Qbaxj7Cd36M/bI54OrbWWETJkVVSV1i0tghCd6HHyquTdFl7wYcz6cL1hn/6byVnD+
 sR3BLvSBHYp8WSwv0TCuf6tLiNgHAO1hWiQ1pOoXyMEsxZlgPXT+wb4dbNVunckwqFjGxRbl
 Rz7apFT/ZRwbazEzEzNyrBOfB55xdipG/2+SmFn0oMFqFOBEszXLQVslh64lI0CMJm2OYYe3
 PxHqYaztyeXsx13Bfnq9+bUynAQ4uW1P5DJ3OIRZWKmbQd/Me3Fq6TU57LsvwRgE0Le9PFQs
 dcP2071rMTpqTUteEgODJS4VDf4lXJfY91u32BJkiqM7/62Cqatcz5UWWHq5xeF03MIUTqdE
 qHWk3RJEoWHWQRzQfcx6Fn2fDAUKhAddvoopfcjAHfpAWJ+ENc7BTQROprNHARAAx0aat8GU
 hsusCLc4MIxOQwidecCTRc9Dz/7U2goUwhw2O5j9TPqLtp57VITmHILnvZf6q3QAho2QMQyE
 DDvHubrdtEoqaaSKxKkFie1uhWNNvXPhwkKLYieyL9m2JdU+b88HaDnpzdyTTR4uH7wk0bBa
 KbTSgIFDDe5lXInypewPO30TmYNkFSexnnM3n1PBCqiJXsJahE4ZQ+WnV5FbPUj8T2zXS2xk
 0LZ0+DwKmZ0ZDovvdEWRWrz3UzJ8DLHb7blPpGhmqj3ANXQXC7mb9qJ6J/VSl61GbxIO2Dwb
 xPNkHk8fwnxlUBCOyBti/uD2uSTgKHNdabhVm2dgFNVuS1y3bBHbI/qjC3J7rWE0WiaHWEqy
 UVPk8rsph4rqITsj2RiY70vEW0SKePrChvET7D8P1UPqmveBNNtSS7In+DdZ5kUqLV7rJnM9
 /4cwy+uZUt8cuCZlcA5u8IsBCNJudxEqBG10GHg1B6h1RZIz9Q9XfiBdaqa5+CjyFs8ua01c
 9HmyfkuhXG2OLjfQuK+Ygd56mV3lq0aFdwbaX16DG22c6flkkBSjyWXYepFtHz9KsBS0DaZb
 4IkLmZwEXpZcIOQjQ71fqlpiXkXSIaQ6YMEs8WjBbpP81h7QxWIfWtp+VnwNGc6nq5IQDESH
 mvQcsFS7d3eGVI6eyjCFdcAO8eMAEQEAAcLBXwQYAQIACQUCTqazRwIbDAAKCRD6PaqMvJYe
 9fA7EACS6exUedsBKmt4pT7nqXBcRsqm6YzT6DeCM8PWMTeaVGHiR4TnNFiT3otD5UpYQI7S
 suYxoTdHrrrBzdlKe5rUWpzoZkVK6p0s9OIvGzLT0lrb0HC9iNDWT3JgpYDnk4Z2mFi6tTbq
 xKMtpVFRA6FjviGDRsfkfoURZI51nf2RSAk/A8BEDDZ7lgJHskYoklSpwyrXhkp9FHGMaYII
 m9EKuUTX9JPDG2FTthCBrdsgWYPdJQvM+zscq09vFMQ9Fykbx5N8z/oFEUy3ACyPqW2oyfvU
 CH5WDpWBG0s5BALp1gBJPytIAd/pY/5ZdNoi0Cx3+Z7jaBFEyYJdWy1hGddpkgnMjyOfLI7B
 CFrdecTZbR5upjNSDvQ7RG85SnpYJTIin+SAUazAeA2nS6gTZzumgtdw8XmVXZwdBfF+ICof
 92UkbYcYNbzWO/GHgsNT1WnM4sa9lwCSWH8Fw1o/3bX1VVPEsnESOfxkNdu+gAF5S6+I6n3a
 ueeIlwJl5CpT5l8RpoZXEOVtXYn8zzOJ7oGZYINRV9Pf8qKGLf3Dft7zKBP832I3PQjeok7F
 yjt+9S+KgSFSHP3Pa4E7lsSdWhSlHYNdG/czhoUkSCN09C0rEK93wxACx3vtxPLjXu6RptBw
 3dRq7n+mQChEB1am0BueV1JZaBboIL0AGlSJkm23kw==
In-Reply-To: <a2bbeb47-2569-4ee0-9265-92bab139bdc6@suse.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

On 16/01/2025 10:09, Thomas Zimmermann wrote:
> Hi
> 
> 
> Am 15.01.25 um 15:20 schrieb Tomi Valkeinen:
> [...]
>>
>> My point is that we have the current UAPI, and we have userspace using 
>> it, but we don't have clear rules what the ioctl does with specific 
>> parameters, and we don't document how it has to be used.
>>
>> Perhaps the situation is bad, and all we can really say is that 
>> CREATE_DUMB only works for use with simple RGB formats, and the 
>> behavior for all other formats is platform specific. But I think even 
>> that would be valuable in the UAPI docs.
> 
> To be honest, I would not want to specify behavior for anything but the 
> linear RGB formats. If anything, I'd take Daniel's reply mail for 
> documentation as-is. Anyone stretching the UAPI beyond RGB is on their own.
> 
>>
>> Thinking about this, I wonder if this change is good for omapdrm or 
>> xilinx (probably other platforms too that support non-simple non-RGB 
>> formats via dumb buffers): without this patch, in both drivers, the 
>> pitch calculations just take the bpp as bit-per-pixels, align it up, 
>> and that's it.
>>
>> With this patch we end up using drm_driver_color_mode_format(), and 
>> aligning buffers according to RGB formats figured out via heuristics. 
>> It does happen to work, for the formats I tested, but it sounds like 
>> something that might easily not work, as it's doing adjustments based 
>> on wrong format.
>>
>> Should we have another version of drm_mode_size_dumb() which just 
>> calculates using the bpp, without the drm_driver_color_mode_format() 
>> path? Or does the drm_driver_color_mode_format() path provide some 
>> value for the drivers that do not currently do anything similar?
> 
> With the RGB-only rule, using drm_driver_color_mode_format() makes 
> sense. It aligns dumb buffers and video=, provides error checking, and 
> overall harmonizes code. The fallback is only required because of the 
> existing odd cases that already bend the UAPI's rules.

I have to disagree here.

On the platforms I have been using (omap, tidss, xilinx, rcar) the dumb 
buffers are the only buffers you can get from the DRM driver. The dumb 
buffers have been used to allocate linear and multiplanar YUV buffers 
for a very long time on those platforms.

I tried to look around, but I did not find any mentions that CREATE_DUMB 
should only be used for RGB buffers. Is anyone outside the core 
developers even aware of it?

If we don't use dumb buffers there, where do we get the buffers? Maybe 
from a v4l2 device or from a gpu device, but often you don't have those. 
DMA_HEAP is there, of course.

So we have the option to get DMA_HEAP buffers, specifying just the size 
of the buffer. Here we only specify the size, so the userspace has to 
understand the requirements for the format and the platform.

Or we can use CREATE_DUMB, specifying the width, height and 
bitsperpixel, and if we don't have any heuristics about figuring out the 
pixel format (as it has been), the end result is exactly the same as 
with DMA_HEAP (i.e. we essentially define the size of the buffer).

So, on these platforms (omap, tidss, xilinx, rcar), the CREATE_DUMB has 
always been just "give me X amount of memory that can be used for 
scanout". With this series, the meaning of the ioctl changes, and it's 
now "give me an memory buffer buffer that works with an RGB format with 
this width, height, bpp".

In practice I believe that doesn't cause regressions, as aligning 
buffers according to RGB pixel format rules happens to be fine for YUV 
formats too, but I'm not sure (and it already almost caused a regression 
with bpp=64). And I'm having trouble seeing the upside.

Aligning video= and dumb buffers almost sounds like going backwards. 
video= parameter is bad, so let's also make dumb buffers bad?

Harmonizing code is fine, but I think that can be done with a function 
that only does the fallback-case.

So... I can only speak for the platforms I'm using and maintaining, but 
I'd rather keep the old behavior for CREATE_DUMB that we've had for ages.

  Tomi



From xen-devel-bounces@lists.xenproject.org Thu Jan 16 10:07:58 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 10:07:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873432.1284393 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYMn7-0006Zz-Rm; Thu, 16 Jan 2025 10:07:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873432.1284393; Thu, 16 Jan 2025 10:07:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYMn7-0006Zs-Nu; Thu, 16 Jan 2025 10:07:57 +0000
Received: by outflank-mailman (input) for mailman id 873432;
 Thu, 16 Jan 2025 10:07:56 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=FBKk=UI=ideasonboard.com=tomi.valkeinen@srs-se1.protection.inumbo.net>)
 id 1tYMn6-0006Zm-FK
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 10:07:56 +0000
Received: from perceval.ideasonboard.com (perceval.ideasonboard.com
 [213.167.242.64]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c0964222-d3f1-11ef-99a4-01e77a169b0f;
 Thu, 16 Jan 2025 11:07:54 +0100 (CET)
Received: from [192.168.88.20] (91-158-153-178.elisa-laajakaista.fi
 [91.158.153.178])
 by perceval.ideasonboard.com (Postfix) with ESMTPSA id 5E9B9169;
 Thu, 16 Jan 2025 11:06:54 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c0964222-d3f1-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;
	s=mail; t=1737022015;
	bh=5iBWzPVmw+7VsrlU5C002xE3DHz4wSYEG2lvi9WrW80=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=GC4JgPWOpTh5fUSUYxE2btYpeplZmk/wc1/y1hysA5w7Ekqjjovy5AnVu0+UP/8PB
	 WuoMl50q34IhSbq2JjW5zgTeNPTY5ITtuywUrB98SjdmT56zJthdugncYjNOwHs207
	 UGK7kRU9a0swMfzHVM6e3yIQ8OXcNHWB1aTeIVnk=
Message-ID: <e8125edc-928a-47b4-80a3-224c945f6d68@ideasonboard.com>
Date: Thu, 16 Jan 2025 12:07:49 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with
 drm_mode_size_dumb()
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
 Daniel Stone <daniel@fooishbar.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>,
 maarten.lankhorst@linux.intel.com, mripard@kernel.org, airlied@gmail.com,
 simona@ffwll.ch, dri-devel@lists.freedesktop.org,
 linux-mediatek@lists.infradead.org, freedreno@lists.freedesktop.org,
 linux-arm-msm@vger.kernel.org, imx@lists.linux.dev,
 linux-samsung-soc@vger.kernel.org, nouveau@lists.freedesktop.org,
 virtualization@lists.linux.dev, spice-devel@lists.freedesktop.org,
 linux-renesas-soc@vger.kernel.org, linux-rockchip@lists.infradead.org,
 linux-tegra@vger.kernel.org, intel-xe@lists.freedesktop.org,
 xen-devel@lists.xenproject.org, Andy Yan <andyshrk@163.com>
References: <bc97b92e-7f8a-4b92-af8a-20fa165ead55@suse.de>
 <f3ba05c7-6e49-4641-a3f9-ba418ebdb7c3@ideasonboard.com>
 <c6735280-7c32-4319-8ca9-a7305d8117c3@suse.de>
 <d67adb03-5cd0-4ac9-af58-cf4446dacee3@ideasonboard.com>
 <0ea6be58-0e04-4172-87cd-064a3e4a43bc@suse.de>
 <f35cb350-6be9-48ca-ad7e-e9dd418281d5@ideasonboard.com>
 <4af0b6a7-c16a-4187-bbf5-365a9c86de21@suse.de>
 <e327ad84-b5c9-4480-b873-dc3aca605538@ideasonboard.com>
 <CAPj87rOn=RQ615zyaEdFT2ADfPztU7+heVi0G34Rdg-=QO1cCw@mail.gmail.com>
 <20250116084340.GF6754@pendragon.ideasonboard.com>
 <20250116093854.GG6754@pendragon.ideasonboard.com>
Content-Language: en-US
From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Autocrypt: addr=tomi.valkeinen@ideasonboard.com; keydata=
 xsFNBE6ms0cBEACyizowecZqXfMZtnBniOieTuFdErHAUyxVgtmr0f5ZfIi9Z4l+uUN4Zdw2
 wCEZjx3o0Z34diXBaMRJ3rAk9yB90UJAnLtb8A97Oq64DskLF81GCYB2P1i0qrG7UjpASgCA
 Ru0lVvxsWyIwSfoYoLrazbT1wkWRs8YBkkXQFfL7Mn3ZMoGPcpfwYH9O7bV1NslbmyJzRCMO
 eYV258gjCcwYlrkyIratlHCek4GrwV8Z9NQcjD5iLzrONjfafrWPwj6yn2RlL0mQEwt1lOvn
 LnI7QRtB3zxA3yB+FLsT1hx0va6xCHpX3QO2gBsyHCyVafFMrg3c/7IIWkDLngJxFgz6DLiA
 G4ld1QK/jsYqfP2GIMH1mFdjY+iagG4DqOsjip479HCWAptpNxSOCL6z3qxCU8MCz8iNOtZk
 DYXQWVscM5qgYSn+fmMM2qN+eoWlnCGVURZZLDjg387S2E1jT/dNTOsM/IqQj+ZROUZuRcF7
 0RTtuU5q1HnbRNwy+23xeoSGuwmLQ2UsUk7Q5CnrjYfiPo3wHze8avK95JBoSd+WIRmV3uoO
 rXCoYOIRlDhg9XJTrbnQ3Ot5zOa0Y9c4IpyAlut6mDtxtKXr4+8OzjSVFww7tIwadTK3wDQv
 Bus4jxHjS6dz1g2ypT65qnHen6mUUH63lhzewqO9peAHJ0SLrQARAQABzTBUb21pIFZhbGtl
 aW5lbiA8dG9taS52YWxrZWluZW5AaWRlYXNvbmJvYXJkLmNvbT7CwY4EEwEIADgWIQTEOAw+
 ll79gQef86f6PaqMvJYe9QUCX/HruAIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRD6
 PaqMvJYe9WmFD/99NGoD5lBJhlFDHMZvO+Op8vCwnIRZdTsyrtGl72rVh9xRfcSgYPZUvBuT
 VDxE53mY9HaZyu1eGMccYRBaTLJSfCXl/g317CrMNdY0k40b9YeIX10feiRYEWoDIPQ3tMmA
 0nHDygzcnuPiPT68JYZ6tUOvAt7r6OX/litM+m2/E9mtp8xCoWOo/kYO4mOAIoMNvLB8vufi
 uBB4e/AvAjtny4ScuNV5c5q8MkfNIiOyag9QCiQ/JfoAqzXRjVb4VZG72AKaElwipiKCWEcU
 R4+Bu5Qbaxj7Cd36M/bI54OrbWWETJkVVSV1i0tghCd6HHyquTdFl7wYcz6cL1hn/6byVnD+
 sR3BLvSBHYp8WSwv0TCuf6tLiNgHAO1hWiQ1pOoXyMEsxZlgPXT+wb4dbNVunckwqFjGxRbl
 Rz7apFT/ZRwbazEzEzNyrBOfB55xdipG/2+SmFn0oMFqFOBEszXLQVslh64lI0CMJm2OYYe3
 PxHqYaztyeXsx13Bfnq9+bUynAQ4uW1P5DJ3OIRZWKmbQd/Me3Fq6TU57LsvwRgE0Le9PFQs
 dcP2071rMTpqTUteEgODJS4VDf4lXJfY91u32BJkiqM7/62Cqatcz5UWWHq5xeF03MIUTqdE
 qHWk3RJEoWHWQRzQfcx6Fn2fDAUKhAddvoopfcjAHfpAWJ+ENc7BTQROprNHARAAx0aat8GU
 hsusCLc4MIxOQwidecCTRc9Dz/7U2goUwhw2O5j9TPqLtp57VITmHILnvZf6q3QAho2QMQyE
 DDvHubrdtEoqaaSKxKkFie1uhWNNvXPhwkKLYieyL9m2JdU+b88HaDnpzdyTTR4uH7wk0bBa
 KbTSgIFDDe5lXInypewPO30TmYNkFSexnnM3n1PBCqiJXsJahE4ZQ+WnV5FbPUj8T2zXS2xk
 0LZ0+DwKmZ0ZDovvdEWRWrz3UzJ8DLHb7blPpGhmqj3ANXQXC7mb9qJ6J/VSl61GbxIO2Dwb
 xPNkHk8fwnxlUBCOyBti/uD2uSTgKHNdabhVm2dgFNVuS1y3bBHbI/qjC3J7rWE0WiaHWEqy
 UVPk8rsph4rqITsj2RiY70vEW0SKePrChvET7D8P1UPqmveBNNtSS7In+DdZ5kUqLV7rJnM9
 /4cwy+uZUt8cuCZlcA5u8IsBCNJudxEqBG10GHg1B6h1RZIz9Q9XfiBdaqa5+CjyFs8ua01c
 9HmyfkuhXG2OLjfQuK+Ygd56mV3lq0aFdwbaX16DG22c6flkkBSjyWXYepFtHz9KsBS0DaZb
 4IkLmZwEXpZcIOQjQ71fqlpiXkXSIaQ6YMEs8WjBbpP81h7QxWIfWtp+VnwNGc6nq5IQDESH
 mvQcsFS7d3eGVI6eyjCFdcAO8eMAEQEAAcLBXwQYAQIACQUCTqazRwIbDAAKCRD6PaqMvJYe
 9fA7EACS6exUedsBKmt4pT7nqXBcRsqm6YzT6DeCM8PWMTeaVGHiR4TnNFiT3otD5UpYQI7S
 suYxoTdHrrrBzdlKe5rUWpzoZkVK6p0s9OIvGzLT0lrb0HC9iNDWT3JgpYDnk4Z2mFi6tTbq
 xKMtpVFRA6FjviGDRsfkfoURZI51nf2RSAk/A8BEDDZ7lgJHskYoklSpwyrXhkp9FHGMaYII
 m9EKuUTX9JPDG2FTthCBrdsgWYPdJQvM+zscq09vFMQ9Fykbx5N8z/oFEUy3ACyPqW2oyfvU
 CH5WDpWBG0s5BALp1gBJPytIAd/pY/5ZdNoi0Cx3+Z7jaBFEyYJdWy1hGddpkgnMjyOfLI7B
 CFrdecTZbR5upjNSDvQ7RG85SnpYJTIin+SAUazAeA2nS6gTZzumgtdw8XmVXZwdBfF+ICof
 92UkbYcYNbzWO/GHgsNT1WnM4sa9lwCSWH8Fw1o/3bX1VVPEsnESOfxkNdu+gAF5S6+I6n3a
 ueeIlwJl5CpT5l8RpoZXEOVtXYn8zzOJ7oGZYINRV9Pf8qKGLf3Dft7zKBP832I3PQjeok7F
 yjt+9S+KgSFSHP3Pa4E7lsSdWhSlHYNdG/czhoUkSCN09C0rEK93wxACx3vtxPLjXu6RptBw
 3dRq7n+mQChEB1am0BueV1JZaBboIL0AGlSJkm23kw==
In-Reply-To: <20250116093854.GG6754@pendragon.ideasonboard.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

On 16/01/2025 11:38, Laurent Pinchart wrote:
> On Thu, Jan 16, 2025 at 10:43:40AM +0200, Laurent Pinchart wrote:
>> On Wed, Jan 15, 2025 at 02:34:26PM +0000, Daniel Stone wrote:
>>> On Wed, 15 Jan 2025 at 14:20, Tomi Valkeinen wrote:
>>>> No disagreement there, we need CREATE_DUMB2.
>>>>
>>>> My point is that we have the current UAPI, and we have userspace using
>>>> it, but we don't have clear rules what the ioctl does with specific
>>>> parameters, and we don't document how it has to be used.
>>>>
>>>> Perhaps the situation is bad, and all we can really say is that
>>>> CREATE_DUMB only works for use with simple RGB formats, and the behavior
>>>> for all other formats is platform specific. But I think even that would
>>>> be valuable in the UAPI docs.
>>>
>>> Yeah, CREATE_DUMB only works for use with simple RGB formats in a
>>> linear layout. Not monochrome or YUV or tiled or displayed rotated or
>>> whatever.
>>>
>>> If it happens to accidentally work for other uses, that's fine, but
>>> it's not generically reliable for anything other than simple linear
>>> RGB. It's intended to let you do splash screens, consoles, recovery
>>> password entries, and software-rendered compositors if you really
>>> want. Anything more than that isn't 'dumb'.
>>
>> We have lots of software out there that rely on CREATE_DUMB supporting
>> YUV linear formats, and lots of drivers (mostly on Arm I suppose) that
>> implement YUV support in CREATE_DUMB. I'm fine replacing it with
>> something better, but I think we need a standard ioctl that can create
>> linear YUV buffers. I've been told many times that DRM doesn't want to
>> standardize buffer allocation further than what CREATE_DUMB is made for.
>> Can we reconsider this rule then ?
> 
> Actually... Instead of adding a CREATE_DUMB2, it would be best on trying
> to leverage DMA heaps and deprecate allocating from the KMS device.

If we allocate from DMA heaps, I think we then need a DRM ioctl which 
will tell you how big buffer(s) you need, based on the size and format.

  Tomi



From xen-devel-bounces@lists.xenproject.org Thu Jan 16 10:18:15 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 10:18:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873445.1284419 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYMwz-0000j6-U5; Thu, 16 Jan 2025 10:18:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873445.1284419; Thu, 16 Jan 2025 10:18:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYMwz-0000iz-Qs; Thu, 16 Jan 2025 10:18:09 +0000
Received: by outflank-mailman (input) for mailman id 873445;
 Thu, 16 Jan 2025 10:18:08 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=fpqP=UI=gmail.com=geert.uytterhoeven@srs-se1.protection.inumbo.net>)
 id 1tYMwy-0000it-Pu
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 10:18:08 +0000
Received: from mail-vs1-f51.google.com (mail-vs1-f51.google.com
 [209.85.217.51]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2cfa2714-d3f3-11ef-99a4-01e77a169b0f;
 Thu, 16 Jan 2025 11:18:06 +0100 (CET)
Received: by mail-vs1-f51.google.com with SMTP id
 ada2fe7eead31-4afefc876c6so133652137.2
 for <xen-devel@lists.xenproject.org>; Thu, 16 Jan 2025 02:18:06 -0800 (PST)
Received: from mail-vs1-f42.google.com (mail-vs1-f42.google.com.
 [209.85.217.42]) by smtp.gmail.com with ESMTPSA id
 ada2fe7eead31-4b608f86d6fsm5359863137.17.2025.01.16.02.18.02
 for <xen-devel@lists.xenproject.org>
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 16 Jan 2025 02:18:02 -0800 (PST)
Received: by mail-vs1-f42.google.com with SMTP id
 ada2fe7eead31-4affd0fb6adso122683137.1
 for <xen-devel@lists.xenproject.org>; Thu, 16 Jan 2025 02:18:02 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2cfa2714-d3f3-11ef-99a4-01e77a169b0f
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737022683; x=1737627483;
        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=hEBC4YtYCJgyImQmIlExzdfeh9O+mJTPH+y0EtpZi1E=;
        b=cFlMQbca/9uuW0L+5UO8RweIm7QrdHkevAVxMd62FaepiMniJTCqTJo1P3QPo0wR1e
         M3pWB9hmoR4BcreDYotV1XsElKdRMaFUtZ+CdLTgWpoh3M0ZJVKDuYkqZfz/7E85jVh7
         jIDj/zfDXCclmxhxIywrr1Kv4TSo43LZTDFICooO4RZ+3wlSuMcBNzbzfDHBdh9YfWsu
         ge4/xbXlfKEMUDaxcQy0AM5VAtjz5HG6GgWw5eOjHAsc0JcWaE/vkkAWv/6Dim1a1rXP
         vEBfh76aNMy0wYLUeV6gMPh6I5APbvYnZlot668AhvpNjjBnsXezvywwnPjom2fraSj0
         hmgA==
X-Forwarded-Encrypted: i=1; AJvYcCX1wb5kCUl6+0XMsZK14abwrfsFRAHt+O41LgKIEgqvdzW3ZeuDy95ipmSTuBv4JHuEQehwpDnKKoA=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy8Awl44702/Y3s1xllZsMGav+qTRuk5ot+sfgmeDBuZkZ3/1OP
	KpLHTDlehR4IkT0MOVGBH83oEaajRMqoklxqsqGSRsIInFpuopmEPIY5iqzV9yk=
X-Gm-Gg: ASbGncto4/HtG7RNp6fzWHRpOTLqofplLXQQjcLrSXIPB/8ncufHG3IkGLrRizFJLEq
	fSYLznS53jxwHTAKBOu98tFJmzSzyzYsdd+CA00ehBip+SFKdx170iLsM3oIPBUZMWxvJvrqAn3
	6N7TZuG9E1j8KvMA+lnJbjh91NwejifWTX2iLrLftOukjjOptHuMuBhiWvU5Zv3YSoKmhG2vK7k
	5OOghp296kqWqs2iorEnWIlpfK53RiHyW8ekbXcVYJ1JS2WUAogfkTIIkDm+dw5CvGzxq6F6xa0
	GhkdiTuyMgKPdq4TIWY=
X-Google-Smtp-Source: AGHT+IEn+DiK94AD97xFvkks8gZpvRgA07p5b9xhDrGOwReQZ/SSyXzq1uadt8SF6Fj5fM+mI7Ltqw==
X-Received: by 2002:a05:6102:512c:b0:4b4:bec1:7368 with SMTP id ada2fe7eead31-4b4bec1796dmr27795246137.8.1737022683307;
        Thu, 16 Jan 2025 02:18:03 -0800 (PST)
X-Forwarded-Encrypted: i=1; AJvYcCUC6FO6J9ldLWuJ7vJX+hAZDxyA+czGWyPsvqQLDzzB5Ty89uEq5i/ndqG8OeLfbl+LzbaPaiE6wxI=@lists.xenproject.org
X-Received: by 2002:a05:6102:3a14:b0:4b2:5c2a:cc9d with SMTP id
 ada2fe7eead31-4b3d0dc0215mr29032050137.16.1737022681773; Thu, 16 Jan 2025
 02:18:01 -0800 (PST)
MIME-Version: 1.0
References: <20250109150310.219442-1-tzimmermann@suse.de> <20250109150310.219442-26-tzimmermann@suse.de>
 <cdbe483d-0895-47aa-8c83-1c28220f4a02@ideasonboard.com> <bc97b92e-7f8a-4b92-af8a-20fa165ead55@suse.de>
 <f3ba05c7-6e49-4641-a3f9-ba418ebdb7c3@ideasonboard.com> <c6735280-7c32-4319-8ca9-a7305d8117c3@suse.de>
 <d67adb03-5cd0-4ac9-af58-cf4446dacee3@ideasonboard.com> <0ea6be58-0e04-4172-87cd-064a3e4a43bc@suse.de>
 <f35cb350-6be9-48ca-ad7e-e9dd418281d5@ideasonboard.com> <4af0b6a7-c16a-4187-bbf5-365a9c86de21@suse.de>
 <e327ad84-b5c9-4480-b873-dc3aca605538@ideasonboard.com> <a2bbeb47-2569-4ee0-9265-92bab139bdc6@suse.de>
 <f3833771-fcd7-45dc-9019-1525fef34429@ideasonboard.com>
In-Reply-To: <f3833771-fcd7-45dc-9019-1525fef34429@ideasonboard.com>
From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: Thu, 16 Jan 2025 11:17:50 +0100
X-Gmail-Original-Message-ID: <CAMuHMdXxYa+Na3XxpLTy=-eUL_zQ9kAiUKYu-E04u3KWApusSA@mail.gmail.com>
X-Gm-Features: AbW1kvbCtGVmgNJ1oRyFqRTMVO1bCUCk0WwRoRvrPqq521tQuGLKMDrWmAM4CG4
Message-ID: <CAMuHMdXxYa+Na3XxpLTy=-eUL_zQ9kAiUKYu-E04u3KWApusSA@mail.gmail.com>
Subject: Re: [PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with drm_mode_size_dumb()
To: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>, maarten.lankhorst@linux.intel.com, 
	mripard@kernel.org, airlied@gmail.com, simona@ffwll.ch, 
	dri-devel@lists.freedesktop.org, linux-mediatek@lists.infradead.org, 
	freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org, 
	imx@lists.linux.dev, linux-samsung-soc@vger.kernel.org, 
	nouveau@lists.freedesktop.org, virtualization@lists.linux.dev, 
	spice-devel@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org, 
	linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org, 
	intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org, 
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Andy Yan <andyshrk@163.com>, 
	Daniel Stone <daniel@fooishbar.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 16, 2025 at 11:03=E2=80=AFAM Tomi Valkeinen
<tomi.valkeinen@ideasonboard.com> wrote:
> On 16/01/2025 10:09, Thomas Zimmermann wrote:
> > Am 15.01.25 um 15:20 schrieb Tomi Valkeinen:
> > [...]
> >>
> >> My point is that we have the current UAPI, and we have userspace using
> >> it, but we don't have clear rules what the ioctl does with specific
> >> parameters, and we don't document how it has to be used.
> >>
> >> Perhaps the situation is bad, and all we can really say is that
> >> CREATE_DUMB only works for use with simple RGB formats, and the
> >> behavior for all other formats is platform specific. But I think even
> >> that would be valuable in the UAPI docs.
> >
> > To be honest, I would not want to specify behavior for anything but the
> > linear RGB formats. If anything, I'd take Daniel's reply mail for
> > documentation as-is. Anyone stretching the UAPI beyond RGB is on their =
own.
> >
> >> Thinking about this, I wonder if this change is good for omapdrm or
> >> xilinx (probably other platforms too that support non-simple non-RGB
> >> formats via dumb buffers): without this patch, in both drivers, the
> >> pitch calculations just take the bpp as bit-per-pixels, align it up,
> >> and that's it.
> >>
> >> With this patch we end up using drm_driver_color_mode_format(), and
> >> aligning buffers according to RGB formats figured out via heuristics.
> >> It does happen to work, for the formats I tested, but it sounds like
> >> something that might easily not work, as it's doing adjustments based
> >> on wrong format.
> >>
> >> Should we have another version of drm_mode_size_dumb() which just
> >> calculates using the bpp, without the drm_driver_color_mode_format()
> >> path? Or does the drm_driver_color_mode_format() path provide some
> >> value for the drivers that do not currently do anything similar?
> >
> > With the RGB-only rule, using drm_driver_color_mode_format() makes
> > sense. It aligns dumb buffers and video=3D, provides error checking, an=
d
> > overall harmonizes code. The fallback is only required because of the
> > existing odd cases that already bend the UAPI's rules.
>
> I have to disagree here.
>
> On the platforms I have been using (omap, tidss, xilinx, rcar) the dumb
> buffers are the only buffers you can get from the DRM driver. The dumb
> buffers have been used to allocate linear and multiplanar YUV buffers
> for a very long time on those platforms.
>
> I tried to look around, but I did not find any mentions that CREATE_DUMB
> should only be used for RGB buffers. Is anyone outside the core
> developers even aware of it?
>
> If we don't use dumb buffers there, where do we get the buffers? Maybe
> from a v4l2 device or from a gpu device, but often you don't have those.
> DMA_HEAP is there, of course.

Why can't there be a variant that takes a proper fourcc format instead of
an imprecise bpp value?

Gr{oetje,eeting}s,

                        Geert

--=20
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k=
.org

In personal conversations with technical people, I call myself a hacker. Bu=
t
when I'm talking to journalists I just say "programmer" or something like t=
hat.
                                -- Linus Torvalds


From xen-devel-bounces@lists.xenproject.org Thu Jan 16 10:27:00 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 10:27:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873456.1284430 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYN5S-0002xU-QU; Thu, 16 Jan 2025 10:26:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873456.1284430; Thu, 16 Jan 2025 10:26:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYN5S-0002xN-M9; Thu, 16 Jan 2025 10:26:54 +0000
Received: by outflank-mailman (input) for mailman id 873456;
 Thu, 16 Jan 2025 10:26: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
 <SRS0=FBKk=UI=ideasonboard.com=tomi.valkeinen@srs-se1.protection.inumbo.net>)
 id 1tYN5S-0002xH-2F
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 10:26:54 +0000
Received: from perceval.ideasonboard.com (perceval.ideasonboard.com
 [213.167.242.64]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6711a08f-d3f4-11ef-a0e2-8be0dac302b0;
 Thu, 16 Jan 2025 11:26:52 +0100 (CET)
Received: from [192.168.88.20] (91-158-153-178.elisa-laajakaista.fi
 [91.158.153.178])
 by perceval.ideasonboard.com (Postfix) with ESMTPSA id 42498526;
 Thu, 16 Jan 2025 11:25:52 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 6711a08f-d3f4-11ef-a0e2-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;
	s=mail; t=1737023153;
	bh=Z7ediVkgoetAGoCSEC+NS9LE30jZLpQmaH2NAmg+fKo=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=sAbVtvKbp7o8SfyrbwqpGIwVYmdgJpMjZmC6qEgRNe2H25LicDH6k69guisjqJioP
	 8SncRl1CoC+3SXf6Y8cJQEuIj38aZG4lFFJrCQ0l8buZDLY37H2yUZEQna2GSs0Dn+
	 1llb/TtQTaZKCXEOlL7x1MNtOgUhrQcJ6XdrIu2U=
Message-ID: <710224b4-1b40-49e1-9985-3340c6e4138f@ideasonboard.com>
Date: Thu, 16 Jan 2025 12:26:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with
 drm_mode_size_dumb()
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>,
 maarten.lankhorst@linux.intel.com, mripard@kernel.org, airlied@gmail.com,
 simona@ffwll.ch, dri-devel@lists.freedesktop.org,
 linux-mediatek@lists.infradead.org, freedreno@lists.freedesktop.org,
 linux-arm-msm@vger.kernel.org, imx@lists.linux.dev,
 linux-samsung-soc@vger.kernel.org, nouveau@lists.freedesktop.org,
 virtualization@lists.linux.dev, spice-devel@lists.freedesktop.org,
 linux-renesas-soc@vger.kernel.org, linux-rockchip@lists.infradead.org,
 linux-tegra@vger.kernel.org, intel-xe@lists.freedesktop.org,
 xen-devel@lists.xenproject.org,
 Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
 Andy Yan <andyshrk@163.com>, Daniel Stone <daniel@fooishbar.org>
References: <20250109150310.219442-1-tzimmermann@suse.de>
 <20250109150310.219442-26-tzimmermann@suse.de>
 <cdbe483d-0895-47aa-8c83-1c28220f4a02@ideasonboard.com>
 <bc97b92e-7f8a-4b92-af8a-20fa165ead55@suse.de>
 <f3ba05c7-6e49-4641-a3f9-ba418ebdb7c3@ideasonboard.com>
 <c6735280-7c32-4319-8ca9-a7305d8117c3@suse.de>
 <d67adb03-5cd0-4ac9-af58-cf4446dacee3@ideasonboard.com>
 <0ea6be58-0e04-4172-87cd-064a3e4a43bc@suse.de>
 <f35cb350-6be9-48ca-ad7e-e9dd418281d5@ideasonboard.com>
 <4af0b6a7-c16a-4187-bbf5-365a9c86de21@suse.de>
 <e327ad84-b5c9-4480-b873-dc3aca605538@ideasonboard.com>
 <a2bbeb47-2569-4ee0-9265-92bab139bdc6@suse.de>
 <f3833771-fcd7-45dc-9019-1525fef34429@ideasonboard.com>
 <CAMuHMdXxYa+Na3XxpLTy=-eUL_zQ9kAiUKYu-E04u3KWApusSA@mail.gmail.com>
Content-Language: en-US
From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Autocrypt: addr=tomi.valkeinen@ideasonboard.com; keydata=
 xsFNBE6ms0cBEACyizowecZqXfMZtnBniOieTuFdErHAUyxVgtmr0f5ZfIi9Z4l+uUN4Zdw2
 wCEZjx3o0Z34diXBaMRJ3rAk9yB90UJAnLtb8A97Oq64DskLF81GCYB2P1i0qrG7UjpASgCA
 Ru0lVvxsWyIwSfoYoLrazbT1wkWRs8YBkkXQFfL7Mn3ZMoGPcpfwYH9O7bV1NslbmyJzRCMO
 eYV258gjCcwYlrkyIratlHCek4GrwV8Z9NQcjD5iLzrONjfafrWPwj6yn2RlL0mQEwt1lOvn
 LnI7QRtB3zxA3yB+FLsT1hx0va6xCHpX3QO2gBsyHCyVafFMrg3c/7IIWkDLngJxFgz6DLiA
 G4ld1QK/jsYqfP2GIMH1mFdjY+iagG4DqOsjip479HCWAptpNxSOCL6z3qxCU8MCz8iNOtZk
 DYXQWVscM5qgYSn+fmMM2qN+eoWlnCGVURZZLDjg387S2E1jT/dNTOsM/IqQj+ZROUZuRcF7
 0RTtuU5q1HnbRNwy+23xeoSGuwmLQ2UsUk7Q5CnrjYfiPo3wHze8avK95JBoSd+WIRmV3uoO
 rXCoYOIRlDhg9XJTrbnQ3Ot5zOa0Y9c4IpyAlut6mDtxtKXr4+8OzjSVFww7tIwadTK3wDQv
 Bus4jxHjS6dz1g2ypT65qnHen6mUUH63lhzewqO9peAHJ0SLrQARAQABzTBUb21pIFZhbGtl
 aW5lbiA8dG9taS52YWxrZWluZW5AaWRlYXNvbmJvYXJkLmNvbT7CwY4EEwEIADgWIQTEOAw+
 ll79gQef86f6PaqMvJYe9QUCX/HruAIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRD6
 PaqMvJYe9WmFD/99NGoD5lBJhlFDHMZvO+Op8vCwnIRZdTsyrtGl72rVh9xRfcSgYPZUvBuT
 VDxE53mY9HaZyu1eGMccYRBaTLJSfCXl/g317CrMNdY0k40b9YeIX10feiRYEWoDIPQ3tMmA
 0nHDygzcnuPiPT68JYZ6tUOvAt7r6OX/litM+m2/E9mtp8xCoWOo/kYO4mOAIoMNvLB8vufi
 uBB4e/AvAjtny4ScuNV5c5q8MkfNIiOyag9QCiQ/JfoAqzXRjVb4VZG72AKaElwipiKCWEcU
 R4+Bu5Qbaxj7Cd36M/bI54OrbWWETJkVVSV1i0tghCd6HHyquTdFl7wYcz6cL1hn/6byVnD+
 sR3BLvSBHYp8WSwv0TCuf6tLiNgHAO1hWiQ1pOoXyMEsxZlgPXT+wb4dbNVunckwqFjGxRbl
 Rz7apFT/ZRwbazEzEzNyrBOfB55xdipG/2+SmFn0oMFqFOBEszXLQVslh64lI0CMJm2OYYe3
 PxHqYaztyeXsx13Bfnq9+bUynAQ4uW1P5DJ3OIRZWKmbQd/Me3Fq6TU57LsvwRgE0Le9PFQs
 dcP2071rMTpqTUteEgODJS4VDf4lXJfY91u32BJkiqM7/62Cqatcz5UWWHq5xeF03MIUTqdE
 qHWk3RJEoWHWQRzQfcx6Fn2fDAUKhAddvoopfcjAHfpAWJ+ENc7BTQROprNHARAAx0aat8GU
 hsusCLc4MIxOQwidecCTRc9Dz/7U2goUwhw2O5j9TPqLtp57VITmHILnvZf6q3QAho2QMQyE
 DDvHubrdtEoqaaSKxKkFie1uhWNNvXPhwkKLYieyL9m2JdU+b88HaDnpzdyTTR4uH7wk0bBa
 KbTSgIFDDe5lXInypewPO30TmYNkFSexnnM3n1PBCqiJXsJahE4ZQ+WnV5FbPUj8T2zXS2xk
 0LZ0+DwKmZ0ZDovvdEWRWrz3UzJ8DLHb7blPpGhmqj3ANXQXC7mb9qJ6J/VSl61GbxIO2Dwb
 xPNkHk8fwnxlUBCOyBti/uD2uSTgKHNdabhVm2dgFNVuS1y3bBHbI/qjC3J7rWE0WiaHWEqy
 UVPk8rsph4rqITsj2RiY70vEW0SKePrChvET7D8P1UPqmveBNNtSS7In+DdZ5kUqLV7rJnM9
 /4cwy+uZUt8cuCZlcA5u8IsBCNJudxEqBG10GHg1B6h1RZIz9Q9XfiBdaqa5+CjyFs8ua01c
 9HmyfkuhXG2OLjfQuK+Ygd56mV3lq0aFdwbaX16DG22c6flkkBSjyWXYepFtHz9KsBS0DaZb
 4IkLmZwEXpZcIOQjQ71fqlpiXkXSIaQ6YMEs8WjBbpP81h7QxWIfWtp+VnwNGc6nq5IQDESH
 mvQcsFS7d3eGVI6eyjCFdcAO8eMAEQEAAcLBXwQYAQIACQUCTqazRwIbDAAKCRD6PaqMvJYe
 9fA7EACS6exUedsBKmt4pT7nqXBcRsqm6YzT6DeCM8PWMTeaVGHiR4TnNFiT3otD5UpYQI7S
 suYxoTdHrrrBzdlKe5rUWpzoZkVK6p0s9OIvGzLT0lrb0HC9iNDWT3JgpYDnk4Z2mFi6tTbq
 xKMtpVFRA6FjviGDRsfkfoURZI51nf2RSAk/A8BEDDZ7lgJHskYoklSpwyrXhkp9FHGMaYII
 m9EKuUTX9JPDG2FTthCBrdsgWYPdJQvM+zscq09vFMQ9Fykbx5N8z/oFEUy3ACyPqW2oyfvU
 CH5WDpWBG0s5BALp1gBJPytIAd/pY/5ZdNoi0Cx3+Z7jaBFEyYJdWy1hGddpkgnMjyOfLI7B
 CFrdecTZbR5upjNSDvQ7RG85SnpYJTIin+SAUazAeA2nS6gTZzumgtdw8XmVXZwdBfF+ICof
 92UkbYcYNbzWO/GHgsNT1WnM4sa9lwCSWH8Fw1o/3bX1VVPEsnESOfxkNdu+gAF5S6+I6n3a
 ueeIlwJl5CpT5l8RpoZXEOVtXYn8zzOJ7oGZYINRV9Pf8qKGLf3Dft7zKBP832I3PQjeok7F
 yjt+9S+KgSFSHP3Pa4E7lsSdWhSlHYNdG/czhoUkSCN09C0rEK93wxACx3vtxPLjXu6RptBw
 3dRq7n+mQChEB1am0BueV1JZaBboIL0AGlSJkm23kw==
In-Reply-To: <CAMuHMdXxYa+Na3XxpLTy=-eUL_zQ9kAiUKYu-E04u3KWApusSA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi,

On 16/01/2025 12:17, Geert Uytterhoeven wrote:
> On Thu, Jan 16, 2025 at 11:03 AM Tomi Valkeinen
> <tomi.valkeinen@ideasonboard.com> wrote:
>> On 16/01/2025 10:09, Thomas Zimmermann wrote:
>>> Am 15.01.25 um 15:20 schrieb Tomi Valkeinen:
>>> [...]
>>>>
>>>> My point is that we have the current UAPI, and we have userspace using
>>>> it, but we don't have clear rules what the ioctl does with specific
>>>> parameters, and we don't document how it has to be used.
>>>>
>>>> Perhaps the situation is bad, and all we can really say is that
>>>> CREATE_DUMB only works for use with simple RGB formats, and the
>>>> behavior for all other formats is platform specific. But I think even
>>>> that would be valuable in the UAPI docs.
>>>
>>> To be honest, I would not want to specify behavior for anything but the
>>> linear RGB formats. If anything, I'd take Daniel's reply mail for
>>> documentation as-is. Anyone stretching the UAPI beyond RGB is on their own.
>>>
>>>> Thinking about this, I wonder if this change is good for omapdrm or
>>>> xilinx (probably other platforms too that support non-simple non-RGB
>>>> formats via dumb buffers): without this patch, in both drivers, the
>>>> pitch calculations just take the bpp as bit-per-pixels, align it up,
>>>> and that's it.
>>>>
>>>> With this patch we end up using drm_driver_color_mode_format(), and
>>>> aligning buffers according to RGB formats figured out via heuristics.
>>>> It does happen to work, for the formats I tested, but it sounds like
>>>> something that might easily not work, as it's doing adjustments based
>>>> on wrong format.
>>>>
>>>> Should we have another version of drm_mode_size_dumb() which just
>>>> calculates using the bpp, without the drm_driver_color_mode_format()
>>>> path? Or does the drm_driver_color_mode_format() path provide some
>>>> value for the drivers that do not currently do anything similar?
>>>
>>> With the RGB-only rule, using drm_driver_color_mode_format() makes
>>> sense. It aligns dumb buffers and video=, provides error checking, and
>>> overall harmonizes code. The fallback is only required because of the
>>> existing odd cases that already bend the UAPI's rules.
>>
>> I have to disagree here.
>>
>> On the platforms I have been using (omap, tidss, xilinx, rcar) the dumb
>> buffers are the only buffers you can get from the DRM driver. The dumb
>> buffers have been used to allocate linear and multiplanar YUV buffers
>> for a very long time on those platforms.
>>
>> I tried to look around, but I did not find any mentions that CREATE_DUMB
>> should only be used for RGB buffers. Is anyone outside the core
>> developers even aware of it?
>>
>> If we don't use dumb buffers there, where do we get the buffers? Maybe
>> from a v4l2 device or from a gpu device, but often you don't have those.
>> DMA_HEAP is there, of course.
> 
> Why can't there be a variant that takes a proper fourcc format instead of
> an imprecise bpp value?

There can, but it's somewhat a different topic, although it's been 
covered a bit in this thread.

My specific concern here is the current CREATE_DUMB, and (not) changing 
how it behaves.

  Tomi



From xen-devel-bounces@lists.xenproject.org Thu Jan 16 10:28:21 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 10:28:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873467.1284439 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYN6q-0003Wo-6P; Thu, 16 Jan 2025 10:28:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873467.1284439; Thu, 16 Jan 2025 10:28:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYN6q-0003Wh-3j; Thu, 16 Jan 2025 10:28:20 +0000
Received: by outflank-mailman (input) for mailman id 873467;
 Thu, 16 Jan 2025 10:28:18 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=WMgP=UI=bugseng.com=nicola.vetrini@srs-se1.protection.inumbo.net>)
 id 1tYN6o-0003WW-Gk
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 10:28:18 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9829547f-d3f4-11ef-99a4-01e77a169b0f;
 Thu, 16 Jan 2025 11:28:15 +0100 (CET)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 by support.bugseng.com (Postfix) with ESMTPA id 4FC584EED422;
 Thu, 16 Jan 2025 11:28:14 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9829547f-d3f4-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1737023294; bh=AUwWCNjvcshp1xbXU9Tk31xqxAFJO1NKUVDP+VWCffc=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=cbE7avJ0Ee2wGfzR/NVEfGUswCf/fzOJhaQwLinqNIfk/vV4gNUAlEnbApC2MirnD
	 Ge1mObVIrGZTwnDznn6mdzd5bdGMS4mc1/FOhxuudGO47DsmMIrFq8lkYsoDLr4xw5
	 ck9aesQROo6axhXS5l4qbXppaJzACcGd1LGdTR+QGFEKVitrDDv/vI4U3DQliXAmk/
	 eHtNJc4exqRkv4DiyX1EwxDT4ePbsvBay3yLAJ5zhJoIqtFnemf+6JKZNkrziIAF0N
	 +aN6Lw+hS3gfTeDKveijsCsQWazB68INTra27ErEGY8IEGy0IIE7rzzZhthXu7vlMn
	 zwIw9qCh9LFLw==
MIME-Version: 1.0
Date: Thu, 16 Jan 2025 11:28:14 +0100
From: Nicola Vetrini <nicola.vetrini@bugseng.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com, Andrew Cooper
 <andrew.cooper3@citrix.com>, Anthony PERARD <anthony.perard@vates.tech>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [XEN PATCH] docs/misra: Document ECLAIR extension to Rule 20.7
In-Reply-To: <d90e5496-cccf-4670-8332-8d2e5f482c5e@suse.com>
References: <77354513a986a14c37ec2dfc45cf3534b08b5e85.1736972547.git.nicola.vetrini@bugseng.com>
 <d90e5496-cccf-4670-8332-8d2e5f482c5e@suse.com>
Message-ID: <48035a91703c82c82e9c5239fb6373a7@bugseng.com>
X-Sender: nicola.vetrini@bugseng.com
Organization: BUGSENG s.r.l.
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit

On 2025-01-16 10:51, Jan Beulich wrote:
> On 16.01.2025 10:31, Nicola Vetrini wrote:
>> MISRA C Rule 20.7 states:
>> "Expressions resulting from the expansion of macro parameters shall
>> be enclosed in parentheses".
>> 
>> Document the behaviour of ECLAIR with respect to the CPP extension
>> that allows variable macro arguments to be named.
>> 
>> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
>> ---
>>  docs/misra/rules.rst | 9 ++++++++-
>>  1 file changed, 8 insertions(+), 1 deletion(-)
>> 
>> diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
>> index e7763795b826..13890f6d8852 100644
>> --- a/docs/misra/rules.rst
>> +++ b/docs/misra/rules.rst
>> @@ -671,7 +671,14 @@ maintainers if you want to suggest a change.
>>         shall be enclosed in parentheses
>>       - Extra parentheses are not required when macro parameters are 
>> used
>>         as function arguments, as macro arguments, array indices, lhs 
>> in
>> -       assignments or as initializers in initalizer lists.
>> +       assignments or as initializers in initalizer lists. In 
>> addition,
>> +       the use of a named variable argument in a macro that would 
>> constitute
>> +       a violation of the rule is allowed by ECLAIR as an extension 
>> of the
>> +       MISRA, since it may not always be possible to parenthesize 
>> such
> 
> Just one nit / question (addressable while committing, if desired): I
> wouldn't have expected "the" before "MISRA". Is that conventional 
> wording
> in your environment?
> 
> Jan

Hi Jan,

that was just a typo. It should have been "the MISRA guideline".
Thanks for catching that

> 
>> +       argument and the feature is non-standard::
>> +
>> +         #define M(args...) args
>> +         #if M(1) + 0
>> 
>>     * - `Rule 20.9 
>> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_20_09.c>`_
>>       - Required

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253


From xen-devel-bounces@lists.xenproject.org Thu Jan 16 10:35:56 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 10:35:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873477.1284449 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYNDx-0005qt-SI; Thu, 16 Jan 2025 10:35:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873477.1284449; Thu, 16 Jan 2025 10:35:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYNDx-0005qm-Pb; Thu, 16 Jan 2025 10:35:41 +0000
Received: by outflank-mailman (input) for mailman id 873477;
 Thu, 16 Jan 2025 10:35: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
 <SRS0=Ynob=UI=linaro.org=dmitry.baryshkov@srs-se1.protection.inumbo.net>)
 id 1tYNDw-0005qg-F0
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 10:35:40 +0000
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com
 [2a00:1450:4864:20::12e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a109da01-d3f5-11ef-a0e2-8be0dac302b0;
 Thu, 16 Jan 2025 11:35:39 +0100 (CET)
Received: by mail-lf1-x12e.google.com with SMTP id
 2adb3069b0e04-53e3a227b82so807162e87.0
 for <xen-devel@lists.xenproject.org>; Thu, 16 Jan 2025 02:35:39 -0800 (PST)
Received: from eriador.lumag.spb.ru
 (2001-14ba-a0c3-3a00--7a1.rev.dnainternet.fi. [2001:14ba:a0c3:3a00::7a1])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5428be49d6esm2261466e87.50.2025.01.16.02.35.36
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 16 Jan 2025 02:35:37 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a109da01-d3f5-11ef-a0e2-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737023739; x=1737628539; 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=gprmJm/Cl6p6869D60XQ3XjbtrOWLJEOxZITgqe2J5o=;
        b=lqL10bD5pgrxDq3KrLUOAGIonABZqzHhNRom95aE6yd66xWDUlFnCjYUN2/pjnqOoC
         nvZaPuB4sAW/Fz8Z6aEcaLOn1DslcIjmfANKAigMUGMeyzLRKpC2l0ggxGXZQi1veXKF
         n0h1WotkOW6bmzZBuEzn2/SrJghge+0z9hmvUSEQ5iPsmEF3ZE1GpYJA9jLVFI+EkyLa
         Io60Y1cRqHsgAOlUcp/CMf+1KtWQ9QrHCm5/c1P38qnpZ+jRlmHvvdknjwHZQWTDXyhq
         Dv6DjNfg23uw7hqH70GMlyynC/1y2jqVnzqscZfPWH6lECED7YJhMUbIZhp4vPCyOWwD
         FHLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737023739; x=1737628539;
        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=gprmJm/Cl6p6869D60XQ3XjbtrOWLJEOxZITgqe2J5o=;
        b=svvSwlJinAOtD2rfZ89S9AaYd7ofbQG/rd3Vf3nP30pKUCmCvXu8zmUIZP+lKx8fnO
         ggyWEvw5aaoflU3h9qVT85cmezr5/z0M/+is1jFBypSi/FwK2oDFSMziHbRle3VyY8Ex
         T+oZzwbKkrwwgOOOdiwPzwUhFB6TYrmaDOcVX8DuXgahwl8LWjU/rF65DeU4FfYi7E/P
         qdUdIVFd5wW91ze06TQKpKrRR2xhnRO+zGk5SNyWkHkSNcnA9Fim0EcNl426GZFYmkHb
         hvtZ56gNsC0V0qKQy/vH1AAOuA+x/KbXWqntSfk716iU6UHIuXfA7Iw58LAnoyKFySFq
         mHXA==
X-Forwarded-Encrypted: i=1; AJvYcCWpvIbJWcnuzipW2F91OO3RkBdvFcTGok/NkkiUteQVxvoaJMMM21T26jCBnaifvBqHqohBwGsjEG4=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx5TxHCJnfLUhKlLjYr7aKpJj0xK+5UdlWhIerrTNxBRuTOff/K
	HZNWtNWlWJF3ycIIFi52cfxdUpByYiein3dfdA+HkZQwqTZ/bJa8UIWtiIOHMHI=
X-Gm-Gg: ASbGncsQeHu1Y9Z1rD/TIidDnV+T5/Opc1HKtC+5NsdIAkNKkdlf1b5g7CqA6s9yqf9
	MLM7NI5/+yoHzSfcpZtlFp+BXMS8xjAKGyEQj76zjYTc70hmTh9EljdvmfeSceNbnAy8KIm9dIw
	6bO2rO0+MZSnbYReKAl/ijKiGdhSKX+enVhmNysFQsuwn6sI9tPqR5XbKSXJJED4fmhoTWQ1Ku5
	fo+IC80hkn7WWpvAd+4+PHp0m/4TZ5oOl/wjljXrqa7WdrjYDjK9KOo2JjpQu/IHB/8bCDTlZeU
	ZT971Db23UB+68S/Hti9q2WE5+94J69DahNp
X-Google-Smtp-Source: AGHT+IH3G1Mnr8k23AF5/dIs7iAuJyOHJCwOMDmvWc4umnN+swRWG+FLBCp9QsFSdvm1xDWFrQeEdg==
X-Received: by 2002:a05:6512:3d27:b0:540:20a9:9ab5 with SMTP id 2adb3069b0e04-54284824476mr9777793e87.50.1737023738809;
        Thu, 16 Jan 2025 02:35:38 -0800 (PST)
Date: Thu, 16 Jan 2025 12:35:35 +0200
From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>, 
	Thomas Zimmermann <tzimmermann@suse.de>, maarten.lankhorst@linux.intel.com, mripard@kernel.org, 
	airlied@gmail.com, simona@ffwll.ch, dri-devel@lists.freedesktop.org, 
	linux-mediatek@lists.infradead.org, freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org, 
	imx@lists.linux.dev, linux-samsung-soc@vger.kernel.org, nouveau@lists.freedesktop.org, 
	virtualization@lists.linux.dev, spice-devel@lists.freedesktop.org, 
	linux-renesas-soc@vger.kernel.org, linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org, 
	intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org, 
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Andy Yan <andyshrk@163.com>, Daniel Stone <daniel@fooishbar.org>
Subject: Re: [PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with
 drm_mode_size_dumb()
Message-ID: <xz5ncq67bgmdase2jg3cfvyaxpiwhol2eqpfzow6dqpauvslo5@2w3rw27lhnxo>
References: <f3ba05c7-6e49-4641-a3f9-ba418ebdb7c3@ideasonboard.com>
 <c6735280-7c32-4319-8ca9-a7305d8117c3@suse.de>
 <d67adb03-5cd0-4ac9-af58-cf4446dacee3@ideasonboard.com>
 <0ea6be58-0e04-4172-87cd-064a3e4a43bc@suse.de>
 <f35cb350-6be9-48ca-ad7e-e9dd418281d5@ideasonboard.com>
 <4af0b6a7-c16a-4187-bbf5-365a9c86de21@suse.de>
 <e327ad84-b5c9-4480-b873-dc3aca605538@ideasonboard.com>
 <a2bbeb47-2569-4ee0-9265-92bab139bdc6@suse.de>
 <f3833771-fcd7-45dc-9019-1525fef34429@ideasonboard.com>
 <CAMuHMdXxYa+Na3XxpLTy=-eUL_zQ9kAiUKYu-E04u3KWApusSA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAMuHMdXxYa+Na3XxpLTy=-eUL_zQ9kAiUKYu-E04u3KWApusSA@mail.gmail.com>

On Thu, Jan 16, 2025 at 11:17:50AM +0100, Geert Uytterhoeven wrote:
> On Thu, Jan 16, 2025 at 11:03 AM Tomi Valkeinen
> <tomi.valkeinen@ideasonboard.com> wrote:
> > On 16/01/2025 10:09, Thomas Zimmermann wrote:
> > > Am 15.01.25 um 15:20 schrieb Tomi Valkeinen:
> > > [...]
> > >>
> > >> My point is that we have the current UAPI, and we have userspace using
> > >> it, but we don't have clear rules what the ioctl does with specific
> > >> parameters, and we don't document how it has to be used.
> > >>
> > >> Perhaps the situation is bad, and all we can really say is that
> > >> CREATE_DUMB only works for use with simple RGB formats, and the
> > >> behavior for all other formats is platform specific. But I think even
> > >> that would be valuable in the UAPI docs.
> > >
> > > To be honest, I would not want to specify behavior for anything but the
> > > linear RGB formats. If anything, I'd take Daniel's reply mail for
> > > documentation as-is. Anyone stretching the UAPI beyond RGB is on their own.
> > >
> > >> Thinking about this, I wonder if this change is good for omapdrm or
> > >> xilinx (probably other platforms too that support non-simple non-RGB
> > >> formats via dumb buffers): without this patch, in both drivers, the
> > >> pitch calculations just take the bpp as bit-per-pixels, align it up,
> > >> and that's it.
> > >>
> > >> With this patch we end up using drm_driver_color_mode_format(), and
> > >> aligning buffers according to RGB formats figured out via heuristics.
> > >> It does happen to work, for the formats I tested, but it sounds like
> > >> something that might easily not work, as it's doing adjustments based
> > >> on wrong format.
> > >>
> > >> Should we have another version of drm_mode_size_dumb() which just
> > >> calculates using the bpp, without the drm_driver_color_mode_format()
> > >> path? Or does the drm_driver_color_mode_format() path provide some
> > >> value for the drivers that do not currently do anything similar?
> > >
> > > With the RGB-only rule, using drm_driver_color_mode_format() makes
> > > sense. It aligns dumb buffers and video=, provides error checking, and
> > > overall harmonizes code. The fallback is only required because of the
> > > existing odd cases that already bend the UAPI's rules.
> >
> > I have to disagree here.
> >
> > On the platforms I have been using (omap, tidss, xilinx, rcar) the dumb
> > buffers are the only buffers you can get from the DRM driver. The dumb
> > buffers have been used to allocate linear and multiplanar YUV buffers
> > for a very long time on those platforms.
> >
> > I tried to look around, but I did not find any mentions that CREATE_DUMB
> > should only be used for RGB buffers. Is anyone outside the core
> > developers even aware of it?
> >
> > If we don't use dumb buffers there, where do we get the buffers? Maybe
> > from a v4l2 device or from a gpu device, but often you don't have those.
> > DMA_HEAP is there, of course.
> 
> Why can't there be a variant that takes a proper fourcc format instead of
> an imprecise bpp value?

Backwards compatibility. We can add an IOCTL for YUV / etc. But
userspace must be able to continue allocating YUV buffers through
CREATE_DUMB.

> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> -- 
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

-- 
With best wishes
Dmitry


From xen-devel-bounces@lists.xenproject.org Thu Jan 16 10:43:37 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 10:43:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873454.1284459 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYNLY-0007vZ-KJ; Thu, 16 Jan 2025 10:43:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873454.1284459; Thu, 16 Jan 2025 10:43:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYNLY-0007vS-GP; Thu, 16 Jan 2025 10:43:32 +0000
Received: by outflank-mailman (input) for mailman id 873454;
 Thu, 16 Jan 2025 10:23:03 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=g7wr=UI=ventanamicro.com=rkrcmar@srs-se1.protection.inumbo.net>)
 id 1tYN1j-0002tB-JE
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 10:23:03 +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 dd282102-d3f3-11ef-99a4-01e77a169b0f;
 Thu, 16 Jan 2025 11:23:01 +0100 (CET)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-385e971a2a0so33030f8f.1
 for <xen-devel@lists.xenproject.org>; Thu, 16 Jan 2025 02:23:01 -0800 (PST)
Received: from localhost (ip-89-103-73-235.bb.vodafone.cz. [89.103.73.235])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-437c74ac207sm54165545e9.12.2025.01.16.02.23.00
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 16 Jan 2025 02:23:00 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: dd282102-d3f3-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=ventanamicro.com; s=google; t=1737022981; x=1737627781; darn=lists.xenproject.org;
        h=in-reply-to:references:from:to:cc:subject:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=8ZkvdDnyLVGp1IEy4txVMz8RNqPNLFiF+bNPBLcxx30=;
        b=Q3FL8DgKV9p0YvrpItuCmw0U4uTrTIv2G40G1LsSTxdiKazpL9EJ/k4kDzPUz1ZueW
         u4VCiimImlJtsYBqMP46Tve0+C0S4emjhkDLYifi+5a3zbWjjvqrNFhYhLHlm/qFrRuf
         c7+a1fDo8M0ObcOOAlGwir4to2ke9vqPPL8LlZf6OVIl97IDB70r410tYLaZtoLMoBGS
         v3tBA3hGduRqgr3N1b8vkQhKDc64uVbldLnKnBYOx2XkNikmqg40DeSMoZmoPF0xohql
         3AdanCtoolkWHnQsfJid13ZQfgtvAiptTy8oceE8S/IYJl7/Y7FMmgCeO+4p+DpmoiOi
         M9sw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737022981; x=1737627781;
        h=in-reply-to:references:from:to:cc:subject:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=8ZkvdDnyLVGp1IEy4txVMz8RNqPNLFiF+bNPBLcxx30=;
        b=F9omrVKzCUt6ZwYH65lvnSoTq5OuUXLui3sVtIE6jkratZnklQmiJXV3RdtWNApfCC
         egMwp6pxRDD88NhxArjFQw5WhzMWBs7GKHA990S4+aoMPo7PTV63kBqSklcNVQbJs6Wp
         roc+xGUDeppxaSuyU7OlrbldwVXFAcNZOJ2p0S8N16a05EIPPSYf04T38YV+hyk2EprV
         vMgSvlZgoRqWWUSdHk7TG+JMxOZvFOdI41xFjQ7tRH5K1Eez+MzHXAs8sqiRLmUNIApX
         oSMVuVYyT9A2ZeDrsbCT+nzSwcMdqXgzl3QvBjG//6yjA+8D+GmPBo+vU7/EuXV32Crb
         PGCw==
X-Forwarded-Encrypted: i=1; AJvYcCX/m4dVZ9L3zDsxJRmw5xiBfFXlrZwBkUf+2j29H4y1jBQ19ufFIQvFBkB+8EoC+/SzEnqe242cSiY=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz8ZM9H0bA+eq8jSRH6Oep17+ZT6YlDML2DsntOfHb2noXcEjr7
	/7167y316rDNXnhY0+nsgF3TVNBRjR2Xt4AdhoGX9flge0Lrb6CONTiPUKjBw2s=
X-Gm-Gg: ASbGnct6ryw6wC640lovGCtsu1Nb7sReyutF8cnTM8yIToX9vaYVYaYN2/ppx12aIw2
	m0d7WB+MhDvLj33b1WuKquZMfgQajWa2hgNqbH+a0xhO6tb8AQMKnEbzYjKlIlT6OE9jOV+aDXs
	AuPWcjzx1o1V6rqGtWUjeBE1L3AWFh3SdRCIZmZYTkefa5HCVKAVjKuHojNFdB/lfKX/AsdIJba
	yfssFBt+BsqH4LsYi3x+S3a6yoV1nsf0F8lB9I/IxkdQiee6jDTAUmd9uwDdsQPhw12+wb+uMzJ
	GhFaCuV+ZkTuCEL/
X-Google-Smtp-Source: AGHT+IGRoCDvefbFzC6jI8eoiyaJwQY+MVagscMSk1SQP59pQNBBzH+/Z2VgQqY5H4m/ta4tZ/nIKw==
X-Received: by 2002:a5d:5848:0:b0:385:f7a3:fec1 with SMTP id ffacd0b85a97d-38a872dc81dmr10932658f8f.3.1737022980865;
        Thu, 16 Jan 2025 02:23:00 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Thu, 16 Jan 2025 11:22:59 +0100
Message-Id: <D73F98QBJ4S9.3CN2ZUQ0GSMT6@ventanamicro.com>
Subject: Re: [PATCH] riscv: Add initial Xen guest support for RISC-V
Cc: <linux-riscv@lists.infradead.org>, <jgross@suse.com>,
 <aou@eecs.berkeley.edu>, <Milan.Djokic@rt-rk.com>,
 <rafael.j.wysocki@intel.com>, <linux-kernel@vger.kernel.org>,
 <oleksandr_tyshchenko@epam.com>, <iommu@lists.linux.dev>,
 <sstabellini@kernel.org>, <palmer@dabbelt.com>, <paul.walmsley@sifive.com>,
 <xen-devel@lists.xenproject.org>, <Slavisa.Petrovic@rt-rk.com>,
 <takakura@valinux.co.jp>, "linux-riscv"
 <linux-riscv-bounces@lists.infradead.org>
To: "Andrew Jones" <ajones@ventanamicro.com>,
 =?utf-8?q?Milan_=C4=90oki=C4=87?= <milandjokic1995@gmail.com>
From: =?utf-8?q?Radim_Kr=C4=8Dm=C3=A1=C5=99?= <rkrcmar@ventanamicro.com>
References: <e4a649a7fdfc8fcf5f48a0bc4e76e5d546078083.1736868605.git.Slavisa.Petrovic@rt-rk.com> <20250114-316084c962eb867c0b681043@orel> <CAKp59VFkW8F2xHsgAxiw138ZrpQJL8R5cTkF8f9vY40iEoRbWg@mail.gmail.com> <20250116-aa9eadde9279e66dbc01c705@orel>
In-Reply-To: <20250116-aa9eadde9279e66dbc01c705@orel>

2025-01-16T09:51:25+01:00, Andrew Jones <ajones@ventanamicro.com>:
> On Wed, Jan 15, 2025 at 08:04:05PM +0100, Milan =C4=90oki=C4=87 wrote:
>> On Tue, Jan 14, 2025 at 7:18=E2=80=AFPM Andrew Jones <ajones@ventanamicr=
o.com> wrote:
>> > On Tue, Jan 14, 2025 at 05:09:36PM +0100, Milan Djokic wrote:
>> > > +#define SBI_ECALL 0xE
>> >
>> > Shouldn't this be 0xA000007, i.e. the SBI firmware specific extension
>> > for Xen. Otherwise why refer to SBI? Note, '0xE' is an invalid, legacy
>> > extension ID in SBI.
>> >
>> Hypercall is triggered through SBI and we defined 0xE just as an
>> SBI_ECALL ID on Xen side for hypercall handling (among other operation
>> IDs), so we're not referring to some standard /legacy ID here, just
>> utilizing SBI for hypercall handling.
>
> If the SBI specified EIDs and binary encoding aren't used, then the
> hypercalls aren't "triggered through SBI", Xen is just doing its own
> thing on an ecall. Xen doesn't have to implement SBI at all, but if
> it wants to provide SBI services, as well as its own hypercalls, then
> the hypercalls should be encoded in the same way as SBI functions and
> an EID allowed by the SBI specification for hypervisor-specific
> functions should be used. For Xen, that EID is already specified and
> it's 0xA000007.

SBI specifies a complete calling convention, but it's not necessary for
binary compatibility.  SBI also aims to simplify caller API.

Linux maintainers will want a good reason for introducing separate Xen
SBI call functions/macros (linux already has sbi_ecall, so please try to
use and potentially improve it), but the ECALL is guaranteed to be SBI
compatible as long as a7=3D0xA000007.

a7 is needed to denote Xen's extension space and the remaining
input/output registers can be implemented in any way Xen wants.


From xen-devel-bounces@lists.xenproject.org Thu Jan 16 10:58:24 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 10:58:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873495.1284468 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYNZq-000254-PO; Thu, 16 Jan 2025 10:58:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873495.1284468; Thu, 16 Jan 2025 10:58:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYNZq-00024x-Mp; Thu, 16 Jan 2025 10:58:18 +0000
Received: by outflank-mailman (input) for mailman id 873495;
 Thu, 16 Jan 2025 10:58: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
 <SRS0=EPy+=UI=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tYNZq-00024r-7i
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 10:58:18 +0000
Received: from mail-ed1-x542.google.com (mail-ed1-x542.google.com
 [2a00:1450:4864:20::542])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c9cae44e-d3f8-11ef-a0e2-8be0dac302b0;
 Thu, 16 Jan 2025 11:58:16 +0100 (CET)
Received: by mail-ed1-x542.google.com with SMTP id
 4fb4d7f45d1cf-5d0ac27b412so1077682a12.1
 for <xen-devel@lists.xenproject.org>; Thu, 16 Jan 2025 02:58:16 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c905ecb7sm890094966b.26.2025.01.16.02.58.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 16 Jan 2025 02:58:11 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c9cae44e-d3f8-11ef-a0e2-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737025096; x=1737629896; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=j/pgzfJHVhqJBf5aofeh4mqtiSZ1isoUvxZ/YYTT6lc=;
        b=gEF/SVOdaR6Wxsa4IwoLd4a8Zt4Hx55nM4DulpZYyXtrACXZUZRLxZIeRF/Xfe1UXZ
         /Ebfskr4yuAnOf6awHu5oE9QX2qfCQCBwMVbYV2Ixc779MmBsbtZ9OJ3JnbLvIigQd7I
         01qKQ9SlCWNBoNzvKnpThdFMcTqi5mbO5XzZw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737025096; x=1737629896;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=j/pgzfJHVhqJBf5aofeh4mqtiSZ1isoUvxZ/YYTT6lc=;
        b=GSxaqWfMLjkM+esgvGMbnM/vG9KbPrMTS+Cmw0Z1Bj/amcQGJd9QC1qSRUTXHCidRw
         xbbgvhFTUO0gmRw4HmDJRT7HYyA3ZI1VTpqYUpP+70OrvA+EKxHFSMjP840dQe88EjFB
         +g7IfiKPlIJRiazO/RaAlQU7ApO+iWNzZZuNHizEwzVzj5Uk2WiKC/9wFRg0pZRWR505
         rs/zLJQjuMUw9kaA5Se30dlxpy42m1MFxiyleuLI8PMWUGi9MWAmUmwETrdVCIhr1GxL
         msWykQ4IQwjYa+Ij6yq4Mq5/mqNCB2D4tZvsWQ3dVFHZABeSv+tKTZrJpN/TDMDjL7KT
         djpg==
X-Forwarded-Encrypted: i=1; AJvYcCUF2TZqzOrafiy8PZZ1FzlLO1oXck39/IrqESQpkqkxIxij98USDpTD6kItfiY1cXoVj9tQIInoMSE=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyq3AsZrNRK8pr3VerVcWp+A2siFTN3jDCN/6yBIiaF++yCierQ
	QyjzxEHASQRGj7NyWIpsJy98I9eUzZBLvSzWMpJdzn6z2STnrmExfh87BS7NPDs=
X-Gm-Gg: ASbGncsUeCacOsmrGoK4n0GKEGozA8c158nJYF6xQIy3k87XTVFuav6IbPxa9OwBrK3
	3coHfzHrHC4RRvDEyw6VnQ9d1jaW8Y92j247U8XdRLyn6lHiAaF1MA0fgVZ7JJxCdDpe43+Q8s5
	6NB17k9bv25P/U5sOFHLMpRrCP1cu+lTTuK7pAurpMcoIPouifvc04KTwBfR5hzlc6EiA436/oS
	IHUmqD6KrXg/IMRbzbStOKVJum+c0cEFU6NJL4IJSO0+UYPDIU50boNZc8wbarVDSAMfMS9ET2U
	uEmkxC/ulasPbrDlsgPP
X-Google-Smtp-Source: AGHT+IFdBuErmaLQh8qzDSGRNJz+uya9Gtzcme2EUce3xUtYu2KkkyU4wRqy+MrU90COYD0GwDZXzw==
X-Received: by 2002:a17:907:86a9:b0:aa6:c266:97cc with SMTP id a640c23a62f3a-ab2ab70b006mr2675266466b.23.1737025091425;
        Thu, 16 Jan 2025 02:58:11 -0800 (PST)
Message-ID: <ad8a8314-5cd0-4792-93ec-a530396ba3af@citrix.com>
Date: Thu, 16 Jan 2025 10:58:10 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] Design docs: Fix some typos in the design docs
To: Bernhard Kaindl <bernhard.kaindl@cloud.com>,
 xen-devel@lists.xenproject.org
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Stefano Stabellini <sstabellini@kernel.org>
References: <692dabc63953fb0d33536f87e4c5c147ba6ce11c.1736948633.git.bernhard.kaindl@cloud.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <692dabc63953fb0d33536f87e4c5c147ba6ce11c.1736948633.git.bernhard.kaindl@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15/01/2025 1:44 pm, Bernhard Kaindl wrote:
> diff --git a/docs/designs/argo.pandoc b/docs/designs/argo.pandoc
> index e18aacea7c..cd854d2a7a 100644
> --- a/docs/designs/argo.pandoc
> +++ b/docs/designs/argo.pandoc
> @@ -127,7 +127,7 @@ by the domain.
>  
>  ## Hierarchical Locking Model and Protocol
>  
> -The locking discipline within the Argo code is heirarchical and utilizes
> +The locking discipline within the Argo code is hierarchical and utilizes
>  reader/writer locks to enable increased concurrency when operations do not
>  conflict. None of the Argo locks are reentrant.
>  

In addition, focusses -> focuses needed in another hunk here.

> diff --git a/docs/designs/nested-svm-cpu-features.md b/docs/designs/nested-svm-cpu-features.md
> index 837a96df05..c855748141 100644
> --- a/docs/designs/nested-svm-cpu-features.md
> +++ b/docs/designs/nested-svm-cpu-features.md
> @@ -89,7 +89,7 @@ leaf 8000000A:edx
>   - 5 `VmcbClean`: VMCB Clean Bits: Not required by L0, provide to L1
>  
>    This is a pure optimization, both on the side of the L0 and L1.  The
> -  implementaiton for L1 is entirely Xen-side, so can be provided even
> +  implementation for L1 is entirely Xen-side, so can be provided even
>    on hardware that doesn't provide it.  And it's purely an
>    optimization, so could be "implemented" by ignoring the bits
>    entirely.

Also reson -> reason in another hunk here.


> diff --git a/docs/designs/qemu-deprivilege.md b/docs/designs/qemu-deprivilege.md
> index f12b1a3ae3..603491f24d 100644
> --- a/docs/designs/qemu-deprivilege.md
> +++ b/docs/designs/qemu-deprivilege.md
> @@ -251,7 +251,7 @@ executing QEMU.  (But this would then require other changes to create
>  the QMP socket, VNC socket, and so on).
>  
>  It should be noted that `-sandbox` is implemented as a blacklist, not
> -a whitelist; that is, it disables known-unsed functionality which may
> +a whitelist; that is, it disables known-unused functionality which may
>  be harmful, rather than disabling all functionality except that known
>  to be safe and needed.  This is unfortunately necessary since qemu
>  doesn't know what system calls libraries might end up making.  (See

Also assymetry -> asymmetry and constrants -> constraints.

I've folded these in.

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>


From xen-devel-bounces@lists.xenproject.org Thu Jan 16 11:15:34 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 11:15:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873507.1284478 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYNqR-00065L-83; Thu, 16 Jan 2025 11:15:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873507.1284478; Thu, 16 Jan 2025 11:15:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYNqR-00065E-5P; Thu, 16 Jan 2025 11:15:27 +0000
Received: by outflank-mailman (input) for mailman id 873507;
 Thu, 16 Jan 2025 11:15:26 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=EPy+=UI=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tYNqQ-000658-CB
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 11:15:26 +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 2df7c12e-d3fb-11ef-99a4-01e77a169b0f;
 Thu, 16 Jan 2025 12:15:23 +0100 (CET)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-aa67ac42819so124299066b.0
 for <xen-devel@lists.xenproject.org>; Thu, 16 Jan 2025 03:15:24 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c964dc9dsm905289366b.178.2025.01.16.03.15.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 16 Jan 2025 03:15:23 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2df7c12e-d3fb-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737026124; x=1737630924; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=EIJCpZvmy9qhj+WPYC6fYDDcHO0Q7EQf/pdc0RFqvAc=;
        b=d2cY2cpe+HqjqnLEWztNJoC5b3muowxloYE+efWLWny4T4Gscj+vcC51IZoth5uJi/
         KT7qfM7lkYjKNoQGkPpQzzdkV4BhP7pBT3IRuFra4PX5yO/0cDv2lU1fBqBUu9tiAKel
         TN5A8I2/RiB0x5Gjl3a+nD38Hj0y1durIuIS4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737026124; x=1737630924;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=EIJCpZvmy9qhj+WPYC6fYDDcHO0Q7EQf/pdc0RFqvAc=;
        b=mKu0441zDsvZT1ecm/YPIAOJ7qFNuR7SQ33wlIrb1mR9pY6aSMuEvR6Yoc6H/0ux6p
         DF467F3qCp/jH8k/I2gv8kV7c5tyZ2ZfxcDZzsW0I2RA8WJESjG8OwxCC7HWeO2XvCJ/
         Ccz+JYxfBUFGL2PIBMEZ6bFwgRCvODXUqIMh5RntnK5Tap1x/B0mxXKlF04xquHjfpS6
         c3gQIYR87FCSnIXs43i/lzUW+hv4V3Y4J35Qu1JpXZFMkIdYMxts597IvGepbl+wu1qT
         j/BYSd9erZNRqv8pnWDtcDzlb/UHyPcb0cFbVS2nrmDmEy7qwI3Hm/Lfz7m+ZA5hnlK0
         OG7g==
X-Forwarded-Encrypted: i=1; AJvYcCU3WOE7ac77wAHxKko+MeKhtlhskjN5ILvY2Qk32NCw8wxyPKCQes8CUhADyh92/hG7io6k/9MqgaA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwHIOFK0AnEWwpsbHJWqD6XLOe40AEnGDAwzW4OTynRggfJZK36
	dxlmOKI400keqaM7U6KSzUxeSaaDTCAW87cx5aY8/N7S3J4MObtWVJWNC1B4dSw=
X-Gm-Gg: ASbGncvtmD9GNtL7U5mlqX3ZnK8rk+9xCwnzbR787CDaYhwHd6ZBel6D3twsn3KGWOi
	FWxJOThDNVkl6Rg745kZ9HPrPhdU/wfI0ZbQsW+3C+kqyLqWaIQX6btOjGEB74m3o0w4ziihDrq
	yU6J1OTYg9pFdxlxlLVgFz/hp88Hg9kYHgDJb6N8CvMJFAnehw7GppWYZIyjoFnS8uH6w2chemP
	VdMH64GsgPuB4NMQq1TxJZKBqbt+c5dgFdI6XTHcVl+YmviRCCSdsZ2+c4ePxm+ggRPQQYtiYwS
	HXJqhgx/dp37NPGwGktj
X-Google-Smtp-Source: AGHT+IHt0viWcS5QE8Ze3REHOvKTPimZtNsvbQZecxxqzgZDCNvsih5u+OhVEAjcCXU18JRXhZEPaw==
X-Received: by 2002:a17:907:1c2a:b0:ab3:3eea:1ccc with SMTP id a640c23a62f3a-ab33eea225cmr959005666b.27.1737026123658;
        Thu, 16 Jan 2025 03:15:23 -0800 (PST)
Message-ID: <d389734e-216f-4c03-9932-b30a8b536183@citrix.com>
Date: Thu, 16 Jan 2025 11:15:22 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] docs/misc: Fix a few typos
To: Bernhard Kaindl <bernhard.kaindl@cloud.com>,
 xen-devel@lists.xenproject.org
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Ross Lagerwall <ross.lagerwall@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>
References: <5ab7cdad0c275dc2de900568ae3105be60f32db5.1736953714.git.bernhard.kaindl@cloud.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <5ab7cdad0c275dc2de900568ae3105be60f32db5.1736953714.git.bernhard.kaindl@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 15/01/2025 3:09 pm, Bernhard Kaindl wrote:
> While skimming through the misc docs, I spotted a few typos.
>
> Signed-off-by: Bernhard Kaindl <bernhard.kaindl@cloud.com>
> ---
>  docs/misc/livepatch.pandoc            |  8 ++++----

specifc -> specific
perfomed -> performed
randezvous -> rendezvous
seperate -> separate (multiple)
hypevisor -> hypervisor (multiple)
indepedently -> independently
containst -> contains
stricts -> strict
accomodate -> accommodate

Also, something a bit more complicated, "quiescing zone" -> "quiescent
zone".  ("quiesced zone" would also do, but quiescent if the proper term.)

>  docs/misc/netif-staging-grants.pandoc | 10 +++++-----

hackaton -> hackathon
emcompasses -> encompasses
accomodates -> accommodates
underying -> underlying
successfull -> successful

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Jan 16 11:29:40 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 11:29:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873516.1284488 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYO47-0008FY-Ce; Thu, 16 Jan 2025 11:29:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873516.1284488; Thu, 16 Jan 2025 11:29:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYO47-0008FR-A4; Thu, 16 Jan 2025 11:29:35 +0000
Received: by outflank-mailman (input) for mailman id 873516;
 Thu, 16 Jan 2025 11:29: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
 <SRS0=dy9H=UI=epam.com=Sergiy_Kibrik@srs-se1.protection.inumbo.net>)
 id 1tYO46-0008FL-9j
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 11:29:34 +0000
Received: from EUR05-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur05on20625.outbound.protection.outlook.com
 [2a01:111:f403:2613::625])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 282029ff-d3fd-11ef-a0e2-8be0dac302b0;
 Thu, 16 Jan 2025 12:29:33 +0100 (CET)
Received: from AS8PR03MB9192.eurprd03.prod.outlook.com (2603:10a6:20b:5c0::11)
 by AM9PR03MB7541.eurprd03.prod.outlook.com (2603:10a6:20b:410::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8356.13; Thu, 16 Jan
 2025 11:29:30 +0000
Received: from AS8PR03MB9192.eurprd03.prod.outlook.com
 ([fe80::baa9:29b3:908:ed7d]) by AS8PR03MB9192.eurprd03.prod.outlook.com
 ([fe80::baa9:29b3:908:ed7d%4]) with mapi id 15.20.8356.010; Thu, 16 Jan 2025
 11:29:30 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 282029ff-d3fd-11ef-a0e2-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=UcqdOgJ7kZ1glDYlQcohnnwArXlIDygMWwXA5415niZx7gM/CE80cK1h2eabMgibGZOOxt2LQvGlIsc6Jl7rsrEIDJmIl3j2HGT+G/FjYy+ZdhSwcQ47gpDau1JOuJf/MOEbROE+jHGz8QfVgxwPYQPIaXPcYOXb0L2AhZEq8gv+S+Gui7kKwXDvgzw0HhOmpnO6gD0hqR8OMI7QHH/77aS44+UKIO03URdd6GIEGxwEASC/1Qhtz7tCm/Ijbe2CBjDlnVItoicbm91eWdMpu8B5jqzrbw4IZ00c1sdV6oildmprg58guFmWU0HSzQ9PhuxdwV60QwbqYN3BqGy2Cg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=SzJcRdDFcNa/JHdo6ET0bo0EE20NiRzFULe0NfJ3fVU=;
 b=xlVvv/euiOMS7BFI0OBtnEb91sSd1UXmdkUzuh+KFH/tExkwSrQBpMGBFptBHhkpkA5CJloR1m5/ibeg63Bgiyq1111pU5BWkE9dxDcwPoAvqCIQjzIw13U5Vho18tJFYjFIOAgP2zQwzpG4WaLt4Gg+5YYu58lZ6ut1RdDC+c8Pj1QidkV2FE1RPV+LWs3MgUNC3Anp/GLwMSX39mfxGLUzJPBFTonUR5kTj8LVAkBQyLa1M7AkwPB2E1rONyei4BJIu49V4VhndKF33h2gBmUR743PsfQWS4m80pcNsBBMB9oL9+y4cgFigH5N/0yd8CrijQtqUCdk56eWbv96wQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=SzJcRdDFcNa/JHdo6ET0bo0EE20NiRzFULe0NfJ3fVU=;
 b=p+uynT1tMmwdRwqCXxbfdayIzz6sjkFrU32ixyms4j5GDcjrzCrYTEAz8pnb+/zMVsSHqkGnRtIsskbpSlcUMg0hNqVjnOloKwhpI7gYs6jmv1q7dArjbGvj4PJsJfbOVK3ucpiIEQY4XsNGsc7WNV3Wq7R8n0gmm15jcOtV82cHvw4XkZefBD3r/xNub/InUoaljkx46kwVx8QcvpcjciFZrNg5iAWjoyVSC7yzxL9lQcgeXdBgPyqoNw/t0I30mjBwm0rm3GgW3dU+J5c4pvnFMwzhTjwZQSP96nTRYKtiwsuaWiufiNr4xMYOdhnNvPdCuApUZXf0ZKVaV8QfRw==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
Message-ID: <f475354d-5df6-41a5-9928-519eaf4eb7b3@epam.com>
Date: Thu, 16 Jan 2025 13:29:27 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v1] xen: mem_access: conditionally compile vm_event.c
 & monitor.c
To: Jan Beulich <jbeulich@suse.com>, Tamas K Lengyel <tamas@tklengyel.com>
Cc: Stefano Stabellini <stefano.stabellini@amd.com>,
 Julien Grall <julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Alexandru Isaila <aisaila@bitdefender.com>,
 Petre Pircalabu <ppircalabu@bitdefender.com>, xen-devel@lists.xenproject.org
References: <20241230063051.3332332-1-Sergiy_Kibrik@epam.com>
 <c8684340-33f9-41d3-94e4-77ee3bc18306@suse.com>
 <CABfawhk4pzA9bSMzJDX7ZwaYC50dfn_ntCnk=bePmiKCpDnN3w@mail.gmail.com>
 <8fc662a1-4c74-4f97-a116-3bc5a0b71cf1@suse.com>
 <CABfawhkyg+TVB-uc04OefDhOXEfeQyQypW6gL4qsYO3ZrDxYfQ@mail.gmail.com>
 <a0c50fb6-516a-4e0e-8c3b-49c4dbc7b863@suse.com>
Content-Language: en-US
From: Sergiy Kibrik <sergiy_kibrik@epam.com>
In-Reply-To: <a0c50fb6-516a-4e0e-8c3b-49c4dbc7b863@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P123CA0134.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:193::13) To AS8PR03MB9192.eurprd03.prod.outlook.com
 (2603:10a6:20b:5c0::11)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS8PR03MB9192:EE_|AM9PR03MB7541:EE_
X-MS-Office365-Filtering-Correlation-Id: 9fb02eae-c624-4291-60a4-08dd36210b16
X-LD-Processed: b41b72d0-4e9f-4c26-8a69-f949f367c91d,ExtAddr
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|366016|1800799024|376014|7416014|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?c2wwWUtCSlFzNFdEbWtEQmI2UVpBc0lDci9MaWlEWW12Ym5QMHM0TnNUdE9E?=
 =?utf-8?B?OFkvUG1iZ2lIdW84emlXR2dTaUhUdkQxTGFsR2JWeFdHbE5jNUk1RXZPTXYz?=
 =?utf-8?B?WW1JUmthQ3ptNVdPeVpTTnlwTkJ1N0VOYkNZQVBCNkJKNTJOQWNtMTVpS3FD?=
 =?utf-8?B?QmpRbEI2N2ZsWnpzTmxGbWU1R1BIdXQzYStoMmc4Q25jUkdSYzlLWXlLZmVB?=
 =?utf-8?B?VEtxZ0RHVFo3UVRKRVhQNFdyT1VjN1d5alZRck1OdFU2T1lWZSsyOWxET3Jr?=
 =?utf-8?B?dkNrczB3TlFqRHlDdGh2aUlCZHE3VCtXOFlUa3ZtYW5ucytFNENqWW1wdG1B?=
 =?utf-8?B?NENHbVgwbWVsWFJKa3Z1VGhUa3NqeVBGMFhlMzhKY0pkQWlLRlNURVZqN0VR?=
 =?utf-8?B?dUlZUmljU0U2L1ZucnZRUjN2NGZpV2RvVHpRMXA3MzlVTWFNcDAyQXhoMXh0?=
 =?utf-8?B?NTFTSERPTTJRa1dBZmRDUVlNajAzS2FrZXBhTjRZamVoUkE0TVNOVWFzUVBp?=
 =?utf-8?B?OWxqK0xXZFBzVzdIMTVJN1N3Zml0KzFuck9xTy9OSktSNmFDL1FFRklHUXln?=
 =?utf-8?B?dHJBZ29mYmQ3U2JUUi9Ocm5heFRYcHo0YXA1RG9Ud243WThMRms4Q3Y2Ty85?=
 =?utf-8?B?dWI5VW50R1pkdjNHWGNmOExGK2hZdFl4cmRKZG44UG5uZzFuNTZrTGFVRVcw?=
 =?utf-8?B?UkpReWEzbVUwdUFBM2NjMjAxQm16QnZNMU1RVEwzWFBBMThTZ04zakxUMlFX?=
 =?utf-8?B?QjNhaVVrQ09lSEw4Kzczcm8zT281aWpFcGxpWHNTYUFmc2xGTTNML0tHRUVD?=
 =?utf-8?B?M0R4YWJ1bTJtdmY3d2tYaUtHcUdSa3pJTDlVU0FoaWRWTFNGSVEveUFCSkQ0?=
 =?utf-8?B?dzJlM0dPNTJwWldjSnZqZkJVRUwrWHA3bG9ud0cwUlhUWFBlZGwwWTQzbktE?=
 =?utf-8?B?ckN3c0djQUFmcXlMcWlVS2RQdGllSERjSGhSQXlpTExUS3N3L3hhWTB4ZGRq?=
 =?utf-8?B?RzVQejN4UE1EZzYzTk1kZkkxdlNtZXNERlRYT0dhWVRpTSs3a0Q0MkNpdnBE?=
 =?utf-8?B?QjZiZGpIZU90MG1Nb25od1VuNUFIcjRRNEhqeFFVSC9UbGxmUElMTVFXVzVV?=
 =?utf-8?B?b29sczVwdmxOa2lFUDh2blUwWjlZTDJMWERoRTV1b1JxQ1lFNjNHMWRYcFcz?=
 =?utf-8?B?YU9yNytnSFp2VU9OOGU3aFQ4dTU3cURSbUwvbkJ1bk5yUUY2TUtCU2FucCtJ?=
 =?utf-8?B?c1JWMXBMK2VTbW4yVitXWWI5UjlzTHgzbFVRMHBxTnBZM0oyc2xKN0Fyd1lF?=
 =?utf-8?B?V3NWdWJDYTVKTXlpZkw0ZDNwTWJSNFRQaVBFTzU2VkJ0SGtLUHMxUDFnUVNL?=
 =?utf-8?B?TXJGSXdLMU9HakdsSFdvUk15cE9TbThzVjRyTVV5VkF0Mm94Q0kxZkxNaU9W?=
 =?utf-8?B?UmVLRmYvVHYyQ0VtWUtsY1BocXlIUEIydmVPeExzUmJHODJkUmlZQ1VNd3VV?=
 =?utf-8?B?RGFFeC9aN0VyQ21wMy94anVYaW1EQkx2ZjMyOHJ3NHpzNVAyYVdRWitXZ2dB?=
 =?utf-8?B?UHdxMkdXSXlTSzAyYTIwaU5QaG1sQk11MHJlYWpuV3ZaNENVMHhsN0RrN2da?=
 =?utf-8?B?eVc0ZFZLNXp1YkhXM1BOdFdOM2M4cTRnd1VndUdEMmhVVkp1NjVRMUplZlcy?=
 =?utf-8?B?eThWRWdWdnZkek9EQlhIUm5vend0VUwzRGtLTzN5VzFvOW1RM0tma3Q1KzBq?=
 =?utf-8?B?VEp6QlR4STk5SDFidkpzb0xOVVhzc0NaRDlRZHdxYW9WODhvcmZiVkNQdXlF?=
 =?utf-8?B?T3RmVU5QSGFGVjd4L3NtTS96c25qNzF5a0xvaVpHQTA0eU0rdFZqb29Ub2Mr?=
 =?utf-8?Q?eFEViyINQq/nm?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9192.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(7416014)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?am52NE5TdjhkTEZJZ1VvL3F0UDZ3Rk14dWdKdklBcVpmcVVCNEpOcWJ4SUlJ?=
 =?utf-8?B?NFY2QkhzTlU3Nk0vYVRuQjkvd05CNTVEY3JuMFVpWCtJOGQwdTNRZEZOdnhk?=
 =?utf-8?B?UzhNRkczQmsvWjA0bGVyZ3VJU1dqZ3hjQzlkZDUvSkdUWVcrcUQwWFZHWVZE?=
 =?utf-8?B?Ynd4VFdzZWtvSzJ1U1N3TmZlMXRvLzEvMk9HWml6TWkwcHZDUXlPamhHZFFm?=
 =?utf-8?B?YzRpTlpXUEx6di9VWVZXZHZHcHdobWNzUVgzbG5nYVNwSVJyVmxmN0dTTGRI?=
 =?utf-8?B?c0VINFJJeHFOL3ZYeis3aVVRWTk3dWxYcHVRNHptVDY3ZkliRnNwUnlWdlBL?=
 =?utf-8?B?RUpJRjNKY21DcGhpa255dm40aTdIQjhsdHFmdXhtYlB3TFV5UDEwYm5tRnZh?=
 =?utf-8?B?S2wrMks2T3hxNkRseGFiYWdtNzBxWHJKNHFmVzBMcXlEbjJhWHhtWllhWm5Q?=
 =?utf-8?B?L0psNUZ3TUxydGd5dmJUUUZMVEgrd0cyOEZWT3FDOTdXeDFSTFlwL2dMampr?=
 =?utf-8?B?c2lQQmhLaERPSjFhaTQwZGJLYVJoV1pHV0lBNmduQ09OU1U3S1N0YlNKbmRi?=
 =?utf-8?B?T0tid3NHM3k0WkpTRUdoQTNwUEROWkxFRkYyODd2RHVLU1BYRDQ2ei9nRjdS?=
 =?utf-8?B?bHVRUW9aQUJEMFZSUURxVVBHaHIrY1Z3WXo2VHRSNmVvZGFHK3FNZ1R5S0wr?=
 =?utf-8?B?V1ZZTWdBSE1ZQmMvU2IvS1M3Q2poZWgrRlhqS2hYZm84YzZOVnc5d0FEMUdk?=
 =?utf-8?B?dXR3VkVjd2JYcXlnZEdBUys3VWE4bUJkR0ViQU14UkdCYnk4ckZ6aFFIalAx?=
 =?utf-8?B?VkRYV2I5aTUzM3pBOHp0QlVrYWJXVWJnSm5UU2RFUFZWMlVURnRNdXQ0eXNs?=
 =?utf-8?B?dmNwUWZOQ0dXdmY2T1BxSXJ6NkV2bGZHVENCWVJTWlFldWRaeTUrOFA3dmV5?=
 =?utf-8?B?SVdsSEpwOTMyaVVucXdXQ0lXMTBCWHZqNldCSUFCUVJxRmhHWnd6QS9UYVNP?=
 =?utf-8?B?SmJHMWRWa1NwZ3JzeDBpenJxTzZ0UW9QV2ZEY3QraUNkWng3Qjl6WWF5L0d5?=
 =?utf-8?B?N29EUlhhZHJCMGMza0xxYU8wTXVaNk0wcS8rWWE0OXhVMHY5UzdFclNRNnUw?=
 =?utf-8?B?bDl3MmN5Y2JMWDBHTkJaS1BnWC9BQXdWWWh2cTFaNWJ1VFhYWXN6VjY3clZY?=
 =?utf-8?B?eGFscG1DUWpjUktwT2VDQmNWZGZ5WmpRNFVNMDRrOUhpWDhoM0JXSGpEdFdk?=
 =?utf-8?B?N3lDYXJZNDFmNVd2bXhpUzVEcElEMkxUNWdiWFNhdXAzcjVVT0RWZktxTWs5?=
 =?utf-8?B?T3BGNFE4YmROTFZtUWZDbzNFSGlZWXBxNlRvQ202b3FrdStXSkFSdkc4R2Yy?=
 =?utf-8?B?Tlc2OVRTOHB3NmF2MmdYQ0F6WjFxajV0VUJXcWE5bFphVmtqdFM1NnBJMU85?=
 =?utf-8?B?SzlIakRRUUpSbldoQTN0elFqNS9adWl4eXdhSnRGMWJjbVo1SXVzdVk4Qzhy?=
 =?utf-8?B?UGM5MFMzb29PbVl2OWdnQTM2cUtXTWNiWlp4UjRFakE5NDIvaHcvd1VIM0No?=
 =?utf-8?B?Z3lpK0FFZDJHRjJlU3crZHhOdXJDNTEzMDJybEZtbWNuMEpOUnQ1enVQenlH?=
 =?utf-8?B?Y0xCRVhkY1orQm1JYzFNd05xNzZJZEIvR0QwVVNNUXRVY1RGN3N6YVZRdk43?=
 =?utf-8?B?VE1DUmxvaDB4QklNUFNZZmZWMmExTUI3MzVpTkwyVlRNQVhDM3p6WTNua1dP?=
 =?utf-8?B?MVh4dXFab1N3NnVuN2xZYmZVR3FKNS80ZDRCN1FGYVNZVkJFcjRNaDBENDFs?=
 =?utf-8?B?MXMxbGQxTElZUDR5VUY1eTZXb0hmMlJ2bzQ1MGtzVTFTWXMwZjFIMUIvSjM3?=
 =?utf-8?B?eHhoM2RGaTF3NEcwOUpidFdGOFQ1TjQ2Z0hXd3hEMXZmckRvYy9PdzYxMkhF?=
 =?utf-8?B?ZGdHdGlId25PSi84UGVhZTdCS2Y0VkZIZjJhdjR1bllMeHB6MXo2Q2dqM0NU?=
 =?utf-8?B?UklZZlUyU1g3RVM2M3ovWlhEL0ozWThCNW9Kd1k0SzRxRDBWT0krcWRsMnBU?=
 =?utf-8?B?ejRwZHFzNFQyTkF5bnlSL01iRS80bjlReVBqdUR1QXhOTU5rNWRaMGZUc1Jv?=
 =?utf-8?Q?CD1PJ8r3sWKvJLtU3rZLnKEBH?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9fb02eae-c624-4291-60a4-08dd36210b16
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9192.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jan 2025 11:29:30.5465
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 0fQhqcn1vMe4DebINJW0GKm5wMnYnSX0PRU9RIuGrm+J1lFZvE2jEqlWqcRn2gBeiiKjsDpvWG2eS6idV5yLgA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR03MB7541

07.01.25 10:46, Jan Beulich:
> On 06.01.2025 19:09, Tamas K Lengyel wrote:
>> On Mon, Jan 6, 2025 at 10:10 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>
>>> On 06.01.2025 15:05, Tamas K Lengyel wrote:
>>>> On Mon, Jan 6, 2025 at 5:16 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>
>>>>> On 30.12.2024 07:30, Sergiy Kibrik wrote:
>>>>>> From: Stefano Stabellini <stefano.stabellini@amd.com>
>>>>>>
>>>>>> Extend coverage of CONFIG_MEM_ACCESS option and make the build of VM events
>>>>>> and monitoring support optional.
>>>>>
>>>>> Yet doesn't this end up in things becoming misleading? Don't we rather need a
>>>>> 2nd Kconfig option, with a dependency between the two? Or alternatively a
>>>>> rename of the existing option (to describe the higher-level feature rather
>>>>> than the lower level one)? Tamas, I'm particularly interested in knowing your
>>>>> view here as well.
>>>>
>>>> Thanks Jan, I was thinking the same thing. The dependency of these
>>>> subsystems is mem_access -> monitor -> vm_event. If the goal here is
>>>> to disable all three levels the ideal way would be to have separate
>>>> kconfig options for each level. It may be a bit too fine-grained
>>>> though on ARM since there are only two types of events for monitor
>>>> (SMC & mem_access) and only the monitor uses the vm_event channel (no
>>>> mem-sharing/paging on ARM). So if doing separate kconfig for each
>>>> individual feature is an overkill I would suggest using
>>>> CONFIG_VM_EVENT that disables all three levels, including both
>>>> mem_access & smc monitor hooks.
>>>
>>> Except that "disables all three levels" doesn't work, unless the other
>>> option(s) are promptless (and selected). I'd have expected VM_EVENT to
>>> maybe have a "depends on MEM_ACCESS", whereas a "select MEM_ACCESS"
>>> wouldn't make much sense as long as MEM_ACCESS can be enabled
>>> individually (with it being unclear to me whether such a configuration
>>> is actually useful in any way).
>>
>> Not sure I follow. None of these systems make sense to enable
>> individually. Without vm_event monitor/mem_access are useless, that's
>> why I would pick CONFIG_VM_EVENT as the option on ARM to disable all
>> three levels if we don't want to start splitting it into multiple
>> kconfig options (which I think may be an overkill here).
> 
> Oh, okay, you suggest to replace MEM_ACCESS by VM_EVENT at the Kconfig
> level. That would be fine with me, so long as it's also appropriate on
> (in particular) x86. Then, if there was ever a 2nd use of mem-access,
> MEM_ACCESS could be re-introduced as a standalone option.
> 

Thanks Jan,
would it be ok to replace MEM_ACCESS with VM_EVENT everywhere at once, 
including in defconfigs and automation script etc? Or such changes would 
better be done gradually, starting with changing Kconfig only?

   -Sergiy


From xen-devel-bounces@lists.xenproject.org Thu Jan 16 12:17:08 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 12:17:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873544.1284546 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYOnv-00088l-Ae; Thu, 16 Jan 2025 12:16:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873544.1284546; Thu, 16 Jan 2025 12:16:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYOnv-00088e-88; Thu, 16 Jan 2025 12:16:55 +0000
Received: by outflank-mailman (input) for mailman id 873544;
 Thu, 16 Jan 2025 12:16:54 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=PV9y=UI=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tYOnu-00088Y-F5
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 12:16:54 +0000
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [2a00:1450:4864:20::534])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c53e6a7f-d403-11ef-a0e2-8be0dac302b0;
 Thu, 16 Jan 2025 13:16:53 +0100 (CET)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-5d647d5df90so1510395a12.2
 for <xen-devel@lists.xenproject.org>; Thu, 16 Jan 2025 04:16:53 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d9903c4400sm8902334a12.52.2025.01.16.04.16.51
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 16 Jan 2025 04:16:52 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c53e6a7f-d403-11ef-a0e2-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737029813; x=1737634613; 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=T/BI101gbrfPK7SSENpL2wtYlQSOkQlwIA5fX8OmXxQ=;
        b=wDhn7iNj9TmLsJJgSlBRW0FwpNf7Re5cRdF5qPBZeeXo/0UPxfwdNTJZOkdrEnrU25
         arv6XJFmrw3gIrZugrS9DTLIIBGam64u434al5MBK/EKTn97VFb96fRBD3UhSKuC7M2s
         UEM/uVGZXvJxQtantgpy+URbd8LbjKlYr7O7E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737029813; x=1737634613;
        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=T/BI101gbrfPK7SSENpL2wtYlQSOkQlwIA5fX8OmXxQ=;
        b=TSrMeTE5/4YIAYFl8FbWUML1pOsp9Nla0nv+LlF+gPUH8lnKGGV4WlRtkOSR6oFw0z
         hlc3+/6dgBbPz9ZM9JqFO+JQH1yhF1zm877QHewXN0kQeoAWwZsLahmgPv3eOZyrZsom
         SS96dyWCtoGCtK2coWstMrZ3DYGb4ZJCca8QDovTLuNYAtwFwdCS98+3k5xNVkAzvZd/
         ijdftDdbCLEpoKmdwL7bFZ6T89AxGzVu7ISSPj+pZYltlzVWpesn100lWVFy0lzldOuR
         qERsan7cIjbZXCShLFajFMuZrPU3HGds2k3PanfxxJgLRlJrncjci0R1olGZ+B8EVbKU
         e8mQ==
X-Gm-Message-State: AOJu0YxxkfVnqWi9Mm5aJCtCuPA0hmLvwu3TbipZwoqYe2WVtl8f7aWM
	JDoihu47S4FxPZZc9qAuaePUTnRBqX1VdFFF78HpGr8trUz95R+nIbW5RLLp4Hs=
X-Gm-Gg: ASbGnctbXmVEVtajUHuLZwFLszrFTGO8hoc770f17MW2PGvMkw8okOpfW1yeOEyUvtK
	gACEYTJpoG4GSL8BeXaj57Msyovp6ypeckkQPqLJP7ddHCl45BiCcPBIxuoYsH6onvCbBcvfUuE
	h7ooTPJ8ei2+GRPw9uDS9XTJPXaILw77M4y9UH3vz/DCoj647wzhMOPYrwIPT5atAJVILAqe9AZ
	G67mjd7YOvUfd3I/UzWlIorvxj5w6lRjqh7EC2JkqL1oRC2N1tMFsdwkhG+Pg==
X-Google-Smtp-Source: AGHT+IFL0GaKKHxRxrdUgIxwH8vyf1S4XiqYRYea6WhvEdHeExIdgq0YTjX9+F6/t2LlJ7ujQs0PgQ==
X-Received: by 2002:a05:6402:5296:b0:5d1:3da:e6c with SMTP id 4fb4d7f45d1cf-5d972e06b06mr31712709a12.10.1737029812603;
        Thu, 16 Jan 2025 04:16:52 -0800 (PST)
Date: Thu, 16 Jan 2025 13:16:51 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: xen-devel@lists.xenproject.org,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH for-4.20 2/2] automation/cirrus-ci: introduce FreeBSD
 randconfig builds
Message-ID: <Z4j4s-1iK2CH4ssK@macbook.local>
References: <20250116085852.78273-1-roger.pau@citrix.com>
 <20250116085852.78273-2-roger.pau@citrix.com>
 <7984d25d-66ac-4791-929b-a3ce037e960c@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <7984d25d-66ac-4791-929b-a3ce037e960c@citrix.com>

On Thu, Jan 16, 2025 at 09:46:33AM +0000, Andrew Cooper wrote:
> On 16/01/2025 8:58 am, Roger Pau Monne wrote:
> > Add a new randconfig job for each FreeBSD version.  This requires some
> > rework of the template so common parts can be shared between the full and
> > the randconfig builds.  Such randconfig builds are relevant because FreeBSD
> > is the only tested system that has a full non-GNU toolchain.
> >
> > While there remove the stale `python` package install in the full build
> > case: this is no longer needed if `python311` is also specified.
> >
> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> > ---
> >  .cirrus.yml | 64 +++++++++++++++++++++++++++++++++++++++++------------
> >  1 file changed, 50 insertions(+), 14 deletions(-)
> >
> > diff --git a/.cirrus.yml b/.cirrus.yml
> > index ee80152890f2..f3ea29102cbf 100644
> > --- a/.cirrus.yml
> > +++ b/.cirrus.yml
> > @@ -1,11 +1,24 @@
> >  # https://cirrus-ci.org/guide/tips-and-tricks/#sharing-configuration-between-tasks
> > -freebsd_template: &FREEBSD_TEMPLATE
> > +freebsd_13: &FREEBSD_13
> > +  freebsd_instance:
> > +    image_family: freebsd-13-4
> > +freebsd_14: &FREEBSD_14
> > +  freebsd_instance:
> > +    image_family: freebsd-14-2
> > +freebsd_15: &FREEBSD_15
> > +  freebsd_instance:
> > +    image_family: freebsd-15-0-snap
> > +
> > +freebsd_template: &FREEBSD_ENV
> >    environment:
> >      APPEND_LIB: /usr/local/lib
> >      APPEND_INCLUDES: /usr/local/include
> >  
> > +freebsd_full_build_template: &FREEBSD_FULL_BUILD_TEMPLATE
> > +  << : *FREEBSD_ENV
> > +
> >    install_script: pkg install -y seabios gmake ninja bash
> > -                                 pkgconf python bison perl5
> > +                                 pkgconf bison perl5
> >                                   yajl lzo2 pixman argp-standalone
> >                                   libxml2 glib git python311
> >  
> > @@ -15,20 +28,43 @@ freebsd_template: &FREEBSD_TEMPLATE
> >      - ./configure --with-system-seabios=/usr/local/share/seabios/bios.bin
> >      - gmake -j`sysctl -n hw.ncpu` clang=y
> >  
> > +freebsd_randconfig_template: &FREEBSD_RANDCONFIG_TEMPLATE
> > +  << : *FREEBSD_ENV
> > +
> > +  install_script: pkg install -y gmake python bison
> 
> It's odd having python311 for the full build but only python for the
> randconfig build.
> 
> IIRC, it's just for Qemu, so there is a split based on whether we build
> tools or not.

Right, this was added by you in order to fix the build with the new
QEMU:

1223375d8b7f CI: Fix builds following qemu-xen update

IIRC you said that on FreeBSD you used 3.11 because it already
includes the required packages (tomllib and ensurepip).

> What will happen when python becomes 3.12?  Does pkg have a way of
> asking "I want any python as long as it's 3.11 or later" ?

Hm, I don't really know.  Maybe we could use a regexp, but that seems
ugly.  Otherwise maybe some shell logic based on the output of `pkg
version`.  I've been told by pkg developers there's no way (yet) to do
such version matching.

One suggestion I've received is to use the python3 meta-package,
which will default to python 3.11 right now (and will keep moving
forward).

Would you be OK with that?

> Relatedly, how likely is python to transform into 3.12 in a bump to the
> minor FreeBSD versions?

It will transform as a result of the change in the ports tree, rather
than a FreeBSD version bump.  When that happens it will affect all
FreeBSD branches mostly equally (as it propagates to the binary package
repositories).

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jan 16 12:25:09 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 12:25:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873553.1284556 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYOvo-0001XH-3X; Thu, 16 Jan 2025 12:25:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873553.1284556; Thu, 16 Jan 2025 12:25:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYOvo-0001XA-0j; Thu, 16 Jan 2025 12:25:04 +0000
Received: by outflank-mailman (input) for mailman id 873553;
 Thu, 16 Jan 2025 12:25:02 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=vlR0=UI=fooishbar.org=daniel@srs-se1.protection.inumbo.net>)
 id 1tYOvm-0001X4-Hd
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 12:25:02 +0000
Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com
 [2607:f8b0:4864:20::f2d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e6f11f4a-d404-11ef-99a4-01e77a169b0f;
 Thu, 16 Jan 2025 13:24:59 +0100 (CET)
Received: by mail-qv1-xf2d.google.com with SMTP id
 6a1803df08f44-6d92e457230so8661046d6.1
 for <xen-devel@lists.xenproject.org>; Thu, 16 Jan 2025 04:24:59 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e6f11f4a-d404-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=fooishbar.org; s=google; t=1737030298; x=1737635098; 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=GBwF2KOXlFDp1MGeRltem3iAJtpX3AYE0x8w+f0gonM=;
        b=Lm18+Oz+7gIDPWShMHyk0mSFlH3i5ER81TApFrletR7iiJ4eBCx0FyNs7WU9XdNEIf
         9rwmxm6XVNMzF0R86Vn0VCGD5hFhobM2f5kcT1IquavC0DVbr3RPjynUufaxejLfAHEb
         Mhg5yQacVkmWmHLTG9dMaHuM+Y99z0jLSbXCtI6byDuztACDEolRdWGiOmeYqd1IETJG
         BfGG6TFBathCPKZAG+q25pZYQCnCezzduCvqcGZuqc//h0HktlHKiqOroPJ4J3S64ZNr
         EzR9+itpqrN1JSIdo6sJdQ6J37i76t5CDBvMYQOJJei6LVyKMHDqu5KhNmjzhUMPo0Gn
         dMSw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737030299; x=1737635099;
        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=GBwF2KOXlFDp1MGeRltem3iAJtpX3AYE0x8w+f0gonM=;
        b=v09sTuMkf1JeeomHctyHCy86LPfJYmuwH1hxjgoKmSrRFp3Yn9FxNK3LFxboYeOft8
         PoDhia146oaVUKBOGMTcoU3ylh0aQhHpMeAS+5nPhWMUW9JJhlcfIs1A39Vqmgcwc7cx
         5RHGp7kH4usMnYTp4vz8yhSC2OyAp/Ow+/am8EeTXgWQlUhXuiyra2MO0PYPfHvTqSiR
         Zl0Ljok4oNv97gA2oO4xEgmSSIN57ADeM0j+an1ua0ucXCrR9s9DmXTfQoRE4Eo2xy/A
         gX3GW0wsnUMVzuEVRPvYkGetNSfqDeTNkacMo45iDLOi0TOaGc2Z0T+Ruk0Bm5MRYUqj
         OenA==
X-Forwarded-Encrypted: i=1; AJvYcCXX1sOIxJ1GkBsfzLs7hF9N0eREgd5ZNxTFxPD4RbjQaLoZj25WVHaCA50U1SZGxXy3fUjN4gpqT0U=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzPF31jqOPBVLAWlgeE5RQVh5fXVzTAxmnt6jWc33W4LD52wdbL
	oeJrzYLWe9bVDjGqZ8YgqT370GZHO2XExKN6KRcs96VvvHrevlr4Bwf2BY9tFD50eQFwCfGdQhp
	whPYlL0zDm4j+Kz9Xb1XfFsU6uy4JxQVo0av0yQ==
X-Gm-Gg: ASbGncu5qG3HGIaZP0g3dlswybjKabDC6QKPs5FP7CPStj0o2+fKHqTqOVEl87zllBI
	B2/VwYq1AAIWh0seXpdZMZCil3UpyZJvLGIc=
X-Google-Smtp-Source: AGHT+IHYPoThOqCGG0mIrocl9o1givl0D/RoYwWOKY0kUiZ64KPF9cSvP+6N1Rd6ke2PYtdS9xOibflODkJbaGvT990=
X-Received: by 2002:a05:6214:528e:b0:6d9:3016:d0e7 with SMTP id
 6a1803df08f44-6df9b2b1a21mr442378366d6.29.1737030298608; Thu, 16 Jan 2025
 04:24:58 -0800 (PST)
MIME-Version: 1.0
References: <f3ba05c7-6e49-4641-a3f9-ba418ebdb7c3@ideasonboard.com>
 <c6735280-7c32-4319-8ca9-a7305d8117c3@suse.de> <d67adb03-5cd0-4ac9-af58-cf4446dacee3@ideasonboard.com>
 <0ea6be58-0e04-4172-87cd-064a3e4a43bc@suse.de> <f35cb350-6be9-48ca-ad7e-e9dd418281d5@ideasonboard.com>
 <4af0b6a7-c16a-4187-bbf5-365a9c86de21@suse.de> <e327ad84-b5c9-4480-b873-dc3aca605538@ideasonboard.com>
 <a2bbeb47-2569-4ee0-9265-92bab139bdc6@suse.de> <f3833771-fcd7-45dc-9019-1525fef34429@ideasonboard.com>
 <CAMuHMdXxYa+Na3XxpLTy=-eUL_zQ9kAiUKYu-E04u3KWApusSA@mail.gmail.com> <xz5ncq67bgmdase2jg3cfvyaxpiwhol2eqpfzow6dqpauvslo5@2w3rw27lhnxo>
In-Reply-To: <xz5ncq67bgmdase2jg3cfvyaxpiwhol2eqpfzow6dqpauvslo5@2w3rw27lhnxo>
From: Daniel Stone <daniel@fooishbar.org>
Date: Thu, 16 Jan 2025 12:24:47 +0000
X-Gm-Features: AbW1kvarRJv1VyJjUo1t8ScK0brJ2o4-Qq6ABYK10edUo6rgOW2PAccCb4uQWlM
Message-ID: <CAPj87rNS7quwfqDmxyrW8_vQ6tnrcfWUn=81aTduDXtmdVkkAg@mail.gmail.com>
Subject: Re: [PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with drm_mode_size_dumb()
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>, Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>, 
	Thomas Zimmermann <tzimmermann@suse.de>, maarten.lankhorst@linux.intel.com, mripard@kernel.org, 
	airlied@gmail.com, simona@ffwll.ch, dri-devel@lists.freedesktop.org, 
	linux-mediatek@lists.infradead.org, freedreno@lists.freedesktop.org, 
	linux-arm-msm@vger.kernel.org, imx@lists.linux.dev, 
	linux-samsung-soc@vger.kernel.org, nouveau@lists.freedesktop.org, 
	virtualization@lists.linux.dev, spice-devel@lists.freedesktop.org, 
	linux-renesas-soc@vger.kernel.org, linux-rockchip@lists.infradead.org, 
	linux-tegra@vger.kernel.org, intel-xe@lists.freedesktop.org, 
	xen-devel@lists.xenproject.org, 
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Andy Yan <andyshrk@163.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 16 Jan 2025 at 10:35, Dmitry Baryshkov
<dmitry.baryshkov@linaro.org> wrote:
> On Thu, Jan 16, 2025 at 11:17:50AM +0100, Geert Uytterhoeven wrote:
> > On Thu, Jan 16, 2025 at 11:03=E2=80=AFAM Tomi Valkeinen
> > <tomi.valkeinen@ideasonboard.com> wrote:
> > > On the platforms I have been using (omap, tidss, xilinx, rcar) the du=
mb
> > > buffers are the only buffers you can get from the DRM driver. The dum=
b
> > > buffers have been used to allocate linear and multiplanar YUV buffers
> > > for a very long time on those platforms.
> > >
> > > I tried to look around, but I did not find any mentions that CREATE_D=
UMB
> > > should only be used for RGB buffers. Is anyone outside the core
> > > developers even aware of it?
> > >
> > > If we don't use dumb buffers there, where do we get the buffers? Mayb=
e
> > > from a v4l2 device or from a gpu device, but often you don't have tho=
se.
> > > DMA_HEAP is there, of course.
> >
> > Why can't there be a variant that takes a proper fourcc format instead =
of
> > an imprecise bpp value?
>
> Backwards compatibility. We can add an IOCTL for YUV / etc. But
> userspace must be able to continue allocating YUV buffers through
> CREATE_DUMB.

Right. If allocating YUYV dumb buffers works on AM68 today, then we
need to keep that working. But it doesn't mean we should go out of our
way to make CREATE_DUMB work for every YUV format on every device.

Currently, drivers are free to implement their own ioctls for anything
specific they have. But like Laurent said, standardising on heaps and
how to communicate requirements to userspace wrt heap selection / size
/ alignment / etc is imo a better path forward for something generic.

Cheers,
Daniel


From xen-devel-bounces@lists.xenproject.org Thu Jan 16 13:07:38 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 13:07:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873567.1284566 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYPat-0007NG-6e; Thu, 16 Jan 2025 13:07:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873567.1284566; Thu, 16 Jan 2025 13:07:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYPat-0007N9-3m; Thu, 16 Jan 2025 13:07:31 +0000
Received: by outflank-mailman (input) for mailman id 873567;
 Thu, 16 Jan 2025 13:07:30 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=kd1b=UI=bounce.vates.tech=bounce-md_30504962.6789048d.v1-1127180d23774829bb59a9e75bd419e9@srs-se1.protection.inumbo.net>)
 id 1tYPas-0007N3-2B
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 13:07:30 +0000
Received: from mail187-43.suw11.mandrillapp.com
 (mail187-43.suw11.mandrillapp.com [198.2.187.43])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d4ca28c4-d40a-11ef-99a4-01e77a169b0f;
 Thu, 16 Jan 2025 14:07:26 +0100 (CET)
Received: from pmta09.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail187-43.suw11.mandrillapp.com (Mailchimp) with ESMTP id
 4YYjnn29D8zLfHXMv
 for <xen-devel@lists.xenproject.org>; Thu, 16 Jan 2025 13:07:25 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 1127180d23774829bb59a9e75bd419e9; Thu, 16 Jan 2025 13:07:25 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: d4ca28c4-d40a-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1737032845; x=1737302845;
	bh=U4zJKnHETDSGpbyfc8Xor+pecEkKp2yPxoCKuDdLEQM=;
	h=From:Subject:To:Cc:Message-Id:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=nq9cXfmjNlvnTPh/9FzYjVRRWg2dtzs2QMpVP06Wpl9yE+eUNxpRoYO/zFfzUPK8/
	 haUsrQ2yqwulqRYrP9OvAgTTGf8RGIl4IYCQfK+chmbbrHhvNWpWyqil1k3acme19U
	 fFQP3WOlqlpyjqxBlvZMTuAsAi+qES1N8B7ZmK2H2d1YnnScYuRmBfifLRdXBlAnRv
	 9AT7+liYcZ7IF+5kDd1m7bnTMX2NAei18huXSq7FPTkgFEqf7jU7dxFCTCzGs3gZAi
	 dKRi0M+V4pD0iw5YP5/weh7SW25rrIxvtE5hUqclgD38RHdnfGBqd3Wq8yolkCR6JV
	 cFbskirINImfg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1737032845; x=1737293345; i=anthony.perard@vates.tech;
	bh=U4zJKnHETDSGpbyfc8Xor+pecEkKp2yPxoCKuDdLEQM=;
	h=From:Subject:To:Cc:Message-Id:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=E/3uIscUUCy4Ot74CfomRs5xP9WEFCPuqVS0/M1W8ulFBqAnWscXaQ1pmjAvpXzyV
	 WGbMCUu4vgwjl8RkeQL8w6gOF97n7hPPDr/4qksQnq7Od1jvX53GGnN8uCPe0MS9zM
	 eXx+DVmzFT+GPF86BLAtbrsCK7mbajR7jwZVLxW3tIiY20uAagWtYuxmDhejbuhy4o
	 T5fU0Puxzr15LA2DmZ+8O/LODfC2dBORX39EDfdG58TLOb6sjSn9qpYtgVYp+tmszF
	 eqgqFioSqhIDyiQmgSMguEThl1RSKgcXNWL8Z/MBCz+1Ce0dOiVpLOqzA89cUyTN2u
	 lJ0kDc23g3LeA==
From: "Anthony PERARD" <anthony.perard@vates.tech>
Subject: =?utf-8?Q?Re:=20[PATCH]=20xentrace:=20free=20CPU=20mask=20string=20before=20overwriting=20pointer?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1737032844354
To: "Jan Beulich" <jbeulich@suse.com>
Cc: xen-devel@lists.xenproject.org, "Oleksii Kurochko" <oleksii.kurochko@gmail.com>
Message-Id: <Z4kEi-qPzRQpAwsC@l14>
References: <fedf2b9d-a475-4062-b8a4-5e33c7dd6305@suse.com>
In-Reply-To: <fedf2b9d-a475-4062-b8a4-5e33c7dd6305@suse.com>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.1127180d23774829bb59a9e75bd419e9?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250116:md
Date: Thu, 16 Jan 2025 13:07:25 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On Tue, Jan 14, 2025 at 09:12:37AM +0100, Jan Beulich wrote:
> While multiple -c options may be unexpected, we'd still better deal with
> them properly.
> 
> Also restore the blank line that was bogusly zapped by the same commit.
> 
> Coverity-ID: 1638723
> Fixes: e4ad2836842a ("xentrace: Implement cpu mask range parsing of human values (-c)")
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Anthony PERARD <anthony.perard@vates.tech>

Thanks,

-- 

 | Vates 

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


From xen-devel-bounces@lists.xenproject.org Thu Jan 16 13:12:17 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 13:12:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873575.1284577 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYPfT-0000fD-NJ; Thu, 16 Jan 2025 13:12:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873575.1284577; Thu, 16 Jan 2025 13:12:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYPfT-0000f6-KY; Thu, 16 Jan 2025 13:12:15 +0000
Received: by outflank-mailman (input) for mailman id 873575;
 Thu, 16 Jan 2025 13:12: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
 <SRS0=PdhZ=UI=bounce.vates.tech=bounce-md_30504962.678905aa.v1-9424578a66f24915a65dc65823ee464c@srs-se1.protection.inumbo.net>)
 id 1tYPfS-0000f0-I7
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 13:12:14 +0000
Received: from mail133-1.atl131.mandrillapp.com
 (mail133-1.atl131.mandrillapp.com [198.2.133.1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7f3ada28-d40b-11ef-99a4-01e77a169b0f;
 Thu, 16 Jan 2025 14:12:12 +0100 (CET)
Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail133-1.atl131.mandrillapp.com (Mailchimp) with ESMTP id
 4YYjvG6kB4zBsW9BX
 for <xen-devel@lists.xenproject.org>; Thu, 16 Jan 2025 13:12:10 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 9424578a66f24915a65dc65823ee464c; Thu, 16 Jan 2025 13:12:10 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 7f3ada28-d40b-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1737033130; x=1737303130;
	bh=bHVbnQrA+apYF5cGgvaLXBOWXQDf8GIbShzQDUS0SKQ=;
	h=From:Subject:To:Cc:Message-Id:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=NMB4tdtIthEPJcQiBCYnix9QPQji4PS2FlgcwKSfS30Ri1hbcxyJMJ8psl58FrcRg
	 iLMAQERpl32HaR+ijT2Fpl1OyCDSvWOmS15vITzFvD/0MEiLqwmU0QABeW2RgAi6Ns
	 hN+NokAO1KHLjw2HttRylLiCb1KNo5Vc2qs9tVU1zTxpL9m98f1ar4+T5FBWyNn/J2
	 vK+AhFOq9jL4MgHEzL4ULmyBJ7rPP1YRzz2QNEc0MNh6EZQrjEKjhE/aTaVeFXH+PN
	 +J0mY/uJbCf0jjv5oOaL7/XKODGgplSu7IAk5GifNkZy9sFGSkL0DxhBfePE9kmBnR
	 VEXR3L0ahNLDQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1737033130; x=1737293630; i=anthony.perard@vates.tech;
	bh=bHVbnQrA+apYF5cGgvaLXBOWXQDf8GIbShzQDUS0SKQ=;
	h=From:Subject:To:Cc:Message-Id:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=cJRNuOgwwdra8Ra6yiWLrKcRq0k6BpqVuYzK4IqDCRquN1fgncDBKgJNJRfe9xmNh
	 xn8uIOVwhAnWec+5asu2L1+xo1v7G/odaZ6vyNs0myWf9B0Z7lz2+RuZQ1yLCRp65O
	 63uD86DAQobGfvhXgB7kF0vG14devdtHIMZJ3y1CWEDQazFAfTSyq4bp0eoJWvohyP
	 y9KKlMXtHYUhC+Kj1a9cBhHglA272JxPFgj3fUrT3pN/HvndcxyErBG+133FuXMS2l
	 LyVsXWs/RrleAkHL2XH4mCHP7xcgJZnXxSOZMPkYNjYng8adYNggu+yfWE5NDPhukL
	 yWtu/qlvr/dkw==
From: "Anthony PERARD" <anthony.perard@vates.tech>
Subject: =?utf-8?Q?Re:=20[PATCH]=20xl:=20properly=20dispose=20of=20vTPM=20struct=20instance?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1737033129829
To: "Jan Beulich" <jbeulich@suse.com>
Cc: xen-devel@lists.xenproject.org, "Oleksii Kurochko" <oleksii.kurochko@gmail.com>
Message-Id: <Z4kFqZCcwjNggdUi@l14>
References: <73a01ddf-6090-4fda-a8c0-5703e7c9e81b@suse.com>
In-Reply-To: <73a01ddf-6090-4fda-a8c0-5703e7c9e81b@suse.com>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.9424578a66f24915a65dc65823ee464c?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250116:md
Date: Thu, 16 Jan 2025 13:12:10 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On Tue, Jan 14, 2025 at 09:13:16AM +0100, Jan Beulich wrote:
> The backend_domname field requires separate freeing; make sure to call
> libxl_device_vtpm_dispose() also on respective error paths.
> 
> Coverity-ID: 1638719
> Fixes: dde22055ac3a ("libxl: add vtpm support")
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Anthony PERARD <anthony.perard@vates.tech>

Thanks,

-- 

Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


From xen-devel-bounces@lists.xenproject.org Thu Jan 16 13:13:35 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 13:13:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873583.1284586 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYPgi-0001DP-0x; Thu, 16 Jan 2025 13:13:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873583.1284586; Thu, 16 Jan 2025 13:13:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYPgh-0001DI-UM; Thu, 16 Jan 2025 13:13:31 +0000
Received: by outflank-mailman (input) for mailman id 873583;
 Thu, 16 Jan 2025 13:13: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
 <SRS0=8Vl/=UI=bounce.vates.tech=bounce-md_30504962.678905f6.v1-b58ca62c75f04763b5700872826744ff@srs-se1.protection.inumbo.net>)
 id 1tYPgf-0001DA-VK
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 13:13:29 +0000
Received: from mail133-1.atl131.mandrillapp.com
 (mail133-1.atl131.mandrillapp.com [198.2.133.1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ac507679-d40b-11ef-a0e2-8be0dac302b0;
 Thu, 16 Jan 2025 14:13:28 +0100 (CET)
Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail133-1.atl131.mandrillapp.com (Mailchimp) with ESMTP id
 4YYjwk4tNBzBsV52b
 for <xen-devel@lists.xenproject.org>; Thu, 16 Jan 2025 13:13:26 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 b58ca62c75f04763b5700872826744ff; Thu, 16 Jan 2025 13:13:26 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ac507679-d40b-11ef-a0e2-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1737033206; x=1737303206;
	bh=JV/iMG/hrEsDwBsWn+9dUNxeR47ZvBedy3wUovrLXPE=;
	h=From:Subject:To:Cc:Message-Id:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=yL0oVFxH9+kL0HK7o/8TUJdEaEpTGV2Ywml1OyIis638YfxJLKxDXll8O0HBfSsP5
	 EnRnRKCAhH/dbA7jFx5sWgmI/9r0sx0cQ1BU8ErUV+JKrlPTFYwSlgBIT4zSV8rGf9
	 gCpEmpq5s9XL1lDQTzG+Y4S26azuQIA2zBA0BHsJ+PSbRxwUPIlGbMJuCfc/ixkcbJ
	 6GyDYl6FZzwKRt3J9IAmt8nB+515RJolLJ0DYlcG5U6uspfclDomXV7h8E9bNaj3MN
	 +Z33ukupEQ6k37oDf/baLRpfNpLzSaRhTlSp/pZsp+ck+pjSp3dfHws8hajbkHYmtT
	 YxhUeE049KjzQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1737033206; x=1737293706; i=anthony.perard@vates.tech;
	bh=JV/iMG/hrEsDwBsWn+9dUNxeR47ZvBedy3wUovrLXPE=;
	h=From:Subject:To:Cc:Message-Id:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=nDSMxCNRbOJkgHFW6f7Big76UEIsUNP7OtGf7aHgXYVw6NjdbuWP4fZ/VGhdqMOXA
	 7VaPQllCB1mCS/xhbcwe4uiEdxZT5KVVBOEgUV6Lk6Pfwq4lO9wE4jA6Uvco194nlX
	 o0CCfLdubevptp99V2BC1WgMMxz88Lnp1oOrnJwr7SsBlhIuHFFPgq8oDWskCl98ZI
	 kmlo7SmMS2Z9ATTXRRQWOjVWwRzIbzzfafbYqyFd+eLNmmxQ84D67Gw4MI+gw078R5
	 +qsL78+8yz8zIwkLLLzudRjN9NKkQDYwN/PZf7NwZ+Xaj3jmHReA9YyOfBiD+3OCFD
	 NyJA8TazXlVQg==
From: "Anthony PERARD" <anthony.perard@vates.tech>
Subject: =?utf-8?Q?Re:=20[PATCH=20v2]=20xl:=20properly=20dispose=20of=20libxl=5Fdominfo=20struct=20instances?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1737033205722
To: "Jan Beulich" <jbeulich@suse.com>
Cc: xen-devel@lists.xenproject.org, "Oleksii Kurochko" <oleksii.kurochko@gmail.com>
Message-Id: <Z4kF9aniy2JoP1ie@l14>
References: <4460f13b-03bc-4ca0-aa97-facde3122be4@suse.com>
In-Reply-To: <4460f13b-03bc-4ca0-aa97-facde3122be4@suse.com>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.b58ca62c75f04763b5700872826744ff?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250116:md
Date: Thu, 16 Jan 2025 13:13:26 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On Tue, Jan 14, 2025 at 02:29:12PM +0100, Jan Beulich wrote:
> The ssid_label field requires separate freeing; make sure to call
> libxl_dominfo_dispose() as well as libxl_dominfo_init(). Since vcpuset()
> calls only the former, add a call to the latter there at the same time.
> 
> Coverity-ID: 1638727
> Coverity-ID: 1638728
> Fixes: c458c404da16 ("xl: use libxl_domain_info to get the uuid in printf_info")
> Fixes: 48dab9767d2e ("tools/xl: use libxl_domain_info to get domain type for vcpu-pin")
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Release-Acked-by: Oleksii Kurochko<oleksii.kurochko@gmail.com>

Acked-by: Anthony PERARD <anthony.perard@vates.tech>

Thanks,

-- 

Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


From xen-devel-bounces@lists.xenproject.org Thu Jan 16 13:45:13 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 13:45:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873592.1284599 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYQB5-0005mR-EV; Thu, 16 Jan 2025 13:44:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873592.1284599; Thu, 16 Jan 2025 13:44:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYQB5-0005mK-C1; Thu, 16 Jan 2025 13:44:55 +0000
Received: by outflank-mailman (input) for mailman id 873592;
 Thu, 16 Jan 2025 13:44:54 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=5HgK=UI=bounce.vates.tech=bounce-md_30504962.67890d52.v1-f73ea77b3cea41ca8fc34524bafcfe5a@srs-se1.protection.inumbo.net>)
 id 1tYQB4-0005mE-G0
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 13:44:54 +0000
Received: from mail187-43.suw11.mandrillapp.com
 (mail187-43.suw11.mandrillapp.com [198.2.187.43])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0f53757e-d410-11ef-99a4-01e77a169b0f;
 Thu, 16 Jan 2025 14:44:52 +0100 (CET)
Received: from pmta09.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail187-43.suw11.mandrillapp.com (Mailchimp) with ESMTP id
 4YYkcy75gGzLfHJXv
 for <xen-devel@lists.xenproject.org>; Thu, 16 Jan 2025 13:44:50 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 f73ea77b3cea41ca8fc34524bafcfe5a; Thu, 16 Jan 2025 13:44:50 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 0f53757e-d410-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1737035091; x=1737305091;
	bh=CxJQhexA8x8AADvqtEfVv/6jNb5za2wMWCq+dJ4E3gU=;
	h=From:Subject:To:Cc:Message-Id:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=CYGFpKo1A2Ur6NZKrr0kpCuG1rLH5UB4n3fzaASbIZyYRmeE2dUThgdiyQ72ewHVc
	 mh7uRrQRyJ5RygqJdIeHXkwLET3cKi+6o5/wWPYiRVP4W2ja60HU5mqRoHv59UM27f
	 jXD2TMLIlGpahTBE9nO6HVYqbiLBspYBem5LuMotbivzVOwgd0YZiebXr37MLpv3o4
	 EzcivFf8661tudpRM9LaxhfWkyHa+CGnWB8CpIHpgvtD1oHrsZDc46U9ucAbrUBYgz
	 5W766+qH17bUWzRCczf2dLNpRoGkFHzc2hV48I95tJbBbhpF8q2zyu60tfKzfk7SLO
	 7h4EIx7bdgJcA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1737035091; x=1737295591; i=anthony.perard@vates.tech;
	bh=CxJQhexA8x8AADvqtEfVv/6jNb5za2wMWCq+dJ4E3gU=;
	h=From:Subject:To:Cc:Message-Id:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=fbElwXC8QRvBUbZtCwW0jnejsmb5cgmamHwlhyspeaHK6WVFOBjeuv7+Thba5Susr
	 cB1YNeZn/Lep5uyZZbCgkBw68vLp0hPnpeszcI1fdF/kCnHEm3h9zjE9N36CKFVw8s
	 TmaxPLNruzgbOIWsiujnXMfE9K/neeoT4A9E3Swcp7OVfthbl1sbO75KqWxJgZJSUw
	 uVULoqlDCgGvXmKY7U8UGwAX26H1po6HnV0NzcWUvRtZG2FVJkntPFhZk7JRVHoPvm
	 HM6nxNJIXTKt2kcb9qw6hBkL9YCnvEaQ5eCVvLR5WwoWcnUVClaXs44twIs3vRyzT0
	 lsskGy197vJzQ==
From: "Anthony PERARD" <anthony.perard@vates.tech>
Subject: =?utf-8?Q?Re:=20[PATCH=20v7=207/7]=20tools/xenstored:=20use=20new=20stable=20interface=20instead=20of=20libxenctrl?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1737035090163
To: "Juergen Gross" <jgross@suse.com>
Cc: xen-devel@lists.xenproject.org, "Samuel Thibault" <samuel.thibault@ens-lyon.org>, "Julien Grall" <julien@xen.org>
Message-Id: <Z4kNUd_etZTBlX7S@l14>
References: <20250109105935.23585-1-jgross@suse.com> <20250109105935.23585-8-jgross@suse.com>
In-Reply-To: <20250109105935.23585-8-jgross@suse.com>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.f73ea77b3cea41ca8fc34524bafcfe5a?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250116:md
Date: Thu, 16 Jan 2025 13:44:50 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On Thu, Jan 09, 2025 at 11:59:35AM +0100, Juergen Gross wrote:
> Replace the current use of the unstable xc_domain_getinfo_single()
> interface with the stable domctl XEN_DOMCTL_get_domain_state call
> via the new libxenmanage library.
> 
> This will remove the last usage of libxenctrl by Xenstore, so update
> the library dependencies accordingly.
> 
> For now only do a direct replacement without using the functionality
> of obtaining information about domains having changed the state.
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>
> Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>

Thanks,

-- 

Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


From xen-devel-bounces@lists.xenproject.org Thu Jan 16 14:00:19 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 14:00:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873606.1284610 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYQPq-0000LD-PK; Thu, 16 Jan 2025 14:00:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873606.1284610; Thu, 16 Jan 2025 14:00:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYQPq-0000L6-M0; Thu, 16 Jan 2025 14:00:10 +0000
Received: by outflank-mailman (input) for mailman id 873606;
 Thu, 16 Jan 2025 14:00:09 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=PV9y=UI=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tYQPp-0000Kw-Fm
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 14:00:09 +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 30f58cec-d412-11ef-99a4-01e77a169b0f;
 Thu, 16 Jan 2025 15:00:06 +0100 (CET)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-5d3ecae02beso1359346a12.0
 for <xen-devel@lists.xenproject.org>; Thu, 16 Jan 2025 06:00:06 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c95b09b2sm925387266b.146.2025.01.16.06.00.04
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 16 Jan 2025 06:00:05 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 30f58cec-d412-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737036006; x=1737640806; 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=Nt5tZUxfG2TMA2CB2W1W3RklLqcWU+NHY2yBLyCbl7Q=;
        b=pE2lmswfRKU0rbCCiIuRyryaDyk7F0GHycpvJEWP0i6V59nbSVoExjPPuAcJEo3Sy7
         dHJSugvGxMXeeSTOEXtt1K+ttGAN4jeqnkWSd9ZBFN8iOCJBhPE7MFGy0tqlIFvORckx
         UtNFm/WCnCmaUGKyBZDKH9zYRaX0U/qCCkywg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737036006; x=1737640806;
        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=Nt5tZUxfG2TMA2CB2W1W3RklLqcWU+NHY2yBLyCbl7Q=;
        b=LqicrjggXAGPNAS1IlH5KR6AdNTnbO4kAeKRBilxEqO2uhYS/ZDoTcdvHSDsxLqe46
         cS6Y2LjWFgJxQcoDeA6zmV18IZCWdWBOeHvsu8iPn09j+6DVcMpcxg+tH/5HBftLyYwc
         MYxFfqvmPINsA5Ho7T05BkLlt0g4xXfQRyeVxls//yJSQ5Ol+RY5WvudHCE5h3+ssIHq
         gx1FksJrN7+yQ0oPOp0OYGziqC5uHn0+cCuWyy5xC5uRQEWrtvYIub2aTiBrRkZCfBuK
         5SwJNVmdCnbUe0niSeQ0mf2xXyS3k5ix058Va1qU9YYJExm3GVBZrlCN9zAqmbuG2Wfn
         lbtQ==
X-Gm-Message-State: AOJu0YyiDQm679JEaGpCv+DAQTJoOVffSvYtuz/Ko3c+3hFqkSMX+ZvU
	lZEY64YtKIxX+oWhHpmrAXM4Di3+260WTRTJrJyNbPedHUfy/wD5go4wIXDg2cwPsZyLDu8VHZB
	m
X-Gm-Gg: ASbGncsjqyS8DsOoGyQTlZQt0j9bDqUI0IzTrZw3JL7n7YFqbiTtwBycAtsbvm/UE3i
	01g/vejTdah3PWm95jtbyTs/wVgx9ctleRGHtYpVlb7YJjujcWnZB29f8eSpeAI0wS15FF4/XvB
	ubZMUfQCFt1BZk1Sl/B6HVPA6+FyRy1lNLtq7xtBBaloA9RQAlIAVJL3QEspbCJJPFBg7CZ73ay
	Otz66sWmCRxHjHZPSMVrrfAh0GqWPUfD3cQqwVCB2Vg8vjBLxXSM6R5mNf9eA==
X-Google-Smtp-Source: AGHT+IEboO17plnsAbiFBo3crdNvP5rGg2eOQ55fSCqSCS10u6Da+mHBa2rkD2GfhU94TOK+fO1aBQ==
X-Received: by 2002:a17:907:968e:b0:aa6:7662:c56d with SMTP id a640c23a62f3a-ab2ab709415mr3117921766b.30.1737036005690;
        Thu, 16 Jan 2025 06:00:05 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH for-4.20 v2 2/2] automation/cirrus-ci: introduce FreeBSD randconfig builds
Date: Thu, 16 Jan 2025 14:59:57 +0100
Message-ID: <20250116135957.80826-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <Z4j4s-1iK2CH4ssK@macbook.local>
References: <Z4j4s-1iK2CH4ssK@macbook.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Add a new randconfig job for each FreeBSD version.  This requires some
rework of the template so common parts can be shared between the full and
the randconfig builds.  Such randconfig builds are relevant because FreeBSD
is the only tested system that has a full non-GNU toolchain.

While there replace the usage of the python311 package with python3, which is
already using 3.11, and remove the install of the plain python package for full
builds.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 .cirrus.yml | 67 ++++++++++++++++++++++++++++++++++++++++-------------
 1 file changed, 51 insertions(+), 16 deletions(-)

diff --git a/.cirrus.yml b/.cirrus.yml
index ee80152890f2..7216729b6993 100644
--- a/.cirrus.yml
+++ b/.cirrus.yml
@@ -1,34 +1,69 @@
 # https://cirrus-ci.org/guide/tips-and-tricks/#sharing-configuration-between-tasks
-freebsd_template: &FREEBSD_TEMPLATE
+freebsd_13: &FREEBSD_13
+  freebsd_instance:
+    image_family: freebsd-13-4
+freebsd_14: &FREEBSD_14
+  freebsd_instance:
+    image_family: freebsd-14-2
+freebsd_15: &FREEBSD_15
+  freebsd_instance:
+    image_family: freebsd-15-0-snap
+
+freebsd_template: &FREEBSD_ENV
   environment:
     APPEND_LIB: /usr/local/lib
     APPEND_INCLUDES: /usr/local/include
 
+freebsd_full_build_template: &FREEBSD_FULL_BUILD_TEMPLATE
+  << : *FREEBSD_ENV
+
   install_script: pkg install -y seabios gmake ninja bash
-                                 pkgconf python bison perl5
+                                 pkgconf bison perl5
                                  yajl lzo2 pixman argp-standalone
-                                 libxml2 glib git python311
+                                 libxml2 glib git python3
 
   build_script:
     - cc --version
-    - export PYTHON=/usr/local/bin/python3.11
     - ./configure --with-system-seabios=/usr/local/share/seabios/bios.bin
     - gmake -j`sysctl -n hw.ncpu` clang=y
 
+freebsd_randconfig_template: &FREEBSD_RANDCONFIG_TEMPLATE
+  << : *FREEBSD_ENV
+
+  install_script: pkg install -y gmake python3 bison
+
+  build_script:
+    - cc --version
+    - gmake -j`sysctl -n hw.ncpu` -C xen clang=y \
+            KCONFIG_ALLCONFIG=tools/kconfig/allrandom.config randconfig
+    - gmake -j`sysctl -n hw.ncpu` build-xen clang=y
+
 task:
-  name: 'FreeBSD 13'
-  freebsd_instance:
-    image_family: freebsd-13-4
-  << : *FREEBSD_TEMPLATE
+  name: 'FreeBSD 13: full build'
+  << : *FREEBSD_13
+  << : *FREEBSD_FULL_BUILD_TEMPLATE
 
 task:
-  name: 'FreeBSD 14'
-  freebsd_instance:
-    image_family: freebsd-14-2
-  << : *FREEBSD_TEMPLATE
+  name: 'FreeBSD 14: full build'
+  << : *FREEBSD_14
+  << : *FREEBSD_FULL_BUILD_TEMPLATE
 
 task:
-  name: 'FreeBSD 15'
-  freebsd_instance:
-    image_family: freebsd-15-0-snap
-  << : *FREEBSD_TEMPLATE
+  name: 'FreeBSD 15: full build'
+  << : *FREEBSD_15
+  << : *FREEBSD_FULL_BUILD_TEMPLATE
+
+task:
+  name: 'FreeBSD 13: randconfig'
+  << : *FREEBSD_13
+  << : *FREEBSD_RANDCONFIG_TEMPLATE
+
+task:
+  name: 'FreeBSD 14: randconfig'
+  << : *FREEBSD_14
+  << : *FREEBSD_RANDCONFIG_TEMPLATE
+
+task:
+  name: 'FreeBSD 15: randconfig'
+  << : *FREEBSD_15
+  << : *FREEBSD_RANDCONFIG_TEMPLATE
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Thu Jan 16 14:02:54 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 14:02:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873615.1284619 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYQST-0001GB-5i; Thu, 16 Jan 2025 14:02:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873615.1284619; Thu, 16 Jan 2025 14:02:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYQST-0001G4-2w; Thu, 16 Jan 2025 14:02:53 +0000
Received: by outflank-mailman (input) for mailman id 873615;
 Thu, 16 Jan 2025 14:02:52 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=EPy+=UI=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tYQSS-0001Fy-34
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 14:02:52 +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 92eabec7-d412-11ef-a0e2-8be0dac302b0;
 Thu, 16 Jan 2025 15:02:51 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-aa689a37dd4so206103566b.3
 for <xen-devel@lists.xenproject.org>; Thu, 16 Jan 2025 06:02:51 -0800 (PST)
Received: from [10.81.35.177] ([46.149.103.10])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c90df91esm911935666b.79.2025.01.16.06.02.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 16 Jan 2025 06:02:39 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 92eabec7-d412-11ef-a0e2-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737036171; x=1737640971; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=iFAE9J6bA0Y8GbUjaDp0sHDRaG8WCii4dd6ZDIDMans=;
        b=iNxUdmAnqd70lzXQml6X7deydEN+CKvWEVqwkgla1gAow+pDzC9qjXQJqFYzIH6C1G
         DFA2arMo5sUoJ8tk4E6JzKVad7YzyTRE5x1ErD9C813Be2Xd3GLy6fA6Bkb+RWbtcAf9
         Vaxoz8nMJn5hkAyN3TeYpCob8r+MiYYFs23Cg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737036171; x=1737640971;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=iFAE9J6bA0Y8GbUjaDp0sHDRaG8WCii4dd6ZDIDMans=;
        b=uIzVEkzju0T59VEsGo0vNVnmm8ADWl3wFAcEk4i8GulZcSp1Y2k6pjE7ktm74SKokL
         ogq3Qsu7pqBD/16ZeLsL/PIy8SKoo5e9tZ6jypI8J6MmFhxi9Cf0aJNEWJisRo7WAeRq
         JvR2y2X7mFi3w7qLzfRcubs8jth2696Z5NjUqpGjTND0iWym7dbnh8Qv17o9GwgcZAeT
         CmdH97IBe3q1AS7uq9E90bjM/BtaAtXUqYlwuN/EzaAN5NggK0s6Zu+8b25PwzmsXAdl
         79QAFYwrUv/6UzyTiSEI2mwn9UqJIOxeZCdX+ETVLlfB79eAHIK82OMr66zYm6dR4rMJ
         s01A==
X-Forwarded-Encrypted: i=1; AJvYcCUJSoHS5v5/lBF4cBvkGjNCJyL+zNQuZbumOzrIC1EGPy0OMinKhaJE2UfiY6vVkH6rOP7/qNX8kGI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwYwpeBzicHUc75am/jd7Ars0cqEbr2z4VyvNUfQsApuNQBRN3t
	6Ilb6aew+34qt7rqiLvu8sb4KwHmludDEu8G0yJI6mCLcWRnY32YTDG54WCLoaOkJ8o/dCdBvmy
	vm8s=
X-Gm-Gg: ASbGnctWddedd1krN9dOejXn/yC+ikJRxoNCgGFwuDyMx8eqmb9D6wYA7hVC2/cCAd7
	kRgM0wnKWLr0FWO5pCTZCdbUJpdzQj+0t1pEGpfTwXjlfKt881ne5r4odggoFYHE/psGfrj2Olh
	bx7HqLw66UWoxLYhiRvZuX8Q/CtQ8AD9PKM7JkgPeEWD74oZ9hb//RzTXq+qxsXZR6fzdZEwDlm
	Atf7+awL0o0mB10/yCCCIjDeW9UKE0HQj9EqkwQLRWzwd8peZ/owxvQCLyF1KJvUc0=
X-Google-Smtp-Source: AGHT+IEG+lPJLTujh0IjZrFDiUgCEHn5tcOOqQO4TceZXblBVI1hRU4fS+GIG+10/bnYVL1iDFi5+w==
X-Received: by 2002:a17:907:720e:b0:aa6:6c08:dc79 with SMTP id a640c23a62f3a-ab2ab741567mr3194133166b.35.1737036159445;
        Thu, 16 Jan 2025 06:02:39 -0800 (PST)
Message-ID: <94bbb56e-4a44-4981-a617-cdc541ea5308@citrix.com>
Date: Thu, 16 Jan 2025 14:02:38 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20 v2 2/2] automation/cirrus-ci: introduce FreeBSD
 randconfig builds
To: Roger Pau Monne <roger.pau@citrix.com>, xen-devel@lists.xenproject.org
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>
References: <Z4j4s-1iK2CH4ssK@macbook.local>
 <20250116135957.80826-1-roger.pau@citrix.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <20250116135957.80826-1-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 16/01/2025 1:59 pm, Roger Pau Monne wrote:
> Add a new randconfig job for each FreeBSD version.  This requires some
> rework of the template so common parts can be shared between the full and
> the randconfig builds.  Such randconfig builds are relevant because FreeBSD
> is the only tested system that has a full non-GNU toolchain.
>
> While there replace the usage of the python311 package with python3, which is
> already using 3.11, and remove the install of the plain python package for full
> builds.
>
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>

That looks cleaner, and likely to have better longevity.  Thanks.

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>


From xen-devel-bounces@lists.xenproject.org Thu Jan 16 14:13:57 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 14:13:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873623.1284630 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYQd5-0003Es-4p; Thu, 16 Jan 2025 14:13:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873623.1284630; Thu, 16 Jan 2025 14:13:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYQd5-0003El-1x; Thu, 16 Jan 2025 14:13:51 +0000
Received: by outflank-mailman (input) for mailman id 873623;
 Thu, 16 Jan 2025 14:13: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
 <SRS0=PV9y=UI=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tYQd3-0003Ef-GP
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 14:13:49 +0000
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [2a00:1450:4864:20::534])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1968452e-d414-11ef-99a4-01e77a169b0f;
 Thu, 16 Jan 2025 15:13:46 +0100 (CET)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-5d3ecae02beso1381866a12.0
 for <xen-devel@lists.xenproject.org>; Thu, 16 Jan 2025 06:13:46 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab384ce1777sm206966b.56.2025.01.16.06.13.45
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 16 Jan 2025 06:13:45 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1968452e-d414-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737036826; x=1737641626; 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=ZlfQH2akjNZXtvLQjhwM/MLBUNqHYF0JmuKFBUgzlu4=;
        b=ABCEpD+f4WC+iAYWbqVdCGcji8tM218oUK/TLm5xSLRYPetBchSX7pwY3Do7fFCQ2Q
         hjgW8xTZBTu+GtJt6rof3H7ZoSMrnHHyZ3dc5bMgvkoCDuBGjq7054Z8G3UNLketcZV/
         p263/sLONdwpKZkKoTiMG3zhUhP2koqGChm+A=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737036826; x=1737641626;
        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=ZlfQH2akjNZXtvLQjhwM/MLBUNqHYF0JmuKFBUgzlu4=;
        b=DTsY9zeha3qKpwRXDEkTKr9kcbEy5/tszBdqXimovK6KbQrdlgjCFO24NS71jbRYye
         aj8iyC3s0CwftjbhbASuPEu1zEhxB4qwsjfaEt+sdj7WMRZRmhnpEfAfT9jcK5c5HR7a
         wbDQ3gPuyxENDhUYUjN68Ziw7evqaoDizWEldONZ/pdNMGCTlCCt1Xab73SE/Z0T84Xq
         qBEpPOBb8Bkl+6QoqMUmDJ9qc1Zx+QdF7WNtqD3BFdNdk10lUeUv48tG22x5u1eBeFHo
         TGBOOzr2Fr9O8IuOKVwBQ8FZ3JY7xSI/GbsP0MOMS/6/kvZliJ6X96TVl43VHE862bWz
         7Dlw==
X-Gm-Message-State: AOJu0Yy+/F9H1gm+iD6/RUzFxN+7lgfrN8il/fXVXy4A6NpatxNxjfXb
	xluPv15E3DSXtrKt4eT5EjGeHEwmzAN6+/tr4bZclMIfmyygxxB0xH46/OAS4wA=
X-Gm-Gg: ASbGncu16xCOOUteLqcrJ4NU0L8qoSru0CLb2Hky63Mq1BjigfUvdo6BGc7xT+DDZoc
	p2LLB+Fpl7ubfm2geny0YlYvE1luMB/aK3/HKvdnXj0Vglh9l2z95IfpWCrpI2sTTyly0ua9LiE
	ZcGUhcZ4oFn/xoOxjC1HTnosdJV6bbH4+NmFOTKA5SW/2pKr0epjgUKVFAZuKzEY57kyHoGS8Y3
	0NznUPgyV/+He+dIkJwUlRFSfDKGMEIU4rW9OM9WDKViMioYpHCI0SPNlz4Hg==
X-Google-Smtp-Source: AGHT+IH4UX0YqKXfX/bYeZglj5ja6xd6GOHzA99uvIqJ/IAVML+ilw7TqIB2HW16exRLhPb9QNrWuQ==
X-Received: by 2002:a17:907:d1b:b0:aac:23f4:f971 with SMTP id a640c23a62f3a-ab2ab70a173mr3491363466b.33.1737036825826;
        Thu, 16 Jan 2025 06:13:45 -0800 (PST)
Date: Thu, 16 Jan 2025 15:13:44 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: xen-devel@lists.xenproject.org,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH for-4.20 v2 2/2] automation/cirrus-ci: introduce FreeBSD
 randconfig builds
Message-ID: <Z4kUGFKFHFBExvBl@macbook.local>
References: <Z4j4s-1iK2CH4ssK@macbook.local>
 <20250116135957.80826-1-roger.pau@citrix.com>
 <94bbb56e-4a44-4981-a617-cdc541ea5308@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <94bbb56e-4a44-4981-a617-cdc541ea5308@citrix.com>

On Thu, Jan 16, 2025 at 02:02:38PM +0000, Andrew Cooper wrote:
> On 16/01/2025 1:59 pm, Roger Pau Monne wrote:
> > Add a new randconfig job for each FreeBSD version.  This requires some
> > rework of the template so common parts can be shared between the full and
> > the randconfig builds.  Such randconfig builds are relevant because FreeBSD
> > is the only tested system that has a full non-GNU toolchain.
> >
> > While there replace the usage of the python311 package with python3, which is
> > already using 3.11, and remove the install of the plain python package for full
> > builds.
> >
> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> 
> That looks cleaner, and likely to have better longevity.  Thanks.
> 
> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

Forgot to Cc Oleksii on the patches, as I would like a Release-Ack.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jan 16 15:11:13 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 15:11:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873640.1284640 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYRWL-000388-W7; Thu, 16 Jan 2025 15:10:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873640.1284640; Thu, 16 Jan 2025 15:10:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYRWL-000381-Sz; Thu, 16 Jan 2025 15:10:57 +0000
Received: by outflank-mailman (input) for mailman id 873640;
 Thu, 16 Jan 2025 15:10:56 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=kdRh=UI=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tYRWK-00037v-NE
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 15:10:56 +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 153d06dd-d41c-11ef-a0e2-8be0dac302b0;
 Thu, 16 Jan 2025 16:10:55 +0100 (CET)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-43623f0c574so6886365e9.2
 for <xen-devel@lists.xenproject.org>; Thu, 16 Jan 2025 07:10: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
 5b1f17b1804b1-43890367b48sm2473845e9.0.2025.01.16.07.10.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 16 Jan 2025 07:10:53 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 153d06dd-d41c-11ef-a0e2-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737040255; x=1737645055; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=zdRIhZHsbbFvURBS8/QHEf5PM16SAMuExybb9/BAnN8=;
        b=CymcNiTkRIJ5Kn7xfnI5aTzkpO+XPquQaEOYWXJmZCeVW4JXJXkN8tb3tpazK203XD
         gX/d2cqatPyPThXr/GRulxh3+GF8d1hOdQFKXd/eubOvosV3QXUXDb99kYlYuo9u6T2a
         WIkAKluT5o5U9Kp+L387QmTYrFS2GBn4h85Id04L48TurqHQkldS9bw0nExxUH1N29Jv
         zRqgWP2vSBl+JDP3uuZNj9ZQT0HIZ4PQYXG/jZCqEuNLMlZIWCUw3PMYaugOIpa1NTOu
         ODwvmQWDhArFElNVJHkJXLBtSIL2DjvmWVhZSgHim1DbnloarYM8K4aLcYbXAR8zcT9V
         u2AQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737040255; x=1737645055;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=zdRIhZHsbbFvURBS8/QHEf5PM16SAMuExybb9/BAnN8=;
        b=HlouAoS177sgbiXOuvXzWr6B0tWP3IN4lds/ikT7SHgjOqt9pvAADHkZ7hDFcKTcyQ
         A62qgsTIFhide65DyRvcSgJzV2/MXjqG9EEr3CIvn9cOwrqRCJcB8RRnPDBApuS/ATGX
         B+WY1aBO8g23pJs/DYoADWolf3KC/ymf2kfpLfAz7LG6i06yPwzdfJulfw369BONhvZG
         D9Zf9S99IbEHS1Ju3iywhxHvJSKpHhEIrVWpa1dg0vvoDpqL0qcP9ia0zXV0RyO/dgnV
         GObEtQFNr/6A6v+As3B2ObiVR1sy5PlzFJv2r9mh/0FOMQ5XVNr4aLWrPXw/hkPNb+dN
         irLA==
X-Forwarded-Encrypted: i=1; AJvYcCVEXFUFKkekgMYPVkFofqjFlZuzGCaTS3LgMWY4r4BE3/ibiqbe0y9YDZOA8F5xNvaOrhptsS+rPlA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzJmJg37vaFdP/02l0xuxh8sKeW8Ani6oQpJDkPuvVOTtK1yH1f
	M6nw9BM/TGkC9CT9kfdqPmPuRb2vRPDgQekz3q6vdfB8yKGRVvBvive0dzzWog==
X-Gm-Gg: ASbGncsGc360eSDjdf7bEWJaVFUqlJZGI0OUw9tGsIx4uotoxwES/VpxsJMfpCcX27V
	HYc90c44qi9Nv9Jn/13cIbLtTWwEJqMszibTnii7Ydad9yXdOQBZVWtW8A/A3CIiEupVIAUBsuu
	u2pGLl8XpEDr7wiehVppYJLdT7q0M1nV+wKjCoDqF8+o6mLOPN+ybwxghXoeTf26XD4oNADCFwN
	heLJYZuxoLgTQ2KaCQ22GWVXKV4szRDVHmv7H5VKEcApFxSxg9y6/H0LXvJCyaxiTl3ej6THhnT
	3kYSXdtiORTUQ5ChYLYW9HoSfRArBhGJ8LxuRuvzEg==
X-Google-Smtp-Source: AGHT+IHZqeZ0ioO2JhokBn+E1qHLFTJs3J1lwQf2Jyih+kNPabT1nE660fU1dCE+D2ULaC6Mj51sZA==
X-Received: by 2002:a05:600c:4ecd:b0:434:f739:7ce3 with SMTP id 5b1f17b1804b1-436e26954a9mr299963065e9.8.1737040253317;
        Thu, 16 Jan 2025 07:10:53 -0800 (PST)
Message-ID: <2fc6c2fd-f360-46ee-9ded-f5efd8c508bf@suse.com>
Date: Thu, 16 Jan 2025 16:10:51 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v1] xen: mem_access: conditionally compile vm_event.c
 & monitor.c
To: Sergiy Kibrik <sergiy_kibrik@epam.com>,
 Tamas K Lengyel <tamas@tklengyel.com>
Cc: Stefano Stabellini <stefano.stabellini@amd.com>,
 Julien Grall <julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Alexandru Isaila <aisaila@bitdefender.com>,
 Petre Pircalabu <ppircalabu@bitdefender.com>, xen-devel@lists.xenproject.org
References: <20241230063051.3332332-1-Sergiy_Kibrik@epam.com>
 <c8684340-33f9-41d3-94e4-77ee3bc18306@suse.com>
 <CABfawhk4pzA9bSMzJDX7ZwaYC50dfn_ntCnk=bePmiKCpDnN3w@mail.gmail.com>
 <8fc662a1-4c74-4f97-a116-3bc5a0b71cf1@suse.com>
 <CABfawhkyg+TVB-uc04OefDhOXEfeQyQypW6gL4qsYO3ZrDxYfQ@mail.gmail.com>
 <a0c50fb6-516a-4e0e-8c3b-49c4dbc7b863@suse.com>
 <f475354d-5df6-41a5-9928-519eaf4eb7b3@epam.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <f475354d-5df6-41a5-9928-519eaf4eb7b3@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 16.01.2025 12:29, Sergiy Kibrik wrote:
> 07.01.25 10:46, Jan Beulich:
>> On 06.01.2025 19:09, Tamas K Lengyel wrote:
>>> On Mon, Jan 6, 2025 at 10:10 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> On 06.01.2025 15:05, Tamas K Lengyel wrote:
>>>>> On Mon, Jan 6, 2025 at 5:16 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>
>>>>>> On 30.12.2024 07:30, Sergiy Kibrik wrote:
>>>>>>> From: Stefano Stabellini <stefano.stabellini@amd.com>
>>>>>>>
>>>>>>> Extend coverage of CONFIG_MEM_ACCESS option and make the build of VM events
>>>>>>> and monitoring support optional.
>>>>>>
>>>>>> Yet doesn't this end up in things becoming misleading? Don't we rather need a
>>>>>> 2nd Kconfig option, with a dependency between the two? Or alternatively a
>>>>>> rename of the existing option (to describe the higher-level feature rather
>>>>>> than the lower level one)? Tamas, I'm particularly interested in knowing your
>>>>>> view here as well.
>>>>>
>>>>> Thanks Jan, I was thinking the same thing. The dependency of these
>>>>> subsystems is mem_access -> monitor -> vm_event. If the goal here is
>>>>> to disable all three levels the ideal way would be to have separate
>>>>> kconfig options for each level. It may be a bit too fine-grained
>>>>> though on ARM since there are only two types of events for monitor
>>>>> (SMC & mem_access) and only the monitor uses the vm_event channel (no
>>>>> mem-sharing/paging on ARM). So if doing separate kconfig for each
>>>>> individual feature is an overkill I would suggest using
>>>>> CONFIG_VM_EVENT that disables all three levels, including both
>>>>> mem_access & smc monitor hooks.
>>>>
>>>> Except that "disables all three levels" doesn't work, unless the other
>>>> option(s) are promptless (and selected). I'd have expected VM_EVENT to
>>>> maybe have a "depends on MEM_ACCESS", whereas a "select MEM_ACCESS"
>>>> wouldn't make much sense as long as MEM_ACCESS can be enabled
>>>> individually (with it being unclear to me whether such a configuration
>>>> is actually useful in any way).
>>>
>>> Not sure I follow. None of these systems make sense to enable
>>> individually. Without vm_event monitor/mem_access are useless, that's
>>> why I would pick CONFIG_VM_EVENT as the option on ARM to disable all
>>> three levels if we don't want to start splitting it into multiple
>>> kconfig options (which I think may be an overkill here).
>>
>> Oh, okay, you suggest to replace MEM_ACCESS by VM_EVENT at the Kconfig
>> level. That would be fine with me, so long as it's also appropriate on
>> (in particular) x86. Then, if there was ever a 2nd use of mem-access,
>> MEM_ACCESS could be re-introduced as a standalone option.
> 
> Thanks Jan,
> would it be ok to replace MEM_ACCESS with VM_EVENT everywhere at once, 
> including in defconfigs and automation script etc? Or such changes would 
> better be done gradually, starting with changing Kconfig only?

Things need to remain in sync throughout the tree, so I don't think you
can leave out e.g. defconfigs when doing the renamed. Similarly stuff
under automation/ may need changing at the same time.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 16 17:21:55 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 17:21:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873664.1284649 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYTYq-00031l-VN; Thu, 16 Jan 2025 17:21:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873664.1284649; Thu, 16 Jan 2025 17:21:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYTYq-00031e-Sl; Thu, 16 Jan 2025 17:21:40 +0000
Received: by outflank-mailman (input) for mailman id 873664;
 Thu, 16 Jan 2025 17:21: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
 <SRS0=StQj=UI=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tYTYq-00031B-Bf
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 17:21:40 +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 56a34e4c-d42e-11ef-a0e2-8be0dac302b0;
 Thu, 16 Jan 2025 18:21:38 +0100 (CET)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-43622267b2eso11445995e9.0
 for <xen-devel@lists.xenproject.org>; Thu, 16 Jan 2025 09:21:36 -0800 (PST)
Received: from localhost (0545937c.skybroadband.com. [5.69.147.124])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-437c753c60csm64359305e9.36.2025.01.16.09.21.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 16 Jan 2025 09:21:34 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 56a34e4c-d42e-11ef-a0e2-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1737048095; x=1737652895; darn=lists.xenproject.org;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=aiB7t28fo8v6Pa+jD/C05PgyVfsvktli5fg7J/PavTk=;
        b=BvKJhIIGWJ2Gtdbtwircmy03Dy4KK777bdsORE1Pj4RLSM27OGjtoecnGDUFCThS+N
         dUvfqX/KZyyrYBW/uVsaJOReQ4ywffPK0xr1x9pGr0I4Otvqjmh5zVOAaaFduZvVejEW
         abaPBNO2MtKjSR4T7NLhqRk9ulobnf55KuCXs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737048095; x=1737652895;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=aiB7t28fo8v6Pa+jD/C05PgyVfsvktli5fg7J/PavTk=;
        b=D1FBRjMvwEIa+IrUN8jVThxA7rFNoZ5om6YtF16LCEhjOrsei79LsRyDcasuElK1YX
         vEuW3GAzsjh3Aa6/AbDzLu9Hzfyk0pRa51V9urA04XA+BgvdNpgA4JnK0mZx0/gBRdRO
         H6Q3KXoUMAyYQvTZGwJcyFLXYi+Y+PAKJUSley4OBZGD2pzD5i/Ws4hCPMpJv3cAyfBt
         oF2v6ikHcAeKtFiSg1I7ZBoH3fc1xutkYv0/extVy4+ub0oMaV3z8GJ1eP96sRntMYOl
         moRKR/40+VWm+xCWHqHQk+ujT1cdicMak002zFqaQ/egMycCdLYHE1YHEDHsXLac6kKk
         dpXA==
X-Forwarded-Encrypted: i=1; AJvYcCWN5Vh+1C5VOOu5wknUQ+ZBJBkk+e2OH0CjbHgZ8rnxZWBb8oAXjPq+wPXPrxZJOPApoMCu2bnS3qI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwLjGiSLxo4RXwBtsYbBV4AmGN4DfIFehcuergqQbvMNl6ZLhqc
	Eai/ESU35glbGVLAAdeSvtAmhdsinLrO6JqwdpeqvhxHOsBCTzFeGHfY1xl/jWU=
X-Gm-Gg: ASbGncvLejyK+5jPj8+YmtykeCtvT3T9nTz5Munr1ECPHw0EyifVCk7W1BWjGoT/9PH
	8ba8axzRnZYrCHGuIwxiFJ9mNezoQPtG5W7Gfw/74po12vjaAA6kPx0+QlnPh+f6jSvmWX+qtya
	BPBwWZ+6UTDQcXL3i623BBnTZTK/Soc5krIgoCfM6puS5Kz7UOG707Bmccd7y6mBYpgwkPo7zAw
	08Zk3V/tUlH16vCVGpLV3QKPavvzPI0xgxXa7MC7EakVp0iir2qj8YwUExVM+DxYQDO+56bJi8q
	1A7tECpyYOI=
X-Google-Smtp-Source: AGHT+IGO60/8X+2XAeb2bgrS2UcjWrwcCuAaq/kQa+TdjzAMBxwmBFFDJ5XQsOXQaFqBLtNYK/ZH0A==
X-Received: by 2002:a05:600c:3ca4:b0:434:a10f:9b with SMTP id 5b1f17b1804b1-436e26ab2a2mr354174645e9.14.1737048095408;
        Thu, 16 Jan 2025 09:21:35 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Thu, 16 Jan 2025 17:21:34 +0000
Message-Id: <D73O5Q2J1MGM.2YBNH2X7YYT2E@cloud.com>
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>, "Anthony PERARD"
 <anthony.perard@vates.tech>, "Michal Orzel" <michal.orzel@amd.com>, "Julien
 Grall" <julien@xen.org>, =?utf-8?q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, "Stefano Stabellini" <sstabellini@kernel.org>,
 <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH] docs: Punctuation: Add missing commas after linking
 adverbs as intros
From: "Alejandro Vallejo" <alejandro.vallejo@cloud.com>
To: "Jan Beulich" <jbeulich@suse.com>, "Bernhard Kaindl"
 <bernhard.kaindl@cloud.com>
X-Mailer: aerc 0.18.2
References: <ad9d1d7db8d43c82a02f64b8a317d7ae6522dd62.1736964253.git.bernhard.kaindl@cloud.com> <0d2e9617-e4cf-4b34-954a-a790c4bfda0a@suse.com>
In-Reply-To: <0d2e9617-e4cf-4b34-954a-a790c4bfda0a@suse.com>

On Thu Jan 16, 2025 at 9:46 AM GMT, Jan Beulich wrote:
> On 15.01.2025 19:06, Bernhard Kaindl wrote:
> > Fix missing commas after linking adverbs such as currently, fortunately=
,
> > hence, instead, and thus, when used as linking adverbs at the beginning
> > of sentences. I saw them with LTeX; other checkers have this rule too.
>
> I'm unconvinced, and despite Stefano's R-b (Stefano, please don't feel
> offended) I'd like this to be commented on by a native speaker.

Not a native speaker, but those are "sentence adverbs" and must indeed have=
 a
comma to refer to the whole sentence they preceed. Read them aloud and you'=
ll
notice you do pause for a little while.

> It is my understanding that commas in such situations are optional.
>
> Jan

A comma may or may not accompany such words depending on their position and=
 use
in the sentence, but that doesn't mean it's optional. Some construction hav=
e
pauses and some don't (sometime meaning different things). In this case I'd=
 say
they were definitely missing. Reading that without pausing at those spots i=
s
just awkward.

My .02 anyway.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Thu Jan 16 17:52:56 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 17:52:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873679.1284679 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYU33-0007f9-Ow; Thu, 16 Jan 2025 17:52:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873679.1284679; Thu, 16 Jan 2025 17:52:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYU33-0007f0-LO; Thu, 16 Jan 2025 17:52:53 +0000
Received: by outflank-mailman (input) for mailman id 873679;
 Thu, 16 Jan 2025 17:52: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
 <SRS0=PV9y=UI=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tYU31-0007CP-Ky
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 17:52:51 +0000
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com
 [2a00:1450:4864:20::629])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b3bf4873-d432-11ef-a0e2-8be0dac302b0;
 Thu, 16 Jan 2025 18:52:50 +0100 (CET)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-aaecf50578eso271479166b.2
 for <xen-devel@lists.xenproject.org>; Thu, 16 Jan 2025 09:52:50 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab384c57034sm27787866b.34.2025.01.16.09.52.48
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 16 Jan 2025 09:52:48 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b3bf4873-d432-11ef-a0e2-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737049969; x=1737654769; 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=FuFvwoczQ0Dt1tA24xhRPUnmiSMeJ5zfD1PkZdC+rZ4=;
        b=TCfaB8BNMNubLNnPXbD6bMbfmJI/c3o/xtaHojwA3oSy3bNnaO1qwi/Z/rIyF+9Juu
         ycwe9rTGtRxJM6raqjYo9P2OHA3n93PAfpvKNvHdEX5EEIh9ohaM6LhsRB5t1ArKjFTj
         X9OMXDdgTineOjogMRw5wYwfOuKnIMJsfMI8s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737049969; x=1737654769;
        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=FuFvwoczQ0Dt1tA24xhRPUnmiSMeJ5zfD1PkZdC+rZ4=;
        b=wWcWF7QEHDwtLGNnqbPakYIp7nORGssd64HmW4nxKaZHZeYgaDN6or9CYUkGe83yEj
         zU2hbz5Uj0P+YWGYnqSjaCEqESimjFklZpVdsR3ektXOmptBksZNCggHU2krt/mJa91v
         lubdJboXjjCsUevEOmWowoGsJ5lFuBu2C0a1WRRdWN3aZsiL5lr/7XQn5JcXBYadTzGY
         cnnvjl6L/R/mZLXi+Rzqi2Gec6tVB6VrdprwwDgxpMhPfpR7vO9VjcxLAtgOjspnY/nO
         HRQyw26VQ8kl+bCSjUYNrxW66QG7slOVnZOQtZVy0xpABaUDa8B1EGqdo/iG7ygUJuGW
         LfCQ==
X-Gm-Message-State: AOJu0YxiDsnklJLQlaoHGXaNk3nMLi+jsuEFcEUvZ8iNut/GztWfk5r0
	jmSmhyFMgeB/Tf5ZSDlSSe2HEw/o/a3OAL7q59nAVmRmqehSHT9baOq//5phOTNhGbSn+NUTBA+
	6
X-Gm-Gg: ASbGncudV+qYdLiy2TE0olpWQ0kKNWnhZtJlWumlaDDfHfIV+jtEooEnkJl+x53o8yP
	jA5OWKu/9UUTYbJDpeJfYOiA/dDlbY91zt8gBBEeySxKUU6Krno+kfoqM8Bx5AHx8YdZlP4K6Ad
	jsZfLt9hdWaJzInxSEwnbsaqsldaKuaprtI5NYWIA9+fM1Q6vEIT7dKAhnLMoSSh2iHkVilCnD8
	mAkREnqhQX+MHEhQ84XBC575ZAeQ4mCu4rhFVqF5PDp5nqVmLbeQfi6nv2Dpw==
X-Google-Smtp-Source: AGHT+IHQ78fj4w35Y9kLgaBu47AToy7EGUILnKAan473qANN6ZzI//+m6f88rVqsRBAIby1r3BuuSQ==
X-Received: by 2002:a17:907:7f0a:b0:aab:da48:493e with SMTP id a640c23a62f3a-ab2ab559c29mr3048679366b.21.1737049969348;
        Thu, 16 Jan 2025 09:52:49 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: konrad.wilk@oracle.com,
	ross.lagerwall@citrix.com,
	Artem Savkov <asavkov@redhat.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PATCH 2/7] create-diff-object: add symbol relations
Date: Thu, 16 Jan 2025 18:52:09 +0100
Message-ID: <20250116175214.83742-3-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250116175214.83742-1-roger.pau@citrix.com>
References: <20250116175214.83742-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: Artem Savkov <asavkov@redhat.com>

Add a function that would detect parent/child symbol relations. So far
it only supports .cold.* symbols as children.

Signed-off-by: Artem Savkov <asavkov@redhat.com>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 common.h             |  2 ++
 create-diff-object.c | 35 +++++++++++++++++++++++++++++++++++
 2 files changed, 37 insertions(+)

diff --git a/common.h b/common.h
index 5ff9ef6ca8e9..7f3a82ffdb29 100644
--- a/common.h
+++ b/common.h
@@ -85,6 +85,8 @@ struct section {
 struct symbol {
 	struct list_head list;
 	struct symbol *twin;
+	struct symbol *parent;
+	struct symbol *child;
 	struct section *sec;
 	GElf_Sym sym;
 	char *name;
diff --git a/create-diff-object.c b/create-diff-object.c
index fed360a9aa68..b041d94d9723 100644
--- a/create-diff-object.c
+++ b/create-diff-object.c
@@ -327,6 +327,38 @@ static void kpatch_rename_mangled_functions(struct kpatch_elf *base,
 	}
 }
 
+/*
+ * During optimization gcc may move unlikely execution branches into *.cold
+ * subfunctions. kpatch_detect_child_functions detects such subfunctions and
+ * crossreferences them with their parent functions through parent/child
+ * pointers.
+ */
+static void kpatch_detect_child_functions(struct kpatch_elf *kelf)
+{
+	struct symbol *sym;
+
+	list_for_each_entry(sym, &kelf->symbols, list) {
+		char *coldstr;
+
+		coldstr = strstr(sym->name, ".cold.");
+		if (coldstr != NULL) {
+			char *pname;
+
+			pname = strndup(sym->name, coldstr - sym->name);
+			if (!pname)
+				ERROR("strndup");
+
+			sym->parent = find_symbol_by_name(&kelf->symbols, pname);
+			free(pname);
+
+			if (!sym->parent)
+				ERROR("failed to find parent function for %s", sym->name);
+
+			sym->parent->child = sym;
+		}
+	}
+}
+
 /*
  * This function detects whether the given symbol is a "special" static local
  * variable (for lack of a better term).
@@ -2329,6 +2361,9 @@ int main(int argc, char *argv[])
 	log_debug("Open patched\n");
 	kelf_patched = kpatch_elf_open(arguments.args[1]);
 
+	kpatch_detect_child_functions(kelf_base);
+	kpatch_detect_child_functions(kelf_patched);
+
 	log_debug("Compare elf headers\n");
 	kpatch_compare_elf_headers(kelf_base->elf, kelf_patched->elf);
 	log_debug("Check program headers of base\n");
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Thu Jan 16 17:52:56 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 17:52:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873681.1284692 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYU34-0007pn-Hl; Thu, 16 Jan 2025 17:52:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873681.1284692; Thu, 16 Jan 2025 17:52:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYU34-0007pI-8Z; Thu, 16 Jan 2025 17:52:54 +0000
Received: by outflank-mailman (input) for mailman id 873681;
 Thu, 16 Jan 2025 17:52:53 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=PV9y=UI=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tYU33-0007CP-JR
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 17:52:53 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b57a67f7-d432-11ef-a0e2-8be0dac302b0;
 Thu, 16 Jan 2025 18:52:53 +0100 (CET)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-aa68b513abcso243480166b.0
 for <xen-devel@lists.xenproject.org>; Thu, 16 Jan 2025 09:52:53 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab384c5c470sm27605266b.26.2025.01.16.09.52.51
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 16 Jan 2025 09:52:51 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b57a67f7-d432-11ef-a0e2-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737049972; x=1737654772; 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=lkduoX8PBg5wURJov3JoF6FhqdQ9jnRnJkykFwuVuZg=;
        b=bIroicPcLT3DNyLvc4AZ/eKYdI9emjI4M5k3XSAPUWXVECVvxQmL7aora6M8qke4ok
         RzE/bMEAfA8vpXnVCPc75FBRUuVlkRf1V1i63ZTHJc0ybnIPZ4BTszQX3DhqYZDvrSDP
         3sqnrIkS0pTBaCF4D+628nB3IhmFVBDZkB4AQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737049972; x=1737654772;
        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=lkduoX8PBg5wURJov3JoF6FhqdQ9jnRnJkykFwuVuZg=;
        b=qAk5s5bGTidyCGc8/SBLLQt5iLDFmPPWrxkNhsLCj2hekJ1WCKjLt0YwEn+YpmTBVS
         gmBNA4gJ1Wr47O9nTrlHABlDyk8rCaZ+fABDZdYRQGsuNeKvZOLoKubKe6PadRnNTu3I
         QeVcbl8yVRECWEQp5U4LbK0p4TOzYg0sCayd6CSEKdSozUolCzjiiRlCsun7W2eJ6+8C
         KUH7BVqefZZ5XqdB1GpSl+YTc2BMXZAF5v+9sa5FHpLdN49M1ihcVux3dNqUVRrdkXwW
         iYLyM4ATj8Th6X8Xv+BCy+amwgKplvdK8fiXHs227WdSdjz4UPOETFeI1usdYoJ0Ezx9
         fUbA==
X-Gm-Message-State: AOJu0YwWE7d6W2o+kHjqkakH9YEzx0lwGTw62x/ziQ+0WWk6jT+1lgxp
	MxRjvxII3HpczGeeUCDwsn5jMKyfCgwSzaEz2W8VsVa9GbuHt1p56quyougFuC/oc7DQ7u4Lo4k
	U
X-Gm-Gg: ASbGncvq+ooqL8x1emWSgj8786xfHM12s9/Hv9a8n2uR3mdG8rxAOR1DJfdRQTh/ap6
	qQciALZgcYDvcbcwthFJxrdvDB1Sm01PYKD/cydS7J6+5U7XoxKlk+9+3i50BLFThkmp5jSRt7W
	ASDSjLMr2MRGBHr67iVmn4pmAbbnaiIKmcK8mwM65nvyk3M/4bwuc0JZ3DZFo7zB/5ekn9Y3Pqi
	7d/sh6epDuaHm8Di5OeDdsycRss3XpMSb8E41LTRSm6/6OjzoWiSE9zqThtsQ==
X-Google-Smtp-Source: AGHT+IGIWKNJ4OtuhG7/i0Y2/9mANngRo5I7/u9pGjriJtCtSVzLJB4+kk7wHWPjSwVBWTH8QmM9wg==
X-Received: by 2002:a17:907:9997:b0:ab2:c0ba:519e with SMTP id a640c23a62f3a-ab2c0ba708fmr3082553166b.35.1737049972304;
        Thu, 16 Jan 2025 09:52:52 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: konrad.wilk@oracle.com,
	ross.lagerwall@citrix.com,
	Artem Savkov <asavkov@redhat.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PATCH 4/7] create-diff-object: allow changing subsections
Date: Thu, 16 Jan 2025 18:52:11 +0100
Message-ID: <20250116175214.83742-5-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250116175214.83742-1-roger.pau@citrix.com>
References: <20250116175214.83742-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: Artem Savkov <asavkov@redhat.com>

gcc8 can place functions to .text.unlikely and .text.hot subsections
during optimizations. Allow symbols to change subsections instead of
failing.

Signed-off-by: Artem Savkov <asavkov@redhat.com>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 create-diff-object.c | 29 +++++++++++++++++++++++++++--
 1 file changed, 27 insertions(+), 2 deletions(-)

diff --git a/create-diff-object.c b/create-diff-object.c
index dd5466bff6ce..3189d3e8451c 100644
--- a/create-diff-object.c
+++ b/create-diff-object.c
@@ -55,6 +55,13 @@
 #include "common.h"
 
 char *childobj;
+
+enum subsection {
+       SUBSECTION_NORMAL,
+       SUBSECTION_HOT,
+       SUBSECTION_UNLIKELY
+};
+
 enum loglevel loglevel = NORMAL;
 
 static void kpatch_compare_elf_headers(Elf *elf1, Elf *elf2)
@@ -833,6 +840,22 @@ static void kpatch_compare_sections(struct list_head *seclist)
 	}
 }
 
+static enum subsection kpatch_subsection_type(struct section *sec)
+{
+	if (!strncmp(sec->name, ".text.unlikely.", 15))
+		return SUBSECTION_UNLIKELY;
+
+	if (!strncmp(sec->name, ".text.hot.", 10))
+		return SUBSECTION_HOT;
+
+	return SUBSECTION_NORMAL;
+}
+
+static int kpatch_subsection_changed(struct section *sec1, struct section *sec2)
+{
+	return kpatch_subsection_type(sec1) != kpatch_subsection_type(sec2);
+}
+
 static void kpatch_compare_correlated_symbol(struct symbol *sym)
 {
 	struct symbol *sym1 = sym, *sym2 = sym->twin;
@@ -846,10 +869,12 @@ static void kpatch_compare_correlated_symbol(struct symbol *sym)
 	/*
 	 * If two symbols are correlated but their sections are not, then the
 	 * symbol has changed sections.  This is only allowed if the symbol is
-	 * moving out of an ignored section.
+	 * moving out of an ignored section, or moving between normal/hot/unlikely
+	 * subsections.
 	 */
 	if (sym1->sec && sym2->sec && sym1->sec->twin != sym2->sec) {
-		if (sym2->sec->twin && sym2->sec->twin->ignore)
+		if ((sym2->sec->twin && sym2->sec->twin->ignore) ||
+		    kpatch_subsection_changed(sym1->sec, sym2->sec))
 			sym->status = CHANGED;
 		else
 			DIFF_FATAL("symbol changed sections: %s, %s, %s, %s", sym1->name, sym2->name, sym1->sec->name, sym2->sec->name);
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Thu Jan 16 17:52:56 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 17:52:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873677.1284660 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYU31-0007CM-Ay; Thu, 16 Jan 2025 17:52:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873677.1284660; Thu, 16 Jan 2025 17:52:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYU31-0007CF-8N; Thu, 16 Jan 2025 17:52:51 +0000
Received: by outflank-mailman (input) for mailman id 873677;
 Thu, 16 Jan 2025 17:52:50 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=PV9y=UI=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tYU30-0007C4-56
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 17:52:50 +0000
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com
 [2a00:1450:4864:20::533])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b21fd5fd-d432-11ef-99a4-01e77a169b0f;
 Thu, 16 Jan 2025 18:52:47 +0100 (CET)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-5d3f65844deso1973465a12.0
 for <xen-devel@lists.xenproject.org>; Thu, 16 Jan 2025 09:52:47 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab384f22c6asm26516166b.106.2025.01.16.09.52.46
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 16 Jan 2025 09:52:46 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b21fd5fd-d432-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737049967; x=1737654767; 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=jwFdCUm+DIThbUpHUfjQvJ17doF3H9OpBArUoynYNPs=;
        b=cpv4sa/d48KpsYIHWolUD4P5kY4r2yNFTWDP6Hz6lh2Z6OI1zZSpm0pqvJCLyl6uYM
         u+a4Uq92UpyHg2lQGhz+MlEpfKK3En/HTuqMgv3ALhzdES/a2WFhZu/fU4xrHOPJb3FO
         rnXtIetND+18XMwj6++Q8oGlixg3n6C48yW80=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737049967; x=1737654767;
        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=jwFdCUm+DIThbUpHUfjQvJ17doF3H9OpBArUoynYNPs=;
        b=pH9y+Jv0cqtn1d/TlbAISMgMzFdj8mZOplWLox0mzKzqcbnfUY+zjyn12R6XRD0NKw
         uaGE7b1ZK6cfiBc6TlWEQbj4nj3LHUgyxyR35eFUYaW6KfyndXttzzFIgfnMf6KhIAmQ
         Pk2RNWisr/jeoUsC9O0m3HRRL7ffIYGgKF4ivD+AIyCy4ZFIInoUIlCz7XzLfh34WCqu
         V6MLqfEK04hglarQm1YcHxYE9PJ5Yv+uHETfvUESVNU0HZ6CLgTTlnGkMaP50lyjGi3J
         J6D6Vc4HJU1BAADOYT945QvQE6tm4bqwIH35DVuCJz8vYMvJwPq5tCWVMXNfboGhxf9M
         KahQ==
X-Gm-Message-State: AOJu0YxARMYHUGNI2lN/jWjcZEULuEBxOqewkEl4o4WRBsRhOJ9/79Vk
	80JnWg03oqZ5lLHoBlUkwb3oOPaXpsMcMnfD4yFMVFaMZ7dY+2Z1/IraFeHVJf6R5cIBCKF/yqq
	0
X-Gm-Gg: ASbGncsoRLBo5CnYwmbrnebaYICUwNp3yycbZa3BmRLyU3Q22P3JJ/vkMNIUf3lvh7u
	vsp3dy4XQ+jVejIM4tBOfPl9TPM/mvLLr6KhB6uKSMQNMWVahx3SprSPoJIzEyKxtpyEf7PBSp4
	cLuddb7oZ4ZkDABcjFBeVgKCzohtfTtazaIev4J/64B4LGJcShexPev1uCDPyB+D+l1jjFsHgRA
	iBy5ZWsy+PM07WKnkHhS6p2KLj/XMG7FcZrvTBIKSYxmyQTdGfLn38MQfkmfw==
X-Google-Smtp-Source: AGHT+IGdPocoRdZ5HMXzl72k9uRHG5ZfNuKI52jDRlWS/PtTDuu3aX+jhUfP+RwTTNWdZQguGyPE8g==
X-Received: by 2002:a17:907:368c:b0:aa6:9624:78fd with SMTP id a640c23a62f3a-ab2abc78a71mr3378635366b.48.1737049966657;
        Thu, 16 Jan 2025 09:52:46 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: konrad.wilk@oracle.com,
	ross.lagerwall@citrix.com,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [PATCH 0/7] livepatch-build-tools: fixes for handling .cold and .hot sections
Date: Thu, 16 Jan 2025 18:52:07 +0100
Message-ID: <20250116175214.83742-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Hello,

Fixes picked from kpatch to deal with .cold and .hot sub-functions
sections generated by gcc.

Thanks, Roger.

Artem Savkov (7):
  create-diff-object: ignore .cold.* suffixes in is_bundleable()
  create-diff-object: add symbol relations
  create-diff-object: propagate child symbol changes
  create-diff-object: allow changing subsections
  create-diff-object: add .text.hot to the list of bundleable functions
  create-diff-object: propagate ignore.functions to children
  create-build-diff: support for .cold functions with no id suffix

 common.c             |  9 ++++-
 common.h             |  2 ++
 create-diff-object.c | 78 +++++++++++++++++++++++++++++++++++++++++---
 3 files changed, 84 insertions(+), 5 deletions(-)

-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Thu Jan 16 17:52:56 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 17:52:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873678.1284669 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYU32-0007Qj-H0; Thu, 16 Jan 2025 17:52:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873678.1284669; Thu, 16 Jan 2025 17:52:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYU32-0007Qc-EK; Thu, 16 Jan 2025 17:52:52 +0000
Received: by outflank-mailman (input) for mailman id 873678;
 Thu, 16 Jan 2025 17:52:50 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=PV9y=UI=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tYU30-0007C4-Q9
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 17:52:50 +0000
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com
 [2a00:1450:4864:20::52f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b306d240-d432-11ef-99a4-01e77a169b0f;
 Thu, 16 Jan 2025 18:52:49 +0100 (CET)
Received: by mail-ed1-x52f.google.com with SMTP id
 4fb4d7f45d1cf-5d3d143376dso1878477a12.3
 for <xen-devel@lists.xenproject.org>; Thu, 16 Jan 2025 09:52:49 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5db73683de7sm243751a12.42.2025.01.16.09.52.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 16 Jan 2025 09:52:47 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b306d240-d432-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737049968; x=1737654768; 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=U/uapuiccaTxH7EAPivIv8o3YxFQp/soQ4UJlMTsG9c=;
        b=O/2JNqElh5xNd+RStDT21xcxV487992pG/yzLw+1TeuPYTfB+1uX+uR0ErhdlfzBpI
         pL80Vn+Q2n7BbBmySPqcC4+0gUfxd0tLtkEqc7GIa+UylBZWqyGaYeyoihW1XzF0bqeE
         0R4GWHrPSOoVZBO0RVd1fsRg59z9zDnx7SY+g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737049968; x=1737654768;
        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=U/uapuiccaTxH7EAPivIv8o3YxFQp/soQ4UJlMTsG9c=;
        b=RolzNYnCqX3nHvY/S31qMbbpTwfYYzwmPTTBz9ZSLOtDpapjGJZz5InSIJaLN91aw4
         +B23xvTQ4CA9JKoqnrFGR8KoWpMtKwRATU0ZSxTJjRd0KJfNvpxFMnHNfL0HbdNiK+0r
         rjXHAmUdudj6YrzaHqyTSMsGSjAO9BvsFqvpFe6EuvNfgqBp49ZJ65VlbqKpKeT8SUGx
         SVtcnaYullke+ZsIAcKJLh5udTnc/yKOSS01a6UJ3LJm5vYaw7R89Zf7Nknp28A/8k6X
         Yv1dL1WYRNmiEz4LMH+RhXbbdsh2ly4czs+kuTzf7lE6w0MyZOYqNiC9Xmec9yOsFBLv
         mz5w==
X-Gm-Message-State: AOJu0YwFCZ0hVS55RLHMtjwmXMn7mYq66kUqR110eal0x2z68NssQPch
	5UMnxHUzthnteDKeHrShRgGsOHIbm8kgXxlR60NiIs/1nhqrricR07bTlW8xvw//YzevIhrb3eE
	u
X-Gm-Gg: ASbGncsG399MMxdUpraho/Zxjk+uy/FbpuJA7TDI7lLd5O2GbyBhbwIIPvM0fbsSSp1
	P1wEEhuZlV7LFHtD2Or7Iti5XMerKt51Q3DPWSr27GVxVvWcNaLJ9V9eGA5j7ZQoJBocaqEUYo4
	8Klyax8rkqQAviVE89KCgUaSPFKJYUCgH+4NZWpTF+aZ1ofxUlvv9N9jOYRt8kpdkKjHKyTUxKQ
	wSRV2uNF+g8fVEEIN3xkxaKZNI+1OJ2hEEtf4YD/XLzKxD1/tnun+i3kw4Tfw==
X-Google-Smtp-Source: AGHT+IGeIm8rBfa4224KwZC18X4+hgNPmw3wjFS1KC8gS4AtREa/j5SkB6WcvVr/HvK0A4HLRZN3Kg==
X-Received: by 2002:a05:6402:40d5:b0:5d9:f21e:ff5 with SMTP id 4fb4d7f45d1cf-5d9f21e18a0mr13175025a12.16.1737049968140;
        Thu, 16 Jan 2025 09:52:48 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: konrad.wilk@oracle.com,
	ross.lagerwall@citrix.com,
	Artem Savkov <asavkov@redhat.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PATCH 1/7] create-diff-object: ignore .cold.* suffixes in is_bundleable()
Date: Thu, 16 Jan 2025 18:52:08 +0100
Message-ID: <20250116175214.83742-2-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250116175214.83742-1-roger.pau@citrix.com>
References: <20250116175214.83742-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: Artem Savkov <asavkov@redhat.com>

While building a gcc-consprop patch from integration tests gcc8 would place a
__timekeeping_inject_sleeptime.constprop.18.cold.27 symbol into
.text.unlikely.__timekeeping_inject_sleeptime.constprop.18 section. Because
section name doesn't have the '.cold.27' suffix this symbol fails
is_bundleable() check while still being bundleable and later exits early in
kpatch_rename_mangled_functions() without renaming the corresponding patched
function. All of this results in a create-diff-object errror:

  ERROR: timekeeping.o: symbol changed sections: __timekeeping_inject_sleeptime.constprop.18.cold.27
  /home/asavkov/dev/kpatch/kpatch-build/create-diff-object: unreconcilable difference

Fix by ignoring .cold.* name suffix in is_bundleable() for.text.unlikely
sections.

Signed-off-by: Artem Savkov <asavkov@redhat.com>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 common.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/common.c b/common.c
index 68a71f75ac7b..84ca14d3e397 100644
--- a/common.c
+++ b/common.c
@@ -126,7 +126,9 @@ static int is_bundleable(struct symbol *sym)
 
 	if (sym->type == STT_FUNC &&
 	    !strncmp(sym->sec->name, ".text.unlikely.",15) &&
-	    !strcmp(sym->sec->name + 15, sym->name))
+	    (!strcmp(sym->sec->name + 15, sym->name) ||
+			 (strstr(sym->name, ".cold.") &&
+			  !strncmp(sym->sec->name + 15, sym->name, strlen(sym->sec->name) - 15))))
 		return 1;
 
 	if (sym->type == STT_OBJECT &&
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Thu Jan 16 17:52:56 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 17:52:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873680.1284686 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYU34-0007iN-3q; Thu, 16 Jan 2025 17:52:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873680.1284686; Thu, 16 Jan 2025 17:52:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYU33-0007hS-Tv; Thu, 16 Jan 2025 17:52:53 +0000
Received: by outflank-mailman (input) for mailman id 873680;
 Thu, 16 Jan 2025 17:52: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
 <SRS0=PV9y=UI=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tYU32-0007CP-Gg
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 17:52:52 +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 b4d73ef0-d432-11ef-a0e2-8be0dac302b0;
 Thu, 16 Jan 2025 18:52:52 +0100 (CET)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-5d932eac638so2527302a12.1
 for <xen-devel@lists.xenproject.org>; Thu, 16 Jan 2025 09:52:52 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5db73edbc18sm227073a12.69.2025.01.16.09.52.49
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 16 Jan 2025 09:52:50 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b4d73ef0-d432-11ef-a0e2-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737049971; x=1737654771; 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=PStf4fVV3eap1o0m+cwA72iRcnwg9eiUKsl3FHMYlFU=;
        b=Tqh209ID0kkvPNRWt5u+zTzLFI0cjqx8oJ/QQRr7BbTuvi4SSHJHHMQMAEE0NmvR0U
         SonJZg7ftu5VqrkSfWreDR4U3VOQrpb2MOv8RFtZ9D5MNNH5kn9R4BzVb92gDLdhUlzo
         hL1XEY5+vc4ztc86PX2yVjsOCKsDOvn2B+Ve8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737049971; x=1737654771;
        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=PStf4fVV3eap1o0m+cwA72iRcnwg9eiUKsl3FHMYlFU=;
        b=E5VZGcAkkMcd3GSRZwAjC9UbkzsETKVxQg4MzNVGHZrPAiIUDIV7iLmHUZxPwTPGC1
         Bx4QL2NID7JJAGDmTpmMQuidt7rCYgPLMmq601tnr28Bj/FUg6kE3t/j2hsIPexGPcIF
         cvUNvvC7p45dPn+grbIBIZG7r014zuVHFqgTu1YTvI91gvsvUzBFD+7JnzcPpFy1zsit
         DueT6kU5dgRIO0Fc4WL5FiOMaJH2oc7k3xdAaAoeXAGPduricin5Ko4yOYnq5Jlo6Zz3
         cZjiCxHhWJq90YFr7j+pkKHE9pVtT0uxfMf45ikEyKxd+DzUTHXWxgxTlt0OHiS3lxFj
         PGYg==
X-Gm-Message-State: AOJu0YxPOL3juHPUR5mrsIF2evZHignfrSPcuuIqWNjw5ITxEt9KKsZ5
	iz/YrdlKfgWCer486ZqAjJojzG3/2IPPc/NtUwZyXe2ZfHU8GxuYCt7FmFBDsjeTCXQ7e9kA2Gj
	k
X-Gm-Gg: ASbGncsB9pcxq/0i3YC2rzb4Ow0vsOS3VwhJ38RHGB0NSHXTDQuRPkg4S/ItvHH2bTb
	fJhKhbTqTU027FmuzcD3GGMIrATKfuHd9x6dDjDYAdUv7ZB1AjoMHtfCbjDKdi64OGSI24xjk0g
	aarsc6+ynzZy2gs5dVZWTfsH6qLsWIC/vH5/07dKZh4BBjtB0+vhsDIgxLxIFVLdcMICh9UPdI+
	+QX+99SpdkQiMsx6b4Vrz0JZ7VK1BLUyXAZq0qjRFVeg7D2pYP8qdD1MtqI4g==
X-Google-Smtp-Source: AGHT+IGM5B89/sW4jjyLnVgy25mYg6tio8LEb3BuycnqnUnpAsENjVhhpxBjpArg3oaD7QOU8tBTaA==
X-Received: by 2002:a05:6402:4304:b0:5d0:e570:508d with SMTP id 4fb4d7f45d1cf-5d972e1787bmr34413603a12.17.1737049970833;
        Thu, 16 Jan 2025 09:52:50 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: konrad.wilk@oracle.com,
	ross.lagerwall@citrix.com,
	Artem Savkov <asavkov@redhat.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PATCH 3/7] create-diff-object: propagate child symbol changes
Date: Thu, 16 Jan 2025 18:52:10 +0100
Message-ID: <20250116175214.83742-4-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250116175214.83742-1-roger.pau@citrix.com>
References: <20250116175214.83742-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: Artem Savkov <asavkov@redhat.com>

Propagate child symbol changes to it's parent.

Signed-off-by: Artem Savkov <asavkov@redhat.com>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 create-diff-object.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/create-diff-object.c b/create-diff-object.c
index b041d94d9723..dd5466bff6ce 100644
--- a/create-diff-object.c
+++ b/create-diff-object.c
@@ -821,8 +821,14 @@ static void kpatch_compare_sections(struct list_head *seclist)
 			if (sec->base->sym && sec->base->sym->status != CHANGED)
 				sec->base->sym->status = sec->status;
 		} else {
-			if (sec->sym && sec->sym->status != CHANGED)
-				sec->sym->status = sec->status;
+			struct symbol *sym = sec->sym;
+
+			if (sym && sym->status != CHANGED)
+				sym->status = sec->status;
+
+			if (sym && sym->child && sym->status == SAME &&
+			    sym->child->sec->status == CHANGED)
+				sym->status = CHANGED;
 		}
 	}
 }
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Thu Jan 16 17:52:56 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 17:52:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873682.1284710 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYU36-0008QS-P2; Thu, 16 Jan 2025 17:52:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873682.1284710; Thu, 16 Jan 2025 17:52:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYU36-0008QJ-Lu; Thu, 16 Jan 2025 17:52:56 +0000
Received: by outflank-mailman (input) for mailman id 873682;
 Thu, 16 Jan 2025 17:52:55 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=PV9y=UI=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tYU35-0007CP-KG
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 17:52:55 +0000
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com
 [2a00:1450:4864:20::52d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b6ab3639-d432-11ef-a0e2-8be0dac302b0;
 Thu, 16 Jan 2025 18:52:55 +0100 (CET)
Received: by mail-ed1-x52d.google.com with SMTP id
 4fb4d7f45d1cf-5d9837f201aso4236583a12.0
 for <xen-devel@lists.xenproject.org>; Thu, 16 Jan 2025 09:52:55 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab384d2d69fsm27215966b.79.2025.01.16.09.52.52
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 16 Jan 2025 09:52:53 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b6ab3639-d432-11ef-a0e2-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737049974; x=1737654774; 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=GKB1yFs9c8qB7Ii2QUVBsCJgsFYCAo4Ha6+WZCUSBfI=;
        b=t6+0mhNL8ZhKyFpbFGHukojR9IGHOWUYKFDxhLCJhzpYt7aFSOJe5CkzjxSwdPXiI+
         aJFUm+EcQZMk9Use+Wgbj6LaSxsTXqwIavtJrYqFfPx+nieWj3WgTChzFSuzHKVogalC
         UCrEz2Z+6QcMc2ez88XvqRPqAhhJkhsMyqshc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737049974; x=1737654774;
        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=GKB1yFs9c8qB7Ii2QUVBsCJgsFYCAo4Ha6+WZCUSBfI=;
        b=ArxhJ1rppZqJYCs2Er8EDSIdDE3GengFkAU1/Qe6dx95uUFUvdqAgEs/oTyTZLuNJp
         GfbrtJ1fUg/Wa0xH9ZK8wDCYOOb9dKQZve6jatdl0sWWkzY7eyyAB91GZQ0X2N/ieuQ+
         d1bgaFBgvO6B4OeUjYCDgNU5yvrWnlgulXDVUmBBwVcZUgvU5PDyMpqUpQdrSWLwGlEB
         r1ylMRlOff82HRKKErPumNWhGOrowyxqa9vVIX7nB1QobwFpJk8efBIU01W5500fNu9q
         J9ZmRs8D1T4Ytx+8IoaonzjBlWDw4yTFgZwASQwaCTAlbllXilFVhjQlzYyu2/tjuKRO
         5OEA==
X-Gm-Message-State: AOJu0YzRV/p/bJQCIR/XdsIF9ALbUTMzo6CWUQlrpF5GTeECbAkGBD0W
	Wvego9liphsZg9ijKWH/ZHgwtLl3TP6imb+Kl2/D9UkxlbgjS6T/JdYRRNN848uB4KuCfSUbEzz
	j
X-Gm-Gg: ASbGnctW/52qFIo3oJk/prF33zQQjPtd50O4AQPl2L/Df3oCFpq4/DHDRNS9ifOw+Mh
	odJ9uO6Vb3c0RORprpRAUYjpu0FDCc4WpBpGjJJ5wPNFeljCinlkZ4NkPTBEFWpeT38VLGHjfZ+
	JR8Q1OxlRAvAXaEBIpeWXdDVjOHPFZP6epVI5sbi3/lZbAVfcEyB//U4DgugWA5e2+vxDHFmjqm
	pesEFAbcqv/8RcmKZlAU/tfAF90I/dDj5efyVASJjwFh62VdIHU8Md2/AJ5tw==
X-Google-Smtp-Source: AGHT+IGH4OzQgxrsJ/IwnTnRF18Pado6jmWcA1RPVb0SjpZkArfJzXDlTxxDnOmwH4JgvOnn9o1fdg==
X-Received: by 2002:a17:907:9d18:b0:ab3:85eb:377c with SMTP id a640c23a62f3a-ab385eb4029mr59295266b.17.1737049973869;
        Thu, 16 Jan 2025 09:52:53 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: konrad.wilk@oracle.com,
	ross.lagerwall@citrix.com,
	Artem Savkov <asavkov@redhat.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PATCH 5/7] create-diff-object: add .text.hot to the list of bundleable functions
Date: Thu, 16 Jan 2025 18:52:12 +0100
Message-ID: <20250116175214.83742-6-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250116175214.83742-1-roger.pau@citrix.com>
References: <20250116175214.83742-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: Artem Savkov <asavkov@redhat.com>

According to gcc8's man pages gcc can put functions into .text.unlikely
or .text.hot subfunctions during optimization. Add ".text.hot" to the
list of bundleable functions in is_bundleable().

Signed-off-by: Artem Savkov <asavkov@redhat.com>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 common.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/common.c b/common.c
index 84ca14d3e397..b46fcf5cb6ca 100644
--- a/common.c
+++ b/common.c
@@ -131,6 +131,11 @@ static int is_bundleable(struct symbol *sym)
 			  !strncmp(sym->sec->name + 15, sym->name, strlen(sym->sec->name) - 15))))
 		return 1;
 
+	if (sym->type == STT_FUNC &&
+	    !strncmp(sym->sec->name, ".text.hot.",10) &&
+	    !strcmp(sym->sec->name + 10, sym->name))
+		return 1;
+
 	if (sym->type == STT_OBJECT &&
 	   !strncmp(sym->sec->name, ".data.",6) &&
 	   !strcmp(sym->sec->name + 6, sym->name))
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Thu Jan 16 17:52:58 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 17:52:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873683.1284720 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYU38-0000G4-6j; Thu, 16 Jan 2025 17:52:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873683.1284720; Thu, 16 Jan 2025 17:52:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYU38-0000Et-0x; Thu, 16 Jan 2025 17:52:58 +0000
Received: by outflank-mailman (input) for mailman id 873683;
 Thu, 16 Jan 2025 17:52: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
 <SRS0=PV9y=UI=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tYU36-0007CP-KW
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 17:52:56 +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 b74e02b7-d432-11ef-a0e2-8be0dac302b0;
 Thu, 16 Jan 2025 18:52:56 +0100 (CET)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-5d3cf094768so2189107a12.0
 for <xen-devel@lists.xenproject.org>; Thu, 16 Jan 2025 09:52:56 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab384f224e0sm26235766b.112.2025.01.16.09.52.54
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 16 Jan 2025 09:52:54 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b74e02b7-d432-11ef-a0e2-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737049975; x=1737654775; 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=sXVxPmSkdh6kTkitg7Sn1/R1oEUNu+Kk247t0METCbc=;
        b=Uc7Ti+F3lmBlCvE7EC2B6zQyMxGzLjfvlab3jVvOE1frB7JUn1kWhC6PxGkFDUKHDg
         0nbLYwRjEnJdtw12z2glQLYVy5vTVfvK+3g/WIfCGd6Ab87d7IYnz9RL2OBKBPVoCd7m
         H4xie7EIh7MnrVoQ03oLEJsb6TeFly8hoO57M=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737049975; x=1737654775;
        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=sXVxPmSkdh6kTkitg7Sn1/R1oEUNu+Kk247t0METCbc=;
        b=Ndp855aArMaV0u/S0kdQntWR6mkDDoYGnhGWcBiUp8EgbZr5TB4ncYx5Je29Cxx9+B
         UGoM6ybifsKcO/q09FpG0XiIyQE+bGRPJHVhnVkV9qcYXxPJUpXPpNNGYcWH2PusYPGJ
         NqHVGJYv1d6O6QBtaQCVuFB9Vg5hGYcrYy8C30vO4Ub/xqF4WZoxNkH2ru18il8W+vhE
         5WmXkyFrPSfrOwEsQEu6QT0b4N4fsz2LfixQtyYcI/Ca00myvRpgs8lfrJp6gU+oApUZ
         yVX7xyi3EoLx7WDi4huNP6RyfQp5bzBv4mVPi83OwTidN49sdruA+0G1tcUwGMSnYcLG
         pF4Q==
X-Gm-Message-State: AOJu0Yz9EbwjAFcq1h7L/50/AQ8n5ZKD5H8DqM+8sHnu6BbzH1Rt1CSx
	Lk0J6JxCIlIPsBpD8qZ+EEk3L4pT4TQvaeEAkh2diLITHypiX7tGZky8yjELkWVGtCFmxbt6jXe
	O
X-Gm-Gg: ASbGnctyN06UcnGqHK8Oh0sMTPBZxbmsCOspNTDlcSGZheJUhnzDkMABGFISnazOc2v
	vP6ezJnXd99nL1AbFhGO/2JUR+SQIOBuc6Am4qkeJwa/asN+VdN25nkq8G9GvCUJyfaWMw5De1g
	0/ELNidHXxrBio027NzWXwh5W5FvtuItng4nq+cQ/kxZSYQgOzDswrgp5Ucz+TyUTjgGBkjRe8B
	VG56YnVifMW2cmIu7wzpywflinhYvSaqNJ0/1ANMIzC/Wtbpv/Ch0N8gOVRAw==
X-Google-Smtp-Source: AGHT+IFdZIe4URc/r5aMLDRcUwmFjsTbWtOQeBFa9lkuRgU01Wen7f7gO9nWpmnH3qTK+bjccegIkA==
X-Received: by 2002:a17:907:72d0:b0:aa6:5eae:7ed8 with SMTP id a640c23a62f3a-ab2ab66cea6mr3122115866b.6.1737049975319;
        Thu, 16 Jan 2025 09:52:55 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: konrad.wilk@oracle.com,
	ross.lagerwall@citrix.com,
	Artem Savkov <asavkov@redhat.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PATCH 6/7] create-diff-object: propagate ignore.functions to children
Date: Thu, 16 Jan 2025 18:52:13 +0100
Message-ID: <20250116175214.83742-7-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250116175214.83742-1-roger.pau@citrix.com>
References: <20250116175214.83742-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: Artem Savkov <asavkov@redhat.com>

Add child symbols to .kpatch.ignore.functions in case their parents are
added to the list.

Signed-off-by: Artem Savkov <asavkov@redhat.com>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 create-diff-object.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/create-diff-object.c b/create-diff-object.c
index 3189d3e8451c..6060a73555ed 100644
--- a/create-diff-object.c
+++ b/create-diff-object.c
@@ -936,6 +936,10 @@ static void kpatch_mark_ignored_functions_same(struct kpatch_elf *kelf)
 			log_normal("NOTICE: no change detected in function %s, unnecessary KPATCH_IGNORE_FUNCTION()?\n", rela->sym->name);
 		rela->sym->status = SAME;
 		rela->sym->sec->status = SAME;
+
+		if (rela->sym->child)
+			rela->sym->child->status = SAME;
+
 		if (rela->sym->sec->secsym)
 			rela->sym->sec->secsym->status = SAME;
 		if (rela->sym->sec->rela)
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Thu Jan 16 17:52:59 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 17:52:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873685.1284730 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYU39-0000YG-Fj; Thu, 16 Jan 2025 17:52:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873685.1284730; Thu, 16 Jan 2025 17:52:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYU39-0000XG-CA; Thu, 16 Jan 2025 17:52:59 +0000
Received: by outflank-mailman (input) for mailman id 873685;
 Thu, 16 Jan 2025 17:52: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
 <SRS0=PV9y=UI=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tYU37-0007CP-Uj
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 17:52:57 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b812c9cb-d432-11ef-a0e2-8be0dac302b0;
 Thu, 16 Jan 2025 18:52:57 +0100 (CET)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-5d9f06f8cf2so2369387a12.3
 for <xen-devel@lists.xenproject.org>; Thu, 16 Jan 2025 09:52:57 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5db73684c70sm242918a12.47.2025.01.16.09.52.55
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 16 Jan 2025 09:52:56 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b812c9cb-d432-11ef-a0e2-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737049976; x=1737654776; 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=pdKNm+zFNAAty/krwKMMryYSZX6eNIKljOU3/XkBfjk=;
        b=TrP4+fX4xWedESq+GgjV0EGPvvFyXVfxL6/8PBb6isMet6d4NFl814iulAIbSB/MHQ
         wtpjeKTq5IhOZuOeQ+/LYdudWBnaHq8YtMEKqXB9FrXgFRZEp426thxRD67/MwDRsrkj
         iuoju2xlwQADRgljQduiHBjcudljLHgvW+5kI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737049976; x=1737654776;
        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=pdKNm+zFNAAty/krwKMMryYSZX6eNIKljOU3/XkBfjk=;
        b=CPYiibXyvu7qHt21RClF5XL7WROHoRVZc1OPlxH6TMUBX4ovzvTkzqSbhFij6q+vT6
         Fm02yWsVNqoRwqxguGzJdyxfSXOx4jeua69a7Az6lJtimiXOTrNKRbx0wKVED1uyhhnk
         FiFY35sujMcGA1+qdE/NBEoA7B0/+nMwmalIo3sp+gjB4dEMg1T9Bsfxu+NOYgC6ATtB
         IGzRQET1Kbkemw4quKwvKObumNCWNUZ5IXfWedXE6uxS2nfc2G/c85FtiZt3k8OcQrl2
         QH/pnSKGN/bi2Hf5+zKmTgewRrC1EmEEjfTcMBbsASzEyJ40uHFFV1hd4GUWWlyic6jb
         M7sg==
X-Gm-Message-State: AOJu0YxjYyt0yXiXO0l7VcVU/YrqUMxFtmiwC2quyYrvTUzfvH4pOOQ9
	BoFBHl03nNjsodiLksLbr0FU19XYr853A+o2BA+IS0CxCpT6g7U4kLoui/71NfL3T9nhpsVkKca
	e
X-Gm-Gg: ASbGncv+KmEl5hjOHRbBG9YV1gBJq86mjknt7MWvK+otbtPpNrhUxwOdC8V5g5LoY2P
	6tRlUOMlgN1+qXTgTL7WYvPBlJXr+ENJlHn1JRW/PxMeM8Gz0q8IAS5J/k02ETO04UYXXMYOoUn
	58k6zVkVcs6vYF+leiS5cIciRkaN8hqyL/lrPiiqRAbIRkk53umNYRH07+D6gk1XnSmrJjeLMKo
	CZ09vkA+TbF7CZ/42t2BV6Lw8EdFx/t9ONu9Ncb4iFTY+6N8PBK398JOzaYxA==
X-Google-Smtp-Source: AGHT+IE5XnhgEzjPcuMfl//ipOH+hpNHepD0cjDK0+Mb4WVVe19cwgfC5+H5ddmcqSBBK+MRP1f+hA==
X-Received: by 2002:a05:6402:3217:b0:5cf:bcaf:98ec with SMTP id 4fb4d7f45d1cf-5d972e48686mr30530902a12.26.1737049976608;
        Thu, 16 Jan 2025 09:52:56 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: konrad.wilk@oracle.com,
	ross.lagerwall@citrix.com,
	Artem Savkov <asavkov@redhat.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PATCH 7/7] create-build-diff: support for .cold functions with no id suffix
Date: Thu, 16 Jan 2025 18:52:14 +0100
Message-ID: <20250116175214.83742-8-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250116175214.83742-1-roger.pau@citrix.com>
References: <20250116175214.83742-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: Artem Savkov <asavkov@redhat.com>

create-build-diff expects .cold functions to be suffixed by an id, which
is not always the case. Drop the trailing '.' when searching for cold
functions.

Fixes: #1160

Signed-off-by: Artem Savkov <asavkov@redhat.com>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 common.c             | 2 +-
 create-diff-object.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/common.c b/common.c
index b46fcf5cb6ca..67b9fcdb0ada 100644
--- a/common.c
+++ b/common.c
@@ -127,7 +127,7 @@ static int is_bundleable(struct symbol *sym)
 	if (sym->type == STT_FUNC &&
 	    !strncmp(sym->sec->name, ".text.unlikely.",15) &&
 	    (!strcmp(sym->sec->name + 15, sym->name) ||
-			 (strstr(sym->name, ".cold.") &&
+			 (strstr(sym->name, ".cold") &&
 			  !strncmp(sym->sec->name + 15, sym->name, strlen(sym->sec->name) - 15))))
 		return 1;
 
diff --git a/create-diff-object.c b/create-diff-object.c
index 6060a73555ed..19590fc0fce1 100644
--- a/create-diff-object.c
+++ b/create-diff-object.c
@@ -347,7 +347,7 @@ static void kpatch_detect_child_functions(struct kpatch_elf *kelf)
 	list_for_each_entry(sym, &kelf->symbols, list) {
 		char *coldstr;
 
-		coldstr = strstr(sym->name, ".cold.");
+		coldstr = strstr(sym->name, ".cold");
 		if (coldstr != NULL) {
 			char *pname;
 
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Thu Jan 16 20:42:34 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 20:42:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873765.1284740 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYWh1-0002Nw-Qb; Thu, 16 Jan 2025 20:42:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873765.1284740; Thu, 16 Jan 2025 20:42:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYWh1-0002Np-Ns; Thu, 16 Jan 2025 20:42:19 +0000
Received: by outflank-mailman (input) for mailman id 873765;
 Thu, 16 Jan 2025 20:42: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
 <SRS0=mFzr=UI=gmail.com=milandjokic1995@srs-se1.protection.inumbo.net>)
 id 1tYWh0-0002Nj-Fq
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 20:42:18 +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 5f925972-d44a-11ef-a0e2-8be0dac302b0;
 Thu, 16 Jan 2025 21:42:17 +0100 (CET)
Received: by mail-qv1-xf32.google.com with SMTP id
 6a1803df08f44-6d900c27af7so14979986d6.2
 for <xen-devel@lists.xenproject.org>; Thu, 16 Jan 2025 12:42:17 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5f925972-d44a-11ef-a0e2-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1737060136; x=1737664936; 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=AJQkn8xBOrqxhMrTvXO5m4xHY+rpEt1QvLDpaLCQ2xA=;
        b=YaMLUcviPxqcYaT7Dr/2MTujR06Wvg6zaU01V7is+4mAujWUrhEZkXB+J8QZHscNqB
         uhAH2bCXDfyRRMd52TkammOXg1cPLWF370iSqQU4VO64bNhokGhQYO8qdayjDV+GG+1k
         O5YU9xuAYTvB05HVoWFckEHAuOC8QNyRHS2fiS4Bfefey7h0TXmKVzuJS7dpMzU/x5ts
         IZtTfke/Upb8J/xSTxdLae566ywl2v327+eLswM1dJsWOHGokG7KWy68Z3mWfLv6OmnE
         waGGAH6eFyLg7smK53Sa/k50WcwddGLFmvOqfVa8wu4/1gTQgwJiE9D+LDrZoE0xjj1W
         mWcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737060136; x=1737664936;
        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=AJQkn8xBOrqxhMrTvXO5m4xHY+rpEt1QvLDpaLCQ2xA=;
        b=lGrResSIQ9bLVHw9nukwZlfIqp02aGuukMEjN5TeIZMZiiPEInNcmMLCpP2+o+BHcR
         c+58v1FV4O7TaVh8CN0N5RxIfc8bv5lHOa52JmH3B0+dQMiamPbpgBexjmivYyJJleUt
         OACusKLpuHNyF338CnsQqgNArduQ9SnpQrN2lTrdFBxSl1+jiFl8oEeauVlOl8EeSxZI
         QREpDtYTarT+ZlCYdmK0E3wsd9O9fLQzdlCBrw/aEaFP/JA5xBZuyxYVfKyt5QiZZcpy
         KxTHJZKnvH9XNnOe+fg5xE4kqW5U5B+1gHKNRi9padqvcJNRZZANDv5nWrA3gHx0kHKS
         xJ/w==
X-Forwarded-Encrypted: i=1; AJvYcCV3T5UScYw3BASOgWlNqrVGlftVAMoWqDKyg4QE6hVoj/PyDiiWl8eh/fjRarZsP6rwylNcDViCqb4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwlW0R2diaF3HP5YI0TMx+N6wz7wjTjrVqlP4+wQFE8/2xGPCp5
	RoD+HHsMfXb+Og0RQrFtmUNq+7klyPG6ugnRBGMokfHRZ60ancKajODkKadYpMOGSuiCCEBd9eX
	2qTTWjuch+TRfbBRzALtdoCWRD1s=
X-Gm-Gg: ASbGncuyk9fb4SbtyZzIJuhAZDJ0tctkTw31f7FsTs+el2QGICLuw8S29Yo1z+lBq4a
	JhwakiNw1e2mOmYmA8XBcdS/sShA1+cB9Wk8VRg==
X-Google-Smtp-Source: AGHT+IHACpWQarwyHqgVFej12h3sZ9v5XSkC82TZvdnRS6/tjJiM7t0IXYSpLP19pAQaJiQBCnassDGmy7JGKAd6wj8=
X-Received: by 2002:a05:6214:240b:b0:6df:97a3:5e76 with SMTP id
 6a1803df08f44-6e1b21d13e5mr4146116d6.27.1737060136243; Thu, 16 Jan 2025
 12:42:16 -0800 (PST)
MIME-Version: 1.0
References: <e4a649a7fdfc8fcf5f48a0bc4e76e5d546078083.1736868605.git.Slavisa.Petrovic@rt-rk.com>
 <alpine.DEB.2.22.394.2501141554170.2684657@ubuntu-linux-20-04-desktop>
 <2f1432e6-0d27-48fd-b034-475284f14233@gmail.com> <CAKp59VEOiXo+OKwPNiomtXNCsfDURCXaDktooi5JSoTSdhc90w@mail.gmail.com>
 <alpine.DEB.2.22.394.2501151313590.2684657@ubuntu-linux-20-04-desktop>
In-Reply-To: <alpine.DEB.2.22.394.2501151313590.2684657@ubuntu-linux-20-04-desktop>
From: =?UTF-8?B?TWlsYW4gxJBva2nEhw==?= <milandjokic1995@gmail.com>
Date: Thu, 16 Jan 2025 21:42:05 +0100
X-Gm-Features: AbW1kvZkiUy496iMlyaJzvfye_IOgV9RfBQMyk7ZAcKoXtvYI4DmcGkMijbvCWw
Message-ID: <CAKp59VG=MV2=gCFqsC16EpP9oGa=eDBFJbwn-vS5q8oKyM_ZJQ@mail.gmail.com>
Subject: Re: [PATCH] riscv: Add initial Xen guest support for RISC-Vgh
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: Oleksii Kurochko <oleksii.kurochko@gmail.com>, linux-riscv@lists.infradead.org, 
	paul.walmsley@sifive.com, palmer@dabbelt.com, aou@eecs.berkeley.edu, 
	jgross@suse.com, oleksandr_tyshchenko@epam.com, Slavisa.Petrovic@rt-rk.com, 
	Milan.Djokic@rt-rk.com, rafael.j.wysocki@intel.com, sunilvl@ventanamicro.com, 
	takakura@valinux.co.jp, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, iommu@lists.linux.dev
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Jan 15, 2025 at 10:14=E2=80=AFPM Stefano Stabellini
<sstabellini@kernel.org> wrote:
>
> On Wed, 15 Jan 2025, Milan =C4=90oki=C4=87 wrote:
> > Hello Stefano, Oleksii
> >
> > On Wed, Jan 15, 2025 at 5:30=E2=80=AFPM Oleksii Kurochko
> > <oleksii.kurochko@gmail.com> wrote:
> > >
> > > Hi Stefano,
> > >
> > > On 1/15/25 1:01 AM, Stefano Stabellini wrote:
> > >
> > > +Oleksii
> > >
> > > On Tue, 14 Jan 2025, Milan Djokic wrote:
> > >
> > > From: Slavisa Petrovic <Slavisa.Petrovic@rt-rk.com>
> > >
> > > This patch introduces initial support for running RISC-V as a Xen gue=
st.
> > > It provides the necessary infrastructure and stubs for Xen-specific
> > > operations. Key changes include:
> > >
> > > - Modifications to the RISC-V kernel to integrate Xen-specific hyperc=
alls
> > >   and interfaces, with function implementations stubbed for future wo=
rk.
> > > - Introduction of Xen-specific headers for RISC-V, including event
> > >   handling, hypervisor interaction, and page management. Functions ar=
e
> > >   defined but not yet implemented.
> > > - Stub implementations for memory management, grant tables, and conte=
xt
> > >   switching in the Xen environment, allowing further development and
> > >   integration.
> > >
> > > Signed-off-by: Milan Djokic <Milan.Djokic@rt-rk.com>
> > > Signed-off-by: Slavisa Petrovic <Slavisa.Petrovic@rt-rk.com>
> > >
> > > Hi Milan, Slavisa,
> > >
> > > Thank you very much for your contribution! Which Xen tree are you usi=
ng
> > > for development?
> > >
> > > They are using [1] and have separate branches on top of latest. So we=
 are in
> > > sync. Also, if you are interested we have created a task/epics for th=
is feature in
> > > [1] so you could also check there some details:
> > > 1. https://gitlab.com/groups/xen-project/people/olkur/-/epics/5
> > > 2. https://gitlab.com/xen-project/people/olkur/xen/-/issues/12
> > >
> > >  I am asking because RISC-V support in Xen is still in
> > > the process of being upstreamed, and [1] is the tree that consolidate=
s
> > > all patches currently on the to-be-upstreamed list.
> > >
> > > While the specific Xen tree you are using is not particularly importa=
nt
> > > at this stage, and using [1] is not a requirement, I am asking becaus=
e
> > > it is essential to align on the hypervisor ABI, especially regarding =
any
> > > details that have not yet been upstreamed. Specifically, is there
> > > anything in this patch series that relies on features not yet upstrea=
m
> > > in Xen?
> > >
> > > There are few features but some things which are Rt-Tk's branch in [1=
] could go
> > > without waiting for these features to be upstreamed.
> > >
> > > Thanks.
> > >
> > > ~ Oleksii
> > >
> > > [1] https://gitlab.com/xen-project/people/olkur/xen/-/tree/latest?ref=
_type=3Dheads
> >
> > As Oleksii already explained, we are working in sync with his latest
> > branch where most of the risc port is done.
>
> Perfect, I was hoping you'd say that! :-)
> It is great to have you on board.
>
>
> > I would just add that this patch introduces kernel risc-v hypercall
> > support on which only our branch on xen tree depends on. Therefore, it
> > won't disrupt any functionality with current upstream Xen, it will
> > just introduce kernel functionality which is not used from Xen side
> > until our branch is merged upstream.
>
> Ideally, we should upstream the Xen side of an interface first to Xen,
> then add support for the interface to Linux. Let me make a concrete
> example. Let's say that you upstream hypercall support to Linux first,
> using SBI_ECALL defined as 0xE. Then, during the upstreaming process,
> the Xen community decides to change SBI_ECALL to 0XEA1 to make it the
> same as ARM. You'd have to change the Linux code again to fix it. To
> avoid this, it is best to wait upstreaming the Linux side, until the Xen
> side is Acked.
>
Sure, I got your point. This is actually one of the things we were not
sure about (whether we should upstream Linux or Xen side first).
Anyways it's good that we got review comments. We'll fix this patch
according to suggestions and send it back when Xen side is upstream.

> This was just an example, and Andrew is right that the SBI
> Implementation ID for Xen is reserved to 0x7, see the SBI specification.
Yes, we were not aware of it, thanks.

BR,
Milan


From xen-devel-bounces@lists.xenproject.org Thu Jan 16 20:47:24 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 20:47:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873775.1284749 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYWlv-0002xx-Cp; Thu, 16 Jan 2025 20:47:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873775.1284749; Thu, 16 Jan 2025 20:47:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYWlv-0002xq-9s; Thu, 16 Jan 2025 20:47:23 +0000
Received: by outflank-mailman (input) for mailman id 873775;
 Thu, 16 Jan 2025 20:47:21 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=mFzr=UI=gmail.com=milandjokic1995@srs-se1.protection.inumbo.net>)
 id 1tYWlt-0002xk-J2
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 20:47:21 +0000
Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com
 [2607:f8b0:4864:20::f33])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1429b003-d44b-11ef-a0e2-8be0dac302b0;
 Thu, 16 Jan 2025 21:47:20 +0100 (CET)
Received: by mail-qv1-xf33.google.com with SMTP id
 6a1803df08f44-6dd049b5428so13126056d6.2
 for <xen-devel@lists.xenproject.org>; Thu, 16 Jan 2025 12:47:20 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1429b003-d44b-11ef-a0e2-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1737060439; x=1737665239; 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=V4WaxXi2+hLFc11CwCXtWWCzphbkvrV7PTL31qaoaOM=;
        b=c5t16SYKo3HC8ZRnZlpiQTB7a+ZoNB6TTxF/t531Yl5TmVuknVj9KGSL1TzT7iG3g+
         bMrkCVugg/gCABpK1xDUifKUeKvR3CRh/8Z3NpphgeR7h6GL+bCHSpLrVOnQVnaaYMdj
         SCLVS5yeWk+W55Lya47lPVncTO9XKwMqYv6sNvafOQxkAW3AchH/6U6e1LtzDXtcvaZb
         9AsO1gL9qn5Fh+oQwgymxlaV+w5Bfsw+GojVAPso8zWdmSUt5wCNz7D8a4Bwaqy98fTS
         Namig+HPog800cNq8yWUyXLzVxDvwufgoqEMEdqkMcD17MAZP5fkD4WyGcP7Ctn/61Je
         nXmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737060439; x=1737665239;
        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=V4WaxXi2+hLFc11CwCXtWWCzphbkvrV7PTL31qaoaOM=;
        b=L1J9AlLVFUw2qSp8yizjIIQHs6rD8tI4yN5SMr9Y3jJ7Tbhm2a3ESQuLpyv2Zv14Pz
         XhB73H7GRi+ozfbR8Mw+1Wp1N5s6TGbM6QUZrp/8OipV/VJk2wL+Qbcd+dkzotd4px/W
         l04jILV1X3G9Ao0dnKIZ8aKUSVGuDsokiZUYiSdGFfC3ujOEjgysYXvVftLfVr81wVay
         mmngiLuchASHS+hB0m2zqYqt5UnTZyrmvWM96CvImHxZFErigT9ZFJUV56/ZNLUD28rV
         mclwM9XnmVXRB/LmCcMdnwL0kcZ5yjzQp3epEwx7Ff/+1Z3h3d0NEFn3O8WR6Wl4rJ2i
         iV+w==
X-Forwarded-Encrypted: i=1; AJvYcCVd1yOwNRZYajYQIWpm8HdnRQJDirHkNB6c3yhrQC/nbp61X+g1fMXOg896cHUHgrosHYxF2anW7G0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyzXOSaWY6P3CbzMjOx2mby5Wf/iH0jUG2gm99Wprq8QoEZGBg3
	/rCVL+uz4Gzf0KYsJPweOeO0UzsN4bg9XPHwrmY3VNhOWvsDiE7o7RW6rXWOn1GDm/9R3snCkej
	tHSYyMeq+XPLHSqXz1r54/wmmLVI=
X-Gm-Gg: ASbGnctTNJmXhT2mmyk4bon8kmfXLLW9hTYxzgHp2NTLQa2hmBE0x+8p9Z+nNHOoFI4
	S1ui8hN6rbVn3wZT3YmAIsmtnFj+JWAb59SL59Q==
X-Google-Smtp-Source: AGHT+IHkiMkxTT+D/jUmccrpj641SbpMcRFsm0/PjGiESgQXTK8ry7/fBlshiko5P+U6Wk0IaoScZJqKTAzwl10WUSs=
X-Received: by 2002:a05:6214:d67:b0:6d3:b936:60d1 with SMTP id
 6a1803df08f44-6e1b222f30dmr4145206d6.33.1737060439255; Thu, 16 Jan 2025
 12:47:19 -0800 (PST)
MIME-Version: 1.0
References: <e4a649a7fdfc8fcf5f48a0bc4e76e5d546078083.1736868605.git.Slavisa.Petrovic@rt-rk.com>
 <20250114-316084c962eb867c0b681043@orel> <CAKp59VFkW8F2xHsgAxiw138ZrpQJL8R5cTkF8f9vY40iEoRbWg@mail.gmail.com>
 <20250116-aa9eadde9279e66dbc01c705@orel> <D73F98QBJ4S9.3CN2ZUQ0GSMT6@ventanamicro.com>
In-Reply-To: <D73F98QBJ4S9.3CN2ZUQ0GSMT6@ventanamicro.com>
From: =?UTF-8?B?TWlsYW4gxJBva2nEhw==?= <milandjokic1995@gmail.com>
Date: Thu, 16 Jan 2025 21:47:07 +0100
X-Gm-Features: AbW1kvYRLMdilN-fKQeGs9HLVXMRAcFvnbevXtEayIrgWQ6TZbBT9Zlq_f2m72k
Message-ID: <CAKp59VFN+vfdvg0jVsLiQitoTDAVg=ZsuatPJkwcLdG7RqUqMw@mail.gmail.com>
Subject: Re: [PATCH] riscv: Add initial Xen guest support for RISC-V
To: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= <rkrcmar@ventanamicro.com>
Cc: Andrew Jones <ajones@ventanamicro.com>, linux-riscv@lists.infradead.org, 
	jgross@suse.com, aou@eecs.berkeley.edu, Milan.Djokic@rt-rk.com, 
	rafael.j.wysocki@intel.com, linux-kernel@vger.kernel.org, 
	oleksandr_tyshchenko@epam.com, iommu@lists.linux.dev, sstabellini@kernel.org, 
	palmer@dabbelt.com, paul.walmsley@sifive.com, xen-devel@lists.xenproject.org, 
	Slavisa.Petrovic@rt-rk.com, takakura@valinux.co.jp, 
	linux-riscv <linux-riscv-bounces@lists.infradead.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 16, 2025 at 11:23=E2=80=AFAM Radim Kr=C4=8Dm=C3=A1=C5=99 <rkrcm=
ar@ventanamicro.com> wrote:
>
> 2025-01-16T09:51:25+01:00, Andrew Jones <ajones@ventanamicro.com>:
> > On Wed, Jan 15, 2025 at 08:04:05PM +0100, Milan =C4=90oki=C4=87 wrote:
> >> On Tue, Jan 14, 2025 at 7:18=E2=80=AFPM Andrew Jones <ajones@ventanami=
cro.com> wrote:
> >> > On Tue, Jan 14, 2025 at 05:09:36PM +0100, Milan Djokic wrote:
> >> > > +#define SBI_ECALL 0xE
> >> >
> >> > Shouldn't this be 0xA000007, i.e. the SBI firmware specific extensio=
n
> >> > for Xen. Otherwise why refer to SBI? Note, '0xE' is an invalid, lega=
cy
> >> > extension ID in SBI.
> >> >
> >> Hypercall is triggered through SBI and we defined 0xE just as an
> >> SBI_ECALL ID on Xen side for hypercall handling (among other operation
> >> IDs), so we're not referring to some standard /legacy ID here, just
> >> utilizing SBI for hypercall handling.
> >
> > If the SBI specified EIDs and binary encoding aren't used, then the
> > hypercalls aren't "triggered through SBI", Xen is just doing its own
> > thing on an ecall. Xen doesn't have to implement SBI at all, but if
> > it wants to provide SBI services, as well as its own hypercalls, then
> > the hypercalls should be encoded in the same way as SBI functions and
> > an EID allowed by the SBI specification for hypervisor-specific
> > functions should be used. For Xen, that EID is already specified and
> > it's 0xA000007.
>
> SBI specifies a complete calling convention, but it's not necessary for
> binary compatibility.  SBI also aims to simplify caller API.
>
> Linux maintainers will want a good reason for introducing separate Xen
> SBI call functions/macros (linux already has sbi_ecall, so please try to
> use and potentially improve it), but the ECALL is guaranteed to be SBI
> compatible as long as a7=3D0xA000007.
>
> a7 is needed to denote Xen's extension space and the remaining
> input/output registers can be implemented in any way Xen wants.
Thanks for clarification. We have checked the SBI specification and
everything is clear now.
We'll fix this in the following patch revision.

BR,
Milan


From xen-devel-bounces@lists.xenproject.org Thu Jan 16 21:08:10 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 21:08:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873800.1284759 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYX5x-0006I6-70; Thu, 16 Jan 2025 21:08:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873800.1284759; Thu, 16 Jan 2025 21:08:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYX5x-0006Hz-4B; Thu, 16 Jan 2025 21:08:05 +0000
Received: by outflank-mailman (input) for mailman id 873800;
 Thu, 16 Jan 2025 21:08:03 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=oLIk=UI=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tYX5v-0006Hs-H5
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 21:08:03 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org
 [2604:1380:45d1:ec00::3])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f83923ce-d44d-11ef-a0e2-8be0dac302b0;
 Thu, 16 Jan 2025 22:08:02 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 77096A4277F;
 Thu, 16 Jan 2025 21:06:12 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 27BB0C4CED6;
 Thu, 16 Jan 2025 21:07:58 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f83923ce-d44d-11ef-a0e2-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1737061680;
	bh=jz4mFU9u1twIuaW1pCTzx/vWfeheqpZU6b45voKJ0ZI=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=JgJhFSFlpSgBwC33cUPlLEwY7nroUBe4Dh4dJJ1Qbrf5FiYoxOrVTwPsTUcxxfRFU
	 BfPi2xogBfE+QgsczG8EqWUNKWtN9TWbjTpe00eeUlDg/q0ggTEq2iMMOuG2iOSYS0
	 cuuRUi9Eb9n4m/y9LibBZbDIhP/n3R8EddH/XQ75ywVAjo5zVH0ncK3WhKrOQtxfXP
	 yHB6WuTxiAKzrk3XZyc83WHb/ow7ffLfGY9t5c7rjRFO1leS+gfsrvlKE1t6JGXnEw
	 Dk92qEqVbimIs50isLxQCVjD+KR1csIFVVVcsKRPf1TRQC96vpaMIlbvnKyedvA4Kk
	 GAoAla+4VpnAQ==
Date: Thu, 16 Jan 2025 13:07:56 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: =?UTF-8?Q?Milan_=C4=90oki=C4=87?= <milandjokic1995@gmail.com>
cc: Stefano Stabellini <sstabellini@kernel.org>, 
    Oleksii Kurochko <oleksii.kurochko@gmail.com>, 
    linux-riscv@lists.infradead.org, paul.walmsley@sifive.com, 
    palmer@dabbelt.com, aou@eecs.berkeley.edu, jgross@suse.com, 
    oleksandr_tyshchenko@epam.com, Slavisa.Petrovic@rt-rk.com, 
    Milan.Djokic@rt-rk.com, rafael.j.wysocki@intel.com, 
    sunilvl@ventanamicro.com, takakura@valinux.co.jp, 
    linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, 
    iommu@lists.linux.dev
Subject: Re: [PATCH] riscv: Add initial Xen guest support for RISC-Vgh
In-Reply-To: <CAKp59VG=MV2=gCFqsC16EpP9oGa=eDBFJbwn-vS5q8oKyM_ZJQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.22.394.2501161304480.2684657@ubuntu-linux-20-04-desktop>
References: <e4a649a7fdfc8fcf5f48a0bc4e76e5d546078083.1736868605.git.Slavisa.Petrovic@rt-rk.com> <alpine.DEB.2.22.394.2501141554170.2684657@ubuntu-linux-20-04-desktop> <2f1432e6-0d27-48fd-b034-475284f14233@gmail.com> <CAKp59VEOiXo+OKwPNiomtXNCsfDURCXaDktooi5JSoTSdhc90w@mail.gmail.com>
 <alpine.DEB.2.22.394.2501151313590.2684657@ubuntu-linux-20-04-desktop> <CAKp59VG=MV2=gCFqsC16EpP9oGa=eDBFJbwn-vS5q8oKyM_ZJQ@mail.gmail.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-352887263-1737061680=:2684657"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-352887263-1737061680=:2684657
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Thu, 16 Jan 2025, Milan Đokić wrote:
> On Wed, Jan 15, 2025 at 10:14 PM Stefano Stabellini
> <sstabellini@kernel.org> wrote:
> >
> > On Wed, 15 Jan 2025, Milan Đokić wrote:
> > > Hello Stefano, Oleksii
> > >
> > > On Wed, Jan 15, 2025 at 5:30 PM Oleksii Kurochko
> > > <oleksii.kurochko@gmail.com> wrote:
> > > >
> > > > Hi Stefano,
> > > >
> > > > On 1/15/25 1:01 AM, Stefano Stabellini wrote:
> > > >
> > > > +Oleksii
> > > >
> > > > On Tue, 14 Jan 2025, Milan Djokic wrote:
> > > >
> > > > From: Slavisa Petrovic <Slavisa.Petrovic@rt-rk.com>
> > > >
> > > > This patch introduces initial support for running RISC-V as a Xen guest.
> > > > It provides the necessary infrastructure and stubs for Xen-specific
> > > > operations. Key changes include:
> > > >
> > > > - Modifications to the RISC-V kernel to integrate Xen-specific hypercalls
> > > >   and interfaces, with function implementations stubbed for future work.
> > > > - Introduction of Xen-specific headers for RISC-V, including event
> > > >   handling, hypervisor interaction, and page management. Functions are
> > > >   defined but not yet implemented.
> > > > - Stub implementations for memory management, grant tables, and context
> > > >   switching in the Xen environment, allowing further development and
> > > >   integration.
> > > >
> > > > Signed-off-by: Milan Djokic <Milan.Djokic@rt-rk.com>
> > > > Signed-off-by: Slavisa Petrovic <Slavisa.Petrovic@rt-rk.com>
> > > >
> > > > Hi Milan, Slavisa,
> > > >
> > > > Thank you very much for your contribution! Which Xen tree are you using
> > > > for development?
> > > >
> > > > They are using [1] and have separate branches on top of latest. So we are in
> > > > sync. Also, if you are interested we have created a task/epics for this feature in
> > > > [1] so you could also check there some details:
> > > > 1. https://gitlab.com/groups/xen-project/people/olkur/-/epics/5
> > > > 2. https://gitlab.com/xen-project/people/olkur/xen/-/issues/12
> > > >
> > > >  I am asking because RISC-V support in Xen is still in
> > > > the process of being upstreamed, and [1] is the tree that consolidates
> > > > all patches currently on the to-be-upstreamed list.
> > > >
> > > > While the specific Xen tree you are using is not particularly important
> > > > at this stage, and using [1] is not a requirement, I am asking because
> > > > it is essential to align on the hypervisor ABI, especially regarding any
> > > > details that have not yet been upstreamed. Specifically, is there
> > > > anything in this patch series that relies on features not yet upstream
> > > > in Xen?
> > > >
> > > > There are few features but some things which are Rt-Tk's branch in [1] could go
> > > > without waiting for these features to be upstreamed.
> > > >
> > > > Thanks.
> > > >
> > > > ~ Oleksii
> > > >
> > > > [1] https://gitlab.com/xen-project/people/olkur/xen/-/tree/latest?ref_type=heads
> > >
> > > As Oleksii already explained, we are working in sync with his latest
> > > branch where most of the risc port is done.
> >
> > Perfect, I was hoping you'd say that! :-)
> > It is great to have you on board.
> >
> >
> > > I would just add that this patch introduces kernel risc-v hypercall
> > > support on which only our branch on xen tree depends on. Therefore, it
> > > won't disrupt any functionality with current upstream Xen, it will
> > > just introduce kernel functionality which is not used from Xen side
> > > until our branch is merged upstream.
> >
> > Ideally, we should upstream the Xen side of an interface first to Xen,
> > then add support for the interface to Linux. Let me make a concrete
> > example. Let's say that you upstream hypercall support to Linux first,
> > using SBI_ECALL defined as 0xE. Then, during the upstreaming process,
> > the Xen community decides to change SBI_ECALL to 0XEA1 to make it the
> > same as ARM. You'd have to change the Linux code again to fix it. To
> > avoid this, it is best to wait upstreaming the Linux side, until the Xen
> > side is Acked.
> >
> Sure, I got your point. This is actually one of the things we were not
> sure about (whether we should upstream Linux or Xen side first).
> Anyways it's good that we got review comments. We'll fix this patch
> according to suggestions and send it back when Xen side is upstream.

Thank you! In general, "first upstream to Xen, then to Linux" is a good
guideline, but we can be flexible. For instance, in the case of
hypercalls that seem pretty obvious how we are going to implement them,
it might be sufficient to send a simple patch to Xen to add a document
under xen.git/docs/ to document how the hypercall ABI will look like on
RISC-V, without the implementation. With that document committed to
xen.git, we can go forward with upstreaming the Linux side, even if the
upstream Xen implementation is still lacking.
--8323329-352887263-1737061680=:2684657--


From xen-devel-bounces@lists.xenproject.org Thu Jan 16 21:22:27 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 21:22:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873812.1284769 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYXJl-00011l-C5; Thu, 16 Jan 2025 21:22:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873812.1284769; Thu, 16 Jan 2025 21:22:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYXJl-00011e-9F; Thu, 16 Jan 2025 21:22:21 +0000
Received: by outflank-mailman (input) for mailman id 873812;
 Thu, 16 Jan 2025 21:22:21 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=oLIk=UI=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tYXJl-00011Y-0M
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 21:22:21 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f6b34956-d44f-11ef-99a4-01e77a169b0f;
 Thu, 16 Jan 2025 22:22:18 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 7D2EF5C5FE7;
 Thu, 16 Jan 2025 21:21:36 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7F0E3C4CEDD;
 Thu, 16 Jan 2025 21:22:15 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f6b34956-d44f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1737062536;
	bh=ffkEaWjYvlPoNeNiYvsQVbb/vU0axWyLB1EqOQ73goU=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=WYgKrCuaImJOgUTHEKMgEBtMeelvPTqBLVZw3gdu38qkulAkqoFEzhf3ZhEX89uZh
	 nFWicHSIBw8A1jRAOyHu6jlmZRUB4ZV0haf9r4n6EJKwAulWycOtIhJflT0VPBhTfB
	 TcA7Nc04gpS44X+O8wTMGKqbvJZ2W6kKA47Ao1P1G+40TVDBZqsFK7T1QsBJ0ba6Q4
	 oeSStMwUb1V/LEdx3S/badIE2xX28RD4kb5vavqLkcbaGY+eREtj5Zuin/5FW6mXbi
	 Pd0THwomJZe478IMFzW2LTn3pcYor8JkheGiINkHQgd6FG4dZrhnY8GQxPwSnaFrar
	 zpKVXneoHrMFQ==
Date: Thu, 16 Jan 2025 13:22:14 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Nicola Vetrini <nicola.vetrini@bugseng.com>
cc: Jan Beulich <jbeulich@suse.com>, sstabellini@kernel.org, 
    michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, 
    consulting@bugseng.com, Andrew Cooper <andrew.cooper3@citrix.com>, 
    Anthony PERARD <anthony.perard@vates.tech>, Julien Grall <julien@xen.org>, 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
    xen-devel@lists.xenproject.org
Subject: Re: [XEN PATCH] docs/misra: Document ECLAIR extension to Rule 20.7
In-Reply-To: <48035a91703c82c82e9c5239fb6373a7@bugseng.com>
Message-ID: <alpine.DEB.2.22.394.2501161322000.2684657@ubuntu-linux-20-04-desktop>
References: <77354513a986a14c37ec2dfc45cf3534b08b5e85.1736972547.git.nicola.vetrini@bugseng.com> <d90e5496-cccf-4670-8332-8d2e5f482c5e@suse.com> <48035a91703c82c82e9c5239fb6373a7@bugseng.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Thu, 16 Jan 2025, Nicola Vetrini wrote:
> On 2025-01-16 10:51, Jan Beulich wrote:
> > On 16.01.2025 10:31, Nicola Vetrini wrote:
> > > MISRA C Rule 20.7 states:
> > > "Expressions resulting from the expansion of macro parameters shall
> > > be enclosed in parentheses".
> > > 
> > > Document the behaviour of ECLAIR with respect to the CPP extension
> > > that allows variable macro arguments to be named.
> > > 
> > > Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
> > > ---
> > >  docs/misra/rules.rst | 9 ++++++++-
> > >  1 file changed, 8 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
> > > index e7763795b826..13890f6d8852 100644
> > > --- a/docs/misra/rules.rst
> > > +++ b/docs/misra/rules.rst
> > > @@ -671,7 +671,14 @@ maintainers if you want to suggest a change.
> > >         shall be enclosed in parentheses
> > >       - Extra parentheses are not required when macro parameters are used
> > >         as function arguments, as macro arguments, array indices, lhs in
> > > -       assignments or as initializers in initalizer lists.
> > > +       assignments or as initializers in initalizer lists. In addition,
> > > +       the use of a named variable argument in a macro that would
> > > constitute
> > > +       a violation of the rule is allowed by ECLAIR as an extension of
> > > the
> > > +       MISRA, since it may not always be possible to parenthesize such
> > 
> > Just one nit / question (addressable while committing, if desired): I
> > wouldn't have expected "the" before "MISRA". Is that conventional wording
> > in your environment?
> > 
> > Jan
> 
> Hi Jan,
> 
> that was just a typo. It should have been "the MISRA guideline".
> Thanks for catching that

With that fixed:

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


From xen-devel-bounces@lists.xenproject.org Thu Jan 16 22:10:57 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Jan 2025 22:10:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873822.1284780 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYY4Z-000803-Qy; Thu, 16 Jan 2025 22:10:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873822.1284780; Thu, 16 Jan 2025 22:10:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYY4Z-0007zw-O4; Thu, 16 Jan 2025 22:10:43 +0000
Received: by outflank-mailman (input) for mailman id 873822;
 Thu, 16 Jan 2025 22:10: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
 <SRS0=KbEa=UI=redhat.com=stefanha@srs-se1.protection.inumbo.net>)
 id 1tYY4Y-0007wG-VD
 for xen-devel@lists.xenproject.org; Thu, 16 Jan 2025 22:10:42 +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 b775f8be-d456-11ef-99a4-01e77a169b0f;
 Thu, 16 Jan 2025 23:10:39 +0100 (CET)
Received: from mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-215--MrRq8HIO2CqLybNWlljYw-1; Thu,
 16 Jan 2025 17:10:34 -0500
Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 3C5AD1955DCC; Thu, 16 Jan 2025 22:10:32 +0000 (UTC)
Received: from localhost (unknown [10.2.16.180])
 by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP
 id E5DEA195608A; Thu, 16 Jan 2025 22:10:28 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b775f8be-d456-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1737065438;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=3w/7Xt83amm/l8+9d346Cvv8xvPaOw1+n1RLVeOI+Fc=;
	b=TwxCCDJJW+bhBrPwIob4yF5kNvfdOL8Rtq3ZhQGuS0OHnanAuEXdUL8DKFnXND7v68D1ac
	db4yDqnwQMg/T/OWsT8ijTu0w2Qw7xCuHzLyBHdB14L85SAjE6fxdIvqr9YPCyHulMWYll
	Me67wkngDYNaYKqoA2g3b/n6jVhkkTY=
X-MC-Unique: -MrRq8HIO2CqLybNWlljYw-1
X-Mimecast-MFC-AGG-ID: -MrRq8HIO2CqLybNWlljYw
Date: Thu, 16 Jan 2025 17:10:27 -0500
From: Stefan Hajnoczi <stefanha@redhat.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Stefan Hajnoczi <stefanha@redhat.com>, qemu-devel@nongnu.org,
	Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	Paul Durrant <paul@xen.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Kevin Wolf <kwolf@redhat.com>, Hanna Reitz <hreitz@redhat.com>,
	=?iso-8859-1?Q?Marc-Andr=E9?= Lureau <marcandre.lureau@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Jason Wang <jasowang@redhat.com>, xen-devel@lists.xenproject.org,
	qemu-block@nongnu.org, Phil Dennis-Jordan <phil@philjordan.eu>,
	David Woodhouse <dwmw@amazon.co.uk>
Subject: Re: [PULL 0/8] Xen regression fixes and cleanups
Message-ID: <20250116221027.GA378432@fedora>
References: <20250116084332.1864967-1-dwmw2@infradead.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="8HLMaDdlMH1p57ew"
Content-Disposition: inline
In-Reply-To: <20250116084332.1864967-1-dwmw2@infradead.org>
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15


--8HLMaDdlMH1p57ew
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/10.0 for any user-visible changes.

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

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

iQEzBAEBCAAdFiEEhpWov9P5fNqsNXdanKSrs4Grc8gFAmeJg9MACgkQnKSrs4Gr
c8i1bgf+MHoLNCA3PrVNq+8PBjcLbABt0e/iUMP1lMjdZbfbSuXOKnOXzkuuV4j/
B4VgoC3lPDm5BLF8YmliXE377/khnnh87uFifbar35rL/CZ/FQaMQ1+LSmqx5muk
B38lJR6aA16v/FmcOfQiIe3ucNcqVoxUGLMUD9maouS05t0EhSN3ZYEbwn8lU65O
8OoVoBRgKlBH+3KQf+x5pdKC8WkFm1rzhak5WfY2G7kghzspSYvTaz9z2TPfgobq
ejm6N8Nstls4VrqBOPUzcuJpOC5nDsx1DgabuTiGWkPwSZ1wccDNn+rfJkb85tEz
uO8oEL54Z5Ie9w4+tfuhOl7MdVcLiw==
=eYTV
-----END PGP SIGNATURE-----

--8HLMaDdlMH1p57ew--



From xen-devel-bounces@lists.xenproject.org Fri Jan 17 00:32:09 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Jan 2025 00:32:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873837.1284790 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYaHC-00012q-Rs; Fri, 17 Jan 2025 00:31:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873837.1284790; Fri, 17 Jan 2025 00:31:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYaHC-00012j-Ou; Fri, 17 Jan 2025 00:31:54 +0000
Received: by outflank-mailman (input) for mailman id 873837;
 Fri, 17 Jan 2025 00:31:53 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=O/RI=UJ=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tYaHB-00012b-Hi
 for xen-devel@lists.xenproject.org; Fri, 17 Jan 2025 00:31:53 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org
 [2604:1380:45d1:ec00::3])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7091a171-d46a-11ef-a0e2-8be0dac302b0;
 Fri, 17 Jan 2025 01:31:50 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 60E9AA41BC6;
 Fri, 17 Jan 2025 00:30:01 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id E479BC4CED6;
 Fri, 17 Jan 2025 00:31:47 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 7091a171-d46a-11ef-a0e2-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1737073909;
	bh=EtUVYei0Ssjo061yq3sHLWqSi2Ur2ERypmCb1H2SLt8=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=IHutaP6GhlmGHCamSsvQHgYTs6EQ1ZpMiKbv20G+2ICpZAt2atUHZc3MdLA5IhJvY
	 nHVXVq7IBKDHatirJgmxqOr1ILlNfCEzHJkg6mvVSZraiOIkjwciEZiZeVv5bMxsB1
	 3ZVdtq5ei8qgn5jQQIX8aCT1w/KvU8qAyhdqIOopS7p65QYxzq5J3008LZkSI+cW6C
	 pSEinZk4dIyeyXNMyCKx9bUqEseEaeZgqc7Uyjuow/AIQkww9MRfi7lDHrDoPjGnPE
	 cUpbf07bT4YxuLbG3QgchRfKTH6eCW3h3/N92TmVCxFZ/Fo3Q8vtDANY4eDQRpowgZ
	 4jGEtjem/U6bw==
Date: Thu, 16 Jan 2025 16:31:46 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich <jbeulich@suse.com>
cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, 
    Andrew Cooper <andrew.cooper3@citrix.com>, 
    George Dunlap <george.dunlap@citrix.com>, Julien Grall <julien@xen.org>, 
    Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>, 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
    sergiy_kibrik@epam.com
Subject: Re: [PATCH v2 1/4] x86: provide an inverted Kconfig control for
 shim-exclusive mode
In-Reply-To: <617842e1-8ef2-b095-0c52-c2e2e5f1c0a8@suse.com>
Message-ID: <alpine.DEB.2.22.394.2501161503120.2684657@ubuntu-linux-20-04-desktop>
References: <da5f5bac-6d5d-092d-d872-f1120dcd2661@suse.com> <617842e1-8ef2-b095-0c52-c2e2e5f1c0a8@suse.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Wed, 1 Mar 2023, Jan Beulich wrote:
> While we want certain things turned off in shim-exclusive mode, doing
> so via "depends on !PV_SHIM_EXCLUSIVE" badly affects allyesconfig: Since
> that will turn on PV_SHIM_EXCLUSIVE, other options will be turned off as
> a result. Yet allyesconfig wants to enable as much of the functionality
> as possible.
> 
> Retain PV_SHIM_EXCLUSIVE as a prompt-less option such that first of all
> C code using it can remain as is. This isn't just for less code churn,
> but also because I think that symbol is more logical to use in many
> (all?) places.
> 
> Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> ---
> The new Kconfig control's name is up for improvement suggestions, but I
> think it's already better than the originally thought of
> FULL_HYPERVISOR.

I think the approach in general is OK, maybe we can improve the naming
further. What about one of the following?

NO_PV_SHIM_EXCLUSIVE
PV_SHIM_NOT_EXCLUSIVE
ADD_PV_SHIM
PV_SHIM_AND_HYPERVISOR

This is because I think the option should be tied to PV_SHIM. Keep in
mind that users are supposed to be able to use "make menuconfig" and
pick good options based on the menu. An option called UNCONSTRAINED or
FULL_HYPERVISOR or any other name that has nothing to do with PV_SHIM is
very confusing to me.


> Secondary Kconfig changes could be omitted; in all of the cases I wasn't
> really sure whether do the adjustments. I think to avoid setting a bad
> precedent we want to avoid "depends on !..." (and hence also the
> functionally equivalent "if !..."), but any default settings or prompt
> controls could also be left as they were (or could be done the other way
> around in subsequent patches).
> 
> The Requested-by: isn't for what exactly is done here, but for the
> underlying principle of avoiding the negative dependencies we've grown.
> 
> Outside of Arm-specific code we have two more negative "depends on":
> COVERAGE requires !LIVEPATCH and SUPPRESS_DUPLICATE_SYMBOL_WARNINGS
> requires !ENFORCE_UNIQUE_SYMBOLS. The latter could apparently be
> switched to a choice (enforce, warn, don't warn), but then I'm not sure
> how well choices play with allyesconfig (I guess the default setting is
> used).
> ---
> v2: New.
> 
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -103,7 +103,7 @@ config PV_LINEAR_PT
>  
>  config HVM
>  	bool "HVM support"
> -	depends on !PV_SHIM_EXCLUSIVE
> +	depends on UNCONSTRAINED
>  	default !PV_SHIM
>  	select COMPAT
>  	select IOREQ_SERVER
> @@ -145,7 +145,7 @@ config XEN_IBT
>  
>  config SHADOW_PAGING
>  	bool "Shadow Paging"
> -	default !PV_SHIM_EXCLUSIVE
> +	default UNCONSTRAINED
>  	depends on PV || HVM
>  	---help---
>  
> @@ -196,7 +196,7 @@ config HVM_FEP
>  config TBOOT
>  	bool "Xen tboot support (UNSUPPORTED)"
>  	depends on UNSUPPORTED
> -	default !PV_SHIM_EXCLUSIVE
> +	default UNCONSTRAINED
>  	select CRYPTO
>  	---help---
>  	  Allows support for Trusted Boot using the Intel(R) Trusted Execution
> @@ -276,17 +276,19 @@ config PV_SHIM
>  
>  	  If unsure, say Y.
>  
> -config PV_SHIM_EXCLUSIVE
> -	bool "PV Shim Exclusive"
> -	depends on PV_SHIM
> -	---help---
> -	  Build Xen in a way which unconditionally assumes PV_SHIM mode.  This
> -	  option is only intended for use when building a dedicated PV Shim
> -	  firmware, and will not function correctly in other scenarios.
> +config UNCONSTRAINED
> +	bool "do NOT build a functionality restricted hypervisor" if PV_SHIM
> +	default y
> +	help
> +	  Do NOT build Xen in a way which unconditionally assumes PV_SHIM mode.
>  
> -	  If unsure, say N.
> +	  If unsure, say Y.

Yes, the option should not be visible and default y unless PV_SHIM is
selected, like you did.

I think this patch is fine overall, I only suggest a renaming of
UNCONSTRAINED to something to ties it to PV_SHIM.


> +config PV_SHIM_EXCLUSIVE
> +	def_bool y
> +	depends on !UNCONSTRAINED
>  
> -if !PV_SHIM_EXCLUSIVE
> +if UNCONSTRAINED
>  
>  config HYPERV_GUEST
>  	bool "Hyper-V Guest"
> --- a/xen/arch/x86/configs/pvshim_defconfig
> +++ b/xen/arch/x86/configs/pvshim_defconfig
> @@ -3,7 +3,7 @@ CONFIG_PV=y
>  CONFIG_XEN_GUEST=y
>  CONFIG_PVH_GUEST=y
>  CONFIG_PV_SHIM=y
> -CONFIG_PV_SHIM_EXCLUSIVE=y
> +# CONFIG_UNCONSTRAINED is not set
>  CONFIG_NR_CPUS=32
>  CONFIG_EXPERT=y
>  # Disable features not used by the PV shim
> --- a/xen/drivers/video/Kconfig
> +++ b/xen/drivers/video/Kconfig
> @@ -3,10 +3,10 @@ config VIDEO
>  	bool
>  
>  config VGA
> -	bool "VGA support" if !PV_SHIM_EXCLUSIVE
> +	bool "VGA support" if UNCONSTRAINED
>  	select VIDEO
>  	depends on X86
> -	default y if !PV_SHIM_EXCLUSIVE
> +	default y if UNCONSTRAINED
>  	---help---
>  	  Enable VGA output for the Xen hypervisor.
>  
> 
> 


From xen-devel-bounces@lists.xenproject.org Fri Jan 17 07:24:00 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Jan 2025 07:24:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873886.1284800 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYghc-00016S-Vi; Fri, 17 Jan 2025 07:23:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873886.1284800; Fri, 17 Jan 2025 07:23:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYghc-00016L-SH; Fri, 17 Jan 2025 07:23:36 +0000
Received: by outflank-mailman (input) for mailman id 873886;
 Fri, 17 Jan 2025 07:23:35 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=b505=UJ=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tYghb-00016F-Of
 for xen-devel@lists.xenproject.org; Fri, 17 Jan 2025 07:23:35 +0000
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com
 [2a00:1450:4864:20::32b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f43d95e7-d4a3-11ef-99a4-01e77a169b0f;
 Fri, 17 Jan 2025 08:23:31 +0100 (CET)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-436637e8c8dso16451125e9.1
 for <xen-devel@lists.xenproject.org>; Thu, 16 Jan 2025 23:23:31 -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
 5b1f17b1804b1-437c752910esm85600795e9.28.2025.01.16.23.23.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 16 Jan 2025 23:23:30 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f43d95e7-d4a3-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737098611; x=1737703411; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=IJkQQXkSc73VEbb4qnL4cwBsQbLzEFyJJDAPga3driA=;
        b=DXwSRTgpO3C/4DEH76EfoHYdFEy3UqShPCvyQyLYhRF+UGsFl3lgwza3SPxDTMQPwg
         1wGWKXL0KkNJDzJsax658ABQyDfT2BZZoxjQBwfJpLdTQmh0Q1osfeh3HdRBeIGkcRKU
         mPyi/8tgBPNSSTG82G3LsM3Elcq2Z+BP2kBV+U5CVrdGVK6lkPWjU8pcmJN57bTQb8ZA
         pcmi12hp+8QPaMyzq1DlHMI2hGypa2m6HIcXXDcnb7iB8TDjRF9/8nuU59n3ThfnZT65
         ZoWc+gXK70Pd5AWX/2iOSJRycvgr59wmI9+voHhcMmIAPGFR+dJyCH1jTaxFX4a8auVm
         fzDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737098611; x=1737703411;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=IJkQQXkSc73VEbb4qnL4cwBsQbLzEFyJJDAPga3driA=;
        b=hhhpbhiaqzIPPNVLLDiDfpn6tGizS+KNqbqBh6joXjxohBZtki07vQNvLs3//rp/+y
         dZU23IWi5OPOx51iegTg3sT9Ng6Q5LA9uy6466ZYfeTKRkbG2QB8mNu7P39hc+z//Kzr
         AhwgaH4pn0xlFK17zXbCO/sDvMJLLqKUf9B8fhYd9BKpMYcNo/n3k+rW1CPHJizgt/Q2
         MrASKUIAuD52YAod+MA2MijNz/nZC+gXd/+ukyvm8pABY+HvGrVSzePDz4OO1Db1NFz6
         JMyclDXO55ryMifoOKHoQOIqLzu4lryRMhZQddaxvQax+207VD4gP3lfi1A7RWikHbh1
         jWUg==
X-Gm-Message-State: AOJu0YzuVMrFI1S5ab/RJN5Xkfgz+w2RYtQIw0iLqd0fqafk16BFhQXe
	KOOIYcxAJE7yH+4k+fqmlm8t81Aycshi/51OJA+XJcYj21rcf1ua15eerrAwoA==
X-Gm-Gg: ASbGncslLdPkctrZoG1elGC0HMrjmPlZjHZZZTP8gngpg+4mbHVcAkfUvu/cIMHSoVn
	MlsuKekrUJbcsKve5S2NiQstGW4LNfbJkbtL7OnaHjBkPsz7Ken93xKg8Sani/2Kluj32VYxFD8
	FB9W1Ok04iofLdi4Db6yFGIJmaUNia/lJ/+pkO2JmBdydBe89DmxEIch1Xyg1vPBkiUtmqlUisU
	dO6KiSHOFO18BpaSfQ3TqJ/Ak8rTmb4laY64g7zH+t4eLQParM5VKWRU5ox8JVfJ3G11z73mD8o
	aDdEvUHSBfl0wqcEuLOXMeI0q4C0T4z9Re36fZsqGw==
X-Google-Smtp-Source: AGHT+IFGRZVGhg+yXHTXDsh9nXaJk4/mMSWvEdaWpaihb/28Oj7LdRKX9riLRoFaQ5t9IYubZy6wcg==
X-Received: by 2002:a05:600c:c87:b0:434:ff30:a159 with SMTP id 5b1f17b1804b1-438912d54b1mr14740705e9.0.1737098610924;
        Thu, 16 Jan 2025 23:23:30 -0800 (PST)
Message-ID: <afe1350b-249a-478c-ad27-7c1c80ad3558@suse.com>
Date: Fri, 17 Jan 2025 08:23:29 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/4] x86: provide an inverted Kconfig control for
 shim-exclusive mode
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, sergiy_kibrik@epam.com
References: <da5f5bac-6d5d-092d-d872-f1120dcd2661@suse.com>
 <617842e1-8ef2-b095-0c52-c2e2e5f1c0a8@suse.com>
 <alpine.DEB.2.22.394.2501161503120.2684657@ubuntu-linux-20-04-desktop>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <alpine.DEB.2.22.394.2501161503120.2684657@ubuntu-linux-20-04-desktop>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 17.01.2025 01:31, Stefano Stabellini wrote:
> On Wed, 1 Mar 2023, Jan Beulich wrote:
>> While we want certain things turned off in shim-exclusive mode, doing
>> so via "depends on !PV_SHIM_EXCLUSIVE" badly affects allyesconfig: Since
>> that will turn on PV_SHIM_EXCLUSIVE, other options will be turned off as
>> a result. Yet allyesconfig wants to enable as much of the functionality
>> as possible.
>>
>> Retain PV_SHIM_EXCLUSIVE as a prompt-less option such that first of all
>> C code using it can remain as is. This isn't just for less code churn,
>> but also because I think that symbol is more logical to use in many
>> (all?) places.
>>
>> Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>
>> ---
>> The new Kconfig control's name is up for improvement suggestions, but I
>> think it's already better than the originally thought of
>> FULL_HYPERVISOR.
> 
> I think the approach in general is OK, maybe we can improve the naming
> further. What about one of the following?
> 
> NO_PV_SHIM_EXCLUSIVE
> PV_SHIM_NOT_EXCLUSIVE
> ADD_PV_SHIM
> PV_SHIM_AND_HYPERVISOR
> 
> This is because I think the option should be tied to PV_SHIM. Keep in
> mind that users are supposed to be able to use "make menuconfig" and
> pick good options based on the menu. An option called UNCONSTRAINED or
> FULL_HYPERVISOR or any other name that has nothing to do with PV_SHIM is
> very confusing to me.

Hmm. That was actually something I was specifically trying to avoid. Imo
the connection to the shim only wants making in the help text. And I fear
I view all your naming suggestions as hard to grok.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Jan 17 09:48:16 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Jan 2025 09:48:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873944.1284850 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYixO-0002wM-HI; Fri, 17 Jan 2025 09:48:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873944.1284850; Fri, 17 Jan 2025 09:48:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYixO-0002wF-Dg; Fri, 17 Jan 2025 09:48:02 +0000
Received: by outflank-mailman (input) for mailman id 873944;
 Fri, 17 Jan 2025 09:48:01 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=qJiU=UJ=redhat.com=vschneid@srs-se1.protection.inumbo.net>)
 id 1tYixM-0002w9-UD
 for xen-devel@lists.xenproject.org; Fri, 17 Jan 2025 09:48:00 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.129.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 219d00f6-d4b8-11ef-a0e2-8be0dac302b0;
 Fri, 17 Jan 2025 10:47:58 +0100 (CET)
Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com
 [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-113-DOgDMzT-OCm8bYKou_wLEg-1; Fri, 17 Jan 2025 04:47:55 -0500
Received: by mail-wm1-f72.google.com with SMTP id
 5b1f17b1804b1-4361eb83f46so13349995e9.3
 for <xen-devel@lists.xenproject.org>; Fri, 17 Jan 2025 01:47:54 -0800 (PST)
Received: from vschneid-thinkpadt14sgen2i.remote.csb
 (213-44-141-166.abo.bbox.fr. [213.44.141.166])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438904131f5sm27135155e9.11.2025.01.17.01.47.50
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 17 Jan 2025 01:47:52 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 219d00f6-d4b8-11ef-a0e2-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1737107277;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=VvR9KfuLK5jT/0k1YGBwcApH+9cF5PsvBxGMV+DYi4c=;
	b=DHBRYnQclWBz29AczmtdH2psrHQWNAp2LDJjwl32uDPBUSGvi1VCdiDO7Zu95RYG4y3OpB
	9Tebjf3WoGAbLJ64WOQ9vzSA4BycUOWy/bKAHOHksNptStG7BmNFug3JbEo5RGgIFyw1yE
	ZQ5x15X5d61OUrj/+AN5FwVAZ+jtRyE=
X-MC-Unique: DOgDMzT-OCm8bYKou_wLEg-1
X-Mimecast-MFC-AGG-ID: DOgDMzT-OCm8bYKou_wLEg
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737107274; x=1737712074;
        h=mime-version:message-id:date:references:in-reply-to:subject:cc:to
         :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=VvR9KfuLK5jT/0k1YGBwcApH+9cF5PsvBxGMV+DYi4c=;
        b=oxmTON5xHZVXjXzsSXQ6YAwA3NeW6tgVP/J6eD+Frt+OUC15fUHDDqtPrAuoQ/6sVY
         nSL1dTkkwwIr69JV3auNPbmRYoMa7/FUjH8WL5GwuCD16EDVI6yGX3GcOTIhfbLjVuAm
         vTBPa0Cgb6IwBTmkbUsippHbfr/pdZwOIJ1szl/rfvSXflNsyR2V4rMCUhLN5hD5Wrnh
         rHQ8Ifqcl5K20Fu3KJJsJ5eFpLoPf4heSL142VV5VqTHikNyyitAefZjqnVtuo6ilB1y
         nqf7eh0Tj5nY52jD3v9AL0D1WubKqITpjpwNC7QFQVV+2YYF+qGgKp+HvtmiAS6EgEsi
         uY2Q==
X-Forwarded-Encrypted: i=1; AJvYcCXh3cwGNUEUQdLwyXXUShnKcsEHUjx9ZjA8ekZMnHvdONMMyMvDuBoREsisjW/6oFyo2vN3vQarbuw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwbaKuHq6sfOQjW2kDchdHs24RSW9RTQFLm5Ba9XoN/mEEwfOPW
	BSEFiMdMA1VvPFhOBw5gQ+eFA6iiCKS8n2qXOHSfv1o3Oo2TUubumV2vNva5XgPfe0MYgVLIU2h
	VaBef8ebor18wZmiH15meXd2tY0F10/h4qhDhiEMU5lRICfUurl9/1ZwZYiFhKofj
X-Gm-Gg: ASbGncuIEhQJjh3F9Sx/4xql+G7GvuiiT0R7b506uBfIAoBZNm+lzRgk8jm9GLBoSo4
	3ZrxynI/XknVxeJObrqqaHTuH46lFhrH8xOULbGT8XF3tKaMHOeWdtwuIZvlkEb94pVs13Fm+vK
	gQaGuLFPz3rfbKFAY4HWqOONIHWvOMMfS1V3jPuM47Ko4yy4Aj2RRVGdhDCyphAZ/HHdtJXMGdY
	U8LsljYc6/WWGPCvDe4v1WhhaoFU29H9Z/caAqwR3/9dQ+R31hElTgm5BbXP+ObTrdNzVt77dFI
	AKhWfdkftWiPK1t5xsIbEcV9/NwUr585BghcyOKXIw==
X-Received: by 2002:a05:600c:9a3:b0:434:fa73:a907 with SMTP id 5b1f17b1804b1-4389191b819mr16314055e9.13.1737107273772;
        Fri, 17 Jan 2025 01:47:53 -0800 (PST)
X-Google-Smtp-Source: AGHT+IHToHDxXT5KMOIEW1byUZUSn/LchRidR5pJg2ZFHbUxu07B2Q/njknWrWkjTXhDYHkp8NfwWQ==
X-Received: by 2002:a05:600c:9a3:b0:434:fa73:a907 with SMTP id 5b1f17b1804b1-4389191b819mr16313255e9.13.1737107273291;
        Fri, 17 Jan 2025 01:47:53 -0800 (PST)
From: Valentin Schneider <vschneid@redhat.com>
To: Sean Christopherson <seanjc@google.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
 virtualization@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
 loongarch@lists.linux.dev, linux-riscv@lists.infradead.org,
 linux-perf-users@vger.kernel.org, xen-devel@lists.xenproject.org,
 kvm@vger.kernel.org, linux-arch@vger.kernel.org, rcu@vger.kernel.org,
 linux-hardening@vger.kernel.org, linux-mm@kvack.org,
 linux-kselftest@vger.kernel.org, bpf@vger.kernel.org,
 bcm-kernel-feedback-list@broadcom.com, Peter Zijlstra
 <peterz@infradead.org>, Nicolas Saenz Julienne <nsaenzju@redhat.com>,
 Juergen Gross <jgross@suse.com>, Ajay Kaher <ajay.kaher@broadcom.com>,
 Alexey Makhalov <alexey.amakhalov@broadcom.com>, Russell King
 <linux@armlinux.org.uk>, Catalin Marinas <catalin.marinas@arm.com>, Will
 Deacon <will@kernel.org>, Huacai Chen <chenhuacai@kernel.org>, WANG Xuerui
 <kernel@xen0n.name>, Paul Walmsley <paul.walmsley@sifive.com>, Palmer
 Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>, Thomas
 Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, Borislav
 Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, "H.
 Peter Anvin" <hpa@zytor.com>, Arnaldo Carvalho de Melo <acme@kernel.org>,
 Namhyung Kim <namhyung@kernel.org>, Mark Rutland <mark.rutland@arm.com>,
 Alexander Shishkin <alexander.shishkin@linux.intel.com>, Jiri Olsa
 <jolsa@kernel.org>, Ian Rogers <irogers@google.com>, Adrian Hunter
 <adrian.hunter@intel.com>, Kan Liang <kan.liang@linux.intel.com>, Boris
 Ostrovsky <boris.ostrovsky@oracle.com>, Josh Poimboeuf
 <jpoimboe@kernel.org>, Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
 Paolo Bonzini <pbonzini@redhat.com>, Andy Lutomirski <luto@kernel.org>,
 Arnd Bergmann <arnd@arndb.de>, Frederic Weisbecker <frederic@kernel.org>,
 "Paul E. McKenney" <paulmck@kernel.org>, Jason Baron <jbaron@akamai.com>,
 Steven Rostedt <rostedt@goodmis.org>, Ard Biesheuvel <ardb@kernel.org>,
 Neeraj Upadhyay <neeraj.upadhyay@kernel.org>, Joel Fernandes
 <joel@joelfernandes.org>, Josh Triplett <josh@joshtriplett.org>, Boqun
 Feng <boqun.feng@gmail.com>, Uladzislau Rezki <urezki@gmail.com>, Mathieu
 Desnoyers <mathieu.desnoyers@efficios.com>, Lai Jiangshan
 <jiangshanlai@gmail.com>, Zqiang <qiang.zhang1211@gmail.com>, Juri Lelli
 <juri.lelli@redhat.com>, Clark Williams <williams@redhat.com>, Yair
 Podemsky <ypodemsk@redhat.com>, Tomas Glozar <tglozar@redhat.com>, Vincent
 Guittot <vincent.guittot@linaro.org>, Dietmar Eggemann
 <dietmar.eggemann@arm.com>, Ben Segall <bsegall@google.com>, Mel Gorman
 <mgorman@suse.de>, Kees Cook <kees@kernel.org>, Andrew Morton
 <akpm@linux-foundation.org>, Christoph Hellwig <hch@infradead.org>, Shuah
 Khan <shuah@kernel.org>, Sami Tolvanen <samitolvanen@google.com>, Miguel
 Ojeda <ojeda@kernel.org>, Alice Ryhl <aliceryhl@google.com>, "Mike
 Rapoport (Microsoft)" <rppt@kernel.org>, Samuel Holland
 <samuel.holland@sifive.com>, Rong Xu <xur@google.com>, Geert Uytterhoeven
 <geert@linux-m68k.org>, Yosry Ahmed <yosryahmed@google.com>, "Kirill A.
 Shutemov" <kirill.shutemov@linux.intel.com>, "Masami Hiramatsu (Google)"
 <mhiramat@kernel.org>, Jinghao Jia <jinghao7@illinois.edu>, Luis
 Chamberlain <mcgrof@kernel.org>, Randy Dunlap <rdunlap@infradead.org>,
 Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: Re: [PATCH v4 25/30] context_tracking,x86: Defer kernel text
 patching IPIs
In-Reply-To: <Z4bTlZkqihaAyGb4@google.com>
References: <20250114175143.81438-1-vschneid@redhat.com>
 <20250114175143.81438-26-vschneid@redhat.com>
 <Z4bTlZkqihaAyGb4@google.com>
Date: Fri, 17 Jan 2025 10:47:49 +0100
Message-ID: <xhsmhed11hiuy.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
MIME-Version: 1.0
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: oYi4crjaPN1tOE9tpzoh7_hiWhVzH64uureXBywV25w_1737107274
X-Mimecast-Originator: redhat.com
Content-Type: text/plain

On 14/01/25 13:13, Sean Christopherson wrote:
> On Tue, Jan 14, 2025, Valentin Schneider wrote:
>> text_poke_bp_batch() sends IPIs to all online CPUs to synchronize
>> them vs the newly patched instruction. CPUs that are executing in userspace
>> do not need this synchronization to happen immediately, and this is
>> actually harmful interference for NOHZ_FULL CPUs.
>
> ...
>
>> This leaves us with static keys and static calls.
>
> ...
>
>> @@ -2317,11 +2334,20 @@ static void text_poke_bp_batch(struct text_poke_loc *tp, unsigned int nr_entries
>>       * First step: add a int3 trap to the address that will be patched.
>>       */
>>      for (i = 0; i < nr_entries; i++) {
>> -		tp[i].old = *(u8 *)text_poke_addr(&tp[i]);
>> -		text_poke(text_poke_addr(&tp[i]), &int3, INT3_INSN_SIZE);
>> +		void *addr = text_poke_addr(&tp[i]);
>> +
>> +		/*
>> +		 * There's no safe way to defer IPIs for patching text in
>> +		 * .noinstr, record whether there is at least one such poke.
>> +		 */
>> +		if (is_kernel_noinstr_text((unsigned long)addr))
>> +			cond = NULL;
>
> Maybe pre-check "cond", especially if multiple ranges need to be checked?  I.e.
>
>               if (cond && is_kernel_noinstr_text(...))
>> +
>> +		tp[i].old = *((u8 *)addr);
>> +		text_poke(addr, &int3, INT3_INSN_SIZE);
>>      }
>>
>> -	text_poke_sync();
>> +	__text_poke_sync(cond);
>>
>>      /*
>>       * Second step: update all but the first byte of the patched range.
>
> ...
>
>> +/**
>> + * is_kernel_noinstr_text - checks if the pointer address is located in the
>> + *                    .noinstr section
>> + *
>> + * @addr: address to check
>> + *
>> + * Returns: true if the address is located in .noinstr, false otherwise.
>> + */
>> +static inline bool is_kernel_noinstr_text(unsigned long addr)
>> +{
>> +	return addr >= (unsigned long)__noinstr_text_start &&
>> +	       addr < (unsigned long)__noinstr_text_end;
>> +}
>
> This doesn't do the right thing for modules, which matters because KVM can be
> built as a module on x86, and because context tracking understands transitions
> to GUEST mode, i.e. CPUs that are running in a KVM guest will be treated as not
> being in the kernel, and thus will have IPIs deferred.  If KVM uses a static key
> or branch between guest_state_enter_irqoff() and guest_state_exit_irqoff(), the
> patching code won't wait for CPUs to exit guest mode, i.e. KVM could theoretically
> use the wrong static path.
>

AFAICT guest_state_{enter,exit}_irqoff() are only used in noinstr functions
and thus such a static key usage should at the very least be caught and
warned about by objtool - when this isn't built as a module.

I never really thought about noinstr sections for modules; I can get
objtool to warn about a non-noinstr allowed key being used in
e.g. vmx_vcpu_enter_exit() just by feeding it the vmx.o:

arch/x86/kvm/vmx/vmx.o: warning: objtool: vmx_vcpu_enter_exit.isra.0+0x0: dummykey: non-RO static key usage in noinstr

...but that requires removing a lot of code first because objtool stops
earlier in its noinstr checks as it hits functions it doesn't have full
information on, e.g.

arch/x86/kvm/vmx/vmx.o: warning: objtool: vmx_vcpu_enter_exit+0x21c: call to __ct_user_enter() leaves .noinstr.text section

__ct_user_enter() *is* noinstr, but you don't get that from just the header prototype.

> I don't expect this to ever cause problems in practice, because patching code in
> KVM's VM-Enter/VM-Exit path that has *functional* implications, while CPUs are
> actively running guest code, would be all kinds of crazy.  But I do think we
> should plug the hole.
>
> If this issue is unique to KVM, i.e. is not a generic problem for all modules (I
> assume module code generally isn't allowed in the entry path, even via NMI?), one
> idea would be to let KVM register its noinstr section for text poking.



From xen-devel-bounces@lists.xenproject.org Fri Jan 17 09:50:59 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Jan 2025 09:50:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873953.1284859 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYj0E-0004g6-Tb; Fri, 17 Jan 2025 09:50:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873953.1284859; Fri, 17 Jan 2025 09:50:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYj0E-0004fz-Qz; Fri, 17 Jan 2025 09:50:58 +0000
Received: by outflank-mailman (input) for mailman id 873953;
 Fri, 17 Jan 2025 09:50:57 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=qJiU=UJ=redhat.com=vschneid@srs-se1.protection.inumbo.net>)
 id 1tYj0D-0004fo-8a
 for xen-devel@lists.xenproject.org; Fri, 17 Jan 2025 09:50:57 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.129.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8baf2d6e-d4b8-11ef-a0e2-8be0dac302b0;
 Fri, 17 Jan 2025 10:50:56 +0100 (CET)
Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com
 [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-619-H324YN4XP6iEV3aB0zmqYA-1; Fri, 17 Jan 2025 04:50:53 -0500
Received: by mail-wr1-f69.google.com with SMTP id
 ffacd0b85a97d-385e49efd59so844768f8f.0
 for <xen-devel@lists.xenproject.org>; Fri, 17 Jan 2025 01:50:53 -0800 (PST)
Received: from vschneid-thinkpadt14sgen2i.remote.csb
 (213-44-141-166.abo.bbox.fr. [213.44.141.166])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4389046885esm27213805e9.36.2025.01.17.01.50.48
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 17 Jan 2025 01:50:51 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8baf2d6e-d4b8-11ef-a0e2-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1737107455;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=YDQmnZNuWDRDpTPs8hGbe0u4gXPeipncYfFhncsjtPs=;
	b=Efg1gUZ79jxEVw5YbXdYyNzBjM8xfS9nayXJ+V9O+VdSoRqJ5ZYmC/Pp97HRLEAbYBW6Av
	JDhFlV6dpcwGFD6Yf2lrM6Iful/jXFGCeIdz6X0xQf0haYHvh6k/y9F6YNakAB09Scc+LO
	lssds5SRlJryWh26U7wNhtPjNJMB/mM=
X-MC-Unique: H324YN4XP6iEV3aB0zmqYA-1
X-Mimecast-MFC-AGG-ID: H324YN4XP6iEV3aB0zmqYA
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737107452; x=1737712252;
        h=mime-version:message-id:date:references:in-reply-to:subject:cc:to
         :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=YDQmnZNuWDRDpTPs8hGbe0u4gXPeipncYfFhncsjtPs=;
        b=ET9ZTT2Hwcwnf6DgQNiDdKfihR6NWUk8VT0u/7MNdgKRipNILr3rkJ/YLowRF0uFX5
         VkPggR/bTw28o4luP31+rV960vrmJ3jAeIPZv/RMpXDbofhPq32lH35eGPFojfRvOlhx
         6M43fp3vmdNAEndPmpqEOqG7BkXJuZGG8oimaS++3cr9j72kfKqFWfNOqWpe37C5a6Vk
         DfWYzX0uk7C/HdAMtoHGsgD+wkvxvd+fleEyxvJowdDXRZnlJUO/UxzFG2gT9ijfZwWF
         esb2Z+4jWCE8lyIe8RkzChL/F0kAwvUCpnCCbo7AL4OHhWk83XQmjWu98jrLIgL8MRAx
         DYyA==
X-Forwarded-Encrypted: i=1; AJvYcCWbdKp2wrVw6MAf0X0sCNuFKMppRhF6x450p11b3F6EtBL5Op3ZuahAZYhmQEZ9ol50p8x6H056AeU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzGUQV6VfK3VgK9tnZnxZEZmwvwl6fClY/X29+YHwnlWhgW2mTM
	Xo6awTKkNivTbDU0pK8kgD1ayrDr0X6+UueOlvG2y8X9OL6/s0gcBB6JNN+tNDoEb6duEdbnQ5J
	K7SiR2laxJQvsJ2HkHACEnG0/B+Eay5qOW6g6E1BYGdX87OVoB1dkxLiywxxPNjlQ
X-Gm-Gg: ASbGncsgFV8WjuXGTcFe6azqfe43MNexKAl7RQ3v2lFYqCaNlNi1wsIlRb+qZkG0hxc
	0wUZwCd42Oe2gXaLB/trbPxTfkBFcqXLiWoFrv0uGpGNSTPB8YzzxA+TrWaRermXqnHvJ8aUPd9
	g2/Qj4T7Z3mbwsDueFSAf34iotNTMMmxOK1OGf9Ht5XA1p2d48p6eYelEDFUBQRI8Rppv2/627h
	rBdaxzxFdZottDSPzUvpWo7/FuamRPqQQNaqB1o4fH2anZlI8nb7mT1otRH/xqiIO8d5KnS/Ii6
	KDlyzJVtZhVi8v2km/KF/MNUy9V6bB0ehD/C1/lh2A==
X-Received: by 2002:a05:600c:4894:b0:434:a7e7:a1ca with SMTP id 5b1f17b1804b1-43891427762mr17119665e9.20.1737107452062;
        Fri, 17 Jan 2025 01:50:52 -0800 (PST)
X-Google-Smtp-Source: AGHT+IFIrTJfr3xbQQG9oIc57+hAZrhxLTFv7PUY9ukHOiTt7KK/CefEP4sOd+O4YFea/uwaauu8yg==
X-Received: by 2002:a05:600c:4894:b0:434:a7e7:a1ca with SMTP id 5b1f17b1804b1-43891427762mr17118965e9.20.1737107451685;
        Fri, 17 Jan 2025 01:50:51 -0800 (PST)
From: Valentin Schneider <vschneid@redhat.com>
To: Sean Christopherson <seanjc@google.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
 virtualization@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
 loongarch@lists.linux.dev, linux-riscv@lists.infradead.org,
 linux-perf-users@vger.kernel.org, xen-devel@lists.xenproject.org,
 kvm@vger.kernel.org, linux-arch@vger.kernel.org, rcu@vger.kernel.org,
 linux-hardening@vger.kernel.org, linux-mm@kvack.org,
 linux-kselftest@vger.kernel.org, bpf@vger.kernel.org,
 bcm-kernel-feedback-list@broadcom.com, Josh Poimboeuf
 <jpoimboe@kernel.org>, Juergen Gross <jgross@suse.com>, Ajay Kaher
 <ajay.kaher@broadcom.com>, Alexey Makhalov
 <alexey.amakhalov@broadcom.com>, Russell King <linux@armlinux.org.uk>,
 Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>,
 Huacai Chen <chenhuacai@kernel.org>, WANG Xuerui <kernel@xen0n.name>, Paul
 Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>,
 Albert Ou <aou@eecs.berkeley.edu>, Thomas Gleixner <tglx@linutronix.de>,
 Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Dave
 Hansen <dave.hansen@linux.intel.com>, "H. Peter Anvin" <hpa@zytor.com>,
 Peter Zijlstra <peterz@infradead.org>, Arnaldo Carvalho de Melo
 <acme@kernel.org>, Namhyung Kim <namhyung@kernel.org>, Mark Rutland
 <mark.rutland@arm.com>, Alexander Shishkin
 <alexander.shishkin@linux.intel.com>, Jiri Olsa <jolsa@kernel.org>, Ian
 Rogers <irogers@google.com>, Adrian Hunter <adrian.hunter@intel.com>, Kan
 Liang <kan.liang@linux.intel.com>, Boris Ostrovsky
 <boris.ostrovsky@oracle.com>, Pawan Gupta
 <pawan.kumar.gupta@linux.intel.com>, Paolo Bonzini <pbonzini@redhat.com>,
 Andy Lutomirski <luto@kernel.org>, Arnd Bergmann <arnd@arndb.de>, Frederic
 Weisbecker <frederic@kernel.org>, "Paul E. McKenney" <paulmck@kernel.org>,
 Jason Baron <jbaron@akamai.com>, Steven Rostedt <rostedt@goodmis.org>, Ard
 Biesheuvel <ardb@kernel.org>, Neeraj Upadhyay
 <neeraj.upadhyay@kernel.org>, Joel Fernandes <joel@joelfernandes.org>,
 Josh Triplett <josh@joshtriplett.org>, Boqun Feng <boqun.feng@gmail.com>,
 Uladzislau Rezki <urezki@gmail.com>, Mathieu Desnoyers
 <mathieu.desnoyers@efficios.com>, Lai Jiangshan <jiangshanlai@gmail.com>,
 Zqiang <qiang.zhang1211@gmail.com>, Juri Lelli <juri.lelli@redhat.com>,
 Clark Williams <williams@redhat.com>, Yair Podemsky <ypodemsk@redhat.com>,
 Tomas Glozar <tglozar@redhat.com>, Vincent Guittot
 <vincent.guittot@linaro.org>, Dietmar Eggemann <dietmar.eggemann@arm.com>,
 Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>, Kees Cook
 <kees@kernel.org>, Andrew Morton <akpm@linux-foundation.org>, Christoph
 Hellwig <hch@infradead.org>, Shuah Khan <shuah@kernel.org>, Sami Tolvanen
 <samitolvanen@google.com>, Miguel Ojeda <ojeda@kernel.org>, Alice Ryhl
 <aliceryhl@google.com>, "Mike Rapoport (Microsoft)" <rppt@kernel.org>,
 Samuel Holland <samuel.holland@sifive.com>, Rong Xu <xur@google.com>,
 Nicolas Saenz Julienne <nsaenzju@redhat.com>, Geert Uytterhoeven
 <geert@linux-m68k.org>, Yosry Ahmed <yosryahmed@google.com>, "Kirill A.
 Shutemov" <kirill.shutemov@linux.intel.com>, "Masami Hiramatsu (Google)"
 <mhiramat@kernel.org>, Jinghao Jia <jinghao7@illinois.edu>, Luis
 Chamberlain <mcgrof@kernel.org>, Randy Dunlap <rdunlap@infradead.org>,
 Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: Re: [PATCH v4 18/30] x86/kvm/vmx: Mark vmx_l1d_should flush and
 vmx_l1d_flush_cond keys as allowed in .noinstr
In-Reply-To: <Z4bU2xlZXh53lgH6@google.com>
References: <20250114175143.81438-1-vschneid@redhat.com>
 <20250114175143.81438-19-vschneid@redhat.com>
 <Z4bU2xlZXh53lgH6@google.com>
Date: Fri, 17 Jan 2025 10:50:48 +0100
Message-ID: <xhsmhbjw5hipz.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
MIME-Version: 1.0
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: cuUX9thPxz3bWF2MBfOtzwtBE_ZoqfPhzMKyzvp9td0_1737107452
X-Mimecast-Originator: redhat.com
Content-Type: text/plain

On 14/01/25 13:19, Sean Christopherson wrote:
> Please use "KVM: VMX:" for the scope.
>
> On Tue, Jan 14, 2025, Valentin Schneider wrote:
>> Later commits will cause objtool to warn about static keys being used in
>> .noinstr sections in order to safely defer instruction patching IPIs
>> targeted at NOHZ_FULL CPUs.
>>
>> These keys are used in .noinstr code, and can be modified at runtime
>> (/proc/kernel/vmx* write). However it is not expected that they will be
>> flipped during latency-sensitive operations, and thus shouldn't be a source
>> of interference wrt the text patching IPI.
>
> This misses KVM's static key that's buried behind CONFIG_HYPERV=m|y.
>
> vmlinux.o: warning: objtool: vmx_vcpu_enter_exit+0x241: __kvm_is_using_evmcs: non-RO static key usage in noinstr
> vmlinux.o: warning: objtool: vmx_update_host_rsp+0x13: __kvm_is_using_evmcs: non-RO static key usage in noinstr
>

Thanks, I'll add these to v5.

> Side topic, it's super annoying that "objtool --noinstr" only runs on vmlinux.o.
> I realize objtool doesn't have the visilibity to validate cross-object calls,
> but couldn't objtool validates calls and static key/branch usage so long as the
> target or key/branch is defined in the same object?

Per my testing you can manually run it on individual objects, but it can
and will easily get hung up on the first noinstr violation it finds and not
search further within one given function.



From xen-devel-bounces@lists.xenproject.org Fri Jan 17 09:54:30 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Jan 2025 09:54:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873960.1284869 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYj3a-0005FW-C5; Fri, 17 Jan 2025 09:54:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873960.1284869; Fri, 17 Jan 2025 09:54:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYj3a-0005FP-8O; Fri, 17 Jan 2025 09:54:26 +0000
Received: by outflank-mailman (input) for mailman id 873960;
 Fri, 17 Jan 2025 09:54:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=qJiU=UJ=redhat.com=vschneid@srs-se1.protection.inumbo.net>)
 id 1tYj3Y-0005FJ-Bg
 for xen-devel@lists.xenproject.org; Fri, 17 Jan 2025 09:54:24 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 06531c2c-d4b9-11ef-99a4-01e77a169b0f;
 Fri, 17 Jan 2025 10:54:22 +0100 (CET)
Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com
 [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-642-RRpvVdpsN1KByxlo0sVCYg-1; Fri, 17 Jan 2025 04:54:16 -0500
Received: by mail-wm1-f70.google.com with SMTP id
 5b1f17b1804b1-43626224274so9700805e9.0
 for <xen-devel@lists.xenproject.org>; Fri, 17 Jan 2025 01:54:16 -0800 (PST)
Received: from vschneid-thinkpadt14sgen2i.remote.csb
 (213-44-141-166.abo.bbox.fr. [213.44.141.166])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-43890420412sm28393455e9.18.2025.01.17.01.54.11
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 17 Jan 2025 01:54:14 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 06531c2c-d4b9-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1737107660;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=L9Oe7BkLz3ZQnhnrUC9eWHjE3nyj6wgCJoWV2O/5t40=;
	b=LE8U3DmT3gzpsSVFq0G5WDH9SYgbFj6TVLii4ma06aBuEWYVYd2eJNuxPkNLvfsYiqJuu3
	SaD/zTjPzp/QiCEAsfHKsreZ/8YCg/VmwgRRQJ/eh+c2PIGcZaqG9z/hNRVmWS1ohVGyie
	d/a/zXCy9UjF3/6QPXwk8EnEFj9v3vA=
X-MC-Unique: RRpvVdpsN1KByxlo0sVCYg-1
X-Mimecast-MFC-AGG-ID: RRpvVdpsN1KByxlo0sVCYg
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737107655; x=1737712455;
        h=mime-version:message-id:date:references:in-reply-to:subject:cc:to
         :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=L9Oe7BkLz3ZQnhnrUC9eWHjE3nyj6wgCJoWV2O/5t40=;
        b=ccGM+ybYAi1kNiPgSSdJp4KS7OHkGsqoY1jOqdOLhk/XvRsMxtCUsXe8snF6Q0LgTs
         wk6YxckJKrqH9JEHSaLK9djNSUBBn84vk2y68dOhOrIXsPzX9JeiPZf2kHVGxe+6IHmH
         hEnZLVTl9NkNC7se/UpfwQxkD+ez2Lubcvh90wOGXu3o45/3dnb0offnEbCKWZOxeaqy
         w8Kdkow8qj1UY8JePLB5Y4eZjnubD8VfzZC+etAdfdiLGDqLxC6RTFjS4iTPj1YmIGKu
         5soLFUMKHTT++UMGBfvkxKvA7yyoN5tI7TlCskZMpcHrInmyf7D13xLpEeT6pqhwAiGc
         Q57A==
X-Forwarded-Encrypted: i=1; AJvYcCV5kLOwfSrV002s7C2KxB1+1JqC+tpveYKjjeKYwm5/IbISm/hep36ql7/QO2UjISEuvac6WgQxScw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzHUy8UammxdIh3DOiyKpwNth+3i8TKZb1mLIRYQb1zw8SLmnqw
	fdl9Q0upL3oIK0TBaHHqxDJec/AOyhLOOJ9VwIkCSExKSO/W5CHyjzWga+qXtng339PsCS2/Ush
	9PQZ/bKwYJ/SnG0StRJV5a4yshdNm7qub4GBU6Z/KmbTRAzBNlQ6sEHLue+uk4HHZ
X-Gm-Gg: ASbGncstXdO28LOu8fC4d8qY1kq2NWqpS/gaJbrkHu37i9rOEJzy+uJ9hTusG37mGfk
	sBXSkbRv8gUOlO5d/KEzEdertz7z5yf2fG3vEtTqbq+Cx8I9esr4myBYPLZIfTqP+4QOwdFmkiX
	DQoIYUwG0SgMkli2hZ9xh7XnbMk6FuFgp1n1fFbDYbhHNbLof8c08Xd2kl0KhOrAM68XDBk3bjX
	IZiILwFuE6tJvG19xvsv7q6KDvlcwe0I0tf5PyoSP5vwWraYfpF/ImB/YedlOXoWS5UxFRB3591
	PCyIsSWnd0iE8Kv7yO2Pimzc0o30yXhyYfaYm7InBA==
X-Received: by 2002:a05:600c:450d:b0:436:840b:261c with SMTP id 5b1f17b1804b1-438914340afmr16339345e9.19.1737107655075;
        Fri, 17 Jan 2025 01:54:15 -0800 (PST)
X-Google-Smtp-Source: AGHT+IFuw6rUkDZiEIMePly7ic4RGfvY46wjcWihk2kMpcZz3D30VqRFOYeHlJ+bekZM5WnBbSAhfQ==
X-Received: by 2002:a05:600c:450d:b0:436:840b:261c with SMTP id 5b1f17b1804b1-438914340afmr16338925e9.19.1737107654599;
        Fri, 17 Jan 2025 01:54:14 -0800 (PST)
From: Valentin Schneider <vschneid@redhat.com>
To: Sean Christopherson <seanjc@google.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
 virtualization@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
 loongarch@lists.linux.dev, linux-riscv@lists.infradead.org,
 linux-perf-users@vger.kernel.org, xen-devel@lists.xenproject.org,
 kvm@vger.kernel.org, linux-arch@vger.kernel.org, rcu@vger.kernel.org,
 linux-hardening@vger.kernel.org, linux-mm@kvack.org,
 linux-kselftest@vger.kernel.org, bpf@vger.kernel.org,
 bcm-kernel-feedback-list@broadcom.com, Peter Zijlstra
 <peterz@infradead.org>, Nicolas Saenz Julienne <nsaenzju@redhat.com>,
 Juergen Gross <jgross@suse.com>, Ajay Kaher <ajay.kaher@broadcom.com>,
 Alexey Makhalov <alexey.amakhalov@broadcom.com>, Russell King
 <linux@armlinux.org.uk>, Catalin Marinas <catalin.marinas@arm.com>, Will
 Deacon <will@kernel.org>, Huacai Chen <chenhuacai@kernel.org>, WANG Xuerui
 <kernel@xen0n.name>, Paul Walmsley <paul.walmsley@sifive.com>, Palmer
 Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>, Thomas
 Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, Borislav
 Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, "H.
 Peter Anvin" <hpa@zytor.com>, Arnaldo Carvalho de Melo <acme@kernel.org>,
 Namhyung Kim <namhyung@kernel.org>, Mark Rutland <mark.rutland@arm.com>,
 Alexander Shishkin <alexander.shishkin@linux.intel.com>, Jiri Olsa
 <jolsa@kernel.org>, Ian Rogers <irogers@google.com>, Adrian Hunter
 <adrian.hunter@intel.com>, Kan Liang <kan.liang@linux.intel.com>, Boris
 Ostrovsky <boris.ostrovsky@oracle.com>, Josh Poimboeuf
 <jpoimboe@kernel.org>, Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
 Paolo Bonzini <pbonzini@redhat.com>, Andy Lutomirski <luto@kernel.org>,
 Arnd Bergmann <arnd@arndb.de>, Frederic Weisbecker <frederic@kernel.org>,
 "Paul E. McKenney" <paulmck@kernel.org>, Jason Baron <jbaron@akamai.com>,
 Steven Rostedt <rostedt@goodmis.org>, Ard Biesheuvel <ardb@kernel.org>,
 Neeraj Upadhyay <neeraj.upadhyay@kernel.org>, Joel Fernandes
 <joel@joelfernandes.org>, Josh Triplett <josh@joshtriplett.org>, Boqun
 Feng <boqun.feng@gmail.com>, Uladzislau Rezki <urezki@gmail.com>, Mathieu
 Desnoyers <mathieu.desnoyers@efficios.com>, Lai Jiangshan
 <jiangshanlai@gmail.com>, Zqiang <qiang.zhang1211@gmail.com>, Juri Lelli
 <juri.lelli@redhat.com>, Clark Williams <williams@redhat.com>, Yair
 Podemsky <ypodemsk@redhat.com>, Tomas Glozar <tglozar@redhat.com>, Vincent
 Guittot <vincent.guittot@linaro.org>, Dietmar Eggemann
 <dietmar.eggemann@arm.com>, Ben Segall <bsegall@google.com>, Mel Gorman
 <mgorman@suse.de>, Kees Cook <kees@kernel.org>, Andrew Morton
 <akpm@linux-foundation.org>, Christoph Hellwig <hch@infradead.org>, Shuah
 Khan <shuah@kernel.org>, Sami Tolvanen <samitolvanen@google.com>, Miguel
 Ojeda <ojeda@kernel.org>, Alice Ryhl <aliceryhl@google.com>, "Mike
 Rapoport (Microsoft)" <rppt@kernel.org>, Samuel Holland
 <samuel.holland@sifive.com>, Rong Xu <xur@google.com>, Geert Uytterhoeven
 <geert@linux-m68k.org>, Yosry Ahmed <yosryahmed@google.com>, "Kirill A.
 Shutemov" <kirill.shutemov@linux.intel.com>, "Masami Hiramatsu (Google)"
 <mhiramat@kernel.org>, Jinghao Jia <jinghao7@illinois.edu>, Luis
 Chamberlain <mcgrof@kernel.org>, Randy Dunlap <rdunlap@infradead.org>,
 Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: Re: [PATCH v4 25/30] context_tracking,x86: Defer kernel text
 patching IPIs
In-Reply-To: <Z4bbwE8yfg349gBx@google.com>
References: <20250114175143.81438-1-vschneid@redhat.com>
 <20250114175143.81438-26-vschneid@redhat.com>
 <Z4bTlZkqihaAyGb4@google.com> <Z4bbwE8yfg349gBx@google.com>
Date: Fri, 17 Jan 2025 10:54:11 +0100
Message-ID: <xhsmh8qr9hikc.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
MIME-Version: 1.0
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: T5iBU4nXzC_W19XSNyTiNppodYyylKxNWJ8k2mPFb8Y_1737107655
X-Mimecast-Originator: redhat.com
Content-Type: text/plain

On 14/01/25 13:48, Sean Christopherson wrote:
> On Tue, Jan 14, 2025, Sean Christopherson wrote:
>> On Tue, Jan 14, 2025, Valentin Schneider wrote:
>> > +/**
>> > + * is_kernel_noinstr_text - checks if the pointer address is located in the
>> > + *                    .noinstr section
>> > + *
>> > + * @addr: address to check
>> > + *
>> > + * Returns: true if the address is located in .noinstr, false otherwise.
>> > + */
>> > +static inline bool is_kernel_noinstr_text(unsigned long addr)
>> > +{
>> > +	return addr >= (unsigned long)__noinstr_text_start &&
>> > +	       addr < (unsigned long)__noinstr_text_end;
>> > +}
>>
>> This doesn't do the right thing for modules, which matters because KVM can be
>> built as a module on x86, and because context tracking understands transitions
>> to GUEST mode, i.e. CPUs that are running in a KVM guest will be treated as not
>> being in the kernel, and thus will have IPIs deferred.  If KVM uses a static key
>> or branch between guest_state_enter_irqoff() and guest_state_exit_irqoff(), the
>> patching code won't wait for CPUs to exit guest mode, i.e. KVM could theoretically
>> use the wrong static path.
>>
>> I don't expect this to ever cause problems in practice, because patching code in
>> KVM's VM-Enter/VM-Exit path that has *functional* implications, while CPUs are
>> actively running guest code, would be all kinds of crazy.  But I do think we
>> should plug the hole.
>>
>> If this issue is unique to KVM, i.e. is not a generic problem for all modules (I
>> assume module code generally isn't allowed in the entry path, even via NMI?), one
>> idea would be to let KVM register its noinstr section for text poking.
>
> Another idea would be to track which keys/branches are tagged noinstr, i.e. generate
> the information at compile time instead of doing lookups at runtime.  The biggest
> downside I can think of is that it would require plumbing in the information to
> text_poke_bp_batch().

IIUC that's what I went for in v3:

https://lore.kernel.org/lkml/20241119153502.41361-11-vschneid@redhat.com

but, modules notwithstanding, simply checking if the patched instruction is
in .noinstr was a lot neater.



From xen-devel-bounces@lists.xenproject.org Fri Jan 17 10:31:12 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Jan 2025 10:31:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873980.1284879 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYjd3-0003J9-3d; Fri, 17 Jan 2025 10:31:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873980.1284879; Fri, 17 Jan 2025 10:31:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYjd3-0003J2-0a; Fri, 17 Jan 2025 10:31:05 +0000
Received: by outflank-mailman (input) for mailman id 873980;
 Fri, 17 Jan 2025 10:31:04 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=wado=UJ=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tYjd2-0003H8-DR
 for xen-devel@lists.xenproject.org; Fri, 17 Jan 2025 10:31:04 +0000
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com
 [2a00:1450:4864:20::335])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 26b69b04-d4be-11ef-a0e2-8be0dac302b0;
 Fri, 17 Jan 2025 11:31:03 +0100 (CET)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-43675b1155bso20511515e9.2
 for <xen-devel@lists.xenproject.org>; Fri, 17 Jan 2025 02:31:03 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-43890413801sm28329125e9.15.2025.01.17.02.31.01
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 17 Jan 2025 02:31:02 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 26b69b04-d4be-11ef-a0e2-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737109862; x=1737714662; 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=aWnfsQANsxzXMU5+yYNLa3Ox6UG+PQHS2M8lsUr+nz4=;
        b=WSQ/BMBsh+gLnnaHJ/oBXzxmrQblRmaXFQqgj2tKeu9mYF5GR0m7zeP91tPGSGniU5
         REH42Uyuf04gKvG8WoIIqqf0aKre+VIempQa1MplHsUcAfq5UgPMlSp0i21wXHj8OoDT
         RsNFjFErU1dgsCsEvJYN3ug550uCnobx/ZqZA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737109862; x=1737714662;
        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=aWnfsQANsxzXMU5+yYNLa3Ox6UG+PQHS2M8lsUr+nz4=;
        b=NbeaAAN7erPWu6IupM1uQBcSTHlE+64v9t88ttpIWiFuErwosgbISzKIUPu4jyZ9za
         c55VO/z9BuvJ6qCXs1gRorUq0axX/K5jutH7DrdVuRHwLCwab12DDDmhauPfWjhl2Vnd
         fRaM6IxZZEXMBMt5ArEDRc2HesiPWekq9TTp7BwGbSNr34XOfVwt61lSDLw8q7969ROl
         YOP2WnRgqfl8AQWTyuauxP0kk0PFfi9z9uKgQN8GvLt2gh4eJlz2tt5b5Jl/wSK21d36
         PVkcznsFCP0c3Yis7cubLEmK7DvB58JUUwDQNT/ccVonixwHvgINHrzZeZqVISqEbKGo
         f32Q==
X-Forwarded-Encrypted: i=1; AJvYcCUHKsgsxCkwp1GD/EUIsMtOPoisanGyFkl6fjnmtshrjMlbqd4KVjr3qGpW3nX4C70MPVQR9QdPCqs=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw8Tg813oEF6LGnwKNthbDrgmhEl66J1pGAXoW593GXYNGS/eaL
	1rNE3fdvHf6uiGxFcheZL2cHtM7aFxdopeMJQh3hpJ55cm6Qn8gn+tKhtH0r7qQ=
X-Gm-Gg: ASbGncv5sgytdaV/MSJkDvaRdlUTc/HFJ8g3x/LaMLtBa/fWB5FZx+EOUZeW6Pj79sc
	YVmKeDYeeFgqwcr5wGiNJKznHiC0zLj1728ztGz/FxNTh8RUl1PN4Wxwjl4e+AMPSjB6UUaWpov
	tPbshHbfGG2fNgWYydrem+u3hHlCBxJKkjwWtl7mi2j91L3c8VRjGOURJs87bzWYyiJFcMWGogJ
	hUwNcZoEyL5z1Xg17QvVCbuO3uYiNhZ27hkTiy366D0j2MUmvzPZ/uhP8vWnA==
X-Google-Smtp-Source: AGHT+IEo+Qxb9n8ExU9BaXNNFMwfhk7Dy9TIAKl2hbzARFWejH53KYJHc1VJzhokTtaFMB/pYmDtUg==
X-Received: by 2002:a05:600c:4fd6:b0:436:18e5:6917 with SMTP id 5b1f17b1804b1-438912d3aa3mr22055875e9.0.1737109862550;
        Fri, 17 Jan 2025 02:31:02 -0800 (PST)
Date: Fri, 17 Jan 2025 11:31:01 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: Jan Beulich <jbeulich@suse.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Julien Grall <julien@xen.org>, Wei Liu <wl@xen.org>,
	sergiy_kibrik@epam.com
Subject: Re: [PATCH v2 1/4] x86: provide an inverted Kconfig control for
 shim-exclusive mode
Message-ID: <Z4oxZSUQ6VARiR0H@macbook.local>
References: <da5f5bac-6d5d-092d-d872-f1120dcd2661@suse.com>
 <617842e1-8ef2-b095-0c52-c2e2e5f1c0a8@suse.com>
 <alpine.DEB.2.22.394.2501161503120.2684657@ubuntu-linux-20-04-desktop>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.22.394.2501161503120.2684657@ubuntu-linux-20-04-desktop>

On Thu, Jan 16, 2025 at 04:31:46PM -0800, Stefano Stabellini wrote:
> On Wed, 1 Mar 2023, Jan Beulich wrote:
> > While we want certain things turned off in shim-exclusive mode, doing
> > so via "depends on !PV_SHIM_EXCLUSIVE" badly affects allyesconfig: Since
> > that will turn on PV_SHIM_EXCLUSIVE, other options will be turned off as
> > a result. Yet allyesconfig wants to enable as much of the functionality
> > as possible.
> > 
> > Retain PV_SHIM_EXCLUSIVE as a prompt-less option such that first of all
> > C code using it can remain as is. This isn't just for less code churn,
> > but also because I think that symbol is more logical to use in many
> > (all?) places.
> > 
> > Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
> > Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >
> > ---
> > The new Kconfig control's name is up for improvement suggestions, but I
> > think it's already better than the originally thought of
> > FULL_HYPERVISOR.
> 
> I think the approach in general is OK, maybe we can improve the naming
> further. What about one of the following?
> 
> NO_PV_SHIM_EXCLUSIVE
> PV_SHIM_NOT_EXCLUSIVE

IMO negated options are confusing, and if possible I think we should
avoid using them unless strictly necessary.

I for example always considered extremely confusing that previous to
having CONFIG_DEBUG Xen used NDEBUG (so no debug) as a way to signal
debug vs non-debug builds.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jan 17 10:40:21 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Jan 2025 10:40:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.873990.1284890 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYjlx-00059A-Uh; Fri, 17 Jan 2025 10:40:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 873990.1284890; Fri, 17 Jan 2025 10:40:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYjlx-000593-RG; Fri, 17 Jan 2025 10:40:17 +0000
Received: by outflank-mailman (input) for mailman id 873990;
 Fri, 17 Jan 2025 10:40:17 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=wado=UJ=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tYjlx-00058x-6S
 for xen-devel@lists.xenproject.org; Fri, 17 Jan 2025 10:40:17 +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 7031a7d8-d4bf-11ef-a0e2-8be0dac302b0;
 Fri, 17 Jan 2025 11:40:15 +0100 (CET)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-385e3621518so871965f8f.1
 for <xen-devel@lists.xenproject.org>; Fri, 17 Jan 2025 02:40:15 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38bf327e118sm2118050f8f.82.2025.01.17.02.40.13
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 17 Jan 2025 02:40:14 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 7031a7d8-d4bf-11ef-a0e2-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737110415; x=1737715215; 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=7mwTTuad42S1rQBszQTQ89Dyk+uWIrWT74aPH7+8FQo=;
        b=IOE07+0cHWb+Hpiuuv7WqeiXOQ+FCjHAC2TWHC/4T8YpyCsaL5hE0Ckwicq/ko04Wo
         hib/WggkCrSWvdwR7+4OKpgb8GEddWI6I9vV9ImHY9oK1EFoTplegdzSBQJRXhVF4nlR
         SmiYXQlCEU1hDmthaFBHJdE4aIHUcaJS1zkt8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737110415; x=1737715215;
        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=7mwTTuad42S1rQBszQTQ89Dyk+uWIrWT74aPH7+8FQo=;
        b=Vc8TIQyEomIP6P7OZd1ozAOjx4DzvNkgWZdib00ShBqKQJkfyYcrpv+loWzNH7askv
         lykCfBjiSAjZuqTzTlLOCpLEuL/AIGFWdSxm/hsh6qkguGKOklhzLviBirS6iN6jko2W
         BqHbAUIl6+ey7gCjRLXMLdPKUyCDEcw0qu/yYrZgDDfcSF4EonAgcrYp+eOwX9IlbejP
         WydmSg9xFUCaQ18xKV1DAgEjZTIAs80Ni7Tjv5QUj4h8OmpOte3A49BWOgBSZtsyp5lD
         lP1RzBWRMu0CWfJwkMNzzhmAFp8iP6KhlMY9Vayv/+xcBaTwqppcU0V52bih1yH7uUPj
         0Y0g==
X-Forwarded-Encrypted: i=1; AJvYcCXiFc2fAbe7TvHOeQHm6iVQD4TpoTM0oA5fSat7R5BKbsQSFl39ewbfiEh6giI82fErotKa7VEZ8YQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxGqzQSc5CRDprfcDJ5/FLGn4fJtlaHv9gycDNR+ZfYYe4oXKP0
	GoULuwCx9x27SlbhauqCB8m/Z+8qwks3FMaMjG34vg9vBaipXilcW18gh2XqwdM=
X-Gm-Gg: ASbGncv3vU4xTDksKpqVW5rhCzpfMNMUe9ufGhMTk8wkjJ/RkeumfHDMVGn4VNArT77
	ne02XGJj+MbMV6TIUTEP9TLXNtXraqs0G1rOT8QDEVrwFYqKHMzCRpQINAA5z7zY2oI2LSjb2YQ
	A0vwlZY+/rxI0TTpKlGBiL8EKq6orHPi17Kg+Vwm1yhXET21waAsGVV0REyURmwXk33Ph0jqWBT
	llTr7GuwgY1P/44quTFcoCcYN+KjSMcpKCZBJoI6d+0G+fJpLNTe1zqgxELPw==
X-Google-Smtp-Source: AGHT+IEd3Voj97QjUCC8T2mznpMxbTLbRdt6fDN/yV+XnZv4JkSA2HFG4hid+6GiGQ53VtTaISRNYg==
X-Received: by 2002:a05:6000:10cd:b0:385:e429:e591 with SMTP id ffacd0b85a97d-38bf566e433mr1658936f8f.23.1737110415311;
        Fri, 17 Jan 2025 02:40:15 -0800 (PST)
Date: Fri, 17 Jan 2025 11:40:12 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jason Andryuk <jason.andryuk@amd.com>
Cc: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
	Jan Beulich <jbeulich@suse.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: Problems in PV dom0 on recent x86 hardware
Message-ID: <Z4ozjKIrT8tEi_wn@macbook.local>
References: <baade0a7-e204-4743-bda1-282df74e5f89@suse.com>
 <d379a900-fd1c-42ca-bc31-071f7fd80d0b@suse.com>
 <ZousjqOAFJgO6681@macbook.local>
 <6101999a-6f88-46cb-b850-af43b364f299@suse.com>
 <7a0a8b1c-69e0-435d-b4f4-7a9d784eab29@amd.com>
 <1f96a355-b0d2-4cc9-a2ae-6d3ab750136d@suse.com>
 <89d7b5a6-e971-4cd0-85df-0dd599d0ba1b@suse.com>
 <7d207d6c-d025-4fbb-8649-9c42224097f5@suse.com>
 <88db3cb6-2b7e-48b2-9bf4-d871067325a0@suse.com>
 <3d6d35ea-5044-4249-a277-0e5aa31ed888@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <3d6d35ea-5044-4249-a277-0e5aa31ed888@amd.com>

On Tue, Jul 09, 2024 at 09:08:11AM -0400, Jason Andryuk wrote:
> On 2024-07-09 06:56, Jürgen Groß wrote:
> > On 09.07.24 09:01, Jan Beulich wrote:
> > > On 09.07.2024 08:36, Jürgen Groß wrote:
> > > > On 09.07.24 08:24, Jan Beulich wrote:
> > > > > On 08.07.2024 23:30, Jason Andryuk wrote:
> > > > > >    From the backtrace, it looks like the immediate case
> > > > > > is just trying to
> > > > > > read a 4-byte version:
> > > > > > 
> > > > > >    >>>> [   44.575541]  ucsi_acpi_dsm+0x53/0x80
> > > > > >    >>>> [   44.575546]  ucsi_acpi_read+0x2e/0x60
> > > > > >    >>>> [   44.575550]  ucsi_register+0x24/0xa0
> > > > > >    >>>> [   44.575555]  ucsi_acpi_probe+0x162/0x1e3
> > > > > > 
> > > > > > int ucsi_register(struct ucsi *ucsi)
> > > > > > {
> > > > > >            int ret;
> > > > > > 
> > > > > >            ret = ucsi->ops->read(ucsi, UCSI_VERSION, &ucsi->version,
> > > > > >                                  sizeof(ucsi->version));
> > > > > > 
> > > > > > ->read being ucsi_acpi_read()
> > > > > > 
> > > > > > However, the driver also appears write to adjacent addresses.
> > > > > 
> > > > > There are also corresponding write functions in the driver, yes, but
> > > > > ucsi_acpi_async_write() (used directly or indirectly) similarly calls
> > > > > ucsi_acpi_dsm(), which wires through to acpi_evaluate_dsm(). That's
> > > > > ACPI object evaluation, which isn't obvious without seeing the
> > > > > involved AML whether it might write said memory region.
> > > > 
> > > > I guess an ACPI dump would help here?
> > > 
> > > Perhaps, yes.
> > 
> > It is available in the bug report:
> > 
> > https://bugzilla.opensuse.org/show_bug.cgi?id=1227301
> 
> After acpixtract & iasl:
> 
> $ grep -ir FEEC *
> dsdt.dsl:   OperationRegion (ECMM, SystemMemory, 0xFEEC2000, 0x0100)
> ssdt16.dsl: OperationRegion (SUSC, SystemMemory, 0xFEEC2100, 0x30)
> 
> 
> from the DSDT:
>     Scope (\_SB.PCI0.LPC0.EC0)
>     {
>         OperationRegion (ECMM, SystemMemory, 0xFEEC2000, 0x0100)
>         Field (ECMM, AnyAcc, Lock, Preserve)
>         {
>             TWBT,   2048
>         }
> 
>         Name (BTBF, Buffer (0x0100)
>         {
>              0x00                                             // .
>         })
>         Method (BTIF, 0, NotSerialized)
>         {
>             BTBF = TWBT /* \_SB_.PCI0.LPC0.EC0_.TWBT */
>             Return (BTBF) /* \_SB_.PCI0.LPC0.EC0_.BTBF */
>         }
>     }
> 
> From SSDT16:
> DefinitionBlock ("", "SSDT", 2, "LENOVO", "UsbCTabl", 0x00000001)
> {
>     External (_SB_.PCI0.LPC0.EC0_, DeviceObj)
> 
>     Scope (\_SB)
>     {
>         OperationRegion (SUSC, SystemMemory, 0xFEEC2100, 0x30)
>         Field (SUSC, ByteAcc, Lock, Preserve)
>         {
> 
> 
> This embedded controller (?) seems to live at 0xfeec2xxx.

I've done some further research on this, and my current hypothesis is
that the region defined in 0xfeec2xxx contains at least the UCSI
shared mailbox, used for communication between ACPI and the OSPM.

This is a regular RAM region (iow: not MMIO), that's used to send and
receive UCSI commands with the mediation of ACPI.

The specification that defines the interface can be found at:

https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/bios-implementation-of-ucsi.pdf

If my suspicion is correct, this is a purely software defined
interface, and hence not related to the chipset or the CPU in any way.

I will attempt to contact Lenovo to figure out which of their systems
place the mailbox in the 0xfeecxxxx range, and how we can detect
this.

I think such memory range should likely be defined in the memory map
with type EfiACPIMemoryNVS, so that we know it's presence and can map
it into the guest.  Otherwise this won't work with PVH dom0.

Regards, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jan 17 12:06:09 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Jan 2025 12:06:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.874015.1284899 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYl6n-0001Ht-Ny; Fri, 17 Jan 2025 12:05:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 874015.1284899; Fri, 17 Jan 2025 12:05:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYl6n-0001Hm-LB; Fri, 17 Jan 2025 12:05:53 +0000
Received: by outflank-mailman (input) for mailman id 874015;
 Fri, 17 Jan 2025 12:05:52 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=rDGL=UJ=invisiblethingslab.com=marmarek@srs-se1.protection.inumbo.net>)
 id 1tYl6m-0001HN-Hg
 for xen-devel@lists.xenproject.org; Fri, 17 Jan 2025 12:05:52 +0000
Received: from fout-b5-smtp.messagingengine.com
 (fout-b5-smtp.messagingengine.com [202.12.124.148])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 63656738-d4cb-11ef-99a4-01e77a169b0f;
 Fri, 17 Jan 2025 13:05:49 +0100 (CET)
Received: from phl-compute-09.internal (phl-compute-09.phl.internal
 [10.202.2.49])
 by mailfout.stl.internal (Postfix) with ESMTP id ACB0C114014A;
 Fri, 17 Jan 2025 07:05:47 -0500 (EST)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-09.internal (MEProxy); Fri, 17 Jan 2025 07:05:47 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri,
 17 Jan 2025 07:05:44 -0500 (EST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 63656738-d4cb-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:message-id:mime-version:reply-to
	:subject:subject:to:to; s=fm2; t=1737115547; x=1737201947; bh=E4
	BKaLgjKwxl3qk+S8d/r25/8ei0FPAdbuCz0wO7smo=; b=tjZfnjVdV4QdGRwsEx
	DS2LMAOMtk8DiwivpYQoZQveZgUTBeCkOwXnvBWYNLUlfOZyxINj4xiRm6DfYVip
	ZPRUU9tT+BVC5q9ARmDvWAxDQgWhE/sVwNM0eSjwo+n6maMgYsRSf94eCihQ1kjv
	9YVkR5oVx10DT3akBe3w5WiXIr/mVyJWzmn+/ti37hgTTfuwo0PJvt94hAM5dYqO
	gSOhq9BBAu/INz+SmDoVxUg738UNeH8sVHGeiEKiVQUbW9dueqEN8/A4dTfOS4Sj
	yApXUW3Fuh/QwgHViOAYqBX6nO1W9T68hZE0NJPHLQ3fqea5yJM5tH4nzNz6sKKI
	+BUg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:message-id
	:mime-version:reply-to:subject:subject:to:to:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1737115547; x=
	1737201947; bh=E4BKaLgjKwxl3qk+S8d/r25/8ei0FPAdbuCz0wO7smo=; b=e
	7Y/W0SY4AGk1J1Qg9sa3BAnCAeTTNk++WFNqgZrMdlvFVxKPusThjMNoHK+odS54
	MqG/tDHrcYUH1co3lxeqgx+4Cw9eK0UptOcrf13GOlI1FeY2NFF2RfwTYnSlqAO7
	3rnDJ/bjvwtQ1Qkm5INUpq5qlqkgzodIt1rdtdzsjQt9EPkZOYAqmZqoMk0MxeNg
	ZjklWlwg4wl0BvuRuomCs7bYLZC8AEoAFRG4oZsHWS8S4srVQ/Y8VHSkLiQcjxke
	SCMopBFP/9TkGO+k2GZpGjnhT7Ij06gq172nnjaeq2d2AkHW6rSNIQzBzfKrk21v
	LLbL9dOBGwHClBwV16f9A==
X-ME-Sender: <xms:mkeKZ7tvasDCMxptcYa8_7KxesDN9FchzTWXK871Yh-5KsnnuzxZxQ>
    <xme:mkeKZ8ewDQBMtS_rRSXzHLuZwZHqaTDz7RESVDrWD-Bwd9RpFr4-7LdMhCH1cDtji
    Z9oJMbXuxojzA>
X-ME-Received: <xmr:mkeKZ-xme9OmWV3NosHuPlo-4-01iUdfFSNvDiEJ5dM6aNqV1-su9bPn3p8stfzw1OUDqhNPFMLjei9AmNtMHmq79Zj993q1hg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrudeifedgfeegucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
    rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
    htshculddquddttddmnecujfgurhepfffhvfevuffkgggtugesghdtreertddtjeenucfh
    rhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrh
    hmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgr
    thhtvghrnhephfetuefhiefgtddtlefggffggeevhedtvdefffeugfeiieeiheefteefge
    fggeejnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucevlhhushhtvghrufhiiigv
    pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvhhishhisg
    hlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopedutddpmhhouggvpehs
    mhhtphhouhhtpdhrtghpthhtohepsghhvghlghgrrghssehgohhoghhlvgdrtghomhdprh
    gtphhtthhopehjghhrohhsshesshhushgvrdgtohhmpdhrtghpthhtoheprhhoghgvrhdr
    phgruhestghithhrihigrdgtohhmpdhrtghpthhtohepsghorhhishdrohhsthhrohhvsh
    hkhiesohhrrggtlhgvrdgtohhmpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishht
    shdrgigvnhhprhhojhgvtghtrdhorhhgpdhrtghpthhtoheplhhinhhugidqkhgvrhhnvg
    hlsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheprhgvghhrvghsshhiohhn
    sheslhhishhtshdrlhhinhhugidruggvvhdprhgtphhtthhopehnsggusehnsggurdhnrg
    hmvgdprhgtphhtthhopehlohhrvghniihosehkvghrnhgvlhdrohhrgh
X-ME-Proxy: <xmx:mkeKZ6NGdri_FRzbilqE0iPwZQ5mER2Nt835O87c-hsPeJcSIXO9Tw>
    <xmx:mkeKZ79JWoKaeCfzhawdpNTD6_HUFHL-pNoDj9nr6cDcR1woi2uSVw>
    <xmx:mkeKZ6Wcrb0PrFd_-xuRybEXr3-OfjWb5gv6w2VbzI6HIIz06cCO3A>
    <xmx:mkeKZ8eBYa7pmyU9aKDnEyGfLpIWcF4fOUqwgmGSpNkcZOaU9PP5Ng>
    <xmx:m0eKZ83JcmhpKN0VmRnx_g48kqQHNlsKPfxwtB0dAomm_J7mCpF7-YZp>
Feedback-ID: i1568416f:Fastmail
Date: Fri, 17 Jan 2025 13:05:30 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Bjorn Helgaas <bhelgaas@google.com>,
	=?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	linux-kernel@vger.kernel.org, regressions@lists.linux.dev,
	Felix Fietkau <nbd@nbd.name>, Lorenzo Bianconi <lorenzo@kernel.org>,
	Ryder Lee <ryder.lee@mediatek.com>
Subject: Config space access to Mediatek MT7922 doesn't work after device
 reset in Xen PV dom0 (regression, Linux 6.12)
Message-ID: <Z4pHll_6GX7OUBzQ@mail-itl>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="sWxZVOYUfcZCOYXA"
Content-Disposition: inline


--sWxZVOYUfcZCOYXA
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Fri, 17 Jan 2025 13:05:30 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Bjorn Helgaas <bhelgaas@google.com>,
	=?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	linux-kernel@vger.kernel.org, regressions@lists.linux.dev,
	Felix Fietkau <nbd@nbd.name>, Lorenzo Bianconi <lorenzo@kernel.org>,
	Ryder Lee <ryder.lee@mediatek.com>
Subject: Config space access to Mediatek MT7922 doesn't work after device
 reset in Xen PV dom0 (regression, Linux 6.12)

Hi,

After updating PV dom0 to Linux 6.12, The Mediatek MT7922 device reports
all 0xff when accessing its config space. This happens only after device
reset (which is also triggered when binding the device to the
xen-pciback driver).

Reproducer:

    # lspci -xs 01:00.0
    01:00.0 Network controller: MEDIATEK Corp. MT7922 802.11ax PCI Express =
Wireless Network Adapter
    00: c3 14 16 06 00 00 10 00 00 00 80 02 10 00 00 00
    ...
    # echo 1 > /sys/bus/pci/devices/0000:01:00.0/reset
    # lspci -xs 01:00.0
    01:00.0 Network controller: MEDIATEK Corp. MT7922 802.11ax PCI Express =
Wireless Network Adapter
    00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    ...

The same operation done on Linux 6.12 running without Xen works fine.

git bisect points at:

    commit d591f6804e7e1310881c9224d72247a2b65039af
    Author: Bjorn Helgaas <bhelgaas@google.com>
    Date:   Tue Aug 27 18:48:46 2024 -0500

    PCI: Wait for device readiness with Configuration RRS

part of that commit:
@@ -1311,9 +1320,15 @@ static int pci_dev_wait(struct pci_dev *dev, char *r=
eset_type, int timeout)
                        return -ENOTTY;
                }
=20
-               pci_read_config_dword(dev, PCI_COMMAND, &id);
-               if (!PCI_POSSIBLE_ERROR(id))
-                       break;
+               if (root && root->config_crs_sv) {
+                       pci_read_config_dword(dev, PCI_VENDOR_ID, &id);
+                       if (!pci_bus_crs_vendor_id(id))
+                               break;
+               } else {
+                       pci_read_config_dword(dev, PCI_COMMAND, &id);
+                       if (!PCI_POSSIBLE_ERROR(id))
+                               break;
+               }
=20
   =20
Adding some debugging, the PCI_VENDOR_ID read in pci_dev_wait() returns
initially 0xffffffff. If I extend the condition with
"&& !PCI_POSSIBLE_ERROR(id)", then the issue disappear. But reading the
patch description, it would break VF.
I'm not sure where the issue is, but given it breaks only when running
with Xen, I guess something is wrong with "Configuration RRS Software
Visibility" in that case.

BTW, shouldn't PCI_VENDOR_ID be accessed via pci_read_config_word()
instead of pci_read_config_dword()?

I'm also CC-ing MT76 driver maintainers in case it turns out to be
device-specific issue, not a generic one.

Initially reported at https://github.com/QubesOS/qubes-issues/issues/9689

#regzbot introduced: d591f6804e7e1310881c9224d72247a2b65039af

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

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

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmeKR5YACgkQ24/THMrX
1yyDjQf+JBoWE4mxxNyZATD6m9P70rRJd0JhGqotS5b1B5P6bMIEGSophssWxldE
+p9xAUihpymf67AQsqMP1bEgUuQUHbBE+VuQp12aFb1AdKgGCjsKK1sZgx+1WjlM
mWxC8vWyXEmRXUBU+0j531yBb9JbO93HULXk8EC0DYHqt1YSH68b0vHYNoRVBVqZ
S4fOb7LhEsIWpprx/yWtRlcKwFUSK96KabmpGSeXgkZ+LSM8eMQgLfTXcpRLxNaR
yKIeadTj2I2wjwZ0LnGSFjDGfMqhWl/myprlcyoonnEGs/lenDpMQ8Ja2QHzpSKx
GrUjgFoZdghTv4mOtnDPTarPl0e6KQ==
=9sOx
-----END PGP SIGNATURE-----

--sWxZVOYUfcZCOYXA--


From xen-devel-bounces@lists.xenproject.org Fri Jan 17 12:25:07 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Jan 2025 12:25:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.874040.1284910 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYlPI-0004XG-94; Fri, 17 Jan 2025 12:25:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 874040.1284910; Fri, 17 Jan 2025 12:25:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYlPI-0004X9-5b; Fri, 17 Jan 2025 12:25:00 +0000
Received: by outflank-mailman (input) for mailman id 874040;
 Fri, 17 Jan 2025 12:24:58 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=SGgd=UJ=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tYlPG-0004X3-Kc
 for xen-devel@lists.xenproject.org; Fri, 17 Jan 2025 12:24:58 +0000
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com
 [2a00:1450:4864:20::62a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0fcb850e-d4ce-11ef-99a4-01e77a169b0f;
 Fri, 17 Jan 2025 13:24:56 +0100 (CET)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-aaec61d0f65so439546566b.1
 for <xen-devel@lists.xenproject.org>; Fri, 17 Jan 2025 04:24:56 -0800 (PST)
Received: from localhost ([217.156.233.154]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab384d28507sm162195766b.77.2025.01.17.04.24.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 17 Jan 2025 04:24:55 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 0fcb850e-d4ce-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1737116696; x=1737721496; darn=lists.xenproject.org;
        h=in-reply-to:references:subject:cc:to:from:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ZjGDC0ZAfo7uCkPg54+zeMeHrkZkBx1xwvN1HBSGBps=;
        b=cyH9RGKuNyFEetxcYUkxYWuRe9PD7JLc60GWBHpATvK48c9PYSsDCwvOOAwh5Fkrlw
         yLBqHymKbHYr8rh9OS2DB0z2slcGAhI1oJ6whBVgNdW5dS71iIoWb9E18PHjuWu9xQTT
         FyPTZCfKpIaSVYLqQ7JyuZKKKqBr5Ft5QAdlg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737116696; x=1737721496;
        h=in-reply-to:references:subject:cc:to:from:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=ZjGDC0ZAfo7uCkPg54+zeMeHrkZkBx1xwvN1HBSGBps=;
        b=u6QAMGXPTVOE8GIukD3fu1jEJBXxz7HXWmh0/yV+im5lrr9jXV4RgM3kBlEMT6pUWy
         Ii+nQrS0dWsJyfU3DIKYBc5fHw8xVawuKsaMPZb56d7V2dAaYDU361M8aJgex88eutop
         v54NFX6OzhgC7Fl6AqmHoGHVnX9dEk8TkHoYwXmVbifwTylkcDH6/sZ2FHoxc5A75gcx
         /7y3FPV17Ap0zck1JXZaXt8V/PlrLnfuiVP/mdRhequehHgGTwDN5fCdKTaPYPGPW3cL
         r3bXqQAZDXaAQ/aLydcJqDS9Y6I5jlJ8w7opjyr6BnjkcuL/q7bW8wkKqosRHxUB3VR7
         8Jwg==
X-Forwarded-Encrypted: i=1; AJvYcCXNOsYRZWAhqPo/wxwW9vmf/NU+aolYGPOMhbKUQC2dhxVU2nhz2J23Yq3Yu2+gxQ6X5xDe5nAX+8w=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzzG41fiEO+aaTQC0nQs3U/lQpqgVFB8Yk7JTD6mzcrb6nvVoSN
	dKXouHvrRy6XSjjW/EcnG3i9E3rlb9vk06CVeWg4iW3RrKK1pb6AHo2CGqREWPs=
X-Gm-Gg: ASbGnct/c0oTZ7STK0K3f9BGe4iiPaeQxUWO+EKfi5NCR+jrN/yHXEGpvUZTDRYELyI
	VtQfurhHTW6uKw9TMZbnvCef+N+gNhqogzaxZcfer/SbkvzMgFsak5yfXLWLG+IUYDtHSg8swny
	uQhFsZ8nqQwnk04C9vVu12z6kZmAHOafLluwFqbwxmCDe7vagsnZESK6379su9Uwf1f67iBFz2m
	QBA3NY/YiLrqekAKEo790iFPuTsEaLcOQs7MJFr2CQLfkU6sknm8XP081eiNolrvA==
X-Google-Smtp-Source: AGHT+IHiqGtgizAR99kSa21ynZO425cuV68rvSS6tGs+oi/qyVmdNo9uJqML7SsYa+R2Qn+Nz1/H+g==
X-Received: by 2002:a17:907:930b:b0:aab:c78c:a705 with SMTP id a640c23a62f3a-ab38b3d4253mr243695766b.52.1737116696049;
        Fri, 17 Jan 2025 04:24:56 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Fri, 17 Jan 2025 12:24:54 +0000
Message-Id: <D74CH4RDRRR9.ZR6RL8U6PQ56@cloud.com>
From: "Alejandro Vallejo" <alejandro.vallejo@cloud.com>
To: =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, "Stefano
 Stabellini" <sstabellini@kernel.org>
Cc: "Jan Beulich" <jbeulich@suse.com>, "xen-devel@lists.xenproject.org"
 <xen-devel@lists.xenproject.org>, "Andrew Cooper"
 <andrew.cooper3@citrix.com>, "George Dunlap" <george.dunlap@citrix.com>,
 "Julien Grall" <julien@xen.org>, "Wei Liu" <wl@xen.org>,
 <sergiy_kibrik@epam.com>
Subject: Re: [PATCH v2 1/4] x86: provide an inverted Kconfig control for
 shim-exclusive mode
X-Mailer: aerc 0.18.2
References: <da5f5bac-6d5d-092d-d872-f1120dcd2661@suse.com>
 <617842e1-8ef2-b095-0c52-c2e2e5f1c0a8@suse.com>
 <alpine.DEB.2.22.394.2501161503120.2684657@ubuntu-linux-20-04-desktop>
 <Z4oxZSUQ6VARiR0H@macbook.local>
In-Reply-To: <Z4oxZSUQ6VARiR0H@macbook.local>

On Fri Jan 17, 2025 at 10:31 AM GMT, Roger Pau Monn=C3=A9 wrote:
> On Thu, Jan 16, 2025 at 04:31:46PM -0800, Stefano Stabellini wrote:
> > On Wed, 1 Mar 2023, Jan Beulich wrote:
> > > While we want certain things turned off in shim-exclusive mode, doing
> > > so via "depends on !PV_SHIM_EXCLUSIVE" badly affects allyesconfig: Si=
nce
> > > that will turn on PV_SHIM_EXCLUSIVE, other options will be turned off=
 as
> > > a result. Yet allyesconfig wants to enable as much of the functionali=
ty
> > > as possible.
> > >=20
> > > Retain PV_SHIM_EXCLUSIVE as a prompt-less option such that first of a=
ll
> > > C code using it can remain as is. This isn't just for less code churn=
,
> > > but also because I think that symbol is more logical to use in many
> > > (all?) places.
> > >=20
> > > Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
> > > Signed-off-by: Jan Beulich <jbeulich@suse.com>
> > >
> > > ---
> > > The new Kconfig control's name is up for improvement suggestions, but=
 I
> > > think it's already better than the originally thought of
> > > FULL_HYPERVISOR.
> >=20
> > I think the approach in general is OK, maybe we can improve the naming
> > further. What about one of the following?
> >=20
> > NO_PV_SHIM_EXCLUSIVE
> > PV_SHIM_NOT_EXCLUSIVE
>
> IMO negated options are confusing, and if possible I think we should
> avoid using them unless strictly necessary.

The problem is that the option is negative in nature. It's asking for
hypervisor without _something_. I do agree with Stefano that shim would be
better in the name. Otherwise readers are forced to play divination tricks.

How about something like:

    SHIMLESS_HYPERVISOR

That's arguably not negated, preserves "shim" in the name and has the corre=
ct
polarity for allyesconfig to yield the right thing.

>
> I for example always considered extremely confusing that previous to
> having CONFIG_DEBUG Xen used NDEBUG (so no debug) as a way to signal
> debug vs non-debug builds.
>
> Thanks, Roger.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Fri Jan 17 12:41:33 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Jan 2025 12:41:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.874051.1284921 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYlfE-0007hZ-Jr; Fri, 17 Jan 2025 12:41:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 874051.1284921; Fri, 17 Jan 2025 12:41:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYlfE-0007hS-G0; Fri, 17 Jan 2025 12:41:28 +0000
Received: by outflank-mailman (input) for mailman id 874051;
 Fri, 17 Jan 2025 12:41:27 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=b505=UJ=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tYlfD-0007hG-0h
 for xen-devel@lists.xenproject.org; Fri, 17 Jan 2025 12:41:27 +0000
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com
 [2a00:1450:4864:20::430])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5bf0357a-d4d0-11ef-99a4-01e77a169b0f;
 Fri, 17 Jan 2025 13:41:23 +0100 (CET)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3862b40a6e0so1223401f8f.0
 for <xen-devel@lists.xenproject.org>; Fri, 17 Jan 2025 04:41:23 -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
 ffacd0b85a97d-38bf327e024sm2373776f8f.88.2025.01.17.04.41.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 17 Jan 2025 04:41:22 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5bf0357a-d4d0-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737117683; x=1737722483; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=vm2T92KgDW9Mi2Le1XhF32fcQchrX/O3tdFBs2FrGOs=;
        b=D5M6bgSQCNHch9PkqNjwGyaTRZ4utu/qfH3duytdnB0oJLQBVLArXnJ0313wIJ+/5N
         aWAb5WMpDSSdPGP/nB4aihiVMHa3v4NznbgtfqM/kdBfASQD33WJF8H2RTSCPIRGWkxu
         ZbyN1NXWTT+vNUayEIf72bpYYmbdzrJQjbIhoxzQUOT8spT7coWLmObdhom2B0DUrupk
         +EvopXZbb1lhv7xbbVYPwq2kJn1WBtbDWPLRwuZlVFXJs1kpBGmYP5dBiL9i6FYla+rz
         v6cMBjlmYvl7pS5LziVrheN/+LHaJx7X4uVZcQscsZJVE+GP0cG2DH6KDt05H58zc6a7
         HE5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737117683; x=1737722483;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=vm2T92KgDW9Mi2Le1XhF32fcQchrX/O3tdFBs2FrGOs=;
        b=teVnjQzaW43/OiSKBqeY1x9VcQkyf93TbYIZIomAjdEfh0Wq6yk1f7xtp8TI0+SyiA
         2oxrqZEXyhniDrl8BekTLmd23EROagsOMabaXrC4bLdbezKpy2y3+5T7q6SEE+gTinNY
         gt4BJktlOalJJwOmVSzMXfnwiA261mbZfldttuly1XHG5IrMqH21rrCbW9fb30TuXTHR
         EJHmCfx/y61MLS2pNh3q37u7LakH0n+wZvieaWjdo7sastHyPjBvtb8RYanvb69PuY/A
         kqDVdWjIWISrMmfYLJTbq9piUgSGfqjcwrYmDrNwA5RP6slKRlcxTbkAB3kf4LOEWBVE
         NYVA==
X-Gm-Message-State: AOJu0Yw0LUXLQUI0p0Ny1df45zUpIm5TVO7SXJWuAOOr+Rpzdbhuqm1g
	pOK0c22sVrXDyRtikarEtrP11QZGinT1orqqyfU6Zk0YoJUgdHc2/gUGlmDr2A==
X-Gm-Gg: ASbGncsTvaC6PEKlaQtuz4MCL/cNe5EqMRHppaoOkVkQGKrdfdCNax3nQAzKdVraxs9
	1EWxc4Z9DRhdF/sI6/4c9EIDSdy09B3ZkB9ixDpZoCm7GAaOnoq2PxL0XvAwkOp8xF7QODZVwL3
	vM+d/StZD6QjZIYGEth2qjMYijxhzZPi6N9UdpshebZJW7FnHHFhIM0ZLewBud19A8PqbrSBKOR
	3seZVWkToYOO8NjogyDzPTeiC0h0KmOKJX9CHX8gdViMLlG3lhis5p25lVH5e93M9QfOT19fESs
	2/Nn9xfpDWYOqqOIFvlNkTvHUX4wCvb6Ye7tFIOXOg==
X-Google-Smtp-Source: AGHT+IG4w7j3gEgGKa1PFkR5WQ4cKyt+9PDhBtgKZKO482oM2WAMMX3S+WNm0TNTXle5c9y0hKMiSg==
X-Received: by 2002:a5d:5f8c:0:b0:385:ef2f:92ad with SMTP id ffacd0b85a97d-38bf564d5e7mr2744161f8f.10.1737117682834;
        Fri, 17 Jan 2025 04:41:22 -0800 (PST)
Message-ID: <6285f86d-f2d2-4040-999d-01aed3e72a36@suse.com>
Date: Fri, 17 Jan 2025 13:41:21 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/4] x86: provide an inverted Kconfig control for
 shim-exclusive mode
To: Alejandro Vallejo <alejandro.vallejo@cloud.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Wei Liu <wl@xen.org>, sergiy_kibrik@epam.com,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>
References: <da5f5bac-6d5d-092d-d872-f1120dcd2661@suse.com>
 <617842e1-8ef2-b095-0c52-c2e2e5f1c0a8@suse.com>
 <alpine.DEB.2.22.394.2501161503120.2684657@ubuntu-linux-20-04-desktop>
 <Z4oxZSUQ6VARiR0H@macbook.local> <D74CH4RDRRR9.ZR6RL8U6PQ56@cloud.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <D74CH4RDRRR9.ZR6RL8U6PQ56@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 17.01.2025 13:24, Alejandro Vallejo wrote:
> On Fri Jan 17, 2025 at 10:31 AM GMT, Roger Pau Monné wrote:
>> On Thu, Jan 16, 2025 at 04:31:46PM -0800, Stefano Stabellini wrote:
>>> On Wed, 1 Mar 2023, Jan Beulich wrote:
>>>> While we want certain things turned off in shim-exclusive mode, doing
>>>> so via "depends on !PV_SHIM_EXCLUSIVE" badly affects allyesconfig: Since
>>>> that will turn on PV_SHIM_EXCLUSIVE, other options will be turned off as
>>>> a result. Yet allyesconfig wants to enable as much of the functionality
>>>> as possible.
>>>>
>>>> Retain PV_SHIM_EXCLUSIVE as a prompt-less option such that first of all
>>>> C code using it can remain as is. This isn't just for less code churn,
>>>> but also because I think that symbol is more logical to use in many
>>>> (all?) places.
>>>>
>>>> Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>>
>>>> ---
>>>> The new Kconfig control's name is up for improvement suggestions, but I
>>>> think it's already better than the originally thought of
>>>> FULL_HYPERVISOR.
>>>
>>> I think the approach in general is OK, maybe we can improve the naming
>>> further. What about one of the following?
>>>
>>> NO_PV_SHIM_EXCLUSIVE
>>> PV_SHIM_NOT_EXCLUSIVE
>>
>> IMO negated options are confusing, and if possible I think we should
>> avoid using them unless strictly necessary.
> 
> The problem is that the option is negative in nature. It's asking for
> hypervisor without _something_. I do agree with Stefano that shim would be
> better in the name. Otherwise readers are forced to play divination tricks.
> 
> How about something like:
> 
>     SHIMLESS_HYPERVISOR
> 
> That's arguably not negated, preserves "shim" in the name and has the correct
> polarity for allyesconfig to yield the right thing.

Except that a hypervisor with this option enabled isn't shim-less, but permits
working in shim as well as in non-shim mode.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Jan 17 13:45:23 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Jan 2025 13:45:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.874061.1284929 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYmeq-0007ka-2d; Fri, 17 Jan 2025 13:45:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 874061.1284929; Fri, 17 Jan 2025 13:45:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYmeq-0007kT-00; Fri, 17 Jan 2025 13:45:08 +0000
Received: by outflank-mailman (input) for mailman id 874061;
 Fri, 17 Jan 2025 13:45:06 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=qJiU=UJ=redhat.com=vschneid@srs-se1.protection.inumbo.net>)
 id 1tYmeo-0007kN-AO
 for xen-devel@lists.xenproject.org; Fri, 17 Jan 2025 13:45:06 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3f5f4f1a-d4d9-11ef-99a4-01e77a169b0f;
 Fri, 17 Jan 2025 14:45:01 +0100 (CET)
Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com
 [209.85.160.199]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-504-dO1CuvSTPOqOCtjIYYFVbA-1; Fri, 17 Jan 2025 08:44:57 -0500
Received: by mail-qt1-f199.google.com with SMTP id
 d75a77b69052e-46798d74f0cso43648521cf.0
 for <xen-devel@lists.xenproject.org>; Fri, 17 Jan 2025 05:44:57 -0800 (PST)
Received: from vschneid-thinkpadt14sgen2i.remote.csb
 (213-44-141-166.abo.bbox.fr. [213.44.141.166])
 by smtp.gmail.com with ESMTPSA id
 d75a77b69052e-46e1042ef63sm11228641cf.71.2025.01.17.05.44.44
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 17 Jan 2025 05:44:55 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 3f5f4f1a-d4d9-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1737121500;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=HEKKhsO2kOL/qF9SHnIE9a8dcD47/tUh4wLid3vzvOo=;
	b=a51vRx2QsdZszzMXf+neqOLckjs1ZNq5QSO3L01C7glmUK9RzGB27lCc3ukQTVuMwOJisy
	1+OuvjOqVCUPdl02sJLiT5+PAOsjVCpfVrcA6SgKdGPs26r7t4mugWAom0mnglOxajvYVo
	yfcVWexUV1OlB/UaPLu6P89mG/wIIY8=
X-MC-Unique: dO1CuvSTPOqOCtjIYYFVbA-1
X-Mimecast-MFC-AGG-ID: dO1CuvSTPOqOCtjIYYFVbA
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737121496; x=1737726296;
        h=mime-version:message-id:date:references:in-reply-to:subject:cc:to
         :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=HEKKhsO2kOL/qF9SHnIE9a8dcD47/tUh4wLid3vzvOo=;
        b=OGLA0Jg6n6IWTXX4Lob4yG7F7UMYrXfnmgJROPpt2Km6cGUFq9pnK0PzmRyxAdIia1
         b5cbjiPBqtuoEKIcI/lIqFKCYWgw0rB/gRiNBGXoa/mcNzrsDewxq9rfqzZaozdl3Lmr
         W9+4iYEC/6UaLlKJoccqudQRAYtzhiHCAPKiqLLUKDq8LNmHxfeXrJ8i/yEpfvm2LDJI
         lG9vakOO+u3H5bApgtSY6xSCXrdvNuWsJam52wRswr5LI5NBGWs/Ais8YKFl8Vv9nvau
         5WJAjJ7CMlraVz9YPTtM2ypmrFNCYqalbCFUYfC6unX7f2fkl2zrc16TMnaNmAlqITMm
         yUyA==
X-Forwarded-Encrypted: i=1; AJvYcCWjbTdOJN3N6WQXriXmXYFOB5pXdkVGd3sm4IFwqIHpSu0RcovBWrhlM1DhdlY6SgCuDRGZdUQp/44=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzevS3QuQ8RqNW/kpS58OVQWLCi2skLiMv8sU8RFSeuC99H1LrG
	FBxwlGI3wJA9Cx8ZT1g7y13SSg2Y1pJUObaZzZ1JX8XiVUdodA3X8OJwB0o6vwHj0Kf5Ur790QS
	G5nr49iX55e6t4jKDXhiwhwPhyZ5VhQiZw3x+/GD/3qcWegCQ/skqHwYG+IjoKpfO
X-Gm-Gg: ASbGncs55ZWleEt90HCUbbyoHLmCr7qvanmWkvgsaOe8woxPCKYJTV4jtJMxnzPtGPn
	DZChH4+GdwzSe0+GHAzN6NbW+kZFkGLh4teg4phuLDZKMKxGkuOxrdTjPjqQVvzamm0zq6EPM5N
	cjq8imJX5Ws50cG/is3CbOa5FDpQhb0Is4VSeHPl4EUuoEUquJ4P6sdAXdLEt01Qd64PuVmTgQp
	BOhwhG1amAPdHE69fdMCQPhHH2QKPkVmSX+XLdfwKj1zrTbOz5s2hmWU1h/Z8ilyIuhvBTTJ7hX
	OOTIBBJ4zQjmBHjX5/JXjh15COUpLqHIY98Qyz4GiA==
X-Received: by 2002:a05:622a:1387:b0:467:674d:237f with SMTP id d75a77b69052e-46e12ad5f7bmr40518901cf.11.1737121496627;
        Fri, 17 Jan 2025 05:44:56 -0800 (PST)
X-Google-Smtp-Source: AGHT+IHmIl4MCDkHkFsxi8fUyXS99BtrKRZsY+6w06Ii3eQgKuqou3xcsKirOxy10aWGIFujuL9O5w==
X-Received: by 2002:a05:622a:1387:b0:467:674d:237f with SMTP id d75a77b69052e-46e12ad5f7bmr40518371cf.11.1737121496270;
        Fri, 17 Jan 2025 05:44:56 -0800 (PST)
From: Valentin Schneider <vschneid@redhat.com>
To: Dave Hansen <dave.hansen@intel.com>, linux-kernel@vger.kernel.org,
 x86@kernel.org, virtualization@lists.linux.dev,
 linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev,
 linux-riscv@lists.infradead.org, linux-perf-users@vger.kernel.org,
 xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
 linux-arch@vger.kernel.org, rcu@vger.kernel.org,
 linux-hardening@vger.kernel.org, linux-mm@kvack.org,
 linux-kselftest@vger.kernel.org, bpf@vger.kernel.org,
 bcm-kernel-feedback-list@broadcom.com
Cc: Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>,
 Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov
 <alexey.amakhalov@broadcom.com>, Russell King <linux@armlinux.org.uk>,
 Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>,
 Huacai Chen <chenhuacai@kernel.org>, WANG Xuerui <kernel@xen0n.name>, Paul
 Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>,
 Albert Ou <aou@eecs.berkeley.edu>, Thomas Gleixner <tglx@linutronix.de>,
 Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Dave
 Hansen <dave.hansen@linux.intel.com>, "H. Peter Anvin" <hpa@zytor.com>,
 Arnaldo Carvalho de Melo <acme@kernel.org>, Namhyung Kim
 <namhyung@kernel.org>, Mark Rutland <mark.rutland@arm.com>, Alexander
 Shishkin <alexander.shishkin@linux.intel.com>, Jiri Olsa
 <jolsa@kernel.org>, Ian Rogers <irogers@google.com>, Adrian Hunter
 <adrian.hunter@intel.com>, "Liang, Kan" <kan.liang@linux.intel.com>, Boris
 Ostrovsky <boris.ostrovsky@oracle.com>, Josh Poimboeuf
 <jpoimboe@kernel.org>, Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
 Sean Christopherson <seanjc@google.com>, Paolo Bonzini
 <pbonzini@redhat.com>, Andy Lutomirski <luto@kernel.org>, Arnd Bergmann
 <arnd@arndb.de>, Frederic Weisbecker <frederic@kernel.org>, "Paul E.
 McKenney" <paulmck@kernel.org>, Jason Baron <jbaron@akamai.com>, Steven
 Rostedt <rostedt@goodmis.org>, Ard Biesheuvel <ardb@kernel.org>, Neeraj
 Upadhyay <neeraj.upadhyay@kernel.org>, Joel Fernandes
 <joel@joelfernandes.org>, Josh Triplett <josh@joshtriplett.org>, Boqun
 Feng <boqun.feng@gmail.com>, Uladzislau Rezki <urezki@gmail.com>, Mathieu
 Desnoyers <mathieu.desnoyers@efficios.com>, Lai Jiangshan
 <jiangshanlai@gmail.com>, Zqiang <qiang.zhang1211@gmail.com>, Juri Lelli
 <juri.lelli@redhat.com>, Clark Williams <williams@redhat.com>, Yair
 Podemsky <ypodemsk@redhat.com>, Tomas Glozar <tglozar@redhat.com>, Vincent
 Guittot <vincent.guittot@linaro.org>, Dietmar Eggemann
 <dietmar.eggemann@arm.com>, Ben Segall <bsegall@google.com>, Mel Gorman
 <mgorman@suse.de>, Kees Cook <kees@kernel.org>, Andrew Morton
 <akpm@linux-foundation.org>, Christoph Hellwig <hch@infradead.org>, Shuah
 Khan <shuah@kernel.org>, Sami Tolvanen <samitolvanen@google.com>, Miguel
 Ojeda <ojeda@kernel.org>, Alice Ryhl <aliceryhl@google.com>, "Mike
 Rapoport (Microsoft)" <rppt@kernel.org>, Samuel Holland
 <samuel.holland@sifive.com>, Rong Xu <xur@google.com>, Nicolas Saenz
 Julienne <nsaenzju@redhat.com>, Geert Uytterhoeven <geert@linux-m68k.org>,
 Yosry Ahmed <yosryahmed@google.com>, "Kirill A. Shutemov"
 <kirill.shutemov@linux.intel.com>, "Masami Hiramatsu (Google)"
 <mhiramat@kernel.org>, Jinghao Jia <jinghao7@illinois.edu>, Luis
 Chamberlain <mcgrof@kernel.org>, Randy Dunlap <rdunlap@infradead.org>,
 Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: Re: [PATCH v4 26/30] x86,tlb: Make __flush_tlb_global()
 noinstr-compliant
In-Reply-To: <52311c3d-83cf-4dc4-bbcb-5fbca8eb249c@intel.com>
References: <20250114175143.81438-1-vschneid@redhat.com>
 <20250114175143.81438-27-vschneid@redhat.com>
 <52311c3d-83cf-4dc4-bbcb-5fbca8eb249c@intel.com>
Date: Fri, 17 Jan 2025 14:44:42 +0100
Message-ID: <xhsmh5xmdh7w5.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
MIME-Version: 1.0
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: oBlO9Yyi-gG1te7VPLjuQergYRA_PHWP-bbKSsUFZwA_1737121496
X-Mimecast-Originator: redhat.com
Content-Type: text/plain

On 14/01/25 13:45, Dave Hansen wrote:
> On 1/14/25 09:51, Valentin Schneider wrote:
>> +	cr4 = this_cpu_read(cpu_tlbstate.cr4);
>> +	asm volatile("mov %0,%%cr4": : "r" (cr4 ^ X86_CR4_PGE) : "memory");
>> +	asm volatile("mov %0,%%cr4": : "r" (cr4) : "memory");
>> +	/*
>> +	 * In lieu of not having the pinning crap, hard fail if CR4 doesn't
>> +	 * match the expected value. This ensures that anybody doing dodgy gets
>> +	 * the fallthrough check.
>> +	 */
>> +	BUG_ON(cr4 != this_cpu_read(cpu_tlbstate.cr4));
>
> Let's say someone managed to write to cpu_tlbstate.cr4 where they
> cleared one of the pinned bits.
>
> Before this patch, CR4 pinning would WARN_ONCE() about it pretty quickly
> and also reset the cleared bits.
>
> After this patch, the first native_flush_tlb_global() can clear pinned
> bits, at least until native_write_cr4() gets called the next time. That
> seems like it'll undermine CR4 pinning at least somewhat.
>

The BUG_ON() should still catch any pinned bit mishandling, however...

> What keeps native_write_cr4() from being noinstr-compliant now? Is it
> just the WARN_ONCE()?
>

I don't think that's even an issue since __WARN_printf() wraps the print in
instrumentation_{begin,end}(). In v3 I made native_write_cr4() noinstr and
added a non-noinstr wrapper to be used in existing callsites.

AFAICT if acceptable we could make the whole thing noinstr and stick with
that; Peter, is there something I missed that made you write the handmade
noinstr CR4 RMW?



From xen-devel-bounces@lists.xenproject.org Fri Jan 17 14:46:19 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Jan 2025 14:46:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.874099.1284940 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYnbn-0007hw-B2; Fri, 17 Jan 2025 14:46:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 874099.1284940; Fri, 17 Jan 2025 14:46:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYnbn-0007hp-7L; Fri, 17 Jan 2025 14:46:03 +0000
Received: by outflank-mailman (input) for mailman id 874099;
 Fri, 17 Jan 2025 14:46:01 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=wado=UJ=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tYnbl-0007hj-Sa
 for xen-devel@lists.xenproject.org; Fri, 17 Jan 2025 14:46:01 +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 c47621a4-d4e1-11ef-a0e2-8be0dac302b0;
 Fri, 17 Jan 2025 15:46:00 +0100 (CET)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-43618283d48so14936685e9.1
 for <xen-devel@lists.xenproject.org>; Fri, 17 Jan 2025 06:46:00 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-437c753cc1fsm97868425e9.39.2025.01.17.06.45.58
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 17 Jan 2025 06:45:58 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c47621a4-d4e1-11ef-a0e2-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737125160; x=1737729960; 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=bhZi52Q331IKB83Epo0yLj7+/mxBEWdhynpLcd6BGdA=;
        b=FGE0a3luGV0QG6cTQ8zkkkI/ztzjMu4r51pty1hAGwdUz7+qTkVLg5yj3j9U8huc9G
         PdkvZZC7eUX3loS3I2s523dAPurVCcESWd4PsQuqB8mainmcAgC9ZMnoa0pmVj9GSwJ3
         WcGQ7xKawtg/7Yp5DmOMJEYXLcnVANRu6nhmA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737125160; x=1737729960;
        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=bhZi52Q331IKB83Epo0yLj7+/mxBEWdhynpLcd6BGdA=;
        b=i4BywVDyLCpaQDGsNb8SfgBTsZg6FoeqSO2ze1zvGYNqwTjzyf/1pb6pY9C2jtHwFm
         fqcJkdseU5veAq+qnZEmTjL0mWaTjP1GOrRgBYGvKIHUL/GRQm4loU4zUNeFqBDHLdRF
         x5dHp5JYNXoW4JlJvfap/nLJiPj8sD8jxH2aISzp7Fg38u0sxDbpykhde+owcJ4Eowl3
         5YRAN5cRcSecc4D49Kegp4LzsqPGCRsarPkA6eUrzqvAfutc2dr5aURtdspxCYwXV45l
         bX2YCKCzFmVU165ne/mK9l5dvJt/TVVLES9KY0+9On4CzEkwiBvDo1tEMSUwdT3NolPY
         ZVkg==
X-Forwarded-Encrypted: i=1; AJvYcCU8OeKWOdQDJp+8OprDn4tX+iMkFm0mREY1uKtDsbPxpQ5HGiZqy9MykYblVQwmFWmIPC+lyLp/4Oc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyYbII7YRQaHNON/dCTFOgZLDNsts4TbpE8FOgTSBOUfso9sCH2
	mqeNdmAxVBhRoOxV+98oDPlPujxUoK/7icnfpGLbF7VTYR6Tn/ZuZHO1jTg4m2o=
X-Gm-Gg: ASbGncuL9fK0RP4dZEJGF7PgmK8MGO3dsxoK8dXcamzvFXK4PY3AuZlQihRdYle+ZHU
	F+mezNgnDtjiE1BJqafY9qT36uuWXwhyU2GZLVr0tAOhiT85/qANM2VF/CIa91+n1INLuiQ7j8K
	xpHvn6VUi8bb5hRgZE/DUZkrERhhOrBTF+Vks3xiEI1H66jcanhVTpcdxf5OT/pHgAA6Ec/kiCw
	rb3Q/NBGWH8Gjm7ObHYgDsfnyenpa1wVotZ0umDBv5fFIYaAD5t90VrKv1z51maz9A=
X-Google-Smtp-Source: AGHT+IGXo+sI3Hqa/dapJ9upJMjmD+l/zOCOWl4b5b2dJgpzUKXE+WKzXQ/ExOwuxwiqWrM7hEvEVg==
X-Received: by 2002:a05:600c:5486:b0:434:f1e9:afae with SMTP id 5b1f17b1804b1-438913bfa0fmr26368815e9.1.1737125159566;
        Fri, 17 Jan 2025 06:45:59 -0800 (PST)
Date: Fri, 17 Jan 2025 15:45:57 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Tim Deegan <tim@xen.org>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 00/18] x86: adventures in Address Space Isolation
Message-ID: <Z4ptJWmEwWdGsocD@macbook.local>
References: <20250108142659.99490-1-roger.pau@citrix.com>
 <8064a526-3525-4c48-8926-6ea99a8312a6@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <8064a526-3525-4c48-8926-6ea99a8312a6@suse.com>

On Tue, Jan 14, 2025 at 05:20:04PM +0100, Jan Beulich wrote:
> On 08.01.2025 15:26, Roger Pau Monne wrote:
> > Hello,
> > 
> > The aim of this series is to introduce the functionality required to
> > create linear mappings visible to a single pCPU.
> > 
> > Doing so requires having a per-vCPU root page-table (L4), and hence
> > requires shadowing the guest selected L4 on PV guests.  As follow ups
> > (and partially to ensure the per-CPU mappings work fine) the CPU stacks
> > are switched to use per-CPU mappings, so that remote stack contents are
> > not by default mapped on all page-tables (note: for this to be true the
> > directmap entries for the stack pages would need to be removed also).
> > 
> > There's one known shortcoming with the presented code: migration of PV
> > guests using per-vCPU root page-tables is not working.  I need to
> > introduce extra logic to deal with PV shadow mode when using unique root
> > page-tables.  I don't think this should block the series however, such
> > missing functionality can always be added as follow up work.
> > paging_domctl() is adjusted to reflect this restriction.
> > 
> > The main differences compared to v1 are the usage of per-vCPU root page
> > tables (as opposed to per-pCPU), and the usage of the existing perdomain
> > family of functions to manage the mappings in the per-domain slot, that
> > now becomes per-vCPU.
> > 
> > All patches until 17 are mostly preparatory, I think there's a nice
> > cleanup and generalization of the creation and managing of per-domain
> > mappings, by no longer storing references to L1 page-tables in the vCPU
> > or domain struct.
> 
> Since you referred me to the cover letter, I've looked back here after
> making some more progress with the series. Along with my earlier comment
> towards the need or ultimate goal, ...
> 
> > Patch 13 introduces the command line option, and would need discussion
> > and integration with the sparse direct map series.  IMO we should get
> > consensus on how we want the command line to look ASAP, so that we can
> > basic parsing logic in place to be used by both the work here and the
> > direct map removal series.
> > 
> > As part of this series the map_domain_page() helpers are also switched
> > to create per-vCPU mappings (see patch 15), which converts an existing
> > interface into creating per-vCPU mappings.  Such interface can be used
> > to hide (map per-vCPU) further data that we don't want to be part of the
> > direct map, or even shared between vCPUs of the same domain.  Also all
> > existing users of the interface will already create per-vCPU mappings
> > without needing additional changes.
> > 
> > Note that none of the logic introduced in the series removes entries for
> > the directmap, so even when creating the per-CPU mappings the underlying
> > physical addresses are fully accessible when using it's direct map
> > entries.
> > 
> > I also haven't done any benchmarking.  Doesn't seem to cripple
> > performance up to the point that XenRT jobs would timeout before
> > finishing, that the only objective reference I can provide at the
> > moment.
> > 
> > The series has been extensively tested on XenRT, but that doesn't cover
> > all possible use-cases, so it's likely to still have some rough edges,
> > handle with care.
> > 
> > Thanks, Roger.
> > 
> > Roger Pau Monne (18):
> >   x86/mm: purge unneeded destroy_perdomain_mapping()
> >   x86/domain: limit window where curr_vcpu != current on context switch
> >   x86/mm: introduce helper to detect per-domain L1 entries that need
> >     freeing
> >   x86/pv: introduce function to populate perdomain area and use it to
> >     map Xen GDT
> >   x86/mm: switch destroy_perdomain_mapping() parameter from domain to
> >     vCPU
> >   x86/pv: set/clear guest GDT mappings using
> >     {populate,destroy}_perdomain_mapping()
> >   x86/pv: update guest LDT mappings using the linear entries
> >   x86/pv: remove stashing of GDT/LDT L1 page-tables
> >   x86/mm: simplify create_perdomain_mapping() interface
> >   x86/mm: switch {create,destroy}_perdomain_mapping() domain parameter
> >     to vCPU
> >   x86/pv: untie issuing FLUSH_ROOT_PGTBL from XPTI
> >   x86/mm: move FLUSH_ROOT_PGTBL handling before TLB flush
> >   x86/spec-ctrl: introduce Address Space Isolation command line option
> >   x86/mm: introduce per-vCPU L3 page-table
> >   x86/mm: introduce a per-vCPU mapcache when using ASI
> >   x86/pv: allow using a unique per-pCPU root page table (L4)
> >   x86/mm: switch to a per-CPU mapped stack when using ASI
> >   x86/mm: zero stack on context switch
> > 
> >  docs/misc/xen-command-line.pandoc    |  24 +++
> >  xen/arch/x86/cpu/mcheck/mce.c        |   4 +
> >  xen/arch/x86/domain.c                | 157 +++++++++++----
> >  xen/arch/x86/domain_page.c           | 105 ++++++----
> >  xen/arch/x86/flushtlb.c              |  28 ++-
> >  xen/arch/x86/hvm/hvm.c               |   6 -
> >  xen/arch/x86/include/asm/config.h    |  16 +-
> >  xen/arch/x86/include/asm/current.h   |  58 +++++-
> >  xen/arch/x86/include/asm/desc.h      |   6 +-
> >  xen/arch/x86/include/asm/domain.h    |  50 +++--
> >  xen/arch/x86/include/asm/flushtlb.h  |   2 +-
> >  xen/arch/x86/include/asm/mm.h        |  15 +-
> >  xen/arch/x86/include/asm/processor.h |   5 +
> >  xen/arch/x86/include/asm/pv/mm.h     |   5 +
> >  xen/arch/x86/include/asm/smp.h       |  12 ++
> >  xen/arch/x86/include/asm/spec_ctrl.h |   4 +
> >  xen/arch/x86/mm.c                    | 291 +++++++++++++++++++++------
> >  xen/arch/x86/mm/hap/hap.c            |   2 +-
> >  xen/arch/x86/mm/paging.c             |   6 +
> >  xen/arch/x86/mm/shadow/hvm.c         |   2 +-
> >  xen/arch/x86/mm/shadow/multi.c       |   2 +-
> >  xen/arch/x86/pv/descriptor-tables.c  |  47 ++---
> >  xen/arch/x86/pv/dom0_build.c         |  12 +-
> >  xen/arch/x86/pv/domain.c             |  57 ++++--
> >  xen/arch/x86/pv/mm.c                 |  43 +++-
> >  xen/arch/x86/setup.c                 |  32 ++-
> >  xen/arch/x86/smp.c                   |  39 ++++
> >  xen/arch/x86/smpboot.c               |  26 ++-
> >  xen/arch/x86/spec_ctrl.c             | 205 ++++++++++++++++++-
> >  xen/arch/x86/traps.c                 |  25 ++-
> >  xen/arch/x86/x86_64/mm.c             |   7 +-
> >  xen/common/smp.c                     |  10 +
> >  xen/common/stop_machine.c            |  10 +
> >  xen/include/xen/smp.h                |   8 +
> >  34 files changed, 1052 insertions(+), 269 deletions(-)
> 
> ... this diffstat (even after subtracting out the contribution of the last two
> patches in the series) doesn't really look like a cleanup / simplification.

To be fair you would need to subtract the contribution of the last 8
patches, as all those are strictly related to ASI.  The perdomain
mapping interface cleanup is just the first 10 patches.  Which leaves
a diffstat of:

 xen/arch/x86/domain.c                |  81 ++++++++++++----
 xen/arch/x86/domain_page.c           |  19 ++--
 xen/arch/x86/hvm/hvm.c               |   6 --
 xen/arch/x86/include/asm/desc.h      |   6 +-
 xen/arch/x86/include/asm/domain.h    |  13 +--
 xen/arch/x86/include/asm/mm.h        |  11 ++-
 xen/arch/x86/include/asm/processor.h |   5 +
 xen/arch/x86/mm.c                    | 175 ++++++++++++++++++++++++++---------
 xen/arch/x86/pv/descriptor-tables.c  |  47 +++++-----
 xen/arch/x86/pv/domain.c             |  24 ++---
 xen/arch/x86/pv/mm.c                 |   3 +-
 xen/arch/x86/smpboot.c               |   6 +-
 xen/arch/x86/traps.c                 |  12 +--
 xen/arch/x86/x86_64/mm.c             |   7 +-
 14 files changed, 260 insertions(+), 155 deletions(-)

That's including the context switch change and not differentiating
between lines of code vs comments.

However, I don't think cleanup / simplifications should be purely
based on diffstat LoC.  Arguably the current
create_perdomain_mapping() set of parameters are not the most obvious
ones:

int create_perdomain_mapping(struct domain *d, unsigned long va,
                             unsigned int nr, l1_pgentry_t **pl1tab,
                             struct page_info **ppg);

Compared to the result after the first 10 patches in the series:

int create_perdomain_mapping(struct vcpu *v, unsigned long va,
                             unsigned int nr, bool populate);

Together with the fact that callers no longer need to keep a reference
to the L1(s) tables to populate such area.

> Things becoming slightly slower (because of the L1 no longer directly available
> to modify) may, otoh, not be a significant issue, if we assume that GDT/LDT
> manipulation isn't normally a very frequent operation.

I introduce a fast path in both {populate,destroy}_perdomain_mapping()
that uses the recursive linear slot for manipulating the L1
page-table.  There's still a slow path that relies on walking the
page-tables, but that should only be used when the vCPU is not
running, and hence the added latency shouldn't be too critical.

As a side-effect of this logic the pages allocated for the per-domain
region page-tables can now uniformly be from domheap.  The usage of
xenheap pages for L1 page-tables is no longer needed once those are
not stashed in the domain structure anymore.

> IOW my earlier request stands: Can you please try to make more clear (in the
> patch descriptions) what exactly the motivation for these changes is? Just
> doing things differently with more code overall can't be it, I don't think.

The main motivation for the change is to remove stashing L1
page-tables for the per-domain area(s) in the domain struct, as with
the introduction of ASI Xen would need to stash L1 page-tables for the
per-domain area on the vcpu struct also, as a result of the per-domain
slot becoming per-vCPU.  IMO managing such references, and having
logic to deal with domain and vcpu L1 page-tables is too complex and
error prone.

Instead I propose to add an interface:
{populate,destroy}_perdomain_mapping() that can be used to manage
mappings on the per-domain area with callers being completely unaware
of whether the domain is running with per-vCPU mappings or not.

Please let me know if you are happy with the reasoning and arguments
provided.  I think the resulting perdomain mapping interface is much
better than what Xen currently does for manipulating per-domain
mapping entries, but I might be spoiled.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jan 17 14:49:09 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Jan 2025 14:49:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.874112.1284950 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYnem-0008Go-NN; Fri, 17 Jan 2025 14:49:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 874112.1284950; Fri, 17 Jan 2025 14:49:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYnem-0008Gh-Ki; Fri, 17 Jan 2025 14:49:08 +0000
Received: by outflank-mailman (input) for mailman id 874112;
 Fri, 17 Jan 2025 14:49: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
 <SRS0=uuMv=UJ=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tYnel-0008GW-CP
 for xen-devel@lists.xenproject.org; Fri, 17 Jan 2025 14:49:07 +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 338d1311-d4e2-11ef-a0e2-8be0dac302b0;
 Fri, 17 Jan 2025 15:49:06 +0100 (CET)
Received: by mail-lf1-x12b.google.com with SMTP id
 2adb3069b0e04-5401bd6cdb7so2176016e87.2
 for <xen-devel@lists.xenproject.org>; Fri, 17 Jan 2025 06:49:06 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-543a24d2237sm5809e87.9.2025.01.17.06.49.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 17 Jan 2025 06:49:05 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 338d1311-d4e2-11ef-a0e2-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1737125346; x=1737730146; darn=lists.xenproject.org;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=qW9ZYsB86Q9/+J1D7xZz6p0RqShqfz4LZx9J65RLi70=;
        b=E+jKzxlUGqsZ/tHOu3Q2FePvX27BoddjXAvJ27zQ8Uy5yxXYUqRIugL+NxgRIVNxZE
         Vflz0zCemlZYWP5Qc48kRnvC9lgxrJRjLndIjrQkUry0HBXB3hBbhLUVIguHkcr1s0LE
         3jL2T/Z6Yzqgoiw8opL0rrxBSL8f2t01It24u9Doa1CdYM/gnBkJeNE9ABMXPIXZPsG6
         2uGC/PcJJTV8TAE7d9xUtC0sdr3fEvDtQAeykdBN6OEmRTZkYq5wlbb0mq+iC0bI/Vie
         fCiWPIYquiMT25zb3QqHNssmqPq4CGfqBD/JU0tl+ucygEgBZCGmpWF6WHI4iG2QGsD0
         GdeQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737125346; x=1737730146;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=qW9ZYsB86Q9/+J1D7xZz6p0RqShqfz4LZx9J65RLi70=;
        b=QlPpsxUp7/+55/FyKQQqEF+9+H/vp+s7CLuqSWdpNgDcAU5JypOEgvv/7DUDtj2a20
         ov0p+iuofH1S5wJ+C25uyVH3yNLUI7/2s1VGQye4QJvvI2KEUXQmKAGzljcd7+KYxhXU
         Simy0TvGLSVn4DD/Szsd04ajltNkFK/Jgw3HoDGLZaE7afr3PJWYxTqsrB9XZNL8P47u
         Tr6tjEU1E6nI8ElHUAnHkzPzIL/gblBhnGA9eXs/UBfgmfN4V5LQG7mZRdc5VxQN8p+F
         Wp75umoXurn7pE/WW/sHQiR46wBSUb971t7DGXoQLLKotKZN56dikvpKGZn2ODQTEwV/
         REaw==
X-Gm-Message-State: AOJu0YyT824QyCGI2AA6/295fZS64mFYRic76Wmko+mEttft2qqdsZJz
	gwYTrtlgCiu5X/sQKA4isdw+Dtl5GbguLrZNm9UPpYuf4rU6iGxo
X-Gm-Gg: ASbGncs98IDbG4uYjhFLmwRSXsqH55TFJlR5B+yTYb/eYzWN8ZU1/TH+c/Xx1Du4vEt
	qsMtwe3j5aPpWmR+I264MVmPtLMmi4zxgcxl0UDip7oJ808qAi1ACKhHaeDsf65WpngvEuXnBsk
	6L8OJukBxcB0IIZ/2h/bJaV/7wHoGpL55M49EOj93NELfxgtBh6ay2o3S6qmd/avx/B184AApvy
	NydMAoqDXPFspqCMXF5DpKfEOC3mKoSDn+MFplsSgWrWIDy70UCYPXAPCbzYxgORrpa+A==
X-Google-Smtp-Source: AGHT+IEM/KdAXnsc4qYMmKoF0DpK0hX8iSzZqwvM3nZytSFO04u12XZNvwnINUz8l4IXS4ZFB/fnsg==
X-Received: by 2002:ac2:561b:0:b0:540:353a:5b1f with SMTP id 2adb3069b0e04-5439c1ba039mr977823e87.0.1737125345591;
        Fri, 17 Jan 2025 06:49:05 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------zvh0GQkezdH8j6rlGDHgZ2Uz"
Message-ID: <51ac13ed-c6a8-4cd6-9790-d7c13de4c5ee@gmail.com>
Date: Fri, 17 Jan 2025 15:49:04 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20 v2 2/2] automation/cirrus-ci: introduce FreeBSD
 randconfig builds
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Cc: xen-devel@lists.xenproject.org, Anthony PERARD
 <anthony.perard@vates.tech>, Michal Orzel <michal.orzel@amd.com>,
 Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
References: <Z4j4s-1iK2CH4ssK@macbook.local>
 <20250116135957.80826-1-roger.pau@citrix.com>
 <94bbb56e-4a44-4981-a617-cdc541ea5308@citrix.com>
 <Z4kUGFKFHFBExvBl@macbook.local>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <Z4kUGFKFHFBExvBl@macbook.local>

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


On 1/16/25 3:13 PM, Roger Pau Monné wrote:
> On Thu, Jan 16, 2025 at 02:02:38PM +0000, Andrew Cooper wrote:
>> On 16/01/2025 1:59 pm, Roger Pau Monne wrote:
>>> Add a new randconfig job for each FreeBSD version.  This requires some
>>> rework of the template so common parts can be shared between the full and
>>> the randconfig builds.  Such randconfig builds are relevant because FreeBSD
>>> is the only tested system that has a full non-GNU toolchain.
>>>
>>> While there replace the usage of the python311 package with python3, which is
>>> already using 3.11, and remove the install of the plain python package for full
>>> builds.
>>>
>>> Signed-off-by: Roger Pau Monné<roger.pau@citrix.com>
>> That looks cleaner, and likely to have better longevity.  Thanks.
>>
>> Reviewed-by: Andrew Cooper<andrew.cooper3@citrix.com>
> Forgot to Cc Oleksii on the patches, as I would like a Release-Ack.

R-Acked-by: Oleksii Kurochko<oleksii.kurochko@gmail.com>

Thanks.

~ Oleksii

>
> Thanks, Roger.
--------------zvh0GQkezdH8j6rlGDHgZ2Uz
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 1/16/25 3:13 PM, Roger Pau Monné
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:Z4kUGFKFHFBExvBl@macbook.local">
      <pre wrap="" class="moz-quote-pre">On Thu, Jan 16, 2025 at 02:02:38PM +0000, Andrew Cooper wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">On 16/01/2025 1:59 pm, Roger Pau Monne wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="" class="moz-quote-pre">Add a new randconfig job for each FreeBSD version.  This requires some
rework of the template so common parts can be shared between the full and
the randconfig builds.  Such randconfig builds are relevant because FreeBSD
is the only tested system that has a full non-GNU toolchain.

While there replace the usage of the python311 package with python3, which is
already using 3.11, and remove the install of the plain python package for full
builds.

Signed-off-by: Roger Pau Monné <a class="moz-txt-link-rfc2396E" href="mailto:roger.pau@citrix.com">&lt;roger.pau@citrix.com&gt;</a>
</pre>
        </blockquote>
        <pre wrap="" class="moz-quote-pre">
That looks cleaner, and likely to have better longevity.  Thanks.

Reviewed-by: Andrew Cooper <a class="moz-txt-link-rfc2396E" href="mailto:andrew.cooper3@citrix.com">&lt;andrew.cooper3@citrix.com&gt;</a>
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
Forgot to Cc Oleksii on the patches, as I would like a Release-Ack.</pre>
    </blockquote>
    <pre>R-Acked-by: Oleksii Kurochko <a class="moz-txt-link-rfc2396E" href="mailto:oleksii.kurochko@gmail.com">&lt;oleksii.kurochko@gmail.com&gt;</a></pre>
    <pre>Thanks.</pre>
    <pre>~ Oleksii
</pre>
    <blockquote type="cite" cite="mid:Z4kUGFKFHFBExvBl@macbook.local">
      <pre wrap="" class="moz-quote-pre">

Thanks, Roger.
</pre>
    </blockquote>
  </body>
</html>

--------------zvh0GQkezdH8j6rlGDHgZ2Uz--


From xen-devel-bounces@lists.xenproject.org Fri Jan 17 14:58:03 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Jan 2025 14:58:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.874123.1284959 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYnnL-0001jv-Ga; Fri, 17 Jan 2025 14:57:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 874123.1284959; Fri, 17 Jan 2025 14:57:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYnnL-0001jo-Dx; Fri, 17 Jan 2025 14:57:59 +0000
Received: by outflank-mailman (input) for mailman id 874123;
 Fri, 17 Jan 2025 14:57: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
 <SRS0=wado=UJ=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tYnnK-0001ji-5R
 for xen-devel@lists.xenproject.org; Fri, 17 Jan 2025 14:57:58 +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 6fbac4fd-d4e3-11ef-a0e2-8be0dac302b0;
 Fri, 17 Jan 2025 15:57:57 +0100 (CET)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-4362bae4d7dso15046065e9.1
 for <xen-devel@lists.xenproject.org>; Fri, 17 Jan 2025 06:57:57 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38bf322aab8sm2754541f8f.57.2025.01.17.06.57.55
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 17 Jan 2025 06:57:55 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 6fbac4fd-d4e3-11ef-a0e2-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737125876; x=1737730676; 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=eaF3E/s+Qolsus2xx+kGrUlsIIEtO+GcgybAtuy88M4=;
        b=go8ENQ7+MzGg8utxxsZhkxLj6l4wCZGg16Oipe9RmKItr4ZbPheEO1Q1zHd13fPmJF
         hhA/yHbsqrxlXZhAZq6bo4stncDSvGvygo1ZbI5h2gpldAe1259c1YkKKW2xZx8c2Aeu
         04zZTmgRtnkEcADGva/sskrz10zd9++cLtBlU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737125876; x=1737730676;
        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=eaF3E/s+Qolsus2xx+kGrUlsIIEtO+GcgybAtuy88M4=;
        b=W2Feah4sGTPvS+lQGWfGx7qizPwShpp0IHyzoVtUPLPBWdW4cObzsvopSV4ayFc0Rg
         PlKfY3QN3zXCHQI4S0+5RvUE00hxYNPkAqJT0ZG1TrSUoZqphSzN1cXNMwc8VnKxPVzZ
         ual02mGsqY0C0F7l7hdv3gW2SZmvOt7/p1BUBP3XwwHju18zsHwSRZkX8IxnfO7P93+t
         3dFRtY5ikU4urVVv4bwLEdVUPsNBcNyCMVuBafpahD5q09CqT64Nw/Nlp+Zi8LFJYYE6
         iezkiNBEf5ItSEwzlXGLypLo3W+aaadaTmOdsRtjeoYDchKe5CEiaRMSNYaVRAV6QEqa
         KypA==
X-Forwarded-Encrypted: i=1; AJvYcCU2qaooqxVd/ayWyEA7PgI73rNrmdXAZVk7mTwRNAo6/q2SJc3G/P8USNsFn9Ew5HCGptrKLU49rPA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxrEownzxVhghOA1Nn+/rMmEz0f1gOUZSa4EJYXUjrAk1HfuLP4
	Lzk4mA3kMXqqFGFLJy703bt86UoVbjf+0/Rz0RzyJ+M8cmUzLjkA4/5w5RRA20MLbsedhdS2502
	t
X-Gm-Gg: ASbGncuTbLwWJ8ajdMEyXJFvrAylQYQwkRFCpLx9f3y43IZ7+Ts4DxSOHxNtfRAjBJB
	bP2sgFQ5VUTy14tZuT6M43yZ05vahPKjiWcPWi3W7wwSBT1kVvDyLeKxd3nQaCfNP8/9LDCWyAG
	+kN4QORZ5N+zzLSpJrLUp1x+vmaXcdynNAd5GjaNYl/vqbGqpt8WXrbZvu7DG+lx+6JOuUszfI4
	5LIJbjLk7d2ecW89ZJ4mant3+mS3u3fLEdcJ4kLdc0J4+zmgUDc5d+S/1OyIQ==
X-Google-Smtp-Source: AGHT+IGTahAVHPN0bmB6Gq7tuu5eBFTRJEzEDPSc+Vuf0TAwxboe3/fL5bz84Pkv9YK0SxGkkTcpoA==
X-Received: by 2002:a5d:588e:0:b0:385:faec:d94d with SMTP id ffacd0b85a97d-38bf57bd65bmr2776920f8f.51.1737125876420;
        Fri, 17 Jan 2025 06:57:56 -0800 (PST)
Date: Fri, 17 Jan 2025 15:57:55 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 02/18] x86/domain: limit window where curr_vcpu !=
 current on context switch
Message-ID: <Z4pv87ngrHD64Prm@macbook.local>
References: <20250108142659.99490-1-roger.pau@citrix.com>
 <20250108142659.99490-3-roger.pau@citrix.com>
 <46cb0ee0-ea9f-4515-abac-058a9aa846e4@suse.com>
 <Z4AIdlx7uWcS3cOP@macbook.local>
 <153425e6-a17d-48d2-a1d7-a9b0bf3167dd@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <153425e6-a17d-48d2-a1d7-a9b0bf3167dd@suse.com>

On Tue, Jan 14, 2025 at 04:02:01PM +0100, Jan Beulich wrote:
> On 09.01.2025 18:33, Roger Pau Monné wrote:
> > On Thu, Jan 09, 2025 at 09:59:58AM +0100, Jan Beulich wrote:
> >> On 08.01.2025 15:26, Roger Pau Monne wrote:
> >>>      }
> >>>      else
> >>>      {
> >>> -        __context_switch();
> >>> +        /*
> >>> +         * curr_vcpu will always point to the currently loaded vCPU context, as
> >>> +         * it's not updated when doing a lazy switch to the idle vCPU.
> >>> +         */
> >>> +        struct vcpu *prev_ctx = per_cpu(curr_vcpu, cpu);
> >>> +
> >>> +        if ( prev_ctx != current )
> >>> +        {
> >>> +            /*
> >>> +             * Doing a full context switch to a non-idle vCPU from a lazy
> >>> +             * context switched state.  Adjust current to point to the
> >>> +             * currently loaded vCPU context.
> >>> +             */
> >>> +            ASSERT(current == idle_vcpu[cpu]);
> >>> +            ASSERT(!is_idle_vcpu(next));
> >>> +            set_current(prev_ctx);
> >>
> >> This feels wrong, as in "current" then not representing what it should represent,
> >> for a certain time window. I may be dense, but neither comment not description
> >> clarify to me why this might be needed. I can see that it's needed to please the
> >> ASSERT() you add to __context_switch(), yet then I might ask why that assertion
> >> is put there.
> > 
> > This is done so that when calling __context_switch() current ==
> > curr_vcpu, and map_domain_page() can be used without getting into an
> > infinite sync_local_execstate() recursion loop.
> 
> Yet it's the purpose of __context_switch() to bring curr_vcpu in sync
> with current. IOW both matching up is supposed to be an exit condition
> of the function, not an entry one.
> 
> Plus, as indicated when we were talking this through yesterday, the
> set_current() here make "current" no longer point at what - from the
> scheduler's perspective - is (supposed to be) the current vCPU.

I understand this, and I will look into alternative ways to workaround
the issues I'm facing that prompted the changes proposed on this
patch.

I've been thinking about what we spoke of disabling lazy idle context
switch when ASI was enabled, and I'm afraid that won't be enough.  The
{populate,destroy}_perdomain_mapping() functions added later in the
series will be used in the context switch path regardless of whether
ASI is enabled, and those functions require map_domain_page() to be
usable.  Hence map_domain_page() needs to be usable in the context
switch path.

I will see whether I can allow the usage of map_domain_page() at
context switch in a different way.

I understand the main concern is the window where current and the
scheduler notion of current diverge right?

Arguably this is already happening in context_switch(), as
set_current() gets called almost at the beggining of the function,
while the call to sched_context_switched() only happens at the tail of
the function.  So for the whole call to  __context_switch() current is
not in-sync with the scheduler currently running vCPU.  And I'm not
saying this is a model to follow, but the context switch code is
already fairly special, hence I don't see the change here as that much
different from the current logic.

That said, I will still try to figure an alternative way to deal with
the usage of map_domain_page() in the context switch path.

> Aiui this adjustment is the reason for ...
> 
> >>> --- a/xen/arch/x86/traps.c
> >>> +++ b/xen/arch/x86/traps.c
> >>> @@ -2232,8 +2232,6 @@ void __init trap_init(void)
> >>>  
> >>>  void activate_debugregs(const struct vcpu *curr)
> >>>  {
> >>> -    ASSERT(curr == current);
> >>> -
> >>>      write_debugreg(0, curr->arch.dr[0]);
> >>>      write_debugreg(1, curr->arch.dr[1]);
> >>>      write_debugreg(2, curr->arch.dr[2]);
> >>
> >> Why would this assertion go away? If it suddenly triggers, the parameter name
> >> would now end up being wrong.
> > 
> > Well, at the point where activate_debugregs() gets called (in
> > paravirt_ctxt_switch_to()), current == previous as a result of this
> > change, so the assert is no longer true on purpose on that call
> > path.
> 
> ... this behavior. Which, as said, feels wrong the latest when "curr" was
> renamed to no longer suggest it actually is cached "current". At that point
> it'll be dubious whose ->arch.dr[] are actually written into the CPU
> registers.
> 
> Also let's not forget that there's a 2nd call here, where I very much hope
> it continues to be "current" that's being passed in.

Indeed, for the other call the assert would still be valid, that
context is not changed.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jan 17 15:26:04 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Jan 2025 15:26:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.874139.1284978 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYoEP-0006cu-Od; Fri, 17 Jan 2025 15:25:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 874139.1284978; Fri, 17 Jan 2025 15:25:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYoEP-0006cn-Lu; Fri, 17 Jan 2025 15:25:57 +0000
Received: by outflank-mailman (input) for mailman id 874139;
 Fri, 17 Jan 2025 15:25:55 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=qJiU=UJ=redhat.com=vschneid@srs-se1.protection.inumbo.net>)
 id 1tYoEN-0006ch-ST
 for xen-devel@lists.xenproject.org; Fri, 17 Jan 2025 15:25:55 +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 564383c3-d4e7-11ef-99a4-01e77a169b0f;
 Fri, 17 Jan 2025 16:25:53 +0100 (CET)
Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com
 [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-513-sKC4sGzLNkKbVaZaGvX9Pw-1; Fri, 17 Jan 2025 10:25:50 -0500
Received: by mail-wm1-f72.google.com with SMTP id
 5b1f17b1804b1-4361eb83f46so15909385e9.3
 for <xen-devel@lists.xenproject.org>; Fri, 17 Jan 2025 07:25:50 -0800 (PST)
Received: from vschneid-thinkpadt14sgen2i.remote.csb
 (213-44-141-166.abo.bbox.fr. [213.44.141.166])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438904621cdsm36969035e9.27.2025.01.17.07.25.45
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 17 Jan 2025 07:25:48 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 564383c3-d4e7-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1737127552;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=6DE9vuKFSEA1KS0VYNiNovYjAz7Lk/cPOvdu2tw3vf8=;
	b=ZKD9SAMF0FdqQu4ndh/Wo2Xlovg2Uw0ajlHS/AdumOQOZAn9AiDYzMgtNRjYOCharPikYE
	llcT8t44sI+jGA9ejcXOgmAI6/1jcxVhqi/eClUcHP4BhKJ9dZ1lmHj4NEl1SJgy7Ck1qH
	2wxAfLdZoMAtmGc9qN12FpplPdgIHkU=
X-MC-Unique: sKC4sGzLNkKbVaZaGvX9Pw-1
X-Mimecast-MFC-AGG-ID: sKC4sGzLNkKbVaZaGvX9Pw
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737127549; x=1737732349;
        h=content-transfer-encoding:mime-version:message-id:date:references
         :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=6DE9vuKFSEA1KS0VYNiNovYjAz7Lk/cPOvdu2tw3vf8=;
        b=Z0BUuPtSKvWk4xvx7Kx9K/MLApnMeexX92citbLwwpmEY5BdZdx66rdgt/rtW+hSRs
         mElEHiXNhvma6S8r6j1cUV4vP0kQN8XBzyJxBHWMNLepGSUuSBFmucfqYwOQXEihPdAr
         2B1KuH/pKlfMnSIpcsquAIVVEUnJj4ed+omrVFu2SJsKiCTwCtmY0RmKouZzSn/JBMfM
         SBxEE6LMx0oJqhb3qy6QjTxQc+woXI1Bw4zTUQghaZnAkM/hubHRB3MfyS46ikay1LPX
         eLSronKaMlNsPlJNohRidoUyHL81wiL42SDgHkzRilWKTbq8DYpG5wuOXIoEUvlCHYc0
         w5UA==
X-Forwarded-Encrypted: i=1; AJvYcCXpAvOlxJHVmcg5JIVnrN+e96bP70NTxmIn+O3vhBI0PrSl0+7vNYaX0xx6GmlsVzSTJHXoVpXGhWM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwfoXugEcZI5onOLiuhKX3QqRRIdOLbgYYLCOGF+Rp2fxlJNm8G
	pUJxRO8ba2WXq912FbYkfX3VWiEQMyHMoeJh+6auDxV11WfO50OqtwRfX6LM6OVDEcSlHO+CJGn
	snwyG9FgnksWqkJ9yNdDBpFVOhyckXFI4/v6ribBsBuEX22/552P/BwcTrPaUaHxw
X-Gm-Gg: ASbGncuEXUe9RhnxgSUizdvclV/pS44Zh+6M/3xCwULq7dQuxtmnXSGZj3AO3/eo4Nm
	3+xhxywNigMScrK5WSwvU57gCYjSNbV2axiZQniip/H9RLITqFRX7aAfZPRNQwpXyei3JWXJ+m3
	h2BMESpM2h+g3XgFzO1Vif+7cb2ZOdNTtamqz/PAXbrsGdXpl0A+dGq5HPDUuktxAbfRMbRidiR
	ScM7f7gLth0jDNP30fPHxa9Ut2wDFW9rYvdioP6ah2UiUW5bUIdXq6us2thZ1KC7zbX377cpCRY
	1e4CJxOopFsbMAa9FFJm+xksCF4EzAfecXD6dUbO8A==
X-Received: by 2002:a05:600c:3114:b0:434:a386:6cf with SMTP id 5b1f17b1804b1-438913bff57mr31772435e9.2.1737127549294;
        Fri, 17 Jan 2025 07:25:49 -0800 (PST)
X-Google-Smtp-Source: AGHT+IG0gMZqDwGTwzxqPbq5mivOriCCRRTxthl4OtSHet5NBdrE0Nd7orMMIHX4tKohkjx8g0xD5Q==
X-Received: by 2002:a05:600c:3114:b0:434:a386:6cf with SMTP id 5b1f17b1804b1-438913bff57mr31771625e9.2.1737127548862;
        Fri, 17 Jan 2025 07:25:48 -0800 (PST)
From: Valentin Schneider <vschneid@redhat.com>
To: Jann Horn <jannh@google.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
 virtualization@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
 loongarch@lists.linux.dev, linux-riscv@lists.infradead.org,
 linux-perf-users@vger.kernel.org, xen-devel@lists.xenproject.org,
 kvm@vger.kernel.org, linux-arch@vger.kernel.org, rcu@vger.kernel.org,
 linux-hardening@vger.kernel.org, linux-mm@kvack.org,
 linux-kselftest@vger.kernel.org, bpf@vger.kernel.org,
 bcm-kernel-feedback-list@broadcom.com, Juergen Gross <jgross@suse.com>,
 Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov
 <alexey.amakhalov@broadcom.com>, Russell King <linux@armlinux.org.uk>,
 Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>,
 Huacai Chen <chenhuacai@kernel.org>, WANG Xuerui <kernel@xen0n.name>, Paul
 Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>,
 Albert Ou <aou@eecs.berkeley.edu>, Thomas Gleixner <tglx@linutronix.de>,
 Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Dave
 Hansen <dave.hansen@linux.intel.com>, "H. Peter Anvin" <hpa@zytor.com>,
 Peter Zijlstra <peterz@infradead.org>, Arnaldo Carvalho de Melo
 <acme@kernel.org>, Namhyung Kim <namhyung@kernel.org>, Mark Rutland
 <mark.rutland@arm.com>, Alexander Shishkin
 <alexander.shishkin@linux.intel.com>, Jiri Olsa <jolsa@kernel.org>, Ian
 Rogers <irogers@google.com>, Adrian Hunter <adrian.hunter@intel.com>,
 "Liang, Kan" <kan.liang@linux.intel.com>, Boris Ostrovsky
 <boris.ostrovsky@oracle.com>, Josh Poimboeuf <jpoimboe@kernel.org>, Pawan
 Gupta <pawan.kumar.gupta@linux.intel.com>, Sean Christopherson
 <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, Andy Lutomirski
 <luto@kernel.org>, Arnd Bergmann <arnd@arndb.de>, Frederic Weisbecker
 <frederic@kernel.org>, "Paul E. McKenney" <paulmck@kernel.org>, Jason
 Baron <jbaron@akamai.com>, Steven Rostedt <rostedt@goodmis.org>, Ard
 Biesheuvel <ardb@kernel.org>, Neeraj Upadhyay
 <neeraj.upadhyay@kernel.org>, Joel Fernandes <joel@joelfernandes.org>,
 Josh Triplett <josh@joshtriplett.org>, Boqun Feng <boqun.feng@gmail.com>,
 Uladzislau Rezki <urezki@gmail.com>, Mathieu Desnoyers
 <mathieu.desnoyers@efficios.com>, Lai Jiangshan <jiangshanlai@gmail.com>,
 Zqiang <qiang.zhang1211@gmail.com>, Juri Lelli <juri.lelli@redhat.com>,
 Clark Williams <williams@redhat.com>, Yair Podemsky <ypodemsk@redhat.com>,
 Tomas Glozar <tglozar@redhat.com>, Vincent Guittot
 <vincent.guittot@linaro.org>, Dietmar Eggemann <dietmar.eggemann@arm.com>,
 Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>, Kees Cook
 <kees@kernel.org>, Andrew Morton <akpm@linux-foundation.org>, Christoph
 Hellwig <hch@infradead.org>, Shuah Khan <shuah@kernel.org>, Sami Tolvanen
 <samitolvanen@google.com>, Miguel Ojeda <ojeda@kernel.org>, Alice Ryhl
 <aliceryhl@google.com>, "Mike Rapoport (Microsoft)" <rppt@kernel.org>,
 Samuel Holland <samuel.holland@sifive.com>, Rong Xu <xur@google.com>,
 Nicolas Saenz Julienne <nsaenzju@redhat.com>, Geert Uytterhoeven
 <geert@linux-m68k.org>, Yosry Ahmed <yosryahmed@google.com>, "Kirill A.
 Shutemov" <kirill.shutemov@linux.intel.com>, "Masami Hiramatsu (Google)"
 <mhiramat@kernel.org>, Jinghao Jia <jinghao7@illinois.edu>, Luis
 Chamberlain <mcgrof@kernel.org>, Randy Dunlap <rdunlap@infradead.org>,
 Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: Re: [PATCH v4 29/30] x86/mm, mm/vmalloc: Defer
 flush_tlb_kernel_range() targeting NOHZ_FULL CPUs
In-Reply-To: <CAG48ez1Mh+DOy0ysOo7Qioxh1W7xWQyK9CLGNU9TGOsLXbg=gQ@mail.gmail.com>
References: <20250114175143.81438-1-vschneid@redhat.com>
 <20250114175143.81438-30-vschneid@redhat.com>
 <CAG48ez1Mh+DOy0ysOo7Qioxh1W7xWQyK9CLGNU9TGOsLXbg=gQ@mail.gmail.com>
Date: Fri, 17 Jan 2025 16:25:45 +0100
Message-ID: <xhsmh34hhh37q.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
MIME-Version: 1.0
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: ATjCXxdmQCxVLhpOAR8DDm-s3NO7TdRw3Tpm6uMYK7Y_1737127549
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 14/01/25 19:16, Jann Horn wrote:
> On Tue, Jan 14, 2025 at 6:51=E2=80=AFPM Valentin Schneider <vschneid@redh=
at.com> wrote:
>> vunmap()'s issued from housekeeping CPUs are a relatively common source =
of
>> interference for isolated NOHZ_FULL CPUs, as they are hit by the
>> flush_tlb_kernel_range() IPIs.
>>
>> Given that CPUs executing in userspace do not access data in the vmalloc
>> range, these IPIs could be deferred until their next kernel entry.
>>
>> Deferral vs early entry danger zone
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>
>> This requires a guarantee that nothing in the vmalloc range can be vunma=
p'd
>> and then accessed in early entry code.
>
> In other words, it needs a guarantee that no vmalloc allocations that
> have been created in the vmalloc region while the CPU was idle can
> then be accessed during early entry, right?

I'm not sure if that would be a problem (not an mm expert, please do
correct me) - looking at vmap_pages_range(), flush_cache_vmap() isn't
deferred anyway.

So after vmapping something, I wouldn't expect isolated CPUs to have
invalid TLB entries for the newly vmapped page.

However, upon vunmap'ing something, the TLB flush is deferred, and thus
stale TLB entries can and will remain on isolated CPUs, up until they
execute the deferred flush themselves (IOW for the entire duration of the
"danger zone").

Does that make sense?



From xen-devel-bounces@lists.xenproject.org Fri Jan 17 15:53:14 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Jan 2025 15:53:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.874149.1284988 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYoeZ-0002vb-PX; Fri, 17 Jan 2025 15:52:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 874149.1284988; Fri, 17 Jan 2025 15:52:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYoeZ-0002vU-MD; Fri, 17 Jan 2025 15:52:59 +0000
Received: by outflank-mailman (input) for mailman id 874149;
 Fri, 17 Jan 2025 15:52: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 <SRS0=atmh=UJ=google.com=jannh@srs-se1.protection.inumbo.net>)
 id 1tYoeY-0002vN-PX
 for xen-devel@lists.xenproject.org; Fri, 17 Jan 2025 15:52:58 +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 1ebc7f12-d4eb-11ef-a0e2-8be0dac302b0;
 Fri, 17 Jan 2025 16:52:57 +0100 (CET)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-5d0c939ab78so9596a12.0
 for <xen-devel@lists.xenproject.org>; Fri, 17 Jan 2025 07:52:57 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1ebc7f12-d4eb-11ef-a0e2-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20230601; t=1737129176; x=1737733976; 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=E7d+TpfXp3p6m5vGusLumGYBM9vV8hEetyox2i/2Tk8=;
        b=NnTfXfW+Z8rGhZbSJjPWOpNwlgYW8eT1U1QES5cnRgSMP+N5RJb1wHamneYkhL7mz4
         kPmgqhcfl+CwkVnl4R3Gg+fw5oZV0PmZ4mgGsfubGaV7rWdE4/s4iDKG4C+oZK8EFdIm
         te+th+e3TKpMLHvFgS3m2l5PC1SRgJMc8By14IwHYponjNTZgqC+IP6rBpOp0skHlwnS
         75LkRRrgTZNUAxK31MqBvBQrrMxL4r+rxmwyMKpplpV8YctT5Us5Y5NycAPEGuguurQd
         +hSE4que46dbrYFJVRGTuBjrTMx2CA1RnrWIB1D1g5bP0LHz4PeCnphrzzvjb6jdi0JN
         pEQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737129176; x=1737733976;
        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=E7d+TpfXp3p6m5vGusLumGYBM9vV8hEetyox2i/2Tk8=;
        b=Whosc2vMV0SbSnxtfTSULoaJDlWRcofPeXmt6lBdds7f0FMgYAtH17nF8N1v2s8PPr
         xwcu3xl+K4ucDOiae5X0+suD0TKUXUTPjSCH2Cm6bq9q2ztPtKi2c8NN7okphgFHoq8v
         JiSm/yGShuns9M0wV2sP6P2vT84pv81pKFoTYdiAysFix33nvEerSArfF2Q4w7OTFoO6
         0/N4b0UBG/r92216WdXOwO1KrPmdx5z0s4brM6VCbnG0IxP+TLZ6C9pvnDqZXvYYb8dT
         28FXD0HNeglUqYg2DRe519dJsUNGxV7cEbqcsLmoF5IwaPJeGRF11+wvWEBGtQivV5EM
         epHQ==
X-Forwarded-Encrypted: i=1; AJvYcCXYbUWQJP3OJDGlrlilqwhbdtVzL7NnHwoJskwwZYSVkXlamNVTQsj0b/kGr65ehyAhNAO0RYms3YE=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywy4aqFeDYP4Yko2pL2xbl+CCIwL0oUkJwfnqo2qk2hNWDtA+l2
	m4XQXuRY1qRqTnPyDeQumqgTJLK8lj8TWOvbEsVhjPiroeBvE3c1luhffCTjLvGxyfpRpG7x1Bx
	iYEEarhr3n3YWJoZpRU7upw7jI1grFbY8aTnh
X-Gm-Gg: ASbGnct+8030wI/S82BrO0JKS0E1qg8H+hugdyKaPLe4AS7dIY6iGy3Ql3HKbnkKaH4
	IbaAlNaaTsJ1zpnkT4T0N4PRhsBgl+tL6KieJRjdOveG1HpLrz0Ptv21BqycVCrvpEg==
X-Google-Smtp-Source: AGHT+IEEkI7Iy2SK9FPAK0t7gLelF/8kGvCq2TFqgDI01h52pfAV4lOJlwJrdbZvw3hEJ10c/9do3FNZA9vfJuC5wNY=
X-Received: by 2002:a50:8e10:0:b0:5d0:acf3:e3a6 with SMTP id
 4fb4d7f45d1cf-5db7e2c3f9dmr75503a12.1.1737129175787; Fri, 17 Jan 2025
 07:52:55 -0800 (PST)
MIME-Version: 1.0
References: <20250114175143.81438-1-vschneid@redhat.com> <20250114175143.81438-30-vschneid@redhat.com>
 <CAG48ez1Mh+DOy0ysOo7Qioxh1W7xWQyK9CLGNU9TGOsLXbg=gQ@mail.gmail.com> <xhsmh34hhh37q.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
In-Reply-To: <xhsmh34hhh37q.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
From: Jann Horn <jannh@google.com>
Date: Fri, 17 Jan 2025 16:52:19 +0100
X-Gm-Features: AbW1kvZJ0qyEwdtkrx_UmrEU0O4aMmTblOKPsNQ-aUYqHdGS_cvMGi3arE1PehU
Message-ID: <CAG48ez3H8OVP1GxBLdmFgusvT1gQhwu2SiXbgi8T9uuCYVK52w@mail.gmail.com>
Subject: Re: [PATCH v4 29/30] x86/mm, mm/vmalloc: Defer flush_tlb_kernel_range()
 targeting NOHZ_FULL CPUs
To: Valentin Schneider <vschneid@redhat.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org, 
	virtualization@lists.linux.dev, linux-arm-kernel@lists.infradead.org, 
	loongarch@lists.linux.dev, linux-riscv@lists.infradead.org, 
	linux-perf-users@vger.kernel.org, xen-devel@lists.xenproject.org, 
	kvm@vger.kernel.org, linux-arch@vger.kernel.org, rcu@vger.kernel.org, 
	linux-hardening@vger.kernel.org, linux-mm@kvack.org, 
	linux-kselftest@vger.kernel.org, bpf@vger.kernel.org, 
	bcm-kernel-feedback-list@broadcom.com, Juergen Gross <jgross@suse.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.amakhalov@broadcom.com>, 
	Russell King <linux@armlinux.org.uk>, Catalin Marinas <catalin.marinas@arm.com>, 
	Will Deacon <will@kernel.org>, Huacai Chen <chenhuacai@kernel.org>, WANG Xuerui <kernel@xen0n.name>, 
	Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, 
	Albert Ou <aou@eecs.berkeley.edu>, Thomas Gleixner <tglx@linutronix.de>, 
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, 
	Dave Hansen <dave.hansen@linux.intel.com>, "H. Peter Anvin" <hpa@zytor.com>, 
	Peter Zijlstra <peterz@infradead.org>, Arnaldo Carvalho de Melo <acme@kernel.org>, 
	Namhyung Kim <namhyung@kernel.org>, Mark Rutland <mark.rutland@arm.com>, 
	Alexander Shishkin <alexander.shishkin@linux.intel.com>, Jiri Olsa <jolsa@kernel.org>, 
	Ian Rogers <irogers@google.com>, Adrian Hunter <adrian.hunter@intel.com>, 
	"Liang, Kan" <kan.liang@linux.intel.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>, 
	Josh Poimboeuf <jpoimboe@kernel.org>, Pawan Gupta <pawan.kumar.gupta@linux.intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	Andy Lutomirski <luto@kernel.org>, Arnd Bergmann <arnd@arndb.de>, 
	Frederic Weisbecker <frederic@kernel.org>, "Paul E. McKenney" <paulmck@kernel.org>, 
	Jason Baron <jbaron@akamai.com>, Steven Rostedt <rostedt@goodmis.org>, 
	Ard Biesheuvel <ardb@kernel.org>, Neeraj Upadhyay <neeraj.upadhyay@kernel.org>, 
	Joel Fernandes <joel@joelfernandes.org>, Josh Triplett <josh@joshtriplett.org>, 
	Boqun Feng <boqun.feng@gmail.com>, Uladzislau Rezki <urezki@gmail.com>, 
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>, Lai Jiangshan <jiangshanlai@gmail.com>, 
	Zqiang <qiang.zhang1211@gmail.com>, Juri Lelli <juri.lelli@redhat.com>, 
	Clark Williams <williams@redhat.com>, Yair Podemsky <ypodemsk@redhat.com>, 
	Tomas Glozar <tglozar@redhat.com>, Vincent Guittot <vincent.guittot@linaro.org>, 
	Dietmar Eggemann <dietmar.eggemann@arm.com>, Ben Segall <bsegall@google.com>, 
	Mel Gorman <mgorman@suse.de>, Kees Cook <kees@kernel.org>, 
	Andrew Morton <akpm@linux-foundation.org>, Christoph Hellwig <hch@infradead.org>, 
	Shuah Khan <shuah@kernel.org>, Sami Tolvanen <samitolvanen@google.com>, 
	Miguel Ojeda <ojeda@kernel.org>, Alice Ryhl <aliceryhl@google.com>, 
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>, Samuel Holland <samuel.holland@sifive.com>, Rong Xu <xur@google.com>, 
	Nicolas Saenz Julienne <nsaenzju@redhat.com>, Geert Uytterhoeven <geert@linux-m68k.org>, 
	Yosry Ahmed <yosryahmed@google.com>, 
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>, 
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>, Jinghao Jia <jinghao7@illinois.edu>, 
	Luis Chamberlain <mcgrof@kernel.org>, Randy Dunlap <rdunlap@infradead.org>, 
	Tiezhu Yang <yangtiezhu@loongson.cn>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 17, 2025 at 4:25=E2=80=AFPM Valentin Schneider <vschneid@redhat=
.com> wrote:
> On 14/01/25 19:16, Jann Horn wrote:
> > On Tue, Jan 14, 2025 at 6:51=E2=80=AFPM Valentin Schneider <vschneid@re=
dhat.com> wrote:
> >> vunmap()'s issued from housekeeping CPUs are a relatively common sourc=
e of
> >> interference for isolated NOHZ_FULL CPUs, as they are hit by the
> >> flush_tlb_kernel_range() IPIs.
> >>
> >> Given that CPUs executing in userspace do not access data in the vmall=
oc
> >> range, these IPIs could be deferred until their next kernel entry.
> >>
> >> Deferral vs early entry danger zone
> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >>
> >> This requires a guarantee that nothing in the vmalloc range can be vun=
map'd
> >> and then accessed in early entry code.
> >
> > In other words, it needs a guarantee that no vmalloc allocations that
> > have been created in the vmalloc region while the CPU was idle can
> > then be accessed during early entry, right?
>
> I'm not sure if that would be a problem (not an mm expert, please do
> correct me) - looking at vmap_pages_range(), flush_cache_vmap() isn't
> deferred anyway.

flush_cache_vmap() is about stuff like flushing data caches on
architectures with virtually indexed caches; that doesn't do TLB
maintenance. When you look for its definition on x86 or arm64, you'll
see that they use the generic implementation which is simply an empty
inline function.

> So after vmapping something, I wouldn't expect isolated CPUs to have
> invalid TLB entries for the newly vmapped page.
>
> However, upon vunmap'ing something, the TLB flush is deferred, and thus
> stale TLB entries can and will remain on isolated CPUs, up until they
> execute the deferred flush themselves (IOW for the entire duration of the
> "danger zone").
>
> Does that make sense?

The design idea wrt TLB flushes in the vmap code is that you don't do
TLB flushes when you unmap stuff or when you map stuff, because doing
TLB flushes across the entire system on every vmap/vunmap would be a
bit costly; instead you just do batched TLB flushes in between, in
__purge_vmap_area_lazy().

In other words, the basic idea is that you can keep calling vmap() and
vunmap() a bunch of times without ever doing TLB flushes until you run
out of virtual memory in the vmap region; then you do one big TLB
flush, and afterwards you can reuse the free virtual address space for
new allocations again.

So if you "defer" that batched TLB flush for CPUs that are not
currently running in the kernel, I think the consequence is that those
CPUs may end up with incoherent TLB state after a reallocation of the
virtual address space.

Actually, I think this would mean that your optimization is disallowed
at least on arm64 - I'm not sure about the exact wording, but arm64
has a "break before make" rule that forbids conflicting writable
address translations or something like that.

(I said "until you run out of virtual memory in the vmap region", but
that's not actually true - see the comment above lazy_max_pages() for
an explanation of the actual heuristic. You might be able to tune that
a bit if you'd be significantly happier with less frequent
interruptions, or something along those lines.)


From xen-devel-bounces@lists.xenproject.org Fri Jan 17 16:12:10 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Jan 2025 16:12:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.874171.1284997 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYox2-0006pj-A6; Fri, 17 Jan 2025 16:12:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 874171.1284997; Fri, 17 Jan 2025 16:12:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYox2-0006pc-77; Fri, 17 Jan 2025 16:12:04 +0000
Received: by outflank-mailman (input) for mailman id 874171;
 Fri, 17 Jan 2025 16:11:40 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=eQyO=UJ=gmail.com=urezki@srs-se1.protection.inumbo.net>)
 id 1tYowe-0006kM-3L
 for xen-devel@lists.xenproject.org; Fri, 17 Jan 2025 16:11:40 +0000
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com
 [2a00:1450:4864:20::230])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id baf77065-d4ed-11ef-99a4-01e77a169b0f;
 Fri, 17 Jan 2025 17:11:38 +0100 (CET)
Received: by mail-lj1-x230.google.com with SMTP id
 38308e7fff4ca-3003d7ca01cso23310981fa.0
 for <xen-devel@lists.xenproject.org>; Fri, 17 Jan 2025 08:11:38 -0800 (PST)
Received: from pc636 (host-217-213-93-172.mobileonline.telia.com.
 [217.213.93.172]) by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-3072a4ed4bcsm4854351fa.71.2025.01.17.08.11.32
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 17 Jan 2025 08:11:36 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: baf77065-d4ed-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1737130297; x=1737735097; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:date:from:from:to
         :cc:subject:date:message-id:reply-to;
        bh=Mwf/8xvajfVfuiw0AKepwMJBFKP0lwWuKM/onBPK6d8=;
        b=O1yQKD2+UYVjPQ2lKONAEbVFOKhcWo/CsSCSwsSiAgF5jzViZPoje6R6aXra2QLwSD
         DpQq67KJqXsQFttBnxgVAlpO8eqd95oMV8CrZ9deHOcOIeggc3z3sbfIlIYUGEyC7XaJ
         XbJGRpta+ZUP8U4BzwL8xUSiyynGfYWwHE/LUOfGm6CB3Sf0zvewhmiyi3aEL2pzrCEU
         smAQ4JGhpUSvDUp0T1GgEhzTXUulH1fP5pkbvwF/59HRB4zLqrFFYX1IaPmXzkg5oxWD
         K7cytEli4rIAOyLCHeMxRLznZBXRjzbbmQh4kT886OAwFsTz963iDLoIXLqCdYJXkQQL
         n5MQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737130297; x=1737735097;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:date:from
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Mwf/8xvajfVfuiw0AKepwMJBFKP0lwWuKM/onBPK6d8=;
        b=AH7z2xe5O6pw9Pp+R54TH8vLus4nY2+/D4hj4eBI7Rar20hzocx39uJwOCy2OEA8Hq
         18p2XCghBlBo+RiAw3n4xDyhRMqIMb1izdhhuSV9MBhaA/PI0pDlgBzIWaucUrDFYdYF
         e91fvr+kkyR9fzGHMwSRfc9MHvAXpLUf1laomm+iQDSLDWoKiX0Fi0EAI1uZ/JguqURT
         w1cvtvRUo4C+yeHNV7bY79CuURpBR0zu+6xTevppkx5inirjjloH6MGfa9dIqVE9xU0q
         XyBQSkaKVFxetPF7dwgNoxVKxetJEY15k9ywx2rMvCC06H98OJWd8QQhPIkY5qt0KbRc
         guhw==
X-Forwarded-Encrypted: i=1; AJvYcCURGfiJrbltvkbJFqZu1JRKhQw4Y9KKh1AoUDbChbtsSh9kUpqgTO4UeVV+ZdRb/asWI0izqEbcwmc=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz6TCUKl4e2gI3Zvdaz6hHIWbTJqO0nJTz26LuM1AtBavAq8bz9
	ari6AfWKgkaFj/sHIpcN4gs0982BZ+j6hzivgiuzjlK9ize8+mn4
X-Gm-Gg: ASbGnct1dXArnQfz9vVGfiO4m0HRUpxfriQ9JZ2k5fQIeeJJNb0ttkcwv0EQWajog/+
	fKvVHY93Ma4C0hgaZyyuivf+VgdnVYgt+xXuhKeG/cxCtDPSnNrQTy7qGw1kEOobjfnt7aVTdzL
	KJFvLeX7H0KhrX8CNJPM2Er7arm9DrSAfKjtKJZuoSuN32DfatK1o+8a5k07MlNUUTs16NPbMl+
	egwbpgoJoxSfam8EGYlLHWsv+EL7RAfdkK1zuHeYvQmd4IlKWBVbZixDl8Uo1gRMwjiNjDQR1r5
	pmQEzHx1h6k=
X-Google-Smtp-Source: AGHT+IFH9kfhzB42dITXdZg9xXnIuIrCtLCGkWK8kDwmfncKlFAzifmDHoUZVUHtKkW5iC7Zz8oHDA==
X-Received: by 2002:a2e:bc27:0:b0:302:40ec:a1b3 with SMTP id 38308e7fff4ca-3072caa166amr12690871fa.21.1737130297134;
        Fri, 17 Jan 2025 08:11:37 -0800 (PST)
From: Uladzislau Rezki <urezki@gmail.com>
X-Google-Original-From: Uladzislau Rezki <urezki@pc636>
Date: Fri, 17 Jan 2025 17:11:30 +0100
To: Valentin Schneider <vschneid@redhat.com>
Cc: Jann Horn <jannh@google.com>, linux-kernel@vger.kernel.org,
	x86@kernel.org, virtualization@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev,
	linux-riscv@lists.infradead.org, linux-perf-users@vger.kernel.org,
	xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
	linux-arch@vger.kernel.org, rcu@vger.kernel.org,
	linux-hardening@vger.kernel.org, linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org, bpf@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com,
	Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.amakhalov@broadcom.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andy Lutomirski <luto@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Clark Williams <williams@redhat.com>,
	Yair Podemsky <ypodemsk@redhat.com>,
	Tomas Glozar <tglozar@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
	Kees Cook <kees@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Shuah Khan <shuah@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Miguel Ojeda <ojeda@kernel.org>, Alice Ryhl <aliceryhl@google.com>,
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
	Samuel Holland <samuel.holland@sifive.com>,
	Rong Xu <xur@google.com>,
	Nicolas Saenz Julienne <nsaenzju@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Yosry Ahmed <yosryahmed@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Jinghao Jia <jinghao7@illinois.edu>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: Re: [PATCH v4 29/30] x86/mm, mm/vmalloc: Defer
 flush_tlb_kernel_range() targeting NOHZ_FULL CPUs
Message-ID: <Z4qBMqcMg16p57av@pc636>
References: <20250114175143.81438-1-vschneid@redhat.com>
 <20250114175143.81438-30-vschneid@redhat.com>
 <CAG48ez1Mh+DOy0ysOo7Qioxh1W7xWQyK9CLGNU9TGOsLXbg=gQ@mail.gmail.com>
 <xhsmh34hhh37q.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <xhsmh34hhh37q.mognet@vschneid-thinkpadt14sgen2i.remote.csb>

On Fri, Jan 17, 2025 at 04:25:45PM +0100, Valentin Schneider wrote:
> On 14/01/25 19:16, Jann Horn wrote:
> > On Tue, Jan 14, 2025 at 6:51 PM Valentin Schneider <vschneid@redhat.com> wrote:
> >> vunmap()'s issued from housekeeping CPUs are a relatively common source of
> >> interference for isolated NOHZ_FULL CPUs, as they are hit by the
> >> flush_tlb_kernel_range() IPIs.
> >>
> >> Given that CPUs executing in userspace do not access data in the vmalloc
> >> range, these IPIs could be deferred until their next kernel entry.
> >>
> >> Deferral vs early entry danger zone
> >> ===================================
> >>
> >> This requires a guarantee that nothing in the vmalloc range can be vunmap'd
> >> and then accessed in early entry code.
> >
> > In other words, it needs a guarantee that no vmalloc allocations that
> > have been created in the vmalloc region while the CPU was idle can
> > then be accessed during early entry, right?
> 
> I'm not sure if that would be a problem (not an mm expert, please do
> correct me) - looking at vmap_pages_range(), flush_cache_vmap() isn't
> deferred anyway.
> 
> So after vmapping something, I wouldn't expect isolated CPUs to have
> invalid TLB entries for the newly vmapped page.
> 
> However, upon vunmap'ing something, the TLB flush is deferred, and thus
> stale TLB entries can and will remain on isolated CPUs, up until they
> execute the deferred flush themselves (IOW for the entire duration of the
> "danger zone").
> 
> Does that make sense?
> 
Probably i am missing something and need to have a look at your patches,
but how do you guarantee that no-one map same are that you defer for TLB
flushing?

As noted by Jann, we already defer a TLB flushing by backing freed areas
until certain threshold and just after we cross it we do a flush.

--
Uladzislau Rezki


From xen-devel-bounces@lists.xenproject.org Fri Jan 17 16:54:04 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Jan 2025 16:54:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.874202.1285009 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYpbQ-0005DQ-Ax; Fri, 17 Jan 2025 16:53:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 874202.1285009; Fri, 17 Jan 2025 16:53:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYpbQ-0005DJ-6s; Fri, 17 Jan 2025 16:53:48 +0000
Received: by outflank-mailman (input) for mailman id 874202;
 Fri, 17 Jan 2025 16:53:46 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=qJiU=UJ=redhat.com=vschneid@srs-se1.protection.inumbo.net>)
 id 1tYpbO-0005DD-UI
 for xen-devel@lists.xenproject.org; Fri, 17 Jan 2025 16:53:46 +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 9b6ff134-d4f3-11ef-99a4-01e77a169b0f;
 Fri, 17 Jan 2025 17:53:43 +0100 (CET)
Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com
 [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-467-EKBD1GyOOIW1w5QFNhuGPw-1; Fri, 17 Jan 2025 11:53:38 -0500
Received: by mail-wr1-f70.google.com with SMTP id
 ffacd0b85a97d-38a35a65575so1875760f8f.1
 for <xen-devel@lists.xenproject.org>; Fri, 17 Jan 2025 08:53:38 -0800 (PST)
Received: from vschneid-thinkpadt14sgen2i.remote.csb
 (213-44-141-166.abo.bbox.fr. [213.44.141.166])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38bf3221db2sm2893201f8f.29.2025.01.17.08.53.33
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 17 Jan 2025 08:53:36 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9b6ff134-d4f3-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1737132822;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=N/IFo0/H4hlssGmiFiddM6Zrvy7F7bLkhW3DK1UInsM=;
	b=CU/jQxKR6Lxejify8Dv6s70MhiYLa9fQaHLYrIzNorFYcEZMbqQqI7XLQGt44XjmUZQD64
	eMRYE7dF5zBwa0KohAOQu3LEvFPc+1OiLpnbaJJLPwD1vC3zevvvnzfp8dcZkcmOrARkEQ
	HXCM7ovQjonbg6tRdnpJx5LZ3ND7WrU=
X-MC-Unique: EKBD1GyOOIW1w5QFNhuGPw-1
X-Mimecast-MFC-AGG-ID: EKBD1GyOOIW1w5QFNhuGPw
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737132817; x=1737737617;
        h=content-transfer-encoding:mime-version:message-id:date:references
         :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=zS2KlTiZnGu6aQKTYj9yMifWHTI073WZ1gonGb0ZMuU=;
        b=o4CnZJjk/1N61FEJaCKrH9/w4jlDSOm1ytGW1JcWsv6MUMrfyw/G5uwZM/n12YR5o7
         RsZ9d4fkVa9JzDnbTpQVeqSsEJGbqKfAxV4wW/UVMPxBserK2FBdpLKvusDYZuRPkCwk
         BKMDJMAr7UnqWQdSGIu61ysc2zWSEsC17BCVCNBVX0pj5hSBXbA4WGoh8i87SxZlNxaH
         WC5ZP7RLXMy7dIWmVa+Se1Am9Th5uoS7ySlT+bqFuTVtGIt0NK9RqzoOU+0vIwYeFnw6
         PSJbq29IMfoVBPctOe3el1vArmH9SRzCP9Ob55TDrSypAMLU1HIZjLPfNPSAGWEUr+d1
         2SPw==
X-Forwarded-Encrypted: i=1; AJvYcCWHYmyPo2r9vJio965rKDCXTGWrWhCXfDnbeZM8rM0NSz8ilF5hoimMuta3IPa+b1Pb7kVp4g14te8=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx2gsFN4IC/6Q8VX3F+P4bWTTjsxEbwa26T6OyWHbZOCdX1QtBD
	MpgJKKoh1bu3Lm+c7hHWDG5g3kPp3p99rONMyavXjDDl2YrRPjfjNaM54ggiwHBz4UuP1noDMNO
	5j25UYLSHak30MMGExI7z3+6h6/cZtSREKVnf82PRVIVwGd81AyUza64IrMPfSSrf
X-Gm-Gg: ASbGncuOEc5tVHck4jCkUnOEfFa+vxIxunKhFEMATVddu3+Vd78SLfg3bg4gk8ChDz2
	O8bRzlWnE3oXA4mxnDfDFvQ6qOkuMWCae2NfJwPVuIurmX9zksvfeKoXPH3nqH9JGa6DJgiDe+S
	SeVhHpHwCfE3eLfqi5Po4zNjOchdGB7bd8vsMbx38nZkD1TCipH1UxInvc7LXFaCHG/Z4ocXWlV
	lPSvlG2F4a0xG1NltB7UJVMYUh7mvsSXXdpkOJMD3wr/PZ4UC3WKKOGLZdFbLIT5qhBmoYadKBu
	s+vmhTKIIhN2AAXYBq2peX3oBGOhkytK2Ig5kEhcxA==
X-Received: by 2002:a5d:6da4:0:b0:38b:e32a:10a6 with SMTP id ffacd0b85a97d-38bf57a9932mr3394924f8f.41.1737132817348;
        Fri, 17 Jan 2025 08:53:37 -0800 (PST)
X-Google-Smtp-Source: AGHT+IGgg/tn25OOVaMMDMlg+FUQ1oxKEYFZYFbhCFaXXhI5w4vXLbPHJsNwkMnyD4aTZ+GRHXAAGg==
X-Received: by 2002:a5d:6da4:0:b0:38b:e32a:10a6 with SMTP id ffacd0b85a97d-38bf57a9932mr3394815f8f.41.1737132816637;
        Fri, 17 Jan 2025 08:53:36 -0800 (PST)
From: Valentin Schneider <vschneid@redhat.com>
To: Jann Horn <jannh@google.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
 virtualization@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
 loongarch@lists.linux.dev, linux-riscv@lists.infradead.org,
 linux-perf-users@vger.kernel.org, xen-devel@lists.xenproject.org,
 kvm@vger.kernel.org, linux-arch@vger.kernel.org, rcu@vger.kernel.org,
 linux-hardening@vger.kernel.org, linux-mm@kvack.org,
 linux-kselftest@vger.kernel.org, bpf@vger.kernel.org,
 bcm-kernel-feedback-list@broadcom.com, Juergen Gross <jgross@suse.com>,
 Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov
 <alexey.amakhalov@broadcom.com>, Russell King <linux@armlinux.org.uk>,
 Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>,
 Huacai Chen <chenhuacai@kernel.org>, WANG Xuerui <kernel@xen0n.name>, Paul
 Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>,
 Albert Ou <aou@eecs.berkeley.edu>, Thomas Gleixner <tglx@linutronix.de>,
 Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Dave
 Hansen <dave.hansen@linux.intel.com>, "H. Peter Anvin" <hpa@zytor.com>,
 Peter Zijlstra <peterz@infradead.org>, Arnaldo Carvalho de Melo
 <acme@kernel.org>, Namhyung Kim <namhyung@kernel.org>, Mark Rutland
 <mark.rutland@arm.com>, Alexander Shishkin
 <alexander.shishkin@linux.intel.com>, Jiri Olsa <jolsa@kernel.org>, Ian
 Rogers <irogers@google.com>, Adrian Hunter <adrian.hunter@intel.com>,
 "Liang, Kan" <kan.liang@linux.intel.com>, Boris Ostrovsky
 <boris.ostrovsky@oracle.com>, Josh Poimboeuf <jpoimboe@kernel.org>, Pawan
 Gupta <pawan.kumar.gupta@linux.intel.com>, Sean Christopherson
 <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, Andy Lutomirski
 <luto@kernel.org>, Arnd Bergmann <arnd@arndb.de>, Frederic Weisbecker
 <frederic@kernel.org>, "Paul E. McKenney" <paulmck@kernel.org>, Jason
 Baron <jbaron@akamai.com>, Steven Rostedt <rostedt@goodmis.org>, Ard
 Biesheuvel <ardb@kernel.org>, Neeraj Upadhyay
 <neeraj.upadhyay@kernel.org>, Joel Fernandes <joel@joelfernandes.org>,
 Josh Triplett <josh@joshtriplett.org>, Boqun Feng <boqun.feng@gmail.com>,
 Uladzislau Rezki <urezki@gmail.com>, Mathieu Desnoyers
 <mathieu.desnoyers@efficios.com>, Lai Jiangshan <jiangshanlai@gmail.com>,
 Zqiang <qiang.zhang1211@gmail.com>, Juri Lelli <juri.lelli@redhat.com>,
 Clark Williams <williams@redhat.com>, Yair Podemsky <ypodemsk@redhat.com>,
 Tomas Glozar <tglozar@redhat.com>, Vincent Guittot
 <vincent.guittot@linaro.org>, Dietmar Eggemann <dietmar.eggemann@arm.com>,
 Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>, Kees Cook
 <kees@kernel.org>, Andrew Morton <akpm@linux-foundation.org>, Christoph
 Hellwig <hch@infradead.org>, Shuah Khan <shuah@kernel.org>, Sami Tolvanen
 <samitolvanen@google.com>, Miguel Ojeda <ojeda@kernel.org>, Alice Ryhl
 <aliceryhl@google.com>, "Mike Rapoport (Microsoft)" <rppt@kernel.org>,
 Samuel Holland <samuel.holland@sifive.com>, Rong Xu <xur@google.com>,
 Nicolas Saenz Julienne <nsaenzju@redhat.com>, Geert Uytterhoeven
 <geert@linux-m68k.org>, Yosry Ahmed <yosryahmed@google.com>, "Kirill A.
 Shutemov" <kirill.shutemov@linux.intel.com>, "Masami Hiramatsu (Google)"
 <mhiramat@kernel.org>, Jinghao Jia <jinghao7@illinois.edu>, Luis
 Chamberlain <mcgrof@kernel.org>, Randy Dunlap <rdunlap@infradead.org>,
 Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: Re: [PATCH v4 29/30] x86/mm, mm/vmalloc: Defer
 flush_tlb_kernel_range() targeting NOHZ_FULL CPUs
In-Reply-To: <CAG48ez3H8OVP1GxBLdmFgusvT1gQhwu2SiXbgi8T9uuCYVK52w@mail.gmail.com>
References: <20250114175143.81438-1-vschneid@redhat.com>
 <20250114175143.81438-30-vschneid@redhat.com>
 <CAG48ez1Mh+DOy0ysOo7Qioxh1W7xWQyK9CLGNU9TGOsLXbg=gQ@mail.gmail.com>
 <xhsmh34hhh37q.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
 <CAG48ez3H8OVP1GxBLdmFgusvT1gQhwu2SiXbgi8T9uuCYVK52w@mail.gmail.com>
Date: Fri, 17 Jan 2025 17:53:33 +0100
Message-ID: <xhsmhzfjpfkky.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
MIME-Version: 1.0
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: z44P9XNjjfHDsexF5_KeS0ZBe1z20L1YQHp0wxEzWKM_1737132817
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 17/01/25 16:52, Jann Horn wrote:
> On Fri, Jan 17, 2025 at 4:25=E2=80=AFPM Valentin Schneider <vschneid@redh=
at.com> wrote:
>> On 14/01/25 19:16, Jann Horn wrote:
>> > On Tue, Jan 14, 2025 at 6:51=E2=80=AFPM Valentin Schneider <vschneid@r=
edhat.com> wrote:
>> >> vunmap()'s issued from housekeeping CPUs are a relatively common sour=
ce of
>> >> interference for isolated NOHZ_FULL CPUs, as they are hit by the
>> >> flush_tlb_kernel_range() IPIs.
>> >>
>> >> Given that CPUs executing in userspace do not access data in the vmal=
loc
>> >> range, these IPIs could be deferred until their next kernel entry.
>> >>
>> >> Deferral vs early entry danger zone
>> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> >>
>> >> This requires a guarantee that nothing in the vmalloc range can be vu=
nmap'd
>> >> and then accessed in early entry code.
>> >
>> > In other words, it needs a guarantee that no vmalloc allocations that
>> > have been created in the vmalloc region while the CPU was idle can
>> > then be accessed during early entry, right?
>>
>> I'm not sure if that would be a problem (not an mm expert, please do
>> correct me) - looking at vmap_pages_range(), flush_cache_vmap() isn't
>> deferred anyway.
>
> flush_cache_vmap() is about stuff like flushing data caches on
> architectures with virtually indexed caches; that doesn't do TLB
> maintenance. When you look for its definition on x86 or arm64, you'll
> see that they use the generic implementation which is simply an empty
> inline function.
>
>> So after vmapping something, I wouldn't expect isolated CPUs to have
>> invalid TLB entries for the newly vmapped page.
>>
>> However, upon vunmap'ing something, the TLB flush is deferred, and thus
>> stale TLB entries can and will remain on isolated CPUs, up until they
>> execute the deferred flush themselves (IOW for the entire duration of th=
e
>> "danger zone").
>>
>> Does that make sense?
>
> The design idea wrt TLB flushes in the vmap code is that you don't do
> TLB flushes when you unmap stuff or when you map stuff, because doing
> TLB flushes across the entire system on every vmap/vunmap would be a
> bit costly; instead you just do batched TLB flushes in between, in
> __purge_vmap_area_lazy().
>
> In other words, the basic idea is that you can keep calling vmap() and
> vunmap() a bunch of times without ever doing TLB flushes until you run
> out of virtual memory in the vmap region; then you do one big TLB
> flush, and afterwards you can reuse the free virtual address space for
> new allocations again.
>
> So if you "defer" that batched TLB flush for CPUs that are not
> currently running in the kernel, I think the consequence is that those
> CPUs may end up with incoherent TLB state after a reallocation of the
> virtual address space.
>

Ah, gotcha, thank you for laying this out! In which case yes, any vmalloc
that occurred while an isolated CPU was NOHZ-FULL can be an issue if said
CPU accesses it during early entry;

> Actually, I think this would mean that your optimization is disallowed
> at least on arm64 - I'm not sure about the exact wording, but arm64
> has a "break before make" rule that forbids conflicting writable
> address translations or something like that.
>

On the bright side of things, arm64 is not as bad as x86 when it comes to
IPI'ing isolated CPUs :-) I'll add that to my notes, thanks!

> (I said "until you run out of virtual memory in the vmap region", but
> that's not actually true - see the comment above lazy_max_pages() for
> an explanation of the actual heuristic. You might be able to tune that
> a bit if you'd be significantly happier with less frequent
> interruptions, or something along those lines.)



From xen-devel-bounces@lists.xenproject.org Fri Jan 17 17:00:48 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Jan 2025 17:00:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.874213.1285025 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYpi6-0006qO-0y; Fri, 17 Jan 2025 17:00:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 874213.1285025; Fri, 17 Jan 2025 17:00:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYpi5-0006qH-Uj; Fri, 17 Jan 2025 17:00:41 +0000
Received: by outflank-mailman (input) for mailman id 874213;
 Fri, 17 Jan 2025 17:00:40 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=qJiU=UJ=redhat.com=vschneid@srs-se1.protection.inumbo.net>)
 id 1tYpi4-0006qB-KJ
 for xen-devel@lists.xenproject.org; Fri, 17 Jan 2025 17:00:40 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 92f2819d-d4f4-11ef-99a4-01e77a169b0f;
 Fri, 17 Jan 2025 18:00:38 +0100 (CET)
Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com
 [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-472-7UlXyWV1M9-rrHnyYzIydw-1; Fri, 17 Jan 2025 12:00:35 -0500
Received: by mail-wm1-f71.google.com with SMTP id
 5b1f17b1804b1-436219070b4so11176035e9.1
 for <xen-devel@lists.xenproject.org>; Fri, 17 Jan 2025 09:00:35 -0800 (PST)
Received: from vschneid-thinkpadt14sgen2i.remote.csb
 (213-44-141-166.abo.bbox.fr. [213.44.141.166])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-437c7499932sm99166875e9.7.2025.01.17.09.00.30
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 17 Jan 2025 09:00:32 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 92f2819d-d4f4-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1737133237;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=2zB9z7u7dclAVOo2ULVj1p74p7CXPvWK/XjFblVO3P8=;
	b=XnTWdTDEfozNSXhNWM4vP6dfiTPqEIhPGM045rIVLcdmL4NGUldnh+nOVCppvrcuAI0swS
	BCkWFgfEoKAgBmwv6p+s9DwqRnk4OUmz0+nZ0+k6v3NfvE7Jn8URZ87cfQkK0bF2wtRu7q
	7LuyEFJ/cZS3+Lrc1+qqV5lMdP33kww=
X-MC-Unique: 7UlXyWV1M9-rrHnyYzIydw-1
X-Mimecast-MFC-AGG-ID: 7UlXyWV1M9-rrHnyYzIydw
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737133234; x=1737738034;
        h=content-transfer-encoding:mime-version:message-id:date:references
         :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=XGvTpyNczRvA62kOrzrUa3TgLdL0aqoCD5BBfkghzOs=;
        b=oGLguCTzpAJiZ0jfrOJmzVmo6gpwDfeBUvI7QAS6WNyeQPBB6yMI/vd6PGUvP8uRKt
         s6JlBGqzCFET5wZlzsGqrsW0j0x7HVAN0uGl7sOy9nk6KxB4euwMbua4GOZ10n38NCmk
         y/V9qtH/muO8v4JzHmmCobB+y3ql+vEcRzrww2Wk1/0U+1YiyvMi/ldmP72S5jNSsMKt
         6XZ4R9cL+G2bEoJTxqC+ZvLP+rmlPLuwlhzCmkOpGFuMhszGItRsdiNquMGKI9PwUhds
         0n34iQxQMyHC7DWfXhd9Z8TAwID/upQxos0JpzvbxAYVfmPNQP0o6mbpCfwY86wXA/Yf
         6/QA==
X-Forwarded-Encrypted: i=1; AJvYcCU0JZuiTXZuq1dO2OpD1IdBT8JZMHCvnlzAiZEnAQyLaRfXhvFASqcMY9Crg5Eui+CvbszuEVOaGwU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxtWoJ4LbCxvLAn6yluJ5RL4WiO95F8giwB/DDcGlNMkBDQfGRZ
	ZoW8xY20Zz47qWasH7dRL9NBRsq8AxVPmQWiVrQ9oEuLpqtyLCtBk2Wx7vXiae9wcqccwwd06k2
	iD+oHSmeJT57GQJ3qJJHB2uBn+PFrDvHXTUhcxEj8fR1kHqfvcQEJV+iP2J9wScUy
X-Gm-Gg: ASbGnctoYAOSbcKWskBRSfxW3vS4zyzZiYgEVh+5TuGPc0Vd3sKpS+qUtr9z30wz9e0
	vzUdumXwjdCiUlgVmI3ZBmUmi5bvwY3h3OkvmVUQubd0OOh1vMFs47iMRvVR3wRp8Nh/reNf0D5
	bYO1zMwwHKwfoiWqxXWLAHFL9ymZmp5XctZQYtCn5FiGIj7rZTu/+vHusvg6m+/eRQDeUgnz4mL
	2RkojgPzuHtPGC0SjNGX+cRduvaroxOyQGhCheGI5ZCg+XhKv/jq1NJ9nkz51C+NJv233luGtRX
	of1ZD/ZALUCpaFWYGL08tXN9vPD/gJ4Sp327btckYQ==
X-Received: by 2002:a05:600c:3585:b0:434:9936:c823 with SMTP id 5b1f17b1804b1-438913ef6d0mr38317025e9.18.1737133234140;
        Fri, 17 Jan 2025 09:00:34 -0800 (PST)
X-Google-Smtp-Source: AGHT+IFagDashmtCONr1e0mPjwxw78kvxvfLwflTa5M+wz0yje22vE2jx/prTk0zBbNIWdtqILag4w==
X-Received: by 2002:a05:600c:3585:b0:434:9936:c823 with SMTP id 5b1f17b1804b1-438913ef6d0mr38315575e9.18.1737133233397;
        Fri, 17 Jan 2025 09:00:33 -0800 (PST)
From: Valentin Schneider <vschneid@redhat.com>
To: Uladzislau Rezki <urezki@gmail.com>
Cc: Jann Horn <jannh@google.com>, linux-kernel@vger.kernel.org,
 x86@kernel.org, virtualization@lists.linux.dev,
 linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev,
 linux-riscv@lists.infradead.org, linux-perf-users@vger.kernel.org,
 xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
 linux-arch@vger.kernel.org, rcu@vger.kernel.org,
 linux-hardening@vger.kernel.org, linux-mm@kvack.org,
 linux-kselftest@vger.kernel.org, bpf@vger.kernel.org,
 bcm-kernel-feedback-list@broadcom.com, Juergen Gross <jgross@suse.com>,
 Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov
 <alexey.amakhalov@broadcom.com>, Russell King <linux@armlinux.org.uk>,
 Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>,
 Huacai Chen <chenhuacai@kernel.org>, WANG Xuerui <kernel@xen0n.name>, Paul
 Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>,
 Albert Ou <aou@eecs.berkeley.edu>, Thomas Gleixner <tglx@linutronix.de>,
 Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Dave
 Hansen <dave.hansen@linux.intel.com>, "H. Peter Anvin" <hpa@zytor.com>,
 Peter Zijlstra <peterz@infradead.org>, Arnaldo Carvalho de Melo
 <acme@kernel.org>, Namhyung Kim <namhyung@kernel.org>, Mark Rutland
 <mark.rutland@arm.com>, Alexander Shishkin
 <alexander.shishkin@linux.intel.com>, Jiri Olsa <jolsa@kernel.org>, Ian
 Rogers <irogers@google.com>, Adrian Hunter <adrian.hunter@intel.com>,
 "Liang, Kan" <kan.liang@linux.intel.com>, Boris Ostrovsky
 <boris.ostrovsky@oracle.com>, Josh Poimboeuf <jpoimboe@kernel.org>, Pawan
 Gupta <pawan.kumar.gupta@linux.intel.com>, Sean Christopherson
 <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, Andy Lutomirski
 <luto@kernel.org>, Arnd Bergmann <arnd@arndb.de>, Frederic Weisbecker
 <frederic@kernel.org>, "Paul E. McKenney" <paulmck@kernel.org>, Jason
 Baron <jbaron@akamai.com>, Steven Rostedt <rostedt@goodmis.org>, Ard
 Biesheuvel <ardb@kernel.org>, Neeraj Upadhyay
 <neeraj.upadhyay@kernel.org>, Joel Fernandes <joel@joelfernandes.org>,
 Josh Triplett <josh@joshtriplett.org>, Boqun Feng <boqun.feng@gmail.com>,
 Uladzislau Rezki <urezki@gmail.com>, Mathieu Desnoyers
 <mathieu.desnoyers@efficios.com>, Lai Jiangshan <jiangshanlai@gmail.com>,
 Zqiang <qiang.zhang1211@gmail.com>, Juri Lelli <juri.lelli@redhat.com>,
 Clark Williams <williams@redhat.com>, Yair Podemsky <ypodemsk@redhat.com>,
 Tomas Glozar <tglozar@redhat.com>, Vincent Guittot
 <vincent.guittot@linaro.org>, Dietmar Eggemann <dietmar.eggemann@arm.com>,
 Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>, Kees Cook
 <kees@kernel.org>, Andrew Morton <akpm@linux-foundation.org>, Christoph
 Hellwig <hch@infradead.org>, Shuah Khan <shuah@kernel.org>, Sami Tolvanen
 <samitolvanen@google.com>, Miguel Ojeda <ojeda@kernel.org>, Alice Ryhl
 <aliceryhl@google.com>, "Mike Rapoport (Microsoft)" <rppt@kernel.org>,
 Samuel Holland <samuel.holland@sifive.com>, Rong Xu <xur@google.com>,
 Nicolas Saenz Julienne <nsaenzju@redhat.com>, Geert Uytterhoeven
 <geert@linux-m68k.org>, Yosry Ahmed <yosryahmed@google.com>, "Kirill A.
 Shutemov" <kirill.shutemov@linux.intel.com>, "Masami Hiramatsu (Google)"
 <mhiramat@kernel.org>, Jinghao Jia <jinghao7@illinois.edu>, Luis
 Chamberlain <mcgrof@kernel.org>, Randy Dunlap <rdunlap@infradead.org>,
 Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: Re: [PATCH v4 29/30] x86/mm, mm/vmalloc: Defer
 flush_tlb_kernel_range() targeting NOHZ_FULL CPUs
In-Reply-To: <Z4qBMqcMg16p57av@pc636>
References: <20250114175143.81438-1-vschneid@redhat.com>
 <20250114175143.81438-30-vschneid@redhat.com>
 <CAG48ez1Mh+DOy0ysOo7Qioxh1W7xWQyK9CLGNU9TGOsLXbg=gQ@mail.gmail.com>
 <xhsmh34hhh37q.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
 <Z4qBMqcMg16p57av@pc636>
Date: Fri, 17 Jan 2025 18:00:30 +0100
Message-ID: <xhsmhwmetfk9d.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
MIME-Version: 1.0
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: kVRq4oLRO_S5ZfeWoWHDrTHqWeGRIKERckk6iETv1QI_1737133234
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 17/01/25 17:11, Uladzislau Rezki wrote:
> On Fri, Jan 17, 2025 at 04:25:45PM +0100, Valentin Schneider wrote:
>> On 14/01/25 19:16, Jann Horn wrote:
>> > On Tue, Jan 14, 2025 at 6:51=E2=80=AFPM Valentin Schneider <vschneid@r=
edhat.com> wrote:
>> >> vunmap()'s issued from housekeeping CPUs are a relatively common sour=
ce of
>> >> interference for isolated NOHZ_FULL CPUs, as they are hit by the
>> >> flush_tlb_kernel_range() IPIs.
>> >>
>> >> Given that CPUs executing in userspace do not access data in the vmal=
loc
>> >> range, these IPIs could be deferred until their next kernel entry.
>> >>
>> >> Deferral vs early entry danger zone
>> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> >>
>> >> This requires a guarantee that nothing in the vmalloc range can be vu=
nmap'd
>> >> and then accessed in early entry code.
>> >
>> > In other words, it needs a guarantee that no vmalloc allocations that
>> > have been created in the vmalloc region while the CPU was idle can
>> > then be accessed during early entry, right?
>>
>> I'm not sure if that would be a problem (not an mm expert, please do
>> correct me) - looking at vmap_pages_range(), flush_cache_vmap() isn't
>> deferred anyway.
>>
>> So after vmapping something, I wouldn't expect isolated CPUs to have
>> invalid TLB entries for the newly vmapped page.
>>
>> However, upon vunmap'ing something, the TLB flush is deferred, and thus
>> stale TLB entries can and will remain on isolated CPUs, up until they
>> execute the deferred flush themselves (IOW for the entire duration of th=
e
>> "danger zone").
>>
>> Does that make sense?
>>
> Probably i am missing something and need to have a look at your patches,
> but how do you guarantee that no-one map same are that you defer for TLB
> flushing?
>

That's the cool part: I don't :')

For deferring instruction patching IPIs, I (well Josh really) managed to
get instrumentation to back me up and catch any problematic area.

I looked into getting something similar for vmalloc region access in
.noinstr code, but I didn't get anywhere. I even tried using emulated
watchpoints on QEMU to watch the whole vmalloc range, but that went about
as well as you could expect.

That left me with staring at code. AFAICT the only vmap'd thing that is
accessed during early entry is the task stack (CONFIG_VMAP_STACK), which
itself cannot be freed until the task exits - thus can't be subject to
invalidation when a task is entering kernelspace.

If you have any tracing/instrumentation suggestions, I'm all ears (eyes?).

> As noted by Jann, we already defer a TLB flushing by backing freed areas
> until certain threshold and just after we cross it we do a flush.
>
> --
> Uladzislau Rezki



From xen-devel-bounces@lists.xenproject.org Fri Jan 17 17:15:38 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Jan 2025 17:15:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.874229.1285036 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYpwT-0001IM-9Y; Fri, 17 Jan 2025 17:15:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 874229.1285036; Fri, 17 Jan 2025 17:15:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYpwT-0001IF-62; Fri, 17 Jan 2025 17:15:33 +0000
Received: by outflank-mailman (input) for mailman id 874229;
 Fri, 17 Jan 2025 17:15:32 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=F0h2=UJ=flex--seanjc.bounces.google.com=3MJCKZwYKCb0vhdqmfjrrjoh.frp0hq-ghyhoolvwv.0hqsurmhfw.ruj@srs-se1.protection.inumbo.net>)
 id 1tYpwS-0001I9-CP
 for xen-devel@lists.xenproject.org; Fri, 17 Jan 2025 17:15:32 +0000
Received: from mail-pl1-x64a.google.com (mail-pl1-x64a.google.com
 [2607:f8b0:4864:20::64a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a6e23de2-d4f6-11ef-a0e2-8be0dac302b0;
 Fri, 17 Jan 2025 18:15:31 +0100 (CET)
Received: by mail-pl1-x64a.google.com with SMTP id
 d9443c01a7336-2166a1a5cc4so43079535ad.3
 for <xen-devel@lists.xenproject.org>; Fri, 17 Jan 2025 09:15:31 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a6e23de2-d4f6-11ef-a0e2-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20230601; t=1737134129; x=1737738929; darn=lists.xenproject.org;
        h=cc:to:from:subject:message-id:references:mime-version:in-reply-to
         :date:from:to:cc:subject:date:message-id:reply-to;
        bh=/pcx17eniD+ASjh3teIfjrJN/d55a+1SMCIjE05N6Y0=;
        b=zJ8hUFM3xBr+KdxjyAxaSg5zYRmUp8FbyB6p1l1qiWNc5Nb00nrDTzNT1+LPKO5WIc
         AVhJWHY8dI5Eb96UTAoSBVnp2JkcHJphRSGuHexHukaSGEfBGyXhHgMQ1aE+NbRSu6sT
         Ufj9Wbx4foaHoczOdeZN7v6ouYMRhX5nd+9K+NRe2oWHEM6cc06v4eRRtpb9+Dd4h36y
         9gPmEhAda9Vdry0IPzVbaTSqiQ3ihpc0/h4JqXnFJzvxfw2wv5AoDx3aG6MWxa+mXcjD
         Dya1jww6jWtBs6hOiF8CEM/ERMi+V2gdAoaszJOSXyCP6RvRMcP0Oa5bKUmFgcxtaY1Y
         v8jA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737134129; x=1737738929;
        h=cc:to:from:subject:message-id:references:mime-version:in-reply-to
         :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=/pcx17eniD+ASjh3teIfjrJN/d55a+1SMCIjE05N6Y0=;
        b=NUbIMsitx8TcFBO9MXvmUdijDhrjCZ5FMAOGTAru3qNp30/ObxV4u8aN2mdfhK/QJv
         9q31TChOfEa6Gh4dbeFjQTGz7xaSs58YxC1++13jF1IFeU9pWbjRUMqhA3bQhTh509bH
         firrh1+d/g17jirooib9T2+rRK+NHqnPZ96Si5Ci92/SVcdNk/MUrxdxUXCZy3G/J3Wd
         ZJpToHYX6ijLaDmDLfocQMyJ/lcZtPDBxMCF0tZxstZojcPVPwYJjk10gpoGYi9g5BFd
         sJtGXakuNpSqnV6eIH6saSE/k+vWwmQ0mNY803HmyD1s/t3gllcolbgtWDoK5l7WCozT
         yIZg==
X-Forwarded-Encrypted: i=1; AJvYcCWsFPcNbhqRmtdc8pEp1E/Xqr9v3YXSceLeo1sIa0qXI2q1yaJmMKmfCrZGKDI/3/vY9AUiFzon5QY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwZZH3Qz65fUGsqjSZfL4wmnDFZLyE5KNX5brNcT1l8X9UN4+Nu
	t7P+WELT8ZIWgQHt06RXTD1JyLVu3fVnORZT1cDtbREGppngzlmmUDrozRjOTCzoBZRltozQE6l
	jHw==
X-Google-Smtp-Source: AGHT+IFBt8EUJmCBrYJSR6SbgIXxnZj6fm10TNGjaAj4XRK+x0dRIzGirCE9VGAaKkDPtl0zEYTqCFRnILs=
X-Received: from pfbcv2.prod.google.com ([2002:a05:6a00:44c2:b0:725:a760:4c72])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:148d:b0:725:eb85:f802
 with SMTP id d2e1a72fcca58-72daf930e3cmr5815077b3a.2.1737134128872; Fri, 17
 Jan 2025 09:15:28 -0800 (PST)
Date: Fri, 17 Jan 2025 09:15:27 -0800
In-Reply-To: <xhsmhed11hiuy.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
Mime-Version: 1.0
References: <20250114175143.81438-1-vschneid@redhat.com> <20250114175143.81438-26-vschneid@redhat.com>
 <Z4bTlZkqihaAyGb4@google.com> <xhsmhed11hiuy.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
Message-ID: <Z4qQL89GZ_gk0vpu@google.com>
Subject: Re: [PATCH v4 25/30] context_tracking,x86: Defer kernel text patching IPIs
From: Sean Christopherson <seanjc@google.com>
To: Valentin Schneider <vschneid@redhat.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org, 
	virtualization@lists.linux.dev, linux-arm-kernel@lists.infradead.org, 
	loongarch@lists.linux.dev, linux-riscv@lists.infradead.org, 
	linux-perf-users@vger.kernel.org, xen-devel@lists.xenproject.org, 
	kvm@vger.kernel.org, linux-arch@vger.kernel.org, rcu@vger.kernel.org, 
	linux-hardening@vger.kernel.org, linux-mm@kvack.org, 
	linux-kselftest@vger.kernel.org, bpf@vger.kernel.org, 
	bcm-kernel-feedback-list@broadcom.com, Peter Zijlstra <peterz@infradead.org>, 
	Nicolas Saenz Julienne <nsaenzju@redhat.com>, Juergen Gross <jgross@suse.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.amakhalov@broadcom.com>, 
	Russell King <linux@armlinux.org.uk>, Catalin Marinas <catalin.marinas@arm.com>, 
	Will Deacon <will@kernel.org>, Huacai Chen <chenhuacai@kernel.org>, WANG Xuerui <kernel@xen0n.name>, 
	Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, 
	Albert Ou <aou@eecs.berkeley.edu>, Thomas Gleixner <tglx@linutronix.de>, 
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, 
	Dave Hansen <dave.hansen@linux.intel.com>, "H. Peter Anvin" <hpa@zytor.com>, 
	Arnaldo Carvalho de Melo <acme@kernel.org>, Namhyung Kim <namhyung@kernel.org>, 
	Mark Rutland <mark.rutland@arm.com>, 
	Alexander Shishkin <alexander.shishkin@linux.intel.com>, Jiri Olsa <jolsa@kernel.org>, 
	Ian Rogers <irogers@google.com>, Adrian Hunter <adrian.hunter@intel.com>, 
	Kan Liang <kan.liang@linux.intel.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>, 
	Josh Poimboeuf <jpoimboe@kernel.org>, Pawan Gupta <pawan.kumar.gupta@linux.intel.com>, 
	Paolo Bonzini <pbonzini@redhat.com>, Andy Lutomirski <luto@kernel.org>, Arnd Bergmann <arnd@arndb.de>, 
	Frederic Weisbecker <frederic@kernel.org>, "Paul E. McKenney" <paulmck@kernel.org>, 
	Jason Baron <jbaron@akamai.com>, Steven Rostedt <rostedt@goodmis.org>, 
	Ard Biesheuvel <ardb@kernel.org>, Neeraj Upadhyay <neeraj.upadhyay@kernel.org>, 
	Joel Fernandes <joel@joelfernandes.org>, Josh Triplett <josh@joshtriplett.org>, 
	Boqun Feng <boqun.feng@gmail.com>, Uladzislau Rezki <urezki@gmail.com>, 
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>, Lai Jiangshan <jiangshanlai@gmail.com>, 
	Zqiang <qiang.zhang1211@gmail.com>, Juri Lelli <juri.lelli@redhat.com>, 
	Clark Williams <williams@redhat.com>, Yair Podemsky <ypodemsk@redhat.com>, 
	Tomas Glozar <tglozar@redhat.com>, Vincent Guittot <vincent.guittot@linaro.org>, 
	Dietmar Eggemann <dietmar.eggemann@arm.com>, Ben Segall <bsegall@google.com>, 
	Mel Gorman <mgorman@suse.de>, Kees Cook <kees@kernel.org>, 
	Andrew Morton <akpm@linux-foundation.org>, Christoph Hellwig <hch@infradead.org>, 
	Shuah Khan <shuah@kernel.org>, Sami Tolvanen <samitolvanen@google.com>, 
	Miguel Ojeda <ojeda@kernel.org>, Alice Ryhl <aliceryhl@google.com>, 
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>, Samuel Holland <samuel.holland@sifive.com>, Rong Xu <xur@google.com>, 
	Geert Uytterhoeven <geert@linux-m68k.org>, Yosry Ahmed <yosryahmed@google.com>, 
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>, 
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>, Jinghao Jia <jinghao7@illinois.edu>, 
	Luis Chamberlain <mcgrof@kernel.org>, Randy Dunlap <rdunlap@infradead.org>, 
	Tiezhu Yang <yangtiezhu@loongson.cn>
Content-Type: text/plain; charset="us-ascii"

On Fri, Jan 17, 2025, Valentin Schneider wrote:
> On 14/01/25 13:13, Sean Christopherson wrote:
> > On Tue, Jan 14, 2025, Valentin Schneider wrote:
> >> +/**
> >> + * is_kernel_noinstr_text - checks if the pointer address is located in the
> >> + *                    .noinstr section
> >> + *
> >> + * @addr: address to check
> >> + *
> >> + * Returns: true if the address is located in .noinstr, false otherwise.
> >> + */
> >> +static inline bool is_kernel_noinstr_text(unsigned long addr)
> >> +{
> >> +	return addr >= (unsigned long)__noinstr_text_start &&
> >> +	       addr < (unsigned long)__noinstr_text_end;
> >> +}
> >
> > This doesn't do the right thing for modules, which matters because KVM can be
> > built as a module on x86, and because context tracking understands transitions
> > to GUEST mode, i.e. CPUs that are running in a KVM guest will be treated as not
> > being in the kernel, and thus will have IPIs deferred.  If KVM uses a static key
> > or branch between guest_state_enter_irqoff() and guest_state_exit_irqoff(), the
> > patching code won't wait for CPUs to exit guest mode, i.e. KVM could theoretically
> > use the wrong static path.
> 
> AFAICT guest_state_{enter,exit}_irqoff() are only used in noinstr functions
> and thus such a static key usage should at the very least be caught and
> warned about by objtool - when this isn't built as a module.

That doesn't magically do the right thing though.  If KVM is built as a module,
is_kernel_noinstr_text() will get false negatives even for static keys/branches
that are annotaed as NOINSTR.


From xen-devel-bounces@lists.xenproject.org Fri Jan 17 20:20:38 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Jan 2025 20:20:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.874291.1285046 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYspK-00052G-Uc; Fri, 17 Jan 2025 20:20:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 874291.1285046; Fri, 17 Jan 2025 20:20:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYspK-000529-Rt; Fri, 17 Jan 2025 20:20:22 +0000
Received: by outflank-mailman (input) for mailman id 874291;
 Fri, 17 Jan 2025 20:20:21 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=dRtS=UJ=daemonizer.de=maxi@srs-se1.protection.inumbo.net>)
 id 1tYspJ-000523-0S
 for xen-devel@lists.xenproject.org; Fri, 17 Jan 2025 20:20:21 +0000
Received: from mx1.somlen.de (breeze.somlen.de [2a00:1828:a019::100:0])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 779ba34e-d510-11ef-99a4-01e77a169b0f;
 Fri, 17 Jan 2025 21:20:18 +0100 (CET)
Received: by mx1.somlen.de with ESMTPSA id 61BA25030C5;
 Fri, 17 Jan 2025 21:20:16 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 779ba34e-d510-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=daemonizer.de;
	s=202303; t=1737145216;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=U1f/FOsYILpgODc2jCY0Q8D48grq7mgyBUP9Wk8XFUw=;
	b=Kf7goFDQXxGaNHDTP5iSUiYHdeLuUIwLDBjcUzqqepkZ0eHhCVh+lV6T5JM2V6FQTd8TIp
	+2aN8l28qOe9Gx68eAXnLNnf+DghJGiRyo/ef0NuH2mwb74k0FSrT2k1hfotGlpVlpU5Cy
	+Ii8DMLlVxOvtmsdFl2+HmT9OjeL71tLgJt+88XwK2C/gmcBqqcjbhKY7XbeudhcTsmGAp
	WaThmKUWaLyUDVWqzU9CU1BIBZn0NOfb+98sKbBdYnQoFF4kJywcpp+9jcmBUusPWiWNJP
	lmGhcGg8fPrPCkcnBnyiOAFS+lQjLcHacKooMJeYr4X5Y6hq9P5PhoJcBeJDZg==
From: Maximilian Engelhardt <maxi@daemonizer.de>
To: xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Anthony PERARD <anthony.perard@vates.tech>
Subject:
 Re: [XEN PATCH 0/1] Bug: Hyperlinks in generated documentation may point to
 the wrong architecture
Date: Fri, 17 Jan 2025 21:20:03 +0100
Message-ID: <2013076.usQuhbGJ8B@localhost>
In-Reply-To: <fe71538a-92ed-4ab5-95f7-e5c8d42929d2@citrix.com>
References:
 <cover.1736542505.git.maxi@daemonizer.de>
 <fe71538a-92ed-4ab5-95f7-e5c8d42929d2@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart3528437.QJadu78ljV";
 micalg="pgp-sha512"; protocol="application/pgp-signature"

--nextPart3528437.QJadu78ljV
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"; protected-headers="v1"
From: Maximilian Engelhardt <maxi@daemonizer.de>
Cc: Anthony PERARD <anthony.perard@vates.tech>
Date: Fri, 17 Jan 2025 21:20:03 +0100
Message-ID: <2013076.usQuhbGJ8B@localhost>
In-Reply-To: <fe71538a-92ed-4ab5-95f7-e5c8d42929d2@citrix.com>
MIME-Version: 1.0

On Freitag, 10. Januar 2025 22:32:06 CET Andrew Cooper wrote:
> [...]
> Thanks for the patch.  I'll commit it in due course.
> 
> As an aside though, is there anything we could sensibly do in our own CI
> (Gitlab) to not regress this?
> 
> https://salsa.debian.org/reproducible-builds/reprotest looks like it
> might be good start, but I've never really played in this area before. 
> Would this be suitable, or do you have any other suggestion?

Hi Andrew,

thanks for merging all my patches. Having some upstream xen testing for 
reproducible builds would indeed be a good thing to have.

Reprotest is the tool the salsa CI currently runs as one step and I also have 
been using locally for testing. Salsa is the Debian gitlab instance and there 
is a CI pipeline provided for testing various Debian packaging related things, 
including reproducibility of the Debian package. We use this pipeline for 
testing our Debian xen package.
There is also the reproducible-builds project which among other things looks 
at being able to reproduce the whole Debian archive [1], but as far as i know 
they are using their own tooling for testing.

So to answer your question, I would say reprotest is a good tool for testing 
for reproducibility issues and I don't know any better alternative at the 
moment. There might be some issues e.g. faketime not working as intended in 
certain situations, but there is always the option to configure or disable a 
certain variation if it causes problems.

Maxi

[1] https://tests.reproducible-builds.org/debian/reproducible.html


--nextPart3528437.QJadu78ljV
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

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

iQIzBAABCgAdFiEEQ8gZ7vwsPje0uPkIgepkfSQr0hUFAmeKu3MACgkQgepkfSQr
0hVn7A/+NtVMzQKyKqKSf+2QrgsuVYF1/nj1TueW6iWsSayjGhR1D9fszUo9ZFi+
SZprv668ZPmR40QlmASfqSrAIjxYLrS/yEgWCcZrRd6RSofL8V9zvn3bsX58JJag
XIdFr2SDqqM4fu8pTScgGpxL7/pOiUxRUzKIjmHEy9MOmsbr9jpkV/4UPRZ1kSXa
r0x/Jvcb0bDTv+zF6hGqjZLUHDx+SWjx5UVpyHZjszupOM2SzaP+ZcZn6ez4E67q
/puHmCwGJk+uBQQPn8swkIcX5SGmv4V2BxmalTLFxgMp+uamr7MsQg7wb6fpg91M
qCdDOglfZjx0zGqUZripFLq1kocU1AXGHTGamGPlZe4A71G44jCXPqrqujzSke+1
xGExOiXzLScOHyjZiBdbfegoZedYUDkf6W7jf17fVV7CsnIIFErQS0JK1r6PjudJ
T0NfKp0X/V0kZDDdCb6mN88iQsdUnjlY4Mdw1+uteRw0poUWYvIzTvOEvOxRWJu8
Wh0Ab+ua1ryT3S/xdwQZbb018Iu1JOW8dBr1BseCDmVGupIn+ws8IU6TjuFBKJNo
W/5PK+kt3IdECj40vDXTWRexQUJNv1FJetK2dmWN+5jcoxumI2paeXt/+KYYfH/1
U+yBuPwC9iS1Wdlybo1DuqdG1AY5A9eFG6H1KYwsMw+lV1vzEvI=
=nrf+
-----END PGP SIGNATURE-----

--nextPart3528437.QJadu78ljV--





From xen-devel-bounces@lists.xenproject.org Fri Jan 17 22:43:48 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Jan 2025 22:43:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.874337.1285056 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYv3w-0006nH-Im; Fri, 17 Jan 2025 22:43:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 874337.1285056; Fri, 17 Jan 2025 22:43:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYv3w-0006nA-G9; Fri, 17 Jan 2025 22:43:36 +0000
Received: by outflank-mailman (input) for mailman id 874337;
 Fri, 17 Jan 2025 22:43: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
 <SRS0=O/RI=UJ=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tYv3v-0006n4-7R
 for xen-devel@lists.xenproject.org; Fri, 17 Jan 2025 22:43:35 +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 7ae19242-d524-11ef-a0e2-8be0dac302b0;
 Fri, 17 Jan 2025 23:43:33 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 7CFB25C6417;
 Fri, 17 Jan 2025 22:42:51 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 47AA7C4CEDD;
 Fri, 17 Jan 2025 22:43:30 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 7ae19242-d524-11ef-a0e2-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1737153811;
	bh=VQkzYmnK1qE/xFXhxxj/74ZXfYa7VSdfUA52jckQ4a8=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=DSAqSH8C/vbi1DYMrwdANw+ivgxjxccegitIMlbPpe1lqPqvm17AzYi3fX4mJAasI
	 kWasB6j8UvHcN7UYizJp/jtHHiUYyPXwHkKE/wqmxGwSAgo6F3+jBMfE5n2K/8dmNB
	 kx7gSV02bKflZvUb66mIPvV/QJpZqLlNfhfl8F+9qKrWxJqqGOkcnhVc2q7hrPVWRP
	 jCXKiyuNPIScNU6ievCIzIaGjEVswZQLXXgtfbRU9YEjUcltqxw6jlih6MJDyXC/ZH
	 koMQf8cSKS+K5Xad8LmfJVCUlkifFc7VdHf6KZlD7r7MloFNTu7/Vr0TJ0f7zjSEQy
	 WbxnkbZjdAASA==
Date: Fri, 17 Jan 2025 14:43:28 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich <jbeulich@suse.com>
cc: Alejandro Vallejo <alejandro.vallejo@cloud.com>, 
    "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, 
    Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, 
    Wei Liu <wl@xen.org>, sergiy_kibrik@epam.com, 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
    Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2 1/4] x86: provide an inverted Kconfig control for
 shim-exclusive mode
In-Reply-To: <6285f86d-f2d2-4040-999d-01aed3e72a36@suse.com>
Message-ID: <alpine.DEB.2.22.394.2501171430570.2684657@ubuntu-linux-20-04-desktop>
References: <da5f5bac-6d5d-092d-d872-f1120dcd2661@suse.com> <617842e1-8ef2-b095-0c52-c2e2e5f1c0a8@suse.com> <alpine.DEB.2.22.394.2501161503120.2684657@ubuntu-linux-20-04-desktop> <Z4oxZSUQ6VARiR0H@macbook.local> <D74CH4RDRRR9.ZR6RL8U6PQ56@cloud.com>
 <6285f86d-f2d2-4040-999d-01aed3e72a36@suse.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-846094575-1737152576=:2684657"
Content-ID: <alpine.DEB.2.22.394.2501171423030.2684657@ubuntu-linux-20-04-desktop>

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-846094575-1737152576=:2684657
Content-Type: text/plain; CHARSET=UTF-8
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine.DEB.2.22.394.2501171423031.2684657@ubuntu-linux-20-04-desktop>

On Fri, 17 Jan 2025, Jan Beulich wrote:
> On 17.01.2025 13:24, Alejandro Vallejo wrote:
> > On Fri Jan 17, 2025 at 10:31 AM GMT, Roger Pau Monné wrote:
> >> On Thu, Jan 16, 2025 at 04:31:46PM -0800, Stefano Stabellini wrote:
> >>> On Wed, 1 Mar 2023, Jan Beulich wrote:
> >>>> While we want certain things turned off in shim-exclusive mode, doing
> >>>> so via "depends on !PV_SHIM_EXCLUSIVE" badly affects allyesconfig: Since
> >>>> that will turn on PV_SHIM_EXCLUSIVE, other options will be turned off as
> >>>> a result. Yet allyesconfig wants to enable as much of the functionality
> >>>> as possible.
> >>>>
> >>>> Retain PV_SHIM_EXCLUSIVE as a prompt-less option such that first of all
> >>>> C code using it can remain as is. This isn't just for less code churn,
> >>>> but also because I think that symbol is more logical to use in many
> >>>> (all?) places.
> >>>>
> >>>> Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
> >>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >>>>
> >>>> ---
> >>>> The new Kconfig control's name is up for improvement suggestions, but I
> >>>> think it's already better than the originally thought of
> >>>> FULL_HYPERVISOR.
> >>>
> >>> I think the approach in general is OK, maybe we can improve the naming
> >>> further. What about one of the following?
> >>>
> >>> NO_PV_SHIM_EXCLUSIVE
> >>> PV_SHIM_NOT_EXCLUSIVE
> >>
> >> IMO negated options are confusing, and if possible I think we should
> >> avoid using them unless strictly necessary.
> > 
> > The problem is that the option is negative in nature. It's asking for
> > hypervisor without _something_. I do agree with Stefano that shim would be
> > better in the name. Otherwise readers are forced to play divination tricks.
> > 
> > How about something like:
> > 
> >     SHIMLESS_HYPERVISOR
> > 
> > That's arguably not negated, preserves "shim" in the name and has the correct
> > polarity for allyesconfig to yield the right thing.
> 
> Except that a hypervisor with this option enabled isn't shim-less, but permits
> working in shim as well as in non-shim mode.

First, let's recognize that we have two opposing requirements. One
requirement is to make it as easy as possible to configure for the user.
Ideally without using negative CONFIG options, such as
NO_PV_SHIM_EXCLUSIVE. From the user point of view, honestly,
PV_SHIM_EXCLUSIVE is a pretty good name. Better than all of the others,
I think.

On the other hand, we have the requirement that we don't want
allyesconfig to end up disabling a bunch of CONFIG options. Now this
requirement can be satisfied easily by adding something like
NO_PV_SHIM_EXCLUSIVE. However, it would go somewhat against the previous
requirement.

So we need a compromise, something that doesn't end up disabling other
CONFIG options, to make allyesconfig happy, but also not too confusing
for the user (which is a matter of personal opinion).

In short, expect that people will have different opinions on this and
will find different compromises better or worse. For one, I prefer to
compromise on "no negative CONFIG options" and use
PV_SHIM_NOT_EXCLUSIVE. Because it serves the allyesconfig goal, and
while it is not as clear as PV_SHIM_EXCLUSIVE, is still better than a
completely generic FULL_HYPERVISOR option, which means nothing to me.

I cannot see a way to have a good and clear non-negated CONFIG option,
and also satisfy the allyesconfig requirement. So I prefer to compromise
on the "non-negated" part.
--8323329-846094575-1737152576=:2684657--


From xen-devel-bounces@lists.xenproject.org Fri Jan 17 23:41:36 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Jan 2025 23:41:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.874351.1285066 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYvxw-0006Je-NL; Fri, 17 Jan 2025 23:41:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 874351.1285066; Fri, 17 Jan 2025 23:41:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tYvxw-0006JX-KP; Fri, 17 Jan 2025 23:41:28 +0000
Received: by outflank-mailman (input) for mailman id 874351;
 Fri, 17 Jan 2025 23:41:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=VHvT=UJ=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tYvxv-0006JR-Um
 for xen-devel@lists.xenproject.org; Fri, 17 Jan 2025 23:41:27 +0000
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com
 [2a00:1450:4864:20::32b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 903a99ad-d52c-11ef-a0e2-8be0dac302b0;
 Sat, 18 Jan 2025 00:41:25 +0100 (CET)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-4361f664af5so28712845e9.1
 for <xen-devel@lists.xenproject.org>; Fri, 17 Jan 2025 15:41:25 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438904084e7sm48317705e9.6.2025.01.17.15.41.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 17 Jan 2025 15:41:24 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 903a99ad-d52c-11ef-a0e2-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737157285; x=1737762085; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=7G+q7+YNodUeSCykRUjbKao1Cp6MRoZwAU9NzKs+V2Y=;
        b=fhy8Aka7FZ9cFtHYwDjJKS+FECbDjOv0kZEQI1EQE+x3P5+/9F6FSxU8MdBZaZm8y8
         uJdxIVGiChE4M6b2iAtjVdQ7vMwFJQZlp/KwPNuh9yfKjoTn74+ZeTEM5Fk6Ub7T6fMt
         En3tqw8ZPThBuuEod4+Yrp8HOFE8e1dEwhdgk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737157285; x=1737762085;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=7G+q7+YNodUeSCykRUjbKao1Cp6MRoZwAU9NzKs+V2Y=;
        b=KbkjqJBTRffsEvDutA+PwXAZTZ38YpAK2cWkNSpgCf4b3a58xzP8jQ5/L5xvi3a1pz
         WuRrnWIXLb+D2hFF12ZBgFct75cyzNAHmw3+F3JEZVvHgCO4fbzgOVUHcN1FLtKzX1N0
         WvU3fJgVfRCMuWgTY9w4TFsTmd/wOUQUwAYPrGbG97V0BT6kEXFrsNM9S4399YJTxYpv
         X+oRmYubpvpfo4RE75Y0RqoVhxH7CdHeOdVyYNy4t1l/GF7SYrAx7fUUye2W/UOzoXZH
         zYBQIldjwYxxDN4gJLlLw0FJJV34t63CZcgYfxtuk/fkfZcTnzpnnbSVdvOaEfsmE3Es
         rMbQ==
X-Forwarded-Encrypted: i=1; AJvYcCVTeFCu2pBtKnKpjDXT1m432xSjOka4DEvahuTKeVincxU6VnEBaBx6yZsRYGz+3EzpSpbA3xvCWbY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YznaBKFxMvVSpJO3Pbc+MGb0MAnfa7EHl0QRXWkFiXrrtE4m+96
	vYvdXBL60Efj2xOZvy/AYid9kUdafOa8WnGSoSM9AWNhzFY0KtjhTqrIqh4MGBQ=
X-Gm-Gg: ASbGncuB5wEYoTyoByTyMZx/AeJehJufFHp5FbHIKycFbZ3TGqUhPqXoAdVes1G1t+b
	hEgWaOHNCQGjoG+EvjRWq/RVNYhnxM7vDAinvKsoDGSdPC9MmEvWlkkQTEW7Z0iqBFeYZJz2hVK
	tvx55/Ls5SP30zol68QLb5Z+/HC5SvhCgf8wGA8Hj5ukFTD1Ib9wXqae22MvuGKufm2yp8yiGcJ
	nbag6Ez25g2n2250xs5JHQnG5+TycvfKGPM39OVVCAREb0cyI4N+KLWE/+cdGlK3Pe+w6uXzmFC
	F97Jm41QfVe0GlwYAgmY6m/LCVdGD/TfaQ==
X-Google-Smtp-Source: AGHT+IHe/sgsUcek+Vt3Nw04aT02txb4V9vNV2R/6qTKuS/gvdVvsjV+LIMdtfyg/XFfOpBWB9KFmg==
X-Received: by 2002:a05:600c:3ba7:b0:435:172:5052 with SMTP id 5b1f17b1804b1-438913becb8mr36689365e9.1.1737157284922;
        Fri, 17 Jan 2025 15:41:24 -0800 (PST)
Message-ID: <f8c1e2c2-ceb5-4200-a304-e2d824a171a8@citrix.com>
Date: Fri, 17 Jan 2025 23:41:24 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/4] x86: provide an inverted Kconfig control for
 shim-exclusive mode
To: Stefano Stabellini <sstabellini@kernel.org>,
 Jan Beulich <jbeulich@suse.com>
Cc: Alejandro Vallejo <alejandro.vallejo@cloud.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Julien Grall <julien@xen.org>, Wei Liu <wl@xen.org>, sergiy_kibrik@epam.com,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
References: <da5f5bac-6d5d-092d-d872-f1120dcd2661@suse.com>
 <617842e1-8ef2-b095-0c52-c2e2e5f1c0a8@suse.com>
 <alpine.DEB.2.22.394.2501161503120.2684657@ubuntu-linux-20-04-desktop>
 <Z4oxZSUQ6VARiR0H@macbook.local> <D74CH4RDRRR9.ZR6RL8U6PQ56@cloud.com>
 <6285f86d-f2d2-4040-999d-01aed3e72a36@suse.com>
 <alpine.DEB.2.22.394.2501171430570.2684657@ubuntu-linux-20-04-desktop>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <alpine.DEB.2.22.394.2501171430570.2684657@ubuntu-linux-20-04-desktop>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 17/01/2025 10:43 pm, Stefano Stabellini wrote:
> On Fri, 17 Jan 2025, Jan Beulich wrote:
>> On 17.01.2025 13:24, Alejandro Vallejo wrote:
>>> On Fri Jan 17, 2025 at 10:31 AM GMT, Roger Pau Monné wrote:
>>>> On Thu, Jan 16, 2025 at 04:31:46PM -0800, Stefano Stabellini wrote:
>>>>> On Wed, 1 Mar 2023, Jan Beulich wrote:
>>>>>> While we want certain things turned off in shim-exclusive mode, doing
>>>>>> so via "depends on !PV_SHIM_EXCLUSIVE" badly affects allyesconfig: Since
>>>>>> that will turn on PV_SHIM_EXCLUSIVE, other options will be turned off as
>>>>>> a result. Yet allyesconfig wants to enable as much of the functionality
>>>>>> as possible.
>>>>>>
>>>>>> Retain PV_SHIM_EXCLUSIVE as a prompt-less option such that first of all
>>>>>> C code using it can remain as is. This isn't just for less code churn,
>>>>>> but also because I think that symbol is more logical to use in many
>>>>>> (all?) places.
>>>>>>
>>>>>> Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>>>>
>>>>>> ---
>>>>>> The new Kconfig control's name is up for improvement suggestions, but I
>>>>>> think it's already better than the originally thought of
>>>>>> FULL_HYPERVISOR.
>>>>> I think the approach in general is OK, maybe we can improve the naming
>>>>> further. What about one of the following?
>>>>>
>>>>> NO_PV_SHIM_EXCLUSIVE
>>>>> PV_SHIM_NOT_EXCLUSIVE
>>>> IMO negated options are confusing, and if possible I think we should
>>>> avoid using them unless strictly necessary.
>>> The problem is that the option is negative in nature. It's asking for
>>> hypervisor without _something_. I do agree with Stefano that shim would be
>>> better in the name. Otherwise readers are forced to play divination tricks.
>>>
>>> How about something like:
>>>
>>>     SHIMLESS_HYPERVISOR
>>>
>>> That's arguably not negated, preserves "shim" in the name and has the correct
>>> polarity for allyesconfig to yield the right thing.
>> Except that a hypervisor with this option enabled isn't shim-less, but permits
>> working in shim as well as in non-shim mode.
> First, let's recognize that we have two opposing requirements. One
> requirement is to make it as easy as possible to configure for the user.
> Ideally without using negative CONFIG options, such as
> NO_PV_SHIM_EXCLUSIVE. From the user point of view, honestly,
> PV_SHIM_EXCLUSIVE is a pretty good name. Better than all of the others,
> I think.
>
> On the other hand, we have the requirement that we don't want
> allyesconfig to end up disabling a bunch of CONFIG options. Now this
> requirement can be satisfied easily by adding something like
> NO_PV_SHIM_EXCLUSIVE. However, it would go somewhat against the previous
> requirement.
>
> So we need a compromise, something that doesn't end up disabling other
> CONFIG options, to make allyesconfig happy, but also not too confusing
> for the user (which is a matter of personal opinion).
>
> In short, expect that people will have different opinions on this and
> will find different compromises better or worse. For one, I prefer to
> compromise on "no negative CONFIG options" and use
> PV_SHIM_NOT_EXCLUSIVE. Because it serves the allyesconfig goal, and
> while it is not as clear as PV_SHIM_EXCLUSIVE, is still better than a
> completely generic FULL_HYPERVISOR option, which means nothing to me.
>
> I cannot see a way to have a good and clear non-negated CONFIG option,
> and also satisfy the allyesconfig requirement. So I prefer to compromise
> on the "non-negated" part.

Debating the naming is missing the point.


The problem here is the wish to have PV_SHIM_EXCLUSIVE behave in a way
that Kconfig is not capable of expressing.  Specifically, what is broken
is having "lower level" options inhibit unrelated "higher level" options
when the graph gets rescanned[1].  That's why we're in the laughable
position of `make allyesconfig` turning off CONFIG_HVM.

Jan, you want "echo PV_SHIM_EXCLUSIVE=y >> .config && make" to mean
"reset me back to a PV Shim".

Kconfig spells this "make $foo_defconfig" for an appropriately given foo.


There should be:

1) an option called PV_SHIM_EXCLUSIVE which does *nothing* other than
making the boolean be a compile time constant.

2) a pvshim_defconfig target which expresses what a pvshim ought to look
like.

Trying to fight against the behaviour of Kconfig is not a good use of
anyone's time.

~Andrew

[1] default to unrelated symbols is also broken for a related reason. 
The result you get is sensitive to the order of processing of symbols.


From xen-devel-bounces@lists.xenproject.org Sun Jan 19 11:29:58 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 19 Jan 2025 11:29:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.874607.1285076 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZTUi-0007pp-PS; Sun, 19 Jan 2025 11:29:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 874607.1285076; Sun, 19 Jan 2025 11:29:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZTUi-0007ph-Ke; Sun, 19 Jan 2025 11:29:32 +0000
Received: by outflank-mailman (input) for mailman id 874607;
 Sun, 19 Jan 2025 11:29:32 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=mvz8=UL=linux.dev=sui.jingfeng@srs-se1.protection.inumbo.net>)
 id 1tZTUe-0007pb-Va
 for xen-devel@lists.xenproject.org; Sun, 19 Jan 2025 11:29:32 +0000
Received: from out-173.mta1.migadu.com (out-173.mta1.migadu.com
 [2001:41d0:203:375::ad])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a38c4fee-d658-11ef-a0e2-8be0dac302b0;
 Sun, 19 Jan 2025 12:29:26 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a38c4fee-d658-11ef-a0e2-8be0dac302b0
Message-ID: <b97fcd2f-516a-4172-aef3-631418564cfa@linux.dev>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1;
	t=1737286164;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=uuK0LkbEgQqPgK0yPnR5LzoggyynezSlKlKR/CKdeTY=;
	b=xMqoqpXwM+10B3buteMukau9UQmlGuAXyj0ur9aXSA7WbWzwRnMniPiQaxTWp6qqTY2fRw
	kdeVaGsloeyKfqel8VbZAIHcFFD77zLC4uiMyod2/pw8443jMEAy0AngMSBb8Lp3KLn9lX
	baphMPg1zk5Qs828ODB8iVWTCpuol5w=
Date: Sun, 19 Jan 2025 19:29:14 +0800
MIME-Version: 1.0
Subject: Re: [PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with
 drm_mode_size_dumb()
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
 Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>,
 Thomas Zimmermann <tzimmermann@suse.de>, maarten.lankhorst@linux.intel.com,
 mripard@kernel.org, airlied@gmail.com, simona@ffwll.ch,
 dri-devel@lists.freedesktop.org, linux-mediatek@lists.infradead.org,
 freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
 imx@lists.linux.dev, linux-samsung-soc@vger.kernel.org,
 nouveau@lists.freedesktop.org, virtualization@lists.linux.dev,
 spice-devel@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org,
 linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org,
 intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org,
 Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
 Andy Yan <andyshrk@163.com>, Daniel Stone <daniel@fooishbar.org>
References: <f3ba05c7-6e49-4641-a3f9-ba418ebdb7c3@ideasonboard.com>
 <c6735280-7c32-4319-8ca9-a7305d8117c3@suse.de>
 <d67adb03-5cd0-4ac9-af58-cf4446dacee3@ideasonboard.com>
 <0ea6be58-0e04-4172-87cd-064a3e4a43bc@suse.de>
 <f35cb350-6be9-48ca-ad7e-e9dd418281d5@ideasonboard.com>
 <4af0b6a7-c16a-4187-bbf5-365a9c86de21@suse.de>
 <e327ad84-b5c9-4480-b873-dc3aca605538@ideasonboard.com>
 <a2bbeb47-2569-4ee0-9265-92bab139bdc6@suse.de>
 <f3833771-fcd7-45dc-9019-1525fef34429@ideasonboard.com>
 <CAMuHMdXxYa+Na3XxpLTy=-eUL_zQ9kAiUKYu-E04u3KWApusSA@mail.gmail.com>
 <xz5ncq67bgmdase2jg3cfvyaxpiwhol2eqpfzow6dqpauvslo5@2w3rw27lhnxo>
Content-Language: en-US
X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers.
From: Sui Jingfeng <sui.jingfeng@linux.dev>
In-Reply-To: <xz5ncq67bgmdase2jg3cfvyaxpiwhol2eqpfzow6dqpauvslo5@2w3rw27lhnxo>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Migadu-Flow: FLOW_OUT

Hi,

On 2025/1/16 18:35, Dmitry Baryshkov wrote:
> On Thu, Jan 16, 2025 at 11:17:50AM +0100, Geert Uytterhoeven wrote:
>> On Thu, Jan 16, 2025 at 11:03 AM Tomi Valkeinen
>> <tomi.valkeinen@ideasonboard.com> wrote:
>>> On 16/01/2025 10:09, Thomas Zimmermann wrote:
>>>> Am 15.01.25 um 15:20 schrieb Tomi Valkeinen:
>>>> [...]
>>>>> My point is that we have the current UAPI, and we have userspace using
>>>>> it, but we don't have clear rules what the ioctl does with specific
>>>>> parameters, and we don't document how it has to be used.
>>>>>
>>>>> Perhaps the situation is bad, and all we can really say is that
>>>>> CREATE_DUMB only works for use with simple RGB formats, and the
>>>>> behavior for all other formats is platform specific. But I think even
>>>>> that would be valuable in the UAPI docs.
>>>> To be honest, I would not want to specify behavior for anything but the
>>>> linear RGB formats. If anything, I'd take Daniel's reply mail for
>>>> documentation as-is. Anyone stretching the UAPI beyond RGB is on their own.
>>>>
>>>>> Thinking about this, I wonder if this change is good for omapdrm or
>>>>> xilinx (probably other platforms too that support non-simple non-RGB
>>>>> formats via dumb buffers): without this patch, in both drivers, the
>>>>> pitch calculations just take the bpp as bit-per-pixels, align it up,
>>>>> and that's it.
>>>>>
>>>>> With this patch we end up using drm_driver_color_mode_format(), and
>>>>> aligning buffers according to RGB formats figured out via heuristics.
>>>>> It does happen to work, for the formats I tested, but it sounds like
>>>>> something that might easily not work, as it's doing adjustments based
>>>>> on wrong format.
>>>>>
>>>>> Should we have another version of drm_mode_size_dumb() which just
>>>>> calculates using the bpp, without the drm_driver_color_mode_format()
>>>>> path? Or does the drm_driver_color_mode_format() path provide some
>>>>> value for the drivers that do not currently do anything similar?
>>>> With the RGB-only rule, using drm_driver_color_mode_format() makes
>>>> sense. It aligns dumb buffers and video=, provides error checking, and
>>>> overall harmonizes code. The fallback is only required because of the
>>>> existing odd cases that already bend the UAPI's rules.
>>> I have to disagree here.
>>>
>>> On the platforms I have been using (omap, tidss, xilinx, rcar) the dumb
>>> buffers are the only buffers you can get from the DRM driver. The dumb
>>> buffers have been used to allocate linear and multiplanar YUV buffers
>>> for a very long time on those platforms.
>>>
>>> I tried to look around, but I did not find any mentions that CREATE_DUMB
>>> should only be used for RGB buffers. Is anyone outside the core
>>> developers even aware of it?
>>>
>>> If we don't use dumb buffers there, where do we get the buffers? Maybe
>>> from a v4l2 device or from a gpu device, but often you don't have those.
>>> DMA_HEAP is there, of course.
>> Why can't there be a variant that takes a proper fourcc format instead of
>> an imprecise bpp value?
> Backwards compatibility. We can add an IOCTL for YUV / etc.

[...]

> But userspace must be able to continue allocating YUV buffers through
> CREATE_DUMB.

I think, allocating YUV buffers through CREATE_DUMB interface is just
an *abuse* and *misuse* of this API for now.

Take the NV12 format as an example, NV12 is YUV420 planar format, have
two planar: the Y-planar and the UV-planar. The Y-planar appear first
in memory as an array of unsigned char values. The Y-planar is followed
immediately by the UV-planar, which is also an array of unsigned char
values that contains packed U (Cb) and V (Cr) samples.

But the 'drm_mode_create_dumb' structure is only intend to provide
descriptions for *one* planar.

struct drm_mode_create_dumb {
     __u32 height;
     __u32 width;
     __u32 bpp;
     __u32 flags;
     __u32 handle;
     __u32 pitch;
     __u64 size;
};

An width x height NV12 image takes up width*height*(1 + 1/4 + 1/4) bytes.

So we can allocate an *equivalent* sized buffer to store the NV12 raw data.

Either 'width * (height * 3/2)' where each pixel take up 8 bits,
or just 'with * height' where each pixels take up 12 bits.

However, all those math are just equivalents description to the original
NV12 format, neither are concrete correct physical description.

Therefore, allocating YUV buffers through the dumb interface is just an
abuse for that API. We certainly can abuse more by allocating two dumb
buffers, one for Y-planer, another one for the UV-planer. But again,dumb buffers can be (and must be) used for *scanout* directly. What will yield if I commit the YUV buffers you allocated to the CRTC directly?

In other words, You can allocated buffers via the dumb APIs to store anything,
but the key point is that how can we interpret it.

As Daniel puts it, the semantics of that API is well defined for simple RGB
formats. Usages on non linear RGB dumb buffers are considered as undefined
behavior.

Peoples can still abusing it at the user-space though, but the kernel don't
have to guarantee that the user-space *must* to be able to continue doing
balabala..., That's it.


Best regards,
Sui

>> Gr{oetje,eeting}s,
>>
>>                          Geert
>>
>> -- 
>> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>>
>> In personal conversations with technical people, I call myself a hacker. But
>> when I'm talking to journalists I just say "programmer" or something like that.
>>                                  -- Linus Torvalds

-- 
Best regards,
Sui



From xen-devel-bounces@lists.xenproject.org Sun Jan 19 12:19:11 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 19 Jan 2025 12:19:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.874630.1285086 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZUGf-0005ux-EA; Sun, 19 Jan 2025 12:19:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 874630.1285086; Sun, 19 Jan 2025 12:19:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZUGf-0005uq-B0; Sun, 19 Jan 2025 12:19:05 +0000
Received: by outflank-mailman (input) for mailman id 874630;
 Sun, 19 Jan 2025 12:19:03 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=NF4y=UL=ideasonboard.com=tomi.valkeinen@srs-se1.protection.inumbo.net>)
 id 1tZUGd-0005uk-RX
 for xen-devel@lists.xenproject.org; Sun, 19 Jan 2025 12:19:03 +0000
Received: from perceval.ideasonboard.com (perceval.ideasonboard.com
 [213.167.242.64]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 908a619d-d65f-11ef-99a4-01e77a169b0f;
 Sun, 19 Jan 2025 13:19:01 +0100 (CET)
Received: from [192.168.88.20] (91-158-153-178.elisa-laajakaista.fi
 [91.158.153.178])
 by perceval.ideasonboard.com (Postfix) with ESMTPSA id 7716F5B3;
 Sun, 19 Jan 2025 13:17:57 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 908a619d-d65f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;
	s=mail; t=1737289078;
	bh=WuYYM946dC5xRl6wuOuPFt4jLi3lqjwU+0HIDQSxgRA=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=tRX80voci0sTMUOK/9reTBMJPQAlIV8TvrcXURq7jGG+vCjVE38fbi500thBBeC7R
	 1NlYT9LEyEDVeYFh/ogm0nF9tKWDflDEycJBP5OcuRzlfjV7wptK19XyjYCNbKLSBt
	 z/j+dL4juHco2r0+YdfeUb8fcWnZC19aO+gnkjK0=
Message-ID: <ef52dab0-058f-408f-a298-c4b2453a3d2f@ideasonboard.com>
Date: Sun, 19 Jan 2025 14:18:55 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with
 drm_mode_size_dumb()
To: Sui Jingfeng <sui.jingfeng@linux.dev>,
 Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
 Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>,
 maarten.lankhorst@linux.intel.com, mripard@kernel.org, airlied@gmail.com,
 simona@ffwll.ch, dri-devel@lists.freedesktop.org,
 linux-mediatek@lists.infradead.org, freedreno@lists.freedesktop.org,
 linux-arm-msm@vger.kernel.org, imx@lists.linux.dev,
 linux-samsung-soc@vger.kernel.org, nouveau@lists.freedesktop.org,
 virtualization@lists.linux.dev, spice-devel@lists.freedesktop.org,
 linux-renesas-soc@vger.kernel.org, linux-rockchip@lists.infradead.org,
 linux-tegra@vger.kernel.org, intel-xe@lists.freedesktop.org,
 xen-devel@lists.xenproject.org,
 Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
 Andy Yan <andyshrk@163.com>, Daniel Stone <daniel@fooishbar.org>
References: <f3ba05c7-6e49-4641-a3f9-ba418ebdb7c3@ideasonboard.com>
 <c6735280-7c32-4319-8ca9-a7305d8117c3@suse.de>
 <d67adb03-5cd0-4ac9-af58-cf4446dacee3@ideasonboard.com>
 <0ea6be58-0e04-4172-87cd-064a3e4a43bc@suse.de>
 <f35cb350-6be9-48ca-ad7e-e9dd418281d5@ideasonboard.com>
 <4af0b6a7-c16a-4187-bbf5-365a9c86de21@suse.de>
 <e327ad84-b5c9-4480-b873-dc3aca605538@ideasonboard.com>
 <a2bbeb47-2569-4ee0-9265-92bab139bdc6@suse.de>
 <f3833771-fcd7-45dc-9019-1525fef34429@ideasonboard.com>
 <CAMuHMdXxYa+Na3XxpLTy=-eUL_zQ9kAiUKYu-E04u3KWApusSA@mail.gmail.com>
 <xz5ncq67bgmdase2jg3cfvyaxpiwhol2eqpfzow6dqpauvslo5@2w3rw27lhnxo>
 <b97fcd2f-516a-4172-aef3-631418564cfa@linux.dev>
Content-Language: en-US
From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Autocrypt: addr=tomi.valkeinen@ideasonboard.com; keydata=
 xsFNBE6ms0cBEACyizowecZqXfMZtnBniOieTuFdErHAUyxVgtmr0f5ZfIi9Z4l+uUN4Zdw2
 wCEZjx3o0Z34diXBaMRJ3rAk9yB90UJAnLtb8A97Oq64DskLF81GCYB2P1i0qrG7UjpASgCA
 Ru0lVvxsWyIwSfoYoLrazbT1wkWRs8YBkkXQFfL7Mn3ZMoGPcpfwYH9O7bV1NslbmyJzRCMO
 eYV258gjCcwYlrkyIratlHCek4GrwV8Z9NQcjD5iLzrONjfafrWPwj6yn2RlL0mQEwt1lOvn
 LnI7QRtB3zxA3yB+FLsT1hx0va6xCHpX3QO2gBsyHCyVafFMrg3c/7IIWkDLngJxFgz6DLiA
 G4ld1QK/jsYqfP2GIMH1mFdjY+iagG4DqOsjip479HCWAptpNxSOCL6z3qxCU8MCz8iNOtZk
 DYXQWVscM5qgYSn+fmMM2qN+eoWlnCGVURZZLDjg387S2E1jT/dNTOsM/IqQj+ZROUZuRcF7
 0RTtuU5q1HnbRNwy+23xeoSGuwmLQ2UsUk7Q5CnrjYfiPo3wHze8avK95JBoSd+WIRmV3uoO
 rXCoYOIRlDhg9XJTrbnQ3Ot5zOa0Y9c4IpyAlut6mDtxtKXr4+8OzjSVFww7tIwadTK3wDQv
 Bus4jxHjS6dz1g2ypT65qnHen6mUUH63lhzewqO9peAHJ0SLrQARAQABzTBUb21pIFZhbGtl
 aW5lbiA8dG9taS52YWxrZWluZW5AaWRlYXNvbmJvYXJkLmNvbT7CwY4EEwEIADgWIQTEOAw+
 ll79gQef86f6PaqMvJYe9QUCX/HruAIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRD6
 PaqMvJYe9WmFD/99NGoD5lBJhlFDHMZvO+Op8vCwnIRZdTsyrtGl72rVh9xRfcSgYPZUvBuT
 VDxE53mY9HaZyu1eGMccYRBaTLJSfCXl/g317CrMNdY0k40b9YeIX10feiRYEWoDIPQ3tMmA
 0nHDygzcnuPiPT68JYZ6tUOvAt7r6OX/litM+m2/E9mtp8xCoWOo/kYO4mOAIoMNvLB8vufi
 uBB4e/AvAjtny4ScuNV5c5q8MkfNIiOyag9QCiQ/JfoAqzXRjVb4VZG72AKaElwipiKCWEcU
 R4+Bu5Qbaxj7Cd36M/bI54OrbWWETJkVVSV1i0tghCd6HHyquTdFl7wYcz6cL1hn/6byVnD+
 sR3BLvSBHYp8WSwv0TCuf6tLiNgHAO1hWiQ1pOoXyMEsxZlgPXT+wb4dbNVunckwqFjGxRbl
 Rz7apFT/ZRwbazEzEzNyrBOfB55xdipG/2+SmFn0oMFqFOBEszXLQVslh64lI0CMJm2OYYe3
 PxHqYaztyeXsx13Bfnq9+bUynAQ4uW1P5DJ3OIRZWKmbQd/Me3Fq6TU57LsvwRgE0Le9PFQs
 dcP2071rMTpqTUteEgODJS4VDf4lXJfY91u32BJkiqM7/62Cqatcz5UWWHq5xeF03MIUTqdE
 qHWk3RJEoWHWQRzQfcx6Fn2fDAUKhAddvoopfcjAHfpAWJ+ENc7BTQROprNHARAAx0aat8GU
 hsusCLc4MIxOQwidecCTRc9Dz/7U2goUwhw2O5j9TPqLtp57VITmHILnvZf6q3QAho2QMQyE
 DDvHubrdtEoqaaSKxKkFie1uhWNNvXPhwkKLYieyL9m2JdU+b88HaDnpzdyTTR4uH7wk0bBa
 KbTSgIFDDe5lXInypewPO30TmYNkFSexnnM3n1PBCqiJXsJahE4ZQ+WnV5FbPUj8T2zXS2xk
 0LZ0+DwKmZ0ZDovvdEWRWrz3UzJ8DLHb7blPpGhmqj3ANXQXC7mb9qJ6J/VSl61GbxIO2Dwb
 xPNkHk8fwnxlUBCOyBti/uD2uSTgKHNdabhVm2dgFNVuS1y3bBHbI/qjC3J7rWE0WiaHWEqy
 UVPk8rsph4rqITsj2RiY70vEW0SKePrChvET7D8P1UPqmveBNNtSS7In+DdZ5kUqLV7rJnM9
 /4cwy+uZUt8cuCZlcA5u8IsBCNJudxEqBG10GHg1B6h1RZIz9Q9XfiBdaqa5+CjyFs8ua01c
 9HmyfkuhXG2OLjfQuK+Ygd56mV3lq0aFdwbaX16DG22c6flkkBSjyWXYepFtHz9KsBS0DaZb
 4IkLmZwEXpZcIOQjQ71fqlpiXkXSIaQ6YMEs8WjBbpP81h7QxWIfWtp+VnwNGc6nq5IQDESH
 mvQcsFS7d3eGVI6eyjCFdcAO8eMAEQEAAcLBXwQYAQIACQUCTqazRwIbDAAKCRD6PaqMvJYe
 9fA7EACS6exUedsBKmt4pT7nqXBcRsqm6YzT6DeCM8PWMTeaVGHiR4TnNFiT3otD5UpYQI7S
 suYxoTdHrrrBzdlKe5rUWpzoZkVK6p0s9OIvGzLT0lrb0HC9iNDWT3JgpYDnk4Z2mFi6tTbq
 xKMtpVFRA6FjviGDRsfkfoURZI51nf2RSAk/A8BEDDZ7lgJHskYoklSpwyrXhkp9FHGMaYII
 m9EKuUTX9JPDG2FTthCBrdsgWYPdJQvM+zscq09vFMQ9Fykbx5N8z/oFEUy3ACyPqW2oyfvU
 CH5WDpWBG0s5BALp1gBJPytIAd/pY/5ZdNoi0Cx3+Z7jaBFEyYJdWy1hGddpkgnMjyOfLI7B
 CFrdecTZbR5upjNSDvQ7RG85SnpYJTIin+SAUazAeA2nS6gTZzumgtdw8XmVXZwdBfF+ICof
 92UkbYcYNbzWO/GHgsNT1WnM4sa9lwCSWH8Fw1o/3bX1VVPEsnESOfxkNdu+gAF5S6+I6n3a
 ueeIlwJl5CpT5l8RpoZXEOVtXYn8zzOJ7oGZYINRV9Pf8qKGLf3Dft7zKBP832I3PQjeok7F
 yjt+9S+KgSFSHP3Pa4E7lsSdWhSlHYNdG/czhoUkSCN09C0rEK93wxACx3vtxPLjXu6RptBw
 3dRq7n+mQChEB1am0BueV1JZaBboIL0AGlSJkm23kw==
In-Reply-To: <b97fcd2f-516a-4172-aef3-631418564cfa@linux.dev>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi,

On 19/01/2025 13:29, Sui Jingfeng wrote:
> Hi,
> 
> On 2025/1/16 18:35, Dmitry Baryshkov wrote:
>> On Thu, Jan 16, 2025 at 11:17:50AM +0100, Geert Uytterhoeven wrote:
>>> On Thu, Jan 16, 2025 at 11:03 AM Tomi Valkeinen
>>> <tomi.valkeinen@ideasonboard.com> wrote:
>>>> On 16/01/2025 10:09, Thomas Zimmermann wrote:
>>>>> Am 15.01.25 um 15:20 schrieb Tomi Valkeinen:
>>>>> [...]
>>>>>> My point is that we have the current UAPI, and we have userspace 
>>>>>> using
>>>>>> it, but we don't have clear rules what the ioctl does with specific
>>>>>> parameters, and we don't document how it has to be used.
>>>>>>
>>>>>> Perhaps the situation is bad, and all we can really say is that
>>>>>> CREATE_DUMB only works for use with simple RGB formats, and the
>>>>>> behavior for all other formats is platform specific. But I think even
>>>>>> that would be valuable in the UAPI docs.
>>>>> To be honest, I would not want to specify behavior for anything but 
>>>>> the
>>>>> linear RGB formats. If anything, I'd take Daniel's reply mail for
>>>>> documentation as-is. Anyone stretching the UAPI beyond RGB is on 
>>>>> their own.
>>>>>
>>>>>> Thinking about this, I wonder if this change is good for omapdrm or
>>>>>> xilinx (probably other platforms too that support non-simple non-RGB
>>>>>> formats via dumb buffers): without this patch, in both drivers, the
>>>>>> pitch calculations just take the bpp as bit-per-pixels, align it up,
>>>>>> and that's it.
>>>>>>
>>>>>> With this patch we end up using drm_driver_color_mode_format(), and
>>>>>> aligning buffers according to RGB formats figured out via heuristics.
>>>>>> It does happen to work, for the formats I tested, but it sounds like
>>>>>> something that might easily not work, as it's doing adjustments based
>>>>>> on wrong format.
>>>>>>
>>>>>> Should we have another version of drm_mode_size_dumb() which just
>>>>>> calculates using the bpp, without the drm_driver_color_mode_format()
>>>>>> path? Or does the drm_driver_color_mode_format() path provide some
>>>>>> value for the drivers that do not currently do anything similar?
>>>>> With the RGB-only rule, using drm_driver_color_mode_format() makes
>>>>> sense. It aligns dumb buffers and video=, provides error checking, and
>>>>> overall harmonizes code. The fallback is only required because of the
>>>>> existing odd cases that already bend the UAPI's rules.
>>>> I have to disagree here.
>>>>
>>>> On the platforms I have been using (omap, tidss, xilinx, rcar) the dumb
>>>> buffers are the only buffers you can get from the DRM driver. The dumb
>>>> buffers have been used to allocate linear and multiplanar YUV buffers
>>>> for a very long time on those platforms.
>>>>
>>>> I tried to look around, but I did not find any mentions that 
>>>> CREATE_DUMB
>>>> should only be used for RGB buffers. Is anyone outside the core
>>>> developers even aware of it?
>>>>
>>>> If we don't use dumb buffers there, where do we get the buffers? Maybe
>>>> from a v4l2 device or from a gpu device, but often you don't have 
>>>> those.
>>>> DMA_HEAP is there, of course.
>>> Why can't there be a variant that takes a proper fourcc format 
>>> instead of
>>> an imprecise bpp value?
>> Backwards compatibility. We can add an IOCTL for YUV / etc.
> 
> [...]
> 
>> But userspace must be able to continue allocating YUV buffers through
>> CREATE_DUMB.
> 
> I think, allocating YUV buffers through CREATE_DUMB interface is just
> an *abuse* and *misuse* of this API for now.
> 
> Take the NV12 format as an example, NV12 is YUV420 planar format, have
> two planar: the Y-planar and the UV-planar. The Y-planar appear first
> in memory as an array of unsigned char values. The Y-planar is followed
> immediately by the UV-planar, which is also an array of unsigned char
> values that contains packed U (Cb) and V (Cr) samples.
> 
> But the 'drm_mode_create_dumb' structure is only intend to provide
> descriptions for *one* planar.
> 
> struct drm_mode_create_dumb {
>      __u32 height;
>      __u32 width;
>      __u32 bpp;
>      __u32 flags;
>      __u32 handle;
>      __u32 pitch;
>      __u64 size;
> };
> 
> An width x height NV12 image takes up width*height*(1 + 1/4 + 1/4) bytes.
> 
> So we can allocate an *equivalent* sized buffer to store the NV12 raw data.
> 
> Either 'width * (height * 3/2)' where each pixel take up 8 bits,
> or just 'with * height' where each pixels take up 12 bits.
> 
> However, all those math are just equivalents description to the original
> NV12 format, neither are concrete correct physical description.

I don't see the problem. Allocating dumb buffers, if we don't have any 
heuristics related to RGB behind it, is essentially just allocating a 
specific amount of memory, defined by width, height and bitsperpixel.

If I want to create an NV12 framebuffer, I allocate two dumb buffers, 
one for Y and one for UV planes, and size them accordingly. And then 
create the DRM framebuffer with those.

> Therefore, allocating YUV buffers through the dumb interface is just an
> abuse for that API. We certainly can abuse more by allocating two dumb
> buffers, one for Y-planer, another one for the UV-planer. But again,dumb 
> buffers can be (and must be) used for *scanout* directly. What will 
> yield if I commit the YUV buffers you allocated to the CRTC directly?

You'll see it on the screen? I don't understand your point here...

> In other words, You can allocated buffers via the dumb APIs to store 
> anything,
> but the key point is that how can we interpret it.
> 
> As Daniel puts it, the semantics of that API is well defined for simple RGB
> formats. Usages on non linear RGB dumb buffers are considered as undefined
> behavior.
> 
> Peoples can still abusing it at the user-space though, but the kernel don't
> have to guarantee that the user-space *must* to be able to continue doing
> balabala..., That's it.

I have hard time understanding the "abuse" argument. But in any case, 
the API has been working like this for who knows how long, and used 
widely (afaik). The question is, do we break it or not. Granted, this 
series doesn't break it as such, but it adds heuristics that wasn't 
there before, and it could affect the behavior. If we still want to do 
that, I want to understand what is the benefit, because there's a 
potential to cause regressions.

  Tomi



From xen-devel-bounces@lists.xenproject.org Sun Jan 19 15:00:13 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 19 Jan 2025 15:00:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.874666.1285096 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZWmK-0008Db-Ni; Sun, 19 Jan 2025 14:59:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 874666.1285096; Sun, 19 Jan 2025 14:59:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZWmK-0008DU-Jq; Sun, 19 Jan 2025 14:59:56 +0000
Received: by outflank-mailman (input) for mailman id 874666;
 Sun, 19 Jan 2025 14:59:55 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=mvz8=UL=linux.dev=sui.jingfeng@srs-se1.protection.inumbo.net>)
 id 1tZWmG-0008DN-EM
 for xen-devel@lists.xenproject.org; Sun, 19 Jan 2025 14:59:55 +0000
Received: from out-177.mta1.migadu.com (out-177.mta1.migadu.com
 [95.215.58.177]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 07d536f8-d676-11ef-a0e2-8be0dac302b0;
 Sun, 19 Jan 2025 15:59:50 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 07d536f8-d676-11ef-a0e2-8be0dac302b0
Message-ID: <f4562dbf-b132-4cfd-8f7e-43cd69f2673f@linux.dev>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1;
	t=1737298788;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=zNY9fo693oU2B1dKi7Yad0MtryDjxzNQa/7Ip1S7xnQ=;
	b=heGdHto3F+5K7JCqIvHDGXf1N0wnwZf1k6Vn1a+AfaN8emD7p116EZNmNhdoe3qOiN8MSL
	BAskCcm13dLRGLlnl2OBU60SLqXM+CELdtyiknyOyqOXKvH7THRFFzoAh4sZgSEp9q/ASO
	MFarzvKjz35Ws/S8kauuETysIOP9JiM=
Date: Sun, 19 Jan 2025 22:59:36 +0800
MIME-Version: 1.0
Subject: Re: [PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with
 drm_mode_size_dumb()
To: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>,
 Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
 Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>,
 maarten.lankhorst@linux.intel.com, mripard@kernel.org, airlied@gmail.com,
 simona@ffwll.ch, dri-devel@lists.freedesktop.org,
 linux-mediatek@lists.infradead.org, freedreno@lists.freedesktop.org,
 linux-arm-msm@vger.kernel.org, imx@lists.linux.dev,
 linux-samsung-soc@vger.kernel.org, nouveau@lists.freedesktop.org,
 virtualization@lists.linux.dev, spice-devel@lists.freedesktop.org,
 linux-renesas-soc@vger.kernel.org, linux-rockchip@lists.infradead.org,
 linux-tegra@vger.kernel.org, intel-xe@lists.freedesktop.org,
 xen-devel@lists.xenproject.org,
 Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
 Andy Yan <andyshrk@163.com>, Daniel Stone <daniel@fooishbar.org>
References: <f3ba05c7-6e49-4641-a3f9-ba418ebdb7c3@ideasonboard.com>
 <c6735280-7c32-4319-8ca9-a7305d8117c3@suse.de>
 <d67adb03-5cd0-4ac9-af58-cf4446dacee3@ideasonboard.com>
 <0ea6be58-0e04-4172-87cd-064a3e4a43bc@suse.de>
 <f35cb350-6be9-48ca-ad7e-e9dd418281d5@ideasonboard.com>
 <4af0b6a7-c16a-4187-bbf5-365a9c86de21@suse.de>
 <e327ad84-b5c9-4480-b873-dc3aca605538@ideasonboard.com>
 <a2bbeb47-2569-4ee0-9265-92bab139bdc6@suse.de>
 <f3833771-fcd7-45dc-9019-1525fef34429@ideasonboard.com>
 <CAMuHMdXxYa+Na3XxpLTy=-eUL_zQ9kAiUKYu-E04u3KWApusSA@mail.gmail.com>
 <xz5ncq67bgmdase2jg3cfvyaxpiwhol2eqpfzow6dqpauvslo5@2w3rw27lhnxo>
 <b97fcd2f-516a-4172-aef3-631418564cfa@linux.dev>
 <ef52dab0-058f-408f-a298-c4b2453a3d2f@ideasonboard.com>
Content-Language: en-US
X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers.
From: Sui Jingfeng <sui.jingfeng@linux.dev>
In-Reply-To: <ef52dab0-058f-408f-a298-c4b2453a3d2f@ideasonboard.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Migadu-Flow: FLOW_OUT

Hi,

On 2025/1/19 20:18, Tomi Valkeinen wrote:
> Hi,
>
> On 19/01/2025 13:29, Sui Jingfeng wrote:
>> Hi,
>>
>> On 2025/1/16 18:35, Dmitry Baryshkov wrote:
>>> On Thu, Jan 16, 2025 at 11:17:50AM +0100, Geert Uytterhoeven wrote:
>>>> On Thu, Jan 16, 2025 at 11:03 AM Tomi Valkeinen
>>>> <tomi.valkeinen@ideasonboard.com> wrote:
>>>>> On 16/01/2025 10:09, Thomas Zimmermann wrote:
>>>>>> Am 15.01.25 um 15:20 schrieb Tomi Valkeinen:
>>>>>> [...]
>>>>>>> My point is that we have the current UAPI, and we have userspace 
>>>>>>> using
>>>>>>> it, but we don't have clear rules what the ioctl does with specific
>>>>>>> parameters, and we don't document how it has to be used.
>>>>>>>
>>>>>>> Perhaps the situation is bad, and all we can really say is that
>>>>>>> CREATE_DUMB only works for use with simple RGB formats, and the
>>>>>>> behavior for all other formats is platform specific. But I think 
>>>>>>> even
>>>>>>> that would be valuable in the UAPI docs.
>>>>>> To be honest, I would not want to specify behavior for anything 
>>>>>> but the
>>>>>> linear RGB formats. If anything, I'd take Daniel's reply mail for
>>>>>> documentation as-is. Anyone stretching the UAPI beyond RGB is on 
>>>>>> their own.
>>>>>>
>>>>>>> Thinking about this, I wonder if this change is good for omapdrm or
>>>>>>> xilinx (probably other platforms too that support non-simple 
>>>>>>> non-RGB
>>>>>>> formats via dumb buffers): without this patch, in both drivers, the
>>>>>>> pitch calculations just take the bpp as bit-per-pixels, align it 
>>>>>>> up,
>>>>>>> and that's it.
>>>>>>>
>>>>>>> With this patch we end up using drm_driver_color_mode_format(), and
>>>>>>> aligning buffers according to RGB formats figured out via 
>>>>>>> heuristics.
>>>>>>> It does happen to work, for the formats I tested, but it sounds 
>>>>>>> like
>>>>>>> something that might easily not work, as it's doing adjustments 
>>>>>>> based
>>>>>>> on wrong format.
>>>>>>>
>>>>>>> Should we have another version of drm_mode_size_dumb() which just
>>>>>>> calculates using the bpp, without the 
>>>>>>> drm_driver_color_mode_format()
>>>>>>> path? Or does the drm_driver_color_mode_format() path provide some
>>>>>>> value for the drivers that do not currently do anything similar?
>>>>>> With the RGB-only rule, using drm_driver_color_mode_format() makes
>>>>>> sense. It aligns dumb buffers and video=, provides error 
>>>>>> checking, and
>>>>>> overall harmonizes code. The fallback is only required because of 
>>>>>> the
>>>>>> existing odd cases that already bend the UAPI's rules.
>>>>> I have to disagree here.
>>>>>
>>>>> On the platforms I have been using (omap, tidss, xilinx, rcar) the 
>>>>> dumb
>>>>> buffers are the only buffers you can get from the DRM driver. The 
>>>>> dumb
>>>>> buffers have been used to allocate linear and multiplanar YUV buffers
>>>>> for a very long time on those platforms.
>>>>>
>>>>> I tried to look around, but I did not find any mentions that 
>>>>> CREATE_DUMB
>>>>> should only be used for RGB buffers. Is anyone outside the core
>>>>> developers even aware of it?
>>>>>
>>>>> If we don't use dumb buffers there, where do we get the buffers? 
>>>>> Maybe
>>>>> from a v4l2 device or from a gpu device, but often you don't have 
>>>>> those.
>>>>> DMA_HEAP is there, of course.
>>>> Why can't there be a variant that takes a proper fourcc format 
>>>> instead of
>>>> an imprecise bpp value?
>>> Backwards compatibility. We can add an IOCTL for YUV / etc.
>>
>> [...]
>>
>>> But userspace must be able to continue allocating YUV buffers through
>>> CREATE_DUMB.
>>
>> I think, allocating YUV buffers through CREATE_DUMB interface is just
>> an *abuse* and *misuse* of this API for now.
>>
>> Take the NV12 format as an example, NV12 is YUV420 planar format, have
>> two planar: the Y-planar and the UV-planar. The Y-planar appear first
>> in memory as an array of unsigned char values. The Y-planar is followed
>> immediately by the UV-planar, which is also an array of unsigned char
>> values that contains packed U (Cb) and V (Cr) samples.
>>
>> But the 'drm_mode_create_dumb' structure is only intend to provide
>> descriptions for *one* planar.
>>
>> struct drm_mode_create_dumb {
>>      __u32 height;
>>      __u32 width;
>>      __u32 bpp;
>>      __u32 flags;
>>      __u32 handle;
>>      __u32 pitch;
>>      __u64 size;
>> };
>>
>> An width x height NV12 image takes up width*height*(1 + 1/4 + 1/4) 
>> bytes.
>>
>> So we can allocate an *equivalent* sized buffer to store the NV12 raw 
>> data.
>>
>> Either 'width * (height * 3/2)' where each pixel take up 8 bits,
>> or just 'with * height' where each pixels take up 12 bits.
>>
>> However, all those math are just equivalents description to the original
>> NV12 format, neither are concrete correct physical description.
>
> I don't see the problem. Allocating dumb buffers, if we don't have any 
> heuristics related to RGB behind it, is essentially just allocating a 
> specific amount of memory, defined by width, height and bitsperpixel.
>
I think, the problem will be that the 'width', 'height' and 'bpp'
are originally used to describe one plane. Those three parameters
has perfectly defined physical semantics.

But with multi planar formats, take NV12 image as an example,
for a 2×2 square of pixels, there are 4 Y samples but only 1 U
sample and 1 V sample. This format requires 4x8+1x8+1x8=48 bits
to store the 2x2 square.

So its depth is 12 bits per pixel (48 / (2 * 2)).

so my problem is that the mentioned 12bpp in this example only
make sense in mathematics, it doesn't has a good physical
interpret. Do you agree with me on this technique point?
     

> If I want to create an NV12 framebuffer, I allocate two dumb buffers, 
> one for Y and one for UV planes, and size them accordingly. And then 
> create the DRM framebuffer with those.
>
Then how you fill the value of the 'width', 'height' and 'bpp' of each dumb buffers?

Why not allocate storage for the whole on one shoot?

The modetest in libdrm can be an good example, send it[1] to you as an reference.

[1] https://gitlab.freedesktop.org/mesa/drm/-/blob/main/tests/modetest/buffers.c?ref_type=heads#L114

-- 

Best regards,
Sui



From xen-devel-bounces@lists.xenproject.org Sun Jan 19 15:23:05 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 19 Jan 2025 15:23:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.874682.1285106 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZX8e-0003s6-FY; Sun, 19 Jan 2025 15:23:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 874682.1285106; Sun, 19 Jan 2025 15:23:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZX8e-0003rz-Cv; Sun, 19 Jan 2025 15:23:00 +0000
Received: by outflank-mailman (input) for mailman id 874682;
 Sun, 19 Jan 2025 15:22:59 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=NF4y=UL=ideasonboard.com=tomi.valkeinen@srs-se1.protection.inumbo.net>)
 id 1tZX8c-0003rt-Vt
 for xen-devel@lists.xenproject.org; Sun, 19 Jan 2025 15:22:59 +0000
Received: from perceval.ideasonboard.com (perceval.ideasonboard.com
 [213.167.242.64]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 42d835e6-d679-11ef-a0e2-8be0dac302b0;
 Sun, 19 Jan 2025 16:22:57 +0100 (CET)
Received: from [192.168.88.20] (91-158-153-178.elisa-laajakaista.fi
 [91.158.153.178])
 by perceval.ideasonboard.com (Postfix) with ESMTPSA id EAD45446;
 Sun, 19 Jan 2025 16:21:53 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 42d835e6-d679-11ef-a0e2-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;
	s=mail; t=1737300115;
	bh=CTvWZ10sB6Bpu7OwRCTU/O0pKZ8mB6w+tH5Yr4dSd4E=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=vWU1A4F9YgGtIhbdQyreotqH6d1Ml2MZ0LSMmJD+E3aF7hT7Iyt2tb7DnjVNF+Pxr
	 Ur2IAlVdyYB0u9eTY9nLS1iOqf1rbDS74NQte5xiZiorKZzIDc2ltm+dCMDxo3gGnD
	 tQCGpMKCUDl0+FP1sNJGb4wT3uTFLGuXW16Hvc0Q=
Message-ID: <cf34be39-ce92-4ea5-b548-03008c163d31@ideasonboard.com>
Date: Sun, 19 Jan 2025 17:22:51 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with
 drm_mode_size_dumb()
To: Sui Jingfeng <sui.jingfeng@linux.dev>,
 Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
 Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>,
 maarten.lankhorst@linux.intel.com, mripard@kernel.org, airlied@gmail.com,
 simona@ffwll.ch, dri-devel@lists.freedesktop.org,
 linux-mediatek@lists.infradead.org, freedreno@lists.freedesktop.org,
 linux-arm-msm@vger.kernel.org, imx@lists.linux.dev,
 linux-samsung-soc@vger.kernel.org, nouveau@lists.freedesktop.org,
 virtualization@lists.linux.dev, spice-devel@lists.freedesktop.org,
 linux-renesas-soc@vger.kernel.org, linux-rockchip@lists.infradead.org,
 linux-tegra@vger.kernel.org, intel-xe@lists.freedesktop.org,
 xen-devel@lists.xenproject.org,
 Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
 Andy Yan <andyshrk@163.com>, Daniel Stone <daniel@fooishbar.org>
References: <f3ba05c7-6e49-4641-a3f9-ba418ebdb7c3@ideasonboard.com>
 <c6735280-7c32-4319-8ca9-a7305d8117c3@suse.de>
 <d67adb03-5cd0-4ac9-af58-cf4446dacee3@ideasonboard.com>
 <0ea6be58-0e04-4172-87cd-064a3e4a43bc@suse.de>
 <f35cb350-6be9-48ca-ad7e-e9dd418281d5@ideasonboard.com>
 <4af0b6a7-c16a-4187-bbf5-365a9c86de21@suse.de>
 <e327ad84-b5c9-4480-b873-dc3aca605538@ideasonboard.com>
 <a2bbeb47-2569-4ee0-9265-92bab139bdc6@suse.de>
 <f3833771-fcd7-45dc-9019-1525fef34429@ideasonboard.com>
 <CAMuHMdXxYa+Na3XxpLTy=-eUL_zQ9kAiUKYu-E04u3KWApusSA@mail.gmail.com>
 <xz5ncq67bgmdase2jg3cfvyaxpiwhol2eqpfzow6dqpauvslo5@2w3rw27lhnxo>
 <b97fcd2f-516a-4172-aef3-631418564cfa@linux.dev>
 <ef52dab0-058f-408f-a298-c4b2453a3d2f@ideasonboard.com>
 <f4562dbf-b132-4cfd-8f7e-43cd69f2673f@linux.dev>
Content-Language: en-US
From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Autocrypt: addr=tomi.valkeinen@ideasonboard.com; keydata=
 xsFNBE6ms0cBEACyizowecZqXfMZtnBniOieTuFdErHAUyxVgtmr0f5ZfIi9Z4l+uUN4Zdw2
 wCEZjx3o0Z34diXBaMRJ3rAk9yB90UJAnLtb8A97Oq64DskLF81GCYB2P1i0qrG7UjpASgCA
 Ru0lVvxsWyIwSfoYoLrazbT1wkWRs8YBkkXQFfL7Mn3ZMoGPcpfwYH9O7bV1NslbmyJzRCMO
 eYV258gjCcwYlrkyIratlHCek4GrwV8Z9NQcjD5iLzrONjfafrWPwj6yn2RlL0mQEwt1lOvn
 LnI7QRtB3zxA3yB+FLsT1hx0va6xCHpX3QO2gBsyHCyVafFMrg3c/7IIWkDLngJxFgz6DLiA
 G4ld1QK/jsYqfP2GIMH1mFdjY+iagG4DqOsjip479HCWAptpNxSOCL6z3qxCU8MCz8iNOtZk
 DYXQWVscM5qgYSn+fmMM2qN+eoWlnCGVURZZLDjg387S2E1jT/dNTOsM/IqQj+ZROUZuRcF7
 0RTtuU5q1HnbRNwy+23xeoSGuwmLQ2UsUk7Q5CnrjYfiPo3wHze8avK95JBoSd+WIRmV3uoO
 rXCoYOIRlDhg9XJTrbnQ3Ot5zOa0Y9c4IpyAlut6mDtxtKXr4+8OzjSVFww7tIwadTK3wDQv
 Bus4jxHjS6dz1g2ypT65qnHen6mUUH63lhzewqO9peAHJ0SLrQARAQABzTBUb21pIFZhbGtl
 aW5lbiA8dG9taS52YWxrZWluZW5AaWRlYXNvbmJvYXJkLmNvbT7CwY4EEwEIADgWIQTEOAw+
 ll79gQef86f6PaqMvJYe9QUCX/HruAIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRD6
 PaqMvJYe9WmFD/99NGoD5lBJhlFDHMZvO+Op8vCwnIRZdTsyrtGl72rVh9xRfcSgYPZUvBuT
 VDxE53mY9HaZyu1eGMccYRBaTLJSfCXl/g317CrMNdY0k40b9YeIX10feiRYEWoDIPQ3tMmA
 0nHDygzcnuPiPT68JYZ6tUOvAt7r6OX/litM+m2/E9mtp8xCoWOo/kYO4mOAIoMNvLB8vufi
 uBB4e/AvAjtny4ScuNV5c5q8MkfNIiOyag9QCiQ/JfoAqzXRjVb4VZG72AKaElwipiKCWEcU
 R4+Bu5Qbaxj7Cd36M/bI54OrbWWETJkVVSV1i0tghCd6HHyquTdFl7wYcz6cL1hn/6byVnD+
 sR3BLvSBHYp8WSwv0TCuf6tLiNgHAO1hWiQ1pOoXyMEsxZlgPXT+wb4dbNVunckwqFjGxRbl
 Rz7apFT/ZRwbazEzEzNyrBOfB55xdipG/2+SmFn0oMFqFOBEszXLQVslh64lI0CMJm2OYYe3
 PxHqYaztyeXsx13Bfnq9+bUynAQ4uW1P5DJ3OIRZWKmbQd/Me3Fq6TU57LsvwRgE0Le9PFQs
 dcP2071rMTpqTUteEgODJS4VDf4lXJfY91u32BJkiqM7/62Cqatcz5UWWHq5xeF03MIUTqdE
 qHWk3RJEoWHWQRzQfcx6Fn2fDAUKhAddvoopfcjAHfpAWJ+ENc7BTQROprNHARAAx0aat8GU
 hsusCLc4MIxOQwidecCTRc9Dz/7U2goUwhw2O5j9TPqLtp57VITmHILnvZf6q3QAho2QMQyE
 DDvHubrdtEoqaaSKxKkFie1uhWNNvXPhwkKLYieyL9m2JdU+b88HaDnpzdyTTR4uH7wk0bBa
 KbTSgIFDDe5lXInypewPO30TmYNkFSexnnM3n1PBCqiJXsJahE4ZQ+WnV5FbPUj8T2zXS2xk
 0LZ0+DwKmZ0ZDovvdEWRWrz3UzJ8DLHb7blPpGhmqj3ANXQXC7mb9qJ6J/VSl61GbxIO2Dwb
 xPNkHk8fwnxlUBCOyBti/uD2uSTgKHNdabhVm2dgFNVuS1y3bBHbI/qjC3J7rWE0WiaHWEqy
 UVPk8rsph4rqITsj2RiY70vEW0SKePrChvET7D8P1UPqmveBNNtSS7In+DdZ5kUqLV7rJnM9
 /4cwy+uZUt8cuCZlcA5u8IsBCNJudxEqBG10GHg1B6h1RZIz9Q9XfiBdaqa5+CjyFs8ua01c
 9HmyfkuhXG2OLjfQuK+Ygd56mV3lq0aFdwbaX16DG22c6flkkBSjyWXYepFtHz9KsBS0DaZb
 4IkLmZwEXpZcIOQjQ71fqlpiXkXSIaQ6YMEs8WjBbpP81h7QxWIfWtp+VnwNGc6nq5IQDESH
 mvQcsFS7d3eGVI6eyjCFdcAO8eMAEQEAAcLBXwQYAQIACQUCTqazRwIbDAAKCRD6PaqMvJYe
 9fA7EACS6exUedsBKmt4pT7nqXBcRsqm6YzT6DeCM8PWMTeaVGHiR4TnNFiT3otD5UpYQI7S
 suYxoTdHrrrBzdlKe5rUWpzoZkVK6p0s9OIvGzLT0lrb0HC9iNDWT3JgpYDnk4Z2mFi6tTbq
 xKMtpVFRA6FjviGDRsfkfoURZI51nf2RSAk/A8BEDDZ7lgJHskYoklSpwyrXhkp9FHGMaYII
 m9EKuUTX9JPDG2FTthCBrdsgWYPdJQvM+zscq09vFMQ9Fykbx5N8z/oFEUy3ACyPqW2oyfvU
 CH5WDpWBG0s5BALp1gBJPytIAd/pY/5ZdNoi0Cx3+Z7jaBFEyYJdWy1hGddpkgnMjyOfLI7B
 CFrdecTZbR5upjNSDvQ7RG85SnpYJTIin+SAUazAeA2nS6gTZzumgtdw8XmVXZwdBfF+ICof
 92UkbYcYNbzWO/GHgsNT1WnM4sa9lwCSWH8Fw1o/3bX1VVPEsnESOfxkNdu+gAF5S6+I6n3a
 ueeIlwJl5CpT5l8RpoZXEOVtXYn8zzOJ7oGZYINRV9Pf8qKGLf3Dft7zKBP832I3PQjeok7F
 yjt+9S+KgSFSHP3Pa4E7lsSdWhSlHYNdG/czhoUkSCN09C0rEK93wxACx3vtxPLjXu6RptBw
 3dRq7n+mQChEB1am0BueV1JZaBboIL0AGlSJkm23kw==
In-Reply-To: <f4562dbf-b132-4cfd-8f7e-43cd69f2673f@linux.dev>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 19/01/2025 16:59, Sui Jingfeng wrote:

>>>> But userspace must be able to continue allocating YUV buffers through
>>>> CREATE_DUMB.
>>>
>>> I think, allocating YUV buffers through CREATE_DUMB interface is just
>>> an *abuse* and *misuse* of this API for now.
>>>
>>> Take the NV12 format as an example, NV12 is YUV420 planar format, have
>>> two planar: the Y-planar and the UV-planar. The Y-planar appear first
>>> in memory as an array of unsigned char values. The Y-planar is followed
>>> immediately by the UV-planar, which is also an array of unsigned char
>>> values that contains packed U (Cb) and V (Cr) samples.
>>>
>>> But the 'drm_mode_create_dumb' structure is only intend to provide
>>> descriptions for *one* planar.
>>>
>>> struct drm_mode_create_dumb {
>>>      __u32 height;
>>>      __u32 width;
>>>      __u32 bpp;
>>>      __u32 flags;
>>>      __u32 handle;
>>>      __u32 pitch;
>>>      __u64 size;
>>> };
>>>
>>> An width x height NV12 image takes up width*height*(1 + 1/4 + 1/4) 
>>> bytes.
>>>
>>> So we can allocate an *equivalent* sized buffer to store the NV12 raw 
>>> data.
>>>
>>> Either 'width * (height * 3/2)' where each pixel take up 8 bits,
>>> or just 'with * height' where each pixels take up 12 bits.
>>>
>>> However, all those math are just equivalents description to the original
>>> NV12 format, neither are concrete correct physical description.
>>
>> I don't see the problem. Allocating dumb buffers, if we don't have any 
>> heuristics related to RGB behind it, is essentially just allocating a 
>> specific amount of memory, defined by width, height and bitsperpixel.
>>
> I think, the problem will be that the 'width', 'height' and 'bpp'
> are originally used to describe one plane. Those three parameters
> has perfectly defined physical semantics.
> 
> But with multi planar formats, take NV12 image as an example,
> for a 2×2 square of pixels, there are 4 Y samples but only 1 U
> sample and 1 V sample. This format requires 4x8+1x8+1x8=48 bits
> to store the 2x2 square.
> 
> So its depth is 12 bits per pixel (48 / (2 * 2)).
> 
> so my problem is that the mentioned 12bpp in this example only
> make sense in mathematics, it doesn't has a good physical
> interpret. Do you agree with me on this technique point?
> 
>> If I want to create an NV12 framebuffer, I allocate two dumb buffers, 
>> one for Y and one for UV planes, and size them accordingly. And then 
>> create the DRM framebuffer with those.
>>
> Then how you fill the value of the 'width', 'height' and 'bpp' of each 
> dumb buffers?

For 640x480-NV12:
plane 0: width = 640, height = 480, bpp = 8
plane 1: width = 640 / 2, height = 480 / 2, bpp = 16

> Why not allocate storage for the whole on one shoot?

You can, if you adjust the parameters accordingly. However, if the 
strides of the planes are not equal, I guess it might cause problems on 
some platforms.

But I think it's usually simpler to allocate one buffer per plane, and 
perhaps even better as it doesn't require as large contiguous memory area.

> The modetest in libdrm can be an good example, send it[1] to you as an 
> reference.

Right, so modetest already does it successfully. So... What is the issue?

Everyone agrees that CREATE_DUMB is not the best ioctl to allocate 
buffers, and one can't consider it to work identically across the 
platforms. But it's what we have and what has been used for ages.

  Tomi



From xen-devel-bounces@lists.xenproject.org Sun Jan 19 16:27:09 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 19 Jan 2025 16:27:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.874695.1285116 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZY8T-0003oN-Sq; Sun, 19 Jan 2025 16:26:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 874695.1285116; Sun, 19 Jan 2025 16:26:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZY8T-0003oG-Q7; Sun, 19 Jan 2025 16:26:53 +0000
Received: by outflank-mailman (input) for mailman id 874695;
 Sun, 19 Jan 2025 16:26:52 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=mvz8=UL=linux.dev=sui.jingfeng@srs-se1.protection.inumbo.net>)
 id 1tZY8P-0003o3-BU
 for xen-devel@lists.xenproject.org; Sun, 19 Jan 2025 16:26:52 +0000
Received: from out-181.mta1.migadu.com (out-181.mta1.migadu.com
 [95.215.58.181]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2d392488-d682-11ef-a0e2-8be0dac302b0;
 Sun, 19 Jan 2025 17:26:46 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2d392488-d682-11ef-a0e2-8be0dac302b0
Message-ID: <8234927e-0d12-4655-813d-8ec94179b737@linux.dev>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1;
	t=1737304005;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=vk3LJPYAEJumDCHfvyn+0B3wt+JaPCGDzjEcWZxdF60=;
	b=rSN8t36GlcqKWcSry2NAS7uuPoSokjl/moVcZQqfvubYqsOYH01D0yN3RMsNHteHhtpLti
	kVL97c93wJmSXin/dBnch03Cy9RjtJi2PzJmt0HI9IluiFQUnxKcft+J/Ya7YtZG1krPc+
	YGBCQ0RrYcucM6qjwpDCjNrgG9sTpfk=
Date: Mon, 20 Jan 2025 00:26:30 +0800
MIME-Version: 1.0
Subject: Re: [PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with
 drm_mode_size_dumb()
To: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>,
 Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
 Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>,
 maarten.lankhorst@linux.intel.com, mripard@kernel.org, airlied@gmail.com,
 simona@ffwll.ch, dri-devel@lists.freedesktop.org,
 linux-mediatek@lists.infradead.org, freedreno@lists.freedesktop.org,
 linux-arm-msm@vger.kernel.org, imx@lists.linux.dev,
 linux-samsung-soc@vger.kernel.org, nouveau@lists.freedesktop.org,
 virtualization@lists.linux.dev, spice-devel@lists.freedesktop.org,
 linux-renesas-soc@vger.kernel.org, linux-rockchip@lists.infradead.org,
 linux-tegra@vger.kernel.org, intel-xe@lists.freedesktop.org,
 xen-devel@lists.xenproject.org,
 Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
 Andy Yan <andyshrk@163.com>, Daniel Stone <daniel@fooishbar.org>
References: <f3ba05c7-6e49-4641-a3f9-ba418ebdb7c3@ideasonboard.com>
 <c6735280-7c32-4319-8ca9-a7305d8117c3@suse.de>
 <d67adb03-5cd0-4ac9-af58-cf4446dacee3@ideasonboard.com>
 <0ea6be58-0e04-4172-87cd-064a3e4a43bc@suse.de>
 <f35cb350-6be9-48ca-ad7e-e9dd418281d5@ideasonboard.com>
 <4af0b6a7-c16a-4187-bbf5-365a9c86de21@suse.de>
 <e327ad84-b5c9-4480-b873-dc3aca605538@ideasonboard.com>
 <a2bbeb47-2569-4ee0-9265-92bab139bdc6@suse.de>
 <f3833771-fcd7-45dc-9019-1525fef34429@ideasonboard.com>
 <CAMuHMdXxYa+Na3XxpLTy=-eUL_zQ9kAiUKYu-E04u3KWApusSA@mail.gmail.com>
 <xz5ncq67bgmdase2jg3cfvyaxpiwhol2eqpfzow6dqpauvslo5@2w3rw27lhnxo>
 <b97fcd2f-516a-4172-aef3-631418564cfa@linux.dev>
 <ef52dab0-058f-408f-a298-c4b2453a3d2f@ideasonboard.com>
 <f4562dbf-b132-4cfd-8f7e-43cd69f2673f@linux.dev>
 <cf34be39-ce92-4ea5-b548-03008c163d31@ideasonboard.com>
Content-Language: en-US
X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers.
From: Sui Jingfeng <sui.jingfeng@linux.dev>
In-Reply-To: <cf34be39-ce92-4ea5-b548-03008c163d31@ideasonboard.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Migadu-Flow: FLOW_OUT

Hi,

On 2025/1/19 23:22, Tomi Valkeinen wrote:
> On 19/01/2025 16:59, Sui Jingfeng wrote:
>
>>>>> But userspace must be able to continue allocating YUV buffers through
>>>>> CREATE_DUMB.
>>>>
>>>> I think, allocating YUV buffers through CREATE_DUMB interface is just
>>>> an *abuse* and *misuse* of this API for now.
>>>>
>>>> Take the NV12 format as an example, NV12 is YUV420 planar format, have
>>>> two planar: the Y-planar and the UV-planar. The Y-planar appear first
>>>> in memory as an array of unsigned char values. The Y-planar is 
>>>> followed
>>>> immediately by the UV-planar, which is also an array of unsigned char
>>>> values that contains packed U (Cb) and V (Cr) samples.
>>>>
>>>> But the 'drm_mode_create_dumb' structure is only intend to provide
>>>> descriptions for *one* planar.
>>>>
>>>> struct drm_mode_create_dumb {
>>>>      __u32 height;
>>>>      __u32 width;
>>>>      __u32 bpp;
>>>>      __u32 flags;
>>>>      __u32 handle;
>>>>      __u32 pitch;
>>>>      __u64 size;
>>>> };
>>>>
>>>> An width x height NV12 image takes up width*height*(1 + 1/4 + 1/4) 
>>>> bytes.
>>>>
>>>> So we can allocate an *equivalent* sized buffer to store the NV12 
>>>> raw data.
>>>>
>>>> Either 'width * (height * 3/2)' where each pixel take up 8 bits,
>>>> or just 'with * height' where each pixels take up 12 bits.
>>>>
>>>> However, all those math are just equivalents description to the 
>>>> original
>>>> NV12 format, neither are concrete correct physical description.
>>>
>>> I don't see the problem. Allocating dumb buffers, if we don't have 
>>> any heuristics related to RGB behind it, is essentially just 
>>> allocating a specific amount of memory, defined by width, height and 
>>> bitsperpixel.
>>>
>> I think, the problem will be that the 'width', 'height' and 'bpp'
>> are originally used to describe one plane. Those three parameters
>> has perfectly defined physical semantics.
>>
>> But with multi planar formats, take NV12 image as an example,
>> for a 2×2 square of pixels, there are 4 Y samples but only 1 U
>> sample and 1 V sample. This format requires 4x8+1x8+1x8=48 bits
>> to store the 2x2 square.
>>
>> So its depth is 12 bits per pixel (48 / (2 * 2)).
>>
>> so my problem is that the mentioned 12bpp in this example only
>> make sense in mathematics, it doesn't has a good physical
>> interpret. Do you agree with me on this technique point?
>>
>>> If I want to create an NV12 framebuffer, I allocate two dumb 
>>> buffers, one for Y and one for UV planes, and size them accordingly. 
>>> And then create the DRM framebuffer with those.
>>>
>> Then how you fill the value of the 'width', 'height' and 'bpp' of 
>> each dumb buffers?
>
> For 640x480-NV12:
> plane 0: width = 640, height = 480, bpp = 8
> plane 1: width = 640 / 2, height = 480 / 2, bpp = 16
>
But i think this should be hardware dependent. The hardware I'm using
load NV12  raw data as a whole. I only need to feed gpuva of the backing
memory to the hardware register once.

Not familiar with your hardware, so I can't talk more on this software
design. Perhaps someone know more could have a comment on this.

>> Why not allocate storage for the whole on one shoot?
>
> You can, if you adjust the parameters accordingly. However, if the 
> strides of the planes are not equal, I guess it might cause problems 
> on some platforms.
>
> But I think it's usually simpler to allocate one buffer per plane, and 
> perhaps even better as it doesn't require as large contiguous memory 
> area.
>
>> The modetest in libdrm can be an good example, send it[1] to you as 
>> an reference.
>
> Right, so modetest already does it successfully. So... What is the issue?
>
But then, the problem will become that it override the 'height' parameter.
What's the physical interpretation of the 'height' parameter when creating
an NV12 image with the dump API then?

I guess, solving complex problems with simple APIs may see the limitation,
sooner or later. But I not very sure and might be wrong. So other peoples
can override me words.


> Everyone agrees that CREATE_DUMB is not the best ioctl to allocate 
> buffers, and one can't consider it to work identically across the 
> platforms. But it's what we have and what has been used for ages.
>
Yeah, your request are not unreasonable. It can be seen as a kind of rigid demand.
Since GEM DMA helpers doesn't export an more advanced interface to userspace so far.
As a result, drivers that employing GEM DMA has no other choice, but to abuse the
dumb buffer API to do allocation for the more complex format buffers.

The dumb buffer API doesn't support to specify buffer format, tile status and
placement etc. The more advance drivers has been exposed the xxx_create_gem()
to user-space. It seems that a few more experienced programmers hint us to
create an new ioctl at above thread, so that we can keep employing simple API
to do simple things and to suit complex needs with the more advanced APIs.


>  Tomi
>
-- 
Best regards,
Sui



From xen-devel-bounces@lists.xenproject.org Sun Jan 19 17:09:19 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 19 Jan 2025 17:09:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.874722.1285125 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZYnQ-0000bL-Te; Sun, 19 Jan 2025 17:09:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 874722.1285125; Sun, 19 Jan 2025 17:09:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZYnQ-0000bE-QR; Sun, 19 Jan 2025 17:09:12 +0000
Received: by outflank-mailman (input) for mailman id 874722;
 Sun, 19 Jan 2025 17:09:11 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=rKhJ=UL=ideasonboard.com=laurent.pinchart@srs-se1.protection.inumbo.net>)
 id 1tZYnP-0000b8-4H
 for xen-devel@lists.xenproject.org; Sun, 19 Jan 2025 17:09:11 +0000
Received: from perceval.ideasonboard.com (perceval.ideasonboard.com
 [213.167.242.64]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 18646bba-d688-11ef-99a4-01e77a169b0f;
 Sun, 19 Jan 2025 18:09:08 +0100 (CET)
Received: from pendragon.ideasonboard.com (81-175-209-231.bb.dnainternet.fi
 [81.175.209.231])
 by perceval.ideasonboard.com (Postfix) with ESMTPSA id 89E37A44;
 Sun, 19 Jan 2025 18:08:05 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 18646bba-d688-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;
	s=mail; t=1737306485;
	bh=aJRfXAoIvGiK3DbkqnVQeu1PiaXDKaiA9Gr69mpEeis=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=OBw1pvsHcR2BweZX/KU1szcB/w7FtiRtRW7yb+DznyFivWl1EatIqP+ePhHYSjEzj
	 woJcak3Nj+IU95kPpPRovUwkyjiuPwG5ekSoIX5uH93MQlfYfUlHPU6r5/ncEIxZV4
	 QiCXHGtqYYzymRcOpqSQO1hNMGBl60pFLxpvCuJY=
Date: Sun, 19 Jan 2025 19:08:59 +0200
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Cc: Daniel Stone <daniel@fooishbar.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	maarten.lankhorst@linux.intel.com, mripard@kernel.org,
	airlied@gmail.com, simona@ffwll.ch, dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org, freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org, imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org, nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev, spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org,
	Andy Yan <andyshrk@163.com>
Subject: Re: [PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with
 drm_mode_size_dumb()
Message-ID: <20250119170859.GA2467@pendragon.ideasonboard.com>
References: <c6735280-7c32-4319-8ca9-a7305d8117c3@suse.de>
 <d67adb03-5cd0-4ac9-af58-cf4446dacee3@ideasonboard.com>
 <0ea6be58-0e04-4172-87cd-064a3e4a43bc@suse.de>
 <f35cb350-6be9-48ca-ad7e-e9dd418281d5@ideasonboard.com>
 <4af0b6a7-c16a-4187-bbf5-365a9c86de21@suse.de>
 <e327ad84-b5c9-4480-b873-dc3aca605538@ideasonboard.com>
 <CAPj87rOn=RQ615zyaEdFT2ADfPztU7+heVi0G34Rdg-=QO1cCw@mail.gmail.com>
 <20250116084340.GF6754@pendragon.ideasonboard.com>
 <20250116093854.GG6754@pendragon.ideasonboard.com>
 <e8125edc-928a-47b4-80a3-224c945f6d68@ideasonboard.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <e8125edc-928a-47b4-80a3-224c945f6d68@ideasonboard.com>

On Thu, Jan 16, 2025 at 12:07:49PM +0200, Tomi Valkeinen wrote:
> On 16/01/2025 11:38, Laurent Pinchart wrote:
> > On Thu, Jan 16, 2025 at 10:43:40AM +0200, Laurent Pinchart wrote:
> >> On Wed, Jan 15, 2025 at 02:34:26PM +0000, Daniel Stone wrote:
> >>> On Wed, 15 Jan 2025 at 14:20, Tomi Valkeinen wrote:
> >>>> No disagreement there, we need CREATE_DUMB2.
> >>>>
> >>>> My point is that we have the current UAPI, and we have userspace using
> >>>> it, but we don't have clear rules what the ioctl does with specific
> >>>> parameters, and we don't document how it has to be used.
> >>>>
> >>>> Perhaps the situation is bad, and all we can really say is that
> >>>> CREATE_DUMB only works for use with simple RGB formats, and the behavior
> >>>> for all other formats is platform specific. But I think even that would
> >>>> be valuable in the UAPI docs.
> >>>
> >>> Yeah, CREATE_DUMB only works for use with simple RGB formats in a
> >>> linear layout. Not monochrome or YUV or tiled or displayed rotated or
> >>> whatever.
> >>>
> >>> If it happens to accidentally work for other uses, that's fine, but
> >>> it's not generically reliable for anything other than simple linear
> >>> RGB. It's intended to let you do splash screens, consoles, recovery
> >>> password entries, and software-rendered compositors if you really
> >>> want. Anything more than that isn't 'dumb'.
> >>
> >> We have lots of software out there that rely on CREATE_DUMB supporting
> >> YUV linear formats, and lots of drivers (mostly on Arm I suppose) that
> >> implement YUV support in CREATE_DUMB. I'm fine replacing it with
> >> something better, but I think we need a standard ioctl that can create
> >> linear YUV buffers. I've been told many times that DRM doesn't want to
> >> standardize buffer allocation further than what CREATE_DUMB is made for.
> >> Can we reconsider this rule then ?
> > 
> > Actually... Instead of adding a CREATE_DUMB2, it would be best on trying
> > to leverage DMA heaps and deprecate allocating from the KMS device.
> 
> If we allocate from DMA heaps, I think we then need a DRM ioctl which 
> will tell you how big buffer(s) you need, based on the size and format.

We will at least a kernel API to expose constraints to userspace.
Whether that should calculate the buffer size for a given format, or
expose information to userspace to enable that calculation, I'm not
sure. But regardless of which option we pick, I agree we likely need a
new API to enable usage of DMA heaps as allocators.

-- 
Regards,

Laurent Pinchart


From xen-devel-bounces@lists.xenproject.org Sun Jan 19 20:15:10 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 19 Jan 2025 20:15:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.874747.1285136 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZbh8-0005qk-E1; Sun, 19 Jan 2025 20:14:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 874747.1285136; Sun, 19 Jan 2025 20:14:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZbh8-0005qd-9q; Sun, 19 Jan 2025 20:14:54 +0000
Received: by outflank-mailman (input) for mailman id 874747;
 Sun, 19 Jan 2025 20:14: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
 <SRS0=rKhJ=UL=ideasonboard.com=laurent.pinchart@srs-se1.protection.inumbo.net>)
 id 1tZbh7-0005q4-NI
 for xen-devel@lists.xenproject.org; Sun, 19 Jan 2025 20:14:53 +0000
Received: from perceval.ideasonboard.com (perceval.ideasonboard.com
 [213.167.242.64]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0974a7b2-d6a2-11ef-99a4-01e77a169b0f;
 Sun, 19 Jan 2025 21:14:50 +0100 (CET)
Received: from pendragon.ideasonboard.com (81-175-209-231.bb.dnainternet.fi
 [81.175.209.231])
 by perceval.ideasonboard.com (Postfix) with ESMTPSA id 85456928;
 Sun, 19 Jan 2025 21:13:48 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 0974a7b2-d6a2-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;
	s=mail; t=1737317628;
	bh=Ur5TiuDT0KV1E3ES7k+/3Zr4hEwwAAPuNmpmijHxcE0=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=SS+99s7tpuo+gPcxMER5jdDaof5TicjCpzG4c3b8L9QjuYGIwEIGNxOpvhm9TbJ1K
	 WDQ8UU3Os41Ewzy+4kV7y7CeQXv55XGw/jZbTqWOQI9B6aQfo6jbIU+WwUmbNEjidS
	 k9ILi43LKurT0oL3MNbHe4TD8sUVaA21oTrP0eCY=
Date: Sun, 19 Jan 2025 22:14:43 +0200
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Sui Jingfeng <sui.jingfeng@linux.dev>
Cc: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>,
	Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	maarten.lankhorst@linux.intel.com, mripard@kernel.org,
	airlied@gmail.com, simona@ffwll.ch, dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org, freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org, imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org, nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev, spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org,
	Andy Yan <andyshrk@163.com>, Daniel Stone <daniel@fooishbar.org>
Subject: Re: [PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with
 drm_mode_size_dumb()
Message-ID: <20250119201443.GB2467@pendragon.ideasonboard.com>
References: <e327ad84-b5c9-4480-b873-dc3aca605538@ideasonboard.com>
 <a2bbeb47-2569-4ee0-9265-92bab139bdc6@suse.de>
 <f3833771-fcd7-45dc-9019-1525fef34429@ideasonboard.com>
 <CAMuHMdXxYa+Na3XxpLTy=-eUL_zQ9kAiUKYu-E04u3KWApusSA@mail.gmail.com>
 <xz5ncq67bgmdase2jg3cfvyaxpiwhol2eqpfzow6dqpauvslo5@2w3rw27lhnxo>
 <b97fcd2f-516a-4172-aef3-631418564cfa@linux.dev>
 <ef52dab0-058f-408f-a298-c4b2453a3d2f@ideasonboard.com>
 <f4562dbf-b132-4cfd-8f7e-43cd69f2673f@linux.dev>
 <cf34be39-ce92-4ea5-b548-03008c163d31@ideasonboard.com>
 <8234927e-0d12-4655-813d-8ec94179b737@linux.dev>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <8234927e-0d12-4655-813d-8ec94179b737@linux.dev>

On Mon, Jan 20, 2025 at 12:26:30AM +0800, Sui Jingfeng wrote:
> On 2025/1/19 23:22, Tomi Valkeinen wrote:
> > On 19/01/2025 16:59, Sui Jingfeng wrote:
> >
> >>>>> But userspace must be able to continue allocating YUV buffers through
> >>>>> CREATE_DUMB.
> >>>>
> >>>> I think, allocating YUV buffers through CREATE_DUMB interface is just
> >>>> an *abuse* and *misuse* of this API for now.
> >>>>
> >>>> Take the NV12 format as an example, NV12 is YUV420 planar format, have
> >>>> two planar: the Y-planar and the UV-planar. The Y-planar appear first
> >>>> in memory as an array of unsigned char values. The Y-planar is followed
> >>>> immediately by the UV-planar, which is also an array of unsigned char
> >>>> values that contains packed U (Cb) and V (Cr) samples.
> >>>>
> >>>> But the 'drm_mode_create_dumb' structure is only intend to provide
> >>>> descriptions for *one* planar.
> >>>>
> >>>> struct drm_mode_create_dumb {
> >>>>      __u32 height;
> >>>>      __u32 width;
> >>>>      __u32 bpp;
> >>>>      __u32 flags;
> >>>>      __u32 handle;
> >>>>      __u32 pitch;
> >>>>      __u64 size;
> >>>> };
> >>>>
> >>>> An width x height NV12 image takes up width*height*(1 + 1/4 + 1/4) 
> >>>> bytes.
> >>>>
> >>>> So we can allocate an *equivalent* sized buffer to store the NV12 
> >>>> raw data.
> >>>>
> >>>> Either 'width * (height * 3/2)' where each pixel take up 8 bits,
> >>>> or just 'with * height' where each pixels take up 12 bits.
> >>>>
> >>>> However, all those math are just equivalents description to the original
> >>>> NV12 format, neither are concrete correct physical description.
> >>>
> >>> I don't see the problem. Allocating dumb buffers, if we don't have 
> >>> any heuristics related to RGB behind it, is essentially just 
> >>> allocating a specific amount of memory, defined by width, height and 
> >>> bitsperpixel.
> >>>
> >> I think, the problem will be that the 'width', 'height' and 'bpp'
> >> are originally used to describe one plane. Those three parameters
> >> has perfectly defined physical semantics.
> >>
> >> But with multi planar formats, take NV12 image as an example,
> >> for a 2×2 square of pixels, there are 4 Y samples but only 1 U
> >> sample and 1 V sample. This format requires 4x8+1x8+1x8=48 bits
> >> to store the 2x2 square.
> >>
> >> So its depth is 12 bits per pixel (48 / (2 * 2)).
> >>
> >> so my problem is that the mentioned 12bpp in this example only
> >> make sense in mathematics, it doesn't has a good physical
> >> interpret. Do you agree with me on this technique point?
> >>
> >>> If I want to create an NV12 framebuffer, I allocate two dumb 
> >>> buffers, one for Y and one for UV planes, and size them accordingly. 
> >>> And then create the DRM framebuffer with those.
> >>>
> >> Then how you fill the value of the 'width', 'height' and 'bpp' of 
> >> each dumb buffers?
> >
> > For 640x480-NV12:
> > plane 0: width = 640, height = 480, bpp = 8
> > plane 1: width = 640 / 2, height = 480 / 2, bpp = 16
>
> But i think this should be hardware dependent. The hardware I'm using
> load NV12  raw data as a whole. I only need to feed gpuva of the backing
> memory to the hardware register once.
> 
> Not familiar with your hardware, so I can't talk more on this software
> design. Perhaps someone know more could have a comment on this.

Layout of planes in memory is just one hardware constraint, the same way
we have constraints on alignment and strides. Some devices require the
planes to be contiguous (likely with some alignment constraints), some
can work with planes being in discontiguous pieces of memory, and even
require them to be discontiguous and located in separate DRAM banks.

> >> Why not allocate storage for the whole on one shoot?
> >
> > You can, if you adjust the parameters accordingly. However, if the 
> > strides of the planes are not equal, I guess it might cause problems 
> > on some platforms.
> >
> > But I think it's usually simpler to allocate one buffer per plane, and 
> > perhaps even better as it doesn't require as large contiguous memory 
> > area.
> >
> >> The modetest in libdrm can be an good example, send it[1] to you as 
> >> an reference.
> >
> > Right, so modetest already does it successfully. So... What is the issue?
>
> But then, the problem will become that it override the 'height' parameter.
> What's the physical interpretation of the 'height' parameter when creating
> an NV12 image with the dump API then?

I wouldn't be too concerned about physical interpretations. Yes, the
height, width and bpp parameters were likely designed with RGB formats
in mind. Yes, using DUMB_CREATE for YUV formats is probably something
that the original authors didn't envision. And yes, from that point of
view, it could be seen by the original authors as an abuse of the API.
But I don't think that's a problem as such.

An API is just an API. True, it would be nicer if the usage of the ioctl
parameters was more intuitive for YUV formats, but I believe we could
still standardize how the existing parameters map to linear scanout YUV
formats without causing the world to end. As has been said before, lots
of drivers are using DUMB_CREATE for this purpose, and we can't change
that.

This doesn't mean we shouldn't work on improving memory allocation, but
I see that as a separate issue.

> I guess, solving complex problems with simple APIs may see the limitation,
> sooner or later. But I not very sure and might be wrong. So other peoples
> can override me words.
> 
> > Everyone agrees that CREATE_DUMB is not the best ioctl to allocate 
> > buffers, and one can't consider it to work identically across the 
> > platforms. But it's what we have and what has been used for ages.
>
> Yeah, your request are not unreasonable. It can be seen as a kind of rigid demand.
> Since GEM DMA helpers doesn't export an more advanced interface to userspace so far.
> As a result, drivers that employing GEM DMA has no other choice, but to abuse the
> dumb buffer API to do allocation for the more complex format buffers.
> 
> The dumb buffer API doesn't support to specify buffer format, tile status and
> placement etc. The more advance drivers has been exposed the xxx_create_gem()
> to user-space. It seems that a few more experienced programmers hint us to
> create an new ioctl at above thread, so that we can keep employing simple API
> to do simple things and to suit complex needs with the more advanced APIs.

I'd really like to explore adding new ioctls to exposure memory
allocation constraints, and allocating the memory itself from DMA heaps.

-- 
Regards,

Laurent Pinchart


From xen-devel-bounces@lists.xenproject.org Mon Jan 20 03:35:08 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Jan 2025 03:35:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.874767.1285146 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZiYv-0004Vt-N9; Mon, 20 Jan 2025 03:34:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 874767.1285146; Mon, 20 Jan 2025 03:34:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZiYv-0004Vb-IC; Mon, 20 Jan 2025 03:34:53 +0000
Received: by outflank-mailman (input) for mailman id 874767;
 Mon, 20 Jan 2025 03:34:52 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=ri3r=UM=linux.dev=sui.jingfeng@srs-se1.protection.inumbo.net>)
 id 1tZiYr-0004VR-73
 for xen-devel@lists.xenproject.org; Mon, 20 Jan 2025 03:34:52 +0000
Received: from out-182.mta0.migadu.com (out-182.mta0.migadu.com
 [2001:41d0:1004:224b::b6])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7de3ff81-d6df-11ef-99a4-01e77a169b0f;
 Mon, 20 Jan 2025 04:34:45 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 7de3ff81-d6df-11ef-99a4-01e77a169b0f
Message-ID: <3d4e4bda-f465-4c8a-97c4-846b2f3ecb54@linux.dev>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1;
	t=1737344078;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=R9tPeFJh3Z8KzRS9nqqf16JZtB2EUc5uK4Rq+n7DfNw=;
	b=YY0vmGRwrZUTBrUrgVqfAahrdf8E2LNioasg7jg8ibtK9oZUoF3Gyb6ENECPTEd6jx4ozD
	dCAprAdgpk+wCkRotDFwZGdWs/yRlXxl8a6R+PVCHx5z5L1Gon1hTd9+nMflzGPYruxiHZ
	vu7GbnHgrZEtNupovuNQyF4Ah1bgbyA=
Date: Mon, 20 Jan 2025 11:34:27 +0800
MIME-Version: 1.0
Subject: Re: [PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with
 drm_mode_size_dumb()
To: Geert Uytterhoeven <geert@linux-m68k.org>,
 Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>,
 maarten.lankhorst@linux.intel.com, mripard@kernel.org, airlied@gmail.com,
 simona@ffwll.ch, dri-devel@lists.freedesktop.org,
 linux-mediatek@lists.infradead.org, freedreno@lists.freedesktop.org,
 linux-arm-msm@vger.kernel.org, imx@lists.linux.dev,
 linux-samsung-soc@vger.kernel.org, nouveau@lists.freedesktop.org,
 virtualization@lists.linux.dev, spice-devel@lists.freedesktop.org,
 linux-renesas-soc@vger.kernel.org, linux-rockchip@lists.infradead.org,
 linux-tegra@vger.kernel.org, intel-xe@lists.freedesktop.org,
 xen-devel@lists.xenproject.org,
 Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
 Andy Yan <andyshrk@163.com>, Daniel Stone <daniel@fooishbar.org>
References: <20250109150310.219442-1-tzimmermann@suse.de>
 <20250109150310.219442-26-tzimmermann@suse.de>
 <cdbe483d-0895-47aa-8c83-1c28220f4a02@ideasonboard.com>
 <bc97b92e-7f8a-4b92-af8a-20fa165ead55@suse.de>
 <f3ba05c7-6e49-4641-a3f9-ba418ebdb7c3@ideasonboard.com>
 <c6735280-7c32-4319-8ca9-a7305d8117c3@suse.de>
 <d67adb03-5cd0-4ac9-af58-cf4446dacee3@ideasonboard.com>
 <0ea6be58-0e04-4172-87cd-064a3e4a43bc@suse.de>
 <f35cb350-6be9-48ca-ad7e-e9dd418281d5@ideasonboard.com>
 <4af0b6a7-c16a-4187-bbf5-365a9c86de21@suse.de>
 <e327ad84-b5c9-4480-b873-dc3aca605538@ideasonboard.com>
 <a2bbeb47-2569-4ee0-9265-92bab139bdc6@suse.de>
 <f3833771-fcd7-45dc-9019-1525fef34429@ideasonboard.com>
 <CAMuHMdXxYa+Na3XxpLTy=-eUL_zQ9kAiUKYu-E04u3KWApusSA@mail.gmail.com>
Content-Language: en-US
X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers.
From: Sui Jingfeng <sui.jingfeng@linux.dev>
In-Reply-To: <CAMuHMdXxYa+Na3XxpLTy=-eUL_zQ9kAiUKYu-E04u3KWApusSA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Migadu-Flow: FLOW_OUT

Hi,

On 2025/1/16 18:17, Geert Uytterhoeven wrote:
> On Thu, Jan 16, 2025 at 11:03 AM Tomi Valkeinen
> <tomi.valkeinen@ideasonboard.com> wrote:
>> On 16/01/2025 10:09, Thomas Zimmermann wrote:
>>> Am 15.01.25 um 15:20 schrieb Tomi Valkeinen:
>>> [...]
>>>> My point is that we have the current UAPI, and we have userspace using
>>>> it, but we don't have clear rules what the ioctl does with specific
>>>> parameters, and we don't document how it has to be used.
>>>>
>>>> Perhaps the situation is bad, and all we can really say is that
>>>> CREATE_DUMB only works for use with simple RGB formats, and the
>>>> behavior for all other formats is platform specific. But I think even
>>>> that would be valuable in the UAPI docs.
>>> To be honest, I would not want to specify behavior for anything but the
>>> linear RGB formats. If anything, I'd take Daniel's reply mail for
>>> documentation as-is. Anyone stretching the UAPI beyond RGB is on their own.
>>>
>>>> Thinking about this, I wonder if this change is good for omapdrm or
>>>> xilinx (probably other platforms too that support non-simple non-RGB
>>>> formats via dumb buffers): without this patch, in both drivers, the
>>>> pitch calculations just take the bpp as bit-per-pixels, align it up,
>>>> and that's it.
>>>>
>>>> With this patch we end up using drm_driver_color_mode_format(), and
>>>> aligning buffers according to RGB formats figured out via heuristics.
>>>> It does happen to work, for the formats I tested, but it sounds like
>>>> something that might easily not work, as it's doing adjustments based
>>>> on wrong format.
>>>>
>>>> Should we have another version of drm_mode_size_dumb() which just
>>>> calculates using the bpp, without the drm_driver_color_mode_format()
>>>> path? Or does the drm_driver_color_mode_format() path provide some
>>>> value for the drivers that do not currently do anything similar?
>>> With the RGB-only rule, using drm_driver_color_mode_format() makes
>>> sense. It aligns dumb buffers and video=, provides error checking, and
>>> overall harmonizes code. The fallback is only required because of the
>>> existing odd cases that already bend the UAPI's rules.
>> I have to disagree here.
>>
>> On the platforms I have been using (omap, tidss, xilinx, rcar) the dumb
>> buffers are the only buffers you can get from the DRM driver. The dumb
>> buffers have been used to allocate linear and multiplanar YUV buffers
>> for a very long time on those platforms.
>>
>> I tried to look around, but I did not find any mentions that CREATE_DUMB
>> should only be used for RGB buffers. Is anyone outside the core
>> developers even aware of it?
>>
>> If we don't use dumb buffers there, where do we get the buffers? Maybe
>> from a v4l2 device or from a gpu device, but often you don't have those.
>> DMA_HEAP is there, of course.
> Why can't there be a variant that takes a proper fourcc format instead of
> an imprecise bpp value?

The 'flags' parameter of the 'struct drm_mode_create_dumb' doesn't gets
in used so far, I guess the situation will be much better if passing a
correct fourcc code from the user-space to kernel is allowed.


> Gr{oetje,eeting}s,
>
>                          Geert
>
-- 
Best regards,
Sui



From xen-devel-bounces@lists.xenproject.org Mon Jan 20 07:05:32 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Jan 2025 07:05:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.874782.1285156 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZlqX-0004D9-SB; Mon, 20 Jan 2025 07:05:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 874782.1285156; Mon, 20 Jan 2025 07:05:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZlqX-0004D2-Ok; Mon, 20 Jan 2025 07:05:17 +0000
Received: by outflank-mailman (input) for mailman id 874782;
 Mon, 20 Jan 2025 07:05:16 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=ri3r=UM=linux.dev=sui.jingfeng@srs-se1.protection.inumbo.net>)
 id 1tZlqT-0004Cw-UI
 for xen-devel@lists.xenproject.org; Mon, 20 Jan 2025 07:05:16 +0000
Received: from out-171.mta0.migadu.com (out-171.mta0.migadu.com
 [91.218.175.171]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e2547ce5-d6fc-11ef-99a4-01e77a169b0f;
 Mon, 20 Jan 2025 08:05:09 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e2547ce5-d6fc-11ef-99a4-01e77a169b0f
Message-ID: <84adda72-24c1-428d-9c55-8bb9ec189584@linux.dev>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1;
	t=1737356708;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=s4k8B9SqdOW/b4nXIri28MHaonby69L1MPYqhyNKUX0=;
	b=H42Z2l+UXNpZWYWEmHERkXyThqLsthOt2Tl1gQlgH7BXsUNxeI/rr3PfiugdYdU7zHqpvq
	dLqd9siDrRP2RNM9ARbxgV6zGEqcH+5CdCKOZz1TBdC0GDysb1JYpX1OOzaYOnjlwgwB22
	siLOW8pFM6wtm6a+laFnQN1GQRPRQXE=
Date: Mon, 20 Jan 2025 15:04:56 +0800
MIME-Version: 1.0
Subject: Re: [PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with
 drm_mode_size_dumb()
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>,
 Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
 Geert Uytterhoeven <geert@linux-m68k.org>,
 Thomas Zimmermann <tzimmermann@suse.de>, maarten.lankhorst@linux.intel.com,
 mripard@kernel.org, airlied@gmail.com, simona@ffwll.ch,
 dri-devel@lists.freedesktop.org, linux-mediatek@lists.infradead.org,
 freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
 imx@lists.linux.dev, linux-samsung-soc@vger.kernel.org,
 nouveau@lists.freedesktop.org, virtualization@lists.linux.dev,
 spice-devel@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org,
 linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org,
 intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org,
 Andy Yan <andyshrk@163.com>, Daniel Stone <daniel@fooishbar.org>
References: <e327ad84-b5c9-4480-b873-dc3aca605538@ideasonboard.com>
 <a2bbeb47-2569-4ee0-9265-92bab139bdc6@suse.de>
 <f3833771-fcd7-45dc-9019-1525fef34429@ideasonboard.com>
 <CAMuHMdXxYa+Na3XxpLTy=-eUL_zQ9kAiUKYu-E04u3KWApusSA@mail.gmail.com>
 <xz5ncq67bgmdase2jg3cfvyaxpiwhol2eqpfzow6dqpauvslo5@2w3rw27lhnxo>
 <b97fcd2f-516a-4172-aef3-631418564cfa@linux.dev>
 <ef52dab0-058f-408f-a298-c4b2453a3d2f@ideasonboard.com>
 <f4562dbf-b132-4cfd-8f7e-43cd69f2673f@linux.dev>
 <cf34be39-ce92-4ea5-b548-03008c163d31@ideasonboard.com>
 <8234927e-0d12-4655-813d-8ec94179b737@linux.dev>
 <20250119201443.GB2467@pendragon.ideasonboard.com>
Content-Language: en-US
X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers.
From: Sui Jingfeng <sui.jingfeng@linux.dev>
In-Reply-To: <20250119201443.GB2467@pendragon.ideasonboard.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Migadu-Flow: FLOW_OUT

Hi,

On 2025/1/20 04:14, Laurent Pinchart wrote:
> On Mon, Jan 20, 2025 at 12:26:30AM +0800, Sui Jingfeng wrote:
>> On 2025/1/19 23:22, Tomi Valkeinen wrote:
>>> On 19/01/2025 16:59, Sui Jingfeng wrote:
>>>
>>>>>>> But userspace must be able to continue allocating YUV buffers through
>>>>>>> CREATE_DUMB.
>>>>>> I think, allocating YUV buffers through CREATE_DUMB interface is just
>>>>>> an *abuse* and *misuse* of this API for now.
>>>>>>
>>>>>> Take the NV12 format as an example, NV12 is YUV420 planar format, have
>>>>>> two planar: the Y-planar and the UV-planar. The Y-planar appear first
>>>>>> in memory as an array of unsigned char values. The Y-planar is followed
>>>>>> immediately by the UV-planar, which is also an array of unsigned char
>>>>>> values that contains packed U (Cb) and V (Cr) samples.
>>>>>>
>>>>>> But the 'drm_mode_create_dumb' structure is only intend to provide
>>>>>> descriptions for *one* planar.
>>>>>>
>>>>>> struct drm_mode_create_dumb {
>>>>>>       __u32 height;
>>>>>>       __u32 width;
>>>>>>       __u32 bpp;
>>>>>>       __u32 flags;
>>>>>>       __u32 handle;
>>>>>>       __u32 pitch;
>>>>>>       __u64 size;
>>>>>> };
>>>>>>
>>>>>> An width x height NV12 image takes up width*height*(1 + 1/4 + 1/4)
>>>>>> bytes.
>>>>>>
>>>>>> So we can allocate an *equivalent* sized buffer to store the NV12
>>>>>> raw data.
>>>>>>
>>>>>> Either 'width * (height * 3/2)' where each pixel take up 8 bits,
>>>>>> or just 'with * height' where each pixels take up 12 bits.
>>>>>>
>>>>>> However, all those math are just equivalents description to the original
>>>>>> NV12 format, neither are concrete correct physical description.
>>>>> I don't see the problem. Allocating dumb buffers, if we don't have
>>>>> any heuristics related to RGB behind it, is essentially just
>>>>> allocating a specific amount of memory, defined by width, height and
>>>>> bitsperpixel.
>>>>>
>>>> I think, the problem will be that the 'width', 'height' and 'bpp'
>>>> are originally used to describe one plane. Those three parameters
>>>> has perfectly defined physical semantics.
>>>>
>>>> But with multi planar formats, take NV12 image as an example,
>>>> for a 2×2 square of pixels, there are 4 Y samples but only 1 U
>>>> sample and 1 V sample. This format requires 4x8+1x8+1x8=48 bits
>>>> to store the 2x2 square.
>>>>
>>>> So its depth is 12 bits per pixel (48 / (2 * 2)).
>>>>
>>>> so my problem is that the mentioned 12bpp in this example only
>>>> make sense in mathematics, it doesn't has a good physical
>>>> interpret. Do you agree with me on this technique point?
>>>>
>>>>> If I want to create an NV12 framebuffer, I allocate two dumb
>>>>> buffers, one for Y and one for UV planes, and size them accordingly.
>>>>> And then create the DRM framebuffer with those.
>>>>>
>>>> Then how you fill the value of the 'width', 'height' and 'bpp' of
>>>> each dumb buffers?
>>> For 640x480-NV12:
>>> plane 0: width = 640, height = 480, bpp = 8
>>> plane 1: width = 640 / 2, height = 480 / 2, bpp = 16
>> But i think this should be hardware dependent. The hardware I'm using
>> load NV12  raw data as a whole. I only need to feed gpuva of the backing
>> memory to the hardware register once.
>>
>> Not familiar with your hardware, so I can't talk more on this software
>> design. Perhaps someone know more could have a comment on this.
> Layout of planes in memory is just one hardware constraint, the same way
> we have constraints on alignment and strides. Some devices require the
> planes to be contiguous (likely with some alignment constraints), some
> can work with planes being in discontiguous pieces of memory, and even
> require them to be discontiguous and located in separate DRAM banks.

Right.


>>>> Why not allocate storage for the whole on one shoot?
>>> You can, if you adjust the parameters accordingly. However, if the
>>> strides of the planes are not equal, I guess it might cause problems
>>> on some platforms.
>>>
>>> But I think it's usually simpler to allocate one buffer per plane, and
>>> perhaps even better as it doesn't require as large contiguous memory
>>> area.
>>>
>>>> The modetest in libdrm can be an good example, send it[1] to you as
>>>> an reference.
>>> Right, so modetest already does it successfully. So... What is the issue?
>> But then, the problem will become that it override the 'height' parameter.
>> What's the physical interpretation of the 'height' parameter when creating
>> an NV12 image with the dump API then?
> I wouldn't be too concerned about physical interpretations. Yes, the
> height, width and bpp parameters were likely designed with RGB formats
> in mind. Yes, using DUMB_CREATE for YUV formats is probably something
> that the original authors didn't envision. And yes, from that point of
> view, it could be seen by the original authors as an abuse of the API.
> But I don't think that's a problem as such.

Sometimes there may have 2D GPU or Image Process Unit get involved.
Setting the dimension, the clip window and pitch etc parameters to the
hardware are needed.

The value of bpp affects pitch, bigger pitch may cause the hardware load
more bytes than it should on one line. While the 'height' may affect the
size of the clip window, depend on the calculation method.

But I have no strong opinion toward with this and agree with you in overall.

> An API is just an API. True, it would be nicer if the usage of the ioctl
> parameters was more intuitive for YUV formats, but I believe we could
> still standardize how the existing parameters map to linear scanout YUV
> formats without causing the world to end. As has been said before, lots
> of drivers are using DUMB_CREATE for this purpose, and we can't change
> that.
>
> This doesn't mean we shouldn't work on improving memory allocation, but
> I see that as a separate issue.
>
>> I guess, solving complex problems with simple APIs may see the limitation,
>> sooner or later. But I not very sure and might be wrong. So other peoples
>> can override me words.
>>
>>> Everyone agrees that CREATE_DUMB is not the best ioctl to allocate
>>> buffers, and one can't consider it to work identically across the
>>> platforms. But it's what we have and what has been used for ages.
>> Yeah, your request are not unreasonable. It can be seen as a kind of rigid demand.
>> Since GEM DMA helpers doesn't export an more advanced interface to userspace so far.
>> As a result, drivers that employing GEM DMA has no other choice, but to abuse the
>> dumb buffer API to do allocation for the more complex format buffers.
>>
>> The dumb buffer API doesn't support to specify buffer format, tile status and
>> placement etc. The more advance drivers has been exposed the xxx_create_gem()
>> to user-space. It seems that a few more experienced programmers hint us to
>> create an new ioctl at above thread, so that we can keep employing simple API
>> to do simple things and to suit complex needs with the more advanced APIs.
> I'd really like to explore adding new ioctls to exposure memory
> allocation constraints, and allocating the memory itself from DMA heaps.
>
-- 
Best regards,
Sui



From xen-devel-bounces@lists.xenproject.org Mon Jan 20 07:49:26 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Jan 2025 07:49:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.874790.1285167 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZmXA-00012K-T0; Mon, 20 Jan 2025 07:49:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 874790.1285167; Mon, 20 Jan 2025 07:49:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZmXA-00012D-OC; Mon, 20 Jan 2025 07:49:20 +0000
Received: by outflank-mailman (input) for mailman id 874790;
 Mon, 20 Jan 2025 07:49:20 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=D7kk=UM=suse.de=tzimmermann@srs-se1.protection.inumbo.net>)
 id 1tZmXA-000127-2q
 for xen-devel@lists.xenproject.org; Mon, 20 Jan 2025 07:49:20 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de
 [2a07:de40:b251:101:10:150:64:2])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0d0f5a41-d703-11ef-99a4-01e77a169b0f;
 Mon, 20 Jan 2025 08:49:17 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id EFFAF1F7A0;
 Mon, 20 Jan 2025 07:49:16 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 6B5AC1393E;
 Mon, 20 Jan 2025 07:49:16 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id OWHAGPz/jWeMZgAAD6G6ig
 (envelope-from <tzimmermann@suse.de>); Mon, 20 Jan 2025 07:49:16 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 0d0f5a41-d703-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1737359357; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=RZvZ3OHRKadbpCzwXWAL9vLWOCTKT7oyU5vMn2WBlbQ=;
	b=rxs81/qA+bqzO4BE/s58b3QnZ9ySonlik4XEccALctdyByQ0CfWLJZO4UVHI5jtBECf6RV
	cmXxgS7mzJNeBldU+QkbCQ/JOHv3CD/IC3KG5cD+dcZ1XLmX81Q1qDPmwlkhuezC9c6J65
	pXDSfpcuX4rUspcXjJZWoQzkUvEU8wM=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1737359357;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=RZvZ3OHRKadbpCzwXWAL9vLWOCTKT7oyU5vMn2WBlbQ=;
	b=+Mr1oFFrBhsU+w8y11IF2x35dxiOsGhsMELD00UtG2qwMf7mYXoPuoXKDHLWyP5HflI4YR
	KV4qljNpKhKcuHAA==
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1737359356; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=RZvZ3OHRKadbpCzwXWAL9vLWOCTKT7oyU5vMn2WBlbQ=;
	b=2YEQodiuZ3UsPCWnqdQR5j65/V3LzIyTQOZmU+zah5ybLMPcCp2h8kDcRvxehKn20iQ/Xi
	2P8iRS8l+8D8L4xJj9TGLESugE124kevxgeqjiUoW4bK3KbBS8TYObyw6uPets5WiVIFCv
	2xtZw3gud2Zba+Nr9FAP5CT1rpKPbOI=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1737359356;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=RZvZ3OHRKadbpCzwXWAL9vLWOCTKT7oyU5vMn2WBlbQ=;
	b=Y38vcmSMf3QLl1H/CftXf7wTfovn1ctCaZ2FOKCqx9I5f1sOR0jqGX7BJ+poBWrpS+flOa
	IsIoNujSOz8vXSCg==
Message-ID: <156804a9-3095-4c93-888f-d9041f523da6@suse.de>
Date: Mon, 20 Jan 2025 08:49:16 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with
 drm_mode_size_dumb()
To: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>,
 maarten.lankhorst@linux.intel.com, mripard@kernel.org, airlied@gmail.com,
 simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org, linux-mediatek@lists.infradead.org,
 freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
 imx@lists.linux.dev, linux-samsung-soc@vger.kernel.org,
 nouveau@lists.freedesktop.org, virtualization@lists.linux.dev,
 spice-devel@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org,
 linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org,
 intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org,
 Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
 Andy Yan <andyshrk@163.com>, Daniel Stone <daniel@fooishbar.org>
References: <20250109150310.219442-1-tzimmermann@suse.de>
 <20250109150310.219442-26-tzimmermann@suse.de>
 <cdbe483d-0895-47aa-8c83-1c28220f4a02@ideasonboard.com>
 <bc97b92e-7f8a-4b92-af8a-20fa165ead55@suse.de>
 <f3ba05c7-6e49-4641-a3f9-ba418ebdb7c3@ideasonboard.com>
 <c6735280-7c32-4319-8ca9-a7305d8117c3@suse.de>
 <d67adb03-5cd0-4ac9-af58-cf4446dacee3@ideasonboard.com>
 <0ea6be58-0e04-4172-87cd-064a3e4a43bc@suse.de>
 <f35cb350-6be9-48ca-ad7e-e9dd418281d5@ideasonboard.com>
 <4af0b6a7-c16a-4187-bbf5-365a9c86de21@suse.de>
 <e327ad84-b5c9-4480-b873-dc3aca605538@ideasonboard.com>
 <a2bbeb47-2569-4ee0-9265-92bab139bdc6@suse.de>
 <f3833771-fcd7-45dc-9019-1525fef34429@ideasonboard.com>
Content-Language: en-US
From: Thomas Zimmermann <tzimmermann@suse.de>
Autocrypt: addr=tzimmermann@suse.de; keydata=
 xsBNBFs50uABCADEHPidWt974CaxBVbrIBwqcq/WURinJ3+2WlIrKWspiP83vfZKaXhFYsdg
 XH47fDVbPPj+d6tQrw5lPQCyqjwrCPYnq3WlIBnGPJ4/jreTL6V+qfKRDlGLWFjZcsrPJGE0
 BeB5BbqP5erN1qylK9i3gPoQjXGhpBpQYwRrEyQyjuvk+Ev0K1Jc5tVDeJAuau3TGNgah4Yc
 hdHm3bkPjz9EErV85RwvImQ1dptvx6s7xzwXTgGAsaYZsL8WCwDaTuqFa1d1jjlaxg6+tZsB
 9GluwvIhSezPgnEmimZDkGnZRRSFiGP8yjqTjjWuf0bSj5rUnTGiyLyRZRNGcXmu6hjlABEB
 AAHNJ1Rob21hcyBaaW1tZXJtYW5uIDx0emltbWVybWFubkBzdXNlLmRlPsLAjgQTAQgAOAIb
 AwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftODH
 AAoJEGgNwR1TC3ojx1wH/0hKGWugiqDgLNXLRD/4TfHBEKmxIrmfu9Z5t7vwUKfwhFL6hqvo
 lXPJJKQpQ2z8+X2vZm/slsLn7J1yjrOsoJhKABDi+3QWWSGkaGwRJAdPVVyJMfJRNNNIKwVb
 U6B1BkX2XDKDGffF4TxlOpSQzdtNI/9gleOoUA8+jy8knnDYzjBNOZqLG2FuTdicBXblz0Mf
 vg41gd9kCwYXDnD91rJU8tzylXv03E75NCaTxTM+FBXPmsAVYQ4GYhhgFt8S2UWMoaaABLDe
 7l5FdnLdDEcbmd8uLU2CaG4W2cLrUaI4jz2XbkcPQkqTQ3EB67hYkjiEE6Zy3ggOitiQGcqp
 j//OwE0EWznS4AEIAMYmP4M/V+T5RY5at/g7rUdNsLhWv1APYrh9RQefODYHrNRHUE9eosYb
 T6XMryR9hT8XlGOYRwKWwiQBoWSDiTMo/Xi29jUnn4BXfI2px2DTXwc22LKtLAgTRjP+qbU6
 3Y0xnQN29UGDbYgyyK51DW3H0If2a3JNsheAAK+Xc9baj0LGIc8T9uiEWHBnCH+RdhgATnWW
 GKdDegUR5BkDfDg5O/FISymJBHx2Dyoklv5g4BzkgqTqwmaYzsl8UxZKvbaxq0zbehDda8lv
 hFXodNFMAgTLJlLuDYOGLK2AwbrS3Sp0AEbkpdJBb44qVlGm5bApZouHeJ/+n+7r12+lqdsA
 EQEAAcLAdgQYAQgAIAIbDBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftOH6AAoJEGgNwR1T
 C3ojVSkIALpAPkIJPQoURPb1VWjh34l0HlglmYHvZszJWTXYwavHR8+k6Baa6H7ufXNQtThR
 yIxJrQLW6rV5lm7TjhffEhxVCn37+cg0zZ3j7zIsSS0rx/aMwi6VhFJA5hfn3T0TtrijKP4A
 SAQO9xD1Zk9/61JWk8OysuIh7MXkl0fxbRKWE93XeQBhIJHQfnc+YBLprdnxR446Sh8Wn/2D
 Ya8cavuWf2zrB6cZurs048xe0UbSW5AOSo4V9M0jzYI4nZqTmPxYyXbm30Kvmz0rYVRaitYJ
 4kyYYMhuULvrJDMjZRvaNe52tkKAvMevcGdt38H4KSVXAylqyQOW5zvPc4/sq9c=
In-Reply-To: <f3833771-fcd7-45dc-9019-1525fef34429@ideasonboard.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Level: 
X-Spamd-Result: default: False [-2.80 / 50.00];
	BAYES_HAM(-3.00)[99.99%];
	SUSPICIOUS_RECIPS(1.50)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	FREEMAIL_TO(0.00)[ideasonboard.com,linux.intel.com,kernel.org,gmail.com,ffwll.ch];
	RCPT_COUNT_TWELVE(0.00)[22];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_ALL(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	FREEMAIL_ENVRCPT(0.00)[163.com,gmail.com];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	FROM_HAS_DN(0.00)[];
	FREEMAIL_CC(0.00)[lists.freedesktop.org,lists.infradead.org,vger.kernel.org,lists.linux.dev,lists.xenproject.org,ideasonboard.com,163.com,fooishbar.org];
	TO_DN_SOME(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:mid,imap1.dmz-prg2.suse.org:helo]
X-Spam-Score: -2.80
X-Spam-Flag: NO

Hi


Am 16.01.25 um 11:03 schrieb Tomi Valkeinen:
[...]
> Aligning video= and dumb buffers almost sounds like going backwards. 
> video= parameter is bad,

Who told you that? Video= is still the way to specify an initial display 
mode to the kernel and it will remain so.

Of course, it is better to auto-detect settings, but that's for a 
different use case.

Best regards
Thomas

>
> Harmonizing code is fine, but I think that can be done with a function 
> that only does the fallback-case.
>
> So... I can only speak for the platforms I'm using and maintaining, 
> but I'd rather keep the old behavior for CREATE_DUMB that we've had 
> for ages.
>
>  Tomi
>

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)



From xen-devel-bounces@lists.xenproject.org Mon Jan 20 07:53:18 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Jan 2025 07:53:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.874799.1285175 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZmaz-0002fk-9a; Mon, 20 Jan 2025 07:53:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 874799.1285175; Mon, 20 Jan 2025 07:53:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZmaz-0002fd-6r; Mon, 20 Jan 2025 07:53:17 +0000
Received: by outflank-mailman (input) for mailman id 874799;
 Mon, 20 Jan 2025 07:53: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 <SRS0=BOU1=UM=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tZmax-0002fX-Qs
 for xen-devel@lists.xenproject.org; Mon, 20 Jan 2025 07:53:15 +0000
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com
 [2a00:1450:4864:20::42c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9a4bc177-d703-11ef-a0e3-8be0dac302b0;
 Mon, 20 Jan 2025 08:53:14 +0100 (CET)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-38789e5b6a7so2271611f8f.1
 for <xen-devel@lists.xenproject.org>; Sun, 19 Jan 2025 23:53:14 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38bf32755f0sm9653085f8f.76.2025.01.19.23.53.12
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 19 Jan 2025 23:53:13 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9a4bc177-d703-11ef-a0e3-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737359594; x=1737964394; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=1GKvWEfMKJ+hyDx9pO6ChzbiDFbdAHbptH/AKvnW094=;
        b=IhQAfXfT0qt/SFSMkYaPVjgYMX8gk6YSsYIo3Xp7GP5OboDtdY0n0tzJbdlP+1VNjQ
         iKyyE6IlHtCDR3/6EA1kARBb0ugm3JhcRzN0kzo1ycIUBewW3jq9IBtZslFaMtg3/Aer
         pO4qobj7Z5w2fnAMZvLwNgTTZ9dkpoo9sOwPtyBJ/3JE4uC5Zk/VDf4dFlkvaxNchm3f
         kNegOVxqt89ecxScLJGJ+a+9wN6ZNWJfktEGcpUODSvdIBY4NlQ3mDp9+B5O88Yl7f2/
         Us+2zmwoRzF78GmE1O6aG+CCMNpcpvr7oUPoz29RL7+Fozjn/Lxs+eQKDXINW9YwM+67
         0flg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737359594; x=1737964394;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=1GKvWEfMKJ+hyDx9pO6ChzbiDFbdAHbptH/AKvnW094=;
        b=G6eFA1qCiYtInQu99p54sOtr7oVtTwwF9eUriGTDK0z1+YQjoLD3Uur4zjA1TnsFF3
         xXsLz2OHxTEeA0lWvdHoxk0XwX3c7UgOw+1CoPQm4z/ed30cujXOyB22fiS2yiMr8K42
         cxeND680+VH3h7Xfwioal7SKe0v+/Yu9sOckWNYPAEwAS7B1O7oNCgpyXzsxqOrgYvGO
         YVQsmM/X7SlsjAPIISPDZCPwn6JioL5b+10KhPWWPjSQ3Vqd8H5xeDVihxajPS74Zbgk
         5w4uchzy2pgG/0MdnS/38ps1OQ8XWwTRFh1aoEz9Sq8ah9maMkj/A8owzmxHwKmqX+Ar
         oCqg==
X-Forwarded-Encrypted: i=1; AJvYcCUCd5CieVI5hodzN1UEEa/T7DlM0n7TT488gnYCZz/zSlahcKY5vcpeaFsXywICqOTCEJsDQtYVzKE=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yws6QjK9KPXY/KIqjoC95ifvC8Ez3sWGRSvOeuZti9VOhwrpGxJ
	2ucXpZy3pGePIZbZA/Ixr3ZlPSB8JISvqeEi8xyo/7GvnSMcWgmmxb4yFQW1Ig==
X-Gm-Gg: ASbGncuJPVoseALzLCIELqHzSWIT370/+bHIzR4ahiGR7gAR/4nUYDww9GzpX/+LJK2
	Zr1kUsoEye4BzEtFNigVQ+Lu7WPLzuRJKcnQGNaieDfvhB5XbtIU+7W+kUbCbaI8acnXqnIigeQ
	LTlEljChj6QQn6SlNymt8P0+2bUwj0fDJyBEfMKssiyYEuPg7OivJtn6hwtHgRh/TD07/YXT/HR
	KbHOls9vHpK7OnvPd+1H6vdo/5o3SgM80CyKeTvtWWBHuK30EL2Cxdih6UA76mxcwGMOMnBEyCr
	u0uIByDGP8LCoEJ3zTHgpXu73evRUajJ00M7UvxSpOV0KUn3djQUt84=
X-Google-Smtp-Source: AGHT+IHAuRNDcc+OI1Jv04rsfnMH2dRW4L+7iILK4E/JOPPajiqMrwlk8MP6aJIR2aTA8dWarW+nvA==
X-Received: by 2002:a05:6000:8c:b0:386:3f3e:ab11 with SMTP id ffacd0b85a97d-38bf57a25b1mr7811923f8f.34.1737359593348;
        Sun, 19 Jan 2025 23:53:13 -0800 (PST)
Message-ID: <40c9d806-000d-43e7-a804-ad4e84209b2f@suse.com>
Date: Mon, 20 Jan 2025 08:53:14 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/4] x86: provide an inverted Kconfig control for
 shim-exclusive mode
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Alejandro Vallejo <alejandro.vallejo@cloud.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Julien Grall <julien@xen.org>, Wei Liu <wl@xen.org>, sergiy_kibrik@epam.com,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>
References: <da5f5bac-6d5d-092d-d872-f1120dcd2661@suse.com>
 <617842e1-8ef2-b095-0c52-c2e2e5f1c0a8@suse.com>
 <alpine.DEB.2.22.394.2501161503120.2684657@ubuntu-linux-20-04-desktop>
 <Z4oxZSUQ6VARiR0H@macbook.local> <D74CH4RDRRR9.ZR6RL8U6PQ56@cloud.com>
 <6285f86d-f2d2-4040-999d-01aed3e72a36@suse.com>
 <alpine.DEB.2.22.394.2501171430570.2684657@ubuntu-linux-20-04-desktop>
 <f8c1e2c2-ceb5-4200-a304-e2d824a171a8@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <f8c1e2c2-ceb5-4200-a304-e2d824a171a8@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 18.01.2025 00:41, Andrew Cooper wrote:
> On 17/01/2025 10:43 pm, Stefano Stabellini wrote:
>> On Fri, 17 Jan 2025, Jan Beulich wrote:
>>> On 17.01.2025 13:24, Alejandro Vallejo wrote:
>>>> On Fri Jan 17, 2025 at 10:31 AM GMT, Roger Pau Monné wrote:
>>>>> On Thu, Jan 16, 2025 at 04:31:46PM -0800, Stefano Stabellini wrote:
>>>>>> On Wed, 1 Mar 2023, Jan Beulich wrote:
>>>>>>> While we want certain things turned off in shim-exclusive mode, doing
>>>>>>> so via "depends on !PV_SHIM_EXCLUSIVE" badly affects allyesconfig: Since
>>>>>>> that will turn on PV_SHIM_EXCLUSIVE, other options will be turned off as
>>>>>>> a result. Yet allyesconfig wants to enable as much of the functionality
>>>>>>> as possible.
>>>>>>>
>>>>>>> Retain PV_SHIM_EXCLUSIVE as a prompt-less option such that first of all
>>>>>>> C code using it can remain as is. This isn't just for less code churn,
>>>>>>> but also because I think that symbol is more logical to use in many
>>>>>>> (all?) places.
>>>>>>>
>>>>>>> Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>>>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>>>>>
>>>>>>> ---
>>>>>>> The new Kconfig control's name is up for improvement suggestions, but I
>>>>>>> think it's already better than the originally thought of
>>>>>>> FULL_HYPERVISOR.
>>>>>> I think the approach in general is OK, maybe we can improve the naming
>>>>>> further. What about one of the following?
>>>>>>
>>>>>> NO_PV_SHIM_EXCLUSIVE
>>>>>> PV_SHIM_NOT_EXCLUSIVE
>>>>> IMO negated options are confusing, and if possible I think we should
>>>>> avoid using them unless strictly necessary.
>>>> The problem is that the option is negative in nature. It's asking for
>>>> hypervisor without _something_. I do agree with Stefano that shim would be
>>>> better in the name. Otherwise readers are forced to play divination tricks.
>>>>
>>>> How about something like:
>>>>
>>>>     SHIMLESS_HYPERVISOR
>>>>
>>>> That's arguably not negated, preserves "shim" in the name and has the correct
>>>> polarity for allyesconfig to yield the right thing.
>>> Except that a hypervisor with this option enabled isn't shim-less, but permits
>>> working in shim as well as in non-shim mode.
>> First, let's recognize that we have two opposing requirements. One
>> requirement is to make it as easy as possible to configure for the user.
>> Ideally without using negative CONFIG options, such as
>> NO_PV_SHIM_EXCLUSIVE. From the user point of view, honestly,
>> PV_SHIM_EXCLUSIVE is a pretty good name. Better than all of the others,
>> I think.
>>
>> On the other hand, we have the requirement that we don't want
>> allyesconfig to end up disabling a bunch of CONFIG options. Now this
>> requirement can be satisfied easily by adding something like
>> NO_PV_SHIM_EXCLUSIVE. However, it would go somewhat against the previous
>> requirement.
>>
>> So we need a compromise, something that doesn't end up disabling other
>> CONFIG options, to make allyesconfig happy, but also not too confusing
>> for the user (which is a matter of personal opinion).
>>
>> In short, expect that people will have different opinions on this and
>> will find different compromises better or worse. For one, I prefer to
>> compromise on "no negative CONFIG options" and use
>> PV_SHIM_NOT_EXCLUSIVE. Because it serves the allyesconfig goal, and
>> while it is not as clear as PV_SHIM_EXCLUSIVE, is still better than a
>> completely generic FULL_HYPERVISOR option, which means nothing to me.
>>
>> I cannot see a way to have a good and clear non-negated CONFIG option,
>> and also satisfy the allyesconfig requirement. So I prefer to compromise
>> on the "non-negated" part.
> 
> Debating the naming is missing the point.
> 
> 
> The problem here is the wish to have PV_SHIM_EXCLUSIVE behave in a way
> that Kconfig is not capable of expressing.  Specifically, what is broken
> is having "lower level" options inhibit unrelated "higher level" options
> when the graph gets rescanned[1].  That's why we're in the laughable
> position of `make allyesconfig` turning off CONFIG_HVM.
> 
> Jan, you want "echo PV_SHIM_EXCLUSIVE=y >> .config && make" to mean
> "reset me back to a PV Shim".

Isn't this an independent goal? Or is this a statement on what you see
my change (kind of) doing, indicating you consider this wrong?

> Kconfig spells this "make $foo_defconfig" for an appropriately given foo.
> 
> 
> There should be:
> 
> 1) an option called PV_SHIM_EXCLUSIVE which does *nothing* other than
> making the boolean be a compile time constant.

I fear it remains unclear to me what exactly you mean here. It feels like
you may be suggesting that all other uses of PV_SHIM_EXCLUSIVE should be
dropped, without replacement. That seems wrong to me, though. In
particular I'm of the opinion that besides using "make pvshim_defconfig"
people ought to also have the option to properly configure a shim build
from scratch (or from any random .config they hold in hands), requiring
respective "depends on" and/or "select" / "imply" to be in place. Or else
they may end up with a lot of dead code. (Just consider e.g. HVM=n: We
also don't permit HVM-only stuff to be enabled in that case, as any of
that would again be dead code then.)

> 2) a pvshim_defconfig target which expresses what a pvshim ought to look
> like.

We have this file already. I consider it debatable though whether this file
should really force PV_SHIM_EXCLUSIVE=y. People may read "pvshim" in the
name as either "works just as shim" or "can also work as shim".

> Trying to fight against the behaviour of Kconfig is not a good use of
> anyone's time.
> 
> ~Andrew
> 
> [1] default to unrelated symbols is also broken for a related reason. 
> The result you get is sensitive to the order of processing of symbols.

Is it? It has been my understanding that defaults get re-evaluated as user
input is processed.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 20 07:54:54 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Jan 2025 07:54:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.874811.1285186 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZmcU-0003Gu-MD; Mon, 20 Jan 2025 07:54:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 874811.1285186; Mon, 20 Jan 2025 07:54:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZmcU-0003Gn-Jb; Mon, 20 Jan 2025 07:54:50 +0000
Received: by outflank-mailman (input) for mailman id 874811;
 Mon, 20 Jan 2025 07:54: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
 <SRS0=D7kk=UM=suse.de=tzimmermann@srs-se1.protection.inumbo.net>)
 id 1tZmcS-0003Fv-HM
 for xen-devel@lists.xenproject.org; Mon, 20 Jan 2025 07:54:48 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id cdedb0e6-d703-11ef-99a4-01e77a169b0f;
 Mon, 20 Jan 2025 08:54:41 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id 62A7721165;
 Mon, 20 Jan 2025 07:54:46 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id CC5C81393E;
 Mon, 20 Jan 2025 07:54:45 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id fe4aMEUBjmdrTgAAD6G6ig
 (envelope-from <tzimmermann@suse.de>); Mon, 20 Jan 2025 07:54:45 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: cdedb0e6-d703-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1737359686; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=62CCysYlf1kTpBmg533SyW74Db9V4YMx6+JH5cKqFcA=;
	b=FRr113FrvNY+g8Scutf0XfwDasSBYHi5AIkPEyrAWic0hYaJzGtbFSWGAz9Rpcw/asWHqo
	+uzbzX10wlrE+dm2eEj7tENItEGpadqCgd0lMj5CystsyyE59+mdYpMMFVPhU0r+e6Ffyn
	NKRkdJejoy6uAm3BnpZflXT2UCPvQKM=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1737359686;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=62CCysYlf1kTpBmg533SyW74Db9V4YMx6+JH5cKqFcA=;
	b=6cfO3rrQTWcPgKhBaNClVtc+LDctjRhzKgk3CpddogOxdYxc/bEclN3oJiG2Z+z22Okltj
	b5LuMPJO8sDPSMAg==
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1737359686; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=62CCysYlf1kTpBmg533SyW74Db9V4YMx6+JH5cKqFcA=;
	b=FRr113FrvNY+g8Scutf0XfwDasSBYHi5AIkPEyrAWic0hYaJzGtbFSWGAz9Rpcw/asWHqo
	+uzbzX10wlrE+dm2eEj7tENItEGpadqCgd0lMj5CystsyyE59+mdYpMMFVPhU0r+e6Ffyn
	NKRkdJejoy6uAm3BnpZflXT2UCPvQKM=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1737359686;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=62CCysYlf1kTpBmg533SyW74Db9V4YMx6+JH5cKqFcA=;
	b=6cfO3rrQTWcPgKhBaNClVtc+LDctjRhzKgk3CpddogOxdYxc/bEclN3oJiG2Z+z22Okltj
	b5LuMPJO8sDPSMAg==
Message-ID: <a8a37f7c-a60b-4644-9640-3fabc7257f9b@suse.de>
Date: Mon, 20 Jan 2025 08:54:45 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with
 drm_mode_size_dumb()
To: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>,
 maarten.lankhorst@linux.intel.com, mripard@kernel.org, airlied@gmail.com,
 simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org, linux-mediatek@lists.infradead.org,
 freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
 imx@lists.linux.dev, linux-samsung-soc@vger.kernel.org,
 nouveau@lists.freedesktop.org, virtualization@lists.linux.dev,
 spice-devel@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org,
 linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org,
 intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org,
 Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
 Andy Yan <andyshrk@163.com>, Daniel Stone <daniel@fooishbar.org>
References: <20250109150310.219442-1-tzimmermann@suse.de>
 <20250109150310.219442-26-tzimmermann@suse.de>
 <cdbe483d-0895-47aa-8c83-1c28220f4a02@ideasonboard.com>
 <bc97b92e-7f8a-4b92-af8a-20fa165ead55@suse.de>
 <f3ba05c7-6e49-4641-a3f9-ba418ebdb7c3@ideasonboard.com>
 <c6735280-7c32-4319-8ca9-a7305d8117c3@suse.de>
 <d67adb03-5cd0-4ac9-af58-cf4446dacee3@ideasonboard.com>
 <0ea6be58-0e04-4172-87cd-064a3e4a43bc@suse.de>
 <f35cb350-6be9-48ca-ad7e-e9dd418281d5@ideasonboard.com>
 <4af0b6a7-c16a-4187-bbf5-365a9c86de21@suse.de>
 <e327ad84-b5c9-4480-b873-dc3aca605538@ideasonboard.com>
 <a2bbeb47-2569-4ee0-9265-92bab139bdc6@suse.de>
 <f3833771-fcd7-45dc-9019-1525fef34429@ideasonboard.com>
Content-Language: en-US
From: Thomas Zimmermann <tzimmermann@suse.de>
Autocrypt: addr=tzimmermann@suse.de; keydata=
 xsBNBFs50uABCADEHPidWt974CaxBVbrIBwqcq/WURinJ3+2WlIrKWspiP83vfZKaXhFYsdg
 XH47fDVbPPj+d6tQrw5lPQCyqjwrCPYnq3WlIBnGPJ4/jreTL6V+qfKRDlGLWFjZcsrPJGE0
 BeB5BbqP5erN1qylK9i3gPoQjXGhpBpQYwRrEyQyjuvk+Ev0K1Jc5tVDeJAuau3TGNgah4Yc
 hdHm3bkPjz9EErV85RwvImQ1dptvx6s7xzwXTgGAsaYZsL8WCwDaTuqFa1d1jjlaxg6+tZsB
 9GluwvIhSezPgnEmimZDkGnZRRSFiGP8yjqTjjWuf0bSj5rUnTGiyLyRZRNGcXmu6hjlABEB
 AAHNJ1Rob21hcyBaaW1tZXJtYW5uIDx0emltbWVybWFubkBzdXNlLmRlPsLAjgQTAQgAOAIb
 AwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftODH
 AAoJEGgNwR1TC3ojx1wH/0hKGWugiqDgLNXLRD/4TfHBEKmxIrmfu9Z5t7vwUKfwhFL6hqvo
 lXPJJKQpQ2z8+X2vZm/slsLn7J1yjrOsoJhKABDi+3QWWSGkaGwRJAdPVVyJMfJRNNNIKwVb
 U6B1BkX2XDKDGffF4TxlOpSQzdtNI/9gleOoUA8+jy8knnDYzjBNOZqLG2FuTdicBXblz0Mf
 vg41gd9kCwYXDnD91rJU8tzylXv03E75NCaTxTM+FBXPmsAVYQ4GYhhgFt8S2UWMoaaABLDe
 7l5FdnLdDEcbmd8uLU2CaG4W2cLrUaI4jz2XbkcPQkqTQ3EB67hYkjiEE6Zy3ggOitiQGcqp
 j//OwE0EWznS4AEIAMYmP4M/V+T5RY5at/g7rUdNsLhWv1APYrh9RQefODYHrNRHUE9eosYb
 T6XMryR9hT8XlGOYRwKWwiQBoWSDiTMo/Xi29jUnn4BXfI2px2DTXwc22LKtLAgTRjP+qbU6
 3Y0xnQN29UGDbYgyyK51DW3H0If2a3JNsheAAK+Xc9baj0LGIc8T9uiEWHBnCH+RdhgATnWW
 GKdDegUR5BkDfDg5O/FISymJBHx2Dyoklv5g4BzkgqTqwmaYzsl8UxZKvbaxq0zbehDda8lv
 hFXodNFMAgTLJlLuDYOGLK2AwbrS3Sp0AEbkpdJBb44qVlGm5bApZouHeJ/+n+7r12+lqdsA
 EQEAAcLAdgQYAQgAIAIbDBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftOH6AAoJEGgNwR1T
 C3ojVSkIALpAPkIJPQoURPb1VWjh34l0HlglmYHvZszJWTXYwavHR8+k6Baa6H7ufXNQtThR
 yIxJrQLW6rV5lm7TjhffEhxVCn37+cg0zZ3j7zIsSS0rx/aMwi6VhFJA5hfn3T0TtrijKP4A
 SAQO9xD1Zk9/61JWk8OysuIh7MXkl0fxbRKWE93XeQBhIJHQfnc+YBLprdnxR446Sh8Wn/2D
 Ya8cavuWf2zrB6cZurs048xe0UbSW5AOSo4V9M0jzYI4nZqTmPxYyXbm30Kvmz0rYVRaitYJ
 4kyYYMhuULvrJDMjZRvaNe52tkKAvMevcGdt38H4KSVXAylqyQOW5zvPc4/sq9c=
In-Reply-To: <f3833771-fcd7-45dc-9019-1525fef34429@ideasonboard.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Level: 
X-Spamd-Result: default: False [-2.80 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	FREEMAIL_TO(0.00)[ideasonboard.com,linux.intel.com,kernel.org,gmail.com,ffwll.ch];
	RCPT_COUNT_TWELVE(0.00)[22];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_ALL(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	FREEMAIL_ENVRCPT(0.00)[163.com,gmail.com];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	FROM_HAS_DN(0.00)[];
	FREEMAIL_CC(0.00)[lists.freedesktop.org,lists.infradead.org,vger.kernel.org,lists.linux.dev,lists.xenproject.org,ideasonboard.com,163.com,fooishbar.org];
	TO_DN_SOME(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:mid]
X-Spam-Score: -2.80
X-Spam-Flag: NO

Hi


Am 16.01.25 um 11:03 schrieb Tomi Valkeinen:
[...]
>
> Harmonizing code is fine, but I think that can be done with a function 
> that only does the fallback-case.
>
> So... I can only speak for the platforms I'm using and maintaining, 
> but I'd rather keep the old behavior for CREATE_DUMB that we've had 
> for ages.

And we're not going to change that. I'll also include documentation of 
the intended behavior and semantics in the series' next update.

Whatever else is being discussed here, such as new ioctls, is a topic 
for a different series.

Best regards
Thomas

>
>  Tomi
>

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)



From xen-devel-bounces@lists.xenproject.org Mon Jan 20 08:29:27 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Jan 2025 08:29:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.874821.1285195 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZn9l-0008LW-9a; Mon, 20 Jan 2025 08:29:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 874821.1285195; Mon, 20 Jan 2025 08:29:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZn9l-0008LP-72; Mon, 20 Jan 2025 08:29:13 +0000
Received: by outflank-mailman (input) for mailman id 874821;
 Mon, 20 Jan 2025 08:29:12 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=FiXK=UM=amd.com=penny.zheng@srs-se1.protection.inumbo.net>)
 id 1tZn9k-0008LJ-Ba
 for xen-devel@lists.xenproject.org; Mon, 20 Jan 2025 08:29:12 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on2060d.outbound.protection.outlook.com
 [2a01:111:f403:2413::60d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9e726a76-d708-11ef-a0e3-8be0dac302b0;
 Mon, 20 Jan 2025 09:29:10 +0100 (CET)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 CH3PR12MB9023.namprd12.prod.outlook.com (2603:10b6:610:17b::12) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8356.20; Mon, 20 Jan
 2025 08:29:04 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%4]) with mapi id 15.20.8356.017; Mon, 20 Jan 2025
 08:29:04 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9e726a76-d708-11ef-a0e3-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=FVzf3dYVUcmju5InveuEvE+m9uouTi+bqQ9ih21Yh2JZ265da4jdql9ivD9I2JCVnXnQU2bxEuEVYevRYHvhTMN44ifwoZbfq80f8R8ws6GGd9plkKApAHe63gGO99P0tYipviPqjUopTrDjGOYL9bYirEAim7JjGAy2mOKD+PCww66tH3EJSpk8EgyKToISHRtq9n8ay7r59QBqK1Zoyl1J+FA37zh6Qxe2hheb5UN23CYuOld9YQR/B3YBXhbeWWA39ZH0v/aaNPPrkfKJSiMZQdONhfpAAyokHd1QMNveYiLdeu2UEK+QvY9P/7T8CJg4Tyr7/ft5ax7NRA/SeA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=9ynM/lfWoVXzwT4DZ6o9ktmrkPZFyJwLOwBQ8mbcao0=;
 b=Asf87K027yeGyXfly8jHRKkBOv0aKxfuBM42AGFKxVT3QK1aZYlCqt/TRkzQ+5f5c1PX8SchdfdKGRZUkrDdpKm4fhdRT8sy7McYlFXzkAxygms8GcPhkOPI36RJJKw1oCTKzm8c/RDkqqBUatP6um5OXbxhHJq0x6cDilYPDUALrbz7NkpCd8CGQc3VyxB2kQf63gJ6EQCpqmginXDckhEHK0m2VYXH/jAt0j2GtlHtWn6KaAhmFHGtowyLj5AcJXay9nYWQ/jzRXaxpefSpYVf0l4BDXyb5zCTt/7dnhi8koc54ta9VEg9wl1gFGanxg0Tuah1vWomz1IJMIInuA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=9ynM/lfWoVXzwT4DZ6o9ktmrkPZFyJwLOwBQ8mbcao0=;
 b=yK+oAiOwc/I6H0nzLpVSHsD9Ocomp0OgCjj0R0dER9YVXaaznDyml2baccssLIAf23Mt5wWE6uAxIAFCSDjrtqrGev9NI47t+rauV5P/mLZElJ8I04FD5bzRrowoIhhphmv55DWfslZ1nTWUIwpfyLlT6gZaQYu1g1kk/PJW/74=
From: "Penny, Zheng" <penny.zheng@amd.com>
To: Jan Beulich <jbeulich@suse.com>
CC: "Stabellini, Stefano" <stefano.stabellini@amd.com>, "Huang, Ray"
	<Ray.Huang@amd.com>, "Ragiadakou, Xenia" <Xenia.Ragiadakou@amd.com>,
	"Andryuk, Jason" <Jason.Andryuk@amd.com>, Andrew Cooper
	<andrew.cooper3@citrix.com>, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	<roger.pau@citrix.com>, Julien Grall <julien@xen.org>, Stefano Stabellini
	<sstabellini@kernel.org>, "xen-devel@lists.xenproject.org"
	<xen-devel@lists.xenproject.org>
Subject: RE: [PATCH v1 04/11] xen/x86: get processor max speed from DMI table
Thread-Topic: [PATCH v1 04/11] xen/x86: get processor max speed from DMI table
Thread-Index: AQHbRVyYUn8JDdimHUmiK3WJzTytZ7MOc1iAgBEaM5A=
Date: Mon, 20 Jan 2025 08:29:04 +0000
Message-ID:
 <DM4PR12MB84513955738017284726E260E1E72@DM4PR12MB8451.namprd12.prod.outlook.com>
References: <20241203081111.463400-1-Penny.Zheng@amd.com>
 <20241203081111.463400-5-Penny.Zheng@amd.com>
 <69360d8f-61e8-4bdc-b7e4-be67dbdd719b@suse.com>
In-Reply-To: <69360d8f-61e8-4bdc-b7e4-be67dbdd719b@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_ActionId=01dcd389-e04c-4bec-9154-66fe2076012f;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_ContentBits=0;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_Enabled=true;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_Method=Standard;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_Name=AMD
 Internal Distribution
 Only;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_SetDate=2025-01-20T07:22:59Z;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DM4PR12MB8451:EE_|CH3PR12MB9023:EE_
x-ms-office365-filtering-correlation-id: 94d2f463-5499-4315-1b84-08dd392c8039
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?MUtLUEFSQTZYWFh6YTgrQzlRUHhrUjZpSjd2TCsrWWl3S2FCZXFTcjQ2UVE5?=
 =?utf-8?B?TWJ1OW94NFRHZFRtOFFuenVxYWo4SURpakJOeXQzdXVIR1FVb1RYQUZRQVpu?=
 =?utf-8?B?aDQxUXlCUXlqT1N1b01oVzN1R2FDcDh0bk5TU09PUitBaWVDRnlkaHJmcGdL?=
 =?utf-8?B?bEJlb3hjVVNBM0pkY0tZU2Jqa1I3QkVnTFJsN3pXSm1ubDZTWWtZd3E5SGls?=
 =?utf-8?B?SFdWTkpnbUFCUkRyMzIvZzVlM3ljSzhISldZZHBvZnh3VzVKdzJBYWFxN3Az?=
 =?utf-8?B?WlFTcXNHWUFKbGpvNTZVS1E5K2dWUXJVNGtaRFZ3WGpSOEhQNGRrYTB5Mktx?=
 =?utf-8?B?QTU3a0k2dVRGWDhmeWlONklHOExkVnRFcnVFeDdCOCtLanBUd1NqenFrNk5q?=
 =?utf-8?B?K0JmM0F3b2Z5bTVrSEpnUHRZMHpIYlRaaWJzTG1CZUE2MjhSTHkxQ1lSR1Jp?=
 =?utf-8?B?dVpldlArTzJpaHk2VitPRlRXRTN3MzZtWWh0YTJDTFJqTkVUdUhuUENGS0xr?=
 =?utf-8?B?YXFib1JLbXR6TWdrQVRsR0xCZDhJNS9NdHMrWXBWaXIxWE1ycEdpZHFFMEs1?=
 =?utf-8?B?VDB3c3pzL0JGbXBIOVJTYlNWMzZmbjRnRTVhTHJQTHRkblZCNVlodWwzQ0o1?=
 =?utf-8?B?ZUJoMEp0SDJPUVhCSlUrMTZxZTRBaFpwN1VsZElQSlFHRjRMRGNZZzlFbVpp?=
 =?utf-8?B?M2VxMTNPaGdjN2hwbGZ3ekZyR0xOOVlFNEM3eVVIMnd4M285ajZxU0tIZHJC?=
 =?utf-8?B?NEdwV1dTdjQ1c0hxOE1KdnMzYTBoLzFrYUF1SWZRVGxLajlxMVJjMDhETVQ3?=
 =?utf-8?B?dHFpR0srTS8vNFV4MFFhN2h1ZTJEeGROOFcyUkFCSU55OHRhOEY5blFFT1Ni?=
 =?utf-8?B?KzhRczYzenJSOERRdzk3N0t2RkJSakNtbUVNSnRtQThXVkxkYTZjOEgyZmFD?=
 =?utf-8?B?U1FOYzRPNmkxTHlkZUx6dTVkR0NuaWVsMGY0RnN3aDV3TTRycFZtSm1oNWxY?=
 =?utf-8?B?cG0rbGhNdW84SzFrSm5GY0xjNGliTkZPdlNrdmg1ZGhBbit6VnI4TG1kNHcy?=
 =?utf-8?B?Q2xob0ovVjBDdUhORnBqM0dhRGxESm1NNGEvc1l6KzR0SjBmTGJkU2lBNll2?=
 =?utf-8?B?SXJReERxWDY2eUxPYnc4cDhtN1l4aUQ0cmdTR1E0VEJuYnR0Wkx0eW5MUnZJ?=
 =?utf-8?B?Z1JxTFQ5UnZWQmJ2YUtVblhKUmhadGtNZUJmMVNyRkZPOGtJYUZGazJRQ205?=
 =?utf-8?B?eU90ZVduN1ZVelZYRXNmdTMwS0J4OGFycG1IL0RBM3dzTmJjaFZFSHdKdEhX?=
 =?utf-8?B?ZmJYeVlxZkluU1VMd1Yxcit6QkhSQ1NBdnhlNGU1SkVzSTNWcU1GQWIxR3Rl?=
 =?utf-8?B?WVNteFQwdHU2aUI5d0t4REJhUnYyZW52d01jWHYzbEk3enozbTJkRTg0Nlgy?=
 =?utf-8?B?Ym1SVGNVQkkwM3V3M2tyTzFOaFBoNmJ3NmhYbFVWekkwWExQQ3p1YTVyeUZD?=
 =?utf-8?B?WTdseGhxaE5lSENJOFlNOXVQQVV2d2xUSEhsaDRtOUJkOHJIVFM5N2pqNUEr?=
 =?utf-8?B?dEVDOStEWWdrYkdGR1duRndMUkFaU0hScUtYZ1NzcnpTY3d0bUIwSjZ0NUZU?=
 =?utf-8?B?NlRqL0c2UU55WUw0aFk3U2hKZ3dHT0RlWnd4cU1IdE9FNzNURHJYRStTVlh3?=
 =?utf-8?B?dGhqQ3FvRzhnZjdVNFlpbkVCdE1mN1dUSlhKMVdQTmZRNHBhamxSUGl3b29s?=
 =?utf-8?B?VlRYWXd2cmJEQWl2YmRWZCsvaGZOcEhqbzJzWmxmMCtOSzFmMGI4My9IbUt3?=
 =?utf-8?B?YklSckx6Q3NjWlpIeWNMeHZNTmRjTHU2ME1kbzBjaEtUNDVSL2ZjRG9OM0pC?=
 =?utf-8?B?WGRweTcrcUdzT2grOU1Gbjd5WTV6NmhoUHNHL1lvMGdQdGtJTHlXMm93YUM0?=
 =?utf-8?Q?U3CZuavUEwS0w1mf6sIPoA7+XHBbzo8L?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB8451.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?cmk4bGpqUGt3QUYva1dONVRtSDU3WW1kWmpveERmTncvc1V1cjdEMVRFekt6?=
 =?utf-8?B?dEk2elVROUM4cFNlZ2E4OURGMWtCL2NtL09tMUlPZnlqYXZKZjZRYUk5NEs1?=
 =?utf-8?B?UXBhNU1jc0xiWXk1empiUStleVRKOFlCQ0Y4VUNkaHNUY09nTDYwQkFhbjdI?=
 =?utf-8?B?bEY3VzdtdkhjVE5Fd0lYUGlXWnpOdnYxZ0lEd2FiT3czOHMwRi9DMXlhaDlp?=
 =?utf-8?B?d1E3VVNqRko3Q3lQZWorQ0s1WmJDSmVTT1dJV1VuNGpRYmF1Zk1xcG9NN2ht?=
 =?utf-8?B?d2tmQzlCUHBYdUw4eTNsQlZBKys5aDFYVzh0YWR6SUN3WU9kTy9aWkpaT3pS?=
 =?utf-8?B?MnJqUHhBakFCM3N5c204YXlrVVFxQ3FYTTluaFVjRjQ0ZVFYODFiVlhVWHBo?=
 =?utf-8?B?RHlFUkgwZnhKZU5WOGozRlpUTU1mdUJrQlhqay9LdEpPUDNnTkZWblV2L0I0?=
 =?utf-8?B?N3lyR1EwT0Roc2gyZzMyaFdQVGJtRDdlamd1Qm9IZGtNbUM3RmdrS2xLdERX?=
 =?utf-8?B?eURrQVhxUGIyeHo3NDFSVW0zS291QmwwaTRJdU9FUlhtS1htMUxGNTFnRi9k?=
 =?utf-8?B?Y21QeEg4RFRJTVFoZmhqQThTVFA4QXdXa0liZmRTa09qZlBRMGZTajRDNmlw?=
 =?utf-8?B?ZjRsZjl1a0NXbkwzSGNvREhpTkM0aVdRK25NdGVVbmJIRElINWZPdzltZU0x?=
 =?utf-8?B?NXowMEcxM1BvRDJzQzZZbkMvZVMwNjNwVktPOTJSNFpheWJOdGg2TFVNVXlX?=
 =?utf-8?B?d1RRQVlkdWVvMFN3QWJ2eXZyV2N6cllqSVA5YUQ2TDJVSVVMMmtZNUhrVFhm?=
 =?utf-8?B?YnpyU2ZkajlOamN6d2IzMU5Sa1ZLb0dxNC9YcGFveEFLYkgwc2t1ODhrSFo0?=
 =?utf-8?B?Zms4aEsxYW05ekZJTVJ5NXU0VGdjdXdMSTJCc2pOVkV2MnRuUnZMWVQwOUxU?=
 =?utf-8?B?MzVHSUFVRVRFWVd2NkFhdXltaW9Qc3NhUUVNNDUrZzlmVDhUTFlVNDhYaFdX?=
 =?utf-8?B?WkZmQkdRbjlDdFhJVG1Lb2hwd3JmSnJkYjZEUTRJSDdIaGN6aEVsdlFkOExP?=
 =?utf-8?B?TzI0MnRCczBvejBzQWZhR3VvbGMvNkl4WHllZForNXI0ZENDSHVwOEhuaEM1?=
 =?utf-8?B?ZEJWUlBtTlB1eVNxd2tkVGwzQzlwZDA3K0VVVWhqN2l4OE9hM29XWjlKV3BC?=
 =?utf-8?B?bzBoVEorZ1l2TkRzcS9ZTGtXSVRSM0h0RUlkdTlJRGljQkZXcW1EQkR5WSsy?=
 =?utf-8?B?cGRYTmIyUGVib0JWMUNEZHVVaGY3eVpBK0xrUTl3aE5lMUltcHFmV01mQkwr?=
 =?utf-8?B?NnVGNS9vU0k0TWxWRSsrK1JjR1h4RStGSDEyY2E5M1RwdHpRM2FWb09YY0pl?=
 =?utf-8?B?V0FLSHEvcldCSytZSkNGRkJQOXlpNytPeXRhWFprSTFCdHdDcVdORkVFYm5N?=
 =?utf-8?B?dzZGYWRuM1RjaHUvTVhXR2xMUHZTaGxiR3crNlVsSDduek05WTEwVVZvYkNi?=
 =?utf-8?B?NmpUMStqOExiems5cnpyZlN0ajIyNjFOR09zRlJML3hncXF4eUd5RnNMSGNh?=
 =?utf-8?B?ejREblRIUEc1cEJyTklreG1ZWGsxYk5xaWhlQzZWbVprUlpIajA3eE1HTHhB?=
 =?utf-8?B?WHkrc1RaS1BodUp3c0IxOHFpSVhYQUJrQ1AwM1VQQ3ZLN1N3Vi9saFRrQ0tR?=
 =?utf-8?B?Rk9KcjNzSmpuRDE5Ri9hS2FNUmRDbXk4WlRxbzBHLzU4TlpyTllpeEt2YjBl?=
 =?utf-8?B?eWc0ZnZjMVUzM3JpeU1CTUJnK3NNdEp3b0UwMWliaVZYUW5EamhDRzYvbWRN?=
 =?utf-8?B?ZXNNSnlycGtTdExJVTJYQWdHVDNDTHdhUXZLb25oblBEWkdKWWNjSTNWVytI?=
 =?utf-8?B?VGFXMHFlN1BJYUNHc1dmNkYwdlcvbUtTUTZhdTcrZzBtNENqTWgyMEhqcmRi?=
 =?utf-8?B?YkFTYUJrRGMyaHlYSEdLaHRWWXhpeDBURjRkcklHbW12ekp5YTAyNjJ5dE5v?=
 =?utf-8?B?V0NpbDZreXZ6d0ZhSHNBMUN0d28zaElUK2tTbDRXTjZhRy90c00wRVQzTTNr?=
 =?utf-8?B?dXpkV0R2TTZMbHdsZFViZVFiOGFiSzdtRHBnM1ZCTGUwTVJjNUZQR2xDbFZm?=
 =?utf-8?Q?qKu8=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB8451.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 94d2f463-5499-4315-1b84-08dd392c8039
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jan 2025 08:29:04.8575
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: /BWYKPTVfRS6BnB6lG0nHEYt2P+VGDas4HUnbbmQrpiQDr4JnOf7nO80JzpRY0x/tNmkwc7LDCsssvLjeLHxHg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB9023

W0FNRCBPZmZpY2lhbCBVc2UgT25seSAtIEFNRCBJbnRlcm5hbCBEaXN0cmlidXRpb24gT25seV0N
Cg0KSGksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSmFuIEJldWxp
Y2ggPGpiZXVsaWNoQHN1c2UuY29tPg0KPiBTZW50OiBUaHVyc2RheSwgSmFudWFyeSA5LCAyMDI1
IDY6MTMgUE0NCj4gVG86IFBlbm55LCBaaGVuZyA8cGVubnkuemhlbmdAYW1kLmNvbT4NCj4gQ2M6
IFN0YWJlbGxpbmksIFN0ZWZhbm8gPHN0ZWZhbm8uc3RhYmVsbGluaUBhbWQuY29tPjsgSHVhbmcs
IFJheQ0KPiA8UmF5Lkh1YW5nQGFtZC5jb20+OyBSYWdpYWRha291LCBYZW5pYSA8WGVuaWEuUmFn
aWFkYWtvdUBhbWQuY29tPjsNCj4gQW5kcnl1aywgSmFzb24gPEphc29uLkFuZHJ5dWtAYW1kLmNv
bT47IEFuZHJldyBDb29wZXINCj4gPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+OyBSb2dlciBQ
YXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT47DQo+IEp1bGllbiBHcmFsbCA8anVsaWVu
QHhlbi5vcmc+OyBTdGVmYW5vIFN0YWJlbGxpbmkgPHNzdGFiZWxsaW5pQGtlcm5lbC5vcmc+OyB4
ZW4tDQo+IGRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0gg
djEgMDQvMTFdIHhlbi94ODY6IGdldCBwcm9jZXNzb3IgbWF4IHNwZWVkIGZyb20gRE1JIHRhYmxl
DQo+DQo+IE9uIDAzLjEyLjIwMjQgMDk6MTEsIFBlbm55IFpoZW5nIHdyb3RlOg0KPiA+IFdoZW4g
X0NQQyB0YWJsZSBjb3VsZCBub3QgcHJvdmlkZSBwcm9jZXNzb3IgZnJlcXVlbmN5IHJhbmdlIHZh
bHVlcyBmb3INCj4gPiBPUyBnb3Zlcm5vciwgd2UgbmVlZCB0byByZWFkIHByb2Nlc3NvciBtYXgg
ZnJlcXVlbmN5IGFzIGFuY2hvciBwb2ludC4NCj4gPg0KPiA+IEZvciBBTUQgcHJvY2Vzc29ycywg
d2UgcmVseSBvbiBwYXJzaW5nIERNSSB0YWJsZSB0byBnZXQgcHJvY2Vzc29yIG1heA0KPiA+IHNw
ZWVkLg0KPg0KPiBUaGF0IHNvdW5kcyBlbnRpcmVseSBmcmFnaWxlLiBUaGVyZSBhcmUgYmV0dGVy
IHNvdXJjZXMgZm9yIHRoaXMgaW5mbywgYXJlbid0IHRoZXJlPw0KPiBTZWUgZS5nLiBhbWRfbG9n
X2ZyZXEoKS4NCj4NCg0KVGhhbmtzIGZvciB0aGUgcmVmZXIuIFRoZW4gSSBtYXkgaW50cm9kdWNl
IGEgbmV3IHBlci1jcHUgdmFsdWUgdG8gZXhwb3J0IG1heCBmcmVxdWVuY3kNCmZyb20gYW1kX2xv
Z19mcmVxKCkuDQoNCj4gSmFuDQoNCk1hbnkgdGhhbmtzLA0KUGVubnkNCg0K


From xen-devel-bounces@lists.xenproject.org Mon Jan 20 08:51:36 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Jan 2025 08:51:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.874839.1285206 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZnVK-000487-Vt; Mon, 20 Jan 2025 08:51:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 874839.1285206; Mon, 20 Jan 2025 08:51:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZnVK-000480-Ss; Mon, 20 Jan 2025 08:51:30 +0000
Received: by outflank-mailman (input) for mailman id 874839;
 Mon, 20 Jan 2025 08:51:30 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=2DPH=UM=ideasonboard.com=tomi.valkeinen@srs-se1.protection.inumbo.net>)
 id 1tZnVK-00047t-7q
 for xen-devel@lists.xenproject.org; Mon, 20 Jan 2025 08:51:30 +0000
Received: from perceval.ideasonboard.com (perceval.ideasonboard.com
 [213.167.242.64]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b8f32a0a-d70b-11ef-99a4-01e77a169b0f;
 Mon, 20 Jan 2025 09:51:22 +0100 (CET)
Received: from [192.168.88.20] (91-158-153-178.elisa-laajakaista.fi
 [91.158.153.178])
 by perceval.ideasonboard.com (Postfix) with ESMTPSA id 9AED3735;
 Mon, 20 Jan 2025 09:50:24 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b8f32a0a-d70b-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;
	s=mail; t=1737363025;
	bh=XGVXA8RFEid3r1QRColBlQttrSeJN5LcMuwzsp8evGE=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=ORoPGZ873bLFpXc4xj0ZeN/6Lx5dqB9w0e97Rm1RwzB6B3smvYvJOGaAS4AdO2FdK
	 uv1FmShTizPOz7DlEX13/kmFLevZy83ajoSYNtGKPOSQRWTZfN0EY8Cf3sW8dOQTLV
	 iLeaw24LF8z2yQ15B8wAEXOEhqialqWrnRg2dKzA=
Message-ID: <469daa7f-123b-41cb-a99c-4441436d82dc@ideasonboard.com>
Date: Mon, 20 Jan 2025 10:51:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with
 drm_mode_size_dumb()
To: Thomas Zimmermann <tzimmermann@suse.de>,
 maarten.lankhorst@linux.intel.com, mripard@kernel.org, airlied@gmail.com,
 simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org, linux-mediatek@lists.infradead.org,
 freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
 imx@lists.linux.dev, linux-samsung-soc@vger.kernel.org,
 nouveau@lists.freedesktop.org, virtualization@lists.linux.dev,
 spice-devel@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org,
 linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org,
 intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org,
 Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
 Andy Yan <andyshrk@163.com>, Daniel Stone <daniel@fooishbar.org>
References: <20250109150310.219442-1-tzimmermann@suse.de>
 <20250109150310.219442-26-tzimmermann@suse.de>
 <cdbe483d-0895-47aa-8c83-1c28220f4a02@ideasonboard.com>
 <bc97b92e-7f8a-4b92-af8a-20fa165ead55@suse.de>
 <f3ba05c7-6e49-4641-a3f9-ba418ebdb7c3@ideasonboard.com>
 <c6735280-7c32-4319-8ca9-a7305d8117c3@suse.de>
 <d67adb03-5cd0-4ac9-af58-cf4446dacee3@ideasonboard.com>
 <0ea6be58-0e04-4172-87cd-064a3e4a43bc@suse.de>
 <f35cb350-6be9-48ca-ad7e-e9dd418281d5@ideasonboard.com>
 <4af0b6a7-c16a-4187-bbf5-365a9c86de21@suse.de>
 <e327ad84-b5c9-4480-b873-dc3aca605538@ideasonboard.com>
 <a2bbeb47-2569-4ee0-9265-92bab139bdc6@suse.de>
 <f3833771-fcd7-45dc-9019-1525fef34429@ideasonboard.com>
 <156804a9-3095-4c93-888f-d9041f523da6@suse.de>
Content-Language: en-US
From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Autocrypt: addr=tomi.valkeinen@ideasonboard.com; keydata=
 xsFNBE6ms0cBEACyizowecZqXfMZtnBniOieTuFdErHAUyxVgtmr0f5ZfIi9Z4l+uUN4Zdw2
 wCEZjx3o0Z34diXBaMRJ3rAk9yB90UJAnLtb8A97Oq64DskLF81GCYB2P1i0qrG7UjpASgCA
 Ru0lVvxsWyIwSfoYoLrazbT1wkWRs8YBkkXQFfL7Mn3ZMoGPcpfwYH9O7bV1NslbmyJzRCMO
 eYV258gjCcwYlrkyIratlHCek4GrwV8Z9NQcjD5iLzrONjfafrWPwj6yn2RlL0mQEwt1lOvn
 LnI7QRtB3zxA3yB+FLsT1hx0va6xCHpX3QO2gBsyHCyVafFMrg3c/7IIWkDLngJxFgz6DLiA
 G4ld1QK/jsYqfP2GIMH1mFdjY+iagG4DqOsjip479HCWAptpNxSOCL6z3qxCU8MCz8iNOtZk
 DYXQWVscM5qgYSn+fmMM2qN+eoWlnCGVURZZLDjg387S2E1jT/dNTOsM/IqQj+ZROUZuRcF7
 0RTtuU5q1HnbRNwy+23xeoSGuwmLQ2UsUk7Q5CnrjYfiPo3wHze8avK95JBoSd+WIRmV3uoO
 rXCoYOIRlDhg9XJTrbnQ3Ot5zOa0Y9c4IpyAlut6mDtxtKXr4+8OzjSVFww7tIwadTK3wDQv
 Bus4jxHjS6dz1g2ypT65qnHen6mUUH63lhzewqO9peAHJ0SLrQARAQABzTBUb21pIFZhbGtl
 aW5lbiA8dG9taS52YWxrZWluZW5AaWRlYXNvbmJvYXJkLmNvbT7CwY4EEwEIADgWIQTEOAw+
 ll79gQef86f6PaqMvJYe9QUCX/HruAIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRD6
 PaqMvJYe9WmFD/99NGoD5lBJhlFDHMZvO+Op8vCwnIRZdTsyrtGl72rVh9xRfcSgYPZUvBuT
 VDxE53mY9HaZyu1eGMccYRBaTLJSfCXl/g317CrMNdY0k40b9YeIX10feiRYEWoDIPQ3tMmA
 0nHDygzcnuPiPT68JYZ6tUOvAt7r6OX/litM+m2/E9mtp8xCoWOo/kYO4mOAIoMNvLB8vufi
 uBB4e/AvAjtny4ScuNV5c5q8MkfNIiOyag9QCiQ/JfoAqzXRjVb4VZG72AKaElwipiKCWEcU
 R4+Bu5Qbaxj7Cd36M/bI54OrbWWETJkVVSV1i0tghCd6HHyquTdFl7wYcz6cL1hn/6byVnD+
 sR3BLvSBHYp8WSwv0TCuf6tLiNgHAO1hWiQ1pOoXyMEsxZlgPXT+wb4dbNVunckwqFjGxRbl
 Rz7apFT/ZRwbazEzEzNyrBOfB55xdipG/2+SmFn0oMFqFOBEszXLQVslh64lI0CMJm2OYYe3
 PxHqYaztyeXsx13Bfnq9+bUynAQ4uW1P5DJ3OIRZWKmbQd/Me3Fq6TU57LsvwRgE0Le9PFQs
 dcP2071rMTpqTUteEgODJS4VDf4lXJfY91u32BJkiqM7/62Cqatcz5UWWHq5xeF03MIUTqdE
 qHWk3RJEoWHWQRzQfcx6Fn2fDAUKhAddvoopfcjAHfpAWJ+ENc7BTQROprNHARAAx0aat8GU
 hsusCLc4MIxOQwidecCTRc9Dz/7U2goUwhw2O5j9TPqLtp57VITmHILnvZf6q3QAho2QMQyE
 DDvHubrdtEoqaaSKxKkFie1uhWNNvXPhwkKLYieyL9m2JdU+b88HaDnpzdyTTR4uH7wk0bBa
 KbTSgIFDDe5lXInypewPO30TmYNkFSexnnM3n1PBCqiJXsJahE4ZQ+WnV5FbPUj8T2zXS2xk
 0LZ0+DwKmZ0ZDovvdEWRWrz3UzJ8DLHb7blPpGhmqj3ANXQXC7mb9qJ6J/VSl61GbxIO2Dwb
 xPNkHk8fwnxlUBCOyBti/uD2uSTgKHNdabhVm2dgFNVuS1y3bBHbI/qjC3J7rWE0WiaHWEqy
 UVPk8rsph4rqITsj2RiY70vEW0SKePrChvET7D8P1UPqmveBNNtSS7In+DdZ5kUqLV7rJnM9
 /4cwy+uZUt8cuCZlcA5u8IsBCNJudxEqBG10GHg1B6h1RZIz9Q9XfiBdaqa5+CjyFs8ua01c
 9HmyfkuhXG2OLjfQuK+Ygd56mV3lq0aFdwbaX16DG22c6flkkBSjyWXYepFtHz9KsBS0DaZb
 4IkLmZwEXpZcIOQjQ71fqlpiXkXSIaQ6YMEs8WjBbpP81h7QxWIfWtp+VnwNGc6nq5IQDESH
 mvQcsFS7d3eGVI6eyjCFdcAO8eMAEQEAAcLBXwQYAQIACQUCTqazRwIbDAAKCRD6PaqMvJYe
 9fA7EACS6exUedsBKmt4pT7nqXBcRsqm6YzT6DeCM8PWMTeaVGHiR4TnNFiT3otD5UpYQI7S
 suYxoTdHrrrBzdlKe5rUWpzoZkVK6p0s9OIvGzLT0lrb0HC9iNDWT3JgpYDnk4Z2mFi6tTbq
 xKMtpVFRA6FjviGDRsfkfoURZI51nf2RSAk/A8BEDDZ7lgJHskYoklSpwyrXhkp9FHGMaYII
 m9EKuUTX9JPDG2FTthCBrdsgWYPdJQvM+zscq09vFMQ9Fykbx5N8z/oFEUy3ACyPqW2oyfvU
 CH5WDpWBG0s5BALp1gBJPytIAd/pY/5ZdNoi0Cx3+Z7jaBFEyYJdWy1hGddpkgnMjyOfLI7B
 CFrdecTZbR5upjNSDvQ7RG85SnpYJTIin+SAUazAeA2nS6gTZzumgtdw8XmVXZwdBfF+ICof
 92UkbYcYNbzWO/GHgsNT1WnM4sa9lwCSWH8Fw1o/3bX1VVPEsnESOfxkNdu+gAF5S6+I6n3a
 ueeIlwJl5CpT5l8RpoZXEOVtXYn8zzOJ7oGZYINRV9Pf8qKGLf3Dft7zKBP832I3PQjeok7F
 yjt+9S+KgSFSHP3Pa4E7lsSdWhSlHYNdG/czhoUkSCN09C0rEK93wxACx3vtxPLjXu6RptBw
 3dRq7n+mQChEB1am0BueV1JZaBboIL0AGlSJkm23kw==
In-Reply-To: <156804a9-3095-4c93-888f-d9041f523da6@suse.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

On 20/01/2025 09:49, Thomas Zimmermann wrote:
> Hi
> 
> 
> Am 16.01.25 um 11:03 schrieb Tomi Valkeinen:
> [...]
>> Aligning video= and dumb buffers almost sounds like going backwards. 
>> video= parameter is bad,
> 
> Who told you that? Video= is still the way to specify an initial display 
> mode to the kernel and it will remain so.

You did =). "It aligns dumb buffers and video=". I understand the need 
for drm_driver_color_mode_format() for video=. But I think it's bad for 
CREATE_DUMB, at least for the platforms which have never aimed for 
"RGB-only".

So you're not in favor of a drm_mode_size_dumb() version that does not 
use drm_driver_color_mode_format(), for these platforms? I'm still at 
loss as to why we would want to change the behavior of CREATE_DUMB. I 
see no upside, but I see the chance of regressions.

  Tomi



From xen-devel-bounces@lists.xenproject.org Mon Jan 20 08:57:45 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Jan 2025 08:57:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.874850.1285216 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZnbJ-0004np-NT; Mon, 20 Jan 2025 08:57:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 874850.1285216; Mon, 20 Jan 2025 08:57:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZnbJ-0004ni-K2; Mon, 20 Jan 2025 08:57:41 +0000
Received: by outflank-mailman (input) for mailman id 874850;
 Mon, 20 Jan 2025 08:57: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
 <SRS0=D7kk=UM=suse.de=tzimmermann@srs-se1.protection.inumbo.net>)
 id 1tZnbI-0004na-Cg
 for xen-devel@lists.xenproject.org; Mon, 20 Jan 2025 08:57:40 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 99a434b9-d70c-11ef-a0e3-8be0dac302b0;
 Mon, 20 Jan 2025 09:57:39 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id 45D501F7A5;
 Mon, 20 Jan 2025 08:57:38 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id B6E2E139CB;
 Mon, 20 Jan 2025 08:57:37 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id GIpkKwEQjmc1bAAAD6G6ig
 (envelope-from <tzimmermann@suse.de>); Mon, 20 Jan 2025 08:57:37 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 99a434b9-d70c-11ef-a0e3-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1737363458; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=UxuzgDcZRRA2/FviISYwEq2AIPpj8Irf9o88aWv1Nug=;
	b=kW3Pr8f901Z7ow0UHFahd4SLynjHr1wROdXiToHoUzdZtS0UDlBfei6zyIhlrIvzjk3tTp
	1yl9BBLd/wW4AIbYNxR4/K1qnpxSQzwOXdAtcjJfXqEvwzk6HOTU7pxJDjvQKvk3vSEC+G
	+gkt4/bJ2a6edrgg2+jIR/ApD6tqgY4=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1737363458;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=UxuzgDcZRRA2/FviISYwEq2AIPpj8Irf9o88aWv1Nug=;
	b=VlO1OePapx4jPwQ9JJ2gQmbCi/5qM66D0h4jEtVFfdhS3PQIpAi47mvrbt89crlhSXbRc0
	E8Wy/g/yidV+kRBQ==
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.de header.s=susede2_rsa header.b=kW3Pr8f9;
	dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=VlO1OePa
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1737363458; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=UxuzgDcZRRA2/FviISYwEq2AIPpj8Irf9o88aWv1Nug=;
	b=kW3Pr8f901Z7ow0UHFahd4SLynjHr1wROdXiToHoUzdZtS0UDlBfei6zyIhlrIvzjk3tTp
	1yl9BBLd/wW4AIbYNxR4/K1qnpxSQzwOXdAtcjJfXqEvwzk6HOTU7pxJDjvQKvk3vSEC+G
	+gkt4/bJ2a6edrgg2+jIR/ApD6tqgY4=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1737363458;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=UxuzgDcZRRA2/FviISYwEq2AIPpj8Irf9o88aWv1Nug=;
	b=VlO1OePapx4jPwQ9JJ2gQmbCi/5qM66D0h4jEtVFfdhS3PQIpAi47mvrbt89crlhSXbRc0
	E8Wy/g/yidV+kRBQ==
Message-ID: <dce0191b-8df0-4239-bdee-08a34c4b28d2@suse.de>
Date: Mon, 20 Jan 2025 09:57:37 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with
 drm_mode_size_dumb()
To: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>,
 maarten.lankhorst@linux.intel.com, mripard@kernel.org, airlied@gmail.com,
 simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org, linux-mediatek@lists.infradead.org,
 freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
 imx@lists.linux.dev, linux-samsung-soc@vger.kernel.org,
 nouveau@lists.freedesktop.org, virtualization@lists.linux.dev,
 spice-devel@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org,
 linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org,
 intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org,
 Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
 Andy Yan <andyshrk@163.com>, Daniel Stone <daniel@fooishbar.org>
References: <20250109150310.219442-1-tzimmermann@suse.de>
 <20250109150310.219442-26-tzimmermann@suse.de>
 <cdbe483d-0895-47aa-8c83-1c28220f4a02@ideasonboard.com>
 <bc97b92e-7f8a-4b92-af8a-20fa165ead55@suse.de>
 <f3ba05c7-6e49-4641-a3f9-ba418ebdb7c3@ideasonboard.com>
 <c6735280-7c32-4319-8ca9-a7305d8117c3@suse.de>
 <d67adb03-5cd0-4ac9-af58-cf4446dacee3@ideasonboard.com>
 <0ea6be58-0e04-4172-87cd-064a3e4a43bc@suse.de>
 <f35cb350-6be9-48ca-ad7e-e9dd418281d5@ideasonboard.com>
 <4af0b6a7-c16a-4187-bbf5-365a9c86de21@suse.de>
 <e327ad84-b5c9-4480-b873-dc3aca605538@ideasonboard.com>
 <a2bbeb47-2569-4ee0-9265-92bab139bdc6@suse.de>
 <f3833771-fcd7-45dc-9019-1525fef34429@ideasonboard.com>
 <156804a9-3095-4c93-888f-d9041f523da6@suse.de>
 <469daa7f-123b-41cb-a99c-4441436d82dc@ideasonboard.com>
Content-Language: en-US
From: Thomas Zimmermann <tzimmermann@suse.de>
Autocrypt: addr=tzimmermann@suse.de; keydata=
 xsBNBFs50uABCADEHPidWt974CaxBVbrIBwqcq/WURinJ3+2WlIrKWspiP83vfZKaXhFYsdg
 XH47fDVbPPj+d6tQrw5lPQCyqjwrCPYnq3WlIBnGPJ4/jreTL6V+qfKRDlGLWFjZcsrPJGE0
 BeB5BbqP5erN1qylK9i3gPoQjXGhpBpQYwRrEyQyjuvk+Ev0K1Jc5tVDeJAuau3TGNgah4Yc
 hdHm3bkPjz9EErV85RwvImQ1dptvx6s7xzwXTgGAsaYZsL8WCwDaTuqFa1d1jjlaxg6+tZsB
 9GluwvIhSezPgnEmimZDkGnZRRSFiGP8yjqTjjWuf0bSj5rUnTGiyLyRZRNGcXmu6hjlABEB
 AAHNJ1Rob21hcyBaaW1tZXJtYW5uIDx0emltbWVybWFubkBzdXNlLmRlPsLAjgQTAQgAOAIb
 AwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftODH
 AAoJEGgNwR1TC3ojx1wH/0hKGWugiqDgLNXLRD/4TfHBEKmxIrmfu9Z5t7vwUKfwhFL6hqvo
 lXPJJKQpQ2z8+X2vZm/slsLn7J1yjrOsoJhKABDi+3QWWSGkaGwRJAdPVVyJMfJRNNNIKwVb
 U6B1BkX2XDKDGffF4TxlOpSQzdtNI/9gleOoUA8+jy8knnDYzjBNOZqLG2FuTdicBXblz0Mf
 vg41gd9kCwYXDnD91rJU8tzylXv03E75NCaTxTM+FBXPmsAVYQ4GYhhgFt8S2UWMoaaABLDe
 7l5FdnLdDEcbmd8uLU2CaG4W2cLrUaI4jz2XbkcPQkqTQ3EB67hYkjiEE6Zy3ggOitiQGcqp
 j//OwE0EWznS4AEIAMYmP4M/V+T5RY5at/g7rUdNsLhWv1APYrh9RQefODYHrNRHUE9eosYb
 T6XMryR9hT8XlGOYRwKWwiQBoWSDiTMo/Xi29jUnn4BXfI2px2DTXwc22LKtLAgTRjP+qbU6
 3Y0xnQN29UGDbYgyyK51DW3H0If2a3JNsheAAK+Xc9baj0LGIc8T9uiEWHBnCH+RdhgATnWW
 GKdDegUR5BkDfDg5O/FISymJBHx2Dyoklv5g4BzkgqTqwmaYzsl8UxZKvbaxq0zbehDda8lv
 hFXodNFMAgTLJlLuDYOGLK2AwbrS3Sp0AEbkpdJBb44qVlGm5bApZouHeJ/+n+7r12+lqdsA
 EQEAAcLAdgQYAQgAIAIbDBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftOH6AAoJEGgNwR1T
 C3ojVSkIALpAPkIJPQoURPb1VWjh34l0HlglmYHvZszJWTXYwavHR8+k6Baa6H7ufXNQtThR
 yIxJrQLW6rV5lm7TjhffEhxVCn37+cg0zZ3j7zIsSS0rx/aMwi6VhFJA5hfn3T0TtrijKP4A
 SAQO9xD1Zk9/61JWk8OysuIh7MXkl0fxbRKWE93XeQBhIJHQfnc+YBLprdnxR446Sh8Wn/2D
 Ya8cavuWf2zrB6cZurs048xe0UbSW5AOSo4V9M0jzYI4nZqTmPxYyXbm30Kvmz0rYVRaitYJ
 4kyYYMhuULvrJDMjZRvaNe52tkKAvMevcGdt38H4KSVXAylqyQOW5zvPc4/sq9c=
In-Reply-To: <469daa7f-123b-41cb-a99c-4441436d82dc@ideasonboard.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 45D501F7A5
X-Spam-Level: 
X-Spamd-Result: default: False [-3.01 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_DKIM_ALLOW(-0.20)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	FREEMAIL_ENVRCPT(0.00)[163.com,gmail.com];
	RCVD_TLS_ALL(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[22];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_TO(0.00)[ideasonboard.com,linux.intel.com,kernel.org,gmail.com,ffwll.ch];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	FROM_HAS_DN(0.00)[];
	FREEMAIL_CC(0.00)[lists.freedesktop.org,lists.infradead.org,vger.kernel.org,lists.linux.dev,lists.xenproject.org,ideasonboard.com,163.com,fooishbar.org];
	TO_DN_SOME(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:dkim,suse.de:mid,imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns];
	RCVD_COUNT_TWO(0.00)[2];
	DKIM_TRACE(0.00)[suse.de:+]
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Rspamd-Action: no action
X-Spam-Score: -3.01
X-Spam-Flag: NO

Hi


Am 20.01.25 um 09:51 schrieb Tomi Valkeinen:
> Hi,
>
> On 20/01/2025 09:49, Thomas Zimmermann wrote:
>> Hi
>>
>>
>> Am 16.01.25 um 11:03 schrieb Tomi Valkeinen:
>> [...]
>>> Aligning video= and dumb buffers almost sounds like going backwards. 
>>> video= parameter is bad,
>>
>> Who told you that? Video= is still the way to specify an initial 
>> display mode to the kernel and it will remain so.
>
> You did =). "It aligns dumb buffers and video=". 

I did not tell you "video= parameter is bad".

Best regards
Thomas

> I understand the need for drm_driver_color_mode_format() for video=. 
> But I think it's bad for CREATE_DUMB, at least for the platforms which 
> have never aimed for "RGB-only".
>
> So you're not in favor of a drm_mode_size_dumb() version that does not 
> use drm_driver_color_mode_format(), for these platforms? I'm still at 
> loss as to why we would want to change the behavior of CREATE_DUMB. I 
> see no upside, but I see the chance of regressions.
>
>  Tomi
>

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)



From xen-devel-bounces@lists.xenproject.org Mon Jan 20 09:32:17 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Jan 2025 09:32:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.874863.1285225 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZo8a-0002FY-2X; Mon, 20 Jan 2025 09:32:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 874863.1285225; Mon, 20 Jan 2025 09:32:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZo8a-0002FR-00; Mon, 20 Jan 2025 09:32:04 +0000
Received: by outflank-mailman (input) for mailman id 874863;
 Mon, 20 Jan 2025 09:32:03 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=LEkp=UM=suse.com=jgross@srs-se1.protection.inumbo.net>)
 id 1tZo8Z-0002FL-1F
 for xen-devel@lists.xenproject.org; Mon, 20 Jan 2025 09:32:03 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 629f2fe0-d711-11ef-99a4-01e77a169b0f;
 Mon, 20 Jan 2025 10:31:54 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id 68D991F7A1;
 Mon, 20 Jan 2025 09:31:59 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 42C391393E;
 Mon, 20 Jan 2025 09:31:59 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id IRi7Dg8YjmfYcwAAD6G6ig
 (envelope-from <jgross@suse.com>); Mon, 20 Jan 2025 09:31:59 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 629f2fe0-d711-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1737365519; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=i/ombj/g9T3o/qYpel9j/OgZ4BqsMjTn9szDF4pyRA8=;
	b=LQL0j5OoG6LW3eYCfkWBe7j4gmvdRvdZXIlOfLEvkv3wYaON403YU5RzwwJ4qqGVnG0bPp
	wUE7bil3NbTFbVnv0TWtvXXXqNAj085idxQ8/z8Qhs7Eu9novT2aveyh101qdpqtlcqTI7
	k3+njGfHEAJ7y+9iE5be9q93FVW7bXs=
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1737365519; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=i/ombj/g9T3o/qYpel9j/OgZ4BqsMjTn9szDF4pyRA8=;
	b=LQL0j5OoG6LW3eYCfkWBe7j4gmvdRvdZXIlOfLEvkv3wYaON403YU5RzwwJ4qqGVnG0bPp
	wUE7bil3NbTFbVnv0TWtvXXXqNAj085idxQ8/z8Qhs7Eu9novT2aveyh101qdpqtlcqTI7
	k3+njGfHEAJ7y+9iE5be9q93FVW7bXs=
Message-ID: <81ae6f34-1530-4324-8036-46e63b1bb8cd@suse.com>
Date: Mon, 20 Jan 2025 10:31:58 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] xen: update pvcalls_front_accept prototype
To: Stefano Stabellini <sstabellini@kernel.org>, linux-kernel@vger.kernel.org
Cc: xen-devel@lists.xenproject.org, jbeulich@suse.com
References: <alpine.DEB.2.22.394.2501101117030.1731534@ubuntu-linux-20-04-desktop>
Content-Language: en-US
From: Juergen Gross <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <alpine.DEB.2.22.394.2501101117030.1731534@ubuntu-linux-20-04-desktop>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------qLcLKeovj3KbmjlAQAj0ZApI"
X-Spam-Score: -5.19
X-Spamd-Result: default: False [-5.19 / 50.00];
	BAYES_HAM(-3.00)[99.99%];
	SIGNED_PGP(-2.00)[];
	MIME_BASE64_TEXT_BOGUS(1.00)[];
	NEURAL_HAM_LONG(-0.99)[-0.987];
	MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_BASE64_TEXT(0.10)[];
	MIME_UNKNOWN(0.10)[application/pgp-keys];
	RCVD_TLS_ALL(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~];
	ARC_NA(0.00)[];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	RCPT_COUNT_THREE(0.00)[4];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[amd.com:email,imap1.dmz-prg2.suse.org:helo];
	HAS_ATTACHMENT(0.00)[]
X-Spam-Flag: NO
X-Spam-Level: 

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------qLcLKeovj3KbmjlAQAj0ZApI
Content-Type: multipart/mixed; boundary="------------E1jYqZH00Hxmcq1Rd5ShzECc";
 protected-headers="v1"
From: Juergen Gross <jgross@suse.com>
To: Stefano Stabellini <sstabellini@kernel.org>, linux-kernel@vger.kernel.org
Cc: xen-devel@lists.xenproject.org, jbeulich@suse.com
Message-ID: <81ae6f34-1530-4324-8036-46e63b1bb8cd@suse.com>
Subject: Re: [PATCH v3] xen: update pvcalls_front_accept prototype
References: <alpine.DEB.2.22.394.2501101117030.1731534@ubuntu-linux-20-04-desktop>
In-Reply-To: <alpine.DEB.2.22.394.2501101117030.1731534@ubuntu-linux-20-04-desktop>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------E1jYqZH00Hxmcq1Rd5ShzECc
Content-Type: multipart/mixed; boundary="------------QeYPZJ1ZMsOo2gOxCfbbia4T"

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

T24gMTAuMDEuMjUgMjA6MTgsIFN0ZWZhbm8gU3RhYmVsbGluaSB3cm90ZToNCj4gV2hpbGUg
Y3VycmVudGx5IHRoZXJlIGFyZSBubyBpbi10cmVlIGNhbGxlcnMgb2YgdGhlc2UgZnVuY3Rp
b25zLCBpdCBpcw0KPiBiZXN0IHRvIGtlZXAgdGhlbSB1cC10by1kYXRlIHdpdGggdGhlIGxh
dGVzdCBuZXR3b3JrIEFQSS4NCj4gDQo+IFNpZ25lZC1vZmYtYnk6IFN0ZWZhbm8gU3RhYmVs
bGluaSA8c3RlZmFuby5zdGFiZWxsaW5pQGFtZC5jb20+DQoNCldoYXQgYXJlIHlvdXIgZnV0
dXJlIHBsYW5zIHJlZ2FyZGluZyB1c2FnZSBvZiB0aGlzIGZ1bmN0aW9uPw0KDQpJIGd1ZXNz
IHlvdSBhcmUgbG9va2luZyBpbnRvIGFuIGFkZGl0aW9uIHRvIHRoZSBwdmNhbGxzIGRyaXZl
cj8gSWYgdGhlDQpwbGFuIGlzIHRvIHVzZSBpdCBmcm9tIGEgZGlmZmVyZW50IGRyaXZlciwg
SSdkIHJlY29tbWVuZCBhZGRpbmcgdGhlDQptaXNzaW5nIEVYUE9SVF9TWU1CT0xbX0dQTF0o
KSByaWdodCBhd2F5Lg0KDQoNCkp1ZXJnZW4NCg==
--------------QeYPZJ1ZMsOo2gOxCfbbia4T
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

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

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

--------------QeYPZJ1ZMsOo2gOxCfbbia4T--

--------------E1jYqZH00Hxmcq1Rd5ShzECc--

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

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

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmeOGA4FAwAAAAAACgkQsN6d1ii/Ey8Y
2Af/QmTBfcxGP+Y05VaOpmWKINwbe1rqQZO1YkgczPiS0YpGQDITbgo0GDgExXW6cVIY1L/dCtwt
n0EDDe0BVu32nxm5N4pn1nArIdSMOMKqhBE9hsyCe5NAOmLPcQJdrOb3GRl0+QpHczc7nfzJF+1U
P/rnTNvFuFBF07tFsPf7BsIKG0zFocI+MdoCvJhN4nKrY8Kq3Z5gs7W0x0hRRnnPjDM6njeSViCI
ef7kkG1TPiz30bEFNiL5Jahk03E1K8rTpA354S8REtWiH/FWumK0rSQD+SfRaEnsqOsgjUhoOULj
Oxa125PwlyDHvqABDLQmsw+AQY2vJlVP4XDE1dlO8g==
=TyPn
-----END PGP SIGNATURE-----

--------------qLcLKeovj3KbmjlAQAj0ZApI--


From xen-devel-bounces@lists.xenproject.org Mon Jan 20 09:35:52 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Jan 2025 09:35:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.874870.1285236 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZoCF-0002p8-I9; Mon, 20 Jan 2025 09:35:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 874870.1285236; Mon, 20 Jan 2025 09:35:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZoCF-0002p1-Ez; Mon, 20 Jan 2025 09:35:51 +0000
Received: by outflank-mailman (input) for mailman id 874870;
 Mon, 20 Jan 2025 09:35: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
 <SRS0=1xfr=UM=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tZoCD-0002oo-Qn
 for xen-devel@lists.xenproject.org; Mon, 20 Jan 2025 09:35:49 +0000
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com
 [2a00:1450:4864:20::231])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e8bd8d89-d711-11ef-99a4-01e77a169b0f;
 Mon, 20 Jan 2025 10:35:40 +0100 (CET)
Received: by mail-lj1-x231.google.com with SMTP id
 38308e7fff4ca-3061513d353so39259311fa.2; 
 Mon, 20 Jan 2025 01:35:44 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5439af07437sm1245908e87.25.2025.01.20.01.35.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 20 Jan 2025 01:35:43 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e8bd8d89-d711-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1737365744; x=1737970544; darn=lists.xenproject.org;
        h=content-transfer-encoding:subject:from:cc:to:content-language
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=/q9HFjah82H3fpeLxRupwWEr0ySBimWHo8tSEFu9+qw=;
        b=mstCHx/xS2Qf4Mrezolnpy080OF01JBYGYV+xhTieoYUHCTYLmGysD3YSUbC/U0kgu
         M0MKUc2BJcxpYPfk2OU40v5f859LWw+RvYvKg+ca+jN4dZgcCrQTS6QDM8sYcHWLT2g8
         a8boUqHBiOMD/sHq8OtZhEIotawJ6foLiqtkXLWUfkNMiGWGncJ2Nok/JfrNkFNXksbI
         OVQh6Ue2GHPzFb5OfK30RMpEFQKuS7S3tkL1ATV8m+CSoA+q9F37jh6XxqT2XrtXgYjD
         MF59pr0DUc2gNm/b/N16NhQTl5eTcpSR3ygYxA7rx5LFJf+osPjMxU9vweTC2PoHapnC
         /wfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737365744; x=1737970544;
        h=content-transfer-encoding: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=/q9HFjah82H3fpeLxRupwWEr0ySBimWHo8tSEFu9+qw=;
        b=ZsbDE2y0WHvJuhVAkCLbHdxMUv3OSTbNr8XX4JTsGXXOuHyMalsItyg5HXF8gQeNjn
         O3/M64hm5AY5Hm/1OOhC1uaS+Jj6wU3VgAMhIWydriOuFXe3yKJWC5uyxPwel/kLwkcf
         rtyTnZxf8P3NLkOPK6a3MOJRpnzToUP076Ph6WGPuM+K/oQrSXpsDFn+42UBbHwgDF/C
         TpW3WpMiCFQloy9765tYPT+ZMJ1ZVrVQQGAxL9UTxON0OHU3dM4LpY6P8YOBL3dgEW2l
         DMGBxwIsS542rak17wekZZkINGHkDMVGJNP/MILs0+OOKzW0wFvz/6QEPbKfAx27lJj8
         6AqA==
X-Forwarded-Encrypted: i=1; AJvYcCUomROg9GN0OJ7K1+8OiFNcGKbrHYYR2B6GOUgE1fhkksJN/yyO8CyuH8L++vtsURZC3d4WSMK/r6OFM3E=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzVoFuqtfcNEZ1uhb1nz9kYezi5axJySPtAQ8sL0E85wUSn6Xyv
	O+ISQmhdaAaV75D2Ykeax0V7iSi58Fk6Hujm7xgNQRFJ9PlfbgYr/BA+8A==
X-Gm-Gg: ASbGncvanPn+AMlDz+oc0nHh2XnfAnRzx9thrqgJRz4QlF650Be86NV4WiEstiZ8yKR
	7K2vUkEncephZOptPXL424HDX7TMBpG6j59mjQfGjPFfUVMGjJ7QfHUgLcFw5K9IOQ2DkdWQcB+
	PuoLEw73YfaSUA5XbykeM/Fj7l8j49T8w76Un124ewNuCoXkUn5MgxdDxvkDvXDgwcFWPTgR9Md
	ey/lIWAd9z7O43wdYP4aqSIN2/1DRF2FxjSx5mUAKVc9CNnN7mdYW2kTyGPpnCXjYQzjbAuJG4L
	bDGmoO8=
X-Google-Smtp-Source: AGHT+IFOh9LhNdkDnTT/D7VE43v91V2HBSphEUYtPPz+mPOPFdzrJRiJgU2BqZaqilhGPNYH7Y5AYA==
X-Received: by 2002:a05:6512:398a:b0:542:1b6b:1e8f with SMTP id 2adb3069b0e04-5439c2412b8mr4457490e87.18.1737365743313;
        Mon, 20 Jan 2025 01:35:43 -0800 (PST)
Message-ID: <7bf2ec2f-ecb3-4136-a979-6111c11447b4@gmail.com>
Date: Mon, 20 Jan 2025 10:35:42 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: xen-users@lists.xenproject.org, xen-announce@lists.xenproject.org,
 Community Manager <community.manager@xenproject.org>,
 committers@xenproject.org
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Subject: [ANNOUNCEMENT] Xen 4.20.0-rc2 is tagged
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi all,

Xen 4.20 rc2 is tagged. You can check that out from xen.git:

git://xenbits.xen.org/xen.git 4.20.0-rc2

For your convenience there is also a tarball and the signature at:
https://downloads.xenproject.org/release/xen/4.20.0-rc2/xen-4.20.0-rc2.tar.gz

And the signature is at:
https://downloads.xenproject.org/release/xen/4.20.0-rc2/xen-4.20.0-rc2.tar.gz.sig

Please send bug reports and test reports to
xen-devel@lists.xenproject.org<mailto:xen-devel@lists.xenproject.org>.
When sending bug reports, please CC relevant maintainers and me
(oleskii.kurochko@gmail.com<mailto:oleskii.kurochko@gmail.com).

Have a good week.

Best regards,
  Oleksii



From xen-devel-bounces@lists.xenproject.org Mon Jan 20 09:49:09 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Jan 2025 09:49:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.874898.1285259 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZoP2-0005Yy-1H; Mon, 20 Jan 2025 09:49:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 874898.1285259; Mon, 20 Jan 2025 09:49:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZoP1-0005Yr-TB; Mon, 20 Jan 2025 09:49:03 +0000
Received: by outflank-mailman (input) for mailman id 874898;
 Mon, 20 Jan 2025 09:49:02 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=1xfr=UM=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tZoP0-0005Yl-NX
 for xen-devel@lists.xenproject.org; Mon, 20 Jan 2025 09:49:02 +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 c70c3a50-d713-11ef-a0e3-8be0dac302b0;
 Mon, 20 Jan 2025 10:49:01 +0100 (CET)
Received: by mail-lf1-x12b.google.com with SMTP id
 2adb3069b0e04-5401bd6cdb7so4088168e87.2
 for <xen-devel@lists.xenproject.org>; Mon, 20 Jan 2025 01:49:01 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5439af60913sm1264997e87.123.2025.01.20.01.48.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 20 Jan 2025 01:48:59 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c70c3a50-d713-11ef-a0e3-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1737366540; x=1737971340; darn=lists.xenproject.org;
        h=content-transfer-encoding:subject:from:cc:to:content-language
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=z+J/LNJvWYY+tHim3tSirhQiRwXTYSBgfGctgoztLNU=;
        b=lxXBO1A8fQ7QN+mWqVY4Jp/tlTOa5i8ncieHJgvv8ZaTYsby7/YbQ+D7WHaVhN4M6Q
         f7RIdFUOt+eU+cZIEzC4A1Z8KHiG6aa+3TltU2NZ/mch1ZT8uPi9pNNYCk3AvPJIELV9
         dyXAoem9jTLLoG8CiUZzVk6RBU0IdOkJukuMwU+LXD3GH6QIrIijly+Z6xx0VZEk27Ly
         ZNznTsmAqEjt3AxViLjzpiN0ixyi0F/jAmctkNusyn+MCdV3hfwRiDjxuwyQR8nkbL1C
         uVvjpoWrlJ78LXvcgV2CDnDzK2tRvQbH8qviitneEdwglZNeE0NIZyBLeKA5X+jhPhBM
         IkFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737366540; x=1737971340;
        h=content-transfer-encoding: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=z+J/LNJvWYY+tHim3tSirhQiRwXTYSBgfGctgoztLNU=;
        b=Xk+ufXlmm8LJeWhPB3jKXBfWHa0Chn6vKvsEcVypQYLDVszj3AI8IADpagn4ALeLZy
         Bs97AbBIMKTRL/vpXRf5MYkQqd87oJjPxQVzuCl0HKjU2iRgzS/OI+IDSmpC7K/k/9ps
         XFQiOlyKzGR+Xw6yM49qPDSBs0smAQibaq3bYKOG7pblHqIz8xBXjBfi2fnXQYxl1WRt
         91dgIVwIOLsaSaC3t965aSaWOCDY7KhAvKBhs/XGKFewewowAcd/fxfETRvt8zI3i5h5
         sY+r1bI3rLanFsWdleEOtMai25BYoIm83yHyNyzQd3pBgadNHDWovYtMR5fI1lMJ0To9
         ujPw==
X-Gm-Message-State: AOJu0Yyhj+iyyWsuPg/vNnaK48PSOiBlQ6QaUcjIWEW23HgBxv5EFIQt
	AedLKwWWWwBn9WOVGrJBbHVfoerBnH027t91Q1QWR2rvmytLJ2NIngtcCw==
X-Gm-Gg: ASbGncv/aEdgm0yzlje5A/6pOLSosOKqAzF9fOvDAA3g16jSf+9e1bSbNTPng8KkdDg
	y2+3mjI+6wu6Pi+UwkKIbzWO2T8LfmroJZhRKVGzDVsrpClsQ0pI5mVd/300nWOOVuf39vdXsZi
	ndb1IykObd4do/6GfuVQY+8zHVz74OhK6vYsgsOidbaHMG+b9gRhrDmap0lutNsR7Zmx0DW/vUM
	8VcOQqp5N2Fs+OBhmHXmbLmAISoXuqqqBrkQuBs8MjeA6e3DLNxU60wqjL7chCdBW08+XjWEZTB
	hYnaGOw=
X-Google-Smtp-Source: AGHT+IFQYU+eXGZVdwiQ4sYivTuKqaSG3hPjfFGrNYKmmi0S01UOIQRN8jq0Ihz/XXMRoBG5HK6vcA==
X-Received: by 2002:a05:6512:4808:b0:540:22e0:1f80 with SMTP id 2adb3069b0e04-5439c229158mr3469326e87.20.1737366540074;
        Mon, 20 Jan 2025 01:49:00 -0800 (PST)
Message-ID: <9ce473c2-0735-4ded-9f44-6e8c0605cf3d@gmail.com>
Date: Mon, 20 Jan 2025 10:48:59 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Community Manager <community.manager@xenproject.org>,
 committers@xenproject.org
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Subject: Hard code freeze date for Xen 4.20 is Feb 07, 2025
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hello everyone,

The hard code freeze date for Xen 4.20 is  February 07, 2025.

Bug fixes for serious bugs (including regressions), and low-risk fixes 
only may
continue to be accepted by maintainers beyond this point. Please add me 
in CC
for the bugs and fixes you think should be in the current release.

Thanks and have a great week!

Best regards,
   Oleksii



From xen-devel-bounces@lists.xenproject.org Mon Jan 20 09:56:17 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Jan 2025 09:56:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.874913.1285268 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZoVy-0007WL-IN; Mon, 20 Jan 2025 09:56:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 874913.1285268; Mon, 20 Jan 2025 09:56:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZoVy-0007WE-FX; Mon, 20 Jan 2025 09:56:14 +0000
Received: by outflank-mailman (input) for mailman id 874913;
 Mon, 20 Jan 2025 09:56:13 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=1xfr=UM=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tZoVx-0007Vu-3F
 for xen-devel@lists.xenproject.org; Mon, 20 Jan 2025 09:56:13 +0000
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com
 [2a00:1450:4864:20::129])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c7b98913-d714-11ef-a0e3-8be0dac302b0;
 Mon, 20 Jan 2025 10:56:12 +0100 (CET)
Received: by mail-lf1-x129.google.com with SMTP id
 2adb3069b0e04-54298ec925bso5120683e87.3
 for <xen-devel@lists.xenproject.org>; Mon, 20 Jan 2025 01:56:12 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5439af07ae4sm1247415e87.47.2025.01.20.01.56.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 20 Jan 2025 01:56:10 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c7b98913-d714-11ef-a0e3-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1737366971; x=1737971771; darn=lists.xenproject.org;
        h=in-reply-to:content-language:references:cc:to:from:subject
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=aWd478+1zlqzkwI3n78PwnNHKKyIVpxwGjjTEAnc7FI=;
        b=IoPWugCAxdfZ+FIwCALYA9VwN+OPrMtQIuJKgz4B08zkmmTagz63R2iI3QdNW7JlAH
         7q+YApQv/Q7K4bqYy7ui3/M1kM0SzyhekTJJtGLbzgZLk0coxtxHGCT8R3EDsYrhvax4
         Qp00y8My8JESAgccgN8JPfS9uEC/+pgI8XuGddpEY/yvbrgpJFfuHvTgJypSLHfV0S5i
         6ZhKraIEMiMjXCGESsipYApru3SJk5pQk9mtvkxShMxoi9STUVzodKdPJCRn7urfUpFW
         p8ZtYnegVkX4tSAFsmCGIJoWOhMocS7sKxfihUV4L+VieT0HaBA4O+AYBSrFAlmtiwUN
         awWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737366971; x=1737971771;
        h=in-reply-to:content-language:references:cc:to:from:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=aWd478+1zlqzkwI3n78PwnNHKKyIVpxwGjjTEAnc7FI=;
        b=sd+fuRg/jdLfQ2UcCf7ZkJZHcfCBoOEgBuT2QptVpdHirgiaQXpekNjIEQMDS6K8QQ
         kqjwyP5xd5Uyq+L4gPRBI2C4lX+USZ67xKyBbHCbHBibgjXOP/tX+of89nbIQXOEv5Bh
         SZzxTyVy1MOP7ZvGD8BXBuQ5XoxgEaC3Pyfw/c8LWmrnYskKS5yxcMDonkpLRMFY3maO
         FjVprYUQKl0BNaMLj4otN4ba5+sYZv7A0rlrWslL1y7N+KtESnpS9Kf090TeR9iL4Fzw
         SOob5shbWJoVnplJih+zpl/VqB4tUcglGj9Z5XADayK3HT3VeTxMLkc7/QypOrcSRpSP
         6B9w==
X-Gm-Message-State: AOJu0YwbFpq2E9ywHN50kokTc86xQtj7E3yUgffwsdSzwP4G57+UA2n1
	4hAQHu3IoZU+PrCa1y8rNHJpj9p+e1bOirPGngkttGA047z1iBCOBg3oSg==
X-Gm-Gg: ASbGncsWv1BMaxSx0Iya8lvJpH1zVWcyO6VQZyHuhtxNz3D8kRw3t0ovVGcQhaZw2Ry
	0oDE8FWdUi8Ljbc8ZPCGxuWjTP9pnKjpp0JB0DeP6nlab+iUi3aXfyyoTC7PqtLFMbH5LvY3lKt
	Sm1jxpFMYOd4R+4fBFb6Vx0Vxy+3BFl64KdzjHzxoPWXDVC0l8VA4PGTq+ETUH8G7BXU2PzF5l2
	LPwfaT4n/etXU8cn1vpEMtWzSUBEfGGZG80X4gdVLhHgchnRpuZGwgcuafWqnotI34jpKfLfCkC
	Y55HimQ=
X-Google-Smtp-Source: AGHT+IHunhH8LDpuVcMBXJmaJ674tTCFQdbOHDETTvEfoWKmpbFMRKN3yAtd3TITGI49L5oDEzVWtQ==
X-Received: by 2002:ac2:4acb:0:b0:540:1a0c:9ba6 with SMTP id 2adb3069b0e04-5439c282d2bmr3668735e87.34.1737366970652;
        Mon, 20 Jan 2025 01:56:10 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------qa0UJA0v1VMAXraQv0gh2UeC"
Message-ID: <2f0550b6-2b2c-495a-9b06-1d24a2748138@gmail.com>
Date: Mon, 20 Jan 2025 10:56:09 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Hard code freeze date for Xen 4.20 is Feb 07, 2025
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Community Manager <community.manager@xenproject.org>,
 committers@xenproject.org
References: <9ce473c2-0735-4ded-9f44-6e8c0605cf3d@gmail.com>
Content-Language: en-US
In-Reply-To: <9ce473c2-0735-4ded-9f44-6e8c0605cf3d@gmail.com>

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


On 1/20/25 10:48 AM, Oleksii Kurochko wrote:
> Hello everyone,
>
> The hard code freeze date for Xen 4.20 is  February 07, 2025.
>
> Bug fixes for serious bugs (including regressions), and low-risk fixes 
> only may
> continue to be accepted by maintainers beyond this point. Please add 
> me in CC
> for the bugs and fixes you think should be in the current release.

For straightforward bugs and fixes, an R-Ack is not needed until the end of hard
code freeze date.
However, if you have any doubts, feel free to request an R-Ack explicitly.

~ Oleksii

>
> Thanks and have a great week!
>
> Best regards,
>   Oleksii
>
--------------qa0UJA0v1VMAXraQv0gh2UeC
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 1/20/25 10:48 AM, Oleksii Kurochko
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:9ce473c2-0735-4ded-9f44-6e8c0605cf3d@gmail.com">Hello
      everyone,
      <br>
      <br>
      The hard code freeze date for Xen 4.20 is  February 07, 2025.
      <br>
      <br>
      Bug fixes for serious bugs (including regressions), and low-risk
      fixes only may
      <br>
      continue to be accepted by maintainers beyond this point. Please
      add me in CC
      <br>
      for the bugs and fixes you think should be in the current release.
      <br>
    </blockquote>
    <pre>For straightforward bugs and fixes, an R-Ack is not needed until the end of hard
code freeze date.
However, if you have any doubts, feel free to request an R-Ack explicitly.

~ Oleksii</pre>
    <blockquote type="cite"
      cite="mid:9ce473c2-0735-4ded-9f44-6e8c0605cf3d@gmail.com">
      <br>
      Thanks and have a great week!
      <br>
      <br>
      Best regards,
      <br>
        Oleksii
      <br>
      <br>
    </blockquote>
  </body>
</html>

--------------qa0UJA0v1VMAXraQv0gh2UeC--


From xen-devel-bounces@lists.xenproject.org Mon Jan 20 11:15:51 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Jan 2025 11:15:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.874930.1285277 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZpkj-0001RR-Tq; Mon, 20 Jan 2025 11:15:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 874930.1285277; Mon, 20 Jan 2025 11:15:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZpkj-0001RK-Qo; Mon, 20 Jan 2025 11:15:33 +0000
Received: by outflank-mailman (input) for mailman id 874930;
 Mon, 20 Jan 2025 11:15:32 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=/LCm=UM=gmail.com=urezki@srs-se1.protection.inumbo.net>)
 id 1tZpki-0001RE-Bx
 for xen-devel@lists.xenproject.org; Mon, 20 Jan 2025 11:15:32 +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 db95f187-d71f-11ef-a0e3-8be0dac302b0;
 Mon, 20 Jan 2025 12:15:30 +0100 (CET)
Received: by mail-lf1-x12a.google.com with SMTP id
 2adb3069b0e04-5401be44b58so4488478e87.0
 for <xen-devel@lists.xenproject.org>; Mon, 20 Jan 2025 03:15:30 -0800 (PST)
Received: from pc636 (host-217-213-93-172.mobileonline.telia.com.
 [217.213.93.172]) by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5439af60936sm1298036e87.107.2025.01.20.03.15.22
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 20 Jan 2025 03:15:27 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: db95f187-d71f-11ef-a0e3-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1737371729; x=1737976529; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:date:from:from:to
         :cc:subject:date:message-id:reply-to;
        bh=2GVkq9tRDCkhxRDT/CBStGfoQ0If4+e8Z0FyGDV8QRs=;
        b=muBHzK9OGtoqhUoFdYXAVrgnerS1nJ4l/MxbPuuLduD3Rq5Ux8VwhWL6SFZPPdK1hR
         RLhPekPpZ8+6uajrGGSsIK96da11yDhnE7Lp8lefTN2z4+wfUbS3badjfNFBkN3l0wlv
         TNPNOgNVpHn9+Uk+IZlbBxyPUbQ0k8gwq8ITHSHvN/4FnO519V/XudTQ4WnUoUyeuN2r
         +Cq641zeoY1OQmcpL4D8PR3+OLjyR9j+/gQm92KKCnhCZ/j+NUCmNGmEEqZtO1rMXif1
         KpUH9gTrwlha79kSEe4VNhp71GgaUCs+ISavBkipYAVXBbiZCCqB3O8phIzlKE2l+1j0
         9dTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737371729; x=1737976529;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:date:from
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=2GVkq9tRDCkhxRDT/CBStGfoQ0If4+e8Z0FyGDV8QRs=;
        b=K67/x9IjZ4StFMKV3Jn3NFUHmhUjFOXPwWvf3nLM8shQkVaREbEChTx44qHK/Oij7C
         vytYL1ZYTlTFYy7AAUpq4Fy7tBitCzs4zhxnxAFY0dh6FUi0iz+Xd2jWrFWRFb5aOf20
         8mKuls0AHsCst1oOgKaMibOQYmhtk+51YBuyVfXN813qHSplHXWMjhUTgykJYOZT96nI
         k9W8lozPC3ue6K9PgE34wWEfZx3mpI/o5jDomM5nKT0S+SY8IKCm8nSXVK3JgbeoZMPU
         /Lp2NI17CYqPCRXNztuXELQM819inEFLuL+7DTzyhjKbdGhzvWE2L/lIek8OvFMT0dC5
         Obow==
X-Forwarded-Encrypted: i=1; AJvYcCUd5Vimjcl0aeoF2+VVxTYwhOD/GSaFVUlYTaBo5T5JLrJ97XSoyIvb7kyuXbZ4KBP2Re1J4dJj7k8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwLvL2QKBF04rJs7rrgWTV/Qj3E4Ftp4MW4RiC/Iu84epNDtfIn
	ti6xsMme8MKeo5eIk8liJfJWFFY9khllAYyrA/Xsg0pmYiaQa3ic
X-Gm-Gg: ASbGncucYInBv4NGscMAYmx5ulOoorqT9DnX+CLcn4bc4EOr7xc8UFThPsjygcP1o4K
	CFcC4C3tCTCqUunZrnsVr77YFnRO6/HiSCQCs1VZhoRf37VxD+A6r7E1tsX9iZ2LP5ydRSXnNAh
	w1QsGjEELrUmV2E/+gqO0AWi/aND2FEn5otlzfXm5G6JEcIMeku987c90jGfCCtwbhdfidqjtm8
	7BTdPGf1Ut4rxqqqgnD71JKR0P5oYK+hXNFN/Rpsw8YkXpzjFmAISBNynmGFF5aBPGb3JA0fOPL
	CLrbjbEG/JPjzoBoxuoSSIjv
X-Google-Smtp-Source: AGHT+IHKV/b4OpTja4V+3bSeLRqiI1pV4ugkz/2qcipp1USPLcCJuF4RKlBH/zOnSXkuGgwcoGAG8A==
X-Received: by 2002:ac2:4155:0:b0:542:8cf5:a3a3 with SMTP id 2adb3069b0e04-5439c216c23mr3426183e87.5.1737371729069;
        Mon, 20 Jan 2025 03:15:29 -0800 (PST)
From: Uladzislau Rezki <urezki@gmail.com>
X-Google-Original-From: Uladzislau Rezki <urezki@pc636>
Date: Mon, 20 Jan 2025 12:15:20 +0100
To: Valentin Schneider <vschneid@redhat.com>
Cc: Uladzislau Rezki <urezki@gmail.com>, Jann Horn <jannh@google.com>,
	linux-kernel@vger.kernel.org, x86@kernel.org,
	virtualization@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev,
	linux-riscv@lists.infradead.org, linux-perf-users@vger.kernel.org,
	xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
	linux-arch@vger.kernel.org, rcu@vger.kernel.org,
	linux-hardening@vger.kernel.org, linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org, bpf@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com,
	Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.amakhalov@broadcom.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andy Lutomirski <luto@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Clark Williams <williams@redhat.com>,
	Yair Podemsky <ypodemsk@redhat.com>,
	Tomas Glozar <tglozar@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
	Kees Cook <kees@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Shuah Khan <shuah@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Miguel Ojeda <ojeda@kernel.org>, Alice Ryhl <aliceryhl@google.com>,
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
	Samuel Holland <samuel.holland@sifive.com>,
	Rong Xu <xur@google.com>,
	Nicolas Saenz Julienne <nsaenzju@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Yosry Ahmed <yosryahmed@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Jinghao Jia <jinghao7@illinois.edu>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: Re: [PATCH v4 29/30] x86/mm, mm/vmalloc: Defer
 flush_tlb_kernel_range() targeting NOHZ_FULL CPUs
Message-ID: <Z44wSJTXknQVKWb0@pc636>
References: <20250114175143.81438-1-vschneid@redhat.com>
 <20250114175143.81438-30-vschneid@redhat.com>
 <CAG48ez1Mh+DOy0ysOo7Qioxh1W7xWQyK9CLGNU9TGOsLXbg=gQ@mail.gmail.com>
 <xhsmh34hhh37q.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
 <Z4qBMqcMg16p57av@pc636>
 <xhsmhwmetfk9d.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <xhsmhwmetfk9d.mognet@vschneid-thinkpadt14sgen2i.remote.csb>

On Fri, Jan 17, 2025 at 06:00:30PM +0100, Valentin Schneider wrote:
> On 17/01/25 17:11, Uladzislau Rezki wrote:
> > On Fri, Jan 17, 2025 at 04:25:45PM +0100, Valentin Schneider wrote:
> >> On 14/01/25 19:16, Jann Horn wrote:
> >> > On Tue, Jan 14, 2025 at 6:51 PM Valentin Schneider <vschneid@redhat.com> wrote:
> >> >> vunmap()'s issued from housekeeping CPUs are a relatively common source of
> >> >> interference for isolated NOHZ_FULL CPUs, as they are hit by the
> >> >> flush_tlb_kernel_range() IPIs.
> >> >>
> >> >> Given that CPUs executing in userspace do not access data in the vmalloc
> >> >> range, these IPIs could be deferred until their next kernel entry.
> >> >>
> >> >> Deferral vs early entry danger zone
> >> >> ===================================
> >> >>
> >> >> This requires a guarantee that nothing in the vmalloc range can be vunmap'd
> >> >> and then accessed in early entry code.
> >> >
> >> > In other words, it needs a guarantee that no vmalloc allocations that
> >> > have been created in the vmalloc region while the CPU was idle can
> >> > then be accessed during early entry, right?
> >>
> >> I'm not sure if that would be a problem (not an mm expert, please do
> >> correct me) - looking at vmap_pages_range(), flush_cache_vmap() isn't
> >> deferred anyway.
> >>
> >> So after vmapping something, I wouldn't expect isolated CPUs to have
> >> invalid TLB entries for the newly vmapped page.
> >>
> >> However, upon vunmap'ing something, the TLB flush is deferred, and thus
> >> stale TLB entries can and will remain on isolated CPUs, up until they
> >> execute the deferred flush themselves (IOW for the entire duration of the
> >> "danger zone").
> >>
> >> Does that make sense?
> >>
> > Probably i am missing something and need to have a look at your patches,
> > but how do you guarantee that no-one map same are that you defer for TLB
> > flushing?
> >
> 
> That's the cool part: I don't :')
> 
Indeed, sounds unsafe :) Then we just do not need to free areas.

> For deferring instruction patching IPIs, I (well Josh really) managed to
> get instrumentation to back me up and catch any problematic area.
> 
> I looked into getting something similar for vmalloc region access in
> .noinstr code, but I didn't get anywhere. I even tried using emulated
> watchpoints on QEMU to watch the whole vmalloc range, but that went about
> as well as you could expect.
> 
> That left me with staring at code. AFAICT the only vmap'd thing that is
> accessed during early entry is the task stack (CONFIG_VMAP_STACK), which
> itself cannot be freed until the task exits - thus can't be subject to
> invalidation when a task is entering kernelspace.
> 
> If you have any tracing/instrumentation suggestions, I'm all ears (eyes?).
> 
As noted before, we defer flushing for vmalloc. We have a lazy-threshold
which can be exposed(if you need it) over sysfs for tuning. So, we can add it.

--
Uladzislau Rezki


From xen-devel-bounces@lists.xenproject.org Mon Jan 20 13:53:59 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Jan 2025 13:53:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.874959.1285288 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZsDf-0004a0-MK; Mon, 20 Jan 2025 13:53:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 874959.1285288; Mon, 20 Jan 2025 13:53:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZsDf-0004Zt-Ij; Mon, 20 Jan 2025 13:53:35 +0000
Received: by outflank-mailman (input) for mailman id 874959;
 Mon, 20 Jan 2025 13:53: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
 <SRS0=UHT9=UM=redhat.com=vschneid@srs-se1.protection.inumbo.net>)
 id 1tZsDd-0004Zl-Vv
 for xen-devel@lists.xenproject.org; Mon, 20 Jan 2025 13:53:34 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ee928ed5-d735-11ef-a0e3-8be0dac302b0;
 Mon, 20 Jan 2025 14:53:31 +0100 (CET)
Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com
 [209.85.160.197]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-328-TqlFYvuiOWu4g0FaAdR92A-1; Mon, 20 Jan 2025 08:53:29 -0500
Received: by mail-qt1-f197.google.com with SMTP id
 d75a77b69052e-467a3c0c8f6so85056201cf.0
 for <xen-devel@lists.xenproject.org>; Mon, 20 Jan 2025 05:53:29 -0800 (PST)
Received: from vschneid-thinkpadt14sgen2i.remote.csb
 (213-44-141-166.abo.bbox.fr. [213.44.141.166])
 by smtp.gmail.com with ESMTPSA id
 d75a77b69052e-46e1030da00sm42651971cf.33.2025.01.20.05.53.14
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 20 Jan 2025 05:53:25 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ee928ed5-d735-11ef-a0e3-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1737381210;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=6OUKdt6VXAQzpOTUFB26LmXUDO8O/oST+Zn2uKcAtKs=;
	b=eGDHOXeGpR0jSKvHT5MBkJQHXMkMHJjrO/ODuRg5+tdN5vwxwkP5D7crDRlIYgMqpJ/ZRH
	Mgv+dY1h8sVNw6GaDZ5g5/KruDz557TqFehXyGhq67R0z2CdocTOLD1xCXDhfTipTZGWGs
	N0NKT0mZO49sGVe0K2zIRN7scilZ6Qg=
X-MC-Unique: TqlFYvuiOWu4g0FaAdR92A-1
X-Mimecast-MFC-AGG-ID: TqlFYvuiOWu4g0FaAdR92A
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737381207; x=1737986007;
        h=mime-version:message-id:date:references:in-reply-to:subject:cc:to
         :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=6OUKdt6VXAQzpOTUFB26LmXUDO8O/oST+Zn2uKcAtKs=;
        b=CbTUyyzxiT3lhdrkXY8ybdys8SrdadnZdlPlTiu7L2CGxYsEqexykABvJjxT/uMZ6v
         B1Z9qejckrfHgr8Zop0n9YfORA199J3wKJ4AKGYFPbUBuzoFTZTvsBrZefjIij4/xpLJ
         LpR3hXrMWx2ThTP7d2j8AdCTXqHaVijtx3H2a4cFlXJsZxo/yJsCi2ts8POeibMx8FIm
         O564aHRnIkKOqsxfTi6ue5xhitsNULnvmc6ea2+2KUKEgkveZP20sZCYneyO6SCR4kyj
         npPcv/zI07w0tMTpGoYjgURxuAkU8g80HmqzesgU5R44ZuK4glvR09CW+PJ9NnzVZlu+
         y91w==
X-Forwarded-Encrypted: i=1; AJvYcCXn1/CmquGKvk/TZJvy56S/mfPutQsYt5PQ23hSdO3A8BS2r5LX0EqNb+WMAVrwdW03gGhgAzUKgBE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyykohG3DIBKsDr5SAe1/rLC6M+/KnTxQsDL6S1lXbtmXlVtexq
	eOIrdOYo6fCbfniIaa1upbaSgNJMiRAA/ISJpv9f18MP4UfpS953ybZUUZKwTusqOKZhZK1x5j3
	QUfsctn+nKKRzYA3G2vG3DLlQze1mjgcjr8fx3skpPfPMGcUUAonzXjBxNeU1niVC
X-Gm-Gg: ASbGncv8z5oagsD9DECKb/J4iBOmamgfYLljadAShLnq4Ul4oIxpjG3rwt/17ufBAqU
	tXfySkkilHvl8Hp238zT1db+q+BnOLBm3C+b6GB7YjJ5UHdzfDMpkhyXvJzV3yTDMVC7ho+FKQs
	AvjTnbnMyNoB15XQm/wMuJTXdfPwmR2bUFzsVESkyntHPgnLnnR65lHzOJ/JQStHB393lGC2ywf
	0YX1Ql6dOyd4FWC8IOT5KZqoYEb/vvYvt81RTWRPvycgiNnjCjgG5OLXns7/CVkhj30AUEAycJj
	/YAESxYLrDm1Mf5RYr39IiFcQeA6q7z3bbKapGQShICAfEjD964TuWQ=
X-Received: by 2002:ac8:7d82:0:b0:467:5e61:c116 with SMTP id d75a77b69052e-46e12a1e36cmr160729241cf.7.1737381207225;
        Mon, 20 Jan 2025 05:53:27 -0800 (PST)
X-Google-Smtp-Source: AGHT+IGCbxGDy6CHUSfOLqTxGL3gA1S6wKRHlUvydXAdXodFBspL8+Pdog+OKdfN6k1jzDkgqmOx+A==
X-Received: by 2002:ac8:7d82:0:b0:467:5e61:c116 with SMTP id d75a77b69052e-46e12a1e36cmr160728291cf.7.1737381206799;
        Mon, 20 Jan 2025 05:53:26 -0800 (PST)
From: Valentin Schneider <vschneid@redhat.com>
To: Sean Christopherson <seanjc@google.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
 virtualization@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
 loongarch@lists.linux.dev, linux-riscv@lists.infradead.org,
 linux-perf-users@vger.kernel.org, xen-devel@lists.xenproject.org,
 kvm@vger.kernel.org, linux-arch@vger.kernel.org, rcu@vger.kernel.org,
 linux-hardening@vger.kernel.org, linux-mm@kvack.org,
 linux-kselftest@vger.kernel.org, bpf@vger.kernel.org,
 bcm-kernel-feedback-list@broadcom.com, Peter Zijlstra
 <peterz@infradead.org>, Nicolas Saenz Julienne <nsaenzju@redhat.com>,
 Juergen Gross <jgross@suse.com>, Ajay Kaher <ajay.kaher@broadcom.com>,
 Alexey Makhalov <alexey.amakhalov@broadcom.com>, Russell King
 <linux@armlinux.org.uk>, Catalin Marinas <catalin.marinas@arm.com>, Will
 Deacon <will@kernel.org>, Huacai Chen <chenhuacai@kernel.org>, WANG Xuerui
 <kernel@xen0n.name>, Paul Walmsley <paul.walmsley@sifive.com>, Palmer
 Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>, Thomas
 Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, Borislav
 Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, "H.
 Peter Anvin" <hpa@zytor.com>, Arnaldo Carvalho de Melo <acme@kernel.org>,
 Namhyung Kim <namhyung@kernel.org>, Mark Rutland <mark.rutland@arm.com>,
 Alexander Shishkin <alexander.shishkin@linux.intel.com>, Jiri Olsa
 <jolsa@kernel.org>, Ian Rogers <irogers@google.com>, Adrian Hunter
 <adrian.hunter@intel.com>, Kan Liang <kan.liang@linux.intel.com>, Boris
 Ostrovsky <boris.ostrovsky@oracle.com>, Josh Poimboeuf
 <jpoimboe@kernel.org>, Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
 Paolo Bonzini <pbonzini@redhat.com>, Andy Lutomirski <luto@kernel.org>,
 Arnd Bergmann <arnd@arndb.de>, Frederic Weisbecker <frederic@kernel.org>,
 "Paul E. McKenney" <paulmck@kernel.org>, Jason Baron <jbaron@akamai.com>,
 Steven Rostedt <rostedt@goodmis.org>, Ard Biesheuvel <ardb@kernel.org>,
 Neeraj Upadhyay <neeraj.upadhyay@kernel.org>, Joel Fernandes
 <joel@joelfernandes.org>, Josh Triplett <josh@joshtriplett.org>, Boqun
 Feng <boqun.feng@gmail.com>, Uladzislau Rezki <urezki@gmail.com>, Mathieu
 Desnoyers <mathieu.desnoyers@efficios.com>, Lai Jiangshan
 <jiangshanlai@gmail.com>, Zqiang <qiang.zhang1211@gmail.com>, Juri Lelli
 <juri.lelli@redhat.com>, Clark Williams <williams@redhat.com>, Yair
 Podemsky <ypodemsk@redhat.com>, Tomas Glozar <tglozar@redhat.com>, Vincent
 Guittot <vincent.guittot@linaro.org>, Dietmar Eggemann
 <dietmar.eggemann@arm.com>, Ben Segall <bsegall@google.com>, Mel Gorman
 <mgorman@suse.de>, Kees Cook <kees@kernel.org>, Andrew Morton
 <akpm@linux-foundation.org>, Christoph Hellwig <hch@infradead.org>, Shuah
 Khan <shuah@kernel.org>, Sami Tolvanen <samitolvanen@google.com>, Miguel
 Ojeda <ojeda@kernel.org>, Alice Ryhl <aliceryhl@google.com>, "Mike
 Rapoport (Microsoft)" <rppt@kernel.org>, Samuel Holland
 <samuel.holland@sifive.com>, Rong Xu <xur@google.com>, Geert Uytterhoeven
 <geert@linux-m68k.org>, Yosry Ahmed <yosryahmed@google.com>, "Kirill A.
 Shutemov" <kirill.shutemov@linux.intel.com>, "Masami Hiramatsu (Google)"
 <mhiramat@kernel.org>, Jinghao Jia <jinghao7@illinois.edu>, Luis
 Chamberlain <mcgrof@kernel.org>, Randy Dunlap <rdunlap@infradead.org>,
 Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: Re: [PATCH v4 25/30] context_tracking,x86: Defer kernel text
 patching IPIs
In-Reply-To: <Z4qQL89GZ_gk0vpu@google.com>
References: <20250114175143.81438-1-vschneid@redhat.com>
 <20250114175143.81438-26-vschneid@redhat.com>
 <Z4bTlZkqihaAyGb4@google.com>
 <xhsmhed11hiuy.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
 <Z4qQL89GZ_gk0vpu@google.com>
Date: Mon, 20 Jan 2025 14:53:13 +0100
Message-ID: <xhsmhtt9tfv7a.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
MIME-Version: 1.0
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: Hz6eqdwPvC4VycMOcC0wGO5K0ZeTa_NzpDiwQXN2mvU_1737381207
X-Mimecast-Originator: redhat.com
Content-Type: text/plain

On 17/01/25 09:15, Sean Christopherson wrote:
> On Fri, Jan 17, 2025, Valentin Schneider wrote:
>> On 14/01/25 13:13, Sean Christopherson wrote:
>> > On Tue, Jan 14, 2025, Valentin Schneider wrote:
>> >> +/**
>> >> + * is_kernel_noinstr_text - checks if the pointer address is located in the
>> >> + *                    .noinstr section
>> >> + *
>> >> + * @addr: address to check
>> >> + *
>> >> + * Returns: true if the address is located in .noinstr, false otherwise.
>> >> + */
>> >> +static inline bool is_kernel_noinstr_text(unsigned long addr)
>> >> +{
>> >> +	return addr >= (unsigned long)__noinstr_text_start &&
>> >> +	       addr < (unsigned long)__noinstr_text_end;
>> >> +}
>> >
>> > This doesn't do the right thing for modules, which matters because KVM can be
>> > built as a module on x86, and because context tracking understands transitions
>> > to GUEST mode, i.e. CPUs that are running in a KVM guest will be treated as not
>> > being in the kernel, and thus will have IPIs deferred.  If KVM uses a static key
>> > or branch between guest_state_enter_irqoff() and guest_state_exit_irqoff(), the
>> > patching code won't wait for CPUs to exit guest mode, i.e. KVM could theoretically
>> > use the wrong static path.
>>>
>> AFAICT guest_state_{enter,exit}_irqoff() are only used in noinstr functions
>> and thus such a static key usage should at the very least be caught and
>> warned about by objtool - when this isn't built as a module.
>
> That doesn't magically do the right thing though.  If KVM is built as a module,
> is_kernel_noinstr_text() will get false negatives even for static keys/branches
> that are annotaed as NOINSTR.

Quite so.

I've been looking at mod_mem_type & friends, I'm thinking adding a
MOD_NOINSTR_TEXT type might be overkill considering modules really
shouldn't be involved with early entry, KVM being the one exception.

Your suggestion to have a KVM-module-specific noinstr section sounds good
to me, I'll have a look at that.



From xen-devel-bounces@lists.xenproject.org Mon Jan 20 15:13:47 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Jan 2025 15:13:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.874971.1285298 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZtT4-0006BQ-5w; Mon, 20 Jan 2025 15:13:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 874971.1285298; Mon, 20 Jan 2025 15:13:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZtT4-0006BJ-38; Mon, 20 Jan 2025 15:13:34 +0000
Received: by outflank-mailman (input) for mailman id 874971;
 Mon, 20 Jan 2025 15:13:32 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=BOU1=UM=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tZtT2-0006BD-41
 for xen-devel@lists.xenproject.org; Mon, 20 Jan 2025 15:13:32 +0000
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com
 [2a00:1450:4864:20::32a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 19c177c7-d741-11ef-99a4-01e77a169b0f;
 Mon, 20 Jan 2025 16:13:27 +0100 (CET)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-43675b1155bso53042175e9.2
 for <xen-devel@lists.xenproject.org>; Mon, 20 Jan 2025 07:13:27 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4389041f7e9sm145903445e9.23.2025.01.20.07.13.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 20 Jan 2025 07:13:26 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 19c177c7-d741-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737386007; x=1737990807; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=xwvcWJEM2r93MIueVaqX5Gcfo90Ld3KonSEJsz4HUPo=;
        b=ZKwKg9F0UD2z2QxtdewmTqyDP7BGyISh1393BdfozjIJoh3S0/xxiIzRRYzfYu554F
         LW+GizJmBbv1Ag0D23Mxxra0S54UcCvgb8E2EKzyqZ0RodbFdOF8XNLNQzV79FowgSYP
         cBCSvK68nchmE7/V9/N3iKWpHD0pIyk18QdaXA9dBMff5z62oMnmtb8JoaJRzHe54UGH
         G3LPcF3pH7FIGVrfSpui04IKu8SQqz8rjH9LazhaZndAnqJeWlYDY7qefgEgCxfG0AMi
         fsGH1uDt42D5xbAet/xF+oGqJ+R79doK+tGBM9j6dSQVerAsLvm4PO4gZa7WD17Lim5N
         Qi7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737386007; x=1737990807;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=xwvcWJEM2r93MIueVaqX5Gcfo90Ld3KonSEJsz4HUPo=;
        b=WbGcng1zE3cqYz9BHxn0z4YngOwtL8PPDqUYrZBQdQjlNHpr8b9H0WeGvzwa1pDnM0
         zoNN/orbl80bm3Ku78CP67Aq9X4/7UTNE8OIa0LDCp1oe7l2pA44JxIwuztSUu3iXaFH
         vqlwJtBs6JqponY1DSA8Dfs803hw10H7uvMP/v6tub8QPYpI9sv+rSoGKVjcy66GvlFL
         Y+sq3tPOK8jxUZET94D8UC0SWw+sJ4Dg3RlBCxwRrsAVa/O4/Gi72Zfnkjfiwb9yfG+S
         1uVa2WGmbuhqtEz27x063oR4BsEKMcPIYI+yewBwb4zqin6yAj+CMiYV+QKxgxto2LSx
         AgnA==
X-Forwarded-Encrypted: i=1; AJvYcCUbrCmCqTibjvea1g/oJQA53c9zhlTkOTswj+njjNuxiAFQBKUU/6DpP3vIRISzWf5jFv7EGyIv4hA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxNli9Ds40WnhoOPnlIjF8g06pg9oq6KWHqIarGYqh1QCbeSkyd
	dxc1pzmc070bXOsNmtiT9mjXQGxQFfkkeSETBxvpUnsEaOtSoC1ykKOl+pPmiw==
X-Gm-Gg: ASbGnctxYvEk75KGk77hz/2qEPXOYjYmKy+lGF28eGYUjBOvGIpt1fzFFy12rJSRZkY
	aByNP7PXrQHMjLVXkYQv4kIvWhq5morKJ0IF3sCVWkuudC5iZQZoM6vpaNRXb6G9zKGbnfT2r7R
	bsGHgX7MAzocq+i/uOO0XaJ3NafLXs60Xz/Vbx+/A/cG3tGfgFF7wr00o4aifyHi4dEah5z2sEl
	N/7Is3SGNFrLfil0uvjIO31vuClbYpR1NzcdNKFhzV4X9iGPeg+htEBlmlwW4FySpls5zM6SkRy
	QpZ64O6SKlVfMlzUDUIV8rc3iB0qJ4RbTzVRGsSmgy1TseedScOL5cQ=
X-Google-Smtp-Source: AGHT+IFNNooqE/lUTeUnaQk5z1Hd+CDXjd7/gbFGlyaoq9sVP+jrz6LYzYKGq5RgZayAjS0aL1FkgA==
X-Received: by 2002:a05:600c:4fc1:b0:434:f218:e1a8 with SMTP id 5b1f17b1804b1-4389141c21cmr106100245e9.19.1737386007185;
        Mon, 20 Jan 2025 07:13:27 -0800 (PST)
Message-ID: <0ceaa04e-36ac-4099-8a84-977a08ba16a2@suse.com>
Date: Mon, 20 Jan 2025 16:13:25 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] xen/riscv: identify specific ISA supported by cpu
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Alistair Francis <alistair.francis@wdc.com>,
 Bob Eshleman <bobbyeshleman@gmail.com>, Connor Davis
 <connojdavis@gmail.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <0a6562ae1e22e3fe607054b33df3467c12d0b276.1736956861.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <0a6562ae1e22e3fe607054b33df3467c12d0b276.1736956861.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15.01.2025 17:36, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/arch/riscv/cpufeature.c
> @@ -0,0 +1,506 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Taken for Linux kernel v6.12-rc3 and modified by
> + * Oleksii Kurochko <oleksii.kurochko@gmail.com>:
> + *
> + * - Drop unconditional setting of {RISCV_ISA_EXT_ZICSR,
> + *   RISCV_ISA_EXT_ZIFENCEI, RISCV_ISA_EXT_ZICNTR, RISCV_ISA_EXT_ZIHPM} as they
> + *   are now part of the riscv,isa string.
> + * - Remove saving of the ISA for each CPU, only the common available ISA is
> + *   saved.
> + * - Remove ACPI-related code as ACPI is not supported by Xen.
> + * - Drop handling of elf_hwcap, since Xen does not provide hwcap to
> + *   userspace.
> + * - Replace of_cpu_device_node_get() API, which is not available in Xen,
> + *   with a combination of dt_for_each_child_node(), dt_device_type_is_equal(),
> + *   and dt_get_cpuid_from_node() to retrieve cpuid and riscv,isa in
> + *   riscv_fill_hwcap_from_isa_string().
> + * - Rename arguments of __RISCV_ISA_EXT_DATA() from _name to ext_name, and
> + *   _id to ext_id for clarity.
> + * - Replace instances of __RISCV_ISA_EXT_DATA with RISCV_ISA_EXT_DATA.
> + * - Replace instances of __riscv_isa_extension_available with
> + *   riscv_isa_extension_available for consistency. Also, update the type of
> + *   `bit` argument of riscv_isa_extension_available().
> + * - Redefine RISCV_ISA_EXT_DATA() to work only with ext_name and ext_id,
> + *   as other fields are not used in Xen currently.
> + * - Add check of first 4 letters of riscv,isa string to
> + *   riscv_isa_parse_string() as Xen doesn't do this check before so it is
> + *   necessary to check correctness of riscv,isa string. ( it should start with
> + *   rv{32,64} with taking into account lower case of "rv").
> + * - Drop an argument of riscv_fill_hwcap() and riscv_fill_hwcap_from_isa_string()
> + *   as it isn't used, at the moment.
> + * - Update the comment message about QEMU workaround.
> + * - s/pr_info/printk.

As said before - having this in the commit message is likely enough. Putting
it here as well is only risking for this to go stale (perhaps rather sooner
than later).

> + * Copyright (C) 2015 ARM Ltd.
> + * Copyright (C) 2017 SiFive
> + * Copyright (C) 2024 Vates
> + */
> +
> +#include <xen/bitmap.h>
> +#include <xen/ctype.h>
> +#include <xen/device_tree.h>
> +#include <xen/errno.h>
> +#include <xen/init.h>
> +#include <xen/lib.h>
> +#include <xen/sections.h>
> +
> +#include <asm/cpufeature.h>
> +
> +#ifdef CONFIG_ACPI
> +#error "cpufeature.c functions should be updated to support ACPI"
> +#endif
> +
> +struct riscv_isa_ext_data {
> +    unsigned int id;
> +    const char *name;
> +};
> +
> +#define RISCV_ISA_EXT_DATA(ext_name, ext_id)    \
> +{                                               \
> +    .id = ext_id,                               \
> +    .name = #ext_name,                          \
> +}
> +
> +/* Host ISA bitmap */
> +static __ro_after_init DECLARE_BITMAP(riscv_isa, RISCV_ISA_EXT_MAX);
> +
> +static int __init dt_get_cpuid_from_node(const struct dt_device_node *cpu)
> +{
> +    const __be32 *prop;
> +    unsigned int reg_len;
> +
> +    if ( dt_n_size_cells(cpu) != 0 )
> +        printk("cpu node `%s`: #size-cells %d\n",
> +               dt_node_full_name(cpu), dt_n_size_cells(cpu));

The call to dt_n_size_cells() is here really just for the printk()?

> +    prop = dt_get_property(cpu, "reg", &reg_len);
> +    if ( !prop )
> +    {
> +        printk("cpu node `%s`: has no reg property\n", dt_node_full_name(cpu));
> +        return -EINVAL;
> +    }
> +
> +    if ( reg_len < dt_cells_to_size(dt_n_addr_cells(cpu)) )
> +    {
> +        printk("cpu node `%s`: reg property too short\n",
> +               dt_node_full_name(cpu));
> +        return -EINVAL;
> +    }
> +
> +    return dt_read_paddr(prop, dt_n_addr_cells(cpu));

How come it is okay to (silently) truncate here from paddr_t to int?

> +}
> +
> +/*
> + * The canonical order of ISA extension names in the ISA string is defined in
> + * chapter 27 of the unprivileged specification.
> + *
> + * The specification uses vague wording, such as should, when it comes to
> + * ordering, so for our purposes the following rules apply:
> + *
> + * 1. All multi-letter extensions must be separated from other extensions by an
> + *    underscore.
> + *
> + * 2. Additional standard extensions (starting with 'Z') must be sorted after
> + *    single-letter extensions and before any higher-privileged extensions.
> + *
> + * 3. The first letter following the 'Z' conventionally indicates the most
> + *    closely related alphabetical extension category, IMAFDQLCBKJTPVH.
> + *    If multiple 'Z' extensions are named, they must be ordered first by
> + *    category, then alphabetically within a category.
> + *
> + * 4. Standard supervisor-level extensions (starting with 'S') must be listed
> + *    after standard unprivileged extensions.  If multiple supervisor-level
> + *    extensions are listed, they must be ordered alphabetically.
> + *
> + * 5. Standard machine-level extensions (starting with 'Zxm') must be listed
> + *    after any lower-privileged, standard extensions.  If multiple
> + *    machine-level extensions are listed, they must be ordered
> + *    alphabetically.
> + *
> + * 6. Non-standard extensions (starting with 'X') must be listed after all
> + *    standard extensions. If multiple non-standard extensions are listed, they
> + *    must be ordered alphabetically.
> + *
> + * An example string following the order is:
> + *    rv64imadc_zifoo_zigoo_zafoo_sbar_scar_zxmbaz_xqux_xrux
> + *
> + * New entries to this struct should follow the ordering rules described above.
> + *
> + * Extension name must be all lowercase ( according to device-tree binding )
> + * and strncmp() is used in match_isa_ext() to compare extension names instead
> + * of strncasecmp().
> + */
> +const struct riscv_isa_ext_data __initconst riscv_isa_ext[] = {
> +    RISCV_ISA_EXT_DATA(i, RISCV_ISA_EXT_i),
> +    RISCV_ISA_EXT_DATA(m, RISCV_ISA_EXT_m),
> +    RISCV_ISA_EXT_DATA(a, RISCV_ISA_EXT_a),
> +    RISCV_ISA_EXT_DATA(f, RISCV_ISA_EXT_f),
> +    RISCV_ISA_EXT_DATA(d, RISCV_ISA_EXT_d),
> +    RISCV_ISA_EXT_DATA(q, RISCV_ISA_EXT_q),
> +    RISCV_ISA_EXT_DATA(h, RISCV_ISA_EXT_h),
> +    RISCV_ISA_EXT_DATA(zicntr, RISCV_ISA_EXT_ZICNTR),
> +    RISCV_ISA_EXT_DATA(zicsr, RISCV_ISA_EXT_ZICSR),
> +    RISCV_ISA_EXT_DATA(zifencei, RISCV_ISA_EXT_ZIFENCEI),
> +    RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE),
> +    RISCV_ISA_EXT_DATA(zihpm, RISCV_ISA_EXT_ZIHPM),
> +    RISCV_ISA_EXT_DATA(zbb, RISCV_ISA_EXT_ZBB),
> +    RISCV_ISA_EXT_DATA(smaia, RISCV_ISA_EXT_SMAIA),
> +    RISCV_ISA_EXT_DATA(ssaia, RISCV_ISA_EXT_SSAIA),
> +};
> +
> +static const struct riscv_isa_ext_data __initconst required_extensions[] = {
> +    RISCV_ISA_EXT_DATA(zbb, RISCV_ISA_EXT_ZBB),
> +    RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE),
> +};

No Zicsr here?

> +static bool is_lowercase_extension_name(const char *str)
> +{
> +    if ( !str )
> +        return false;

This path doesn't look like it can actually be taken. Imo such checks
may make sense in non-static functions, but in static ones it is usually
clear enough that all callers pass in good pointers.

> +    for ( unsigned int i = 0; (str[i] != '\0') && (str[i] != '_'); i++ )
> +        if ( !islower(str[i]) )
> +            return false;
> +
> +    return true;
> +}
> +
> +static void __init match_isa_ext(const char *name, const char *name_end,
> +                                 unsigned long *bitmap)
> +{
> +    const size_t riscv_isa_ext_count = ARRAY_SIZE(riscv_isa_ext);
> +
> +    for ( unsigned int i = 0; i < riscv_isa_ext_count; i++ )
> +    {
> +        const struct riscv_isa_ext_data *ext = &riscv_isa_ext[i];
> +
> +        /*
> +         * `name` ( according to device tree binding ) and
> +         * `ext->name` ( according to initialization of riscv_isa_ext[]

Nit: There appears to be a missing closing parenthesis here. Plus in text
may I advise to omit blanks after the opening and before the closing
parenthesis? Imo this just makes it harder to read, even if only slightly.

> +         * elements must be all in lowercase.
> +         *
> +         * Just to be sure that it is true, ASSERT() are added.
> +         */
> +        ASSERT(is_lowercase_extension_name(name) &&
> +               is_lowercase_extension_name(ext->name));
> +
> +        if ( (name_end - name == strlen(ext->name)) &&
> +             !strncmp(name, ext->name, name_end - name) )
> +        {
> +            __set_bit(ext->id, bitmap);
> +            break;
> +        }
> +    }
> +}
> +
> +static int __init riscv_isa_parse_string(const char *isa,
> +                                         unsigned long *out_bitmap)
> +{
> +    /*
> +     * According to RISC-V device tree binding isa string must be all
> +     * lowercase.
> +     * To be sure that this is true, ASSERT below is added.
> +     */
> +    ASSERT(islower(isa[0]) && islower(isa[1]));

This looks a little odd to me when you have ...

> +    if ( (isa[0] != 'r') && (isa[1] != 'v') )
> +        return -EINVAL;

... this anyway.

> +#if defined(CONFIG_RISCV_32)
> +    if ( isa[2] != '3' && isa[3] != '2' )
> +        return -EINVAL;
> +#elif defined(CONFIG_RISCV_64)
> +    if ( isa[2] != '6' && isa[3] != '4' )
> +        return -EINVAL;
> +#else
> +    #error "unsupported RISC-V bitness"
> +#endif
> +
> +    isa += 4;
> +
> +    while ( *isa )
> +    {
> +        const char *ext = isa++;
> +        const char *ext_end = isa;
> +        bool ext_err = false;
> +
> +        switch ( *ext )
> +        {
> +        case 'x':
> +        case 'X':
> +            printk_once("Vendor extensions are ignored in riscv,isa."
> +                        "Use riscv,isa-extensions instead\n");

Interesting suggestion considering that doing so will end in a panic().

> +static int __init riscv_fill_hwcap_from_ext_list(void)
> +{
> +    const struct dt_device_node *cpus = dt_find_node_by_path("/cpus");
> +    const struct dt_device_node *cpu;
> +    int res = -EINVAL;
> +
> +    if ( !cpus )
> +    {
> +        printk("Missing /cpus node in the device tree?\n");
> +        return -EINVAL;
> +    }
> +
> +    dt_for_each_child_node(cpus, cpu)
> +    {
> +        const char *isa;
> +        int cpuid;
> +
> +        if ( !dt_device_type_is_equal(cpu, "cpu") )
> +            continue;
> +
> +        cpuid = dt_get_cpuid_from_node(cpu);
> +        if ( cpuid < 0 )
> +            continue;
> +
> +        if ( dt_property_read_string(cpu, "riscv,isa-extensions", &isa) )
> +        {
> +            printk("Unable to find \"riscv,isa-extensions\" devicetree entry "
> +                   "for cpu%d\n", cpuid);

This is DT's number space for CPUs, isn't it? Any use of cpu%d (or CPU%d) or
alike generally suggests the number is Xen's. This may want disambiguating
here.

> +static void __init riscv_fill_hwcap_from_isa_string(void)
> +{
> +    const struct dt_device_node *cpus = dt_find_node_by_path("/cpus");
> +    const struct dt_device_node *cpu;
> +
> +    if ( !cpus )
> +    {
> +        printk("Missing /cpus node in the device tree?\n");
> +        return;
> +    }
> +
> +    dt_for_each_child_node(cpus, cpu)
> +    {
> +        DECLARE_BITMAP(this_isa, RISCV_ISA_EXT_MAX);
> +        const char *isa;
> +        int cpuid;
> +
> +        if ( !dt_device_type_is_equal(cpu, "cpu") )
> +            continue;
> +
> +        cpuid = dt_get_cpuid_from_node(cpu);
> +        if ( cpuid < 0 )
> +            continue;
> +
> +        if ( dt_property_read_string(cpu, "riscv,isa", &isa) )
> +        {
> +            printk("Unable to find \"riscv,isa\" devicetree entry\n");
> +            continue;
> +        }

Interestingly you don't log the CPU number here. What's the deal?

> +bool riscv_isa_extension_available(const unsigned long *isa_bitmap,
> +                                   enum riscv_isa_ext_id bit)
> +{
> +    const unsigned long *bmap = (isa_bitmap) ? isa_bitmap : riscv_isa;

Since it helps readability, may I suggest

    const unsigned long *bmap = isa_bitmap ?: riscv_isa;

or even getting away without the local var altogether:

    if ( !isa_bitmap )
        isa_bitmap = riscv_isa;

?

> +void __init riscv_fill_hwcap(void)
> +{
> +    unsigned int i;
> +    size_t req_extns_amount = ARRAY_SIZE(required_extensions);
> +    bool all_extns_available = true;
> +
> +    int ret = riscv_fill_hwcap_from_ext_list();

I don't think there's a reason here to have a blank line in the middle
of declarations.

> +    if ( ret )
> +    {
> +        printk("Falling back to deprecated \"riscv,isa\"\n");
> +        riscv_fill_hwcap_from_isa_string();
> +    }

I continue to find it irritating that you first try a function you
know won't succeed (and will panic() if the DT item is actually there),
in order to the log yet another message about using something that's
deprecated. If this is deprecated, why don't we prefer (and hence
support) the mor modern approach?

> +    for ( i = 0; i < req_extns_amount; i++ )
> +    {
> +        const struct riscv_isa_ext_data ext = required_extensions[i];
> +
> +        if ( !riscv_isa_extension_available(NULL, ext.id) )
> +        {
> +            printk("Xen requires extension: %s\n", ext.name);
> +            all_extns_available = false;
> +        }
> +    }
> +
> +    if ( !all_extns_available )
> +        panic("Look why the extensions above are needed in booting.txt\n");

Where's this booting.txt? I don't think people should be made hunt it
down ...

> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/cpufeature.h
> @@ -0,0 +1,57 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef ASM__RISCV__CPUFEATURE_H
> +#define ASM__RISCV__CPUFEATURE_H
> +
> +#ifndef __ASSEMBLY__
> +
> +#include <xen/stdbool.h>
> +
> +/*
> + * These macros represent the logical IDs of each multi-letter RISC-V ISA
> + * extension and are used in the ISA bitmap. The logical IDs start from
> + * RISCV_ISA_EXT_BASE, which allows the 0-25 range to be reserved for single
> + * letter extensions and are used in enum riscv_isa_ext_id.
> + *
> + * New extensions should just be added to the bottom, rather than added
> + * alphabetically, in order to avoid unnecessary shuffling.
> + */
> +#define RISCV_ISA_EXT_BASE  26
> +
> +enum riscv_isa_ext_id {
> +    RISCV_ISA_EXT_a,
> +    RISCV_ISA_EXT_c,
> +    RISCV_ISA_EXT_d,
> +    RISCV_ISA_EXT_f,
> +    RISCV_ISA_EXT_h,
> +    RISCV_ISA_EXT_i,
> +    RISCV_ISA_EXT_m,
> +    RISCV_ISA_EXT_q,
> +    RISCV_ISA_EXT_v,
> +    RISCV_ISA_EXT_ZICNTR = RISCV_ISA_EXT_BASE,
> +    RISCV_ISA_EXT_ZICSR,
> +    RISCV_ISA_EXT_ZIFENCEI,
> +    RISCV_ISA_EXT_ZIHINTPAUSE,
> +    RISCV_ISA_EXT_ZIHPM,
> +    RISCV_ISA_EXT_ZBB,
> +    RISCV_ISA_EXT_SMAIA,
> +    RISCV_ISA_EXT_SSAIA,
> +    RISCV_ISA_EXT_MAX
> +};
> +
> +void riscv_fill_hwcap(void);
> +
> +bool riscv_isa_extension_available(const unsigned long *isa_bitmap,
> +                                   enum riscv_isa_ext_id bit);

Nit: "bit" is an implementation detail. Imo "id" would be more natural
to use for people considering whether to call this function in a given
situation.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 20 15:35:43 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Jan 2025 15:35:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.874984.1285308 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZtoQ-0000nj-1M; Mon, 20 Jan 2025 15:35:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 874984.1285308; Mon, 20 Jan 2025 15:35:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZtoP-0000nc-Tf; Mon, 20 Jan 2025 15:35:37 +0000
Received: by outflank-mailman (input) for mailman id 874984;
 Mon, 20 Jan 2025 15:35:37 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=BOU1=UM=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tZtoP-0000nU-9f
 for xen-devel@lists.xenproject.org; Mon, 20 Jan 2025 15:35:37 +0000
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com
 [2a00:1450:4864:20::335])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 30cefac5-d744-11ef-99a4-01e77a169b0f;
 Mon, 20 Jan 2025 16:35:35 +0100 (CET)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-435f8f29f8aso32896365e9.2
 for <xen-devel@lists.xenproject.org>; Mon, 20 Jan 2025 07:35:35 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-437c74c475csm206068965e9.20.2025.01.20.07.35.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 20 Jan 2025 07:35:34 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 30cefac5-d744-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737387334; x=1737992134; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=IvXlhcaAtilLlQfU3BTOUNloWLtSLhanA/kAgU+qBAI=;
        b=fJFzCQvsbkkkem4uZPt82FXtFzV2wp6f8JJcEYDHH/zM69sSlyacRiKhu8NICLxgFJ
         szgHbZ2nbLs0Bi1nPWcgXoyzUbSUgxtv8bJ44szJ3dnaEZXw0j9BBMY5R7M17y5abCeQ
         Wf0IGnrRGsH+sgBlkL7IKRpI60NvcBGECtxIku77NzgK7kpz58SIskdbFfZz7IKMwQ3A
         U7F4agcmt3CUZ0uYS+7IFOrltGxp0YsgZmqEyMbbARig4l9OEi8wl+92nFLVDYMGfraJ
         qn/50qV+C4VjawcnnGAe+wWo9Vit1Q51CV08Kvc1SHo/l5MCCPa4uUI7ncJOmt+I6MDE
         t6DA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737387334; x=1737992134;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=IvXlhcaAtilLlQfU3BTOUNloWLtSLhanA/kAgU+qBAI=;
        b=TiM2uY/ujqP5nVbdB5hGgn0prelms5HXqghiW7IshpfDfBzi1HIzl8Qmo6sn5U8qTZ
         4SjuYf+XsIezN/tcSiWlL2pBRFxG2N1CsZ6GNvdtPkf+eyxYt+GhsLoce4umQ+gEHfaF
         Vnar1A3Ksixk0Rqx6DGHW+uE2VLa6ed4AcUgaNlASspJgh5T8LxNETgjV+CNb47kCRea
         9W2kINDmo5TrVcHCRUBq9bsGoj0v0vAWJPV2T3+Hczz6EbQRaZCIb9y3sfQoG0OTqJoR
         xf1AF74UD+haoSnIEzFWQO+KHF8YWhSW+z4Q+krePlkKJku4gmfyQ14pn5syWFe5NjVe
         dk7Q==
X-Forwarded-Encrypted: i=1; AJvYcCWgNsxhh5F4S3ieBTjzth73swm2BmjKeYgWVjYE8kYdk9Oxs8chFrjNg5LmPHGTNgHor4TVOR6wYcs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxQbyR62n1KsfwuVrIP8e6UKWNW7KgHp7NoDAl4cgL74hZc3r9W
	Sxmg1K35bSwlpS5LpFR21x8RrZk+HrA7HXmTfjTM6xG4Pjg33h61tbcR2MptKA==
X-Gm-Gg: ASbGncsFAoPNA4i9SD5lPzBmPkE1axSRrWqeTC1nfYAKSNVDGNboxjzY01DjNP2A0xA
	ZNfpxyzOw3m+K6EMh1i9d0g02ZMOJrCeMp8mt15n/yPKoRy0eO8Zwxv8E+wj96TuruSln5xtMfM
	aZfdyv4+Oo5PyPRR8X6KyEBFhjM3fY+mPXa/6sU+Bn32R0CePq8YSJk+7jMeNSQOPxiCJZBfpeT
	JcAVZwW264Qw9Nsb2POKDdZ7B7OyH2gFUWk9YPWnOGmJFThvHhRFCvyGCK8Vc8gvIQryzcUjLHy
	a8QX2CvuZon8CRmlZprXSmjL+/TgGKZR5tvz6qTDUqmZugpoH1gGW9k=
X-Google-Smtp-Source: AGHT+IE5ipjHq7F9TG/oz+jCJmBEWQtDtV1iDJltR/psCLN2WsjGGTfT+/aUO344TL0m0x4V0Df4jQ==
X-Received: by 2002:a05:600c:4e4f:b0:434:f767:68ea with SMTP id 5b1f17b1804b1-438913bf92cmr148742105e9.5.1737387334505;
        Mon, 20 Jan 2025 07:35:34 -0800 (PST)
Message-ID: <3e535294-8e68-476f-9958-d8c870f85f7c@suse.com>
Date: Mon, 20 Jan 2025 16:35:33 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5] vpci: Add resizable bar support
To: Jiqian Chen <Jiqian.Chen@amd.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>, Huang Rui <ray.huang@amd.com>,
 xen-devel@lists.xenproject.org
References: <20250114032636.3698383-1-Jiqian.Chen@amd.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250114032636.3698383-1-Jiqian.Chen@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14.01.2025 04:26, Jiqian Chen wrote:
> --- /dev/null
> +++ b/xen/drivers/vpci/rebar.c
> @@ -0,0 +1,135 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (C) 2024 Advanced Micro Devices, Inc. All Rights Reserved.

Nit: This has now gone stale.

> + * Author: Jiqian Chen <Jiqian.Chen@amd.com>
> + */
> +
> +#include <xen/sched.h>
> +#include <xen/vpci.h>
> +
> +static void cf_check rebar_ctrl_write(const struct pci_dev *pdev,
> +                                      unsigned int reg,
> +                                      uint32_t val,
> +                                      void *data)
> +{
> +    unsigned int index;
> +    struct vpci_bar *bar = data;
> +    uint64_t size = PCI_REBAR_CTRL_SIZE(val);
> +
> +    if ( bar->enabled )
> +    {
> +        /*
> +         * Refuse to resize a BAR while memory decoding is enabled, as
> +         * otherwise the size of the mapped region in the p2m would become
> +         * stale with the newly set BAR size, and the position of the BAR
> +         * would be reset to undefined.  Note the PCIe specification also
> +         * forbids resizing a BAR with memory decoding enabled.
> +         */
> +        if ( size != bar->size )
> +            gprintk(XENLOG_ERR,
> +                    "%pp: refuse to resize BAR with memory decoding enabled\n",
> +                    &pdev->sbdf);
> +        return;
> +    }
> +
> +    if ( !((size >> PCI_REBAR_CTRL_SIZE_BIAS) & bar->resizable_sizes) )
> +        gprintk(XENLOG_WARNING,
> +                "%pp: new size %#lx is not supported by hardware\n",
> +                &pdev->sbdf, size);
> +
> +    pci_conf_write32(pdev->sbdf, reg, val);
> +
> +    index = pci_conf_read32(pdev->sbdf, reg) & PCI_REBAR_CTRL_BAR_IDX;
> +    pci_size_mem_bar(pdev->sbdf, PCI_BASE_ADDRESS_0 + index * 4, &bar->addr,
> +                     &bar->size, ((index == PCI_HEADER_NORMAL_NR_BARS - 1) ?
> +                                  PCI_BAR_LAST : 0));

Nit: Imo it's unhelpful to the reader if you put multiple arguments on a single
line, when the final one then needs wrapping across lines. (Putting multiple
arguments on a single line is fine of course when they fully fit.)

> --- a/xen/include/xen/pci_regs.h
> +++ b/xen/include/xen/pci_regs.h
> @@ -459,6 +459,7 @@
>  #define PCI_EXT_CAP_ID_ARI	14
>  #define PCI_EXT_CAP_ID_ATS	15
>  #define PCI_EXT_CAP_ID_SRIOV	16
> +#define PCI_EXT_CAP_ID_REBAR	21	/* Resizable BAR */
>  
>  /* Advanced Error Reporting */
>  #define PCI_ERR_UNCOR_STATUS	4	/* Uncorrectable Error Status */
> @@ -541,6 +542,19 @@
>  #define  PCI_VNDR_HEADER_REV(x)	(((x) >> 16) & 0xf)
>  #define  PCI_VNDR_HEADER_LEN(x)	(((x) >> 20) & 0xfff)
>  
> +/* Resizable BARs */
> +#define PCI_REBAR_CAP(n)	(4 + 8 * (n))	/* capability register */
> +#define  PCI_REBAR_CAP_SIZES_MASK	0xFFFFFFF0U	/* supported BAR sizes in CAP */
> +#define PCI_REBAR_CTRL(n)	(8 + 8 * (n))	/* control register */
> +#define  PCI_REBAR_CTRL_BAR_IDX		0x00000007	/* BAR index */
> +#define  PCI_REBAR_CTRL_NBAR_MASK	0x000000E0	/* # of resizable BARs */
> +#define  PCI_REBAR_CTRL_BAR_SIZE	0x00003F00	/* BAR size */
> +#define  PCI_REBAR_CTRL_SIZES_MASK	0xFFFF0000U	/* supported BAR sizes in CTRL */
> +#define  PCI_REBAR_CTRL_SIZE_BIAS	20
> +#define  PCI_REBAR_CTRL_SIZE(v) \
> +            (1UL << (MASK_EXTR(v, PCI_REBAR_CTRL_BAR_SIZE) \
> +                     + PCI_REBAR_CTRL_SIZE_BIAS))

On x86 (being 64-bit only) and Arm64 1UL may be good enough here, but
I expect we'll need 1ULL for any 32-bit architecture.

Plus, as indicated before, these two auxiliary #define-s would imo
better be separated from those directly pertaining to the control
register fields (and then also not be padded like those).

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 20 16:09:53 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Jan 2025 16:09:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.874992.1285318 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZuLR-0005UC-H0; Mon, 20 Jan 2025 16:09:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 874992.1285318; Mon, 20 Jan 2025 16:09:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZuLR-0005U5-DN; Mon, 20 Jan 2025 16:09:45 +0000
Received: by outflank-mailman (input) for mailman id 874992;
 Mon, 20 Jan 2025 16:09: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
 <SRS0=UHT9=UM=redhat.com=vschneid@srs-se1.protection.inumbo.net>)
 id 1tZuLQ-0005Tz-Pa
 for xen-devel@lists.xenproject.org; Mon, 20 Jan 2025 16:09:44 +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 f48f7a44-d748-11ef-99a4-01e77a169b0f;
 Mon, 20 Jan 2025 17:09:42 +0100 (CET)
Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com
 [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-107-8_LS9IIPM5KAgYCe1zV-Mw-1; Mon, 20 Jan 2025 11:09:39 -0500
Received: by mail-wr1-f72.google.com with SMTP id
 ffacd0b85a97d-38a873178f2so2320517f8f.1
 for <xen-devel@lists.xenproject.org>; Mon, 20 Jan 2025 08:09:39 -0800 (PST)
Received: from vschneid-thinkpadt14sgen2i.remote.csb
 (213-44-141-166.abo.bbox.fr. [213.44.141.166])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38bf3221b70sm10695813f8f.26.2025.01.20.08.09.34
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 20 Jan 2025 08:09:37 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f48f7a44-d748-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1737389381;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=SNeDTVMDd6LFz2Ibm+JZz5IT863oQDJPOaC5/U8lcJk=;
	b=YCuIi2gqY27/RenYo+i67O1JK7ekVse6cs1fAn7xO6n6ukpSgzz3wokTwcvwoSIDPChQFO
	yupdrm0+05XyuGVby5P4zH4FFDrt382SGWD+3X6j1lkD4aqbEDrQBw4NKoLCHKliqBmMj5
	WCxV8GAHEnJFtnnMaRdblDg5U18r8xM=
X-MC-Unique: 8_LS9IIPM5KAgYCe1zV-Mw-1
X-Mimecast-MFC-AGG-ID: 8_LS9IIPM5KAgYCe1zV-Mw
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737389378; x=1737994178;
        h=content-transfer-encoding:mime-version:message-id:date:references
         :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=uPYF3/ytKmNcBW6xY8UN6OXUapKiaxgyBXzq3dB0L9c=;
        b=nditCq6lK08+KZb1wgmp56msNVReaZ2stKnzRiOk2eFmtTZiKXY3sXsQWZbv25veL4
         4qVMgGQGniCu2URqO6vCG9P5qctfNhZO78Qe+BOYHs+UmW8GbwwlImBWDQzss+0uQbYN
         9f7g4PzhN7jwYd7B2znYOsLcfmrqT9DMZTa+J/g3k9DS11V2W2Vk2rO2V95Bums/Bp6S
         4tV/m3unvnpDN9/ntoPCiRL1/em8+P98TLFYOJjQWynnaW5G76VS5APckwA66LcPOYgx
         TRsMFiwktr39GwozxmQAAk8JCTiipTZpzYBEgHp8aGDD+Jh/0U0NpHYsjoOZCaKTiLoG
         4Dlg==
X-Forwarded-Encrypted: i=1; AJvYcCXBnpOIy3bZ8q4zXGX6m3ReBvwlANulOIKKAAeWYoHosI44HF7UGFZ8I2kS8P+sos61MXS4HEoknG8=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx9DY4dkvA6VA3D0US0ePp8e5M2dyrG9pBCrEeLibDsrsAW1lD1
	PqYimRIyGbkLBIAbTn+N8XZMQ5OGJt384ckJL/eiofATDoEkLPBQggkafGUF/MzPXcv92qenz3E
	n4muxMwtIrdUWhqaN5Ci2DPHZwkoMYU+Mfw+Wex6oHH9gYp2hBkihSjT1ok1WFCa1
X-Gm-Gg: ASbGncsGzlDApXm8JZRkAD3wDj/Awox/B394jfNNXSOBNEMuhOzNtOm45MRyczjWFZJ
	T+e/I9H1d5M5P+8Mph/KFC77Dvn12C7LdxKvB+3eMZCagvg9wV72VVCEiRSLM7RXAbqZ195s1F+
	9tO1UxlvdvQbAMI+RcBqYC56KWtrHmFchxcA1WihMtegfCXj3t4dEhzv7B9r0nD6vonq0jpXsuP
	4MZKLIHoElkvtT2rIZgIfWQmuMGmGoLkGyQ8J6fh26DrrQVcJbYS2wYg+wYAxCXj6ZQ7ygz/E+2
	2qo1r2EaY5D8/i3Zx8J/IRwxdaAOnnSfo35SnqQfrUj77CggzRceU4k=
X-Received: by 2002:adf:f682:0:b0:38b:e26d:ea0b with SMTP id ffacd0b85a97d-38bf566c314mr10592139f8f.25.1737389378238;
        Mon, 20 Jan 2025 08:09:38 -0800 (PST)
X-Google-Smtp-Source: AGHT+IE7jMmKmijGDhYJpj3v2AzDeWwh7lxfHaye7x+JEw9SklvyOVZq+Wb4Niy5wxwqRIeZEeA2rg==
X-Received: by 2002:adf:f682:0:b0:38b:e26d:ea0b with SMTP id ffacd0b85a97d-38bf566c314mr10592030f8f.25.1737389377661;
        Mon, 20 Jan 2025 08:09:37 -0800 (PST)
From: Valentin Schneider <vschneid@redhat.com>
To: Uladzislau Rezki <urezki@gmail.com>
Cc: Uladzislau Rezki <urezki@gmail.com>, Jann Horn <jannh@google.com>,
 linux-kernel@vger.kernel.org, x86@kernel.org,
 virtualization@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
 loongarch@lists.linux.dev, linux-riscv@lists.infradead.org,
 linux-perf-users@vger.kernel.org, xen-devel@lists.xenproject.org,
 kvm@vger.kernel.org, linux-arch@vger.kernel.org, rcu@vger.kernel.org,
 linux-hardening@vger.kernel.org, linux-mm@kvack.org,
 linux-kselftest@vger.kernel.org, bpf@vger.kernel.org,
 bcm-kernel-feedback-list@broadcom.com, Juergen Gross <jgross@suse.com>,
 Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov
 <alexey.amakhalov@broadcom.com>, Russell King <linux@armlinux.org.uk>,
 Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>,
 Huacai Chen <chenhuacai@kernel.org>, WANG Xuerui <kernel@xen0n.name>, Paul
 Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>,
 Albert Ou <aou@eecs.berkeley.edu>, Thomas Gleixner <tglx@linutronix.de>,
 Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Dave
 Hansen <dave.hansen@linux.intel.com>, "H. Peter Anvin" <hpa@zytor.com>,
 Peter Zijlstra <peterz@infradead.org>, Arnaldo Carvalho de Melo
 <acme@kernel.org>, Namhyung Kim <namhyung@kernel.org>, Mark Rutland
 <mark.rutland@arm.com>, Alexander Shishkin
 <alexander.shishkin@linux.intel.com>, Jiri Olsa <jolsa@kernel.org>, Ian
 Rogers <irogers@google.com>, Adrian Hunter <adrian.hunter@intel.com>,
 "Liang, Kan" <kan.liang@linux.intel.com>, Boris Ostrovsky
 <boris.ostrovsky@oracle.com>, Josh Poimboeuf <jpoimboe@kernel.org>, Pawan
 Gupta <pawan.kumar.gupta@linux.intel.com>, Sean Christopherson
 <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, Andy Lutomirski
 <luto@kernel.org>, Arnd Bergmann <arnd@arndb.de>, Frederic Weisbecker
 <frederic@kernel.org>, "Paul E. McKenney" <paulmck@kernel.org>, Jason
 Baron <jbaron@akamai.com>, Steven Rostedt <rostedt@goodmis.org>, Ard
 Biesheuvel <ardb@kernel.org>, Neeraj Upadhyay
 <neeraj.upadhyay@kernel.org>, Joel Fernandes <joel@joelfernandes.org>,
 Josh Triplett <josh@joshtriplett.org>, Boqun Feng <boqun.feng@gmail.com>,
 Mathieu Desnoyers <mathieu.desnoyers@efficios.com>, Lai Jiangshan
 <jiangshanlai@gmail.com>, Zqiang <qiang.zhang1211@gmail.com>, Juri Lelli
 <juri.lelli@redhat.com>, Clark Williams <williams@redhat.com>, Yair
 Podemsky <ypodemsk@redhat.com>, Tomas Glozar <tglozar@redhat.com>, Vincent
 Guittot <vincent.guittot@linaro.org>, Dietmar Eggemann
 <dietmar.eggemann@arm.com>, Ben Segall <bsegall@google.com>, Mel Gorman
 <mgorman@suse.de>, Kees Cook <kees@kernel.org>, Andrew Morton
 <akpm@linux-foundation.org>, Christoph Hellwig <hch@infradead.org>, Shuah
 Khan <shuah@kernel.org>, Sami Tolvanen <samitolvanen@google.com>, Miguel
 Ojeda <ojeda@kernel.org>, Alice Ryhl <aliceryhl@google.com>, "Mike
 Rapoport (Microsoft)" <rppt@kernel.org>, Samuel Holland
 <samuel.holland@sifive.com>, Rong Xu <xur@google.com>, Nicolas Saenz
 Julienne <nsaenzju@redhat.com>, Geert Uytterhoeven <geert@linux-m68k.org>,
 Yosry Ahmed <yosryahmed@google.com>, "Kirill A. Shutemov"
 <kirill.shutemov@linux.intel.com>, "Masami Hiramatsu (Google)"
 <mhiramat@kernel.org>, Jinghao Jia <jinghao7@illinois.edu>, Luis
 Chamberlain <mcgrof@kernel.org>, Randy Dunlap <rdunlap@infradead.org>,
 Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: Re: [PATCH v4 29/30] x86/mm, mm/vmalloc: Defer
 flush_tlb_kernel_range() targeting NOHZ_FULL CPUs
In-Reply-To: <Z44wSJTXknQVKWb0@pc636>
References: <20250114175143.81438-1-vschneid@redhat.com>
 <20250114175143.81438-30-vschneid@redhat.com>
 <CAG48ez1Mh+DOy0ysOo7Qioxh1W7xWQyK9CLGNU9TGOsLXbg=gQ@mail.gmail.com>
 <xhsmh34hhh37q.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
 <Z4qBMqcMg16p57av@pc636>
 <xhsmhwmetfk9d.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
 <Z44wSJTXknQVKWb0@pc636>
Date: Mon, 20 Jan 2025 17:09:34 +0100
Message-ID: <xhsmhr04xfow1.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
MIME-Version: 1.0
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: 1VxRLfKOh_hiPXpwwouRVcP6w-GXnGZyknx6S_2iY98_1737389378
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 20/01/25 12:15, Uladzislau Rezki wrote:
> On Fri, Jan 17, 2025 at 06:00:30PM +0100, Valentin Schneider wrote:
>> On 17/01/25 17:11, Uladzislau Rezki wrote:
>> > On Fri, Jan 17, 2025 at 04:25:45PM +0100, Valentin Schneider wrote:
>> >> On 14/01/25 19:16, Jann Horn wrote:
>> >> > On Tue, Jan 14, 2025 at 6:51=E2=80=AFPM Valentin Schneider <vschnei=
d@redhat.com> wrote:
>> >> >> vunmap()'s issued from housekeeping CPUs are a relatively common s=
ource of
>> >> >> interference for isolated NOHZ_FULL CPUs, as they are hit by the
>> >> >> flush_tlb_kernel_range() IPIs.
>> >> >>
>> >> >> Given that CPUs executing in userspace do not access data in the v=
malloc
>> >> >> range, these IPIs could be deferred until their next kernel entry.
>> >> >>
>> >> >> Deferral vs early entry danger zone
>> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> >> >>
>> >> >> This requires a guarantee that nothing in the vmalloc range can be=
 vunmap'd
>> >> >> and then accessed in early entry code.
>> >> >
>> >> > In other words, it needs a guarantee that no vmalloc allocations th=
at
>> >> > have been created in the vmalloc region while the CPU was idle can
>> >> > then be accessed during early entry, right?
>> >>
>> >> I'm not sure if that would be a problem (not an mm expert, please do
>> >> correct me) - looking at vmap_pages_range(), flush_cache_vmap() isn't
>> >> deferred anyway.
>> >>
>> >> So after vmapping something, I wouldn't expect isolated CPUs to have
>> >> invalid TLB entries for the newly vmapped page.
>> >>
>> >> However, upon vunmap'ing something, the TLB flush is deferred, and th=
us
>> >> stale TLB entries can and will remain on isolated CPUs, up until they
>> >> execute the deferred flush themselves (IOW for the entire duration of=
 the
>> >> "danger zone").
>> >>
>> >> Does that make sense?
>> >>
>> > Probably i am missing something and need to have a look at your patche=
s,
>> > but how do you guarantee that no-one map same are that you defer for T=
LB
>> > flushing?
>> >
>>
>> That's the cool part: I don't :')
>>
> Indeed, sounds unsafe :) Then we just do not need to free areas.
>
>> For deferring instruction patching IPIs, I (well Josh really) managed to
>> get instrumentation to back me up and catch any problematic area.
>>
>> I looked into getting something similar for vmalloc region access in
>> .noinstr code, but I didn't get anywhere. I even tried using emulated
>> watchpoints on QEMU to watch the whole vmalloc range, but that went abou=
t
>> as well as you could expect.
>>
>> That left me with staring at code. AFAICT the only vmap'd thing that is
>> accessed during early entry is the task stack (CONFIG_VMAP_STACK), which
>> itself cannot be freed until the task exits - thus can't be subject to
>> invalidation when a task is entering kernelspace.
>>
>> If you have any tracing/instrumentation suggestions, I'm all ears (eyes?=
).
>>
> As noted before, we defer flushing for vmalloc. We have a lazy-threshold
> which can be exposed(if you need it) over sysfs for tuning. So, we can ad=
d it.
>

In a CPU isolation / NOHZ_FULL context, isolated CPUs will be running a
single userspace application that will never enter the kernel, unless
forced to by some interference (e.g. IPI sent from a housekeeping CPU).

Increasing the lazy threshold would unfortunately only delay the
interference - housekeeping CPUs are free to run whatever, and so they will
eventually cause the lazy threshold to be hit and IPI all the CPUs,
including the isolated/NOHZ_FULL ones.

I was thinking maybe we could subdivide the vmap space into two regions
with their own thresholds, but a task may allocate/vmap stuff while on a HK
CPU and be moved to an isolated CPU afterwards, and also I still don't have
any strong guarantee about what accesses an isolated CPU can do in its
early entry code :(

> --
> Uladzislau Rezki



From xen-devel-bounces@lists.xenproject.org Mon Jan 20 16:20:17 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Jan 2025 16:20:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875000.1285327 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZuVS-00082W-Cv; Mon, 20 Jan 2025 16:20:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875000.1285327; Mon, 20 Jan 2025 16:20:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZuVS-00082P-A4; Mon, 20 Jan 2025 16:20:06 +0000
Received: by outflank-mailman (input) for mailman id 875000;
 Mon, 20 Jan 2025 16:20:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=BOU1=UM=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tZuVQ-0007UB-Oh
 for xen-devel@lists.xenproject.org; Mon, 20 Jan 2025 16:20:04 +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 65b636df-d74a-11ef-99a4-01e77a169b0f;
 Mon, 20 Jan 2025 17:20:00 +0100 (CET)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-38a8b35e168so3230353f8f.1
 for <xen-devel@lists.xenproject.org>; Mon, 20 Jan 2025 08:20:00 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38bf3275995sm10976994f8f.74.2025.01.20.08.19.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 20 Jan 2025 08:19:59 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 65b636df-d74a-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737390000; x=1737994800; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=MVeHsKo51et0p2xO0kVBUEFVFau8Z9G3ZPS/uI+xbf4=;
        b=LKkB7Z4iTnfOAWl+Zof+YRnqD7cHHP2R3LRhpMW9P5jUySMMTIohqMsPk+0DuXVSWI
         xBk7fWH/AMXX3ea/10y1vzaEfuUIUUj+QRS8blj0LSLzTNU18o62EYSDIxb6bd5WzlAA
         9E0OmJJtg7cAHVKrw5XK12Tbc53FInpqah9CAlP7d0/oqaRyKCQY25Ut1Xf/dnfeWbuc
         FCKkSzq0SXquAe3fE3reP6+f45O+DQLahes5NrDp0Ts1wJ83nMWln8uyEio60SEZsfDF
         ZTV5fuB0aTFfJ0gfZSL9RKxaqNmqMWh88lKnhAAnBtjX6wt1RzZZ/kvbmIH8a7pISKd3
         FV4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737390000; x=1737994800;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=MVeHsKo51et0p2xO0kVBUEFVFau8Z9G3ZPS/uI+xbf4=;
        b=mL0M3QlXM1/H0YSJWgP0Xx/bbUrPyG54HbNMoF7RNW4D3u3RFP2S8OaC/r3iPmcf8w
         Uqr2vb7RV1NgdYKrRU5lI78px0Yxg7zGtOw40ZGTjP/1x5jRJBsmy1SfgsToBaBgg6hc
         c3JM1ntD7LvWTdv0I4H6UK07GI2ekjSX0vxcDuDfip6qHHEV7EYYigVMojb1dsGyjVzR
         vWKyWGgbgHDbu+YTW71QtgB+TOTMhlEvQhdfVUswunhcZQ9UEboxscK2ixY7r+w4Fve4
         DsfYYS6+M4zBjIHA6vTOsLhxPpyROAs28Wp/XvI/Y9S1Cw0VSUId/TKvuMuGiXCiaPXg
         C2Hg==
X-Forwarded-Encrypted: i=1; AJvYcCVTVq8bD8vJLagfpvsTQpTU/+nF06g6GASKA+7yJ+0cXx5lPyzn2orIhNGEPmY8VwxfET0ml8I9RNs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwHpGLtcLtZHUiqoREMT57ocXLL0muH4mpycNkRcMtDeZGk9iuh
	zI2f4x+e4+gllrEOl/WcLvrEPt+Df7ns26etF/xi7NTVyqB/o3+yrOs4urxHIg==
X-Gm-Gg: ASbGncseGjsbQhAlFHIsVmdPb3RL/0+FOIJyE7+jonoJ1NfTsnuBY5feB/lkrJl8DNm
	hpFq644QXj+12q8gSw7mDQ51LzxkzziBGfTvrxJZedUMBWE131B/XfQnUkIyr3MsQB4ZWmCLqGh
	8FxwflxZQeu2ukOYcTtIbDYrMJauZPevXs1ru634LjIkY7VRxVvWN3opA1JEEyeGRyXZMbt8m0s
	59NI1cljivRAZiLowh4FOowWSjKTtzvkhAqRKis3NtH8KONIo+u5HhgYdp9aTD5AmEZJ6YHRWRr
	pmhYwmPOp5mOo4ogflnX9HHe2GMR/2PpWJZpQ/+wMvkIIBtgl2Er/9s=
X-Google-Smtp-Source: AGHT+IEf8xex0q9+g2tukb4jwd6unXLdA5S1EzhyQHd0ONN6mmPWvORDv5h6d7nR+kWPrbBElCjGtw==
X-Received: by 2002:a5d:6da1:0:b0:38b:ee01:a5b with SMTP id ffacd0b85a97d-38bf5ae2a66mr10886574f8f.15.1737390000044;
        Mon, 20 Jan 2025 08:20:00 -0800 (PST)
Message-ID: <52aa648a-0442-4d99-a423-32cb1de72d1c@suse.com>
Date: Mon, 20 Jan 2025 17:19:58 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v2 10/10] x86/hvm: Enable XSAVES LBR save/restore
To: Tu Dinh <ngoc-tu.dinh@vates.tech>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Juergen Gross <jgross@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20250102084413.102-1-ngoc-tu.dinh@vates.tech>
 <20250102084413.102-11-ngoc-tu.dinh@vates.tech>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250102084413.102-11-ngoc-tu.dinh@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 02.01.2025 09:45, Tu Dinh wrote:
> Add a new save code type CPU_XSAVES_CODE containing a compressed XSAVES
> image.
> 
> Signed-off-by: Tu Dinh <ngoc-tu.dinh@vates.tech>

I'm afraid this way too little of a description here. First unanswered
question would be why it is that we need a new save code in the first
place. Second question then would be what the interaction is when both
old and new save records are present. After all aiui ...

> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -1238,6 +1238,36 @@ static int cf_check hvm_save_cpu_xsave_states(
>      return 0;
>  }
>  
> +#define HVM_CPU_XSAVES_SIZE(xcr0) (offsetof(struct hvm_hw_cpu_xsave, \
> +                                            save_area) + \
> +                                   xstate_compressed_size(xcr0))
> +
> +static int cf_check hvm_save_cpu_xsaves_states(
> +    struct vcpu *v, hvm_domain_context_t *h)
> +{
> +    struct hvm_hw_cpu_xsave *ctxt;
> +    unsigned int size;
> +    int err;
> +
> +    if ( !xsave_enabled(v) )
> +        return 0;   /* do nothing */
> +
> +    size = HVM_CPU_XSAVES_SIZE(v->arch.xcr0_accum);
> +    err = _hvm_init_entry(h, CPU_XSAVES_CODE, v->vcpu_id, size);
> +    if ( err )
> +        return err;
> +
> +    ctxt = (struct hvm_hw_cpu_xsave *)&h->data[h->cur];
> +    h->cur += size;
> +    ctxt->xfeature_mask = xfeature_mask;
> +    ctxt->xcr0 = v->arch.xcr0;
> +    ctxt->xcr0_accum = v->arch.xcr0_accum;
> +
> +    memcpy(&ctxt->save_area, v->arch.xsave_area, size);
> +
> +    return 0;
> +}

... you save all states under this new code, not just the XSS-controlled
ones. Plus you're going through all of this even if there are no XSS-
controlled components, i.e. in particular also when there's no XSAVES
support in hardware. This way you then end up saving twice the exact
same data, just differently arranged.

> --- a/xen/arch/x86/xstate.c
> +++ b/xen/arch/x86/xstate.c
> @@ -946,8 +946,7 @@ int validate_xstate(const struct domain *d, uint64_t xcr0, uint64_t xcr0_accum,
>           !valid_xcr0(xcr0_accum) )
>          return -EINVAL;
>  
> -    if ( (xcr0_accum & ~xfeature_mask) ||
> -         hdr->xcomp_bv )
> +    if ( xcr0_accum & ~xfeature_mask )
>          return -EOPNOTSUPP;
>  
>      for ( i = 0; i < ARRAY_SIZE(hdr->reserved); ++i )

Can you really merely delete the check? Don't you need to validate
non-zero ->xcomp_bv then instead?

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 20 16:39:06 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Jan 2025 16:39:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875011.1285338 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZunl-0001z9-1G; Mon, 20 Jan 2025 16:39:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875011.1285338; Mon, 20 Jan 2025 16:39:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZunk-0001z2-TL; Mon, 20 Jan 2025 16:39:00 +0000
Received: by outflank-mailman (input) for mailman id 875011;
 Mon, 20 Jan 2025 16:38:59 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=BOU1=UM=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tZunj-0001yw-2h
 for xen-devel@lists.xenproject.org; Mon, 20 Jan 2025 16:38:59 +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 0b8e150b-d74d-11ef-a0e4-8be0dac302b0;
 Mon, 20 Jan 2025 17:38:58 +0100 (CET)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-438a39e659cso13046205e9.2
 for <xen-devel@lists.xenproject.org>; Mon, 20 Jan 2025 08:38: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
 5b1f17b1804b1-438904084e7sm146023155e9.6.2025.01.20.08.38.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 20 Jan 2025 08:38:57 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 0b8e150b-d74d-11ef-a0e4-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737391137; x=1737995937; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=I8acPMMNfBa5yJgbhB9KB8Wf6+4ucs4xk8J5nrdK9WA=;
        b=bR5mY+aDU/fd3JTFo/P6ApF1KiEa64CFqaIevoa1Mt8xX0Ql/yRQ5Jyv1rsgV60t9L
         FgAkwcqR65KlqML/sN0lUUsc+9vdU7dlpA/fyNYt/zz5NPfC0PCzvI4lXmEkKWBbvRbh
         Pnc+cP9XavzJDI7/MlyIK1L39wKVVe/rUvGXg301cfRMG2YCGlkF+gyUcyComSJIrZZg
         2SmQ/nyDFBbfvB+x8+rRBppRs7ydpP4fChRRaeB5dkNJfGWA1AuWVCtCE5EjxuIftXiM
         7eSuRbdE4sszKPNOHLFco+4FozepH3gSc/HRo9LcT05qh4khZLMXhW2uVZcGl2t+AZkJ
         aZLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737391137; x=1737995937;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=I8acPMMNfBa5yJgbhB9KB8Wf6+4ucs4xk8J5nrdK9WA=;
        b=ctN6beogR3H1bidTrNpH+elMc/rqRHIgpF8IYdGh5tBnDbjZwFGezZZJb5pVx1/w6m
         I51EeTD3QGlDXTl5evht6+2QmYXUe567CD4PX/PVlg1pT4SaNlADljDB5OuBt5+r2at+
         RtBu1RtxRBkCWQwMPgWzOH0a7yk9ulFlJO41M9Fj3MSC/50pUOL/AMqwRy5oEdznf45l
         qOLBD64Y7nyRqnoFwgM6O1KKvFwr4TZXZu9JPehZKZLF8YgkFGw8TC6umbXzQCfUgUS7
         1zESn15N3wO9PforlikUvAXJKm5BIsvS34Jq+dg2ZoXf78UCAVKVVa2iTmyJ4/Yglmhj
         Cd6Q==
X-Forwarded-Encrypted: i=1; AJvYcCVUFVTXxv/NAIi40f2UUvYZ8FecBBxvKqmS8KIx+ayeVUYqqDdzX8Drvuqdk0PCmssWZu7y0URtezk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwpecI5GBQAREq4MuVZPUe6nixF4QY+Nkpx6Bj0mjBj3bbnL9zA
	mIsHPt48iDSC4e/cSAXylf5qsPxf8mlJhuVYY/Sz0tF8C0Td0hMmqMic3dv5iA==
X-Gm-Gg: ASbGncuf6qi5hWsFVCdHGj7gv7anUirnYTRmb6DMcL1K/j9rwZGWvCeRu+nFryc08Tn
	nLdmd1MzXSmuWkLTgRkf5+BQuFU6jVOrosyYLYsw8P/D5//hG9br1kOoVlyPCbEcwshOup/h5wU
	GX1hVMhhwVSjc18j59l+ssr9VjhvxIFkdish9TqEJSTbKUHgGobIZaCbPDD+UjAb+0IsGsdPIyz
	YSGMRj7q6/HYu1RvjC6dRgF131A8sRfjJUgTi2mptgf+O8SxjcczwlhxKWaG/k8mB0FoGkmK6sN
	uD4wdh7Mo5dYNA8OcqIpvI3UQnVNZQUwxq90uLGtFOZFsckrAZEXR0k=
X-Google-Smtp-Source: AGHT+IGVQxwvdR0ilcqOWNp2M+c38jQy/07RSNXDvHfc7+gKLsGJ0ijaK1AgUZgYVZOd950AH9BhFQ==
X-Received: by 2002:a05:600c:34d0:b0:434:fbda:1f44 with SMTP id 5b1f17b1804b1-4389142e805mr113200345e9.19.1737391137374;
        Mon, 20 Jan 2025 08:38:57 -0800 (PST)
Message-ID: <2682d50b-8152-427a-9184-322afdb9dd47@suse.com>
Date: Mon, 20 Jan 2025 17:38:56 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v2 06/10] x86: Enable XSTATE save/restore for arch LBR
To: Tu Dinh <ngoc-tu.dinh@vates.tech>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Juergen Gross <jgross@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20250102084413.102-1-ngoc-tu.dinh@vates.tech>
 <20250102084413.102-7-ngoc-tu.dinh@vates.tech>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250102084413.102-7-ngoc-tu.dinh@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 02.01.2025 09:45, Tu Dinh wrote:
> --- a/xen/arch/x86/include/asm/xstate.h
> +++ b/xen/arch/x86/include/asm/xstate.h
> @@ -33,13 +33,13 @@ extern uint32_t mxcsr_mask;
>  #define XSTATE_FP_SSE  (X86_XCR0_X87 | X86_XCR0_SSE)
>  #define XCNTXT_MASK    (X86_XCR0_X87 | X86_XCR0_SSE | X86_XCR0_YMM | \
>                          X86_XCR0_OPMASK | X86_XCR0_ZMM | X86_XCR0_HI_ZMM | \
> -                        XSTATE_NONLAZY)
> +                        XSTATE_NONLAZY | XSTATE_XSAVES_ONLY)

This is odd - in the sole pre-existing place where the #define is used you
then remove X86_XSS_STATES again. Plus please see also
https://lists.xen.org/archives/html/xen-devel/2021-04/msg01336.html.

>  #define XSTATE_ALL     (~(1ULL << 63))
>  #define XSTATE_NONLAZY (X86_XCR0_BNDREGS | X86_XCR0_BNDCSR | X86_XCR0_PKRU | \
>                          X86_XCR0_TILE_CFG | X86_XCR0_TILE_DATA)
>  #define XSTATE_LAZY    (XSTATE_ALL & ~XSTATE_NONLAZY)
> -#define XSTATE_XSAVES_ONLY         0
> +#define XSTATE_XSAVES_ONLY         (X86_XSS_LBR)
>  #define XSTATE_COMPACTION_ENABLED  (1ULL << 63)
>  
>  #define XSTATE_XSS     (1U << 0)
> @@ -91,6 +91,21 @@ struct xstate_bndcsr {
>      uint64_t bndstatus;
>  };
>  
> +struct xstate_lbr_entry {
> +    uint64_t lbr_from_ip;
> +    uint64_t lbr_to_ip;
> +    uint64_t lbr_info;
> +};
> +
> +struct xstate_lbr {
> +	uint64_t lbr_ctl;
> +	uint64_t lbr_depth;
> +	uint64_t ler_from_ip;
> +	uint64_t ler_to_ip;
> +	uint64_t ler_info;
> +	struct xstate_lbr_entry entries[32];
> +};

Doesn't this 32 appear in an earlier patch as well? They need tying together
via a #define then.

Also nit: Hard tabs slipped in.

> @@ -114,6 +129,9 @@ int xstate_alloc_save_area(struct vcpu *v);
>  void xstate_init(struct cpuinfo_x86 *c);
>  unsigned int xstate_uncompressed_size(uint64_t xcr0);
>  unsigned int xstate_compressed_size(uint64_t xstates);
> +void *get_xstate_component_comp(struct xsave_struct *xstate,
> +                                unsigned int size,
> +                                uint64_t component);
>  
>  static inline uint64_t xgetbv(unsigned int index)
>  {
> diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
> index 289cf10b78..68a419ac8e 100644
> --- a/xen/arch/x86/msr.c
> +++ b/xen/arch/x86/msr.c
> @@ -522,8 +522,7 @@ int guest_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val)
>          if ( !cp->xstate.xsaves )
>              goto gp_fault;
>  
> -        /* No XSS features currently supported for guests */
> -        if ( val != 0 )
> +        if ( val & ~(uint64_t)XSTATE_XSAVES_ONLY )
>              goto gp_fault;

Imo we'd be better off arranging for casts like this to not be required. It's
too easy to leave one out unintentionally.

> @@ -210,7 +214,7 @@ void expand_xsave_states(const struct vcpu *v, void *dest, unsigned int size)
>       * non-compacted offset.
>       */
>      src = xstate;
> -    valid = xstate_bv & ~XSTATE_FP_SSE;
> +    valid = xstate_bv & ~XSTATE_FP_SSE & ~X86_XSS_STATES;
>      while ( valid )
>      {
>          u64 feature = valid & -valid;
> @@ -276,7 +280,7 @@ void compress_xsave_states(struct vcpu *v, const void *src, unsigned int size)
>       * possibly compacted offset.
>       */
>      dest = xstate;
> -    valid = xstate_bv & ~XSTATE_FP_SSE;
> +    valid = xstate_bv & ~XSTATE_FP_SSE & ~X86_XSS_STATES;
>      while ( valid )
>      {
>          u64 feature = valid & -valid;

I can't figure why these two changes are needed, and the description isn't
of any help here either.

> @@ -1072,6 +1085,30 @@ void xstate_set_init(uint64_t mask)
>          BUG();
>  }
>  
> +void *get_xstate_component_comp(struct xsave_struct *xstate,
> +                                unsigned int size,
> +                                uint64_t component)
> +{
> +    uint16_t comp_offsets[sizeof(xfeature_mask) * 8];
> +    uint16_t offset;
> +    unsigned int i = ilog2(component);
> +
> +    ASSERT(generic_hweightl(component) == 1);
> +
> +    if ( !(xstate->xsave_hdr.xcomp_bv & XSTATE_COMPACTION_ENABLED) ||
> +         i >= xstate_features ||
> +         xstate_sizes[i] == 0 ||
> +         !(xstate->xsave_hdr.xcomp_bv & component) )
> +        return NULL;
> +
> +    setup_xstate_comp(comp_offsets, xstate->xsave_hdr.xcomp_bv);
> +    offset = comp_offsets[i];
> +    if ( xstate_sizes[i] + offset > size )
> +        return NULL;
> +
> +    return (void *)xstate + offset;
> +}

The function is unused at this point. Besides this being a Misra violation
(unreachable code), it also means it's left unclear what the purpose is.
That would, for example, influence whether there should be some "const"
applied. I find it particularly worrying that the function returns a
pointer to non-const, thus permitting the caller to fiddle with the
contents. Similarly it's left unclear what the "size" parameter is for.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 20 16:42:06 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Jan 2025 16:42:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875019.1285347 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZuqj-0003iu-Cy; Mon, 20 Jan 2025 16:42:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875019.1285347; Mon, 20 Jan 2025 16:42:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZuqj-0003in-9p; Mon, 20 Jan 2025 16:42:05 +0000
Received: by outflank-mailman (input) for mailman id 875019;
 Mon, 20 Jan 2025 16:42:04 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=BOU1=UM=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tZuqi-0003ih-5G
 for xen-devel@lists.xenproject.org; Mon, 20 Jan 2025 16:42:04 +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 7a055fa5-d74d-11ef-a0e4-8be0dac302b0;
 Mon, 20 Jan 2025 17:42:03 +0100 (CET)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-436341f575fso51765765e9.1
 for <xen-devel@lists.xenproject.org>; Mon, 20 Jan 2025 08:42:03 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38bf327ded8sm10776855f8f.89.2025.01.20.08.42.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 20 Jan 2025 08:42:02 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 7a055fa5-d74d-11ef-a0e4-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737391323; x=1737996123; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Z4nvgaG6VFt2175QMussB2Byc/bxtdqA81s35cU6zRw=;
        b=CYyu8J6tTcNjsdG2yQcLS15RbSWp3v/+PIPAbFKgt5fTtO/x8V3wwb931yNYKEmOaQ
         RdLyLVBXEbyet2Vfi1TScx26j0ImZC5UvSchv6CPfYsg677kUlFgS535PLuatogEbPsN
         heonFGVjCCcXZE4QGMehKOhf0G1oXWIrFuoAOvxBpljuu9tX9Tbe+pz+58IJgl7JyL78
         ORXwE8/kaf9H//4EzQ9/WTK4VwS4wrNIJjWyUpk3CV3qCEGKeKl0KCr0bQUTWdoLxcjX
         MWxinhmgrtCwZgPo6ggfqneZrQIS7kjFAMsiQyCfh0rVPSAB0Epu+i/2LBjnseNlhVEy
         MUsw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737391323; x=1737996123;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Z4nvgaG6VFt2175QMussB2Byc/bxtdqA81s35cU6zRw=;
        b=iDIubjNR0e/cX8VJj1ApvxSxNWftPIYUYNuVeDN/JvB8PtF1b8qMQ3HVLjub3bmAiL
         2ZeRt7oQITNFxa+Abjr7if3aYW/qjB4wP5ytSXRWLsFJG2fTrY2n3uAviX9g8IViSiMw
         8UNUaRt4accRG3v30xyYJixGXJaMq7UWEqIWN9skbNUWaYxqAwUs8o8DsMYYwwYMy4Ag
         hPcX4IOA3/ha6R3dIrDvT+Wnrl3RBmRBceGgJYzzMdZIzimtRFGO9HbWHLM8ENZDV2RL
         Qc2oxfZtDXhGUIYNbdJHOKONu8TGA9vtsZgfVDzYrPCdhB6LOVOQtD5FoRv9sHj8IMnT
         h1hw==
X-Forwarded-Encrypted: i=1; AJvYcCWmFPMjYpcVcqaaaEmAa5f6x9hc2W2jY6oyacPgM/8yEtz16cG2wknuo2FrXffepn3XwAdbbSpEvf8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyFLTHzxt84VtYM0BRR1dDfTTx+tkIB62LzrV1Q+KxpI72whLbD
	6qiFDAbJwiMZKZjrIHotUrZPt//MdEaveiwLwJoHWup+TQYQGsF/j/GiPALdMw==
X-Gm-Gg: ASbGnctD9plm2/22Usx2yFPOGoPEEa8JmXwr4dQsr/LxAh2o0CfpY4O6dtTIUsoQFKF
	ogBhWFmPaIHh5ezgoSgjn8e4lGc0z474nQGskYJ1zPfZqNDkHIisVGy0uEFbWMIV5E9/iDHf+Bx
	uJfRuPwtZ6Xojtxh8Cm0o2JshaGFbP00ZZHD3RC0eVKPwRL/sGfoMoZBil72iJ28rbHRlG+7oXw
	GgKcq7F+4l77DaqeR6LtGtQsf3nK04klLqzR15Wh0QRF2XfyQo+pVlHHfifQveC02BNmkoO76RU
	mMJhWCDAcBdVyfrEzT+3UctN1HjTp39rECYTsg+wHlex66JeJhNfjWY=
X-Google-Smtp-Source: AGHT+IH9GiBsS3TarhI4zxGpX03LVLiMlYHoUx1xU/1XDA0chbP4YYaPx/7+uR3VgySmrrP+FkoYSQ==
X-Received: by 2002:adf:e98e:0:b0:38b:e32a:109f with SMTP id ffacd0b85a97d-38bf56594e9mr8336111f8f.12.1737391322748;
        Mon, 20 Jan 2025 08:42:02 -0800 (PST)
Message-ID: <9e02381e-f350-4d89-a164-6db2dfbde0b3@suse.com>
Date: Mon, 20 Jan 2025 17:42:01 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v2 07/10] x86/hvm: Don't count XSS bits in XSAVE size
To: Tu Dinh <ngoc-tu.dinh@vates.tech>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Juergen Gross <jgross@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20250102084413.102-1-ngoc-tu.dinh@vates.tech>
 <20250102084413.102-8-ngoc-tu.dinh@vates.tech>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250102084413.102-8-ngoc-tu.dinh@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 02.01.2025 09:45, Tu Dinh wrote:
> HVM vCPU state images are uncompressed and therefore can't contain XSS
> states.

Then again ...

> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -1208,7 +1208,8 @@ HVM_REGISTER_SAVE_RESTORE(CPU, hvm_save_cpu_ctxt, NULL, hvm_load_cpu_ctxt, 1,
>  
>  #define HVM_CPU_XSAVE_SIZE(xcr0) (offsetof(struct hvm_hw_cpu_xsave, \
>                                             save_area) + \
> -                                  xstate_uncompressed_size(xcr0))
> +                                  xstate_uncompressed_size(xcr0 & \
> +                                                           ~X86_XSS_STATES))

... a variable / parameter named "xcr0" shouldn't include any XSS bits
anyway. IOW this perhaps needs sorting at the use sites of the macros.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 20 16:55:00 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Jan 2025 16:55:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875028.1285378 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZv3D-000685-0u; Mon, 20 Jan 2025 16:54:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875028.1285378; Mon, 20 Jan 2025 16:54:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZv3C-00067w-Tr; Mon, 20 Jan 2025 16:54:58 +0000
Received: by outflank-mailman (input) for mailman id 875028;
 Mon, 20 Jan 2025 16:54:58 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=1xfr=UM=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tZv3C-0005fM-2d
 for xen-devel@lists.xenproject.org; Mon, 20 Jan 2025 16:54:58 +0000
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com
 [2a00:1450:4864:20::22b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 46f996f7-d74f-11ef-99a4-01e77a169b0f;
 Mon, 20 Jan 2025 17:54:56 +0100 (CET)
Received: by mail-lj1-x22b.google.com with SMTP id
 38308e7fff4ca-305d843d925so40162631fa.2
 for <xen-devel@lists.xenproject.org>; Mon, 20 Jan 2025 08:54:56 -0800 (PST)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-3072a35aec4sm16581501fa.56.2025.01.20.08.54.54
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 20 Jan 2025 08:54:55 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 46f996f7-d74f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1737392096; x=1737996896; 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=UXq8oJNFxqFqbhkJfspIF9HTbKUSA1pwy167cwYkY18=;
        b=SoxvpOZwRY0kgsrDtA96pC4HCJtvIOkWZ8+bnldF/K3FhoE9FlsNB4kFhfiCvacE9R
         ILKFgGvidmEk+JcAYB9tTP/jGw1p0Ss7/N/nWvAVwcLPdwsGQLI/hIZR/7gy3dSHUle4
         5GqB3zKXrbXle0lKbNBpYp0iblyJIC3ybvfx0IkktLhIoJp4hHQjiTq6gW+7pPRVetyp
         iS+VkLBV7wbLJ8rqBQCZvqWcp/9iQSNo02uqkcHpHWWFoDmxoy6+7DSsoVXgtyIPWXy7
         vmrvxTMXtCbntnqlJclglGreSu0isaaLxHjf0iBwhF/Edu3GTDtmrbQmjNKOTZZqXm8s
         zguA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737392096; x=1737996896;
        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=UXq8oJNFxqFqbhkJfspIF9HTbKUSA1pwy167cwYkY18=;
        b=t9TX38jjqHdol/bU1VMp7tPgS8AdVThDDOo0mc95JMfWoAc9h6QrY9TAFjHSr5XWRX
         yRer7Rdkkp0V0CZ/zLTz38E0k8Dl73PiIv1edg7lI0Mct1nCZgXzrjt+8L7gw1P+865q
         agiAS1IzIPxfvukByYjQTuhfl51E+EVwzO9H5cSiBHIVIkmxWvVob27aRaImK2m12t7+
         ZWtH7FDy10A9wv8iiwPge5cGS1y4PDfL4zWbd3MOivMI0O03Bzp+C/4D1qfsOpC8J8+p
         t98qM3xOP2b4e0p/NByYgnlvHAarLJ8cXTul8AjJoYE2QheXlaelrm1JSlHLIur7QS/y
         A9bw==
X-Gm-Message-State: AOJu0YwOLUamRN5RneR+PX6FohU4LKh+S3cI9UnvDOQF7ozsvzbNSbZt
	yNU7lC3Oop3NavzKDH0p9IDX9HAmQK36O0huJxk4S2/BK8Klij2p/2YAcQ==
X-Gm-Gg: ASbGncsn13tHXRIvuweRx0k1YnCzhnAnJk7UY/skR43PCig36OGHlGAw6Ao5yDhMJze
	mFe+Wlugoo/BIXBn8I/DhwfBPcsdfdl6jd7gGi/4y6kPtHvmMny9owCyltuuD6vZUQcArkuG0eV
	Dy++UezcAGuguUWcxuDc6yYcpIRjJUGwBuErgqOSLs0GK72ZVyJQ2b22ulRS9geaGX58fAuoqk6
	snyuscNuFBV+cbzt5unrtATcPQvujhCskAChA6Q1ZUtBw71uArYCpEqDaRh8SvaEXIrMh8=
X-Google-Smtp-Source: AGHT+IG+yeo267gkP4ELBuOOmKSTVwh7M1OX0XAwHuYDvtkxZzwBI37tWNfMYNAWGF0DAjQMih51bA==
X-Received: by 2002:a2e:a54a:0:b0:300:3a15:8f19 with SMTP id 38308e7fff4ca-3072cb3c7a9mr56218221fa.32.1737392095702;
        Mon, 20 Jan 2025 08:54:55 -0800 (PST)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Bob Eshleman <bobbyeshleman@gmail.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v1 2/3] xen/riscv: update defintion of vmap_to_mfn()
Date: Mon, 20 Jan 2025 17:54:48 +0100
Message-ID: <bf85f6987c2a2f3374ad47fc0bf1513d69372b1f.1737391102.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.48.1
In-Reply-To: <cover.1737391102.git.oleksii.kurochko@gmail.com>
References: <cover.1737391102.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

vmap_to_mfn() uses virt_to_maddr(), which is designed to work with VA from
either the direct map region or Xen's linkage region (XEN_VIRT_START).
An assertion will occur if it is used with other regions, in particular for
the VMAP region.

Since RISC-V lacks a hardware feature to request the MMU to translate a VA to
a PA (as Arm does, for example), software page table walking (pt_walk()) is
used for the VMAP region to obtain the PA.

Fixes: 7db8d2bd9b ("xen/riscv: add minimal stuff to mm.h to build full Xen")
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/arch/riscv/include/asm/mm.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/riscv/include/asm/mm.h b/xen/arch/riscv/include/asm/mm.h
index d46018c132..528e1e257f 100644
--- a/xen/arch/riscv/include/asm/mm.h
+++ b/xen/arch/riscv/include/asm/mm.h
@@ -25,7 +25,7 @@ paddr_t pt_walk(vaddr_t va);
 #define gaddr_to_gfn(ga)    _gfn(paddr_to_pfn(ga))
 #define mfn_to_maddr(mfn)   pfn_to_paddr(mfn_x(mfn))
 #define maddr_to_mfn(ma)    _mfn(paddr_to_pfn(ma))
-#define vmap_to_mfn(va)     maddr_to_mfn(virt_to_maddr((vaddr_t)(va)))
+#define vmap_to_mfn(va)     maddr_to_mfn(pt_walk((vaddr_t)(va)))
 #define vmap_to_page(va)    mfn_to_page(vmap_to_mfn(va))
 
 static inline void *maddr_to_virt(paddr_t ma)
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Mon Jan 20 16:55:00 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Jan 2025 16:55:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875026.1285358 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZv3A-0005fa-Fr; Mon, 20 Jan 2025 16:54:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875026.1285358; Mon, 20 Jan 2025 16:54:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZv3A-0005fT-Cf; Mon, 20 Jan 2025 16:54:56 +0000
Received: by outflank-mailman (input) for mailman id 875026;
 Mon, 20 Jan 2025 16:54:55 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=1xfr=UM=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tZv39-0005fM-MT
 for xen-devel@lists.xenproject.org; Mon, 20 Jan 2025 16:54:55 +0000
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com
 [2a00:1450:4864:20::22d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 453dd124-d74f-11ef-99a4-01e77a169b0f;
 Mon, 20 Jan 2025 17:54:53 +0100 (CET)
Received: by mail-lj1-x22d.google.com with SMTP id
 38308e7fff4ca-30225b2586cso53775291fa.0
 for <xen-devel@lists.xenproject.org>; Mon, 20 Jan 2025 08:54:53 -0800 (PST)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-3072a35aec4sm16581501fa.56.2025.01.20.08.54.51
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 20 Jan 2025 08:54:51 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 453dd124-d74f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1737392092; x=1737996892; 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=2wmguJZGAmdCa6h8C+hITCEE8sE0M2/Z9lgrMQrF6jo=;
        b=c62LsOP8QSFLIQswVJn5PJ32ex1tPJ9YktnMGjYOMGEoi/ykndE8jCg9EzI8tOBapv
         80zDoi8DuX488+SR5BvF7nc/Nv8gRhb6mhuMsceY5uyFuGC2AVhZyxvWDx+lRPV78FR2
         6PyHMGtk+5PqZEHpbgX4ac20HgjfNoE4kkxJHkqPPHw7Qp9+E90Asqy3Zw+Iq0hefLI/
         2NFpZOBRk2MTzD6WDMjuA6C3AsJwNYW6UR/wqV7J846f7OUE++VKuwxLwoYJrG55Jq4d
         3ZnSWqCKHb16yujrylrCSMhcWqg65/K4ExCLfI6lmUNdeVhL9mRNWodcHV9GJzt2JTbY
         FcDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737392092; x=1737996892;
        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=2wmguJZGAmdCa6h8C+hITCEE8sE0M2/Z9lgrMQrF6jo=;
        b=T2O0Us09APZHHAAsEtXZ9d4YW0cyHxPAoJUNzRagfnB+grtszr4qvk7TCJky5jzdO2
         zivR4YWHCQBmhQqA0fk8XFdkqQXfaqUYzHrTgssolJ8y8VHH/3PvGtv26sVM6eLioeZo
         73tjs8X3RPHM2LhtDbpKeRPUWa0wdIXy+SdtBbhy5jIPOnc0R7aVHUHTjQuj+/9yxuPg
         PmsbOKUM97T/QMfoS6+q4ztzPnqC4a5AaBvU7ZyvUrkr0JrDfpRmqcZOopbcCLGNz/TO
         g63Ls1M5T2O2HD4hydQA+y9mwlltYPCHODZ+WUmvqpWMwfdMH7ENgs+W/OjcdahY8K35
         YUfw==
X-Gm-Message-State: AOJu0YxxPkL/CBRK8XZBzJrgSmUqSasY2ruF9WrgOwELEXEJjnIoveKE
	u5zbfIaKxipHkT9TYywZmvqTZ/x+6Ow8uYWuZEEd5+x0T5FOosXE6f/CIw==
X-Gm-Gg: ASbGnctlOe1xjGYZME/hwBd0q7j+54TUs7qvbx6OV6lF8AxyRDRSQsT1BBCWgNbeKZ7
	0hzDSKa3saGhV9WHwezkudj4hIsysNcCqMEAccp7gA1QJQePwsrRpBALQ/1vSbOsPxi1xirxMLr
	W0jJkkh9d7tjcZm5f77j7w86zEAwejcIYdv73WFEeVeJjFpWJx7hvBghXzS12KxDOiO4jnELUWM
	neScDNKAUH9y+ODAYFN7aJjsuLusTvlJA+4S5Bd00mRC2C8wRqJkPUiHuuCsNJfWpa7UwE=
X-Google-Smtp-Source: AGHT+IHS/he8PSwbOJuVFJ4wvA8HOKfU67IvvWM2roebx+FbhzRiGY4cH+9P/bHOXHLBjKmCoYw7OA==
X-Received: by 2002:a05:651c:118d:b0:302:23a7:1ee8 with SMTP id 38308e7fff4ca-3063057702fmr67983861fa.3.1737392092013;
        Mon, 20 Jan 2025 08:54:52 -0800 (PST)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Bob Eshleman <bobbyeshleman@gmail.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH for 4.20? v1 0/3] Fixes for vmap_to_mfn() and pt_mapping_level
Date: Mon, 20 Jan 2025 17:54:46 +0100
Message-ID: <cover.1737391102.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.48.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Introduce pt_walk(), which does software page table walking to resolve the
following issues:
1. vmap_to_mfn() uses virt_to_maddr(), which is designed to work with VA
   from either the direct map region or Xen's linkage region (XEN_VIRT_START),
   thereby an assertion will occur if it is used with other regions, in
   particular for the VMAP region. The solution is usage of pt_walk() for
   vmap_to_mfn().
2. pt_mapping_level() returns incorrect page table level in the case when
   mfn==INVALID_MFN when, for example, VA was mapped to PA using 4k mapping,
   but during destroying/modification pt_mapping_level() could return incorrect
   page table level as when mfn==INVALID_MFN then only VA is taking into account
   for page table level calculation and so if VA is page table level 1 aligned
   then page_mapping_level() will return level 1 ( instead of level 0 as VA was
   mapped to PA using 4k mapping so there is incostinency here ). The solution is
   usage of pt_walk() to recieve mfn and use both mfn and VA for proper page
   table level calculation.

It would be nice  to have these fixes in Xen 4.20 but isn't really critical as
there is no any users for RISC-V port at this moment.

Oleksii Kurochko (3):
  xen/riscv: implement software page table walking
  xen/riscv: update defintion of vmap_to_mfn()
  xen/riscv: update mfn calculation in pt_mapping_level()

 xen/arch/riscv/include/asm/mm.h |  4 +-
 xen/arch/riscv/pt.c             | 84 ++++++++++++++++++++++++++++++++-
 2 files changed, 85 insertions(+), 3 deletions(-)

-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Mon Jan 20 16:55:00 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Jan 2025 16:55:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875027.1285367 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZv3B-0005tW-M8; Mon, 20 Jan 2025 16:54:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875027.1285367; Mon, 20 Jan 2025 16:54:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZv3B-0005tP-JF; Mon, 20 Jan 2025 16:54:57 +0000
Received: by outflank-mailman (input) for mailman id 875027;
 Mon, 20 Jan 2025 16:54: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
 <SRS0=1xfr=UM=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tZv3A-0005fS-LH
 for xen-devel@lists.xenproject.org; Mon, 20 Jan 2025 16:54:56 +0000
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com
 [2a00:1450:4864:20::231])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 466665e7-d74f-11ef-a0e4-8be0dac302b0;
 Mon, 20 Jan 2025 17:54:55 +0100 (CET)
Received: by mail-lj1-x231.google.com with SMTP id
 38308e7fff4ca-30219437e63so57884471fa.1
 for <xen-devel@lists.xenproject.org>; Mon, 20 Jan 2025 08:54:55 -0800 (PST)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-3072a35aec4sm16581501fa.56.2025.01.20.08.54.53
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 20 Jan 2025 08:54:54 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 466665e7-d74f-11ef-a0e4-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1737392095; x=1737996895; 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=QAci7/y9aPonTonAxMRXFGNKbw9P1cakqYuBwvG636Q=;
        b=Yx9aellsnkuED7G5txVPAKyxUjdWwSBSaeF06qlWva4/2lnAFmigc/FlGtYvBOxyHw
         9XMJZoRJ2d/JsfVACxOxrucZ1oCIwNremymLKUrzSMVpaJlPbh8aWO/BNmhcdRHc65Uk
         94PNC+kkq+h1SjPPG9/7dPHDVXGa4+EsEcES9B0Pqr/6BzAoiWrpxcGxORVjksDqy0kp
         qYeo5/oxLlCm1j9Yb9NAupKhYY2KKiZTD8u+4g7ICdr9g3KS8W0M03+OdvbUmJKCc+2u
         UdHsm40wFyinIt05zVK+iDuh2/Spv61Y/gIRdHhJq9Lr28JmF44c5TydfIlAo7voeKoH
         Vj6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737392095; x=1737996895;
        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=QAci7/y9aPonTonAxMRXFGNKbw9P1cakqYuBwvG636Q=;
        b=YK920muqcRi+GRta8R6NAEFvATV4WyYzLEuMO6IgzNtnODP1pGxl/rFkTbePMlaiJQ
         SIQ2w9OZGzFW6s1pRwVzlrthBAD29YOcG1QnTXdCMwIFVQokJV6CfX/0LEtV0fn+NOHV
         aTTKreWI0LD9Jg/U/qA0A4fg6QvoWUKGUewfwxhmLbwzN3+b2nFYCxy9L8c2zsImfcAk
         AeCJOsynAnk8O2eIvqgAR420OkW9ipgcopnpaB4aF31hL4ZBPSBCCl1t0JjGXGTE2RN2
         m96SPEGjkW28ytvNA1Lnvw0SgA/VUj3VCpiNABQiXt3pAZ8+/KuZp8oVnuVZxlo3UEfY
         2RFA==
X-Gm-Message-State: AOJu0Yyuct7Qdt5Otv3rcK+cDv0wMqTTRRNPMPfSeX8jbYm9PmSSCuKv
	nEACggM0sNkZ4eIDUWqRE+3Ksg7VMeDomdxF4LAO35JK/mn/XSfkeyamCw==
X-Gm-Gg: ASbGnct1zBqavo2E7AyfxhA4jTf7Hk8h0nTXqr7c2BAQQPtMlVXecZZkHOl7/npVVSr
	opMLMw7uEhKM5zdAQG5gVwfEF8G/o0OKZvHLcxHENJ6mMEu6TjnXW195QKwmyxboGR7q9TzO1Se
	T3FYxzux/ivISa0eokJyOdCXAtTMXb2CIzEpgVea5iBI6rHMq0HbxWZAVspZJsAOS4e9rQsvsFQ
	hKAY5w7tMjLjEU39bnsZkSkM3sQ4ToNiIAmR4EiIQe0bRsVvNMIVNN378+GfNbAxeJkNis=
X-Google-Smtp-Source: AGHT+IFz5Cwm7/8fr/VJmijwGV+DRnd1DmMRxxqBYFi+G0+4wzYO6HCvGfCX2bJrTTWWBIyVVv0Mqw==
X-Received: by 2002:a2e:a912:0:b0:306:d69:904b with SMTP id 38308e7fff4ca-3072d11346dmr48975511fa.8.1737392094574;
        Mon, 20 Jan 2025 08:54:54 -0800 (PST)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Bob Eshleman <bobbyeshleman@gmail.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v1 1/3] xen/riscv: implement software page table walking
Date: Mon, 20 Jan 2025 17:54:47 +0100
Message-ID: <00dfc71569bc9971b53e29b36a80e9e020ac61ac.1737391102.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.48.1
In-Reply-To: <cover.1737391102.git.oleksii.kurochko@gmail.com>
References: <cover.1737391102.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

RISC-V doesn't have hardware feature to ask MMU to translate
virtual address to physical address ( like Arm has, for example ),
so software page table walking in implemented.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/arch/riscv/include/asm/mm.h |  2 ++
 xen/arch/riscv/pt.c             | 56 +++++++++++++++++++++++++++++++++
 2 files changed, 58 insertions(+)

diff --git a/xen/arch/riscv/include/asm/mm.h b/xen/arch/riscv/include/asm/mm.h
index 292aa48fc1..d46018c132 100644
--- a/xen/arch/riscv/include/asm/mm.h
+++ b/xen/arch/riscv/include/asm/mm.h
@@ -15,6 +15,8 @@
 
 extern vaddr_t directmap_virt_start;
 
+paddr_t pt_walk(vaddr_t va);
+
 #define pfn_to_paddr(pfn) ((paddr_t)(pfn) << PAGE_SHIFT)
 #define paddr_to_pfn(pa)  ((unsigned long)((pa) >> PAGE_SHIFT))
 
diff --git a/xen/arch/riscv/pt.c b/xen/arch/riscv/pt.c
index a703e0f1bd..865d60d1af 100644
--- a/xen/arch/riscv/pt.c
+++ b/xen/arch/riscv/pt.c
@@ -274,6 +274,62 @@ static int pt_update_entry(mfn_t root, vaddr_t virt,
     return rc;
 }
 
+paddr_t pt_walk(vaddr_t va)
+{
+    const mfn_t root = get_root_page();
+    /*
+     * In pt_walk() only XEN_TALE_MAP_NONE and XEN_TABLE_SUPER_PAGE are
+     * handled ( as they are only possible for page table walking ), so
+     * initialize `ret` with "impossible" XEN_TABLE_MAP_NOMEM.
+    */
+    int ret = XEN_TABLE_MAP_NOMEM;
+    unsigned int level = HYP_PT_ROOT_LEVEL;
+    paddr_t pa = 0;
+    pte_t *table;
+
+    DECLARE_OFFSETS(offsets, va);
+
+    table = map_table(root);
+
+    /*
+     * Find `pa` of an entry which corresponds to `va` by iterating for each
+     * page level and checking if the entry points to a next page table or
+     * to a page.
+     *
+     * Two cases are possible:
+     * - ret == XEN_TABLE_SUPER_PAGE means that the entry was find;
+     *   (Despite of the name) XEN_TABLE_SUPER_PAGE covers 4k mapping too.
+     * - ret == XEN_TABLE_MAP_NONE means that requested `va` wasn't actually
+     *   mapped.
+     */
+    while ( (ret != XEN_TABLE_MAP_NONE) && (ret != XEN_TABLE_SUPER_PAGE) )
+    {
+        /*
+         * This case shouldn't really occur as it will mean that for table
+         * level 0 a pointer to next page table has been written, but at
+         * level 0 it could be only a pointer to 4k page.
+         */
+        ASSERT(level <= HYP_PT_ROOT_LEVEL);
+
+        ret = pt_next_level(false, &table, offsets[level]);
+        level--;
+    }
+
+    if ( ret == XEN_TABLE_MAP_NONE )
+        dprintk(XENLOG_WARNING, "Is va(%#lx) really mapped?\n", va);
+    else if ( ret == XEN_TABLE_SUPER_PAGE )
+        pa = pte_to_paddr(*(table + offsets[level + 1]));
+
+    /*
+     * There is no need for unmap_table() after each pt_next_level() call as
+     * pt_next_level() will do unmap_table() for the previous table before
+     * returning next level table.
+     */
+    unmap_table(table);
+
+    return pa;
+}
+
 /* Return the level where mapping should be done */
 static int pt_mapping_level(unsigned long vfn, mfn_t mfn, unsigned long nr,
                             unsigned int flags)
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Mon Jan 20 16:55:01 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Jan 2025 16:55:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875029.1285388 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZv3F-0006Oy-8b; Mon, 20 Jan 2025 16:55:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875029.1285388; Mon, 20 Jan 2025 16:55:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tZv3F-0006On-5Z; Mon, 20 Jan 2025 16:55:01 +0000
Received: by outflank-mailman (input) for mailman id 875029;
 Mon, 20 Jan 2025 16:54: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
 <SRS0=1xfr=UM=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tZv3D-0005fM-4Z
 for xen-devel@lists.xenproject.org; Mon, 20 Jan 2025 16:54:59 +0000
Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com
 [2a00:1450:4864:20::233])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 478ffdb4-d74f-11ef-99a4-01e77a169b0f;
 Mon, 20 Jan 2025 17:54:57 +0100 (CET)
Received: by mail-lj1-x233.google.com with SMTP id
 38308e7fff4ca-3003c0c43c0so50073791fa.1
 for <xen-devel@lists.xenproject.org>; Mon, 20 Jan 2025 08:54:57 -0800 (PST)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-3072a35aec4sm16581501fa.56.2025.01.20.08.54.55
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 20 Jan 2025 08:54:56 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 478ffdb4-d74f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1737392097; x=1737996897; 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=eKyZpIY7f8FG3QEkOJcyw71ibKhausbsni6UpIbgyKc=;
        b=AU+DWBbSlZyR+59P4cd4Kl82WOplfekxfVnXeZHtTKsNooQTeQmh/ShlQbI+mNc03S
         kIcwl28JbWoHaa8DrdjC0yKCqBT1hvoVAwVfN7AAdBMxgTYeeF246haaBxHl1GpoJYE7
         BNvSZE2hCw1ge7NSLbJdFpO++OXN3p9AJ9e66uyldMzpWUyeP6WFigz10aBoPJyihdBO
         FN2ODuptdIyD+aUyuwcU8scoB+0Tat/B0bD+0LNafIXSN8MphpFDx0QId3tQdqytT7nZ
         6J8cNeUwHmTj2JObavgig6WRJH5jYHRKnHFYyef5LalOTsEuDLktB0xmhqs8glOPPg/X
         ZH4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737392097; x=1737996897;
        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=eKyZpIY7f8FG3QEkOJcyw71ibKhausbsni6UpIbgyKc=;
        b=LnI1FWux9JLTpaRblI9GcbZOm4NvtV6apfOuqKhUl/TSVpO3MTSxl6lQQ7hMJBpm2N
         Zy7IZ/v3RupwIGbVmQlhwF1i/xm5oIFPUurC93/dOXTia8KxAPlLpGsgxfLyuMMnudUx
         RY1+86P9IXc5asIT9i2ql5W7sl8x5ndQOsS2bYjP4vU+MkRmmgmXQhHsDgwlQ4Rzobnc
         e+AC0uOx4Xc6a/1WGKr95Wf/O2ZtgFOO20AJGp1B74Ig7FANHfwO5KkcvzVydEE59mgl
         teeqxFKz3Z6W7DfTzTizFbIIzaYt0V/crvPMtNE8I4w+HjE8chJwANTEyvKKR2tQyuby
         TcnA==
X-Gm-Message-State: AOJu0YxX4vYQbo9qJ6v7xDz0IwT606Vbly+QX7G0Jg6+vJe7D8eYiYOW
	5cAKJQG9TSRUqBXQ/F9uOWVscGRi3vqnwTThtPWlPn+KY17xD22sodhnQg==
X-Gm-Gg: ASbGnctT5JrLnY8wubiQzLC6SthtEa4KdIbPP/RAvRM5fGJArw5Sl5V0AmRUjEiH00y
	hQEOKnABom6fz+h9SRq6pjhp+OPzESEn0YkuMwffGMMYK5RvuULh3zIR9Z5n2+LLBfO/7LwLbNf
	uY09RzeLKETDnHskhQZXXpBQ9WpAq8q8X3g8kmmhHdR/0QOUxgHQTUxUx/e9Qqr7weODzE7NfGV
	XEuzHmL45ISOmzLN4Rf82Wh4Sh87425TIBQ2wFHZZr0Q9lG24CY+9hJoYg/aqBr2tLKINw=
X-Google-Smtp-Source: AGHT+IH/viGUbRyRw/B7XR/62gU1OPKwbDr47PSryCh5/zBWHLDg91Hg7oKnyLuGqHaJ/yivTGWjHQ==
X-Received: by 2002:a05:651c:b27:b0:2ff:c86b:5b4f with SMTP id 38308e7fff4ca-3072ca9c953mr52322211fa.21.1737392096663;
        Mon, 20 Jan 2025 08:54:56 -0800 (PST)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Bob Eshleman <bobbyeshleman@gmail.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v1 3/3] xen/riscv: update mfn calculation in pt_mapping_level()
Date: Mon, 20 Jan 2025 17:54:49 +0100
Message-ID: <a4a970490471035bf49a97257b400da23091fb9a.1737391102.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.48.1
In-Reply-To: <cover.1737391102.git.oleksii.kurochko@gmail.com>
References: <cover.1737391102.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

When pt_update() is called with arguments (..., INVALID_MFN, ..., 0 or 1),
it indicates that a mapping is being destroyed/modifyed.

`mfn` should be set properly in cases when modifying/destroying a  mapping
to ensure the correct page table `level` is returned. In the  case of
`mfn` == INVALID_MFN, the `mask` will take into account only `vfn` and could
accidentally return an incorrect level.
For example,  if `vfn` is page table level 1 aligned, but it was mapped as
page table level 0, then without the check below it will return `level` = 1
because only `vfn`, which is page table level 1 aligned, is taken into
account when `mfn` == INVALID_MFN.

To address this issue, during the destruction/modification of a mapping,
physical address is calculated for provided `va`. This ensures that the
appropriate mask is generated, resulting in the correct calculation of
the level.

Fixes: c2f1ded524 ("xen/riscv: page table handling")
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/arch/riscv/pt.c | 28 ++++++++++++++++++++++++++--
 1 file changed, 26 insertions(+), 2 deletions(-)

diff --git a/xen/arch/riscv/pt.c b/xen/arch/riscv/pt.c
index 865d60d1af..c8bc6f7e37 100644
--- a/xen/arch/riscv/pt.c
+++ b/xen/arch/riscv/pt.c
@@ -346,9 +346,33 @@ static int pt_mapping_level(unsigned long vfn, mfn_t mfn, unsigned long nr,
         return level;
 
     /*
-     * Don't take into account the MFN when removing mapping (i.e
-     * MFN_INVALID) to calculate the correct target order.
+     * `mfn` should be set properly in cases when modifying/destroying a
+     * mapping to ensure the correct page table `level` is received. In the
+     * case of `mfn` == INVALID_MFN, the `mask` will take into account only
+     * `vfn` and could accidentally return an incorrect level. For example,
+     * if `vfn` is page table level 1 aligned, but it was mapped as page table
+     * level 0, then without the check below it will return `level` = 1
+     * because only `vfn`, which is page table level 1 aligned, is taken into
+     * account when `mfn` == INVALID_MFN.
      *
+     * POPULATE shouldn't be considered as `va` hasn't been mapped yet.
+     */
+    if ( mfn_eq(mfn, INVALID_MFN) && !(flags & PTE_POPULATE) )
+    {
+        vaddr_t va = vfn << PAGE_SHIFT;
+        paddr_t pa;
+        unsigned long xen_virt_end = (XEN_VIRT_START + XEN_VIRT_SIZE - 1);
+
+        if ( ((va >= DIRECTMAP_VIRT_START) && (va <= DIRECTMAP_VIRT_END)) ||
+             ((va >= XEN_VIRT_START) && (va <= xen_virt_end)) )
+            pa = virt_to_maddr(va);
+        else
+            pa = pt_walk(va);
+
+        mfn = _mfn(paddr_to_pfn(pa));
+    }
+
+    /*
      * `vfn` and `mfn` must be both superpage aligned.
      * They are or-ed together and then checked against the size of
      * each level.
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Mon Jan 20 23:27:53 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Jan 2025 23:27:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875082.1285398 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ta1BB-0002Jj-WD; Mon, 20 Jan 2025 23:27:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875082.1285398; Mon, 20 Jan 2025 23:27:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ta1BB-0002Jc-TB; Mon, 20 Jan 2025 23:27:37 +0000
Received: by outflank-mailman (input) for mailman id 875082;
 Mon, 20 Jan 2025 23:27: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
 <SRS0=fP4x=UM=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1ta1BA-0002JW-T0
 for xen-devel@lists.xenproject.org; Mon, 20 Jan 2025 23:27:37 +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 1e622de4-d786-11ef-a0e4-8be0dac302b0;
 Tue, 21 Jan 2025 00:27:34 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 3B8775C5EBD;
 Mon, 20 Jan 2025 23:26:49 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3BA24C4CEDD;
 Mon, 20 Jan 2025 23:27:28 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1e622de4-d786-11ef-a0e4-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1737415649;
	bh=P1h9BSSHq/93NNAvn/L/oIb9qmAQ+5NcfsZNGhd1GlQ=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=uimXVDDii97PBXD68ccH8wlznj80cyzQgdeywgtnE98fEMMQuhNSxCInAbdsekOCs
	 Zy14SsTNjXWSYW5/QiYhj6zx9NRyy+peq3tfQg00C95xw/qdkopQU+siNfrjbw393n
	 XGBLZiLTpi8oLT39NinVrEVrEu7SM9+K+HZsqwGNuVbkzCZI61a54+ReDRvJAwx8Tp
	 I+67BIE8uEYDBdfvfOacr3xnk1hUwZa2jjUvPv7W9Vh4J8Y2i6rlds/smcb4caCJS7
	 cwHsQBwZkQXD1UrlGQRgp545okN9ILSBTg6zfrHlL8KkCS9zN8FSj8fq4Z2vVKvxgA
	 pqzo0Fs5SJD8w==
Date: Mon, 20 Jan 2025 15:27:16 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich <jbeulich@suse.com>
cc: Andrew Cooper <andrew.cooper3@citrix.com>, 
    Alejandro Vallejo <alejandro.vallejo@cloud.com>, 
    "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, 
    Julien Grall <julien@xen.org>, Wei Liu <wl@xen.org>, 
    sergiy_kibrik@epam.com, 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
    Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2 1/4] x86: provide an inverted Kconfig control for
 shim-exclusive mode
In-Reply-To: <40c9d806-000d-43e7-a804-ad4e84209b2f@suse.com>
Message-ID: <alpine.DEB.2.22.394.2501201527090.11086@ubuntu-linux-20-04-desktop>
References: <da5f5bac-6d5d-092d-d872-f1120dcd2661@suse.com> <617842e1-8ef2-b095-0c52-c2e2e5f1c0a8@suse.com> <alpine.DEB.2.22.394.2501161503120.2684657@ubuntu-linux-20-04-desktop> <Z4oxZSUQ6VARiR0H@macbook.local> <D74CH4RDRRR9.ZR6RL8U6PQ56@cloud.com>
 <6285f86d-f2d2-4040-999d-01aed3e72a36@suse.com> <alpine.DEB.2.22.394.2501171430570.2684657@ubuntu-linux-20-04-desktop> <f8c1e2c2-ceb5-4200-a304-e2d824a171a8@citrix.com> <40c9d806-000d-43e7-a804-ad4e84209b2f@suse.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1689403285-1737415649=:11086"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-1689403285-1737415649=:11086
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Mon, 20 Jan 2025, Jan Beulich wrote:
> On 18.01.2025 00:41, Andrew Cooper wrote:
> > On 17/01/2025 10:43 pm, Stefano Stabellini wrote:
> >> On Fri, 17 Jan 2025, Jan Beulich wrote:
> >>> On 17.01.2025 13:24, Alejandro Vallejo wrote:
> >>>> On Fri Jan 17, 2025 at 10:31 AM GMT, Roger Pau Monné wrote:
> >>>>> On Thu, Jan 16, 2025 at 04:31:46PM -0800, Stefano Stabellini wrote:
> >>>>>> On Wed, 1 Mar 2023, Jan Beulich wrote:
> >>>>>>> While we want certain things turned off in shim-exclusive mode, doing
> >>>>>>> so via "depends on !PV_SHIM_EXCLUSIVE" badly affects allyesconfig: Since
> >>>>>>> that will turn on PV_SHIM_EXCLUSIVE, other options will be turned off as
> >>>>>>> a result. Yet allyesconfig wants to enable as much of the functionality
> >>>>>>> as possible.
> >>>>>>>
> >>>>>>> Retain PV_SHIM_EXCLUSIVE as a prompt-less option such that first of all
> >>>>>>> C code using it can remain as is. This isn't just for less code churn,
> >>>>>>> but also because I think that symbol is more logical to use in many
> >>>>>>> (all?) places.
> >>>>>>>
> >>>>>>> Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
> >>>>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >>>>>>>
> >>>>>>> ---
> >>>>>>> The new Kconfig control's name is up for improvement suggestions, but I
> >>>>>>> think it's already better than the originally thought of
> >>>>>>> FULL_HYPERVISOR.
> >>>>>> I think the approach in general is OK, maybe we can improve the naming
> >>>>>> further. What about one of the following?
> >>>>>>
> >>>>>> NO_PV_SHIM_EXCLUSIVE
> >>>>>> PV_SHIM_NOT_EXCLUSIVE
> >>>>> IMO negated options are confusing, and if possible I think we should
> >>>>> avoid using them unless strictly necessary.
> >>>> The problem is that the option is negative in nature. It's asking for
> >>>> hypervisor without _something_. I do agree with Stefano that shim would be
> >>>> better in the name. Otherwise readers are forced to play divination tricks.
> >>>>
> >>>> How about something like:
> >>>>
> >>>>     SHIMLESS_HYPERVISOR
> >>>>
> >>>> That's arguably not negated, preserves "shim" in the name and has the correct
> >>>> polarity for allyesconfig to yield the right thing.
> >>> Except that a hypervisor with this option enabled isn't shim-less, but permits
> >>> working in shim as well as in non-shim mode.
> >> First, let's recognize that we have two opposing requirements. One
> >> requirement is to make it as easy as possible to configure for the user.
> >> Ideally without using negative CONFIG options, such as
> >> NO_PV_SHIM_EXCLUSIVE. From the user point of view, honestly,
> >> PV_SHIM_EXCLUSIVE is a pretty good name. Better than all of the others,
> >> I think.
> >>
> >> On the other hand, we have the requirement that we don't want
> >> allyesconfig to end up disabling a bunch of CONFIG options. Now this
> >> requirement can be satisfied easily by adding something like
> >> NO_PV_SHIM_EXCLUSIVE. However, it would go somewhat against the previous
> >> requirement.
> >>
> >> So we need a compromise, something that doesn't end up disabling other
> >> CONFIG options, to make allyesconfig happy, but also not too confusing
> >> for the user (which is a matter of personal opinion).
> >>
> >> In short, expect that people will have different opinions on this and
> >> will find different compromises better or worse. For one, I prefer to
> >> compromise on "no negative CONFIG options" and use
> >> PV_SHIM_NOT_EXCLUSIVE. Because it serves the allyesconfig goal, and
> >> while it is not as clear as PV_SHIM_EXCLUSIVE, is still better than a
> >> completely generic FULL_HYPERVISOR option, which means nothing to me.
> >>
> >> I cannot see a way to have a good and clear non-negated CONFIG option,
> >> and also satisfy the allyesconfig requirement. So I prefer to compromise
> >> on the "non-negated" part.
> > 
> > Debating the naming is missing the point.
> > 
> > 
> > The problem here is the wish to have PV_SHIM_EXCLUSIVE behave in a way
> > that Kconfig is not capable of expressing.  Specifically, what is broken
> > is having "lower level" options inhibit unrelated "higher level" options
> > when the graph gets rescanned[1].  That's why we're in the laughable
> > position of `make allyesconfig` turning off CONFIG_HVM.
> > 
> > Jan, you want "echo PV_SHIM_EXCLUSIVE=y >> .config && make" to mean
> > "reset me back to a PV Shim".
> 
> Isn't this an independent goal? Or is this a statement on what you see
> my change (kind of) doing, indicating you consider this wrong?

The way I understood it, it is the latter


> > Kconfig spells this "make $foo_defconfig" for an appropriately given foo.
> > 
> > 
> > There should be:
> > 
> > 1) an option called PV_SHIM_EXCLUSIVE which does *nothing* other than
> > making the boolean be a compile time constant.
> 
> I fear it remains unclear to me what exactly you mean here. It feels like
> you may be suggesting that all other uses of PV_SHIM_EXCLUSIVE should be
> dropped, without replacement. That seems wrong to me, though. In
> particular I'm of the opinion that besides using "make pvshim_defconfig"
> people ought to also have the option to properly configure a shim build
> from scratch (or from any random .config they hold in hands), requiring
> respective "depends on" and/or "select" / "imply" to be in place.

That should be done with "make pvshim_defconfig"


> Or else they may end up with a lot of dead code. (Just consider e.g.
> HVM=n: We also don't permit HVM-only stuff to be enabled in that case,
> as any of that would again be dead code then.)

It will always be possible to come up with poor configurations. I do not
believe it is necessarily our responsibility to go out of our way to
prevent them.


> > 2) a pvshim_defconfig target which expresses what a pvshim ought to look
> > like.
> 
> We have this file already. I consider it debatable though whether this file
> should really force PV_SHIM_EXCLUSIVE=y. People may read "pvshim" in the
> name as either "works just as shim" or "can also work as shim".

If I understood it right, I like Andrew's suggestion. He is suggesting
to do the following:

- turning PV_SHIM_EXCLUSIVE into something that does nothing
- adding "make pvshim_defconfig"

So that:

- people use "make pvshim_defconfig" to get what today is enabled by
  PV_SHIM_EXCLUSIVE
- but "make allyesconfig" doesn't end up disabling things
- the Kconfig menu makes sense because PV_SHIM_EXCLUSIVE goes away and
  it is not replaced by anything

If I got it right, I am in favor.
--8323329-1689403285-1737415649=:11086--


From xen-devel-bounces@lists.xenproject.org Mon Jan 20 23:38:35 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Jan 2025 23:38:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875090.1285407 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ta1Lj-00042A-TM; Mon, 20 Jan 2025 23:38:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875090.1285407; Mon, 20 Jan 2025 23:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ta1Lj-000423-Qh; Mon, 20 Jan 2025 23:38:31 +0000
Received: by outflank-mailman (input) for mailman id 875090;
 Mon, 20 Jan 2025 23:38:30 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=fP4x=UM=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1ta1Li-00041x-Gw
 for xen-devel@lists.xenproject.org; Mon, 20 Jan 2025 23:38:30 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a59f0e46-d787-11ef-99a4-01e77a169b0f;
 Tue, 21 Jan 2025 00:38:28 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 0311B5C4B41;
 Mon, 20 Jan 2025 23:37:46 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7C64CC4CEDD;
 Mon, 20 Jan 2025 23:38:25 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a59f0e46-d787-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1737416306;
	bh=TW9EPxz+4Go5O6VN3cVzyvM0MaYeMTbTiX7vYd4r3Ac=;
	h=Date:From:To:cc:Subject:From;
	b=pP3zfSwLBIe3m8rfK8nGYTcssAF2ne68X+PlwKUqloDMHVzUvjYzPncryY+/R3fo4
	 OME8FE372qhaUt8+y9zK0ZsEPDqmmwhFCYEjWrCSDhVrHtkf2L+aLthaGUVUZRU7Jk
	 qVOUuoiRbZPYfqhX4Uognbbxiwy64X1Oka/yVIBzpkWG/HsL84PS3YpwzoUMioZks5
	 kW8zKfrV/uXeESbmOX1CqfDl0ZFDRpadPTwf1bTKLQ/Smxw8+jTdoZcIyOPs+P6tyL
	 M0qlH1hOrONTP/7sXXDY/9qnNj7EDKmW5YI4p01w1t473FbsUP3s3/LnPqlOYzaDG1
	 FPmLLi0IseJ+Q==
Date: Mon, 20 Jan 2025 15:38:24 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: linux-kernel@vger.kernel.org
cc: sstabellini@kernel.org, jgross@suse.com, xen-devel@lists.xenproject.org, 
    jbeulich@suse.com
Subject: [PATCH v4] xen: update pvcalls_front_accept prototype
Message-ID: <alpine.DEB.2.22.394.2501201537560.11086@ubuntu-linux-20-04-desktop>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

While currently there are no in-tree callers of these functions, it is
best to keep them up-to-date with the latest network API.

In addition, add the missing EXPORT_SYMBOL_GPL to the functions listed
in pvcalls-front.h.

Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
---
Changes in v4:
- add the missing EXPORT_SYMBOL_GPL

Changes in v3:
- expand commit message
---
 drivers/xen/pvcalls-front.c | 14 ++++++++++++--
 drivers/xen/pvcalls-front.h |  2 +-
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
index b72ee9379d77..4926d4badc57 100644
--- a/drivers/xen/pvcalls-front.c
+++ b/drivers/xen/pvcalls-front.c
@@ -341,6 +341,7 @@ int pvcalls_front_socket(struct socket *sock)
 	pvcalls_exit();
 	return ret;
 }
+EXPORT_SYMBOL_GPL(pvcalls_front_socket);
 
 static void free_active_ring(struct sock_mapping *map)
 {
@@ -486,6 +487,7 @@ int pvcalls_front_connect(struct socket *sock, struct sockaddr *addr,
 	pvcalls_exit_sock(sock);
 	return ret;
 }
+EXPORT_SYMBOL_GPL(pvcalls_front_connect);
 
 static int __write_ring(struct pvcalls_data_intf *intf,
 			struct pvcalls_data *data,
@@ -581,6 +583,7 @@ int pvcalls_front_sendmsg(struct socket *sock, struct msghdr *msg,
 	pvcalls_exit_sock(sock);
 	return tot_sent;
 }
+EXPORT_SYMBOL_GPL(pvcalls_front_sendmsg);
 
 static int __read_ring(struct pvcalls_data_intf *intf,
 		       struct pvcalls_data *data,
@@ -666,6 +669,7 @@ int pvcalls_front_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
 	pvcalls_exit_sock(sock);
 	return ret;
 }
+EXPORT_SYMBOL_GPL(pvcalls_front_recvmsg);
 
 int pvcalls_front_bind(struct socket *sock, struct sockaddr *addr, int addr_len)
 {
@@ -719,6 +723,7 @@ int pvcalls_front_bind(struct socket *sock, struct sockaddr *addr, int addr_len)
 	pvcalls_exit_sock(sock);
 	return 0;
 }
+EXPORT_SYMBOL_GPL(pvcalls_front_bind);
 
 int pvcalls_front_listen(struct socket *sock, int backlog)
 {
@@ -768,8 +773,10 @@ int pvcalls_front_listen(struct socket *sock, int backlog)
 	pvcalls_exit_sock(sock);
 	return ret;
 }
+EXPORT_SYMBOL_GPL(pvcalls_front_listen);
 
-int pvcalls_front_accept(struct socket *sock, struct socket *newsock, int flags)
+int pvcalls_front_accept(struct socket *sock, struct socket *newsock,
+			 struct proto_accept_arg *arg)
 {
 	struct pvcalls_bedata *bedata;
 	struct sock_mapping *map;
@@ -788,7 +795,7 @@ int pvcalls_front_accept(struct socket *sock, struct socket *newsock, int flags)
 		return -EINVAL;
 	}
 
-	nonblock = flags & SOCK_NONBLOCK;
+	nonblock = arg->flags & SOCK_NONBLOCK;
 	/*
 	 * Backend only supports 1 inflight accept request, will return
 	 * errors for the others
@@ -904,6 +911,7 @@ int pvcalls_front_accept(struct socket *sock, struct socket *newsock, int flags)
 	pvcalls_exit_sock(sock);
 	return ret;
 }
+EXPORT_SYMBOL_GPL(pvcalls_front_accept);
 
 static __poll_t pvcalls_front_poll_passive(struct file *file,
 					       struct pvcalls_bedata *bedata,
@@ -1004,6 +1012,7 @@ __poll_t pvcalls_front_poll(struct file *file, struct socket *sock,
 	pvcalls_exit_sock(sock);
 	return ret;
 }
+EXPORT_SYMBOL_GPL(pvcalls_front_poll);
 
 int pvcalls_front_release(struct socket *sock)
 {
@@ -1087,6 +1096,7 @@ int pvcalls_front_release(struct socket *sock)
 	pvcalls_exit();
 	return 0;
 }
+EXPORT_SYMBOL_GPL(pvcalls_front_release);
 
 static const struct xenbus_device_id pvcalls_front_ids[] = {
 	{ "pvcalls" },
diff --git a/drivers/xen/pvcalls-front.h b/drivers/xen/pvcalls-front.h
index f694ad77379f..881ef14660bc 100644
--- a/drivers/xen/pvcalls-front.h
+++ b/drivers/xen/pvcalls-front.h
@@ -12,7 +12,7 @@ int pvcalls_front_bind(struct socket *sock,
 int pvcalls_front_listen(struct socket *sock, int backlog);
 int pvcalls_front_accept(struct socket *sock,
 			 struct socket *newsock,
-			 int flags);
+			 struct proto_accept_arg *arg);
 int pvcalls_front_sendmsg(struct socket *sock,
 			  struct msghdr *msg,
 			  size_t len);
-- 
2.25.1


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 06:15:07 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 06:15:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875102.1285418 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ta7XI-0007Uk-Ov; Tue, 21 Jan 2025 06:14:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875102.1285418; Tue, 21 Jan 2025 06:14:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ta7XI-0007Uc-JE; Tue, 21 Jan 2025 06:14:52 +0000
Received: by outflank-mailman (input) for mailman id 875102;
 Tue, 21 Jan 2025 06:14: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
 <SRS0=I1SE=UN=amd.com=penny.zheng@srs-se1.protection.inumbo.net>)
 id 1ta7XG-0007UB-Qo
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 06:14:51 +0000
Received: from NAM02-SN1-obe.outbound.protection.outlook.com
 (mail-sn1nam02on2060f.outbound.protection.outlook.com
 [2a01:111:f403:2406::60f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0321d29d-d7bf-11ef-a0e4-8be0dac302b0;
 Tue, 21 Jan 2025 07:14:47 +0100 (CET)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 DS0PR12MB9322.namprd12.prod.outlook.com (2603:10b6:8:1bd::14) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8356.21; Tue, 21 Jan 2025 06:14:35 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%4]) with mapi id 15.20.8356.017; Tue, 21 Jan 2025
 06:14:35 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 0321d29d-d7bf-11ef-a0e4-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=uYnW2RliAK95Irhli0gwiMUGP3M4TMFWuU+8U5kAuK7FgcBuRE1Kh+3JjSc4vUWWSNU6pxUNomNWdw2VfIHkkt5ChIjwYtDhsYaSejMgsTfXABM6YfmfJyCK7de9mgUXJYzy1dSVp5MK3slXBzevdu3FJ1yfuKUKT9bzg1TeTqJX0TzPdFJZAWchTwLyM95LmQ5HC93jvrLs8w5ALlYQ+O5dmuFKRF35ao9okCOZKxWLe/x1LzSi5gNXmDUtPSIQO04MjloREfDasytwlzH3Fqp9vTto6KnGT6o7+CKIrw7JmUopS2HIozpJ6D1bcwdR27FIPlpCZSvHC5y7egiUhg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=fG836oHwTdrPMz2amjx3nm1KdAkHqkh6gz3fUaNbtbw=;
 b=cdUkaMz3KvvntgENijOrCna06NwxEpnSyjb4tpMcMoARPvO7nZUxWzb0kL0rc7igALShEIRjN0rHLQB8vIZ+WTu2bD4MQl5KcNLYQjXb13UyNw9Pd+HWJm4HeZvPfzJ+NjqG4aDOQ2iNZxraTyYsFTjYoLgFU1dGPHJfQQlrI06ADn/aTh7jNNgZQmeGoJq0u+pNVMa1eH6CjHfD1AfFsGuQofu0pBq1IVSo5Z08tI9dV2F2VmCF+SrpzDrPwa7pFFjIIhbdwVTH9+7xa+RUewidwOEhj68JpitRAszI040kxBEYS2TTRdUiLNqF/UreaUpi9OaZ4B87gvPCPWdzAA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=fG836oHwTdrPMz2amjx3nm1KdAkHqkh6gz3fUaNbtbw=;
 b=46aKrLorluoPBnctHo7D2DIotC5+S6dQtmzj4gP2SW4o2ajHuwlSk8KcKZbesOQJezVPW8Ms0ykdlyoH5/C5xhbaCQIuJ03zGiCIw+TFZJ4oJGUcwR8DJ/wRB+JzC4xRS6o1C0hFfRyXObm8OcU1xl2JYl71YJeyknoDNfaE24o=
From: "Penny, Zheng" <penny.zheng@amd.com>
To: Jan Beulich <jbeulich@suse.com>
CC: "Stabellini, Stefano" <stefano.stabellini@amd.com>, "Huang, Ray"
	<Ray.Huang@amd.com>, "Ragiadakou, Xenia" <Xenia.Ragiadakou@amd.com>,
	"Andryuk, Jason" <Jason.Andryuk@amd.com>, Andrew Cooper
	<andrew.cooper3@citrix.com>, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	<roger.pau@citrix.com>, "xen-devel@lists.xenproject.org"
	<xen-devel@lists.xenproject.org>
Subject: RE: [PATCH v1 05/11] xen/x86: introduce a new amd pstate driver for
 cpufreq scaling
Thread-Topic: [PATCH v1 05/11] xen/x86: introduce a new amd pstate driver for
 cpufreq scaling
Thread-Index: AQHbRVybhl3TP2LETk2QrPDVcEclFLMOfzaAgBE8HHA=
Date: Tue, 21 Jan 2025 06:14:35 +0000
Message-ID:
 <DM4PR12MB8451942DEC644085A16F2391E1E62@DM4PR12MB8451.namprd12.prod.outlook.com>
References: <20241203081111.463400-1-Penny.Zheng@amd.com>
 <20241203081111.463400-6-Penny.Zheng@amd.com>
 <f7f03617-e438-48c1-b5b0-1ca975cbc7e6@suse.com>
In-Reply-To: <f7f03617-e438-48c1-b5b0-1ca975cbc7e6@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_ActionId=78932ae9-7ceb-46b5-b1bd-5573345af994;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_ContentBits=0;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_Enabled=true;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_Method=Standard;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_Name=AMD
 Internal Distribution
 Only;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_SetDate=2025-01-20T10:06:50Z;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DM4PR12MB8451:EE_|DS0PR12MB9322:EE_
x-ms-office365-filtering-correlation-id: e45c6755-7a72-49ee-c468-08dd39e2e0c4
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?QUR6Y09ZbFd4RFpiVjVBd3dXeU1Jb0hOMkRUTTE3RnFRSzZTZUg0Qzd3M1RI?=
 =?utf-8?B?clE5U0NmV0lQVDB2TlN6enFjenl4RC9MMm5EWEFRNVZWUFZnK2ptYVVUblIx?=
 =?utf-8?B?V1ZZSXZJZTgxZnlMSHBqbnZtNW9CbVp0M0NQT0ExNktGNW9yRkYzZzhndVB1?=
 =?utf-8?B?UlQ3R3drb0swQWtWUzRXVkxEQXViNDhRRllETjZtZDJoVFZSeWZmVUtmaHcz?=
 =?utf-8?B?eTRKeWNCOTB0REJ2NGZXUjhucEtEdXpDKzlya2h6VFBhUzAwR3FhRzg3ZlZa?=
 =?utf-8?B?Z0cvU2o4MWJXZ3UzWngwbStIMnY2bDNiTnY4QjVUb2dOdVQzdlUrd2E5VlZK?=
 =?utf-8?B?WE0zdDFaTXV4SG5ad3FrTU5OU3BMYVZJblAxQ3hUT2VLS09EMXVCNkJDWHBN?=
 =?utf-8?B?ZDU5TE9LM2ZzSlJkQWJTYUdvVE0yTDRKM3JpYnJzNHVYOURpQVMxRDRDTHln?=
 =?utf-8?B?OTRWQmtVVk5qdVNVZGNnWGl6aG1HMyt3RktrVHkyaXJiWWVTNnZLamZLLytj?=
 =?utf-8?B?dEVVc3M2cUlHM3E4RmhIWHpTWTV5VGZyOFZxSVJQU0xSSUNEakJ1SUF0aHM5?=
 =?utf-8?B?UGxrVEhMa1hPRVdyMkxIUWkyWG9MNU4yVVBHOERMUTE2eWN4U0NPK00yaGJR?=
 =?utf-8?B?QTNMSjk1QlU0SUpqaDZjS2dGcmcyME10a0hrQ1ExS2szOEMrMTk3amNVbGk4?=
 =?utf-8?B?Z3dlSzIwYXJ6dGpwLzNteWZzWENjd2lzaEZHajdLMVdTakhaekJtZlVRQnFC?=
 =?utf-8?B?MXBQTU1vSy91S1luMUx3K0VlS3dwZmY3eGhQaDR4L2RvYVowMmF2NlRQKzJJ?=
 =?utf-8?B?QnpKMUJ3WUlTMm9Xc2JDbjRadi9BQUFLNGVoSmk4RC9hWnVTclRoWWdRYlRj?=
 =?utf-8?B?R01rY0RTMFlicTRXdWZFbUFBaURBRFE4L1ZTNUdtT1kwTGdHbE1yeU42ejVV?=
 =?utf-8?B?dUdnTUdidDhZZXlHYzlqS2FBSk1pSkJhWVRSNGFvL1dqUnRUSG5aN0U5VzI3?=
 =?utf-8?B?RlltSTJyVXBBN3pyRE9wSC9kTE1hcndMZTdiVENlbkp3VTAvU3NnWnRJOUNs?=
 =?utf-8?B?ODdHQkVLZ1NmRzk4VkhsaUFxTk5yUlZmN0ZQZmQ5Nm1RTzZIc1FmZDc3WEdk?=
 =?utf-8?B?UUovU2k0TktDSjNQWUNYVStLUFkwamRJdVpWQ1RjSFljV1lnME1sWG02cHgy?=
 =?utf-8?B?WURsVXBjK29RODdnVzhvZDNZZmUwL2JsWTNaczB5azdnK0x3QUsyTWM3VG14?=
 =?utf-8?B?ZmxUc3I1RHAyUlV2NVAyRzVvdnpZK2g0ZUpNVTAxODluSmt1djdKS2RJSlN3?=
 =?utf-8?B?WkxVVk1ibVhucGdHZzVyOXlJUEwyTzZFdi9vMVN2a3VmNllBUjgwb1V3d3g0?=
 =?utf-8?B?Uk1RdWJTUEQzRStlY0k5bTArR1lreXE4TVZtT3FlMGZGR1ZJMkJNdHc3bWlx?=
 =?utf-8?B?WGQ4V0hkQUgrNkZYZ1F2K1FwOWFzTi8zTDR6cjJSdkJHRDZUZEZDRDhCQnRx?=
 =?utf-8?B?enRzd2VuTkdSWmtyQkVUaHFXTWR6SFZzR2RlSlhEWWxLT2RxS0ZHYndyck5M?=
 =?utf-8?B?R3NCN1A1VkYwdFJhNk8rZUorREhVMWduS3ZKQnp4VjVuWjg0S2tNQllaUjBt?=
 =?utf-8?B?RDl2Nk1QUWY3M292aXBvNFc4NXhoMWd3bldJNVNnVWRSRWJxY0YrQ3lERWFU?=
 =?utf-8?B?SmxGcTc3TWZIQVl5dVpPOWF5aGh0L1Z6alF6cThJQ0ljNjlvcFBWQTdrOWUz?=
 =?utf-8?B?Z0NzMkw1aWlFYkdOQStEbDZnKzFqbEd4V1JJMjI1bTFhMDNuVk1FMzA4a3Fj?=
 =?utf-8?B?cEwwUXVGclFJS1NLRVJRejl6emY3ME8vUWlBMVllWHNjTmhOSlZ1QnhPZ3ov?=
 =?utf-8?B?TjVCek5QZnc2a1JHWi9wbFRkbkFHZFdPYVpuNTJVTGNLVzdRZU5tdHE4L2Nr?=
 =?utf-8?Q?9G8vL1U5Y96q6HJEf0A/XZ4DBFCMfOCh?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB8451.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?aFZqU1k1RlQyUXc3aWVXWFlxc3FRMEJtVFA1ejhtQW1LMVJnelV0d3pOSm85?=
 =?utf-8?B?UFluT0dnYTZlejN6V0swelNCRUQxZkNhNkpodzVRcjlmekowTHMrbjN4RWw0?=
 =?utf-8?B?QUh0UWwwSDVBaERCU3FxTFRPV2Qrd1NBRTIzT0lzTTQ4ZVVCMTdaeCtFV2U3?=
 =?utf-8?B?eXRUOGZEU3BKL0pPSmhNdUVSa2s1WE8zeXFLalQ5U0J6Q21BY0FyN3ZLbFVz?=
 =?utf-8?B?Rkp4eXJrckdvNlNHNnpIUGV4MzFodjhPUndzN1FlT2w4d1lLYUVvR2hFRFZp?=
 =?utf-8?B?b3FJTVdSVFRmRzNNYm9lZDk3bThaOVJ4dDVmcWhoSnAwcGcvV3Z1VisyVVMr?=
 =?utf-8?B?VTBoWTFXckZzbGJhaDdhVHZOelh0RkhiYTQyYjVHZXBtZjdHakdVUi9QV2Vw?=
 =?utf-8?B?YmpkNjJxUUNxY3p0MWtBR3B2Q0g3cHMwY2t3RGJrNEF2Slgva2NSQXhmMlpk?=
 =?utf-8?B?ejRLajZ3Q2R1cC9CT01hcUU4NENNSGVpczd4cWdQN3czeWtGbjhnYmYzTDdQ?=
 =?utf-8?B?RENFMC9SdllyMVVLaXhra0dnaUI1M0VDNXpvb1FqV1F2dWg4RC9pRTJieUdV?=
 =?utf-8?B?M25aRnBLRFdpeTZuUjh1dVpLemRqWWpEMUxXaVVCTENLRVdQaWcveml3NWN4?=
 =?utf-8?B?bEd6K3hTTWt3dHI2RENmSjF1RnZhMlluYUNxWFRRcXJ4ZVdhQWNRaWJURU5n?=
 =?utf-8?B?czdmVDdkQnZOdElQZmJxbTErVlMxR2JvVEczN2MyRy9RcUxOcVZzQWVrOGF0?=
 =?utf-8?B?eEQzV0pnSWk0cTZJWVRRRkJ0NXlXRUsxeVk3clFadHVpdlBQclg0N1hiOStl?=
 =?utf-8?B?R3EyZDNSYmlaUExWRGh6NUtRMlRiTTVXT2ZzanJuTjl3czdDeDZQbk1EZjIr?=
 =?utf-8?B?Und0cVBhSGhqUWl0cmNtVU9Id3BCazF3VmoydTRNT0owR1NmNWM3R1h5ZUhy?=
 =?utf-8?B?SmJQdnJsTEd4b21HU0M3cWdvdzVvMHJsbU9WUVoyZlhzaFcrNGlwZUhhWjND?=
 =?utf-8?B?MGtkelRiN2VPcUdFNEE1amUvZFhveXNaUmlFSzVnRDlYTVJ2NGdLUDJnS1FD?=
 =?utf-8?B?NGJBWE55MFN4M1kzSFFhckVjN25IUW9GdlhLT216SksrVjFoMjNyWmh5emRi?=
 =?utf-8?B?U25ScG9lWWRmL3cveGd1M1pTaElqbzlJekpqS3dMNktXL2c4QzBJK1ltR0ZR?=
 =?utf-8?B?aDdpcTdTR3FjR3ZYV3h5ZnlCV0pndjVwMW9zWnFPUzRIVXhqS1VMSnZyQ1pD?=
 =?utf-8?B?aW1KUllHcGJrT3FnTzdJSVQ2bDMvc3h2N1BaMFllQ0ppR3J0OHI1eEFuR1BF?=
 =?utf-8?B?UXNIdkRWNWJCMlk2bEhDSjZqVVdndmNXcnNHekl2NzJZczlrQWFNcnE4VjB4?=
 =?utf-8?B?eUZ3YlVzclV2eTNER2N0M3BiS255dHhXQzB0SStIS3p3NFh0YTJLSlFWWStn?=
 =?utf-8?B?UnRvZ3o2NmJiOElUY01QMGZlWlZEeUhxWDZtUWFmeUMzMnJBbW9YWjFiTmJQ?=
 =?utf-8?B?a2xrYStSVDkyam5oV3liR1RlalRhdExNNUQ1WkRabVIxcys4YVF2YVZ2OW03?=
 =?utf-8?B?Uzcvb3lPcWNRZFpSYWc5MytKelFBS3BSNGlyZUtITmNqWjlwc1RiS0FDL0Ev?=
 =?utf-8?B?RkhSVldPZ1FuNkhLbjI1Q0xveUhNQS9BTFg1cndOdGd1Q1V0eEVkL3N0SHB5?=
 =?utf-8?B?T2FnM2ZldzZGYjUvLzE0aXRHcmZuaVlHUWZCTWlNSnpqeExXaWFsbkZnM1Uy?=
 =?utf-8?B?a25FNW5BaGM0dDdydmJKencrRHJieTVZdEZSZy9COTRpUjRrMzFXR2t1UmpW?=
 =?utf-8?B?VmY1M3NjVUVjUGRDZWhnWDZrYXJQV2REMDNPd3VUbUJaM28zWDZxM1NBMUhu?=
 =?utf-8?B?RHBMbzZ3S2I0bC9ORVN0MkRTTWdoZk5oTjNiQXRoNVhaNE16TzNtekpaanBU?=
 =?utf-8?B?OVFDWnhpMWppb0k0eHNBaWF2eHM5U0FGRHRYWVo3ZkEvdE1IcHp3ak5qUmVh?=
 =?utf-8?B?VThpa1JKVk9uUXB1eDZsYjlLTlQ3TjQ5RGJCY2V2dS8wUW04c1hHWlVQQjgr?=
 =?utf-8?B?dHJVRW5JTjJzZ3ZrR3lFSXJuM0l4azcxYzV3cUFOM2poOUd1SDdQSytVZHFV?=
 =?utf-8?Q?ezAM=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB8451.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e45c6755-7a72-49ee-c468-08dd39e2e0c4
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2025 06:14:35.2696
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 7qp7fnBMYtphhd+gdClBXjyoWCCYD1Wu9l21uIAAtJCAY2EuFdCGANtrus0L1ZYXCFPremt4FX6jZFVdul+5Qw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB9322

W0FNRCBPZmZpY2lhbCBVc2UgT25seSAtIEFNRCBJbnRlcm5hbCBEaXN0cmlidXRpb24gT25seV0N
Cg0KSGksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSmFuIEJldWxp
Y2ggPGpiZXVsaWNoQHN1c2UuY29tPg0KPiBTZW50OiBUaHVyc2RheSwgSmFudWFyeSA5LCAyMDI1
IDY6NTUgUE0NCj4gVG86IFBlbm55LCBaaGVuZyA8cGVubnkuemhlbmdAYW1kLmNvbT4NCj4gQ2M6
IFN0YWJlbGxpbmksIFN0ZWZhbm8gPHN0ZWZhbm8uc3RhYmVsbGluaUBhbWQuY29tPjsgSHVhbmcs
IFJheQ0KPiA8UmF5Lkh1YW5nQGFtZC5jb20+OyBSYWdpYWRha291LCBYZW5pYSA8WGVuaWEuUmFn
aWFkYWtvdUBhbWQuY29tPjsNCj4gQW5kcnl1aywgSmFzb24gPEphc29uLkFuZHJ5dWtAYW1kLmNv
bT47IEFuZHJldyBDb29wZXINCj4gPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+OyBSb2dlciBQ
YXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT47IHhlbi0NCj4gZGV2ZWxAbGlzdHMueGVu
cHJvamVjdC5vcmcNCj4gU3ViamVjdDogUmU6IFtQQVRDSCB2MSAwNS8xMV0geGVuL3g4NjogaW50
cm9kdWNlIGEgbmV3IGFtZCBwc3RhdGUgZHJpdmVyIGZvcg0KPiBjcHVmcmVxIHNjYWxpbmcNCj4N
Cj4gT24gMDMuMTIuMjAyNCAwOToxMSwgUGVubnkgWmhlbmcgd3JvdGU6DQo+ID4gLS0tIGEveGVu
L2FyY2gveDg2L2FjcGkvY3B1ZnJlcS9hbWQtcHN0YXRlLmMNCj4gPiArKysgYi94ZW4vYXJjaC94
ODYvYWNwaS9jcHVmcmVxL2FtZC1wc3RhdGUuYw0KPiA+IEBAIC0xNSw2ICsxNSw1MyBAQA0KPiA+
ICAjaW5jbHVkZSA8eGVuL2luaXQuaD4NCj4gPiAgI2luY2x1ZGUgPHhlbi9wYXJhbS5oPg0KPiA+
ICAjaW5jbHVkZSA8YWNwaS9jcHVmcmVxL2NwdWZyZXEuaD4NCj4gPiArI2luY2x1ZGUgPGFzbS9t
c3IuaD4NCj4gPiArDQo+ID4gKyNkZWZpbmUgYW1kX3BzdGF0ZV9lcnIoY3B1LCBmbXQsIGFyZ3Mu
Li4pIFwNCj4gPiArICAgIHByaW50ayhYRU5MT0dfRVJSICJBTURfUFNUQVRFOiBDUFUldSBlcnJv
cjogIiBmbXQsIGNwdSwgIyMgYXJncykNCj4gPiArI2RlZmluZSBhbWRfcHN0YXRlX3ZlcmJvc2Uo
Zm10LCBhcmdzLi4uKSAgICAgICAgICAgICAgICAgICAgICAgICBcDQo+ID4gKyh7ICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXA0K
PiA+ICsgICAgaWYgKCBjcHVmcmVxX3ZlcmJvc2UgKSAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIFwNCj4gPiArICAgICAgICBwcmludGsoWEVOTE9HX0RFQlVHICJBTURfUFNU
QVRFOiAiIGZtdCwgIyMgYXJncyk7ICAgICAgICBcDQo+ID4gK30pDQo+ID4gKyNkZWZpbmUgYW1k
X3BzdGF0ZV93YXJuKGZtdCwgYXJncy4uLikgXA0KPiA+ICsgICAgcHJpbnRrKFhFTkxPR19XQVJO
SU5HICJBTURfUFNUQVRFOiBDUFUldSB3YXJuaW5nOiAiIGZtdCwgY3B1LA0KPiAjIw0KPiA+ICth
cmdzKQ0KPiA+ICsNCj4gPiArc3RydWN0IGFtZF9wc3RhdGVfZHJ2X2RhdGENCj4gPiArew0KPiA+
ICsgICAgc3RydWN0IHhlbl9wcm9jZXNzb3JfY3BwYyAqY3BwY19kYXRhOw0KPiA+ICsgICAgdW5p
b24NCj4gPiArICAgIHsNCj4gPiArICAgICAgICB1aW50NjRfdCBhbWRfY2FwczsNCj4gPiArICAg
ICAgICBzdHJ1Y3QNCj4gPiArICAgICAgICB7DQo+ID4gKyAgICAgICAgICAgIHVuc2lnbmVkIGlu
dCBsb3dlc3RfcGVyZjo4Ow0KPiA+ICsgICAgICAgICAgICB1bnNpZ25lZCBpbnQgbG93ZXN0X25v
bmxpbmVhcl9wZXJmOjg7DQo+ID4gKyAgICAgICAgICAgIHVuc2lnbmVkIGludCBub21pbmFsX3Bl
cmY6ODsNCj4gPiArICAgICAgICAgICAgdW5zaWduZWQgaW50IGhpZ2hlc3RfcGVyZjo4Ow0KPiA+
ICsgICAgICAgICAgICB1bnNpZ25lZCBpbnQgOjMyOw0KPiA+ICsgICAgICAgIH0gaHc7DQo+DQo+
IFBsZWFzZSBjYW4gdGhpcyBiZQ0KPg0KPg0KPiAgICAgdW5pb24gew0KPiAgICAgICAgIHVpbnQ2
NF90IHJhdzsNCj4gICAgICAgICBzdHJ1Y3Qgew0KPiAgICAgICAgICAgICB1bnNpZ25lZCBpbnQg
bG93ZXN0X3BlcmY6ODsNCj4gICAgICAgICAgICAgdW5zaWduZWQgaW50IGxvd2VzdF9ub25saW5l
YXJfcGVyZjo4Ow0KPiAgICAgICAgICAgICB1bnNpZ25lZCBpbnQgbm9taW5hbF9wZXJmOjg7DQo+
ICAgICAgICAgICAgIHVuc2lnbmVkIGludCBoaWdoZXN0X3BlcmY6ODsNCj4gICAgICAgICAgICAg
dW5zaWduZWQgaW50IDozMjsNCj4gICAgICAgICB9Ow0KPiAgICAgfSBjYXBzOw0KPg0KPiBzdWNo
IHRoYXQgYXQgdXNlIHNpdGVzIChlLmcuIGFtZF9wc3RhdGVfd3JpdGVfcmVxdWVzdCgpKSBpdCBp
cyBwb3NzaWJsZSB0byBhY3R1YWxseQ0KPiBzcG90IHRoYXQgdGhlIHNhbWUgdGhpbmcgaXMgYmVp
bmcgYWNjZXNzZWQgdGhyb3VnaCB0aGUgdHdvIHBhcnRzIG9mIHRoZSB1bmlvbj8NCj4NCg0KVW5k
ZXJzdG9vZC4NCg0KPiA+ICsgICAgew0KPiA+ICsgICAgICAgIC8qIFJlYWQgUHJvY2Vzc29yIE1h
eCBTcGVlZChtaHopIGZyb20gRE1JIHRhYmxlIGFzIGFuY2hvciBwb2ludCAqLw0KPiA+ICsgICAg
ICAgIG11bCA9IGRtaV9tYXhfc3BlZWRfbWh6Ow0KPiA+ICsgICAgICAgIGRpdiA9IGRhdGEtPmh3
LmhpZ2hlc3RfcGVyZjsNCj4gPiArDQo+ID4gKyAgICAgICAgcmV0dXJuICh1bnNpZ25lZCBpbnQp
KG11bCAvIGRpdikgKiBkYXRhLT5ody5sb3dlc3RfcGVyZiAqDQo+ID4gKyAxMDAwOw0KPg0KPiBO
byByaXNrIG9mIHRoZSBjYXN0IGNob3BwaW5nIG9mZiBzZXQgYml0cz8NCg0KTXVsIHNoYWxsIGJl
IHVpbnQ2NF90LCBoaWdoZXN0X3BlcmYgYW5kIGxvd2VzdF9wZXJmIHNoYWxsIGJlIHVpbnQ4X3Qs
IGFuZCBub3JtYWxseQ0KdGhlIGVxdWF0aW9uIG91dHB1dCBzaGFsbCBub3QgYmUgYSB0b28gYmln
IHZhbHVlLi4uDQpJZiB5b3UgdGhpbmsgaXQncyBzYWZlciB0byBkbyBjYXN0IGFmdGVyIGNvbXBh
cmluZyB3aXRoIHRoZSBVSU5UMzJfTUFYLCBJIHdpbGwgYWRkIHRoZSBjaGVjaw0KDQo+DQo+ID4g
Kw0KPiA+ICtzdGF0aWMgaW50IGNmX2NoZWNrIGFtZF9wc3RhdGVfY3B1ZnJlcV92ZXJpZnkoc3Ry
dWN0IGNwdWZyZXFfcG9saWN5DQo+ID4gKypwb2xpY3kpIHsNCj4gPiArICAgIHN0cnVjdCBhbWRf
cHN0YXRlX2Rydl9kYXRhICpkYXRhID0gcGVyX2NwdShhbWRfcHN0YXRlX2Rydl9kYXRhLA0KPiA+
ICtwb2xpY3ktPmNwdSk7DQo+DQo+IENvbnN0PyAoSSB3b24ndCBmdXJ0aGVyIHJlcGVhdCB0aGlz
LiBQbGVhc2UgbWFrZSBwb2ludGVycyBwb2ludGVyLXRvLSBjb25zdA0KPiB3aGVyZXZlciBwb3Nz
aWJsZS4gV2UgYWltIGF0IGhhdmluZyBmdWxseSBjb25zdC1jb3JyZWN0IGNvZGUuKQ0KPg0KDQpT
dXJlLg0KDQo+ID4gK30NCj4gPiArDQo+ID4gK3N0YXRpYyB2b2lkIGNmX2NoZWNrIGFtZF9wc3Rh
dGVfaW5pdF9tc3JzKHZvaWQgKmluZm8pIHsNCj4gPiArICAgIHN0cnVjdCBjcHVmcmVxX3BvbGlj
eSAqcG9saWN5ID0gaW5mbzsNCj4gPiArICAgIHN0cnVjdCBhbWRfcHN0YXRlX2Rydl9kYXRhICpk
YXRhID0gdGhpc19jcHUoYW1kX3BzdGF0ZV9kcnZfZGF0YSk7DQo+ID4gKyAgICB1aW50NjRfdCB2
YWw7DQo+ID4gKyAgICB1bnNpZ25lZCBpbnQgbWluX2ZyZXEsIG5vbWluYWxfZnJlcSwgbWF4X2Zy
ZXE7DQo+ID4gKw0KPiA+ICsgICAgLyogUGFja2FnZSBsZXZlbCBNU1IgKi8NCj4gPiArICAgIGlm
ICggcmRtc3Jfc2FmZShNU1JfQU1EX0NQUENfRU5BQkxFLCB2YWwpICkNCj4NCj4gQmVmb3JlIHRy
eWluZyB0aGlzLCB3b3VsZG4ndCB5b3UgYmV0dGVyIGV4Y2x1ZGUgY2VydGFpbiB2ZXJ5IG9sZCBm
YW1pbGllcz8NCj4gRXZlbiBsb29raW5nIGF0IGEgcmFuZG9tIEZhbTE3IFBQUiBJIGNhbid0IHNw
b3QgZG9jdW1lbnRhdGlvbiBvZiB0aGlzIE1TUg0KPiAobm9yIHRoZSBvdGhlciB0d28pLCBkZXNw
aXRlIHlvdSBtZXJlbHkgc2F5aW5nIFplbiBlbHNld2hlcmUgKHdpdGhvdXQgYW55DQo+IHZlcnNp
b24gbnVtYmVyKS4NCj4NCg0KSSBzaGFsbCBjb21tZW50IG1vcmUgc3BlY2lmaWNhbGx5LCB0aGlz
IGZlYXR1cmUgaXMgZmlyc3RseSBpbnRyb2R1Y2VkIG9uIHNvbWUgWmVuMiBzZXJpZSwgbGlrZSBS
ZW5vaXINCkknbGwgZXhjbHVkZSB0aGUgZmFtaWxpZXMgYmVmb3JlIFplbihGYW0xN2gpDQoNCj4g
PiArICAgIHsNCj4gPiArICAgICAgICBhbWRfcHN0YXRlX2Vycihwb2xpY3ktPmNwdSwNCj4gInJk
bXNyX3NhZmUoTVNSX0FNRF9DUFBDX0VOQUJMRSlcbiIpOw0KPiA+ICsgICAgICAgIGRhdGEtPmVy
ciA9IC1FSU5WQUw7DQo+ID4gKyAgICAgICAgcmV0dXJuOw0KPiA+ICsgICAgfQ0KPiA+ICsNCj4g
PiArICAgIGlmICggISh2YWwgJiBBTURfQ1BQQ19FTkFCTEUpICkNCj4gPiArICAgIHsNCj4gPiAr
ICAgICAgICB2YWwgfD0gQU1EX0NQUENfRU5BQkxFOw0KPiA+ICsgICAgICAgIGlmICggd3Jtc3Jf
c2FmZShNU1JfQU1EX0NQUENfRU5BQkxFLCB2YWwpICkNCj4gPiArICAgICAgICB7DQo+ID4gKyAg
ICAgICAgICAgIGFtZF9wc3RhdGVfZXJyKHBvbGljeS0+Y3B1LA0KPiAid3Jtc3Jfc2FmZShNU1Jf
QU1EX0NQUENfRU5BQkxFLCAlbHgpXG4iLCB2YWwpOw0KPiA+ICsgICAgICAgICAgICBkYXRhLT5l
cnIgPSAtRUlOVkFMOw0KPiA+ICsgICAgICAgICAgICByZXR1cm47DQo+ID4gKyAgICAgICAgfQ0K
PiA+ICsgICAgfQ0KPg0KPiBEbyB5b3UgcmVhbGx5IG5lZWQgdG8gZW5hYmxlIGJlZm9yIHJlYWRp
bmcgLi4uDQo+DQo+ID4gKyAgICBpZiAoIHJkbXNyX3NhZmUoTVNSX0FNRF9DUFBDX0NBUDEsIGRh
dGEtPmFtZF9jYXBzKSApDQo+DQo+IC4uLiBjYXBhYmlsaXRpZXMgYW5kIC4uLg0KPg0KDQpZZXMu
DQpPbmx5IHdoZW4gQ1BQQyBpcyBlbmFibGVkLCB0aGUgaGFyZHdhcmUgd2lsbCBjYWxjdWxhdGUg
dGhlIHByb2Nlc3NvcuKAmXMgcGVyZm9ybWFuY2UgY2FwYWJpbGl0aWVzIGFuZA0KaW5pdGlhbGl6
ZSB0aGUgcGVyZm9ybWFuY2UgbGV2ZWwgZmllbGRzIGluIHRoZSBDUFBDIGNhcGFiaWxpdHkgcmVn
aXN0ZXJzLg0KU2VlIDE3LjYuMyBodHRwczovL3d3dy5hbWQuY29tL2NvbnRlbnQvZGFtL2FtZC9l
bi9kb2N1bWVudHMvcHJvY2Vzc29yLXRlY2gtZG9jcy9wcm9ncmFtbWVyLXJlZmVyZW5jZXMvMjQ1
OTMucGRmDQoNCj4gPiArICAgIHsNCj4gPiArICAgICAgICBhbWRfcHN0YXRlX2Vycihwb2xpY3kt
PmNwdSwgInJkbXNyX3NhZmUoTVNSX0FNRF9DUFBDX0NBUDEpXG4iKTsNCj4gPiArICAgICAgICBn
b3RvIGVycm9yOw0KPiA+ICsgICAgfQ0KPiA+ICsNCj4gPiArICAgIGlmICggZGF0YS0+aHcuaGln
aGVzdF9wZXJmID09IDAgfHwgZGF0YS0+aHcubG93ZXN0X3BlcmYgPT0gMCB8fA0KPiA+ICsgICAg
ICAgICBkYXRhLT5ody5ub21pbmFsX3BlcmYgPT0gMCB8fCBkYXRhLT5ody5sb3dlc3Rfbm9ubGlu
ZWFyX3BlcmYgPT0gMCApDQo+ID4gKyAgICB7DQo+ID4gKyAgICAgICAgYW1kX3BzdGF0ZV9lcnIo
cG9saWN5LT5jcHUsICJQbGF0Zm9ybSBtYWxmdW5jdGlvbiwgcmVhZCBDUFBDDQo+IGhpZ2hlc3Rf
cGVyZjogJXUsIGxvd2VzdF9wZXJmOiAldSwgbm9taW5hbF9wZXJmOiAldSwgbG93ZXN0X25vbmxp
bmVhcl9wZXJmOiAldQ0KPiB6ZXJvIHZhbHVlXG4iLA0KPiA+ICsgICAgICAgICAgICAgICAgICAg
ICAgIGRhdGEtPmh3LmhpZ2hlc3RfcGVyZiwgZGF0YS0+aHcubG93ZXN0X3BlcmYsDQo+ID4gKyAg
ICAgICAgICAgICAgICAgICAgICAgZGF0YS0+aHcubm9taW5hbF9wZXJmLCBkYXRhLT5ody5sb3dl
c3Rfbm9ubGluZWFyX3BlcmYpOw0KPiA+ICsgICAgICAgIGdvdG8gZXJyb3I7DQo+ID4gKyAgICB9
DQo+ID4gKw0KPiA+ICsgICAgbWluX2ZyZXEgPSBhbWRfZ2V0X21pbl9mcmVxKGRhdGEpOw0KPiA+
ICsgICAgbm9taW5hbF9mcmVxID0gYW1kX2dldF9ub21pbmFsX2ZyZXEoZGF0YSk7DQo+ID4gKyAg
ICBtYXhfZnJlcSA9IGFtZF9nZXRfbWF4X2ZyZXEoZGF0YSk7DQo+ID4gKyAgICBpZiAoIG1pbl9m
cmVxID4gbWF4X2ZyZXEgKQ0KPiA+ICsgICAgew0KPiA+ICsgICAgICAgIGFtZF9wc3RhdGVfZXJy
KHBvbGljeS0+Y3B1LCAibWluX2ZyZXEoJXUpIG9yIG1heF9mcmVxKCV1KSB2YWx1ZSBpcw0KPiBp
bmNvcnJlY3RcbiIsDQo+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgbWluX2ZyZXEsIG1heF9m
cmVxKTsNCj4gPiArICAgICAgICBnb3RvIGVycm9yOw0KPiA+ICsgICAgfQ0KPg0KPiAuLi4gY2hl
Y2tpbmcgdGhlbT8gRXJyb3IgaGFuZGxpbmcgd291bGQgYmUgZWFzaWVyIGlmIHlvdSBlbmFibGVk
IG9ubHkgYWZ0ZXJ3YXJkcy4NCj4NCj4gPiArICAgIGhpZ2hlc3RfcGVyZiA9IGRhdGEtPmh3Lmhp
Z2hlc3RfcGVyZjsNCj4gPiArICAgIG5vbWluYWxfcGVyZiA9IGRhdGEtPmh3Lm5vbWluYWxfcGVy
ZjsNCj4gPiArDQo+ID4gKyAgICBpZiAoIGhpZ2hlc3RfcGVyZiA8PSBub21pbmFsX3BlcmYgKQ0K
PiA+ICsgICAgICAgIHJldHVybjsNCj4gPiArDQo+ID4gKyAgICBwb2xpY3ktPnR1cmJvID0gQ1BV
RlJFUV9UVVJCT19FTkFCTEVEOyB9DQo+DQo+IEFuZCB3aHkgdGhlIGhlbHBlciB2YXJpYWJsZXMg
aW4gdGhlIGZpcnN0IHBsYWNlPw0KPg0KDQpTb3JyeSwgbWF5YmUgYSBiaXQgbW9yZSBzcGVjaWZp
YywgZ290IGNvbmZ1c2VkIGFib3V0IHRoZSBxdWVzdGlvbiA7Lw0KDQo+DQo+IEphbg0KDQpNYW55
IHRoYW5rcywNClBlbm55DQo=


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 06:19:45 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 06:19:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875111.1285428 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ta7c0-00086d-81; Tue, 21 Jan 2025 06:19:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875111.1285428; Tue, 21 Jan 2025 06:19:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ta7c0-00086W-4Y; Tue, 21 Jan 2025 06:19:44 +0000
Received: by outflank-mailman (input) for mailman id 875111;
 Tue, 21 Jan 2025 06:19:42 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=WcK4=UN=amd.com=Jiqian.Chen@srs-se1.protection.inumbo.net>)
 id 1ta7by-00086L-En
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 06:19:42 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20630.outbound.protection.outlook.com
 [2a01:111:f403:2009::630])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b1b7911b-d7bf-11ef-99a4-01e77a169b0f;
 Tue, 21 Jan 2025 07:19:40 +0100 (CET)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by IA0PR12MB7627.namprd12.prod.outlook.com (2603:10b6:208:437::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8356.22; Tue, 21 Jan
 2025 06:19:37 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285%4]) with mapi id 15.20.8356.020; Tue, 21 Jan 2025
 06:19:37 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b1b7911b-d7bf-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=jOwue6UZbWc2qwe129o8ULdwZ7t7oIMGn2SDiVgthGzbRTaBkHefeGZ2OQx7fLn2vjZqB4qt+U+a4osT5AcBO39pkVcejiVhmHogd0t8WHmh2kMlxASn2A26qK5ezVIDmyy+stzq+VcrKuy4+9BoKJvtZ5xeyqym1Bxl/C4A7dYC/yDVgDCxhnJWgUQn+LaXW0dlj+lHDWMyoy8ka+p+wT7PKi3Gs26hI3ZN+on6BSvlSoEiFw/Z0I3LjpPNiqNPB+SBjmoVikwgsdSD/xF32RdjmlOExnAXBRHRarYGywlNpk0cJs9e1m3iqSBi44EB+o+GUyqVB2+TrWg5rBhw3A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=mZB/lM3mqHRulFmPNjWYrE4z9pniZHNsTosKeURX3eo=;
 b=l0ckpZaSVwfVx8nPWtGyqFrkVQzbLKf3OP36gqLmBaKr/JF5LqMLv7QIqvZenDL9Or599IUB68c2YC7RGmUviQu99+TT0DztR6NPCf/ZwnleUDedHNWR/uPf2rl2lipWuLzU/r+D5+1kxIcwrJkfz2bOUzeI19BAs2p4l83jpk/DTbv36pwxSe/MLoxGVZO8fp8st371m+hpc7HMuG+kcksypLrgGyfYj5IeD0WJvsuiVV1ecNH4KSg3+vSoyI46k+FSEu63erEUqif+yKggOjjRn9cM9IQmks/luUmb7A+9rOyf6Esx1B9mxpC044upAKrr/T+vO9wjYNuZQCr+yQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=mZB/lM3mqHRulFmPNjWYrE4z9pniZHNsTosKeURX3eo=;
 b=aDX16ecnGVB28iumcMTD7UJCNeps7RIA3Ug4hBxAHsrakD4e10WrdQup2sJPEK9kigT4Oxij7dEbTnQ0ydNp5sGFzBNm6fUEhgTi1tm+kv+8KzPuj8T+W6SmxFwaLBacoBUaJLzysxxqEdsQMV2UnyO9XB0WKfZ9r5Wia3G0lKM=
From: "Chen, Jiqian" <Jiqian.Chen@amd.com>
To: Jan Beulich <jbeulich@suse.com>
CC: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>, Andrew Cooper
	<andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, Stefano
 Stabellini <sstabellini@kernel.org>, "Huang, Ray" <Ray.Huang@amd.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, "Chen,
 Jiqian" <Jiqian.Chen@amd.com>
Subject: Re: [PATCH v5] vpci: Add resizable bar support
Thread-Topic: [PATCH v5] vpci: Add resizable bar support
Thread-Index: AQHbZjRJ+4D0uojYEUmC9gRuRAux1rMf1XqAgAF7xoA=
Date: Tue, 21 Jan 2025 06:19:37 +0000
Message-ID:
 <BL1PR12MB58493331595F4C3AB561DA2AE7E62@BL1PR12MB5849.namprd12.prod.outlook.com>
References: <20250114032636.3698383-1-Jiqian.Chen@amd.com>
 <3e535294-8e68-476f-9958-d8c870f85f7c@suse.com>
In-Reply-To: <3e535294-8e68-476f-9958-d8c870f85f7c@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com
 (15.20.8356.017)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|IA0PR12MB7627:EE_
x-ms-office365-filtering-correlation-id: 64bbc25f-849d-4ee6-fc17-08dd39e394a9
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?Wnd3Wk5ocm9yWkJZT2kydC9yWWNFTWJhNi9wd2QzVDB4ck9yODZxQlNyMzl1?=
 =?utf-8?B?b24wMXVDN2NNK1JMeDdFNzV0eUxtYnNVeE1tVmd1WWFYaXJpV0M4RytBL1J3?=
 =?utf-8?B?ckpJVENnREtML2grOHU2UmdGZ2c2aDA2bUU4RlhsTWVmd3hQSUI0Wm5uUUV2?=
 =?utf-8?B?Si8vT3FJenhGZ0c1UWJGZVJaY0t2aXdUWUNwaGhEL1Q1TVBBd2IxVzVFdE9J?=
 =?utf-8?B?VjYxTDBmWEFGbzNZUTV0enlucWZYZS90a2VKaGVrNXVzSzV2V2crazZTV1Rn?=
 =?utf-8?B?SjhCWHV0dkVueTBFVWkvQXhFVlhMeXc5WXNpcTVqUjFGYUo4YVU4Y3VUc1NG?=
 =?utf-8?B?WTZubUE1Wk5rdGpIL2MrZm1yMVhSQmZ5Mll6SjNHR05ha1BvUHpsM0dIQXZX?=
 =?utf-8?B?VGxzQ2ZPa2h2MFk5NlRTK0x1Z3ZYWUc1T2NaQmFQNGJTeU1jN0d0VkdiUC9u?=
 =?utf-8?B?L1g3dkloQVljQ3c4clIzVHlzL0FUdnpiUmpZSk8rQXdqOWptUDV0cit1UkZL?=
 =?utf-8?B?SHptdWJMKzZWOUlCL2xuMkplSkxIakR3Q2pDbCtPRVdmVjlmL2dtQlZNYmJE?=
 =?utf-8?B?MEZDNEhLUTNxWWIzbGcvcmp0ajFlWDVUWmF0cXhwQlVTRm81S3J6ZmpBNkEr?=
 =?utf-8?B?NjZ6akZTYm03d0txOXZRQVdiT2luUTJVOWdMbHlaeE9IM245OVN1RVNMUzRK?=
 =?utf-8?B?TklZeUpQZ3llVHBEVWVtMjJxbTB1aG9jK0FQN0RrRVB2N2FHV2hCaXkyVDNH?=
 =?utf-8?B?d0hBenhJSnN2QlN3bFU0Yk5pRjI3K3Q2UC8rQVI1Y0xvc3pia2MzcXErcHFC?=
 =?utf-8?B?bmc0S29Vc1R3Y1J1dFRZYmJlOEc4SVVTZlFGUm03OHlKMTlWSmw2bCtadUIz?=
 =?utf-8?B?K2RWYWFDY1RYV3hkLzR3aUd5dGRWRlMvTkFFaDBUOVJ0RTBlQU9ZRURRTVp5?=
 =?utf-8?B?RG9xZHRGR3J3bUhlOEhhUzZ6am5iY05MdVVSU2dBOVc4YURiNG5RUCt0N0s3?=
 =?utf-8?B?RDlVL1cxU3JzcGNFL0RHRW5LL3p3a0VYVEVRMUhCemdKcFdnd1NxMnM2SEdv?=
 =?utf-8?B?aEZoNm5GNHJVcmNRVkQ1M0x6aFFzTFErTkdIWkVKYVVVMGVEeDM3Q1hhbzVC?=
 =?utf-8?B?L0RIRVY0d28xK3FtUXVqZ29rOXJlWGRhTlNkamgwOCtFSTBsaTk5aGRROU5i?=
 =?utf-8?B?ZlNzK0Z6aEtlMEVzS0puMlpIbTNuQzdYalR0QTlqbjNhTjdWKzF1MkY2QUhQ?=
 =?utf-8?B?OHJxNm5Ba0hHelVaanVUVkwxRG52MlhjeGZBL09TQW5FcmNSM3Joc0ZvdG5H?=
 =?utf-8?B?VmMxdmQyd0ZFejYxdVFnOHh3UFEvQWZnS28vb2c3ZlgyTjlxbzhLMWkrVUhR?=
 =?utf-8?B?RHhFMEx0TExPSG1GNGhveXA5d2R0dEpuOU1ERUtpVmNwWUV4VGlmOUFBSmdS?=
 =?utf-8?B?NWdGQUJkeFZ4enNtbDdzeGVseUJIU3V2MHY3d1FmYjIySEpIdU9SU2EvdjNP?=
 =?utf-8?B?OU9mZU5OVURXZTdtZGxDKzlxRllVdXdET2h3SS9aelhqUG1wRDlBL2lKNEZl?=
 =?utf-8?B?YmJiN0twMXIzNkNiMWh3d2w1M2h6QnlZaHBDUmhRRGYzMjg3Z0FlUytXT2Uv?=
 =?utf-8?B?YjVkMGJueCt1SGQ5VVcxSUNuakVseEgrV0NqRWNBVDAyMTg2cEZFb1FLYlZQ?=
 =?utf-8?B?ZFJDU1dTSjljbFJDcy9iVGZyNmFFeEcvRzNDRXJ3TVcyQjBDanltREFVeksr?=
 =?utf-8?B?V3pZMytPMFROb2FnNVQ1L0p5a1VUNjM2V1M2N0lZalBmcUJ2dUtiakRCL1B1?=
 =?utf-8?B?UUw0TGpGNkVhaUdpOGhFYkF5Rk9BYzQ2SEZlUjRkeEJyeFBmditRcGJCdDdt?=
 =?utf-8?B?WWo3NTQ1eVdsSEFoOHp1K1d4VGhjWWsrTThWc1RKRWUzaG9kb3dyQ0VFdDlk?=
 =?utf-8?Q?WvHmS2DcBuZxGyE1ynL2L/dmrjTOObHo?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?QlJrSGM3NUxVZy82L000NE00T1pudisyL1puY3FteTdjTExnTkdDSlMxK3RM?=
 =?utf-8?B?SGlYVDhkdXc0TTFPMG9LZjRwS3h1SmUwNEI2VFJrdnN5VDNEWTZpSUM4Wmdo?=
 =?utf-8?B?dW0rTE45TkFtRDB3bXZYTVE0eU95ckdsc2pWcGYvU0VBTE93aEVkWXpRcFMw?=
 =?utf-8?B?OUxYejd1eDkzOTJaSTZydFMxT0RKTHA3V0ZlT0tWM1FCakIxUjVvL2poMTky?=
 =?utf-8?B?K29pUFo1YXN2MU5SL0FFN0RzTHk0MWRvSzB6c054aWxnV1JWSE1NWXJqRWZw?=
 =?utf-8?B?cUpxMDVic2xSTUQwM0piU1h0anQyeDhWUUxtOVpsTUZZU3RCY1JrRjI2RTZU?=
 =?utf-8?B?SytGZE8rMkV5R203c1lUSnJOWTFTTWZESXMvWENabVFMTGNqdmxGUlc2NlM1?=
 =?utf-8?B?bjMrUFM3Q1lWMlJ5cU9jYVdXdGxVTTU2alVPaEdhdFZncEZFSDhEZlJMN3g5?=
 =?utf-8?B?Ump4OUh1ODRDVEtBRThBUWpTSHdYSmZhWnhTZENEVGFmbjZXbTVkMkloaG4z?=
 =?utf-8?B?QnZsT0lKcUQvN2VwT1JrRGFBSGs5U1lwT1RuYmJENTJHbUpwNFNCajRhT1Qz?=
 =?utf-8?B?OG9US01OYTY0ZXlCZU90MGlNY3RWb01KQklwWWhyUGMyTG1yek9CRnVnZFM0?=
 =?utf-8?B?VlZGVmQ5MkZEc3l5bHdqK2J4VjlSUGRSbnVSWjdwZGQxZ2FIc2tNU0N4dUQv?=
 =?utf-8?B?SVdrMHFVREh2L2lXR2pibWV1RE9aSlN0azZyTElPUVRzWU95YVdTNGt6UHZ1?=
 =?utf-8?B?aElMK3lwUFVINzV4M3BVc2RFV29oVitsRDFldTlJWCtGN3YrVnYzbFNqZDBm?=
 =?utf-8?B?dW9YQkRDeVdSQjE2aE9aVnhqVVFmYUZTY2FBQzU3S0dlVVFjdzg2NUp6SXps?=
 =?utf-8?B?MGExeUxYcUwyOUFicDlCQjJieXJ3Qk0vaVRrdzYvL0NUVSticlNlaTIzV3By?=
 =?utf-8?B?ZEF4a0dWd3djaTROb2pTYVEvQnJQcm13bGhJN2RhTXl6Y2J5WWFrRzNOMWky?=
 =?utf-8?B?Z0xnTjdTcDhuME04Y0llYjJpTDgyMTV2NGZoQVlUNXB2bVNVOWJoOWhpNnpH?=
 =?utf-8?B?R0t6NlZQN3NiTmhkV2ZSTXdqSW5JZTZuNVZla0RXWGdBL0o1dUhIQ3dhLzVW?=
 =?utf-8?B?NUFMMkF2aVlHUGdSazlYRnM0QnZINDJRZkoyeFBzOW9JaDlXbkJwaW9ZRi9w?=
 =?utf-8?B?alZhaWdjT3R4UXp4MzhONlVUbHBRaDE0cGJOdnhDUGVkbHIrZTRKZ25rSGpQ?=
 =?utf-8?B?RGlTVkN0WjlrUlF6elZvUUtVQm1pdE9Ra3pLZG1mbHU5Qk9XZ0JWOGcwSHJj?=
 =?utf-8?B?RmFwcHFhNTgxVXFLS1pwWEpPV1JKZWVTSWNDVWpJMHJuc3NUOHNtYjcrVG0x?=
 =?utf-8?B?bTJWbUZNa3VldVl5eFpsbDBRVVVCcEhzTHNiRXNYZ2poQWlTejN0WU1TZWlF?=
 =?utf-8?B?b1J1TlRROUZjU29TZmx1T0tJZTUweVk4TERoQ3M2MVlZZ0dZL0lQQjJDd3dF?=
 =?utf-8?B?WVBHb3h4WmJYL2krQitUS1BseFNmalBXbHdWZlNTOTFHT3BlL3dNU2hJOUp5?=
 =?utf-8?B?RzQyN0ttWjdEYkpxcGcvczVhVVhLZzBmV3d4UGxJMExoNzZ2TkxwQjc1bjc0?=
 =?utf-8?B?N1o3QW10dXg1LzBWTHpJcHF1clQ2dlBCOG9VdmExT1o2RXJYV0lDV1N0ZEdB?=
 =?utf-8?B?UXJlbDlKVVVYdU4vVXhjTDVCdWtEQzRpakRDUDM2SVpDKzRBcDlmZDNKbEFU?=
 =?utf-8?B?ekJUK3FXMGMvVUhoYWQyS2Y2S1FkSkJnbzF4ZmRHSkQvcWg4cWxxUGJ1WHZs?=
 =?utf-8?B?ZDZ3YkF2QTJ1Q3JTUUV6MDJ1MFFENE9LWVdPUjdaSmw1VkVHZC9oL1NGMSta?=
 =?utf-8?B?blJVNkN4QnFTQ3RVSjg3OENseUdSZU5LcTZvRitBUXFTczVmVGd4NHpCWU9X?=
 =?utf-8?B?Tk5YOFp1Z2NrY3ViUHRnamN5bVN4b3d0Zi8xSVQyUWRtdndxUk9LYXIxOTQw?=
 =?utf-8?B?K21XMmhHc2pvczJWNFpJd2JQMTFGTnEzN1NRbW40NmJDbDlqbHNyOW1zV2tv?=
 =?utf-8?B?SG0rUi92a0Z5SWdjOWZjZmpWUFBNWWR5NnZvVnJNbzJLQXd0MXlpc2JIcks4?=
 =?utf-8?Q?xZK8=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <E44D3E0E66E35942B212DFB3902675D5@amdcloud.onmicrosoft.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 64bbc25f-849d-4ee6-fc17-08dd39e394a9
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2025 06:19:37.0609
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: QCknQ1ni2wKBQHr2AHJ+G0/lnUOoNgygANExr+spsfxvmXfShBkCkfJ03mLwUgLuqYjH+lB2lhhFGJWypDHNTg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB7627

T24gMjAyNS8xLzIwIDIzOjM1LCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMTQuMDEuMjAyNSAw
NDoyNiwgSmlxaWFuIENoZW4gd3JvdGU6DQo+PiAtLS0gL2Rldi9udWxsDQo+PiArKysgYi94ZW4v
ZHJpdmVycy92cGNpL3JlYmFyLmMNCj4+IEBAIC0wLDAgKzEsMTM1IEBADQo+PiArLyogU1BEWC1M
aWNlbnNlLUlkZW50aWZpZXI6IEdQTC0yLjAtb25seSAqLw0KPj4gKy8qDQo+PiArICogQ29weXJp
Z2h0IChDKSAyMDI0IEFkdmFuY2VkIE1pY3JvIERldmljZXMsIEluYy4gQWxsIFJpZ2h0cyBSZXNl
cnZlZC4NCj4gDQo+IE5pdDogVGhpcyBoYXMgbm93IGdvbmUgc3RhbGUuDQpUaGFua3MsIHdpbGwg
Y2hhbmdlIDIwMjQgdG8gMjAyNS4NCg0KPiANCj4+ICsgKiBBdXRob3I6IEppcWlhbiBDaGVuIDxK
aXFpYW4uQ2hlbkBhbWQuY29tPg0KPj4gKyAqLw0KPj4gKw0KPj4gKyNpbmNsdWRlIDx4ZW4vc2No
ZWQuaD4NCj4+ICsjaW5jbHVkZSA8eGVuL3ZwY2kuaD4NCj4+ICsNCj4+ICtzdGF0aWMgdm9pZCBj
Zl9jaGVjayByZWJhcl9jdHJsX3dyaXRlKGNvbnN0IHN0cnVjdCBwY2lfZGV2ICpwZGV2LA0KPj4g
KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgaW50IHJlZywN
Cj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IHZhbCwN
Cj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHZvaWQgKmRhdGEpDQo+
PiArew0KPj4gKyAgICB1bnNpZ25lZCBpbnQgaW5kZXg7DQo+PiArICAgIHN0cnVjdCB2cGNpX2Jh
ciAqYmFyID0gZGF0YTsNCj4+ICsgICAgdWludDY0X3Qgc2l6ZSA9IFBDSV9SRUJBUl9DVFJMX1NJ
WkUodmFsKTsNCj4+ICsNCj4+ICsgICAgaWYgKCBiYXItPmVuYWJsZWQgKQ0KPj4gKyAgICB7DQo+
PiArICAgICAgICAvKg0KPj4gKyAgICAgICAgICogUmVmdXNlIHRvIHJlc2l6ZSBhIEJBUiB3aGls
ZSBtZW1vcnkgZGVjb2RpbmcgaXMgZW5hYmxlZCwgYXMNCj4+ICsgICAgICAgICAqIG90aGVyd2lz
ZSB0aGUgc2l6ZSBvZiB0aGUgbWFwcGVkIHJlZ2lvbiBpbiB0aGUgcDJtIHdvdWxkIGJlY29tZQ0K
Pj4gKyAgICAgICAgICogc3RhbGUgd2l0aCB0aGUgbmV3bHkgc2V0IEJBUiBzaXplLCBhbmQgdGhl
IHBvc2l0aW9uIG9mIHRoZSBCQVINCj4+ICsgICAgICAgICAqIHdvdWxkIGJlIHJlc2V0IHRvIHVu
ZGVmaW5lZC4gIE5vdGUgdGhlIFBDSWUgc3BlY2lmaWNhdGlvbiBhbHNvDQo+PiArICAgICAgICAg
KiBmb3JiaWRzIHJlc2l6aW5nIGEgQkFSIHdpdGggbWVtb3J5IGRlY29kaW5nIGVuYWJsZWQuDQo+
PiArICAgICAgICAgKi8NCj4+ICsgICAgICAgIGlmICggc2l6ZSAhPSBiYXItPnNpemUgKQ0KPj4g
KyAgICAgICAgICAgIGdwcmludGsoWEVOTE9HX0VSUiwNCj4+ICsgICAgICAgICAgICAgICAgICAg
ICIlcHA6IHJlZnVzZSB0byByZXNpemUgQkFSIHdpdGggbWVtb3J5IGRlY29kaW5nIGVuYWJsZWRc
biIsDQo+PiArICAgICAgICAgICAgICAgICAgICAmcGRldi0+c2JkZik7DQo+PiArICAgICAgICBy
ZXR1cm47DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgaWYgKCAhKChzaXplID4+IFBDSV9SRUJB
Ul9DVFJMX1NJWkVfQklBUykgJiBiYXItPnJlc2l6YWJsZV9zaXplcykgKQ0KPj4gKyAgICAgICAg
Z3ByaW50ayhYRU5MT0dfV0FSTklORywNCj4+ICsgICAgICAgICAgICAgICAgIiVwcDogbmV3IHNp
emUgJSNseCBpcyBub3Qgc3VwcG9ydGVkIGJ5IGhhcmR3YXJlXG4iLA0KPj4gKyAgICAgICAgICAg
ICAgICAmcGRldi0+c2JkZiwgc2l6ZSk7DQo+PiArDQo+PiArICAgIHBjaV9jb25mX3dyaXRlMzIo
cGRldi0+c2JkZiwgcmVnLCB2YWwpOw0KPj4gKw0KPj4gKyAgICBpbmRleCA9IHBjaV9jb25mX3Jl
YWQzMihwZGV2LT5zYmRmLCByZWcpICYgUENJX1JFQkFSX0NUUkxfQkFSX0lEWDsNCj4+ICsgICAg
cGNpX3NpemVfbWVtX2JhcihwZGV2LT5zYmRmLCBQQ0lfQkFTRV9BRERSRVNTXzAgKyBpbmRleCAq
IDQsICZiYXItPmFkZHIsDQo+PiArICAgICAgICAgICAgICAgICAgICAgJmJhci0+c2l6ZSwgKChp
bmRleCA9PSBQQ0lfSEVBREVSX05PUk1BTF9OUl9CQVJTIC0gMSkgPw0KPj4gKyAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBQQ0lfQkFSX0xBU1QgOiAwKSk7DQo+IA0KPiBOaXQ6IElt
byBpdCdzIHVuaGVscGZ1bCB0byB0aGUgcmVhZGVyIGlmIHlvdSBwdXQgbXVsdGlwbGUgYXJndW1l
bnRzIG9uIGEgc2luZ2xlDQo+IGxpbmUsIHdoZW4gdGhlIGZpbmFsIG9uZSB0aGVuIG5lZWRzIHdy
YXBwaW5nIGFjcm9zcyBsaW5lcy4gKFB1dHRpbmcgbXVsdGlwbGUNCj4gYXJndW1lbnRzIG9uIGEg
c2luZ2xlIGxpbmUgaXMgZmluZSBvZiBjb3Vyc2Ugd2hlbiB0aGV5IGZ1bGx5IGZpdC4pDQpXaWxs
IGNoYW5nZSB0byBwdXQgZWFjaCBhcmd1bWVudCBpbiBhIHNpbmdsZSBsaW5lIGluIG5leHQgdmVy
c2lvbi4NCg0KPiANCj4+IC0tLSBhL3hlbi9pbmNsdWRlL3hlbi9wY2lfcmVncy5oDQo+PiArKysg
Yi94ZW4vaW5jbHVkZS94ZW4vcGNpX3JlZ3MuaA0KPj4gQEAgLTQ1OSw2ICs0NTksNyBAQA0KPj4g
ICNkZWZpbmUgUENJX0VYVF9DQVBfSURfQVJJCTE0DQo+PiAgI2RlZmluZSBQQ0lfRVhUX0NBUF9J
RF9BVFMJMTUNCj4+ICAjZGVmaW5lIFBDSV9FWFRfQ0FQX0lEX1NSSU9WCTE2DQo+PiArI2RlZmlu
ZSBQQ0lfRVhUX0NBUF9JRF9SRUJBUgkyMQkvKiBSZXNpemFibGUgQkFSICovDQo+PiAgDQo+PiAg
LyogQWR2YW5jZWQgRXJyb3IgUmVwb3J0aW5nICovDQo+PiAgI2RlZmluZSBQQ0lfRVJSX1VOQ09S
X1NUQVRVUwk0CS8qIFVuY29ycmVjdGFibGUgRXJyb3IgU3RhdHVzICovDQo+PiBAQCAtNTQxLDYg
KzU0MiwxOSBAQA0KPj4gICNkZWZpbmUgIFBDSV9WTkRSX0hFQURFUl9SRVYoeCkJKCgoeCkgPj4g
MTYpICYgMHhmKQ0KPj4gICNkZWZpbmUgIFBDSV9WTkRSX0hFQURFUl9MRU4oeCkJKCgoeCkgPj4g
MjApICYgMHhmZmYpDQo+PiAgDQo+PiArLyogUmVzaXphYmxlIEJBUnMgKi8NCj4+ICsjZGVmaW5l
IFBDSV9SRUJBUl9DQVAobikJKDQgKyA4ICogKG4pKQkvKiBjYXBhYmlsaXR5IHJlZ2lzdGVyICov
DQo+PiArI2RlZmluZSAgUENJX1JFQkFSX0NBUF9TSVpFU19NQVNLCTB4RkZGRkZGRjBVCS8qIHN1
cHBvcnRlZCBCQVIgc2l6ZXMgaW4gQ0FQICovDQo+PiArI2RlZmluZSBQQ0lfUkVCQVJfQ1RSTChu
KQkoOCArIDggKiAobikpCS8qIGNvbnRyb2wgcmVnaXN0ZXIgKi8NCj4+ICsjZGVmaW5lICBQQ0lf
UkVCQVJfQ1RSTF9CQVJfSURYCQkweDAwMDAwMDA3CS8qIEJBUiBpbmRleCAqLw0KPj4gKyNkZWZp
bmUgIFBDSV9SRUJBUl9DVFJMX05CQVJfTUFTSwkweDAwMDAwMEUwCS8qICMgb2YgcmVzaXphYmxl
IEJBUnMgKi8NCj4+ICsjZGVmaW5lICBQQ0lfUkVCQVJfQ1RSTF9CQVJfU0laRQkweDAwMDAzRjAw
CS8qIEJBUiBzaXplICovDQo+PiArI2RlZmluZSAgUENJX1JFQkFSX0NUUkxfU0laRVNfTUFTSwkw
eEZGRkYwMDAwVQkvKiBzdXBwb3J0ZWQgQkFSIHNpemVzIGluIENUUkwgKi8NCj4+ICsjZGVmaW5l
ICBQQ0lfUkVCQVJfQ1RSTF9TSVpFX0JJQVMJMjANCj4+ICsjZGVmaW5lICBQQ0lfUkVCQVJfQ1RS
TF9TSVpFKHYpIFwNCj4+ICsgICAgICAgICAgICAoMVVMIDw8IChNQVNLX0VYVFIodiwgUENJX1JF
QkFSX0NUUkxfQkFSX1NJWkUpIFwNCj4+ICsgICAgICAgICAgICAgICAgICAgICArIFBDSV9SRUJB
Ul9DVFJMX1NJWkVfQklBUykpDQo+IA0KPiBPbiB4ODYgKGJlaW5nIDY0LWJpdCBvbmx5KSBhbmQg
QXJtNjQgMVVMIG1heSBiZSBnb29kIGVub3VnaCBoZXJlLCBidXQNCj4gSSBleHBlY3Qgd2UnbGwg
bmVlZCAxVUxMIGZvciBhbnkgMzItYml0IGFyY2hpdGVjdHVyZS4NCj4gDQo+IFBsdXMsIGFzIGlu
ZGljYXRlZCBiZWZvcmUsIHRoZXNlIHR3byBhdXhpbGlhcnkgI2RlZmluZS1zIHdvdWxkIGltbw0K
PiBiZXR0ZXIgYmUgc2VwYXJhdGVkIGZyb20gdGhvc2UgZGlyZWN0bHkgcGVydGFpbmluZyB0byB0
aGUgY29udHJvbA0KPiByZWdpc3RlciBmaWVsZHMgKGFuZCB0aGVuIGFsc28gbm90IGJlIHBhZGRl
ZCBsaWtlIHRob3NlKS4NClRoYW5rIHlvdSENCldpbGwgdXNlIGEgc3BhY2UgbGluZSB0byBzZXBh
cmF0ZSB0aGVzZSB0d28gI2RlZmluZS1zIGZyb20gdGhlIG90aGVycyBhbmQgY2hhbmdlIDFVTCB0
byAxVUxMLg0KDQo+IA0KPiBKYW4NCg0KLS0gDQpCZXN0IHJlZ2FyZHMsDQpKaXFpYW4gQ2hlbi4N
Cg==


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 08:03:00 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 08:03:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875126.1285438 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ta9Dj-0004gf-KQ; Tue, 21 Jan 2025 08:02:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875126.1285438; Tue, 21 Jan 2025 08:02:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ta9Dj-0004gY-Gm; Tue, 21 Jan 2025 08:02:47 +0000
Received: by outflank-mailman (input) for mailman id 875126;
 Tue, 21 Jan 2025 08:02:46 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Gode=UN=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1ta9Di-0004gS-P4
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 08:02:46 +0000
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com
 [2a00:1450:4864:20::431])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 16e4f730-d7ce-11ef-99a4-01e77a169b0f;
 Tue, 21 Jan 2025 09:02:42 +0100 (CET)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-38a8b35e168so3637962f8f.1
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 00:02:42 -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
 ffacd0b85a97d-38bf32150a6sm12859490f8f.15.2025.01.21.00.02.40
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 21 Jan 2025 00:02:40 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 16e4f730-d7ce-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737446561; x=1738051361; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=e7tTecqTERmlCdRRxd5/kg8ci5254d689LI+sgsVamE=;
        b=dguzg5xVbW03wQg6jI+n5qonXD/SVkdT2DPwHIzmxBvxnZV4EMne/ELfGb6Y+b8d3F
         OiHXyoWyVZVmZC5ma/5aYb6Px3cGQa0KLWHKn/9D/MAvtvJJua91t6HBfy8G/HOpW9r/
         +PmssXNsQc6VRu/K6tisKBD5d/38RA4BxtD7CzutqM1T3l9SwNJkxdx4FLmPs48/JILT
         DKRYZsvO7NtXBwzqRxyUJLes7urwh4NddTPFBp5I6hIl976HMKI4UA15NgwjtW74+cj7
         73XcuReK1LV68sl75KWKsG9aZrOFqwn91mrjewLQNrivx5BIeOGE0gy9yLMTBYzpolyA
         BzQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737446561; x=1738051361;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=e7tTecqTERmlCdRRxd5/kg8ci5254d689LI+sgsVamE=;
        b=bZgUcbYlm4i0US6u3A45Me0FJWgciPUdQYw5OrvMhcbz0sDOduZT0v6PpGFaFkZV3m
         rBFviLcpGhXSH/8jE3bro4ywdG+KJqdarvAPzdhg6i7hev8fUpjAkurHNa8qE592lpiV
         TVbzjUd8B29SQYl/1VuA50z5sXMNWkR/vTBgWwZuv4tf433ztuALv5mEfsqE4d00TfcJ
         W4g9ZJuwHPuobpN6Op8OLmyxiy4enza8XcZLxkzMWVBAHCHrRuz9XF8xZcnsY6cTfKmC
         cb0uRlpIJXJJGSbQlVJuuDoWnjOeUIkdgwde7YD3ImJBxTbLAe65cKqD2Fqjyl/3lklN
         ph7g==
X-Forwarded-Encrypted: i=1; AJvYcCX5SNhwmBgq/BUshfQjf61M35a0dLfS3e1QL4gs3OKp4BaBVkLLt/6SGUAjx/+EVoVui6nxVfX1S0Y=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwyRMOsW7jj9r9zEqQi6Ua7LKU3VQW5k/BQd7EKy0W3bnXvLmYd
	iN2raiEubfoVl1wdFUllab0BCKSlqJhz3341rTBSXfRZWUpp7vNqwsHES7tDWQ==
X-Gm-Gg: ASbGncs22e0YmA9FSJG9ngVJbCZuNeFpPuQrOXYfENysY42uznLk8Y+GP0wHfbNxk1T
	oMD03g5rqX4y57tLHs9lTVVD1ytBOQAzAH4QQ00Askslw/WgBFrDcWAFqbm09mlPhVtVMYnSsXf
	WNMg91EZoGKYJC9jj3euqXcJopuL21uMWfXEdmBkxRLRgbbbhNH40lxcZSSi+NN5ZWz0sbITwwz
	PUciLyFi8hwCWwsggi2qqpDje00kafZg87/Ic6z2diljTXudiCNwcp4j2bh1s6vUx905NfWT4ZG
	b2vh9Jbo8JolrcXeoLBhzg4UW4/17cLuXepKVXANzQN4opwbP8D94q8=
X-Google-Smtp-Source: AGHT+IFKZKIiAvE7n+YZA4eE5PfAmfv/aNEklyEPYvHu1tbkcTSCsrd+376RQYWrEajlZkbfRzLEuw==
X-Received: by 2002:a5d:64e6:0:b0:381:ed32:d604 with SMTP id ffacd0b85a97d-38bf5ad3a71mr12905929f8f.10.1737446561429;
        Tue, 21 Jan 2025 00:02:41 -0800 (PST)
Message-ID: <98115dfa-0d86-4651-869d-578069ac413c@suse.com>
Date: Tue, 21 Jan 2025 09:02:40 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 05/11] xen/x86: introduce a new amd pstate driver for
 cpufreq scaling
To: "Penny, Zheng" <penny.zheng@amd.com>
Cc: "Stabellini, Stefano" <stefano.stabellini@amd.com>,
 "Huang, Ray" <Ray.Huang@amd.com>,
 "Ragiadakou, Xenia" <Xenia.Ragiadakou@amd.com>,
 "Andryuk, Jason" <Jason.Andryuk@amd.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <20241203081111.463400-1-Penny.Zheng@amd.com>
 <20241203081111.463400-6-Penny.Zheng@amd.com>
 <f7f03617-e438-48c1-b5b0-1ca975cbc7e6@suse.com>
 <DM4PR12MB8451942DEC644085A16F2391E1E62@DM4PR12MB8451.namprd12.prod.outlook.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <DM4PR12MB8451942DEC644085A16F2391E1E62@DM4PR12MB8451.namprd12.prod.outlook.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 21.01.2025 07:14, Penny, Zheng wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Thursday, January 9, 2025 6:55 PM
>>
>> On 03.12.2024 09:11, Penny Zheng wrote:
>>> +    {
>>> +        /* Read Processor Max Speed(mhz) from DMI table as anchor point */
>>> +        mul = dmi_max_speed_mhz;
>>> +        div = data->hw.highest_perf;
>>> +
>>> +        return (unsigned int)(mul / div) * data->hw.lowest_perf *
>>> + 1000;
>>
>> No risk of the cast chopping off set bits?
> 
> Mul shall be uint64_t, highest_perf and lowest_perf shall be uint8_t, and normally
> the equation output shall not be a too big value...
> If you think it's safer to do cast after comparing with the UINT32_MAX, I will add the check

Well, I can only say as much: Dividing a uint64_t by a uint8_t has ample
opportunity for there being more than 32 significant bits in the result.

>>> +    if ( !(val & AMD_CPPC_ENABLE) )
>>> +    {
>>> +        val |= AMD_CPPC_ENABLE;
>>> +        if ( wrmsr_safe(MSR_AMD_CPPC_ENABLE, val) )
>>> +        {
>>> +            amd_pstate_err(policy->cpu,
>> "wrmsr_safe(MSR_AMD_CPPC_ENABLE, %lx)\n", val);
>>> +            data->err = -EINVAL;
>>> +            return;
>>> +        }
>>> +    }
>>
>> Do you really need to enable befor reading ...
>>
>>> +    if ( rdmsr_safe(MSR_AMD_CPPC_CAP1, data->amd_caps) )
>>
>> ... capabilities and ...
>>
> 
> Yes.
> Only when CPPC is enabled, the hardware will calculate the processor’s performance capabilities and
> initialize the performance level fields in the CPPC capability registers.
> See 17.6.3 https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/24593.pdf

Ah yes, I see. Yet then the text there also says that the ENABLE bit can't
be cleared (except by reset), so your error handling is questionable.

>>> +    {
>>> +        amd_pstate_err(policy->cpu, "rdmsr_safe(MSR_AMD_CPPC_CAP1)\n");
>>> +        goto error;
>>> +    }
>>> +
>>> +    if ( data->hw.highest_perf == 0 || data->hw.lowest_perf == 0 ||
>>> +         data->hw.nominal_perf == 0 || data->hw.lowest_nonlinear_perf == 0 )
>>> +    {
>>> +        amd_pstate_err(policy->cpu, "Platform malfunction, read CPPC
>> highest_perf: %u, lowest_perf: %u, nominal_perf: %u, lowest_nonlinear_perf: %u
>> zero value\n",
>>> +                       data->hw.highest_perf, data->hw.lowest_perf,
>>> +                       data->hw.nominal_perf, data->hw.lowest_nonlinear_perf);
>>> +        goto error;
>>> +    }
>>> +
>>> +    min_freq = amd_get_min_freq(data);
>>> +    nominal_freq = amd_get_nominal_freq(data);
>>> +    max_freq = amd_get_max_freq(data);
>>> +    if ( min_freq > max_freq )
>>> +    {
>>> +        amd_pstate_err(policy->cpu, "min_freq(%u) or max_freq(%u) value is
>> incorrect\n",
>>> +                       min_freq, max_freq);
>>> +        goto error;
>>> +    }
>>
>> ... checking them? Error handling would be easier if you enabled only afterwards.
>>
>>> +    highest_perf = data->hw.highest_perf;
>>> +    nominal_perf = data->hw.nominal_perf;
>>> +
>>> +    if ( highest_perf <= nominal_perf )
>>> +        return;
>>> +
>>> +    policy->turbo = CPUFREQ_TURBO_ENABLED; }
>>
>> And why the helper variables in the first place?
> 
> Sorry, maybe a bit more specific, got confused about the question ;/

With local variables like these, you end up with more code volume for
no real gain. IOW what's wrong with

    if ( data->hw.highest_perf <= data->hw.nominal_perf )
        return;

? (As an aside, even if the variables were actually useful, it would
still be better to have them have initializers than to use separate
declarations and assignments.)

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 08:13:48 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 08:13:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875140.1285453 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ta9OI-0006ZO-KT; Tue, 21 Jan 2025 08:13:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875140.1285453; Tue, 21 Jan 2025 08:13:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ta9OI-0006ZH-He; Tue, 21 Jan 2025 08:13:42 +0000
Received: by outflank-mailman (input) for mailman id 875140;
 Tue, 21 Jan 2025 08:13:41 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Gode=UN=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1ta9OH-0006ZB-Su
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 08:13:41 +0000
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com
 [2a00:1450:4864:20::335])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9f65308d-d7cf-11ef-a0e4-8be0dac302b0;
 Tue, 21 Jan 2025 09:13:40 +0100 (CET)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-43618283d48so37621295e9.1
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 00:13:40 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-437c7527fc4sm229082475e9.27.2025.01.21.00.13.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 21 Jan 2025 00:13:39 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9f65308d-d7cf-11ef-a0e4-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737447220; x=1738052020; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=UJiWAcwRKVg70zxs6LKvPOa5P1qlh6eb+sEkP8s1ByI=;
        b=BjVGDcbFdEg9e9EYxjA1L+l49a/96NQomJSZ5d7cmdM2GrPs7IHTESEpdBTtxBbitB
         ygHwfVZ6rNhNekxQ3dXwShzt2I4DI18wViWITKao4+RaHIn0ngINoHFD8a/xu7iAT9YU
         1Q5D3d9FMG8Ul0tz3KFA4tXN7kQ7Y0+eNd8PtMP9xOdyRVTUPByUgNejmWPBgTYVX1fQ
         rOjAE6pA4ZFF51uLliBerjP88frnWhp1GfjcFgUYJt2tfYzUKcsUVDSLbHxa8FbJcYbk
         zWmw9NRgtNYt1nscOTegnq6Eh5pPop33ZyX/pmJvs7FcMkGUJroK/eoQTQ7/FPEpRT5C
         vQiw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737447220; x=1738052020;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=UJiWAcwRKVg70zxs6LKvPOa5P1qlh6eb+sEkP8s1ByI=;
        b=c8EljGUMg6WVkUny6tmEFocTRJff6PhG/PW1qBSPUjbb3CXYPrjbAPlQ3C94SINO1P
         FMxdumQfJxyww+2J2l2D5pT+drWjX/dzeabd2iuV+j9CttNC3TprG4OXq1khDKsJmhzC
         68KWdWLYpHkgTebnO7nuJU6SmU5Pv8ph18Z+Hb6Q9rqSGYZWkw8TogwkZAHpfZUJCSUl
         wdSfuJfxkVo4ynfEsmh1SzAJ6HhtUOxbwgMdT5VxR4Pxnm+MbhNuE3a7oMeTrALPZggY
         PxipjIH4nXJKJNtpxEEwSAAkhpp1DgTt72rPec2btXbNM3jN2ldZxh9k531xUoTipuUF
         qPFA==
X-Forwarded-Encrypted: i=1; AJvYcCUwtS4+A64F8zpIdXSuEy3fbAPyyL79a98C4PjeX3jF/yh+XLfPe6gbbqULSgUmmUx/ksBow1sG9Go=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxKcEXhPAQWmp4DKwL/Y+JOzWf/rs3xwSM+spxz54LJmFulJfW0
	gp81OaAh6JgH3pA/2goHuu87eLIxpJIoJ3WtMpD0QAj4GA3sNTtRzY8/NNo31w==
X-Gm-Gg: ASbGncuy4hckzN3SMSAXKP18x/uaW/Q0bH1sI/klULuxhZmFamxHzuFpqbPWP6+HMjZ
	AjyRoPquaRuVhM0fMElyPw7GdmTlDtZXK+0+1w+i2jCLivX790RgGQIUF3K2wcpN06uMd3WKbOG
	D97Hm65fFgS2YySR2KjKIPaMCpQLFILVDeJvVYVw4V0VCcNTNePhzwA+capYb6ElM+v1tWI1wfk
	pZCfH4RffrGeAvIz7iKvs75/tfyYFaImnrvCzMVniZwb1bprpj4zCkj/RLEgSx9oa1aX6kD2g5D
	a+GM6j0LKFs5OmzBfk+GydiFUmVuTTjqrbey5TS88PMHYFkkwjqBmg4=
X-Google-Smtp-Source: AGHT+IHsHcS4ngyhIji98Y1QMfHUQYjYj7HCqwxhr+Ikiw4m7MdMI/2OD0Ob1rnhn84/+yL8KkE2zQ==
X-Received: by 2002:a05:600c:138a:b0:435:194:3cdf with SMTP id 5b1f17b1804b1-438914292demr141042245e9.19.1737447219887;
        Tue, 21 Jan 2025 00:13:39 -0800 (PST)
Message-ID: <bae48627-fa5b-48b6-b74e-267285175eff@suse.com>
Date: Tue, 21 Jan 2025 09:13:38 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/4] x86: provide an inverted Kconfig control for
 shim-exclusive mode
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Alejandro Vallejo <alejandro.vallejo@cloud.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Julien Grall <julien@xen.org>, Wei Liu <wl@xen.org>, sergiy_kibrik@epam.com,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
References: <da5f5bac-6d5d-092d-d872-f1120dcd2661@suse.com>
 <617842e1-8ef2-b095-0c52-c2e2e5f1c0a8@suse.com>
 <alpine.DEB.2.22.394.2501161503120.2684657@ubuntu-linux-20-04-desktop>
 <Z4oxZSUQ6VARiR0H@macbook.local> <D74CH4RDRRR9.ZR6RL8U6PQ56@cloud.com>
 <6285f86d-f2d2-4040-999d-01aed3e72a36@suse.com>
 <alpine.DEB.2.22.394.2501171430570.2684657@ubuntu-linux-20-04-desktop>
 <f8c1e2c2-ceb5-4200-a304-e2d824a171a8@citrix.com>
 <40c9d806-000d-43e7-a804-ad4e84209b2f@suse.com>
 <alpine.DEB.2.22.394.2501201527090.11086@ubuntu-linux-20-04-desktop>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <alpine.DEB.2.22.394.2501201527090.11086@ubuntu-linux-20-04-desktop>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 21.01.2025 00:27, Stefano Stabellini wrote:
> On Mon, 20 Jan 2025, Jan Beulich wrote:
>> On 18.01.2025 00:41, Andrew Cooper wrote:
>>> On 17/01/2025 10:43 pm, Stefano Stabellini wrote:
>>>> On Fri, 17 Jan 2025, Jan Beulich wrote:
>>>>> On 17.01.2025 13:24, Alejandro Vallejo wrote:
>>>>>> On Fri Jan 17, 2025 at 10:31 AM GMT, Roger Pau Monné wrote:
>>>>>>> On Thu, Jan 16, 2025 at 04:31:46PM -0800, Stefano Stabellini wrote:
>>>>>>>> On Wed, 1 Mar 2023, Jan Beulich wrote:
>>>>>>>>> While we want certain things turned off in shim-exclusive mode, doing
>>>>>>>>> so via "depends on !PV_SHIM_EXCLUSIVE" badly affects allyesconfig: Since
>>>>>>>>> that will turn on PV_SHIM_EXCLUSIVE, other options will be turned off as
>>>>>>>>> a result. Yet allyesconfig wants to enable as much of the functionality
>>>>>>>>> as possible.
>>>>>>>>>
>>>>>>>>> Retain PV_SHIM_EXCLUSIVE as a prompt-less option such that first of all
>>>>>>>>> C code using it can remain as is. This isn't just for less code churn,
>>>>>>>>> but also because I think that symbol is more logical to use in many
>>>>>>>>> (all?) places.
>>>>>>>>>
>>>>>>>>> Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>>>>>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>>>>>>>
>>>>>>>>> ---
>>>>>>>>> The new Kconfig control's name is up for improvement suggestions, but I
>>>>>>>>> think it's already better than the originally thought of
>>>>>>>>> FULL_HYPERVISOR.
>>>>>>>> I think the approach in general is OK, maybe we can improve the naming
>>>>>>>> further. What about one of the following?
>>>>>>>>
>>>>>>>> NO_PV_SHIM_EXCLUSIVE
>>>>>>>> PV_SHIM_NOT_EXCLUSIVE
>>>>>>> IMO negated options are confusing, and if possible I think we should
>>>>>>> avoid using them unless strictly necessary.
>>>>>> The problem is that the option is negative in nature. It's asking for
>>>>>> hypervisor without _something_. I do agree with Stefano that shim would be
>>>>>> better in the name. Otherwise readers are forced to play divination tricks.
>>>>>>
>>>>>> How about something like:
>>>>>>
>>>>>>     SHIMLESS_HYPERVISOR
>>>>>>
>>>>>> That's arguably not negated, preserves "shim" in the name and has the correct
>>>>>> polarity for allyesconfig to yield the right thing.
>>>>> Except that a hypervisor with this option enabled isn't shim-less, but permits
>>>>> working in shim as well as in non-shim mode.
>>>> First, let's recognize that we have two opposing requirements. One
>>>> requirement is to make it as easy as possible to configure for the user.
>>>> Ideally without using negative CONFIG options, such as
>>>> NO_PV_SHIM_EXCLUSIVE. From the user point of view, honestly,
>>>> PV_SHIM_EXCLUSIVE is a pretty good name. Better than all of the others,
>>>> I think.
>>>>
>>>> On the other hand, we have the requirement that we don't want
>>>> allyesconfig to end up disabling a bunch of CONFIG options. Now this
>>>> requirement can be satisfied easily by adding something like
>>>> NO_PV_SHIM_EXCLUSIVE. However, it would go somewhat against the previous
>>>> requirement.
>>>>
>>>> So we need a compromise, something that doesn't end up disabling other
>>>> CONFIG options, to make allyesconfig happy, but also not too confusing
>>>> for the user (which is a matter of personal opinion).
>>>>
>>>> In short, expect that people will have different opinions on this and
>>>> will find different compromises better or worse. For one, I prefer to
>>>> compromise on "no negative CONFIG options" and use
>>>> PV_SHIM_NOT_EXCLUSIVE. Because it serves the allyesconfig goal, and
>>>> while it is not as clear as PV_SHIM_EXCLUSIVE, is still better than a
>>>> completely generic FULL_HYPERVISOR option, which means nothing to me.
>>>>
>>>> I cannot see a way to have a good and clear non-negated CONFIG option,
>>>> and also satisfy the allyesconfig requirement. So I prefer to compromise
>>>> on the "non-negated" part.
>>>
>>> Debating the naming is missing the point.
>>>
>>>
>>> The problem here is the wish to have PV_SHIM_EXCLUSIVE behave in a way
>>> that Kconfig is not capable of expressing.  Specifically, what is broken
>>> is having "lower level" options inhibit unrelated "higher level" options
>>> when the graph gets rescanned[1].  That's why we're in the laughable
>>> position of `make allyesconfig` turning off CONFIG_HVM.
>>>
>>> Jan, you want "echo PV_SHIM_EXCLUSIVE=y >> .config && make" to mean
>>> "reset me back to a PV Shim".
>>
>> Isn't this an independent goal? Or is this a statement on what you see
>> my change (kind of) doing, indicating you consider this wrong?
> 
> The way I understood it, it is the latter
> 
> 
>>> Kconfig spells this "make $foo_defconfig" for an appropriately given foo.
>>>
>>>
>>> There should be:
>>>
>>> 1) an option called PV_SHIM_EXCLUSIVE which does *nothing* other than
>>> making the boolean be a compile time constant.
>>
>> I fear it remains unclear to me what exactly you mean here. It feels like
>> you may be suggesting that all other uses of PV_SHIM_EXCLUSIVE should be
>> dropped, without replacement. That seems wrong to me, though. In
>> particular I'm of the opinion that besides using "make pvshim_defconfig"
>> people ought to also have the option to properly configure a shim build
>> from scratch (or from any random .config they hold in hands), requiring
>> respective "depends on" and/or "select" / "imply" to be in place.
> 
> That should be done with "make pvshim_defconfig"

Why? Specifically, why should people use only one entirely nailed down
configuration for a shim. Like a "normal" hypervisor, there are aspects
which very well can be left to the person doing the configuration.

>> Or else they may end up with a lot of dead code. (Just consider e.g.
>> HVM=n: We also don't permit HVM-only stuff to be enabled in that case,
>> as any of that would again be dead code then.)
> 
> It will always be possible to come up with poor configurations. I do not
> believe it is necessarily our responsibility to go out of our way to
> prevent them.

Well - if so, why would we do this in some cases but not in others?
You may recall that I'm a proponent of consistency and predictability.

>>> 2) a pvshim_defconfig target which expresses what a pvshim ought to look
>>> like.
>>
>> We have this file already. I consider it debatable though whether this file
>> should really force PV_SHIM_EXCLUSIVE=y. People may read "pvshim" in the
>> name as either "works just as shim" or "can also work as shim".
> 
> If I understood it right, I like Andrew's suggestion. He is suggesting
> to do the following:
> 
> - turning PV_SHIM_EXCLUSIVE into something that does nothing

FTAOD - you mean Kconfig-wise? Andrew clearly didn't say "nothing", but
"nothing other than making the boolean be a compile time constant".

> - adding "make pvshim_defconfig"

Why do you say "adding"? We have this already.

Jan

> So that:
> 
> - people use "make pvshim_defconfig" to get what today is enabled by
>   PV_SHIM_EXCLUSIVE
> - but "make allyesconfig" doesn't end up disabling things
> - the Kconfig menu makes sense because PV_SHIM_EXCLUSIVE goes away and
>   it is not replaced by anything
> 
> If I got it right, I am in favor.



From xen-devel-bounces@lists.xenproject.org Tue Jan 21 08:46:51 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 08:46:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875170.1285546 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ta9uH-00034Z-Tx; Tue, 21 Jan 2025 08:46:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875170.1285546; Tue, 21 Jan 2025 08:46:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ta9uH-00034S-RM; Tue, 21 Jan 2025 08:46:45 +0000
Received: by outflank-mailman (input) for mailman id 875170;
 Tue, 21 Jan 2025 08:46: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
 <SRS0=jEc5=UN=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1ta9uG-00034M-DD
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 08:46:44 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3c7cbe75-d7d4-11ef-99a4-01e77a169b0f;
 Tue, 21 Jan 2025 09:46:42 +0100 (CET)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-aaf6b1a5f2bso1239784966b.1
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 00:46:42 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab384f2903esm726241066b.109.2025.01.21.00.46.41
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 21 Jan 2025 00:46:41 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 3c7cbe75-d7d4-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737449202; x=1738054002; 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=2FgS81LB4NBRN++NAOxJ72iP2ET8JVvetObbwk8eQFs=;
        b=n0N/rD4J/J9tGw5EcK2K7+1xuetbEflsKxqmS0WLPway1HpnSXShonhPcnJLYfKlkg
         +RCRRCPr/18tzAc+F+/m1vJPYEN/4KA7AgQczvBnR9ObXVrIqGBt/qOyE6aqNCAmpJ9O
         ooVZgn/3cL1DxR9mleShRxmWTv8Rq1s4nJDlY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737449202; x=1738054002;
        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=2FgS81LB4NBRN++NAOxJ72iP2ET8JVvetObbwk8eQFs=;
        b=bsxJ4cfwW/UdP2IzGoIJvLZ2DXktiZNBBsYPwtyAVkIYy91lMP1T17oJDL8Yn5bSwF
         mX470Dio2yl1ZHGKsK3AoH2GmntSgLIXwkPB+ZyFJwY2TwtoytHXAQajDvFGlpwFCkrI
         eNer+yblNpuW6zKsH44ionbg2iKmphwqbXVGH5fHf7PViVQQgf5Fo1cf73qw/Ehx9OYw
         KrRrSqpd3dk8+zLFTe7bk7HoeoBNZaLd7tdMeNTzIFNyAIRDEo6xG8dtWYq1tPq7a2Gi
         tW8+lU7H03UfTd4ckQuvRJry3b+AMrYYfErQApqR27fQJ1SPCVMbbvmX6Y7eyw9N1Qjo
         YKMg==
X-Gm-Message-State: AOJu0YxSBmOdzsPed6S0qKWaLP/ouZFn0ngz6BIYZcff++0n75Yt6fCP
	0nAoVLqK8al0Uz4mVAFEAWcDM5HFINlxzpcgrTJdhbezJwRxCXjTw599/Z1MMrk=
X-Gm-Gg: ASbGnctz61nYczl29ZfDbspce3p4KVkY+Dor7BndNI78q4ERQ3HjZ86cNQYJAKbHXf+
	6kjhnZeNFcXBP0VDzNQLFeXcoga8o2xc/SMlOOrankzEBRrtqn4FU7RauTWRdE8vbpAk+8qGgoE
	4OpIWf5uW1F8InrZRHf9tkIPZ/FDYpycMZYuOTnggoaD6t+AmSmeK31iuX6N8F780dsI4nw1UkJ
	hgAZPHcyCvPBFhbJnVnHHF0vON85NUYTbRED4rDeitnDLnXKpUEe9kqzBMb0BqYqFwSLQulhU53
	EwHg
X-Google-Smtp-Source: AGHT+IH639w8V3BtUp5cxLcBjQetbapqpzOXln19CAP+ZqrDHOwP5XxOdyunw5Ijrqx20JiuObdrsQ==
X-Received: by 2002:a17:906:c156:b0:ab3:3283:faf9 with SMTP id a640c23a62f3a-ab38cd63286mr1133294666b.24.1737449201615;
        Tue, 21 Jan 2025 00:46:41 -0800 (PST)
Date: Tue, 21 Jan 2025 09:46:40 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jiqian Chen <Jiqian.Chen@amd.com>
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Huang Rui <ray.huang@amd.com>
Subject: Re: [PATCH v5] vpci: Add resizable bar support
Message-ID: <Z49e8NmROzke-tYc@macbook.local>
References: <20250114032636.3698383-1-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20250114032636.3698383-1-Jiqian.Chen@amd.com>

On Tue, Jan 14, 2025 at 11:26:36AM +0800, Jiqian Chen wrote:
> Some devices, like discrete GPU of amd, support resizable bar
> capability, but vpci of Xen doesn't support this feature, so
> they fail to resize bars and then cause probing failure.
> 
> According to PCIe spec, each bar that supports resizing has
> two registers, PCI_REBAR_CAP and PCI_REBAR_CTRL. So, add
> handlers for them to support resizing the size of BARs.
> 
> Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com>
> ---
> Hi all,
> v4->v5 changes:
> * Called pci_size_mem_bar in rebar_ctrl_write to get addr and size of BAR instead of setting
>   their values directly after writing new size to hardware.
> * Changed from "return" to "continue" when index/type of BAR are not correct during initializing
>   BAR.
> * Corrected the value of PCI_REBAR_CTRL_BAR_SIZE from "0x00001F00" to "0x00003F00".
> * Renamed PCI_REBAR_SIZE_BIAS to PCI_REBAR_CTRL_SIZE_BIAS.
> * Re-defined "PCI_REBAR_CAP_SHIFT 4" to "PCI_REBAR_CAP_SIZES_MASK 0xFFFFFFF0U".
> 
> Best regards,
> Jiqian Chen.
> 
> v3->v4 changes:
> * Removed PCI_REBAR_CAP_SIZES since it was not needed, and added
>   PCI_REBAR_CAP_SHIFT and PCI_REBAR_CTRL_SIZES.
> * Added parameter resizable_sizes to struct vpci_bar to cache the support resizable sizes and
>   added the logic in init_rebar().
> * Changed PCI_REBAR_CAP to PCI_REBAR_CAP(n) (4+8*(n)), changed PCI_REBAR_CTRL to
>   PCI_REBAR_CTRL(n) (8+8*(n)).
> * Added domain info of pci_dev to printings of init_rebar().
> 
> v2->v3 changes:
> * Used "bar->enabled" to replace "pci_conf_read16(pdev->sbdf, PCI_COMMAND) & PCI_COMMAND_MEMORY",
>   and added comments why it needs this check.
> * Added "!is_hardware_domain(pdev->domain)" check in init_rebar() to return EOPNOTSUPP for domUs.
> * Moved BAR type and index check into init_rebar(), then only need to check once.
> * Added 'U' suffix for macro PCI_REBAR_CAP_SIZES.
> * Added macro PCI_REBAR_SIZE_BIAS to represent 20.
> TODO: need to hide ReBar capability from hardware domain when init_rebar() fails.
> 
> v1->v2 changes:
> * In rebar_ctrl_write, to check if memory decoding is enabled, and added
>   some checks for the type of Bar.
> * Added vpci_hw_write32 to handle PCI_REBAR_CAP's write, since there is
>   no write limitation of dom0.
> * And has many other minor modifications as well.
> ---
>  xen/drivers/vpci/Makefile  |   2 +-
>  xen/drivers/vpci/rebar.c   | 135 +++++++++++++++++++++++++++++++++++++
>  xen/drivers/vpci/vpci.c    |   6 ++
>  xen/include/xen/pci_regs.h |  14 ++++
>  xen/include/xen/vpci.h     |   3 +
>  5 files changed, 159 insertions(+), 1 deletion(-)
>  create mode 100644 xen/drivers/vpci/rebar.c
> 
> diff --git a/xen/drivers/vpci/Makefile b/xen/drivers/vpci/Makefile
> index 1a1413b93e76..a7c8a30a8956 100644
> --- a/xen/drivers/vpci/Makefile
> +++ b/xen/drivers/vpci/Makefile
> @@ -1,2 +1,2 @@
> -obj-y += vpci.o header.o
> +obj-y += vpci.o header.o rebar.o
>  obj-$(CONFIG_HAS_PCI_MSI) += msi.o msix.o
> diff --git a/xen/drivers/vpci/rebar.c b/xen/drivers/vpci/rebar.c
> new file mode 100644
> index 000000000000..ed22a75e16fd
> --- /dev/null
> +++ b/xen/drivers/vpci/rebar.c
> @@ -0,0 +1,135 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (C) 2024 Advanced Micro Devices, Inc. All Rights Reserved.
> + *
> + * Author: Jiqian Chen <Jiqian.Chen@amd.com>
> + */
> +
> +#include <xen/sched.h>
> +#include <xen/vpci.h>
> +
> +static void cf_check rebar_ctrl_write(const struct pci_dev *pdev,
> +                                      unsigned int reg,
> +                                      uint32_t val,
> +                                      void *data)
> +{
> +    unsigned int index;
> +    struct vpci_bar *bar = data;
> +    uint64_t size = PCI_REBAR_CTRL_SIZE(val);
> +
> +    if ( bar->enabled )
> +    {
> +        /*
> +         * Refuse to resize a BAR while memory decoding is enabled, as
> +         * otherwise the size of the mapped region in the p2m would become
> +         * stale with the newly set BAR size, and the position of the BAR
> +         * would be reset to undefined.  Note the PCIe specification also
> +         * forbids resizing a BAR with memory decoding enabled.
> +         */
> +        if ( size != bar->size )
> +            gprintk(XENLOG_ERR,
> +                    "%pp: refuse to resize BAR with memory decoding enabled\n",
> +                    &pdev->sbdf);
> +        return;
> +    }
> +
> +    if ( !((size >> PCI_REBAR_CTRL_SIZE_BIAS) & bar->resizable_sizes) )
> +        gprintk(XENLOG_WARNING,
> +                "%pp: new size %#lx is not supported by hardware\n",
> +                &pdev->sbdf, size);
> +
> +    pci_conf_write32(pdev->sbdf, reg, val);
> +
> +    index = pci_conf_read32(pdev->sbdf, reg) & PCI_REBAR_CTRL_BAR_IDX;

No need for the PCI config space access, you can get the index using:

bar - pdev->vpci->header.bars

In fact you could define the local variables as:

struct vpci_bar *bar = data;
const unsigned int index = bar - pdev->vpci->header.bars;
uint64_t size = PCI_REBAR_CTRL_SIZE(val);

And use index in the error messages also:

"%pp: refuse to resize BAR#u with memory decoding enabled\n"
"%pp: new BAR#%u size %#lx is not supported by hardware\n",

> +    pci_size_mem_bar(pdev->sbdf, PCI_BASE_ADDRESS_0 + index * 4, &bar->addr,
> +                     &bar->size, ((index == PCI_HEADER_NORMAL_NR_BARS - 1) ?
> +                                  PCI_BAR_LAST : 0));

Seeing as Jan already asked you to fix indentation here, I think you
can also drop the outermost parentheses from the last argument.

> +    bar->guest_addr = bar->addr;
> +}
> +
> +static int cf_check init_rebar(struct pci_dev *pdev)
> +{
> +    uint32_t ctrl;
> +    unsigned int nbars;
> +    unsigned int rebar_offset = pci_find_ext_capability(pdev->sbdf,
> +                                                        PCI_EXT_CAP_ID_REBAR);
> +
> +    if ( !rebar_offset )
> +        return 0;
> +
> +    if ( !is_hardware_domain(pdev->domain) )
> +    {
> +        printk(XENLOG_ERR "%pp: resizable BARs unsupported for unpriv %pd\n",
> +               &pdev->sbdf, pdev->domain);
> +        return -EOPNOTSUPP;
> +    }
> +
> +    ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL(0));
> +    nbars = MASK_EXTR(ctrl, PCI_REBAR_CTRL_NBAR_MASK);
> +    for ( unsigned int i = 0; i < nbars; i++ )
> +    {
> +        int rc;
> +        struct vpci_bar *bar;
> +        unsigned int index;
> +
> +        ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL(i));
> +        index = ctrl & PCI_REBAR_CTRL_BAR_IDX;
> +        if ( index >= PCI_HEADER_NORMAL_NR_BARS )
> +        {
> +            printk(XENLOG_ERR "%pd %pp: too big BAR number %u in REBAR_CTRL\n",
> +                   pdev->domain, &pdev->sbdf, index);
> +            continue;
> +        }
> +
> +        bar = &pdev->vpci->header.bars[index];
> +        if ( bar->type != VPCI_BAR_MEM64_LO && bar->type != VPCI_BAR_MEM32 )
> +        {
> +            printk(XENLOG_ERR "%pd %pp: BAR%u is not in memory space\n",
> +                   pdev->domain, &pdev->sbdf, index);
> +            continue;
> +        }
> +
> +        rc = vpci_add_register(pdev->vpci, vpci_hw_read32, vpci_hw_write32,
> +                               rebar_offset + PCI_REBAR_CAP(i), 4, NULL);
> +        if ( rc )
> +        {
> +            /*
> +             * TODO: for failed pathes, need to hide ReBar capability
> +             * from hardware domain instead of returning an error.
> +             */
> +            printk(XENLOG_ERR "%pd %pp: fail to add reg of REBAR_CAP rc=%d\n",
> +                   pdev->domain, &pdev->sbdf, rc);
> +            return rc;
> +        }
> +
> +        rc = vpci_add_register(pdev->vpci, vpci_hw_read32, rebar_ctrl_write,
> +                               rebar_offset + PCI_REBAR_CTRL(i), 4, bar);
> +        if ( rc )
> +        {
> +            printk(XENLOG_ERR "%pd %pp: fail to add reg of REBAR_CTRL rc=%d\n",
> +                   pdev->domain, &pdev->sbdf, rc);
> +            return rc;

I think we said we wanted to attempt to continue here, rather than
returning an error and thus removing all vPCI handlers from the
device?

Error messages should also contain the BAR index IMO:

"%pd %pp: BAR%u fail to add reg of REBAR_{CAP,CTRL} rc=%d\n"

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 08:52:25 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 08:52:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875181.1285557 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ta9zh-0004oF-Jy; Tue, 21 Jan 2025 08:52:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875181.1285557; Tue, 21 Jan 2025 08:52:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ta9zh-0004o8-H3; Tue, 21 Jan 2025 08:52:21 +0000
Received: by outflank-mailman (input) for mailman id 875181;
 Tue, 21 Jan 2025 08:52:20 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=jEc5=UN=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1ta9zg-0004o2-50
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 08:52:20 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 05204a19-d7d5-11ef-a0e4-8be0dac302b0;
 Tue, 21 Jan 2025 09:52:18 +0100 (CET)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-aab6fa3e20eso965466366b.2
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 00:52:18 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab5af51c7aesm157812366b.57.2025.01.21.00.52.17
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 21 Jan 2025 00:52:17 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 05204a19-d7d5-11ef-a0e4-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737449538; x=1738054338; 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=aTv6vPUEVmrYUvmmGf59uBtbyDnFk9VGXKm3BCsFU+s=;
        b=SXEg2AdOO2jl8otQab2RpNrJrcQmdy/V5NVuqBbzHb0UQbYhqY23ZXfxEkhHTrfrT7
         D7Trit6fMhpSvCSV/+i/Jg0vesyutTYvL3pJ/2tli1M88RHWT/0js+x5qsleIYrr4fKy
         xxdx1Jszczc0BnM99Mq28BeCc8CuIQV3F9cOY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737449538; x=1738054338;
        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=aTv6vPUEVmrYUvmmGf59uBtbyDnFk9VGXKm3BCsFU+s=;
        b=wQvTL5dibN9xN+dyC0RB9tQQdit5VhwOByBiStK4tTaMuLQTWUZnFpVDUrb30C0EXG
         7zwHZ0JMKS5LTYcZ8sJ+YtTSC2pbSQ2xYAABrG4DYXatpBr7G9NocTutd+dSOhuPhS0k
         pvU71FZz05cospXoN9eb8VazJjr9NfGamPebhp77/GB1X71XtRWx0o1QghgvuH3aY3cV
         rmG3ZtMw6iKgfXcZArFDyOmywYf+ywuKPYt7Q6PVTAcwWXN6jvOF8oEZkQ9DLZRosgtJ
         ojRBSL2Ee3mcwmyQgKjug+/neTaHVGXKR+k9lRlS6owm3EbnbflmNbYIcmO3alpmHol0
         KYMA==
X-Forwarded-Encrypted: i=1; AJvYcCUeoiF7gTOL9TcYrzh9l4DCtgIrazxKpreXGODxbjirtltIB6jYuiks1nFw/rntNCKPZFLtIAPth7E=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzLBZKMUKMfWpHir1Ea0RzeZD8SFolXEGGy/+ZnGrPI2ChdquWd
	OKELP079es58BDfRboh+KTGnEHSMrTH4LBhX7nUOjkH3Hrw2OFvYGKb+j1yv+57H01wCr8Pl7VF
	d
X-Gm-Gg: ASbGnctUTYmNQfgqMF7O5eRp0BtNbV2zdhyhJzbXhnnYEsO0O/SuZ89dqS09K20gNRw
	n3kJlaTouiwUARLmUzmMDvh/uDNX0r3PN0CPdhdX1+Es7+jWUcbbNu1qaNyiOhR5FrLDRs4wF6A
	iFOEBzcuoMTa5uSJC0pha1bbXGPlAi+rAdYUwuePYLoyZUM2XGewP7ELP8ZwDwJLts0L8gA8sUT
	XHS2EZ5dBhVUIl8vS5YYoIIej2D33zBGTZHeG2Li8dV3MzEif6gXA1hK72ezWeoZfifl0o0yVQ=
X-Google-Smtp-Source: AGHT+IHkTvNYTtWu3uZa7xcWM8VVWoqcNwe+7dcX05a66lIUfgH9AD1fXYJilc/ni7W0yd3mq1YJ9w==
X-Received: by 2002:a17:907:9307:b0:ab2:d2e7:abc7 with SMTP id a640c23a62f3a-ab38b203dfamr1328416166b.19.1737449538024;
        Tue, 21 Jan 2025 00:52:18 -0800 (PST)
Date: Tue, 21 Jan 2025 09:52:16 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Alejandro Vallejo <alejandro.vallejo@cloud.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Julien Grall <julien@xen.org>, Wei Liu <wl@xen.org>,
	sergiy_kibrik@epam.com
Subject: Re: [PATCH v2 1/4] x86: provide an inverted Kconfig control for
 shim-exclusive mode
Message-ID: <Z49gQBkxCbXIO84D@macbook.local>
References: <617842e1-8ef2-b095-0c52-c2e2e5f1c0a8@suse.com>
 <alpine.DEB.2.22.394.2501161503120.2684657@ubuntu-linux-20-04-desktop>
 <Z4oxZSUQ6VARiR0H@macbook.local>
 <D74CH4RDRRR9.ZR6RL8U6PQ56@cloud.com>
 <6285f86d-f2d2-4040-999d-01aed3e72a36@suse.com>
 <alpine.DEB.2.22.394.2501171430570.2684657@ubuntu-linux-20-04-desktop>
 <f8c1e2c2-ceb5-4200-a304-e2d824a171a8@citrix.com>
 <40c9d806-000d-43e7-a804-ad4e84209b2f@suse.com>
 <alpine.DEB.2.22.394.2501201527090.11086@ubuntu-linux-20-04-desktop>
 <bae48627-fa5b-48b6-b74e-267285175eff@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <bae48627-fa5b-48b6-b74e-267285175eff@suse.com>

On Tue, Jan 21, 2025 at 09:13:38AM +0100, Jan Beulich wrote:
> On 21.01.2025 00:27, Stefano Stabellini wrote:
> > On Mon, 20 Jan 2025, Jan Beulich wrote:
> >> On 18.01.2025 00:41, Andrew Cooper wrote:
> >>> On 17/01/2025 10:43 pm, Stefano Stabellini wrote:
> >>>> On Fri, 17 Jan 2025, Jan Beulich wrote:
> >>>>> On 17.01.2025 13:24, Alejandro Vallejo wrote:
> >>>>>> On Fri Jan 17, 2025 at 10:31 AM GMT, Roger Pau Monné wrote:
> >>>>>>> On Thu, Jan 16, 2025 at 04:31:46PM -0800, Stefano Stabellini wrote:
> >>>>>>>> On Wed, 1 Mar 2023, Jan Beulich wrote:
> >>>>>>>>> While we want certain things turned off in shim-exclusive mode, doing
> >>>>>>>>> so via "depends on !PV_SHIM_EXCLUSIVE" badly affects allyesconfig: Since
> >>>>>>>>> that will turn on PV_SHIM_EXCLUSIVE, other options will be turned off as
> >>>>>>>>> a result. Yet allyesconfig wants to enable as much of the functionality
> >>>>>>>>> as possible.
> >>>>>>>>>
> >>>>>>>>> Retain PV_SHIM_EXCLUSIVE as a prompt-less option such that first of all
> >>>>>>>>> C code using it can remain as is. This isn't just for less code churn,
> >>>>>>>>> but also because I think that symbol is more logical to use in many
> >>>>>>>>> (all?) places.
> >>>>>>>>>
> >>>>>>>>> Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
> >>>>>>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >>>>>>>>>
> >>>>>>>>> ---
> >>>>>>>>> The new Kconfig control's name is up for improvement suggestions, but I
> >>>>>>>>> think it's already better than the originally thought of
> >>>>>>>>> FULL_HYPERVISOR.
> >>>>>>>> I think the approach in general is OK, maybe we can improve the naming
> >>>>>>>> further. What about one of the following?
> >>>>>>>>
> >>>>>>>> NO_PV_SHIM_EXCLUSIVE
> >>>>>>>> PV_SHIM_NOT_EXCLUSIVE
> >>>>>>> IMO negated options are confusing, and if possible I think we should
> >>>>>>> avoid using them unless strictly necessary.
> >>>>>> The problem is that the option is negative in nature. It's asking for
> >>>>>> hypervisor without _something_. I do agree with Stefano that shim would be
> >>>>>> better in the name. Otherwise readers are forced to play divination tricks.
> >>>>>>
> >>>>>> How about something like:
> >>>>>>
> >>>>>>     SHIMLESS_HYPERVISOR
> >>>>>>
> >>>>>> That's arguably not negated, preserves "shim" in the name and has the correct
> >>>>>> polarity for allyesconfig to yield the right thing.
> >>>>> Except that a hypervisor with this option enabled isn't shim-less, but permits
> >>>>> working in shim as well as in non-shim mode.
> >>>> First, let's recognize that we have two opposing requirements. One
> >>>> requirement is to make it as easy as possible to configure for the user.
> >>>> Ideally without using negative CONFIG options, such as
> >>>> NO_PV_SHIM_EXCLUSIVE. From the user point of view, honestly,
> >>>> PV_SHIM_EXCLUSIVE is a pretty good name. Better than all of the others,
> >>>> I think.
> >>>>
> >>>> On the other hand, we have the requirement that we don't want
> >>>> allyesconfig to end up disabling a bunch of CONFIG options. Now this
> >>>> requirement can be satisfied easily by adding something like
> >>>> NO_PV_SHIM_EXCLUSIVE. However, it would go somewhat against the previous
> >>>> requirement.
> >>>>
> >>>> So we need a compromise, something that doesn't end up disabling other
> >>>> CONFIG options, to make allyesconfig happy, but also not too confusing
> >>>> for the user (which is a matter of personal opinion).
> >>>>
> >>>> In short, expect that people will have different opinions on this and
> >>>> will find different compromises better or worse. For one, I prefer to
> >>>> compromise on "no negative CONFIG options" and use
> >>>> PV_SHIM_NOT_EXCLUSIVE. Because it serves the allyesconfig goal, and
> >>>> while it is not as clear as PV_SHIM_EXCLUSIVE, is still better than a
> >>>> completely generic FULL_HYPERVISOR option, which means nothing to me.
> >>>>
> >>>> I cannot see a way to have a good and clear non-negated CONFIG option,
> >>>> and also satisfy the allyesconfig requirement. So I prefer to compromise
> >>>> on the "non-negated" part.
> >>>
> >>> Debating the naming is missing the point.
> >>>
> >>>
> >>> The problem here is the wish to have PV_SHIM_EXCLUSIVE behave in a way
> >>> that Kconfig is not capable of expressing.  Specifically, what is broken
> >>> is having "lower level" options inhibit unrelated "higher level" options
> >>> when the graph gets rescanned[1].  That's why we're in the laughable
> >>> position of `make allyesconfig` turning off CONFIG_HVM.
> >>>
> >>> Jan, you want "echo PV_SHIM_EXCLUSIVE=y >> .config && make" to mean
> >>> "reset me back to a PV Shim".
> >>
> >> Isn't this an independent goal? Or is this a statement on what you see
> >> my change (kind of) doing, indicating you consider this wrong?
> > 
> > The way I understood it, it is the latter
> > 
> > 
> >>> Kconfig spells this "make $foo_defconfig" for an appropriately given foo.
> >>>
> >>>
> >>> There should be:
> >>>
> >>> 1) an option called PV_SHIM_EXCLUSIVE which does *nothing* other than
> >>> making the boolean be a compile time constant.
> >>
> >> I fear it remains unclear to me what exactly you mean here. It feels like
> >> you may be suggesting that all other uses of PV_SHIM_EXCLUSIVE should be
> >> dropped, without replacement. That seems wrong to me, though. In
> >> particular I'm of the opinion that besides using "make pvshim_defconfig"
> >> people ought to also have the option to properly configure a shim build
> >> from scratch (or from any random .config they hold in hands), requiring
> >> respective "depends on" and/or "select" / "imply" to be in place.
> > 
> > That should be done with "make pvshim_defconfig"
> 
> Why? Specifically, why should people use only one entirely nailed down
> configuration for a shim. Like a "normal" hypervisor, there are aspects
> which very well can be left to the person doing the configuration.

But nothing prevents a user from starting from a shim defconfig, and
then tweaking it as desired:

$ make pvshim_defconfig
$ make menuconfig

Or there's something I'm missing here?

> >> Or else they may end up with a lot of dead code. (Just consider e.g.
> >> HVM=n: We also don't permit HVM-only stuff to be enabled in that case,
> >> as any of that would again be dead code then.)
> > 
> > It will always be possible to come up with poor configurations. I do not
> > believe it is necessarily our responsibility to go out of our way to
> > prevent them.
> 
> Well - if so, why would we do this in some cases but not in others?
> You may recall that I'm a proponent of consistency and predictability.
> 
> >>> 2) a pvshim_defconfig target which expresses what a pvshim ought to look
> >>> like.
> >>
> >> We have this file already. I consider it debatable though whether this file
> >> should really force PV_SHIM_EXCLUSIVE=y. People may read "pvshim" in the
> >> name as either "works just as shim" or "can also work as shim".
> > 
> > If I understood it right, I like Andrew's suggestion. He is suggesting
> > to do the following:
> > 
> > - turning PV_SHIM_EXCLUSIVE into something that does nothing
> 
> FTAOD - you mean Kconfig-wise? Andrew clearly didn't say "nothing", but
> "nothing other than making the boolean be a compile time constant".

Won't making the boolean a compile time constant would also result in
DCO kicking in and removing a fair amount of code?  So even if you
have enabled everything in Kconfig, the resulting hypervisor would
only be suitable to be used as a shim?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 09:10:51 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 09:10:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875189.1285566 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taAHL-0007fB-1J; Tue, 21 Jan 2025 09:10:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875189.1285566; Tue, 21 Jan 2025 09:10:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taAHK-0007f4-Un; Tue, 21 Jan 2025 09:10:34 +0000
Received: by outflank-mailman (input) for mailman id 875189;
 Tue, 21 Jan 2025 09:10: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
 <SRS0=WcK4=UN=amd.com=Jiqian.Chen@srs-se1.protection.inumbo.net>)
 id 1taAHJ-0007eR-Cu
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 09:10:33 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on2060c.outbound.protection.outlook.com
 [2a01:111:f403:2418::60c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8f919926-d7d7-11ef-a0e4-8be0dac302b0;
 Tue, 21 Jan 2025 10:10:31 +0100 (CET)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by SJ1PR12MB6097.namprd12.prod.outlook.com (2603:10b6:a03:488::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8356.20; Tue, 21 Jan
 2025 09:10:26 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285%4]) with mapi id 15.20.8356.020; Tue, 21 Jan 2025
 09:10:26 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8f919926-d7d7-11ef-a0e4-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=dCv+ticTYwbugWH9WgkivT5ixeZSOFXEPzuRD5YdUvNUuOmHiX0Dw1gKlxkP6v01s4guUtGAkacdxbGxFFey7pdRiq7iUR9PTbtsxdTCRXsffpUbyNomKRhKPDALTXNzI6BHN1s0H88yZeTr4lLLOiHyQC18FHOlIBsrN8R3XfCjdDD/PwOMhpA/8r2RZRdDD/AAREJ5RduVHEYzEVgiog6lDivg2fwbvx3iFew/HjW2b6eW1pDllPXmKCYLXYyM4LM66fId80IsSWR8RnZc1I+cT4+I/JLaGXMchDYOSLf5HSfHd3wPTA27DdAT+0uWyqn5BlJcWq117uqp/oSqBQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=W/uidy0zt/6oRCT8NcuWjDEM2TIENa4DTDV8uP9OQCA=;
 b=xwEtBXCeDOhBG54dlAl8deXs/DY9aavjn0vPN4p9PTZwiLD9A8ROp8oOxJYhUoIUFV53Qhiy9CMwIrsK6J5YdpmvG2P/bV1im9NmI+CzY8hzc+Lv/mG8xH7V8oLJ/GBsT/P6xSmEtqbJ5fo/53lqeIwZxWI0Zptild2rzrDCSvJz2N2oU8C9nlcuSBDJNPhburg5Wt43hALVxQeNVmxlhLMKEETk6dSDVuESNHgbc/tg7KyWoZilUT2NT8PqaairOTgGEleS8RzUE0RBsgJfv//7Ki6G3pyASmtOnDfWTh/gh8Iwm/vWdFBQjfjUYyFNnJkXTOVQdbxLAHFJD6XbkQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=W/uidy0zt/6oRCT8NcuWjDEM2TIENa4DTDV8uP9OQCA=;
 b=ELse1WlP2PqJEgzKdcu7F5ez9JrBTJ+0TvrmqmR6/hCVjBlY/kMHkqsWymnjBbWCGEstt8hcjUbNZxed8N7xEFMnVXK0oxRW9eW34Z2R/CvqhzRu1ujA38X/Znd6KLP6QW/G3c5eZFJI5XgMV0sBeycDOkKCv+AM5ydriElTzjM=
From: "Chen, Jiqian" <Jiqian.Chen@amd.com>
To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>, Jan Beulich
	<jbeulich@suse.com>
CC: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Andrew
 Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, Stefano
 Stabellini <sstabellini@kernel.org>, "Huang, Ray" <Ray.Huang@amd.com>, "Chen,
 Jiqian" <Jiqian.Chen@amd.com>
Subject: Re: [PATCH v5] vpci: Add resizable bar support
Thread-Topic: [PATCH v5] vpci: Add resizable bar support
Thread-Index: AQHbZjRJ+4D0uojYEUmC9gRuRAux1rMg9ZEAgACK3YA=
Date: Tue, 21 Jan 2025 09:10:26 +0000
Message-ID:
 <BL1PR12MB58492016DDBB106A607F32CDE7E62@BL1PR12MB5849.namprd12.prod.outlook.com>
References: <20250114032636.3698383-1-Jiqian.Chen@amd.com>
 <Z49e8NmROzke-tYc@macbook.local>
In-Reply-To: <Z49e8NmROzke-tYc@macbook.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com
 (15.20.8356.017)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|SJ1PR12MB6097:EE_
x-ms-office365-filtering-correlation-id: 78f7ca5b-877f-4458-9294-08dd39fb71c5
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?RGhJUmUxN1JmTVN5OU4xZU92Z1dtSURpbmdLUnlpekE1cmVKTk5Mak1seThF?=
 =?utf-8?B?OFBzZDhWYVpTS1Q1VFNaa1ppVDNNbFloTEJlTU5qNmk0cXFvSG45WU4vanRy?=
 =?utf-8?B?UG9WSmU4djRuV0FuSGZQeHk0NXlkOEJ3WjkrUlRzVGtaakZXb0lIRDNnMDI0?=
 =?utf-8?B?ZlJIVC80cnNqSXRRakNEQjd4QUJDTUFTaFFFSEVKV21LTU9wTlJjNjYzR2Zi?=
 =?utf-8?B?Wi9NY2FGYUlKRXdCVk8xdjJxZ0xNdmJ5VzhRZ2t4a2pLWHBlQTFubVBQYkVm?=
 =?utf-8?B?alU3enBzUDhyQy9CZk15SjZKSUtscjhPbG8wSVoyRStpbFZ1ZzNseWltekw4?=
 =?utf-8?B?ZWlsMG0wczRteHgyQzlyeVVqU01aYUhFR2VtbUY0UEd6SGJud3BkZzRFRC9S?=
 =?utf-8?B?OGNRRUFmMjZ4RVBNbjFaS3NjQmNIZ3hkSmorVWtBTGQzQXA3NEFKUEdkY01h?=
 =?utf-8?B?dTBGSHNBSThac1I4UlZueTEwaHprcnFsWVovQTFjdyt1cnVmMlp4VUVUc3ls?=
 =?utf-8?B?MzNtTE81VmtkR0RvZy9CYUU5ekpUZWxNVlBEa2pzeitVaDJZdVc0UnF6Sk80?=
 =?utf-8?B?N29oR1Ava1hqa2E1RlFRWmRKcEIxdDJPVFRwSS93eVZheWxjNW1EY3FUN0gw?=
 =?utf-8?B?N2M2OStXcDcwQXRzQkZ5bHc0MUZBOENzNnZJYmREbldGWllKc0I1VnpGZ3R2?=
 =?utf-8?B?WDZIUzh2dmRXQjlpUC9DWkVaYm9URHBtWE9VK2JNcnBVd1BrWGNqRXVnNEh1?=
 =?utf-8?B?SkJWL2hsR3cycVh3c29sV3BONkQxQk5FbXU5cW1WWU9yOHRtT1NvWG16UkVk?=
 =?utf-8?B?b3dMU2dVNEFJK1FEVEcxMVoyVFNoMUxDSzhhWDl1T1RRUkdsRnBUaDdZcjkr?=
 =?utf-8?B?RUtWOTBFdTlPSVdGb1BiOXZ6emEram44KzBHaVVUVnlreHZWbjJ6RjQ4UmQx?=
 =?utf-8?B?OHZFaFBWbjhMYWVCT1AxQU51QXh6NjVDTDY3Q1JTY1dpWFYrUTliK2RYVGtS?=
 =?utf-8?B?Wk5EUmJrRkVubit0SkpQbUNVcVd1aXI0UkpmRStLS3lJK3dDc2QwMjh1c0U5?=
 =?utf-8?B?Q1NTVTVVV3RBNkVlWlJCaEJlK1dhdmNxSEVKb25ueDVEd2JhYjFDQWVLL2hT?=
 =?utf-8?B?RFJmUkZmV1RlemdKZ1FTeXhnMTZhQ2pkelkrbHlEeDcrNEQyb3ZPei8vN0dQ?=
 =?utf-8?B?QzY0MlF2OUJOeG1rQTF1QVlXcXMxUjNSWlZjL0E1K3ZxTmRKd0pIWTRKM3BZ?=
 =?utf-8?B?V21BUlFwbzJPdEFaRTRyNExTUGRWVkdYMTROM1JaWkhpTEhieVRxVTg5cDlW?=
 =?utf-8?B?VSs2bC9NSHZhekdiOEdjU3YzNk55U21sYnNTZDl1VG1jU2tLaDJEL3pZeWFR?=
 =?utf-8?B?QlFDazF1UGJNWk9EY3VXOWVmdXFKSVRkNFJpVWg2QXNYdGlqSWNwYnlsQ0Ew?=
 =?utf-8?B?eEgza1N6RzNCWDVuUG95ME5YRFY5dW42WnM3UzBObVdvSC9kTlNvdnJTRzZC?=
 =?utf-8?B?dkdhSFIzR2daQ0d3YVJ1V3p5dFVML2N3dE9HYXd4elVZNHVxQzNRUkxLNURJ?=
 =?utf-8?B?Q3VaeEVkSGJ6MFoycURwQ0RBZDRUT3dyeFVHTzZ2WTZDWUtlR0ducU9XdDc5?=
 =?utf-8?B?TmtHdlRZUmpKNlVQa0F6NS9VSzlNbGwrTUU2OFE4U0pjL3BHdHRCMUhlRWZG?=
 =?utf-8?B?STFjUDU4RjQ3N1FxNWdkc3Y4N3lkbUppRmFHZlNaM1JwRVM0dlZzd05KVXJ0?=
 =?utf-8?B?QlBBNGtUSXcvUmcwbi9na1ZPQm90UU5aa2Y4RHdSRURSUWR2Nm9aM3h1c3Jv?=
 =?utf-8?B?MjNlWnRocVZkeFhUK2dRU25vRHV1WlFEdFZrNjdzbGlvNFgwKzFVRTF3RHhv?=
 =?utf-8?B?RXBVcy9hQTFDZkFRempBelJmQVNmQVVkM3RqQWpsTGVWbStqdUQzc2VTWlNi?=
 =?utf-8?Q?fsnJ5liu9VZOmhlr2mY/WhUF+YjP4oyL?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?QjNXQjNhMEFFdXFVOWVMWlowQk8yWEZPa1YyKysyQ05QdFI4bHhmWkdqVVRF?=
 =?utf-8?B?ajc5ZS93eC9EcDBId0VEaTFlU1RCUDhSTFVCclRBVWxJaG5oWlJWVW13UlFv?=
 =?utf-8?B?aHJtSVVUWUdxWHAxZHZabmc1Z2lHMWpqbU9uRURodHlyci9DZVVBUmFVemR5?=
 =?utf-8?B?Umw0MERzM1pwVFRDUmsyOHRQSWtlUTBxeERMdHJFQWFYQjdpOEVWWnZCVzFE?=
 =?utf-8?B?YmJXUzZzdERzSnFFWUhBTXpDMWlHZ0U3bzFXeTExK0E1eGhaOThROWJkNlE4?=
 =?utf-8?B?WlJNYnVqZmhteWY4SGQ5TklHdEV5SndvZkRZZWhqWThUcmJoVmxTTkhyZXJ3?=
 =?utf-8?B?cHViU2JoTWV4VHhlMmZmazFwNEt5U2RKWHhaZEtXeGp6OFlBQWljZURMWTZX?=
 =?utf-8?B?Z3FVZ3Mwa1RxSG1EajRjdjYyKzZWWU15TmJUellBdFFJUWpLaEFUOGkyb0lL?=
 =?utf-8?B?cVRxNzdOTUNVMDZqUWZrOTdMUVdqaXZzNHdYNG8vQ0xqQVFKV3lkeVN3MWdR?=
 =?utf-8?B?dUgyYUpWY0IyelZpNVMycFQyQm9SWmpzT1FYTGt1NkRWeEdmZ3NwcEd3VWg1?=
 =?utf-8?B?dkNoWlg1NFpwd3dUbldvalBSNU5yMjN2UlVQTTNvaVlmSnFuRnNNRWM1L3du?=
 =?utf-8?B?dkJTbloySDNlTU5yUWhNSFJRWllBWDFuWmVQRkxoS25YUDRGdk8ybEhmczY1?=
 =?utf-8?B?SlU3UjROcmN4VndDcjdRWENVd09NWExEejdseUExMjVQSW9GYkFYK09aVksx?=
 =?utf-8?B?cnVVNnc1QlJLUy9ydGpDVVZ6NkFGbTRCcUlYVFQyQndxNzQ5eFFYWkQ3SERX?=
 =?utf-8?B?TW1tbDBwZEU2OXVCOVdkMjR0cHc5eWFiUnlZWWNhZmdPUkNnbWJtV1FxM1FK?=
 =?utf-8?B?OFJycEhZbll0VTIrcnZkVk54WWh5Zkl5TitLamFna1FlV0JXRUVxMEVuUU5L?=
 =?utf-8?B?cEtsaDFwQWdVRXVPampleVRkVjF4d2JVTVRFQWRtWFVtVnBqd2d2UWRXczhw?=
 =?utf-8?B?TVgxY2N5YjlhaW44K1RjT1lMQS81ZW82RWpqcG9PNS8xUHEyS0kwbGhCekpr?=
 =?utf-8?B?SElUNVFqZExHbEZYQWFkK3hsYXFUUnRMOTBkdnFUZDhpbitEQUYvcUxabEx0?=
 =?utf-8?B?WEpySnY3Rlp3K3k4RDhRQkVPdVJ4YXB3bHJXL0kwd2hkekZUaHRvKythaVIw?=
 =?utf-8?B?TTZsYXoxSXhTRXlzeFdtdmdNTzJtOFFtNCs4dC9jNG5jTzA5eTJ2b2FWZVJ4?=
 =?utf-8?B?eXpYTGJZcFJ4UkQvMHRRdU9LOEpNQ2VNaUZ2OUtHQWwrdmFKOGFQQTROeEtZ?=
 =?utf-8?B?RGNObFJqYmQ4a0FjQUVuU3pVYnpFa1QrK2JVU1JUZjdYM21RWDd6QkRMNUEw?=
 =?utf-8?B?eHV4YVpGQXFzQW44TC9rdU5MZTU2bGR0aHdCckF2NnpaaHlvTDM1dmpHc2F5?=
 =?utf-8?B?ZU9XdngwYTlFbmRRQ2REaE5uc2crVEFqZGRJYzh1d05QMWxiUURiMGRpcDZr?=
 =?utf-8?B?TWxXYWRLalQrUFZkdSt0UTZuRFpzYURaVHhIVHEreHgvQWlBcmx4UTA4aU1F?=
 =?utf-8?B?TU03WHhSUzZ1V0pEOUtZc1psMjdGVGxYUW1hemV1VVUxLzlXbklZK1dMc2Nq?=
 =?utf-8?B?eDlGNURDeUJKbUxCK0R3MFlmd0x1ZGlUK3N1ME5wMDRKTGl1bm1TZGpObGp6?=
 =?utf-8?B?bzh4R2luVTdRajZRTTc0MmJ2VC9tdDRvSFA0R2VGMU80WTh5N2JTUkkzTm9Q?=
 =?utf-8?B?eElUQUVhYTF3ZUxIMVUxeGdrOEhLQytyYUVLWFNiUS9zSU04cXNlWHJ4alQy?=
 =?utf-8?B?NkpaZm9pRWE5OEIvWG1ZWjU2dnpuVENvaWtTOEVNRTZIcnM2UjhMZ1NxUVBK?=
 =?utf-8?B?R0lHMnMxR0dXVnZUVjRVaWEvbVBNRHFWRmdnMUY1UzY4SEppbnZLa3dwOU90?=
 =?utf-8?B?MW1rUXc0THZ1MENEVlRjQW1xM0lPTXBsRmhBdFB3eS9vU01Jc3RmL1NFcVVO?=
 =?utf-8?B?dS9QMXVHbitHUXpUdUF3V3RrZlRTQnVVSGJxbllhNkFJYkIyZTlUUllFWC83?=
 =?utf-8?B?bFgxZElrYk5PSXc2Vis5eFVZZGtVeHAySGt0SXJlQTBXWU1uM1IzYUtyK3A0?=
 =?utf-8?Q?U9Ak=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <7965CE5ECFE26E4A9D81B6E71A313FC7@amdcloud.onmicrosoft.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 78f7ca5b-877f-4458-9294-08dd39fb71c5
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2025 09:10:26.4243
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: NyYGwUS7Qgfw/k3Gfshx2kWH/3KQoOjw12LO7GyR4SSGS4I506Q8Y05ivNZVf0p98Cyxi7+7jcGA4vJRZmsIGQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ1PR12MB6097

T24gMjAyNS8xLzIxIDE2OjQ2LCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOg0KPiBPbiBUdWUsIEph
biAxNCwgMjAyNSBhdCAxMToyNjozNkFNICswODAwLCBKaXFpYW4gQ2hlbiB3cm90ZToNCj4+ICsg
ICAgY3RybCA9IHBjaV9jb25mX3JlYWQzMihwZGV2LT5zYmRmLCByZWJhcl9vZmZzZXQgKyBQQ0lf
UkVCQVJfQ1RSTCgwKSk7DQo+PiArICAgIG5iYXJzID0gTUFTS19FWFRSKGN0cmwsIFBDSV9SRUJB
Ul9DVFJMX05CQVJfTUFTSyk7DQo+PiArICAgIGZvciAoIHVuc2lnbmVkIGludCBpID0gMDsgaSA8
IG5iYXJzOyBpKysgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBpbnQgcmM7DQo+PiArICAgICAg
ICBzdHJ1Y3QgdnBjaV9iYXIgKmJhcjsNCj4+ICsgICAgICAgIHVuc2lnbmVkIGludCBpbmRleDsN
Cj4+ICsNCj4+ICsgICAgICAgIGN0cmwgPSBwY2lfY29uZl9yZWFkMzIocGRldi0+c2JkZiwgcmVi
YXJfb2Zmc2V0ICsgUENJX1JFQkFSX0NUUkwoaSkpOw0KPj4gKyAgICAgICAgaW5kZXggPSBjdHJs
ICYgUENJX1JFQkFSX0NUUkxfQkFSX0lEWDsNCj4+ICsgICAgICAgIGlmICggaW5kZXggPj0gUENJ
X0hFQURFUl9OT1JNQUxfTlJfQkFSUyApDQo+PiArICAgICAgICB7DQo+PiArICAgICAgICAgICAg
cHJpbnRrKFhFTkxPR19FUlIgIiVwZCAlcHA6IHRvbyBiaWcgQkFSIG51bWJlciAldSBpbiBSRUJB
Ul9DVFJMXG4iLA0KPj4gKyAgICAgICAgICAgICAgICAgICBwZGV2LT5kb21haW4sICZwZGV2LT5z
YmRmLCBpbmRleCk7DQo+PiArICAgICAgICAgICAgY29udGludWU7DQo+PiArICAgICAgICB9DQo+
PiArDQo+PiArICAgICAgICBiYXIgPSAmcGRldi0+dnBjaS0+aGVhZGVyLmJhcnNbaW5kZXhdOw0K
Pj4gKyAgICAgICAgaWYgKCBiYXItPnR5cGUgIT0gVlBDSV9CQVJfTUVNNjRfTE8gJiYgYmFyLT50
eXBlICE9IFZQQ0lfQkFSX01FTTMyICkNCj4+ICsgICAgICAgIHsNCj4+ICsgICAgICAgICAgICBw
cmludGsoWEVOTE9HX0VSUiAiJXBkICVwcDogQkFSJXUgaXMgbm90IGluIG1lbW9yeSBzcGFjZVxu
IiwNCj4+ICsgICAgICAgICAgICAgICAgICAgcGRldi0+ZG9tYWluLCAmcGRldi0+c2JkZiwgaW5k
ZXgpOw0KPj4gKyAgICAgICAgICAgIGNvbnRpbnVlOw0KPj4gKyAgICAgICAgfQ0KPj4gKw0KPj4g
KyAgICAgICAgcmMgPSB2cGNpX2FkZF9yZWdpc3RlcihwZGV2LT52cGNpLCB2cGNpX2h3X3JlYWQz
MiwgdnBjaV9od193cml0ZTMyLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBy
ZWJhcl9vZmZzZXQgKyBQQ0lfUkVCQVJfQ0FQKGkpLCA0LCBOVUxMKTsNCj4+ICsgICAgICAgIGlm
ICggcmMgKQ0KPj4gKyAgICAgICAgew0KPj4gKyAgICAgICAgICAgIC8qDQo+PiArICAgICAgICAg
ICAgICogVE9ETzogZm9yIGZhaWxlZCBwYXRoZXMsIG5lZWQgdG8gaGlkZSBSZUJhciBjYXBhYmls
aXR5DQo+PiArICAgICAgICAgICAgICogZnJvbSBoYXJkd2FyZSBkb21haW4gaW5zdGVhZCBvZiBy
ZXR1cm5pbmcgYW4gZXJyb3IuDQo+PiArICAgICAgICAgICAgICovDQo+PiArICAgICAgICAgICAg
cHJpbnRrKFhFTkxPR19FUlIgIiVwZCAlcHA6IGZhaWwgdG8gYWRkIHJlZyBvZiBSRUJBUl9DQVAg
cmM9JWRcbiIsDQo+PiArICAgICAgICAgICAgICAgICAgIHBkZXYtPmRvbWFpbiwgJnBkZXYtPnNi
ZGYsIHJjKTsNCj4+ICsgICAgICAgICAgICByZXR1cm4gcmM7DQo+PiArICAgICAgICB9DQo+PiAr
DQo+PiArICAgICAgICByYyA9IHZwY2lfYWRkX3JlZ2lzdGVyKHBkZXYtPnZwY2ksIHZwY2lfaHdf
cmVhZDMyLCByZWJhcl9jdHJsX3dyaXRlLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICByZWJhcl9vZmZzZXQgKyBQQ0lfUkVCQVJfQ1RSTChpKSwgNCwgYmFyKTsNCj4+ICsgICAg
ICAgIGlmICggcmMgKQ0KPj4gKyAgICAgICAgew0KPj4gKyAgICAgICAgICAgIHByaW50ayhYRU5M
T0dfRVJSICIlcGQgJXBwOiBmYWlsIHRvIGFkZCByZWcgb2YgUkVCQVJfQ1RSTCByYz0lZFxuIiwN
Cj4+ICsgICAgICAgICAgICAgICAgICAgcGRldi0+ZG9tYWluLCAmcGRldi0+c2JkZiwgcmMpOw0K
Pj4gKyAgICAgICAgICAgIHJldHVybiByYzsNCj4gDQo+IEkgdGhpbmsgd2Ugc2FpZCB3ZSB3YW50
ZWQgdG8gYXR0ZW1wdCB0byBjb250aW51ZSBoZXJlLCByYXRoZXIgdGhhbg0KPiByZXR1cm5pbmcg
YW4gZXJyb3IgYW5kIHRodXMgcmVtb3ZpbmcgYWxsIHZQQ0kgaGFuZGxlcnMgZnJvbSB0aGUNCj4g
ZGV2aWNlPw0KSSB0aG91Z2h0IHRoZSByZXN1bHQgb2YgeW91ciBkaXNjdXNzaW9uIHdpdGggSmFu
IHdhcyB0aGF0IEkgb25seSBuZWVkZWQgdG8gY2hhbmdlIHRoZSBhYm92ZSB0d28gZXJyb3IgcGF0
aHMgdG8gYmUgImNvbnRpbnVlIi4NCklmIHRoZXNlIHR3byBhbHNvIG5lZWQgdG8gYmUgY2hhbmdl
ZCwgSSB3aWxsIG1vZGlmeSB0aGVtIGluIHRoZSBuZXh0IHZlcnNpb24uDQoNCg0KLS0gDQpCZXN0
IHJlZ2FyZHMsDQpKaXFpYW4gQ2hlbi4NCg==


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 09:29:17 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 09:29:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875198.1285577 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taAZM-0001KT-Gl; Tue, 21 Jan 2025 09:29:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875198.1285577; Tue, 21 Jan 2025 09:29:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taAZM-0001KM-DS; Tue, 21 Jan 2025 09:29:12 +0000
Received: by outflank-mailman (input) for mailman id 875198;
 Tue, 21 Jan 2025 09:29:10 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=jEc5=UN=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1taAZK-0001KG-9l
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 09:29:10 +0000
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com
 [2a00:1450:4864:20::62f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2a79241b-d7da-11ef-a0e4-8be0dac302b0;
 Tue, 21 Jan 2025 10:29:09 +0100 (CET)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-aaf900cc7fbso894483766b.3
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 01:29:08 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab644adb658sm57199666b.134.2025.01.21.01.29.07
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 21 Jan 2025 01:29:07 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2a79241b-d7da-11ef-a0e4-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737451748; x=1738056548; 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=GvJEpUlaCpSa5xrAbtwL2ucNycSaZ8DMf4Zq0g3iUCE=;
        b=bn6abcNGIFrmamYxXvqxSsK2oyqCFO8sdPxCnb5AU1n+Dgh12mNfLMSjOK9i4O5SOm
         QlZYil7zLF056IFTG4Zai4BpZgK0i9OzG0lwToJENemlzAYxyaz+GnYpNN/5Ik6jCLQU
         JIshCyI+lHiKKaDjqcHNyyEaRp9V1h+DP2PJE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737451748; x=1738056548;
        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=GvJEpUlaCpSa5xrAbtwL2ucNycSaZ8DMf4Zq0g3iUCE=;
        b=Hw+Ugm5u8hzSXzY8SLDs+rU9Hnn7BjHDrPmsuiHW3PbQHfUKzbzSTL2JO8iX9wD+N8
         KjEHJY8A+8c9W5r7k9RF4sYR7Sfz0S4z2P5wVc4qwHVZy65E2IQXhhzVo+iDKfBVlytU
         ydsvh2066dUZfn52W83ZYj2luWFSYF0iFvr7GrXv8Ko6NJ3C1gZixKRudlinYnmFAlkc
         RQwvnhqMeAsl42ElHZH0u6+vaKM72M9DXYJPqp6o5dnfJpdyGxPM/llelnQ9GyHPb8UW
         1GSzxz4h1oqGjJ5hUzdcs29HNwD9f89rL+n14JhrN6mpsYRmMQKJ2xEpbQ9YuoBsakhz
         bGBw==
X-Forwarded-Encrypted: i=1; AJvYcCVElCcqYbTIwcRbK+cfop/QrzyeuMo+EH/aUGjiIHp1X99f95DtFtGVWoBiF0cQN+D2vwSm+r+NGqY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxYq8dKeGKd0wtBDRAcJK5M52K7kEW89Nn2O/wdZG/QAN369U1e
	EdfAbvOGrK3sFGgtW8D80+Xv0CWiKRl3twV2VdFQ56T5EfCJJ9BuoDw/AlyFyZ4=
X-Gm-Gg: ASbGncvyDY5CURB1bvPIAaof5OENNjPUaQySqa9CHNbpGsRY44Vw6v54bxGbWqzPWYg
	OD+vTNDgrUprWdf+PkvBnVgP84kpI5QXqDYthicFNGcEUOH18gKdrBtS0Y5ApqZvMhzlTwaegf4
	Slx49C8V004/C3OkrZXq04CLTEFdarGMpRCcPz1RagZXTeO9rHYlou+a5CAa4B8kPp7KS7sFhP8
	DPfOuAxQfm2o+wnbVmxr8YBhCaxpAIvrNexwGbssm+9u8uNGUrpYBD3FcPJTCZwHagVt2zxkwk=
X-Google-Smtp-Source: AGHT+IGswEwVXXzTKLYyvM7Jam5pW0T7DgM5GLV0NMC4GIai2nKx2ULjAk42kPDcqavcwsds+qxWyA==
X-Received: by 2002:a17:907:2d2c:b0:ab2:faed:f180 with SMTP id a640c23a62f3a-ab38b18bf29mr1705692866b.33.1737451748250;
        Tue, 21 Jan 2025 01:29:08 -0800 (PST)
Date: Tue, 21 Jan 2025 10:29:06 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: "Chen, Jiqian" <Jiqian.Chen@amd.com>
Cc: Jan Beulich <jbeulich@suse.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	"Huang, Ray" <Ray.Huang@amd.com>
Subject: Re: [PATCH v5] vpci: Add resizable bar support
Message-ID: <Z49o4iyY7vPhz2ow@macbook.local>
References: <20250114032636.3698383-1-Jiqian.Chen@amd.com>
 <Z49e8NmROzke-tYc@macbook.local>
 <BL1PR12MB58492016DDBB106A607F32CDE7E62@BL1PR12MB5849.namprd12.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <BL1PR12MB58492016DDBB106A607F32CDE7E62@BL1PR12MB5849.namprd12.prod.outlook.com>

On Tue, Jan 21, 2025 at 09:10:26AM +0000, Chen, Jiqian wrote:
> On 2025/1/21 16:46, Roger Pau Monné wrote:
> > On Tue, Jan 14, 2025 at 11:26:36AM +0800, Jiqian Chen wrote:
> >> +    ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL(0));
> >> +    nbars = MASK_EXTR(ctrl, PCI_REBAR_CTRL_NBAR_MASK);
> >> +    for ( unsigned int i = 0; i < nbars; i++ )
> >> +    {
> >> +        int rc;
> >> +        struct vpci_bar *bar;
> >> +        unsigned int index;
> >> +
> >> +        ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL(i));
> >> +        index = ctrl & PCI_REBAR_CTRL_BAR_IDX;
> >> +        if ( index >= PCI_HEADER_NORMAL_NR_BARS )
> >> +        {
> >> +            printk(XENLOG_ERR "%pd %pp: too big BAR number %u in REBAR_CTRL\n",
> >> +                   pdev->domain, &pdev->sbdf, index);
> >> +            continue;
> >> +        }
> >> +
> >> +        bar = &pdev->vpci->header.bars[index];
> >> +        if ( bar->type != VPCI_BAR_MEM64_LO && bar->type != VPCI_BAR_MEM32 )
> >> +        {
> >> +            printk(XENLOG_ERR "%pd %pp: BAR%u is not in memory space\n",
> >> +                   pdev->domain, &pdev->sbdf, index);
> >> +            continue;
> >> +        }
> >> +
> >> +        rc = vpci_add_register(pdev->vpci, vpci_hw_read32, vpci_hw_write32,
> >> +                               rebar_offset + PCI_REBAR_CAP(i), 4, NULL);
> >> +        if ( rc )
> >> +        {
> >> +            /*
> >> +             * TODO: for failed pathes, need to hide ReBar capability
> >> +             * from hardware domain instead of returning an error.
> >> +             */
> >> +            printk(XENLOG_ERR "%pd %pp: fail to add reg of REBAR_CAP rc=%d\n",
> >> +                   pdev->domain, &pdev->sbdf, rc);
> >> +            return rc;
> >> +        }
> >> +
> >> +        rc = vpci_add_register(pdev->vpci, vpci_hw_read32, rebar_ctrl_write,
> >> +                               rebar_offset + PCI_REBAR_CTRL(i), 4, bar);
> >> +        if ( rc )
> >> +        {
> >> +            printk(XENLOG_ERR "%pd %pp: fail to add reg of REBAR_CTRL rc=%d\n",
> >> +                   pdev->domain, &pdev->sbdf, rc);
> >> +            return rc;
> > 
> > I think we said we wanted to attempt to continue here, rather than
> > returning an error and thus removing all vPCI handlers from the
> > device?
> I thought the result of your discussion with Jan was that I only needed to change the above two error paths to be "continue".
> If these two also need to be changed, I will modify them in the next version.

Hm, let's wait for Jan to confirm, but even if handler cannot be setup
for some of the registers, it's better than just allowing dom0
unmediated access to the capability.

None of this is ideal, but it seems to be the option that gives dom0
most options to successfully boot.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 09:57:23 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 09:57:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875232.1285670 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taB0Y-0006SS-Ix; Tue, 21 Jan 2025 09:57:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875232.1285670; Tue, 21 Jan 2025 09:57:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taB0Y-0006SL-Fk; Tue, 21 Jan 2025 09:57:18 +0000
Received: by outflank-mailman (input) for mailman id 875232;
 Tue, 21 Jan 2025 09:57: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
 <SRS0=jEc5=UN=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1taB0X-0006SF-Dw
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 09:57:17 +0000
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
 [2a00:1450:4864:20::531])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 178893a7-d7de-11ef-99a4-01e77a169b0f;
 Tue, 21 Jan 2025 10:57:15 +0100 (CET)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-5d9f0a6ad83so1864995a12.2
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 01:57:15 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab384f22fdesm720781366b.89.2025.01.21.01.57.13
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 21 Jan 2025 01:57:13 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 178893a7-d7de-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737453434; x=1738058234; 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=JLq/1/TKHChK/00HofyD4lzzmkRQv59j49Ig1IX6vnk=;
        b=YVFOIFuwVGaipQYwxCU/9Svap/edFFUqCrvJeOUe4XWd3GjqzT5yOwlxKg5lnpNZWA
         bGw54ElSIWCJNDuUWBfwL2cvJdLLtj99o7Y2TH8dVpIXTMrGooh21oGTHXu+lNH4bueU
         0SSrsaci13APlPdI80rSz7K9Ya81o40T18kX4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737453434; x=1738058234;
        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=JLq/1/TKHChK/00HofyD4lzzmkRQv59j49Ig1IX6vnk=;
        b=fBh3d1dD0H9Z8owQVHTfLVvz3Gus4/tvIV7wB2+7TzjJ9c07EaNqdxNLeyEOBN9eyQ
         1UdPvHmteuEtF1WWrKgV4TzyqPyjzxe3U/sMYzxAhzrHQBViw/H1gYRinpczZ4Q8v5+C
         4O5wlgH7wbqbCJzqpOE7f7M+qlKLO6hdL3ORbn9RyQBXmbu7Ifo4Iy+EnbFeN/eRmLt2
         oqHx9xnWcwWyb+GY3a6C3I0VjtjurxrWnzxgE+HRnJ+mA/e2IT/sJacNFRWRm0gd/Oa7
         mJZuQEXONrXNEyZjIDNlsEzqbvguTfyncsbM/AXUw1VwsLdWZsssKUM9kQUpKb0uPn44
         2M0A==
X-Gm-Message-State: AOJu0YzTc7b5ulfEiVs80zZ674cSaP8atoT7lv1y4A+gFH78Mq/4JdX1
	D1kSiXhkSqwW5VqVr4wHL4dqZOtK+egY734stG2HN0c/Rdo7Ki90WYS6QpP3oGBQY441X4pQtvm
	s
X-Gm-Gg: ASbGncv2tBWsr4n+1WTWlJaQRnSFw/Tp0QIlYyfIVwlNldzhx49u0j1el0mAwiIjXo0
	33rarxpadBpaHdKxB0D/bNUhqbHetAVGArd3H7d3t6jf8wAj6soHQHDluWA/sE+sFfVWqkKjG6m
	TjI89dg3sJUDfP7VHY0e02BlImgSwuKSk1ugptBaVSpmCtYR1zNuVv4QizJJAMEeKXIOxTfqBmY
	+J+Ro3hdh8TIBSraAyIZNeu7VXRnnMcSlmzOjG1fbXkGMafjMq4bQ0cCuIGYyVnmPEu00GFTILD
	aEUJ
X-Google-Smtp-Source: AGHT+IHcgiXHgAMe1LbUuoPDB4nCxqK3qTBmqrJxS+RM4BGJBFhOGNBA4zgJ516v7Bn7w3Sa93pYxQ==
X-Received: by 2002:a17:906:dc8c:b0:ab2:f937:b3aa with SMTP id a640c23a62f3a-ab38b4cff42mr1545982566b.56.1737453434167;
        Tue, 21 Jan 2025 01:57:14 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: [PATCH] iommu/amd: atomically update IRTE if supported
Date: Tue, 21 Jan 2025 10:57:04 +0100
Message-ID: <20250121095704.18769-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

If using a 32bit Interrupt Remapping Entry or a 128bit one and the CPU
supports 128bit cmpxchg don't disable the entry by setting RemapEn = 0
ahead of updating it.  As a consequence of not toggling RemapEn ahead of
the update the Interrupt Remapping Table needs to be flushed after the
entry update.

This avoids a window where the IRTE has RemapEn = 0, which can lead to
IO_PAGE_FAULT if the underlying interrupt source is not masked.

There's no guidance in AMD-Vi specification about how IRTE update should be
performed as opposed to DTE updating which has specific guidance.  However
DTE updating claims that reads will always be at least 128bits in size, and
hence for the purposes here assume that reads and caching of the IRTE
entries in either 32 or 128 bit format will be done atomically from
the IOMMU.

Note that as part of introducing a new raw128 field in the IRTE struct, the
current raw field is renamed to raw64 to explicitly contain the size in the
field name.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/drivers/passthrough/amd/iommu_intr.c | 68 ++++++++++++++++++------
 1 file changed, 53 insertions(+), 15 deletions(-)

diff --git a/xen/drivers/passthrough/amd/iommu_intr.c b/xen/drivers/passthrough/amd/iommu_intr.c
index 7fc796dec25b..efa9ddc62458 100644
--- a/xen/drivers/passthrough/amd/iommu_intr.c
+++ b/xen/drivers/passthrough/amd/iommu_intr.c
@@ -39,7 +39,8 @@ union irte32 {
 };
 
 union irte128 {
-    uint64_t raw[2];
+    uint64_t raw64[2];
+    __uint128_t raw128;
     struct {
         bool remap_en:1;
         bool sup_io_pf:1;
@@ -187,7 +188,7 @@ static void free_intremap_entry(const struct amd_iommu *iommu,
 
     if ( iommu->ctrl.ga_en )
     {
-        ACCESS_ONCE(entry.ptr128->raw[0]) = 0;
+        ACCESS_ONCE(entry.ptr128->raw64[0]) = 0;
         /*
          * Low half (containing RemapEn) needs to be cleared first.  Note that
          * strictly speaking smp_wmb() isn't enough, as conceptually it expands
@@ -197,7 +198,7 @@ static void free_intremap_entry(const struct amd_iommu *iommu,
          * variant will do.
          */
         smp_wmb();
-        entry.ptr128->raw[1] = 0;
+        entry.ptr128->raw64[1] = 0;
     }
     else
         ACCESS_ONCE(entry.ptr32->raw) = 0;
@@ -223,14 +224,36 @@ static void update_intremap_entry(const struct amd_iommu *iommu,
             },
         };
 
-        ASSERT(!entry.ptr128->full.remap_en);
-        entry.ptr128->raw[1] = irte.raw[1];
-        /*
-         * High half needs to be set before low one (containing RemapEn).  See
-         * comment in free_intremap_entry() regarding the choice of barrier.
-         */
-        smp_wmb();
-        ACCESS_ONCE(entry.ptr128->raw[0]) = irte.raw[0];
+        if ( cpu_has_cx16 )
+        {
+            __uint128_t old = entry.ptr128->raw128;
+            __uint128_t res = cmpxchg16b(&entry.ptr128->raw128, &old,
+                                         &irte.raw128);
+
+            /*
+             * Hardware does not update the IRTE behind our backs, so the
+             * return value should match "old".
+             */
+            if ( res != old )
+            {
+                printk(XENLOG_ERR
+                       "unexpected IRTE %016lx_%016lx (expected %016lx_%016lx)\n",
+                       (uint64_t)(res >> 64), (uint64_t)res,
+                       (uint64_t)(old >> 64), (uint64_t)old);
+                BUG();
+            }
+        }
+        else
+        {
+            ASSERT(!entry.ptr128->full.remap_en);
+            entry.ptr128->raw64[1] = irte.raw64[1];
+            /*
+             * High half needs to be set before low one (containing RemapEn).  See
+             * comment in free_intremap_entry() regarding the choice of barrier.
+             */
+            smp_wmb();
+            ACCESS_ONCE(entry.ptr128->raw64[0]) = irte.raw64[0];
+        }
     }
     else
     {
@@ -300,7 +323,8 @@ static int update_intremap_entry_from_ioapic(
     entry = get_intremap_entry(iommu, req_id, offset);
 
     /* The RemapEn fields match for all formats. */
-    while ( iommu->enabled && entry.ptr32->flds.remap_en )
+    while ( iommu->enabled && entry.ptr32->flds.remap_en &&
+            iommu->ctrl.ga_en && !cpu_has_cx16 )
     {
         entry.ptr32->flds.remap_en = false;
         spin_unlock(lock);
@@ -314,6 +338,9 @@ static int update_intremap_entry_from_ioapic(
 
     spin_unlock_irqrestore(lock, flags);
 
+    if ( iommu->enabled && !fresh && (!iommu->ctrl.ga_en || cpu_has_cx16) )
+        amd_iommu_flush_intremap(iommu, req_id);
+
     set_rte_index(rte, offset);
 
     return 0;
@@ -425,6 +452,7 @@ static int update_intremap_entry_from_msi_msg(
     uint8_t delivery_mode, vector, dest_mode;
     spinlock_t *lock;
     unsigned int dest, offset, i;
+    bool fresh = false;
 
     req_id = get_dma_requestor_id(iommu->seg, bdf);
     alias_id = get_intremap_requestor_id(iommu->seg, bdf);
@@ -468,12 +496,14 @@ static int update_intremap_entry_from_msi_msg(
             return -ENOSPC;
         }
         *remap_index = offset;
+        fresh = true;
     }
 
     entry = get_intremap_entry(iommu, req_id, offset);
 
     /* The RemapEn fields match for all formats. */
-    while ( iommu->enabled && entry.ptr32->flds.remap_en )
+    while ( iommu->enabled && entry.ptr32->flds.remap_en &&
+            iommu->ctrl.ga_en && !cpu_has_cx16 )
     {
         entry.ptr32->flds.remap_en = false;
         spin_unlock(lock);
@@ -488,6 +518,13 @@ static int update_intremap_entry_from_msi_msg(
     update_intremap_entry(iommu, entry, vector, delivery_mode, dest_mode, dest);
     spin_unlock_irqrestore(lock, flags);
 
+    if ( iommu->enabled && !fresh && (!iommu->ctrl.ga_en || cpu_has_cx16) )
+    {
+        amd_iommu_flush_intremap(iommu, req_id);
+        if ( alias_id != req_id )
+            amd_iommu_flush_intremap(iommu, alias_id);
+    }
+
     *data = (msg->data & ~(INTREMAP_MAX_ENTRIES - 1)) | offset;
 
     /*
@@ -722,7 +759,7 @@ static void dump_intremap_table(const struct amd_iommu *iommu,
     for ( count = 0; count < nr; count++ )
     {
         if ( iommu->ctrl.ga_en
-             ? !tbl.ptr128[count].raw[0] && !tbl.ptr128[count].raw[1]
+             ? !tbl.ptr128[count].raw64[0] && !tbl.ptr128[count].raw64[1]
              : !tbl.ptr32[count].raw )
                 continue;
 
@@ -735,7 +772,8 @@ static void dump_intremap_table(const struct amd_iommu *iommu,
 
         if ( iommu->ctrl.ga_en )
             printk("    IRTE[%03x] %016lx_%016lx\n",
-                   count, tbl.ptr128[count].raw[1], tbl.ptr128[count].raw[0]);
+                   count, tbl.ptr128[count].raw64[1],
+                   tbl.ptr128[count].raw64[0]);
         else
             printk("    IRTE[%03x] %08x\n", count, tbl.ptr32[count].raw);
     }
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 21 10:13:27 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 10:13:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875242.1285681 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taBFr-00019d-Rj; Tue, 21 Jan 2025 10:13:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875242.1285681; Tue, 21 Jan 2025 10:13:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taBFr-00019W-Ol; Tue, 21 Jan 2025 10:13:07 +0000
Received: by outflank-mailman (input) for mailman id 875242;
 Tue, 21 Jan 2025 10:13:07 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=qQWO=UN=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1taBFr-00019Q-1D
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 10:13:07 +0000
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com
 [2a00:1450:4864:20::32a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4d9175ae-d7e0-11ef-a0e4-8be0dac302b0;
 Tue, 21 Jan 2025 11:13:04 +0100 (CET)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-4361f664af5so62395325e9.1
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 02:13:04 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438904625e5sm174706295e9.32.2025.01.21.02.13.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 21 Jan 2025 02:13:03 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 4d9175ae-d7e0-11ef-a0e4-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737454384; x=1738059184; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=w7PL6jtDuqaCI47/vBihS/1cwVtVGWcN0cpHdQWY7CM=;
        b=QEiS9Rn4CeBp3Qb8zPmWxObOjZEZIZfQ41RmTb3SONE2ZE+5x5eATPcuUHsxlsTXhD
         X50qNn3ixMcbdIsGbrqY/sHcBubeuOhMng6SkA8q9yquhDtB4TF9+AMRD3s+x7E2l8Ic
         edpAbmz+os4FCyzJl4NDrKbGjJkyn67QdMh7Q=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737454384; x=1738059184;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=w7PL6jtDuqaCI47/vBihS/1cwVtVGWcN0cpHdQWY7CM=;
        b=OWo6IKWIUhMu2P6i50t1JJh/xnnSjpcAC8Oavxe7GNElkqrhUmqZ4Oz1dsH7AE+jZ7
         UM2jxJjMgaR5gyxorPIpIB7C/Tw/Ej3jO71ISIJVQ4eS/zxDN0/alWB0BCLONn7YD4Pe
         DXfgET9DD/kJLjjIz4/daJdmHJlTXh/aN82tfpRIVHZE0OmIDnxeIPEyKfn2eALumeDG
         Xr21qpQhIMhVtCe5m005JE0ILLE5518YCW+MeeuCj0AMZ+tNLXJmeWmEAuver56KAX/Y
         YCmKpCK/0pHBtBEFN/64fQM4yPgFZ3PLve4ClqtHECNhggx0O5bNR5v9EsHHJhiuMdQi
         REMQ==
X-Forwarded-Encrypted: i=1; AJvYcCXM3969ePUKkqvmpfn/P9pkB3gdcHj1RzunGJh9my1hu70pKATcst5Er//vpEW1l8AXWbw7DoZ0/uc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwADqI5gMWxCcyHNsc3uftvFiHkeRYuyXRdy6L2JTLWYhV5jZL8
	nHEbb/zgxFnmG2Y2Rig/6hTkzfGHt3Kf9ilIES5XbFiWAL3HlL4y1lgRXvf0WOI=
X-Gm-Gg: ASbGncsvtNH1y/WlgCFsxEtEDD/MiX21rji3gfOQn5gMGQafmOGL+xW3+dskrsYF9F/
	GUH3TcFOWWjvu175GRlANykgXSIXCs6+A5XjuZBU3WR3x/W7ZrNwlSfaUtqpEY3SSg/FA1Z9SAN
	8Fmzw2ffOfqRUsbTbdLZSO1yL9tsna27s93FX2kFPvt7hYSO0DjvgV4wKiqwoVzmCHT+16hqXVR
	uD+2bOY+UzfZ3oqNj2vUUqvGh+gF01co5u6QdhsR281hf++Hp+HdRWv4x6hC5soHecJGiC7hikE
	llDPxl0x7ukoEb0nk+pJ2UjW2RihA59t8Q==
X-Google-Smtp-Source: AGHT+IGqgc+G/R8qYlMP6RGudFGP5SKZBDMGlxz7E3VKZrURjhhqXxZSWlXLKqDCUsQZaAj3K5l9uw==
X-Received: by 2002:a05:600c:6c06:b0:436:e8b4:36e7 with SMTP id 5b1f17b1804b1-438913cb191mr145965745e9.8.1737454384103;
        Tue, 21 Jan 2025 02:13:04 -0800 (PST)
Message-ID: <a1a43ab4-5028-4fe4-8e08-5ebd92220436@citrix.com>
Date: Tue, 21 Jan 2025 10:13:03 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] iommu/amd: atomically update IRTE if supported
To: Roger Pau Monne <roger.pau@citrix.com>, xen-devel@lists.xenproject.org
Cc: Jan Beulich <jbeulich@suse.com>
References: <20250121095704.18769-1-roger.pau@citrix.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <20250121095704.18769-1-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 21/01/2025 9:57 am, Roger Pau Monne wrote:
> diff --git a/xen/drivers/passthrough/amd/iommu_intr.c b/xen/drivers/passthrough/amd/iommu_intr.c
> index 7fc796dec25b..efa9ddc62458 100644
> --- a/xen/drivers/passthrough/amd/iommu_intr.c
> +++ b/xen/drivers/passthrough/amd/iommu_intr.c
> @@ -223,14 +224,36 @@ static void update_intremap_entry(const struct amd_iommu *iommu,
>              },
>          };
>  
> -        ASSERT(!entry.ptr128->full.remap_en);
> -        entry.ptr128->raw[1] = irte.raw[1];
> -        /*
> -         * High half needs to be set before low one (containing RemapEn).  See
> -         * comment in free_intremap_entry() regarding the choice of barrier.
> -         */
> -        smp_wmb();
> -        ACCESS_ONCE(entry.ptr128->raw[0]) = irte.raw[0];
> +        if ( cpu_has_cx16 )

cx16 is always available.  Teddy even submitted patches, but it looks
like they succumbed.

We need to take Teddy's patches, then ~half this one.

As proved by this patch alone, it's already hard enough getting this
right, without introducing dead logic paths into the mix.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 10:14:11 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 10:14:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875251.1285691 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taBGt-0001f7-4N; Tue, 21 Jan 2025 10:14:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875251.1285691; Tue, 21 Jan 2025 10:14:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taBGt-0001f0-1p; Tue, 21 Jan 2025 10:14:11 +0000
Received: by outflank-mailman (input) for mailman id 875251;
 Tue, 21 Jan 2025 10:14:10 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=abyW=UN=cloud.com=ross.lagerwall@srs-se1.protection.inumbo.net>)
 id 1taBGs-00019Q-21
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 10:14:10 +0000
Received: from mail-oa1-x31.google.com (mail-oa1-x31.google.com
 [2001:4860:4864:20::31])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 73cd04df-d7e0-11ef-a0e4-8be0dac302b0;
 Tue, 21 Jan 2025 11:14:09 +0100 (CET)
Received: by mail-oa1-x31.google.com with SMTP id
 586e51a60fabf-2a8690dcb35so1790274fac.3
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 02:14:09 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 73cd04df-d7e0-11ef-a0e4-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737454448; x=1738059248; 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=vrwCgFpGhvioWbjjmWesN6tqEnMoFZb0MgDSm3GqrOw=;
        b=gXU06Q5g3CVJL9sDbJPgpqJ8L/SRWQOwZleHiR6eykYr8/tCirV41hjHnb3esInHr/
         iObuWfqqwVSIY5Us3spZwBDl/XCw/v9B30Bm2dZTtbJM1Y9uoeJcA0E3TiazbVPZ+b1G
         ZqkyBMMIcTQospWXKu1Sl7RHsMmokK58pOtpA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737454448; x=1738059248;
        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=vrwCgFpGhvioWbjjmWesN6tqEnMoFZb0MgDSm3GqrOw=;
        b=TTW1kR55SpKLKucnzR7YFzjzmnj0CZ8WA5M9Uwz6Nj3Haw9GcXsNOytZxdmODJyVZ2
         mXo5/kVe78O0+9f7Dd6YiapaX/6mrKuAgXELoHXpT8HYGYAlAEPgojVwZTOfhIcKB5Su
         2yPx61DXMRUeBUzj5hhCy7wEljIzm8TrmRBIOuM82Qb7kVsaLmleobH0lJa8BVHLRh/q
         kgaMckqwNjE62lBrlD8AnZjjo2hYBLCR/fG18RcS9MhD/lsP+6G7knwJM+UcxZemiLSq
         epo7YcdM98q/av1bkGuph0hw9NqF+KPTHhbVDcWejlXGZFKOdGphKObroQBm5xcJtpn5
         xY4g==
X-Gm-Message-State: AOJu0YzcgUOUPBjEVB4PXLztc2qZFa7P1E39pssFF637HeEv+/kFmF+h
	LIaAMt4/RhzUgK11U/ifj9WVXlfvLw7Gw/YUZNWc29YO4n5UzZAW+hzPlM96Dlp43v0tBEgQm5v
	Wbf5GT1oo+nkxV866S5Ffq9nwMu8VoV3oAIUJ
X-Gm-Gg: ASbGncvX0zt/L8vCgJFYjpVqA0JvutixFpyHeqY8BIpAC/VchqT7bq72Z6bGMV4NNEB
	3KkWVgeL+OYnPG15Wq79TY4OhNt/Vu40/mQhBEejNUxS2ZHaY7A==
X-Google-Smtp-Source: AGHT+IGI3+dV2kc5H5TBxUN/oFa5UzTmoLuTgpUYKclPHbvqgj3pdBRh/G5gqwka4Q1OMeC7xlmviwpc9QfrMnFiGaQ=
X-Received: by 2002:a05:6870:4f0b:b0:29e:7dd8:92b1 with SMTP id
 586e51a60fabf-2b1c0c01e40mr8642567fac.24.1737454448172; Tue, 21 Jan 2025
 02:14:08 -0800 (PST)
MIME-Version: 1.0
References: <20250116175214.83742-1-roger.pau@citrix.com>
In-Reply-To: <20250116175214.83742-1-roger.pau@citrix.com>
From: Ross Lagerwall <ross.lagerwall@citrix.com>
Date: Tue, 21 Jan 2025 10:13:56 +0000
X-Gm-Features: AbW1kvb9nfCQoAe19QxR8uhgZBe2FEwWEaoeQD6hc-nUmn819CVSrekFHO2fJew
Message-ID: <CAG7k0EqE2HrZabEqA741cDT+nMGttwGZ2jssLLwOzxp+ZYE85w@mail.gmail.com>
Subject: Re: [PATCH 0/7] livepatch-build-tools: fixes for handling .cold and
 .hot sections
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: xen-devel@lists.xenproject.org, konrad.wilk@oracle.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 16, 2025 at 5:52=E2=80=AFPM Roger Pau Monne <roger.pau@citrix.c=
om> wrote:
>
> Hello,
>
> Fixes picked from kpatch to deal with .cold and .hot sub-functions
> sections generated by gcc.
>
> Thanks, Roger.
>
> Artem Savkov (7):
>   create-diff-object: ignore .cold.* suffixes in is_bundleable()
>   create-diff-object: add symbol relations
>   create-diff-object: propagate child symbol changes
>   create-diff-object: allow changing subsections
>   create-diff-object: add .text.hot to the list of bundleable functions
>   create-diff-object: propagate ignore.functions to children
>   create-build-diff: support for .cold functions with no id suffix
>

For all patches,

Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>

Thanks


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 10:17:58 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 10:17:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875258.1285701 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taBKN-0002F2-Ju; Tue, 21 Jan 2025 10:17:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875258.1285701; Tue, 21 Jan 2025 10:17:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taBKN-0002Ev-H3; Tue, 21 Jan 2025 10:17:47 +0000
Received: by outflank-mailman (input) for mailman id 875258;
 Tue, 21 Jan 2025 10:17:46 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=fb3U=UN=darkstar.site=sakib@srs-se1.protection.inumbo.net>)
 id 1taBKM-0002Ep-C9
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 10:17:46 +0000
Received: from fforwardh-b2-smtp.messagingengine.com
 (fforwardh-b2-smtp.messagingengine.com [202.12.124.197])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f3799fb8-d7e0-11ef-99a4-01e77a169b0f;
 Tue, 21 Jan 2025 11:17:43 +0100 (CET)
Received: from phl-compute-06.internal (phl-compute-06.phl.internal
 [10.202.2.46])
 by mailfforwardh.stl.internal (Postfix) with ESMTP id E1FE21740127;
 Tue, 21 Jan 2025 05:17:41 -0500 (EST)
Received: from phl-frontend-02 ([10.202.2.161])
 by phl-compute-06.internal (MEProxy); Tue, 21 Jan 2025 05:17:42 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 21 Jan 2025 05:17:39 -0500 (EST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f3799fb8-d7e0-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:date:date:feedback-id:feedback-id:from:from
	:in-reply-to:message-id:mime-version:reply-to:subject:subject:to
	:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=
	1737454661; x=1737541061; bh=OBw60GEEhVQWibPY0f38eIS0+A3cujIKzzL
	MMlGQtkI=; b=U0M5Y1WW1639D8DhQqTaOGPUFzQizqxKkqpp18ak0sfXgsWImAx
	UoHNZgny8E5SAUr+v+FSs1IoMWAF4SrJvLkJX1ugvWMLD0SmAM7Y0DvCOIqtW5Po
	pwIM3QcJFT67rLJTR/QvRnytGJ4xwlWEpl20EnpKWiyigXc2UJ1Vn4fQax/knrJe
	o8sxOGgFN4efRHZ7XfoY+TwIX6cO9YRdQS+6e465ydXUmEXw5A+VZS2agaOe6BJQ
	Q7Pa9j82mt/vaLx6dX+2A6vBBXDAy75NfKNu987zXWh5a0fuOw78ZnLKgZR92JTj
	GtjeCs63vN9YJdcKuJm/zPTitIJZLfU1tyw==
X-ME-Sender: <xms:RHSPZ2hmbNtoj0wKMHCvGzXogxRZqHGmatrdKzJJnIz6jqk6Uk9dQw>
    <xme:RHSPZ3Am_7AbC_2afDjJShvj0CeQmoR-EEZIyC8DzaqCw36k647t-xPsMIANsyMMj
    TjpW-l7cdGNA18la3I>
X-ME-Received: <xmr:RHSPZ-FVzB9Bh2PtHEZ-SMSilufk_8tBGE9v-FKoRGvPw6HOcusykx-c6TraKywgnfIiVwdQwhk37r2KfrF6jCUI4FY-tQacfs8XUnmEzuyzMOJg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrudejuddgudefucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
    rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
    htshculddquddttddmnecujfgurhephffvvefufffkofgggfestdekredtredttdenucfh
    rhhomhepufgvrhhgihihucfmihgsrhhikhcuoefuvghrghhihigpmfhisghrihhksegvph
    grmhdrtghomheqnecuggftrfgrthhtvghrnhepgedvfeefhfduvdetkeegleeggfelheek
    veeiuddufeehtdehleelhfekiedvvedvnecuffhomhgrihhnpehkvghrnhgvlhdrohhrgh
    enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehsrghk
    ihgssegurghrkhhsthgrrhdrshhithgvpdhnsggprhgtphhtthhopedvvddpmhhouggvpe
    hsmhhtphhouhhtpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhp
    rhhojhgvtghtrdhorhhgpdhrtghpthhtohepshgvrhhgihihpghkihgsrhhikhesvghprg
    hmrdgtohhmpdhrtghpthhtohepjhhulhhivghnseigvghnrdhorhhgpdhrtghpthhtohep
    sggvrhhtrhgrnhgurdhmrghrqhhuihhssegrrhhmrdgtohhmpdhrtghpthhtohepmhhitg
    hhrghlrdhorhiivghlsegrmhgurdgtohhmpdhrtghpthhtohepvhholhhougihmhihrhgp
    sggrsggthhhukhesvghprghmrdgtohhmpdhrtghpthhtoheprghnughrvgifrdgtohhoph
    gvrhefsegtihhtrhhigidrtghomhdprhgtphhtthhopegrnhhthhhonhihrdhpvghrrghr
    ugesvhgrthgvshdrthgvtghhpdhrtghpthhtohepjhgsvghulhhitghhsehsuhhsvgdrtg
    homh
X-ME-Proxy: <xmx:RHSPZ_QieK1_Xks3ahqP2RuG3y-uIOyQImNZ7cjeBmi5WF54U8VncQ>
    <xmx:RHSPZzzewdg1B7SVA5FzYF9ZasFPPAACQ_7HrBmOCG15KiaRgviY5g>
    <xmx:RHSPZ94jbOA-cMHLhipmmsT-8MBv4GmQrmt_y1XtG_E_6Q3nT6t0rA>
    <xmx:RHSPZwxLir330FpAOuRQtZU8OuwpKad6wUSVLwXT8s0InGr_HYg2uQ>
    <xmx:RHSPZ_iID5Or8hlS37cBQ79ppiF5Tp42VB9RFiWg9s6SYqbyx4H7Dg>
    <xmx:RXSPZxpDWjrCQsiaEa9gB3bqD8nN-XVf_U3BVzfDa1fWELBuqlwSdHBKbNtW>
Feedback-ID: if7fb09ee:Fastmail
From: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
To: xen-devel@lists.xenproject.org
Cc: Sergiy Kibrik <Sergiy_Kibrik@epam.com>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Tamas K Lengyel <tamas@tklengyel.com>,
	Alexandru Isaila <aisaila@bitdefender.com>,
	Petre Pircalabu <ppircalabu@bitdefender.com>,
	Shawn Anastasio <sanastasio@raptorengineering.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Bob Eshleman <bobbyeshleman@gmail.com>,
	Connor Davis <connojdavis@gmail.com>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Nicola Vetrini <nicola.vetrini@bugseng.com>,
	Doug Goldstein <cardoe@cardoe.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v2 0/4] make build of vm_event/mem_access/monitor optional
Date: Tue, 21 Jan 2025 12:17:36 +0200
Message-Id: <cover.1737452864.git.Sergiy_Kibrik@epam.com>
X-Mailer: git-send-email 2.25.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

This series aims to provide a possibility to build Xen without mem_access and
related features. It is already largely covered by corresponding
CONFIG_MEM_ACCESS option, yet there're still some parts remaining.
Hopefully this would help to reduce dead code a bit.

As coverage of MEM_ACCESS config option begins to extend beyond actual
mem_access code it has been suggested to rename it into VM_EVENT, as a more
general option controlling mem_access, vm_event and monitor code.

v1 patch here:
https://lore.kernel.org/xen-devel/20241230063051.3332332-1-Sergiy_Kibrik@epam.com/

  -Sergiy

Sergiy Kibrik (3):
  xen: kconfig: rename MEM_ACCESS -> VM_EVENT
  x86:monitor: control monitor.c build with CONFIG_VM_EVENT option
  automation: rename CONFIG_MEM_ACCESS -> CONFIG_VM_EVENT

Stefano Stabellini (1):
  xen: mem_access: conditionally compile vm_event.c & monitor.c

 automation/eclair_analysis/xen_arm_config |  2 +-
 automation/eclair_analysis/xen_x86_config |  2 +-
 automation/gitlab-ci/build.yaml           |  2 +-
 xen/arch/arm/Makefile                     |  6 +++---
 xen/arch/arm/configs/tiny64_defconfig     |  2 +-
 xen/arch/arm/include/asm/mem_access.h     |  4 ++--
 xen/arch/arm/vsmc.c                       |  3 ++-
 xen/arch/ppc/configs/ppc64_defconfig      |  2 +-
 xen/arch/riscv/configs/tiny64_defconfig   |  2 +-
 xen/arch/x86/Makefile                     |  2 +-
 xen/arch/x86/mm/Makefile                  |  2 +-
 xen/common/Kconfig                        |  2 +-
 xen/common/Makefile                       |  6 +++---
 xen/common/domctl.c                       |  2 +-
 xen/include/xen/mem_access.h              |  6 +++---
 xen/include/xen/monitor.h                 |  9 +++++++++
 xen/include/xen/vm_event.h                | 14 +++++++++++---
 xen/include/xsm/dummy.h                   |  2 +-
 xen/include/xsm/xsm.h                     |  4 ++--
 xen/xsm/dummy.c                           |  2 +-
 xen/xsm/flask/hooks.c                     |  4 ++--
 21 files changed, 49 insertions(+), 31 deletions(-)

-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Tue Jan 21 10:20:05 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 10:20:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875270.1285710 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taBMN-0002qs-1A; Tue, 21 Jan 2025 10:19:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875270.1285710; Tue, 21 Jan 2025 10:19:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taBMM-0002ql-Uq; Tue, 21 Jan 2025 10:19:50 +0000
Received: by outflank-mailman (input) for mailman id 875270;
 Tue, 21 Jan 2025 10:19:49 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=fb3U=UN=darkstar.site=sakib@srs-se1.protection.inumbo.net>)
 id 1taBML-0002qf-CL
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 10:19:49 +0000
Received: from fforwardh-b2-smtp.messagingengine.com
 (fforwardh-b2-smtp.messagingengine.com [202.12.124.197])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3d40c1e7-d7e1-11ef-99a4-01e77a169b0f;
 Tue, 21 Jan 2025 11:19:47 +0100 (CET)
Received: from phl-compute-01.internal (phl-compute-01.phl.internal
 [10.202.2.41])
 by mailfforwardh.stl.internal (Postfix) with ESMTP id E43551740226;
 Tue, 21 Jan 2025 05:19:45 -0500 (EST)
Received: from phl-frontend-01 ([10.202.2.160])
 by phl-compute-01.internal (MEProxy); Tue, 21 Jan 2025 05:19:46 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 21 Jan 2025 05:19:44 -0500 (EST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 3d40c1e7-d7e1-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:date:date:feedback-id:feedback-id:from:from
	:in-reply-to:in-reply-to:message-id:mime-version:references
	:reply-to:subject:subject:to:to:x-me-proxy:x-me-sender
	:x-me-sender:x-sasl-enc; s=fm3; t=1737454785; x=1737541185; bh=3
	rPlU7XgPSyjTpGplKIP+1gNXPsjweB81ibCUw3TTuA=; b=nOTTj2fPwaKSHI3NN
	jyo1C4Y8K9M1QGijqFkSRJG1bmYK1S6nd6XTbczIc5LYj55XWKP3SbN0G/78EvDM
	HiEIeGzCk+fiTTObVGfzv576O48+xJFTX/6mUuDLmUewXqK1+djZqGvVjz9FmrmH
	x8BJH8g9u93q60ZnMjQ8pNyhHHvCSDBCP4zzDbz8+AwKmDlOq7hUKUPmRIF+n3qd
	WKL9T/IdIX2WVyYO9yPRJSdgVHxea8gaXQGL4HQC+Cl8IKWh+7ODmIIHQDto/Sho
	euOFfyXQsh5OGEqONNRUwWFmE6KAMU58gZ5HzGqfp2QxthxODwJOeU89c74mXm4Q
	wwHEg==
X-ME-Sender: <xms:wXSPZ8zjqTmAaFqn8tRDUshya5iQp8aP_vTO3E2EqFiIiucNIq_mcg>
    <xme:wXSPZwRiBWAm6bz_VYfwEKDNghiHifaqmAtP3-7aHDJHbbsld6qYbeFVqznmv0lFU
    1k4hRX0VRRdGl8hxrU>
X-ME-Received: <xmr:wXSPZ-WraoPmDdttLo2BdGyok8F7Pvgik05ly77yyIvBItJ38pkafoao4v62DmCvRu29nWNvwvS38uwXqBdKW-4wfasU2WHNPUr46E6yu_IU9-tt>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrudejuddgudegucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
    rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
    htshculddquddttddmnecujfgurhephffvvefufffkofgjfhgggfestdekredtredttden
    ucfhrhhomhepufgvrhhgihihucfmihgsrhhikhcuoefuvghrghhihigpmfhisghrihhkse
    gvphgrmhdrtghomheqnecuggftrfgrthhtvghrnhepfeejheefveekheeguedvhfeuudei
    hfegieeifefglefhveeihfduuddvkeegjefhnecuffhomhgrihhnpehkvghrnhgvlhdroh
    hrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehs
    rghkihgssegurghrkhhsthgrrhdrshhithgvpdhnsggprhgtphhtthhopedvtddpmhhoug
    gvpehsmhhtphhouhhtpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigv
    nhhprhhojhgvtghtrdhorhhgpdhrtghpthhtohepshgvrhhgihihpghkihgsrhhikhesvg
    hprghmrdgtohhmpdhrtghpthhtohepjhhulhhivghnseigvghnrdhorhhgpdhrtghpthht
    ohepsggvrhhtrhgrnhgurdhmrghrqhhuihhssegrrhhmrdgtohhmpdhrtghpthhtohepmh
    hitghhrghlrdhorhiivghlsegrmhgurdgtohhmpdhrtghpthhtohepvhholhhougihmhih
    rhgpsggrsggthhhukhesvghprghmrdgtohhmpdhrtghpthhtoheprghnughrvgifrdgtoh
    hophgvrhefsegtihhtrhhigidrtghomhdprhgtphhtthhopegrnhhthhhonhihrdhpvghr
    rghrugesvhgrthgvshdrthgvtghhpdhrtghpthhtohepjhgsvghulhhitghhsehsuhhsvg
    drtghomh
X-ME-Proxy: <xmx:wXSPZ6ha2hzu38blgrq-LxhbnF9S1_oTCbtPr5fcKNvfgEkB78XLFw>
    <xmx:wXSPZ-BNj_VtA3GGLkRcoiHefBvzdAm-70h-5LKjDeN2GZEOfGvQvA>
    <xmx:wXSPZ7IEYtkskhbjJ41KL0OmJ2AEsCrGyhbT_rRpNM8fMwutM3tCPA>
    <xmx:wXSPZ1B9qcEVshgrvSlr3DBEOEgny1F6kwZ-pUEuUZDPdIaifySMQw>
    <xmx:wXSPZ-wHMao6NhyLe7zPTqw4_iN8dUrnokK1cqpi9M0MOeAUStUydw>
    <xmx:wXSPZ5XFIdyGWEVEq2hcCiGu2B18anrmnf5l1iaTWJPivTgXv2A59mlI1FNe>
Feedback-ID: i7fe92d45:Fastmail
From: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
To: xen-devel@lists.xenproject.org
Cc: Sergiy Kibrik <Sergiy_Kibrik@epam.com>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Tamas K Lengyel <tamas@tklengyel.com>,
	Alexandru Isaila <aisaila@bitdefender.com>,
	Petre Pircalabu <ppircalabu@bitdefender.com>,
	Shawn Anastasio <sanastasio@raptorengineering.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Bob Eshleman <bobbyeshleman@gmail.com>,
	Connor Davis <connojdavis@gmail.com>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v2 1/4] xen: kconfig: rename MEM_ACCESS -> VM_EVENT
Date: Tue, 21 Jan 2025 12:19:42 +0200
Message-Id: <ff22f35dafd04b16165e1caec038e5a5fcf2aeee.1737452864.git.Sergiy_Kibrik@epam.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <cover.1737452864.git.Sergiy_Kibrik@epam.com>
References: <cover.1737452864.git.Sergiy_Kibrik@epam.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Use more generic CONFIG_VM_EVENT name throughout Xen code instead of
CONFIG_MEM_ACCESS. This reflects the fact that vm_event is a higher level
feature, with mem_access & monitor depending on it.

Suggested-by: Jan Beulich <jbeulich@suse.com>
Suggested-by: Tamas K Lengyel <tamas@tklengyel.com>
Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
---
option renaming brought up as part of v1 review discussion:
   https://lore.kernel.org/xen-devel/c8684340-33f9-41d3-94e4-77ee3bc18306@suse.com/
---
 xen/arch/arm/Makefile                   | 2 +-
 xen/arch/arm/configs/tiny64_defconfig   | 2 +-
 xen/arch/arm/include/asm/mem_access.h   | 4 ++--
 xen/arch/ppc/configs/ppc64_defconfig    | 2 +-
 xen/arch/riscv/configs/tiny64_defconfig | 2 +-
 xen/arch/x86/mm/Makefile                | 2 +-
 xen/common/Kconfig                      | 2 +-
 xen/common/Makefile                     | 2 +-
 xen/common/domctl.c                     | 2 +-
 xen/include/xen/mem_access.h            | 6 +++---
 xen/include/xsm/dummy.h                 | 2 +-
 xen/include/xsm/xsm.h                   | 4 ++--
 xen/xsm/dummy.c                         | 2 +-
 xen/xsm/flask/hooks.c                   | 4 ++--
 14 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 43ab5e8f25..ad29316df1 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -37,7 +37,7 @@ obj-y += irq.o
 obj-y += kernel.init.o
 obj-$(CONFIG_LIVEPATCH) += livepatch.o
 obj-$(CONFIG_LLC_COLORING) += llc-coloring.o
-obj-$(CONFIG_MEM_ACCESS) += mem_access.o
+obj-$(CONFIG_VM_EVENT) += mem_access.o
 obj-y += mm.o
 obj-y += monitor.o
 obj-y += p2m.o
diff --git a/xen/arch/arm/configs/tiny64_defconfig b/xen/arch/arm/configs/tiny64_defconfig
index cc6d93f2f8..469a1eb9f9 100644
--- a/xen/arch/arm/configs/tiny64_defconfig
+++ b/xen/arch/arm/configs/tiny64_defconfig
@@ -5,7 +5,7 @@ CONFIG_ARM=y
 # Architecture Features
 #
 # CONFIG_GICV3 is not set
-# CONFIG_MEM_ACCESS is not set
+# CONFIG_VM_EVENT is not set
 # CONFIG_SBSA_VUART_CONSOLE is not set
 
 #
diff --git a/xen/arch/arm/include/asm/mem_access.h b/xen/arch/arm/include/asm/mem_access.h
index abac8032fc..43f73f7e38 100644
--- a/xen/arch/arm/include/asm/mem_access.h
+++ b/xen/arch/arm/include/asm/mem_access.h
@@ -37,7 +37,7 @@ static inline bool p2m_mem_access_sanity_check(struct domain *d)
  * Send mem event based on the access. Boolean return value indicates if trap
  * needs to be injected into guest.
  */
-#ifdef CONFIG_MEM_ACCESS
+#ifdef CONFIG_VM_EVENT
 bool p2m_mem_access_check(paddr_t gpa, vaddr_t gla, const struct npfec npfec);
 
 struct page_info*
@@ -58,7 +58,7 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned long flag,
     return NULL;
 }
 
-#endif /*CONFIG_MEM_ACCESS*/
+#endif /*CONFIG_VM_EVENT*/
 #endif /* _ASM_ARM_MEM_ACCESS_H */
 
 /*
diff --git a/xen/arch/ppc/configs/ppc64_defconfig b/xen/arch/ppc/configs/ppc64_defconfig
index 4924d881a2..d6aaf772e7 100644
--- a/xen/arch/ppc/configs/ppc64_defconfig
+++ b/xen/arch/ppc/configs/ppc64_defconfig
@@ -1,6 +1,6 @@
 # CONFIG_GRANT_TABLE is not set
 # CONFIG_SPECULATIVE_HARDEN_ARRAY is not set
-# CONFIG_MEM_ACCESS is not set
+# CONFIG_VM_EVENT is not set
 
 CONFIG_PPC64=y
 CONFIG_DEBUG=y
diff --git a/xen/arch/riscv/configs/tiny64_defconfig b/xen/arch/riscv/configs/tiny64_defconfig
index bb3ae26a44..2399f7b918 100644
--- a/xen/arch/riscv/configs/tiny64_defconfig
+++ b/xen/arch/riscv/configs/tiny64_defconfig
@@ -1,6 +1,6 @@
 # CONFIG_BOOT_TIME_CPUPOOLS is not set
 # CONFIG_GRANT_TABLE is not set
-# CONFIG_MEM_ACCESS is not set
+# CONFIG_VM_EVENT is not set
 # CONFIG_COVERAGE is not set
 # CONFIG_LIVEPATCH is not set
 # CONFIG_XSM is not set
diff --git a/xen/arch/x86/mm/Makefile b/xen/arch/x86/mm/Makefile
index 0345388359..960f6e8409 100644
--- a/xen/arch/x86/mm/Makefile
+++ b/xen/arch/x86/mm/Makefile
@@ -4,7 +4,7 @@ obj-$(CONFIG_HVM) += hap/
 obj-$(CONFIG_ALTP2M) += altp2m.o
 obj-$(CONFIG_HVM) += guest_walk_2.o guest_walk_3.o guest_walk_4.o
 obj-$(CONFIG_SHADOW_PAGING) += guest_walk_4.o
-obj-$(CONFIG_MEM_ACCESS) += mem_access.o
+obj-$(CONFIG_VM_EVENT) += mem_access.o
 obj-$(CONFIG_MEM_PAGING) += mem_paging.o
 obj-$(CONFIG_MEM_SHARING) += mem_sharing.o
 obj-$(CONFIG_HVM) += nested.o
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 6166327f4d..a6aa2c5c14 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -92,7 +92,7 @@ config HAS_VMAP
 config MEM_ACCESS_ALWAYS_ON
 	bool
 
-config MEM_ACCESS
+config VM_EVENT
 	def_bool MEM_ACCESS_ALWAYS_ON
 	prompt "Memory Access and VM events" if !MEM_ACCESS_ALWAYS_ON
 	depends on HVM
diff --git a/xen/common/Makefile b/xen/common/Makefile
index cba3b32733..b71d4b3efa 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -26,7 +26,7 @@ obj-$(CONFIG_KEXEC) += kexec.o
 obj-$(CONFIG_KEXEC) += kimage.o
 obj-$(CONFIG_LIVEPATCH) += livepatch.o livepatch_elf.o
 obj-$(CONFIG_LLC_COLORING) += llc-coloring.o
-obj-$(CONFIG_MEM_ACCESS) += mem_access.o
+obj-$(CONFIG_VM_EVENT) += mem_access.o
 obj-y += memory.o
 obj-y += multicall.o
 obj-y += notifier.o
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 05abb581a0..ffe896d8b3 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -802,7 +802,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
             copyback = true;
         break;
 
-#ifdef CONFIG_MEM_ACCESS
+#ifdef CONFIG_VM_EVENT
     case XEN_DOMCTL_set_access_required:
         if ( unlikely(current->domain == d) ) /* no domain_pause() */
             ret = -EPERM;
diff --git a/xen/include/xen/mem_access.h b/xen/include/xen/mem_access.h
index 2231341b5d..4de651038d 100644
--- a/xen/include/xen/mem_access.h
+++ b/xen/include/xen/mem_access.h
@@ -33,7 +33,7 @@
  */
 struct vm_event_st;
 
-#ifdef CONFIG_MEM_ACCESS
+#ifdef CONFIG_VM_EVENT
 #include <asm/mem_access.h>
 #endif
 
@@ -99,7 +99,7 @@ long p2m_set_mem_access_multi(struct domain *d,
 int p2m_get_mem_access(struct domain *d, gfn_t gfn, xenmem_access_t *access,
                        unsigned int altp2m_idx);
 
-#ifdef CONFIG_MEM_ACCESS
+#ifdef CONFIG_VM_EVENT
 int mem_access_memop(unsigned long cmd,
                      XEN_GUEST_HANDLE_PARAM(xen_mem_access_op_t) arg);
 #else
@@ -109,7 +109,7 @@ int mem_access_memop(unsigned long cmd,
 {
     return -ENOSYS;
 }
-#endif /* CONFIG_MEM_ACCESS */
+#endif /* CONFIG_VM_EVENT */
 
 #endif /* _XEN_MEM_ACCESS_H */
 
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 6a2fc33c3b..c728da9016 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -646,7 +646,7 @@ static XSM_INLINE int cf_check xsm_vm_event_control(
     return xsm_default_action(action, current->domain, d);
 }
 
-#ifdef CONFIG_MEM_ACCESS
+#ifdef CONFIG_VM_EVENT
 static XSM_INLINE int cf_check xsm_mem_access(XSM_DEFAULT_ARG struct domain *d)
 {
     XSM_ASSERT_ACTION(XSM_DM_PRIV);
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 4dbff9d866..6ac1627b7b 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -153,7 +153,7 @@ struct xsm_ops {
 
     int (*vm_event_control)(struct domain *d, int mode, int op);
 
-#ifdef CONFIG_MEM_ACCESS
+#ifdef CONFIG_VM_EVENT
     int (*mem_access)(struct domain *d);
 #endif
 
@@ -631,7 +631,7 @@ static inline int xsm_vm_event_control(
     return alternative_call(xsm_ops.vm_event_control, d, mode, op);
 }
 
-#ifdef CONFIG_MEM_ACCESS
+#ifdef CONFIG_VM_EVENT
 static inline int xsm_mem_access(xsm_default_t def, struct domain *d)
 {
     return alternative_call(xsm_ops.mem_access, d);
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index e6ffa948f7..a6d2ec2f8b 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -111,7 +111,7 @@ static const struct xsm_ops __initconst_cf_clobber dummy_ops = {
 
     .vm_event_control              = xsm_vm_event_control,
 
-#ifdef CONFIG_MEM_ACCESS
+#ifdef CONFIG_VM_EVENT
     .mem_access                    = xsm_mem_access,
 #endif
 
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 14d84df9ca..acca89e123 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1361,7 +1361,7 @@ static int cf_check flask_vm_event_control(struct domain *d, int mode, int op)
     return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__VM_EVENT);
 }
 
-#ifdef CONFIG_MEM_ACCESS
+#ifdef CONFIG_VM_EVENT
 static int cf_check flask_mem_access(struct domain *d)
 {
     return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__MEM_ACCESS);
@@ -1949,7 +1949,7 @@ static const struct xsm_ops __initconst_cf_clobber flask_ops = {
 
     .vm_event_control = flask_vm_event_control,
 
-#ifdef CONFIG_MEM_ACCESS
+#ifdef CONFIG_VM_EVENT
     .mem_access = flask_mem_access,
 #endif
 
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Tue Jan 21 10:21:55 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 10:21:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875279.1285721 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taBOM-0004hj-CW; Tue, 21 Jan 2025 10:21:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875279.1285721; Tue, 21 Jan 2025 10:21:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taBOM-0004hc-9I; Tue, 21 Jan 2025 10:21:54 +0000
Received: by outflank-mailman (input) for mailman id 875279;
 Tue, 21 Jan 2025 10:21:52 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=fb3U=UN=darkstar.site=sakib@srs-se1.protection.inumbo.net>)
 id 1taBOK-0004hS-Is
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 10:21:52 +0000
Received: from fforwardh-b2-smtp.messagingengine.com
 (fforwardh-b2-smtp.messagingengine.com [202.12.124.197])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 86c548aa-d7e1-11ef-99a4-01e77a169b0f;
 Tue, 21 Jan 2025 11:21:50 +0100 (CET)
Received: from phl-compute-07.internal (phl-compute-07.phl.internal
 [10.202.2.47])
 by mailfforwardh.stl.internal (Postfix) with ESMTP id 9CC841740130;
 Tue, 21 Jan 2025 05:21:49 -0500 (EST)
Received: from phl-frontend-01 ([10.202.2.160])
 by phl-compute-07.internal (MEProxy); Tue, 21 Jan 2025 05:21:49 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 21 Jan 2025 05:21:48 -0500 (EST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 86c548aa-d7e1-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:date:date:feedback-id:feedback-id:from:from
	:in-reply-to:in-reply-to:message-id:mime-version:references
	:reply-to:subject:subject:to:to:x-me-proxy:x-me-sender
	:x-me-sender:x-sasl-enc; s=fm3; t=1737454909; x=1737541309; bh=I
	exxg0Qo4kbGg2eh3LYztUydfNJEguXN/Nl++lsTnTM=; b=Mwtfzvg8F8Bak6QlF
	ERJgm4sMuddnT+Y05HgYDF9YOnUM6XYBwMJJ1TIm7lkCvTWld0VtQ5yOBLqGlq1U
	OUw+2A0UA2r+CXu9WB3TVo4SoJ0iOJwiBBD/Dy+yMC45Fbt2rgFPrgP8vivb2Twm
	S/1zPN4+tuTdqlqM/n0LOEFAFD79eMy7bF/52tLNcU2rYGib73OqaM2uNwscTQK0
	nn6aww3qaFUBCj4qLL4bbfFrJUHzbZ1OU/9btCgFNTGdEV439OsaoU1kbXfU1qQA
	We8dzYdR1jfyCYRPwSRglQdRjuXqDg+fNROx79OwOY5//5i4OiTO8Yo4HtZ9Sg6R
	aBFYA==
X-ME-Sender: <xms:PXWPZ8LxUUGOyNoezIC86blph30I-sU3dmLiiWg_CZ5D2B8E6sf2Rw>
    <xme:PXWPZ8JX5tHCwgeA1rAvKo23Ft7DsEBYyZYZtZmKORZY-b8nyDD9_EnRfT-f1W9ah
    vVcHBhG7bwoGDaMLaU>
X-ME-Received: <xmr:PXWPZ8sBJGw6Q0_Mz-5jrqSEbpIoLmXsiVjj7zaqF0N1hFUF6cKRDq7OMh4HnIbR7ECBkbv88rSrMXRtbb2_U-ecmUEMY5Uil5zdsrz0k98iQCGA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrudejuddgudefucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
    rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
    htshculddquddttddmnecujfgurhephffvvefufffkofgjfhgggfestdekredtredttden
    ucfhrhhomhepufgvrhhgihihucfmihgsrhhikhcuoefuvghrghhihigpmfhisghrihhkse
    gvphgrmhdrtghomheqnecuggftrfgrthhtvghrnheptdejgeegvdffkeekleefueevgfdu
    heevkedvhfdvkeeludehleegheeivedugfejnecuvehluhhsthgvrhfuihiivgeptdenuc
    frrghrrghmpehmrghilhhfrhhomhepshgrkhhisgesuggrrhhkshhtrghrrdhsihhtvgdp
    nhgspghrtghpthhtohepiedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepgigvnh
    dquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdhrtghpthhtohep
    shgvrhhgihihpghkihgsrhhikhesvghprghmrdgtohhmpdhrtghpthhtohepjhgsvghulh
    hitghhsehsuhhsvgdrtghomhdprhgtphhtthhopegrnhgurhgvfidrtghoohhpvghrfees
    tghithhrihigrdgtohhmpdhrtghpthhtoheprhhoghgvrhdrphgruhestghithhrihigrd
    gtohhmpdhrtghpthhtohepshhsthgrsggvlhhlihhniheskhgvrhhnvghlrdhorhhg
X-ME-Proxy: <xmx:PXWPZ5aR-FpoSkHSPoLXZCibCAEzXYLeaFOB6s-4UtYQAPmyK-mo7w>
    <xmx:PXWPZzaFLpXk-r9wtfKbh9nQSv1Dmv4wPntxae4komBZ4D2pXl5oxA>
    <xmx:PXWPZ1DYK3MvlcOJJ5y-7hU5aVMtuKUtiVLaJP8OyolQCX_Ceu-LkA>
    <xmx:PXWPZ5aLYKpFrUAfisMNUhe5AV3jbtwRwrCzTFYDPAMDQx-d_pBhog>
    <xmx:PXWPZ7r_fBPDgHPfXWGbAZtgp5aTn27aWzmnmBik8qPntFGTmpV-7A>
    <xmx:PXWPZ-wuRQL-Th-EgLzpjc40aiarrJPRAcB9q5j6DmN-nyam1g8oS5l3dVq8>
Feedback-ID: i57d9e29e:Fastmail
From: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
To: xen-devel@lists.xenproject.org
Cc: Sergiy Kibrik <Sergiy_Kibrik@epam.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v2 2/4] x86:monitor: control monitor.c build with CONFIG_VM_EVENT option
Date: Tue, 21 Jan 2025 12:21:47 +0200
Message-Id: <6fe254034570e1443a41c7dc5e3e3767b9c77f79.1737452864.git.Sergiy_Kibrik@epam.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <cover.1737452864.git.Sergiy_Kibrik@epam.com>
References: <cover.1737452864.git.Sergiy_Kibrik@epam.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Replace more general CONFIG_HVM option with CONFIG_VM_EVENT which is more
relevant and specific to monitoring. This is only to clarify at build level
to which subsystem this file belongs.

No functional change here, as VM_EVENT depends on HVM.

Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
---
 xen/arch/x86/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index b35fd5196c..8b3c17d689 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -49,7 +49,7 @@ obj-$(CONFIG_PV) += ioport_emulate.o
 obj-y += irq.o
 obj-$(CONFIG_KEXEC) += machine_kexec.o
 obj-y += mm.o x86_64/mm.o
-obj-$(CONFIG_HVM) += monitor.o
+obj-$(CONFIG_VM_EVENT) += monitor.o
 obj-y += mpparse.o
 obj-y += nmi.o
 obj-y += numa.o
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Tue Jan 21 10:23:59 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 10:23:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875288.1285731 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taBQL-0005Gj-NT; Tue, 21 Jan 2025 10:23:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875288.1285731; Tue, 21 Jan 2025 10:23:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taBQL-0005Gc-J0; Tue, 21 Jan 2025 10:23:57 +0000
Received: by outflank-mailman (input) for mailman id 875288;
 Tue, 21 Jan 2025 10:23:55 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=fb3U=UN=darkstar.site=sakib@srs-se1.protection.inumbo.net>)
 id 1taBQJ-0005GT-MP
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 10:23:55 +0000
Received: from fforwardh-b2-smtp.messagingengine.com
 (fforwardh-b2-smtp.messagingengine.com [202.12.124.197])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d0828c1f-d7e1-11ef-a0e4-8be0dac302b0;
 Tue, 21 Jan 2025 11:23:54 +0100 (CET)
Received: from phl-compute-04.internal (phl-compute-04.phl.internal
 [10.202.2.44])
 by mailfforwardh.stl.internal (Postfix) with ESMTP id 2EC94174022A;
 Tue, 21 Jan 2025 05:23:53 -0500 (EST)
Received: from phl-frontend-01 ([10.202.2.160])
 by phl-compute-04.internal (MEProxy); Tue, 21 Jan 2025 05:23:53 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 21 Jan 2025 05:23:51 -0500 (EST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: d0828c1f-d7e1-11ef-a0e4-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:date:date:feedback-id:feedback-id:from:from
	:in-reply-to:in-reply-to:message-id:mime-version:references
	:reply-to:subject:subject:to:to:x-me-proxy:x-me-sender
	:x-me-sender:x-sasl-enc; s=fm3; t=1737455033; x=1737541433; bh=i
	YEVQqGlu6rOaDg6bu+NtoBAX9qDsxKc2/u3zO9X5Vw=; b=J8sBVHrlRXqHSHdL7
	53gX6LympSmCHzv/35ObJrcimhWJKHikXeCIGgb9HgHq0wxiwZKAQ0Nf4ma0Wa60
	wD9g5fDKJk8sGB/lOX/IOYBCtwhW6dO1CCP/fef1nIEdEvI6g3r/nD8dKSMkIQub
	sj97Ifj4wtqBNnDYvRHbXARnQwEn0ofRN0CmK4SyQqBpRJTPvMnU1+frmLW8eegw
	rcQcrjY14g4oK3sxmd2ZHU6IvwygsPTDgPEUeBIJe48VevcXbNgKvDjOlMTba0wL
	t6Q3J60b8b/g2OjvuFc0F9NohVK1dgVxNnleuPCNvqN6+W8Iwjn3D+b8KrjTHJJ5
	nOLiQ==
X-ME-Sender: <xms:uHWPZ3Mmz-rwz0TGXu5lWLz2-CIlJIvgp99gFfxLkuYXqsn3f8QpBQ>
    <xme:uHWPZx_NuIpXpR7Io4zLFMFh4f9xHXDVaah5M0sk_ZYVHk2Nxpz2E8v999PhNvJLW
    hNHt3zhkkwwDBFXg3I>
X-ME-Received: <xmr:uHWPZ2SI7Qp3t5TA7ktW9-_ELQfkp9NMeNu_3eY-LUvh3GT_kcxCZfwuis1vzYWGQdRp-9192gJRWVf3G2bcz3VWwUFLqME3JG-V1Xef2BljgCJT>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrudejuddgudegucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
    rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
    htshculddquddttddmnecujfgurhephffvvefufffkofgjfhgggfestdekredtredttden
    ucfhrhhomhepufgvrhhgihihucfmihgsrhhikhcuoefuvghrghhihigpmfhisghrihhkse
    gvphgrmhdrtghomheqnecuggftrfgrthhtvghrnheptdejgeegvdffkeekleefueevgfdu
    heevkedvhfdvkeeludehleegheeivedugfejnecuvehluhhsthgvrhfuihiivgeptdenuc
    frrghrrghmpehmrghilhhfrhhomhepshgrkhhisgesuggrrhhkshhtrghrrdhsihhtvgdp
    nhgspghrtghpthhtohephedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepgigvnh
    dquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdhrtghpthhtohep
    shgvrhhgihihpghkihgsrhhikhesvghprghmrdgtohhmpdhrtghpthhtohepnhhitgholh
    grrdhvvghtrhhinhhisegsuhhgshgvnhhgrdgtohhmpdhrtghpthhtoheptggrrhguohgv
    segtrghrughovgdrtghomhdprhgtphhtthhopehsshhtrggsvghllhhinhhisehkvghrnh
    gvlhdrohhrgh
X-ME-Proxy: <xmx:uHWPZ7tWwMihqchR2xjQLwtmyGoCaqkKZNwcwVt7rzJE3g9u6nkHeA>
    <xmx:uHWPZ_ezeKLeG8pj_JhFrFth1n4M-9MmzYzqjmi1DodlKmsoXPy9Ag>
    <xmx:uHWPZ30mrzl0exOz7oE22_VN4fbuAoIGV-7PhPYLcb_oH6SiciB0NQ>
    <xmx:uHWPZ79CAUBEs0TOfC3_VILQwew_VsaVSGEwYoutti_44yQ5JONiMA>
    <xmx:uHWPZy_SRZU-jFQOGUHE_01ZwENjcNe7_kng45ilzjnZBQhk7Z6lqA>
    <xmx:uXWPZ27KKqRR88jTqEFEJ2-tpcMkGM4w5b3ZMgZtowvuRDdrbjh1giHBJY7g>
Feedback-ID: id5db7974:Fastmail
From: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
To: xen-devel@lists.xenproject.org
Cc: Sergiy Kibrik <Sergiy_Kibrik@epam.com>,
	Nicola Vetrini <nicola.vetrini@bugseng.com>,
	Doug Goldstein <cardoe@cardoe.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v2 3/4] automation: rename CONFIG_MEM_ACCESS -> CONFIG_VM_EVENT
Date: Tue, 21 Jan 2025 12:23:50 +0200
Message-Id: <e43444e0cd04bf08edf47ee4c56d0aa675d19534.1737452864.git.Sergiy_Kibrik@epam.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <cover.1737452864.git.Sergiy_Kibrik@epam.com>
References: <cover.1737452864.git.Sergiy_Kibrik@epam.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Following the renaming of Xen build option.

Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
---
 automation/eclair_analysis/xen_arm_config | 2 +-
 automation/eclair_analysis/xen_x86_config | 2 +-
 automation/gitlab-ci/build.yaml           | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/automation/eclair_analysis/xen_arm_config b/automation/eclair_analysis/xen_arm_config
index ef140ceb73..4b01ef51c5 100644
--- a/automation/eclair_analysis/xen_arm_config
+++ b/automation/eclair_analysis/xen_arm_config
@@ -63,7 +63,7 @@ CONFIG_HAS_DEVICE_TREE=y
 CONFIG_HAS_FAST_MULTIPLY=y
 CONFIG_HAS_PDX=y
 CONFIG_HAS_PMAP=y
-# CONFIG_MEM_ACCESS is not set
+# CONFIG_VM_EVENT is not set
 CONFIG_STATIC_MEMORY=y
 
 #
diff --git a/automation/eclair_analysis/xen_x86_config b/automation/eclair_analysis/xen_x86_config
index abc44d43e1..9da3264dd0 100644
--- a/automation/eclair_analysis/xen_x86_config
+++ b/automation/eclair_analysis/xen_x86_config
@@ -54,7 +54,7 @@ CONFIG_HAS_PDX=y
 CONFIG_HAS_SCHED_GRANULARITY=y
 CONFIG_HAS_UBSAN=y
 CONFIG_MEM_ACCESS_ALWAYS_ON=y
-CONFIG_MEM_ACCESS=y
+CONFIG_VM_EVENT=y
 CONFIG_NEEDS_LIBELF=y
 CONFIG_NUMA=y
 
diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
index bc4a8a5ad2..ed65e2edd7 100644
--- a/automation/gitlab-ci/build.yaml
+++ b/automation/gitlab-ci/build.yaml
@@ -741,7 +741,7 @@ debian-12-riscv64-gcc:
       CONFIG_EXPERT=y
       CONFIG_GRANT_TABLE=n
       CONFIG_LIVEPATCH=n
-      CONFIG_MEM_ACCESS=n
+      CONFIG_VM_EVENT=n
       CONFIG_QEMU_PLATFORM=y
       CONFIG_XSM=n
 
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Tue Jan 21 10:24:39 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 10:24:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875298.1285741 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taBR0-0005lT-Tq; Tue, 21 Jan 2025 10:24:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875298.1285741; Tue, 21 Jan 2025 10: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 <xen-devel-bounces@lists.xenproject.org>)
	id 1taBR0-0005lM-R1; Tue, 21 Jan 2025 10:24:38 +0000
Received: by outflank-mailman (input) for mailman id 875298;
 Tue, 21 Jan 2025 10:24:38 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Gode=UN=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1taBR0-0005X8-8g
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 10:24:38 +0000
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com
 [2a00:1450:4864:20::333])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e9d8cd88-d7e1-11ef-99a4-01e77a169b0f;
 Tue, 21 Jan 2025 11:24:36 +0100 (CET)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-436202dd730so38986785e9.2
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 02:24:36 -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
 5b1f17b1804b1-438904625f5sm176947175e9.28.2025.01.21.02.24.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 21 Jan 2025 02:24:35 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e9d8cd88-d7e1-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737455076; x=1738059876; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=RgwUgZwX2PeWgrko2c5vyGrhzzW//75peqveWOYVkXI=;
        b=L3ZCj+yopXMmTcpSMtmQFWF5fE+/A7TDExfDXwhmNVXXHAt8Hx2eBvQymvmykc79Vn
         vy1ZBlxegEZO4S2Kc2QAY1anjbDVBAPoSNZpXKK0tilc+IQkNzh3qt8brwAivMvqGmc0
         s+p81N6YFgQRdYqJpLbLkCGWfktn3DVbPX4Oj4dDVMFljt+7y8F02ZUbT0/0rd2f/HoL
         LqcFk6FpCjoV79CUGJOl1VadOJCfsVvf5D0Y0M//Z7nVRmzqUGhm2HXrPx0kuUNYDV5L
         AQxrSqQ6OR5TJMspONUM3vbrs648RTqVHDAlueOUTo05Lz0xyTUUNt69Sqxaa8+vAygN
         H42Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737455076; x=1738059876;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=RgwUgZwX2PeWgrko2c5vyGrhzzW//75peqveWOYVkXI=;
        b=IPvt5PL0ERCPfZwIunizTE7DoS5e9PaD2Uk59TJr7ZYQZB/dIebk5N0Y/jmY0/yKht
         zosxtGDPFGhqU8NYOrFkT/jdV3vAVkagZOdDXiaEJ3vPXqqo/c0nVMTYDvJdEEpVh4Tu
         1FEbGAZ+6aofo/6YDVMbRpgehJ3yiu6E90NjrPNTgiOlJIG/Jhsw27eF213t0rjXYA4V
         UfrqfZBqi/LYTmwoHFGrzxcYM5q8YCAj2outtCOU5irBsUztFn5E7D0CWu0m1xPsnJZI
         tLEZ+VVhGQMxYY2ad3S45dWyxfbcMIsgU0l3Ks0EylJk+ZczO0s0qPVxGVgEj0kwLvQG
         F8jA==
X-Forwarded-Encrypted: i=1; AJvYcCXY0qz0Mo/nyPClYWRftW44PSSMs1NbhPTxZ8E8pyxjNWDfUJ8kBr7rW58gzR6iprGHQhdjagAAjC8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzqtyNSko2aWnWqRBJ88rMGCJXuWsrwK+K6+OESjamvz/7CHfEW
	KuX2KFr2nm5A5gfqWsUPy5EaUSRBzXWqqitC2baVA6zXe9poj6G5OskODI6y7w==
X-Gm-Gg: ASbGncvA83I1sAaCaPjIwhZrNmVCiRBWD+uEtbZaoWotSXlzApOH0ZNicMDab2P46Ag
	Wz1lvuqEPHrc3KtLeuadeqYEqu8hQ+bkDPYUWcY5Xu2P4Vt4gU4JKjJ3wcBq70Vhk3+TNjBBY94
	V2CbXrPoXkH+XmvniLCxOpGwkGMEhnNV4W+WzMzJigVDNsGEGMl2bSa357jAifAU3N0ob0CqCXa
	xaZgBXzO6YoVZtjT7G5Sc0eItifBhuYLaMuxQryvl647qBzMtuHoZjdc+Agg0cuIo8JtKx86RNq
	1IBWdPXXd+VQ7Fijd0FlqNR+J3R+BDvTeUBU34VjUlk4Flvj7fvqY+0=
X-Google-Smtp-Source: AGHT+IEXkK/zCXQm1sdv62CbcIrymcCZJrTBa4KzvE+AQZDbhpgSYgLRbKBdP5I07CKYRiJ9taHA8A==
X-Received: by 2002:a7b:c44d:0:b0:434:9fac:b158 with SMTP id 5b1f17b1804b1-438a2b59615mr86054555e9.1.1737455075520;
        Tue, 21 Jan 2025 02:24:35 -0800 (PST)
Message-ID: <c6f909c6-bc4d-4dd9-acce-b36c0f450601@suse.com>
Date: Tue, 21 Jan 2025 11:24:34 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v2 08/10] x86/emulate: Implement XSAVES/XRSTORS for
 arch LBR
To: Tu Dinh <ngoc-tu.dinh@vates.tech>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Juergen Gross <jgross@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20250102084413.102-1-ngoc-tu.dinh@vates.tech>
 <20250102084413.102-9-ngoc-tu.dinh@vates.tech>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250102084413.102-9-ngoc-tu.dinh@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 02.01.2025 09:45, Tu Dinh wrote:
> Add new set_lbr_depth HVM function and emulate ops to support LBR
> XSAVES/XRSTORS emulation.

What about any of the other state components, like BNDCSR?

> Add the appropriate instruction hooks to 0fc7.c. Translate LBR registers
> using cs.base within a large block emulator operation.
> 
> Signed-off-by: Tu Dinh <ngoc-tu.dinh@vates.tech>

I fear this needs splitting; the x86_emulate/* changes want to be separate,
and I'm having a hard time seeing why we'd gain XSAVES/XRSTORS support
there without first/also gaining XSAVE/XRSTOR/XSAVEOPT/XSAVEC support.

Various comments further down will hopefully give you an idea of why this
enabling wasn't done so far.

> --- a/xen/arch/x86/include/asm/hvm/hvm.h
> +++ b/xen/arch/x86/include/asm/hvm/hvm.h
> @@ -238,6 +238,9 @@ struct hvm_function_table {
>      int (*vmtrace_get_option)(struct vcpu *v, uint64_t key, uint64_t *value);
>      int (*vmtrace_reset)(struct vcpu *v);
>  
> +    /* Arch LBR */
> +    void (*set_lbr_depth)(struct vcpu *v, uint32_t depth);

I don't see why "depth" would need to be fixed-width. "unsigned int" will
surely do? See also ./CODING_STYLE.

> --- a/xen/arch/x86/x86_emulate/0fc7.c
> +++ b/xen/arch/x86/x86_emulate/0fc7.c
> @@ -10,6 +10,10 @@
>  
>  #include "private.h"
>  
> +#if defined(__XEN__) && !defined(X86EMUL_NO_FPU)
> +# include <asm/xstate.h>
> +#endif
> +
>  /* Avoid namespace pollution. */
>  #undef cmpxchg
>  
> @@ -107,87 +111,203 @@ int x86emul_0fc7(struct x86_emulate_state *s,
>      }
>      else
>      {
> -        union {
> -            uint32_t u32[2];
> -            uint64_t u64[2];
> -        } *old, *aux;
> -
> -        /* cmpxchg8b/cmpxchg16b */
> -        generate_exception_if((s->modrm_reg & 7) != 1, X86_EXC_UD);
> -        fail_if(!ops->cmpxchg);
> -        if ( s->rex_prefix & REX_W )
> -        {
> -            host_and_vcpu_must_have(cx16);
> -            generate_exception_if(!is_aligned(s->ea.mem.seg, s->ea.mem.off, 16,
> -                                              ctxt, ops),
> -                                  X86_EXC_GP, 0);
> -            s->op_bytes = 16;
> -        }
> -        else
> +        switch ( s->modrm_reg & 7 )
>          {
> -            vcpu_must_have(cx8);
> -            s->op_bytes = 8;
> -        }
> +            default:
> +                return X86EMUL_UNRECOGNIZED;
>  
> -        old = container_of(&mmvalp->ymm[0], typeof(*old), u64[0]);
> -        aux = container_of(&mmvalp->ymm[2], typeof(*aux), u64[0]);
> +            case 1: /* cmpxchg8b/cmpxchg16b */
> +            {
> +                union {
> +                    uint32_t u32[2];
> +                    uint64_t u64[2];
> +                } *old, *aux;
>  
> -        /* Get actual old value. */
> -        if ( (rc = ops->read(s->ea.mem.seg, s->ea.mem.off, old, s->op_bytes,
> -                             ctxt)) != X86EMUL_OKAY )
> -            goto done;
> +                fail_if(!ops->cmpxchg);
> +                if ( s->rex_prefix & REX_W )
> +                {
> +                    host_and_vcpu_must_have(cx16);
> +                    generate_exception_if(!is_aligned(s->ea.mem.seg, s->ea.mem.off, 16,
> +                                                      ctxt, ops),
> +                                          X86_EXC_GP, 0);
> +                    s->op_bytes = 16;
> +                }
> +                else
> +                {
> +                    vcpu_must_have(cx8);
> +                    s->op_bytes = 8;
> +                }
>  
> -        /* Get expected value. */
> -        if ( s->op_bytes == 8 )
> -        {
> -            aux->u32[0] = regs->eax;
> -            aux->u32[1] = regs->edx;
> -        }
> -        else
> -        {
> -            aux->u64[0] = regs->r(ax);
> -            aux->u64[1] = regs->r(dx);
> -        }
> +                old = container_of(&mmvalp->ymm[0], typeof(*old), u64[0]);
> +                aux = container_of(&mmvalp->ymm[2], typeof(*aux), u64[0]);
>  
> -        if ( memcmp(old, aux, s->op_bytes) )
> -        {
> -        cmpxchgNb_failed:
> -            /* Expected != actual: store actual to rDX:rAX and clear ZF. */
> -            regs->r(ax) = s->op_bytes == 8 ? old->u32[0] : old->u64[0];
> -            regs->r(dx) = s->op_bytes == 8 ? old->u32[1] : old->u64[1];
> -            regs->eflags &= ~X86_EFLAGS_ZF;
> -        }
> -        else
> -        {
> -            /*
> -             * Expected == actual: Get proposed value, attempt atomic cmpxchg
> -             * and set ZF if successful.
> -             */
> -            if ( s->op_bytes == 8 )
> -            {
> -                aux->u32[0] = regs->ebx;
> -                aux->u32[1] = regs->ecx;
> -            }
> -            else
> -            {
> -                aux->u64[0] = regs->r(bx);
> -                aux->u64[1] = regs->r(cx);
> +                /* Get actual old value. */
> +                if ( (rc = ops->read(s->ea.mem.seg, s->ea.mem.off, old, s->op_bytes,
> +                                     ctxt)) != X86EMUL_OKAY )
> +                    goto done;
> +
> +                /* Get expected value. */
> +                if ( s->op_bytes == 8 )
> +                {
> +                    aux->u32[0] = regs->eax;
> +                    aux->u32[1] = regs->edx;
> +                }
> +                else
> +                {
> +                    aux->u64[0] = regs->r(ax);
> +                    aux->u64[1] = regs->r(dx);
> +                }
> +
> +                if ( memcmp(old, aux, s->op_bytes) )
> +                {
> +                cmpxchgNb_failed:
> +                    /* Expected != actual: store actual to rDX:rAX and clear ZF. */
> +                    regs->r(ax) = s->op_bytes == 8 ? old->u32[0] : old->u64[0];
> +                    regs->r(dx) = s->op_bytes == 8 ? old->u32[1] : old->u64[1];
> +                    regs->eflags &= ~X86_EFLAGS_ZF;
> +                }
> +                else
> +                {
> +                    /*
> +                    * Expected == actual: Get proposed value, attempt atomic cmpxchg
> +                    * and set ZF if successful.
> +                    */
> +                    if ( s->op_bytes == 8 )
> +                    {
> +                        aux->u32[0] = regs->ebx;
> +                        aux->u32[1] = regs->ecx;
> +                    }
> +                    else
> +                    {
> +                        aux->u64[0] = regs->r(bx);
> +                        aux->u64[1] = regs->r(cx);
> +                    }
> +
> +                    switch ( rc = ops->cmpxchg(s->ea.mem.seg, s->ea.mem.off, old, aux,
> +                                               s->op_bytes, s->lock_prefix, ctxt) )
> +                    {
> +                    case X86EMUL_OKAY:
> +                        regs->eflags |= X86_EFLAGS_ZF;
> +                        break;
> +
> +                    case X86EMUL_CMPXCHG_FAILED:
> +                        rc = X86EMUL_OKAY;
> +                        goto cmpxchgNb_failed;
> +
> +                    default:
> +                        goto done;
> +                    }
> +                }
> +                break;
>              }
>  
> -            switch ( rc = ops->cmpxchg(s->ea.mem.seg, s->ea.mem.off, old, aux,
> -                                       s->op_bytes, s->lock_prefix, ctxt) )

Since it's a significant chunk of diff, this re-arrangement (mostly re-
indentation) likely would better be split out to a separate patch, too.
This will then also help readability of the diff for the actual addition
you're making.

> +#if defined(__XEN__) && !defined(X86EMUL_NO_FPU)

I'm sorry, but no, it is not an option to confine this to __XEN__. This
very certainly needs wiring up in the testharness as well, just like we
have it for FXSAVE/FXRSTOR.

I'm further unconvinced that X86EMUL_NO_FPU is appropriate to use here.
This is different from FXSAVE/FXRSTOR, the more that you likely have
seen that NO_SIMD and NO_MMX are checked there as well (only FSAVE/FRSTOR
have solely NO_FPU as a check). XSAVE etc are about more than just FPU /
SIMD state, after all (arch LBR being one of them), expressed by the lack
of an F prefix on their mnemonics.

> +            case 3: /* xrstors */
> +            case 5: /* xsaves */
>              {
> -            case X86EMUL_OKAY:
> -                regs->eflags |= X86_EFLAGS_ZF;
> -                break;
> +                unsigned long cr0, cr4;
> +                unsigned long xcr0, xss;
> +                struct segment_register cs;
>  
> -            case X86EMUL_CMPXCHG_FAILED:
> -                rc = X86EMUL_OKAY;
> -                goto cmpxchgNb_failed;
> +                generate_exception_if(s->vex.pfx, X86_EXC_UD);
> +                host_and_vcpu_must_have(xsaves);
> +                generate_exception_if(s->ea.type != OP_MEM, X86_EXC_UD);
> +                generate_exception_if(!is_aligned(s->ea.mem.seg, s->ea.mem.off,
> +                                                  64, ctxt, ops),
> +                                      X86_EXC_GP, 0);
> +                fail_if(!ops->blk || !ops->read_cr || !ops->read_xcr ||
> +                        !ops->read_msr || !ops->write_msr ||
> +                        !ops->read_segment);
> +                fail_if(vcpu_has_arch_lbr() && !ops->set_lbr_depth);
>  
> -            default:
> -                goto done;
> +                if ( ops->read_cr(4, &cr4, ctxt) != X86EMUL_OKAY ||
> +                     ops->read_cr(0, &cr0, ctxt) != X86EMUL_OKAY )
> +                     cr0 = cr4 = 0;
> +                generate_exception_if(!(cr4 & X86_CR4_OSXSAVE), X86_EXC_UD);
> +                generate_exception_if(cr0 & X86_CR0_TS, X86_EXC_NM);
> +                generate_exception_if(!mode_ring0(), X86_EXC_GP, 0);
> +
> +                if ( (rc = ops->read_segment(x86_seg_cs,
> +                                             &cs, ctxt)) != X86EMUL_OKAY ||
> +                     (rc = ops->read_xcr(0, &xcr0, ctxt)) != X86EMUL_OKAY ||
> +                     (rc = ops->read_msr(MSR_IA32_XSS,
> +                                         &xss, ctxt)) != X86EMUL_OKAY )
> +                    goto done;
> +
> +                if ( vcpu_has_arch_lbr() &&
> +                     ((rc = ops->read_msr(MSR_LBR_CTL, &ctxt->xsaves.lbr_ctl,
> +                                          ctxt)) != X86EMUL_OKAY ||
> +                      (rc = ops->read_msr(MSR_LBR_DEPTH, &ctxt->xsaves.lbr_depth,
> +                                          ctxt)) != X86EMUL_OKAY) )
> +                    goto done;
> +
> +                s->blk = (s->modrm_reg & 7) == 3 ? blk_xrstors : blk_xsaves;
> +                ctxt->xsaves.rfbm = ((uint64_t)regs->edx << 32) | regs->eax;
> +                ctxt->xsaves.rfbm &= xcr0 | xss;

I'm unconvinced that this is a field that needs recording / passing. The
callee has all necessary pieces available afaic (the hookm after all,
should know what its sibling hook functions are).

> +                if ( s->blk == blk_xrstors )
> +                {
> +                    struct xsave_struct hdr;
> +                    int i;

Please don't ever use plain int for variables only ever holding non-
negative values.

> +                    if ( (rc = ops->read(s->ea.mem.seg, s->ea.mem.off, &hdr,
> +                                         sizeof(hdr), ctxt)) != X86EMUL_OKAY )
> +                        goto done;
> +                    /*
> +                     * We must validate xcomp_bv at this stage to get a
> +                     * stable XSAVE area size.
> +                     */
> +                    generate_exception_if(!xsave_area_compressed(&hdr),
> +                                          X86_EXC_GP, 0);
> +                    generate_exception_if(hdr.xsave_hdr.xcomp_bv &
> +                                          ~XSTATE_COMPACTION_ENABLED &
> +                                          ~(xcr0 | xss),
> +                                          X86_EXC_GP, 0);
> +                    generate_exception_if(hdr.xsave_hdr.xstate_bv &
> +                                          ~hdr.xsave_hdr.xcomp_bv,
> +                                          X86_EXC_GP, 0);
> +                    for ( i = 0; i < ARRAY_SIZE(hdr.xsave_hdr.reserved); i++ )
> +                        generate_exception_if(hdr.xsave_hdr.reserved[i],
> +                                              X86_EXC_GP, 0);
> +                    ctxt->xsaves.size = xstate_compressed_size(
> +                            hdr.xsave_hdr.xcomp_bv &
> +                            ~XSTATE_COMPACTION_ENABLED);
> +                }
> +                else
> +                {
> +                    ctxt->xsaves.size =
> +                            xstate_compressed_size(ctxt->xsaves.rfbm);
> +                }
> +
> +                if ( (rc = ops->blk(s->ea.mem.seg, s->ea.mem.off, NULL,
> +                                    ctxt->xsaves.size, &regs->eflags,
> +                                    s, ctxt)) != X86EMUL_OKAY )
> +                    goto done;
> +
> +                if ( s->blk == blk_xrstors && vcpu_has_arch_lbr() )
> +                {
> +                    if ( (rc = ops->write_msr(MSR_LBR_CTL,
> +                                              ctxt->xsaves.lbr_ctl,
> +                                              ctxt)) != X86EMUL_OKAY ||
> +                         (rc = ops->set_lbr_depth(ctxt->xsaves.lbr_depth,
> +                                                  ctxt)) != X86EMUL_OKAY )

This is the sole place where this new emulator hook is used. Why is the
hook necessary? IOW why isn't this ->write_msr(MSR_LBR_DEPTH, ...)?

> +                        goto done;
> +                    /*
> +                     * Even if xstate_bv[LBR]=0, XRSTORS will still clear
> +                     * LBR/LER MSRs.
> +                     */
> +                    if ( !(ctxt->xsaves.xstate_bv & X86_XSS_LBR) &&

Comment and code aren't quite correct, are they? The clearing won't happen
if the bit wasn't set in %eax. Plus I'd expect this to happen by way of
calling ->blk() (through the XSTRORS insn there) anyway.

> +                         ((rc = ops->write_msr(MSR_IA32_LASTINTFROMIP, 0,
> +                                               ctxt)) != X86EMUL_OKAY ||
> +                          (rc = ops->write_msr(MSR_IA32_LASTINTTOIP, 0,
> +                                               ctxt)) != X86EMUL_OKAY ||
> +                          (rc = ops->write_msr(MSR_LER_INFO, 0,
> +                                               ctxt)) != X86EMUL_OKAY) )
> +                        goto done;

If one of the later operations fails, in principle we'd need to roll back
earlier operations. As that's hard, at least a comment is needed to clarify
that not doing so is intentional.

> --- a/xen/arch/x86/x86_emulate/blk.c
> +++ b/xen/arch/x86/x86_emulate/blk.c
> @@ -17,6 +17,29 @@
>  # endif
>  #endif
>  
> +#if defined(__XEN__) && !defined(X86EMUL_NO_FPU)
> +static struct xstate_lbr *
> +x86_translate_lbr(struct x86_emulate_state *s,
> +                  struct x86_emulate_ctxt *ctxt,
> +                  const struct segment_register *cs,
> +                  bool saving,
> +                  struct xstate_lbr *lbr)
> +{
> +    uint64_t cs_offset;
> +    uint32_t i;

As per the earlier comment: While for cs_offset a fixed width type may be
justifiable (I would expect it to be a signed type, though), for i it
pretty certainly isn't.

> +    

Nit: No trailing blanks anywhere, please.

> +    cs_offset = x86_get_lbr_cs_offset(ctxt->cpuid, mode_64bit(), cs, saving);

Both callers avoid calling here when mode_64bit() is true. Why would you
nevertheless invoke that function here again? (See also the other, related
comment.)

> +    lbr->ler_from_ip += cs_offset;
> +    lbr->ler_to_ip += cs_offset;
> +    for ( i = 0; i < ctxt->xsaves.lbr_depth; i++ )
> +    {
> +        lbr->entries[i].lbr_from_ip += cs_offset;
> +        lbr->entries[i].lbr_to_ip += cs_offset;
> +    }
> +    return lbr;
> +}
> +#endif
> +
>  int x86_emul_blk(
>      void *ptr,
>      void *data,
> @@ -373,6 +396,125 @@ int x86_emul_blk(
>          }
>          break;
>  
> +/*
> + * XSAVES/XRSTORS emulation uses the host's XSS instructions and therefore
> + * can't be used in an usermode emulator.
> + */
> +#if defined(__XEN__) && !defined(X86EMUL_NO_FPU)

Seeing the comment here, to add to my related comment elsewhere: While you
can't invoke XSAVES/XRSTORS in usermode code, you can still mimic enough
of them using XSAVEC/XRSTOR to facilitate a reasonable level of testing. If
need be you can even (partly) deal with the new enumerators in
test_x86_emulator.c's blk() directly, rather than leaving (all of) it to
x86_emul_blk(). This may (see my comments on the commit message) even end
up easier if you have proper support for XSAVEC/XRSTOR first.

> +#define _xrstors(pfx, mem, eax, edx, faulted) \
> +        asm volatile ( "1: .byte " pfx "0x0f,0xc7,0x1f\n" \
> +                       "3:\n" \
> +                       "   .section .fixup,\"ax\"\n" \
> +                       "2: incl %[faulted]\n" \
> +                       "   jmp 3b\n" \
> +                       "   .previous\n" \
> +                       _ASM_EXTABLE(1b, 2b) \
> +                       : "+m" (*mem), [faulted] "+g" (faulted) \
> +                       : "a" (eax), "d" (edx), "D" (mem) )
> +#define _xsaves(pfx, mem, eax, edx, faulted) \
> +        asm volatile ( "1: .byte " pfx "0x0f,0xc7,0x2f\n" \
> +                       "3:\n" \
> +                       "   .section .fixup,\"ax\"\n" \
> +                       "2: incl %[faulted]\n" \
> +                       "   jmp 3b\n" \
> +                       "   .previous\n" \
> +                       _ASM_EXTABLE(1b, 2b) \
> +                       : "+m" (*mem), [faulted] "+g" (faulted) \
> +                       : "a" (eax), "d" (edx), "D" (mem) )
> +
> +    case blk_xrstors:
> +    {
> +        struct xsave_struct *xstate = ptr;
> +        unsigned int faulted;

bool?

> +        ASSERT(!data);
> +
> +        if ( ctxt->xsaves.rfbm & xstate->xsave_hdr.xcomp_bv & X86_XSS_LBR )
> +        {
> +            struct xstate_lbr *lbr;
> +
> +            lbr = get_xstate_component_comp(xstate, bytes, X86_XSS_LBR);
> +            generate_exception_if(!lbr, X86_EXC_GP, 0);
> +            if ( xstate->xsave_hdr.xstate_bv & X86_XSS_LBR )
> +            {
> +                generate_exception_if(lbr->lbr_ctl & ~LBR_CTL_VALID,
> +                                      X86_EXC_GP, 0);
> +                generate_exception_if(lbr->lbr_depth == 0 ||
> +                                      lbr->lbr_depth >
> +                                       NUM_MSR_ARCH_LBR_FROM_TO ||
> +                                      lbr->lbr_depth % 8 != 0,
> +                                      X86_EXC_GP, 0);
> +
> +                if ( !mode_64bit() )
> +                    x86_translate_lbr(s, ctxt, data, false, lbr);
> +                ctxt->xsaves.lbr_ctl = lbr->lbr_ctl;
> +                ctxt->xsaves.lbr_depth = lbr->lbr_depth;
> +                lbr->lbr_ctl = 0;
> +            }
> +            else
> +            {
> +                ctxt->xsaves.lbr_ctl = 0;
> +                /* Don't touch the previous LBR depth */
> +            }
> +        }
> +
> +        faulted = 0;
> +        if ( s->rex_prefix & REX_W )
> +            _xrstors("0x48,", xstate, ctxt->xsaves.rfbm & UINT32_MAX,
> +                     ctxt->xsaves.rfbm >> 32, faulted);
> +        else
> +            _xrstors("", xstate, ctxt->xsaves.rfbm & UINT32_MAX,
> +                     ctxt->xsaves.rfbm >> 32, faulted);

Personally I don't think UINT32_MAX is suitable for use as a mask. Imo
this wants to be a cast to uint32_t, which will also permit the
compiler to generate marginally better code.

> +        generate_exception_if(faulted, X86_EXC_GP, 0);

This ought to be only a safety net; you want to check _all_ fault
conditions (for all enabled components) in software.

> --- a/xen/arch/x86/x86_emulate/private.h
> +++ b/xen/arch/x86/x86_emulate/private.h
> @@ -295,6 +295,10 @@ struct x86_emulate_state {
>          blk_fxsave,
>  #endif
>          blk_movdir,
> +#ifndef X86EMUL_NO_FPU
> +        blk_xrstors,
> +        blk_xsaves,
> +#endif
>      } blk;
>      uint8_t modrm, modrm_mod, modrm_reg, modrm_rm;
>      uint8_t sib_index, sib_scale;
> @@ -537,6 +541,7 @@ amd_like(const struct x86_emulate_ctxt *ctxt)
>  #define vcpu_has_avx()         (ctxt->cpuid->basic.avx)
>  #define vcpu_has_f16c()        (ctxt->cpuid->basic.f16c)
>  #define vcpu_has_rdrand()      (ctxt->cpuid->basic.rdrand)
> +#define vcpu_has_lbr_lip()     (ctxt->cpuid->basic.lbr_1Ca.ip_contains_lip)

This reads odd, likely indicating a problem earlier in the series (I may
even have commented there): With leaf 1c being the LBR leaf, the above
ought to read

#define vcpu_has_lbr_lip()     (ctxt->cpuid->lbr.ip_contains_lip)

imo.

> --- a/xen/arch/x86/x86_emulate/util-xen.c
> +++ b/xen/arch/x86/x86_emulate/util-xen.c
> @@ -96,6 +96,20 @@ bool cf_check x86_insn_is_cr_access(const struct x86_emulate_state *s,
>      return false;
>  }
>  
> +bool cf_check x86_insn_is_xsaves(const struct x86_emulate_state *s,
> +                                 const struct x86_emulate_ctxt *ctxt)
> +{
> +    return ctxt->opcode == X86EMUL_OPC(0x0f, 0xc7) && s->ea.type == OP_MEM &&
> +           (s->modrm_reg & 7) == 5;
> +}
> +
> +bool cf_check x86_insn_is_xrstors(const struct x86_emulate_state *s,
> +                                  const struct x86_emulate_ctxt *ctxt)
> +{
> +    return ctxt->opcode == X86EMUL_OPC(0x0f, 0xc7) && s->ea.type == OP_MEM &&
> +           (s->modrm_reg & 7) == 3;
> +}

I can't spot any use of these two functions. Why are they being added here?
(Recall that unused functions constitute Misra violations. Plus we surely
don't want cf_check functions - i.e. more ENDBR instances - when they aren't
used.)

> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -8592,6 +8592,25 @@ int x86_emul_rmw(
>  }
>  #undef stub_exn
>  
> +uint64_t x86_get_lbr_cs_offset(const struct cpu_policy *cp,
> +                               bool is_long_mode,
> +                               const struct segment_register *cs,
> +                               bool saving)
> +{
> +    bool host_lip, guest_lip;
> +    
> +    host_lip = current_cpu_has_lbr_lip;
> +    guest_lip = !!cp->basic.lbr_1Ca.ip_contains_lip;
> +
> +    if ( host_lip == guest_lip || is_long_mode )
> +        return 0;
> +    else if ( (host_lip && !guest_lip && saving) ||
> +              (!host_lip && guest_lip && !saving) )
> +        return -cs->base;
> +    else
> +        return cs->base;
> +}

This function is pretty certainly misplaced here. In fact I don't see
why it would need living under x86_emulate/ at all.

Also can you please avoid the use of "else" in cases like these (where
the earlier if() ends in a control flow statement)?

And then I question the is_long_mode parameter: Wouldn't it make sense
to have callers simply avoid the call for long mode environments? Yet
then the doc says nothing about long mode being special. Calls here may
be avoided for 64-bit mode environments, but afaict not for compat mode
ones.

Finally - no need for !! when the lhs is of type bool.

> --- a/xen/arch/x86/x86_emulate/x86_emulate.h
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.h
> @@ -534,6 +534,10 @@ struct x86_emulate_ops
>      /* vmfunc: Emulate VMFUNC via given set of EAX ECX inputs */
>      int (*vmfunc)(
>          struct x86_emulate_ctxt *ctxt);
> +
> +    int (*set_lbr_depth)(
> +        uint32_t depth,
> +        struct x86_emulate_ctxt *ctxt);
>  };
>  
>  struct cpu_user_regs;
> @@ -572,6 +576,22 @@ struct x86_emulate_ctxt
>      /* Long mode active? */
>      bool lma;
>  
> +    struct {
> +        /* In */
> +        uint64_t rfbm;
> +        unsigned int size;
> +        /* Inout */
> +        /*
> +         * MSR_LBR_{CTL,DEPTH} don't match guest state, so we need to pass
> +         * them to the emulator.
> +         */
> +        uint64_t lbr_ctl;
> +        uint64_t lbr_depth;
> +        /* Out */
> +        /* XRSTORS */
> +        uint64_t xstate_bv;
> +    } xsaves;

If any of this is really needed (see at least one comment further up),
this is the wrong structure to put the data in. Anything here is input /
output for callers of x86_emulate(). The interface to the ->blk() hook,
otoh, is internal to the emulator, and hence any associated data wants to
go into struct x86_emulate_state.

Yet even then a question would be whether adding to that structure is
actually necessary. There is the "data" parameter of the hook, after all,
which right now is unused for the two new enumerators.

All of the criticism aside, let me say that I'm impressed that you dared
to touch the emulator code, even more so for a rather complicated area.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 10:26:04 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 10:26:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875309.1285750 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taBSK-0006N0-Aa; Tue, 21 Jan 2025 10:26:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875309.1285750; Tue, 21 Jan 2025 10:26:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taBSK-0006Mt-81; Tue, 21 Jan 2025 10:26:00 +0000
Received: by outflank-mailman (input) for mailman id 875309;
 Tue, 21 Jan 2025 10:25:59 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=fb3U=UN=darkstar.site=sakib@srs-se1.protection.inumbo.net>)
 id 1taBSJ-0006Mk-2S
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 10:25:59 +0000
Received: from fforwardh-b2-smtp.messagingengine.com
 (fforwardh-b2-smtp.messagingengine.com [202.12.124.197])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1a301b33-d7e2-11ef-a0e4-8be0dac302b0;
 Tue, 21 Jan 2025 11:25:58 +0100 (CET)
Received: from phl-compute-10.internal (phl-compute-10.phl.internal
 [10.202.2.50])
 by mailfforwardh.stl.internal (Postfix) with ESMTP id B310C174028A;
 Tue, 21 Jan 2025 05:25:56 -0500 (EST)
Received: from phl-frontend-01 ([10.202.2.160])
 by phl-compute-10.internal (MEProxy); Tue, 21 Jan 2025 05:25:57 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 21 Jan 2025 05:25:55 -0500 (EST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1a301b33-d7e2-11ef-a0e4-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:date:date:feedback-id:feedback-id:from:from
	:in-reply-to:in-reply-to:message-id:mime-version:references
	:reply-to:subject:subject:to:to:x-me-proxy:x-me-sender
	:x-me-sender:x-sasl-enc; s=fm3; t=1737455156; x=1737541556; bh=r
	kkiqbSwc6jmF2J2ez5nWu827Q/H2UnBXmYuGwWx5kg=; b=MXPKNXlkB+7ZSX6ff
	P8KCCIwBFR4cdpTIx9skAfPBsStA31IhWEcTe+7IWnJpxmdSQMqXHfPfdmGjm8lX
	j3JsTful9BhQGU1omBizN7D3nv2MwQECD/eMvXxR+I/kIIYiOK1NOIEKP5UBgxie
	Eh/g9vh9DIURKMaEJP2pL0vDltEQ2IK8a2X8dFJC8KoZRl6Q0BNNvYR+ntN3OtqN
	CmMPqF/FEkCS7c2N3B3RzhTVn1QVv718RzsOBLndW++urZGE7kflO+OK40a4u6Lx
	X/AxEZNhm6tJkogQGFc01qkTgDrV+Elv/QBdDqUmU1nU+kssStLLrqSs0pfNT91Y
	a5Inw==
X-ME-Sender: <xms:NHaPZyUePAwdK2dnk5NYu5SlFC0FxB51LpKRuz2A5KqtRiNmdVXrvA>
    <xme:NHaPZ-kvwGCk3DPCWVMnYoM4wecfOoH24oyLAInsCZ9eaLUGPIC94ep0DFFoCpg3X
    bjVH14goWq-QKGTavY>
X-ME-Received: <xmr:NHaPZ2YUDA1RnYsb24DjyoQySGEilR0N2L8FLM8ZArcqNhyZMGUZz3SZOwvnK3stqvzwgjWfUShx3cHzzbWxjL3KxKcScoTMcpp2Gjzg5rk2ZV3h>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrudejuddgudehucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
    rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
    htshculddquddttddmnecujfgurhephffvvefufffkofgjfhgggfestdekredtredttden
    ucfhrhhomhepufgvrhhgihihucfmihgsrhhikhcuoefuvghrghhihigpmfhisghrihhkse
    gvphgrmhdrtghomheqnecuggftrfgrthhtvghrnheptdejgeegvdffkeekleefueevgfdu
    heevkedvhfdvkeeludehleegheeivedugfejnecuvehluhhsthgvrhfuihiivgeptdenuc
    frrghrrghmpehmrghilhhfrhhomhepshgrkhhisgesuggrrhhkshhtrghrrdhsihhtvgdp
    nhgspghrtghpthhtohepudeipdhmohguvgepshhmthhpohhuthdprhgtphhtthhopeigvg
    hnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdprhgtphhtthho
    pehsthgvfhgrnhhordhsthgrsggvlhhlihhnihesrghmugdrtghomhdprhgtphhtthhope
    hjuhhlihgvnhesgigvnhdrohhrghdprhgtphhtthhopegsvghrthhrrghnugdrmhgrrhhq
    uhhishesrghrmhdrtghomhdprhgtphhtthhopehmihgthhgrlhdrohhriigvlhesrghmug
    drtghomhdprhgtphhtthhopehvohhlohguhihmhihrpggsrggstghhuhhksegvphgrmhdr
    tghomhdprhgtphhtthhopegrnhgurhgvfidrtghoohhpvghrfeestghithhrihigrdgtoh
    hmpdhrtghpthhtoheprghnthhhohhnhidrphgvrhgrrhgusehvrghtvghsrdhtvggthhdp
    rhgtphhtthhopehrohhgvghrrdhprghusegtihhtrhhigidrtghomh
X-ME-Proxy: <xmx:NHaPZ5W_Y-9IgPdL6bHJh0LAhI0_hPVOBIaOJ5BA81EB4AoPo2Q9uw>
    <xmx:NHaPZ8k0OJsE5U53mYW1o2OWQhnDIREwaSeUwrJHN_FeK3K2Z3TixQ>
    <xmx:NHaPZ-erjQ4lcQCWNEQtmBXAeXqgSpGOm9Rq62bM1eVZoQXhDqWsEg>
    <xmx:NHaPZ-FMVbjiUBjinjT7VK_Br-OV2VvL1mXuYH6h240Su6KQRRO0BA>
    <xmx:NHaPZ6mugCXs6jtlEXvTURl-GlxNbGbN4G8cxtw-09T7lU8VZvHnDA>
    <xmx:NHaPZwkaSjgOfz8lf8MWyaJOH3yS1PyLIIhdmo6_xui2Ns9fuf_KDhAGg5rf>
Feedback-ID: i7de5e997:Fastmail
From: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <stefano.stabellini@amd.com>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Alexandru Isaila <aisaila@bitdefender.com>,
	Petre Pircalabu <ppircalabu@bitdefender.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Jan Beulich <jbeulich@suse.com>,
	Tamas K Lengyel <tamas@tklengyel.com>,
	Ayan Kumar Halder <ayan.kumar.halder@amd.com>,
	Sergiy Kibrik <Sergiy_Kibrik@epam.com>
Subject: [PATCH v2 4/4] xen: mem_access: conditionally compile vm_event.c & monitor.c
Date: Tue, 21 Jan 2025 12:25:53 +0200
Message-Id: <2e8b9c5390019ef66610a21d9a8744282e2badeb.1737452864.git.Sergiy_Kibrik@epam.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <cover.1737452864.git.Sergiy_Kibrik@epam.com>
References: <cover.1737452864.git.Sergiy_Kibrik@epam.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Stefano Stabellini <stefano.stabellini@amd.com>

Extend coverage of CONFIG_VM_EVENT option and make the build of VM events
and monitoring support optional.
This is to reduce code size on Arm when this option isn't enabled.

CC: Jan Beulich <jbeulich@suse.com>
CC: Tamas K Lengyel <tamas@tklengyel.com>
Reviewed-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
---
changes in v2:
 - rename CONFIG_MEM_ACCESS -> CONFIG_VM_EVENT
 - tags
---
 xen/arch/arm/Makefile      |  4 ++--
 xen/arch/arm/vsmc.c        |  3 ++-
 xen/common/Makefile        |  4 ++--
 xen/include/xen/monitor.h  |  9 +++++++++
 xen/include/xen/vm_event.h | 14 +++++++++++---
 5 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index ad29316df1..e61238c4d0 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -39,7 +39,7 @@ obj-$(CONFIG_LIVEPATCH) += livepatch.o
 obj-$(CONFIG_LLC_COLORING) += llc-coloring.o
 obj-$(CONFIG_VM_EVENT) += mem_access.o
 obj-y += mm.o
-obj-y += monitor.o
+obj-$(CONFIG_VM_EVENT) += monitor.o
 obj-y += p2m.o
 obj-y += platform.o
 obj-y += platform_hypercall.o
@@ -65,7 +65,7 @@ obj-$(CONFIG_VGICV2) += vgic-v2.o
 obj-$(CONFIG_GICV3) += vgic-v3.o
 obj-$(CONFIG_HAS_ITS) += vgic-v3-its.o
 endif
-obj-y += vm_event.o
+obj-$(CONFIG_VM_EVENT) += vm_event.o
 obj-y += vtimer.o
 obj-$(CONFIG_SBSA_VUART_CONSOLE) += vpl011.o
 obj-y += vsmc.o
diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index 62d8117a12..1ea75cd7f1 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -330,7 +330,8 @@ void do_trap_smc(struct cpu_user_regs *regs, const union hsr hsr)
     }
 
     /* If monitor is enabled, let it handle the call. */
-    if ( current->domain->arch.monitor.privileged_call_enabled )
+    if ( IS_ENABLED(CONFIG_VM_EVENT) &&
+         current->domain->arch.monitor.privileged_call_enabled )
         rc = monitor_smc();
 
     if ( rc == 1 )
diff --git a/xen/common/Makefile b/xen/common/Makefile
index b71d4b3efa..ac23120d7d 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -54,7 +54,7 @@ obj-y += timer.o
 obj-$(CONFIG_TRACEBUFFER) += trace.o
 obj-y += version.o
 obj-y += virtual_region.o
-obj-y += vm_event.o
+obj-$(CONFIG_VM_EVENT) += vm_event.o
 obj-$(CONFIG_HAS_VMAP) += vmap.o
 obj-y += vsprintf.o
 obj-y += wait.o
@@ -68,7 +68,7 @@ obj-$(CONFIG_COMPAT) += $(addprefix compat/,domain.o memory.o multicall.o xlat.o
 
 ifneq ($(CONFIG_PV_SHIM_EXCLUSIVE),y)
 obj-y += domctl.o
-obj-y += monitor.o
+obj-$(CONFIG_VM_EVENT) += monitor.o
 obj-y += sysctl.o
 endif
 
diff --git a/xen/include/xen/monitor.h b/xen/include/xen/monitor.h
index 713d54f7c1..afb582bc26 100644
--- a/xen/include/xen/monitor.h
+++ b/xen/include/xen/monitor.h
@@ -27,8 +27,17 @@
 struct domain;
 struct xen_domctl_monitor_op;
 
+#ifdef CONFIG_VM_EVENT
 int monitor_domctl(struct domain *d, struct xen_domctl_monitor_op *mop);
 void monitor_guest_request(void);
+#else
+static inline int monitor_domctl(struct domain *d,
+                                 struct xen_domctl_monitor_op *mop)
+{
+    return -EINVAL;
+}
+static inline void monitor_guest_request(void) {}
+#endif
 
 int monitor_traps(struct vcpu *v, bool sync, vm_event_request_t *req);
 
diff --git a/xen/include/xen/vm_event.h b/xen/include/xen/vm_event.h
index 9a86358b42..268c85fc4f 100644
--- a/xen/include/xen/vm_event.h
+++ b/xen/include/xen/vm_event.h
@@ -50,9 +50,6 @@ struct vm_event_domain
     unsigned int last_vcpu_wake_up;
 };
 
-/* Clean up on domain destruction */
-void vm_event_cleanup(struct domain *d);
-
 /* Returns whether a ring has been set up */
 bool vm_event_check_ring(struct vm_event_domain *ved);
 
@@ -88,7 +85,18 @@ void vm_event_cancel_slot(struct domain *d, struct vm_event_domain *ved);
 void vm_event_put_request(struct domain *d, struct vm_event_domain *ved,
                           vm_event_request_t *req);
 
+#ifdef CONFIG_VM_EVENT
+/* Clean up on domain destruction */
+void vm_event_cleanup(struct domain *d);
 int vm_event_domctl(struct domain *d, struct xen_domctl_vm_event_op *vec);
+#else
+static inline void vm_event_cleanup(struct domain *d) {}
+static inline int vm_event_domctl(struct domain *d,
+                                  struct xen_domctl_vm_event_op *vec)
+{
+    return -EINVAL;
+}
+#endif
 
 void vm_event_vcpu_pause(struct vcpu *v);
 void vm_event_vcpu_unpause(struct vcpu *v);
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Tue Jan 21 10:29:17 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 10:29:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875320.1285760 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taBVT-0006xK-O7; Tue, 21 Jan 2025 10:29:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875320.1285760; Tue, 21 Jan 2025 10:29:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taBVT-0006xD-LR; Tue, 21 Jan 2025 10:29:15 +0000
Received: by outflank-mailman (input) for mailman id 875320;
 Tue, 21 Jan 2025 10:29: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 <SRS0=Gode=UN=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1taBVS-0006x7-Qa
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 10:29:14 +0000
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com
 [2a00:1450:4864:20::431])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8f2cc152-d7e2-11ef-a0e4-8be0dac302b0;
 Tue, 21 Jan 2025 11:29:13 +0100 (CET)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-385ddcfc97bso4443527f8f.1
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 02:29: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
 ffacd0b85a97d-38bf328dc08sm12843697f8f.101.2025.01.21.02.29.12
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 21 Jan 2025 02:29:12 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8f2cc152-d7e2-11ef-a0e4-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737455353; x=1738060153; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=I4jtW+0BcJwoVm13t0cc/7gcNYaVWCPs6eP3Jj7dJLw=;
        b=VuCTd+9O0n8/pCP7ZvYTTK3jECPQQUFMoqymhqjiQbJhoyvzzGYbO5B8XFoGJnSbPW
         dU2JK0ZgsBkORMdL7PuV8TJCecWGb1C03vE2EW4rE5fo2njXTN2r/kZ6+ryfG1CFXbQk
         0w6GMd/wKcE2k0yNpv4SB4YSuGcnIpqMJuAKPqjkdLjjtmwRQ0zbiER3AOZEBHUgNdwN
         FJSoRRsnnZhY5fjMam+vMFPCYSMworNdKvx8ya0/xt/SQK/z96kN84sa1p7Iq7jFHqHo
         Xd78UcukSnYUaIBeLdAWIClnqjBqeYNDIHrLFCmEQHQEf8KuEI6XcjddqL21c5QybqYC
         4thQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737455353; x=1738060153;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=I4jtW+0BcJwoVm13t0cc/7gcNYaVWCPs6eP3Jj7dJLw=;
        b=XeCDebHr3lXo/GB/NBg2ISkYEcG7MDClUgRMw2EHQQDSTKNFjzhmhQ1c/vDg+WfUEz
         zTyF0Yt00S7v/4feyQFBMDzckWw3kDVzUFQOdUemc5lhBhKpHft2D6+WWlHZYxUa34RV
         zYike1ud9M4ogn6E4T+tN7KI66VyRakBi1Hkgu5iSbnFRrFPCnhY2sqTIAwsbQdyF2US
         rNUUQWSv3IS4956GhhhJ7bJQUatwnHzmpiyqs9iaxzncP4X6JqeUA8gJUBp2Vq1eAT+C
         ma0w2ugUQ7QLXnJOwRkF2amftnbcjsqBM4BBOiYjmTj7J1q8yPo0/qE2wvArdxOwp5qf
         OWHw==
X-Gm-Message-State: AOJu0YySXn/hDdrjeWIqrQkwefA716pMNsNanMjdwxMIsTspRaTdtn4m
	n5YYc3ma5Wbi0rOa1E7r2BPx1DitSvJSy0JaFjdU1jXPc42lsG8/RDg6vYgnl515PCEbMjRuIYE
	=
X-Gm-Gg: ASbGncsjCSoV/FhzVnkNiTA9Wi+Ohp5bGalE/mmAUVtS2tNAsF70YUVqDYnFVtPl/uc
	dEyKBX/E4UV4cWFH4dFuWNBdxIvA2UMR9a1qRMBHWNMpRF+XfchpKytffydjX0HUb8ow97WZlCl
	hJhVYoGbDQn4f12ZckfbtO/JbLiUc4+zIMkEGLbkywLR1w75NGl7fVHqsGDFL7wIvqG7D3s2Vq4
	YhrLJXVY+jC2pLExplI2wmoDi1Fhrtz9kCfwmxn9yBEjOTh29kf9b2Zx93+exch4S/KD/GluDua
	FEtEgC/eauOhG+WDpcmtS+AgEYMW1bwLVwF2BQ1ZaN8l3TFF0c7Vkc0=
X-Google-Smtp-Source: AGHT+IE9691+oHqNROIHVaOcjH/0jHIlSsU0MtBcaZThA9I9rKl868Q6mGlU1j9xGgs/oIrYSJYW6g==
X-Received: by 2002:a5d:5848:0:b0:38b:e1b3:16dc with SMTP id ffacd0b85a97d-38bf57d339amr14639342f8f.50.1737455353231;
        Tue, 21 Jan 2025 02:29:13 -0800 (PST)
Message-ID: <b65a4189-e643-45d3-ac62-25ccc1ffb39a@suse.com>
Date: Tue, 21 Jan 2025 11:29:11 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5] vpci: Add resizable bar support
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 "Chen, Jiqian" <Jiqian.Chen@amd.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>, "Huang, Ray" <Ray.Huang@amd.com>
References: <20250114032636.3698383-1-Jiqian.Chen@amd.com>
 <Z49e8NmROzke-tYc@macbook.local>
 <BL1PR12MB58492016DDBB106A607F32CDE7E62@BL1PR12MB5849.namprd12.prod.outlook.com>
 <Z49o4iyY7vPhz2ow@macbook.local>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <Z49o4iyY7vPhz2ow@macbook.local>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 21.01.2025 10:29, Roger Pau Monné wrote:
> On Tue, Jan 21, 2025 at 09:10:26AM +0000, Chen, Jiqian wrote:
>> On 2025/1/21 16:46, Roger Pau Monné wrote:
>>> On Tue, Jan 14, 2025 at 11:26:36AM +0800, Jiqian Chen wrote:
>>>> +    ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL(0));
>>>> +    nbars = MASK_EXTR(ctrl, PCI_REBAR_CTRL_NBAR_MASK);
>>>> +    for ( unsigned int i = 0; i < nbars; i++ )
>>>> +    {
>>>> +        int rc;
>>>> +        struct vpci_bar *bar;
>>>> +        unsigned int index;
>>>> +
>>>> +        ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL(i));
>>>> +        index = ctrl & PCI_REBAR_CTRL_BAR_IDX;
>>>> +        if ( index >= PCI_HEADER_NORMAL_NR_BARS )
>>>> +        {
>>>> +            printk(XENLOG_ERR "%pd %pp: too big BAR number %u in REBAR_CTRL\n",
>>>> +                   pdev->domain, &pdev->sbdf, index);
>>>> +            continue;
>>>> +        }
>>>> +
>>>> +        bar = &pdev->vpci->header.bars[index];
>>>> +        if ( bar->type != VPCI_BAR_MEM64_LO && bar->type != VPCI_BAR_MEM32 )
>>>> +        {
>>>> +            printk(XENLOG_ERR "%pd %pp: BAR%u is not in memory space\n",
>>>> +                   pdev->domain, &pdev->sbdf, index);
>>>> +            continue;
>>>> +        }
>>>> +
>>>> +        rc = vpci_add_register(pdev->vpci, vpci_hw_read32, vpci_hw_write32,
>>>> +                               rebar_offset + PCI_REBAR_CAP(i), 4, NULL);
>>>> +        if ( rc )
>>>> +        {
>>>> +            /*
>>>> +             * TODO: for failed pathes, need to hide ReBar capability
>>>> +             * from hardware domain instead of returning an error.
>>>> +             */
>>>> +            printk(XENLOG_ERR "%pd %pp: fail to add reg of REBAR_CAP rc=%d\n",
>>>> +                   pdev->domain, &pdev->sbdf, rc);
>>>> +            return rc;
>>>> +        }
>>>> +
>>>> +        rc = vpci_add_register(pdev->vpci, vpci_hw_read32, rebar_ctrl_write,
>>>> +                               rebar_offset + PCI_REBAR_CTRL(i), 4, bar);
>>>> +        if ( rc )
>>>> +        {
>>>> +            printk(XENLOG_ERR "%pd %pp: fail to add reg of REBAR_CTRL rc=%d\n",
>>>> +                   pdev->domain, &pdev->sbdf, rc);
>>>> +            return rc;
>>>
>>> I think we said we wanted to attempt to continue here, rather than
>>> returning an error and thus removing all vPCI handlers from the
>>> device?
>> I thought the result of your discussion with Jan was that I only needed to change the above two error paths to be "continue".
>> If these two also need to be changed, I will modify them in the next version.
> 
> Hm, let's wait for Jan to confirm, but even if handler cannot be setup
> for some of the registers, it's better than just allowing dom0
> unmediated access to the capability.

I remained silent on this because I accepted this middle ground as ...

> None of this is ideal, but it seems to be the option that gives dom0
> most options to successfully boot.

... perhaps the most reasonable compromise.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 10:29:57 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 10:29:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875328.1285771 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taBW9-0007Rh-0L; Tue, 21 Jan 2025 10:29:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875328.1285771; Tue, 21 Jan 2025 10:29:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taBW8-0007RY-Tb; Tue, 21 Jan 2025 10:29:56 +0000
Received: by outflank-mailman (input) for mailman id 875328;
 Tue, 21 Jan 2025 10:29:55 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=abyW=UN=cloud.com=ross.lagerwall@srs-se1.protection.inumbo.net>)
 id 1taBW7-0007Fn-RH
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 10:29:55 +0000
Received: from mail-oa1-x2f.google.com (mail-oa1-x2f.google.com
 [2001:4860:4864:20::2f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a6d609f6-d7e2-11ef-99a4-01e77a169b0f;
 Tue, 21 Jan 2025 11:29:54 +0100 (CET)
Received: by mail-oa1-x2f.google.com with SMTP id
 586e51a60fabf-2addd5053c0so3398842fac.1
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 02:29:54 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a6d609f6-d7e2-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737455393; x=1738060193; 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=kWiYWjwnCXUKr9k4usiiB0rss/xJcUGQqbM6feFrsug=;
        b=cnEaoMuJg/ixS4axvfmQBYfwH0jCIhdS6nJr18/0/8sF1L27o8QCh1GmOH/wtiQTcu
         LPQIzDd0ZwlS3AhsfU6LazaXY51Vod4KX443dBl0XsZo1PnoJlTVnzO8tHDabbpreucq
         4Ju++iUdQLylSV4qcztfTm6YQ9vUD5PWV4L5E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737455393; x=1738060193;
        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=kWiYWjwnCXUKr9k4usiiB0rss/xJcUGQqbM6feFrsug=;
        b=OZT1RshJzfYT42ZkrKLg8AxwHJkljgPT8PpNUBGQhsFYKQXodTAT9RRR9u3XN5sYCg
         9kdgLVwatli8f8oRM7Dz0H+zYoffQukBOcxaFmF2mHXLJSHd4noQ9bkJFin7uHIfzKe4
         9HIVAn7mitTVlHuA+r4o7vE41VWQ+fEzUJOgd7Hn3dSK1V6qQFutNZZ+JIZR2Lt76kJk
         N7ptNPI6m68wUtdmhq2C3SY7L1x+4RSJFSx4q3gTBzn40oOTOyyjJ/AEYEr7wtdoVI5R
         G5PSLjG01cnRXLTOAWqiNSckjKd0JPZAnByugP03heeoj/6Wktdvd6IA8WiPcFaEoOqS
         +iPg==
X-Gm-Message-State: AOJu0Yw/xGfg5bwQiOYjKx5VZURl31vZTVvaUZ6nb3UVKforXU+JiWcg
	0C5gZEZ/9dJR1r4FUahLdA3aUcrOg7mRaT02Jo5tBv5cdA4MsdQOPFrO2HOY8UeYs4KUonT+6WZ
	zelikgwuxRsc++8/gnwnLAMxNtPAktbNZNo8N
X-Gm-Gg: ASbGncvaAerOPzdKYdexk7rvViK7F37GVOF4iEv2uFi+5TMHat+SjEIC+1M4RTbBY8q
	9pjpaUX0HbbW0fwZpuF9sPuWeNpo6a9Y07GSH831iyFel3fVjQA==
X-Google-Smtp-Source: AGHT+IGaruOW/5zSMu2hyoQWZXuQ5XCBUG4Vv51k8BwSY9sKGHEXq80WCeEZAnxH4Rro1NWmL+thvOgwKk+z+FtEPfQ=
X-Received: by 2002:a05:6870:e2cf:b0:29e:76c8:be2e with SMTP id
 586e51a60fabf-2b1c0b08182mr10701735fac.28.1737455392787; Tue, 21 Jan 2025
 02:29:52 -0800 (PST)
MIME-Version: 1.0
References: <20241107151509.73621-1-roger.pau@citrix.com> <20241107151509.73621-2-roger.pau@citrix.com>
In-Reply-To: <20241107151509.73621-2-roger.pau@citrix.com>
From: Ross Lagerwall <ross.lagerwall@citrix.com>
Date: Tue, 21 Jan 2025 10:29:42 +0000
X-Gm-Features: AbW1kvbNEHrIjVeApohhmIFZ25M0TGPc25YkDyxr3G-xCDZgOtMIIKs-uGrJycI
Message-ID: <CAG7k0EoemEjzaHnDSnDhLAeuJOiuJBu9QxsimSXrA9Nu3FNktw@mail.gmail.com>
Subject: Re: [PATCH 1/4] livepatch-build: allow patch file name sizes up to
 127 characters
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: xen-devel@lists.xenproject.org, konrad.wilk@oracle.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Nov 7, 2024 at 3:15=E2=80=AFPM Roger Pau Monne <roger.pau@citrix.co=
m> wrote:
>
> XenServer uses quite long Xen version names, and encode such in the livep=
atch
> filename, and it's currently running out of space in the file name.
>
> Bump max filename size to 127, so it also matches the patch name length i=
n the
> hypervisor interface.  Note the size of the buffer is 128 characters, and=
 the
> last one is reserved for the null terminator.
>
> Signed-off-by: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
> ---
> Changes since v1:
>  - Take into account the null terminator.
> ---
>  livepatch-build | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/livepatch-build b/livepatch-build
> index 948b2acfc2f6..f3ca9399d149 100755
> --- a/livepatch-build
> +++ b/livepatch-build
> @@ -72,8 +72,9 @@ function make_patch_name()
>      fi
>
>      # Only allow alphanumerics and '_' and '-' in the patch name.  Every=
thing
> -    # else is replaced with '-'.  Truncate to 48 chars.
> -    echo ${PATCHNAME//[^a-zA-Z0-9_-]/-} |cut -c 1-48
> +    # else is replaced with '-'.  Truncate to 127 chars
> +    # (XEN_LIVEPATCH_NAME_SIZE - 1).
> +    echo ${PATCHNAME//[^a-zA-Z0-9_-]/-} |cut -c -127
>  }

I think this 48 char limit erroneously came from kpatch / Linux's module
name length limit and is therefore not relevant.

Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>

Thanks


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 10:31:39 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 10:31:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875337.1285780 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taBXk-0000qQ-BC; Tue, 21 Jan 2025 10:31:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875337.1285780; Tue, 21 Jan 2025 10:31:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taBXk-0000qJ-8V; Tue, 21 Jan 2025 10:31:36 +0000
Received: by outflank-mailman (input) for mailman id 875337;
 Tue, 21 Jan 2025 10:31:34 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=abyW=UN=cloud.com=ross.lagerwall@srs-se1.protection.inumbo.net>)
 id 1taBXi-0000qD-NO
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 10:31:34 +0000
Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com
 [2607:f8b0:4864:20::230])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e22dbf30-d7e2-11ef-a0e4-8be0dac302b0;
 Tue, 21 Jan 2025 11:31:33 +0100 (CET)
Received: by mail-oi1-x230.google.com with SMTP id
 5614622812f47-3eb9a0a2089so3453943b6e.1
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 02:31:33 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e22dbf30-d7e2-11ef-a0e4-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737455492; x=1738060292; 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=Co/euGMbvZPpVD/aIJIvyVgoWh6IQMIsE/5p6Qufnrw=;
        b=XKhqt3x8wocvuZz2y6SjY92Vz7axQP7shK+uYWm7uYVludYBGxuQXL1N7OEZbVKxCP
         dCfHjiUUA0wbVTBK9mFFzIWVt8JiPepEz9MR7kSXTjZcpKQ5+XfjgyG3Q6IhAnpycb6n
         FbUd2a7NhiG/K64R/eb+mH24xs3mET++dW6Ys=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737455492; x=1738060292;
        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=Co/euGMbvZPpVD/aIJIvyVgoWh6IQMIsE/5p6Qufnrw=;
        b=nYiRBs+Qh84BvySgkhf2EWIJzixLGHn8ojvgNse3sN/18qQM2xOMGIhpC2x6W09LHt
         pc4dbhShLygp5ZrpG8lpwnkp+oujI0Xc3Bz58ooiLYvEYQ/o3fpcZRV8gcMybVjYs8Gq
         rLPUOB6+ox9+Xvz6SDNnfrALUNkff75d17NzMRsO4hDVkRokC/pF/AsW/G9CT7SjHGQt
         /+UmUVjDmyNwtIWCIXT4Zjya12JIr9wqu9mfWUqBw3GRb2RBltEXmC/vRS+gShiv4SOt
         rfuWjgdoZ8UDgIUCbCoH7oyTbCTmC5/MhqTXdIutHBzbVpWSdkMBnFjzRir71umwQaWS
         KqPA==
X-Gm-Message-State: AOJu0Yw4RwZKxz1fGki8pyLpNorv1N1B6swlu2vM0Di30Nav6mtXHfks
	caJPkLcXMNenOuAvYbOibnnttVb9b5Jo26AIheYOcEO4xVbX+hAA1ksDa3svD/m1NPxST0ISvaA
	Y95N/m8U13KeVm4LZ9NKvHP1IScisrQ+4oY4o
X-Gm-Gg: ASbGncuNIcu1Sg251G2t1FCTqm9p4R6Jl9X2Apxp2nX613ub0J7896b40HQYz2bEEIo
	JOKuEN73LaVOsqoQ4fGNYo/U2OQlU7sMkTsJ7eVqF8u7h0iBCFQ==
X-Google-Smtp-Source: AGHT+IHJJeR3bTH+6yG7GcYJ41sMdptddoz50cPKVxfRUbydK8XPGTonJf67eHUGaXvh0dxCojFNcGmp1LgIN+3d+vU=
X-Received: by 2002:a05:6871:4109:b0:29e:5aa6:2bb3 with SMTP id
 586e51a60fabf-2b1c084189emr8856779fac.1.1737455492389; Tue, 21 Jan 2025
 02:31:32 -0800 (PST)
MIME-Version: 1.0
References: <20241107151509.73621-1-roger.pau@citrix.com> <20241107151509.73621-3-roger.pau@citrix.com>
In-Reply-To: <20241107151509.73621-3-roger.pau@citrix.com>
From: Ross Lagerwall <ross.lagerwall@citrix.com>
Date: Tue, 21 Jan 2025 10:31:21 +0000
X-Gm-Features: AbW1kvZpheZcKA8ggw7-07Zc_w8xthUpQCacK9Es59eCiULPTl_T1kTEqDxx9jE
Message-ID: <CAG7k0Erg1vuVrPgg8XvY_qcQFjKYXGu35c70CMucMSj=7ajpkw@mail.gmail.com>
Subject: Re: [PATCH 2/4] create-diff-object: update default alt_instr size
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: xen-devel@lists.xenproject.org, konrad.wilk@oracle.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Nov 7, 2024 at 3:15=E2=80=AFPM Roger Pau Monne <roger.pau@citrix.co=
m> wrote:
>
> The size of the alt_instr structure in Xen is 14 instead of 12 bytes, adj=
ust
> it.
>
> Signed-off-by: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
> ---
>  create-diff-object.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/create-diff-object.c b/create-diff-object.c
> index fed360a9aa68..d8a2afbf2774 100644
> --- a/create-diff-object.c
> +++ b/create-diff-object.c
> @@ -1000,7 +1000,7 @@ static int altinstructions_group_size(struct kpatch=
_elf *kelf, int offset)
>         char *str;
>         if (!size) {
>                 str =3D getenv("ALT_STRUCT_SIZE");
> -               size =3D str ? atoi(str) : 12;
> +               size =3D str ? atoi(str) : 14;
>         }
>
>         log_debug("altinstr_size=3D%d\n", size);
> --
> 2.46.0
>

Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 10:32:35 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 10:32:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875345.1285791 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taBYh-0001be-KN; Tue, 21 Jan 2025 10:32:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875345.1285791; Tue, 21 Jan 2025 10:32:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taBYh-0001bX-Gs; Tue, 21 Jan 2025 10:32:35 +0000
Received: by outflank-mailman (input) for mailman id 875345;
 Tue, 21 Jan 2025 10:32:34 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=qQWO=UN=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1taBYg-0001bR-JE
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 10:32:34 +0000
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com
 [2a00:1450:4864:20::32d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 05cd2b37-d7e3-11ef-99a4-01e77a169b0f;
 Tue, 21 Jan 2025 11:32:32 +0100 (CET)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-436202dd7f6so62734585e9.0
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 02:32:32 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4389046bab0sm170524625e9.38.2025.01.21.02.32.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 21 Jan 2025 02:32:31 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 05cd2b37-d7e3-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737455552; x=1738060352; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=4QzFt9GYqnwY9aYauCPhmlgp8rdqc3OvPDr0+heicTk=;
        b=oWctKYr3pChIleklC2b/DbLO4I3cwQPro3+Hn+M1QZw8bbzq1XqVij8qC+rVc/3tZ7
         xipaINlF5x0ZmoEXC0kxR+//x0fl4uU/oMBDbPaWzpb7agGNEbEGghHtZuRxcrpLZgsv
         bGRUXvackwfP3LIhzeYpvDKzJw0e7dcWsOhRE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737455552; x=1738060352;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=4QzFt9GYqnwY9aYauCPhmlgp8rdqc3OvPDr0+heicTk=;
        b=VSW7ZBxiNkhOSO/K4FBzZ1fY4Ci75oL97l5h5JPdcojix0GKcxN2q07fTFnAcSWSLe
         mQrk2/uUDHzt5zYz7JN5YPu2QcZ6kD+gY4REXtzB5TL9Spwr3Rgnq0RFmqO15riiAHXM
         65HZSRSS+Skrq25zsDrfpzlRhTwJcviFBMfYHkmalnHJSaFdbceeGXnMY1oI60YgTonY
         6/KP9c7zO3Xke/CbD6tmYYU6PYuTkGQga+cdbTJtB6fzON8vVziznVJhxGqEOjxqixB7
         ld+9mfxDDfTbXWe1RvzRvAUB1+DI7RmZQqOkNtmuDpwGbsyuEpJxVKftr6cS0ATG9/nF
         7NGA==
X-Forwarded-Encrypted: i=1; AJvYcCWldlz2t6D1Qf+01QH/fmwgoBxCIfzTyK3xuEXVHwCIzKWaMA+3U3+Cx9Z/vgxsuprFSpCnwrIS6iM=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywn9yRGhgrqsuMyazr2lCXonAKqiNYBhCLLX/KhM0jhkhYtEso5
	0KYvuZV4c1JRS8KSv9mg4Dim8tLZagRMIsKCg/wwhq3aBdu1LCC7j0MH2csubh4=
X-Gm-Gg: ASbGncvvzQ7/PV4mweatSxKqe8+De6A4tNqbad7TLzhzRRK1cv6sHfiOOM1SOJ4areW
	9r93ZdPATy4AmjnhYAgLDJliGBukXeFZSF0lEtY5JTpOrQ7VmX95u0aGt/rBJpyb8HuwL480edC
	7hPmnGfjG2EGmbMuXtXccfiQ3ggZah2+9FFSGc9pYhUAeu5K9uQ69x0I6dj6eI6ofcpBMb2GHj+
	hW7tr3g8JmBF7Ph5BwP8/Hbgiq/ml21z1D6dgahChrlx/HAoxz+VispjUTUZU0pgxrrO+GlZKHX
	6veNkIG2fNq/oawC2hY1BaMsBHq6wZINPg==
X-Google-Smtp-Source: AGHT+IH/2R1yLXmm0bCeC2YLju5ekfwU1aNWfAVVjKUM2AewxbpZZzrcb/mliNrSPn2Phs0JgjQkcg==
X-Received: by 2002:a05:600c:4fd6:b0:436:18e5:6917 with SMTP id 5b1f17b1804b1-438912d3aa3mr165222155e9.0.1737455552125;
        Tue, 21 Jan 2025 02:32:32 -0800 (PST)
Message-ID: <a1bbceec-e4b3-4ce5-a54e-b3080508f340@citrix.com>
Date: Tue, 21 Jan 2025 10:32:31 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] iommu/amd: atomically update IRTE if supported
To: Roger Pau Monne <roger.pau@citrix.com>, xen-devel@lists.xenproject.org
Cc: Jan Beulich <jbeulich@suse.com>
References: <20250121095704.18769-1-roger.pau@citrix.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <20250121095704.18769-1-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 21/01/2025 9:57 am, Roger Pau Monne wrote:
> If using a 32bit Interrupt Remapping Entry or a 128bit one and the CPU
> supports 128bit cmpxchg don't disable the entry by setting RemapEn = 0
> ahead of updating it.  As a consequence of not toggling RemapEn ahead of
> the update the Interrupt Remapping Table needs to be flushed after the
> entry update.
>
> This avoids a window where the IRTE has RemapEn = 0, which can lead to
> IO_PAGE_FAULT if the underlying interrupt source is not masked.

It's probably worth saying that this race condition was identified in
the field, rather than being a theoretical issue.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 10:35:51 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 10:35:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875356.1285801 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taBbo-0002N4-50; Tue, 21 Jan 2025 10:35:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875356.1285801; Tue, 21 Jan 2025 10:35:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taBbo-0002Mx-12; Tue, 21 Jan 2025 10:35:48 +0000
Received: by outflank-mailman (input) for mailman id 875356;
 Tue, 21 Jan 2025 10:35:46 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Gode=UN=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1taBbm-0002Mr-FS
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 10:35:46 +0000
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com
 [2a00:1450:4864:20::436])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 78114107-d7e3-11ef-99a4-01e77a169b0f;
 Tue, 21 Jan 2025 11:35:44 +0100 (CET)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-385eed29d17so2909364f8f.0
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 02:35:44 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-437c752935csm230629295e9.26.2025.01.21.02.35.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 21 Jan 2025 02:35:43 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 78114107-d7e3-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737455744; x=1738060544; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=iqME+v0CEK8F/LmxoOToHCnJ0x3lcEhnSNs5R3C2FWY=;
        b=Vusj5ranAC6gs37dt4qerhRDY6O8/iYBp+oqT37fBSb98zKHg7JnUEroALsRTJ/CtO
         bcuVgpy2fTsJ+d3Yo2f8PCjKUJ+kCSH+8uuu/RLe03LWLSVw71LL5nafntnV36m8BTBG
         n0KDd94vO+URIxkR/Z8oDiBZfX84b7jamWG13lAPn+V7JWMA1B72BwKoeU+El0N8nCdY
         h8QXvS7RBP9mIYVrqvS8M3n/yMb7pcQMq6zIdml3yJouo+lGL6TGzCClO6VcFJMLemqh
         7JgO4VTJJ3LrSWVJTS0C/76ZMA0NryK+xjLOXzgCCx0Gp4FhQ1uBBgXbkZquWqma6OOg
         CQDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737455744; x=1738060544;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=iqME+v0CEK8F/LmxoOToHCnJ0x3lcEhnSNs5R3C2FWY=;
        b=YQ4NaAzrQ8pBhU4SWp9Gw8UURnVoP7bHPbOPmzDIM0jsXY4S9mnZPR0fX77XR8SDim
         gYd28BG2ugstXFBX+xPPUl+zOPCmD33QS+qvsljuUmIZNqUFZGFYoS3EaMXEMTzaLpGq
         F9Kpt6eCXBmlzl8IPXbcq1ae/OTfj/7gnMTIqt1AHqIXmooQg8YiLEqx/bsfnzlIeYNL
         KK6A6ZdS3pSOtvZClu9NUUvjbqcKsihknRJYJ4F9sq/QwkEnXpiT5Dp4e+GpdcHlcEhZ
         cfVC/wGDUjv9o6ehpxwnhrWovOkODs4W8ilsK6EcHtLTh74Ptm2UE3lNXNMuzXMcg8hS
         62nQ==
X-Forwarded-Encrypted: i=1; AJvYcCV46zxRzhuhz65A36kgSm53FTlmcWgCYAfma+IUNtU6VUuvt9pRTO+y9e8UxVEddZ2vetLikTnHEPo=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx7Jh2RuKKes43jWSefzPtvMD4mMtOvq2AqE9RdSVcI9Mdi4/mG
	yfaOV2t7AHpSKDBawagf5ZsjXEXL/Fgm9un0LF8d6P7d6gTZZ9qq1mzylUYBwg==
X-Gm-Gg: ASbGncu5lmQLJcJE0krxfQL+F5hKAK0DEkaF0O7xCzjBEIdfdMT8fvFF+r5CrtIlgde
	BYqNxqY3cXpAJtVPVvW/nJvde9sg7JUvFw+WYXAwkeToc9CcI9bKMWrjnzbhqLjl+Q5jG6Waa6K
	yD1b+R181lOIzBGXRLImjKHDIT1wsk1eoJJE5K+dy685Yt44nWzAVS7ot+45Ht4StLirUsGtwpC
	1xh3ZVSrg7RGPlqThI+8MUZXBxApaONcY4fxgGAbd53HqUH7gwFiUaRUgPzz+znnDF/2CY+Qtls
	FfT584fnZhcdoajcjzmaXP/0VSTqrqlgXAJ+HaVh1BoEfPoqjcgsKBk=
X-Google-Smtp-Source: AGHT+IFydmMWnH8VyLrNV/nd8vONhKGDArxk1MTMJBWZ06LplpTRZnmC3ZIIWX4D8e0LS9cariADDg==
X-Received: by 2002:a05:6000:dcc:b0:382:5aae:87c7 with SMTP id ffacd0b85a97d-38bf5674546mr12452872f8f.31.1737455743762;
        Tue, 21 Jan 2025 02:35:43 -0800 (PST)
Message-ID: <41859184-bd9c-420f-96c1-65abe379b81e@suse.com>
Date: Tue, 21 Jan 2025 11:35:42 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/4] x86: provide an inverted Kconfig control for
 shim-exclusive mode
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Alejandro Vallejo <alejandro.vallejo@cloud.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Julien Grall <julien@xen.org>, Wei Liu <wl@xen.org>, sergiy_kibrik@epam.com
References: <617842e1-8ef2-b095-0c52-c2e2e5f1c0a8@suse.com>
 <alpine.DEB.2.22.394.2501161503120.2684657@ubuntu-linux-20-04-desktop>
 <Z4oxZSUQ6VARiR0H@macbook.local> <D74CH4RDRRR9.ZR6RL8U6PQ56@cloud.com>
 <6285f86d-f2d2-4040-999d-01aed3e72a36@suse.com>
 <alpine.DEB.2.22.394.2501171430570.2684657@ubuntu-linux-20-04-desktop>
 <f8c1e2c2-ceb5-4200-a304-e2d824a171a8@citrix.com>
 <40c9d806-000d-43e7-a804-ad4e84209b2f@suse.com>
 <alpine.DEB.2.22.394.2501201527090.11086@ubuntu-linux-20-04-desktop>
 <bae48627-fa5b-48b6-b74e-267285175eff@suse.com>
 <Z49gQBkxCbXIO84D@macbook.local>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <Z49gQBkxCbXIO84D@macbook.local>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 21.01.2025 09:52, Roger Pau Monné wrote:
> On Tue, Jan 21, 2025 at 09:13:38AM +0100, Jan Beulich wrote:
>> On 21.01.2025 00:27, Stefano Stabellini wrote:
>>> On Mon, 20 Jan 2025, Jan Beulich wrote:
>>>> On 18.01.2025 00:41, Andrew Cooper wrote:
>>>>> On 17/01/2025 10:43 pm, Stefano Stabellini wrote:
>>>>>> On Fri, 17 Jan 2025, Jan Beulich wrote:
>>>>>>> On 17.01.2025 13:24, Alejandro Vallejo wrote:
>>>>>>>> On Fri Jan 17, 2025 at 10:31 AM GMT, Roger Pau Monné wrote:
>>>>>>>>> On Thu, Jan 16, 2025 at 04:31:46PM -0800, Stefano Stabellini wrote:
>>>>>>>>>> On Wed, 1 Mar 2023, Jan Beulich wrote:
>>>>>>>>>>> While we want certain things turned off in shim-exclusive mode, doing
>>>>>>>>>>> so via "depends on !PV_SHIM_EXCLUSIVE" badly affects allyesconfig: Since
>>>>>>>>>>> that will turn on PV_SHIM_EXCLUSIVE, other options will be turned off as
>>>>>>>>>>> a result. Yet allyesconfig wants to enable as much of the functionality
>>>>>>>>>>> as possible.
>>>>>>>>>>>
>>>>>>>>>>> Retain PV_SHIM_EXCLUSIVE as a prompt-less option such that first of all
>>>>>>>>>>> C code using it can remain as is. This isn't just for less code churn,
>>>>>>>>>>> but also because I think that symbol is more logical to use in many
>>>>>>>>>>> (all?) places.
>>>>>>>>>>>
>>>>>>>>>>> Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>>>>>>>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>>>>>>>>>
>>>>>>>>>>> ---
>>>>>>>>>>> The new Kconfig control's name is up for improvement suggestions, but I
>>>>>>>>>>> think it's already better than the originally thought of
>>>>>>>>>>> FULL_HYPERVISOR.
>>>>>>>>>> I think the approach in general is OK, maybe we can improve the naming
>>>>>>>>>> further. What about one of the following?
>>>>>>>>>>
>>>>>>>>>> NO_PV_SHIM_EXCLUSIVE
>>>>>>>>>> PV_SHIM_NOT_EXCLUSIVE
>>>>>>>>> IMO negated options are confusing, and if possible I think we should
>>>>>>>>> avoid using them unless strictly necessary.
>>>>>>>> The problem is that the option is negative in nature. It's asking for
>>>>>>>> hypervisor without _something_. I do agree with Stefano that shim would be
>>>>>>>> better in the name. Otherwise readers are forced to play divination tricks.
>>>>>>>>
>>>>>>>> How about something like:
>>>>>>>>
>>>>>>>>     SHIMLESS_HYPERVISOR
>>>>>>>>
>>>>>>>> That's arguably not negated, preserves "shim" in the name and has the correct
>>>>>>>> polarity for allyesconfig to yield the right thing.
>>>>>>> Except that a hypervisor with this option enabled isn't shim-less, but permits
>>>>>>> working in shim as well as in non-shim mode.
>>>>>> First, let's recognize that we have two opposing requirements. One
>>>>>> requirement is to make it as easy as possible to configure for the user.
>>>>>> Ideally without using negative CONFIG options, such as
>>>>>> NO_PV_SHIM_EXCLUSIVE. From the user point of view, honestly,
>>>>>> PV_SHIM_EXCLUSIVE is a pretty good name. Better than all of the others,
>>>>>> I think.
>>>>>>
>>>>>> On the other hand, we have the requirement that we don't want
>>>>>> allyesconfig to end up disabling a bunch of CONFIG options. Now this
>>>>>> requirement can be satisfied easily by adding something like
>>>>>> NO_PV_SHIM_EXCLUSIVE. However, it would go somewhat against the previous
>>>>>> requirement.
>>>>>>
>>>>>> So we need a compromise, something that doesn't end up disabling other
>>>>>> CONFIG options, to make allyesconfig happy, but also not too confusing
>>>>>> for the user (which is a matter of personal opinion).
>>>>>>
>>>>>> In short, expect that people will have different opinions on this and
>>>>>> will find different compromises better or worse. For one, I prefer to
>>>>>> compromise on "no negative CONFIG options" and use
>>>>>> PV_SHIM_NOT_EXCLUSIVE. Because it serves the allyesconfig goal, and
>>>>>> while it is not as clear as PV_SHIM_EXCLUSIVE, is still better than a
>>>>>> completely generic FULL_HYPERVISOR option, which means nothing to me.
>>>>>>
>>>>>> I cannot see a way to have a good and clear non-negated CONFIG option,
>>>>>> and also satisfy the allyesconfig requirement. So I prefer to compromise
>>>>>> on the "non-negated" part.
>>>>>
>>>>> Debating the naming is missing the point.
>>>>>
>>>>>
>>>>> The problem here is the wish to have PV_SHIM_EXCLUSIVE behave in a way
>>>>> that Kconfig is not capable of expressing.  Specifically, what is broken
>>>>> is having "lower level" options inhibit unrelated "higher level" options
>>>>> when the graph gets rescanned[1].  That's why we're in the laughable
>>>>> position of `make allyesconfig` turning off CONFIG_HVM.
>>>>>
>>>>> Jan, you want "echo PV_SHIM_EXCLUSIVE=y >> .config && make" to mean
>>>>> "reset me back to a PV Shim".
>>>>
>>>> Isn't this an independent goal? Or is this a statement on what you see
>>>> my change (kind of) doing, indicating you consider this wrong?
>>>
>>> The way I understood it, it is the latter
>>>
>>>
>>>>> Kconfig spells this "make $foo_defconfig" for an appropriately given foo.
>>>>>
>>>>>
>>>>> There should be:
>>>>>
>>>>> 1) an option called PV_SHIM_EXCLUSIVE which does *nothing* other than
>>>>> making the boolean be a compile time constant.
>>>>
>>>> I fear it remains unclear to me what exactly you mean here. It feels like
>>>> you may be suggesting that all other uses of PV_SHIM_EXCLUSIVE should be
>>>> dropped, without replacement. That seems wrong to me, though. In
>>>> particular I'm of the opinion that besides using "make pvshim_defconfig"
>>>> people ought to also have the option to properly configure a shim build
>>>> from scratch (or from any random .config they hold in hands), requiring
>>>> respective "depends on" and/or "select" / "imply" to be in place.
>>>
>>> That should be done with "make pvshim_defconfig"
>>
>> Why? Specifically, why should people use only one entirely nailed down
>> configuration for a shim. Like a "normal" hypervisor, there are aspects
>> which very well can be left to the person doing the configuration.
> 
> But nothing prevents a user from starting from a shim defconfig, and
> then tweaking it as desired:
> 
> $ make pvshim_defconfig
> $ make menuconfig
> 
> Or there's something I'm missing here?

Well, no, you don't. But if the above is okay, why would not starting from
pvshim_defconfig not also be okay? Plus whichever way tweaks are done,
sensible dependencies should still be enforced imo.

>>>> Or else they may end up with a lot of dead code. (Just consider e.g.
>>>> HVM=n: We also don't permit HVM-only stuff to be enabled in that case,
>>>> as any of that would again be dead code then.)
>>>
>>> It will always be possible to come up with poor configurations. I do not
>>> believe it is necessarily our responsibility to go out of our way to
>>> prevent them.
>>
>> Well - if so, why would we do this in some cases but not in others?
>> You may recall that I'm a proponent of consistency and predictability.
>>
>>>>> 2) a pvshim_defconfig target which expresses what a pvshim ought to look
>>>>> like.
>>>>
>>>> We have this file already. I consider it debatable though whether this file
>>>> should really force PV_SHIM_EXCLUSIVE=y. People may read "pvshim" in the
>>>> name as either "works just as shim" or "can also work as shim".
>>>
>>> If I understood it right, I like Andrew's suggestion. He is suggesting
>>> to do the following:
>>>
>>> - turning PV_SHIM_EXCLUSIVE into something that does nothing
>>
>> FTAOD - you mean Kconfig-wise? Andrew clearly didn't say "nothing", but
>> "nothing other than making the boolean be a compile time constant".
> 
> Won't making the boolean a compile time constant would also result in
> DCO kicking in and removing a fair amount of code?  So even if you
> have enabled everything in Kconfig, the resulting hypervisor would
> only be suitable to be used as a shim?

Of course.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 10:41:12 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 10:41:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875364.1285811 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taBgy-00044V-NQ; Tue, 21 Jan 2025 10:41:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875364.1285811; Tue, 21 Jan 2025 10:41:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taBgy-00044O-KR; Tue, 21 Jan 2025 10:41:08 +0000
Received: by outflank-mailman (input) for mailman id 875364;
 Tue, 21 Jan 2025 10:41:07 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=abyW=UN=cloud.com=ross.lagerwall@srs-se1.protection.inumbo.net>)
 id 1taBgx-00044I-ED
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 10:41:07 +0000
Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com
 [2607:f8b0:4864:20::22e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 37166250-d7e4-11ef-99a4-01e77a169b0f;
 Tue, 21 Jan 2025 11:41:05 +0100 (CET)
Received: by mail-oi1-x22e.google.com with SMTP id
 5614622812f47-3eb9a0a2089so3458511b6e.1
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 02:41:05 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 37166250-d7e4-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737456064; x=1738060864; 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=GN5S+dtoU4QAnEngV7PhQV+IPW4js7xThkeyUCCuQ4c=;
        b=V3q5PdDqwFHKyx8FsSZr7E32LpTkloqIWgFsGKngbVCvuNW1+/kFHab393fHojteG+
         mOrFsN9EB2x3aEYr1QPyXmHe0XJ7a7miugSkXthtkHCaTAZis7/HvmqPR6N9+0QNp2XO
         MZOs5E6L3RcofrL/c4l+i/CFxbBjKUXvzseLs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737456064; x=1738060864;
        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=GN5S+dtoU4QAnEngV7PhQV+IPW4js7xThkeyUCCuQ4c=;
        b=CTnepkkX4H2wGXejGxilRIJbMx+R9vTHsRc+WoSiN5iKRQDbScrctOBzQwYF3/bwU2
         Cx52W9la2OkqbUI7B+AgVl/NBn4Dr453aC9ebVl4rqBjMCCt5HXMHuTkn/U8I8bTj6Tl
         DDlhcG2KBDlZ4c8j35sNy8caZeeQLEJJRvpf+m4TPFnT2tU8n1VA5+DqFMgYUJfY+fv+
         KNmluS7krgoppt9I9vLj+yX1h5k+xmoeuaYCAsh5aAMYDKNgl7pSMLEQdmxyGXwn7h/j
         1tx5dFUiXNkYh2ATRIF4xQzh4AS7moRTdEq+EWMWqnQI3DzICNlPvZgSPOKvDWTYKg2M
         y2tw==
X-Gm-Message-State: AOJu0YyDMNcpZ3qGnkhy2QjqqdXzF7yEtiIRzBhSQeFe2njOHXebgWI7
	dJcbA70qN+f98EsDgItf7YBCukggmwN1NyEEHDmQrDbWMJqQ7vWLgE7nrxdZqDDkg0kqlbYCVwx
	LILxXJmH7m9RCmFtcRaiSynnsxixfTDXp5nFE
X-Gm-Gg: ASbGnctQVlz58HZYyaNssjII+Tqh00YL77fQtGkoPdpZofEP086P2Yd9nLuUhC1Lmwa
	TOi2t0KnwnWzEQl3/FSHIU0l0KFntSBDdbcYmL49H9CzThIG56w==
X-Google-Smtp-Source: AGHT+IHqS/wo2mBbTCedt8iB+VHN+ntqRQqanojZ1LwZUrPfIbNjigsFmu4EPD/Re7JU95bh8hzNNzi27yI9nVF4jG8=
X-Received: by 2002:a05:6871:5e07:b0:29e:4d0e:a2b6 with SMTP id
 586e51a60fabf-2b1c08c9884mr10092665fac.10.1737456064233; Tue, 21 Jan 2025
 02:41:04 -0800 (PST)
MIME-Version: 1.0
References: <20241107151509.73621-1-roger.pau@citrix.com> <20241107151509.73621-4-roger.pau@citrix.com>
In-Reply-To: <20241107151509.73621-4-roger.pau@citrix.com>
From: Ross Lagerwall <ross.lagerwall@citrix.com>
Date: Tue, 21 Jan 2025 10:40:53 +0000
X-Gm-Features: AbW1kvaAvU0anQ9Lp5l5BRcrMFkqvTdyCSIonIDOFkLGYeR_jcYkIKl4sb-9SS4
Message-ID: <CAG7k0EoV-hOonu0qZLOHoeSoQJmVb+1pn7g9MFff_tQfou_rKQ@mail.gmail.com>
Subject: Re: [PATCH 3/4] create-diff-object: don't include symbols for
 .livepatch.hooks.* sections
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: xen-devel@lists.xenproject.org, konrad.wilk@oracle.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Nov 7, 2024 at 3:15=E2=80=AFPM Roger Pau Monne <roger.pau@citrix.co=
m> wrote:
>
> Not all toolchains generate symbols for the .livepatch.hooks.* sections,
> neither those symbols are required by the livepatch loading logic in Xen =
to
> find and process the hooks.  Hooks in livepatch payloads are found and
> processed based exclusively on section data.
>
> The unconditional attempt to expect each hook serction to have a matching
> symbol leads to a segmentation fault in create-diff-object when such symb=
ol is
> not present, as the code references a NULL pointer.
>
> Fix this by not attempting to include symbols associated with hook sectio=
ns.
>
> Signed-off-by: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
> ---
>  create-diff-object.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/create-diff-object.c b/create-diff-object.c
> index d8a2afbf2774..924059a1842b 100644
> --- a/create-diff-object.c
> +++ b/create-diff-object.c
> @@ -1555,8 +1555,6 @@ static int kpatch_include_hook_elements(struct kpat=
ch_elf *kelf)
>                                 sym->sec->sym =3D NULL;
>                                 /* use section symbol instead */
>                                 rela->sym =3D sym->sec->secsym;
> -                       } else {
> -                               sec->secsym->include =3D 1;
>                         }
>                 }
>         }
> --
> 2.46.0
>

Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>

Thanks


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 10:41:48 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 10:41:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875371.1285820 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taBhb-0004ct-Uv; Tue, 21 Jan 2025 10:41:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875371.1285820; Tue, 21 Jan 2025 10:41:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taBhb-0004cm-S4; Tue, 21 Jan 2025 10:41:47 +0000
Received: by outflank-mailman (input) for mailman id 875371;
 Tue, 21 Jan 2025 10:41:46 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=abyW=UN=cloud.com=ross.lagerwall@srs-se1.protection.inumbo.net>)
 id 1taBha-00044I-46
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 10:41:46 +0000
Received: from mail-oa1-x29.google.com (mail-oa1-x29.google.com
 [2001:4860:4864:20::29])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4e594aa3-d7e4-11ef-99a4-01e77a169b0f;
 Tue, 21 Jan 2025 11:41:44 +0100 (CET)
Received: by mail-oa1-x29.google.com with SMTP id
 586e51a60fabf-29fcbf3d709so1794524fac.2
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 02:41:44 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 4e594aa3-d7e4-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737456103; x=1738060903; 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=nLo5nkHbVjFQWG7SU2GZfAG4NVdknbQu66jBuqWlEBE=;
        b=lOJWvMxB51eQ+THr65u07/55Xnc9s3ZDPaYOsPfy4YdjP7xDdHaX88c2otqF8gw1Oa
         rT1etZtUtieMx6uKDrvvJPk9RCcARMTyNd9ZLKPD/LwSJZuNHXQcNwFpl5eXw1iGKRl5
         4A9usHLy6geXKMet7odLALtSIduOCSfUdV/+g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737456103; x=1738060903;
        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=nLo5nkHbVjFQWG7SU2GZfAG4NVdknbQu66jBuqWlEBE=;
        b=iWRzNsFhRAiW/CrsRj3e8HzkZrXC77PcVloJQthWuN8+JHGOR9HjLMfhqa/GFof/ZE
         bp4UKlwjxzK0I/BBoonEtR/+fMnXZ+NI0XEbLg3eiQAPTrLb+9BltP01ys7RuyHL0iFm
         4yQ427Fqnqyl0B6PFxsBDkkqjGbj64lsGXV0NFFkc5NQbmrwMsQIxh41dp3Vx/n3vpP6
         zBIaR0sArX9YKWNI49rApVH+rmhspmgrs3MpBRHheytsphWQa1cgV4/K2/lPihmLeNNC
         4b9mf19cvYsRU82LgRweR6kNnl5xtnw6x7+eNOF1UnrgRNoGtZ/OPHKCq1z6XY6A/mn/
         AcjA==
X-Gm-Message-State: AOJu0YwyeOk9EW7lam3BZpd7cv331X+O+HQX7Fve2WDF3lnGWx8KZ1cb
	oWHZFEN4Fj/K43/61Ta8xqgAv0BPaHl2VC18h2x1J9k9nK720zzEDwdhZHOxZ6M+7uvQngm7iZF
	+JpQIdWBzckQOZ/EM03t8QgsIxaBxqA/Y9q0H
X-Gm-Gg: ASbGncvlUvin9esmZNkpmQnEp42/PTfH4xl3cTL+oiSN4k9CJCsR3f1GpTtMfL6zEYn
	cyfWIj22yBxXGKxy8xhtwbq+XR8Kf7TUGSWBaMS/IgQ7yF7N9mA==
X-Google-Smtp-Source: AGHT+IG/mxAUyoXNSINHiPN+Mg2JH9PbaFAd9/SZQ3skGOKzC9evh8TgHbkIwOzcPwJ+v2zHhqoxEEqHk+Jb4MK20y0=
X-Received: by 2002:a05:6870:6981:b0:29f:f1cc:12a5 with SMTP id
 586e51a60fabf-2b1c0c025c8mr10156762fac.31.1737456103234; Tue, 21 Jan 2025
 02:41:43 -0800 (PST)
MIME-Version: 1.0
References: <20241107151509.73621-1-roger.pau@citrix.com> <20241107151509.73621-5-roger.pau@citrix.com>
In-Reply-To: <20241107151509.73621-5-roger.pau@citrix.com>
From: Ross Lagerwall <ross.lagerwall@citrix.com>
Date: Tue, 21 Jan 2025 10:41:32 +0000
X-Gm-Features: AbW1kvZNKOw-wF9VqtF2H7WYu6tLCWVGnyH0wTPOiWVWFncY6gAgLGwdq1Qbgmc
Message-ID: <CAG7k0EqVdZK4Pe73k_1PiUg0RoCxkekC7a6yn4MceZUvO81EXg@mail.gmail.com>
Subject: Re: [PATCH 4/4] create-diff-object: also include relas that point to
 changed sections
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: xen-devel@lists.xenproject.org, konrad.wilk@oracle.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Nov 7, 2024 at 3:15=E2=80=AFPM Roger Pau Monne <roger.pau@citrix.co=
m> wrote:
>
> create-diff-object has a special handling for some specific sections, lik=
e
> .altinstructions or .livepatch.hooks.*.  The contents of those sections a=
re in
> the form of array elements, where each element can be processed independe=
ntly
> of the rest.  For example an element in .altinstructions is a set of
> replacement coordinates, with the layout specified by the alt_instr struc=
t.  In
> the case of .livepatch.hooks.* each element is a pointer to a hook functi=
on to
> call.
>
> The contents of this array is processed element wise, so that
> create-diff-object can decide whether the element relates to the content =
in the
> livepatch and thus needs keeping.  Such relation is driven based on the
> contents of the relocations for the special sections.  If a relocation to=
 be
> applied to a special section element depends on any symbol to be included=
 in
> the livepatch then the special element is also considered required and th=
us
> added to the livepatch contents.
>
> However relocations don't always reference function type symbols, they ca=
n also
> reference sections type symbols, and that's usually the case with hook sy=
mbols
> that have relocations based on section symbols, as an example:
>
> RELOCATION RECORDS FOR [.livepatch.hooks.load]:
> OFFSET           TYPE              VALUE
> 0000000000000000 R_X86_64_64       .text.foobar
>
> Symbol information for .text.foobar:
>
> 0000000000000000 l    d  .text.foobar      0000000000000000 .text.foobar
>
> As seen above, the .livepatch.hooks.load relocation uses a non-function s=
ymbol,
> which given the current code in should_keep_rela_group() would mean it's =
not
> considered for inclusion in the livepatch.
>
> Fix this by allowing should_keep_rela_group() to also keep relocations if=
 they
> either point to function or section symbols.
>
> Signed-off-by: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
> ---
>  create-diff-object.c | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/create-diff-object.c b/create-diff-object.c
> index 924059a1842b..c21cc576052a 100644
> --- a/create-diff-object.c
> +++ b/create-diff-object.c
> @@ -1158,11 +1158,17 @@ static int should_keep_rela_group(struct section =
*sec, int start, int size)
>         struct rela *rela;
>         int found =3D 0;
>
> -       /* check if any relas in the group reference any changed function=
s */
> +       /*
> +        * Check if any relas in the group reference any changed function=
s or
> +        * sections.  As seen by hook related relocations (.livepatch.hoo=
ks.*),
> +        * it's possible they use the section symbol as a reference rathe=
r than
> +        * the function symbol.
> +        */
>         list_for_each_entry(rela, &sec->relas, list) {
>                 if (rela->offset >=3D start &&
>                     rela->offset < start + size &&
> -                   rela->sym->type =3D=3D STT_FUNC &&
> +                   (rela->sym->type =3D=3D STT_FUNC ||
> +                    rela->sym->type =3D=3D STT_SECTION) &&
>                     rela->sym->sec->include) {
>                         found =3D 1;
>                         log_debug("new/changed symbol %s found in special=
 section %s\n",
> --
> 2.46.0
>

Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>

Thanks


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 11:09:54 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 11:09:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875382.1285831 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taC8j-00012O-4A; Tue, 21 Jan 2025 11:09:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875382.1285831; Tue, 21 Jan 2025 11:09:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taC8i-00012H-Vl; Tue, 21 Jan 2025 11:09:48 +0000
Received: by outflank-mailman (input) for mailman id 875382;
 Tue, 21 Jan 2025 11:09: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
 <SRS0=jEc5=UN=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1taC8g-00012B-Qd
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 11:09:46 +0000
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com
 [2a00:1450:4864:20::129])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 389371e6-d7e8-11ef-a0e4-8be0dac302b0;
 Tue, 21 Jan 2025 12:09:45 +0100 (CET)
Received: by mail-lf1-x129.google.com with SMTP id
 2adb3069b0e04-5401c52000fso5296971e87.2
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 03:09:45 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab384c5ad7bsm734421966b.36.2025.01.21.03.09.33
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 21 Jan 2025 03:09:33 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 389371e6-d7e8-11ef-a0e4-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737457785; x=1738062585; 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=3dWZiJEDc99jShgeu4oFpCmpOwPWEJ86pDTkm2NKdxw=;
        b=XvmViPbVm8GK/9xYq4T7jdaU/spY1N3Ev0oGEk5nZfZL06d4uMq6cuAoJx6RT9hubl
         KPR9lMMRGe2bacMqeVr2UIcIhdtsnQPAXXAk77bIl4tGGrEWxINPMEH9VqtyeEJmdV99
         SIaQHNd9lpZgpJ/ZvNDwVjXsnvElryM9+NCOI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737457785; x=1738062585;
        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=3dWZiJEDc99jShgeu4oFpCmpOwPWEJ86pDTkm2NKdxw=;
        b=lCwBCeOBGiSgh5E7avAr5CAZTsNirnUz1MidKLpnC3ygM/aSno47RVR9j8FGX5lXM2
         C2ovHaPi1MMlP3c/HpGEBZxdtos4TpKve6lY66Ohv8wUwRMNQJAOA7ZpeNzuqu5P1EVB
         xU7ZomkFrDBc5JQBipVkxheHDNtGIXCcVt60CLvW2Ad0cpnz58w0orv0hQpRcn52Y7fM
         6aYnxrtm9NHtDBgH2+eqpfUnVmfhE18SCyruu+VyxAiVdWbmqKWaDFuJuwB48hCK2jGF
         IL5GZQLzuv6NriAWjkZQoOYEcb50jCNfl7JIE9o3acq+gFqLs6EmIs/JC2UrPRS8fAs4
         CxCQ==
X-Forwarded-Encrypted: i=1; AJvYcCWwgv22nm59owpwHDpE9SA7YYbO/rX3uHeYnjPdLZctDHT1mZeHKwnOjDI5I5QrfeWOLGWgpnyFjVo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwLYceGybL5Ns5sQWc1lXemaD5hjMuomJVz8qcX2mN3zKyuiUxG
	3biz7vYuku9Evn8zUNGT3rzuvmefisLHFaVAUPP42vW/CrAlI5spwODFCh9RzNNMJ/WGT+MPNL8
	U
X-Gm-Gg: ASbGnctEyAu738jDIEYdlmOh5pKBgPAAVM1K1BEFjYsttxCltwHQJxiHhekmFrr8lgW
	uikVtYLxxIJDbcGHLDfWzNIVGu9JMb/ZAmOP6DhefN8kGXfNC29vrqP2opti3Y7g7FVHsARzVR0
	qB5NM+01FslGaeMBQoPw12/oEteuS4U1J5IBPrJ6qpLNCbeAH9gT2XRc5AZSwRLiUw6jS6ZThCt
	ygTIVWeoNn6Kr1vPxVhTj2k9w6TErggjczavPB4EQDpgfdrneI0lIg4Oes/wnz6HOg7aMOO6wg=
X-Google-Smtp-Source: AGHT+IHpTcp9+GfPwPygMEIAY3gRkoVWDKq2w5F/HWcwMTvbck12Fmy/3YyLGuI3pADpbQxbGQp/oQ==
X-Received: by 2002:a05:6402:518a:b0:5d3:ba42:e9e3 with SMTP id 4fb4d7f45d1cf-5db7d2f5ec0mr43385865a12.13.1737457773959;
        Tue, 21 Jan 2025 03:09:33 -0800 (PST)
Date: Tue, 21 Jan 2025 12:09:32 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Teddy Astie <teddy.astie@vates.tech>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [XEN PATCH v5 1/3] x86/iommu: Disable IOMMU if cx16 isn't
 supported
Message-ID: <Z4-AbI2oKWCR5bws@macbook.local>
References: <cover.1713433029.git.teddy.astie@vates.tech>
 <4656eab84f7b4b807fc61f54b9ba5c0fc4fae64d.1713433029.git.teddy.astie@vates.tech>
 <8cab0372-8c40-4648-bdbe-ff56844f289d@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <8cab0372-8c40-4648-bdbe-ff56844f289d@suse.com>

On Wed, Apr 24, 2024 at 04:27:10PM +0200, Jan Beulich wrote:
> On 18.04.2024 13:57, Teddy Astie wrote:
> > All hardware with VT-d/AMD-Vi has CMPXCHG16B support. Check this at
> > initialisation time, and remove the effectively-dead logic for the
> > non-cx16 case.
> 
> As before: What about Xen itself running virtualized, and the underlying
> hypervisor surfacing an IOMMU but not CX16? It may be okay to ignore the
> IOMMU in such an event, but by not mentioning the case you give the
> appearance of not having considered it at all.
> 
> > --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
> > +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
> > @@ -305,6 +305,12 @@ static int __init cf_check iov_detect(void)
> >      if ( !iommu_enable && !iommu_intremap )
> >          return 0;
> >  
> > +    if ( unlikely(!cpu_has_cx16) )
> > +    {
> > +        printk("AMD-Vi: CPU doesn't support CMPXCHG16B, disabling\n");
> > +        return -ENODEV;
> > +    }
> > +
> >      if ( (init_done ? amd_iommu_init_late()
> >                      : amd_iommu_init(false)) != 0 )
> >      {
> 
> I did previously point out (and that's even visible in patch context here)
> that the per-vendor .setup() hooks aren't necessarily the first thing to
> run. Please can you make sure you address (verbally or by code) prior to
> submitting new versions?

I've re-visiting this as part of my other IOMMU IRTE atomic update
fix.

Would you prefer the check for CX16 be in the common x86
iommu_hardware_setup()?  That would be kind of layering violation, as
in principle a further IOMMU implementation on x86 might not require
CX16.  However I find it very unlikely, and hence I would be fine in
placing the check in iommu_hardware_setup() if you prefer it there.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 11:20:37 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 11:20:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875393.1285841 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taCIx-0004Gd-4W; Tue, 21 Jan 2025 11:20:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875393.1285841; Tue, 21 Jan 2025 11:20:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taCIx-0004GW-15; Tue, 21 Jan 2025 11:20:23 +0000
Received: by outflank-mailman (input) for mailman id 875393;
 Tue, 21 Jan 2025 11:20:22 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Gode=UN=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1taCIw-0004GQ-A1
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 11:20:22 +0000
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com
 [2a00:1450:4864:20::32c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b27ae025-d7e9-11ef-99a4-01e77a169b0f;
 Tue, 21 Jan 2025 12:20:19 +0100 (CET)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-43621d27adeso37314885e9.2
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 03:20:19 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-437c0efccf7sm152892055e9.0.2025.01.21.03.20.18
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 21 Jan 2025 03:20:18 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b27ae025-d7e9-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737458419; x=1738063219; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=I6y2pyU3STAQWtek6i/q7gL4MQuoPOasqN9mkUC/6gE=;
        b=X7x/+28CcEHFori4UbnhJZRXeUTFOFtZStX0l30VEEK67ilEXBmF1wEIZOYJkA9qQC
         jQ+aTz60m6ufussk/tbWrTItjQGLgZI0Y4LbWjNLs9K+HB9X91+RCP1wEiWLosPFxbKE
         BjDDmN0kuZzM2BX1ttPK7ksiFwsjLGLLWpOT12h7P/2LsjExUBY449zj8hzfRcYbRpJe
         cAFdX25L64G4xi4KJMucl4JXWRyH4frX7nhqZ2KXgMu2OT+Y9PJ+wNeXaZFSdC1Ww4IF
         IVHcmkrAcp2gBThjErxPzuyFyHoNE0coUrShtzVXAM+6wlLtZ2GEz6EAtO1OA03QZq8q
         TpTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737458419; x=1738063219;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=I6y2pyU3STAQWtek6i/q7gL4MQuoPOasqN9mkUC/6gE=;
        b=iuZscUAulYIcGrNbF5muQBiMt6hGEScO4xACYb/sGVHUa8lx+ALKaWoVI+ymSL9MJb
         kO+c72KZ6sqZnaPa3dLK2DEBUROhBNR7sqKOc+2SjwxOGbvcHGO4n9Fps9teC7Dpqj4N
         NMR1Jb2Qc1ReSQe9AkwVUu6fmjQUlcAfdXgbrGgxW01MJTsYMQYVpAQBFin8lpvWkj2a
         6IVMfSVJyeGqeSVmxneSxN2uS7AcHuMgORxU9NU/OeSr1LmuTJravw9GIoGc2kJXu1Tv
         E6TTgxycZ0IYssQMJqZSKpxphyVoxzcVUs6XytyRIJIfwDWGmh5Qjc5QzL9Tcv4GPoT2
         kKcQ==
X-Forwarded-Encrypted: i=1; AJvYcCUOzmUZxWhftQlOICIdHJPb65Wppu3j7MUNfrFy3PnWFhqmfSLVkzD+4qDZ6Ge3AI8W502kTx7ebXs=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyc5nPP8fzRaBj6w3TADWpBiyyomFxOCy64bpB8YliFZAjrlVK5
	rJ52hhNer5EqiAOhqryO8xuNVoplLk9Ky5yGfELtOdDJyu/n9vIVgIAC3GLxNA==
X-Gm-Gg: ASbGncvd04+i/TjqI8mcpmZT9ohrtJR67Ce6cjvfezjsx3ffuSyiE1YoMPa1+LiuBqS
	Ggh8F/zVIqmC+L9MTvB7w7zjfrTLUDVoIQjeEjplm5ZCi08rkamq3x3KGiR2YwTLVu0zJjXjfzH
	uY6Lj6Lq0uiUZO7zM2eFmJKdi//1q/AM6raPIzslXMSIpoOgHz3IO6g1MXBnHuq92yCexElHhuG
	Va3U2pagspHDZ49Fl9ln9ukejSFWE2tlYm4GfVlU/kuMzr+fGsn5iluNyl9b34Q7rLd7gLX47JA
	3ikcG2niyGXIgFwKssPEwWzjg+TS750yBV9ecF9ybC0UwX+4z0+vfws=
X-Google-Smtp-Source: AGHT+IHVVG71nnomT4BWJ6Quz7D+hXKNrrRX4iOzK4cYZqXLSqOKAdhlgLsC9r+C3wMevkEbDD7WfA==
X-Received: by 2002:a05:600c:4e0b:b0:434:a525:7257 with SMTP id 5b1f17b1804b1-43891433febmr133233915e9.21.1737458418768;
        Tue, 21 Jan 2025 03:20:18 -0800 (PST)
Message-ID: <885982e1-fb1b-4b6a-a0bf-2251e5d9acf1@suse.com>
Date: Tue, 21 Jan 2025 12:20:17 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v5 1/3] x86/iommu: Disable IOMMU if cx16 isn't
 supported
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Cc: Teddy Astie <teddy.astie@vates.tech>,
 Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xenproject.org
References: <cover.1713433029.git.teddy.astie@vates.tech>
 <4656eab84f7b4b807fc61f54b9ba5c0fc4fae64d.1713433029.git.teddy.astie@vates.tech>
 <8cab0372-8c40-4648-bdbe-ff56844f289d@suse.com>
 <Z4-AbI2oKWCR5bws@macbook.local>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <Z4-AbI2oKWCR5bws@macbook.local>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 21.01.2025 12:09, Roger Pau Monné wrote:
> On Wed, Apr 24, 2024 at 04:27:10PM +0200, Jan Beulich wrote:
>> On 18.04.2024 13:57, Teddy Astie wrote:
>>> All hardware with VT-d/AMD-Vi has CMPXCHG16B support. Check this at
>>> initialisation time, and remove the effectively-dead logic for the
>>> non-cx16 case.
>>
>> As before: What about Xen itself running virtualized, and the underlying
>> hypervisor surfacing an IOMMU but not CX16? It may be okay to ignore the
>> IOMMU in such an event, but by not mentioning the case you give the
>> appearance of not having considered it at all.
>>
>>> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
>>> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
>>> @@ -305,6 +305,12 @@ static int __init cf_check iov_detect(void)
>>>      if ( !iommu_enable && !iommu_intremap )
>>>          return 0;
>>>  
>>> +    if ( unlikely(!cpu_has_cx16) )
>>> +    {
>>> +        printk("AMD-Vi: CPU doesn't support CMPXCHG16B, disabling\n");
>>> +        return -ENODEV;
>>> +    }
>>> +
>>>      if ( (init_done ? amd_iommu_init_late()
>>>                      : amd_iommu_init(false)) != 0 )
>>>      {
>>
>> I did previously point out (and that's even visible in patch context here)
>> that the per-vendor .setup() hooks aren't necessarily the first thing to
>> run. Please can you make sure you address (verbally or by code) prior to
>> submitting new versions?
> 
> I've re-visiting this as part of my other IOMMU IRTE atomic update
> fix.
> 
> Would you prefer the check for CX16 be in the common x86
> iommu_hardware_setup()?  That would be kind of layering violation, as
> in principle a further IOMMU implementation on x86 might not require
> CX16.  However I find it very unlikely, and hence I would be fine in
> placing the check in iommu_hardware_setup() if you prefer it there.

No. The check needs replicating into the other hook that may run first,
->supports_x2apic(). And the ->enable_x2apic() hooks may want to gain
respective assertions then.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 12:37:33 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 12:37:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875408.1285851 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taDVO-0007CF-Ia; Tue, 21 Jan 2025 12:37:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875408.1285851; Tue, 21 Jan 2025 12:37:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taDVO-0007C8-Fm; Tue, 21 Jan 2025 12:37:18 +0000
Received: by outflank-mailman (input) for mailman id 875408;
 Tue, 21 Jan 2025 12:37:17 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=NioT=UN=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1taDVM-0007Ag-Re
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 12:37:17 +0000
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com
 [2a00:1450:4864:20::236])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 714c3982-d7f4-11ef-a0e4-8be0dac302b0;
 Tue, 21 Jan 2025 13:37:14 +0100 (CET)
Received: by mail-lj1-x236.google.com with SMTP id
 38308e7fff4ca-30227ccf803so46304571fa.2
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 04:37:14 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-3072a34489fsm20533791fa.29.2025.01.21.04.37.12
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 21 Jan 2025 04:37:13 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 714c3982-d7f4-11ef-a0e4-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1737463034; x=1738067834; darn=lists.xenproject.org;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=NJ+EAvY3g+W4cU26MGjggghSeDmZuBjdFoRe4claR2o=;
        b=iE9j2RYGLMfKSyxQoIzBiPU8vWfuD9nHgOCLq5M+xESShDnGzIPnBux+ZPFFjkKiiG
         a2SRGi8u3sWbI3B+Ybm+/4RtchYFv1qrJcuMBwNE1dPT4zm5XVADqYlTpldowyabOzeB
         aPb7bnlHaSTZ3+3DG5qPzRuhBSsI/svgkYqDP2f/GYc8+Mc5gxsSoUMNiWCrrEKxmWGX
         tP8+pQl3Vz5q3xRqST6NjqlVmWhhbRHv5C4YUZKzJeIckLss872YLm3J8XHu+ivtqTBS
         aCv5PIKxB2p6BJU30Wj4opXzBi3DIySaT/UfES6VaTcophaBBlUaI3yqxP1IqoXk1GQM
         XP4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737463034; x=1738067834;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=NJ+EAvY3g+W4cU26MGjggghSeDmZuBjdFoRe4claR2o=;
        b=mmOV3RL8DTj+UW2M5naCeb2XzhyCjT+vnYCIFgNqAUOUaj83/YAmVzXaCJv0M3YCRH
         4dZLA2WtkRKUEGg8duBQtI1rum3Eewp3vYHae4q9oz401F6gCdcgZPTkO5HSbEt3d0Fm
         e7byMsNRCYEAHDKqqIjy/GAziiDT+gR8xiAIvagBrCl+rDGlKkiAiTZozqiEYZvOqkdh
         c0ish0Kvs+x6Ac6tpTvL0Ln1WnrYsSJsLxh6tcmgbxsbySdeHzUhplx47iFvPDE4KBYy
         Nb3uSaSB9luY4YvR7hY6e/yuEPZha9w9lE0LFJ5KjVI5XGodACRHU8FQrr5wC55zc9lK
         hS4w==
X-Forwarded-Encrypted: i=1; AJvYcCVP8/ophxLYL5zoX+Y2/xlFsqN65EXRojK7yUG/V4VKf162zlK4JBOFHLI9BsE0Q5wlGqKzQIC9TFI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxnciOcjcG0vNpQRj7W4c0vSPoYOR2szM/gQLfvVLiK4Wjs7Ln6
	JLpfAzfRpIUw31GYKIu/jqLGkPKgUZdFH/4zkLZ/bB+SappiM/32
X-Gm-Gg: ASbGncscGp1vpI3dhxBBTORf1Jq9HRaPWMMgaxdYhhLnvTv1/iNPHOc4MsHfglQ98JW
	+OpmnjDQvvvTep+bgMwjHSSqtIyzmr0UMyN+wc6zYLQGN9ZQpW+Ant6KPfX0umAtyGaK3SF5Rbc
	37tBgPgq6eZS7gkZ3RpORyeIJGqQFd3IY7mt29v+e5ZYnFu3o5c/3avdkCkpwi5W+tBb94AxK7T
	bFFyNA8AX5cUnPpGjthqAdNmGpXD5l2ICKYtpZhhaWbHbN4TrhSdvj4+BoXS+3w6VBMusk3JvEu
	Z+n6FhE=
X-Google-Smtp-Source: AGHT+IHgZs3f0X8lEbaGiuoCFRDd9sUFstMa8tB4iNwoybJGLhPi4+QjJouf3KpL4TEeCdAgR8PIuQ==
X-Received: by 2002:a05:651c:b24:b0:304:67d4:6e2c with SMTP id 38308e7fff4ca-3072cb1f301mr66860841fa.24.1737463033379;
        Tue, 21 Jan 2025 04:37:13 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------C0x33TP0pSjxn0DaWykmYcnz"
Message-ID: <59dd7cdd-b353-4463-966e-345266a7a54e@gmail.com>
Date: Tue, 21 Jan 2025 13:37:12 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] xen/riscv: identify specific ISA supported by cpu
To: Jan Beulich <jbeulich@suse.com>
Cc: Alistair Francis <alistair.francis@wdc.com>,
 Bob Eshleman <bobbyeshleman@gmail.com>, Connor Davis
 <connojdavis@gmail.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <0a6562ae1e22e3fe607054b33df3467c12d0b276.1736956861.git.oleksii.kurochko@gmail.com>
 <0ceaa04e-36ac-4099-8a84-977a08ba16a2@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <0ceaa04e-36ac-4099-8a84-977a08ba16a2@suse.com>

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


On 1/20/25 4:13 PM, Jan Beulich wrote:
> On 15.01.2025 17:36, Oleksii Kurochko wrote:
>> --- /dev/null
>> +++ b/xen/arch/riscv/cpufeature.c
>> @@ -0,0 +1,506 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +/*
>> + * Taken for Linux kernel v6.12-rc3 and modified by
>> + * Oleksii Kurochko<oleksii.kurochko@gmail.com>:
>> + *
>> + * - Drop unconditional setting of {RISCV_ISA_EXT_ZICSR,
>> + *   RISCV_ISA_EXT_ZIFENCEI, RISCV_ISA_EXT_ZICNTR, RISCV_ISA_EXT_ZIHPM} as they
>> + *   are now part of the riscv,isa string.
>> + * - Remove saving of the ISA for each CPU, only the common available ISA is
>> + *   saved.
>> + * - Remove ACPI-related code as ACPI is not supported by Xen.
>> + * - Drop handling of elf_hwcap, since Xen does not provide hwcap to
>> + *   userspace.
>> + * - Replace of_cpu_device_node_get() API, which is not available in Xen,
>> + *   with a combination of dt_for_each_child_node(), dt_device_type_is_equal(),
>> + *   and dt_get_cpuid_from_node() to retrieve cpuid and riscv,isa in
>> + *   riscv_fill_hwcap_from_isa_string().
>> + * - Rename arguments of __RISCV_ISA_EXT_DATA() from _name to ext_name, and
>> + *   _id to ext_id for clarity.
>> + * - Replace instances of __RISCV_ISA_EXT_DATA with RISCV_ISA_EXT_DATA.
>> + * - Replace instances of __riscv_isa_extension_available with
>> + *   riscv_isa_extension_available for consistency. Also, update the type of
>> + *   `bit` argument of riscv_isa_extension_available().
>> + * - Redefine RISCV_ISA_EXT_DATA() to work only with ext_name and ext_id,
>> + *   as other fields are not used in Xen currently.
>> + * - Add check of first 4 letters of riscv,isa string to
>> + *   riscv_isa_parse_string() as Xen doesn't do this check before so it is
>> + *   necessary to check correctness of riscv,isa string. ( it should start with
>> + *   rv{32,64} with taking into account lower case of "rv").
>> + * - Drop an argument of riscv_fill_hwcap() and riscv_fill_hwcap_from_isa_string()
>> + *   as it isn't used, at the moment.
>> + * - Update the comment message about QEMU workaround.
>> + * - s/pr_info/printk.
> As said before - having this in the commit message is likely enough. Putting
> it here as well is only risking for this to go stale (perhaps rather sooner
> than later).

I misunderstood you last time. I will remove this comment entirely to avoid dealing
with potential staleness in the future.

>
>> + * Copyright (C) 2015 ARM Ltd.
>> + * Copyright (C) 2017 SiFive
>> + * Copyright (C) 2024 Vates
>> + */
>> +
>> +#include <xen/bitmap.h>
>> +#include <xen/ctype.h>
>> +#include <xen/device_tree.h>
>> +#include <xen/errno.h>
>> +#include <xen/init.h>
>> +#include <xen/lib.h>
>> +#include <xen/sections.h>
>> +
>> +#include <asm/cpufeature.h>
>> +
>> +#ifdef CONFIG_ACPI
>> +#error "cpufeature.c functions should be updated to support ACPI"
>> +#endif
>> +
>> +struct riscv_isa_ext_data {
>> +    unsigned int id;
>> +    const char *name;
>> +};
>> +
>> +#define RISCV_ISA_EXT_DATA(ext_name, ext_id)    \
>> +{                                               \
>> +    .id = ext_id,                               \
>> +    .name = #ext_name,                          \
>> +}
>> +
>> +/* Host ISA bitmap */
>> +static __ro_after_init DECLARE_BITMAP(riscv_isa, RISCV_ISA_EXT_MAX);
>> +
>> +static int __init dt_get_cpuid_from_node(const struct dt_device_node *cpu)
>> +{
>> +    const __be32 *prop;
>> +    unsigned int reg_len;
>> +
>> +    if ( dt_n_size_cells(cpu) != 0 )
>> +        printk("cpu node `%s`: #size-cells %d\n",
>> +               dt_node_full_name(cpu), dt_n_size_cells(cpu));
> The call to dt_n_size_cells() is here really just for the printk()?

Yes, it is only used for debug purposes.

Based on DT's bindings (https://www.kernel.org/doc/Documentation/devicetree/bindings/riscv/cpus.txt )
and RISC-V's DTS files in kernel #size-cells for cpu node is expected to be 0.

>> +    prop = dt_get_property(cpu, "reg", &reg_len);
>> +    if ( !prop )
>> +    {
>> +        printk("cpu node `%s`: has no reg property\n", dt_node_full_name(cpu));
>> +        return -EINVAL;
>> +    }
>> +
>> +    if ( reg_len < dt_cells_to_size(dt_n_addr_cells(cpu)) )
>> +    {
>> +        printk("cpu node `%s`: reg property too short\n",
>> +               dt_node_full_name(cpu));
>> +        return -EINVAL;
>> +    }
>> +
>> +    return dt_read_paddr(prop, dt_n_addr_cells(cpu));
> How come it is okay to (silently) truncate here from paddr_t to int?

Specifically in this case it is okay as it is low chance that cpuid will be higher then the size of `int`.
But based on RISC-V spec. hartid could be from 0 to ((1ULL << (MXLEN)) - 1) [MXLEN is the size of register]
so it would be better to use `long` instead of `int` as return value and use `long` for cpuid variable in
the callers of dt_get_cpuid_from_node().

Probably it would be even better to return error code as `int` to have ability to verify if something wrong
happens during dt_get_cpuid_from_node() and add another one argument to dt_get_cpuid_from_node() with paddr_t
type ( or `unsigned long` as type `paddr_t` looks confusing a little bit for describing of cpu id ) and set this
argument before return.
  

>
>> +}
>> +
>> +/*
>> + * The canonical order of ISA extension names in the ISA string is defined in
>> + * chapter 27 of the unprivileged specification.
>> + *
>> + * The specification uses vague wording, such as should, when it comes to
>> + * ordering, so for our purposes the following rules apply:
>> + *
>> + * 1. All multi-letter extensions must be separated from other extensions by an
>> + *    underscore.
>> + *
>> + * 2. Additional standard extensions (starting with 'Z') must be sorted after
>> + *    single-letter extensions and before any higher-privileged extensions.
>> + *
>> + * 3. The first letter following the 'Z' conventionally indicates the most
>> + *    closely related alphabetical extension category, IMAFDQLCBKJTPVH.
>> + *    If multiple 'Z' extensions are named, they must be ordered first by
>> + *    category, then alphabetically within a category.
>> + *
>> + * 4. Standard supervisor-level extensions (starting with 'S') must be listed
>> + *    after standard unprivileged extensions.  If multiple supervisor-level
>> + *    extensions are listed, they must be ordered alphabetically.
>> + *
>> + * 5. Standard machine-level extensions (starting with 'Zxm') must be listed
>> + *    after any lower-privileged, standard extensions.  If multiple
>> + *    machine-level extensions are listed, they must be ordered
>> + *    alphabetically.
>> + *
>> + * 6. Non-standard extensions (starting with 'X') must be listed after all
>> + *    standard extensions. If multiple non-standard extensions are listed, they
>> + *    must be ordered alphabetically.
>> + *
>> + * An example string following the order is:
>> + *    rv64imadc_zifoo_zigoo_zafoo_sbar_scar_zxmbaz_xqux_xrux
>> + *
>> + * New entries to this struct should follow the ordering rules described above.
>> + *
>> + * Extension name must be all lowercase ( according to device-tree binding )
>> + * and strncmp() is used in match_isa_ext() to compare extension names instead
>> + * of strncasecmp().
>> + */
>> +const struct riscv_isa_ext_data __initconst riscv_isa_ext[] = {
>> +    RISCV_ISA_EXT_DATA(i, RISCV_ISA_EXT_i),
>> +    RISCV_ISA_EXT_DATA(m, RISCV_ISA_EXT_m),
>> +    RISCV_ISA_EXT_DATA(a, RISCV_ISA_EXT_a),
>> +    RISCV_ISA_EXT_DATA(f, RISCV_ISA_EXT_f),
>> +    RISCV_ISA_EXT_DATA(d, RISCV_ISA_EXT_d),
>> +    RISCV_ISA_EXT_DATA(q, RISCV_ISA_EXT_q),
>> +    RISCV_ISA_EXT_DATA(h, RISCV_ISA_EXT_h),
>> +    RISCV_ISA_EXT_DATA(zicntr, RISCV_ISA_EXT_ZICNTR),
>> +    RISCV_ISA_EXT_DATA(zicsr, RISCV_ISA_EXT_ZICSR),
>> +    RISCV_ISA_EXT_DATA(zifencei, RISCV_ISA_EXT_ZIFENCEI),
>> +    RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE),
>> +    RISCV_ISA_EXT_DATA(zihpm, RISCV_ISA_EXT_ZIHPM),
>> +    RISCV_ISA_EXT_DATA(zbb, RISCV_ISA_EXT_ZBB),
>> +    RISCV_ISA_EXT_DATA(smaia, RISCV_ISA_EXT_SMAIA),
>> +    RISCV_ISA_EXT_DATA(ssaia, RISCV_ISA_EXT_SSAIA),
>> +};
>> +
>> +static const struct riscv_isa_ext_data __initconst required_extensions[] = {
>> +    RISCV_ISA_EXT_DATA(zbb, RISCV_ISA_EXT_ZBB),
>> +    RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE),
>> +};
> No Zicsr here?

Agree, it should be added.


>> +
>> +static int __init riscv_isa_parse_string(const char *isa,
>> +                                         unsigned long *out_bitmap)
>> +{
>> +    /*
>> +     * According to RISC-V device tree binding isa string must be all
>> +     * lowercase.
>> +     * To be sure that this is true, ASSERT below is added.
>> +     */
>> +    ASSERT(islower(isa[0]) && islower(isa[1]));
> This looks a little odd to me when you have ...
>
>> +    if ( (isa[0] != 'r') && (isa[1] != 'v') )
>> +        return -EINVAL;
> ... this anyway.

Agree, there is a little sense in having ASSERT() as, actually, if-condition does the same. I'll
drop ASSERT().

>
>> +#if defined(CONFIG_RISCV_32)
>> +    if ( isa[2] != '3' && isa[3] != '2' )
>> +        return -EINVAL;
>> +#elif defined(CONFIG_RISCV_64)
>> +    if ( isa[2] != '6' && isa[3] != '4' )
>> +        return -EINVAL;
>> +#else
>> +    #error "unsupported RISC-V bitness"
>> +#endif
>> +
>> +    isa += 4;
>> +
>> +    while ( *isa )
>> +    {
>> +        const char *ext = isa++;
>> +        const char *ext_end = isa;
>> +        bool ext_err = false;
>> +
>> +        switch ( *ext )
>> +        {
>> +        case 'x':
>> +        case 'X':
>> +            printk_once("Vendor extensions are ignored in riscv,isa."
>> +                        "Use riscv,isa-extensions instead\n");
> Interesting suggestion considering that doing so will end in a panic().

Do you think that "Use riscv,isa-extensions instead\n" would be better to add when "riscv,isa-extensions" handling
will be ready?

>> +static int __init riscv_fill_hwcap_from_ext_list(void)
>> +{
>> +    const struct dt_device_node *cpus = dt_find_node_by_path("/cpus");
>> +    const struct dt_device_node *cpu;
>> +    int res = -EINVAL;
>> +
>> +    if ( !cpus )
>> +    {
>> +        printk("Missing /cpus node in the device tree?\n");
>> +        return -EINVAL;
>> +    }
>> +
>> +    dt_for_each_child_node(cpus, cpu)
>> +    {
>> +        const char *isa;
>> +        int cpuid;
>> +
>> +        if ( !dt_device_type_is_equal(cpu, "cpu") )
>> +            continue;
>> +
>> +        cpuid = dt_get_cpuid_from_node(cpu);
>> +        if ( cpuid < 0 )
>> +            continue;
>> +
>> +        if ( dt_property_read_string(cpu, "riscv,isa-extensions", &isa) )
>> +        {
>> +            printk("Unable to find \"riscv,isa-extensions\" devicetree entry "
>> +                   "for cpu%d\n", cpuid);
> This is DT's number space for CPUs, isn't it? Any use of cpu%d (or CPU%d) or
> alike generally suggests the number is Xen's. This may want disambiguating
> here.

Yeah, the cpuid in this context is from the DT's namespace.

I'm not sure if we can get Xen's number at this stage, as only one CPU is used. We can only get
the DT's cpuid for Xen's CPU0 as|set_cpuid_to_hartid|(0, bootcpuid) has been already called.
For other CPUs, it depends on the order in which they are booted and the call to|set_cpuid_to_hartid()|.

I think that the best thing we can do is re-wording. I have two options:
1. "for DT's cpu%d node\n", cpuid);
2. "for hartid%d\n", cpuid); -> as based on the function name|set_cpuid_to_hartid|() we are using cpuid
    for Xen's cpu id and hart id - for real cpu id.
I prefer the first one option as it is more explicit and it doesn't require to know RISC-V specific terminology.

>> +static void __init riscv_fill_hwcap_from_isa_string(void)
>> +{
>> +    const struct dt_device_node *cpus = dt_find_node_by_path("/cpus");
>> +    const struct dt_device_node *cpu;
>> +
>> +    if ( !cpus )
>> +    {
>> +        printk("Missing /cpus node in the device tree?\n");
>> +        return;
>> +    }
>> +
>> +    dt_for_each_child_node(cpus, cpu)
>> +    {
>> +        DECLARE_BITMAP(this_isa, RISCV_ISA_EXT_MAX);
>> +        const char *isa;
>> +        int cpuid;
>> +
>> +        if ( !dt_device_type_is_equal(cpu, "cpu") )
>> +            continue;
>> +
>> +        cpuid = dt_get_cpuid_from_node(cpu);
>> +        if ( cpuid < 0 )
>> +            continue;
>> +
>> +        if ( dt_property_read_string(cpu, "riscv,isa", &isa) )
>> +        {
>> +            printk("Unable to find \"riscv,isa\" devicetree entry\n");
>> +            continue;
>> +        }
> Interestingly you don't log the CPU number here. What's the deal?

Missed to do that, I will add CPU number to printk().

>
>> +bool riscv_isa_extension_available(const unsigned long *isa_bitmap,
>> +                                   enum riscv_isa_ext_id bit)
>> +{
>> +    const unsigned long *bmap = (isa_bitmap) ? isa_bitmap : riscv_isa;
> Since it helps readability, may I suggest
>
>      const unsigned long *bmap = isa_bitmap ?: riscv_isa;
>
> or even getting away without the local var altogether:
>
>      if ( !isa_bitmap )
>          isa_bitmap = riscv_isa;
>
> ?

I think it would be better then go without local variable. I will proceed in that way.

>> +    if ( ret )
>> +    {
>> +        printk("Falling back to deprecated \"riscv,isa\"\n");
>> +        riscv_fill_hwcap_from_isa_string();
>> +    }
> I continue to find it irritating that you first try a function you
> know won't succeed (and will panic() if the DT item is actually there),
> in order to the log yet another message about using something that's
> deprecated. If this is deprecated, why don't we prefer (and hence
> support) the mor modern approach?

Even though it is considered deprecated, I haven't seen any DTS files in the Linux kernel using|riscv,isa-extension|.
Currently, Xen relies on the DTB generated by QEMU, which still uses|riscv,isa|. This is why, unfortunately, we still
need to support the deprecated|riscv,isa|. (Although I would much prefer using|riscv,isa-extension| since it's easier
to parse.)

Based on the fact that every source I checked doesn't use|riscv,isa-extension|, I decided to postpone adding support
for it. However, this task is still on my TODO list.

I completely agree that this is a frustrating approach. But at the time of porting the code, it seemed like the
best option. After you pointed it out, I think we could improve this part of the code in the following way:
   -    int ret = riscv_fill_hwcap_from_ext_list();
   -
   -    if ( ret )
   -    {
   -        printk("Falling back to deprecated \"riscv,isa\"\n");
   -        riscv_fill_hwcap_from_isa_string();
   -    }
   +    if ( riscv_fill_hwcap_from_isa_string() )
   +        panic("HW capabilities parsing fro isa string failed\n");
( with dropping of riscv_fill_hwcap_from_ext_list() and adding of return value for riscv_fill_hwcap_from_isa_string() )

>> +    for ( i = 0; i < req_extns_amount; i++ )
>> +    {
>> +        const struct riscv_isa_ext_data ext = required_extensions[i];
>> +
>> +        if ( !riscv_isa_extension_available(NULL, ext.id) )
>> +        {
>> +            printk("Xen requires extension: %s\n", ext.name);
>> +            all_extns_available = false;
>> +        }
>> +    }
>> +
>> +    if ( !all_extns_available )
>> +        panic("Look why the extensions above are needed in booting.txt\n");
> Where's this booting.txt? I don't think people should be made hunt it
> down ...

I will add ("...docs/misc/riscv/booting.txt\n").

As an other option I could paste here a link to booting.txt ( it will violate code string length but I think it is
fine in the current case ):
  panic("Look why the extensions above are needed inhttps://gitlab.com/xen-project/xen/-/blob/staging/docs/misc/riscv/booting.txt?ref_type=heads \n");

Thanks.

~ Oleksii

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

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 1/20/25 4:13 PM, Jan Beulich wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:0ceaa04e-36ac-4099-8a84-977a08ba16a2@suse.com">
      <pre wrap="" class="moz-quote-pre">On 15.01.2025 17:36, Oleksii Kurochko wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">--- /dev/null
+++ b/xen/arch/riscv/cpufeature.c
@@ -0,0 +1,506 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Taken for Linux kernel v6.12-rc3 and modified by
+ * Oleksii Kurochko <a class="moz-txt-link-rfc2396E" href="mailto:oleksii.kurochko@gmail.com">&lt;oleksii.kurochko@gmail.com&gt;</a>:
+ *
+ * - Drop unconditional setting of {RISCV_ISA_EXT_ZICSR,
+ *   RISCV_ISA_EXT_ZIFENCEI, RISCV_ISA_EXT_ZICNTR, RISCV_ISA_EXT_ZIHPM} as they
+ *   are now part of the riscv,isa string.
+ * - Remove saving of the ISA for each CPU, only the common available ISA is
+ *   saved.
+ * - Remove ACPI-related code as ACPI is not supported by Xen.
+ * - Drop handling of elf_hwcap, since Xen does not provide hwcap to
+ *   userspace.
+ * - Replace of_cpu_device_node_get() API, which is not available in Xen,
+ *   with a combination of dt_for_each_child_node(), dt_device_type_is_equal(),
+ *   and dt_get_cpuid_from_node() to retrieve cpuid and riscv,isa in
+ *   riscv_fill_hwcap_from_isa_string().
+ * - Rename arguments of __RISCV_ISA_EXT_DATA() from _name to ext_name, and
+ *   _id to ext_id for clarity.
+ * - Replace instances of __RISCV_ISA_EXT_DATA with RISCV_ISA_EXT_DATA.
+ * - Replace instances of __riscv_isa_extension_available with
+ *   riscv_isa_extension_available for consistency. Also, update the type of
+ *   `bit` argument of riscv_isa_extension_available().
+ * - Redefine RISCV_ISA_EXT_DATA() to work only with ext_name and ext_id,
+ *   as other fields are not used in Xen currently.
+ * - Add check of first 4 letters of riscv,isa string to
+ *   riscv_isa_parse_string() as Xen doesn't do this check before so it is
+ *   necessary to check correctness of riscv,isa string. ( it should start with
+ *   rv{32,64} with taking into account lower case of "rv").
+ * - Drop an argument of riscv_fill_hwcap() and riscv_fill_hwcap_from_isa_string()
+ *   as it isn't used, at the moment.
+ * - Update the comment message about QEMU workaround.
+ * - s/pr_info/printk.
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
As said before - having this in the commit message is likely enough. Putting
it here as well is only risking for this to go stale (perhaps rather sooner
than later).</pre>
    </blockquote>
    <pre>I misunderstood you last time. I will remove this comment entirely to avoid dealing
with potential staleness in the future.

</pre>
    <blockquote type="cite"
      cite="mid:0ceaa04e-36ac-4099-8a84-977a08ba16a2@suse.com">
      <pre wrap="" class="moz-quote-pre">

</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">+ * Copyright (C) 2015 ARM Ltd.
+ * Copyright (C) 2017 SiFive
+ * Copyright (C) 2024 Vates
+ */
+
+#include &lt;xen/bitmap.h&gt;
+#include &lt;xen/ctype.h&gt;
+#include &lt;xen/device_tree.h&gt;
+#include &lt;xen/errno.h&gt;
+#include &lt;xen/init.h&gt;
+#include &lt;xen/lib.h&gt;
+#include &lt;xen/sections.h&gt;
+
+#include &lt;asm/cpufeature.h&gt;
+
+#ifdef CONFIG_ACPI
+#error "cpufeature.c functions should be updated to support ACPI"
+#endif
+
+struct riscv_isa_ext_data {
+    unsigned int id;
+    const char *name;
+};
+
+#define RISCV_ISA_EXT_DATA(ext_name, ext_id)    \
+{                                               \
+    .id = ext_id,                               \
+    .name = #ext_name,                          \
+}
+
+/* Host ISA bitmap */
+static __ro_after_init DECLARE_BITMAP(riscv_isa, RISCV_ISA_EXT_MAX);
+
+static int __init dt_get_cpuid_from_node(const struct dt_device_node *cpu)
+{
+    const __be32 *prop;
+    unsigned int reg_len;
+
+    if ( dt_n_size_cells(cpu) != 0 )
+        printk("cpu node `%s`: #size-cells %d\n",
+               dt_node_full_name(cpu), dt_n_size_cells(cpu));
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
The call to dt_n_size_cells() is here really just for the printk()?</pre>
    </blockquote>
    <pre>Yes, it is only used for debug purposes.

Based on DT's bindings ( <a class="moz-txt-link-freetext" href="https://www.kernel.org/doc/Documentation/devicetree/bindings/riscv/cpus.txt">https://www.kernel.org/doc/Documentation/devicetree/bindings/riscv/cpus.txt</a> )
and RISC-V's DTS files in kernel #size-cells for cpu node is expected to be 0.
</pre>
    <blockquote type="cite"
      cite="mid:0ceaa04e-36ac-4099-8a84-977a08ba16a2@suse.com">
      <pre wrap="" class="moz-quote-pre">
</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">+    prop = dt_get_property(cpu, "reg", &amp;reg_len);
+    if ( !prop )
+    {
+        printk("cpu node `%s`: has no reg property\n", dt_node_full_name(cpu));
+        return -EINVAL;
+    }
+
+    if ( reg_len &lt; dt_cells_to_size(dt_n_addr_cells(cpu)) )
+    {
+        printk("cpu node `%s`: reg property too short\n",
+               dt_node_full_name(cpu));
+        return -EINVAL;
+    }
+
+    return dt_read_paddr(prop, dt_n_addr_cells(cpu));
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
How come it is okay to (silently) truncate here from paddr_t to int?</pre>
    </blockquote>
    <pre>Specifically in this case it is okay as it is low chance that cpuid will be higher then the size of `int`.
But based on RISC-V spec. hartid could be from 0 to ((1ULL &lt;&lt; (MXLEN)) - 1) [MXLEN is the size of register]
so it would be better to use `long` instead of `int` as return value and use `long` for cpuid variable in
the callers of dt_get_cpuid_from_node().

Probably it would be even better to return error code as `int` to have ability to verify if something wrong
happens during dt_get_cpuid_from_node() and add another one argument to dt_get_cpuid_from_node() with paddr_t
type ( or `unsigned long` as type `paddr_t` looks confusing a little bit for describing of cpu id ) and set this
argument before return.
 </pre>
    <blockquote type="cite"
      cite="mid:0ceaa04e-36ac-4099-8a84-977a08ba16a2@suse.com">
      <pre wrap="" class="moz-quote-pre">

</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">+}
+
+/*
+ * The canonical order of ISA extension names in the ISA string is defined in
+ * chapter 27 of the unprivileged specification.
+ *
+ * The specification uses vague wording, such as should, when it comes to
+ * ordering, so for our purposes the following rules apply:
+ *
+ * 1. All multi-letter extensions must be separated from other extensions by an
+ *    underscore.
+ *
+ * 2. Additional standard extensions (starting with 'Z') must be sorted after
+ *    single-letter extensions and before any higher-privileged extensions.
+ *
+ * 3. The first letter following the 'Z' conventionally indicates the most
+ *    closely related alphabetical extension category, IMAFDQLCBKJTPVH.
+ *    If multiple 'Z' extensions are named, they must be ordered first by
+ *    category, then alphabetically within a category.
+ *
+ * 4. Standard supervisor-level extensions (starting with 'S') must be listed
+ *    after standard unprivileged extensions.  If multiple supervisor-level
+ *    extensions are listed, they must be ordered alphabetically.
+ *
+ * 5. Standard machine-level extensions (starting with 'Zxm') must be listed
+ *    after any lower-privileged, standard extensions.  If multiple
+ *    machine-level extensions are listed, they must be ordered
+ *    alphabetically.
+ *
+ * 6. Non-standard extensions (starting with 'X') must be listed after all
+ *    standard extensions. If multiple non-standard extensions are listed, they
+ *    must be ordered alphabetically.
+ *
+ * An example string following the order is:
+ *    rv64imadc_zifoo_zigoo_zafoo_sbar_scar_zxmbaz_xqux_xrux
+ *
+ * New entries to this struct should follow the ordering rules described above.
+ *
+ * Extension name must be all lowercase ( according to device-tree binding )
+ * and strncmp() is used in match_isa_ext() to compare extension names instead
+ * of strncasecmp().
+ */
+const struct riscv_isa_ext_data __initconst riscv_isa_ext[] = {
+    RISCV_ISA_EXT_DATA(i, RISCV_ISA_EXT_i),
+    RISCV_ISA_EXT_DATA(m, RISCV_ISA_EXT_m),
+    RISCV_ISA_EXT_DATA(a, RISCV_ISA_EXT_a),
+    RISCV_ISA_EXT_DATA(f, RISCV_ISA_EXT_f),
+    RISCV_ISA_EXT_DATA(d, RISCV_ISA_EXT_d),
+    RISCV_ISA_EXT_DATA(q, RISCV_ISA_EXT_q),
+    RISCV_ISA_EXT_DATA(h, RISCV_ISA_EXT_h),
+    RISCV_ISA_EXT_DATA(zicntr, RISCV_ISA_EXT_ZICNTR),
+    RISCV_ISA_EXT_DATA(zicsr, RISCV_ISA_EXT_ZICSR),
+    RISCV_ISA_EXT_DATA(zifencei, RISCV_ISA_EXT_ZIFENCEI),
+    RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE),
+    RISCV_ISA_EXT_DATA(zihpm, RISCV_ISA_EXT_ZIHPM),
+    RISCV_ISA_EXT_DATA(zbb, RISCV_ISA_EXT_ZBB),
+    RISCV_ISA_EXT_DATA(smaia, RISCV_ISA_EXT_SMAIA),
+    RISCV_ISA_EXT_DATA(ssaia, RISCV_ISA_EXT_SSAIA),
+};
+
+static const struct riscv_isa_ext_data __initconst required_extensions[] = {
+    RISCV_ISA_EXT_DATA(zbb, RISCV_ISA_EXT_ZBB),
+    RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE),
+};
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
No Zicsr here?</pre>
    </blockquote>
    <pre>Agree, it should be added.


</pre>
    <blockquote type="cite"
      cite="mid:0ceaa04e-36ac-4099-8a84-977a08ba16a2@suse.com">
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">+
+static int __init riscv_isa_parse_string(const char *isa,
+                                         unsigned long *out_bitmap)
+{
+    /*
+     * According to RISC-V device tree binding isa string must be all
+     * lowercase.
+     * To be sure that this is true, ASSERT below is added.
+     */
+    ASSERT(islower(isa[0]) &amp;&amp; islower(isa[1]));
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
This looks a little odd to me when you have ...

</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">+    if ( (isa[0] != 'r') &amp;&amp; (isa[1] != 'v') )
+        return -EINVAL;
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
... this anyway.</pre>
    </blockquote>
    <pre>Agree, there is a little sense in having ASSERT() as, actually, if-condition does the same. I'll
drop ASSERT().

</pre>
    <blockquote type="cite"
      cite="mid:0ceaa04e-36ac-4099-8a84-977a08ba16a2@suse.com">
      <pre wrap="" class="moz-quote-pre">

</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">+#if defined(CONFIG_RISCV_32)
+    if ( isa[2] != '3' &amp;&amp; isa[3] != '2' )
+        return -EINVAL;
+#elif defined(CONFIG_RISCV_64)
+    if ( isa[2] != '6' &amp;&amp; isa[3] != '4' )
+        return -EINVAL;
+#else
+    #error "unsupported RISC-V bitness"
+#endif
+
+    isa += 4;
+
+    while ( *isa )
+    {
+        const char *ext = isa++;
+        const char *ext_end = isa;
+        bool ext_err = false;
+
+        switch ( *ext )
+        {
+        case 'x':
+        case 'X':
+            printk_once("Vendor extensions are ignored in riscv,isa."
+                        "Use riscv,isa-extensions instead\n");
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
Interesting suggestion considering that doing so will end in a panic().</pre>
    </blockquote>
    <pre>Do you think that "Use riscv,isa-extensions instead\n" would be better to add when "riscv,isa-extensions" handling
will be ready?

</pre>
    <blockquote type="cite"
      cite="mid:0ceaa04e-36ac-4099-8a84-977a08ba16a2@suse.com">
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">+static int __init riscv_fill_hwcap_from_ext_list(void)
+{
+    const struct dt_device_node *cpus = dt_find_node_by_path("/cpus");
+    const struct dt_device_node *cpu;
+    int res = -EINVAL;
+
+    if ( !cpus )
+    {
+        printk("Missing /cpus node in the device tree?\n");
+        return -EINVAL;
+    }
+
+    dt_for_each_child_node(cpus, cpu)
+    {
+        const char *isa;
+        int cpuid;
+
+        if ( !dt_device_type_is_equal(cpu, "cpu") )
+            continue;
+
+        cpuid = dt_get_cpuid_from_node(cpu);
+        if ( cpuid &lt; 0 )
+            continue;
+
+        if ( dt_property_read_string(cpu, "riscv,isa-extensions", &amp;isa) )
+        {
+            printk("Unable to find \"riscv,isa-extensions\" devicetree entry "
+                   "for cpu%d\n", cpuid);
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
This is DT's number space for CPUs, isn't it? Any use of cpu%d (or CPU%d) or
alike generally suggests the number is Xen's. This may want disambiguating
here.</pre>
    </blockquote>
    <pre>Yeah, the cpuid in this context is from the DT's namespace.

I'm not sure if we can get Xen's number at this stage, as only one CPU is used. We can only get
the DT's cpuid for Xen's CPU0 as <code>set_cpuid_to_hartid</code>(0, bootcpuid) has been already called.
For other CPUs, it depends on the order in which they are booted and the call to <code>set_cpuid_to_hartid()</code>.

I think that the best thing we can do is re-wording. I have two options:
1. "for DT's cpu%d node\n", cpuid);
2. "for hartid%d\n", cpuid); -&gt; as based on the function name <code>set_cpuid_to_hartid</code>() we are using cpuid
   for Xen's cpu id and hart id - for real cpu id.
I prefer the first one option as it is more explicit and it doesn't require to know RISC-V specific terminology.

</pre>
    <blockquote type="cite"
      cite="mid:0ceaa04e-36ac-4099-8a84-977a08ba16a2@suse.com">
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">+static void __init riscv_fill_hwcap_from_isa_string(void)
+{
+    const struct dt_device_node *cpus = dt_find_node_by_path("/cpus");
+    const struct dt_device_node *cpu;
+
+    if ( !cpus )
+    {
+        printk("Missing /cpus node in the device tree?\n");
+        return;
+    }
+
+    dt_for_each_child_node(cpus, cpu)
+    {
+        DECLARE_BITMAP(this_isa, RISCV_ISA_EXT_MAX);
+        const char *isa;
+        int cpuid;
+
+        if ( !dt_device_type_is_equal(cpu, "cpu") )
+            continue;
+
+        cpuid = dt_get_cpuid_from_node(cpu);
+        if ( cpuid &lt; 0 )
+            continue;
+
+        if ( dt_property_read_string(cpu, "riscv,isa", &amp;isa) )
+        {
+            printk("Unable to find \"riscv,isa\" devicetree entry\n");
+            continue;
+        }
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
Interestingly you don't log the CPU number here. What's the deal?</pre>
    </blockquote>
    <pre>Missed to do that, I will add CPU number to printk().

</pre>
    <blockquote type="cite"
      cite="mid:0ceaa04e-36ac-4099-8a84-977a08ba16a2@suse.com">
      <pre wrap="" class="moz-quote-pre">

</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">+bool riscv_isa_extension_available(const unsigned long *isa_bitmap,
+                                   enum riscv_isa_ext_id bit)
+{
+    const unsigned long *bmap = (isa_bitmap) ? isa_bitmap : riscv_isa;
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
Since it helps readability, may I suggest

    const unsigned long *bmap = isa_bitmap ?: riscv_isa;

or even getting away without the local var altogether:

    if ( !isa_bitmap )
        isa_bitmap = riscv_isa;

?</pre>
    </blockquote>
    <pre>I think it would be better then go without local variable. I will proceed in that way.

</pre>
    <blockquote type="cite"
      cite="mid:0ceaa04e-36ac-4099-8a84-977a08ba16a2@suse.com">
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">+    if ( ret )
+    {
+        printk("Falling back to deprecated \"riscv,isa\"\n");
+        riscv_fill_hwcap_from_isa_string();
+    }
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
I continue to find it irritating that you first try a function you
know won't succeed (and will panic() if the DT item is actually there),
in order to the log yet another message about using something that's
deprecated. If this is deprecated, why don't we prefer (and hence
support) the mor modern approach?</pre>
    </blockquote>
    <pre>Even though it is considered deprecated, I haven't seen any DTS files in the Linux kernel using <code>riscv,isa-extension</code>.
Currently, Xen relies on the DTB generated by QEMU, which still uses <code>riscv,isa</code>. This is why, unfortunately, we still
need to support the deprecated <code>riscv,isa</code>. (Although I would much prefer using <code>riscv,isa-extension</code> since it's easier
to parse.)</pre>
    <pre>Based on the fact that every source I checked doesn't use <code>riscv,isa-extension</code>, I decided to postpone adding support
for it. However, this task is still on my TODO list.</pre>
    <pre>I completely agree that this is a frustrating approach. But at the time of porting the code, it seemed like the
best option. After you pointed it out, I think we could improve this part of the code in the following way:
  -    int ret = riscv_fill_hwcap_from_ext_list();
  -
  -    if ( ret )
  -    {
  -        printk("Falling back to deprecated \"riscv,isa\"\n");
  -        riscv_fill_hwcap_from_isa_string();
  -    }
  +    if ( riscv_fill_hwcap_from_isa_string() )
  +        panic("HW capabilities parsing fro isa string failed\n");
( with dropping of riscv_fill_hwcap_from_ext_list() and adding of return value for riscv_fill_hwcap_from_isa_string() )

</pre>
    <blockquote type="cite"
      cite="mid:0ceaa04e-36ac-4099-8a84-977a08ba16a2@suse.com">
      <pre wrap="" class="moz-quote-pre">
</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">+    for ( i = 0; i &lt; req_extns_amount; i++ )
+    {
+        const struct riscv_isa_ext_data ext = required_extensions[i];
+
+        if ( !riscv_isa_extension_available(NULL, ext.id) )
+        {
+            printk("Xen requires extension: %s\n", ext.name);
+            all_extns_available = false;
+        }
+    }
+
+    if ( !all_extns_available )
+        panic("Look why the extensions above are needed in booting.txt\n");
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
Where's this booting.txt? I don't think people should be made hunt it
down ...</pre>
    </blockquote>
    <pre>I will add ("...docs/misc/riscv/booting.txt\n").

As an other option I could paste here a link to booting.txt ( it will violate code string length but I think it is
fine in the current case ):
 panic("Look why the extensions above are needed in <a class="moz-txt-link-freetext" href="https://gitlab.com/xen-project/xen/-/blob/staging/docs/misc/riscv/booting.txt?ref_type=heads">https://gitlab.com/xen-project/xen/-/blob/staging/docs/misc/riscv/booting.txt?ref_type=heads</a> \n");

Thanks.

~ Oleksii
</pre>
  </body>
</html>

--------------C0x33TP0pSjxn0DaWykmYcnz--


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 12:59:53 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 12:59:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875422.1285861 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taDrA-0001wX-FB; Tue, 21 Jan 2025 12:59:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875422.1285861; Tue, 21 Jan 2025 12:59:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taDrA-0001wQ-CY; Tue, 21 Jan 2025 12:59:48 +0000
Received: by outflank-mailman (input) for mailman id 875422;
 Tue, 21 Jan 2025 12:59:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=jEc5=UN=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1taDr9-0001wK-Gn
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 12:59:47 +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 9664e1c8-d7f7-11ef-99a4-01e77a169b0f;
 Tue, 21 Jan 2025 13:59:45 +0100 (CET)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-ab2e308a99bso1162453566b.1
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 04:59:45 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab384ce2295sm759220466b.64.2025.01.21.04.59.43
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 21 Jan 2025 04:59:44 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9664e1c8-d7f7-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737464385; x=1738069185; 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=yYbG1mnwBwoO1fMs1J6m/ZrdDQNxIQ0sdrUC4ehUK/w=;
        b=hoaXvtoh/l6GcVJ/q/cMA4GGJFi4NSfXLkpQIdo1orbrfiZ4rrdCHeqjNschGVxmbU
         8YNTQlY7DIhnHbiNt+tPz2UbWM1xXSBRfwTAuncBmchzXGRiXRo42N+SzeG6j6pxH8Zn
         H5PlNPmyrvM/z0Xst/AOAXd4nIknXbPMm4SiM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737464385; x=1738069185;
        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=yYbG1mnwBwoO1fMs1J6m/ZrdDQNxIQ0sdrUC4ehUK/w=;
        b=scZXSy7snk8i+/DE4cBNy1aUIr1y/Ax7uEwhz6zUXG7b3srrsP5tRBQWCme9kf/RSn
         46EFD1rEjcqDSKw3qKq1NrkWE8fEVdzG9ibS9rNgGRyT0UR0+DgZ/oQKJ71IgEEsdIrF
         Fve/1Ty0fE3YjaHbCagzb2c9ZfQmy4k28ND0KUw7uAx0Ez6E7vC5kYaLAcwL142bp1gE
         K8YHm7rzcN2nfodbFJPYoML3IsLGTLHeKrj6rWLHM57mBxnGg33sEm4FgmppEr72n4X8
         I4EN5L26T/HofJ97iqzOWhgsgBBAgfOuQq00rL19HKv7oh3/P8A2ztk1HWV6VIrrigE8
         mrpA==
X-Forwarded-Encrypted: i=1; AJvYcCWg9nMDQNbSe5dxnBheXQVa9jRn68SZ1Y7Iu0R5Ee6igFTQMxwfHS3PXVrIcnmr7NVk/EqnQtMY1mk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxmGTIGS5PszqP+MWMYrvT4Do3vFzCv0DQuiOIWK5aDy7I8y4LY
	CXbwjzJbwBodf2TsVmTy/494e7jRAhehu0iUdMS7O05AIsubU2byDSzLWlfeqRs=
X-Gm-Gg: ASbGnctuj25a21LwyS7mIpPbfZfo1fIVPetNooZ444xXxSMX+6nuttibt0w80jpERlL
	LEKZHxb/zxq0kdeZBs8hLiyhchl9mIxEPI6XhIi2BpEXjWYDu6epgHfzpLvHGNZPhVj4CFXC6HN
	OMnfR/BW+gaAoXWIGr/md3oZ2mezweXHeYY9zG/voFP0ompfuXziu2RtZcfgA4d7t3Hp4ALwf+R
	YPrElqx1iCZAe3QIK3PEOTDRcVBjcjigXr/f3tW6LQDcmZ/MRxhZJr3ZmTigBV6GxpXlM4cB7k=
X-Google-Smtp-Source: AGHT+IGUDKYXpqQYnT9OkILoYpDC7XluPZv2Uu7/XCHA3FA71ofupfDZOrPYO5gzyG5h6rHAH90SpQ==
X-Received: by 2002:a17:907:6e8e:b0:ab3:4d1e:4606 with SMTP id a640c23a62f3a-ab38cbaa4d8mr1589695366b.3.1737464384524;
        Tue, 21 Jan 2025 04:59:44 -0800 (PST)
Date: Tue, 21 Jan 2025 13:59:43 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Teddy Astie <teddy.astie@vates.tech>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [XEN PATCH v5 1/3] x86/iommu: Disable IOMMU if cx16 isn't
 supported
Message-ID: <Z4-aPzCoegbp5T19@macbook.local>
References: <cover.1713433029.git.teddy.astie@vates.tech>
 <4656eab84f7b4b807fc61f54b9ba5c0fc4fae64d.1713433029.git.teddy.astie@vates.tech>
 <8cab0372-8c40-4648-bdbe-ff56844f289d@suse.com>
 <Z4-AbI2oKWCR5bws@macbook.local>
 <885982e1-fb1b-4b6a-a0bf-2251e5d9acf1@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <885982e1-fb1b-4b6a-a0bf-2251e5d9acf1@suse.com>

On Tue, Jan 21, 2025 at 12:20:17PM +0100, Jan Beulich wrote:
> On 21.01.2025 12:09, Roger Pau Monné wrote:
> > On Wed, Apr 24, 2024 at 04:27:10PM +0200, Jan Beulich wrote:
> >> On 18.04.2024 13:57, Teddy Astie wrote:
> >>> All hardware with VT-d/AMD-Vi has CMPXCHG16B support. Check this at
> >>> initialisation time, and remove the effectively-dead logic for the
> >>> non-cx16 case.
> >>
> >> As before: What about Xen itself running virtualized, and the underlying
> >> hypervisor surfacing an IOMMU but not CX16? It may be okay to ignore the
> >> IOMMU in such an event, but by not mentioning the case you give the
> >> appearance of not having considered it at all.
> >>
> >>> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
> >>> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
> >>> @@ -305,6 +305,12 @@ static int __init cf_check iov_detect(void)
> >>>      if ( !iommu_enable && !iommu_intremap )
> >>>          return 0;
> >>>  
> >>> +    if ( unlikely(!cpu_has_cx16) )
> >>> +    {
> >>> +        printk("AMD-Vi: CPU doesn't support CMPXCHG16B, disabling\n");
> >>> +        return -ENODEV;
> >>> +    }
> >>> +
> >>>      if ( (init_done ? amd_iommu_init_late()
> >>>                      : amd_iommu_init(false)) != 0 )
> >>>      {
> >>
> >> I did previously point out (and that's even visible in patch context here)
> >> that the per-vendor .setup() hooks aren't necessarily the first thing to
> >> run. Please can you make sure you address (verbally or by code) prior to
> >> submitting new versions?
> > 
> > I've re-visiting this as part of my other IOMMU IRTE atomic update
> > fix.
> > 
> > Would you prefer the check for CX16 be in the common x86
> > iommu_hardware_setup()?  That would be kind of layering violation, as
> > in principle a further IOMMU implementation on x86 might not require
> > CX16.  However I find it very unlikely, and hence I would be fine in
> > placing the check in iommu_hardware_setup() if you prefer it there.
> 
> No. The check needs replicating into the other hook that may run first,
> ->supports_x2apic(). And the ->enable_x2apic() hooks may want to gain
> respective assertions then.

Oh, I see.  So you either want patch 3 ahead of this, or both patches
merged into a single one.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 13:31:31 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 13:31:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875432.1285870 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taELk-0007Kg-PH; Tue, 21 Jan 2025 13:31:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875432.1285870; Tue, 21 Jan 2025 13:31:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taELk-0007KZ-Ml; Tue, 21 Jan 2025 13:31:24 +0000
Received: by outflank-mailman (input) for mailman id 875432;
 Tue, 21 Jan 2025 13:31:23 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Gode=UN=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1taELj-0007KT-UM
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 13:31:23 +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 00f38014-d7fc-11ef-a0e4-8be0dac302b0;
 Tue, 21 Jan 2025 14:31:22 +0100 (CET)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-43625c4a50dso39207775e9.0
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 05:31: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
 ffacd0b85a97d-38bf322a838sm13219048f8f.48.2025.01.21.05.31.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 21 Jan 2025 05:31:21 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 00f38014-d7fc-11ef-a0e4-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737466281; x=1738071081; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=2fuCUTPp7zNUUkC9Vvp8PuqkVeIs8e/F37hznUw6Xjo=;
        b=BhNFVgVsQnitVgcuK5oVKfYKnUOwBUdyUjty/wSDPqXhukHdvW036iblmfBhKUlEtr
         4uPxifAklkBA9rcxbsMaUhMkuCL8M8SSg+DQoaQv4aVZYyqk7NI6JFFr19Bo8xtNN6Z9
         Ke2draVC5xwMFteldMoOADn06tMdOk5dfDAZgUO/S3BszdTD/mQTxWxmRLAu/Mb8sAjv
         wsv4fM+ZSLdC8QG1tT1tBsvLyDwoqq55izQu/SBfD615RnX1MIT2J348WIP3rM4FuVzt
         A+XPWJi5RXVsjmby/GW/5k+8MLxBptveZqFcVzrPBPqVqO1X/2c/oA6I52p0oweptCvD
         e7BQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737466281; x=1738071081;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=2fuCUTPp7zNUUkC9Vvp8PuqkVeIs8e/F37hznUw6Xjo=;
        b=nXjk2Dg7jIRY8HqTG5DQnz4ypjQCliGtbNAwjM9Rje6hw35wFt9xTsbgYpbSGP0VmU
         QUi6Xt+arVlEacI8yEuTwtVtfZpSj+WprbKspsDI5t1z9/GdY3bzfUz6BJoEp2HVYrTo
         SyauU0f6dZrwJ1o1/u5ZkZO3FId7aUx9U7pTjj3a1jYCrZxDpvYKo6hgyOeK6eHuvvea
         Z1se6fJ6n5LueiA2fjcqQe1kSvf2h7a5NjTSsYUeA2GgYebHa8aZLxdTb4mtGAXUh7Mi
         LqCrwMAZzviJuK1TqrfhfwJcVYRoDkE42YZd9pq0nomsVNbgzm1bGFJ5EKR6Te8kiLht
         PIBw==
X-Forwarded-Encrypted: i=1; AJvYcCV9sYw3qLlbdNw8tOLzI6jevGEmhmADQX57FEwJizoRbnMMtAiZTn/GYwpaImE6kvjI3AbsU4Mid74=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxVsk0EsOBj5SCd75iPVHNjGKkwoHh/bK7PBOl2nT0w8/M+75Ij
	XHqwXbBeBYxRBZWtgn10GIVLkhVtjF73sFk/ZSrpew9741gbeGwVty0o52vD5Q==
X-Gm-Gg: ASbGncvv7njRcSrUiwS4KvR7qzVWophRyr93Tkr9y1KGfhicEiEzGOShGgLtimHpBQ6
	tTC0tvrYAheSB4u/p7+O4r3UD1Hynn7zl7f//r3EKQ5xQ8z2TPtr9muWAA/Fo1FRJQP3Xhq2J/D
	uPZzUT6hQJoD1qC4CNes2JVGbjyf0wCRSn/FwxeSNC6EtLIos8jMeYqY4ss1aOjkrjve9EIP8Uc
	V04jf1ERa86hQSgmf9yuOp8S+UvLrksjqLDGhfFlmMUPqYsxE+sVRG696f39ujyjno2NuovJnBS
	zO47+eHXwC7zxswAb+oMXim7wUPu77sfvt/+IWEy5rDP99TilG/v+po=
X-Google-Smtp-Source: AGHT+IFQeYqRSIktfzxC33wPeR7Hf55ZTEYfZwB1+RFZjdlx7z8oqeGbCYnNWT6CmdcxedbLw0v6VA==
X-Received: by 2002:a05:6000:18a2:b0:385:f840:e613 with SMTP id ffacd0b85a97d-38bf57b6d9amr19394726f8f.51.1737466281444;
        Tue, 21 Jan 2025 05:31:21 -0800 (PST)
Message-ID: <b88cfbd0-b4f1-4f70-971f-574198eca830@suse.com>
Date: Tue, 21 Jan 2025 14:31:20 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] xen/riscv: identify specific ISA supported by cpu
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Alistair Francis <alistair.francis@wdc.com>,
 Bob Eshleman <bobbyeshleman@gmail.com>, Connor Davis
 <connojdavis@gmail.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <0a6562ae1e22e3fe607054b33df3467c12d0b276.1736956861.git.oleksii.kurochko@gmail.com>
 <0ceaa04e-36ac-4099-8a84-977a08ba16a2@suse.com>
 <59dd7cdd-b353-4463-966e-345266a7a54e@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <59dd7cdd-b353-4463-966e-345266a7a54e@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 21.01.2025 13:37, Oleksii Kurochko wrote:
> On 1/20/25 4:13 PM, Jan Beulich wrote:
>> On 15.01.2025 17:36, Oleksii Kurochko wrote:
>>> +#if defined(CONFIG_RISCV_32)
>>> +    if ( isa[2] != '3' && isa[3] != '2' )
>>> +        return -EINVAL;
>>> +#elif defined(CONFIG_RISCV_64)
>>> +    if ( isa[2] != '6' && isa[3] != '4' )
>>> +        return -EINVAL;
>>> +#else
>>> +    #error "unsupported RISC-V bitness"
>>> +#endif
>>> +
>>> +    isa += 4;
>>> +
>>> +    while ( *isa )
>>> +    {
>>> +        const char *ext = isa++;
>>> +        const char *ext_end = isa;
>>> +        bool ext_err = false;
>>> +
>>> +        switch ( *ext )
>>> +        {
>>> +        case 'x':
>>> +        case 'X':
>>> +            printk_once("Vendor extensions are ignored in riscv,isa."
>>> +                        "Use riscv,isa-extensions instead\n");
>> Interesting suggestion considering that doing so will end in a panic().
> 
> Do you think that "Use riscv,isa-extensions instead\n" would be better to add when "riscv,isa-extensions" handling
> will be ready?

Possibly (see also below). At the very least the code should be self-consistent.

>>> +static int __init riscv_fill_hwcap_from_ext_list(void)
>>> +{
>>> +    const struct dt_device_node *cpus = dt_find_node_by_path("/cpus");
>>> +    const struct dt_device_node *cpu;
>>> +    int res = -EINVAL;
>>> +
>>> +    if ( !cpus )
>>> +    {
>>> +        printk("Missing /cpus node in the device tree?\n");
>>> +        return -EINVAL;
>>> +    }
>>> +
>>> +    dt_for_each_child_node(cpus, cpu)
>>> +    {
>>> +        const char *isa;
>>> +        int cpuid;
>>> +
>>> +        if ( !dt_device_type_is_equal(cpu, "cpu") )
>>> +            continue;
>>> +
>>> +        cpuid = dt_get_cpuid_from_node(cpu);
>>> +        if ( cpuid < 0 )
>>> +            continue;
>>> +
>>> +        if ( dt_property_read_string(cpu, "riscv,isa-extensions", &isa) )
>>> +        {
>>> +            printk("Unable to find \"riscv,isa-extensions\" devicetree entry "
>>> +                   "for cpu%d\n", cpuid);
>> This is DT's number space for CPUs, isn't it? Any use of cpu%d (or CPU%d) or
>> alike generally suggests the number is Xen's. This may want disambiguating
>> here.
> 
> Yeah, the cpuid in this context is from the DT's namespace.
> 
> I'm not sure if we can get Xen's number at this stage, as only one CPU is used. We can only get
> the DT's cpuid for Xen's CPU0 as|set_cpuid_to_hartid|(0, bootcpuid) has been already called.
> For other CPUs, it depends on the order in which they are booted and the call to|set_cpuid_to_hartid()|.
> 
> I think that the best thing we can do is re-wording. I have two options:
> 1. "for DT's cpu%d node\n", cpuid);
> 2. "for hartid%d\n", cpuid); -> as based on the function name|set_cpuid_to_hartid|() we are using cpuid
>     for Xen's cpu id and hart id - for real cpu id.
> I prefer the first one option as it is more explicit and it doesn't require to know RISC-V specific terminology.

I'd be fine with either; all I care about is absence of ambiguity.

>>> +    if ( ret )
>>> +    {
>>> +        printk("Falling back to deprecated \"riscv,isa\"\n");
>>> +        riscv_fill_hwcap_from_isa_string();
>>> +    }
>> I continue to find it irritating that you first try a function you
>> know won't succeed (and will panic() if the DT item is actually there),
>> in order to the log yet another message about using something that's
>> deprecated. If this is deprecated, why don't we prefer (and hence
>> support) the mor modern approach?
> 
> Even though it is considered deprecated, I haven't seen any DTS files in the Linux kernel using|riscv,isa-extension|.
> Currently, Xen relies on the DTB generated by QEMU, which still uses|riscv,isa|. This is why, unfortunately, we still
> need to support the deprecated|riscv,isa|. (Although I would much prefer using|riscv,isa-extension| since it's easier
> to parse.)
> 
> Based on the fact that every source I checked doesn't use|riscv,isa-extension|, I decided to postpone adding support
> for it. However, this task is still on my TODO list.
> 
> I completely agree that this is a frustrating approach. But at the time of porting the code, it seemed like the
> best option. After you pointed it out, I think we could improve this part of the code in the following way:
>    -    int ret = riscv_fill_hwcap_from_ext_list();
>    -
>    -    if ( ret )
>    -    {
>    -        printk("Falling back to deprecated \"riscv,isa\"\n");
>    -        riscv_fill_hwcap_from_isa_string();
>    -    }
>    +    if ( riscv_fill_hwcap_from_isa_string() )
>    +        panic("HW capabilities parsing fro isa string failed\n");
> ( with dropping of riscv_fill_hwcap_from_ext_list() and adding of return value for riscv_fill_hwcap_from_isa_string() )

That's probably best indeed. The panic() message may then want conditionalizing
upon there actually being "riscv,isa-extension" in DT. If there is, you may want
to say that support for it needs implementing, in place of the above.

>>> +    for ( i = 0; i < req_extns_amount; i++ )
>>> +    {
>>> +        const struct riscv_isa_ext_data ext = required_extensions[i];
>>> +
>>> +        if ( !riscv_isa_extension_available(NULL, ext.id) )
>>> +        {
>>> +            printk("Xen requires extension: %s\n", ext.name);
>>> +            all_extns_available = false;
>>> +        }
>>> +    }
>>> +
>>> +    if ( !all_extns_available )
>>> +        panic("Look why the extensions above are needed in booting.txt\n");
>> Where's this booting.txt? I don't think people should be made hunt it
>> down ...
> 
> I will add ("...docs/misc/riscv/booting.txt\n").
> 
> As an other option I could paste here a link to booting.txt ( it will violate code string length but I think it is
> fine in the current case ):
>   panic("Look why the extensions above are needed inhttps://gitlab.com/xen-project/xen/-/blob/staging/docs/misc/riscv/booting.txt?ref_type=heads \n");

String length is of no real concern. What I'd recommend against though
is to reference anything other than the canonical tree (which lives on
xenbits, not at gitlab). Yet better might be to refer to the produced
documentation
(https://xenbits.xenproject.org/docs/unstable/misc/riscv/booting.txt)
rather than a file in a source tree / git repo.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 13:41:07 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 13:41:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875440.1285881 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taEUy-0000dt-Lk; Tue, 21 Jan 2025 13:40:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875440.1285881; Tue, 21 Jan 2025 13:40:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taEUy-0000dm-I4; Tue, 21 Jan 2025 13:40:56 +0000
Received: by outflank-mailman (input) for mailman id 875440;
 Tue, 21 Jan 2025 13:40:55 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=PLWh=UN=linux.ibm.com=agordeev@srs-se1.protection.inumbo.net>)
 id 1taEUx-0000dg-7r
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 13:40:55 +0000
Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com
 [148.163.156.1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 544c93f3-d7fd-11ef-a0e4-8be0dac302b0;
 Tue, 21 Jan 2025 14:40:52 +0100 (CET)
Received: from pps.filterd (m0360083.ppops.net [127.0.0.1])
 by mx0a-001b2d01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 50LBcWDl021758;
 Tue, 21 Jan 2025 13:40:21 GMT
Received: from ppma11.dal12v.mail.ibm.com
 (db.9e.1632.ip4.static.sl-reverse.com [50.22.158.219])
 by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 44a1n9b0sf-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Tue, 21 Jan 2025 13:40:21 +0000 (GMT)
Received: from pps.filterd (ppma11.dal12v.mail.ibm.com [127.0.0.1])
 by ppma11.dal12v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 50LAtOsq021012;
 Tue, 21 Jan 2025 13:40:19 GMT
Received: from smtprelay01.fra02v.mail.ibm.com ([9.218.2.227])
 by ppma11.dal12v.mail.ibm.com (PPS) with ESMTPS id 448sb1b14q-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Tue, 21 Jan 2025 13:40:19 +0000
Received: from smtpav07.fra02v.mail.ibm.com (smtpav07.fra02v.mail.ibm.com
 [10.20.54.106])
 by smtprelay01.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id
 50LDeIWj60031254
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Tue, 21 Jan 2025 13:40:18 GMT
Received: from smtpav07.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id 25C3B2004B;
 Tue, 21 Jan 2025 13:40:18 +0000 (GMT)
Received: from smtpav07.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id 7FD1A20040;
 Tue, 21 Jan 2025 13:40:17 +0000 (GMT)
Received: from li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com (unknown
 [9.155.204.135])
 by smtpav07.fra02v.mail.ibm.com (Postfix) with ESMTPS;
 Tue, 21 Jan 2025 13:40:17 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 544c93f3-d7fd-11ef-a0e4-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc
	:content-type:date:from:in-reply-to:message-id:mime-version
	:references:subject:to; s=pp1; bh=1XuHjAhe+6crgeyPxGiThULHkHEa/Q
	wDtL3yiBvZqn4=; b=XXJc1fjY1LEte8uWYOHY0rVlVq4wX9PCcoXpIbn1EYs9EL
	OD4/8pPTNQ9wGah7zwpokGzeZLvKhyS2XwyswSQynQSvx4Pq0nVXT5v0PMm1KdzN
	F6FmU2v9zN3MF0dGtVIr8337iz/SeaELL+AkChcaIBTAfjVK9Q1TKCVQHZUYF4b8
	lkEmavTZcGG7bcRDLLuw9HOFrKWm+iyEw+rBb1iDcR2ksQakFyzbWZB9l+0n9NZH
	7bFXS3CXhWJ3qAfxFUQeEb9d90I2xBmDXS8qIuY9SsKjzzFL1VStL4eYIhJR/WhB
	kacwVPn3TvuRt93neu9S0HZxZA9oxnhjkLM3qkFg==
Date: Tue, 21 Jan 2025 14:40:16 +0100
From: Alexander Gordeev <agordeev@linux.ibm.com>
To: Joel Granados <joel.granados@kernel.org>
Cc: Thomas =?iso-8859-1?Q?Wei=DFschuh?= <linux@weissschuh.net>,
        Kees Cook <kees@kernel.org>, Luis Chamberlain <mcgrof@kernel.org>,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
        linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,
        linux-s390@vger.kernel.org, linux-crypto@vger.kernel.org,
        openipmi-developer@lists.sourceforge.net,
        intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
        intel-xe@lists.freedesktop.org, linux-hyperv@vger.kernel.org,
        linux-rdma@vger.kernel.org, linux-raid@vger.kernel.org,
        linux-scsi@vger.kernel.org, linux-serial@vger.kernel.org,
        xen-devel@lists.xenproject.org, linux-aio@kvack.org,
        linux-fsdevel@vger.kernel.org, netfs@lists.linux.dev,
        codalist@coda.cs.cmu.edu, linux-mm@kvack.org,
        linux-nfs@vger.kernel.org, ocfs2-devel@lists.linux.dev,
        fsverity@lists.linux.dev, linux-xfs@vger.kernel.org,
        io-uring@vger.kernel.org, bpf@vger.kernel.org,
        kexec@lists.infradead.org, linux-trace-kernel@vger.kernel.org,
        linux-hardening@vger.kernel.org, apparmor@lists.ubuntu.com,
        linux-security-module@vger.kernel.org, keyrings@vger.kernel.org,
        Song Liu <song@kernel.org>,
        "Steven Rostedt (Google)" <rostedt@goodmis.org>,
        "Martin K. Petersen" <martin.petersen@oracle.com>,
        "Darrick J. Wong" <djwong@kernel.org>,
        Jani Nikula <jani.nikula@intel.com>,
        Corey Minyard <cminyard@mvista.com>
Subject: Re: [PATCH v2] treewide: const qualify ctl_tables where applicable
Message-ID: <Z4+jwDBrZNRgu85S@li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com>
References: <20250110-jag-ctl_table_const-v2-1-0000e1663144@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250110-jag-ctl_table_const-v2-1-0000e1663144@kernel.org>
X-TM-AS-GCONF: 00
X-Proofpoint-ORIG-GUID: mWjZL4Eizm--6YwnTI2RlL8astD0-e-i
X-Proofpoint-GUID: mWjZL4Eizm--6YwnTI2RlL8astD0-e-i
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34
 definitions=2025-01-21_05,2025-01-21_02,2024-11-22_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 phishscore=0
 bulkscore=0 suspectscore=0 adultscore=0 clxscore=1011 priorityscore=1501
 spamscore=0 impostorscore=0 lowpriorityscore=0 mlxscore=0 mlxlogscore=999
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2411120000
 definitions=main-2501210112

On Fri, Jan 10, 2025 at 03:16:08PM +0100, Joel Granados wrote:

Hi Joel,

> Add the const qualifier to all the ctl_tables in the tree except for
> watchdog_hardlockup_sysctl, memory_allocation_profiling_sysctls,
> loadpin_sysctl_table and the ones calling register_net_sysctl (./net,
> drivers/inifiniband dirs). These are special cases as they use a
> registration function with a non-const qualified ctl_table argument or
> modify the arrays before passing them on to the registration function.
> 
> Constifying ctl_table structs will prevent the modification of
> proc_handler function pointers as the arrays would reside in .rodata.
> This is made possible after commit 78eb4ea25cd5 ("sysctl: treewide:
> constify the ctl_table argument of proc_handlers") constified all the
> proc_handlers.

I could identify at least these occurences in s390 code as well:

diff --git a/arch/s390/appldata/appldata_base.c b/arch/s390/appldata/appldata_base.c
index dd7ba7587dd5..9b83c318f919 100644
--- a/arch/s390/appldata/appldata_base.c
+++ b/arch/s390/appldata/appldata_base.c
@@ -204,7 +204,7 @@ appldata_timer_handler(const struct ctl_table *ctl, int write,
 {
 	int timer_active = appldata_timer_active;
 	int rc;
-	struct ctl_table ctl_entry = {
+	const struct ctl_table ctl_entry = {
 		.procname	= ctl->procname,
 		.data		= &timer_active,
 		.maxlen		= sizeof(int),
@@ -237,7 +237,7 @@ appldata_interval_handler(const struct ctl_table *ctl, int write,
 {
 	int interval = appldata_interval;
 	int rc;
-	struct ctl_table ctl_entry = {
+	const struct ctl_table ctl_entry = {
 		.procname	= ctl->procname,
 		.data		= &interval,
 		.maxlen		= sizeof(int),
@@ -269,7 +269,7 @@ appldata_generic_handler(const struct ctl_table *ctl, int write,
 	struct list_head *lh;
 	int rc, found;
 	int active;
-	struct ctl_table ctl_entry = {
+	const struct ctl_table ctl_entry = {
 		.data		= &active,
 		.maxlen		= sizeof(int),
 		.extra1		= SYSCTL_ZERO,
diff --git a/arch/s390/kernel/hiperdispatch.c b/arch/s390/kernel/hiperdispatch.c
index 7857a7e8e56c..7d0ba16085c1 100644
--- a/arch/s390/kernel/hiperdispatch.c
+++ b/arch/s390/kernel/hiperdispatch.c
@@ -273,7 +273,7 @@ static int hiperdispatch_ctl_handler(const struct ctl_table *ctl, int write,
 {
 	int hiperdispatch;
 	int rc;
-	struct ctl_table ctl_entry = {
+	const struct ctl_table ctl_entry = {
 		.procname	= ctl->procname,
 		.data		= &hiperdispatch,
 		.maxlen		= sizeof(int),
diff --git a/arch/s390/kernel/topology.c b/arch/s390/kernel/topology.c
index 6691808bf50a..26e50de83d80 100644
--- a/arch/s390/kernel/topology.c
+++ b/arch/s390/kernel/topology.c
@@ -629,7 +629,7 @@ static int topology_ctl_handler(const struct ctl_table *ctl, int write,
 	int enabled = topology_is_enabled();
 	int new_mode;
 	int rc;
-	struct ctl_table ctl_entry = {
+	const struct ctl_table ctl_entry = {
 		.procname	= ctl->procname,
 		.data		= &enabled,
 		.maxlen		= sizeof(int),
@@ -658,7 +658,7 @@ static int polarization_ctl_handler(const struct ctl_table *ctl, int write,
 {
 	int polarization;
 	int rc;
-	struct ctl_table ctl_entry = {
+	const struct ctl_table ctl_entry = {
 		.procname	= ctl->procname,
 		.data		= &polarization,
 		.maxlen		= sizeof(int),
diff --git a/arch/s390/mm/cmm.c b/arch/s390/mm/cmm.c
index 939e3bec2db7..8e354c90a3dd 100644
--- a/arch/s390/mm/cmm.c
+++ b/arch/s390/mm/cmm.c
@@ -263,7 +263,7 @@ static int cmm_pages_handler(const struct ctl_table *ctl, int write,
 			     void *buffer, size_t *lenp, loff_t *ppos)
 {
 	long nr = cmm_get_pages();
-	struct ctl_table ctl_entry = {
+	const struct ctl_table ctl_entry = {
 		.procname	= ctl->procname,
 		.data		= &nr,
 		.maxlen		= sizeof(long),
@@ -283,7 +283,7 @@ static int cmm_timed_pages_handler(const struct ctl_table *ctl, int write,
 				   loff_t *ppos)
 {
 	long nr = cmm_get_timed_pages();
-	struct ctl_table ctl_entry = {
+	const struct ctl_table ctl_entry = {
 		.procname	= ctl->procname,
 		.data		= &nr,
 		.maxlen		= sizeof(long),


> Best regards,
> -- 
> Joel Granados <joel.granados@kernel.org>

Thanks!


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 14:02:25 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 14:02:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875449.1285890 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taEpa-0003rh-Ca; Tue, 21 Jan 2025 14:02:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875449.1285890; Tue, 21 Jan 2025 14:02:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taEpa-0003ra-9K; Tue, 21 Jan 2025 14:02:14 +0000
Received: by outflank-mailman (input) for mailman id 875449;
 Tue, 21 Jan 2025 13:56: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
 <SRS0=+LsX=UN=kernel.org=frederic@srs-se1.protection.inumbo.net>)
 id 1taEkQ-0002ZZ-I8
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 13:56:54 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 912a7965-d7ff-11ef-a0e4-8be0dac302b0;
 Tue, 21 Jan 2025 14:56:53 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 7F01AA41972;
 Tue, 21 Jan 2025 13:55:03 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 13D92C4CEDF;
 Tue, 21 Jan 2025 13:56:50 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 912a7965-d7ff-11ef-a0e4-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1737467810;
	bh=MqI6lrWOZQoTFNws7n2UwUgsmLRqEZNZodv6GljplcY=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=isvlPBsQ7TrI9disQI4ep5AL0JttTMJYCjeOXU0i2Ch/ZJhKtfxYn7noZla1QkDqv
	 en2cxtzrpb+ySn8gOB8ZoZV2S+K1n5H3W3i1NokW2jFX5MYZAQKEGHyjcd+04RPzL6
	 fTPenbokZbubnqvnOZIUv59tCiByEKKxVUoJRCVR2ClnBGXpdDVbmRMbF5RR0kls7U
	 7c4EikX8Q0rBg27nmXW8SWsbwke1FjZREhy6DgcwG1U+Sf6B+2s64Bk1dTdAxFB7Uo
	 aEgg3mljv5NxhaLk6HLG7ru2QC2RXk1FcHRWMYbZ4w1F80Cti9sUorhTjzrFo4+wEW
	 S4aA+5YxpaHVg==
Date: Tue, 21 Jan 2025 14:56:47 +0100
From: Frederic Weisbecker <frederic@kernel.org>
To: Valentin Schneider <vschneid@redhat.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
	virtualization@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev,
	linux-riscv@lists.infradead.org, linux-perf-users@vger.kernel.org,
	xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
	linux-arch@vger.kernel.org, rcu@vger.kernel.org,
	linux-hardening@vger.kernel.org, linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org, bpf@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com,
	"Paul E . McKenney" <paulmck@kernel.org>,
	Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.amakhalov@broadcom.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andy Lutomirski <luto@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
	Jason Baron <jbaron@akamai.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Clark Williams <williams@redhat.com>,
	Yair Podemsky <ypodemsk@redhat.com>,
	Tomas Glozar <tglozar@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
	Kees Cook <kees@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Shuah Khan <shuah@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Miguel Ojeda <ojeda@kernel.org>, Alice Ryhl <aliceryhl@google.com>,
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
	Samuel Holland <samuel.holland@sifive.com>,
	Rong Xu <xur@google.com>,
	Nicolas Saenz Julienne <nsaenzju@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Yosry Ahmed <yosryahmed@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Jinghao Jia <jinghao7@illinois.edu>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: Re: [PATCH v4 03/30] rcu: Add a small-width RCU watching counter
 debug option
Message-ID: <Z4-nn8snXYyzocQW@localhost.localdomain>
References: <20250114175143.81438-1-vschneid@redhat.com>
 <20250114175143.81438-4-vschneid@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250114175143.81438-4-vschneid@redhat.com>

Le Tue, Jan 14, 2025 at 06:51:16PM +0100, Valentin Schneider a �crit :
> A later commit will reduce the size of the RCU watching counter to free up
> some bits for another purpose. Paul suggested adding a config option to
> test the extreme case where the counter is reduced to its minimum usable
> width for rcutorture to poke at, so do that.
> 
> Make it only configurable under RCU_EXPERT. While at it, add a comment to
> explain the layout of context_tracking->state.
> 
> Link: http://lore.kernel.org/r/4c2cb573-168f-4806-b1d9-164e8276e66a@paulmck-laptop
> Suggested-by: Paul E. McKenney <paulmck@kernel.org>
> Signed-off-by: Valentin Schneider <vschneid@redhat.com>
> Reviewed-by: Paul E. McKenney <paulmck@kernel.org>

Reviewed-by: Frederic Weisbecker <frederic@kernel.org>


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 14:02:25 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 14:02:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875451.1285896 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taEpa-0003v1-LJ; Tue, 21 Jan 2025 14:02:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875451.1285896; Tue, 21 Jan 2025 14:02:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taEpa-0003tf-HK; Tue, 21 Jan 2025 14:02:14 +0000
Received: by outflank-mailman (input) for mailman id 875451;
 Tue, 21 Jan 2025 14:00:28 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=+LsX=UN=kernel.org=frederic@srs-se1.protection.inumbo.net>)
 id 1taEns-0003cS-J2
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 14:00:28 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org
 [2604:1380:4641:c500::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0ff333d8-d800-11ef-99a4-01e77a169b0f;
 Tue, 21 Jan 2025 15:00:26 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 23A275C58A7;
 Tue, 21 Jan 2025 13:59:43 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id C5C8CC4CEE0;
 Tue, 21 Jan 2025 14:00:22 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 0ff333d8-d800-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1737468023;
	bh=Q5S9rJetTl9cgCroBUGkg7SOjKEl71T4cDyTy00Ssfo=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=FXH6cakOFkqIb5zaMucRt18L87yvpwVZGaJxUhREOt4P68rgom62uMZqy68vIiJxY
	 vC1cXMrRMcOwMAfmuxLEZ5bndo3NE4WwazkktDRZnaa3oxsql1H5GUr7t+fwMIx0bz
	 XkAJkUT9nkasLdUoZuBKZrBbotzPsLrjgcHMO3sqMz38POYs+eMlsXPGM73jQ0n8iK
	 MmzoQzjKnN6ACmqf4QPGnpglxf6uAX3/BRM7U3tqtHBoHNE7h6KqKMl22hpV4arvIi
	 4EBHxuw1qzMJUStZM7S/rcVySHrJR+84rbhK+Ss3scFXmd7IzHbUAqqT0NZChxotoD
	 A/lQ8LRjiOvEw==
Date: Tue, 21 Jan 2025 15:00:20 +0100
From: Frederic Weisbecker <frederic@kernel.org>
To: Valentin Schneider <vschneid@redhat.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
	virtualization@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev,
	linux-riscv@lists.infradead.org, linux-perf-users@vger.kernel.org,
	xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
	linux-arch@vger.kernel.org, rcu@vger.kernel.org,
	linux-hardening@vger.kernel.org, linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org, bpf@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com,
	"Paul E . McKenney" <paulmck@kernel.org>,
	Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.amakhalov@broadcom.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andy Lutomirski <luto@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
	Jason Baron <jbaron@akamai.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Clark Williams <williams@redhat.com>,
	Yair Podemsky <ypodemsk@redhat.com>,
	Tomas Glozar <tglozar@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
	Kees Cook <kees@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Shuah Khan <shuah@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Miguel Ojeda <ojeda@kernel.org>, Alice Ryhl <aliceryhl@google.com>,
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
	Samuel Holland <samuel.holland@sifive.com>,
	Rong Xu <xur@google.com>,
	Nicolas Saenz Julienne <nsaenzju@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Yosry Ahmed <yosryahmed@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Jinghao Jia <jinghao7@illinois.edu>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: Re: [PATCH v4 04/30] rcutorture: Make TREE04 use
 CONFIG_RCU_DYNTICKS_TORTURE
Message-ID: <Z4-odFAImP-_uLV7@localhost.localdomain>
References: <20250114175143.81438-1-vschneid@redhat.com>
 <20250114175143.81438-5-vschneid@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250114175143.81438-5-vschneid@redhat.com>

Le Tue, Jan 14, 2025 at 06:51:17PM +0100, Valentin Schneider a �crit :
> We now have an RCU_EXPERT config for testing small-sized RCU dynticks
> counter:  CONFIG_RCU_DYNTICKS_TORTURE.
> 
> Modify scenario TREE04 to exercise to use this config in order to test a
> ridiculously small counter (2 bits).
> 
> Link: http://lore.kernel.org/r/4c2cb573-168f-4806-b1d9-164e8276e66a@paulmck-laptop
> Suggested-by: Paul E. McKenney <paulmck@kernel.org>
> Signed-off-by: Valentin Schneider <vschneid@redhat.com>
> Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
> ---
>  tools/testing/selftests/rcutorture/configs/rcu/TREE04 | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tools/testing/selftests/rcutorture/configs/rcu/TREE04 b/tools/testing/selftests/rcutorture/configs/rcu/TREE04
> index dc4985064b3ad..67caf4276bb01 100644
> --- a/tools/testing/selftests/rcutorture/configs/rcu/TREE04
> +++ b/tools/testing/selftests/rcutorture/configs/rcu/TREE04
> @@ -16,3 +16,4 @@ CONFIG_DEBUG_OBJECTS_RCU_HEAD=n
>  CONFIG_RCU_EXPERT=y
>  CONFIG_RCU_EQS_DEBUG=y
>  CONFIG_RCU_LAZY=y
> +CONFIG_RCU_DYNTICKS_TORTURE=y

Reviewed-by: Frederic Weisbecker <frederic@kernel.org>


> -- 
> 2.43.0
> 
> 


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 14:25:23 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 14:25:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875470.1285911 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taFBt-00083E-IU; Tue, 21 Jan 2025 14:25:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875470.1285911; Tue, 21 Jan 2025 14:25:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taFBt-000837-Fd; Tue, 21 Jan 2025 14:25:17 +0000
Received: by outflank-mailman (input) for mailman id 875470;
 Tue, 21 Jan 2025 14:25:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=qQWO=UN=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1taFBs-000831-9q
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 14:25:16 +0000
Received: from mail-ed1-x543.google.com (mail-ed1-x543.google.com
 [2a00:1450:4864:20::543])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 86a1dc3e-d803-11ef-a0e4-8be0dac302b0;
 Tue, 21 Jan 2025 15:25:13 +0100 (CET)
Received: by mail-ed1-x543.google.com with SMTP id
 4fb4d7f45d1cf-5db689a87cbso11267258a12.3
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 06:25:13 -0800 (PST)
Received: from andrewcoop.eng.citrite.net (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5db73eb5b05sm7059934a12.63.2025.01.21.06.25.11
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 21 Jan 2025 06:25:11 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 86a1dc3e-d803-11ef-a0e4-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737469512; x=1738074312; 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=IvOrZpMGGQA+YD5BVos8SdHvfHAL1b+MsHG+uttROsU=;
        b=wY4SrTEqBYhQcY2g6gTCXrp68DwvM6faS+AEzIvajuZDZdh7qHAMoDmljKThDCq7fB
         CnTPEmt2Nf43CNCe+SxKeM620EDpzMuyOaOGji2ssby43KEMDZ7ynuNX1XJNH3XWnJsH
         +kqxqIEQK7QSdXYzXZYyWhsS8VB9zMXsdhOEM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737469512; x=1738074312;
        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=IvOrZpMGGQA+YD5BVos8SdHvfHAL1b+MsHG+uttROsU=;
        b=mhCLbHMW1/VLFn3eI0R7cJRlUoc4LD89yj+y9z1wWZD0jIZ55c8IIzTVrrhZEcHysW
         Xw0I7+6PvGdeL3nU/vmhAsAQB3C0J+HPifDqDPi1oJ2TvMQAGZaqdz86QUWTbXbop0TD
         w6jsHdQ79YLDXC9WNVIZ6vtq5TzuNcRMQeZHnzrcUNoVwixOoA0Lqkcj/5gajBoXspy+
         udAN6g6BXMw3STQ/daaF4KkrpOcT7b4sa803jZR+5j4Ds4LHwwgJNietoDXeB13kOgau
         pMzTLKRMF1TbnWp8GjnayEDwuDKzAygoeEcYJLWdp63b8iSOTth/GEM2IzRTf6ntDsmd
         /5+Q==
X-Gm-Message-State: AOJu0YxAB6s7cYHFgfTLE0SuYcDr/AuKn/KonfXzZqcv/y3fUqU8Wube
	EnJTw0Hu5HRi5hUQBL4HTH580B1UdzWT/pADe11SNxKV3HByfbDRrN4HnQFJgMarj3OWf7ikaG0
	pZRv64w==
X-Gm-Gg: ASbGncsleqhJgf3h0RK43LKyp15TFQR6red06lvIWSNfbZvSU36SbjtepdQpPKaUpdf
	aIkW8MynE8yHPWSQp6+/sUXq3oH8zKfpTJv+rttfP68ojXlmlufW901I6MG8a7LdvzA6c7qzUsq
	5924WsDXPOz7Y+8bCOrzj4lzI6j/UwkxxX5sZH9tXXeeUep1GDMSrC/1ztm5qlpal7R1rmRvJS7
	OX13nJcPDzbOc8GpjB6pdfvhrhQJvQjQ5fDqWTKhDag8CKK65YQ7R5nS3kZK3Du7PtWNXo4XNSE
	ULLeJe4L/nkdwgqNFW/+ZMVVKKVz7UuSzH4Q2eOUERZMPa36dQ==
X-Google-Smtp-Source: AGHT+IEMy3Ai4UyNazji72hNigCLpbTF1IMBzCiawudGVO2lvl8G22VxYDdUMslc2oapKeT+eO2YrA==
X-Received: by 2002:a05:6402:3483:b0:5d0:d30b:d53e with SMTP id 4fb4d7f45d1cf-5db7d318decmr15709509a12.19.1737469511924;
        Tue, 21 Jan 2025 06:25:11 -0800 (PST)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jonathan Katz <jonathan.katz@aptar.com>,
	Jan Beulich <JBeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>
Subject: [PATCH for-4.20] x86/intel: Fix PERF_GLOBAL fixup when virtualised
Date: Tue, 21 Jan 2025 14:25:10 +0000
Message-Id: <20250121142510.358996-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Logic using performance counters needs to look at
MSR_MISC_ENABLE.PERF_AVAILABLE before touching any other resources.

When virtualised under ESX, Xen dies with a #GP fault trying to read
MSR_CORE_PERF_GLOBAL_CTRL.

Factor this logic out into a separate function (it's already too squashed to
the RHS), and insert a check of MSR_MISC_ENABLE.PERF_AVAILABLE.

This also limits setting X86_FEATURE_ARCH_PERFMON, although oprofile (the only
consumer of this flag) cross-checks too.

Reported-by: Jonathan Katz <jonathan.katz@aptar.com>
Link: https://xcp-ng.org/forum/topic/10286/nesting-xcp-ng-on-esx-8
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Roger Pau Monné <roger.pau@citrix.com>
CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>

Untested, but this is the same pattern used by oprofile and watchdog setup.

I've intentionally stopped using Intel style.  This file is already mixed (as
visible even in context), and it doesn't remotely resemble it's Linux origin
any more.

For 4.20.  This regressions has already been backported.
---
 xen/arch/x86/cpu/intel.c | 64 +++++++++++++++++++++++-----------------
 1 file changed, 37 insertions(+), 27 deletions(-)

diff --git a/xen/arch/x86/cpu/intel.c b/xen/arch/x86/cpu/intel.c
index 6a7347968ba2..586ae84d806d 100644
--- a/xen/arch/x86/cpu/intel.c
+++ b/xen/arch/x86/cpu/intel.c
@@ -535,39 +535,49 @@ static void intel_log_freq(const struct cpuinfo_x86 *c)
     printk("%u MHz\n", (factor * max_ratio + 50) / 100);
 }
 
+static void init_intel_perf(struct cpuinfo_x86 *c)
+{
+    uint64_t val;
+    unsigned int eax, ver, nr_cnt;
+
+    if ( c->cpuid_level <= 9 ||
+         rdmsr_safe(MSR_IA32_MISC_ENABLE, val) ||
+         !(val & MSR_IA32_MISC_ENABLE_PERF_AVAIL) )
+        return;
+
+    eax = cpuid_eax(10);
+    ver = eax & 0xff;
+    nr_cnt = (eax >> 8) & 0xff;
+
+    if ( ver && nr_cnt > 1 && nr_cnt <= 32 )
+    {
+        unsigned int cnt_mask = (1UL << nr_cnt) - 1;
+
+        /*
+         * On (some?) Sapphire/Emerald Rapids platforms each package-BSP
+         * starts with all the enable bits for the general-purpose PMCs
+         * cleared.  Adjust so counters can be enabled from EVNTSEL.
+         */
+        rdmsrl(MSR_CORE_PERF_GLOBAL_CTRL, val);
+
+        if ( (val & cnt_mask) != cnt_mask )
+        {
+            printk("FIRMWARE BUG: CPU%u invalid PERF_GLOBAL_CTRL: %#"PRIx64" adjusting to %#"PRIx64"\n",
+                   smp_processor_id(), val, val | cnt_mask);
+            wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, val | cnt_mask);
+        }
+    }
+
+    __set_bit(X86_FEATURE_ARCH_PERFMON, c->x86_capability);
+}
+
 static void cf_check init_intel(struct cpuinfo_x86 *c)
 {
 	/* Detect the extended topology information if available */
 	detect_extended_topology(c);
 
 	init_intel_cacheinfo(c);
-	if (c->cpuid_level > 9) {
-		unsigned eax = cpuid_eax(10);
-		unsigned int cnt = (eax >> 8) & 0xff;
-
-		/* Check for version and the number of counters */
-		if ((eax & 0xff) && (cnt > 1) && (cnt <= 32)) {
-			uint64_t global_ctrl;
-			unsigned int cnt_mask = (1UL << cnt) - 1;
-
-			/*
-			 * On (some?) Sapphire/Emerald Rapids platforms each
-			 * package-BSP starts with all the enable bits for the
-			 * general-purpose PMCs cleared.  Adjust so counters
-			 * can be enabled from EVNTSEL.
-			 */
-			rdmsrl(MSR_CORE_PERF_GLOBAL_CTRL, global_ctrl);
-			if ((global_ctrl & cnt_mask) != cnt_mask) {
-				printk("CPU%u: invalid PERF_GLOBAL_CTRL: %#"
-				       PRIx64 " adjusting to %#" PRIx64 "\n",
-				       smp_processor_id(), global_ctrl,
-				       global_ctrl | cnt_mask);
-				wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL,
-				       global_ctrl | cnt_mask);
-			}
-			__set_bit(X86_FEATURE_ARCH_PERFMON, c->x86_capability);
-		}
-	}
+	init_intel_perf(c);
 
 	if ( !cpu_has(c, X86_FEATURE_XTOPOLOGY) )
 	{

base-commit: c3f5d1bb40b57d467cb4051eafa86f5933ec9003
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Tue Jan 21 15:03:54 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 15:03:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875481.1285925 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taFn3-0006BW-C7; Tue, 21 Jan 2025 15:03:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875481.1285925; Tue, 21 Jan 2025 15:03:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taFn3-0006BP-8R; Tue, 21 Jan 2025 15:03:41 +0000
Received: by outflank-mailman (input) for mailman id 875481;
 Tue, 21 Jan 2025 15:03:40 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Gode=UN=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1taFn2-00069s-0z
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 15:03:40 +0000
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com
 [2a00:1450:4864:20::434])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e015dc32-d808-11ef-99a4-01e77a169b0f;
 Tue, 21 Jan 2025 16:03:30 +0100 (CET)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-385dece873cso3104068f8f.0
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 07:03:30 -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
 5b1f17b1804b1-437c7499884sm246831485e9.5.2025.01.21.07.03.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 21 Jan 2025 07:03:29 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e015dc32-d808-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737471810; x=1738076610; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=C0DDs/jRuXK4di6ZzkqrmzJpEB0SiMe3X2u+cZw3fJI=;
        b=Q5/crleT3MxVN/18ivf+idJMRUj1QIAvJcJOW8LseLZCIVEiXCdd7RmnzIzFSgghuX
         psrY4URVTcGHLqgjhhs4gqFKh0q9sMOAWPVslmpzN3AJ45NGAOstsGcc7BBrpETyF84n
         Ty8U23An4zLCE6OQgWCZW4qJfEi29yc86yJPmDd69xTR1JhjpR/KF1PCrQBCYI46jJdZ
         Kl4UalYDRZI9JtBCuuICpvEBy/8FQnsMGycs8elt4AzxEC83TkCUOXILG51rOo+jkZ4S
         9ljtpAJohH/GON93Pli0Lk6JhGN4DOmddxhyCuuiqd5YsOB8qtuNy0kg/YgC3sc08BpH
         KjCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737471810; x=1738076610;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=C0DDs/jRuXK4di6ZzkqrmzJpEB0SiMe3X2u+cZw3fJI=;
        b=ILSL0913lmpuNx239O1ogSdiNUamREyjSgXkSr97SpZeMy1Z9VeXlx1Hg4xgJ1vXbb
         8p6vJaID7+ZLv346MIWNz9T3WmR+Yv2iXQLwl4Ay+6Ni/QvSPwsV70giVgV+8fQq32Gt
         1PsbHFpLN7JvBS2Xbwrlk/43jgJt8+NcbLz7jLzm1ik4E6kS3NbuIL02Yq+HroAiny5D
         3hlmDvR1VuNCZbjE6TyZ8wE7w91ABVtU8bq3XcnbzHB/TI0Vt1lXeiu4ucfbR6NUyqKw
         BUXIsVGzfjSyP8/vBQkG1Epq9W1PhboRkVJs7eXDR5UGkWk20/BVRzhrE3WdjpJZVLDY
         LBvw==
X-Forwarded-Encrypted: i=1; AJvYcCW/8oIH9oTKCOBDaVqEV8iUj7BOQk3Bi64VyTfPD38mqOlSzSN6STGP8+iA8Dr8/a4MdFrnT1yHf6o=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyr+BbIBytI7ciWmEfBgDSQh7x30GydaYvs1HB+3zm5WMXvT5DW
	QSXKSXd1SsPOO1omxlO3O0chbXBCkViNOOavEvWngJllgfpMmqzUiA+RA1CUfg==
X-Gm-Gg: ASbGncu5Lb240LhRUxpRPKi2T1okhsoPkor5gbZZH4yCMXJh5Xa1GnvK8hXzczF/R4I
	ij1L44EHEuu+AgCIi+uq/n8hnz2yZK5ZM5kVYgyyOszFOCbj0wVsB/bRr4TznjOWA2wrwBqhFBD
	qywrGaMg17qkd5+h+vnv1SApM2rcQyQrTnx23VEo4kCQN9OsahJ0CY0uOQGLvMoV3BY8Hy65ovK
	x9aOJxAqg27i9gIcVo7YAFgEKGldrH/jo9OBTnOZbAxx/GocnVdIgS1NRA0PqiuNJqTTWKbG6kd
	zTrNqqEjmRUUZ8VqdItE/hdIOGjipy628VxNNGo062Wm9YbImCwC1PA=
X-Google-Smtp-Source: AGHT+IEjfneuXBKEtBPbxN196hAx21Z+8eC27m/+wW8+5o+QaW7o132OtJrTrAY8z45Smo+5oCUTLQ==
X-Received: by 2002:a05:6000:1faa:b0:385:e013:39ec with SMTP id ffacd0b85a97d-38bf5656b93mr16106365f8f.8.1737471809448;
        Tue, 21 Jan 2025 07:03:29 -0800 (PST)
Message-ID: <2b36d54d-88fb-4ad4-b0e4-cfa837872b14@suse.com>
Date: Tue, 21 Jan 2025 16:03:28 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20] x86/intel: Fix PERF_GLOBAL fixup when
 virtualised
To: Andrew Cooper <andrew.cooper3@citrix.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
Cc: Jonathan Katz <jonathan.katz@aptar.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>
References: <20250121142510.358996-1-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250121142510.358996-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 21.01.2025 15:25, Andrew Cooper wrote:
> Logic using performance counters needs to look at
> MSR_MISC_ENABLE.PERF_AVAILABLE before touching any other resources.
> 
> When virtualised under ESX, Xen dies with a #GP fault trying to read
> MSR_CORE_PERF_GLOBAL_CTRL.
> 
> Factor this logic out into a separate function (it's already too squashed to
> the RHS), and insert a check of MSR_MISC_ENABLE.PERF_AVAILABLE.
> 
> This also limits setting X86_FEATURE_ARCH_PERFMON, although oprofile (the only
> consumer of this flag) cross-checks too.
> 
> Reported-by: Jonathan Katz <jonathan.katz@aptar.com>
> Link: https://xcp-ng.org/forum/topic/10286/nesting-xcp-ng-on-esx-8
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> CC: Jan Beulich <JBeulich@suse.com>
> CC: Roger Pau Monné <roger.pau@citrix.com>
> CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> 
> Untested, but this is the same pattern used by oprofile and watchdog setup.

Wow, in the oprofile case with pretty bad open-coding.

> I've intentionally stopped using Intel style.  This file is already mixed (as
> visible even in context), and it doesn't remotely resemble it's Linux origin
> any more.

I guess you mean s/Intel/Linux/ here? (Yes, I'm entirely fine with using Xen
style there.)

> --- a/xen/arch/x86/cpu/intel.c
> +++ b/xen/arch/x86/cpu/intel.c
> @@ -535,39 +535,49 @@ static void intel_log_freq(const struct cpuinfo_x86 *c)
>      printk("%u MHz\n", (factor * max_ratio + 50) / 100);
>  }
>  
> +static void init_intel_perf(struct cpuinfo_x86 *c)
> +{
> +    uint64_t val;
> +    unsigned int eax, ver, nr_cnt;
> +
> +    if ( c->cpuid_level <= 9 ||
> +         rdmsr_safe(MSR_IA32_MISC_ENABLE, val) ||

In e.g. intel_unlock_cpuid_leaves() and early_init_intel() and in particular
also in boot/head.S we access this MSR without recovery attached. Is there a
reason rdmsr_safe() needs using here?

> +         !(val & MSR_IA32_MISC_ENABLE_PERF_AVAIL) )
> +        return;
> +
> +    eax = cpuid_eax(10);
> +    ver = eax & 0xff;
> +    nr_cnt = (eax >> 8) & 0xff;
> +
> +    if ( ver && nr_cnt > 1 && nr_cnt <= 32 )
> +    {
> +        unsigned int cnt_mask = (1UL << nr_cnt) - 1;
> +
> +        /*
> +         * On (some?) Sapphire/Emerald Rapids platforms each package-BSP
> +         * starts with all the enable bits for the general-purpose PMCs
> +         * cleared.  Adjust so counters can be enabled from EVNTSEL.
> +         */
> +        rdmsrl(MSR_CORE_PERF_GLOBAL_CTRL, val);
> +
> +        if ( (val & cnt_mask) != cnt_mask )
> +        {
> +            printk("FIRMWARE BUG: CPU%u invalid PERF_GLOBAL_CTRL: %#"PRIx64" adjusting to %#"PRIx64"\n",
> +                   smp_processor_id(), val, val | cnt_mask);
> +            wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, val | cnt_mask);
> +        }
> +    }
> +
> +    __set_bit(X86_FEATURE_ARCH_PERFMON, c->x86_capability);

This moved, without the description suggesting the move is intentional.
It did live at the end of the earlier scope before, ...

> +}
> +
>  static void cf_check init_intel(struct cpuinfo_x86 *c)
>  {
>  	/* Detect the extended topology information if available */
>  	detect_extended_topology(c);
>  
>  	init_intel_cacheinfo(c);
> -	if (c->cpuid_level > 9) {
> -		unsigned eax = cpuid_eax(10);
> -		unsigned int cnt = (eax >> 8) & 0xff;
> -
> -		/* Check for version and the number of counters */
> -		if ((eax & 0xff) && (cnt > 1) && (cnt <= 32)) {
> -			uint64_t global_ctrl;
> -			unsigned int cnt_mask = (1UL << cnt) - 1;
> -
> -			/*
> -			 * On (some?) Sapphire/Emerald Rapids platforms each
> -			 * package-BSP starts with all the enable bits for the
> -			 * general-purpose PMCs cleared.  Adjust so counters
> -			 * can be enabled from EVNTSEL.
> -			 */
> -			rdmsrl(MSR_CORE_PERF_GLOBAL_CTRL, global_ctrl);
> -			if ((global_ctrl & cnt_mask) != cnt_mask) {
> -				printk("CPU%u: invalid PERF_GLOBAL_CTRL: %#"
> -				       PRIx64 " adjusting to %#" PRIx64 "\n",
> -				       smp_processor_id(), global_ctrl,
> -				       global_ctrl | cnt_mask);
> -				wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL,
> -				       global_ctrl | cnt_mask);
> -			}
> -			__set_bit(X86_FEATURE_ARCH_PERFMON, c->x86_capability);
> -		}
> -	}

... as can be seen here.

Jan

> +	init_intel_perf(c);
>  
>  	if ( !cpu_has(c, X86_FEATURE_XTOPOLOGY) )
>  	{
> 
> base-commit: c3f5d1bb40b57d467cb4051eafa86f5933ec9003



From xen-devel-bounces@lists.xenproject.org Tue Jan 21 15:23:15 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 15:23:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875491.1285934 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taG5s-00013i-T5; Tue, 21 Jan 2025 15:23:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875491.1285934; Tue, 21 Jan 2025 15:23:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taG5s-00013b-PT; Tue, 21 Jan 2025 15:23:08 +0000
Received: by outflank-mailman (input) for mailman id 875491;
 Tue, 21 Jan 2025 15:23:08 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=qQWO=UN=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1taG5s-00013V-1O
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 15:23:08 +0000
Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com
 [2a00:1450:4864:20::443])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9ca21e3f-d80b-11ef-99a4-01e77a169b0f;
 Tue, 21 Jan 2025 16:23:05 +0100 (CET)
Received: by mail-wr1-x443.google.com with SMTP id
 ffacd0b85a97d-385deda28b3so3659417f8f.0
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 07:23:05 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38bf327e024sm13375672f8f.88.2025.01.21.07.23.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 21 Jan 2025 07:23:03 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9ca21e3f-d80b-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737472985; x=1738077785; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=oEIlm5ePJ0nksZRQlQPghhrfweIrmTE/Nq0MrDDvxd8=;
        b=s+mgwQfc+oKm5KZM7TH8YLBSOmT+MpPS6eH+raLJETGpAhD69WdzWkB8C3Qgt7/8Sv
         uE3FBv+kXxWfFFN2H6uxfmzBlo9Y7cfEAE7LOLueKxagWMyPHWKdErQ5YWLfRx53Ehcl
         C22oKncN6Ina1i3YIE1hFIrP9pe4m/NgF9cfc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737472985; x=1738077785;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=oEIlm5ePJ0nksZRQlQPghhrfweIrmTE/Nq0MrDDvxd8=;
        b=ZgySn4crtxY3/IRUz4xx6h5/YnpHsdGyd0HaLY5b6CU9+GBz0YHaknSHNkN56+YZlO
         9ZepssjdWEnvOQPksu8Ze6euiUTo7prw40aR+xJ6a7ysI+5bu6MTiHjEDbAq9QTirXvD
         00iK/YPQDD4aB4JLBEgIZdJNg+hcrwWqZkJv416z1xL/4lC2ptF9gHUdvkZvnZY8jw0V
         Dg1RGs4QoBbrIZTctJ/A5ez3SGP+eyDmukTrmT56DenvjZBmo+8JEOkt7FFnKgLf9InM
         tnbr4A17J/RIX9UtCJqcaNBhBWQUuWUuC3DoxUIMZV5pN2oxTOtSXjhTXJtMZY2DrbV7
         8Z8w==
X-Forwarded-Encrypted: i=1; AJvYcCXSps/Ica1k/YkZbLzyi9E8nlC1Vb4qxVKRc0zZ1WQrXkqY7sbz3ZvJNVphqAUBpHG/dFHnO8O9YtQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx5VUhPKgHPlVowxUaaGGrAx8rVSNgTPZcc9COY0MVo7GWwfytG
	JhxGdh6DbauxFmr4eiAY6lvTdigtOKodptyZv/qP1XDItAiFNhEUB1orW/Nx3Jo=
X-Gm-Gg: ASbGnct8PQ6Q/iVvz/6HKuUGhY4JZDp8Rdu0KcY4mz264Q1VN+dyvssX8I97+RvjiFz
	iL938GlTGgJgoh/TosjB0Wrv9bSiZyga6NzbpITEMydCkVFIt2Q/369XiAsOviglTqeu0yLim3q
	nM1boCyMq5nEFhEwpiuZJPfVwXeRVgRcr5kjbGcVRqJMfvM1sRku9JbBdzhOD9F91ovytLtZ5Fy
	kTSRIGNpvcFmjz/EOn62ac4qcDQSxPv6JyMVSPhtIfvFgDdTV9gG9i5ZSPuJMk/U5FeMfiYENAa
	8KOxSBiwVtW8Zcy9jwPx0F9lbIsdtAu1aA==
X-Google-Smtp-Source: AGHT+IGe49Z3ty2pUyKl+Rf7PRVyYl0ukJY5JlQ6y74BWTG1cnQWVUmQ/sD0ZbIAbDb2Hj9bLfjtew==
X-Received: by 2002:adf:ef04:0:b0:385:f23a:2fe1 with SMTP id ffacd0b85a97d-38bf566f7c9mr12437027f8f.26.1737472983519;
        Tue, 21 Jan 2025 07:23:03 -0800 (PST)
Message-ID: <ae54889d-ae82-4df3-a35f-ea09f3972eec@citrix.com>
Date: Tue, 21 Jan 2025 15:23:02 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20] x86/intel: Fix PERF_GLOBAL fixup when
 virtualised
To: Jan Beulich <jbeulich@suse.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
Cc: Jonathan Katz <jonathan.katz@aptar.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>
References: <20250121142510.358996-1-andrew.cooper3@citrix.com>
 <2b36d54d-88fb-4ad4-b0e4-cfa837872b14@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <2b36d54d-88fb-4ad4-b0e4-cfa837872b14@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 21/01/2025 3:03 pm, Jan Beulich wrote:
> On 21.01.2025 15:25, Andrew Cooper wrote:
>> Logic using performance counters needs to look at
>> MSR_MISC_ENABLE.PERF_AVAILABLE before touching any other resources.
>>
>> When virtualised under ESX, Xen dies with a #GP fault trying to read
>> MSR_CORE_PERF_GLOBAL_CTRL.
>>
>> Factor this logic out into a separate function (it's already too squashed to
>> the RHS), and insert a check of MSR_MISC_ENABLE.PERF_AVAILABLE.
>>
>> This also limits setting X86_FEATURE_ARCH_PERFMON, although oprofile (the only
>> consumer of this flag) cross-checks too.

Fixes: 6bdb965178bb ("x86/intel: ensure Global Performance Counter
Control is setup correctly")

(fixed up locally).

>> Reported-by: Jonathan Katz <jonathan.katz@aptar.com>
>> Link: https://xcp-ng.org/forum/topic/10286/nesting-xcp-ng-on-esx-8
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> ---
>> CC: Jan Beulich <JBeulich@suse.com>
>> CC: Roger Pau Monné <roger.pau@citrix.com>
>> CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
>>
>> Untested, but this is the same pattern used by oprofile and watchdog setup.
> Wow, in the oprofile case with pretty bad open-coding.
>
>> I've intentionally stopped using Intel style.  This file is already mixed (as
>> visible even in context), and it doesn't remotely resemble it's Linux origin
>> any more.
> I guess you mean s/Intel/Linux/ here? (Yes, I'm entirely fine with using Xen
> style there.)

Oops yes.

>
>> --- a/xen/arch/x86/cpu/intel.c
>> +++ b/xen/arch/x86/cpu/intel.c
>> @@ -535,39 +535,49 @@ static void intel_log_freq(const struct cpuinfo_x86 *c)
>>      printk("%u MHz\n", (factor * max_ratio + 50) / 100);
>>  }
>>  
>> +static void init_intel_perf(struct cpuinfo_x86 *c)
>> +{
>> +    uint64_t val;
>> +    unsigned int eax, ver, nr_cnt;
>> +
>> +    if ( c->cpuid_level <= 9 ||
>> +         rdmsr_safe(MSR_IA32_MISC_ENABLE, val) ||
> In e.g. intel_unlock_cpuid_leaves() and early_init_intel() and in particular
> also in boot/head.S we access this MSR without recovery attached. Is there a
> reason rdmsr_safe() needs using here?

Abundance of caution.  cpufreq/hwp.c uses a safe accessor.

Given the regular NMI path works, I doubt we need the _safe() here.

As future work, it's accessed loads of times, so I'm highly tempted to
have the BSP sanitise it once, and have the APs copy the "global" value.

>
>> +         !(val & MSR_IA32_MISC_ENABLE_PERF_AVAIL) )
>> +        return;
>> +
>> +    eax = cpuid_eax(10);
>> +    ver = eax & 0xff;
>> +    nr_cnt = (eax >> 8) & 0xff;
>> +
>> +    if ( ver && nr_cnt > 1 && nr_cnt <= 32 )
>> +    {
>> +        unsigned int cnt_mask = (1UL << nr_cnt) - 1;
>> +
>> +        /*
>> +         * On (some?) Sapphire/Emerald Rapids platforms each package-BSP
>> +         * starts with all the enable bits for the general-purpose PMCs
>> +         * cleared.  Adjust so counters can be enabled from EVNTSEL.
>> +         */
>> +        rdmsrl(MSR_CORE_PERF_GLOBAL_CTRL, val);
>> +
>> +        if ( (val & cnt_mask) != cnt_mask )
>> +        {
>> +            printk("FIRMWARE BUG: CPU%u invalid PERF_GLOBAL_CTRL: %#"PRIx64" adjusting to %#"PRIx64"\n",
>> +                   smp_processor_id(), val, val | cnt_mask);
>> +            wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, val | cnt_mask);
>> +        }
>> +    }
>> +
>> +    __set_bit(X86_FEATURE_ARCH_PERFMON, c->x86_capability);
> This moved, without the description suggesting the move is intentional.
> It did live at the end of the earlier scope before, ...

Final paragraph of the commit message?

If PERF_AVAIL is clear, we don't have ARCH_PERFMON, whatever the CPUID
leaves say.

OTOH, this bit really doesn't serve much value.  Given oprofile
cross-checks everything anyway, I think it can be dropped.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 15:58:25 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 15:58:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875504.1285945 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taGdu-0005h6-Gk; Tue, 21 Jan 2025 15:58:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875504.1285945; Tue, 21 Jan 2025 15:58:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taGdu-0005gz-Dr; Tue, 21 Jan 2025 15:58:18 +0000
Received: by outflank-mailman (input) for mailman id 875504;
 Tue, 21 Jan 2025 15:58: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 <SRS0=Gode=UN=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1taGdt-0005gt-Em
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 15:58:17 +0000
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com
 [2a00:1450:4864:20::336])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 86106a59-d810-11ef-99a4-01e77a169b0f;
 Tue, 21 Jan 2025 16:58:15 +0100 (CET)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-4361b6f9faeso37456685e9.1
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 07:58:15 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38bf32151f1sm14006802f8f.14.2025.01.21.07.58.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 21 Jan 2025 07:58:14 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 86106a59-d810-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737475095; x=1738079895; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ZgxlN/7GROnSqyYD26A1DB4EiWNixpT7taZWgqGGyWA=;
        b=COcJ62TMc9K1V0nruiihaQzBXCFjanYqz00LMpd8E7kWg6yAiXw4je37QD1F6TcVcM
         o0wmO8MpJXZK/0oh0TqPrICywzR1KFhxJTmTtgUbGx6itZi6UJHOtR3pJIEOaCWrGg2a
         0+Lxo0hTMYWLbNfUKwiQNiFiB/UvNxEW3OV6i607ceYE4BDn9cdM3wjeEttZ6j0Y39bC
         9Rt5TA4aJbhp32Dlclfhs99Rx0tMSY0faXMjVr4ryj13cPFYKKaOsszceiJMpLRLNX2a
         pCJKmpPo6y9PnHJ0akvFjYz2KY+hgnDl/QbagKJ7ErjFATDiz4eTu39sql7pgnGkkFYM
         TZ3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737475095; x=1738079895;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ZgxlN/7GROnSqyYD26A1DB4EiWNixpT7taZWgqGGyWA=;
        b=UkAfmBrNOIQPClGdTePc659MaS/AcgpkUdBFLP1IZw+YianbWMRD4EkNxM/Iqcctpx
         iwhv8XgJLeLwolGsIl0thVKV1GuDrj6WTJp6T2ENJxzoW34ms3hte1BFCqD4ZFTtDfLl
         Y51bLE0115TtGBA4OqVJBvoGAExvk6eDa89fpMc2zbL6Bz3DwucoKxolZAcPAY/25i4D
         xD0gMbfAUXFCcyUMn931BxTpw97x8Z0pICLsvaThgK9wWqJRInSp0WQWPOw3t8AOstMr
         StPhc8KcvFkXHyTHS5AErn4tBtPeFZSvLwOKNigFgG0fIQAPjjRaYm1ldvVj+9i9AO16
         ziHw==
X-Forwarded-Encrypted: i=1; AJvYcCUH5mT83OIKDSiGGgyNql3S1WHJZhagmdr71RxlT5MXWHftSP9am4kQkdnU4uItZWjY1H+Pjvtk+Ow=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzs2NFWZRF3r134gua2ZCzAKBgITN6oNRNaxxFKnl6jdLBin9Dc
	Fy6G9aMianU3qQ/YO90sZMp6ryFwPjd7bv0NQ+/pl3Zl1efHB7joAZMCsm3X+w==
X-Gm-Gg: ASbGncv3aY74KEYiVCQea2OWzaWkWo3aYyc7gsiXFmqoP0wLE33+SzqetYrSRq2c/ce
	KJAySlKhveImG1g+DGZHWdR4GV6Eok7c6oz3VXNNDlffyZ1qa0OpJu4+UsC6o9l26VHqk/5uiCo
	TUvsKL8nYlBIuXeMs1ZdrkKecKI5o7VFNhzI0NQb4zs8m53Vz3zUAx5EbjGmfbxxaWHGa7w0cT+
	gq4pFWkPZTGCInrOSjAh6XaV3JPRmgXs+6g4ApLv5aA5ULAg6ktTYyrPbVFj0FIa6pcEcMOHKiW
	V3JgUNyrhpsAuJ4NcaKQcdq181+retwloAQPwd+JdJrq0kIy41+vkfw=
X-Google-Smtp-Source: AGHT+IFZApX3OS7dzZBiap5RiYUt9pHkpeyxfMPTkZ0Oq1Kuz3UzRQUgSVrTKwY9yQg5MZ/t5Mlccg==
X-Received: by 2002:a05:600c:cc8:b0:434:fe3c:c662 with SMTP id 5b1f17b1804b1-438918f6027mr138981105e9.12.1737475094652;
        Tue, 21 Jan 2025 07:58:14 -0800 (PST)
Message-ID: <445f93d3-626e-40ca-9acd-db3af83be1e5@suse.com>
Date: Tue, 21 Jan 2025 16:58:13 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20] x86/intel: Fix PERF_GLOBAL fixup when
 virtualised
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Jonathan Katz <jonathan.katz@aptar.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20250121142510.358996-1-andrew.cooper3@citrix.com>
 <2b36d54d-88fb-4ad4-b0e4-cfa837872b14@suse.com>
 <ae54889d-ae82-4df3-a35f-ea09f3972eec@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <ae54889d-ae82-4df3-a35f-ea09f3972eec@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 21.01.2025 16:23, Andrew Cooper wrote:
> On 21/01/2025 3:03 pm, Jan Beulich wrote:
>> On 21.01.2025 15:25, Andrew Cooper wrote:
>>> Logic using performance counters needs to look at
>>> MSR_MISC_ENABLE.PERF_AVAILABLE before touching any other resources.
>>>
>>> When virtualised under ESX, Xen dies with a #GP fault trying to read
>>> MSR_CORE_PERF_GLOBAL_CTRL.
>>>
>>> Factor this logic out into a separate function (it's already too squashed to
>>> the RHS), and insert a check of MSR_MISC_ENABLE.PERF_AVAILABLE.
>>>
>>> This also limits setting X86_FEATURE_ARCH_PERFMON, although oprofile (the only
>>> consumer of this flag) cross-checks too.
> 
> Fixes: 6bdb965178bb ("x86/intel: ensure Global Performance Counter
> Control is setup correctly")
> 
> (fixed up locally).
> 
>>> Reported-by: Jonathan Katz <jonathan.katz@aptar.com>
>>> Link: https://xcp-ng.org/forum/topic/10286/nesting-xcp-ng-on-esx-8
>>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>> ---
>>> CC: Jan Beulich <JBeulich@suse.com>
>>> CC: Roger Pau Monné <roger.pau@citrix.com>
>>> CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
>>>
>>> Untested, but this is the same pattern used by oprofile and watchdog setup.
>> Wow, in the oprofile case with pretty bad open-coding.
>>
>>> I've intentionally stopped using Intel style.  This file is already mixed (as
>>> visible even in context), and it doesn't remotely resemble it's Linux origin
>>> any more.
>> I guess you mean s/Intel/Linux/ here? (Yes, I'm entirely fine with using Xen
>> style there.)
> 
> Oops yes.
> 
>>
>>> --- a/xen/arch/x86/cpu/intel.c
>>> +++ b/xen/arch/x86/cpu/intel.c
>>> @@ -535,39 +535,49 @@ static void intel_log_freq(const struct cpuinfo_x86 *c)
>>>      printk("%u MHz\n", (factor * max_ratio + 50) / 100);
>>>  }
>>>  
>>> +static void init_intel_perf(struct cpuinfo_x86 *c)
>>> +{
>>> +    uint64_t val;
>>> +    unsigned int eax, ver, nr_cnt;
>>> +
>>> +    if ( c->cpuid_level <= 9 ||
>>> +         rdmsr_safe(MSR_IA32_MISC_ENABLE, val) ||
>> In e.g. intel_unlock_cpuid_leaves() and early_init_intel() and in particular
>> also in boot/head.S we access this MSR without recovery attached. Is there a
>> reason rdmsr_safe() needs using here?
> 
> Abundance of caution.  cpufreq/hwp.c uses a safe accessor.

Perhaps it (and other places) shouldn't?

> Given the regular NMI path works, I doubt we need the _safe() here.
> 
> As future work, it's accessed loads of times, so I'm highly tempted to
> have the BSP sanitise it once, and have the APs copy the "global" value.
> 
>>
>>> +         !(val & MSR_IA32_MISC_ENABLE_PERF_AVAIL) )
>>> +        return;
>>> +
>>> +    eax = cpuid_eax(10);
>>> +    ver = eax & 0xff;
>>> +    nr_cnt = (eax >> 8) & 0xff;
>>> +
>>> +    if ( ver && nr_cnt > 1 && nr_cnt <= 32 )
>>> +    {
>>> +        unsigned int cnt_mask = (1UL << nr_cnt) - 1;
>>> +
>>> +        /*
>>> +         * On (some?) Sapphire/Emerald Rapids platforms each package-BSP
>>> +         * starts with all the enable bits for the general-purpose PMCs
>>> +         * cleared.  Adjust so counters can be enabled from EVNTSEL.
>>> +         */
>>> +        rdmsrl(MSR_CORE_PERF_GLOBAL_CTRL, val);
>>> +
>>> +        if ( (val & cnt_mask) != cnt_mask )
>>> +        {
>>> +            printk("FIRMWARE BUG: CPU%u invalid PERF_GLOBAL_CTRL: %#"PRIx64" adjusting to %#"PRIx64"\n",
>>> +                   smp_processor_id(), val, val | cnt_mask);
>>> +            wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, val | cnt_mask);
>>> +        }
>>> +    }
>>> +
>>> +    __set_bit(X86_FEATURE_ARCH_PERFMON, c->x86_capability);
>> This moved, without the description suggesting the move is intentional.
>> It did live at the end of the earlier scope before, ...
> 
> Final paragraph of the commit message?
> 
> If PERF_AVAIL is clear, we don't have ARCH_PERFMON, whatever the CPUID
> leaves say.

Hmm, the final paragraph in the posting that I got in my inbox was:

"This also limits setting X86_FEATURE_ARCH_PERFMON, although oprofile (the only
 consumer of this flag) cross-checks too."

Which says quite the opposite: You now set the bit in more cases, i.e.
when nr_cnt is out of range or when ver is zero.

> OTOH, this bit really doesn't serve much value.  Given oprofile
> cross-checks everything anyway, I think it can be dropped.

Hmm, it's not entirely straightforward to see that all uses of
cpu_has_arch_perfmon can really be done away with.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 16:00:20 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 16:00:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875512.1285955 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taGfr-0007bu-TN; Tue, 21 Jan 2025 16:00:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875512.1285955; Tue, 21 Jan 2025 16:00:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taGfr-0007bn-Po; Tue, 21 Jan 2025 16:00:19 +0000
Received: by outflank-mailman (input) for mailman id 875512;
 Tue, 21 Jan 2025 16:00:18 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=qQWO=UN=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1taGfq-0007Ym-KB
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 16:00:18 +0000
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com
 [2a00:1450:4864:20::334])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id cd8404ae-d810-11ef-99a4-01e77a169b0f;
 Tue, 21 Jan 2025 17:00:15 +0100 (CET)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-4361815b96cso41011895e9.1
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 08:00:15 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38bf3278f06sm13798367f8f.70.2025.01.21.08.00.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 21 Jan 2025 08:00:14 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: cd8404ae-d810-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737475214; x=1738080014; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=06ttZ+7H3gBYv4ATiGOvO1zrwnLepB8AqgnXNCXx4Lg=;
        b=P5jn1yY67UvBJBq0/76SQBUip/cmF+7/yulCoAyuzXjB387xwgWN8m3MWtJ9yivTEJ
         KAsmEPHcXIayX+tn43QVDGFzL8m3mSNFiBFRCcyaiMlMfA3gm3AqNiYuzJDPkzmrhBBr
         unYFVrzhPVOrvsA3pPQo5Ci3hK692t1PQttZk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737475214; x=1738080014;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=06ttZ+7H3gBYv4ATiGOvO1zrwnLepB8AqgnXNCXx4Lg=;
        b=MDSSmy6sAGRZaQyWGN/LPROlJm8mBZoM1bQN7+GgJ3TwWAKpPAIj/L82ULO4LFG1qL
         oygs0dPtkdFdgLK8LHOkcOG3pYFQajdwBtbNVbBNLAlRmqUNipEXiOMweRboHFdM+XwE
         og0wC6imYEwNaUFbvPkRJQYp5qhd9/CRipKdDpUTUUypYgphi3kGzi2r3wjE1wHwZik5
         kTt7qAuL20HhEHMyybwim2AUSVnAuZZBjtCIet8mUz4clqcCweOv4GOKubf7TZTzsPF3
         XpdIrQJ8U5bUcdg+qyH5/vktMwxX4AoOvzrW9XM0O0UTu2s6CNuHfbcL0XUkvYYqrPGf
         ng4A==
X-Forwarded-Encrypted: i=1; AJvYcCX2gGl3Egsek0cldBds71Pt2nt92jnS5KieW8ibQlCRkRtOPCALQ1aiILo33ZV0u/YH1N4oJhSfHi8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YypMm57k51xe4MPgwLrjf2SqUKU8Rv64Qazd8FBsOdhWMkX/1+e
	UQA5mKIRbuVID85L2jAUgl75YI4pNNvWYwDAMIKuvm2WNvj7/ve9qyIKoBLZNH0=
X-Gm-Gg: ASbGncstnqZWtKU9lyEYvuZ/iEPAaW36apObjk5NHiNc4bRUvaU9h8UZi8kDdPQpwJ5
	HaNb11mdcWDW8rOaa+yQVSeeuLtdiYPBR79A8zIlut36ieFDYu2JCz2GRTi5IWCUM7wNA9uul2V
	+jwYUiUex5MB4qQApC120uoMOeUUet8TNCd25184Kai0uAlaMBKLFrzQSir/UkuoyRwTKaTSqjS
	ydD1Fm/+B33Kmk1WzKPfnMfP4yPm58vB1pAjm32Js7xhuBYbdHIkAumWlP35lM7B5ilMx2ZO/SD
	5P5NVSfMnTfAembnTIrlXucbDSQ6yUAp6Q==
X-Google-Smtp-Source: AGHT+IGnRwftRQsynKWeKoCMkaN6QpepNctWssTFe3BfWf1ikj8/+KyesEjed0/FsD2FQDLMiY1a8g==
X-Received: by 2002:a05:600c:5486:b0:436:51bb:7a52 with SMTP id 5b1f17b1804b1-438913c9c93mr169542795e9.7.1737475214593;
        Tue, 21 Jan 2025 08:00:14 -0800 (PST)
Message-ID: <9d7a1ee2-e7cc-497e-899a-028d739a1b7a@citrix.com>
Date: Tue, 21 Jan 2025 16:00:13 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20] x86/intel: Fix PERF_GLOBAL fixup when
 virtualised
To: Jan Beulich <jbeulich@suse.com>
Cc: Jonathan Katz <jonathan.katz@aptar.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20250121142510.358996-1-andrew.cooper3@citrix.com>
 <2b36d54d-88fb-4ad4-b0e4-cfa837872b14@suse.com>
 <ae54889d-ae82-4df3-a35f-ea09f3972eec@citrix.com>
 <445f93d3-626e-40ca-9acd-db3af83be1e5@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <445f93d3-626e-40ca-9acd-db3af83be1e5@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 21/01/2025 3:58 pm, Jan Beulich wrote:
> On 21.01.2025 16:23, Andrew Cooper wrote:
>> On 21/01/2025 3:03 pm, Jan Beulich wrote:
>>> On 21.01.2025 15:25, Andrew Cooper wrote:
>>>> +         !(val & MSR_IA32_MISC_ENABLE_PERF_AVAIL) )
>>>> +        return;
>>>> +
>>>> +    eax = cpuid_eax(10);
>>>> +    ver = eax & 0xff;
>>>> +    nr_cnt = (eax >> 8) & 0xff;
>>>> +
>>>> +    if ( ver && nr_cnt > 1 && nr_cnt <= 32 )
>>>> +    {
>>>> +        unsigned int cnt_mask = (1UL << nr_cnt) - 1;
>>>> +
>>>> +        /*
>>>> +         * On (some?) Sapphire/Emerald Rapids platforms each package-BSP
>>>> +         * starts with all the enable bits for the general-purpose PMCs
>>>> +         * cleared.  Adjust so counters can be enabled from EVNTSEL.
>>>> +         */
>>>> +        rdmsrl(MSR_CORE_PERF_GLOBAL_CTRL, val);
>>>> +
>>>> +        if ( (val & cnt_mask) != cnt_mask )
>>>> +        {
>>>> +            printk("FIRMWARE BUG: CPU%u invalid PERF_GLOBAL_CTRL: %#"PRIx64" adjusting to %#"PRIx64"\n",
>>>> +                   smp_processor_id(), val, val | cnt_mask);
>>>> +            wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, val | cnt_mask);
>>>> +        }
>>>> +    }
>>>> +
>>>> +    __set_bit(X86_FEATURE_ARCH_PERFMON, c->x86_capability);
>>> This moved, without the description suggesting the move is intentional.
>>> It did live at the end of the earlier scope before, ...
>> Final paragraph of the commit message?
>>
>> If PERF_AVAIL is clear, we don't have ARCH_PERFMON, whatever the CPUID
>> leaves say.
> Hmm, the final paragraph in the posting that I got in my inbox was:
>
> "This also limits setting X86_FEATURE_ARCH_PERFMON, although oprofile (the only
>  consumer of this flag) cross-checks too."
>
> Which says quite the opposite: You now set the bit in more cases, i.e.
> when nr_cnt is out of range or when ver is zero.

Oh, right.  Yeah, that was unintentional.  I'll adjust.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 16:12:37 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 16:12:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875523.1285965 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taGrW-0001Kn-Ti; Tue, 21 Jan 2025 16:12:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875523.1285965; Tue, 21 Jan 2025 16:12:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taGrW-0001Kg-Qr; Tue, 21 Jan 2025 16:12:22 +0000
Received: by outflank-mailman (input) for mailman id 875523;
 Tue, 21 Jan 2025 16:12:21 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=jEc5=UN=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1taGrV-0001Ka-6W
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 16:12:21 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 78852ce9-d812-11ef-99a4-01e77a169b0f;
 Tue, 21 Jan 2025 17:12:11 +0100 (CET)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-ab39f84cbf1so696985766b.3
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 08:12:11 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab384c57034sm766173666b.34.2025.01.21.08.12.09
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 21 Jan 2025 08:12:10 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 78852ce9-d812-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737475931; x=1738080731; 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=mSV15Srcq+Nl4YhU/S4lmFiS7ITihItYiuJhQd3Ib/w=;
        b=HLYZ7OmSFEVwKm6JG3OlJteNUMYFIWCWnk9FGDnBAVQiCxm+OP+6BkMNwHS2pVnS0X
         oObd9na02kPyvze75Gxa9B3g25zA42Bws8AHybnn0MMbomxzg/hhDdkpmfDGECUp2qBr
         8tEQvuvJmVJ99p04qC7cTrcjCduyNErDnW2L0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737475931; x=1738080731;
        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=mSV15Srcq+Nl4YhU/S4lmFiS7ITihItYiuJhQd3Ib/w=;
        b=IR33Ll4SVCTseKTvXNJhrTa8qaXbfm4/9Fy7mBb/hlnHIUo5ehO2rJHgxSDJnfqCuV
         VJLRIZT38N2/wYN0BYZTpaDtf0zRjwa/WpsF3+LHxBKm3AeRLLxf6SbQkMAQeVtfJPB2
         ZDUmBdtkTgdmsUvOc6v+i0QUjvJ3lM2GLvXQ6RYn13U3rg+kB0L7Ke8+Xcy+bwMNAYbe
         4/imRCnrZMjHYCLMdrb3cMN9YIJCdaQUEM2tWc5GHiLRkZf0n2hijYQaT0AAErvJ7Yb0
         eLyu7hSiXKTGQQ/5P3NbVMkQuH9+2OWvQu/wO0Jkl4Nim6Gi7s5V9EDbh9X+PTrBj6iZ
         WpIg==
X-Gm-Message-State: AOJu0YyyKLmYjtO5So2G/liACXSJJVHPPDLhqYRC592nfbc+PARCvQRI
	Rch42UtywPm0uBJIokxb/HpMLUHGI2zSprZFSJPACci4G/wCekQaKIrm31i9mbA=
X-Gm-Gg: ASbGncuTKWA4g2L9WD2TL3rg5J+gLDeqT/fLN6dc88pWKlEpqjKMLUC+mvmlq7dxexh
	VmdNTOO9HVifi54ri7gyIJ+1vKKMXeG4rPkRh078Ro/Pd20CbLwataapVOG1bOCra9zlklPQyZu
	oSZgedjHq+GuP2BUGBauIFP5aC2pHo9ier4EEXNk+nRQB0+Mrep2kU3+UwIUL4b8YnGv6cC+GIy
	dINV7vdZYeXEJiSnGhH7R2e9LeO+X3MP64AzgYR4iL1oFTfk0o+P9Pc92TcbUr6us5FXRnDoFpy
	gBKN
X-Google-Smtp-Source: AGHT+IGTVh6WQm4fJk2laXvh16Rlqyg0azoJHf9oav0dG9alBlsqTyMIMzivO4Nh7fQv7BLxPEpT/w==
X-Received: by 2002:a17:907:d1b:b0:aae:fd36:f511 with SMTP id a640c23a62f3a-ab38b3cce8cmr1615142166b.47.1737475930757;
        Tue, 21 Jan 2025 08:12:10 -0800 (PST)
Date: Tue, 21 Jan 2025 17:12:09 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Xen-devel <xen-devel@lists.xenproject.org>,
	Jonathan Katz <jonathan.katz@aptar.com>,
	Jan Beulich <JBeulich@suse.com>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>
Subject: Re: [PATCH for-4.20] x86/intel: Fix PERF_GLOBAL fixup when
 virtualised
Message-ID: <Z4_HWTpXfj19-BA7@macbook.local>
References: <20250121142510.358996-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250121142510.358996-1-andrew.cooper3@citrix.com>

On Tue, Jan 21, 2025 at 02:25:10PM +0000, Andrew Cooper wrote:
> Logic using performance counters needs to look at
> MSR_MISC_ENABLE.PERF_AVAILABLE before touching any other resources.
> 
> When virtualised under ESX, Xen dies with a #GP fault trying to read
> MSR_CORE_PERF_GLOBAL_CTRL.
> 
> Factor this logic out into a separate function (it's already too squashed to
> the RHS), and insert a check of MSR_MISC_ENABLE.PERF_AVAILABLE.
> 
> This also limits setting X86_FEATURE_ARCH_PERFMON, although oprofile (the only
> consumer of this flag) cross-checks too.
> 
> Reported-by: Jonathan Katz <jonathan.katz@aptar.com>
> Link: https://xcp-ng.org/forum/topic/10286/nesting-xcp-ng-on-esx-8
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> CC: Jan Beulich <JBeulich@suse.com>
> CC: Roger Pau Monné <roger.pau@citrix.com>
> CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> 
> Untested, but this is the same pattern used by oprofile and watchdog setup.
> 
> I've intentionally stopped using Intel style.  This file is already mixed (as
> visible even in context), and it doesn't remotely resemble it's Linux origin
> any more.
> 
> For 4.20.  This regressions has already been backported.
> ---
>  xen/arch/x86/cpu/intel.c | 64 +++++++++++++++++++++++-----------------
>  1 file changed, 37 insertions(+), 27 deletions(-)
> 
> diff --git a/xen/arch/x86/cpu/intel.c b/xen/arch/x86/cpu/intel.c
> index 6a7347968ba2..586ae84d806d 100644
> --- a/xen/arch/x86/cpu/intel.c
> +++ b/xen/arch/x86/cpu/intel.c
> @@ -535,39 +535,49 @@ static void intel_log_freq(const struct cpuinfo_x86 *c)
>      printk("%u MHz\n", (factor * max_ratio + 50) / 100);
>  }
>  
> +static void init_intel_perf(struct cpuinfo_x86 *c)
> +{
> +    uint64_t val;
> +    unsigned int eax, ver, nr_cnt;
> +
> +    if ( c->cpuid_level <= 9 ||
> +         rdmsr_safe(MSR_IA32_MISC_ENABLE, val) ||
> +         !(val & MSR_IA32_MISC_ENABLE_PERF_AVAIL) )
> +        return;
> +
> +    eax = cpuid_eax(10);
> +    ver = eax & 0xff;
> +    nr_cnt = (eax >> 8) & 0xff;
> +
> +    if ( ver && nr_cnt > 1 && nr_cnt <= 32 )
> +    {
> +        unsigned int cnt_mask = (1UL << nr_cnt) - 1;
> +
> +        /*
> +         * On (some?) Sapphire/Emerald Rapids platforms each package-BSP
> +         * starts with all the enable bits for the general-purpose PMCs
> +         * cleared.  Adjust so counters can be enabled from EVNTSEL.
> +         */
> +        rdmsrl(MSR_CORE_PERF_GLOBAL_CTRL, val);
> +
> +        if ( (val & cnt_mask) != cnt_mask )
> +        {
> +            printk("FIRMWARE BUG: CPU%u invalid PERF_GLOBAL_CTRL: %#"PRIx64" adjusting to %#"PRIx64"\n",
> +                   smp_processor_id(), val, val | cnt_mask);
> +            wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, val | cnt_mask);
> +        }
> +    }
> +
> +    __set_bit(X86_FEATURE_ARCH_PERFMON, c->x86_capability);

With this chunk moved back inside the if scope, and the Fixes tag
added:

Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 16:13:27 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 16:13:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875531.1285976 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taGsZ-0001pq-8g; Tue, 21 Jan 2025 16:13:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875531.1285976; Tue, 21 Jan 2025 16:13:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taGsZ-0001pj-3T; Tue, 21 Jan 2025 16:13:27 +0000
Received: by outflank-mailman (input) for mailman id 875531;
 Tue, 21 Jan 2025 16:13:25 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=SGjB=UN=bounce.vates.tech=bounce-md_30504962.678fc7a0.v1-142299a20ea043b8a0073e531c53c474@srs-se1.protection.inumbo.net>)
 id 1taGsX-0001oY-5o
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 16:13:25 +0000
Received: from mail187-20.suw11.mandrillapp.com
 (mail187-20.suw11.mandrillapp.com [198.2.187.20])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a2441a15-d812-11ef-a0e4-8be0dac302b0;
 Tue, 21 Jan 2025 17:13:22 +0100 (CET)
Received: from pmta09.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail187-20.suw11.mandrillapp.com (Mailchimp) with ESMTP id
 4Ycsh06F2yzFCWYww
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 16:13:20 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 142299a20ea043b8a0073e531c53c474; Tue, 21 Jan 2025 16:13:20 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a2441a15-d812-11ef-a0e4-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1737476000; x=1737746000;
	bh=QNm5/FdxziH0dgBZNhQT9Vh/itVkKAAaHUfT5p3fmhI=;
	h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version:
	 Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From;
	b=GrDHO6bglyJLi8vnC98zxgKqJqxem8aSI6b/1646hpQiMEfPWRBVCWzoCPEY7JxUI
	 Drrowom3whjLVBLbWrSoefM4iZ+wBw5MOPqv3X5rF+qfmTHWkMwKc1Adkz/S+iMhms
	 xcPgscUBmIKw2C7uMgXih+PPRfzN7t6eRWhLLydb4vvhTPGe1AMUCasenv7iC3dGDS
	 3od/fw1t2eD74wNjSmFuYbiAAY/hKQsHGLC4UMdgDF4GDWFvw2CEIAJaQ6wTFoelT5
	 Quu26CdVNqPUYgznak6eGM/Bc95NIghh8cZCzGzd0uYGkbu3TP/Cu5mv1BFAXrqVrM
	 hQ5yT9rEpw5WQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1737476000; x=1737736500; i=teddy.astie@vates.tech;
	bh=QNm5/FdxziH0dgBZNhQT9Vh/itVkKAAaHUfT5p3fmhI=;
	h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version:
	 Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From;
	b=vxYYTIVeGWEwTojCPG6mqwTgcQnwIHuHnHP+gT2cc6ec0KYdgDk3AkmXeJqsD/sGA
	 PoXY4fYwiGufFZ0tgXaja40wA98x8UoN7SYmuayh3z+CXHci4nqRbm2AnyvvWHHf/l
	 Yaz+Zg5yFxwfz3kacFubFGnlfO6t3tRSeLsLBxKi3YzywIBlnB+ZWZPZ1v9QqH0NEm
	 hBpyzUH60UsNcVRQh5Pea6FnuI/t2+i0vN7YscMJNz+fVkoRi/6tqyBTJAtMSG9PcN
	 VGVNT1aKRIcpfq3e5t/p/zCm72DZcFA/GPTZ+dvDd4/QkPoeoHUNDvQnSrk22TGp+f
	 S74SI6jIhfCGw==
From: "Teddy Astie" <teddy.astie@vates.tech>
Subject: =?utf-8?Q?[XEN=20RFC=20PATCH=20v5=200/5]=20IOMMU=20subsystem=20redesign=20and=20PV-IOMMU=20interface?=
X-Mailer: git-send-email 2.45.3
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1737475999126
To: xen-devel@lists.xenproject.org
Cc: "Teddy Astie" <teddy.astie@vates.tech>, "Andrew Cooper" <andrew.cooper3@citrix.com>, "Jan Beulich" <jbeulich@suse.com>, "Julien Grall" <julien@xen.org>, "Stefano Stabellini" <sstabellini@kernel.org>, "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>, "Lukasz Hawrylko" <lukasz@hawrylko.pl>, "Daniel P. Smith" <dpsmith@apertussolutions.com>, "=?utf-8?Q?Mateusz=20M=C3=B3wka?=" <mateusz.mowka@intel.com>, "=?utf-8?Q?Marek=20Marczykowski-G=C3=B3recki?=" <marmarek@invisiblethingslab.com>
Message-Id: <cover.1737470269.git.teddy.astie@vates.tech>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.142299a20ea043b8a0073e531c53c474?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250121:md
Date: Tue, 21 Jan 2025 16:13:20 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

This work has been presented at Xen Summit 2024 during the
  IOMMU paravirtualization and Xen IOMMU subsystem rework
design session.

Operating systems may want to have access to a IOMMU in order to do DMA
protection or implement certain features (e.g VFIO on Linux).

VFIO support is mandatory for framework such as SPDK, which can be useful t=
o
implement an alternative storage backend for virtual machines [1].

In this patch series, we introduce in Xen the ability to manage several
contexts per domain and provide a new hypercall interface to allow guests
to manage IOMMU contexts.

The VT-d driver is updated to support these new features.

[1] Using SPDK with the Xen hypervisor - FOSDEM 2023
---
Cc: Marek Marczykowski-G=C3=B3recki <marmarek@invisiblethingslab.com>

PCI Passthrough now work on my side, but things are still feels quite britt=
le.

Changed in v2 :
* fixed Xen crash when dumping IOMMU contexts (using X debug key)
with DomUs without IOMMU
* s/dettach/detach/
* removed some unused includes
* fix dangling devices in contexts with detach

Changed in v3 :
* lock entirely map/unmap in hypercall
* prevent IOMMU operations on dying contexts (fix race condition)
* iommu_check_context+iommu_get_context -> iommu_get_context and check for =
NULL

Changed in v4 :
* Part of initialization logic is moved to domain or toolstack (IOMMU_init)
  + domain/toolstack now decides on "context count" and "pagetable pool siz=
e"
  + for now, all domains are able to initialize PV-IOMMU
* introduce "dom0-iommu=3Dno-dma" to make default context block all DMA
  (disables HAP and sync-pt), enforcing usage of PV-IOMMU for DMA
  Can be used to expose properly "Pre-boot DMA protection"
* redesigned locking logic for contexts
  + contexts are accessed using iommu_get_context and released with iommu_p=
ut_context

Changed in v5 :
* various PCI Passthrough related fixes
  + rewrote parts of PCI Passthrough logic
  + various other related bug fixes
* simplified VT-d DID (for hardware) management by only having one map inst=
ead of two
  (pseudo_domid map was previously used for old quarantine code then recycl=
ed for PV-IOMMU
   in addition to another map also tracing Domain<->VT-d DID, now there is =
only one
   map tracking both making things simpler)
* reworked parts of Xen quarantine logic (needed for PCI Passthrough)
* added cf_check annotations
* some changes to PV-IOMMU headers (Alejandro)

TODO:
* add stub implementations for bissecting needs and non-ported IOMMU implem=
entations
* fix some issues with no-dma+PV and grants
* complete "no-dma" mode (expose to toolstack, add documentation, ...)
* properly define nested mode and PASID support

* make new quarantine code more unity region aware (isolate devices with
  different reserved regions regions using separate 'contexts')
* find a way to make PV-IOMMU work in DomUs (they don't see machine bdf)
* there are corner cases with PV-IOMMU and to-domain Xen PCI Passthrough
  (e.g pci-assignable-remove will reassign to context 0, while the driver
   expects the device to to be in context X)

Teddy Astie (5):
  docs/designs: Add a design document for IOMMU subsystem redesign
  docs/designs: Add a design document for PV-IOMMU
  xen/public: Introduce PV-IOMMU hypercall interface
  IOMMU: Introduce redesigned IOMMU subsystem
  VT-d: Port IOMMU driver to new subsystem

 docs/designs/iommu-contexts.md       |  403 ++++++
 docs/designs/pv-iommu.md             |  116 ++
 xen/arch/x86/domain.c                |    2 +-
 xen/arch/x86/include/asm/arena.h     |   54 +
 xen/arch/x86/include/asm/iommu.h     |   58 +-
 xen/arch/x86/include/asm/pci.h       |   17 -
 xen/arch/x86/mm/p2m-ept.c            |    2 +-
 xen/arch/x86/pv/dom0_build.c         |    6 +-
 xen/arch/x86/tboot.c                 |    4 +-
 xen/common/Makefile                  |    1 +
 xen/common/memory.c                  |    4 +-
 xen/common/pv-iommu.c                |  539 ++++++++
 xen/drivers/passthrough/Makefile     |    3 +
 xen/drivers/passthrough/context.c    |  740 +++++++++++
 xen/drivers/passthrough/iommu.c      |  431 +++----
 xen/drivers/passthrough/pci.c        |  379 ++----
 xen/drivers/passthrough/quarantine.c |   49 +
 xen/drivers/passthrough/vtd/Makefile |    2 +-
 xen/drivers/passthrough/vtd/extern.h |   16 +-
 xen/drivers/passthrough/vtd/iommu.c  | 1692 ++++++++------------------
 xen/drivers/passthrough/vtd/iommu.h  |    4 +-
 xen/drivers/passthrough/vtd/qinval.c |    2 +-
 xen/drivers/passthrough/vtd/quirks.c |   20 +-
 xen/drivers/passthrough/x86/Makefile |    1 +
 xen/drivers/passthrough/x86/arena.c  |  157 +++
 xen/drivers/passthrough/x86/iommu.c  |  299 +++--
 xen/include/hypercall-defs.c         |    6 +
 xen/include/public/pv-iommu.h        |  343 ++++++
 xen/include/public/xen.h             |    1 +
 xen/include/xen/iommu.h              |  119 +-
 xen/include/xen/pci.h                |    3 +
 31 files changed, 3606 insertions(+), 1867 deletions(-)
 create mode 100644 docs/designs/iommu-contexts.md
 create mode 100644 docs/designs/pv-iommu.md
 create mode 100644 xen/arch/x86/include/asm/arena.h
 create mode 100644 xen/common/pv-iommu.c
 create mode 100644 xen/drivers/passthrough/context.c
 create mode 100644 xen/drivers/passthrough/quarantine.c
 create mode 100644 xen/drivers/passthrough/x86/arena.c
 create mode 100644 xen/include/public/pv-iommu.h

-- 
2.45.3



 | Vates 

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech



From xen-devel-bounces@lists.xenproject.org Tue Jan 21 16:13:27 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 16:13:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875532.1285979 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taGsZ-0001sb-Fq; Tue, 21 Jan 2025 16:13:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875532.1285979; Tue, 21 Jan 2025 16:13:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taGsZ-0001r1-Ai; Tue, 21 Jan 2025 16:13:27 +0000
Received: by outflank-mailman (input) for mailman id 875532;
 Tue, 21 Jan 2025 16:13:25 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=uENJ=UN=bounce.vates.tech=bounce-md_30504962.678fc7a2.v1-bf2c2e70db3446bca2f4aa45b151a049@srs-se1.protection.inumbo.net>)
 id 1taGsX-0001Ka-Dp
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 16:13:25 +0000
Received: from mail187-43.suw11.mandrillapp.com
 (mail187-43.suw11.mandrillapp.com [198.2.187.43])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a310d9fd-d812-11ef-99a4-01e77a169b0f;
 Tue, 21 Jan 2025 17:13:23 +0100 (CET)
Received: from pmta09.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail187-43.suw11.mandrillapp.com (Mailchimp) with ESMTP id
 4Ycsh22dxFzLfH57N
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 16:13:22 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 bf2c2e70db3446bca2f4aa45b151a049; Tue, 21 Jan 2025 16:13:22 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a310d9fd-d812-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1737476002; x=1737746002;
	bh=0JqsHknEraVF6WKaagEJ7SDzLULxFQMArD2KjcyBzZA=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=IUjM/a5X9maMH/j4Oxaa/n6f4nl4W2Etp6nuIhvH+GRvB3xFg8LbyzY+nDT6leupn
	 TUXUS6gffRRCbtcjd9Fe4wG3dg9S89SEuQO4bSJs31zXrhB0gqdfQpIkrRpHYXx4Y8
	 lJivicC9HdgiSv0v2zMmyCHkQ1Jw7R75cMFqLTjmCCQRaFPHYnNZ6/zvKbnyC+IQ3d
	 orItl7uINKIJTmqjHT+r7mXd0Oa45M2iJCg4MWt2A9KeNlx3cikAAjJc9g6DRb08K3
	 RdhTlwrzoVFKcdOzg78a4olPrhmMM43vHSMDDrYLxjE2G66SRLvkCbrlvLG4Bwnsdf
	 KEWku12YhTvCA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1737476002; x=1737736502; i=teddy.astie@vates.tech;
	bh=0JqsHknEraVF6WKaagEJ7SDzLULxFQMArD2KjcyBzZA=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=SDPAv6SyT/maDWKEpOGx4dujvw8sQiMOQWyJPf15NtEyOFKio8hvxEQDVuF6ltJPd
	 wqduo9Vryf67m1CUX9ShY2I5ZrPajRaWgTElMfG7hIz7kRfWPY7XLzrT7hhDvbYnWE
	 OKx7PPak/54zCzwXLf2E308DFwg4LGimpPZhYpF5D9isTdUcw0YvVLJ87KilxhUxTG
	 7Qhldv6b7aWgf5BdvJUQ+gmpGxr3Em9V39S/QdBYKXEYpaJA2fUKZ4M0iM23ODF/Rf
	 cPEUKHG4nekWxWaR9iIpImHxy+WbdSIYe8ud/klLIhvi1AZIW++9+SOv39ovv86NpZ
	 As02RT6SbMEAQ==
From: "Teddy Astie" <teddy.astie@vates.tech>
Subject: =?utf-8?Q?[XEN=20RFC=20PATCH=20v5=201/5]=20docs/designs:=20Add=20a=20design=20document=20for=20IOMMU=20subsystem=20redesign?=
X-Mailer: git-send-email 2.45.3
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1737476001087
To: xen-devel@lists.xenproject.org
Cc: "Teddy Astie" <teddy.astie@vates.tech>, "Andrew Cooper" <andrew.cooper3@citrix.com>, "Jan Beulich" <jbeulich@suse.com>, "Julien Grall" <julien@xen.org>, "Stefano Stabellini" <sstabellini@kernel.org>, "=?utf-8?Q?Marek=20Marczykowski-G=C3=B3recki?=" <marmarek@invisiblethingslab.com>
Message-Id: <0907cf1c8b5a706bb02c31eda2f1d3e089feac5b.1737470269.git.teddy.astie@vates.tech>
In-Reply-To: <cover.1737470269.git.teddy.astie@vates.tech>
References: <cover.1737470269.git.teddy.astie@vates.tech>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.bf2c2e70db3446bca2f4aa45b151a049?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250121:md
Date: Tue, 21 Jan 2025 16:13:22 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Current IOMMU subsystem has some limitations that make PV-IOMMU practically impossible.
One of them is the assumtion that each domain is bound to a single "IOMMU domain", which
also causes complications with quarantine implementation.

Moreover, current IOMMU subsystem is not entirely well-defined, for instance, the behavior
of map_page between ARM SMMUv3 and x86 VT-d/AMD-Vi greatly differs. On ARM, it can modifies
the domain page table while on x86, it may be forbidden (e.g using HAP with PVH), or only
modifying the devices PoV (e.g using PV).

The goal of this redesign is to define more explicitely the behavior and interface of the
IOMMU subsystem while allowing PV-IOMMU to be effectively implemented.

Signed-off-by Teddy Astie <teddy.astie@vates.tech>
---
Changes in v4:
* added init and remote_op commands
---
 docs/designs/iommu-contexts.md | 403 +++++++++++++++++++++++++++++++++
 1 file changed, 403 insertions(+)
 create mode 100644 docs/designs/iommu-contexts.md

diff --git a/docs/designs/iommu-contexts.md b/docs/designs/iommu-contexts.md
new file mode 100644
index 0000000000..9d6fb95549
--- /dev/null
+++ b/docs/designs/iommu-contexts.md
@@ -0,0 +1,403 @@
+# IOMMU context management in Xen
+
+Status: Experimental
+Revision: 0
+
+# Background
+
+The design for *IOMMU paravirtualization for Dom0* [1] explains that some guests may
+want to access to IOMMU features. In order to implement this in Xen, several adjustments
+needs to be made to the IOMMU subsystem.
+
+This "hardware IOMMU domain" is currently implemented on a per-domain basis such as each
+domain actually has a specific *hardware IOMMU domain*, this design aims to allow a
+single Xen domain to manage several "IOMMU context", and allow some domains (e.g Dom0
+[1]) to modify their IOMMU contexts.
+
+In addition to this, quarantine feature can be refactored into using IOMMU contexts
+to reduce the complexity of platform-specific implementations and ensuring more
+consistency across platforms.
+
+# IOMMU context
+
+We define a "IOMMU context" as being a *hardware IOMMU domain*, but named as a context
+to avoid confusion with Xen domains.
+It represents some hardware-specific data structure that contains mappings from a device
+frame-number to a machine frame-number (e.g using a pagetable) that can be applied to
+a device using IOMMU hardware.
+
+This structure is bound to a Xen domain, but a Xen domain may have several IOMMU context.
+These contexts may be modifiable using the interface as defined in [1] aside some
+specific cases (e.g modifying default context).
+
+This is implemented in Xen as a new structure that will hold context-specific
+data.
+
+```c
+struct iommu_context {
+    u16 id; /* Context id (0 means default context) */
+    struct list_head devices;
+
+    struct arch_iommu_context arch;
+
+    bool opaque; /* context can't be modified nor accessed (e.g HAP) */
+};
+```
+
+A context is identified by a number that is domain-specific and may be used by IOMMU
+users such as PV-IOMMU by the guest.
+
+struct arch_iommu_context is splited from struct arch_iommu
+
+```c
+struct arch_iommu_context
+{
+    spinlock_t pgtables_lock;
+    struct page_list_head pgtables;
+
+    union {
+        /* Intel VT-d */
+        struct {
+            uint64_t pgd_maddr; /* io page directory machine address */
+            domid_t *didmap; /* per-iommu DID */
+            unsigned long *iommu_bitmap; /* bitmap of iommu(s) that the context uses */
+        } vtd;
+        /* AMD IOMMU */
+        struct {
+            struct page_info *root_table;
+        } amd;
+    };
+};
+
+struct arch_iommu
+{
+    spinlock_t mapping_lock; /* io page table lock */
+    struct {
+        struct page_list_head list;
+        spinlock_t lock;
+    } pgtables;
+
+    struct list_head identity_maps;
+
+    union {
+        /* Intel VT-d */
+        struct {
+            /* no more context-specific values */
+            unsigned int agaw; /* adjusted guest address width, 0 is level 2 30-bit */
+        } vtd;
+        /* AMD IOMMU */
+        struct {
+            unsigned int paging_mode;
+            struct guest_iommu *g_iommu;
+        } amd;
+    };
+};
+```
+
+IOMMU context information is now carried by iommu_context rather than being integrated to
+struct arch_iommu.
+
+# Xen domain IOMMU structure
+
+`struct domain_iommu` is modified to allow multiples context within a single Xen domain
+to exist :
+
+```c
+struct iommu_context_list {
+    uint16_t count; /* Context count excluding default context */
+
+    /* if count > 0 */
+
+    uint64_t *bitmap; /* bitmap of context allocation */
+    struct iommu_context *map; /* Map of contexts */
+};
+
+struct domain_iommu {
+    /* ... */
+
+    struct iommu_context default_ctx;
+    struct iommu_context_list other_contexts;
+
+    /* ... */
+}
+```
+
+default_ctx is a special context with id=0 that holds the page table mapping the entire
+domain, which basically preserve the previous behavior. All devices are expected to be
+bound to this context during initialization.
+
+Along with this default context that always exist, we use a pool of contexts that has a
+fixed size at domain initialization, where contexts can be allocated (if possible), and
+have a id matching their position in the map (considering that id != 0).
+These contexts may be used by IOMMU contexts users such as PV-IOMMU or quarantine domain
+(DomIO).
+
+# Platform independent context management interface
+
+A new platform independant interface is introduced in Xen hypervisor to allow
+IOMMU contexts users to create and manage contexts within domains.
+
+```c
+/* Direct context access functions (not supposed to be used directly) */
+struct iommu_context *iommu_get_context(struct domain *d, u16 ctx_no);
+void iommu_put_context(struct iommu_context *ctx);
+
+/* Flag for default context initialization */
+#define IOMMU_CONTEXT_INIT_default (1 << 0)
+
+/* Flag for quarantine contexts (scratch page, DMA Abort mode, ...) */
+#define IOMMU_CONTEXT_INIT_quarantine (1 << 1)
+
+int iommu_context_init(struct domain *d, struct iommu_context *ctx, u16 ctx_no, u32 flags);
+
+/* Flag to specify that devices will need to be reattached to default domain */
+#define IOMMU_TEARDOWN_REATTACH_DEFAULT (1 << 0)
+
+/*
+ * Flag to specify that the context needs to be destroyed preemptively
+ * (multiple calls to iommu_context_teardown will be required)
+ */
+#define IOMMU_TEARDOWN_PREEMPT (1 << 1)
+
+int iommu_context_teardown(struct domain *d, struct iommu_context *ctx, u32 flags);
+
+/* Allocate a new context, uses CONTEXT_INIT flags */
+int iommu_context_alloc(struct domain *d, u16 *ctx_no, u32 flags);
+
+/* Free a context, uses CONTEXT_TEARDOWN flags */
+int iommu_context_free(struct domain *d, u16 ctx_no, u32 flags);
+
+/* Move a device from one context to another, including between different domains. */
+int iommu_reattach_context(struct domain *prev_dom, struct domain *next_dom,
+                           device_t *dev, u16 ctx_no);
+
+/* Add a device to a context for first initialization */
+int iommu_attach_context(struct domain *d, device_t *dev, u16 ctx_no);
+
+/* Remove a device from a context, effectively removing it from the IOMMU. */
+int iommu_detach_context(struct domain *d, device_t *dev);
+```
+
+This interface will use a new interface with drivers to implement these features.
+
+Some existing functions will have a new parameter to specify on what context to do the operation.
+- iommu_map (iommu_legacy_map untouched)
+- iommu_unmap (iommu_legacy_unmap untouched)
+- iommu_lookup_page
+- iommu_iotlb_flush
+
+These functions will modify the iommu_context structure to accomodate with the
+operations applied, these functions will be used to replace some operations previously
+made in the IOMMU driver.
+
+# IOMMU platform_ops interface changes
+
+The IOMMU driver needs to expose a way to create and manage IOMMU contexts, the approach
+taken here is to modify the interface to allow specifying a IOMMU context on operations,
+and at the same time, simplifying the interface by relying more on iommu
+platform-independent code.
+
+Added functions in iommu_ops
+
+```c
+/* Initialize a context (creating page tables, allocating hardware, structures, ...) */
+int (*context_init)(struct domain *d, struct iommu_context *ctx,
+                    u32 flags);
+/* Destroy a context, assumes no device is bound to the context. */
+int (*context_teardown)(struct domain *d, struct iommu_context *ctx,
+                        u32 flags);
+/* Put a device in a context (assumes the device is not attached to another context) */
+int (*attach)(struct domain *d, device_t *dev,
+              struct iommu_context *ctx);
+/* Remove a device from a context, and from the IOMMU. */
+int (*detach)(struct domain *d, device_t *dev,
+              struct iommu_context *prev_ctx);
+/* Move the device from a context to another, including if the new context is in
+   another domain. d corresponds to the target domain. */
+int (*reattach)(struct domain *d, device_t *dev,
+                struct iommu_context *prev_ctx,
+                struct iommu_context *ctx);
+
+#ifdef CONFIG_HAS_PCI
+/* Specific interface for phantom function devices. */
+int (*add_devfn)(struct domain *d, struct pci_dev *pdev, u16 devfn,
+                 struct iommu_context *ctx);
+int (*remove_devfn)(struct domain *d, struct pci_dev *pdev, u16 devfn,
+                    struct iommu_context *ctx);
+#endif
+
+/* Changes in existing to use a specified iommu_context. */
+int __must_check (*map_page)(struct domain *d, dfn_t dfn, mfn_t mfn,
+                             unsigned int flags,
+                             unsigned int *flush_flags,
+                             struct iommu_context *ctx);
+int __must_check (*unmap_page)(struct domain *d, dfn_t dfn,
+                               unsigned int order,
+                               unsigned int *flush_flags,
+                               struct iommu_context *ctx);
+int __must_check (*lookup_page)(struct domain *d, dfn_t dfn, mfn_t *mfn,
+                                unsigned int *flags,
+                                struct iommu_context *ctx);
+
+int __must_check (*iotlb_flush)(struct domain *d,
+                                struct iommu_context *ctx, dfn_t dfn,
+                                unsigned long page_count,
+                                unsigned int flush_flags);
+
+void (*clear_root_pgtable)(struct domain *d, struct iommu_context *ctx);
+```
+
+These functions are redundant with existing functions, therefore, the following functions
+are replaced with new equivalents :
+- quarantine_init : platform-independent code and IOMMU_CONTEXT_INIT_quarantine flag
+- add_device : attach and add_devfn (phantom)
+- assign_device : attach and add_devfn (phantom)
+- remove_device : detach and remove_devfn (phantom)
+- reassign_device : reattach
+
+Some functionnal differences with previous functions, the following should be handled
+by platform-independent/arch-specific code instead of IOMMU driver :
+- identity mappings (unity mappings and rmrr)
+- device list in context and domain
+- domain of a device
+- quarantine
+
+The idea behind this is to implement IOMMU context features while simplifying IOMMU
+drivers implementations and ensuring more consistency between IOMMU drivers.
+
+## Phantom function handling
+
+PCI devices may use additionnal devfn to do DMA operations, in order to support such
+devices, an interface is added to map specific device functions without implying that
+the device is mapped to a new context (that may cause duplicates in Xen data structures).
+
+Functions add_devfn and remove_devfn allows to map a iommu context on specific devfn
+for a pci device, without altering platform-independent data structures.
+
+It is important for the reattach operation to care about these devices, in order
+to prevent devices from being partially reattached to the new context (see XSA-449 [2])
+by using a all-or-nothing approach for reattaching such devices.
+
+# Quarantine refactoring using IOMMU contexts
+
+The quarantine mecanism can be entirely reimplemented using IOMMU context, making
+it simpler, more consistent between platforms,
+
+Quarantine is currently only supported with x86 platforms and works by creating a
+single *hardware IOMMU domain* per quarantined device. All the quarantine logic is
+the implemented in a platform-specific fashion while actually implementing the same
+concepts :
+
+The *hardware IOMMU context* data structures for quarantine are currently stored in
+the device structure itself (using arch_pci_dev) and IOMMU driver needs to care about
+whether we are dealing with quarantine operations or regular operations (often dealt
+using macros such as QUARANTINE_SKIP or DEVICE_PGTABLE).
+
+The page table that will apply on the quarantined device is created reserved device
+regions, and adding mappings to a scratch page if enabled (quarantine=scratch-page).
+
+A new approach we can use is allowing the quarantine domain (DomIO) to manage IOMMU
+contexts, and implement all the quarantine logic using IOMMU contexts.
+
+That way, the quarantine implementation can be platform-independent, thus have a more
+consistent implementation between platforms. It will also allows quarantine to work
+with other IOMMU implementations without having to implement platform-specific behavior.
+Moreover, quarantine operations can be implemented using regular context operations
+instead of relying on driver-specific code.
+
+Quarantine implementation can be summarised as
+
+```c
+int iommu_quarantine_dev_init(device_t *dev)
+{
+    int ret;
+    u16 ctx_no;
+
+    if ( !iommu_quarantine )
+        return -EINVAL;
+
+    ret = iommu_context_alloc(dom_io, &ctx_no, IOMMU_CONTEXT_INIT_quarantine);
+
+    if ( ret )
+        return ret;
+
+    /** TODO: Setup scratch page, mappings... */
+
+    ret = iommu_reattach_context(dev->domain, dom_io, dev, ctx_no);
+
+    if ( ret )
+    {
+        ASSERT(!iommu_context_free(dom_io, ctx_no, 0));
+        return ret;
+    }
+
+    return ret;
+}
+```
+
+# Platform-specific considerations
+
+## Reference counters on target pages
+
+When mapping a guest page onto a IOMMU context, we need to make sure that
+this page is not reused for something else while being actually referenced
+by a IOMMU context. One way of doing it is incrementing the reference counter
+of each target page we map (excluding reserved regions), and decrementing it
+when the mapping isn't used anymore.
+
+One consideration to have is when destroying the context while having existing
+mappings in it. We can walk through the entire page table and decrement the
+reference counter of all mappings. All of that assumes that there is no reserved
+region mapped (which should be the case as a requirement of teardown, or as a
+consequence of REATTACH_DEFAULT flag).
+
+Another consideration is that the "cleanup mappings" operation may take a lot
+of time depending on the complexity of the page table. Making the teardown operation preemptable can allow the hypercall to be preempted if needed also preventing a malicious
+guest from stalling a CPU in a teardown operation with a specially crafted IOMMU
+context (e.g with several 1G superpages).
+
+## Limit the amount of pages IOMMU contexts can use
+
+In order to prevent a (eventually malicious) guest from causing too much allocations
+in Xen, we can enforce limits on the memory the IOMMU subsystem can use for IOMMU context.
+A possible implementation can be to preallocate a reasonably large chunk of memory
+and split it into pages for use by the IOMMU subsystem only for non-default IOMMU
+contexts (e.g PV-IOMMU interface), if this limitation is overcome, some operations
+may fail from the guest side. These limitations shouldn't impact "usual" operations
+of the IOMMU subsystem (e.g default context initialization).
+
+## x86 Architecture
+
+TODO
+
+### Intel VT-d
+
+VT-d uses DID to tag the *IOMMU domain* applied to a device and assumes that all entries
+with the same DID uses the same page table (i.e same IOMMU context).
+Under certain circonstances (e.g DRHD with DID limit below 16-bits), the *DID* is
+transparently converted into a DRHD-specific DID using a map managed internally.
+
+The current implementation of the code reuses the Xen domain_id as DID.
+However, by using multiples IOMMU contexts per domain, we can't use the domain_id for
+contexts (otherwise, different page tables will be mapped with the same DID).
+The following strategy is used :
+- on the default context, reuse the domain_id (the default context is unique per domain)
+- on non-default context, use a id allocated in the pseudo_domid map, (actually used by
+quarantine) which is a DID outside of Xen domain_id range
+
+### AMD-Vi
+
+TODO
+
+## Device-tree platforms
+
+### SMMU and SMMUv3
+
+TODO
+
+* * *
+
+[1] See pv-iommu.md
+
+[2] pci: phantom functions assigned to incorrect contexts
+https://xenbits.xen.org/xsa/advisory-449.html
\ No newline at end of file
-- 
2.45.3



Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 16:13:28 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 16:13:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875533.1285985 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taGsZ-0001xb-RI; Tue, 21 Jan 2025 16:13:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875533.1285985; Tue, 21 Jan 2025 16:13:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taGsZ-0001v2-Iy; Tue, 21 Jan 2025 16:13:27 +0000
Received: by outflank-mailman (input) for mailman id 875533;
 Tue, 21 Jan 2025 16:13:25 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=whPl=UN=bounce.vates.tech=bounce-md_30504962.678fc7a3.v1-ff9033a53f704e2c929778eda4f784eb@srs-se1.protection.inumbo.net>)
 id 1taGsX-0001oY-P7
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 16:13:25 +0000
Received: from mail187-43.suw11.mandrillapp.com
 (mail187-43.suw11.mandrillapp.com [198.2.187.43])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a3cebce8-d812-11ef-a0e4-8be0dac302b0;
 Tue, 21 Jan 2025 17:13:24 +0100 (CET)
Received: from pmta09.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail187-43.suw11.mandrillapp.com (Mailchimp) with ESMTP id
 4Ycsh36JvHzLfHCRV
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 16:13:23 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 ff9033a53f704e2c929778eda4f784eb; Tue, 21 Jan 2025 16:13:23 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a3cebce8-d812-11ef-a0e4-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1737476003; x=1737746003;
	bh=xTxb6vk36SreQPSgyQdzBvLcCEpJSeagGkdZk4HqOW8=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=SZckJbenf0532KYIm9npEXP0Mi4W3Y8u7HufTRPKfmueyXS8ZrZZCRXBkAgaNxPVM
	 wVd6H2A5bDI047ZE1RKliaaFfyJ+0ApiCwsvfVdluNPPcYN7o5T8kcf6K+5tKsAQuF
	 MYYPmnPsEvGPHZbQqX+/WjP7hu8ThWay45oYS2mhC+Vi/fB4aBj0Yf3ZnlkmNtr3oo
	 gWE5v3jvdIbwr1jyGILVY+gnZCnbGZvRe+9D4DH+piy31MIxEy8i3nGEqSf25FmNsK
	 2BS4nkC2+rNRlSV7YrGEQ/sOKrj3++BnFd7pOXO7UtV1ilO/HoKLPEfR+ubl6MnFWK
	 UaRjgjWINaKCA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1737476003; x=1737736503; i=teddy.astie@vates.tech;
	bh=xTxb6vk36SreQPSgyQdzBvLcCEpJSeagGkdZk4HqOW8=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=FhR9N9X6KL7Wfk5wGG1WGYjWr6H8hlaefkF+61WimS/Di7cYtm5n8NKDMlM7hEN6X
	 v7hzUjpffSvEiyg4NHGWlUYdCBxCHPZWcqopoy71psZ7r688Q68WccJNnT0lO/6HQs
	 lNISCn9fcV9OQQmRcfa/3TsGfJw3YkZKAXoGUVuHvIVowHPYZEiTp6iE0e7c0GEBnc
	 DHVkJnBNFy7tSbM2uGqG5okhX+DCo4eEM4LQrXLpucJka3VqNuTzfJG7vLq6vb0vtB
	 /8Hcc0MBfiRWrtwFQ5KZ4+N/MJY340/RgPypSgLTGGZ6kBlVIXh37xmaRKxKVDIDhR
	 KyiuVTREnh8Fg==
From: "Teddy Astie" <teddy.astie@vates.tech>
Subject: =?utf-8?Q?[XEN=20RFC=20PATCH=20v5=202/5]=20docs/designs:=20Add=20a=20design=20document=20for=20PV-IOMMU?=
X-Mailer: git-send-email 2.45.3
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1737476002887
To: xen-devel@lists.xenproject.org
Cc: "Teddy Astie" <teddy.astie@vates.tech>, "Andrew Cooper" <andrew.cooper3@citrix.com>, "Jan Beulich" <jbeulich@suse.com>, "Julien Grall" <julien@xen.org>, "Stefano Stabellini" <sstabellini@kernel.org>, "=?utf-8?Q?Marek=20Marczykowski-G=C3=B3recki?=" <marmarek@invisiblethingslab.com>
Message-Id: <34db7226a1abe8ac6f8dc0f61415e2783988ea45.1737470269.git.teddy.astie@vates.tech>
In-Reply-To: <cover.1737470269.git.teddy.astie@vates.tech>
References: <cover.1737470269.git.teddy.astie@vates.tech>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.ff9033a53f704e2c929778eda4f784eb?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250121:md
Date: Tue, 21 Jan 2025 16:13:23 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Some operating systems want to use IOMMU to implement various features (e.g
VFIO) or DMA protection.
This patch introduce a proposal for IOMMU paravirtualization for Dom0.

Signed-off-by Teddy Astie <teddy.astie@vates.tech>
---
Changed in V2:
* nit s/dettach/detach/

Changed in v4:
* updated for iommu_context locking changes
---
 docs/designs/pv-iommu.md | 116 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 116 insertions(+)
 create mode 100644 docs/designs/pv-iommu.md

diff --git a/docs/designs/pv-iommu.md b/docs/designs/pv-iommu.md
new file mode 100644
index 0000000000..7df9fa0b94
--- /dev/null
+++ b/docs/designs/pv-iommu.md
@@ -0,0 +1,116 @@
+# IOMMU paravirtualization for Dom0
+
+Status: Experimental
+
+# Background
+
+By default, Xen only uses the IOMMU for itself, either to make device adress
+space coherent with guest adress space (x86 HVM/PVH) or to prevent devices
+from doing DMA outside it's expected memory regions including the hypervisor
+(x86 PV).
+
+A limitation is that guests (especially privildged ones) may want to use
+IOMMU hardware in order to implement features such as DMA protection and
+VFIO [1] as IOMMU functionality is not available outside of the hypervisor
+currently.
+
+[1] VFIO - "Virtual Function I/O" - https://www.kernel.org/doc/html/latest/driver-api/vfio.html
+
+# Design
+
+The operating system may want to have access to various IOMMU features such as
+context management and DMA remapping. We can create a new hypercall that allows
+the guest to have access to a new paravirtualized IOMMU interface.
+
+This feature is only meant to be available for the Dom0, as DomU have some
+emulated devices that can't be managed on Xen side and are not hardware, we
+can't rely on the hardware IOMMU to enforce DMA remapping.
+
+This interface is exposed under the `iommu_op` hypercall.
+
+In addition, Xen domains are modified in order to allow existence of several
+IOMMU context including a default one that implement default behavior (e.g
+hardware assisted paging) and can't be modified by guest. DomU cannot have
+contexts, and therefore act as if they only have the default domain.
+
+Each IOMMU context within a Xen domain is identified using a domain-specific
+context number that is used in the Xen IOMMU subsystem and the hypercall
+interface.
+
+The number of IOMMU context a domain is specified by either the toolstack or
+the domain itself.
+
+# IOMMU operations
+
+## Initialize PV-IOMMU
+
+Initialize PV-IOMMU for the domain.
+It can only be called once.
+
+## Alloc context
+
+Create a new IOMMU context for the guest and return the context number to the
+guest.
+Fail if the IOMMU context limit of the guest is reached.
+
+A flag can be specified to create a identity mapping.
+
+## Free context
+
+Destroy a IOMMU context created previously.
+It is not possible to free the default context.
+
+Reattach context devices to default context if specified by the guest.
+
+Fail if there is a device in the context and reattach-to-default flag is not
+specified.
+
+## Reattach device
+
+Reattach a device to another IOMMU context (including the default one).
+The target IOMMU context number must be valid and the context allocated.
+
+The guest needs to specify a PCI SBDF of a device he has access to.
+
+## Map/unmap page
+
+Map/unmap a page on a context.
+The guest needs to specify a gfn and target dfn to map.
+
+Refuse to create the mapping if one already exist for the same dfn.
+
+## Lookup page
+
+Get the gfn mapped by a specific dfn.
+
+## Remote command
+
+Make a PV-IOMMU operation on behalf of another domain.
+Especially useful for implementing IOMMU emulation (e.g using QEMU)
+or initializing PV-IOMMU with enforced limits.
+
+# Implementation considerations
+
+## Hypercall batching
+
+In order to prevent unneeded hypercalls and IOMMU flushing, it is advisable to
+be able to batch some critical IOMMU operations (e.g map/unmap multiple pages).
+
+## Hardware without IOMMU support
+
+Operating system needs to be aware on PV-IOMMU capability, and whether it is
+able to make contexts. However, some operating system may critically fail in
+case they are able to make a new IOMMU context. Which is supposed to happen
+if no IOMMU hardware is available.
+
+The hypercall interface needs a interface to advertise the ability to create
+and manage IOMMU contexts including the amount of context the guest is able
+to use. Using these informations, the Dom0 may decide whether to use or not
+the PV-IOMMU interface.
+
+## Page pool for contexts
+
+In order to prevent unexpected starving on the hypervisor memory with a
+buggy Dom0. We can preallocate the pages the contexts will use and make
+map/unmap use these pages instead of allocating them dynamically.
+
-- 
2.45.3



Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 16:13:30 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 16:13:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875534.1286004 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taGsc-0002Zs-98; Tue, 21 Jan 2025 16:13:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875534.1286004; Tue, 21 Jan 2025 16:13:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taGsc-0002Zj-5i; Tue, 21 Jan 2025 16:13:30 +0000
Received: by outflank-mailman (input) for mailman id 875534;
 Tue, 21 Jan 2025 16:13:28 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Wtim=UN=bounce.vates.tech=bounce-md_30504962.678fc7a5.v1-57151dc962994d31b6ca681faeeeafde@srs-se1.protection.inumbo.net>)
 id 1taGsa-0001Ka-NM
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 16:13:28 +0000
Received: from mail187-43.suw11.mandrillapp.com
 (mail187-43.suw11.mandrillapp.com [198.2.187.43])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a4fa83da-d812-11ef-99a4-01e77a169b0f;
 Tue, 21 Jan 2025 17:13:26 +0100 (CET)
Received: from pmta09.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail187-43.suw11.mandrillapp.com (Mailchimp) with ESMTP id
 4Ycsh55dsZzLfH7tY
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 16:13:25 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 57151dc962994d31b6ca681faeeeafde; Tue, 21 Jan 2025 16:13:25 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a4fa83da-d812-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1737476005; x=1737746005;
	bh=p2FEphAG0RzRrA4z4pvhf20EVKbkOp01bHUz8SZBsrg=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=V0hDTJrIC0s5IXLDIuu25RiaHgbz68kzG4Za6qtZPMa66sIMtXJkBtxX366vJdpin
	 O8/3q+kEbfeS65a6aPKJC/nFF9otcXLDZsFy51YiXc1NFlNZw2F41tTzeimfFWXvW3
	 5dRxkxu1wLeMqz1nuRdE38zFEOOcKrimyFRbTwrhhPBQb03HSTsai6SFmA9L5i0qXe
	 tHdD0QoMz0/jCOHEKrF5VgdXhxTVZAsdvEPGtxAkVchigu41OTOk5iARnAxYn6qTMn
	 AdeUjVjXIbt2EwzZIW8asUcs51aHp5W3QtUjSnJuhiVZl46DQU45toq5WgFYDsjiw+
	 wsTxvHn8IBoVg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1737476005; x=1737736505; i=teddy.astie@vates.tech;
	bh=p2FEphAG0RzRrA4z4pvhf20EVKbkOp01bHUz8SZBsrg=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=FdvBhZQDlXojhhhujhTIc8mUvgobfYNtFQOa33r34txMAqWDPUq+wH6GQ4dFwmG62
	 37vNFCy0jBtKGB1k5WGZEvpc4HKeDf4nBs7FkUoj2TjQnBUp61cmKo0whR4lqRFjUi
	 94RF/bI3alifdGd6yj1bcE8PJCwWpo6i1Ndvi0gCQgYXY6wHTS8H1bWVa/wWvOBY57
	 GJLyZdARY0Lr+YBI2OnVkOJMGjX2I+2Omfe72ryiLpF9oNtv5dYULk6babjsU4umjO
	 HJSAwO+/ToJrpfmRAmukM8TH1+KipGUK3rdpwpvF/Oza+yRerxJxf/w4oPr5ZZtRjV
	 7adYHOjTWnDXQ==
From: "Teddy Astie" <teddy.astie@vates.tech>
Subject: =?utf-8?Q?[XEN=20RFC=20PATCH=20v5=203/5]=20xen/public:=20Introduce=20PV-IOMMU=20hypercall=20interface?=
X-Mailer: git-send-email 2.45.3
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1737476004649
To: xen-devel@lists.xenproject.org
Cc: "Teddy Astie" <teddy.astie@vates.tech>, "Andrew Cooper" <andrew.cooper3@citrix.com>, "Jan Beulich" <jbeulich@suse.com>, "Julien Grall" <julien@xen.org>, "Stefano Stabellini" <sstabellini@kernel.org>, "=?utf-8?Q?Marek=20Marczykowski-G=C3=B3recki?=" <marmarek@invisiblethingslab.com>
Message-Id: <29f3e87532573bfc4196083ab0291326adae5100.1737470269.git.teddy.astie@vates.tech>
In-Reply-To: <cover.1737470269.git.teddy.astie@vates.tech>
References: <cover.1737470269.git.teddy.astie@vates.tech>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.57151dc962994d31b6ca681faeeeafde?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250121:md
Date: Tue, 21 Jan 2025 16:13:25 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Introduce a new pv interface to manage the underlying IOMMU and manage contexts
and devices. This interface allows creation of new contexts from Dom0 and
addition of IOMMU mappings using guest PoV.

This interface doesn't allow creation of mapping to other domains.

Signed-off-by Teddy Astie <teddy.astie@vates.tech>
---
Changed in V2:
* cleanup some unneeded includes
* fix dangling devices in context on detach

Changed in V3:
* add unlocked _iommu_lookup_page
* iommu_check_context+iommu_get_context -> iommu_get_context and check for NULL
* prevent IOMMU operations on dying contexts

Changed in V4:
* changed context lock logic : iommu_get_context -> iommu_get_context+iommu_put_context
* added no-dma mode (see cover letter)
* use new initialization logic
---
 xen/common/Makefile           |   1 +
 xen/common/pv-iommu.c         | 539 ++++++++++++++++++++++++++++++++++
 xen/include/hypercall-defs.c  |   6 +
 xen/include/public/pv-iommu.h | 343 ++++++++++++++++++++++
 xen/include/public/xen.h      |   1 +
 5 files changed, 890 insertions(+)
 create mode 100644 xen/common/pv-iommu.c
 create mode 100644 xen/include/public/pv-iommu.h

diff --git a/xen/common/Makefile b/xen/common/Makefile
index f12a474d40..52ada89888 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -58,6 +58,7 @@ obj-y += wait.o
 obj-bin-y += warning.init.o
 obj-$(CONFIG_XENOPROF) += xenoprof.o
 obj-y += xmalloc_tlsf.o
+obj-y += pv-iommu.o
 
 obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma lzo unlzo unlz4 unzstd earlycpio,$(n).init.o)
 
diff --git a/xen/common/pv-iommu.c b/xen/common/pv-iommu.c
new file mode 100644
index 0000000000..9c7d04b4c7
--- /dev/null
+++ b/xen/common/pv-iommu.c
@@ -0,0 +1,539 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * xen/common/pv_iommu.c
+ *
+ * PV-IOMMU hypercall interface.
+ */
+
+#include <xen/errno.h>
+#include <xen/mm.h>
+#include <xen/lib.h>
+#include <xen/iommu.h>
+#include <xen/sched.h>
+#include <xen/iocap.h>
+#include <xen/mm-frame.h>
+#include <xen/pci.h>
+#include <xen/guest_access.h>
+#include <asm/p2m.h>
+#include <asm/event.h>
+#include <asm/mm.h>
+#include <asm/iommu.h>
+#include <public/pv-iommu.h>
+
+#define PVIOMMU_PREFIX "[PV-IOMMU] "
+
+static int get_paged_frame(struct domain *d, gfn_t gfn, mfn_t *mfn,
+                           struct page_info **page, bool readonly)
+{
+    int ret = 0;
+    p2m_type_t p2mt = p2m_invalid;
+
+    #ifdef CONFIG_X86
+    p2m_query_t query = P2M_ALLOC;
+
+    if ( !readonly )
+        query |= P2M_UNSHARE;
+
+    *mfn = get_gfn_type(d, gfn_x(gfn), &p2mt, query);
+    #else
+    *mfn = p2m_lookup(d, gfn, &p2mt);
+    #endif
+
+    if ( mfn_eq(*mfn, INVALID_MFN) )
+    {
+        /* No mapping ? */
+        printk(XENLOG_G_WARNING PVIOMMU_PREFIX
+               "Trying to map to non-backed page frame (gfn=%"PRI_gfn
+               " p2mt=%d d%d)\n", gfn_x(gfn), p2mt, d->domain_id);
+
+        ret = -ENOENT;
+    }
+    else if ( p2m_is_any_ram(p2mt) && mfn_valid(*mfn) )
+    {
+        *page = get_page_from_mfn(*mfn, d);
+        ret = 0;
+    }
+    else if ( p2m_is_mmio(p2mt) ||
+              iomem_access_permitted(d, mfn_x(*mfn),mfn_x(*mfn)) )
+    {
+        *page = NULL;
+        ret = 0;
+    }
+    else
+    {
+        printk(XENLOG_G_WARNING PVIOMMU_PREFIX
+               "Unexpected p2mt %d (d%d gfn=%"PRI_gfn" mfn=%"PRI_mfn")\n",
+               p2mt, d->domain_id, gfn_x(gfn), mfn_x(*mfn));
+
+        ret = -EPERM;
+    }
+
+    put_gfn(d, gfn_x(gfn));
+    return ret;
+}
+
+static bool can_use_iommu_check(struct domain *d)
+{
+    if ( !is_iommu_enabled(d) )
+    {
+        printk(XENLOG_G_WARNING PVIOMMU_PREFIX
+               "IOMMU disabled for this domain\n");
+        return false;
+    }
+
+    if ( !dom_iommu(d)->allow_pv_iommu )
+    {
+        printk(XENLOG_G_WARNING PVIOMMU_PREFIX
+               "PV-IOMMU disabled for this domain\n");
+        return false;
+    }
+
+    return true;
+}
+
+static long capabilities_op(struct pv_iommu_capabilities *cap, struct domain *d)
+{
+    cap->max_ctx_no = d->iommu.other_contexts.count;
+    cap->max_iova_addr = iommu_get_max_iova(d);
+
+    cap->max_pasid = 0; /* TODO */
+    cap->cap_flags = 0;
+
+    if ( !dom_iommu(d)->no_dma )
+        cap->cap_flags |= IOMMUCAP_default_identity;
+
+    cap->pgsize_mask = PAGE_SIZE_4K;
+
+    return 0;
+}
+
+static long init_op(struct pv_iommu_init *init, struct domain *d)
+{
+    if (init->max_ctx_no == UINT32_MAX)
+        return -E2BIG;
+
+    return iommu_domain_pviommu_init(d, init->max_ctx_no + 1, init->arena_order);
+}
+
+static long alloc_context_op(struct pv_iommu_alloc *alloc, struct domain *d)
+{
+    u16 ctx_no = 0;
+    int status = 0;
+
+    status = iommu_context_alloc(d, &ctx_no, 0);
+
+    if ( status )
+        return status;
+
+    printk(XENLOG_G_INFO PVIOMMU_PREFIX
+           "Created IOMMU context %hu in d%d\n", ctx_no, d->domain_id);
+
+    alloc->ctx_no = ctx_no;
+    return 0;
+}
+
+static long free_context_op(struct pv_iommu_free *free, struct domain *d)
+{
+    int flags = IOMMU_TEARDOWN_PREEMPT;
+
+    if ( !free->ctx_no )
+        return -EINVAL;
+
+    if ( free->free_flags & IOMMU_FREE_reattach_default )
+        flags |= IOMMU_TEARDOWN_REATTACH_DEFAULT;
+
+    return iommu_context_free(d, free->ctx_no, flags);
+}
+
+static long reattach_device_op(struct pv_iommu_reattach_device *reattach,
+                               struct domain *d)
+{
+    int ret;
+    device_t *pdev;
+    struct physdev_pci_device dev = reattach->dev;
+
+    pcidevs_lock();
+    pdev = pci_get_pdev(d, PCI_SBDF(dev.seg, dev.bus, dev.devfn));
+
+    if ( !pdev )
+    {
+        pcidevs_unlock();
+        return -ENOENT;
+    }
+
+    ret = iommu_reattach_context(d, d, pdev, reattach->ctx_no);
+
+    pcidevs_unlock();
+    return ret;
+}
+
+static long map_pages_op(struct pv_iommu_map_pages *map, struct domain *d)
+{
+    struct iommu_context *ctx;
+    int ret = 0, flush_ret;
+    struct page_info *page = NULL;
+    mfn_t mfn, mfn_lookup;
+    unsigned int flags = 0, flush_flags = 0;
+    size_t i = 0;
+    dfn_t dfn0 = _dfn(map->dfn); /* original map->dfn */
+
+    if ( !map->ctx_no || !(ctx = iommu_get_context(d, map->ctx_no)) )
+        return -EINVAL;
+
+    if ( map->map_flags & IOMMU_MAP_readable )
+        flags |= IOMMUF_readable;
+
+    if ( map->map_flags & IOMMU_MAP_writeable )
+        flags |= IOMMUF_writable;
+
+    for (i = 0; i < map->nr_pages; i++)
+    {
+        gfn_t gfn = _gfn(map->gfn + i);
+        dfn_t dfn = _dfn(map->dfn + i);
+
+#ifdef CONFIG_X86
+        if ( iommu_identity_map_check(d, ctx, _mfn(map->dfn)) )
+        {
+            ret = -EADDRNOTAVAIL;
+            break;
+        }
+#endif
+
+        ret = get_paged_frame(d, gfn, &mfn, &page, 0);
+
+        if ( ret )
+            break;
+
+        /* Check for conflict with existing mappings */
+        if ( !iommu_lookup_page(d, dfn, &mfn_lookup, &flags, map->ctx_no) )
+        {
+            if ( page )
+                put_page(page);
+
+            ret = -EADDRINUSE;
+            break;
+        }
+
+        ret = iommu_map(d, dfn, mfn, 1, flags, &flush_flags, map->ctx_no);
+
+        if ( ret )
+        {
+            if ( page )
+                put_page(page);
+
+            break;
+        }
+
+        map->mapped++;
+
+        if ( (i & 0xff) && hypercall_preempt_check() )
+        {
+            i++;
+
+            map->gfn += i;
+            map->dfn += i;
+            map->nr_pages -= i;
+
+            ret = -ERESTART;
+            break;
+        }
+    }
+
+    flush_ret = iommu_iotlb_flush(d, dfn0, i, flush_flags, map->ctx_no);
+
+    iommu_put_context(ctx);
+
+    if ( flush_ret )
+        printk(XENLOG_G_WARNING PVIOMMU_PREFIX
+               "Flush operation failed for d%dc%d (%d)\n", d->domain_id,
+               ctx->id, flush_ret);
+
+    return ret;
+}
+
+static long unmap_pages_op(struct pv_iommu_unmap_pages *unmap, struct domain *d)
+{
+    struct iommu_context *ctx;
+    mfn_t mfn;
+    int ret = 0, flush_ret;
+    unsigned int flags, flush_flags = 0;
+    size_t i = 0;
+    dfn_t dfn0 = _dfn(unmap->dfn); /* original unmap->dfn */
+
+    if ( !unmap->ctx_no || !(ctx = iommu_get_context(d, unmap->ctx_no)) )
+        return -EINVAL;
+
+    for (i = 0; i < unmap->nr_pages; i++)
+    {
+        dfn_t dfn = _dfn(unmap->dfn + i);
+
+#ifdef CONFIG_X86
+        if ( iommu_identity_map_check(d, ctx, _mfn(unmap->dfn)) )
+        {
+            ret = -EADDRNOTAVAIL;
+            break;
+        }
+#endif
+
+        /* Check if there is a valid mapping for this domain */
+        if ( iommu_lookup_page(d, dfn, &mfn, &flags, unmap->ctx_no) ) {
+            ret = -ENOENT;
+            break;
+        }
+
+        ret = iommu_unmap(d, dfn, 1, 0, &flush_flags, unmap->ctx_no);
+
+        if ( ret )
+            break;
+
+        unmap->unmapped++;
+
+        /* Decrement reference counter (if needed) */
+        if ( mfn_valid(mfn) )
+            put_page(mfn_to_page(mfn));
+
+        if ( (i & 0xff) && hypercall_preempt_check() )
+        {
+            i++;
+
+            unmap->dfn += i;
+            unmap->nr_pages -= i;
+
+            ret = -ERESTART;
+            break;
+        }
+    }
+
+    flush_ret = iommu_iotlb_flush(d, dfn0, i, flush_flags, unmap->ctx_no);
+
+    iommu_put_context(ctx);
+
+    if ( flush_ret )
+        printk(XENLOG_WARNING PVIOMMU_PREFIX
+               "Flush operation failed for d%dc%d (%d)\n", d->domain_id,
+               ctx->id, flush_ret);
+
+    return ret;
+}
+
+static long do_iommu_subop(int subop, XEN_GUEST_HANDLE_PARAM(void) arg,
+                           struct domain *d, bool remote);
+
+static long remote_cmd_op(struct pv_iommu_remote_cmd *remote_cmd,
+                          struct domain *current_domain)
+{
+    long ret = 0;
+    struct domain *d;
+
+    /* TODO: use a better permission logic */
+    if ( !is_hardware_domain(current_domain) )
+        return -EPERM;
+
+    d = get_domain_by_id(remote_cmd->domid);
+
+    if ( !d )
+        return -ENOENT;
+
+    ret = do_iommu_subop(remote_cmd->subop, remote_cmd->arg, d, true);
+
+    put_domain(d);
+
+    return ret;
+}
+
+static long do_iommu_subop(int subop, XEN_GUEST_HANDLE_PARAM(void) arg,
+                           struct domain *d, bool remote)
+{
+    long ret = 0;
+
+    switch ( subop )
+    {
+        case IOMMU_noop:
+            break;
+
+        case IOMMU_query_capabilities:
+        {
+            struct pv_iommu_capabilities cap;
+
+            ret = capabilities_op(&cap, d);
+
+            if ( unlikely(copy_to_guest(arg, &cap, 1)) )
+                ret = -EFAULT;
+
+            break;
+        }
+
+        case IOMMU_init:
+        {
+            struct pv_iommu_init init;
+
+            if ( unlikely(copy_from_guest(&init, arg, 1)) )
+            {
+                ret = -EFAULT;
+                break;
+            }
+
+            ret = init_op(&init, d);
+        }
+
+        case IOMMU_alloc_context:
+        {
+            struct pv_iommu_alloc alloc;
+
+            if ( unlikely(copy_from_guest(&alloc, arg, 1)) )
+            {
+                ret = -EFAULT;
+                break;
+            }
+
+            ret = alloc_context_op(&alloc, d);
+
+            if ( unlikely(copy_to_guest(arg, &alloc, 1)) )
+                ret = -EFAULT;
+
+            break;
+        }
+
+        case IOMMU_free_context:
+        {
+            struct pv_iommu_free free;
+
+            if ( unlikely(copy_from_guest(&free, arg, 1)) )
+            {
+                ret = -EFAULT;
+                break;
+            }
+
+            ret = free_context_op(&free, d);
+            break;
+        }
+
+        case IOMMU_reattach_device:
+        {
+            struct pv_iommu_reattach_device reattach;
+
+            if ( unlikely(copy_from_guest(&reattach, arg, 1)) )
+            {
+                ret = -EFAULT;
+                break;
+            }
+
+            ret = reattach_device_op(&reattach, d);
+            break;
+        }
+
+        case IOMMU_map_pages:
+        {
+            struct pv_iommu_map_pages map;
+
+            if ( unlikely(copy_from_guest(&map, arg, 1)) )
+            {
+                ret = -EFAULT;
+                break;
+            }
+
+            ret = map_pages_op(&map, d);
+
+            if ( unlikely(copy_to_guest(arg, &map, 1)) )
+                ret = -EFAULT;
+
+            break;
+        }
+
+        case IOMMU_unmap_pages:
+        {
+            struct pv_iommu_unmap_pages unmap;
+
+            if ( unlikely(copy_from_guest(&unmap, arg, 1)) )
+            {
+                ret = -EFAULT;
+                break;
+            }
+
+            ret = unmap_pages_op(&unmap, d);
+
+            if ( unlikely(copy_to_guest(arg, &unmap, 1)) )
+                ret = -EFAULT;
+
+            break;
+        }
+
+        case IOMMU_remote_cmd:
+        {
+            struct pv_iommu_remote_cmd remote_cmd;
+
+            if ( remote )
+            {
+                /* Prevent remote_cmd from being called recursively */
+                ret = -EINVAL;
+                break;
+            }
+
+            if ( unlikely(copy_from_guest(&remote_cmd, arg, 1)) )
+            {
+                ret = -EFAULT;
+                break;
+            }
+
+            ret = remote_cmd_op(&remote_cmd, d);
+            break;
+        }
+
+        /*
+         * TODO
+         */
+        case IOMMU_alloc_nested:
+        {
+            ret = -EOPNOTSUPP;
+            break;
+        }
+
+        case IOMMU_flush_nested:
+        {
+            ret = -EOPNOTSUPP;
+            break;
+        }
+
+        case IOMMU_attach_pasid:
+        {
+            ret = -EOPNOTSUPP;
+            break;
+        }
+
+        case IOMMU_detach_pasid:
+        {
+            ret = -EOPNOTSUPP;
+            break;
+        }
+
+        default:
+            return -EOPNOTSUPP;
+    }
+
+    return ret;
+}
+
+long do_iommu_op(unsigned int subop, XEN_GUEST_HANDLE_PARAM(void) arg)
+{
+    long ret = 0;
+
+    if ( !can_use_iommu_check(current->domain) )
+        return -ENODEV;
+
+    ret = do_iommu_subop(subop, arg, current->domain, false);
+
+    if ( ret == -ERESTART )
+        return hypercall_create_continuation(__HYPERVISOR_iommu_op, "ih", subop, arg);
+
+    return ret;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/hypercall-defs.c b/xen/include/hypercall-defs.c
index 47c093acc8..59d7c02f55 100644
--- a/xen/include/hypercall-defs.c
+++ b/xen/include/hypercall-defs.c
@@ -209,6 +209,9 @@ hypfs_op(unsigned int cmd, const char *arg1, unsigned long arg2, void *arg3, uns
 #ifdef CONFIG_X86
 xenpmu_op(unsigned int op, xen_pmu_params_t *arg)
 #endif
+#ifdef CONFIG_HAS_PASSTHROUGH
+iommu_op(unsigned int subop, void *arg)
+#endif
 
 #ifdef CONFIG_PV
 caller: pv64
@@ -295,5 +298,8 @@ mca                                do       do       -        -        -
 #ifndef CONFIG_PV_SHIM_EXCLUSIVE
 paging_domctl_cont                 do       do       do       do       -
 #endif
+#ifdef CONFIG_HAS_PASSTHROUGH
+iommu_op                           do       do       do       do       -
+#endif
 
 #endif /* !CPPCHECK */
diff --git a/xen/include/public/pv-iommu.h b/xen/include/public/pv-iommu.h
new file mode 100644
index 0000000000..6f50aea4b7
--- /dev/null
+++ b/xen/include/public/pv-iommu.h
@@ -0,0 +1,343 @@
+/* SPDX-License-Identifier: MIT */
+/**
+ * pv-iommu.h
+ *
+ * Paravirtualized IOMMU driver interface.
+ *
+ * Copyright (c) 2024 Teddy Astie <teddy.astie@vates.tech>
+ */
+
+#ifndef __XEN_PUBLIC_PV_IOMMU_H__
+#define __XEN_PUBLIC_PV_IOMMU_H__
+
+#include "xen.h"
+#include "physdev.h"
+
+#ifndef uint64_aligned_t
+#define uint64_aligned_t uint64_t
+#endif
+
+#define IOMMU_DEFAULT_CONTEXT (0)
+
+enum pv_iommu_cmd {
+    /* Basic cmd */
+    IOMMU_noop = 0,
+    IOMMU_query_capabilities = 1,
+    IOMMU_init = 2,
+    IOMMU_alloc_context = 3,
+    IOMMU_free_context = 4,
+    IOMMU_reattach_device = 5,
+    IOMMU_map_pages = 6,
+    IOMMU_unmap_pages = 7,
+    IOMMU_remote_cmd = 8,
+
+    /* Extended cmd */
+    IOMMU_alloc_nested = 9,      /* if IOMMUCAP_nested */
+    IOMMU_flush_nested = 10,     /* if IOMMUCAP_nested */
+    IOMMU_attach_pasid = 11,     /* if IOMMUCAP_pasid */
+    IOMMU_detach_pasid = 12,     /* if IOMMUCAP_pasid */
+};
+
+/**
+ * If set, default context allow DMA to domain memory.
+ * If cleared, default context blocks all DMA to domain memory.
+ */
+#define IOMMUCAP_default_identity  (1U << 0)
+
+/**
+ * IOMMU_MAP_cache support.
+ */
+#define IOMMUCAP_cache     (1U << 1)
+
+/**
+ * If set, IOMMU_alloc_nested and IOMMU_flush_nested are supported.
+ */
+#define IOMMUCAP_nested    (1U << 2)
+
+/**
+ * If set, IOMMU_attach_pasid and IOMMU_detach_pasid are supported and
+ * a device PASID can be specified in reattach_context.
+ */
+#define IOMMUCAP_pasid     (1U << 3)
+
+/**
+ * If set, IOMMU_ALLOC_identity is supported in pv_iommu_alloc.
+ */
+#define IOMMUCAP_identity  (1U << 4)
+
+/**
+ * IOMMU_query_capabilities
+ * Query PV-IOMMU capabilities for this domain.
+ */
+struct pv_iommu_capabilities {
+    /*
+     * OUT: Maximum device address (iova) that the guest can use for mappings.
+     */
+    uint64_aligned_t max_iova_addr;
+
+    /* OUT: IOMMU capabilities flags */
+    uint32_t cap_flags;
+
+    /* OUT: Mask of all supported page sizes. */
+    uint32_t pgsize_mask;
+
+    /* OUT: Maximum pasid (if IOMMUCAP_pasid) */
+    uint32_t max_pasid;
+
+    /* OUT: Maximum number of IOMMU context this domain can use. */
+    uint16_t max_ctx_no;
+
+    uint16_t pad0;
+};
+typedef struct pv_iommu_capabilities pv_iommu_capabilities_t;
+DEFINE_XEN_GUEST_HANDLE(pv_iommu_capabilities_t);
+
+/**
+ * IOMMU_init
+ * Initialize PV-IOMMU for this domain.
+ *
+ * Fails with -EACCESS if PV-IOMMU is already initialized.
+ */
+struct pv_iommu_init {
+    /* IN: Maximum number of IOMMU context this domain can use. */
+    uint32_t max_ctx_no;
+
+    /* IN: Arena size in pages (in power of two) */
+    uint32_t arena_order;
+};
+typedef struct pv_iommu_init pv_iommu_init_t;
+DEFINE_XEN_GUEST_HANDLE(pv_iommu_init_t);
+
+/**
+ * Create a 1:1 identity mapped context to domain memory
+ * (needs IOMMUCAP_identity).
+ */
+#define IOMMU_ALLOC_identity (1 << 0)
+
+/**
+ * IOMMU_alloc_context
+ * Allocate an IOMMU context.
+ * Fails with -ENOSPC if no context number is available.
+ */
+struct pv_iommu_alloc {
+    /* OUT: allocated IOMMU context number */
+    uint16_t ctx_no;
+
+    /* IN: allocation flags */
+    uint32_t alloc_flags;
+};
+typedef struct pv_iommu_alloc pv_iommu_alloc_t;
+DEFINE_XEN_GUEST_HANDLE(pv_iommu_alloc_t);
+
+/**
+ * Move all devices to default context before freeing the context.
+ */
+#define IOMMU_FREE_reattach_default (1 << 0)
+
+/**
+ * IOMMU_free_context
+ * Destroy a IOMMU context.
+ *
+ * If IOMMU_FREE_reattach_default is specified, move all context devices to
+ * default context before destroying this context.
+ *
+ * If there are devices in the context and IOMMU_FREE_reattach_default is not
+ * specified, fail with -EBUSY.
+ *
+ * The default context can't be destroyed.
+ */
+struct pv_iommu_free {
+    /* IN: IOMMU context number to free */
+    uint16_t ctx_no;
+
+    /* IN: Free operation specific flags */
+    uint32_t free_flags;
+};
+typedef struct pv_iommu_free pv_iommu_free_t;
+DEFINE_XEN_GUEST_HANDLE(pv_iommu_free_t);
+
+/* Device has read access */
+#define IOMMU_MAP_readable (1 << 0)
+
+/* Device has write access */
+#define IOMMU_MAP_writeable (1 << 1)
+
+/* Enforce DMA coherency */
+#define IOMMU_MAP_cache (1 << 2)
+
+/**
+ * IOMMU_map_pages
+ * Map pages on a IOMMU context.
+ *
+ * pgsize must be supported by pgsize_mask.
+ * Fails with -EINVAL if mapping on top of another mapping.
+ * Report actually mapped page count in mapped field (regardless of failure).
+ */
+struct pv_iommu_map_pages {
+    /* IN: IOMMU context number */
+    uint16_t ctx_no;
+
+    /* IN: Guest frame number */
+    uint64_aligned_t gfn;
+
+    /* IN: Device frame number */
+    uint64_aligned_t dfn;
+
+    /* IN: Map flags */
+    uint32_t map_flags;
+
+    /* IN: Size of pages to map */
+    uint32_t pgsize;
+
+    /* IN: Number of pages to map */
+    uint32_t nr_pages;
+
+    /* OUT: Number of pages actually mapped */
+    uint32_t mapped;
+};
+typedef struct pv_iommu_map_pages pv_iommu_map_pages_t;
+DEFINE_XEN_GUEST_HANDLE(pv_iommu_map_pages_t);
+
+/**
+ * IOMMU_unmap_pages
+ * Unmap pages on a IOMMU context.
+ *
+ * pgsize must be supported by pgsize_mask.
+ * Report actually unmapped page count in mapped field (regardless of failure).
+ * Fails with -ENOENT when attempting to unmap a page without any mapping
+ */
+struct pv_iommu_unmap_pages {
+    /* IN: IOMMU context number */
+    uint16_t ctx_no;
+
+    /* IN: Device frame number */
+    uint64_aligned_t dfn;
+
+    /* IN: Size of pages to unmap */
+    uint32_t pgsize;
+
+    /* IN: Number of pages to unmap */
+    uint32_t nr_pages;
+
+    /* OUT: Number of pages actually unmapped */
+    uint32_t unmapped;
+};
+typedef struct pv_iommu_unmap_pages pv_iommu_unmap_pages_t;
+DEFINE_XEN_GUEST_HANDLE(pv_iommu_unmap_pages_t);
+
+/**
+ * IOMMU_reattach_device
+ * Reattach a device to another IOMMU context.
+ * Fails with -ENODEV if no such device exist.
+ */
+struct pv_iommu_reattach_device {
+    /* IN: Target IOMMU context number */
+    uint16_t ctx_no;
+
+    /* IN: Physical device to move */
+    struct physdev_pci_device dev;
+
+    /* IN: PASID of the device (if IOMMUCAP_pasid) */
+    uint32_t pasid;
+};
+typedef struct pv_iommu_reattach_device pv_iommu_reattach_device_t;
+DEFINE_XEN_GUEST_HANDLE(pv_iommu_reattach_device_t);
+
+
+/**
+ * IOMMU_remote_cmd
+ * Do a PV-IOMMU operation on another domain.
+ * Current domain needs to be allowed to act on the target domain, otherwise
+ * fails with -EPERM.
+ */
+struct pv_iommu_remote_cmd {
+    /* IN: Target domain to do the subop on */
+    uint16_t domid;
+
+    /* IN: Command to do on target domain. */
+    uint16_t subop;
+
+    /* INOUT: Command argument from current domain memory */
+    XEN_GUEST_HANDLE(void) arg;
+};
+typedef struct pv_iommu_remote_cmd pv_iommu_remote_cmd_t;
+DEFINE_XEN_GUEST_HANDLE(pv_iommu_remote_cmd_t);
+
+/**
+ * IOMMU_alloc_nested
+ * Create a nested IOMMU context (needs IOMMUCAP_nested).
+ *
+ * This context uses a platform-specific page table from domain address space
+ * specified in pgtable_gfn and use it for nested translations.
+ *
+ * Explicit flushes needs to be submited with IOMMU_flush_nested on
+ * modification of the nested pagetable to ensure coherency between IOTLB and
+ * nested page table.
+ *
+ * This context can be destroyed using IOMMU_free_context.
+ * This context cannot be modified using map_pages, unmap_pages.
+ */
+struct pv_iommu_alloc_nested {
+    /* OUT: allocated IOMMU context number */
+    uint16_t ctx_no;
+
+    /* IN: guest frame number of the nested page table */
+    uint64_aligned_t pgtable_gfn;
+
+    /* IN: nested mode flags */
+    uint64_aligned_t nested_flags;
+};
+typedef struct pv_iommu_alloc_nested pv_iommu_alloc_nested_t;
+DEFINE_XEN_GUEST_HANDLE(pv_iommu_alloc_nested_t);
+
+/**
+ * IOMMU_flush_nested (needs IOMMUCAP_nested)
+ * Flush the IOTLB for nested translation.
+ */
+struct pv_iommu_flush_nested {
+    /* TODO */
+};
+typedef struct pv_iommu_flush_nested pv_iommu_flush_nested_t;
+DEFINE_XEN_GUEST_HANDLE(pv_iommu_flush_nested_t);
+
+/**
+ * IOMMU_attach_pasid (needs IOMMUCAP_pasid)
+ * Attach a new device-with-pasid to a IOMMU context.
+ * If a matching device-with-pasid already exists (globally),
+ * fail with -EEXIST.
+ * If pasid is 0, fails with -EINVAL.
+ * If physical device doesn't exist in domain, fail with -ENOENT.
+ */
+struct pv_iommu_attach_pasid {
+    /* IN: IOMMU context to add the device-with-pasid in */
+    uint16_t ctx_no;
+
+    /* IN: Physical device */
+    struct physdev_pci_device dev;
+
+    /* IN: pasid of the device to attach */
+    uint32_t pasid;
+};
+typedef struct pv_iommu_attach_pasid pv_iommu_attach_pasid_t;
+DEFINE_XEN_GUEST_HANDLE(pv_iommu_attach_pasid_t);
+
+/**
+ * IOMMU_detach_pasid (needs IOMMUCAP_pasid)
+ * detach a device-with-pasid.
+ * If the device-with-pasid doesn't exist or belong to the domain,
+ * fail with -ENOENT.
+ * If pasid is 0, fails with -EINVAL.
+ */
+struct pv_iommu_detach_pasid {
+    /* IN: Physical device */
+    struct physdev_pci_device dev;
+
+    /* pasid of the device to detach */
+    uint32_t pasid;
+};
+typedef struct pv_iommu_detach_pasid pv_iommu_detach_pasid_t;
+DEFINE_XEN_GUEST_HANDLE(pv_iommu_detach_pasid_t);
+
+/* long do_iommu_op(int subop, XEN_GUEST_HANDLE_PARAM(void) arg) */
+
+#endif
\ No newline at end of file
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index b47d48d0e2..28ab815ebc 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -118,6 +118,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
 #define __HYPERVISOR_xenpmu_op            40
 #define __HYPERVISOR_dm_op                41
 #define __HYPERVISOR_hypfs_op             42
+#define __HYPERVISOR_iommu_op             43
 
 /* Architecture-specific hypercall definitions. */
 #define __HYPERVISOR_arch_0               48
-- 
2.45.3



Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 16:13:32 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 16:13:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875535.1286015 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taGse-0002ri-JD; Tue, 21 Jan 2025 16:13:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875535.1286015; Tue, 21 Jan 2025 16:13:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taGse-0002rX-DV; Tue, 21 Jan 2025 16:13:32 +0000
Received: by outflank-mailman (input) for mailman id 875535;
 Tue, 21 Jan 2025 16:13:32 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=ZsVy=UN=bounce.vates.tech=bounce-md_30504962.678fc7a8.v1-da59f0c36c6e4d75a19f323da7dd1803@srs-se1.protection.inumbo.net>)
 id 1taGsd-0001Ka-KJ
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 16:13:31 +0000
Received: from mail187-43.suw11.mandrillapp.com
 (mail187-43.suw11.mandrillapp.com [198.2.187.43])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a6d56301-d812-11ef-99a4-01e77a169b0f;
 Tue, 21 Jan 2025 17:13:29 +0100 (CET)
Received: from pmta09.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail187-43.suw11.mandrillapp.com (Mailchimp) with ESMTP id
 4Ycsh904NczLfH7tZ
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 16:13:29 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 da59f0c36c6e4d75a19f323da7dd1803; Tue, 21 Jan 2025 16:13:28 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a6d56301-d812-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1737476009; x=1737746009;
	bh=DI5VKSbscTWnrZHNYJyhtqDMfI6IQMQSgrexg8QuZ0s=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=tytfObwyft0hImWnKXZq6v0iGkPPKC4qHD2tGfx//B82TUqXsEjBXGbay9PChiXIY
	 0HRZly6ywFvlAfZyRiCog5al59QDqxowy4xcmZrpogmaGvL3zc62lyj+QJGFtc4hpm
	 VJhvnxKGaXlmZjMYfBLJpQu74KGLKhqvmzT/SmnCECVsF9jS/rsPi3FSyIyFMKKRxy
	 MFsrBw+rvL8En66B9cT5bgyCdqvwcsKja9zLaD6etr6vHP+LS3XUtO1tLjvxhtl3AY
	 dbdXO1Y0/ryDRtKgDwna5959fUjvqRLIzDH1fG1TvKdKH4kjreLVhdVTCHKBntHX0+
	 iPPK3gaWc4BiA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1737476009; x=1737736509; i=teddy.astie@vates.tech;
	bh=DI5VKSbscTWnrZHNYJyhtqDMfI6IQMQSgrexg8QuZ0s=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=VcuoUMZr2EwL6adAdxB3YXHtVIQF1geC7KI1aXkqMfNIeM79bG91O6eGZgE/6S3LS
	 KX0GbW6wbQkHU1/icpMRHkwThWZmEXULdp2d7rvYABfGj94T4v8SizPrde5bLciWWw
	 +HllecV6/ouQoaieTI8sQDqvndKa2CuhKArlzO1z11m1jYyxnl2NLNtipPpIfFnJvw
	 2GR5YADnWcQR+GEqDingtyULU/xWr7SGt64nW4g7MGqWg6JCuhdqbgCk4Oe1tJmJPy
	 Y/GgM1MuY1WHx8u/qPa/qGwYVMQrDmEImGv5s2hMEyuxoTwGQ0CcRgWvkUjSOtv2sF
	 SLp9/S82kb6UA==
From: "Teddy Astie" <teddy.astie@vates.tech>
Subject: =?utf-8?Q?[XEN=20RFC=20PATCH=20v5=204/5]=20IOMMU:=20Introduce=20redesigned=20IOMMU=20subsystem?=
X-Mailer: git-send-email 2.45.3
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1737476006465
To: xen-devel@lists.xenproject.org
Cc: "Teddy Astie" <teddy.astie@vates.tech>, "Jan Beulich" <jbeulich@suse.com>, "Andrew Cooper" <andrew.cooper3@citrix.com>, "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>, "Julien Grall" <julien@xen.org>, "Stefano Stabellini" <sstabellini@kernel.org>, "Lukasz Hawrylko" <lukasz@hawrylko.pl>, "Daniel P. Smith" <dpsmith@apertussolutions.com>, "=?utf-8?Q?Mateusz=20M=C3=B3wka?=" <mateusz.mowka@intel.com>, "=?utf-8?Q?Marek=20Marczykowski-G=C3=B3recki?=" <marmarek@invisiblethingslab.com>
Message-Id: <e80bf868a009425c03ce4589bf8af09fb147a6e3.1737470269.git.teddy.astie@vates.tech>
In-Reply-To: <cover.1737470269.git.teddy.astie@vates.tech>
References: <cover.1737470269.git.teddy.astie@vates.tech>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.da59f0c36c6e4d75a19f323da7dd1803?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250121:md
Date: Tue, 21 Jan 2025 16:13:28 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Based on docs/designs/iommu-contexts.md, implement the redesigned IOMMU subsystem.

Signed-off-by Teddy Astie <teddy.astie@vates.tech>

---
Changed in V2:
* cleanup some unneeded includes
* s/dettach/detach/
* don't dump IOMMU context of non-iommu domains (fix crash with DomUs)

Changed in v4:
* add "no-dma" support
* use new locking logic

Changed in v5:
* rewrote parts of PCI passthrough logic (pci.c)
* reworked quarantine logic (mostly fixes PCI Passthrough)
* make iotlb_flush_all context-specific
* various bug fixes related to iommu initialization with DomUs
  (e.g flags being wrongly defined)
---
 xen/arch/x86/domain.c                |   2 +-
 xen/arch/x86/mm/p2m-ept.c            |   2 +-
 xen/arch/x86/pv/dom0_build.c         |   6 +-
 xen/arch/x86/tboot.c                 |   4 +-
 xen/common/memory.c                  |   4 +-
 xen/drivers/passthrough/Makefile     |   3 +
 xen/drivers/passthrough/context.c    | 740 +++++++++++++++++++++++++++
 xen/drivers/passthrough/iommu.c      | 431 ++++++----------
 xen/drivers/passthrough/pci.c        | 379 +++++---------
 xen/drivers/passthrough/quarantine.c |  49 ++
 xen/include/xen/iommu.h              | 119 ++++-
 xen/include/xen/pci.h                |   3 +
 12 files changed, 1189 insertions(+), 553 deletions(-)
 create mode 100644 xen/drivers/passthrough/context.c
 create mode 100644 xen/drivers/passthrough/quarantine.c

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index ccadfe0c9e..1dd2453d71 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -2405,7 +2405,7 @@ int domain_relinquish_resources(struct domain *d)
 
     PROGRESS(iommu_pagetables):
 
-        ret = iommu_free_pgtables(d);
+        ret = iommu_free_pgtables(d, iommu_default_context(d));
         if ( ret )
             return ret;
 
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 469e27ee93..80026a9cb9 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -975,7 +975,7 @@ out:
             rc = iommu_iotlb_flush(d, _dfn(gfn), 1ul << order,
                                    (iommu_flags ? IOMMU_FLUSHF_added : 0) |
                                    (vtd_pte_present ? IOMMU_FLUSHF_modified
-                                                    : 0));
+                                                    : 0), 0);
         else if ( need_iommu_pt_sync(d) )
             rc = iommu_flags ?
                 iommu_legacy_map(d, _dfn(gfn), mfn, 1ul << order, iommu_flags) :
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index 07e9594493..b77f1c5ca3 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -76,7 +76,7 @@ static __init void mark_pv_pt_pages_rdonly(struct domain *d,
          * iommu_memory_setup() ended up mapping them.
          */
         if ( need_iommu_pt_sync(d) &&
-             iommu_unmap(d, _dfn(mfn_x(page_to_mfn(page))), 1, 0, flush_flags) )
+             iommu_unmap(d, _dfn(mfn_x(page_to_mfn(page))), 1, 0, flush_flags, 0) )
             BUG();
 
         /* Read-only mapping + PGC_allocated + page-table page. */
@@ -127,7 +127,7 @@ static void __init iommu_memory_setup(struct domain *d, const char *what,
 
     while ( (rc = iommu_map(d, _dfn(mfn_x(mfn)), mfn, nr,
                             IOMMUF_readable | IOMMUF_writable | IOMMUF_preempt,
-                            flush_flags)) > 0 )
+                            flush_flags, 0)) > 0 )
     {
         mfn = mfn_add(mfn, rc);
         nr -= rc;
@@ -943,7 +943,7 @@ static int __init dom0_construct(struct domain *d,
     }
 
     /* Use while() to avoid compiler warning. */
-    while ( iommu_iotlb_flush_all(d, flush_flags) )
+    while ( iommu_iotlb_flush_all(d, 0, flush_flags) )
         break;
 
     if ( initrd_len != 0 )
diff --git a/xen/arch/x86/tboot.c b/xen/arch/x86/tboot.c
index ba0700d2d5..ca55306830 100644
--- a/xen/arch/x86/tboot.c
+++ b/xen/arch/x86/tboot.c
@@ -216,9 +216,9 @@ static void tboot_gen_domain_integrity(const uint8_t key[TB_KEY_SIZE],
 
         if ( is_iommu_enabled(d) && is_vtd )
         {
-            const struct domain_iommu *dio = dom_iommu(d);
+            struct domain_iommu *dio = dom_iommu(d);
 
-            update_iommu_mac(&ctx, dio->arch.vtd.pgd_maddr,
+            update_iommu_mac(&ctx, iommu_default_context(d)->arch.vtd.pgd_maddr,
                              agaw_to_level(dio->arch.vtd.agaw));
         }
     }
diff --git a/xen/common/memory.c b/xen/common/memory.c
index de2cc7ad92..0eb0f9da7b 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -925,7 +925,7 @@ int xenmem_add_to_physmap(struct domain *d, struct xen_add_to_physmap *xatp,
         this_cpu(iommu_dont_flush_iotlb) = 0;
 
         ret = iommu_iotlb_flush(d, _dfn(xatp->idx - done), done,
-                                IOMMU_FLUSHF_modified);
+                                IOMMU_FLUSHF_modified, 0);
         if ( unlikely(ret) && rc >= 0 )
             rc = ret;
 
@@ -939,7 +939,7 @@ int xenmem_add_to_physmap(struct domain *d, struct xen_add_to_physmap *xatp,
             put_page(pages[i]);
 
         ret = iommu_iotlb_flush(d, _dfn(xatp->gpfn - done), done,
-                                IOMMU_FLUSHF_added | IOMMU_FLUSHF_modified);
+                                IOMMU_FLUSHF_added | IOMMU_FLUSHF_modified, 0);
         if ( unlikely(ret) && rc >= 0 )
             rc = ret;
     }
diff --git a/xen/drivers/passthrough/Makefile b/xen/drivers/passthrough/Makefile
index a1621540b7..69327080ab 100644
--- a/xen/drivers/passthrough/Makefile
+++ b/xen/drivers/passthrough/Makefile
@@ -4,6 +4,9 @@ obj-$(CONFIG_X86) += x86/
 obj-$(CONFIG_ARM) += arm/
 
 obj-y += iommu.o
+obj-y += context.o
+obj-y += quarantine.o
+
 obj-$(CONFIG_HAS_PCI) += pci.o
 obj-$(CONFIG_HAS_DEVICE_TREE) += device_tree.o
 obj-$(CONFIG_HAS_PCI) += ats.o
diff --git a/xen/drivers/passthrough/context.c b/xen/drivers/passthrough/context.c
new file mode 100644
index 0000000000..6e68f840f3
--- /dev/null
+++ b/xen/drivers/passthrough/context.c
@@ -0,0 +1,740 @@
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <xen/iommu.h>
+#include <xen/event.h>
+#include <xen/sched.h>
+#include <xen/spinlock.h>
+#include <xen/bitops.h>
+#include <xen/bitmap.h>
+
+bool cf_check iommu_check_context(struct domain *d, u16 ctx_no) {
+    struct domain_iommu *hd = dom_iommu(d);
+
+    if (ctx_no == 0)
+        return 1; /* Default context always exist. */
+
+    if ((ctx_no - 1) >= hd->other_contexts.count)
+        return 0; /* out of bounds */
+
+    return test_bit(ctx_no - 1, hd->other_contexts.bitmap);
+}
+
+struct iommu_context * cf_check iommu_get_context(struct domain *d, u16 ctx_no) {
+    struct domain_iommu *hd = dom_iommu(d);
+    struct iommu_context *ctx;
+
+    if ( !iommu_check_context(d, ctx_no) )
+        return NULL;
+
+    if (ctx_no == 0)
+        ctx = &hd->default_ctx;
+    else
+        ctx = &hd->other_contexts.map[ctx_no - 1];
+
+    rspin_lock(&ctx->lock);
+    /* Check if the context is still valid at this point */
+    if ( unlikely(!iommu_check_context(d, ctx_no)) )
+    {
+        /* Context has been destroyed in between */
+        rspin_unlock(&ctx->lock);
+        return NULL;
+    }
+
+    return ctx;
+}
+
+void iommu_put_context(struct iommu_context *ctx)
+{
+    rspin_unlock(&ctx->lock);
+}
+
+static unsigned int mapping_order(const struct domain_iommu *hd,
+                                  dfn_t dfn, mfn_t mfn, unsigned long nr)
+{
+    unsigned long res = dfn_x(dfn) | mfn_x(mfn);
+    unsigned long sizes = hd->platform_ops->page_sizes;
+    unsigned int bit = ffsl(sizes) - 1, order = 0;
+
+    ASSERT(bit == PAGE_SHIFT);
+
+    while ( (sizes = (sizes >> bit) & ~1) )
+    {
+        unsigned long mask;
+
+        bit = ffsl(sizes) - 1;
+        mask = (1UL << bit) - 1;
+        if ( nr <= mask || (res & mask) )
+            break;
+        order += bit;
+        nr >>= bit;
+        res >>= bit;
+    }
+
+    return order;
+}
+
+static long _iommu_map(struct domain *d, dfn_t dfn0, mfn_t mfn0,
+                       unsigned long page_count, unsigned int flags,
+                       unsigned int *flush_flags, struct iommu_context *ctx)
+{
+    struct domain_iommu *hd = dom_iommu(d);
+    unsigned long i;
+    unsigned int order, j = 0;
+    int rc = 0;
+
+    if ( !is_iommu_enabled(d) )
+        return 0;
+
+    ASSERT(!IOMMUF_order(flags));
+
+    for ( i = 0; i < page_count; i += 1UL << order )
+    {
+        dfn_t dfn = dfn_add(dfn0, i);
+        mfn_t mfn = mfn_add(mfn0, i);
+
+        order = mapping_order(hd, dfn, mfn, page_count - i);
+
+        if ( (flags & IOMMUF_preempt) &&
+             ((!(++j & 0xfff) && general_preempt_check()) ||
+              i > LONG_MAX - (1UL << order)) )
+            return i;
+
+        rc = iommu_call(hd->platform_ops, map_page, d, dfn, mfn,
+                        flags | IOMMUF_order(order), flush_flags, ctx);
+
+        if ( likely(!rc) )
+            continue;
+
+        if ( !d->is_shutting_down && printk_ratelimit() )
+            printk(XENLOG_ERR
+                   "d%d: IOMMU mapping dfn %"PRI_dfn" to mfn %"PRI_mfn" failed: %d\n",
+                   d->domain_id, dfn_x(dfn), mfn_x(mfn), rc);
+
+        /* while statement to satisfy __must_check */
+        while ( iommu_unmap(d, dfn0, i, 0, flush_flags, ctx->id) )
+            break;
+
+        if ( !ctx->id && !is_hardware_domain(d) )
+            domain_crash(d);
+
+        break;
+    }
+
+    /*
+     * Something went wrong so, if we were dealing with more than a single
+     * page, flush everything and clear flush flags.
+     */
+    if ( page_count > 1 && unlikely(rc) &&
+         !iommu_iotlb_flush_all(d, ctx->id, *flush_flags) )
+        *flush_flags = 0;
+
+    return rc;
+}
+
+long iommu_map(struct domain *d, dfn_t dfn0, mfn_t mfn0,
+               unsigned long page_count, unsigned int flags,
+               unsigned int *flush_flags, u16 ctx_no)
+{
+    struct iommu_context *ctx;
+    long ret;
+
+    if ( !(ctx = iommu_get_context(d, ctx_no)) )
+        return -ENOENT;
+
+    ret = _iommu_map(d, dfn0, mfn0, page_count, flags, flush_flags, ctx);
+
+    iommu_put_context(ctx);
+
+    return ret;
+}
+
+int iommu_legacy_map(struct domain *d, dfn_t dfn, mfn_t mfn,
+                     unsigned long page_count, unsigned int flags)
+{
+    struct iommu_context *ctx;
+    unsigned int flush_flags = 0;
+    int rc = 0;
+
+    ASSERT(!(flags & IOMMUF_preempt));
+
+    if ( dom_iommu(d)->no_dma )
+        return 0;
+
+    ctx = iommu_get_context(d, 0);
+
+    if ( !ctx->opaque )
+    {
+        rc = iommu_map(d, dfn, mfn, page_count, flags, &flush_flags, 0);
+
+        if ( !this_cpu(iommu_dont_flush_iotlb) && !rc )
+            rc = iommu_iotlb_flush(d, dfn, page_count, flush_flags, 0);
+    }
+
+    iommu_put_context(ctx);
+
+    return rc;
+}
+
+static long _iommu_unmap(struct domain *d, dfn_t dfn0, unsigned long page_count,
+                         unsigned int flags, unsigned int *flush_flags,
+                         struct iommu_context *ctx)
+{
+    struct domain_iommu *hd = dom_iommu(d);
+    unsigned long i;
+    unsigned int order, j = 0;
+    int rc = 0;
+
+    if ( !is_iommu_enabled(d) )
+        return 0;
+
+    ASSERT(!(flags & ~IOMMUF_preempt));
+
+    for ( i = 0; i < page_count; i += 1UL << order )
+    {
+        dfn_t dfn = dfn_add(dfn0, i);
+        int err;
+
+        order = mapping_order(hd, dfn, _mfn(0), page_count - i);
+
+        if ( (flags & IOMMUF_preempt) &&
+             ((!(++j & 0xfff) && general_preempt_check()) ||
+              i > LONG_MAX - (1UL << order)) )
+            return i;
+
+        err = iommu_call(hd->platform_ops, unmap_page, d, dfn,
+                         flags | IOMMUF_order(order), flush_flags,
+                         ctx);
+
+        if ( likely(!err) )
+            continue;
+
+        if ( !d->is_shutting_down && printk_ratelimit() )
+            printk(XENLOG_ERR
+                   "d%d: IOMMU unmapping dfn %"PRI_dfn" failed: %d\n",
+                   d->domain_id, dfn_x(dfn), err);
+
+        if ( !rc )
+            rc = err;
+
+        if ( !ctx->id && !is_hardware_domain(d) )
+        {
+            domain_crash(d);
+            break;
+        }
+    }
+
+    /*
+     * Something went wrong so, if we were dealing with more than a single
+     * page, flush everything and clear flush flags.
+     */
+    if ( page_count > 1 && unlikely(rc) &&
+         !iommu_iotlb_flush_all(d, ctx->id, *flush_flags) )
+        *flush_flags = 0;
+
+    return rc;
+}
+
+long iommu_unmap(struct domain *d, dfn_t dfn0, unsigned long page_count,
+                 unsigned int flags, unsigned int *flush_flags,
+                 u16 ctx_no)
+{
+    struct iommu_context *ctx;
+    long ret;
+
+    if ( !(ctx = iommu_get_context(d, ctx_no)) )
+        return -ENOENT;
+
+    ret = _iommu_unmap(d, dfn0, page_count, flags, flush_flags, ctx);
+
+    iommu_put_context(ctx);
+
+    return ret;
+}
+
+int iommu_legacy_unmap(struct domain *d, dfn_t dfn, unsigned long page_count)
+{
+    unsigned int flush_flags = 0;
+    struct iommu_context *ctx;
+    int rc;
+
+    if ( dom_iommu(d)->no_dma )
+        return 0;
+
+    ctx = iommu_get_context(d, 0);
+
+    if ( ctx->opaque )
+        return 0;
+
+    rc = iommu_unmap(d, dfn, page_count, 0, &flush_flags, 0);
+
+    if ( !this_cpu(iommu_dont_flush_iotlb) && !rc )
+        rc = iommu_iotlb_flush(d, dfn, page_count, flush_flags, 0);
+
+    iommu_put_context(ctx);
+
+    return rc;
+}
+
+int iommu_lookup_page(struct domain *d, dfn_t dfn, mfn_t *mfn,
+                      unsigned int *flags, u16 ctx_no)
+{
+    struct domain_iommu *hd = dom_iommu(d);
+    struct iommu_context *ctx;
+    int ret = 0;
+
+    if ( !is_iommu_enabled(d) || !hd->platform_ops->lookup_page )
+        return -EOPNOTSUPP;
+
+    if ( !(ctx = iommu_get_context(d, ctx_no)) )
+        return -ENOENT;
+
+    ret = iommu_call(hd->platform_ops, lookup_page, d, dfn, mfn, flags, ctx);
+
+    iommu_put_context(ctx);
+    return ret;
+}
+
+int iommu_iotlb_flush(struct domain *d, dfn_t dfn, unsigned long page_count,
+                      unsigned int flush_flags, u16 ctx_no)
+{
+    struct domain_iommu *hd = dom_iommu(d);
+    struct iommu_context *ctx;
+    int rc;
+
+    if ( !is_iommu_enabled(d) || !hd->platform_ops->iotlb_flush ||
+         !page_count || !flush_flags )
+        return 0;
+
+    if ( dfn_eq(dfn, INVALID_DFN) )
+        return -EINVAL;
+
+    if ( !(ctx = iommu_get_context(d, ctx_no)) )
+        return -ENOENT;
+
+    rc = iommu_call(hd->platform_ops, iotlb_flush, d, ctx, dfn, page_count,
+                    flush_flags);
+    if ( unlikely(rc) )
+    {
+        if ( !d->is_shutting_down && printk_ratelimit() )
+            printk(XENLOG_ERR
+                   "d%d: IOMMU IOTLB flush failed: %d, dfn %"PRI_dfn", page count %lu flags %x\n",
+                   d->domain_id, rc, dfn_x(dfn), page_count, flush_flags);
+
+        if ( !ctx->id && !is_hardware_domain(d) )
+            domain_crash(d);
+    }
+
+    iommu_put_context(ctx);
+
+    return rc;
+}
+
+int iommu_iotlb_flush_all(struct domain *d, u16 ctx_no, unsigned int flush_flags)
+{
+    struct domain_iommu *hd = dom_iommu(d);
+    struct iommu_context *ctx;
+    int rc;
+
+    if ( !(ctx = iommu_get_context(d, ctx_no)) )
+        return -ENOENT;
+
+    rc = iommu_call(hd->platform_ops, iotlb_flush, d, ctx, _dfn(0), 0,
+                    flush_flags | IOMMU_FLUSHF_all);
+    if ( unlikely(rc) )
+    {
+        if ( !d->is_shutting_down && printk_ratelimit() )
+            printk(XENLOG_ERR
+                   "d%d: IOMMU IOTLB flush all failed: %d\n",
+                   d->domain_id, rc);
+
+        if ( !is_hardware_domain(d) )
+            domain_crash(d);
+    }
+
+    iommu_put_context(ctx);
+    return rc;
+}
+
+int cf_check iommu_context_init(struct domain *d, struct iommu_context *ctx, u16 ctx_no,
+                       u32 flags)
+{
+    if ( !dom_iommu(d)->platform_ops->context_init )
+        return -ENOSYS;
+
+    INIT_LIST_HEAD(&ctx->devices);
+    ctx->id = ctx_no;
+    ctx->dying = false;
+    ctx->opaque = false; /* assume non-opaque by default */
+
+    return iommu_call(dom_iommu(d)->platform_ops, context_init, d, ctx, flags);
+}
+
+int iommu_context_alloc(struct domain *d, u16 *ctx_no, u32 flags)
+{
+    unsigned int i;
+    int ret;
+    struct domain_iommu *hd = dom_iommu(d);
+    struct iommu_context *ctx;
+
+    do {
+        i = find_first_zero_bit(hd->other_contexts.bitmap, hd->other_contexts.count);
+
+        if ( i >= hd->other_contexts.count )
+            return -ENOSPC;
+
+        ctx = &hd->other_contexts.map[i];
+
+        /* Try to lock the mutex, can fail on concurrent accesses */
+        if ( !rspin_trylock(&ctx->lock) )
+            continue;
+
+        /* We can now set it as used, we keep the lock for initialization. */
+        set_bit(i, hd->other_contexts.bitmap);
+    } while (0);
+
+    *ctx_no = i + 1;
+
+    ret = iommu_context_init(d, ctx, *ctx_no, flags);
+
+    if ( ret )
+        clear_bit(*ctx_no, hd->other_contexts.bitmap);
+
+    iommu_put_context(ctx);
+    return ret;
+}
+
+/**
+ * Attach dev phantom functions to ctx, override any existing
+ * mapped context.
+ */
+static int cf_check iommu_reattach_phantom(struct domain *d, device_t *dev,
+                                  struct iommu_context *ctx)
+{
+    int ret = 0;
+    uint8_t devfn = dev->devfn;
+    struct domain_iommu *hd = dom_iommu(d);
+
+    while ( dev->phantom_stride )
+    {
+        devfn += dev->phantom_stride;
+
+        if ( PCI_SLOT(devfn) != PCI_SLOT(dev->devfn) )
+            break;
+
+        ret = iommu_call(hd->platform_ops, add_devfn, d, dev, devfn, ctx);
+
+        if ( ret )
+            break;
+    }
+
+    return ret;
+}
+
+/**
+ * Detach all device phantom functions.
+ */
+static int cf_check iommu_detach_phantom(struct domain *d, device_t *dev)
+{
+    int ret = 0;
+    uint8_t devfn = dev->devfn;
+    struct domain_iommu *hd = dom_iommu(d);
+
+    while ( dev->phantom_stride )
+    {
+        devfn += dev->phantom_stride;
+
+        if ( PCI_SLOT(devfn) != PCI_SLOT(dev->devfn) )
+            break;
+
+        ret = iommu_call(hd->platform_ops, remove_devfn, d, dev, devfn);
+
+        if ( ret )
+            break;
+    }
+
+    return ret;
+}
+
+int cf_check iommu_attach_context(struct domain *d, device_t *dev, u16 ctx_no)
+{
+    struct iommu_context *ctx = NULL;
+    int ret, rc;
+
+    if ( !(ctx = iommu_get_context(d, ctx_no)) )
+    {
+        ret = -ENOENT;
+        goto unlock;
+    }
+
+    pcidevs_lock();
+
+    if ( ctx->dying )
+    {
+        ret = -EINVAL;
+        goto unlock;
+    }
+
+    ret = iommu_call(dom_iommu(d)->platform_ops, attach, d, dev, ctx);
+
+    if ( ret )
+        goto unlock;
+
+    /* See iommu_reattach_context() */
+    rc = iommu_reattach_phantom(d, dev, ctx);
+
+    if ( rc )
+    {
+        printk(XENLOG_ERR "IOMMU: Unable to attach %pp phantom functions\n",
+               &dev->sbdf);
+
+        if( iommu_call(dom_iommu(d)->platform_ops, detach, d, dev, ctx)
+            || iommu_detach_phantom(d, dev) )
+        {
+            printk(XENLOG_ERR "IOMMU: Improperly detached %pp\n", &dev->sbdf);
+            WARN();
+        }
+
+        ret = -EIO;
+        goto unlock;
+    }
+
+    dev->context = ctx_no;
+    list_add(&dev->context_list, &ctx->devices);
+
+unlock:
+    pcidevs_unlock();
+
+    if ( ctx )
+        iommu_put_context(ctx);
+
+    return ret;
+}
+
+int cf_check iommu_detach_context(struct domain *d, device_t *dev)
+{
+    struct iommu_context *ctx;
+    int ret, rc;
+
+    if ( !dev->domain )
+    {
+        printk(XENLOG_WARNING "IOMMU: Trying to detach a non-attached device\n");
+        WARN();
+        return 0;
+    }
+
+    /* Make sure device is actually in the domain. */
+    ASSERT(d == dev->domain);
+
+    pcidevs_lock();
+
+    ctx = iommu_get_context(d, dev->context);
+    ASSERT(ctx); /* device is using an invalid context ?
+                    dev->context invalid ? */
+
+    ret = iommu_call(dom_iommu(d)->platform_ops, detach, d, dev, ctx);
+
+    if ( ret )
+        goto unlock;
+
+    rc = iommu_detach_phantom(d, dev);
+
+    if ( rc )
+        printk(XENLOG_WARNING "IOMMU: "
+               "Improperly detached device functions (%d)\n", rc);
+
+    list_del(&dev->context_list);
+
+unlock:
+    pcidevs_unlock();
+    iommu_put_context(ctx);
+    return ret;
+}
+
+int cf_check iommu_reattach_context(struct domain *prev_dom, struct domain *next_dom,
+                           device_t *dev, u16 ctx_no)
+{
+    u16 prev_ctx_no;
+    device_t *ctx_dev;
+    struct domain_iommu *prev_hd, *next_hd;
+    struct iommu_context *prev_ctx = NULL, *next_ctx = NULL;
+    int ret, rc;
+    bool same_domain;
+
+    /* Make sure we actually are doing something meaningful */
+    BUG_ON(!prev_dom && !next_dom);
+
+    /* Device domain must be coherent with prev_dom. */
+    ASSERT(!prev_dom || dev->domain == prev_dom);
+
+    /// TODO: Do such cases exists ?
+    // /* Platform ops must match */
+    // if (dom_iommu(prev_dom)->platform_ops != dom_iommu(next_dom)->platform_ops)
+    //     return -EINVAL;
+
+    if ( !prev_dom )
+        return iommu_attach_context(next_dom, dev, ctx_no);
+
+    if ( !next_dom )
+        return iommu_detach_context(prev_dom, dev);
+
+    prev_hd = dom_iommu(prev_dom);
+    next_hd = dom_iommu(next_dom);
+
+    pcidevs_lock();
+
+    same_domain = prev_dom == next_dom;
+
+    prev_ctx_no = dev->context;
+
+    if ( same_domain && (ctx_no == prev_ctx_no) )
+    {
+        printk(XENLOG_DEBUG
+               "IOMMU: Reattaching %pp to same IOMMU context c%hu\n",
+               &dev->sbdf, ctx_no);
+        ret = 0;
+        goto unlock;
+    }
+
+    if ( !(prev_ctx = iommu_get_context(prev_dom, prev_ctx_no)) )
+    {
+        ret = -ENOENT;
+        goto unlock;
+    }
+
+    if ( !(next_ctx = iommu_get_context(next_dom, ctx_no)) )
+    {
+        ret = -ENOENT;
+        goto unlock;
+    }
+
+    if ( next_ctx->dying )
+    {
+        ret = -EINVAL;
+        goto unlock;
+    }
+
+    ret = iommu_call(prev_hd->platform_ops, reattach, next_dom, dev, prev_ctx,
+                     next_ctx);
+
+    if ( ret )
+        goto unlock;
+
+    /*
+     * We need to do special handling for phantom devices as they
+     * also use some other PCI functions behind the scenes.
+     */
+    rc = iommu_reattach_phantom(next_dom, dev, next_ctx);
+
+    if ( rc )
+    {
+        /**
+         * Device is being partially reattached (we have primary function and
+         * maybe some phantom functions attached to next_ctx, some others to prev_ctx),
+         * some functions of the device will be attached to next_ctx.
+         */
+        printk(XENLOG_WARNING "IOMMU: "
+               "Device %pp improperly reattached due to phantom function"
+               " reattach failure between %dd%dc and %dd%dc (%d)\n", dev,
+               prev_dom->domain_id, prev_ctx->id, next_dom->domain_id,
+               next_dom->domain_id, rc);
+
+        /* Try reattaching to previous context, reverting into a consistent state. */
+        if ( iommu_call(prev_hd->platform_ops, reattach, prev_dom, dev, next_ctx,
+                        prev_ctx) || iommu_reattach_phantom(prev_dom, dev, prev_ctx) )
+        {
+            printk(XENLOG_ERR "Unable to reattach %pp back to %dd%dc\n",
+                   &dev->sbdf, prev_dom->domain_id, prev_ctx->id);
+
+            if ( !is_hardware_domain(prev_dom) )
+                domain_crash(prev_dom);
+
+            if ( prev_dom != next_dom && !is_hardware_domain(next_dom) )
+                domain_crash(next_dom);
+
+            rc = -EIO;
+        }
+
+        ret = rc;
+        goto unlock;
+    }
+
+    /* Remove device from previous context, and add it to new one. */
+    list_for_each_entry(ctx_dev, &prev_ctx->devices, context_list)
+    {
+        if ( ctx_dev == dev )
+        {
+            list_del(&ctx_dev->context_list);
+            list_add(&ctx_dev->context_list, &next_ctx->devices);
+            break;
+        }
+    }
+
+    if (!ret)
+        dev->context = ctx_no; /* update device context*/
+
+unlock:
+    pcidevs_unlock();
+
+    if ( prev_ctx )
+        iommu_put_context(prev_ctx);
+
+    if ( next_ctx )
+        iommu_put_context(next_ctx);
+
+    return ret;
+}
+
+int cf_check iommu_context_teardown(struct domain *d, struct iommu_context *ctx, u32 flags)
+{
+    struct domain_iommu *hd = dom_iommu(d);
+
+    if ( !hd->platform_ops->context_teardown )
+        return -ENOSYS;
+
+    ctx->dying = true;
+
+    /* first reattach devices back to default context if needed */
+    if ( flags & IOMMU_TEARDOWN_REATTACH_DEFAULT )
+    {
+        struct pci_dev *device;
+        list_for_each_entry(device, &ctx->devices, context_list)
+            iommu_reattach_context(d, d, device, 0);
+    }
+    else if (!list_empty(&ctx->devices))
+        return -EBUSY; /* there is a device in context */
+
+    return iommu_call(hd->platform_ops, context_teardown, d, ctx, flags);
+}
+
+int cf_check iommu_context_free(struct domain *d, u16 ctx_no, u32 flags)
+{
+    int ret;
+    struct domain_iommu *hd = dom_iommu(d);
+    struct iommu_context *ctx;
+
+    if ( ctx_no == 0 )
+        return -EINVAL;
+
+    if ( !(ctx = iommu_get_context(d, ctx_no)) )
+        return -ENOENT;
+
+    ret = iommu_context_teardown(d, ctx, flags);
+
+    if ( !ret )
+        clear_bit(ctx_no - 1, hd->other_contexts.bitmap);
+
+    iommu_put_context(ctx);
+    return ret;
+}
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 50bfd62553..091333f100 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -12,15 +12,18 @@
  * this program; If not, see <http://www.gnu.org/licenses/>.
  */
 
+#include <xen/atomic.h>
+#include <xen/errno.h>
+#include <xen/xmalloc.h>
+#include <xen/pci.h>
 #include <xen/sched.h>
+#include <xen/spinlock.h>
 #include <xen/iommu.h>
-#include <xen/paging.h>
-#include <xen/guest_access.h>
-#include <xen/event.h>
 #include <xen/param.h>
-#include <xen/softirq.h>
 #include <xen/keyhandler.h>
-#include <xsm/xsm.h>
+#include <asm/arena.h>
+#include <asm/iommu.h>
+#include <asm/bitops.h>
 
 #ifdef CONFIG_X86
 #include <asm/e820.h>
@@ -35,26 +38,11 @@ bool __read_mostly force_iommu;
 bool __read_mostly iommu_verbose;
 static bool __read_mostly iommu_crash_disable;
 
-#define IOMMU_quarantine_none         0 /* aka false */
-#define IOMMU_quarantine_basic        1 /* aka true */
-#define IOMMU_quarantine_scratch_page 2
-#ifdef CONFIG_HAS_PCI
-uint8_t __read_mostly iommu_quarantine =
-# if defined(CONFIG_IOMMU_QUARANTINE_NONE)
-    IOMMU_quarantine_none;
-# elif defined(CONFIG_IOMMU_QUARANTINE_BASIC)
-    IOMMU_quarantine_basic;
-# elif defined(CONFIG_IOMMU_QUARANTINE_SCRATCH_PAGE)
-    IOMMU_quarantine_scratch_page;
-# endif
-#else
-# define iommu_quarantine IOMMU_quarantine_none
-#endif /* CONFIG_HAS_PCI */
-
 static bool __hwdom_initdata iommu_hwdom_none;
 bool __hwdom_initdata iommu_hwdom_strict;
 bool __read_mostly iommu_hwdom_passthrough;
 bool __hwdom_initdata iommu_hwdom_inclusive;
+bool __read_mostly iommu_hwdom_no_dma = false;
 int8_t __hwdom_initdata iommu_hwdom_reserved = -1;
 
 #ifndef iommu_hap_pt_share
@@ -172,6 +160,8 @@ static int __init cf_check parse_dom0_iommu_param(const char *s)
             iommu_hwdom_reserved = val;
         else if ( !cmdline_strcmp(s, "none") )
             iommu_hwdom_none = true;
+        else if ( (val = parse_boolean("dma", s, ss)) >= 0 )
+            iommu_hwdom_no_dma = !val;
         else
             rc = -EINVAL;
 
@@ -193,6 +183,98 @@ static void __hwdom_init check_hwdom_reqs(struct domain *d)
     arch_iommu_check_autotranslated_hwdom(d);
 }
 
+int iommu_domain_pviommu_init(struct domain *d, uint16_t nb_ctx, uint32_t arena_order)
+{
+    struct domain_iommu *hd = dom_iommu(d);
+    int rc;
+
+    BUG_ON(nb_ctx == 0); /* sanity check (prevent underflow) */
+
+    /*
+     * hd->other_contexts.count is always reported as 0 during initialization
+     * preventing misuse of partially initialized IOMMU contexts.
+     */
+
+    if ( atomic_cmpxchg(&hd->other_contexts.initialized, 0, 1) == 1 )
+        return -EACCES;
+
+    if ( (nb_ctx - 1) > 0 ) {
+        /* Initialize context bitmap */
+        size_t i;
+
+        hd->other_contexts.bitmap = xzalloc_array(unsigned long,
+                                                  BITS_TO_LONGS(nb_ctx - 1));
+
+        if (!hd->other_contexts.bitmap)
+        {
+            rc = -ENOMEM;
+            goto cleanup;
+        }
+
+        hd->other_contexts.map = xzalloc_array(struct iommu_context, nb_ctx - 1);
+
+        if (!hd->other_contexts.map)
+        {
+            rc = -ENOMEM;
+            goto cleanup;
+        }
+
+        for (i = 0; i < (nb_ctx - 1); i++)
+            rspin_lock_init(&hd->other_contexts.map[i].lock);
+    }
+
+    rc = arch_iommu_pviommu_init(d, nb_ctx, arena_order);
+
+    if ( rc )
+        goto cleanup;
+
+    /* Make sure initialization is complete before making it visible to other CPUs. */
+    smp_wmb();
+
+    hd->other_contexts.count = nb_ctx - 1;
+
+    printk(XENLOG_INFO "Dom%d uses %lu IOMMU contexts (%llu pages arena)\n",
+           d->domain_id, (unsigned long)nb_ctx, 1llu << arena_order);
+
+    return 0;
+
+cleanup:
+    /* TODO: Reset hd->other_contexts.initialized */
+    if ( hd->other_contexts.bitmap )
+    {
+        xfree(hd->other_contexts.bitmap);
+        hd->other_contexts.bitmap = NULL;
+    }
+
+    if ( hd->other_contexts.map )
+    {
+        xfree(hd->other_contexts.map);
+        hd->other_contexts.bitmap = NULL;
+    }
+
+    return rc;
+}
+
+int iommu_domain_pviommu_teardown(struct domain *d)
+{
+    struct domain_iommu *hd = dom_iommu(d);
+    int i;
+    /* FIXME: Potential race condition with remote_op ? */
+
+    for (i = 0; i < hd->other_contexts.count; i++)
+        WARN_ON(iommu_context_free(d, i, IOMMU_TEARDOWN_REATTACH_DEFAULT) != ENOENT);
+
+    hd->other_contexts.count = 0;
+
+    if ( hd->other_contexts.bitmap )
+        xfree(hd->other_contexts.bitmap);
+
+    if ( hd->other_contexts.map )
+        xfree(hd->other_contexts.map);
+
+    return 0;
+}
+
 int iommu_domain_init(struct domain *d, unsigned int opts)
 {
     struct domain_iommu *hd = dom_iommu(d);
@@ -208,13 +290,15 @@ int iommu_domain_init(struct domain *d, unsigned int opts)
     hd->node = NUMA_NO_NODE;
 #endif
 
+    rspin_lock_init(&hd->default_ctx.lock);
+
     ret = arch_iommu_domain_init(d);
     if ( ret )
         return ret;
 
     hd->platform_ops = iommu_get_ops();
     ret = iommu_call(hd->platform_ops, init, d);
-    if ( ret || is_system_domain(d) )
+    if ( ret || (is_system_domain(d) && d != dom_io) )
         return ret;
 
     /*
@@ -236,6 +320,23 @@ int iommu_domain_init(struct domain *d, unsigned int opts)
 
     ASSERT(!(hd->need_sync && hd->hap_pt_share));
 
+    if ( hd->no_dma )
+    {
+        /* No-DMA mode is exclusive with HAP and sync_pt. */
+        hd->hap_pt_share = false;
+        hd->need_sync = false;
+    }
+
+    hd->allow_pv_iommu = true;
+
+    iommu_context_init(d, &hd->default_ctx, 0, IOMMU_CONTEXT_INIT_default);
+
+    rwlock_init(&hd->other_contexts.lock);
+    hd->other_contexts.initialized = (atomic_t)ATOMIC_INIT(0);
+    hd->other_contexts.count = 0;
+    hd->other_contexts.bitmap = NULL;
+    hd->other_contexts.map = NULL;
+
     return 0;
 }
 
@@ -249,14 +350,11 @@ static void cf_check iommu_dump_page_tables(unsigned char key)
 
     for_each_domain(d)
     {
-        if ( is_hardware_domain(d) || !is_iommu_enabled(d) )
+        if ( !is_iommu_enabled(d) )
             continue;
 
         if ( iommu_use_hap_pt(d) )
-        {
             printk("%pd sharing page tables\n", d);
-            continue;
-        }
 
         iommu_vcall(dom_iommu(d)->platform_ops, dump_page_tables, d);
     }
@@ -276,9 +374,13 @@ void __hwdom_init iommu_hwdom_init(struct domain *d)
     iommu_vcall(hd->platform_ops, hwdom_init, d);
 }
 
-static void iommu_teardown(struct domain *d)
+void cf_check iommu_domain_destroy(struct domain *d)
 {
     struct domain_iommu *hd = dom_iommu(d);
+    struct pci_dev *pdev;
+
+    if ( !is_iommu_enabled(d) )
+        return;
 
     /*
      * During early domain creation failure, we may reach here with the
@@ -287,266 +389,25 @@ static void iommu_teardown(struct domain *d)
     if ( !hd->platform_ops )
         return;
 
-    iommu_vcall(hd->platform_ops, teardown, d);
-}
-
-void iommu_domain_destroy(struct domain *d)
-{
-    if ( !is_iommu_enabled(d) )
-        return;
-
-    iommu_teardown(d);
-
-    arch_iommu_domain_destroy(d);
-}
-
-static unsigned int mapping_order(const struct domain_iommu *hd,
-                                  dfn_t dfn, mfn_t mfn, unsigned long nr)
-{
-    unsigned long res = dfn_x(dfn) | mfn_x(mfn);
-    unsigned long sizes = hd->platform_ops->page_sizes;
-    unsigned int bit = ffsl(sizes) - 1, order = 0;
-
-    ASSERT(bit == PAGE_SHIFT);
-
-    while ( (sizes = (sizes >> bit) & ~1) )
+    /* Move all devices back to quarantine */
+    /* TODO: Is it needed ? */
+    for_each_pdev(d, pdev)
     {
-        unsigned long mask;
-
-        bit = ffsl(sizes) - 1;
-        mask = (1UL << bit) - 1;
-        if ( nr <= mask || (res & mask) )
-            break;
-        order += bit;
-        nr >>= bit;
-        res >>= bit;
-    }
-
-    return order;
-}
-
-long iommu_map(struct domain *d, dfn_t dfn0, mfn_t mfn0,
-               unsigned long page_count, unsigned int flags,
-               unsigned int *flush_flags)
-{
-    const struct domain_iommu *hd = dom_iommu(d);
-    unsigned long i;
-    unsigned int order, j = 0;
-    int rc = 0;
-
-    if ( !is_iommu_enabled(d) )
-        return 0;
-
-    ASSERT(!IOMMUF_order(flags));
-
-    for ( i = 0; i < page_count; i += 1UL << order )
-    {
-        dfn_t dfn = dfn_add(dfn0, i);
-        mfn_t mfn = mfn_add(mfn0, i);
-
-        order = mapping_order(hd, dfn, mfn, page_count - i);
-
-        if ( (flags & IOMMUF_preempt) &&
-             ((!(++j & 0xfff) && general_preempt_check()) ||
-              i > LONG_MAX - (1UL << order)) )
-            return i;
-
-        rc = iommu_call(hd->platform_ops, map_page, d, dfn, mfn,
-                        flags | IOMMUF_order(order), flush_flags);
-
-        if ( likely(!rc) )
-            continue;
-
-        if ( !d->is_shutting_down && printk_ratelimit() )
-            printk(XENLOG_ERR
-                   "d%d: IOMMU mapping dfn %"PRI_dfn" to mfn %"PRI_mfn" failed: %d\n",
-                   d->domain_id, dfn_x(dfn), mfn_x(mfn), rc);
-
-        /* while statement to satisfy __must_check */
-        while ( iommu_unmap(d, dfn0, i, 0, flush_flags) )
-            break;
+        int rc = iommu_reattach_context(d, dom_io, pdev, 0);
 
-        if ( !is_hardware_domain(d) )
-            domain_crash(d);
-
-        break;
-    }
-
-    /*
-     * Something went wrong so, if we were dealing with more than a single
-     * page, flush everything and clear flush flags.
-     */
-    if ( page_count > 1 && unlikely(rc) &&
-         !iommu_iotlb_flush_all(d, *flush_flags) )
-        *flush_flags = 0;
-
-    return rc;
-}
-
-int iommu_legacy_map(struct domain *d, dfn_t dfn, mfn_t mfn,
-                     unsigned long page_count, unsigned int flags)
-{
-    unsigned int flush_flags = 0;
-    int rc;
-
-    ASSERT(!(flags & IOMMUF_preempt));
-    rc = iommu_map(d, dfn, mfn, page_count, flags, &flush_flags);
-
-    if ( !this_cpu(iommu_dont_flush_iotlb) && !rc )
-        rc = iommu_iotlb_flush(d, dfn, page_count, flush_flags);
-
-    return rc;
-}
-
-long iommu_unmap(struct domain *d, dfn_t dfn0, unsigned long page_count,
-                 unsigned int flags, unsigned int *flush_flags)
-{
-    const struct domain_iommu *hd = dom_iommu(d);
-    unsigned long i;
-    unsigned int order, j = 0;
-    int rc = 0;
-
-    if ( !is_iommu_enabled(d) )
-        return 0;
-
-    ASSERT(!(flags & ~IOMMUF_preempt));
-
-    for ( i = 0; i < page_count; i += 1UL << order )
-    {
-        dfn_t dfn = dfn_add(dfn0, i);
-        int err;
-
-        order = mapping_order(hd, dfn, _mfn(0), page_count - i);
-
-        if ( (flags & IOMMUF_preempt) &&
-             ((!(++j & 0xfff) && general_preempt_check()) ||
-              i > LONG_MAX - (1UL << order)) )
-            return i;
-
-        err = iommu_call(hd->platform_ops, unmap_page, d, dfn,
-                         flags | IOMMUF_order(order), flush_flags);
-
-        if ( likely(!err) )
-            continue;
-
-        if ( !d->is_shutting_down && printk_ratelimit() )
-            printk(XENLOG_ERR
-                   "d%d: IOMMU unmapping dfn %"PRI_dfn" failed: %d\n",
-                   d->domain_id, dfn_x(dfn), err);
-
-        if ( !rc )
-            rc = err;
-
-        if ( !is_hardware_domain(d) )
+        if ( rc )
         {
-            domain_crash(d);
-            break;
+            printk(XENLOG_WARNING "Unable to quarantine device %pp (%d)\n", &pdev->sbdf, rc);
+            pdev->broken = true;
         }
+        else
+            pdev->domain = dom_io;
     }
 
-    /*
-     * Something went wrong so, if we were dealing with more than a single
-     * page, flush everything and clear flush flags.
-     */
-    if ( page_count > 1 && unlikely(rc) &&
-         !iommu_iotlb_flush_all(d, *flush_flags) )
-        *flush_flags = 0;
-
-    return rc;
-}
-
-int iommu_legacy_unmap(struct domain *d, dfn_t dfn, unsigned long page_count)
-{
-    unsigned int flush_flags = 0;
-    int rc = iommu_unmap(d, dfn, page_count, 0, &flush_flags);
-
-    if ( !this_cpu(iommu_dont_flush_iotlb) && !rc )
-        rc = iommu_iotlb_flush(d, dfn, page_count, flush_flags);
-
-    return rc;
-}
-
-int iommu_lookup_page(struct domain *d, dfn_t dfn, mfn_t *mfn,
-                      unsigned int *flags)
-{
-    const struct domain_iommu *hd = dom_iommu(d);
-
-    if ( !is_iommu_enabled(d) || !hd->platform_ops->lookup_page )
-        return -EOPNOTSUPP;
-
-    return iommu_call(hd->platform_ops, lookup_page, d, dfn, mfn, flags);
-}
-
-int iommu_iotlb_flush(struct domain *d, dfn_t dfn, unsigned long page_count,
-                      unsigned int flush_flags)
-{
-    const struct domain_iommu *hd = dom_iommu(d);
-    int rc;
-
-    if ( !is_iommu_enabled(d) || !hd->platform_ops->iotlb_flush ||
-         !page_count || !flush_flags )
-        return 0;
-
-    if ( dfn_eq(dfn, INVALID_DFN) )
-        return -EINVAL;
-
-    rc = iommu_call(hd->platform_ops, iotlb_flush, d, dfn, page_count,
-                    flush_flags);
-    if ( unlikely(rc) )
-    {
-        if ( !d->is_shutting_down && printk_ratelimit() )
-            printk(XENLOG_ERR
-                   "d%d: IOMMU IOTLB flush failed: %d, dfn %"PRI_dfn", page count %lu flags %x\n",
-                   d->domain_id, rc, dfn_x(dfn), page_count, flush_flags);
-
-        if ( !is_hardware_domain(d) )
-            domain_crash(d);
-    }
-
-    return rc;
-}
-
-int iommu_iotlb_flush_all(struct domain *d, unsigned int flush_flags)
-{
-    const struct domain_iommu *hd = dom_iommu(d);
-    int rc;
-
-    if ( !is_iommu_enabled(d) || !hd->platform_ops->iotlb_flush ||
-         !flush_flags )
-        return 0;
-
-    rc = iommu_call(hd->platform_ops, iotlb_flush, d, INVALID_DFN, 0,
-                    flush_flags | IOMMU_FLUSHF_all);
-    if ( unlikely(rc) )
-    {
-        if ( !d->is_shutting_down && printk_ratelimit() )
-            printk(XENLOG_ERR
-                   "d%d: IOMMU IOTLB flush all failed: %d\n",
-                   d->domain_id, rc);
-
-        if ( !is_hardware_domain(d) )
-            domain_crash(d);
-    }
-
-    return rc;
-}
-
-int iommu_quarantine_dev_init(device_t *dev)
-{
-    const struct domain_iommu *hd = dom_iommu(dom_io);
-
-    if ( !iommu_quarantine || !hd->platform_ops->quarantine_init )
-        return 0;
-
-    return iommu_call(hd->platform_ops, quarantine_init,
-                      dev, iommu_quarantine == IOMMU_quarantine_scratch_page);
-}
-
-static int __init iommu_quarantine_init(void)
-{
-    dom_io->options |= XEN_DOMCTL_CDF_iommu;
+    iommu_vcall(hd->platform_ops, teardown, d);
 
-    return iommu_domain_init(dom_io, 0);
+    iommu_domain_pviommu_teardown(d);
+    arch_iommu_domain_destroy(d);
 }
 
 int __init iommu_setup(void)
@@ -681,6 +542,16 @@ bool iommu_has_feature(struct domain *d, enum iommu_feature feature)
     return is_iommu_enabled(d) && test_bit(feature, dom_iommu(d)->features);
 }
 
+uint64_t iommu_get_max_iova(struct domain *d)
+{
+    struct domain_iommu *hd = dom_iommu(d);
+
+    if ( !hd->platform_ops->get_max_iova )
+        return 0;
+
+    return iommu_call(hd->platform_ops, get_max_iova, d);
+}
+
 #define MAX_EXTRA_RESERVED_RANGES 20
 struct extra_reserved_range {
     unsigned long start;
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index ae620b3007..7b2625a9de 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -1,6 +1,6 @@
 /*
  * Copyright (C) 2008,  Netronome Systems, Inc.
- *                
+ *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms and conditions of the GNU General Public License,
  * version 2, as published by the Free Software Foundation.
@@ -286,14 +286,14 @@ static void apply_quirks(struct pci_dev *pdev)
          * Device [8086:2fc0]
          * Erratum HSE43
          * CONFIG_TDP_NOMINAL CSR Implemented at Incorrect Offset
-         * http://www.intel.com/content/www/us/en/processors/xeon/xeon-e5-v3-spec-update.html 
+         * http://www.intel.com/content/www/us/en/processors/xeon/xeon-e5-v3-spec-update.html
          */
         { PCI_VENDOR_ID_INTEL, 0x2fc0 },
         /*
          * Devices [8086:6f60,6fa0,6fc0]
          * Errata BDF2 / BDX2
          * PCI BARs in the Home Agent Will Return Non-Zero Values During Enumeration
-         * http://www.intel.com/content/www/us/en/processors/xeon/xeon-e5-v4-spec-update.html 
+         * http://www.intel.com/content/www/us/en/processors/xeon/xeon-e5-v4-spec-update.html
         */
         { PCI_VENDOR_ID_INTEL, 0x6f60 },
         { PCI_VENDOR_ID_INTEL, 0x6fa0 },
@@ -651,6 +651,101 @@ unsigned int pci_size_mem_bar(pci_sbdf_t sbdf, unsigned int pos,
     return is64bits ? 2 : 1;
 }
 
+static int device_assigned(struct pci_dev *pdev)
+{
+    int rc = 0;
+
+    /*
+     * If the device exists and it is not owned by either the hardware
+     * domain or dom_io then it must be assigned to a guest, or be
+     * hidden (owned by dom_xen).
+     */
+    if ( pdev->domain != hardware_domain && pdev->domain != dom_io )
+        rc = -EBUSY;
+
+    return rc;
+}
+
+/* Caller should hold the pcidevs_lock */
+static int pci_reassign_device(struct domain *prev_dom, struct domain *next_dom,
+                               struct pci_dev *pdev, u32 flag)
+{
+    int rc = 0;
+    ASSERT(prev_dom || next_dom);
+
+    if ( !is_iommu_enabled(next_dom) )
+        return -EINVAL;
+
+    if ( !arch_iommu_use_permitted(next_dom) )
+        return -EXDEV;
+
+    /* Do not allow broken devices to be assigned to guests. */
+    if ( pdev->broken && next_dom != hardware_domain && next_dom != dom_io )
+        return -EBADF;
+
+    if ( prev_dom )
+    {
+        write_lock(&prev_dom->pci_lock);
+        vpci_deassign_device(pdev);
+        write_unlock(&prev_dom->pci_lock);
+    }
+
+    rc = pdev_msix_assign(next_dom, pdev);
+    if ( rc )
+        goto done;
+
+    pdev->fault.count = 0;
+
+    if ( prev_dom && next_dom )
+    {
+        printk(XENLOG_INFO "PCI: Reassigning PCI device from %dd to %dd\n",
+               prev_dom->domain_id, next_dom->domain_id);
+    }
+    else if ( prev_dom )
+    {
+        printk(XENLOG_INFO "PCI: Assigning PCI device to %dd\n", prev_dom->domain_id);
+    }
+    else if ( next_dom )
+    {
+        printk(XENLOG_INFO "PCI: Remove PCI device of %dd\n", next_dom->domain_id);
+    }
+    else
+    {
+        ASSERT_UNREACHABLE();
+    }
+
+    rc = iommu_reattach_context(prev_dom, next_dom, pci_to_dev(pdev), 0);
+
+    if ( rc )
+        goto done;
+
+    if ( prev_dom )
+    {
+        write_lock(&prev_dom->pci_lock);
+        list_del(&pdev->domain_list);
+        write_unlock(&prev_dom->pci_lock);
+    }
+
+    pdev->domain = next_dom;
+
+    if ( next_dom )
+    {
+        write_lock(&next_dom->pci_lock);
+        list_add(&pdev->domain_list, &next_dom->pdev_list);
+
+        rc = vpci_assign_device(pdev);
+        write_unlock(&next_dom->pci_lock);
+    }
+
+ done:
+
+    /* The device is assigned to dom_io so mark it as quarantined */
+    if ( !rc && next_dom == dom_io )
+        pdev->quarantine = true;
+
+    return rc;
+}
+
 int pci_add_device(u16 seg, u8 bus, u8 devfn,
                    const struct pci_dev_info *info, nodeid_t node)
 {
@@ -891,74 +986,6 @@ int pci_remove_device(u16 seg, u8 bus, u8 devfn)
     return ret;
 }
 
-/* Caller should hold the pcidevs_lock */
-static int deassign_device(struct domain *d, uint16_t seg, uint8_t bus,
-                           uint8_t devfn)
-{
-    const struct domain_iommu *hd = dom_iommu(d);
-    struct pci_dev *pdev;
-    struct domain *target;
-    int ret = 0;
-
-    if ( !is_iommu_enabled(d) )
-        return -EINVAL;
-
-    ASSERT(pcidevs_locked());
-    pdev = pci_get_pdev(d, PCI_SBDF(seg, bus, devfn));
-    if ( !pdev )
-        return -ENODEV;
-
-    /* De-assignment from dom_io should de-quarantine the device */
-    if ( (pdev->quarantine || iommu_quarantine) && pdev->domain != dom_io )
-    {
-        ret = iommu_quarantine_dev_init(pci_to_dev(pdev));
-        if ( ret )
-           return ret;
-
-        target = dom_io;
-    }
-    else
-        target = hardware_domain;
-
-    while ( pdev->phantom_stride )
-    {
-        devfn += pdev->phantom_stride;
-        if ( PCI_SLOT(devfn) != PCI_SLOT(pdev->devfn) )
-            break;
-        ret = iommu_call(hd->platform_ops, reassign_device, d, target, devfn,
-                         pci_to_dev(pdev));
-        if ( ret )
-            goto out;
-    }
-
-    write_lock(&d->pci_lock);
-    vpci_deassign_device(pdev);
-    write_unlock(&d->pci_lock);
-
-    devfn = pdev->devfn;
-    ret = iommu_call(hd->platform_ops, reassign_device, d, target, devfn,
-                     pci_to_dev(pdev));
-    if ( ret )
-        goto out;
-
-    if ( pdev->domain == hardware_domain  )
-        pdev->quarantine = false;
-
-    pdev->fault.count = 0;
-
-    write_lock(&target->pci_lock);
-    /* Re-assign back to hardware_domain */
-    ret = vpci_assign_device(pdev);
-    write_unlock(&target->pci_lock);
-
- out:
-    if ( ret )
-        printk(XENLOG_G_ERR "%pd: deassign (%pp) failed (%d)\n",
-               d, &PCI_SBDF(seg, bus, devfn), ret);
-
-    return ret;
-}
-
 int pci_release_devices(struct domain *d)
 {
     int combined_ret;
@@ -980,13 +1007,10 @@ int pci_release_devices(struct domain *d)
         struct pci_dev *pdev = list_first_entry(&d->pdev_list,
                                                 struct pci_dev,
                                                 domain_list);
-        uint16_t seg = pdev->seg;
-        uint8_t bus = pdev->bus;
-        uint8_t devfn = pdev->devfn;
         int ret;
 
         write_unlock(&d->pci_lock);
-        ret = deassign_device(d, seg, bus, devfn);
+        ret = pci_reassign_device(d, dom_io, pdev, 0);
         write_lock(&d->pci_lock);
         if ( ret )
         {
@@ -1194,25 +1218,18 @@ struct setup_hwdom {
 static void __hwdom_init setup_one_hwdom_device(const struct setup_hwdom *ctxt,
                                                 struct pci_dev *pdev)
 {
-    u8 devfn = pdev->devfn;
     int err;
 
-    do {
-        err = ctxt->handler(devfn, pdev);
-        if ( err )
-        {
-            printk(XENLOG_ERR "setup %pp for d%d failed (%d)\n",
-                   &pdev->sbdf, ctxt->d->domain_id, err);
-            if ( devfn == pdev->devfn )
-                return;
-        }
-        devfn += pdev->phantom_stride;
-    } while ( devfn != pdev->devfn &&
-              PCI_SLOT(devfn) == PCI_SLOT(pdev->devfn) );
+    err = ctxt->handler(pdev->devfn, pdev);
+
+    if ( err )
+        goto done;
 
     write_lock(&ctxt->d->pci_lock);
     err = vpci_assign_device(pdev);
     write_unlock(&ctxt->d->pci_lock);
+
+done:
     if ( err )
         printk(XENLOG_ERR "setup of vPCI for d%d failed: %d\n",
                ctxt->d->domain_id, err);
@@ -1384,12 +1401,7 @@ static int cf_check _dump_pci_devices(struct pci_seg *pseg, void *arg)
     list_for_each_entry ( pdev, &pseg->alldevs_list, alldevs_list )
     {
         printk("%pp - ", &pdev->sbdf);
-#ifdef CONFIG_X86
-        if ( pdev->domain == dom_io )
-            printk("DomIO:%x", pdev->arch.pseudo_domid);
-        else
-#endif
-            printk("%pd", pdev->domain);
+        printk("%pd", pdev->domain);
         printk(" - node %-3d", (pdev->node != NUMA_NO_NODE) ? pdev->node : -1);
         pdev_dump_msi(pdev);
         printk("\n");
@@ -1416,8 +1428,6 @@ __initcall(setup_dump_pcidevs);
 static int iommu_add_device(struct pci_dev *pdev)
 {
     const struct domain_iommu *hd;
-    int rc;
-    unsigned int devfn = pdev->devfn;
 
     if ( !pdev->domain )
         return -EINVAL;
@@ -1428,20 +1438,7 @@ static int iommu_add_device(struct pci_dev *pdev)
     if ( !is_iommu_enabled(pdev->domain) )
         return 0;
 
-    rc = iommu_call(hd->platform_ops, add_device, devfn, pci_to_dev(pdev));
-    if ( rc || !pdev->phantom_stride )
-        return rc;
-
-    for ( ; ; )
-    {
-        devfn += pdev->phantom_stride;
-        if ( PCI_SLOT(devfn) != PCI_SLOT(pdev->devfn) )
-            return 0;
-        rc = iommu_call(hd->platform_ops, add_device, devfn, pci_to_dev(pdev));
-        if ( rc )
-            printk(XENLOG_WARNING "IOMMU: add %pp failed (%d)\n",
-                   &PCI_SBDF(pdev->seg, pdev->bus, devfn), rc);
-    }
+    return iommu_attach_context(pdev->domain, pci_to_dev(pdev), 0);
 }
 
 static int iommu_enable_device(struct pci_dev *pdev)
@@ -1463,145 +1460,13 @@ static int iommu_enable_device(struct pci_dev *pdev)
 
 static int iommu_remove_device(struct pci_dev *pdev)
 {
-    const struct domain_iommu *hd;
-    u8 devfn;
-
     if ( !pdev->domain )
         return -EINVAL;
 
-    hd = dom_iommu(pdev->domain);
     if ( !is_iommu_enabled(pdev->domain) )
         return 0;
 
-    for ( devfn = pdev->devfn ; pdev->phantom_stride; )
-    {
-        int rc;
-
-        devfn += pdev->phantom_stride;
-        if ( PCI_SLOT(devfn) != PCI_SLOT(pdev->devfn) )
-            break;
-        rc = iommu_call(hd->platform_ops, remove_device, devfn,
-                        pci_to_dev(pdev));
-        if ( !rc )
-            continue;
-
-        printk(XENLOG_ERR "IOMMU: remove %pp failed (%d)\n",
-               &PCI_SBDF(pdev->seg, pdev->bus, devfn), rc);
-        return rc;
-    }
-
-    devfn = pdev->devfn;
-
-    return iommu_call(hd->platform_ops, remove_device, devfn, pci_to_dev(pdev));
-}
-
-static int device_assigned(u16 seg, u8 bus, u8 devfn)
-{
-    struct pci_dev *pdev;
-    int rc = 0;
-
-    ASSERT(pcidevs_locked());
-    pdev = pci_get_pdev(NULL, PCI_SBDF(seg, bus, devfn));
-
-    if ( !pdev )
-        rc = -ENODEV;
-    /*
-     * If the device exists and it is not owned by either the hardware
-     * domain or dom_io then it must be assigned to a guest, or be
-     * hidden (owned by dom_xen).
-     */
-    else if ( pdev->domain != hardware_domain &&
-              pdev->domain != dom_io )
-        rc = -EBUSY;
-
-    return rc;
-}
-
-/* Caller should hold the pcidevs_lock */
-static int assign_device(struct domain *d, u16 seg, u8 bus, u8 devfn, u32 flag)
-{
-    const struct domain_iommu *hd = dom_iommu(d);
-    struct pci_dev *pdev;
-    int rc = 0;
-
-    if ( !is_iommu_enabled(d) )
-        return 0;
-
-    if ( !arch_iommu_use_permitted(d) )
-        return -EXDEV;
-
-    /* device_assigned() should already have cleared the device for assignment */
-    ASSERT(pcidevs_locked());
-    pdev = pci_get_pdev(NULL, PCI_SBDF(seg, bus, devfn));
-    ASSERT(pdev && (pdev->domain == hardware_domain ||
-                    pdev->domain == dom_io));
-
-    /* Do not allow broken devices to be assigned to guests. */
-    rc = -EBADF;
-    if ( pdev->broken && d != hardware_domain && d != dom_io )
-        goto done;
-
-    write_lock(&pdev->domain->pci_lock);
-    vpci_deassign_device(pdev);
-    write_unlock(&pdev->domain->pci_lock);
-
-    rc = pdev_msix_assign(d, pdev);
-    if ( rc )
-        goto done;
-
-    if ( pdev->domain != dom_io )
-    {
-        rc = iommu_quarantine_dev_init(pci_to_dev(pdev));
-        if ( rc )
-            goto done;
-    }
-
-    pdev->fault.count = 0;
-
-    rc = iommu_call(hd->platform_ops, assign_device, d, devfn, pci_to_dev(pdev),
-                    flag);
-
-    while ( pdev->phantom_stride && !rc )
-    {
-        devfn += pdev->phantom_stride;
-        if ( PCI_SLOT(devfn) != PCI_SLOT(pdev->devfn) )
-            break;
-        rc = iommu_call(hd->platform_ops, assign_device, d, devfn,
-                        pci_to_dev(pdev), flag);
-    }
-
-    if ( rc )
-        goto done;
-
-    write_lock(&d->pci_lock);
-    rc = vpci_assign_device(pdev);
-    write_unlock(&d->pci_lock);
-
- done:
-    if ( rc )
-    {
-        printk(XENLOG_G_WARNING "%pd: assign %s(%pp) failed (%d)\n",
-               d, devfn != pdev->devfn ? "phantom function " : "",
-               &PCI_SBDF(seg, bus, devfn), rc);
-
-        if ( devfn != pdev->devfn && deassign_device(d, seg, bus, pdev->devfn) )
-        {
-            /*
-             * Device with phantom functions that failed to both assign and
-             * rollback.  Mark the device as broken and crash the target domain,
-             * as the state of the functions at this point is unknown and Xen
-             * has no way to assert consistent context assignment among them.
-             */
-            pdev->broken = true;
-            if ( !is_hardware_domain(d) && d != dom_io )
-                domain_crash(d);
-        }
-    }
-    /* The device is assigned to dom_io so mark it as quarantined */
-    else if ( d == dom_io )
-        pdev->quarantine = true;
-
-    return rc;
+    return iommu_detach_context(pdev->domain, pdev);
 }
 
 static int iommu_get_device_group(
@@ -1691,6 +1556,7 @@ int iommu_do_pci_domctl(
     u8 bus, devfn;
     int ret = 0;
     uint32_t machine_sbdf;
+    struct pci_dev *pdev;
 
     switch ( domctl->cmd )
     {
@@ -1760,7 +1626,15 @@ int iommu_do_pci_domctl(
         devfn = PCI_DEVFN(machine_sbdf);
 
         pcidevs_lock();
-        ret = device_assigned(seg, bus, devfn);
+        pdev = pci_get_pdev(NULL, PCI_SBDF(seg, bus, devfn));
+
+        if ( !pdev )
+        {
+            printk(XENLOG_G_INFO "%pp doesn't exist", &PCI_SBDF(seg, bus, devfn));
+            break;
+        }
+
+        ret = device_assigned(pdev);
         if ( domctl->cmd == XEN_DOMCTL_test_assign_device )
         {
             if ( ret )
@@ -1771,7 +1645,7 @@ int iommu_do_pci_domctl(
             }
         }
         else if ( !ret )
-            ret = assign_device(d, seg, bus, devfn, flags);
+            ret = pci_reassign_device(pdev->domain, d, pdev, flags);
         pcidevs_unlock();
         if ( ret == -ERESTART )
             ret = hypercall_create_continuation(__HYPERVISOR_domctl,
@@ -1805,7 +1679,20 @@ int iommu_do_pci_domctl(
         devfn = PCI_DEVFN(machine_sbdf);
 
         pcidevs_lock();
-        ret = deassign_device(d, seg, bus, devfn);
+        pdev = pci_get_pdev(d, PCI_SBDF(seg, bus, devfn));
+
+        if ( pdev )
+        {
+            struct domain *target = hardware_domain;
+
+            if ( (pdev->quarantine || iommu_quarantine) && pdev->domain != dom_io )
+                target = dom_io;
+
+            ret = pci_reassign_device(d, target, pdev, 0);
+        }
+        else
+            ret = -ENODEV;
+
         pcidevs_unlock();
         break;
 
diff --git a/xen/drivers/passthrough/quarantine.c b/xen/drivers/passthrough/quarantine.c
new file mode 100644
index 0000000000..b58f136ad8
--- /dev/null
+++ b/xen/drivers/passthrough/quarantine.c
@@ -0,0 +1,49 @@
+#include <xen/stdint.h>
+#include <xen/iommu.h>
+#include <xen/sched.h>
+
+#ifdef CONFIG_HAS_PCI
+uint8_t __read_mostly iommu_quarantine =
+# if defined(CONFIG_IOMMU_QUARANTINE_NONE)
+    IOMMU_quarantine_none;
+# elif defined(CONFIG_IOMMU_QUARANTINE_BASIC)
+    IOMMU_quarantine_basic;
+# elif defined(CONFIG_IOMMU_QUARANTINE_SCRATCH_PAGE)
+    IOMMU_quarantine_scratch_page;
+# endif
+#else
+# define iommu_quarantine IOMMU_quarantine_none
+#endif /* CONFIG_HAS_PCI */
+
+int iommu_quarantine_dev_init(device_t *dev)
+{
+    int ret;
+    u16 ctx_no;
+
+    if ( !iommu_quarantine )
+        return 0;
+
+    ret = iommu_context_alloc(dom_io, &ctx_no, IOMMU_CONTEXT_INIT_quarantine);
+
+    if ( ret )
+        return ret;
+
+    /** TODO: Setup scratch page, mappings... */
+
+    ret = iommu_reattach_context(dev->domain, dom_io, dev, ctx_no);
+
+    if ( ret )
+    {
+        ASSERT(!iommu_context_free(dom_io, ctx_no, 0));
+        return ret;
+    }
+
+    return ret;
+}
+
+int __init iommu_quarantine_init(void)
+{
+    dom_io->options |= XEN_DOMCTL_CDF_iommu;
+
+    return iommu_domain_init(dom_io, 0);
+}
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 442ae5322d..ea23f2b734 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -52,7 +52,11 @@ static inline bool dfn_eq(dfn_t x, dfn_t y)
 #ifdef CONFIG_HAS_PASSTHROUGH
 extern bool iommu_enable, iommu_enabled;
 extern bool force_iommu, iommu_verbose;
+
 /* Boolean except for the specific purposes of drivers/passthrough/iommu.c. */
+#define IOMMU_quarantine_none         0 /* aka false */
+#define IOMMU_quarantine_basic        1 /* aka true */
+#define IOMMU_quarantine_scratch_page 2
 extern uint8_t iommu_quarantine;
 #else
 #define iommu_enabled false
@@ -106,6 +110,7 @@ extern bool iommu_debug;
 extern bool amd_iommu_perdev_intremap;
 
 extern bool iommu_hwdom_strict, iommu_hwdom_passthrough, iommu_hwdom_inclusive;
+extern bool iommu_hwdom_no_dma;
 extern int8_t iommu_hwdom_reserved;
 
 extern unsigned int iommu_dev_iotlb_timeout;
@@ -161,11 +166,10 @@ enum
  */
 long __must_check iommu_map(struct domain *d, dfn_t dfn0, mfn_t mfn0,
                             unsigned long page_count, unsigned int flags,
-                            unsigned int *flush_flags);
+                            unsigned int *flush_flags, u16 ctx_no);
 long __must_check iommu_unmap(struct domain *d, dfn_t dfn0,
                               unsigned long page_count, unsigned int flags,
-                              unsigned int *flush_flags);
-
+                              unsigned int *flush_flags, u16 ctx_no);
 int __must_check iommu_legacy_map(struct domain *d, dfn_t dfn, mfn_t mfn,
                                   unsigned long page_count,
                                   unsigned int flags);
@@ -173,12 +177,13 @@ int __must_check iommu_legacy_unmap(struct domain *d, dfn_t dfn,
                                     unsigned long page_count);
 
 int __must_check iommu_lookup_page(struct domain *d, dfn_t dfn, mfn_t *mfn,
-                                   unsigned int *flags);
+                                   unsigned int *flags, u16 ctx_no);
 
 int __must_check iommu_iotlb_flush(struct domain *d, dfn_t dfn,
                                    unsigned long page_count,
-                                   unsigned int flush_flags);
-int __must_check iommu_iotlb_flush_all(struct domain *d,
+                                   unsigned int flush_flags,
+                                   u16 ctx_no);
+int __must_check iommu_iotlb_flush_all(struct domain *d, u16 ctx_no,
                                        unsigned int flush_flags);
 
 enum iommu_feature
@@ -250,20 +255,30 @@ struct page_info;
  */
 typedef int iommu_grdm_t(xen_pfn_t start, xen_ulong_t nr, u32 id, void *ctxt);
 
+struct iommu_context;
+
 struct iommu_ops {
     unsigned long page_sizes;
     int (*init)(struct domain *d);
     void (*hwdom_init)(struct domain *d);
-    int (*quarantine_init)(device_t *dev, bool scratch_page);
-    int (*add_device)(uint8_t devfn, device_t *dev);
+    int (*context_init)(struct domain *d, struct iommu_context *ctx,
+                        u32 flags);
+    int (*context_teardown)(struct domain *d, struct iommu_context *ctx,
+                            u32 flags);
+    int (*attach)(struct domain *d, device_t *dev,
+                  struct iommu_context *ctx);
+    int (*detach)(struct domain *d, device_t *dev,
+                   struct iommu_context *prev_ctx);
+    int (*reattach)(struct domain *d, device_t *dev,
+                    struct iommu_context *prev_ctx,
+                    struct iommu_context *ctx);
+
     int (*enable_device)(device_t *dev);
-    int (*remove_device)(uint8_t devfn, device_t *dev);
-    int (*assign_device)(struct domain *d, uint8_t devfn, device_t *dev,
-                         uint32_t flag);
-    int (*reassign_device)(struct domain *s, struct domain *t,
-                           uint8_t devfn, device_t *dev);
 #ifdef CONFIG_HAS_PCI
     int (*get_device_group_id)(uint16_t seg, uint8_t bus, uint8_t devfn);
+    int (*add_devfn)(struct domain *d, struct pci_dev *pdev, u16 devfn,
+                     struct iommu_context *ctx);
+    int (*remove_devfn)(struct domain *d, struct pci_dev *pdev, u16 devfn);
 #endif /* HAS_PCI */
 
     void (*teardown)(struct domain *d);
@@ -274,12 +289,15 @@ struct iommu_ops {
      */
     int __must_check (*map_page)(struct domain *d, dfn_t dfn, mfn_t mfn,
                                  unsigned int flags,
-                                 unsigned int *flush_flags);
+                                 unsigned int *flush_flags,
+                                 struct iommu_context *ctx);
     int __must_check (*unmap_page)(struct domain *d, dfn_t dfn,
                                    unsigned int order,
-                                   unsigned int *flush_flags);
+                                   unsigned int *flush_flags,
+                                   struct iommu_context *ctx);
     int __must_check (*lookup_page)(struct domain *d, dfn_t dfn, mfn_t *mfn,
-                                    unsigned int *flags);
+                                    unsigned int *flags,
+                                    struct iommu_context *ctx);
 
 #ifdef CONFIG_X86
     int (*enable_x2apic)(void);
@@ -292,14 +310,15 @@ struct iommu_ops {
     int (*setup_hpet_msi)(struct msi_desc *msi_desc);
 
     void (*adjust_irq_affinities)(void);
-    void (*clear_root_pgtable)(struct domain *d);
+    void (*clear_root_pgtable)(struct domain *d, struct iommu_context *ctx);
     int (*update_ire_from_msi)(struct msi_desc *msi_desc, struct msi_msg *msg);
 #endif /* CONFIG_X86 */
 
     int __must_check (*suspend)(void);
     void (*resume)(void);
     void (*crash_shutdown)(void);
-    int __must_check (*iotlb_flush)(struct domain *d, dfn_t dfn,
+    int __must_check (*iotlb_flush)(struct domain *d,
+                                    struct iommu_context *ctx, dfn_t dfn,
                                     unsigned long page_count,
                                     unsigned int flush_flags);
     int (*get_reserved_device_memory)(iommu_grdm_t *func, void *ctxt);
@@ -314,6 +333,8 @@ struct iommu_ops {
      */
     int (*dt_xlate)(device_t *dev, const struct dt_phandle_args *args);
 #endif
+
+    uint64_t (*get_max_iova)(struct domain *d);
 };
 
 /*
@@ -343,11 +364,39 @@ extern int iommu_get_extra_reserved_device_memory(iommu_grdm_t *func,
 # define iommu_vcall iommu_call
 #endif
 
+struct iommu_context {
+    u16 id; /* Context id (0 means default context) */
+    rspinlock_t lock; /* context lock */
+
+    struct list_head devices;
+
+    struct arch_iommu_context arch;
+
+    bool opaque; /* context can't be modified nor accessed (e.g HAP) */
+    bool dying; /* the context is tearing down */
+};
+
+struct iommu_context_list {
+    atomic_t initialized; /* has/is context list being initialized ? */
+    rwlock_t lock; /* prevent concurrent destruction and access of contexts */
+    uint16_t count; /* Context count excluding default context */
+
+    /* if count > 0 */
+
+    uint64_t *bitmap; /* bitmap of context allocation */
+    struct iommu_context *map; /* Map of contexts */
+};
+
+
 struct domain_iommu {
+
 #ifdef CONFIG_HAS_PASSTHROUGH
     struct arch_iommu arch;
 #endif
 
+    struct iommu_context default_ctx;
+    struct iommu_context_list other_contexts;
+
     /* iommu_ops */
     const struct iommu_ops *platform_ops;
 
@@ -365,6 +414,12 @@ struct domain_iommu {
     /* SAF-2-safe enum constant in arithmetic operation */
     DECLARE_BITMAP(features, IOMMU_FEAT_count);
 
+    /* Do the IOMMU block all DMA on default context (implies !has_pt_share) ? */
+    bool no_dma;
+
+    /* Is the domain allowed to use PV-IOMMU ? */
+    bool allow_pv_iommu;
+
     /* Does the guest share HAP mapping with the IOMMU? */
     bool hap_pt_share;
 
@@ -380,6 +435,7 @@ struct domain_iommu {
 #define dom_iommu(d)              (&(d)->iommu)
 #define iommu_set_feature(d, f)   set_bit(f, dom_iommu(d)->features)
 #define iommu_clear_feature(d, f) clear_bit(f, dom_iommu(d)->features)
+#define iommu_default_context(d) (&dom_iommu(d)->default_ctx) /* does not lock ! */
 
 /* Are we using the domain P2M table as its IOMMU pagetable? */
 #define iommu_use_hap_pt(d)       (IS_ENABLED(CONFIG_HVM) && \
@@ -401,10 +457,14 @@ static inline int iommu_do_domctl(struct xen_domctl *domctl, struct domain *d,
 }
 #endif
 
+int iommu_domain_pviommu_init(struct domain *d, uint16_t nb_ctx, uint32_t arena_order);
+
 int __must_check iommu_suspend(void);
 void iommu_resume(void);
 void iommu_crash_shutdown(void);
 int iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt);
+
+int __init iommu_quarantine_init(void);
 int iommu_quarantine_dev_init(device_t *dev);
 
 #ifdef CONFIG_HAS_PCI
@@ -414,6 +474,27 @@ int iommu_do_pci_domctl(struct xen_domctl *domctl, struct domain *d,
 
 void iommu_dev_iotlb_flush_timeout(struct domain *d, struct pci_dev *pdev);
 
+uint64_t iommu_get_max_iova(struct domain *d);
+
+struct iommu_context *iommu_get_context(struct domain *d, u16 ctx_no);
+void iommu_put_context(struct iommu_context *ctx);
+
+#define IOMMU_CONTEXT_INIT_default (1 << 0)
+#define IOMMU_CONTEXT_INIT_quarantine (1 << 1)
+int iommu_context_init(struct domain *d, struct iommu_context *ctx, u16 ctx_no, u32 flags);
+
+#define IOMMU_TEARDOWN_REATTACH_DEFAULT (1 << 0)
+#define IOMMU_TEARDOWN_PREEMPT (1 << 1)
+int iommu_context_teardown(struct domain *d, struct iommu_context *ctx, u32 flags);
+
+int iommu_context_alloc(struct domain *d, u16 *ctx_no, u32 flags);
+int iommu_context_free(struct domain *d, u16 ctx_no, u32 flags);
+
+int iommu_reattach_context(struct domain *prev_dom, struct domain *next_dom,
+                           device_t *dev, u16 ctx_no);
+int iommu_attach_context(struct domain *d, device_t *dev, u16 ctx_no);
+int iommu_detach_context(struct domain *d, device_t *dev);
+
 /*
  * The purpose of the iommu_dont_flush_iotlb optional cpu flag is to
  * avoid unecessary iotlb_flush in the low level IOMMU code.
@@ -429,6 +510,8 @@ DECLARE_PER_CPU(bool, iommu_dont_flush_iotlb);
 extern struct spinlock iommu_pt_cleanup_lock;
 extern struct page_list_head iommu_pt_cleanup_list;
 
+int arch_iommu_pviommu_init(struct domain *d, uint16_t nb_ctx, uint32_t arena_order);
+int arch_iommu_pviommu_teardown(struct domain *d);
 bool arch_iommu_use_permitted(const struct domain *d);
 
 #ifdef CONFIG_X86
diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
index 82e1221c9c..bb3931b01d 100644
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -97,6 +97,7 @@ struct pci_dev_info {
 struct pci_dev {
     struct list_head alldevs_list;
     struct list_head domain_list;
+    struct list_head context_list;
 
     struct list_head msi_list;
 
@@ -104,6 +105,8 @@ struct pci_dev {
 
     struct domain *domain;
 
+    uint16_t context; /* IOMMU context number of domain */
+
     const union {
         struct {
             uint8_t devfn;
-- 
2.45.3



Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 16:13:36 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 16:13:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875536.1286025 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taGsi-0003Ej-4Z; Tue, 21 Jan 2025 16:13:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875536.1286025; Tue, 21 Jan 2025 16:13:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taGsh-0003EJ-Vf; Tue, 21 Jan 2025 16:13:35 +0000
Received: by outflank-mailman (input) for mailman id 875536;
 Tue, 21 Jan 2025 16:13: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
 <SRS0=r8rV=UN=bounce.vates.tech=bounce-md_30504962.678fc7aa.v1-7ba38ac92ddf47bf98518981ccafb9b5@srs-se1.protection.inumbo.net>)
 id 1taGsf-0001oY-PX
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 16:13:34 +0000
Received: from mail187-43.suw11.mandrillapp.com
 (mail187-43.suw11.mandrillapp.com [198.2.187.43])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a7bf665d-d812-11ef-a0e4-8be0dac302b0;
 Tue, 21 Jan 2025 17:13:31 +0100 (CET)
Received: from pmta09.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail187-43.suw11.mandrillapp.com (Mailchimp) with ESMTP id
 4YcshB3TdkzLfH6hy
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 16:13:30 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 7ba38ac92ddf47bf98518981ccafb9b5; Tue, 21 Jan 2025 16:13:30 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a7bf665d-d812-11ef-a0e4-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1737476010; x=1737746010;
	bh=g73F4QgyQz7ml1sK4w80vYbFtffd6XqqtD33apxkfx8=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=pPt3Qahvq1hlUnJ+/z/OJnKOghUN7bbBrgFC3IfaHfRkZRx+3uo2EvfYsWSoGzyZo
	 9cCCAUO40CZ/RUg7KCT9onZpHg4JPqKStxQQwET789G4dVwm67GuBWylqpqg5DLdhD
	 R7s0NNZEHA4RuOtUbFGaTMDStG1/Z9zC1l78eBg6z/teIwCGyRAwL7+4QX7n0Gvnqf
	 lR015xl3ixYYzMPpo4ikd9jtQqvq/mOlQ/U0kIttwGqJ/UNGhpVwKzCjLk8st5d6af
	 AVD1PNM3R9vZyBfFkv18jfyr8EitxubhWyZ+w71nHm0/26IwfnbpB4sl++G9HrtVHu
	 5SKHJA/mG9NgQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1737476010; x=1737736510; i=teddy.astie@vates.tech;
	bh=g73F4QgyQz7ml1sK4w80vYbFtffd6XqqtD33apxkfx8=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=wNSSyBLMsYgiG5V29wsrhrNe2UA2VNskRcNbLQO0AqpTMJMKSMbm6sSVn5uF8nTdS
	 w+tytr6v8kg2bU7UXHFqmlQIY6R++RNR2M401hZ+U7fxagbUB+5Sm8PVlWGZYBK/hL
	 hAlIK3Coc2J8SX4reBYSQJodfSdsOcWd4XUARhfYWXV6OhOEE/SG6grW1EEXkqMwFW
	 XoZKpEJnbHXk/cg2XQw4gIlPjaHitWEDWh1SRGOh5lGjWihtWV7W37mn8xz6zv75ay
	 8UcOaUu5VC8UuCy3nbGr0gnsfx0bKh3bz6VppTfs40YUUxa3mFO0RHaRJyLqzQoI1b
	 23ap2FSN4JBeg==
From: "Teddy Astie" <teddy.astie@vates.tech>
Subject: =?utf-8?Q?[XEN=20RFC=20PATCH=20v5=205/5]=20VT-d:=20Port=20IOMMU=20driver=20to=20new=20subsystem?=
X-Mailer: git-send-email 2.45.3
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1737476008096
To: xen-devel@lists.xenproject.org
Cc: "Teddy Astie" <teddy.astie@vates.tech>, "Jan Beulich" <jbeulich@suse.com>, "Andrew Cooper" <andrew.cooper3@citrix.com>, "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>, "=?utf-8?Q?Marek=20Marczykowski-G=C3=B3recki?=" <marmarek@invisiblethingslab.com>
Message-Id: <d6b9b8dc27adad9dd212820c6bb7093b1174345a.1737470269.git.teddy.astie@vates.tech>
In-Reply-To: <cover.1737470269.git.teddy.astie@vates.tech>
References: <cover.1737470269.git.teddy.astie@vates.tech>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.7ba38ac92ddf47bf98518981ccafb9b5?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250121:md
Date: Tue, 21 Jan 2025 16:13:30 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Port the driver with guidances specified in iommu-contexts.md.

Add a arena-based allocator for allocating a fixed chunk of memory and
split it into 4k pages for use by the IOMMU contexts. This chunk size
is configurable with X86_ARENA_ORDER and dom0-iommu=arena-order=N.

Signed-off-by Teddy Astie <teddy.astie@vates.tech>
---
Changed in V2:
* formatting

Changed in V3:
* prevent IOMMU operations on dying contexts

Changed in V4:
* redesigned hypercall interface [1]
* added remote_cmd and init logic

[1] https://lore.kernel.org/all/fdfa32c9-c177-4d05-891a-138f9b663f19@vates.tech/

Changed in V5:
* simplified domid management
* also dump dom_io iommu contexts (with 'X' key handler)
---
 xen/arch/x86/include/asm/arena.h     |   54 +
 xen/arch/x86/include/asm/iommu.h     |   58 +-
 xen/arch/x86/include/asm/pci.h       |   17 -
 xen/drivers/passthrough/vtd/Makefile |    2 +-
 xen/drivers/passthrough/vtd/extern.h |   16 +-
 xen/drivers/passthrough/vtd/iommu.c  | 1692 ++++++++------------------
 xen/drivers/passthrough/vtd/iommu.h  |    4 +-
 xen/drivers/passthrough/vtd/qinval.c |    2 +-
 xen/drivers/passthrough/vtd/quirks.c |   20 +-
 xen/drivers/passthrough/x86/Makefile |    1 +
 xen/drivers/passthrough/x86/arena.c  |  157 +++
 xen/drivers/passthrough/x86/iommu.c  |  299 +++--
 12 files changed, 1008 insertions(+), 1314 deletions(-)
 create mode 100644 xen/arch/x86/include/asm/arena.h
 create mode 100644 xen/drivers/passthrough/x86/arena.c

diff --git a/xen/arch/x86/include/asm/arena.h b/xen/arch/x86/include/asm/arena.h
new file mode 100644
index 0000000000..7555b100e0
--- /dev/null
+++ b/xen/arch/x86/include/asm/arena.h
@@ -0,0 +1,54 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/**
+ * Simple arena-based page allocator.
+ */
+
+#ifndef __XEN_IOMMU_ARENA_H__
+#define __XEN_IOMMU_ARENA_H__
+
+#include "xen/domain.h"
+#include "xen/atomic.h"
+#include "xen/mm-frame.h"
+#include "xen/types.h"
+
+/**
+ * struct page_arena: Page arena structure
+ */
+struct iommu_arena {
+    /* mfn of the first page of the memory region */
+    mfn_t region_start;
+    /* bitmap of allocations */
+    unsigned long *map;
+
+    /* Order of the arena */
+    unsigned int order;
+
+    /* Used page count */
+    atomic_t used_pages;
+};
+
+/**
+ * Initialize a arena using domheap allocator.
+ * @param [out] arena Arena to allocate
+ * @param [in] domain domain that has ownership of arena pages
+ * @param [in] order order of the arena (power of two of the size)
+ * @param [in] memflags Flags for domheap_alloc_pages()
+ * @return -ENOMEM on arena allocation error, 0 otherwise
+ */
+int iommu_arena_initialize(struct iommu_arena *arena, struct domain *domain,
+                           unsigned int order, unsigned int memflags);
+
+/**
+ * Teardown a arena.
+ * @param [out] arena arena to allocate
+ * @param [in] check check for existing allocations
+ * @return -EBUSY if check is specified
+ */
+int iommu_arena_teardown(struct iommu_arena *arena, bool check);
+
+struct page_info *iommu_arena_allocate_page(struct iommu_arena *arena);
+bool iommu_arena_free_page(struct iommu_arena *arena, struct page_info *page);
+
+#define iommu_arena_size(arena) (1LLU << (arena)->order)
+
+#endif
diff --git a/xen/arch/x86/include/asm/iommu.h b/xen/arch/x86/include/asm/iommu.h
index 8dc464fbd3..533bb8d777 100644
--- a/xen/arch/x86/include/asm/iommu.h
+++ b/xen/arch/x86/include/asm/iommu.h
@@ -2,14 +2,18 @@
 #ifndef __ARCH_X86_IOMMU_H__
 #define __ARCH_X86_IOMMU_H__
 
+#include <xen/bitmap.h>
 #include <xen/errno.h>
 #include <xen/list.h>
 #include <xen/mem_access.h>
 #include <xen/spinlock.h>
+#include <xen/stdbool.h>
 #include <asm/apicdef.h>
 #include <asm/cache.h>
 #include <asm/processor.h>
 
+#include "arena.h"
+
 #define DEFAULT_DOMAIN_ADDRESS_WIDTH 48
 
 struct g2m_ioport {
@@ -31,27 +35,45 @@ typedef uint64_t daddr_t;
 #define dfn_to_daddr(dfn) __dfn_to_daddr(dfn_x(dfn))
 #define daddr_to_dfn(daddr) _dfn(__daddr_to_dfn(daddr))
 
-struct arch_iommu
+struct arch_iommu_context
 {
-    spinlock_t mapping_lock; /* io page table lock */
-    struct {
-        struct page_list_head list;
-        spinlock_t lock;
-    } pgtables;
-
+    struct page_list_head pgtables;
     struct list_head identity_maps;
 
+    /* Queue for freeing pages */
+    struct page_list_head free_queue;
+
+    /* Is this context reusing domain P2M ? */
+    bool hap_context;
+
     union {
         /* Intel VT-d */
         struct {
             uint64_t pgd_maddr; /* io page directory machine address */
+            domid_t *didmap; /* per-iommu DID */
+            unsigned long *iommu_bitmap; /* bitmap of iommu(s) that the context uses */
+            uint32_t superpage_progress; /* superpage progress during teardown */
+        } vtd;
+        /* AMD IOMMU */
+        struct {
+            struct page_info *root_table;
+        } amd;
+    };
+};
+
+struct arch_iommu
+{
+    struct iommu_arena pt_arena; /* allocator for non-default contexts */
+
+    union {
+        /* Intel VT-d */
+        struct {
             unsigned int agaw; /* adjusted guest address width, 0 is level 2 30-bit */
-            unsigned long *iommu_bitmap; /* bitmap of iommu(s) that the domain uses */
         } vtd;
         /* AMD IOMMU */
         struct {
             unsigned int paging_mode;
-            struct page_info *root_table;
+            struct guest_iommu *g_iommu;
         } amd;
     };
 };
@@ -109,10 +131,13 @@ static inline void iommu_disable_x2apic(void)
         iommu_vcall(&iommu_ops, disable_x2apic);
 }
 
-int iommu_identity_mapping(struct domain *d, p2m_access_t p2ma,
-                           paddr_t base, paddr_t end,
+int iommu_identity_mapping(struct domain *d, struct iommu_context *ctx,
+                           p2m_access_t p2ma, paddr_t base, paddr_t end,
                            unsigned int flag);
-void iommu_identity_map_teardown(struct domain *d);
+void iommu_identity_map_teardown(struct domain *d, struct iommu_context *ctx);
+bool iommu_identity_map_check(struct domain *d, struct iommu_context *ctx,
+                              mfn_t mfn);
+
 
 extern bool untrusted_msi;
 
@@ -128,14 +153,19 @@ unsigned long *iommu_init_domid(domid_t reserve);
 domid_t iommu_alloc_domid(unsigned long *map);
 void iommu_free_domid(domid_t domid, unsigned long *map);
 
-int __must_check iommu_free_pgtables(struct domain *d);
+struct iommu_context;
+int __must_check iommu_free_pgtables(struct domain *d, struct iommu_context *ctx);
 struct domain_iommu;
 struct page_info *__must_check iommu_alloc_pgtable(struct domain_iommu *hd,
+                                                   struct iommu_context *ctx,
                                                    uint64_t contig_mask);
-void iommu_queue_free_pgtable(struct domain_iommu *hd, struct page_info *pg);
+void iommu_queue_free_pgtable(struct iommu_context *ctx, struct page_info *pg);
 
 /* Check [start, end] unity map range for correctness. */
 bool iommu_unity_region_ok(const char *prefix, mfn_t start, mfn_t end);
+int arch_iommu_context_init(struct domain *d, struct iommu_context *ctx, u32 flags);
+int arch_iommu_context_teardown(struct domain *d, struct iommu_context *ctx, u32 flags);
+int arch_iommu_flush_free_queue(struct domain *d, struct iommu_context *ctx);
 
 #endif /* !__ARCH_X86_IOMMU_H__ */
 /*
diff --git a/xen/arch/x86/include/asm/pci.h b/xen/arch/x86/include/asm/pci.h
index fd5480d67d..214c1a0948 100644
--- a/xen/arch/x86/include/asm/pci.h
+++ b/xen/arch/x86/include/asm/pci.h
@@ -15,23 +15,6 @@
 
 struct arch_pci_dev {
     vmask_t used_vectors;
-    /*
-     * These fields are (de)initialized under pcidevs-lock. Other uses of
-     * them don't race (de)initialization and hence don't strictly need any
-     * locking.
-     */
-    union {
-        /* Subset of struct arch_iommu's fields, to be used in dom_io. */
-        struct {
-            uint64_t pgd_maddr;
-        } vtd;
-        struct {
-            struct page_info *root_table;
-        } amd;
-    };
-    domid_t pseudo_domid;
-    mfn_t leaf_mfn;
-    struct page_list_head pgtables_list;
 };
 
 int pci_conf_write_intercept(unsigned int seg, unsigned int bdf,
diff --git a/xen/drivers/passthrough/vtd/Makefile b/xen/drivers/passthrough/vtd/Makefile
index fde7555fac..81e1f46179 100644
--- a/xen/drivers/passthrough/vtd/Makefile
+++ b/xen/drivers/passthrough/vtd/Makefile
@@ -5,4 +5,4 @@ obj-y += dmar.o
 obj-y += utils.o
 obj-y += qinval.o
 obj-y += intremap.o
-obj-y += quirks.o
+obj-y += quirks.o
\ No newline at end of file
diff --git a/xen/drivers/passthrough/vtd/extern.h b/xen/drivers/passthrough/vtd/extern.h
index 667590ee52..c564982489 100644
--- a/xen/drivers/passthrough/vtd/extern.h
+++ b/xen/drivers/passthrough/vtd/extern.h
@@ -45,8 +45,6 @@ void disable_intremap(struct vtd_iommu *iommu);
 int iommu_alloc(struct acpi_drhd_unit *drhd);
 void iommu_free(struct acpi_drhd_unit *drhd);
 
-domid_t did_to_domain_id(const struct vtd_iommu *iommu, unsigned int did);
-
 int iommu_flush_iec_global(struct vtd_iommu *iommu);
 int iommu_flush_iec_index(struct vtd_iommu *iommu, u8 im, u16 iidx);
 void clear_fault_bits(struct vtd_iommu *iommu);
@@ -80,12 +78,10 @@ uint64_t alloc_pgtable_maddr(unsigned long npages, nodeid_t node);
 void free_pgtable_maddr(u64 maddr);
 void *map_vtd_domain_page(u64 maddr);
 void unmap_vtd_domain_page(const void *va);
-int domain_context_mapping_one(struct domain *domain, struct vtd_iommu *iommu,
-                               uint8_t bus, uint8_t devfn,
-                               const struct pci_dev *pdev, domid_t domid,
-                               paddr_t pgd_maddr, unsigned int mode);
-int domain_context_unmap_one(struct domain *domain, struct vtd_iommu *iommu,
-                             uint8_t bus, uint8_t devfn);
+int apply_context_single(struct domain *domain, struct iommu_context *ctx,
+                         struct vtd_iommu *iommu, uint8_t bus, uint8_t devfn);
+int unapply_context_single(struct domain *domain, struct vtd_iommu *iommu,
+                           uint8_t bus, uint8_t devfn);
 int cf_check intel_iommu_get_reserved_device_memory(
     iommu_grdm_t *func, void *ctxt);
 
@@ -106,8 +102,8 @@ void platform_quirks_init(void);
 void vtd_ops_preamble_quirk(struct vtd_iommu *iommu);
 void vtd_ops_postamble_quirk(struct vtd_iommu *iommu);
 int __must_check me_wifi_quirk(struct domain *domain, uint8_t bus,
-                               uint8_t devfn, domid_t domid, paddr_t pgd_maddr,
-                               unsigned int mode);
+                               uint8_t devfn, domid_t domid,
+                               unsigned int mode, struct iommu_context *ctx);
 void pci_vtd_quirk(const struct pci_dev *);
 void quirk_iommu_caps(struct vtd_iommu *iommu);
 
diff --git a/xen/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/vtd/iommu.c
index e13be244c1..6c4ae649d3 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -20,6 +20,7 @@
 
 #include <xen/irq.h>
 #include <xen/sched.h>
+#include <xen/mem_access.h>
 #include <xen/xmalloc.h>
 #include <xen/domain_page.h>
 #include <xen/err.h>
@@ -30,12 +31,20 @@
 #include <xen/time.h>
 #include <xen/pci.h>
 #include <xen/pci_regs.h>
+#include <xen/sched.h>
+#include <xen/event.h>
 #include <xen/keyhandler.h>
+#include <xen/list.h>
+#include <xen/spinlock.h>
+#include <xen/iommu.h>
+#include <xen/lib.h>
 #include <asm/msi.h>
-#include <asm/nops.h>
 #include <asm/irq.h>
 #include <asm/hvm/vmx/vmx.h>
 #include <asm/p2m.h>
+#include <asm/bitops.h>
+#include <asm/iommu.h>
+#include <asm/page.h>
 #include <mach_apic.h>
 #include "iommu.h"
 #include "dmar.h"
@@ -46,14 +55,6 @@
 #define CONTIG_MASK DMA_PTE_CONTIG_MASK
 #include <asm/pt-contig-markers.h>
 
-/* dom_io is used as a sentinel for quarantined devices */
-#define QUARANTINE_SKIP(d, pgd_maddr) ((d) == dom_io && !(pgd_maddr))
-#define DEVICE_DOMID(d, pdev) ((d) != dom_io ? (d)->domain_id \
-                                             : (pdev)->arch.pseudo_domid)
-#define DEVICE_PGTABLE(d, pdev) ((d) != dom_io \
-                                 ? dom_iommu(d)->arch.vtd.pgd_maddr \
-                                 : (pdev)->arch.vtd.pgd_maddr)
-
 bool __read_mostly iommu_igfx = true;
 bool __read_mostly iommu_qinval = true;
 #ifndef iommu_snoop
@@ -66,183 +67,19 @@ static unsigned int __ro_after_init min_pt_levels = UINT_MAX;
 static struct tasklet vtd_fault_tasklet;
 
 static int cf_check setup_hwdom_device(u8 devfn, struct pci_dev *);
-static void setup_hwdom_rmrr(struct domain *d);
-
-static bool domid_mapping(const struct vtd_iommu *iommu)
-{
-    return (const void *)iommu->domid_bitmap != (const void *)iommu->domid_map;
-}
-
-static domid_t convert_domid(const struct vtd_iommu *iommu, domid_t domid)
-{
-    /*
-     * While we need to avoid DID 0 for caching-mode IOMMUs, maintain
-     * the property of the transformation being the same in either
-     * direction. By clipping to 16 bits we ensure that the resulting
-     * DID will fit in the respective context entry field.
-     */
-    BUILD_BUG_ON(DOMID_MASK >= 0xffff);
-
-    return !cap_caching_mode(iommu->cap) ? domid : ~domid;
-}
-
-static int get_iommu_did(domid_t domid, const struct vtd_iommu *iommu,
-                         bool warn)
-{
-    unsigned int nr_dom, i;
-
-    if ( !domid_mapping(iommu) )
-        return convert_domid(iommu, domid);
-
-    nr_dom = cap_ndoms(iommu->cap);
-    i = find_first_bit(iommu->domid_bitmap, nr_dom);
-    while ( i < nr_dom )
-    {
-        if ( iommu->domid_map[i] == domid )
-            return i;
-
-        i = find_next_bit(iommu->domid_bitmap, nr_dom, i + 1);
-    }
-
-    if ( warn )
-        dprintk(XENLOG_ERR VTDPREFIX,
-                "No valid iommu %u domid for Dom%d\n",
-                iommu->index, domid);
-
-    return -1;
-}
 
 #define DID_FIELD_WIDTH 16
 #define DID_HIGH_OFFSET 8
 
-/*
- * This function may have "context" passed as NULL, to merely obtain a DID
- * for "domid".
- */
 static int context_set_domain_id(struct context_entry *context,
                                  domid_t domid, struct vtd_iommu *iommu)
 {
-    unsigned int i;
-
-    ASSERT(pcidevs_locked());
-
-    if ( domid_mapping(iommu) )
-    {
-        unsigned int nr_dom = cap_ndoms(iommu->cap);
-
-        i = find_first_bit(iommu->domid_bitmap, nr_dom);
-        while ( i < nr_dom && iommu->domid_map[i] != domid )
-            i = find_next_bit(iommu->domid_bitmap, nr_dom, i + 1);
-
-        if ( i >= nr_dom )
-        {
-            i = find_first_zero_bit(iommu->domid_bitmap, nr_dom);
-            if ( i >= nr_dom )
-            {
-                dprintk(XENLOG_ERR VTDPREFIX, "IOMMU: no free domain id\n");
-                return -EBUSY;
-            }
-            iommu->domid_map[i] = domid;
-            set_bit(i, iommu->domid_bitmap);
-        }
-    }
-    else
-        i = convert_domid(iommu, domid);
-
-    if ( context )
-    {
-        context->hi &= ~(((1 << DID_FIELD_WIDTH) - 1) << DID_HIGH_OFFSET);
-        context->hi |= (i & ((1 << DID_FIELD_WIDTH) - 1)) << DID_HIGH_OFFSET;
-    }
+    context->hi &= ~(((1 << DID_FIELD_WIDTH) - 1) << DID_HIGH_OFFSET);
+    context->hi |= (domid & ((1 << DID_FIELD_WIDTH) - 1)) << DID_HIGH_OFFSET;
 
     return 0;
 }
 
-static void cleanup_domid_map(domid_t domid, struct vtd_iommu *iommu)
-{
-    int iommu_domid;
-
-    if ( !domid_mapping(iommu) )
-        return;
-
-    iommu_domid = get_iommu_did(domid, iommu, false);
-
-    if ( iommu_domid >= 0 )
-    {
-        /*
-         * Update domid_map[] /before/ domid_bitmap[] to avoid a race with
-         * context_set_domain_id(), setting the slot to DOMID_INVALID for
-         * did_to_domain_id() to return a suitable value while the bit is
-         * still set.
-         */
-        iommu->domid_map[iommu_domid] = DOMID_INVALID;
-        clear_bit(iommu_domid, iommu->domid_bitmap);
-    }
-}
-
-static bool any_pdev_behind_iommu(const struct domain *d,
-                                  const struct pci_dev *exclude,
-                                  const struct vtd_iommu *iommu)
-{
-    const struct pci_dev *pdev;
-
-    for_each_pdev ( d, pdev )
-    {
-        const struct acpi_drhd_unit *drhd;
-
-        if ( pdev == exclude )
-            continue;
-
-        drhd = acpi_find_matched_drhd_unit(pdev);
-        if ( drhd && drhd->iommu == iommu )
-            return true;
-    }
-
-    return false;
-}
-
-/*
- * If no other devices under the same iommu owned by this domain,
- * clear iommu in iommu_bitmap and clear domain_id in domid_bitmap.
- */
-static void check_cleanup_domid_map(const struct domain *d,
-                                    const struct pci_dev *exclude,
-                                    struct vtd_iommu *iommu)
-{
-    bool found;
-
-    if ( d == dom_io )
-        return;
-
-    found = any_pdev_behind_iommu(d, exclude, iommu);
-    /*
-     * Hidden devices are associated with DomXEN but usable by the hardware
-     * domain. Hence they need considering here as well.
-     */
-    if ( !found && is_hardware_domain(d) )
-        found = any_pdev_behind_iommu(dom_xen, exclude, iommu);
-
-    if ( !found )
-    {
-        clear_bit(iommu->index, dom_iommu(d)->arch.vtd.iommu_bitmap);
-        cleanup_domid_map(d->domain_id, iommu);
-    }
-}
-
-domid_t did_to_domain_id(const struct vtd_iommu *iommu, unsigned int did)
-{
-    if ( did >= cap_ndoms(iommu->cap) )
-        return DOMID_INVALID;
-
-    if ( !domid_mapping(iommu) )
-        return convert_domid(iommu, did);
-
-    if ( !test_bit(did, iommu->domid_bitmap) )
-        return DOMID_INVALID;
-
-    return iommu->domid_map[did];
-}
-
 /* Allocate page table, return its machine address */
 uint64_t alloc_pgtable_maddr(unsigned long npages, nodeid_t node)
 {
@@ -312,8 +149,9 @@ static u64 bus_to_context_maddr(struct vtd_iommu *iommu, u8 bus)
  *   PTE for the requested address,
  * - for target == 0 the full PTE contents below PADDR_BITS limit.
  */
-static uint64_t addr_to_dma_page_maddr(struct domain *domain, daddr_t addr,
-                                       unsigned int target,
+static uint64_t addr_to_dma_page_maddr(struct domain *domain,
+                                       struct iommu_context *ctx,
+                                       daddr_t addr, unsigned int target,
                                        unsigned int *flush_flags, bool alloc)
 {
     struct domain_iommu *hd = dom_iommu(domain);
@@ -323,10 +161,9 @@ static uint64_t addr_to_dma_page_maddr(struct domain *domain, daddr_t addr,
     u64 pte_maddr = 0;
 
     addr &= (((u64)1) << addr_width) - 1;
-    ASSERT(spin_is_locked(&hd->arch.mapping_lock));
     ASSERT(target || !alloc);
 
-    if ( !hd->arch.vtd.pgd_maddr )
+    if ( !ctx->arch.vtd.pgd_maddr )
     {
         struct page_info *pg;
 
@@ -334,13 +171,13 @@ static uint64_t addr_to_dma_page_maddr(struct domain *domain, daddr_t addr,
             goto out;
 
         pte_maddr = level;
-        if ( !(pg = iommu_alloc_pgtable(hd, 0)) )
+        if ( !(pg = iommu_alloc_pgtable(hd, ctx, 0)) )
             goto out;
 
-        hd->arch.vtd.pgd_maddr = page_to_maddr(pg);
+        ctx->arch.vtd.pgd_maddr = page_to_maddr(pg);
     }
 
-    pte_maddr = hd->arch.vtd.pgd_maddr;
+    pte_maddr = ctx->arch.vtd.pgd_maddr;
     parent = map_vtd_domain_page(pte_maddr);
     while ( level > target )
     {
@@ -376,7 +213,7 @@ static uint64_t addr_to_dma_page_maddr(struct domain *domain, daddr_t addr,
             }
 
             pte_maddr = level - 1;
-            pg = iommu_alloc_pgtable(hd, DMA_PTE_CONTIG_MASK);
+            pg = iommu_alloc_pgtable(hd, ctx, DMA_PTE_CONTIG_MASK);
             if ( !pg )
                 break;
 
@@ -428,38 +265,25 @@ static uint64_t addr_to_dma_page_maddr(struct domain *domain, daddr_t addr,
     return pte_maddr;
 }
 
-static paddr_t domain_pgd_maddr(struct domain *d, paddr_t pgd_maddr,
-                                unsigned int nr_pt_levels)
+static paddr_t get_context_pgd(struct domain *d, struct iommu_context *ctx,
+                               unsigned int nr_pt_levels)
 {
-    struct domain_iommu *hd = dom_iommu(d);
     unsigned int agaw;
+    paddr_t pgd_maddr = ctx->arch.vtd.pgd_maddr;
 
-    ASSERT(spin_is_locked(&hd->arch.mapping_lock));
-
-    if ( pgd_maddr )
-        /* nothing */;
-    else if ( iommu_use_hap_pt(d) )
+    if ( !ctx->arch.vtd.pgd_maddr )
     {
-        pagetable_t pgt = p2m_get_pagetable(p2m_get_hostp2m(d));
+        /*
+         * Ensure we have pagetables allocated down to the smallest
+         * level the loop below may need to run to.
+         */
+        addr_to_dma_page_maddr(d, ctx, 0, min_pt_levels, NULL, true);
 
-        pgd_maddr = pagetable_get_paddr(pgt);
+        if ( !ctx->arch.vtd.pgd_maddr )
+            return 0;
     }
-    else
-    {
-        if ( !hd->arch.vtd.pgd_maddr )
-        {
-            /*
-             * Ensure we have pagetables allocated down to the smallest
-             * level the loop below may need to run to.
-             */
-            addr_to_dma_page_maddr(d, 0, min_pt_levels, NULL, true);
 
-            if ( !hd->arch.vtd.pgd_maddr )
-                return 0;
-        }
-
-        pgd_maddr = hd->arch.vtd.pgd_maddr;
-    }
+    pgd_maddr = ctx->arch.vtd.pgd_maddr;
 
     /* Skip top level(s) of page tables for less-than-maximum level DRHDs. */
     for ( agaw = level_to_agaw(4);
@@ -727,17 +551,20 @@ static int __must_check iommu_flush_all(void)
     return rc;
 }
 
-static int __must_check cf_check iommu_flush_iotlb(struct domain *d, dfn_t dfn,
+static int __must_check cf_check iommu_flush_iotlb(struct domain *d,
+                                                   struct iommu_context *ctx,
+                                                   dfn_t dfn,
                                                    unsigned long page_count,
                                                    unsigned int flush_flags)
 {
-    struct domain_iommu *hd = dom_iommu(d);
     struct acpi_drhd_unit *drhd;
     struct vtd_iommu *iommu;
     bool flush_dev_iotlb;
     int iommu_domid;
     int ret = 0;
 
+    ASSERT(ctx);
+
     if ( flush_flags & IOMMU_FLUSHF_all )
     {
         dfn = INVALID_DFN;
@@ -759,14 +586,16 @@ static int __must_check cf_check iommu_flush_iotlb(struct domain *d, dfn_t dfn,
 
         iommu = drhd->iommu;
 
-        if ( !test_bit(iommu->index, hd->arch.vtd.iommu_bitmap) )
+        if ( !test_bit(iommu->index, ctx->arch.vtd.iommu_bitmap) )
             continue;
 
-        flush_dev_iotlb = !!find_ats_dev_drhd(iommu);
-        iommu_domid = get_iommu_did(d->domain_id, iommu, !d->is_dying);
+        iommu_domid = ctx->arch.vtd.didmap[iommu->index];
+
         if ( iommu_domid == -1 )
             continue;
 
+        flush_dev_iotlb = !!find_ats_dev_drhd(iommu);
+
         if ( !page_count || (page_count & (page_count - 1)) ||
              dfn_eq(dfn, INVALID_DFN) || !IS_ALIGNED(dfn_x(dfn), page_count) )
             rc = iommu_flush_iotlb_dsi(iommu, iommu_domid,
@@ -784,10 +613,13 @@ static int __must_check cf_check iommu_flush_iotlb(struct domain *d, dfn_t dfn,
             ret = rc;
     }
 
+    if ( !ret && ctx )
+        arch_iommu_flush_free_queue(d, ctx);
+
     return ret;
 }
 
-static void queue_free_pt(struct domain_iommu *hd, mfn_t mfn, unsigned int level)
+static void queue_free_pt(struct iommu_context *ctx, mfn_t mfn, unsigned int level)
 {
     if ( level > 1 )
     {
@@ -796,13 +628,13 @@ static void queue_free_pt(struct domain_iommu *hd, mfn_t mfn, unsigned int level
 
         for ( i = 0; i < PTE_NUM; ++i )
             if ( dma_pte_present(pt[i]) && !dma_pte_superpage(pt[i]) )
-                queue_free_pt(hd, maddr_to_mfn(dma_pte_addr(pt[i])),
+                queue_free_pt(ctx, maddr_to_mfn(dma_pte_addr(pt[i])),
                               level - 1);
 
         unmap_domain_page(pt);
     }
 
-    iommu_queue_free_pgtable(hd, mfn_to_page(mfn));
+    iommu_queue_free_pgtable(ctx, mfn_to_page(mfn));
 }
 
 static int iommu_set_root_entry(struct vtd_iommu *iommu)
@@ -1261,7 +1093,6 @@ int __init iommu_alloc(struct acpi_drhd_unit *drhd)
 {
     struct vtd_iommu *iommu;
     unsigned int sagaw, agaw = 0, nr_dom;
-    domid_t reserved_domid = DOMID_INVALID;
     int rc;
 
     iommu = xzalloc(struct vtd_iommu);
@@ -1350,44 +1181,19 @@ int __init iommu_alloc(struct acpi_drhd_unit *drhd)
     if ( !ecap_coherent(iommu->ecap) )
         iommu_non_coherent = true;
 
-    if ( nr_dom <= DOMID_MASK * 2 + cap_caching_mode(iommu->cap) )
-    {
-        /* Allocate domain id (bit) maps. */
-        iommu->domid_bitmap = xzalloc_array(unsigned long,
-                                            BITS_TO_LONGS(nr_dom));
-        iommu->domid_map = xzalloc_array(domid_t, nr_dom);
-        rc = -ENOMEM;
-        if ( !iommu->domid_bitmap || !iommu->domid_map )
-            goto free;
-
-        /*
-         * If Caching mode is set, then invalid translations are tagged
-         * with domain id 0. Hence reserve bit/slot 0.
-         */
-        if ( cap_caching_mode(iommu->cap) )
-        {
-            iommu->domid_map[0] = DOMID_INVALID;
-            __set_bit(0, iommu->domid_bitmap);
-        }
-    }
-    else
-    {
-        /* Don't leave dangling NULL pointers. */
-        iommu->domid_bitmap = ZERO_BLOCK_PTR;
-        iommu->domid_map = ZERO_BLOCK_PTR;
-
-        /*
-         * If Caching mode is set, then invalid translations are tagged
-         * with domain id 0. Hence reserve the ID taking up bit/slot 0.
-         */
-        reserved_domid = convert_domid(iommu, 0) ?: DOMID_INVALID;
-    }
-
-    iommu->pseudo_domid_map = iommu_init_domid(reserved_domid);
+    /* Allocate domain id (bit) maps. */
+    iommu->domid_bitmap = xzalloc_array(unsigned long, BITS_TO_LONGS(nr_dom));
     rc = -ENOMEM;
-    if ( !iommu->pseudo_domid_map )
+    if ( !iommu->domid_bitmap )
         goto free;
 
+    /*
+        * If Caching mode is set, then invalid translations are tagged
+        * with domain id 0. Hence reserve bit/slot 0.
+        */
+    if ( cap_caching_mode(iommu->cap) )
+        __set_bit(0, iommu->domid_bitmap);
+
     return 0;
 
  free:
@@ -1414,8 +1220,6 @@ void __init iommu_free(struct acpi_drhd_unit *drhd)
         iounmap(iommu->reg);
 
     xfree(iommu->domid_bitmap);
-    xfree(iommu->domid_map);
-    xfree(iommu->pseudo_domid_map);
 
     if ( iommu->msi.irq >= 0 )
         destroy_irq(iommu->msi.irq);
@@ -1433,11 +1237,6 @@ static int cf_check intel_iommu_domain_init(struct domain *d)
 {
     struct domain_iommu *hd = dom_iommu(d);
 
-    hd->arch.vtd.iommu_bitmap = xzalloc_array(unsigned long,
-                                              BITS_TO_LONGS(nr_iommus));
-    if ( !hd->arch.vtd.iommu_bitmap )
-        return -ENOMEM;
-
     hd->arch.vtd.agaw = width_to_agaw(DEFAULT_DOMAIN_ADDRESS_WIDTH);
 
     return 0;
@@ -1448,7 +1247,7 @@ static void __hwdom_init cf_check intel_iommu_hwdom_init(struct domain *d)
     struct acpi_drhd_unit *drhd;
 
     setup_hwdom_pci_devices(d, setup_hwdom_device);
-    setup_hwdom_rmrr(d);
+
     /* Make sure workarounds are applied before enabling the IOMMU(s). */
     arch_iommu_hwdom_init(d);
 
@@ -1465,62 +1264,40 @@ static void __hwdom_init cf_check intel_iommu_hwdom_init(struct domain *d)
     }
 }
 
-/*
- * This function returns
- * - a negative errno value upon error,
- * - zero upon success when previously the entry was non-present, or this isn't
- *   the "main" request for a device (pdev == NULL), or for no-op quarantining
- *   assignments,
- * - positive (one) upon success when previously the entry was present and this
- *   is the "main" request for a device (pdev != NULL).
+/**
+ * Apply a context on a device.
+ * @param domain Domain of the context
+ * @param iommu IOMMU hardware to use (must match device iommu)
+ * @param ctx IOMMU context to apply
+ * @param devfn PCI device function (may be different to pdev)
  */
-int domain_context_mapping_one(
-    struct domain *domain,
-    struct vtd_iommu *iommu,
-    uint8_t bus, uint8_t devfn, const struct pci_dev *pdev,
-    domid_t domid, paddr_t pgd_maddr, unsigned int mode)
+int apply_context_single(struct domain *domain, struct iommu_context *ctx,
+                         struct vtd_iommu *iommu, uint8_t bus, uint8_t devfn)
 {
-    struct domain_iommu *hd = dom_iommu(domain);
     struct context_entry *context, *context_entries, lctxt;
-    __uint128_t old;
+    __uint128_t res, old;
     uint64_t maddr;
-    uint16_t seg = iommu->drhd->segment, prev_did = 0;
-    struct domain *prev_dom = NULL;
+    uint16_t seg = iommu->drhd->segment, prev_did = 0, did;
     int rc, ret;
-    bool flush_dev_iotlb;
-
-    if ( QUARANTINE_SKIP(domain, pgd_maddr) )
-        return 0;
+    bool flush_dev_iotlb, overwrite_entry = false;
 
     ASSERT(pcidevs_locked());
     spin_lock(&iommu->lock);
     maddr = bus_to_context_maddr(iommu, bus);
     context_entries = (struct context_entry *)map_vtd_domain_page(maddr);
     context = &context_entries[devfn];
-    old = (lctxt = *context).full;
+    lctxt = *context;
+    old = lctxt.full;
+
+    did = ctx->arch.vtd.didmap[iommu->index];
 
     if ( context_present(lctxt) )
     {
-        domid_t domid;
-
         prev_did = context_domain_id(lctxt);
-        domid = did_to_domain_id(iommu, prev_did);
-        if ( domid < DOMID_FIRST_RESERVED )
-            prev_dom = rcu_lock_domain_by_id(domid);
-        else if ( pdev ? domid == pdev->arch.pseudo_domid : domid > DOMID_MASK )
-            prev_dom = rcu_lock_domain(dom_io);
-        if ( !prev_dom )
-        {
-            spin_unlock(&iommu->lock);
-            unmap_vtd_domain_page(context_entries);
-            dprintk(XENLOG_DEBUG VTDPREFIX,
-                    "no domain for did %u (nr_dom %u)\n",
-                    prev_did, cap_ndoms(iommu->cap));
-            return -ESRCH;
-        }
+        overwrite_entry = true;
     }
 
-    if ( iommu_hwdom_passthrough && is_hardware_domain(domain) )
+    if ( iommu_hwdom_passthrough && is_hardware_domain(domain) && !ctx->id )
     {
         context_set_translation_type(lctxt, CONTEXT_TT_PASS_THRU);
     }
@@ -1528,16 +1305,10 @@ int domain_context_mapping_one(
     {
         paddr_t root;
 
-        spin_lock(&hd->arch.mapping_lock);
-
-        root = domain_pgd_maddr(domain, pgd_maddr, iommu->nr_pt_levels);
+        root = get_context_pgd(domain, ctx, iommu->nr_pt_levels);
         if ( !root )
         {
-            spin_unlock(&hd->arch.mapping_lock);
-            spin_unlock(&iommu->lock);
             unmap_vtd_domain_page(context_entries);
-            if ( prev_dom )
-                rcu_unlock_domain(prev_dom);
             return -ENOMEM;
         }
 
@@ -1546,98 +1317,39 @@ int domain_context_mapping_one(
             context_set_translation_type(lctxt, CONTEXT_TT_DEV_IOTLB);
         else
             context_set_translation_type(lctxt, CONTEXT_TT_MULTI_LEVEL);
-
-        spin_unlock(&hd->arch.mapping_lock);
     }
 
-    rc = context_set_domain_id(&lctxt, domid, iommu);
+    rc = context_set_domain_id(&lctxt, did, iommu);
     if ( rc )
-    {
-    unlock:
-        spin_unlock(&iommu->lock);
-        unmap_vtd_domain_page(context_entries);
-        if ( prev_dom )
-            rcu_unlock_domain(prev_dom);
-        return rc;
-    }
-
-    if ( !prev_dom )
-    {
-        context_set_address_width(lctxt, level_to_agaw(iommu->nr_pt_levels));
-        context_set_fault_enable(lctxt);
-        context_set_present(lctxt);
-    }
-    else if ( prev_dom == domain )
-    {
-        ASSERT(lctxt.full == context->full);
-        rc = !!pdev;
         goto unlock;
-    }
-    else
-    {
-        ASSERT(context_address_width(lctxt) ==
-               level_to_agaw(iommu->nr_pt_levels));
-        ASSERT(!context_fault_disable(lctxt));
-    }
-
-    if ( cpu_has_cx16 )
-    {
-        __uint128_t res = cmpxchg16b(context, &old, &lctxt.full);
 
-        /*
-         * Hardware does not update the context entry behind our backs,
-         * so the return value should match "old".
-         */
-        if ( res != old )
-        {
-            if ( pdev )
-                check_cleanup_domid_map(domain, pdev, iommu);
-            printk(XENLOG_ERR
-                   "%pp: unexpected context entry %016lx_%016lx (expected %016lx_%016lx)\n",
-                   &PCI_SBDF(seg, bus, devfn),
-                   (uint64_t)(res >> 64), (uint64_t)res,
-                   (uint64_t)(old >> 64), (uint64_t)old);
-            rc = -EILSEQ;
-            goto unlock;
-        }
-    }
-    else if ( !prev_dom || !(mode & MAP_WITH_RMRR) )
-    {
-        context_clear_present(*context);
-        iommu_sync_cache(context, sizeof(*context));
+    context_set_address_width(lctxt, level_to_agaw(iommu->nr_pt_levels));
+    context_set_fault_enable(lctxt);
+    context_set_present(lctxt);
 
-        write_atomic(&context->hi, lctxt.hi);
-        /* No barrier should be needed between these two. */
-        write_atomic(&context->lo, lctxt.lo);
-    }
-    else /* Best effort, updating DID last. */
-    {
-         /*
-          * By non-atomically updating the context entry's DID field last,
-          * during a short window in time TLB entries with the old domain ID
-          * but the new page tables may be inserted.  This could affect I/O
-          * of other devices using this same (old) domain ID.  Such updating
-          * therefore is not a problem if this was the only device associated
-          * with the old domain ID.  Diverting I/O of any of a dying domain's
-          * devices to the quarantine page tables is intended anyway.
-          */
-        if ( !(mode & (MAP_OWNER_DYING | MAP_SINGLE_DEVICE)) )
-            printk(XENLOG_WARNING VTDPREFIX
-                   " %pp: reassignment may cause %pd data corruption\n",
-                   &PCI_SBDF(seg, bus, devfn), prev_dom);
+    res = cmpxchg16b(context, &old, &lctxt.full);
 
-        write_atomic(&context->lo, lctxt.lo);
-        /* No barrier should be needed between these two. */
-        write_atomic(&context->hi, lctxt.hi);
+    /*
+     * Hardware does not update the context entry behind our backs,
+     * so the return value should match "old".
+     */
+    if ( res != old )
+    {
+        printk(XENLOG_ERR
+                "%pp: unexpected context entry %016lx_%016lx (expected %016lx_%016lx)\n",
+                &PCI_SBDF(seg, bus, devfn),
+                (uint64_t)(res >> 64), (uint64_t)res,
+                (uint64_t)(old >> 64), (uint64_t)old);
+        rc = -EILSEQ;
+        goto unlock;
     }
 
     iommu_sync_cache(context, sizeof(struct context_entry));
-    spin_unlock(&iommu->lock);
 
     rc = iommu_flush_context_device(iommu, prev_did, PCI_BDF(bus, devfn),
-                                    DMA_CCMD_MASK_NOBIT, !prev_dom);
+                                    DMA_CCMD_MASK_NOBIT, !overwrite_entry);
     flush_dev_iotlb = !!find_ats_dev_drhd(iommu);
-    ret = iommu_flush_iotlb_dsi(iommu, prev_did, !prev_dom, flush_dev_iotlb);
+    ret = iommu_flush_iotlb_dsi(iommu, prev_did, !overwrite_entry, flush_dev_iotlb);
 
     /*
      * The current logic for returns:
@@ -1653,230 +1365,55 @@ int domain_context_mapping_one(
     if ( rc > 0 )
         rc = 0;
 
-    set_bit(iommu->index, hd->arch.vtd.iommu_bitmap);
+    set_bit(iommu->index, ctx->arch.vtd.iommu_bitmap);
 
     unmap_vtd_domain_page(context_entries);
+    spin_unlock(&iommu->lock);
 
     if ( !seg && !rc )
-        rc = me_wifi_quirk(domain, bus, devfn, domid, pgd_maddr, mode);
-
-    if ( rc && !(mode & MAP_ERROR_RECOVERY) )
-    {
-        if ( !prev_dom ||
-             /*
-              * Unmapping here means DEV_TYPE_PCI devices with RMRRs (if such
-              * exist) would cause problems if such a region was actually
-              * accessed.
-              */
-             (prev_dom == dom_io && !pdev) )
-            ret = domain_context_unmap_one(domain, iommu, bus, devfn);
-        else
-            ret = domain_context_mapping_one(prev_dom, iommu, bus, devfn, pdev,
-                                             DEVICE_DOMID(prev_dom, pdev),
-                                             DEVICE_PGTABLE(prev_dom, pdev),
-                                             (mode & MAP_WITH_RMRR) |
-                                             MAP_ERROR_RECOVERY) < 0;
-
-        if ( !ret && pdev && pdev->devfn == devfn )
-            check_cleanup_domid_map(domain, pdev, iommu);
-    }
+        rc = me_wifi_quirk(domain, bus, devfn, did, 0, ctx);
 
-    if ( prev_dom )
-        rcu_unlock_domain(prev_dom);
+    return rc;
 
-    return rc ?: pdev && prev_dom;
+    unlock:
+        unmap_vtd_domain_page(context_entries);
+        spin_unlock(&iommu->lock);
+        return rc;
 }
 
-static const struct acpi_drhd_unit *domain_context_unmap(
-    struct domain *d, uint8_t devfn, struct pci_dev *pdev);
-
-static int domain_context_mapping(struct domain *domain, u8 devfn,
-                                  struct pci_dev *pdev)
+int apply_context(struct domain *d, struct iommu_context *ctx,
+                  struct pci_dev *pdev, u8 devfn)
 {
     const struct acpi_drhd_unit *drhd = acpi_find_matched_drhd_unit(pdev);
-    const struct acpi_rmrr_unit *rmrr;
-    paddr_t pgd_maddr = DEVICE_PGTABLE(domain, pdev);
-    domid_t orig_domid = pdev->arch.pseudo_domid;
     int ret = 0;
-    unsigned int i, mode = 0;
-    uint16_t seg = pdev->seg, bdf;
-    uint8_t bus = pdev->bus, secbus;
-
-    /*
-     * Generally we assume only devices from one node to get assigned to a
-     * given guest.  But even if not, by replacing the prior value here we
-     * guarantee that at least some basic allocations for the device being
-     * added will get done against its node.  Any further allocations for
-     * this or other devices may be penalized then, but some would also be
-     * if we left other than NUMA_NO_NODE untouched here.
-     */
-    if ( drhd && drhd->iommu->node != NUMA_NO_NODE )
-        dom_iommu(domain)->node = drhd->iommu->node;
-
-    ASSERT(pcidevs_locked());
 
-    for_each_rmrr_device( rmrr, bdf, i )
-    {
-        if ( rmrr->segment != pdev->seg || bdf != pdev->sbdf.bdf )
-            continue;
-
-        mode |= MAP_WITH_RMRR;
-        break;
-    }
+    if ( !drhd )
+        return -EINVAL;
 
-    if ( domain != pdev->domain && pdev->domain != dom_io )
+    if ( pdev->type == DEV_TYPE_PCI_HOST_BRIDGE ||
+         pdev->type == DEV_TYPE_PCIe_BRIDGE ||
+         pdev->type == DEV_TYPE_PCIe2PCI_BRIDGE ||
+         pdev->type == DEV_TYPE_LEGACY_PCI_BRIDGE )
     {
-        if ( pdev->domain->is_dying )
-            mode |= MAP_OWNER_DYING;
-        else if ( drhd &&
-                  !any_pdev_behind_iommu(pdev->domain, pdev, drhd->iommu) &&
-                  !pdev->phantom_stride )
-            mode |= MAP_SINGLE_DEVICE;
+        printk(XENLOG_WARNING VTDPREFIX " Ignoring apply_context on PCI bridge\n");
+        return 0;
     }
 
-    switch ( pdev->type )
-    {
-        bool prev_present;
-
-    case DEV_TYPE_PCI_HOST_BRIDGE:
-        if ( iommu_debug )
-            printk(VTDPREFIX "%pd:Hostbridge: skip %pp map\n",
-                   domain, &PCI_SBDF(seg, bus, devfn));
-        if ( !is_hardware_domain(domain) )
-            return -EPERM;
-        break;
-
-    case DEV_TYPE_PCIe_BRIDGE:
-    case DEV_TYPE_PCIe2PCI_BRIDGE:
-    case DEV_TYPE_LEGACY_PCI_BRIDGE:
-        break;
-
-    case DEV_TYPE_PCIe_ENDPOINT:
-        if ( !drhd )
-            return -ENODEV;
-
-        if ( iommu_quarantine && orig_domid == DOMID_INVALID )
-        {
-            pdev->arch.pseudo_domid =
-                iommu_alloc_domid(drhd->iommu->pseudo_domid_map);
-            if ( pdev->arch.pseudo_domid == DOMID_INVALID )
-                return -ENOSPC;
-        }
-
-        if ( iommu_debug )
-            printk(VTDPREFIX "%pd:PCIe: map %pp\n",
-                   domain, &PCI_SBDF(seg, bus, devfn));
-        ret = domain_context_mapping_one(domain, drhd->iommu, bus, devfn, pdev,
-                                         DEVICE_DOMID(domain, pdev), pgd_maddr,
-                                         mode);
-        if ( ret > 0 )
-            ret = 0;
-        if ( !ret && devfn == pdev->devfn && ats_device(pdev, drhd) > 0 )
-            enable_ats_device(pdev, &drhd->iommu->ats_devices);
-
-        break;
-
-    case DEV_TYPE_PCI:
-        if ( !drhd )
-            return -ENODEV;
-
-        if ( iommu_quarantine && orig_domid == DOMID_INVALID )
-        {
-            pdev->arch.pseudo_domid =
-                iommu_alloc_domid(drhd->iommu->pseudo_domid_map);
-            if ( pdev->arch.pseudo_domid == DOMID_INVALID )
-                return -ENOSPC;
-        }
-
-        if ( iommu_debug )
-            printk(VTDPREFIX "%pd:PCI: map %pp\n",
-                   domain, &PCI_SBDF(seg, bus, devfn));
-
-        ret = domain_context_mapping_one(domain, drhd->iommu, bus, devfn,
-                                         pdev, DEVICE_DOMID(domain, pdev),
-                                         pgd_maddr, mode);
-        if ( ret < 0 )
-            break;
-        prev_present = ret;
-
-        if ( (ret = find_upstream_bridge(seg, &bus, &devfn, &secbus)) < 1 )
-        {
-            if ( !ret )
-                break;
-            ret = -ENXIO;
-        }
-        /*
-         * Strictly speaking if the device is the only one behind this bridge
-         * and the only one with this (secbus,0,0) tuple, it could be allowed
-         * to be re-assigned regardless of RMRR presence.  But let's deal with
-         * that case only if it is actually found in the wild.  Note that
-         * dealing with this just here would still not render the operation
-         * secure.
-         */
-        else if ( prev_present && (mode & MAP_WITH_RMRR) &&
-                  domain != pdev->domain )
-            ret = -EOPNOTSUPP;
-
-        /*
-         * Mapping a bridge should, if anything, pass the struct pci_dev of
-         * that bridge. Since bridges don't normally get assigned to guests,
-         * their owner would be the wrong one. Pass NULL instead.
-         */
-        if ( ret >= 0 )
-            ret = domain_context_mapping_one(domain, drhd->iommu, bus, devfn,
-                                             NULL, DEVICE_DOMID(domain, pdev),
-                                             pgd_maddr, mode);
-
-        /*
-         * Devices behind PCIe-to-PCI/PCIx bridge may generate different
-         * requester-id. It may originate from devfn=0 on the secondary bus
-         * behind the bridge. Map that id as well if we didn't already.
-         *
-         * Somewhat similar as for bridges, we don't want to pass a struct
-         * pci_dev here - there may not even exist one for this (secbus,0,0)
-         * tuple. If there is one, without properly working device groups it
-         * may again not have the correct owner.
-         */
-        if ( !ret && pdev_type(seg, bus, devfn) == DEV_TYPE_PCIe2PCI_BRIDGE &&
-             (secbus != pdev->bus || pdev->devfn != 0) )
-            ret = domain_context_mapping_one(domain, drhd->iommu, secbus, 0,
-                                             NULL, DEVICE_DOMID(domain, pdev),
-                                             pgd_maddr, mode);
-
-        if ( ret )
-        {
-            if ( !prev_present )
-                domain_context_unmap(domain, devfn, pdev);
-            else if ( pdev->domain != domain ) /* Avoid infinite recursion. */
-                domain_context_mapping(pdev->domain, devfn, pdev);
-        }
+    ASSERT(pcidevs_locked());
 
-        break;
+    ret = apply_context_single(d, ctx, drhd->iommu, pdev->bus, devfn);
 
-    default:
-        dprintk(XENLOG_ERR VTDPREFIX, "%pd:unknown(%u): %pp\n",
-                domain, pdev->type, &PCI_SBDF(seg, bus, devfn));
-        ret = -EINVAL;
-        break;
-    }
+    if ( !ret && ats_device(pdev, drhd) > 0 )
+        enable_ats_device(pdev, &drhd->iommu->ats_devices);
 
     if ( !ret && devfn == pdev->devfn )
         pci_vtd_quirk(pdev);
 
-    if ( ret && drhd && orig_domid == DOMID_INVALID )
-    {
-        iommu_free_domid(pdev->arch.pseudo_domid,
-                         drhd->iommu->pseudo_domid_map);
-        pdev->arch.pseudo_domid = DOMID_INVALID;
-    }
-
     return ret;
 }
 
-int domain_context_unmap_one(
-    struct domain *domain,
-    struct vtd_iommu *iommu,
-    uint8_t bus, uint8_t devfn)
+int unapply_context_single(struct domain *domain, struct vtd_iommu *iommu,
+                           uint8_t bus, uint8_t devfn)
 {
     struct context_entry *context, *context_entries;
     u64 maddr;
@@ -1928,8 +1465,8 @@ int domain_context_unmap_one(
     unmap_vtd_domain_page(context_entries);
 
     if ( !iommu->drhd->segment && !rc )
-        rc = me_wifi_quirk(domain, bus, devfn, DOMID_INVALID, 0,
-                           UNMAP_ME_PHANTOM_FUNC);
+        rc = me_wifi_quirk(domain, bus, devfn, DOMID_INVALID, UNMAP_ME_PHANTOM_FUNC,
+                           NULL);
 
     if ( rc && !is_hardware_domain(domain) && domain != dom_io )
     {
@@ -1947,180 +1484,53 @@ int domain_context_unmap_one(
     return rc;
 }
 
-static const struct acpi_drhd_unit *domain_context_unmap(
-    struct domain *domain,
-    uint8_t devfn,
-    struct pci_dev *pdev)
+static void cf_check iommu_clear_root_pgtable(struct domain *d,
+                                              struct iommu_context *ctx)
 {
-    const struct acpi_drhd_unit *drhd = acpi_find_matched_drhd_unit(pdev);
-    struct vtd_iommu *iommu = drhd ? drhd->iommu : NULL;
-    int ret;
-    uint16_t seg = pdev->seg;
-    uint8_t bus = pdev->bus, tmp_bus, tmp_devfn, secbus;
-
-    switch ( pdev->type )
-    {
-    case DEV_TYPE_PCI_HOST_BRIDGE:
-        if ( iommu_debug )
-            printk(VTDPREFIX "%pd:Hostbridge: skip %pp unmap\n",
-                   domain, &PCI_SBDF(seg, bus, devfn));
-        return ERR_PTR(is_hardware_domain(domain) ? 0 : -EPERM);
+    ctx->arch.vtd.pgd_maddr = 0;
+}
 
-    case DEV_TYPE_PCIe_BRIDGE:
-    case DEV_TYPE_PCIe2PCI_BRIDGE:
-    case DEV_TYPE_LEGACY_PCI_BRIDGE:
-        return ERR_PTR(0);
+static void cf_check iommu_domain_teardown(struct domain *d)
+{
+    struct iommu_context *ctx = iommu_default_context(d);
 
-    case DEV_TYPE_PCIe_ENDPOINT:
-        if ( !iommu )
-            return ERR_PTR(-ENODEV);
+    if ( list_empty(&acpi_drhd_units) )
+        return;
 
-        if ( iommu_debug )
-            printk(VTDPREFIX "%pd:PCIe: unmap %pp\n",
-                   domain, &PCI_SBDF(seg, bus, devfn));
-        ret = domain_context_unmap_one(domain, iommu, bus, devfn);
-        if ( !ret && devfn == pdev->devfn && ats_device(pdev, drhd) > 0 )
-            disable_ats_device(pdev);
+    ASSERT(!ctx->arch.vtd.pgd_maddr);
+}
 
-        break;
+static int __must_check cf_check intel_iommu_map_page(
+    struct domain *d, dfn_t dfn, mfn_t mfn, unsigned int flags,
+    unsigned int *flush_flags, struct iommu_context *ctx)
+{
+    struct domain_iommu *hd = dom_iommu(d);
+    struct dma_pte *page, *pte, old, new = {};
+    u64 pg_maddr;
+    unsigned int level = (IOMMUF_order(flags) / LEVEL_STRIDE) + 1;
+    int rc = 0;
 
-    case DEV_TYPE_PCI:
-        if ( !iommu )
-            return ERR_PTR(-ENODEV);
+    ASSERT((hd->platform_ops->page_sizes >> IOMMUF_order(flags)) &
+           PAGE_SIZE_4K);
 
-        if ( iommu_debug )
-            printk(VTDPREFIX "%pd:PCI: unmap %pp\n",
-                   domain, &PCI_SBDF(seg, bus, devfn));
-        ret = domain_context_unmap_one(domain, iommu, bus, devfn);
-        if ( ret )
-            break;
-
-        tmp_bus = bus;
-        tmp_devfn = devfn;
-        if ( (ret = find_upstream_bridge(seg, &tmp_bus, &tmp_devfn,
-                                         &secbus)) < 1 )
-        {
-            if ( ret )
-            {
-                ret = -ENXIO;
-                if ( !domain->is_dying &&
-                     !is_hardware_domain(domain) && domain != dom_io )
-                {
-                    domain_crash(domain);
-                    /* Make upper layers continue in a best effort manner. */
-                    ret = 0;
-                }
-            }
-            break;
-        }
-
-        ret = domain_context_unmap_one(domain, iommu, tmp_bus, tmp_devfn);
-        /* PCIe to PCI/PCIx bridge */
-        if ( !ret && pdev_type(seg, tmp_bus, tmp_devfn) == DEV_TYPE_PCIe2PCI_BRIDGE )
-            ret = domain_context_unmap_one(domain, iommu, secbus, 0);
-
-        break;
-
-    default:
-        dprintk(XENLOG_ERR VTDPREFIX, "%pd:unknown(%u): %pp\n",
-                domain, pdev->type, &PCI_SBDF(seg, bus, devfn));
-        return ERR_PTR(-EINVAL);
-    }
-
-    if ( !ret && pdev->devfn == devfn &&
-         !QUARANTINE_SKIP(domain, pdev->arch.vtd.pgd_maddr) )
-        check_cleanup_domid_map(domain, pdev, iommu);
-
-    return drhd;
-}
-
-static void cf_check iommu_clear_root_pgtable(struct domain *d)
-{
-    struct domain_iommu *hd = dom_iommu(d);
-
-    spin_lock(&hd->arch.mapping_lock);
-    hd->arch.vtd.pgd_maddr = 0;
-    spin_unlock(&hd->arch.mapping_lock);
-}
-
-static void cf_check iommu_domain_teardown(struct domain *d)
-{
-    struct domain_iommu *hd = dom_iommu(d);
-    const struct acpi_drhd_unit *drhd;
-
-    if ( list_empty(&acpi_drhd_units) )
-        return;
-
-    iommu_identity_map_teardown(d);
-
-    ASSERT(!hd->arch.vtd.pgd_maddr);
-
-    for_each_drhd_unit ( drhd )
-        cleanup_domid_map(d->domain_id, drhd->iommu);
-
-    XFREE(hd->arch.vtd.iommu_bitmap);
-}
-
-static void quarantine_teardown(struct pci_dev *pdev,
-                                const struct acpi_drhd_unit *drhd)
-{
-    struct domain_iommu *hd = dom_iommu(dom_io);
-
-    ASSERT(pcidevs_locked());
-
-    if ( !pdev->arch.vtd.pgd_maddr )
-        return;
-
-    ASSERT(page_list_empty(&hd->arch.pgtables.list));
-    page_list_move(&hd->arch.pgtables.list, &pdev->arch.pgtables_list);
-    while ( iommu_free_pgtables(dom_io) == -ERESTART )
-        /* nothing */;
-    pdev->arch.vtd.pgd_maddr = 0;
-
-    if ( drhd )
-        cleanup_domid_map(pdev->arch.pseudo_domid, drhd->iommu);
-}
-
-static int __must_check cf_check intel_iommu_map_page(
-    struct domain *d, dfn_t dfn, mfn_t mfn, unsigned int flags,
-    unsigned int *flush_flags)
-{
-    struct domain_iommu *hd = dom_iommu(d);
-    struct dma_pte *page, *pte, old, new = {};
-    u64 pg_maddr;
-    unsigned int level = (IOMMUF_order(flags) / LEVEL_STRIDE) + 1;
-    int rc = 0;
-
-    ASSERT((hd->platform_ops->page_sizes >> IOMMUF_order(flags)) &
-           PAGE_SIZE_4K);
-
-    /* Do nothing if VT-d shares EPT page table */
-    if ( iommu_use_hap_pt(d) )
-        return 0;
-
-    /* Do nothing if hardware domain and iommu supports pass thru. */
-    if ( iommu_hwdom_passthrough && is_hardware_domain(d) )
-        return 0;
-
-    spin_lock(&hd->arch.mapping_lock);
+    if ( ctx->opaque )
+        return 0;
 
     /*
      * IOMMU mapping request can be safely ignored when the domain is dying.
      *
-     * hd->arch.mapping_lock guarantees that d->is_dying will be observed
+     * hd->lock guarantees that d->is_dying will be observed
      * before any page tables are freed (see iommu_free_pgtables())
      */
     if ( d->is_dying )
     {
-        spin_unlock(&hd->arch.mapping_lock);
         return 0;
     }
 
-    pg_maddr = addr_to_dma_page_maddr(d, dfn_to_daddr(dfn), level, flush_flags,
+    pg_maddr = addr_to_dma_page_maddr(d, ctx, dfn_to_daddr(dfn), level, flush_flags,
                                       true);
     if ( pg_maddr < PAGE_SIZE )
     {
-        spin_unlock(&hd->arch.mapping_lock);
         return -ENOMEM;
     }
 
@@ -2141,7 +1551,6 @@ static int __must_check cf_check intel_iommu_map_page(
 
     if ( !((old.val ^ new.val) & ~DMA_PTE_CONTIG_MASK) )
     {
-        spin_unlock(&hd->arch.mapping_lock);
         unmap_vtd_domain_page(page);
         return 0;
     }
@@ -2170,7 +1579,7 @@ static int __must_check cf_check intel_iommu_map_page(
         new.val &= ~(LEVEL_MASK << level_to_offset_bits(level));
         dma_set_pte_superpage(new);
 
-        pg_maddr = addr_to_dma_page_maddr(d, dfn_to_daddr(dfn), ++level,
+        pg_maddr = addr_to_dma_page_maddr(d, ctx, dfn_to_daddr(dfn), ++level,
                                           flush_flags, false);
         BUG_ON(pg_maddr < PAGE_SIZE);
 
@@ -2180,11 +1589,10 @@ static int __must_check cf_check intel_iommu_map_page(
         iommu_sync_cache(pte, sizeof(*pte));
 
         *flush_flags |= IOMMU_FLUSHF_modified | IOMMU_FLUSHF_all;
-        iommu_queue_free_pgtable(hd, pg);
+        iommu_queue_free_pgtable(ctx, pg);
         perfc_incr(iommu_pt_coalesces);
     }
 
-    spin_unlock(&hd->arch.mapping_lock);
     unmap_vtd_domain_page(page);
 
     *flush_flags |= IOMMU_FLUSHF_added;
@@ -2193,7 +1601,7 @@ static int __must_check cf_check intel_iommu_map_page(
         *flush_flags |= IOMMU_FLUSHF_modified;
 
         if ( IOMMUF_order(flags) && !dma_pte_superpage(old) )
-            queue_free_pt(hd, maddr_to_mfn(dma_pte_addr(old)),
+            queue_free_pt(ctx, maddr_to_mfn(dma_pte_addr(old)),
                           IOMMUF_order(flags) / LEVEL_STRIDE);
     }
 
@@ -2201,7 +1609,8 @@ static int __must_check cf_check intel_iommu_map_page(
 }
 
 static int __must_check cf_check intel_iommu_unmap_page(
-    struct domain *d, dfn_t dfn, unsigned int order, unsigned int *flush_flags)
+    struct domain *d, dfn_t dfn, unsigned int order, unsigned int *flush_flags,
+    struct iommu_context *ctx)
 {
     struct domain_iommu *hd = dom_iommu(d);
     daddr_t addr = dfn_to_daddr(dfn);
@@ -2215,29 +1624,19 @@ static int __must_check cf_check intel_iommu_unmap_page(
      */
     ASSERT((hd->platform_ops->page_sizes >> order) & PAGE_SIZE_4K);
 
-    /* Do nothing if VT-d shares EPT page table */
-    if ( iommu_use_hap_pt(d) )
+    if ( ctx->opaque )
         return 0;
 
-    /* Do nothing if hardware domain and iommu supports pass thru. */
-    if ( iommu_hwdom_passthrough && is_hardware_domain(d) )
-        return 0;
-
-    spin_lock(&hd->arch.mapping_lock);
     /* get target level pte */
-    pg_maddr = addr_to_dma_page_maddr(d, addr, level, flush_flags, false);
+    pg_maddr = addr_to_dma_page_maddr(d, ctx, addr, level, flush_flags, false);
     if ( pg_maddr < PAGE_SIZE )
-    {
-        spin_unlock(&hd->arch.mapping_lock);
         return pg_maddr ? -ENOMEM : 0;
-    }
 
     page = map_vtd_domain_page(pg_maddr);
     pte = &page[address_level_offset(addr, level)];
 
     if ( !dma_pte_present(*pte) )
     {
-        spin_unlock(&hd->arch.mapping_lock);
         unmap_vtd_domain_page(page);
         return 0;
     }
@@ -2255,7 +1654,7 @@ static int __must_check cf_check intel_iommu_unmap_page(
 
         unmap_vtd_domain_page(page);
 
-        pg_maddr = addr_to_dma_page_maddr(d, addr, level, flush_flags, false);
+        pg_maddr = addr_to_dma_page_maddr(d, ctx, addr, level, flush_flags, false);
         BUG_ON(pg_maddr < PAGE_SIZE);
 
         page = map_vtd_domain_page(pg_maddr);
@@ -2264,42 +1663,31 @@ static int __must_check cf_check intel_iommu_unmap_page(
         iommu_sync_cache(pte, sizeof(*pte));
 
         *flush_flags |= IOMMU_FLUSHF_all;
-        iommu_queue_free_pgtable(hd, pg);
+        iommu_queue_free_pgtable(ctx, pg);
         perfc_incr(iommu_pt_coalesces);
     }
 
-    spin_unlock(&hd->arch.mapping_lock);
-
     unmap_vtd_domain_page(page);
 
     *flush_flags |= IOMMU_FLUSHF_modified;
 
     if ( order && !dma_pte_superpage(old) )
-        queue_free_pt(hd, maddr_to_mfn(dma_pte_addr(old)),
+        queue_free_pt(ctx, maddr_to_mfn(dma_pte_addr(old)),
                       order / LEVEL_STRIDE);
 
     return 0;
 }
 
 static int cf_check intel_iommu_lookup_page(
-    struct domain *d, dfn_t dfn, mfn_t *mfn, unsigned int *flags)
+    struct domain *d, dfn_t dfn, mfn_t *mfn, unsigned int *flags,
+    struct iommu_context *ctx)
 {
-    struct domain_iommu *hd = dom_iommu(d);
     uint64_t val;
 
-    /*
-     * If VT-d shares EPT page table or if the domain is the hardware
-     * domain and iommu_passthrough is set then pass back the dfn.
-     */
-    if ( iommu_use_hap_pt(d) ||
-         (iommu_hwdom_passthrough && is_hardware_domain(d)) )
+    if ( ctx->opaque )
         return -EOPNOTSUPP;
 
-    spin_lock(&hd->arch.mapping_lock);
-
-    val = addr_to_dma_page_maddr(d, dfn_to_daddr(dfn), 0, NULL, false);
-
-    spin_unlock(&hd->arch.mapping_lock);
+    val = addr_to_dma_page_maddr(d, ctx, dfn_to_daddr(dfn), 0, NULL, false);
 
     if ( val < PAGE_SIZE )
         return -ENOENT;
@@ -2320,7 +1708,7 @@ static bool __init vtd_ept_page_compatible(const struct vtd_iommu *iommu)
 
     /* EPT is not initialised yet, so we must check the capability in
      * the MSR explicitly rather than use cpu_has_vmx_ept_*() */
-    if ( rdmsr_safe(MSR_IA32_VMX_EPT_VPID_CAP, ept_cap) != 0 ) 
+    if ( rdmsr_safe(MSR_IA32_VMX_EPT_VPID_CAP, ept_cap) != 0 )
         return false;
 
     return (ept_has_2mb(ept_cap) && opt_hap_2mb) <=
@@ -2329,44 +1717,6 @@ static bool __init vtd_ept_page_compatible(const struct vtd_iommu *iommu)
             (cap_sps_1gb(vtd_cap) && iommu_superpages);
 }
 
-static int cf_check intel_iommu_add_device(u8 devfn, struct pci_dev *pdev)
-{
-    struct acpi_rmrr_unit *rmrr;
-    u16 bdf;
-    int ret, i;
-
-    ASSERT(pcidevs_locked());
-
-    if ( !pdev->domain )
-        return -EINVAL;
-
-    for_each_rmrr_device ( rmrr, bdf, i )
-    {
-        if ( rmrr->segment == pdev->seg && bdf == PCI_BDF(pdev->bus, devfn) )
-        {
-            /*
-             * iommu_add_device() is only called for the hardware
-             * domain (see xen/drivers/passthrough/pci.c:pci_add_device()).
-             * Since RMRRs are always reserved in the e820 map for the hardware
-             * domain, there shouldn't be a conflict.
-             */
-            ret = iommu_identity_mapping(pdev->domain, p2m_access_rw,
-                                         rmrr->base_address, rmrr->end_address,
-                                         0);
-            if ( ret )
-                dprintk(XENLOG_ERR VTDPREFIX, "%pd: RMRR mapping failed\n",
-                        pdev->domain);
-        }
-    }
-
-    ret = domain_context_mapping(pdev->domain, devfn, pdev);
-    if ( ret )
-        dprintk(XENLOG_ERR VTDPREFIX, "%pd: context mapping failed\n",
-                pdev->domain);
-
-    return ret;
-}
-
 static int cf_check intel_iommu_enable_device(struct pci_dev *pdev)
 {
     struct acpi_drhd_unit *drhd = acpi_find_matched_drhd_unit(pdev);
@@ -2382,49 +1732,16 @@ static int cf_check intel_iommu_enable_device(struct pci_dev *pdev)
     return ret >= 0 ? 0 : ret;
 }
 
-static int cf_check intel_iommu_remove_device(u8 devfn, struct pci_dev *pdev)
-{
-    const struct acpi_drhd_unit *drhd;
-    struct acpi_rmrr_unit *rmrr;
-    u16 bdf;
-    unsigned int i;
-
-    if ( !pdev->domain )
-        return -EINVAL;
-
-    drhd = domain_context_unmap(pdev->domain, devfn, pdev);
-    if ( IS_ERR(drhd) )
-        return PTR_ERR(drhd);
-
-    for_each_rmrr_device ( rmrr, bdf, i )
-    {
-        if ( rmrr->segment != pdev->seg || bdf != PCI_BDF(pdev->bus, devfn) )
-            continue;
-
-        /*
-         * Any flag is nothing to clear these mappings but here
-         * its always safe and strict to set 0.
-         */
-        iommu_identity_mapping(pdev->domain, p2m_access_x, rmrr->base_address,
-                               rmrr->end_address, 0);
-    }
-
-    quarantine_teardown(pdev, drhd);
-
-    if ( drhd )
-    {
-        iommu_free_domid(pdev->arch.pseudo_domid,
-                         drhd->iommu->pseudo_domid_map);
-        pdev->arch.pseudo_domid = DOMID_INVALID;
-    }
-
-    return 0;
-}
-
 static int __hwdom_init cf_check setup_hwdom_device(
     u8 devfn, struct pci_dev *pdev)
 {
-    return domain_context_mapping(pdev->domain, devfn, pdev);
+    if (pdev->type == DEV_TYPE_PCI_HOST_BRIDGE ||
+        pdev->type == DEV_TYPE_PCIe_BRIDGE ||
+        pdev->type == DEV_TYPE_PCIe2PCI_BRIDGE ||
+        pdev->type == DEV_TYPE_LEGACY_PCI_BRIDGE)
+        return 0;
+
+    return iommu_attach_context(hardware_domain, pdev, 0);
 }
 
 void clear_fault_bits(struct vtd_iommu *iommu)
@@ -2518,7 +1835,7 @@ static int __must_check init_vtd_hw(bool resume)
 
     /*
      * Enable queue invalidation
-     */   
+     */
     for_each_drhd_unit ( drhd )
     {
         iommu = drhd->iommu;
@@ -2539,7 +1856,7 @@ static int __must_check init_vtd_hw(bool resume)
 
     /*
      * Enable interrupt remapping
-     */  
+     */
     if ( iommu_intremap != iommu_intremap_off )
     {
         int apic;
@@ -2594,34 +1911,58 @@ static int __must_check init_vtd_hw(bool resume)
     return iommu_flush_all();
 }
 
-static void __hwdom_init setup_hwdom_rmrr(struct domain *d)
+static struct iommu_state {
+    uint32_t fectl;
+} *__read_mostly iommu_state;
+
+static void arch_iommu_dump_domain_contexts(struct domain *d)
 {
-    struct acpi_rmrr_unit *rmrr;
-    u16 bdf;
-    int ret, i;
+    unsigned int i, iommu_no;
+    struct pci_dev *pdev;
+    struct iommu_context *ctx;
+    struct domain_iommu *hd = dom_iommu(d);
 
-    pcidevs_lock();
-    for_each_rmrr_device ( rmrr, bdf, i )
+    if (d == dom_io)
+        printk("d[IO] contexts\n");
+    else
+        printk("d%hu contexts\n", d->domain_id);
+
+    for (i = 0; i < (1 + hd->other_contexts.count); ++i)
     {
-        /*
-         * Here means we're add a device to the hardware domain.
-         * Since RMRRs are always reserved in the e820 map for the hardware
-         * domain, there shouldn't be a conflict. So its always safe and
-         * strict to set 0.
-         */
-        ret = iommu_identity_mapping(d, p2m_access_rw, rmrr->base_address,
-                                     rmrr->end_address, 0);
-        if ( ret )
-            dprintk(XENLOG_ERR VTDPREFIX,
-                     "IOMMU: mapping reserved region failed\n");
+        if ( (ctx = iommu_get_context(d, i)) )
+        {
+            printk(" Context %d (%"PRIx64")\n", i, ctx->arch.vtd.pgd_maddr);
+
+            for (iommu_no = 0; iommu_no < nr_iommus; iommu_no++)
+                printk("  IOMMU %hu (used=%u; did=%hu)\n", iommu_no,
+                       test_bit(iommu_no, ctx->arch.vtd.iommu_bitmap),
+                       ctx->arch.vtd.didmap[iommu_no]);
+
+            list_for_each_entry(pdev, &ctx->devices, context_list)
+            {
+                printk("  - %pp\n", &pdev->sbdf);
+            }
+
+            iommu_put_context(ctx);
+        }
     }
-    pcidevs_unlock();
 }
 
-static struct iommu_state {
-    uint32_t fectl;
-} *__read_mostly iommu_state;
+static void arch_iommu_dump_contexts(unsigned char key)
+{
+    struct domain *d;
+
+    for_each_domain(d)
+        if (is_iommu_enabled(d)) {
+            struct domain_iommu *hd = dom_iommu(d);
+            printk("d%hu arena page usage: %d\n", d->domain_id,
+                atomic_read(&hd->arch.pt_arena.used_pages));
 
+            arch_iommu_dump_domain_contexts(d);
+        }
+
+    arch_iommu_dump_domain_contexts(dom_io);
+}
 static int __init cf_check vtd_setup(void)
 {
     struct acpi_drhd_unit *drhd;
@@ -2749,6 +2090,7 @@ static int __init cf_check vtd_setup(void)
     iommu_ops.page_sizes |= large_sizes;
 
     register_keyhandler('V', vtd_dump_iommu_info, "dump iommu info", 1);
+    register_keyhandler('X', arch_iommu_dump_contexts, "dump iommu contexts", 1);
 
     return 0;
 
@@ -2763,192 +2105,6 @@ static int __init cf_check vtd_setup(void)
     return ret;
 }
 
-static int cf_check reassign_device_ownership(
-    struct domain *source,
-    struct domain *target,
-    u8 devfn, struct pci_dev *pdev)
-{
-    int ret;
-
-    if ( !QUARANTINE_SKIP(target, pdev->arch.vtd.pgd_maddr) )
-    {
-        if ( !has_arch_pdevs(target) )
-            vmx_pi_hooks_assign(target);
-
-#ifdef CONFIG_PV
-        /*
-         * Devices assigned to untrusted domains (here assumed to be any domU)
-         * can attempt to send arbitrary LAPIC/MSI messages. We are unprotected
-         * by the root complex unless interrupt remapping is enabled.
-         */
-        if ( !iommu_intremap && !is_hardware_domain(target) &&
-             !is_system_domain(target) )
-            untrusted_msi = true;
-#endif
-
-        ret = domain_context_mapping(target, devfn, pdev);
-
-        if ( !ret && pdev->devfn == devfn &&
-             !QUARANTINE_SKIP(source, pdev->arch.vtd.pgd_maddr) )
-        {
-            const struct acpi_drhd_unit *drhd = acpi_find_matched_drhd_unit(pdev);
-
-            if ( drhd )
-                check_cleanup_domid_map(source, pdev, drhd->iommu);
-        }
-    }
-    else
-    {
-        const struct acpi_drhd_unit *drhd;
-
-        drhd = domain_context_unmap(source, devfn, pdev);
-        ret = IS_ERR(drhd) ? PTR_ERR(drhd) : 0;
-    }
-    if ( ret )
-    {
-        if ( !has_arch_pdevs(target) )
-            vmx_pi_hooks_deassign(target);
-        return ret;
-    }
-
-    if ( devfn == pdev->devfn && pdev->domain != target )
-    {
-        write_lock(&source->pci_lock);
-        list_del(&pdev->domain_list);
-        write_unlock(&source->pci_lock);
-
-        pdev->domain = target;
-
-        write_lock(&target->pci_lock);
-        list_add(&pdev->domain_list, &target->pdev_list);
-        write_unlock(&target->pci_lock);
-    }
-
-    if ( !has_arch_pdevs(source) )
-        vmx_pi_hooks_deassign(source);
-
-    /*
-     * If the device belongs to the hardware domain, and it has RMRR, don't
-     * remove it from the hardware domain, because BIOS may use RMRR at
-     * booting time.
-     */
-    if ( !is_hardware_domain(source) )
-    {
-        const struct acpi_rmrr_unit *rmrr;
-        u16 bdf;
-        unsigned int i;
-
-        for_each_rmrr_device( rmrr, bdf, i )
-            if ( rmrr->segment == pdev->seg &&
-                 bdf == PCI_BDF(pdev->bus, devfn) )
-            {
-                /*
-                 * Any RMRR flag is always ignored when remove a device,
-                 * but its always safe and strict to set 0.
-                 */
-                ret = iommu_identity_mapping(source, p2m_access_x,
-                                             rmrr->base_address,
-                                             rmrr->end_address, 0);
-                if ( ret && ret != -ENOENT )
-                    return ret;
-            }
-    }
-
-    return 0;
-}
-
-static int cf_check intel_iommu_assign_device(
-    struct domain *d, u8 devfn, struct pci_dev *pdev, u32 flag)
-{
-    struct domain *s = pdev->domain;
-    struct acpi_rmrr_unit *rmrr;
-    int ret = 0, i;
-    u16 bdf, seg;
-    u8 bus;
-
-    if ( list_empty(&acpi_drhd_units) )
-        return -ENODEV;
-
-    seg = pdev->seg;
-    bus = pdev->bus;
-    /*
-     * In rare cases one given rmrr is shared by multiple devices but
-     * obviously this would put the security of a system at risk. So
-     * we would prevent from this sort of device assignment. But this
-     * can be permitted if user set
-     *      "pci = [ 'sbdf, rdm_policy=relaxed' ]"
-     *
-     * TODO: in the future we can introduce group device assignment
-     * interface to make sure devices sharing RMRR are assigned to the
-     * same domain together.
-     */
-    for_each_rmrr_device( rmrr, bdf, i )
-    {
-        if ( rmrr->segment == seg && bdf == PCI_BDF(bus, devfn) &&
-             rmrr->scope.devices_cnt > 1 )
-        {
-            bool relaxed = flag & XEN_DOMCTL_DEV_RDM_RELAXED;
-
-            printk(XENLOG_GUEST "%s" VTDPREFIX
-                   " It's %s to assign %pp"
-                   " with shared RMRR at %"PRIx64" for %pd.\n",
-                   relaxed ? XENLOG_WARNING : XENLOG_ERR,
-                   relaxed ? "risky" : "disallowed",
-                   &PCI_SBDF(seg, bus, devfn), rmrr->base_address, d);
-            if ( !relaxed )
-                return -EPERM;
-        }
-    }
-
-    if ( d == dom_io )
-        return reassign_device_ownership(s, d, devfn, pdev);
-
-    /* Setup rmrr identity mapping */
-    for_each_rmrr_device( rmrr, bdf, i )
-    {
-        if ( rmrr->segment == seg && bdf == PCI_BDF(bus, devfn) )
-        {
-            ret = iommu_identity_mapping(d, p2m_access_rw, rmrr->base_address,
-                                         rmrr->end_address, flag);
-            if ( ret )
-            {
-                printk(XENLOG_G_ERR VTDPREFIX
-                       "%pd: cannot map reserved region [%"PRIx64",%"PRIx64"]: %d\n",
-                       d, rmrr->base_address, rmrr->end_address, ret);
-                break;
-            }
-        }
-    }
-
-    if ( !ret )
-        ret = reassign_device_ownership(s, d, devfn, pdev);
-
-    /* See reassign_device_ownership() for the hwdom aspect. */
-    if ( !ret || is_hardware_domain(d) )
-        return ret;
-
-    for_each_rmrr_device( rmrr, bdf, i )
-    {
-        if ( rmrr->segment == seg && bdf == PCI_BDF(bus, devfn) )
-        {
-            int rc = iommu_identity_mapping(d, p2m_access_x,
-                                            rmrr->base_address,
-                                            rmrr->end_address, 0);
-
-            if ( rc && rc != -ENOENT )
-            {
-                printk(XENLOG_ERR VTDPREFIX
-                       "%pd: cannot unmap reserved region [%"PRIx64",%"PRIx64"]: %d\n",
-                       d, rmrr->base_address, rmrr->end_address, rc);
-                domain_crash(d);
-                break;
-            }
-        }
-    }
-
-    return ret;
-}
-
 static int cf_check intel_iommu_group_id(u16 seg, u8 bus, u8 devfn)
 {
     u8 secbus;
@@ -3073,6 +2229,11 @@ static void vtd_dump_page_table_level(paddr_t pt_maddr, int level, paddr_t gpa,
     if ( level < 1 )
         return;
 
+    if (pt_maddr == 0) {
+        printk(" (empty)\n");
+        return;
+    }
+
     pt_vaddr = map_vtd_domain_page(pt_maddr);
 
     next_level = level - 1;
@@ -3103,158 +2264,364 @@ static void vtd_dump_page_table_level(paddr_t pt_maddr, int level, paddr_t gpa,
 
 static void cf_check vtd_dump_page_tables(struct domain *d)
 {
-    const struct domain_iommu *hd = dom_iommu(d);
+    struct domain_iommu *hd = dom_iommu(d);
+    unsigned int i;
 
-    printk(VTDPREFIX" %pd table has %d levels\n", d,
+    printk(VTDPREFIX " %pd table has %d levels\n", d,
            agaw_to_level(hd->arch.vtd.agaw));
-    vtd_dump_page_table_level(hd->arch.vtd.pgd_maddr,
-                              agaw_to_level(hd->arch.vtd.agaw), 0, 0);
+
+    for (i = 1; i < (1 + hd->other_contexts.count); ++i)
+    {
+        struct iommu_context *ctx = iommu_get_context(d, i);
+
+        printk(VTDPREFIX " %pd context %d: %s\n", d, i,
+               ctx ? "allocated" : "non-allocated");
+
+        if (ctx)
+        {
+            vtd_dump_page_table_level(ctx->arch.vtd.pgd_maddr,
+                                      agaw_to_level(hd->arch.vtd.agaw), 0, 0);
+            iommu_put_context(ctx);
+        }
+    }
 }
 
-static int fill_qpt(struct dma_pte *this, unsigned int level,
-                    struct page_info *pgs[6])
+static int cf_check intel_iommu_context_init(struct domain *d,
+                                             struct iommu_context *ctx, u32 flags)
 {
-    struct domain_iommu *hd = dom_iommu(dom_io);
-    unsigned int i;
-    int rc = 0;
+    struct acpi_drhd_unit *drhd;
+
+    ctx->arch.vtd.didmap = xzalloc_array(u16, nr_iommus);
+
+    if ( !ctx->arch.vtd.didmap )
+        return -ENOMEM;
 
-    for ( i = 0; !rc && i < PTE_NUM; ++i )
+    ctx->arch.vtd.iommu_bitmap = xzalloc_array(unsigned long,
+                                               BITS_TO_LONGS(nr_iommus));
+    if ( !ctx->arch.vtd.iommu_bitmap )
+        return -ENOMEM;
+
+    ctx->arch.vtd.superpage_progress = 0;
+
+    if ( flags & IOMMU_CONTEXT_INIT_default )
     {
-        struct dma_pte *pte = &this[i], *next;
+        ctx->arch.vtd.pgd_maddr = 0;
 
-        if ( !dma_pte_present(*pte) )
+        /*
+         * Context is considered "opaque" (non-managed) in these cases :
+         *  - HAP is enabled, in this case, the pagetable is not managed by the
+         *    IOMMU code, thus opaque
+         *  - IOMMU is in passthrough which means that there is no actual pagetable
+         *
+         * If no-dma mode is specified, it's always non-opaque as the pagetable is
+         * always managed regardless of the rest.
+         */
+        ctx->opaque = iommu_use_hap_pt(d);
+
+        /* no-dma mode implies not sharing hap. */
+        if (is_hardware_domain(d) && iommu_hwdom_no_dma)
+            ctx->opaque = false;
+    }
+
+    // TODO: Allocate IOMMU domid only when attaching devices ?
+    /* Populate context DID map using pseudo DIDs */
+    for_each_drhd_unit(drhd)
+    {
+        ctx->arch.vtd.didmap[drhd->iommu->index] =
+            iommu_alloc_domid(drhd->iommu->domid_bitmap);
+    }
+
+    if ( !ctx->opaque )
+        /* Create initial context page */
+        addr_to_dma_page_maddr(d, ctx, 0, min_pt_levels, NULL, true);
+
+    return arch_iommu_context_init(d, ctx, flags);
+}
+
+static int intel_iommu_cleanup_pte(uint64_t pte_maddr, bool preempt)
+{
+    size_t i;
+    struct dma_pte *pte = map_vtd_domain_page(pte_maddr);
+
+    for (i = 0; i < (1 << PAGETABLE_ORDER); ++i)
+        if ( dma_pte_present(pte[i]) )
         {
-            if ( !pgs[level] )
-            {
-                /*
-                 * The pgtable allocator is fine for the leaf page, as well as
-                 * page table pages, and the resulting allocations are always
-                 * zeroed.
-                 */
-                pgs[level] = iommu_alloc_pgtable(hd, 0);
-                if ( !pgs[level] )
-                {
-                    rc = -ENOMEM;
-                    break;
-                }
-
-                if ( level )
-                {
-                    next = map_vtd_domain_page(page_to_maddr(pgs[level]));
-                    rc = fill_qpt(next, level - 1, pgs);
-                    unmap_vtd_domain_page(next);
-                }
-            }
+            /* Remove the reference of the target mapping (if needed) */
+            mfn_t mfn = maddr_to_mfn(dma_pte_addr(pte[i]));
+
+            if ( mfn_valid(mfn) )
+                put_page(mfn_to_page(mfn));
 
-            dma_set_pte_addr(*pte, page_to_maddr(pgs[level]));
-            dma_set_pte_readable(*pte);
-            dma_set_pte_writable(*pte);
+            if ( preempt )
+                dma_clear_pte(pte[i]);
         }
-        else if ( level && !dma_pte_superpage(*pte) )
+
+    unmap_vtd_domain_page(pte);
+
+    return 0;
+}
+
+/**
+ * Cleanup logic :
+ * Walk through the entire page table, progressively removing mappings if preempt.
+ *
+ * Return values :
+ *  - Report preemption with -ERESTART.
+ *  - Report empty pte/pgd with 0.
+ *
+ * When preempted during superpage operation, store state in vtd.superpage_progress.
+ */
+
+static int intel_iommu_cleanup_superpage(struct iommu_context *ctx,
+                                          unsigned int page_order, uint64_t pte_maddr,
+                                          bool preempt)
+{
+    size_t i = 0, page_count = 1 << page_order;
+    struct page_info *page = maddr_to_page(pte_maddr);
+
+    if ( preempt )
+        i = ctx->arch.vtd.superpage_progress;
+
+    for (; i < page_count; page++)
+    {
+        put_page(page);
+
+        if ( preempt && (i & 0xff) && general_preempt_check() )
         {
-            next = map_vtd_domain_page(dma_pte_addr(*pte));
-            rc = fill_qpt(next, level - 1, pgs);
-            unmap_vtd_domain_page(next);
+            ctx->arch.vtd.superpage_progress = i + 1;
+            return -ERESTART;
         }
     }
 
-    return rc;
+    if ( preempt )
+        ctx->arch.vtd.superpage_progress = 0;
+
+    return 0;
 }
 
-static int cf_check intel_iommu_quarantine_init(struct pci_dev *pdev,
-                                                bool scratch_page)
+static int intel_iommu_cleanup_mappings(struct iommu_context *ctx,
+                                         unsigned int nr_pt_levels, uint64_t pgd_maddr,
+                                         bool preempt)
 {
-    struct domain_iommu *hd = dom_iommu(dom_io);
-    struct page_info *pg;
-    unsigned int agaw = hd->arch.vtd.agaw;
-    unsigned int level = agaw_to_level(agaw);
-    const struct acpi_drhd_unit *drhd;
-    const struct acpi_rmrr_unit *rmrr;
-    unsigned int i, bdf;
-    bool rmrr_found = false;
+    size_t i;
     int rc;
+    struct dma_pte *pgd;
 
-    ASSERT(pcidevs_locked());
-    ASSERT(!hd->arch.vtd.pgd_maddr);
-    ASSERT(page_list_empty(&hd->arch.pgtables.list));
+    if ( ctx->opaque )
+        /* don't touch opaque contexts */
+        return 0;
 
-    if ( pdev->arch.vtd.pgd_maddr )
+    pgd = map_vtd_domain_page(pgd_maddr);
+
+    for (i = 0; i < (1 << PAGETABLE_ORDER); ++i)
     {
-        clear_domain_page(pdev->arch.leaf_mfn);
-        return 0;
+        if ( dma_pte_present(pgd[i]) )
+        {
+            uint64_t pte_maddr = dma_pte_addr(pgd[i]);
+
+            if ( dma_pte_superpage(pgd[i]) )
+                rc = intel_iommu_cleanup_superpage(ctx, nr_pt_levels * SUPERPAGE_ORDER,
+                                                   pte_maddr, preempt);
+            else if ( nr_pt_levels > 2 )
+                /* Next level is not PTE */
+                rc = intel_iommu_cleanup_mappings(ctx, nr_pt_levels - 1,
+                                                  pte_maddr, preempt);
+            else
+                rc = intel_iommu_cleanup_pte(pte_maddr, preempt);
+
+            if ( preempt && !rc )
+                /* Fold pgd (no more mappings in it) */
+                dma_clear_pte(pgd[i]);
+            else if ( preempt && (rc == -ERESTART || general_preempt_check()) )
+            {
+                unmap_vtd_domain_page(pgd);
+                return -ERESTART;
+            }
+        }
     }
 
-    drhd = acpi_find_matched_drhd_unit(pdev);
-    if ( !drhd )
-        return -ENODEV;
+    unmap_vtd_domain_page(pgd);
 
-    pg = iommu_alloc_pgtable(hd, 0);
-    if ( !pg )
-        return -ENOMEM;
+    return 0;
+}
 
-    rc = context_set_domain_id(NULL, pdev->arch.pseudo_domid, drhd->iommu);
+static int cf_check intel_iommu_context_teardown(struct domain *d,
+                                        struct iommu_context *ctx, u32 flags)
+{
+    struct acpi_drhd_unit *drhd;
+    pcidevs_lock();
+
+    // Cleanup mappings
+    if ( intel_iommu_cleanup_mappings(ctx, agaw_to_level(d->iommu.arch.vtd.agaw),
+                                      ctx->arch.vtd.pgd_maddr,
+                                      flags & IOMMUF_preempt) < 0 )
+    {
+        pcidevs_unlock();
+        return -ERESTART;
+    }
 
-    /* Transiently install the root into DomIO, for iommu_identity_mapping(). */
-    hd->arch.vtd.pgd_maddr = page_to_maddr(pg);
+    ASSERT(ctx->arch.vtd.didmap);
 
-    for_each_rmrr_device ( rmrr, bdf, i )
+    for_each_drhd_unit(drhd)
     {
-        if ( rc )
-            break;
+        unsigned long index = drhd->iommu->index;
 
-        if ( rmrr->segment == pdev->seg && bdf == pdev->sbdf.bdf )
+        if ( test_bit(index, ctx->arch.vtd.iommu_bitmap) )
+            iommu_free_domid(ctx->arch.vtd.didmap[index], drhd->iommu->domid_bitmap);
+    }
+
+    xfree(ctx->arch.vtd.didmap);
+
+    pcidevs_unlock();
+    return arch_iommu_context_teardown(d, ctx, flags);
+}
+
+static int intel_iommu_dev_rmrr(struct domain *d, struct pci_dev *pdev,
+                                struct iommu_context *ctx, bool unmap)
+{
+    struct acpi_rmrr_unit *rmrr;
+    u16 bdf;
+    int ret, i;
+
+    for_each_rmrr_device(rmrr, bdf, i)
+    {
+        if ( PCI_SBDF(rmrr->segment, bdf).sbdf == pdev->sbdf.sbdf )
         {
-            rmrr_found = true;
-
-            rc = iommu_identity_mapping(dom_io, p2m_access_rw,
-                                        rmrr->base_address, rmrr->end_address,
-                                        0);
-            if ( rc )
-                printk(XENLOG_ERR VTDPREFIX
-                       "%pp: RMRR quarantine mapping failed\n",
-                       &pdev->sbdf);
+            ret = iommu_identity_mapping(d, ctx,
+                                         unmap ? p2m_access_x : p2m_access_rw,
+                                         rmrr->base_address, rmrr->end_address,
+                                         0);
+
+            if ( ret < 0 )
+                return ret;
         }
     }
 
-    iommu_identity_map_teardown(dom_io);
-    hd->arch.vtd.pgd_maddr = 0;
-    pdev->arch.vtd.pgd_maddr = page_to_maddr(pg);
+    return 0;
+}
 
-    if ( !rc && scratch_page )
-    {
-        struct dma_pte *root;
-        struct page_info *pgs[6] = {};
+static int cf_check intel_iommu_attach(struct domain *d, struct pci_dev *pdev,
+                                       struct iommu_context *ctx)
+{
+    int ret;
+    const struct acpi_drhd_unit *drhd = acpi_find_matched_drhd_unit(pdev);
 
-        root = map_vtd_domain_page(pdev->arch.vtd.pgd_maddr);
-        rc = fill_qpt(root, level - 1, pgs);
-        unmap_vtd_domain_page(root);
+    if (!pdev || !drhd)
+        return -EINVAL;
+
+    if ( !ctx->opaque )
+    {
+        ret = intel_iommu_dev_rmrr(d, pdev, ctx, false);
 
-        pdev->arch.leaf_mfn = page_to_mfn(pgs[0]);
+        if ( ret )
+            return ret;
     }
 
-    page_list_move(&pdev->arch.pgtables_list, &hd->arch.pgtables.list);
+    ret = apply_context(d, ctx, pdev, pdev->devfn);
+
+    if ( ret )
+        return ret;
 
-    if ( rc || (!scratch_page && !rmrr_found) )
-        quarantine_teardown(pdev, drhd);
+    pci_vtd_quirk(pdev);
 
-    return rc;
+    return ret;
+}
+
+static int cf_check intel_iommu_detach(struct domain *d, struct pci_dev *pdev,
+                                       struct iommu_context *prev_ctx)
+{
+    int ret;
+    const struct acpi_drhd_unit *drhd = acpi_find_matched_drhd_unit(pdev);
+
+    if (!pdev || !drhd)
+        return -EINVAL;
+
+    ret = unapply_context_single(d, drhd->iommu, pdev->bus, pdev->devfn);
+
+    if ( ret )
+        return ret;
+
+    if ( !prev_ctx->opaque )
+        WARN_ON(intel_iommu_dev_rmrr(d, pdev, prev_ctx, true));
+
+    return ret;
+}
+
+static int cf_check intel_iommu_reattach(struct domain *d,
+                                         struct pci_dev *pdev,
+                                         struct iommu_context *prev_ctx,
+                                         struct iommu_context *ctx)
+{
+    int ret;
+    const struct acpi_drhd_unit *drhd = acpi_find_matched_drhd_unit(pdev);
+
+    if (!pdev || !drhd)
+        return -EINVAL;
+
+    ret = intel_iommu_dev_rmrr(d, pdev, ctx, false);
+
+    if ( ret )
+        return ret;
+
+    ret = apply_context_single(d, ctx, drhd->iommu, pdev->bus, pdev->devfn);
+
+    if ( ret )
+        return ret;
+
+    WARN_ON(intel_iommu_dev_rmrr(d, pdev, prev_ctx, true));
+
+    pci_vtd_quirk(pdev);
+
+    return ret;
+}
+
+static int cf_check intel_iommu_add_devfn(struct domain *d,
+                                          struct pci_dev *pdev, u16 devfn,
+                                          struct iommu_context *ctx)
+{
+    const struct acpi_drhd_unit *drhd = acpi_find_matched_drhd_unit(pdev);
+
+    if (!pdev || !drhd)
+        return -EINVAL;
+
+    return apply_context(d, ctx, pdev, devfn);
+}
+
+static int cf_check intel_iommu_remove_devfn(struct domain *d, struct pci_dev *pdev,
+                                             u16 devfn)
+{
+    const struct acpi_drhd_unit *drhd = acpi_find_matched_drhd_unit(pdev);
+
+    if (!pdev || !drhd)
+        return -EINVAL;
+
+    return unapply_context_single(d, drhd->iommu, pdev->bus, devfn);
+}
+
+static uint64_t cf_check intel_iommu_get_max_iova(struct domain *d)
+{
+    struct domain_iommu *hd = dom_iommu(d);
+
+    return (1LLU << agaw_to_width(hd->arch.vtd.agaw)) - 1;
 }
 
 static const struct iommu_ops __initconst_cf_clobber vtd_ops = {
     .page_sizes = PAGE_SIZE_4K,
     .init = intel_iommu_domain_init,
     .hwdom_init = intel_iommu_hwdom_init,
-    .quarantine_init = intel_iommu_quarantine_init,
-    .add_device = intel_iommu_add_device,
+    .context_init = intel_iommu_context_init,
+    .context_teardown = intel_iommu_context_teardown,
+    .attach = intel_iommu_attach,
+    .detach = intel_iommu_detach,
+    .reattach = intel_iommu_reattach,
+    .add_devfn = intel_iommu_add_devfn,
+    .remove_devfn = intel_iommu_remove_devfn,
     .enable_device = intel_iommu_enable_device,
-    .remove_device = intel_iommu_remove_device,
-    .assign_device  = intel_iommu_assign_device,
     .teardown = iommu_domain_teardown,
     .clear_root_pgtable = iommu_clear_root_pgtable,
     .map_page = intel_iommu_map_page,
     .unmap_page = intel_iommu_unmap_page,
     .lookup_page = intel_iommu_lookup_page,
-    .reassign_device = reassign_device_ownership,
     .get_device_group_id = intel_iommu_group_id,
     .enable_x2apic = intel_iommu_enable_eim,
     .disable_x2apic = intel_iommu_disable_eim,
@@ -3269,6 +2636,7 @@ static const struct iommu_ops __initconst_cf_clobber vtd_ops = {
     .iotlb_flush = iommu_flush_iotlb,
     .get_reserved_device_memory = intel_iommu_get_reserved_device_memory,
     .dump_page_tables = vtd_dump_page_tables,
+    .get_max_iova = intel_iommu_get_max_iova,
 };
 
 const struct iommu_init_ops __initconstrel intel_iommu_init_ops = {
diff --git a/xen/drivers/passthrough/vtd/iommu.h b/xen/drivers/passthrough/vtd/iommu.h
index 78aa8a96f5..48b5900d49 100644
--- a/xen/drivers/passthrough/vtd/iommu.h
+++ b/xen/drivers/passthrough/vtd/iommu.h
@@ -104,7 +104,7 @@
 #define DMA_TLB_GLOBAL_FLUSH (((u64)1) << 60)
 #define DMA_TLB_DSI_FLUSH (((u64)2) << 60)
 #define DMA_TLB_PSI_FLUSH (((u64)3) << 60)
-#define DMA_TLB_IIRG(x) (((x) >> 60) & 7) 
+#define DMA_TLB_IIRG(x) (((x) >> 60) & 7)
 #define DMA_TLB_IAIG(val) (((val) >> 57) & 7)
 #define DMA_TLB_DID(x) (((uint64_t)((x) & 0xffff)) << 32)
 
@@ -506,9 +506,7 @@ struct vtd_iommu {
     } flush;
 
     struct list_head ats_devices;
-    unsigned long *pseudo_domid_map; /* "pseudo" domain id bitmap */
     unsigned long *domid_bitmap;  /* domain id bitmap */
-    domid_t *domid_map;           /* domain id mapping array */
     uint32_t version;
 };
 
diff --git a/xen/drivers/passthrough/vtd/qinval.c b/xen/drivers/passthrough/vtd/qinval.c
index 036f3e8505..3f25b6a2e0 100644
--- a/xen/drivers/passthrough/vtd/qinval.c
+++ b/xen/drivers/passthrough/vtd/qinval.c
@@ -229,7 +229,7 @@ static int __must_check dev_invalidate_sync(struct vtd_iommu *iommu,
     rc = queue_invalidate_wait(iommu, 0, 1, 1, 1);
     if ( rc == -ETIMEDOUT && !pdev->broken )
     {
-        struct domain *d = rcu_lock_domain_by_id(did_to_domain_id(iommu, did));
+        struct domain *d = rcu_lock_domain(pdev->domain);
 
         /*
          * In case the domain has been freed or the IOMMU domid bitmap is
diff --git a/xen/drivers/passthrough/vtd/quirks.c b/xen/drivers/passthrough/vtd/quirks.c
index 950dcd56ef..568a1a06d5 100644
--- a/xen/drivers/passthrough/vtd/quirks.c
+++ b/xen/drivers/passthrough/vtd/quirks.c
@@ -408,9 +408,8 @@ void __init platform_quirks_init(void)
 
 static int __must_check map_me_phantom_function(struct domain *domain,
                                                 unsigned int dev,
-                                                domid_t domid,
-                                                paddr_t pgd_maddr,
-                                                unsigned int mode)
+                                                unsigned int mode,
+                                                struct iommu_context *ctx)
 {
     struct acpi_drhd_unit *drhd;
     struct pci_dev *pdev;
@@ -422,18 +421,17 @@ static int __must_check map_me_phantom_function(struct domain *domain,
 
     /* map or unmap ME phantom function */
     if ( !(mode & UNMAP_ME_PHANTOM_FUNC) )
-        rc = domain_context_mapping_one(domain, drhd->iommu, 0,
-                                        PCI_DEVFN(dev, 7), NULL,
-                                        domid, pgd_maddr, mode);
+        rc = apply_context_single(domain, ctx, drhd->iommu, 0,
+                                  PCI_DEVFN(dev, 7));
     else
-        rc = domain_context_unmap_one(domain, drhd->iommu, 0,
-                                      PCI_DEVFN(dev, 7));
+        rc = unapply_context_single(domain, drhd->iommu, 0, PCI_DEVFN(dev, 7));
 
     return rc;
 }
 
 int me_wifi_quirk(struct domain *domain, uint8_t bus, uint8_t devfn,
-                  domid_t domid, paddr_t pgd_maddr, unsigned int mode)
+                  domid_t domid, unsigned int mode,
+                  struct iommu_context *ctx)
 {
     u32 id;
     int rc = 0;
@@ -457,7 +455,7 @@ int me_wifi_quirk(struct domain *domain, uint8_t bus, uint8_t devfn,
             case 0x423b8086:
             case 0x423c8086:
             case 0x423d8086:
-                rc = map_me_phantom_function(domain, 3, domid, pgd_maddr, mode);
+                rc = map_me_phantom_function(domain, 3, mode, ctx);
                 break;
             default:
                 break;
@@ -483,7 +481,7 @@ int me_wifi_quirk(struct domain *domain, uint8_t bus, uint8_t devfn,
             case 0x42388086:        /* Puma Peak */
             case 0x422b8086:
             case 0x422c8086:
-                rc = map_me_phantom_function(domain, 22, domid, pgd_maddr, mode);
+                rc = map_me_phantom_function(domain, 22, mode, ctx);
                 break;
             default:
                 break;
diff --git a/xen/drivers/passthrough/x86/Makefile b/xen/drivers/passthrough/x86/Makefile
index 75b2885336..1614f3d284 100644
--- a/xen/drivers/passthrough/x86/Makefile
+++ b/xen/drivers/passthrough/x86/Makefile
@@ -1,2 +1,3 @@
 obj-y += iommu.o
+obj-y += arena.o
 obj-$(CONFIG_HVM) += hvm.o
diff --git a/xen/drivers/passthrough/x86/arena.c b/xen/drivers/passthrough/x86/arena.c
new file mode 100644
index 0000000000..984bc4d643
--- /dev/null
+++ b/xen/drivers/passthrough/x86/arena.c
@@ -0,0 +1,157 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/**
+ * Simple arena-based page allocator.
+ *
+ * Allocate a large block using alloc_domheam_pages and allocate single pages
+ * using iommu_arena_allocate_page and iommu_arena_free_page functions.
+ *
+ * Concurrent {allocate/free}_page is thread-safe
+ * iommu_arena_teardown during {allocate/free}_page is not thread-safe.
+ *
+ * Written by Teddy Astie <teddy.astie@vates.tech>
+ */
+
+#include <asm/bitops.h>
+#include <asm/page.h>
+#include <xen/atomic.h>
+#include <xen/bug.h>
+#include <xen/config.h>
+#include <xen/mm-frame.h>
+#include <xen/mm.h>
+#include <xen/xmalloc.h>
+
+#include <asm/arena.h>
+
+/* Maximum of scan tries if the bit found not available */
+#define ARENA_TSL_MAX_TRIES 5
+
+int iommu_arena_initialize(struct iommu_arena *arena, struct domain *d,
+                           unsigned int order, unsigned int memflags)
+{
+    struct page_info *page;
+
+    /* TODO: Maybe allocate differently ? */
+    page = alloc_domheap_pages(d, order, memflags);
+
+    if ( !page )
+        return -ENOMEM;
+
+    arena->map = xzalloc_array(unsigned long, BITS_TO_LONGS(1LLU << order));
+    arena->order = order;
+    arena->region_start = page_to_mfn(page);
+
+    _atomic_set(&arena->used_pages, 0);
+    bitmap_zero(arena->map, iommu_arena_size(arena));
+
+    printk(XENLOG_DEBUG "IOMMU: Allocated arena (%llu pages, start=%"PRI_mfn")\n",
+           iommu_arena_size(arena), mfn_x(arena->region_start));
+    return 0;
+}
+
+int iommu_arena_teardown(struct iommu_arena *arena, bool check)
+{
+    BUG_ON(mfn_x(arena->region_start) == 0);
+
+    /* Check for allocations if check is specified */
+    if ( check && (atomic_read(&arena->used_pages) > 0) )
+        return -EBUSY;
+
+    free_domheap_pages(mfn_to_page(arena->region_start), arena->order);
+
+    arena->region_start = _mfn(0);
+    _atomic_set(&arena->used_pages, 0);
+    xfree(arena->map);
+    arena->map = NULL;
+
+    return 0;
+}
+
+struct page_info *iommu_arena_allocate_page(struct iommu_arena *arena)
+{
+    unsigned int index;
+    unsigned int tsl_tries = 0;
+
+    BUG_ON(mfn_x(arena->region_start) == 0);
+
+    if ( atomic_read(&arena->used_pages) == iommu_arena_size(arena) )
+        /* All pages used */
+        return NULL;
+
+    do
+    {
+        index = find_first_zero_bit(arena->map, iommu_arena_size(arena));
+
+        if ( index >= iommu_arena_size(arena) )
+            /* No more free pages */
+            return NULL;
+
+        /*
+         * While there shouldn't be a lot of retries in practice, this loop
+         * *may* run indefinetly if the found bit is never free due to being
+         * overwriten by another CPU core right after. Add a safeguard for
+         * such very rare cases.
+         */
+        tsl_tries++;
+
+        if ( unlikely(tsl_tries == ARENA_TSL_MAX_TRIES) )
+        {
+            printk(XENLOG_ERR "ARENA: Too many TSL retries !");
+            return NULL;
+        }
+
+        /* Make sure that the bit we found is still free */
+    } while ( test_and_set_bit(index, arena->map) );
+
+    atomic_inc(&arena->used_pages);
+
+    return mfn_to_page(mfn_add(arena->region_start, index));
+}
+
+bool iommu_arena_free_page(struct iommu_arena *arena, struct page_info *page)
+{
+    unsigned long index;
+    mfn_t frame;
+
+    if ( !page )
+    {
+        printk(XENLOG_WARNING "IOMMU: Trying to free NULL page");
+        WARN();
+        return false;
+    }
+
+    frame = page_to_mfn(page);
+
+    /* Check if page belongs to our arena */
+    if ( (mfn_x(frame) < mfn_x(arena->region_start))
+        || (mfn_x(frame) >= (mfn_x(arena->region_start) + iommu_arena_size(arena))) )
+    {
+        printk(XENLOG_WARNING
+               "IOMMU: Trying to free outside arena region [mfn=%"PRI_mfn"]",
+               mfn_x(frame));
+        WARN();
+        return false;
+    }
+
+    index = mfn_x(frame) - mfn_x(arena->region_start);
+
+    /* Sanity check in case of underflow. */
+    ASSERT(index < iommu_arena_size(arena));
+
+    if ( !test_and_clear_bit(index, arena->map) )
+    {
+        /*
+         * Bit was free during our arena_free_page, which means that
+         * either this page was never allocated, or we are in a double-free
+         * situation.
+         */
+        printk(XENLOG_WARNING
+               "IOMMU: Freeing non-allocated region (double-free?) [mfn=%"PRI_mfn"]",
+               mfn_x(frame));
+        WARN();
+        return false;
+    }
+
+    atomic_dec(&arena->used_pages);
+
+    return true;
+}
\ No newline at end of file
diff --git a/xen/drivers/passthrough/x86/iommu.c b/xen/drivers/passthrough/x86/iommu.c
index 8b1e0596b8..ec6cfdf1d9 100644
--- a/xen/drivers/passthrough/x86/iommu.c
+++ b/xen/drivers/passthrough/x86/iommu.c
@@ -12,6 +12,12 @@
  * this program; If not, see <http://www.gnu.org/licenses/>.
  */
 
+#include <xen/keyhandler.h>
+#include <xen/lib.h>
+#include <xen/pci.h>
+#include <xen/bitmap.h>
+#include <xen/list.h>
+#include <xen/mm.h>
 #include <xen/cpu.h>
 #include <xen/sched.h>
 #include <xen/iocap.h>
@@ -28,6 +34,10 @@
 #include <asm/mem_paging.h>
 #include <asm/pt-contig-markers.h>
 #include <asm/setup.h>
+#include <asm/iommu.h>
+#include <asm/arena.h>
+#include <asm/page.h>
+#include <asm/p2m.h>
 
 const struct iommu_init_ops *__initdata iommu_init_ops;
 struct iommu_ops __ro_after_init iommu_ops;
@@ -183,28 +193,68 @@ void __hwdom_init arch_iommu_check_autotranslated_hwdom(struct domain *d)
         panic("PVH hardware domain iommu must be set in 'strict' mode\n");
 }
 
-int arch_iommu_domain_init(struct domain *d)
+int arch_iommu_context_init(struct domain *d, struct iommu_context *ctx, u32 flags)
+{
+    INIT_PAGE_LIST_HEAD(&ctx->arch.pgtables);
+    INIT_PAGE_LIST_HEAD(&ctx->arch.free_queue);
+    INIT_LIST_HEAD(&ctx->arch.identity_maps);
+
+    return 0;
+}
+
+int arch_iommu_context_teardown(struct domain *d, struct iommu_context *ctx, u32 flags)
 {
+    /* Cleanup all page tables */
+    while ( iommu_free_pgtables(d, ctx) == -ERESTART )
+        /* nothing */;
+
+    return 0;
+}
+
+int arch_iommu_flush_free_queue(struct domain *d, struct iommu_context *ctx)
+{
+    struct page_info *pg;
     struct domain_iommu *hd = dom_iommu(d);
 
-    spin_lock_init(&hd->arch.mapping_lock);
+    while ( (pg = page_list_remove_head(&ctx->arch.free_queue)) )
+        iommu_arena_free_page(&hd->arch.pt_arena, pg);
+
+    return 0;
+}
+
+int arch_iommu_pviommu_init(struct domain *d, uint16_t nb_ctx, uint32_t arena_order)
+{
+    struct domain_iommu *hd = dom_iommu(d);
+
+    if ( arena_order == 0 )
+        return 0;
+
+    return iommu_arena_initialize(&hd->arch.pt_arena, NULL, arena_order, 0);
+}
+
+int arch_iommu_pviommu_teardown(struct domain *d)
+{
+    struct domain_iommu *hd = dom_iommu(d);
+
+    if ( iommu_arena_teardown(&hd->arch.pt_arena, true) )
+    {
+        printk(XENLOG_WARNING "IOMMU Arena used while being destroyed\n");
+        WARN();
+
+        /* Teardown anyway */
+        iommu_arena_teardown(&hd->arch.pt_arena, false);
+    }
 
-    INIT_PAGE_LIST_HEAD(&hd->arch.pgtables.list);
-    spin_lock_init(&hd->arch.pgtables.lock);
-    INIT_LIST_HEAD(&hd->arch.identity_maps);
+    return 0;
+}
 
+int arch_iommu_domain_init(struct domain *d)
+{
     return 0;
 }
 
 void arch_iommu_domain_destroy(struct domain *d)
 {
-    /*
-     * There should be not page-tables left allocated by the time the
-     * domain is destroyed. Note that arch_iommu_domain_destroy() is
-     * called unconditionally, so pgtables may be uninitialized.
-     */
-    ASSERT(!dom_iommu(d)->platform_ops ||
-           page_list_empty(&dom_iommu(d)->arch.pgtables.list));
 }
 
 struct identity_map {
@@ -214,32 +264,104 @@ struct identity_map {
     unsigned int count;
 };
 
-int iommu_identity_mapping(struct domain *d, p2m_access_t p2ma,
-                           paddr_t base, paddr_t end,
+static int unmap_identity_region(struct domain *d, struct iommu_context *ctx,
+                                 unsigned int base_pfn, unsigned int end_pfn)
+{
+    int ret = 0;
+
+    if ( ctx->opaque )
+    {
+        this_cpu(iommu_dont_flush_iotlb) = true;
+        while ( base_pfn < end_pfn )
+        {
+            if ( p2m_remove_identity_entry(d, base_pfn) )
+                ret = -ENXIO;
+
+            base_pfn++;
+        }
+        this_cpu(iommu_dont_flush_iotlb) = false;
+    }
+    else
+    {
+        size_t page_count = end_pfn - base_pfn + 1;
+        unsigned int flush_flags;
+
+        ret = iommu_unmap(d, _dfn(base_pfn), page_count, 0, &flush_flags,
+                          ctx->id);
+
+        if ( ret )
+            return ret;
+
+        ret = iommu_iotlb_flush(d, _dfn(base_pfn), page_count,
+                                flush_flags, ctx->id);
+    }
+
+    return ret;
+}
+
+static int map_identity_region(struct domain *d, struct iommu_context *ctx,
+                               unsigned int base_pfn, unsigned int end_pfn,
+                               p2m_access_t p2ma, unsigned int flag)
+{
+    int ret = 0;
+    unsigned int flush_flags = 0;
+    size_t page_count = end_pfn - base_pfn + 1;
+
+    if ( ctx->opaque )
+    {
+        this_cpu(iommu_dont_flush_iotlb) = true;
+        while ( base_pfn < end_pfn )
+        {
+            ret = p2m_add_identity_entry(d, base_pfn, p2ma, flag);
+
+            if ( ret )
+            {
+                this_cpu(iommu_dont_flush_iotlb) = false;
+                return ret;
+            }
+
+            base_pfn++;
+        }
+        this_cpu(iommu_dont_flush_iotlb) = false;
+    }
+    else
+    {
+        ret = iommu_map(d, _dfn(base_pfn), _mfn(base_pfn), page_count,
+                        p2m_access_to_iommu_flags(p2ma), &flush_flags,
+                        ctx->id);
+
+        if ( ret )
+            return ret;
+    }
+
+    ret = iommu_iotlb_flush(d, _dfn(base_pfn), page_count, flush_flags,
+                            ctx->id);
+
+    return ret;
+}
+
+/* p2m_access_x removes the mapping */
+int iommu_identity_mapping(struct domain *d, struct iommu_context *ctx,
+                           p2m_access_t p2ma, paddr_t base, paddr_t end,
                            unsigned int flag)
 {
     unsigned long base_pfn = base >> PAGE_SHIFT_4K;
     unsigned long end_pfn = PAGE_ALIGN_4K(end) >> PAGE_SHIFT_4K;
     struct identity_map *map;
-    struct domain_iommu *hd = dom_iommu(d);
+    int ret = 0;
 
     ASSERT(pcidevs_locked());
     ASSERT(base < end);
 
-    /*
-     * No need to acquire hd->arch.mapping_lock: Both insertion and removal
-     * get done while holding pcidevs_lock.
-     */
-    list_for_each_entry( map, &hd->arch.identity_maps, list )
+    list_for_each_entry( map, &ctx->arch.identity_maps, list )
     {
         if ( map->base == base && map->end == end )
         {
-            int ret = 0;
-
             if ( p2ma != p2m_access_x )
             {
                 if ( map->access != p2ma )
                     return -EADDRINUSE;
+
                 ++map->count;
                 return 0;
             }
@@ -247,12 +369,9 @@ int iommu_identity_mapping(struct domain *d, p2m_access_t p2ma,
             if ( --map->count )
                 return 0;
 
-            while ( base_pfn < end_pfn )
-            {
-                if ( clear_identity_p2m_entry(d, base_pfn) )
-                    ret = -ENXIO;
-                base_pfn++;
-            }
+            printk("Unmapping [%"PRI_mfn"x:%"PRI_mfn"] for d%dc%d\n", base_pfn, end_pfn,
+                   d->domain_id, ctx->id);
+            ret = unmap_identity_region(d, ctx, base_pfn, end_pfn);
 
             list_del(&map->list);
             xfree(map);
@@ -271,47 +390,43 @@ int iommu_identity_mapping(struct domain *d, p2m_access_t p2ma,
     if ( !map )
         return -ENOMEM;
 
-    map->base = base;
-    map->end = end;
-    map->access = p2ma;
-    map->count = 1;
+    printk("Mapping [%"PRI_mfn"x:%"PRI_mfn"] for d%dc%d\n", base_pfn, end_pfn,
+           d->domain_id, ctx->id);
+    ret = map_identity_region(d, ctx, base_pfn, end_pfn, p2ma, flag);
 
-    /*
-     * Insert into list ahead of mapping, so the range can be found when
-     * trying to clean up.
-     */
-    list_add_tail(&map->list, &hd->arch.identity_maps);
-
-    for ( ; base_pfn < end_pfn; ++base_pfn )
+    if ( ret )
     {
-        int err = set_identity_p2m_entry(d, base_pfn, p2ma, flag);
-
-        if ( !err )
-            continue;
-
-        if ( (map->base >> PAGE_SHIFT_4K) == base_pfn )
-        {
-            list_del(&map->list);
-            xfree(map);
-        }
-        return err;
+        xfree(map);
+        return ret;
     }
 
     return 0;
 }
 
-void iommu_identity_map_teardown(struct domain *d)
+void iommu_identity_map_teardown(struct domain *d, struct iommu_context *ctx)
 {
-    struct domain_iommu *hd = dom_iommu(d);
     struct identity_map *map, *tmp;
 
-    list_for_each_entry_safe ( map, tmp, &hd->arch.identity_maps, list )
+    list_for_each_entry_safe ( map, tmp, &ctx->arch.identity_maps, list )
     {
         list_del(&map->list);
         xfree(map);
     }
 }
 
+bool iommu_identity_map_check(struct domain *d, struct iommu_context *ctx,
+                              mfn_t mfn)
+{
+    struct identity_map *map;
+    uint64_t addr = pfn_to_paddr(mfn_x(mfn));
+
+    list_for_each_entry ( map, &ctx->arch.identity_maps, list )
+        if (addr >= map->base && addr < map->end)
+            return true;
+
+    return false;
+}
+
 static int __hwdom_init cf_check map_subtract(unsigned long s, unsigned long e,
                                               void *data)
 {
@@ -369,7 +484,7 @@ static int __hwdom_init cf_check identity_map(unsigned long s, unsigned long e,
             if ( iomem_access_permitted(d, s, s) )
             {
                 rc = iommu_map(d, _dfn(s), _mfn(s), 1, perms,
-                               &info->flush_flags);
+                               &info->flush_flags, 0);
                 if ( rc < 0 )
                     break;
                 /* Must map a frame at least, which is what we request for. */
@@ -379,7 +494,7 @@ static int __hwdom_init cf_check identity_map(unsigned long s, unsigned long e,
             s++;
         }
         while ( (rc = iommu_map(d, _dfn(s), _mfn(s), e - s + 1,
-                                perms, &info->flush_flags)) > 0 )
+                                perms, &info->flush_flags, 0)) > 0 )
         {
             s += rc;
             process_pending_softirqs();
@@ -408,6 +523,10 @@ void __hwdom_init arch_iommu_hwdom_init(struct domain *d)
     if ( iommu_hwdom_reserved == -1 )
         iommu_hwdom_reserved = 1;
 
+    if ( iommu_hwdom_no_dma )
+        /* Skip special mappings with no-dma mode */
+        return;
+
     if ( iommu_hwdom_inclusive )
     {
         printk(XENLOG_WARNING
@@ -539,22 +658,18 @@ void __hwdom_init arch_iommu_hwdom_init(struct domain *d)
                map_data.mmio_ro ? "read-only " : "", rc);
 
     /* Use if to avoid compiler warning */
-    if ( iommu_iotlb_flush_all(d, map_data.flush_flags) )
+    if ( iommu_iotlb_flush_all(d, 0, map_data.flush_flags) )
         return;
 }
 
 void arch_pci_init_pdev(struct pci_dev *pdev)
 {
-    pdev->arch.pseudo_domid = DOMID_INVALID;
 }
 
 unsigned long *__init iommu_init_domid(domid_t reserve)
 {
     unsigned long *map;
 
-    if ( !iommu_quarantine )
-        return ZERO_BLOCK_PTR;
-
     BUILD_BUG_ON(DOMID_MASK * 2U >= UINT16_MAX);
 
     map = xzalloc_array(unsigned long, BITS_TO_LONGS(UINT16_MAX - DOMID_MASK));
@@ -569,41 +684,29 @@ unsigned long *__init iommu_init_domid(domid_t reserve)
 
 domid_t iommu_alloc_domid(unsigned long *map)
 {
-    /*
-     * This is used uniformly across all IOMMUs, such that on typical
-     * systems we wouldn't re-use the same ID very quickly (perhaps never).
-     */
-    static unsigned int start;
-    unsigned int idx = find_next_zero_bit(map, UINT16_MAX - DOMID_MASK, start);
+    /* TODO: Consider nr_doms ? */
+    unsigned int idx = find_next_zero_bit(map, UINT16_MAX, 0);
 
-    ASSERT(pcidevs_locked());
-
-    if ( idx >= UINT16_MAX - DOMID_MASK )
-        idx = find_first_zero_bit(map, UINT16_MAX - DOMID_MASK);
-    if ( idx >= UINT16_MAX - DOMID_MASK )
-        return DOMID_INVALID;
+    if ( idx >= UINT16_MAX )
+        return UINT16_MAX;
 
     __set_bit(idx, map);
 
-    start = idx + 1;
-
-    return idx | (DOMID_MASK + 1);
+    return idx;
 }
 
 void iommu_free_domid(domid_t domid, unsigned long *map)
 {
     ASSERT(pcidevs_locked());
 
-    if ( domid == DOMID_INVALID )
+    if ( domid == UINT16_MAX )
         return;
 
-    ASSERT(domid > DOMID_MASK);
-
     if ( !__test_and_clear_bit(domid & DOMID_MASK, map) )
         BUG();
 }
 
-int iommu_free_pgtables(struct domain *d)
+int cf_check iommu_free_pgtables(struct domain *d, struct iommu_context *ctx)
 {
     struct domain_iommu *hd = dom_iommu(d);
     struct page_info *pg;
@@ -612,18 +715,18 @@ int iommu_free_pgtables(struct domain *d)
     if ( !is_iommu_enabled(d) )
         return 0;
 
-    /* After this barrier, no new IOMMU mappings can be inserted. */
-    spin_barrier(&hd->arch.mapping_lock);
-
     /*
      * Pages will be moved to the free list below. So we want to
      * clear the root page-table to avoid any potential use after-free.
      */
-    iommu_vcall(hd->platform_ops, clear_root_pgtable, d);
+    iommu_vcall(hd->platform_ops, clear_root_pgtable, d, ctx);
 
-    while ( (pg = page_list_remove_head(&hd->arch.pgtables.list)) )
+    while ( (pg = page_list_remove_head(&ctx->arch.pgtables)) )
     {
-        free_domheap_page(pg);
+        if (ctx->id == 0)
+            free_domheap_page(pg);
+        else
+            iommu_arena_free_page(&hd->arch.pt_arena, pg);
 
         if ( !(++done & 0xff) && general_preempt_check() )
             return -ERESTART;
@@ -633,6 +736,7 @@ int iommu_free_pgtables(struct domain *d)
 }
 
 struct page_info *iommu_alloc_pgtable(struct domain_iommu *hd,
+                                      struct iommu_context *ctx,
                                       uint64_t contig_mask)
 {
     unsigned int memflags = 0;
@@ -644,7 +748,11 @@ struct page_info *iommu_alloc_pgtable(struct domain_iommu *hd,
         memflags = MEMF_node(hd->node);
 #endif
 
-    pg = alloc_domheap_page(NULL, memflags);
+    if (ctx->id == 0)
+        pg = alloc_domheap_page(NULL, memflags);
+    else
+        pg = iommu_arena_allocate_page(&hd->arch.pt_arena);
+
     if ( !pg )
         return NULL;
 
@@ -677,9 +785,7 @@ struct page_info *iommu_alloc_pgtable(struct domain_iommu *hd,
 
     unmap_domain_page(p);
 
-    spin_lock(&hd->arch.pgtables.lock);
-    page_list_add(pg, &hd->arch.pgtables.list);
-    spin_unlock(&hd->arch.pgtables.lock);
+    page_list_add(pg, &ctx->arch.pgtables);
 
     return pg;
 }
@@ -718,17 +824,20 @@ static void cf_check free_queued_pgtables(void *arg)
     }
 }
 
-void iommu_queue_free_pgtable(struct domain_iommu *hd, struct page_info *pg)
+void iommu_queue_free_pgtable(struct iommu_context *ctx, struct page_info *pg)
 {
     unsigned int cpu = smp_processor_id();
 
-    spin_lock(&hd->arch.pgtables.lock);
-    page_list_del(pg, &hd->arch.pgtables.list);
-    spin_unlock(&hd->arch.pgtables.lock);
+    page_list_del(pg, &ctx->arch.pgtables);
 
-    page_list_add_tail(pg, &per_cpu(free_pgt_list, cpu));
+    if ( !ctx->id )
+    {
+        page_list_add_tail(pg, &per_cpu(free_pgt_list, cpu));
 
-    tasklet_schedule(&per_cpu(free_pgt_tasklet, cpu));
+        tasklet_schedule(&per_cpu(free_pgt_tasklet, cpu));
+    }
+    else
+        page_list_add_tail(pg, &ctx->arch.free_queue);
 }
 
 static int cf_check cpu_callback(
-- 
2.45.3



Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 16:44:36 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 16:44:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875596.1286035 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taHMc-0001Dk-P7; Tue, 21 Jan 2025 16:44:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875596.1286035; Tue, 21 Jan 2025 16:44:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taHMc-0001Dd-L1; Tue, 21 Jan 2025 16:44:30 +0000
Received: by outflank-mailman (input) for mailman id 875596;
 Tue, 21 Jan 2025 16:44:29 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Gode=UN=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1taHMb-0001DX-BJ
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 16:44:29 +0000
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com
 [2a00:1450:4864:20::331])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id fa26ebd4-d816-11ef-99a4-01e77a169b0f;
 Tue, 21 Jan 2025 17:44:27 +0100 (CET)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-436326dcb1cso41515625e9.0
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 08:44:27 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38bf327decbsm14109338f8f.90.2025.01.21.08.44.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 21 Jan 2025 08:44:25 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: fa26ebd4-d816-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737477866; x=1738082666; 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=EmCD58f4zvehMaZJsFTMs/mrzruzYybuNQJUOgew3cA=;
        b=G167hpSWLviqGQENN1QYTcvpzqDoUxi+c7A3DhW2/n3/Ui1+/vhbzP/0on53b/90zq
         hlHcQz2175x7CWm+tA7WsH6guekRR5GgVewJp8Px/mzYzAmFqVT6Rxy2j071rwPMkzpk
         b7Jnn7tJ4QPcseozox9UpRoOP9VDQzlwmYC49wxpj0zk59ul8QixbWmZ03AZnfbqAbjJ
         uLyYUlWucxRnuTw0vXEq3rQ5aMIgvPND2bIeAIefFa48kabPpPhDMt2iMI2FSijJoKYP
         odBSURDsdAFi1VDAvYl3RgdH9hjJsfqfcE8FDuwScCW2xDDnMJ2SJ5Od14UbB3MzFalQ
         juBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737477866; x=1738082666;
        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=EmCD58f4zvehMaZJsFTMs/mrzruzYybuNQJUOgew3cA=;
        b=Z4Aqbm4ndrrXzjbevVkfqkNatDXXAVCLZGHgbEdMu7Wv66FiGbvVP3kdcVB/omWQ8h
         E5e7XFuZ9OLJ7auSaiNRP+Jz59+IAFcAcV5F9pacF74V+wu0DbjkE0odeaGqCH+/Zzk/
         kwQPm413YlpPRVbraAshs0YmanARVwK/tORc9dignOw1VfgPtC+CQI6jGv0mBX1XEip8
         END+BSU7B+v/VJ4wvrvsTA9483wYD2cnu/yCVkEt+l7izqaqbPokkSzmb8GXSnqBrVpj
         gS+GuGFvKpQk6iZj1WuKMwPlFCUSs7EhpYkwgqw2u3K6OoIr5wmaViv1JY/QwR9Mj7IC
         nt3Q==
X-Gm-Message-State: AOJu0YyPcIBMHOtP1SljAvCZCOX111GLX9T4GYodm1w3oAoOueLnk+Lu
	on5fBYtc0ZTcVlyFYjluGqgxMehPftUibvXbWjmpT8vcFl4dhZJ1Ls7LZPJ/3g5w0xFG4YWShK4
	=
X-Gm-Gg: ASbGncvSGGtdA9pVXTR1wZHh9AhZuMXyjxig/1APkdfp5roELQHre3ajhFhgzzWN4p6
	ZesiohTcEbemzfc3QSAmMj9BHgxLhkVBMwJbxIIZtERjPO2N3tEw6HgjWWjMxTpcsz02fjWhTPm
	i0uy9U0xoyMVP3H+yKmTYSJwIjxYMbVsEpiozCVzKGwwiNfl77ofv+dpwbpBDBngfZwK8+0sL+j
	Hr+WLxQawjkYPH0+eow+2C6oXiRoVjs2FxccoPbLQGO/Gx3MN8nOyi76tsUnCF+ZXhTyLbXim1R
	IdqySRWa+PdpgYlMWqFExtY4bnCAaG61DlfiKXt03V3YOIDHaIfFOy4=
X-Google-Smtp-Source: AGHT+IECM6xf5vJKaZeIi573x2ZBgRIn1r+aJgUL8ImblEdTGNvP61Vn8LxnLoCVIvyj5HHq1CKOuA==
X-Received: by 2002:a05:600c:3b02:b0:431:54d9:da57 with SMTP id 5b1f17b1804b1-4389144d5a1mr180164435e9.30.1737477866496;
        Tue, 21 Jan 2025 08:44:26 -0800 (PST)
Message-ID: <a2f8501d-2cc9-4210-ab33-cd70f47c6373@suse.com>
Date: Tue, 21 Jan 2025 17:44:25 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH for-4.21] x86emul: drop open-coding of REX.W prefixes
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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

Along the lines of 0e3642514719 ("x86: drop REX64_PREFIX"), move to well
formed FXSAVEQ / FXRSTORQ here as well.

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

--- a/xen/arch/x86/x86_emulate/blk.c
+++ b/xen/arch/x86/x86_emulate/blk.c
@@ -259,16 +259,7 @@ int x86_emul_blk(
         if ( s->op_bytes < sizeof(*fxsr) )
         {
             if ( s->rex_prefix & REX_W )
-            {
-                /*
-                 * The only way to force fxsaveq on a wide range of gas
-                 * versions. On older versions the rex64 prefix works only if
-                 * we force an addressing mode that doesn't require extended
-                 * registers.
-                 */
-                asm volatile ( ".byte 0x48; fxsave (%1)"
-                               : "=m" (*fxsr) : "R" (fxsr) );
-            }
+                asm volatile ( "fxsaveq %0" : "=m" (*fxsr) );
             else
                 asm volatile ( "fxsave %0" : "=m" (*fxsr) );
         }
@@ -285,11 +276,7 @@ int x86_emul_blk(
         generate_exception_if(fxsr->mxcsr & ~mxcsr_mask, X86_EXC_GP, 0);
 
         if ( s->rex_prefix & REX_W )
-        {
-            /* See above for why operand/constraints are this way. */
-            asm volatile ( ".byte 0x48; fxrstor (%1)"
-                           :: "m" (*fxsr), "R" (fxsr) );
-        }
+            asm volatile ( "fxrstorq %0" :: "m" (*fxsr) );
         else
             asm volatile ( "fxrstor %0" :: "m" (*fxsr) );
         break;
@@ -310,11 +297,7 @@ int x86_emul_blk(
             fxsr = ptr;
 
         if ( s->rex_prefix & REX_W )
-        {
-            /* See above for why operand/constraints are this way. */
-            asm volatile ( ".byte 0x48; fxsave (%1)"
-                           : "=m" (*fxsr) : "R" (fxsr) );
-        }
+            asm volatile ( "fxsaveq %0" : "=m" (*fxsr) );
         else
             asm volatile ( "fxsave %0" : "=m" (*fxsr) );
 


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 16:53:59 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 16:53:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875604.1286045 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taHVi-00036m-Iw; Tue, 21 Jan 2025 16:53:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875604.1286045; Tue, 21 Jan 2025 16:53:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taHVi-00036f-GQ; Tue, 21 Jan 2025 16:53:54 +0000
Received: by outflank-mailman (input) for mailman id 875604;
 Tue, 21 Jan 2025 16:53:53 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=qQWO=UN=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1taHVh-00036Z-36
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 16:53:53 +0000
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com
 [2a00:1450:4864:20::32d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4ab5f32a-d818-11ef-a0e4-8be0dac302b0;
 Tue, 21 Jan 2025 17:53:52 +0100 (CET)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-4361dc6322fso41460845e9.3
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 08:53:52 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38bf322acdcsm14145777f8f.55.2025.01.21.08.53.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 21 Jan 2025 08:53:50 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 4ab5f32a-d818-11ef-a0e4-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737478431; x=1738083231; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=kkhqh9rNWNPd4Q42WrI+ZA18UDRR0mdGKMdRpVxxhmM=;
        b=TSi1p/A+rhUe7dFImDvOU+Y6QbfDRE/dWMD0fE0mMsd60+Eb9WchnTmLDuJeUlb1c0
         via+S5Aa9EP48bNKFUWVWfLfS6fY1OWxv6CqUgEWO8IHu8JHQ7ZPVCc/XF0utQxk3vs4
         9AdY8LMghuz16GyMIyTZHboyIquQQ/eg1MYxM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737478431; x=1738083231;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=kkhqh9rNWNPd4Q42WrI+ZA18UDRR0mdGKMdRpVxxhmM=;
        b=g+elOwqhoDrkEBk3QlTWtmsT560TlJ2KMUgfY5gcV1iOf4Sj4CsUzozCGXaPMx1xCU
         e82genQN02NzpLnKpPBko+R7g5h/rSWHVpb3LnbxXkY0OkPCUf99bY/cInBwsxXheq73
         GHB51yFHSGnsj3HEXJMcL5MPrTBK1DRG9BnB2/3B7gXlI2gtqTsSSRgL+R+nP5WKb96R
         +UVwpye1bO9WGiZB8sCd7+Bq+H78sO6pmDLjHzLFCQo4bQ5f4Jyr2knSR16KHW6MPe6G
         +78gL8RgFigmmmWV4oGzS9QxX0Ykkk+2yriCgpJV9XrT3Rpa+z0xFF9N9Xowj5jVnVV3
         D3aQ==
X-Forwarded-Encrypted: i=1; AJvYcCWn7Pquiq3kjdmKxTntZI3AcGfPgOQcVA0QekGuDaDprZyzS3w/f5BbiowzQ4jmD0tBM+pANguEN1w=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywm7a93Veig46VPEOjJX8YSmEq9XVR8sn0hCYOr35fmftcsJcK3
	4xCOtDjQRqbi84ahz0HRqO7LYC4sdY42BfhEuKz5tPxR6NhT7peayWvZ1gBgl7o=
X-Gm-Gg: ASbGncsEDz4dLivc+ssmHYNrP6ovQ7yTdnz+97OZd0WFkbvyGYuJIIjzdbomFyoGY3h
	h+N3WtKb0eOWyDgL5OrKwN9r4Y6G4FHIhLkRN9CZ1KfRGB496zEWaXo1Z/iJfccbCDnAVUdNKbf
	rdGefk/F8jCVWsSKduT0EM2+koAKJumaGRvw4cfMSbK/we0KUi8fZpZdkiGjsz6CiBQdkgZQc3G
	PCTp6KvWWxWlvHcPcmx1AzNAXPL2sz9NIniiFL6Upnu5+GYGnp7aArJg0BOXjq8IuhuceU24Gwp
	t9HDPeMJ5OKmr8//hXlJscHbiE3ax7R2Uw==
X-Google-Smtp-Source: AGHT+IEELCP1btDzM/dM+aN2CQWxqYzE4Xy6f7wDKLy8byD7OQVrTqYih4ULcOM3kU3aFLLmVfqL5g==
X-Received: by 2002:a05:600c:1ca7:b0:431:44fe:fd9f with SMTP id 5b1f17b1804b1-4389142776dmr164977055e9.23.1737478431210;
        Tue, 21 Jan 2025 08:53:51 -0800 (PST)
Message-ID: <1e876c43-1b16-4996-9818-1fad0b9d73ea@citrix.com>
Date: Tue, 21 Jan 2025 16:53:50 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.21] x86emul: drop open-coding of REX.W prefixes
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
References: <a2f8501d-2cc9-4210-ab33-cd70f47c6373@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <a2f8501d-2cc9-4210-ab33-cd70f47c6373@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 21/01/2025 4:44 pm, Jan Beulich wrote:
> Along the lines of 0e3642514719 ("x86: drop REX64_PREFIX"), move to well
> formed FXSAVEQ / FXRSTORQ here as well.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 16:56:34 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 16:56:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875611.1286055 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taHYF-0003e1-V0; Tue, 21 Jan 2025 16:56:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875611.1286055; Tue, 21 Jan 2025 16:56:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taHYF-0003du-SE; Tue, 21 Jan 2025 16:56:31 +0000
Received: by outflank-mailman (input) for mailman id 875611;
 Tue, 21 Jan 2025 16:56:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=qQWO=UN=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1taHYF-0003do-4I
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 16:56:31 +0000
Received: from mail-ed1-x542.google.com (mail-ed1-x542.google.com
 [2a00:1450:4864:20::542])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a88aa2fd-d818-11ef-99a4-01e77a169b0f;
 Tue, 21 Jan 2025 17:56:29 +0100 (CET)
Received: by mail-ed1-x542.google.com with SMTP id
 4fb4d7f45d1cf-5d3d0205bd5so9525822a12.3
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 08:56:29 -0800 (PST)
Received: from andrewcoop.eng.citrite.net (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5db73697174sm7377310a12.45.2025.01.21.08.56.27
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 21 Jan 2025 08:56:28 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a88aa2fd-d818-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737478588; x=1738083388; 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=aJMA+NwRz9Q4wQth1iLhNf8fNKE6Vjh+DxIWkVVgb04=;
        b=IADM2SyXWUHUkD/1SMJ6UuVd7dz1+SnUxScXyaBOAns9kkUKkauwYJm9fXg4/UdtLQ
         hXpkp7SkeSBx3IPtpaCaExUmBHLdTNqH1/VpS3rpTdQC7fBlq5MrKBszft6tu8/A+CUS
         CBJjiNfeU4jcOiYHoRyIDRYSWu7pBqn8Lk/QE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737478588; x=1738083388;
        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=aJMA+NwRz9Q4wQth1iLhNf8fNKE6Vjh+DxIWkVVgb04=;
        b=eaNM2sLxaGMDaEC591W3kfOjCDY0qdiAbMRxXytBmhVSQ0RTNjtRhAzGSLbhWYXeli
         e+xgjkydTDoSm/o0Tb6D8c1Q7AatKjUH8SEe1gISufGiyzbvD4Lxxzv3nGoNEy2qdQIM
         Nn/StHBT8ea/VcTKpQ61SpqFJkn4HFtdsTdo9V3ysnI3HBiLr7bFz/JukyV5pNxXEWWc
         7G/Q6ii8DWlg3KCG0NFAQi1/TqkVzOZZA9C7i8D7+c0zI1S3g++XnLULkKp8CY1o89K+
         rqdKzDf3DSAA8gG9xBxdPTB0khL2dYUfPKD3HQqQ9/XhIa6fcoLDm7Z8qsPBe+yODRDU
         VGSw==
X-Gm-Message-State: AOJu0Yy7CP05v+0/tYz7kO+yGQzLoa3/7wsczQUiewQ9CJX9+GbwjNlx
	TuJ8kIRTCAkgkXLpfiGov3FMW1mCdhqPSRZCwWEcqLws61mfS/rA7tAXgE6e9WTB+nXE1LlpI9G
	c/xoG8Q==
X-Gm-Gg: ASbGncu1VO/mlImxc9Jbtq9894yeq+wyS2TSRwN0nmKXOfiNrwo4sA1azNMA7iiTRmF
	hTlMes6AhaCgmQPAMzlsyfWwB4L2sR6jCfYLW+BaWFh4sHBiCN246hIq6Iov0P4FCtpGkf055pJ
	IER31fX/HOwAOOpjY21N0FsEPxyA0QVbd+Q58PZ7aaud3atm9wPjYURz6stTNrJ8itu/3RB8XOn
	+/DlM5v4HcNkWdLlCPUPnD9EmPxwNJTE8xMfRW7YdUsF6b1MrShseDKSY7GXeRwvsNZy4NUdWMI
	MOwrtuG0ALA4sloB3q3NvKsgDWkmnQ+uk4Rr71MVez8yuUnshw==
X-Google-Smtp-Source: AGHT+IEztnPdON91e+BElFap+6j1zBaaefdtCNoo2J1bSnKRifwrsDk8mjz5XHrhMs/ipgcqsbL87g==
X-Received: by 2002:a50:c010:0:b0:5d9:8877:895a with SMTP id 4fb4d7f45d1cf-5db7d300e78mr13640317a12.17.1737478588313;
        Tue, 21 Jan 2025 08:56:28 -0800 (PST)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jonathan Katz <jonathan.katz@aptar.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>
Subject: [PATCH for-4.20 v2] x86/intel: Fix PERF_GLOBAL fixup when virtualised
Date: Tue, 21 Jan 2025 16:56:26 +0000
Message-Id: <20250121165626.380627-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250121142510.358996-1-andrew.cooper3@citrix.com>
References: <20250121142510.358996-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Logic using performance counters needs to look at
MSR_MISC_ENABLE.PERF_AVAILABLE before touching any other resources.

When virtualised under ESX, Xen dies with a #GP fault trying to read
MSR_CORE_PERF_GLOBAL_CTRL.

Factor this logic out into a separate function (it's already too squashed to
the RHS), and insert a check of MSR_MISC_ENABLE.PERF_AVAILABLE.

This also avoids setting X86_FEATURE_ARCH_PERFMON if MSR_MISC_ENABLE says that
PERF is unavailable, although oprofile (the only consumer of this flag)
cross-checks too.

Fixes: 6bdb965178bb ("x86/intel: ensure Global Performance Counter Control is setup correctly")
Reported-by: Jonathan Katz <jonathan.katz@aptar.com>
Link: https://xcp-ng.org/forum/topic/10286/nesting-xcp-ng-on-esx-8
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Roger Pau Monné <roger.pau@citrix.com>
CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>

v2:
 * Drop _safe() on MSR_IA32_MISC_ENABLE read.
 * Fix the setting of X86_FEATURE_ARCH_PERFMON.

Untested, but this is the same pattern used by oprofile and watchdog setup.

I've intentionally stopped using Intel style.  This file is already mixed (as
visible even in context), and it doesn't remotely resemble it's Linux origin
any more.

For 4.20.  This regressions has already been backported.
---
 xen/arch/x86/cpu/intel.c | 64 +++++++++++++++++++++++-----------------
 1 file changed, 37 insertions(+), 27 deletions(-)

diff --git a/xen/arch/x86/cpu/intel.c b/xen/arch/x86/cpu/intel.c
index 6a7347968ba2..6a680ba38dc9 100644
--- a/xen/arch/x86/cpu/intel.c
+++ b/xen/arch/x86/cpu/intel.c
@@ -535,39 +535,49 @@ static void intel_log_freq(const struct cpuinfo_x86 *c)
     printk("%u MHz\n", (factor * max_ratio + 50) / 100);
 }
 
+static void init_intel_perf(struct cpuinfo_x86 *c)
+{
+    uint64_t val;
+    unsigned int eax, ver, nr_cnt;
+
+    if ( c->cpuid_level <= 9 ||
+         ({  rdmsrl(MSR_IA32_MISC_ENABLE, val);
+             !(val & MSR_IA32_MISC_ENABLE_PERF_AVAIL); }) )
+        return;
+
+    eax = cpuid_eax(10);
+    ver = eax & 0xff;
+    nr_cnt = (eax >> 8) & 0xff;
+
+    if ( ver && nr_cnt > 1 && nr_cnt <= 32 )
+    {
+        unsigned int cnt_mask = (1UL << nr_cnt) - 1;
+
+        /*
+         * On (some?) Sapphire/Emerald Rapids platforms each package-BSP
+         * starts with all the enable bits for the general-purpose PMCs
+         * cleared.  Adjust so counters can be enabled from EVNTSEL.
+         */
+        rdmsrl(MSR_CORE_PERF_GLOBAL_CTRL, val);
+
+        if ( (val & cnt_mask) != cnt_mask )
+        {
+            printk("FIRMWARE BUG: CPU%u invalid PERF_GLOBAL_CTRL: %#"PRIx64" adjusting to %#"PRIx64"\n",
+                   smp_processor_id(), val, val | cnt_mask);
+            wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, val | cnt_mask);
+        }
+
+        __set_bit(X86_FEATURE_ARCH_PERFMON, c->x86_capability);
+    }
+}
+
 static void cf_check init_intel(struct cpuinfo_x86 *c)
 {
 	/* Detect the extended topology information if available */
 	detect_extended_topology(c);
 
 	init_intel_cacheinfo(c);
-	if (c->cpuid_level > 9) {
-		unsigned eax = cpuid_eax(10);
-		unsigned int cnt = (eax >> 8) & 0xff;
-
-		/* Check for version and the number of counters */
-		if ((eax & 0xff) && (cnt > 1) && (cnt <= 32)) {
-			uint64_t global_ctrl;
-			unsigned int cnt_mask = (1UL << cnt) - 1;
-
-			/*
-			 * On (some?) Sapphire/Emerald Rapids platforms each
-			 * package-BSP starts with all the enable bits for the
-			 * general-purpose PMCs cleared.  Adjust so counters
-			 * can be enabled from EVNTSEL.
-			 */
-			rdmsrl(MSR_CORE_PERF_GLOBAL_CTRL, global_ctrl);
-			if ((global_ctrl & cnt_mask) != cnt_mask) {
-				printk("CPU%u: invalid PERF_GLOBAL_CTRL: %#"
-				       PRIx64 " adjusting to %#" PRIx64 "\n",
-				       smp_processor_id(), global_ctrl,
-				       global_ctrl | cnt_mask);
-				wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL,
-				       global_ctrl | cnt_mask);
-			}
-			__set_bit(X86_FEATURE_ARCH_PERFMON, c->x86_capability);
-		}
-	}
+	init_intel_perf(c);
 
 	if ( !cpu_has(c, X86_FEATURE_XTOPOLOGY) )
 	{

base-commit: c3f5d1bb40b57d467cb4051eafa86f5933ec9003
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Tue Jan 21 16:57:30 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 16:57:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875620.1286065 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taHZC-000496-8s; Tue, 21 Jan 2025 16:57:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875620.1286065; Tue, 21 Jan 2025 16:57:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taHZC-00048z-50; Tue, 21 Jan 2025 16:57:30 +0000
Received: by outflank-mailman (input) for mailman id 875620;
 Tue, 21 Jan 2025 16:57:29 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=NioT=UN=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1taHZB-0003tG-47
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 16:57:29 +0000
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com
 [2a00:1450:4864:20::22f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id cbdf347a-d818-11ef-a0e4-8be0dac302b0;
 Tue, 21 Jan 2025 17:57:28 +0100 (CET)
Received: by mail-lj1-x22f.google.com with SMTP id
 38308e7fff4ca-30167f4c1e3so53865051fa.3
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 08:57:28 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-543bb6bf5b1sm15507e87.118.2025.01.21.08.57.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 21 Jan 2025 08:57:27 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: cbdf347a-d818-11ef-a0e4-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1737478648; x=1738083448; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=bTA4jnXzYEFzhmsmqQFRKNCJDj+5qOjoNV3nC5NctjY=;
        b=D9p6VP0PfLjIdHxmfeXwFLkpp8T/YA28BQrC62QRSsajB6fsFkoJ2k+Ra3Nz2UeMFM
         fDw3v0Az28EznC+82obRpu1As7SF6uuSngc7a/Tb5MjuHtLO09VlWbnNxrtu0NLMydK6
         LvHvRyluW3wiRv2ALQdQ0elkxQJh5S1MYSxzXzkK+Ec5dPHGY3lgQxdVhD4Bi/P1qWz4
         yJ7U3cBUFwBQAih8XOWCWV/o2QA2S1Zl0JTBLe1+biX40WnHTIkcbrF50UXjb2uleX/w
         tYiNJ4JuNVlOlnKPItgpGGh29AU0AafKOiytO21f2oiPQg9xU2Dr38te4LIvibK4hE4I
         VSMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737478648; x=1738083448;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=bTA4jnXzYEFzhmsmqQFRKNCJDj+5qOjoNV3nC5NctjY=;
        b=SDPpId56fPNFqvfK/y4meCE/yH4T4Jn6yufmrXvRQAXtKKzVSHUEWXzd8kirNXoVPg
         5nEBRmDX/ZiHZfVh4o1yRlTt+BVE3CaN9mPtPlygxI2qmfGfV0fvNYgC45/MHPDvf7Lr
         H1i4VBuRsysGhATvQ6iM4hZEcelNpm85lvEPB5l2vZ96t/S+JaKgu+e0tjWACOS1EgJ9
         G7oqns6YjThtM4G4tq8dXyllOfq/UQFJgXEhCnd4VHw33EXPRH/ZYmsn0bMn3KSJpUFu
         FVKQsRoyw3Hf/q5rca0J6b++KXpkB2Tudp8dYsKa9OhzjbEJWKyI2mJi8Sr4/rP0aie/
         yVRA==
X-Forwarded-Encrypted: i=1; AJvYcCV5MHJpCt5dFabCRuvnso6YWduo4boU/Av9ZnB8Fwi2tCW73th1WuT/jbCZiy6DnKJPZMHFzPucEJE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyOBgVQ76gbVDGPI5dbl2Mttq5QonxyTyw1W0eXDWS/zpI/gh48
	IFrsXEhD1DiiuYCybjVScIPk8SgbZfYPf7kag0H+69g1k7ZezGhr
X-Gm-Gg: ASbGncsH65qGZsdJr+CznEUAMC5a462od5IoejKFQoKcoOIit8ydS2x8LC3FjHG+XAG
	xpT4sDtArUu9p3i6VrBuRSH7pUD8h9jnuNZY0R5iNo97wue05C1wjLdFYgFXFfuGr58LQy8sJPz
	UmX0Wvw4d2lKNnw8zIZ3Y5Og1UJqJsWAgLb3mt+Ay8s+eYqMq3/XqrYOvYftl/uqPQxQQ575F9z
	brVirc70Spc6zZ9amFy75sV1NRG8I1WlspWIV/HoVeJnlqvfAgJ0zU1gkzYeY4H1MovixXVzN4J
	+aZhQ/U=
X-Google-Smtp-Source: AGHT+IEmqlkmLB6r+6X22LkqrvhDpJYh2ZTxsooDO9jLNU/yUB5ZwPsm0rpXL/w8Af4/5yAFgkeyAw==
X-Received: by 2002:ac2:4541:0:b0:53e:389d:8ce4 with SMTP id 2adb3069b0e04-5439c281f4fmr5546707e87.34.1737478647331;
        Tue, 21 Jan 2025 08:57:27 -0800 (PST)
Message-ID: <eb58ed74-1156-4de5-8392-a546d9afddc3@gmail.com>
Date: Tue, 21 Jan 2025 17:57:26 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20] x86/intel: Fix PERF_GLOBAL fixup when
 virtualised
To: Andrew Cooper <andrew.cooper3@citrix.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
Cc: Jonathan Katz <jonathan.katz@aptar.com>, Jan Beulich <JBeulich@suse.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
References: <20250121142510.358996-1-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <20250121142510.358996-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


On 1/21/25 3:25 PM, Andrew Cooper wrote:
> Logic using performance counters needs to look at
> MSR_MISC_ENABLE.PERF_AVAILABLE before touching any other resources.
>
> When virtualised under ESX, Xen dies with a #GP fault trying to read
> MSR_CORE_PERF_GLOBAL_CTRL.
>
> Factor this logic out into a separate function (it's already too squashed to
> the RHS), and insert a check of MSR_MISC_ENABLE.PERF_AVAILABLE.
>
> This also limits setting X86_FEATURE_ARCH_PERFMON, although oprofile (the only
> consumer of this flag) cross-checks too.
>
> Reported-by: Jonathan Katz <jonathan.katz@aptar.com>
> Link: https://xcp-ng.org/forum/topic/10286/nesting-xcp-ng-on-esx-8
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> CC: Jan Beulich <JBeulich@suse.com>
> CC: Roger Pau Monné <roger.pau@citrix.com>
> CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
>
> Untested, but this is the same pattern used by oprofile and watchdog setup.

Probably it will make sense to wait for a response on the forum (you 
mentioned in the Link:) that the current one patch works?

~ Oleksii

>
> I've intentionally stopped using Intel style.  This file is already mixed (as
> visible even in context), and it doesn't remotely resemble it's Linux origin
> any more.
>
> For 4.20.  This regressions has already been backported.
> ---
>   xen/arch/x86/cpu/intel.c | 64 +++++++++++++++++++++++-----------------
>   1 file changed, 37 insertions(+), 27 deletions(-)
>
> diff --git a/xen/arch/x86/cpu/intel.c b/xen/arch/x86/cpu/intel.c
> index 6a7347968ba2..586ae84d806d 100644
> --- a/xen/arch/x86/cpu/intel.c
> +++ b/xen/arch/x86/cpu/intel.c
> @@ -535,39 +535,49 @@ static void intel_log_freq(const struct cpuinfo_x86 *c)
>       printk("%u MHz\n", (factor * max_ratio + 50) / 100);
>   }
>   
> +static void init_intel_perf(struct cpuinfo_x86 *c)
> +{
> +    uint64_t val;
> +    unsigned int eax, ver, nr_cnt;
> +
> +    if ( c->cpuid_level <= 9 ||
> +         rdmsr_safe(MSR_IA32_MISC_ENABLE, val) ||
> +         !(val & MSR_IA32_MISC_ENABLE_PERF_AVAIL) )
> +        return;
> +
> +    eax = cpuid_eax(10);
> +    ver = eax & 0xff;
> +    nr_cnt = (eax >> 8) & 0xff;
> +
> +    if ( ver && nr_cnt > 1 && nr_cnt <= 32 )
> +    {
> +        unsigned int cnt_mask = (1UL << nr_cnt) - 1;
> +
> +        /*
> +         * On (some?) Sapphire/Emerald Rapids platforms each package-BSP
> +         * starts with all the enable bits for the general-purpose PMCs
> +         * cleared.  Adjust so counters can be enabled from EVNTSEL.
> +         */
> +        rdmsrl(MSR_CORE_PERF_GLOBAL_CTRL, val);
> +
> +        if ( (val & cnt_mask) != cnt_mask )
> +        {
> +            printk("FIRMWARE BUG: CPU%u invalid PERF_GLOBAL_CTRL: %#"PRIx64" adjusting to %#"PRIx64"\n",
> +                   smp_processor_id(), val, val | cnt_mask);
> +            wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, val | cnt_mask);
> +        }
> +    }
> +
> +    __set_bit(X86_FEATURE_ARCH_PERFMON, c->x86_capability);
> +}
> +
>   static void cf_check init_intel(struct cpuinfo_x86 *c)
>   {
>   	/* Detect the extended topology information if available */
>   	detect_extended_topology(c);
>   
>   	init_intel_cacheinfo(c);
> -	if (c->cpuid_level > 9) {
> -		unsigned eax = cpuid_eax(10);
> -		unsigned int cnt = (eax >> 8) & 0xff;
> -
> -		/* Check for version and the number of counters */
> -		if ((eax & 0xff) && (cnt > 1) && (cnt <= 32)) {
> -			uint64_t global_ctrl;
> -			unsigned int cnt_mask = (1UL << cnt) - 1;
> -
> -			/*
> -			 * On (some?) Sapphire/Emerald Rapids platforms each
> -			 * package-BSP starts with all the enable bits for the
> -			 * general-purpose PMCs cleared.  Adjust so counters
> -			 * can be enabled from EVNTSEL.
> -			 */
> -			rdmsrl(MSR_CORE_PERF_GLOBAL_CTRL, global_ctrl);
> -			if ((global_ctrl & cnt_mask) != cnt_mask) {
> -				printk("CPU%u: invalid PERF_GLOBAL_CTRL: %#"
> -				       PRIx64 " adjusting to %#" PRIx64 "\n",
> -				       smp_processor_id(), global_ctrl,
> -				       global_ctrl | cnt_mask);
> -				wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL,
> -				       global_ctrl | cnt_mask);
> -			}
> -			__set_bit(X86_FEATURE_ARCH_PERFMON, c->x86_capability);
> -		}
> -	}
> +	init_intel_perf(c);
>   
>   	if ( !cpu_has(c, X86_FEATURE_XTOPOLOGY) )
>   	{
>
> base-commit: c3f5d1bb40b57d467cb4051eafa86f5933ec9003


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 17:00:23 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 17:00:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875631.1286074 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taHbt-0005iq-Nt; Tue, 21 Jan 2025 17:00:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875631.1286074; Tue, 21 Jan 2025 17:00:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taHbt-0005ij-LG; Tue, 21 Jan 2025 17:00:17 +0000
Received: by outflank-mailman (input) for mailman id 875631;
 Tue, 21 Jan 2025 17:00:15 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=wvur=UN=gmail.com=urezki@srs-se1.protection.inumbo.net>)
 id 1taHbr-0005id-Q0
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 17:00:15 +0000
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com
 [2a00:1450:4864:20::12f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2f2b1153-d819-11ef-a0e4-8be0dac302b0;
 Tue, 21 Jan 2025 18:00:14 +0100 (CET)
Received: by mail-lf1-x12f.google.com with SMTP id
 2adb3069b0e04-53f22fd6832so6170908e87.1
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 09:00:14 -0800 (PST)
Received: from pc636 (host-217-213-93-172.mobileonline.telia.com.
 [217.213.93.172]) by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5439af76fe9sm1916768e87.212.2025.01.21.09.00.08
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 21 Jan 2025 09:00:12 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2f2b1153-d819-11ef-a0e4-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1737478814; x=1738083614; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to;
        bh=6O7kZyVX02YaNVvlK+AnjIGslDTljYFtI1mm3L3G+es=;
        b=MZtQqUN6VI8Z+xYY9kFNJjnjLk3DnCLkjEYBzKlS28hkExIopJp9Dz7mCw1XMYUL3H
         liXrGfPTg0iEcC6go396nNdpyGXcaweKjo5HxfCq0hsp9hymStUW7EIIHEYteekHzdBe
         SV60ILQ/YCuT6rf45KyYm+XGRwwpkkNHVUMq94J76Nwi4TgsaBZ+qo6/Gpbc3fNV35+D
         KKDN/VG7sOhtzjvqsy+552qkRhpejILhZhX2xe5+WavH2+MzQzBXQJ95DgL8UW0ahxjr
         siKj+N0FCCrvYVD4vWmrPp9imWqDvNRNsaq/u2WpYRlIxvtofciY6ZlN/0EHMSK16bsC
         axtA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737478814; x=1738083614;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:date:from:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=6O7kZyVX02YaNVvlK+AnjIGslDTljYFtI1mm3L3G+es=;
        b=HlNwhenZ7C/zgjWoWXYgWElpSlYU4rTjG4La4/D9bOXf1YlWN5JskJlbR9eG6K8hYn
         tMJWJl3Xy5nG0B32yY3QSNFV5M72y8SP+rqafnVlidngrxcllohvOC2LJy9Z3rKQccVr
         1/ASP0HEMC+XvGp8lYwh/KVRF0fNDduKI4b3keBx5LJqcmO06w5i1SmWZ550FXimPXUe
         pEeb3qt1udPw0fT+BJlMafYib/yROJjPtJSFROSt7nwENxFmSM+qpFLcTY8VnZuiDpJu
         WL3Hmwfbwyvv4L1mZsTnD6STEBvljpaOuqjZenXE2w2GKqSk/rp/TQpn2B2UsUGz66/C
         sglw==
X-Forwarded-Encrypted: i=1; AJvYcCXe2Yg88AEi0BMPtie0ef9QpWa6A/qGWe9yJ4hizZHQI7lCqVHFwEbLnBiWuCeCcO+STGawevjkJSA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzW7dAdcbg+Gax+oI4MBNhqHnvWE2vilfWSosVFdcH0QZaHCkZ0
	vBXnVBH7Cd6fJZfiyYePgv47s6wY41Es1W0GO5+xO2DFF6eOAbHF
X-Gm-Gg: ASbGnctArsRnWjYmB8lCpSqv6JWRLsU3F+59NEOP8xwE4/e3XZCHrTTmzoY8Zp3chE0
	PhZowO0DN6EFiJ5l+LcdcJ7iFjDv3Z78HW2weuSK+B8tLPksC5KutRtM84O/KvkLwpt7Yj9FTF0
	/zVA//AEMMZxtPezOko7NsJ6uXD7x5afyIxgMEHOX2cfDzarRnoim/fd2dQqOHUNRn9zkNlIl5B
	UXUBV/mGHPCGrZbrH/sW3v6+06SwAqYupLvrDBUnTHdBL/jkW3aGQ24CsCWmtcdxYFyJFwX3QVg
	kninqJiph2dfR3fplSAeNM7u
X-Google-Smtp-Source: AGHT+IGYPF71D1RmaKnbW82c+U5IMmpDPZJTk/HJCRRaq5z7S90tH0rTVzhA6Sl8Kwc0O/33Vf8jgg==
X-Received: by 2002:a05:6512:104b:b0:543:9b0f:7d39 with SMTP id 2adb3069b0e04-5439c282920mr7151519e87.32.1737478813837;
        Tue, 21 Jan 2025 09:00:13 -0800 (PST)
From: Uladzislau Rezki <urezki@gmail.com>
X-Google-Original-From: Uladzislau Rezki <urezki@pc636>
Date: Tue, 21 Jan 2025 18:00:07 +0100
To: Valentin Schneider <vschneid@redhat.com>
Cc: Uladzislau Rezki <urezki@gmail.com>, Jann Horn <jannh@google.com>,
	linux-kernel@vger.kernel.org, x86@kernel.org,
	virtualization@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev,
	linux-riscv@lists.infradead.org, linux-perf-users@vger.kernel.org,
	xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
	linux-arch@vger.kernel.org, rcu@vger.kernel.org,
	linux-hardening@vger.kernel.org, linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org, bpf@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com,
	Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.amakhalov@broadcom.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andy Lutomirski <luto@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Clark Williams <williams@redhat.com>,
	Yair Podemsky <ypodemsk@redhat.com>,
	Tomas Glozar <tglozar@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
	Kees Cook <kees@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Shuah Khan <shuah@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Miguel Ojeda <ojeda@kernel.org>, Alice Ryhl <aliceryhl@google.com>,
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
	Samuel Holland <samuel.holland@sifive.com>,
	Rong Xu <xur@google.com>,
	Nicolas Saenz Julienne <nsaenzju@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Yosry Ahmed <yosryahmed@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Jinghao Jia <jinghao7@illinois.edu>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: Re: [PATCH v4 29/30] x86/mm, mm/vmalloc: Defer
 flush_tlb_kernel_range() targeting NOHZ_FULL CPUs
Message-ID: <Z4_Sl-zu7GprkbaL@pc636>
References: <20250114175143.81438-1-vschneid@redhat.com>
 <20250114175143.81438-30-vschneid@redhat.com>
 <CAG48ez1Mh+DOy0ysOo7Qioxh1W7xWQyK9CLGNU9TGOsLXbg=gQ@mail.gmail.com>
 <xhsmh34hhh37q.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
 <Z4qBMqcMg16p57av@pc636>
 <xhsmhwmetfk9d.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
 <Z44wSJTXknQVKWb0@pc636>
 <xhsmhr04xfow1.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <xhsmhr04xfow1.mognet@vschneid-thinkpadt14sgen2i.remote.csb>

> >
> > As noted before, we defer flushing for vmalloc. We have a lazy-threshold
> > which can be exposed(if you need it) over sysfs for tuning. So, we can add it.
> >
> 
> In a CPU isolation / NOHZ_FULL context, isolated CPUs will be running a
> single userspace application that will never enter the kernel, unless
> forced to by some interference (e.g. IPI sent from a housekeeping CPU).
> 
> Increasing the lazy threshold would unfortunately only delay the
> interference - housekeeping CPUs are free to run whatever, and so they will
> eventually cause the lazy threshold to be hit and IPI all the CPUs,
> including the isolated/NOHZ_FULL ones.
> 
Do you have any testing results for your workload? I mean how much
potentially we can allocate. Again, maybe it is just enough to back
and once per-hour offload it.

Apart of that how critical IPIing CPUs affect your workloads?

> I was thinking maybe we could subdivide the vmap space into two regions
> with their own thresholds, but a task may allocate/vmap stuff while on a HK
> CPU and be moved to an isolated CPU afterwards, and also I still don't have
> any strong guarantee about what accesses an isolated CPU can do in its
> early entry code :(
> 
I agree this is not worth to play with a vmap space in terms of splitting it.

Sorry for later answer and thank you!

--
Uladzislau Rezki


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 17:04:39 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 17:04:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875641.1286085 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taHg6-0006oi-7u; Tue, 21 Jan 2025 17:04:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875641.1286085; Tue, 21 Jan 2025 17:04:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taHg6-0006ob-5F; Tue, 21 Jan 2025 17:04:38 +0000
Received: by outflank-mailman (input) for mailman id 875641;
 Tue, 21 Jan 2025 17:04:37 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Gode=UN=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1taHg5-0006oV-G0
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 17:04:37 +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 ca80e822-d819-11ef-99a4-01e77a169b0f;
 Tue, 21 Jan 2025 18:04:35 +0100 (CET)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-438a3216fc2so31443905e9.1
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 09:04:35 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-437c75298adsm248530265e9.30.2025.01.21.09.04.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 21 Jan 2025 09:04:34 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ca80e822-d819-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737479075; x=1738083875; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=42MoWso1BmGQpEDbQM3c8i2LYn73IupsdAF3ksm2ifk=;
        b=JBg+dytl3fiiTo4WvLnXfk66lmHqSgfd0UQG+U0RYUc7voAvUX1KYCl1MPhOJPpE4z
         TkGTAfpIV6X1FhlVewxdvbb02iF7qOSzJb109bg53aQs+vLWLgowMpJvPbD+MMJD+LlV
         vxZLdhHE9QQ1SmrpCLneTrTM/5T2M0vSD/gHR2MshtlQKzgJYAmx+jJBSbS5iWhegX61
         G4zLXMAwKGWvXjBGdDkuMjwf8sVQ3Bw2szPlhMTeIIxLlfbbE7fwWShVZm/zwD738w9e
         H7Wrd4lOT0Meq+4tzJnM7J8ZEFgTtvGWgl5njAahqfQJBkq/CMg+OV3Zji2cuJrNEbEH
         zpXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737479075; x=1738083875;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=42MoWso1BmGQpEDbQM3c8i2LYn73IupsdAF3ksm2ifk=;
        b=wnWEApBmS087gVqWgTeJxlcvumPV8kTKGpsk1DKj1P1jRWUhXeKNQ/A1Q62MAYNHO9
         3mAUu7z2bmlCRWdpeRnjkdS8l9ViGI7EIThDg9L9DEOR+VFq8iwxbcf78c6bAC3YGhY3
         JwdzfRBwFdwhfHuQ9O5g4Rh62XxCYcLytOSYdBAkrJBO2cO/2La3lwYKf7tzg6p1OWMV
         z70OYYOgxzAD2eLUXB/JE6ChQrT3DtoVRRiuMCrVSZqFDpniGWGdPdp4sgG3bqIv8TKp
         rHOwmvljMLS40xmOB62innNYWn4oeWGGCYrYdSXes1VhONATiur5+B3CXc40fE11wlaV
         JnwQ==
X-Forwarded-Encrypted: i=1; AJvYcCX1YEaG5/nX+1dPJrdV6T1r+RNpVkM3MlFXcik/lq42SqF7aki6wcAr5AaxMpTBNf5UeKPbeRtMi6g=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxEWKFrNBr8P8bl1akg+V6jvzz/lIH3ZjIsvC/Hw/QeDDhSkjYy
	gUF/SaxdVIuMXhiueM0hlcBX3M0H0gGqNALACt0CwbscI+UgfSfR0oQOmvS1PA==
X-Gm-Gg: ASbGnctWKckfd7RdSrp66xiXFo6xGw4Nh9//NKmpYlBN+JrbeYLBOPCNBs66IBXs2Jn
	p++HNg9Xsc3CQw7uK7Fng7XIqSMk30q+ugBvyjNHasA/jE+C3HrQFbkDBErI3LpAEqZ7z0uS35v
	Dy1PXXRNHP6DdTJMFyLIGL9OFK75OupgpqRGctxypX5y7JMgZECwRuE7nTMmx21m8cadVFObmt5
	Jig8ESfSkYytkd81EdIwgcq2ESif8Q8pBoVI5rBeiSRyl/SfRze/GRiOBgoabB5M7t0Omio8i3W
	+M/IGrJybm8cOz2ivMuhElg48Juj4lzzQeBCsmBD8nkV7jN89NU4NHE=
X-Google-Smtp-Source: AGHT+IEkABKMT+dXN1ujGpLRwwiARZqTdWN1FzdFhlY4bctwIEx0gIDcYl9E1l0rmoHXsR4a8PyItA==
X-Received: by 2002:a05:600c:3b26:b0:434:a0bf:98ea with SMTP id 5b1f17b1804b1-438913cd4a1mr158634355e9.9.1737479074940;
        Tue, 21 Jan 2025 09:04:34 -0800 (PST)
Message-ID: <741f15ea-2c54-4e02-8be6-bcce10c7393b@suse.com>
Date: Tue, 21 Jan 2025 18:04:33 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20 v2] x86/intel: Fix PERF_GLOBAL fixup when
 virtualised
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Jonathan Katz <jonathan.katz@aptar.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20250121142510.358996-1-andrew.cooper3@citrix.com>
 <20250121165626.380627-1-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250121165626.380627-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 21.01.2025 17:56, Andrew Cooper wrote:
> --- a/xen/arch/x86/cpu/intel.c
> +++ b/xen/arch/x86/cpu/intel.c
> @@ -535,39 +535,49 @@ static void intel_log_freq(const struct cpuinfo_x86 *c)
>      printk("%u MHz\n", (factor * max_ratio + 50) / 100);
>  }
>  
> +static void init_intel_perf(struct cpuinfo_x86 *c)
> +{
> +    uint64_t val;
> +    unsigned int eax, ver, nr_cnt;
> +
> +    if ( c->cpuid_level <= 9 ||
> +         ({  rdmsrl(MSR_IA32_MISC_ENABLE, val);

Just curious (not an objection or anything): Is there a reason you have
two padding blanks here instead of just one? (Really we may want to gain
a function-like form to invoke RDMSR, but that's orthogonal to the change
here.)

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 17:07:47 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 17:07:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875650.1286094 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taHj3-0007MS-KG; Tue, 21 Jan 2025 17:07:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875650.1286094; Tue, 21 Jan 2025 17:07:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taHj3-0007ML-Ha; Tue, 21 Jan 2025 17:07:41 +0000
Received: by outflank-mailman (input) for mailman id 875650;
 Tue, 21 Jan 2025 17:07:40 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=qQWO=UN=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1taHj2-0007MF-KQ
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 17:07:40 +0000
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com
 [2a00:1450:4864:20::431])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 383d8d6d-d81a-11ef-a0e4-8be0dac302b0;
 Tue, 21 Jan 2025 18:07:39 +0100 (CET)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-38789e5b6a7so3411966f8f.1
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 09:07:39 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38bf322a859sm13683445f8f.43.2025.01.21.09.07.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 21 Jan 2025 09:07:38 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 383d8d6d-d81a-11ef-a0e4-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737479259; x=1738084059; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=AJzUpIejbduRBYy2kvT1O33GN715gAdfV7786VAfMWg=;
        b=ZsO2Lh6yejoEEbhhARg9exs0YEcysfbxrgd4s33cD+cJJpWeOnHI2n8vzgl00LGZFo
         QihaOyUjMz5trjwazLm9gNdueLHUyWU/Oc6llbPj1XLeBzX8EgZF6Yc1fWM5xazRfK5p
         3iN+MyYHiGJ7SlRVxD6To1Zu4RaFibTpWoZdg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737479259; x=1738084059;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=AJzUpIejbduRBYy2kvT1O33GN715gAdfV7786VAfMWg=;
        b=iLT9tDM4YJssARFnYskb/m69/vcUYBq59mUDgszHGgoKuWDZCuSFApVZtmkjYEJ5Nd
         rRk/ha0Cg7mk6VikjPZJB/92ULoAoWEkBMfRDFMNytbM0ubAuyOmg2Bv1IuOgpJNVSiz
         K4v8dBjQ8gngDVtvqqzoIsKfkPLDp5ToR4X8U2dwpRU2b7svGlZ6sl8SrbFKh2tpreM1
         +TejZKF/kqNitLuumrB9H2I5TLjlp/LEo+l2gPDBriURbMBQ5ELPfvYM0idblbDHghUb
         GBNRyQmGhOjL33NoSB0IFgTgxobquojCSpfAnBUOckqr8B+wjW6Dma8yHKtldgy9n3lV
         Z3mQ==
X-Forwarded-Encrypted: i=1; AJvYcCXzFhv2R6w83R9nDG9y+ZRLm2q18wJRHlBhHWtbe/mTOcEC4TKuxRXJuPjReR8U+k5Y1Eh6cUph4iw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyyv7f+plBjsftuUOjvTTxIqmelis5LvVHfv+2fuXfHETvepW4A
	xnDv/narILBCJ4Ply4UJVnI6U8rrU1XnimPWQ8dM2XEleFQEr4uOnfmkMABSLes=
X-Gm-Gg: ASbGncuMrkYEEtAkZREbEuot7ReQsJfPpSymswbva4UyYw5L+vR2XniKrSCoVQNGsYy
	tDEUyTnXY9djwLEE4Ms3pLOXpUDhoeGkIJmaQX9DqQWafUY3YIAPxLKffweKpWjl0mqS4ePHNFQ
	MmzGJZnXNI6O6QCvKyLfqEOINiRPiUXRTnf1I/tC8cNpi6GlwalchPfABZzyqT6A3Ls6SwzYjm/
	U8M4FDc8Dit/AWzvYO5rQGrXC3o5aWQzCzv41PKyCMeO6ZZ744SZ94efXEPQWFCZLmJz3F7NBXK
	1Mb0yE4E27dbGp4C+dl0GISjgtjX0NEpbw==
X-Google-Smtp-Source: AGHT+IFAmYxdDbFDiO95xQDGwz1F9G0T2sQUI89BOl+FnWANhuXHVcXT7nLKQcNPrMqh+vcnclW6gg==
X-Received: by 2002:a5d:47cf:0:b0:38c:1270:f964 with SMTP id ffacd0b85a97d-38c1270fbaamr5894163f8f.47.1737479259181;
        Tue, 21 Jan 2025 09:07:39 -0800 (PST)
Message-ID: <fb62d881-720e-499f-a301-fdf1880b097c@citrix.com>
Date: Tue, 21 Jan 2025 17:07:38 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20 v2] x86/intel: Fix PERF_GLOBAL fixup when
 virtualised
To: Jan Beulich <jbeulich@suse.com>
Cc: Jonathan Katz <jonathan.katz@aptar.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20250121142510.358996-1-andrew.cooper3@citrix.com>
 <20250121165626.380627-1-andrew.cooper3@citrix.com>
 <741f15ea-2c54-4e02-8be6-bcce10c7393b@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <741f15ea-2c54-4e02-8be6-bcce10c7393b@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 21/01/2025 5:04 pm, Jan Beulich wrote:
> On 21.01.2025 17:56, Andrew Cooper wrote:
>> --- a/xen/arch/x86/cpu/intel.c
>> +++ b/xen/arch/x86/cpu/intel.c
>> @@ -535,39 +535,49 @@ static void intel_log_freq(const struct cpuinfo_x86 *c)
>>      printk("%u MHz\n", (factor * max_ratio + 50) / 100);
>>  }
>>  
>> +static void init_intel_perf(struct cpuinfo_x86 *c)
>> +{
>> +    uint64_t val;
>> +    unsigned int eax, ver, nr_cnt;
>> +
>> +    if ( c->cpuid_level <= 9 ||
>> +         ({  rdmsrl(MSR_IA32_MISC_ENABLE, val);
> Just curious (not an objection or anything): Is there a reason you have
> two padding blanks here instead of just one?

Alignment with the next line.

> (Really we may want to gain
> a function-like form to invoke RDMSR, but that's orthogonal to the change
> here.)

Indeed.

* def0701b5373 - (xen-nj-msr) switch rdmsrl => rdmsr (30 hours ago)
<Andrew Cooper>
* 1a3f92abccf1 - rdmsr (30 hours ago) <Andrew Cooper>
* 01c9ec7d9482 - rdmsr_safe (30 hours ago) <Andrew Cooper>
* 7ec72a0379b2 - fix error printing in write_msr() (30 hours ago)
<Andrew Cooper>
* 3ff3d60835a5 - drop wrmsrl (30 hours ago) <Andrew Cooper>
* 136128799b4a - wrmsr cleanup (30 hours ago) <Andrew Cooper>
* b2ed78d2e7e3 - x86/msr: Move MSR_FEATURE_CONTROL handling to the new
MSR infrastructure (30 hours ago) <Andrew Cooper>
* 7691edea3d67 - x86/msr: Clean up the MSR_DEBUGCTL constants (30 hours
ago) <Andrew Cooper>
* 77ba2827a955 - x86/msr: Clean up the MSR_MISC_ENABLE constants (30
hours ago) <Andrew Cooper>
* 7f2768cfc4b3 - ---upstream--- (30 hours ago) <Andrew Cooper>
* 8b2e048fdd14 - x86/msr: Introduce msr_{set,clear}_bits() helpers (30
hours ago) <Andrew Cooper>
* 562f88503342 - x86/msr: Clean up the MSR_FEATURE_CONTROL constants (30
hours ago) <Andrew Cooper>
* 199888c9e2f8 - x86/msr: Clean up the
MSR_{PLATFORM_INFO,MISC_FEATURES_ENABLES} constants (30 hours ago)
<Andrew Cooper>
* c3f5d1bb40b5 - (tag: 4.20.0-rc2, xenbits/staging, xenbits/master,
upstream/staging, upstream/master, origin/staging, origin/master,
origin/HEAD, staging, pending, master) automation/cirrus-ci: introduce
FreeBSD randconfig builds (4 days ago) <Roger Pau Monne>

That was work I did while sat in an airport unable to leave XenSummit in
Nanjing...

It's blocked on arguments over naming.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 18:02:58 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 18:02:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875662.1286105 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taIaI-0007fk-Il; Tue, 21 Jan 2025 18:02:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875662.1286105; Tue, 21 Jan 2025 18:02:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taIaI-0007fd-Ei; Tue, 21 Jan 2025 18:02:42 +0000
Received: by outflank-mailman (input) for mailman id 875662;
 Tue, 21 Jan 2025 18:02:41 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=jEc5=UN=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1taIaG-0007fX-VF
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 18:02:41 +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 e6924a69-d821-11ef-99a4-01e77a169b0f;
 Tue, 21 Jan 2025 19:02:38 +0100 (CET)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-ab39f84cbf1so719639666b.3
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 10:02:38 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab384f86272sm783077866b.131.2025.01.21.10.02.35
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 21 Jan 2025 10:02:35 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e6924a69-d821-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737482558; x=1738087358; 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=GJk/G0s9PSVIMmLyL9Z6K7hA1vh4XdMlLF14FiECGDo=;
        b=l+qQgJH2uisqQAZTtXzxpQkeyFqpm7PeopeiWjPxxQ75sw0nUImA+uT8ezYj2CfIhN
         FpxqPhVPKZfKnr7nLtEH7kHfAITeBw89V1hEammYS4vnQhX/CrsTGsrt6/CCX9GYLOEq
         0Go5p/exeYiV8MlkvAjjPoaFxCKJIMYTnUEYE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737482558; x=1738087358;
        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=GJk/G0s9PSVIMmLyL9Z6K7hA1vh4XdMlLF14FiECGDo=;
        b=kRLMhRJeZTak2BVlP1r84VeoUobacLy3c3P/V9fYxD6wuceSCEInustOSUd7XrVU8z
         pgfh8skQoZ7lu7tvCNAWikssH0AosGnfdguSleGVkkGSLj1GmAe48LjLolgW3Hj4I2Tq
         Wlcfu3RIZ8cDLPsXGG7Gz3f+9tLxttBnPUX3vD2GGx6zxuo0yK1BZ2E4Wuh2amPYNyP/
         9M3ni5MITn1JQC6qcOfhWiDlwvxT/o8yyeTysTXEZfZIusNJw1ma5fZUOxzAoxzvfYAB
         LWFqAxenFd3CGBp/mOTdK0mDwL2Afhs096RZ1oBOBHAOWs6YOOdiW9RlWsn71PW2BVr8
         nR4g==
X-Forwarded-Encrypted: i=1; AJvYcCUYnUZe+kTqDHdfAtwrEvJaAou6dQeUOWSC0Tpa/3fUuwo9CEdJoHwBKwKuuS9qqP6b7AWb+NiwwNY=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxfm1BUTlJp8qbwA6cLAX5OsatE0IBD3JysU626Eg0yFuDuiuNo
	0/A65EZApfJsDEEqMQKiWcdlJn3Xd22i/nBDpBNP8BlEcEjTleJps5deXcA1v9w=
X-Gm-Gg: ASbGncvPeKK+AJFhrRVWbwJ/6hwzisK1o4ISyd1cXBbU8alMshkccmGCA8crKchVcrT
	mzCcxrSiGgsK+jDZsSzzUwgsyegw2B7/A/kdpjNN+ozg6f6gjmeWmFAOIc7D1Ju+pZ8TcJVPFI3
	WRAec520dlBmwFKz6BWKsmDKxdRV/74as+F5GRME4pr5kWL2IAmbxCADDXuWWzILt52QjzqwoSB
	nImCnxCRydFHLITquJ9//LbWLihLtvnc0F2J1fLPDKrSwkNOK8YfK7bzZIJlZqWY6ibNw6KGDY=
X-Google-Smtp-Source: AGHT+IEX/pcZDUDZCmo0FxPsa1DFtDpMkew0eUS2Md/SqwLoEM2qmXnWuROzFUJZvz6Hx+j4T9GeEA==
X-Received: by 2002:a17:907:969f:b0:aa6:8dcb:365c with SMTP id a640c23a62f3a-ab38b3ce55fmr2026298066b.49.1737482556484;
        Tue, 21 Jan 2025 10:02:36 -0800 (PST)
Date: Tue, 21 Jan 2025 19:02:34 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Alejandro Vallejo <alejandro.vallejo@cloud.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Julien Grall <julien@xen.org>, Wei Liu <wl@xen.org>,
	sergiy_kibrik@epam.com
Subject: Re: [PATCH v2 1/4] x86: provide an inverted Kconfig control for
 shim-exclusive mode
Message-ID: <Z4_hOmi01AkiYH_k@macbook.local>
References: <Z4oxZSUQ6VARiR0H@macbook.local>
 <D74CH4RDRRR9.ZR6RL8U6PQ56@cloud.com>
 <6285f86d-f2d2-4040-999d-01aed3e72a36@suse.com>
 <alpine.DEB.2.22.394.2501171430570.2684657@ubuntu-linux-20-04-desktop>
 <f8c1e2c2-ceb5-4200-a304-e2d824a171a8@citrix.com>
 <40c9d806-000d-43e7-a804-ad4e84209b2f@suse.com>
 <alpine.DEB.2.22.394.2501201527090.11086@ubuntu-linux-20-04-desktop>
 <bae48627-fa5b-48b6-b74e-267285175eff@suse.com>
 <Z49gQBkxCbXIO84D@macbook.local>
 <41859184-bd9c-420f-96c1-65abe379b81e@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <41859184-bd9c-420f-96c1-65abe379b81e@suse.com>

On Tue, Jan 21, 2025 at 11:35:42AM +0100, Jan Beulich wrote:
> On 21.01.2025 09:52, Roger Pau Monné wrote:
> > On Tue, Jan 21, 2025 at 09:13:38AM +0100, Jan Beulich wrote:
> >> On 21.01.2025 00:27, Stefano Stabellini wrote:
> >>> On Mon, 20 Jan 2025, Jan Beulich wrote:
> >>>> On 18.01.2025 00:41, Andrew Cooper wrote:
> >>>>> On 17/01/2025 10:43 pm, Stefano Stabellini wrote:
> >>>>>> On Fri, 17 Jan 2025, Jan Beulich wrote:
> >>>>>>> On 17.01.2025 13:24, Alejandro Vallejo wrote:
> >>>>>>>> On Fri Jan 17, 2025 at 10:31 AM GMT, Roger Pau Monné wrote:
> >>>>>>>>> On Thu, Jan 16, 2025 at 04:31:46PM -0800, Stefano Stabellini wrote:
> >>>>>>>>>> On Wed, 1 Mar 2023, Jan Beulich wrote:
> >>>>>>>>>>> While we want certain things turned off in shim-exclusive mode, doing
> >>>>>>>>>>> so via "depends on !PV_SHIM_EXCLUSIVE" badly affects allyesconfig: Since
> >>>>>>>>>>> that will turn on PV_SHIM_EXCLUSIVE, other options will be turned off as
> >>>>>>>>>>> a result. Yet allyesconfig wants to enable as much of the functionality
> >>>>>>>>>>> as possible.
> >>>>>>>>>>>
> >>>>>>>>>>> Retain PV_SHIM_EXCLUSIVE as a prompt-less option such that first of all
> >>>>>>>>>>> C code using it can remain as is. This isn't just for less code churn,
> >>>>>>>>>>> but also because I think that symbol is more logical to use in many
> >>>>>>>>>>> (all?) places.
> >>>>>>>>>>>
> >>>>>>>>>>> Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
> >>>>>>>>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >>>>>>>>>>>
> >>>>>>>>>>> ---
> >>>>>>>>>>> The new Kconfig control's name is up for improvement suggestions, but I
> >>>>>>>>>>> think it's already better than the originally thought of
> >>>>>>>>>>> FULL_HYPERVISOR.
> >>>>>>>>>> I think the approach in general is OK, maybe we can improve the naming
> >>>>>>>>>> further. What about one of the following?
> >>>>>>>>>>
> >>>>>>>>>> NO_PV_SHIM_EXCLUSIVE
> >>>>>>>>>> PV_SHIM_NOT_EXCLUSIVE
> >>>>>>>>> IMO negated options are confusing, and if possible I think we should
> >>>>>>>>> avoid using them unless strictly necessary.
> >>>>>>>> The problem is that the option is negative in nature. It's asking for
> >>>>>>>> hypervisor without _something_. I do agree with Stefano that shim would be
> >>>>>>>> better in the name. Otherwise readers are forced to play divination tricks.
> >>>>>>>>
> >>>>>>>> How about something like:
> >>>>>>>>
> >>>>>>>>     SHIMLESS_HYPERVISOR
> >>>>>>>>
> >>>>>>>> That's arguably not negated, preserves "shim" in the name and has the correct
> >>>>>>>> polarity for allyesconfig to yield the right thing.
> >>>>>>> Except that a hypervisor with this option enabled isn't shim-less, but permits
> >>>>>>> working in shim as well as in non-shim mode.
> >>>>>> First, let's recognize that we have two opposing requirements. One
> >>>>>> requirement is to make it as easy as possible to configure for the user.
> >>>>>> Ideally without using negative CONFIG options, such as
> >>>>>> NO_PV_SHIM_EXCLUSIVE. From the user point of view, honestly,
> >>>>>> PV_SHIM_EXCLUSIVE is a pretty good name. Better than all of the others,
> >>>>>> I think.
> >>>>>>
> >>>>>> On the other hand, we have the requirement that we don't want
> >>>>>> allyesconfig to end up disabling a bunch of CONFIG options. Now this
> >>>>>> requirement can be satisfied easily by adding something like
> >>>>>> NO_PV_SHIM_EXCLUSIVE. However, it would go somewhat against the previous
> >>>>>> requirement.
> >>>>>>
> >>>>>> So we need a compromise, something that doesn't end up disabling other
> >>>>>> CONFIG options, to make allyesconfig happy, but also not too confusing
> >>>>>> for the user (which is a matter of personal opinion).
> >>>>>>
> >>>>>> In short, expect that people will have different opinions on this and
> >>>>>> will find different compromises better or worse. For one, I prefer to
> >>>>>> compromise on "no negative CONFIG options" and use
> >>>>>> PV_SHIM_NOT_EXCLUSIVE. Because it serves the allyesconfig goal, and
> >>>>>> while it is not as clear as PV_SHIM_EXCLUSIVE, is still better than a
> >>>>>> completely generic FULL_HYPERVISOR option, which means nothing to me.
> >>>>>>
> >>>>>> I cannot see a way to have a good and clear non-negated CONFIG option,
> >>>>>> and also satisfy the allyesconfig requirement. So I prefer to compromise
> >>>>>> on the "non-negated" part.
> >>>>>
> >>>>> Debating the naming is missing the point.
> >>>>>
> >>>>>
> >>>>> The problem here is the wish to have PV_SHIM_EXCLUSIVE behave in a way
> >>>>> that Kconfig is not capable of expressing.  Specifically, what is broken
> >>>>> is having "lower level" options inhibit unrelated "higher level" options
> >>>>> when the graph gets rescanned[1].  That's why we're in the laughable
> >>>>> position of `make allyesconfig` turning off CONFIG_HVM.
> >>>>>
> >>>>> Jan, you want "echo PV_SHIM_EXCLUSIVE=y >> .config && make" to mean
> >>>>> "reset me back to a PV Shim".
> >>>>
> >>>> Isn't this an independent goal? Or is this a statement on what you see
> >>>> my change (kind of) doing, indicating you consider this wrong?
> >>>
> >>> The way I understood it, it is the latter
> >>>
> >>>
> >>>>> Kconfig spells this "make $foo_defconfig" for an appropriately given foo.
> >>>>>
> >>>>>
> >>>>> There should be:
> >>>>>
> >>>>> 1) an option called PV_SHIM_EXCLUSIVE which does *nothing* other than
> >>>>> making the boolean be a compile time constant.
> >>>>
> >>>> I fear it remains unclear to me what exactly you mean here. It feels like
> >>>> you may be suggesting that all other uses of PV_SHIM_EXCLUSIVE should be
> >>>> dropped, without replacement. That seems wrong to me, though. In
> >>>> particular I'm of the opinion that besides using "make pvshim_defconfig"
> >>>> people ought to also have the option to properly configure a shim build
> >>>> from scratch (or from any random .config they hold in hands), requiring
> >>>> respective "depends on" and/or "select" / "imply" to be in place.
> >>>
> >>> That should be done with "make pvshim_defconfig"
> >>
> >> Why? Specifically, why should people use only one entirely nailed down
> >> configuration for a shim. Like a "normal" hypervisor, there are aspects
> >> which very well can be left to the person doing the configuration.
> > 
> > But nothing prevents a user from starting from a shim defconfig, and
> > then tweaking it as desired:
> > 
> > $ make pvshim_defconfig
> > $ make menuconfig
> > 
> > Or there's something I'm missing here?
> 
> Well, no, you don't. But if the above is okay, why would not starting from
> pvshim_defconfig not also be okay? Plus whichever way tweaks are done,
> sensible dependencies should still be enforced imo.

Not starting from pvshim_defconfig should always be OK, as the
defconfig file is just a set of options that the user can otherwise
enable manually.

There are two different things that PV_SHIM_EXCLUSIVE accomplishes:
 - Use to remove code blocks or change defines:  for example
   short-circuiting PG_log_dirty to 0.  This should likely be done
   using a different more fine grained set of Kconfig options.
 - Convert pv_shim to a compile time constant: this is the tricky part
   IMO, as such conversion will force DCO and thus make the resulting
   Xen binary no longer what a user would expect when using
   allyesconfig.

> >>>> Or else they may end up with a lot of dead code. (Just consider e.g.
> >>>> HVM=n: We also don't permit HVM-only stuff to be enabled in that case,
> >>>> as any of that would again be dead code then.)
> >>>
> >>> It will always be possible to come up with poor configurations. I do not
> >>> believe it is necessarily our responsibility to go out of our way to
> >>> prevent them.
> >>
> >> Well - if so, why would we do this in some cases but not in others?
> >> You may recall that I'm a proponent of consistency and predictability.
> >>
> >>>>> 2) a pvshim_defconfig target which expresses what a pvshim ought to look
> >>>>> like.
> >>>>
> >>>> We have this file already. I consider it debatable though whether this file
> >>>> should really force PV_SHIM_EXCLUSIVE=y. People may read "pvshim" in the
> >>>> name as either "works just as shim" or "can also work as shim".
> >>>
> >>> If I understood it right, I like Andrew's suggestion. He is suggesting
> >>> to do the following:
> >>>
> >>> - turning PV_SHIM_EXCLUSIVE into something that does nothing
> >>
> >> FTAOD - you mean Kconfig-wise? Andrew clearly didn't say "nothing", but
> >> "nothing other than making the boolean be a compile time constant".
> > 
> > Won't making the boolean a compile time constant would also result in
> > DCO kicking in and removing a fair amount of code?  So even if you
> > have enabled everything in Kconfig, the resulting hypervisor would
> > only be suitable to be used as a shim?
> 
> Of course.

Then what's the point of this approach?  Options will be enabled in
Kconfig, but the resulting hypervisor build when using allyesconfig
would have a lot of them short-circuited, making it even worse than
currently?  As options will get effectively build-time disabled due
to DCO while enabled in Kconfig.

Overall I think PV_SHIM_EXCLUSIVE should be excluded from
allyesconfig, even with Andrew's proposed change.  Otherwise the
purpose of allyesconfig is defeated if enabling PV_SHIM_EXCLUSIVE
makes the resulting hypervisor build PV shim only.  IIRC we can
provide a default alllyes.config with CONFIG_PV_SHIM_EXCLUSIVE=n.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 23:53:56 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 23:53:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875722.1286140 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taO3v-0007t4-CQ; Tue, 21 Jan 2025 23:53:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875722.1286140; Tue, 21 Jan 2025 23:53:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taO3v-0007sx-8H; Tue, 21 Jan 2025 23:53:39 +0000
Received: by outflank-mailman (input) for mailman id 875722;
 Tue, 21 Jan 2025 23:53: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
 <SRS0=eP5S=UN=amd.com=Jason.Andryuk@srs-se1.protection.inumbo.net>)
 id 1taO3u-0007sr-6F
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 23:53:38 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on20611.outbound.protection.outlook.com
 [2a01:111:f403:2408::611])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ec86888d-d852-11ef-a0e5-8be0dac302b0;
 Wed, 22 Jan 2025 00:53:36 +0100 (CET)
Received: from BN9PR03CA0563.namprd03.prod.outlook.com (2603:10b6:408:138::28)
 by SN7PR12MB7884.namprd12.prod.outlook.com (2603:10b6:806:343::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8356.20; Tue, 21 Jan
 2025 23:53:30 +0000
Received: from BL02EPF0001A0FD.namprd03.prod.outlook.com
 (2603:10b6:408:138:cafe::88) by BN9PR03CA0563.outlook.office365.com
 (2603:10b6:408:138::28) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8356.22 via Frontend Transport; Tue,
 21 Jan 2025 23:53:29 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BL02EPF0001A0FD.mail.protection.outlook.com (10.167.242.104) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8377.8 via Frontend Transport; Tue, 21 Jan 2025 23:53:29 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 21 Jan
 2025 17:53:29 -0600
Received: from [192.168.62.40] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Tue, 21 Jan 2025 17:53:28 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ec86888d-d852-11ef-a0e5-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=tPX7LVZV6k5RRedDe4TRx3pA/U+ahClvMNXnfczAPATkIdgSK80y0u9bE1n/7/uo/poYyHbGtEiQNsCTKn4GngiATj/4Qp3lTXkwU3muEM5vRBhRXqzaBXPrHpYDe3egXCqK//p9zZmjKYO1publ7vkRGFVTdVnngagyTcRDAE91LIkc/N60McN8zMzfbnglfsmMEugSF3YiLBTxxHymQqGoYucM3rC2Yjxk7wm0Ebe/CHbD6wDN7svzl6RIqWQeOE51Adps46lQjT0H5uOSFgF+l+bfmFv53TT3sl0N23371QUFtT97PsKrnxhDPn0da/B+0F1cdTKe+rfzn7vrpA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=af10JZJcWTXMWWC8WnVRNapxtQBCXjCco68gtDJVO3k=;
 b=BxoMoXN/iABxHYCYG73vd9tgwnMmMTekfDFT4t/FbegAHUsLU8/OzrsHQAMdZ7gdnzD9ofD/qt3j+cZSgLYBYSVKGyzOHJONxQYbnv9vgPX1dFZPfS4iXF84ybgutfy4TAhtx5RgemFut0vFUD4CxLS8VHX0ymckSnkifIJMej6qdck0Z16i3yWv67bAvis4m0oDzfKdRRTyRa/RyT/34RpMpEQcH0gbMZg1g4Hv5h0+VKglJqgKGbzPtpKWNUgDMAA0btbLoLW5LPUAZHTjVxEdM57aFbu6k/F1Cxpqg5ez6ViofQHCPxFGVeoojqEmyIcpXymKyVwS3hMls9Z24Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=ford.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=af10JZJcWTXMWWC8WnVRNapxtQBCXjCco68gtDJVO3k=;
 b=OQBPsnk1A3dQRtA4xee4IEWNUrVRhf/7qtQc9cfZxWPAMyJvoef+rUhJH3GL1s04x1rQleLnC9kmyahBwZlryycCzxj+37KeYnBexUySt8B06Osannd4oy1sxqQjaEjphlQSPINfcGnypttiANatLNU7Ut9bHYe5LdLYYtARJho=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <8595e239-079d-43a6-8713-dcabba9136bf@amd.com>
Date: Tue, 21 Jan 2025 17:56:17 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 01/24] xen/ctype: introduce is_console_printable()
To: <dmukhin@ford.com>, <xen-devel@lists.xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
	<julien@xen.org>, Michal Orzel <michal.orzel@amd.com>, Andrew Cooper
	<andrew.cooper3@citrix.com>, Anthony PERARD <anthony.perard@vates.tech>, "Jan
 Beulich" <jbeulich@suse.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
	<roger.pau@citrix.com>
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
 <20250103-vuart-ns8250-v3-v1-1-c5d36b31d66c@ford.com>
Content-Language: en-US
From: Jason Andryuk <jason.andryuk@amd.com>
In-Reply-To: <20250103-vuart-ns8250-v3-v1-1-c5d36b31d66c@ford.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB04.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL02EPF0001A0FD:EE_|SN7PR12MB7884:EE_
X-MS-Office365-Filtering-Correlation-Id: c0ae81b1-4211-4163-77ca-08dd3a76ce51
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|82310400026|1800799024|376014|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?SHRzTDVxY2JwM1UrNm1SMmdzSDNIdUFpZXFtcHZudHYwYjRYbysvTjJYdVQ2?=
 =?utf-8?B?UlFOdHViK1pza1hKTEhjbHNzL3RWejJRRU9mSmRZNXBBUDFSMnNMRkVVSDJ3?=
 =?utf-8?B?NTBEa0hiYklDWDNOM01tQk5qVkVHUHpCcnBMa0RFS1dKVU9TeEVMOXYwOXo0?=
 =?utf-8?B?cG1IYURlVW05QWtReFh6eU0yTkRmQjRsMXYxRU0yTXR4QThKVEowMzlxbTYz?=
 =?utf-8?B?elRTZXhpSFZwb293cHNvZ09mRW5JUXZVb0FsN1VEbkNuQ1pCWmhzR0hWdGdK?=
 =?utf-8?B?REZ1STdybEd0a21BbEhRSk83UHBKRU5kQndkVWVaeXhHbE1Qa0NjTk5QMkRX?=
 =?utf-8?B?QTRKK0l4Q1dWdDFxazBYWWxESWY1c2RIcUtROGlEdWROamxtREppeGxZcFNx?=
 =?utf-8?B?N0F2c20vVFpnZ3Njd3hibWVNWEs2WTY2dUNBWVJ1QjYzL0k4YjIrZUVVdjhy?=
 =?utf-8?B?L2VreGNwanlUb1ZGcHpac0VjbXFDY3F2S2hnWWFiZUJmUkFKT3RkVXo5cW1x?=
 =?utf-8?B?RkJBcW9UbzlwbmlDM0pwbkwwQU1hWHpMcGUrcHJNN0Z6VHUyemN4UGVQMCtS?=
 =?utf-8?B?OTMvM0VWRmRKbVh2clpzWFgzVDJ6Vk5qN2VOTE03cE1kRUhJcUtKNmxGQTZK?=
 =?utf-8?B?cDJJTEVKcnhXMzdteVczZmZLSThrekFab3JJU1IzNWdXaHBSVHdtbjZSQ0NR?=
 =?utf-8?B?M1BEQ3pRSGl3MmJiaFkvNFNXUS9mUXFWOXg5YkJ2T09acURjNHRscXdmWCs0?=
 =?utf-8?B?VFJMQjR2ZkcwanNhcWdsTmkyZ2xKQXE3ZEpyK25jQjRjcXVxRkFLRmxwV3dl?=
 =?utf-8?B?bkZ1dE1PSjA0WUlOa3JkVXVuMkZaME9RZ1VQUHRTbHlLeVRkTmFNUGdETHpL?=
 =?utf-8?B?c05CV2U5T2hSZnAzZTNDaStydHJFNzVMU2M1czlBK1J0eERlN2ZXWXhmOUtY?=
 =?utf-8?B?NlU3akJTeFNTcmx6R2pWZHYveUw0WXI3bENtVWtuUThML243cTJvZ1ZiWGRn?=
 =?utf-8?B?K1Q1QVhhSDBPbFluVkluT0RNR1M3eEJERU0zc1dUckhkM0ZWRHVVUUl4WTF0?=
 =?utf-8?B?N2hrS1JuUG1tK3phL01DcEtML1R2c2VyUjhKNlJzL0xzcktoQVJiSWNzU3dD?=
 =?utf-8?B?bE1FbzJBRmdrV3YwdUFVSFRxdm9HMUJZa24vZ2NHRlhEYk9CVVRrL1lBNnNG?=
 =?utf-8?B?VXRPcjlBMHZBeWtLQlVHaGYxTmJFcTFpTW1UVEU3cTRGdnIwUituTWRQeFFs?=
 =?utf-8?B?aXNETUEwYnZYbTMra3ZCdWFMQWRnd2lrdVRIWUo1TjJFVW5Ldkh2c1lYdnVV?=
 =?utf-8?B?YlprQXNKUnplMjhGZWFDWGNNNkZ0aS8rc0d6NmIzQjBrNUVSMUFrRGNMK0ds?=
 =?utf-8?B?d1FEWmhoOW9KaVBTblRaK1VXQTBoZFEva09TZi9aeTc4cEN1aHExY0xHLzd1?=
 =?utf-8?B?S1FncEpUQmQ1bHFuZ2t0N29vWmxaREVOVHpQTHFSWnpPZllJMlQ3MERCT0lX?=
 =?utf-8?B?TzRhai9aWHFWQU9YWU1OVDZtL2l3Mks2S1BVTEwvc1NrcGZ4YzUvMUZMMVZE?=
 =?utf-8?B?K0xZazBuOFVsME9NaERMY2VvZEZ1Q1VDanR5NDZvbFhMZ1RjcnZ0Y1ptbWlR?=
 =?utf-8?B?dGV5VzVwaG1USWduMmluUjhFbHo1MnBxV3dlcVRRMWhid3BGMmxCU2pCVkpY?=
 =?utf-8?B?c1IvSHdLUyt1cGljNVR5UGpJdkF6dWd2Q1JYV2NGa1J6aDdUbG9vakFFT2dQ?=
 =?utf-8?B?YWdRekFvdDgxdTdVcnhlWVNDVFVVZEp2cWNaaFJBb1Y2Y3NOV3c1QUZ4eXl5?=
 =?utf-8?B?R0Z5RVZOYURVMUlHdFBzMzk3NS9TeFhFbnpSMzZXYkF4ZWxWcDZFQU5lazli?=
 =?utf-8?B?WFB5c1lMdFhrdDcxZzd0VzNIaXQrMXo4UUFIY1NxbUVlQVd1YTJqUlhIU3Ro?=
 =?utf-8?B?OHk2MVl3ODFWZkc1TlV5OW13TStqNzNkMDdzdXZmcTI4QWwvN2o5NThrNUNx?=
 =?utf-8?B?L0luZHdlTCt3PT0=?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(82310400026)(1800799024)(376014)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jan 2025 23:53:29.7694
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c0ae81b1-4211-4163-77ca-08dd3a76ce51
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL02EPF0001A0FD.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB7884

On 2025-01-03 20:58, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin <dmukhin@ford.com>
> 
> There are several console drivers which have same checks w.r.t. printable
> characters. The check is moved to new is_console_printable() function and
> re-used in the UART emulation / guest logging code.
> 
> Also, MISRA rule 21.13 for ctype.h has been exploited while working on
> the code change, reference the rule from ctype.h for future engineers.
> 
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>

> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index 7da8c5296f3b62c6c45131c58fe5cf0e393e9ef3..4cb397116b44935214801c496b30e44c9399c59a 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -674,7 +674,7 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer,
>                   c = *kin++;
>                   if ( c == '\n' )
>                       break;
> -                if ( isprint(c) || c == '\t' )
> +                if ( is_console_printable(c) )
>                       *kout++ = c;

This `if` now accepts newline, but newline is already handled above.  So 
it seems okay to me.

Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>

>               } while ( --kcount > 0 );
>   


From xen-devel-bounces@lists.xenproject.org Tue Jan 21 23:54:00 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Jan 2025 23:54:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875724.1286149 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taO4G-0008Dc-JK; Tue, 21 Jan 2025 23:54:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875724.1286149; Tue, 21 Jan 2025 23:54:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taO4G-0008DV-Gg; Tue, 21 Jan 2025 23:54:00 +0000
Received: by outflank-mailman (input) for mailman id 875724;
 Tue, 21 Jan 2025 23:53:59 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=eP5S=UN=amd.com=Jason.Andryuk@srs-se1.protection.inumbo.net>)
 id 1taO4F-0007sr-N5
 for xen-devel@lists.xenproject.org; Tue, 21 Jan 2025 23:53:59 +0000
Received: from NAM04-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam04on20600.outbound.protection.outlook.com
 [2a01:111:f403:2409::600])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id fab46cdb-d852-11ef-a0e5-8be0dac302b0;
 Wed, 22 Jan 2025 00:53:58 +0100 (CET)
Received: from BN0PR02CA0044.namprd02.prod.outlook.com (2603:10b6:408:e5::19)
 by CYYPR12MB8892.namprd12.prod.outlook.com (2603:10b6:930:be::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8356.20; Tue, 21 Jan
 2025 23:53:55 +0000
Received: from BL02EPF0001A0FB.namprd03.prod.outlook.com
 (2603:10b6:408:e5:cafe::93) by BN0PR02CA0044.outlook.office365.com
 (2603:10b6:408:e5::19) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8356.21 via Frontend Transport; Tue,
 21 Jan 2025 23:53:54 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BL02EPF0001A0FB.mail.protection.outlook.com (10.167.242.102) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8377.8 via Frontend Transport; Tue, 21 Jan 2025 23:53:54 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 21 Jan
 2025 17:53:54 -0600
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB06.amd.com
 (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 21 Jan
 2025 17:53:54 -0600
Received: from [192.168.62.40] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Tue, 21 Jan 2025 17:53:53 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: fab46cdb-d852-11ef-a0e5-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=w8SejpETBUgZzvhJBA4UfMP6ksRSEY2XzX8oSNMvp2lxQ9e+5M+xX9zWYUj725J7KoOD46FXPfM/H0nST5KmpcXteBCeAmfgjVEzO17YQooYwMbHnBEG3giQ6S6FJVHyo9nQ1ReA0no2TbcaM2IOUeuOEW122VK21Dk0HWQcfe2SPeeZnVQd3N8QamlawBSV7ODT7rolhqRyE+waqAhZI5yzlGmiGpeoxiRnTEUbAJQlRgjTIzzbx9uhMVINzQO3hFjAOWKoIoM26lat+zlEPuEY4NfMFeCo/0M4lYE4EIKRcysil5lnWPlV4mP8B8HaB0GmKZi1Z9ngomxusJgruA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=MtwZNlSo1PT/CNoHxOp2k22F/4id72rjUEgzv0Q3XUM=;
 b=JXfc9+JaOIU28hNCOd/5mT8cksoc/KrIzb3UIfHWjYv12U499LIMO9zi5drXCCTASGllcLANvdAUKDCe/0wGt8nYpED7PdOPzB7sS2I7Mf3+ZZCuh7wVCyW/mpRnwm0PzwwRnLLusY3OBxYw2muTl1HrPZIIOIKnes7VGqC5qHTkkWScgnhTxM6YaTLTqe9QdIDbxhpwQJhFU0GUn18yu7blgFFOQf9z7VeeA4FvXX8DgTNHY9gOFVMhdkG4EIDpqSRQ2bUAEd+qbHuuXfItV9GbQuloh5VpKfj990gSjvsZkKQdyzrxIcrrDXKvD3AsdwxCw2IdlEho1l394ZpMbQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=ford.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=MtwZNlSo1PT/CNoHxOp2k22F/4id72rjUEgzv0Q3XUM=;
 b=kjSZ2aA5Pk7nZdusRxCDO0dijmCiJhLKZLLABHPjtB3mAtvTAWPq6uGwflq1IvWERx95i8j0c3TYldz+Wfo+BAP6qfkHtsln6iR3MmW2IARseTpuBHrT2sPS9FDFNap30FMJp/ZHqlvDpR/i+2K/K1TWnzEl0/RAYQHngjr3nlM=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <99bda095-391e-4825-9bb4-c21b7c5e1813@amd.com>
Date: Tue, 21 Jan 2025 17:56:42 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 02/24] arm/vuart: move vpl011-related code to vpl011
 emulator
To: <dmukhin@ford.com>, <xen-devel@lists.xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
	<julien@xen.org>, Michal Orzel <michal.orzel@amd.com>, Andrew Cooper
	<andrew.cooper3@citrix.com>, Anthony PERARD <anthony.perard@vates.tech>, "Jan
 Beulich" <jbeulich@suse.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
	<roger.pau@citrix.com>
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
 <20250103-vuart-ns8250-v3-v1-2-c5d36b31d66c@ford.com>
Content-Language: en-US
From: Jason Andryuk <jason.andryuk@amd.com>
In-Reply-To: <20250103-vuart-ns8250-v3-v1-2-c5d36b31d66c@ford.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL02EPF0001A0FB:EE_|CYYPR12MB8892:EE_
X-MS-Office365-Filtering-Correlation-Id: 4035c2a0-8903-452b-bfc6-08dd3a76dd34
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|36860700013|82310400026|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?TmIrZkVlWU5TVzBQc1Y5bFc3SVU5eGtKbjVycVo4NWJLY0lwaEZvQjFwbmd4?=
 =?utf-8?B?VTk2dzljZzVnSmFZbkkwSXNRcWVGR2pnWE5LWmlnODVtZlU5VzdDR1ZCS2tM?=
 =?utf-8?B?Z1NuMytDbjZablM1aVdHbjY3WmlTYnRhcjEzVktsZEJEamxtTEt2ZVJVVGZE?=
 =?utf-8?B?cDFiUnI2ZUhjUnNxLytYMWExNy9HYlRNY0NsUHdqVE5RQXBpWkUyU001Nngr?=
 =?utf-8?B?RnZwdVIyT3RzWFVkcmpld0xHbUZZWDVYTUtDZ3NJSXNvYS9TaXBneG10Qmg0?=
 =?utf-8?B?N0VPcmJxQkYrTlp1T2YwQWJaOWdzV0pQNEpXdkdrQ3RIMG9RU3NORXpFQ2Fx?=
 =?utf-8?B?WGd6R1NoL3hlTmtiTUZkRVpYRmM5UjhtOGZqR3dPU3EyMWk5TXAvcnI3OGJw?=
 =?utf-8?B?UG1VVG5iMnZKdk12dDlkYU9OVmY5V3RMZ3hldy9VamlzcXhtTWl5Z213RThp?=
 =?utf-8?B?RXRHM3pKNHIvL3pXUDZxOTh3R21JdUMyV1R5N0ZFVGxqeVNJQUdLcHNCTThO?=
 =?utf-8?B?ajZ3cDQ4WFQ3UlFneTJYUTNXSzRPWUZ2QjNJMDFWWTJFaEQxVkJFcWNWa1ZG?=
 =?utf-8?B?U1BJdWw0WUg4cUtxZXRpcEJvWEdtdHRyQ3JOTjJZKzJhTjVnSlpaV0RoOURV?=
 =?utf-8?B?ZVFIWHZ3cVZZTk9teHdrbTlNUzB2RnRra1FoSmRnNUZXcFpJL2EySVMvZjNY?=
 =?utf-8?B?cDJjdDZXUWFUS0tpU1RLcWRxQUQrVmJNR0dnSFc0ZlNobkJZS2laZkZhZ2VK?=
 =?utf-8?B?SlcwYjJhMklKSUZ3MDBqNE9ocUFqV2tzZDJpRVN2TGtKZlNZSjlVQnM1WjV2?=
 =?utf-8?B?d2FQM2xFeWlueEtnaUJkQ2JYWDVLZWNZcWVZWXBFSEJLZGZkN0pleUpmNVNa?=
 =?utf-8?B?OW9xNy9OdkVXRG9STjRVOTA3U0o5K28vSHBCY2RrZ0VpdWkyd01FdGlzMWNC?=
 =?utf-8?B?bU1BUnk1N1pYcWxmYU56aUt6SFZncnhQOXJhR1R2RXlUVGRLc1V6VXdwOHhq?=
 =?utf-8?B?S0FSdENtdzR6M0Z1YmhqWDRmYktteGFmYi85RTc1ZDFQcVo2VzZFMHZ5L0Nv?=
 =?utf-8?B?Z3FXUnQxQlM0Y1lrNzhvU2xDN25DWVJjR210TUU1aUdyTi8rTzQweE0xMisv?=
 =?utf-8?B?clFvN3FTSFdiK3JqZmVMQUtHMEZiTW94bXE5OUMxMnZhbFAzUWhFMHM0TWo4?=
 =?utf-8?B?YmlIY1gxSVhjKzJZTW9hZTBpTFJ0UXRaWVZUMFg4NGlXbm1SR05ZNUt1NGo3?=
 =?utf-8?B?RHVJZkhSZ2JrTXpGeEU0NGVlK292MEdKcGpwejBQazNJM0UvSHFOWS9PekZr?=
 =?utf-8?B?WFdwZ3JQWjV6YUpUYnJHQ01Vcmt2cTFDV253Q1hvNndNRjU0OXFiak9FczdE?=
 =?utf-8?B?MVJGb09qWDJDbzMwZERlbXZjUzZ2ZUhrbngxTThNdHRpVG9JZTBmVXRDSUJs?=
 =?utf-8?B?MCtPNlp0bk9ZYk9SOFBKcGRoYXU1dVh6OWxrMnJybVpZeGxhcXpSVk1US0hX?=
 =?utf-8?B?Szc0TU9FaElvalVWbUtzVHU3K2VMZjd0cmh6Qno2RmlTL2p6ai95VWxUdnVO?=
 =?utf-8?B?VXdQdWRQejBrTExoZmVLU3lNenBNQWQzWUNUYlJLWlJTQVpyOTFjK0ZyRkJr?=
 =?utf-8?B?MlFYME1DRlZXSEdUdkxNR2g5Zk03SWxtZ2hLWWg1SXRYYzBZUDZ3L3JxdGpF?=
 =?utf-8?B?L3phZWdtRFF1Q3cveHdYVlFOZ0c0V2pHOUhSU2Y0d1REb3BNU01hZ0huZzl1?=
 =?utf-8?B?eGI2dVBtditqUkh3ZjAwRjJHZ2dZYUVydHpPTEdmZ1BPZnp6VENDU3lKbVhn?=
 =?utf-8?B?blVmemlHQ3Y4SDl0a0lWRzVpK0Z1bWVFbnZGMU5zZ3RQckRRL3h6Tml2eXho?=
 =?utf-8?B?WGR2ZktoRStjcWxZWXJvcnpwU1pYdkYvTmhickI0TzlQTUxSU0RDZE9KYWNJ?=
 =?utf-8?B?U1lmYld3TDNnUmpvOXBVdmsrVTBra3pweXN2VERXbVZEdDRTaHRMckRMNzJ6?=
 =?utf-8?B?ZWFSbGVleXN3PT0=?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(376014)(36860700013)(82310400026)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jan 2025 23:53:54.7627
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 4035c2a0-8903-452b-bfc6-08dd3a76dd34
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL02EPF0001A0FB.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CYYPR12MB8892

On 2025-01-03 20:58, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin <dmukhin@ford.com>
> 
> Xen console driver has vpl011-related logic which shall belong vpl011 emulator
> code (Arm port). Move vpl011-related code from arch-independent console driver
> to Arm's vpl011.c.
> 
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>

> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index 4cb397116b44935214801c496b30e44c9399c59a..1411c991977b5fb26ee5709e523b7bc32b612808 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c

> @@ -579,6 +571,9 @@ static void __serial_rx(char c)
>       if ( pv_shim && pv_console )
>           consoled_guest_tx(c);
>   #endif
> +
> +    if ( rc )
> +        printk(KERN_ERR "d%pd: failed to process console input: %d\n", d, rc);
>   }
>   
>   static void cf_check serial_rx(char c)
> 

This will print the ENOSPC that was formerly silent.  Since this is 
input from the console, that seems more informative to the user and okay 
to me.

Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>


From xen-devel-bounces@lists.xenproject.org Wed Jan 22 00:22:28 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Jan 2025 00:22:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875739.1286160 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taOVg-0004cM-Re; Wed, 22 Jan 2025 00:22:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875739.1286160; Wed, 22 Jan 2025 00:22:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taOVg-0004cF-Ny; Wed, 22 Jan 2025 00:22:20 +0000
Received: by outflank-mailman (input) for mailman id 875739;
 Wed, 22 Jan 2025 00:22:19 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=VMsP=UO=kernel.org=frederic@srs-se1.protection.inumbo.net>)
 id 1taOVf-0004c9-Ay
 for xen-devel@lists.xenproject.org; Wed, 22 Jan 2025 00:22:19 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ef930b97-d856-11ef-a0e5-8be0dac302b0;
 Wed, 22 Jan 2025 01:22:17 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 5B5B6A42598;
 Wed, 22 Jan 2025 00:20:28 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1A0ECC4CEDF;
 Wed, 22 Jan 2025 00:22:15 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ef930b97-d856-11ef-a0e5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1737505335;
	bh=/jGFli4cvz5GuKwl53vdKodQbbfB6lqGAT1IVg71WEg=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=m6yz2ru+LXXh5xzgW1nRGofBLoFG1mOtZGKi5a///oNnHCh2ZlX7+dcv8uCWMxNTP
	 NYc7Ip5HhxveoM1UG1zbALPWHqlghrr9FWkgxzL4ynzknjr2qzRJNXR0bvmmp0LFhV
	 2OSMqyc+t3WixyaNjJpsZ4FqrFQOpqBUkDbXqnD8oIRzHSRo6BI6S0PtYY51ka7mXT
	 F/aNHCRlDP27nrL0iFxyIILAmTVs3KAxdOxLI4Oy09Y/BLpA3KwnyrjprYZYiv2vA6
	 /XRCO70HAGc/N4UdSrMWqxSo9SxN0390mZcC3+duriCj1eGd6MeQlfVWwQxOpCa2cX
	 9AeBV3eiLnmoQ==
Date: Wed, 22 Jan 2025 01:22:12 +0100
From: Frederic Weisbecker <frederic@kernel.org>
To: Valentin Schneider <vschneid@redhat.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
	virtualization@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev,
	linux-riscv@lists.infradead.org, linux-perf-users@vger.kernel.org,
	xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
	linux-arch@vger.kernel.org, rcu@vger.kernel.org,
	linux-hardening@vger.kernel.org, linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org, bpf@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com,
	Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.amakhalov@broadcom.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andy Lutomirski <luto@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Clark Williams <williams@redhat.com>,
	Yair Podemsky <ypodemsk@redhat.com>,
	Tomas Glozar <tglozar@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
	Kees Cook <kees@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Shuah Khan <shuah@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Miguel Ojeda <ojeda@kernel.org>, Alice Ryhl <aliceryhl@google.com>,
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
	Samuel Holland <samuel.holland@sifive.com>,
	Rong Xu <xur@google.com>,
	Nicolas Saenz Julienne <nsaenzju@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Yosry Ahmed <yosryahmed@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Jinghao Jia <jinghao7@illinois.edu>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: Re: [PATCH v4 22/30] context_tracking: Exit CT_STATE_IDLE upon
 irq/nmi entry
Message-ID: <Z5A6NPqVGoZ32YsN@pavilion.home>
References: <20250114175143.81438-1-vschneid@redhat.com>
 <20250114175143.81438-23-vschneid@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250114175143.81438-23-vschneid@redhat.com>

Le Tue, Jan 14, 2025 at 06:51:35PM +0100, Valentin Schneider a �crit :
> ct_nmi_{enter, exit}() only touches the RCU watching counter and doesn't
> modify the actual CT state part context_tracking.state. This means that
> upon receiving an IRQ when idle, the CT_STATE_IDLE->CT_STATE_KERNEL
> transition only happens in ct_idle_exit().
> 
> One can note that ct_nmi_enter() can only ever be entered with the CT state
> as either CT_STATE_KERNEL or CT_STATE_IDLE, as an IRQ/NMI happenning in the
> CT_STATE_USER or CT_STATE_GUEST states will be routed down to ct_user_exit().

Are you sure? An NMI can fire between guest_state_enter_irqoff() and
__svm_vcpu_run(). And NMIs interrupting userspace don't call
enter_from_user_mode(). In fact they don't call irqentry_enter_from_user_mode()
like regular IRQs but irqentry_nmi_enter() instead. Well that's for archs
implementing common entry code, I can't speak for the others.

Unifying the behaviour between user and idle such that the IRQs/NMIs exit the
CT_STATE can be interesting but I fear this may not come for free. You would
need to save the old state on IRQ/NMI entry and restore it on exit.

Do we really need it?

Thanks.


From xen-devel-bounces@lists.xenproject.org Wed Jan 22 01:04:23 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Jan 2025 01:04:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875748.1286170 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taPA9-00019K-QC; Wed, 22 Jan 2025 01:04:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875748.1286170; Wed, 22 Jan 2025 01:04:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taPA9-00019D-NK; Wed, 22 Jan 2025 01:04:09 +0000
Received: by outflank-mailman (input) for mailman id 875748;
 Wed, 22 Jan 2025 01:04:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=EKZg=UO=flex--seanjc.bounces.google.com=3BUSQZwYKCRIAws51uy66y3w.u64Fw5-vwDw330ABA.Fw57961wuB.69y@srs-se1.protection.inumbo.net>)
 id 1taPA9-000197-5R
 for xen-devel@lists.xenproject.org; Wed, 22 Jan 2025 01:04:09 +0000
Received: from mail-pl1-x64a.google.com (mail-pl1-x64a.google.com
 [2607:f8b0:4864:20::64a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c74849bc-d85c-11ef-a0e5-8be0dac302b0;
 Wed, 22 Jan 2025 02:04:07 +0100 (CET)
Received: by mail-pl1-x64a.google.com with SMTP id
 d9443c01a7336-2166a1a5cc4so114491385ad.3
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 17:04:07 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c74849bc-d85c-11ef-a0e5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20230601; t=1737507846; x=1738112646; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:from:subject:message-id:references
         :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id
         :reply-to;
        bh=HGAInSW7+q0vU97QD0HUaaeZu0zheatXMugXZrnQnto=;
        b=idqj0mT6TOveQhfUQx0HjC1a4MFmemiyh4H+w3QPD1+XnkqBQ2C/ArbVNTT3DEIrWU
         zefDx6opVeDq60DDyDWgNPYGZ1X6rMhLDROM4nhwtejT9R3JjAFvZ2ycDgzEIWCO5Nu6
         r2jKAlOgsvigtBSBx4yKKkf/fCKKNl7hBdxd7vhr0NrjEH9GWIYiZqnaZGHFc8aVclp/
         5Tgp3Iy5/wLOfqpYwtTBeEhBj/q8+ekL3buGuQHAOIDFSeMgSlK8K2C7n+ruaNSClCdj
         odZ5lHC1zo1lqQU11CSohMAQWRDXJvX/vrvWBRlcwAcYkAplDOYvc5h1njJffU1FzRFz
         RcOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737507846; x=1738112646;
        h=content-transfer-encoding:cc:to:from:subject:message-id:references
         :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to;
        bh=HGAInSW7+q0vU97QD0HUaaeZu0zheatXMugXZrnQnto=;
        b=idq07oh9ULe3taK0bC6R3nnug0LA54VGwTYxwU/3UlXkWgKn1Hh5pyTHjqiRnR318J
         WBiunvpi7Nlutqz36GXNGNA8EM1Ess1OyRe+IMh/Wrh/6nIr+L1++lrNOq3O1L2ptk4Q
         oIB8LrNkNABmYDt2ZOh8vfTAnthl7nWuJwKdBrAzKdzIktLwzlmF2o36oiDXIKRhnpk/
         Z1Jn5TCYLLLK0WyoxsOuTheQYHnXM6AyMRPqWWc6LdTevGe2yKmNXVA7Z9t+tb6dF45G
         sQ3NL4H0JxeIzBYyYtTnSgJYi+Gm/cDakQF//u3xsgaS01QXGMcK+SNjKDBBmvdjpa1T
         G9AQ==
X-Forwarded-Encrypted: i=1; AJvYcCX72pGFMLa1Cq6AIBJhk+ppt/PLzfI1eLFXKOkiENliQp6rJA7FJg0tHYIYOWcm88S+ZbjDYsjF3Lc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzhZhmPHaMqBKVd2gSeRHVbi1D1ZEGCzvLDhD0bM+SFZaF1puVF
	DleEVYaN4Ks5mwpttux5faCtUNVV74vepF8yiX8KLXdFcDHjkfDQ18Rm2pAT28WPQxv8Y6KrGQi
	i1Q==
X-Google-Smtp-Source: AGHT+IH6F+XmsAOl9kzgOVOxBLRRXT62oJJbonrrKhR+qzEndDJ3UWVtcgPMx5PJJKXl4IX7nvimBDDp9aQ=
X-Received: from pfau14.prod.google.com ([2002:a05:6a00:aa8e:b0:72d:b2a2:bed7])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:6088:b0:72a:a9b5:ed91
 with SMTP id d2e1a72fcca58-72daf99ed03mr26365241b3a.13.1737507845610; Tue, 21
 Jan 2025 17:04:05 -0800 (PST)
Date: Tue, 21 Jan 2025 17:04:04 -0800
In-Reply-To: <Z5A6NPqVGoZ32YsN@pavilion.home>
Mime-Version: 1.0
References: <20250114175143.81438-1-vschneid@redhat.com> <20250114175143.81438-23-vschneid@redhat.com>
 <Z5A6NPqVGoZ32YsN@pavilion.home>
Message-ID: <Z5BEBCWVWP_fq2zY@google.com>
Subject: Re: [PATCH v4 22/30] context_tracking: Exit CT_STATE_IDLE upon
 irq/nmi entry
From: Sean Christopherson <seanjc@google.com>
To: Frederic Weisbecker <frederic@kernel.org>
Cc: Valentin Schneider <vschneid@redhat.com>, linux-kernel@vger.kernel.org, x86@kernel.org, 
	virtualization@lists.linux.dev, linux-arm-kernel@lists.infradead.org, 
	loongarch@lists.linux.dev, linux-riscv@lists.infradead.org, 
	linux-perf-users@vger.kernel.org, xen-devel@lists.xenproject.org, 
	kvm@vger.kernel.org, linux-arch@vger.kernel.org, rcu@vger.kernel.org, 
	linux-hardening@vger.kernel.org, linux-mm@kvack.org, 
	linux-kselftest@vger.kernel.org, bpf@vger.kernel.org, 
	bcm-kernel-feedback-list@broadcom.com, Juergen Gross <jgross@suse.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.amakhalov@broadcom.com>, 
	Russell King <linux@armlinux.org.uk>, Catalin Marinas <catalin.marinas@arm.com>, 
	Will Deacon <will@kernel.org>, Huacai Chen <chenhuacai@kernel.org>, WANG Xuerui <kernel@xen0n.name>, 
	Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, 
	Albert Ou <aou@eecs.berkeley.edu>, Thomas Gleixner <tglx@linutronix.de>, 
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, 
	Dave Hansen <dave.hansen@linux.intel.com>, "H. Peter Anvin" <hpa@zytor.com>, 
	Peter Zijlstra <peterz@infradead.org>, Arnaldo Carvalho de Melo <acme@kernel.org>, 
	Namhyung Kim <namhyung@kernel.org>, Mark Rutland <mark.rutland@arm.com>, 
	Alexander Shishkin <alexander.shishkin@linux.intel.com>, Jiri Olsa <jolsa@kernel.org>, 
	Ian Rogers <irogers@google.com>, Adrian Hunter <adrian.hunter@intel.com>, 
	Kan Liang <kan.liang@linux.intel.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>, 
	Josh Poimboeuf <jpoimboe@kernel.org>, Pawan Gupta <pawan.kumar.gupta@linux.intel.com>, 
	Paolo Bonzini <pbonzini@redhat.com>, Andy Lutomirski <luto@kernel.org>, Arnd Bergmann <arnd@arndb.de>, 
	"Paul E. McKenney" <paulmck@kernel.org>, Jason Baron <jbaron@akamai.com>, 
	Steven Rostedt <rostedt@goodmis.org>, Ard Biesheuvel <ardb@kernel.org>, 
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>, Joel Fernandes <joel@joelfernandes.org>, 
	Josh Triplett <josh@joshtriplett.org>, Boqun Feng <boqun.feng@gmail.com>, 
	Uladzislau Rezki <urezki@gmail.com>, Mathieu Desnoyers <mathieu.desnoyers@efficios.com>, 
	Lai Jiangshan <jiangshanlai@gmail.com>, Zqiang <qiang.zhang1211@gmail.com>, 
	Juri Lelli <juri.lelli@redhat.com>, Clark Williams <williams@redhat.com>, 
	Yair Podemsky <ypodemsk@redhat.com>, Tomas Glozar <tglozar@redhat.com>, 
	Vincent Guittot <vincent.guittot@linaro.org>, Dietmar Eggemann <dietmar.eggemann@arm.com>, 
	Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>, Kees Cook <kees@kernel.org>, 
	Andrew Morton <akpm@linux-foundation.org>, Christoph Hellwig <hch@infradead.org>, 
	Shuah Khan <shuah@kernel.org>, Sami Tolvanen <samitolvanen@google.com>, 
	Miguel Ojeda <ojeda@kernel.org>, Alice Ryhl <aliceryhl@google.com>, 
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>, Samuel Holland <samuel.holland@sifive.com>, Rong Xu <xur@google.com>, 
	Nicolas Saenz Julienne <nsaenzju@redhat.com>, Geert Uytterhoeven <geert@linux-m68k.org>, 
	Yosry Ahmed <yosryahmed@google.com>, 
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>, 
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>, Jinghao Jia <jinghao7@illinois.edu>, 
	Luis Chamberlain <mcgrof@kernel.org>, Randy Dunlap <rdunlap@infradead.org>, 
	Tiezhu Yang <yangtiezhu@loongson.cn>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Jan 22, 2025, Frederic Weisbecker wrote:
> Le Tue, Jan 14, 2025 at 06:51:35PM +0100, Valentin Schneider a =C3=A9crit=
 :
> > ct_nmi_{enter, exit}() only touches the RCU watching counter and doesn'=
t
> > modify the actual CT state part context_tracking.state. This means that
> > upon receiving an IRQ when idle, the CT_STATE_IDLE->CT_STATE_KERNEL
> > transition only happens in ct_idle_exit().
> >=20
> > One can note that ct_nmi_enter() can only ever be entered with the CT s=
tate
> > as either CT_STATE_KERNEL or CT_STATE_IDLE, as an IRQ/NMI happenning in=
 the
> > CT_STATE_USER or CT_STATE_GUEST states will be routed down to ct_user_e=
xit().
>=20
> Are you sure? An NMI can fire between guest_state_enter_irqoff() and
> __svm_vcpu_run().

Heh, technically, they can't.  On SVM, KVM clears GIF prior to svm_vcpu_ent=
er_exit(),
and restores GIF=3D1 only after it returns.  I.e. NMIs are fully blocked _o=
n SVM_.

VMX unfortunately doesn't provide GIF, and so NMIs can arrive at any time. =
 It's
infeasible for software to prevent them, so we're stuck with that.  [In the=
ory,
KVM could deliberately generate an NMI and not do IRET so that NMIs are blo=
cked,
but that would be beyond crazy].

> And NMIs interrupting userspace don't call enter_from_user_mode(). In fac=
t
> they don't call irqentry_enter_from_user_mode() like regular IRQs but
> irqentry_nmi_enter() instead. Well that's for archs implementing common e=
ntry
> code, I can't speak for the others.
>=20
> Unifying the behaviour between user and idle such that the IRQs/NMIs exit=
 the
> CT_STATE can be interesting but I fear this may not come for free. You wo=
uld
> need to save the old state on IRQ/NMI entry and restore it on exit.
>=20
> Do we really need it?
>=20
> Thanks.


From xen-devel-bounces@lists.xenproject.org Wed Jan 22 02:51:11 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Jan 2025 02:51:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875762.1286180 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taQpW-0007zd-Ti; Wed, 22 Jan 2025 02:50:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875762.1286180; Wed, 22 Jan 2025 02:50:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taQpW-0007zW-PU; Wed, 22 Jan 2025 02:50:58 +0000
Received: by outflank-mailman (input) for mailman id 875762;
 Wed, 22 Jan 2025 02:50:56 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=6gdw=UO=amd.com=Jiqian.Chen@srs-se1.protection.inumbo.net>)
 id 1taQpU-0007yy-Mr
 for xen-devel@lists.xenproject.org; Wed, 22 Jan 2025 02:50:56 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20615.outbound.protection.outlook.com
 [2a01:111:f403:2412::615])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b1d61bea-d86b-11ef-a0e5-8be0dac302b0;
 Wed, 22 Jan 2025 03:50:54 +0100 (CET)
Received: from PH7PR12MB5854.namprd12.prod.outlook.com (2603:10b6:510:1d5::20)
 by LV8PR12MB9408.namprd12.prod.outlook.com (2603:10b6:408:208::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8356.21; Wed, 22 Jan
 2025 02:50:48 +0000
Received: from PH7PR12MB5854.namprd12.prod.outlook.com
 ([fe80::bd58:fa72:e622:dd76]) by PH7PR12MB5854.namprd12.prod.outlook.com
 ([fe80::bd58:fa72:e622:dd76%7]) with mapi id 15.20.8356.014; Wed, 22 Jan 2025
 02:50:48 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b1d61bea-d86b-11ef-a0e5-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=oyunNs0zzgg72DXS1Z6Yrilx3ywn3ApSPAE7B2HQChBERMFqG8j5NfGBiNW87MuEwh9QcOw6kVXJjP2OTBII8mPSiNRFpxQDv40eX9DIHR8hoH7ws8YO5jZ/Wg3uS27VfL5fAuY8yW++wtxB3oftcUm4CuXxH7v62l4NSXnXzgKaLC4t0Fn5cICwiC4kU0dvML3TuyKbMbV2kkZjmiL69YFLUhir2Bk0uOoBPPvkfopNVbP9cwzvrBgMTrtLIP3exrm77ZptWVp/0ZyMg6ZiIrCXzE0K51FZUTkq5jHlQrUEa7LwxCx1dVO3Vh678qANmTdi39AM965wiYJyjeS1cQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=3wBsXJWENb6NtyWsyU6BabsVXTBN5XirCiQcIt5/C0E=;
 b=gLRlgTh97fP4bVE4L/rFvyj9PAYhgtN1Qn0zN8KJsx0Eeg0pjYrC5z5lCcv0qJ7HWrld9PeuTivySDTnzf+sHLJqbuA/ttn78J5ynmeYBd/A+d5XxPk3KaECNiUMVTBMmNaGYfdoKpg9gBnb9yHmOHwH8umME06QLXhhuN6CsK0fk80DFzWAEejC/AB24cp2iNd1mCqIcmQVCuqTL+BspXb3mvDI6mzOJeFizZ7Np9oayk/6xNKegKBxcoXmB4g3a6Zed6Xi7pVsYiuC567aGV0pZ0xzI8TUS7Qmx2OBXrs41yiJeVDqmmTQBdMQR4AicPlGHKKcM7mML3ZMeZ8eOw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=3wBsXJWENb6NtyWsyU6BabsVXTBN5XirCiQcIt5/C0E=;
 b=uuQ030YwH6/B3w2n89axx7TmhDlzbzY2PwHB28vYiLgR5ilxZtKhfMVl61U6C9oL372YlMwBL8N3I0tHRVNVgjw/Iw4LpRYA29glodD5s3KoOOPMCIJWDFphbxsDIy7f8Xtc8UAxpygrs8IpDYMfcqz3kzRMHU9Hb/9FZIh3eyw=
From: "Chen, Jiqian" <Jiqian.Chen@amd.com>
To: Jan Beulich <jbeulich@suse.com>, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	<roger.pau@citrix.com>
CC: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Andrew
 Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, Stefano
 Stabellini <sstabellini@kernel.org>, "Huang, Ray" <Ray.Huang@amd.com>, "Chen,
 Jiqian" <Jiqian.Chen@amd.com>
Subject: Re: [PATCH v5] vpci: Add resizable bar support
Thread-Topic: [PATCH v5] vpci: Add resizable bar support
Thread-Index: AQHbZjRJ+4D0uojYEUmC9gRuRAux1rMg9ZEAgACK3YD//4D+AIAAEMqAgAGX2oA=
Date: Wed, 22 Jan 2025 02:50:48 +0000
Message-ID:
 <PH7PR12MB5854EEA40EEF51B3785BE9FBE7E12@PH7PR12MB5854.namprd12.prod.outlook.com>
References: <20250114032636.3698383-1-Jiqian.Chen@amd.com>
 <Z49e8NmROzke-tYc@macbook.local>
 <BL1PR12MB58492016DDBB106A607F32CDE7E62@BL1PR12MB5849.namprd12.prod.outlook.com>
 <Z49o4iyY7vPhz2ow@macbook.local>
 <b65a4189-e643-45d3-ac62-25ccc1ffb39a@suse.com>
In-Reply-To: <b65a4189-e643-45d3-ac62-25ccc1ffb39a@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: PH7PR12MB5854.namprd12.prod.outlook.com
 (15.20.8356.008)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PH7PR12MB5854:EE_|LV8PR12MB9408:EE_
x-ms-office365-filtering-correlation-id: 6b566115-0011-4fd6-79a3-08dd3a8f9371
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?ZUVlRm5jbUJKdi9xYkQzOHFmSmlDU3h1OVI2b1B1L0xWYlJpbmRMdVcyMjRH?=
 =?utf-8?B?d2VibDY3QkpGbm1rNFU2Tzl3RzJxTk9nVnZNMTg3NTc2WVlHMmpaNFRGaGU4?=
 =?utf-8?B?Ukw5TmhoeS9SL3I5UDZJdzJPN3VZSEs1b3NuS2twbm9CQmhoQ2pNWC9rdnNk?=
 =?utf-8?B?NUVJZXBzUlNXc2xmV0h4UjFERWVsZFU1MUpKVU9GY1VINzloNEJOV1BzOCsv?=
 =?utf-8?B?SEtyRW8yeGZLMllKZ0UzV09lTGU0RHhKQitnanE3MDNxQ201VTdXT2k1WnEr?=
 =?utf-8?B?Ynh4dnd3bDdSUnJBcFhVdnMvcm5La3RqWW9jc2ZvWlRSVEJObDJhdkc1NHln?=
 =?utf-8?B?K1BCd2dEcmtvU2xwZGZPMGViL1dHT0tLZi9MaE9JSWowNFJwQnIrL1FscU9K?=
 =?utf-8?B?STk2STVTb3d3WXpoOTdPanoxcmdWL0RRd0F1ekxJbkp2UWJCWFU0MFI3UXor?=
 =?utf-8?B?VTB2NVNCVWp1c0pTS0lpV2llMDUyUldCcDV4R0lGWXZ5cm5PT3RrZWEzaXV3?=
 =?utf-8?B?WGFUd2dRSHlaNEdBcTNZN0l1V0dMcFVzd1JCZjg2bFZYRzJZYnlSWlR3T080?=
 =?utf-8?B?ODl5aTloeklVNW51NzRIdFR6MTk5VkVRRFBOVjQzZjFhZkh5VmRacGdpdHgy?=
 =?utf-8?B?SEZWNTFYcHJ0b3MxaUVzOVVYMHFQUWFlVFNKMVdYWkZKSXl2OE5heEV0REtl?=
 =?utf-8?B?b2d0STRNQTVCTWVsMW5kUTNYdFBRQ1BZWjFVVVYzcnRuZUZxUnpKT1c2UjdO?=
 =?utf-8?B?QWFQL0lZVDRJbnNWZE51ajNYaWR1QnZMZjIxUjRRVHZNQUowaEF4dzJoQk9E?=
 =?utf-8?B?enZFWVcyMTFPL1FWSUkrSXVCTEErb2tyWG9lRnpCK2ovSGY1WWRjS0x5V0xF?=
 =?utf-8?B?TDhEMFJCbHZnOUtPWjNZbmlCNisrTituN244Zko1WFlpemZHL2FRUXZON0Ns?=
 =?utf-8?B?QzRvM2RkMTNodzB5Y2FxeldiTmVzU1p3U1BKWi9WMkF3eUU3ZG9RVnZadmFX?=
 =?utf-8?B?VjgxcXZ2MkhJVjE4cjNXRFFmMWZ5bllidjlsTU53cVIzSkxkdzJEdDJlWldE?=
 =?utf-8?B?UFNYSHVKT0pzNEhJMDNNYVpCcWNzSUZqVzBBRWpOb3pKMTRkUnpEZ3lxd0NK?=
 =?utf-8?B?UGlOUUswQ1hCNURqZkJNQUhWbUJDaWxiS2p6QjREeEdTS2ZlUGZieTNaMU9V?=
 =?utf-8?B?YTNIZ0xGSUZlNkNIcExVaU1qQlhiaGVaMjB0OWlUeEltODR0ZTR1aEhlOG5I?=
 =?utf-8?B?aGhaYVEvVnFXaVJsRkpFajIzRVNvVTdzeDJpMHlFZzdHWlZhaUVUS1d2bmRy?=
 =?utf-8?B?VFk3NzhVY1B3bTRIc0o0T2xxd3g1ckpyS0FqcE9zUmM2alNsRXdISkh3dHFx?=
 =?utf-8?B?bDhsZURjY2pEUkM5dk9kM2pqdHdZeEkxNkoxZ0JHQnpGcUVjaHY3UnBWL3RP?=
 =?utf-8?B?SklyOGVVNnpiMnFEV21tSmZnQmZUbVdjWHQyRnlWUW1UL296K3VRcnRBVnRS?=
 =?utf-8?B?TDBEZHVLNGFIQVZCck0zQ0llaFdha0JYaUFNSHlKS29sRCs2V3p6dlh1V2pK?=
 =?utf-8?B?R0FhOGZxLzg1ZEorQmIydkFReUgyV043UGxaTlhXT010YXJnSlRWYXFDd3B1?=
 =?utf-8?B?SEpNNXJXZkZTcGpBbXJGZ1d2cTV0VEpZNTZIeXhVNENqZ2tsaGF2MFBIY0dM?=
 =?utf-8?B?T2hIYzl3Yy9nVFp2bktpUXc5OGVUWXVnajc4cWYvNnpLbU44bGxVZkJaUDJO?=
 =?utf-8?B?VlZEajFjZWtNQXRoSG1CeG1QV0dDdWVoT09wSGlNS1BiaGg3OWNWSm5nVHVr?=
 =?utf-8?B?U0FLdzNKNzkvQS9jSjV0TXV5STZPQ3FXZzJFWGpBbWEzZVZlT2pub0VTdkxr?=
 =?utf-8?B?MlVuZ1JPcUZDclpLSVg0UzR3anc5bTdlRUcvU0R6cFk1RDNEbXlNSjNvcnNS?=
 =?utf-8?Q?M+IK/CZJGKAOvWxf0QSXKbvjDTDtu71r?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH7PR12MB5854.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?WWpQSGhxbE9CbVd0RmZGKzFhbVA5OHpaeXdiWFMvQjlVWEY4aGJjNzlXbXQ0?=
 =?utf-8?B?bWowcFd3R0lpTFpGY3QwSnc5MEQ3SWZzanJGTnJVdWg2UStTVjRNYndwZ1o4?=
 =?utf-8?B?ZzMzZ3pML0RSL1RFOGdTdEhrd0xKN3g3dzhlMUVkRmNVYS9UbUZmaHlPYStL?=
 =?utf-8?B?Q3VLOUY4S0VCRHQ5Q2dveG9oZ2wzMzd1NlRWRDBSRXZ6ZHR2cWxwdGFCemRK?=
 =?utf-8?B?TUFBVm9XandxNDkvNEhxdnIycFZERWtXL25hY3ZJMGtBbDVKQnlaNHhhSFZ6?=
 =?utf-8?B?aFFJV1JUT3hDUENqOE83RkxPVVB2RjZCSXQxSHNzMWx4MFFWKzNqM3RpY1k3?=
 =?utf-8?B?bGZTcWVUOVdiODBRbE5vcFArUG94anZzQ2p0VzlSK09CQnlyeTRZRGRMQy96?=
 =?utf-8?B?dHZWSnpHM2pIYnBsRmlNK1BDNkMwZ3FDL0VmZ2lMZE0yMUQ0ano5UWpVU09J?=
 =?utf-8?B?Vkk3TzdXTEVmZ0s2K3NoV0tXTkw5WEN4T3ZkVWZMVVNJeFlHc25KWjl6YWN3?=
 =?utf-8?B?MTBXQWJPOWY0Skg5aTNDK3VXUnJiT0lRTmVsMUtad1IyUnhkNWcvUmluU3lE?=
 =?utf-8?B?cUFFekFhbzRlaExQaldKMFlOVG9qejk3bXllMHJCb3V1ek5GNVBEU2hyNDlT?=
 =?utf-8?B?dTArZWIyTGU2OHFTaHZ0YWJKQ2ttcENKa1FwTGN6QjVWZHV1ZHRFMDV2aWI0?=
 =?utf-8?B?SnVwcmJza1AvckE1cUMrK3gwZVhWWjZPVVdiUnI1dGZZRXdYdTlPUnVGYk51?=
 =?utf-8?B?Ym1MdS9PbU1JTjRuZjRIYVNpKzNhR2NRZm83MmRiVUtKeGM3aGxKOWlQNWtl?=
 =?utf-8?B?WjNKOGhLcFVvWFpBbU90dDJYNFRKS3BSdjNKaStiVWpsVWgxRlJTcVdRclZM?=
 =?utf-8?B?UTJUVFRDb2ZRd3h6QklaYW9Id0lpUFZlTCtPV3ZKeDRBLzlPQ2xLaTI5OE9Q?=
 =?utf-8?B?dGFEUEFKK0JxQVlvOTlJc1p0RlpGSFJmYmsvK0ZTeFZXVHRWOW5QVW4zbVpH?=
 =?utf-8?B?TWkxWmhEVXd2L1IzQ2FNQnlhZ3B5TytWNGpaa0lxL20yQXhGY1BnVUE1NGhi?=
 =?utf-8?B?V3k0bDh5TVZ1cE9yaEdqY20vb1pCRjFxVEF2REd5bXI5REphUitzbENUYlJD?=
 =?utf-8?B?TThpUmhxVFMxZEtOVmgrQ2Jmb0RtMytIVWJMbWFzK29uN3FqaHZOYzJTVVNP?=
 =?utf-8?B?UWhVaTdmMkZxZVJxT29CUENPQTdINS8wenVqR0NOcFlhL0JHTEM4WWQ5bWxp?=
 =?utf-8?B?bldIYkxiR3RxS2h0K0ZSQldadlRlaWplUGJYZTZUUnI4Z3lrd0M0TlNUVWpq?=
 =?utf-8?B?OFR3YjRNTXFnTzk3NVRCTU9RN2FxVnV2czBaZ050SnFGcHZqL2NjRFpEYi9u?=
 =?utf-8?B?SVJqZDlUbnRXbTJ4ZVpYNEVFVnpEOWJ5L3I5WjQvYm5HUXd6VXJCdFFOSUlZ?=
 =?utf-8?B?UCtFTG9mT3RhR1RYZi9OU0FxQ29RQjRNQXl1QU9ZL0wwNVpZYmxwbWlNZHkw?=
 =?utf-8?B?dkptUld1SHVOdUptVFpKYlZodUVtVjNDUGtnZS9zOUdQK1B1Z1NQYlpBN1pY?=
 =?utf-8?B?NVJZV3Ercmwxa1pJM0tWclRDRTVBUzBoTllNMFNzdmJXVG16ekUvY2JkNWxF?=
 =?utf-8?B?OVJlYVNQbjU5aHBXVmFtSVoySzBsQXVydVpKK2sxemV5MHpXT203MFloSlZB?=
 =?utf-8?B?Q1RVY0lkZW9hYVdaL2pGMXRuTExiRGZ6SStoMFN0bGowZzd1ZHRqNlhHY0gr?=
 =?utf-8?B?RkpMZmhiNGlQMkw0andQM2gvTXBTTTFXbVIyaitUbFhnN1ZYUUpjOEh4RDkr?=
 =?utf-8?B?ZlppLzQvaFBieDFGc2JqVDJiaFQ0RlN2MXdGSFNsOWdFdWl1aGR5NnhyL1Jj?=
 =?utf-8?B?UmVlTDNNQ2FCYllmL3NHZnVEMHo1dlFQQXhUSXVmSnJGVkp4QUFYQVFjSWFX?=
 =?utf-8?B?NmEwYVliU1BkaGFIamNJM0JodHFJT3ltZ0w5bWtLTFZBSENvNGx3dWdHNjVO?=
 =?utf-8?B?eGxCMmtmK0U0ajcrd3VZT3l4dTdYZml0Wk44SExRRTEzWk1ZVnVkMUV4T2hz?=
 =?utf-8?B?QS80T1piVjd1SHJOL01MR0xkbFJzTlhGQ0l0U2tuN0JhWlBzT3NwbVFaMnNq?=
 =?utf-8?Q?BhaI=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <CDCDCDE0A253B8458F966B43097BBFC3@amdcloud.onmicrosoft.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH7PR12MB5854.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6b566115-0011-4fd6-79a3-08dd3a8f9371
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2025 02:50:48.4834
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: XEM59LwlhCetMSjCsBU164FV+lXSbDnpLdUeaFlnOQkdVBeNFreGHDHew7A4exhlmZFvtU5LRRslW9j6mgE5gA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV8PR12MB9408

T24gMjAyNS8xLzIxIDE4OjI5LCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMjEuMDEuMjAyNSAx
MDoyOSwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToNCj4+IE9uIFR1ZSwgSmFuIDIxLCAyMDI1IGF0
IDA5OjEwOjI2QU0gKzAwMDAsIENoZW4sIEppcWlhbiB3cm90ZToNCj4+PiBPbiAyMDI1LzEvMjEg
MTY6NDYsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6DQo+Pj4+IE9uIFR1ZSwgSmFuIDE0LCAyMDI1
IGF0IDExOjI2OjM2QU0gKzA4MDAsIEppcWlhbiBDaGVuIHdyb3RlOg0KPj4+Pj4gKyAgICBjdHJs
ID0gcGNpX2NvbmZfcmVhZDMyKHBkZXYtPnNiZGYsIHJlYmFyX29mZnNldCArIFBDSV9SRUJBUl9D
VFJMKDApKTsNCj4+Pj4+ICsgICAgbmJhcnMgPSBNQVNLX0VYVFIoY3RybCwgUENJX1JFQkFSX0NU
UkxfTkJBUl9NQVNLKTsNCj4+Pj4+ICsgICAgZm9yICggdW5zaWduZWQgaW50IGkgPSAwOyBpIDwg
bmJhcnM7IGkrKyApDQo+Pj4+PiArICAgIHsNCj4+Pj4+ICsgICAgICAgIGludCByYzsNCj4+Pj4+
ICsgICAgICAgIHN0cnVjdCB2cGNpX2JhciAqYmFyOw0KPj4+Pj4gKyAgICAgICAgdW5zaWduZWQg
aW50IGluZGV4Ow0KPj4+Pj4gKw0KPj4+Pj4gKyAgICAgICAgY3RybCA9IHBjaV9jb25mX3JlYWQz
MihwZGV2LT5zYmRmLCByZWJhcl9vZmZzZXQgKyBQQ0lfUkVCQVJfQ1RSTChpKSk7DQo+Pj4+PiAr
ICAgICAgICBpbmRleCA9IGN0cmwgJiBQQ0lfUkVCQVJfQ1RSTF9CQVJfSURYOw0KPj4+Pj4gKyAg
ICAgICAgaWYgKCBpbmRleCA+PSBQQ0lfSEVBREVSX05PUk1BTF9OUl9CQVJTICkNCj4+Pj4+ICsg
ICAgICAgIHsNCj4+Pj4+ICsgICAgICAgICAgICBwcmludGsoWEVOTE9HX0VSUiAiJXBkICVwcDog
dG9vIGJpZyBCQVIgbnVtYmVyICV1IGluIFJFQkFSX0NUUkxcbiIsDQo+Pj4+PiArICAgICAgICAg
ICAgICAgICAgIHBkZXYtPmRvbWFpbiwgJnBkZXYtPnNiZGYsIGluZGV4KTsNCj4+Pj4+ICsgICAg
ICAgICAgICBjb250aW51ZTsNCj4+Pj4+ICsgICAgICAgIH0NCj4+Pj4+ICsNCj4+Pj4+ICsgICAg
ICAgIGJhciA9ICZwZGV2LT52cGNpLT5oZWFkZXIuYmFyc1tpbmRleF07DQo+Pj4+PiArICAgICAg
ICBpZiAoIGJhci0+dHlwZSAhPSBWUENJX0JBUl9NRU02NF9MTyAmJiBiYXItPnR5cGUgIT0gVlBD
SV9CQVJfTUVNMzIgKQ0KPj4+Pj4gKyAgICAgICAgew0KPj4+Pj4gKyAgICAgICAgICAgIHByaW50
ayhYRU5MT0dfRVJSICIlcGQgJXBwOiBCQVIldSBpcyBub3QgaW4gbWVtb3J5IHNwYWNlXG4iLA0K
Pj4+Pj4gKyAgICAgICAgICAgICAgICAgICBwZGV2LT5kb21haW4sICZwZGV2LT5zYmRmLCBpbmRl
eCk7DQo+Pj4+PiArICAgICAgICAgICAgY29udGludWU7DQo+Pj4+PiArICAgICAgICB9DQo+Pj4+
PiArDQo+Pj4+PiArICAgICAgICByYyA9IHZwY2lfYWRkX3JlZ2lzdGVyKHBkZXYtPnZwY2ksIHZw
Y2lfaHdfcmVhZDMyLCB2cGNpX2h3X3dyaXRlMzIsDQo+Pj4+PiArICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHJlYmFyX29mZnNldCArIFBDSV9SRUJBUl9DQVAoaSksIDQsIE5VTEwpOw0K
Pj4+Pj4gKyAgICAgICAgaWYgKCByYyApDQo+Pj4+PiArICAgICAgICB7DQo+Pj4+PiArICAgICAg
ICAgICAgLyoNCj4+Pj4+ICsgICAgICAgICAgICAgKiBUT0RPOiBmb3IgZmFpbGVkIHBhdGhlcywg
bmVlZCB0byBoaWRlIFJlQmFyIGNhcGFiaWxpdHkNCj4+Pj4+ICsgICAgICAgICAgICAgKiBmcm9t
IGhhcmR3YXJlIGRvbWFpbiBpbnN0ZWFkIG9mIHJldHVybmluZyBhbiBlcnJvci4NCj4+Pj4+ICsg
ICAgICAgICAgICAgKi8NCj4+Pj4+ICsgICAgICAgICAgICBwcmludGsoWEVOTE9HX0VSUiAiJXBk
ICVwcDogZmFpbCB0byBhZGQgcmVnIG9mIFJFQkFSX0NBUCByYz0lZFxuIiwNCj4+Pj4+ICsgICAg
ICAgICAgICAgICAgICAgcGRldi0+ZG9tYWluLCAmcGRldi0+c2JkZiwgcmMpOw0KPj4+Pj4gKyAg
ICAgICAgICAgIHJldHVybiByYzsNCj4+Pj4+ICsgICAgICAgIH0NCj4+Pj4+ICsNCj4+Pj4+ICsg
ICAgICAgIHJjID0gdnBjaV9hZGRfcmVnaXN0ZXIocGRldi0+dnBjaSwgdnBjaV9od19yZWFkMzIs
IHJlYmFyX2N0cmxfd3JpdGUsDQo+Pj4+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHJlYmFyX29mZnNldCArIFBDSV9SRUJBUl9DVFJMKGkpLCA0LCBiYXIpOw0KPj4+Pj4gKyAgICAg
ICAgaWYgKCByYyApDQo+Pj4+PiArICAgICAgICB7DQo+Pj4+PiArICAgICAgICAgICAgcHJpbnRr
KFhFTkxPR19FUlIgIiVwZCAlcHA6IGZhaWwgdG8gYWRkIHJlZyBvZiBSRUJBUl9DVFJMIHJjPSVk
XG4iLA0KPj4+Pj4gKyAgICAgICAgICAgICAgICAgICBwZGV2LT5kb21haW4sICZwZGV2LT5zYmRm
LCByYyk7DQo+Pj4+PiArICAgICAgICAgICAgcmV0dXJuIHJjOw0KPj4+Pg0KPj4+PiBJIHRoaW5r
IHdlIHNhaWQgd2Ugd2FudGVkIHRvIGF0dGVtcHQgdG8gY29udGludWUgaGVyZSwgcmF0aGVyIHRo
YW4NCj4+Pj4gcmV0dXJuaW5nIGFuIGVycm9yIGFuZCB0aHVzIHJlbW92aW5nIGFsbCB2UENJIGhh
bmRsZXJzIGZyb20gdGhlDQo+Pj4+IGRldmljZT8NCj4+PiBJIHRob3VnaHQgdGhlIHJlc3VsdCBv
ZiB5b3VyIGRpc2N1c3Npb24gd2l0aCBKYW4gd2FzIHRoYXQgSSBvbmx5IG5lZWRlZCB0byBjaGFu
Z2UgdGhlIGFib3ZlIHR3byBlcnJvciBwYXRocyB0byBiZSAiY29udGludWUiLg0KPj4+IElmIHRo
ZXNlIHR3byBhbHNvIG5lZWQgdG8gYmUgY2hhbmdlZCwgSSB3aWxsIG1vZGlmeSB0aGVtIGluIHRo
ZSBuZXh0IHZlcnNpb24uDQo+Pg0KPj4gSG0sIGxldCdzIHdhaXQgZm9yIEphbiB0byBjb25maXJt
LCBidXQgZXZlbiBpZiBoYW5kbGVyIGNhbm5vdCBiZSBzZXR1cA0KPj4gZm9yIHNvbWUgb2YgdGhl
IHJlZ2lzdGVycywgaXQncyBiZXR0ZXIgdGhhbiBqdXN0IGFsbG93aW5nIGRvbTANCj4+IHVubWVk
aWF0ZWQgYWNjZXNzIHRvIHRoZSBjYXBhYmlsaXR5Lg0KPiANCj4gSSByZW1haW5lZCBzaWxlbnQg
b24gdGhpcyBiZWNhdXNlIEkgYWNjZXB0ZWQgdGhpcyBtaWRkbGUgZ3JvdW5kIGFzIC4uLg0KPiAN
Cj4+IE5vbmUgb2YgdGhpcyBpcyBpZGVhbCwgYnV0IGl0IHNlZW1zIHRvIGJlIHRoZSBvcHRpb24g
dGhhdCBnaXZlcyBkb20wDQo+PiBtb3N0IG9wdGlvbnMgdG8gc3VjY2Vzc2Z1bGx5IGJvb3QuDQo+
IA0KPiAuLi4gcGVyaGFwcyB0aGUgbW9zdCByZWFzb25hYmxlIGNvbXByb21pc2UuDQpPSywgSSBz
ZWUuDQpJIHdpbGwgY2hhbmdlIHRvICJjb250aW51ZSIgaW4gbmV4dCB2ZXJzaW9uIGFuZCBzZW5k
IHY2IHNvb24uDQpUaGFuayB5b3UuDQoNCj4gDQo+IEphbg0KDQotLSANCkJlc3QgcmVnYXJkcywN
CkppcWlhbiBDaGVuLg0K


From xen-devel-bounces@lists.xenproject.org Wed Jan 22 07:13:02 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Jan 2025 07:13:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875772.1286189 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taUuu-0004r7-He; Wed, 22 Jan 2025 07:12:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875772.1286189; Wed, 22 Jan 2025 07:12:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taUuu-0004r0-F0; Wed, 22 Jan 2025 07:12:48 +0000
Received: by outflank-mailman (input) for mailman id 875772;
 Wed, 22 Jan 2025 07:12: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 <SRS0=XwhO=UO=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1taUut-0004qu-3I
 for xen-devel@lists.xenproject.org; Wed, 22 Jan 2025 07:12:47 +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 473ec8e3-d890-11ef-a0e5-8be0dac302b0;
 Wed, 22 Jan 2025 08:12:45 +0100 (CET)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-43621d27adeso44535505e9.2
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 23:12: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
 5b1f17b1804b1-438b31d99ffsm12695865e9.29.2025.01.21.23.12.44
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 21 Jan 2025 23:12:44 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 473ec8e3-d890-11ef-a0e5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737529965; x=1738134765; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=KK+6IApfm6L63hE7/QkDSe1SVLuwZgq9lNGJ5H7WOKU=;
        b=FWIp/2hmmmv8OzEgbhY448c6vnGojRb0abFJKcbTqxDHXuDXKmifkq1ge6zFtS10qt
         1hYjysDcHkq4PFjAuMkrrEdpDGgrvXXGaPfKQTpifEsOPo7Mw4nY4QxP99pFUndCtEaK
         Tn9pjrxEv2rozmD34m4b7FFOPHT47x0qnIlvHOgl8fQmovamcTUnuRmpb7GxCsGAMq4f
         0H/jIM4ZguUMP+Fc4t9GntcBbFUB5RTzQJHPwYn8nxej/SHZkUPJu2hRqith2gzycpk/
         fPrRU33hPiG83pXF1Lv6yYo8py6lRuf23PFkNalrGMtUHKUYfWuj332xkP79Y2hWRgCi
         uAcA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737529965; x=1738134765;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=KK+6IApfm6L63hE7/QkDSe1SVLuwZgq9lNGJ5H7WOKU=;
        b=rJHecxtLnL8NFWKm1LM50/WlwEf1WeQc43kfzpKpAh1rJMQHbCVR6tfYxGtnh0ovD8
         KjXemytQZWC9dtndo/1rS8S/PgP8uQvnK60vjFjd+o8XMsTPUDnUpjvEhhhq3JCF4SfG
         USnBKw7uUN+LONu5jq4nycP5YyFSn2yhdWBgATwZEVQU8D4mseIvm2uAzWd31o6OQdFo
         rxyzRwR28XlYAwR3z2goIdMCSUQzviN8uWXcR/F5T1BaJAnRD3Tx4UGD/VVbNdc5uR1Y
         QcpYzvbBOaniWLyCAYBZEH0z4Oc1nRxwrVJD5WFEh1lIZlIuvXpKBSmv29Zz0RUsbZ/3
         +8qQ==
X-Forwarded-Encrypted: i=1; AJvYcCVkb8ChFV04JxYl6R2eS2pB7loCZLh9tcvpVBrDSzCqbL8tdI5tEbv17uQNerA+jt2i4AxUCpQ1HLg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxvgTfNJhtVJAuH5dzOXBvPvuz1rRe3gl9OYkAscSRPUTy6L8wp
	w5fqkGJPofnGKxHV35xv02dGMzKLVnkhsN3Pnzm0hpT1WkEj+molpRii4QEe9Q==
X-Gm-Gg: ASbGncsjNHzIrBTJFZ4Ej7Thu4PuzUeazqDb62UQDwENcBbEZsLF5YjQx9C+ec56VBu
	hSTi604U+dH3z+MOnDpVqo9mLzwGWRyeUYdGJp/4VEBlxluCdT8SmHCR+MjQWKdT2u4HYfN3qv4
	/BgYmN2WjhX4AddLg2kAP9duQCe/dL22hLDvjBbpRRDmOonP0V8ur8X0DJ12mkYzsCPF78GDoTd
	kHTGP+aYFMN1LuF0nyxnYpaojhUtDA/nrCCBZSBZcNyfis3dBx5dJE4bhfRFFaMilm4XVfl60Vd
	W3baFsi0lkgjz5+Gy2PQlSvKN1x+OKvOtaBUV+ya7gTpjRNdiDA/XCQ=
X-Google-Smtp-Source: AGHT+IHRrZ1BwNeb5Wv8RdaMiKxFFpu/ItS4uhc46rNbgB8Hn9mV9P4aHmdWRn8LYnJ4V8ejlhLyLw==
X-Received: by 2002:a05:600c:a03:b0:434:a902:97cd with SMTP id 5b1f17b1804b1-438913ed350mr194670715e9.12.1737529964912;
        Tue, 21 Jan 2025 23:12:44 -0800 (PST)
Message-ID: <c1e6d78e-d5c4-4fbe-815f-e1bdcbc47e31@suse.com>
Date: Wed, 22 Jan 2025 08:12:43 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20 v2] x86/intel: Fix PERF_GLOBAL fixup when
 virtualised
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Jonathan Katz <jonathan.katz@aptar.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20250121142510.358996-1-andrew.cooper3@citrix.com>
 <20250121165626.380627-1-andrew.cooper3@citrix.com>
 <741f15ea-2c54-4e02-8be6-bcce10c7393b@suse.com>
 <fb62d881-720e-499f-a301-fdf1880b097c@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <fb62d881-720e-499f-a301-fdf1880b097c@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 21.01.2025 18:07, Andrew Cooper wrote:
> On 21/01/2025 5:04 pm, Jan Beulich wrote:
>> On 21.01.2025 17:56, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/cpu/intel.c
>>> +++ b/xen/arch/x86/cpu/intel.c
>>> @@ -535,39 +535,49 @@ static void intel_log_freq(const struct cpuinfo_x86 *c)
>>>      printk("%u MHz\n", (factor * max_ratio + 50) / 100);
>>>  }
>>>  
>>> +static void init_intel_perf(struct cpuinfo_x86 *c)
>>> +{
>>> +    uint64_t val;
>>> +    unsigned int eax, ver, nr_cnt;
>>> +
>>> +    if ( c->cpuid_level <= 9 ||
>>> +         ({  rdmsrl(MSR_IA32_MISC_ENABLE, val);
>> Just curious (not an objection or anything): Is there a reason you have
>> two padding blanks here instead of just one?
> 
> Alignment with the next line.

Yet that's then merely a matter of removing a blank from that line too,
isn't it?

>> (Really we may want to gain
>> a function-like form to invoke RDMSR, but that's orthogonal to the change
>> here.)
> 
> Indeed.
> 
> * def0701b5373 - (xen-nj-msr) switch rdmsrl => rdmsr (30 hours ago)
> <Andrew Cooper>
> * 1a3f92abccf1 - rdmsr (30 hours ago) <Andrew Cooper>
> * 01c9ec7d9482 - rdmsr_safe (30 hours ago) <Andrew Cooper>
> * 7ec72a0379b2 - fix error printing in write_msr() (30 hours ago)
> <Andrew Cooper>
> * 3ff3d60835a5 - drop wrmsrl (30 hours ago) <Andrew Cooper>
> * 136128799b4a - wrmsr cleanup (30 hours ago) <Andrew Cooper>
> * b2ed78d2e7e3 - x86/msr: Move MSR_FEATURE_CONTROL handling to the new
> MSR infrastructure (30 hours ago) <Andrew Cooper>
> * 7691edea3d67 - x86/msr: Clean up the MSR_DEBUGCTL constants (30 hours
> ago) <Andrew Cooper>
> * 77ba2827a955 - x86/msr: Clean up the MSR_MISC_ENABLE constants (30
> hours ago) <Andrew Cooper>
> * 7f2768cfc4b3 - ---upstream--- (30 hours ago) <Andrew Cooper>
> * 8b2e048fdd14 - x86/msr: Introduce msr_{set,clear}_bits() helpers (30
> hours ago) <Andrew Cooper>
> * 562f88503342 - x86/msr: Clean up the MSR_FEATURE_CONTROL constants (30
> hours ago) <Andrew Cooper>
> * 199888c9e2f8 - x86/msr: Clean up the
> MSR_{PLATFORM_INFO,MISC_FEATURES_ENABLES} constants (30 hours ago)
> <Andrew Cooper>
> * c3f5d1bb40b5 - (tag: 4.20.0-rc2, xenbits/staging, xenbits/master,
> upstream/staging, upstream/master, origin/staging, origin/master,
> origin/HEAD, staging, pending, master) automation/cirrus-ci: introduce
> FreeBSD randconfig builds (4 days ago) <Roger Pau Monne>
> 
> That was work I did while sat in an airport unable to leave XenSummit in
> Nanjing...
> 
> It's blocked on arguments over naming.

Is it? I couldn't find any replies of mine in my outbox (and a quick
attempt to search by subjects on the web also didn't reveal anything),
but then Nanjing also was quite some time ago.

I fear you will not like this, but from a more general perspective:
When you say "blocked" for your own patches, it's usually the case that
the ball is in your court. Interestingly other people's patches (say
Roger's or mine) are, when they are "blocked", also often lacking
feedback from you. While it's apparently close to impossible to get
you to reply on such threads rooting in other people's patches,
shouldn't it at least be entirely in your own interest to keep the ball
rolling when it comes to your own ones? That is, make an attempt (or
perhaps repeated ones) to come to some form of agreement?

Plus for anything you deem blocked, you know where the list of pending
x86 patches is that you could add yours to. Since in that table we
record last posting dates, finding the patches is then much easier as
well.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jan 22 07:19:14 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Jan 2025 07:19:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875780.1286199 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taV15-0005TH-4y; Wed, 22 Jan 2025 07:19:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875780.1286199; Wed, 22 Jan 2025 07:19:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taV15-0005T9-2H; Wed, 22 Jan 2025 07:19:11 +0000
Received: by outflank-mailman (input) for mailman id 875780;
 Wed, 22 Jan 2025 07:19:10 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=XwhO=UO=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1taV14-0005T3-1N
 for xen-devel@lists.xenproject.org; Wed, 22 Jan 2025 07:19:10 +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 2be3d6a3-d891-11ef-a0e5-8be0dac302b0;
 Wed, 22 Jan 2025 08:19:09 +0100 (CET)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3863703258fso307667f8f.1
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 23:19:09 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38bf3275901sm15635954f8f.61.2025.01.21.23.19.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 21 Jan 2025 23:19:08 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2be3d6a3-d891-11ef-a0e5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737530348; x=1738135148; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=6SJAo92DyDNJXxNIt7nA2UJV2gTXGpGtR/vEGz4DxbQ=;
        b=GRCV8BQN57i1ZVlyRoZz3M+OcUU5oDVkTZ/Cje99oPOKbMw3wNVd3NlXqJh23yATcI
         NEtGJTfN+cL+mP2q/1Cks8L/sDfmI4FOsORFnrI5mYhCOjwLX3pLLwx7VidDbruBIx1N
         cljWxXDCkBRe1r+ZaUgOiglzAk62PK/7LbqkmLZFZKOsr2yYsmdMgCnU/IAgiqpMHPbP
         edp7bd/XIRK97DFi99HO9RiM0DunTXiOJOilz2wHuXJoA9SPRRiRa4bAM3KRgE8YuBjx
         dclSJCmatDepKwbmSCPZ/lfAv5WLNrBdNPZcHHQq9o/VxpZBgx4wED6mPBNdh52Mrm+x
         byzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737530348; x=1738135148;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=6SJAo92DyDNJXxNIt7nA2UJV2gTXGpGtR/vEGz4DxbQ=;
        b=pInACeOeF8/B0i6cmoNj5GwaIL6yYy1eKv1UedmC7fMwLs9thN43cv1ECL1HpFTrwA
         4Tr3ySK8CNd0XJcU+tD27Z0uqhLYlfhhYLAv244NfRq5rkKLaBAMAOFDT2MNRRRyESTq
         jPaihOnpaGXPiQkJlLcpViJUzVR6rRv/rnoqWXJ3VtbPXqo0fxmtenp+N0uoPJicKQ/k
         ikWvHGPJmJS6ngbL2BOqQFzi8ITT7KPbDRoc7ZnGczVBekJUccH34ifYHM4QIfta8E5/
         HhSfXqzJI9Z/NOGGriCUA38pMg6By8gtLOw/JKVcNxwpcmFfHQfgCTpmF5UseQNgyZP0
         g7AQ==
X-Forwarded-Encrypted: i=1; AJvYcCV0VOC6DmYKNfFGIprR6avnjtDF6YH4PwSPk8qFoyY19Ccw17DQwJ4DFQnfeO4/wRLMdFeYnnjo60U=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxw99LaxkNSOp+yThWo/+aJ/wHOsOg+SX7gp1yNHxUYMRuNds5e
	Wim5VQ5S/uDGbU/qWVQiuvEyWmoz0uh77lMIhRoCFQdFCtUaoptsa/3IyPHAzA==
X-Gm-Gg: ASbGncvFzgnkSESemPiGZyov4a0M0DXzV74nQfUmTwGGF/ri/rEE2SZPtTQ12khPpTJ
	Vo7qi/OFE464PcyIJuvXglXCj4NJHag5HsjHV6AVWRdFF4PjYmK6VSpeHw+fjhGIeMTou6JrDnK
	ah0VRutYvWcUnuJORfTExHBVIO/u71N/sKpmE4XK6kOx4OEbEWOonSPT3dXUs56XMofmywdqNmE
	DynRHhCGpamDFdpsC9W1cffL+UqQE9UT+2R03pq3+8lOJBXMuFouKUSa1CyQBcoIO9zG7HwCSGh
	VXvQm0j3dYoJmjKFxDmQALcdwGuxiBZmTqX7Pp7X4fBBHKenGB4j5bE=
X-Google-Smtp-Source: AGHT+IH3qI48ShHKGTiTqG5IrLo8zKLfLUJUlAC/orWWS151hSB30Iez6U+DXhV4yyzlpWAPXtaXog==
X-Received: by 2002:a5d:47a2:0:b0:38b:e22e:aee0 with SMTP id ffacd0b85a97d-38bf5b02a75mr17587005f8f.23.1737530348548;
        Tue, 21 Jan 2025 23:19:08 -0800 (PST)
Message-ID: <c490d01a-fe97-414d-8093-b0bff6a12eec@suse.com>
Date: Wed, 22 Jan 2025 08:19:07 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 01/24] xen/ctype: introduce is_console_printable()
To: dmukhin@ford.com
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
 <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
 <20250103-vuart-ns8250-v3-v1-1-c5d36b31d66c@ford.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250103-vuart-ns8250-v3-v1-1-c5d36b31d66c@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04.01.2025 02:58, Denis Mukhin via B4 Relay wrote:
> --- a/xen/include/xen/ctype.h
> +++ b/xen/include/xen/ctype.h
> @@ -4,6 +4,8 @@
>  /*
>   * NOTE! This ctype does not handle EOF like the standard C
>   * library is required to.
> + *
> + * See Rule 21.13 in docs/misra/rules.rst.
>   */

As previously indicated, I object to such comments. I think I said so before:
_All_ Misra rules are relevant _everywhere_ anyway.

> @@ -51,4 +53,9 @@ static inline unsigned char __toupper(unsigned char c)
>  #define tolower(c) ((char)__tolower(c))
>  #define toupper(c) ((char)__toupper(c))
>  
> +static inline unsigned is_console_printable(unsigned char c)
> +{
> +	return isprint(c) || c == '\n' || c == '\t';
> +}

Why a return type of unsigned (and then not even "unsigned int")? I can't
spot anything in the file which would serve as a reference for this, and
by its nature the function clearly wants to return bool.

I further question the placement of this function in ctype.h: Only console
related code cares about this function, so exposure is far too wide this
way.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jan 22 07:26:20 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Jan 2025 07:26:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875791.1286210 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taV7v-0007Eo-UM; Wed, 22 Jan 2025 07:26:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875791.1286210; Wed, 22 Jan 2025 07:26:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taV7v-0007Eh-RG; Wed, 22 Jan 2025 07:26:15 +0000
Received: by outflank-mailman (input) for mailman id 875791;
 Wed, 22 Jan 2025 07:26: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 <SRS0=XwhO=UO=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1taV7t-0007Eb-Si
 for xen-devel@lists.xenproject.org; Wed, 22 Jan 2025 07:26:13 +0000
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com
 [2a00:1450:4864:20::335])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 27ac1d29-d892-11ef-99a4-01e77a169b0f;
 Wed, 22 Jan 2025 08:26:11 +0100 (CET)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-4361e89b6daso44995245e9.3
 for <xen-devel@lists.xenproject.org>; Tue, 21 Jan 2025 23:26:11 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38bf327e06asm15730131f8f.95.2025.01.21.23.26.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 21 Jan 2025 23:26:08 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 27ac1d29-d892-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737530771; x=1738135571; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=uXON6t7AxhOnqd0US4WwWK/Pgdlb8dqLkOOvl3UraWs=;
        b=OcFJ+Lyq2W5AFwvmJj57rXSICal/KqucmQ+j1umToi+qdO3dbdU50WRk4c2SEf2xYe
         N6SxN5Egw464zIfZ2eLjDgkVSvtSt2cEo/D6aWabztuuu3HYUAzBG5z90NqQWj6oOhsl
         0yZZruEJ5EQKE6TLSRaSU7WBmUSjXW5tDyT2jCkbiKOXWbXuaV5ESSipwfOQEz3sFHV4
         tp0obEk4nWQO4mKuW8YutISiaSjoWRA9Nm004rCGLIB0uT6aQEsKZjPXzN0fHw6GM9t5
         kVsbLUwRR8Gfh/BtlRw/L1KSE6xyTja8BnNI3caCEuM5IUYtxCDNmYGJtH6SWFtvJe9V
         TF5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737530771; x=1738135571;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=uXON6t7AxhOnqd0US4WwWK/Pgdlb8dqLkOOvl3UraWs=;
        b=EN+LsEsObswleF8PS39SFQFm65e4K/1Mjo0/9vDbX84w98ffjIbME+rT9/0Tb+4V7Z
         QKeXol+F4bWHfWYQ4yQfvbzxjJpFpXZN0QH1iQMsNOFqykDvwFX7Cl4w0b7qUknVMpHM
         biVIldElh9OtMLcIhN1stWONqucgyjRayO9bs5b9Kt0HBuXVcHW9wSi/L9wFjx1mYslf
         tRZqcZSSzL2hhzwA/xdHfOBChBI/x/OWyrsllvjpx/vbFMv0u2GnPpVTmciEA3175O/h
         y0uyq+D91UqyXygSJdBc/ymQSQE102tGLRAzLTqnWSiom71KaRNT35cLwvfS7kxAtlqb
         LzTQ==
X-Forwarded-Encrypted: i=1; AJvYcCXva91dnzyTZ4KQ7bnbt7HtLPbc77NuTvRCmoEl/BSHtYO+5Uj4jaQrbK+/H2FijojH/usjajM7J3o=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyCAE57YP/2gIibC3K/CJABDogc1xuPbYe+0gSBSX//1YWIr8cA
	AhmFIl9NICty+yB8FB2ATVTKD0t4A8gq7Iv5Hooq7785GJUNj+1rQ00wts9Xkw==
X-Gm-Gg: ASbGncuOgnfBWyK6CMX5LsqmbTb1n8liVWSCp8uZY70WSpnw8aMpweb1f6abQl/eU3j
	tCRjQrD8TzkgbrlWl0Gy3dOhY45NT+6CGDDwrXzAzDdt2iChCWXYfF0jgDIJDYkFS63UvJyhAL5
	b/XGbqq0KcDrq1gcOMmjKScpwlYA2JENffvKUZdxCVBt1AeUPW7DFZvTlLMKX84ocjq7swc74jg
	A0+sxyYcC12ZpR7IZ33AzWkQ3SA3WOF6NhIvjE1RVPHM+dV1JOrBq1fB41NG7r2QnZ4ctf6DKHN
	SeKbq1wCgX0d/WlN6RS3i609EMoHpK7DvSVPmD8CjfkJQN+E4N98ATc=
X-Google-Smtp-Source: AGHT+IFXOLvBP+gbmo2rvCn94gz6toag1PleudUe00XW4enwQFjr5EhSWaVywxlq3lYSQ/lK0vE2/A==
X-Received: by 2002:adf:f788:0:b0:38a:41c9:8544 with SMTP id ffacd0b85a97d-38bf57a2838mr12894564f8f.37.1737530768580;
        Tue, 21 Jan 2025 23:26:08 -0800 (PST)
Message-ID: <68e3da06-2b21-4f42-8d24-2743290ac562@suse.com>
Date: Wed, 22 Jan 2025 08:26:07 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 02/24] arm/vuart: move vpl011-related code to vpl011
 emulator
To: Jason Andryuk <jason.andryuk@amd.com>, dmukhin@ford.com
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
 <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
 <20250103-vuart-ns8250-v3-v1-2-c5d36b31d66c@ford.com>
 <99bda095-391e-4825-9bb4-c21b7c5e1813@amd.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <99bda095-391e-4825-9bb4-c21b7c5e1813@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 21.01.2025 23:56, Jason Andryuk wrote:
> On 2025-01-03 20:58, Denis Mukhin via B4 Relay wrote:
>> --- a/xen/drivers/char/console.c
>> +++ b/xen/drivers/char/console.c
> 
>> @@ -579,6 +571,9 @@ static void __serial_rx(char c)
>>       if ( pv_shim && pv_console )
>>           consoled_guest_tx(c);
>>   #endif
>> +
>> +    if ( rc )
>> +        printk(KERN_ERR "d%pd: failed to process console input: %d\n", d, rc);
>>   }
>>   
>>   static void cf_check serial_rx(char c)
>>
> 
> This will print the ENOSPC that was formerly silent.  Since this is 
> input from the console, that seems more informative to the user and okay 
> to me.

I don't view this as okay. For one it needs to be a guest log level, such
that rate limiting can suitably suppress too many of these messages in a
short time (which in particular might happen if the ENOSPC reason isn't
dealt with by the receiving domain). And then I wonder whether this
wouldn't better be even more strongly limited, perhaps to just once per
domain.

I'm also unconvinced of KERN_ERR - from Xen's perspective nothing error-
like has happened, once again most notably for the ENOSPC case. I'd view
this as a warning at best.

Finally: Why d%pd? It ought to be just %pd.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jan 22 08:03:46 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Jan 2025 08:03:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875802.1286219 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taVi8-0004vA-GO; Wed, 22 Jan 2025 08:03:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875802.1286219; Wed, 22 Jan 2025 08:03:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taVi8-0004v3-Do; Wed, 22 Jan 2025 08:03:40 +0000
Received: by outflank-mailman (input) for mailman id 875802;
 Wed, 22 Jan 2025 08:03:38 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=bvhL=UO=bugseng.com=nicola.vetrini@srs-se1.protection.inumbo.net>)
 id 1taVi6-0004ux-A3
 for xen-devel@lists.xenproject.org; Wed, 22 Jan 2025 08:03:38 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 617fc6f2-d897-11ef-99a4-01e77a169b0f;
 Wed, 22 Jan 2025 09:03:36 +0100 (CET)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 by support.bugseng.com (Postfix) with ESMTPA id 29DCC4EEDA0A;
 Wed, 22 Jan 2025 09:03:35 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 617fc6f2-d897-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1737533015; bh=Ua93nFhI/sq4o/07h6AHLt7Zh4Rtu0WNi8meYxH9LUc=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=Zqf6I9B/hU5C2veWXkP75JvxehbS/g5T94KKutUsmnMEVCPun7k/rVAMlc/nPG31w
	 fICeoUdQh5rnWBsPYRmTcEYwK/KbQcHVbc12NwejfHO8k0MkKhQ1I3ugoH34m/a5Yl
	 RJeQBfrFoRrGI3oFq6xtuSH/J1jA+LCodB6NSMhp3f2h98DNpK4m5fww6UM7/XAoUY
	 PuMbLkGqlVFm1ouI6LXbwcOBbA3mS5DBfq5et4u/uQcrXsmeQcaggQnPymld+PkfXp
	 5hRPXqf0dqxPvAGqpFb59uV07yQJJcVZdKyAdH3htw4Y8tqEcJ3/PXrAZGr5sKcLg2
	 DL/i9KBK2FanQ==
MIME-Version: 1.0
Date: Wed, 22 Jan 2025 09:03:35 +0100
From: Nicola Vetrini <nicola.vetrini@bugseng.com>
To: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
Cc: xen-devel@lists.xenproject.org, Doug Goldstein <cardoe@cardoe.com>,
 Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2 3/4] automation: rename CONFIG_MEM_ACCESS ->
 CONFIG_VM_EVENT
In-Reply-To: <e43444e0cd04bf08edf47ee4c56d0aa675d19534.1737452864.git.Sergiy_Kibrik@epam.com>
References: <cover.1737452864.git.Sergiy_Kibrik@epam.com>
 <e43444e0cd04bf08edf47ee4c56d0aa675d19534.1737452864.git.Sergiy_Kibrik@epam.com>
Message-ID: <da69069d1e0dcc157abdf078790c2b34@bugseng.com>
X-Sender: nicola.vetrini@bugseng.com
Organization: BUGSENG s.r.l.
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit

On 2025-01-21 11:23, Sergiy Kibrik wrote:
> Following the renaming of Xen build option.
> 
> Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>

For the ECLAIR part:
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>

> ---
>  automation/eclair_analysis/xen_arm_config | 2 +-
>  automation/eclair_analysis/xen_x86_config | 2 +-
>  automation/gitlab-ci/build.yaml           | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/automation/eclair_analysis/xen_arm_config 
> b/automation/eclair_analysis/xen_arm_config
> index ef140ceb73..4b01ef51c5 100644
> --- a/automation/eclair_analysis/xen_arm_config
> +++ b/automation/eclair_analysis/xen_arm_config
> @@ -63,7 +63,7 @@ CONFIG_HAS_DEVICE_TREE=y
>  CONFIG_HAS_FAST_MULTIPLY=y
>  CONFIG_HAS_PDX=y
>  CONFIG_HAS_PMAP=y
> -# CONFIG_MEM_ACCESS is not set
> +# CONFIG_VM_EVENT is not set
>  CONFIG_STATIC_MEMORY=y
> 
>  #
> diff --git a/automation/eclair_analysis/xen_x86_config 
> b/automation/eclair_analysis/xen_x86_config
> index abc44d43e1..9da3264dd0 100644
> --- a/automation/eclair_analysis/xen_x86_config
> +++ b/automation/eclair_analysis/xen_x86_config
> @@ -54,7 +54,7 @@ CONFIG_HAS_PDX=y
>  CONFIG_HAS_SCHED_GRANULARITY=y
>  CONFIG_HAS_UBSAN=y
>  CONFIG_MEM_ACCESS_ALWAYS_ON=y
> -CONFIG_MEM_ACCESS=y
> +CONFIG_VM_EVENT=y
>  CONFIG_NEEDS_LIBELF=y
>  CONFIG_NUMA=y
> 
> diff --git a/automation/gitlab-ci/build.yaml 
> b/automation/gitlab-ci/build.yaml
> index bc4a8a5ad2..ed65e2edd7 100644
> --- a/automation/gitlab-ci/build.yaml
> +++ b/automation/gitlab-ci/build.yaml
> @@ -741,7 +741,7 @@ debian-12-riscv64-gcc:
>        CONFIG_EXPERT=y
>        CONFIG_GRANT_TABLE=n
>        CONFIG_LIVEPATCH=n
> -      CONFIG_MEM_ACCESS=n
> +      CONFIG_VM_EVENT=n
>        CONFIG_QEMU_PLATFORM=y
>        CONFIG_XSM=n

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253


From xen-devel-bounces@lists.xenproject.org Wed Jan 22 08:44:13 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Jan 2025 08:44:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875815.1286229 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taWL8-00025f-DJ; Wed, 22 Jan 2025 08:43:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875815.1286229; Wed, 22 Jan 2025 08:43:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taWL8-00025Y-Aj; Wed, 22 Jan 2025 08:43:58 +0000
Received: by outflank-mailman (input) for mailman id 875815;
 Wed, 22 Jan 2025 08:43:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=XwhO=UO=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1taWL6-00025R-Vx
 for xen-devel@lists.xenproject.org; Wed, 22 Jan 2025 08:43:56 +0000
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com
 [2a00:1450:4864:20::42a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 03203572-d89d-11ef-99a4-01e77a169b0f;
 Wed, 22 Jan 2025 09:43:54 +0100 (CET)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-38637614567so3205783f8f.3
 for <xen-devel@lists.xenproject.org>; Wed, 22 Jan 2025 00:43: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
 5b1f17b1804b1-438b31c7cc6sm15516675e9.36.2025.01.22.00.43.53
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 22 Jan 2025 00:43:53 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 03203572-d89d-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737535434; x=1738140234; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=RofGx1wSF73veAp4SZBgNWzAxn8WO51MSbDP+YrbTZA=;
        b=YkYCaiNMTjMZ4F7SMOHjsF6kdvZBwsJOF2rk3v+lxWU1Xt2yIXVBmAYqwsHj3uF6oW
         Ye4QtlbU12eQgPMP3b1V4WQeYwCVsnXc+MiwCq+Kzc/iiyTXoCoCMw62vPcrra5UCDf9
         Zxrge006YNWueD+EO81ftBc1oaimMzr+Y/CYEtIi5fb2Xo21MB2lvYrvEmqynawuaoMZ
         afXZWvrcFgQuI7E8UOBSMvFXzmEvt99MaZzi39NdDNyVWKtOoD54jSvtXaFxYMSNBTGS
         I/Mn1xihamRExm/T7uV6Ikamma+11LJvNLTuA9zMYW3IIPzl4JIKWOfUTyMK6fwlCLf9
         hxdw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737535434; x=1738140234;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=RofGx1wSF73veAp4SZBgNWzAxn8WO51MSbDP+YrbTZA=;
        b=Czp2sWDBxl5uRbUOV0HpafSuOGnoUAEAIdbyGpP5CLc/5j8OQtyPOotTConP3jRWkl
         Ark6DIAf32i1s+RFgA/AXoRdUxYpFvSJv3/kGCO6VRs5wMtiOlNCFETkfzLuWaeGZcrU
         dfmeZ8ZWlQfAkcXcbuHLexOTONiYGgKVEZ0zXDuPDSzrBxWjr6zS7IXTNwJDHFdKCsLl
         5SMrX/2/dVrG1DzRgmpVMBhaL9oUPpo9kYGes1kJhyKDPDY1+aadDcl0l0/aJU5d7ZXu
         YDgyhJCpMIRK/WSwsvt/1CugDQw2dW69y20RTsCn0+8g+uBfXsIS3pfj6HJjsn9w8ZfE
         2YJQ==
X-Forwarded-Encrypted: i=1; AJvYcCWvxSJrDVAV+xq1aTwt563MIlk2VYR13AAjNV+UuBTW0+OelQqnont7143gUp8RXVNLsxXibe2ihqA=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yytnzz7pJaYO+yU4SrpTPH7K+wRz5U/0tT5zM2MtcE98EL59ICd
	MqfsReN1xUxt+tOJrJQP58UIHB1HgAL5eol/b2441ubHQiRje1WYY/NJba/soA==
X-Gm-Gg: ASbGncsl1VobYDagnJCzmI1e60A90tD898PWZG+7zXtQYMoNGs1rcN5UseWcGvLq4Tm
	VfijGpF2zcbBFgcj0gUFgaXjVCsDclWsSmcEJD1TM9fHii3ZoRJ3afbaTGGYolJ3Pm+NWqePXoW
	qILUAZ5l5FqLHIRsC3kQhLshBDMNjxtYojnur65K/nNX7JTNB9VxVtI20sDT/CSNS23wYM/UcmS
	dI5sv80rWeTrhnFHZ2mQt5bb75VIKKcxIViCAIilAeuLnLKNODeIPiitLuJQraelZBrqVYzIywe
	EacmSIzHRq3UXrrky8mKJoIZT3lBI7ra1tjrU843vipiV6Fw0sBzo+8=
X-Google-Smtp-Source: AGHT+IHGnaZTw785Vb6QFvE3iyWGjlAJYJ/gKF1CsjH1bvCky/LP/fGm0k6S5xmxybvXMkyyuTEXHw==
X-Received: by 2002:a05:6000:1863:b0:385:e17a:ce61 with SMTP id ffacd0b85a97d-38bf57c9b17mr18673063f8f.53.1737535434135;
        Wed, 22 Jan 2025 00:43:54 -0800 (PST)
Message-ID: <c897005a-2e8e-4031-a828-acb8128f7c0c@suse.com>
Date: Wed, 22 Jan 2025 09:43:53 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/4] x86: provide an inverted Kconfig control for
 shim-exclusive mode
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Alejandro Vallejo <alejandro.vallejo@cloud.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Julien Grall <julien@xen.org>, Wei Liu <wl@xen.org>, sergiy_kibrik@epam.com
References: <Z4oxZSUQ6VARiR0H@macbook.local>
 <D74CH4RDRRR9.ZR6RL8U6PQ56@cloud.com>
 <6285f86d-f2d2-4040-999d-01aed3e72a36@suse.com>
 <alpine.DEB.2.22.394.2501171430570.2684657@ubuntu-linux-20-04-desktop>
 <f8c1e2c2-ceb5-4200-a304-e2d824a171a8@citrix.com>
 <40c9d806-000d-43e7-a804-ad4e84209b2f@suse.com>
 <alpine.DEB.2.22.394.2501201527090.11086@ubuntu-linux-20-04-desktop>
 <bae48627-fa5b-48b6-b74e-267285175eff@suse.com>
 <Z49gQBkxCbXIO84D@macbook.local>
 <41859184-bd9c-420f-96c1-65abe379b81e@suse.com>
 <Z4_hOmi01AkiYH_k@macbook.local>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <Z4_hOmi01AkiYH_k@macbook.local>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 21.01.2025 19:02, Roger Pau Monné wrote:
> On Tue, Jan 21, 2025 at 11:35:42AM +0100, Jan Beulich wrote:
>> On 21.01.2025 09:52, Roger Pau Monné wrote:
>>> On Tue, Jan 21, 2025 at 09:13:38AM +0100, Jan Beulich wrote:
>>>> On 21.01.2025 00:27, Stefano Stabellini wrote:
>>>>> If I understood it right, I like Andrew's suggestion. He is suggesting
>>>>> to do the following:
>>>>>
>>>>> - turning PV_SHIM_EXCLUSIVE into something that does nothing
>>>>
>>>> FTAOD - you mean Kconfig-wise? Andrew clearly didn't say "nothing", but
>>>> "nothing other than making the boolean be a compile time constant".
>>>
>>> Won't making the boolean a compile time constant would also result in
>>> DCO kicking in and removing a fair amount of code?  So even if you
>>> have enabled everything in Kconfig, the resulting hypervisor would
>>> only be suitable to be used as a shim?
>>
>> Of course.
> 
> Then what's the point of this approach?  Options will be enabled in
> Kconfig, but the resulting hypervisor build when using allyesconfig
> would have a lot of them short-circuited, making it even worse than
> currently?  As options will get effectively build-time disabled due
> to DCO while enabled in Kconfig.

Well, I have to direct this question to Andrew. It is specifically
what I'm trying to address with UNCONSTRAINED.

> Overall I think PV_SHIM_EXCLUSIVE should be excluded from
> allyesconfig, even with Andrew's proposed change.  Otherwise the
> purpose of allyesconfig is defeated if enabling PV_SHIM_EXCLUSIVE
> makes the resulting hypervisor build PV shim only.  IIRC we can
> provide a default alllyes.config with CONFIG_PV_SHIM_EXCLUSIVE=n.

Hmm, I wasn't aware of the option of using allyes.config. That might be
the route to go, albeit it looks like people using the allyesconfig
target then need to remember to set KCONFIG_ALLCONFIG in the environment
(to <empty> or 1), or to explicitly specify a file name that way. (This
of course ought to be easy enough to arrange for in our automation.)

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jan 22 09:16:19 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Jan 2025 09:16:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875830.1286245 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taWqL-0006ZV-2q; Wed, 22 Jan 2025 09:16:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875830.1286245; Wed, 22 Jan 2025 09:16:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taWqK-0006ZO-WF; Wed, 22 Jan 2025 09:16:13 +0000
Received: by outflank-mailman (input) for mailman id 875830;
 Wed, 22 Jan 2025 09:16:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=WfTz=UO=daimlertruck.com=john_preetham.l@srs-se1.protection.inumbo.net>)
 id 1taWqJ-0006ZI-41
 for xen-devel@lists.xenproject.org; Wed, 22 Jan 2025 09:16:11 +0000
Received: from FR5P281CU006.outbound.protection.outlook.com
 (mail-germanywestcentralazlp170120004.outbound.protection.outlook.com
 [2a01:111:f403:c20c::4])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8379cde3-d8a1-11ef-a0e5-8be0dac302b0;
 Wed, 22 Jan 2025 10:16:08 +0100 (CET)
Received: from FR2PPF86245AF1B.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d18:2::5d)
 by FR3P281MB2479.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:5f::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.17; Wed, 22 Jan
 2025 09:16:06 +0000
Received: from FR2PPF86245AF1B.DEUP281.PROD.OUTLOOK.COM
 ([fe80::ebcb:2ff2:50f7:cced]) by FR2PPF86245AF1B.DEUP281.PROD.OUTLOOK.COM
 ([fe80::ebcb:2ff2:50f7:cced%7]) with mapi id 15.20.8356.020; Wed, 22 Jan 2025
 09:16:06 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8379cde3-d8a1-11ef-a0e5-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=goy/zAmwMCTYOs5HObmeZ4rrAIwh7OZkOksK8suGbFN8tE7IZr4p+xA+tcF3xhUdGA3lrwQYbmKaoNlAuWL26Ya3PkxcAZ0x/hXhFMAa/vuycLJ8xIv5Rfp+wXEj8Fv4tntVfcTbcuxu3f1x0RF9+77PCZVJNscnQDeoKmjJm+AN2/BxL1nSe1kmMo3nkqOFWjqAiS5DTJLmOputm/LpF9lzHH5l8o9K1cngc/cakKuo8KXD0F+7LkG134iqW/a8E2bDSg4eT5GeJscZywB8cHbLtOcsaz8I6HsL6ZbHqptuuqUTA9g+gBuTLto54rTOBSc2rn96JubJvghdObj6Lg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=8JCkwHjvkVe47kj3/9kvU4Eu//s3c8eg2nnqgCch+Hc=;
 b=v+FQqMarm2JC53HwixlZ5fyJU5+FjT0CcNeNwLO57hF9/O/JVQ5DHzKh1RjXj464qNcCGx26ItpbyVK+s+484TNQ3rBtX2GO1aqr3/QNg/nZdFoFwuMnbxWOKBGpvtlvrBGgIVSwV00ShsM3gC5Xj3FqXN8R9anq1oDO/WrCfw37r++eAcrisTpMI8mKP+zc1w8e2oLZHiOHg0fsSIwGwDG1ntYsj/yKNrw/umYcgvGECMoYlZKq7mfF5xIDlPjmBjNEJB5d07tLFwKDSxL05K30mNRwB9qIXsPVZSFPfCtpF5VXc41YdRtkj7N/ry+CG4kossUP9ysx4JdMNzytPQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=daimlertruck.com; dmarc=pass action=none
 header.from=daimlertruck.com; dkim=pass header.d=daimlertruck.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=daimlertruck.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=8JCkwHjvkVe47kj3/9kvU4Eu//s3c8eg2nnqgCch+Hc=;
 b=QJ/4uBEOcJ9GSJYUozoEb8q9BcUM2/4VIemsszBUm0iU39PCCK4NpatC2TO82F5eDFmk6AI279kplr1Pt5kc98CHEmaA5ngP1LKTtLeiMiqGPGFKHM9UzNDmAjSxH+YKuPamTbpzJvYE+qBGfJ51EI41YTAchBNhIjbcDG6MCpODIIYXLSO0qJOsVZKajmYFqibIofYqXUl5tdOGhZ3rTBFFaAty7SimFpkKHwqoANGVt3uJhlzZy42mvsRG3hXGtjXWHdilAB1E59afOEPvo6jsRqOu/TuBKRKB6bXKt9LNAcrwKU7yow9fbi1aYKJxaerjN52JngloiWUpU9rdOQ==
From: "L, John Preetham (893)" <john_preetham.l@daimlertruck.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Request for Documentation on Bringing Up Xen on R-Car H3e (H3ULCB)
Thread-Topic: Request for Documentation on Bringing Up Xen on R-Car H3e
 (H3ULCB)
Thread-Index: AdtsrjaU74AF3fZpR/+NK9h56D1xZg==
Date: Wed, 22 Jan 2025 09:16:06 +0000
Message-ID:
 <FR2PPF86245AF1B81D71CF27EE705ED09B7B8E12@FR2PPF86245AF1B.DEUP281.PROD.OUTLOOK.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_b97ea58d-47e6-47cc-9ab7-39ab03def869_ActionId=3b8ad166-c234-4542-ba61-c22bd0df4fcb;MSIP_Label_b97ea58d-47e6-47cc-9ab7-39ab03def869_ContentBits=0;MSIP_Label_b97ea58d-47e6-47cc-9ab7-39ab03def869_Enabled=true;MSIP_Label_b97ea58d-47e6-47cc-9ab7-39ab03def869_Method=Standard;MSIP_Label_b97ea58d-47e6-47cc-9ab7-39ab03def869_Name=DT_Standard;MSIP_Label_b97ea58d-47e6-47cc-9ab7-39ab03def869_SetDate=2025-01-22T09:12:17Z;MSIP_Label_b97ea58d-47e6-47cc-9ab7-39ab03def869_SiteId=505cca53-5750-4134-9501-8d52d5df3cd1;
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=daimlertruck.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: FR2PPF86245AF1B:EE_|FR3P281MB2479:EE_
x-ms-office365-filtering-correlation-id: 6ec58d0d-6bed-460f-15da-08dd3ac566ac
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|366016|376014|8096899003|38070700018;
x-microsoft-antispam-message-info:
 =?us-ascii?Q?q/O0fo13vXDyvkEJ0aJlSDbqf1uorvW7TboPKBTJz4SZDnUMjfIgWzoC9788?=
 =?us-ascii?Q?Q2cDHPpT5wkugdiUR9771Sav5VT/ehdb/7T/AOIb9ErUzJnERyecq0hqb/kd?=
 =?us-ascii?Q?m5lZNdrUuJaZ6rbLkVWQYjgx1EVbT+Ie3XYzY42BPvdkyE1g64EX5pVb19kA?=
 =?us-ascii?Q?cZCHJ00UJnyHTE40uRmcZ3Pcz0mvh4lM6kuHqc/qEk0czvpDI+Y9ZGggyMka?=
 =?us-ascii?Q?pLc4dQx/wSiTVsp5O4+eQ6meYNjneDdeN7XWLNsWZtJ9elRtSOmBvy3gh4wn?=
 =?us-ascii?Q?Ouu700l1dRCtZPZeKDsgaVxNCHCGCpKf4we6VDMCuHuvtDUqmay+Fp5JMSg+?=
 =?us-ascii?Q?M+fofL3kyvChBiMBJes+Q/qloQyd3Z3lkLzBJ9cZwN1TL57Om8arQdKMYJad?=
 =?us-ascii?Q?sr6oTn1u+vcnGIh+sVdirvR0V1xOGi5Cp83CtdZ1R4Kxpa4SI4dnTyidvXYz?=
 =?us-ascii?Q?pMAgBu6nN/KLaIodTGlvMwn8REQLwCMkrcXxs45nxjlx8GuDysG/Fs/hEJl3?=
 =?us-ascii?Q?vYYAQSa2kbaj+GjGWPvMrCm7tDLtZ9xeC0a+hfbDZFEEqnRBFCXCRjrbu9jL?=
 =?us-ascii?Q?pf4zMHcqBOZx6hRL9HcSFDBp+LhyWi4Gl5u7kcqW1qUwb2ANbpbF3JMid6Sb?=
 =?us-ascii?Q?X0e/dq6vQ9JxzVMd9hsvO1pTSfnzOx+Blvz/pqTXlfQy5Lr5H3XEip+pImTt?=
 =?us-ascii?Q?+IZ3q9UhRvRS5bpnAKUv1l3pHA8q6D8wmptEspAAuX81i/AsP/MLo0XBWgSD?=
 =?us-ascii?Q?PyBzeVqJ4bBilB/9eYsfAZsFurgH4h0oNNLKsJoSveh9g0ihHGbAsMK0IvQd?=
 =?us-ascii?Q?t/vvF6W9toodU8oy4VbrS8+UnJZQ/GnawdGWEwJh21tQvyiSc0OOU0BGQLta?=
 =?us-ascii?Q?R43VV5qH9kKDKfBghA+9xFoE7ZNuwJGnB6mcu/CBW8H2zKHdgFYGaFyIcz9e?=
 =?us-ascii?Q?NKU/g3bpMX1diuS3wpsSEY5yNrV/mO6vYr0r/zsMAZU2NhHEw/R9o0LkDZ5Q?=
 =?us-ascii?Q?oyhNbTSnrZsmQnzAbGuI2j9BE3el6gmAV+SWCAf7qTJaOChhVDbuinBU51oz?=
 =?us-ascii?Q?hzX0nSVwngvtGw1NYceB9baOBR9wyCCIG1uUKmZrd2h3IqC9Ua/Q0vega2GW?=
 =?us-ascii?Q?vkm/ajC6Gcs6hrgCrWI6AySHMUhCXAS+wSlWIOsUjMfcuZkOZ0DDaxi/3EoL?=
 =?us-ascii?Q?/iwA7kExHnkadCx+VvCauBBc5Dj7KJ9pF1AYkCw1kzvVhZc9vBC4Jpdj0n8U?=
 =?us-ascii?Q?jJfLrcvMsSXJgtFBX96gM8JWMZcXMOSrznHAzxjqbMVjRvD0KPucupfllo+2?=
 =?us-ascii?Q?njklY/D7KusKnC/kRxg3KRLXH6eZWu1E1DG6DUyRnMTjFp5595mrJei7B5SV?=
 =?us-ascii?Q?Aw/JeuZNadHLZWZjTafPkbJEF6MSVjPYEDilcSNX5JrOlzhHnHYVtiwVtDaR?=
 =?us-ascii?Q?jQCcDKRmWLjXN/iAX/e6zgQ3yYaUb7qW?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:FR2PPF86245AF1B.DEUP281.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(8096899003)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?uxZLS3Lc6VFHjmtkosu9Cqik3zlirpAQHxDZxnEOVl89cdAhLWRCOIca7xAu?=
 =?us-ascii?Q?H7PVNoNSEw2qe9Ao04pnBrQectZ6hzoYzzxELkHPKPfDT58YlhHnl9+uV+a5?=
 =?us-ascii?Q?TirR2ZzP95tZJFj/Xl1bWyUhRR0f7PLupEC6nwVoGkxb5JU6Y+vBfcrHdhoB?=
 =?us-ascii?Q?nIFQw0uZchLOjP6SktT9F9pJ13oXWHPbCd+hMoHH3ILnDf1vQvXuyI89tR0Q?=
 =?us-ascii?Q?xy+Hn5gZviPszqUgmhOke9p+xvK9HdhSB4otPfXMJb/Hr5zHzc+OpU6+kvSa?=
 =?us-ascii?Q?RzhSnKe4iDh0j+224NV+dpFfTJd/FBD7TLK6olS0+2VJJ2B3nkcHqg8Di39E?=
 =?us-ascii?Q?5XfFLkfCXNYcb4a6lsvgwIZZvVqfjcwNO7gbqWonyDSebw8tU+wi4VURDDE3?=
 =?us-ascii?Q?eRLFmGQP7EfVKMZ8xBwVyezqa9tW6NN62CC1dI+syvczCMl9OlYry63XrvwZ?=
 =?us-ascii?Q?sU5zvRfVaSIZJqmHM4tTy/EmnJs/QkJPlz9hRn+rNDJGOrzaaCcgZUl8ogJC?=
 =?us-ascii?Q?4RyRKAkwT9pihZ8l6VshtsatCf68o1QO0ZbxHNsrDGbK2vxEij2NIi23qLGi?=
 =?us-ascii?Q?3c8YRN011Oosqa+PaepFK38n0tIkB0Eldng8FVTUrdOnKq1ZPJBgtgBM1XUD?=
 =?us-ascii?Q?I5874CjIl01e6EmrMXmPBLYQp7VhQeKEvFNhDG1l7IKL5layVV49vDMPzc6n?=
 =?us-ascii?Q?ZDLa4VzFMXKfO7+gikJg6tkcyKznhxNGSEzwx/xI2cTs/yGIt1TdeZcfEw0y?=
 =?us-ascii?Q?c5UeHBjZ8dujlQ4/eAPAAzP2XrcfkKTInUW3Mp5HrOWbPs5tT+Z+KLWQKDvt?=
 =?us-ascii?Q?s495FdaskMpRSeIPs5vvXaUX05pg5kpbN4ZTp94TNyAMSewbrHNy5WSM2H8R?=
 =?us-ascii?Q?5jmfWJw5TRgxzyMGicjG1F2BVjAJDiB9sWblpeXtXtQ9P8VkX7CyB3mOJazB?=
 =?us-ascii?Q?ZmAdWnWQ4f9PnhOSfC2EqN59oRf3IMdcygD+oENdfMOvDPodTkmtXUJYL28j?=
 =?us-ascii?Q?cOITXtxgHXMoZ55qn0oo0qd6cp66RxtimpZ1P6/OykGYf/DV6kd3b7NxV/BW?=
 =?us-ascii?Q?b/5QTMSnc++GdubJRs0eRedSiMqIewNAw7t/25tTSwUNerVxPH01MXVxoCLo?=
 =?us-ascii?Q?BviO3SxpiyEyKm6cPdMzk0M3er99ybhIQ3k9pbsSNIjI5d2hMig9Xhz1qI+I?=
 =?us-ascii?Q?K2Km4drf+hXQTrqjaDcTw2wCOYLhnTPVBPk/w2OmFAjeBqtpPI8kilKiPF3r?=
 =?us-ascii?Q?4Fax5PX6lY/jgPWmK4s6HXo7GbhHT4kmeLow5FXYYId1q+YZMYwAKzWomGwI?=
 =?us-ascii?Q?ymtBVC7Y4qSOOu629YbLoJPin4Bhe2g4Pr457NJsioAAX2l6lKHm7YpXZrOW?=
 =?us-ascii?Q?h/F11qQnnvFPViwrFf2LR00vyHL2++WKqjdxRYDtrKWoTEuJo592Yy40roDG?=
 =?us-ascii?Q?Elp9gvM9em1MXZuGIPZGOCfp4uMXETqJTDZltVFUSET2tutCbe/pOUg+r2t9?=
 =?us-ascii?Q?awjDk9yiFq+cppUbqOImpHAjWR3jZh8Ma84DkDY3WOKHgPC5t4AYbwZLOrMK?=
 =?us-ascii?Q?4CJT6qd6BIx5sukWvEk=3D?=
Content-Type: multipart/alternative;
	boundary="_000_FR2PPF86245AF1B81D71CF27EE705ED09B7B8E12FR2PPF86245AF1B_"
MIME-Version: 1.0
X-OriginatorOrg: daimlertruck.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: FR2PPF86245AF1B.DEUP281.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 6ec58d0d-6bed-460f-15da-08dd3ac566ac
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2025 09:16:06.1837
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 505cca53-5750-4134-9501-8d52d5df3cd1
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: HpiAXrE2BBslroTD79Jd2MrZKPwbcvJ9AVEUKt982NFslFc6zEJm1FKalR6czItLzmfY8MrP6+gPW0BmZU106w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: FR3P281MB2479

--_000_FR2PPF86245AF1B81D71CF27EE705ED09B7B8E12FR2PPF86245AF1B_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear Xen Community,

I hope this message finds you well.

I am currently working on a project that involves bringing up Xen on the Re=
nesas R-Car H3e (H3ULCB) platform. I am seeking guidance on where I can fin=
d the proper documentation for this process. Specifically, I am looking for=
 comprehensive documentation that covers everything from scratch to the end=
, including the required versions and any specific configurations.

Could anyone point me to the relevant resources or share any documentation =
that might be helpful?

Thank you in advance for your assistance.

Best regards,
John Preetham L


If you are not the addressee, please inform us immediately that you have re=
ceived this e-mail by mistake, and delete it. We thank you for your support=
.


--_000_FR2PPF86245AF1B81D71CF27EE705ED09B7B8E12FR2PPF86245AF1B_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"Segoe UI";
	panose-1:2 11 5 2 4 2 4 2 2 3;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;
	mso-ligatures:standardcontextual;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri",sans-serif;
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72" style=3D"word-wrap:=
break-word">
<div class=3D"WordSection1">
<p style=3D"mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;ma=
rgin-left:0in;background:#FAFAFA">
<span style=3D"font-size:10.5pt;font-family:&quot;Segoe UI&quot;,sans-serif=
;color:#242424">Dear Xen Community,<o:p></o:p></span></p>
<p style=3D"mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;ma=
rgin-left:0in;background:#FAFAFA;overflow-wrap: break-word;font-variant-lig=
atures: normal;font-variant-caps: normal;orphans: 2;text-align:start;widows=
: 2;-webkit-text-stroke-width: 0px;text-decoration-thickness: initial;text-=
decoration-style: initial;text-decoration-color: initial;word-spacing:0px">
<span style=3D"font-size:10.5pt;font-family:&quot;Segoe UI&quot;,sans-serif=
;color:#242424">I hope this message finds you well.<o:p></o:p></span></p>
<p style=3D"mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;ma=
rgin-left:0in;background:#FAFAFA;overflow-wrap: break-word;font-variant-lig=
atures: normal;font-variant-caps: normal;orphans: 2;text-align:start;widows=
: 2;-webkit-text-stroke-width: 0px;text-decoration-thickness: initial;text-=
decoration-style: initial;text-decoration-color: initial;word-spacing:0px">
<span style=3D"font-size:10.5pt;font-family:&quot;Segoe UI&quot;,sans-serif=
;color:#242424">I am currently working on a project that involves bringing =
up Xen on the Renesas R-Car H3e (H3ULCB) platform. I am seeking guidance on=
 where I can find the proper documentation for
 this process. Specifically, I am looking for comprehensive documentation t=
hat covers everything from scratch to the end, including the required versi=
ons and any specific configurations.<o:p></o:p></span></p>
<p style=3D"mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;ma=
rgin-left:0in;background:#FAFAFA;overflow-wrap: break-word;font-variant-lig=
atures: normal;font-variant-caps: normal;orphans: 2;text-align:start;widows=
: 2;-webkit-text-stroke-width: 0px;text-decoration-thickness: initial;text-=
decoration-style: initial;text-decoration-color: initial;word-spacing:0px">
<span style=3D"font-size:10.5pt;font-family:&quot;Segoe UI&quot;,sans-serif=
;color:#242424">Could anyone point me to the relevant resources or share an=
y documentation that might be helpful?<o:p></o:p></span></p>
<p style=3D"mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;ma=
rgin-left:0in;background:#FAFAFA;overflow-wrap: break-word;font-variant-lig=
atures: normal;font-variant-caps: normal;orphans: 2;text-align:start;widows=
: 2;-webkit-text-stroke-width: 0px;text-decoration-thickness: initial;text-=
decoration-style: initial;text-decoration-color: initial;word-spacing:0px">
<span style=3D"font-size:10.5pt;font-family:&quot;Segoe UI&quot;,sans-serif=
;color:#242424">Thank you in advance for your assistance.<br>
<br>
<span style=3D"background:#FAFAFA">Best regards,<br>
John Preetham L</span><o:p></o:p></span></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//DE">
<table cellpadding=3D"0" cellspacing=3D"0" border=3D"0">
<font face=3D"sans-serif, Arial, Helvetica" size=3D"-1" color=3D"#808080"><=
br>
If you are not the addressee, please inform us immediately that you have re=
ceived this e-mail by mistake, and delete it. We thank you for your support=
.<br>
<br>
</font>
</table>
</body>
</html>

--_000_FR2PPF86245AF1B81D71CF27EE705ED09B7B8E12FR2PPF86245AF1B_--


From xen-devel-bounces@lists.xenproject.org Wed Jan 22 09:49:32 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Jan 2025 09:49:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875844.1286255 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taXMI-0002Re-Fm; Wed, 22 Jan 2025 09:49:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875844.1286255; Wed, 22 Jan 2025 09:49:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taXMI-0002RX-Cm; Wed, 22 Jan 2025 09:49:14 +0000
Received: by outflank-mailman (input) for mailman id 875844;
 Wed, 22 Jan 2025 09:49: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
 <SRS0=jYzQ=UO=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1taXMI-0002RR-24
 for xen-devel@lists.xenproject.org; Wed, 22 Jan 2025 09:49:14 +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 22773307-d8a6-11ef-a0e5-8be0dac302b0;
 Wed, 22 Jan 2025 10:49:12 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-aaf57c2e0beso1301923166b.3
 for <xen-devel@lists.xenproject.org>; Wed, 22 Jan 2025 01:49:12 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab384c5c465sm891577866b.17.2025.01.22.01.49.11
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 22 Jan 2025 01:49:11 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 22773307-d8a6-11ef-a0e5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737539352; x=1738144152; 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=EJSCDKb2eB5CRIvZDbmZLNEwqJEBlN0L6WqqdCi1C5s=;
        b=sTPp3GY1BMmiy13ZPqwr2hXKW2jLWxUJXTKDisjWN7xQI6sFxzhZGcTdNjihMNETBj
         aaUJ+FZuC0+vesOSR3sPf3L8/ruaZWOj7u/qOFwexlVirBvhBXBqHQJ9cQlkWDYLZQ4J
         +aCmaWjUxFbXZMOBLLfFHwshevg7+s7jVxfqA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737539352; x=1738144152;
        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=EJSCDKb2eB5CRIvZDbmZLNEwqJEBlN0L6WqqdCi1C5s=;
        b=MjHn885lPnvzd8l2bgPSp6KTf+uTZ550CaHN66PseJAjaSbckSxdaYumm1IKROYmJj
         Gd9mtVKWrEbY7wRa0/FluuL2Y1wwCncqhh5+m3JVbCjNwYuzppF7myTqsT3Fmjtn7pc/
         uA2KsdGmJNZtu6jNemcsgHTQwqk4SsuJVMhbrr2bzwYUOhWP5AQLL4WryQkWCtPgRPq4
         YDe8Pf4IcGs0ouXDL2ttU2Or0Uh0kq3zhWxaiTHyCrHcMv7y7C3ojZmg0N7B6XAMBMIJ
         CnSOWTKoQn+Md8JTyqVX+EgjK0QaWLNSjhK/m1QdRW9CAYSfwhLhlzCuF6DiMSFjB5TO
         8whw==
X-Forwarded-Encrypted: i=1; AJvYcCVJkfmfGTJAG8lzH6f4UgMrRKW+rh08hlP3aJRd3+TRPsFQTuV+JwaPAjjKtqakqDr488NLycDQIpk=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz3b4Vn+Sm0LBNaHo4T1T8niYz1L87rPLoVUSNFtw9i/m2Uk6x/
	UlVf2Le+vhsBXxrY02YmvshuWXhado//aDXucgBuAIi7kDMSUcjtZUVHd9qIx/0=
X-Gm-Gg: ASbGnctGrA2vnMJ+ONbQy+ElVoy7Aw6p+C0M4PiEjBYb2EcguPJNsU/xrqu3Y/Pnf17
	C6jtaUUW6eYpFQ7K0fHFT6dFskRmg8xEjhB8tRb/gFZJFUjYIu77N6ueCecmhAhlEiLpqz/ui/o
	UpuGWtTNthcBs7q5OlcfnmuQUJrnbNw9usvVzzENkKUTT2/gv5DXEhshhdoPXFv02RiK4v/xL/T
	AvxM8Cw3qqpDntervUTz52+iwb9q9n4e1goYRCz4jzPHttHAiUUBdhxKPhzP4ehoFAlHB/l5k1k
	FjPJ
X-Google-Smtp-Source: AGHT+IETiRXoQSjhqFAYlk6Wqt2G/2hm//dP61dZAbkxSrUOgOP4ozfPdYXiY6KLOb15FJHuSlggfg==
X-Received: by 2002:a17:907:3e21:b0:ab6:5558:4922 with SMTP id a640c23a62f3a-ab655585167mr197757766b.41.1737539352139;
        Wed, 22 Jan 2025 01:49:12 -0800 (PST)
Date: Wed, 22 Jan 2025 10:49:04 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Alejandro Vallejo <alejandro.vallejo@cloud.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Julien Grall <julien@xen.org>, Wei Liu <wl@xen.org>,
	sergiy_kibrik@epam.com
Subject: Re: [PATCH v2 1/4] x86: provide an inverted Kconfig control for
 shim-exclusive mode
Message-ID: <Z5C_EJEtorK2pwGE@macbook.local>
References: <6285f86d-f2d2-4040-999d-01aed3e72a36@suse.com>
 <alpine.DEB.2.22.394.2501171430570.2684657@ubuntu-linux-20-04-desktop>
 <f8c1e2c2-ceb5-4200-a304-e2d824a171a8@citrix.com>
 <40c9d806-000d-43e7-a804-ad4e84209b2f@suse.com>
 <alpine.DEB.2.22.394.2501201527090.11086@ubuntu-linux-20-04-desktop>
 <bae48627-fa5b-48b6-b74e-267285175eff@suse.com>
 <Z49gQBkxCbXIO84D@macbook.local>
 <41859184-bd9c-420f-96c1-65abe379b81e@suse.com>
 <Z4_hOmi01AkiYH_k@macbook.local>
 <c897005a-2e8e-4031-a828-acb8128f7c0c@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <c897005a-2e8e-4031-a828-acb8128f7c0c@suse.com>

On Wed, Jan 22, 2025 at 09:43:53AM +0100, Jan Beulich wrote:
> On 21.01.2025 19:02, Roger Pau Monné wrote:
> > On Tue, Jan 21, 2025 at 11:35:42AM +0100, Jan Beulich wrote:
> >> On 21.01.2025 09:52, Roger Pau Monné wrote:
> >>> On Tue, Jan 21, 2025 at 09:13:38AM +0100, Jan Beulich wrote:
> >>>> On 21.01.2025 00:27, Stefano Stabellini wrote:
> >>>>> If I understood it right, I like Andrew's suggestion. He is suggesting
> >>>>> to do the following:
> >>>>>
> >>>>> - turning PV_SHIM_EXCLUSIVE into something that does nothing
> >>>>
> >>>> FTAOD - you mean Kconfig-wise? Andrew clearly didn't say "nothing", but
> >>>> "nothing other than making the boolean be a compile time constant".
> >>>
> >>> Won't making the boolean a compile time constant would also result in
> >>> DCO kicking in and removing a fair amount of code?  So even if you
> >>> have enabled everything in Kconfig, the resulting hypervisor would
> >>> only be suitable to be used as a shim?
> >>
> >> Of course.
> > 
> > Then what's the point of this approach?  Options will be enabled in
> > Kconfig, but the resulting hypervisor build when using allyesconfig
> > would have a lot of them short-circuited, making it even worse than
> > currently?  As options will get effectively build-time disabled due
> > to DCO while enabled in Kconfig.
> 
> Well, I have to direct this question to Andrew. It is specifically
> what I'm trying to address with UNCONSTRAINED.
> 
> > Overall I think PV_SHIM_EXCLUSIVE should be excluded from
> > allyesconfig, even with Andrew's proposed change.  Otherwise the
> > purpose of allyesconfig is defeated if enabling PV_SHIM_EXCLUSIVE
> > makes the resulting hypervisor build PV shim only.  IIRC we can
> > provide a default alllyes.config with CONFIG_PV_SHIM_EXCLUSIVE=n.
> 
> Hmm, I wasn't aware of the option of using allyes.config. That might be
> the route to go, albeit it looks like people using the allyesconfig
> target then need to remember to set KCONFIG_ALLCONFIG in the environment
> (to <empty> or 1), or to explicitly specify a file name that way. (This
> of course ought to be easy enough to arrange for in our automation.)

My knowledge of Kconfig is very limited, but isn't there a default
path for such file to be picked up by Kconfig?  I see we already have
a xen/tools/kconfig/allrandom.config, I was expecting it would be a
matter of dropping an allyes.config in that directory, but I haven't
tried.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Jan 22 10:14:26 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Jan 2025 10:14:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875853.1286265 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taXkb-0006ml-DU; Wed, 22 Jan 2025 10:14:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875853.1286265; Wed, 22 Jan 2025 10:14:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taXkb-0006me-9e; Wed, 22 Jan 2025 10:14:21 +0000
Received: by outflank-mailman (input) for mailman id 875853;
 Wed, 22 Jan 2025 10:14:20 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=sFHA=UO=cloud.com=frediano.ziglio@srs-se1.protection.inumbo.net>)
 id 1taXka-0006mW-GZ
 for xen-devel@lists.xenproject.org; Wed, 22 Jan 2025 10:14:20 +0000
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com
 [2a00:1450:4864:20::32b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a3f73a3a-d8a9-11ef-99a4-01e77a169b0f;
 Wed, 22 Jan 2025 11:14:18 +0100 (CET)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-4361b0ec57aso68989435e9.0
 for <xen-devel@lists.xenproject.org>; Wed, 22 Jan 2025 02:14:18 -0800 (PST)
Received: from localhost.localdomain (138.74.6.51.dyn.plus.net. [51.6.74.138])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438b31adbd7sm19001075e9.17.2025.01.22.02.14.16
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 22 Jan 2025 02:14:17 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a3f73a3a-d8a9-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1737540857; x=1738145657; 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=Bq0fItC7RjRBrIPmdbqHQFomEOwcPofRm5EAzxAg2Uo=;
        b=FViZOk5iMZh/DEw+5XwxVrBsNBhv2DB5P6BYQs4j0z89QuF7mdwKhwLR8szeVzz86H
         ayYOnpSV1RxmAAV/JndgyfH3HxJmOyrvfOjesn/RbXFVPJQhAYTBP8nt/7G70CKSGmh0
         8kgyPepTSWhP9jUq4OWWfBTmV/Yr+oaEbKbZ8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737540857; x=1738145657;
        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=Bq0fItC7RjRBrIPmdbqHQFomEOwcPofRm5EAzxAg2Uo=;
        b=cPJNt/GL9Ee8wBQavfT5yJwClYfXWapYLz6Q2O0MGLFuvOKVAeA/YvRNnuLKKUukHx
         teNwT2nZj3SaeSX1PJg9ScyRFQWVKlBOgA7GnmN4NyCKdzqbeJtpvmA34ccSiURIJxOB
         mCIp9CbvufilUetqYcHvHM3lf0toe7YsjYZot/Sgn5Jd5aL4sIXHqV9hSSXmtf5FoJQC
         LiRDk71puU5Zr7aGfuMBqccdu2fPkGSherRIrSE+tmMpKqJPZ4h7vaBSOPBQwz8LWSrT
         u63uLMb1m1EFbyz/0XKH8ZvDe5ivNdb8dW58uLgqAK/a83NQW8rjbc5/lfo9Za2gfCko
         hJ1A==
X-Gm-Message-State: AOJu0YwOqUTVwyLxe42ODlSqO/iOdpo1D2cOH0yUGnqW8oeoEvvFXolW
	nY1pG09kfAk25JX3O4Kiy78ntYAHFy7qXy3RLljcMiOaB9IswRaOg+YSGQYhCCjyVOYtit3N3bj
	oin8=
X-Gm-Gg: ASbGncvgsO4uh5rZZujWTZFC4N6zSpWqCM39BLIfQRgHLHTpjGmgZ9ZWTnMKU1Y5mh7
	xwpKdsXdSnNdpbvoJXjZNUoT/0zuJyiztkQFAXa4qxfBSk7oOH3k8EoaTMXwyAZNAkD6WJFNtXv
	WaB2CjRQHVukYY7hUpBRh5k0ikU6/vsJRCJm4/1pbKpma66o5UXI0XwLl87FDDRrsP9RTMDPhcb
	nS3cGFljc5sNEg/7/Guh0NBVcKDYAcHNmnJSONch34c3lTBEgDhcC9aYpdvTAyNZcMB9tqhZlsz
	vjJeVk7p9xB+NRCtnVnAo2kitnGb42gFMu4=
X-Google-Smtp-Source: AGHT+IH5ptnqZs0us7gx6e/DQfTaF0rHpZncxzilCqO1/Tgggj0TikgZ1u59liIvEysCh/YNhHmmNA==
X-Received: by 2002:a05:600c:4f84:b0:434:a90b:94fe with SMTP id 5b1f17b1804b1-438913ca9bamr207463655e9.10.1737540857557;
        Wed, 22 Jan 2025 02:14:17 -0800 (PST)
From: Frediano Ziglio <frediano.ziglio@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio <frediano.ziglio@cloud.com>,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>,
	Jan Beulich <jbeulich@suse.com>
Subject: [PATCH v5] Avoid crash calling PrintErrMesg from efi_multiboot2
Date: Wed, 22 Jan 2025 10:14:07 +0000
Message-Id: <20250122101407.52282-1-frediano.ziglio@cloud.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Although code is compiled with -fpic option data is not position
independent. This causes data pointer to become invalid if
code is not relocated properly which is what happens for
efi_multiboot2 which is called by multiboot entry code.

Code tested adding
   PrintErrMesg(L"Test message", EFI_BUFFER_TOO_SMALL);
in efi_multiboot2 before calling efi_arch_edd (this function
can potentially call PrintErrMesg).

Before the patch (XenServer installation on Qemu, xen replaced
with vanilla xen.gz):
  Booting `XenServer (Serial)'Booting `XenServer (Serial)'
  Test message: !!!! X64 Exception Type - 0E(#PF - Page-Fault)  CPU Apic ID - 00000000 !!!!
  ExceptionData - 0000000000000000  I:0 R:0 U:0 W:0 P:0 PK:0 SS:0 SGX:0
  RIP  - 000000007EE21E9A, CS  - 0000000000000038, RFLAGS - 0000000000210246
  RAX  - 000000007FF0C1B5, RCX - 0000000000000050, RDX - 0000000000000010
  RBX  - 0000000000000000, RSP - 000000007FF0C180, RBP - 000000007FF0C210
  RSI  - FFFF82D040467CE8, RDI - 0000000000000000
  R8   - 000000007FF0C1C8, R9  - 000000007FF0C1C0, R10 - 0000000000000000
  R11  - 0000000000001020, R12 - FFFF82D040467CE8, R13 - 000000007FF0C1B8
  R14  - 000000007EA33328, R15 - 000000007EA332D8
  DS   - 0000000000000030, ES  - 0000000000000030, FS  - 0000000000000030
  GS   - 0000000000000030, SS  - 0000000000000030
  CR0  - 0000000080010033, CR2 - FFFF82D040467CE8, CR3 - 000000007FC01000
  CR4  - 0000000000000668, CR8 - 0000000000000000
  DR0  - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000
  DR3  - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400
  GDTR - 000000007F9DB000 0000000000000047, LDTR - 0000000000000000
  IDTR - 000000007F48E018 0000000000000FFF,   TR - 0000000000000000
  FXSAVE_STATE - 000000007FF0BDE0
  !!!! Find image based on IP(0x7EE21E9A) (No PDB)  (ImageBase=000000007EE20000, EntryPoint=000000007EE23935) !!!!

After the patch:
  Booting `XenServer (Serial)'Booting `XenServer (Serial)'
  Test message: Buffer too small
  BdsDxe: loading Boot0000 "UiApp" from Fv(7CB8BDC9-F8EB-4F34-AAEA-3EE4AF6516A1)/FvFile(462CAA21-7614-4503-836E-8AB6F4662331)
  BdsDxe: starting Boot0000 "UiApp" from Fv(7CB8BDC9-F8EB-4F34-AAEA-3EE4AF6516A1)/FvFile(462CAA21-7614-4503-836E-8AB6F4662331)

This partially rollback commit 00d5d5ce23e6.

Fixes: 9180f5365524 ("x86: add multiboot2 protocol support for EFI platforms")
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
---
 xen/common/efi/boot.c | 58 +++++++++++++++++++++++++++++--------------
 1 file changed, 39 insertions(+), 19 deletions(-)
---
Changes since v1:
- added "Fixes:" tag;
- fixed cast style change.

Changes since v2:
- wrap long line.

Changes since v3:
- fixed "Fixes:" tag.

Changes since v4:
- use switch instead of tables.

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index efbec00af9..143b5681ba 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -287,33 +287,53 @@ static bool __init match_guid(const EFI_GUID *guid1, const EFI_GUID *guid2)
 /* generic routine for printing error messages */
 static void __init PrintErrMesg(const CHAR16 *mesg, EFI_STATUS ErrCode)
 {
-    static const CHAR16* const ErrCodeToStr[] __initconstrel = {
-        [~EFI_ERROR_MASK & EFI_NOT_FOUND]           = L"Not found",
-        [~EFI_ERROR_MASK & EFI_NO_MEDIA]            = L"The device has no media",
-        [~EFI_ERROR_MASK & EFI_MEDIA_CHANGED]       = L"Media changed",
-        [~EFI_ERROR_MASK & EFI_DEVICE_ERROR]        = L"Device error",
-        [~EFI_ERROR_MASK & EFI_VOLUME_CORRUPTED]    = L"Volume corrupted",
-        [~EFI_ERROR_MASK & EFI_ACCESS_DENIED]       = L"Access denied",
-        [~EFI_ERROR_MASK & EFI_OUT_OF_RESOURCES]    = L"Out of resources",
-        [~EFI_ERROR_MASK & EFI_VOLUME_FULL]         = L"Volume is full",
-        [~EFI_ERROR_MASK & EFI_SECURITY_VIOLATION]  = L"Security violation",
-        [~EFI_ERROR_MASK & EFI_CRC_ERROR]           = L"CRC error",
-        [~EFI_ERROR_MASK & EFI_COMPROMISED_DATA]    = L"Compromised data",
-        [~EFI_ERROR_MASK & EFI_BUFFER_TOO_SMALL]    = L"Buffer too small",
-    };
-    EFI_STATUS ErrIdx = ErrCode & ~EFI_ERROR_MASK;
-
     StdOut = StdErr;
     PrintErr(mesg);
     PrintErr(L": ");
 
-    if( (ErrIdx < ARRAY_SIZE(ErrCodeToStr)) && ErrCodeToStr[ErrIdx] )
-        mesg = ErrCodeToStr[ErrIdx];
-    else
+    switch (ErrCode)
     {
+    case EFI_NOT_FOUND:
+        mesg = L"Not found";
+        break;
+    case EFI_NO_MEDIA:
+        mesg = L"The device has no media";
+        break;
+    case EFI_MEDIA_CHANGED:
+        mesg = L"Media changed";
+        break;
+    case EFI_DEVICE_ERROR:
+        mesg = L"Device error";
+        break;
+    case EFI_VOLUME_CORRUPTED:
+        mesg = L"Volume corrupted";
+        break;
+    case EFI_ACCESS_DENIED:
+        mesg = L"Access denied";
+        break;
+    case EFI_OUT_OF_RESOURCES:
+        mesg = L"Out of resources";
+        break;
+    case EFI_VOLUME_FULL:
+        mesg = L"Volume is full";
+        break;
+    case EFI_SECURITY_VIOLATION:
+        mesg = L"Security violation";
+        break;
+    case EFI_CRC_ERROR:
+        mesg = L"CRC error";
+        break;
+    case EFI_COMPROMISED_DATA:
+        mesg = L"Compromised data";
+        break;
+    case EFI_BUFFER_TOO_SMALL:
+        mesg = L"Buffer too small";
+        break;
+    default:
         PrintErr(L"ErrCode: ");
         DisplayUint(ErrCode, 0);
         mesg = NULL;
+        break;
     }
     blexit(mesg);
 }
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Jan 22 10:24:13 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Jan 2025 10:24:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875862.1286275 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taXtw-0000A6-6f; Wed, 22 Jan 2025 10:24:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875862.1286275; Wed, 22 Jan 2025 10:24:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taXtw-00009x-3t; Wed, 22 Jan 2025 10:24:00 +0000
Received: by outflank-mailman (input) for mailman id 875862;
 Wed, 22 Jan 2025 10:23:58 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=jYzQ=UO=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1taXtu-00009o-N5
 for xen-devel@lists.xenproject.org; Wed, 22 Jan 2025 10:23:58 +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 fc7faff4-d8aa-11ef-99a4-01e77a169b0f;
 Wed, 22 Jan 2025 11:23:56 +0100 (CET)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-437a92d7b96so66206925e9.2
 for <xen-devel@lists.xenproject.org>; Wed, 22 Jan 2025 02:23:56 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438b318c059sm19606175e9.8.2025.01.22.02.23.55
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 22 Jan 2025 02:23:55 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: fc7faff4-d8aa-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737541436; x=1738146236; 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=FLcwpP7Zz4xxiGaVQcgn7KerB+Yi5fPr3kurnqDBUq8=;
        b=Nw1dtYylIdLr/HBSHIS52POr8lnAqFFAnx7eFeof+PHH/W1HSJT4JWi42rqNW77UdI
         2dY2dIus28JAbsy83vhI8VeGUK/oe4iP84o5f8WHXO3kKznk3oSKen5aY1Us/X5whmLL
         yj/RC7DiEY+YIX7aenbDpjTIWg1IVF52c+be8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737541436; x=1738146236;
        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=FLcwpP7Zz4xxiGaVQcgn7KerB+Yi5fPr3kurnqDBUq8=;
        b=HOy7hhtDChQIVg+uvzV6WJ0i3ReJcZYBUeKpGiLT4DInumY926PV7jxsMe8n04W9jn
         bKvFrUBybFCfjKQ+GVSlUk8UfLBCjyuNDGmVshkE0MAk4eXkZiHVgGNY8nsf6Aa+uCwd
         5d3k0hPlfH6q8qJQE+vDmgs4hnmu4CZuHkm+Yb7BKKzFdUXATsuFKNGmmGxnVYp+fsFa
         2Gs6QPx9trAN21TdIE6Er0xqBJ7sNIkXPULFI7bMvnS48Dg015kzQg/71FZ3YkBWSphV
         Q1sUfzdXcFSgLLIxSmK9yVD2INN4F+hGm9xwJLF7IyoWizAqDjSLChaee3zQ07fqJqo1
         EN/w==
X-Gm-Message-State: AOJu0YwqMhW5+/oppE6jvH3518ldY7YSJuQBOXIGhzVq8/vA13msYpCZ
	Mqk5AbUWHIhlwmA9wvOxWpMu3p4vZhNI+5OT78ry9HyZQrSnoYbMCTEnplWOl0A=
X-Gm-Gg: ASbGncvTbEoILXL5m3bmQdHi9/TN3iYozu9ahnVL0SA/aA+1tj2/C7xjx3LZYs53QNG
	B2fOjHF5yeKIg+e97s5t/sVyLt9U3SuSTMvt9tCwbWOa16rV3OWbw/gFpTjHV8yvye6vXozOqSW
	dcpsA8fkcPjSFRwpgkEXNWLxpN/qC9APSHJeb7EH+RLp85tkLV8puc0Vop8NZnM8iEorMNuNLB4
	+MBikW6Jp3JkF4AgDeklCHDjnPbgIvo1VhCr9xagB6S/bMZpfzeKdsxjsk4jJ7hWDugvfZncuA=
X-Google-Smtp-Source: AGHT+IE98PFtbN2cemTu0C8JTlVwZnRETr+CNiItbJ830J/cDg5kGb2/ApLZ/TLbwh/qDPthQ+IP0g==
X-Received: by 2002:a7b:cd0a:0:b0:438:a1f5:3e38 with SMTP id 5b1f17b1804b1-438a1f53e8fmr165716365e9.30.1737541436004;
        Wed, 22 Jan 2025 02:23:56 -0800 (PST)
Date: Wed, 22 Jan 2025 11:23:54 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>
Subject: Re: [PATCH v3] x86emul: further correct 64-bit mode zero count
 repeated string insn handling
Message-ID: <Z5DHOknjrhMoAGz6@macbook.local>
References: <2e81cf29-65fd-74fc-db4f-95c453acc327@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <2e81cf29-65fd-74fc-db4f-95c453acc327@suse.com>

On Fri, Aug 04, 2023 at 07:58:21AM +0200, Jan Beulich wrote:
> In an entirely different context I came across Linux commit 428e3d08574b
> ("KVM: x86: Fix zero iterations REP-string"), which points out that
> we're still doing things wrong: For one, there's no zero-extension at
> all on AMD. And then while RCX is zero-extended from 32 bits uniformly
> for all string instructions on newer hardware, RSI/RDI are only for MOVS
> and STOS on the systems I have access to. (On an old family 0xf system
> I've further found that for REP LODS even RCX is not zero-extended.)
> 
> Fixes: 79e996a89f69 ("x86emul: correct 64-bit mode repeated string insn handling with zero count")
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Roger Pau Monné <roger.pau@citrix.com>

> ---
> Partly RFC for none of this being documented anywhere (and it partly
> being model specific); inquiry pending.

Did you get any reply on this?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Jan 22 10:44:57 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Jan 2025 10:44:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875875.1286285 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taYE6-0003D7-Pk; Wed, 22 Jan 2025 10:44:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875875.1286285; Wed, 22 Jan 2025 10:44:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taYE6-0003D0-Mk; Wed, 22 Jan 2025 10:44:50 +0000
Received: by outflank-mailman (input) for mailman id 875875;
 Wed, 22 Jan 2025 10:44: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
 <SRS0=jYzQ=UO=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1taYE5-0003Cs-8B
 for xen-devel@lists.xenproject.org; Wed, 22 Jan 2025 10:44:49 +0000
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com
 [2a00:1450:4864:20::432])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e5e147f6-d8ad-11ef-99a4-01e77a169b0f;
 Wed, 22 Jan 2025 11:44:47 +0100 (CET)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-38a88ba968aso6226254f8f.3
 for <xen-devel@lists.xenproject.org>; Wed, 22 Jan 2025 02:44:47 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38bf327e024sm15580578f8f.88.2025.01.22.02.44.45
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 22 Jan 2025 02:44:45 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e5e147f6-d8ad-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737542686; x=1738147486; 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=nbKc52aZVFHWL/Kuo9uEPiusS6Q/xJ9mXewdDhI8Qxk=;
        b=p360OWuMgoYIeWZc8oe4589Qw3vvkTHsem4R1xbQk0ZETlUDWecPucImkL+iEaUecr
         R2Tfs1eTcXgX1cdmakApNe2N41xL2GIyiOCt1mxxigBBTHA/bWMaAfWGnvInM2KlL3Li
         Ax6WFmJSotDGtSBwIid7whqkgBNzg+dqMLqUo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737542686; x=1738147486;
        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=nbKc52aZVFHWL/Kuo9uEPiusS6Q/xJ9mXewdDhI8Qxk=;
        b=FMloX376bjjmFycnEfn/m+SDLaoTIKem2FxvFuqwRSZZ57ZE/EQ2BfXTISmRSdWFYJ
         Nq/szhZGE5dreDtUOfN/UsPGIdvvMxszj4hUnjrE5tupcOed2PIpl1wZQ2YS3wGnQl5O
         sL5QK3/tf3YEh3ILK78CA5qN9OIPZaJ4J7wNdyVOly5gXaL3dzJ1gEv1tcxU4AEIYDA+
         V0STmZAM8qnq8T0QxcJk/o63EeCVtKGhN9pE+uXfqJuppxeYWyeVkwdG5QVgaDEsC5vE
         1nXXF7F8m0a6VrBQjtUlgKOUiJawHRpQgKPeKnxZYI5y1DcoAw19hCULv1lxoLANj8JP
         4PZw==
X-Gm-Message-State: AOJu0YzzxszhuOPRMrFUAD6IkdPCluXOh1H8TxVcJ709oan2w6gqKa3d
	OYsRb9Iwa9ae7A44KQnce6wet9bbvsLYei5qFILW8u2Ic+kwfXHOljAsKMHaWSA=
X-Gm-Gg: ASbGncuZ3w/ZVbE6R3G8DDd0qIFYYMazq2HDeGMKUjo2FwuvU9dNktUcM9nn0V9UsQR
	XGjmBlUZZlOSi+2wiLSKBg3+saSuMmmn96sJ6vTi1AZAICOCAsnLgNbgcgjOuj1T96FVp/mt/JI
	qKRopaf3m+RR2dUXhdAHMZtVK1cFlEuf/40Db7GPDpDsxxwo4szyFOHB5WPRBp/MpMt51210uvI
	N5RR5NmLiz0M59d44k6GhTKz6zibcekGpwShWLSztAq48ExSIbBfN7yX/Q4WNov2of/q6xlfcc=
X-Google-Smtp-Source: AGHT+IFznrjlRDSTQgDmVqiAo4b+8DH9NMOARZhgheKnUQ+cnUOFIhlLvsAjXfgTwDAT90D2OpOz4Q==
X-Received: by 2002:a5d:6d86:0:b0:385:fc00:f5e1 with SMTP id ffacd0b85a97d-38bf5649261mr19491309f8f.9.1737542686554;
        Wed, 22 Jan 2025 02:44:46 -0800 (PST)
Date: Wed, 22 Jan 2025 11:44:44 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v2 1/5] x86/HVM: correct MMIO emulation cache bounds check
Message-ID: <Z5DMHJ0-W1xz4jz5@macbook.local>
References: <3294f629-f91f-4b5d-9eb0-40a34aa2ec3e@suse.com>
 <c7f78078-e0ab-40a7-8624-167512cbe1cf@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <c7f78078-e0ab-40a7-8624-167512cbe1cf@suse.com>

On Tue, Oct 01, 2024 at 10:48:20AM +0200, Jan Beulich wrote:
> To avoid overrunning the internal buffer we need to take the offset into
> the buffer into account.
> 
> Fixes: d95da91fb497 ("x86/HVM: grow MMIO cache data size to 64 bytes")
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Jan 22 11:57:41 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Jan 2025 11:57:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875889.1286294 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taZMJ-0003ng-Qr; Wed, 22 Jan 2025 11:57:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875889.1286294; Wed, 22 Jan 2025 11:57:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taZMJ-0003nZ-OO; Wed, 22 Jan 2025 11:57:23 +0000
Received: by outflank-mailman (input) for mailman id 875889;
 Wed, 22 Jan 2025 11:57:21 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=gzEB=UO=cloud.com=kelly.choi@srs-se1.protection.inumbo.net>)
 id 1taZMH-0003nT-TK
 for xen-devel@lists.xenproject.org; Wed, 22 Jan 2025 11:57:21 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 085acbd6-d8b8-11ef-99a4-01e77a169b0f;
 Wed, 22 Jan 2025 12:57:19 +0100 (CET)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-5d3d14336f0so12387583a12.3
 for <xen-devel@lists.xenproject.org>; Wed, 22 Jan 2025 03:57:19 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 085acbd6-d8b8-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1737547038; x=1738151838; darn=lists.xenproject.org;
        h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject
         :date:message-id:reply-to;
        bh=nm79P6NQOpbUxVOz/w/v/vi5vp2ye++U6SB3B9WBrQk=;
        b=gEmVK3uKzbgi9qWkKxuPbYHE4qO2QxPZ2Kd4RkfXE5bUxNSFAty+ALAvMRBGiISoZX
         W2W+cFNHDMkAD1T3GXslNUhu5NUg3FGeiTbn1TyM6QUIxaAD4iUYIPmKZrkTQLzbPbdg
         FitVALR+fRO9f1Ula6dCXtPETBgvu1s+VtQlo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737547038; x=1738151838;
        h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=nm79P6NQOpbUxVOz/w/v/vi5vp2ye++U6SB3B9WBrQk=;
        b=AZ328GNz68J1aDWqkXjAPGOC2kW+s8joZoyUWkeHzSHryzlws9IKvvPfZTCAMKllaI
         Vb4td20kcESdFHIFxsNnkMI10EoZtZPmRbEAR/blQLb7PpMLTTyVHKBkhGQc+AX6i7E7
         8G+z/DfHes0SmWzN0LZBFcj0QSOFLcO5u73zjEOL1nnTteWPNyxqErm26FP+dAJnOf4r
         Az0Q1ogA+SLhj65qzGQDadXOnqVDyJhZkHARON4v+CYQxD9RCeqmw5kIg5JvgZFhCSZy
         ckp5/LS/kGs7TPvAFJtlUxVH16LJtLCTCgqTVquXR7Xvq2rtlrz/qZh1q0Fm3OIKcian
         J9AQ==
X-Gm-Message-State: AOJu0YyucEoaFAVrdf+2qqC8Gvp2lFElIFT7RwARVVjX3X/Onqk4istl
	TT/Ew6PR3zIOw7ktppAcPX0bmB79vu0tF+rK3atKvVlpJ5HGv/KdtSL9LPbuf7AkHrlzSbVjuei
	RL0MQAn0z13rjGvXbH1fK1KFTSlawayzZ/v/FXP2Hyq7LE3i2WYE=
X-Gm-Gg: ASbGncvog4wCAtZGjeftNahE9khvRX6k8FZJw6jxNE2+1KrYpB/qlr0acIXk3UR4nN0
	CBDQ/U+TUyIQccGiW9T4/tm5VMhJIYOi/RPp1G3llEtuK01LnLcmd4Ojk3NSXLft1jdwdk2iIi1
	wfG2lbaG7Htmue8zefkJc=
X-Google-Smtp-Source: AGHT+IFSkMgxXAIMWle+crTM+30t6YD+chTbMVe5o+Ae+vkAbLOzEzq5pUd/qOBvhXlB3vBTGieI2tRVxGwryrAyoIE=
X-Received: by 2002:a17:907:969f:b0:ab2:d721:ed8e with SMTP id
 a640c23a62f3a-ab38b42e688mr2243496866b.39.1737547038355; Wed, 22 Jan 2025
 03:57:18 -0800 (PST)
MIME-Version: 1.0
From: Kelly Choi <kelly.choi@cloud.com>
Date: Wed, 22 Jan 2025 11:56:42 +0000
X-Gm-Features: AbW1kvZFsDqR5yA_pw6DfVgssdJoYd9tc2wolkoFRNJUZCIu9xTz9speJfu_Fo8
Message-ID: <CAO-mL=yv1MgVY+CNAf46xvTs1-cxFQo6bwL7cDOjr9ROfMZB-Q@mail.gmail.com>
Subject: Xen Project Grenoble Meetup - Schedule
To: xen-devel <xen-devel@lists.xenproject.org>
Cc: Olivier Lambert <olivier.lambert@vates.fr>
Content-Type: multipart/alternative; boundary="000000000000009ced062c4a3239"

--000000000000009ced062c4a3239
Content-Type: text/plain; charset="UTF-8"

Hi all,

The schedule for the Xen Project meetup has now been published.
https://cfp.vates.tech/xen-meetup-2025/schedule/

Hope to see you there!

Thanks,
Kelly Choi
Community Manager
Xen Project <https://xenproject.org/>

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

<div dir=3D"ltr"><div>Hi all,=C2=A0</div><div><br></div><div>The schedule f=
or the Xen Project meetup has now been published.=C2=A0</div><div><a href=
=3D"https://cfp.vates.tech/xen-meetup-2025/schedule/">https://cfp.vates.tec=
h/xen-meetup-2025/schedule/</a>=C2=A0</div><div><br></div><div>Hope to see =
you there!</div><div><br></div><div><div dir=3D"ltr" class=3D"gmail_signatu=
re" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>Thanks,</div><=
div>Kelly Choi<br></div><div><div style=3D"color:rgb(136,136,136)">Communit=
y Manager</div><div style=3D"color:rgb(136,136,136)"><a href=3D"https://xen=
project.org/" target=3D"_blank">Xen Project</a><br></div></div></div></div>=
</div></div>

--000000000000009ced062c4a3239--


From xen-devel-bounces@lists.xenproject.org Wed Jan 22 12:00:21 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Jan 2025 12:00:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875903.1286304 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taZPA-0005P0-JE; Wed, 22 Jan 2025 12:00:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875903.1286304; Wed, 22 Jan 2025 12:00:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taZPA-0005Ot-Gg; Wed, 22 Jan 2025 12:00:20 +0000
Received: by outflank-mailman (input) for mailman id 875903;
 Wed, 22 Jan 2025 12:00:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=jYzQ=UO=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1taZP9-0005Oh-2j
 for xen-devel@lists.xenproject.org; Wed, 22 Jan 2025 12:00:19 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 71e15ec9-d8b8-11ef-99a4-01e77a169b0f;
 Wed, 22 Jan 2025 13:00:16 +0100 (CET)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-ab39f84cbf1so868767466b.3
 for <xen-devel@lists.xenproject.org>; Wed, 22 Jan 2025 04:00:16 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab384c56fc9sm910060966b.14.2025.01.22.04.00.14
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 22 Jan 2025 04:00:15 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 71e15ec9-d8b8-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737547216; x=1738152016; 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=3myN014Aqnv4wVHqpthFcYH4tQfPzWvxstnSnEWD1Fo=;
        b=obpyYE5goX9Kl427AV4FTDPC9/42QU3TzhiUp2o3dYG2O33FwGipusIO9EpeGWrv6O
         7WIZ+cNgcJICBNL4nZIUPwFoPnUrEC6bi8kUidBsLPEVF6VLSxoskjecNqYyvDw5h/D7
         CVydFDzBtiieQvjWsJqBkD8Hb1kY6ds2KgeE8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737547216; x=1738152016;
        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=3myN014Aqnv4wVHqpthFcYH4tQfPzWvxstnSnEWD1Fo=;
        b=q9D3PxuAZlLWKInlUZh61Ip7Bu4lWIM9erzebPrE36VH36oNHq59spsFzvzcpGT2co
         Sif8iI0tleJMI7z+ZRZ9Mp4zUKTVrDoDIoQXmy8OlECO2/AnTvV2oGTnaunRrl6nZ2uI
         QdtQXnHiJx9gMRCRzXxhwoGEBs0I910BdWZQyV4UBrTaH2itTPb6tOxvKVSzOlrZpLfz
         wnq2e/tUoJN0Tt+rFE7yQpTLWGRmi8SA5tDJirTKESG5GI42uTqqk8FxDuN6dsosfS4U
         Zx5amSBSm/L0rhAURcdlL8H5vmQMpvbhtaJEcTjoAsEv6dJ4rk2hxIqr7wWKFRoVbW7j
         gBig==
X-Gm-Message-State: AOJu0YzV9AUQyfkfxh/eF3IxJcAnegIa9UW4XlYBg2ir/FMGMBE1RztV
	AWOTQX0QZoOqEmx45XoXug+EGDA7SmFEVsCPc5jFCDoRuvEbpvENr6n1ZRPAtAKZw9K1ZCt0TiU
	3
X-Gm-Gg: ASbGncv85NRYK14lBtaFb/fWkpbagqNW4D/wuP7DhRWcqsMub6P0QQXpZzDVq/gdpco
	b9tii6OaT7zCbo0CkNVoWR0bViO3VKb5IbzZUBazE+Gu+vSXGx3IILNeLtFpo49vrzwWKu648hd
	bJcpLtYEe8sCjhdHRLH6xI53XDeEFVFDVawHBvaTC8AVRbJzZvj7gXg9habLwKmvcRRHmTuFl07
	a2VkiDuHYC8HkvXrTHmrkAuzTpFM+UHpWryri7hjTa0eqjSlqFmt1sZa8sKtgiLkjnVZ+g9MCGR
	SAM6
X-Google-Smtp-Source: AGHT+IGY+OWgIP7COSfUTRVofSe4SEhbeMlE7xr3ttJ9YDEGYYumHF8golmYLkERHWOJK3aj+BexCw==
X-Received: by 2002:a17:907:1b15:b0:ab6:53fb:9683 with SMTP id a640c23a62f3a-ab653fba885mr230447166b.54.1737547216328;
        Wed, 22 Jan 2025 04:00:16 -0800 (PST)
Date: Wed, 22 Jan 2025 13:00:14 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v2 2/5] x86/HVM: allocate emulation cache entries
 dynamically
Message-ID: <Z5Ddzh-Ygy5cGuPj@macbook.local>
References: <3294f629-f91f-4b5d-9eb0-40a34aa2ec3e@suse.com>
 <93967ab8-a472-475a-bdd6-41dfc3afa895@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <93967ab8-a472-475a-bdd6-41dfc3afa895@suse.com>

On Tue, Oct 01, 2024 at 10:49:10AM +0200, Jan Beulich wrote:
> Both caches may need higher capacity, and the upper bound will need to
> be determined dynamically based on CPUID policy (for AMX'es TILELOAD /
> TILESTORE at least).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Just a couple of comments below.

> ---
> This is a patch taken from the AMX series, but wasn't part of the v3
> submission. All I did is strip out the actual AMX bits (from
> hvmemul_cache_init()), plus of course change the description. As a
> result some local variables there may look unnecessary, but this way
> it's going to be less churn when the AMX bits are added. The next patch
> pretty strongly depends on the changed approach (contextually, not so
> much functionally), and I'd really like to avoid rebasing that one ahead
> of this one, and then this one on top of that.

Oh, I was just going to ask about the weirdness of nents compared to
what was previously.

> 
> TBD: For AMX hvmemul_cache_init() will become CPUID policy dependent. We
>      could of course take the opportunity and also reduce overhead when
>      AVX-512 (and maybe even AVX) is unavailable (in the future: to the
>      guest).
> ---
> v2: Split off cache bounds check fix.
> 
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -26,6 +26,18 @@
>  #include <asm/iocap.h>
>  #include <asm/vm_event.h>
>  
> +/*
> + * We may read or write up to m512 or up to a tile row as a number of
> + * device-model transactions.
> + */
> +struct hvm_mmio_cache {
> +    unsigned long gla;
> +    unsigned int size;
> +    unsigned int space:31;

Having size and space is kind of confusing, would you mind adding a
comment that size is the runtime consumed buffer space, while space is
the total allocated buffer size (and hence not supposed to change
during usage)?

> +    unsigned int dir:1;
> +    uint8_t buffer[] __aligned(sizeof(long));
> +};
> +
>  struct hvmemul_cache
>  {
>      /* The cache is disabled as long as num_ents > max_ents. */
> @@ -935,7 +947,7 @@ static int hvmemul_phys_mmio_access(
>      }
>  
>      /* Accesses must not overflow the cache's buffer. */
> -    if ( offset + size > sizeof(cache->buffer) )
> +    if ( offset + size > cache->space )
>      {
>          ASSERT_UNREACHABLE();
>          return X86EMUL_UNHANDLEABLE;
> @@ -1011,7 +1023,7 @@ static struct hvm_mmio_cache *hvmemul_fi
>  
>      for ( i = 0; i < hvio->mmio_cache_count; i ++ )
>      {
> -        cache = &hvio->mmio_cache[i];
> +        cache = hvio->mmio_cache[i];
>  
>          if ( gla == cache->gla &&
>               dir == cache->dir )
> @@ -1027,10 +1039,11 @@ static struct hvm_mmio_cache *hvmemul_fi
>  
>      ++hvio->mmio_cache_count;
>  
> -    cache = &hvio->mmio_cache[i];
> -    memset(cache, 0, sizeof (*cache));
> +    cache = hvio->mmio_cache[i];
> +    memset(cache->buffer, 0, cache->space);
>  
>      cache->gla = gla;
> +    cache->size = 0;
>      cache->dir = dir;
>  
>      return cache;
> @@ -2978,16 +2991,21 @@ void hvm_dump_emulation_state(const char
>  int hvmemul_cache_init(struct vcpu *v)
>  {
>      /*
> -     * No insn can access more than 16 independent linear addresses (AVX512F
> -     * scatters/gathers being the worst). Each such linear range can span a
> -     * page boundary, i.e. may require two page walks. Account for each insn
> -     * byte individually, for simplicity.
> +     * AVX512F scatter/gather insns can access up to 16 independent linear
> +     * addresses, up to 8 bytes size. Each such linear range can span a page
> +     * boundary, i.e. may require two page walks.
> +     */
> +    unsigned int nents = 16 * 2 * (CONFIG_PAGING_LEVELS + 1);
> +    unsigned int i, max_bytes = 64;
> +    struct hvmemul_cache *cache;
> +
> +    /*
> +     * Account for each insn byte individually, both for simplicity and to
> +     * leave some slack space.
>       */
> -    const unsigned int nents = (CONFIG_PAGING_LEVELS + 1) *
> -                               (MAX_INST_LEN + 16 * 2);
> -    struct hvmemul_cache *cache = xmalloc_flex_struct(struct hvmemul_cache,
> -                                                      ents, nents);
> +    nents += MAX_INST_LEN * (CONFIG_PAGING_LEVELS + 1);
>  
> +    cache = xvmalloc_flex_struct(struct hvmemul_cache, ents, nents);

Change here seems completely unrelated, but I guess this is what you
refer to in the post-commit remark.  IOW: the split of the nents
variable setup, plus the change of xmalloc_flex_struct() ->
xvmalloc_flex_struct() don't seem to be related to the change at
hand.

>      if ( !cache )
>          return -ENOMEM;
>  
> @@ -2997,6 +3015,15 @@ int hvmemul_cache_init(struct vcpu *v)
>  
>      v->arch.hvm.hvm_io.cache = cache;
>  
> +    for ( i = 0; i < ARRAY_SIZE(v->arch.hvm.hvm_io.mmio_cache); ++i )
> +    {
> +        v->arch.hvm.hvm_io.mmio_cache[i] =
> +            xmalloc_flex_struct(struct hvm_mmio_cache, buffer, max_bytes);

TBH I would be tempted to just use xvmalloc here also, even if the
structure is never going to be > PAGE_SIZE, it's more consistent IMO.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Jan 22 12:26:05 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Jan 2025 12:26:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875916.1286315 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taZny-0000Mh-HA; Wed, 22 Jan 2025 12:25:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875916.1286315; Wed, 22 Jan 2025 12:25:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taZny-0000Ma-E9; Wed, 22 Jan 2025 12:25:58 +0000
Received: by outflank-mailman (input) for mailman id 875916;
 Wed, 22 Jan 2025 12:25:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=fBaA=UO=kernel.org=joel.granados@srs-se1.protection.inumbo.net>)
 id 1taZnx-0000MU-7j
 for xen-devel@lists.xenproject.org; Wed, 22 Jan 2025 12:25:57 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0574c9c5-d8bc-11ef-99a4-01e77a169b0f;
 Wed, 22 Jan 2025 13:25:53 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 8086E5C54FD;
 Wed, 22 Jan 2025 12:25:11 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1DED6C4CED6;
 Wed, 22 Jan 2025 12:25:51 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 0574c9c5-d8bc-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1737548751;
	bh=Xfp892u0X0rMtHWkGD3r2bVHj+FTM/t28M4VtoJ0Wyc=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=ZRnNn+6Tt76019xBirdMVmzRbeL8Q2odMq6HFhgkth9P5ZrYdpErYPlXsxL6Fl3rj
	 ZI5VtP10jvH/fQAv6HRDykVpsfGmvb0d/xEWjnDE5tgAnq++jvuWWHT6WYDemhqEh2
	 qhtEzGq7/MMx5/wpO74r4FRgEujUuclOLSKI/Yy3NZM6X5dfnqSKY4Ag8uJB7GG8XW
	 AQ7J/NzQdgEpLRKLYUKh7jqPAvOBjZZ+gq5nRJ0qTwqiguA+mChUjtx0pX3QTt2bwy
	 E0gMyTw1G3DnV5TJGaTuN+E86ySP5PQe5fDrGHlTa+/9p9roru7zJ1Awo7fm8PfyZm
	 vQJdRIi7afA0Q==
Date: Wed, 22 Jan 2025 13:25:46 +0100
From: Joel Granados <joel.granados@kernel.org>
To: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Thomas =?utf-8?Q?Wei=C3=9Fschuh?= <linux@weissschuh.net>, 
	Kees Cook <kees@kernel.org>, Luis Chamberlain <mcgrof@kernel.org>, 
	linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, 
	linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-crypto@vger.kernel.org, 
	openipmi-developer@lists.sourceforge.net, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, 
	intel-xe@lists.freedesktop.org, linux-hyperv@vger.kernel.org, linux-rdma@vger.kernel.org, 
	linux-raid@vger.kernel.org, linux-scsi@vger.kernel.org, linux-serial@vger.kernel.org, 
	xen-devel@lists.xenproject.org, linux-aio@kvack.org, linux-fsdevel@vger.kernel.org, 
	netfs@lists.linux.dev, codalist@coda.cs.cmu.edu, linux-mm@kvack.org, 
	linux-nfs@vger.kernel.org, ocfs2-devel@lists.linux.dev, fsverity@lists.linux.dev, 
	linux-xfs@vger.kernel.org, io-uring@vger.kernel.org, bpf@vger.kernel.org, 
	kexec@lists.infradead.org, linux-trace-kernel@vger.kernel.org, 
	linux-hardening@vger.kernel.org, apparmor@lists.ubuntu.com, linux-security-module@vger.kernel.org, 
	keyrings@vger.kernel.org, Song Liu <song@kernel.org>, 
	"Steven Rostedt (Google)" <rostedt@goodmis.org>, "Martin K. Petersen" <martin.petersen@oracle.com>, 
	"Darrick J. Wong" <djwong@kernel.org>, Jani Nikula <jani.nikula@intel.com>, 
	Corey Minyard <cminyard@mvista.com>
Subject: Re: Re: [PATCH v2] treewide: const qualify ctl_tables where
 applicable
Message-ID: <nslqrapp4v3rknjgtfk4cg64ha7rewrrg24aslo2e5jmxfwce5@t4chrpuk632k>
References: <20250110-jag-ctl_table_const-v2-1-0000e1663144@kernel.org>
 <Z4+jwDBrZNRgu85S@li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Z4+jwDBrZNRgu85S@li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com>

On Tue, Jan 21, 2025 at 02:40:16PM +0100, Alexander Gordeev wrote:
> On Fri, Jan 10, 2025 at 03:16:08PM +0100, Joel Granados wrote:
> 
> Hi Joel,
> 
> > Add the const qualifier to all the ctl_tables in the tree except for
> > watchdog_hardlockup_sysctl, memory_allocation_profiling_sysctls,
> > loadpin_sysctl_table and the ones calling register_net_sysctl (./net,
> > drivers/inifiniband dirs). These are special cases as they use a
> > registration function with a non-const qualified ctl_table argument or
> > modify the arrays before passing them on to the registration function.
> > 
> > Constifying ctl_table structs will prevent the modification of
> > proc_handler function pointers as the arrays would reside in .rodata.
> > This is made possible after commit 78eb4ea25cd5 ("sysctl: treewide:
> > constify the ctl_table argument of proc_handlers") constified all the
> > proc_handlers.
> 
> I could identify at least these occurences in s390 code as well:
Hey Alexander

Thx for bringing these to my attention. I had completely missed them as
the spatch only deals with ctl_tables outside functions.

Short answer:
These should not be included in the current patch because they are a
different pattern from how sysctl tables are usually used. So I will not
include them.

With that said, I think it might be interesting to look closer at them
as they seem to be complicating the proc_handler (I have to look at them
closer).

I see that they are defining a ctl_table struct within the functions and
just using the data (from the incoming ctl_table) to forward things down
to proc_do{u,}intvec_* functions. This is very odd and I have only seen
it done in order to change the incoming ctl_table (which is not what is
being done here).

I will take a closer look after the merge window and circle back with
more info. Might take me a while as I'm not very familiar with s390
code; any additional information on why those are being used inside the
functions would be helpfull.

Best


> 
> diff --git a/arch/s390/appldata/appldata_base.c b/arch/s390/appldata/appldata_base.c
> index dd7ba7587dd5..9b83c318f919 100644
> --- a/arch/s390/appldata/appldata_base.c
> +++ b/arch/s390/appldata/appldata_base.c
> @@ -204,7 +204,7 @@ appldata_timer_handler(const struct ctl_table *ctl, int write,
>  {
>  	int timer_active = appldata_timer_active;
>  	int rc;
> -	struct ctl_table ctl_entry = {
> +	const struct ctl_table ctl_entry = {
>  		.procname	= ctl->procname,
>  		.data		= &timer_active,
>  		.maxlen		= sizeof(int),
> @@ -237,7 +237,7 @@ appldata_interval_handler(const struct ctl_table *ctl, int write,
>  {
>  	int interval = appldata_interval;
>  	int rc;
> -	struct ctl_table ctl_entry = {
> +	const struct ctl_table ctl_entry = {
>  		.procname	= ctl->procname,
>  		.data		= &interval,
>  		.maxlen		= sizeof(int),
> @@ -269,7 +269,7 @@ appldata_generic_handler(const struct ctl_table *ctl, int write,
>  	struct list_head *lh;
>  	int rc, found;
>  	int active;
> -	struct ctl_table ctl_entry = {
> +	const struct ctl_table ctl_entry = {
>  		.data		= &active,
>  		.maxlen		= sizeof(int),
>  		.extra1		= SYSCTL_ZERO,
> diff --git a/arch/s390/kernel/hiperdispatch.c b/arch/s390/kernel/hiperdispatch.c
> index 7857a7e8e56c..7d0ba16085c1 100644
> --- a/arch/s390/kernel/hiperdispatch.c
> +++ b/arch/s390/kernel/hiperdispatch.c
> @@ -273,7 +273,7 @@ static int hiperdispatch_ctl_handler(const struct ctl_table *ctl, int write,
>  {
>  	int hiperdispatch;
>  	int rc;
> -	struct ctl_table ctl_entry = {
> +	const struct ctl_table ctl_entry = {
>  		.procname	= ctl->procname,
>  		.data		= &hiperdispatch,
>  		.maxlen		= sizeof(int),
> diff --git a/arch/s390/kernel/topology.c b/arch/s390/kernel/topology.c
> index 6691808bf50a..26e50de83d80 100644
> --- a/arch/s390/kernel/topology.c
> +++ b/arch/s390/kernel/topology.c
> @@ -629,7 +629,7 @@ static int topology_ctl_handler(const struct ctl_table *ctl, int write,
>  	int enabled = topology_is_enabled();
>  	int new_mode;
>  	int rc;
> -	struct ctl_table ctl_entry = {
> +	const struct ctl_table ctl_entry = {
>  		.procname	= ctl->procname,
>  		.data		= &enabled,
>  		.maxlen		= sizeof(int),
> @@ -658,7 +658,7 @@ static int polarization_ctl_handler(const struct ctl_table *ctl, int write,
>  {
>  	int polarization;
>  	int rc;
> -	struct ctl_table ctl_entry = {
> +	const struct ctl_table ctl_entry = {
>  		.procname	= ctl->procname,
>  		.data		= &polarization,
>  		.maxlen		= sizeof(int),
> diff --git a/arch/s390/mm/cmm.c b/arch/s390/mm/cmm.c
> index 939e3bec2db7..8e354c90a3dd 100644
> --- a/arch/s390/mm/cmm.c
> +++ b/arch/s390/mm/cmm.c
> @@ -263,7 +263,7 @@ static int cmm_pages_handler(const struct ctl_table *ctl, int write,
>  			     void *buffer, size_t *lenp, loff_t *ppos)
>  {
>  	long nr = cmm_get_pages();
> -	struct ctl_table ctl_entry = {
> +	const struct ctl_table ctl_entry = {
>  		.procname	= ctl->procname,
>  		.data		= &nr,
>  		.maxlen		= sizeof(long),
> @@ -283,7 +283,7 @@ static int cmm_timed_pages_handler(const struct ctl_table *ctl, int write,
>  				   loff_t *ppos)
>  {
>  	long nr = cmm_get_timed_pages();
> -	struct ctl_table ctl_entry = {
> +	const struct ctl_table ctl_entry = {
>  		.procname	= ctl->procname,
>  		.data		= &nr,
>  		.maxlen		= sizeof(long),
> 
> 
> > Best regards,
> > -- 
> > Joel Granados <joel.granados@kernel.org>
> 
> Thanks!

-- 

Joel Granados


From xen-devel-bounces@lists.xenproject.org Wed Jan 22 12:42:02 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Jan 2025 12:42:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875928.1286326 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taa3N-0003MQ-O9; Wed, 22 Jan 2025 12:41:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875928.1286326; Wed, 22 Jan 2025 12:41:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taa3N-0003MJ-JJ; Wed, 22 Jan 2025 12:41:53 +0000
Received: by outflank-mailman (input) for mailman id 875928;
 Wed, 22 Jan 2025 12:41:52 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Cfnn=UO=kernel.org=ardb@srs-se1.protection.inumbo.net>)
 id 1taa3M-0003MB-Nj
 for xen-devel@lists.xenproject.org; Wed, 22 Jan 2025 12:41:52 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org
 [2604:1380:4641:c500::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3f706d4a-d8be-11ef-99a4-01e77a169b0f;
 Wed, 22 Jan 2025 13:41:50 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 248C25C5EA3
 for <xen-devel@lists.xenproject.org>; Wed, 22 Jan 2025 12:41:08 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 423C8C4CEE2
 for <xen-devel@lists.xenproject.org>; Wed, 22 Jan 2025 12:41:48 +0000 (UTC)
Received: by mail-lj1-f180.google.com with SMTP id
 38308e7fff4ca-30738a717ffso40026961fa.0
 for <xen-devel@lists.xenproject.org>; Wed, 22 Jan 2025 04:41:48 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 3f706d4a-d8be-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1737549708;
	bh=/nRt7/FOVju0HHPP7y/y/GmcikIqd0uun9LCjQjrq7E=;
	h=References:In-Reply-To:From:Date:Subject:To:Cc:From;
	b=VoyrM/KR3y6SyzXqcrUXIeXUzSXAukF1jTugO3Tp/XeZbDQsZz0btjWFVZexImUyA
	 GNv9Ye0JlCb6LXyPS9Jx9MVxR+Wdtkk0Ms+qZSrA1Lr8Xe+0i9vU/ISeGtF/6vb7Vs
	 1Uj3RovlFmNzqVfmuzQ82cCacT+Fx0ki2YqsVx1IY92F3iqqKCafCCMLWLqphwdRxg
	 srLeLPCzyALTJw1qCRW7tcb44xO01Rx4zDtdApARN9p2pthq2z1LppbizS751cMHo9
	 cZn++ylUYdHjeWMHwboi8qRzV/CerfY2kd1XCsOqWLze560AIlYM8svAXpyzid0N54
	 v69z43CGgr7bQ==
X-Forwarded-Encrypted: i=1; AJvYcCWG9349shETfNB8/2IB4+bG/Ffl4qnhYwL2NyI63dwEg7JiaXHUqjOdmsySZTR9lUF6qKRYzsgIbk8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwpbRwIIRIX6TthMOYjU0on1f7R+FF/2M9NU4Eq5nE7nAawTOVX
	Ni7kcglkPU7160lKx/oeOqAIAkQeKZyWNm73jHZncV2FRhbHH+wDofj6wIUbHwVCF/jGKpvcR9Q
	OHGUginZsvLxhpASol/51nxkQn/4=
X-Google-Smtp-Source: AGHT+IFcRSReB7hah7mapcirnp1PWu31SswN3BbR4HjBYPEG79Tzl030J0TjqkE7fYQS4xaDIi2/KgOUqh2J3fswv1A=
X-Received: by 2002:a05:651c:2228:b0:302:4130:e19c with SMTP id
 38308e7fff4ca-3072caa15c1mr71017091fa.19.1737549706586; Wed, 22 Jan 2025
 04:41:46 -0800 (PST)
MIME-Version: 1.0
References: <20250110-jag-ctl_table_const-v2-1-0000e1663144@kernel.org>
 <Z4+jwDBrZNRgu85S@li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com> <nslqrapp4v3rknjgtfk4cg64ha7rewrrg24aslo2e5jmxfwce5@t4chrpuk632k>
In-Reply-To: <nslqrapp4v3rknjgtfk4cg64ha7rewrrg24aslo2e5jmxfwce5@t4chrpuk632k>
From: Ard Biesheuvel <ardb@kernel.org>
Date: Wed, 22 Jan 2025 13:41:35 +0100
X-Gmail-Original-Message-ID: <CAMj1kXEZPe8zk7s67SADK9wVH3cfBup-sAZSC6_pJyng9QT7aw@mail.gmail.com>
X-Gm-Features: AbW1kvaDj3u8bGVj1m4rnYAkpiRSTpmPAB3bThAH-GyuG2Tmgw9okzkp1e58uCc
Message-ID: <CAMj1kXEZPe8zk7s67SADK9wVH3cfBup-sAZSC6_pJyng9QT7aw@mail.gmail.com>
Subject: Re: Re: [PATCH v2] treewide: const qualify ctl_tables where applicable
To: Joel Granados <joel.granados@kernel.org>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>, =?UTF-8?Q?Thomas_Wei=C3=9Fschuh?= <linux@weissschuh.net>, 
	Kees Cook <kees@kernel.org>, Luis Chamberlain <mcgrof@kernel.org>, 
	linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, 
	linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, 
	linux-s390@vger.kernel.org, linux-crypto@vger.kernel.org, 
	openipmi-developer@lists.sourceforge.net, intel-gfx@lists.freedesktop.org, 
	dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org, 
	linux-hyperv@vger.kernel.org, linux-rdma@vger.kernel.org, 
	linux-raid@vger.kernel.org, linux-scsi@vger.kernel.org, 
	linux-serial@vger.kernel.org, xen-devel@lists.xenproject.org, 
	linux-aio@kvack.org, linux-fsdevel@vger.kernel.org, netfs@lists.linux.dev, 
	codalist@coda.cs.cmu.edu, linux-mm@kvack.org, linux-nfs@vger.kernel.org, 
	ocfs2-devel@lists.linux.dev, fsverity@lists.linux.dev, 
	linux-xfs@vger.kernel.org, io-uring@vger.kernel.org, bpf@vger.kernel.org, 
	kexec@lists.infradead.org, linux-trace-kernel@vger.kernel.org, 
	linux-hardening@vger.kernel.org, apparmor@lists.ubuntu.com, 
	linux-security-module@vger.kernel.org, keyrings@vger.kernel.org, 
	Song Liu <song@kernel.org>, "Steven Rostedt (Google)" <rostedt@goodmis.org>, 
	"Martin K. Petersen" <martin.petersen@oracle.com>, "Darrick J. Wong" <djwong@kernel.org>, 
	Jani Nikula <jani.nikula@intel.com>, Corey Minyard <cminyard@mvista.com>
Content-Type: text/plain; charset="UTF-8"

On Wed, 22 Jan 2025 at 13:25, Joel Granados <joel.granados@kernel.org> wrote:
>
> On Tue, Jan 21, 2025 at 02:40:16PM +0100, Alexander Gordeev wrote:
> > On Fri, Jan 10, 2025 at 03:16:08PM +0100, Joel Granados wrote:
> >
> > Hi Joel,
> >
> > > Add the const qualifier to all the ctl_tables in the tree except for
> > > watchdog_hardlockup_sysctl, memory_allocation_profiling_sysctls,
> > > loadpin_sysctl_table and the ones calling register_net_sysctl (./net,
> > > drivers/inifiniband dirs). These are special cases as they use a
> > > registration function with a non-const qualified ctl_table argument or
> > > modify the arrays before passing them on to the registration function.
> > >
> > > Constifying ctl_table structs will prevent the modification of
> > > proc_handler function pointers as the arrays would reside in .rodata.
> > > This is made possible after commit 78eb4ea25cd5 ("sysctl: treewide:
> > > constify the ctl_table argument of proc_handlers") constified all the
> > > proc_handlers.
> >
> > I could identify at least these occurences in s390 code as well:
> Hey Alexander
>
> Thx for bringing these to my attention. I had completely missed them as
> the spatch only deals with ctl_tables outside functions.
>
> Short answer:
> These should not be included in the current patch because they are a
> different pattern from how sysctl tables are usually used. So I will not
> include them.
>
> With that said, I think it might be interesting to look closer at them
> as they seem to be complicating the proc_handler (I have to look at them
> closer).
>
> I see that they are defining a ctl_table struct within the functions and
> just using the data (from the incoming ctl_table) to forward things down
> to proc_do{u,}intvec_* functions. This is very odd and I have only seen
> it done in order to change the incoming ctl_table (which is not what is
> being done here).
>
> I will take a closer look after the merge window and circle back with
> more info. Might take me a while as I'm not very familiar with s390
> code; any additional information on why those are being used inside the
> functions would be helpfull.
>

Using const data on the stack is not as useful, because the stack is
always mapped writable.

Global data structures marked 'const' will be moved into an ELF
section that is typically mapped read-only in its entirely, and so the
data cannot be modified by writing to it directly. No such protection
is possible for the stack, and so the constness there is only enforced
at compile time.


From xen-devel-bounces@lists.xenproject.org Wed Jan 22 13:25:11 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Jan 2025 13:25:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875936.1286334 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taaj2-0000nk-N7; Wed, 22 Jan 2025 13:24:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875936.1286334; Wed, 22 Jan 2025 13:24:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taaj2-0000nd-Ke; Wed, 22 Jan 2025 13:24:56 +0000
Received: by outflank-mailman (input) for mailman id 875936;
 Wed, 22 Jan 2025 13:24: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 <SRS0=XwhO=UO=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1taaj0-0000nX-TG
 for xen-devel@lists.xenproject.org; Wed, 22 Jan 2025 13:24:54 +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 434b4d4d-d8c4-11ef-99a4-01e77a169b0f;
 Wed, 22 Jan 2025 14:24:52 +0100 (CET)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-43618283d48so49688435e9.1
 for <xen-devel@lists.xenproject.org>; Wed, 22 Jan 2025 05:24: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
 5b1f17b1804b1-438b31c7cc6sm23992475e9.36.2025.01.22.05.24.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 22 Jan 2025 05:24:51 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 434b4d4d-d8c4-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737552292; x=1738157092; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=FDGUomymv0ZsBpuAUt98T1Sxt8+05TXqMxs65cdngOE=;
        b=KhuHYOBZDaakfBRPm38eChnYqRL/kYBhuMkzDgsh9y2GoC8gzsOdai2uMP9PRGqljz
         5eBX8tFjsTsVU8pXEoP0pUBgrV1j3VJFDvhI7R5GtpwZhsS3P1xodchrgqBgEwFkkteD
         r4L34Cevys+mHgcboVgumS6owaW3YZHAGQ8yHx0gHpKv8pJhjAKORffKQwn5gJiqcKnu
         VyK1q+VWRz2iT1P32/9Zu5g/iMUJ0F38RgZmSCpwTcTGt/UUt45ggiTiBBX5rwkYWVUY
         E5vEziN2mj0Go39epsGsO5ShiEEe52YEZUy29ai87wjWPGXaAhRwJEEgiUgfeE1aDSo3
         L+uw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737552292; x=1738157092;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=FDGUomymv0ZsBpuAUt98T1Sxt8+05TXqMxs65cdngOE=;
        b=X+nUKYfTMek8FVFPGRtY4XZhnWqLEf+CapTN9Qy+EHyKYBHBg6KfH40z+ITQTxdXds
         mCqRShzw9uW1xM1pswRgFzA03ZOvEva/VrEV6DM6aeRBJ/jGIzHXx0vAIc8rAxErYmLh
         6lIXrjsLw1L2lqBIVwYc+0cPwBILTQmUSO3jSvGNkT+IGSL5UVd+AfmyxbKz/pK2afHE
         y+VJKPqvbOjT2ygcakix5p1Izs9bfB5z1cB7S2ikPiJ88RcYtpzTs/BLx/uTSeGgvdeP
         hdc+tFLOOML+1xV51IelP75wK+09pxzkJ/FTrZmZhOW43PNmZ2NvIUCyigXiOSB5m+2Q
         cbfw==
X-Forwarded-Encrypted: i=1; AJvYcCUKJmb3BXXXe7LewRcy2j5xhPb0dPsDpLrGOoXMR29L0RTmCOaPHJlZIOcjQ7GZXWz/AmGvFhfePqw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzF7RXeYJWgVGeJ5GxeQ8xonVVYE89Y4JK4hFNPKdoXSIglJFut
	9Z7Hi/ZN/DUyF3yt4VgVRQ+FT6UrqOupQIqBqFZnNAaw32fJOpv8Wf8LTQ9v7Q==
X-Gm-Gg: ASbGncs3A5xKpdxspb7ZovajThrLuh2zLTiuzk19wF1acZrx4w85H+RyZppZ9/dJA6K
	fh/U56EDFP+jRnbJT5/wgljYYBIDqU9RHpxWGpq3BoP/eR1vqbhLEmVQQoLG1EQ8Gpe3d6kekB3
	MnXv3wr1+WYXRkAFu6J+9VqaYxc5xf/EbgAbr8JFPRUqpqkzZtQTzqv0OOus2++6FCPKOW/e1vm
	snBh4/3Nyiwc9eZx9HpklXyHYPdeooXCwdynyQtwWh/0pk3nz7E2VYQsewPa3TKGHC+DgqQ+iGx
	uyjnqzO3nRMuzOKSH3XP/FRTnYASrKrqlxj9K9p4KWU/F0TjE/knP2s=
X-Google-Smtp-Source: AGHT+IETt8CWXd/G5aN79XuQv4Xb4nBUtlYxqiY9w5Jo06azZJf4F06hdUpWzgCrpTLtAEWpv3YI9w==
X-Received: by 2002:a05:600c:138a:b0:435:194:3cdf with SMTP id 5b1f17b1804b1-438914292demr191783615e9.19.1737552292084;
        Wed, 22 Jan 2025 05:24:52 -0800 (PST)
Message-ID: <6c0ebe4b-fc47-4bb0-b317-f854abb63517@suse.com>
Date: Wed, 22 Jan 2025 14:24:50 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/4] x86: provide an inverted Kconfig control for
 shim-exclusive mode
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Alejandro Vallejo <alejandro.vallejo@cloud.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Julien Grall <julien@xen.org>, Wei Liu <wl@xen.org>, sergiy_kibrik@epam.com
References: <6285f86d-f2d2-4040-999d-01aed3e72a36@suse.com>
 <alpine.DEB.2.22.394.2501171430570.2684657@ubuntu-linux-20-04-desktop>
 <f8c1e2c2-ceb5-4200-a304-e2d824a171a8@citrix.com>
 <40c9d806-000d-43e7-a804-ad4e84209b2f@suse.com>
 <alpine.DEB.2.22.394.2501201527090.11086@ubuntu-linux-20-04-desktop>
 <bae48627-fa5b-48b6-b74e-267285175eff@suse.com>
 <Z49gQBkxCbXIO84D@macbook.local>
 <41859184-bd9c-420f-96c1-65abe379b81e@suse.com>
 <Z4_hOmi01AkiYH_k@macbook.local>
 <c897005a-2e8e-4031-a828-acb8128f7c0c@suse.com>
 <Z5C_EJEtorK2pwGE@macbook.local>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <Z5C_EJEtorK2pwGE@macbook.local>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 22.01.2025 10:49, Roger Pau Monné wrote:
> On Wed, Jan 22, 2025 at 09:43:53AM +0100, Jan Beulich wrote:
>> On 21.01.2025 19:02, Roger Pau Monné wrote:
>>> On Tue, Jan 21, 2025 at 11:35:42AM +0100, Jan Beulich wrote:
>>>> On 21.01.2025 09:52, Roger Pau Monné wrote:
>>>>> On Tue, Jan 21, 2025 at 09:13:38AM +0100, Jan Beulich wrote:
>>>>>> On 21.01.2025 00:27, Stefano Stabellini wrote:
>>>>>>> If I understood it right, I like Andrew's suggestion. He is suggesting
>>>>>>> to do the following:
>>>>>>>
>>>>>>> - turning PV_SHIM_EXCLUSIVE into something that does nothing
>>>>>>
>>>>>> FTAOD - you mean Kconfig-wise? Andrew clearly didn't say "nothing", but
>>>>>> "nothing other than making the boolean be a compile time constant".
>>>>>
>>>>> Won't making the boolean a compile time constant would also result in
>>>>> DCO kicking in and removing a fair amount of code?  So even if you
>>>>> have enabled everything in Kconfig, the resulting hypervisor would
>>>>> only be suitable to be used as a shim?
>>>>
>>>> Of course.
>>>
>>> Then what's the point of this approach?  Options will be enabled in
>>> Kconfig, but the resulting hypervisor build when using allyesconfig
>>> would have a lot of them short-circuited, making it even worse than
>>> currently?  As options will get effectively build-time disabled due
>>> to DCO while enabled in Kconfig.
>>
>> Well, I have to direct this question to Andrew. It is specifically
>> what I'm trying to address with UNCONSTRAINED.
>>
>>> Overall I think PV_SHIM_EXCLUSIVE should be excluded from
>>> allyesconfig, even with Andrew's proposed change.  Otherwise the
>>> purpose of allyesconfig is defeated if enabling PV_SHIM_EXCLUSIVE
>>> makes the resulting hypervisor build PV shim only.  IIRC we can
>>> provide a default alllyes.config with CONFIG_PV_SHIM_EXCLUSIVE=n.
>>
>> Hmm, I wasn't aware of the option of using allyes.config. That might be
>> the route to go, albeit it looks like people using the allyesconfig
>> target then need to remember to set KCONFIG_ALLCONFIG in the environment
>> (to <empty> or 1), or to explicitly specify a file name that way. (This
>> of course ought to be easy enough to arrange for in our automation.)
> 
> My knowledge of Kconfig is very limited, but isn't there a default
> path for such file to be picked up by Kconfig?  I see we already have
> a xen/tools/kconfig/allrandom.config, I was expecting it would be a
> matter of dropping an allyes.config in that directory, but I haven't
> tried.

Well, I simply looked at the kconfig sources, and my reading of it is
that it won't even try to open allyes.config when the envvar is absent.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jan 22 13:29:30 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Jan 2025 13:29:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875947.1286344 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taanR-0001RD-Bc; Wed, 22 Jan 2025 13:29:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875947.1286344; Wed, 22 Jan 2025 13:29:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taanR-0001R6-8o; Wed, 22 Jan 2025 13:29:29 +0000
Received: by outflank-mailman (input) for mailman id 875947;
 Wed, 22 Jan 2025 13:29:27 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=XwhO=UO=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1taanP-0001Qy-K8
 for xen-devel@lists.xenproject.org; Wed, 22 Jan 2025 13:29:27 +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 e699612c-d8c4-11ef-a0e5-8be0dac302b0;
 Wed, 22 Jan 2025 14:29:26 +0100 (CET)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-385e27c75f4so5721873f8f.2
 for <xen-devel@lists.xenproject.org>; Wed, 22 Jan 2025 05:29:26 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38bf327e19fsm16691124f8f.93.2025.01.22.05.29.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 22 Jan 2025 05:29:25 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e699612c-d8c4-11ef-a0e5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737552566; x=1738157366; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=bZidTBZU8G0XrlYEVd9UJVLcI4BEzSu2qbiRpOHgj7U=;
        b=Txk19CrBEWfs++qu6PZefwSdSNC2YpxvmWoyHA4m9873OZaIx8WdAo9BIR0+GbT7GD
         cPqYJFNu/XG3V9iI5eN01jdyTlKmiX3MYM5qt6tGavzxZZ8svIpCsTaBLArt6ut6V+oS
         E/F5NMHfehE7bxr/D72uAYkV1ONlHvvPEtYH2Fz5HTPQ3OJ1peTwkO7K8wgIgOj7lEma
         WeBVySdnQIFFeHkOeIt2E0/4tJK6UbDNiTo7DpAiN0zgICf1Yb3uwnQSzVnhVbrtpDJo
         mGmBRDVOkMI0sKyJ64Qvjr1tPjFepcZ7gKVGHkImGzJ+bjpcJTMSBPps4nx+cj/eR9T3
         YTeA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737552566; x=1738157366;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=bZidTBZU8G0XrlYEVd9UJVLcI4BEzSu2qbiRpOHgj7U=;
        b=f9IJzBDf4xyLuaEzMeSiiB5YBfQY/omnXVoNWuz3ygfwKQz9dWw6iFEi6NQMy+i5wM
         uN6L3kWg+24Zj8g1NL84d4JTIF1xOF6QOfXFVKWU9AQoWt4MSoB2mpPWe4HJBTYoVNY4
         bW1iTD66BLLSgarTV5mcmMey5ei/ELfUI10ZH3bSq05lvJJZQTmxTUY2bmt/JSNlZSN9
         BtNn8t2A97rAjSAjLiMS9g2Dff8Ck4idPO/IYlgpgdMusiPzn67bVS3X3ZRIigfiNZ9j
         xDXoI7Q+hAY2nqSMhEKGtEB9o13CLrS6LWijpv/qxVFj4w/wETvg0TXKuyEKR170WUzW
         NG0w==
X-Gm-Message-State: AOJu0Yw35XdAdeyCvb2CFhbzywxs/KeY7wXwI+M+iNY6XjADPmD7eGyh
	rsIjW7PxrtNu+WvlFDHIaq+D8oU721fn0aUsMPys6Rh8R6GxOIdm3qqukl+4xWKuxbYW8kCzJXk
	=
X-Gm-Gg: ASbGnct4ZbML+3Flgm04XZwJQtyN2lVQiSeW1kkyx/o+t2ftQX9iulKoiwk7qXClcaR
	2iYWBar0YXc71pXrZBZGEbA4QXRoUxkPiFNIzfmNrOkmmLzr6V6fmn59eUZzLhnBuajRpSc71Rc
	pkflOtgngIijAUCaakJhIRyPQ7DMmFzqIXQ4q1ACwRGvCRxH/PbkVLjH9o1uvAEdu2w7dq3b1xb
	KrAQHTdezmkdGM/cmcMIQ32dACVC3IB2UdrLtEiKhByQnd9GgfArYQz0A2bSHQzubOXqoZvQ7Fr
	2iQUWBaAO0iWpIYccjRV4j/fstibeAQQMJbIljA2PM708AkZofWR0ps=
X-Google-Smtp-Source: AGHT+IGtdiiTBfcSWw/hEj+lngLNZdJ567IYrB9FkzcsF+IgDygSe3xSLKaiJ6te3CPFk6KVC0Ra1Q==
X-Received: by 2002:a05:6000:1ace:b0:386:1cd3:8a07 with SMTP id ffacd0b85a97d-38bf5678239mr18260014f8f.7.1737552566141;
        Wed, 22 Jan 2025 05:29:26 -0800 (PST)
Message-ID: <24885d31-e536-4ff4-8457-300c9a028701@suse.com>
Date: Wed, 22 Jan 2025 14:29:25 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] x86emul: further correct 64-bit mode zero count
 repeated string insn handling
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <2e81cf29-65fd-74fc-db4f-95c453acc327@suse.com>
 <Z5DHOknjrhMoAGz6@macbook.local>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <Z5DHOknjrhMoAGz6@macbook.local>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 22.01.2025 11:23, Roger Pau Monné wrote:
> On Fri, Aug 04, 2023 at 07:58:21AM +0200, Jan Beulich wrote:
>> In an entirely different context I came across Linux commit 428e3d08574b
>> ("KVM: x86: Fix zero iterations REP-string"), which points out that
>> we're still doing things wrong: For one, there's no zero-extension at
>> all on AMD. And then while RCX is zero-extended from 32 bits uniformly
>> for all string instructions on newer hardware, RSI/RDI are only for MOVS
>> and STOS on the systems I have access to. (On an old family 0xf system
>> I've further found that for REP LODS even RCX is not zero-extended.)
>>
>> Fixes: 79e996a89f69 ("x86emul: correct 64-bit mode repeated string insn handling with zero count")
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Acked-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks. I'm uncertain though whether with concerns Andrew had voiced (maybe
just on irc/Matrix) I may go ahead and commit this. Andrew?

In any event - Oleksii, I guess I'd need a release ack here (or an indication
to defer to 4.21).

>> ---
>> Partly RFC for none of this being documented anywhere (and it partly
>> being model specific); inquiry pending.
> 
> Did you get any reply on this?

No, and to be honest I also didn't have much hope I would get any reply.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jan 22 13:39:54 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Jan 2025 13:39:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875958.1286355 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taaxR-0003NR-7e; Wed, 22 Jan 2025 13:39:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875958.1286355; Wed, 22 Jan 2025 13:39:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taaxR-0003NK-4w; Wed, 22 Jan 2025 13:39:49 +0000
Received: by outflank-mailman (input) for mailman id 875958;
 Wed, 22 Jan 2025 13:39: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 <SRS0=XwhO=UO=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1taaxQ-0003NE-7u
 for xen-devel@lists.xenproject.org; Wed, 22 Jan 2025 13:39:48 +0000
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com
 [2a00:1450:4864:20::42f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 57d31ec6-d8c6-11ef-99a4-01e77a169b0f;
 Wed, 22 Jan 2025 14:39:46 +0100 (CET)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-385df53e559so5239090f8f.3
 for <xen-devel@lists.xenproject.org>; Wed, 22 Jan 2025 05:39: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
 5b1f17b1804b1-438b31898ebsm24953605e9.2.2025.01.22.05.39.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 22 Jan 2025 05:39:45 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 57d31ec6-d8c6-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737553185; x=1738157985; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=v95tgaJmKqaerP+y0ayp/BZjOw5ZF5qeHKhaytqL1x8=;
        b=fa8NY9Wye4FvWI4CFuUEDhhcP1bAlMtL8zz/JOo3NCcfvoGdeLQIkgAL1M2EgPhXqE
         iOFPpj7M5oWpjIDOBJaxWnEWaqA737VdMshXvDg02mtfIueU+9u23qp5KxfOXIgSblYf
         FEQATuNtqvDIvgEtN/PSYfVAlu03DIlSXiRQ6D40o1ADm3RsNY6UrcIyGeTUxYxUWqPX
         zrHEHmMspmdDH/hf2OqTGM1YjCR01SZnQnHFSHjXUesAi2ke1hxukc471d3NPP/dHUlD
         NRHXwlk+NkK6H/AIXOSwJMjWo1+x+SGVXBg4UTPqkwHoJwBmOMSDJnHIq0B+Rzq/Nfrm
         MMEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737553185; x=1738157985;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=v95tgaJmKqaerP+y0ayp/BZjOw5ZF5qeHKhaytqL1x8=;
        b=GmUJO3wV/IqGHyzUy0UxG8EErFT7zQSXLar4N9f8PwLKNfCY/zHp7w3yJd7xR5gORw
         59lJprcKBcuio8NQVlk71KUpIoQgbIfECU3vuBVBanQDOE9BsJn4TBrKIVWj2MVzmnZw
         1Ml+5EUgWyFxNcWU0CbS0Y0uFZz3e5+6mIFQYj48fW/0MJecbhHNSGC02xjSFxtE0Bq1
         GkqdKH6pkP7mzFIszujW98gkE4Rd/vcfUClgu0nfSHqel6L1bJUa73Vcav4vI/pnRwbx
         m6PnQyomh9oTyZBf/m3zA1rQSLUbJS6T291vO7WlZBenpteSBv2K7AJ/VE7WXmwHeJHa
         3fuw==
X-Gm-Message-State: AOJu0YzjzY23NSeOMcBCQapgr9wY4A6Ix++6wDPtV+3EJbU78RiDK9oz
	o5Y3y5LWQIyRDdq83wFJqdOTYcUfHbydaDHtN4dkvQShfgP4DckT5wBSreawHQ==
X-Gm-Gg: ASbGncvd1oAwdXKreiTTysFNkVlBZDTtD6BqOmbIY6ehPdaYkrn9dZ8Oj4XDsYwjs36
	aa8G7BfnX11dchAkmG527+VfZztq5aQw8WjKpvBcvcuU9pbIyUP3BmNmw5Gmx8/bh4NCtWWLqe8
	dVMToFX8lqISelIpByuXQFcLLtpoGYd8+tv0BihGTDzaUYXY0ftVnDbJRVVUwJ0Rs1wPx1OwNwL
	B+mXSDl7x18GFGvG7KWkq2/hTRIN7KegVfprHKfSnrAeb6GMrhfLRKHLy1whIbwIlMh1BoYLGOp
	3uWs5TnhbPWMSBj2ZEpxVmEsId10nbXFmP1KMN0nROfnW0ywKnvZEAo=
X-Google-Smtp-Source: AGHT+IGK23Ry5+z/NqYZmgYaPVVCHAkS4RFBrRqq+UU7Oy2qOkbUvSRtlFBCFu8Z7LBD0EcRz3eIiQ==
X-Received: by 2002:a5d:6c68:0:b0:38b:ed7b:f791 with SMTP id ffacd0b85a97d-38bf5655caamr18227966f8f.5.1737553185517;
        Wed, 22 Jan 2025 05:39:45 -0800 (PST)
Message-ID: <de1934b8-b7c9-472f-9b9e-5183a5a34b65@suse.com>
Date: Wed, 22 Jan 2025 14:39:43 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/5] x86/HVM: allocate emulation cache entries
 dynamically
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
References: <3294f629-f91f-4b5d-9eb0-40a34aa2ec3e@suse.com>
 <93967ab8-a472-475a-bdd6-41dfc3afa895@suse.com>
 <Z5Ddzh-Ygy5cGuPj@macbook.local>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <Z5Ddzh-Ygy5cGuPj@macbook.local>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 22.01.2025 13:00, Roger Pau Monné wrote:
> On Tue, Oct 01, 2024 at 10:49:10AM +0200, Jan Beulich wrote:
>> Both caches may need higher capacity, and the upper bound will need to
>> be determined dynamically based on CPUID policy (for AMX'es TILELOAD /
>> TILESTORE at least).
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Just a couple of comments below.
> 
>> ---
>> This is a patch taken from the AMX series, but wasn't part of the v3
>> submission. All I did is strip out the actual AMX bits (from
>> hvmemul_cache_init()), plus of course change the description. As a
>> result some local variables there may look unnecessary, but this way
>> it's going to be less churn when the AMX bits are added. The next patch
>> pretty strongly depends on the changed approach (contextually, not so
>> much functionally), and I'd really like to avoid rebasing that one ahead
>> of this one, and then this one on top of that.
> 
> Oh, I was just going to ask about the weirdness of nents compared to
> what was previously.

And then you did ask; I'll comment on that below.

>> --- a/xen/arch/x86/hvm/emulate.c
>> +++ b/xen/arch/x86/hvm/emulate.c
>> @@ -26,6 +26,18 @@
>>  #include <asm/iocap.h>
>>  #include <asm/vm_event.h>
>>  
>> +/*
>> + * We may read or write up to m512 or up to a tile row as a number of
>> + * device-model transactions.
>> + */
>> +struct hvm_mmio_cache {
>> +    unsigned long gla;
>> +    unsigned int size;
>> +    unsigned int space:31;
> 
> Having size and space is kind of confusing, would you mind adding a
> comment that size is the runtime consumed buffer space, while space is
> the total allocated buffer size (and hence not supposed to change
> during usage)?

Sure; I thought the two names would be clear enough when sitting side by
side, but here you go:

    unsigned int size;     /* Amount of buffer[] actually used. */
    unsigned int space:31; /* Allocated size of buffer[]. */


>> @@ -2978,16 +2991,21 @@ void hvm_dump_emulation_state(const char
>>  int hvmemul_cache_init(struct vcpu *v)
>>  {
>>      /*
>> -     * No insn can access more than 16 independent linear addresses (AVX512F
>> -     * scatters/gathers being the worst). Each such linear range can span a
>> -     * page boundary, i.e. may require two page walks. Account for each insn
>> -     * byte individually, for simplicity.
>> +     * AVX512F scatter/gather insns can access up to 16 independent linear
>> +     * addresses, up to 8 bytes size. Each such linear range can span a page
>> +     * boundary, i.e. may require two page walks.
>> +     */
>> +    unsigned int nents = 16 * 2 * (CONFIG_PAGING_LEVELS + 1);
>> +    unsigned int i, max_bytes = 64;
>> +    struct hvmemul_cache *cache;
>> +
>> +    /*
>> +     * Account for each insn byte individually, both for simplicity and to
>> +     * leave some slack space.
>>       */
>> -    const unsigned int nents = (CONFIG_PAGING_LEVELS + 1) *
>> -                               (MAX_INST_LEN + 16 * 2);
>> -    struct hvmemul_cache *cache = xmalloc_flex_struct(struct hvmemul_cache,
>> -                                                      ents, nents);
>> +    nents += MAX_INST_LEN * (CONFIG_PAGING_LEVELS + 1);
>>  
>> +    cache = xvmalloc_flex_struct(struct hvmemul_cache, ents, nents);
> 
> Change here seems completely unrelated, but I guess this is what you
> refer to in the post-commit remark.  IOW: the split of the nents
> variable setup, plus the change of xmalloc_flex_struct() ->
> xvmalloc_flex_struct() don't seem to be related to the change at
> hand.

See the post-commit-message remark that you commented on. To repeat:
It'll be quite a bit easier for me if the seemingly unrelated adjustments
could be kept like that. Unless of course there's something wrong with
them.

>> @@ -2997,6 +3015,15 @@ int hvmemul_cache_init(struct vcpu *v)
>>  
>>      v->arch.hvm.hvm_io.cache = cache;
>>  
>> +    for ( i = 0; i < ARRAY_SIZE(v->arch.hvm.hvm_io.mmio_cache); ++i )
>> +    {
>> +        v->arch.hvm.hvm_io.mmio_cache[i] =
>> +            xmalloc_flex_struct(struct hvm_mmio_cache, buffer, max_bytes);
> 
> TBH I would be tempted to just use xvmalloc here also, even if the
> structure is never going to be > PAGE_SIZE, it's more consistent IMO.

Oh, absolutely under the current rules (which weren't in effect yet back
when all of this was written).

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jan 22 15:03:46 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Jan 2025 15:03:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875970.1286365 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tacGN-00078H-Ui; Wed, 22 Jan 2025 15:03:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875970.1286365; Wed, 22 Jan 2025 15:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tacGN-00078A-QX; Wed, 22 Jan 2025 15:03:27 +0000
Received: by outflank-mailman (input) for mailman id 875970;
 Wed, 22 Jan 2025 15:03:26 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=9MVI=UO=suse.com=jgross@srs-se1.protection.inumbo.net>)
 id 1tacGM-00076j-TI
 for xen-devel@lists.xenproject.org; Wed, 22 Jan 2025 15:03:26 +0000
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com
 [2a00:1450:4864:20::331])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 07018572-d8d2-11ef-99a4-01e77a169b0f;
 Wed, 22 Jan 2025 16:03:24 +0100 (CET)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-436a03197b2so49402945e9.2
 for <xen-devel@lists.xenproject.org>; Wed, 22 Jan 2025 07:03:24 -0800 (PST)
Received: from ?IPV6:2003:e5:8731:2800:842d:42a0:5992:3595?
 (p200300e587312800842d42a059923595.dip0.t-ipconnect.de.
 [2003:e5:8731:2800:842d:42a0:5992:3595])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438b31df435sm28182715e9.34.2025.01.22.07.03.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 22 Jan 2025 07:03:23 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 07018572-d8d2-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737558204; x=1738163004; darn=lists.xenproject.org;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=vTL8udFqGBx4YIc5Ep+FMre3MWyydR+dtNFDFm0ET+o=;
        b=MFiqgEu9gxCAVtHTvxldymkibGcQzbWvdE2IUzxuKk/xKOZiCrnQJws/ImPAbLvjRm
         6WTNlldVXxx7HJqleGqfP7fGlD8/XWZjuldOofwnQC1cRMDLejb4duoWYlY4ZgOYJFpU
         rw4KD/spTDytrJt3PlZReUES8IMsVL8PVGgLrmyx+I1glq6B5kaPRO3fomxVrwlNZyTY
         3/iSVpEYqOPRCSEOrIJcf+rK/yde+iQqXD6QqLKdmG6T/H4XdPFGRXDrkCdfw8hp0ARV
         MgAihhWpT+YVtDLgaDybOlOjos53x/m9Ouui5gS2RaiIcZS5i+r3SucIGGTv/pNhHYbd
         dSkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737558204; x=1738163004;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=vTL8udFqGBx4YIc5Ep+FMre3MWyydR+dtNFDFm0ET+o=;
        b=ATld03R3wCJtAOK1LrQpxbQ6e8UuWvLyLHSUzTxuY7mlqZsPeSNlQjLY309p3piIz+
         ooJemfxBTGZQVp+dOvX1STk3+UF35xFcE5o1cs9yYeqQXQaQgsOvNywQpf6/vwPtAtpV
         NkJQR6ftvBBGuh0pqVUAS6jwGCxC2uHSYvAKEsw0T2beRv2NJDhxtz8OsfXe4K3nmmD2
         IQGkIYk/s9sLEInI/yU+aO/pLZyRO8V0MPzlfushsIKbDVETuun41UEgk9I106aGbanF
         P+LecsWqmmMbZR0zWUMmFN5Ch92trDMhipVpUtOVtNvC5vesb26hkY56L33ytMFHN3qv
         zdMQ==
X-Gm-Message-State: AOJu0Yw4npwL/bYbOw+zx7v5neBWtNyYVbvd1gPP/r22hyfI/lNDsdAP
	x89RwEiJigSR/wdlsLk/vbLspvB0/sCMhtc5RLbNGiekPflGuCpajN5r/DFp6kHmIc4WQ2/vJUH
	J
X-Gm-Gg: ASbGnctZATFUWVGS86sX8EcZ3wkRGBdVBFdrmx39rO/te2ds9SgA0p8F3tO63rwvZOp
	pjAstfCMeVd+vJQEhc62FRrCJ36yIHDzn0gOhowBM2k3z27/yUlqBVgxKZJHhzb6mX14goIG00J
	cWR6rzUZWYeNTXuils8m9zI4s6UvY/tift7CVnAAwgE8GHfvc0ELkjsrspPp9krdXrjh8l5xCQI
	AdJJ5aE/o2EBV13WX5lgPjRdRSQRGW3vsqFJiVsSYLHyGBxUN83aiDyFPpefPMjK7+YHN2QkWdJ
	agXtuqdAL3AFXZD0GBX8R3/pO9JjWoO3q+QWToaVHnIPTmOBsT/yVKLzTCF9sJD9zKCzTz277p1
	zy3ZxWWZM4cXFusRFZOk=
X-Google-Smtp-Source: AGHT+IFy5RHBkSlwbCzQdFRULzUwfs+Aiu+iXQxJQOG8oZfIKbMhOeDVwCZdgwXuTZiwAxUrcwSkyg==
X-Received: by 2002:a05:600c:1d07:b0:436:488f:50a with SMTP id 5b1f17b1804b1-438913ef4b7mr212245035e9.17.1737558203658;
        Wed, 22 Jan 2025 07:03:23 -0800 (PST)
Message-ID: <afb9d7e2-1aa9-482b-ad97-83585ea6f3d6@suse.com>
Date: Wed, 22 Jan 2025 16:03:22 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4] xen: update pvcalls_front_accept prototype
To: Stefano Stabellini <sstabellini@kernel.org>, linux-kernel@vger.kernel.org
Cc: xen-devel@lists.xenproject.org, jbeulich@suse.com
References: <alpine.DEB.2.22.394.2501201537560.11086@ubuntu-linux-20-04-desktop>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <alpine.DEB.2.22.394.2501201537560.11086@ubuntu-linux-20-04-desktop>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------m0dny2jJEL3aKdlv0ZZH0Wbs"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------m0dny2jJEL3aKdlv0ZZH0Wbs
Content-Type: multipart/mixed; boundary="------------ejjV6YF1QTjbOOKheX0SCOeP";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: Stefano Stabellini <sstabellini@kernel.org>, linux-kernel@vger.kernel.org
Cc: xen-devel@lists.xenproject.org, jbeulich@suse.com
Message-ID: <afb9d7e2-1aa9-482b-ad97-83585ea6f3d6@suse.com>
Subject: Re: [PATCH v4] xen: update pvcalls_front_accept prototype
References: <alpine.DEB.2.22.394.2501201537560.11086@ubuntu-linux-20-04-desktop>
In-Reply-To: <alpine.DEB.2.22.394.2501201537560.11086@ubuntu-linux-20-04-desktop>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------ejjV6YF1QTjbOOKheX0SCOeP
Content-Type: multipart/mixed; boundary="------------MZUhi2rg4UdWatbbSws24Zyx"

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

T24gMjEuMDEuMjUgMDA6MzgsIFN0ZWZhbm8gU3RhYmVsbGluaSB3cm90ZToNCj4gV2hpbGUg
Y3VycmVudGx5IHRoZXJlIGFyZSBubyBpbi10cmVlIGNhbGxlcnMgb2YgdGhlc2UgZnVuY3Rp
b25zLCBpdCBpcw0KPiBiZXN0IHRvIGtlZXAgdGhlbSB1cC10by1kYXRlIHdpdGggdGhlIGxh
dGVzdCBuZXR3b3JrIEFQSS4NCj4gDQo+IEluIGFkZGl0aW9uLCBhZGQgdGhlIG1pc3Npbmcg
RVhQT1JUX1NZTUJPTF9HUEwgdG8gdGhlIGZ1bmN0aW9ucyBsaXN0ZWQNCj4gaW4gcHZjYWxs
cy1mcm9udC5oLg0KPiANCj4gU2lnbmVkLW9mZi1ieTogU3RlZmFubyBTdGFiZWxsaW5pIDxz
dGVmYW5vLnN0YWJlbGxpbmlAYW1kLmNvbT4NCg0KUmV2aWV3ZWQtYnk6IEp1ZXJnZW4gR3Jv
c3MgPGpncm9zc0BzdXNlLmNvbT4NCg0KDQpKdWVyZ2VuDQo=
--------------MZUhi2rg4UdWatbbSws24Zyx
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

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

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

--------------MZUhi2rg4UdWatbbSws24Zyx--

--------------ejjV6YF1QTjbOOKheX0SCOeP--

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

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

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmeRCLoFAwAAAAAACgkQsN6d1ii/Ey+m
Lgf/eLDnoy5SfqCIOB3O7V82yNGoJ52AQw2CT8q65iH8JqOW+uwLL9e9xo+9/miF34Kb1S4fDgWK
7gwTeqhvU37aMJywTWtDA+fyVWS5Su6a6tR7/7z9osBXZvGgFKN/OhDdhB7vsLIs7BgT4QFYa2eA
US739Thy1ko8XN0+OCCEDtdqJ092aOtrDWUFUbc1ze/XzaOj+dQkP6rFv1F6SyaQVDXxxRxxW/1/
RjrW8dVqQHR7OjnZz/cTGyGYEtsEbBWqmaxF/ARBLr2Lenia/bPAGvFpPsBhKS2xGi0mdezH0rjy
auKJGW0cGxcvl9DzAhXTIRpQefa3wM4UWSxjSTiscw==
=iedn
-----END PGP SIGNATURE-----

--------------m0dny2jJEL3aKdlv0ZZH0Wbs--


From xen-devel-bounces@lists.xenproject.org Wed Jan 22 16:01:58 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Jan 2025 16:01:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.875985.1286374 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tadAu-00070d-49; Wed, 22 Jan 2025 16:01:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 875985.1286374; Wed, 22 Jan 2025 16:01:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tadAu-00070W-1H; Wed, 22 Jan 2025 16:01:52 +0000
Received: by outflank-mailman (input) for mailman id 875985;
 Wed, 22 Jan 2025 16:01: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
 <SRS0=32Vc=UO=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tadAs-00070L-4o
 for xen-devel@lists.xenproject.org; Wed, 22 Jan 2025 16:01:50 +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 2fed3085-d8da-11ef-a0e5-8be0dac302b0;
 Wed, 22 Jan 2025 17:01:49 +0100 (CET)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-5d7e3f1fc01so14384484a12.2
 for <xen-devel@lists.xenproject.org>; Wed, 22 Jan 2025 08:01:49 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5db73edbaffsm8826378a12.66.2025.01.22.08.01.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 22 Jan 2025 08:01:46 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2fed3085-d8da-11ef-a0e5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1737561708; x=1738166508; darn=lists.xenproject.org;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=8uR6wsqFlwBpyRXiy4j2Zc9iFSAkkHWXDs0GCAz7Ziw=;
        b=GPblWV455scQKyIAysOkegXvY/Qy4Ect/oAxkzLlJrXdeyCjFAqBs13vco+J7Q4Hgs
         Y/O8n0LmIlWLEF/sPDxNWAxbMmhM8XgP/U+BVpSRtnPRy8kU0ldb3j5ob+elTZlXsIeq
         JkypPUcbRcQnpmDdIaEA6MYWzWMPJIXIM19YheUgrkoSvpoa82FIKuEvuxGsz3XfwFLY
         ZziiGcnw0927v85ZEohagq45PhSWTpPNIGwf6AWF8vHHUCHaD96NG8L8fwbAgSenXdku
         lKz4RAyzKxUcmHYIoDebJYjzBR8EkpXk+mNmpj8hpcNwfi8i5+ZgWS35TAaYEnAfObTt
         QN8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737561708; x=1738166508;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=8uR6wsqFlwBpyRXiy4j2Zc9iFSAkkHWXDs0GCAz7Ziw=;
        b=hRW9KgqxnHVqrdyOAnMrsvHUl8j8GO+iwReL86cLTXc7OnFuLtk9EHys5IXNji+x9I
         0MRyoJW4uTQ/2SlrLkcC5t8cc0CA36mE+xhoyhxX6oIf8u4uWofb9X4p5GAYKN4rSN0c
         78PIGVDZeZVqNdEiF/Csw1m7Fa7Vywk3+QblIGPWLR5EC/B6CItc1Vqwkm2XSBe9Qvdn
         1SrjcjmWTElJBpe8uuxt6ImC/zD6ReFIqq6H9ILoi2e8udYy+p5IIkWqbx6TGapIGoHV
         g2xleZRYu7VBgYPJQ2V3QSoh2TwD2IVofopShWZi/Tw67IJ3G7BsouS6lx7rgNexjiEH
         juqQ==
X-Gm-Message-State: AOJu0YzUl35L27k0wmcsd7A/ohP4kP/AjOKXz/8NP2Cuosl1q1LSxuSC
	nW580Jc3xzwSPOg9aSSW8+ll7CqdYAtYLHs7iq2ucQZjrcB+qOqU
X-Gm-Gg: ASbGncv0/LLtHmT7pIGo3UMPmDjbf2VI7Bd1sip6ybw3KnB0EKcq2KogvPOiJ495nSD
	NdO5olp06Z85gkbihwV78TbmCA6g6O00m+4U6n+XnlChKM9v3w/F9eO1aatDqZqTK6Dqz88hMFC
	GosMA/m2sRQZ8P/ySwHBbTkjjNHkTM1dZKebaKa5p5ItlrmC9f0mc5jPwBcoKf6xtgcM5LjQ8Dj
	VYRoPKofYolIvLl/JpdnXHol2NIU1r+MboZVfqXLphzjubPocutB5YQ6gAjbDXjNemK1kj9XAla
	2ry2mmI=
X-Google-Smtp-Source: AGHT+IGZS1PwZcjjzqbcIiM0wjykbuA/dZyUpYPyp+ZmhfemWabxVFjf2TZV3vHHchCFDWuWWhRWgw==
X-Received: by 2002:a05:6402:1ec1:b0:5d3:f6cb:73e7 with SMTP id 4fb4d7f45d1cf-5db7d2fc234mr21005799a12.13.1737561706755;
        Wed, 22 Jan 2025 08:01:46 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------UmrOygGyndRTXyq57w1EU0b8"
Message-ID: <7dcee103-1f3d-4b0c-b9c3-d9f37d4735b2@gmail.com>
Date: Wed, 22 Jan 2025 17:01:45 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] x86emul: further correct 64-bit mode zero count
 repeated string insn handling
To: Jan Beulich <jbeulich@suse.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <2e81cf29-65fd-74fc-db4f-95c453acc327@suse.com>
 <Z5DHOknjrhMoAGz6@macbook.local>
 <24885d31-e536-4ff4-8457-300c9a028701@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <24885d31-e536-4ff4-8457-300c9a028701@suse.com>

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


On 1/22/25 2:29 PM, Jan Beulich wrote:
> On 22.01.2025 11:23, Roger Pau Monné wrote:
>> On Fri, Aug 04, 2023 at 07:58:21AM +0200, Jan Beulich wrote:
>>> In an entirely different context I came across Linux commit 428e3d08574b
>>> ("KVM: x86: Fix zero iterations REP-string"), which points out that
>>> we're still doing things wrong: For one, there's no zero-extension at
>>> all on AMD. And then while RCX is zero-extended from 32 bits uniformly
>>> for all string instructions on newer hardware, RSI/RDI are only for MOVS
>>> and STOS on the systems I have access to. (On an old family 0xf system
>>> I've further found that for REP LODS even RCX is not zero-extended.)
>>>
>>> Fixes: 79e996a89f69 ("x86emul: correct 64-bit mode repeated string insn handling with zero count")
>>> Signed-off-by: Jan Beulich<jbeulich@suse.com>
>> Acked-by: Roger Pau Monné<roger.pau@citrix.com>
> Thanks. I'm uncertain though whether with concerns Andrew had voiced (maybe
> just on irc/Matrix) I may go ahead and commit this. Andrew?
>
> In any event - Oleksii, I guess I'd need a release ack here (or an indication
> to defer to 4.21).

If Andrew has no objections to this patch, then:|R-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>|

Otherwise, it would be better to defer the patch to 4.21 or wait until the objections are resolved or clarified as unnecessary.


~ Oleksii

>
>>> ---
>>> Partly RFC for none of this being documented anywhere (and it partly
>>> being model specific); inquiry pending.
>> Did you get any reply on this?
> No, and to be honest I also didn't have much hope I would get any reply.
>
> Jan
--------------UmrOygGyndRTXyq57w1EU0b8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 1/22/25 2:29 PM, Jan Beulich wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:24885d31-e536-4ff4-8457-300c9a028701@suse.com">
      <pre wrap="" class="moz-quote-pre">On 22.01.2025 11:23, Roger Pau Monné wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">On Fri, Aug 04, 2023 at 07:58:21AM +0200, Jan Beulich wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="" class="moz-quote-pre">In an entirely different context I came across Linux commit 428e3d08574b
("KVM: x86: Fix zero iterations REP-string"), which points out that
we're still doing things wrong: For one, there's no zero-extension at
all on AMD. And then while RCX is zero-extended from 32 bits uniformly
for all string instructions on newer hardware, RSI/RDI are only for MOVS
and STOS on the systems I have access to. (On an old family 0xf system
I've further found that for REP LODS even RCX is not zero-extended.)

Fixes: 79e996a89f69 ("x86emul: correct 64-bit mode repeated string insn handling with zero count")
Signed-off-by: Jan Beulich <a class="moz-txt-link-rfc2396E" href="mailto:jbeulich@suse.com">&lt;jbeulich@suse.com&gt;</a>
</pre>
        </blockquote>
        <pre wrap="" class="moz-quote-pre">
Acked-by: Roger Pau Monné <a class="moz-txt-link-rfc2396E" href="mailto:roger.pau@citrix.com">&lt;roger.pau@citrix.com&gt;</a>
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
Thanks. I'm uncertain though whether with concerns Andrew had voiced (maybe
just on irc/Matrix) I may go ahead and commit this. Andrew?

In any event - Oleksii, I guess I'd need a release ack here (or an indication
to defer to 4.21).</pre>
    </blockquote>
    <pre>If Andrew has no objections to this patch, then: <code>R-Acked-by: Oleksii Kurochko <a class="moz-txt-link-rfc2396E" href="mailto:oleksii.kurochko@gmail.com">&lt;oleksii.kurochko@gmail.com&gt;</a></code></pre>
    <pre>Otherwise, it would be better to defer the patch to 4.21 or wait until the objections are resolved or clarified as unnecessary.</pre>
    <pre>

~ Oleksii
</pre>
    <blockquote type="cite"
      cite="mid:24885d31-e536-4ff4-8457-300c9a028701@suse.com">
      <pre wrap="" class="moz-quote-pre">

</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="" class="moz-quote-pre">---
Partly RFC for none of this being documented anywhere (and it partly
being model specific); inquiry pending.
</pre>
        </blockquote>
        <pre wrap="" class="moz-quote-pre">
Did you get any reply on this?
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
No, and to be honest I also didn't have much hope I would get any reply.

Jan
</pre>
    </blockquote>
  </body>
</html>

--------------UmrOygGyndRTXyq57w1EU0b8--


From xen-devel-bounces@lists.xenproject.org Wed Jan 22 17:46:36 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Jan 2025 17:46:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876004.1286390 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taenx-0002dU-BX; Wed, 22 Jan 2025 17:46:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876004.1286390; Wed, 22 Jan 2025 17:46:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taenx-0002dN-6U; Wed, 22 Jan 2025 17:46:17 +0000
Received: by outflank-mailman (input) for mailman id 876004;
 Wed, 22 Jan 2025 17:46:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=jYzQ=UO=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1taenw-0002dF-Ck
 for xen-devel@lists.xenproject.org; Wed, 22 Jan 2025 17:46:16 +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 b643a662-d8e8-11ef-a0e5-8be0dac302b0;
 Wed, 22 Jan 2025 18:45:47 +0100 (CET)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-5db689a87cbso77039a12.3
 for <xen-devel@lists.xenproject.org>; Wed, 22 Jan 2025 09:45:47 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab384f223dcsm926998566b.123.2025.01.22.09.45.46
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 22 Jan 2025 09:45:46 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b643a662-d8e8-11ef-a0e5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737567947; x=1738172747; 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=35X/Lm1Sw8kEIzs1tpQwWbVyenVhfCjmTR+f/Pr3sRE=;
        b=wJADaysaPtZAasHansq5ByveySZWMUzxSeMer4nWWs/C8p9WMVfOv+0SRvRK5AhiYV
         T7ZvlivxhoYFfwz/ikelfWDxQO4XjJa2o1ml27mhJ4mNWSkMpW+L5DQ4eaAFT3up+R3s
         S6vO6Giv81mX8Y8hz+9WgDSaDQ5FlP0erTqjk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737567947; x=1738172747;
        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=35X/Lm1Sw8kEIzs1tpQwWbVyenVhfCjmTR+f/Pr3sRE=;
        b=q/EORdX4uCqw/zm/GPPyPPFZZyID+6cbzcXwytMYYwyBFzEVTwRRGJ3rUUPCKR7O0/
         2Y3WFKqT9oeNWTOiy7RqHgSVJTzwV71kHe0b3XkkRx8EpnqtrIGj8bBv9jd6wyhhMey4
         VELIAt6FxA8ORPGKrZTBxdSI18eiPx6OuwbcjEgQadol08i4W3ErnGiWS95wbisKZeNf
         S0kTPx9nYNh7y5ZVjpTy1J99MIKrIm7wTsb+01Ct+jSgwqOtK2+pH4QeLqq6UTc9RS6+
         i5lI32Bw0owTKJtbINudUOg+QAIU9f7U2ugPJ67NZeG4dUBZ5gUO5WvV3yK90dMsbh54
         TmJw==
X-Gm-Message-State: AOJu0YzFubgPfYwsHDp7+GFVq7qXCUAvPIqDq7llO86RhyPSJS0AwD3Z
	lEK2RGh1oZhYcLtWSrdP29s4qA2MkD8KGM2BDEH+rIy36Qmv2uK1iddCl8+8BdU=
X-Gm-Gg: ASbGnctW3CgcAw4s4iKujTLOfPQOoOQeeWZ3QCqC+/4no+zgSlTVRs8AU2YN709Uf+7
	jS8tTb/Nm+IhWlbzaEuRBCWUUNNv8Q8FLDRPnWZob/2EaeTNqAZRA/Yprs5Y4OYW6hQt+zv2YTr
	oqcNpx+HV1nEihWsUb3u9QFAqvVndqKfG0K6SjVYkSpjI9NPf67tZYSRuO1ju2n8zjzxQxD+b76
	cjtquvgtJYVrSuwjfc2bplMCwDE4eG+Wjnn5KoTBYMGBvt4UHCbKm3bdXORyUYgfBjLcAKInkTE
	Qq/3
X-Google-Smtp-Source: AGHT+IH/D45BGwMiZmkbGM3czLY3pmdJQtJyHdVu9uf1cegfUURe/UlntRacHZVcTrdMSuDTZQZjiQ==
X-Received: by 2002:a17:907:3da4:b0:aa6:7933:8b31 with SMTP id a640c23a62f3a-ab38b3707bdmr2297719566b.46.1737567946758;
        Wed, 22 Jan 2025 09:45:46 -0800 (PST)
Date: Wed, 22 Jan 2025 18:45:45 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Manuel Andreas <manuel.andreas@tum.de>
Subject: Re: [PATCH v2 3/5] x86/HVM: correct read/write split at page
 boundaries
Message-ID: <Z5Euyc91PZsyMP6f@macbook.local>
References: <3294f629-f91f-4b5d-9eb0-40a34aa2ec3e@suse.com>
 <fde70079-4084-4aa6-b76e-becd62a71ddb@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <fde70079-4084-4aa6-b76e-becd62a71ddb@suse.com>

On Tue, Oct 01, 2024 at 10:49:40AM +0200, Jan Beulich wrote:
> The MMIO cache is intended to have one entry used per independent memory
> access that an insn does. This, in particular, is supposed to be
> ignoring any page boundary crossing. Therefore when looking up a cache
> entry, the access'es starting (linear) address is relevant, not the one
> possibly advanced past a page boundary.
> 
> In order for the same offset-into-buffer variable to be usable in
> hvmemul_phys_mmio_access() for both the caller's buffer and the cache
> entry's it is further necessary to have the un-adjusted caller buffer
> passed into there.
> 
> Fixes: 2d527ba310dc ("x86/hvm: split all linear reads and writes at page boundary")
> Reported-by: Manuel Andreas <manuel.andreas@tum.de>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> This way problematic overlaps are only reduced (to ones starting at the
> same address), not eliminated: Assumptions in hvmemul_phys_mmio_access()
> go further - if a subsequent access is larger than an earlier one, but
> the splitting results in a chunk to cross the end "boundary" of the
> earlier access, an assertion will still trigger. Explicit memory
> accesses (ones encoded in an insn by explicit or implicit memory
> operands) match the assumption afaict (i.e. all those accesses are of
> uniform size, and hence they either fully overlap or are mapped to
> distinct cache entries).
> 
> Insns accessing descriptor tables, otoh, don't fulfill these
> expectations: The selector read (if coming from memory) will always be
> smaller than the descriptor being read, and if both (insanely) start at
> the same linear address (in turn mapping MMIO), said assertion will kick
> in. (The same would be true for an insn trying to access itself as data,
> as long as certain size "restrictions" between insn and memory operand
> are met. Except that linear_read() disallows insn fetches from MMIO.) To
> deal with such, I expect we will need to further qualify (tag) cache
> entries, such that reads/writes won't use insn fetch entries, and
> implicit-supervisor-mode accesses won't use entries of ordinary
> accesses. (Page table accesses don't need considering here for now, as
> our page walking code demands page tables to be mappable, implying
> they're in guest RAM; such accesses also don't take the path here.)
> Thoughts anyone, before I get to making another patch?
> 
> Considering the insn fetch aspect mentioned above I'm having trouble
> following why the cache has 3 entries. With insn fetches permitted,
> descriptor table accesses where the accessed bit needs setting may also
> fail because of that limited capacity of the cache, due to the way the
> accesses are done. The read and write (cmpxchg) are independent accesses
> from the cache's perspective, and hence we'd need another entry there.
> If, otoh, the 3 entries are there to account for precisely this (which
> seems unlikely with commit e101123463d2 ["x86/hvm: track large memory
> mapped accesses by buffer offset"] not saying anything at all), then we
> should be fine in this regard. If we were to permit insn fetches, which
> way to overcome this (possibly by allowing the write to re-use the
> earlier read's entry in this special situation) would remain to be
> determined.

I'm not that familiar with the emulator logic for memory accesses, but
it seems like we are adding more and more complexity and special
casing.  Maybe it's the only way to go forward, but I wonder if there
could be some other way to solve this.  However, I don't think I
will have time to look into it, and hence I'm not going to oppose to
your proposal.

Are there however some tests, possibly XTF, that we could use to
ensure the behavior of accesses is as we expect?

> 
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -31,8 +31,9 @@
>   * device-model transactions.
>   */
>  struct hvm_mmio_cache {
> -    unsigned long gla;
> -    unsigned int size;
> +    unsigned long gla;     /* Start of original access (e.g. insn operand) */
> +    unsigned int skip;     /* Offset to start of MMIO */
> +    unsigned int size;     /* Populated space, including @skip */
>      unsigned int space:31;
>      unsigned int dir:1;
>      uint8_t buffer[] __aligned(sizeof(long));
> @@ -953,6 +954,13 @@ static int hvmemul_phys_mmio_access(
>          return X86EMUL_UNHANDLEABLE;
>      }
>  
> +    /* Accesses must not be to the unused leading space. */
> +    if ( offset < cache->skip )
> +    {
> +        ASSERT_UNREACHABLE();
> +        return X86EMUL_UNHANDLEABLE;
> +    }
> +
>      /*
>       * hvmemul_do_io() cannot handle non-power-of-2 accesses or
>       * accesses larger than sizeof(long), so choose the highest power
> @@ -1010,13 +1018,15 @@ static int hvmemul_phys_mmio_access(
>  
>  /*
>   * Multi-cycle MMIO handling is based upon the assumption that emulation
> - * of the same instruction will not access the same MMIO region more
> - * than once. Hence we can deal with re-emulation (for secondary or
> - * subsequent cycles) by looking up the result or previous I/O in a
> - * cache indexed by linear MMIO address.
> + * of the same instruction will not access the exact same MMIO region
> + * more than once in exactly the same way (if it does, the accesses will
> + * be "folded"). Hence we can deal with re-emulation (for secondary or
> + * subsequent cycles) by looking up the result of previous I/O in a cache
> + * indexed by linear address and access type.
>   */
>  static struct hvm_mmio_cache *hvmemul_find_mmio_cache(
> -    struct hvm_vcpu_io *hvio, unsigned long gla, uint8_t dir, bool create)
> +    struct hvm_vcpu_io *hvio, unsigned long gla, uint8_t dir,
> +    unsigned int skip)
>  {
>      unsigned int i;
>      struct hvm_mmio_cache *cache;
> @@ -1030,7 +1040,11 @@ static struct hvm_mmio_cache *hvmemul_fi
>              return cache;
>      }
>  
> -    if ( !create )
> +    /*
> +     * Bail if a new entry shouldn't be allocated, utilizing that ->space has
                                                      ^rely on ->space having ...
Would be easier to read IMO.

> +     * the same value for all entries.
> +     */
> +    if ( skip >= hvio->mmio_cache[0]->space )
>          return NULL;
>  
>      i = hvio->mmio_cache_count;
> @@ -1043,7 +1057,8 @@ static struct hvm_mmio_cache *hvmemul_fi
>      memset(cache->buffer, 0, cache->space);
>  
>      cache->gla = gla;
> -    cache->size = 0;
> +    cache->skip = skip;
> +    cache->size = skip;
>      cache->dir = dir;
>  
>      return cache;
> @@ -1064,12 +1079,14 @@ static void latch_linear_to_phys(struct
>  
>  static int hvmemul_linear_mmio_access(
>      unsigned long gla, unsigned int size, uint8_t dir, void *buffer,
> -    uint32_t pfec, struct hvm_emulate_ctxt *hvmemul_ctxt, bool known_gpfn)
> +    uint32_t pfec, struct hvm_emulate_ctxt *hvmemul_ctxt,
> +    unsigned long start, bool known_gpfn)

I think start is a bit ambiguous, start_gla might be clearer (same
below for the start parameter).

>  {
>      struct hvm_vcpu_io *hvio = &current->arch.hvm.hvm_io;
>      unsigned long offset = gla & ~PAGE_MASK;
> -    struct hvm_mmio_cache *cache = hvmemul_find_mmio_cache(hvio, gla, dir, true);
> -    unsigned int chunk, buffer_offset = 0;
> +    unsigned int chunk, buffer_offset = gla - start;
> +    struct hvm_mmio_cache *cache = hvmemul_find_mmio_cache(hvio, start, dir,
> +                                                           buffer_offset);
>      paddr_t gpa;
>      unsigned long one_rep = 1;
>      int rc;
> @@ -1117,19 +1134,19 @@ static int hvmemul_linear_mmio_access(
>  static inline int hvmemul_linear_mmio_read(
>      unsigned long gla, unsigned int size, void *buffer,
>      uint32_t pfec, struct hvm_emulate_ctxt *hvmemul_ctxt,
> -    bool translate)
> +    unsigned long start, bool translate)
>  {
>      return hvmemul_linear_mmio_access(gla, size, IOREQ_READ, buffer,
> -                                      pfec, hvmemul_ctxt, translate);
> +                                      pfec, hvmemul_ctxt, start, translate);
>  }
>  
>  static inline int hvmemul_linear_mmio_write(
>      unsigned long gla, unsigned int size, void *buffer,
>      uint32_t pfec, struct hvm_emulate_ctxt *hvmemul_ctxt,
> -    bool translate)
> +    unsigned long start, bool translate)
>  {
>      return hvmemul_linear_mmio_access(gla, size, IOREQ_WRITE, buffer,
> -                                      pfec, hvmemul_ctxt, translate);
> +                                      pfec, hvmemul_ctxt, start, translate);
>  }
>  
>  static bool known_gla(unsigned long addr, unsigned int bytes, uint32_t pfec)
> @@ -1158,7 +1175,10 @@ static int linear_read(unsigned long add
>  {
>      pagefault_info_t pfinfo;
>      struct hvm_vcpu_io *hvio = &current->arch.hvm.hvm_io;
> +    void *buffer = p_data;
> +    unsigned long start = addr;
>      unsigned int offset = addr & ~PAGE_MASK;
> +    const struct hvm_mmio_cache *cache;
>      int rc;
>  
>      if ( offset + bytes > PAGE_SIZE )
> @@ -1182,8 +1202,17 @@ static int linear_read(unsigned long add
>       * an access that was previously handled as MMIO. Thus it is imperative that
>       * we handle this access in the same way to guarantee completion and hence
>       * clean up any interim state.
> +     *
> +     * Care must be taken, however, to correctly deal with crossing RAM/MMIO or
> +     * MMIO/RAM boundaries. While we want to use a single cache entry (tagged
> +     * by the starting linear address), we need to continue issuing (i.e. also
> +     * upon replay) the RAM access for anything that's ahead of or past MMIO,
> +     * i.e. in RAM.
>       */
> -    if ( !hvmemul_find_mmio_cache(hvio, addr, IOREQ_READ, false) )
> +    cache = hvmemul_find_mmio_cache(hvio, start, IOREQ_READ, ~0);
> +    if ( !cache ||
> +         addr + bytes <= start + cache->skip ||
> +         addr >= start + cache->size )

Seeing as this bound checks is also used below, could it be a macro or
inline function?

is_cached() or similar?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Jan 22 17:47:42 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Jan 2025 17:47:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876013.1286400 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taepJ-00038I-Id; Wed, 22 Jan 2025 17:47:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876013.1286400; Wed, 22 Jan 2025 17:47:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taepJ-00038B-Ft; Wed, 22 Jan 2025 17:47:41 +0000
Received: by outflank-mailman (input) for mailman id 876013;
 Wed, 22 Jan 2025 17:47:40 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=jYzQ=UO=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1taepI-000381-1p
 for xen-devel@lists.xenproject.org; Wed, 22 Jan 2025 17:47:40 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f8ce53b0-d8e8-11ef-a0e5-8be0dac302b0;
 Wed, 22 Jan 2025 18:47:39 +0100 (CET)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-5d647d5df90so69407a12.2
 for <xen-devel@lists.xenproject.org>; Wed, 22 Jan 2025 09:47:39 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5db7364258csm8707206a12.1.2025.01.22.09.47.37
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 22 Jan 2025 09:47:38 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f8ce53b0-d8e8-11ef-a0e5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737568058; x=1738172858; 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=DeQjUUicbBqviSksbyHebDo61aD1lEGSAwrEn+EfYoM=;
        b=LwNOGp8ykLPyrP223DZ+F/K0lFP4t31ts+q2849UcTUE8qR4yUJX4ebjh/FlbhvZDc
         chsQyp6HG7nuMi2HkeMHd2Fga0I8D/yhfzWopy8bMVD3+np5tF1/FlQPnR3VC8pHvFNu
         3PKuqL/XdfHupzY/rRI/qxfl+F898AyrnreX4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737568058; x=1738172858;
        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=DeQjUUicbBqviSksbyHebDo61aD1lEGSAwrEn+EfYoM=;
        b=D7BqRnIrp+y3iQnMy4pVkKEpRfSa5KZifFi6/cu4z/udVtOF+9udxJ0sdfe7XcANdI
         vdrq8yR1fHF5O/veQvn6Ee+Kg8uxREfXJkf/kVq0fYjp8CMy5KJZXZX835MFPYdYo23j
         lD5WjeZjVxlHEhH/86SioEDYuKIB5HE0cYTk0dognHSn8pLVucf/clZ6ZfPB//IN78/+
         miUK6/XO2UH8RhwSX/E/kdo07wuyf5Z7AakBRu2qZ8iJCSIrkD6GMmZOAb2jpR5qUdcr
         B4GzgyC3rtWwSXLwlYbsUlRBo+e61zjVB4D1f5h3OChlU9XpaHX5dibQcPwpepM8Q61g
         l92A==
X-Gm-Message-State: AOJu0Yw/CZzEwBQWe/n6ch9gkBKu5e1XWe213VlYbBVJmW3byfPcogIG
	wFKPp1+tH11UX7Y/QhcPIWGHyVn/5y6E4EfxKZruXopbE4MuKU15wM7fczl0bR/ehFWuX1Yl0MI
	3
X-Gm-Gg: ASbGnctiAMOo8/mdWxxSc2GJiyyX9iJmSBYpzy2I7HqB2AEJ2vDI1q3zvRV3MxJRmi9
	teHhmJnZ6nGEsaQDtSoW4Yp+XcBjyJ7LJIkipAO4DPrmOaku4xrs/HHZg1egx9bHBYryqrQR6OR
	EFiETTI07DI2jDGYxSFVQtYehJccdoZVfSsSeozIzX0cDsm1BYmujY89+EMLwIvu1A/riEarpN+
	ZN4m56SLZCddUp8hb0y2B6248MHKQq7CZ3ceZJTSVMr0RIZTmd/XzJmpOZlYo2YsscEA4X/tA0z
	VAod
X-Google-Smtp-Source: AGHT+IEkl0kZbwttoDcsTvCH+GxAWXI21jaEj+/T6LVutFnp3HkHtK0mJzsNwJ8izVFepEs8nSEeyA==
X-Received: by 2002:a05:6402:5106:b0:5d4:4143:c06c with SMTP id 4fb4d7f45d1cf-5db7db086c2mr20781614a12.23.1737568058545;
        Wed, 22 Jan 2025 09:47:38 -0800 (PST)
Date: Wed, 22 Jan 2025 18:47:37 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v2 2/5] x86/HVM: allocate emulation cache entries
 dynamically
Message-ID: <Z5EvOTbZC_UxUGo-@macbook.local>
References: <3294f629-f91f-4b5d-9eb0-40a34aa2ec3e@suse.com>
 <93967ab8-a472-475a-bdd6-41dfc3afa895@suse.com>
 <Z5Ddzh-Ygy5cGuPj@macbook.local>
 <de1934b8-b7c9-472f-9b9e-5183a5a34b65@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <de1934b8-b7c9-472f-9b9e-5183a5a34b65@suse.com>

On Wed, Jan 22, 2025 at 02:39:43PM +0100, Jan Beulich wrote:
> On 22.01.2025 13:00, Roger Pau Monné wrote:
> > On Tue, Oct 01, 2024 at 10:49:10AM +0200, Jan Beulich wrote:
> >> Both caches may need higher capacity, and the upper bound will need to
> >> be determined dynamically based on CPUID policy (for AMX'es TILELOAD /
> >> TILESTORE at least).
> >>
> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> > 
> > Just a couple of comments below.
> > 
> >> ---
> >> This is a patch taken from the AMX series, but wasn't part of the v3
> >> submission. All I did is strip out the actual AMX bits (from
> >> hvmemul_cache_init()), plus of course change the description. As a
> >> result some local variables there may look unnecessary, but this way
> >> it's going to be less churn when the AMX bits are added. The next patch
> >> pretty strongly depends on the changed approach (contextually, not so
> >> much functionally), and I'd really like to avoid rebasing that one ahead
> >> of this one, and then this one on top of that.
> > 
> > Oh, I was just going to ask about the weirdness of nents compared to
> > what was previously.
> 
> And then you did ask; I'll comment on that below.
> 
> >> --- a/xen/arch/x86/hvm/emulate.c
> >> +++ b/xen/arch/x86/hvm/emulate.c
> >> @@ -26,6 +26,18 @@
> >>  #include <asm/iocap.h>
> >>  #include <asm/vm_event.h>
> >>  
> >> +/*
> >> + * We may read or write up to m512 or up to a tile row as a number of
> >> + * device-model transactions.
> >> + */
> >> +struct hvm_mmio_cache {
> >> +    unsigned long gla;
> >> +    unsigned int size;
> >> +    unsigned int space:31;
> > 
> > Having size and space is kind of confusing, would you mind adding a
> > comment that size is the runtime consumed buffer space, while space is
> > the total allocated buffer size (and hence not supposed to change
> > during usage)?
> 
> Sure; I thought the two names would be clear enough when sitting side by
> side, but here you go:
> 
>     unsigned int size;     /* Amount of buffer[] actually used. */
>     unsigned int space:31; /* Allocated size of buffer[]. */
> 
> 
> >> @@ -2978,16 +2991,21 @@ void hvm_dump_emulation_state(const char
> >>  int hvmemul_cache_init(struct vcpu *v)
> >>  {
> >>      /*
> >> -     * No insn can access more than 16 independent linear addresses (AVX512F
> >> -     * scatters/gathers being the worst). Each such linear range can span a
> >> -     * page boundary, i.e. may require two page walks. Account for each insn
> >> -     * byte individually, for simplicity.
> >> +     * AVX512F scatter/gather insns can access up to 16 independent linear
> >> +     * addresses, up to 8 bytes size. Each such linear range can span a page
> >> +     * boundary, i.e. may require two page walks.
> >> +     */
> >> +    unsigned int nents = 16 * 2 * (CONFIG_PAGING_LEVELS + 1);
> >> +    unsigned int i, max_bytes = 64;
> >> +    struct hvmemul_cache *cache;
> >> +
> >> +    /*
> >> +     * Account for each insn byte individually, both for simplicity and to
> >> +     * leave some slack space.
> >>       */
> >> -    const unsigned int nents = (CONFIG_PAGING_LEVELS + 1) *
> >> -                               (MAX_INST_LEN + 16 * 2);
> >> -    struct hvmemul_cache *cache = xmalloc_flex_struct(struct hvmemul_cache,
> >> -                                                      ents, nents);
> >> +    nents += MAX_INST_LEN * (CONFIG_PAGING_LEVELS + 1);
> >>  
> >> +    cache = xvmalloc_flex_struct(struct hvmemul_cache, ents, nents);
> > 
> > Change here seems completely unrelated, but I guess this is what you
> > refer to in the post-commit remark.  IOW: the split of the nents
> > variable setup, plus the change of xmalloc_flex_struct() ->
> > xvmalloc_flex_struct() don't seem to be related to the change at
> > hand.
> 
> See the post-commit-message remark that you commented on. To repeat:
> It'll be quite a bit easier for me if the seemingly unrelated adjustments
> could be kept like that. Unless of course there's something wrong with
> them.
> 
> >> @@ -2997,6 +3015,15 @@ int hvmemul_cache_init(struct vcpu *v)
> >>  
> >>      v->arch.hvm.hvm_io.cache = cache;
> >>  
> >> +    for ( i = 0; i < ARRAY_SIZE(v->arch.hvm.hvm_io.mmio_cache); ++i )
> >> +    {
> >> +        v->arch.hvm.hvm_io.mmio_cache[i] =
> >> +            xmalloc_flex_struct(struct hvm_mmio_cache, buffer, max_bytes);
> > 
> > TBH I would be tempted to just use xvmalloc here also, even if the
> > structure is never going to be > PAGE_SIZE, it's more consistent IMO.
> 
> Oh, absolutely under the current rules (which weren't in effect yet back
> when all of this was written).

With the two items above fixed (not the nents related change, that's
fine as-is):

Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Jan 22 21:10:37 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Jan 2025 21:10:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876034.1286410 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tahzT-0002iD-6h; Wed, 22 Jan 2025 21:10:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876034.1286410; Wed, 22 Jan 2025 21:10:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tahzT-0002i6-2k; Wed, 22 Jan 2025 21:10:23 +0000
Received: by outflank-mailman (input) for mailman id 876034;
 Wed, 22 Jan 2025 21:10:21 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=nwLx=UO=amd.com=Jason.Andryuk@srs-se1.protection.inumbo.net>)
 id 1tahzR-0002i0-2M
 for xen-devel@lists.xenproject.org; Wed, 22 Jan 2025 21:10:21 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20604.outbound.protection.outlook.com
 [2a01:111:f403:2418::604])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 47e48da7-d905-11ef-99a4-01e77a169b0f;
 Wed, 22 Jan 2025 22:10:18 +0100 (CET)
Received: from SN6PR01CA0011.prod.exchangelabs.com (2603:10b6:805:b6::24) by
 DM6PR12MB4353.namprd12.prod.outlook.com (2603:10b6:5:2a6::12) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8356.22; Wed, 22 Jan 2025 21:10:12 +0000
Received: from SA2PEPF00003F62.namprd04.prod.outlook.com
 (2603:10b6:805:b6:cafe::c3) by SN6PR01CA0011.outlook.office365.com
 (2603:10b6:805:b6::24) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8356.21 via Frontend Transport; Wed,
 22 Jan 2025 21:10:12 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SA2PEPF00003F62.mail.protection.outlook.com (10.167.248.37) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8377.8 via Frontend Transport; Wed, 22 Jan 2025 21:10:11 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 22 Jan
 2025 15:10:11 -0600
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 22 Jan
 2025 15:10:11 -0600
Received: from [192.168.62.40] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Wed, 22 Jan 2025 15:10:10 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 47e48da7-d905-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=IOjemcsZOnKu25m1QgoCG9vH2Tt8NTplmXjZDjxGQVOGSS5YzXxra7y+Nb7KgEQ2IDQMrG0r01yBuQIjwN8AvvkMSPzaQT3ky81uOsyc1/9QG9rZguX2i79FOd/2ji2spTsCRKlPazDVUJL04jhfniVqtYH38ZnMaFXIMASHBT6uLKRPmqoGvU0GBrfijFN06QIvz72OY2rO8ggET0SsC2hDfgfpk7cMkd+u7w8a/9m2arL1dBxIiK+C0QIhT2T8NLXEQt6KOty7alH4OyYwAnNn2lIT0pv7piuGpirqliwTfdagJyVabLnpFmP8PNxp+sFhq8A8HF/E0tRLLD4yFA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=ZebZP97Gkv980sGkf0i4UIqMoPKku5TR0lgvSI1jARs=;
 b=Q2bW/1OVpmwv5SlGO8/A37KlyWHjaJVLqULBhWAz1XvlVpzJsuejk/6AeuEt5QW6ez9lsIPNM/CN/gA/+byPz0VzAGWjaVuZkRDqkyfC+lOwSl/LYw+RrXlzPumr473ag+RKUTSVdhUhC6lOqI/I6OX6ceodqlEyQrnjWLvYAxhZ876homtNViIfkHEk5nCjhFmDcQiOYdjoeTT1+CCaugUa2+JOD+3775hSVpqt1UeaqXLtGABzhx/aEguH8+2TmeuD+7AN2ZmBkYrixFDdJCHc32uARFp9ZJ2n/JCL9H7proZea9/AFZgPXeR3pduyhvwltgqErdIcI/EIBqN5AQ==
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=ZebZP97Gkv980sGkf0i4UIqMoPKku5TR0lgvSI1jARs=;
 b=JZIhKg6HdobzTb3NiXtN7RVCWAExxnMaQAiY+v6Hk5cml7Zwadl766DIir3OMZKHY3Wi8auELX2gUdPWzWsQRql91ECl/lVNC7HdNkc8eZZnsClq0zRqA6YoHXVkeQG93gwqzBNuwdlO8fKJ/v9Pqr38W2Fl9zcenUmfcqEn+yw=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <22bd4587-cd00-41d4-a21f-102c6c61c942@amd.com>
Date: Wed, 22 Jan 2025 16:09:55 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 02/24] arm/vuart: move vpl011-related code to vpl011
 emulator
To: Jan Beulich <jbeulich@suse.com>, <dmukhin@ford.com>
CC: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
	<julien@xen.org>, Michal Orzel <michal.orzel@amd.com>, Andrew Cooper
	<andrew.cooper3@citrix.com>, Anthony PERARD <anthony.perard@vates.tech>,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
	<xen-devel@lists.xenproject.org>
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
 <20250103-vuart-ns8250-v3-v1-2-c5d36b31d66c@ford.com>
 <99bda095-391e-4825-9bb4-c21b7c5e1813@amd.com>
 <68e3da06-2b21-4f42-8d24-2743290ac562@suse.com>
Content-Language: en-US
From: Jason Andryuk <jason.andryuk@amd.com>
In-Reply-To: <68e3da06-2b21-4f42-8d24-2743290ac562@suse.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB05.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SA2PEPF00003F62:EE_|DM6PR12MB4353:EE_
X-MS-Office365-Filtering-Correlation-Id: caa07a86-a68f-46bc-47c8-08dd3b2928c4
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|82310400026|1800799024|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?cVFTcTRYOEQ3alpLT0w4UnltK2hjc3JJeWdNYU92Wloya0Y2bWdYUmMrcEJ4?=
 =?utf-8?B?M1NOcmtPMWc4NkJjTnNKWXoyNjdLZGhEeDdaMzdHMnN4WHF1WFREZFR2dVF6?=
 =?utf-8?B?dzY3aUI5aFp4VzlRdDZxSm5MUit2VHY4V0ZBYllWTmtsZmtDSG1ubmtPYzBV?=
 =?utf-8?B?a0xKVFYzZGdSZzNyWlp1RDc5bVRVdlFHVHIvV2F5eVg3dXRCUlpTMjJ2dC9S?=
 =?utf-8?B?UmJlOFZsQWlkakZ6YTFEZ3hPMzFlNDFJL3RUaG9MMEdvYVd4eUxQNFZ6Szd2?=
 =?utf-8?B?dzFGVTFUTGFydCt5QjdmTjhRcitURk5lRUh1Z3MrZWNxemlMN2dESmQ5dXZx?=
 =?utf-8?B?RVhSTlRaT3NiSURXVTZwbFBLdnpXUjZaRjRxZEgwN2RBemErZ3R0V0RBc3Rp?=
 =?utf-8?B?YXBEQUZ2ZjNBMEgrL0doTlp3YjNibTk4OTZTSHVnbGJVR1p6R2xWRGc5U1FL?=
 =?utf-8?B?cG0yWlY1eHZrbFhkOTJlZm5aRnlKTU9LQ3ZWbDJnZ3NqL1ZSUThsVVdOdzZm?=
 =?utf-8?B?d21KK3NrT014RGxvUE9IS2ZQUktmMFJ4Uy92QlJ1dlNGT0VJSWEvejRUK0hx?=
 =?utf-8?B?NzhWQmtUZXYrNitsOHhlSjhlLysxUEx4TTB3UFdvaUpreHUzbDdsL2d2NGEv?=
 =?utf-8?B?eGpTMGxUMDVnbnNEeVphOCs2L2x4NkJqSWE5U0pTcFljM2VqNktOZjErcFY2?=
 =?utf-8?B?SnhlOEVtTmxYR3Y1NFk5bTFoZHlkem90NnpGRE0yZ2FJR1JDK2VUbGtJb3dG?=
 =?utf-8?B?d1NMU1g4U0phWFJwWDZ2Wm91LzVnNFdNNkdZV29FY0VUSzRhQmw5M2dLVUpL?=
 =?utf-8?B?U0VSemZ0VW9LazFkc0UrKzJFUHZHQmQwVkR6STh6NEd4cHQvejlCMTNrK2FO?=
 =?utf-8?B?ZW1EQ1FxcSt1aEkrK3MwOU9LTkZsTnZBcmYzQjdzQ2hwZzVTQ3FLdlVkM3hO?=
 =?utf-8?B?TU1aSTA2Zzl6TklOS0xwdmZzWmZYYVh1Q3FRNkUwTnpNMzBzU1dvQ01KSlpa?=
 =?utf-8?B?Y2RmOFd0ZEhyS1h3ck1WSlluWlRJbFlnWnVlWUo5TTRVQTRHcTdiTm80OUR6?=
 =?utf-8?B?eVo4WTl1ck85WktHYUNSZE1WcVZOdE9zbFl5elc5dHNGTVNGbVhlTmJyZWdX?=
 =?utf-8?B?Qk81RS9qUXJzdWZMcEh4NHdjelVnTlRGeVdQdC9jL1EyUHNTMXQyT0J1NS9M?=
 =?utf-8?B?SVcyRmt1N2E3Z0NvdmpISG1nbFh4NmtKMjdvRDhHWDh4eC9mdytmTzRxOWNF?=
 =?utf-8?B?dFdTdWpxckVyb0t5OXJ0UE10c1Y2bTJGMW9nNllCSHNibDBwS1JWTXI4ZVpq?=
 =?utf-8?B?d0xlN1VJOStGaXFrTjVNd3lsNFRuZ2ZPTE5PY2cvVHhia0pMa2Jna1U4eHVz?=
 =?utf-8?B?WjduYXZobXd6bk0vQVpoaHhOSjFiRTlrWWlMQ1ZQNmlwTUhwenBlb2ptOHlp?=
 =?utf-8?B?RDZkRG9JMm51UzZoYkNhSldmdlBYeWdXbUh2Q3hmbGhidTZrS3lZdDhUOFZy?=
 =?utf-8?B?YWtRRnlPd09La0p3ZjdCOThNYkRwcDlDdVZJNFE2Q0lRWUdtMlJjbGU3d3V6?=
 =?utf-8?B?TE1nKzFDRytidklyWVRtZXNFSFVjRWYyU2xMVk93VzNWVXhIbGV1WG0wME90?=
 =?utf-8?B?SWxTYU1vNzQ5dHYxQWJRVy9JRGNsbUc0Sjh0MUFkSTFsVG9CNkUxVmJvMzYw?=
 =?utf-8?B?UXJmM0Q3emZhSDMxbVQ0Z1NhR2tiRjE2NUw4T1p4TmR1VlluYjcwaWl5c29K?=
 =?utf-8?B?R2RpQ3NRcGlUZUhRWmFoNUpUSC9iL2RWa0Jra2dVVHp4ZmNCTW14NTlIME5z?=
 =?utf-8?B?VllXQjNKc0VUWFNTNEtIQThSMVd0Q1g1ZWpMUGVscm9qSFZ4QnF5M0sxT1p6?=
 =?utf-8?B?amFwQTh0SkRPZjM0Qyt1MHdKa0JBRGE2YjMzQXIzS3pvLzNoR1VlVkViLzlC?=
 =?utf-8?B?Q0dzeFNnRGVmMmZjaDNZaTgvSUZiL3FGdW8vUDB5anFDNzNKS05WZC83TEJ0?=
 =?utf-8?Q?F73UOfsgNhmD/ZYjDZoQco0mcl8nE8=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(1800799024)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2025 21:10:11.9347
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: caa07a86-a68f-46bc-47c8-08dd3b2928c4
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SA2PEPF00003F62.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4353

On 2025-01-22 02:26, Jan Beulich wrote:
> On 21.01.2025 23:56, Jason Andryuk wrote:
>> On 2025-01-03 20:58, Denis Mukhin via B4 Relay wrote:
>>> --- a/xen/drivers/char/console.c
>>> +++ b/xen/drivers/char/console.c
>>
>>> @@ -579,6 +571,9 @@ static void __serial_rx(char c)
>>>        if ( pv_shim && pv_console )
>>>            consoled_guest_tx(c);
>>>    #endif
>>> +
>>> +    if ( rc )
>>> +        printk(KERN_ERR "d%pd: failed to process console input: %d\n", d, rc);
>>>    }
>>>    
>>>    static void cf_check serial_rx(char c)
>>>
>>
>> This will print the ENOSPC that was formerly silent.  Since this is
>> input from the console, that seems more informative to the user and okay
>> to me.
> 
> I don't view this as okay. For one it needs to be a guest log level, such
> that rate limiting can suitably suppress too many of these messages in a
> short time (which in particular might happen if the ENOSPC reason isn't
> dealt with by the receiving domain). And then I wonder whether this
> wouldn't better be even more strongly limited, perhaps to just once per
> domain.

I was thinking of a user typing into the console.  Silently dropping 
characters is frustrating when you don't know it is happening.  On the 
other hand, if the domU is echoing characters, then the user receives 
feedback on their typing.  So maybe silently ignoring ENOSPC is okay?

ENODEV could be okay just once.  It could also be helpful to get the 
message if you come back a week later and try to type into the same 
console.  But these the user should rate limit themselves when they just 
keep getting errors :)

> I'm also unconvinced of KERN_ERR - from Xen's perspective nothing error-
> like has happened, once again most notably for the ENOSPC case. I'd view
> this as a warning at best.
> 
> Finally: Why d%pd? It ought to be just %pd.

Yes, thanks.

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Wed Jan 22 21:50:50 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Jan 2025 21:50:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876043.1286419 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taicV-0007wM-1B; Wed, 22 Jan 2025 21:50:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876043.1286419; Wed, 22 Jan 2025 21:50:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taicU-0007wF-Uh; Wed, 22 Jan 2025 21:50:42 +0000
Received: by outflank-mailman (input) for mailman id 876043;
 Wed, 22 Jan 2025 21:50:42 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=HhLn=UO=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1taicT-0007vD-Ua
 for xen-devel@lists.xenproject.org; Wed, 22 Jan 2025 21:50:41 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org
 [2604:1380:4641:c500::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id eb7f65f6-d90a-11ef-a0e5-8be0dac302b0;
 Wed, 22 Jan 2025 22:50:40 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 5AA5C5C56B5;
 Wed, 22 Jan 2025 21:49:58 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 53442C4CED2;
 Wed, 22 Jan 2025 21:50:37 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: eb7f65f6-d90a-11ef-a0e5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1737582638;
	bh=d6F70RIYR0XRfB3shU52lDwJDzboOHrtCNl2jxOI9MM=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=gk2Bu0eFdf6e0zfmZZsKBw19fIBt5UK1Oy/4Zigp5LQsWrYVXn453YWIgANUUb7Y1
	 miPXhcMpIg2FaL6zsHghKagSG6glXfTXiA4unbP7G1hMiAg9KdU+qMCPTI06xiKqp6
	 lW6haKfScQAuO05co2nsvNVvLawJDDG7jF/0J5brUNxdHvBsUGeJDzSyqzxILDkGp9
	 LsZhHswUk0iEDsY+9TUjhvtL1fAOc5A16yUYIz0QwB7qvESFM3QPlfZo9YUG6aOboy
	 7cfNlbJFjl3fgES6hNHI0xiWuYcACd0lCTlnSIz5FjUZywwzXtXkLZTNTMOZwpwrte
	 Q65IYWuuZpnow==
Date: Wed, 22 Jan 2025 13:50:36 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich <jbeulich@suse.com>
cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
    Stefano Stabellini <sstabellini@kernel.org>, 
    Andrew Cooper <andrew.cooper3@citrix.com>, 
    Alejandro Vallejo <alejandro.vallejo@cloud.com>, 
    "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, 
    Julien Grall <julien@xen.org>, Wei Liu <wl@xen.org>, 
    sergiy_kibrik@epam.com
Subject: Re: [PATCH v2 1/4] x86: provide an inverted Kconfig control for
 shim-exclusive mode
In-Reply-To: <6c0ebe4b-fc47-4bb0-b317-f854abb63517@suse.com>
Message-ID: <alpine.DEB.2.22.394.2501221349060.11086@ubuntu-linux-20-04-desktop>
References: <6285f86d-f2d2-4040-999d-01aed3e72a36@suse.com> <alpine.DEB.2.22.394.2501171430570.2684657@ubuntu-linux-20-04-desktop> <f8c1e2c2-ceb5-4200-a304-e2d824a171a8@citrix.com> <40c9d806-000d-43e7-a804-ad4e84209b2f@suse.com>
 <alpine.DEB.2.22.394.2501201527090.11086@ubuntu-linux-20-04-desktop> <bae48627-fa5b-48b6-b74e-267285175eff@suse.com> <Z49gQBkxCbXIO84D@macbook.local> <41859184-bd9c-420f-96c1-65abe379b81e@suse.com> <Z4_hOmi01AkiYH_k@macbook.local> <c897005a-2e8e-4031-a828-acb8128f7c0c@suse.com>
 <Z5C_EJEtorK2pwGE@macbook.local> <6c0ebe4b-fc47-4bb0-b317-f854abb63517@suse.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1937431721-1737582639=:11086"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-1937431721-1737582639=:11086
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Wed, 22 Jan 2025, Jan Beulich wrote:
> On 22.01.2025 10:49, Roger Pau Monné wrote:
> > On Wed, Jan 22, 2025 at 09:43:53AM +0100, Jan Beulich wrote:
> >> On 21.01.2025 19:02, Roger Pau Monné wrote:
> >>> On Tue, Jan 21, 2025 at 11:35:42AM +0100, Jan Beulich wrote:
> >>>> On 21.01.2025 09:52, Roger Pau Monné wrote:
> >>>>> On Tue, Jan 21, 2025 at 09:13:38AM +0100, Jan Beulich wrote:
> >>>>>> On 21.01.2025 00:27, Stefano Stabellini wrote:
> >>>>>>> If I understood it right, I like Andrew's suggestion. He is suggesting
> >>>>>>> to do the following:
> >>>>>>>
> >>>>>>> - turning PV_SHIM_EXCLUSIVE into something that does nothing
> >>>>>>
> >>>>>> FTAOD - you mean Kconfig-wise? Andrew clearly didn't say "nothing", but
> >>>>>> "nothing other than making the boolean be a compile time constant".
> >>>>>
> >>>>> Won't making the boolean a compile time constant would also result in
> >>>>> DCO kicking in and removing a fair amount of code?  So even if you
> >>>>> have enabled everything in Kconfig, the resulting hypervisor would
> >>>>> only be suitable to be used as a shim?
> >>>>
> >>>> Of course.
> >>>
> >>> Then what's the point of this approach?  Options will be enabled in
> >>> Kconfig, but the resulting hypervisor build when using allyesconfig
> >>> would have a lot of them short-circuited, making it even worse than
> >>> currently?  As options will get effectively build-time disabled due
> >>> to DCO while enabled in Kconfig.
> >>
> >> Well, I have to direct this question to Andrew. It is specifically
> >> what I'm trying to address with UNCONSTRAINED.
> >>
> >>> Overall I think PV_SHIM_EXCLUSIVE should be excluded from
> >>> allyesconfig, even with Andrew's proposed change.  Otherwise the
> >>> purpose of allyesconfig is defeated if enabling PV_SHIM_EXCLUSIVE
> >>> makes the resulting hypervisor build PV shim only.  IIRC we can
> >>> provide a default alllyes.config with CONFIG_PV_SHIM_EXCLUSIVE=n.
> >>
> >> Hmm, I wasn't aware of the option of using allyes.config. That might be
> >> the route to go, albeit it looks like people using the allyesconfig
> >> target then need to remember to set KCONFIG_ALLCONFIG in the environment
> >> (to <empty> or 1), or to explicitly specify a file name that way. (This
> >> of course ought to be easy enough to arrange for in our automation.)
> > 
> > My knowledge of Kconfig is very limited, but isn't there a default
> > path for such file to be picked up by Kconfig?  I see we already have
> > a xen/tools/kconfig/allrandom.config, I was expecting it would be a
> > matter of dropping an allyes.config in that directory, but I haven't
> > tried.
> 
> Well, I simply looked at the kconfig sources, and my reading of it is
> that it won't even try to open allyes.config when the envvar is absent.

Reading the thread, I think that:

- using allyes.config as Roger suggested
- arranging for KCONFIG_ALLCONFIG to be set as needed
- leaving PV_SHIM_EXCLUSIVE as is

is the simplest way forward
--8323329-1937431721-1737582639=:11086--


From xen-devel-bounces@lists.xenproject.org Thu Jan 23 00:35:48 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 00:35:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876056.1286429 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1talBw-00023O-8l; Thu, 23 Jan 2025 00:35:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876056.1286429; Thu, 23 Jan 2025 00:35:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1talBw-00023H-65; Thu, 23 Jan 2025 00:35:28 +0000
Received: by outflank-mailman (input) for mailman id 876056;
 Thu, 23 Jan 2025 00:35:27 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=MzGd=UP=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1talBu-00023B-Ui
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 00:35:26 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id eec8d08f-d921-11ef-99a4-01e77a169b0f;
 Thu, 23 Jan 2025 01:35:24 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 17B285C5644;
 Thu, 23 Jan 2025 00:34:42 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7A86BC4CED2;
 Thu, 23 Jan 2025 00:35:21 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: eec8d08f-d921-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1737592522;
	bh=J6KuCRfbMk94xpsEV0S1mHtmAQmCSAimuwcRn1vbn1s=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=U0mik1W3Mbt7ppDDxbUrofdQoFjFLXEusj0UCtsGSJyG+WmE3wOWT+tJN4l1J30LG
	 Rh3igHps7ZkUXzr1XwvP4Yy0idmU73MpYkrDMh+5FjuAIzmTcmWSlUbkAkirSYfFNR
	 WYGVKqN9lwaf0miL5V5z/Js/mUg3/1Zb1LgiMpQ1scjQEDDS9E1oz7SqkAy6Y6t6F4
	 VOyDxWlJQDrGf1jVGjlcmGF/qfQL8SB/Ek1TwgkUjr1U33fJvjFN933SQllqgISfSj
	 MwxWITkVv0vo2A7rWjM6STwxKzVBTw3UoDDG7dD15vwS1WACkaQUwebipxNZIICCBu
	 sSC+R1rnaI4/w==
Date: Wed, 22 Jan 2025 16:35:20 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: "L, John Preetham (893)" <john_preetham.l@daimlertruck.com>
cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, 
    Artem_Mygaiev@epam.com, Volodymyr_Babchuk@epam.com, sstabellini@kernel.org
Subject: Re: Request for Documentation on Bringing Up Xen on R-Car H3e
 (H3ULCB)
In-Reply-To: <FR2PPF86245AF1B81D71CF27EE705ED09B7B8E12@FR2PPF86245AF1B.DEUP281.PROD.OUTLOOK.COM>
Message-ID: <alpine.DEB.2.22.394.2501221625100.11086@ubuntu-linux-20-04-desktop>
References: <FR2PPF86245AF1B81D71CF27EE705ED09B7B8E12@FR2PPF86245AF1B.DEUP281.PROD.OUTLOOK.COM>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-329154796-1737591945=:11086"
Content-ID: <alpine.DEB.2.22.394.2501221625520.11086@ubuntu-linux-20-04-desktop>

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-329154796-1737591945=:11086
Content-Type: text/plain; CHARSET=UTF-8
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine.DEB.2.22.394.2501221625521.11086@ubuntu-linux-20-04-desktop>

Hi John,

Let me add a few people that might have more information for you on this
topic.

Typically, the minimal set of operations to get started is the
following. Build Xen from sources (hypervisor only):

export CROSS_COMPILE=/path/to/cross-compiler
export XEN_TARGET_ARCH=arm64
cd xen.git/xen; make

Use ImageBuilder to generate a U-boot boot script to start
Xen and one ore more virtual machines:
https://gitlab.com/xen-project/imagebuilder/

Here are a few links:
https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions#Building_Xen_on_ARM
https://wiki.xenproject.org/wiki/ImageBuilder
https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/Salvator-XS

I know this is for a different board (Xilinx), but it might help you
get concrete examples on how Xen is typically used:
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/2451243106/Building+Xen+Hypervisor+with+PetaLinux+2022.1

People in CC might be able to give you additional material specific to
R-Car H3e.

Cheers,

Stefano


On Wed, 22 Jan 2025, L, John Preetham (893) wrote:
> Dear Xen Community,
> 
> I hope this message finds you well.
> 
> I am currently working on a project that involves bringing up Xen on the Renesas R-Car H3e (H3ULCB) platform. I am seeking guidance on
> where I can find the proper documentation for this process. Specifically, I am looking for comprehensive documentation that covers
> everything from scratch to the end, including the required versions and any specific configurations.
> 
> Could anyone point me to the relevant resources or share any documentation that might be helpful?
> 
> Thank you in advance for your assistance.
> 
> Best regards,
> John Preetham L
> 
>  
> 
> 
> If you are not the addressee, please inform us immediately that you have received this e-mail by mistake, and delete it. We thank you for
> your support.
> 
> 
> 
--8323329-329154796-1737591945=:11086--


From xen-devel-bounces@lists.xenproject.org Thu Jan 23 03:52:35 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 03:52:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876076.1286439 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taoGU-0008JC-IV; Thu, 23 Jan 2025 03:52:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876076.1286439; Thu, 23 Jan 2025 03:52:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taoGU-0008J5-Fn; Thu, 23 Jan 2025 03:52:22 +0000
Received: by outflank-mailman (input) for mailman id 876076;
 Thu, 23 Jan 2025 03:52:21 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=MUd8=UP=amd.com=Jiqian.Chen@srs-se1.protection.inumbo.net>)
 id 1taoGT-0008Ij-Hx
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 03:52:21 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on2060a.outbound.protection.outlook.com
 [2a01:111:f403:2413::60a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 70bda8f3-d93d-11ef-a0e5-8be0dac302b0;
 Thu, 23 Jan 2025 04:52:19 +0100 (CET)
Received: from CH5P221CA0024.NAMP221.PROD.OUTLOOK.COM (2603:10b6:610:1f2::18)
 by DS0PR12MB9037.namprd12.prod.outlook.com (2603:10b6:8:f1::13) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8356.22; Thu, 23 Jan
 2025 03:52:14 +0000
Received: from DS3PEPF000099DE.namprd04.prod.outlook.com
 (2603:10b6:610:1f2:cafe::18) by CH5P221CA0024.outlook.office365.com
 (2603:10b6:610:1f2::18) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8356.22 via Frontend Transport; Thu,
 23 Jan 2025 03:52:14 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 DS3PEPF000099DE.mail.protection.outlook.com (10.167.17.200) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8377.8 via Frontend Transport; Thu, 23 Jan 2025 03:52:13 +0000
Received: from cjq-desktop.amd.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 22 Jan
 2025 21:50:38 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 70bda8f3-d93d-11ef-a0e5-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=weUNKG+Xx3qY42Wu5aHdUKrv0RnXOep5BTAppy8WHq7mgRCG4OWfnsWm+UuKn9KD288yUggsNRG/Wudc9Cc6kNIcE64l48o+afb/4oz9cKyP2tlQ9F4IfuVjzKFG54X3wcLxTjkCeFStM2g6FJ48Lo/gIjn+nlTCOd5NNOEGsS3De/5UMbMG/buBqiewlXeA+5SSfYswUebd36u/kB0dAuaEL9+45cZDFCkzIMZw4VImg9O6HMdoQUo9qrrFmOA9NwPs/lfGLGjjoOv1//vxyVAcVJ8Inpjj7AKERDXeRRYGrUGtAx4fiKmReU+1mOIcRNCl6LVnhgXoefnM/wprMg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=JL53AitgXp0lFybZ1hpKhN095kelGWUaiTE/qW8VedM=;
 b=Wd0dlfh0rNbYfvLkdyNeP5y8bt70v0X67wYhFP7VL0VmF6pTaox4CNL/9KeDkERbt6UbKB8ZHay6Zxrqlhr5u/pUZKcPklRXmCg5WtblexIerAPNC45CFvXAMTpUPUyJ4kZ62HCt1/Vi7C5W4q97srZfRmDt0RuXAiF6KQdiazHzCj2D/UxfMYeYdG2JyFhAmrv1n2IOHysaEvOPamJh9CV9P+VEgekYKMeObcLcWCFPbRg+NTX0Gsc0CXAqjmMP2QD+UNZxwD2JsI/hm+FVfWgsEXnjI82JcXEJ15cgkKgaVVvjJjXM0AISK3esq2l/klDfyVOHdMxM0nSkYR+P9g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=temperror (sender ip
 is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org
 smtp.mailfrom=amd.com; dmarc=temperror 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=JL53AitgXp0lFybZ1hpKhN095kelGWUaiTE/qW8VedM=;
 b=IjvBfwdm/uSZyqRJXLctmD5Wr9nLutqusBkFa8eh9acfn3sqTNiCKO5clDGfpzFAs7CJ/K7G7Gsx0dvCstB9KOo8LsgIJ7JRZK31AdOelFOo5OOu62fMalVgyJ00VDsZzTtDfI/Yfg7n+K4wwUmGYrONPOkNd0OtmD/nuidFuYA=
X-MS-Exchange-Authentication-Results: spf=temperror (sender IP is
 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=temperror action=none header.from=amd.com;
Received-SPF: TempError (protection.outlook.com: error in processing during
 lookup of amd.com: DNS Timeout)
From: Jiqian Chen <Jiqian.Chen@amd.com>
To: <xen-devel@lists.xenproject.org>
CC: =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>, Andrew Cooper
	<andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>, Julien Grall
	<julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>, Huang Rui
	<ray.huang@amd.com>, Jiqian Chen <Jiqian.Chen@amd.com>
Subject: [PATCH v6] vpci: Add resizable bar support
Date: Thu, 23 Jan 2025 11:50:03 +0800
Message-ID: <20250123035003.3797022-1-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS3PEPF000099DE:EE_|DS0PR12MB9037:EE_
X-MS-Office365-Filtering-Correlation-Id: 5aebafcc-7c94-428b-a8a2-08dd3b61523c
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|36860700013|376014|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?e15w1tMQ6W8IuhjJD1lQUSmlt9lxtVREdyy1vn2PaDoRbDjgyhFyN4P2FJ+h?=
 =?us-ascii?Q?doN85qxvGBXr+Xl6WnEVBBGfg1wDW8JUbROTu1wVT2z7IkriE0Z99LeZce+b?=
 =?us-ascii?Q?9MoXqTG5roxbfrSx2xkXBY2djbMk6oXkoC+o71NmWR7bwLpQFkW+d/I2ASno?=
 =?us-ascii?Q?gf2k0OuXQwDgSxrov34ZR5m+XzLYixV6oAkjQO747Kz1eECXgMcFiGyIKEfZ?=
 =?us-ascii?Q?lVmQ6yH8mdYpyFYbhYpQWfjZl/g/kIomvWwtk0R/MegM2SAyRKufB5B53Bae?=
 =?us-ascii?Q?Q1Ir90KMuowGxSmYvXgzSIhY8UxNF8jP7GEy2lJtBFH7vtMgdgTDbayFcD/o?=
 =?us-ascii?Q?r7cJc+f7SsFFuuMQFrj3g5pbK1Qc9B8n308T8BMX8pGyLinBTR1JlU0N5EjY?=
 =?us-ascii?Q?diqLQcG8DveftvVmqXW6hYtgxHSfzFTig+BU0Y9c4lAy9JInylkwvb1zzaND?=
 =?us-ascii?Q?pxMOWaQPhhoTIpQn4HkWx2xolejDNfYmzh8wZi8a0aX1W6CElJd8AtVG7U2U?=
 =?us-ascii?Q?YvuNQi5Qt4rc+nTkgRfx08pGFTB6pNLQ+GiIfM8DheMjHd4ROSx2/HX6/QUt?=
 =?us-ascii?Q?S5L9znoLZ/KndwFpl+pOPGIAVtAd0d9ZYxJUHcc9yvkxprQwXO6bkk77WdFF?=
 =?us-ascii?Q?hSL3zmLXUao2mmWqHggPi4Sa6ds1pnzYqmbU1x0AmsO2U3aSXd/fAGgXW4kC?=
 =?us-ascii?Q?Hb6m/M6A22I5w61eZA13PgsNxItCBoG3iw4SXbJWdZ3NEoIO8di+eBe2wFfp?=
 =?us-ascii?Q?uV5FrzUKdBp6gA113oZbWQSHeJXVxX7EaZWyktFuKQcNI03a9iJXsEONiVQH?=
 =?us-ascii?Q?90bHdXjZep4OUwyXgMfJSUj7+n4D7M+3BbXTTdgN0mYpBsihTXqox095yghu?=
 =?us-ascii?Q?xrIKa4VDFVgXKBNwKoEbuETlxNnYxe1V/yhPW4h85ktZDHtPHRuukLVBLNAf?=
 =?us-ascii?Q?1TuvmGoKxmmB83hyGOPRycqSVfH19snCmLyzyly2bn9lO94aDMXKO5sJ7O04?=
 =?us-ascii?Q?mncQjgtPCZ3qiDJLto97Vsy2MR5N2z9MZFIOEO8JLq1/4jBoLzmu4ThKiw2H?=
 =?us-ascii?Q?FV9ew0ya7uQTHl/1pC76jMriyjWUrOy2PuEANtK0P0UFHlDLM3+P+J3Lz6CM?=
 =?us-ascii?Q?NUvWDN2LOBhH4s1lkXsjv4SfEIsBOTq7c+J6rfUVK9lUoJWYBo0NOT7oe6ws?=
 =?us-ascii?Q?Jb2UMZ7eqwUgiYZ2AO+ZM8PpjT0ZC1bMq+V7BZ38RZkKpQIOyT46AYNbyTN7?=
 =?us-ascii?Q?p/PXcyrfJW1QNoALM4Y2U4JzjjPxEmkHSajK+JxoPdPOpBkYPBHOIDxuRwLb?=
 =?us-ascii?Q?P7MX/dVMMsCG5XnW88ekC5UkykwjwsQCuicfTrB8nA7q22bPn0s/N+F9BIKg?=
 =?us-ascii?Q?M8riBJpL4byuHyyksr5R4mNBOG26W+4U66/pNzWWffhOjWVAHETiMLc/6Abl?=
 =?us-ascii?Q?4BrmVMnE3GpsX9PPVI2HWtw4fB0EZhk27nfsmeUIy71tY1wjGFLEnEn97AxX?=
 =?us-ascii?Q?a/uhLAiSz+crqOw=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(376014)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jan 2025 03:52:13.2958
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 5aebafcc-7c94-428b-a8a2-08dd3b61523c
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DS3PEPF000099DE.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB9037

Some devices, like discrete GPU of amd, support resizable bar
capability, but vpci of Xen doesn't support this feature, so
they fail to resize bars and then cause probing failure.

According to PCIe spec, each bar that supports resizing has
two registers, PCI_REBAR_CAP and PCI_REBAR_CTRL. So, add
handlers for them to support resizing the size of BARs.

Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com>
---
Hi all,
v5->v6 changes:
* Changed "1UL" to "1ULL" in PCI_REBAR_CTRL_SIZE idefinition for 32 bit architecture.
* In rebar_ctrl_write used "bar - pdev->vpci->header.bars" to get index instead of reading
  from register.
* Added the index of BAR to error messages.
* Changed to "continue" instead of "return an error" when vpci_add_register failed.

Best regards,
Jiqian Chen.

v4->v5 changes:
* Called pci_size_mem_bar in rebar_ctrl_write to get addr and size of BAR instead of setting
  their values directly after writing new size to hardware.
* Changed from "return" to "continue" when index/type of BAR are not correct during initializing
  BAR.
* Corrected the value of PCI_REBAR_CTRL_BAR_SIZE from "0x00001F00" to "0x00003F00".
* Renamed PCI_REBAR_SIZE_BIAS to PCI_REBAR_CTRL_SIZE_BIAS.
* Re-defined "PCI_REBAR_CAP_SHIFT 4" to "PCI_REBAR_CAP_SIZES_MASK 0xFFFFFFF0U".

v3->v4 changes:
* Removed PCI_REBAR_CAP_SIZES since it was not needed, and added
  PCI_REBAR_CAP_SHIFT and PCI_REBAR_CTRL_SIZES.
* Added parameter resizable_sizes to struct vpci_bar to cache the support resizable sizes and
  added the logic in init_rebar().
* Changed PCI_REBAR_CAP to PCI_REBAR_CAP(n) (4+8*(n)), changed PCI_REBAR_CTRL to
  PCI_REBAR_CTRL(n) (8+8*(n)).
* Added domain info of pci_dev to printings of init_rebar().

v2->v3 changes:
* Used "bar->enabled" to replace "pci_conf_read16(pdev->sbdf, PCI_COMMAND) & PCI_COMMAND_MEMORY",
  and added comments why it needs this check.
* Added "!is_hardware_domain(pdev->domain)" check in init_rebar() to return EOPNOTSUPP for domUs.
* Moved BAR type and index check into init_rebar(), then only need to check once.
* Added 'U' suffix for macro PCI_REBAR_CAP_SIZES.
* Added macro PCI_REBAR_SIZE_BIAS to represent 20.
TODO: need to hide ReBar capability from hardware domain when init_rebar() fails.

v1->v2 changes:
* In rebar_ctrl_write, to check if memory decoding is enabled, and added
  some checks for the type of Bar.
* Added vpci_hw_write32 to handle PCI_REBAR_CAP's write, since there is
  no write limitation of dom0.
* And has many other minor modifications as well.
---
 xen/drivers/vpci/Makefile  |   2 +-
 xen/drivers/vpci/rebar.c   | 137 +++++++++++++++++++++++++++++++++++++
 xen/drivers/vpci/vpci.c    |   6 ++
 xen/include/xen/pci_regs.h |  15 ++++
 xen/include/xen/vpci.h     |   3 +
 5 files changed, 162 insertions(+), 1 deletion(-)
 create mode 100644 xen/drivers/vpci/rebar.c

diff --git a/xen/drivers/vpci/Makefile b/xen/drivers/vpci/Makefile
index 1a1413b93e76..a7c8a30a8956 100644
--- a/xen/drivers/vpci/Makefile
+++ b/xen/drivers/vpci/Makefile
@@ -1,2 +1,2 @@
-obj-y += vpci.o header.o
+obj-y += vpci.o header.o rebar.o
 obj-$(CONFIG_HAS_PCI_MSI) += msi.o msix.o
diff --git a/xen/drivers/vpci/rebar.c b/xen/drivers/vpci/rebar.c
new file mode 100644
index 000000000000..8c611cf0cd91
--- /dev/null
+++ b/xen/drivers/vpci/rebar.c
@@ -0,0 +1,137 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2025 Advanced Micro Devices, Inc. All Rights Reserved.
+ *
+ * Author: Jiqian Chen <Jiqian.Chen@amd.com>
+ */
+
+#include <xen/sched.h>
+#include <xen/vpci.h>
+
+static void cf_check rebar_ctrl_write(const struct pci_dev *pdev,
+                                      unsigned int reg,
+                                      uint32_t val,
+                                      void *data)
+{
+    struct vpci_bar *bar = data;
+    const unsigned int index = bar - pdev->vpci->header.bars;
+    uint64_t size = PCI_REBAR_CTRL_SIZE(val);
+
+    if ( bar->enabled )
+    {
+        /*
+         * Refuse to resize a BAR while memory decoding is enabled, as
+         * otherwise the size of the mapped region in the p2m would become
+         * stale with the newly set BAR size, and the position of the BAR
+         * would be reset to undefined.  Note the PCIe specification also
+         * forbids resizing a BAR with memory decoding enabled.
+         */
+        if ( size != bar->size )
+            gprintk(XENLOG_ERR,
+                    "%pp: refuse to resize BAR#%u with memory decoding enabled\n",
+                    &pdev->sbdf, index);
+        return;
+    }
+
+    if ( !((size >> PCI_REBAR_CTRL_SIZE_BIAS) & bar->resizable_sizes) )
+        gprintk(XENLOG_WARNING,
+                "%pp: new BAR#%u size %#lx is not supported by hardware\n",
+                &pdev->sbdf, index, size);
+
+    pci_conf_write32(pdev->sbdf, reg, val);
+
+    pci_size_mem_bar(pdev->sbdf,
+                     PCI_BASE_ADDRESS_0 + index * 4,
+                     &bar->addr,
+                     &bar->size,
+                     (index == PCI_HEADER_NORMAL_NR_BARS - 1) ?
+                      PCI_BAR_LAST : 0);
+    bar->guest_addr = bar->addr;
+}
+
+static int cf_check init_rebar(struct pci_dev *pdev)
+{
+    uint32_t ctrl;
+    unsigned int nbars;
+    unsigned int rebar_offset = pci_find_ext_capability(pdev->sbdf,
+                                                        PCI_EXT_CAP_ID_REBAR);
+
+    if ( !rebar_offset )
+        return 0;
+
+    if ( !is_hardware_domain(pdev->domain) )
+    {
+        printk(XENLOG_ERR "%pp: resizable BARs unsupported for unpriv %pd\n",
+               &pdev->sbdf, pdev->domain);
+        return -EOPNOTSUPP;
+    }
+
+    ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL(0));
+    nbars = MASK_EXTR(ctrl, PCI_REBAR_CTRL_NBAR_MASK);
+    for ( unsigned int i = 0; i < nbars; i++ )
+    {
+        int rc;
+        struct vpci_bar *bar;
+        unsigned int index;
+
+        ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL(i));
+        index = ctrl & PCI_REBAR_CTRL_BAR_IDX;
+        if ( index >= PCI_HEADER_NORMAL_NR_BARS )
+        {
+            printk(XENLOG_ERR "%pd %pp: too big BAR number %u in REBAR_CTRL\n",
+                   pdev->domain, &pdev->sbdf, index);
+            continue;
+        }
+
+        bar = &pdev->vpci->header.bars[index];
+        if ( bar->type != VPCI_BAR_MEM64_LO && bar->type != VPCI_BAR_MEM32 )
+        {
+            printk(XENLOG_ERR "%pd %pp: BAR%u is not in memory space\n",
+                   pdev->domain, &pdev->sbdf, index);
+            continue;
+        }
+
+        rc = vpci_add_register(pdev->vpci, vpci_hw_read32, vpci_hw_write32,
+                               rebar_offset + PCI_REBAR_CAP(i), 4, NULL);
+        if ( rc )
+        {
+            /*
+             * TODO: for failed pathes, need to hide ReBar capability
+             * from hardware domain instead of returning an error.
+             */
+            printk(XENLOG_ERR "%pd %pp: BAR%u fail to add reg of REBAR_CAP rc=%d\n",
+                   pdev->domain, &pdev->sbdf, index, rc);
+            continue;
+        }
+
+        rc = vpci_add_register(pdev->vpci, vpci_hw_read32, rebar_ctrl_write,
+                               rebar_offset + PCI_REBAR_CTRL(i), 4, bar);
+        if ( rc )
+        {
+            printk(XENLOG_ERR "%pd %pp: BAR%u fail to add reg of REBAR_CTRL rc=%d\n",
+                   pdev->domain, &pdev->sbdf, index, rc);
+            continue;
+        }
+
+        bar->resizable_sizes =
+            MASK_EXTR(pci_conf_read32(pdev->sbdf,
+                                      rebar_offset + PCI_REBAR_CAP(i)),
+                      PCI_REBAR_CAP_SIZES_MASK);
+        bar->resizable_sizes |=
+            (((uint64_t)MASK_EXTR(ctrl, PCI_REBAR_CTRL_SIZES_MASK) << 32) /
+             ISOLATE_LSB(PCI_REBAR_CAP_SIZES_MASK));
+    }
+
+    return 0;
+}
+REGISTER_VPCI_INIT(init_rebar, VPCI_PRIORITY_LOW);
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
index 1e6aa5d799b9..3349b98389b8 100644
--- a/xen/drivers/vpci/vpci.c
+++ b/xen/drivers/vpci/vpci.c
@@ -232,6 +232,12 @@ void cf_check vpci_hw_write16(
     pci_conf_write16(pdev->sbdf, reg, val);
 }
 
+void cf_check vpci_hw_write32(
+    const struct pci_dev *pdev, unsigned int reg, uint32_t val, void *data)
+{
+    pci_conf_write32(pdev->sbdf, reg, val);
+}
+
 int vpci_add_register_mask(struct vpci *vpci, vpci_read_t *read_handler,
                            vpci_write_t *write_handler, unsigned int offset,
                            unsigned int size, void *data, uint32_t ro_mask,
diff --git a/xen/include/xen/pci_regs.h b/xen/include/xen/pci_regs.h
index 250ba106dbd3..2f1d0d63e962 100644
--- a/xen/include/xen/pci_regs.h
+++ b/xen/include/xen/pci_regs.h
@@ -459,6 +459,7 @@
 #define PCI_EXT_CAP_ID_ARI	14
 #define PCI_EXT_CAP_ID_ATS	15
 #define PCI_EXT_CAP_ID_SRIOV	16
+#define PCI_EXT_CAP_ID_REBAR	21	/* Resizable BAR */
 
 /* Advanced Error Reporting */
 #define PCI_ERR_UNCOR_STATUS	4	/* Uncorrectable Error Status */
@@ -541,6 +542,20 @@
 #define  PCI_VNDR_HEADER_REV(x)	(((x) >> 16) & 0xf)
 #define  PCI_VNDR_HEADER_LEN(x)	(((x) >> 20) & 0xfff)
 
+/* Resizable BARs */
+#define PCI_REBAR_CAP(n)	(4 + 8 * (n))	/* capability register */
+#define  PCI_REBAR_CAP_SIZES_MASK	0xFFFFFFF0U	/* supported BAR sizes in CAP */
+#define PCI_REBAR_CTRL(n)	(8 + 8 * (n))	/* control register */
+#define  PCI_REBAR_CTRL_BAR_IDX		0x00000007	/* BAR index */
+#define  PCI_REBAR_CTRL_NBAR_MASK	0x000000E0	/* # of resizable BARs */
+#define  PCI_REBAR_CTRL_BAR_SIZE	0x00003F00	/* BAR size */
+#define  PCI_REBAR_CTRL_SIZES_MASK	0xFFFF0000U	/* supported BAR sizes in CTRL */
+
+#define PCI_REBAR_CTRL_SIZE_BIAS	20
+#define PCI_REBAR_CTRL_SIZE(v) \
+            (1ULL << (MASK_EXTR(v, PCI_REBAR_CTRL_BAR_SIZE) \
+                      + PCI_REBAR_CTRL_SIZE_BIAS))
+
 /*
  * Hypertransport sub capability types
  *
diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h
index 41e7c3bc2791..9d47b8c1a50e 100644
--- a/xen/include/xen/vpci.h
+++ b/xen/include/xen/vpci.h
@@ -78,6 +78,8 @@ uint32_t cf_check vpci_hw_read32(
     const struct pci_dev *pdev, unsigned int reg, void *data);
 void cf_check vpci_hw_write16(
     const struct pci_dev *pdev, unsigned int reg, uint32_t val, void *data);
+void cf_check vpci_hw_write32(
+    const struct pci_dev *pdev, unsigned int reg, uint32_t val, void *data);
 
 /*
  * Check for pending vPCI operations on this vcpu. Returns true if the vcpu
@@ -100,6 +102,7 @@ struct vpci {
             /* Guest address. */
             uint64_t guest_addr;
             uint64_t size;
+            uint64_t resizable_sizes;
             struct rangeset *mem;
             enum {
                 VPCI_BAR_EMPTY,
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 23 09:01:38 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 09:01:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876098.1286450 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tat5W-0003E2-Hb; Thu, 23 Jan 2025 09:01:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876098.1286450; Thu, 23 Jan 2025 09:01:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tat5W-0003Dv-D8; Thu, 23 Jan 2025 09:01:22 +0000
Received: by outflank-mailman (input) for mailman id 876098;
 Thu, 23 Jan 2025 09:01:21 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Lw3w=UP=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tat5V-0003Dp-AO
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 09:01:21 +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 9b218580-d968-11ef-99a4-01e77a169b0f;
 Thu, 23 Jan 2025 10:01:17 +0100 (CET)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-5d3f57582a2so3824202a12.1
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 01:01:17 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5db73edce5csm9789295a12.75.2025.01.23.01.01.14
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 23 Jan 2025 01:01:15 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9b218580-d968-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737622877; x=1738227677; 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=XB00nACidL2dpJz4IlvCpGEqsXYyoGUAUemDPBhT2Co=;
        b=Bb4NgSu6qzmwEluKb6CL9FTI06VeOHjMNQafkiMhABF4NR7MKZWsDlu3GK3iGgsuym
         sWrmvgjuxDA9OIIJpn0oed/cyEi1FcuiAyzP7yz7yaFW1fPseDd8MCMgySpemtNmDF8f
         +ufPb3qWwZCT9WkRXQzVSo0I5x15kmAkSDhPc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737622877; x=1738227677;
        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=XB00nACidL2dpJz4IlvCpGEqsXYyoGUAUemDPBhT2Co=;
        b=ACaZQuj22j9yzu/wQQmKuerGk1VujlOuh3nGdTZ4oDt1CszCFxrxsJr9HzcUrTF6Gb
         OdPXu7otY+MehmmeHVERlIh7xg3NuKScMT73TVNTJ6GVBfHxOlBaTlbsFny7EllfhuyC
         KSewZfN2xLBTB2V/4dNFpZmfxwwT+DqpAg2HVJig7410Dmywl+oNkXjpQMrywUQc83tE
         m0Gii1jDONTJu5UoXCKoO7OzgtOMuyn41thTh0QSHmqmwgJ7qF5dpTwS2NSOdoXzfrG7
         XjpPP1MfpD79RC2n0Zuoj6y1y59Lzi2CPv49ugVexvWOboF+sOHbhYUglH+Byix/jlYk
         q0mg==
X-Gm-Message-State: AOJu0YwMGbhxxkWvs/KSF7lFhE9BLvTbh8B5ecFon4Wz8ONXB38affL6
	Xy7gxPxxATYdXPqgSgFaLwylZpCYbW7gWH71ZO+PLnq69dntWSyHpP/c647Z1DiA/LhIzYPvBQ/
	+
X-Gm-Gg: ASbGncsjCPV5nNQnhZZ+x8TFZzEa/C0dtBfA0o5g2jDkxWtlF6wilVJxZq2VarMUfL8
	RWBgLpYGDxTWHu7N778W/DAY4htQLANmCvKCPWPoc5K6/zrEeBdDOEGbz0kdk/PLMwdNang89RF
	TBV+8v9rXPw4pK1rG0GGNVUmann63svhfJWk4hLdH4P3glj/CdvqvDbew8yslbDY0k08vrKZds3
	oyGkgbcPSJbqSzkNZOReWepHJ3bOiQzPNMSnGdDwkygyONckRyUN+aOw6rhFrKNBFxj32Ra+6UH
	VOZIXlQZoQ==
X-Google-Smtp-Source: AGHT+IEly179ZaUSyz8Nfztfxuu1Cq6grlYUNtG9rotB7W/odsTFfibIemalY8EgsHCiWn9glQbo1g==
X-Received: by 2002:a05:6402:5211:b0:5d3:d79a:6d6d with SMTP id 4fb4d7f45d1cf-5dc07c07084mr2093354a12.0.1737622876927;
        Thu, 23 Jan 2025 01:01:16 -0800 (PST)
Date: Thu, 23 Jan 2025 10:01:13 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v2 5/5] x86/HVM: drop redundant access splitting
Message-ID: <Z5IFWQLbhCBk4XxY@macbook.local>
References: <3294f629-f91f-4b5d-9eb0-40a34aa2ec3e@suse.com>
 <7d73f0c5-3d16-4cf3-b8de-e45f539e8916@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <7d73f0c5-3d16-4cf3-b8de-e45f539e8916@suse.com>

On Tue, Oct 01, 2024 at 10:50:25AM +0200, Jan Beulich wrote:
> With all paths into hvmemul_linear_mmio_access() coming through
> linear_{read,write}(), there's no need anymore to split accesses at
> page boundaries there. Leave an assertion, though.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> v2: Replace ASSERT() by more safe construct.
> 
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -1084,7 +1084,7 @@ static int hvmemul_linear_mmio_access(
>  {
>      struct hvm_vcpu_io *hvio = &current->arch.hvm.hvm_io;
>      unsigned long offset = gla & ~PAGE_MASK;
> -    unsigned int chunk, buffer_offset = gla - start;
> +    unsigned int buffer_offset = gla - start;
>      struct hvm_mmio_cache *cache = hvmemul_find_mmio_cache(hvio, start, dir,
>                                                             buffer_offset);
>      paddr_t gpa;
> @@ -1094,13 +1094,17 @@ static int hvmemul_linear_mmio_access(
>      if ( cache == NULL )
>          return X86EMUL_UNHANDLEABLE;
>  
> -    chunk = min_t(unsigned int, size, PAGE_SIZE - offset);
> +    if ( size > PAGE_SIZE - offset )

FWIW, I find this easier to read as `size + offset > PAGE_SIZE` (which
is the same condition used in linear_{read,write}().

Preferably with that adjusted:

Acked-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jan 23 09:20:22 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 09:20:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876105.1286460 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tatNq-0005uW-W3; Thu, 23 Jan 2025 09:20:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876105.1286460; Thu, 23 Jan 2025 09:20:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tatNq-0005uP-TT; Thu, 23 Jan 2025 09:20:18 +0000
Received: by outflank-mailman (input) for mailman id 876105;
 Thu, 23 Jan 2025 09:20: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 <SRS0=nhpA=UP=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tatNp-0005uH-HJ
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 09:20:17 +0000
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com
 [2a00:1450:4864:20::436])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 412af8c0-d96b-11ef-99a4-01e77a169b0f;
 Thu, 23 Jan 2025 10:20:15 +0100 (CET)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-3863494591bso288800f8f.1
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 01:20:15 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38bf322a414sm18564375f8f.47.2025.01.23.01.20.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 23 Jan 2025 01:20:14 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 412af8c0-d96b-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737624014; x=1738228814; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=7Jr2azDodMzgBejAO0xKx87ZKSMbgFNXoTP8dfxn3n0=;
        b=MEBLdM1Eu/vpy/uZAujmarhnSuiOOX0g3pkT79KasqRNJkEqPFE6zg57Nb+lP7QXer
         8nDaYhCbg7a8PqhZcP8vZf1KK2D0dTh06PsEjtw7qKHUriy5ujg3DunhznF+oVwzMpQg
         jYty7PfADsZjBj7ywGqUP8hPrhOPyiMBtKG5SxSKL6UZaY6aEM5Dm6E2SMoKHBRdrTSw
         bTiGj8gyEZdtqtZEgGpHyA6+GrXMzmjYqZ6ig5e9FdUDH3x3ileiTd4iZexbLc+k51ns
         87FCsaGlYAjxoVEyuxCUU1RfoCOUH/ARCM/i536fOMpjgP70XxYXjyPI458YY0yYNHYg
         do3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737624014; x=1738228814;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=7Jr2azDodMzgBejAO0xKx87ZKSMbgFNXoTP8dfxn3n0=;
        b=swABlaFoqfJUIIMauyr3YQtlPGWJYqRQuPMO+fXuaWzIO97CUl74CvoV/SlOx9Cw5e
         HX37dpu/J+ybD229QLtwwZLXdYa+UF/M3fUJFOTLI/WzWbYJa/HrDsi5YYKlKSUGZ0aE
         EQ6u4GY1qZNJoFkrbbcGkifwmxkhqz6L48vS5ZTxyloV/c4DwE+wUy7iHlVUarYCVOwN
         9E1VHYMiixKvI83kHh+NBrVSIiV9FY2HZ9hYx9w7W+s1vxP6TY1k5WvoAUEhgimp6WzJ
         PCjklXGp6XBtsUiWc5rHeFvHspS5qb8CcF90sUmUiRFfZP7gn8miNPfeYYKlnRFufRf3
         Huxg==
X-Gm-Message-State: AOJu0YxzwF4RboMuyub6Pkqp5MQCwOH4ya2/DrYpul6mjSbArQOczkIk
	lCD0fJY5XS2wSAs9USjF3WG4JwtrTTUurZ409X3KJPXSGQUNMlkkCf3HqLqbn7rCYWA5pnnDSzQ
	=
X-Gm-Gg: ASbGncupF3qYHSofgAXKc0ojO+TOgr8j08SQOXts/zQs94yBtbgK6uxg2eCSI0Hsvvx
	dFKWc2Dr+yfQr1pMhcik/vC0EAmbvDUKvSlTqjYu9u/92CDfhwWmUlG2U13X3xSMiqLKOaUoBmP
	TCIpH+DQMRVVXb0415ZPD38VYEbYsgCl8ptqiSj/PdEXmbGFpMWCHm3WPm6jHbEEbLgqr19pCaC
	UPc8Bp7PkGAnz7YEnDPoyL0z4ENX8Z3uYnKhNd+4y00BYXisp/UcDNYh/Oug4sDOymjQqYXY9X5
	kYE9v2w3HPPNpQeXgs+pe/mVQ/V+URtgp5R9PmTg7UeabSW+pAIqmf9Xm01+QBZtVg==
X-Google-Smtp-Source: AGHT+IHFvdM5nj6TnqemPiCW+JaNkfkCElKyd/v0ROFo6tSquTBY0tdUFw1lERpTZz+oBR4qByaQbA==
X-Received: by 2002:a5d:59ad:0:b0:38b:ed7b:f78c with SMTP id ffacd0b85a97d-38bf566f41cmr21752445f8f.6.1737624014507;
        Thu, 23 Jan 2025 01:20:14 -0800 (PST)
Message-ID: <600c8bee-a6fd-41df-82bf-60ec15fec42c@suse.com>
Date: Thu, 23 Jan 2025 10:20:13 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 5/5] x86/HVM: drop redundant access splitting
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
References: <3294f629-f91f-4b5d-9eb0-40a34aa2ec3e@suse.com>
 <7d73f0c5-3d16-4cf3-b8de-e45f539e8916@suse.com>
 <Z5IFWQLbhCBk4XxY@macbook.local>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <Z5IFWQLbhCBk4XxY@macbook.local>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 23.01.2025 10:01, Roger Pau Monné wrote:
> On Tue, Oct 01, 2024 at 10:50:25AM +0200, Jan Beulich wrote:
>> --- a/xen/arch/x86/hvm/emulate.c
>> +++ b/xen/arch/x86/hvm/emulate.c
>> @@ -1084,7 +1084,7 @@ static int hvmemul_linear_mmio_access(
>>  {
>>      struct hvm_vcpu_io *hvio = &current->arch.hvm.hvm_io;
>>      unsigned long offset = gla & ~PAGE_MASK;
>> -    unsigned int chunk, buffer_offset = gla - start;
>> +    unsigned int buffer_offset = gla - start;
>>      struct hvm_mmio_cache *cache = hvmemul_find_mmio_cache(hvio, start, dir,
>>                                                             buffer_offset);
>>      paddr_t gpa;
>> @@ -1094,13 +1094,17 @@ static int hvmemul_linear_mmio_access(
>>      if ( cache == NULL )
>>          return X86EMUL_UNHANDLEABLE;
>>  
>> -    chunk = min_t(unsigned int, size, PAGE_SIZE - offset);
>> +    if ( size > PAGE_SIZE - offset )
> 
> FWIW, I find this easier to read as `size + offset > PAGE_SIZE` (which
> is the same condition used in linear_{read,write}().

Hmm, yes, considering that "size" here is specifically what "bytes" is there,
doing the change is okay. However, in general I prefer the way it was written
above, for being more obviously safe against overflow (taking into account
how "offset" is calculated).

> Preferably with that adjusted:
> 
> Acked-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 23 09:49:47 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 09:49:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876111.1286469 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tatqG-0000gA-Qi; Thu, 23 Jan 2025 09:49:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876111.1286469; Thu, 23 Jan 2025 09:49:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tatqG-0000g3-OB; Thu, 23 Jan 2025 09:49:40 +0000
Received: by outflank-mailman (input) for mailman id 876111;
 Thu, 23 Jan 2025 09:49: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 <SRS0=nhpA=UP=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tatqF-0000fx-IT
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 09:49:39 +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 5befa02f-d96f-11ef-a0e5-8be0dac302b0;
 Thu, 23 Jan 2025 10:49:38 +0100 (CET)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-437a92d7b96so6760905e9.2
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 01:49: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
 5b1f17b1804b1-438b31ddef8sm54926105e9.35.2025.01.23.01.49.36
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 23 Jan 2025 01:49:36 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5befa02f-d96f-11ef-a0e5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737625777; x=1738230577; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=1LygtcFDAU1z8CMYGmvaUpsVoDP57AchSXyWewGKPgM=;
        b=MGaa2OYIoVqkVpqwF7ndQo4ktMPv7GJb47cnu/yfHToWna+CKf2okGgDXW7iq732Sz
         t2gy4sLGlNJMWSNHHyd1RLUyLV0ajJv5vayEYSF52ZJpy46U440YtxG8omIwjE8D/M+r
         FVAcx68bYhdjHsDv8WfLlrtRADW9813cd01zxPdJXTlJ1XaOoJUzA1wysIJ7As3pzBMB
         bIRfIi//zs16K2a3cWpZ4WXxe85YVNtlmj8IUhp5HrqziIn8G5rhvZlrppTanOt/XB+9
         8nX2W76x4GOmNJ9E8U41AHSBIqe5g02CfwXQul2qyW7XHnWlLp8jDcc44BzNXQJ6yL+P
         ITSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737625777; x=1738230577;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=1LygtcFDAU1z8CMYGmvaUpsVoDP57AchSXyWewGKPgM=;
        b=HmHNN363FbCPfV3i3+7NXTIWPorROoGkqY1OdOGHVAA9SGB5LbgTd+JplWigmKh7Rd
         7OupjxEtZlPjFp14kIa1ulwGV/Av1U/ruWHzSZq3/aRFOudoLx/lTTAH9UR2Zdvn9Ojc
         O7aum1Tw2zXXHYDom2gxwdEbi03i3PYey2iY9u5UvYRySZK1o9btc+zfyZaRD5GxsTg4
         kDFPFSWBTNXDdTQTaA+zDB+u9j2kOIYmeZ3/VSREdrWYsv6w39yr1XCSq0tjXQ41QTxL
         YJoJtorV8cRLcyxgu/cQo7JjnTQ2d9gFPBDEUqGJzCMOm72nJ2friAFnojcXmtpgRTpr
         CVzA==
X-Gm-Message-State: AOJu0YwI3aIBj9oCrIIRh1zHrDIZdXnjAZp0zkFDuYnVY6qd/l3wRVle
	5Cw7S3h8yJk5Mpt0qfvKs5qi2JE9tsOtt5XfuRYc33gRm+siLy4hh2fzRlhiPA==
X-Gm-Gg: ASbGncvnSUadtI2WW7vF+Fd8LnfBwjd1zd+VhBG8/u//rEyDKJx/7DfzR1UqH3NUJjq
	pVhw26c/PoSJUlD+wVV1iDC4EKbVCxAKTStSdntenc0QwqcUEL21XIjPGXO4baHM941wocJYMo3
	NLEDvCOGcPfWfl8KZyOJKOqyXriHhVR2b6IeVHyoG1szZQ9sFw9R2Iov7J424lxET0B2OuHXY3+
	mIt92s+j7M9iWElJIPR0U8XEcd0a36wI+h/ciTzf0v2xZ+PCgWLZ5LaeutNRLB2IBFRj1dXI4lW
	pkzYX3r1dTXr/45z7cmoyqpQOwHfFI9OMOipTU9Z4Z/YBE8zp2w6mx2vrEXcvMCKUA==
X-Google-Smtp-Source: AGHT+IE4LxbkZ37r/V0zkEhESf7PJtGARK5SXTxdC+coikfBbCF9o4g6uesG5UofvLK7HTsz1BXSnw==
X-Received: by 2002:a05:600c:1f8c:b0:436:fb02:e90 with SMTP id 5b1f17b1804b1-438913cdaa8mr271546785e9.10.1737625777235;
        Thu, 23 Jan 2025 01:49:37 -0800 (PST)
Message-ID: <41e6c4a5-d5c4-40a2-a8c6-f6b5bba70f8c@suse.com>
Date: Thu, 23 Jan 2025 10:49:36 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/5] x86/HVM: correct read/write split at page
 boundaries
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Manuel Andreas <manuel.andreas@tum.de>
References: <3294f629-f91f-4b5d-9eb0-40a34aa2ec3e@suse.com>
 <fde70079-4084-4aa6-b76e-becd62a71ddb@suse.com>
 <Z5Euyc91PZsyMP6f@macbook.local>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <Z5Euyc91PZsyMP6f@macbook.local>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 22.01.2025 18:45, Roger Pau Monné wrote:
> On Tue, Oct 01, 2024 at 10:49:40AM +0200, Jan Beulich wrote:
>> The MMIO cache is intended to have one entry used per independent memory
>> access that an insn does. This, in particular, is supposed to be
>> ignoring any page boundary crossing. Therefore when looking up a cache
>> entry, the access'es starting (linear) address is relevant, not the one
>> possibly advanced past a page boundary.
>>
>> In order for the same offset-into-buffer variable to be usable in
>> hvmemul_phys_mmio_access() for both the caller's buffer and the cache
>> entry's it is further necessary to have the un-adjusted caller buffer
>> passed into there.
>>
>> Fixes: 2d527ba310dc ("x86/hvm: split all linear reads and writes at page boundary")
>> Reported-by: Manuel Andreas <manuel.andreas@tum.de>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> ---
>> This way problematic overlaps are only reduced (to ones starting at the
>> same address), not eliminated: Assumptions in hvmemul_phys_mmio_access()
>> go further - if a subsequent access is larger than an earlier one, but
>> the splitting results in a chunk to cross the end "boundary" of the
>> earlier access, an assertion will still trigger. Explicit memory
>> accesses (ones encoded in an insn by explicit or implicit memory
>> operands) match the assumption afaict (i.e. all those accesses are of
>> uniform size, and hence they either fully overlap or are mapped to
>> distinct cache entries).
>>
>> Insns accessing descriptor tables, otoh, don't fulfill these
>> expectations: The selector read (if coming from memory) will always be
>> smaller than the descriptor being read, and if both (insanely) start at
>> the same linear address (in turn mapping MMIO), said assertion will kick
>> in. (The same would be true for an insn trying to access itself as data,
>> as long as certain size "restrictions" between insn and memory operand
>> are met. Except that linear_read() disallows insn fetches from MMIO.) To
>> deal with such, I expect we will need to further qualify (tag) cache
>> entries, such that reads/writes won't use insn fetch entries, and
>> implicit-supervisor-mode accesses won't use entries of ordinary
>> accesses. (Page table accesses don't need considering here for now, as
>> our page walking code demands page tables to be mappable, implying
>> they're in guest RAM; such accesses also don't take the path here.)
>> Thoughts anyone, before I get to making another patch?
>>
>> Considering the insn fetch aspect mentioned above I'm having trouble
>> following why the cache has 3 entries. With insn fetches permitted,
>> descriptor table accesses where the accessed bit needs setting may also
>> fail because of that limited capacity of the cache, due to the way the
>> accesses are done. The read and write (cmpxchg) are independent accesses
>> from the cache's perspective, and hence we'd need another entry there.
>> If, otoh, the 3 entries are there to account for precisely this (which
>> seems unlikely with commit e101123463d2 ["x86/hvm: track large memory
>> mapped accesses by buffer offset"] not saying anything at all), then we
>> should be fine in this regard. If we were to permit insn fetches, which
>> way to overcome this (possibly by allowing the write to re-use the
>> earlier read's entry in this special situation) would remain to be
>> determined.
> 
> I'm not that familiar with the emulator logic for memory accesses, but
> it seems like we are adding more and more complexity and special
> casing.  Maybe it's the only way to go forward, but I wonder if there
> could be some other way to solve this.  However, I don't think I
> will have time to look into it, and hence I'm not going to oppose to
> your proposal.

I'll see what I can do; it's been quite a while, so I'll first need to
swap context back in.

> Are there however some tests, possibly XTF, that we could use to
> ensure the behavior of accesses is as we expect?

Manuel's report included an XTF test, which I expect will become a part
of XTF once this fix went in. I fear though that there is an issue
Andrew has been pointing out, which may prevent this from happening
right away (even if with osstest having disappeared that's now only a
latent issue, until gitlab CI would start exercising XTF): With the
issue unfixed on older trees (i.e. those remaining after this series
was backported as appropriate), the new test would fail there.

>> @@ -1030,7 +1040,11 @@ static struct hvm_mmio_cache *hvmemul_fi
>>              return cache;
>>      }
>>  
>> -    if ( !create )
>> +    /*
>> +     * Bail if a new entry shouldn't be allocated, utilizing that ->space has
>                                                       ^rely on ->space having ...
> Would be easier to read IMO.

Changed; I'm not overly fussed, yet at the same time I also don't really
agree with your comment.

>> @@ -1064,12 +1079,14 @@ static void latch_linear_to_phys(struct
>>  
>>  static int hvmemul_linear_mmio_access(
>>      unsigned long gla, unsigned int size, uint8_t dir, void *buffer,
>> -    uint32_t pfec, struct hvm_emulate_ctxt *hvmemul_ctxt, bool known_gpfn)
>> +    uint32_t pfec, struct hvm_emulate_ctxt *hvmemul_ctxt,
>> +    unsigned long start, bool known_gpfn)
> 
> I think start is a bit ambiguous, start_gla might be clearer (same
> below for the start parameter).

Fine with me - changed for all three hvmemul_linear_mmio_*(). It wasn't
clear to me whether you also meant the local variables in
linear_{read,write}(); since you said "parameter" I assumed you didn't.
If you did, I fear I'd be less happy to make the change there too, for
"addr" then preferably also wanting to change to "gla". Yet that would
cause undue extra churn.

>> @@ -1182,8 +1202,17 @@ static int linear_read(unsigned long add
>>       * an access that was previously handled as MMIO. Thus it is imperative that
>>       * we handle this access in the same way to guarantee completion and hence
>>       * clean up any interim state.
>> +     *
>> +     * Care must be taken, however, to correctly deal with crossing RAM/MMIO or
>> +     * MMIO/RAM boundaries. While we want to use a single cache entry (tagged
>> +     * by the starting linear address), we need to continue issuing (i.e. also
>> +     * upon replay) the RAM access for anything that's ahead of or past MMIO,
>> +     * i.e. in RAM.
>>       */
>> -    if ( !hvmemul_find_mmio_cache(hvio, addr, IOREQ_READ, false) )
>> +    cache = hvmemul_find_mmio_cache(hvio, start, IOREQ_READ, ~0);
>> +    if ( !cache ||
>> +         addr + bytes <= start + cache->skip ||
>> +         addr >= start + cache->size )
> 
> Seeing as this bound checks is also used below, could it be a macro or
> inline function?
> 
> is_cached() or similar?

Hmm. Yes, it's twice the same expression, yet that helper would require
four parameters. That's a little too much for my taste; I'd prefer to
keep things as they are. After all there are far more redundancies between
the two functions.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 23 10:29:24 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 10:29:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876123.1286484 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tauSY-0006H2-RE; Thu, 23 Jan 2025 10:29:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876123.1286484; Thu, 23 Jan 2025 10:29:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tauSY-0006Gv-Nh; Thu, 23 Jan 2025 10:29:14 +0000
Received: by outflank-mailman (input) for mailman id 876123;
 Thu, 23 Jan 2025 10:29: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 <SRS0=nhpA=UP=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tauSX-0006Gp-LK
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 10:29:13 +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 e21233f6-d974-11ef-99a4-01e77a169b0f;
 Thu, 23 Jan 2025 11:29:10 +0100 (CET)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-436326dcb1cso4893215e9.0
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 02:29: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
 5b1f17b1804b1-438b31a2f1csm56269805e9.16.2025.01.23.02.29.09
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 23 Jan 2025 02:29:09 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e21233f6-d974-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737628150; x=1738232950; darn=lists.xenproject.org;
        h=content-transfer-encoding:autocrypt:content-language:cc:to:subject
         :from:user-agent:mime-version:date:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=oGEr3K/NMquYqgIavb4yV6pdTbdvdJ2f1hsdj+0wTMY=;
        b=dZotmasu9orpN2mdcM0GisPIaRuKtbURwFEn/Z9kV6qOQtqdnWmz5N/WeGklwDUPno
         BM3fXQwn/m63AxR5x5fCtldgtOZJHP6KqzIyKVZhHWtux1rCpBPAw+Bhetb8+yWBIzxi
         yvxy9DW/3kC4Rm0HyHR+AdYjoeLnhKBSqZyiVaBEXRr1QD3glVeSFK9580+usDC3sX3H
         1PslBbUrqlDjWmsSC+drSwz15epQhGgxiALBg3up11+nWua1p6K7zX+pH+CgcjEPLHLP
         R4VRrUSS4UfJpIXWWAzwhgwaAdDmFN/HrvP4hHhk83h1/K1mOCi7w8T/R0ed1jHSCNhr
         cxBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737628150; x=1738232950;
        h=content-transfer-encoding:autocrypt:content-language:cc:to:subject
         :from:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=oGEr3K/NMquYqgIavb4yV6pdTbdvdJ2f1hsdj+0wTMY=;
        b=sYJ4k8CaDpG/rPfr9G40R87EcbaBvky2gEsGjYSvRzHCCUUzSHwYopchsQbxgJxbvk
         CvebFC8Y/4N7VwK+wF1c1/zHPN49pqSwsSCd50WgVyi24Z+cTVWHl23ppKH30OQQvqBE
         CRlVwt+VJ+e8Rd+bAeP2rzkJKsPvWetHAwG3m/kS3hDIpT5zNoGTwVtuAzV3n4f7k4uw
         RjDG19q6ekJRK4yNgW4ZpqM3vKxA+fqZylWkiy/LFadIqPRpwN4YcqM89Txsjpcfiigu
         HSoGk48HRo5brN05wha3XuK8TBm7BrfO61MgIjC7ki2kNAuEMZTU+BC+mGiYxfZkXLxd
         ae3w==
X-Gm-Message-State: AOJu0YwOrOdolsi17WCAKW8V6dcTJE1UVCba4MsdAyDL2fkh60yyioAB
	IJwg6svxlqhmdzyBImBEelLc3zSKRW2FqbSFANrHkJfnnywhKeyqnQP0O8fjodwDqKQsrFPSjxc
	=
X-Gm-Gg: ASbGnctLqFmhHhUoHrEELEIH4fneJzWmVRp+uOpV2d7PoJJL2IwPKZ6RkJ24Ft4ChwP
	UPy0x48eolQNZ3TbFejyVfsRZEKUOsoRBAbffoASgPejh0RbKLSY8m8EqueNwnceq9mtEB2DG66
	bW/K8ZsruKCVj/8SPbon0G6FdBg3oOgl+5hoaJGdMUIHKSCgclYCZRxI/IKqQcOs4qJg2JUaa6F
	CDaVMM6udPNOQ/urk0gmZsNOTRwMS2spvnmfnLd6jwoQAtKh9gbH3lKqc94qc5Hhu1dnTLD7LN6
	KFyp2J1KpYc9JZ86dLrbj0VD179qxyQxWBgUZsyrHj12y1+a1bFPquO5jPoHJLHGew==
X-Google-Smtp-Source: AGHT+IEgtTcmiKl60UpMd2W1xasleROL44TM3ovPnClsMMq8VupTMqxcN31MVznsWj/2RdS2KtPZDA==
X-Received: by 2002:a7b:c8c9:0:b0:436:fb02:e68 with SMTP id 5b1f17b1804b1-438913bdd6cmr229021215e9.2.1737628149981;
        Thu, 23 Jan 2025 02:29:09 -0800 (PST)
Message-ID: <729f7896-55b7-4b5b-a7e9-6eb0420e0b14@suse.com>
Date: Thu, 23 Jan 2025 11:29:08 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH partly-for-4.20 v3 0/4] x86/HVM: emulation (MMIO) improvements
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

The main fix is patch 2, with the earlier patch setting the stage and
the latter ones simplifying other things at least a little in exchange.

1: allocate emulation cache entries dynamically
2: correct read/write split at page boundaries
3: slightly improve CMPXCHG16B emulation
4: drop redundant access splitting

Oleksii - the first two patches (plus the simple one from v2 that I just
committed) are backporting material, and hence I'd like to ask for a
release ack for at least those two.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 23 10:30:52 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 10:30:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876134.1286493 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tauTy-0007uX-8g; Thu, 23 Jan 2025 10:30:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876134.1286493; Thu, 23 Jan 2025 10:30:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tauTy-0007uQ-5z; Thu, 23 Jan 2025 10:30:42 +0000
Received: by outflank-mailman (input) for mailman id 876134;
 Thu, 23 Jan 2025 10:30:41 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=nhpA=UP=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tauTx-0007uI-33
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 10:30:41 +0000
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com
 [2a00:1450:4864:20::32d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 16e4e21a-d975-11ef-99a4-01e77a169b0f;
 Thu, 23 Jan 2025 11:30:39 +0100 (CET)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-438a39e659cso4529765e9.2
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 02:30:39 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438b171e68bsm48604425e9.0.2025.01.23.02.30.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 23 Jan 2025 02:30:38 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 16e4e21a-d975-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737628238; x=1738233038; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=dsMqFHxJXXNO39LKNvc0EVP+IRiH33FuXJ52J3jrZ40=;
        b=I3ZRcO5imDBipoP8aqzMo3mdp7sKFMay4HNGx6hDzTWSeCW9zczfswm89FmYx24zZU
         3kWV3x0Ez/WHqjwuR7DkwiSI+kBFpgsjR4fmBaJCzsG6+huV4m7rFVv5exdaVHIpuAiC
         DXiFn+tupk1gf2NVFmgWihRTz8tkMdaaTvR/HHOhCVakKcKbzH/EANQ4GAL72Y85/Bv2
         Xf2PaAEcHAIuZtVyaLHRmd/BMrj7CXRQvyxhVGBOS6cBAKNTu/eoPJqJR42ir6BOl63g
         j9LGdXmhYrYoCslvlzAXTOvxwZpDJMWSqXlDJXVewGhtNPL0B+aEA6H6Cx2mjI+kEIqN
         Tvaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737628238; x=1738233038;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=dsMqFHxJXXNO39LKNvc0EVP+IRiH33FuXJ52J3jrZ40=;
        b=RB5f9kOZMvBBARM33lTzhDFaOmyUOMndW5DbWMZNp+92QWJlmSdfmkQgVRlLR60ZLD
         sT5JnVxuPb9VLStLa0tqmt8iJ0OP/RVU6gD2+seianXyhQWVtJBbn0/Dd3m1RNHV3a44
         f0UE8UgCRU+kGTjmDdgEATNZAANeYznvvxSQAEq2zVNQo43WcTqvskqOPfqWyqoAy8VB
         o5JifdpA7a4xE/UAbJ2forHLJKenv1lfrkNcSn/V/PMTNUpvkpaVvDwUTSwGX871oDu3
         ++tHZxa4J8bxXSq3dR9BuOe9tRbXV79j3keo0Wv3gW5uTI/D1VAybSvlQhaEMBzcUzzo
         EHiQ==
X-Gm-Message-State: AOJu0Yyx40i23zcx1d3z78sHG4uj5BqisCpGPmOTcfya64+tPmlqgfdC
	rKyvlCkxUnJ4Tcgvjlup7XDNnCyDjnfvd/WqLibCNZUVvJT2hYXnHpbRfjcMZmzZkAp01zSlJpY
	=
X-Gm-Gg: ASbGncvt9BkV4O6CBHOgUrJt8P2Tp5Xa5wCmWeSZPVRJemICdPf1Q58zl5tw5DBfjPp
	UfJofPj/K9R4ryvmNFu4hFlxq8uxTjPdX7VG6X/E2MvKdBW47uvuhmHSZ8+oz781ykWxeqLqeqn
	00zZs5Vi462MmJZG5j0mBwsL+gJSLI24sYdYxHtBmwEQjjFch9CpkRyoRyJx6IpFSW5+CaWhddG
	8WVNJYpRkakrjgRd1Hn3Z3jRpaOEF4vztPH0BIXUUeH0KFZLYwmvl3FQtr23QP/canouVrNluzs
	UatXuPZpoRW/JjrlStWYGjno48Cbl3NudYcRH/NkZBkciRbpfIAy9G9tX5FN+Buupg==
X-Google-Smtp-Source: AGHT+IEPS77mTCqi+7nzIqEnDNmcmMkd52/VQSX9RGJGP+9sfTGAgRSFxmooHUE1NAh1pi9oNO8ovQ==
X-Received: by 2002:a05:600c:138f:b0:436:ed50:4f8a with SMTP id 5b1f17b1804b1-438913caeb9mr266219895e9.10.1737628238589;
        Thu, 23 Jan 2025 02:30:38 -0800 (PST)
Message-ID: <812a9d41-5b5c-49eb-8592-23a2d0ccbcfe@suse.com>
Date: Thu, 23 Jan 2025 11:30:37 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH for-4.20 v3 1/4] x86/HVM: allocate emulation cache entries
 dynamically
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>
References: <729f7896-55b7-4b5b-a7e9-6eb0420e0b14@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <729f7896-55b7-4b5b-a7e9-6eb0420e0b14@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Both caches may need higher capacity, and the upper bound will need to
be determined dynamically based on CPUID policy (for AMX'es TILELOAD /
TILESTORE at least).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
---
This is a patch taken from the AMX series, but wasn't part of the v3
submission. All I did is strip out the actual AMX bits (from
hvmemul_cache_init()), plus of course change the description. As a
result some local variables there may look unnecessary, but this way
it's going to be less churn when the AMX bits are added. The next patch
pretty strongly depends on the changed approach (contextually, not so
much functionally), and I'd really like to avoid rebasing that one ahead
of this one, and then this one on top of that.

TBD: For AMX hvmemul_cache_init() will become CPUID policy dependent. We
     could of course take the opportunity and also reduce overhead when
     AVX-512 (and maybe even AVX) is unavailable (in the future: to the
     guest).
---
v3: Use xvmalloc variants throughout. Add comments.
v2: Split off cache bounds check fix.

--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -26,6 +26,18 @@
 #include <asm/iocap.h>
 #include <asm/vm_event.h>
 
+/*
+ * We may read or write up to m512 or up to a tile row as a number of
+ * device-model transactions.
+ */
+struct hvm_mmio_cache {
+    unsigned long gla;
+    unsigned int size;     /* Amount of buffer[] actually used. */
+    unsigned int space:31; /* Allocated size of buffer[]. */
+    unsigned int dir:1;
+    uint8_t buffer[] __aligned(sizeof(long));
+};
+
 struct hvmemul_cache
 {
     /* The cache is disabled as long as num_ents > max_ents. */
@@ -935,7 +947,7 @@ static int hvmemul_phys_mmio_access(
     }
 
     /* Accesses must not overflow the cache's buffer. */
-    if ( offset + size > sizeof(cache->buffer) )
+    if ( offset + size > cache->space )
     {
         ASSERT_UNREACHABLE();
         return X86EMUL_UNHANDLEABLE;
@@ -1011,7 +1023,7 @@ static struct hvm_mmio_cache *hvmemul_fi
 
     for ( i = 0; i < hvio->mmio_cache_count; i ++ )
     {
-        cache = &hvio->mmio_cache[i];
+        cache = hvio->mmio_cache[i];
 
         if ( gla == cache->gla &&
              dir == cache->dir )
@@ -1027,10 +1039,11 @@ static struct hvm_mmio_cache *hvmemul_fi
 
     ++hvio->mmio_cache_count;
 
-    cache = &hvio->mmio_cache[i];
-    memset(cache, 0, sizeof (*cache));
+    cache = hvio->mmio_cache[i];
+    memset(cache->buffer, 0, cache->space);
 
     cache->gla = gla;
+    cache->size = 0;
     cache->dir = dir;
 
     return cache;
@@ -2980,16 +2993,21 @@ void hvm_dump_emulation_state(const char
 int hvmemul_cache_init(struct vcpu *v)
 {
     /*
-     * No insn can access more than 16 independent linear addresses (AVX512F
-     * scatters/gathers being the worst). Each such linear range can span a
-     * page boundary, i.e. may require two page walks. Account for each insn
-     * byte individually, for simplicity.
+     * AVX512F scatter/gather insns can access up to 16 independent linear
+     * addresses, up to 8 bytes size. Each such linear range can span a page
+     * boundary, i.e. may require two page walks.
+     */
+    unsigned int nents = 16 * 2 * (CONFIG_PAGING_LEVELS + 1);
+    unsigned int i, max_bytes = 64;
+    struct hvmemul_cache *cache;
+
+    /*
+     * Account for each insn byte individually, both for simplicity and to
+     * leave some slack space.
      */
-    const unsigned int nents = (CONFIG_PAGING_LEVELS + 1) *
-                               (MAX_INST_LEN + 16 * 2);
-    struct hvmemul_cache *cache = xmalloc_flex_struct(struct hvmemul_cache,
-                                                      ents, nents);
+    nents += MAX_INST_LEN * (CONFIG_PAGING_LEVELS + 1);
 
+    cache = xvmalloc_flex_struct(struct hvmemul_cache, ents, nents);
     if ( !cache )
         return -ENOMEM;
 
@@ -2999,6 +3017,15 @@ int hvmemul_cache_init(struct vcpu *v)
 
     v->arch.hvm.hvm_io.cache = cache;
 
+    for ( i = 0; i < ARRAY_SIZE(v->arch.hvm.hvm_io.mmio_cache); ++i )
+    {
+        v->arch.hvm.hvm_io.mmio_cache[i] =
+            xvmalloc_flex_struct(struct hvm_mmio_cache, buffer, max_bytes);
+        if ( !v->arch.hvm.hvm_io.mmio_cache[i] )
+            return -ENOMEM;
+        v->arch.hvm.hvm_io.mmio_cache[i]->space = max_bytes;
+    }
+
     return 0;
 }
 
--- a/xen/arch/x86/include/asm/hvm/emulate.h
+++ b/xen/arch/x86/include/asm/hvm/emulate.h
@@ -15,6 +15,7 @@
 #include <xen/err.h>
 #include <xen/mm.h>
 #include <xen/sched.h>
+#include <xen/xvmalloc.h>
 #include <asm/hvm/hvm.h>
 #include <asm/x86_emulate.h>
 
@@ -119,7 +120,11 @@ int hvmemul_do_pio_buffer(uint16_t port,
 int __must_check hvmemul_cache_init(struct vcpu *v);
 static inline void hvmemul_cache_destroy(struct vcpu *v)
 {
-    XFREE(v->arch.hvm.hvm_io.cache);
+    unsigned int i;
+
+    for ( i = 0; i < ARRAY_SIZE(v->arch.hvm.hvm_io.mmio_cache); ++i )
+        XFREE(v->arch.hvm.hvm_io.mmio_cache[i]);
+    XVFREE(v->arch.hvm.hvm_io.cache);
 }
 bool hvmemul_read_cache(const struct vcpu *v, paddr_t gpa,
                         void *buffer, unsigned int size);
--- a/xen/arch/x86/include/asm/hvm/vcpu.h
+++ b/xen/arch/x86/include/asm/hvm/vcpu.h
@@ -22,17 +22,6 @@ struct hvm_vcpu_asid {
     uint32_t asid;
 };
 
-/*
- * We may read or write up to m512 as a number of device-model
- * transactions.
- */
-struct hvm_mmio_cache {
-    unsigned long gla;
-    unsigned int size;
-    uint8_t dir;
-    uint8_t buffer[64] __aligned(sizeof(long));
-};
-
 struct hvm_vcpu_io {
     /*
      * HVM emulation:
@@ -48,7 +37,7 @@ struct hvm_vcpu_io {
      * We may need to handle up to 3 distinct memory accesses per
      * instruction.
      */
-    struct hvm_mmio_cache mmio_cache[3];
+    struct hvm_mmio_cache *mmio_cache[3];
     unsigned int mmio_cache_count;
 
     /* For retries we shouldn't re-fetch the instruction. */



From xen-devel-bounces@lists.xenproject.org Thu Jan 23 10:31:34 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 10:31:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876142.1286504 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tauUe-0008PK-Hu; Thu, 23 Jan 2025 10:31:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876142.1286504; Thu, 23 Jan 2025 10:31:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tauUe-0008PD-EP; Thu, 23 Jan 2025 10:31:24 +0000
Received: by outflank-mailman (input) for mailman id 876142;
 Thu, 23 Jan 2025 10:31:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=nhpA=UP=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tauUd-0008P3-Cr
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 10:31:23 +0000
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com
 [2a00:1450:4864:20::329])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3010be45-d975-11ef-99a4-01e77a169b0f;
 Thu, 23 Jan 2025 11:31:21 +0100 (CET)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-4361c705434so4912705e9.3
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 02:31: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
 5b1f17b1804b1-438b31d987csm56523315e9.27.2025.01.23.02.31.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 23 Jan 2025 02:31:20 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 3010be45-d975-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737628281; x=1738233081; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=u9ER73lT2NDtHVJZyG93g4NYSSRN+hnbjwdtc66+e+s=;
        b=UT5ERQQJDRgAYsY4gdFAW8+LDxVniiTAkCtGZfJRvKQYxw7arZ4GYKoMyrRgIlT8Kc
         TnX+LUAMu1iLZqv0abngP0TNd2TOYCZbFuC6dTuYq+QNGKjz+lVc6q574LfXMq5LLSHk
         aixxbd9GXE/Lbe7hh+UqBGJl2K8mHEicjuWErbHKD9u4F8nqEtOHlfD7Ibip+N0ov2zB
         OCK3pSZaF8mQXNktyeTldsbxI5nEPMtZU9TKK9shUlSv096ShCWy41zbHl5nGT3CniT7
         Xw+Q12cY3nHQWe3WThYmho0MBTISWTWYcaj773pByEB7eAZXpTkYlFc0vtcVxJaG9+7n
         Qlcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737628281; x=1738233081;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=u9ER73lT2NDtHVJZyG93g4NYSSRN+hnbjwdtc66+e+s=;
        b=Xxvl4xa4prz6f/Duc2sdReQjqJ8imG5rzyE36sd/GBcdv9wOMTR6J+M9HCqjxJS1QV
         zie9EneMFB32Sv5BgPGjrhwAzEBiR2nef8xqNw038LvB+n7v7+L4cR7CZRWjS2qcgUks
         7KiC9DeLZFUcHoH8zIJaAfaDnmlJczRJ1ycf4jhb/fM2fk1u0N/mW2U6O2n2JsUuBCFt
         3cvJ5zaAgl7yqvF0ks/SHWeHwTCfJ1rrlSn2sPjeePzIBxuGPTxdiAm44jpInSV8dVSJ
         CUbRX4TsZoEaiRrWv1DA4StJb0aywkWXY3ne0UvlWR6kLqVV1OweYAuLtdpyoToA7wLi
         ex0g==
X-Gm-Message-State: AOJu0YydWlyTZB5mSXvrFx5YrKjmo8nJLYWLf6UvdH7kHAysyQ6uvZDs
	04xwbN08eXJodmxoTqf0oqy8mIXKROMBbjPiceNz1LvlGmCf3fwqOETp8JA8uxyehBbxckzgze4
	=
X-Gm-Gg: ASbGncu7yFBmYLbygGJBASG22F4KibBIvwYyIUxQhkml8hfDOf6nbRIOIphhV1m89fr
	x21StxmDxj9Hp6fd4/7kDrHDpri5IwW8AqjdXsZeQr6JjXp2mNEyJsYV7zuhKkgoO/p4vm1xf+d
	SN60zaUGFmp059qUkJdnFeMmH6y2f8jnutA3VMsM8fxX/+UN8bGLDXFojz3bD/khNSsZKZh+8NM
	1x4nc8ChL4zRUB0RKjme41/GN+/qqxANWpX6Am5K/0y09yxtmjL2EJqm8+oPIIH3IIE71NUkoZO
	FnOIN+Va9VLI1pZCTdDaJDJdAZbFJhcNR/8CbSyeIxOg3dHr9CcK2jbUGEIULQtmWA==
X-Google-Smtp-Source: AGHT+IEJyiuaeKTuWi+MniWWUIDpX7/ZBYCqnROd3hG27mB9OF4NqgoIQZjHiCdHEEccyk1wEB0M3w==
X-Received: by 2002:a05:600c:1c93:b0:434:fbda:1f36 with SMTP id 5b1f17b1804b1-438914299bdmr223255885e9.20.1737628280760;
        Thu, 23 Jan 2025 02:31:20 -0800 (PST)
Message-ID: <5bd5cad3-698e-420b-aa97-e84763df0420@suse.com>
Date: Thu, 23 Jan 2025 11:31:19 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH for-4.20 v3 2/4] x86/HVM: correct read/write split at page
 boundaries
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>
References: <729f7896-55b7-4b5b-a7e9-6eb0420e0b14@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <729f7896-55b7-4b5b-a7e9-6eb0420e0b14@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

The MMIO cache is intended to have one entry used per independent memory
access that an insn does. This, in particular, is supposed to be
ignoring any page boundary crossing. Therefore when looking up a cache
entry, the access'es starting (linear) address is relevant, not the one
possibly advanced past a page boundary.

In order for the same offset-into-buffer variable to be usable in
hvmemul_phys_mmio_access() for both the caller's buffer and the cache
entry's it is further necessary to have the un-adjusted caller buffer
passed into there.

Fixes: 2d527ba310dc ("x86/hvm: split all linear reads and writes at page boundary")
Reported-by: Manuel Andreas <manuel.andreas@tum.de>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
This way problematic overlaps are only reduced (to ones starting at the
same address), not eliminated: Assumptions in hvmemul_phys_mmio_access()
go further - if a subsequent access is larger than an earlier one, but
the splitting results in a chunk to cross the end "boundary" of the
earlier access, an assertion will still trigger. Explicit memory
accesses (ones encoded in an insn by explicit or implicit memory
operands) match the assumption afaict (i.e. all those accesses are of
uniform size, and hence they either fully overlap or are mapped to
distinct cache entries).

Insns accessing descriptor tables, otoh, don't fulfill these
expectations: The selector read (if coming from memory) will always be
smaller than the descriptor being read, and if both (insanely) start at
the same linear address (in turn mapping MMIO), said assertion will kick
in. (The same would be true for an insn trying to access itself as data,
as long as certain size "restrictions" between insn and memory operand
are met. Except that linear_read() disallows insn fetches from MMIO.) To
deal with such, I expect we will need to further qualify (tag) cache
entries, such that reads/writes won't use insn fetch entries, and
implicit-supervisor-mode accesses won't use entries of ordinary
accesses. (Page table accesses don't need considering here for now, as
our page walking code demands page tables to be mappable, implying
they're in guest RAM; such accesses also don't take the path here.)
Thoughts anyone, before I get to making another patch?

Considering the insn fetch aspect mentioned above I'm having trouble
following why the cache has 3 entries. With insn fetches permitted,
descriptor table accesses where the accessed bit needs setting may also
fail because of that limited capacity of the cache, due to the way the
accesses are done. The read and write (cmpxchg) are independent accesses
from the cache's perspective, and hence we'd need another entry there.
If, otoh, the 3 entries are there to account for precisely this (which
seems unlikely with commit e101123463d2 ["x86/hvm: track large memory
mapped accesses by buffer offset"] not saying anything at all), then we
should be fine in this regard. If we were to permit insn fetches, which
way to overcome this (possibly by allowing the write to re-use the
earlier read's entry in this special situation) would remain to be
determined.
---
v3: Rename "start" function parameters to "start_gla". Adjust wording of
    a comment. Re-base over comment addition in an earlier patch.

--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -31,8 +31,9 @@
  * device-model transactions.
  */
 struct hvm_mmio_cache {
-    unsigned long gla;
-    unsigned int size;     /* Amount of buffer[] actually used. */
+    unsigned long gla;     /* Start of original access (e.g. insn operand). */
+    unsigned int skip;     /* Offset to start of MMIO */
+    unsigned int size;     /* Amount of buffer[] actually used, incl @skip. */
     unsigned int space:31; /* Allocated size of buffer[]. */
     unsigned int dir:1;
     uint8_t buffer[] __aligned(sizeof(long));
@@ -953,6 +954,13 @@ static int hvmemul_phys_mmio_access(
         return X86EMUL_UNHANDLEABLE;
     }
 
+    /* Accesses must not be to the unused leading space. */
+    if ( offset < cache->skip )
+    {
+        ASSERT_UNREACHABLE();
+        return X86EMUL_UNHANDLEABLE;
+    }
+
     /*
      * hvmemul_do_io() cannot handle non-power-of-2 accesses or
      * accesses larger than sizeof(long), so choose the highest power
@@ -1010,13 +1018,15 @@ static int hvmemul_phys_mmio_access(
 
 /*
  * Multi-cycle MMIO handling is based upon the assumption that emulation
- * of the same instruction will not access the same MMIO region more
- * than once. Hence we can deal with re-emulation (for secondary or
- * subsequent cycles) by looking up the result or previous I/O in a
- * cache indexed by linear MMIO address.
+ * of the same instruction will not access the exact same MMIO region
+ * more than once in exactly the same way (if it does, the accesses will
+ * be "folded"). Hence we can deal with re-emulation (for secondary or
+ * subsequent cycles) by looking up the result of previous I/O in a cache
+ * indexed by linear address and access type.
  */
 static struct hvm_mmio_cache *hvmemul_find_mmio_cache(
-    struct hvm_vcpu_io *hvio, unsigned long gla, uint8_t dir, bool create)
+    struct hvm_vcpu_io *hvio, unsigned long gla, uint8_t dir,
+    unsigned int skip)
 {
     unsigned int i;
     struct hvm_mmio_cache *cache;
@@ -1030,7 +1040,11 @@ static struct hvm_mmio_cache *hvmemul_fi
             return cache;
     }
 
-    if ( !create )
+    /*
+     * Bail if a new entry shouldn't be allocated, relying on ->space having
+     * the same value for all entries.
+     */
+    if ( skip >= hvio->mmio_cache[0]->space )
         return NULL;
 
     i = hvio->mmio_cache_count;
@@ -1043,7 +1057,8 @@ static struct hvm_mmio_cache *hvmemul_fi
     memset(cache->buffer, 0, cache->space);
 
     cache->gla = gla;
-    cache->size = 0;
+    cache->skip = skip;
+    cache->size = skip;
     cache->dir = dir;
 
     return cache;
@@ -1064,12 +1079,14 @@ static void latch_linear_to_phys(struct
 
 static int hvmemul_linear_mmio_access(
     unsigned long gla, unsigned int size, uint8_t dir, void *buffer,
-    uint32_t pfec, struct hvm_emulate_ctxt *hvmemul_ctxt, bool known_gpfn)
+    uint32_t pfec, struct hvm_emulate_ctxt *hvmemul_ctxt,
+    unsigned long start_gla, bool known_gpfn)
 {
     struct hvm_vcpu_io *hvio = &current->arch.hvm.hvm_io;
     unsigned long offset = gla & ~PAGE_MASK;
-    struct hvm_mmio_cache *cache = hvmemul_find_mmio_cache(hvio, gla, dir, true);
-    unsigned int chunk, buffer_offset = 0;
+    unsigned int chunk, buffer_offset = gla - start_gla;
+    struct hvm_mmio_cache *cache = hvmemul_find_mmio_cache(hvio, start_gla,
+                                                           dir, buffer_offset);
     paddr_t gpa;
     unsigned long one_rep = 1;
     int rc;
@@ -1117,19 +1134,19 @@ static int hvmemul_linear_mmio_access(
 static inline int hvmemul_linear_mmio_read(
     unsigned long gla, unsigned int size, void *buffer,
     uint32_t pfec, struct hvm_emulate_ctxt *hvmemul_ctxt,
-    bool translate)
+    unsigned long start_gla, bool translate)
 {
-    return hvmemul_linear_mmio_access(gla, size, IOREQ_READ, buffer,
-                                      pfec, hvmemul_ctxt, translate);
+    return hvmemul_linear_mmio_access(gla, size, IOREQ_READ, buffer, pfec,
+                                      hvmemul_ctxt, start_gla, translate);
 }
 
 static inline int hvmemul_linear_mmio_write(
     unsigned long gla, unsigned int size, void *buffer,
     uint32_t pfec, struct hvm_emulate_ctxt *hvmemul_ctxt,
-    bool translate)
+    unsigned long start_gla, bool translate)
 {
-    return hvmemul_linear_mmio_access(gla, size, IOREQ_WRITE, buffer,
-                                      pfec, hvmemul_ctxt, translate);
+    return hvmemul_linear_mmio_access(gla, size, IOREQ_WRITE, buffer, pfec,
+                                      hvmemul_ctxt, start_gla, translate);
 }
 
 static bool known_gla(unsigned long addr, unsigned int bytes, uint32_t pfec)
@@ -1158,7 +1175,10 @@ static int linear_read(unsigned long add
 {
     pagefault_info_t pfinfo;
     struct hvm_vcpu_io *hvio = &current->arch.hvm.hvm_io;
+    void *buffer = p_data;
+    unsigned long start = addr;
     unsigned int offset = addr & ~PAGE_MASK;
+    const struct hvm_mmio_cache *cache;
     int rc;
 
     if ( offset + bytes > PAGE_SIZE )
@@ -1182,8 +1202,17 @@ static int linear_read(unsigned long add
      * an access that was previously handled as MMIO. Thus it is imperative that
      * we handle this access in the same way to guarantee completion and hence
      * clean up any interim state.
+     *
+     * Care must be taken, however, to correctly deal with crossing RAM/MMIO or
+     * MMIO/RAM boundaries. While we want to use a single cache entry (tagged
+     * by the starting linear address), we need to continue issuing (i.e. also
+     * upon replay) the RAM access for anything that's ahead of or past MMIO,
+     * i.e. in RAM.
      */
-    if ( !hvmemul_find_mmio_cache(hvio, addr, IOREQ_READ, false) )
+    cache = hvmemul_find_mmio_cache(hvio, start, IOREQ_READ, ~0);
+    if ( !cache ||
+         addr + bytes <= start + cache->skip ||
+         addr >= start + cache->size )
         rc = hvm_copy_from_guest_linear(p_data, addr, bytes, pfec, &pfinfo);
 
     switch ( rc )
@@ -1199,8 +1228,8 @@ static int linear_read(unsigned long add
         if ( pfec & PFEC_insn_fetch )
             return X86EMUL_UNHANDLEABLE;
 
-        return hvmemul_linear_mmio_read(addr, bytes, p_data, pfec,
-                                        hvmemul_ctxt,
+        return hvmemul_linear_mmio_read(addr, bytes, buffer, pfec,
+                                        hvmemul_ctxt, start,
                                         known_gla(addr, bytes, pfec));
 
     case HVMTRANS_gfn_paged_out:
@@ -1217,7 +1246,10 @@ static int linear_write(unsigned long ad
 {
     pagefault_info_t pfinfo;
     struct hvm_vcpu_io *hvio = &current->arch.hvm.hvm_io;
+    void *buffer = p_data;
+    unsigned long start = addr;
     unsigned int offset = addr & ~PAGE_MASK;
+    const struct hvm_mmio_cache *cache;
     int rc;
 
     if ( offset + bytes > PAGE_SIZE )
@@ -1236,13 +1268,11 @@ static int linear_write(unsigned long ad
 
     rc = HVMTRANS_bad_gfn_to_mfn;
 
-    /*
-     * If there is an MMIO cache entry for the access then we must be re-issuing
-     * an access that was previously handled as MMIO. Thus it is imperative that
-     * we handle this access in the same way to guarantee completion and hence
-     * clean up any interim state.
-     */
-    if ( !hvmemul_find_mmio_cache(hvio, addr, IOREQ_WRITE, false) )
+    /* See commentary in linear_read(). */
+    cache = hvmemul_find_mmio_cache(hvio, start, IOREQ_WRITE, ~0);
+    if ( !cache ||
+         addr + bytes <= start + cache->skip ||
+         addr >= start + cache->size )
         rc = hvm_copy_to_guest_linear(addr, p_data, bytes, pfec, &pfinfo);
 
     switch ( rc )
@@ -1255,8 +1285,8 @@ static int linear_write(unsigned long ad
         return X86EMUL_EXCEPTION;
 
     case HVMTRANS_bad_gfn_to_mfn:
-        return hvmemul_linear_mmio_write(addr, bytes, p_data, pfec,
-                                         hvmemul_ctxt,
+        return hvmemul_linear_mmio_write(addr, bytes, buffer, pfec,
+                                         hvmemul_ctxt, start,
                                          known_gla(addr, bytes, pfec));
 
     case HVMTRANS_gfn_paged_out:
@@ -1643,7 +1673,7 @@ static int cf_check hvmemul_cmpxchg(
     {
         /* Fix this in case the guest is really relying on r-m-w atomicity. */
         return hvmemul_linear_mmio_write(addr, bytes, p_new, pfec,
-                                         hvmemul_ctxt,
+                                         hvmemul_ctxt, addr,
                                          hvio->mmio_access.write_access &&
                                          hvio->mmio_gla == (addr & PAGE_MASK));
     }



From xen-devel-bounces@lists.xenproject.org Thu Jan 23 10:32:01 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 10:32:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876149.1286514 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tauV4-0000T9-Tc; Thu, 23 Jan 2025 10:31:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876149.1286514; Thu, 23 Jan 2025 10:31:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tauV4-0000T2-QM; Thu, 23 Jan 2025 10:31:50 +0000
Received: by outflank-mailman (input) for mailman id 876149;
 Thu, 23 Jan 2025 10:31: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 <SRS0=nhpA=UP=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tauV3-0008P3-KC
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 10:31:49 +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 4009918e-d975-11ef-99a4-01e77a169b0f;
 Thu, 23 Jan 2025 11:31:48 +0100 (CET)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-43624b2d453so7306175e9.2
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 02:31:48 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38bf3214b4fsm18724758f8f.2.2025.01.23.02.31.46
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 23 Jan 2025 02:31:46 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 4009918e-d975-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737628308; x=1738233108; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=GkPtOo84ZGrBaC3bJPX3VZcUrguvma+CLYeb6XeRzK8=;
        b=eYh89Pm6wN2SrS3XlqB+Ky8XRsA2tT+IV1IdcNhXuvk/WrGTiQDIqJJDyDIY21hS/0
         cFVAmQ5GsfqSk+L0se1ktpaUwosuGvBcc/OrhW3OS6bo0/W05SkdYoUYyPwbpANIydw8
         vPJT2FpiuiWN54k4zZ4rPbDnwkZohD8J6fgyDpoxgLGEpivkyx7DXCXlnLZ6hoCWHp/3
         C03mbQXYIgdnfruHPPPJJH/XgA6qxbJEWtkleJm8OrLUdpxPM0E6+lRuX2dwWBFegbu8
         yC+EU2rb1RyXd1FMrgoQXNWrjN4rB9qvJUp2snHS5A+Usrzw4FOl7EH9tbyZgbp814PO
         qTRQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737628308; x=1738233108;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=GkPtOo84ZGrBaC3bJPX3VZcUrguvma+CLYeb6XeRzK8=;
        b=HILFPX1bHyjt/xs5gPUVzX74KFGUyyzaFQvMfdBMZCYEcxHzmX36gJPCVHthU7bdMv
         4Xb1hrbqHJid4RLJPPPUjPhTTbtjx0PnH6nM0lI9NtpHvxvD6pFNhxJ66taXbCFy+z/Q
         gqX+Ube0DCCgYG0Ohe3KCBjlmmVHArgkKIeAbSSEk9Go7rdjHr2EsMrxqdN0kSQqp20r
         Kcy7qiYEWDURHTIonTBOC8E7vy/GOq7q7UhqM40fxdi6AHxuGv6mtQ0kF2/ADqyT7Anb
         nJkFGI+CvTqOkMCqgXwXO3LCp9ki/2mjSe8f49rxs+vUV2H74vwNvIqZ21HBf3gIcaZ/
         ahCg==
X-Gm-Message-State: AOJu0YyVfKILZk0auqg9xv/ThGfoWPAW/m+BlA0GfLxpgalHCUA5CMWq
	ZWerGvyQJIUZ9ZeDzcpGemHcvNXrYrKnCaFmO5qEsj9ggcARr5kSN2Ju88+H4nItiuDOpNo12Ik
	=
X-Gm-Gg: ASbGnctNp0t3i4T+hJeRCtsYJRnE2K4hZVQ0R+gD0SMzQu2CwLf+xQsi5K04rDEhDWS
	iUkyX+s9ZJ6a9zRBPq20+TrkCvtuIvSnCYoBd2IEclRLCktcV3Vg3s3kLDl1m0CKXkGACbV6kFv
	jy7VlhRCGBmXxiwXJKPWBiNngM34/ASdCfo42Z/NUyWkI6XxSkna1uwMVFmjNOlRWGoCxYLLs/P
	WVWnKEUNpL3Ds071mLTTJvriRnpanpZTDfVI625DD+5+o0PiJ+CFxX1VYjP815xZYedVQsWJWH7
	fvg0c/FXAWhSA6T4aRjYkXOaduRAWWAN/IQuXQl1VEH7oVo+Lwa0EwzzMsRzpRZCPA==
X-Google-Smtp-Source: AGHT+IGCWDUbub4VO/0yCZvz8DysCk7T1E5ger/ES1zeoOxNZfhJp1gTiug0jc0H+ZS/kCSCCPImLQ==
X-Received: by 2002:a5d:6ac9:0:b0:38b:d765:7039 with SMTP id ffacd0b85a97d-38bf5659be6mr17267975f8f.17.1737628307124;
        Thu, 23 Jan 2025 02:31:47 -0800 (PST)
Message-ID: <df11d714-b041-4e07-aaaa-4a3a3d37fb3d@suse.com>
Date: Thu, 23 Jan 2025 11:31:46 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v3 3/4] x86/HVM: slightly improve CMPXCHG16B emulation
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>
References: <729f7896-55b7-4b5b-a7e9-6eb0420e0b14@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <729f7896-55b7-4b5b-a7e9-6eb0420e0b14@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Using hvmemul_linear_mmio_write() directly (as fallback when mapping the
memory operand isn't possible) won't work properly when the access
crosses a RAM/MMIO boundary. Use linear_write() instead, which splits at
such boundaries as necessary.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1645,10 +1645,8 @@ static int cf_check hvmemul_cmpxchg(
 {
     struct hvm_emulate_ctxt *hvmemul_ctxt =
         container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
-    struct vcpu *curr = current;
     unsigned long addr;
     uint32_t pfec = PFEC_page_present | PFEC_write_access;
-    struct hvm_vcpu_io *hvio = &curr->arch.hvm.hvm_io;
     int rc;
     void *mapping = NULL;
 
@@ -1672,10 +1670,7 @@ static int cf_check hvmemul_cmpxchg(
     if ( !mapping )
     {
         /* Fix this in case the guest is really relying on r-m-w atomicity. */
-        return hvmemul_linear_mmio_write(addr, bytes, p_new, pfec,
-                                         hvmemul_ctxt, addr,
-                                         hvio->mmio_access.write_access &&
-                                         hvio->mmio_gla == (addr & PAGE_MASK));
+        return linear_write(addr, bytes, p_new, pfec, hvmemul_ctxt);
     }
 
     switch ( bytes )



From xen-devel-bounces@lists.xenproject.org Thu Jan 23 10:32:28 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 10:32:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876157.1286523 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tauVW-0000zy-4f; Thu, 23 Jan 2025 10:32:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876157.1286523; Thu, 23 Jan 2025 10:32:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tauVW-0000zr-2A; Thu, 23 Jan 2025 10:32:18 +0000
Received: by outflank-mailman (input) for mailman id 876157;
 Thu, 23 Jan 2025 10:32:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=nhpA=UP=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tauVU-0008FU-55
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 10:32:16 +0000
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com
 [2a00:1450:4864:20::335])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4fa30f07-d975-11ef-a0e5-8be0dac302b0;
 Thu, 23 Jan 2025 11:32:14 +0100 (CET)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-4361815b96cso4823035e9.1
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 02:32:14 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38bf327e327sm18385898f8f.87.2025.01.23.02.32.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 23 Jan 2025 02:32:13 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 4fa30f07-d975-11ef-a0e5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737628334; x=1738233134; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=HneC4tuDeqdivr7ucNMyxLt3tAp+7YCblsbiCrRGkJ8=;
        b=DGnbataJNvBmAyVVW6OhXH92C1mXC88FF8r5HNNjusx3Y+zDkDn+n46SRnCs9gXX+z
         WofvVvKon4D2Wq3piz1keCHLjmOTSJElkw6Y74kheCMFdcV7UhIuiKzwtOi+XaEtjpfk
         StYHlyj2L9M9JMFpprERYLOdd+aN/b6HrhyjarxJiRVCggxKDj9urexNlvXDjed263hz
         lEG9VhObzd4G46qGwKdECDy/kmQMO8QYgAq0q0HeVB84ssWweG12rdyxZrKGvO1qmKWJ
         joi5YuNoM2aaKfak6wCTZ3XYUBJZ2AreN924C4l0hnN1qPSLztSP195BmcWPn2Zu0e06
         0HIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737628334; x=1738233134;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=HneC4tuDeqdivr7ucNMyxLt3tAp+7YCblsbiCrRGkJ8=;
        b=P54aZ0UBZD1qMt3sLaMYO2dyS17H0lEyB5OrPT+zHADu78V1ZoToy0Nib0hQx57UxG
         /8otyREh5pddKOkjbnEPcEb6XQohmyE3ObHu42WlYF/4224TqY7nJG0XGOzkVTooqj9x
         4Q81G/KVJXhq4Q/j4vwI/3dyelkrx4tqad2FHBvKXSvfrCabw8zEMXgNqHuyzcbeMrMz
         hOs7Ei1N8N8Hp130pHTqIvcC8eKRhgm2J94/ZH9pTL1ulFMBGrGLeIGVlViAHkVAt+fE
         oIHG6XhLH4sfMHr1Mu9LjKA5e6DzoYjCphI/8BFclVFr3sAYHgkI+oJs9kJwiqIm81CE
         6eJQ==
X-Gm-Message-State: AOJu0YyOe1TBuBFkWQJHkAyEBLxw2m7Oyq2Wy+TEmpguQ0c5nLfQfGWc
	0mOEKFfL5fDA6sIHHJXiQiQ1mjTdSsdjZdZV/fYnDVQEBNx3m3edTZ3Ctx8JnK/V3Qn8ufpubOs
	=
X-Gm-Gg: ASbGncsMKZTOtqDoj72n1hHql5m+ZY6AzfYcIUeTkNSUOP8z0v8dKmPXxVAiFJqG3is
	muuke1ohjILPSVvRdonRpF9vE73278jGoOE/aDTQB2WoeQjOnuMPB48oLf/BHmxMysEvAAOMAtM
	21LI1A+9fPUkOxwtwNfntCSSUwcHqFckd5nPhjynRkfZ5bDjjVckNox53M/ukYkC7mnrGN6Zsr5
	13cmYRb6yeGwaly+bZSp+lh+A//Y6RKkTYdVq0o/FTo/SVtrKKa2dWWl2oZKV5bPQw122pNizUj
	LOF5+Gjg/QfSkhy9y1ymoZ+N4C8O3Bwt74QLzcA95eqZTkGBcpFpO+26L6FThOlfrg==
X-Google-Smtp-Source: AGHT+IHb/PlX38QozwvGAx+OkBsBBWcIYqoCdLQn0lCrvawFT0EMu1SZpBRSTyuztnrfiO3rTvciBw==
X-Received: by 2002:a5d:64e9:0:b0:382:450c:2607 with SMTP id ffacd0b85a97d-38bf566e73cmr19476285f8f.4.1737628333808;
        Thu, 23 Jan 2025 02:32:13 -0800 (PST)
Message-ID: <93c773f3-2426-43ef-ab15-64c6589234d3@suse.com>
Date: Thu, 23 Jan 2025 11:32:13 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v3 4/4] x86/HVM: drop redundant access splitting
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>
References: <729f7896-55b7-4b5b-a7e9-6eb0420e0b14@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <729f7896-55b7-4b5b-a7e9-6eb0420e0b14@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

With all paths into hvmemul_linear_mmio_access() coming through
linear_{read,write}(), there's no need anymore to split accesses at
page boundaries there. Leave an assertion, though.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
---
v3: Transform an expression. Re-base over parameter renaming in an
    earlier patch.
v2: Replace ASSERT() by more safe construct.

--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1084,7 +1084,7 @@ static int hvmemul_linear_mmio_access(
 {
     struct hvm_vcpu_io *hvio = &current->arch.hvm.hvm_io;
     unsigned long offset = gla & ~PAGE_MASK;
-    unsigned int chunk, buffer_offset = gla - start_gla;
+    unsigned int buffer_offset = gla - start_gla;
     struct hvm_mmio_cache *cache = hvmemul_find_mmio_cache(hvio, start_gla,
                                                            dir, buffer_offset);
     paddr_t gpa;
@@ -1094,13 +1094,17 @@ static int hvmemul_linear_mmio_access(
     if ( cache == NULL )
         return X86EMUL_UNHANDLEABLE;
 
-    chunk = min_t(unsigned int, size, PAGE_SIZE - offset);
+    if ( size + offset > PAGE_SIZE )
+    {
+        ASSERT_UNREACHABLE();
+        return X86EMUL_UNHANDLEABLE;
+    }
 
     if ( known_gpfn )
         gpa = pfn_to_paddr(hvio->mmio_gpfn) | offset;
     else
     {
-        rc = hvmemul_linear_to_phys(gla, &gpa, chunk, &one_rep, pfec,
+        rc = hvmemul_linear_to_phys(gla, &gpa, size, &one_rep, pfec,
                                     hvmemul_ctxt);
         if ( rc != X86EMUL_OKAY )
             return rc;
@@ -1108,27 +1112,8 @@ static int hvmemul_linear_mmio_access(
         latch_linear_to_phys(hvio, gla, gpa, dir == IOREQ_WRITE);
     }
 
-    for ( ;; )
-    {
-        rc = hvmemul_phys_mmio_access(cache, gpa, chunk, dir, buffer, buffer_offset);
-        if ( rc != X86EMUL_OKAY )
-            break;
-
-        gla += chunk;
-        buffer_offset += chunk;
-        size -= chunk;
-
-        if ( size == 0 )
-            break;
-
-        chunk = min_t(unsigned int, size, PAGE_SIZE);
-        rc = hvmemul_linear_to_phys(gla, &gpa, chunk, &one_rep, pfec,
-                                    hvmemul_ctxt);
-        if ( rc != X86EMUL_OKAY )
-            return rc;
-    }
-
-    return rc;
+    return hvmemul_phys_mmio_access(cache, gpa, size, dir, buffer,
+                                    buffer_offset);
 }
 
 static inline int hvmemul_linear_mmio_read(



From xen-devel-bounces@lists.xenproject.org Thu Jan 23 11:55:24 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 11:55:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876170.1286538 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tavnb-0003mU-Qh; Thu, 23 Jan 2025 11:55:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876170.1286538; Thu, 23 Jan 2025 11:55:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tavnb-0003mN-Nd; Thu, 23 Jan 2025 11:55:03 +0000
Received: by outflank-mailman (input) for mailman id 876170;
 Thu, 23 Jan 2025 11:55:03 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Lw3w=UP=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tavnb-0003mF-0L
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 11:55:03 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id dfbc24af-d980-11ef-99a4-01e77a169b0f;
 Thu, 23 Jan 2025 12:55:00 +0100 (CET)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-ab39f84cbf1so158812166b.3
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 03:55:00 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab384ce1f71sm1063895966b.61.2025.01.23.03.54.59
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 23 Jan 2025 03:54:59 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: dfbc24af-d980-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737633300; x=1738238100; 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=asFzOIJ6HW15QI2JSh029PiL2Dhl+h9jYjhIOuP0MGo=;
        b=i/oStinnrSqyafQPyqUBasCTa4E8VUQyq5tjLFaXYyXCKtyKky9nJ3TcQ5WpIZHzqf
         ppILrAzD2lGQ88f4FWW2TViWOqiWQzrH3fqiisn2pCu44k8EnzRBH2bN8kPhpGYiyIkf
         +lSnlrkCbMwKUh1/qgcsNLoulhIyM3cyRLL8s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737633300; x=1738238100;
        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=asFzOIJ6HW15QI2JSh029PiL2Dhl+h9jYjhIOuP0MGo=;
        b=KRjP3yeLclpm6JvmxilCi6WnwIh0km113siFVgX7P/pui4OFdq/e508Yiml8qMqOVD
         Ni585WFNqO0Wsy2IBB0bGI6Ku5M6Lmo9LnG1z/6Zr5xEZVh6N0dumgp2hKTxEusjQfC/
         UyBWLnTkWB1qaFYV9VzuJBmd4GzX1q4bWfloBMRKcT8cXmnXu/Z+k8uQjv9CO4Xo753g
         UadayGOsQWgLpC/Txw7/AC1D0Nu8za/qLEblTfOec6jF7Ncxxt7CuIi6ya+PwavQupl+
         6GAadcMcapyUEt6vU2m44tVCXKTZNjOoWiE4JRe+Kd8T8K8rOwg32Nz9bVdK5hjMaXXL
         R+kw==
X-Gm-Message-State: AOJu0YxtswvLnAd5S8UQeAKcXnX5aUw5hNkhdkZHTIDy0k2w4RRQm2aP
	0KaQT8FyRSz1b0nM1AmphyJWcJO9rvDdM/LgcDdf9wzFVVu0Cdse0rbb9Txant8=
X-Gm-Gg: ASbGncvWrGNVP+U3alUd0kqb5E6vIIhrhl2mbDnSO15u+zRZRR+Ze5jJ8+SrJFmuR7U
	v3MAzq6/KUrATP1kfalSnQMGEIDFFho/CwAeF5gMXc5cq62LPK8eGvHWjOEVYTz3+zdHMzVw/qB
	yqJRZWG4cbY68ZRPjf0HEBDzhS81cXWXq/Z52SRHb58WSpiMJz8byEyeikjaEnsyaRcH2mpuAoW
	edDaDQHYm3RB4NkpEIhbB6dgS2GcIb3Qve/3hA8gHdjTuxmbJ1Pg9vdLxjWV2jDwzyaxDxkx/9Q
	aaOCo2MNWILSjYs=
X-Google-Smtp-Source: AGHT+IFVw0rEpcBDTLfqDv/zd3mDH1uJAooG65ExD3HbcIhYShBBY2A8M/eXm1d+SEGjB0pUo/k/Gw==
X-Received: by 2002:a17:907:930b:b0:aab:c78c:a705 with SMTP id a640c23a62f3a-ab38b3d4253mr2407868366b.52.1737633300026;
        Thu, 23 Jan 2025 03:55:00 -0800 (PST)
Date: Thu, 23 Jan 2025 12:54:58 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH] x86/PV: further harden guest memory accesses against
 speculative abuse
Message-ID: <Z5IuEq9Lauhn8glx@macbook.local>
References: <a537dd1e-bbd3-4ef8-8014-6bb432484c57@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <a537dd1e-bbd3-4ef8-8014-6bb432484c57@suse.com>

On Tue, Nov 05, 2024 at 02:56:42PM +0100, Jan Beulich wrote:
> The original implementation has two issues: For one it doesn't preserve
> non-canonical-ness of inputs in the range 0x8000000000000000 through
> 0x80007fffffffffff. Bogus guest pointers in that range would not cause a
> (#GP) fault upon access, when they should.
> 
> And then there is an AMD-specific aspect, where only the low 48 bits of
> an address are used for speculative execution; the architecturally
> mandated #GP for non-canonical addresses would be raised at a later
> execution stage. Therefore to prevent Xen controlled data to make it
> into any of the caches in a guest controllable manner, we need to
> additionally ensure that for non-canonical inputs bit 47 would be clear.
> 
> See the code comment for how addressing both is being achieved.
> 
> Fixes: 4dc181599142 ("x86/PV: harden guest memory accesses against speculative abuse")
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> RFC: Two variants of part of the logic are being presented, both with
>      certain undesirable aspects: The first form is pretty large and
>      ugly (some improvement may be possible by introducing further
>      helper macros). The alternative form continues to use RCR, which
>      generally would be nice to do away with. Then again that's also
>      slightly smaller generated code.

Oh, I assume that's why there's a hardcoded .if 1, I was wondering
about that.  What's the specific issue with using rcr?  And why is the
more complex set of macros that use setc plus a shl better?

Why not use cmovc:

mov $(1 << 63), \scratch1
cmovc \scratch1, \scratch2

AFAICT \scratch1 is not used past the btr instruction, and hence can
be used for the cmovc?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jan 23 11:57:06 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 11:57:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876178.1286549 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tavpZ-0004Ij-6j; Thu, 23 Jan 2025 11:57:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876178.1286549; Thu, 23 Jan 2025 11:57:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tavpZ-0004Ic-1z; Thu, 23 Jan 2025 11:57:05 +0000
Received: by outflank-mailman (input) for mailman id 876178;
 Thu, 23 Jan 2025 11:57:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=nhpA=UP=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tavpY-0004IW-ET
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 11:57:04 +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 284d4859-d981-11ef-99a4-01e77a169b0f;
 Thu, 23 Jan 2025 12:57:02 +0100 (CET)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-385deda28b3so534491f8f.0
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 03:57:02 -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
 ffacd0b85a97d-38bf322a838sm18753848f8f.48.2025.01.23.03.57.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 23 Jan 2025 03:57:01 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 284d4859-d981-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737633422; x=1738238222; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=/joPImFr6xW5XVBnoTNvsOMKWUJOHC3IgxYB/qzg4Wg=;
        b=J4lWypdkTLZ6rNqjuqO5OXvOmjnRI5nVLI1CA+2DpAyZdCt9C9AJMfQE8vJ+JO5dsk
         GhVxhGOGVxybIH4dcRloPQxKrVJtfzQn54u3Sxhn/Gt5tKgimp3ezMuZythHWYQjIjQz
         9di+dSkTSD6LF6Gfs6jE9uFXcxzIouiKzrnpAqi3VpvH86en+0o6ZbBzXZEm90qaW7+b
         VoCU88YPX8M6eFKo8iPJvY6+pQpq4nJTXW6vJpX/dAo4Kr9yib5uAnM7sKb1+IL5XGU4
         1nAnD9Ju4rSpiYi4uJubYADmITkePuqTAVrtdROkpp2EA2ABgxfE1yilYQObRZ99Z62w
         VjMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737633422; x=1738238222;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=/joPImFr6xW5XVBnoTNvsOMKWUJOHC3IgxYB/qzg4Wg=;
        b=kUXWCChdvTLNC5CnRFFHRWyqkYC+I6kpujzP66UQJab1DR5SsZxBHBWp5eWbvKI86d
         1VWp7TCZn+SkA0wY7ZK3BGhylTEYTKC4bM7GuMhHMWw2VmCgrOZ8zaZIpcXCfu1Uptmi
         T2xG1bR8lWq0QbAxFl+U5kNJ/YnK6KOHISyTSCaa6stOecwi70szRSuItStEln04oNJx
         OD1BSTqAM0KqqXrZ+UaquNMtA18fW3+M5Z9+TxZEITZVvhoKPjDP3wb6X92sBPZpEe5E
         Zfoizin3VEW54MGY2Hc3X1zmw7YmctRVe/zAFm6zsbYoidQBj466vaj2rzJAL6QyaW1+
         RlLw==
X-Forwarded-Encrypted: i=1; AJvYcCXJq9ymhICqg4jbG6Ne3L7yrt3pjPfrVg6UlTKfosgFiE92GFAly/M2fW89fcHfbEiQxsWf4RJIRIc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzpkAwwz13FcqKmjbR6YKIQtHVm815FlSEEcaDdvHiZKU1eiwxi
	5bw/u71I/+6pbmC1ljSFLbTrbulmRKfclbBog74tHzZOQj5TKplrPZfOSGYrVQ==
X-Gm-Gg: ASbGncsicbqCr7Jt5XKPlAVsWE3upe6U04f6vcpuxAQxo9ZEGFfEDxZbrEKAKO8wgHB
	nUfmvoc2WzHkS4+y4pxAntrx6lye9S46N5moS3bZVExKXetJl2RKea/dlgiV8roNGwVM3Vuj8UX
	Pa+AnyITaLK1ioUj4lIdFokBnn8Qg5WNPAkWd/LyW4+uCgGnsKR+dOYB57mO+G0Yc5B/7ox50/V
	qqG+yKoO6nu2FYMZ+a1mI/RpcTeTffxwj411lC6G5r1vNZ8kcwIQQbJJLdrdKpN+kHsumTJJZv6
	TJqiegm+w+/z1gjX3C+38sON2MS0cAx0YfgUzlbpAkvIOJLidvAUM9do/N/na/qztg==
X-Google-Smtp-Source: AGHT+IG9RxqFBr+4wuNveVskPoUugHh9j64Cfe+bFcUo5L8Xjy6VChDCcfDpn7Dv+8eYKq5HRGyd5Q==
X-Received: by 2002:a05:6000:1883:b0:386:459f:67e0 with SMTP id ffacd0b85a97d-38bf5663678mr27149519f8f.21.1737633421654;
        Thu, 23 Jan 2025 03:57:01 -0800 (PST)
Message-ID: <867b4010-29d3-475c-a17d-8c7c19edea56@suse.com>
Date: Thu, 23 Jan 2025 12:57:00 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v2 09/10] x86/vmx: Implement arch LBR
To: Tu Dinh <ngoc-tu.dinh@vates.tech>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Juergen Gross <jgross@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20250102084413.102-1-ngoc-tu.dinh@vates.tech>
 <20250102084413.102-10-ngoc-tu.dinh@vates.tech>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250102084413.102-10-ngoc-tu.dinh@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 02.01.2025 09:45, Tu Dinh wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -2021,6 +2021,13 @@ static void __context_switch(void)
>              if ( cpu_has_xsaves && is_hvm_vcpu(n) )
>                  set_msr_xss(n->arch.msrs->xss.raw);
>          }
> +#ifdef CONFIG_HVM
> +        /* XRSTORS LBR state behavior depends on MSR_LBR_DEPTH */
> +        if ( using_vmx() &&
> +             is_hvm_vcpu(n) &&
> +             n->domain->arch.cpu_policy->feat.arch_lbr )
> +            wrmsrl(MSR_LBR_DEPTH, n->arch.msrs->lbr_depth.raw);
> +#endif
>          vcpu_restore_fpu_nonlazy(n, false);
>          nd->arch.ctxt_switch->to(n);
>      }

Why the #ifdef? That's (indirectly) included in using_vmx() already,
isn't it?

And why the is_hvm_vcpu()? Non-HVM ones shouldn't ever have
->feat.arch_lbr set. In fact using_vmx() ought to be redundant with
the CPU policy check, too.

> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -48,6 +48,7 @@
>  #include <asm/monitor.h>
>  #include <asm/prot-key.h>
>  #include <asm/spec_ctrl.h>
> +#include <asm/xstate.h>
>  #include <public/arch-x86/cpuid.h>
>  
>  static bool __initdata opt_force_ept;
> @@ -773,6 +774,67 @@ void vmx_update_exception_bitmap(struct vcpu *v)
>          __vmwrite(EXCEPTION_BITMAP, bitmap);
>  }
>  
> +static void cf_check vmx_set_lbr_depth(struct vcpu *v,
> +                                       uint32_t depth)
> +{
> +    struct cpu_policy *cp = v->domain->arch.cpu_policy;
> +    bool host_lip, guest_lip;
> +    uint32_t i;

unsigned int

> +    if ( !cp->feat.arch_lbr )
> +        return;
> +
> +    ASSERT(depth != 0 &&
> +           depth <= NUM_MSR_ARCH_LBR_FROM_TO &&

See comments on the respective guest_wrmsr() additions.

> +           depth % 8 == 0);
> +    ASSERT(cp->basic.lbr_1Ca.supported_depths & ((1u << (depth / 8)) - 1));
> +
> +    host_lip = current_cpu_has_lbr_lip;
> +    guest_lip = !!cp->basic.lbr_1Ca.ip_contains_lip;

As already indicated elsewhere in the series: No need for !! in cases
like this one. I wonder though whether the local variables are actually
needed. They look to be used only ...

> +    if ( v->arch.msrs->lbr_depth.raw == depth &&
> +         v->arch.hvm.vmx.last_host_lip == host_lip )
> +        return;
> +
> +    if ( host_lip != guest_lip )

... here (the XSS_EXIT_BITMAP update could be folded into this if()
and its "else").

> +    {
> +        for ( i = 0; i < depth; i++ )
> +        {
> +            vmx_set_msr_intercept(v, MSR_LBR_FROM_IP(i), VMX_MSR_RW);
> +            vmx_set_msr_intercept(v, MSR_LBR_TO_IP(i), VMX_MSR_RW);
> +        }
> +        vmx_set_msr_intercept(v, MSR_IA32_LASTINTFROMIP, VMX_MSR_RW);
> +        vmx_set_msr_intercept(v, MSR_IA32_LASTINTTOIP, VMX_MSR_RW);
> +    }
> +    else
> +    {
> +        for ( i = 0; i < depth; i++ )
> +        {
> +            vmx_clear_msr_intercept(v, MSR_LBR_FROM_IP(i), VMX_MSR_RW);
> +            vmx_clear_msr_intercept(v, MSR_LBR_TO_IP(i), VMX_MSR_RW);
> +        }
> +        vmx_clear_msr_intercept(v, MSR_IA32_LASTINTFROMIP, VMX_MSR_RW);
> +        vmx_clear_msr_intercept(v, MSR_IA32_LASTINTTOIP, VMX_MSR_RW);
> +    }
> +
> +    /* MSR_{LBR,LER}_INFO don't need translating */
> +    for ( i = 0; i < depth; i++ )
> +        vmx_clear_msr_intercept(v, MSR_LBR_INFO(i), VMX_MSR_RW);
> +    vmx_clear_msr_intercept(v, MSR_LER_INFO, VMX_MSR_RW);
> +    /* MSRs beyond LBR_DEPTH always need #GP */
> +    for ( i = depth; i < NUM_MSR_ARCH_LBR_FROM_TO; i++ )
> +    {
> +        vmx_set_msr_intercept(v, MSR_LBR_INFO(i), VMX_MSR_RW);
> +        vmx_set_msr_intercept(v, MSR_LBR_FROM_IP(i), VMX_MSR_RW);
> +        vmx_set_msr_intercept(v, MSR_LBR_TO_IP(i), VMX_MSR_RW);
> +    }

While I agree with the comment ahead of the loop, wouldn't hardware take
care of this when the intercept is disabled?

Further, do you really need to fiddle with the entire
[0,NUM_MSR_ARCH_LBR_FROM_TO) range for all three groups? Isn't is enough
to cover
[min(depth, v->arch.msrs->lbr_depth), max(depth, v->arch.msrs->lbr_depth))
when "host_lip != guest_lip" didn't change (which, aiui, on some [many?]
systems will never be the case)?

> @@ -871,6 +933,16 @@ static void cf_check vmx_cpuid_policy_changed(struct vcpu *v)
>      else
>          vmx_set_msr_intercept(v, MSR_PKRS, VMX_MSR_RW);
>  
> +    if ( cp->feat.arch_lbr && v->arch.msrs->lbr_depth.raw == 0 )
> +    {
> +        uint32_t max_depth;

unsigned int

> @@ -2679,6 +2752,48 @@ static uint64_t cf_check vmx_get_reg(struct vcpu *v, unsigned int reg)
>          __vmread(GUEST_BNDCFGS, &val);
>          break;
>  
> +    case MSR_LBR_CTL:
> +        __vmread(GUEST_LBR_CTL, &val);
> +        break;
> +
> +    case MSR_LBR_DEPTH:
> +        val = v->arch.msrs->lbr_depth.raw;
> +        break;

This doesn't look to be VMX-specific (beyond the question whether AMD
will ever implement ARCH-LBR), and hence perhaps does't belong here.

> +    case MSR_LER_INFO:
> +    case MSR_LBR_INFO(0)...MSR_LBR_INFO(NUM_MSR_ARCH_LBR_FROM_TO - 1):
> +        if ( v != curr )
> +        {
> +            val = 0;
> +            break;
> +        }
> +        rdmsrl(reg, val);
> +        break;
> +
> +    case MSR_IA32_LASTINTFROMIP:
> +    case MSR_IA32_LASTINTTOIP:
> +    case MSR_LBR_FROM_IP(0)...MSR_LBR_FROM_IP(NUM_MSR_ARCH_LBR_FROM_TO - 1):
> +    case MSR_LBR_TO_IP(0)...MSR_LBR_TO_IP(NUM_MSR_ARCH_LBR_FROM_TO - 1):
> +    {
> +        struct segment_register cs;
> +        int mode_64bit;
> +        uint64_t offset;
> +
> +        if ( v != curr )
> +        {
> +            val = 0;
> +            break;
> +        }
> +
> +        mode_64bit = vmx_guest_x86_mode(v) == X86_MODE_64BIT;
> +        hvm_get_segment_register(v, x86_seg_cs, &cs);
> +        offset = x86_get_lbr_cs_offset(cp, mode_64bit, &cs, true);
> +
> +        rdmsrl(reg, val);
> +        val += offset;
> +        break;
> +    }

Same for all of these as it seems. And then similarly for set-reg.

> @@ -4055,6 +4197,36 @@ static void undo_nmis_unblocked_by_iret(void)
>                guest_info | VMX_INTR_SHADOW_NMI);
>  }
>  
> +static void vmx_handle_xsaves_xrstors(bool saving)
> +{
> +    struct hvm_emulate_ctxt ctxt;
> +    int rc;
> +
> +    if ( saving )
> +        hvm_emulate_init_once(&ctxt, x86_insn_is_xsaves, guest_cpu_user_regs());
> +    else
> +        hvm_emulate_init_once(&ctxt, x86_insn_is_xrstors, guest_cpu_user_regs());
> +
> +    switch ( rc = hvm_emulate_one(&ctxt, VIO_no_completion) )
> +    {
> +    case X86EMUL_UNHANDLEABLE:
> +        hvm_dump_emulation_state(XENLOG_G_WARNING, "XSAVES/XRSTORS", &ctxt, rc);

Can the strings passed here and ...

> +        hvm_inject_hw_exception(X86_EXC_UD, 0);
> +        return;
> +
> +    case X86EMUL_UNRECOGNIZED:
> +        hvm_dump_emulation_state(XENLOG_G_WARNING, "XSAVES/XRSTORS", &ctxt, rc);

... here please properly reflect "saving"?

> +        hvm_inject_hw_exception(X86_EXC_UD, X86_EVENT_NO_EC);

You correctly have X86_EVENT_NO_EC here, but not in the earlier invocation
of the function.

> +        break;
> +
> +    case X86EMUL_EXCEPTION:
> +        hvm_inject_event(&ctxt.ctxt.event);
> +        break;
> +    }

This switch lacks the handling of other X86EMUL_* cases (I realize you may
have found this pattern elsewhere). Actually, why aren't you using
hvm_emulate_one_insn() in the first place? After all this code isn't VMX-
specific at all.

> --- a/xen/arch/x86/include/asm/hvm/vmx/vmcs.h
> +++ b/xen/arch/x86/include/asm/hvm/vmx/vmcs.h
> @@ -154,6 +154,9 @@ struct vmx_vcpu {
>      /* Are we emulating rather than VMENTERing? */
>      uint8_t              vmx_emulate;
>  
> +    /* If the vCPU last ran on a host CPU with XEN_X86_FEATURE_LBR_LIP */
> +    bool                 last_host_lip;

I assume this is for asymmetric configurations (e.g. E-cores vs P-cores)?
Yet then - doesn't this field also need migrating (which I first thought
it's for, considering the "host" in its name)?

> @@ -229,6 +232,7 @@ extern u32 vmx_pin_based_exec_control;
>  #define VM_EXIT_LOAD_HOST_EFER          0x00200000
>  #define VM_EXIT_SAVE_PREEMPT_TIMER      0x00400000
>  #define VM_EXIT_CLEAR_BNDCFGS           0x00800000
> +#define VM_EXIT_CLEAR_GUEST_LBR_CTL     0x04000000
>  extern u32 vmx_vmexit_control;
>  
>  #define VM_ENTRY_IA32E_MODE             0x00000200
> @@ -238,6 +242,7 @@ extern u32 vmx_vmexit_control;
>  #define VM_ENTRY_LOAD_GUEST_PAT         0x00004000
>  #define VM_ENTRY_LOAD_GUEST_EFER        0x00008000
>  #define VM_ENTRY_LOAD_BNDCFGS           0x00010000
> +#define VM_ENTRY_LOAD_GUEST_LBR_CTL     0x00200000
>  extern u32 vmx_vmentry_control;

As you can see from context (BNDCFGS) we don't use a _GUEST_ infix for
these. It's technically wrong in the former case (as it's the real MSR
that's to be cleared, not the guest view thereof).

> @@ -480,6 +489,8 @@ enum vmcs_field {
>      GUEST_PDPTE0                    = 0x0000280a,
>  #define GUEST_PDPTE(n) (GUEST_PDPTE0 + (n) * 2) /* n = 0...3 */
>      GUEST_BNDCFGS                   = 0x00002812,
> +    GUEST_RTIT_CTL                  = 0x00002814,
> +    GUEST_LBR_CTL                   = 0x00002816,
>      HOST_PAT                        = 0x00002c00,
>      HOST_EFER                       = 0x00002c02,
>      HOST_PERF_GLOBAL_CTRL           = 0x00002c04,

While I don't mind the GUEST_RTIT_CTL addition here, it's unrelated. Such
things, even if minor, are normally mentioned in the patch description
(if nothing else, then to indicate they're actually deliberate).

> --- a/xen/arch/x86/include/asm/msr.h
> +++ b/xen/arch/x86/include/asm/msr.h
> @@ -389,6 +389,11 @@ struct vcpu_msrs
>          uint64_t raw;
>      } xss;
>  
> +    /* 0x000014cf - MSR_LBR_DEPTH */
> +    struct {
> +        uint64_t raw;
> +    } lbr_depth;

Why is this needed? The value is part of xstate, and hence saved/restored
that way, and also accessible there. You may of course have chosen to put
it here for other reasons, but then please comment this entry accordingly.
The comment would presumably also want to clarify that this is a HVM-only
field (alternatively this could be expressed by enclosing in #ifdef
CONFIG_HVM, provided the result actually builds okay).

I'm also uncertain about this wanting to be a struct. There are no fields
within the MSR (except for the partitioning between valid and reserved
bits).

> --- a/xen/arch/x86/msr.c
> +++ b/xen/arch/x86/msr.c
> @@ -193,6 +193,38 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val)
>              goto gp_fault;
>          goto get_reg;
>  
> +    case MSR_LBR_CTL:
> +    case MSR_LBR_DEPTH:
> +    case MSR_LER_INFO:
> +        if ( !cp->feat.arch_lbr )
> +            goto gp_fault;
> +
> +        goto get_reg;
> +
> +    case MSR_LBR_INFO(0)...MSR_LBR_INFO(NUM_MSR_ARCH_LBR_FROM_TO - 1):
> +        if ( !cp->feat.arch_lbr )
> +            goto gp_fault;
> +
> +        if ( msr - MSR_LBR_INFO(0) >= msrs->lbr_depth.raw )
> +            goto gp_fault;
> +
> +        goto get_reg;
> +
> +    case MSR_IA32_LASTINTFROMIP:
> +    case MSR_IA32_LASTINTTOIP:

I don't think you can wire these two ...

> +    case MSR_LBR_FROM_IP(0)...MSR_LBR_FROM_IP(NUM_MSR_ARCH_LBR_FROM_TO - 1):
> +    case MSR_LBR_TO_IP(0)...MSR_LBR_TO_IP(NUM_MSR_ARCH_LBR_FROM_TO - 1):
> +        if ( !cp->feat.arch_lbr )
> +            goto gp_fault;

... this way. When called from hvm_msr_read_intercept() they need to be
permitted through to vmx_msr_read_intercept() in the !ARCH_LBR case.

> +        if ( (msr >= MSR_LBR_FROM_IP(msrs->lbr_depth.raw) &&
> +              msr <= MSR_LBR_FROM_IP(NUM_MSR_ARCH_LBR_FROM_TO - 1)) ||
> +             (msr >= MSR_LBR_TO_IP(msrs->lbr_depth.raw) &&
> +              msr <= MSR_LBR_TO_IP(NUM_MSR_ARCH_LBR_FROM_TO - 1)) )
> +            goto gp_fault;

Much like you did for INFO, having the two ranges separately will simplify
the conditional(s) here.

Both comments obviously apply to the write path, too.

> @@ -516,6 +548,60 @@ int guest_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val)
>          }
>  
>          goto set_reg;
> +
> +    case MSR_LBR_CTL:
> +        if ( !cp->feat.arch_lbr )
> +            goto gp_fault;
> +
> +        if ( val & ~LBR_CTL_VALID )
> +            goto gp_fault;
> +
> +        goto set_reg;
> +
> +    case MSR_LBR_DEPTH:
> +        if ( !cp->feat.arch_lbr )
> +            goto gp_fault;
> +
> +        if ( val == 0 ||

I wasn't able to find an indication that 0 is an illegal value here. It
looks as if this simply means "no LBRs other than the LER ones".

> +             val > NUM_MSR_ARCH_LBR_FROM_TO ||

Isn't this redundant with ...

> +             val % 8 != 0 )
> +            goto gp_fault;
> +
> +        if ( !(cp->basic.lbr_1Ca.supported_depths &
> +               ((1u << (val / 8)) - 1)) )
> +            goto gp_fault;

... this?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 23 12:23:25 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 12:23:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876195.1286557 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tawEz-0000B4-6C; Thu, 23 Jan 2025 12:23:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876195.1286557; Thu, 23 Jan 2025 12:23:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tawEz-0000Ax-3K; Thu, 23 Jan 2025 12:23:21 +0000
Received: by outflank-mailman (input) for mailman id 876195;
 Thu, 23 Jan 2025 12:23: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
 <SRS0=Lw3w=UP=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tawEy-0000Ar-9n
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 12:23:20 +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 d399a3de-d984-11ef-99a4-01e77a169b0f;
 Thu, 23 Jan 2025 13:23:18 +0100 (CET)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-5d9837f201aso3727096a12.0
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 04:23:18 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab632fa9f6esm472093166b.115.2025.01.23.04.23.15
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 23 Jan 2025 04:23:16 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: d399a3de-d984-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737634997; x=1738239797; 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=Jqyzbacxeoe/hGUk9E85W1gEGbEF6DW25f7NXqDuufc=;
        b=FSfE2rzkPx98irM5pK7njLeIyxYcbd+ViyMuWI925AX5fxtQr8Z+xJaMyQpq1jmGrf
         XbgZslXRrZO13Hq3lfi+CyDlm3jqoMKsZm02quFlIRBqt4rYrvt524ZxEiXmpn7doCM5
         /UNixTTDrLcW79hCC620zZHTNJU8AvDK1Mh1s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737634997; x=1738239797;
        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=Jqyzbacxeoe/hGUk9E85W1gEGbEF6DW25f7NXqDuufc=;
        b=GUHm5LFy9wG7RFthj7Ejkm6snnpEx7KfrNlB5CRAW+mCA0oXq9eqlZC3riIBrZ5Mb4
         7pcJAdB0AU5mWA+kuv2lUTuwAmrzF0zUssV1eiOAOc0nQEylOlBMzztew5SxCwvXrXoZ
         wlJOg0sZP7ED9p5Yfkw2s8l0frWPbxPX4EvlGS5g6dT10+oaKlSm3qwoGfSsfzuH1D6c
         h5sBLu8V4/thKCk5a6BQj8pPXUjdSLHIRaBOHjLEb4AoyYhFhxRwOgQ8GWnqXTJBslIj
         5tMA6hjmO/gDT+OQlSHvrbzbQQWmVkYLxUYAWKDmdcFrydiVovef36QFlj5LXQGUmQyW
         4EDg==
X-Gm-Message-State: AOJu0Yz8C2XHuA1nGi5Lk3Up+tKn++fj4bhLlxL47LhgU886I3TcmKAX
	SFalt+aVhl5VUgkHto73SEEHKGfMRDWuExo1RIdL3K24WnyB8LUHpHxy2vM5N+Q=
X-Gm-Gg: ASbGncs5zLv7B4oFVrOSvdtl7eLF2e0SHd4rAiVV8IBFwQYOfK76JNs/GOwGp9UR0o7
	OGVjIzg3MYaTZglY7DocSuB8Eq17qvn3SL73MCHEOv5uTbwgRHrNLXGbgOap5/YnNvkaK5+F8V+
	mBNPZ/BMtHXFtaN/MyWwCY5LEwPDugBl0Mb4FVcul5ZgPzqO0x98u6sZkbNli8BjfDZRMe61HT5
	aXZwqMMqPiwutW52kax4/EQG/gwWxbvYkCYeL2nrNI/mG5T2F7uj5zM0qpEuaHwxxrnVXuAt6Q+
	zR/Jjq1AWWfxLHg=
X-Google-Smtp-Source: AGHT+IF4N2JVRlBpG1T/QPKg1+XOsCej1L+ouNhpRhI4mzQ4NrsbquZWlOFokiZosxt9dmmJbsak8w==
X-Received: by 2002:a17:906:d555:b0:ab3:85eb:377c with SMTP id a640c23a62f3a-ab662a63a50mr315122066b.17.1737634997388;
        Thu, 23 Jan 2025 04:23:17 -0800 (PST)
Date: Thu, 23 Jan 2025 13:23:15 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Manuel Andreas <manuel.andreas@tum.de>
Subject: Re: [PATCH v2 3/5] x86/HVM: correct read/write split at page
 boundaries
Message-ID: <Z5I0s83trDGp1x2V@macbook.local>
References: <3294f629-f91f-4b5d-9eb0-40a34aa2ec3e@suse.com>
 <fde70079-4084-4aa6-b76e-becd62a71ddb@suse.com>
 <Z5Euyc91PZsyMP6f@macbook.local>
 <41e6c4a5-d5c4-40a2-a8c6-f6b5bba70f8c@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <41e6c4a5-d5c4-40a2-a8c6-f6b5bba70f8c@suse.com>

On Thu, Jan 23, 2025 at 10:49:36AM +0100, Jan Beulich wrote:
> On 22.01.2025 18:45, Roger Pau Monné wrote:
> > On Tue, Oct 01, 2024 at 10:49:40AM +0200, Jan Beulich wrote:
> >> The MMIO cache is intended to have one entry used per independent memory
> >> access that an insn does. This, in particular, is supposed to be
> >> ignoring any page boundary crossing. Therefore when looking up a cache
> >> entry, the access'es starting (linear) address is relevant, not the one
> >> possibly advanced past a page boundary.
> >>
> >> In order for the same offset-into-buffer variable to be usable in
> >> hvmemul_phys_mmio_access() for both the caller's buffer and the cache
> >> entry's it is further necessary to have the un-adjusted caller buffer
> >> passed into there.
> >>
> >> Fixes: 2d527ba310dc ("x86/hvm: split all linear reads and writes at page boundary")
> >> Reported-by: Manuel Andreas <manuel.andreas@tum.de>
> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >> ---
> >> This way problematic overlaps are only reduced (to ones starting at the
> >> same address), not eliminated: Assumptions in hvmemul_phys_mmio_access()
> >> go further - if a subsequent access is larger than an earlier one, but
> >> the splitting results in a chunk to cross the end "boundary" of the
> >> earlier access, an assertion will still trigger. Explicit memory
> >> accesses (ones encoded in an insn by explicit or implicit memory
> >> operands) match the assumption afaict (i.e. all those accesses are of
> >> uniform size, and hence they either fully overlap or are mapped to
> >> distinct cache entries).
> >>
> >> Insns accessing descriptor tables, otoh, don't fulfill these
> >> expectations: The selector read (if coming from memory) will always be
> >> smaller than the descriptor being read, and if both (insanely) start at
> >> the same linear address (in turn mapping MMIO), said assertion will kick
> >> in. (The same would be true for an insn trying to access itself as data,
> >> as long as certain size "restrictions" between insn and memory operand
> >> are met. Except that linear_read() disallows insn fetches from MMIO.) To
> >> deal with such, I expect we will need to further qualify (tag) cache
> >> entries, such that reads/writes won't use insn fetch entries, and
> >> implicit-supervisor-mode accesses won't use entries of ordinary
> >> accesses. (Page table accesses don't need considering here for now, as
> >> our page walking code demands page tables to be mappable, implying
> >> they're in guest RAM; such accesses also don't take the path here.)
> >> Thoughts anyone, before I get to making another patch?
> >>
> >> Considering the insn fetch aspect mentioned above I'm having trouble
> >> following why the cache has 3 entries. With insn fetches permitted,
> >> descriptor table accesses where the accessed bit needs setting may also
> >> fail because of that limited capacity of the cache, due to the way the
> >> accesses are done. The read and write (cmpxchg) are independent accesses
> >> from the cache's perspective, and hence we'd need another entry there.
> >> If, otoh, the 3 entries are there to account for precisely this (which
> >> seems unlikely with commit e101123463d2 ["x86/hvm: track large memory
> >> mapped accesses by buffer offset"] not saying anything at all), then we
> >> should be fine in this regard. If we were to permit insn fetches, which
> >> way to overcome this (possibly by allowing the write to re-use the
> >> earlier read's entry in this special situation) would remain to be
> >> determined.
> > 
> > I'm not that familiar with the emulator logic for memory accesses, but
> > it seems like we are adding more and more complexity and special
> > casing.  Maybe it's the only way to go forward, but I wonder if there
> > could be some other way to solve this.  However, I don't think I
> > will have time to look into it, and hence I'm not going to oppose to
> > your proposal.
> 
> I'll see what I can do; it's been quite a while, so I'll first need to
> swap context back in.
> 
> > Are there however some tests, possibly XTF, that we could use to
> > ensure the behavior of accesses is as we expect?
> 
> Manuel's report included an XTF test, which I expect will become a part
> of XTF once this fix went in. I fear though that there is an issue
> Andrew has been pointing out, which may prevent this from happening
> right away (even if with osstest having disappeared that's now only a
> latent issue, until gitlab CI would start exercising XTF): With the
> issue unfixed on older trees (i.e. those remaining after this series
> was backported as appropriate), the new test would fail there.

All this seems (to my possibly untrained eye in the emulator) quite
fragile, so I would feel more comfortable knowing we have some way to
test functionality here don't regress.

> >> @@ -1030,7 +1040,11 @@ static struct hvm_mmio_cache *hvmemul_fi
> >>              return cache;
> >>      }
> >>  
> >> -    if ( !create )
> >> +    /*
> >> +     * Bail if a new entry shouldn't be allocated, utilizing that ->space has
> >                                                       ^rely on ->space having ...
> > Would be easier to read IMO.
> 
> Changed; I'm not overly fussed, yet at the same time I also don't really
> agree with your comment.
> 
> >> @@ -1064,12 +1079,14 @@ static void latch_linear_to_phys(struct
> >>  
> >>  static int hvmemul_linear_mmio_access(
> >>      unsigned long gla, unsigned int size, uint8_t dir, void *buffer,
> >> -    uint32_t pfec, struct hvm_emulate_ctxt *hvmemul_ctxt, bool known_gpfn)
> >> +    uint32_t pfec, struct hvm_emulate_ctxt *hvmemul_ctxt,
> >> +    unsigned long start, bool known_gpfn)
> > 
> > I think start is a bit ambiguous, start_gla might be clearer (same
> > below for the start parameter).
> 
> Fine with me - changed for all three hvmemul_linear_mmio_*(). It wasn't
> clear to me whether you also meant the local variables in
> linear_{read,write}(); since you said "parameter" I assumed you didn't.

Indeed, I think those are fine as they are local variables.

> If you did, I fear I'd be less happy to make the change there too, for
> "addr" then preferably also wanting to change to "gla". Yet that would
> cause undue extra churn.
> 
> >> @@ -1182,8 +1202,17 @@ static int linear_read(unsigned long add
> >>       * an access that was previously handled as MMIO. Thus it is imperative that
> >>       * we handle this access in the same way to guarantee completion and hence
> >>       * clean up any interim state.
> >> +     *
> >> +     * Care must be taken, however, to correctly deal with crossing RAM/MMIO or
> >> +     * MMIO/RAM boundaries. While we want to use a single cache entry (tagged
> >> +     * by the starting linear address), we need to continue issuing (i.e. also
> >> +     * upon replay) the RAM access for anything that's ahead of or past MMIO,
> >> +     * i.e. in RAM.
> >>       */
> >> -    if ( !hvmemul_find_mmio_cache(hvio, addr, IOREQ_READ, false) )
> >> +    cache = hvmemul_find_mmio_cache(hvio, start, IOREQ_READ, ~0);
> >> +    if ( !cache ||
> >> +         addr + bytes <= start + cache->skip ||
> >> +         addr >= start + cache->size )
> > 
> > Seeing as this bound checks is also used below, could it be a macro or
> > inline function?
> > 
> > is_cached() or similar?
> 
> Hmm. Yes, it's twice the same expression, yet that helper would require
> four parameters. That's a little too much for my taste; I'd prefer to
> keep things as they are. After all there are far more redundancies between
> the two functions.

Oh, indeed that would be 4 parameters.  Anyway, I guess it's fine
as-is then.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jan 23 12:42:05 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 12:42:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876202.1286568 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tawX1-000341-Jp; Thu, 23 Jan 2025 12:41:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876202.1286568; Thu, 23 Jan 2025 12:41:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tawX1-00033u-GN; Thu, 23 Jan 2025 12:41:59 +0000
Received: by outflank-mailman (input) for mailman id 876202;
 Thu, 23 Jan 2025 12:41:57 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Lw3w=UP=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tawWz-00033o-Nb
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 12:41:57 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6d830d1c-d987-11ef-a0e5-8be0dac302b0;
 Thu, 23 Jan 2025 13:41:55 +0100 (CET)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-5d0d32cd31aso1342490a12.0
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 04:41:55 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5db8942cad4sm8755221a12.60.2025.01.23.04.41.52
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 23 Jan 2025 04:41:53 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 6d830d1c-d987-11ef-a0e5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737636115; x=1738240915; 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=wSfzTFylqFzgb4b+vtSRkFUXylJhpaSO7FXRQJJL0Y0=;
        b=kvKklMU32aBgtupgy1iAp10gHQFxGRVGBAoQ9ZKhggsgsbb4/DFeiQS+mKB7MrrCNO
         8U1T54GpEpoKkK5aX4gw608wcRsHIiyTov/JidN2n2iLwzu5stQZMBRVXFtHHpUgx71i
         GpAPNH0D+5rqvlTftz7tp6Xg8/x+rMDWB/YQE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737636115; x=1738240915;
        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=wSfzTFylqFzgb4b+vtSRkFUXylJhpaSO7FXRQJJL0Y0=;
        b=ngJO64g0ntOoTOerGfnpzHY46AENHl9CkXah8LZeeJrcHkBampgM71CkLPLMQgJVNM
         dHdOSkfTDV9L7PmZTlP2RCp+QQUkZJwpO2mn0V2x4w0+YLacUHZ3yxSfmcAuUSLLY7c/
         +i31cP4OTQ7C0Yw0wwYKzfSWpV00631+LP1rFtIdg2mYFcFP5UA84QWo8pCgfqNklDvr
         wVqydeq3g1fVNbp8CDs6Zcutc2WidFAlPbyhYggACkg5KVDCXt74Pbvca2I2jZIRN96Z
         5DtpXc7jIiWhVbEwN3QOUvhBS2V/Briod4/I6zIJYh/vk7urc8un9Iv0Exty97g6CcOZ
         EuPg==
X-Gm-Message-State: AOJu0Yx3NMmQvu9HpAs+9sd8OLfAM99i8eRyfMM+53dX1AH7H0nxvslS
	1E59ZajcB2n6cIfewyfdzOGP2Bte6Rs143Gvs3ywVgXnr7b81SbSaFQI6yHNT1A=
X-Gm-Gg: ASbGncsIv42bQ3VxnVA4BoKtp+xaEoH6moe4a956ZdsboU5khZyFRytL7B0gA5bDOZr
	/tnjd3MM9YEcz6Lx85mfzSqZU2vaRG6OkJh+I/HASWgXmyGToB5BDrO98JiDbSyHyLf4urjPf0d
	nOXor1I2RDVvR2O7Gezphqryy4KhDCFavc3Gj/V8dlLri8LDJa7ELOOZEr+Qe3e7bzdeHkp/GkA
	YWTAEX2Km4Jk0cDBvk1x1dQ3J3JyvSfqm8TD8sXGRzmGUpN7OVbLUoby5J3V8tw165b78X1ku1R
	2PKjbZo/bYBeyzU=
X-Google-Smtp-Source: AGHT+IHMi9avWuM8RRIxXQhv9boDsJdHvKz0oBUJ4L3IHU5SBb/3Y0qRrQo+Dj82ROdWmdUfw5Gvog==
X-Received: by 2002:a05:6402:2745:b0:5d0:bf5e:eb8 with SMTP id 4fb4d7f45d1cf-5db7db07846mr57108083a12.23.1737636115052;
        Thu, 23 Jan 2025 04:41:55 -0800 (PST)
Date: Thu, 23 Jan 2025 13:41:51 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
	Kevin Tian <kevin.tian@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>
Subject: Re: [PATCH v3 02/12] x86/HVM: improve CET-IBT pruning of ENDBR
Message-ID: <Z5I5D_uVxijLF6sK@macbook.local>
References: <293e5aef-8843-461c-bc96-709a605b2680@suse.com>
 <537b0d9c-1936-4cf5-a012-d50b1097a22d@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <537b0d9c-1936-4cf5-a012-d50b1097a22d@suse.com>

On Mon, Feb 26, 2024 at 05:42:20PM +0100, Jan Beulich wrote:
> __init{const,data}_cf_clobber can have an effect only for pointers
> actually populated in the respective tables. While not the case for SVM
> right now, VMX installs a number of pointers only under certain
> conditions. Hence the respective functions would have their ENDBR purged
> only when those conditions are met. Invoke "pruning" functions after
> having copied the respective tables, for them to install any "missing"
> pointers.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> This is largely cosmetic for present hardware, which when supporting
> CET-IBT likely also supports all of the advanced VMX features for which
> hook pointers are installed conditionally. The only case this would make
> a difference there is when use of respective features was suppressed via
> command line option (where available). For future hooks it may end up
> relevant even by default, and it also would be if AMD started supporting
> CET-IBT; right now it matters only for .pi_update_irte, as iommu_intpost
> continues to default to off.
> 
> Originally I had meant to put the SVM and VMX functions in presmp-
> initcalls, but hvm/{svm,vmx}/built_in.o are linked into hvm/built_in.o
> before hvm/hvm.o. And I don't think I want to fiddle with link order
> here.
> ---
> v3: Re-base.
> v2: Use cpu_has_xen_ibt in prune_{svm,vmx}().
> 
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -161,10 +161,15 @@ static int __init cf_check hvm_enable(vo
>      else if ( cpu_has_svm )
>          fns = start_svm();
>  
> +    if ( fns )
> +        hvm_funcs = *fns;
> +
> +    prune_vmx();
> +    prune_svm();

Isn't it actually the opposite of pruning.  What the helpers do is
fill all the pointers in the structure.  I would rather name them
{vmx,svm}_fill_hvm_funcs() or similar.  And possibly pull the
cpu_has_xen_ibt check outside the functions:

if ( cpu_has_xen_ibt )
{
    /*
     * Now that svm_function_table was copied, populate all function pointers
     * which may have been left at NULL, for __initdata_cf_clobber to have as
     * much of an effect as possible.
     */
    vmx_fill_hvm_funcs();
    svm_fill_hvm_funcs();
}

I would be nice to avoid directly exporting more vmx and smv specific
helpers, as if we ever want to compile out vmx or svm it would be more
churn to deal with those.  I however cannot think of any good way to
do this here, so it's fine to export those functions.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jan 23 12:44:05 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 12:44:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876209.1286577 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tawZ2-0003i2-T4; Thu, 23 Jan 2025 12:44:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876209.1286577; Thu, 23 Jan 2025 12:44:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tawZ2-0003hv-QJ; Thu, 23 Jan 2025 12:44:04 +0000
Received: by outflank-mailman (input) for mailman id 876209;
 Thu, 23 Jan 2025 12:44:03 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Lw3w=UP=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tawZ1-0003hp-Kz
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 12:44:03 +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 b8c72449-d987-11ef-99a4-01e77a169b0f;
 Thu, 23 Jan 2025 13:44:01 +0100 (CET)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-ab2b29dfc65so144258266b.1
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 04:44:01 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab384d2df47sm1049144466b.85.2025.01.23.04.43.59
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 23 Jan 2025 04:43:59 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b8c72449-d987-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737636241; x=1738241041; 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=Jz2VcQWO8EJikEJJUCtGoQ2xN6AMbnTI9F+jtpLAFDk=;
        b=Qxwm1lPLt/yNvDLXwJwY7NWw29eGFPZonLMeVx4BGB6zTbXw7kZUcWtCeOKJBvLhCh
         zl0VtDz8+0b7KMdddKLEgRZZvoBykecO1BHOC4GX62358onfSuh3CYNw8bt637Q2rTCH
         wSYccnFhh8cLhsolpL6BGrq7OLDP81J8gWwXE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737636241; x=1738241041;
        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=Jz2VcQWO8EJikEJJUCtGoQ2xN6AMbnTI9F+jtpLAFDk=;
        b=GPYCHtnOR4xC8yRxAsvBlKdNDl7z/OZMpMMrNyvi/TVBK84JoQee5rDXIEm8t+DtlC
         RnGfpPQfQhn0qgyBLVkf2yZLvjY//dWVsRXSAHvKmGUa3GliJRUDO4F+cghT3VeUuaTl
         GsqwK+i8uugKOILrmaIEQsLwyia3rUG8plbrZUnu/lfsNqRC5qWAiNDx3mYaMEu6Uzc3
         1jobYb6EU4BraweRvb9Ev4aHJFRcttESb0QOPb9caupGPf9z5T6yguUul7G/7Lu3JoUo
         X2XdfET6z07Bn1KOA7dn8KAq1We2o3Mu7DJZ9oIOyWkQyGxQuA3u4yLtSz3LJAoYrfOy
         5PEw==
X-Gm-Message-State: AOJu0YxxbqxgjVLBQkXZoa7qaO9kIkt/mR9g+RZzBe6wHplBJ6lRN7MP
	RMeDFQYp6nrdCswInH9RT7saMJnJPkSl2F5rFMoqwNJca0+oLXIhB2B7YPRPmys=
X-Gm-Gg: ASbGncuRsFUvpvBD1MmcmteumJcI0FLT8ZB17nZrsxJ18UhKlkSTOSbSwUDSAwWqUve
	ig/sP+OcnmaupumL70ChTOTeYcti5zA2KhZJw3sgkXlS9Q1a+wWebuaq9byFzzEfZVcsL0qfTM6
	G9nEb6QVF/2yIhmYc6/JM4PWXx5jDwLqB00F/rnOrTMlemEC1rDEKPjoV7M0glhAEgr5EWEphy5
	qcV43Et4tTqSsUUY2CytruclKl8CFfS8zCZVdn73QrhXQNEhDIg5lDpH/Am8VZZyPFTSgMbZKtc
	Xfd7Q68KqTlT5Qc=
X-Google-Smtp-Source: AGHT+IE0yCa5ExwrU3XbJNXsOQLxR9h/rczerUBUHXZnbagyXZJfZAajGiAu3eveZrMI9fFqnwAsSA==
X-Received: by 2002:a17:907:3e1c:b0:aa6:a7ef:7f1f with SMTP id a640c23a62f3a-ab38b0bb338mr2450295066b.11.1737636241137;
        Thu, 23 Jan 2025 04:44:01 -0800 (PST)
Date: Thu, 23 Jan 2025 13:43:58 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>
Subject: Re: [PATCH for-4.20 v3 2/4] x86/HVM: correct read/write split at
 page boundaries
Message-ID: <Z5I5jsqp7_MG_6dJ@macbook.local>
References: <729f7896-55b7-4b5b-a7e9-6eb0420e0b14@suse.com>
 <5bd5cad3-698e-420b-aa97-e84763df0420@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <5bd5cad3-698e-420b-aa97-e84763df0420@suse.com>

On Thu, Jan 23, 2025 at 11:31:19AM +0100, Jan Beulich wrote:
> The MMIO cache is intended to have one entry used per independent memory
> access that an insn does. This, in particular, is supposed to be
> ignoring any page boundary crossing. Therefore when looking up a cache
> entry, the access'es starting (linear) address is relevant, not the one
> possibly advanced past a page boundary.
> 
> In order for the same offset-into-buffer variable to be usable in
> hvmemul_phys_mmio_access() for both the caller's buffer and the cache
> entry's it is further necessary to have the un-adjusted caller buffer
> passed into there.
> 
> Fixes: 2d527ba310dc ("x86/hvm: split all linear reads and writes at page boundary")
> Reported-by: Manuel Andreas <manuel.andreas@tum.de>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jan 23 12:44:39 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 12:44:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876215.1286588 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tawZb-0004CM-4b; Thu, 23 Jan 2025 12:44:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876215.1286588; Thu, 23 Jan 2025 12:44:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tawZb-0004CF-1u; Thu, 23 Jan 2025 12:44:39 +0000
Received: by outflank-mailman (input) for mailman id 876215;
 Thu, 23 Jan 2025 12:44:37 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=nhpA=UP=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tawZZ-0004C1-Q5
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 12:44:37 +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 cd29b17a-d987-11ef-99a4-01e77a169b0f;
 Thu, 23 Jan 2025 13:44:35 +0100 (CET)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-4364a37a1d7so8578425e9.3
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 04:44:35 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438b318a38bsm63727285e9.6.2025.01.23.04.44.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 23 Jan 2025 04:44:35 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: cd29b17a-d987-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737636275; x=1738241075; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ZX31MC31Y7iTaz7/yHdlVhMl6BCpgyjs1QWm3fml3VE=;
        b=OdWDk5D8ZAbQFj+UV3c0/YvaisKuK3cY7ziGG/f08ZpA9XtnXzzbiPBPAzQkhhRI7e
         Bdlj/3xyjQgfz0X1amUVQcCP5qizr1crhEGhQq9l5rEQTX7HgOPPa16QJ31RT8QAVEzZ
         +DcEbquqQcJtYrmiOLheDjGoAwu+IGOt6SHBxQay3jvqlRkQ6ZhlylQGAmcLDFo31cU3
         A01fP4wF45vDif9dgq/Ee4zOE9QDQ15D8+TiETlHwnSyFrQDcYFjglLRhbXnwHTXaeGC
         eWAl2fegEymg3lzYSc0dru4X7ixgTXPbabVjJgTLFOEeBtPKdp8SzS8/jVuWsqsfINLj
         oExA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737636275; x=1738241075;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ZX31MC31Y7iTaz7/yHdlVhMl6BCpgyjs1QWm3fml3VE=;
        b=cPTQshmPU+TLFDjm0HNR9PTuPg43CdqzCMKjyEUagtYGZkh6miyUVRKd/v4zgCqi23
         WZxbQ26fIxuMMlCs2yO4NR1elc+2a7wbf7lEa8Z6ErfzgyItxKhI1E2GY4IxkbOxamQV
         XexTQMI0Wigw+ECjkLe9UJQ+7TwXmr/0B4tdgok5x6fNhucJp3EzSUmzCZFZBWnjySg+
         XBAcoaWlV/8PgHHM9aoWYxBq6ZzkH6kx4MD38H8+RE8J9qhdxPZiXQI4PsTigkI5DCjN
         wpONhrSEj5qhRiWvGfOIxJF8XWGAAQLRWzXT56eBqoUXY15PCHHi+NDQTgwFgIishZB9
         dZbw==
X-Gm-Message-State: AOJu0Yym//ifuTaXK96rsaBZTZnpIs6dkL29dtIKU5oWa2BCtl+1BuQ4
	N0l6ZexMiy3e6qMcy0gl9mR5uBGvv1u5Qm7wCZIqoYYHTkmFCb7HYAENK1RjHpZT64Jl7r7AyPo
	=
X-Gm-Gg: ASbGncvughjLDX3mYJuop4Ax9sKZ3nunDt+BZj3YsrxftPH+zD9UnUxGJHb2fQJCZY1
	G/rsuK+eRiQFHfWDrgDThX2REC2RzC5FPRXDdrmIKygmZhzgOguWsJWeRTBd+/kWsBsTh3wEqB3
	Q4OGGCJ+H1T4SitcnWg1QfowVMVSYYighXXiy5UEev94XPo/SS19zkEBiLR//U+ntGJmmc2zMMQ
	BW0qKxAjZEBzVs/l4yGw9yQFIHqKDrELpXVbj1L7nrM2PssHuXXfCGSDG30n1Wpn2v8WnTpJlG0
	IO39vrExADOIzbeiOuzDkQC7XMfvYb1GFDpQ9R6U90biXDKA/67g88zASwuK+a0UCQ==
X-Google-Smtp-Source: AGHT+IEJr9elbdIAvn2z8nFhYCsviiWuQRnEr2ugYfBycK8Gpv4FtL4zt3Nyzsb0F6aqiuLnR3fWbA==
X-Received: by 2002:a05:600c:3149:b0:434:e9ee:c2d with SMTP id 5b1f17b1804b1-4389144eee4mr209414795e9.26.1737636275355;
        Thu, 23 Jan 2025 04:44:35 -0800 (PST)
Message-ID: <10a655b0-1cdc-4e14-8fcf-221336ccc0ac@suse.com>
Date: Thu, 23 Jan 2025 13:44:34 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/PV: further harden guest memory accesses against
 speculative abuse
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>
References: <a537dd1e-bbd3-4ef8-8014-6bb432484c57@suse.com>
 <Z5IuEq9Lauhn8glx@macbook.local>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <Z5IuEq9Lauhn8glx@macbook.local>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 23.01.2025 12:54, Roger Pau Monné wrote:
> On Tue, Nov 05, 2024 at 02:56:42PM +0100, Jan Beulich wrote:
>> The original implementation has two issues: For one it doesn't preserve
>> non-canonical-ness of inputs in the range 0x8000000000000000 through
>> 0x80007fffffffffff. Bogus guest pointers in that range would not cause a
>> (#GP) fault upon access, when they should.
>>
>> And then there is an AMD-specific aspect, where only the low 48 bits of
>> an address are used for speculative execution; the architecturally
>> mandated #GP for non-canonical addresses would be raised at a later
>> execution stage. Therefore to prevent Xen controlled data to make it
>> into any of the caches in a guest controllable manner, we need to
>> additionally ensure that for non-canonical inputs bit 47 would be clear.
>>
>> See the code comment for how addressing both is being achieved.
>>
>> Fixes: 4dc181599142 ("x86/PV: harden guest memory accesses against speculative abuse")
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> ---
>> RFC: Two variants of part of the logic are being presented, both with
>>      certain undesirable aspects: The first form is pretty large and
>>      ugly (some improvement may be possible by introducing further
>>      helper macros). The alternative form continues to use RCR, which
>>      generally would be nice to do away with. Then again that's also
>>      slightly smaller generated code.
> 
> Oh, I assume that's why there's a hardcoded .if 1, I was wondering
> about that.  What's the specific issue with using rcr?

It's slower than SHL. Albeit - checking a few places - not as much as I
thought I remembered it would be.

>  And why is the
> more complex set of macros that use setc plus a shl better?

They're slightly longer (beyond the source complexity), but (presumably)
a little faster.

> Why not use cmovc:
> 
> mov $(1 << 63), \scratch1
> cmovc \scratch1, \scratch2
> 
> AFAICT \scratch1 is not used past the btr instruction, and hence can
> be used for the cmovc?

Such an alternative was already considered back at the time:
https://lists.xen.org/archives/html/xen-devel/2021-02/msg01067.html.
Granted I was wrong there about needing a 3rd scratch register, but
the code size consideration remains - we have dozens of instances of
this macro in the resulting binary, after all. Yet ftaod, this isn't
to mean we can't re-consider. Given the above I'm inclined though to
go the RCR route.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 23 12:45:52 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 12:45:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876224.1286598 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tawaj-0004nI-Kd; Thu, 23 Jan 2025 12:45:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876224.1286598; Thu, 23 Jan 2025 12:45:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tawaj-0004nB-Gf; Thu, 23 Jan 2025 12:45:49 +0000
Received: by outflank-mailman (input) for mailman id 876224;
 Thu, 23 Jan 2025 12:45: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
 <SRS0=AE9i=UP=invisiblethingslab.com=marmarek@srs-se1.protection.inumbo.net>)
 id 1tawai-0004n3-Kn
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 12:45:48 +0000
Received: from fhigh-a6-smtp.messagingengine.com
 (fhigh-a6-smtp.messagingengine.com [103.168.172.157])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f69ceb7c-d987-11ef-a0e5-8be0dac302b0;
 Thu, 23 Jan 2025 13:45:46 +0100 (CET)
Received: from phl-compute-09.internal (phl-compute-09.phl.internal
 [10.202.2.49])
 by mailfhigh.phl.internal (Postfix) with ESMTP id 2B4CD11401D2;
 Thu, 23 Jan 2025 07:45:45 -0500 (EST)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-09.internal (MEProxy); Thu, 23 Jan 2025 07:45:45 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 23 Jan 2025 07:45:42 -0500 (EST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f69ceb7c-d987-11ef-a0e5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm2; t=1737636345;
	 x=1737722745; bh=TofuWM/fl1i1a2ILH9a2CAZzsCjC8894mdpIvVDFors=; b=
	G5bWwLAqhkIMmHYH4NcSlOzKVL5ZQc9THB+qvoxChNpymTE29Wo0tuvf/Keyek4a
	HYWgaMKYYQDtaDafA+dr7cztILUobfwRuSGu9gmZdib7s083RheLmZJi0rArWEX1
	TB0d4Lf6Mz4hB6QgmKAtZ0Vly6eyY+l+hnywfqnL8NVkb2c3x7W/FqrskiMecDyA
	TJkxFqVo3kEktaPpYXR/nx7wyA1GiuQ6stYr1jE8n8uVTq/SiAxT3o3kh0R4WnIg
	bhd4VBeKjYETMOzAsrayX0wpJSv27lTcOwUS349NMkXwW0lgPpeu51yF5bQweqzY
	4f4HmIudEEU6zYdTFucqpg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:subject:subject:to
	:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=
	1737636345; x=1737722745; bh=TofuWM/fl1i1a2ILH9a2CAZzsCjC8894mdp
	IvVDFors=; b=XLpV2HmQSds/RKll3XcSGmGv3tXcJDTJd+USTvwhiey5e7R5uNJ
	heCW/xuV97sTEzUsrqw+yTUs/h//In6gtOivVgHsBsu5RIH5u3XIIxZseaHDD5Jf
	ercjqsiqUiTghPGCQA1jeU3N6B2AxgdU2x1wn4gaEJkwB32FUpiSjHk84SiJBrtO
	Ooo0dOV5tv3aElq/fk/vkhXVa8+klSX/2rJlf7ajTB4Uc7gFPvahVhzeMeklj1/d
	xmJVoc1BYYHCZvPlu604HNFPjzUst3iGIFrcepwTjs2uAgxxlx/Inlta0dgExGWP
	xXwmwWxFxM2Ig5kSkSAhuCzC2sElWrwMv4Q==
X-ME-Sender: <xms:-DmSZ0SwfLolv3InxvjN8ZB-qsYk31AKWPQNOWKuIBH3E7KVJOPe3A>
    <xme:-DmSZxxBGizebaBvs7LC68RSf7ZCFyj9pFaTgufBPImY4DpTJGSZcyk8w4DE3Du3y
    AC93Uw3ShqrHw>
X-ME-Received: <xmr:-DmSZx053aJVoZqGD6eZCoS0MedSuQf3d3JzSXSmUheJ8Q0qg6doA1tQh9aZtIBxqSN7rQ6Q4fDTGzOL9HhBNUXFg7qq9edkPg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrudejgedgudejtdcutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp
    uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg
    hnthhsucdlqddutddtmdenucfjughrpeffhffvvefukfhfgggtuggjsehgtderredttdej
    necuhfhrohhmpeforghrvghkucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoe
    hmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucgg
    tffrrghtthgvrhhnpeevueejteegleelteduueevhfetgfffjeevtddvgfeiveehteehle
    egueelvdejveenucffohhmrghinhepghhithhlrggsrdgtohhmnecuvehluhhsthgvrhfu
    ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehinhhvih
    hsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohepuddtpdhmohgu
    vgepshhmthhpohhuthdprhgtphhtthhopehtvgguugihrdgrshhtihgvsehvrghtvghsrd
    htvggthhdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhj
    vggtthdrohhrghdprhgtphhtthhopegrnhgurhgvfidrtghoohhpvghrfeestghithhrih
    igrdgtohhmpdhrtghpthhtohepjhgsvghulhhitghhsehsuhhsvgdrtghomhdprhgtphht
    thhopehjuhhlihgvnhesgigvnhdrohhrghdprhgtphhtthhopehsshhtrggsvghllhhinh
    hisehkvghrnhgvlhdrohhrghdprhgtphhtthhopehrohhgvghrrdhprghusegtihhtrhhi
    gidrtghomhdprhgtphhtthhopehluhhkrghsiieshhgrfihrhihlkhhordhplhdprhgtph
    htthhopeguphhsmhhithhhsegrphgvrhhtuhhsshholhhuthhiohhnshdrtghomh
X-ME-Proxy: <xmx:-DmSZ4DLICvu5itXTjjk7XALaw7IkvXG0aklmPDNmeH5bOg0cq1QXg>
    <xmx:-DmSZ9hpD6oD0Kt9WdZJwUeGoawQOOL1wNulKTpsoWGRYGa1I0NuPQ>
    <xmx:-DmSZ0q9rqV61EsK0Si1KXKs7fMMqHLTXC5EqUjK0g-WLEFaFDQlng>
    <xmx:-DmSZwimTKg6LEDwoz3viP1cORbZCgFey3IcViO1bhLQ4XRZkof8Kg>
    <xmx:-TmSZyYiBNO9xT_AkTzyb_TlnmQm7CilKGi9e3MrtBluCStLgj51_pLg>
Feedback-ID: i1568416f:Fastmail
Date: Thu, 23 Jan 2025 13:45:40 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Teddy Astie <teddy.astie@vates.tech>
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>,
	Lukasz Hawrylko <lukasz@hawrylko.pl>,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Mateusz =?utf-8?B?TcOzd2th?= <mateusz.mowka@intel.com>
Subject: Re: [XEN RFC PATCH v5 0/5] IOMMU subsystem redesign and PV-IOMMU
 interface
Message-ID: <Z5I59HC77QxpPtJG@mail-itl>
References: <cover.1737470269.git.teddy.astie@vates.tech>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="32bNM4k22C4EMmMr"
Content-Disposition: inline
In-Reply-To: <cover.1737470269.git.teddy.astie@vates.tech>


--32bNM4k22C4EMmMr
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Thu, 23 Jan 2025 13:45:40 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Teddy Astie <teddy.astie@vates.tech>
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>,
	Lukasz Hawrylko <lukasz@hawrylko.pl>,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Mateusz =?utf-8?B?TcOzd2th?= <mateusz.mowka@intel.com>
Subject: Re: [XEN RFC PATCH v5 0/5] IOMMU subsystem redesign and PV-IOMMU
 interface

On Tue, Jan 21, 2025 at 04:13:20PM +0000, Teddy Astie wrote:
> This work has been presented at Xen Summit 2024 during the
>   IOMMU paravirtualization and Xen IOMMU subsystem rework
> design session.
>=20
> Operating systems may want to have access to a IOMMU in order to do DMA
> protection or implement certain features (e.g VFIO on Linux).
>=20
> VFIO support is mandatory for framework such as SPDK, which can be useful=
 to
> implement an alternative storage backend for virtual machines [1].
>=20
> In this patch series, we introduce in Xen the ability to manage several
> contexts per domain and provide a new hypercall interface to allow guests
> to manage IOMMU contexts.
>=20
> The VT-d driver is updated to support these new features.
>=20
> [1] Using SPDK with the Xen hypervisor - FOSDEM 2023
> ---
> Cc: Marek Marczykowski-G=C3=B3recki <marmarek@invisiblethingslab.com>
>=20
> PCI Passthrough now work on my side, but things are still feels quite bri=
ttle.
>=20
> Changed in v2 :
> * fixed Xen crash when dumping IOMMU contexts (using X debug key)
> with DomUs without IOMMU
> * s/dettach/detach/
> * removed some unused includes
> * fix dangling devices in contexts with detach
>=20
> Changed in v3 :
> * lock entirely map/unmap in hypercall
> * prevent IOMMU operations on dying contexts (fix race condition)
> * iommu_check_context+iommu_get_context -> iommu_get_context and check fo=
r NULL
>=20
> Changed in v4 :
> * Part of initialization logic is moved to domain or toolstack (IOMMU_ini=
t)
>   + domain/toolstack now decides on "context count" and "pagetable pool s=
ize"
>   + for now, all domains are able to initialize PV-IOMMU
> * introduce "dom0-iommu=3Dno-dma" to make default context block all DMA
>   (disables HAP and sync-pt), enforcing usage of PV-IOMMU for DMA
>   Can be used to expose properly "Pre-boot DMA protection"
> * redesigned locking logic for contexts
>   + contexts are accessed using iommu_get_context and released with iommu=
_put_context
>=20
> Changed in v5 :
> * various PCI Passthrough related fixes
>   + rewrote parts of PCI Passthrough logic
>   + various other related bug fixes
> * simplified VT-d DID (for hardware) management by only having one map in=
stead of two
>   (pseudo_domid map was previously used for old quarantine code then recy=
cled for PV-IOMMU
>    in addition to another map also tracing Domain<->VT-d DID, now there i=
s only one
>    map tracking both making things simpler)
> * reworked parts of Xen quarantine logic (needed for PCI Passthrough)
> * added cf_check annotations
> * some changes to PV-IOMMU headers (Alejandro)
>=20
> TODO:
> * add stub implementations for bissecting needs and non-ported IOMMU impl=
ementations
> * fix some issues with no-dma+PV and grants
> * complete "no-dma" mode (expose to toolstack, add documentation, ...)
> * properly define nested mode and PASID support
>=20
> * make new quarantine code more unity region aware (isolate devices with
>   different reserved regions regions using separate 'contexts')
> * find a way to make PV-IOMMU work in DomUs (they don't see machine bdf)
> * there are corner cases with PV-IOMMU and to-domain Xen PCI Passthrough
>   (e.g pci-assignable-remove will reassign to context 0, while the driver
>    expects the device to to be in context X)

Thanks for the updated patches. I have run them through gitlab-ci, and
here are some observations:
- I needed to disable CONFIG_AMD_IOMMU (it fails to build, as expected at t=
his point)
- I needed to disable pvshim (it fails to build)
- fails to build with clang: https://gitlab.com/xen-project/people/marmarek=
/xen/-/jobs/8931373789/viewer#L3525
- gcc-ibt build fails: https://gitlab.com/xen-project/people/marmarek/xen/-=
/jobs/8931373785#L1314
- fails to build for ARM (both 32 and 64) and PPC64
- QEMU smoke test panic with PV dom0, looks like it runs on AMD, so it
  may be related to the disabled CONFIG_AMD_IOMMU, but I wouldn't expect
  it to panic on _PV_ dom0 boot...
- PVH dom0 fails to boot (on real hw) with a lot of VT-d faults: https://gi=
tlab.com/xen-project/people/marmarek/xen/-/jobs/8931373875
- PCI passthrough (with PV dom0) results in a lot of VT-d faults: https://g=
itlab.com/xen-project/people/marmarek/xen/-/jobs/8931373881

Note this uses only this series, but plain Linux (appears to be 6.1.19).
IIUC if one doesn't try to configure PV-IOMMU specifically (non-default
contexts) it should still work.

BTW Linux says it detected "Xen version 4.19." - shouldn't it report
4.20 already at this point in release cycle?

All results:
https://gitlab.com/xen-project/people/marmarek/xen/-/pipelines/1637849303

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

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

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmeSOfQACgkQ24/THMrX
1yy23Qf/VqNuCnbQxBHQKAHSWNWRUK0dvuqV2bJy4fuSf3Bgmeg/Sz/Z/gC18wlE
8j2L0Er75l83wtLmBHBotoRbDgvV63sLraXxxUoG3JLBwTvW41p1ls+gYIDaGP3k
qW1poGb2kFmCHg2KchpIkM6MnKaYSIM3vqcTrnENx4KD02PyBrrhL7kOb154Qy2E
bgIEDKmerrgiZ17FsV6VIUUk1KVuX5uiWPmSGQl9hWD78A1wlmhrY7uOKXzzGn3t
+b4Qz/ybU0JMg6+eShGECJ0tMD65eCdEo98JSk6nGhVIuQA0H4FZC5KcF6IB5zag
hHipWqLBnfs9rFNrQaXpQpdwjvpTdQ==
=D+Ls
-----END PGP SIGNATURE-----

--32bNM4k22C4EMmMr--


From xen-devel-bounces@lists.xenproject.org Thu Jan 23 12:48:38 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 12:48:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876232.1286608 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tawdN-0005NG-Vj; Thu, 23 Jan 2025 12:48:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876232.1286608; Thu, 23 Jan 2025 12:48:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tawdN-0005N9-T5; Thu, 23 Jan 2025 12:48:33 +0000
Received: by outflank-mailman (input) for mailman id 876232;
 Thu, 23 Jan 2025 12:48:33 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=nhpA=UP=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tawdN-0005N3-1l
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 12:48:33 +0000
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com
 [2a00:1450:4864:20::42b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 59660d26-d988-11ef-99a4-01e77a169b0f;
 Thu, 23 Jan 2025 13:48:31 +0100 (CET)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-385ddcfc97bso750810f8f.1
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 04:48:31 -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
 ffacd0b85a97d-38bf3279388sm19070155f8f.75.2025.01.23.04.48.29
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 23 Jan 2025 04:48:30 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 59660d26-d988-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737636510; x=1738241310; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Uubn3B4AJmy/tkkVoElarXDljvIi0RFazkyKWEB01/Y=;
        b=JXaNh18EPgSqWCGcHgwXInXIq+ZWKbX0WpHuKbMkBTtwtuqvS/WzHG6Ukc8VoBeAwd
         XtaqdwlPBertCFaxhPHWjdcfF9kooqBfzziK5auBGS0E3BUosazvRWfyB+dUgw8mEj2l
         KX69AQywxTojdKs0JhBCbCyrglK/mCbSxLAqE/ZN+jvfJGIexOs9MXgsv8C2Wb1IZqFI
         u+poqDMKcoZw9XdQZIpQLby7sQw0O+wM7Ilf53L7AYoa3l+0ultmZvre2gl9HJtDa+uK
         s6c0pYTnfAVKSp5S/n2nWnn2kgLA993Pq5k1zUmB1Dd5OhXOwZ6SwmcJKuZ7YVmNbzXr
         MXxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737636510; x=1738241310;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Uubn3B4AJmy/tkkVoElarXDljvIi0RFazkyKWEB01/Y=;
        b=LY/qzQRldYev6TIamRGp9swZiRTH9qMBtvIuBoW24a5Diqmim2L/QG0QAHwi1HQ6la
         p41VcfcYMQnTiDGZf/ZF3u3KYwiGZoVlkaw2KopQOl3Z4P6f5mgKTcVveIScz1AtYfXR
         kkegRysy9k77uBv02brhpeCU4+4HTi24wRp9yxhOphnTJvdTPrWe6oUEAWctCCDS50P8
         1q7Sq66Z7Vm9WVAq4XhGhfhpYTRVM7JmIsvszBs+2CYUqH07lfRzChcRSMIv7FLF/k8B
         j55zKypuAV22u2uUJNz31WsyirLuVPSfmzq4KmOeNFR5h6syoOQPRQlA/RS39TA+cws+
         5LDQ==
X-Gm-Message-State: AOJu0Yxix8zhmmGPzwXBfGuNiXMMS0KWLOr/0VxfBIABYYgTTjtIF2KQ
	Pi1HQtcScS7jkIolIiWs5KzgpGS4+dL60pnPlFq68jnKugViOa4FpuSQ2vkABQ==
X-Gm-Gg: ASbGnctHQcvC7mJPE3/Eu2MnChZxqxfN9+u2TNky4mkqM3S59Pd/nxNDnUKNUKYTU/U
	awawretC5JIXKpN60gfrDx4XoUhZt2pIGkWwuf7wPuInPttzh7IgDlLfpfbQdWFHvY2Kklows8l
	DrsJcHbtUj3zZQCbobmiOSf0gEaqGKJ2gzJ+kSCJFDg5AoJjRwppFGHPSrhZveuWTAd1C1sAQiM
	sQvRbkKCmuQ0QcRSHBGtfJhW/rAKmSCqPH18U+V8gj1d8IVYRcxsng5DRIhUOd35uKZmADF5Mfu
	Om7nKw53DsUFVP3kcnELb3VhVMcKtnR+XGrgvzdDeAwKJFTs9vAGjyEbs3timQPpDg==
X-Google-Smtp-Source: AGHT+IFVUwsy25aSgRw3fH0pg96VhrfWu1tcolophVQZLaj0kx20uVVEJX2dBFKOinjlfWMlYreklw==
X-Received: by 2002:a5d:64e9:0:b0:38a:86fe:52b3 with SMTP id ffacd0b85a97d-38bf56639edmr22787558f8f.22.1737636510603;
        Thu, 23 Jan 2025 04:48:30 -0800 (PST)
Message-ID: <8e19c066-2d76-4f4d-9ccc-ed57e02143ab@suse.com>
Date: Thu, 23 Jan 2025 13:48:29 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN RFC PATCH v5 0/5] IOMMU subsystem redesign and PV-IOMMU
 interface
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>
Cc: xen-devel@lists.xenproject.org, Andrew Cooper
 <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Lukasz Hawrylko <lukasz@hawrylko.pl>,
 "Daniel P. Smith" <dpsmith@apertussolutions.com>,
 =?UTF-8?Q?Mateusz_M=C3=B3wka?= <mateusz.mowka@intel.com>,
 Teddy Astie <teddy.astie@vates.tech>
References: <cover.1737470269.git.teddy.astie@vates.tech>
 <Z5I59HC77QxpPtJG@mail-itl>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <Z5I59HC77QxpPtJG@mail-itl>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 23.01.2025 13:45, Marek Marczykowski-Górecki wrote:
> BTW Linux says it detected "Xen version 4.19." - shouldn't it report
> 4.20 already at this point in release cycle?

Not only at this point, but throughout the release cycle. Yet I fear I
haven't seen such, so I wouldn't be able to look into it.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 23 13:18:57 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 13:18:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876242.1286618 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tax6b-0001uC-7k; Thu, 23 Jan 2025 13:18:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876242.1286618; Thu, 23 Jan 2025 13:18:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tax6b-0001u5-50; Thu, 23 Jan 2025 13:18:45 +0000
Received: by outflank-mailman (input) for mailman id 876242;
 Thu, 23 Jan 2025 13:18: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 <SRS0=nhpA=UP=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tax6a-0001ty-08
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 13:18:44 +0000
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com
 [2a00:1450:4864:20::431])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9144c3a7-d98c-11ef-a0e5-8be0dac302b0;
 Thu, 23 Jan 2025 14:18:42 +0100 (CET)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-386329da1d9so482467f8f.1
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 05:18:42 -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
 ffacd0b85a97d-38bf32151f1sm19534961f8f.14.2025.01.23.05.18.41
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 23 Jan 2025 05:18:42 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9144c3a7-d98c-11ef-a0e5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737638322; x=1738243122; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=sHEDMNPetKm/UfJaod/2s4iViLSNkUfQuWFOwKPC9L4=;
        b=YZFEBy0LsQVo0OoYe8mY9DGPcQl1EW3ayESpNC3YIa6o+9jv6U+e3RIjqRh3zXU+VJ
         lTCLWJhbWeSAIW3TvWrBT3z2aRB9uhVqRAerLMZsKsA0ngM3WwubBxrAfmaDzeZP6lLp
         bVzHq9jr/SJGCCsb/nLEf72kdIAOQC3rwEdJMZgAScAZsTd2brigOyI9ZoP3ffQRomae
         uOYsTMNI6h373ApVkcaxGWAvB+aJMT00lt4shQ3Q0BmmZgaVl7eAhKXwTeUkdOncjLzv
         D0at/w1vTcs3YOehUuv+H2dmrP8DE07SdhJrPHb7Ajva0khz9QBjYyWVFU2RGzQILd/t
         zF8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737638322; x=1738243122;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=sHEDMNPetKm/UfJaod/2s4iViLSNkUfQuWFOwKPC9L4=;
        b=t1BmdYUIXf3/IygjknPEW0jveuU9vDgzPlRYnJojxf8XiySiu6ttYrgKlsMOeVjFgZ
         0FINudpA0PpWN6v2CkZ55Uyn03KvPt0XhDXA6TA5dxytJn1DgoaWAjAfqxL2LXkqegmZ
         /IyAhHI/MAdxRXflD3UkeAcUHbEz19QGQKTmS0IaUb6G9LklLbTJZnK4H0fdu9HEEIE7
         +WvyQuqzafte0LdY9Yz6VODUPuRIyQPRcnT1AIZvArMrgp/UhHovJuKx/N0YLDGEUeiv
         0SysvOsNAlFkeOEfqJ8sGIU6dsXQ/Cr5/B81JeLrtH5Cv0AsK5nYrvWfZHPQMDPnAv/D
         XM8g==
X-Gm-Message-State: AOJu0Yz4gDSjFtDLy63LwWnGY3nQDSc9ss7DSDZtElHYxILW9eV5c8kH
	dPU6/Ji31y3pFxOMuoYBJNWhaBE4oh+ElF3P2ULNmuSVdQFzLwO0zPPVUWzVRg==
X-Gm-Gg: ASbGncu/3ZR45/DkJIPFmnOgnGZN2cCUEEV5WejoYBFyxdbyjWKd54pq23MtkiVg1PT
	RdxPGX71UH0oVKaGvZOVMnXzyS6HjAtgylJQ0gwq2Gi1yegUTSHZrq98x5VyDRWr9WpLqA3CUrn
	dLdLPmlBf4+faa2vQvWAF8UUOXP01XuwOlDnli+XbhuEBD4GnQ58ZiuahAoQkW2Lc/ok7loUeVw
	NHGW27tGBHQrnkbq0YfZ0kfSwZOy+NKOBrvHT+HzSXPB+94OAi/zJ4R1cjz8p8AVrHwm78SZAc4
	DYw+aoE8x1MFKF6kdQ7VCS2Vb6SKYKzqs3STNCk4cAgHHWcjn5BuQISW3rtz/d7wqQ==
X-Google-Smtp-Source: AGHT+IFXPz7rmqsiP+SNHu+vhNL3+N7/3rsFkXOo82FToxA2ZrFmMRcVo+GkNk/bmMEcwpagkK7onQ==
X-Received: by 2002:a5d:6d86:0:b0:38a:8e2e:9fcc with SMTP id ffacd0b85a97d-38bf57befa9mr24717162f8f.45.1737638322334;
        Thu, 23 Jan 2025 05:18:42 -0800 (PST)
Message-ID: <f0e2a3f3-3081-414d-824c-bf940134aece@suse.com>
Date: Thu, 23 Jan 2025 14:18:41 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 02/12] x86/HVM: improve CET-IBT pruning of ENDBR
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Kevin Tian <kevin.tian@intel.com>, Jun Nakajima <jun.nakajima@intel.com>
References: <293e5aef-8843-461c-bc96-709a605b2680@suse.com>
 <537b0d9c-1936-4cf5-a012-d50b1097a22d@suse.com>
 <Z5I5D_uVxijLF6sK@macbook.local>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <Z5I5D_uVxijLF6sK@macbook.local>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 23.01.2025 13:41, Roger Pau Monné wrote:
> On Mon, Feb 26, 2024 at 05:42:20PM +0100, Jan Beulich wrote:
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -161,10 +161,15 @@ static int __init cf_check hvm_enable(vo
>>      else if ( cpu_has_svm )
>>          fns = start_svm();
>>  
>> +    if ( fns )
>> +        hvm_funcs = *fns;
>> +
>> +    prune_vmx();
>> +    prune_svm();
> 
> Isn't it actually the opposite of pruning.  What the helpers do is
> fill all the pointers in the structure.

With the goal of their ENDBR to then be pruned. I agree though that the
functions don't do any pruning themselves. Yet
{svm,vmx}_prepare_for_cet_ibt_pruning() is a little awkward for my taste
(although it would properly document the purpose). Plus ...

>  I would rather name them {vmx,svm}_fill_hvm_funcs() or similar.

... while I can use those names (perhaps without the "hvm" infix), the
present names have the advantage that any other pruning that we may
find desirable could also be put there. Hence also why the cpu_has_*
checks live there.

>  And possibly pull the
> cpu_has_xen_ibt check outside the functions:
> 
> if ( cpu_has_xen_ibt )
> {
>     /*
>      * Now that svm_function_table was copied, populate all function pointers
>      * which may have been left at NULL, for __initdata_cf_clobber to have as
>      * much of an effect as possible.
>      */
>     vmx_fill_hvm_funcs();
>     svm_fill_hvm_funcs();
> }

Which would leave the SVM function entirely empty. The intention was for
that to not be the case, and also for the comment you have added above
to also live in the per-vendor functions.

> I would be nice to avoid directly exporting more vmx and smv specific
> helpers, as if we ever want to compile out vmx or svm it would be more
> churn to deal with those.  I however cannot think of any good way to
> do this here, so it's fine to export those functions.

It could be another hook, just that the hook pointer then would point
into .init.text (i.e. become stale once we purge .init.*). We could zap
it of course after invoking it ...

Note that the vendor function invocations have meanwhile, in the course
of re-basing, gained "if ( IS_ENABLED(CONFIG_...) )", so no extra
(future) churn for the (already available) option you talk about.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 23 13:24:06 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 13:24:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876250.1286627 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taxBh-0003hh-Pv; Thu, 23 Jan 2025 13:24:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876250.1286627; Thu, 23 Jan 2025 13:24:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taxBh-0003ha-Lp; Thu, 23 Jan 2025 13:24:01 +0000
Received: by outflank-mailman (input) for mailman id 876250;
 Thu, 23 Jan 2025 13:24: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
 <SRS0=AE9i=UP=invisiblethingslab.com=marmarek@srs-se1.protection.inumbo.net>)
 id 1taxBh-0003hU-28
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 13:24:01 +0000
Received: from fout-a3-smtp.messagingengine.com
 (fout-a3-smtp.messagingengine.com [103.168.172.146])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4ca45d23-d98d-11ef-99a4-01e77a169b0f;
 Thu, 23 Jan 2025 14:23:58 +0100 (CET)
Received: from phl-compute-04.internal (phl-compute-04.phl.internal
 [10.202.2.44])
 by mailfout.phl.internal (Postfix) with ESMTP id 9826F1380193;
 Thu, 23 Jan 2025 08:23:56 -0500 (EST)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-04.internal (MEProxy); Thu, 23 Jan 2025 08:23:56 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 23 Jan 2025 08:23:54 -0500 (EST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 4ca45d23-d98d-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm2; t=1737638636;
	 x=1737725036; bh=DgjgGv7jyTeHmwDzOc84QYkjkbvkYFUocoQoxVjSo6o=; b=
	K5QdPxKv7Endgvv6UxUni76NhpABqGfSRQff+EKuePeySA10KdeVNUYQFF+TCPbX
	72YjVr7wStFXW2iW5ozxZu347QaLzjE9BU6IBc5oyC1Yc76rXqJ082NrE8lGlC6J
	cYceEprbsPzLwHbHSK93nx8/0B9Xub6yeqw3Xjz1QO31gKVFg/8EgpMxEC/cfdFD
	PAVFdBXKoNLdfsmRDQUCfQ4Xl4xE4zbDbJyVZfvkvBRO/+wyjRh5dvA7YNIOhPAN
	JeYpWsQvPyKFtAtPfPlzE6DqB2iJa3Wug9d3And+AzINoiP/8f3mpmUtvFMIP8RB
	/MbIc9aTp2ATYtWyAh1Eog==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:subject:subject:to
	:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=
	1737638636; x=1737725036; bh=DgjgGv7jyTeHmwDzOc84QYkjkbvkYFUocoQ
	oxVjSo6o=; b=QuaTGKnP2JW0es9xmMC9VM4KWYHWqR9mGoR359jxVL59Z3t7LgC
	ukMUTfMVlnnJUQ62PfPGQhWBGCQ6RUgp0KKeF5ut0Fsz44TnX86dagnTdFv9LoNu
	NhVlv+zBI0LWLScSdDUKzojk0ZyepIcRIPDRrpu150V0VrcFysxS1Td7clBvot+n
	AFmqJ7Tsv6gonMbZpeVUw2Usy4gG/igLpV0ZOzZ9G+ATM567hqnrmP2jbenl5mSZ
	Qi/M5E+5KG9JD6SrWtsHbsrldsUIE0eNGg6RnnzXEz9cCy4/Ym6kTcNt7S1k5yz4
	tB8Zdn+B1JBsCULsRfGy2B+m5t803aW3SAg==
X-ME-Sender: <xms:60KSZ_odNENTJMa_u51_H2fzaQSp3brNAZ5SPh5SwEUSpTTt6WUGHA>
    <xme:60KSZ5p7jSbtOrWWuJsTmtBh5jxuwJCiklzu6_70ro4K0qW5ANwGkSZlTXBNh3ktF
    3PiYTOO9onE9g>
X-ME-Received: <xmr:60KSZ8NUovzoGXqFeP8cQ8DV39BXs07etsKqMFt-ZwifvA8iZnukvUgkd2grwzy-Mt_3a7tEu_HxCVCQLkv7rycfpoG31pCf4g>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrudejgedgudejkecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp
    uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg
    hnthhsucdlqddutddtmdenucfjughrpeffhffvvefukfhfgggtuggjsehgtderredttdej
    necuhfhrohhmpeforghrvghkucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoe
    hmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucgg
    tffrrghtthgvrhhnpefgudelteefvefhfeehieetleeihfejhfeludevteetkeevtedtvd
    egueetfeejudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhr
    ohhmpehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpd
    hnsggprhgtphhtthhopedutddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepjhgs
    vghulhhitghhsehsuhhsvgdrtghomhdprhgtphhtthhopeigvghnqdguvghvvghlsehlih
    hsthhsrdigvghnphhrohhjvggtthdrohhrghdprhgtphhtthhopegrnhgurhgvfidrtgho
    ohhpvghrfeestghithhrihigrdgtohhmpdhrtghpthhtohepjhhulhhivghnseigvghnrd
    horhhgpdhrtghpthhtohepshhsthgrsggvlhhlihhniheskhgvrhhnvghlrdhorhhgpdhr
    tghpthhtoheprhhoghgvrhdrphgruhestghithhrihigrdgtohhmpdhrtghpthhtoheplh
    hukhgrshiisehhrgifrhihlhhkohdrphhlpdhrtghpthhtohepughpshhmihhthhesrghp
    vghrthhushhsohhluhhtihhonhhsrdgtohhmpdhrtghpthhtohepmhgrthgvuhhsiidrmh
    hofihkrgesihhnthgvlhdrtghomh
X-ME-Proxy: <xmx:7EKSZy617Ot1YxrZLeoAyiKeQHuCD7URHwHXJOckmZBEl9wr5Ze0oQ>
    <xmx:7EKSZ-48PEV4ns1pYZ-SD4t_C9R0UQKRHSr6mZ5WP5FMNin1_cRFmg>
    <xmx:7EKSZ6hhsqnnMjD2FHxqFiligYjNfnJFStWuHx62S_K_gQ-KGKEAhQ>
    <xmx:7EKSZw4WLq6zv-ACYrz-G4bei9kXG8PbR3ospW1vQmvfpXHu08MfxA>
    <xmx:7EKSZ7zmA3nV6bE1uzwH-mVUn3ZEYgy3_vP2zKfwm7H-cQO0UZzqcKQ4>
Feedback-ID: i1568416f:Fastmail
Date: Thu, 23 Jan 2025 14:23:52 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>,
	Lukasz Hawrylko <lukasz@hawrylko.pl>,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Mateusz =?utf-8?B?TcOzd2th?= <mateusz.mowka@intel.com>,
	Teddy Astie <teddy.astie@vates.tech>
Subject: Re: [XEN RFC PATCH v5 0/5] IOMMU subsystem redesign and PV-IOMMU
 interface
Message-ID: <Z5JC6ELVTWtvbqPU@mail-itl>
References: <cover.1737470269.git.teddy.astie@vates.tech>
 <Z5I59HC77QxpPtJG@mail-itl>
 <8e19c066-2d76-4f4d-9ccc-ed57e02143ab@suse.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="HzESkeORsoA+bDtT"
Content-Disposition: inline
In-Reply-To: <8e19c066-2d76-4f4d-9ccc-ed57e02143ab@suse.com>


--HzESkeORsoA+bDtT
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Thu, 23 Jan 2025 14:23:52 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>,
	Lukasz Hawrylko <lukasz@hawrylko.pl>,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Mateusz =?utf-8?B?TcOzd2th?= <mateusz.mowka@intel.com>,
	Teddy Astie <teddy.astie@vates.tech>
Subject: Re: [XEN RFC PATCH v5 0/5] IOMMU subsystem redesign and PV-IOMMU
 interface

On Thu, Jan 23, 2025 at 01:48:29PM +0100, Jan Beulich wrote:
> On 23.01.2025 13:45, Marek Marczykowski-G=C3=B3recki wrote:
> > BTW Linux says it detected "Xen version 4.19." - shouldn't it report
> > 4.20 already at this point in release cycle?
>=20
> Not only at this point, but throughout the release cycle. Yet I fear I
> haven't seen such, so I wouldn't be able to look into it.

Ah, my bad, it seems Teddy's branch is based on 4.19, not staging.

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

--HzESkeORsoA+bDtT
Content-Type: application/pgp-signature; name="signature.asc"

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmeSQugACgkQ24/THMrX
1yzMcgf+JHwlpghc/p0Ho9n3bWbYggDhPxoy0nDmFRPAFayT5S1xU4v1wo30cBgi
rNKLOlT43yb1xTukdAZnBqvFu4rXDG3kw4au4D3kXGXYtJrr2cBmRRTi/S+cc39Q
SDM3+QssS/dqu1+0N4olIf9E8Ig1YJmiTfZ4unoKLeLf9Ve6aMIUSjO76BVHGoL8
EtIxCLCnhPEuUy4AacYxmtKaw+XnqOcvQ5JFZutp0zyZR/vmsfrLe44eHPDCgihn
SjUBJIfuHyxTu2wYs9asFXYYEAAmlxKjgJqmsdVc6RiHI4FLwgCjVXlE4qiM3d8E
Znbh77PDx4bJSEqjbHbQe/5EXQe0bw==
=2TQ+
-----END PGP SIGNATURE-----

--HzESkeORsoA+bDtT--


From xen-devel-bounces@lists.xenproject.org Thu Jan 23 13:58:39 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 13:58:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876261.1286637 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taxj7-0008Bv-99; Thu, 23 Jan 2025 13:58:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876261.1286637; Thu, 23 Jan 2025 13:58:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taxj7-0008Bo-6Y; Thu, 23 Jan 2025 13:58:33 +0000
Received: by outflank-mailman (input) for mailman id 876261;
 Thu, 23 Jan 2025 13:58:32 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=AE9i=UP=invisiblethingslab.com=marmarek@srs-se1.protection.inumbo.net>)
 id 1taxj5-0008Bi-Qi
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 13:58:31 +0000
Received: from fhigh-a6-smtp.messagingengine.com
 (fhigh-a6-smtp.messagingengine.com [103.168.172.157])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1f3e3082-d992-11ef-99a4-01e77a169b0f;
 Thu, 23 Jan 2025 14:58:29 +0100 (CET)
Received: from phl-compute-11.internal (phl-compute-11.phl.internal
 [10.202.2.51])
 by mailfhigh.phl.internal (Postfix) with ESMTP id ED8961140086;
 Thu, 23 Jan 2025 08:58:27 -0500 (EST)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-11.internal (MEProxy); Thu, 23 Jan 2025 08:58:27 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 23 Jan 2025 08:58:25 -0500 (EST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1f3e3082-d992-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm2; t=1737640707;
	 x=1737727107; bh=YNgtDN8MyYrnS0ZAXV//Lsh9jHzupvOzKZGjbiEleBU=; b=
	T/t1zQyZccRUNHXJnOa7D9aKvisiWF/NirT/F4M1mfRjJRmsj0sS3VU05Hw9QFMN
	znnaoQreoB5H1JYxKUVpSQsooFHBlTV5cCFV9sGTLFtCMUka8fiGNGM1214xVomV
	COgO403NpAwyh2rMd12xZg7vN9czKTFhK/hN/GWehEXRRHhiriUxuPb0RnK4DZl7
	DOpib/gU0E1xs6Gc1gaWXYsNY/3cHjLKZwVbOvxgBm/O2/xba4XPq0PogIMN45tu
	6NlKuNqURzGerxN8yEykA0yBcYcWDnsFL73vxDVuPkXaE9ZjVkeUrK+YVF4Cy15J
	+P7XLUIkuydRe64eFLRH3w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:subject:subject:to
	:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=
	1737640707; x=1737727107; bh=YNgtDN8MyYrnS0ZAXV//Lsh9jHzupvOzKZG
	jbiEleBU=; b=d+m58byQe4dTIPQhd65N1GZElII5lgFW9SycyderwUs3purGdQO
	L/t0iwyfyEG2li1QVi2N6gVHQTJwQtymnS1w1ZyXDWOHrSId/HylrQ4koh5xvcBN
	Tw02JMElUjp4ST8bH+sU09B6u4UKCHEXRTM1fe0IWVcCOY9l5r+M1dLN/EUiyCh3
	pRG5V/KadO7ncle6ka0UvkIa4Asd17tK61sOkW9kuWK/srlug29JzftlyA6iEaNV
	v2MWADO/c8G9JknIdLZ3Nds2McdEryF9XAMTDB6AS2rs4D8dsqY4X3ZXzm730oBl
	qJ/MVC/4ZMf5pZEKrJkJxz13u6Tl3bgG0Mg==
X-ME-Sender: <xms:A0uSZ-kKP9xjkDnfEO77mkVJuQz6OZZRfSLJxwbLRkO6rWf3e3QO4A>
    <xme:A0uSZ10XZ88kAbPQLwT74IW99q776qzdA0RXIzvUczXnT9XY7E-REsZhFGEaCAPGB
    FpERzAzeq-Lcw>
X-ME-Received: <xmr:A0uSZ8rY_hTn6TjUnwEv7QrJYVYuhsHm73s6wATf8HwZG5mIinnbQoAQhUNc6ajNlatdZEP6gLnHJSD9iRdYTWZb2MSwIQaizw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrudejgedgudekgecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp
    uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg
    hnthhsucdlqddutddtmdenucfjughrpeffhffvvefukfhfgggtuggjsehgtderredttdej
    necuhfhrohhmpeforghrvghkucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoe
    hmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucgg
    tffrrghtthgvrhhnpeevueejteegleelteduueevhfetgfffjeevtddvgfeiveehteehle
    egueelvdejveenucffohhmrghinhepghhithhlrggsrdgtohhmnecuvehluhhsthgvrhfu
    ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehinhhvih
    hsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohepuddtpdhmohgu
    vgepshhmthhpohhuthdprhgtphhtthhopehtvgguugihrdgrshhtihgvsehvrghtvghsrd
    htvggthhdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhj
    vggtthdrohhrghdprhgtphhtthhopegrnhgurhgvfidrtghoohhpvghrfeestghithhrih
    igrdgtohhmpdhrtghpthhtohepjhgsvghulhhitghhsehsuhhsvgdrtghomhdprhgtphht
    thhopehjuhhlihgvnhesgigvnhdrohhrghdprhgtphhtthhopehsshhtrggsvghllhhinh
    hisehkvghrnhgvlhdrohhrghdprhgtphhtthhopehrohhgvghrrdhprghusegtihhtrhhi
    gidrtghomhdprhgtphhtthhopehluhhkrghsiieshhgrfihrhihlkhhordhplhdprhgtph
    htthhopeguphhsmhhithhhsegrphgvrhhtuhhsshholhhuthhiohhnshdrtghomh
X-ME-Proxy: <xmx:A0uSZyk2YzID61H9CVcihBzIxEtYKcI8KqdOqJk1IdEGxcX60ImCRw>
    <xmx:A0uSZ82p9k56l4nichfAm1jeqTH5dcoe6ENbmUB67bhSKC3rPl5RLw>
    <xmx:A0uSZ5sWdwsFOT12akfe4ZFQeSPA-y0dIkp5iBk3MYDmwCeJd3dF2g>
    <xmx:A0uSZ4VzhZM-sm5ls4n_9TrRRfUWq8DaI6qQsyLWW7loJOeCt3-HgA>
    <xmx:A0uSZ1tJP1tsDUp3StNq9lcMNq_qA9XEfiXm1dWKW7LgAJojXD2y6qwh>
Feedback-ID: i1568416f:Fastmail
Date: Thu, 23 Jan 2025 14:58:23 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Teddy Astie <teddy.astie@vates.tech>
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>,
	Lukasz Hawrylko <lukasz@hawrylko.pl>,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Mateusz =?utf-8?B?TcOzd2th?= <mateusz.mowka@intel.com>
Subject: Re: [XEN RFC PATCH v5 0/5] IOMMU subsystem redesign and PV-IOMMU
 interface
Message-ID: <Z5JK_xHjIqvk25VE@mail-itl>
References: <cover.1737470269.git.teddy.astie@vates.tech>
 <Z5I59HC77QxpPtJG@mail-itl>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="rwOvWbJJcpXuwh6q"
Content-Disposition: inline
In-Reply-To: <Z5I59HC77QxpPtJG@mail-itl>


--rwOvWbJJcpXuwh6q
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Thu, 23 Jan 2025 14:58:23 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Teddy Astie <teddy.astie@vates.tech>
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>,
	Lukasz Hawrylko <lukasz@hawrylko.pl>,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Mateusz =?utf-8?B?TcOzd2th?= <mateusz.mowka@intel.com>
Subject: Re: [XEN RFC PATCH v5 0/5] IOMMU subsystem redesign and PV-IOMMU
 interface

On Thu, Jan 23, 2025 at 01:45:40PM +0100, Marek Marczykowski-G=C3=B3recki w=
rote:
> On Tue, Jan 21, 2025 at 04:13:20PM +0000, Teddy Astie wrote:
> > This work has been presented at Xen Summit 2024 during the
> >   IOMMU paravirtualization and Xen IOMMU subsystem rework
> > design session.
> >=20
> > Operating systems may want to have access to a IOMMU in order to do DMA
> > protection or implement certain features (e.g VFIO on Linux).
> >=20
> > VFIO support is mandatory for framework such as SPDK, which can be usef=
ul to
> > implement an alternative storage backend for virtual machines [1].
> >=20
> > In this patch series, we introduce in Xen the ability to manage several
> > contexts per domain and provide a new hypercall interface to allow gues=
ts
> > to manage IOMMU contexts.
> >=20
> > The VT-d driver is updated to support these new features.
> >=20
> > [1] Using SPDK with the Xen hypervisor - FOSDEM 2023
> > ---
> > Cc: Marek Marczykowski-G=C3=B3recki <marmarek@invisiblethingslab.com>
> >=20
> > PCI Passthrough now work on my side, but things are still feels quite b=
rittle.
> >=20
> > Changed in v2 :
> > * fixed Xen crash when dumping IOMMU contexts (using X debug key)
> > with DomUs without IOMMU
> > * s/dettach/detach/
> > * removed some unused includes
> > * fix dangling devices in contexts with detach
> >=20
> > Changed in v3 :
> > * lock entirely map/unmap in hypercall
> > * prevent IOMMU operations on dying contexts (fix race condition)
> > * iommu_check_context+iommu_get_context -> iommu_get_context and check =
for NULL
> >=20
> > Changed in v4 :
> > * Part of initialization logic is moved to domain or toolstack (IOMMU_i=
nit)
> >   + domain/toolstack now decides on "context count" and "pagetable pool=
 size"
> >   + for now, all domains are able to initialize PV-IOMMU
> > * introduce "dom0-iommu=3Dno-dma" to make default context block all DMA
> >   (disables HAP and sync-pt), enforcing usage of PV-IOMMU for DMA
> >   Can be used to expose properly "Pre-boot DMA protection"
> > * redesigned locking logic for contexts
> >   + contexts are accessed using iommu_get_context and released with iom=
mu_put_context
> >=20
> > Changed in v5 :
> > * various PCI Passthrough related fixes
> >   + rewrote parts of PCI Passthrough logic
> >   + various other related bug fixes
> > * simplified VT-d DID (for hardware) management by only having one map =
instead of two
> >   (pseudo_domid map was previously used for old quarantine code then re=
cycled for PV-IOMMU
> >    in addition to another map also tracing Domain<->VT-d DID, now there=
 is only one
> >    map tracking both making things simpler)
> > * reworked parts of Xen quarantine logic (needed for PCI Passthrough)
> > * added cf_check annotations
> > * some changes to PV-IOMMU headers (Alejandro)
> >=20
> > TODO:
> > * add stub implementations for bissecting needs and non-ported IOMMU im=
plementations
> > * fix some issues with no-dma+PV and grants
> > * complete "no-dma" mode (expose to toolstack, add documentation, ...)
> > * properly define nested mode and PASID support
> >=20
> > * make new quarantine code more unity region aware (isolate devices with
> >   different reserved regions regions using separate 'contexts')
> > * find a way to make PV-IOMMU work in DomUs (they don't see machine bdf)
> > * there are corner cases with PV-IOMMU and to-domain Xen PCI Passthrough
> >   (e.g pci-assignable-remove will reassign to context 0, while the driv=
er
> >    expects the device to to be in context X)
>=20
> Thanks for the updated patches. I have run them through gitlab-ci, and
> here are some observations:
> - I needed to disable CONFIG_AMD_IOMMU (it fails to build, as expected at=
 this point)
> - I needed to disable pvshim (it fails to build)
> - fails to build with clang: https://gitlab.com/xen-project/people/marmar=
ek/xen/-/jobs/8931373789/viewer#L3525
> - gcc-ibt build fails: https://gitlab.com/xen-project/people/marmarek/xen=
/-/jobs/8931373785#L1314
> - fails to build for ARM (both 32 and 64) and PPC64
> - QEMU smoke test panic with PV dom0, looks like it runs on AMD, so it
>   may be related to the disabled CONFIG_AMD_IOMMU, but I wouldn't expect
>   it to panic on _PV_ dom0 boot...
> - PVH dom0 fails to boot (on real hw) with a lot of VT-d faults: https://=
gitlab.com/xen-project/people/marmarek/xen/-/jobs/8931373875
> - PCI passthrough (with PV dom0) results in a lot of VT-d faults: https:/=
/gitlab.com/xen-project/people/marmarek/xen/-/jobs/8931373881
>=20
> Note this uses only this series, but plain Linux (appears to be 6.1.19).
> IIUC if one doesn't try to configure PV-IOMMU specifically (non-default
> contexts) it should still work.
>=20
> BTW Linux says it detected "Xen version 4.19." - shouldn't it report
> 4.20 already at this point in release cycle?
>=20
> All results:
> https://gitlab.com/xen-project/people/marmarek/xen/-/pipelines/1637849303

FWIW the test run rebased on staging looks similar:
https://gitlab.com/xen-project/people/marmarek/xen/-/pipelines/1638019332

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

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

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmeSSv8ACgkQ24/THMrX
1yxJLwf8Dk+VwjjB9TlbQysRYZLQGSCvu+D2io17gZlwLZf2sFTfU0eQw93aWdo2
+qoglODNxc2Z3mW0LwbFAo2rkP01LOt9+TumPMeQ5bl7HboqGW5Q5QpNAtOO5h+O
QZqZcNEjNWX1enG8yyFcEuoDHt9Br9JBOZsijfMUtyxYqQC9baElo71J4PBvdzWc
g3HeEhcvbsjIqHCPjRUV30+AbPl8MtZUer4/Tc0+yjJl9fJDMsCjW2FBGSMjcKD8
ZRCPLaVn8W6Oqj6nZx/9T4uhslcWGmYbu+79jCDVnYsG0VxyVwyS3ooIcsIa1wfs
CNaGQBwi6u88PPBEpGiKD1vkeSnWFw==
=vzyZ
-----END PGP SIGNATURE-----

--rwOvWbJJcpXuwh6q--


From xen-devel-bounces@lists.xenproject.org Thu Jan 23 14:02:43 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 14:02:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876271.1286647 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taxn7-0001Sr-O7; Thu, 23 Jan 2025 14:02:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876271.1286647; Thu, 23 Jan 2025 14:02:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1taxn7-0001Sk-LY; Thu, 23 Jan 2025 14:02:41 +0000
Received: by outflank-mailman (input) for mailman id 876271;
 Thu, 23 Jan 2025 14:02:40 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Lw3w=UP=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1taxn6-0001SS-FU
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 14:02:40 +0000
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com
 [2a00:1450:4864:20::52d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b4610c39-d992-11ef-99a4-01e77a169b0f;
 Thu, 23 Jan 2025 15:02:38 +0100 (CET)
Received: by mail-ed1-x52d.google.com with SMTP id
 4fb4d7f45d1cf-5d9b6b034easo1981259a12.3
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 06:02:38 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5dc0e9f5a75sm859627a12.40.2025.01.23.06.02.37
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 23 Jan 2025 06:02:37 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b4610c39-d992-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737640958; x=1738245758; 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=/y5Gr8QBrV9P5vy6alHK/Y3zsWpx60h7+msUsErPQDQ=;
        b=Nn67jt20MPO0TME9rkGoOzV89PbnPWfHsD1cQVLyUAE+Wa9DbeaNT9nUryDkPlGgNj
         qPTgOPFwt37oZ04gNhLB/rskA5HWowIct8E6g8VYZ2FcDjZP+e+bccPD+d+mbidOe5Y+
         cGlxI5T1psH7E4vg3LT136EFDv7bT3j6Heh04=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737640958; x=1738245758;
        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=/y5Gr8QBrV9P5vy6alHK/Y3zsWpx60h7+msUsErPQDQ=;
        b=ijMjHAvSsv+GDhqkTaZqEtrPyhqaZlj0SwCsI3kFREWFtQKq41UcRtzGkuIOtw7B2E
         AFY6u0W7vWJwX1RjwIEspY4W8Zc5B0a/fuGYdW9njwBsrpJsFw0UIcTmQzSUSoz/GyAj
         jcinp/7b/U6nzz9pkxD7oSUWyqoVdJXgX51cIvgFUcmL1SArXIvsYvzHJ+orMR/y+j7k
         N3zE0I6oA6uPRqay6yCDpP9AebNz6EI046g+Lv5VFlf0uASL/RYyztgph5V6QWioR+Xu
         bgQslptl48PDOAz5n/BZtibLmDrGhOv6OyHJdBzVqSUszgCoedLGpX9EYWIV1EOTMx4p
         D2vQ==
X-Gm-Message-State: AOJu0YxafgoIZzJsPYyctWPVg8xeaOdoOvjWPT/kCPw/Sfq/R7v0nGQq
	NPv0S6B7prebo+Rso4BNaaT728VRBRF74LWUNzNnoroV2JtMqnmTp7anckWptNI=
X-Gm-Gg: ASbGnctmfCxUTXn/a4vOFdTDLi8L7U7sCSQAHiqL42KhBzAqOGVO7+q7xtvWO+Y1cVJ
	W0uxF88piGuUDZID1FOvdak7zTOPGFHDkU8c1qtHUZVJFbnYyy32kL9905Rh8ZBhTiZU0i5SZxe
	y2PzRwZRUhvWCQbR/n3JRl1DiFVAwhWNZ5k8nT9pf8GkFTe8lhqA4jAn+jyfyGjdmlqfY6RYPdT
	nTVGVlR0Hz6IbHlaViLYoVUu+qxymZfwiiqF+8yIHZC1vGQJs/DS6Xfowqz8l6JWxfsJI0IgZfU
	Jpt7pKj5UA==
X-Google-Smtp-Source: AGHT+IGrsTrKj0Bx/slw8fyvnmOSjhQPheiyoBi/n/hH+4wjHznHoLu07nwiczXUoPMQieYHX5J1tw==
X-Received: by 2002:a05:6402:348c:b0:5dc:1239:1e5b with SMTP id 4fb4d7f45d1cf-5dc123920a9mr1232823a12.23.1737640957782;
        Thu, 23 Jan 2025 06:02:37 -0800 (PST)
Date: Thu, 23 Jan 2025 15:02:36 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH] x86/PV: further harden guest memory accesses against
 speculative abuse
Message-ID: <Z5JL_HXbtsx5g02y@macbook.local>
References: <a537dd1e-bbd3-4ef8-8014-6bb432484c57@suse.com>
 <Z5IuEq9Lauhn8glx@macbook.local>
 <10a655b0-1cdc-4e14-8fcf-221336ccc0ac@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <10a655b0-1cdc-4e14-8fcf-221336ccc0ac@suse.com>

On Thu, Jan 23, 2025 at 01:44:34PM +0100, Jan Beulich wrote:
> On 23.01.2025 12:54, Roger Pau Monné wrote:
> > On Tue, Nov 05, 2024 at 02:56:42PM +0100, Jan Beulich wrote:
> >> The original implementation has two issues: For one it doesn't preserve
> >> non-canonical-ness of inputs in the range 0x8000000000000000 through
> >> 0x80007fffffffffff. Bogus guest pointers in that range would not cause a
> >> (#GP) fault upon access, when they should.
> >>
> >> And then there is an AMD-specific aspect, where only the low 48 bits of
> >> an address are used for speculative execution; the architecturally
> >> mandated #GP for non-canonical addresses would be raised at a later
> >> execution stage. Therefore to prevent Xen controlled data to make it
> >> into any of the caches in a guest controllable manner, we need to
> >> additionally ensure that for non-canonical inputs bit 47 would be clear.
> >>
> >> See the code comment for how addressing both is being achieved.
> >>
> >> Fixes: 4dc181599142 ("x86/PV: harden guest memory accesses against speculative abuse")
> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >> ---
> >> RFC: Two variants of part of the logic are being presented, both with
> >>      certain undesirable aspects: The first form is pretty large and
> >>      ugly (some improvement may be possible by introducing further
> >>      helper macros). The alternative form continues to use RCR, which
> >>      generally would be nice to do away with. Then again that's also
> >>      slightly smaller generated code.
> > 
> > Oh, I assume that's why there's a hardcoded .if 1, I was wondering
> > about that.  What's the specific issue with using rcr?
> 
> It's slower than SHL. Albeit - checking a few places - not as much as I
> thought I remembered it would be.
> 
> >  And why is the
> > more complex set of macros that use setc plus a shl better?
> 
> They're slightly longer (beyond the source complexity), but (presumably)
> a little faster.
> 
> > Why not use cmovc:
> > 
> > mov $(1 << 63), \scratch1
> > cmovc \scratch1, \scratch2
> > 
> > AFAICT \scratch1 is not used past the btr instruction, and hence can
> > be used for the cmovc?
> 
> Such an alternative was already considered back at the time:
> https://lists.xen.org/archives/html/xen-devel/2021-02/msg01067.html.
> Granted I was wrong there about needing a 3rd scratch register, but
> the code size consideration remains - we have dozens of instances of
> this macro in the resulting binary, after all. Yet ftaod, this isn't
> to mean we can't re-consider. Given the above I'm inclined though to
> go the RCR route.

RCR or CMOVC would either be fine by me.  The SETC is IMO too complex,
and using it would need a clear performance justification compared to
RCR or CMOVC.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jan 23 14:24:49 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 14:24:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876281.1286657 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tay8J-0004XQ-Df; Thu, 23 Jan 2025 14:24:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876281.1286657; Thu, 23 Jan 2025 14:24:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tay8J-0004XJ-BB; Thu, 23 Jan 2025 14:24:35 +0000
Received: by outflank-mailman (input) for mailman id 876281;
 Thu, 23 Jan 2025 14:24:34 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Lw3w=UP=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tay8I-0004XC-06
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 14:24:34 +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 c195849e-d995-11ef-99a4-01e77a169b0f;
 Thu, 23 Jan 2025 15:24:29 +0100 (CET)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-aa67ac42819so165377366b.0
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 06:24:29 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5db73ef6c37sm10287257a12.81.2025.01.23.06.24.28
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 23 Jan 2025 06:24:28 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c195849e-d995-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737642269; x=1738247069; 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=TtV2w0OkMULVw/3Ztxc5AaC/n0VuTCkq4bSs96ssGoY=;
        b=vBWBlSJLuMKPfabLNUKXnf28jVqrPloJbdEOdiwo8CuzfRwc28Jcv7WQ1vb2frDyj7
         GzOgjeL8EeA0BLB+Z8NIwhmtuVa1PnVlFlfT7Zk06Xb+2TZKnc95fIQXpflDuBL7STQL
         +3tAyBn7AbKrTNC9QWzg1hmHZQ/O4RW4Bu/5Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737642269; x=1738247069;
        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=TtV2w0OkMULVw/3Ztxc5AaC/n0VuTCkq4bSs96ssGoY=;
        b=QdeXgXNYA7OkOTMa5XAjUqc8YrBIEY0mJF7RqMUVXf044uJ4MH3mGQlBCR1o6tu6sh
         ZWgq6RV5/Sf7Go6LT7QA/BOopwSjtvtTrzFv91AX+DH1GPOWHn3cAdr3qmynlOnfX0+B
         DcNCeLDEZStqqwYIgu6dLOqQNCwyWvIv3Bm9RYntIhMR+OSBKlMrc8ya5k6GECkYIJy9
         fvouAqukbd9jaWpFYzbqGkEvxrV4Sf8ZRl2h3hoHWBtImBn9okJhxtJrcy+TIVjlnLKF
         VU3MI8dQm2qW4DRBKkQI3zpFF0XwIpB7VPjItD2B2PZOKf1FsFdXI7kGBkhesQL7trpO
         C/HA==
X-Gm-Message-State: AOJu0YxbRfnrYIk3yaJQTTZr56A6dxkNkoNvK8B/Bg4gs++iBlDJ5K0g
	IAvATMwQqDxmyI4w8AQ5CIKpP29LF2tvRdCYsdLWyQHQ80fTYzrJkcaUKx7n8eE=
X-Gm-Gg: ASbGnctKeGzE6aTGOB/sRHBw7S9avWoiM+vriUIoDHg47kMXT27g/Dd/G2sr5k6PCjH
	Jt2FxDzveQiGqBDnkPG93DEqsIGPp50CakSbT9N2vXWMGZRRhFYzBal6k5Za9uAWrWgL+Cz4vOL
	Qu9G2H0bjFGCxz+ysZ3UBIwM9PZCcwMRwrRti+lVqYvN3exHjG85sQ6D0lhPfQSMLASyVVJNIXV
	ZwWcz3yHUvjvioe4hLp6jW8TkUZfZ4useC4Lvo2giDr/ZxgfyNHUI9oBqHp9KK0lBTG05bj9OUx
	lBa7TnnvpQ==
X-Google-Smtp-Source: AGHT+IHV2gMEoUueAD6cnOH1KMgkg7v+oXBWRu1U+psNzHq4ec37QY4gbF0Bt/rxi8Qw7dJ3ie/gcw==
X-Received: by 2002:a17:906:6a20:b0:aac:23f4:f971 with SMTP id a640c23a62f3a-ab38b1b45e1mr2276902866b.33.1737642268750;
        Thu, 23 Jan 2025 06:24:28 -0800 (PST)
Date: Thu, 23 Jan 2025 15:24:27 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
	Kevin Tian <kevin.tian@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>
Subject: Re: [PATCH v3 02/12] x86/HVM: improve CET-IBT pruning of ENDBR
Message-ID: <Z5JRGwA51lOs65t5@macbook.local>
References: <293e5aef-8843-461c-bc96-709a605b2680@suse.com>
 <537b0d9c-1936-4cf5-a012-d50b1097a22d@suse.com>
 <Z5I5D_uVxijLF6sK@macbook.local>
 <f0e2a3f3-3081-414d-824c-bf940134aece@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <f0e2a3f3-3081-414d-824c-bf940134aece@suse.com>

On Thu, Jan 23, 2025 at 02:18:41PM +0100, Jan Beulich wrote:
> On 23.01.2025 13:41, Roger Pau Monné wrote:
> > On Mon, Feb 26, 2024 at 05:42:20PM +0100, Jan Beulich wrote:
> >> --- a/xen/arch/x86/hvm/hvm.c
> >> +++ b/xen/arch/x86/hvm/hvm.c
> >> @@ -161,10 +161,15 @@ static int __init cf_check hvm_enable(vo
> >>      else if ( cpu_has_svm )
> >>          fns = start_svm();
> >>  
> >> +    if ( fns )
> >> +        hvm_funcs = *fns;
> >> +
> >> +    prune_vmx();
> >> +    prune_svm();
> > 
> > Isn't it actually the opposite of pruning.  What the helpers do is
> > fill all the pointers in the structure.
> 
> With the goal of their ENDBR to then be pruned. I agree though that the
> functions don't do any pruning themselves. Yet
> {svm,vmx}_prepare_for_cet_ibt_pruning() is a little awkward for my taste
> (although it would properly document the purpose). Plus ...
> 
> >  I would rather name them {vmx,svm}_fill_hvm_funcs() or similar.
> 
> ... while I can use those names (perhaps without the "hvm" infix), the
> present names have the advantage that any other pruning that we may
> find desirable could also be put there. Hence also why the cpu_has_*
> checks live there.

Hm, I'm unsure.  What else do you see becoming part of those
functions?  It's hard for me to suggest a name when it's unclear what
future logic do you think they could contain.

Given the current code I still think something that contains 'fill' or
similar is way more appropriate, the more if the IBT check is pulled
out into the caller.

> >  And possibly pull the
> > cpu_has_xen_ibt check outside the functions:
> > 
> > if ( cpu_has_xen_ibt )
> > {
> >     /*
> >      * Now that svm_function_table was copied, populate all function pointers
> >      * which may have been left at NULL, for __initdata_cf_clobber to have as
> >      * much of an effect as possible.
> >      */
> >     vmx_fill_hvm_funcs();
> >     svm_fill_hvm_funcs();
> > }
> 
> Which would leave the SVM function entirely empty.

You could possible declare it as an static inline in the hvm.h header
for the time being?

> The intention was for
> that to not be the case, and also for the comment you have added above
> to also live in the per-vendor functions.

Isn't that a bit redundant?  I would prefer to not have duplicated
comments over the code, hence my suggestion to place part of the logic
in the caller.

> > I would be nice to avoid directly exporting more vmx and smv specific
> > helpers, as if we ever want to compile out vmx or svm it would be more
> > churn to deal with those.  I however cannot think of any good way to
> > do this here, so it's fine to export those functions.
> 
> It could be another hook, just that the hook pointer then would point
> into .init.text (i.e. become stale once we purge .init.*). We could zap
> it of course after invoking it ...

Yes, I also think this is not great, and prefer your current proposal.

> Note that the vendor function invocations have meanwhile, in the course
> of re-basing, gained "if ( IS_ENABLED(CONFIG_...) )", so no extra
> (future) churn for the (already available) option you talk about.

Oh, OK, that's better then.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jan 23 14:46:49 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 14:46:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876323.1286684 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tayTk-0000H0-GE; Thu, 23 Jan 2025 14:46:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876323.1286684; Thu, 23 Jan 2025 14:46:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tayTk-0000Gt-D5; Thu, 23 Jan 2025 14:46:44 +0000
Received: by outflank-mailman (input) for mailman id 876323;
 Thu, 23 Jan 2025 14:46: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
 <SRS0=GMDf=UP=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tayTi-0000Gf-U0
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 14:46:43 +0000
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com
 [2a00:1450:4864:20::52d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id daeab873-d998-11ef-99a4-01e77a169b0f;
 Thu, 23 Jan 2025 15:46:40 +0100 (CET)
Received: by mail-ed1-x52d.google.com with SMTP id
 4fb4d7f45d1cf-5d3f28881d6so1522826a12.1
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 06:46:40 -0800 (PST)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab644adb658sm406169066b.134.2025.01.23.06.46.37
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 23 Jan 2025 06:46:38 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: daeab873-d998-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1737643599; x=1738248399; 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=apFL10DQbrX/XBE9G0QNbmvukb9vXVmmJc1QbPQYSQE=;
        b=juTyLPpcNW5qFcrJ2DvB26gc9fZuFWvh9cDoqZZoGdrP9j5K7Bi0N6yeXK9fvxQHeT
         bEfg5i4SmP2ILuP67UQw4dA8kGVY3nHJgG9Nyn5Bk577HPjRcZTqd/9SF0M2Bl6psiAa
         wiX8/TgEkhqLKfuN63ndNdaAl+XnEGQa7KRy75szgz6WHszf1o81pjNSi0YzMEGVkgFI
         3IZZsVRfBCguCx5sZjHxH7EmKF8/butVMA/KprxIFIAhDLUXHVdms/DQmPu4umel2UB5
         rkT1qdJUFaaMCzy3VjM4ozMmsGXJ0vt44I+7/IcMP1Q+k+xeajdAPOdV1aa/aCOo/C8S
         NfCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737643599; x=1738248399;
        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=apFL10DQbrX/XBE9G0QNbmvukb9vXVmmJc1QbPQYSQE=;
        b=OT9YYuE6XqVjrYfeSFHAbZICNF7JLcb9rJNoUdibOg5Q+fC76iAHjWKkI1gMhDbmlF
         188PkRAaVgEq1GcKb7kOgyyV0uvwDguQdas/6WozYoajTiWSAwX3nK3YFBKlBYkFrYra
         4gTNEFfSxQXPyYM77mNLgKgwiC+29pQdFMWFfsGfToyyOQ+/TnB/QarBwBRlXAgXS5zs
         OZn+wl/or74S32rlQfUIpXs0xwY3vQmG3DuQFKzOk4vVGGZJZ8vd5+finSOGKL9EQ4dN
         DXfhSPyGWcmHForlMJBSrcywX5mid8b+SoggWrZTNp+I8gclgwn0R0El3VvJxSCwEH9d
         9phQ==
X-Gm-Message-State: AOJu0YxphXESBkrBk7wPrIrXa+vGElkGxYNLokvvbYsa/tjREP2bnUTS
	IghQ45VSqonllRFkLmIDkgaks8rkfMnliYNAscSP5LzXxCK/3tVUxzBHmw==
X-Gm-Gg: ASbGncvK0V489mc9qgv/Yr6MGI9DZmNgDz6kcIr3O+k2NCkM9Ha+x0PenjfI0aCt2vM
	ygcrRG+JktTAQRGCEVFnekb9AuFhfpFdnPW5QuwYc56TXgPBZLAsP2KYmly5JdC3hWl31J1/LTo
	58c0476dj/pisiR7/kzovpd03qpejI9A1FU+NZRwWjO0zOO3tMGgwfUchc9eQ9BtZDjcIeVh8qL
	LjBUmzEf+1OIz2e76NnqjcQq8luiYisbkaacWFtRe57B9zYa0GSUqfe1xhP92H2dp0/hey0IDqp
	bbABSQ==
X-Google-Smtp-Source: AGHT+IHCaHJz3C4KDH754WRtLVz12bQlQAQKyBJJnRgO1EvPyWOwvrk3Z1dV9imQEFocQKAejL4HQg==
X-Received: by 2002:a05:6402:34ca:b0:5d0:81f5:a398 with SMTP id 4fb4d7f45d1cf-5db7d2dc58bmr56594097a12.1.1737643599105;
        Thu, 23 Jan 2025 06:46:39 -0800 (PST)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Bob Eshleman <bobbyeshleman@gmail.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v3] xen/riscv: identify specific ISA supported by cpu
Date: Thu, 23 Jan 2025 15:46:36 +0100
Message-ID: <ddf678bb829003b2c4a0a85166a29b61e75bcea9.1737643226.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.48.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Supported ISA extensions are specified in the device tree within the CPU
node, using two properties: `riscv,isa-extensions` and `riscv,isa`.

Currently, Xen does not support the `riscv,isa-extensions` property, as
all available device tree source (DTS) files in the Linux kernel (v6.12-rc3)
and DTBs generated by QEMU use only the `riscv,isa` property.
Therefore, only `riscv,isa` parsing is implemented.

The `riscv,isa` property is parsed for each CPU, and the common extensions
are stored in the `host_riscv_isa` bitmap.
This bitmap is then used by `riscv_isa_extension_available()` to check
if a specific extension is supported.

The current implementation is based on Linux kernel v6.12-rc3
implementation with the following changes:
 - Drop unconditional setting of {RISCV_ISA_EXT_ZICSR,
   RISCV_ISA_EXT_ZIFENCEI, RISCV_ISA_EXT_ZICNTR, RISCV_ISA_EXT_ZIHPM} as they
   are now part of the riscv,isa string.
 - Remove saving of the ISA for each CPU, only the common available ISA is
   saved.
 - Remove ACPI-related code as ACPI is not supported by Xen.
 - Drop handling of elf_hwcap, since Xen does not provide hwcap to
   userspace.
 - Replace of_cpu_device_node_get() API, which is not available in Xen,
   with a combination of dt_for_each_child_node(), dt_device_type_is_equal(),
   and dt_get_cpuid_from_node() to retrieve cpuid and riscv,isa in
   riscv_fill_hwcap_from_isa_string().
 - Rename arguments of __RISCV_ISA_EXT_DATA() from _name to ext_name, and
   _id to ext_id for clarity.
 - Replace instances of __RISCV_ISA_EXT_DATA with RISCV_ISA_EXT_DATA.
 - Replace instances of __riscv_isa_extension_available with
   riscv_isa_extension_available for consistency. Also, update the type of
   `bit` argument of riscv_isa_extension_available().
 - Redefine RISCV_ISA_EXT_DATA() to work only with ext_name and ext_id,
   as other fields are not used in Xen currently.
 - Add check of first 4 letters of riscv,isa string to
   riscv_isa_parse_string() as Xen doesn't do this check before so it is
   necessary to check correctness of riscv,isa string. ( it should start with
   rv{32,64} with taking into account upper and lower case of "rv").
 - Drop an argument of riscv_fill_hwcap() and riscv_fill_hwcap_from_isa_string()
   as it isn't used, at the moment.
 - Update the comment message about QEMU workaround.
 - Apply Xen coding style.
 - s/pr_info/printk.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
Changes in V3:
- Drop description of changes in cpufeature.c and leave only in the commit
  message to not deal with possible staleness of them in the future.
- Update for dt_get_cpuid_from_node():
  - update printk() message.
  - add some explanation about if-condition on the start of the function.
  - add dt_cpuid argument for function dt_get_cpuid_from_node() to deal
    with potential truncation issue from paddr_t (dt_read_paddr() returns
    that ) to int.
- Add Zicsr to required_extensions[].
- Drop an argument check at the start of is_lowercase_extension_name()
  as function is static and callers are expected to pass a good pointer.
- Add a comment with some additional explanation about the stop condition
  of checking a case of extension name.
- Omit blanks after opening and closing parentheses in the comments.
- Add missed parentheses in match_isa_ext().
- Drop ASSERT() which checks that first two letters of `isa` string are in
  lower case as after this ASSERT() there is an if-condition which does the
  same.
- Cut part of printk_once()'s message in riscv_isa_parse_string() related
  to riscv,isa-extension as it isn't supported for now and usage of it will
  lead to panic().
- Drop function riscv_fill_hwcap_from_ext_list() at all as Xen isn't going
  to support riscv,isa-extensions for now.
- Clarify printk()'s message when riscv,isa property wasn't found in cpu node.
  Now it contains "for DT's cpu%d node", where %d is cpuid, instead of
  "for cpu%d" to not confuse cpuid number ( if it Xen's cpu id and physical
  cpu's id).
- Updates in riscv_isa_extension_available():
  - Drop local varible `bmap` and initialize `isa_bitmap` in more readable way.
  - Rename argument `bit` of riscv_isa_extension_available() to `id` for
    clearness.
- Update handling of failure of h/w capabilities parsing in riscv_fill_hwcap().
- Introduce has_isa_extensions_property() to check if "riscv,isa-extension" is
  present in any device tree cpu node.
---
Changes in V2:
- Update the list of changes in comparison with Linux on the top of
  cpufeature.c.
- Now really drop all ACPI-related stuff.
  Add #ifdef CONFIG_ACPI #error ... #endif instead.
- Make `id` ( member of riscv_isa_ext_data structure ) not const.
- s/__read_mostly/__ro_after_init for riscv_isa bitmap.
- Update the comment above riscv_isa_ext[] declaration:
  - Drop Linux details.
  - Revised the numbering of the ordering rules for RISC-V ISA extensions.
  - Add comment that extension name must be all lowercase according to
    device tree binding.
- Add __initconst for declarations of riscv_isa_ext[] and
  required_extensions[].
- Move riscv_isa_ext_count for global declaration to match_isa_ext where
  it is really used.
- Add new function is_lowercase_extension_name().
- Updates for match_isa_ext():
  - Move last argument of match_isa_ext() to new line to not violate line
    length.
  - s/int/unsigned int for cycle varible `i`.
  - s/set_bit/__set_bit as no need for atomicity at this stage of boot.
  - Add ASSERT() to be sure that extension name is in lowercase.
  - s/strncasecmp/strncasecmp as extension name must be in a lowercase.
- Updates for riscv_isa_parse_string():
  - Move last argument of riscv_isa_parse_string() to new line to not violate
    line length.
  - Update the checks at the start of the function. Now if CONFIG_RISCV_32=y
    the only rv32 is accepted, or rv64 for CONFIG_RISCV_64=y.
  - Drop ACPI-related stuff.
  - Add blank lines between non-fall-through case blocks.
  - Add blanks in `for loops` before ')'.
  - Update the comment about QEMU workaround for invalid single-letter
    's' & 'u'.
- Updates for riscv_fill_hwcap_from_ext_list():
  - Drop initilizer of cpuid inside dt_for_each_child_node() {...}.
  - Introduce res and return it instead of -EINVAL.
  - Drop `else` and change printk("riscv,isa-extensions isnt supported\n")
    to panic("riscv,isa-extensions isnt supported\n").
  - Drop ( cpuid >= NR_CPUS ) check as cpuid technically could be any
    number. Only cpuid=0 is guaranteed to be.
- Updates for riscv_fill_hwcap_from_isa_string():
  - move cpuid and isa variables to dt_for_each_child_node() {...}.
  - Drop initilizer of cpuid inside dt_for_each_child_node() {...}.
  - Drop ( cpuid >= NR_CPUS ) check as cpuid technically could be any
    number. Only cpuid=0 is guaranteed to be.
  - Add ASSERT() to be sure that `this_isa` isn't null to prevent ending up
    with extensions not supported by one of the CPUs.
- Updates for riscv_isa_extension_available():
  - Code style fixes.
  - Drop conditional operator used in return as functions returns bool.
- s/extenstion/extensions, s/extenstion/extenstion.
- Drop RISCV_ISA_EXT_SxAIA as it isn't used.
- Move definitions of RISCV_ISA_EXT_{a,c,d,...,v} to enum riscv_isa_ext_id.
- Move macros RISCV_ISA_EXT_MAX to enum riscv_isa_ext_id.
- Update the comment above definition of RISCV_ISA_EXT_BASE.
- Fix code style ( violation of line length ) for
  riscv_isa_extension_available().
- Sync commit message with the comment on the start of cpufeature.c
---
 xen/arch/riscv/Makefile                 |   1 +
 xen/arch/riscv/cpufeature.c             | 482 ++++++++++++++++++++++++
 xen/arch/riscv/include/asm/cpufeature.h |  57 +++
 xen/arch/riscv/setup.c                  |   3 +
 4 files changed, 543 insertions(+)
 create mode 100644 xen/arch/riscv/cpufeature.c
 create mode 100644 xen/arch/riscv/include/asm/cpufeature.h

diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
index a5eb2aed4b..b0c8270a99 100644
--- a/xen/arch/riscv/Makefile
+++ b/xen/arch/riscv/Makefile
@@ -1,3 +1,4 @@
+obj-y += cpufeature.o
 obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
 obj-y += entry.o
 obj-y += mm.o
diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c
new file mode 100644
index 0000000000..d4fa5a22a5
--- /dev/null
+++ b/xen/arch/riscv/cpufeature.c
@@ -0,0 +1,482 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Taken for Linux kernel v6.12-rc3.
+ *
+ * Copyright (C) 2015 ARM Ltd.
+ * Copyright (C) 2017 SiFive
+ * Copyright (C) 2024 Vates
+ */
+
+#include <xen/bitmap.h>
+#include <xen/ctype.h>
+#include <xen/device_tree.h>
+#include <xen/errno.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/sections.h>
+
+#include <asm/cpufeature.h>
+
+#ifdef CONFIG_ACPI
+#error "cpufeature.c functions should be updated to support ACPI"
+#endif
+
+struct riscv_isa_ext_data {
+    unsigned int id;
+    const char *name;
+};
+
+#define RISCV_ISA_EXT_DATA(ext_name, ext_id)    \
+{                                               \
+    .id = ext_id,                               \
+    .name = #ext_name,                          \
+}
+
+/* Host ISA bitmap */
+static __ro_after_init DECLARE_BITMAP(riscv_isa, RISCV_ISA_EXT_MAX);
+
+static int __init dt_get_cpuid_from_node(const struct dt_device_node *cpu,
+                                         unsigned long *dt_cpuid)
+{
+    const __be32 *prop;
+    unsigned int reg_len;
+
+    /*
+     * For debug purpose check dt_n_size_cells(cpu) value.
+     *
+     * Based on DT's bindings [1] and RISC-V's DTS files in kernel #size-cells
+     * for cpu node is expected to be 0.
+     *
+     * [1] https://www.kernel.org/doc/Documentation/devicetree/bindings/riscv/cpus.txt
+     */
+    if ( dt_n_size_cells(cpu) != 0 )
+        printk("DT's cpu node `%s`: #size-cells %d\n",
+               dt_node_full_name(cpu), dt_n_size_cells(cpu));
+
+    prop = dt_get_property(cpu, "reg", &reg_len);
+    if ( !prop )
+    {
+        printk("cpu node `%s`: has no reg property\n", dt_node_full_name(cpu));
+        return -EINVAL;
+    }
+
+    if ( reg_len < dt_cells_to_size(dt_n_addr_cells(cpu)) )
+    {
+        printk("cpu node `%s`: reg property too short\n",
+               dt_node_full_name(cpu));
+        return -EINVAL;
+    }
+
+    /*
+     * It is safe to convert `paddr_t` to `unsigned long` as dt_read_paddr()
+     * in the context of this function returns cpuid which according to RISC-V
+     * specification could be from 0 to ((1ULL << (MXLEN)) - 1), where
+     * MXLEN=32 for RV32 and MXLEN=64 for RV64.
+    */
+    *dt_cpuid = dt_read_paddr(prop, dt_n_addr_cells(cpu));
+
+    return 0;
+}
+
+/*
+ * The canonical order of ISA extension names in the ISA string is defined in
+ * chapter 27 of the unprivileged specification.
+ *
+ * The specification uses vague wording, such as should, when it comes to
+ * ordering, so for our purposes the following rules apply:
+ *
+ * 1. All multi-letter extensions must be separated from other extensions by an
+ *    underscore.
+ *
+ * 2. Additional standard extensions (starting with 'Z') must be sorted after
+ *    single-letter extensions and before any higher-privileged extensions.
+ *
+ * 3. The first letter following the 'Z' conventionally indicates the most
+ *    closely related alphabetical extension category, IMAFDQLCBKJTPVH.
+ *    If multiple 'Z' extensions are named, they must be ordered first by
+ *    category, then alphabetically within a category.
+ *
+ * 4. Standard supervisor-level extensions (starting with 'S') must be listed
+ *    after standard unprivileged extensions.  If multiple supervisor-level
+ *    extensions are listed, they must be ordered alphabetically.
+ *
+ * 5. Standard machine-level extensions (starting with 'Zxm') must be listed
+ *    after any lower-privileged, standard extensions.  If multiple
+ *    machine-level extensions are listed, they must be ordered
+ *    alphabetically.
+ *
+ * 6. Non-standard extensions (starting with 'X') must be listed after all
+ *    standard extensions. If multiple non-standard extensions are listed, they
+ *    must be ordered alphabetically.
+ *
+ * An example string following the order is:
+ *    rv64imadc_zifoo_zigoo_zafoo_sbar_scar_zxmbaz_xqux_xrux
+ *
+ * New entries to this struct should follow the ordering rules described above.
+ *
+ * Extension name must be all lowercase (according to device-tree binding)
+ * and strncmp() is used in match_isa_ext() to compare extension names instead
+ * of strncasecmp().
+ */
+const struct riscv_isa_ext_data __initconst riscv_isa_ext[] = {
+    RISCV_ISA_EXT_DATA(i, RISCV_ISA_EXT_i),
+    RISCV_ISA_EXT_DATA(m, RISCV_ISA_EXT_m),
+    RISCV_ISA_EXT_DATA(a, RISCV_ISA_EXT_a),
+    RISCV_ISA_EXT_DATA(f, RISCV_ISA_EXT_f),
+    RISCV_ISA_EXT_DATA(d, RISCV_ISA_EXT_d),
+    RISCV_ISA_EXT_DATA(q, RISCV_ISA_EXT_q),
+    RISCV_ISA_EXT_DATA(h, RISCV_ISA_EXT_h),
+    RISCV_ISA_EXT_DATA(zicntr, RISCV_ISA_EXT_ZICNTR),
+    RISCV_ISA_EXT_DATA(zicsr, RISCV_ISA_EXT_ZICSR),
+    RISCV_ISA_EXT_DATA(zifencei, RISCV_ISA_EXT_ZIFENCEI),
+    RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE),
+    RISCV_ISA_EXT_DATA(zihpm, RISCV_ISA_EXT_ZIHPM),
+    RISCV_ISA_EXT_DATA(zbb, RISCV_ISA_EXT_ZBB),
+    RISCV_ISA_EXT_DATA(smaia, RISCV_ISA_EXT_SMAIA),
+    RISCV_ISA_EXT_DATA(ssaia, RISCV_ISA_EXT_SSAIA),
+};
+
+static const struct riscv_isa_ext_data __initconst required_extensions[] = {
+    RISCV_ISA_EXT_DATA(zbb, RISCV_ISA_EXT_ZBB),
+    RISCV_ISA_EXT_DATA(zicsr, RISCV_ISA_EXT_ZICSR),
+    RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE),
+};
+
+static bool is_lowercase_extension_name(const char *str)
+{
+    /*
+     * `str` could contain full riscv,isa string from device tree so one
+     * of the stop condionitions is checking for '_' as extensions are
+     * separated by '_'.
+     */
+    for ( unsigned int i = 0; (str[i] != '\0') && (str[i] != '_'); i++ )
+        if ( !islower(str[i]) )
+            return false;
+
+    return true;
+}
+
+static void __init match_isa_ext(const char *name, const char *name_end,
+                                 unsigned long *bitmap)
+{
+    const size_t riscv_isa_ext_count = ARRAY_SIZE(riscv_isa_ext);
+
+    for ( unsigned int i = 0; i < riscv_isa_ext_count; i++ )
+    {
+        const struct riscv_isa_ext_data *ext = &riscv_isa_ext[i];
+
+        /*
+         * `name` (according to device tree binding) and
+         * `ext->name` (according to initialization of riscv_isa_ext[]
+         * elements) must be all in lowercase.
+         *
+         * Just to be sure that it is true, ASSERT() is added.
+         */
+        ASSERT(is_lowercase_extension_name(name) &&
+               is_lowercase_extension_name(ext->name));
+
+        if ( (name_end - name == strlen(ext->name)) &&
+             !strncmp(name, ext->name, name_end - name) )
+        {
+            __set_bit(ext->id, bitmap);
+            break;
+        }
+    }
+}
+
+static int __init riscv_isa_parse_string(const char *isa,
+                                         unsigned long *out_bitmap)
+{
+    if ( (isa[0] != 'r') && (isa[1] != 'v') )
+        return -EINVAL;
+
+#if defined(CONFIG_RISCV_32)
+    if ( isa[2] != '3' && isa[3] != '2' )
+        return -EINVAL;
+#elif defined(CONFIG_RISCV_64)
+    if ( isa[2] != '6' && isa[3] != '4' )
+        return -EINVAL;
+#else
+    #error "unsupported RISC-V bitness"
+#endif
+
+    isa += 4;
+
+    while ( *isa )
+    {
+        const char *ext = isa++;
+        const char *ext_end = isa;
+        bool ext_err = false;
+
+        switch ( *ext )
+        {
+        case 'x':
+        case 'X':
+            printk_once("Vendor extensions are ignored in riscv,isa\n");
+            /*
+             * To skip an extension, we find its end.
+             * As multi-letter extensions must be split from other multi-letter
+             * extensions with an "_", the end of a multi-letter extension will
+             * either be the null character or the "_" at the start of the next
+             * multi-letter extension.
+             */
+            for ( ; *isa && *isa != '_'; ++isa )
+                ;
+            ext_err = true;
+            break;
+
+        case 's':
+            /*
+             * Workaround for invalid single-letter 's' & 'u' (QEMU):
+             *   Before QEMU 7.1 it was an issue with misa to ISA string
+             *   conversion:
+             *     https://patchwork.kernel.org/project/qemu-devel/patch/dee09d708405075420b29115c1e9e87910b8da55.1648270894.git.research_trasio@irq.a4lg.com/#24792587
+             *   Additional details of the workaround on Linux kernel side:
+             *     https://lore.kernel.org/linux-riscv/ae93358e-e117-b43d-faad-772c529f846c@irq.a4lg.com/#t
+             *
+             * No need to set the bit in riscv_isa as 's' & 'u' are
+             * not valid ISA extensions. It works unless the first
+             * multi-letter extension in the ISA string begins with
+             * "Su" and is not prefixed with an underscore.
+             */
+            if ( ext[-1] != '_' && ext[1] == 'u' )
+            {
+                ++isa;
+                ext_err = true;
+                break;
+            }
+            fallthrough;
+        case 'S':
+        case 'z':
+        case 'Z':
+            /*
+             * Before attempting to parse the extension itself, we find its end.
+             * As multi-letter extensions must be split from other multi-letter
+             * extensions with an "_", the end of a multi-letter extension will
+             * either be the null character or the "_" at the start of the next
+             * multi-letter extension.
+             *
+             * Next, as the extensions version is currently ignored, we
+             * eliminate that portion. This is done by parsing backwards from
+             * the end of the extension, removing any numbers. This may be a
+             * major or minor number however, so the process is repeated if a
+             * minor number was found.
+             *
+             * ext_end is intended to represent the first character *after* the
+             * name portion of an extension, but will be decremented to the last
+             * character itself while eliminating the extensions version number.
+             * A simple re-increment solves this problem.
+             */
+            for ( ; *isa && *isa != '_'; ++isa )
+                if ( unlikely(!isalnum(*isa)) )
+                    ext_err = true;
+
+            ext_end = isa;
+            if ( unlikely(ext_err) )
+                break;
+
+            if ( !isdigit(ext_end[-1]) )
+                break;
+
+            while ( isdigit(*--ext_end) )
+                ;
+
+            if ( tolower(ext_end[0]) != 'p' || !isdigit(ext_end[-1]) )
+            {
+                ++ext_end;
+                break;
+            }
+
+            while ( isdigit(*--ext_end) )
+                ;
+
+            ++ext_end;
+            break;
+
+        default:
+            /*
+             * Things are a little easier for single-letter extensions, as they
+             * are parsed forwards.
+             *
+             * After checking that our starting position is valid, we need to
+             * ensure that, when isa was incremented at the start of the loop,
+             * that it arrived at the start of the next extension.
+             *
+             * If we are already on a non-digit, there is nothing to do. Either
+             * we have a multi-letter extension's _, or the start of an
+             * extension.
+             *
+             * Otherwise we have found the current extension's major version
+             * number. Parse past it, and a subsequent p/minor version number
+             * if present. The `p` extension must not appear immediately after
+             * a number, so there is no fear of missing it.
+             */
+            if ( unlikely(!isalpha(*ext)) )
+            {
+                ext_err = true;
+                break;
+            }
+
+            if ( !isdigit(*isa) )
+                break;
+
+            while ( isdigit(*++isa) )
+                ;
+
+            if ( tolower(*isa) != 'p' )
+                break;
+
+            if ( !isdigit(*++isa) )
+            {
+                --isa;
+                break;
+            }
+
+            while ( isdigit(*++isa) )
+                ;
+
+            break;
+        }
+
+        /*
+         * The parser expects that at the start of an iteration isa points to the
+         * first character of the next extension. As we stop parsing an extension
+         * on meeting a non-alphanumeric character, an extra increment is needed
+         * where the succeeding extension is a multi-letter prefixed with an "_".
+         */
+        if ( *isa == '_' )
+            ++isa;
+
+        if ( unlikely(ext_err) )
+            continue;
+
+        match_isa_ext(ext, ext_end, out_bitmap);
+    }
+
+    return 0;
+}
+
+static void __init riscv_fill_hwcap_from_isa_string(void)
+{
+    const struct dt_device_node *cpus = dt_find_node_by_path("/cpus");
+    const struct dt_device_node *cpu;
+
+    if ( !cpus )
+    {
+        printk("Missing /cpus node in the device tree?\n");
+        return;
+    }
+
+    dt_for_each_child_node(cpus, cpu)
+    {
+        DECLARE_BITMAP(this_isa, RISCV_ISA_EXT_MAX);
+        const char *isa;
+        unsigned long cpuid;
+
+        if ( !dt_device_type_is_equal(cpu, "cpu") )
+            continue;
+
+        if ( dt_get_cpuid_from_node(cpu, &cpuid) < 0 )
+            continue;
+
+        if ( dt_property_read_string(cpu, "riscv,isa", &isa) )
+        {
+            printk("Unable to find \"riscv,isa\" devicetree entry "
+                   "for DT's cpu%ld node\n", cpuid);
+            continue;
+        }
+
+        riscv_isa_parse_string(isa, this_isa);
+
+        /*
+         * In the unpriv. spec is mentioned:
+         *   A RISC-V ISA is defined as a base integer ISA, which must be
+         *   present in any implementation, plus optional extensions to
+         *   the base ISA.
+         * What means that isa should contain, at least, I or E thereby
+         * this_isa can't be empty too.
+         *
+         * Ensure that this_isa is not empty, so riscv_isa won't be empty
+         * during initialization. This prevents ending up with extensions
+         * not supported by one of the CPUs.
+         */
+        ASSERT(!bitmap_empty(this_isa, RISCV_ISA_EXT_MAX));
+
+        if ( bitmap_empty(riscv_isa, RISCV_ISA_EXT_MAX) )
+            bitmap_copy(riscv_isa, this_isa, RISCV_ISA_EXT_MAX);
+        else
+            bitmap_and(riscv_isa, riscv_isa, this_isa, RISCV_ISA_EXT_MAX);
+    }
+}
+
+static bool __init has_isa_extensions_property(void)
+{
+    const struct dt_device_node *cpus = dt_find_node_by_path("/cpus");
+    const struct dt_device_node *cpu;
+
+    if ( !cpus )
+    {
+        printk("Missing /cpus node in the device tree?\n");
+        return false;
+    }
+
+    dt_for_each_child_node(cpus, cpu)
+    {
+        const char *isa;
+
+        if ( !dt_device_type_is_equal(cpu, "cpu") )
+            continue;
+
+        if ( dt_property_read_string(cpu, "riscv,isa-extensions", &isa) )
+            continue;
+
+        return true;
+    }
+
+    return false;
+}
+
+bool riscv_isa_extension_available(const unsigned long *isa_bitmap,
+                                   enum riscv_isa_ext_id id)
+{
+    if ( !isa_bitmap )
+        isa_bitmap = riscv_isa;
+
+    if ( id >= RISCV_ISA_EXT_MAX )
+        return false;
+
+    return test_bit(id, isa_bitmap);
+}
+
+void __init riscv_fill_hwcap(void)
+{
+    unsigned int i;
+    size_t req_extns_amount = ARRAY_SIZE(required_extensions);
+    bool all_extns_available = true;
+
+    riscv_fill_hwcap_from_isa_string();
+
+    if ( bitmap_empty(riscv_isa, RISCV_ISA_EXT_MAX) )
+    {
+        const char *failure_msg = has_isa_extensions_property() ?
+                                    "\"riscv,isa-extension\" isn't supported" :
+                                    "\"riscv,isa\" parsing failed";
+
+        panic("HW capabilities parsing failed: %s\n", failure_msg);
+    }
+
+    for ( i = 0; i < req_extns_amount; i++ )
+    {
+        const struct riscv_isa_ext_data ext = required_extensions[i];
+
+        if ( !riscv_isa_extension_available(NULL, ext.id) )
+        {
+            printk("Xen requires extension: %s\n", ext.name);
+            all_extns_available = false;
+        }
+    }
+
+    if ( !all_extns_available )
+        panic("Look why the extensions above are needed in "
+              "https://xenbits.xenproject.org/docs/unstable/misc/riscv/booting.txt\n");
+}
diff --git a/xen/arch/riscv/include/asm/cpufeature.h b/xen/arch/riscv/include/asm/cpufeature.h
new file mode 100644
index 0000000000..f5bb612146
--- /dev/null
+++ b/xen/arch/riscv/include/asm/cpufeature.h
@@ -0,0 +1,57 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef ASM__RISCV__CPUFEATURE_H
+#define ASM__RISCV__CPUFEATURE_H
+
+#ifndef __ASSEMBLY__
+
+#include <xen/stdbool.h>
+
+/*
+ * These macros represent the logical IDs of each multi-letter RISC-V ISA
+ * extension and are used in the ISA bitmap. The logical IDs start from
+ * RISCV_ISA_EXT_BASE, which allows the 0-25 range to be reserved for single
+ * letter extensions and are used in enum riscv_isa_ext_id.
+ *
+ * New extensions should just be added to the bottom, rather than added
+ * alphabetically, in order to avoid unnecessary shuffling.
+ */
+#define RISCV_ISA_EXT_BASE  26
+
+enum riscv_isa_ext_id {
+    RISCV_ISA_EXT_a,
+    RISCV_ISA_EXT_c,
+    RISCV_ISA_EXT_d,
+    RISCV_ISA_EXT_f,
+    RISCV_ISA_EXT_h,
+    RISCV_ISA_EXT_i,
+    RISCV_ISA_EXT_m,
+    RISCV_ISA_EXT_q,
+    RISCV_ISA_EXT_v,
+    RISCV_ISA_EXT_ZICNTR = RISCV_ISA_EXT_BASE,
+    RISCV_ISA_EXT_ZICSR,
+    RISCV_ISA_EXT_ZIFENCEI,
+    RISCV_ISA_EXT_ZIHINTPAUSE,
+    RISCV_ISA_EXT_ZIHPM,
+    RISCV_ISA_EXT_ZBB,
+    RISCV_ISA_EXT_SMAIA,
+    RISCV_ISA_EXT_SSAIA,
+    RISCV_ISA_EXT_MAX
+};
+
+void riscv_fill_hwcap(void);
+
+bool riscv_isa_extension_available(const unsigned long *isa_bitmap,
+                                   enum riscv_isa_ext_id id);
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* ASM__RISCV__CPUFEATURE_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index 38ca4f3baa..380461a054 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -13,6 +13,7 @@
 
 #include <public/version.h>
 
+#include <asm/cpufeature.h>
 #include <asm/early_printk.h>
 #include <asm/fixmap.h>
 #include <asm/sbi.h>
@@ -121,6 +122,8 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
         panic("Booting using ACPI isn't supported\n");
     }
 
+    riscv_fill_hwcap();
+
     printk("All set up\n");
 
     machine_halt();
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 23 15:10:08 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 15:10:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876337.1286693 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tayqD-0003Zp-CH; Thu, 23 Jan 2025 15:09:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876337.1286693; Thu, 23 Jan 2025 15:09:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tayqD-0003Zi-9e; Thu, 23 Jan 2025 15:09:57 +0000
Received: by outflank-mailman (input) for mailman id 876337;
 Thu, 23 Jan 2025 15:09:56 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=GMDf=UP=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tayqC-0003Zc-Hz
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 15:09:56 +0000
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com
 [2a00:1450:4864:20::12b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1a095228-d99c-11ef-99a4-01e77a169b0f;
 Thu, 23 Jan 2025 16:09:54 +0100 (CET)
Received: by mail-lf1-x12b.google.com with SMTP id
 2adb3069b0e04-53e3778bffdso1166783e87.0
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 07:09:54 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5439af732ddsm2692294e87.198.2025.01.23.07.09.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 23 Jan 2025 07:09:53 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1a095228-d99c-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1737644994; x=1738249794; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=sOALsuAJW1LZwGF3zk+Y24qSfCH+qPZ25tMRrMAnTtU=;
        b=DIgXfFk8Bsz8AKUwo7I8dUcegIH7fQ76YNJz7af1fggNt559qLNTQFSxi9TEEHvQLT
         /2FvwbjOa1rBwohMiqHoXCkvd3h8K0UlxHdFyEBAqFB2URZ8o7e3SyRiaUv+D0hDVJ0U
         pMfEN5HPM54q4v0s+8NVxKF04OUF1qnGNdCdwIEt9+eGYCvSLgLrRQTXp/HLyiJ6UTPv
         sgiycX4CXRbgEFC60d5J2ESN58mfWvhHhk6xfaTzHXxe97+h2imqz89pxuMkgxXLmYmt
         e1BFsRoNfmLauViqKHt2YFMlIvzQz0i5WvqksuqDpZQ7fN64Ecx80uD5tUiwN8PCCfw6
         MZ3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737644994; x=1738249794;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=sOALsuAJW1LZwGF3zk+Y24qSfCH+qPZ25tMRrMAnTtU=;
        b=Bo9pHWMuqXVuphIZl7Y4/f5VNaCe0RsOoUqB+OSe4pCLYoQiDlCQwsvZm9vOwWt7Hi
         AYXcnB0n4ty27i0kNr95dawhF7FDHojees+CymR8kmqhFU2QW9O7XcJdAV2kPURxSdJO
         rqP2rioiT9WDOMzNHodKChVurqVz6Ymn5ukm0SCoAePNeW3EtXlb7CPIYl4KjWnZ5Ox5
         2QY6KTw0Bk0ANAiaAr5X2S7kHAEjixyLQH0CJhuekD7GH3kazW1la372tPRQvP8feTa+
         31Xh3V+5mFSiwhQ5aJ8IUMg8rI0Yjio+QDXY5XPt3ApsWDMQL3PCecKmEeiWyYZSd3Gz
         a7AA==
X-Forwarded-Encrypted: i=1; AJvYcCWoW1Z9Dyxl1qo0Pa1jsTd97ZOmpOrmbPBl1vjhSCp0ZRnrk8CsWgPeO7DcMyk+pKZzBOX6qD3xGZs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyicFqu/KxcKJSBE0QX/UwDs+DP16LFALOtkV3BmHQXufYkCGOC
	iBTeYXdq0L+uJS9iLSTjZ4Kl6ECUGbGR63btPniFOskshDf8dgIE
X-Gm-Gg: ASbGncvcNrEVDd5iA25PxcIHLyaEFMxtFJfB53aifXFymdJI3YpQa+g1creaGd4/evz
	6sgeSJu7CZXIBTWNn4x2LWc2fWCCyS3X3uvxyJEeo58yLosR26e3GszGj8bSpOvLuHQWz0PSr9y
	8VppoUima3hhHdCbJJfU4Ck8zxv7ArPGv2oyy1NbTycw614bx2AM7mpSVGnqa7WR5ybcGfn8w1H
	/ZyyjshZAOUbyQUT8TWxPCSiQJJXKSWVNnlbq7Qka/7z23IoGa5DyQZZKwNhut85TsnUBAP7cAl
	RTuO/R29z/fc3H0TRQ==
X-Google-Smtp-Source: AGHT+IFCFb5WpdvPDORwvGAHR84eWKRFZI6LeOWIeX5qpvBwPqmFa1BlELIVlWsR549q4JGpr3AKkg==
X-Received: by 2002:a19:740f:0:b0:542:2388:3f05 with SMTP id 2adb3069b0e04-5439c25122fmr8547193e87.31.1737644993737;
        Thu, 23 Jan 2025 07:09:53 -0800 (PST)
Message-ID: <a8cb8a0d-9c44-4e1b-92f3-50928f03ebd2@gmail.com>
Date: Thu, 23 Jan 2025 16:09:52 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH partly-for-4.20 v3 0/4] x86/HVM: emulation (MMIO)
 improvements
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
References: <729f7896-55b7-4b5b-a7e9-6eb0420e0b14@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <729f7896-55b7-4b5b-a7e9-6eb0420e0b14@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 1/23/25 11:29 AM, Jan Beulich wrote:
> The main fix is patch 2, with the earlier patch setting the stage and
> the latter ones simplifying other things at least a little in exchange.
>
> 1: allocate emulation cache entries dynamically
> 2: correct read/write split at page boundaries
> 3: slightly improve CMPXCHG16B emulation
> 4: drop redundant access splitting
>
> Oleksii - the first two patches (plus the simple one from v2 that I just
> committed) are backporting material, and hence I'd like to ask for a
> release ack for at least those two.

R-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> for first two 
patches.

Thanks.

~ Oleksii




From xen-devel-bounces@lists.xenproject.org Thu Jan 23 15:46:49 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 15:46:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876346.1286704 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tazPc-0000f0-T1; Thu, 23 Jan 2025 15:46:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876346.1286704; Thu, 23 Jan 2025 15:46:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tazPc-0000et-Pq; Thu, 23 Jan 2025 15:46:32 +0000
Received: by outflank-mailman (input) for mailman id 876346;
 Thu, 23 Jan 2025 15:46:31 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=NrAP=UP=bounce.vates.tech=bounce-md_30504962.67926454.v1-6f4cd110751f4a0d9dc20ee8aea8c00f@srs-se1.protection.inumbo.net>)
 id 1tazPb-0000en-NL
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 15:46:31 +0000
Received: from mail180-4.suw31.mandrillapp.com
 (mail180-4.suw31.mandrillapp.com [198.2.180.4])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 35bc0b3d-d9a1-11ef-a0e5-8be0dac302b0;
 Thu, 23 Jan 2025 16:46:29 +0100 (CET)
Received: from pmta11.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail180-4.suw31.mandrillapp.com (Mailchimp) with ESMTP id 4Yf5041JkvzlgWY5
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 15:46:28 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 6f4cd110751f4a0d9dc20ee8aea8c00f; Thu, 23 Jan 2025 15:46:28 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 35bc0b3d-d9a1-11ef-a0e5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1737647188; x=1737917188;
	bh=qZYA7QoYh/1BL2aHwxg5JDHqafw6k32+xHrB0+1VTtY=;
	h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=gmtyhtKMAGb2z6HZ8meI9nwufwSi5GiYAOim+wcDCXiPqLiIj1EqnTmCEhN9HBQ86
	 Ik26KQJ28Mq7QGbCD4umcMGh2wAl//77UA2PT2I4XLl7iJYkrzyZcc6akNIzzVEO9i
	 tmUeukYFf410c9tHIS9xYBt8gejX9R5iMesSTAc7rddxRhwCsitSIXmg0LK4QD3VPm
	 +ZHi85keV8wmNrrfBhbWWiTmH9y+9yTsS5gVse8sI+a93DePIQfZV5xo8RiYKcAkYY
	 AkTiOKq7FdhfDGdrjGHkhvWb3ifnu/4pAEmUlEGrjTX59GALseQHLVxeRXT7DceXdx
	 Qkf/uWTEwpVYg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1737647188; x=1737907688; i=teddy.astie@vates.tech;
	bh=qZYA7QoYh/1BL2aHwxg5JDHqafw6k32+xHrB0+1VTtY=;
	h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=dyClGd/nxuC+0lrygYRAG0p1G+pQqxIOX6B6ACHxfxfyp0uhDQ8BIB9LXCmpu4dHb
	 wE5z09tq48wCF+Nqv1+BMVLxwjI1X378iWcgnrXcuy3KrvXMLomz9XG4SvTsDs3WIU
	 amCoSbPtZj0eWUOQOPt9xb4DxqBe25Bwc6cVd0Btsm2itWIC+x903X8GvzSod+WgTZ
	 Ecjr/nuQ76UPwV0ieSqrt15rqAuUyn/x3vfHKOhRHNlmik0FkDdjrfO3rT3aMfF4SX
	 PnZ/7B2+K3t7ayRzQKUrDd5VAVJVpl0UHlu3dVjPR25Gv6/jxXOm704RMhDhA5VPKB
	 zyplFrcEhiP0A==
From: "Teddy Astie" <teddy.astie@vates.tech>
Subject: =?utf-8?Q?Re:=20[XEN=20RFC=20PATCH=20v5=200/5]=20IOMMU=20subsystem=20redesign=20and=20PV-IOMMU=20interface?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1737647186337
Message-Id: <27cbe4ae-054d-454e-8d8a-3eb2f4af7654@vates.tech>
To: "=?utf-8?Q?Marek=20Marczykowski-G=C3=B3recki?=" <marmarek@invisiblethingslab.com>
Cc: xen-devel@lists.xenproject.org, "Andrew Cooper" <andrew.cooper3@citrix.com>, "Jan Beulich" <jbeulich@suse.com>, "Julien Grall" <julien@xen.org>, "Stefano Stabellini" <sstabellini@kernel.org>, "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>, "Lukasz Hawrylko" <lukasz@hawrylko.pl>, "Daniel P. Smith" <dpsmith@apertussolutions.com>, "=?utf-8?Q?Mateusz=20M=C3=B3wka?=" <mateusz.mowka@intel.com>
References: <cover.1737470269.git.teddy.astie@vates.tech> <Z5I59HC77QxpPtJG@mail-itl>
In-Reply-To: <Z5I59HC77QxpPtJG@mail-itl>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.6f4cd110751f4a0d9dc20ee8aea8c00f?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250123:md
Date: Thu, 23 Jan 2025 15:46:28 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hello Marek,
Thanks for your testing.

Le 23/01/2025 =C3=A0 13:45, Marek Marczykowski-G=C3=B3recki a =C3=A9crit=C2=
=A0:
> Thanks for the updated patches. I have run them through gitlab-
ci, and
> here are some observations:
> - I needed to disable CONFIG_AMD_IOMMU (it fails to build, as expected at=
 this point)
> - I needed to disable pvshim (it fails to build)

> - fails to build with clang: https://gitlab.com/xen-project/people/marmar=
ek/xen/-/jobs/8931373789/viewer#L3525> - gcc-ibt build fails: 
https://gitlab.com/xen-project/people/marmarek/xen/-/jobs/8931373785#L1314

Looks like another cf_check related issue that I missed.

> - fails to build for ARM (both 32 and 64) and PPC64

This is expected like for the AMD_IOMMU part.

> - QEMU smoke test panic with PV dom0, looks like it runs on AMD, so it
>    may be related to the disabled CONFIG_AMD_IOMMU, but I wouldn't expect
>    it to panic on _PV_ dom0 boot...

Looks like I broke something when there is no IOMMU detected (removed 
some check that should be there).

This patch should fix it (tested with QEMU without IOMMU).

---
diff --git a/xen/drivers/passthrough/context.c 
b/xen/drivers/passthrough/context.c
index 6e68f840f3..98c84b439b 100644
--- a/xen/drivers/passthrough/context.c
+++ b/xen/drivers/passthrough/context.c
@@ -347,6 +347,10 @@ int iommu_iotlb_flush_all(struct domain *d, u16 
ctx_no, unsigned int flush_flags
      struct iommu_context *ctx;
      int rc;

+    if ( !is_iommu_enabled(d) || !hd->platform_ops->iotlb_flush ||
+         !flush_flags )
+        return 0;
+
      if ( !(ctx =3D iommu_get_context(d, ctx_no)) )
          return -ENOENT;

---

> - PVH dom0 fails to boot (on real hw) with a lot of VT-d faults: https://=
gitlab.com/xen-project/people/marmarek/xen/-/jobs/8931373875

I guess 00:02.0 is the iGPU. The addresses point to reserved memory in 
E820 (is it the framebuffer ?) which should be reconfigured by the guest.

Is the guest dying (maybe due to the PVH Dom0 issue) before being able
to setup anything, causing the GPU to not be properly set ?
I tested a plain Alpine 3.18 PVH Dom0 and the kernel crashes very early
(6.1.123-0-lts though).

Or there is something else going wrong like with PCI Passthrough.
> - PCI passthrough (with PV dom0) results in a lot of VT-d faults: 
> Note this uses only this series, but plain Linux (appears to be 6.1.19).
> IIUC if one doesn't try to configure PV-IOMMU specifically (non-default
> contexts) it should still work.

Yes, and PV-IOMMU drivers will likely not fix the issues you are facing.

> 
> BTW Linux says it detected "Xen version 4.19." - shouldn't it report
> 4.20 already at this point in release cycle?
> 

It's probably because I mostly tested on Xen 4.19 (for practical reasons 
to make toolstack happy), but I will update it to staging.

> All results:
> https://gitlab.com/xen-project/people/marmarek/xen/-/pipelines/1637849303
> 

Thanks

Teddy



Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech



From xen-devel-bounces@lists.xenproject.org Thu Jan 23 16:14:50 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 16:14:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876357.1286714 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tazqu-0005Dk-Vx; Thu, 23 Jan 2025 16:14:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876357.1286714; Thu, 23 Jan 2025 16:14:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tazqu-0005Dd-SX; Thu, 23 Jan 2025 16:14:44 +0000
Received: by outflank-mailman (input) for mailman id 876357;
 Thu, 23 Jan 2025 16:14:43 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=nhpA=UP=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tazqt-0005DX-KZ
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 16:14:43 +0000
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com
 [2a00:1450:4864:20::333])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 26c9c5a7-d9a5-11ef-99a4-01e77a169b0f;
 Thu, 23 Jan 2025 17:14:41 +0100 (CET)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-43635796b48so7869585e9.0
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 08:14:41 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438b31c6fbasm65761645e9.33.2025.01.23.08.14.40
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 23 Jan 2025 08:14:40 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 26c9c5a7-d9a5-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737648881; x=1738253681; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=PZ4ivLeAwKE7KroPvTmAfQrCzVUwXfNphHY6Uzsd7mg=;
        b=I8w/ULaTj9voPOpWb0GyO03bJPdrHmWZ1S93wgcoCIUrDPHkjJdwskpz3EV7ASvIx2
         ADtLzbfrS/xomTECtyDE2mLJ8wflzgyL+6pb2VDVzetF6BOK5kDRm4DzBA3cD/e4A7hO
         C5gXNfOMUT3WX2luGS0SWjWHuJp8lwGBbMack/VEZNEair4fov/BPWkL5BBXOMF3QC8S
         imYrOb4UZUwDHSaTzPmwp2k9jbzfu0byhLx1c2uTo28JMLlFXk9PmrImu0t2Yh8e3HPu
         iKdJBOtzqcs5MDgD0lCZtmALgQtqrvSTb78VNmkTc1EeKtzvV++LRirKd4C0QuAuzJWa
         /Eiw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737648881; x=1738253681;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=PZ4ivLeAwKE7KroPvTmAfQrCzVUwXfNphHY6Uzsd7mg=;
        b=LYXW5TsEJmKL32JitNds/PBAyFiB7eDGLZU41ZKe+5lBoNi30LoT1YkIMiESYLPoIe
         UVNGME8QDJ9DRD1HY4tp8aYfT2R5Vga8IqVQQg1cjbS8Mw9m/4KVFlZHTwG3cAsnAFGf
         2ukwm0kE0fMshvJ971MsfoFIH3WV/C51FKlj10/upN1gNL9a1bBKibhxppAxx++MNjCv
         i4k/XnD5IMLaykwqumvCfZYIDaj8JLpYj82XlgCfgzmMVOA5kd/uLF3TruG26xj6OIvR
         oLmUIHIcZGW7bbG702V2Uftq5mDzQ+rMz6uc6iqRxllGpkWsznOIz3PRjwHk02wTZkzL
         tnVA==
X-Gm-Message-State: AOJu0Yzf1yk1VgzoifnDiE2heGbEPiLR+uWxfNxgCzSBXrmU7DuLhxjk
	n/wDE+xJTBFId8cYe8Al6VAPu0kTbxqF41LLtYECwtd2Yn2ZeKqukigetviN/w==
X-Gm-Gg: ASbGnct8t3RTfwXu2QwnxikbHQTjSDMVakqeg0Ya9glQfvps+1oTP3uLFrVy9JROlwk
	xdlpGgPKIBHfwO6KWhpOrBekWxK7MwMafpWDRWEAicvHVVOj3098Ph3J1Su2XYPll76XgDmueCO
	9C08wE+XXKYk3PIdehzcDLh7cJWG7FyJFFY9gNXcsCEneNT8v5MqqvHL2OtlCGhUvN6N9ns5zHe
	nr8FPRebMjKKya7NgnjwUUuhJLLawFNegEECmtibj2rGkgytU+euNxzXN1GmxyhjKpCocDyKU6Q
	VobiMzeOeu8exvNw7qpuDO7ZF5z8q6d8GOaFNcokwapK4FLwsrKP5oda5DNu1jO6QQ==
X-Google-Smtp-Source: AGHT+IFQleoj5MhZsMmVajEiKDgPZgo5utL3vrTngILg1WPPDOcNjUvSope6kTPgCOkghr3cdmMUZw==
X-Received: by 2002:a05:600c:83c4:b0:434:fe3c:c662 with SMTP id 5b1f17b1804b1-438b885be4cmr34116705e9.12.1737648881104;
        Thu, 23 Jan 2025 08:14:41 -0800 (PST)
Message-ID: <8aa7c377-b664-4786-b671-deff1601ac5f@suse.com>
Date: Thu, 23 Jan 2025 17:14:39 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 02/12] x86/HVM: improve CET-IBT pruning of ENDBR
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
 Kevin Tian <kevin.tian@intel.com>, Jun Nakajima <jun.nakajima@intel.com>
References: <293e5aef-8843-461c-bc96-709a605b2680@suse.com>
 <537b0d9c-1936-4cf5-a012-d50b1097a22d@suse.com>
 <Z5I5D_uVxijLF6sK@macbook.local>
 <f0e2a3f3-3081-414d-824c-bf940134aece@suse.com>
 <Z5JRGwA51lOs65t5@macbook.local>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <Z5JRGwA51lOs65t5@macbook.local>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 23.01.2025 15:24, Roger Pau Monné wrote:
> On Thu, Jan 23, 2025 at 02:18:41PM +0100, Jan Beulich wrote:
>> On 23.01.2025 13:41, Roger Pau Monné wrote:
>>> On Mon, Feb 26, 2024 at 05:42:20PM +0100, Jan Beulich wrote:
>>>> --- a/xen/arch/x86/hvm/hvm.c
>>>> +++ b/xen/arch/x86/hvm/hvm.c
>>>> @@ -161,10 +161,15 @@ static int __init cf_check hvm_enable(vo
>>>>      else if ( cpu_has_svm )
>>>>          fns = start_svm();
>>>>  
>>>> +    if ( fns )
>>>> +        hvm_funcs = *fns;
>>>> +
>>>> +    prune_vmx();
>>>> +    prune_svm();
>>>
>>> Isn't it actually the opposite of pruning.  What the helpers do is
>>> fill all the pointers in the structure.
>>
>> With the goal of their ENDBR to then be pruned. I agree though that the
>> functions don't do any pruning themselves. Yet
>> {svm,vmx}_prepare_for_cet_ibt_pruning() is a little awkward for my taste
>> (although it would properly document the purpose). Plus ...
>>
>>>  I would rather name them {vmx,svm}_fill_hvm_funcs() or similar.
>>
>> ... while I can use those names (perhaps without the "hvm" infix), the
>> present names have the advantage that any other pruning that we may
>> find desirable could also be put there. Hence also why the cpu_has_*
>> checks live there.
> 
> Hm, I'm unsure.  What else do you see becoming part of those
> functions?  It's hard for me to suggest a name when it's unclear what
> future logic do you think they could contain.

Prior to IBT it wasn't foreseeable any pruning might be needed. We're
in a similar position now: We simply can't know whether anything else
is going to be needed there.

> Given the current code I still think something that contains 'fill' or
> similar is way more appropriate, the more if the IBT check is pulled
> out into the caller.

As indicated, I'd prefer the IBT check to remain in the function. But
yes, I'll see about renaming. If ever other stuff wants adding there,
we can surely rename another time.

>>>  And possibly pull the
>>> cpu_has_xen_ibt check outside the functions:
>>>
>>> if ( cpu_has_xen_ibt )
>>> {
>>>     /*
>>>      * Now that svm_function_table was copied, populate all function pointers
>>>      * which may have been left at NULL, for __initdata_cf_clobber to have as
>>>      * much of an effect as possible.
>>>      */
>>>     vmx_fill_hvm_funcs();
>>>     svm_fill_hvm_funcs();
>>> }
>>
>> Which would leave the SVM function entirely empty.
> 
> You could possible declare it as an static inline in the hvm.h header
> for the time being?
> 
>> The intention was for
>> that to not be the case, and also for the comment you have added above
>> to also live in the per-vendor functions.
> 
> Isn't that a bit redundant?  I would prefer to not have duplicated
> comments over the code, hence my suggestion to place part of the logic
> in the caller.

In this case I view the redundancy as necessary. You want to know what
to add to the functions when you look at them, irrespective of whether
you also look at their caller.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 23 21:12:02 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 21:12:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876377.1286724 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb4UH-0006pe-Bz; Thu, 23 Jan 2025 21:11:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876377.1286724; Thu, 23 Jan 2025 21:11:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb4UH-0006pX-8M; Thu, 23 Jan 2025 21:11:41 +0000
Received: by outflank-mailman (input) for mailman id 876377;
 Thu, 23 Jan 2025 21:11:40 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=7sXU=UP=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tb4UF-0006pJ-9t
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 21:11:40 +0000
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a02e704c-d9ce-11ef-99a4-01e77a169b0f;
 Thu, 23 Jan 2025 22:11:34 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a02e704c-d9ce-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1737666692; x=1737925892;
	bh=YO8OSyrNHGNT7NRkbRI6g+/A3sBKeBEhmQqYM0FnKZM=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=iNOHHijTOfTLCrq69Z29qNA9h4hhqZqbiau9zvpCzYPC9yl83qj8XZBqxXsImkdr8
	 L/tHVwmLIUKFonT2SGjTtir/Nvw1UmkYYNQNaNXtvM59r1pg7XqaKPP4647rhHmZRR
	 YcQOHIjVLuddM6ANsm9NVYCnNR7JYorLXG2C6lfSJ+bgQ5E8RK7KN1LfgXqREwdXRL
	 tkPfY1J+/SQEjLx00QXj6LGFZwBCNcSIRwbyijHuobL8HMaAV/qnjhCj+DZT7vUIpr
	 lotMs0RIHaCvrbtYS1PP9IchaOjqjwAHsylEKzE7BrQJoQFw6D+SvyPtv5/Uq2XG2H
	 mWUZ1p123XSCw==
Date: Thu, 23 Jan 2025 21:11:26 +0000
To: Jan Beulich <jbeulich@suse.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>, Andrew Cooper <andrew.cooper3@citrix.com>, Anthony PERARD <anthony.perard@vates.tech>, =?utf-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 01/24] xen/ctype: introduce is_console_printable()
Message-ID: <qUr2zHXrlh8KYYpH00v4yhSvka5v2rcdUHmW6ajV3qp91yOaid-3V72YxE_hfeB0P64gJkjchYvqfHZWlp7WzcMg3GDUk8APnTPVxP_NDuQ=@proton.me>
In-Reply-To: <c490d01a-fe97-414d-8093-b0bff6a12eec@suse.com>
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com> <20250103-vuart-ns8250-v3-v1-1-c5d36b31d66c@ford.com> <c490d01a-fe97-414d-8093-b0bff6a12eec@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 3ca0b26640700fb1c8c3b3ef90897f5ebc7a38bb
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tuesday, January 21st, 2025 at 11:19 PM, Jan Beulich <jbeulich@suse.com>=
 wrote:

>=20
>=20
> On 04.01.2025 02:58, Denis Mukhin via B4 Relay wrote:
>=20
> > --- a/xen/include/xen/ctype.h
> > +++ b/xen/include/xen/ctype.h
> > @@ -4,6 +4,8 @@
> > /*
> > * NOTE! This ctype does not handle EOF like the standard C
> > * library is required to.
> > + *
> > + * See Rule 21.13 in docs/misra/rules.rst.
> > */
>=20
>=20
> As previously indicated, I object to such comments. I think I said so bef=
ore:
> All Misra rules are relevant everywhere anyway.

Correct, I received that feedback in v2 comments, but after I posted v3
on the mailing list.

That will be addressed in the next iteration.

>=20
> > @@ -51,4 +53,9 @@ static inline unsigned char __toupper(unsigned char c=
)
> > #define tolower(c) ((char)__tolower(c))
> > #define toupper(c) ((char)__toupper(c))
> >=20
> > +static inline unsigned is_console_printable(unsigned char c)
> > +{
> > + return isprint(c) || c =3D=3D '\n' || c =3D=3D '\t';
> > +}
>=20
>=20
> Why a return type of unsigned (and then not even "unsigned int")? I can't
> spot anything in the file which would serve as a reference for this, and
> by its nature the function clearly wants to return bool.
>=20
> I further question the placement of this function in ctype.h: Only consol=
e
> related code cares about this function, so exposure is far too wide this
> way.

I will move that to console.h in v4.
Thanks.

>=20
> Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 23 23:44:31 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 23:44:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876390.1286753 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6s9-0008Dp-W0; Thu, 23 Jan 2025 23:44:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876390.1286753; Thu, 23 Jan 2025 23:44:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6s9-0008Di-T2; Thu, 23 Jan 2025 23:44:29 +0000
Received: by outflank-mailman (input) for mailman id 876390;
 Thu, 23 Jan 2025 23:44:29 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=QxCy=UP=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tb6s9-0007hN-5d
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 23:44:29 +0000
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com
 [2a00:1450:4864:20::42a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id fba857b2-d9e3-11ef-99a4-01e77a169b0f;
 Fri, 24 Jan 2025 00:44:27 +0100 (CET)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-385df53e559so1133687f8f.3
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 15:44:27 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38c2a17d6e2sm989811f8f.23.2025.01.23.15.44.25
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 23 Jan 2025 15:44:26 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: fba857b2-d9e3-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737675867; x=1738280667; 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=4nuXtmGFXC6ord9LKCUcMBdqEKN9u5T/6Xkbf7Pq9+s=;
        b=Gm1Rwz1Ej4xWapZtJpOvUo7Vj9iGnyELUcoaRwcc47DMm3/GkikBmZue3bTmXGC/rK
         4dFoFKdsyns1G7mqGduPHFLWo42wYSyVo33PGsYTUn7cwPkftCQyvckeWjcD6TOthFtk
         mKPhFL4Fc2CtAdh8XbfWE2JpFkf0g5L7GhcwhdugoVJC/yXA00XWpN0Rc+PwWmWp1d21
         SuaR9HhhxN8PukvdGzK0JAIOm2pSQg4D2pzf/OWLwwbmqlqguf8XrmJpBCZkuh0acJPW
         JtKzVsI+6fL4STQcxxdYhT0B6tWNEMj2pwr7VLPR98+Pg5uvb+a454oIDfJ4LwgIrtVH
         VVsA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737675867; x=1738280667;
        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=4nuXtmGFXC6ord9LKCUcMBdqEKN9u5T/6Xkbf7Pq9+s=;
        b=RBZxwe+LPjZqTJ+Qx8U3LXFgN7KilptYvLS+s97iQP1PWmzQLYtTSYM0VbMpGc9/6c
         RfZ18BHiCVx+XmdRlQMzKuddiy3/SLAQujhABTC4/P1o0nB052Fa4IK+mb+R4r95CC6U
         aEFcktuDKKsb2wkMDxgorno94iyjgHsvIO2qXhLTFXGqYfjyjfvS9CDZSD9h/0VCLN9u
         lU6h8Or9yYc3Ll+jC+uhkZkn0iqeIoDeAo9KgwvH21jk7dZxMl1k+mqBreHSXBsUUm7x
         COeD+EJNCounXDhW3iRr7GDbpUxpWC4YDEuni7Mc0uLppEdmw19I6WC8AExMEQqxsMbl
         5wrA==
X-Forwarded-Encrypted: i=1; AJvYcCXOjH5ZOURC1YR031D5dyPeMC/3l6wSJ3mC1us1i/JJ3qmFCjhTsD1QjV6bSG0HbtIAAcZzqeaN+Xs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxJ72by1UqHzeAf1khyBGEm39P/+AphJuJYTxQDnLPfqhspuIx5
	SPe5lGeWzfItqQMqgRkfjEQaKH7/53b8Js4hXMmWnj1NvlGxMyRe2bErN3Kz5XA=
X-Gm-Gg: ASbGncuR4A3f3kTa+SuwfzL5FCoea5bKmloO4/fdxr+lWLoBS2aPNyBHnF16BGAd+Dz
	hAebmo53CubVZGz6haiy+kTSV158ALn3nyfL4pwAiegAdeetJmVhS/gmFjYr0CMEIWVkfmX0fxv
	IUt7pNqGGzNNZI8/UTI4hPhVYOG2G/yLqUAN3csbO8tRb8wOMg5K7IMldqsYF/iHEcQh4tD2e/u
	LGk8X7g5Qxxo34aJEfyWBKgrbpdOBVvLxGKiIGUpL0NVDaW8+C95cot7g3lbDlR6BAWYAs20A3s
	TSgarR5pcKUr0Ew0u0WVYlWv6rUmYTSl8tXc7uG9MDnZl23aQAx/I8s=
X-Google-Smtp-Source: AGHT+IHv5zns5zWE/8mYKYb9FdwvG4F/GC7lN2DJcXXFDd0WLjCHyuvzadU0RlDxZ5dNLmoZuF9u5A==
X-Received: by 2002:a05:6000:1887:b0:38a:87cc:fb42 with SMTP id ffacd0b85a97d-38bf56639d5mr27205303f8f.21.1737675867076;
        Thu, 23 Jan 2025 15:44:27 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	qemu-arm@nongnu.org,
	Igor Mammedov <imammedo@redhat.com>,
	=?UTF-8?q?Alex=20Benn=C3=A9e?= <alex.bennee@linaro.org>,
	kvm@vger.kernel.org,
	qemu-ppc@nongnu.org,
	qemu-riscv@nongnu.org,
	David Hildenbrand <david@redhat.com>,
	qemu-s390x@nongnu.org,
	xen-devel@lists.xenproject.org,
	Richard Henderson <richard.henderson@linaro.org>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
Subject: [PATCH 02/20] user: Extract common MMAP API to 'user/mmap.h'
Date: Fri, 24 Jan 2025 00:43:56 +0100
Message-ID: <20250123234415.59850-3-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250123234415.59850-1-philmd@linaro.org>
References: <20250123234415.59850-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Keep common MMAP-related declarations in a single place.

Note, this disable ThreadSafetyAnalysis on Linux for:
- mmap_fork_start()
- mmap_fork_end().

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 bsd-user/qemu.h        | 12 +-----------
 include/user/mmap.h    | 32 ++++++++++++++++++++++++++++++++
 linux-user/user-mmap.h | 19 ++-----------------
 3 files changed, 35 insertions(+), 28 deletions(-)
 create mode 100644 include/user/mmap.h

diff --git a/bsd-user/qemu.h b/bsd-user/qemu.h
index 4e97c796318..c1c508281a8 100644
--- a/bsd-user/qemu.h
+++ b/bsd-user/qemu.h
@@ -32,6 +32,7 @@
 extern char **environ;
 
 #include "user/thunk.h"
+#include "user/mmap.h"
 #include "target_arch.h"
 #include "syscall_defs.h"
 #include "target_syscall.h"
@@ -233,19 +234,8 @@ void print_taken_signal(int target_signum, const target_siginfo_t *tinfo);
 extern int do_strace;
 
 /* mmap.c */
-int target_mprotect(abi_ulong start, abi_ulong len, int prot);
-abi_long target_mmap(abi_ulong start, abi_ulong len, int prot,
-                     int flags, int fd, off_t offset);
-int target_munmap(abi_ulong start, abi_ulong len);
-abi_long target_mremap(abi_ulong old_addr, abi_ulong old_size,
-                       abi_ulong new_size, unsigned long flags,
-                       abi_ulong new_addr);
 int target_msync(abi_ulong start, abi_ulong len, int flags);
-extern abi_ulong mmap_next_start;
-abi_ulong mmap_find_vma(abi_ulong start, abi_ulong size);
 void mmap_reserve(abi_ulong start, abi_ulong size);
-void TSA_NO_TSA mmap_fork_start(void);
-void TSA_NO_TSA mmap_fork_end(int child);
 
 /* main.c */
 extern char qemu_proc_pathname[];
diff --git a/include/user/mmap.h b/include/user/mmap.h
new file mode 100644
index 00000000000..4d004e6b822
--- /dev/null
+++ b/include/user/mmap.h
@@ -0,0 +1,32 @@
+/*
+ * MMAP declarations for QEMU user emulation
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+#ifndef USER_MMAP_H
+#define USER_MMAP_H
+
+#include "user/abitypes.h"
+
+/*
+ * mmap_next_start: The base address for the next mmap without hint,
+ * increased after each successful map, starting at task_unmapped_base.
+ * This is an optimization within QEMU and not part of ADDR_COMPAT_LAYOUT.
+ */
+extern abi_ulong mmap_next_start;
+
+int target_mprotect(abi_ulong start, abi_ulong len, int prot);
+
+abi_long target_mmap(abi_ulong start, abi_ulong len, int prot,
+                     int flags, int fd, off_t offset);
+int target_munmap(abi_ulong start, abi_ulong len);
+abi_long target_mremap(abi_ulong old_addr, abi_ulong old_size,
+                       abi_ulong new_size, unsigned long flags,
+                       abi_ulong new_addr);
+
+abi_ulong mmap_find_vma(abi_ulong, abi_ulong, abi_ulong);
+
+void TSA_NO_TSA mmap_fork_start(void);
+void TSA_NO_TSA mmap_fork_end(int child);
+
+#endif
diff --git a/linux-user/user-mmap.h b/linux-user/user-mmap.h
index b94bcdcf83c..dfc4477a720 100644
--- a/linux-user/user-mmap.h
+++ b/linux-user/user-mmap.h
@@ -18,6 +18,8 @@
 #ifndef LINUX_USER_USER_MMAP_H
 #define LINUX_USER_USER_MMAP_H
 
+#include "user/mmap.h"
+
 /*
  * Guest parameters for the ADDR_COMPAT_LAYOUT personality
  * (at present this is the only layout supported by QEMU).
@@ -39,24 +41,7 @@
 extern abi_ulong task_unmapped_base;
 extern abi_ulong elf_et_dyn_base;
 
-/*
- * mmap_next_start: The base address for the next mmap without hint,
- * increased after each successful map, starting at task_unmapped_base.
- * This is an optimization within QEMU and not part of ADDR_COMPAT_LAYOUT.
- */
-extern abi_ulong mmap_next_start;
-
-int target_mprotect(abi_ulong start, abi_ulong len, int prot);
-abi_long target_mmap(abi_ulong start, abi_ulong len, int prot,
-                     int flags, int fd, off_t offset);
-int target_munmap(abi_ulong start, abi_ulong len);
-abi_long target_mremap(abi_ulong old_addr, abi_ulong old_size,
-                       abi_ulong new_size, unsigned long flags,
-                       abi_ulong new_addr);
 abi_long target_madvise(abi_ulong start, abi_ulong len_in, int advice);
-abi_ulong mmap_find_vma(abi_ulong, abi_ulong, abi_ulong);
-void mmap_fork_start(void);
-void mmap_fork_end(int child);
 
 abi_ulong target_shmat(CPUArchState *cpu_env, int shmid,
                        abi_ulong shmaddr, int shmflg);
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 23 23:44:31 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 23:44:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876388.1286733 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6s1-0007ha-CB; Thu, 23 Jan 2025 23:44:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876388.1286733; Thu, 23 Jan 2025 23: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 <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6s1-0007hT-95; Thu, 23 Jan 2025 23:44:21 +0000
Received: by outflank-mailman (input) for mailman id 876388;
 Thu, 23 Jan 2025 23:44: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 <SRS0=QxCy=UP=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tb6rz-0007hN-Vd
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 23:44:20 +0000
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com
 [2a00:1450:4864:20::32c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f5d396ac-d9e3-11ef-99a4-01e77a169b0f;
 Fri, 24 Jan 2025 00:44:17 +0100 (CET)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-43690d4605dso10331405e9.0
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 15:44:17 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438bd54c098sm6544235e9.31.2025.01.23.15.44.15
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 23 Jan 2025 15:44:16 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f5d396ac-d9e3-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737675857; x=1738280657; 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=SrJqTercMM7Oiv7TI6NgScSjNQ/Q43/m4EWNljCwQJg=;
        b=pMhCITg/5t9F82JB+WtHPGBhqZEoI1oBwILVyfi1rN2/DisTsyjCRH1pU1PPlZVFi2
         HG9/wAk/4YsetLosxr6Dx6zoxPxN/1UFG5TF6jbI6NrBozDEmL6Xrw/05bI58wPGQPKN
         OULnSS1Phc2GoRh1HSSx1cnDXFjeMdE6M7L62n8dZtRaPLxXFFGsfeO49o6tawTZDCGa
         mCge5Ivoubqb4JcKIKJXnrNfNAj1ybp1JzoOoKaR1Mo2TvkFbp3mDMvAAVWX6PhGmaIV
         pDqaKrrx9Gi70542ONK/q/X0G8Ml3Vbs5n8+Vx5sxieNRG8JSUdr1YFuvltwVFi7MRRw
         3B4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737675857; x=1738280657;
        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=SrJqTercMM7Oiv7TI6NgScSjNQ/Q43/m4EWNljCwQJg=;
        b=v20ZYVaAyGOA7mlEqEvCwO2zC1HiIEsrvC2LmTyOSrHDcbovNIq2jh/Z1H0DwReM9k
         kLWjoqPNqEg5T2jTq1T6XIPzQskB2jfclaf8qmQFnxx1fqi+ikzlHztQxYM/33+w+ujb
         GFabHtzIWWF1Nz71cxddLY/ZcwEwI5enpU3tG4RglUdFXkbboU4gJUuhU0sTtujAb5fG
         rGLSBjaN0dsNfwG9tRFl74yujkTX9OjAocz0sVpDT10mz/l2PTFCoE5QoQSVu5NcVCXj
         3Vxo/7a8zlyyO0NtBkoEhR457/7zThw4TdDvGuTn8dGuHulZiuO+ELSf27eN+KIbPFhR
         4D2A==
X-Forwarded-Encrypted: i=1; AJvYcCV7uaPZowpgsRO6IzrE/IWJMJzMVk48BzYf67yreUUnuRMRgsP2QVjyC9v3iJTxcC8FXwGzivlyrRQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz/Vqcey3cp/FB0sDQ/OeI/wbNEJTUoa5Pe1UDV6swH59LBWAqk
	nrOSZSdaba9IguCajfL5cGOCK3C+u9WE7US1JorWA1BWzKo51lJmCev9crC7XGo=
X-Gm-Gg: ASbGncvAkV0DMaIn4nFJRGNB3fdh3r4Z+OCkR1gRhkXjmNXrdjxGik67QN6yJhnIIeO
	e5ANtpqcloTcrGhUBKJljZSeMjJB2xSxJZoR3WT4j6tf7tAJ2YnzdHceTZd2w5BgLKYsaT8stzR
	pFjJUbFKRQ44OiSW776JoQN5V8ZfoyDUlyjGclcb/p85JjSVXsQFV8ulLEeocKb8AZyek2RKoNz
	JimcU4oHtHNauue7IE18mJAguCcJJfpnGkjXoLjD0E9vfsS2QGU6kSsAffdNnBzyXMEdh4bIzP2
	5CCpO02hrE3bmHQVZpc/tQHQbXrX9sG0lQI8/eIKka6An/+jm/LvQne0y6Fa+RDI6Q==
X-Google-Smtp-Source: AGHT+IGBiB8E0eTSoI28+V9cp1gWnvQIF0NcnM5MrTMqS5rNZ7M1PFDJt5j8Or2lR2bn/A8RFfyqaQ==
X-Received: by 2002:a05:600c:a09:b0:435:9ed3:5688 with SMTP id 5b1f17b1804b1-438913f86dcmr267594425e9.18.1737675857123;
        Thu, 23 Jan 2025 15:44:17 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	qemu-arm@nongnu.org,
	Igor Mammedov <imammedo@redhat.com>,
	=?UTF-8?q?Alex=20Benn=C3=A9e?= <alex.bennee@linaro.org>,
	kvm@vger.kernel.org,
	qemu-ppc@nongnu.org,
	qemu-riscv@nongnu.org,
	David Hildenbrand <david@redhat.com>,
	qemu-s390x@nongnu.org,
	xen-devel@lists.xenproject.org,
	Richard Henderson <richard.henderson@linaro.org>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
Subject: [PATCH 00/20] accel: Simplify cpu-target.c (omnibus)
Date: Fri, 24 Jan 2025 00:43:54 +0100
Message-ID: <20250123234415.59850-1-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Yet another cleanup series before respining the "extract TCG
fields from CPUState" series. Before that, we try to clarify
a bit the code around CPU creation. Target specific code is
reduced further. Some intermixed User/System is separated,
making maintenance simpler IMHO. Since my local branch is
quite big, I tried to group here all the generic patches.

Regards,

Phil.

Based-on: <20250123215609.30432-1-philmd@linaro.org>
  "target/ppc: Move TCG code from excp_helper.c to tcg-excp_helper.c"

Philippe Mathieu-Daudé (20):
  qemu/compiler: Absorb 'clang-tsa.h'
  user: Extract common MMAP API to 'user/mmap.h'
  gdbstub: Check for TCG before calling tb_flush()
  cpus: Cache CPUClass early in instance_init() handler
  cpus: Keep default fields initialization in cpu_common_initfn()
  accel/kvm: Remove unused 'system/cpus.h' header in kvm-cpus.h
  accel/tcg: Build tcg_flags helpers as common code
  accel/tcg: Restrict tlb_init() / destroy() to TCG
  accel/tcg: Restrict 'icount_align_option' global to TCG
  accel/tcg: Rename 'hw/core/tcg-cpu-ops.h' -> 'accel/tcg/cpu-ops.h'
  accel: Rename 'hw/core/accel-cpu.h' -> 'accel/accel-cpu-target.h'
  accel/accel-cpu-target.h: Include missing 'cpu.h' header
  accel: Forward-declare AccelOpsClass in 'qemu/typedefs.h'
  accel/tcg: Move cpu_memory_rw_debug() user implementation to
    user-exec.c
  cpus: Fix style in cpu-target.c
  cpus: Restrict cpu_common_post_load() code to TCG
  cpus: Have cpu_class_init_props() per user / system emulation
  cpus: Have cpu_exec_initfn() per user / system emulation
  cpus: Register VMState per user / system emulation
  cpus: Build cpu_exec_[un]realizefn() methods once

 MAINTAINERS                                   |   4 +-
 accel/kvm/kvm-cpus.h                          |   2 -
 accel/tcg/internal-common.h                   |  13 +
 bsd-user/qemu.h                               |  13 +-
 .../accel-cpu.h => accel/accel-cpu-target.h}  |   7 +-
 .../tcg-cpu-ops.h => accel/tcg/cpu-ops.h}     |   0
 include/block/block_int-common.h              |   1 -
 include/block/graph-lock.h                    |   2 -
 include/exec/exec-all.h                       |  16 -
 include/exec/page-protection.h                |   2 -
 include/hw/core/cpu.h                         |   2 +
 include/qemu/clang-tsa.h                      | 114 -------
 include/qemu/compiler.h                       |  87 +++++
 include/qemu/thread.h                         |   1 -
 include/qemu/typedefs.h                       |   1 +
 include/system/accel-ops.h                    |   1 -
 include/system/cpus.h                         |   4 -
 include/user/mmap.h                           |  32 ++
 linux-user/user-mmap.h                        |  19 +-
 accel/accel-system.c                          |   1 +
 accel/accel-target.c                          |   2 +-
 accel/hvf/hvf-accel-ops.c                     |   1 +
 accel/kvm/kvm-accel-ops.c                     |   1 +
 accel/qtest/qtest.c                           |   1 +
 accel/stubs/tcg-stub.c                        |   4 -
 accel/tcg/cpu-exec-common.c                   |  34 +-
 accel/tcg/cpu-exec.c                          |  37 +--
 accel/tcg/cputlb.c                            |   2 +-
 accel/tcg/icount-common.c                     |   2 +
 accel/tcg/monitor.c                           |   1 -
 accel/tcg/tcg-accel-ops.c                     |   1 +
 accel/tcg/translate-all.c                     |   3 +-
 accel/tcg/user-exec-stub.c                    |  11 +
 accel/tcg/user-exec.c                         |  94 +++++-
 accel/tcg/watchpoint.c                        |   2 +-
 accel/xen/xen-all.c                           |   1 +
 block/create.c                                |   1 -
 bsd-user/signal.c                             |   2 +-
 cpu-common.c                                  |   1 -
 cpu-target.c                                  | 314 +-----------------
 gdbstub/system.c                              |   6 +-
 hw/core/cpu-common.c                          |  31 ++
 hw/core/cpu-system.c                          | 170 ++++++++++
 hw/core/cpu-user.c                            |  44 +++
 hw/mips/jazz.c                                |   2 +-
 linux-user/signal.c                           |   2 +-
 system/cpus.c                                 |   1 +
 system/globals.c                              |   1 -
 system/physmem.c                              |   2 +-
 target/alpha/cpu.c                            |   2 +-
 target/arm/cpu.c                              |   2 +-
 target/arm/tcg/cpu-v7m.c                      |   2 +-
 target/arm/tcg/cpu32.c                        |   2 +-
 target/arm/tcg/mte_helper.c                   |   2 +-
 target/arm/tcg/sve_helper.c                   |   2 +-
 target/avr/cpu.c                              |   2 +-
 target/avr/helper.c                           |   2 +-
 target/hexagon/cpu.c                          |   2 +-
 target/hppa/cpu.c                             |   2 +-
 target/i386/hvf/hvf-cpu.c                     |   2 +-
 target/i386/kvm/kvm-cpu.c                     |   2 +-
 target/i386/nvmm/nvmm-accel-ops.c             |   1 +
 target/i386/tcg/tcg-cpu.c                     |   4 +-
 target/i386/whpx/whpx-accel-ops.c             |   1 +
 target/loongarch/cpu.c                        |   2 +-
 target/m68k/cpu.c                             |   2 +-
 target/microblaze/cpu.c                       |   2 +-
 target/mips/cpu.c                             |   2 +-
 target/openrisc/cpu.c                         |   2 +-
 target/ppc/cpu_init.c                         |   2 +-
 target/ppc/kvm.c                              |   2 +-
 target/riscv/kvm/kvm-cpu.c                    |   2 +-
 target/riscv/tcg/tcg-cpu.c                    |   4 +-
 target/rx/cpu.c                               |   2 +-
 target/s390x/cpu.c                            |   2 +-
 target/s390x/tcg/mem_helper.c                 |   2 +-
 target/sh4/cpu.c                              |   2 +-
 target/sparc/cpu.c                            |   2 +-
 target/tricore/cpu.c                          |   2 +-
 target/xtensa/cpu.c                           |   2 +-
 tests/unit/test-bdrv-drain.c                  |   1 -
 tests/unit/test-block-iothread.c              |   1 -
 util/qemu-thread-posix.c                      |   1 -
 hw/core/meson.build                           |   5 +-
 84 files changed, 590 insertions(+), 578 deletions(-)
 rename include/{hw/core/accel-cpu.h => accel/accel-cpu-target.h} (92%)
 rename include/{hw/core/tcg-cpu-ops.h => accel/tcg/cpu-ops.h} (100%)
 delete mode 100644 include/qemu/clang-tsa.h
 create mode 100644 include/user/mmap.h
 create mode 100644 hw/core/cpu-user.c

-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 23 23:44:31 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 23:44:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876389.1286744 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6s5-0007wh-No; Thu, 23 Jan 2025 23:44:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876389.1286744; Thu, 23 Jan 2025 23:44:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6s5-0007wY-Kk; Thu, 23 Jan 2025 23:44:25 +0000
Received: by outflank-mailman (input) for mailman id 876389;
 Thu, 23 Jan 2025 23:44:24 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=QxCy=UP=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tb6s4-0007w9-KA
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 23:44:24 +0000
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com
 [2a00:1450:4864:20::42c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f8c4c627-d9e3-11ef-a0e5-8be0dac302b0;
 Fri, 24 Jan 2025 00:44:22 +0100 (CET)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3863703258fso1722951f8f.1
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 15:44:22 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38c2a1764c8sm979124f8f.3.2025.01.23.15.44.20
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 23 Jan 2025 15:44:21 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f8c4c627-d9e3-11ef-a0e5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737675862; x=1738280662; 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=7gr0bDqRAyX8smxLdEX+9XpZH40OE0aprdKko/M9qp4=;
        b=mHQFV8Yxc4qnodx15/O9P9U9JbYITuRwuKA9jw+Sq4OcPQCOVNWXoNA4WPz6CdpAMy
         nnr4CqgG8CA0CYw+hMp7wpk9Jco4nY/kKtyhQKqltw3fqBv/B+9KVfQ87spg0i9DD21M
         MsVI90GlKbMcBJdxWhxXDXksi2McmW2xoKtW2q1tH0wj3GvuAjpUNrbezl7cI6P6H3VU
         FLqWzYmNkK+1FxoqFL9KQ4/ENdktoK2GhmFnxceHq6KvydkUE6EL1SVdN3a8TMOp0ega
         afLgX7kLLxtaVOnpdpdSjC/495OXg3cH3l1lSFKL4zsyrFU+JPZQ2pVR834MkH7elHc5
         anzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737675862; x=1738280662;
        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=7gr0bDqRAyX8smxLdEX+9XpZH40OE0aprdKko/M9qp4=;
        b=g6+6tNRx6ziPPrQVGO9sVimMd5OErBiHfwRLiwOD2pX1TYdh3Xe8rk8bc6+Q/QleT/
         S10iDccCBtbOs7fLyCmQt3a99jNlZkfpzpS3p66KrTrRssEjhrHYB57c4YxE2+di+XYJ
         iET+3fXrOeZaR2+Pvcx5lqXevR1ov/e6+fw0sfWPko8B2AbbvFoI2X57BNP15ktyvtyY
         IbCfkA8p1HlQyT6G6qMgQNw5BQH8Qj8PTwTWaQzditCi35y5lFAZWp5WnGKkrvmqc0oy
         bnIzg+X7lTLR4qqD/keC7hqkabg0NnHSDRJSwXwRyOSHkzJEhv5k2fozonS0GSLuRUBg
         o1UA==
X-Forwarded-Encrypted: i=1; AJvYcCWnggkLV6Ooynqe+FfQlbHB+SQrNQCGEt+DFulVgGmnGhap9kvHfmSiHdW09/cQdj8ug5tvDnsvH3w=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyliCGj8xhBuwp0156Zm5e9P5HD7r3GbhR4wwcsY1OkMltl5aaV
	lNaWn2LeIxHbW6NMs4xBdDqJA4LcsM6h3sz7tyU4B3gDPHN+92YleedPT7KdltM=
X-Gm-Gg: ASbGncuxguO2fXbmrF4hCHAOMqZ6ZSVxywOAdrHwN5Evt7HD08PUmuLiEyv8wduxbvq
	F2lr4uIR5oZeHk32m5YQu9TX+vBzJ+Qmu1mJRSBXyPpWwfGZOBRT8i8IiajFCfdWpdm4JRRS83y
	N8/AfHScz28WjXWE0z4Cn4ejJRUYA86KXV2zBLQszzY0j3vnQ26nggSfAHRb0+nKY8JU329YDuX
	lzzSnLpf7rgio/5XD1zy4MWpsSMc0adgTlyUGKCsm757j0NTV/BK3I+eHA7+uNTeAj+nqon80hy
	tdQ9vFstEdfOP1f7YdzFZZwxB74iDpvb8opezJkmC7/BMD420VD1rDw=
X-Google-Smtp-Source: AGHT+IFO1I6JtHdZSiAttwFg1MlQL9TeL6Qp22FcnpRuMJ6TxX0mL0F5rCxwJt2t6SeC+o26N2z+Yw==
X-Received: by 2002:a5d:5885:0:b0:386:3213:5b80 with SMTP id ffacd0b85a97d-38c2b7cdc55mr1203868f8f.24.1737675862142;
        Thu, 23 Jan 2025 15:44:22 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	qemu-arm@nongnu.org,
	Igor Mammedov <imammedo@redhat.com>,
	=?UTF-8?q?Alex=20Benn=C3=A9e?= <alex.bennee@linaro.org>,
	kvm@vger.kernel.org,
	qemu-ppc@nongnu.org,
	qemu-riscv@nongnu.org,
	David Hildenbrand <david@redhat.com>,
	qemu-s390x@nongnu.org,
	xen-devel@lists.xenproject.org,
	Richard Henderson <richard.henderson@linaro.org>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>,
	Pierrick Bouvier <pierrick.bouvier@linaro.org>,
	Kevin Wolf <kwolf@redhat.com>
Subject: [PATCH 01/20] qemu/compiler: Absorb 'clang-tsa.h'
Date: Fri, 24 Jan 2025 00:43:55 +0100
Message-ID: <20250123234415.59850-2-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250123234415.59850-1-philmd@linaro.org>
References: <20250123234415.59850-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

We already have "qemu/compiler.h" for compiler-specific arrangements,
automatically included by "qemu/osdep.h" for each source file. No
need to explicitly include a header for a Clang particularity.

Suggested-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 bsd-user/qemu.h                  |   1 -
 include/block/block_int-common.h |   1 -
 include/block/graph-lock.h       |   2 -
 include/exec/page-protection.h   |   2 -
 include/qemu/clang-tsa.h         | 114 -------------------------------
 include/qemu/compiler.h          |  87 +++++++++++++++++++++++
 include/qemu/thread.h            |   1 -
 block/create.c                   |   1 -
 tests/unit/test-bdrv-drain.c     |   1 -
 tests/unit/test-block-iothread.c |   1 -
 util/qemu-thread-posix.c         |   1 -
 11 files changed, 87 insertions(+), 125 deletions(-)
 delete mode 100644 include/qemu/clang-tsa.h

diff --git a/bsd-user/qemu.h b/bsd-user/qemu.h
index 3eaa14f3f56..4e97c796318 100644
--- a/bsd-user/qemu.h
+++ b/bsd-user/qemu.h
@@ -40,7 +40,6 @@ extern char **environ;
 #include "target.h"
 #include "exec/gdbstub.h"
 #include "exec/page-protection.h"
-#include "qemu/clang-tsa.h"
 #include "accel/tcg/vcpu-state.h"
 
 #include "qemu-os.h"
diff --git a/include/block/block_int-common.h b/include/block/block_int-common.h
index bb91a0f62fa..ebb4e56a503 100644
--- a/include/block/block_int-common.h
+++ b/include/block/block_int-common.h
@@ -28,7 +28,6 @@
 #include "block/block-common.h"
 #include "block/block-global-state.h"
 #include "block/snapshot.h"
-#include "qemu/clang-tsa.h"
 #include "qemu/iov.h"
 #include "qemu/rcu.h"
 #include "qemu/stats64.h"
diff --git a/include/block/graph-lock.h b/include/block/graph-lock.h
index dc8d9491843..2c26c721081 100644
--- a/include/block/graph-lock.h
+++ b/include/block/graph-lock.h
@@ -20,8 +20,6 @@
 #ifndef GRAPH_LOCK_H
 #define GRAPH_LOCK_H
 
-#include "qemu/clang-tsa.h"
-
 /**
  * Graph Lock API
  * This API provides a rwlock used to protect block layer
diff --git a/include/exec/page-protection.h b/include/exec/page-protection.h
index bae3355f62c..3e0a8a03331 100644
--- a/include/exec/page-protection.h
+++ b/include/exec/page-protection.h
@@ -40,8 +40,6 @@
 
 #ifdef CONFIG_USER_ONLY
 
-#include "qemu/clang-tsa.h"
-
 void TSA_NO_TSA mmap_lock(void);
 void TSA_NO_TSA mmap_unlock(void);
 bool have_mmap_lock(void);
diff --git a/include/qemu/clang-tsa.h b/include/qemu/clang-tsa.h
deleted file mode 100644
index ba06fb8c924..00000000000
--- a/include/qemu/clang-tsa.h
+++ /dev/null
@@ -1,114 +0,0 @@
-#ifndef CLANG_TSA_H
-#define CLANG_TSA_H
-
-/*
- * Copyright 2018 Jarkko Hietaniemi <jhi@iki.fi>
- *
- * Permission is hereby granted, free of charge, to any person obtaining
- * a copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without
- * limitation the rights to use, copy, modify, merge, publish,
- * distribute, sublicense, and/or sell copies of the Software, and to
- * permit persons to whom the Software is furnished to do so, subject to
- * the following conditions:
- *
- * The above copyright notice and this permission notice shall be
- * included in all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
- * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
- * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
- * IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
- * CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
- * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
- * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
- */
-
-/* http://clang.llvm.org/docs/ThreadSafetyAnalysis.html
- *
- * TSA is available since clang 3.6-ish.
- */
-#ifdef __clang__
-#  define TSA(x)   __attribute__((x))
-#else
-#  define TSA(x)   /* No TSA, make TSA attributes no-ops. */
-#endif
-
-/* TSA_CAPABILITY() is used to annotate typedefs:
- *
- * typedef pthread_mutex_t TSA_CAPABILITY("mutex") tsa_mutex;
- */
-#define TSA_CAPABILITY(x) TSA(capability(x))
-
-/* TSA_GUARDED_BY() is used to annotate global variables,
- * the data is guarded:
- *
- * Foo foo TSA_GUARDED_BY(mutex);
- */
-#define TSA_GUARDED_BY(x) TSA(guarded_by(x))
-
-/* TSA_PT_GUARDED_BY() is used to annotate global pointers, the data
- * behind the pointer is guarded.
- *
- * Foo* ptr TSA_PT_GUARDED_BY(mutex);
- */
-#define TSA_PT_GUARDED_BY(x) TSA(pt_guarded_by(x))
-
-/* The TSA_REQUIRES() is used to annotate functions: the caller of the
- * function MUST hold the resource, the function will NOT release it.
- *
- * More than one mutex may be specified, comma-separated.
- *
- * void Foo(void) TSA_REQUIRES(mutex);
- */
-#define TSA_REQUIRES(...) TSA(requires_capability(__VA_ARGS__))
-#define TSA_REQUIRES_SHARED(...) TSA(requires_shared_capability(__VA_ARGS__))
-
-/* TSA_EXCLUDES() is used to annotate functions: the caller of the
- * function MUST NOT hold resource, the function first acquires the
- * resource, and then releases it.
- *
- * More than one mutex may be specified, comma-separated.
- *
- * void Foo(void) TSA_EXCLUDES(mutex);
- */
-#define TSA_EXCLUDES(...) TSA(locks_excluded(__VA_ARGS__))
-
-/* TSA_ACQUIRE() is used to annotate functions: the caller of the
- * function MUST NOT hold the resource, the function will acquire the
- * resource, but NOT release it.
- *
- * More than one mutex may be specified, comma-separated.
- *
- * void Foo(void) TSA_ACQUIRE(mutex);
- */
-#define TSA_ACQUIRE(...) TSA(acquire_capability(__VA_ARGS__))
-#define TSA_ACQUIRE_SHARED(...) TSA(acquire_shared_capability(__VA_ARGS__))
-
-/* TSA_RELEASE() is used to annotate functions: the caller of the
- * function MUST hold the resource, but the function will then release it.
- *
- * More than one mutex may be specified, comma-separated.
- *
- * void Foo(void) TSA_RELEASE(mutex);
- */
-#define TSA_RELEASE(...) TSA(release_capability(__VA_ARGS__))
-#define TSA_RELEASE_SHARED(...) TSA(release_shared_capability(__VA_ARGS__))
-
-/* TSA_NO_TSA is used to annotate functions.  Use only when you need to.
- *
- * void Foo(void) TSA_NO_TSA;
- */
-#define TSA_NO_TSA TSA(no_thread_safety_analysis)
-
-/*
- * TSA_ASSERT() is used to annotate functions: This function will assert that
- * the lock is held. When it returns, the caller of the function is assumed to
- * already hold the resource.
- *
- * More than one mutex may be specified, comma-separated.
- */
-#define TSA_ASSERT(...) TSA(assert_capability(__VA_ARGS__))
-#define TSA_ASSERT_SHARED(...) TSA(assert_shared_capability(__VA_ARGS__))
-
-#endif /* #ifndef CLANG_TSA_H */
diff --git a/include/qemu/compiler.h b/include/qemu/compiler.h
index d904408e5ed..af0a9b17ff9 100644
--- a/include/qemu/compiler.h
+++ b/include/qemu/compiler.h
@@ -207,6 +207,93 @@
 # define QEMU_USED
 #endif
 
+/* http://clang.llvm.org/docs/ThreadSafetyAnalysis.html
+ *
+ * TSA is available since clang 3.6-ish.
+ */
+#ifdef __clang__
+#  define TSA(x)   __attribute__((x))
+#else
+#  define TSA(x)   /* No TSA, make TSA attributes no-ops. */
+#endif
+
+/* TSA_CAPABILITY() is used to annotate typedefs:
+ *
+ * typedef pthread_mutex_t TSA_CAPABILITY("mutex") tsa_mutex;
+ */
+#define TSA_CAPABILITY(x) TSA(capability(x))
+
+/* TSA_GUARDED_BY() is used to annotate global variables,
+ * the data is guarded:
+ *
+ * Foo foo TSA_GUARDED_BY(mutex);
+ */
+#define TSA_GUARDED_BY(x) TSA(guarded_by(x))
+
+/* TSA_PT_GUARDED_BY() is used to annotate global pointers, the data
+ * behind the pointer is guarded.
+ *
+ * Foo* ptr TSA_PT_GUARDED_BY(mutex);
+ */
+#define TSA_PT_GUARDED_BY(x) TSA(pt_guarded_by(x))
+
+/* The TSA_REQUIRES() is used to annotate functions: the caller of the
+ * function MUST hold the resource, the function will NOT release it.
+ *
+ * More than one mutex may be specified, comma-separated.
+ *
+ * void Foo(void) TSA_REQUIRES(mutex);
+ */
+#define TSA_REQUIRES(...) TSA(requires_capability(__VA_ARGS__))
+#define TSA_REQUIRES_SHARED(...) TSA(requires_shared_capability(__VA_ARGS__))
+
+/* TSA_EXCLUDES() is used to annotate functions: the caller of the
+ * function MUST NOT hold resource, the function first acquires the
+ * resource, and then releases it.
+ *
+ * More than one mutex may be specified, comma-separated.
+ *
+ * void Foo(void) TSA_EXCLUDES(mutex);
+ */
+#define TSA_EXCLUDES(...) TSA(locks_excluded(__VA_ARGS__))
+
+/* TSA_ACQUIRE() is used to annotate functions: the caller of the
+ * function MUST NOT hold the resource, the function will acquire the
+ * resource, but NOT release it.
+ *
+ * More than one mutex may be specified, comma-separated.
+ *
+ * void Foo(void) TSA_ACQUIRE(mutex);
+ */
+#define TSA_ACQUIRE(...) TSA(acquire_capability(__VA_ARGS__))
+#define TSA_ACQUIRE_SHARED(...) TSA(acquire_shared_capability(__VA_ARGS__))
+
+/* TSA_RELEASE() is used to annotate functions: the caller of the
+ * function MUST hold the resource, but the function will then release it.
+ *
+ * More than one mutex may be specified, comma-separated.
+ *
+ * void Foo(void) TSA_RELEASE(mutex);
+ */
+#define TSA_RELEASE(...) TSA(release_capability(__VA_ARGS__))
+#define TSA_RELEASE_SHARED(...) TSA(release_shared_capability(__VA_ARGS__))
+
+/* TSA_NO_TSA is used to annotate functions.  Use only when you need to.
+ *
+ * void Foo(void) TSA_NO_TSA;
+ */
+#define TSA_NO_TSA TSA(no_thread_safety_analysis)
+
+/*
+ * TSA_ASSERT() is used to annotate functions: This function will assert that
+ * the lock is held. When it returns, the caller of the function is assumed to
+ * already hold the resource.
+ *
+ * More than one mutex may be specified, comma-separated.
+ */
+#define TSA_ASSERT(...) TSA(assert_capability(__VA_ARGS__))
+#define TSA_ASSERT_SHARED(...) TSA(assert_shared_capability(__VA_ARGS__))
+
 /*
  * Ugly CPP trick that is like "defined FOO", but also works in C
  * code.  Useful to replace #ifdef with "if" statements; assumes
diff --git a/include/qemu/thread.h b/include/qemu/thread.h
index 7eba27a7049..6f800aad31a 100644
--- a/include/qemu/thread.h
+++ b/include/qemu/thread.h
@@ -3,7 +3,6 @@
 
 #include "qemu/processor.h"
 #include "qemu/atomic.h"
-#include "qemu/clang-tsa.h"
 
 typedef struct QemuCond QemuCond;
 typedef struct QemuSemaphore QemuSemaphore;
diff --git a/block/create.c b/block/create.c
index 72abafb4c12..6b23a216753 100644
--- a/block/create.c
+++ b/block/create.c
@@ -24,7 +24,6 @@
 
 #include "qemu/osdep.h"
 #include "block/block_int.h"
-#include "qemu/clang-tsa.h"
 #include "qemu/job.h"
 #include "qemu/main-loop.h"
 #include "qapi/qapi-commands-block-core.h"
diff --git a/tests/unit/test-bdrv-drain.c b/tests/unit/test-bdrv-drain.c
index 98ad89b390c..7410e6f3528 100644
--- a/tests/unit/test-bdrv-drain.c
+++ b/tests/unit/test-bdrv-drain.c
@@ -28,7 +28,6 @@
 #include "system/block-backend.h"
 #include "qapi/error.h"
 #include "qemu/main-loop.h"
-#include "qemu/clang-tsa.h"
 #include "iothread.h"
 
 static QemuEvent done_event;
diff --git a/tests/unit/test-block-iothread.c b/tests/unit/test-block-iothread.c
index 1de04a8a13d..26a6c051758 100644
--- a/tests/unit/test-block-iothread.c
+++ b/tests/unit/test-block-iothread.c
@@ -29,7 +29,6 @@
 #include "system/block-backend.h"
 #include "qapi/error.h"
 #include "qapi/qmp/qdict.h"
-#include "qemu/clang-tsa.h"
 #include "qemu/main-loop.h"
 #include "iothread.h"
 
diff --git a/util/qemu-thread-posix.c b/util/qemu-thread-posix.c
index 6fff4162ac6..b2e26e21205 100644
--- a/util/qemu-thread-posix.c
+++ b/util/qemu-thread-posix.c
@@ -17,7 +17,6 @@
 #include "qemu-thread-common.h"
 #include "qemu/tsan.h"
 #include "qemu/bitmap.h"
-#include "qemu/clang-tsa.h"
 
 #ifdef CONFIG_PTHREAD_SET_NAME_NP
 #include <pthread_np.h>
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 23 23:44:37 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 23:44:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876393.1286764 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6sH-000095-8A; Thu, 23 Jan 2025 23:44:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876393.1286764; Thu, 23 Jan 2025 23:44:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6sH-00008v-4E; Thu, 23 Jan 2025 23:44:37 +0000
Received: by outflank-mailman (input) for mailman id 876393;
 Thu, 23 Jan 2025 23:44:35 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=QxCy=UP=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tb6sF-0007hN-GI
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 23:44:35 +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 ff707947-d9e3-11ef-99a4-01e77a169b0f;
 Fri, 24 Jan 2025 00:44:34 +0100 (CET)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3862ca8e0bbso1403875f8f.0
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 15:44:33 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38c2a1c4006sm982952f8f.94.2025.01.23.15.44.30
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 23 Jan 2025 15:44:32 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ff707947-d9e3-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737675873; x=1738280673; 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=ce4xXqVbqUUJ3kwtGZLdz75HP+CS3yxZeowyzQLM8Ns=;
        b=M8MSYh4FA1WGZl6q5/sHZkYMUsiSlL9TI4NfXSXSADnqsjqXJyDzwMZCV8YNc+HXe6
         U+UfbMytymvLkOfask9hVv6sbCCt6DtOQNhFrVesllxTs0wAEDlj0NVo0lTVvQ6XI1VA
         +3KOIk1xq7252WaZvJZDpj7Qr4dWMVeDEnGnWqNUwhN1nsYw2DZO1z/cB5SvRP/0S5Bb
         geWiYAcEuoR++jg6hL8wIT3B8uWX74L8Z41TsOR4Ud2Tl+o3WItgF7sWtHYN/3zLRUVp
         oVUhfUHmLXmVBbxz1pci90Yf15VJhplSMgCFgeJ26LjzlLP5+x+2HOLPw5thKopI9viQ
         M/Ow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737675873; x=1738280673;
        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=ce4xXqVbqUUJ3kwtGZLdz75HP+CS3yxZeowyzQLM8Ns=;
        b=ZccKH5rkaOKFpnABW+QiEUa42BED/tZ8OdNN5bBm8SEfEHxUy2ZvxbXSzJ4s5SW+G3
         AX53+mmpZalUiDi2awPis8YELnhr4vVePJjfSwetJ7HCcWBtQEAfzXSHY+TQHBU6hbq0
         gG5BlWdSEzLNCSxGQoJ8ikaLQuXUNfIehwMK2PoP4+OLNQ7KLdF+5VqVw8LqscOQBM+9
         +BgSGRozhRB3kJ9aEjDiVj0MLopaJufzo4HeUNf/Xp7LdKiDNjCoSvkmkXEXUCBzpxEJ
         C38k6R3K3g3yI6KkAkW1GrpHQSO1eWMWAHYH3MyxKvQD+gnu6NQ2409/LNsWNt8D+qlr
         AHpQ==
X-Forwarded-Encrypted: i=1; AJvYcCVBqGKJd49irVuEE+czPmnZbidXts5wSzp7bdDekE015ciEC6Q1dqR/vyei+OGrXAdxwKh3Hdp8Jzk=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxuur7aGUPwh4EGL1ENFXQqt7fnS55ghshPmnqLcaXiDTlxuwov
	WECuH4zJfJd5OjTJKMglP0SbdDq0r91s3M6waYYfe+F9lTTCqI7X0z9qpIcc6gI=
X-Gm-Gg: ASbGnctac+rmcBQtDUZDA9l3OI3TPZC+wBUcaynefeGr2mFQcErlj6+Wu+hnkSgWmJl
	+xyru4P1kMabHWahoFieHE/gM7eDaP8IupcPlGqG2k/AARjbd7Fz/CmRNm4do51wk/qUWt5PV46
	6l/d8saN5Akrh9NGeTruyTyN7eXXfQy4YGss7RqGe2eJmlU/CbIk3VG5YhOwH9yYDy5sWuMtOaW
	A9P9fG2IreQ1vWiFaBxynbEIn+jj1Uk+YYtxZRL6FQI48xbdJ42JFr77l3oRGkckLs0+U+V90SW
	F3Qwm0Hx5nOqeYjEPuONjyQUdh8L6xCiMI4lzc0n22qn3FNOCNkAUW6RAtliERmesQ==
X-Google-Smtp-Source: AGHT+IF2OW+qflIazHPgiEcST7oe1qZGT6aj/Hik/HFfGWbVcOJj4aFV8515DLdGfzbOF2nObYCMQg==
X-Received: by 2002:a05:6000:144a:b0:38a:9c1b:df5b with SMTP id ffacd0b85a97d-38bf566a279mr25563799f8f.30.1737675873434;
        Thu, 23 Jan 2025 15:44:33 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	qemu-arm@nongnu.org,
	Igor Mammedov <imammedo@redhat.com>,
	=?UTF-8?q?Alex=20Benn=C3=A9e?= <alex.bennee@linaro.org>,
	kvm@vger.kernel.org,
	qemu-ppc@nongnu.org,
	qemu-riscv@nongnu.org,
	David Hildenbrand <david@redhat.com>,
	qemu-s390x@nongnu.org,
	xen-devel@lists.xenproject.org,
	Richard Henderson <richard.henderson@linaro.org>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
Subject: [PATCH 03/20] gdbstub: Check for TCG before calling tb_flush()
Date: Fri, 24 Jan 2025 00:43:57 +0100
Message-ID: <20250123234415.59850-4-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250123234415.59850-1-philmd@linaro.org>
References: <20250123234415.59850-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Use the tcg_enabled() check so the compiler can elide
the call when TCG isn't available, allowing to remove
the tb_flush() stub.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 accel/stubs/tcg-stub.c | 4 ----
 gdbstub/system.c       | 5 ++++-
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/accel/stubs/tcg-stub.c b/accel/stubs/tcg-stub.c
index 7f4208fddf2..b2b9881bdfb 100644
--- a/accel/stubs/tcg-stub.c
+++ b/accel/stubs/tcg-stub.c
@@ -14,10 +14,6 @@
 #include "exec/tb-flush.h"
 #include "exec/exec-all.h"
 
-void tb_flush(CPUState *cpu)
-{
-}
-
 G_NORETURN void cpu_loop_exit(CPUState *cpu)
 {
     g_assert_not_reached();
diff --git a/gdbstub/system.c b/gdbstub/system.c
index 8ce79fa88cf..7f047a285c8 100644
--- a/gdbstub/system.c
+++ b/gdbstub/system.c
@@ -22,6 +22,7 @@
 #include "system/cpus.h"
 #include "system/runstate.h"
 #include "system/replay.h"
+#include "system/tcg.h"
 #include "hw/core/cpu.h"
 #include "hw/cpu/cluster.h"
 #include "hw/boards.h"
@@ -171,7 +172,9 @@ static void gdb_vm_state_change(void *opaque, bool running, RunState state)
         } else {
             trace_gdbstub_hit_break();
         }
-        tb_flush(cpu);
+        if (tcg_enabled()) {
+            tb_flush(cpu);
+        }
         ret = GDB_SIGNAL_TRAP;
         break;
     case RUN_STATE_PAUSED:
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 23 23:44:41 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 23:44:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876396.1286774 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6sL-0000ZO-Mp; Thu, 23 Jan 2025 23:44:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876396.1286774; Thu, 23 Jan 2025 23:44:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6sL-0000ZE-J8; Thu, 23 Jan 2025 23:44:41 +0000
Received: by outflank-mailman (input) for mailman id 876396;
 Thu, 23 Jan 2025 23:44:40 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=QxCy=UP=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tb6sK-0007hN-Db
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 23:44:40 +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 02623f21-d9e4-11ef-99a4-01e77a169b0f;
 Fri, 24 Jan 2025 00:44:38 +0100 (CET)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-4361b6f9faeso10115625e9.1
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 15:44:38 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438bd4857c3sm7081075e9.10.2025.01.23.15.44.37
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 23 Jan 2025 15:44:37 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 02623f21-d9e4-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737675878; x=1738280678; 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=JSvw35u1c/GeD9pKIKqf6WHVcOBbPhJhoq/j5sOwl2I=;
        b=C4soO1wrkXfi/7UdcyGa+U6Vkylnu4OsHLQ4u8nOvV9uztw+hVTOKzy687uN1NrGJ5
         EKvUaRkIcqVi7SfdRC4qTI1x6nXiSShWf4PA9lNHtK1QwpP/cc8B6gsrlrEEilMdI1tE
         3NkADsX3CpMZFMckmOLY0hDrVLG/0+mTT18mBoX4C2dU4RXZAOeL/cKjCphOInh/NoNr
         dT8u7fkdxZ4YdO2wY3+zwhJuzvKW1TdWviDAP7ATcFHI3dUn8pP26WWxZV8FunoMpkWw
         P6jipUeKzzuqBzVEO+pj/TrxG159UDQl/sPqZcGkn6MTJEZRraRj5RSHFBE7izrdr2ZU
         pKkg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737675878; x=1738280678;
        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=JSvw35u1c/GeD9pKIKqf6WHVcOBbPhJhoq/j5sOwl2I=;
        b=B2c8EVA/obNpx71jNTe87E16C49hYp5clOyJXVVoBLPJ3p0dDU1U7CHBNjq8KM9zUT
         TGX36yVgsh3bxYrCkk2sXhSo3KwQGApxawRn25aXAnMuphJ6IHykxJ52Y5eNOo0udXFv
         2hie8M8grRGL0rMZP9wUx9QxEB/K34npa6vBuG2loFNRbG372bkKtLYR7YGcsri7V/FY
         T/LDrmp2trlXL2PLL81r42dMHyEX589WyeDVOS1ModgEJ2VG9ESC/i/oatkERqb1Yc9G
         2LrkUcNyT5mZdk24lJk+0XHxihYCXjgwgg+dP4P4eMGMMqU5l/oBnSC/aMbFGd15bI+t
         s/RQ==
X-Forwarded-Encrypted: i=1; AJvYcCUu6QK7R4Us8jacRb31jBhyyPUo2HvGm2WvHPnDTH/6cuvwFzjbayXtmzQhZtV3j9ePFFMczcvyJ6I=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzR61OcdzLp9vaNjzW9Gyhm07bHdS7KFB10yZId3P1T0xKBtjgb
	luMGstV7g2hRqVrGfeJ7gDmTqoqe7oYZmTmZR7MUK97Ao0Uf8PUk/51eA56/qrs=
X-Gm-Gg: ASbGncsrX5Bjkr2xKD9R2WidAghKgG9tLSQKDxbrKvpvv+lsj7N43FYrVb59cWIRlil
	IyutIzW3JFaItF/KTVDlOgWqNleUtZVGrAFwZPEy4SwheElUTxdSRRHoCPjLyvlMn3cmzVmmWqu
	g8PvznHZh9v2jKoGQEMqimz92bv17uibBm4MGL/8t901Aox96PPjBrOVvhR/vqrY6BRe55vgmJO
	AB+7MNfPXJ8/oJ2Y1eG0maVglRs76tZ98UD/PEaNiiZCFPideidUgIFujrP7CCHc55T4LbSf2ii
	DiICXFiUL1el3FagT4VVKH9AYv7h8VrdagIK+yUJEX5f6pzwXvpp/i82x6GZHCVG5w==
X-Google-Smtp-Source: AGHT+IGo8PNbuw90Bq4/JTfJj+icg7kmRyyI+cmqGdvUrpM4r/a237PZVlDOFDC6zvKvXQiH9M0QlA==
X-Received: by 2002:a05:600c:3d05:b0:434:9e17:190c with SMTP id 5b1f17b1804b1-438b87f953fmr44596875e9.0.1737675878313;
        Thu, 23 Jan 2025 15:44:38 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	qemu-arm@nongnu.org,
	Igor Mammedov <imammedo@redhat.com>,
	=?UTF-8?q?Alex=20Benn=C3=A9e?= <alex.bennee@linaro.org>,
	kvm@vger.kernel.org,
	qemu-ppc@nongnu.org,
	qemu-riscv@nongnu.org,
	David Hildenbrand <david@redhat.com>,
	qemu-s390x@nongnu.org,
	xen-devel@lists.xenproject.org,
	Richard Henderson <richard.henderson@linaro.org>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
Subject: [PATCH 04/20] cpus: Cache CPUClass early in instance_init() handler
Date: Fri, 24 Jan 2025 00:43:58 +0100
Message-ID: <20250123234415.59850-5-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250123234415.59850-1-philmd@linaro.org>
References: <20250123234415.59850-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Cache CPUClass as early as possible, when the instance
is initialized.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
---
 cpu-target.c         | 3 ---
 hw/core/cpu-common.c | 3 +++
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/cpu-target.c b/cpu-target.c
index 667688332c9..89874496a41 100644
--- a/cpu-target.c
+++ b/cpu-target.c
@@ -134,9 +134,6 @@ const VMStateDescription vmstate_cpu_common = {
 
 bool cpu_exec_realizefn(CPUState *cpu, Error **errp)
 {
-    /* cache the cpu class for the hotpath */
-    cpu->cc = CPU_GET_CLASS(cpu);
-
     if (!accel_cpu_common_realize(cpu, errp)) {
         return false;
     }
diff --git a/hw/core/cpu-common.c b/hw/core/cpu-common.c
index cb79566cc51..ff605059c15 100644
--- a/hw/core/cpu-common.c
+++ b/hw/core/cpu-common.c
@@ -238,6 +238,9 @@ static void cpu_common_initfn(Object *obj)
 {
     CPUState *cpu = CPU(obj);
 
+    /* cache the cpu class for the hotpath */
+    cpu->cc = CPU_GET_CLASS(cpu);
+
     gdb_init_cpu(cpu);
     cpu->cpu_index = UNASSIGNED_CPU_INDEX;
     cpu->cluster_index = UNASSIGNED_CLUSTER_INDEX;
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 23 23:44:46 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 23:44:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876402.1286784 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6sP-0000zA-Uq; Thu, 23 Jan 2025 23:44:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876402.1286784; Thu, 23 Jan 2025 23:44:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6sP-0000yz-RW; Thu, 23 Jan 2025 23:44:45 +0000
Received: by outflank-mailman (input) for mailman id 876402;
 Thu, 23 Jan 2025 23:44: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 <SRS0=QxCy=UP=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tb6sP-0007w9-3J
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 23:44:45 +0000
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com
 [2a00:1450:4864:20::429])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 05c54f2a-d9e4-11ef-a0e5-8be0dac302b0;
 Fri, 24 Jan 2025 00:44:44 +0100 (CET)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-3862d16b4f5so936156f8f.0
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 15:44:44 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438bd4d29cesm6991745e9.35.2025.01.23.15.44.42
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 23 Jan 2025 15:44:43 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 05c54f2a-d9e4-11ef-a0e5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737675884; x=1738280684; 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=89WHzW+ji4rB+60gFYzeRD9ADgUNDHjcXvYSPMINgc0=;
        b=LOKpZaohNaPsXqTNFqQma82C7DJalWUqbkHFlFZ8ABdwhIlFNbJK3U7JI7Su+jHxfS
         zjtwuzU+lJ06EXc40EKFIQn3p8J0WCyMsqwcnuI6HqBedFZdLQ5p4e3PwxXhohQ9/SKB
         y0Kb7aZIdxcqNQIF7sB0RrMm96URup/Z3UBabnpUEnrNBbKontJHdX2DzfKKu4mIR/pb
         le1+C6hUtwdk6Gts9okLl9FzNZUHfFD6O8We9X8327gFMRsNJV9jUQYkOIjceD/hqVBE
         /pa4A4MNQ+qqKZfNsTCnv3nFt6ZzFpC/3y4lHfZUgcQ4oUo8OtK4LusAGNg/mUQcLBi0
         AUiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737675884; x=1738280684;
        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=89WHzW+ji4rB+60gFYzeRD9ADgUNDHjcXvYSPMINgc0=;
        b=ld6H4Uba5NrXjyQHH9UcTy8RV/Bappf4KvC3cHdzC+Ar9v44/hdLWXwLXTgDUj0V5j
         EJ57En1F8/YY8+JyRckDp49DfS7gcRL3lVQjeVuqMQ/ck8GgAQ7UzCmUkjSJZbfItDs0
         g6UTpkp2wXCrSMx4b1jLP0w37dW5SmFFmP7RM+kelJrrWzM/H5F18BKirmZFjyXttXWN
         cDWh5wfWwDFktbtFxqAFF8cIhWDmdLCSxij/6IZFXsrz/sMcgtkFYU9znfLWrZZQOYoU
         vwjRth1YmsNwqPhgGyjcT392JUPpZPZEwtLEuv/t+hpIsiKu+jYQh31qqSBlzqdDmE3j
         aObg==
X-Forwarded-Encrypted: i=1; AJvYcCXHIKfOmdBOaVK3kJOiQxlrmt2uo/c2vr+2GMlSifSmy54/EH3XorJ50blZpe+Y6jDtbs0h0EEmC2w=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxgWEYLR7Gh1qnf7wpTOSEC11GbV74pXMAKHTWC8oW16ilO+j1I
	gvKoMUCFdMeUU2/pqyqGEq4wYXzQ5hx002e1LH9MdWWHFa8qHSL35LBlevFkyPU=
X-Gm-Gg: ASbGnctosNAIDijgdrxe3qETQfEyBS78tcdA3c7Fz92+1KoFitFMWUuR3wH7Hnb4bEc
	Xh9YN1t7Lqu5QPEFhigWTfBvflUDKk1LgLtX9Z5GvNDjoefNsOXk/Z2PvIAGC7QE1y/MqGpGbBC
	dXBeMjfuER72qwudn48zXsay0pUr5i2KGWvkMCA8PX1E7GzRN1cD99KiLL0uqvF2c7qqMri3+Vn
	u2m2G/ehthPrix+8Q0uBBRpn8FliNZRrZ1E/PnUXmSjp/Nj9+rIcTZF13pv4s4d+vue9ZE/IYpQ
	vrCpGlDtfneyY5Vtam6GdF2V4Bgbezv4xS4AgCZ7gbsg2cRyqvkMSFE=
X-Google-Smtp-Source: AGHT+IHfcp2D5aSm8Sn0VT4IidLdBYhD/KSzWcZHka724j1qpNfMP/dVIsxPCprx8nPoBb5TgAtEpw==
X-Received: by 2002:a05:6000:1fa9:b0:38b:f4dc:44ad with SMTP id ffacd0b85a97d-38c2b65ebf8mr997845f8f.5.1737675884076;
        Thu, 23 Jan 2025 15:44:44 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	qemu-arm@nongnu.org,
	Igor Mammedov <imammedo@redhat.com>,
	=?UTF-8?q?Alex=20Benn=C3=A9e?= <alex.bennee@linaro.org>,
	kvm@vger.kernel.org,
	qemu-ppc@nongnu.org,
	qemu-riscv@nongnu.org,
	David Hildenbrand <david@redhat.com>,
	qemu-s390x@nongnu.org,
	xen-devel@lists.xenproject.org,
	Richard Henderson <richard.henderson@linaro.org>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
Subject: [PATCH 05/20] cpus: Keep default fields initialization in cpu_common_initfn()
Date: Fri, 24 Jan 2025 00:43:59 +0100
Message-ID: <20250123234415.59850-6-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250123234415.59850-1-philmd@linaro.org>
References: <20250123234415.59850-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

cpu_common_initfn() is our target agnostic initializer,
while cpu_exec_initfn() is the target specific one.

The %as and %num_ases fields are not target specific,
so initialize them in the common helper.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 cpu-target.c         | 3 ---
 hw/core/cpu-common.c | 2 ++
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/cpu-target.c b/cpu-target.c
index 89874496a41..75501a909df 100644
--- a/cpu-target.c
+++ b/cpu-target.c
@@ -234,9 +234,6 @@ void cpu_class_init_props(DeviceClass *dc)
 
 void cpu_exec_initfn(CPUState *cpu)
 {
-    cpu->as = NULL;
-    cpu->num_ases = 0;
-
 #ifndef CONFIG_USER_ONLY
     cpu->memory = get_system_memory();
     object_ref(OBJECT(cpu->memory));
diff --git a/hw/core/cpu-common.c b/hw/core/cpu-common.c
index ff605059c15..71425cb7422 100644
--- a/hw/core/cpu-common.c
+++ b/hw/core/cpu-common.c
@@ -244,6 +244,8 @@ static void cpu_common_initfn(Object *obj)
     gdb_init_cpu(cpu);
     cpu->cpu_index = UNASSIGNED_CPU_INDEX;
     cpu->cluster_index = UNASSIGNED_CLUSTER_INDEX;
+    cpu->as = NULL;
+    cpu->num_ases = 0;
     /* user-mode doesn't have configurable SMP topology */
     /* the default value is changed by qemu_init_vcpu() for system-mode */
     cpu->nr_threads = 1;
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 23 23:44:58 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 23:44:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876420.1286794 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6sc-0001o7-5K; Thu, 23 Jan 2025 23:44:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876420.1286794; Thu, 23 Jan 2025 23:44:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6sc-0001o0-2T; Thu, 23 Jan 2025 23:44:58 +0000
Received: by outflank-mailman (input) for mailman id 876420;
 Thu, 23 Jan 2025 23:44:57 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=QxCy=UP=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tb6sb-0007w9-4x
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 23:44:57 +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 0caeff66-d9e4-11ef-a0e5-8be0dac302b0;
 Fri, 24 Jan 2025 00:44:56 +0100 (CET)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-436a39e4891so10246835e9.1
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 15:44:56 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438bd48a94asm7141855e9.23.2025.01.23.15.44.53
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 23 Jan 2025 15:44:54 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 0caeff66-d9e4-11ef-a0e5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737675895; x=1738280695; 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=zgM0qO1a7TmnAaVr92PdlZQNV8dbDE9Lo8CXyhKvg/4=;
        b=Xq1EpJl+70Py/LtP6EAYoCC+9/lLsp8P1gYlPa+EqzwE5fizFA+Y7N+mEBQCtWYPkr
         gqwqJzAIhswNWNHyN51hTKCDgeZcGxQeMz47g2r/A8Ba4yu0FQNZ4d0eadTJd4F4COih
         JhZyMc9e2IYghSbBBJ5QEYhwdRszjHJkGMZgeycX37kWO35e5a1yLqhgBcZs642vl6wv
         sf8NXp1sFZ4Kn8jWilco3bJIgx/dOjvHs3euwrjfHW8JWbkpjcRIOIimaTbRkZJzAicW
         mTh9/abAYst/DDNgLKE7IpGyQOjXTi52w6QdKHnSfkilNPLVAoiiP1KpXiGqZRCqVdPv
         X9RQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737675895; x=1738280695;
        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=zgM0qO1a7TmnAaVr92PdlZQNV8dbDE9Lo8CXyhKvg/4=;
        b=KqTc5zy7BIGyUv59r5i/im8LLnW8ojcDwfcfRQ17mdf2vV7UQt/E7VSQBv0nghwzwp
         POKAVtO0WGBEnTFyvULhjAnp3L2VWycp+OgZJxhgX3AcooGghHHLVo4kL16+SNcaWpFZ
         xuTpeyGL1rXE1WtxKI1z0jc9xGbn31Q+haL6R9MtuxsKNSya3z6+Ue8ar9UKf6jdjQtu
         Fs213pyLgd+O/ofVCCVcRPEVO7wIAsIOQPxkpw/3CMa5X0216eh5DCWQBp5xUqDNvReC
         2JFvUbBK4G+5EPYCr47g45thLSBGn/TKUZsuhOBQML8/GWF23ZkbMUg+Qbr9k6TWLQbn
         flvA==
X-Forwarded-Encrypted: i=1; AJvYcCVjiJOkiUaCBQy4w1Mxtlufd3+niJ9tB+uvzuHVOYkdsTaLCT/QV5GFO5oZRp8u6FgPPdcSeuKuk5U=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywvu/CYQ34CbL1UzMv2jqXp3Qq8CzdR0V2++a17wh082aPaRMdg
	sliT35SaTJ9lJ0QT3OE5CJBBf8/n5ow7gy/xNZV/kBvEDWptX2IL7N7T0Y0+ljY=
X-Gm-Gg: ASbGncsPnywYvobWU04a0y7jPZzyoeuQZq6nrmtAGxVgcCPNQndvxUifUBqI8gvErjF
	xUMAAoYPn1gLgVZ5Ud5gidY4WTBPuuF4IB0MLW2RuAkMSnjwIn7dFGi00dP4I0gUIs4h19c6G3X
	5Tbaxa9KMEmbVpc6Rl57f7etXc3Tclc1u1huZN09fvDX1SawlAewDkfhF5cfT7Bz/Obx8EZGzDR
	Cg4YHVGTZDj8oC4J8dIG/9cDaBDFAXItA7E/SDj450GHTmFDZa+qZGvlqvsGXUDrUVXtjk3WnhI
	vi+MrBYZSr7toiKniFjNvh5laNQ01XjSQ552vbM7o3Iv4KnFmpqeFaY=
X-Google-Smtp-Source: AGHT+IFu3bGh+dR4gXvA0Xd23GoBCnM+yfw+G3EPNj4Vc2jg+fj1VnlHOFgKCDXygKj5XAozIyeBjA==
X-Received: by 2002:a05:600c:a09:b0:435:9ed3:5688 with SMTP id 5b1f17b1804b1-438913f86dcmr267603485e9.18.1737675895459;
        Thu, 23 Jan 2025 15:44:55 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	qemu-arm@nongnu.org,
	Igor Mammedov <imammedo@redhat.com>,
	=?UTF-8?q?Alex=20Benn=C3=A9e?= <alex.bennee@linaro.org>,
	kvm@vger.kernel.org,
	qemu-ppc@nongnu.org,
	qemu-riscv@nongnu.org,
	David Hildenbrand <david@redhat.com>,
	qemu-s390x@nongnu.org,
	xen-devel@lists.xenproject.org,
	Richard Henderson <richard.henderson@linaro.org>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
Subject: [PATCH 07/20] accel/tcg: Build tcg_flags helpers as common code
Date: Fri, 24 Jan 2025 00:44:01 +0100
Message-ID: <20250123234415.59850-8-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250123234415.59850-1-philmd@linaro.org>
References: <20250123234415.59850-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

While cpu-exec.c is build for each target,tcg_flags helpers
aren't target specific. Move them to cpu-exec-common.c to
build them once.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 accel/tcg/cpu-exec-common.c | 33 +++++++++++++++++++++++++++++++++
 accel/tcg/cpu-exec.c        | 32 --------------------------------
 2 files changed, 33 insertions(+), 32 deletions(-)

diff --git a/accel/tcg/cpu-exec-common.c b/accel/tcg/cpu-exec-common.c
index 6ecfc4e7c21..100746d555a 100644
--- a/accel/tcg/cpu-exec-common.c
+++ b/accel/tcg/cpu-exec-common.c
@@ -18,6 +18,7 @@
  */
 
 #include "qemu/osdep.h"
+#include "exec/log.h"
 #include "system/cpus.h"
 #include "system/tcg.h"
 #include "qemu/plugin.h"
@@ -25,6 +26,38 @@
 
 bool tcg_allowed;
 
+bool tcg_cflags_has(CPUState *cpu, uint32_t flags)
+{
+    return cpu->tcg_cflags & flags;
+}
+
+void tcg_cflags_set(CPUState *cpu, uint32_t flags)
+{
+    cpu->tcg_cflags |= flags;
+}
+
+uint32_t curr_cflags(CPUState *cpu)
+{
+    uint32_t cflags = cpu->tcg_cflags;
+
+    /*
+     * Record gdb single-step.  We should be exiting the TB by raising
+     * EXCP_DEBUG, but to simplify other tests, disable chaining too.
+     *
+     * For singlestep and -d nochain, suppress goto_tb so that
+     * we can log -d cpu,exec after every TB.
+     */
+    if (unlikely(cpu->singlestep_enabled)) {
+        cflags |= CF_NO_GOTO_TB | CF_NO_GOTO_PTR | CF_SINGLE_STEP | 1;
+    } else if (qatomic_read(&one_insn_per_tb)) {
+        cflags |= CF_NO_GOTO_TB | 1;
+    } else if (qemu_loglevel_mask(CPU_LOG_TB_NOCHAIN)) {
+        cflags |= CF_NO_GOTO_TB;
+    }
+
+    return cflags;
+}
+
 /* exit the current TB, but without causing any exception to be raised */
 void cpu_loop_exit_noexc(CPUState *cpu)
 {
diff --git a/accel/tcg/cpu-exec.c b/accel/tcg/cpu-exec.c
index 8b773d88478..be2ba199d3d 100644
--- a/accel/tcg/cpu-exec.c
+++ b/accel/tcg/cpu-exec.c
@@ -148,38 +148,6 @@ static void init_delay_params(SyncClocks *sc, const CPUState *cpu)
 }
 #endif /* CONFIG USER ONLY */
 
-bool tcg_cflags_has(CPUState *cpu, uint32_t flags)
-{
-    return cpu->tcg_cflags & flags;
-}
-
-void tcg_cflags_set(CPUState *cpu, uint32_t flags)
-{
-    cpu->tcg_cflags |= flags;
-}
-
-uint32_t curr_cflags(CPUState *cpu)
-{
-    uint32_t cflags = cpu->tcg_cflags;
-
-    /*
-     * Record gdb single-step.  We should be exiting the TB by raising
-     * EXCP_DEBUG, but to simplify other tests, disable chaining too.
-     *
-     * For singlestep and -d nochain, suppress goto_tb so that
-     * we can log -d cpu,exec after every TB.
-     */
-    if (unlikely(cpu->singlestep_enabled)) {
-        cflags |= CF_NO_GOTO_TB | CF_NO_GOTO_PTR | CF_SINGLE_STEP | 1;
-    } else if (qatomic_read(&one_insn_per_tb)) {
-        cflags |= CF_NO_GOTO_TB | 1;
-    } else if (qemu_loglevel_mask(CPU_LOG_TB_NOCHAIN)) {
-        cflags |= CF_NO_GOTO_TB;
-    }
-
-    return cflags;
-}
-
 struct tb_desc {
     vaddr pc;
     uint64_t cs_base;
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 23 23:50:36 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 23:50:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876444.1286813 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6y1-0004Hf-Tz; Thu, 23 Jan 2025 23:50:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876444.1286813; Thu, 23 Jan 2025 23:50:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6y1-0004HY-R4; Thu, 23 Jan 2025 23:50:33 +0000
Received: by outflank-mailman (input) for mailman id 876444;
 Thu, 23 Jan 2025 23:50:31 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=QxCy=UP=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tb6t9-0007w9-SV
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 23:45:31 +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 2147c1e8-d9e4-11ef-a0e5-8be0dac302b0;
 Fri, 24 Jan 2025 00:45:31 +0100 (CET)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-4364a37a1d7so15354855e9.3
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 15:45:31 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438bd4b9990sm7076685e9.29.2025.01.23.15.45.28
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 23 Jan 2025 15:45:28 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2147c1e8-d9e4-11ef-a0e5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737675930; x=1738280730; 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=zGO8rj66FytAuOx0HD2g/yFD3gx++HeKfsSZtvEWB0o=;
        b=E8nClg6RFIrCM/4UBFtQR5OShb40JB1lEvZEyq1u9Q53kC/olFFjMMy2v38TRtZP8i
         JbHeBiBkgCDtJkEFfrwJqG/rI1umkkMfb3JujSRueasQsTyaTmlmwORDSsZfOgOhxiPD
         9in0mir1BgYQqCiYnOmqLIWWepYfxLg4KihajUS/pPsR1v2lrnKTI1RS+JYDDTA1Qydc
         Gm0hqiecMEnshkXF9NZYoPtw/2o2BlJiF6k/guhu9nFzmLrHJLeP1ehNS2h9vipjnRcF
         VeYjkcG/iK5ZtRYCSjxWr1fNHny1kHm1ylYvaqu6U81srVGZ3j9XC/GKKPB9Pkg3ENaH
         qA1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737675930; x=1738280730;
        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=zGO8rj66FytAuOx0HD2g/yFD3gx++HeKfsSZtvEWB0o=;
        b=VGNf/6ZOiwFjic1UfT1hux/mJu1ykKDfDey2bwlst1sHHfXkj+Ju78qqcMo3/i9O6o
         EYz4ZcGJyuSxdeLO1VgTdcuau3iBrW2MKlRXn0h9ykaXfQcjxW/TO+1H/kO37RMTBgYv
         /cgJa7/sn10j6h5ZJiDgDaJvZC9UYdDtUvzOi2+9Pyimm9cx8OxDHYnBpvIT7sKlHU55
         4nvZdXa15D5ynnHRwF6s6Wf3zmBBzQV2hc1iEWrbhFJVEC0ozK8o/+d2EKIxuDY4LZio
         PmPyPk7+cwGCftFAnUndgSkb7gco+J9Lks9/5KlotMDs/+xqNFQ8hhhTMOd3zPh26bNg
         jfRg==
X-Forwarded-Encrypted: i=1; AJvYcCVDycpKS38bx0pVEQXxfgl9uIqhqc5c0ZsatB3NPDnNlz3UgG/UyScVmaND7OAQ85rVXw87WlMBwFY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwKxvyZ37RqB6h5xlzUM2FeWqEiRo93RkhWiPg57ga0DForwmwe
	gOePG0y1q6J1uujvF2ssPzkzO3ERGsYqiL2fCqt7oKVyRS1w1GLFKKvpSeVFVes=
X-Gm-Gg: ASbGncubU0OiQH7xt3EdvS2habtKs84ZtAilLA/TIUuRx4AwM9CF0uHHtO69izFW0Xs
	N84PpBrXrWTXOkGnzn9Q54x7Z3c3MGyq8qs3ONyw4e6OS3VDywslk+3Qlsa69MP47QPUmwLw9Vl
	AhIPzfxTjFDUQUVvTpPb88vKra0P5uXB15GGXB6nLSymrGhCDB+z9HyuLfJmknV8YwjqxuW8fIk
	LpgKOD3Gzz1kZXKOzCvvZ/l9YfPqTaMx8zFWc4QdZ7vvbIlypYFapm2oValPND5Muh3txilnC7c
	uoPUgT9tIGz55XvjtcR2loyitoG/Yi32HRLlRc7Fgwc1Gu/c5HwEM84=
X-Google-Smtp-Source: AGHT+IGTWWuqfdRG1OdMv1JrJhUNbIyiZqrhlB9MFbw+o6IkF6P0PGvSwNrik0HZ18U5C5r24zY0/A==
X-Received: by 2002:a05:600c:1e0e:b0:438:a20b:6a2a with SMTP id 5b1f17b1804b1-438a20b6b71mr242006995e9.14.1737675930187;
        Thu, 23 Jan 2025 15:45:30 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	qemu-arm@nongnu.org,
	Igor Mammedov <imammedo@redhat.com>,
	=?UTF-8?q?Alex=20Benn=C3=A9e?= <alex.bennee@linaro.org>,
	kvm@vger.kernel.org,
	qemu-ppc@nongnu.org,
	qemu-riscv@nongnu.org,
	David Hildenbrand <david@redhat.com>,
	qemu-s390x@nongnu.org,
	xen-devel@lists.xenproject.org,
	Richard Henderson <richard.henderson@linaro.org>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
Subject: [PATCH 13/20] accel: Forward-declare AccelOpsClass in 'qemu/typedefs.h'
Date: Fri, 24 Jan 2025 00:44:07 +0100
Message-ID: <20250123234415.59850-14-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250123234415.59850-1-philmd@linaro.org>
References: <20250123234415.59850-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The heavily imported "system/cpus.h" header includes "accel-ops.h"
to get AccelOpsClass type declaration. Reduce headers pressure by
forward declaring it in "qemu/typedefs.h", where we already
declare the AccelCPUState type.

Reduce "system/cpus.h" inclusions by only including
"system/accel-ops.h" when necessary.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 include/qemu/typedefs.h           | 1 +
 include/system/accel-ops.h        | 1 -
 include/system/cpus.h             | 2 --
 accel/accel-system.c              | 1 +
 accel/hvf/hvf-accel-ops.c         | 1 +
 accel/kvm/kvm-accel-ops.c         | 1 +
 accel/qtest/qtest.c               | 1 +
 accel/tcg/cpu-exec-common.c       | 1 -
 accel/tcg/cpu-exec.c              | 1 -
 accel/tcg/monitor.c               | 1 -
 accel/tcg/tcg-accel-ops.c         | 1 +
 accel/tcg/translate-all.c         | 1 -
 accel/xen/xen-all.c               | 1 +
 cpu-common.c                      | 1 -
 cpu-target.c                      | 1 +
 gdbstub/system.c                  | 1 +
 system/cpus.c                     | 1 +
 target/i386/nvmm/nvmm-accel-ops.c | 1 +
 target/i386/whpx/whpx-accel-ops.c | 1 +
 19 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/include/qemu/typedefs.h b/include/qemu/typedefs.h
index 3d84efcac47..465cc501773 100644
--- a/include/qemu/typedefs.h
+++ b/include/qemu/typedefs.h
@@ -22,6 +22,7 @@
  * Please keep this list in case-insensitive alphabetical order.
  */
 typedef struct AccelCPUState AccelCPUState;
+typedef struct AccelOpsClass AccelOpsClass;
 typedef struct AccelState AccelState;
 typedef struct AddressSpace AddressSpace;
 typedef struct AioContext AioContext;
diff --git a/include/system/accel-ops.h b/include/system/accel-ops.h
index 137fb96d444..4c99d25aeff 100644
--- a/include/system/accel-ops.h
+++ b/include/system/accel-ops.h
@@ -17,7 +17,6 @@
 #define TYPE_ACCEL_OPS "accel" ACCEL_OPS_SUFFIX
 #define ACCEL_OPS_NAME(name) (name "-" TYPE_ACCEL_OPS)
 
-typedef struct AccelOpsClass AccelOpsClass;
 DECLARE_CLASS_CHECKERS(AccelOpsClass, ACCEL_OPS, TYPE_ACCEL_OPS)
 
 /**
diff --git a/include/system/cpus.h b/include/system/cpus.h
index 1cffeaaf5c4..3226c765d01 100644
--- a/include/system/cpus.h
+++ b/include/system/cpus.h
@@ -1,8 +1,6 @@
 #ifndef QEMU_CPUS_H
 #define QEMU_CPUS_H
 
-#include "system/accel-ops.h"
-
 /* register accel-specific operations */
 void cpus_register_accel(const AccelOpsClass *i);
 
diff --git a/accel/accel-system.c b/accel/accel-system.c
index a7596aef59d..5df49fbe831 100644
--- a/accel/accel-system.c
+++ b/accel/accel-system.c
@@ -26,6 +26,7 @@
 #include "qemu/osdep.h"
 #include "qemu/accel.h"
 #include "hw/boards.h"
+#include "system/accel-ops.h"
 #include "system/cpus.h"
 #include "qemu/error-report.h"
 #include "accel-system.h"
diff --git a/accel/hvf/hvf-accel-ops.c b/accel/hvf/hvf-accel-ops.c
index 945ba720513..12fc30c2761 100644
--- a/accel/hvf/hvf-accel-ops.c
+++ b/accel/hvf/hvf-accel-ops.c
@@ -54,6 +54,7 @@
 #include "exec/exec-all.h"
 #include "gdbstub/enums.h"
 #include "hw/boards.h"
+#include "system/accel-ops.h"
 #include "system/cpus.h"
 #include "system/hvf.h"
 #include "system/hvf_int.h"
diff --git a/accel/kvm/kvm-accel-ops.c b/accel/kvm/kvm-accel-ops.c
index a81e8f3b03b..54ea60909e2 100644
--- a/accel/kvm/kvm-accel-ops.c
+++ b/accel/kvm/kvm-accel-ops.c
@@ -16,6 +16,7 @@
 #include "qemu/osdep.h"
 #include "qemu/error-report.h"
 #include "qemu/main-loop.h"
+#include "system/accel-ops.h"
 #include "system/kvm.h"
 #include "system/kvm_int.h"
 #include "system/runstate.h"
diff --git a/accel/qtest/qtest.c b/accel/qtest/qtest.c
index ad7e3441a5a..7fae80f6a1b 100644
--- a/accel/qtest/qtest.c
+++ b/accel/qtest/qtest.c
@@ -18,6 +18,7 @@
 #include "qemu/option.h"
 #include "qemu/config-file.h"
 #include "qemu/accel.h"
+#include "system/accel-ops.h"
 #include "system/qtest.h"
 #include "system/cpus.h"
 #include "qemu/guest-random.h"
diff --git a/accel/tcg/cpu-exec-common.c b/accel/tcg/cpu-exec-common.c
index 100746d555a..c5c513f1e4a 100644
--- a/accel/tcg/cpu-exec-common.c
+++ b/accel/tcg/cpu-exec-common.c
@@ -19,7 +19,6 @@
 
 #include "qemu/osdep.h"
 #include "exec/log.h"
-#include "system/cpus.h"
 #include "system/tcg.h"
 #include "qemu/plugin.h"
 #include "internal-common.h"
diff --git a/accel/tcg/cpu-exec.c b/accel/tcg/cpu-exec.c
index 8ee76e14b0d..4070d532bf1 100644
--- a/accel/tcg/cpu-exec.c
+++ b/accel/tcg/cpu-exec.c
@@ -33,7 +33,6 @@
 #include "qemu/rcu.h"
 #include "exec/log.h"
 #include "qemu/main-loop.h"
-#include "system/cpus.h"
 #include "exec/cpu-all.h"
 #include "system/cpu-timers.h"
 #include "exec/replay-core.h"
diff --git a/accel/tcg/monitor.c b/accel/tcg/monitor.c
index ae1dbeb79f8..eeb38a4d9ce 100644
--- a/accel/tcg/monitor.c
+++ b/accel/tcg/monitor.c
@@ -13,7 +13,6 @@
 #include "qapi/type-helpers.h"
 #include "qapi/qapi-commands-machine.h"
 #include "monitor/monitor.h"
-#include "system/cpus.h"
 #include "system/cpu-timers.h"
 #include "system/tcg.h"
 #include "tcg/tcg.h"
diff --git a/accel/tcg/tcg-accel-ops.c b/accel/tcg/tcg-accel-ops.c
index 6e3f1fa92b2..132c5d14613 100644
--- a/accel/tcg/tcg-accel-ops.c
+++ b/accel/tcg/tcg-accel-ops.c
@@ -26,6 +26,7 @@
  */
 
 #include "qemu/osdep.h"
+#include "system/accel-ops.h"
 #include "system/tcg.h"
 #include "system/replay.h"
 #include "system/cpu-timers.h"
diff --git a/accel/tcg/translate-all.c b/accel/tcg/translate-all.c
index 786e2f6f1a7..0914d6e98b2 100644
--- a/accel/tcg/translate-all.c
+++ b/accel/tcg/translate-all.c
@@ -54,7 +54,6 @@
 #include "qemu/cacheinfo.h"
 #include "qemu/timer.h"
 #include "exec/log.h"
-#include "system/cpus.h"
 #include "system/cpu-timers.h"
 #include "system/tcg.h"
 #include "qapi/error.h"
diff --git a/accel/xen/xen-all.c b/accel/xen/xen-all.c
index 852e9fbe5fe..7aa28b9ab93 100644
--- a/accel/xen/xen-all.c
+++ b/accel/xen/xen-all.c
@@ -18,6 +18,7 @@
 #include "hw/xen/xen_igd.h"
 #include "chardev/char.h"
 #include "qemu/accel.h"
+#include "system/accel-ops.h"
 #include "system/cpus.h"
 #include "system/xen.h"
 #include "system/runstate.h"
diff --git a/cpu-common.c b/cpu-common.c
index 4248b2d727e..f5dcc2d136b 100644
--- a/cpu-common.c
+++ b/cpu-common.c
@@ -21,7 +21,6 @@
 #include "qemu/main-loop.h"
 #include "exec/cpu-common.h"
 #include "hw/core/cpu.h"
-#include "system/cpus.h"
 #include "qemu/lockable.h"
 #include "trace/trace-root.h"
 
diff --git a/cpu-target.c b/cpu-target.c
index f97f3a14751..20933bde7d4 100644
--- a/cpu-target.c
+++ b/cpu-target.c
@@ -35,6 +35,7 @@
 #include "exec/address-spaces.h"
 #include "exec/memory.h"
 #endif
+#include "system/accel-ops.h"
 #include "system/cpus.h"
 #include "system/tcg.h"
 #include "exec/tswap.h"
diff --git a/gdbstub/system.c b/gdbstub/system.c
index 7f047a285c8..416c1dbe1e9 100644
--- a/gdbstub/system.c
+++ b/gdbstub/system.c
@@ -19,6 +19,7 @@
 #include "gdbstub/commands.h"
 #include "exec/hwaddr.h"
 #include "exec/tb-flush.h"
+#include "system/accel-ops.h"
 #include "system/cpus.h"
 #include "system/runstate.h"
 #include "system/replay.h"
diff --git a/system/cpus.c b/system/cpus.c
index 37e5892c240..2cc5f887ab5 100644
--- a/system/cpus.c
+++ b/system/cpus.c
@@ -31,6 +31,7 @@
 #include "qapi/qapi-events-run-state.h"
 #include "qapi/qmp/qerror.h"
 #include "exec/gdbstub.h"
+#include "system/accel-ops.h"
 #include "system/hw_accel.h"
 #include "exec/cpu-common.h"
 #include "qemu/thread.h"
diff --git a/target/i386/nvmm/nvmm-accel-ops.c b/target/i386/nvmm/nvmm-accel-ops.c
index e7b56662fee..4e4e63de78e 100644
--- a/target/i386/nvmm/nvmm-accel-ops.c
+++ b/target/i386/nvmm/nvmm-accel-ops.c
@@ -10,6 +10,7 @@
 #include "qemu/osdep.h"
 #include "system/kvm_int.h"
 #include "qemu/main-loop.h"
+#include "system/accel-ops.h"
 #include "system/cpus.h"
 #include "qemu/guest-random.h"
 
diff --git a/target/i386/whpx/whpx-accel-ops.c b/target/i386/whpx/whpx-accel-ops.c
index ab2e014c9ea..81fdd06e487 100644
--- a/target/i386/whpx/whpx-accel-ops.c
+++ b/target/i386/whpx/whpx-accel-ops.c
@@ -11,6 +11,7 @@
 #include "qemu/osdep.h"
 #include "system/kvm_int.h"
 #include "qemu/main-loop.h"
+#include "system/accel-ops.h"
 #include "system/cpus.h"
 #include "qemu/guest-random.h"
 
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 23 23:50:36 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 23:50:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876443.1286803 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6y0-00043d-NG; Thu, 23 Jan 2025 23:50:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876443.1286803; Thu, 23 Jan 2025 23:50:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6y0-00043W-KU; Thu, 23 Jan 2025 23:50:32 +0000
Received: by outflank-mailman (input) for mailman id 876443;
 Thu, 23 Jan 2025 23:50: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 <SRS0=QxCy=UP=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tb6sm-0007w9-PO
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 23:45:08 +0000
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com
 [2a00:1450:4864:20::32f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 13e68f85-d9e4-11ef-a0e5-8be0dac302b0;
 Fri, 24 Jan 2025 00:45:08 +0100 (CET)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-4361f65ca01so15618625e9.1
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 15:45:08 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38c2a17630asm997952f8f.6.2025.01.23.15.45.05
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 23 Jan 2025 15:45:06 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 13e68f85-d9e4-11ef-a0e5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737675908; x=1738280708; 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=yDFP15LbfYjBwdgoNtB1SUTPS+QYiGObjjbLDQKpiPc=;
        b=H01CtwRfWhB4wEasZAKV33jROT9Fur5PGDogNm5FKaZUlxVtxyTBheK5boQJgALWeD
         bmf3oQLWsKNHi/fzhZJuDOl4Krj6oGnnAjHLFfe9czfWFAbsiHp6rUkLcJX0Ldn/77gV
         t2Tlu79cFh2folA6WmMu2jBFqkqqmUZ44eOPUVSmsAdvcNZIe+9GDpOIIffsf9NhqP08
         2/rU54fzDIgCAbZlbjs0c6X4P7KALQ2yslDE6UghNKETDINTKFcX53hqnEix9acRmzkn
         yS/Oa7Y8GydKO3HAfgPcnwr28iNytcoiYLQKboSIKvrk4n/naw1unFvU6HFuBW1kdPAr
         DkBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737675908; x=1738280708;
        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=yDFP15LbfYjBwdgoNtB1SUTPS+QYiGObjjbLDQKpiPc=;
        b=YPYqPR8kGqA8AUCxIqO77Uq3T5EVkvgi3yFpTF2yr+tJuYiM1WehmDg+un690Dodn4
         IuwQqOT5u6RjGX+zsbHkfQz961JV/0lCFIWAV0Y/gddhKzAATai7hHcjgzpMEU8Pdi2l
         +O/DOpWVBg/NB2TrTpHUkX+YAFViGMTSaQ8bA0bq3kXLGTeHDXQ3iLUtU5+17ik29wRj
         EjCVQ7rKu3ElPpvtnRa1Y7zCTma0qGnNazBr4OeSuKLl/UFr0Q+ufYzSaEoggn6MVUfb
         Ba50uz8+F0AUGqRjeGx2YCTaU4JNinQ7mN+jpZ5umumTbVso2M2pS1qtfCCKyQea66lh
         9g3g==
X-Forwarded-Encrypted: i=1; AJvYcCVcC1rrGmLS9JbaizWig7ZnFjNQ+sE8EX6iksDt4Y0rIjbnA5toRwKwcjLgTfmX6XVdgss5m/N6xI4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzdxmgIO/qXeONPDDAJoQdOuE8IXTcIGHVJaQ2axkoxzL5cKsXh
	ylr3DZgZVdVXyLdZ8SzluZgRXxPucThUVJ+m1MFgJRlAwDVdXolf/N5bKp9Z2mU=
X-Gm-Gg: ASbGnct0Au4AcMO3NAI/YrLRDpWe7fvhIbhQ701zSv7ZcE4Buv2aN2X4nPl9iXQyUca
	ZvA8JYoiq+r03HTtImyIZKnlDR81dU1Sh2TVqxP+eGEQ518qp0rECSnBctsnAB1TCeci2+gTFvN
	bmPzNLWZSS8jJKJEJiXEE8w1wQUcMa0JAZVWYiUYCpDLUTnOeomkOuPUOp+di1p6iEMsIWuYZyr
	rulgCg+H3yc+h5+zG0ZTjYlnXl2H0Sa8vLiRfHpwk6n2Kh/hATw23rKWq/TeOTOn1Nnle6dFeV7
	S6jrnWWt6oBDtHS8qyhkYSMb7+ALNo3SFixA+39Z3uieC+l8CKyODs0=
X-Google-Smtp-Source: AGHT+IF/y2rn8++eRXtfGXVV9eCNnufdJ4OAKshcVAU/XMr+be4nBaPjnThGR5Wf47h3eLbBgCoQsA==
X-Received: by 2002:a05:6000:401f:b0:38c:2677:9bee with SMTP id ffacd0b85a97d-38c26779db8mr3711264f8f.15.1737675907708;
        Thu, 23 Jan 2025 15:45:07 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	qemu-arm@nongnu.org,
	Igor Mammedov <imammedo@redhat.com>,
	=?UTF-8?q?Alex=20Benn=C3=A9e?= <alex.bennee@linaro.org>,
	kvm@vger.kernel.org,
	qemu-ppc@nongnu.org,
	qemu-riscv@nongnu.org,
	David Hildenbrand <david@redhat.com>,
	qemu-s390x@nongnu.org,
	xen-devel@lists.xenproject.org,
	Richard Henderson <richard.henderson@linaro.org>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
Subject: [PATCH 09/20] accel/tcg: Restrict 'icount_align_option' global to TCG
Date: Fri, 24 Jan 2025 00:44:03 +0100
Message-ID: <20250123234415.59850-10-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250123234415.59850-1-philmd@linaro.org>
References: <20250123234415.59850-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Since commit 740b1759734 ("cpu-timers, icount: new modules")
we don't need to expose icount_align_option to all the
system code, we can restrict it to TCG. Since it is used as
a boolean, declare it as 'bool' type.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 accel/tcg/internal-common.h | 2 ++
 include/system/cpus.h       | 2 --
 accel/tcg/icount-common.c   | 2 ++
 system/globals.c            | 1 -
 4 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/accel/tcg/internal-common.h b/accel/tcg/internal-common.h
index d3186721839..7ef620d9631 100644
--- a/accel/tcg/internal-common.h
+++ b/accel/tcg/internal-common.h
@@ -17,6 +17,8 @@ extern int64_t max_advance;
 
 extern bool one_insn_per_tb;
 
+extern bool icount_align_option;
+
 /*
  * Return true if CS is not running in parallel with other cpus, either
  * because there are no other cpus or we are within an exclusive context.
diff --git a/include/system/cpus.h b/include/system/cpus.h
index 3d8fd368f32..1cffeaaf5c4 100644
--- a/include/system/cpus.h
+++ b/include/system/cpus.h
@@ -38,8 +38,6 @@ void resume_all_vcpus(void);
 void pause_all_vcpus(void);
 void cpu_stop_current(void);
 
-extern int icount_align_option;
-
 /* Unblock cpu */
 void qemu_cpu_kick_self(void);
 
diff --git a/accel/tcg/icount-common.c b/accel/tcg/icount-common.c
index b178dccec45..402d3e3f4e8 100644
--- a/accel/tcg/icount-common.c
+++ b/accel/tcg/icount-common.c
@@ -48,6 +48,8 @@ static bool icount_sleep = true;
 /* Arbitrarily pick 1MIPS as the minimum allowable speed.  */
 #define MAX_ICOUNT_SHIFT 10
 
+bool icount_align_option;
+
 /* Do not count executed instructions */
 ICountMode use_icount = ICOUNT_DISABLED;
 
diff --git a/system/globals.c b/system/globals.c
index 4867c93ca6b..b968e552452 100644
--- a/system/globals.c
+++ b/system/globals.c
@@ -48,7 +48,6 @@ unsigned int nb_prom_envs;
 const char *prom_envs[MAX_PROM_ENVS];
 uint8_t *boot_splash_filedata;
 int only_migratable; /* turn it off unless user states otherwise */
-int icount_align_option;
 
 /* The bytes in qemu_uuid are in the order specified by RFC4122, _not_ in the
  * little-endian "wire format" described in the SMBIOS 2.6 specification.
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 23 23:50:49 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 23:50:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876449.1286824 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6yH-0004oQ-AM; Thu, 23 Jan 2025 23:50:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876449.1286824; Thu, 23 Jan 2025 23:50:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6yH-0004oJ-6s; Thu, 23 Jan 2025 23:50:49 +0000
Received: by outflank-mailman (input) for mailman id 876449;
 Thu, 23 Jan 2025 23:50: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 <SRS0=QxCy=UP=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tb6sW-0007hN-Qx
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 23:44:52 +0000
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com
 [2a00:1450:4864:20::42b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 092ce7e6-d9e4-11ef-99a4-01e77a169b0f;
 Fri, 24 Jan 2025 00:44:50 +0100 (CET)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-38634c35129so1329304f8f.3
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 15:44:50 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38c2a1c4161sm952291f8f.88.2025.01.23.15.44.47
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 23 Jan 2025 15:44:48 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 092ce7e6-d9e4-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737675890; x=1738280690; 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=VK0JABDJF/QMP4ClWDlwjdLf62KvnH3DnM23ZO9feXo=;
        b=PPL2XawRCjzUxoIMFBJ6Kk5O2Z7HkLNf0lmLlIo+RlDD+LkTbMcUerHwlIcdDumtQO
         xLYp7d/eVA37N3AyUxF7UWqewgZJvS50cZ5szueUQEaaSWFy87e62a4TdsCepKYtpmfs
         H6NWe9sWWc6VkfiX8dNXPhmkCx1h5Ug1NJy017uPQVPwDOgi3s6WAXjetlmNHCSuy7Zi
         wmgZ8ip1vZvExdQb45YEcJ3jJJqb21eFw1DmMecbvcxXy92k/bGC+ubIslnXw+xAwZWc
         stbdvrogEuGPfpOtp715Svrm81sJ03yxaRcBrieoGz47Sk+v7CVLrsABIdrG4ps/lwuv
         40Cg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737675890; x=1738280690;
        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=VK0JABDJF/QMP4ClWDlwjdLf62KvnH3DnM23ZO9feXo=;
        b=eCVL8XpHDUWJI09VQpleD8W+30Y4xABl6hCjAO97V4ZRdGc1BlaJm+GS28lyhWj7nT
         UoJ4XxzYxKZC+JXO9rPLKD97aOj33y3kC7mBa38U/H4QuLrAsFmtq7kmfBtG23XXhRJ0
         grsr49+OOpfh85PegGzptsTS7YSdcpiDuqEkOKBhEhftHHBoZfOnl3sCnMYmWMxDa5UV
         Uqp/SGDpiSVxsVxOc9ES7j8D3FLhgNrACz6J793Ny5mf1iLtNMGUhwNacC4lWs44s7lZ
         sqx2rCpjxjenxU9sRjRMJHNyYPUPPTkw2dPm9HwRiFyJZ6BN8c+AokterC2phrApP8LB
         y59Q==
X-Forwarded-Encrypted: i=1; AJvYcCXkDnW+tyWxX24JUnd0I4lXkKTCc6f+Pb/cYPCmN9GXh8fXzvrkHcSLpX9Ck65c3+2Lz4EvRKQife8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwYVXZunykkBtN3WQ2aM7o2KA9QKWq5NaKuI+gyMVz8R9Jpc4Fy
	3dZIrWtwi31hhWGHIf13A8Xg9TASMzZKkfL2/WsfKl72bOAO1yNlGrBBzQO9xwA=
X-Gm-Gg: ASbGnctVe31StALCB4R4sD7qO3x7LqXYG6eCASsyde4cHlyqly5QbKpqR01eDlZKN1r
	TdPznka9cCAKalkJnn/JngHzQcTN8qX3RI6Dvblmga0i70Y25jYr9OT9rTHisxX5+IHiH1aNGMr
	g+qRE+LbgT3bOdcQfsvRqeMe9t3joTDxm0x2bFolJvvDLVGTMLh37KYCNJUVQt612p0pDzQ9FqY
	UUd1Y/ZGVdnsqXcOSll2stHgcql52uL+qYSux+zRw1YeJ211hcPsvJjid3kKsLY9k1cDFE48gsr
	Ej1u4eX0wvr7UvJR+l50H4460gYeLj50AEwoseKNASzf36dWkrRkw34=
X-Google-Smtp-Source: AGHT+IGSMRqXknIm20dxUVJ6YnBSj5qdwQEIsknPsDpqx1Ro9qYQKL2SDEG840LoeQHivalI7LVk8Q==
X-Received: by 2002:a5d:64a1:0:b0:386:3262:28c6 with SMTP id ffacd0b85a97d-38bf5677c09mr24857649f8f.5.1737675889741;
        Thu, 23 Jan 2025 15:44:49 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	qemu-arm@nongnu.org,
	Igor Mammedov <imammedo@redhat.com>,
	=?UTF-8?q?Alex=20Benn=C3=A9e?= <alex.bennee@linaro.org>,
	kvm@vger.kernel.org,
	qemu-ppc@nongnu.org,
	qemu-riscv@nongnu.org,
	David Hildenbrand <david@redhat.com>,
	qemu-s390x@nongnu.org,
	xen-devel@lists.xenproject.org,
	Richard Henderson <richard.henderson@linaro.org>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
Subject: [PATCH 06/20] accel/kvm: Remove unused 'system/cpus.h' header in kvm-cpus.h
Date: Fri, 24 Jan 2025 00:44:00 +0100
Message-ID: <20250123234415.59850-7-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250123234415.59850-1-philmd@linaro.org>
References: <20250123234415.59850-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Missed in commit b86f59c7155 ("accel: replace struct CpusAccel
with AccelOpsClass") which removed the single CpusAccel use.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 accel/kvm/kvm-cpus.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/accel/kvm/kvm-cpus.h b/accel/kvm/kvm-cpus.h
index b5435286e42..688511151c8 100644
--- a/accel/kvm/kvm-cpus.h
+++ b/accel/kvm/kvm-cpus.h
@@ -10,8 +10,6 @@
 #ifndef KVM_CPUS_H
 #define KVM_CPUS_H
 
-#include "system/cpus.h"
-
 int kvm_init_vcpu(CPUState *cpu, Error **errp);
 int kvm_cpu_exec(CPUState *cpu);
 void kvm_destroy_vcpu(CPUState *cpu);
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 23 23:50:49 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 23:50:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876451.1286829 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6yH-0004rL-K6; Thu, 23 Jan 2025 23:50:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876451.1286829; Thu, 23 Jan 2025 23:50:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6yH-0004qs-Fq; Thu, 23 Jan 2025 23:50:49 +0000
Received: by outflank-mailman (input) for mailman id 876451;
 Thu, 23 Jan 2025 23:50: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 <SRS0=QxCy=UP=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tb6tc-0007w9-F1
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 23:46:00 +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 32930e61-d9e4-11ef-a0e5-8be0dac302b0;
 Fri, 24 Jan 2025 00:45:59 +0100 (CET)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-4361f664af5so17051845e9.1
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 15:45:59 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38c2a17d79csm1009152f8f.39.2025.01.23.15.45.57
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 23 Jan 2025 15:45:58 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 32930e61-d9e4-11ef-a0e5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737675959; x=1738280759; 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=9gXZ2pCmpp3MBAsW4Hnbi8sV5bqYGRAr8w/4hsc1kvQ=;
        b=HBR0Uj+vFlsxRlHxJ5Lq/faMJg7NLpYiRNmRyKvYVs/IeUEAcvQvWXWESC+ZhN2Cv9
         F4tmBDzFpFGfjTEq2Ok7O+LWcAnJfoR2vCLsdh3MfPzHg1QVNqkfPXNLbzx1XdwcRzxf
         WG36fc3dnSER1bmmsQUDvFKstxjqiSOkaH81xSU516EXKACL9IZKQeEujiLGxF1EcnT0
         IzAjdbogNFprKSwoUV277n3U4g2M2dMj52nZqy/NmWqMKTNt6ADpQl/tS5la76crbt2r
         0nNUNNa0iFR69OelfmMAKXeUufRk2GtcV8wh6L3OpD/hK8d/3MErL+HurTWlKVKhHMqY
         CEYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737675959; x=1738280759;
        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=9gXZ2pCmpp3MBAsW4Hnbi8sV5bqYGRAr8w/4hsc1kvQ=;
        b=tkMAHEJLZlpUik3bWkZeQZX7Q0RB4AvjnbUjn+EA5dE78Ep1Fx0jqXRX7mgbFh6lrA
         UhlziAHsxQYMqczGJ4OqqQ+QUpVGQ6DNquBsd3Jy/zTLwCuPuO9iLKUAPLW/mFjbzXD/
         ZL+24NleJ2Wy2uPsPa4rnSc9Ourcret7oNyy8lxxhf7MXXD7C4Tcd7GumqE45n30loHr
         30JRJpe6jngHgNa+R0SzCGC8uGfIw6t+1Qnq1p0B98hn6eGxIpKG2xudUPkAJ01JZ6e7
         z30x1ulGdVfwDeiPAOWvAI3X9tU3ERPWQ/Kh/37ASU3wSV/3qsd7YS4J5HGL5De97Jrm
         ndDg==
X-Forwarded-Encrypted: i=1; AJvYcCXaRLF5katSSRRwjMm7LUxzX4kN2EuwxXsHCDcjkPw0OQHN5cfz8ojlvnD/T+i2/daVysRZVfcRUB8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YziqVhUdaaYRjEM3ATAWgfkWLMu6HDkIrcFZB9DFaHiUtrM5OkJ
	WmQHFH5A8cF273C+2v7JCpIFIPdkuuU0lFp3rpvqLNUMNEwwpUGIwgJa+F+QbmM=
X-Gm-Gg: ASbGncsmGOW0yh79hnpgw4lX1rUKMglqhVV40xtGDu99Tgxr8qs7LkbrZshq0y53quj
	fqOBDs5cV7HlP0M7GjcWXHGo6l26BtxrwtwhLe1FFFiTifAZcn3yCfx0L8QVKM0RzS8V78G5SWs
	Dw3cBIwoXAdJHRAN/cgrcgsx61N3B9CQfXX5Eub8XePXEnJZQb3ypqX0nQ7iAagFNOHzmBCcdPA
	+lLMWS5h+Ye03zuIc20yF6+6hsSOmUOKADKe2MTZQYfRNl5UDiPQ5P8DEjPr61Fq60JAD+6TNA4
	1t0nSrf6XL8VR1RbUnSWSLaGsBXPj70WzdFvnM27gVHBueOBUkvEtFE=
X-Google-Smtp-Source: AGHT+IFkrF3nSiyRp86eT1OfDhljZaIiOgfPlVgQgIeU90j7M027ZvrIkgirhKCWekxtCJUAZQHWLg==
X-Received: by 2002:a05:600c:4f48:b0:434:fd15:3adc with SMTP id 5b1f17b1804b1-43891431319mr209632555e9.25.1737675959187;
        Thu, 23 Jan 2025 15:45:59 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	qemu-arm@nongnu.org,
	Igor Mammedov <imammedo@redhat.com>,
	=?UTF-8?q?Alex=20Benn=C3=A9e?= <alex.bennee@linaro.org>,
	kvm@vger.kernel.org,
	qemu-ppc@nongnu.org,
	qemu-riscv@nongnu.org,
	David Hildenbrand <david@redhat.com>,
	qemu-s390x@nongnu.org,
	xen-devel@lists.xenproject.org,
	Richard Henderson <richard.henderson@linaro.org>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
Subject: [PATCH 18/20] cpus: Have cpu_exec_initfn() per user / system emulation
Date: Fri, 24 Jan 2025 00:44:12 +0100
Message-ID: <20250123234415.59850-19-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250123234415.59850-1-philmd@linaro.org>
References: <20250123234415.59850-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Slighly simplify cpu-target.c again by extracting cpu_exec_initfn()
to cpu-{system,user}.c, adding an empty stub for user emulation.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
Good enough for now...
---
 cpu-target.c         | 9 ---------
 hw/core/cpu-system.c | 7 +++++++
 hw/core/cpu-user.c   | 5 +++++
 3 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/cpu-target.c b/cpu-target.c
index dff8c0747f9..3d33d20b8c8 100644
--- a/cpu-target.c
+++ b/cpu-target.c
@@ -24,7 +24,6 @@
 #include "migration/vmstate.h"
 #ifndef CONFIG_USER_ONLY
 #include "hw/core/sysemu-cpu-ops.h"
-#include "exec/address-spaces.h"
 #endif
 #include "system/accel-ops.h"
 #include "system/cpus.h"
@@ -176,14 +175,6 @@ void cpu_exec_unrealizefn(CPUState *cpu)
     accel_cpu_common_unrealize(cpu);
 }
 
-void cpu_exec_initfn(CPUState *cpu)
-{
-#ifndef CONFIG_USER_ONLY
-    cpu->memory = get_system_memory();
-    object_ref(OBJECT(cpu->memory));
-#endif
-}
-
 char *cpu_model_from_type(const char *typename)
 {
     const char *suffix = "-" CPU_RESOLVING_TYPE;
diff --git a/hw/core/cpu-system.c b/hw/core/cpu-system.c
index c63c984a803..0520c362db4 100644
--- a/hw/core/cpu-system.c
+++ b/hw/core/cpu-system.c
@@ -20,6 +20,7 @@
 
 #include "qemu/osdep.h"
 #include "qapi/error.h"
+#include "exec/address-spaces.h"
 #include "exec/memory.h"
 #include "exec/tswap.h"
 #include "hw/qdev-core.h"
@@ -182,3 +183,9 @@ void cpu_class_init_props(DeviceClass *dc)
 
     device_class_set_props(dc, cpu_system_props);
 }
+
+void cpu_exec_initfn(CPUState *cpu)
+{
+    cpu->memory = get_system_memory();
+    object_ref(OBJECT(cpu->memory));
+}
diff --git a/hw/core/cpu-user.c b/hw/core/cpu-user.c
index e5ccf6bf13a..cdd8de2fefa 100644
--- a/hw/core/cpu-user.c
+++ b/hw/core/cpu-user.c
@@ -25,3 +25,8 @@ void cpu_class_init_props(DeviceClass *dc)
 {
     device_class_set_props(dc, cpu_user_props);
 }
+
+void cpu_exec_initfn(CPUState *cpu)
+{
+    /* nothing to do */
+}
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 23 23:50:50 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 23:50:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876452.1286844 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6yI-0005Hr-S0; Thu, 23 Jan 2025 23:50:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876452.1286844; Thu, 23 Jan 2025 23:50:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6yI-0005HD-NY; Thu, 23 Jan 2025 23:50:50 +0000
Received: by outflank-mailman (input) for mailman id 876452;
 Thu, 23 Jan 2025 23:50: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 <SRS0=QxCy=UP=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tb6to-0007hN-Ta
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 23:46:12 +0000
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com
 [2a00:1450:4864:20::434])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3989e658-d9e4-11ef-99a4-01e77a169b0f;
 Fri, 24 Jan 2025 00:46:11 +0100 (CET)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-38a25d4b9d4so823024f8f.0
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 15:46:11 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438bd4d34e3sm6953255e9.39.2025.01.23.15.46.08
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 23 Jan 2025 15:46:10 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 3989e658-d9e4-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737675971; x=1738280771; 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=xSu/7xOdAlhOhpGqndt0dd/xIMB7MzmL+xgNpZ/1JvM=;
        b=MpF2rRi6k7bvT8XV5swq9D7SwhLpMTGCQ0qzULPbxAT0EYMx5yw6XlgiQYoI/Hb0c+
         rUKSsgvtH4jocAc8JcdM3xW8dzMIE1NGRKwbfpFS+kf28/h3YMzA2u4XQpeLFYgyDTyj
         k7pMa5oB2GA/VvijECAfW8p+Mrh++5//KGB0tcVHIAbGMpHMI3KyIMiJOP8EbG1CIDQk
         DBDz+ISRJB14LQ9e6DaqhynYqTDvcgyRNEivIfABdvlDjPD7DDYOua6FZ/yDANN6djK6
         9PYQLjkDMEUX2i3X4U7zbNAQRcEaON84WKUZY2VtPS/7xeRGs5rEUY9305H/073V3US5
         gzTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737675971; x=1738280771;
        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=xSu/7xOdAlhOhpGqndt0dd/xIMB7MzmL+xgNpZ/1JvM=;
        b=Xc8+8N19wTqQ6NdhsP/8HWXYxGMA+nP2yCeSWllmkP5BV6rV1v5Gf7Gva1fyhRs5jQ
         PRSJPS0eX/9v6+shSdyQJrCg8YvUugTTyLDchZWjQKNt4qJG/RV20wTS0DPXojPeqjJ7
         rqWOsOsxB6SXtA37nQiZ2nnDCoLvg+AaXpw9U2pFoXnkCmjljELdN1YSwPoZecpA8/nb
         y4Osl2nDluB6Ors1jfx7/9udwg4mjhWCZw/55dv1SiBvsu1EO4QbriLcY8dLGYmbTq79
         MAz224yF+R1UpqVOYQujWw5H3q9hJK6BZk1I3+Gk1edL3wM/T/mZt4QGHE6FMrtE6n+e
         Z0ow==
X-Forwarded-Encrypted: i=1; AJvYcCU7MFNtEMpJwOJcKWJMlK1sNotzbEAFBMzk9OjnYfAJc+xa62Bg1cQhAUmN3EsP9br5MCA6jjvHy1U=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyYuFfOS1lb2nKCjbfh0KTf4UYIzENA8txIGTbmQNqwnh4L1c0X
	X3EA2D19cxLzbAPER3SeDamwSyIKjQxA4jldIMxOAiGqCStroJJHawqJEVRauJk=
X-Gm-Gg: ASbGncv0h+cU0BGypouSVAY1GeBfcMG2DffjUDGdxw72jcApIt2w7S1v/assMatryPB
	G3jD/gG5QzBLuFD2Fuu89yavBDF0MA9arshcyZj71GYUAs2KQ59G4Hdw4aoVEkNYu8OW2hSuc8g
	+WK9lUqUVWFRRVyzdWiq6wuCSqYa5+LPKtpOJfssSXYN3mduBeruiQiS1zq57O5XMVcsN78z33s
	kwXoigWEjYPzM1BSbLTFlzL2CF9q0KbW7tYAnKey5YizwY4LfbbeoCzxNtmzuYHUAXaJ3lYZPe1
	HjBaJjuK2reZBJo/OWGF9l93uPp4iCtXZDmhFWowtm2EEztt63XpynA=
X-Google-Smtp-Source: AGHT+IFycJysfhMaCpSR16Rzr8MUGZyLqdkkV1WoJ+3KdF//Z7stLVwsFpncYG19E6JH49Nuy1YUSA==
X-Received: by 2002:a05:6000:e4a:b0:385:ed16:c91 with SMTP id ffacd0b85a97d-38bf566f3bemr20406552f8f.24.1737675970851;
        Thu, 23 Jan 2025 15:46:10 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	qemu-arm@nongnu.org,
	Igor Mammedov <imammedo@redhat.com>,
	=?UTF-8?q?Alex=20Benn=C3=A9e?= <alex.bennee@linaro.org>,
	kvm@vger.kernel.org,
	qemu-ppc@nongnu.org,
	qemu-riscv@nongnu.org,
	David Hildenbrand <david@redhat.com>,
	qemu-s390x@nongnu.org,
	xen-devel@lists.xenproject.org,
	Richard Henderson <richard.henderson@linaro.org>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
Subject: [PATCH 20/20] cpus: Build cpu_exec_[un]realizefn() methods once
Date: Fri, 24 Jan 2025 00:44:14 +0100
Message-ID: <20250123234415.59850-21-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250123234415.59850-1-philmd@linaro.org>
References: <20250123234415.59850-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Now that cpu_exec_realizefn() and cpu_exec_unrealizefn()
methods don't use any target specific definition anymore,
we can move them to cpu-common.c to be able to build them
once.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
Eventually they'll be absorbed within cpu_common_[un]realizefn().
---
 cpu-target.c         | 30 ------------------------------
 hw/core/cpu-common.c | 26 ++++++++++++++++++++++++++
 2 files changed, 26 insertions(+), 30 deletions(-)

diff --git a/cpu-target.c b/cpu-target.c
index bfcd48f9ae2..8f4477be417 100644
--- a/cpu-target.c
+++ b/cpu-target.c
@@ -19,43 +19,13 @@
 
 #include "qemu/osdep.h"
 #include "qapi/error.h"
-#include "qemu/error-report.h"
 #include "qemu/qemu-print.h"
 #include "system/accel-ops.h"
 #include "system/cpus.h"
 #include "exec/replay-core.h"
-#include "exec/cpu-common.h"
 #include "exec/log.h"
 #include "accel/accel-cpu-target.h"
 #include "trace/trace-root.h"
-#include "qemu/accel.h"
-#include "hw/core/cpu.h"
-
-bool cpu_exec_realizefn(CPUState *cpu, Error **errp)
-{
-    if (!accel_cpu_common_realize(cpu, errp)) {
-        return false;
-    }
-
-    /* Wait until cpu initialization complete before exposing cpu. */
-    cpu_list_add(cpu);
-
-    cpu_vmstate_register(cpu);
-
-    return true;
-}
-
-void cpu_exec_unrealizefn(CPUState *cpu)
-{
-    cpu_vmstate_unregister(cpu);
-
-    cpu_list_remove(cpu);
-    /*
-     * Now that the vCPU has been removed from the RCU list, we can call
-     * accel_cpu_common_unrealize, which may free fields using call_rcu.
-     */
-    accel_cpu_common_unrealize(cpu);
-}
 
 char *cpu_model_from_type(const char *typename)
 {
diff --git a/hw/core/cpu-common.c b/hw/core/cpu-common.c
index 71425cb7422..c5382a350fc 100644
--- a/hw/core/cpu-common.c
+++ b/hw/core/cpu-common.c
@@ -193,6 +193,20 @@ static void cpu_common_parse_features(const char *typename, char *features,
     }
 }
 
+bool cpu_exec_realizefn(CPUState *cpu, Error **errp)
+{
+    if (!accel_cpu_common_realize(cpu, errp)) {
+        return false;
+    }
+
+    /* Wait until cpu initialization complete before exposing cpu. */
+    cpu_list_add(cpu);
+
+    cpu_vmstate_register(cpu);
+
+    return true;
+}
+
 static void cpu_common_realizefn(DeviceState *dev, Error **errp)
 {
     CPUState *cpu = CPU(dev);
@@ -234,6 +248,18 @@ static void cpu_common_unrealizefn(DeviceState *dev)
     cpu_exec_unrealizefn(cpu);
 }
 
+void cpu_exec_unrealizefn(CPUState *cpu)
+{
+    cpu_vmstate_unregister(cpu);
+
+    cpu_list_remove(cpu);
+    /*
+     * Now that the vCPU has been removed from the RCU list, we can call
+     * accel_cpu_common_unrealize, which may free fields using call_rcu.
+     */
+    accel_cpu_common_unrealize(cpu);
+}
+
 static void cpu_common_initfn(Object *obj)
 {
     CPUState *cpu = CPU(obj);
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 23 23:50:59 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 23:50:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876462.1286854 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6yR-000648-3V; Thu, 23 Jan 2025 23:50:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876462.1286854; Thu, 23 Jan 2025 23:50:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6yQ-00063v-VT; Thu, 23 Jan 2025 23:50:58 +0000
Received: by outflank-mailman (input) for mailman id 876462;
 Thu, 23 Jan 2025 23:50:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=QxCy=UP=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tb6st-0007hN-R9
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 23:45:15 +0000
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com
 [2a00:1450:4864:20::331])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 175196d6-d9e4-11ef-99a4-01e77a169b0f;
 Fri, 24 Jan 2025 00:45:14 +0100 (CET)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-43618283dedso15514455e9.3
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 15:45:14 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438bd54c04bsm6412735e9.27.2025.01.23.15.45.11
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 23 Jan 2025 15:45:12 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 175196d6-d9e4-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737675913; x=1738280713; 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=9nZeRXAiaA5TpZm6lq5Kgnlq642/zMUBUZPLj6lypP8=;
        b=zOoCTYz4CxkPOVKnpTHv6t3P4ZL/ySg13Oysr6zXEoDUOKhoUud9UIk22rWlvbUqUS
         7kepcbo0fd+G6VUlehI/ITWzJV1hrrjg13A8EaLI5Tq/ht0DTrXCG0Ze2U81gq/UtQZY
         XGdU61ktqiNfANpNGR9DwDijBZK6MK3hA2Dr7FQjJAwgZ4+cceO4JVKE2t2JEs52lUzl
         vTvodMINGarMf42hDRz7oggZWFQkHg2mX9G0tbkxZD/r1yjJB7yzx0He1yy3MUBCWOJK
         e9SR9PLKQk4Y81N0uIKAAB43oxMWOfbgN1W5/w24FAUiEL8RnWJu+PBBwajV9mJRFmfz
         Idig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737675913; x=1738280713;
        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=9nZeRXAiaA5TpZm6lq5Kgnlq642/zMUBUZPLj6lypP8=;
        b=hEX5m78JQgOAPt9J1UZjOvLiM90qKH4MzECg7t4KpYPU2v8p7SDuk57qYEkQERd6V9
         G4K/wy+YtuyG9yyCThWIup1msIxQ4aiAb9CzQYKJ4wnWCrAHGa+6xoJ0COHsD71BsuA6
         T5/oRx9rcz+Oa864R7haFdZvtQG03dUdhq89kP10/yxrZVBqxgyPvMqslUxUGXrHehqy
         voPpHpD139JiCXfmbxflSYRpoO58oue/MI+1n/nFJx8yrJBM3egUrUEo0jLNq238KN1J
         a22B68ZEPQQne0e6j+yyRkwPjVS+Udjkcrmss6snh48L1ehBIyfcvaKztwCU11SAaEE0
         hmOg==
X-Forwarded-Encrypted: i=1; AJvYcCUU3nJEE0GzCNl2HE5yrFa+PcdVf3F9zowYdBls4XuA7a6adJH1lqFrjA/JGv+66ENldNJBwEXCRP0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyApg/XN8f6NmsFIz8CotECLtz1/ZAU31mn15PUu8cbjVjj+H1c
	Z7vV1j9j42rW2UVfPn5njoDIjaIVvWPW4vipqDKEnSDxZx5b3KxW+fwnrREs0KA=
X-Gm-Gg: ASbGnctqBWnsEuqAuVgTtxYk2lXhtZ39hqvjGMsWiFfGA5YSo8TywVSvbIrc5auTS96
	a2K5xy2MvfO6y8q7BHnKcpFOxJ6+BFnDoibvXB/oozGm/RrttYtnabjTOKSEEuDoykwbrjhBI9+
	HMcS7cQ02zICU4/9vtS4pKYXBkvcUgbw6WAXwh3tpA+xYt4xhFSgyPX2zx9AxrE00q4hjHd1/cH
	l8tpUYfU0gX2uwVSe9M1N0HBM08hxpoSTihlC8cRafm8/6KDUjt6rP+yo61AGw6DZ0B1qHvRQ4H
	3oMkIE8tgUuDhrfom9q9Ko+sAyDGPENlJ6oHAiDJxybFMP5QPPMrJ+CMKCghyFnI4w==
X-Google-Smtp-Source: AGHT+IEDiDQdxrx2jB8os0igTQ7OuBNE672qZpSpts43JKLj6+qBPVdV+5rplNMJaEPLV2MbkLotbw==
X-Received: by 2002:a05:600c:4713:b0:436:9227:915 with SMTP id 5b1f17b1804b1-438913caa3cmr222825345e9.9.1737675913369;
        Thu, 23 Jan 2025 15:45:13 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	qemu-arm@nongnu.org,
	Igor Mammedov <imammedo@redhat.com>,
	=?UTF-8?q?Alex=20Benn=C3=A9e?= <alex.bennee@linaro.org>,
	kvm@vger.kernel.org,
	qemu-ppc@nongnu.org,
	qemu-riscv@nongnu.org,
	David Hildenbrand <david@redhat.com>,
	qemu-s390x@nongnu.org,
	xen-devel@lists.xenproject.org,
	Richard Henderson <richard.henderson@linaro.org>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
Subject: [PATCH 10/20] accel/tcg: Rename 'hw/core/tcg-cpu-ops.h' -> 'accel/tcg/cpu-ops.h'
Date: Fri, 24 Jan 2025 00:44:04 +0100
Message-ID: <20250123234415.59850-11-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250123234415.59850-1-philmd@linaro.org>
References: <20250123234415.59850-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

TCGCPUOps structure makes more sense in the accelerator context
rather than hardware emulation. Move it under the accel/tcg/ scope.

Mechanical change doing:

 $  sed -i -e 's,hw/core/tcg-cpu-ops.h,accel/tcg/cpu-ops.h,g' \
   $(git grep -l hw/core/tcg-cpu-ops.h)

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 MAINTAINERS                                            | 2 +-
 include/{hw/core/tcg-cpu-ops.h => accel/tcg/cpu-ops.h} | 0
 accel/tcg/cpu-exec.c                                   | 4 ++--
 accel/tcg/cputlb.c                                     | 2 +-
 accel/tcg/translate-all.c                              | 2 +-
 accel/tcg/user-exec.c                                  | 2 +-
 accel/tcg/watchpoint.c                                 | 2 +-
 bsd-user/signal.c                                      | 2 +-
 hw/mips/jazz.c                                         | 2 +-
 linux-user/signal.c                                    | 2 +-
 system/physmem.c                                       | 2 +-
 target/alpha/cpu.c                                     | 2 +-
 target/arm/cpu.c                                       | 2 +-
 target/arm/tcg/cpu-v7m.c                               | 2 +-
 target/arm/tcg/cpu32.c                                 | 2 +-
 target/arm/tcg/mte_helper.c                            | 2 +-
 target/arm/tcg/sve_helper.c                            | 2 +-
 target/avr/cpu.c                                       | 2 +-
 target/avr/helper.c                                    | 2 +-
 target/hexagon/cpu.c                                   | 2 +-
 target/hppa/cpu.c                                      | 2 +-
 target/i386/tcg/tcg-cpu.c                              | 2 +-
 target/loongarch/cpu.c                                 | 2 +-
 target/m68k/cpu.c                                      | 2 +-
 target/microblaze/cpu.c                                | 2 +-
 target/mips/cpu.c                                      | 2 +-
 target/openrisc/cpu.c                                  | 2 +-
 target/ppc/cpu_init.c                                  | 2 +-
 target/riscv/tcg/tcg-cpu.c                             | 2 +-
 target/rx/cpu.c                                        | 2 +-
 target/s390x/cpu.c                                     | 2 +-
 target/s390x/tcg/mem_helper.c                          | 2 +-
 target/sh4/cpu.c                                       | 2 +-
 target/sparc/cpu.c                                     | 2 +-
 target/tricore/cpu.c                                   | 2 +-
 target/xtensa/cpu.c                                    | 2 +-
 36 files changed, 36 insertions(+), 36 deletions(-)
 rename include/{hw/core/tcg-cpu-ops.h => accel/tcg/cpu-ops.h} (100%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7be3d8f431a..fa46d077d30 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -175,7 +175,7 @@ F: include/exec/helper-info.c.inc
 F: include/exec/page-protection.h
 F: include/system/cpus.h
 F: include/system/tcg.h
-F: include/hw/core/tcg-cpu-ops.h
+F: include/accel/tcg/cpu-ops.h
 F: host/include/*/host/cpuinfo.h
 F: util/cpuinfo-*.c
 F: include/tcg/
diff --git a/include/hw/core/tcg-cpu-ops.h b/include/accel/tcg/cpu-ops.h
similarity index 100%
rename from include/hw/core/tcg-cpu-ops.h
rename to include/accel/tcg/cpu-ops.h
diff --git a/accel/tcg/cpu-exec.c b/accel/tcg/cpu-exec.c
index be2ba199d3d..8ee76e14b0d 100644
--- a/accel/tcg/cpu-exec.c
+++ b/accel/tcg/cpu-exec.c
@@ -22,7 +22,7 @@
 #include "qapi/error.h"
 #include "qapi/type-helpers.h"
 #include "hw/core/cpu.h"
-#include "hw/core/tcg-cpu-ops.h"
+#include "accel/tcg/cpu-ops.h"
 #include "trace.h"
 #include "disas/disas.h"
 #include "exec/cpu-common.h"
@@ -39,7 +39,7 @@
 #include "exec/replay-core.h"
 #include "system/tcg.h"
 #include "exec/helper-proto-common.h"
-#include "tb-jmp-cache.h"
+//#include "tb-jmp-cache.h"
 #include "tb-hash.h"
 #include "tb-context.h"
 #include "tb-internal.h"
diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
index b4ccf0cdcb7..d68401b35c3 100644
--- a/accel/tcg/cputlb.c
+++ b/accel/tcg/cputlb.c
@@ -19,7 +19,7 @@
 
 #include "qemu/osdep.h"
 #include "qemu/main-loop.h"
-#include "hw/core/tcg-cpu-ops.h"
+#include "accel/tcg/cpu-ops.h"
 #include "exec/exec-all.h"
 #include "exec/page-protection.h"
 #include "exec/memory.h"
diff --git a/accel/tcg/translate-all.c b/accel/tcg/translate-all.c
index d4189c73860..786e2f6f1a7 100644
--- a/accel/tcg/translate-all.c
+++ b/accel/tcg/translate-all.c
@@ -58,7 +58,7 @@
 #include "system/cpu-timers.h"
 #include "system/tcg.h"
 #include "qapi/error.h"
-#include "hw/core/tcg-cpu-ops.h"
+#include "accel/tcg/cpu-ops.h"
 #include "tb-jmp-cache.h"
 #include "tb-hash.h"
 #include "tb-context.h"
diff --git a/accel/tcg/user-exec.c b/accel/tcg/user-exec.c
index 0561c4f6dc7..c4454100ad7 100644
--- a/accel/tcg/user-exec.c
+++ b/accel/tcg/user-exec.c
@@ -17,7 +17,7 @@
  * License along with this library; if not, see <http://www.gnu.org/licenses/>.
  */
 #include "qemu/osdep.h"
-#include "hw/core/tcg-cpu-ops.h"
+#include "accel/tcg/cpu-ops.h"
 #include "disas/disas.h"
 #include "exec/exec-all.h"
 #include "tcg/tcg.h"
diff --git a/accel/tcg/watchpoint.c b/accel/tcg/watchpoint.c
index af57d182d5b..40112b2b2e7 100644
--- a/accel/tcg/watchpoint.c
+++ b/accel/tcg/watchpoint.c
@@ -26,7 +26,7 @@
 #include "tb-internal.h"
 #include "system/tcg.h"
 #include "system/replay.h"
-#include "hw/core/tcg-cpu-ops.h"
+#include "accel/tcg/cpu-ops.h"
 #include "hw/core/cpu.h"
 #include "internal-common.h"
 
diff --git a/bsd-user/signal.c b/bsd-user/signal.c
index b4e1458237a..088fe775c05 100644
--- a/bsd-user/signal.c
+++ b/bsd-user/signal.c
@@ -28,7 +28,7 @@
 #include "gdbstub/user.h"
 #include "signal-common.h"
 #include "trace.h"
-#include "hw/core/tcg-cpu-ops.h"
+#include "accel/tcg/cpu-ops.h"
 #include "host-signal.h"
 
 /* target_siginfo_t must fit in gdbstub's siginfo save area. */
diff --git a/hw/mips/jazz.c b/hw/mips/jazz.c
index c89610639a9..1700c3765de 100644
--- a/hw/mips/jazz.c
+++ b/hw/mips/jazz.c
@@ -50,7 +50,7 @@
 #include "qemu/error-report.h"
 #include "qemu/help_option.h"
 #ifdef CONFIG_TCG
-#include "hw/core/tcg-cpu-ops.h"
+#include "accel/tcg/cpu-ops.h"
 #endif /* CONFIG_TCG */
 #include "cpu.h"
 
diff --git a/linux-user/signal.c b/linux-user/signal.c
index 087c4d270e4..b9e9b0a6c03 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -21,7 +21,7 @@
 #include "qemu/cutils.h"
 #include "gdbstub/user.h"
 #include "exec/page-protection.h"
-#include "hw/core/tcg-cpu-ops.h"
+#include "accel/tcg/cpu-ops.h"
 
 #include <sys/ucontext.h>
 #include <sys/resource.h>
diff --git a/system/physmem.c b/system/physmem.c
index c76503aea82..8638f8817e6 100644
--- a/system/physmem.c
+++ b/system/physmem.c
@@ -28,7 +28,7 @@
 #include "qemu/lockable.h"
 
 #ifdef CONFIG_TCG
-#include "hw/core/tcg-cpu-ops.h"
+#include "accel/tcg/cpu-ops.h"
 #endif /* CONFIG_TCG */
 
 #include "exec/exec-all.h"
diff --git a/target/alpha/cpu.c b/target/alpha/cpu.c
index e1b898e5755..da21f99a6ac 100644
--- a/target/alpha/cpu.c
+++ b/target/alpha/cpu.c
@@ -220,7 +220,7 @@ static const struct SysemuCPUOps alpha_sysemu_ops = {
 };
 #endif
 
-#include "hw/core/tcg-cpu-ops.h"
+#include "accel/tcg/cpu-ops.h"
 
 static const TCGCPUOps alpha_tcg_ops = {
     .initialize = alpha_translate_init,
diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index dc0231233a6..d59433e33fb 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -29,7 +29,7 @@
 #include "cpu.h"
 #ifdef CONFIG_TCG
 #include "exec/translation-block.h"
-#include "hw/core/tcg-cpu-ops.h"
+#include "accel/tcg/cpu-ops.h"
 #endif /* CONFIG_TCG */
 #include "internals.h"
 #include "cpu-features.h"
diff --git a/target/arm/tcg/cpu-v7m.c b/target/arm/tcg/cpu-v7m.c
index 03acdf83e00..29a41fde694 100644
--- a/target/arm/tcg/cpu-v7m.c
+++ b/target/arm/tcg/cpu-v7m.c
@@ -10,7 +10,7 @@
 
 #include "qemu/osdep.h"
 #include "cpu.h"
-#include "hw/core/tcg-cpu-ops.h"
+#include "accel/tcg/cpu-ops.h"
 #include "internals.h"
 
 #if !defined(CONFIG_USER_ONLY)
diff --git a/target/arm/tcg/cpu32.c b/target/arm/tcg/cpu32.c
index 2ad21825255..c5913665d12 100644
--- a/target/arm/tcg/cpu32.c
+++ b/target/arm/tcg/cpu32.c
@@ -10,7 +10,7 @@
 
 #include "qemu/osdep.h"
 #include "cpu.h"
-#include "hw/core/tcg-cpu-ops.h"
+#include "accel/tcg/cpu-ops.h"
 #include "internals.h"
 #include "target/arm/idau.h"
 #if !defined(CONFIG_USER_ONLY)
diff --git a/target/arm/tcg/mte_helper.c b/target/arm/tcg/mte_helper.c
index f72ce2ae0d4..5d6d8a17ae8 100644
--- a/target/arm/tcg/mte_helper.c
+++ b/target/arm/tcg/mte_helper.c
@@ -31,7 +31,7 @@
 #endif
 #include "exec/cpu_ldst.h"
 #include "exec/helper-proto.h"
-#include "hw/core/tcg-cpu-ops.h"
+#include "accel/tcg/cpu-ops.h"
 #include "qapi/error.h"
 #include "qemu/guest-random.h"
 #include "mte_helper.h"
diff --git a/target/arm/tcg/sve_helper.c b/target/arm/tcg/sve_helper.c
index d0865dece35..2268fcd41b0 100644
--- a/target/arm/tcg/sve_helper.c
+++ b/target/arm/tcg/sve_helper.c
@@ -28,7 +28,7 @@
 #include "tcg/tcg.h"
 #include "vec_internal.h"
 #include "sve_ldst_internal.h"
-#include "hw/core/tcg-cpu-ops.h"
+#include "accel/tcg/cpu-ops.h"
 #ifdef CONFIG_USER_ONLY
 #include "user/page-protection.h"
 #endif
diff --git a/target/avr/cpu.c b/target/avr/cpu.c
index 8a126ff3222..5a0e21465e5 100644
--- a/target/avr/cpu.c
+++ b/target/avr/cpu.c
@@ -203,7 +203,7 @@ static const struct SysemuCPUOps avr_sysemu_ops = {
     .get_phys_page_debug = avr_cpu_get_phys_page_debug,
 };
 
-#include "hw/core/tcg-cpu-ops.h"
+#include "accel/tcg/cpu-ops.h"
 
 static const TCGCPUOps avr_tcg_ops = {
     .initialize = avr_cpu_tcg_init,
diff --git a/target/avr/helper.c b/target/avr/helper.c
index 345708a1b39..9ea6870e44d 100644
--- a/target/avr/helper.c
+++ b/target/avr/helper.c
@@ -22,7 +22,7 @@
 #include "qemu/log.h"
 #include "qemu/error-report.h"
 #include "cpu.h"
-#include "hw/core/tcg-cpu-ops.h"
+#include "accel/tcg/cpu-ops.h"
 #include "exec/exec-all.h"
 #include "exec/page-protection.h"
 #include "exec/cpu_ldst.h"
diff --git a/target/hexagon/cpu.c b/target/hexagon/cpu.c
index 0b7fc98f6ce..238e63bcea4 100644
--- a/target/hexagon/cpu.c
+++ b/target/hexagon/cpu.c
@@ -321,7 +321,7 @@ static void hexagon_cpu_init(Object *obj)
 {
 }
 
-#include "hw/core/tcg-cpu-ops.h"
+#include "accel/tcg/cpu-ops.h"
 
 static const TCGCPUOps hexagon_tcg_ops = {
     .initialize = hexagon_translate_init,
diff --git a/target/hppa/cpu.c b/target/hppa/cpu.c
index b0bc9d35e4c..f2441d4d7fb 100644
--- a/target/hppa/cpu.c
+++ b/target/hppa/cpu.c
@@ -235,7 +235,7 @@ static const struct SysemuCPUOps hppa_sysemu_ops = {
 };
 #endif
 
-#include "hw/core/tcg-cpu-ops.h"
+#include "accel/tcg/cpu-ops.h"
 
 static const TCGCPUOps hppa_tcg_ops = {
     .initialize = hppa_translate_init,
diff --git a/target/i386/tcg/tcg-cpu.c b/target/i386/tcg/tcg-cpu.c
index 14ee038079a..f09ee813ac9 100644
--- a/target/i386/tcg/tcg-cpu.c
+++ b/target/i386/tcg/tcg-cpu.c
@@ -105,7 +105,7 @@ static bool x86_debug_check_breakpoint(CPUState *cs)
 }
 #endif
 
-#include "hw/core/tcg-cpu-ops.h"
+#include "accel/tcg/cpu-ops.h"
 
 static const TCGCPUOps x86_tcg_ops = {
     .initialize = tcg_x86_init,
diff --git a/target/loongarch/cpu.c b/target/loongarch/cpu.c
index d611a604704..ecfd6edefbe 100644
--- a/target/loongarch/cpu.c
+++ b/target/loongarch/cpu.c
@@ -813,7 +813,7 @@ static void loongarch_cpu_dump_state(CPUState *cs, FILE *f, int flags)
 }
 
 #ifdef CONFIG_TCG
-#include "hw/core/tcg-cpu-ops.h"
+#include "accel/tcg/cpu-ops.h"
 
 static const TCGCPUOps loongarch_tcg_ops = {
     .initialize = loongarch_translate_init,
diff --git a/target/m68k/cpu.c b/target/m68k/cpu.c
index 41dfdf58045..5eac4a38c62 100644
--- a/target/m68k/cpu.c
+++ b/target/m68k/cpu.c
@@ -547,7 +547,7 @@ static const struct SysemuCPUOps m68k_sysemu_ops = {
 };
 #endif /* !CONFIG_USER_ONLY */
 
-#include "hw/core/tcg-cpu-ops.h"
+#include "accel/tcg/cpu-ops.h"
 
 static const TCGCPUOps m68k_tcg_ops = {
     .initialize = m68k_tcg_init,
diff --git a/target/microblaze/cpu.c b/target/microblaze/cpu.c
index f114789abd8..13d194cef88 100644
--- a/target/microblaze/cpu.c
+++ b/target/microblaze/cpu.c
@@ -419,7 +419,7 @@ static const struct SysemuCPUOps mb_sysemu_ops = {
 };
 #endif
 
-#include "hw/core/tcg-cpu-ops.h"
+#include "accel/tcg/cpu-ops.h"
 
 static const TCGCPUOps mb_tcg_ops = {
     .initialize = mb_tcg_init,
diff --git a/target/mips/cpu.c b/target/mips/cpu.c
index 47cd7cfdcef..0b267d2e507 100644
--- a/target/mips/cpu.c
+++ b/target/mips/cpu.c
@@ -544,7 +544,7 @@ static const Property mips_cpu_properties[] = {
 };
 
 #ifdef CONFIG_TCG
-#include "hw/core/tcg-cpu-ops.h"
+#include "accel/tcg/cpu-ops.h"
 static const TCGCPUOps mips_tcg_ops = {
     .initialize = mips_tcg_init,
     .translate_code = mips_translate_code,
diff --git a/target/openrisc/cpu.c b/target/openrisc/cpu.c
index b7bab0d7abf..0669ba2fd10 100644
--- a/target/openrisc/cpu.c
+++ b/target/openrisc/cpu.c
@@ -232,7 +232,7 @@ static const struct SysemuCPUOps openrisc_sysemu_ops = {
 };
 #endif
 
-#include "hw/core/tcg-cpu-ops.h"
+#include "accel/tcg/cpu-ops.h"
 
 static const TCGCPUOps openrisc_tcg_ops = {
     .initialize = openrisc_translate_init,
diff --git a/target/ppc/cpu_init.c b/target/ppc/cpu_init.c
index c05c2dc42dc..ed85448bc7d 100644
--- a/target/ppc/cpu_init.c
+++ b/target/ppc/cpu_init.c
@@ -7427,7 +7427,7 @@ static const struct SysemuCPUOps ppc_sysemu_ops = {
 #endif
 
 #ifdef CONFIG_TCG
-#include "hw/core/tcg-cpu-ops.h"
+#include "accel/tcg/cpu-ops.h"
 
 static const TCGCPUOps ppc_tcg_ops = {
   .initialize = ppc_translate_init,
diff --git a/target/riscv/tcg/tcg-cpu.c b/target/riscv/tcg/tcg-cpu.c
index 0a137281de1..e40c8e85b26 100644
--- a/target/riscv/tcg/tcg-cpu.c
+++ b/target/riscv/tcg/tcg-cpu.c
@@ -31,7 +31,7 @@
 #include "qemu/error-report.h"
 #include "qemu/log.h"
 #include "hw/core/accel-cpu.h"
-#include "hw/core/tcg-cpu-ops.h"
+#include "accel/tcg/cpu-ops.h"
 #include "tcg/tcg.h"
 #ifndef CONFIG_USER_ONLY
 #include "hw/boards.h"
diff --git a/target/rx/cpu.c b/target/rx/cpu.c
index 8c50c7a1bc8..d237d007023 100644
--- a/target/rx/cpu.c
+++ b/target/rx/cpu.c
@@ -192,7 +192,7 @@ static const struct SysemuCPUOps rx_sysemu_ops = {
 };
 #endif
 
-#include "hw/core/tcg-cpu-ops.h"
+#include "accel/tcg/cpu-ops.h"
 
 static const TCGCPUOps rx_tcg_ops = {
     .initialize = rx_translate_init,
diff --git a/target/s390x/cpu.c b/target/s390x/cpu.c
index 97d41c23de7..3bea014f9ee 100644
--- a/target/s390x/cpu.c
+++ b/target/s390x/cpu.c
@@ -322,7 +322,7 @@ static const Property s390x_cpu_properties[] = {
 #endif
 
 #ifdef CONFIG_TCG
-#include "hw/core/tcg-cpu-ops.h"
+#include "accel/tcg/cpu-ops.h"
 
 void cpu_get_tb_cpu_state(CPUS390XState *env, vaddr *pc,
                           uint64_t *cs_base, uint32_t *pflags)
diff --git a/target/s390x/tcg/mem_helper.c b/target/s390x/tcg/mem_helper.c
index 32717acb7d1..4ce7aa8127f 100644
--- a/target/s390x/tcg/mem_helper.c
+++ b/target/s390x/tcg/mem_helper.c
@@ -28,7 +28,7 @@
 #include "exec/exec-all.h"
 #include "exec/page-protection.h"
 #include "exec/cpu_ldst.h"
-#include "hw/core/tcg-cpu-ops.h"
+#include "accel/tcg/cpu-ops.h"
 #include "qemu/int128.h"
 #include "qemu/atomic128.h"
 
diff --git a/target/sh4/cpu.c b/target/sh4/cpu.c
index 24a22724c61..e3c2aea1a64 100644
--- a/target/sh4/cpu.c
+++ b/target/sh4/cpu.c
@@ -247,7 +247,7 @@ static const struct SysemuCPUOps sh4_sysemu_ops = {
 };
 #endif
 
-#include "hw/core/tcg-cpu-ops.h"
+#include "accel/tcg/cpu-ops.h"
 
 static const TCGCPUOps superh_tcg_ops = {
     .initialize = sh4_translate_init,
diff --git a/target/sparc/cpu.c b/target/sparc/cpu.c
index fbd38ec334a..e3b46137178 100644
--- a/target/sparc/cpu.c
+++ b/target/sparc/cpu.c
@@ -992,7 +992,7 @@ static const struct SysemuCPUOps sparc_sysemu_ops = {
 #endif
 
 #ifdef CONFIG_TCG
-#include "hw/core/tcg-cpu-ops.h"
+#include "accel/tcg/cpu-ops.h"
 
 static const TCGCPUOps sparc_tcg_ops = {
     .initialize = sparc_tcg_init,
diff --git a/target/tricore/cpu.c b/target/tricore/cpu.c
index 95202fadbfd..eb794674c8d 100644
--- a/target/tricore/cpu.c
+++ b/target/tricore/cpu.c
@@ -168,7 +168,7 @@ static const struct SysemuCPUOps tricore_sysemu_ops = {
     .get_phys_page_debug = tricore_cpu_get_phys_page_debug,
 };
 
-#include "hw/core/tcg-cpu-ops.h"
+#include "accel/tcg/cpu-ops.h"
 
 static const TCGCPUOps tricore_tcg_ops = {
     .initialize = tricore_tcg_init,
diff --git a/target/xtensa/cpu.c b/target/xtensa/cpu.c
index 4eb699d1f45..efbfe73fcfb 100644
--- a/target/xtensa/cpu.c
+++ b/target/xtensa/cpu.c
@@ -228,7 +228,7 @@ static const struct SysemuCPUOps xtensa_sysemu_ops = {
 };
 #endif
 
-#include "hw/core/tcg-cpu-ops.h"
+#include "accel/tcg/cpu-ops.h"
 
 static const TCGCPUOps xtensa_tcg_ops = {
     .initialize = xtensa_translate_init,
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 23 23:51:09 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 23:51:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876479.1286864 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6yb-0006wC-H8; Thu, 23 Jan 2025 23:51:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876479.1286864; Thu, 23 Jan 2025 23:51:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6yb-0006w1-Du; Thu, 23 Jan 2025 23:51:09 +0000
Received: by outflank-mailman (input) for mailman id 876479;
 Thu, 23 Jan 2025 23:51:08 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=QxCy=UP=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tb6tZ-0007hN-9Y
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 23:45:57 +0000
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com
 [2a00:1450:4864:20::333])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3041449e-d9e4-11ef-99a4-01e77a169b0f;
 Fri, 24 Jan 2025 00:45:55 +0100 (CET)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-43624b2d453so16032555e9.2
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 15:45:55 -0800 (PST)
Received: from [192.168.69.181] (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438bd47f355sm7140915e9.4.2025.01.23.15.45.53
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 23 Jan 2025 15:45:53 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 3041449e-d9e4-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737675955; x=1738280755; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=sIImxUuZ28chVlLL+vN1mb6UQluYe71i/J3SLXui4EM=;
        b=kAPNveCIXFEMkKGA1q4Ps84Wkn0js23LmfHkvmJWBelJ0ETeR4oFk2q2ZsHu2R5gTN
         OWG/WINmUUc+ev83A4A2V64C3ncICF+bceHMGliX8Rd0MKjbadhSn1tH3iuf3bBqaqxZ
         +AiLx+x0LR5DFWCHz8I9gXjb5oKRBIWsh32zvsVa/EAfQpfC0ELsa+0mSqBfXY0+naCd
         DmDQDtD6XHYe0gJIdQQUESXfK0/ZG0/yqygaz5QD+we5AtxspfjUoO/x0JZo06nxRlKH
         JdVdom//19VvXkcr/driW+xuXDzG94kwCHW6ME9dy0eaoe99rH9dL8XhLwic0oJ/8fcU
         gkww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737675955; x=1738280755;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=sIImxUuZ28chVlLL+vN1mb6UQluYe71i/J3SLXui4EM=;
        b=AVzBi6Fujm26gE4T+Z/2HDRWUpEvkcwMWx09eb1WgO6nSjjkQexwUHTxnCiWYl7XvT
         dZX9PNXumlfE3vOIezwptJviiFzKqRsBPxMhFTntpTzauebq/UwlgJCOU/Z4GsvSXqc+
         rsMzfTWqq68RUV7MZNNoQXbjQa1mxzsdk8Yjy7yX8zeMc8IfsOJ0eA8dQ6NxxT/Cq1uw
         Zb38mB7jJW5sUtx7PiD8VWXGmc7PdqhzlpY8DXIX0V8uxO+PJfFi0746X+NdLsImNfGv
         i4BEcd0ETwpk1cFHT7PX1r7y5zvSlBQEhDOJkFCX90NJpUvFI8DGMm/0hfcDl/Nov9SO
         rn6w==
X-Forwarded-Encrypted: i=1; AJvYcCX8L+NzcXcTq2fGLhjZe1QG9xoF/9Y8RfoLleu8wF1fssPmjIF4SQvltaZcE6Hsjmtw0G5W+O5TVPI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxDUIBBwm3w7MbPpX957K/e/OsWvyEXnXjs6L1owQFhnUX547j4
	EOgqupgeJJcfCFebWaBB7Nr6Bp0hvRtO0gdmXjmF9ClLtvYMOgINoX+P0c842D0=
X-Gm-Gg: ASbGncv+shEOpmOZ4lravWKGPDbJffxlwYJa0zzKmJz3d9jJ/AdWH0aoSsP+6x9hU0H
	hGDLH4Th/nnYosWJxEitYuuKSFpjvHQT58gML1GndA874LBkI0ET5G3AE7FhSmVig5Ay2MiaOfi
	IaMinop4KQQp9HPcU1Vq7UJH9Da7/n9pboWcg6f0uhK4HzpMmR/KNWDUPdA2YqvhH9w3Q+Ocu8e
	sevUHNg+ilEd5Pe2lnYE70RCADOM7kIYC21uYGL4eP0ApMj2vq9D7RMN16Z9lNIOc3S0qfpa/8e
	OtIUEAm2vyvjlj7m+7QjIZj677WAQ+6ctkS3ey40ke6cnMWbnOLwk84rifI=
X-Google-Smtp-Source: AGHT+IGfBJfULhniARVxaeHND22dVQGvVM8jm6sNf2yido1MC4lasaduEx+qwJvir1julFx+bnHZjg==
X-Received: by 2002:a05:600c:35c3:b0:434:f131:1e71 with SMTP id 5b1f17b1804b1-438913cf2e0mr264387845e9.8.1737675955349;
        Thu, 23 Jan 2025 15:45:55 -0800 (PST)
Message-ID: <3ef3ad0c-0f53-4588-aaf2-f6fd712ebd41@linaro.org>
Date: Fri, 24 Jan 2025 00:45:52 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 02/20] user: Extract common MMAP API to 'user/mmap.h'
To: qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
 Paolo Bonzini <pbonzini@redhat.com>, qemu-arm@nongnu.org,
 Igor Mammedov <imammedo@redhat.com>, =?UTF-8?Q?Alex_Benn=C3=A9e?=
 <alex.bennee@linaro.org>, kvm@vger.kernel.org, qemu-ppc@nongnu.org,
 qemu-riscv@nongnu.org, David Hildenbrand <david@redhat.com>,
 qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org,
 Richard Henderson <richard.henderson@linaro.org>
References: <20250123234415.59850-1-philmd@linaro.org>
 <20250123234415.59850-3-philmd@linaro.org>
Content-Language: en-US
From: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= <philmd@linaro.org>
In-Reply-To: <20250123234415.59850-3-philmd@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 24/1/25 00:43, Philippe Mathieu-Daudé wrote:
> Keep common MMAP-related declarations in a single place.
> 
> Note, this disable ThreadSafetyAnalysis on Linux for:
> - mmap_fork_start()
> - mmap_fork_end().
> 
> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>

I forgot to include:
Reviewed-by: Warner Losh <imp@bsdimp.com>

> ---
>   bsd-user/qemu.h        | 12 +-----------
>   include/user/mmap.h    | 32 ++++++++++++++++++++++++++++++++
>   linux-user/user-mmap.h | 19 ++-----------------
>   3 files changed, 35 insertions(+), 28 deletions(-)
>   create mode 100644 include/user/mmap.h



From xen-devel-bounces@lists.xenproject.org Thu Jan 23 23:51:17 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 23:51:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876486.1286873 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6yj-0007X5-PC; Thu, 23 Jan 2025 23:51:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876486.1286873; Thu, 23 Jan 2025 23:51:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6yj-0007WI-Lv; Thu, 23 Jan 2025 23:51:17 +0000
Received: by outflank-mailman (input) for mailman id 876486;
 Thu, 23 Jan 2025 23:51:16 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=QxCy=UP=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tb6tj-0007hN-FG
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 23:46:07 +0000
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com
 [2a00:1450:4864:20::42f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3620e9ed-d9e4-11ef-99a4-01e77a169b0f;
 Fri, 24 Jan 2025 00:46:05 +0100 (CET)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-3862d16b4f5so936519f8f.0
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 15:46:05 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38c2a1c403asm989733f8f.93.2025.01.23.15.46.03
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 23 Jan 2025 15:46:03 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 3620e9ed-d9e4-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737675965; x=1738280765; 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=sQ+5PubFZrrCYmUor7z2ohXZLQOj0+FDz6CQ50FZwrM=;
        b=cNL9W4GgXiGbGKj5Oaf3xRXVRuwiyeOYXu35T/8Gek6sP8ZleQZ9j6A9Gwd79h5SwV
         b7ot/UE0hMOfrofoLe7KfZ6prqCnRkobFW2vqBRP1h7damETpX1HePopzG7g6iimmtcG
         yr4TceZEyoxU9eKyNxP9twyN345/mejOxRdiIeEYNr3Gp+NjgKZNORwC1RgkhJSTeSzF
         bew6hrKDuiaC5BEXL6YlPb96cDgmDKf0A6nHXQhAKW+5Ug+bl+Huwj76mAA0pE7rsoHW
         bu3ys0XPQ46DG6bG796R0ZM7dIjgLwaVhZltVu28LhV61GBn9qnYS91Tev+yBojcIJjM
         fKJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737675965; x=1738280765;
        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=sQ+5PubFZrrCYmUor7z2ohXZLQOj0+FDz6CQ50FZwrM=;
        b=N/4IDG1mHaoDKC+S4ZV2CosUH1WIBQeZudMW8mz1ehVpXlf5IoeLCQBtGPt0wPnusK
         jbGAdWQLEwR8mq04DrCC8mAPcDXJ3qO2CBNpWVwIB8fU7Qv44aIy3uvPvRxg5Fy+TlGC
         XipG3xRBbciu6PAy+H48pkpL7NcJ/RCltj33f1OXj/Jx6uWu/XCNOBqgcNQBbi71YtDh
         jd18arq6Ta7Uzd2j1i02VY/GjSUr5TTW2YQZ7uNBZGloQZxnZ6U0+i5ohlCucIntdonx
         54XD09ujzjbLBwmClUslFyF+nyY/Akh3GAp57LFyx7ieBt6SxFFVqKB/gJCctugWEVf/
         5l9w==
X-Forwarded-Encrypted: i=1; AJvYcCVx/AleA068NJoEDcrWE0lXMhNZL53pkOu7pMR5PWZplyRf+G4dKeX2uUKhIyGWGf4zAO15V3mxwsA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxXhleRHduSx4qFQ568LDms2U+IBgKxZfUO/CTs1iiDUCPySaSY
	fkSpuTkwz5at3SSK7P1qeIl47qyMKCxcHRpIjTpRkZxOWLM5qNKQBQsc3Z6QGZlAr57YNLa15IG
	9TD8=
X-Gm-Gg: ASbGncvz9mDfY+LYwTsMQFLns7IwRXZNHj6YNpTyzq62QQ1kcy2aBffsCJWz6IBMRT8
	3ceijSICi0MJ8SKu1qJrQpjK3qyO8kh8J8xLOb2cLrgT73eeqxfNpuJRIeywFSlKGtZDgdF3vVs
	1ecSs4gUjiNe/36qWazzy1jr6c80Qcm8elWzSNNMQKYRMdpNn8llDP2B4/lwqMJv2xAczltv/uP
	CVOhMb6zT01hQopiCYNSV+jfjeVZTEU9d23JESNyXkbEQFXV8tKblYxb6s8S2VVmuyhP35LRR5l
	ZHh54gNS6WCmoiHAemtEqER3SIp1KMRD3+RA3YQKvsnl6Uxl3WGwOpA=
X-Google-Smtp-Source: AGHT+IGsiKZVvuhBn67VKbvp7ZCKdJegwhgfqv/IiEk5xyysRNRbKSY3tyJ6LqHq9Om3O3Zv9Xfmsw==
X-Received: by 2002:adf:f250:0:b0:38a:5dc4:6dcd with SMTP id ffacd0b85a97d-38c22279dafmr4343550f8f.22.1737675965020;
        Thu, 23 Jan 2025 15:46:05 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	qemu-arm@nongnu.org,
	Igor Mammedov <imammedo@redhat.com>,
	=?UTF-8?q?Alex=20Benn=C3=A9e?= <alex.bennee@linaro.org>,
	kvm@vger.kernel.org,
	qemu-ppc@nongnu.org,
	qemu-riscv@nongnu.org,
	David Hildenbrand <david@redhat.com>,
	qemu-s390x@nongnu.org,
	xen-devel@lists.xenproject.org,
	Richard Henderson <richard.henderson@linaro.org>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
Subject: [PATCH 19/20] cpus: Register VMState per user / system emulation
Date: Fri, 24 Jan 2025 00:44:13 +0100
Message-ID: <20250123234415.59850-20-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250123234415.59850-1-philmd@linaro.org>
References: <20250123234415.59850-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Simplify cpu-target.c by extracting mixed vmstate code
into the cpu_vmstate_register() / cpu_vmstate_unregister()
helpers, implemented in cpu-user.c and cpu-system.c.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
XXX: tlb_flush() temporary declared manually.

Only 2 more CONFIG_USER_ONLY to go.
---
 include/hw/core/cpu.h |   2 +
 cpu-target.c          | 122 +----------------------------------------
 hw/core/cpu-system.c  | 123 ++++++++++++++++++++++++++++++++++++++++++
 hw/core/cpu-user.c    |  12 +++++
 4 files changed, 139 insertions(+), 120 deletions(-)

diff --git a/include/hw/core/cpu.h b/include/hw/core/cpu.h
index fb397cdfc53..aadbd2e1122 100644
--- a/include/hw/core/cpu.h
+++ b/include/hw/core/cpu.h
@@ -1163,6 +1163,8 @@ G_NORETURN void cpu_abort(CPUState *cpu, const char *fmt, ...)
 /* $(top_srcdir)/cpu.c */
 void cpu_class_init_props(DeviceClass *dc);
 void cpu_exec_initfn(CPUState *cpu);
+void cpu_vmstate_register(CPUState *cpu);
+void cpu_vmstate_unregister(CPUState *cpu);
 bool cpu_exec_realizefn(CPUState *cpu, Error **errp);
 void cpu_exec_unrealizefn(CPUState *cpu);
 void cpu_exec_reset_hold(CPUState *cpu);
diff --git a/cpu-target.c b/cpu-target.c
index 3d33d20b8c8..bfcd48f9ae2 100644
--- a/cpu-target.c
+++ b/cpu-target.c
@@ -21,115 +21,16 @@
 #include "qapi/error.h"
 #include "qemu/error-report.h"
 #include "qemu/qemu-print.h"
-#include "migration/vmstate.h"
-#ifndef CONFIG_USER_ONLY
-#include "hw/core/sysemu-cpu-ops.h"
-#endif
 #include "system/accel-ops.h"
 #include "system/cpus.h"
-#include "system/tcg.h"
 #include "exec/replay-core.h"
 #include "exec/cpu-common.h"
-#include "exec/exec-all.h"
-#include "exec/tb-flush.h"
 #include "exec/log.h"
 #include "accel/accel-cpu-target.h"
 #include "trace/trace-root.h"
 #include "qemu/accel.h"
 #include "hw/core/cpu.h"
 
-#ifndef CONFIG_USER_ONLY
-static int cpu_common_post_load(void *opaque, int version_id)
-{
-#ifdef CONFIG_TCG
-    if (tcg_enabled()) {
-        CPUState *cpu = opaque;
-
-        /*
-         * 0x01 was CPU_INTERRUPT_EXIT. This line can be removed when the
-         * version_id is increased.
-         */
-        cpu->interrupt_request &= ~0x01;
-
-        tlb_flush(cpu);
-
-        /*
-         * loadvm has just updated the content of RAM, bypassing the
-         * usual mechanisms that ensure we flush TBs for writes to
-         * memory we've translated code from. So we must flush all TBs,
-         * which will now be stale.
-         */
-        tb_flush(cpu);
-    }
-#endif
-
-    return 0;
-}
-
-static int cpu_common_pre_load(void *opaque)
-{
-    CPUState *cpu = opaque;
-
-    cpu->exception_index = -1;
-
-    return 0;
-}
-
-static bool cpu_common_exception_index_needed(void *opaque)
-{
-    CPUState *cpu = opaque;
-
-    return tcg_enabled() && cpu->exception_index != -1;
-}
-
-static const VMStateDescription vmstate_cpu_common_exception_index = {
-    .name = "cpu_common/exception_index",
-    .version_id = 1,
-    .minimum_version_id = 1,
-    .needed = cpu_common_exception_index_needed,
-    .fields = (const VMStateField[]) {
-        VMSTATE_INT32(exception_index, CPUState),
-        VMSTATE_END_OF_LIST()
-    }
-};
-
-static bool cpu_common_crash_occurred_needed(void *opaque)
-{
-    CPUState *cpu = opaque;
-
-    return cpu->crash_occurred;
-}
-
-static const VMStateDescription vmstate_cpu_common_crash_occurred = {
-    .name = "cpu_common/crash_occurred",
-    .version_id = 1,
-    .minimum_version_id = 1,
-    .needed = cpu_common_crash_occurred_needed,
-    .fields = (const VMStateField[]) {
-        VMSTATE_BOOL(crash_occurred, CPUState),
-        VMSTATE_END_OF_LIST()
-    }
-};
-
-const VMStateDescription vmstate_cpu_common = {
-    .name = "cpu_common",
-    .version_id = 1,
-    .minimum_version_id = 1,
-    .pre_load = cpu_common_pre_load,
-    .post_load = cpu_common_post_load,
-    .fields = (const VMStateField[]) {
-        VMSTATE_UINT32(halted, CPUState),
-        VMSTATE_UINT32(interrupt_request, CPUState),
-        VMSTATE_END_OF_LIST()
-    },
-    .subsections = (const VMStateDescription * const []) {
-        &vmstate_cpu_common_exception_index,
-        &vmstate_cpu_common_crash_occurred,
-        NULL
-    }
-};
-#endif
-
 bool cpu_exec_realizefn(CPUState *cpu, Error **errp)
 {
     if (!accel_cpu_common_realize(cpu, errp)) {
@@ -139,33 +40,14 @@ bool cpu_exec_realizefn(CPUState *cpu, Error **errp)
     /* Wait until cpu initialization complete before exposing cpu. */
     cpu_list_add(cpu);
 
-#ifdef CONFIG_USER_ONLY
-    assert(qdev_get_vmsd(DEVICE(cpu)) == NULL ||
-           qdev_get_vmsd(DEVICE(cpu))->unmigratable);
-#else
-    if (qdev_get_vmsd(DEVICE(cpu)) == NULL) {
-        vmstate_register(NULL, cpu->cpu_index, &vmstate_cpu_common, cpu);
-    }
-    if (cpu->cc->sysemu_ops->legacy_vmsd != NULL) {
-        vmstate_register(NULL, cpu->cpu_index, cpu->cc->sysemu_ops->legacy_vmsd, cpu);
-    }
-#endif /* CONFIG_USER_ONLY */
+    cpu_vmstate_register(cpu);
 
     return true;
 }
 
 void cpu_exec_unrealizefn(CPUState *cpu)
 {
-#ifndef CONFIG_USER_ONLY
-    CPUClass *cc = CPU_GET_CLASS(cpu);
-
-    if (cc->sysemu_ops->legacy_vmsd != NULL) {
-        vmstate_unregister(NULL, cc->sysemu_ops->legacy_vmsd, cpu);
-    }
-    if (qdev_get_vmsd(DEVICE(cpu)) == NULL) {
-        vmstate_unregister(NULL, &vmstate_cpu_common, cpu);
-    }
-#endif
+    cpu_vmstate_unregister(cpu);
 
     cpu_list_remove(cpu);
     /*
diff --git a/hw/core/cpu-system.c b/hw/core/cpu-system.c
index 0520c362db4..3e1f60f23df 100644
--- a/hw/core/cpu-system.c
+++ b/hw/core/cpu-system.c
@@ -22,10 +22,21 @@
 #include "qapi/error.h"
 #include "exec/address-spaces.h"
 #include "exec/memory.h"
+#include "exec/tb-flush.h"
 #include "exec/tswap.h"
 #include "hw/qdev-core.h"
 #include "hw/qdev-properties.h"
 #include "hw/core/sysemu-cpu-ops.h"
+#include "migration/vmstate.h"
+#include "system/tcg.h"
+
+/*
+ * XXX this series plan is to be applied on top on my exec/cputlb rework series,
+ * then tlb_flush() won't be declared target-specific in exec-all.h.
+ * Meanwhile, declare locally.
+ * XXX
+ */
+void tlb_flush(CPUState *cs);
 
 bool cpu_paging_enabled(const CPUState *cpu)
 {
@@ -189,3 +200,115 @@ void cpu_exec_initfn(CPUState *cpu)
     cpu->memory = get_system_memory();
     object_ref(OBJECT(cpu->memory));
 }
+
+static int cpu_common_post_load(void *opaque, int version_id)
+{
+#ifdef CONFIG_TCG
+    if (tcg_enabled()) {
+        CPUState *cpu = opaque;
+
+        /*
+         * 0x01 was CPU_INTERRUPT_EXIT. This line can be removed when the
+         * version_id is increased.
+         */
+        cpu->interrupt_request &= ~0x01;
+
+        tlb_flush(cpu);
+
+        /*
+         * loadvm has just updated the content of RAM, bypassing the
+         * usual mechanisms that ensure we flush TBs for writes to
+         * memory we've translated code from. So we must flush all TBs,
+         * which will now be stale.
+         */
+        tb_flush(cpu);
+    }
+#endif
+
+    return 0;
+}
+
+static int cpu_common_pre_load(void *opaque)
+{
+    CPUState *cpu = opaque;
+
+    cpu->exception_index = -1;
+
+    return 0;
+}
+
+static bool cpu_common_exception_index_needed(void *opaque)
+{
+    CPUState *cpu = opaque;
+
+    return tcg_enabled() && cpu->exception_index != -1;
+}
+
+static const VMStateDescription vmstate_cpu_common_exception_index = {
+    .name = "cpu_common/exception_index",
+    .version_id = 1,
+    .minimum_version_id = 1,
+    .needed = cpu_common_exception_index_needed,
+    .fields = (const VMStateField[]) {
+        VMSTATE_INT32(exception_index, CPUState),
+        VMSTATE_END_OF_LIST()
+    }
+};
+
+static bool cpu_common_crash_occurred_needed(void *opaque)
+{
+    CPUState *cpu = opaque;
+
+    return cpu->crash_occurred;
+}
+
+static const VMStateDescription vmstate_cpu_common_crash_occurred = {
+    .name = "cpu_common/crash_occurred",
+    .version_id = 1,
+    .minimum_version_id = 1,
+    .needed = cpu_common_crash_occurred_needed,
+    .fields = (const VMStateField[]) {
+        VMSTATE_BOOL(crash_occurred, CPUState),
+        VMSTATE_END_OF_LIST()
+    }
+};
+
+const VMStateDescription vmstate_cpu_common = {
+    .name = "cpu_common",
+    .version_id = 1,
+    .minimum_version_id = 1,
+    .pre_load = cpu_common_pre_load,
+    .post_load = cpu_common_post_load,
+    .fields = (const VMStateField[]) {
+        VMSTATE_UINT32(halted, CPUState),
+        VMSTATE_UINT32(interrupt_request, CPUState),
+        VMSTATE_END_OF_LIST()
+    },
+    .subsections = (const VMStateDescription * const []) {
+        &vmstate_cpu_common_exception_index,
+        &vmstate_cpu_common_crash_occurred,
+        NULL
+    }
+};
+
+void cpu_vmstate_register(CPUState *cpu)
+{
+    if (qdev_get_vmsd(DEVICE(cpu)) == NULL) {
+        vmstate_register(NULL, cpu->cpu_index, &vmstate_cpu_common, cpu);
+    }
+    if (cpu->cc->sysemu_ops->legacy_vmsd != NULL) {
+        vmstate_register(NULL, cpu->cpu_index, cpu->cc->sysemu_ops->legacy_vmsd, cpu);
+    }
+}
+
+void cpu_vmstate_unregister(CPUState *cpu)
+{
+    CPUClass *cc = CPU_GET_CLASS(cpu);
+
+    if (cc->sysemu_ops->legacy_vmsd != NULL) {
+        vmstate_unregister(NULL, cc->sysemu_ops->legacy_vmsd, cpu);
+    }
+    if (qdev_get_vmsd(DEVICE(cpu)) == NULL) {
+        vmstate_unregister(NULL, &vmstate_cpu_common, cpu);
+    }
+}
diff --git a/hw/core/cpu-user.c b/hw/core/cpu-user.c
index cdd8de2fefa..1892acdee0f 100644
--- a/hw/core/cpu-user.c
+++ b/hw/core/cpu-user.c
@@ -10,6 +10,7 @@
 #include "hw/qdev-core.h"
 #include "hw/qdev-properties.h"
 #include "hw/core/cpu.h"
+#include "migration/vmstate.h"
 
 static const Property cpu_user_props[] = {
     /*
@@ -30,3 +31,14 @@ void cpu_exec_initfn(CPUState *cpu)
 {
     /* nothing to do */
 }
+
+void cpu_vmstate_register(CPUState *cpu)
+{
+    assert(qdev_get_vmsd(DEVICE(cpu)) == NULL ||
+           qdev_get_vmsd(DEVICE(cpu))->unmigratable);
+}
+
+void cpu_vmstate_unregister(CPUState *cpu)
+{
+    /* nothing to do */
+}
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 23 23:51:24 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 23:51:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876491.1286884 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6yq-000865-2S; Thu, 23 Jan 2025 23:51:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876491.1286884; Thu, 23 Jan 2025 23:51:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6yp-00085w-Uo; Thu, 23 Jan 2025 23:51:23 +0000
Received: by outflank-mailman (input) for mailman id 876491;
 Thu, 23 Jan 2025 23:51: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 <SRS0=QxCy=UP=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tb6tQ-0007w9-De
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 23:45:48 +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 2b751e45-d9e4-11ef-a0e5-8be0dac302b0;
 Fri, 24 Jan 2025 00:45:47 +0100 (CET)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-43618283dedso15517605e9.3
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 15:45:47 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438bd47f355sm7138595e9.4.2025.01.23.15.45.46
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 23 Jan 2025 15:45:46 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2b751e45-d9e4-11ef-a0e5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737675947; x=1738280747; 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=OmeiNXwxDOryj9Nk89BSf7ntmaAiV2ODrxL67LjT3oE=;
        b=Nbwi6evql1n75WRaVnKCPLltTihG5WWspsDkjKs3P3n/CiDGfATte5Si4TLL0NvgBr
         uSFr/j1ly5E+kLeI2htX8DdYgZhDtTXxA+H8d9SpVsaMrLsAV7fOybeDbkHdUxi6ygjr
         maw5oSA4G1SNNiak+QWPOkd/hBPAFd90GQwNHRkbvVzhIjdDcS4Jo+pNQ+lELXkIT0dh
         PyEHijOmVRt896CvKidiYv7uW+LhBC5mPiTm8+lxYDS9nRZhKeUbbhZ6H/3NqiHYXWRT
         Pv2Z8tFp/cCzfPyEF7+ipVf9p1dLwD5Wncv+ccm63SRl3fus1InbrXcFQVUovUKTLCNz
         AZrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737675947; x=1738280747;
        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=OmeiNXwxDOryj9Nk89BSf7ntmaAiV2ODrxL67LjT3oE=;
        b=O7PnIOU6RSxFDE+ICi8WBQ3f0dZF/wspV41jDrPRBNPI4LYonTqGv6cKet+hD96RCT
         RYLkbb9qrMXTwJgupQRP/452BdfAUGUFHoyf3NR/E6NYYlQHRYLpjmh/ALLrr7XqqaSn
         vaKSPHOuFDN5HkeukAD6uwZFcXHScjAvIiz8bqzxV6eT86Tz3nVO3bG2ibGcoAL2t1M1
         P5fFrKhnSDZ9fDUoW5GG68z1TuFF8vgkxIuNdo5WssIneiXrvwCmuf/t3qBFky5visTI
         EVuItF8E1GgnRWTMAh8F11Q/O0jX2D4K7f7qxpNYJmccDY8n5d4oIDoC62nBpivIUgDa
         OQNw==
X-Forwarded-Encrypted: i=1; AJvYcCX8PG5Rblywq4UgmYjz9+NCDD3a5B7X7BHiA74O4xlnOF0wazVd+KKfHbNh9R1HcdP6WM6LNsW1b5A=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxk+3AX0nF1PlcKgBAzkAXZ0ZT6Kkgh98d9X/pxKQJipIAZLWyJ
	gFpgLWMD+xSnaiUN3Lx0jAB+ZE8acVhd9o2vO3B6cSLlhkFYUOZQiQN6F+kyRH8=
X-Gm-Gg: ASbGncukU9s1TtRTE4M64BeRy1TFUQQyYfPlUCaiRzpYpMa1rFhwk9xFLraFL7VACXt
	W1Mutbw37Bn2RzSrbV13bv/XhGm61RV0gDcv6vBmP0l1tIwaTsOe/EjUwSdrIf21KJuVEja8Otu
	EP5kvJdXNTS5S2xEimmzhLNKhPKob0FeP1deurjd6l3u6XZZomVZO/CIFXn3B3YcYaBTzrpPwDY
	WO0mTFVlCPgjzxL1xniPAKKCn1HYbpBMU3V46Vme8IxdFKWTAGT7DMaifxorwgnbUm9fcJYzZ9G
	MA16Yznzbvwnhzr/x9pEDzfGmtnxMp0Ldpl5I2hsRWhUDW6+Z/6sisg=
X-Google-Smtp-Source: AGHT+IEFJ1SeJWoUW3YaXnTGBs2yrvL22hVEarb/siWyosLBI70zXEF7xcr/1TRnUm9/lQBURa7m3g==
X-Received: by 2002:a05:600c:1e18:b0:436:8a6f:b6db with SMTP id 5b1f17b1804b1-4389141c12emr225835175e9.22.1737675947213;
        Thu, 23 Jan 2025 15:45:47 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	qemu-arm@nongnu.org,
	Igor Mammedov <imammedo@redhat.com>,
	=?UTF-8?q?Alex=20Benn=C3=A9e?= <alex.bennee@linaro.org>,
	kvm@vger.kernel.org,
	qemu-ppc@nongnu.org,
	qemu-riscv@nongnu.org,
	David Hildenbrand <david@redhat.com>,
	qemu-s390x@nongnu.org,
	xen-devel@lists.xenproject.org,
	Richard Henderson <richard.henderson@linaro.org>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
Subject: [PATCH 16/20] cpus: Restrict cpu_common_post_load() code to TCG
Date: Fri, 24 Jan 2025 00:44:10 +0100
Message-ID: <20250123234415.59850-17-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250123234415.59850-1-philmd@linaro.org>
References: <20250123234415.59850-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

CPU_INTERRUPT_EXIT was removed in commit 3098dba01c7
("Use a dedicated function to request exit from execution
loop"), tlb_flush() and tb_flush() are related to TCG
accelerator.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 cpu-target.c | 33 +++++++++++++++++++--------------
 1 file changed, 19 insertions(+), 14 deletions(-)

diff --git a/cpu-target.c b/cpu-target.c
index a2999e7c3c0..c05ef1ff096 100644
--- a/cpu-target.c
+++ b/cpu-target.c
@@ -45,22 +45,27 @@
 #ifndef CONFIG_USER_ONLY
 static int cpu_common_post_load(void *opaque, int version_id)
 {
-    CPUState *cpu = opaque;
+#ifdef CONFIG_TCG
+    if (tcg_enabled()) {
+        CPUState *cpu = opaque;
 
-    /*
-     * 0x01 was CPU_INTERRUPT_EXIT. This line can be removed when the
-     * version_id is increased.
-     */
-    cpu->interrupt_request &= ~0x01;
-    tlb_flush(cpu);
+        /*
+         * 0x01 was CPU_INTERRUPT_EXIT. This line can be removed when the
+         * version_id is increased.
+         */
+        cpu->interrupt_request &= ~0x01;
 
-    /*
-     * loadvm has just updated the content of RAM, bypassing the
-     * usual mechanisms that ensure we flush TBs for writes to
-     * memory we've translated code from. So we must flush all TBs,
-     * which will now be stale.
-     */
-    tb_flush(cpu);
+        tlb_flush(cpu);
+
+        /*
+         * loadvm has just updated the content of RAM, bypassing the
+         * usual mechanisms that ensure we flush TBs for writes to
+         * memory we've translated code from. So we must flush all TBs,
+         * which will now be stale.
+         */
+        tb_flush(cpu);
+    }
+#endif
 
     return 0;
 }
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 23 23:51:24 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 23:51:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876492.1286888 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6yq-00088t-EK; Thu, 23 Jan 2025 23:51:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876492.1286888; Thu, 23 Jan 2025 23:51:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6yq-00088C-6T; Thu, 23 Jan 2025 23:51:24 +0000
Received: by outflank-mailman (input) for mailman id 876492;
 Thu, 23 Jan 2025 23:51: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 <SRS0=QxCy=UP=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tb6t4-0007w9-0j
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 23:45:26 +0000
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com
 [2a00:1450:4864:20::335])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1deee438-d9e4-11ef-a0e5-8be0dac302b0;
 Fri, 24 Jan 2025 00:45:25 +0100 (CET)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-4362bae4d7dso10798485e9.1
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 15:45:25 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438bd4fa416sm6932195e9.6.2025.01.23.15.45.23
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 23 Jan 2025 15:45:24 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1deee438-d9e4-11ef-a0e5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737675924; x=1738280724; 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=MdlpzTogAHHu3L1/GbHJ1cNEJlm92RpTH1AYDuj/6CU=;
        b=E/CYzjAolE2ZZSP2yfZBtY9ejZvn8LQqaLfaf5oZVlAG2O0Oiipu6hyie6XBz6g4nH
         pN3G5d4XeKS/q0jBWAJetK0jz9hy2vK/ATofWd3TztYIksLfuBO0uywEc3VNELzETNbt
         +YRKfRGZo4QIE5vlS4zPEezHn/Ku4/G+O3C1nLlx2KG/Bn9TbR/g3LsA0ol7+vsnofYT
         PeEaxvgul99KKn2PMIcfjPnDMLju6vbNfxOF3Zn09qHmArvGvbw6PHHwDLQjw72EFBAZ
         jIytylXYStR0gSpYBgAYyKlYBKEUMvbtpoCDqFY8RaI7fP2+K4gc+iIk/rETUVdEZlcR
         +qVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737675924; x=1738280724;
        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=MdlpzTogAHHu3L1/GbHJ1cNEJlm92RpTH1AYDuj/6CU=;
        b=K/etY77RdTZ9TspTkG4BHZN/vDT0D7XlKvRoGZryuvWcZvQkIJXbdj/4+kJtYeGEZR
         Q4QK6KBhmsuZqatbK2eJjgUE2e2Wk+axvMcXc0Xy7dTFPZtlDZipeu/B/a6NM9rXv7SO
         DR5yT07rcE1TbVJo+wWd2KF7T4t8tgIlHQQsVcG4Jj7dbTSNekb8EN+/8bTl64oWmgDE
         kgHs2Mvjj44dA1yfq+QnBr8umk/6vG4YiTvWelpjrj8GBm0uodiQVV30Y/Wh1vIADhzY
         QWKmG7wdt9bFa4FXamfSwmtuTff9mLrjiJL5xHCXambN/7I2xyPy5vrgTbBTAvXFmndW
         RiGQ==
X-Forwarded-Encrypted: i=1; AJvYcCUiiIalxGbOQYHuQwKKLqPRCH6IqAWWhOMu+WXKymMvoZBfLLQONFP7Knl+tiU0DEPbZI80dh4LX3I=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyMab9eMIaGviwKY1PX6rngN9wdMh2TvtjPO3YI6YE9ezPoKLmp
	UCU9v3Q3aBm7WsGCIANqZ87RFfS4zzS3eDi1siaeAfDGKq6J8uDhZeta2tXm1UE=
X-Gm-Gg: ASbGnctxDv58Wi0Wdu+C+kFC7Hi7H6rvQST5YtUaImBk/aKFpDPhTKYsr/TzIPuMoR5
	Iut3h2wllwK/klfiKbe2DTYE3X5oINynuik0E/oYmtLpgNEoeKc7qUtZsp2bKHvMaZz/1pZJR7C
	XELmQTPdDbp9LSn9Ke/QVAgHiAZhPmUWceuLl1MIEGznm0HIHxMg17lQ/cYZcwEU7LaUYkkxWPe
	5SnQDxXbwFKWg2lQde97rxf1rJ5WBwwCBjmheUGfMMB0NWYZXlnAeHCxZj4AyAZ7tuLO9vYxlC4
	WGz+stZbXdX5oVMIq8T8lJm2VdltJMzsDVeQshmNkFYIndNRG5ScR8o=
X-Google-Smtp-Source: AGHT+IEwKoXpxcAtZxGgBrKoty0PAI7DEzj3vUSJHkmHg5BnQeEwYri/vD7fXqCVh16ykXZTkiP5lQ==
X-Received: by 2002:a05:600c:1987:b0:436:faf1:9da with SMTP id 5b1f17b1804b1-438913c68ebmr255744445e9.2.1737675924510;
        Thu, 23 Jan 2025 15:45:24 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	qemu-arm@nongnu.org,
	Igor Mammedov <imammedo@redhat.com>,
	=?UTF-8?q?Alex=20Benn=C3=A9e?= <alex.bennee@linaro.org>,
	kvm@vger.kernel.org,
	qemu-ppc@nongnu.org,
	qemu-riscv@nongnu.org,
	David Hildenbrand <david@redhat.com>,
	qemu-s390x@nongnu.org,
	xen-devel@lists.xenproject.org,
	Richard Henderson <richard.henderson@linaro.org>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
Subject: [PATCH 12/20] accel/accel-cpu-target.h: Include missing 'cpu.h' header
Date: Fri, 24 Jan 2025 00:44:06 +0100
Message-ID: <20250123234415.59850-13-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250123234415.59850-1-philmd@linaro.org>
References: <20250123234415.59850-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

CPU_RESOLVING_TYPE is declared per target in "cpu.h". Include
it (along with "qom/object.h") to avoid when moving code around:

  include/accel/accel-cpu-target.h:26:50: error: expected ')'
     26 | DECLARE_CLASS_CHECKERS(AccelCPUClass, ACCEL_CPU, TYPE_ACCEL_CPU)
        |                                                  ^
  include/accel/accel-cpu-target.h:23:33: note: expanded from macro 'TYPE_ACCEL_CPU'
     23 | #define TYPE_ACCEL_CPU "accel-" CPU_RESOLVING_TYPE
        |                                 ^
  include/accel/accel-cpu-target.h:26:1: note: to match this '('
     26 | DECLARE_CLASS_CHECKERS(AccelCPUClass, ACCEL_CPU, TYPE_ACCEL_CPU)
        | ^
  include/qom/object.h:196:14: note: expanded from macro 'DECLARE_CLASS_CHECKERS'
    196 |     { return OBJECT_GET_CLASS(ClassType, obj, TYPENAME); } \
        |              ^
  include/qom/object.h:558:5: note: expanded from macro 'OBJECT_GET_CLASS'
    558 |     OBJECT_CLASS_CHECK(class, object_get_class(OBJECT(obj)), name)
        |     ^
  include/qom/object.h:544:74: note: expanded from macro 'OBJECT_CLASS_CHECK'
    544 |     ((class_type *)object_class_dynamic_cast_assert(OBJECT_CLASS(class), (name), \
        |                                                                          ^

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 include/accel/accel-cpu-target.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/accel/accel-cpu-target.h b/include/accel/accel-cpu-target.h
index 0a8e518600d..37dde7fae3e 100644
--- a/include/accel/accel-cpu-target.h
+++ b/include/accel/accel-cpu-target.h
@@ -20,6 +20,9 @@
  * subclasses in target/, or the accel implementation itself in accel/
  */
 
+#include "qom/object.h"
+#include "cpu.h"
+
 #define TYPE_ACCEL_CPU "accel-" CPU_RESOLVING_TYPE
 #define ACCEL_CPU_NAME(name) (name "-" TYPE_ACCEL_CPU)
 typedef struct AccelCPUClass AccelCPUClass;
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 23 23:51:25 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 23:51:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876495.1286904 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6yr-00009Y-Sr; Thu, 23 Jan 2025 23:51:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876495.1286904; Thu, 23 Jan 2025 23:51:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6yr-00008M-No; Thu, 23 Jan 2025 23:51:25 +0000
Received: by outflank-mailman (input) for mailman id 876495;
 Thu, 23 Jan 2025 23:51:24 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=QxCy=UP=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tb6tF-0007w9-42
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 23:45:37 +0000
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com
 [2a00:1450:4864:20::331])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 24aeb204-d9e4-11ef-a0e5-8be0dac302b0;
 Fri, 24 Jan 2025 00:45:36 +0100 (CET)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-4362f61757fso15535005e9.2
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 15:45:36 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438bd507d60sm6676495e9.18.2025.01.23.15.45.33
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 23 Jan 2025 15:45:34 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 24aeb204-d9e4-11ef-a0e5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737675936; x=1738280736; 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=QhTovaxYyVYo/iAlHiQi1CfSH3sOOBet2z8bCBrBkk0=;
        b=mfel7qfyKyl/E/IZ1YPIJc/5TClVjqBacIHQpsiXvBzya8GhqP2RXopkeVkondjWfg
         YnHRPEnusL3F/Gz7cxcrgrLaqJL8j0QjOWNbFMNlVCeSgI2v8edpfgFJUwNM/D0gHxLB
         Mc9I2GEN+nOnRlIVvFxuhVI7ZDr3P1zdFaBoNOBrZPHtFbAycj8Rll5PNQrVtnkjRmyj
         kfQohwcKBdualOPYcMP/n8BflnPZyNbnWv5dduASmo4EbeOXSdWn+ncJWuZE5FyCkG0J
         fCAfx9BW+7cAGUrS2bsqmQidhZ7w7W5QMqK5kCINvDM2d3WiTunxtdljrf1Pk4W5U/V0
         AxLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737675936; x=1738280736;
        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=QhTovaxYyVYo/iAlHiQi1CfSH3sOOBet2z8bCBrBkk0=;
        b=CjbkT8X/gs0YxfmVxmgdTY9+QIEt4hgXes9xBX2NygQztD3xMNCdg43Yt5VutNvrNU
         XNBRQ3DsitLXlLkOMbiIL0SyHaQ1yTKOmi3Ln8k+mtSxhPAlIEaiAP+YqexI/sXeqsxt
         5UqOPLeQrVpwDk3p0bIHBz6E0omXbf2BfmACIIiiqaq4hHGTCrGVHuCUz5mkhAcUagIs
         +Ye4mH2fQUAR7TU+wDlLGsyZllF2zfkAas2uO14m2Vn7/dYuGmOOnN00Cd61IuK91yJJ
         zULq94vtdk6Fu/P5Y18dni3wNXTVtvIHvhJSnkLn2VyE+AikB41WGhGMrZBBcfwBw+Hg
         Gtqw==
X-Forwarded-Encrypted: i=1; AJvYcCVMc02PLOo0GVW/9hFU7Pt9mx5HYy9d59n8pE1WSwF5X0ntxyaqBIlupillP1dClAyLm6UmPLf7/5c=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyo5RO2H2v/z/fJWXbXyttDdEd3/4bmf3qwLyS3JnHwIcNDB78N
	FoCqLLAwswU+ydfQdJFp48TgXIuBTNaJF6OfNz1MrjLgls2mvS9QcU5Ei3NPuN8=
X-Gm-Gg: ASbGncut8yu/6CVcjhO6wcXW9M0c0+huOoFcNa0NEKfTZqzJBTIIguQMc1AElYbAIXG
	9eQguBbbcLruxxoFkXHeNQx/ANyxIfjZwkF/MMR4cvVBR6/UvMLkYfdRFsyCJxRgI8Ai+CUI9vj
	FrzKsw0U0B7HqYeTbJH6AgPJfvbuJVQOEPFy9/xfzpd110m/LLpbfzzrVF0CMQ9v5aO7i8f2DTv
	rn3Qv5kvPf0+7vzlBGyj7jBfLMTuh2U4Wdd4ZCS7zS3nrzf9dD0EhQtEn8Ec7gRBkKf6en1c2eT
	BIvOhX4d1Yyc2gsyc2MObZdjGwq1ywZBlBX/emsOlPWaFXiLbqYngq4rlLFaJAwUrA==
X-Google-Smtp-Source: AGHT+IE1g5Lka6yaX7yxmvTjxCMF9sNPmOLsz1lyorKlxhPYpXBg1FExyYB9qYVhhui8O2rA+ot5eQ==
X-Received: by 2002:a05:600c:3b0a:b0:434:9c60:95a3 with SMTP id 5b1f17b1804b1-438913ca93cmr282415605e9.11.1737675935797;
        Thu, 23 Jan 2025 15:45:35 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	qemu-arm@nongnu.org,
	Igor Mammedov <imammedo@redhat.com>,
	=?UTF-8?q?Alex=20Benn=C3=A9e?= <alex.bennee@linaro.org>,
	kvm@vger.kernel.org,
	qemu-ppc@nongnu.org,
	qemu-riscv@nongnu.org,
	David Hildenbrand <david@redhat.com>,
	qemu-s390x@nongnu.org,
	xen-devel@lists.xenproject.org,
	Richard Henderson <richard.henderson@linaro.org>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
Subject: [PATCH 14/20] accel/tcg: Move cpu_memory_rw_debug() user implementation to user-exec.c
Date: Fri, 24 Jan 2025 00:44:08 +0100
Message-ID: <20250123234415.59850-15-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250123234415.59850-1-philmd@linaro.org>
References: <20250123234415.59850-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

cpu_memory_rw_debug() system implementation is defined in
system/physmem.c. Move the user one to accel/tcg/user-exec.c
to simplify cpu-target.c maintenance.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 accel/tcg/user-exec.c |  92 +++++++++++++++++++++++++++++++++++++
 cpu-target.c          | 102 +-----------------------------------------
 2 files changed, 94 insertions(+), 100 deletions(-)

diff --git a/accel/tcg/user-exec.c b/accel/tcg/user-exec.c
index c4454100ad7..e7e99a46087 100644
--- a/accel/tcg/user-exec.c
+++ b/accel/tcg/user-exec.c
@@ -19,6 +19,8 @@
 #include "qemu/osdep.h"
 #include "accel/tcg/cpu-ops.h"
 #include "disas/disas.h"
+#include "exec/vaddr.h"
+#include "exec/tswap.h"
 #include "exec/exec-all.h"
 #include "tcg/tcg.h"
 #include "qemu/bitops.h"
@@ -35,6 +37,7 @@
 #include "internal-common.h"
 #include "internal-target.h"
 #include "tb-internal.h"
+#include "qemu.h"
 
 __thread uintptr_t helper_retaddr;
 
@@ -969,6 +972,95 @@ static void *cpu_mmu_lookup(CPUState *cpu, vaddr addr,
     return ret;
 }
 
+/* physical memory access (slow version, mainly for debug) */
+int cpu_memory_rw_debug(CPUState *cpu, vaddr addr,
+                        void *ptr, size_t len, bool is_write)
+{
+    int flags;
+    vaddr l, page;
+    void * p;
+    uint8_t *buf = ptr;
+    ssize_t written;
+    int ret = -1;
+    int fd = -1;
+
+    while (len > 0) {
+        page = addr & TARGET_PAGE_MASK;
+        l = (page + TARGET_PAGE_SIZE) - addr;
+        if (l > len)
+            l = len;
+        flags = page_get_flags(page);
+        if (!(flags & PAGE_VALID)) {
+            goto out_close;
+        }
+        if (is_write) {
+            if (flags & PAGE_WRITE) {
+                /* XXX: this code should not depend on lock_user */
+                p = lock_user(VERIFY_WRITE, addr, l, 0);
+                if (!p) {
+                    goto out_close;
+                }
+                memcpy(p, buf, l);
+                unlock_user(p, addr, l);
+            } else {
+                /* Bypass the host page protection using ptrace. */
+                if (fd == -1) {
+                    fd = open("/proc/self/mem", O_WRONLY);
+                    if (fd == -1) {
+                        goto out;
+                    }
+                }
+                /*
+                 * If there is a TranslationBlock and we weren't bypassing the
+                 * host page protection, the memcpy() above would SEGV,
+                 * ultimately leading to page_unprotect(). So invalidate the
+                 * translations manually. Both invalidation and pwrite() must
+                 * be under mmap_lock() in order to prevent the creation of
+                 * another TranslationBlock in between.
+                 */
+                mmap_lock();
+                tb_invalidate_phys_range(addr, addr + l - 1);
+                written = pwrite(fd, buf, l,
+                                 (off_t)(uintptr_t)g2h_untagged(addr));
+                mmap_unlock();
+                if (written != l) {
+                    goto out_close;
+                }
+            }
+        } else if (flags & PAGE_READ) {
+            /* XXX: this code should not depend on lock_user */
+            p = lock_user(VERIFY_READ, addr, l, 1);
+            if (!p) {
+                goto out_close;
+            }
+            memcpy(buf, p, l);
+            unlock_user(p, addr, 0);
+        } else {
+            /* Bypass the host page protection using ptrace. */
+            if (fd == -1) {
+                fd = open("/proc/self/mem", O_RDONLY);
+                if (fd == -1) {
+                    goto out;
+                }
+            }
+            if (pread(fd, buf, l,
+                      (off_t)(uintptr_t)g2h_untagged(addr)) != l) {
+                goto out_close;
+            }
+        }
+        len -= l;
+        buf += l;
+        addr += l;
+    }
+    ret = 0;
+out_close:
+    if (fd != -1) {
+        close(fd);
+    }
+out:
+    return ret;
+}
+
 #include "ldst_atomicity.c.inc"
 
 static uint8_t do_ld1_mmu(CPUState *cpu, vaddr addr, MemOpIdx oi,
diff --git a/cpu-target.c b/cpu-target.c
index 20933bde7d4..6d8b7825746 100644
--- a/cpu-target.c
+++ b/cpu-target.c
@@ -19,18 +19,12 @@
 
 #include "qemu/osdep.h"
 #include "qapi/error.h"
-
-#include "exec/target_page.h"
-#include "exec/page-protection.h"
 #include "hw/qdev-core.h"
 #include "hw/qdev-properties.h"
 #include "qemu/error-report.h"
 #include "qemu/qemu-print.h"
 #include "migration/vmstate.h"
-#ifdef CONFIG_USER_ONLY
-#include "qemu.h"
-#include "user/page-protection.h"
-#else
+#ifndef CONFIG_USER_ONLY
 #include "hw/core/sysemu-cpu-ops.h"
 #include "exec/address-spaces.h"
 #include "exec/memory.h"
@@ -38,16 +32,15 @@
 #include "system/accel-ops.h"
 #include "system/cpus.h"
 #include "system/tcg.h"
-#include "exec/tswap.h"
 #include "exec/replay-core.h"
 #include "exec/cpu-common.h"
 #include "exec/exec-all.h"
 #include "exec/tb-flush.h"
-#include "exec/translation-block.h"
 #include "exec/log.h"
 #include "accel/accel-cpu-target.h"
 #include "trace/trace-root.h"
 #include "qemu/accel.h"
+#include "hw/core/cpu.h"
 
 #ifndef CONFIG_USER_ONLY
 static int cpu_common_post_load(void *opaque, int version_id)
@@ -367,97 +360,6 @@ void cpu_abort(CPUState *cpu, const char *fmt, ...)
     abort();
 }
 
-/* physical memory access (slow version, mainly for debug) */
-#if defined(CONFIG_USER_ONLY)
-int cpu_memory_rw_debug(CPUState *cpu, vaddr addr,
-                        void *ptr, size_t len, bool is_write)
-{
-    int flags;
-    vaddr l, page;
-    void * p;
-    uint8_t *buf = ptr;
-    ssize_t written;
-    int ret = -1;
-    int fd = -1;
-
-    while (len > 0) {
-        page = addr & TARGET_PAGE_MASK;
-        l = (page + TARGET_PAGE_SIZE) - addr;
-        if (l > len)
-            l = len;
-        flags = page_get_flags(page);
-        if (!(flags & PAGE_VALID)) {
-            goto out_close;
-        }
-        if (is_write) {
-            if (flags & PAGE_WRITE) {
-                /* XXX: this code should not depend on lock_user */
-                p = lock_user(VERIFY_WRITE, addr, l, 0);
-                if (!p) {
-                    goto out_close;
-                }
-                memcpy(p, buf, l);
-                unlock_user(p, addr, l);
-            } else {
-                /* Bypass the host page protection using ptrace. */
-                if (fd == -1) {
-                    fd = open("/proc/self/mem", O_WRONLY);
-                    if (fd == -1) {
-                        goto out;
-                    }
-                }
-                /*
-                 * If there is a TranslationBlock and we weren't bypassing the
-                 * host page protection, the memcpy() above would SEGV,
-                 * ultimately leading to page_unprotect(). So invalidate the
-                 * translations manually. Both invalidation and pwrite() must
-                 * be under mmap_lock() in order to prevent the creation of
-                 * another TranslationBlock in between.
-                 */
-                mmap_lock();
-                tb_invalidate_phys_range(addr, addr + l - 1);
-                written = pwrite(fd, buf, l,
-                                 (off_t)(uintptr_t)g2h_untagged(addr));
-                mmap_unlock();
-                if (written != l) {
-                    goto out_close;
-                }
-            }
-        } else if (flags & PAGE_READ) {
-            /* XXX: this code should not depend on lock_user */
-            p = lock_user(VERIFY_READ, addr, l, 1);
-            if (!p) {
-                goto out_close;
-            }
-            memcpy(buf, p, l);
-            unlock_user(p, addr, 0);
-        } else {
-            /* Bypass the host page protection using ptrace. */
-            if (fd == -1) {
-                fd = open("/proc/self/mem", O_RDONLY);
-                if (fd == -1) {
-                    goto out;
-                }
-            }
-            if (pread(fd, buf, l,
-                      (off_t)(uintptr_t)g2h_untagged(addr)) != l) {
-                goto out_close;
-            }
-        }
-        len -= l;
-        buf += l;
-        addr += l;
-    }
-    ret = 0;
-out_close:
-    if (fd != -1) {
-        close(fd);
-    }
-out:
-    return ret;
-}
-#endif
-
 bool target_words_bigendian(void)
 {
     return TARGET_BIG_ENDIAN;
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 23 23:51:29 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 23:51:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876499.1286914 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6yv-0000cR-3C; Thu, 23 Jan 2025 23:51:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876499.1286914; Thu, 23 Jan 2025 23:51:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6yu-0000cI-Vi; Thu, 23 Jan 2025 23:51:28 +0000
Received: by outflank-mailman (input) for mailman id 876499;
 Thu, 23 Jan 2025 23:51:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=QxCy=UP=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tb6sh-0007w9-Aj
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 23:45:03 +0000
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com
 [2a00:1450:4864:20::32b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1079a1c2-d9e4-11ef-a0e5-8be0dac302b0;
 Fri, 24 Jan 2025 00:45:02 +0100 (CET)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-43618283d48so10963145e9.1
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 15:45:02 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438bd54c0ecsm6510925e9.30.2025.01.23.15.44.59
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 23 Jan 2025 15:45:00 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1079a1c2-d9e4-11ef-a0e5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737675902; x=1738280702; 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=b+Ptx+X+/4qytTYw1NRizSw3Es7j283R5duCMBs45So=;
        b=mSzCu3lsl75ZqdOh0twGW/TNRGMSM3RWoRNV4JR7lgge4dQNaPn5y+lgv85xHieIAc
         XoMD7CRZ15lQ6ahBDwRmoQc1GOYISZy+b9temlutfQp6sHmAGHYF5qIHqjmRtdXjpH4d
         7wKBRHsK6C5C0azG6HyFsDXToFnIIdk70V/yNIspNp8dcRDheMUn1tpMWiVHiH1EoWRH
         TBq7a268T/izZqClkzGfCUmTPKvXDJTJ6JUmUYOQ1NCGuRhNKKJyicYhApq87VNra0QT
         AppVm8Cn2Snvo8raY7f8t7ZqDE86mqk7sAEwTaEOnxC0lmrJav/DVacwIc9jTd0afizo
         xI5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737675902; x=1738280702;
        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=b+Ptx+X+/4qytTYw1NRizSw3Es7j283R5duCMBs45So=;
        b=BAdAP0vXXlhcKr5K38O1NexrgGgxQtLK9Zob78jnZlq9Ps9sVrebzh6StSlnKY1COv
         Y8ulVYyCTvzfAXuXi5SiQdJ/Kn9VMzK6p/mz8zDBXnBTSPKHL7ZtF7s2ABeuWyXp2zv2
         3/GcKvTvguYML7nMbcdFLNT6A0dvvNJVPPdwY18fs+TZaSbkNmUARCH780SkyofSLmvB
         uepSKETOKzgRLyJ3jwZNdi1svde3Tw7mh6Zbkcnot1ly70C+9GuAVWY8NqfUODzm51Tj
         jBzU6ExuHeXJsFj9AS8GF6j/Fkyns2T0/MUqdrP1r+UooyLuoWCaaP6fZzA2Mslt6yL2
         ww3w==
X-Forwarded-Encrypted: i=1; AJvYcCWX7O+4S+DHF0408oNgYdSI6mN7k1Hg0isovkswvNRQOY3im69UORYF7K+/AGQvFEH7CrQlhF909xM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzYD7QHxNdJYIQ6KfaD5Tghc9AvDIVzfiQ8RnJ15hFzGI2UW7r1
	vvRk8M40JKgvheiL8QQIxqqV4uDsVnC9J82+fWlwbbUGPT71EY/voIobyrpi298=
X-Gm-Gg: ASbGncttx/aYY87k5B5GnUqRZpG/wPWHZBo5qGr2M2Jb532UagM5o39/OgWha5QZCUh
	R3WEsAk6uVmuPmmuzbvCRiJ+tk3+Dsm2MfJwxRtck2FW5sQzArjxySUiOqVfOzPxBK0bre1MyAn
	MPcAwMdiwl+dHNSWFZfmGggy96x4L7tcRoQDVy1+JIG+Yk6s8vT4tka3SDphvU/rRptc/9D9ak+
	siwuLJ0hqQNEx9mQBv6NRkXk2koiE9vfqFJotZwakFsF0FkcFRLJWU5dfL59KMmR9LhjAF9F1nr
	vaZresfuzXr7Z9jNv/1mNEE99zHfyc1xlnZIsmJ0Cx1ZNIUzxen1GqU=
X-Google-Smtp-Source: AGHT+IGYKHSOUWuv3Z35/L1kDcj+xko6P82ABEfwOu6IFt4mwFRNrLSNCMYz6YlSXtAKxKsobnoAmQ==
X-Received: by 2002:a05:600c:46ca:b0:434:a367:2bd9 with SMTP id 5b1f17b1804b1-438913dfd7fmr310320675e9.14.1737675901922;
        Thu, 23 Jan 2025 15:45:01 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	qemu-arm@nongnu.org,
	Igor Mammedov <imammedo@redhat.com>,
	=?UTF-8?q?Alex=20Benn=C3=A9e?= <alex.bennee@linaro.org>,
	kvm@vger.kernel.org,
	qemu-ppc@nongnu.org,
	qemu-riscv@nongnu.org,
	David Hildenbrand <david@redhat.com>,
	qemu-s390x@nongnu.org,
	xen-devel@lists.xenproject.org,
	Richard Henderson <richard.henderson@linaro.org>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>,
	Pierrick Bouvier <pierrick.bouvier@linaro.org>
Subject: [PATCH 08/20] accel/tcg: Restrict tlb_init() / destroy() to TCG
Date: Fri, 24 Jan 2025 00:44:02 +0100
Message-ID: <20250123234415.59850-9-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250123234415.59850-1-philmd@linaro.org>
References: <20250123234415.59850-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Move CPU TLB related methods to accel/tcg/ scope,
in "internal-common.h".

Suggested-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 accel/tcg/internal-common.h | 11 +++++++++++
 include/exec/exec-all.h     | 16 ----------------
 accel/tcg/user-exec-stub.c  | 11 +++++++++++
 3 files changed, 22 insertions(+), 16 deletions(-)

diff --git a/accel/tcg/internal-common.h b/accel/tcg/internal-common.h
index c8d714256cb..d3186721839 100644
--- a/accel/tcg/internal-common.h
+++ b/accel/tcg/internal-common.h
@@ -53,6 +53,17 @@ TranslationBlock *tb_link_page(TranslationBlock *tb);
 void cpu_restore_state_from_tb(CPUState *cpu, TranslationBlock *tb,
                                uintptr_t host_pc);
 
+/**
+ * tlb_init - initialize a CPU's TLB
+ * @cpu: CPU whose TLB should be initialized
+ */
+void tlb_init(CPUState *cpu);
+/**
+ * tlb_destroy - destroy a CPU's TLB
+ * @cpu: CPU whose TLB should be destroyed
+ */
+void tlb_destroy(CPUState *cpu);
+
 bool tcg_exec_realizefn(CPUState *cpu, Error **errp);
 void tcg_exec_unrealizefn(CPUState *cpu);
 
diff --git a/include/exec/exec-all.h b/include/exec/exec-all.h
index d9045c9ac4c..8eb0df48f94 100644
--- a/include/exec/exec-all.h
+++ b/include/exec/exec-all.h
@@ -29,16 +29,6 @@
 
 #if !defined(CONFIG_USER_ONLY) && defined(CONFIG_TCG)
 /* cputlb.c */
-/**
- * tlb_init - initialize a CPU's TLB
- * @cpu: CPU whose TLB should be initialized
- */
-void tlb_init(CPUState *cpu);
-/**
- * tlb_destroy - destroy a CPU's TLB
- * @cpu: CPU whose TLB should be destroyed
- */
-void tlb_destroy(CPUState *cpu);
 /**
  * tlb_flush_page:
  * @cpu: CPU whose TLB should be flushed
@@ -223,12 +213,6 @@ void tlb_set_page(CPUState *cpu, vaddr addr,
                   hwaddr paddr, int prot,
                   int mmu_idx, vaddr size);
 #else
-static inline void tlb_init(CPUState *cpu)
-{
-}
-static inline void tlb_destroy(CPUState *cpu)
-{
-}
 static inline void tlb_flush_page(CPUState *cpu, vaddr addr)
 {
 }
diff --git a/accel/tcg/user-exec-stub.c b/accel/tcg/user-exec-stub.c
index 4fbe2dbdc88..1d52f48226a 100644
--- a/accel/tcg/user-exec-stub.c
+++ b/accel/tcg/user-exec-stub.c
@@ -1,6 +1,7 @@
 #include "qemu/osdep.h"
 #include "hw/core/cpu.h"
 #include "exec/replay-core.h"
+#include "internal-common.h"
 
 void cpu_resume(CPUState *cpu)
 {
@@ -18,6 +19,16 @@ void cpu_exec_reset_hold(CPUState *cpu)
 {
 }
 
+/* User mode emulation does not support softmmu yet.  */
+
+void tlb_init(CPUState *cpu)
+{
+}
+
+void tlb_destroy(CPUState *cpu)
+{
+}
+
 /* User mode emulation does not support record/replay yet.  */
 
 bool replay_exception(void)
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 23 23:51:30 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 23:51:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876501.1286924 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6yw-0000uB-Da; Thu, 23 Jan 2025 23:51:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876501.1286924; Thu, 23 Jan 2025 23:51:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6yw-0000tK-9C; Thu, 23 Jan 2025 23:51:30 +0000
Received: by outflank-mailman (input) for mailman id 876501;
 Thu, 23 Jan 2025 23:51:28 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=QxCy=UP=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tb6tX-0007hN-Pb
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 23:45:55 +0000
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com
 [2a00:1450:4864:20::333])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2f406e78-d9e4-11ef-99a4-01e77a169b0f;
 Fri, 24 Jan 2025 00:45:54 +0100 (CET)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-436341f575fso16147015e9.1
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 15:45:54 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438bd43cdbbsm7488805e9.0.2025.01.23.15.45.51
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 23 Jan 2025 15:45:52 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2f406e78-d9e4-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737675953; x=1738280753; 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=MvtCakZyrGCXwv1NUluQigNUDDDoRJgD07DKcxozaAI=;
        b=IdbepafowxlxzTKnGgOQ0vMfkH3kBJllrqugigxj6XZZNDgDlzNMC2rsWwESGnAVPl
         R+6JQN9hJz1jYaCTGSaiJH6dY84WaB/vdC4dDCMjTAeEUk011wLSUEn1dwGs++zLYcVs
         f40rQWfDhyuzONc6YHtP0apJIoxDiJfrAsFI2MijLSEJkS2j8e2px0ddp4ZMIgixl/5F
         kbj1wbeG3vi1zTz31QkGBHuB6CJ9JqPc7VJCz865xMwtXlU6Zd9lIsuGk3D+pdSLrWEh
         YpJFbB4gAzAAh8L4J8UsJJilafEpE2dFW0FAFOTOSiFG46V406FwgsIPkSTA3E+EOB9K
         vdpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737675953; x=1738280753;
        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=MvtCakZyrGCXwv1NUluQigNUDDDoRJgD07DKcxozaAI=;
        b=NbVKTBg/UdWqMaQ6RBangpy+R0jqxJ5Aj2r3LyKMzI9VFw2+cfYGVZ8l6Oald17UxL
         mjanCcU09IwnthS3O0nYUAfDtiMMAllbDOyv+mU+OG9QYE+0P5wuUaJPIahbOYQZlQsB
         MKu2HyU2uLNVdsSVUP8fi/FXJOcjTcD3EfpZFzZp2NEhWKkSwUxML4iJlFt8sX0P9wJT
         qRIHIDIfRWeKJM20XqBkH7+R1/URIluTFIZXf0zyPeQofN3MmOFY0538l6IA3l6mEqkR
         STSWoRhKNhxHT9M+SAOV17RjJs9vZ+9/UDsoxNAeZM2I9c8+frsjDt/fIfC09p3HAt7v
         UTCQ==
X-Forwarded-Encrypted: i=1; AJvYcCUyEfUb6rxUSfCPo3uFiCs8uiVUrWq/Hi4TN4RUUHaS76vBnb0mLLKS/gVc3cqnQKBMwgyDqpL3dM8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxdDvZa1yDr4GV54Z1OMyTg+JFzG949Z0CsF78jzIYiewoHOM0I
	vk/tHia5RqEj/9xtObe2UwXA+CUYvuT0i4uWu59yfztrcsip60lo0FNk233U4f4=
X-Gm-Gg: ASbGncsjyD0jPUhh/UYp2Tu+nLKJQmbf7J9O04jJqaqE8kCG9vyYyVbfahVGuyLRK5f
	IdxvM6BJ9zS5Z9AnClWsG3GjBxYqZOmqjQ3r6XbnbhpijPzeJYrnoEO6nYZy4icJYoJzssbdaqL
	aPwg1AQDOcmQjgOLsv7tPF9+HO4DJPjFwj2JdK350lGB/x4nFuEZZB3HcUO2A1hDWIGVPh/hBnY
	R1UF2APCwrPd4zX5IASE1wZwqqyv9TDOfqRjTE79aNP9R2/LgwmWfMPecAY6Gu4SBoRPOuRqINU
	qhqI14+iw7GcQE+EaTvdAfr4LskHR5i7Fz53gareS3AbXYqW8xVZ49Y=
X-Google-Smtp-Source: AGHT+IESHbhLNhi6WI+MIsv7kwcNIGaQJ9dXLlWxoyCR3XibduHPGVHiP0CzOiY9OItw0/7PMnFvyA==
X-Received: by 2002:a05:600c:1987:b0:434:f753:6012 with SMTP id 5b1f17b1804b1-438913f2f4emr282730315e9.17.1737675953608;
        Thu, 23 Jan 2025 15:45:53 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	qemu-arm@nongnu.org,
	Igor Mammedov <imammedo@redhat.com>,
	=?UTF-8?q?Alex=20Benn=C3=A9e?= <alex.bennee@linaro.org>,
	kvm@vger.kernel.org,
	qemu-ppc@nongnu.org,
	qemu-riscv@nongnu.org,
	David Hildenbrand <david@redhat.com>,
	qemu-s390x@nongnu.org,
	xen-devel@lists.xenproject.org,
	Richard Henderson <richard.henderson@linaro.org>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
Subject: [PATCH 17/20] cpus: Have cpu_class_init_props() per user / system emulation
Date: Fri, 24 Jan 2025 00:44:11 +0100
Message-ID: <20250123234415.59850-18-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250123234415.59850-1-philmd@linaro.org>
References: <20250123234415.59850-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Rather than maintaining a mix of system / user code for CPU
class properties, move system properties to cpu-system.c
and user ones to the new cpu-user.c unit.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 cpu-target.c         | 58 --------------------------------------------
 hw/core/cpu-system.c | 40 ++++++++++++++++++++++++++++++
 hw/core/cpu-user.c   | 27 +++++++++++++++++++++
 hw/core/meson.build  |  5 +++-
 4 files changed, 71 insertions(+), 59 deletions(-)
 create mode 100644 hw/core/cpu-user.c

diff --git a/cpu-target.c b/cpu-target.c
index c05ef1ff096..dff8c0747f9 100644
--- a/cpu-target.c
+++ b/cpu-target.c
@@ -19,15 +19,12 @@
 
 #include "qemu/osdep.h"
 #include "qapi/error.h"
-#include "hw/qdev-core.h"
-#include "hw/qdev-properties.h"
 #include "qemu/error-report.h"
 #include "qemu/qemu-print.h"
 #include "migration/vmstate.h"
 #ifndef CONFIG_USER_ONLY
 #include "hw/core/sysemu-cpu-ops.h"
 #include "exec/address-spaces.h"
-#include "exec/memory.h"
 #endif
 #include "system/accel-ops.h"
 #include "system/cpus.h"
@@ -179,61 +176,6 @@ void cpu_exec_unrealizefn(CPUState *cpu)
     accel_cpu_common_unrealize(cpu);
 }
 
-/*
- * This can't go in hw/core/cpu.c because that file is compiled only
- * once for both user-mode and system builds.
- */
-static const Property cpu_common_props[] = {
-#ifdef CONFIG_USER_ONLY
-    /*
-     * Create a property for the user-only object, so users can
-     * adjust prctl(PR_SET_UNALIGN) from the command-line.
-     * Has no effect if the target does not support the feature.
-     */
-    DEFINE_PROP_BOOL("prctl-unalign-sigbus", CPUState,
-                     prctl_unalign_sigbus, false),
-#else
-    /*
-     * Create a memory property for system CPU object, so users can
-     * wire up its memory.  The default if no link is set up is to use
-     * the system address space.
-     */
-    DEFINE_PROP_LINK("memory", CPUState, memory, TYPE_MEMORY_REGION,
-                     MemoryRegion *),
-#endif
-};
-
-#ifndef CONFIG_USER_ONLY
-static bool cpu_get_start_powered_off(Object *obj, Error **errp)
-{
-    CPUState *cpu = CPU(obj);
-    return cpu->start_powered_off;
-}
-
-static void cpu_set_start_powered_off(Object *obj, bool value, Error **errp)
-{
-    CPUState *cpu = CPU(obj);
-    cpu->start_powered_off = value;
-}
-#endif
-
-void cpu_class_init_props(DeviceClass *dc)
-{
-#ifndef CONFIG_USER_ONLY
-    ObjectClass *oc = OBJECT_CLASS(dc);
-
-    /*
-     * We can't use DEFINE_PROP_BOOL in the Property array for this
-     * property, because we want this to be settable after realize.
-     */
-    object_class_property_add_bool(oc, "start-powered-off",
-                                   cpu_get_start_powered_off,
-                                   cpu_set_start_powered_off);
-#endif
-
-    device_class_set_props(dc, cpu_common_props);
-}
-
 void cpu_exec_initfn(CPUState *cpu)
 {
 #ifndef CONFIG_USER_ONLY
diff --git a/hw/core/cpu-system.c b/hw/core/cpu-system.c
index 6aae28a349a..c63c984a803 100644
--- a/hw/core/cpu-system.c
+++ b/hw/core/cpu-system.c
@@ -20,7 +20,10 @@
 
 #include "qemu/osdep.h"
 #include "qapi/error.h"
+#include "exec/memory.h"
 #include "exec/tswap.h"
+#include "hw/qdev-core.h"
+#include "hw/qdev-properties.h"
 #include "hw/core/sysemu-cpu-ops.h"
 
 bool cpu_paging_enabled(const CPUState *cpu)
@@ -142,3 +145,40 @@ GuestPanicInformation *cpu_get_crash_info(CPUState *cpu)
     }
     return res;
 }
+
+static const Property cpu_system_props[] = {
+    /*
+     * Create a memory property for system CPU object, so users can
+     * wire up its memory.  The default if no link is set up is to use
+     * the system address space.
+     */
+    DEFINE_PROP_LINK("memory", CPUState, memory, TYPE_MEMORY_REGION,
+                     MemoryRegion *),
+};
+
+static bool cpu_get_start_powered_off(Object *obj, Error **errp)
+{
+    CPUState *cpu = CPU(obj);
+    return cpu->start_powered_off;
+}
+
+static void cpu_set_start_powered_off(Object *obj, bool value, Error **errp)
+{
+    CPUState *cpu = CPU(obj);
+    cpu->start_powered_off = value;
+}
+
+void cpu_class_init_props(DeviceClass *dc)
+{
+    ObjectClass *oc = OBJECT_CLASS(dc);
+
+    /*
+     * We can't use DEFINE_PROP_BOOL in the Property array for this
+     * property, because we want this to be settable after realize.
+     */
+    object_class_property_add_bool(oc, "start-powered-off",
+                                   cpu_get_start_powered_off,
+                                   cpu_set_start_powered_off);
+
+    device_class_set_props(dc, cpu_system_props);
+}
diff --git a/hw/core/cpu-user.c b/hw/core/cpu-user.c
new file mode 100644
index 00000000000..e5ccf6bf13a
--- /dev/null
+++ b/hw/core/cpu-user.c
@@ -0,0 +1,27 @@
+/*
+ * QEMU CPU model (user specific)
+ *
+ * Copyright (c) Linaro, Ltd.
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+
+#include "qemu/osdep.h"
+#include "hw/qdev-core.h"
+#include "hw/qdev-properties.h"
+#include "hw/core/cpu.h"
+
+static const Property cpu_user_props[] = {
+    /*
+     * Create a property for the user-only object, so users can
+     * adjust prctl(PR_SET_UNALIGN) from the command-line.
+     * Has no effect if the target does not support the feature.
+     */
+    DEFINE_PROP_BOOL("prctl-unalign-sigbus", CPUState,
+                     prctl_unalign_sigbus, false),
+};
+
+void cpu_class_init_props(DeviceClass *dc)
+{
+    device_class_set_props(dc, cpu_user_props);
+}
diff --git a/hw/core/meson.build b/hw/core/meson.build
index 65a1698ed1f..b5a545a0edd 100644
--- a/hw/core/meson.build
+++ b/hw/core/meson.build
@@ -46,4 +46,7 @@ system_ss.add(files(
   'vm-change-state-handler.c',
   'clock-vmstate.c',
 ))
-user_ss.add(files('qdev-user.c'))
+user_ss.add(files(
+  'cpu-user.c',
+  'qdev-user.c',
+))
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 23 23:51:31 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 23:51:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876503.1286929 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6yx-0000z8-0M; Thu, 23 Jan 2025 23:51:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876503.1286929; Thu, 23 Jan 2025 23:51:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6yw-0000y9-MI; Thu, 23 Jan 2025 23:51:30 +0000
Received: by outflank-mailman (input) for mailman id 876503;
 Thu, 23 Jan 2025 23:51:28 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=QxCy=UP=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tb6sz-0007hN-Q1
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 23:45:21 +0000
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com
 [2a00:1450:4864:20::32b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1b02e3f4-d9e4-11ef-99a4-01e77a169b0f;
 Fri, 24 Jan 2025 00:45:20 +0100 (CET)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-4361f796586so16011705e9.3
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 15:45:20 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438bd54c0f7sm6499935e9.28.2025.01.23.15.45.17
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 23 Jan 2025 15:45:18 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1b02e3f4-d9e4-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737675920; x=1738280720; 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=KLiVQy6/uYr9fS/vE5notUMei/mcFiOsSDRea34SIY0=;
        b=d0r20FJaOP8sF53di0wK8dZgus1XplMyHR0TD5DJ6D5EjB61yFz52RClr5HgjOvLG6
         3j+J2bKR7gIvn2R57HGQAUXvkOYSwuMo8yFGWfgRoNIfmx+187E6PJXlPYfqKXvj/7ab
         OF1GBXzednkjV8+DoJAZpSLPpJAdtV93TKOvOTwnAhFtpk4gxVw5S8sVXPDXv4iZVMDH
         gTNyEFMP06JChQB2ZwqqAUw40/RyGBpWjBJUmMoYboYJIq1I1CFjZ9BDib3XeyJ+a9FJ
         u9ieZRxYEqqdKd8xaGFMo18lPRma5a3NJPuvEGC/Cm49YbPwnvYI2f9qguWEZOqb/8eO
         qrLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737675920; x=1738280720;
        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=KLiVQy6/uYr9fS/vE5notUMei/mcFiOsSDRea34SIY0=;
        b=XwEUwY1FA6CNIapzmjMKNNMq74TB13IbK80ys0V0TfPzGK5i3zYFjg/WWOdhL4bDV9
         FBMXQ/8iPePXElQVFXRFMecaLuJoaLrT9X8z6Az8G2MNc16hqxYkSQr9IWzDet7X8CU+
         ys6B2TewxLH6izK8KhWEg+xh7ezDroJjptGWnqf1dLpQQsW97xdpgblcgx/Il+q1Hofo
         vj9J+D9uF5DFtsJf0npne7+eKJeNAvP/YnmYuKVqnfCd2kYG19G7so9/kb5DW1do9zSe
         KHwJn6rpEPFcg1Cz1SKRvQ/pBoyOmmVZS+oR5X0tef6Bovow8Qn2OtlATSf31HZfZZRK
         n8Cw==
X-Forwarded-Encrypted: i=1; AJvYcCU6cX61DFk9qK3d8jpEHIXIYsnEyzJ4oC5Hj4Vi1rASlllCjuPgcAC0prC50JQxih5k7zBQxvY2urM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwJ5dH5S41BKu8p7T+jyn3wAqtM8yZtAyglG6PR77sCK6pSNW6o
	HYn/BnDd3Gye5tiSiwQORKe9aGhIgmtZjFJtHIHL+dFGjuG6tKlUtbk2xUK2rkc=
X-Gm-Gg: ASbGnctHLGmw6pWPCn3q7m5198H/tn6ZD5SpQKBGamcj4CnAYWCnIh/hbJ5QDYS8goJ
	gzfBMrS72+dq8wlboLL3fa1sanuhbSIyx5gp8S/n53K/4fngHwilC7akl0rKJrlUExeaizpV8XW
	cE+e46IjrhUXQ5JeVKyQcfEh5lsr82yU2TjMlt+gWjzQRVWZzsml1wFhoJ5jcNU/xNwxZcwbZH5
	VQrYdaxUH8T8ixtIW+5A/WG6miLJ6eufIAKEr4Fxg6AqFzLDC14XEyuIi9Mddq6rr+JIL9zgVMm
	K8PjreX7uSH+/8rxW3C4E4XLe36q9cPUzr5xuuxzx76GEONy9Snlk+w=
X-Google-Smtp-Source: AGHT+IHCUhXEKn4F81kx6ZpXqs9faqGpJN5W9Mj/EUJJpXYvZE3+gYqYLTjnf0hJ5kDL6XLUxlFm9g==
X-Received: by 2002:a05:600c:1913:b0:434:f4fa:83c4 with SMTP id 5b1f17b1804b1-43891453fa7mr280858325e9.29.1737675919693;
        Thu, 23 Jan 2025 15:45:19 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	qemu-arm@nongnu.org,
	Igor Mammedov <imammedo@redhat.com>,
	=?UTF-8?q?Alex=20Benn=C3=A9e?= <alex.bennee@linaro.org>,
	kvm@vger.kernel.org,
	qemu-ppc@nongnu.org,
	qemu-riscv@nongnu.org,
	David Hildenbrand <david@redhat.com>,
	qemu-s390x@nongnu.org,
	xen-devel@lists.xenproject.org,
	Richard Henderson <richard.henderson@linaro.org>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
Subject: [PATCH 11/20] accel: Rename 'hw/core/accel-cpu.h' -> 'accel/accel-cpu-target.h'
Date: Fri, 24 Jan 2025 00:44:05 +0100
Message-ID: <20250123234415.59850-12-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250123234415.59850-1-philmd@linaro.org>
References: <20250123234415.59850-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

AccelCPUClass is for accelerator to initialize target specific
features of a vCPU. Not really related to hardware emulation,
rename "hw/core/accel-cpu.h" as "accel/accel-cpu-target.h"
(using the explicit -target suffix).

More importantly, target specific header often access the
target specific definitions which are in each target/FOO/cpu.h
header, usually included generically as "cpu.h" relative to
target/FOO/. However, there is already a "cpu.h" in hw/core/
which takes precedence. This change allows "accel-cpu-target.h"
to include a target "cpu.h".

Mechanical change doing:

 $  git mv include/hw/core/accel-cpu.h \
           include/accel/accel-cpu-target.h
 $  sed -i -e 's,hw/core/accel-cpu.h,accel/accel-cpu-target.h,' \
   $(git grep -l hw/core/accel-cpu.h)

and renaming header guard 'ACCEL_CPU_TARGET_H'.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 MAINTAINERS                                               | 2 +-
 include/{hw/core/accel-cpu.h => accel/accel-cpu-target.h} | 4 ++--
 accel/accel-target.c                                      | 2 +-
 cpu-target.c                                              | 2 +-
 target/i386/hvf/hvf-cpu.c                                 | 2 +-
 target/i386/kvm/kvm-cpu.c                                 | 2 +-
 target/i386/tcg/tcg-cpu.c                                 | 2 +-
 target/ppc/kvm.c                                          | 2 +-
 target/riscv/kvm/kvm-cpu.c                                | 2 +-
 target/riscv/tcg/tcg-cpu.c                                | 2 +-
 10 files changed, 11 insertions(+), 11 deletions(-)
 rename include/{hw/core/accel-cpu.h => accel/accel-cpu-target.h} (95%)

diff --git a/MAINTAINERS b/MAINTAINERS
index fa46d077d30..e4521852519 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -499,7 +499,7 @@ R: Paolo Bonzini <pbonzini@redhat.com>
 S: Maintained
 F: include/qemu/accel.h
 F: include/system/accel-*.h
-F: include/hw/core/accel-cpu.h
+F: include/accel/accel-cpu-target.h
 F: accel/accel-*.c
 F: accel/Makefile.objs
 F: accel/stubs/Makefile.objs
diff --git a/include/hw/core/accel-cpu.h b/include/accel/accel-cpu-target.h
similarity index 95%
rename from include/hw/core/accel-cpu.h
rename to include/accel/accel-cpu-target.h
index 24dad45ab9e..0a8e518600d 100644
--- a/include/hw/core/accel-cpu.h
+++ b/include/accel/accel-cpu-target.h
@@ -8,8 +8,8 @@
  * See the COPYING file in the top-level directory.
  */
 
-#ifndef ACCEL_CPU_H
-#define ACCEL_CPU_H
+#ifndef ACCEL_CPU_TARGET_H
+#define ACCEL_CPU_TARGET_H
 
 /*
  * This header is used to define new accelerator-specific target-specific
diff --git a/accel/accel-target.c b/accel/accel-target.c
index 08626c00c2d..09c1e1053e0 100644
--- a/accel/accel-target.c
+++ b/accel/accel-target.c
@@ -27,7 +27,7 @@
 #include "qemu/accel.h"
 
 #include "cpu.h"
-#include "hw/core/accel-cpu.h"
+#include "accel/accel-cpu-target.h"
 
 #ifndef CONFIG_USER_ONLY
 #include "accel-system.h"
diff --git a/cpu-target.c b/cpu-target.c
index 75501a909df..f97f3a14751 100644
--- a/cpu-target.c
+++ b/cpu-target.c
@@ -44,7 +44,7 @@
 #include "exec/tb-flush.h"
 #include "exec/translation-block.h"
 #include "exec/log.h"
-#include "hw/core/accel-cpu.h"
+#include "accel/accel-cpu-target.h"
 #include "trace/trace-root.h"
 #include "qemu/accel.h"
 
diff --git a/target/i386/hvf/hvf-cpu.c b/target/i386/hvf/hvf-cpu.c
index 560b5a05940..b5f4c80028f 100644
--- a/target/i386/hvf/hvf-cpu.c
+++ b/target/i386/hvf/hvf-cpu.c
@@ -14,7 +14,7 @@
 #include "system/system.h"
 #include "hw/boards.h"
 #include "system/hvf.h"
-#include "hw/core/accel-cpu.h"
+#include "accel/accel-cpu-target.h"
 #include "hvf-i386.h"
 
 static void hvf_cpu_max_instance_init(X86CPU *cpu)
diff --git a/target/i386/kvm/kvm-cpu.c b/target/i386/kvm/kvm-cpu.c
index 1bda403f88b..6269fa80452 100644
--- a/target/i386/kvm/kvm-cpu.c
+++ b/target/i386/kvm/kvm-cpu.c
@@ -15,7 +15,7 @@
 #include "hw/boards.h"
 
 #include "kvm_i386.h"
-#include "hw/core/accel-cpu.h"
+#include "accel/accel-cpu-target.h"
 
 static void kvm_set_guest_phys_bits(CPUState *cs)
 {
diff --git a/target/i386/tcg/tcg-cpu.c b/target/i386/tcg/tcg-cpu.c
index f09ee813ac9..b8aff825eec 100644
--- a/target/i386/tcg/tcg-cpu.c
+++ b/target/i386/tcg/tcg-cpu.c
@@ -21,7 +21,7 @@
 #include "cpu.h"
 #include "helper-tcg.h"
 #include "qemu/accel.h"
-#include "hw/core/accel-cpu.h"
+#include "accel/accel-cpu-target.h"
 #include "exec/translation-block.h"
 
 #include "tcg-cpu.h"
diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
index 966c2c65723..216638dee40 100644
--- a/target/ppc/kvm.c
+++ b/target/ppc/kvm.c
@@ -49,7 +49,7 @@
 #include "elf.h"
 #include "system/kvm_int.h"
 #include "system/kvm.h"
-#include "hw/core/accel-cpu.h"
+#include "accel/accel-cpu-target.h"
 
 #include CONFIG_DEVICES
 
diff --git a/target/riscv/kvm/kvm-cpu.c b/target/riscv/kvm/kvm-cpu.c
index 23ce7793594..7e4443c5bda 100644
--- a/target/riscv/kvm/kvm-cpu.c
+++ b/target/riscv/kvm/kvm-cpu.c
@@ -32,7 +32,7 @@
 #include "system/kvm_int.h"
 #include "cpu.h"
 #include "trace.h"
-#include "hw/core/accel-cpu.h"
+#include "accel/accel-cpu-target.h"
 #include "hw/pci/pci.h"
 #include "exec/memattrs.h"
 #include "exec/address-spaces.h"
diff --git a/target/riscv/tcg/tcg-cpu.c b/target/riscv/tcg/tcg-cpu.c
index e40c8e85b26..79345e4b89d 100644
--- a/target/riscv/tcg/tcg-cpu.c
+++ b/target/riscv/tcg/tcg-cpu.c
@@ -30,7 +30,7 @@
 #include "qemu/accel.h"
 #include "qemu/error-report.h"
 #include "qemu/log.h"
-#include "hw/core/accel-cpu.h"
+#include "accel/accel-cpu-target.h"
 #include "accel/tcg/cpu-ops.h"
 #include "tcg/tcg.h"
 #ifndef CONFIG_USER_ONLY
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 23 23:51:37 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Jan 2025 23:51:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876510.1286945 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6z2-0001sy-FH; Thu, 23 Jan 2025 23:51:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876510.1286945; Thu, 23 Jan 2025 23:51:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tb6z2-0001si-9D; Thu, 23 Jan 2025 23:51:36 +0000
Received: by outflank-mailman (input) for mailman id 876510;
 Thu, 23 Jan 2025 23:51:35 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=QxCy=UP=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tb6tM-0007hN-Cb
 for xen-devel@lists.xenproject.org; Thu, 23 Jan 2025 23:45:44 +0000
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com
 [2a00:1450:4864:20::433])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 287cc262-d9e4-11ef-99a4-01e77a169b0f;
 Fri, 24 Jan 2025 00:45:42 +0100 (CET)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-385de9f789cso1183751f8f.2
 for <xen-devel@lists.xenproject.org>; Thu, 23 Jan 2025 15:45:42 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38c2a1bad87sm971133f8f.74.2025.01.23.15.45.39
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 23 Jan 2025 15:45:40 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 287cc262-d9e4-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737675942; x=1738280742; 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=GOf7cXhzVFnELwvvE/9oD0dVEdIwULgdsVx2rdQEX18=;
        b=UjpOKTqFMt9XT+aoip/pjX329ZtQSOIaPeKr0YHIr7ui8vdtiEoKHcxM5Rsz+plUzH
         /vPRYrvsEMUZrA34aJSUmWyYOXyNz28Ji7F5BEM2ReIipdND5Fy5ABgeLFX4WCTtmO4+
         zFQCUmCgeIf6pSxkEBmav88beevHst7D1k8xSZ75loTV1xXozuZn/5DiWcgj7gFdAwHk
         pA08ebhwX7VoHpQBHMvW5sIY84ygXcI17VUasocIq4bo4nFv9/fow0owd25gcibnLmfY
         n6Hx5K06B3xfC+79Yh4vstczdgBDksBNiNjpFSSIAOaxQG8aPzNEyjBHEybAkuCZ1FZb
         fYwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737675942; x=1738280742;
        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=GOf7cXhzVFnELwvvE/9oD0dVEdIwULgdsVx2rdQEX18=;
        b=Qh7NuHSVOl2jGe4kY9CuB/K0/j3X3Ns+nIzGUGcgjBUYeNHf+hd5yO+M0hB8UdJBzt
         Rsa1ohNViqc9W4tvGRDnE7zSBYkXHaZ/KvNCktNrM5rRr8MFuwRMNLCZxOduIKBNrmgR
         ikYOWcp6VxnFXv9tZ0j/qEr6LvjRNIDowhsn43ocoA6ZIfiXuPfw8XPxms7WDHwq3sMr
         uYlgUeiiejJs7uyutUrhu6GCrCZWDTMDr/5U4mP8PszxZRQlqJhixN+yuyr0/s11vyy0
         ZPk5D1dZSkvWAqu6uXETqU17U+CbVT/1gm/tjSFecCjwmK7HRfyv3/SgSxPIVhHteeYq
         ODxQ==
X-Forwarded-Encrypted: i=1; AJvYcCWUxWF5lp3vb/U4DOZeB48Rhu/gs2hqFFoSUkocVOZ4wGdCsKHKA3rOo6XKLOusYNT9S3yoTUMKwBc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxgwBK8a12ROh4NxXH27r/JJLPRSpjJ2fOdQs6lW8k1fuJLit/G
	UBwukAMmQMVK2SaQd89aXqsXAi0jzallEESA9cOxus1stIY8H0zhPplxws8Dz3c=
X-Gm-Gg: ASbGncuUYByADoZLlxo/aexeUICBe5Rt1OPskO4yQKeuXGIwUjr2iWsfeK9D1KpxKxY
	GuDj8AWRiU/5m37C/maroJ4NtvPdsVyrNGe64fsB5fPK9vTHZa/EwnBjZGXlPghZ8E7mOGunnqY
	1O541/tWLxlXMCfTGCGcaCZZw7Nf5ZhYWuTousqYmbgENAvE7nPZzS9pgKviDQjdeIb7D+WFg+o
	FWU15QtgB0ngZGfxsewaex4poSdTa6S17OHzaVgcRp9pqf9xC4r9tY7+bo5R/cOG4laYoTZ9AW9
	z7cSwCxgex2wcM6BlMVNN03ebsjajRl6L6CHg5+p0DYyvW6dqdcq8CI=
X-Google-Smtp-Source: AGHT+IFFvdlRkBEFpuvRapz+0/bX2s0BjBYZ6M4itb1IiIpdMWapxxpC9ppUNuB95mK5m+Q7pE4GZw==
X-Received: by 2002:a5d:47c9:0:b0:385:fb56:5596 with SMTP id ffacd0b85a97d-38bf5663956mr20431872f8f.19.1737675942270;
        Thu, 23 Jan 2025 15:45:42 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	qemu-arm@nongnu.org,
	Igor Mammedov <imammedo@redhat.com>,
	=?UTF-8?q?Alex=20Benn=C3=A9e?= <alex.bennee@linaro.org>,
	kvm@vger.kernel.org,
	qemu-ppc@nongnu.org,
	qemu-riscv@nongnu.org,
	David Hildenbrand <david@redhat.com>,
	qemu-s390x@nongnu.org,
	xen-devel@lists.xenproject.org,
	Richard Henderson <richard.henderson@linaro.org>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
Subject: [PATCH 15/20] cpus: Fix style in cpu-target.c
Date: Fri, 24 Jan 2025 00:44:09 +0100
Message-ID: <20250123234415.59850-16-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250123234415.59850-1-philmd@linaro.org>
References: <20250123234415.59850-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Fix style on code we are going to modify.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 cpu-target.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/cpu-target.c b/cpu-target.c
index 6d8b7825746..a2999e7c3c0 100644
--- a/cpu-target.c
+++ b/cpu-target.c
@@ -47,12 +47,15 @@ static int cpu_common_post_load(void *opaque, int version_id)
 {
     CPUState *cpu = opaque;
 
-    /* 0x01 was CPU_INTERRUPT_EXIT. This line can be removed when the
-       version_id is increased. */
+    /*
+     * 0x01 was CPU_INTERRUPT_EXIT. This line can be removed when the
+     * version_id is increased.
+     */
     cpu->interrupt_request &= ~0x01;
     tlb_flush(cpu);
 
-    /* loadvm has just updated the content of RAM, bypassing the
+    /*
+     * loadvm has just updated the content of RAM, bypassing the
      * usual mechanisms that ensure we flush TBs for writes to
      * memory we've translated code from. So we must flush all TBs,
      * which will now be stale.
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Fri Jan 24 04:57:20 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Jan 2025 04:57:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876592.1286954 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbBkd-0006lW-Gx; Fri, 24 Jan 2025 04:57:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876592.1286954; Fri, 24 Jan 2025 04:57:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbBkd-0006lP-EO; Fri, 24 Jan 2025 04:57:03 +0000
Received: by outflank-mailman (input) for mailman id 876592;
 Fri, 24 Jan 2025 04:57:02 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=AcjC=UQ=epam.com=Volodymyr_Babchuk@srs-se1.protection.inumbo.net>)
 id 1tbBkb-0006lJ-SR
 for xen-devel@lists.xenproject.org; Fri, 24 Jan 2025 04:57:02 +0000
Received: from AM0PR83CU005.outbound.protection.outlook.com
 (mail-westeuropeazlp170100000.outbound.protection.outlook.com
 [2a01:111:f403:c201::])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a4a2054c-da0f-11ef-a0e5-8be0dac302b0;
 Fri, 24 Jan 2025 05:56:59 +0100 (CET)
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 (2603:10a6:150:16a::21) by DB8PR03MB6186.eurprd03.prod.outlook.com
 (2603:10a6:10:142::11) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.19; Fri, 24 Jan
 2025 04:56:56 +0000
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e]) by GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e%6]) with mapi id 15.20.8377.009; Fri, 24 Jan 2025
 04:56:56 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a4a2054c-da0f-11ef-a0e5-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=FoKdGxdcnjjEFYZ4Vg2XAcB65wJUujXXeU1FYS87l6crxyMM2rAWolI6ab3u/aJc0e8MJh4cmrAU5EYaUC8royHBwGAFlOHkeGqV5ZbUFvt3ZFZYkzo2nNnsKd6o1Aqm0Gg5DGDbDNcX0WOMmh3XiXEJCDd79zyr5fhBraqFCb5RWtIZgaE+Q2E86iL+KCUqOtOEP4xixUgAC3dCXgRoINAdKGzA1SF1N7GH+joAE29mcDgP7fc3HZXlafjT6tkc5rjlvcj72tAf2J+AThQhLBtph2Vv8I2KTJ4Dbk5RWSr89dGljzMhpZt+rZstqxOt3JfBc/AykZuDSQ1et+zQOg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=3x2po5iIZxkhF3lNQ8hZ1PitGlGbpZrIAEqm5FTqO+s=;
 b=O0Q8DPMBWWaTnelKDwP/0eOIhp60l8viSPLxdApZArYsDEoDHdS0QZtqxWPpkdQirtM4Tf/lyEBIIDqDcP1j4vXrt0G4/Xjp31DWtgLBeLw/ULacrTIHFySG6A4aHfdb1/gs/p/V+DtRlpp6eLTZRnxuV6VjXNqRrsb4i1v8PQCY8BLNh6xMx7clnM5RHE2BE7rq0csNyyfQw4/+DZ2kcvGT3r2lHzjAi/jUtLuYl+8hyOdC1g46NMRbCorFWnt8D8Pkl0dZoB1cjW81n7ks5mGEfMb11UgpAAmhJKaIZoBhpoMKJLQ1NgFrvHlirHUELuCEPUZe42EDkwkN6WlJFA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=3x2po5iIZxkhF3lNQ8hZ1PitGlGbpZrIAEqm5FTqO+s=;
 b=nHVUUg3fMFBe+Bh/4WtmAKpfrzTN6LGocr1DcM6N58++o2A/NgafQ1mSwQfbWrXIuk1LgC0v+V/t+rMaBPfq7TWdAHgItQZP4CaY2sgyAjmJ8K6Wip2952e7Ckh6tZqKWK6XhFgWJrM4dE7zdt/YJmFDGH8HrUX29Kf1U5v09o1htQsPbJa7uPkfOuGhCB9GG5R1tBjA4fTxw5GfqAiCcsaUnGk2Sd9FfCF2iLIma7ETqJzl3nIBxIvsElVjLr8AWGbN9z39yzqqlJXgqMbdYVb5I9oj4dF4dNMJNIA4GxHsYiLZ4suVuAdD9aIveKM8vOlAVf77/yE/7INSOiWItA==
From: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
To: "L, John Preetham (893)" <john_preetham.l@daimlertruck.com>
CC: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: Request for Documentation on Bringing Up Xen on R-Car H3e
 (H3ULCB)
Thread-Topic: Request for Documentation on Bringing Up Xen on R-Car H3e
 (H3ULCB)
Thread-Index: AdtsrjaU74AF3fZpR/+NK9h56D1xZg==
Date: Fri, 24 Jan 2025 04:56:56 +0000
Message-ID: <87wmek24ix.fsf@epam.com>
References:
 <FR2PPF86245AF1B81D71CF27EE705ED09B7B8E12@FR2PPF86245AF1B.DEUP281.PROD.OUTLOOK.COM>
In-Reply-To:
 <FR2PPF86245AF1B81D71CF27EE705ED09B7B8E12@FR2PPF86245AF1B.DEUP281.PROD.OUTLOOK.COM>
	(John Preetham L.'s message of "Wed, 22 Jan 2025 09:16:06 +0000")
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=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: GV1PR03MB10456:EE_|DB8PR03MB6186:EE_
x-ms-office365-filtering-correlation-id: f719432c-5b12-47e4-107c-08dd3c338751
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?r6/KRtJuIRqM+zz7Slx5hXypWfioKDjbSXyKTbcdro5Ys2rUq9nWBtTI3w?=
 =?iso-8859-1?Q?JZi5F5/lczxCk6VXLqX1UlsNk5kAG6Re71RJrD2O3ylvfcC+dB/fS+JWWz?=
 =?iso-8859-1?Q?QYm0a5VuHcu63wvyh8yWfP4fK5jhccVeFYu0Ph2dpbkAmBb9AxUkrBvLBY?=
 =?iso-8859-1?Q?PtB3sXIKJSUz140ksVkF5wNkrVo0J8rqNbrYsg/D4eVVJqlsellCAAPh1j?=
 =?iso-8859-1?Q?NYbAkl2U1wflww5Po9a3mDHnVQBPK2EWgpT92+gHbGeWUN2Ewc7Xn8jF2K?=
 =?iso-8859-1?Q?sP/dSYAHZHvBaqbJKfDLSLLKEwYitG9KUqtYIVDnYK1qZWwcp7ZyMPQeMy?=
 =?iso-8859-1?Q?ulwPbwblxAoyu7TSUkyaox/WLZWZa5NgNyxo2nUzbLxbUBu9bccMNugFwq?=
 =?iso-8859-1?Q?ys+HDin4OG54JMVhqIlqQir5NqlHd9/e8yKPGSa8oNS5EdBKR/4ZlV7MNO?=
 =?iso-8859-1?Q?KF7dt8zqNXPp0aMbhvAz2AOJVbIa/82amTWY3nvno/agBQmTi+bw5Ouj4Z?=
 =?iso-8859-1?Q?ZGwcgggU+ntYqHjYG3owttzSaBaV4Qo15uUSHJuQ53E8PlOg2Irf6mFBaH?=
 =?iso-8859-1?Q?upAs+CIvdC47qi/oamvT7j6dwGeJMl+PgbQV/OwdNdGWI4Jwj1T7jjcqsq?=
 =?iso-8859-1?Q?0vbRRoVCfSJqtsOO98D+uEkcBIfHyLBdF7dR9gDmxP982rDR7vWLG/boc2?=
 =?iso-8859-1?Q?B2wnUSdPcJ3+cPg1bRDvsBiI9Ioc+hv0q1GMJsGZ7QyqoiXgQWzV/u8khH?=
 =?iso-8859-1?Q?3Sva5MZKNj4lkpTubohTcwLZ8p7eEA8lETYdH4LXWQ8frJYWQJDutjWuC3?=
 =?iso-8859-1?Q?dHKe1Mb4k5CA8IKp7jadhG2b/kJNmYEJvryBLuMEtcYQUkHaiPUmdEYr2+?=
 =?iso-8859-1?Q?CS+41QjqZ1AQ9KoawjflQgYwiQguapz7s7PsOQlOwhpO3j9f+hVVGXDYwt?=
 =?iso-8859-1?Q?irjb1gWDUAYIDGJidDpcD9CCdcx+QIpiJ9dC0hOz5ShQqeHwm+CBO84sfX?=
 =?iso-8859-1?Q?K+U4+Ul0xhVrC36YnZcpF6Va7NSAxBs8jO+9sBTc1uaE8QHF+AxRSiNmRj?=
 =?iso-8859-1?Q?6Q4QtQ5MqMyAti28v/XspQvXRp2oe/ebRxTQ+L0/iYTIe00C75NJtA4MxU?=
 =?iso-8859-1?Q?qJsmcx1T/t5hQIiD3N7fgMbGppPmfMGCHxFf+CczW/uCxsUX8O9UVbYfCg?=
 =?iso-8859-1?Q?hRwea1clwJ0T5UPUWGUaNwayIaSwZWGbr5izT1g3dkjdFJjm56rUz4K1Y/?=
 =?iso-8859-1?Q?J7V9Jom2vvDaYP1GIPKBYSQsPVPUxRWEVkttqNo+D8j1rUDk8Q3yLg/OZ+?=
 =?iso-8859-1?Q?Uqvrl5Nu7enLOrQLUOWECzDfLtBCq0RftAtObRXO1OJg7aWjLZCJ60BZpE?=
 =?iso-8859-1?Q?nn7h2BB3+qiS+GghjgKIzwMSQvZi9tVY7g4yG6v/FAvb1rEcs1EGQiPbAM?=
 =?iso-8859-1?Q?8b5Xlx0Zeb51ykWY?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR03MB10456.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?giKHnk3OyBAkAGfzyzZQuxsWtNCQc1kTaufBgfzXVnO5Lc8J7scKGXk7zx?=
 =?iso-8859-1?Q?06lVz/ISTYIZRthie3tNT89bWymHCqqBC8Z8Nb3Mqeepw5T48DSRmuobAQ?=
 =?iso-8859-1?Q?28s9FZCYi9uAxqZmnp1nduMbNr3xYCcgLK7EY1qREDhCB8DhA+Nkc8QxEJ?=
 =?iso-8859-1?Q?6tg4rgE6iDUOHoSmUsw+Eb6EBLhD27KLz+W+yA+NbSmjqBvZJv75N6+9++?=
 =?iso-8859-1?Q?t6kKvBeUTMFUe7vxXtJzvZRE9n81WYiNnQP6caI4ht+W35sp0nc6ZdGv/D?=
 =?iso-8859-1?Q?V9EMAQ8/6kft1IrlgVWaNyz7Ekr1Mrhw22Xo92PIzLoz8XDYsY2Caqciin?=
 =?iso-8859-1?Q?mTwxDIRymkRHhfpap0tMdWZwxgf5nsOGYQAdJOLNjX/KK8jCl1BjapjL4X?=
 =?iso-8859-1?Q?maucMk9BgV3RxC0m1/oLlTu/ulYpqw5KWhxP0BesHGLH2kAKSeUgigfGgZ?=
 =?iso-8859-1?Q?5A4aUeVlaqUey4x0cIWwwbCH1OoFd+8lscCcyO2HTvQ8hqensXA/kCpd0G?=
 =?iso-8859-1?Q?sIsSD6ubNniVRAgJCSVhXiUKQFCJZ7OJJi+XXRf+oroBUJGp7oISfyrB0g?=
 =?iso-8859-1?Q?rL8P0O2AC14PwKxtvRNrgoPN2wBBPA5PeM2wOXQ8votlxGOKIDaT3r6c6E?=
 =?iso-8859-1?Q?Uboljrv/UPtZHaD7hROPhMm0qSbaPIsM2F4G9B8vC2swTpWsMoIEnbahXR?=
 =?iso-8859-1?Q?rptvkbuKW7Lwp+6B7mzDq3GNjjDQG5WYzarFLCRdjT6LYeBLBVUgz9g7i3?=
 =?iso-8859-1?Q?bEVte92RK//a1NI18k5XS+3L7kQvyoKqiIPUGQ0pp/O8REoJPXUzUgWRym?=
 =?iso-8859-1?Q?m4UI6eqv4SZY9tmHnnq0wJltCSOpY5lWF+Gc+F2JVdssh+SFXyU88LsvGR?=
 =?iso-8859-1?Q?XlFf7FOw7cxihWQkEzrD6cA8TM6aP0CFLjewzTy/V/Mc0Sh/N8uJchUM10?=
 =?iso-8859-1?Q?s4IzC7GvD+6OdwgpZfGjE2RMqHG6pfmfStQD5OJkUzk2BNzll6qPM15T94?=
 =?iso-8859-1?Q?UbauHiIs1GB8AKYxmUBdTH/JSQ+vLvAUV8YmtwJSP68ulNRbzJT6s/oow4?=
 =?iso-8859-1?Q?c3Dl3Zwzr8GrekfDl4mlbrzmoTd/C2LuhtaizEesp96rqS5V5P6Df9fdZc?=
 =?iso-8859-1?Q?pVgYQo4cVdoBzVZx80o4qf2JypBRrob0RZrtHsbN/Z6/kfcfSdTz2zxaBw?=
 =?iso-8859-1?Q?/Xdp9iG3EPTzp3MMmJpSxuKN5DS8sOgL9l6hP4FynXuL1C+sZonbvf/KKS?=
 =?iso-8859-1?Q?Vxc2U1a1ssXxfF2GCTaCYOTyVaip89U6k916jaiuZ+jxJgBQ+VxKdq4M4P?=
 =?iso-8859-1?Q?fhB4j7zUx2OQkzuHFuSAUvHJBsAqpHyT+ljphMG9ZPZPf1NOgwqJJpx6pS?=
 =?iso-8859-1?Q?Fo4x6+a5vEBn8UH3OWHSwWsBfN75VhtM70nmAoCGaB7E7KttR2IS0shqx8?=
 =?iso-8859-1?Q?0Q/SbMuzH35ZJH3Y1Mw6zHbbHkjyJK1A1mWQaPmz/5sXTwCn+dMiC3Ot4j?=
 =?iso-8859-1?Q?qX2qmqIDt3Shhx+8oczASl718CRAe4l3w8mWalLuKyg+OGkY3NFEsXYzRs?=
 =?iso-8859-1?Q?btlbrENyvnlvf84q+QXtfnZxGsVyW85yTgojv0mxoq/Ql1FHjdeHXfe1Me?=
 =?iso-8859-1?Q?7rCXGU3DnxigLzvKwYnJfPQnv2hOERu4xI9q8TBPYFZTWQyDPTPtbNrg?=
 =?iso-8859-1?Q?=3D=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: GV1PR03MB10456.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f719432c-5b12-47e4-107c-08dd3c338751
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2025 04:56:56.7622
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: yqVEHbQyeLlZATL7WQ3+uCNg4ynPFGYdAfi8AMeFu77qAlCsCvkjrNgoDosS4ZTzH5FnUKtScnVXK6b3fbRDC7np2yH4cK/ve8kGOi0HXGQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR03MB6186


Hi John,

Sorry, I hit wrong "reply" button last time. So I'm re-sending this mail
with xen-devel ML included.

"L, John Preetham (893)" <john_preetham.l@daimlertruck.com> writes:

> Dear Xen Community,
>
> I hope this message finds you well.
>
> I am currently working on a project that involves bringing up Xen on the =
Renesas R-Car H3e (H3ULCB) platform. I am seeking guidance on
> where I can find the proper documentation for this process. Specifically,=
 I am looking for comprehensive documentation that covers everything
> from scratch to the end, including the required versions and any specific=
 configurations.
>
> Could anyone point me to the relevant resources or share any documentatio=
n that might be helpful?

Well, you can build all from the scratch. I can guide you through all
the steps if you wish. But I recommend you to try this approach first:

https://github.com/xen-troops/meta-xt-prod-devel-rcar

This will build you a full system with Xen and (multiple domains of you
want) on SD card image. Just follow the instruction in the
README.md. You can use this as a starting point and/or reference for
your own setup.

Just be aware that this approach will build you highly customized setup
with "thin" Dom0 and separate driver domain. But anyways, this is a good
start.

Alternatively, you start with official Renesas manual on building BSP:

https://elinux.org/R-Car/Boards/H3SK#Quick_Start_How_To

and then build on top of. But this will require many manual steps. On
other hand, this will give your much better understanding on what goes
on. There are two ways:

1. You can build Xen hypervisor separately, but you will have issues
with building Xen Tools for your dom0, as you will need to create and
install Yocto SDK and then resolve incompatibilities between Yocto SDK
and Xen's own build system.

2. Easier approach is to add meta-virtualization meta-layer to your BSP
and build Xen hypervisor together will toolstack using this meta-layer.

Apart from building Xen Hypervisor and Xen Tools you also need to:

1. Ensure that ARM-TF boots the system in EL2. There is a
Renesas-specific makefile option for that.

2a. Alter BSP device tree, so it can be used by Xen. You need to provide
IO-MMU mappings.  Sadly, Renesas does not provide them by default. We
have custom dtsi just for that:
https://github.com/xen-troops/meta-xt-prod-devel-rcar/blob/master/layers/me=
ta-xt-domd-gen3/recipes-kernel/linux/files/r8a77951-h3ulcb-4x2g-xen.dts

2b. Alter BSP device tree, so it can be used by Xen. Apart from IO-MMU
configuration you need to tell Xen where to look for module. You can use
ImageBuilder, mentioned by Stefano or do this by hand, like this:
https://github.com/xen-troops/meta-xt-rcar/blob/master/meta-xt-rcar-driver-=
domain/recipes-kernel/linux/files/pvr/xen-chosen.dtsi

3. Hide SCIF2 clock from Linux (or use "clk_ignore_unused" dom0 kernel
argument). Otherwise Dom0 will disable console during the boot.


--=20
WBR, Volodymyr=


From xen-devel-bounces@lists.xenproject.org Fri Jan 24 05:03:12 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Jan 2025 05:03:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876600.1286964 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbBqV-0000cr-54; Fri, 24 Jan 2025 05:03:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876600.1286964; Fri, 24 Jan 2025 05:03:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbBqV-0000ck-1F; Fri, 24 Jan 2025 05:03:07 +0000
Received: by outflank-mailman (input) for mailman id 876600;
 Fri, 24 Jan 2025 05:03:06 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=AcjC=UQ=epam.com=Volodymyr_Babchuk@srs-se1.protection.inumbo.net>)
 id 1tbBqU-0000cc-4y
 for xen-devel@lists.xenproject.org; Fri, 24 Jan 2025 05:03:06 +0000
Received: from AM0PR83CU005.outbound.protection.outlook.com
 (mail-westeuropeazlp170100000.outbound.protection.outlook.com
 [2a01:111:f403:c201::])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7c9af1e7-da10-11ef-99a4-01e77a169b0f;
 Fri, 24 Jan 2025 06:03:02 +0100 (CET)
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 (2603:10a6:150:16a::21) by DBBPR03MB7081.eurprd03.prod.outlook.com
 (2603:10a6:10:206::9) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.19; Fri, 24 Jan
 2025 05:02:59 +0000
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e]) by GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e%6]) with mapi id 15.20.8377.009; Fri, 24 Jan 2025
 05:02:59 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 7c9af1e7-da10-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ta+3s3m6IPGfmRbQwp/6qDkYc5CKauJWsJ5nPCFAyfv9mJ4VPBoW2MZJgXiss/+Gv1ML9+lqnO2n+xkmZI/dS1KA/vJO70WQYhvhtBpHfgk5sgq6gdN9sXYbYjv/R6LSCbN1OM6/H1cgSRC79qeMIgcb8hGYXcbIeZw4eYCD2WzQK3SjPDxyKvvmTrWrb+P47eoMoYkSdhNl6df3t5DZegkXhLRgEPMRnoM7YtmtPreeLJ1+8ovAf/sCQqk9oUt1Cx6uyXRlNL7gWqXDjWhk8flWi9FuGFQIXdnEnLPC7ukuqYz/fKvwFP7FxZh2LmrwC5hwW0iWgRBiPKo44GbwSQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=V7vMnJKxyP+NIkFBMw6JMn8+cyadBKvjdLtynAkEmzc=;
 b=pxKzkQYn/kPq50bQtOmG69ELOcwAs328u6yCBNy5Ql3fQgU/q9y7QH6TYHu82gZo1idsP9vDUB/2oam+/lqO8KsJos5Y1xO8cz5ppL+/9eLi5X70JSMJtx8ABlTBbGyB6x+RS/5+Ecy8V7YhnZqA/APdm8V4D4Ri9WWtT2brxeQ6hZjYljMpQyh0MNXnBkKYU++ZADKGlYelBFhUPZqDWcjde+SaYkmHmZ2Da1INUg+/6Pbjoj9apzaD8M843TRxuatBUyytCGYhttosNbACD+k9oEXFxmXfGABtNGjRoMdMl0Lrr/W1Gnp5jcFNyHOHdnKsw3rOKQWKvfhHZsbX4g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=V7vMnJKxyP+NIkFBMw6JMn8+cyadBKvjdLtynAkEmzc=;
 b=I5jtrNPVyl1egr+MDNhuFDTAfxwwcxomHn7/RId1vt7DdxGvRywfaLpicm5ElwH9RrBZJZobzdYV595t0NcUFfZchgkxjTVXrfm4DgabvwjJQQ2QB6cSJKC4g8xknrhwfvtbm+SpOxVN8j5SCGJrmcDOsx3WziyPKWEchpnwotVUm8sNCAFzBisR5l3CsA/HBx40tUlC1bpds66dQLKzssYhT56HBE1RHAKWTGM2h666FPlu+7wVEQy1Vq56DI0WdWYeGAWHnbo+bHHR8WV6Wb6R+kY2KHW97cfnDrigssmS41B34Gwn0yx8Y6Ew3jIACXagRicatfCwdyxqQAKYbA==
From: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
To: "L, John Preetham (893)" <john_preetham.l@daimlertruck.com>
CC: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Ruslan
 Shymkevych <Ruslan_Shymkevych@epam.com>
Subject: Re: Request for Documentation on Bringing Up Xen on R-Car H3e
 (H3ULCB)
Thread-Topic: Request for Documentation on Bringing Up Xen on R-Car H3e
 (H3ULCB)
Thread-Index: AdtsrjaU74AF3fZpR/+NK9h56D1xZg==
Date: Fri, 24 Jan 2025 05:02:58 +0000
Message-ID: <87ldv0248u.fsf@epam.com>
References:
 <FR2PPF86245AF1B81D71CF27EE705ED09B7B8E12@FR2PPF86245AF1B.DEUP281.PROD.OUTLOOK.COM>
	<8734ha2evr.fsf@epam.com>
	<FR2PPF86245AF1B0938F55DAF4FF4E63A31B8E02@FR2PPF86245AF1B.DEUP281.PROD.OUTLOOK.COM>
In-Reply-To:
 <FR2PPF86245AF1B0938F55DAF4FF4E63A31B8E02@FR2PPF86245AF1B.DEUP281.PROD.OUTLOOK.COM>
	(John Preetham L.'s message of "Thu, 23 Jan 2025 11:44:31 +0000")
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=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: GV1PR03MB10456:EE_|DBBPR03MB7081:EE_
x-ms-office365-filtering-correlation-id: 5e6116ab-2d67-4d65-34b9-08dd3c345f40
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?KqVgYs/Qi3TQlyluhM2xJ6ZiuVyUcDVjxKnvPxcjiI/GEzvB+e+PfKBQvu?=
 =?iso-8859-1?Q?IwaLFYqa7k28a8zcNL+hOeP8jMkLoMPrBmFrM9lfqUeMkb09RCX+CAA9PF?=
 =?iso-8859-1?Q?X127IuQdRWTDkxwoYVkPB8Km9Lbeja+y0pgs7sFCuCjBh8BQIdYAp6eJx9?=
 =?iso-8859-1?Q?giIGMCf9gk9+01N3S4cpPxvJvkyYWv3gRLVK4hF/2IQ8Rrukejb/E0dx9P?=
 =?iso-8859-1?Q?YO3BSGHVqp00ZTgwXl02fiE1dqsO+hLgAa6F+Xw92mMYCzV55hl00Xyl5q?=
 =?iso-8859-1?Q?XHlm7KqAtu4hI2wiUfzcBrkGABvn7idcOP/adhrl4tExBfNbCvvkSYUGe9?=
 =?iso-8859-1?Q?VB16lktTR061NK50AYT16ffuavJOvR7pjYrplmIxowQb81O/AC2WrO4aKm?=
 =?iso-8859-1?Q?7/2rpgoe66wQFx+HjSYTcdZQvJ0m8bap1xrb7aE5vaWW9OtJZs+iw0fCky?=
 =?iso-8859-1?Q?eJfKJYtvmoBfH76P8v5JB8c60J4OYhNM4TbPr9D8GNO6MhCTPmi1ICAVE9?=
 =?iso-8859-1?Q?ZjMid7/XjNXv3yr1buWCDJxyBbsgaQFh56XG3ZiJLwLCM2nbcCxyyM0WSS?=
 =?iso-8859-1?Q?vn3rZt9AbMU1vbMj1sQ6uAlyEf+FjAxPejOQoxt7dT2IPFMMohErCeXKhI?=
 =?iso-8859-1?Q?cta9CWLrYpdUgKV484puAl/BvmKorW2+1F0d89N/5oyaxXptd5RLhUcr1c?=
 =?iso-8859-1?Q?u0czwGZGAxkM/Kp+KBJxkfSvTm07Suu0o0LW1t5xvv7RTTCiGbPkqt05YM?=
 =?iso-8859-1?Q?eGrd+Xdc6tKgyeIx0Qv/OFUczGK/5uD4CI6SDL61n70HpOwcifKzSUULOB?=
 =?iso-8859-1?Q?MtLhII3iDeW5tskHG6syEE5f7x+0wKLVRFI5AClDGuRDpbqVhlWubTAYAq?=
 =?iso-8859-1?Q?lDOOV84ozKoYOds4F9jn3DocCIHRaFJA9n5Y2svuIxJW1EacjoDkHxYAvI?=
 =?iso-8859-1?Q?wysOZ7EWfRWXEJ0i4bVAlgrRdEmsZk65FFQ/j0RjDJf9vSIyYh66tiQun6?=
 =?iso-8859-1?Q?xwGpq22CEH9e8VftC0RJOsOB7Bjb3l+AKSUkQImyU1cJ3k5zo2Ar9GB5Xi?=
 =?iso-8859-1?Q?7kdJf3v1E0hBEFtQFhdS5skPmClozVElMr/vPHya8sk4UmoQAYohDGS+eA?=
 =?iso-8859-1?Q?UL1TJ0BRgFMX1wU9FE8H007ofeLA9Bzp0SWlJ7AT8sF2j03IjrzHUIOg6x?=
 =?iso-8859-1?Q?Bw2X0tgfyA/CyYcn94xDbjckXLYSeYl9Hv1Arb/c1KA/9qcmC+zyoNnnLh?=
 =?iso-8859-1?Q?aWVsWKmErFWtI30f9i1S8l/+LpCzJSuoSAwAQ6Uc2nLetWkyK7gZvCcjCN?=
 =?iso-8859-1?Q?aFK6OyzYNObqJuIIhYtnaspigzYacR0j7HzJLiQgAibmEgwnuVTJGq3p39?=
 =?iso-8859-1?Q?NzNA2RDuYkvH/tWn30WWbl8i5H80H02yBGnGV1MNyznLsBQf/l86bgAfi5?=
 =?iso-8859-1?Q?50ylH0+9UisQlVazR1Ybbuohj73U6rUnjYzDjNSFU+IrDzj/65kYS89krS?=
 =?iso-8859-1?Q?EPtl4x+hJpikhmEahgtV6B?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR03MB10456.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?5wNjUEQtxFmeakMWNnZRu0PcSruFRJu90sYBILPK75/buC7v5PxSvRx8x9?=
 =?iso-8859-1?Q?bF0BgFzuX6HLktHB3cIJFG9Lgto1zC7L39V7A0a1UnSjwNl4gVq6ZIUZID?=
 =?iso-8859-1?Q?dGUPu4f0q47GWm0nzJdmBVkElvGYNgJRVEec3IBBnUYdozagLbfr5PrqYY?=
 =?iso-8859-1?Q?2A0jCLP83eC78pYPNi2coG3FFKYGfe6hPM9lRek6EC+qxVp5wWYeZZ0yPX?=
 =?iso-8859-1?Q?WflMirZi4Q4uxedgTL2PLBg1TnILFUb8MO0b5OPZu8QdKolcdPYU50C0mC?=
 =?iso-8859-1?Q?JftDw/xO1n/6y+yqhQjNkR11M2z3VrIciz8TsCR8+ceX+tOy4OTWRv9Big?=
 =?iso-8859-1?Q?vT3ii9vcjuQImDvQq7e3Ea1Ma7sU91kQFfYUc2yrReCEuCTLtPGR0jd5WO?=
 =?iso-8859-1?Q?C5IrB4wvsxjC/AQCM/40/p1GzRc78+ry/Na8Rrv4RZlbeBPgHXtm5Z/uVM?=
 =?iso-8859-1?Q?BxDgG5XNALfkbQJWB1K4kI1LH7/6mL7U3xRex6taXXo/zc18oEyV+IPtAW?=
 =?iso-8859-1?Q?9mT188bsWsQleAx1Wz//4YhsI0f3CKrNWoBL4JqcOL6/9mdmx2E2LCqSBg?=
 =?iso-8859-1?Q?3wtEGULJ45zypoZ0L4aXzMZgxEnzcxqF+/OCOsM4HkYWJA9sG735S3j6Nl?=
 =?iso-8859-1?Q?pezQUtzsYJMoNHvqELXG2Umrwk9HoFg2H2c9bcOv2Sqf18WkjyGdc12tJM?=
 =?iso-8859-1?Q?3o7UthdQNJ68NPyJfxL4QHl48j0URMKihc2cSt+PwF3+sDXWrbR43mltG5?=
 =?iso-8859-1?Q?XsHJcCIoUq1gfdp/D3s5Q3fV4Xzx2tm4yvSp8KGi3DlCeQXeDQcqZIquYf?=
 =?iso-8859-1?Q?iK+v1M8mRYNnQblH5aTmDi2wdYcnn03+HMgJ8RqQY6Ai6IIRop7tLKXKUw?=
 =?iso-8859-1?Q?rH6KyL4Vkoy8FeKpIg+ghhj223tnCBIbbxdplrgmPB5lEiz08Bg5Jj24ek?=
 =?iso-8859-1?Q?/zfpo5hBZMnS4wpfSs1GEMCqIAKrDygYXtdqDOB7uTtamJoaEWLdKjnPI2?=
 =?iso-8859-1?Q?NKVauJtgVc84GnWxSQTa1dMPP7p60CyLbcA5rqphfKmaZDANBwGYeWDKSt?=
 =?iso-8859-1?Q?VgoRGr0P8izko2CVyGaFViOp3En91Hnl0Vn6ORCDY/Yh5MTL8Z1fi500Z6?=
 =?iso-8859-1?Q?21I3/STojutsNF0nFf7pv1zVuF0f5JVJyOx6UfyeaOYMdowe0/9mgej+6w?=
 =?iso-8859-1?Q?7DzeWjZULj4GQR1fVijZ7kkvWxaynPYMOCRqj4Gas6I796Zn7yzuhJBQFr?=
 =?iso-8859-1?Q?BC63sbQLpWjm0CMQ0fhKNg/8ZnP3DTFidLCIelKS+6O12BgtV7Ce3+cvrT?=
 =?iso-8859-1?Q?+7G8KXfyYE98fBoAe333FOWZEvJnJXiL6cXTMZ2W7ORIHzEB3mY8pPgrX0?=
 =?iso-8859-1?Q?Uk4Ylli9BXOZ1bPwabeaqoFGmYfHaf11qqmPpbXploL7gcUfYvFmOU44aA?=
 =?iso-8859-1?Q?ApXL9O1FTMC1aVTpu1LPPY5LxHS5tkJenykDgDYpMMfDHp8hr+6hGX7+a5?=
 =?iso-8859-1?Q?lZqxfRY8WjkBaxAPslF041jdyFNFkUAqjvvV85DkOt6+cp3cW14voqimKz?=
 =?iso-8859-1?Q?hauWJz928cWEI93jS6qkTP7P8qwmnUk9RYTNip4ArHuXpFIH+8ePzGDT96?=
 =?iso-8859-1?Q?NBSXAGWKy2ilnDXYX/dq9UzPN4uQk45xEjvBc4AZicbVPm9tBQ4/W/WA?=
 =?iso-8859-1?Q?=3D=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: GV1PR03MB10456.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5e6116ab-2d67-4d65-34b9-08dd3c345f40
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2025 05:02:58.9927
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: QoSN5/AzCK9L5GoQ4sIUdSrZdPCmHevp3L1XQh0vKY2shSMZSLHZB4ptqdDY2iFEX4nxIpMoejsUQFUguuARjX1PnaP5yRsDT8XZNhu4hfU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR03MB7081

"L, John Preetham (893)" <john_preetham.l@daimlertruck.com> writes:

Hi John,

> Hi Volodymyr,
>
> Thank you for the detailed suggestions.
> Since I'm new to XEN hypervisor.
>
> I will approach the recommended method.

Yeah, I think this is the best approach if you want get something
working ASAP.

> Could you please let me know which Yocto version is stable and tested fro=
m your end?

As of now we are using Kirkstone. I believe, this is the latest Yocto
version supported by Renesas BSP. And we of course can't jump over
their head. Anyways, if you'll follow instruction in README.md, moulin
tool will fetch all required meta-layers and configure Yocto for you.

If you are interested in exact commit ids, you can check the YAML file
used by moulin tool:

https://github.com/xen-troops/meta-xt-prod-devel-rcar/blob/master/prod-deve=
l-rcar.yaml#L32

--=20
WBR, Volodymyr=


From xen-devel-bounces@lists.xenproject.org Fri Jan 24 09:16:55 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Jan 2025 09:16:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876624.1286974 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbFnq-0007Q9-U1; Fri, 24 Jan 2025 09:16:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876624.1286974; Fri, 24 Jan 2025 09:16:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbFnq-0007Q2-QT; Fri, 24 Jan 2025 09:16:38 +0000
Received: by outflank-mailman (input) for mailman id 876624;
 Fri, 24 Jan 2025 09:16:37 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=AkuS=UQ=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tbFnp-0007Pw-Lq
 for xen-devel@lists.xenproject.org; Fri, 24 Jan 2025 09:16:37 +0000
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [2a00:1450:4864:20::62c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e7a4ccb9-da33-11ef-a0e5-8be0dac302b0;
 Fri, 24 Jan 2025 10:16:33 +0100 (CET)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-ab2b29dfc65so301669366b.1
 for <xen-devel@lists.xenproject.org>; Fri, 24 Jan 2025 01:16:33 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab675e6790bsm97248166b.63.2025.01.24.01.16.32
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 24 Jan 2025 01:16:32 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e7a4ccb9-da33-11ef-a0e5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737710193; x=1738314993; 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=kbPtAH9ZMOxDBaDDxqcnEfFRDOrWtvleAjEuxXHtuuE=;
        b=RupBwn3ZLGnlGx0CeWMNACdg2h/8dl4HH2ZjHmYI7udI2GJ1Vb/6mwly2KRhU81h+y
         +KA1z3RcuVPeu+WOGFK+m9BfH+Q7h87SxJvbYHGkruVzBqg2gDyDKgTJ1fAAwgVy+ohz
         2wCH8d3uO962Eipll/y7kdqzHVzcsb8/3MdIE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737710193; x=1738314993;
        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=kbPtAH9ZMOxDBaDDxqcnEfFRDOrWtvleAjEuxXHtuuE=;
        b=XtpkJnOIMIJosvLhCkDNCMy4R9xA5nrCrrcsHFBEEa8ZVrlmf1fSRGpTKr43RgfvDY
         LZFEV3RPRKBzwuwiaJjUiSGiPwNd6P4rcKK8zJi3azLkslKfVhgStU2AGMyEFcWR64FR
         wjjPiplytzG3rL6yIfyMvsXSJsgM/DJ9mlpD3wdq4S6REnBhSEL/xJLn9sqKS9dv+2pI
         xVMJu0VDY6TjGllKJ14yauOeB5VD/l4HN5pgqycmtnOIoVeS0GbaJignAGeRjN8h8kzR
         RY6Y14+x35jiwPTz/Q786lbusDTqJ/g4arBaj+DZZtq2RfMEbonvjhELpkRpQx1fGL8x
         cKQA==
X-Gm-Message-State: AOJu0YyLXB615AReq9J6zN12QpRTI8Q0Lp2bzLKvMoVj7LT6wt+KOjv+
	oRkGNf4ZgvFvhedhFGjzt0JZ3dggLo5XIYQ+agOp2/2o+Z7Ne+PjytDygzp3eVM=
X-Gm-Gg: ASbGncs8JE/z4edd4fkHpLPPLNLBUI8AB45E/vq8NAPmPl/AqYx+UoUrW0O+hYKmo8D
	9zwZJNkZCXR+QixUp6ut95geRRIBltCRfcVI2ruIelpWaXAHBR8jf8o7fmyfn8stKTgJOw0mhFn
	4oEHmm9skaNg4MNuQjpipr5/je/7CL1Yqti74+7/qGstfP0Jum8E5Olp5CleIaEHWpNhPSNa08o
	KPBXQrxg//5OowEiuEmN88mJUCM9zzz1qH0kNINa4xSBBhJXFZfkmIyr9e6CABp2iA+SbWULuQV
	SfGM3tzr6BnFTSA=
X-Google-Smtp-Source: AGHT+IFX0PvntvqjF6O1EoqNi9G2SFAfcl0Ta2PMKTb7GWpvTN5WYdAeKB0HTF1OHh00sbE9AhRUuA==
X-Received: by 2002:a17:906:7956:b0:aae:fb7c:50df with SMTP id a640c23a62f3a-ab38b36be2bmr2891029166b.36.1737710193175;
        Fri, 24 Jan 2025 01:16:33 -0800 (PST)
Date: Fri, 24 Jan 2025 10:16:31 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
	Kevin Tian <kevin.tian@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>
Subject: Re: [PATCH v3 02/12] x86/HVM: improve CET-IBT pruning of ENDBR
Message-ID: <Z5Nab7X6l9McxFw2@macbook.local>
References: <293e5aef-8843-461c-bc96-709a605b2680@suse.com>
 <537b0d9c-1936-4cf5-a012-d50b1097a22d@suse.com>
 <Z5I5D_uVxijLF6sK@macbook.local>
 <f0e2a3f3-3081-414d-824c-bf940134aece@suse.com>
 <Z5JRGwA51lOs65t5@macbook.local>
 <8aa7c377-b664-4786-b671-deff1601ac5f@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <8aa7c377-b664-4786-b671-deff1601ac5f@suse.com>

On Thu, Jan 23, 2025 at 05:14:39PM +0100, Jan Beulich wrote:
> On 23.01.2025 15:24, Roger Pau Monné wrote:
> > On Thu, Jan 23, 2025 at 02:18:41PM +0100, Jan Beulich wrote:
> >> On 23.01.2025 13:41, Roger Pau Monné wrote:
> >>> On Mon, Feb 26, 2024 at 05:42:20PM +0100, Jan Beulich wrote:
> >>>> --- a/xen/arch/x86/hvm/hvm.c
> >>>> +++ b/xen/arch/x86/hvm/hvm.c
> >>>> @@ -161,10 +161,15 @@ static int __init cf_check hvm_enable(vo
> >>>>      else if ( cpu_has_svm )
> >>>>          fns = start_svm();
> >>>>  
> >>>> +    if ( fns )
> >>>> +        hvm_funcs = *fns;
> >>>> +
> >>>> +    prune_vmx();
> >>>> +    prune_svm();
> >>>
> >>> Isn't it actually the opposite of pruning.  What the helpers do is
> >>> fill all the pointers in the structure.
> >>
> >> With the goal of their ENDBR to then be pruned. I agree though that the
> >> functions don't do any pruning themselves. Yet
> >> {svm,vmx}_prepare_for_cet_ibt_pruning() is a little awkward for my taste
> >> (although it would properly document the purpose). Plus ...
> >>
> >>>  I would rather name them {vmx,svm}_fill_hvm_funcs() or similar.
> >>
> >> ... while I can use those names (perhaps without the "hvm" infix), the
> >> present names have the advantage that any other pruning that we may
> >> find desirable could also be put there. Hence also why the cpu_has_*
> >> checks live there.
> > 
> > Hm, I'm unsure.  What else do you see becoming part of those
> > functions?  It's hard for me to suggest a name when it's unclear what
> > future logic do you think they could contain.
> 
> Prior to IBT it wasn't foreseeable any pruning might be needed. We're
> in a similar position now: We simply can't know whether anything else
> is going to be needed there.
> 
> > Given the current code I still think something that contains 'fill' or
> > similar is way more appropriate, the more if the IBT check is pulled
> > out into the caller.
> 
> As indicated, I'd prefer the IBT check to remain in the function. But
> yes, I'll see about renaming. If ever other stuff wants adding there,
> we can surely rename another time.
> 
> >>>  And possibly pull the
> >>> cpu_has_xen_ibt check outside the functions:
> >>>
> >>> if ( cpu_has_xen_ibt )
> >>> {
> >>>     /*
> >>>      * Now that svm_function_table was copied, populate all function pointers
> >>>      * which may have been left at NULL, for __initdata_cf_clobber to have as
> >>>      * much of an effect as possible.
> >>>      */
> >>>     vmx_fill_hvm_funcs();
> >>>     svm_fill_hvm_funcs();
> >>> }
> >>
> >> Which would leave the SVM function entirely empty.
> > 
> > You could possible declare it as an static inline in the hvm.h header
> > for the time being?
> > 
> >> The intention was for
> >> that to not be the case, and also for the comment you have added above
> >> to also live in the per-vendor functions.
> > 
> > Isn't that a bit redundant?  I would prefer to not have duplicated
> > comments over the code, hence my suggestion to place part of the logic
> > in the caller.
> 
> In this case I view the redundancy as necessary. You want to know what
> to add to the functions when you look at them, irrespective of whether
> you also look at their caller.

OK, I won't oppose to it, but I do think function names need
adjusting.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jan 24 10:26:22 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Jan 2025 10:26:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876643.1286992 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbGsx-00081b-R4; Fri, 24 Jan 2025 10:25:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876643.1286992; Fri, 24 Jan 2025 10:25:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbGsx-00081U-Mx; Fri, 24 Jan 2025 10:25:59 +0000
Received: by outflank-mailman (input) for mailman id 876643;
 Fri, 24 Jan 2025 10:25:58 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=AkuS=UQ=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tbGsw-00081K-Qn
 for xen-devel@lists.xenproject.org; Fri, 24 Jan 2025 10:25:58 +0000
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
 [2a00:1450:4864:20::52e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 95df7bbd-da3d-11ef-99a4-01e77a169b0f;
 Fri, 24 Jan 2025 11:25:51 +0100 (CET)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-5d7e3f1fc01so3897141a12.2
 for <xen-devel@lists.xenproject.org>; Fri, 24 Jan 2025 02:25:56 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5dc186397c0sm972585a12.35.2025.01.24.02.25.55
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 24 Jan 2025 02:25:55 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 95df7bbd-da3d-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737714356; x=1738319156; 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=SH3d1P09sjphp9Rwg2Fq0xkJcIR7BrUleRchqAoxUeA=;
        b=C9gz/+HOqlkeiGoUaJORVbBGlo1I8g27cHmeN6XqjQpR99YVn8xlsTz41Y0lHFND33
         fyylSD8nZmFSXGg3cz8fdq6TbS9gHrVAsklv02NiqG13t4ZCDwEHQxfw4Nt7Y3RI7pQU
         sOLfzSjA1Cqbtb4lz0BQ8w2CMnJxzLaSIZ4Vo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737714356; x=1738319156;
        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=SH3d1P09sjphp9Rwg2Fq0xkJcIR7BrUleRchqAoxUeA=;
        b=pYiASPvWU/NZwpW5/34aatYFAdLeYTCbraTYgMV2NrwZfR2lO9Aq/evjVSXZcmZqEt
         N0F15YkzQe9B5wNwy0SKDQLpc21BSwmcuac2eYgYCP5km0nz06wKv3bJ5636dDijJ3aA
         AVq+RyudYLiEY6sCsrKeGWUL8wXpYn4+tZvtz6BLwrQOGvX3ZuqDqzXlb1JnAIECxDDX
         CAYXnSaSPSRfGjYUT1DOotcq5Dv8+1r8RZrhGB9L4B/7uLgPF045lf9CGR+TTFQkI3s3
         UHW+k8RSgxe4bAqVO1dTeVDS3wZSij84mzkX5oKu5UT0DMSes/7FsU8V/GkVkdhIDisn
         EGGg==
X-Gm-Message-State: AOJu0YxFx2ODUafWCE3lGSEG16bqTrVwOB+HIiHxSQrnrzVk52V0NylQ
	4xYa/oEDKnNL/fqOKN0egC5ze41pIlUU3Z1ZPDPKMgKEqulWjKjHKWHP/T4iCLk=
X-Gm-Gg: ASbGnctOGZRN4TsrA0fbnRslsU6JSVPBAv10VtOwRfOXfXJOLHtAuKWLSNaqeMkjmNo
	byROO/qbIe1N3GrDZ9/dfuv133E/NAVmbf1NgtxIyds3eMQOrycBFdcBBhJD8KL/1cEyqICqU+E
	DUl8G29rH18G9f8xfWuDmDXZPAPZYxatYxs+qF2L6xBkcVJgaAfjy9RQf2eJAT/pP8vF0xUtcFQ
	XKO6a5Y+u5zfNHVUDcMJbw6FL7MP6z2K+FjkpzhsjAnFnmBKojo/BNXMExko5ftkLdcAtN/lD9/
	xNAzsFwMrw==
X-Google-Smtp-Source: AGHT+IH+J+vsQnuFLNc0JbXT53jFl5cytesOIiEr/rEfOWpmpBpAWFY13ohqKSq9aCc/0YgyQrgBRQ==
X-Received: by 2002:a05:6402:51cd:b0:5d3:e4eb:8d1f with SMTP id 4fb4d7f45d1cf-5db7d2fc8b0mr25384463a12.12.1737714356275;
        Fri, 24 Jan 2025 02:25:56 -0800 (PST)
Date: Fri, 24 Jan 2025 11:25:54 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
	Kevin Tian <kevin.tian@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>
Subject: Re: [PATCH v3 01/12] VMX: don't run with CR4.VMXE set when VMX could
 not be enabled
Message-ID: <Z5NqsmsuVfQcOcMg@macbook.local>
References: <293e5aef-8843-461c-bc96-709a605b2680@suse.com>
 <21e6cbec-dc29-452f-b6a2-6926245a8beb@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <21e6cbec-dc29-452f-b6a2-6926245a8beb@suse.com>

On Mon, Feb 26, 2024 at 05:42:02PM +0100, Jan Beulich wrote:
> While generally benign, doing so is still at best misleading.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jan 24 10:52:04 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Jan 2025 10:52:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876652.1287001 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbHHx-0003e0-O0; Fri, 24 Jan 2025 10:51:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876652.1287001; Fri, 24 Jan 2025 10:51:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbHHx-0003dt-L4; Fri, 24 Jan 2025 10:51:49 +0000
Received: by outflank-mailman (input) for mailman id 876652;
 Fri, 24 Jan 2025 10:51: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
 <SRS0=AkuS=UQ=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tbHHv-0003dn-V8
 for xen-devel@lists.xenproject.org; Fri, 24 Jan 2025 10:51:47 +0000
Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com
 [2607:f8b0:4864:20::635])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2fe2fa41-da41-11ef-99a4-01e77a169b0f;
 Fri, 24 Jan 2025 11:51:39 +0100 (CET)
Received: by mail-pl1-x635.google.com with SMTP id
 d9443c01a7336-2163dc5155fso34667205ad.0
 for <xen-devel@lists.xenproject.org>; Fri, 24 Jan 2025 02:51:44 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-ac48f6ad41bsm1333864a12.17.2025.01.24.02.51.41
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 24 Jan 2025 02:51:42 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2fe2fa41-da41-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737715903; x=1738320703; 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=HDtClwP7DW8w5GNJ/nJqxtLOtzp1/CM3PkwPFbvsfl4=;
        b=jT6mn/i13a74Iw4KXAx/DNFng/X7DBzq7kpITjOxmEKgGyjJzJtTnNMJnnJK4bJnB4
         TINuqKOhF4udW5I9OgJZMJDRJopXPm06V0KXKjSdN2IEzACZRvCdIlpqAzoVG9JMV6sO
         97sD56YrU3N9kzkUx+7BOTgF7FPd30tyzqVfE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737715903; x=1738320703;
        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=HDtClwP7DW8w5GNJ/nJqxtLOtzp1/CM3PkwPFbvsfl4=;
        b=KtKNUXWVDfSbc75Myw0L+L24wAnHMyPl6grB3x06N+t8Utz/ajuJq2JZA28BbhXGo0
         9rFKEKkYK8J80A4YTde8LO8hpe+9IWvDmGZ+AkNR/7LipYPI5dg2JBlc1XPSXdZtD7My
         i4q+CQ1Dmjz5rS7NQugr6gw1YMxirqShUbr1fpNjfXC07pAlBj346xqNIVnTZqIn0gzu
         FNOnhCuXD9fSVGHA9iN8OV6Z2iGSaQLm2FQO25mSuE44qSR4IhmIvvivdAXsGymxG+8A
         qrVoCDqYW+azwIV/MKuU+NTrCznsU7F3aC5uDxARq2Zi4m8Tz7iqzO6Pn70NAWzPB2OI
         8cag==
X-Gm-Message-State: AOJu0YxTVBaH2bG13+TcUNeskcfkwA38HBBFz4JFlJ1FDwWlVU2Vxypv
	EYHeqN6aaey+8ayjuiCgwhbV18ZlP4e/PKwNMNlDdsSRKao4fLeH48jViZVM3aAvHJ3kPi0FoDP
	I
X-Gm-Gg: ASbGncveI0wuj8WkmeeO84HpxFHOowSLw5OPId0/gP1/U4VRJ6wLRFOuoiVDcIiM9wK
	oQJqijvWh2XUJjUTIlvX9taTXz8SCi4RtRTcyXuhWgP7k0xj623L7e2Vs7ecgjPLoZciPqSZwM9
	rhx70td2CoCWnHnUw1GPF4b2pbwIi1nidwYJFWcshVr1SJZsG927I/paprSIinGDsm6ycCAcRBF
	dcQlt4s20RW8cT43uDMHl9Bw60WdjGQAIFa9kQjkScam51afXpTLXRx+b8u1/n122uXmXaVwJ4s
	943f1VakXdjR4T0=
X-Google-Smtp-Source: AGHT+IFr0K3iNOCp39sFX9oOT8FBO7sS/CxnPSoh6pKefIEhPowRohWXAJyH8sgkyMDzaMmzgxcuPw==
X-Received: by 2002:a17:902:f78e:b0:215:a05d:fb05 with SMTP id d9443c01a7336-21c355dcf9emr462940775ad.32.1737715903012;
        Fri, 24 Jan 2025 02:51:43 -0800 (PST)
Date: Fri, 24 Jan 2025 11:51:37 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
	Kevin Tian <kevin.tian@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>
Subject: Re: [PATCH v3 03/12] VMX: drop vmcs_revision_id
Message-ID: <Z5NwuaCBm4vxATUu@macbook.local>
References: <293e5aef-8843-461c-bc96-709a605b2680@suse.com>
 <7a4ec627-f801-409b-995e-42732970e47c@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <7a4ec627-f801-409b-995e-42732970e47c@suse.com>

On Mon, Feb 26, 2024 at 05:42:50PM +0100, Jan Beulich wrote:
> It's effectively redundant with vmx_basic_msr. For the #define
> replacement to work, struct vmcs_struct's respective field name also
> needs to change: Drop the not really meaningful "vmcs_" prefix from it.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> v2: New.
> 
> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -175,7 +175,7 @@ static DEFINE_PER_CPU(paddr_t, current_v
>  static DEFINE_PER_CPU(struct list_head, active_vmcs_list);
>  DEFINE_PER_CPU(bool, vmxon);
>  
> -static u32 vmcs_revision_id __read_mostly;
> +#define vmcs_revision_id (vmx_basic_msr & VMX_BASIC_REVISION_MASK)
>  u64 __read_mostly vmx_basic_msr;

__ro_after_init maybe while at it (and then uint64_t also)?

I would place the #define after the definition of vmx_basic_msr, but
that's just my taste.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jan 24 10:54:19 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Jan 2025 10:54:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876650.1287011 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbHKH-0004CB-3u; Fri, 24 Jan 2025 10:54:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876650.1287011; Fri, 24 Jan 2025 10:54:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbHKH-0004C4-0w; Fri, 24 Jan 2025 10:54:13 +0000
Received: by outflank-mailman (input) for mailman id 876650;
 Fri, 24 Jan 2025 10:48: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
 <SRS0=d6RC=UQ=amd.com=KPrateek.Nayak@srs-se1.protection.inumbo.net>)
 id 1tbHF4-0002Xu-Kr
 for xen-devel@lists.xenproject.org; Fri, 24 Jan 2025 10:48:50 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20606.outbound.protection.outlook.com
 [2a01:111:f403:2418::606])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ca517aeb-da40-11ef-a0e5-8be0dac302b0;
 Fri, 24 Jan 2025 11:48:48 +0100 (CET)
Received: from PH8PR15CA0019.namprd15.prod.outlook.com (2603:10b6:510:2d2::21)
 by SA3PR12MB7806.namprd12.prod.outlook.com (2603:10b6:806:31d::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8356.20; Fri, 24 Jan
 2025 10:48:43 +0000
Received: from SJ1PEPF00002327.namprd03.prod.outlook.com
 (2603:10b6:510:2d2:cafe::1f) by PH8PR15CA0019.outlook.office365.com
 (2603:10b6:510:2d2::21) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8356.22 via Frontend Transport; Fri,
 24 Jan 2025 10:48:43 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ1PEPF00002327.mail.protection.outlook.com (10.167.242.90) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8377.8 via Frontend Transport; Fri, 24 Jan 2025 10:48:43 +0000
Received: from [10.136.33.41] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 24 Jan
 2025 04:48:22 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ca517aeb-da40-11ef-a0e5-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=zSEBHvK2N2aor+hK5LGetpqh/Roq4RE062Ied/RYZyeLMmNWjiBCxaOAdrZL0Pl3SIzQUG4sjtxOb23rwqcmoXZQ8vk8vLCAa1vfXpdSvzPSxnSmaZw4QcesJOH1bDQJGUjREyQRuvUWo+fGuecvBv+A6Ia8NqosO1abjj76gAyiYDf+itdlb0+Ne28y1o00hSnKvS33knadF0uX9s11psvW4KaHxRU63+dq9kJKyBONOdR6GdSMbOGqL3H+cIUxFukqoxxT2sb5Y/RCvLw1Bqz2L8J80Xs1PGDoKbXdxtinc7zLCmv4seGnYuHVhMGmq8xpzIRzBEnrTBLMulhFKQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=cwVvFaV9aZnIyo9GynOO/BvAClq3gm1jIac8yqCvAwc=;
 b=J1f8q0nZHpw8h9cOW6AYg+muF8gXT6maM0qXPSBmdcdyo8sjtXUMgghcNMU9c9mJGzN8xxeA4xEZinsZPsIdCJVSCisw4NRqzmomsQpwloxel4O2ilL3bhGhz2PMwqMpOyc/6w4kYH899OK5ltirhlWy1CfSIxDY4E/92NVIEaTLARXyRysbqWjO6Fy2uFPzCsWrzVFHxP4g/KZQ23YaQPEeyQr6FKi8BFP4hBCr1i8VVCftJXoDSHEU+RrjrhNupRsXdIP0SgvRFxlwZrguddMkXdyuQ9QVL3zQFRqsefw2hwk0z3qchVuih+31lIwtRqQ2JJX0ooYQ5YPG3BF+2g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=redhat.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=cwVvFaV9aZnIyo9GynOO/BvAClq3gm1jIac8yqCvAwc=;
 b=QtCnc4hWjSJiYO68q+59zcxwqbjygQLbPhpdGpjQYfKLf723X+8ycyiTSPnIQ+ssntv4+KBQi/MfL+/3JMxEpbeZnbp8aYbdPbfr9c2R4ABg6zPf0YNP0WsXAU/fkHwBMt1QTGSqNRKSwKsFEHdcZZCoL3C402yDcmEWPw20MVg=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <8c298b9e-d7c2-4a27-b993-e3bca28f8237@amd.com>
Date: Fri, 24 Jan 2025 16:18:19 +0530
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 25/30] context_tracking,x86: Defer kernel text patching
 IPIs
To: Valentin Schneider <vschneid@redhat.com>, <linux-kernel@vger.kernel.org>,
	<x86@kernel.org>, <virtualization@lists.linux.dev>,
	<linux-arm-kernel@lists.infradead.org>, <loongarch@lists.linux.dev>,
	<linux-riscv@lists.infradead.org>, <linux-perf-users@vger.kernel.org>,
	<xen-devel@lists.xenproject.org>, <kvm@vger.kernel.org>,
	<linux-arch@vger.kernel.org>, <rcu@vger.kernel.org>,
	<linux-hardening@vger.kernel.org>, <linux-mm@kvack.org>,
	<linux-kselftest@vger.kernel.org>, <bpf@vger.kernel.org>,
	<bcm-kernel-feedback-list@broadcom.com>
CC: Peter Zijlstra <peterz@infradead.org>, Nicolas Saenz Julienne
	<nsaenzju@redhat.com>, Juergen Gross <jgross@suse.com>, Ajay Kaher
	<ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.amakhalov@broadcom.com>,
	Russell King <linux@armlinux.org.uk>, Catalin Marinas
	<catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Huacai Chen
	<chenhuacai@kernel.org>, WANG Xuerui <kernel@xen0n.name>, Paul Walmsley
	<paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou
	<aou@eecs.berkeley.edu>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar
	<mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Dave Hansen
	<dave.hansen@linux.intel.com>, "H. Peter Anvin" <hpa@zytor.com>, Arnaldo
 Carvalho de Melo <acme@kernel.org>, Namhyung Kim <namhyung@kernel.org>, Mark
 Rutland <mark.rutland@arm.com>, Alexander Shishkin
	<alexander.shishkin@linux.intel.com>, Jiri Olsa <jolsa@kernel.org>, Ian
 Rogers <irogers@google.com>, Adrian Hunter <adrian.hunter@intel.com>, "Liang,
 Kan" <kan.liang@linux.intel.com>, Boris Ostrovsky
	<boris.ostrovsky@oracle.com>, Josh Poimboeuf <jpoimboe@kernel.org>, Pawan
 Gupta <pawan.kumar.gupta@linux.intel.com>, Sean Christopherson
	<seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, Andy Lutomirski
	<luto@kernel.org>, Arnd Bergmann <arnd@arndb.de>, Frederic Weisbecker
	<frederic@kernel.org>, "Paul E. McKenney" <paulmck@kernel.org>, Jason Baron
	<jbaron@akamai.com>, Steven Rostedt <rostedt@goodmis.org>, Ard Biesheuvel
	<ardb@kernel.org>, Neeraj Upadhyay <neeraj.upadhyay@kernel.org>, Joel
 Fernandes <joel@joelfernandes.org>, Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>, Uladzislau Rezki <urezki@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>, Lai Jiangshan
	<jiangshanlai@gmail.com>, Zqiang <qiang.zhang1211@gmail.com>, Juri Lelli
	<juri.lelli@redhat.com>, Clark Williams <williams@redhat.com>, Yair Podemsky
	<ypodemsk@redhat.com>, Tomas Glozar <tglozar@redhat.com>, Vincent Guittot
	<vincent.guittot@linaro.org>, Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>, Kees Cook
	<kees@kernel.org>, Andrew Morton <akpm@linux-foundation.org>, Christoph
 Hellwig <hch@infradead.org>, Shuah Khan <shuah@kernel.org>, Sami Tolvanen
	<samitolvanen@google.com>, Miguel Ojeda <ojeda@kernel.org>, Alice Ryhl
	<aliceryhl@google.com>, "Mike Rapoport (Microsoft)" <rppt@kernel.org>, Samuel
 Holland <samuel.holland@sifive.com>, Rong Xu <xur@google.com>, Geert
 Uytterhoeven <geert@linux-m68k.org>, Yosry Ahmed <yosryahmed@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>, "Masami Hiramatsu
 (Google)" <mhiramat@kernel.org>, Jinghao Jia <jinghao7@illinois.edu>, Luis
 Chamberlain <mcgrof@kernel.org>, Randy Dunlap <rdunlap@infradead.org>, Tiezhu
 Yang <yangtiezhu@loongson.cn>
References: <20250114175143.81438-1-vschneid@redhat.com>
 <20250114175143.81438-26-vschneid@redhat.com>
Content-Language: en-US
From: K Prateek Nayak <kprateek.nayak@amd.com>
In-Reply-To: <20250114175143.81438-26-vschneid@redhat.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF00002327:EE_|SA3PR12MB7806:EE_
X-MS-Office365-Filtering-Correlation-Id: 600ffd5d-1ae7-41e0-e57b-08dd3c64abd5
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|82310400026|1800799024|7416014|36860700013|921020;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?eGI4dEMxdFNsNzRsU2VWVmlmOTM0OVQ0cm1QdjlOTDlxa2tWcjR4NHlEOXZW?=
 =?utf-8?B?b3UrcW5BamtEb1Nya0pWRDFPY3hRZDViek1ERGg0eVgzWXJmYkh4WVJRLzdR?=
 =?utf-8?B?MEc3NWNTaTNobU9EckwyajdiMkVxQUJBYlZjYU5LajVVSmlQOWlDaGs0alBk?=
 =?utf-8?B?cWlONUUyVlQ3c0hsS1ZTb0ROV0VsUVhVWmprTmxnZm1MNGhYRFpmRlJnVVFK?=
 =?utf-8?B?UEdlOThNUC96dkNGQXJFSmRBU2JmTXdmRnBBWHNNS3Jhd3piOGpQTGJtUmhY?=
 =?utf-8?B?R3FZdHd1R3V5UVZVS25GWjJISm5uYjlRMmhuVERUWERqZ1V5bHFCdURjdlNW?=
 =?utf-8?B?R05Ua3dlUFcrUktoVDUvVnhoeGdQamtSQ3l4RDBGT25EU2w1dkJLbHhldGJp?=
 =?utf-8?B?YUxFTTI3Q3FlRDFwT3hPMUI0Sjl4R1JMbStQZEt6R0c2WWlSMDc1azlmNzY3?=
 =?utf-8?B?MmQ4NTdsd3JjWjJZUDZRVSs3d3hhMXlBVVVMai9nY0VMSHlRMjNvMkJYbkFq?=
 =?utf-8?B?RVkzcWZOczNLYWprR1Ryb2lRbFkxQ2ZHY3RMN0xkY3lpOVFqS3QwSnQyRElJ?=
 =?utf-8?B?SEt4TjhLWm00YWl0NUlQeVA0b2paQTM0azBleHVLcE9USTJEYlo4WnZFNkFv?=
 =?utf-8?B?c2VtZm1wRW42TVRiK3BxWlFDS3NkT0t3SWNrYmZ6N3lRd3FFZjNKYWdQaXJQ?=
 =?utf-8?B?Wml2ZE1qaEpxdEVxcDBiK2x1T21RVWJZZXhGVmlEOFVOVzIxZTV2a21zeUFa?=
 =?utf-8?B?UlVRR2hpM2xJcGFETkpxMGd6MGtiTFNmSE8yQ2lBY1k3TmtYM0lzZkN0Q1Ry?=
 =?utf-8?B?cG9FYlFlb2w0QXJBV3VGdnNXaWl5VThoc1VGVEFWSTQwRHZvUitCRTJCaFBB?=
 =?utf-8?B?eTRuRFMxblZ5OHZ6Zm5MbU82N1NPdVRYZllvNU5XM3UrYkdPOC91VUl3dnRL?=
 =?utf-8?B?aVdZazAzVyt4ZXozVzJqaGFFZjYxMXc4bXhRVVFhMXBCaXdGdkg5VjEyemR2?=
 =?utf-8?B?cTNCS0owUDZvQit6bHpjbkYwYlZOcU5CdzlkVS9Jc2hCMXhXS080ci9qL1Vs?=
 =?utf-8?B?Rk9sTmZNdG9mZ3FlTndKU2trK2l0ME1VaTl1Rkd0MzltbWhNZ1pPMTU0Y1pp?=
 =?utf-8?B?ck1PNytGcTlUWmpoV1RpY0JGZFdIcDJ6UkdNdTRsR3JxMy9xY2ZEMmtBRkFT?=
 =?utf-8?B?MkN2TVBiYWpaWXR2S2UrZG01blNiaFdrRStiR0k0K3ArRTc2UkMzaHVnRnIx?=
 =?utf-8?B?RTFjc1RZa1lhWTdJb2IxZ0ZFeUhBbFl5NHFJSmg1eENEV24yUDV1dkZ3S0xr?=
 =?utf-8?B?eUdhclkvRGN5ekRwVmY1QVMwNWd6d3g4SzdVOVl5WnQ3NEFFQ2dMYUorOXhk?=
 =?utf-8?B?Nkw5OTZyZ2ZLZGhwV0lmdzNLaW5QS1ora2pBSXlvUlJGWWNVaXB6bFBFZUJ5?=
 =?utf-8?B?WENVOFd5ZVMvaFZsU25mb1BQNXF3cE5lRzN4eUM1dzdzenBEbFMwVXR0TjZN?=
 =?utf-8?B?T24wK3VyLzFBMW50a21KUllmSmQ3MEJPdW9sQ1hDc0VHN2ZTVm9zTTJXTWZW?=
 =?utf-8?B?ck9Kc1ZMRXlEcDZzQnBnTG9weWt6MDNDbW5jOFdnVlpReDdCTXlJMFl4WCtO?=
 =?utf-8?B?SGxHQUZaRmxlR2xibmJiT3VPTElNUEhGcnp2Q0UrTHFHd3VtdzhWKzl6b2k5?=
 =?utf-8?B?MTl6UGZNWWovM3pMcmRvTjFHbFk5Njk0QVZZcnNWOUhtZ011S2YvSVBCWU1G?=
 =?utf-8?B?U1I0NVlrR3lnUEl2ZFM1b21UQ2d3YVF2OVZoOFQ4S0pLRGRudTZ4ZHBmNE95?=
 =?utf-8?B?am9UaGFHTTNnL2pORlRpVDZJdDlHUS9TYVVVRzFpem5FdXBDNk9rOHBKVjhr?=
 =?utf-8?B?eDMzTWQ4d1A4U1VaUmRUNmNsNHJuaElOQWdlZXVWaEk1L0tPSTVaMUgvN2N5?=
 =?utf-8?B?MUkwRjdvdnFHa0VUeXlMVEtPUlRzRm1QNFI3V2p0OFpwNm81dlJ5SHp5aVpt?=
 =?utf-8?Q?VrP+GI9ukCMThuvNcrCduETSHbKQ3Y=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(1800799024)(7416014)(36860700013)(921020);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jan 2025 10:48:43.2233
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 600ffd5d-1ae7-41e0-e57b-08dd3c64abd5
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ1PEPF00002327.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR12MB7806

Hello Valentin,

On 1/14/2025 11:21 PM, Valentin Schneider wrote:
> [..snip..]
> diff --git a/include/linux/context_tracking_work.h b/include/linux/context_tracking_work.h
> index c68245f8d77c5..931ade1dcbcc2 100644
> --- a/include/linux/context_tracking_work.h
> +++ b/include/linux/context_tracking_work.h
> @@ -5,12 +5,12 @@
>   #include <linux/bitops.h>
>   
>   enum {
> -	CT_WORK_n_OFFSET,
> +	CT_WORK_SYNC,

nit.

Shouldn't this be "CT_WORK_SYNC_OFFSET"?

I believe it gets fixed in Patch 29/30 when "CT_WORK_TLBI_OFFSET" is
added but perhaps that can be moved here to preserve bisection.

>   	CT_WORK_MAX_OFFSET
>   };
>   
>   enum ct_work {
> -	CT_WORK_n        = BIT(CT_WORK_n_OFFSET),
> +	CT_WORK_SYNC     = BIT(CT_WORK_SYNC_OFFSET),
>   	CT_WORK_MAX      = BIT(CT_WORK_MAX_OFFSET)
>   };
>   

-- 
Thanks and Regards,
Prateek



From xen-devel-bounces@lists.xenproject.org Fri Jan 24 10:57:33 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Jan 2025 10:57:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876670.1287022 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbHNQ-0004nW-Kl; Fri, 24 Jan 2025 10:57:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876670.1287022; Fri, 24 Jan 2025 10:57:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbHNQ-0004nP-I4; Fri, 24 Jan 2025 10:57:28 +0000
Received: by outflank-mailman (input) for mailman id 876670;
 Fri, 24 Jan 2025 10:57:26 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=AkuS=UQ=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tbHNO-0004nJ-QN
 for xen-devel@lists.xenproject.org; Fri, 24 Jan 2025 10:57:26 +0000
Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com
 [2607:f8b0:4864:20::630])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id facf0e84-da41-11ef-99a4-01e77a169b0f;
 Fri, 24 Jan 2025 11:57:19 +0100 (CET)
Received: by mail-pl1-x630.google.com with SMTP id
 d9443c01a7336-216395e151bso26014925ad.0
 for <xen-devel@lists.xenproject.org>; Fri, 24 Jan 2025 02:57:24 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-21da3d9e09dsm13814305ad.23.2025.01.24.02.57.21
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 24 Jan 2025 02:57:22 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: facf0e84-da41-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737716243; x=1738321043; 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=rFQIflmp26yTsLJbWxnGkhpLA53I4s54Cp17dTKkwog=;
        b=ajJafDITsHfy9dyreKRUUqHo+jKBn6XqDeF0UGwxjd+u4MO/BvlCsMsHsB5N1x0wdN
         qp0/IHz+TItnAUprR5aSHRlGzpmoRl8buFs/Meu+8WxmtgYN54n9zrjRelOiwajHhEF9
         8OyjPV3G4hc9PY6OV2oHXExgZ6JtjM3TSVACU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737716243; x=1738321043;
        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=rFQIflmp26yTsLJbWxnGkhpLA53I4s54Cp17dTKkwog=;
        b=LLjPt3w6WbS5ZV16/NBFFmECoDPOv4KiHikxRaWS0oa71ccVSJlPYv6TyTsQJhyrJm
         +A1uXVUpw5XMLpKRD0m/5t6l6OJxUP2A8ksyrgsHkr5BKfE9SltNVKzL3m43wdAEOr4T
         ssOWMX3wrZ08vNQsQ2C90ob5kJTOnwEGV+vCPhgph1a/mCJReXXuOuaiOTDKLIVXitOS
         QcPwttp2FDAdN1NV49A7gC5XP0kPY+T8udS6ft4l1zShfSXYsoYTyd0ktM3xYs5jac2z
         sZKsNE25CXsUamYnjolMZcj1Xp0D9K2rsF17FEztiWS7lpeauf3AHb1aNXrHpSiJPD4b
         4wHA==
X-Gm-Message-State: AOJu0YyPdil7vysOJyce+uQnlKZWA5KwHGIX3nfv5ZGMtwbG5SO/Ss9A
	KpNipJXdAHw3UJdrlQYXgVAwSWoXNXQLMbHl0EswhcrUuJvNebpTbcXnSfoELRo=
X-Gm-Gg: ASbGncsbPceNuXWdL3ZdsnQq/TMctpZnbEYbIPWJ1ptSWAwJRRFWf2H6QOu23lbBsiA
	wWLQ3NaUYozBq/pERu4+W6FXe9Eum09kkEvpqi0mvqJxZPkolLE4dK7UHtqQs2p3T1RqNNv6gu2
	Ggc/phCg1uxf+AGSCaClpOeUYm8oFEEs8081BhZI35NKXzvPrmOySuXUxUUuOgZHDsLdISozjSw
	rae3IgdCA+yqpPOzxk5SKa1QgtwxT4nbBFKJ7QtchaC1JtsPH4yJvPEM0FWRGKP/ymW3TXNhr2X
	RXQsIJcFbRE26M8=
X-Google-Smtp-Source: AGHT+IF25OZFiLio9neQOJNfyfp9Y7pK1Oo6zaWPwQ1t22frCvYY7dDwDHB4ncAs4lOGRe1aP5519w==
X-Received: by 2002:a17:902:ea02:b0:216:4676:dfb5 with SMTP id d9443c01a7336-21d9937d527mr105145015ad.21.1737716243426;
        Fri, 24 Jan 2025 02:57:23 -0800 (PST)
Date: Fri, 24 Jan 2025 11:57:17 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
	Kevin Tian <kevin.tian@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>
Subject: Re: [PATCH v3 04/12] VMX: convert vmx_basic_msr
Message-ID: <Z5NyDfY_ja3hr96P@macbook.local>
References: <293e5aef-8843-461c-bc96-709a605b2680@suse.com>
 <eb9874c7-a392-49c2-a610-cf7ff45a3e3b@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <eb9874c7-a392-49c2-a610-cf7ff45a3e3b@suse.com>

On Mon, Feb 26, 2024 at 05:43:21PM +0100, Jan Beulich wrote:
> ... to a struct field, which is then going to be accompanied by other
> capability/control data presently living in individual variables. As
> this structure isn't supposed to be altered post-boot, put it in
> .data.ro_after_init right away.
> 
> Suggested-by: Roger Pau Monné <roger.pau@citrix.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jan 24 11:02:28 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Jan 2025 11:02:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876678.1287033 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbHSF-0006kU-77; Fri, 24 Jan 2025 11:02:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876678.1287033; Fri, 24 Jan 2025 11:02:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbHSF-0006kN-3F; Fri, 24 Jan 2025 11:02:27 +0000
Received: by outflank-mailman (input) for mailman id 876678;
 Fri, 24 Jan 2025 11:02:26 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=AkuS=UQ=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tbHSE-0006kH-Co
 for xen-devel@lists.xenproject.org; Fri, 24 Jan 2025 11:02:26 +0000
Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com
 [2607:f8b0:4864:20::635])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ad4bea6c-da42-11ef-99a4-01e77a169b0f;
 Fri, 24 Jan 2025 12:02:19 +0100 (CET)
Received: by mail-pl1-x635.google.com with SMTP id
 d9443c01a7336-219f8263ae0so36375475ad.0
 for <xen-devel@lists.xenproject.org>; Fri, 24 Jan 2025 03:02:24 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-72f8a78f317sm1583806b3a.176.2025.01.24.03.02.21
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 24 Jan 2025 03:02:22 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ad4bea6c-da42-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737716543; x=1738321343; 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=y5iX+PGEJ6GpHjvYAaAoXQh+m+2PBM8nT4eMQKseUCU=;
        b=kq2dHEbH3I6B2PQ/06F4+ySzkmNwyCRckAIPmReTkTNI30ZBoHDpJUZYZah5wp/K2l
         Gu5rRqWdjdBfpSpYwadaShcbbhX83ZNpxmHUKj/V358zN8TA026Q01TaSOs5IpiFRu/L
         8tn8x5bxveTfuDBzYUDuFleaqVCN1Jvs9CtlY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737716543; x=1738321343;
        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=y5iX+PGEJ6GpHjvYAaAoXQh+m+2PBM8nT4eMQKseUCU=;
        b=YfMPCR/Na+i/knuGzONfhLv1pP31qXYEM74KiMj/U5HhYj5qTNji7CbQVIj1m3MUMV
         ZO6LtUa8ZaLJMbc4euEanhZrZwdsPYSAq4UdAMQU6eV7EN2sQGO0tkKuLRQ2HgzjHhnF
         BrIGBrWJjoRWi4YndG5+xZN0q+7FFbtLCgVxJE8BGYJMsEsjf5Ih8avQ0LP+hAxQNKT5
         7Ue8woEryaVrPXJLgwfYGo4S4BkrR5C2aIDwmopzhwl6wjM5WwmIhMVt0gFj0fYVx2Py
         WuWmBD4foVvz70R2crHLZOHOQz8vQSHc9xQLAm/Pnk/zGEkENmeuDg6v4qaqj3BugXi0
         3rYg==
X-Gm-Message-State: AOJu0YzTCf13NxpEHACzBsO8EQJS9lZOiAQc09/IWlC0GPUDvvmQsK7p
	GZ9+hG16OdDRP0peRvj4nP9x/CwvJ/uSVIxMXBwvwKqACRyyEaRi+6xhcDscnJo=
X-Gm-Gg: ASbGncs+edx/tbpJZnx++gsjz2qMuh5ae1OuYsqhTkV67RDO5dQv1cIDLPN+XUsRmhE
	Izs7n5DegJzuszeylesM7ElnfBuR0jIiczhkpfDCwQnZmHq1JFLAFznnVOymu1+EdX024FqPLRN
	fxkScUDGITkchPRCYGQmttEN+PxsqiFymGKwixepm8P/GfOqOmejuxqYwlOtSdV+Ff7wHpfZA/C
	//vZ1D2ZqYCzHMzLaD2Q6HgJxWAzKU2DGYYitLEqSYQZpxkiVaIXPpIvArwbJRv9pfWw7YmEfgF
	MIeoiVR4nn1gQFE=
X-Google-Smtp-Source: AGHT+IGaBEWz5RMs885I0m9+mTysZRLYcF2IAxNSiwmUi/rfdOuTY02tfK6N2sI0XreI3edLBse8PQ==
X-Received: by 2002:a05:6a00:244d:b0:71e:6c3f:2fb6 with SMTP id d2e1a72fcca58-72daf950b94mr50262422b3a.8.1737716542857;
        Fri, 24 Jan 2025 03:02:22 -0800 (PST)
Date: Fri, 24 Jan 2025 12:02:17 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
	Kevin Tian <kevin.tian@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>
Subject: Re: [PATCH v3 03/12] VMX: drop vmcs_revision_id
Message-ID: <Z5NzOUA-bWQMkh-_@macbook.local>
References: <293e5aef-8843-461c-bc96-709a605b2680@suse.com>
 <7a4ec627-f801-409b-995e-42732970e47c@suse.com>
 <Z5NwuaCBm4vxATUu@macbook.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <Z5NwuaCBm4vxATUu@macbook.local>

On Fri, Jan 24, 2025 at 11:51:37AM +0100, Roger Pau Monné wrote:
> On Mon, Feb 26, 2024 at 05:42:50PM +0100, Jan Beulich wrote:
> > It's effectively redundant with vmx_basic_msr. For the #define
> > replacement to work, struct vmcs_struct's respective field name also
> > needs to change: Drop the not really meaningful "vmcs_" prefix from it.
> > 
> > Signed-off-by: Jan Beulich <jbeulich@suse.com>
> > ---
> > v2: New.
> > 
> > --- a/xen/arch/x86/hvm/vmx/vmcs.c
> > +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> > @@ -175,7 +175,7 @@ static DEFINE_PER_CPU(paddr_t, current_v
> >  static DEFINE_PER_CPU(struct list_head, active_vmcs_list);
> >  DEFINE_PER_CPU(bool, vmxon);
> >  
> > -static u32 vmcs_revision_id __read_mostly;
> > +#define vmcs_revision_id (vmx_basic_msr & VMX_BASIC_REVISION_MASK)
> >  u64 __read_mostly vmx_basic_msr;
> 
> __ro_after_init maybe while at it (and then uint64_t also)?
> 
> I would place the #define after the definition of vmx_basic_msr, but
> that's just my taste.

I see that this gets further adjusted by the next patch, and the
comments I made are no longer relevant.

Acked-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jan 24 11:10:03 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Jan 2025 11:10:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876686.1287043 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbHZM-0007N0-SU; Fri, 24 Jan 2025 11:09:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876686.1287043; Fri, 24 Jan 2025 11:09:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbHZM-0007Mt-OM; Fri, 24 Jan 2025 11:09:48 +0000
Received: by outflank-mailman (input) for mailman id 876686;
 Fri, 24 Jan 2025 11:09:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=AkuS=UQ=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tbHZL-0007Mn-U3
 for xen-devel@lists.xenproject.org; Fri, 24 Jan 2025 11:09:47 +0000
Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com
 [2607:f8b0:4864:20::62c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b48fb139-da43-11ef-99a4-01e77a169b0f;
 Fri, 24 Jan 2025 12:09:40 +0100 (CET)
Received: by mail-pl1-x62c.google.com with SMTP id
 d9443c01a7336-2166360285dso34699615ad.1
 for <xen-devel@lists.xenproject.org>; Fri, 24 Jan 2025 03:09:46 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-72f8a77c7casm1595729b3a.139.2025.01.24.03.09.42
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 24 Jan 2025 03:09:44 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b48fb139-da43-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737716984; x=1738321784; 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=XhwjDzLmdgIzTMagG6tmcBvirtJNnZa7zDDq27LSVWc=;
        b=FAtnrSR41wGlw/mcUNP06vEUnu9B3C+QwY4zMj4AKZzKRtE6R8Mp0FjM/jYIXv20ze
         8KZjV+tfu03XeOl22xYb6Ad6OFXpkWlVa+jXEluudrOYvts+HKDJUKkKZGnIDibSu1Pb
         mxpDbvRBOQkOxjGQ0+83V53NEaBPW2nUUQb5E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737716984; x=1738321784;
        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=XhwjDzLmdgIzTMagG6tmcBvirtJNnZa7zDDq27LSVWc=;
        b=LuuUGVeGgNkFmNMeJpC1WeWukjvpqCmiG9kf7pkpjFgAJOKIyFRv1iFiggbzwNRj9H
         QDURVoGgyynZ2BvXg71fs5oGsqSh1IupZJSWEsoNfeFEzMHDD7QKzKqnRgWmLs65Fu3f
         hW1JCewA5JZq8CJAeBLbdEbrGLc9a6Rs5LPoKr2v2PrAB9KPmjI1Kl5cu8mGvwVmi9lF
         qofgNap5arOpnyUJZs2fAFGZx9uZkSKmTtk8xhwN8qfNN/HeLbcQ4mxAay4YCu0H0Nqr
         tSw3sZBAR2xMICZ9gGrp00QGMHIbBIl4T1vd2sh/osyJexlK6wtQBkrlqqQKwBx38E3a
         aotw==
X-Gm-Message-State: AOJu0YwI3X/HAa65/655l3np9bp6kTzJMpHoAa5sp+sZK9JdhCshywWJ
	tV+1ojYSN3Vtwa2qKLoEylC+zMrmmuEC3lLEfLeUMQT7Ai94Up2Lm8OusfvNJgg=
X-Gm-Gg: ASbGnctPt/5OaLENXqPEzAtxkjbw8yO7FQ6aMxXFZdWsFgUwlHuzg8xb8WxCK9cpDd9
	k/aSEn/BsAXZTWdLpiAQMVCGbpRlYOr0UQyJZlfz5mnTuZWXMAxoJG1WX/cDssnZ1+2tEI0dK9g
	XYSSgc9awxBGG0jK/FML5IuU8R0TGsC6u2uF+1O5OEbZdiyf9aQ6KdZeMYLZYvRvs37aHaEbKm7
	tKtbZDPlvIbqhmNLBiIofXbEIU0k+knbAR1NAL+0lgw/dqY8r/DfFI6+MoAQA7pbxTCcdzi+9Zw
	7ldbvHMOMTiaFwA=
X-Google-Smtp-Source: AGHT+IHySiw7jOdyC+v5hDObCzBP/Bqpr29abrUVqNiMB790KvukKNHww3L6KTyUcb3CIz4UNgopCA==
X-Received: by 2002:a05:6a00:4fcb:b0:727:99a8:cd31 with SMTP id d2e1a72fcca58-72daf97b5d3mr44134201b3a.14.1737716984565;
        Fri, 24 Jan 2025 03:09:44 -0800 (PST)
Date: Fri, 24 Jan 2025 12:09:39 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
	Kevin Tian <kevin.tian@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>
Subject: Re: [PATCH v3 00/12] x86/HVM: misc tidying
Message-ID: <Z5N085zua-Z8NJLI@macbook.local>
References: <293e5aef-8843-461c-bc96-709a605b2680@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <293e5aef-8843-461c-bc96-709a605b2680@suse.com>

On Mon, Feb 26, 2024 at 05:40:25PM +0100, Jan Beulich wrote:
> 01: VMX: don't run with CR4.VMXE set when VMX could not be enabled
> 02: x86/HVM: improve CET-IBT pruning of ENDBR
> 03: VMX: drop vmcs_revision_id
> 04: VMX: convert vmx_basic_msr
> 05: VMX: convert vmx_pin_based_exec_control
> 06: VMX: convert vmx_cpu_based_exec_control
> 07: VMX: convert vmx_secondary_exec_control
> 08: VMX: convert vmx_tertiary_exec_control
> 09: VMX: convert vmx_vmexit_control
> 10: VMX: convert vmx_vmentry_control
> 11: VMX: convert vmx_ept_vpid_cap
> 12: VMX: convert vmx_vmfunc

 For the "convert ..." ones:

 Acked-by: Roger Pau Monné <roger.pau@citrix.com>

 I've taken a quick look and it all looks like mechanical
 transformations.

 Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jan 24 12:01:29 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Jan 2025 12:01:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876703.1287061 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbING-0007qG-RQ; Fri, 24 Jan 2025 12:01:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876703.1287061; Fri, 24 Jan 2025 12:01:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbING-0007q7-OY; Fri, 24 Jan 2025 12:01:22 +0000
Received: by outflank-mailman (input) for mailman id 876703;
 Fri, 24 Jan 2025 12:01:21 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=AkuS=UQ=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tbINF-0007hy-PJ
 for xen-devel@lists.xenproject.org; Fri, 24 Jan 2025 12:01:21 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ec466dff-da4a-11ef-a0e5-8be0dac302b0;
 Fri, 24 Jan 2025 13:01:19 +0100 (CET)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-5d3cf094768so3917706a12.0
 for <xen-devel@lists.xenproject.org>; Fri, 24 Jan 2025 04:01:19 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5dc18619351sm1097563a12.5.2025.01.24.04.01.17
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 24 Jan 2025 04:01:18 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ec466dff-da4a-11ef-a0e5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737720079; x=1738324879; 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=9c2aZdvI/tbV2jY/GC3KfB8zoMuoAgzT2lT7lgwZi+o=;
        b=pLXBBQ8Yb1Ji0UKZVibD6anqwq5PmLrHcq6uBNaT287b7pBz/0DQ0tiEIMc+ZaWIOV
         32Dxj51cp9YNiFylI/H4qhwxEB/WDx/pQZsbW4g1J/WlfU2Fr8cXCW6N+UWTYdoiLW7C
         SxGctemr51Bm0ooktuc8o8Q1DTQf7Pg2GaduU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737720079; x=1738324879;
        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=9c2aZdvI/tbV2jY/GC3KfB8zoMuoAgzT2lT7lgwZi+o=;
        b=TqIneucwXtEyog3tRl/6MSgr0aF9Cv0vRfItOWLRuFmX4eQNW32h2bhCMt2wXZUAv4
         LmeNY8g6k5AnBjWr1cbba4GFOFgVef2uej7fWBDMRC1F9fZtiXewHuTu2yA1pP8K4kyX
         h/H2t0TYIcLekVJEoEQv07Fp8uHJ2dr/EGxtFHFzUK1+inhUCiJmyEFp1lfggZqAtBGv
         cpKK8cdjhxcOxm0dfXblOMR4szJQ8EAVcqx5ldwZW6SZXcXIpbk6rvCEbz3n2zodE0kB
         v7+ROXSa9KhrIq89hkdUni4PTUeG4bDLylT4L2LQK8FVekez7yDh1802To0jUnRtv7OT
         dFNQ==
X-Gm-Message-State: AOJu0Yz1u8LmEw2YLNqpiZe4KzAfaCyiH5ddW6Gal7x8NHyPzJrRc+X0
	kSsFUZGc1HrxRLFmn/NAtm6uTXelIj2aX8/+gHti4Q51e3YuUszldwEQFOiRSd3y7ExrtPI8teh
	V
X-Gm-Gg: ASbGncvF+j/d0eO+ifBuSS8kYwTtbpD3EPNUigu2vb/kb2vxHTBnO5xDxCT1TU6Stlk
	p+ziDgHlKoI5Iq3BfB5T9+T66CN6qppJmVDFekHYiwGgNX4TokL8Jq19zbwKcvYkfMAWu4AU2+q
	Lnt7r18VZIqS8oVqOPVeGIanTb4cGS7zqFqLJcYI/JkAg0p2j52FQdmcdrOBMhHRmrJ4U7aA4kB
	AfmBDTy6OVlaSSuQm/DA0M7k2yHK7ooX89n2fkGSxGOhQCMqHI+Nlx6MeP7M3XIablpRqFlt6gU
	OdSg9mNEa8qEvy4=
X-Google-Smtp-Source: AGHT+IGtakv+VJopi6Jb6eXJ3iLF9dXAUCjJf06TVnJ0NdxUWVim75lvthE0amCrD/9kE8DxqYdmCQ==
X-Received: by 2002:a05:6402:348b:b0:5db:67a7:e75e with SMTP id 4fb4d7f45d1cf-5db7d2ec452mr27893397a12.5.1737720079038;
        Fri, 24 Jan 2025 04:01:19 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Teddy Astie <teddy.astie@vates.tech>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PATCH v2 1/5] x86/iommu: check for CMPXCHG16B when enabling IOMMU
Date: Fri, 24 Jan 2025 13:01:07 +0100
Message-ID: <20250124120112.56678-2-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250124120112.56678-1-roger.pau@citrix.com>
References: <20250124120112.56678-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: Teddy Astie <teddy.astie@vates.tech>

All hardware with VT-d/AMD-Vi has CMPXCHG16B support. Check this at
initialisation time, and remove the effectively-dead logic for the
non-cx16 case.

If the local APICs support x2APIC mode the IOMMU support for interrupt
remapping will be checked earlier using a specific helper.  If no support
for CX16 is detected by that earlier hook disable the IOMMU at that point
and prevent further poking for CX16 later in the boot process, which would
also fail.

There's a possible corner case when running virtualized, and the underlying
hypervisor exposing an IOMMU but no CMPXCHG16B support.  In which case
ignoring the IOMMU is fine, albeit the most natural would be for the
underlying hypervisor to also expose CMPXCHG16B support if an IOMMU is
available to the VM.

Note this change only introduces the checks, but doesn't remove the now
stale checks for CX16 support sprinkled in the IOMMU code.  Further changes
will take care of that.

Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Changes since pickup:
 - Unify all CX16 checks into a single patch.
---
 xen/drivers/passthrough/amd/iommu_intr.c    | 13 +++++++++++++
 xen/drivers/passthrough/amd/pci_amd_iommu.c |  6 ++++++
 xen/drivers/passthrough/vtd/intremap.c      | 13 +++++++++++++
 xen/drivers/passthrough/vtd/iommu.c         |  7 +++++++
 4 files changed, 39 insertions(+)

diff --git a/xen/drivers/passthrough/amd/iommu_intr.c b/xen/drivers/passthrough/amd/iommu_intr.c
index 7fc796dec25b..f07fd9e3d970 100644
--- a/xen/drivers/passthrough/amd/iommu_intr.c
+++ b/xen/drivers/passthrough/amd/iommu_intr.c
@@ -649,6 +649,19 @@ bool __init cf_check iov_supports_xt(void)
     if ( !iommu_enable || !iommu_intremap )
         return false;
 
+    if ( unlikely(!cpu_has_cx16) )
+    {
+        AMD_IOMMU_ERROR("no CMPXCHG16B support, disabling IOMMU\n");
+        /*
+         * Disable IOMMU support at once: there's no reason to check for CX16
+         * yet again when attempting to initialize IOMMU DMA remapping
+         * functionality or interrupt remapping without x2APIC support.
+         */
+        iommu_enable = false;
+        iommu_intremap = iommu_intremap_off;
+        return false;
+    }
+
     if ( amd_iommu_prepare(true) )
         return false;
 
diff --git a/xen/drivers/passthrough/amd/pci_amd_iommu.c b/xen/drivers/passthrough/amd/pci_amd_iommu.c
index 73dcc4a2dd0c..f96f59440bcc 100644
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -309,6 +309,12 @@ static int __init cf_check iov_detect(void)
     if ( !iommu_enable && !iommu_intremap )
         return 0;
 
+    if ( unlikely(!cpu_has_cx16) )
+    {
+        AMD_IOMMU_ERROR("no CMPXCHG16B support, disabling IOMMU\n");
+        return -ENODEV;
+    }
+
     if ( (init_done ? amd_iommu_init_late()
                     : amd_iommu_init(false)) != 0 )
     {
diff --git a/xen/drivers/passthrough/vtd/intremap.c b/xen/drivers/passthrough/vtd/intremap.c
index c504852eb818..233db5cb64de 100644
--- a/xen/drivers/passthrough/vtd/intremap.c
+++ b/xen/drivers/passthrough/vtd/intremap.c
@@ -150,6 +150,19 @@ bool __init cf_check intel_iommu_supports_eim(void)
     if ( !iommu_qinval || !iommu_intremap || list_empty(&acpi_drhd_units) )
         return false;
 
+    if ( unlikely(!cpu_has_cx16) )
+    {
+        printk(XENLOG_ERR VTDPREFIX "no CMPXCHG16B support, disabling IOMMU\n");
+        /*
+         * Disable IOMMU support at once: there's no reason to check for CX16
+         * yet again when attempting to initialize IOMMU DMA remapping
+         * functionality or interrupt remapping without x2APIC support.
+         */
+        iommu_enable = false;
+        iommu_intremap = iommu_intremap_off;
+        return false;
+    }
+
     /* We MUST have a DRHD unit for each IOAPIC. */
     for ( apic = 0; apic < nr_ioapics; apic++ )
         if ( !ioapic_to_drhd(IO_APIC_ID(apic)) )
diff --git a/xen/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/vtd/iommu.c
index 27a4d1640189..3daedc4f5593 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -2633,6 +2633,13 @@ static int __init cf_check vtd_setup(void)
     int ret;
     bool reg_inval_supported = true;
 
+    if ( unlikely(!cpu_has_cx16) )
+    {
+        printk(XENLOG_ERR VTDPREFIX "no CMPXCHG16B support, disabling IOMMU\n");
+        ret = -ENODEV;
+        goto error;
+    }
+
     if ( list_empty(&acpi_drhd_units) )
     {
         ret = -ENODEV;
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Fri Jan 24 12:01:29 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Jan 2025 12:01:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876705.1287082 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbINL-0008Nd-AE; Fri, 24 Jan 2025 12:01:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876705.1287082; Fri, 24 Jan 2025 12:01:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbINL-0008NW-7D; Fri, 24 Jan 2025 12:01:27 +0000
Received: by outflank-mailman (input) for mailman id 876705;
 Fri, 24 Jan 2025 12:01:25 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=AkuS=UQ=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tbINJ-0007bK-AC
 for xen-devel@lists.xenproject.org; Fri, 24 Jan 2025 12:01:25 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ee63f287-da4a-11ef-99a4-01e77a169b0f;
 Fri, 24 Jan 2025 13:01:23 +0100 (CET)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-aa679ad4265so621868266b.0
 for <xen-devel@lists.xenproject.org>; Fri, 24 Jan 2025 04:01:23 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab675e67814sm118167666b.74.2025.01.24.04.01.21
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 24 Jan 2025 04:01:21 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ee63f287-da4a-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737720083; x=1738324883; 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=DVt6Rj0kKo02aeVOLnGhddbw+hEtfAmvfyBCodPtZ6g=;
        b=JjODsrszv1U9dsAa9ZtCSc+3fGm8uAtr9j//kzUgExAbu0YBHq76aHArgngrDpcPJY
         oioCuMphviKhZZTgQ/Q8a42j7EBwgpgmY3LD7NSPSKWFVTaXUUraXHoj1QQ6cUOcqkQP
         69G0skxDdJwgaeSN60eoPF7aZniL/+VDw8hsc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737720083; x=1738324883;
        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=DVt6Rj0kKo02aeVOLnGhddbw+hEtfAmvfyBCodPtZ6g=;
        b=MurSlX3vyiLQv5si8Euj4ULVsE1AbTer5htVUIINxhgfH+VVpmqj+EBM5LE++Opqyr
         /LS9cFm1KaRrVnGkmAqPQe9a6HMZi5cvGjAwORXenHNV6gy4M8eRZc9lEwnETt6adHoo
         9oxvSP36Mn/pg+V6pqGheGTL9ONZ3iqdrZfJELiTW75uPm2ygwFIOOlAvECy2FtFWGZ/
         Z2rp5sVQZ1YZdsfkQdWm4HgHIciZUl3KpSUr6owKDepGdyWeiFZgcQGUgddrOGjefsb9
         fpSYUEFnZ6OUMlSY6YWNl1BcVYdrO5dA+5lI3DZj2CYgI+Rk3kkub7H0vTpNkflfa+Mo
         0Atg==
X-Gm-Message-State: AOJu0YyddWyrRp+7WvXOyJ2koWDdRsixLTpsoYjqxMJ9fyPLV7e1Yi5K
	02BPFp9ugSz/GORbdROQ0HqiTsMjCQ2vim8oWadhHduGwfgYthpxIm8rTQ2v/O6VlvwwGW3QC0g
	n
X-Gm-Gg: ASbGncvHqKIYM/ikYPd4FjdJQMCOq+sh+n6d+VNULrueC5wDRAXW/Tf0v8cM2+cczXW
	DCpdlzYta6AcQlaHE9ll3aVAKpZ7zu/r5GDw1F4C0SMzOsDY09RIW848nTHu6yJsnLQCtPRFbR4
	9/348KnsCB2YjzDv87o3RWvq62Y53NtUXgJAUm/3zm3c6VRmURBWmn/A4iR27gq6r/vf7JU5fcQ
	9zD+weAvBHQqbW0J+/F83EPoU5VRGGFTDmEA5EPKOADZMTh7DcZ9CRVQo5f8e/UnduXT83ouy7c
	Bdv1MDRf8I0hz7Q=
X-Google-Smtp-Source: AGHT+IGR5urwaiLF47OwHM87ZTumEm4WxfrMk8qLxpI+tZWW0hkbPvCEBF+0lO3eKM6AFRu5rh7bEA==
X-Received: by 2002:a17:907:3ea0:b0:aa6:88a2:cfbd with SMTP id a640c23a62f3a-ab662a001f0mr501155566b.22.1737720082614;
        Fri, 24 Jan 2025 04:01:22 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Teddy Astie <teddy.astie@vates.tech>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PATCH v2 3/5] x86/iommu: remove non-CX16 logic from DMA remapping
Date: Fri, 24 Jan 2025 13:01:09 +0100
Message-ID: <20250124120112.56678-4-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250124120112.56678-1-roger.pau@citrix.com>
References: <20250124120112.56678-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: Teddy Astie <teddy.astie@vates.tech>

As CX16 support is mandatory for IOMMU usage, the checks for CX16 in the
DMA remapping code are stale.  Remove them together with the associated
code introduced in case CX16 was not available.

Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/drivers/passthrough/amd/iommu_map.c | 42 +++++----------
 xen/drivers/passthrough/vtd/iommu.c     | 71 ++++++-------------------
 2 files changed, 31 insertions(+), 82 deletions(-)

diff --git a/xen/drivers/passthrough/amd/iommu_map.c b/xen/drivers/passthrough/amd/iommu_map.c
index 1f0e4167566b..dde393645a62 100644
--- a/xen/drivers/passthrough/amd/iommu_map.c
+++ b/xen/drivers/passthrough/amd/iommu_map.c
@@ -167,15 +167,14 @@ int amd_iommu_set_root_page_table(struct amd_iommu_dte *dte,
 {
     bool valid = flags & SET_ROOT_VALID;
 
-    if ( dte->v && dte->tv &&
-         (cpu_has_cx16 || (flags & SET_ROOT_WITH_UNITY_MAP)) )
+    if ( dte->v && dte->tv )
     {
         union {
             struct amd_iommu_dte dte;
             uint64_t raw64[4];
             __uint128_t raw128[2];
         } ldte = { .dte = *dte };
-        __uint128_t old = ldte.raw128[0];
+        __uint128_t res, old = ldte.raw128[0];
         int ret = 0;
 
         ldte.dte.domain_id = domain_id;
@@ -185,33 +184,20 @@ int amd_iommu_set_root_page_table(struct amd_iommu_dte *dte,
         ldte.dte.paging_mode = paging_mode;
         ldte.dte.v = valid;
 
-        if ( cpu_has_cx16 )
-        {
-            __uint128_t res = cmpxchg16b(dte, &old, &ldte.raw128[0]);
+        res = cmpxchg16b(dte, &old, &ldte.raw128[0]);
 
-            /*
-             * Hardware does not update the DTE behind our backs, so the
-             * return value should match "old".
-             */
-            if ( res != old )
-            {
-                printk(XENLOG_ERR
-                       "Dom%d: unexpected DTE %016lx_%016lx (expected %016lx_%016lx)\n",
-                       domain_id,
-                       (uint64_t)(res >> 64), (uint64_t)res,
-                       (uint64_t)(old >> 64), (uint64_t)old);
-                ret = -EILSEQ;
-            }
-        }
-        else /* Best effort, updating domain_id last. */
+        /*
+         * Hardware does not update the DTE behind our backs, so the
+         * return value should match "old".
+         */
+        if ( res != old )
         {
-            uint64_t *ptr = (void *)dte;
-
-            write_atomic(ptr + 0, ldte.raw64[0]);
-            /* No barrier should be needed between these two. */
-            write_atomic(ptr + 1, ldte.raw64[1]);
-
-            ret = 1;
+            printk(XENLOG_ERR
+                   "Dom%d: unexpected DTE %016lx_%016lx (expected %016lx_%016lx)\n",
+                   domain_id,
+                   (uint64_t)(res >> 64), (uint64_t)res,
+                   (uint64_t)(old >> 64), (uint64_t)old);
+            ret = -EILSEQ;
         }
 
         return ret;
diff --git a/xen/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/vtd/iommu.c
index 3daedc4f5593..b0963bfcf74e 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1485,7 +1485,7 @@ int domain_context_mapping_one(
 {
     struct domain_iommu *hd = dom_iommu(domain);
     struct context_entry *context, *context_entries, lctxt;
-    __uint128_t old;
+    __uint128_t res, old;
     uint64_t maddr;
     uint16_t seg = iommu->drhd->segment, prev_did = 0;
     struct domain *prev_dom = NULL;
@@ -1583,55 +1583,23 @@ int domain_context_mapping_one(
         ASSERT(!context_fault_disable(lctxt));
     }
 
-    if ( cpu_has_cx16 )
-    {
-        __uint128_t res = cmpxchg16b(context, &old, &lctxt.full);
-
-        /*
-         * Hardware does not update the context entry behind our backs,
-         * so the return value should match "old".
-         */
-        if ( res != old )
-        {
-            if ( pdev )
-                check_cleanup_domid_map(domain, pdev, iommu);
-            printk(XENLOG_ERR
-                   "%pp: unexpected context entry %016lx_%016lx (expected %016lx_%016lx)\n",
-                   &PCI_SBDF(seg, bus, devfn),
-                   (uint64_t)(res >> 64), (uint64_t)res,
-                   (uint64_t)(old >> 64), (uint64_t)old);
-            rc = -EILSEQ;
-            goto unlock;
-        }
-    }
-    else if ( !prev_dom || !(mode & MAP_WITH_RMRR) )
-    {
-        context_clear_present(*context);
-        iommu_sync_cache(context, sizeof(*context));
+    res = cmpxchg16b(context, &old, &lctxt.full);
 
-        write_atomic(&context->hi, lctxt.hi);
-        /* No barrier should be needed between these two. */
-        write_atomic(&context->lo, lctxt.lo);
-    }
-    else /* Best effort, updating DID last. */
+    /*
+     * Hardware does not update the context entry behind our backs,
+     * so the return value should match "old".
+     */
+    if ( res != old )
     {
-         /*
-          * By non-atomically updating the context entry's DID field last,
-          * during a short window in time TLB entries with the old domain ID
-          * but the new page tables may be inserted.  This could affect I/O
-          * of other devices using this same (old) domain ID.  Such updating
-          * therefore is not a problem if this was the only device associated
-          * with the old domain ID.  Diverting I/O of any of a dying domain's
-          * devices to the quarantine page tables is intended anyway.
-          */
-        if ( !(mode & (MAP_OWNER_DYING | MAP_SINGLE_DEVICE)) )
-            printk(XENLOG_WARNING VTDPREFIX
-                   " %pp: reassignment may cause %pd data corruption\n",
-                   &PCI_SBDF(seg, bus, devfn), prev_dom);
-
-        write_atomic(&context->lo, lctxt.lo);
-        /* No barrier should be needed between these two. */
-        write_atomic(&context->hi, lctxt.hi);
+        if ( pdev )
+            check_cleanup_domid_map(domain, pdev, iommu);
+        printk(XENLOG_ERR
+                "%pp: unexpected context entry %016lx_%016lx (expected %016lx_%016lx)\n",
+                &PCI_SBDF(seg, bus, devfn),
+                (uint64_t)(res >> 64), (uint64_t)res,
+                (uint64_t)(old >> 64), (uint64_t)old);
+        rc = -EILSEQ;
+        goto unlock;
     }
 
     iommu_sync_cache(context, sizeof(struct context_entry));
@@ -2702,12 +2670,7 @@ static int __init cf_check vtd_setup(void)
             iommu_intremap = iommu_intremap_off;
 
 #ifndef iommu_intpost
-        /*
-         * We cannot use posted interrupt if X86_FEATURE_CX16 is
-         * not supported, since we count on this feature to
-         * atomically update 16-byte IRTE in posted format.
-         */
-        if ( !cap_intr_post(iommu->cap) || !iommu_intremap || !cpu_has_cx16 )
+        if ( !cap_intr_post(iommu->cap) || !iommu_intremap )
             iommu_intpost = false;
 #endif
 
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Fri Jan 24 12:01:29 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Jan 2025 12:01:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876704.1287071 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbINI-00084f-2C; Fri, 24 Jan 2025 12:01:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876704.1287071; Fri, 24 Jan 2025 12:01:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbINH-00084Y-VX; Fri, 24 Jan 2025 12:01:23 +0000
Received: by outflank-mailman (input) for mailman id 876704;
 Fri, 24 Jan 2025 12:01: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
 <SRS0=AkuS=UQ=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tbING-0007hy-Qr
 for xen-devel@lists.xenproject.org; Fri, 24 Jan 2025 12:01:22 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ed9c120f-da4a-11ef-a0e5-8be0dac302b0;
 Fri, 24 Jan 2025 13:01:22 +0100 (CET)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-ab65fca99b6so392579566b.0
 for <xen-devel@lists.xenproject.org>; Fri, 24 Jan 2025 04:01:22 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab675e67814sm118162466b.74.2025.01.24.04.01.19
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 24 Jan 2025 04:01:20 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ed9c120f-da4a-11ef-a0e5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737720081; x=1738324881; 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=zNc8xqr1uTUQn8IFfYe+22YL6fG0Xco7Sp/pdjdKu1o=;
        b=BOgD76sXrIjdPlAVicXZKECEDeobRT174WkCZNqU3w3O7+wlzTlhrl2hr2Q3wHCQ+q
         ksTdXdK43RNc3lsJLTRcqlxlF2S67j+fc81S6ocGwXQiRGeXYC1kShbxzEhv1I3/QUzS
         EYu61ElByuQo9KxVDwmw1UKazAjUcMhz9v8D8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737720081; x=1738324881;
        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=zNc8xqr1uTUQn8IFfYe+22YL6fG0Xco7Sp/pdjdKu1o=;
        b=N4b4sSuDzrQaTBho+Drp19mebo1X0IwIIz2Lkh7pbdKfyS9dfntMYXHQLNBvvPB3ir
         F8CgS67J49vRdTaXTWIhWDz39+Af9ydeMG4PSba2sVcT+sCJNVt5rVOrDLxd7wRDH0e4
         E+HkW9OJt66CqrQmlQ2I35v4yVzI7aBa7dY/FKQbLY6uIozPmEzGy3zfBAM2bEBgruIm
         fhTcGt0+UDBvlL5n0iCzshoWY+Heb4jx99zinZR8bCG2neRbwk1gxhDXiD0cXb8ol/dQ
         AuwGcBzglBa1GQ+zKLt9IQY6D9eiN2phKyjWZ3bnNZekA+EpB/saXCsmIs45LThSbYWr
         K7bg==
X-Gm-Message-State: AOJu0YwtXRn3Xc4O78JdHwVEHfahgVhF3eIYAJSSOG0aOQ1fsUBD8QaK
	1SlBBKi7LHHrlPZXwlLTwJAW7Br2Fqqygv1PkxAdbeKvGsyTD/YM9ASE///f8lePSYR+iVptgAh
	J
X-Gm-Gg: ASbGncsSRaxuxtgpPEiIFKQQ5prBU4/bQHVaqhNpZ+iuNga1Z4ls7OSVaR+Tc71iber
	LRSh1KYcR6Zs+jZqsXRLO67c91D50ua+XImLW9Y42NxOUkR7RJImQXFhUWrTCeUrDoInuNj3iOO
	SeO57DDQ5MTFPe0pYoUw3iD64U2Lf68ZSQ9c3H1qze2Ys7rKJZuvDPaDV4c/7m3QKnER9lc/S3r
	/kXC4pC1RHRVUSC2XViVIZ09gB8vXzHBZner162KwVJ+5IU5z9mQfMTFk6epPwu+7K+MWYtaXQM
	MN/9Z6Qe1eRu20k=
X-Google-Smtp-Source: AGHT+IFO3YfpnhWTuhY7pxWYDKGiB6uFLIA/iTPiVnXhamCt+AM7SEGZvi8MUKHqQXMNGwtAo2YyZg==
X-Received: by 2002:a17:907:940b:b0:aac:619:7ed8 with SMTP id a640c23a62f3a-ab38b1e651bmr2558293466b.7.1737720080876;
        Fri, 24 Jan 2025 04:01:20 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Teddy Astie <teddy.astie@vates.tech>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PATCH v2 2/5] iommu/vtd: remove non-CX16 logic from interrupt remapping
Date: Fri, 24 Jan 2025 13:01:08 +0100
Message-ID: <20250124120112.56678-3-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250124120112.56678-1-roger.pau@citrix.com>
References: <20250124120112.56678-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: Teddy Astie <teddy.astie@vates.tech>

As CX16 support is mandatory for IOMMU usage, the checks for CX16 in the
interrupt remapping code are stale.  Remove them together with the
associated code introduced in case CX16 was not available.

Note that AMD-Vi support for atomically updating a 128bit IRTE entry is
still not implemented, it will be done by further changes.

Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/drivers/passthrough/vtd/intremap.c | 75 +++++---------------------
 1 file changed, 14 insertions(+), 61 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/intremap.c b/xen/drivers/passthrough/vtd/intremap.c
index 233db5cb64de..820616a8de93 100644
--- a/xen/drivers/passthrough/vtd/intremap.c
+++ b/xen/drivers/passthrough/vtd/intremap.c
@@ -184,49 +184,26 @@ bool __init cf_check intel_iommu_supports_eim(void)
 
 /*
  * Assume iremap_lock has been acquired. It is to make sure software will not
- * change the same IRTE behind us. With this assumption, if only high qword or
- * low qword in IRTE is to be updated, this function's atomic variant can
- * present an atomic update to VT-d hardware even when cmpxchg16b
- * instruction is not supported.
+ * change the same IRTE behind us.
  */
 static void update_irte(struct vtd_iommu *iommu, struct iremap_entry *entry,
                         const struct iremap_entry *new_ire, bool atomic)
 {
-    ASSERT(spin_is_locked(&iommu->intremap.lock));
+    __uint128_t ret;
+    struct iremap_entry old_ire;
 
-    if ( cpu_has_cx16 )
-    {
-        __uint128_t ret;
-        struct iremap_entry old_ire;
+    ASSERT(spin_is_locked(&iommu->intremap.lock));
 
-        old_ire = *entry;
-        ret = cmpxchg16b(entry, &old_ire, new_ire);
+    old_ire = *entry;
+    ret = cmpxchg16b(entry, &old_ire, new_ire);
 
-        /*
-         * In the above, we use cmpxchg16 to atomically update the 128-bit
-         * IRTE, and the hardware cannot update the IRTE behind us, so
-         * the return value of cmpxchg16 should be the same as old_ire.
-         * This ASSERT validate it.
-         */
-        ASSERT(ret == old_ire.val);
-    }
-    else
-    {
-        /*
-         * VT-d hardware doesn't update IRTEs behind us, nor the software
-         * since we hold iremap_lock. If the caller wants VT-d hardware to
-         * always see a consistent entry, but we can't meet it, a bug will
-         * be raised.
-         */
-        if ( entry->lo == new_ire->lo )
-            write_atomic(&entry->hi, new_ire->hi);
-        else if ( entry->hi == new_ire->hi )
-            write_atomic(&entry->lo, new_ire->lo);
-        else if ( !atomic )
-            *entry = *new_ire;
-        else
-            BUG();
-    }
+    /*
+     * In the above, we use cmpxchg16 to atomically update the 128-bit
+     * IRTE, and the hardware cannot update the IRTE behind us, so
+     * the return value of cmpxchg16 should be the same as old_ire.
+     * This ASSERT validate it.
+     */
+    ASSERT(ret == old_ire.val);
 }
 
 /* Mark specified intr remap entry as free */
@@ -408,7 +385,6 @@ static int ioapic_rte_to_remap_entry(struct vtd_iommu *iommu,
     /* Indicate remap format. */
     remap_rte->format = 1;
 
-    /* If cmpxchg16b is not available the caller must mask the IO-APIC pin. */
     update_irte(iommu, iremap_entry, &new_ire, !init && !masked);
     iommu_sync_cache(iremap_entry, sizeof(*iremap_entry));
     iommu_flush_iec_index(iommu, 0, index);
@@ -447,38 +423,15 @@ void cf_check io_apic_write_remap_rte(
 {
     struct IO_xAPIC_route_entry old_rte = {}, new_rte;
     struct vtd_iommu *iommu = ioapic_to_iommu(IO_APIC_ID(apic));
-    bool masked = true;
     int rc;
 
-    if ( !cpu_has_cx16 )
-    {
-       /*
-        * Cannot atomically update the IRTE entry: mask the IO-APIC pin to
-        * avoid interrupts seeing an inconsistent IRTE entry.
-        */
-        old_rte = __ioapic_read_entry(apic, pin, true);
-        if ( !old_rte.mask )
-        {
-            masked = false;
-            old_rte.mask = 1;
-            __ioapic_write_entry(apic, pin, true, old_rte);
-        }
-    }
-
     /* Not the initializer, for old gcc to cope. */
     new_rte.raw = rte;
 
     rc = ioapic_rte_to_remap_entry(iommu, apic, pin, &old_rte, new_rte);
     if ( rc )
-    {
-        if ( !masked )
-        {
-            /* Recover the original value of 'mask' bit */
-            old_rte.mask = 0;
-            __ioapic_write_entry(apic, pin, true, old_rte);
-        }
         return;
-    }
+
     /* old_rte will contain the updated IO-APIC RTE on success. */
     __ioapic_write_entry(apic, pin, true, old_rte);
 }
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Fri Jan 24 12:01:29 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Jan 2025 12:01:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876706.1287091 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbINM-0000DZ-Ml; Fri, 24 Jan 2025 12:01:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876706.1287091; Fri, 24 Jan 2025 12:01:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbINM-0000Cp-Jq; Fri, 24 Jan 2025 12:01:28 +0000
Received: by outflank-mailman (input) for mailman id 876706;
 Fri, 24 Jan 2025 12:01:27 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=AkuS=UQ=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tbINL-0007bK-Gs
 for xen-devel@lists.xenproject.org; Fri, 24 Jan 2025 12:01:27 +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 efed0514-da4a-11ef-99a4-01e77a169b0f;
 Fri, 24 Jan 2025 13:01:26 +0100 (CET)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-aafc9d75f8bso378375766b.2
 for <xen-devel@lists.xenproject.org>; Fri, 24 Jan 2025 04:01:26 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab675e12770sm119049166b.28.2025.01.24.04.01.23
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 24 Jan 2025 04:01:24 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: efed0514-da4a-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737720085; x=1738324885; 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=ZG7JEH3gSju1VydKP45xEoqkmeQzG5Nz2nBw/4zt1JY=;
        b=I2sEsWPX0nNYcf4zGoeeZQpf69Qrh7UQEYyzuIJdTDkoVcXkdXoXV9kO7MoSbjb5a7
         3vS63Hu/1rxCVrBsNAhJEX+6lJAR+X+FMfA1lrZF6vOiPW7slaSMnor8xsLMCZ4v3PBG
         WdBSGOxThvpluHYGBdqS0k100Df6IxbL/9Dkk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737720085; x=1738324885;
        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=ZG7JEH3gSju1VydKP45xEoqkmeQzG5Nz2nBw/4zt1JY=;
        b=GYK27V9ueMwQpMjKMG9YechbmYav7t5zlVPe7dzNuNk193GjyyfAndzMDei4v0/u7g
         XFIdbzxsJoxVpq/Kkx+HJZivNxn4CJUAfEeBSwoL335t/V+gmvof7Z+w8y0xge87MRrd
         0evMAWyZmQ0Wkwbm3grP3y31GBlSfRxJApMlJ1O9RUnZ71yjhjJcIYv3Jz2VFB2cCzx+
         K19ddlia0Y6xroOJw12eqz6UBogKRXsW5aAO2/aVJPYYZOYTi9OzBtSzOvePsKMxFTjQ
         dfneW4HxW1exv6glkR/y1eo2te3HaXVqigJuhDD1OA0AhiDxkLXIeCML/GnTVnK2Qezp
         9ezg==
X-Gm-Message-State: AOJu0YyCl+lYyKYf+bDhzSsFh6vj3ECadkMyOnaSr1XpS+yKBb+ZjEEQ
	xd5hC8naNXKHDcA0C9Xd+tUI8/2U6QWhpI1DJpKF88wDb/T1DS/+isWO1Cz/qVw9iJHl1frB1VU
	C
X-Gm-Gg: ASbGnctehdgaCPpvBKCYoVXM7ylH6SbrP7ZVhNtOtDB6FS2YbYQU+nh115YeWQCZGrF
	cIjkJs+eeOEWb8r3G8SYGb/m3ZSNSvcXEdza116sAJ/BD1Ou3ZkJAhv4Dd8oVlXAVWYfctrt69/
	v+/k5tI8QDjbuMdowu8qZiwdniUUdaMBA42aGS5Y9WLFEU3ikuc8dm6Pi4hCByb5bdGjqSs3RWN
	pM9r+Yva9ZqY1ql2L4pvbnlz+GGO6HfmSHWaRzPhX0SxxmJuP3Eo63YbIyBTSjL4FWsvJZyir4z
	5m4WnwtqGbSfACA=
X-Google-Smtp-Source: AGHT+IGwobbZw6n/IuGjK/JSvPcW4EXd/vH/ht5HiCBUBeIfVlLQYJB4jj+811xsVLL8IgmHXb0e+g==
X-Received: by 2002:a17:907:9408:b0:aa6:a87e:f2e1 with SMTP id a640c23a62f3a-ab38b4b96d0mr2693767166b.56.1737720085229;
        Fri, 24 Jan 2025 04:01:25 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Teddy Astie <teddy.astie@vates.tech>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [PATCH v2 4/5] iommu/vtd: cleanup MAP_SINGLE_DEVICE and related code
Date: Fri, 24 Jan 2025 13:01:10 +0100
Message-ID: <20250124120112.56678-5-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250124120112.56678-1-roger.pau@citrix.com>
References: <20250124120112.56678-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: Teddy Astie <teddy.astie@vates.tech>

This flag was only used in case cx16 is not available, as those code paths no
longer exist, this flag now does basically nothing.

Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/drivers/passthrough/vtd/iommu.c | 12 +++---------
 xen/drivers/passthrough/vtd/vtd.h   |  5 ++---
 2 files changed, 5 insertions(+), 12 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/vtd/iommu.c
index b0963bfcf74e..9d7a9977a6a6 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1695,15 +1695,9 @@ static int domain_context_mapping(struct domain *domain, u8 devfn,
         break;
     }
 
-    if ( domain != pdev->domain && pdev->domain != dom_io )
-    {
-        if ( pdev->domain->is_dying )
-            mode |= MAP_OWNER_DYING;
-        else if ( drhd &&
-                  !any_pdev_behind_iommu(pdev->domain, pdev, drhd->iommu) &&
-                  !pdev->phantom_stride )
-            mode |= MAP_SINGLE_DEVICE;
-    }
+    if ( domain != pdev->domain && pdev->domain != dom_io &&
+         pdev->domain->is_dying )
+        mode |= MAP_OWNER_DYING;
 
     switch ( pdev->type )
     {
diff --git a/xen/drivers/passthrough/vtd/vtd.h b/xen/drivers/passthrough/vtd/vtd.h
index 8aeff8c1f287..b95124517bd3 100644
--- a/xen/drivers/passthrough/vtd/vtd.h
+++ b/xen/drivers/passthrough/vtd/vtd.h
@@ -28,9 +28,8 @@
  */
 #define MAP_WITH_RMRR         (1u << 0)
 #define MAP_OWNER_DYING       (1u << 1)
-#define MAP_SINGLE_DEVICE     (1u << 2)
-#define MAP_ERROR_RECOVERY    (1u << 3)
-#define UNMAP_ME_PHANTOM_FUNC (1u << 4)
+#define MAP_ERROR_RECOVERY    (1u << 2)
+#define UNMAP_ME_PHANTOM_FUNC (1u << 3)
 
 /* Allow for both IOAPIC and IOSAPIC. */
 #define IO_xAPIC_route_entry IO_APIC_route_entry
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Fri Jan 24 12:01:29 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Jan 2025 12:01:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876702.1287052 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbINE-0007cA-Lg; Fri, 24 Jan 2025 12:01:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876702.1287052; Fri, 24 Jan 2025 12:01:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbINE-0007c3-ID; Fri, 24 Jan 2025 12:01:20 +0000
Received: by outflank-mailman (input) for mailman id 876702;
 Fri, 24 Jan 2025 12:01:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=AkuS=UQ=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tbIND-0007bK-Oo
 for xen-devel@lists.xenproject.org; Fri, 24 Jan 2025 12:01:19 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id eb1fe049-da4a-11ef-99a4-01e77a169b0f;
 Fri, 24 Jan 2025 13:01:18 +0100 (CET)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-aa679ad4265so621851966b.0
 for <xen-devel@lists.xenproject.org>; Fri, 24 Jan 2025 04:01:18 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab6760fbfbcsm117545266b.153.2025.01.24.04.01.15
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 24 Jan 2025 04:01:16 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: eb1fe049-da4a-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737720077; x=1738324877; 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=/7ZDQWGxPFGr8shs6Rg8vH5vtxlwu8uwF+5wx6Pt1eI=;
        b=IotB79FmXRi/GlvQtqrohcgpn4p4UDUFj+EpBBQPQ/YhZYAuOIc9tlBvO/QjTUlERI
         WjxrWlRFKV4oIxyPStDQiXsdf55cjP5yBfG4ISdLqXDs4l22cy9+/HseMNd/gtSqmhXc
         JQFxz2aXYsdXlNJM5L5q8m9WuMHhSdCRGWm3M=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737720077; x=1738324877;
        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=/7ZDQWGxPFGr8shs6Rg8vH5vtxlwu8uwF+5wx6Pt1eI=;
        b=Ig9vsyP0ONWpWRl4Smr/D5hs1goqgzgEdk6kvF6Cc4SyNgLU+WpPaLoiyhsGPg9hju
         SIIdhTkaJU3y/P+Pb6KMOKdEd9wi/RJvVYlN5ko1jWbfjPsO6ze91efC0cPiVI6NRd1y
         cI+SxCWz1a71wRbFxy7FMkV53WKX3g/BQZlrOlk8mGB4qarS+ZyEdVOvHwOmgr/DtWVm
         uNi5pNJ4TI9krp/hy4cxX9eaSSQNAiDWwDq310q4/Z5hJhHI7rJsA4GAhXv3hLgn9d+S
         EZSf9c5apHEywDn8YgndVTpqIt4LRzwbMtm8ifAtJ8POP+ooVjGJ67I8y5dXngunpsTi
         NUAQ==
X-Gm-Message-State: AOJu0Yw8338SLNO627M6Xjy4+Q9BAQ1TLkJCQgsvhCJJsvHxtIyZfarz
	7owPF9GBRy/rLJuZP8LYuFLxIpvQgu2r+lMk58M0Dsm0gqjlZ+Wro/gBUpJnTN/IrIpnIutteAT
	+
X-Gm-Gg: ASbGnct79/Vo8Pg8ojxw50AiEOyK5mEQ30KlCsA0o8HFT2KOtZ6LKw+CAAdxHSveoVM
	J99xHnExqsHW67JZTtYfGxOXO8jprSdLG2++cusLJKKkxu2SWPtDI0N5R3Dab79rxQGWv6tk4as
	X2pOQc5DlMsSMFUc8oSkH6Vq9gU8QT4kmXYgW6mN3ZCHjV9QxOknLVfyyFVPAzXm/r0wvQiAQSw
	M2REmS8vwq9gn8YMPZeK6KcqpgaKGisAIPrpe9aKZTj+D++6jnADcG0i5AWT5/8Gzx2NXX5hOIA
	sC18Q5zB/zaShu8=
X-Google-Smtp-Source: AGHT+IH9MzzNh5+IlDH4FLutc3tC/X55HB6u8bJWc/55jopMFhljDbrP8TKtVrPXbeBIwhctunMkIw==
X-Received: by 2002:a17:906:f584:b0:ab3:a2f9:d977 with SMTP id a640c23a62f3a-ab67466fca8mr227813866b.22.1737720077191;
        Fri, 24 Jan 2025 04:01:17 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: [PATCH v2 0/5] x86/iommu: make CX16 mandatory for IOMMU
Date: Fri, 24 Jan 2025 13:01:06 +0100
Message-ID: <20250124120112.56678-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Hello,

The following series is the original CX16 series sent by Teddy, with the
CX16 checks split into a separate patch, plus one extra patch to switch
AMD-Vi to use CMPXCHG16B when updating Interrupt Remapping Entries.

Note that last patch to use CMPXCHG16B fixes a real bug with AMD
hardware.

Thanks, Roger.

Roger Pau Monne (1):
  iommu/amd: atomically update IRTE

Teddy Astie (4):
  x86/iommu: check for CMPXCHG16B when enabling IOMMU
  iommu/vtd: remove non-CX16 logic from interrupt remapping
  x86/iommu: remove non-CX16 logic from DMA remapping
  iommu/vtd: cleanup MAP_SINGLE_DEVICE and related code

 xen/drivers/passthrough/amd/iommu_intr.c    | 88 ++++++++++----------
 xen/drivers/passthrough/amd/iommu_map.c     | 42 ++++------
 xen/drivers/passthrough/amd/pci_amd_iommu.c |  6 ++
 xen/drivers/passthrough/vtd/intremap.c      | 88 +++++++-------------
 xen/drivers/passthrough/vtd/iommu.c         | 90 +++++++--------------
 xen/drivers/passthrough/vtd/vtd.h           |  5 +-
 6 files changed, 121 insertions(+), 198 deletions(-)

-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Fri Jan 24 12:01:30 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Jan 2025 12:01:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876708.1287102 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbINO-0000Uz-0a; Fri, 24 Jan 2025 12:01:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876708.1287102; Fri, 24 Jan 2025 12:01:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbINN-0000UY-So; Fri, 24 Jan 2025 12:01:29 +0000
Received: by outflank-mailman (input) for mailman id 876708;
 Fri, 24 Jan 2025 12:01:29 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=AkuS=UQ=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tbINN-0007hy-5l
 for xen-devel@lists.xenproject.org; Fri, 24 Jan 2025 12:01:29 +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 f14bc8ef-da4a-11ef-a0e5-8be0dac302b0;
 Fri, 24 Jan 2025 13:01:28 +0100 (CET)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-ab2e308a99bso380588366b.1
 for <xen-devel@lists.xenproject.org>; Fri, 24 Jan 2025 04:01:28 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab6760ab21esm119803566b.91.2025.01.24.04.01.26
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 24 Jan 2025 04:01:27 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f14bc8ef-da4a-11ef-a0e5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737720087; x=1738324887; 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=fmWyXMHgHQ0P1pkeRIOSC5BWPtegTo9AV2b/sAitCDA=;
        b=Qi83Z7QgRg3Smm2WqWxfDEU/tHxOlKlav+sjDWXuyZmMorgcuBfXVglzujK/dUVFMO
         OajNmYMGiX2zcWDNtkMvrTNj46rDIhORR0V0xmbNxhmtwmH0ZaqDE8ZcZfOBF5qjKpfC
         4zeBNj87hl/YzPfcnGjRIhkMzoR6PHTUhbZes=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737720087; x=1738324887;
        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=fmWyXMHgHQ0P1pkeRIOSC5BWPtegTo9AV2b/sAitCDA=;
        b=RmqJrKXXRjwbPpOulMYi+wozZkzSsH3q8Q3ZMhe1MBlFKONo1UppATIhsFmk0PVugF
         +7pktf1TFyw8x41GTaxDULnYWIOsh57aOlxT9CucqrEOslsX2+OdOOLYSO4Vj1swBIf1
         J6557kfCr8NJ/uC/3hDXSLlVjLKGay8wIu6hDtAo2t8Nfn+oh8N+bTuFUOXRP4dUUk2n
         3IUK2c9B0KTi5LxrG5wUna3+gW3ps7IyNxTqVXohzMBa0/v/3GclBXhuJeDxlqnGwAB7
         VONFcYmhG6wR1OfuELRWBYBhQnhMKhikGvboxzqs5Cz8Y+lt2rFGuxGOLci/fyAMOPns
         CHoA==
X-Gm-Message-State: AOJu0Yyp6T9AtcHCgXeImh7Cw/cLTjAexEgbCIam5FQc1AhBs11ZYm+h
	tUvdkpjA01LxbkvBDZoCyKbzf40FEMPg09XPI4Lrm+MapzluY1p0ihHEDDycvTMMqw+gzS+fUQY
	d
X-Gm-Gg: ASbGncvn1ekXpGRrmKtlcjC1Vbex/rtxuC97vtPJgiMP79skCk/AzYNt5dktVvYTzoI
	gVmTH7BAp99EL01KI0ZV0XYbv50s9NkEYqYHc/YVtNLQVHz4TMQlW+A9knaPLmEYdoJqlmg/6yy
	q7MN4tjaTJdEsFqR2gGYxoao6SajnOeYCN7oaZRU3Kss6nSP2sbv456UdVrcoq7M5gXy6RabKkf
	X5HgQAFMcKTyu4ARW3qCur2HbbuCsSmUU+oYt0yh9NZKnSvET4JCusMzA4KIw93I5s6MYChD99L
	GHQFZm+sLw5cy88=
X-Google-Smtp-Source: AGHT+IGBGKgfieeigYW9s9OK8DaGTcbZVqcEXPQFnIqnHZAlx3xjKRNljOF2ZKSB/sGXA6FfIZrH4Q==
X-Received: by 2002:a17:907:7e96:b0:aa4:cd1e:c91b with SMTP id a640c23a62f3a-ab6745b8c27mr272502266b.7.1737720087493;
        Fri, 24 Jan 2025 04:01:27 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: [PATCH v2 5/5] iommu/amd: atomically update IRTE
Date: Fri, 24 Jan 2025 13:01:11 +0100
Message-ID: <20250124120112.56678-6-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250124120112.56678-1-roger.pau@citrix.com>
References: <20250124120112.56678-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Either when using a 32bit Interrupt Remapping Entry or a 128bit one update
the entry atomically, by using cmpxchg unconditionally as IOMMU depends on
it.  No longer disable the entry by setting RemapEn = 0 ahead of updating
it.  As a consequence of not toggling RemapEn ahead of the update the
Interrupt Remapping Table needs to be flushed after the entry update.

This avoids a window where the IRTE has RemapEn = 0, which can lead to
IO_PAGE_FAULT if the underlying interrupt source is not masked.

There's no guidance in AMD-Vi specification about how IRTE update should be
performed as opposed to DTE updating which has specific guidance.  However
DTE updating claims that reads will always be at least 128bits in size, and
hence for the purposes here assume that reads and caching of the IRTE
entries in either 32 or 128 bit format will be done atomically from
the IOMMU.

Note that as part of introducing a new raw128 field in the IRTE struct, the
current raw field is renamed to raw64 to explicitly contain the size in the
field name.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Changes since v1:
 - cmpxchg is now always available if the IOMMU is enabled.
---
 xen/drivers/passthrough/amd/iommu_intr.c | 75 ++++++++++--------------
 1 file changed, 32 insertions(+), 43 deletions(-)

diff --git a/xen/drivers/passthrough/amd/iommu_intr.c b/xen/drivers/passthrough/amd/iommu_intr.c
index f07fd9e3d970..c0273059cb1d 100644
--- a/xen/drivers/passthrough/amd/iommu_intr.c
+++ b/xen/drivers/passthrough/amd/iommu_intr.c
@@ -39,7 +39,8 @@ union irte32 {
 };
 
 union irte128 {
-    uint64_t raw[2];
+    uint64_t raw64[2];
+    __uint128_t raw128;
     struct {
         bool remap_en:1;
         bool sup_io_pf:1;
@@ -187,7 +188,7 @@ static void free_intremap_entry(const struct amd_iommu *iommu,
 
     if ( iommu->ctrl.ga_en )
     {
-        ACCESS_ONCE(entry.ptr128->raw[0]) = 0;
+        ACCESS_ONCE(entry.ptr128->raw64[0]) = 0;
         /*
          * Low half (containing RemapEn) needs to be cleared first.  Note that
          * strictly speaking smp_wmb() isn't enough, as conceptually it expands
@@ -197,7 +198,7 @@ static void free_intremap_entry(const struct amd_iommu *iommu,
          * variant will do.
          */
         smp_wmb();
-        entry.ptr128->raw[1] = 0;
+        entry.ptr128->raw64[1] = 0;
     }
     else
         ACCESS_ONCE(entry.ptr32->raw) = 0;
@@ -212,7 +213,7 @@ static void update_intremap_entry(const struct amd_iommu *iommu,
 {
     if ( iommu->ctrl.ga_en )
     {
-        union irte128 irte = {
+        const union irte128 irte = {
             .full = {
                 .remap_en = true,
                 .int_type = int_type,
@@ -222,19 +223,26 @@ static void update_intremap_entry(const struct amd_iommu *iommu,
                 .vector = vector,
             },
         };
+        __uint128_t old = entry.ptr128->raw128;
+        __uint128_t res = cmpxchg16b(&entry.ptr128->raw128, &old,
+                                     &irte.raw128);
 
-        ASSERT(!entry.ptr128->full.remap_en);
-        entry.ptr128->raw[1] = irte.raw[1];
         /*
-         * High half needs to be set before low one (containing RemapEn).  See
-         * comment in free_intremap_entry() regarding the choice of barrier.
+         * Hardware does not update the IRTE behind our backs, so the return
+         * value should match "old".
          */
-        smp_wmb();
-        ACCESS_ONCE(entry.ptr128->raw[0]) = irte.raw[0];
+        if ( res != old )
+        {
+            printk(XENLOG_ERR
+                   "unexpected IRTE %016lx_%016lx (expected %016lx_%016lx)\n",
+                   (uint64_t)(res >> 64), (uint64_t)res,
+                   (uint64_t)(old >> 64), (uint64_t)old);
+            ASSERT_UNREACHABLE();
+        }
     }
     else
     {
-        union irte32 irte = {
+        const union irte32 irte = {
             .flds = {
                 .remap_en = true,
                 .int_type = int_type,
@@ -299,21 +307,13 @@ static int update_intremap_entry_from_ioapic(
 
     entry = get_intremap_entry(iommu, req_id, offset);
 
-    /* The RemapEn fields match for all formats. */
-    while ( iommu->enabled && entry.ptr32->flds.remap_en )
-    {
-        entry.ptr32->flds.remap_en = false;
-        spin_unlock(lock);
-
-        amd_iommu_flush_intremap(iommu, req_id);
-
-        spin_lock(lock);
-    }
-
     update_intremap_entry(iommu, entry, vector, delivery_mode, dest_mode, dest);
 
     spin_unlock_irqrestore(lock, flags);
 
+    if ( !fresh )
+        amd_iommu_flush_intremap(iommu, req_id);
+
     set_rte_index(rte, offset);
 
     return 0;
@@ -322,7 +322,7 @@ static int update_intremap_entry_from_ioapic(
 void cf_check amd_iommu_ioapic_update_ire(
     unsigned int apic, unsigned int pin, uint64_t rte)
 {
-    struct IO_APIC_route_entry old_rte, new_rte;
+    struct IO_APIC_route_entry new_rte;
     int seg, bdf, rc;
     struct amd_iommu *iommu;
     unsigned int idx;
@@ -346,14 +346,6 @@ void cf_check amd_iommu_ioapic_update_ire(
         return;
     }
 
-    old_rte = __ioapic_read_entry(apic, pin, true);
-    /* mask the interrupt while we change the intremap table */
-    if ( !old_rte.mask )
-    {
-        old_rte.mask = 1;
-        __ioapic_write_entry(apic, pin, true, old_rte);
-    }
-
     /* Update interrupt remapping entry */
     rc = update_intremap_entry_from_ioapic(
              bdf, iommu, &new_rte,
@@ -425,6 +417,7 @@ static int update_intremap_entry_from_msi_msg(
     uint8_t delivery_mode, vector, dest_mode;
     spinlock_t *lock;
     unsigned int dest, offset, i;
+    bool fresh = false;
 
     req_id = get_dma_requestor_id(iommu->seg, bdf);
     alias_id = get_intremap_requestor_id(iommu->seg, bdf);
@@ -468,26 +461,21 @@ static int update_intremap_entry_from_msi_msg(
             return -ENOSPC;
         }
         *remap_index = offset;
+        fresh = true;
     }
 
     entry = get_intremap_entry(iommu, req_id, offset);
 
-    /* The RemapEn fields match for all formats. */
-    while ( iommu->enabled && entry.ptr32->flds.remap_en )
-    {
-        entry.ptr32->flds.remap_en = false;
-        spin_unlock(lock);
+    update_intremap_entry(iommu, entry, vector, delivery_mode, dest_mode, dest);
+    spin_unlock_irqrestore(lock, flags);
 
+    if ( !fresh )
+    {
         amd_iommu_flush_intremap(iommu, req_id);
         if ( alias_id != req_id )
             amd_iommu_flush_intremap(iommu, alias_id);
-
-        spin_lock(lock);
     }
 
-    update_intremap_entry(iommu, entry, vector, delivery_mode, dest_mode, dest);
-    spin_unlock_irqrestore(lock, flags);
-
     *data = (msg->data & ~(INTREMAP_MAX_ENTRIES - 1)) | offset;
 
     /*
@@ -735,7 +723,7 @@ static void dump_intremap_table(const struct amd_iommu *iommu,
     for ( count = 0; count < nr; count++ )
     {
         if ( iommu->ctrl.ga_en
-             ? !tbl.ptr128[count].raw[0] && !tbl.ptr128[count].raw[1]
+             ? !tbl.ptr128[count].raw64[0] && !tbl.ptr128[count].raw64[1]
              : !tbl.ptr32[count].raw )
                 continue;
 
@@ -748,7 +736,8 @@ static void dump_intremap_table(const struct amd_iommu *iommu,
 
         if ( iommu->ctrl.ga_en )
             printk("    IRTE[%03x] %016lx_%016lx\n",
-                   count, tbl.ptr128[count].raw[1], tbl.ptr128[count].raw[0]);
+                   count, tbl.ptr128[count].raw64[1],
+                   tbl.ptr128[count].raw64[0]);
         else
             printk("    IRTE[%03x] %08x\n", count, tbl.ptr32[count].raw);
     }
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Fri Jan 24 12:50:38 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Jan 2025 12:50:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876767.1287120 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbJ8q-0001LX-B7; Fri, 24 Jan 2025 12:50:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876767.1287120; Fri, 24 Jan 2025 12:50:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbJ8q-0001LQ-8G; Fri, 24 Jan 2025 12:50:32 +0000
Received: by outflank-mailman (input) for mailman id 876767;
 Fri, 24 Jan 2025 12:50:31 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=DEkt=UQ=linaro.org=alex.bennee@srs-se1.protection.inumbo.net>)
 id 1tbJ8p-0001LK-Eg
 for xen-devel@lists.xenproject.org; Fri, 24 Jan 2025 12:50:31 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id cb01e4af-da51-11ef-a0e5-8be0dac302b0;
 Fri, 24 Jan 2025 13:50:30 +0100 (CET)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-5dbfab8a2b0so3954884a12.3
 for <xen-devel@lists.xenproject.org>; Fri, 24 Jan 2025 04:50:30 -0800 (PST)
Received: from draig.lan ([85.9.250.243]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5dc186d905asm1135005a12.79.2025.01.24.04.50.28
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 24 Jan 2025 04:50:29 -0800 (PST)
Received: from draig (localhost [IPv6:::1])
 by draig.lan (Postfix) with ESMTP id 2C1185F8D0;
 Fri, 24 Jan 2025 12:50:28 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: cb01e4af-da51-11ef-a0e5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737723030; x=1738327830; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:user-agent
         :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=AB2Veo0ifNebcRcOL1ytt2gp+aiTiH3Sf5xY6qaSWgQ=;
        b=hteSdQFHbkx/KaSis005MSh1PJMc7PZd4hs+RqmLN9/JY7orduJyueQQugva8kI1ga
         2vjuwuEhVZcRNSuoxD9+oo35h7LboJmloaCGUCtkhcmaaTwzTlXlWyqiVY6Wh4uoC2pa
         MIVKZWRDd2SR9S5zjIJLx8xMuxqjRzT1E1EZNYfYaQBpU1Oj8901H0QiA/DHCcfiuG/+
         0Hp0I6thTFM6R5H60DdO2m1xjtIgA/09J7LprG8Kc38E/B1/kiFls7wU2WnLnj8S15Z/
         bml62UryxdnqVFSme7JiiPvyQ0iy0dr5ofmRw0btJtEO9JVTD4VPJbQFcR0/MxQ+GI6h
         NUWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737723030; x=1738327830;
        h=content-transfer-encoding:mime-version:message-id:date:user-agent
         :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from
         :to:cc:subject:date:message-id:reply-to;
        bh=AB2Veo0ifNebcRcOL1ytt2gp+aiTiH3Sf5xY6qaSWgQ=;
        b=QVfH0/i0PrZzzlbjKwyoQhDJTqL6Mhv6YhHmMuz48xUQTWFzAbYj6Z4/RRnJu75r43
         FViiB+PRHZdzXLeApQLkGYiZhneGipeQAF+0XVxHZMWyCnqR8lrTNCS0YfG76WMeVPxD
         Mx3CScFEQyiHURTPvdh0r2VhgO9pkc7ODIPksiwzmyG6pcQUSP7YrmbjA1FqGYdtNJ9p
         L6X1cc5FvIsQZwCxa16Zuh99gLYuQVN8PAvSAgcKqjCrRJnRAkNpRYZuqfIqSmEMUPAX
         31tKTNMQ+0qAR08yEGuN+wNBQT+0yib8OpTBtTogz10Ji2YAaSW7O0ysawjrhXgTXbI/
         jGyw==
X-Forwarded-Encrypted: i=1; AJvYcCWrdn7ETFmSuajYDFKiApbSve6hxDQFMdgfTSWXWFfY1bB4zqK9u2IucT2k7VdysU7dQ3J+EFpcHmU=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywpkv037ZtRlsdY6N8IY61P7dwGq1l3JvtTlJ2uaUu8QGJEigPL
	XLcd/dSbcya/YojRUnasrkIJrCWMw7J22BCgiEM+GR3YYdYkgomY7qXyuNwPDCQ=
X-Gm-Gg: ASbGncsHfd1BLvvQSYstTjxSFp+PEmPgl4q/F4Md1qKrpMgolQXfWsY8nm+DPgYbIti
	GUyllPUpg/nrP4xbPhwDngR3oamuQWN7EfYJGa7PXLjDzKXA6Q8GT6B9vWJiL+vWPraIjftz7Vv
	UG4g4hrNxNCpMj2MAGZDklqvJnIfTh3C41zACa8T/LkpLg4AgeruAqj41twO9Y3/rW2ZfLJrEBu
	mXJFIGdHMZ6uzvi9A+bbdTV/UfR/kpJniKTM8PqJrWklJMAVXuYGG383w/9uTrrNYTkc2+bhvMq
	n1I=
X-Google-Smtp-Source: AGHT+IHgpCErm6J9FACp/DlMJmoU6m0AQvWBem6CobohmkoE2PSx9F3d28v8z9FWDQeB/0B9Gf2dDQ==
X-Received: by 2002:a05:6402:4403:b0:5da:b47:1092 with SMTP id 4fb4d7f45d1cf-5db7d2f9b01mr25474703a12.10.1737723030120;
        Fri, 24 Jan 2025 04:50:30 -0800 (PST)
From: =?utf-8?Q?Alex_Benn=C3=A9e?= <alex.bennee@linaro.org>
To: Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= <philmd@linaro.org>
Cc: qemu-devel@nongnu.org,  Peter Maydell <peter.maydell@linaro.org>,  Paolo
 Bonzini <pbonzini@redhat.com>,  qemu-arm@nongnu.org,  Igor Mammedov
 <imammedo@redhat.com>,  kvm@vger.kernel.org,  qemu-ppc@nongnu.org,
  qemu-riscv@nongnu.org,  David Hildenbrand <david@redhat.com>,
  qemu-s390x@nongnu.org,  xen-devel@lists.xenproject.org,  Richard
 Henderson <richard.henderson@linaro.org>
Subject: Re: [PATCH 03/20] gdbstub: Check for TCG before calling tb_flush()
In-Reply-To: <20250123234415.59850-4-philmd@linaro.org> ("Philippe
	=?utf-8?Q?Mathieu-Daud=C3=A9=22's?= message of "Fri, 24 Jan 2025 00:43:57
 +0100")
References: <20250123234415.59850-1-philmd@linaro.org>
	<20250123234415.59850-4-philmd@linaro.org>
User-Agent: mu4e 1.12.8; emacs 29.4
Date: Fri, 24 Jan 2025 12:50:28 +0000
Message-ID: <878qr0jrzf.fsf@draig.linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Philippe Mathieu-Daud=C3=A9 <philmd@linaro.org> writes:

> Use the tcg_enabled() check so the compiler can elide
> the call when TCG isn't available, allowing to remove
> the tb_flush() stub.
>
> Signed-off-by: Philippe Mathieu-Daud=C3=A9 <philmd@linaro.org>

Reviewed-by: Alex Benn=C3=A9e <alex.bennee@linaro.org>

--=20
Alex Benn=C3=A9e
Virtualisation Tech Lead @ Linaro


From xen-devel-bounces@lists.xenproject.org Fri Jan 24 14:25:02 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Jan 2025 14:25:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876781.1287129 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbKbv-00053H-LM; Fri, 24 Jan 2025 14:24:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876781.1287129; Fri, 24 Jan 2025 14:24:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbKbv-00053A-Ir; Fri, 24 Jan 2025 14:24:39 +0000
Received: by outflank-mailman (input) for mailman id 876781;
 Fri, 24 Jan 2025 14:24: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
 <SRS0=gDdn=UQ=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tbKbt-000532-UU
 for xen-devel@lists.xenproject.org; Fri, 24 Jan 2025 14:24:37 +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 f004f827-da5e-11ef-a0e5-8be0dac302b0;
 Fri, 24 Jan 2025 15:24:36 +0100 (CET)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-438a39e659cso13971135e9.2
 for <xen-devel@lists.xenproject.org>; Fri, 24 Jan 2025 06:24:36 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438b1718741sm51772085e9.0.2025.01.24.06.24.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 24 Jan 2025 06:24:35 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f004f827-da5e-11ef-a0e5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737728675; x=1738333475; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=IbrNnHdKC0/LFwGAR0T6w8via2cDaA74ls46mFyUi1c=;
        b=LenSFj0AudFPOUq8C034X2sFT7ed3Zj/4WknFbkAFKiJsrR7yqwBpET1JC3I3BOPV+
         61N5kyYVQF5T0/1Xdvhd4VqJFt/MhtxXs0Kf0vNZumsf5Mt4vuwgSP0tA8enW/kmlDRL
         ptYVpXCM21z5Vf69bUscR/OyaF0Fa2HkKx3eI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737728675; x=1738333475;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=IbrNnHdKC0/LFwGAR0T6w8via2cDaA74ls46mFyUi1c=;
        b=HdrslniUjrTM0to62N2UjQA5g7MR/jGLFcf2SfGXtQRhRzrSehal/EdAQD1U6Rp9+O
         eWsCyMZ2ZJXaIxbKrNhafEBSi5Syfap4S4ifyv7Ut+KmBz5CNQkMF/ijNSgvAIXselH+
         iLefoJGIWcxQN7HBnTnHplrD9kDchPUCAcECrJW4wf2VvLxx0F5zd+y9fv+pu2LsHJLd
         Lg8Cax1Ql8Ssy4IaxzhdBtHfVo/tEAAaKnElMWMkZyH7J/SAlUuybMWngfgfF8yFXEKt
         n3FGn2xVdCb25LloS7yuM+T0WwIQaQwRuIgUqY6oSxUYL3N6NtVNZS8NTU/tEmUWNv0f
         O14Q==
X-Forwarded-Encrypted: i=1; AJvYcCWHA0djTwG6RbrdNANAvUur0mns9v5qpobzblvKsjgAe6j+whz3s93uSlq+b13PeYiyBqIS3V11vh0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwIGFBiavbwhsMxhK7o0ju9IvzHr3ua0Y9FvCDamnW8qoKSJ5DH
	CfGMb6Al1RtyAbVidqGBP1/PsVvLXPnNTWe0DL128WylIWPSK7IsJNTY6AiCl/4=
X-Gm-Gg: ASbGncs+pGQQxj9uYCsLl9cjxKIJ4JOOnmjA75wJ0/kBPMg5I5ZKCqLDoSuVaKzmWXw
	RcQ+L0eB3pA4Mm00Dpw3NAtvt2E8CBMEe4Rm4Z5U+BUB8WNBK0pgsYkqVCgPEbQ5vK6f3RTbsIE
	QT/FoCSXYwwmZ7p+4WfKfSObSHxN6Yvl+WFBW/vaKLXn3wbN9aDcwELm9GRlXEO1V2bYBBMrtel
	XjH/3Jb6ikOF2O0+wRuTZumkfe/86912wbWnMd4ZYmXVQD2mIxxgH8kaIrdC+HrT4ViYVkfd4L7
	j8qi+4XtYV6lKZBWPi4w8oSRvsPTsn1QBZPv9cSbSPqG
X-Google-Smtp-Source: AGHT+IEiDpRqlPWd9MM5v1ED+KckdXAM/s5MEZLMnKBj2It/usO39P2Ee7Ofdfdvxf45laUAAClW1g==
X-Received: by 2002:a05:600c:524f:b0:436:1b7a:c0b4 with SMTP id 5b1f17b1804b1-438913bed33mr235476295e9.1.1737728675558;
        Fri, 24 Jan 2025 06:24:35 -0800 (PST)
Message-ID: <3204bed4-4f03-405e-b77c-4355803f3a31@citrix.com>
Date: Fri, 24 Jan 2025 14:24:34 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20 v2 0/5] x86/iommu: make CX16 mandatory for IOMMU
To: Roger Pau Monne <roger.pau@citrix.com>, xen-devel@lists.xenproject.org
Cc: Jan Beulich <jbeulich@suse.com>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>
References: <20250124120112.56678-1-roger.pau@citrix.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <20250124120112.56678-1-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 24/01/2025 12:01 pm, Roger Pau Monne wrote:
> Hello,
>
> The following series is the original CX16 series sent by Teddy, with the
> CX16 checks split into a separate patch, plus one extra patch to switch
> AMD-Vi to use CMPXCHG16B when updating Interrupt Remapping Entries.
>
> Note that last patch to use CMPXCHG16B fixes a real bug with AMD
> hardware.
>
> Thanks, Roger.
>
> Roger Pau Monne (1):
>   iommu/amd: atomically update IRTE
>
> Teddy Astie (4):
>   x86/iommu: check for CMPXCHG16B when enabling IOMMU
>   iommu/vtd: remove non-CX16 logic from interrupt remapping
>   x86/iommu: remove non-CX16 logic from DMA remapping
>   iommu/vtd: cleanup MAP_SINGLE_DEVICE and related code

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

CC Oleksii.  Patch 5 is a real bugfix that needs backporting, and the
prior patches have been in an almost-ready state for more than a release
now.

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri Jan 24 14:27:59 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Jan 2025 14:27:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876791.1287140 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbKf8-0005jE-5x; Fri, 24 Jan 2025 14:27:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876791.1287140; Fri, 24 Jan 2025 14:27:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbKf8-0005j7-3H; Fri, 24 Jan 2025 14:27:58 +0000
Received: by outflank-mailman (input) for mailman id 876791;
 Fri, 24 Jan 2025 14:27:56 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=AkuS=UQ=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tbKf6-0005j0-OY
 for xen-devel@lists.xenproject.org; Fri, 24 Jan 2025 14:27:56 +0000
Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com
 [2607:f8b0:4864:20::1034])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 656a6fae-da5f-11ef-99a4-01e77a169b0f;
 Fri, 24 Jan 2025 15:27:53 +0100 (CET)
Received: by mail-pj1-x1034.google.com with SMTP id
 98e67ed59e1d1-2f44353649aso3083038a91.0
 for <xen-devel@lists.xenproject.org>; Fri, 24 Jan 2025 06:27:53 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-2f7ffafa400sm1733064a91.36.2025.01.24.06.27.50
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 24 Jan 2025 06:27:51 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 656a6fae-da5f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737728872; x=1738333672; 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=TDLg2K8MhJfOLYFUerOkwzHomdYiZlZ1KjiTzk4JjgI=;
        b=Hd+UpCPYBHXiOWio8OLtvtBuCcel10qLhP/+TrHgIQZzgtLFUsfc6gm7CoGJhxaKIO
         ayr8bzcAHCKrUCkRZWlw3UZVEiL4/21F39kTmWObpGEhJTVaKQLYWuRzHEPDaUqzyMhY
         4uuGra4SQ7fHnKLtkXdvo8gUq0L6fuVmnDfWg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737728872; x=1738333672;
        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=TDLg2K8MhJfOLYFUerOkwzHomdYiZlZ1KjiTzk4JjgI=;
        b=hdfNIf1TLUbs5P4YF6Hi1Hr6+hArKRZfzr6AiGHaT6WbgBmrII7+oQvlsZy4fXRheZ
         x9MndOngiWSl8mT+VUhtDU6fCpEWtIMO7oRAVehd3tKI2YyPPheVlMmkGXHjsy58jlwO
         LDDEBX2AiOZfWX7sPINwoj3da/zf+m4ZO2lvgag//3e1ZaI+6Qk0CLl2YqsWDuXI0oZt
         ZI+3SRqDIe2zbHv2RGD/35HLG9t2E3W1cFsGwBTv4v8vwAiNwWJGP1T/xk8iRToSQX1o
         Nmv4i2dRWr6Fs+vZtBlk3Wq3/sfq9EZKWaLFLK4zW9QO37iUkM/AN/tF+ErLrr9NrH8R
         narQ==
X-Gm-Message-State: AOJu0YyfY8nYKK5xyNb/rbomAbwtdoiC0z/vaJwFqWuKWTfaVMcNXMHd
	1UsBSFLYOvQ+fJ4NiV2DBTxmOWRKFKtS8MAN5uGKmAM/FTpFHHeYyOeETzLaIhI=
X-Gm-Gg: ASbGnctGdgOnmLcevt2ybdLVHAEsYC4ZvB5v2trrFZPdGlk1OjEltxMMai61EiBMM8T
	mXqIPy6X5a8o2tA2l11vY4DXGanMnah5wt5i4LtY6e0IbCUYRjpoYZw5CVKOM/UJeTOEaTsF2ib
	szuYRdiq5kg0Cz6rJHSz5S63PB74kVSds8d5SJ4yHG7KTHdtW/lYMO2eZFi35JnKXi09KE84mPu
	fIakkp8tgbyF4FBgIZDS11VglSW0gg4zC/dUeVfYYuiDVDjBgv9GPg1wmzh2AMmqeYJvjtJJ70w
	o985hzc6HA==
X-Google-Smtp-Source: AGHT+IGM1ptKqOPsTolm7iqm6rDU/piBm8rMbk383KQFK9V/Tbts42iG5JXmXE6gATaKSAAlfBamYg==
X-Received: by 2002:a17:90b:2803:b0:2ee:ba84:5cac with SMTP id 98e67ed59e1d1-2f782c51739mr48500280a91.7.1737728872393;
        Fri, 24 Jan 2025 06:27:52 -0800 (PST)
Date: Fri, 24 Jan 2025 15:27:46 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: xen-devel@lists.xenproject.org, Jan Beulich <jbeulich@suse.com>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>
Subject: Re: [PATCH for-4.20 v2 0/5] x86/iommu: make CX16 mandatory for IOMMU
Message-ID: <Z5OjYhD6nbFYa4ff@macbook.local>
References: <20250124120112.56678-1-roger.pau@citrix.com>
 <3204bed4-4f03-405e-b77c-4355803f3a31@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <3204bed4-4f03-405e-b77c-4355803f3a31@citrix.com>

On Fri, Jan 24, 2025 at 02:24:34PM +0000, Andrew Cooper wrote:
> On 24/01/2025 12:01 pm, Roger Pau Monne wrote:
> > Hello,
> >
> > The following series is the original CX16 series sent by Teddy, with the
> > CX16 checks split into a separate patch, plus one extra patch to switch
> > AMD-Vi to use CMPXCHG16B when updating Interrupt Remapping Entries.
> >
> > Note that last patch to use CMPXCHG16B fixes a real bug with AMD
> > hardware.
> >
> > Thanks, Roger.
> >
> > Roger Pau Monne (1):
> >   iommu/amd: atomically update IRTE
> >
> > Teddy Astie (4):
> >   x86/iommu: check for CMPXCHG16B when enabling IOMMU
> >   iommu/vtd: remove non-CX16 logic from interrupt remapping
> >   x86/iommu: remove non-CX16 logic from DMA remapping
> >   iommu/vtd: cleanup MAP_SINGLE_DEVICE and related code
> 
> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

Thanks.

> CC Oleksii.  Patch 5 is a real bugfix that needs backporting, and the
> prior patches have been in an almost-ready state for more than a release
> now.

I've split the checks into a pre-patch, and did a bit more cleanup of
code that was no longer needed (pre/post interrupt mask before IRTE
update), but overall the code is the same plus the extra fix.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jan 24 14:31:45 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Jan 2025 14:31:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876799.1287150 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbKij-0007Oz-KR; Fri, 24 Jan 2025 14:31:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876799.1287150; Fri, 24 Jan 2025 14:31:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbKij-0007Os-Hg; Fri, 24 Jan 2025 14:31:41 +0000
Received: by outflank-mailman (input) for mailman id 876799;
 Fri, 24 Jan 2025 14:31: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
 <SRS0=AkuS=UQ=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tbKih-0007Oi-Oc
 for xen-devel@lists.xenproject.org; Fri, 24 Jan 2025 14:31:39 +0000
Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com
 [2607:f8b0:4864:20::62a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id eb707cd5-da5f-11ef-a0e5-8be0dac302b0;
 Fri, 24 Jan 2025 15:31:38 +0100 (CET)
Received: by mail-pl1-x62a.google.com with SMTP id
 d9443c01a7336-218c8aca5f1so50835365ad.0
 for <xen-devel@lists.xenproject.org>; Fri, 24 Jan 2025 06:31:38 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-21da414130esm16801875ad.111.2025.01.24.06.31.35
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 24 Jan 2025 06:31:36 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: eb707cd5-da5f-11ef-a0e5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737729097; x=1738333897; 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=tvsWvoZq6BRKZKu3jbGoZYBysZtTlW+vOvhDwSNRv+0=;
        b=Qofug35nImLf1drtS6lu6fFdeTh+3EWNDz7lHvkhX91NXSPme/d7DkCLGqmmw/NvHr
         q4TvoE/Tmc9YWiIJ7MgVtce5tfmEf6tdWLW+ZtTxNWEKFPNCKZLZ0RXwQubpBYADqYbB
         3s1rTUkLELK4x6WgvdRHPXDM8Ca/u73A5fbkg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737729097; x=1738333897;
        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=tvsWvoZq6BRKZKu3jbGoZYBysZtTlW+vOvhDwSNRv+0=;
        b=W/7hJZ1OIRsvsdKYqmwkE8lmHLRqEHKGDlCIyNJSQxDjURwORMuFkjwZHxt4Y0uOJE
         cce+HEBkXmIsavz4Rb8do5uSz1aEl5BGT5A/bEHHZcInESHt2jcBlK/XulQ6jHfaQXoW
         s6oChoL9LmTC9numPBKyVLpR4qU8lHNhcd4LD6Xs0K256wS8kX8RLJVsoVYzQnHi/86Z
         TFOY8tEe8s0eo1Mw9GxA1tFaCp0detUTbcWvcLF+U7ockXxQZo2Yl0oz4ydbha680P05
         HOQKiwxXw3kbv5yjZIfJeAgvR9oOVHHMSXvnT1UP26R1NbEiD66l2P7u0BOrgVtYVWXn
         Xauw==
X-Gm-Message-State: AOJu0Yxse9BnbvWGcP1Gpw5EVu1X7Vre0j4CR89Xm2JVWmDB2oVbrKDL
	YrOqeCR/F8sqJ+mQqFVHi7U5JCJc2ETUWF47nGjD/WtxQS98ppqb7CDxTzIixLo=
X-Gm-Gg: ASbGncuEWxJPOQEDR/8IZOWNPOm7CcWa3du11LlUhULi3S7IvoNHEBKLt+4Z+aMHlOC
	GPFlr+y5LFeRYPidwgNjMJnbm0lbez1yBCJdfsGZUqf1UdzNiJD1DxApeaHKO0eJkWXzCuuaywR
	72HeyuZi/YvidclwXiIIlPBeW2LX2DL1D7OThkWaeHlmCWOavNQdSCG3Pgpd2ffMqDH9Bh8zMAz
	/430V1mB1FmLfaouXbf5Oe3Slyol430V1L4OMpc0bw5wWjgDDru2Ps3EfABFYhyHl/Qy47JulJY
	i49xhHTnUw==
X-Google-Smtp-Source: AGHT+IHShirqn2nSv9AUkshTdIGi7nAT+R5X2yHOU2NiXaSlWOXkBWZXDPw6E15Hfla6KJ9stGjGVw==
X-Received: by 2002:a17:902:d50e:b0:216:73f0:ef63 with SMTP id d9443c01a7336-21c3563c76cmr456757925ad.49.1737729097292;
        Fri, 24 Jan 2025 06:31:37 -0800 (PST)
Date: Fri, 24 Jan 2025 15:31:30 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Elliott Mitchell <ehem+xen@m5p.com>
Cc: xen-devel@lists.xenproject.org, Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: Serious AMD-Vi issue
Message-ID: <Z5OkQgjd4Lt_rtr0@macbook.local>
References: <ZbLDlRi0vctlhsNp@mattapan.m5p.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <ZbLDlRi0vctlhsNp@mattapan.m5p.com>

On Thu, Jan 25, 2024 at 12:24:53PM -0800, Elliott Mitchell wrote:
> Apparently this was first noticed with 4.14, but more recently I've been
> able to reproduce the issue:
> 
> https://bugs.debian.org/988477
> 
> The original observation features MD-RAID1 using a pair of Samsung
> SATA-attached flash devices.  The main line shows up in `xl dmesg`:
> 
> (XEN) AMD-Vi: IO_PAGE_FAULT: DDDD:bb:dd.f d0 addr ffffff???????000 flags 0x8 I

I think I've figured out the cause for those faults, and posted a fix
here:

https://lore.kernel.org/xen-devel/20250124120112.56678-1-roger.pau@citrix.com/

Fix is patch 5/5, but you likely want to take them all to avoid
context conflicts.

Can you give it a try and see if it fixes the fault messages, plus
your issues with the disk devices?

Regards, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jan 24 15:23:25 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Jan 2025 15:23:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876811.1287160 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbLWK-0005zu-9x; Fri, 24 Jan 2025 15:22:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876811.1287160; Fri, 24 Jan 2025 15:22:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbLWK-0005zn-62; Fri, 24 Jan 2025 15:22:56 +0000
Received: by outflank-mailman (input) for mailman id 876811;
 Fri, 24 Jan 2025 15:22: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
 <SRS0=BvlM=UQ=redhat.com=vschneid@srs-se1.protection.inumbo.net>)
 id 1tbLWI-0005zh-RY
 for xen-devel@lists.xenproject.org; Fri, 24 Jan 2025 15:22:54 +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 1334c407-da67-11ef-99a4-01e77a169b0f;
 Fri, 24 Jan 2025 16:22:52 +0100 (CET)
Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com
 [209.85.219.71]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-269-njjkiY0IMP-APjSfnuWhNg-1; Fri, 24 Jan 2025 10:22:40 -0500
Received: by mail-qv1-f71.google.com with SMTP id
 6a1803df08f44-6d8f6b89dcdso37331556d6.3
 for <xen-devel@lists.xenproject.org>; Fri, 24 Jan 2025 07:22:39 -0800 (PST)
Received: from vschneid-thinkpadt14sgen2i.remote.csb
 (213-44-141-166.abo.bbox.fr. [213.44.141.166])
 by smtp.gmail.com with ESMTPSA id
 6a1803df08f44-6e2058c2a51sm9344776d6.109.2025.01.24.07.22.20
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 24 Jan 2025 07:22:32 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1334c407-da67-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1737732170;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=DwitzjRGQEzgyZZn0UD4LNiBUZsqGx1Qrum3CBb5LtE=;
	b=KkJGm75bhFl5MMGbe9jAvgzI/cdWtjvHtDbG8bUus5oRIWXcjDmtSbb4gb03r9R5UnpU1l
	xmqILr+Soomp+sC0NCkjvI6EjXdxH4f/soE6QugHXBhTy2O7cLFJlmqBf55ORhWPE7nbIw
	KV1KU4QSKXDR7a1QZ4hXQoEEvYZe4mA=
X-MC-Unique: njjkiY0IMP-APjSfnuWhNg-1
X-Mimecast-MFC-AGG-ID: njjkiY0IMP-APjSfnuWhNg
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737732154; x=1738336954;
        h=mime-version:message-id:date:references:in-reply-to:subject:cc:to
         :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=DwitzjRGQEzgyZZn0UD4LNiBUZsqGx1Qrum3CBb5LtE=;
        b=d+g8FfkYt7DY46+sUxTVZSFYlc49x5ICsh2uZvcnRj4hZ8e4rgaXvXL62EJJy+M25I
         e/xM7z5sqdf8KNBtaLELrsvvPEApji0+aOduiHqB04jfJb4scTsrz7bOV1MBKgV98ZVO
         09CZswIRM5IWgftVUYHMoxl2tRWlYtl/D0XP+bkZR2r/HBLWFyGGNkTbA3UPs1SmHYag
         5kGkfkDUbKVJcIRXUUkEU5Vk2oyFrOl5rZdQGIL5U2yIZAZ0CKrWtVudOmHMlYY/H684
         UD8dJAzXBMNNIjfDFId309N15n1I+SZUC+9X+KQpJMxsqtqpGdh2dXLQzoClBKld5c1K
         ktXQ==
X-Forwarded-Encrypted: i=1; AJvYcCW0U1cl7EqjcB1mV8rRGnh2JHm7l6FrcP/TnEuB1kKEpVXQSbcfjwDmKwyjmtsRQ/Flgqb7t7kPnWE=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz20JWnLT5LlFzQNNVSJgiAKLMTiUhe1QJoLgnbsULhzAiUL74a
	qkDuS01wC4WjLLpXzhAgfARk8uFfx2yoRXgmt0ZsZnhQ1zOiZRX1Pkm/RmmHNQTZ/FKPWnyGghH
	IwxvnIpj7wRbGDcFeTv/iEr904sRQL8zm12Tj5hZuv34+6PRs3kLlU2zg7+GoVYvf
X-Gm-Gg: ASbGncuaXc694TykhxDbC+GATvLoq0ll8Yui+VTdG2xQXxL2enzzoJhvNMMo/3xKTSv
	8A4q69U6iDTf6pXpYenSMA0SL80Rsd6WBpsXICYJetvBACIdKg48m/5KVbqJaMyA36w3vFybDoR
	QTt863IoUFAz0Du1JuGfBjg0zMF1YUVziKCVN3zHpdJsMNSpVIwDrdlVGv0iSugRHWxrJ1UWDy/
	5KNWLSwVj9TEytnZhkMe/vyIeNb9vFbCRM658elkO72reDsHZaEEPgHdn/cG9kak1sEBKe/b0Kp
	xVUOnAb20TGM5q3YgwiXRyqn0TkzwfBT/T8E08DrOj1rseznhDsOHf0=
X-Received: by 2002:a05:6214:1302:b0:6d8:861f:adca with SMTP id 6a1803df08f44-6e1b2235c9fmr497775216d6.42.1737732153428;
        Fri, 24 Jan 2025 07:22:33 -0800 (PST)
X-Google-Smtp-Source: AGHT+IE5TeadQAXYF5iUiWYdZcwN/B3B0GhQEA3OgvrN+YGY06rhpOtkdAXjp93P8gBhIIoKYtqxZQ==
X-Received: by 2002:a05:6214:1302:b0:6d8:861f:adca with SMTP id 6a1803df08f44-6e1b2235c9fmr497773786d6.42.1737732152904;
        Fri, 24 Jan 2025 07:22:32 -0800 (PST)
From: Valentin Schneider <vschneid@redhat.com>
To: Uladzislau Rezki <urezki@gmail.com>
Cc: Uladzislau Rezki <urezki@gmail.com>, Jann Horn <jannh@google.com>,
 linux-kernel@vger.kernel.org, x86@kernel.org,
 virtualization@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
 loongarch@lists.linux.dev, linux-riscv@lists.infradead.org,
 linux-perf-users@vger.kernel.org, xen-devel@lists.xenproject.org,
 kvm@vger.kernel.org, linux-arch@vger.kernel.org, rcu@vger.kernel.org,
 linux-hardening@vger.kernel.org, linux-mm@kvack.org,
 linux-kselftest@vger.kernel.org, bpf@vger.kernel.org,
 bcm-kernel-feedback-list@broadcom.com, Juergen Gross <jgross@suse.com>,
 Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov
 <alexey.amakhalov@broadcom.com>, Russell King <linux@armlinux.org.uk>,
 Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>,
 Huacai Chen <chenhuacai@kernel.org>, WANG Xuerui <kernel@xen0n.name>, Paul
 Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>,
 Albert Ou <aou@eecs.berkeley.edu>, Thomas Gleixner <tglx@linutronix.de>,
 Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Dave
 Hansen <dave.hansen@linux.intel.com>, "H. Peter Anvin" <hpa@zytor.com>,
 Peter Zijlstra <peterz@infradead.org>, Arnaldo Carvalho de Melo
 <acme@kernel.org>, Namhyung Kim <namhyung@kernel.org>, Mark Rutland
 <mark.rutland@arm.com>, Alexander Shishkin
 <alexander.shishkin@linux.intel.com>, Jiri Olsa <jolsa@kernel.org>, Ian
 Rogers <irogers@google.com>, Adrian Hunter <adrian.hunter@intel.com>,
 "Liang, Kan" <kan.liang@linux.intel.com>, Boris Ostrovsky
 <boris.ostrovsky@oracle.com>, Josh Poimboeuf <jpoimboe@kernel.org>, Pawan
 Gupta <pawan.kumar.gupta@linux.intel.com>, Sean Christopherson
 <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, Andy Lutomirski
 <luto@kernel.org>, Arnd Bergmann <arnd@arndb.de>, Frederic Weisbecker
 <frederic@kernel.org>, "Paul E. McKenney" <paulmck@kernel.org>, Jason
 Baron <jbaron@akamai.com>, Steven Rostedt <rostedt@goodmis.org>, Ard
 Biesheuvel <ardb@kernel.org>, Neeraj Upadhyay
 <neeraj.upadhyay@kernel.org>, Joel Fernandes <joel@joelfernandes.org>,
 Josh Triplett <josh@joshtriplett.org>, Boqun Feng <boqun.feng@gmail.com>,
 Mathieu Desnoyers <mathieu.desnoyers@efficios.com>, Lai Jiangshan
 <jiangshanlai@gmail.com>, Zqiang <qiang.zhang1211@gmail.com>, Juri Lelli
 <juri.lelli@redhat.com>, Clark Williams <williams@redhat.com>, Yair
 Podemsky <ypodemsk@redhat.com>, Tomas Glozar <tglozar@redhat.com>, Vincent
 Guittot <vincent.guittot@linaro.org>, Dietmar Eggemann
 <dietmar.eggemann@arm.com>, Ben Segall <bsegall@google.com>, Mel Gorman
 <mgorman@suse.de>, Kees Cook <kees@kernel.org>, Andrew Morton
 <akpm@linux-foundation.org>, Christoph Hellwig <hch@infradead.org>, Shuah
 Khan <shuah@kernel.org>, Sami Tolvanen <samitolvanen@google.com>, Miguel
 Ojeda <ojeda@kernel.org>, Alice Ryhl <aliceryhl@google.com>, "Mike
 Rapoport (Microsoft)" <rppt@kernel.org>, Samuel Holland
 <samuel.holland@sifive.com>, Rong Xu <xur@google.com>, Nicolas Saenz
 Julienne <nsaenzju@redhat.com>, Geert Uytterhoeven <geert@linux-m68k.org>,
 Yosry Ahmed <yosryahmed@google.com>, "Kirill A. Shutemov"
 <kirill.shutemov@linux.intel.com>, "Masami Hiramatsu (Google)"
 <mhiramat@kernel.org>, Jinghao Jia <jinghao7@illinois.edu>, Luis
 Chamberlain <mcgrof@kernel.org>, Randy Dunlap <rdunlap@infradead.org>,
 Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: Re: [PATCH v4 29/30] x86/mm, mm/vmalloc: Defer
 flush_tlb_kernel_range() targeting NOHZ_FULL CPUs
In-Reply-To: <Z4_Sl-zu7GprkbaL@pc636>
References: <20250114175143.81438-1-vschneid@redhat.com>
 <20250114175143.81438-30-vschneid@redhat.com>
 <CAG48ez1Mh+DOy0ysOo7Qioxh1W7xWQyK9CLGNU9TGOsLXbg=gQ@mail.gmail.com>
 <xhsmh34hhh37q.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
 <Z4qBMqcMg16p57av@pc636>
 <xhsmhwmetfk9d.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
 <Z44wSJTXknQVKWb0@pc636>
 <xhsmhr04xfow1.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
 <Z4_Sl-zu7GprkbaL@pc636>
Date: Fri, 24 Jan 2025 16:22:19 +0100
Message-ID: <xhsmh8qr0p784.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
MIME-Version: 1.0
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: l-kUtXxuky9XWFSFntE3LcI_y2tHhAQgycBZnZ82tE0_1737732158
X-Mimecast-Originator: redhat.com
Content-Type: text/plain

On 21/01/25 18:00, Uladzislau Rezki wrote:
>> >
>> > As noted before, we defer flushing for vmalloc. We have a lazy-threshold
>> > which can be exposed(if you need it) over sysfs for tuning. So, we can add it.
>> >
>>
>> In a CPU isolation / NOHZ_FULL context, isolated CPUs will be running a
>> single userspace application that will never enter the kernel, unless
>> forced to by some interference (e.g. IPI sent from a housekeeping CPU).
>>
>> Increasing the lazy threshold would unfortunately only delay the
>> interference - housekeeping CPUs are free to run whatever, and so they will
>> eventually cause the lazy threshold to be hit and IPI all the CPUs,
>> including the isolated/NOHZ_FULL ones.
>>
> Do you have any testing results for your workload? I mean how much
> potentially we can allocate. Again, maybe it is just enough to back
> and once per-hour offload it.
>

Potentially as much as you want... In our Openshift environments, you can
get any sort of container executing on the housekeeping CPUs and they're
free to do pretty much whatever they want. Per CPU isolation they're not
allowed/meant to disturb isolated CPUs, however.

> Apart of that how critical IPIing CPUs affect your workloads?
>

If I'm being pedantic, a single IPI to an isolated CPU breaks the
isolation. If we can't quiesce IPIs to isolated CPUs, then we can't
guarantee that whatever is running on the isolated CPUs is actually
isolated / shielded from third party interference.



From xen-devel-bounces@lists.xenproject.org Fri Jan 24 21:27:04 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Jan 2025 21:27:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876846.1287170 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbRCJ-0007pm-72; Fri, 24 Jan 2025 21:26:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876846.1287170; Fri, 24 Jan 2025 21:26:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbRCJ-0007pe-34; Fri, 24 Jan 2025 21:26:39 +0000
Received: by outflank-mailman (input) for mailman id 876846;
 Fri, 24 Jan 2025 21:26:38 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=yRFp=UQ=m5p.com=ehem@srs-se1.protection.inumbo.net>)
 id 1tbRCI-0007pY-Dw
 for xen-devel@lists.xenproject.org; Fri, 24 Jan 2025 21:26:38 +0000
Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e1f05d25-da99-11ef-99a4-01e77a169b0f;
 Fri, 24 Jan 2025 22:26:34 +0100 (CET)
Received: from m5p.com (mailhost.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:f7])
 by mailhost.m5p.com (8.18.1/8.17.1) with ESMTPS id 50OLQNLa029330
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
 Fri, 24 Jan 2025 16:26:29 -0500 (EST) (envelope-from ehem@m5p.com)
Received: (from ehem@localhost)
 by m5p.com (8.18.1/8.15.2/Submit) id 50OLQNir029329;
 Fri, 24 Jan 2025 13:26:23 -0800 (PST) (envelope-from ehem)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e1f05d25-da99-11ef-99a4-01e77a169b0f
Date: Fri, 24 Jan 2025 13:26:23 -0800
From: Elliott Mitchell <ehem+xen@m5p.com>
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Cc: xen-devel@lists.xenproject.org, Jan Beulich <jbeulich@suse.com>,
        Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: Serious AMD-Vi issue
Message-ID: <Z5QFf5Ipk3GHd27H@mattapan.m5p.com>
References: <ZbLDlRi0vctlhsNp@mattapan.m5p.com>
 <Z5OkQgjd4Lt_rtr0@macbook.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <Z5OkQgjd4Lt_rtr0@macbook.local>
X-Spam-Status: No, score=0.4 required=10.0 tests=KHOP_HELO_FCRDNS autolearn=no
	autolearn_force=no version=4.0.1
X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on mattapan.m5p.com

On Fri, Jan 24, 2025 at 03:31:30PM +0100, Roger Pau Monn� wrote:
> On Thu, Jan 25, 2024 at 12:24:53PM -0800, Elliott Mitchell wrote:
> > Apparently this was first noticed with 4.14, but more recently I've been
> > able to reproduce the issue:
> > 
> > https://bugs.debian.org/988477
> > 
> > The original observation features MD-RAID1 using a pair of Samsung
> > SATA-attached flash devices.  The main line shows up in `xl dmesg`:
> > 
> > (XEN) AMD-Vi: IO_PAGE_FAULT: DDDD:bb:dd.f d0 addr ffffff???????000 flags 0x8 I
> 
> I think I've figured out the cause for those faults, and posted a fix
> here:
> 
> https://lore.kernel.org/xen-devel/20250124120112.56678-1-roger.pau@citrix.com/
> 
> Fix is patch 5/5, but you likely want to take them all to avoid
> context conflicts.

I haven't tested yet, but some analysis from looking at the series.

This seems a plausible explanation for the interrupt IOMMU messages.  As
such I think there is a good chance the reported messages will disappear.

Nothing in here looks plausible for solving the real problem, that of
RAID1 mirrors diverging (almost certainly getting zeroes during DMA, but
there is a chance stale data is being read).

Worse, since it removes the observed messages, the next person will
almost certainly have severe data loss by the time they realize there is
a problem.  Notably those messages lead me to Debian #988477, so I was
able to take action before things got too bad.



I'm not absolutely certain this is a pure Xen bug.  There is a
possibility the RAID1 driver is reusing DMA buffers in a fashion which
violates the DMA interface.  Yet there is also a good chance Xen isn't
implementing its layer properly either.



There is one pattern emerging at this point.  Samsung hardware is badly
effected, other vendors are either uneffected or mildly effected.
Notably the estimated age of the devices meant to be handed off to
someone able to diagnose the issue is >10 years.  The uneffected
Crucial/Micron SATA device *should* drastically outperform these, yet
instead it is uneffected.  The Crucial/Micron NVMe is very mildly
effected, yet should be more than an order of magnitude faster.

The simplest explanation is the flash controller on the Samsung devices
is lower latency than the one used by Micron.


Both present reproductions feature AMD processors and ASUS motherboards.
I'm doubtful of this being an ASUS issue.  This seems more likely a case
of people who use RAID with flash tending to go with a motherboard vendor
who reliably support ECC on all their motherboards.

I don't know whether this is confined to AMD processors, or not.  The
small number of reproductions suggests few people are doing RAID with
flash storage.  In which case no one may have tried RAID1 with flash on
Intel processors.  On Intel hardware the referenced message would be
absent and people might think their problem was distinct from Debian
#988477.

In fact what seems a likely reproduction on Intel hardware is the Intel
sound card issue.  I notice that issue occurs when sound *starts*
playing.  When a sound device starts, its buffers would be empty and the
first DMA request would be turned around with minimal latency.  In such
case this matches the Samsung SATA devices handling DMA with low
latency.


> Can you give it a try and see if it fixes the fault messages, plus
> your issues with the disk devices?

Ick.  I was hoping to avoid reinstalling the known problematic devices
and simply send them to someone better setup for analyzing x86 problems.

Looking at the series, it seems likely to remove the fault messages and
turn this into silent data loss.  I doubt any AMD processors have an
IOMMU, yet omit cmpxchg16b (older system lacked full IOMMU, yet did have
cmpxchg16b, newer system has both).  Even guests have cmpxchg16b
available.

If you really want this tested, it will be a while before the next
potential downtime window.

Come to think of it, I wonder whether this might fix a particular device
which was having an interrupt problem.  Problem there being it was being
uncooperative with motherboard firmware...


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg@m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445




From xen-devel-bounces@lists.xenproject.org Sat Jan 25 15:07:37 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Jan 2025 15:07:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876957.1287180 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbhko-000672-0A; Sat, 25 Jan 2025 15:07:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876957.1287180; Sat, 25 Jan 2025 15:07:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbhkn-00066u-RJ; Sat, 25 Jan 2025 15:07:21 +0000
Received: by outflank-mailman (input) for mailman id 876957;
 Sat, 25 Jan 2025 15:07:20 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=VOc2=UR=alien8.de=bp@srs-se1.protection.inumbo.net>)
 id 1tbhkm-00066o-5F
 for xen-devel@lists.xenproject.org; Sat, 25 Jan 2025 15:07:20 +0000
Received: from mail.alien8.de (mail.alien8.de [2a01:4f9:3051:3f93::2])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 10c7d9fd-db2e-11ef-a0e5-8be0dac302b0;
 Sat, 25 Jan 2025 16:07:18 +0100 (CET)
Received: from localhost (localhost.localdomain [127.0.0.1])
 by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id 50BDC40E016C; 
 Sat, 25 Jan 2025 15:07:15 +0000 (UTC)
Received: from mail.alien8.de ([127.0.0.1])
 by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id 3ear0RxyTJw3; Sat, 25 Jan 2025 15:07:11 +0000 (UTC)
Received: from rn.tnic (unknown [IPv6:2a02:3038:26a:a804:d8b1:8636:c138:a149])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest
 SHA256) (No client certificate requested)
 by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 9329440E015F;
 Sat, 25 Jan 2025 15:06:59 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 10c7d9fd-db2e-11ef-a0e5-8be0dac302b0
X-Virus-Scanned: Debian amavisd-new at mail.alien8.de
Authentication-Results: mail.alien8.de (amavisd-new); dkim=pass (4096-bit key)
	header.d=alien8.de
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8;
	t=1737817631; bh=bcJcQThfeA4UEAY5LgxBbQHlB0IAX/5v2SleSTUbweM=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=XCj83VmscQRO5wf6bhi81xxSftcLg28eT/WZzEzfyHjVqyshB77EbhH1O4NvAngIa
	 0K1dcN1YeKcIbqeUE0IlonQ/Hb1n/CegoHvL6pPYRzGhU4Vp+F2FP0NKVc7yOn6JN/
	 a2htLEMKxNaYWODwZjFw3549E/DiW3fETin4kwO0Sqo1Yl6GB2NtQV3k0Le9muRp4R
	 B3bjNPW86QA3D+yA//ljwStZlwWg23q2TOlsRzxqeTP/rYm21CFQxCR9XrO9+FgNI/
	 JIfp9yCz0uuqMHt/tVLt0IPuTuRQ7H2hP39DJLS6XkAiKyi2dLSPnEJ1z8zcKVk2Rd
	 02JHiumpJSAT5PXsXLbBYIKWs0z4kFLyDstRGVgduYt54R1I5Xqr2A2Y5CnzO4re+D
	 PSKcPoik0STZNhLEBLQ/An+IcxIIxLlipE2mcFIU2qujxxb7zM4+/tYnQPYBL55/PE
	 j3PgCt2zN6k5URdeZ5BMPaBMEYRHyYl6T1izS2MQEoq1glscXvKDMu8+KbMl1noMRz
	 8au5LfUtcyKr0KeTWdgrCpU+/pnQ6PCWQX7vV9YE6WMcOEHp0FkIvqCaAC1CRVv5W5
	 7MqTDf3hJPUECpC5ecWKNlBENgtEXoGn5JWsCvEEMPtTiemEKw9aC8EvcOYEkEYIe5
	 QUwaAC45dBzAwow2o4DPRIT4=
Date: Sat, 25 Jan 2025 16:06:58 +0100
From: Borislav Petkov <bp@alien8.de>
To: Brian Gerst <brgerst@gmail.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
	Ingo Molnar <mingo@kernel.org>, "H . Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ard Biesheuvel <ardb@kernel.org>, Uros Bizjak <ubizjak@gmail.com>,
	Juergen Gross <jgross@suse.com>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v6 04/15] x86/pvh: Use fixed_percpu_data for early boot
 GSBASE
Message-ID: <20250125150658.GAZ5T-EloWfjZAwJdU@renoirsky.local>
References: <20250123190747.745588-1-brgerst@gmail.com>
 <20250123190747.745588-5-brgerst@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20250123190747.745588-5-brgerst@gmail.com>


On Thu, Jan 23, 2025 at 02:07:36PM -0500, Brian Gerst wrote:
> Instead of having a private area for the stack canary, use
> fixed_percpu_data for GSBASE like the native kernel.
> 
> Signed-off-by: Brian Gerst <brgerst@gmail.com>
> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
> ---
>  arch/x86/platform/pvh/head.S | 15 +++++++++------
>  1 file changed, 9 insertions(+), 6 deletions(-)

Use ./scripts/get_maintainer.pl pls. I've added Juergen now.

> diff --git a/arch/x86/platform/pvh/head.S b/arch/x86/platform/pvh/head.S
> index 4733a5f467b8..fa0072e0ca43 100644
> --- a/arch/x86/platform/pvh/head.S
> +++ b/arch/x86/platform/pvh/head.S
> @@ -173,10 +173,15 @@ SYM_CODE_START(pvh_start_xen)
>  1:
>  	UNWIND_HINT_END_OF_STACK
>  
> -	/* Set base address in stack canary descriptor. */
> -	mov $MSR_GS_BASE,%ecx
> -	leal canary(%rip), %eax
> -	xor %edx, %edx
> +	/*
> +	 * Set up GSBASE.
> +	 * Note that, on SMP, the boot cpu uses init data section until
> +	 * the per cpu areas are set up.

s/cpu/CPU/g

check your whole set pls.

> +	 */
> +	movl $MSR_GS_BASE,%ecx
> +	leaq INIT_PER_CPU_VAR(fixed_percpu_data)(%rip), %rdx
> +	movq %edx, %eax
> +	shrq $32, %rdx
>  	wrmsr




From xen-devel-bounces@lists.xenproject.org Sat Jan 25 16:52:02 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Jan 2025 16:52:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.876989.1287190 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbjNo-0003BO-8v; Sat, 25 Jan 2025 16:51:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 876989.1287190; Sat, 25 Jan 2025 16:51:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbjNo-0003BH-5v; Sat, 25 Jan 2025 16:51:44 +0000
Received: by outflank-mailman (input) for mailman id 876989;
 Sat, 25 Jan 2025 16:51: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 <SRS0=WrGG=UR=gmail.com=brgerst@srs-se1.protection.inumbo.net>)
 id 1tbjNn-0003B9-2o
 for xen-devel@lists.xenproject.org; Sat, 25 Jan 2025 16:51:43 +0000
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com
 [2a00:1450:4864:20::12d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a6eccc05-db3c-11ef-a0e5-8be0dac302b0;
 Sat, 25 Jan 2025 17:51:42 +0100 (CET)
Received: by mail-lf1-x12d.google.com with SMTP id
 2adb3069b0e04-5401be44b58so3428309e87.0
 for <xen-devel@lists.xenproject.org>; Sat, 25 Jan 2025 08:51:41 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a6eccc05-db3c-11ef-a0e5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1737823901; x=1738428701; 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=/o5lQz4z3bazVM0zrwUgk9jgdQGjj7NPeb4nW5lxrzw=;
        b=NwsRjcGZJ1dpbdXy7cZmbzHFgfVCCFQ/tEFE7iUgjSAtJqe9vYlkP4hgdW2PZScv5w
         dnV0lPe8+AJrM4SZFe8bDyOHDHiqU+huYuGByZdpFF9yoo6CdCE1f+Ukvl6y3Fe1Da80
         7BgVisvQOHwdAYPYZbQdpr/cXhpoHXziIikDqC682TUylk/6SEGxK3X097Lbruj5Hv+i
         OO1IzTPyZAa+BsRGd4G8HnwQvMKAN8llH1G27hVPLIjtC8g/bJFGRHKZUoqB6PJIFgEo
         LmLYx6FkvUyEU73iHgu7SUIou7HUSTVfi9sk3Jtt2z5fBzvVQ2tD8/l2P2Y1I4o3vFWb
         gS+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737823901; x=1738428701;
        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=/o5lQz4z3bazVM0zrwUgk9jgdQGjj7NPeb4nW5lxrzw=;
        b=FZRVr8e70FkINT1GW8cLRvz7hsF6GccE6eCuD9LojKdaTaLesyz3hi10Ymkkxd/SCF
         CSe5ODhkMpCwAmmQnUUQwLrLLMJZudFxMX9obzc7jUqPOyUHPR21ikBBpGXGRD0chAos
         RqfikVz3W2WjqaEz1XPL87tc+YlbSBX8b/GYCcCbeSHRK5gbMxK5w5EC98gyDiqTWhBi
         C7YbfJ4l53MCN3X9+ZQeejewN4XC3HddGew83wOQIVUS1cJP4rvy9ghOgMj/3NVZAwEZ
         m2krZjpE/F5vteWkMw+b/riwhZtIJcR1B6pHufQN5ED+C9nklIeW3Q8Fj8bLC1OhE8xg
         fhyA==
X-Forwarded-Encrypted: i=1; AJvYcCVKM3ZC9xVckdGqZnOguFCLkoZZc6VEQZx/VUT3Xqos10m9kv5wW8VuA2szuZ0xavBYoay+neUe8D0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxQjov7VsCuW84hmfbaqwH0N4BZUVgQLp5tK/YsZzt0AnRAuh57
	+dnA8QiEkw8yjvnYYzitYZJ9QNwYAavIRxdvAGM/y3QRdDHjrERQ5gwZAd7gIinjEayVoAQIgdp
	wK+6bG7JTKwsc0hI43C+LIDfang==
X-Gm-Gg: ASbGncvuDPtR5bE3QmAYl7yKgLD/6hoS+bNPrQLivy2VNsVsBowHoqdy84MOZvonyDp
	XEAnwgCn6TQZLxiQJfeeS9cmJ/exLx1yLpWjqmjPGGO3gZlQelTbKRxO9z0o6ej9UQHLSLAPLlF
	v+
X-Google-Smtp-Source: AGHT+IHp5nuXQzvNOwwhjBWsjYmQuSyZx/kuCbmED7c4yCz9ZGLQHpBHUJhywm36HZHMsWl0IDePDzcrosG+E0Yu8wM=
X-Received: by 2002:a05:6512:32c7:b0:53e:39e6:a1c5 with SMTP id
 2adb3069b0e04-5439c2659cfmr13611514e87.41.1737823900901; Sat, 25 Jan 2025
 08:51:40 -0800 (PST)
MIME-Version: 1.0
References: <20250123190747.745588-1-brgerst@gmail.com> <20250123190747.745588-5-brgerst@gmail.com>
 <20250125150658.GAZ5T-EloWfjZAwJdU@renoirsky.local>
In-Reply-To: <20250125150658.GAZ5T-EloWfjZAwJdU@renoirsky.local>
From: Brian Gerst <brgerst@gmail.com>
Date: Sat, 25 Jan 2025 11:51:29 -0500
X-Gm-Features: AWEUYZlme3fNTAUaz99MI4IlYuGga1joebdoO1yHLneW1XrEoe2ZlCEU2PYDR44
Message-ID: <CAMzpN2jqOb1jC6ZYxa+1Xw-EXuDXUrGT9_7Gv0FL+XJxTXvC5g@mail.gmail.com>
Subject: Re: [PATCH v6 04/15] x86/pvh: Use fixed_percpu_data for early boot GSBASE
To: Borislav Petkov <bp@alien8.de>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org, 
	Ingo Molnar <mingo@kernel.org>, "H . Peter Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de>, 
	Ard Biesheuvel <ardb@kernel.org>, Uros Bizjak <ubizjak@gmail.com>, Juergen Gross <jgross@suse.com>, 
	xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Jan 25, 2025 at 10:07=E2=80=AFAM Borislav Petkov <bp@alien8.de> wro=
te:
>
>
> On Thu, Jan 23, 2025 at 02:07:36PM -0500, Brian Gerst wrote:
> > Instead of having a private area for the stack canary, use
> > fixed_percpu_data for GSBASE like the native kernel.
> >
> > Signed-off-by: Brian Gerst <brgerst@gmail.com>
> > Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
> > ---
> >  arch/x86/platform/pvh/head.S | 15 +++++++++------
> >  1 file changed, 9 insertions(+), 6 deletions(-)
>
> Use ./scripts/get_maintainer.pl pls. I've added Juergen now.
>
> > diff --git a/arch/x86/platform/pvh/head.S b/arch/x86/platform/pvh/head.=
S
> > index 4733a5f467b8..fa0072e0ca43 100644
> > --- a/arch/x86/platform/pvh/head.S
> > +++ b/arch/x86/platform/pvh/head.S
> > @@ -173,10 +173,15 @@ SYM_CODE_START(pvh_start_xen)
> >  1:
> >       UNWIND_HINT_END_OF_STACK
> >
> > -     /* Set base address in stack canary descriptor. */
> > -     mov $MSR_GS_BASE,%ecx
> > -     leal canary(%rip), %eax
> > -     xor %edx, %edx
> > +     /*
> > +      * Set up GSBASE.
> > +      * Note that, on SMP, the boot cpu uses init data section until
> > +      * the per cpu areas are set up.
>
> s/cpu/CPU/g
>
> check your whole set pls.

To be fair, this was a copy of an existing comment.  Is there a style
guide where all these grammar rules are documented, so I don't have to
keep resending these patches for trivial typos?


Brian Gerst


From xen-devel-bounces@lists.xenproject.org Sat Jan 25 18:14:01 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Jan 2025 18:14:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877005.1287200 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbkfF-0004aw-SZ; Sat, 25 Jan 2025 18:13:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877005.1287200; Sat, 25 Jan 2025 18:13:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbkfF-0004ap-Pp; Sat, 25 Jan 2025 18:13:49 +0000
Received: by outflank-mailman (input) for mailman id 877005;
 Sat, 25 Jan 2025 18:13: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 <SRS0=X0T4=UR=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tbkfE-0004aj-Kf
 for xen-devel@lists.xenproject.org; Sat, 25 Jan 2025 18:13:48 +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 1e3caa5b-db48-11ef-a0e5-8be0dac302b0;
 Sat, 25 Jan 2025 19:13:46 +0100 (CET)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-436326dcb1cso20958985e9.0
 for <xen-devel@lists.xenproject.org>; Sat, 25 Jan 2025 10:13:46 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438bd48b000sm70555435e9.20.2025.01.25.10.13.43
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Sat, 25 Jan 2025 10:13:44 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1e3caa5b-db48-11ef-a0e5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737828826; x=1738433626; 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=moGB9VY6BYgn3pI64/Eq1yuXgBP6nQhiwk+gTGBd7L0=;
        b=sFHxu4AFvNC9sNk6XZu1+U7thV0oKG/TE8O6eQoiQTPTrowRm8SapVL8g0Gz2B6okJ
         z0tBRoBNhhY5Fsuf49qSwrVvoHvtBufFCepdKZ930mscVUdEsMjdNerikwUkopYxT6Ij
         WBfXxRN6jYkE6vTeHsiF/sVxQHJM8Xp6TiWRdDKRzsO5X3yT5lYtSCuUZGn8AsRzgGaE
         Pn1LySNwjAhh9YHKblJzGM/VhivFDJH/9SOwCtNCclj0G/GMKr5dfB4Pdhrm0nAEoxVI
         ONn9AcHpSc3k27W4xS/gh8FKZznFMjpMpXFw80YvwfNja7OdTgPnNrRZgFf59GuQoSI2
         F0Dw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737828826; x=1738433626;
        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=moGB9VY6BYgn3pI64/Eq1yuXgBP6nQhiwk+gTGBd7L0=;
        b=aBNY+OR3DtgNZw5qu7amU68cV60qYO7uQkVdhNFQZRXJmwBBF1LA43fLfxeaGbbKsk
         dZFGIPs4sRGejPkNJR1U8s5lo7jAgIbKWCRwyX0Knf3VLv19gt4JYMy0haziiS378hF+
         a8WALfRGo05hCJwSRvbAdDqzSB+7ehwLpD8DUYsBxv06afEaf3+GIVAvq36TOBZ/O90E
         bVYTPnQ2RvoZWr+wXZ+sTxX1tpabv5Zk/f6GVfKt4vlcQ6DXwdx+dlmi9yScJp6IxuE0
         O6HyfTM25baMSk84pNVvretAYx5cEYNMvl1HJYxtdstmaV/wID3VoDI+0xqSCvfKiKmp
         ce+A==
X-Forwarded-Encrypted: i=1; AJvYcCXT5m+o84cam8d2AqgH1uX6R80HAMxiU+X7KemLrS+KwZ+3tVf5JQp5kpf2yg9EtqlvhKaHdYIoF4I=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxB7Yw45F8QwvBWmCAmf558Z82N/dBFGTqQikbNRs4U14lJq+l/
	kVNYwE9UbJhw6vXBQU13iutp6Zw19O4ntqKCAZe2vU7TEnesTvHFF0fWCUfil6s=
X-Gm-Gg: ASbGncvIh3Go2y8uIV4QhT46nrDmuSyizUsIoXmqBpbkG2AShVl2DPkcVbD1IJ+yDso
	Gngl0GcSI9SGDr20KA340gyKCQdyTHRqrHnZ48CIJ1IXmFkKeyFgu88cTDDHweBrXCQc1wueRP1
	etpjnwa3TtTPlYTR4beNTxHF0RLwi9w5GrX68wKZUH30+TNhAwAaWZBaAbRK90n6RRy+q9teYIr
	NWnlyGN5I+Tq6BtNi7vkYbcXebVk3YNDF1kcjKOUOk1DEBJ7LGJiPjdtJ8TB3iyjgsCAQiUuwQD
	EarPM5WfdC4m5f5VajRbqczyGX/KhCgyqbEHYRPTlrHvai6ISQFa+oN/sUjz
X-Google-Smtp-Source: AGHT+IFFcuv4NbqWEewutKdT/4sas20HtAvh9/vbvnAdvh7QUUP5Q6Afr6fZs6XUltdZIWZYDYhKXA==
X-Received: by 2002:a05:600c:1d07:b0:436:488f:50a with SMTP id 5b1f17b1804b1-438913ef4b7mr333870305e9.17.1737828825695;
        Sat, 25 Jan 2025 10:13:45 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: Yi Liu <yi.l.liu@intel.com>,
	Markus Armbruster <armbru@redhat.com>,
	Eduardo Habkost <eduardo@habkost.net>,
	Anthony PERARD <anthony@xenproject.org>,
	Gustavo Romero <gustavo.romero@linaro.org>,
	Jason Wang <jasowang@redhat.com>,
	qemu-ppc@nongnu.org,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Alexander Graf <graf@amazon.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Stefan Berger <stefanb@linux.vnet.ibm.com>,
	Bernhard Beschow <shentey@gmail.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Gerd Hoffmann <kraxel@redhat.com>,
	=?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= <berrange@redhat.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	xen-devel@lists.xenproject.org,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Paul Durrant <paul@xen.org>,
	=?UTF-8?q?Cl=C3=A9ment=20Mathieu--Drif?= <clement.mathieu--drif@eviden.com>,
	=?UTF-8?q?C=C3=A9dric=20Le=20Goater?= <clg@redhat.com>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
Subject: [PATCH 0/9] hw/sysbus/platform-bus: Introduce TYPE_DYNAMIC_SYS_BUS_DEVICE
Date: Sat, 25 Jan 2025 19:13:34 +0100
Message-ID: <20250125181343.59151-1-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Some SysBus devices can optionally be dynamically plugged onto
the sysbus-platform-bus (then virtual guests are aware of
mmio mapping and IRQs via device tree / ACPI rules).

This series makes these devices explicit by having them implement
the DYNAMIC_SYS_BUS_DEVICE class, which only sets 'user_creatable'
flag to %true but makes the codebase a bit clearer (IMHO, at least
now we can grep for DYNAMIC_SYS_BUS_DEVICE).

Philippe Mathieu-Daudé (9):
  hw/sysbus: Use sizeof(BusState) in main_system_bus_create()
  hw/sysbus: Declare QOM types using DEFINE_TYPES() macro
  hw/sysbus: Introduce TYPE_DYNAMIC_SYS_BUS_DEVICE
  hw/vfio: Have VFIO_PLATFORM devices inherit from
    DYNAMIC_SYS_BUS_DEVICE
  hw/display: Have RAMFB device inherit from DYNAMIC_SYS_BUS_DEVICE
  hw/i386: Have X86_IOMMU devices inherit from DYNAMIC_SYS_BUS_DEVICE
  hw/net: Have eTSEC device inherit from DYNAMIC_SYS_BUS_DEVICE
  hw/tpm: Have TPM TIS sysbus device inherit from DYNAMIC_SYS_BUS_DEVICE
  hw/xen: Have legacy Xen backend inherit from DYNAMIC_SYS_BUS_DEVICE

 include/hw/sysbus.h           |  2 ++
 include/hw/xen/xen_pvdev.h    |  3 +-
 hw/core/sysbus.c              | 53 ++++++++++++++++++++---------------
 hw/display/ramfb-standalone.c |  3 +-
 hw/i386/amd_iommu.c           |  2 --
 hw/i386/intel_iommu.c         |  2 --
 hw/i386/x86-iommu.c           |  2 +-
 hw/net/fsl_etsec/etsec.c      |  4 +--
 hw/tpm/tpm_tis_sysbus.c       |  3 +-
 hw/vfio/amd-xgbe.c            |  2 --
 hw/vfio/calxeda-xgmac.c       |  2 --
 hw/vfio/platform.c            |  4 +--
 hw/xen/xen-legacy-backend.c   |  7 ++---
 13 files changed, 42 insertions(+), 47 deletions(-)

-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Sat Jan 25 18:14:01 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Jan 2025 18:14:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877006.1287210 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbkfJ-0004p0-2T; Sat, 25 Jan 2025 18:13:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877006.1287210; Sat, 25 Jan 2025 18:13:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbkfI-0004ot-W5; Sat, 25 Jan 2025 18:13:52 +0000
Received: by outflank-mailman (input) for mailman id 877006;
 Sat, 25 Jan 2025 18:13: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 <SRS0=X0T4=UR=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tbkfI-0004aj-70
 for xen-devel@lists.xenproject.org; Sat, 25 Jan 2025 18:13:52 +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 213dc56b-db48-11ef-a0e5-8be0dac302b0;
 Sat, 25 Jan 2025 19:13:51 +0100 (CET)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-4361f664af5so35550265e9.1
 for <xen-devel@lists.xenproject.org>; Sat, 25 Jan 2025 10:13:51 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38c2a1c4e49sm6227077f8f.98.2025.01.25.10.13.49
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Sat, 25 Jan 2025 10:13:50 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 213dc56b-db48-11ef-a0e5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737828831; x=1738433631; 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=/se+ZOUWHI4guWWCfgPKU8ovKC99g/6LRZidVGKe1oI=;
        b=LRHBJHLWm7gqxXEu8WXxnmKG3n89uc5bSbcx1rG8HfUc6m/wy+Ft0El7SI79t44d8F
         ufbHGqNRJpjbXQknnJxdIcVYRhT9A0C6Xv2fiC008I883D6kU/C1QphM2p3Nheq+37qv
         6si0JLjwGaMxvkn3uLNFL89V5Hhu0GOPOiVfnSZmnBpnEhQo9DvsVRAPac6hcR2q0ffV
         KDtl+j6SdFlUo+Poims3zileJZz+qEJ0sRlM+lssJGPydgMyEmWYh52DxN5XaNkPCqu9
         d7erUjS01Q7oHKvM/pw6UAp953sIESOQrgZFLu6C7Eb5AVlV4Bz/xQVCUtLs2xqgOKnZ
         Moyw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737828831; x=1738433631;
        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=/se+ZOUWHI4guWWCfgPKU8ovKC99g/6LRZidVGKe1oI=;
        b=w5LUVltpk88pQrnwXjgZGp7K0QLrpPMuHNvXGvU7vV30YGUA/gkw0Puikji9Uu33Hq
         TOUOtZDldtvOEWG/sDkQvYZYyWlt4D1N4yndZT8y2rbW6hO1udNHZ7VJYfAj9Llv3P9I
         2H4FhRaiVZmJaE2dZWHVffiAJcEDC4mtV6FRYNAC41bsvcZ4BY1l3bYVAT4g4z0dTKI4
         TpHA59DebJKHNGj5UMKevlsBqDNVHOFgqVJ540fD14gBBTYbOPg/tMQwMLRTFtWSq0Bx
         RczUubyl5vxyRvRbdDnR1lImSR3E4qMNDg1dugDC2zjHLKXsZIXq5koo7exf2qW/f5VF
         wUSg==
X-Forwarded-Encrypted: i=1; AJvYcCWeVBHglOY2vDriEwI6HPThPBPPUmd23oDTJDwjMiSypEnl4nUN7O0puTImnBy1lA4iPRvUgmVHo+4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyQnDdqUCilr8H2rkEXjNtCQkra4ZE9zZ4vLSDBhppD0Bb9TKW3
	JTjtvHlkU5Zl/JLEfQ60TZyWbBk14c6NEw9kVVsvWNMVkbbIs0Ta8euzYrIRc0w=
X-Gm-Gg: ASbGncuDfjvoKXWCnCyMTXso0CLiZ2ryRZb3UHVxug2IRLAytSaSB0lxL5+3dB8vBOl
	dQKKlN4N1EdIFaOtAbOUcZL/a2NKukatDKVKJblVPcrkRrcMRD2z40wt8q7C4GuNlM8GSmN64x3
	31vWZ4dePZXdZs4KTlQt+ZiWebVy8ekwxlxEidljJYosTHfsKAiO+sno+qWZmhS+flPdRtlgJh/
	7BzLkFNlycCqyr2nKOgRDhIu0jV0ip8+k/wSU7pKdSq5qYGiOkDwfYpC5eUzf/RnQcQH0MyemsY
	tcSwKUkaQ1wo8giigsDYgDp3OXRCbDCFLtLAkrKFD3LwTpQmbcoEvEWyOaIw
X-Google-Smtp-Source: AGHT+IGP2iaXKLI15CkhKDP5NBlnFOMSHwCbGSNXKLvJxawalslRdLF5wYi0CoJhDHevjTYCGWh83g==
X-Received: by 2002:a05:600c:3d86:b0:434:f9e1:5cf8 with SMTP id 5b1f17b1804b1-4389143c306mr335517805e9.31.1737828830945;
        Sat, 25 Jan 2025 10:13:50 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: Yi Liu <yi.l.liu@intel.com>,
	Markus Armbruster <armbru@redhat.com>,
	Eduardo Habkost <eduardo@habkost.net>,
	Anthony PERARD <anthony@xenproject.org>,
	Gustavo Romero <gustavo.romero@linaro.org>,
	Jason Wang <jasowang@redhat.com>,
	qemu-ppc@nongnu.org,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Alexander Graf <graf@amazon.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Stefan Berger <stefanb@linux.vnet.ibm.com>,
	Bernhard Beschow <shentey@gmail.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Gerd Hoffmann <kraxel@redhat.com>,
	=?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= <berrange@redhat.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	xen-devel@lists.xenproject.org,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Paul Durrant <paul@xen.org>,
	=?UTF-8?q?Cl=C3=A9ment=20Mathieu--Drif?= <clement.mathieu--drif@eviden.com>,
	=?UTF-8?q?C=C3=A9dric=20Le=20Goater?= <clg@redhat.com>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
Subject: [PATCH 1/9] hw/sysbus: Use sizeof(BusState) in main_system_bus_create()
Date: Sat, 25 Jan 2025 19:13:35 +0100
Message-ID: <20250125181343.59151-2-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250125181343.59151-1-philmd@linaro.org>
References: <20250125181343.59151-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Rather than using the obscure system_bus_info.instance_size,
directly use sizeof(BusState).

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 hw/core/sysbus.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/core/sysbus.c b/hw/core/sysbus.c
index 9355849ff0a..f713bbfe04f 100644
--- a/hw/core/sysbus.c
+++ b/hw/core/sysbus.c
@@ -323,8 +323,8 @@ static void main_system_bus_create(void)
      * assign main_system_bus before qbus_init()
      * in order to make "if (bus != sysbus_get_default())" work
      */
-    main_system_bus = g_malloc0(system_bus_info.instance_size);
-    qbus_init(main_system_bus, system_bus_info.instance_size,
+    main_system_bus = g_new0(BusState, 1);
+    qbus_init(main_system_bus, sizeof(BusState),
               TYPE_SYSTEM_BUS, NULL, "main-system-bus");
     OBJECT(main_system_bus)->free = g_free;
 }
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Sat Jan 25 18:14:01 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Jan 2025 18:14:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877008.1287220 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbkfR-00058H-9L; Sat, 25 Jan 2025 18:14:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877008.1287220; Sat, 25 Jan 2025 18:14:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbkfR-00058A-6Q; Sat, 25 Jan 2025 18:14:01 +0000
Received: by outflank-mailman (input) for mailman id 877008;
 Sat, 25 Jan 2025 18:14:00 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=X0T4=UR=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tbkfQ-000565-47
 for xen-devel@lists.xenproject.org; Sat, 25 Jan 2025 18:14:00 +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 247d6791-db48-11ef-99a4-01e77a169b0f;
 Sat, 25 Jan 2025 19:13:57 +0100 (CET)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-4361c705434so22039945e9.3
 for <xen-devel@lists.xenproject.org>; Sat, 25 Jan 2025 10:13:57 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438bd4c75c0sm68201815e9.31.2025.01.25.10.13.54
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Sat, 25 Jan 2025 10:13:55 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 247d6791-db48-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737828836; x=1738433636; 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=+D9ecSNssEoyInsTWPhPYbcbkHeV5ELbKuxuFIHXnAU=;
        b=N7dRkc6p0L9U/te9/9bQ7dDkBTWvo2AePP0WNz86xrDKWDkyunA50kwama/VhS4KkM
         u9WtPAyGqenbpHdjXvnlBnVtApy0uj52w5ADLHweKFC0GEOx73qNLhDOYmnJquFloZZT
         0cEHqAKgG1se7H9cKre4cfNvYhR/gqs7Jve88fUaXmMiNogaYOP2MV0wipdj0/cDQGSP
         1HMeU009HUK+aLfLLk+KM+vhQgsBt9d03JgQ+ENpi8c24gO+fgo0su3Zr8hd54vBW4Pv
         bH3rjtASmfcb6JBfB//sxw5LxW/2OxQVcfYgNh55bW/cka3jKZ2TwGDkJi9D3yQzaFZY
         m0Iw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737828836; x=1738433636;
        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=+D9ecSNssEoyInsTWPhPYbcbkHeV5ELbKuxuFIHXnAU=;
        b=oPCf0BwFQWGunizws6vrDn9aainlr4T4VSyA4/TT2mgbvtVPwHhNR5HvOkl83FlK5u
         k19vX4rOFB5pcB5VNVGqwZtO2aevkOz81EGCmbvg0XWf6ZxeWqQkM/HcY3r2OIMO6TPn
         eyEGd9/D1hzvZZfr4Rz5w0P2nHvgoRXcxSOX1d/YeW6Xj/C5RI4uJRJPPGkfgedyZ/4g
         sdn99oFoBr1A5nOAUbO5FzKwBAdE3fhEnuku5sPfIdGwBHYhNvaFj9AljYhALXFzUilq
         pqkmbiCQRWwLn8/HfL6kH0LmvKt4orbAwYx9wuwh6hKeRWw0mNzUpButWxHk/gJDmqJj
         8MEA==
X-Forwarded-Encrypted: i=1; AJvYcCXSxE/Mz8yNvwXdbi2ldxhPQu9oOOwFm/SEnhHUTrycrOACRpt1Z/jvuax0sJZmllVFQ+SL4zCOYaA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzLjl/b5jn3dcS1y/Xy+u/veYSdOazzIeqAXOV6bI9IHVZ9pN9G
	HRJfV6oScHb5ep8DPopsIHlA6ulZJcLy9uc+Idp11Sgu+PPXLGj+jzJJQ9wpna8=
X-Gm-Gg: ASbGncswr2Mx1QAltd1rhMTqQv0oYuR+XlqUxw0jOcHtK8TPJmRTLIACY7CPciJtuui
	ETbsrWoneKVVzQ4hoiSFGbib+EYOGMK2tzqceIT6sx+Jd+Cc7sfEx9taONS7sysKEA8+exgiwV+
	L0HBMnWZzxLF64Sqfay3UpPaB2NgR4QQ4z73hen587qMCaoJXGlJ0YJxNR9sxHgiMMRTheYHjX3
	hni7oXSmJ5BMpmnsRl67VwdWxAW/ENlG7U/ZhQShDDopZq61/j0RWI7n8XweJFopvzOA+TrGhHR
	bAgfFXjQP8eDvDaepsfRx9Rq/ns8fxSaOdDCPTUTGhMzLfdZjXvDSUGVHp1o
X-Google-Smtp-Source: AGHT+IH3gG9oDbH+Yt++6e9axdywvxazaykwi7sr/Zo0cY2/uHyHOw51lxlnycmePra8xEH0EQ/Sbw==
X-Received: by 2002:a05:600c:3b94:b0:434:9934:575 with SMTP id 5b1f17b1804b1-438913e02f8mr395787785e9.16.1737828836350;
        Sat, 25 Jan 2025 10:13:56 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: Yi Liu <yi.l.liu@intel.com>,
	Markus Armbruster <armbru@redhat.com>,
	Eduardo Habkost <eduardo@habkost.net>,
	Anthony PERARD <anthony@xenproject.org>,
	Gustavo Romero <gustavo.romero@linaro.org>,
	Jason Wang <jasowang@redhat.com>,
	qemu-ppc@nongnu.org,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Alexander Graf <graf@amazon.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Stefan Berger <stefanb@linux.vnet.ibm.com>,
	Bernhard Beschow <shentey@gmail.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Gerd Hoffmann <kraxel@redhat.com>,
	=?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= <berrange@redhat.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	xen-devel@lists.xenproject.org,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Paul Durrant <paul@xen.org>,
	=?UTF-8?q?Cl=C3=A9ment=20Mathieu--Drif?= <clement.mathieu--drif@eviden.com>,
	=?UTF-8?q?C=C3=A9dric=20Le=20Goater?= <clg@redhat.com>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
Subject: [PATCH 2/9] hw/sysbus: Declare QOM types using DEFINE_TYPES() macro
Date: Sat, 25 Jan 2025 19:13:36 +0100
Message-ID: <20250125181343.59151-3-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250125181343.59151-1-philmd@linaro.org>
References: <20250125181343.59151-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

When multiple QOM types are registered in the same file,
it is simpler to use the the DEFINE_TYPES() macro. In
particular because type array declared with such macro
are easier to review.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 hw/core/sysbus.c | 39 +++++++++++++++++----------------------
 1 file changed, 17 insertions(+), 22 deletions(-)

diff --git a/hw/core/sysbus.c b/hw/core/sysbus.c
index f713bbfe04f..306f98406c0 100644
--- a/hw/core/sysbus.c
+++ b/hw/core/sysbus.c
@@ -80,13 +80,6 @@ static void system_bus_class_init(ObjectClass *klass, void *data)
     k->get_fw_dev_path = sysbus_get_fw_dev_path;
 }
 
-static const TypeInfo system_bus_info = {
-    .name = TYPE_SYSTEM_BUS,
-    .parent = TYPE_BUS,
-    .instance_size = sizeof(BusState),
-    .class_init = system_bus_class_init,
-};
-
 /* Check whether an IRQ source exists */
 bool sysbus_has_irq(SysBusDevice *dev, int n)
 {
@@ -306,15 +299,6 @@ static void sysbus_device_class_init(ObjectClass *klass, void *data)
     k->user_creatable = false;
 }
 
-static const TypeInfo sysbus_device_type_info = {
-    .name = TYPE_SYS_BUS_DEVICE,
-    .parent = TYPE_DEVICE,
-    .instance_size = sizeof(SysBusDevice),
-    .abstract = true,
-    .class_size = sizeof(SysBusDeviceClass),
-    .class_init = sysbus_device_class_init,
-};
-
 static BusState *main_system_bus;
 
 static void main_system_bus_create(void)
@@ -337,10 +321,21 @@ BusState *sysbus_get_default(void)
     return main_system_bus;
 }
 
-static void sysbus_register_types(void)
-{
-    type_register_static(&system_bus_info);
-    type_register_static(&sysbus_device_type_info);
-}
+static const TypeInfo sysbus_types[] = {
+    {
+        .name           = TYPE_SYSTEM_BUS,
+        .parent         = TYPE_BUS,
+        .instance_size  = sizeof(BusState),
+        .class_init     = system_bus_class_init,
+    },
+    {
+        .name           = TYPE_SYS_BUS_DEVICE,
+        .parent         = TYPE_DEVICE,
+        .instance_size  = sizeof(SysBusDevice),
+        .abstract       = true,
+        .class_size     = sizeof(SysBusDeviceClass),
+        .class_init     = sysbus_device_class_init,
+    },
+};
 
-type_init(sysbus_register_types)
+DEFINE_TYPES(sysbus_types)
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Sat Jan 25 18:14:04 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Jan 2025 18:14:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877009.1287230 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbkfU-0005R9-Ko; Sat, 25 Jan 2025 18:14:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877009.1287230; Sat, 25 Jan 2025 18:14:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbkfU-0005QM-HR; Sat, 25 Jan 2025 18:14:04 +0000
Received: by outflank-mailman (input) for mailman id 877009;
 Sat, 25 Jan 2025 18:14:03 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=X0T4=UR=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tbkfT-000565-R0
 for xen-devel@lists.xenproject.org; Sat, 25 Jan 2025 18:14:03 +0000
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com
 [2a00:1450:4864:20::430])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 27a761a7-db48-11ef-99a4-01e77a169b0f;
 Sat, 25 Jan 2025 19:14:02 +0100 (CET)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-385ef8b64b3so2698316f8f.0
 for <xen-devel@lists.xenproject.org>; Sat, 25 Jan 2025 10:14:02 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38c2a17d865sm6249213f8f.38.2025.01.25.10.14.00
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Sat, 25 Jan 2025 10:14:01 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 27a761a7-db48-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737828842; x=1738433642; 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=60AuA1WDx9vhZn9WTP7sL5YOcyHTmPSWNTPXV1fPX/g=;
        b=IFlm2xVQAoQfvtsA1V7yF+n0t4VdAbrIGxxDsUiOutAcB2a3fkoTR3/WbpNST1hPEd
         TYwZybs9iRmfjhmz6C1PGkSJ3gXQGct1y2xMS4u7nWnYRHGb0cgiR0ufF8xtxNSAEKBb
         yCTahB+URGpRTBcAd7XKPBmJ2Z9M0jpQt1PoOCDA9m60ECHEeyeHQuDYZGOXkcAYpgtK
         YdDxCarS07jWcGnWUUOqyliOISqDNFDfuqkGRfeLrlXn49DU0I0nTRN3LfdMKMdjaj/C
         xjqFMrRd2x3XcVhqWBxT8b3+03sNUStBhMQ+YbDnHWwKD7Gn28ACAKlIe1kNVCemx7UK
         fZpw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737828842; x=1738433642;
        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=60AuA1WDx9vhZn9WTP7sL5YOcyHTmPSWNTPXV1fPX/g=;
        b=W1yZX1ad7GKeDOq5rgSUBKvB7XXpm848/u9g3jzwSU/dJSxS2XV9XrLWKxJv0008lo
         dyexG4OzbSi75Zaf9Qjet1JVNoAQBSmqLzK00/Bx5wZTEYTqL+gPtCXGAbUMMv3C9yI3
         Mrp6fGHZ9ZNGaLipxhqLcqctpNCuiQzVnx9U2zniYq1MwIeE43EB8iHfW6lqzIh1yr6c
         RN21q0imF4E51J7lxwwozm8V4DiUMM/9G0rrdHcyDQL5xKZHnRc0YveKPptOXNoMbI1w
         bW/z0+aG6/G76nK74LMgn9uaTtyvaTuqvyILQg/2/61wwlUEkIgLrRSn/fNhSa0IKNuN
         envg==
X-Forwarded-Encrypted: i=1; AJvYcCUIdznIETPgwkhaAtsNyU4HV20D4VlGAXPSUnMx1AApuBYCgNGlDdhdGMpJ0FrM0MYh6STKYb9Q0vo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxcThVnL+YTwdUM/BAnXlFSAq8r7auXsYqZ0Rn6u9Ix6w2Mcv7Y
	40jsE0pL6PuxNt7XqnmsBLkGSBd30rNdcqyeZJ6omach0U/XJkoMqMwrzeMdtW0=
X-Gm-Gg: ASbGnct70fWQrkdtZb8AVj7QVxogs/OSrLgcmeXzS9ShD1MZ71XF3KffTt56WhgzNca
	cI+DTfUjrKEwGmV9vIn7GnVw97C8SxiJYrqsWKvnjY2CVpf2zvm+NV8c3dvlSmvjPky4S0vtIAT
	igW9dWRCMRNb2egQlCWJJ+hY1lRA3C7m+AV2tZArhhB3ZvBHP7uun2H4B1nyCnbmLdn6qN0F3Ey
	fp1wWtmqsg6wX4uVxXBIRtQOq74Z4rhw+UZTJ4ZKXv40ywKI1iGb/KiB6592PL3vxCrH+cgCxsW
	4h/g43hnW0aFNB+e7s/IGOComZK3mAgDTD2vEEqk83OpnAtTNcmOeQCyhUSg
X-Google-Smtp-Source: AGHT+IFmsyFMtRiyUoQTMlDTj6UgcQ0Wyp8q7Re0IHss6ougDQh97Nwe8Gj2HZEyku0oDKVtn8rFyg==
X-Received: by 2002:a05:6000:2c5:b0:37d:4647:154e with SMTP id ffacd0b85a97d-38bf5655bd3mr29759427f8f.9.1737828841654;
        Sat, 25 Jan 2025 10:14:01 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: Yi Liu <yi.l.liu@intel.com>,
	Markus Armbruster <armbru@redhat.com>,
	Eduardo Habkost <eduardo@habkost.net>,
	Anthony PERARD <anthony@xenproject.org>,
	Gustavo Romero <gustavo.romero@linaro.org>,
	Jason Wang <jasowang@redhat.com>,
	qemu-ppc@nongnu.org,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Alexander Graf <graf@amazon.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Stefan Berger <stefanb@linux.vnet.ibm.com>,
	Bernhard Beschow <shentey@gmail.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Gerd Hoffmann <kraxel@redhat.com>,
	=?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= <berrange@redhat.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	xen-devel@lists.xenproject.org,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Paul Durrant <paul@xen.org>,
	=?UTF-8?q?Cl=C3=A9ment=20Mathieu--Drif?= <clement.mathieu--drif@eviden.com>,
	=?UTF-8?q?C=C3=A9dric=20Le=20Goater?= <clg@redhat.com>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
Subject: [PATCH 3/9] hw/sysbus: Introduce TYPE_DYNAMIC_SYS_BUS_DEVICE
Date: Sat, 25 Jan 2025 19:13:37 +0100
Message-ID: <20250125181343.59151-4-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250125181343.59151-1-philmd@linaro.org>
References: <20250125181343.59151-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Some TYPE_SYS_BUS_DEVICEs can be optionally dynamically
plugged on the TYPE_PLATFORM_BUS_DEVICE.
Rather than sometimes noting that with comment around
the 'user_creatable = true' line in each DeviceRealize
handler, introduce an abstract TYPE_DYNAMIC_SYS_BUS_DEVICE
class.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 include/hw/sysbus.h |  2 ++
 hw/core/sysbus.c    | 14 ++++++++++++++
 2 files changed, 16 insertions(+)

diff --git a/include/hw/sysbus.h b/include/hw/sysbus.h
index c9b1e0e90e3..81bbda10d37 100644
--- a/include/hw/sysbus.h
+++ b/include/hw/sysbus.h
@@ -19,6 +19,8 @@ DECLARE_INSTANCE_CHECKER(BusState, SYSTEM_BUS,
 OBJECT_DECLARE_TYPE(SysBusDevice, SysBusDeviceClass,
                     SYS_BUS_DEVICE)
 
+#define TYPE_DYNAMIC_SYS_BUS_DEVICE "dynamic-sysbus-device"
+
 /**
  * SysBusDeviceClass:
  *
diff --git a/hw/core/sysbus.c b/hw/core/sysbus.c
index 306f98406c0..e8d03fd28d9 100644
--- a/hw/core/sysbus.c
+++ b/hw/core/sysbus.c
@@ -321,6 +321,14 @@ BusState *sysbus_get_default(void)
     return main_system_bus;
 }
 
+static void dynamic_sysbus_device_class_init(ObjectClass *klass, void *data)
+{
+    DeviceClass *k = DEVICE_CLASS(klass);
+
+    k->user_creatable = true;
+    k->hotpluggable = false;
+}
+
 static const TypeInfo sysbus_types[] = {
     {
         .name           = TYPE_SYSTEM_BUS,
@@ -336,6 +344,12 @@ static const TypeInfo sysbus_types[] = {
         .class_size     = sizeof(SysBusDeviceClass),
         .class_init     = sysbus_device_class_init,
     },
+    {
+        .name           = TYPE_DYNAMIC_SYS_BUS_DEVICE,
+        .parent         = TYPE_SYS_BUS_DEVICE,
+        .class_init     = dynamic_sysbus_device_class_init,
+        .abstract       = true,
+    }
 };
 
 DEFINE_TYPES(sysbus_types)
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Sat Jan 25 18:14:11 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Jan 2025 18:14:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877012.1287240 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbkfa-0005ri-TD; Sat, 25 Jan 2025 18:14:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877012.1287240; Sat, 25 Jan 2025 18:14:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbkfa-0005rb-Pt; Sat, 25 Jan 2025 18:14:10 +0000
Received: by outflank-mailman (input) for mailman id 877012;
 Sat, 25 Jan 2025 18:14:08 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=X0T4=UR=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tbkfY-000565-Th
 for xen-devel@lists.xenproject.org; Sat, 25 Jan 2025 18:14:08 +0000
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com
 [2a00:1450:4864:20::335])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2abdfab3-db48-11ef-99a4-01e77a169b0f;
 Sat, 25 Jan 2025 19:14:07 +0100 (CET)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-43622267b2eso32316685e9.0
 for <xen-devel@lists.xenproject.org>; Sat, 25 Jan 2025 10:14:07 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438bd4857c3sm68307685e9.10.2025.01.25.10.14.05
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Sat, 25 Jan 2025 10:14:06 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2abdfab3-db48-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737828847; x=1738433647; 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=dyOkRsNGVEWSIU/g0zj3C7+UfvVjzQgLwIYDoErjrzY=;
        b=E3O265wl8yaUU469AX64Lx2fHgrT11jgPvGuwnNbs2wApqv2zuUVgkd+ZrCcHWzbM9
         nuyw1pl9S3/SGydU1n4FEQkHTZsiIn2G47jTsnv1ckFrstQHyVBvQMz97zeIBRnDcGGv
         fBNp9dx2OkOGMJej9nItABW5MVvQJ4hy1DsdkT6Lr+NUi5/PNLq7lrg4GvgL4o3gqqql
         yz6Fec8OtOElEzfzMHdqt3qWT9vYR4bAlQOWnV/ZZhiqOw09spIhL8HtdlwISu32SCXG
         3VERGi0PMk8dIp/1dB5kCAZWYUeMeeMRw2WSpnmoXsj7PST+0dz58etulVZHCfR+5T7G
         jMHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737828847; x=1738433647;
        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=dyOkRsNGVEWSIU/g0zj3C7+UfvVjzQgLwIYDoErjrzY=;
        b=h4LxTu31Svs5wse0ClHatCNPvzJjf2/ylBctYZwijYPYY3si4YYbL/PtW30ZRntQ9W
         ZZAPR2QDHL/usRKB26UlzJ6r14gjghKAhe51BERYPhsdvpIb3Lra7T11YZ2A7tanyDjo
         wII+1DHMGwmmmK2bDtmKU/FC9j3hZF+9NRFf15b+5Kq4TpdRlPglJUp/plkDoDL3HJwM
         VSP2dvvSSDE8UamZsgltB9AKm3XWtZgU+cLR8gBXihaFzn1Y4/q0J+mrSOsNxv+q5ojt
         /T1m7XZtkYmJN8gVPPNn11bH2uyLUMncQlo1FgbF6A5CxUEYCV5J1pmfva4E0QpReDhy
         LqOA==
X-Forwarded-Encrypted: i=1; AJvYcCWvH5oNEE6kesSQPUmc8gwMEAsOb0ByRbnRM4+OGHF4Q70glcTw4AkGFi0QuMbHa+2Ayl7JMF1jo68=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyHTLGjFrv+XELr7wZKoXqGUOHp68I0a5rBIKnvEHoHYGhUyCEU
	+Nt45C0J8dhzBteka9c/cZgoD2qNleD/7bai5ht/UCD44QyGjxsmkrV2QAnzYOk=
X-Gm-Gg: ASbGncueZI9WCvpTZEWH6bRl7tPNeZ9YERv2TxwhJXJb5ljXkSZhViWAa5EdlLcDbbi
	X2A9rDoFdiXBNHg6XyCiWCU320hrUi4C18xlogxUB1py73TC4n77dZr//2SjFG1DT5+ecbUWNlR
	X7dZ4wbPapr0wqnJm7U6aMuO2CHeXMqYgK0JP2wizTYrPljzCUdAdWVfEyMN5JpmtppfKqO6YFC
	/qn4rEc5bTkv4LNnZveFzogViDkkPzJ07cR408jjI92vSRsS/ODiyGJojh4aFdKyC60985/21i3
	M4Y6/uybwhirkxOTK5jMURmdG3vwxFv8rIMdqb5vW0Q4KuytN2ysErF+xaWm
X-Google-Smtp-Source: AGHT+IEr2qoA1rRQRSxzBRg9AaVRyh1DsB0c2e066JVheh7W35FZo8o118MnJ47nSIRaQRkoz3MpFg==
X-Received: by 2002:a05:600c:468d:b0:436:4708:9fb6 with SMTP id 5b1f17b1804b1-43891437546mr293523335e9.20.1737828846888;
        Sat, 25 Jan 2025 10:14:06 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: Yi Liu <yi.l.liu@intel.com>,
	Markus Armbruster <armbru@redhat.com>,
	Eduardo Habkost <eduardo@habkost.net>,
	Anthony PERARD <anthony@xenproject.org>,
	Gustavo Romero <gustavo.romero@linaro.org>,
	Jason Wang <jasowang@redhat.com>,
	qemu-ppc@nongnu.org,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Alexander Graf <graf@amazon.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Stefan Berger <stefanb@linux.vnet.ibm.com>,
	Bernhard Beschow <shentey@gmail.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Gerd Hoffmann <kraxel@redhat.com>,
	=?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= <berrange@redhat.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	xen-devel@lists.xenproject.org,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Paul Durrant <paul@xen.org>,
	=?UTF-8?q?Cl=C3=A9ment=20Mathieu--Drif?= <clement.mathieu--drif@eviden.com>,
	=?UTF-8?q?C=C3=A9dric=20Le=20Goater?= <clg@redhat.com>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
Subject: [PATCH 4/9] hw/vfio: Have VFIO_PLATFORM devices inherit from DYNAMIC_SYS_BUS_DEVICE
Date: Sat, 25 Jan 2025 19:13:38 +0100
Message-ID: <20250125181343.59151-5-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250125181343.59151-1-philmd@linaro.org>
References: <20250125181343.59151-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Do not explain why VFIO_PLATFORM devices are user_creatable,
have them inherit TYPE_DYNAMIC_SYS_BUS_DEVICE, to explicit
they can optionally be plugged on TYPE_PLATFORM_BUS_DEVICE.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 hw/vfio/amd-xgbe.c      | 2 --
 hw/vfio/calxeda-xgmac.c | 2 --
 hw/vfio/platform.c      | 4 +---
 3 files changed, 1 insertion(+), 7 deletions(-)

diff --git a/hw/vfio/amd-xgbe.c b/hw/vfio/amd-xgbe.c
index 96bd608b8dd..aaa96903db0 100644
--- a/hw/vfio/amd-xgbe.c
+++ b/hw/vfio/amd-xgbe.c
@@ -41,8 +41,6 @@ static void vfio_amd_xgbe_class_init(ObjectClass *klass, void *data)
                                     &vcxc->parent_realize);
     dc->desc = "VFIO AMD XGBE";
     dc->vmsd = &vfio_platform_amd_xgbe_vmstate;
-    /* Supported by TYPE_VIRT_MACHINE */
-    dc->user_creatable = true;
 }
 
 static const TypeInfo vfio_amd_xgbe_dev_info = {
diff --git a/hw/vfio/calxeda-xgmac.c b/hw/vfio/calxeda-xgmac.c
index 87c382e7361..b016d42b496 100644
--- a/hw/vfio/calxeda-xgmac.c
+++ b/hw/vfio/calxeda-xgmac.c
@@ -41,8 +41,6 @@ static void vfio_calxeda_xgmac_class_init(ObjectClass *klass, void *data)
                                     &vcxc->parent_realize);
     dc->desc = "VFIO Calxeda XGMAC";
     dc->vmsd = &vfio_platform_calxeda_xgmac_vmstate;
-    /* Supported by TYPE_VIRT_MACHINE */
-    dc->user_creatable = true;
 }
 
 static const TypeInfo vfio_calxeda_xgmac_dev_info = {
diff --git a/hw/vfio/platform.c b/hw/vfio/platform.c
index 1070a2113a1..f491f4dc954 100644
--- a/hw/vfio/platform.c
+++ b/hw/vfio/platform.c
@@ -672,13 +672,11 @@ static void vfio_platform_class_init(ObjectClass *klass, void *data)
     dc->desc = "VFIO-based platform device assignment";
     sbc->connect_irq_notifier = vfio_start_irqfd_injection;
     set_bit(DEVICE_CATEGORY_MISC, dc->categories);
-    /* Supported by TYPE_VIRT_MACHINE */
-    dc->user_creatable = true;
 }
 
 static const TypeInfo vfio_platform_dev_info = {
     .name = TYPE_VFIO_PLATFORM,
-    .parent = TYPE_SYS_BUS_DEVICE,
+    .parent = TYPE_DYNAMIC_SYS_BUS_DEVICE,
     .instance_size = sizeof(VFIOPlatformDevice),
     .instance_init = vfio_platform_instance_init,
     .class_init = vfio_platform_class_init,
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Sat Jan 25 18:14:16 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Jan 2025 18:14:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877020.1287250 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbkfg-0006Lw-56; Sat, 25 Jan 2025 18:14:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877020.1287250; Sat, 25 Jan 2025 18:14:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbkfg-0006Lp-1N; Sat, 25 Jan 2025 18:14:16 +0000
Received: by outflank-mailman (input) for mailman id 877020;
 Sat, 25 Jan 2025 18:14: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 <SRS0=X0T4=UR=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tbkfe-000565-7O
 for xen-devel@lists.xenproject.org; Sat, 25 Jan 2025 18:14:14 +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 2dee327a-db48-11ef-99a4-01e77a169b0f;
 Sat, 25 Jan 2025 19:14:12 +0100 (CET)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-435f8f29f8aso22054715e9.2
 for <xen-devel@lists.xenproject.org>; Sat, 25 Jan 2025 10:14:12 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438bd4900e2sm68626685e9.24.2025.01.25.10.14.10
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Sat, 25 Jan 2025 10:14:11 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2dee327a-db48-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737828852; x=1738433652; 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=oekQdNljsXmvRCfjRcF/YH736cTnRtLa3bqMS7/4HKc=;
        b=kRDrcwQdbzmSmB8bU63/J64wP26Ii1A8PtSXws8H9JIo5A+Y/78FjH9j+JubgXPtNs
         zR2HMWsUiWelfOg37tSwpTq1+NmkRHE2Aa4vZrhBv7+oIPdV+DjIgHDdz5f13ON2Ivby
         Iu7zN8+pMKkB7UBBf8rTdahQgG4NSHzJPMBQ8Uj4RUBWnD0D559g6/8XJ8BnzwnN9VVr
         BrXkH650taRllw+oCNYcB93pAlkPwXKdLU7xWTlRhDcZwgLLxj3TjCMzau937b34elur
         6Ny1EzninbzZfj2tody8Fcsaa7dqjhiRO+H5y1tNnW7ToJfTpg6nsyvodLWaXVQNi8tF
         tpXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737828852; x=1738433652;
        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=oekQdNljsXmvRCfjRcF/YH736cTnRtLa3bqMS7/4HKc=;
        b=LWHgB5FrKztcwFEC7YVq+W4cIHTAmU6yRvouu/bfPHvIaM9H4TxBtdNlDY+mU31D7Z
         81VhmErx7lwuGEVHi/7AzKZetG2bkfgThbPZv5c1Qwrid7KaHxk1vA503Fp2yUPKoQpH
         TJKN2lJl1pvSZxJdrWmiRpEenJF3I2P8gZZxWoDpSWF1PWWBz+PmSZh70zutB/od7FVL
         2KHRsDvZJDTqNvnfSILVe7lG2q8qdOneH5RRS9CYsA4y3hrjg2xCGOFlW3UAY7qx4FUp
         SPr891So26CSsz4g6pYnEhOv5dSHad+DTmT/0AEUMiZ73VO4/3wJt2Vo7FDvSNYcvQhz
         ifLA==
X-Forwarded-Encrypted: i=1; AJvYcCW45ZiWpwA3Tj2jdEks8XMIJbwnX81e8Wb1U7d5qdx8IjxgkzRJyJO7lAvDVtNlPeCASu2FwAqF2X4=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw7yW/+0k9MTBUBgEdDwWNKiPjDig1PsfcOt49jKm9kCHzkETiq
	Bvt4HtN73NCgwfko0+Q07R16h/p6jxxCJbWks+UhFk8kfOJjuWykouy1IXUGLNk=
X-Gm-Gg: ASbGncvVBzSDtkpzCtFxJ9Xc1DTYSXuolO0XGx5Oaa2cKzRugPjQVxsr9DhdXxEbtn5
	d6e/l61r9HwJJMdPXGdmcZSkAtO/0s19GaudPXR4Vpni/m5s9SYhtafplmUGmXZDySkzJPjgEQW
	M+0EqZpkE6Hn8ji9xGL5Jh2ez3MHFt9KcTluwFEDI80KW5fhPedNYHE0aifqFBxWwBbV/EiT64S
	QhOhNVA1xqd5drkbFy53Nwj8EMqGUXenZwbFdtGn9SaB1ohTGBZQY2Tr6S4SKsPhWXpCiUKSij9
	TkZnkAlJr1aEqcJ98CQ990/jJAUdq9F7IW01epA/7VqHooTLVK3M+7PIzeau
X-Google-Smtp-Source: AGHT+IFcf5NC5w3OdMEeSdE+fJzRv8eMmKrsAaFn1q2W0Qs4+hxyDFiFEoLFYJSBxaKkISXGUJ3R0Q==
X-Received: by 2002:a05:600c:1f19:b0:434:a1d3:a30f with SMTP id 5b1f17b1804b1-438b9cc072emr109914115e9.6.1737828852191;
        Sat, 25 Jan 2025 10:14:12 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: Yi Liu <yi.l.liu@intel.com>,
	Markus Armbruster <armbru@redhat.com>,
	Eduardo Habkost <eduardo@habkost.net>,
	Anthony PERARD <anthony@xenproject.org>,
	Gustavo Romero <gustavo.romero@linaro.org>,
	Jason Wang <jasowang@redhat.com>,
	qemu-ppc@nongnu.org,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Alexander Graf <graf@amazon.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Stefan Berger <stefanb@linux.vnet.ibm.com>,
	Bernhard Beschow <shentey@gmail.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Gerd Hoffmann <kraxel@redhat.com>,
	=?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= <berrange@redhat.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	xen-devel@lists.xenproject.org,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Paul Durrant <paul@xen.org>,
	=?UTF-8?q?Cl=C3=A9ment=20Mathieu--Drif?= <clement.mathieu--drif@eviden.com>,
	=?UTF-8?q?C=C3=A9dric=20Le=20Goater?= <clg@redhat.com>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
Subject: [PATCH 5/9] hw/display: Have RAMFB device inherit from DYNAMIC_SYS_BUS_DEVICE
Date: Sat, 25 Jan 2025 19:13:39 +0100
Message-ID: <20250125181343.59151-6-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250125181343.59151-1-philmd@linaro.org>
References: <20250125181343.59151-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Because the RAM FB device can be optionally plugged on the
TYPE_PLATFORM_BUS_DEVICE, have it inherit TYPE_DYNAMIC_SYS_BUS_DEVICE.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 hw/display/ramfb-standalone.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/hw/display/ramfb-standalone.c b/hw/display/ramfb-standalone.c
index 6c35028965d..1be106b57f2 100644
--- a/hw/display/ramfb-standalone.c
+++ b/hw/display/ramfb-standalone.c
@@ -72,13 +72,12 @@ static void ramfb_class_initfn(ObjectClass *klass, void *data)
     dc->vmsd = &ramfb_dev_vmstate;
     dc->realize = ramfb_realizefn;
     dc->desc = "ram framebuffer standalone device";
-    dc->user_creatable = true;
     device_class_set_props(dc, ramfb_properties);
 }
 
 static const TypeInfo ramfb_info = {
     .name          = TYPE_RAMFB_DEVICE,
-    .parent        = TYPE_SYS_BUS_DEVICE,
+    .parent        = TYPE_DYNAMIC_SYS_BUS_DEVICE,
     .instance_size = sizeof(RAMFBStandaloneState),
     .class_init    = ramfb_class_initfn,
 };
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Sat Jan 25 18:14:20 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Jan 2025 18:14:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877028.1287260 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbkfk-0006kx-Ds; Sat, 25 Jan 2025 18:14:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877028.1287260; Sat, 25 Jan 2025 18:14:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbkfk-0006ko-9d; Sat, 25 Jan 2025 18:14:20 +0000
Received: by outflank-mailman (input) for mailman id 877028;
 Sat, 25 Jan 2025 18:14:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=X0T4=UR=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tbkfj-000565-OA
 for xen-devel@lists.xenproject.org; Sat, 25 Jan 2025 18:14:19 +0000
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com
 [2a00:1450:4864:20::32c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 310dec10-db48-11ef-99a4-01e77a169b0f;
 Sat, 25 Jan 2025 19:14:18 +0100 (CET)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-43621d27adeso20827385e9.2
 for <xen-devel@lists.xenproject.org>; Sat, 25 Jan 2025 10:14:18 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438bd54c066sm67839795e9.29.2025.01.25.10.14.16
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Sat, 25 Jan 2025 10:14:17 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 310dec10-db48-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737828857; x=1738433657; 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=w1nS9BzjJB0tn/0Fa9F2b1T3lbd2oKgl5iwd0JMSerQ=;
        b=eFBesdrMiTebZm1ezPYRTAvmBhUY8ufXa/xDBnjmUG+JoObKcl5SVBTtErKJ6Q5OZd
         NKGc7poeu4rMJZYvL8b9ZACIV/3jYYv4DNcXxlbTjg8bc8XPE6gIunmzXmetxMIxin1c
         P/gUe/7om8FeRyQ/uJV05QG+27iaZCWqSOztVXUFrvMVsQpYMTb2T0YogbLL/n8FUbef
         YEPOD71TZ4TyFgRVcg7LS8e8coqPPFoc8l7fi62dhwRLswqE12kUWhh+DkkRWdgESv2a
         ZxslaYQqLy4aNcvb0z/t7vaib6/loY40lhhfhf88MFcjhDDK/eOM3RetiBMfkZtut4na
         8WVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737828857; x=1738433657;
        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=w1nS9BzjJB0tn/0Fa9F2b1T3lbd2oKgl5iwd0JMSerQ=;
        b=nzR1nYkO0O5SN9fnno2gLb/ASD4Br/YOcBXpOz+Adki+lJiiOQ+okjdTF84S8xKb/X
         ouckhldsy/W3+Zbp7eIPKQMqj8OUqFX6Q/dUNMteB//synICe3wQ5WOstyFoAIRTnv3i
         D/Ke08WSShT6JP9ZbPOmtpapD4+ISTGHXDHllAZ1PgvopB40Xy2g6s0cAjjSdwxCLI62
         MfjHYhg4/H4H5tumrIs30QecZGkK5vVhmVjwwkFKDMIsYg8ibyDKv/24GgIqb+qvhIJz
         5g/7cQmRiMpvSPoWFfTYtjBoPkqFQaDdM4KTbtNcx7XDgxHwOE8jbqQHxQ+RsOzFliT+
         eqUw==
X-Forwarded-Encrypted: i=1; AJvYcCWWgYJjpyk+aRgpdi1x4VB6xsGZgxIg4HY8adbX84KhjQBWeof2GzfbatHzac9Uu8bZcNzfReTpGTs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YztDwgM9J/NJHY4gzonZej7jMEUG8NxNuWcqIqoh9BC0OtmhClC
	3noXXPXuD8giH6AzzLn+zSxGdDJuKM9ESZdTUTeetho00IK6U2cq0m6sRgCwV9Q=
X-Gm-Gg: ASbGncs58a7Og6w6sxS8HupobpRQUF3PzFdwcpC9Aep1uEAW4mtBHMMqLZFdYEl/8es
	JOcKbLGOvZD/l62m+AYDOjZJAElqb+Sk4erUhaPM1pgPzQmPAAq+kjPUFvyA6HykrEgjmT3e9+G
	S24+1fiSHqa6lGyMwbf1xARLS9Lwcgwkxc25lLyUIblzDPapZbfvcjAyYnEIeTe0KnqFYqCPkMS
	VO+DjvKJN6C00t5yyEGDf74Fo1YG2ps7v0pyjelDtBREDv5EU9RHfYT0F4W3VmpXtixFxGMGq+d
	jQfGVU0trR4857vR9lnx66a/dG8iex8/7dKYRw/RpI4s4lQvFGaJr9ecMc26
X-Google-Smtp-Source: AGHT+IE5XUCSuHVVDMagGbiF8o/U1zOarBMIVGYFxMB07VQ6SArrPMMpgZuB4UE+b0bVMHzNNBLvMA==
X-Received: by 2002:a7b:cc8f:0:b0:438:a214:52f4 with SMTP id 5b1f17b1804b1-438a2145332mr233337725e9.25.1737828857490;
        Sat, 25 Jan 2025 10:14:17 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: Yi Liu <yi.l.liu@intel.com>,
	Markus Armbruster <armbru@redhat.com>,
	Eduardo Habkost <eduardo@habkost.net>,
	Anthony PERARD <anthony@xenproject.org>,
	Gustavo Romero <gustavo.romero@linaro.org>,
	Jason Wang <jasowang@redhat.com>,
	qemu-ppc@nongnu.org,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Alexander Graf <graf@amazon.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Stefan Berger <stefanb@linux.vnet.ibm.com>,
	Bernhard Beschow <shentey@gmail.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Gerd Hoffmann <kraxel@redhat.com>,
	=?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= <berrange@redhat.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	xen-devel@lists.xenproject.org,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Paul Durrant <paul@xen.org>,
	=?UTF-8?q?Cl=C3=A9ment=20Mathieu--Drif?= <clement.mathieu--drif@eviden.com>,
	=?UTF-8?q?C=C3=A9dric=20Le=20Goater?= <clg@redhat.com>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
Subject: [PATCH 6/9] hw/i386: Have X86_IOMMU devices inherit from DYNAMIC_SYS_BUS_DEVICE
Date: Sat, 25 Jan 2025 19:13:40 +0100
Message-ID: <20250125181343.59151-7-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250125181343.59151-1-philmd@linaro.org>
References: <20250125181343.59151-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Do not explain why _X86_IOMMU devices are user_creatable,
have them inherit TYPE_DYNAMIC_SYS_BUS_DEVICE, to explicit
they can optionally be plugged on TYPE_PLATFORM_BUS_DEVICE.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 hw/i386/amd_iommu.c   | 2 --
 hw/i386/intel_iommu.c | 2 --
 hw/i386/x86-iommu.c   | 2 +-
 3 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/hw/i386/amd_iommu.c b/hw/i386/amd_iommu.c
index 6b13ce894b1..e8e084c7cf8 100644
--- a/hw/i386/amd_iommu.c
+++ b/hw/i386/amd_iommu.c
@@ -1687,8 +1687,6 @@ static void amdvi_sysbus_class_init(ObjectClass *klass, void *data)
     dc->hotpluggable = false;
     dc_class->realize = amdvi_sysbus_realize;
     dc_class->int_remap = amdvi_int_remap;
-    /* Supported by the pc-q35-* machine types */
-    dc->user_creatable = true;
     set_bit(DEVICE_CATEGORY_MISC, dc->categories);
     dc->desc = "AMD IOMMU (AMD-Vi) DMA Remapping device";
     device_class_set_props(dc, amdvi_properties);
diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
index f366c223d0e..7fde0603bfe 100644
--- a/hw/i386/intel_iommu.c
+++ b/hw/i386/intel_iommu.c
@@ -4871,8 +4871,6 @@ static void vtd_class_init(ObjectClass *klass, void *data)
     dc->hotpluggable = false;
     x86_class->realize = vtd_realize;
     x86_class->int_remap = vtd_int_remap;
-    /* Supported by the pc-q35-* machine types */
-    dc->user_creatable = true;
     set_bit(DEVICE_CATEGORY_MISC, dc->categories);
     dc->desc = "Intel IOMMU (VT-d) DMA Remapping device";
 }
diff --git a/hw/i386/x86-iommu.c b/hw/i386/x86-iommu.c
index fed34b2fcfa..5cdd165af0d 100644
--- a/hw/i386/x86-iommu.c
+++ b/hw/i386/x86-iommu.c
@@ -146,7 +146,7 @@ bool x86_iommu_ir_supported(X86IOMMUState *s)
 
 static const TypeInfo x86_iommu_info = {
     .name          = TYPE_X86_IOMMU_DEVICE,
-    .parent        = TYPE_SYS_BUS_DEVICE,
+    .parent        = TYPE_DYNAMIC_SYS_BUS_DEVICE,
     .instance_size = sizeof(X86IOMMUState),
     .class_init    = x86_iommu_class_init,
     .class_size    = sizeof(X86IOMMUClass),
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Sat Jan 25 18:14:27 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Jan 2025 18:14:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877038.1287270 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbkfr-0007NG-OA; Sat, 25 Jan 2025 18:14:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877038.1287270; Sat, 25 Jan 2025 18:14:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbkfr-0007Mw-JU; Sat, 25 Jan 2025 18:14:27 +0000
Received: by outflank-mailman (input) for mailman id 877038;
 Sat, 25 Jan 2025 18:14:26 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=X0T4=UR=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tbkfq-0004aj-8j
 for xen-devel@lists.xenproject.org; Sat, 25 Jan 2025 18:14:26 +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 3583c3d5-db48-11ef-a0e5-8be0dac302b0;
 Sat, 25 Jan 2025 19:14:25 +0100 (CET)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-4361815b96cso20866275e9.1
 for <xen-devel@lists.xenproject.org>; Sat, 25 Jan 2025 10:14:25 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438bd4d29cesm69824895e9.35.2025.01.25.10.14.21
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Sat, 25 Jan 2025 10:14:23 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 3583c3d5-db48-11ef-a0e5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737828865; x=1738433665; 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=J6WqpNLLgPHFQ99I41LLhDNBlDQghx4mWgl59MS9KjI=;
        b=PAiFrCXOUDqU7nzb8Yrw2aUD8pdEjbr5FIK8KmdIyHq59pvaV4KI5FpJ1ZL0dxv2BU
         LpBsvBlcdsjr98+ZExv+tiR0TlXPijW4kk7l8wQMVXNudH3elPXK+sqoKmZlF57SHrJ5
         DPCXnvVr915yY9mSP0DCQaI+xzgdDARW4Q8VrjTwImcK0OmG9LoGnjMXQbye/Pm/MXKz
         G2dujPk2KmeZ6VFLKcS31ZsxUpuNGbepj+219vUShp03j3IABQWJ7qhJrqd0mW9NreNB
         Ul9RRjXZHy+CBRv61p5ZqgNZ8Yk5mFSA0v+JUWODjkznr2oQUSe6VLWk7s4e6gZ1wgQd
         EfYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737828865; x=1738433665;
        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=J6WqpNLLgPHFQ99I41LLhDNBlDQghx4mWgl59MS9KjI=;
        b=jnpcUvy8pzPJU+0yoInxRioXg4QGKDNnpnfRghSICSNGEm0BoL8nAb+3HpqLsnYKrv
         mtJc5niI1lXE2Ug41ZsUCvBUv1ci/Po3ZwccrOxmi7kq/8pjzt3yqVBivr6WucWuOeQN
         ddProj+5MoMGxX/ANq6TbcF9KTu1Qgj6X8OP5YmNIxtimgqJPq+cfpc+aG8V4xJybgpY
         S3o0M8GjKS3cVnOPEvIyh1EA6yM3+YNbOhOjCfBcmjzlYXutQBV9vuDEjbuW87b7FduN
         2IjxyW0D1gHvC8pJi8zg8uIIlzKvlf9sG4AMfCU2Q6Vir6f3ktoTOZc0alOzZN4d4peR
         j3+g==
X-Forwarded-Encrypted: i=1; AJvYcCW85B297nJktt6g6FDN/rAqH2MG+fxpp1po/QVvevQ7f+Uupj+5zv1vue6oTUdbpYbHJgsFe8bIia4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwREfUbzw2qWbaVu8JCaaxKrspal/lY7atts09m9aR7PJKWWd/L
	HMKW94F6z35DzUdJtN4IPhAbmVWQVPaInmZraqWPQ8EWGBy6iR2B8ulP47UV3yg=
X-Gm-Gg: ASbGncu8TsudT+gwo4irg0DrYW4NndNa7fANyZZjVpEBKPylGWT0zyVgffMnE3ub3Re
	eY0Wva02BEAIxFHWQwZv4vo1GV1YqFX7Tv07svmroFgmHP4wOk/A2G8WWvfIPFF1CeadlmCM3Qs
	9LIFIYTwm03aX7VmlVOIqbDBiJwnKcZ08kKfAhEaVpFdv+FfM9nHdiSoDVu1bRtvcmTR56WX+mm
	r8N8RXasJOM5NyrCJyOT4OvLIuebqSflZ/3ZYM6pDtCRPR3yYs/byoW87IRyNEpEjo2peCtP+tU
	3TLzjMjbniXdD9xzMbCdtwlb4dclGN/OJoJQma3WM8Fwnl1xfbzFaO6kJoWS
X-Google-Smtp-Source: AGHT+IHtukcUsuBgToag1rm73vPOv6PLwBxDIv19SmO8jk0VeznszQ2sl5L6woNkrDfICXUGMJC2jg==
X-Received: by 2002:a05:600c:1f86:b0:436:faeb:2a1b with SMTP id 5b1f17b1804b1-438913db2cfmr312879235e9.13.1737828864896;
        Sat, 25 Jan 2025 10:14:24 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: Yi Liu <yi.l.liu@intel.com>,
	Markus Armbruster <armbru@redhat.com>,
	Eduardo Habkost <eduardo@habkost.net>,
	Anthony PERARD <anthony@xenproject.org>,
	Gustavo Romero <gustavo.romero@linaro.org>,
	Jason Wang <jasowang@redhat.com>,
	qemu-ppc@nongnu.org,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Alexander Graf <graf@amazon.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Stefan Berger <stefanb@linux.vnet.ibm.com>,
	Bernhard Beschow <shentey@gmail.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Gerd Hoffmann <kraxel@redhat.com>,
	=?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= <berrange@redhat.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	xen-devel@lists.xenproject.org,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Paul Durrant <paul@xen.org>,
	=?UTF-8?q?Cl=C3=A9ment=20Mathieu--Drif?= <clement.mathieu--drif@eviden.com>,
	=?UTF-8?q?C=C3=A9dric=20Le=20Goater?= <clg@redhat.com>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
Subject: [PATCH 7/9] hw/net: Have eTSEC device inherit from DYNAMIC_SYS_BUS_DEVICE
Date: Sat, 25 Jan 2025 19:13:41 +0100
Message-ID: <20250125181343.59151-8-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250125181343.59151-1-philmd@linaro.org>
References: <20250125181343.59151-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Because the network eTSEC device can be optionally plugged on the
TYPE_PLATFORM_BUS_DEVICE, have it inherit TYPE_DYNAMIC_SYS_BUS_DEVICE.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 hw/net/fsl_etsec/etsec.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/hw/net/fsl_etsec/etsec.c b/hw/net/fsl_etsec/etsec.c
index 781b9003954..3ce4fa2662d 100644
--- a/hw/net/fsl_etsec/etsec.c
+++ b/hw/net/fsl_etsec/etsec.c
@@ -425,14 +425,12 @@ static void etsec_class_init(ObjectClass *klass, void *data)
     dc->realize = etsec_realize;
     device_class_set_legacy_reset(dc, etsec_reset);
     device_class_set_props(dc, etsec_properties);
-    /* Supported by ppce500 machine */
-    dc->user_creatable = true;
 }
 
 static const TypeInfo etsec_types[] = {
     {
         .name          = TYPE_ETSEC_COMMON,
-        .parent        = TYPE_SYS_BUS_DEVICE,
+        .parent        = TYPE_DYNAMIC_SYS_BUS_DEVICE,
         .instance_size = sizeof(eTSEC),
         .class_init    = etsec_class_init,
         .instance_init = etsec_instance_init,
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Sat Jan 25 18:20:48 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Jan 2025 18:20:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877067.1287280 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbklw-0001SG-JX; Sat, 25 Jan 2025 18:20:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877067.1287280; Sat, 25 Jan 2025 18:20:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbklw-0001S9-GN; Sat, 25 Jan 2025 18:20:44 +0000
Received: by outflank-mailman (input) for mailman id 877067;
 Sat, 25 Jan 2025 18:20: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 <SRS0=X0T4=UR=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tbkfw-0004aj-G7
 for xen-devel@lists.xenproject.org; Sat, 25 Jan 2025 18:14:32 +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 3899b430-db48-11ef-a0e5-8be0dac302b0;
 Sat, 25 Jan 2025 19:14:30 +0100 (CET)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-436ce2ab251so20164085e9.1
 for <xen-devel@lists.xenproject.org>; Sat, 25 Jan 2025 10:14:30 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38c2a176434sm6225313f8f.13.2025.01.25.10.14.28
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Sat, 25 Jan 2025 10:14:29 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 3899b430-db48-11ef-a0e5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737828870; x=1738433670; 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=OjNRCKPy/l7f95vUUTcVvrIiqVVOepFXrbHeokjkTeQ=;
        b=R3aVdPAUhguLT5kpNme6AZC88RmfolhJpPq54ZQm0eqMCjpOAlhNXCXdS8G7uccpVb
         4bWLW6rEgLB75skcTm0t5isdAwig+IxBo3pWxrqB19xc3QfiwJk5+p9TPMuzeHY2deUO
         EuZf6wtw/OoXBmsDKvzZUnDrZwc+oNDpxczCUebGzhA421uDkPjzYNtJuYeI5OybkwEH
         WwzbyjSGJlGHXkFNOFAt/vXxGd6XvefWbGQE5yzyNo7yFQmCKP73Kdp4TFxlj7aAn8Bg
         D3/61m2dgz8ztKU8rtoGAQws6qF8EgjEDedgOvBgF7ltnoJlHbwdibnp5vhdRWcrEaYi
         JvpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737828870; x=1738433670;
        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=OjNRCKPy/l7f95vUUTcVvrIiqVVOepFXrbHeokjkTeQ=;
        b=k9o9cwLbx/AyogCSTJkdqKmthAUYrESUqiYlApGuC7LCrMOqZXryOhfh1nvPkzudWk
         kwuWDwH9PK1spnOq2tlnVe17plgZF49c90j1oJjFP2N4LwNpwuBz7vfCIr7PNlXnbC7k
         JEbFN8uv66Q37RMBXnKYm25cdBHzkckfdRZE2b7mtwrgohbthay0X0qr/EeJbeL4Y3h7
         o4q9RC0GfyV7xbuyx4VAwXQYDYxxdiVSP1XgdsnwOpColZOGmDNWt8bxv6nKBSD7qjUC
         1RwS6W5N1q7DghUQ8ywimOdmnVb9woYK1ISu8hnPyt10dJIxKWQpyOhHgjrvMDop7uBM
         75MQ==
X-Forwarded-Encrypted: i=1; AJvYcCWXw9CAg1gbMnfAEEuNlPgA8h+9TtTynPKDyHCfqBDCKF2Z14oMGlc/Or36rEUWDdHQWkQ12fHHwu4=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz9s42p1RXgEcA79qzmjk26Sf2b43FjvwHOEZBiz96IZWvVHlXg
	Zbf1mxrBUTFD5lZ5Zj3FY9pa52hFEbUPHkF7cwyFZSpXVttJVq3dmIyPdHXuGiM=
X-Gm-Gg: ASbGnct7hZ1Cg8pnh0AcNwsIK+enJUZY8aFOnHKoaIn1wRSX9LPePf4l2FbeW33U9Z6
	gbAGKbvqvWzgBh2aRD7T3tyZulglDgKmt73I6WmTsQTa+oAg2KXVOBPbaFcUHWTAkK5lM44mT2m
	O8HLGmAEaLh0M3zFDzPrKaQ4Qz7mrPWnkIs8Vu/EP+StuSPoJklGeStx6AD5CHYw0QvZiHIbH+T
	McMxSPj2vlE8OOeIR7GYvyA3BQZtBIS9iCloHdjgb4nk4LDb5KCTn9u/CUTPR9zmyt+xFDW4iCp
	RypO7Z1YJJl71f2I3yPkW2ZvjfqM2wakBBlKHuIUo5GA0NvIVqNdFTFl6Zfe
X-Google-Smtp-Source: AGHT+IGsW1rE0tr04FeKYA2KGXlK/mvTNA5dlL64lnJuwONXDJIce4w6YtcdzlGTbIKmz0lEq52uwg==
X-Received: by 2002:a5d:4d83:0:b0:385:f195:2a8 with SMTP id ffacd0b85a97d-38bf566cd2emr22422454f8f.30.1737828870120;
        Sat, 25 Jan 2025 10:14:30 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: Yi Liu <yi.l.liu@intel.com>,
	Markus Armbruster <armbru@redhat.com>,
	Eduardo Habkost <eduardo@habkost.net>,
	Anthony PERARD <anthony@xenproject.org>,
	Gustavo Romero <gustavo.romero@linaro.org>,
	Jason Wang <jasowang@redhat.com>,
	qemu-ppc@nongnu.org,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Alexander Graf <graf@amazon.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Stefan Berger <stefanb@linux.vnet.ibm.com>,
	Bernhard Beschow <shentey@gmail.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Gerd Hoffmann <kraxel@redhat.com>,
	=?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= <berrange@redhat.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	xen-devel@lists.xenproject.org,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Paul Durrant <paul@xen.org>,
	=?UTF-8?q?Cl=C3=A9ment=20Mathieu--Drif?= <clement.mathieu--drif@eviden.com>,
	=?UTF-8?q?C=C3=A9dric=20Le=20Goater?= <clg@redhat.com>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
Subject: [PATCH 8/9] hw/tpm: Have TPM TIS sysbus device inherit from DYNAMIC_SYS_BUS_DEVICE
Date: Sat, 25 Jan 2025 19:13:42 +0100
Message-ID: <20250125181343.59151-9-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250125181343.59151-1-philmd@linaro.org>
References: <20250125181343.59151-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Because the TPM TIS sysbus device can be optionally plugged on the
TYPE_PLATFORM_BUS_DEVICE, have it inherit TYPE_DYNAMIC_SYS_BUS_DEVICE.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 hw/tpm/tpm_tis_sysbus.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/hw/tpm/tpm_tis_sysbus.c b/hw/tpm/tpm_tis_sysbus.c
index ee0bfe9538e..4f187690a28 100644
--- a/hw/tpm/tpm_tis_sysbus.c
+++ b/hw/tpm/tpm_tis_sysbus.c
@@ -133,7 +133,6 @@ static void tpm_tis_sysbus_class_init(ObjectClass *klass, void *data)
     dc->vmsd  = &vmstate_tpm_tis_sysbus;
     tc->model = TPM_MODEL_TPM_TIS;
     dc->realize = tpm_tis_sysbus_realizefn;
-    dc->user_creatable = true;
     device_class_set_legacy_reset(dc, tpm_tis_sysbus_reset);
     tc->request_completed = tpm_tis_sysbus_request_completed;
     tc->get_version = tpm_tis_sysbus_get_tpm_version;
@@ -142,7 +141,7 @@ static void tpm_tis_sysbus_class_init(ObjectClass *klass, void *data)
 
 static const TypeInfo tpm_tis_sysbus_info = {
     .name = TYPE_TPM_TIS_SYSBUS,
-    .parent = TYPE_SYS_BUS_DEVICE,
+    .parent = TYPE_DYNAMIC_SYS_BUS_DEVICE,
     .instance_size = sizeof(TPMStateSysBus),
     .instance_init = tpm_tis_sysbus_initfn,
     .class_init  = tpm_tis_sysbus_class_init,
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Sat Jan 25 18:21:18 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Jan 2025 18:21:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877076.1287290 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbkmT-00022S-Ri; Sat, 25 Jan 2025 18:21:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877076.1287290; Sat, 25 Jan 2025 18:21:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbkmT-00022L-No; Sat, 25 Jan 2025 18:21:17 +0000
Received: by outflank-mailman (input) for mailman id 877076;
 Sat, 25 Jan 2025 18:21:16 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=X0T4=UR=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tbkg1-000565-Dx
 for xen-devel@lists.xenproject.org; Sat, 25 Jan 2025 18:14:37 +0000
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com
 [2a00:1450:4864:20::42e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3bb8d6d0-db48-11ef-99a4-01e77a169b0f;
 Sat, 25 Jan 2025 19:14:35 +0100 (CET)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-38634c35129so2839719f8f.3
 for <xen-devel@lists.xenproject.org>; Sat, 25 Jan 2025 10:14:35 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38c2a176490sm6041968f8f.1.2025.01.25.10.14.33
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Sat, 25 Jan 2025 10:14:34 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 3bb8d6d0-db48-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737828875; x=1738433675; 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=bl6x3NGb6owz3SHDZJmiiZ4r1za5TcxmylUs2G0w4SA=;
        b=MzxmPvjlGOARY7CzHWPsCrATcH3j5+MVdYyjAzrqoWQrOQR2+0+sSyci+/mBFkM3TP
         2x51gqia362cVAj67XryFhVDi2wI068GQNkMlvmKkt3NwcRycy7OhoXSePGd5gw8E74K
         XPOjObItHTA15eEq7txG4Dfecu/gvEta2JTW+C01a176YD/cGPmfoNkHXKmAfJ4hiL96
         JY6UikE1/1jPi2nGlHyx4o3VcQXquXjwcIjy93EPTaUrZYJVJ79FXhpjd4PiYdpfUqdv
         YYjuGjTxPglhJgwBGleHXJH+zr1osCT+Bz7Hw/Sf37Ju5w45N5FyJXh8VMD+RLZhgC5V
         15wA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737828875; x=1738433675;
        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=bl6x3NGb6owz3SHDZJmiiZ4r1za5TcxmylUs2G0w4SA=;
        b=B99hmk03Pxiqrmkl9m8AUmc3LZwhAEHB0L7ys3RvRd+yJiWG46RLVJMB/alizXl5ul
         0yst4MZpQ/+WUjLQRssus6IOkkvD8WPs1Vxwdo8AvDRdqkNMmidaUA3fTcFZ5YnjCfvX
         3/5RIpgZylJmYuaEBWSIV0z64i1bmF5Yr1ygzEQfhJsR9eH75qKKBQLwQTaSORNGc4od
         DiYKECuwFnBo7YA2RwswG/nBGlnGDSqxbhikLLkaZ1gEX64dKzP/TqOMc/757GF1nsu1
         TxyYrGd2l9QGJONZt4iLGIFvnj711mytaUd/jDatiQx2UAngPTQh/cZb90qA/XUZ/tWt
         zZJw==
X-Forwarded-Encrypted: i=1; AJvYcCVcwVc0U05VG1jgOBSfTtBoDEMEkSRBXfORhoG9rcd9Sbn98zNVWJ0EJ3AdJUPuJbMe9Y8Y/UwG8fs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YypvZPtVKWOo48K+26ALr1Q13MNTCnnt2oQxrk5F2aHj2vtZLE2
	DysmPpowsnSvkEG7lArnyfQxpypH/4ZKv2O5tGIIJa8gojwAq3YwTpSfR8XPTgo=
X-Gm-Gg: ASbGncu1QnZ0bDz22a11rY8ZdgZnLsPRJugnhpcmK2NAbbDWArezTKTwbgRowPW+tFI
	IMdTkCqv+ytRQ1HuwvnTiysAGiDOBJFZqXnUJWxNHJdx/Y2pchRKe2VvOvOGnmpDTHYlOlk+UqG
	eteQldDsRkLAzrxlo8ULHHeArUFGxw/QvfZuj8NLGEGs4SUnPviccMxthJJ8G+B8y+8G6g7Jh00
	mR3HTcnrdPgZ0le6v9wX6kpKVv2PJeMJZsWXYKoyaOPgStOOSWqwvzsGTZyf7GXxphA+JfaWQYU
	/82JlF0d8jedt2L4dXizZ2GZ6sZzUlbTdrdMEnRV9F7e2PA2Wmo6agBESXkT
X-Google-Smtp-Source: AGHT+IH6Im9WAFP62p+c65YcO9soXGrjbd4TGzQetbCmkepXX8mf8yxKvYvU59Qz1V1TA9WTvs42GQ==
X-Received: by 2002:adf:f504:0:b0:385:ecdf:a30a with SMTP id ffacd0b85a97d-38bf57ab510mr28008868f8f.33.1737828875399;
        Sat, 25 Jan 2025 10:14:35 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: Yi Liu <yi.l.liu@intel.com>,
	Markus Armbruster <armbru@redhat.com>,
	Eduardo Habkost <eduardo@habkost.net>,
	Anthony PERARD <anthony@xenproject.org>,
	Gustavo Romero <gustavo.romero@linaro.org>,
	Jason Wang <jasowang@redhat.com>,
	qemu-ppc@nongnu.org,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Alexander Graf <graf@amazon.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Stefan Berger <stefanb@linux.vnet.ibm.com>,
	Bernhard Beschow <shentey@gmail.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Gerd Hoffmann <kraxel@redhat.com>,
	=?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= <berrange@redhat.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	xen-devel@lists.xenproject.org,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Paul Durrant <paul@xen.org>,
	=?UTF-8?q?Cl=C3=A9ment=20Mathieu--Drif?= <clement.mathieu--drif@eviden.com>,
	=?UTF-8?q?C=C3=A9dric=20Le=20Goater?= <clg@redhat.com>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
Subject: [RFC PATCH 9/9] hw/xen: Have legacy Xen backend inherit from DYNAMIC_SYS_BUS_DEVICE
Date: Sat, 25 Jan 2025 19:13:43 +0100
Message-ID: <20250125181343.59151-10-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250125181343.59151-1-philmd@linaro.org>
References: <20250125181343.59151-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Because the legacy Xen backend devices can optionally be plugged on the
TYPE_PLATFORM_BUS_DEVICE, have it inherit TYPE_DYNAMIC_SYS_BUS_DEVICE.
Remove the implicit TYPE_XENSYSDEV instance_size.

Untested, but I'm surprised the legacy devices work because they
had a broken instance size (QDev instead of Sysbus...), so accesses
of XenLegacyDevice fields were overwritting sysbus ones.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 include/hw/xen/xen_pvdev.h  | 3 ++-
 hw/xen/xen-legacy-backend.c | 7 ++-----
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/include/hw/xen/xen_pvdev.h b/include/hw/xen/xen_pvdev.h
index 0c984440476..48950dc2b57 100644
--- a/include/hw/xen/xen_pvdev.h
+++ b/include/hw/xen/xen_pvdev.h
@@ -32,7 +32,8 @@ struct XenDevOps {
 };
 
 struct XenLegacyDevice {
-    DeviceState        qdev;
+    SysBusDevice parent_obj;
+
     const char         *type;
     int                dom;
     int                dev;
diff --git a/hw/xen/xen-legacy-backend.c b/hw/xen/xen-legacy-backend.c
index 118c571b3a7..4d079e35d83 100644
--- a/hw/xen/xen-legacy-backend.c
+++ b/hw/xen/xen-legacy-backend.c
@@ -640,16 +640,14 @@ static void xendev_class_init(ObjectClass *klass, void *data)
     DeviceClass *dc = DEVICE_CLASS(klass);
 
     set_bit(DEVICE_CATEGORY_MISC, dc->categories);
-    /* xen-backend devices can be plugged/unplugged dynamically */
-    dc->user_creatable = true;
     dc->bus_type = TYPE_XENSYSBUS;
 }
 
 static const TypeInfo xendev_type_info = {
     .name          = TYPE_XENBACKEND,
-    .parent        = TYPE_DEVICE,
+    .parent        = TYPE_DYNAMIC_SYS_BUS_DEVICE,
     .class_init    = xendev_class_init,
-    .instance_size = sizeof(struct XenLegacyDevice),
+    .instance_size = sizeof(XenLegacyDevice),
 };
 
 static void xen_sysbus_class_init(ObjectClass *klass, void *data)
@@ -672,7 +670,6 @@ static const TypeInfo xensysbus_info = {
 static const TypeInfo xensysdev_info = {
     .name          = TYPE_XENSYSDEV,
     .parent        = TYPE_SYS_BUS_DEVICE,
-    .instance_size = sizeof(SysBusDevice),
 };
 
 static void xenbe_register_types(void)
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Sun Jan 26 00:24:46 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Jan 2025 00:24:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877126.1287300 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbqRy-0001Pm-R8; Sun, 26 Jan 2025 00:24:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877126.1287300; Sun, 26 Jan 2025 00:24:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbqRy-0001Pf-Na; Sun, 26 Jan 2025 00:24:30 +0000
Received: by outflank-mailman (input) for mailman id 877126;
 Sun, 26 Jan 2025 00:24: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
 <SRS0=qu6a=US=bounce.vates.tech=bounce-md_30504962.679580b9.v1-4ae9820069564f3f88597e3d4791d2d6@srs-se1.protection.inumbo.net>)
 id 1tbqRy-0001PX-2C
 for xen-devel@lists.xenproject.org; Sun, 26 Jan 2025 00:24:30 +0000
Received: from mail180-4.suw31.mandrillapp.com
 (mail180-4.suw31.mandrillapp.com [198.2.180.4])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e67d0062-db7b-11ef-a0e5-8be0dac302b0;
 Sun, 26 Jan 2025 01:24:27 +0100 (CET)
Received: from pmta11.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail180-4.suw31.mandrillapp.com (Mailchimp) with ESMTP id 4YgXNn62V4zlfq7b
 for <xen-devel@lists.xenproject.org>; Sun, 26 Jan 2025 00:24:25 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 4ae9820069564f3f88597e3d4791d2d6; Sun, 26 Jan 2025 00:24:25 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e67d0062-db7b-11ef-a0e5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1737851065; x=1738121065;
	bh=Fso/TxpSFQtDqap0uHljRirvoodY3kMgWJHR5PV+Qh4=;
	h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=OuVYEfthjELm6svqERMJs8FOaA/EnqgpF+V3cnrZbEHxwOOIukM6su0JRm/kW9cWE
	 YwyLg9BsMNU+GSMUpfcV2ZVUjw6iS8sunamWvFVfuCvWSOyeD38ZElqm6DYSPXqs4t
	 hxmdlNY3MckIIKKMSEUT3HPiWsmK1bGaoiqOK0dO+9NgJzl2C1dZgkd4L2Ufya0rq2
	 hFcRQ5QMlaXKPOZn+JVXBqKNgzaSR7Z/pTv4yrnXE8qL4c4qp2yHirh+aRJ4w+KQlA
	 wAIvNQVc8SUBlFXZqY7+5nVZDA8EVXnpvLMQr9lTvHWYrCvFAVXqZwR5eKXnEiO6wF
	 AoZQLhj2bCBrA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1737851065; x=1738111565; i=teddy.astie@vates.tech;
	bh=Fso/TxpSFQtDqap0uHljRirvoodY3kMgWJHR5PV+Qh4=;
	h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=bPJl708d5gdza1MPwftgKD3Z1rf8oNZBlF72lcdnJ6gjn09989ww7IUkLN9NNpzJD
	 w2IJqokIZ7l1Zi0KZlywoKGCElb8tXt6R5i/LHQVPolTZlB0hkWOTb6uWfwkLi0xE3
	 AC26Cd6ykyT2no7mtlSD4dsaUUndHQJENUtN0qE49FE2Wlm7AWjN1lrPjUAsFxkccz
	 g3iqjj7OV75eIVd30/SwM7IziaJOAT4oScb1++1rjRh5e9mAnXqYZmpLa5O3XC/We4
	 wMIJZ3E7ITOiLITxA5/igRGvihmOwas3ZedVXX2q0UctT2npyolYoVKE8LcUdGikJB
	 Jq22H8/IgDUjw==
From: "Teddy Astie" <teddy.astie@vates.tech>
Subject: =?utf-8?Q?Re:=20Serious=20AMD-Vi=20issue?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1737851063932
Message-Id: <79ebd460-8e05-4c54-a553-78149b1b751a@vates.tech>
To: "Elliott Mitchell" <ehem+xen@m5p.com>, "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>
Cc: xen-devel@lists.xenproject.org, "Jan Beulich" <jbeulich@suse.com>, "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <ZbLDlRi0vctlhsNp@mattapan.m5p.com> <Z5OkQgjd4Lt_rtr0@macbook.local> <Z5QFf5Ipk3GHd27H@mattapan.m5p.com>
In-Reply-To: <Z5QFf5Ipk3GHd27H@mattapan.m5p.com>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.4ae9820069564f3f88597e3d4791d2d6?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250126:md
Date: Sun, 26 Jan 2025 00:24:25 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hello Elliott,

Le 24/01/2025 =C3=A0 22:31, Elliott Mitchell a =C3=A9crit=C2=A0:
> On Fri, Jan 24, 2025 at 03:31:30PM +0100, Roger Pau Monn=C3=A9 wrote:
>> On Thu, Jan 25, 2024 at 12:24:53PM -0800, Elliott Mitchell wrote:
>>> Apparently this was first noticed with 4.14, but more recently I've bee=
n
>>> able to reproduce the issue:
>>>
>>> https://bugs.debian.org/988477
>>>
>>> The original observation features MD-RAID1 using a pair of Samsung
>>> SATA-attached flash devices.  The main line shows up in `xl dmesg`:
>>>
>>> (XEN) AMD-Vi: IO_PAGE_FAULT: DDDD:bb:dd.f d0 addr ffffff???????000 flag=
s 0x8 I
>>
>> I think I've figured out the cause for those faults, and posted a fix
>> here:
>>
>> https://lore.kernel.org/xen-devel/20250124120112.56678-1-roger.pau@citri=
x.com/
>>
>> Fix is patch 5/5, but you likely want to take them all to avoid
>> context conflicts.
> 
> I haven't tested yet, but some analysis from looking at the series.

> 
> This seems a plausible explanation for the interrupt IOMMU messages.  As
> such I think there is a good chance the reported messages will disappear.
> 
> Nothing in here looks plausible for solving the real problem, that of
> RAID1 mirrors diverging (almost certainly getting zeroes during DMA, but
> there is a chance stale data is being read).
> 

The message is showing shows that something is going wrong, presumably a 
lost interrupt. This can lead to data loss, as it breaks the 
expectations of the Dom0's drivers.

If you still observe data loss after these patches, and these messages 
have disappeared, it may be due to something else, but these patches are 
not looking to hide the fault.

According to AMD-Vi specification, there appears to be a specific case 
where interrupt remapping faults are reported as IO_PAGE_FAULT (which 
appears to be what's happening).

IG bit (133) of DTE appears to provide an explanation (SupIOPF can set 
this behavior globally).

 > IG: ignore unmapped interrupts. 1=3DSuppress event logging for interrupt
 > messages causing IO_PAGE_FAULT events. 0=3Dcreation of event log entries
 > for IO_PAGE_FAULT events is controlled by SupIOPF in the interrupt
 > remapping table entry (see Section 2.2.5 [Interrupt Remapping
 > Tables]).

Note that Xen (and this patch doesn't change this behavior) does set 
this bit to 0, which means that faults are reported as IO_PAGE_FAULT events=
.

> Worse, since it removes the observed messages, the next person will
> almost certainly have severe data loss by the time they realize there is
> a problem.  Notably those messages lead me to Debian #988477, so I was
> able to take action before things got too bad.
> 
> 
> 
> I'm not absolutely certain this is a pure Xen bug.  There is a
> possibility the RAID1 driver is reusing DMA buffers in a fashion which
> violates the DMA interface.  Yet there is also a good chance Xen isn't
> implementing its layer properly either.
> 
> 
> 
> There is one pattern emerging at this point.  Samsung hardware is badly
> effected, other vendors are either uneffected or mildly effected.
> Notably the estimated age of the devices meant to be handed off to
> someone able to diagnose the issue is >10 years.  The uneffected
> Crucial/Micron SATA device *should* drastically outperform these, yet
> instead it is uneffected.  The Crucial/Micron NVMe is very mildly
> effected, yet should be more than an order of magnitude faster.
> 
> The simplest explanation is the flash controller on the Samsung devices
> is lower latency than the one used by Micron.
> 
> 
> Both present reproductions feature AMD processors and ASUS motherboards.
> I'm doubtful of this being an ASUS issue.  This seems more likely a case
> of people who use RAID with flash tending to go with a motherboard vendor
> who reliably support ECC on all their motherboards.
> 
> I don't know whether this is confined to AMD processors, or not.  The
> small number of reproductions suggests few people are doing RAID with
> flash storage.  In which case no one may have tried RAID1 with flash on
> Intel processors.  On Intel hardware the referenced message would be
> absent and people might think their problem was distinct from Debian
> #988477.
> 
> In fact what seems a likely reproduction on Intel hardware is the Intel
> sound card issue.  I notice that issue occurs when sound *starts*
> playing.  When a sound device starts, its buffers would be empty and the
> first DMA request would be turned around with minimal latency.  In such
> case this matches the Samsung SATA devices handling DMA with low
> latency.
> 
> 
>> Can you give it a try and see if it fixes the fault messages, plus
>> your issues with the disk devices?
> 
> Ick.  I was hoping to avoid reinstalling the known problematic devices
> and simply send them to someone better setup for analyzing x86 problems.
> 
> Looking at the series, it seems likely to remove the fault messages and
> turn this into silent data loss.  I doubt any AMD processors have an
> IOMMU, yet omit cmpxchg16b (older system lacked full IOMMU, yet did have
> cmpxchg16b, newer system has both).  Even guests have cmpxchg16b
> available.
> 
> If you really want this tested, it will be a while before the next
> potential downtime window.
> 
> Come to think of it, I wonder whether this might fix a particular device
> which was having an interrupt problem.  Problem there being it was being
> uncooperative with motherboard firmware...
> 
> 

As it seems to be a specific corner case, I would not be surprised that 
it only shows up in very specific hardware setups.

Teddy


Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech



From xen-devel-bounces@lists.xenproject.org Sun Jan 26 03:58:45 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Jan 2025 03:58:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877145.1287310 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbtn4-0008P2-HY; Sun, 26 Jan 2025 03:58:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877145.1287310; Sun, 26 Jan 2025 03:58:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbtn4-0008Ov-ED; Sun, 26 Jan 2025 03:58:30 +0000
Received: by outflank-mailman (input) for mailman id 877145;
 Sun, 26 Jan 2025 03:58:29 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=b7wu=US=alien8.de=bp@srs-se1.protection.inumbo.net>)
 id 1tbtn3-0008Op-1k
 for xen-devel@lists.xenproject.org; Sun, 26 Jan 2025 03:58:29 +0000
Received: from mail.alien8.de (mail.alien8.de [65.109.113.108])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id cb8d46b0-db99-11ef-99a4-01e77a169b0f;
 Sun, 26 Jan 2025 04:58:26 +0100 (CET)
Received: from localhost (localhost.localdomain [127.0.0.1])
 by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id 5E28F40E01B5; 
 Sun, 26 Jan 2025 03:58:25 +0000 (UTC)
Received: from mail.alien8.de ([127.0.0.1])
 by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id y75T0S7EQHDo; Sun, 26 Jan 2025 03:58:22 +0000 (UTC)
Received: from [127.0.0.1] (unknown [80.149.170.8])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256)
 (No client certificate requested)
 by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 3ED3440E0184;
 Sun, 26 Jan 2025 03:58:10 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: cb8d46b0-db99-11ef-99a4-01e77a169b0f
X-Virus-Scanned: Debian amavisd-new at mail.alien8.de
Authentication-Results: mail.alien8.de (amavisd-new); dkim=pass (4096-bit key)
	header.d=alien8.de
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8;
	t=1737863902; bh=woGi95NGqawPIGfJu5X+xepXMktzRhoBJFKUJXaLcng=;
	h=Date:From:To:CC:Subject:In-Reply-To:References:From;
	b=ISHqoIknkR9Zd/YmmJz0vN7TkQMQC9P030806gdBTm3VQnzKcptv6QTpNBSkASYKC
	 ZN468UNcsR35mnqBygK1Uuiyqs92GNhv/6CGP6T8YvrZArptVBG9l/pNb664BviboG
	 l3eAP07Jq/HQBoY2T0Zfi864B8jx17LwG3lHubtKiKBL6pih7ufFuC0sRC4BdX+PWc
	 NwE62JCg4djbuOjrIrqa2YalnxjwCDRQquPSgPpMEHyTE8rW+gfY2fmrldfyYSSIRF
	 jSBk90L2UHXmdY/8e2/u+puU6gygXj2H74a/vrThicalaBbU+gvcBWBwKXmgMxQGY2
	 AHOPXUSWW9zgSRi/DLFiGFUjzGmTDSQ4iYEzO0BVm8RX60kqpHI7ISJ7tVFFXNEFhA
	 S7z4VQ0+jhNC8WuWrmgw3ukRvJ3FgUihvLkFoLNT3+HToJpr3fPuTVZzfAtv1EClqA
	 Tem1ipCZbdSw9mz5HjrffxI9zjmD2G70sX/RsWznnP88BWf4KGYhjcJNX8mNSnZQOC
	 bWeXhqNB7R45y+7Dseq85yi1qiUODYV4QutPpdZBzBSuaRG6a4IJBH1PgsoOefXYjh
	 Wel5Vb1m1lVDqx+H2N1Ie3bel0IXQPAPqD6wCNclxd++olu8lRMNpDa15VZzJDFCg1
	 9Y/kjXp6K5PDg9h4lmNhKOF8=
Date: Sun, 26 Jan 2025 04:57:22 +0100
From: Borislav Petkov <bp@alien8.de>
To: Brian Gerst <brgerst@gmail.com>
CC: linux-kernel@vger.kernel.org, x86@kernel.org, Ingo Molnar <mingo@kernel.org>,
 "H . Peter Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de>,
 Ard Biesheuvel <ardb@kernel.org>, Uros Bizjak <ubizjak@gmail.com>,
 Juergen Gross <jgross@suse.com>, xen-devel@lists.xenproject.org
Subject: =?US-ASCII?Q?Re=3A_=5BPATCH_v6_04/15=5D_x86/pvh=3A_Use_fi?=
 =?US-ASCII?Q?xed=5Fpercpu=5Fdata_for_early_boot_GSBASE?=
User-Agent: K-9 Mail for Android
In-Reply-To: <CAMzpN2jqOb1jC6ZYxa+1Xw-EXuDXUrGT9_7Gv0FL+XJxTXvC5g@mail.gmail.com>
References: <20250123190747.745588-1-brgerst@gmail.com> <20250123190747.745588-5-brgerst@gmail.com> <20250125150658.GAZ5T-EloWfjZAwJdU@renoirsky.local> <CAMzpN2jqOb1jC6ZYxa+1Xw-EXuDXUrGT9_7Gv0FL+XJxTXvC5g@mail.gmail.com>
Message-ID: <85E9A42F-EB78-4F82-9099-B01A18CA16D2@alien8.de>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

On January 25, 2025 5:51:29 PM GMT+01:00, Brian Gerst <brgerst@gmail=2Ecom>=
 wrote:
>To be fair, this was a copy of an existing comment=2E  Is there a style
>guide where all these grammar rules are documented, so I don't have to
>keep resending these patches for trivial typos?

You don't have to keep resending them for trivial typos - you simply wait =
1-2 weeks to gather review feedback, you incorporate it and send a new vers=
ion of the set=2E Like it is usually done on lkml=2E I think you know how t=
he process works=2E=2E=2E


--=20
Sent from a small device: formatting sucks and brevity is inevitable=2E 


From xen-devel-bounces@lists.xenproject.org Sun Jan 26 06:18:44 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Jan 2025 06:18:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877155.1287321 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbvyY-0000DY-Vf; Sun, 26 Jan 2025 06:18:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877155.1287321; Sun, 26 Jan 2025 06:18:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbvyY-0000DR-RY; Sun, 26 Jan 2025 06:18:30 +0000
Received: by outflank-mailman (input) for mailman id 877155;
 Sun, 26 Jan 2025 06:18:29 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=L+Qa=US=amd.com=penny.zheng@srs-se1.protection.inumbo.net>)
 id 1tbvyX-0000CZ-00
 for xen-devel@lists.xenproject.org; Sun, 26 Jan 2025 06:18:29 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on2062c.outbound.protection.outlook.com
 [2a01:111:f403:2417::62c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 58d73b64-dbad-11ef-99a4-01e77a169b0f;
 Sun, 26 Jan 2025 07:18:25 +0100 (CET)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 SA1PR12MB7125.namprd12.prod.outlook.com (2603:10b6:806:29f::14) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.18; Sun, 26 Jan
 2025 06:18:20 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%3]) with mapi id 15.20.8377.009; Sun, 26 Jan 2025
 06:18:20 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 58d73b64-dbad-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Ai9BI/dq70dYxwXnRpnoJLz1t4alxFlhi/8kOU/pCTuXeT1DJeK7QyLA+E82O8YVJ+OaYFvVBpCodg3RyQOVkrHBPWE9b6TXh/Yc/MnPb9dWFtgBJ8VAPKyzhQ7CVvtmWmaUUmMlXmo/yg2E5GzTp/LjU3aLUktkzso+bI82trNCjljzfnOckc2+3PzjnNx/P6rWxkp9CwwJ5xXZ1/9JT/Jn6SChyNlfS+x4ntGguSm1VnRKbnYOfjn/Hhl3XRbD6L83Jsw1opjB3Wud3q1FZZ/PfnhV92UAFsGa+H7qjQLMkLoVNy30bXEhRtDpn/CNCbicOFluE/ybZKnjSumynQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=SMI2dI7n/rB8+PxcfxXFwCj59zzPoInHpIQu34CHdYE=;
 b=ZoEaPClvcCNrq5r0UOrWmNqRV+wyz26jazXydkc5QDu1xvuaY37GrI3lV6NQrW+iME322sxTqG8MFEuYQsaQzoMhjM+/v/KhDMwACD5n7KkAvL7i9xtupXLDPCDLtCR7AYQs1genAMRB36dmlH3Ok4ogdXWxHsuTK4j3EWcooNPXsq6imze+MIqlUdr2lXQe/DRTCc+UxWjyuViXSCGoIB7YuloIAYNiFplx97pIZXkKibkBc9uJufFcXAqMDRf0Kjg5eED7ld7zqlVtOaJ/1Sli9zb0YvRBTwkWIYtzK32yZKwlPDD/0HzqqnPVcI1WU0EJS1KY1rHtiEyRfnZ5ZA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=SMI2dI7n/rB8+PxcfxXFwCj59zzPoInHpIQu34CHdYE=;
 b=bkUQOJeby27E6y/ACN5tZbkwumLsaRI1gegwqiFr10bxRJSbMwyOXiK3bxDJmMOnWQqohdoV8a6kp4Fzlj9uB+TVznmZv9ma4ABLD/RKNUYHcZYuhTtrTRaAHvH00JY9ZF/GH/Bis3hw9Xic0DTjgcIj9ziNGE3IesVXmH48BZ0=
From: "Penny, Zheng" <penny.zheng@amd.com>
To: Jan Beulich <jbeulich@suse.com>
CC: "Stabellini, Stefano" <stefano.stabellini@amd.com>, "Huang, Ray"
	<Ray.Huang@amd.com>, "Ragiadakou, Xenia" <Xenia.Ragiadakou@amd.com>,
	"Andryuk, Jason" <Jason.Andryuk@amd.com>, Andrew Cooper
	<andrew.cooper3@citrix.com>, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	<roger.pau@citrix.com>, Julien Grall <julien@xen.org>, Stefano Stabellini
	<sstabellini@kernel.org>, "xen-devel@lists.xenproject.org"
	<xen-devel@lists.xenproject.org>
Subject: RE: [PATCH v1 09/11] xen/x86: implement EPP support for the AMD
 processors
Thread-Topic: [PATCH v1 09/11] xen/x86: implement EPP support for the AMD
 processors
Thread-Index: AQHbRVznRa/Bwz7xKUirr7NfworPsbMOizuAgBpVwcA=
Date: Sun, 26 Jan 2025 06:18:20 +0000
Message-ID:
 <DM4PR12MB8451D5C244F3087963CA9FADE1ED2@DM4PR12MB8451.namprd12.prod.outlook.com>
References: <20241203081111.463400-1-Penny.Zheng@amd.com>
 <20241203081111.463400-10-Penny.Zheng@amd.com>
 <3f688a4a-c95b-4852-bc0d-089336a5e6ef@suse.com>
In-Reply-To: <3f688a4a-c95b-4852-bc0d-089336a5e6ef@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_ActionId=764e3bf6-b76a-4c11-81d9-b0c72bde7b73;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_ContentBits=0;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_Enabled=true;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_Method=Standard;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_Name=AMD
 Internal Distribution
 Only;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_SetDate=2025-01-26T05:47:59Z;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DM4PR12MB8451:EE_|SA1PR12MB7125:EE_
x-ms-office365-filtering-correlation-id: 138a5cf0-83ba-4c63-aa04-08dd3dd13ad4
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?UnFTN3owaXJ3cVloczNyL2ZzdEZURUxtbU92aVZTRnJmM2lVVlRibTJwWDhB?=
 =?utf-8?B?YWZhMXVaelZ1UDFGbllXMzY3RUNUaHlOV3FrU3dlU1p3SDdINzFwN1QrMmFC?=
 =?utf-8?B?b0YxRUxwNjRqZTR2ckViakJOdnMyQlUrZnFWUVpGQVlzN3EvWWtPUnN6Ymw4?=
 =?utf-8?B?cFNneGdYeCs5Sjd1Q1hNd3FjZlY4TGNZaThsano3VEp1SUJIZzRRS25SZE5r?=
 =?utf-8?B?b3UreUJ0UTIrR2ZwTkpsbmFESXZPRXl6RkhNNW9DVXo0RXphZENwdlpoV3NM?=
 =?utf-8?B?S0Y0aW41RFVEOU4wVHY3bU5HWUNyRXJFSVdycTJrcjEyOTdERm8yMWFIVzNL?=
 =?utf-8?B?OERDSkpGcG9DUGZpNXRBYzY4Q1N2SU9LUnFvYnNsU0FSTlBXRzNUS1N4YkVm?=
 =?utf-8?B?MHFmZGtVVlVDVjh3WVBXSE5TS2JXdGwvQkEyam5LYlQvSEx5L0VxZnk4Tllu?=
 =?utf-8?B?R1JRTnV6c2JPWTViRnk4eG1WTTk1MWxVdjZTeWJuNzg2REJQOEllOWJhcmJ0?=
 =?utf-8?B?Nm9SNGZuOHEyeEVsaUh5M1lSR0gyQzY3UStSbUx3aEVpWTA3UTljYmdhekM5?=
 =?utf-8?B?OURjWWYyRjJ3VjRvRlJEWUFJRWllelBXT2pwZnNOaVdSUVhVbmIvd202aS9r?=
 =?utf-8?B?bSt0RFEwWkZiUFNxK2R2OWVER2txM0NhdkYvVGhuSGFMVG9HTzViZkZNREVo?=
 =?utf-8?B?MG93RnhPakg4MjlZTUs1UE1zUHY5QnZkeU1OQXR4RGZPa3hvMnJJdlkya3dC?=
 =?utf-8?B?UFRWZGg4bGE2eWtRMmRBUUpkNjJMQzB0SG1icGl1aXhCUDBzdEd2MEZ1czQx?=
 =?utf-8?B?Q2xVaFBHRnhRVGo0c0Y5ZmZ3K3EwY3ZkWEhONThrK2xZOFN0UGRHcTcvd09a?=
 =?utf-8?B?R1hkLzJMRnBveGw0a0V5cnhTVUsrNGpTVVIxamQrbDFmSGVTaWJmdU0xcFpV?=
 =?utf-8?B?TzZ6R2RiUUF2MGhEcFVDU29ISDVPaFRoTzNpTmwzOUNjcE5lWElZL1h1SXlo?=
 =?utf-8?B?RnBWdmJTVW1WTlRDOVRvdUdKUHc4dW9XQ1k3Y1JwcUNxZGhFWDUwV0NvU3Vh?=
 =?utf-8?B?T0ZJWXNHYTBObFJsZjBXazJ1NW15cUZzcjM3aCtMRlc0ejhPVkwzYW9pMVBS?=
 =?utf-8?B?a1ZLSTVUYm4yM3lEK0RuRUxObHpEaHRPTmZzckc4dDZ0N0lQSDJFb1pJb1Bp?=
 =?utf-8?B?azRzcjdjbU1kOVA5MUMvRWtuRmowRU10eGVCNGNvWjFPOXhiVmI0TVdmcWwy?=
 =?utf-8?B?TW9EUWZpMXo2ZmlKZUd6cnlvdG1rM1NIa09sMmxsWVF2YXN2dkU3TFlYblN1?=
 =?utf-8?B?QnpwWFF0YzBFR1Y5WE1teVFMRC8yczE2d0R0c0RBdXcyNXRjcXBKVUdkQ092?=
 =?utf-8?B?WUs3cTZOd3FJcmNhZ1hwcVdpcVhNNmd3V0FyQXMrK3A3cVNOQmhwdDAvWWlK?=
 =?utf-8?B?VGo0OU9NTXJCWlBsVk4yUkdHb3BzUjB5NEU5YmVWSmVHSTh1OVZXVlM0OTkw?=
 =?utf-8?B?dG5CUWlQc3c2d1QxdTVzYUkxLzM1dXUyM0ptcEVxSFRDTURySWM5M0RQVEhE?=
 =?utf-8?B?eFF2eCs0WDVTSzRSNEFJZkZjVUZISW01QS9KTTNHOHk0WC9lNGdSZXdVWWNU?=
 =?utf-8?B?RjIzOWczVGsxRVV2SVB6dEt4RWlHbVpYN01LeHFEZVJHUlBNc2ozUEEwN04v?=
 =?utf-8?B?bkNZZE1LSkZMcU42KzZEVHhMd2VTTzE2UC9oME00Y0lxMGk5aDQ3NlhIZDZ1?=
 =?utf-8?B?cmw3enFCQll0YjVwdm5Uc2hpY0VpdWkwYlFWMnJyc3BHRm16OXVtVVRtcG52?=
 =?utf-8?B?cE1RbHplV24rS1BzQ0JtSldYL1dVbU9UL1pCQXNPdjZtVEUwTXBpYzBaM1lJ?=
 =?utf-8?B?aitscy9IYTY1d29GY1JNUjRaVGtoZzJwZlhWL0FkK2pTWWZ2YjdTTzFWVERG?=
 =?utf-8?Q?66l8QLmyR4fY6InwMgXohBJ6YVXEP/fX?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB8451.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?Q3NtQjFXM3hnekYvWDRobk5KU3dWN281M3dlQkJmaldxRm56eU1PYWs5M2cz?=
 =?utf-8?B?L0FPdTJTblZnKzlkZmpOUG1mUzVjdmZBR1JHcytoSVBZbHovb2RNYmpmbVdY?=
 =?utf-8?B?YlMwT1pHeU5XWm1HOEpuSytkcWJqb04vZVRaL2ZpMGhuSXplRjNCcWZ6eThY?=
 =?utf-8?B?eGtCRHJLVnp3bElIUDhxV2RHeDhleUU5dGFLNWNyWVlIcldwT2R1L1NaYW1l?=
 =?utf-8?B?M1gzUjJRNXBLbmxVNk5KbnYvazNCOVlGVzYybCtkb0ZDOVVmWXRvUDAyU3ow?=
 =?utf-8?B?dDFJS0F1dWVUTTRPTjk0dE9mcHhhYjV4R3RERkZ1cTlyR3AvaUR6YXpRRC9u?=
 =?utf-8?B?bndYcjBiWjF4cDRTZ0dWZWpmREZMNWtidG5LRDhOakRxZkVBMlBhQURYd3Nn?=
 =?utf-8?B?aFJTbWpGYVlQZ3M5Lzk0cDhvOFJweTFzdy9XQ3ZyY09qamZPK3YzbTFuL2x4?=
 =?utf-8?B?dktlMDhOb2cyZWl6d1l0L24yZ3VUdVVhNGZ5Sm0rMFBwQUkrRGdnTFhYQit4?=
 =?utf-8?B?TjVwT0x6VnppWllJMkFFdkp5U1RNSUFQZ3FwTFJJMnJQTnBNWTJDbmFwRzVl?=
 =?utf-8?B?cUk4WlVTRFRYSHBSWC9oQmhXNk1yNGo2L05YdjY3aGt0eTRhMkl6Q0ZyN0E3?=
 =?utf-8?B?bDlrQXAyOFI4NGpWRW5qQmU0YTFiNjVzbkNzNGtUQXdGKzdCdTZld2NaRzdp?=
 =?utf-8?B?NzU4L2VZaVAwSDdncTNsejgxT0ZRa1BsSVFDOTAza0xmSnlFTDlNV0RTVGc1?=
 =?utf-8?B?NWRNYy9KRjlDYXVacy9Xamcra2dwVTZnZ0c0bVB3SkJLcjAxY2tSSXpoUmkx?=
 =?utf-8?B?TE96VXA2R3lBU0VSNnFpQk9VbXlpMkpkYms3UTlTVFdxNkVwODFmd0RtWFFi?=
 =?utf-8?B?RGRYK0VzbzlRY1NiN0g3U0NIZEpuN1FCMkNMZVlzUzI5dlp2NjFMeUhCRDc4?=
 =?utf-8?B?eE5udlJVaG1sbHc1UUVyQy80SFlva1Rjbm5heWtSZ2VoVlVsV1VYSStZanpK?=
 =?utf-8?B?bGtLUHFNQmRTWkdtajI5amFRVndnbmx0MUVYL1VMSExWOWlqQTdCK2FWMTBR?=
 =?utf-8?B?RXc1WkJUMmhpSHpEc2FsUWF4VE5zUVhkMzh1eUlqNHRheG04YitKK2tqclRX?=
 =?utf-8?B?VUJrU3NDZCtLMThGOGJoNHNBZXNrYTlwaDc5eWZHbVVzTXI5NnhZWGF1M2dK?=
 =?utf-8?B?SFJza1IxbzVOMGhRNXhwQ3ZWbGZlY3RlUGRqZUJGQTJmNlcvRXgwU2FlYmpM?=
 =?utf-8?B?YUhJcTJJeHpsenUyMjhXWGoyZm90WnBseWdOa2VLS0FyN25hZ3pLVjIvQm42?=
 =?utf-8?B?cEF3SVNoVElZMFhwTzRBR0l6Y2R1bVloVkE5UzNGWkpUcGwzK0FWTkRCdUNj?=
 =?utf-8?B?OS9IMHBRSW9ucndQejJQY3BsR3ZPSU5WY2JtUFpad3RrZXhOUVFRVWZaTTha?=
 =?utf-8?B?Zyt6Slp6aXhrT3VFNE1QVlEvbkFDOGxFNXpFZmxUelAxcC9INDJ2djRnT2ZD?=
 =?utf-8?B?NGQvUzZmS3Yrd08zVUZRZE04N1ZyVXU3dFRaMDA3L3FzUW1ES05ubTRlNXZY?=
 =?utf-8?B?MlUrb0E5bVpQcmJjcVhQMEhvZ2RVY3phUVRRWHJBL3pkaVBCNzN3TVMvUGRJ?=
 =?utf-8?B?bTErQklHNGhNNm1LUm5Wa2h2cWxaNXVCN0Fyc0lueVNQdTNZZ2dralU5Qi9X?=
 =?utf-8?B?OWcwblpJd2xwU0hvTDU2SmVnZmxBYkNvb2xNK3FBOVhGWEIrK3d5eUh3aTZT?=
 =?utf-8?B?c2k3a3FsOXlIdzNsVHBldnBkUGxFMzJXUHZSdDEwSlczcWhncS9VSVRudW40?=
 =?utf-8?B?YW5MZTlvZVp3Z1VUSnhkK1VGbmk0TmtkU3Vtb3N6SjhYbkMxYmtRSVUwQ0pz?=
 =?utf-8?B?dXVOZ05RbkY2YmljS1FjOGdkcWt5WmVaQm1VZXpsbU5lN3ZrNkFhUlp5V1Jz?=
 =?utf-8?B?SmZ2OGhEWlRoR0ZFVUhHSmNxS1h1TnJMbFQ1UFNqY3VESmU4bkRPN1pDa0JV?=
 =?utf-8?B?UnpDR1AyajdXcXRZanFzNnJnVzZpS0hWT1NOVDdNV0FPZ2FjQUE2TUc2a1da?=
 =?utf-8?B?bnkwSzE1eGNXNWJUVitLYzZPYTFwakdEQ1BTbW9kM2ZLTFFJOXVLclZmVlIr?=
 =?utf-8?Q?pi0s=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB8451.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 138a5cf0-83ba-4c63-aa04-08dd3dd13ad4
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jan 2025 06:18:20.0513
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: lUgJUs+T6UlA9kLkssmt9pwdXVigd9ahb8a/ySfhSbYT8lxBPllVUKirI40KzKpJ3oaHYU1pxLbPD437yr22/Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB7125

W0FNRCBPZmZpY2lhbCBVc2UgT25seSAtIEFNRCBJbnRlcm5hbCBEaXN0cmlidXRpb24gT25seV0N
Cg0KSGksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSmFuIEJldWxp
Y2ggPGpiZXVsaWNoQHN1c2UuY29tPg0KPiBTZW50OiBUaHVyc2RheSwgSmFudWFyeSA5LCAyMDI1
IDc6MzggUE0NCj4gVG86IFBlbm55LCBaaGVuZyA8cGVubnkuemhlbmdAYW1kLmNvbT4NCj4gQ2M6
IFN0YWJlbGxpbmksIFN0ZWZhbm8gPHN0ZWZhbm8uc3RhYmVsbGluaUBhbWQuY29tPjsgSHVhbmcs
IFJheQ0KPiA8UmF5Lkh1YW5nQGFtZC5jb20+OyBSYWdpYWRha291LCBYZW5pYSA8WGVuaWEuUmFn
aWFkYWtvdUBhbWQuY29tPjsNCj4gQW5kcnl1aywgSmFzb24gPEphc29uLkFuZHJ5dWtAYW1kLmNv
bT47IEFuZHJldyBDb29wZXINCj4gPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+OyBSb2dlciBQ
YXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT47IEp1bGllbg0KPiBHcmFsbCA8anVsaWVu
QHhlbi5vcmc+OyBTdGVmYW5vIFN0YWJlbGxpbmkgPHNzdGFiZWxsaW5pQGtlcm5lbC5vcmc+OyB4
ZW4tDQo+IGRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0gg
djEgMDkvMTFdIHhlbi94ODY6IGltcGxlbWVudCBFUFAgc3VwcG9ydCBmb3IgdGhlIEFNRA0KPiBw
cm9jZXNzb3JzDQo+DQo+IE9uIDAzLjEyLjIwMjQgMDk6MTEsIFBlbm55IFpoZW5nIHdyb3RlOg0K
PiA+ICsNCj4gPiArICAgIC8qIEluaXRpYWwgbWluL21heCB2YWx1ZXMgZm9yIENQUEMgUGVyZm9y
bWFuY2UgQ29udHJvbHMgUmVnaXN0ZXIgKi8NCj4gPiArICAgIG1heF9wZXJmID0gZGF0YS0+aHcu
aGlnaGVzdF9wZXJmOw0KPiA+ICsgICAgbWluX3BlcmYgPSBkYXRhLT5ody5sb3dlc3RfcGVyZjsN
Cj4gPiArDQo+ID4gKyAgICBpZiAoIGRhdGEtPnBvbGljeSA9PSBDUFVGUkVRX1BPTElDWV9QRVJG
T1JNQU5DRSApDQo+ID4gKyAgICAgICAgbWluX3BlcmYgPSBtYXhfcGVyZjsNCj4NCj4gV2h5IGNh
bid0IHRoaXMgYmUgZG9uZSAuLi4NCj4NCj4gPiArICAgIC8qIENQUEMgRVBQIGZlYXR1cmUgcmVx
dWlyZSB0byBzZXQgemVybyB0byB0aGUgZGVzaXJlIHBlcmYgYml0ICovDQo+ID4gKyAgICBkZXNf
cGVyZiA9IDA7DQo+ID4gKw0KPiA+ICsgICAgaWYgKCBkYXRhLT5wb2xpY3kgPT0gQ1BVRlJFUV9Q
T0xJQ1lfUEVSRk9STUFOQ0UgKQ0KPiA+ICsgICAgICAgIC8qIEZvcmNlIHRoZSBlcHAgdmFsdWUg
dG8gYmUgemVybyBmb3IgcGVyZm9ybWFuY2UgcG9saWN5ICovDQo+ID4gKyAgICAgICAgZXBwID0g
Q1BQQ19FTkVSR1lfUEVSRl9NQVhfUEVSRk9STUFOQ0U7DQo+DQo+IC4uLiBoZXJlIGFzIHdlbGw/
IEFuZCB3aHkgaXMgdGhlcmUgbm90aGluZyByZXNwZWN0aXZlIGZvciAuLi4NCg0KQWNrDQoNCj4N
Cj4gPiArICAgIGVsc2UgaWYgKCBkYXRhLT5wb2xpY3kgPT0gQ1BVRlJFUV9QT0xJQ1lfUE9XRVJT
QVZFICkNCj4gPiArICAgICAgICAvKiBGb3JjZSB0aGUgZXBwIHZhbHVlIHRvIGJlIDB4ZmYgZm9y
IHBvd2Vyc2F2ZSBwb2xpY3kgKi8NCj4gPiArICAgICAgICBlcHAgPSBDUFBDX0VORVJHWV9QRVJG
X01BWF9QT1dFUlNBVkU7DQo+DQo+IC4uLiB0aGlzIGNhc2UgKGUuZy4gc2V0dGluZyBtYXhfcGVy
ZiBmcm9tIG1pbl9wZXJmKT8NCg0KSWYgd2UgcHV0IG1heF9wZXJmID0gbWluX3BlcmYgPSBsb3dl
c3RfcGVyZi9sb3dlc3Rfbm9ubGluZWFyX3BlcmYsIHRoZW4NCndlIGFyZSBwdXR0aW5nIGNvcmUg
aW4gaWRsZSBzdGF0ZS4gVGhhdCdzIGhvdyB3ZSBvZmZsaW5lIHRoZSBjcHUgY29yZSBpbiBMaW51
eA0KYW1kIHBzdGF0ZSBlcHAgZHJpdmVyLCBzZWUgaHR0cHM6Ly9naXQua2VybmVsLm9yZy9wdWIv
c2NtL2xpbnV4L2tlcm5lbC9naXQvdG9ydmFsZHMvbGludXguZ2l0L3RyZWUvZHJpdmVycy9jcHVm
cmVxL2FtZC1wc3RhdGUuYz9oPXY2LjEzI24xNjQzDQoNCj4NCj4gSmFuDQoNCk1hbnkgdGhhbmtz
LA0KUGVubnkNCg==


From xen-devel-bounces@lists.xenproject.org Sun Jan 26 06:31:35 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Jan 2025 06:31:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877166.1287329 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbwB9-00033T-4n; Sun, 26 Jan 2025 06:31:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877166.1287329; Sun, 26 Jan 2025 06:31:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tbwB9-00033M-2B; Sun, 26 Jan 2025 06:31:31 +0000
Received: by outflank-mailman (input) for mailman id 877166;
 Sun, 26 Jan 2025 06:31: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
 <SRS0=L+Qa=US=amd.com=penny.zheng@srs-se1.protection.inumbo.net>)
 id 1tbwB7-00033G-TS
 for xen-devel@lists.xenproject.org; Sun, 26 Jan 2025 06:31:30 +0000
Received: from NAM02-DM3-obe.outbound.protection.outlook.com
 (mail-dm3nam02on20628.outbound.protection.outlook.com
 [2a01:111:f403:2405::628])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2c49edea-dbaf-11ef-a0e6-8be0dac302b0;
 Sun, 26 Jan 2025 07:31:28 +0100 (CET)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 PH7PR12MB9175.namprd12.prod.outlook.com (2603:10b6:510:2e6::14) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.21; Sun, 26 Jan
 2025 06:31:23 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%3]) with mapi id 15.20.8377.009; Sun, 26 Jan 2025
 06:31:22 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2c49edea-dbaf-11ef-a0e6-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=PcyxGe7qE89Lw1fwpUB5RFSdzrW1CKnUuyvi/PeSlFyvLkSylx/CWrJARF4cs78hpdUQyLJbidxEM4b7JvIYix0PYwAo6tUMIycGbKClxUWEQTteai0nZ6c2B8HHrwuSmVmMhLypWRGaYGSwoQQu1PV1/1OoyoZ19nCBBMDJfNHmuHh1fJPHkoAtdCpn4WOH+4398c7RntPddhDLr1ohS94C9I2Oq+jPMl+tkZGpl8IhYh8aw/9n1K/tCAaYdVm3r2D9+WeKCZ6jk8RxH0j7ypKLqBrdsUtNy+qVxDvtLg4nG+9rHWQ7VEIxAKCjRQFKeUO2P4emBNfNe9cfkx+NjA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=V95NOD/e1Nfta/zORbzw8yrPcqp45Uf6O2pBW0TPYEs=;
 b=Y/Ddvh1xwF798SLeFILNq8QkaJSkhvXKjrw0/qG9VPbc6K6XPQ9jnpNsNXEj4ClBp2rcYhZArPGqSzY82FFNxv1h8lt80Q7yINSYDyaOV+DmmTm9VOzV/O1hfHvLteF2kLXTeapMuJCEv0laGnMGjs+GAJLT+HvnmRCBlTHj9tRZZjQpOWCfks7jZXiz1dvIpQW90E8qyhQGNIn9vWGBSU+a3R4foYWmffb7azBY2Ah93lnhBxqbbi7yf0XDkYafWc5gofo7aANBqMrASYBLBW3A9+ksbU0eeY7z7Z9VZZICLQzQdyAjC6ZzfavRwrrTmLo52FvlJ5d+Q2RGg4E8Ew==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=V95NOD/e1Nfta/zORbzw8yrPcqp45Uf6O2pBW0TPYEs=;
 b=gvfphmcAHv9G1Xt+iljlT7r/c8G4vSEXTmG1eaSPgOWBNYD175I6LPWkyYH7y/fhES4BuB0c5zaqmsolWRvqruplTbnEf/l+TlR2dhFR7AdeH5M6NB/O7VPkxy+glFWn72VgOs63DPmdHQipYLI9G5E5whxBdWVt+RjuJZN+Zi0=
From: "Penny, Zheng" <penny.zheng@amd.com>
To: Jan Beulich <jbeulich@suse.com>
CC: "Stabellini, Stefano" <stefano.stabellini@amd.com>, "Huang, Ray"
	<Ray.Huang@amd.com>, "Ragiadakou, Xenia" <Xenia.Ragiadakou@amd.com>,
	"Andryuk, Jason" <Jason.Andryuk@amd.com>, Andrew Cooper
	<andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, Stefano
 Stabellini <sstabellini@kernel.org>, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	<roger.pau@citrix.com>, "xen-devel@lists.xenproject.org"
	<xen-devel@lists.xenproject.org>
Subject: RE: [PATCH v1 08/11] x86/cpufreq: add "cpufreq=amd-pstate,active"
 para
Thread-Topic: [PATCH v1 08/11] x86/cpufreq: add "cpufreq=amd-pstate,active"
 para
Thread-Index: AQHbRVygzo/tK+M4KUarRbqVB0cwPLMOhysAgBpiznA=
Date: Sun, 26 Jan 2025 06:31:22 +0000
Message-ID:
 <DM4PR12MB8451F12422667E90EFD54113E1ED2@DM4PR12MB8451.namprd12.prod.outlook.com>
References: <20241203081111.463400-1-Penny.Zheng@amd.com>
 <20241203081111.463400-9-Penny.Zheng@amd.com>
 <541ed82a-6cf3-4964-9421-23905b777f9c@suse.com>
In-Reply-To: <541ed82a-6cf3-4964-9421-23905b777f9c@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_ActionId=12b1e095-db75-495f-88c8-b42dfce5c969;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_ContentBits=0;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_Enabled=true;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_Method=Standard;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_Name=AMD
 Internal Distribution
 Only;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_SetDate=2025-01-26T06:20:09Z;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DM4PR12MB8451:EE_|PH7PR12MB9175:EE_
x-ms-office365-filtering-correlation-id: 735e272f-e7f2-412c-ebb6-08dd3dd30d65
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?MEJET2ZNamY3R05wN0JhRlFMYjdoM1ZjWG96R3FFOGhnUnJpTlhJSnRaMzly?=
 =?utf-8?B?WFpqaHVDNTRlL21xb2FyeTQ4VjB1RFpicjk5SmZQd2lsR05tTzhCZTRaSUw4?=
 =?utf-8?B?eENvcXU5Z0ZGZ1pMWEZUWWd2VnZ3SE8rNjVsVGtlUjBTR2hQT0sxbW9yVHhI?=
 =?utf-8?B?OWxEU3Vvc0F1amxiOWs2OHpUM1cvNWxJdzZrV0pBbzRGRVN3aHA4a1pXdG1F?=
 =?utf-8?B?bFUwVGFNRStPUDhiZ3hLRDdUS0tqdU1sV3N5SUdGTzBqY2JrdTdXaW1DcmRY?=
 =?utf-8?B?dFBqeDZ5ZGpJdXJka1Q4Ym5HNitIRHVJa3EyRHRxVm9PWTk2M25udmFIQXFx?=
 =?utf-8?B?dGJJZDRYWGozVUptSEt3RFM0bC9JMS9URTV0RjA0V0YvYkFIaHBPcWo1RnZ5?=
 =?utf-8?B?dkJIaWd1OXhFRTdrTzZxaVJtWXF6VG94djhCK25qbnpCVHFmWGJ5S3BicnBO?=
 =?utf-8?B?dkZnc2p5di9ZMXFneENZZS96OVBEaWo0WU5qTzd3ZHFxREVmbGdPOVNWVTRQ?=
 =?utf-8?B?RU8yNnZsUTVUYnJPYVVBcXpDQU1aU1U2aFZOQld1U1ZqWFU4UExxR2ZNWkNo?=
 =?utf-8?B?bDQweW52UjJEcUhWU3puM1ZXbnJ2eWVWcWo3N0YxSVFVWU9hTUFGVzJYRURK?=
 =?utf-8?B?eFhVKzNTeVd0Vm1ISG5PQkUxR1o4MDhTemhaMFBGd3kyaEkwckI1WEFGWEFq?=
 =?utf-8?B?dHNSMkVxZXBnYm5QK1dUekNjR0g3YjJiU1UrQWthdHdiZS9tWHVlR2trSjUy?=
 =?utf-8?B?Mk8rQTFQZ0VvSmo5WnF0UGMrZjEwTEs5bWgwbmZRc29XWUdFTGZBQW4vZWFR?=
 =?utf-8?B?VkhaRXhFN3ZmUlBkTDVYRXNpOERTUm4rV2dyY0ZyN1gwR1BuZWl4KzZYZkVs?=
 =?utf-8?B?TzUrTGFNVFljTlQxMnFTUVp3bVVNZW56N1lHaGtTZ2MvQi9rZkI3cksvZWxt?=
 =?utf-8?B?TG4rQ1VMc2kvalk1NzIxV0h1VnVCcCtEVGVtcFVtN0FvVTk0SFJPeVRVditt?=
 =?utf-8?B?di9OZmM1Qi9VSWd6MHBmUkUvdkVVa0g1K1RDT0l4WHBaYUlzRFcvZmdRemZm?=
 =?utf-8?B?WTZSbXJIU1pKakduQVo1cVg3eDdCYWowSEgrWDRoMTI5a1ZBdjBRSE9mbWNk?=
 =?utf-8?B?OEFqckttTnczZ0NVZU5wNzJUalp2a0FNTFpnQm9zdng1NFU0S1dlMEx1N1ZM?=
 =?utf-8?B?Vm1aZDNITmRWWHB5WGlKK2JMbHNWdDNvSGNHZmZxSGtqZ3lKTHJvQVpTdXM4?=
 =?utf-8?B?ekxnYzVLQUNuT0NSMVhvUDNpWnY2WDNrUjF6N3hUNHNqdHpxbWkycElJdGRX?=
 =?utf-8?B?RHh5VWpXVzQ5d3plRVhYR09uWWlWOC9wQkFTdjNzdnp1SXFjcnJwakxMbUhp?=
 =?utf-8?B?S05sVnNrKy9DTGFOSDR1V2dZUERzVTBLNTdwNGVVNkNUcWJWUjNIZmFKemFV?=
 =?utf-8?B?SnBhaCtINE5tbldJTlNRUGpobEo2R0poVkRIU084Y0NJOHE4SnBkRTZtdlpQ?=
 =?utf-8?B?R29XSEVWVWFIMmJJMG1zZmJhZzZGYjJUNzRHUHVscUM4cjhtWVFEVVJXVUFQ?=
 =?utf-8?B?ZXJvR25odHRISk1rUkR0MTE5WENEY2U0SzBwUVI0eGdGbTV4MnNKNUxzbGZK?=
 =?utf-8?B?K0hOMDkvUkUxRnN0dkVWc3Y1REZMd0FGNlNPcnppRzhNSDF5WUI1T0VvRUdu?=
 =?utf-8?B?N0NveEpMQjUrTDZTVUlMWkFYMksvZE5Fd3dadFRhQ1p0OHFkVnJCTkpWYVpP?=
 =?utf-8?B?enNFV1kyamhzN0Q4RFNNQlZsNCtvQ2tPVzM3d0pRUlV6OUxFOWh3L2xWeGcr?=
 =?utf-8?B?ZjNaaENsZmhIWmhUUm5LMWl2M042Qnk3ZzV5VmxpbG1ETEZqTW96Yk0zZVVR?=
 =?utf-8?B?YkV5Yi8rbitMM0dyR1hKY2xweFh2QTBXRnl6cVowMkEyQnE0K3E0clV1NmdS?=
 =?utf-8?Q?FZYczzIzeftNyhrxGAYXOjB/OwcibO3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB8451.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?Tk1QWk9WZlNhT3lmM0c1M0ZRTloxRkhYeXdKT2lFay93eXdmRWtYSGpOR0li?=
 =?utf-8?B?UVBhZTdvbGt0eWRDYS8ydWVMMkZUVlRSb3VyQjJ5d0VJTFZYUDhUV3FheVRK?=
 =?utf-8?B?a0NQTHdPME50ZmJaRlk2cHFFOWV4N3Z2VS8xNy91a0llZEN3d0FVRHcvYXlE?=
 =?utf-8?B?aGwzdjNvR0hkVTAya1Y4T0p0aUxqVDNoOXd3cHhWa09rNE05bTZqMjZERU5l?=
 =?utf-8?B?SGJsZys5cXhEMklvRWtFcXJlUkxHaW90R2VlMUg4TzJ1SXdRY2llcFIwNE5V?=
 =?utf-8?B?U0ZVb3M1d0l2TTRiaWFqbmQyMHhzejJyU2V4ZFY1NjRydTFlM2doYU1YOGZK?=
 =?utf-8?B?alEzWHpaZHJMSWZqb1BZVlcvL20wOUVObXczNkRla0tKa0ZhUndaOXVtamIx?=
 =?utf-8?B?MWlXMlZuWUw0N05jWU95UlZwTUJMSmVxTFFpcnM0Y3grQ245MkhNdytpd0Zr?=
 =?utf-8?B?a0dJS2VLVGpybFAzY21DVmVFMytsZWhEZFQ0VjFHNkZ4VVcwZG9SZzFqVmwy?=
 =?utf-8?B?dzF3bzdZMW0xcXl1bTZQWHNxcUZ3bEp5QWJSQTl3N3RvRHhNTU9Ka1BIdnRk?=
 =?utf-8?B?Yml4dGhYSEh2dWRNN2txRDkrYUZIeVhuNFVvYSs3V3g4Sm9icVlOMTR3Q0NS?=
 =?utf-8?B?N3AwNUlSK3ZHR3hoamJ4d0ticE44cWp2YW0yK0VxUTA3U3pveURLWkdzSWt1?=
 =?utf-8?B?d3NaS0hIbnRUU2pLWTVuT3BsK2FBVDhOUWkzL1FmZ2RCeEtsbFlDRkMyYWZm?=
 =?utf-8?B?SUIvLzluNXQ0b0Q3QTNQOVZiSlNCT29RWURDeWtSOHlxb2RsRFdEUGYxYjRh?=
 =?utf-8?B?VVl5bjhxTzV4aG1lSWJzQzRZVDRqZEZrMTd0U1BWUUdOM1JBa2ZaaktmK1NH?=
 =?utf-8?B?RXVhcE0rYytzbVNHNzdyTTdxbjNxelpYRytoWFkwT0FESmk4dUx1QWp1OUJL?=
 =?utf-8?B?ano0ZmxqQTk5OE1JNVdwSmJtQldWSndHelJ1cWNEV3lVTkU5dlkrYUUvK0Mv?=
 =?utf-8?B?OFIvNEYzbFlseEVNalNMdEphVmtEZXNZZCsxYVR0RlhPTDFISkFSVkxpRG1C?=
 =?utf-8?B?QUtBbFZ0S1FxK0RPM0hDTGVvOXhkK0dSWWJnck1pbkRmQ2JJSnp4SWxSckxo?=
 =?utf-8?B?MVR6dzlES0JFYkV0bjFDOFlqN3EwMWlhZCtzZzdSdXRXNEhvWlJCS2RKc3kr?=
 =?utf-8?B?RkhWOGd5WHVpM2dsUUJsL0ZPdGM0OG1JY0dnYndSbGc2dlNBckhoaUtuTHU4?=
 =?utf-8?B?T0dPc2xmOXMzNERMdDcvdGhnTXdNWnlsMFFKZEZoY1ZTRHlhWU5DZ0tlaWQz?=
 =?utf-8?B?bXZGK0F1SWQ4Y1M5SFVwOEwydkppSDJPTEU1N2d4SDhVYitjNWc5c1dWR3hL?=
 =?utf-8?B?TU1tUmdYYk9HaGJYeS8xclhWdXJUSTZDV09sQVJ5Qk1vNW53R0l3c1p2cUU2?=
 =?utf-8?B?cm1CS3NrMmNodjRLV1pnbUNIWHU2VzUrS09SWVRvNDdqL0ZGVElaU2EwT0pv?=
 =?utf-8?B?cXpTa3R5VzZaSHRseDN3SzBmbGJkMHpnMzJ1b1cxZmpZS2d3RlB5Y2FJWFNB?=
 =?utf-8?B?ZzdLQVd2aFdwcXZyTUlzUkN5UmZWUnBhc1dKUkZST0FvaUdQb0ZRc2c3b1du?=
 =?utf-8?B?cGtlT0l1cVJsbWE0YzdxejJuajFGUWIvMXdwLzdiM1c1QUhHQTJhU29McWpK?=
 =?utf-8?B?WS9aVmU5NGdyczY1RVQ2bDh6aXdKV1lwUk1wQ2JmWE9jTFh5WFY0ZXJtSTc2?=
 =?utf-8?B?SmdSMWpjZnAyV3BiMjN2SFlwYnBlT3VrNmM5VnhDWERZS054KzZYa2g3amhH?=
 =?utf-8?B?a3gyaWlqTzNnRDYzVzVFTnJKWU5rZmJXWTBMcmE0Z3pSVE51emR1bkJkM0RD?=
 =?utf-8?B?SzRibFA4Q0lXN2pQbUVZZlNxYjRKMFAxVTRjVzhyQ2xNRFBJZkwyTTZic2gr?=
 =?utf-8?B?QnNad20zc1BXT2tqT3RZR1FvdUhnUFhDelVDMFB1N0F1Y0hJenFCdWNENW9D?=
 =?utf-8?B?dnZ6K2Y3OXlRTGFNNEF1WlExTjVsZXA1TWtJbDhQZHMzZG1TeDRaNnFqb3U1?=
 =?utf-8?B?RUovdFF1WEZoZXYrRjU5WG1wc2FGcHEyRFc5eFZqazV0Y1Y4V3ZYWlBza054?=
 =?utf-8?Q?HVeU=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB8451.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 735e272f-e7f2-412c-ebb6-08dd3dd30d65
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jan 2025 06:31:22.8153
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ZtRl0XoJhimsyEotzEM9pwRuidl8+Hl2XENmuIMF5/t5gI5y6RupTlPl9M9DnPqUkcMgZLnbmzcpBgMV3U0Rxg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB9175

W0FNRCBPZmZpY2lhbCBVc2UgT25seSAtIEFNRCBJbnRlcm5hbCBEaXN0cmlidXRpb24gT25seV0N
Cg0KSGksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSmFuIEJldWxp
Y2ggPGpiZXVsaWNoQHN1c2UuY29tPg0KPiBTZW50OiBUaHVyc2RheSwgSmFudWFyeSA5LCAyMDI1
IDc6MjQgUE0NCj4gVG86IFBlbm55LCBaaGVuZyA8cGVubnkuemhlbmdAYW1kLmNvbT4NCj4gQ2M6
IFN0YWJlbGxpbmksIFN0ZWZhbm8gPHN0ZWZhbm8uc3RhYmVsbGluaUBhbWQuY29tPjsgSHVhbmcs
IFJheQ0KPiA8UmF5Lkh1YW5nQGFtZC5jb20+OyBSYWdpYWRha291LCBYZW5pYSA8WGVuaWEuUmFn
aWFkYWtvdUBhbWQuY29tPjsNCj4gQW5kcnl1aywgSmFzb24gPEphc29uLkFuZHJ5dWtAYW1kLmNv
bT47IEFuZHJldyBDb29wZXINCj4gPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+OyBKdWxpZW4g
R3JhbGwgPGp1bGllbkB4ZW4ub3JnPjsgU3RlZmFubyBTdGFiZWxsaW5pDQo+IDxzc3RhYmVsbGlu
aUBrZXJuZWwub3JnPjsgUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+OyB4
ZW4tDQo+IGRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0gg
djEgMDgvMTFdIHg4Ni9jcHVmcmVxOiBhZGQgImNwdWZyZXE9YW1kLXBzdGF0ZSxhY3RpdmUiIHBh
cmENCj4NCj4gT24gMDMuMTIuMjAyNCAwOToxMSwgUGVubnkgWmhlbmcgd3JvdGU6DQo+ID4gRnJv
bTogUGVubnkgWmhlbmcgPHBlbm55LnpoZW5nQGFtZC5jb20+DQo+ID4NCj4gPiBUaGUgYW1kLXBz
dGF0ZSBkcml2ZXIgbWF5IHN1cHBvcnQgbXVsdGlwbGUgd29ya2luZyBtb2RlcywgcGFzc2l2ZSBh
bmQgYWN0aXZlLg0KPiA+DQo+ID4gSW50cm9kdWNlIGEgbmV3IHZhcmlhYmxlIHRvIGtlZXAgdHJh
Y2sgb2Ygd2hpY2ggbW9kZSBpcyBjdXJyZW50bHkgZW5hYmxlZC4NCj4gPiBUaGlzIHZhcmlhYmxl
IHdpbGwgYWxzbyBoZWxwIHRvIGNob29zZSB3aGljaCBjcHVmcmVxIGRyaXZlciB0byBiZSByZWdp
c3RlcmVkLg0KPiA+DQo+ID4gU2lnbmVkLW9mZi1ieTogUGVubnkgWmhlbmcgPFBlbm55LlpoZW5n
QGFtZC5jb20+DQo+ID4gLS0tDQo+ID4gIGRvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLnBhbmRv
YyAgICAgIHwgIDkgKysrKysrKystDQo+ID4gIHhlbi9hcmNoL3g4Ni9hY3BpL2NwdWZyZXEvYW1k
LXBzdGF0ZS5jIHwgMTIgKysrKysrKysrKystDQo+ID4gIDIgZmlsZXMgY2hhbmdlZCwgMTkgaW5z
ZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkNCj4gPg0KPiA+IGRpZmYgLS1naXQgYS9kb2NzL21p
c2MveGVuLWNvbW1hbmQtbGluZS5wYW5kb2MNCj4gPiBiL2RvY3MvbWlzYy94ZW4tY29tbWFuZC1s
aW5lLnBhbmRvYw0KPiA+IGluZGV4IDMwZjg1NWZhMTguLmE5YTNlMGVmNzkgMTAwNjQ0DQo+ID4g
LS0tIGEvZG9jcy9taXNjL3hlbi1jb21tYW5kLWxpbmUucGFuZG9jDQo+ID4gKysrIGIvZG9jcy9t
aXNjL3hlbi1jb21tYW5kLWxpbmUucGFuZG9jDQo+ID4gQEAgLTQ5OSw3ICs0OTksOCBAQCBJZiBz
ZXQsIGZvcmNlIHVzZSBvZiB0aGUgcGVyZm9ybWFuY2UgY291bnRlcnMgZm9yDQo+ID4gb3Byb2Zp
bGUsIHJhdGhlciB0aGFuIGRldGVjdGluICBhdmFpbGFibGUgc3VwcG9ydC4NCj4gPg0KPiA+ICAj
IyMgY3B1ZnJlcQ0KPiA+IC0+IGA9IG5vbmUgfCB7eyA8Ym9vbGVhbj4gfCB4ZW4gfSB7DQo+ID4g
LT4gWzpbcG93ZXJzYXZlfHBlcmZvcm1hbmNlfG9uZGVtYW5kfHVzZXJzcGFjZV1bLFs8bWF4ZnJl
cT5dXVssWzxtaW5mcg0KPiA+IC0+IGVxPl1dXSB9IFssdmVyYm9zZV19IHwgZG9tMC1rZXJuZWwg
fCBod3BbOls8aGRjPl1bLHZlcmJvc2VdXSB8DQo+ID4gLT4gYW1kLXBzdGF0ZVs6W3ZlcmJvc2Vd
XWANCj4gPiArPiBgPSBub25lIHwge3sgPGJvb2xlYW4+IHwgeGVuIH0gew0KPiA+ICs+IFs6W3Bv
d2Vyc2F2ZXxwZXJmb3JtYW5jZXxvbmRlbWFuZHx1c2Vyc3BhY2VdWyxbPG1heGZyZXE+XV1bLFs8
bWluZnINCj4gPiArPiBlcT5dXV0gfQ0KPiA+ICtbLHZlcmJvc2VdfSB8IGRvbTAta2VybmVsIHwg
aHdwWzpbPGhkYz5dWyx2ZXJib3NlXV0gfA0KPiA+ICthbWQtcHN0YXRlWzpbYWN0aXZlXVssdmVy
Ym9zZV1dYA0KPiA+DQo+ID4gID4gRGVmYXVsdDogYHhlbmANCj4gPg0KPiA+IEBAIC01MjIsNiAr
NTIzLDEyIEBAIGNob2ljZSBvZiBgZG9tMC1rZXJuZWxgIGlzIGRlcHJlY2F0ZWQgYW5kIG5vdA0K
PiBzdXBwb3J0ZWQgYnkgYWxsIERvbTAga2VybmVscy4NCj4gPiAgICBvbiBzdXBwb3J0ZWQgQU1E
IGhhcmR3YXJlIHRvIHByb3ZpZGUgYSBmaW5lciBncmFpbmVkIGZyZXF1ZW5jeSBjb250cm9sDQo+
IG1lY2hhbmlzbS4NCj4gPiAgICBUaGUgZGVmYXVsdCBpcyBkaXNhYmxlZC4gSWYgYGFtZC1wc3Rh
dGVgIGlzIHNlbGVjdGVkLCBidXQgaGFyZHdhcmUgc3VwcG9ydA0KPiA+ICAgIGlzIG5vdCBhdmFp
bGFibGUsIFhlbiB3aWxsIGZhbGxiYWNrIHRvIGNwdWZyZXE9eGVuLg0KPiA+ICsqIGBhY3RpdmVg
IGlzIGEgYm9vbGVhbiB0byBlbmFibGUgYW1kLXBzdGF0ZSBkcml2ZXIgaW4gYWN0aXZlKGF1dG9u
b21vdXMpIG1vZGUuDQo+ID4gKyAgSW4gdGhpcyBtb2RlLCB1c2VycyBjb3VsZCBwcm92aWRlIGEg
aGludCB3aXRoIGVuZXJneSBwZXJmb3JtYW5jZQ0KPiA+ICtwcmVmZXJlbmNlDQo+ID4gKyAgcmVn
aXN0ZXIgdG8gdGhlIGhhcmR3YXJlIGlmIHRoZXkgd2FudCB0byBiaWFzIHRvd2FyZA0KPiA+ICtw
ZXJmb3JtYW5jZSgweDApIG9yDQo+ID4gKyAgZW5lcmd5IGVmZmljaWVuY3koMHhmZiksIHRoZW4g
Q1BQQyBwb3dlciBhbGdvcml0aG0gd2lsbCBjYWxjdWxhdGUNCj4gPiArdGhlIHJ1bnRpbWUNCj4g
PiArICB3b3JrbG9hZCBhbmQgYWRqdXN0IHRoZSByZWFsdGltZSBjb3JlcyBmcmVxdWVuY3kgYWNj
b3JkaW5nIHRvIHRoZQ0KPiA+ICtwb3dlciBzdXBwbHkNCj4gPiArICBhbmQgdGhlbWFsLCBjb3Jl
IHZvbHRhZ2UgYW5kIHNvbWUgb3RoZXIgaGFyZHdhcmUgY29uZGl0aW9ucy4NCj4NCj4gTml0OiB0
aGVybWFsDQo+DQo+ID4gLS0tIGEveGVuL2FyY2gveDg2L2FjcGkvY3B1ZnJlcS9hbWQtcHN0YXRl
LmMNCj4gPiArKysgYi94ZW4vYXJjaC94ODYvYWNwaS9jcHVmcmVxL2FtZC1wc3RhdGUuYw0KPiA+
IEBAIC0yNyw2ICsyNyw4IEBADQo+ID4gICNkZWZpbmUgYW1kX3BzdGF0ZV93YXJuKGZtdCwgYXJn
cy4uLikgXA0KPiA+ICAgICAgcHJpbnRrKFhFTkxPR19XQVJOSU5HICJBTURfUFNUQVRFOiBDUFUl
dSB3YXJuaW5nOiAiIGZtdCwgY3B1LCAjIw0KPiA+IGFyZ3MpDQo+ID4NCj4gPiArc3RhdGljIGJv
b2wgX19yb19hZnRlcl9pbml0IG9wdF9jcHVmcmVxX2FjdGl2ZSA9IGZhbHNlOw0KPg0KPiBQb2lu
dGxlc3MgaW5pdGlhbGl6ZXIuDQo+DQo+ID4gQEAgLTM5OCw1ICs0MDcsNiBAQCBpbnQgX19pbml0
IGFtZF9wc3RhdGVfcmVnaXN0ZXJfZHJpdmVyKHZvaWQpDQo+ID4gICAgICBpZiAoICFjcHVfaGFz
X2NwcGMgKQ0KPiA+ICAgICAgICAgIHJldHVybiAtRU5PREVWOw0KPiA+DQo+ID4gLSAgICByZXR1
cm4gY3B1ZnJlcV9yZWdpc3Rlcl9kcml2ZXIoJmFtZF9wc3RhdGVfY3B1ZnJlcV9kcml2ZXIpOw0K
PiA+ICsgICAgaWYgKCAhb3B0X2NwdWZyZXFfYWN0aXZlICkNCj4gPiArICAgICAgICByZXR1cm4g
Y3B1ZnJlcV9yZWdpc3Rlcl9kcml2ZXIoJmFtZF9wc3RhdGVfY3B1ZnJlcV9kcml2ZXIpOw0KPiA+
ICB9DQo+DQo+IEknbSBhZnJhaWQgdGhlIGRlc2NyaXB0aW9uIGlzIG9mIG5vIGhlbHAgaW4gZGV0
ZXJtaW5pbmcgd2h5IHRoaXMgaXMgYSBjb3JyZWN0IGNoYW5nZSB0bw0KPiBtYWtlIChoZXJlKS4g
SG93IHdvdWxkIHRoZSB1c2VyIHByb3ZpZGVkIGhpbnQgKHNlZSBjbWRsaW5lIG9wdGlvbiBkZXNj
cmlwdGlvbikgYmUNCj4gY29tbXVuaWNhdGVkIHRvIGhhcmR3YXJlIHdoZW4gdGhlIGRyaXZlciBp
c24ndCBldmVuIHJlZ2lzdGVyZWQ/DQo+DQoNCk1heWJlIEkgc2hhbGwgY29tYmluZSB0aGlzIGNv
bW1pdCBpbnRvIHRoZSBuZXh0IG9uZSBhYm91dCBpbXBsZW1lbnRpbmcgZXBwIGRyaXZlciBmb3Ig
YWN0aXZlIG1vZGUsDQphbmQgdGhlIGNoYW5nZXMgd2lsbCBiZSBsaWtlOg0KICAtICAgIHJldHVy
biBjcHVmcmVxX3JlZ2lzdGVyX2RyaXZlcigmYW1kX3BzdGF0ZV9jcHVmcmVxX2RyaXZlcik7DQog
KyAgICBpZiAoIG9wdF9jcHVmcmVxX2FjdGl2ZSApDQogKyAgICAgICAgcmV0dXJuIGNwdWZyZXFf
cmVnaXN0ZXJfZHJpdmVyKCYmYW1kX2NwcGNfZXBwX2RyaXZlcik7DQogKyAgICBlbHNlDQogKyAg
ICAgICAgcmV0dXJuIGNwdWZyZXFfcmVnaXN0ZXJfZHJpdmVyKCZhbWRfY3BwY19jcHVmcmVxX2Ry
aXZlcik7DQpOb3csIHRoZSBkZXNjcmlwdGlvbiBtYWtlcyBtb3JlIHNlbnNlLg0KDQo+IEZpbmFs
bHkgSSBkb24ndCB0aGluayB0aGUgY2hhbmdlIGFib3ZlIHdvdWxkIGJ1aWxkLCBhcyBpdCBsZWF2
ZXMgYSByZXR1cm4gZnJvbSB0aGUNCj4gZnVuY3Rpb24gd2l0aG91dCByZXR1cm4gdmFsdWUuDQo+
DQo+IEphbg0KDQpNYW55IHRoYW5rcw0KUGVubnkNCg==


From xen-devel-bounces@lists.xenproject.org Sun Jan 26 19:56:01 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Jan 2025 19:56:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877219.1287340 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tc8jQ-0001lj-Db; Sun, 26 Jan 2025 19:55:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877219.1287340; Sun, 26 Jan 2025 19:55:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tc8jQ-0001lb-8d; Sun, 26 Jan 2025 19:55:44 +0000
Received: by outflank-mailman (input) for mailman id 877219;
 Sun, 26 Jan 2025 19:55: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
 <SRS0=Vl/L=US=linaro.org=richard.henderson@srs-se1.protection.inumbo.net>)
 id 1tc8jO-0001lU-Uo
 for xen-devel@lists.xenproject.org; Sun, 26 Jan 2025 19:55:43 +0000
Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com
 [2607:f8b0:4864:20::1036])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 84b9010f-dc1f-11ef-99a4-01e77a169b0f;
 Sun, 26 Jan 2025 20:55:41 +0100 (CET)
Received: by mail-pj1-x1036.google.com with SMTP id
 98e67ed59e1d1-2ee76befe58so6533802a91.2
 for <xen-devel@lists.xenproject.org>; Sun, 26 Jan 2025 11:55:40 -0800 (PST)
Received: from [192.168.0.4] (174-21-71-127.tukw.qwest.net. [174.21.71.127])
 by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-72f8a77c4ecsm5519455b3a.121.2025.01.26.11.55.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 26 Jan 2025 11:55:38 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 84b9010f-dc1f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737921339; x=1738526139; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=k/VcBzCgSZMRn5BGbBxU096iXq4FkgwntnoR7v0hF60=;
        b=wCmCTNWFzRLk7f3OQ3uZiz3xfXHPCQu3fuCXUC8klKtsxuvdOzG4YryILaKgRaCWDm
         wOKiylYHc+GMbXfqW4JsPiEe1/lICMLQd8uNaUo1SA9nfvMgfSzCMMY9lzS9449zBank
         hObGYdPegWrFVcJjETGvqdKAN45XOMZ8PAiGFxLDBK35F3QRx6Uu3DSnBFlw7rJTWFM/
         yghXXwSUeI+Vc6nnrphLfxKLsmqQQoBc5RT/8ief6FpgvLzedyFOOc8jKYox3hUBy0PL
         Cnml0fPPEnKybIEilwvQzif+zJ2G24jIDLu4N4QuXIifwUdCDygKtP58Mf1Q3u6/AmTc
         EzEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737921339; x=1738526139;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=k/VcBzCgSZMRn5BGbBxU096iXq4FkgwntnoR7v0hF60=;
        b=S0rWURlKYWPuJh7b4sLb6ehnTq9itwVzL8kuJLPWsPHuXmo9nUN3gmaeBPocL1rngY
         0z3ksWWsK/JEdAtxmvJCz9pox5OvJdxii4jbDzlN9RGxi74VVerZ2kwPJCNn/kbrSa/D
         gAv3GkFKzGOXHT+TKKcCCCAt/VmQUGzGZDkze2hpIcLqbNH0jDa5chfLXvpLVlSGUznC
         rsu4G7+O808wNtYgDQSTR/rqkk7yK7PZXwPLVFkjQLn72TkytnjgOjtUNVWrb5Po7N9x
         1tgiBdZckP1gCtdYORGmHM+GWVnjy/4kc+SgB0rC9jx8WzxvHIj1qFpZZdx1bqnqdNxZ
         uMaQ==
X-Forwarded-Encrypted: i=1; AJvYcCUBd3+zd2BhvNvdwOuo3zWZmPc+Ds0O3xwkPAFrnfzeni1SkzleRA1C9QjbdFOE45sLQK5Pd1pxiwk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YySFMCxD/ApQBM4HFBBMZuNvb+XfeO7h1q2hpyTfijMh5XtP2Ro
	o6FwgUXxrma17HD5u6SI7aPUS574fJ0imRvQS0wqMv2/vgUVJKaRrKyJpPp09s8=
X-Gm-Gg: ASbGncuAkqxADjE7UI1Wtuqfff/lA1pkvCKz1o/Oh/my/ccO4YIrQHt1LLWf4MUsN2i
	YwEWjRXUyaHI7ww+YgArILvbkL0qBVX/YftEA+Yym7ESMmB4l4YEoB6e59sEqEniEk9m0Es3rVP
	USOhk+SpfdjVj3YPQIXM5HljmRpMHjiLSt+iOdi8PwFp+wMNn7V4+/5EW7BZvACf0vL8ZEAl6Y/
	WjtfS8G7NOCdO/ClljMKMiml+p/D54/nJjAIX4zybxyM31TVTv0gUcGqZVR5L74kXxnNBj02BdC
	J30V6uPN2cHiHGd+Vn3JfaPdwrQcIt93Dx24YLU24JmBVcEeg2GxZ5a+Ow==
X-Google-Smtp-Source: AGHT+IHkPOqmTCjp5vaq/+XEVF4ezQ8MyiAJ8YKEj+eBpJYARUzB5sl2GUtr7fAvVdhnF62+x0fMUA==
X-Received: by 2002:a05:6a00:a09:b0:72d:80da:aff with SMTP id d2e1a72fcca58-72daf9c1dfcmr48758529b3a.9.1737921339455;
        Sun, 26 Jan 2025 11:55:39 -0800 (PST)
Message-ID: <ea6edd46-f1f6-40b0-bf89-c7f6f68bee87@linaro.org>
Date: Sun, 26 Jan 2025 11:55:36 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 02/20] user: Extract common MMAP API to 'user/mmap.h'
To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= <philmd@linaro.org>,
 qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
 Paolo Bonzini <pbonzini@redhat.com>, qemu-arm@nongnu.org,
 Igor Mammedov <imammedo@redhat.com>, =?UTF-8?Q?Alex_Benn=C3=A9e?=
 <alex.bennee@linaro.org>, kvm@vger.kernel.org, qemu-ppc@nongnu.org,
 qemu-riscv@nongnu.org, David Hildenbrand <david@redhat.com>,
 qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org
References: <20250123234415.59850-1-philmd@linaro.org>
 <20250123234415.59850-3-philmd@linaro.org>
Content-Language: en-US
From: Richard Henderson <richard.henderson@linaro.org>
In-Reply-To: <20250123234415.59850-3-philmd@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 1/23/25 15:43, Philippe Mathieu-Daudé wrote:
> Keep common MMAP-related declarations in a single place.
> 
> Note, this disable ThreadSafetyAnalysis on Linux for:
> - mmap_fork_start()
> - mmap_fork_end().
> 
> Signed-off-by: Philippe Mathieu-Daudé<philmd@linaro.org>
> ---
>   bsd-user/qemu.h        | 12 +-----------
>   include/user/mmap.h    | 32 ++++++++++++++++++++++++++++++++
>   linux-user/user-mmap.h | 19 ++-----------------
>   3 files changed, 35 insertions(+), 28 deletions(-)
>   create mode 100644 include/user/mmap.h

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~


From xen-devel-bounces@lists.xenproject.org Sun Jan 26 19:56:19 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Jan 2025 19:56:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877226.1287350 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tc8jz-0002EM-KK; Sun, 26 Jan 2025 19:56:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877226.1287350; Sun, 26 Jan 2025 19:56:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tc8jz-0002EF-Gn; Sun, 26 Jan 2025 19:56:19 +0000
Received: by outflank-mailman (input) for mailman id 877226;
 Sun, 26 Jan 2025 19:56: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
 <SRS0=Vl/L=US=linaro.org=richard.henderson@srs-se1.protection.inumbo.net>)
 id 1tc8jy-00029Z-Dr
 for xen-devel@lists.xenproject.org; Sun, 26 Jan 2025 19:56:18 +0000
Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com
 [2607:f8b0:4864:20::633])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9a18b7b1-dc1f-11ef-a0e6-8be0dac302b0;
 Sun, 26 Jan 2025 20:56:17 +0100 (CET)
Received: by mail-pl1-x633.google.com with SMTP id
 d9443c01a7336-2166f1e589cso96630705ad.3
 for <xen-devel@lists.xenproject.org>; Sun, 26 Jan 2025 11:56:17 -0800 (PST)
Received: from [192.168.0.4] (174-21-71-127.tukw.qwest.net. [174.21.71.127])
 by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-21da424ef28sm48976545ad.258.2025.01.26.11.56.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 26 Jan 2025 11:56:14 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9a18b7b1-dc1f-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737921375; x=1738526175; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=oZaiNxyRumKDQ6iU0NUlyhjPpWDJhbWYeJfxDmaXxDo=;
        b=z4qHA5gf9PWTl8eBiP9fikCLJJl+njIkfPxMHp9AH/Bkvbs/RLHifmTfzMA8y55CAq
         +DGWL/ksEgs/9hS2QEtyIxPrOGR2o6ET5mD5uyBN6udCaGY4HX7BeRuas1rUUIBcm1Lr
         CWo4lI0zV7liP3o9PboB4eAzAOzTxfHwf27O8MM7H0HtNIOJS8oV8l/6YnHCnt6RzGgl
         XYgs474X7pMDPcO49LrZRA2EtnR5rRkeLzHrAcgF00JpSQawBGYEOvsvFA9onqgpngPY
         vFOdtE4n3bdzCH/KfLDf/P6JWTKkt2TNI8ROqjrppkV4qIH2r5JJvlsBxu9BNdM4/XXY
         bdIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737921375; x=1738526175;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=oZaiNxyRumKDQ6iU0NUlyhjPpWDJhbWYeJfxDmaXxDo=;
        b=xUevOntV88FTWjGCJDV+K3oRshgV0h3nFr8r4pC9zyU4kO3suNppE5PzCqreWORW9/
         3q6/i1CpO8TO0sjgAAIbG2Y7F2dBg0cRcnTO5bk3F1OT1lyszRfshRgXFuOG8Uf5qO9P
         JR3S8Kq1HVqLOZ/HVFxgRW4B8jxn2iuRt76XaPA+VrAetnPSEFhRxyP7E5YCnYGMWeyi
         rNOOCmQGV6344WlHs2/nkzFwLpjAZg1q+qgBQK6Bvk2wxZK9wkXkxMwHPlbKHBidcXiM
         aoUccNr6cVqFWu4lxI8DPrRLDjB0pGckjLyK1/FG4eHG1S7PfGmgXUiLFrnlTgsabSmf
         nBdg==
X-Forwarded-Encrypted: i=1; AJvYcCWNCrbzplvL0I4F7D2V4GazIPjdbV545tsGpXcPtfJklML7SOnQk5qdbaHq0VfX3jnw3w9GKoWHmfc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwgGir+PgPpTdtu0DGbrzclM7ZGkjhh9v5c5aPCaeLkDIRQwKmm
	TtjHdh9YWBRNYul1jBWFOGRbLcC8lsMlPXY2X+F9UxE4E5g+GNhMn8tlYOOxIFE=
X-Gm-Gg: ASbGncswXQq5RfRksG9dWtji1RBYYmLuI8DcunabHBpHnb+tAiOUWJNfQ/ibVfmjFXm
	v47acqrWughSlwkAiY6KbWD9Iido9qC+buCtnhrsh3Wigi4AAAu9aVMmDM8/pFz3la1MWKJRaBI
	OVolHNje32qQhhBMMqjt6llu2UiK12HMFiCE5Ciay1mJfFfS0l4SCU15ElRzZccKdd1WYSMQQ7t
	l+TYnpUfKbVVsAsQK7Mtagl94gL7/sXdO2pQcCWv4M8IqyS+JbOtPqd7vbmKLxzQjHZ4ki9VTjZ
	6iqebkf6j3JBMNlFxJyHZlazbwXaK9X/ZmFi7JRaQesqznI=
X-Google-Smtp-Source: AGHT+IHO4WMUbjm+0GYB5uvcZM2pATyJHyNJ2uKrCdmerCTV19qq9YWTnaUhr9U9sZ/t561e+9mUEA==
X-Received: by 2002:a17:902:e746:b0:215:97c5:52b4 with SMTP id d9443c01a7336-21c35631dd4mr526655615ad.39.1737921375406;
        Sun, 26 Jan 2025 11:56:15 -0800 (PST)
Message-ID: <51770df2-ecbb-47b9-b5c5-a60decf0f751@linaro.org>
Date: Sun, 26 Jan 2025 11:56:12 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 03/20] gdbstub: Check for TCG before calling tb_flush()
To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= <philmd@linaro.org>,
 qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
 Paolo Bonzini <pbonzini@redhat.com>, qemu-arm@nongnu.org,
 Igor Mammedov <imammedo@redhat.com>, =?UTF-8?Q?Alex_Benn=C3=A9e?=
 <alex.bennee@linaro.org>, kvm@vger.kernel.org, qemu-ppc@nongnu.org,
 qemu-riscv@nongnu.org, David Hildenbrand <david@redhat.com>,
 qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org
References: <20250123234415.59850-1-philmd@linaro.org>
 <20250123234415.59850-4-philmd@linaro.org>
Content-Language: en-US
From: Richard Henderson <richard.henderson@linaro.org>
In-Reply-To: <20250123234415.59850-4-philmd@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 1/23/25 15:43, Philippe Mathieu-Daudé wrote:
> Use the tcg_enabled() check so the compiler can elide
> the call when TCG isn't available, allowing to remove
> the tb_flush() stub.
> 
> Signed-off-by: Philippe Mathieu-Daudé<philmd@linaro.org>
> ---
>   accel/stubs/tcg-stub.c | 4 ----
>   gdbstub/system.c       | 5 ++++-
>   2 files changed, 4 insertions(+), 5 deletions(-)

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~


From xen-devel-bounces@lists.xenproject.org Sun Jan 26 20:00:09 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Jan 2025 20:00:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877234.1287360 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tc8ng-0003qG-2c; Sun, 26 Jan 2025 20:00:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877234.1287360; Sun, 26 Jan 2025 20:00:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tc8ng-0003q9-04; Sun, 26 Jan 2025 20:00:08 +0000
Received: by outflank-mailman (input) for mailman id 877234;
 Sun, 26 Jan 2025 20:00:07 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Vl/L=US=linaro.org=richard.henderson@srs-se1.protection.inumbo.net>)
 id 1tc8nf-0003kh-Hh
 for xen-devel@lists.xenproject.org; Sun, 26 Jan 2025 20:00:07 +0000
Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com
 [2607:f8b0:4864:20::1031])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 23186b99-dc20-11ef-a0e6-8be0dac302b0;
 Sun, 26 Jan 2025 21:00:06 +0100 (CET)
Received: by mail-pj1-x1031.google.com with SMTP id
 98e67ed59e1d1-2ef714374c0so5728307a91.0
 for <xen-devel@lists.xenproject.org>; Sun, 26 Jan 2025 12:00:06 -0800 (PST)
Received: from [192.168.0.4] (174-21-71-127.tukw.qwest.net. [174.21.71.127])
 by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-2f7ffb1dc56sm6196959a91.49.2025.01.26.12.00.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 26 Jan 2025 12:00:04 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 23186b99-dc20-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737921605; x=1738526405; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=jvT1nOyyGXJEnkXkKCQj0Xq14BrdlE2RAOYFWR4ybQg=;
        b=e7SDiUR23qm+RyyWxecnkkruvlx+zoM/1pqYtyLJk3ATfnIG9d/LZX1HwooD5d6SwA
         wrKygL1OY3MUKkfVnyaHa0iYE0vcW6eFfgohATMCgs9MYD4nwdG66U5xvw8WrD6GIFek
         WT2xYVdVpA4/Zyw8e3cqJfiGFZRUfZGe7he/HNPs9t79l7JRyyhzIL0zRrRfUsiuy3Ik
         Rpx1VxXWUECjJVpTnYKDj+RDegPmirpR8ynkdFMSSxf6NvzcVWArF1/pl1i8G4/pkbqd
         ix+HfEl4/8qKGxfVgizSY7PUDtBdUEGssfCxYsSesQ+bmuJjgXga8KfldL0Zv1s/o/B0
         3NhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737921605; x=1738526405;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=jvT1nOyyGXJEnkXkKCQj0Xq14BrdlE2RAOYFWR4ybQg=;
        b=wCM97nY4u4OmRVNSyoe7TfCQXMsVHAolHaV68EPBoKt/l6UqibhLyR+OZzHoTxx8No
         r5t1z4SFHCz+BGsaHhg6KXL8vaV0AOwr7oLGp5V763RnauH1mXsO1iASnlTmfC34VjbY
         GJpT7aIPoGnkNi24RlxN4gAeVVI2qIZTbAkMQxDLeC4izeSUIWkI37buGJ15eEEFqMEW
         Cg9aHvPptL6c0OnWJdgCsTQxyh66MhdCnCME1Y3qHYUIKliFpAkJ2e4PLeHqKguNrFr9
         ZvWd4yAca4Th6wtbyy3+eU0a+7TA43jpq0PpQBD8turESA05j7/Zbmh8EhOZ8lxm/xjI
         bMkQ==
X-Forwarded-Encrypted: i=1; AJvYcCW+SYi6W7mfRMq+sz6qiCznEE5J/J2RA0vzuUfajKe12unoQKF2xdlihO5pkuMSXyZWbFniAZGP63g=@lists.xenproject.org
X-Gm-Message-State: AOJu0YywntrpLK7NJM8Bpm+hBRMje9KtlrPuM7xrF4aWtta7i4aMN8n8
	NYqyeCKbTROgmafhsM0y9HKh2vvldAnssHBVn6WP11bkzFXFuqkgXYH0VmqO4Ck=
X-Gm-Gg: ASbGncv1FZ0TJnzGiTEBgDnfT1n67e9AGN3zURWCE9D2HrtKdRjDLzOJkqiSCqERvY0
	/XsRKAwjSLl29aIX0fWVMjbe3U3+GxtsEHOxrI3Sq7GTfIer18BgkRifhqcoQfTFTMktxPWRWL0
	JOs7Ehg30XbTY5sIcQwGt8J0zxn0AHXqfsoxzR9Eu7bkzMNa+3wN35xXiiM720KwNfLlikj2WM0
	yK8XdUNeqme4mXTSIn2DvyyW3Mjw4M4r3RFBqVH4aA7mIIkQjnDN+dz+KUilAgGpkgpB/vovYIT
	XAW6kc5CR7EH9ChruXW6zFaKlbSI9RPxIU92xCehXPwrXVg=
X-Google-Smtp-Source: AGHT+IEP4DwQ/u514V5B38J2P62wTL0qYp8JNncl4+5UB0i/l/G/YI+4UbX8eVL0ayMsA+c7B1DDZA==
X-Received: by 2002:a17:90a:f947:b0:2ee:8cbb:de28 with SMTP id 98e67ed59e1d1-2f7f176b184mr25848071a91.8.1737921605198;
        Sun, 26 Jan 2025 12:00:05 -0800 (PST)
Message-ID: <ba781224-7b4a-43f6-af25-acb308f11313@linaro.org>
Date: Sun, 26 Jan 2025 12:00:02 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 05/20] cpus: Keep default fields initialization in
 cpu_common_initfn()
To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= <philmd@linaro.org>,
 qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
 Paolo Bonzini <pbonzini@redhat.com>, qemu-arm@nongnu.org,
 Igor Mammedov <imammedo@redhat.com>, =?UTF-8?Q?Alex_Benn=C3=A9e?=
 <alex.bennee@linaro.org>, kvm@vger.kernel.org, qemu-ppc@nongnu.org,
 qemu-riscv@nongnu.org, David Hildenbrand <david@redhat.com>,
 qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org
References: <20250123234415.59850-1-philmd@linaro.org>
 <20250123234415.59850-6-philmd@linaro.org>
Content-Language: en-US
From: Richard Henderson <richard.henderson@linaro.org>
In-Reply-To: <20250123234415.59850-6-philmd@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 1/23/25 15:43, Philippe Mathieu-Daudé wrote:
> cpu_common_initfn() is our target agnostic initializer,
> while cpu_exec_initfn() is the target specific one.
> 
> The %as and %num_ases fields are not target specific,
> so initialize them in the common helper.
> 
> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> ---
>   cpu-target.c         | 3 ---
>   hw/core/cpu-common.c | 2 ++
>   2 files changed, 2 insertions(+), 3 deletions(-)

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~


From xen-devel-bounces@lists.xenproject.org Sun Jan 26 20:00:25 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Jan 2025 20:00:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877239.1287370 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tc8nx-0004G9-AO; Sun, 26 Jan 2025 20:00:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877239.1287370; Sun, 26 Jan 2025 20:00:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tc8nx-0004G0-7U; Sun, 26 Jan 2025 20:00:25 +0000
Received: by outflank-mailman (input) for mailman id 877239;
 Sun, 26 Jan 2025 20:00:24 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Vl/L=US=linaro.org=richard.henderson@srs-se1.protection.inumbo.net>)
 id 1tc8nw-0003kh-AK
 for xen-devel@lists.xenproject.org; Sun, 26 Jan 2025 20:00:24 +0000
Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com
 [2607:f8b0:4864:20::630])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2d4e4104-dc20-11ef-a0e6-8be0dac302b0;
 Sun, 26 Jan 2025 21:00:23 +0100 (CET)
Received: by mail-pl1-x630.google.com with SMTP id
 d9443c01a7336-2167141dfa1so65355025ad.1
 for <xen-devel@lists.xenproject.org>; Sun, 26 Jan 2025 12:00:23 -0800 (PST)
Received: from [192.168.0.4] (174-21-71-127.tukw.qwest.net. [174.21.71.127])
 by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-21da3d9e083sm49207555ad.25.2025.01.26.12.00.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 26 Jan 2025 12:00:21 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2d4e4104-dc20-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737921622; x=1738526422; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=r4XT8sSxnuMIL4fpPA4fND9osMVr0JW6MvSO5af0S0M=;
        b=q7BA9rdoQ0fLOsIxIBpPUdOWoV+AvdwWab0orf2N1sAV963UX4MspVUgWOdLgv8Xux
         zoB3mu+1UTy0cWzfJIlpOS8oEUcMKNU5P7wxIMn3rdFIM86HMeOgxPHUyWehzMCBXwEb
         tFiF4Xx1ujt0UlViRrTIxPHEERoeuIwf0ne7524WWzHHrR0WlOc6RFofxSCmDn1a/bgB
         pT4kewSdqGtrCghouVlGFpbEpKPCIiquYVPKPvuPFgyrh+FxWJMp9bnZn3QvhwYhfEER
         3u5b2mNG55dbN02uWMb38775iIiau3Kv2ErNr1CAvgJIJ8CUvUNSd/Txg6I5ks4J25Na
         8zZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737921622; x=1738526422;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=r4XT8sSxnuMIL4fpPA4fND9osMVr0JW6MvSO5af0S0M=;
        b=C8oZyTq1cnHZOmJlptOwA3NLYAme62oYDsn1e/OYTlfmZfzXuwZDFiAAV8t2VrMoOE
         RCspvmGH0t2eEJ9dOde9JRA2kvgtHbxakZc5R6CWxFyTH1Xa0qyl1ESEmy7quNPeDg6C
         6PrqblS90BfYCkTaDoXKQurfZSgrQifCu6oZSAmOyiKBN0QQRXT4BJuicws4BBq/LlFF
         euOhsMzO0t2xKzbpvG678LvwKv+i0bIfWbwoAopJnYQE7iUQZI82fd53XlvXsT5psvBz
         JU5X864nimAgmpRS8edDnxFFfgK5W52qgb14mTya4XDMfvf5dPqWch9iOz3O8VkIJHW2
         JQ0w==
X-Forwarded-Encrypted: i=1; AJvYcCWt97OMyiCnbq3k54tFJlx2q1LukQn49MxgRmniDRSZAWR1Iz6rfVNtI+3WbfTePCGik6e5vE5eadA=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxgr68Q6p3rr1nvda5l969QKptAJKrRUNaCaXdrbTsNKmMHMqvo
	E3pmEHzZ7yMVPHG19b/B89pirsjweJEGfTthfPC2cN47IMwW94hXBZ5t0Lyo0Y4=
X-Gm-Gg: ASbGncvxhtEuyRyLBKMtnK10s2R3BcDWU3jwFm43sS0+ZLMQcwzTO915llSoivqMSu8
	HOsFe7MIQneBuJfXIiecL+sF4rGIAW2BSNJQOka06DYJshti+7CQBKJ8/eGbIBpTsgHw96czjDE
	wO63gwSAeywa7AVnVMBVWhHFDu0or45fQZYXrPz8K0o9x6hiaUi1KjECS6wXq5nFDUS98h45AXL
	/sEpBQZTJtOEYpIRD9PBjpUzFr8rxppjQWE2QkT3KSR6D+NefRE0zpHN0LCvVeZNuS9onQOr/QJ
	1Lt2oEQeyEIKDFiEXgap+XjTLuqF5Z9+3864tcGUAzq5q4o=
X-Google-Smtp-Source: AGHT+IFeEZa5nVv+mtwIu6A9hZNGU86wznbWhD1KnBdApuLwR5PvKTBdXCajk9Qtynkb/fqX/bwRng==
X-Received: by 2002:a17:903:124b:b0:215:98e7:9b1 with SMTP id d9443c01a7336-21d993177a2mr227130405ad.5.1737921622320;
        Sun, 26 Jan 2025 12:00:22 -0800 (PST)
Message-ID: <bb022c56-2ec9-4e76-9bc6-efe2f7272806@linaro.org>
Date: Sun, 26 Jan 2025 12:00:19 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 06/20] accel/kvm: Remove unused 'system/cpus.h' header in
 kvm-cpus.h
To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= <philmd@linaro.org>,
 qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
 Paolo Bonzini <pbonzini@redhat.com>, qemu-arm@nongnu.org,
 Igor Mammedov <imammedo@redhat.com>, =?UTF-8?Q?Alex_Benn=C3=A9e?=
 <alex.bennee@linaro.org>, kvm@vger.kernel.org, qemu-ppc@nongnu.org,
 qemu-riscv@nongnu.org, David Hildenbrand <david@redhat.com>,
 qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org
References: <20250123234415.59850-1-philmd@linaro.org>
 <20250123234415.59850-7-philmd@linaro.org>
Content-Language: en-US
From: Richard Henderson <richard.henderson@linaro.org>
In-Reply-To: <20250123234415.59850-7-philmd@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 1/23/25 15:44, Philippe Mathieu-Daudé wrote:
> Missed in commit b86f59c7155 ("accel: replace struct CpusAccel
> with AccelOpsClass") which removed the single CpusAccel use.
> 
> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> ---
>   accel/kvm/kvm-cpus.h | 2 --
>   1 file changed, 2 deletions(-)
> 
> diff --git a/accel/kvm/kvm-cpus.h b/accel/kvm/kvm-cpus.h
> index b5435286e42..688511151c8 100644
> --- a/accel/kvm/kvm-cpus.h
> +++ b/accel/kvm/kvm-cpus.h
> @@ -10,8 +10,6 @@
>   #ifndef KVM_CPUS_H
>   #define KVM_CPUS_H
>   
> -#include "system/cpus.h"
> -
>   int kvm_init_vcpu(CPUState *cpu, Error **errp);
>   int kvm_cpu_exec(CPUState *cpu);
>   void kvm_destroy_vcpu(CPUState *cpu);

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~


From xen-devel-bounces@lists.xenproject.org Sun Jan 26 20:01:09 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Jan 2025 20:01:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877250.1287380 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tc8oZ-00055q-I7; Sun, 26 Jan 2025 20:01:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877250.1287380; Sun, 26 Jan 2025 20:01:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tc8oZ-00055j-FE; Sun, 26 Jan 2025 20:01:03 +0000
Received: by outflank-mailman (input) for mailman id 877250;
 Sun, 26 Jan 2025 20:01:02 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Vl/L=US=linaro.org=richard.henderson@srs-se1.protection.inumbo.net>)
 id 1tc8oY-0004Vi-Iw
 for xen-devel@lists.xenproject.org; Sun, 26 Jan 2025 20:01:02 +0000
Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com
 [2607:f8b0:4864:20::632])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4385e561-dc20-11ef-99a4-01e77a169b0f;
 Sun, 26 Jan 2025 21:01:01 +0100 (CET)
Received: by mail-pl1-x632.google.com with SMTP id
 d9443c01a7336-21669fd5c7cso64755355ad.3
 for <xen-devel@lists.xenproject.org>; Sun, 26 Jan 2025 12:01:01 -0800 (PST)
Received: from [192.168.0.4] (174-21-71-127.tukw.qwest.net. [174.21.71.127])
 by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-ac495983698sm4974713a12.55.2025.01.26.12.00.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 26 Jan 2025 12:00:59 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 4385e561-dc20-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737921659; x=1738526459; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=UTEeD0XMSKGDjb4UjeehXNP6i1pjJAUAQz3ZrUzV6BY=;
        b=EhQFKSC38jPJ3XFBGzgNBW2enCPrmxuaAf/dp8JA+U5oG0RnIk5i6JSiAf0gXsSTuQ
         LP9qRypyEks1wiBF/YS6nXd9rxJR3iv/VYeJc6ssKPKugNDOWxbv1faM5UXutzTjPiZE
         VMfa1gTPThEDRRTYVxVGefOF5+ejy4yLNVFySlC90kjNsM972l0HuvXM8hzy+KpTv42I
         0Pru+Yuv0i3wb0IqHTGVvWPtRFtwj3hLbgYolaQKBYRNhV7cLRVCfZpUYPRKmR9nEryS
         XRj+3rrjSwpiDG4T/tW/82TdxVqnEmM1VazJsT3N9PEyW1Gv7dB/arQTPzFoVwTNfkcp
         3yhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737921659; x=1738526459;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=UTEeD0XMSKGDjb4UjeehXNP6i1pjJAUAQz3ZrUzV6BY=;
        b=tTyYKFUxi+IXEsISvqxr/k+JQZIb5t72zN3RBfDsrhBiCkWrYOFaDJ2ys/AS0fd0e5
         BCCkbkFWn8HALpjf9LweOrtk7sbn8CjwNca90QtbTa34XCxU+hBRVrOabBxYqRQJJIk2
         v7c5k1fPKywdMMqf4EMyBiczXZo/hxfoCabICAJVLQ3ttYj4zrYlx5/T0z8ENZ8G7/ic
         5Z2psnc/Fg1Sp8X8G06yP7WukctbAr1OmIOPvh4KjcoQRNq6t7pPuFsCUHEJZ8BbCNU7
         aaEoURnYfgX21DxKOUvxoQFG20t0iPvy/IsOP+w3nEZ8X4pae2sbQ+2EK8dvOukt0J8E
         4Qng==
X-Forwarded-Encrypted: i=1; AJvYcCWdmDW2JXvfQbFnRZZFqqiXMNGJy83ro1gsCIo8QQnH+3m0nh6RzkCx/WJiEhPPaQ04LZ4fiCVejHc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyhvtRta5Y+iMLhjCGlSQkwHgiBqXKEoItS2M1ttmezLoDGUNhx
	hb8zgO5CAmigSDzgoKbTp+MRltKeFmHi3ZZ1Z0apx88pgMDH3yVK+h7ptgM15QA=
X-Gm-Gg: ASbGncuc/61o3S2DiXX+/rXznB7hJeyjeKlYMjCau7EB/Nqy1FuQ4BBkxaKYFXruLQm
	/5C3Ph8f4UUAd41qNfwIZoSWCsmCiDJ4dQ0YO3q6e32vjdBLfK82fyWfz8iY85agAf/hkpjwYoG
	Teho8ghqnF4rM2acOM85q5KHyDuXftbKF1MJQauMw0jpcwBdPmzYl3sQEruEE6ayS+aUYSPn6KT
	EIBMo2cw1iyUHtylgZE1K9yncJohndU3+mAYiRJ519bRuY2HIfxHzeGz5+QNLr7BmyWkw9fZhpl
	UNzOyJ1A9TBzxf4wq0xY0yrh0gqlOaPVSgV6JKX7v+npPRM=
X-Google-Smtp-Source: AGHT+IHk4oCZBkQ3EpN55L01I/3BlN88uO4hEsi17nz9LIDtFF+nfMo3swxHhoOsy6uzlknivzwr8w==
X-Received: by 2002:a05:6a21:99aa:b0:1e0:d89e:f5cc with SMTP id adf61e73a8af0-1eb21485c9bmr55831284637.11.1737921659596;
        Sun, 26 Jan 2025 12:00:59 -0800 (PST)
Message-ID: <aa1564ba-b51d-4278-9368-2849266f8685@linaro.org>
Date: Sun, 26 Jan 2025 12:00:56 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 07/20] accel/tcg: Build tcg_flags helpers as common code
To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= <philmd@linaro.org>,
 qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
 Paolo Bonzini <pbonzini@redhat.com>, qemu-arm@nongnu.org,
 Igor Mammedov <imammedo@redhat.com>, =?UTF-8?Q?Alex_Benn=C3=A9e?=
 <alex.bennee@linaro.org>, kvm@vger.kernel.org, qemu-ppc@nongnu.org,
 qemu-riscv@nongnu.org, David Hildenbrand <david@redhat.com>,
 qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org
References: <20250123234415.59850-1-philmd@linaro.org>
 <20250123234415.59850-8-philmd@linaro.org>
Content-Language: en-US
From: Richard Henderson <richard.henderson@linaro.org>
In-Reply-To: <20250123234415.59850-8-philmd@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 1/23/25 15:44, Philippe Mathieu-Daudé wrote:
> While cpu-exec.c is build for each target,tcg_flags helpers
> aren't target specific. Move them to cpu-exec-common.c to
> build them once.
> 
> Signed-off-by: Philippe Mathieu-Daudé<philmd@linaro.org>
> ---
>   accel/tcg/cpu-exec-common.c | 33 +++++++++++++++++++++++++++++++++
>   accel/tcg/cpu-exec.c        | 32 --------------------------------
>   2 files changed, 33 insertions(+), 32 deletions(-)

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~


From xen-devel-bounces@lists.xenproject.org Sun Jan 26 20:33:12 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Jan 2025 20:33:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877260.1287391 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tc9JZ-0001kc-UA; Sun, 26 Jan 2025 20:33:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877260.1287391; Sun, 26 Jan 2025 20:33:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tc9JZ-0001kV-PR; Sun, 26 Jan 2025 20:33:05 +0000
Received: by outflank-mailman (input) for mailman id 877260;
 Sun, 26 Jan 2025 20:33:04 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Vl/L=US=linaro.org=richard.henderson@srs-se1.protection.inumbo.net>)
 id 1tc9JY-0001kP-Dj
 for xen-devel@lists.xenproject.org; Sun, 26 Jan 2025 20:33:04 +0000
Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com
 [2607:f8b0:4864:20::1033])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bcee7df1-dc24-11ef-a0e6-8be0dac302b0;
 Sun, 26 Jan 2025 21:33:02 +0100 (CET)
Received: by mail-pj1-x1033.google.com with SMTP id
 98e67ed59e1d1-2efd81c7ca4so4947872a91.2
 for <xen-devel@lists.xenproject.org>; Sun, 26 Jan 2025 12:33:02 -0800 (PST)
Received: from [192.168.0.4] (174-21-71-127.tukw.qwest.net. [174.21.71.127])
 by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-2f7ffa8122fsm5509332a91.41.2025.01.26.12.33.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 26 Jan 2025 12:33:00 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: bcee7df1-dc24-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737923581; x=1738528381; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=GarlRROndxCjTPZHSIwatKna1U0gu9y5c+dSUp9779s=;
        b=IWizSva2vHJJsalbX6EfDYbGFwIJ08e/RAaEh4kQhwO3ai0j1APHCnT5PMWaiHnyl3
         j/JSq4kO6w6p3O94PxOqOE2Gu4lRPlOHjJ/GWGcSD07DPtTv6xwnbRfdkWgH3Y9rQIMc
         GPg/Mf1MnMXmSZvnZHqpYJT1YRAeODsnnCaKgf+1MRC8WTHka6FsCt92fkFK6CXZRpHO
         AD8Sbc6FoC8SNJ69KBGmlp4DGJBP04Cb7DvaV15ar/X2YEZ3bN9WyG+P68LKUGgbP9G3
         gXvdN2mAaB5YykyB0O44lv+IZfwtpuDrkQCkTfUgIG8i2okpiJC6Oe/ULEZany3O0sle
         74yw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737923581; x=1738528381;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=GarlRROndxCjTPZHSIwatKna1U0gu9y5c+dSUp9779s=;
        b=f5997u9DZ/EnQX76uLJN3AxUi4WbhyGqgtC+vdtlk4kuqVRN33GhVovXfOaT3TPU/Z
         G7E/WRvj7iakf1YDprbx1LxNPI8DKXLawHyg6cPHjzHl+vddIItgW1CRG2Qx/IWwa9QO
         JM8s0hhPoJF27arslPJh9LsGDVCJymMkTrV30d/tfcG7nsrsXqs3VBC0X+lJqhHLRSKS
         Prc1NLelFtrDSqXHc22+5ij+G6Tl9Id5dL6A2UaNKhzr1hgUIP3+hUZgapIJsv+s92+V
         0IuE5wXiAdr13rKqOoABliiFOYZnUSmbqsov4BpBheLz6noG+RKTomUYzxRf8lyn1TML
         5gIA==
X-Forwarded-Encrypted: i=1; AJvYcCW7f59E+MYxMo7DnCNXQAnPymf6v+Jp9moq1wBEDnpZ5FyDLaQ6YpXCtwjmYEPcmjj5ULQNgncM53Y=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyg6eZ2BvO72V+hxgKNasDpELBNKqJva5Vk6p9NR6D465ktGMvu
	hLOLSPVb2v5Mdy8mLFqf19gPylIGFsc5/rn8x3myarWuEFegosriOawZqemV4KY=
X-Gm-Gg: ASbGnctPKQUNg6X/9/ND+foM6xGJ3rSUcuU9cx9hBSrku+mTu5s6kDtMxlzw9jnm1zh
	2HxADMrnhda1kcR9kNAO//j5U3RhaMf0t0Ogvjhcsif4Cuhxs2qsrFkOMob+/w06wye6MQobxIA
	rKTWK31U7DP7vkXxQw3wN/Xdgqlyp/8JBWCnLEvEckK2PG/rcefTlGLddePPe19Ec7wxox2SXzT
	zZWmOS8/gwrT776DxeQ/6/SClr0qfyVlX74ROho7KtLgfVBQWLTFHbvdwkb5aapiLyVn5cQXJXD
	hz3R0cM7tVE7M41+sxquJV1zg9yXBiT9sW57rRuuJ1VmLUA=
X-Google-Smtp-Source: AGHT+IGrTF0ua3JOvhdmIhcZ60si5thXhjyK00MEnuyxWBq+ow6bXi0deca44yvyI2f3m7/CVHkiOg==
X-Received: by 2002:a17:90b:3a0e:b0:2f7:7680:51a6 with SMTP id 98e67ed59e1d1-2f782c55be4mr50581605a91.6.1737923581153;
        Sun, 26 Jan 2025 12:33:01 -0800 (PST)
Message-ID: <525918e8-b114-49de-bf4f-5b6e1c04d29c@linaro.org>
Date: Sun, 26 Jan 2025 12:32:59 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 08/20] accel/tcg: Restrict tlb_init() / destroy() to TCG
To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= <philmd@linaro.org>,
 qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
 Paolo Bonzini <pbonzini@redhat.com>, qemu-arm@nongnu.org,
 Igor Mammedov <imammedo@redhat.com>, =?UTF-8?Q?Alex_Benn=C3=A9e?=
 <alex.bennee@linaro.org>, kvm@vger.kernel.org, qemu-ppc@nongnu.org,
 qemu-riscv@nongnu.org, David Hildenbrand <david@redhat.com>,
 qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org,
 Pierrick Bouvier <pierrick.bouvier@linaro.org>
References: <20250123234415.59850-1-philmd@linaro.org>
 <20250123234415.59850-9-philmd@linaro.org>
Content-Language: en-US
From: Richard Henderson <richard.henderson@linaro.org>
In-Reply-To: <20250123234415.59850-9-philmd@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 1/23/25 15:44, Philippe Mathieu-Daudé wrote:
> Move CPU TLB related methods to accel/tcg/ scope,
> in "internal-common.h".
> 
> Suggested-by: Richard Henderson<richard.henderson@linaro.org>
> Reviewed-by: Pierrick Bouvier<pierrick.bouvier@linaro.org>
> Signed-off-by: Philippe Mathieu-Daudé<philmd@linaro.org>
> ---
>   accel/tcg/internal-common.h | 11 +++++++++++
>   include/exec/exec-all.h     | 16 ----------------
>   accel/tcg/user-exec-stub.c  | 11 +++++++++++
>   3 files changed, 22 insertions(+), 16 deletions(-)

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~


From xen-devel-bounces@lists.xenproject.org Sun Jan 26 20:34:31 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Jan 2025 20:34:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877269.1287400 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tc9Kw-0002LX-B1; Sun, 26 Jan 2025 20:34:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877269.1287400; Sun, 26 Jan 2025 20:34:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tc9Kw-0002LQ-7a; Sun, 26 Jan 2025 20:34:30 +0000
Received: by outflank-mailman (input) for mailman id 877269;
 Sun, 26 Jan 2025 20:34:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Vl/L=US=linaro.org=richard.henderson@srs-se1.protection.inumbo.net>)
 id 1tc9Ku-0002LI-Mc
 for xen-devel@lists.xenproject.org; Sun, 26 Jan 2025 20:34:28 +0000
Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com
 [2607:f8b0:4864:20::102a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ef984a56-dc24-11ef-a0e6-8be0dac302b0;
 Sun, 26 Jan 2025 21:34:27 +0100 (CET)
Received: by mail-pj1-x102a.google.com with SMTP id
 98e67ed59e1d1-2f4409fc8fdso5711905a91.1
 for <xen-devel@lists.xenproject.org>; Sun, 26 Jan 2025 12:34:27 -0800 (PST)
Received: from [192.168.0.4] (174-21-71-127.tukw.qwest.net. [174.21.71.127])
 by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-2f7ffaf8b27sm5519409a91.37.2025.01.26.12.34.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 26 Jan 2025 12:34:25 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ef984a56-dc24-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737923666; x=1738528466; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=HV0rFwm2c/DiJ3VIFDuxU64dDw12Xibjr9C6hrIuIZM=;
        b=E41ZbYGAgfvpd8ve17OwbRlNK+Je79yrbsF36aliJvhlbu/KxYEMX77AXPg0GW9Qel
         dVYWD7x9S83eOZkDQFi9KOphDXExXO61oVfpur62pUvPjh1I52JnLnIUMWQ1t/5bX8Lo
         F4rISFQX4KEJWQqmk9qPLYHT3fJyFZhD+c5iq0UoXWuoThMwpyY+azffYwzg8+iKvQ/w
         /9jVsgkqbLHr3j51plodmfzfWPkDiYqMmzNI12NmTVEcPSTt/rMeoVbB2ndO+3ydBPhb
         kca8frmoFCxcClb91YY1UoiDrOs19c925oUhxVjdtb8Zbbo5rbk1Scv+Xa3DMJOU/wq8
         rMGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737923666; x=1738528466;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=HV0rFwm2c/DiJ3VIFDuxU64dDw12Xibjr9C6hrIuIZM=;
        b=w/HNB+1RoGxnQsCAXHeVPa0lcVeAtzXNM5mCXoVNNTS8FgEdzt4gZbdMI0AD9EjTnI
         1pjewo/k5HJJyy3GcOfM2jzfMTMeocmYp/OPNiOKeZHhkjealMKfcfGhLs6kY2byTGAy
         sBgYCEgZ1PtwY8dhrmeN7gpBcRqdt5lTc7/SVACsAdZAi1SjTFus/84rZtsELD2tBETR
         zDwOrW+C1j3vE7hhEijlo6p2MBsLeYq4SbNjXiMO8IiBDbPL+Y6qokRYIhPrKXu+azI2
         lwi8i/7nAa5j3IEiXsRbdhNTGwLl/h6prD9yZPB9DQOUiZMp8/qSpt/6NpAmTE2zFRoe
         +ujw==
X-Forwarded-Encrypted: i=1; AJvYcCW35okzgSlQLFqJMSLHts+9pug7IErstLVXchTjSxFhwou7RbdhcAoUPDbHEJiO64zLglm+tAlWZIE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwyIfuTsin4j02GP67GjWin2jFPGk/MoQdFKui4tYnGim+2x13M
	XvnS5t4C1jP45mwhYODtrUZ7Fz7o0a1SrP8WeeOVjJQes7KBzE9XYwx8/lUGiZk=
X-Gm-Gg: ASbGncteZ0atWMeAABv3YyX/qrvDCifOQc9WcYO4WG9tSjNse70TE26M7H7dmz8xeMx
	0FrtMlj7Y3wXa6cl3+rhhcwR2QJL6GZ/rvnciuugzMAnvWqogt9ve/NfT85Zzkc2uqc3MxB7UB9
	6UeO8vBwwYwu7N601ufrxdJU4OR2znTWXn6m8UkKwBB0b3YtZd9A+ltTbuKgaA/Z2NJErqILKA0
	deEGnQRXgI0fHUayXJTtqZdZoeYHOGyuPsBs7T5tXbXpBl6Mi9FLb0wabY+FEWc5/r2d9rcqfY3
	YgOueSGXgs3zRoaDp/YFQToXwxi/ooFS7lHEh7/8WPr62/M=
X-Google-Smtp-Source: AGHT+IEnuvCpks4R8m2CWUAxXqy7OUK3I7qmzF32T6Ls9afPXbIvlOOo7wFmoCIeuE1afURwxObJ8g==
X-Received: by 2002:a17:90b:5488:b0:2ee:7e53:bfae with SMTP id 98e67ed59e1d1-2f7f177c6b3mr23097382a91.10.1737923666307;
        Sun, 26 Jan 2025 12:34:26 -0800 (PST)
Message-ID: <2641e9da-db13-490e-9bae-64ecde1f9352@linaro.org>
Date: Sun, 26 Jan 2025 12:34:24 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 09/20] accel/tcg: Restrict 'icount_align_option' global to
 TCG
To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= <philmd@linaro.org>,
 qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
 Paolo Bonzini <pbonzini@redhat.com>, qemu-arm@nongnu.org,
 Igor Mammedov <imammedo@redhat.com>, =?UTF-8?Q?Alex_Benn=C3=A9e?=
 <alex.bennee@linaro.org>, kvm@vger.kernel.org, qemu-ppc@nongnu.org,
 qemu-riscv@nongnu.org, David Hildenbrand <david@redhat.com>,
 qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org
References: <20250123234415.59850-1-philmd@linaro.org>
 <20250123234415.59850-10-philmd@linaro.org>
Content-Language: en-US
From: Richard Henderson <richard.henderson@linaro.org>
In-Reply-To: <20250123234415.59850-10-philmd@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 1/23/25 15:44, Philippe Mathieu-Daudé wrote:
> Since commit 740b1759734 ("cpu-timers, icount: new modules")
> we don't need to expose icount_align_option to all the
> system code, we can restrict it to TCG. Since it is used as
> a boolean, declare it as 'bool' type.
> 
> Signed-off-by: Philippe Mathieu-Daudé<philmd@linaro.org>
> ---
>   accel/tcg/internal-common.h | 2 ++
>   include/system/cpus.h       | 2 --
>   accel/tcg/icount-common.c   | 2 ++
>   system/globals.c            | 1 -
>   4 files changed, 4 insertions(+), 3 deletions(-)

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~


From xen-devel-bounces@lists.xenproject.org Sun Jan 26 20:36:52 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Jan 2025 20:36:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877277.1287409 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tc9ND-0002tz-MZ; Sun, 26 Jan 2025 20:36:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877277.1287409; Sun, 26 Jan 2025 20:36:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tc9ND-0002ts-Jt; Sun, 26 Jan 2025 20:36:51 +0000
Received: by outflank-mailman (input) for mailman id 877277;
 Sun, 26 Jan 2025 20:36:51 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Vl/L=US=linaro.org=richard.henderson@srs-se1.protection.inumbo.net>)
 id 1tc9NC-0002th-Vq
 for xen-devel@lists.xenproject.org; Sun, 26 Jan 2025 20:36:50 +0000
Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com
 [2607:f8b0:4864:20::62c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 43cfd0a7-dc25-11ef-99a4-01e77a169b0f;
 Sun, 26 Jan 2025 21:36:49 +0100 (CET)
Received: by mail-pl1-x62c.google.com with SMTP id
 d9443c01a7336-2161eb94cceso44373175ad.2
 for <xen-devel@lists.xenproject.org>; Sun, 26 Jan 2025 12:36:49 -0800 (PST)
Received: from [192.168.0.4] (174-21-71-127.tukw.qwest.net. [174.21.71.127])
 by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-72f8a6b18b5sm5645530b3a.39.2025.01.26.12.36.46
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 26 Jan 2025 12:36:47 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 43cfd0a7-dc25-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737923807; x=1738528607; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=g2WeP5q4hv+K1Hr21O956YlU/gBG9YtJDHMFPAKuFc4=;
        b=QEt1SpT0VtBkL2hZ85IaRNu0Maypq2iNdmwVLvx2v6o5ZPXF6f9Oc5hOK9V4xdLoTI
         QokCQk4qDhltNpFuhbCmMfsIuJ6rOJCem2OHVRMrZvGgR5vyMjKGJoVmz0JIjx/2jKu4
         kILVQ5eegQGNM7SAYIbYlbJmopFEIaceHSIE/wtTPyJPyz3v0TPtCzrJHbXO3dYzvs4A
         V0AxDQU5ccSbsgP8Pu4jfxF8uMI8+FfirlJGbYUZV4TUQq2YH3hm3Mkxsl07GbVUCwQP
         097B8lCM/Kr3Od2Z4KhniEUj4RMqgeEDikk17pAaBfbA4legl5ldeJMX7InxHbAj5yKJ
         1NAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737923807; x=1738528607;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=g2WeP5q4hv+K1Hr21O956YlU/gBG9YtJDHMFPAKuFc4=;
        b=j+2Z4nHjQiWLwgua8P3pgXo/0VeDyw856YXHLkERmFNAQZB+XkJmuEN2NKiVGnRczK
         CDRF8KJzNuLZvypq4dW5FznNqhfePIxqUBnXJJ3DgVjFmfs3Fniraw/mJeCJ3m1MEzFr
         31p+v0JH6jmqI62x0Pq6cIcOO+80WmTOiPVtzPuNJMx/Xbs4d2Glz5lo4CIOcDb1cWkh
         e7zaZUIumQ02g47r9CyQnZwzR+wNXu5vwQ2cNwLYdqCo0E3PJVc8U3xdiOpuzHCP+IAo
         2WRfnaUXX/eqvT9WN0nKNUpuxMRQLfRdWy2Rv7vaEgSSiNld85H43dC9v3bUeCPhFCx1
         Ly7A==
X-Forwarded-Encrypted: i=1; AJvYcCXDWU2MELgxWkpfydnCjoIcv15Hdz4zCRBcPlM8InlYcpmzH5y41dCu+RmofOnRVju4u9p0m4g6MyA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzZNjHcwLw+/kDybamOg8BHygDDal+CkjJlp8kiVfn1aaj/lNox
	cEpKPCgcVvoj0fG7t0OU+kT2j0Ry/l784QIJXgcHcXgaqoeQGaZ5cH4pm+LFk48=
X-Gm-Gg: ASbGncth5U42uW6kWQ4+xJsinHLKUA9g/KuTrg+HcVI/9gq22rt/sFvSR1wLybPdSN9
	wV7nBcCu9QDOeiThA+2jUW7K/29atFa0A7ySv97/H0fVxGhr1krCUG9EiTFciSoKwCDKOh97Dix
	53kV/wN09WVfZNDG5egtTF4ArksF6MnHsTjyc90bAe6ysWDgD1Prut+Xy7F8um+d6jY72yt9J5V
	R6z5nxmllKQ1YZQlmd5ZfLaIH0waOGURamdZlDp4Dk1MKZlccPqjFe5u8hfsX0K1vrZVH9ja5ev
	Yt/Y6FiwnHRzgm0H/DJUIjXy+OPe29CRvjXNzq9L9798g0M=
X-Google-Smtp-Source: AGHT+IG7QHEN6N12IEj7HpZ8+9ISOfMpvPDzHND+sb7CKsQVCW2Siz1JbFKV0CJ4CarsM9/PXCPftw==
X-Received: by 2002:a05:6a20:2447:b0:1e0:ce11:b0ce with SMTP id adf61e73a8af0-1eb215adabfmr66485176637.35.1737923807521;
        Sun, 26 Jan 2025 12:36:47 -0800 (PST)
Message-ID: <d81542e9-bebf-4f5f-a911-8ab7b6180d4e@linaro.org>
Date: Sun, 26 Jan 2025 12:36:45 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 10/20] accel/tcg: Rename 'hw/core/tcg-cpu-ops.h' ->
 'accel/tcg/cpu-ops.h'
To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= <philmd@linaro.org>,
 qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
 Paolo Bonzini <pbonzini@redhat.com>, qemu-arm@nongnu.org,
 Igor Mammedov <imammedo@redhat.com>, =?UTF-8?Q?Alex_Benn=C3=A9e?=
 <alex.bennee@linaro.org>, kvm@vger.kernel.org, qemu-ppc@nongnu.org,
 qemu-riscv@nongnu.org, David Hildenbrand <david@redhat.com>,
 qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org
References: <20250123234415.59850-1-philmd@linaro.org>
 <20250123234415.59850-11-philmd@linaro.org>
Content-Language: en-US
From: Richard Henderson <richard.henderson@linaro.org>
In-Reply-To: <20250123234415.59850-11-philmd@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 1/23/25 15:44, Philippe Mathieu-Daudé wrote:
> TCGCPUOps structure makes more sense in the accelerator context
> rather than hardware emulation. Move it under the accel/tcg/ scope.
> 
> Mechanical change doing:
> 
>   $  sed -i -e 's,hw/core/tcg-cpu-ops.h,accel/tcg/cpu-ops.h,g' \
>     $(git grep -l hw/core/tcg-cpu-ops.h)
> 
> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> ---
>   MAINTAINERS                                            | 2 +-
>   include/{hw/core/tcg-cpu-ops.h => accel/tcg/cpu-ops.h} | 0
>   accel/tcg/cpu-exec.c                                   | 4 ++--
>   accel/tcg/cputlb.c                                     | 2 +-
>   accel/tcg/translate-all.c                              | 2 +-
>   accel/tcg/user-exec.c                                  | 2 +-
>   accel/tcg/watchpoint.c                                 | 2 +-
>   bsd-user/signal.c                                      | 2 +-
>   hw/mips/jazz.c                                         | 2 +-
>   linux-user/signal.c                                    | 2 +-
>   system/physmem.c                                       | 2 +-
>   target/alpha/cpu.c                                     | 2 +-
>   target/arm/cpu.c                                       | 2 +-
>   target/arm/tcg/cpu-v7m.c                               | 2 +-
>   target/arm/tcg/cpu32.c                                 | 2 +-
>   target/arm/tcg/mte_helper.c                            | 2 +-
>   target/arm/tcg/sve_helper.c                            | 2 +-
>   target/avr/cpu.c                                       | 2 +-
>   target/avr/helper.c                                    | 2 +-
>   target/hexagon/cpu.c                                   | 2 +-
>   target/hppa/cpu.c                                      | 2 +-
>   target/i386/tcg/tcg-cpu.c                              | 2 +-
>   target/loongarch/cpu.c                                 | 2 +-
>   target/m68k/cpu.c                                      | 2 +-
>   target/microblaze/cpu.c                                | 2 +-
>   target/mips/cpu.c                                      | 2 +-
>   target/openrisc/cpu.c                                  | 2 +-
>   target/ppc/cpu_init.c                                  | 2 +-
>   target/riscv/tcg/tcg-cpu.c                             | 2 +-
>   target/rx/cpu.c                                        | 2 +-
>   target/s390x/cpu.c                                     | 2 +-
>   target/s390x/tcg/mem_helper.c                          | 2 +-
>   target/sh4/cpu.c                                       | 2 +-
>   target/sparc/cpu.c                                     | 2 +-
>   target/tricore/cpu.c                                   | 2 +-
>   target/xtensa/cpu.c                                    | 2 +-
>   36 files changed, 36 insertions(+), 36 deletions(-)
>   rename include/{hw/core/tcg-cpu-ops.h => accel/tcg/cpu-ops.h} (100%)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7be3d8f431a..fa46d077d30 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -175,7 +175,7 @@ F: include/exec/helper-info.c.inc
>   F: include/exec/page-protection.h
>   F: include/system/cpus.h
>   F: include/system/tcg.h
> -F: include/hw/core/tcg-cpu-ops.h
> +F: include/accel/tcg/cpu-ops.h
>   F: host/include/*/host/cpuinfo.h
>   F: util/cpuinfo-*.c
>   F: include/tcg/
> diff --git a/include/hw/core/tcg-cpu-ops.h b/include/accel/tcg/cpu-ops.h
> similarity index 100%
> rename from include/hw/core/tcg-cpu-ops.h
> rename to include/accel/tcg/cpu-ops.h
> diff --git a/accel/tcg/cpu-exec.c b/accel/tcg/cpu-exec.c
> index be2ba199d3d..8ee76e14b0d 100644
> --- a/accel/tcg/cpu-exec.c
> +++ b/accel/tcg/cpu-exec.c
> @@ -22,7 +22,7 @@
>   #include "qapi/error.h"
>   #include "qapi/type-helpers.h"
>   #include "hw/core/cpu.h"
> -#include "hw/core/tcg-cpu-ops.h"
> +#include "accel/tcg/cpu-ops.h"
>   #include "trace.h"
>   #include "disas/disas.h"
>   #include "exec/cpu-common.h"
> @@ -39,7 +39,7 @@
>   #include "exec/replay-core.h"
>   #include "system/tcg.h"
>   #include "exec/helper-proto-common.h"
> -#include "tb-jmp-cache.h"
> +//#include "tb-jmp-cache.h"

What's this?


r~


From xen-devel-bounces@lists.xenproject.org Sun Jan 26 20:38:22 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Jan 2025 20:38:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877285.1287420 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tc9Od-0003Pw-0K; Sun, 26 Jan 2025 20:38:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877285.1287420; Sun, 26 Jan 2025 20:38:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tc9Oc-0003Pp-TT; Sun, 26 Jan 2025 20:38:18 +0000
Received: by outflank-mailman (input) for mailman id 877285;
 Sun, 26 Jan 2025 20:38: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
 <SRS0=Vl/L=US=linaro.org=richard.henderson@srs-se1.protection.inumbo.net>)
 id 1tc9Oc-0003Pj-9L
 for xen-devel@lists.xenproject.org; Sun, 26 Jan 2025 20:38:18 +0000
Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com
 [2607:f8b0:4864:20::630])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 77da9359-dc25-11ef-99a4-01e77a169b0f;
 Sun, 26 Jan 2025 21:38:16 +0100 (CET)
Received: by mail-pl1-x630.google.com with SMTP id
 d9443c01a7336-2166651f752so72222305ad.3
 for <xen-devel@lists.xenproject.org>; Sun, 26 Jan 2025 12:38:16 -0800 (PST)
Received: from [192.168.0.4] (174-21-71-127.tukw.qwest.net. [174.21.71.127])
 by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-21da3d9b8e0sm50214325ad.40.2025.01.26.12.38.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 26 Jan 2025 12:38:14 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 77da9359-dc25-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737923895; x=1738528695; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:content-language:references
         :cc:to:from:subject:user-agent:mime-version:date:message-id:from:to
         :cc:subject:date:message-id:reply-to;
        bh=HVPb45ZdRMqIKUAi6GudayI0aNfKV1cv8oTD0Mxltf8=;
        b=H2fkLTO/f8gudljL5nqj5KWCCQ1hXXm6kWZXB9ZXG/Q3OonKW2X9LfDOO/bHZcFpgh
         vvr0xcmDZBtEViKFgj8R5bNMdcuCmU24gB5ZDnQdQV+iCdcZfGC7NGvPC1teY1OP2urm
         W49GwN1ZGEHvTa5Pe0waNdv4DQUQAZapsefHvkW2rH693Fams+vOnuHQ4BpNHSS9imCM
         j0Kd0yMlZGJ2UBTRaHmKorFCiNoeGkicUsc9s7wfmbhc2qsf1vhF75xk9j6dTj/HkoOp
         dJ5nKx3N7bwj6hjTksIun8I6F5aoP9VxuyLh8MhJfie3C9REI+oNzwiHyU0sMoUD9AG1
         79NQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737923895; x=1738528695;
        h=content-transfer-encoding:in-reply-to:content-language:references
         :cc:to:from:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=HVPb45ZdRMqIKUAi6GudayI0aNfKV1cv8oTD0Mxltf8=;
        b=S7J2hgiWg0LZOQBTDZ3VlbxWlIhD28+wjqkokmQciOSoMs4Eu3p/pw4lKhliSvd26+
         rjjPGup1Cv/qX+Q5C9N59jwRaORPfhJboteIsC2sZS86TSrn75asVgKVRde3Q06SKnQb
         /QtAM7RZMrmP/xH4AH5jdyuMyTDsDvGeHhswbFgrLeMggmOwt3zcNIe7phg4VZSrjMRr
         rNnGxm3R66eyMJJnF9phPp7Rpdpgc7rIlfJigWmvHDz21/5nJL1aIJEcTeSWc5/9pVtg
         sD6kTb7C6ll6J/YsxEuxeigQSbhLtYLUEXDgY0QgjcXYVla6q08tbWlrxtKm2fU7QGyL
         Uwfw==
X-Forwarded-Encrypted: i=1; AJvYcCWNoDm4I4lro5DcOlRPk5SafnpEaJi3eD3tr2OkwGf96I6Kf2Yuua9bEouYzE5lHu4zoDUGOCbcKXs=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx+aeQBjVge/t0kYvI5RtP/14mBmhULVbS8mv5OlTNw9QLWkGtb
	FAdp0sikel8CoshIIHRj0K4T/i7h7V88ipSbf8qFvAaaI09PJJwher8fvb/MCiQ=
X-Gm-Gg: ASbGnctSIXHBZcP3z32HuBnQCo6SwfISWaQdNd5XPVDsLB7rmQuHv57qfqmhTMbiHX3
	iU07IYnacWh63rvRcywcsgdL/m+EH57JoMRviih1ZK09cDdUVbM03tbV9+LlLQ0c8x6OJ3PdgMh
	yhG5w5pjAESK8HYlpmhFa5QLJve2e+dVXpIUOKlXgWACEefS91FxsqcjAFzJkhBcwP+naIl3cdj
	N18t5TfTpHjPy7SI1FxC/JHojCkjqoDaTPCYxnmnq3PxirdYxlRWw0rNP0yic3E7QQvAG0i99nK
	rB9Hz4a7p7wPJtrleXwwC3R9ujmSMjnteNvTlFlcEwoLKig=
X-Google-Smtp-Source: AGHT+IFHGSYkE2gK8J+M4s6UHrhYt2yFRPQZ8hFQm3oPTcuYK/Fs6x7qFNLpzA/inMpx9KuBn36otA==
X-Received: by 2002:a17:903:41c3:b0:216:61d2:46b8 with SMTP id d9443c01a7336-21c3555eb72mr575490595ad.23.1737923894867;
        Sun, 26 Jan 2025 12:38:14 -0800 (PST)
Message-ID: <36f6337f-f076-44df-bbb0-29290a010b1a@linaro.org>
Date: Sun, 26 Jan 2025 12:38:12 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 10/20] accel/tcg: Rename 'hw/core/tcg-cpu-ops.h' ->
 'accel/tcg/cpu-ops.h'
From: Richard Henderson <richard.henderson@linaro.org>
To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= <philmd@linaro.org>,
 qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
 Paolo Bonzini <pbonzini@redhat.com>, qemu-arm@nongnu.org,
 Igor Mammedov <imammedo@redhat.com>, =?UTF-8?Q?Alex_Benn=C3=A9e?=
 <alex.bennee@linaro.org>, kvm@vger.kernel.org, qemu-ppc@nongnu.org,
 qemu-riscv@nongnu.org, David Hildenbrand <david@redhat.com>,
 qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org
References: <20250123234415.59850-1-philmd@linaro.org>
 <20250123234415.59850-11-philmd@linaro.org>
 <d81542e9-bebf-4f5f-a911-8ab7b6180d4e@linaro.org>
Content-Language: en-US
In-Reply-To: <d81542e9-bebf-4f5f-a911-8ab7b6180d4e@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 1/26/25 12:36, Richard Henderson wrote:
> On 1/23/25 15:44, Philippe Mathieu-Daudé wrote:
>> TCGCPUOps structure makes more sense in the accelerator context
>> rather than hardware emulation. Move it under the accel/tcg/ scope.
>>
>> Mechanical change doing:
>>
>>   $  sed -i -e 's,hw/core/tcg-cpu-ops.h,accel/tcg/cpu-ops.h,g' \
>>     $(git grep -l hw/core/tcg-cpu-ops.h)
>>
>> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
>> ---
>>   MAINTAINERS                                            | 2 +-
>>   include/{hw/core/tcg-cpu-ops.h => accel/tcg/cpu-ops.h} | 0
>>   accel/tcg/cpu-exec.c                                   | 4 ++--
>>   accel/tcg/cputlb.c                                     | 2 +-
>>   accel/tcg/translate-all.c                              | 2 +-
>>   accel/tcg/user-exec.c                                  | 2 +-
>>   accel/tcg/watchpoint.c                                 | 2 +-
>>   bsd-user/signal.c                                      | 2 +-
>>   hw/mips/jazz.c                                         | 2 +-
>>   linux-user/signal.c                                    | 2 +-
>>   system/physmem.c                                       | 2 +-
>>   target/alpha/cpu.c                                     | 2 +-
>>   target/arm/cpu.c                                       | 2 +-
>>   target/arm/tcg/cpu-v7m.c                               | 2 +-
>>   target/arm/tcg/cpu32.c                                 | 2 +-
>>   target/arm/tcg/mte_helper.c                            | 2 +-
>>   target/arm/tcg/sve_helper.c                            | 2 +-
>>   target/avr/cpu.c                                       | 2 +-
>>   target/avr/helper.c                                    | 2 +-
>>   target/hexagon/cpu.c                                   | 2 +-
>>   target/hppa/cpu.c                                      | 2 +-
>>   target/i386/tcg/tcg-cpu.c                              | 2 +-
>>   target/loongarch/cpu.c                                 | 2 +-
>>   target/m68k/cpu.c                                      | 2 +-
>>   target/microblaze/cpu.c                                | 2 +-
>>   target/mips/cpu.c                                      | 2 +-
>>   target/openrisc/cpu.c                                  | 2 +-
>>   target/ppc/cpu_init.c                                  | 2 +-
>>   target/riscv/tcg/tcg-cpu.c                             | 2 +-
>>   target/rx/cpu.c                                        | 2 +-
>>   target/s390x/cpu.c                                     | 2 +-
>>   target/s390x/tcg/mem_helper.c                          | 2 +-
>>   target/sh4/cpu.c                                       | 2 +-
>>   target/sparc/cpu.c                                     | 2 +-
>>   target/tricore/cpu.c                                   | 2 +-
>>   target/xtensa/cpu.c                                    | 2 +-
>>   36 files changed, 36 insertions(+), 36 deletions(-)
>>   rename include/{hw/core/tcg-cpu-ops.h => accel/tcg/cpu-ops.h} (100%)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 7be3d8f431a..fa46d077d30 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -175,7 +175,7 @@ F: include/exec/helper-info.c.inc
>>   F: include/exec/page-protection.h
>>   F: include/system/cpus.h
>>   F: include/system/tcg.h
>> -F: include/hw/core/tcg-cpu-ops.h
>> +F: include/accel/tcg/cpu-ops.h
>>   F: host/include/*/host/cpuinfo.h
>>   F: util/cpuinfo-*.c
>>   F: include/tcg/
>> diff --git a/include/hw/core/tcg-cpu-ops.h b/include/accel/tcg/cpu-ops.h
>> similarity index 100%
>> rename from include/hw/core/tcg-cpu-ops.h
>> rename to include/accel/tcg/cpu-ops.h
>> diff --git a/accel/tcg/cpu-exec.c b/accel/tcg/cpu-exec.c
>> index be2ba199d3d..8ee76e14b0d 100644
>> --- a/accel/tcg/cpu-exec.c
>> +++ b/accel/tcg/cpu-exec.c
>> @@ -22,7 +22,7 @@
>>   #include "qapi/error.h"
>>   #include "qapi/type-helpers.h"
>>   #include "hw/core/cpu.h"
>> -#include "hw/core/tcg-cpu-ops.h"
>> +#include "accel/tcg/cpu-ops.h"
>>   #include "trace.h"
>>   #include "disas/disas.h"
>>   #include "exec/cpu-common.h"
>> @@ -39,7 +39,7 @@
>>   #include "exec/replay-core.h"
>>   #include "system/tcg.h"
>>   #include "exec/helper-proto-common.h"
>> -#include "tb-jmp-cache.h"
>> +//#include "tb-jmp-cache.h"
> 
> What's this?

Aside from this,
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>


r~


From xen-devel-bounces@lists.xenproject.org Sun Jan 26 20:39:42 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Jan 2025 20:39:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877292.1287430 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tc9Px-0003y6-B7; Sun, 26 Jan 2025 20:39:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877292.1287430; Sun, 26 Jan 2025 20: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 <xen-devel-bounces@lists.xenproject.org>)
	id 1tc9Px-0003xz-6p; Sun, 26 Jan 2025 20:39:41 +0000
Received: by outflank-mailman (input) for mailman id 877292;
 Sun, 26 Jan 2025 20:39: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
 <SRS0=Vl/L=US=linaro.org=richard.henderson@srs-se1.protection.inumbo.net>)
 id 1tc9Pw-0003xp-2v
 for xen-devel@lists.xenproject.org; Sun, 26 Jan 2025 20:39:40 +0000
Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com
 [2607:f8b0:4864:20::630])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a939ae1c-dc25-11ef-a0e6-8be0dac302b0;
 Sun, 26 Jan 2025 21:39:39 +0100 (CET)
Received: by mail-pl1-x630.google.com with SMTP id
 d9443c01a7336-2164b662090so71697385ad.1
 for <xen-devel@lists.xenproject.org>; Sun, 26 Jan 2025 12:39:39 -0800 (PST)
Received: from [192.168.0.4] (174-21-71-127.tukw.qwest.net. [174.21.71.127])
 by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-ac48f897f8dsm4913213a12.22.2025.01.26.12.39.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 26 Jan 2025 12:39:37 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a939ae1c-dc25-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737923978; x=1738528778; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=MvjpRtAdSgDSzkYfmgpR6A/dBIEK8m+/NiOGB5xZ+o4=;
        b=yeAirxMnIZ4echnzc5/x/nDAQacZlc6ss0ApwPwGu8ljVKmIPskdoZ7GGvlpJrzoYZ
         wp8jZh8BumRyzWCD71icuq8nQ8ZLeWWCY59X72uNA9f5YVpA3g6om5Z6PirhS3UTcddQ
         WqoPjZRuF7lOJVNVudAf/l+UAvF5bTU0PlyF9N7NQFlYRd1Z16iDd2pBevF5pQCC69cu
         PQ1KVgkdN0d67gjac73hUid3eK9GutiyWsuyRFvFKxIUkm+ZfE9El4GKc+mIb16PSuPe
         sERvErlf9ORCN43rZqVIwzbwH647z8gNJ+NdKg0OkDjgkRL7xDD7IlVliwyicPOHaDib
         jONg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737923978; x=1738528778;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=MvjpRtAdSgDSzkYfmgpR6A/dBIEK8m+/NiOGB5xZ+o4=;
        b=vkY+kNF8a1Kd8y0nERSQOyiTVWwD8GoBmCJve6/vp43FK82kN+ZK7DyXBmHXu9LIm3
         8+0srfemDxmZZbp0liD2pGV1NL5X6n8NW2zqkdsIWgzV9j841BfJ3qCrpzDs3VF/8DKn
         M83Yry7uvxtfNu2N5ye0yFT7UBTWnjxh1WfUGP8+u1UNR0VHuvHZ5qw92+aOL5kN3Ys3
         mfvUuD1HlhjrNqd6KkVy1ZJNbPtay+0qiOqKFbLsDMMZn/5ePT5h69RGFS1zBDBPolcz
         wFgxgUr2OKO/I53cNvq35n3wKfLTgU+t1c58A9177pM5lkhszRZqI7lhu3mnaG999tfU
         DYDQ==
X-Forwarded-Encrypted: i=1; AJvYcCW9D8XD6DSTOSoT0ZuoQo7TCJg1m2q0PAVLw7DnP9bt1tB5+JWL7CngxJxe/DUtejpH9CUDtGrBFd4=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw1aVs8vca9tmbqK35WsfadOKpZ/Ld/vUiy9KYDCL8aqJExBRqG
	WAPp83y6X+ttKWSpgvJb23ob5QqF7ViN5UpR5B+PL1krgISlsFLt6zyWCN6+3E4=
X-Gm-Gg: ASbGnctOMCCfeR7I8bax+nEgRbe2tpeOnNZHOz8cUCvpXb0+n7RCYws+Hm0TKXk2TXy
	V6/yj27yht9hTG2xSL7oVN3sDLnO+HwOrkoaATDKPaaBEYMEu/ZVQnIvMHDLDtsRg1lt4/1jR3u
	m1ho4FfF6LF0poDOnkLN88wnDila8gpy6cC7rXjz7vF/12xnd+f5bVciwJtLl37f8qr0Jb/DFDs
	BBob9Qprru1oLpA4ViNC9xhUQd+IElEXbP5czylYhEsoHe/QZc2Kxeq4ZywU/JHp3tR5ShigvbP
	ETIv3+UIN5vLFcvTgJgIS7Cz5iWVrFwlS7Q9Z3xcpO4p1xk=
X-Google-Smtp-Source: AGHT+IGm+ocgYvvkVWsUvSKMByg6rdOolrkUz0sM7TYcNoHM9kXNHQjPzT7fvMCLNswi1NUAED96dg==
X-Received: by 2002:a05:6a20:394b:b0:1e5:a0d8:5a33 with SMTP id adf61e73a8af0-1eb21480ef0mr65256986637.18.1737923977749;
        Sun, 26 Jan 2025 12:39:37 -0800 (PST)
Message-ID: <25ab2464-7878-4ade-89b5-1691f70736fc@linaro.org>
Date: Sun, 26 Jan 2025 12:39:35 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 11/20] accel: Rename 'hw/core/accel-cpu.h' ->
 'accel/accel-cpu-target.h'
To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= <philmd@linaro.org>,
 qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
 Paolo Bonzini <pbonzini@redhat.com>, qemu-arm@nongnu.org,
 Igor Mammedov <imammedo@redhat.com>, =?UTF-8?Q?Alex_Benn=C3=A9e?=
 <alex.bennee@linaro.org>, kvm@vger.kernel.org, qemu-ppc@nongnu.org,
 qemu-riscv@nongnu.org, David Hildenbrand <david@redhat.com>,
 qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org
References: <20250123234415.59850-1-philmd@linaro.org>
 <20250123234415.59850-12-philmd@linaro.org>
Content-Language: en-US
From: Richard Henderson <richard.henderson@linaro.org>
In-Reply-To: <20250123234415.59850-12-philmd@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 1/23/25 15:44, Philippe Mathieu-Daudé wrote:
> AccelCPUClass is for accelerator to initialize target specific
> features of a vCPU. Not really related to hardware emulation,
> rename "hw/core/accel-cpu.h" as "accel/accel-cpu-target.h"
> (using the explicit -target suffix).
> 
> More importantly, target specific header often access the
> target specific definitions which are in each target/FOO/cpu.h
> header, usually included generically as "cpu.h" relative to
> target/FOO/. However, there is already a "cpu.h" in hw/core/
> which takes precedence. This change allows "accel-cpu-target.h"
> to include a target "cpu.h".
> 
> Mechanical change doing:
> 
>   $  git mv include/hw/core/accel-cpu.h \
>             include/accel/accel-cpu-target.h
>   $  sed -i -e 's,hw/core/accel-cpu.h,accel/accel-cpu-target.h,' \
>     $(git grep -l hw/core/accel-cpu.h)
> 
> and renaming header guard 'ACCEL_CPU_TARGET_H'.
> 
> Signed-off-by: Philippe Mathieu-Daudé<philmd@linaro.org>
> ---
>   MAINTAINERS                                               | 2 +-
>   include/{hw/core/accel-cpu.h => accel/accel-cpu-target.h} | 4 ++--
>   accel/accel-target.c                                      | 2 +-
>   cpu-target.c                                              | 2 +-
>   target/i386/hvf/hvf-cpu.c                                 | 2 +-
>   target/i386/kvm/kvm-cpu.c                                 | 2 +-
>   target/i386/tcg/tcg-cpu.c                                 | 2 +-
>   target/ppc/kvm.c                                          | 2 +-
>   target/riscv/kvm/kvm-cpu.c                                | 2 +-
>   target/riscv/tcg/tcg-cpu.c                                | 2 +-
>   10 files changed, 11 insertions(+), 11 deletions(-)
>   rename include/{hw/core/accel-cpu.h => accel/accel-cpu-target.h} (95%)

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~


From xen-devel-bounces@lists.xenproject.org Sun Jan 26 20:40:40 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Jan 2025 20:40:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877303.1287440 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tc9Qu-0005Ut-Mx; Sun, 26 Jan 2025 20:40:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877303.1287440; Sun, 26 Jan 2025 20:40:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tc9Qu-0005Um-K8; Sun, 26 Jan 2025 20:40:40 +0000
Received: by outflank-mailman (input) for mailman id 877303;
 Sun, 26 Jan 2025 20:40: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
 <SRS0=Vl/L=US=linaro.org=richard.henderson@srs-se1.protection.inumbo.net>)
 id 1tc9Qt-0005TR-6h
 for xen-devel@lists.xenproject.org; Sun, 26 Jan 2025 20:40:39 +0000
Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com
 [2607:f8b0:4864:20::102a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id cc706053-dc25-11ef-a0e6-8be0dac302b0;
 Sun, 26 Jan 2025 21:40:38 +0100 (CET)
Received: by mail-pj1-x102a.google.com with SMTP id
 98e67ed59e1d1-2f42992f608so5244945a91.0
 for <xen-devel@lists.xenproject.org>; Sun, 26 Jan 2025 12:40:38 -0800 (PST)
Received: from [192.168.0.4] (174-21-71-127.tukw.qwest.net. [174.21.71.127])
 by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-2f7ffa44cc3sm5572845a91.10.2025.01.26.12.40.35
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 26 Jan 2025 12:40:36 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: cc706053-dc25-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737924037; x=1738528837; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=8IakMPE25WQo15H6bcZ/5DvSR8Tj+5m00/ec4213Klk=;
        b=AducoIZIGdzNaOtsZ4VSoE9KZTFw3jgUS6CJAdYcLFSDJL3MuefmywHTvdx6Xt2JAZ
         eqKTyQt+t1rhts5VjschtiIwh3bjCz0KYNb7Clua3mUUnCCyxy3hmgUfxh+ja4Ltg2pJ
         R3HL5iX84hm4hL2wUJKQw6suE6bYVUtHxFZfsV64nMnviSpIdWAjfXtk3CGvHPldYrIx
         5mD2ehF61D0tlRP5mxI4uJNqkR63qJaPkIvhiJlRyJzXiCIXXfJOZp9+YlPWZmcpE/Rr
         ijBgZYYgz1SYP0ZtQXayC3GZVpp/QftZvJ4t0gbtcorJTvZ8H83/Ykm2Nvm9j6cru0CW
         QmoA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737924037; x=1738528837;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=8IakMPE25WQo15H6bcZ/5DvSR8Tj+5m00/ec4213Klk=;
        b=j5U/akTqG985jb0grRge97VjdQHQ79QL6vSzwyK/lAYaUofYRHZfG8HESqVgQ6gtiH
         ++dLL+kDDY0Llksg1y1L3jj1m347VAp+S7TxVKCTAHU5tBIXNWtJdpDoTAmsBu1kmd3c
         IexmeHwmKmp29ALLV+6LJ4p7aL6yp2s32vg7sM+bzaBjrRqL5381Tw2pf7H5e5EFUtct
         MteBHmE6W6hIzhEC8c25FOr7EkJFFVFFKbQ5pDRS0aV/wu2M4S/oq0QjQwgqmjkudn0i
         n/1kMCOHGKZHQVpL90evmJpGElXHi3nm9NS/1k4EIcz4aQ9T9JClv8VykNaZ9ANggDCR
         KymA==
X-Forwarded-Encrypted: i=1; AJvYcCUD17xKO6heJVrk9sqPu5idWIB7eZM44OY9aZUVE4XzIrGclrP87IKZKryv7wDYX1cgqTYGa0kO5mQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyGIpnHq2kGGf/opnL6kp9ozfH5FlPaC3ZiB2u+N7levYpuPYhx
	DmmmBo3ZiYd17VvX8ZU0oMWti8mZJzxosMyyVYJIV4P4WzW+JFvVu0/PBvg/PWQFWkvvWrSyI7X
	v
X-Gm-Gg: ASbGnctPAXp8Azooo45GOYKNl/oR9YgkICJSxM4Wi/y65II4+5vX/47L7GQduCKNMAt
	ARMHydGjaTgshK2vS4S049oeBh/DD4wpLm6Fo/rH4V8wF9HbKs791BcUYF8N5r87+A62IWWh28m
	fwRsFBfrgdnjgHNIu0R4bGGqE1F/zo1Jut/3ulVADpBCS63Lo0CtM0h8nHPl3EfY06R/JN7M4Sa
	EBegTQMq2JawfxsiyIeLxOEDWOl7inpXmcqphWg3IQd73ZT6G4PBEQnVcFIqFc5fGpeJBIjJCcW
	q9RPDAr/7673xugXpOS/do1vwA+pm9bycGd35zjCKWf7/V8=
X-Google-Smtp-Source: AGHT+IHFyv2iybW4GBn6ydLEZa4E4dxLUY4YPXTswHBeV0LQk9iq0lO2cyUKBRO3s8sCKps06u6bpg==
X-Received: by 2002:a17:90b:2c85:b0:2ee:4b8f:a5b1 with SMTP id 98e67ed59e1d1-2f782d30ecamr56371023a91.24.1737924036671;
        Sun, 26 Jan 2025 12:40:36 -0800 (PST)
Message-ID: <41f18203-efc6-43d5-90fa-ea20416ec01c@linaro.org>
Date: Sun, 26 Jan 2025 12:40:34 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 12/20] accel/accel-cpu-target.h: Include missing 'cpu.h'
 header
To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= <philmd@linaro.org>,
 qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
 Paolo Bonzini <pbonzini@redhat.com>, qemu-arm@nongnu.org,
 Igor Mammedov <imammedo@redhat.com>, =?UTF-8?Q?Alex_Benn=C3=A9e?=
 <alex.bennee@linaro.org>, kvm@vger.kernel.org, qemu-ppc@nongnu.org,
 qemu-riscv@nongnu.org, David Hildenbrand <david@redhat.com>,
 qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org
References: <20250123234415.59850-1-philmd@linaro.org>
 <20250123234415.59850-13-philmd@linaro.org>
Content-Language: en-US
From: Richard Henderson <richard.henderson@linaro.org>
In-Reply-To: <20250123234415.59850-13-philmd@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 1/23/25 15:44, Philippe Mathieu-Daudé wrote:
> CPU_RESOLVING_TYPE is declared per target in "cpu.h". Include
> it (along with "qom/object.h") to avoid when moving code around:
> 
>    include/accel/accel-cpu-target.h:26:50: error: expected ')'
>       26 | DECLARE_CLASS_CHECKERS(AccelCPUClass, ACCEL_CPU, TYPE_ACCEL_CPU)
>          |                                                  ^
>    include/accel/accel-cpu-target.h:23:33: note: expanded from macro 'TYPE_ACCEL_CPU'
>       23 | #define TYPE_ACCEL_CPU "accel-" CPU_RESOLVING_TYPE
>          |                                 ^
>    include/accel/accel-cpu-target.h:26:1: note: to match this '('
>       26 | DECLARE_CLASS_CHECKERS(AccelCPUClass, ACCEL_CPU, TYPE_ACCEL_CPU)
>          | ^
>    include/qom/object.h:196:14: note: expanded from macro 'DECLARE_CLASS_CHECKERS'
>      196 |     { return OBJECT_GET_CLASS(ClassType, obj, TYPENAME); } \
>          |              ^
>    include/qom/object.h:558:5: note: expanded from macro 'OBJECT_GET_CLASS'
>      558 |     OBJECT_CLASS_CHECK(class, object_get_class(OBJECT(obj)), name)
>          |     ^
>    include/qom/object.h:544:74: note: expanded from macro 'OBJECT_CLASS_CHECK'
>      544 |     ((class_type *)object_class_dynamic_cast_assert(OBJECT_CLASS(class), (name), \
>          |                                                                          ^
> 
> Signed-off-by: Philippe Mathieu-Daudé<philmd@linaro.org>
> ---
>   include/accel/accel-cpu-target.h | 3 +++
>   1 file changed, 3 insertions(+)

Acked-by: Richard Henderson <richard.henderson@linaro.org>

r~


From xen-devel-bounces@lists.xenproject.org Sun Jan 26 20:42:21 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Jan 2025 20:42:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877310.1287449 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tc9SX-0006da-0r; Sun, 26 Jan 2025 20:42:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877310.1287449; Sun, 26 Jan 2025 20:42:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tc9SW-0006dT-UU; Sun, 26 Jan 2025 20:42:20 +0000
Received: by outflank-mailman (input) for mailman id 877310;
 Sun, 26 Jan 2025 20:42:19 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Vl/L=US=linaro.org=richard.henderson@srs-se1.protection.inumbo.net>)
 id 1tc9SV-0006a9-Pa
 for xen-devel@lists.xenproject.org; Sun, 26 Jan 2025 20:42:19 +0000
Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com
 [2607:f8b0:4864:20::62f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0845e246-dc26-11ef-a0e6-8be0dac302b0;
 Sun, 26 Jan 2025 21:42:18 +0100 (CET)
Received: by mail-pl1-x62f.google.com with SMTP id
 d9443c01a7336-2162c0f6a39so86481175ad.0
 for <xen-devel@lists.xenproject.org>; Sun, 26 Jan 2025 12:42:18 -0800 (PST)
Received: from [192.168.0.4] (174-21-71-127.tukw.qwest.net. [174.21.71.127])
 by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-72f8a6b3233sm5836919b3a.61.2025.01.26.12.42.16
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 26 Jan 2025 12:42:16 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 0845e246-dc26-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737924137; x=1738528937; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=H48ko7PqBt1MRDsTfWIcWC8+CkMs626ufkIw2bc/5x8=;
        b=SYVlLTI841X10GzFjnkWOd80XVxQNJL0k6vjKJYqJhS8jh6dpD+3jINfs+io5K1D3E
         OOqI2OrQ7bNk327KYlligxoXDoFuJvp0qzkCqkfG2V1mMe09YiNWywSMZL1Rt7hXNjF0
         6y0j1DhTNKwEx6L31CPiNhLFAGV/+HewySP9PcGYMz5FjrD8VSnUXEjA7iLrcQ3Mid3I
         rTgyuFD11RPqs0xKUz17nus/S5IwO8VV5KbvJ9N6Npyo9KuqNRULTGwEVUvl0EojLz/N
         v5ZtSn9lHZBw1AL6weQ/BNU1zq/xmpFiS1v6oYSNObzMeD+37iOC2vlAR+AwiXJN4YKk
         mbkg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737924137; x=1738528937;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=H48ko7PqBt1MRDsTfWIcWC8+CkMs626ufkIw2bc/5x8=;
        b=iuW58PmQkqqsR+QWeSkUzUKz3Wx07syZJ1cp+B82bxAx9A4tOJ5gDt4wtYJWgDEI6h
         i7N3NEhU06o5tyD9AqOuff3lyVMta3zegmLf7mgcbbAKkRfYidL+Qc0JnaZDTv6xQFgI
         K9fHaKph+gAkT74eN34MjsSl1dEOAizaSYLJzP7XEjoxcams5k2hOB/3H//+ZWSSZDNY
         eLB4vRk2XZC82nWsPpAI2kqpDIaIrGR3RQZReRh/VFTHd7DfCBnMlhl7Mqz2+5sAxAov
         4w/poJ0d54DoSZlc4gibQSxxqcxxgn3M+oI0PCUoW7WxvrdbJ+4+U/rupXS5nlbfn4DL
         6OZQ==
X-Forwarded-Encrypted: i=1; AJvYcCXaAyNhRTK9g6e5xcbEXzGfTOclGvaLjf+0FTzY1FHpaI1RlhmRkH2/8gGmCaI2z0uHJwMQSZdXqH0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxG/zsjPDKMPGRZAhfOvDi/CliK/uk2CNT74hlVEW8bbNbErFXx
	ZOb9MVzzQ7AJOqmOYt/DW7mmzvZ1jfED0ezpl6RsklUk+3YqQluh/Qw9+vASabY=
X-Gm-Gg: ASbGncuiWzH99kAzJ5p+txtDATSapayXQ3t+Pd5xXZWBwmFo1CvIe5eDMX2yveqlmMI
	IMMZEIwlbSuLE2Ah1w9BjHxV0QXyk0DOfEac7339F88h1/75iPVIcWAE5IF3sx2+xp9QxE68Xjj
	+cQwe6NYCGtxNzP5JYDR7aTMHEyUkiuBLeeOspMCYfYuzeGJ6BtHOvHwlPYeOmA3Wk9bebAsXUf
	kYKkfx3hov+GcR/sAUUiHE6YTY0oygXYyYIHSxJrrbWoVOq0vWWeIhV8VeRG0QRh6JGh1kheGOS
	+Q5QC0AoIRs2q4ZZKyMNCqVJneUMb+EVo4cv2lVnlf/tu48=
X-Google-Smtp-Source: AGHT+IET1Hgf5DlFtTnLB6zbw3cCOrZlZ4h4Z0Ht47r+OhnvTjZQY9E5YHFS64waNnu9A7EWzAD+mw==
X-Received: by 2002:a05:6a00:2719:b0:72a:83ec:b1cb with SMTP id d2e1a72fcca58-72f8adf4091mr15476076b3a.0.1737924137118;
        Sun, 26 Jan 2025 12:42:17 -0800 (PST)
Message-ID: <fc81002d-b169-40f7-80e1-c93e55fadd30@linaro.org>
Date: Sun, 26 Jan 2025 12:42:15 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 13/20] accel: Forward-declare AccelOpsClass in
 'qemu/typedefs.h'
To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= <philmd@linaro.org>,
 qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
 Paolo Bonzini <pbonzini@redhat.com>, qemu-arm@nongnu.org,
 Igor Mammedov <imammedo@redhat.com>, =?UTF-8?Q?Alex_Benn=C3=A9e?=
 <alex.bennee@linaro.org>, kvm@vger.kernel.org, qemu-ppc@nongnu.org,
 qemu-riscv@nongnu.org, David Hildenbrand <david@redhat.com>,
 qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org
References: <20250123234415.59850-1-philmd@linaro.org>
 <20250123234415.59850-14-philmd@linaro.org>
Content-Language: en-US
From: Richard Henderson <richard.henderson@linaro.org>
In-Reply-To: <20250123234415.59850-14-philmd@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 1/23/25 15:44, Philippe Mathieu-Daudé wrote:
> The heavily imported "system/cpus.h" header includes "accel-ops.h"
> to get AccelOpsClass type declaration. Reduce headers pressure by
> forward declaring it in "qemu/typedefs.h", where we already
> declare the AccelCPUState type.
> 
> Reduce "system/cpus.h" inclusions by only including
> "system/accel-ops.h" when necessary.
> 
> Signed-off-by: Philippe Mathieu-Daudé<philmd@linaro.org>
> ---
>   include/qemu/typedefs.h           | 1 +
>   include/system/accel-ops.h        | 1 -
>   include/system/cpus.h             | 2 --
>   accel/accel-system.c              | 1 +
>   accel/hvf/hvf-accel-ops.c         | 1 +
>   accel/kvm/kvm-accel-ops.c         | 1 +
>   accel/qtest/qtest.c               | 1 +
>   accel/tcg/cpu-exec-common.c       | 1 -
>   accel/tcg/cpu-exec.c              | 1 -
>   accel/tcg/monitor.c               | 1 -
>   accel/tcg/tcg-accel-ops.c         | 1 +
>   accel/tcg/translate-all.c         | 1 -
>   accel/xen/xen-all.c               | 1 +
>   cpu-common.c                      | 1 -
>   cpu-target.c                      | 1 +
>   gdbstub/system.c                  | 1 +
>   system/cpus.c                     | 1 +
>   target/i386/nvmm/nvmm-accel-ops.c | 1 +
>   target/i386/whpx/whpx-accel-ops.c | 1 +
>   19 files changed, 12 insertions(+), 8 deletions(-)

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~


From xen-devel-bounces@lists.xenproject.org Sun Jan 26 21:14:08 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Jan 2025 21:14:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877319.1287459 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tc9x6-0004PI-1a; Sun, 26 Jan 2025 21:13:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877319.1287459; Sun, 26 Jan 2025 21:13:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tc9x5-0004PB-Ux; Sun, 26 Jan 2025 21:13:55 +0000
Received: by outflank-mailman (input) for mailman id 877319;
 Sun, 26 Jan 2025 21:13:55 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Vl/L=US=linaro.org=richard.henderson@srs-se1.protection.inumbo.net>)
 id 1tc9x4-0004P5-Tj
 for xen-devel@lists.xenproject.org; Sun, 26 Jan 2025 21:13:55 +0000
Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com
 [2607:f8b0:4864:20::62b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7167d662-dc2a-11ef-a0e6-8be0dac302b0;
 Sun, 26 Jan 2025 22:13:53 +0100 (CET)
Received: by mail-pl1-x62b.google.com with SMTP id
 d9443c01a7336-216401de828so65928465ad.3
 for <xen-devel@lists.xenproject.org>; Sun, 26 Jan 2025 13:13:52 -0800 (PST)
Received: from [192.168.0.4] (174-21-71-127.tukw.qwest.net. [174.21.71.127])
 by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-21da3ea3bb9sm50157355ad.92.2025.01.26.13.13.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 26 Jan 2025 13:13:51 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 7167d662-dc2a-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737926031; x=1738530831; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=M9kpcRwj4XMG8ftG4wmZyZnxF1iU/ErySCW5MvOqlTU=;
        b=EGTumM4lFSgptzooojyXm6sP3Q7FcEfHf7uBAufhk7wZwliYq/oXTh3498BUSMsAUT
         eHko89OUQzkNWIPSNDBJhKXdtl7r/5KMEMtv3iYGdx3CtoE0TsMflssLY8y7LSJuJrlN
         8i5ai2QVM9gUvjmmCEM5iFyfNlqo4wilNbNT33PzoLSKvrwR/LLMBGY3eM/iStz8kCoP
         Tmu94v4BBZvzvr8bfPYM1WWtuj310te8Cp4vvpR+vNH603+ElCr4joJvgyqL7yOoWF9g
         szMEOevyySdO8yWMFAy4AQpOE568iI4V32exExLUfC8AnqhRy7Z5Tjz9YU2LpryQQhZ0
         7QCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737926031; x=1738530831;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=M9kpcRwj4XMG8ftG4wmZyZnxF1iU/ErySCW5MvOqlTU=;
        b=Krvo8uQSQVLQli4PEtaEkQii7TKI0IIEeN4zZQ09rOZiY5XdvgSnQuzilkbumjrEkZ
         EWZ73iCt1FN+1AyqeRhqg+KdK0VqSVIpehXRbInSZWg2OaVClrt13r91IzuHcPHJL0f3
         e2MSNbactogall1+CXxYoIyO014UZT0LoF2UFI4LsJXIUMvJUQ9VIwhqB/e26DsgMDx6
         ZvLkzlK9fhrNe8+2l48dDK9fo7p3o3Wyz+MouhVcDPjJ4yJCiEnOJpCg0RgQK8pTIepu
         vIzi8srLyJLl5YPfv2RSrJGGs0+GudDHCbJ43idI8CiBoNFHXiNNZTRNrKsA5dQMgNt/
         TT+Q==
X-Forwarded-Encrypted: i=1; AJvYcCWAPvUQp1s+2QRIceki+0bbyYX45ukFsyyDKyl8H1gQ2isGBSEBqX9biFXGMuot3HQ3fqkm5kl2igc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyKBplBqj7E+Me9Kr4yS3uc1u994Kc9M5sgOhq5tvoj6oBLfdmV
	RZgeGJ5or11S1Gckj2cVyEkYo1rq9ymAbO8PdBdVyDXYBy0Q3kajDkgAVzEJD/c=
X-Gm-Gg: ASbGncuagRKCtG3iPQN23E+Q3LUOho6A6RnX2YL7ztZFGSBCQlv0bHbefDP9Z/YodLv
	bDk9fkivIbN81u1V9jwkTULxlm+c4P+gdQCTDBeQ2MC9JJ8Cn1VoYEX3dOzWvZUt3jv/nze3e8s
	0aOgB9987bs1HSS4rE1uGn5g9yO1GV6QOJ89v7TelBFvzZIEecBjPyxtPFjCYzPYtE9DGvcBJUS
	yTvcnlzJazo6dNkg7VQR2zAkmnUs6Tdopk1FpgsmNR1SYj9Kng38Y0m+eeodHTIv/syFW84FhEu
	Hcy1vrs0MlkLS8QpUL/Z/tZDhELfWcIWtIafflJsNl9q26Q=
X-Google-Smtp-Source: AGHT+IEZs0zeKB5IzyrVqsgjZQ8Qgr6yuUndfoZR9xIIrSSkISsRSLWzsvON9msLe4CFxT+Ly8wqnw==
X-Received: by 2002:a17:902:f551:b0:215:431f:268a with SMTP id d9443c01a7336-21c3556016amr565306785ad.31.1737926031507;
        Sun, 26 Jan 2025 13:13:51 -0800 (PST)
Message-ID: <c844b086-b3fd-438d-a4ce-6571094e5e14@linaro.org>
Date: Sun, 26 Jan 2025 13:13:49 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 14/20] accel/tcg: Move cpu_memory_rw_debug() user
 implementation to user-exec.c
To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= <philmd@linaro.org>,
 qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
 Paolo Bonzini <pbonzini@redhat.com>, qemu-arm@nongnu.org,
 Igor Mammedov <imammedo@redhat.com>, =?UTF-8?Q?Alex_Benn=C3=A9e?=
 <alex.bennee@linaro.org>, kvm@vger.kernel.org, qemu-ppc@nongnu.org,
 qemu-riscv@nongnu.org, David Hildenbrand <david@redhat.com>,
 qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org
References: <20250123234415.59850-1-philmd@linaro.org>
 <20250123234415.59850-15-philmd@linaro.org>
Content-Language: en-US
From: Richard Henderson <richard.henderson@linaro.org>
In-Reply-To: <20250123234415.59850-15-philmd@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 1/23/25 15:44, Philippe Mathieu-Daudé wrote:
> cpu_memory_rw_debug() system implementation is defined in
> system/physmem.c. Move the user one to accel/tcg/user-exec.c
> to simplify cpu-target.c maintenance.
> 
> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> ---
>   accel/tcg/user-exec.c |  92 +++++++++++++++++++++++++++++++++++++
>   cpu-target.c          | 102 +-----------------------------------------
>   2 files changed, 94 insertions(+), 100 deletions(-)
> 
> diff --git a/accel/tcg/user-exec.c b/accel/tcg/user-exec.c
> index c4454100ad7..e7e99a46087 100644
> --- a/accel/tcg/user-exec.c
> +++ b/accel/tcg/user-exec.c
> @@ -19,6 +19,8 @@
>   #include "qemu/osdep.h"
>   #include "accel/tcg/cpu-ops.h"
>   #include "disas/disas.h"
> +#include "exec/vaddr.h"
> +#include "exec/tswap.h"
>   #include "exec/exec-all.h"
>   #include "tcg/tcg.h"
>   #include "qemu/bitops.h"
> @@ -35,6 +37,7 @@
>   #include "internal-common.h"
>   #include "internal-target.h"
>   #include "tb-internal.h"
> +#include "qemu.h"

What is required from *-user/qemu.h?
We really should not be including that in accel/tcg/.

> +            if (flags & PAGE_WRITE) {
> +                /* XXX: this code should not depend on lock_user */
> +                p = lock_user(VERIFY_WRITE, addr, l, 0);

Ah, here it is, complete with comment.

Indeed, I don't think lock_user is required at all.  page_get_flags() and g2h() are 
sufficient.

> +                mmap_lock();
> +                tb_invalidate_phys_range(addr, addr + l - 1);
> +                written = pwrite(fd, buf, l,
> +                                 (off_t)(uintptr_t)g2h_untagged(addr));
> +                mmap_unlock();

We probably want to own mmap_lock for the entire function.


r~


From xen-devel-bounces@lists.xenproject.org Sun Jan 26 21:14:50 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Jan 2025 21:14:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877326.1287470 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tc9xy-0004so-Aw; Sun, 26 Jan 2025 21:14:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877326.1287470; Sun, 26 Jan 2025 21:14:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tc9xy-0004sh-7v; Sun, 26 Jan 2025 21:14:50 +0000
Received: by outflank-mailman (input) for mailman id 877326;
 Sun, 26 Jan 2025 21:14: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
 <SRS0=Vl/L=US=linaro.org=richard.henderson@srs-se1.protection.inumbo.net>)
 id 1tc9xw-0004qC-6H
 for xen-devel@lists.xenproject.org; Sun, 26 Jan 2025 21:14:48 +0000
Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com
 [2607:f8b0:4864:20::1036])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 91611d32-dc2a-11ef-99a4-01e77a169b0f;
 Sun, 26 Jan 2025 22:14:46 +0100 (CET)
Received: by mail-pj1-x1036.google.com with SMTP id
 98e67ed59e1d1-2eed82ca5b4so6507545a91.2
 for <xen-devel@lists.xenproject.org>; Sun, 26 Jan 2025 13:14:46 -0800 (PST)
Received: from [192.168.0.4] (174-21-71-127.tukw.qwest.net. [174.21.71.127])
 by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-2f7ffb193e1sm5644337a91.42.2025.01.26.13.14.44
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 26 Jan 2025 13:14:44 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 91611d32-dc2a-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737926085; x=1738530885; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=dM482TolBOr/dYb2pXuY2SYJtabVGHzvURXSW1TjI40=;
        b=rsszn5uqTubgBIOCdr6W1Jnbclu9mGaKxjnhzpARcn9xo6g2VBN9IgWFBcYCeZN5CP
         uXW39ZQM3YtJUrKk21Wf0nfL4jzZxDe+vyxnMu1HT1FN5YaWUQPP3mlDjjXkLS2NReH5
         jnBCYcnjG3tCn3MtKKMovljfz3Vz+aBPlgYSDW7TNREiTPBnDABlO+6EgWPuHbAn2G1G
         LIPECxukaoGMKUPheRZxAdV4UAKjAvUWqLh1SYNlklkz2g2HJ40GmRrf3kra/B+tx7Gg
         brCIma3ab0DVGoMSktECR27DNbuNgwLlqxmCvsLVyOI6zXZeDuCV3iSQPr8MNdNq6HCs
         dvTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737926085; x=1738530885;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=dM482TolBOr/dYb2pXuY2SYJtabVGHzvURXSW1TjI40=;
        b=P6CCZOqZ0RKQEVqUkk3lRE2mYs0WSXV0Nx/KaW9YlgvCsZnowYsR6VxfWpcpQlpA7l
         gZARtEDTFDmO1Lca8oNnCXrn3gb3P1Nf4dbcR2rfjjHLYGbg744bQWM2kPbC2idLOH/I
         T6j0WUMD6skEtoq5TIvw0cFlRM61TnSUVtAgd3Oh0rxxxfImGvIP9pEJYMvDf7S7izs/
         +en4mbbqrzdwPF+JBgZet9CIKmP5jpl70yh1NWC+SCDfOn0MgVnOILg4tNRN0Fuwz8WW
         5xgfvrH3q1ok0eQg/lxPgzUGkJzKp7a7qscwioYsQeSAlkAYbqdZh8VtVU4dpnudSpfB
         YX0w==
X-Forwarded-Encrypted: i=1; AJvYcCXf1kXN86nt6eibjWBsPidLpNAwiUqETDOx0/W/HTnkDEDPko1ZuXwXksgVwJZws8/Qvb7bVQTP2yg=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy1s29wuoKkTRkz/2WgScdrKMZKLNBSHwCg1OeT9O8zUud50pXh
	PqgYndtkhfFuim8VTFSax03PGXRhK8NIvAAJOxtTscUYvM+wRQL4K6tgfN0WPKQ=
X-Gm-Gg: ASbGncv/7/9+2jEHzEiZaVdzsiiOr+Dx4Kj3qXvolgtu0EXOQlCx0JOHkmfwGd1/K7p
	lOW94HEt8LRbgXljvuNl7OSrd3IAEcWJpaxp7HYjm7xn6ezY7xfTmVL5TCBtUUxv+RMlUuzpQVC
	RdjRC+Ap1IENcJdBAVRr9U84dc1gjnNmj4XBYRi0nQxfrAwoiXBvw9M8URdKgWXMsHOPO0xnb6S
	8SLzPL0tS6VjVaPrwBcVmaBa86vZHhJxHoUWazPG2G1dKne5sZBXxGpTqvP2uTlnf83NMU7iOeO
	fZgzhtS8o8uRQ4EGiBNK9xGSe8Fabuex5CtVhgZEGAuGFDM=
X-Google-Smtp-Source: AGHT+IE1AaZn04VsAmZoovvHskfFwwHs+/I0v2XJVpXr12XD+Jd8EH5sfL0xlHcxmhZL8x5QsccIOQ==
X-Received: by 2002:a17:90b:2f50:b0:2ee:fdf3:38ea with SMTP id 98e67ed59e1d1-2f782d32c45mr47771107a91.23.1737926085217;
        Sun, 26 Jan 2025 13:14:45 -0800 (PST)
Message-ID: <f7c1590d-5c61-4408-92c9-7241aed2c6be@linaro.org>
Date: Sun, 26 Jan 2025 13:14:43 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 15/20] cpus: Fix style in cpu-target.c
To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= <philmd@linaro.org>,
 qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
 Paolo Bonzini <pbonzini@redhat.com>, qemu-arm@nongnu.org,
 Igor Mammedov <imammedo@redhat.com>, =?UTF-8?Q?Alex_Benn=C3=A9e?=
 <alex.bennee@linaro.org>, kvm@vger.kernel.org, qemu-ppc@nongnu.org,
 qemu-riscv@nongnu.org, David Hildenbrand <david@redhat.com>,
 qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org
References: <20250123234415.59850-1-philmd@linaro.org>
 <20250123234415.59850-16-philmd@linaro.org>
Content-Language: en-US
From: Richard Henderson <richard.henderson@linaro.org>
In-Reply-To: <20250123234415.59850-16-philmd@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 1/23/25 15:44, Philippe Mathieu-Daudé wrote:
> Fix style on code we are going to modify.
> 
> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> ---
>   cpu-target.c | 9 ++++++---
>   1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/cpu-target.c b/cpu-target.c
> index 6d8b7825746..a2999e7c3c0 100644
> --- a/cpu-target.c
> +++ b/cpu-target.c
> @@ -47,12 +47,15 @@ static int cpu_common_post_load(void *opaque, int version_id)
>   {
>       CPUState *cpu = opaque;
>   
> -    /* 0x01 was CPU_INTERRUPT_EXIT. This line can be removed when the
> -       version_id is increased. */
> +    /*
> +     * 0x01 was CPU_INTERRUPT_EXIT. This line can be removed when the
> +     * version_id is increased.
> +     */
>       cpu->interrupt_request &= ~0x01;
>       tlb_flush(cpu);
>   
> -    /* loadvm has just updated the content of RAM, bypassing the
> +    /*
> +     * loadvm has just updated the content of RAM, bypassing the
>        * usual mechanisms that ensure we flush TBs for writes to
>        * memory we've translated code from. So we must flush all TBs,
>        * which will now be stale.

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~


From xen-devel-bounces@lists.xenproject.org Sun Jan 26 21:17:05 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Jan 2025 21:17:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877334.1287479 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcA08-0005Sr-Ls; Sun, 26 Jan 2025 21:17:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877334.1287479; Sun, 26 Jan 2025 21:17:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcA08-0005Sk-JN; Sun, 26 Jan 2025 21:17:04 +0000
Received: by outflank-mailman (input) for mailman id 877334;
 Sun, 26 Jan 2025 21:17:03 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Vl/L=US=linaro.org=richard.henderson@srs-se1.protection.inumbo.net>)
 id 1tcA07-0005Se-NE
 for xen-devel@lists.xenproject.org; Sun, 26 Jan 2025 21:17:03 +0000
Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com
 [2607:f8b0:4864:20::62c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e1063b31-dc2a-11ef-99a4-01e77a169b0f;
 Sun, 26 Jan 2025 22:17:00 +0100 (CET)
Received: by mail-pl1-x62c.google.com with SMTP id
 d9443c01a7336-21661be2c2dso63069875ad.1
 for <xen-devel@lists.xenproject.org>; Sun, 26 Jan 2025 13:17:00 -0800 (PST)
Received: from [192.168.0.4] (174-21-71-127.tukw.qwest.net. [174.21.71.127])
 by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-2f7ffa75bafsm5669849a91.31.2025.01.26.13.16.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 26 Jan 2025 13:16:57 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e1063b31-dc2a-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737926219; x=1738531019; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=kMRLOGE6yrO6E+licLk956mV4oo4UqHJMRzU5NR3n4c=;
        b=LPQ9rE2XZmdmbBe7Oo8EVcy+3kuVUIQ63V/Kev6xBnQTYYO59KIupPIH/NAhfRYPN3
         ZSau6iWpzF92VVDvzRGXavVlDh4Zw0oK8blSj0HGksx90ZsOBQ2SFUcv7ns+oQqoZWbY
         ZDGKyUhw1pgmc56FsEQek7tOXru84wnJImEc0SlcywjdaNQKeADpjlZ5PMmCusoBPjM7
         zITjWcuR6UJGyWs10xd4xyJN6sxTmNIn4Sa9bwdUb07tzqFi8tTZ0p/J1xDC/HMI8xVf
         JLVSZawPTZ9oz1rZgu88yEh5hRtE1OvX4FZpww6kQur7qJNsqZZXMzqPmRKHiRzmVeFz
         IpUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737926219; x=1738531019;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=kMRLOGE6yrO6E+licLk956mV4oo4UqHJMRzU5NR3n4c=;
        b=J5hR4ijxEPvfCB7yXzKTxybU3gmzs4OeIP2T7B1WIGB0gP+isSufx9cTb1w7sZDjPF
         Ja1H+3IeQ3z+Zmx+MoEHAnMKnlSeu+NFp8Vz+1TjhO2MJ1hwXpd/ATpQSNgwsUDIHKpB
         SR4gHWNAY9fPxxSKbeItbCbiyLi13S4lCkrC2cV202+M6sEQSYwnw9Ftj4WLTX9Q8+SK
         We0xp4QvUetXkdtgqH6BA1U8DADv8/jt3KHjll85LY5xlg/JNcRGWHPgE9VRA2ENB1Rv
         eBswH4K9WXyV155mEtAs8oDOhTZ93ZWZmpRN4jcZ3w7cjRajdE3WJNSbSUTN9wzu7n7S
         JHFQ==
X-Forwarded-Encrypted: i=1; AJvYcCWXiZVTccgwFPryT+ScPnNLd730PzB1iTQ3/W/nORDuMqwfusJIPaYKupXWxExht53ErfG0cQJSXmY=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzq3qBSu3AR0f9hgz0RI0HmB0yUBjCFRekGixxd+4ukIkV8XWlH
	Ba6F9wzSlgHcvkx5L9Vv3cF7Qy62A9CDrAuW76rJIdrgaUi3Aa3ITdXHVqJKSrg=
X-Gm-Gg: ASbGncsicjNj2NW1Gs+SVL8GkW7kLMM5etYLGwy53wHkwN2EaIz4sGJWxZQDp1SK7R/
	kr+fVvBv7N87KoSzoRxbKaNxV9225X5fKM0jfF7+6qVpHXLn2fLWpUaINLbwBeTzerLY8RhIAVQ
	MCt9CV9n6z7l7BFtpy3AteGM6JnTDKxkDKF85mpor0wos1c1/vxonH/gKvZR9eoy8USdy/l8xZh
	60d9O1RBt1SLi6sXsHGHBmaIkwJQkk+/LKNtECZ/nJWIGVHJk6MS1fU1Kd3RFS19Vt6JvqTxHnJ
	evSDwDN5jAqTsStY498AfaiPg+tFnPtdED3heOaC4ziiMZo=
X-Google-Smtp-Source: AGHT+IFBHji7Q02DuNHRJzVlNXhJjAx8HDsMis8mrPSUngwfhLK6I5AlZnoO5BvEYdWLX8kF5J4JkA==
X-Received: by 2002:a17:90b:2243:b0:2ee:e961:303d with SMTP id 98e67ed59e1d1-2f782d9ee8emr55346160a91.35.1737926218792;
        Sun, 26 Jan 2025 13:16:58 -0800 (PST)
Message-ID: <e52485c5-122a-4a95-928f-08fcd17cd772@linaro.org>
Date: Sun, 26 Jan 2025 13:16:56 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 16/20] cpus: Restrict cpu_common_post_load() code to TCG
To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= <philmd@linaro.org>,
 qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
 Paolo Bonzini <pbonzini@redhat.com>, qemu-arm@nongnu.org,
 Igor Mammedov <imammedo@redhat.com>, =?UTF-8?Q?Alex_Benn=C3=A9e?=
 <alex.bennee@linaro.org>, kvm@vger.kernel.org, qemu-ppc@nongnu.org,
 qemu-riscv@nongnu.org, David Hildenbrand <david@redhat.com>,
 qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org
References: <20250123234415.59850-1-philmd@linaro.org>
 <20250123234415.59850-17-philmd@linaro.org>
Content-Language: en-US
From: Richard Henderson <richard.henderson@linaro.org>
In-Reply-To: <20250123234415.59850-17-philmd@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 1/23/25 15:44, Philippe Mathieu-Daudé wrote:
> CPU_INTERRUPT_EXIT was removed in commit 3098dba01c7
> ("Use a dedicated function to request exit from execution
> loop"), tlb_flush() and tb_flush() are related to TCG
> accelerator.
> 
> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> ---
>   cpu-target.c | 33 +++++++++++++++++++--------------
>   1 file changed, 19 insertions(+), 14 deletions(-)
> 
> diff --git a/cpu-target.c b/cpu-target.c
> index a2999e7c3c0..c05ef1ff096 100644
> --- a/cpu-target.c
> +++ b/cpu-target.c
> @@ -45,22 +45,27 @@
>   #ifndef CONFIG_USER_ONLY
>   static int cpu_common_post_load(void *opaque, int version_id)
>   {
> -    CPUState *cpu = opaque;
> +#ifdef CONFIG_TCG
> +    if (tcg_enabled()) {

Why do you need both ifdef and tcg_enabled()?  I would have thought just tcg_enabled().

Are there declarations that are (unnecessarily?) protected?


r~


From xen-devel-bounces@lists.xenproject.org Sun Jan 26 21:19:03 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Jan 2025 21:19:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877343.1287490 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcA21-00064k-4V; Sun, 26 Jan 2025 21:19:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877343.1287490; Sun, 26 Jan 2025 21:19:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcA21-00064d-1I; Sun, 26 Jan 2025 21:19:01 +0000
Received: by outflank-mailman (input) for mailman id 877343;
 Sun, 26 Jan 2025 21:18:59 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Vl/L=US=linaro.org=richard.henderson@srs-se1.protection.inumbo.net>)
 id 1tcA1z-00064X-F6
 for xen-devel@lists.xenproject.org; Sun, 26 Jan 2025 21:18:59 +0000
Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com
 [2607:f8b0:4864:20::635])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 275b1621-dc2b-11ef-a0e6-8be0dac302b0;
 Sun, 26 Jan 2025 22:18:58 +0100 (CET)
Received: by mail-pl1-x635.google.com with SMTP id
 d9443c01a7336-215770613dbso45938355ad.2
 for <xen-devel@lists.xenproject.org>; Sun, 26 Jan 2025 13:18:58 -0800 (PST)
Received: from [192.168.0.4] (174-21-71-127.tukw.qwest.net. [174.21.71.127])
 by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-21da3d9db91sm50141815ad.48.2025.01.26.13.18.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 26 Jan 2025 13:18:55 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 275b1621-dc2b-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737926337; x=1738531137; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=X+G0ryUleEoZxvXmUvLzmbIUvRMHYbb2l6B2uT5mTT0=;
        b=VwkgbrmA4EwIkAPtmBRPPhmxoRb9zldGJRSoZb8mjZ1EqEEpe+J94fEFxGQno8K+8a
         2M1fghYvqPQwX0S8xQMlc93NGS37fT9TbS0+F8iQNHEoxeU0m/Y4ynFfDV9RChCy2/XP
         mXt3FE2GGzbQQ5T4duvereM7iKlEUVeKcJhqvx8DKboMIujcih59ZnaHxI9v8XA3dR5j
         UK0mfpXnWIeO4k8CTWiv/Z3QgCD745jRdFtZsVrnWwuxe6nJ4yoMOkGRWLNi/jdZ6nMd
         fatXZrYiDnjs7q60orwXcUq0bpgOMB6oH99Bbu+8YHmpvCijDm1xcGRtxupMknwXvmPl
         32AQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737926337; x=1738531137;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=X+G0ryUleEoZxvXmUvLzmbIUvRMHYbb2l6B2uT5mTT0=;
        b=ATvAibriCbM5XFSBydJdpnjsHhR6Ak+NuCVCDhpslBDTfeY7VrWit7meVPR98vERWF
         z6p8CgwbU35TPEffX06t4Inp4i/AHk/sY/R5QuiIOokAN9WJX583h0EiAq3u5wkc9tQ4
         mgnBgin0/gBRQFauzJuke9c9EfHM3KBSV0z+/m88bns1k/fceOvUSYGU2Mi+I84dthyt
         VRIjFPwRZUHJBf2Kw+nCrqXoNbEE5VhEg7M7CdwC1pAJQf/nJfbzGgQRlsK5RfKnGfjc
         8G4CLTsDNsBxG7AiRchnr/q/ZM05o8FitJLAdsdUlW+LpOpJZjRnkcxL3cRGDagYiL2j
         CRtA==
X-Forwarded-Encrypted: i=1; AJvYcCXmX+5/J7vLmzW35zKNQ9KTVXUGtZd5xXS6kM+SmSKYOcM3xoviG1ugMjQv4iShI2trZemO0iqruAc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwpWMnfhvJpi2mxCSL5iXc08386svriUcwbQtm3cs9YEXNd7WH+
	wxCivMEBDhU+NgTry/ASeLM5xDeZ5/nJuRqrAmJChcDfO0Oor6/inFi4mdZRGzg=
X-Gm-Gg: ASbGnct3WVEWk3bbhC4W23RJfyft8ZcE+ShMXQn6jZtWrhpGLgl99JmTHHH0sLvmeyX
	FwKj8l/jWp7/oq9D4s1ZPjzjqQ1Whycgzb0BlKZBEQV6bUW5IAf5jblOwpt73Y79v8NoKk5iCmY
	/Qppt1quF5B6dJLdC6Z53yDczyNAx+4pjoQ6hmx7rccuqbie26v+GHIaiIQUQjYpwDp+HgnbTEH
	e52fI6UJsHDY0ULzdOcoEXmC5I+1si/1aXUuPqbbveGWP3ylnaNTDBhqZwkoE/gtoFbDd6IRjjV
	3ORgoNZyDUpNekKUc2KUtdcyJrz83DNkGthcWT9UTzWp+At9aLoqkMkIPg==
X-Google-Smtp-Source: AGHT+IFqQ9SrCqtaqHBxnEeUe9wIIgiFAi160abwNWKtJLcX5dR1YlfbX/KbmypQ71AFHncXjFvVWg==
X-Received: by 2002:a17:902:db0e:b0:215:522d:72d6 with SMTP id d9443c01a7336-21c355bae02mr611350715ad.38.1737926336707;
        Sun, 26 Jan 2025 13:18:56 -0800 (PST)
Message-ID: <39ee3338-aa9b-4cdf-a06c-ab25341d3cd2@linaro.org>
Date: Sun, 26 Jan 2025 13:18:54 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 17/20] cpus: Have cpu_class_init_props() per user / system
 emulation
To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= <philmd@linaro.org>,
 qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
 Paolo Bonzini <pbonzini@redhat.com>, qemu-arm@nongnu.org,
 Igor Mammedov <imammedo@redhat.com>, =?UTF-8?Q?Alex_Benn=C3=A9e?=
 <alex.bennee@linaro.org>, kvm@vger.kernel.org, qemu-ppc@nongnu.org,
 qemu-riscv@nongnu.org, David Hildenbrand <david@redhat.com>,
 qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org
References: <20250123234415.59850-1-philmd@linaro.org>
 <20250123234415.59850-18-philmd@linaro.org>
Content-Language: en-US
From: Richard Henderson <richard.henderson@linaro.org>
In-Reply-To: <20250123234415.59850-18-philmd@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 1/23/25 15:44, Philippe Mathieu-Daudé wrote:
> Rather than maintaining a mix of system / user code for CPU
> class properties, move system properties to cpu-system.c
> and user ones to the new cpu-user.c unit.
> 
> Signed-off-by: Philippe Mathieu-Daudé<philmd@linaro.org>
> ---
>   cpu-target.c         | 58 --------------------------------------------
>   hw/core/cpu-system.c | 40 ++++++++++++++++++++++++++++++
>   hw/core/cpu-user.c   | 27 +++++++++++++++++++++
>   hw/core/meson.build  |  5 +++-
>   4 files changed, 71 insertions(+), 59 deletions(-)
>   create mode 100644 hw/core/cpu-user.c

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~


From xen-devel-bounces@lists.xenproject.org Sun Jan 26 21:21:38 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Jan 2025 21:21:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877349.1287499 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcA4V-0007s6-GN; Sun, 26 Jan 2025 21:21:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877349.1287499; Sun, 26 Jan 2025 21:21:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcA4V-0007rz-Dk; Sun, 26 Jan 2025 21:21:35 +0000
Received: by outflank-mailman (input) for mailman id 877349;
 Sun, 26 Jan 2025 21:21: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
 <SRS0=Vl/L=US=linaro.org=richard.henderson@srs-se1.protection.inumbo.net>)
 id 1tcA4U-0007rt-8C
 for xen-devel@lists.xenproject.org; Sun, 26 Jan 2025 21:21:34 +0000
Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com
 [2607:f8b0:4864:20::62b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 83cb84d4-dc2b-11ef-a0e6-8be0dac302b0;
 Sun, 26 Jan 2025 22:21:33 +0100 (CET)
Received: by mail-pl1-x62b.google.com with SMTP id
 d9443c01a7336-2161eb95317so64871125ad.1
 for <xen-devel@lists.xenproject.org>; Sun, 26 Jan 2025 13:21:33 -0800 (PST)
Received: from [192.168.0.4] (174-21-71-127.tukw.qwest.net. [174.21.71.127])
 by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-21da4141e2dsm50143635ad.124.2025.01.26.13.21.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 26 Jan 2025 13:21:31 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 83cb84d4-dc2b-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737926492; x=1738531292; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=QYxKemM/xZvwRVD9aoAgaA6gwfgdoNiv4c107IIPZT4=;
        b=k4v/goeUeTgNYUVg2wwUF9pfXnOekRpLQzzLkXDtamao/6hoeB/9NgMXmNuOORGoi1
         tbKmALFUizZAzJl36C0yfPK7+ohHmsupQCiTqP5Ibw8ISsPtHIy644gpp8DoMtUeKxL3
         zbAPVxA7KQEHTD0pO5VgSWdVdMpLVx04W//z5PkZLsWNtrkIgNsYk03TfjvlMGmYbh1R
         cQVMCIipTA5VX/1l3eVbhBWEJGQitpNYZdR7fT9/he3+1XB9Z2905F5Bi/VSSuRiIrfl
         0rnBB81ud00lAIZklC7gDHrVawU/eVXt6be4/yJJHtgotCV65rFAQSmP/LoaiJrkGJA7
         tcFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737926492; x=1738531292;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=QYxKemM/xZvwRVD9aoAgaA6gwfgdoNiv4c107IIPZT4=;
        b=u4XQM6s0Cs67Z2zTQgRAmyeTJx9pgCO/FYzazi3+l0eTQwnx24AhOFdcwhnEwF1UJz
         OtEXcshXHnJUk36BeIRYcEI5LMdh9Csuw4pyp2ZaJ6QzBp79R4HoH16qjA+CePqwU3eO
         CVEUJ/evjCeNFc4EWyNH0iktqC7JTNeEm8fg/xfi0AVG7/0wO8WQiqQ3zzh+ZBfxmARS
         JCTAhv06TY8wwWCgRMyAHKVt/cz6i77iEDCmwU1+IOwXiNDW2AwxfJTF3+rjywsLhBNQ
         gtc3Nx9tQxd4PjZE0595YvecA67xt1NJQ2Dg7KCRRw36zPYy5K1+exo2BbD2s5jWZX43
         QyRA==
X-Forwarded-Encrypted: i=1; AJvYcCXPOhzYubAmqqglZgWppZclAz84O8vl1fCDZ+urg/lftOrJ6dkojFdFbHqZxp5Vm2QZFdrIzHWPR5I=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx6/XQcW7da49v8w7TbByavAyGdRNXGy6BZRDYUEpCwoouSIf0e
	GJh0BpEWf4b7HqWj+yNnmL0DNU69WKlR9U2s4cBeucSQXiZ9TIYY7lijMv398HM=
X-Gm-Gg: ASbGncsoLwIaizblLwFKoUPbcelpta1ssqPFUknurZxCukz7uXNPdiBr/L/vNnLwQdR
	4qnYQA5cCvJmWbxfXPXym1RmDCUmlHt7Kr1hbMpRTN0Ks3GS7YufpubPZWHL21klJTgcbEYxtgH
	QoIttkPkzhgJ7AqayyRCBSAXxjUBtlpBDEL54WpDFTcf+/DWPmSbpJ8lybOMVlq2ZTvqPtc38F7
	CbTsgMOseDtc59KJogposq8qJTkn1J5JOkc+xPwhYivN0gcxkGJROGeULgCghYVSw7sxMxyIilc
	syFb+IiPgFx4Bv36TZJw8RL7/nUESo57uIr7hrkT6WpAOns=
X-Google-Smtp-Source: AGHT+IEK/IDwjYTfcGC9vytnhg57Unum7j14HBhQ+TRt9SQk9fY2DLtXa4M3MfHh3b7yHzuy9lAQFA==
X-Received: by 2002:a17:902:c951:b0:216:5268:9aab with SMTP id d9443c01a7336-21c355e832amr552530105ad.46.1737926491907;
        Sun, 26 Jan 2025 13:21:31 -0800 (PST)
Message-ID: <6fcaa7b1-ba43-4a3f-a560-5d05a57cdc7c@linaro.org>
Date: Sun, 26 Jan 2025 13:21:29 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 18/20] cpus: Have cpu_exec_initfn() per user / system
 emulation
To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= <philmd@linaro.org>,
 qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
 Paolo Bonzini <pbonzini@redhat.com>, qemu-arm@nongnu.org,
 Igor Mammedov <imammedo@redhat.com>, =?UTF-8?Q?Alex_Benn=C3=A9e?=
 <alex.bennee@linaro.org>, kvm@vger.kernel.org, qemu-ppc@nongnu.org,
 qemu-riscv@nongnu.org, David Hildenbrand <david@redhat.com>,
 qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org
References: <20250123234415.59850-1-philmd@linaro.org>
 <20250123234415.59850-19-philmd@linaro.org>
Content-Language: en-US
From: Richard Henderson <richard.henderson@linaro.org>
In-Reply-To: <20250123234415.59850-19-philmd@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 1/23/25 15:44, Philippe Mathieu-Daudé wrote:
> Slighly simplify cpu-target.c again by extracting cpu_exec_initfn()
> to cpu-{system,user}.c, adding an empty stub for user emulation.
> 
> Signed-off-by: Philippe Mathieu-Daudé<philmd@linaro.org>
> ---
> Good enough for now...
> ---
>   cpu-target.c         | 9 ---------
>   hw/core/cpu-system.c | 7 +++++++
>   hw/core/cpu-user.c   | 5 +++++
>   3 files changed, 12 insertions(+), 9 deletions(-)

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~


From xen-devel-bounces@lists.xenproject.org Sun Jan 26 21:35:45 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Jan 2025 21:35:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877356.1287510 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcAI5-0002h3-LX; Sun, 26 Jan 2025 21:35:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877356.1287510; Sun, 26 Jan 2025 21:35:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcAI5-0002gw-Ig; Sun, 26 Jan 2025 21:35:37 +0000
Received: by outflank-mailman (input) for mailman id 877356;
 Sun, 26 Jan 2025 21:35:36 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Vl/L=US=linaro.org=richard.henderson@srs-se1.protection.inumbo.net>)
 id 1tcAI4-0002gq-Cb
 for xen-devel@lists.xenproject.org; Sun, 26 Jan 2025 21:35:36 +0000
Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com
 [2607:f8b0:4864:20::636])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 78ef9286-dc2d-11ef-99a4-01e77a169b0f;
 Sun, 26 Jan 2025 22:35:34 +0100 (CET)
Received: by mail-pl1-x636.google.com with SMTP id
 d9443c01a7336-2164b662090so72058995ad.1
 for <xen-devel@lists.xenproject.org>; Sun, 26 Jan 2025 13:35:34 -0800 (PST)
Received: from [192.168.0.4] (174-21-71-127.tukw.qwest.net. [174.21.71.127])
 by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-21da3d9c552sm50455215ad.18.2025.01.26.13.35.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 26 Jan 2025 13:35:27 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 78ef9286-dc2d-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737927332; x=1738532132; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=u0m5yL8s0TWSEEfxviVLYoEbDIw5bajMGnLn0okjgqc=;
        b=zK6rk0zU1Gui0fVQjM7n4PH2mUStiW4oL/uxFpSjU1rHho8LJy8QAaZbvbWsOpBho7
         Ufw4tUFIp1MEfZLHFYPxXNAlvssN1sCCOm83l4NrgPLO3IeGFe8T91JD1AaKFpLBR9wD
         D1S4pF5V7GJOlm4wrzL82qVpHGbbaSPbAauD0COs9LHOFP+7bqbwUXpJlHacQ2JKhKfX
         lMzL0wxCJjg/fGzw/0jAcQaeEsFDWZgSS5oRqut/v6pxlY6AIyapu19NHdNDiMQDXMDX
         N3Tj7+dTkIbTCHGlLm0AUuoxtzCDhrVLnNuPEyVDi21AKdewzIp2yB0Wb2CZBMmipV6K
         MKNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737927332; x=1738532132;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=u0m5yL8s0TWSEEfxviVLYoEbDIw5bajMGnLn0okjgqc=;
        b=idNdlIygjNrZCPeK6PBvvrzzlTeKiMEGTf9cp8ApjkccqIvscu/0QYcWS0rYzlhnhg
         fdOU4H0Fa3l7lB9OwLkY34JYl7y7DCu2uMw1Bed2WbeOVqbZT/WEy5ptXKFELb1wCWzF
         VN1c5Dz0/HiIxvMsG9YNy4Vp8uOo7MtTsBC+3RmxwmUHhTIkstZLJ5CI/2d0jKlSIRNl
         +P1lVGdsDejLchzFWrcapraIH0jSQaZ28lEcz+7UStmnAiiZlj+sgdcbZRHQCElg3zOL
         CGsehHin0WVCn7KNnIulWyJaFgAVGEsmWHia+ZeRHwnzSo3rYjdcgUjRBUadesl2b/R8
         6raA==
X-Forwarded-Encrypted: i=1; AJvYcCUX0Pv6ZJvUadbC/trtRGK1uhRKIsAUC+KBeOwCLx8+C11BbRdKsdTTHV1uwDfmlVwFukJZ8HHQgD0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwN8vdQF1LW5U2o16r6JxCbI+qAK/H6471yBp+zpq/pih49422X
	hS0SKWFH1kGAprxFCmzJuMHQMymN07CGbOfsVN1HekC62FTO6GwGXJ4U9ts9CPA=
X-Gm-Gg: ASbGncu6P9IK5yX+GsxZZmV27p6+LrIEqYxa8IaLCS+N77kexqveOz+Xnjf7dMTZVmr
	yt3Z7gpYJpctW+Cz6GBVjK/Ie133ZCt9w/ZkGWNxanEIE/ciCFJrYCZV+4P3YRO3d5HXpM0p7+h
	ehS+Pq0mI+6elzQNtPKazOJzr3BHw8IlCIdXYRnOC41pzHX38WIURkF7JJ1V5Vf+BVkKwQr6yK2
	14wF9zFrlLp8hcYfDI4eZ2lDiDKcYtkLNOvWHN5xXLKu2KRGpOwQ+xU4aAxiH4qCHQSN9AtHsO1
	xqGxpA3CHvlmPyAweLq1Bz11ryeARFTNh5Wmtvb8M02fSQo=
X-Google-Smtp-Source: AGHT+IF/uxXXMxK7HfifMI4lK/bjNl3NXv2LfDusZSj5Oq6BRtJb3xCpVAH5ppeGMpTK7NLB5Z4iRQ==
X-Received: by 2002:a17:903:191:b0:216:3466:7414 with SMTP id d9443c01a7336-21c355f6a9cmr669165345ad.44.1737927327477;
        Sun, 26 Jan 2025 13:35:27 -0800 (PST)
Message-ID: <4de30644-618d-4914-a1c6-008992c7edff@linaro.org>
Date: Sun, 26 Jan 2025 13:35:25 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 19/20] cpus: Register VMState per user / system emulation
To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= <philmd@linaro.org>,
 qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
 Paolo Bonzini <pbonzini@redhat.com>, qemu-arm@nongnu.org,
 Igor Mammedov <imammedo@redhat.com>, =?UTF-8?Q?Alex_Benn=C3=A9e?=
 <alex.bennee@linaro.org>, kvm@vger.kernel.org, qemu-ppc@nongnu.org,
 qemu-riscv@nongnu.org, David Hildenbrand <david@redhat.com>,
 qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org
References: <20250123234415.59850-1-philmd@linaro.org>
 <20250123234415.59850-20-philmd@linaro.org>
Content-Language: en-US
From: Richard Henderson <richard.henderson@linaro.org>
In-Reply-To: <20250123234415.59850-20-philmd@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 1/23/25 15:44, Philippe Mathieu-Daudé wrote:
> Simplify cpu-target.c by extracting mixed vmstate code
> into the cpu_vmstate_register() / cpu_vmstate_unregister()
> helpers, implemented in cpu-user.c and cpu-system.c.
> 
> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> ---
> XXX: tlb_flush() temporary declared manually.
> 
> Only 2 more CONFIG_USER_ONLY to go.

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

> --- a/hw/core/cpu-system.c
> +++ b/hw/core/cpu-system.c
> @@ -22,10 +22,21 @@
>   #include "qapi/error.h"
>   #include "exec/address-spaces.h"
>   #include "exec/memory.h"
> +#include "exec/tb-flush.h"
>   #include "exec/tswap.h"
>   #include "hw/qdev-core.h"
>   #include "hw/qdev-properties.h"
>   #include "hw/core/sysemu-cpu-ops.h"
> +#include "migration/vmstate.h"
> +#include "system/tcg.h"
> +
> +/*
> + * XXX this series plan is to be applied on top on my exec/cputlb rework series,
> + * then tlb_flush() won't be declared target-specific in exec-all.h.
> + * Meanwhile, declare locally.
> + * XXX
> + */
> +void tlb_flush(CPUState *cs);

Ack.


r~


From xen-devel-bounces@lists.xenproject.org Sun Jan 26 21:37:33 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Jan 2025 21:37:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877363.1287519 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcAJv-0003Dq-Vg; Sun, 26 Jan 2025 21:37:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877363.1287519; Sun, 26 Jan 2025 21:37:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcAJv-0003Dj-SR; Sun, 26 Jan 2025 21:37:31 +0000
Received: by outflank-mailman (input) for mailman id 877363;
 Sun, 26 Jan 2025 21:37:29 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Vl/L=US=linaro.org=richard.henderson@srs-se1.protection.inumbo.net>)
 id 1tcAJt-0003Db-Rq
 for xen-devel@lists.xenproject.org; Sun, 26 Jan 2025 21:37:29 +0000
Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com
 [2607:f8b0:4864:20::1032])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bd504737-dc2d-11ef-a0e6-8be0dac302b0;
 Sun, 26 Jan 2025 22:37:28 +0100 (CET)
Received: by mail-pj1-x1032.google.com with SMTP id
 98e67ed59e1d1-2ee46851b5eso4989871a91.1
 for <xen-devel@lists.xenproject.org>; Sun, 26 Jan 2025 13:37:28 -0800 (PST)
Received: from [192.168.0.4] (174-21-71-127.tukw.qwest.net. [174.21.71.127])
 by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-2f7ffaf896csm5651556a91.34.2025.01.26.13.37.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 26 Jan 2025 13:37:26 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: bd504737-dc2d-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1737927447; x=1738532247; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=MbN5ftkFW90qPVFMQN7kThRB1jW5R9e9lwVcXv22rrA=;
        b=z6jaCheu/p4I1jjGljbnBLEjysV36Yrb9OvXAF2O7WJ8x7yoDAPxIeQ/iyQf3TKFhn
         sG+Z8g3ugUoQ50C/pTWwNSThWz73MhhM3HNNYlH73pNm/4nrhRDXfQAJqPUZfoJHYeWs
         4sxY1GI5QCwgSJytkwruxUcylbfIk+i8YezexTZu6lIQKenTWv7bD4i1B1Gx1B79JlNG
         +JCiywV3VN4q188FmsotTC9elQaa2thzJNmAb1Z4G10zkXt4ioIZqkE9nQPt1y3RNU2I
         NUWBahhh1EEl+1UenYnUsISgV+w86HToI81vffFLCjYgKAhkTzCuw9XWDFuThlFz3t/J
         jncw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737927447; x=1738532247;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=MbN5ftkFW90qPVFMQN7kThRB1jW5R9e9lwVcXv22rrA=;
        b=T6Ef7XNSgRrt/W/uV3r8+KHcDq/OiWagORvOBSASfmsa+5NarAp9yOUxgGKjkl3kqX
         HcyE7phOTC9nQezbWPpodT58tU/vq3dHLdKg+kVuIuFPKHtpwH2VP3N0W03i9/WMjwDz
         KYEHEHPfQ/TVmz5oVd6CR7sWUaQFz253P03DVGMjJPPTvP7MYxLjXl5yRU+E4TxZqrOJ
         U5FgwvdOQBzNsP7NujsgZY971xTSD/Y8oX5RgmVd2t/rjWWDjSjuw3LYMpodVkq+egXk
         bqtIaacPyXE3haitAK49mtAjv+n3B2Yq63Xpu4se+ja7O5D/NVXzFi6Q87NghQtKdbLw
         vYSw==
X-Forwarded-Encrypted: i=1; AJvYcCWduke+VfY+9Kzxn6DQJgJ2xLrP6MBTCCeZQQr7EhxvQJjSNJ2L64bOaUjwMcpaa3Sqw1GF2mYkx3A=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwuH4Nm4wyRLZqMHSodK0LH4uaLW4jFhnMnAomoISAxMDgnFoqg
	W7UOoqM9D7r5B3PeB5HGgyBIYulY41SwivdfO/SYWQ5ZWXATTWzyBq4OgllbRMg=
X-Gm-Gg: ASbGncuK1gA8Aq02PJJME8eyALSSm1xJfBU34SmrC+ZCBJqh5qZz9qjQ2UlwJHczsqt
	BArJtpN/XkV8ToW6+Low7BI87xQ7To/FJ6OqkmH7r1xH69cAHy5t4w0sQzwMrfMpEWLH3zPgkAw
	vqEjCv9HJA40BuUXig1vIj5Nl2oEfEfccYAdIEV+ApqVuZdswBa45XalhapMW+Yv9JxLFW6+bLJ
	lcb00rk+hS8XAODxYGevQVT60SsNTnMFLEqsmexq4ccjqdwIP5iP8ocE++M2hAbenQ6FGPuhP5d
	i9ExyLcpZQ5jpTveLneNShcVC6B7uNF23AtBK8I1mxBNjt8=
X-Google-Smtp-Source: AGHT+IFiuSNxM6E2NLFZz0UKT8aL9HnJkIEUZ+PxBPmebPJCN8+PDu1ajnV9q5XziLSw+N+w1RiQzQ==
X-Received: by 2002:a17:90a:c888:b0:2ee:f687:6ad5 with SMTP id 98e67ed59e1d1-2f782c5174emr59291165a91.2.1737927447421;
        Sun, 26 Jan 2025 13:37:27 -0800 (PST)
Message-ID: <46ab28c5-d417-4b83-97d2-b2ba49f7abfa@linaro.org>
Date: Sun, 26 Jan 2025 13:37:24 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 20/20] cpus: Build cpu_exec_[un]realizefn() methods once
To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= <philmd@linaro.org>,
 qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
 Paolo Bonzini <pbonzini@redhat.com>, qemu-arm@nongnu.org,
 Igor Mammedov <imammedo@redhat.com>, =?UTF-8?Q?Alex_Benn=C3=A9e?=
 <alex.bennee@linaro.org>, kvm@vger.kernel.org, qemu-ppc@nongnu.org,
 qemu-riscv@nongnu.org, David Hildenbrand <david@redhat.com>,
 qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org
References: <20250123234415.59850-1-philmd@linaro.org>
 <20250123234415.59850-21-philmd@linaro.org>
Content-Language: en-US
From: Richard Henderson <richard.henderson@linaro.org>
In-Reply-To: <20250123234415.59850-21-philmd@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 1/23/25 15:44, Philippe Mathieu-Daudé wrote:
> Now that cpu_exec_realizefn() and cpu_exec_unrealizefn()
> methods don't use any target specific definition anymore,
> we can move them to cpu-common.c to be able to build them
> once.
> 
> Signed-off-by: Philippe Mathieu-Daudé<philmd@linaro.org>
> ---
> Eventually they'll be absorbed within cpu_common_[un]realizefn().
> ---
>   cpu-target.c         | 30 ------------------------------
>   hw/core/cpu-common.c | 26 ++++++++++++++++++++++++++
>   2 files changed, 26 insertions(+), 30 deletions(-)

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 00:30:07 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 00:30:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877382.1287530 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcD0f-0006xB-MX; Mon, 27 Jan 2025 00:29:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877382.1287530; Mon, 27 Jan 2025 00:29:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcD0f-0006x4-IF; Mon, 27 Jan 2025 00:29:49 +0000
Received: by outflank-mailman (input) for mailman id 877382;
 Mon, 27 Jan 2025 00:29:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=8klh=UT=amazon.de=prvs=1155a3140=graf@srs-se1.protection.inumbo.net>)
 id 1tcD0d-0006ww-Lv
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 00:29:47 +0000
Received: from smtp-fw-80007.amazon.com (smtp-fw-80007.amazon.com
 [99.78.197.218]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id cdc7fa86-dc45-11ef-99a4-01e77a169b0f;
 Mon, 27 Jan 2025 01:29:45 +0100 (CET)
Received: from pdx4-co-svc-p1-lb2-vlan2.amazon.com (HELO
 smtpout.prod.us-west-2.prod.farcaster.email.amazon.dev) ([10.25.36.210])
 by smtp-border-fw-80007.pdx80.corp.amazon.com with
 ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jan 2025 00:29:41 +0000
Received: from EX19MTAUWA001.ant.amazon.com [10.0.21.151:16822]
 by smtpin.naws.us-west-2.prod.farcaster.email.amazon.dev [10.0.6.79:2525] with
 esmtp (Farcaster)
 id cfa39458-8857-455d-858b-eff9b0664ce4; Mon, 27 Jan 2025 00:29:41 +0000 (UTC)
Received: from EX19D020UWC004.ant.amazon.com (10.13.138.149) by
 EX19MTAUWA001.ant.amazon.com (10.250.64.217) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1258.39;
 Mon, 27 Jan 2025 00:29:41 +0000
Received: from [0.0.0.0] (10.253.83.51) by EX19D020UWC004.ant.amazon.com
 (10.13.138.149) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1258.39; Mon, 27 Jan 2025
 00:29:33 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: cdc7fa86-dc45-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209;
  t=1737937785; x=1769473785;
  h=message-id:date:mime-version:subject:to:cc:references:
   from:in-reply-to:content-transfer-encoding;
  bh=1CW7QrQuY535yIxYdxvZyKWa4nCyH6ZLrqRFGNx49Oc=;
  b=obhHzxUu1ArY1/U6JnUF90YSTjl0EEMiXwtaCsNxC5ydQ167KON2tIBh
   dA2GEZXRntLNA33lzaiOBxZjZjbbSfNQdqkHhtC12lRyHPa21pI2S4AgC
   BmwjXXrHUrUMcZ34sp5olw7C6wcT4J+77z/WP/wmvKLzn6qnc2tmyzT24
   w=;
X-IronPort-AV: E=Sophos;i="6.13,237,1732579200"; 
   d="scan'208";a="372062737"
X-Farcaster-Flow-ID: cfa39458-8857-455d-858b-eff9b0664ce4
Message-ID: <890f3e12-a511-40a0-a3c3-d7134b470a1f@amazon.com>
Date: Sun, 26 Jan 2025 16:29:29 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/9] hw/sysbus/platform-bus: Introduce
 TYPE_DYNAMIC_SYS_BUS_DEVICE
To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= <philmd@linaro.org>,
	<qemu-devel@nongnu.org>
CC: Yi Liu <yi.l.liu@intel.com>, Markus Armbruster <armbru@redhat.com>,
	Eduardo Habkost <eduardo@habkost.net>, Anthony PERARD
	<anthony@xenproject.org>, Gustavo Romero <gustavo.romero@linaro.org>, "Jason
 Wang" <jasowang@redhat.com>, <qemu-ppc@nongnu.org>, "Michael S. Tsirkin"
	<mst@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>, Richard Henderson
	<richard.henderson@linaro.org>, Stefan Berger <stefanb@linux.vnet.ibm.com>,
	Bernhard Beschow <shentey@gmail.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Gerd Hoffmann <kraxel@redhat.com>,
	=?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= <berrange@redhat.com>, "Edgar E.
 Iglesias" <edgar.iglesias@gmail.com>, <xen-devel@lists.xenproject.org>,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>, Alex Williamson
	<alex.williamson@redhat.com>, Paul Durrant <paul@xen.org>,
	=?UTF-8?Q?Cl=C3=A9ment_Mathieu--Drif?= <clement.mathieu--drif@eviden.com>,
	=?UTF-8?Q?C=C3=A9dric_Le_Goater?= <clg@redhat.com>
References: <20250125181343.59151-1-philmd@linaro.org>
Content-Language: en-US
From: Alexander Graf <graf@amazon.com>
In-Reply-To: <20250125181343.59151-1-philmd@linaro.org>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.253.83.51]
X-ClientProxiedBy: EX19D037UWC004.ant.amazon.com (10.13.139.254) To
 EX19D020UWC004.ant.amazon.com (10.13.138.149)


On 25.01.25 10:13, Philippe Mathieu-Daudé wrote:
> Some SysBus devices can optionally be dynamically plugged onto
> the sysbus-platform-bus (then virtual guests are aware of
> mmio mapping and IRQs via device tree / ACPI rules).
>
> This series makes these devices explicit by having them implement
> the DYNAMIC_SYS_BUS_DEVICE class, which only sets 'user_creatable'
> flag to %true but makes the codebase a bit clearer (IMHO, at least
> now we can grep for DYNAMIC_SYS_BUS_DEVICE).


I love it. Thank you! This is clearly much more readable than the 
magical hint swizzling I did :).

Reviewed-by: Alexander Graf <graf@amazon.com>


Alex



From xen-devel-bounces@lists.xenproject.org Mon Jan 27 06:15:09 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 06:15:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877403.1287540 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcIOd-00087M-K1; Mon, 27 Jan 2025 06:14:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877403.1287540; Mon, 27 Jan 2025 06:14:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcIOd-00087F-H3; Mon, 27 Jan 2025 06:14:55 +0000
Received: by outflank-mailman (input) for mailman id 877403;
 Mon, 27 Jan 2025 06:14:53 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=50Ot=UT=eviden.com=clement.mathieu--drif@srs-se1.protection.inumbo.net>)
 id 1tcIOb-000872-76
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 06:14:53 +0000
Received: from smarthost1.eviden.com (smarthost1.eviden.com [80.78.11.82])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 040a6f6f-dc76-11ef-a0e6-8be0dac302b0;
 Mon, 27 Jan 2025 07:14:50 +0100 (CET)
Received: from mail-westeuropeazlp17011024.outbound.protection.outlook.com
 (HELO AS8PR04CU009.outbound.protection.outlook.com) ([40.93.65.24])
 by smarthost1.eviden.com with ESMTP/TLS/TLS_AES_256_GCM_SHA384;
 27 Jan 2025 07:14:48 +0100
Received: from AM8PR07MB7602.eurprd07.prod.outlook.com (2603:10a6:20b:24b::7)
 by PA4PR07MB8792.eurprd07.prod.outlook.com (2603:10a6:102:266::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.22; Mon, 27 Jan
 2025 06:14:46 +0000
Received: from AM8PR07MB7602.eurprd07.prod.outlook.com
 ([fe80::fbd7:ca71:b636:6f9d]) by AM8PR07MB7602.eurprd07.prod.outlook.com
 ([fe80::fbd7:ca71:b636:6f9d%7]) with mapi id 15.20.8377.021; Mon, 27 Jan 2025
 06:14:46 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 040a6f6f-dc76-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=eviden.com; i=@eviden.com; q=dns/txt; s=mail;
  t=1737958491; x=1769494491;
  h=from:to:cc:subject:date:message-id:references:
   in-reply-to:content-id:content-transfer-encoding:
   mime-version;
  bh=CAQbx6bVUkOqbYZAAavrHDY9le2cUdZVdJsvPtn/D4o=;
  b=kB2ao8DlIOvZ4hBQRlY/OCXakfY93qR8Lng+56/OSRDthGfcEgfHUzjy
   KN3kh7kuvL2Tm1FaHmWKEipUZsABD67cvgvAm4Kf7St+XViei5qNZ9evo
   XFvS5EN6/Rtpw114yRCQNWMe/S+9SfZykgRJn1ugmvQF+ZxJ+qeRPgaok
   GM+AcgCE1HCiIOUATapSjjTMo7Y6FSVoJ8J+Mi/czVoFLVn9II2FJYS6S
   efliZzHNJhg13NnN1m+nE5w5d5CpjQU34MDl+bg2ziFxxUw4JwGAcjUqh
   mxCx50r6xMfhOWPheI3JkWgTUQ+nshrHF2VKHne80Mp1y6gZw9R6dGQlP
   g==;
X-CSE-ConnectionGUID: shTfnFYfR6eLUQvpLlTfdw==
X-CSE-MsgGUID: cH5UVHijSi6kXONTYd1W8w==
X-IronPort-AV: E=Sophos;i="6.13,237,1732575600"; 
   d="scan'208";a="29566783"
X-MGA-submission: =?us-ascii?q?MDHYPTJJUQEwGh3DCAkM8lnmAAdvGqGRQJQPfB?=
 =?us-ascii?q?Oams2qflgMvrESholn7IHoPmarYjVx4sOELZJSaypGrDwLk9gqKeifIc?=
 =?us-ascii?q?nyavAerdNf/2qcIyWKHPQj6vTpObcpehdGymhxS7MTUwoCvcGmjSBr+u?=
 =?us-ascii?q?mN+nSdoINgLz0Zha+cs26APw=3D=3D?=
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Vz7irmhebvmJIdFEupMlP6sI9fFeG6uuRnj1pkcX+KIZLfLlOkuIoHTYxVocULQSJpELaizRv5tp9hvG4AOChpE2G0voaTi/GtUKNYV05iwfHJJMBxldooJbXr+gS7xtSv5JPKX3yJfcYnMA8s+7vGvoJmfLv0U1TzSGHCmQYnEudD1u0eibl/BQVCEq2xARdnc2yMjyx5TQ+JVb8ikOxTbXHTR74Y9DECcCK1wqeOzNvpFAfnyRzzWqT9Hd9M/B4bFLAd5FZDYh99JfwsTTIAzzCc63SG7Ns7rGaDBpwQiWPbeSmar2ArhlZiEAm5mL0gnssJKajekXU0BClLUkCw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=CAQbx6bVUkOqbYZAAavrHDY9le2cUdZVdJsvPtn/D4o=;
 b=nK0Ucq9+Zn610pfTOLHtfLdAIwBoR9qdMZ0+A0PT7No/l7+E4VCdrrOYE1jUQnVbc0ina4mnCBrwrfqSThJ2k0odBsDydg4L7c0QKNmbb3JlWtWTG08ExydX0y8dqzwze7ih7Dv5AJIr6e0EQPgAcszn+sUtxImK5nOKtRF7RFg+YpfHIUTyXWBMpnpzrgnv7uU+wuc5o53mHHOuBetEfTsG6ehym3oYirpYSIHYqKNwCpBs5mOdl5gV9pPQo6T8sPoBJvDj0eod+sg+lA07PELeYMAjxPUVYVrXUdD8KO6wU7grFaub4HPeAUyyAfjTCt7f0CSOv8xGDSL98WKgKg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=eviden.com; dmarc=pass action=none header.from=eviden.com;
 dkim=pass header.d=eviden.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Eviden.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=CAQbx6bVUkOqbYZAAavrHDY9le2cUdZVdJsvPtn/D4o=;
 b=mB3TEOiVqOKR7l/JgM1TtJPqGl/oy/vtHVnvaS+/mUbN33VbWtdxOPXOY0nwhMoswGV4q8FNVja9CB0svygHPrRut6Uz9WBrj292cRZZv+fq5O7PIe0SrHkp1Iff7DIQduwFuAskrAt2lD+VHmu/Zo0vA+P3Id4aKX0cFedI8ShqV1KjUMX4BEk9Nxyzi4wkslaBQ164xttWIhVOZU5bS6EQVoWpo8JOcYETWCSlmVKIXeR4ovevf+hLqYrHajI4mueY7DfPDThk4JUl45wnXtmZgHQ9nWE92/pPWD8ArnE9THGknOUhhlx6TdCxwhy4PizUkPGlcSqeGJRUjHozZA==
From: CLEMENT MATHIEU--DRIF <clement.mathieu--drif@eviden.com>
To: =?utf-8?B?UGhpbGlwcGUgTWF0aGlldS1EYXVkw6k=?= <philmd@linaro.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
CC: Yi Liu <yi.l.liu@intel.com>, Markus Armbruster <armbru@redhat.com>,
	Eduardo Habkost <eduardo@habkost.net>, Anthony PERARD
	<anthony@xenproject.org>, Gustavo Romero <gustavo.romero@linaro.org>, Jason
 Wang <jasowang@redhat.com>, "qemu-ppc@nongnu.org" <qemu-ppc@nongnu.org>,
	"Michael S. Tsirkin" <mst@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>,
	Alexander Graf <graf@amazon.com>, Richard Henderson
	<richard.henderson@linaro.org>, Stefan Berger <stefanb@linux.vnet.ibm.com>,
	Bernhard Beschow <shentey@gmail.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Gerd Hoffmann <kraxel@redhat.com>,
	=?utf-8?B?RGFuaWVsIFAuIEJlcnJhbmfDqQ==?= <berrange@redhat.com>, "Edgar E.
 Iglesias" <edgar.iglesias@gmail.com>, "xen-devel@lists.xenproject.org"
	<xen-devel@lists.xenproject.org>, Marcel Apfelbaum
	<marcel.apfelbaum@gmail.com>, Alex Williamson <alex.williamson@redhat.com>,
	Paul Durrant <paul@xen.org>, =?utf-8?B?Q8OpZHJpYyBMZSBHb2F0ZXI=?=
	<clg@redhat.com>
Subject: Re: [PATCH 6/9] hw/i386: Have X86_IOMMU devices inherit from
 DYNAMIC_SYS_BUS_DEVICE
Thread-Topic: [PATCH 6/9] hw/i386: Have X86_IOMMU devices inherit from
 DYNAMIC_SYS_BUS_DEVICE
Thread-Index: AQHbb1T1v1PK9knjfUCFEoU3xo3CqLMqJsYA
Date: Mon, 27 Jan 2025 06:14:46 +0000
Message-ID: <34e2ee31-2b06-4e8e-ab94-d9aa3f12e909@eviden.com>
References: <20250125181343.59151-1-philmd@linaro.org>
 <20250125181343.59151-7-philmd@linaro.org>
In-Reply-To: <20250125181343.59151-7-philmd@linaro.org>
Accept-Language: en-GB, fr-FR, 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=eviden.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: AM8PR07MB7602:EE_|PA4PR07MB8792:EE_
x-ms-office365-filtering-correlation-id: 569286dd-ee53-438d-1aae-08dd3e99e5d0
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|366016|7416014|376014|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?aW9UblBwZ2R5RW1tb29OMFhzWlhyUkowN0JzdUNLcTlDRGxVamlrOTVrRGVB?=
 =?utf-8?B?cDdjSS9SWGRSdU5pUzBRT2VFK2hyNmdoZUczWWlpYjFJYlY1ZHc4eks1S2pL?=
 =?utf-8?B?SW1ZMGJLTmNJT1BTTTgwencxbjdER3NVbkNRSXlCc1dFMGVLQXlHdFlPYnVY?=
 =?utf-8?B?OENLMUFPNWFvTWE3UzRlTEx0bFpMZzk1Ym1tYzQwRDcwYTJYODhuM2FDdGlB?=
 =?utf-8?B?T2Z2amRzY3lOZmgxaUxkMElreXpsaGk0dHpjaXRzT1YzejViUC9BRVFvRndJ?=
 =?utf-8?B?YmJhSnY3OTlWZnh5RUZ1M3VSN0U3Y2kzTGx5aFNKeXFOODhTTFNGT1VNWEJk?=
 =?utf-8?B?WWJiaGcxUEgwaVFaRHJZRncrWGQ0dWgxczhyek9aU2hZL2owRUFiWjN2MW1h?=
 =?utf-8?B?MXZaM1RuNTJJVDloRjlDSzZicUc0VlRrSmNuMmlOZ2N3UkQ2UFFOeVhKYjZh?=
 =?utf-8?B?Y0o0QnBRTlpXTmhyVUVIdGQ3OHZRTGJFWnRyUmtyUCtidTB1YmU2NjkzaW8v?=
 =?utf-8?B?U1dOMHhyYTdBdEl1WEtNcmk0Q2liQWhSc0xZdjdwdG0vQkcrTFp3YVJBZTUz?=
 =?utf-8?B?Z0tXdERhVU84MXR1U2k3NmtFYy9rSlBKSU0ySWMvc3ZNRWtrYUFkMjY3bkJp?=
 =?utf-8?B?Z0dmNVBxRDlWZWNQM2pGZ2h3REN3M29yZEhKemdpMjBFT1VBRU1oN0JxRDl6?=
 =?utf-8?B?ellvWXJzSFR4ODY4c3d5dFlnbFRSR2ZyMXR2NytMU0F2cUFXVi9YMlI3elJk?=
 =?utf-8?B?d0ZCdW4vQ01ReVhwSDQvbHIrSVNiejFxOUVFL2k4WmFhSjg0ZnhuanpQRWZK?=
 =?utf-8?B?T2IyTzR4UzBEaHZvVUhqc0tDOTNjMnNXZlAyUi85d1RkRm1qOUpDYU9aSFUy?=
 =?utf-8?B?Tm5PVkJvRThXeU92ZDVCcUMxZGdnc1U3eUtkK1RPNjZQakw3UlVhN2xXVU14?=
 =?utf-8?B?ZnMxQ2NheVFUQ0xPNlpwcm5Eb0JJVWpOYXQ4bzQwcVRKcUZIeUVSUHhvRi8r?=
 =?utf-8?B?TWcra2RKOVZFbXczMFlCOFV6Q1pjMGFxckl0alhObXpYWHNiSkg1V2lUTWVJ?=
 =?utf-8?B?SkhLZnY0dFNIaG1sRS9Ka1ZIM2xNcjc1V2xtMGIyZk5vQXF6ZWVrekd3ai8r?=
 =?utf-8?B?QU5ySG5ESFR4Zmh2R1p1YWZ4QUpSVVlHMENvdDQ5R25LRGhmT3pLWS9HZVVW?=
 =?utf-8?B?SW5TOGNFemlRdmw4UFJrZ2d2S1FXS0ttcmhRK0hLcUlzeCtWS1VYR3JYWE51?=
 =?utf-8?B?aVhBVG9STy9WaGtRaG03TDZ4T1BRZ1pJRTRhNS9reXgxK2g4cE8yU2tSMm9B?=
 =?utf-8?B?ZnZmaE1SY0Ezb0xFNERFcThuaEREWEF3ZW9pNVNWUzZObnFwemRSRGp2S3E5?=
 =?utf-8?B?TWZEaHZ4TlJFS1p4VWJ2cVFIMWNLSWUrZ25DOUZKTjc2STZ4Ylh2b0VieTVH?=
 =?utf-8?B?NzgveUJxeVJSRUtsU2YvMUlLUlJCUGZuNG1UZXk3UG5mV0tOdDJVZjRmaGZO?=
 =?utf-8?B?L0JDVXk3aDN2R2hYL0hVc0ptY2V3b0hPaERnU2tNQVI3RlZNZzlXd2QrSVJJ?=
 =?utf-8?B?VkpqWEZDVGJJUkE2RWlVOHRNNWhHcWRsL1pGdjFTbFp6djFNTGxTSEVtN05V?=
 =?utf-8?B?WXZXcnJLNnEwSkN4T05hS2NiOWt6K3prSmNzOVczajI5cUZac1BWcG5PS3F2?=
 =?utf-8?B?Nmw5d0VLOUM4YUhtOEhKY0krVE9NRGJTd2dEWVBXMmFHaW9uWWcrVXk4M3Jy?=
 =?utf-8?B?ZXV3OEJOeEpHL1Fjbjljc0dBcmthM24zMjhTRm9QQ29ocGpuYTJOS0lHcE5Y?=
 =?utf-8?B?Q2I5d283eVNndEVFWlUyZjVwbHR3Tm5jWlpsK2hkLzZSU0pFcmlCTzlYZFVj?=
 =?utf-8?B?TDdJczh2UnZrZHB3aG9Yc0lXeVo3bWJPb09nc0FXQndvR3VTdlpJT0szMXJi?=
 =?utf-8?Q?Q6UTWsnXOvXdPlZCQcSnQ++Q0LUQ5OvI?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM8PR07MB7602.eurprd07.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(7416014)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?WWtHRmhZWFlJZm52MVhGNHZwQ1BpenJrSVhMdmZVQ2FJS3k3ei91TjBCMVRw?=
 =?utf-8?B?K1VTN09qVWNGTy80SU5LMXdoSGQyVytTS3dBeTBkQ1B0dXhEMCt2QTBSNjN6?=
 =?utf-8?B?bTByaUlLSXNxV0lnaFZlSitNakpQRmhrWHI5Z3hNb2NoSldZbUhUcUhXWlNr?=
 =?utf-8?B?UDNsamJjMGV6ZXdUcm1maGtLZlpwOWgxbXhPZlRweitZSzhoQnFJdG1FeXRG?=
 =?utf-8?B?VlJIY1p0VmVJbmt0THlTR1QzZ3dFK1RGZVgwaG96WmpuSnVPNDhOU0p0MlVx?=
 =?utf-8?B?M1lvOWd0RFdvb2d0TTJVK2xvK05Uc3B3MS9rL25hQ1ZRUFArN1NhMzVEU3VQ?=
 =?utf-8?B?VzdKL25QbmFyZmMvL1labE9nVGFjTjkwUTRXYWFIaCs0S1NsMWRHc0tqODFP?=
 =?utf-8?B?YnpROHdhd3JXZlBDang5VFBHcXhwSExZNFQ2bWM5QnhmME0rRDhNb285VUda?=
 =?utf-8?B?Ymx1cVJBL1JUczBFRjM1NkF0WnByMWkvT0N5NFRHNlBpWDBCZlFxdVQyQXJl?=
 =?utf-8?B?UnNSdS8rSWZmZEgrM2lCL3J3azc0VFRYcG84bGJpSmozZjloa0VtL3BDT0kz?=
 =?utf-8?B?MFN6M2pMNDBkVkJ3bjlWd0FVc2IzanpNUVp1anJRV2tUd05jekJqUk93R1pv?=
 =?utf-8?B?RHQxcENoTG1nVzNUQ2VONUlodW1OU2ZlSW5UWjVXMWFqNy9YaWlUR21Mby9P?=
 =?utf-8?B?cGhPUDhIc3oxNy9IcTVvNG5pOTZObElQVSt1RmM5T1UrTTJKalNoZzlGekJl?=
 =?utf-8?B?dVZ4L0x5Ni9hVFRvTXdEdWRFMW4rc25aNmJldlY1T2NjRlpQL3JoZkNGTFpV?=
 =?utf-8?B?QjNuOGZkNkV6VmRqdkN0YnBnbkxIZTg1d0ZNUC9Nbmw1WjVzM3ZzUVlXZEoy?=
 =?utf-8?B?dWZGRG1DcjVXdnMrekxLVWF4QVF0Ny9lWVlqcUFiTXRaQ1VmdkZZRU5PZnkv?=
 =?utf-8?B?QjVyVzdtZFNibHhkWVRrd3FEdnEzUklCNGNsdmZyOW13MDFPZHJzT0Uvc0xK?=
 =?utf-8?B?eXdkZ2Q0VUVVUjVDTUJ5T01FZXZhL3V6NnQxR09YLzJhdHJqdUpkSWFYRWwr?=
 =?utf-8?B?K2lNVkpDWVJIVE11aU9sTWNPejZucDJEWVVnb3BZS2QwVFFpQ053ODNZUjNE?=
 =?utf-8?B?NHRpRURuOXgyb0JlaDhFZGFCMEcvYlR3T2NmUVEzWWFkVnozZEFtek4xL1pz?=
 =?utf-8?B?Mmtpek1rZ0MyTXhCd0Zka3pJM3hLWGdYYVdNSmtFMmJITUxIMmZHaS9LUjk2?=
 =?utf-8?B?UEYySlIxaUYyMUFnTTFsQmF0YXNiay9oNWpFd1J3bGluZXZrcjc4V29FTVha?=
 =?utf-8?B?REczbytCVFVWZWQyU0ZMOTQ5dUJqblVNMEZSUElUeTJrZGhIZG9nSHVuaUx0?=
 =?utf-8?B?VlI2M1c4eVMzblhwM3R1UFNGa3JPck10K21Gd08zNkZnVThRalJiZnB3YmFD?=
 =?utf-8?B?WTI1YURWaUxKd0hvM2U4c21DdjdPV0NhV1gvV1NSY2RIcy91elhXdDBHa2NX?=
 =?utf-8?B?c2VtUFNhM2w2a2lTQnpuMmR0Y2g0UHFPekRnNUpZMEhQOThyY0prWUZtZkZ5?=
 =?utf-8?B?RTc3aXpXbHN5VW8zV1FDekJ6WjF4NzZ6byt5YUV0RGtSSVpFTUNibGJFSGQ0?=
 =?utf-8?B?OFZ3VGI2YWVKMFdadGYvZmgvWGZ6Qk9ZVmtWNklSczFZUURyRzhMVHdQQU0w?=
 =?utf-8?B?NlFUNjRXODFhdWFqdVN0d2NFSzZUYTJEOEYrMHBDRkdzQ2pMc25ZT3Q5Q0dt?=
 =?utf-8?B?MVI2elZ6Q2ZmaTB2dWxzb1lUNVAwTTdEUCthWDdnMkpOdE4vOTlCRnVXcllG?=
 =?utf-8?B?VUVPeFdKRk9uSVczRFlPSytpZytQNDYxYXNyRXFucmlmWE8ySGY5dUpYUzNJ?=
 =?utf-8?B?STNIQlFDMTZHMTNXUi9DekVXOTllei95ektjdFRvbVA5TWNLY0hLMGljbWov?=
 =?utf-8?B?NnUrY3JMT2NWZVc2TjMveGxvNlNieW4xaHhSejRaejFlSkE1WitoNEVjSVdV?=
 =?utf-8?B?QWR5Ti9FK3hpR1hZU29PNDRzNkhUSEcrREFlMy9uU0N2bUFMMUh3cTlmdVMr?=
 =?utf-8?B?QWJvMGtSQmh5cTdJdFJkQ3lRTWVhbzdzZUJDWUQxL2Zxc0lkVmdQMW1acmFn?=
 =?utf-8?B?RGI5a3BBRi9KMXBJZ2Y5TXNmclRueld6Z1NxZ3hKSG94M3JabllmejZCOU5q?=
 =?utf-8?Q?ANH2TrEfaQ5IIa+MgJRPvh4=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <45BFD4205F14614EA1B9DBA735457DEA@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: eviden.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM8PR07MB7602.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 569286dd-ee53-438d-1aae-08dd3e99e5d0
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2025 06:14:46.2746
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 7d1c7785-2d8a-437d-b842-1ed5d8fbe00a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: r+Iqv3HvT5WQ9j2V3PogI2DXM3v5+9AK2QzYmwGtS63IAxLrZtom2VrbQubvsmBtv2R+WzQLO22H40DDvR27QjRzV/fc+Zidv9v8AEa35UMSGbSZpaBIoID61DSKGNdX
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR07MB8792

UmV2aWV3ZWQtYnk6IENsw6ltZW50IE1hdGhpZXUtLURyaWY8Y2xlbWVudC5tYXRoaWV1LS1kcmlm
QGV2aWRlbi5jb20+DQoNClRoYW5rcyBwaGlsDQoNCk9uIDI1LzAxLzIwMjUgMTk6MTMsIFBoaWxp
cHBlIE1hdGhpZXUtRGF1ZMOpIHdyb3RlOg0KPiBDYXV0aW9uOiBFeHRlcm5hbCBlbWFpbC4gRG8g
bm90IG9wZW4gYXR0YWNobWVudHMgb3IgY2xpY2sgbGlua3MsIHVubGVzcyB0aGlzIGVtYWlsIGNv
bWVzIGZyb20gYSBrbm93biBzZW5kZXIgYW5kIHlvdSBrbm93IHRoZSBjb250ZW50IGlzIHNhZmUu
DQo+IA0KPiANCj4gRG8gbm90IGV4cGxhaW4gd2h5IF9YODZfSU9NTVUgZGV2aWNlcyBhcmUgdXNl
cl9jcmVhdGFibGUsDQo+IGhhdmUgdGhlbSBpbmhlcml0IFRZUEVfRFlOQU1JQ19TWVNfQlVTX0RF
VklDRSwgdG8gZXhwbGljaXQNCj4gdGhleSBjYW4gb3B0aW9uYWxseSBiZSBwbHVnZ2VkIG9uIFRZ
UEVfUExBVEZPUk1fQlVTX0RFVklDRS4NCj4gDQo+IFNpZ25lZC1vZmYtYnk6IFBoaWxpcHBlIE1h
dGhpZXUtRGF1ZMOpIDxwaGlsbWRAbGluYXJvLm9yZz4NCj4gLS0tDQo+ICAgaHcvaTM4Ni9hbWRf
aW9tbXUuYyAgIHwgMiAtLQ0KPiAgIGh3L2kzODYvaW50ZWxfaW9tbXUuYyB8IDIgLS0NCj4gICBo
dy9pMzg2L3g4Ni1pb21tdS5jICAgfCAyICstDQo+ICAgMyBmaWxlcyBjaGFuZ2VkLCAxIGluc2Vy
dGlvbigrKSwgNSBkZWxldGlvbnMoLSkNCj4gDQo+IGRpZmYgLS1naXQgYS9ody9pMzg2L2FtZF9p
b21tdS5jIGIvaHcvaTM4Ni9hbWRfaW9tbXUuYw0KPiBpbmRleCA2YjEzY2U4OTRiMS4uZThlMDg0
YzdjZjggMTAwNjQ0DQo+IC0tLSBhL2h3L2kzODYvYW1kX2lvbW11LmMNCj4gKysrIGIvaHcvaTM4
Ni9hbWRfaW9tbXUuYw0KPiBAQCAtMTY4Nyw4ICsxNjg3LDYgQEAgc3RhdGljIHZvaWQgYW1kdmlf
c3lzYnVzX2NsYXNzX2luaXQoT2JqZWN0Q2xhc3MgKmtsYXNzLCB2b2lkICpkYXRhKQ0KPiAgICAg
ICBkYy0+aG90cGx1Z2dhYmxlID0gZmFsc2U7DQo+ICAgICAgIGRjX2NsYXNzLT5yZWFsaXplID0g
YW1kdmlfc3lzYnVzX3JlYWxpemU7DQo+ICAgICAgIGRjX2NsYXNzLT5pbnRfcmVtYXAgPSBhbWR2
aV9pbnRfcmVtYXA7DQo+IC0gICAgLyogU3VwcG9ydGVkIGJ5IHRoZSBwYy1xMzUtKiBtYWNoaW5l
IHR5cGVzICovDQo+IC0gICAgZGMtPnVzZXJfY3JlYXRhYmxlID0gdHJ1ZTsNCj4gICAgICAgc2V0
X2JpdChERVZJQ0VfQ0FURUdPUllfTUlTQywgZGMtPmNhdGVnb3JpZXMpOw0KPiAgICAgICBkYy0+
ZGVzYyA9ICJBTUQgSU9NTVUgKEFNRC1WaSkgRE1BIFJlbWFwcGluZyBkZXZpY2UiOw0KPiAgICAg
ICBkZXZpY2VfY2xhc3Nfc2V0X3Byb3BzKGRjLCBhbWR2aV9wcm9wZXJ0aWVzKTsNCj4gZGlmZiAt
LWdpdCBhL2h3L2kzODYvaW50ZWxfaW9tbXUuYyBiL2h3L2kzODYvaW50ZWxfaW9tbXUuYw0KPiBp
bmRleCBmMzY2YzIyM2QwZS4uN2ZkZTA2MDNiZmUgMTAwNjQ0DQo+IC0tLSBhL2h3L2kzODYvaW50
ZWxfaW9tbXUuYw0KPiArKysgYi9ody9pMzg2L2ludGVsX2lvbW11LmMNCj4gQEAgLTQ4NzEsOCAr
NDg3MSw2IEBAIHN0YXRpYyB2b2lkIHZ0ZF9jbGFzc19pbml0KE9iamVjdENsYXNzICprbGFzcywg
dm9pZCAqZGF0YSkNCj4gICAgICAgZGMtPmhvdHBsdWdnYWJsZSA9IGZhbHNlOw0KPiAgICAgICB4
ODZfY2xhc3MtPnJlYWxpemUgPSB2dGRfcmVhbGl6ZTsNCj4gICAgICAgeDg2X2NsYXNzLT5pbnRf
cmVtYXAgPSB2dGRfaW50X3JlbWFwOw0KPiAtICAgIC8qIFN1cHBvcnRlZCBieSB0aGUgcGMtcTM1
LSogbWFjaGluZSB0eXBlcyAqLw0KPiAtICAgIGRjLT51c2VyX2NyZWF0YWJsZSA9IHRydWU7DQo+
ICAgICAgIHNldF9iaXQoREVWSUNFX0NBVEVHT1JZX01JU0MsIGRjLT5jYXRlZ29yaWVzKTsNCj4g
ICAgICAgZGMtPmRlc2MgPSAiSW50ZWwgSU9NTVUgKFZULWQpIERNQSBSZW1hcHBpbmcgZGV2aWNl
IjsNCj4gICB9DQo+IGRpZmYgLS1naXQgYS9ody9pMzg2L3g4Ni1pb21tdS5jIGIvaHcvaTM4Ni94
ODYtaW9tbXUuYw0KPiBpbmRleCBmZWQzNGIyZmNmYS4uNWNkZDE2NWFmMGQgMTAwNjQ0DQo+IC0t
LSBhL2h3L2kzODYveDg2LWlvbW11LmMNCj4gKysrIGIvaHcvaTM4Ni94ODYtaW9tbXUuYw0KPiBA
QCAtMTQ2LDcgKzE0Niw3IEBAIGJvb2wgeDg2X2lvbW11X2lyX3N1cHBvcnRlZChYODZJT01NVVN0
YXRlICpzKQ0KPiANCj4gICBzdGF0aWMgY29uc3QgVHlwZUluZm8geDg2X2lvbW11X2luZm8gPSB7
DQo+ICAgICAgIC5uYW1lICAgICAgICAgID0gVFlQRV9YODZfSU9NTVVfREVWSUNFLA0KPiAtICAg
IC5wYXJlbnQgICAgICAgID0gVFlQRV9TWVNfQlVTX0RFVklDRSwNCj4gKyAgICAucGFyZW50ICAg
ICAgICA9IFRZUEVfRFlOQU1JQ19TWVNfQlVTX0RFVklDRSwNCj4gICAgICAgLmluc3RhbmNlX3Np
emUgPSBzaXplb2YoWDg2SU9NTVVTdGF0ZSksDQo+ICAgICAgIC5jbGFzc19pbml0ICAgID0geDg2
X2lvbW11X2NsYXNzX2luaXQsDQo+ICAgICAgIC5jbGFzc19zaXplICAgID0gc2l6ZW9mKFg4NklP
TU1VQ2xhc3MpLA0KPiAtLQ0KPiAyLjQ3LjENCj4gDQo=


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 06:16:42 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 06:16:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877414.1287550 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcIQL-0000Hh-3V; Mon, 27 Jan 2025 06:16:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877414.1287550; Mon, 27 Jan 2025 06:16:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcIQL-0000Ha-0O; Mon, 27 Jan 2025 06:16:41 +0000
Received: by outflank-mailman (input) for mailman id 877414;
 Mon, 27 Jan 2025 06:16:40 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=50Ot=UT=eviden.com=clement.mathieu--drif@srs-se1.protection.inumbo.net>)
 id 1tcIQK-0000Fc-8G
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 06:16:40 +0000
Received: from smarthost2.eviden.com (smarthost2.eviden.com [80.78.11.83])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 44e027c7-dc76-11ef-a0e6-8be0dac302b0;
 Mon, 27 Jan 2025 07:16:39 +0100 (CET)
Received: from mail-norwayeastazlp17013076.outbound.protection.outlook.com
 (HELO OSPPR02CU001.outbound.protection.outlook.com) ([40.93.81.76])
 by smarthost2.eviden.com with ESMTP/TLS/TLS_AES_256_GCM_SHA384;
 27 Jan 2025 07:16:36 +0100
Received: from AM8PR07MB7602.eurprd07.prod.outlook.com (2603:10a6:20b:24b::7)
 by PA4PR07MB8792.eurprd07.prod.outlook.com (2603:10a6:102:266::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.22; Mon, 27 Jan
 2025 06:16:34 +0000
Received: from AM8PR07MB7602.eurprd07.prod.outlook.com
 ([fe80::fbd7:ca71:b636:6f9d]) by AM8PR07MB7602.eurprd07.prod.outlook.com
 ([fe80::fbd7:ca71:b636:6f9d%7]) with mapi id 15.20.8377.021; Mon, 27 Jan 2025
 06:16:34 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 44e027c7-dc76-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=eviden.com; i=@eviden.com; q=dns/txt; s=mail;
  t=1737958599; x=1769494599;
  h=from:to:cc:subject:date:message-id:references:
   in-reply-to:content-id:content-transfer-encoding:
   mime-version;
  bh=ZuB3GVDozJSI7pCxie25kgndB6UvnNq4/Dn3MVNxXx4=;
  b=TzeNtGhNYqTzrVAuo0R55HiVXR/SD9kXlnssGsaivXXZEYZpvJybpmqp
   RDI6NGj/NpBbcpvRb6jwaF61QtMPxzlDkcwj41QOyEKxCLSIiQXT8yPcG
   9yIYXwht34znyCNeGCo5l8NkuLeDUFAreq2/fCmVkrFztdSjwC1ea9+X/
   772E3amKItE1P58Yt1ok4tXQ7rIvlhMsp1WYfEo7TEuR5UDZx4ivx8ZWF
   cLKnqq1e0evSKSwcRCWCgKKpxKR4ImEq716eHQJ5hNSC/xMCILFqotkWI
   hsIBdwxu8aFA01OjEJ9IgawE8bznKhQRBZrGlyp1nozLF9wmrh2zQwPTK
   Q==;
X-CSE-ConnectionGUID: qlCZPluoSIOh56DW9vb5wA==
X-CSE-MsgGUID: xtk2aNF7SDq2L/2PKSDNHA==
X-IronPort-AV: E=Sophos;i="6.13,237,1732575600"; 
   d="scan'208";a="29554823"
X-MGA-submission: =?us-ascii?q?MDFVhE38eoN/gmxjnVP+BLfT6QARUTGmirq1dx?=
 =?us-ascii?q?E7Oh3L5am7ic9U53z1Xw/XmMFZTVfyv5AQYFq4BuU2ja0G6IJZ6FnM9k?=
 =?us-ascii?q?gODZxNm3NRNY/KuWLPDdPsaRGBOromQ+74hQHPOGN5J4kHU7fPJmwaMb?=
 =?us-ascii?q?GATONuA7+U9whRQkkiRV0Ezg=3D=3D?=
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=MW8CTeX9Vx2l1h1iXak8XxnmrfjXhOj1p2mrSLGWHNpZqMSAKjR/OmPuoAiCDhqOwB2nXbdQ8GCvzwrD6KHvPYdRtCQ+JvTVqV7q1xrWtj0qIpyolvA+EnZwnieAzfWlq0YBXYSTjwFESiyKiZl3loghoVTJsmiMer6KnL4AUEM0gAQG7bxObVEH2m7H6fUExfwXr7eO9i/riRgIuUBouUjtxn7PlqWBgAv++uhGzLulvLVdqVBAoLyh19kFdBR7AUMljlnPecdKkrtDD/dFiZje93g81RszS86e3gjNY9qbzPuiBMu0xL+wa/JnP3gok/OJWYDhgdnxaVWHUmBhFg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=ZuB3GVDozJSI7pCxie25kgndB6UvnNq4/Dn3MVNxXx4=;
 b=pZ515OYmfBOFF4KaS+CDv78qS0hBz8etVwK/6ppAfHhAYBqW4ru4t16zpoRIDtHbo55AExm3BPzKaCY6xSdpxhCT/4s764nF54UzpbnxLjwyzJlyczSyq/24WA+hQhCiXYmoyYgd0Ys5Fdd+tzGMmLZh6Q7k+cAFIrupNdoC1G09OgafsbSWYuDp0mkM3wzBaTB8el+jtxdikw8b4Q8SepNayqR50THFzE1CtmvsAX2YFzX9ATapMVJKxuyn73tv3aXl57OtjQvYZql1HDNMoebUB6fq8nzv8LAv48UtCTpVF0PYLTSAI40rxRAo0TCXK1hRdzKtkAkjlXMHGs5LzQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=eviden.com; dmarc=pass action=none header.from=eviden.com;
 dkim=pass header.d=eviden.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Eviden.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=ZuB3GVDozJSI7pCxie25kgndB6UvnNq4/Dn3MVNxXx4=;
 b=gc2bsSe+8K0O/JUFDnJjVpuxCWmlf+AeCApVhRSIZh4SHzraJECQxUMyEedhjvxArEAKplqYjojmyfsIRTJl2nf09z6ks9NQvyX7i/1kmZfAP5NhroUm7eyx+1+TKqhgr+qjYuehtmTuQhQLTON1CwD1MiWhqSpZQvO3Y33mCHyPs/DRdd9ugWtzJreGLPqssRnP3VVUQN9fsIdl7YQfiBibx1S2NdQoP22FnFrkrTxioWu1A/NFPsCfvln3dU6MEN38i+lLA2uqfY4PWMdMBZn4+biv9ad4RL8G74YFy7FMhvL/lpghzoZcXsLkKlUiuoytXtvUgcmgZBVutmcKjw==
From: CLEMENT MATHIEU--DRIF <clement.mathieu--drif@eviden.com>
To: =?utf-8?B?UGhpbGlwcGUgTWF0aGlldS1EYXVkw6k=?= <philmd@linaro.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
CC: Yi Liu <yi.l.liu@intel.com>, Markus Armbruster <armbru@redhat.com>,
	Eduardo Habkost <eduardo@habkost.net>, Anthony PERARD
	<anthony@xenproject.org>, Gustavo Romero <gustavo.romero@linaro.org>, Jason
 Wang <jasowang@redhat.com>, "qemu-ppc@nongnu.org" <qemu-ppc@nongnu.org>,
	"Michael S. Tsirkin" <mst@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>,
	Alexander Graf <graf@amazon.com>, Richard Henderson
	<richard.henderson@linaro.org>, Stefan Berger <stefanb@linux.vnet.ibm.com>,
	Bernhard Beschow <shentey@gmail.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Gerd Hoffmann <kraxel@redhat.com>,
	=?utf-8?B?RGFuaWVsIFAuIEJlcnJhbmfDqQ==?= <berrange@redhat.com>, "Edgar E.
 Iglesias" <edgar.iglesias@gmail.com>, "xen-devel@lists.xenproject.org"
	<xen-devel@lists.xenproject.org>, Marcel Apfelbaum
	<marcel.apfelbaum@gmail.com>, Alex Williamson <alex.williamson@redhat.com>,
	Paul Durrant <paul@xen.org>, =?utf-8?B?Q8OpZHJpYyBMZSBHb2F0ZXI=?=
	<clg@redhat.com>
Subject: Re: [PATCH 8/9] hw/tpm: Have TPM TIS sysbus device inherit from
 DYNAMIC_SYS_BUS_DEVICE
Thread-Topic: [PATCH 8/9] hw/tpm: Have TPM TIS sysbus device inherit from
 DYNAMIC_SYS_BUS_DEVICE
Thread-Index: AQHbb1T72ko97KtHNUmqqgt4c41qN7MqJ0iA
Date: Mon, 27 Jan 2025 06:16:34 +0000
Message-ID: <993fb62e-c6c6-4137-83fb-bd2a8bc4b992@eviden.com>
References: <20250125181343.59151-1-philmd@linaro.org>
 <20250125181343.59151-9-philmd@linaro.org>
In-Reply-To: <20250125181343.59151-9-philmd@linaro.org>
Accept-Language: en-GB, fr-FR, 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=eviden.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: AM8PR07MB7602:EE_|PA4PR07MB8792:EE_
x-ms-office365-filtering-correlation-id: 37f873cf-4453-408d-b4ed-08dd3e9a2686
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|366016|7416014|376014|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?UlNnOEpxS0dqQ1pjV3ZYTnROcmxPOTVnK25wM3ZCSVdxNUZWTkpHcW03Q1p5?=
 =?utf-8?B?Yk1DOTEvV0xNYjMwZDNFMnJmdUM2TVNNQk12UTVxWmxTcDZOcXZ0WjVYVVZo?=
 =?utf-8?B?dGtYUDVKOUx1ZXZCa1diTzcwcW1vQ3FrL2Rlbm53U3E1eEgzQmdOMitVcVJE?=
 =?utf-8?B?L1ZBdUNhODRza1Q4NlJ3eEFYZkJXZkZBZ1lJNGxCNzNnK3BwbTFYcXdsNlEy?=
 =?utf-8?B?bjRpTEFZR0lqblBsdzhGMmVLN0xmZ2Q3QkxPRTlienFkYmEvQkNkalJ5enB0?=
 =?utf-8?B?L2NGb1dMK2hvOVc4c293MllYTURiNWlHUmd2aU9nY2lOVUFndy9UUUV0V0lu?=
 =?utf-8?B?RDB1WGllOHlUMkhJUzdPRVZjU3dDWjlpOWl2a1ZRaEw1VTRjV1JSaDRwSGU5?=
 =?utf-8?B?Y3dUVElSZVA1QU52VmRNVThXRTRld29NV0o0NnFWR2FjS2lMWHVtdkt4NllD?=
 =?utf-8?B?Y1Q5aTJCR1RxdTd5Y0xNaTk0R0w2RjU1TFB5US9nQmFoYTRrc05kditSb1Y3?=
 =?utf-8?B?b2t2UEJIdUtKUDN5UkJkeVdFQkJMejhUK04wVGhKUXR2RW9Uek1Pd1VJSUR5?=
 =?utf-8?B?VGQ2b0haUmlEMXV5b2c1ZVJLaG5WRmU1YnlZcGhlaTBBeThXdFQ0S2ZSd2U5?=
 =?utf-8?B?eUhNRjMxWkw0ZTNYam5nM1BtSVo1WmVGR09YTUFud2R0RnA0eVprT0Z1eUhQ?=
 =?utf-8?B?L0J3dEFxejVONVB1L2UwVElvUWIrVU96dDVnY1hwTHNmWWZZdDY0Wm9aS0F1?=
 =?utf-8?B?QithcFVTa0dGTnBjK1F6RUwwZ1dsWUs4MHcxV0h6L2JHcEJtT1U2SlU1YkFi?=
 =?utf-8?B?Nk1QSGowem1YUjdnS04yWlJmOVJkaER2NFF0REpOT1dBbnVFam5WZlFBR3lT?=
 =?utf-8?B?WG5EbUNTK3F1TmVvUFRXS25MQVNodlQyTHpoejhyd0s2ZkZ3N0g1NldhU243?=
 =?utf-8?B?YkRnUGs4bjkyMVVMMjBreGQ2S29ubDJqNTkyZUx6Y0N2MWNHellMeUJ1NG9S?=
 =?utf-8?B?Z0J2aWlwcnIxaUtRZ2pYYklJNEtUUWk5KzJIM1FRcnBTQnpSeThEQlN6N1RZ?=
 =?utf-8?B?SFVrL3NGRVBZb2Z0eWlXNHVZVzkyRkJJYy90TDZQSS8weDVLcGorL2lUVTZK?=
 =?utf-8?B?TEszbUlpMTl5VEdIM3hHMk43djIyM3hIcHgyQVhRb085UkNwd3g4RnBBRFU3?=
 =?utf-8?B?cUVhMVlicWY2eDdLMTl4cGtBS1BRV2hQMGY1aG5ZYjZWbmx5QUpCSlpoMDdz?=
 =?utf-8?B?S1dzMUVNUExjK1pvOTl5Z05HZDNXWWlYMmwrYnltU0RibU5NQW9uYlBWWTRt?=
 =?utf-8?B?SW1rOXljaVQzR05BM0E4Vmcva3NLVWVQZ3BJVEpOL0NkeWVWenFpWlVxVmZ1?=
 =?utf-8?B?ZEVzeGQrU0JVUHBRb0NTVkt1VXoxSTdwK0dmMHl3bTR5VG92MDd5WW8yZkFu?=
 =?utf-8?B?SUJoKzFmb0xqZ3FLcForU0RheVUwUWdxWlpMeXEvQW0xQjdWbWNacTcxMCtL?=
 =?utf-8?B?NGwvN0dlYjJYMVFVWis5ODQ2RWlqZVQvaFhnUXpwSFVHZG1BWktOTWFHc3RN?=
 =?utf-8?B?RW1kckNyV09QRWRNcHV6Z1NGZU1qYkNXY1Y1OUliZFNxNGM3M2JWQlp0amRs?=
 =?utf-8?B?ZEtEbU9GdmVpNFFub2x3bktrR2t5MEpoWk1sNkQwWFR2RmdYZnBoaC93VDJQ?=
 =?utf-8?B?bEsrZllENk1LN2s4VFNMMFplUmpiSHF6M2U3WXk1bkRjejMvTGVJamtyZmRP?=
 =?utf-8?B?REZtQW5DNkdoMFdYZ1lXd2wxY1U3MHhSVFVURFR3T1VrZE5BTUNyOXVvemQx?=
 =?utf-8?B?VUQ0eWZyYUZlRHVRWVZPUUQrMmV4cEpWMWU0RUtTNTEyK3I5Zml2UnQzam4w?=
 =?utf-8?B?L3ZGdE1ZL0JHWVZlQTBlY3BHSGxQZnowM0d5ZEgwd0NBNnRla2dWVm50MGtm?=
 =?utf-8?Q?hArTRr1WoS0ZyT80E2aioHrFupePz3Lz?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM8PR07MB7602.eurprd07.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(7416014)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?eVY4MlNneUFTbTkxUDNrYnNWZy93UjR5Yk81ZTNhOGVCTjZFWG5LOTZlMDla?=
 =?utf-8?B?NlJWSDRaTXp3UGRGa3h3WFkrbGlYbHFmcDAwc0xSRDFLSVZvWkprZXRWVEtV?=
 =?utf-8?B?dy81ZVpBaDRtUFQ2eVIvbXZENmRWeUdvcmtlQitmN3YyVG5WTWdNVEJDeHlt?=
 =?utf-8?B?c2VBdGo2SjVGUFVuTHVndGNod0NXYjVDcytxdjVTOUx5SWQrYnlkMTUrc1By?=
 =?utf-8?B?TmdkZE9Kckg2U0JnR0h3aVJoS3BMbWpVZHhNQjNBWlVJYy9VVkgyVXd4S1FD?=
 =?utf-8?B?bDBSM1NaMkNkUHdnTEFsOU1sM3ZVd1dWckt5ZVRPdkpZR25kenZPMW4rOE5q?=
 =?utf-8?B?ZGN3RXZ6ekQ5RFZhUVdXclN6b1haNmVITWdtNkd5OVdDejJMUjFBOTBwb3ls?=
 =?utf-8?B?UjZqeDg0U1Vlc1ZkTXd6aENkckwyOG1Xd0YwemJ0Sjk4MDdZb2pxSkJFVXdB?=
 =?utf-8?B?Z05hTEF6R0lBQWdCWUJ5eTBnMUwzSkdxK2xCYXJiaGI1bFN5VkNNWHRlS3BC?=
 =?utf-8?B?L2Z4SHQ3NHQvamRtcjVTbm01dGpKYm1INytseVEvSGN1MnNEdm5PWEpqV3ZQ?=
 =?utf-8?B?U09nanhTQ3lXeVRBc0VqUDZxZ1Z3NG9Ucmp5QmR0WHVrNU4rR1QwU1BYNTF2?=
 =?utf-8?B?Sms4WXRHNyttRFFqVEdTbnRGQS9QMUZWNWtzNnA0WFZqOS9zclNlUlUveGRO?=
 =?utf-8?B?TDlhY0tXdUQ0anlYaTdsMW5OczV4bDVodis5ZkFzUXliNFJyYlNFeGo4Q01o?=
 =?utf-8?B?VzMxV3Jjc205dzBoODRNU2xMYWVGdy9qVm1DY1M2Ry84dmgwR1dZSk1rNGt4?=
 =?utf-8?B?TVdLbDBQU3lTNTNhUk5uM3BqaWF2eE9uNFRKNG1lY0ZBNUZRSXQ3R3haeUZ1?=
 =?utf-8?B?UVROUERjRVgxRnJTcHBRczFESlBZY1MrS1lvOXBqYTZIWHd3U1NmQXJNMjQ3?=
 =?utf-8?B?ZkgwNzBNTkxzZ1ZMTjZCeERsdWp3UE5UTjI5SkhRc0xpU3k2QVM3eGRFYU9j?=
 =?utf-8?B?bjRrTWhReWlKWFRhNDVRMVNiR3VlMEhGNHpRdDFrcnhmZHFTdFZmNUJpZ0Zv?=
 =?utf-8?B?angxZWtmWmFiMzRXRVM5WWR3anl5N2xrZFl3WktZaWo4V3JxeklLNEdGS2pK?=
 =?utf-8?B?S0laNWh5cG9xTkswSnZxQkFxYWJJc0syczFzMEtieWZpL25GSndtcXhzN0h1?=
 =?utf-8?B?VkgvM1FMRTk0K3hJR3lIazhPRytUVXEwZzdYbWhwR1dsUHJiTm5SK3Bqa0Vi?=
 =?utf-8?B?QzFwY2Z6QzZodGJkQUw3WGZnYWw3YzNuLzBEOGtjcDB1MG15K3lqS0E3V1Jx?=
 =?utf-8?B?T0tQbU1PTE9ZUnR3WVZxMks1VXdZa2Qxc0xRMDBFRkJ2Rk1kdzRvUDZ5MzlL?=
 =?utf-8?B?aU1LVnoyVmdZOFAvcU42N0gzOHRPTEFod1dtOElXS281QUVkMWhzbkxKYm1i?=
 =?utf-8?B?YnZDS21OTUkzOS9JbXdXa2tuaWxqaU01L3hCQjZPeFA3dG1NbDJKVzFQNDNo?=
 =?utf-8?B?MW5TbDlPTVBoYzNUR3lFeU9XUEdueWZIOUpQamJNZWwydXFPQUJ3M3ZXWFg3?=
 =?utf-8?B?Q3pwb0huVlQ5UjRQRDRCNmJoNzRBZytvZm90U295aEE4MFRSaVJpZ2ZtSE5X?=
 =?utf-8?B?Q2hhbWM1amg3bUhSay84RzZheG12b0VOYmRMb1lrVVVpYkgvbEU0UytXaGZ4?=
 =?utf-8?B?NEVIMFNuVlBxM1ZBNVlyT2l3WGVUcXl2VnRQVkZOVytzUlJVT2R5RklUVW1p?=
 =?utf-8?B?RUtIL2l5dndXVHNWd3NjQkdBUFpLaDZnb2NCbmw2K2RnbDFJSEdjZW9uZnlV?=
 =?utf-8?B?bGhaUGpUdjU1VUlkZzRkaG1meDVNRThrb1E1RzQ4N1d0MkFCM29TblVMR2VH?=
 =?utf-8?B?U1NrbTJEYkJzcGRHWTNTZFh5R3Q0dXkxNUY0TTBHT001UVZuUndhclp6S0Fq?=
 =?utf-8?B?NFArcDE5ZCtjVXZLTEhOY2h4bmxQY09VZEpuMDJXWXM4aHdaTVVHRmhFbU9O?=
 =?utf-8?B?RU5mNTF4ZDI4aHRqcnJiMFZhekJ0ZVAwUHVkcThKeHVJMkt4TWNnbGlpWWJG?=
 =?utf-8?B?YjBEbHVoUzNhMjJXMVNETTZjMUFVdlNhOVhMNU50TmY0OVdxRUhOUEhmTVAr?=
 =?utf-8?B?V2dxUXYvQUNLK2xGbk1xcWFjd0VHbXF6cVc0QkczVEdTaXNTdTFZbFJxVGlv?=
 =?utf-8?Q?I/spPN/roPFOvQUuqQpQcYc=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <F5B7B009C5FA044CBEFB94E3C3BFEED5@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: eviden.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM8PR07MB7602.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 37f873cf-4453-408d-b4ed-08dd3e9a2686
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2025 06:16:34.8220
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 7d1c7785-2d8a-437d-b842-1ed5d8fbe00a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: WedVj/OdeCFjBb9wP2R7xFmtnwfo80qp2S7jsUcYo5YPJZc2IiJWZ0dpf3KojXcB+VqjU7otoEgnvEtw3hwOg1WEEAPJ4hdlg6kO9fooBNPFwDYQkfaNY/sXFWsY3VpD
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR07MB8792

UmV2aWV3ZWQtYnk6IENsw6ltZW50IE1hdGhpZXUtLURyaWY8Y2xlbWVudC5tYXRoaWV1LS1kcmlm
QGV2aWRlbi5jb20+DQoNCg0KDQpPbiAyNS8wMS8yMDI1IDE5OjEzLCBQaGlsaXBwZSBNYXRoaWV1
LURhdWTDqSB3cm90ZToNCj4gQ2F1dGlvbjogRXh0ZXJuYWwgZW1haWwuIERvIG5vdCBvcGVuIGF0
dGFjaG1lbnRzIG9yIGNsaWNrIGxpbmtzLCB1bmxlc3MgdGhpcyBlbWFpbCBjb21lcyBmcm9tIGEg
a25vd24gc2VuZGVyIGFuZCB5b3Uga25vdyB0aGUgY29udGVudCBpcyBzYWZlLg0KPg0KPg0KPiBC
ZWNhdXNlIHRoZSBUUE0gVElTIHN5c2J1cyBkZXZpY2UgY2FuIGJlIG9wdGlvbmFsbHkgcGx1Z2dl
ZCBvbiB0aGUNCj4gVFlQRV9QTEFURk9STV9CVVNfREVWSUNFLCBoYXZlIGl0IGluaGVyaXQgVFlQ
RV9EWU5BTUlDX1NZU19CVVNfREVWSUNFLg0KPg0KPiBTaWduZWQtb2ZmLWJ5OiBQaGlsaXBwZSBN
YXRoaWV1LURhdWTDqSA8cGhpbG1kQGxpbmFyby5vcmc+DQo+IC0tLQ0KPiAgIGh3L3RwbS90cG1f
dGlzX3N5c2J1cy5jIHwgMyArLS0NCj4gICAxIGZpbGUgY2hhbmdlZCwgMSBpbnNlcnRpb24oKyks
IDIgZGVsZXRpb25zKC0pDQo+DQo+IGRpZmYgLS1naXQgYS9ody90cG0vdHBtX3Rpc19zeXNidXMu
YyBiL2h3L3RwbS90cG1fdGlzX3N5c2J1cy5jDQo+IGluZGV4IGVlMGJmZTk1MzhlLi40ZjE4NzY5
MGEyOCAxMDA2NDQNCj4gLS0tIGEvaHcvdHBtL3RwbV90aXNfc3lzYnVzLmMNCj4gKysrIGIvaHcv
dHBtL3RwbV90aXNfc3lzYnVzLmMNCj4gQEAgLTEzMyw3ICsxMzMsNiBAQCBzdGF0aWMgdm9pZCB0
cG1fdGlzX3N5c2J1c19jbGFzc19pbml0KE9iamVjdENsYXNzICprbGFzcywgdm9pZCAqZGF0YSkN
Cj4gICAgICAgZGMtPnZtc2QgID0gJnZtc3RhdGVfdHBtX3Rpc19zeXNidXM7DQo+ICAgICAgIHRj
LT5tb2RlbCA9IFRQTV9NT0RFTF9UUE1fVElTOw0KPiAgICAgICBkYy0+cmVhbGl6ZSA9IHRwbV90
aXNfc3lzYnVzX3JlYWxpemVmbjsNCj4gLSAgICBkYy0+dXNlcl9jcmVhdGFibGUgPSB0cnVlOw0K
PiAgICAgICBkZXZpY2VfY2xhc3Nfc2V0X2xlZ2FjeV9yZXNldChkYywgdHBtX3Rpc19zeXNidXNf
cmVzZXQpOw0KPiAgICAgICB0Yy0+cmVxdWVzdF9jb21wbGV0ZWQgPSB0cG1fdGlzX3N5c2J1c19y
ZXF1ZXN0X2NvbXBsZXRlZDsNCj4gICAgICAgdGMtPmdldF92ZXJzaW9uID0gdHBtX3Rpc19zeXNi
dXNfZ2V0X3RwbV92ZXJzaW9uOw0KPiBAQCAtMTQyLDcgKzE0MSw3IEBAIHN0YXRpYyB2b2lkIHRw
bV90aXNfc3lzYnVzX2NsYXNzX2luaXQoT2JqZWN0Q2xhc3MgKmtsYXNzLCB2b2lkICpkYXRhKQ0K
Pg0KPiAgIHN0YXRpYyBjb25zdCBUeXBlSW5mbyB0cG1fdGlzX3N5c2J1c19pbmZvID0gew0KPiAg
ICAgICAubmFtZSA9IFRZUEVfVFBNX1RJU19TWVNCVVMsDQo+IC0gICAgLnBhcmVudCA9IFRZUEVf
U1lTX0JVU19ERVZJQ0UsDQo+ICsgICAgLnBhcmVudCA9IFRZUEVfRFlOQU1JQ19TWVNfQlVTX0RF
VklDRSwNCj4gICAgICAgLmluc3RhbmNlX3NpemUgPSBzaXplb2YoVFBNU3RhdGVTeXNCdXMpLA0K
PiAgICAgICAuaW5zdGFuY2VfaW5pdCA9IHRwbV90aXNfc3lzYnVzX2luaXRmbiwNCj4gICAgICAg
LmNsYXNzX2luaXQgID0gdHBtX3Rpc19zeXNidXNfY2xhc3NfaW5pdCwNCj4gLS0NCj4gMi40Ny4x
DQo+DQo=


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 06:18:02 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 06:18:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877421.1287560 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcIRd-0000os-DM; Mon, 27 Jan 2025 06:18:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877421.1287560; Mon, 27 Jan 2025 06:18:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcIRd-0000ol-9n; Mon, 27 Jan 2025 06:18:01 +0000
Received: by outflank-mailman (input) for mailman id 877421;
 Mon, 27 Jan 2025 06:18:00 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=50Ot=UT=eviden.com=clement.mathieu--drif@srs-se1.protection.inumbo.net>)
 id 1tcIRc-0000ob-L1
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 06:18:00 +0000
Received: from smarthost3.eviden.com (smarthost3.eviden.com [80.78.11.84])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7416fb16-dc76-11ef-99a4-01e77a169b0f;
 Mon, 27 Jan 2025 07:17:58 +0100 (CET)
Received: from mail-northeuropeazlp17012024.outbound.protection.outlook.com
 (HELO DU2PR03CU002.outbound.protection.outlook.com) ([40.93.64.24])
 by smarthost3.eviden.com with ESMTP/TLS/TLS_AES_256_GCM_SHA384;
 27 Jan 2025 07:17:56 +0100
Received: from AM8PR07MB7602.eurprd07.prod.outlook.com (2603:10a6:20b:24b::7)
 by PA4PR07MB8792.eurprd07.prod.outlook.com (2603:10a6:102:266::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.22; Mon, 27 Jan
 2025 06:17:55 +0000
Received: from AM8PR07MB7602.eurprd07.prod.outlook.com
 ([fe80::fbd7:ca71:b636:6f9d]) by AM8PR07MB7602.eurprd07.prod.outlook.com
 ([fe80::fbd7:ca71:b636:6f9d%7]) with mapi id 15.20.8377.021; Mon, 27 Jan 2025
 06:17:55 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 7416fb16-dc76-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=eviden.com; i=@eviden.com; q=dns/txt; s=mail;
  t=1737958679; x=1769494679;
  h=from:to:cc:subject:date:message-id:references:
   in-reply-to:content-id:content-transfer-encoding:
   mime-version;
  bh=ZaqRxevQJn6kjwHXQU8NJ2avfOfbYzKHDBFBtpKsA4M=;
  b=JPHmYJEFRU5z+9ULSol8HmgWAfkScZ3pS8s+ZxgK8K4yo+Vq9tKv9/lS
   5Xl3FfChiUZ7GKhCWGtuqNhOx37uhe5PGBvdcJYq4s+695W3vLOm3mtEt
   7Jbb4mADtRYOuhncdcndafbBegLVowSNa/GLcICHfSqyggTF8LuzX/HoW
   V3iCTt42BlBRz5v27K6Y/Q0NJc79i7QKTTAfxM7WoHm60hGwtxE+r1uN3
   EMpUic25hCJI0NilhmwX+ZaDNn/KS7MwfjGSxZRfB83Qv6RsfbBPeW95u
   ouNHIPYnMVTv8FFosW+pJfxKLd9GhyqbcXxTBeTbD7jxaR4wfjw7qftz+
   A==;
X-CSE-ConnectionGUID: aRcu72d3QMC5kwcFpZWyvQ==
X-CSE-MsgGUID: xravemF/R8maJeZB3sAdHQ==
X-IronPort-AV: E=Sophos;i="6.13,237,1732575600"; 
   d="scan'208";a="29554417"
X-MGA-submission: =?us-ascii?q?MDGVbc5IGL8kXlSmMjHF56OdhIAHaoQuM2Rnoe?=
 =?us-ascii?q?nWySzj3zH8xWb3z4acH2lNOBmlGCWrPzge+6SKYfkDgeJqeamHDZlGCc?=
 =?us-ascii?q?3yppnJajj07pboFX2wHN0UOx7xrrj+C6/XxS1QJJkbMd2PsSUoyLCLYm?=
 =?us-ascii?q?1nK6VgX/NEefgBq5YVDlOA2Q=3D=3D?=
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=G2sXv4FS62U6p6QLfZRvzEL5nBksSjkzqvgTol2S2mi0HluIzVIPi8+ZWowuziJN+Ut3CVboxAytBh18kat2lG8hDOI2dqxy30RacrIy9oLdxq+eRl5afrUY/cI6+NdOPS2B/QjOgKmgkrzdQ7tWMK7YfJpxGh/qMgeq+6daEXT3xM/6PL1JFsE1+JvjHc7RZjhPQisAHp87G5vjG4PSuhxP3LaH91W3r+cq7C6mqvB9gYIzxorUOIrwvXL4xpajfsQ8GdkMOhEsX6xBXH7jcWessqi/9YdOn3rzIvLywIGzOIjTliVnqpDehTBTX7qm0TPTmX4BQkgdQQOhygl/Hw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=ZaqRxevQJn6kjwHXQU8NJ2avfOfbYzKHDBFBtpKsA4M=;
 b=vyDd0eoLB5X2TIdYX3v7T/UfxJZZ7j8x3OUw1VVENNPLkRhp+DZHZHQTxT/LCcTUrYPq1G76oku3c9XmTmJzf5lzOJueT/dC3z0J9gn+C512pf8P9C61amz24SGTgrXQt9z7k3FPNc2I7WwEHKWrNxY5EgSABRQjnz1y4WD7ybB2kviFREQiWEfiyrv3Rb0tCEYBWDXo/CX0KFZibaPKdjEGB9kH94t4Gka+Sp3eoMaDCFQrPOy4YN+fBUBpeGw9/e0AwoOtcapU4eC1sxH5G+NWexaJVy3A1JD4WocnyFKVIq2k0KrsIGZx5FBX08SwZsFCDQzqZJxJ1LTgr293zQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=eviden.com; dmarc=pass action=none header.from=eviden.com;
 dkim=pass header.d=eviden.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Eviden.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=ZaqRxevQJn6kjwHXQU8NJ2avfOfbYzKHDBFBtpKsA4M=;
 b=ceXm8TrrjLh6DzOy3Spw8/dlpdrtGOnUlHnJKbpMYox7E49zmIiGkONuVlU0SvP0/atQICrx+u3v5+kYKvCkGImoViXWyjbub6X/byltD2ziFwgeSGRUT7vgxxmyv4FZ9MLE3KBL9N1x1QTWa5/Ysil7s5UQGTm6J/dijetVzaHG7/LeJSe8rD7mhAy5BhNchr+xYUl203DOx5rnHBaanAUtJU2FWKyfmtEuSIx0YoQOAsRvbqV5b0BSAZ83zckJh49E0Tq5I42V8CxxsZEzDPFfrtevwyx7s4hJ1w9VhsCFr5wi+xJDg5plBKyu9SA0nXzrX7CpRliZqPxz0nzNUg==
From: CLEMENT MATHIEU--DRIF <clement.mathieu--drif@eviden.com>
To: =?utf-8?B?UGhpbGlwcGUgTWF0aGlldS1EYXVkw6k=?= <philmd@linaro.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
CC: Yi Liu <yi.l.liu@intel.com>, Markus Armbruster <armbru@redhat.com>,
	Eduardo Habkost <eduardo@habkost.net>, Anthony PERARD
	<anthony@xenproject.org>, Gustavo Romero <gustavo.romero@linaro.org>, Jason
 Wang <jasowang@redhat.com>, "qemu-ppc@nongnu.org" <qemu-ppc@nongnu.org>,
	"Michael S. Tsirkin" <mst@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>,
	Alexander Graf <graf@amazon.com>, Richard Henderson
	<richard.henderson@linaro.org>, Stefan Berger <stefanb@linux.vnet.ibm.com>,
	Bernhard Beschow <shentey@gmail.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Gerd Hoffmann <kraxel@redhat.com>,
	=?utf-8?B?RGFuaWVsIFAuIEJlcnJhbmfDqQ==?= <berrange@redhat.com>, "Edgar E.
 Iglesias" <edgar.iglesias@gmail.com>, "xen-devel@lists.xenproject.org"
	<xen-devel@lists.xenproject.org>, Marcel Apfelbaum
	<marcel.apfelbaum@gmail.com>, Alex Williamson <alex.williamson@redhat.com>,
	Paul Durrant <paul@xen.org>, =?utf-8?B?Q8OpZHJpYyBMZSBHb2F0ZXI=?=
	<clg@redhat.com>
Subject: Re: [PATCH 5/9] hw/display: Have RAMFB device inherit from
 DYNAMIC_SYS_BUS_DEVICE
Thread-Topic: [PATCH 5/9] hw/display: Have RAMFB device inherit from
 DYNAMIC_SYS_BUS_DEVICE
Thread-Index: AQHbb1TxLwglWhJ1hUajUJgEguIvWLMqJ6iA
Date: Mon, 27 Jan 2025 06:17:55 +0000
Message-ID: <69adade0-1f55-4d20-b3e0-ee1647f7d513@eviden.com>
References: <20250125181343.59151-1-philmd@linaro.org>
 <20250125181343.59151-6-philmd@linaro.org>
In-Reply-To: <20250125181343.59151-6-philmd@linaro.org>
Accept-Language: en-GB, fr-FR, 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=eviden.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: AM8PR07MB7602:EE_|PA4PR07MB8792:EE_
x-ms-office365-filtering-correlation-id: f9d54eae-06bd-4a64-f8a1-08dd3e9a5663
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|366016|7416014|376014|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?T09kOXNTOTJMMy9SVStmdkc2VTBXTENYcU1jSXhCYjFyaVNwRkNxQithRlAr?=
 =?utf-8?B?VmZjUWtENmFDckJvbVNScGxmMVExTlh4ay80Vi9GTlN5MlU4VFpFOXlzMFpW?=
 =?utf-8?B?aHZmSW5KTlRKME5DSFR0Y0VRRkV0VTNhV3VIeGZDSTVnNFE2eGg0RmMreDRK?=
 =?utf-8?B?TXdiNm5OdnhSWWREQit6anlFK1k4Z1d0dFFaN0xmVWppZGd6ZzZQeVBKRVJn?=
 =?utf-8?B?b2hCUzl4dU1sWEI1cUxCQ3ZnQVZSTmx6ZklDekFzbTFYVjF6eHdqbitvMWZq?=
 =?utf-8?B?ZnhZR1Z3NnVJWm94TGsrayt1VnFUYzdzYWZ1blZjMFRseXBkRmhSbXBJNHIw?=
 =?utf-8?B?ZzJmaktLY2EydDVCd1pCaGp1RFAvWGQyUmEvdkp6MVZDSThFT0FsMWFyUXNY?=
 =?utf-8?B?aXJNMld2RWoxT0o3MnhKcm1INFNoOHlYQnMyRU9aTVFQRVhYYUxoVk5Idm81?=
 =?utf-8?B?eG1zcjFTRURDNUdPZGZJMnBwSG0wY2xZaVZvV0ZwNnFUOE5EWjFMdTdJZjdL?=
 =?utf-8?B?T1l5S1YrWG1uZnJxbHJ2Zi83clJGVlFKMkVseDR3bmhQQWdGRDVsb3A4Y0Ev?=
 =?utf-8?B?S0Jpb3ozTVczMXU0SVBDQ0RGaVllRmdZcWkvTCthbE1PZnVXaHdBT1NpaEtw?=
 =?utf-8?B?SFBJZmFKTXBUK0MydzRtSmx2SHZLTTFnc1B3Q0xHN0dQTGIzL1JCQnlXdHMx?=
 =?utf-8?B?WFI2QnV4Z0UrcklsYUh5WklBNU5DSnJoSUxZSFZOcmczK1JXUlk2eFJ0RkZl?=
 =?utf-8?B?Tmw3akpqYmhkZnAvQkJrS3I5RkRBcWI2cmgzRVRuSk9BMVByYk4xYTVhUzRK?=
 =?utf-8?B?d3hDclBVSndJMlFEcU8xdjEwOG1pUU5YaGNpbktja0lxR0x3UWtjRTZKMTNl?=
 =?utf-8?B?Mnpla3lheHJwdVdFTzBzNzhDb1JCNFVITy9aTkZNYVNacS9JUEM0QnZBb1RD?=
 =?utf-8?B?WGE0VkhWNXpBOUp6QTM0NmNxVlMzd0lTWldVNGdwOUR2WFBvaGJFNUN2M2lK?=
 =?utf-8?B?YVVNR1FCQlVseUFTSWJEb3d4NmYyYlEzWGorN1UvcEx4S0Z5ZVdoRFNtazBt?=
 =?utf-8?B?dk1OckJPQUFBZ1o1ZXBzTm8xWUpTaEZseFBQZzlneXYyeU1jODY2eTVOdzBB?=
 =?utf-8?B?aExrV1Y0QzdjK25RbDNXOS9FdXhCOXRja00xMmhPYXFBUXhmR2hBNTJWbk0v?=
 =?utf-8?B?VHR0NU0rV2FrdklqalVMRlI4dDhNdlN1bWVzMGlPS3A2S2RKYXJZZ05aSzFk?=
 =?utf-8?B?b3B3ZWZVdnZjamdnTTBIUUFVLzR1R1lZNGw0dmdCb1I4ZGthMkYrcURyMzNw?=
 =?utf-8?B?ays4cURpRnppSTJrZUYrQ1kySWhFQlQyM2UveUJESlJORERkM3ZWb2pCQ1I3?=
 =?utf-8?B?a1FPWGUxNVFZZ2NCN2ZCT091VFRUMWFLd3lRQnNUMy92VWJ0Yi9ZYmtKUFVU?=
 =?utf-8?B?d1FpTmpjTWFTNjhsV3hsbU9kSkFKLzFYWDlYTHVHSEpPT081MDBiWW9PTHky?=
 =?utf-8?B?RXdrb3hCeXZtdVVWdDMydjF6QkMyUllWMVkwYm9hZzJhd1NWV1Nsa3ZlYk93?=
 =?utf-8?B?bjhQbUsrazZNVjBoL0puK2g4VnFTTXNCSU9VbDRERGhaNnBHajZqOFNCN1k2?=
 =?utf-8?B?SktFamhkRU05dW1kUC9Hb3ZYZnhEaTJ2dzRHSXpHdkk0a0ZIUU85dkc5MGlU?=
 =?utf-8?B?K01Tckd2YzBHRDBzMkxvZHRtYW43NlUyL2dKSEhvbkUreVZaRU9MK1RjSjZF?=
 =?utf-8?B?OHF3bjMzQnp3UTYrQms1ejJ1eEJJZzdoM05qTCtFZXViOWs4QjhzMDhUeW5K?=
 =?utf-8?B?c3czejFiQUZ5bm1ZVmxxKzJiRTBZeUtPbGhuclJWRmNqY0NHN0dNM1NaUmVG?=
 =?utf-8?B?SVJTRVVwNXdGSDd0MnYwcWpVc2lUeGNIODliYWVaNjNLZmI1MXZkR0U0QnJs?=
 =?utf-8?Q?TTUxRBy+zaVd0PkRMfUc1eWTY0Xz9UPQ?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM8PR07MB7602.eurprd07.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(7416014)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?M1Z3Rm50N3FsOTkxVDZUaHJmTlE0dE51L0UxdThYbVdMV1NPall2NEJmT1lJ?=
 =?utf-8?B?WmI1NEZ6Qlp6cjloWmZTSGRvOW1DYU9EZUNYaWViSU9wZEF5enU1dFFRbWJX?=
 =?utf-8?B?c0VxWTVBNkZiVjMwZzc1S1pCVEZqQWlsRk85YkRwZnFyQnpGS1lHeVdWNkQz?=
 =?utf-8?B?TUVNWWo4Wm1YWHhPdzRMN1RMNFhtRjV6V0dIcWtIL2VWRXkybTcvZmFpZHZP?=
 =?utf-8?B?QzhRTnFMcHB1MnRnbEt1MXRZbTI1RFFwZ2JLVDRWOW4zS2s0MSt2M2FxTUNY?=
 =?utf-8?B?T2JlalFGYWU3ODVsdkRndVBXbnZXYjZic3M4ZkRFT25UUm9rb1BaNm5CS095?=
 =?utf-8?B?dG9XR0JxRlkzL3F4MXY4OVBVL0hWVnFLUUhwaEEvbXpwSUU3bVVySWpjSVhp?=
 =?utf-8?B?ZWZiVWV1ZmZGclI3SVFlM3VONXlBYkNnNElXanVpQlErRTdobjEzL1FlMHRr?=
 =?utf-8?B?ZzJlb2FwV21UMU00eldHUThHbkV2MTRGUUhzVU94OGM4b1Q5amlpbDBVUDJM?=
 =?utf-8?B?TnV6S0xIR0ZXNUw1MS9QbG1SRFNROElIU2Uvb3FRMFdXcTdjdGZkZExxM2x6?=
 =?utf-8?B?Nkx5UGhDenYyK3d5QjY2VWM1aWs0dnNIT2M5RWxVZDZtcGU0MWVBWkdZOHZl?=
 =?utf-8?B?RjFmTkdXMkRMMllDUUY5SWVmZlBMY0N1TlI0R0RLc0QvL0hQbzVRNjIvRExP?=
 =?utf-8?B?enpSUURpTXdveXNtdSswVnJFYUlBV0grVTFIY2F0M3JpRDVZdjJSKzVKblAx?=
 =?utf-8?B?QldNRnAvWUFnQ3FEL0x3REI3YVBnWUhEamFmNU5RQzJRRzVaRFJUWmpzNVBt?=
 =?utf-8?B?elhPN0RyazdxbnQrckFiTHhNUXJsdkJJVnlwejUwbnFEdzUwSnFOazc5VTZm?=
 =?utf-8?B?bWUrcWVMYWFsdWNqY3REcDA5YXN1K29TSWdJVUNpeElGYXoweE5pUy9CRUQr?=
 =?utf-8?B?anE2VEt2Z0lTakJYa0c0MFZPV0FTZDZyZDhJbVNxK1pyaWRMNGZvcUh3Q1lQ?=
 =?utf-8?B?OEJodWg1c1I0SUQ3c09NWHhyRnVlUjFtYVpCNElrRUVNQ0Z4M0lzYW5GeVkw?=
 =?utf-8?B?OENpYjNMOEtHSWpNTDV4bnI5ZEgwMEhKQ2JwNHpNZE5VcUNLQnZMcGVDai9m?=
 =?utf-8?B?WUxUeWQ3Z3VPYlgrby9XNWZqUVFGazN5OXErbWpnVGxJQXJwOWNFYWt0Kzd0?=
 =?utf-8?B?UlRIcGFocWNIUi9EaW5rLzF1NGdLNEh6TXRPbHR2RVh3QkZKUzhoTDlHVXFs?=
 =?utf-8?B?Q2d4cHNrR1o2RWcyRHVrcVJBekVqWDNkUmtJcmFwUjlDWWp1M01pc3NRK0V1?=
 =?utf-8?B?WENiM0VxV1A5M3NIUkkydHVsbmxVTzVIMTN0ZWlyT1F2U1E0b2JOeFE1WE1T?=
 =?utf-8?B?ekY5bHFlK0tDMk9rVDBQUHdrbFZtRFhhalMyeldIVG5QSWhsWGhMUTdhZW9t?=
 =?utf-8?B?NDI4MGE3TmxIWks5SGRHeFkrb2ZEK1ZNVG5HUUdPSnlJemUwWml5U2ZDNks5?=
 =?utf-8?B?ekJZUFRyZThxc0F0TmdjY1Vjc3I1QXlsNzR1THBtVVVPRlArY01ybnJ0TWxw?=
 =?utf-8?B?MjA1UWVrc1NHcm5CcWRGSG9NQjZwbFZDSTNIYk1sZ0FzdDM3V3hiT0tGa0hP?=
 =?utf-8?B?NmlXRSswVy9xMTVQOUtqU0dkbStEd0JhWjgwU0JWd0hnYWRZSGY5U2VDVStK?=
 =?utf-8?B?QXVQQUNxc2hmWXoyMnBpZ3Irc2wwYlh3M0w0bm9lSkM3d0h3U0FGa3B6MFk1?=
 =?utf-8?B?UUV3aUU4VTQ5L3U5MWdGQllWc3lpcGVIdzBneFJBVk1BamhmZTNUK092NUdT?=
 =?utf-8?B?elV3aUdYblJVK0g4cSt0Q2lFUjIzZzVwSXpqcFl1bEo3VHZ6QmNNSWJJbm5W?=
 =?utf-8?B?d1BvTm5SeFUvTENjdkZzVG0vWm9tOUdNT2ovUkIrUGdTOHVpYUwyUWJZTDJw?=
 =?utf-8?B?bEsrNGp5VWt1UzV4NWJiQkVPMG8yRE9PeG5hTDVpWWpFaERuRlNqSkVvS0Iz?=
 =?utf-8?B?cXkrKzdycUdWQm1RMzZJVHNmQXpVbW5jY1dmeFd6RFh0ZHNuTzVEV3JSZGVv?=
 =?utf-8?B?d2xtU1JYclpoVDBmejBEOE9iQVcyc1lQZ0ZaMHZMV0pPUkFwWGpKWmpidmdC?=
 =?utf-8?B?SHUvRVVHeEFnME1rQnk4RllMUFg5MjhiVnZ2SzUvSi9MaXFJUGJ6M2V4djFS?=
 =?utf-8?Q?sPKESlwi/4QL0Mk4f8S16HM=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <958E267CCF822D4092CC9924836844F9@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: eviden.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM8PR07MB7602.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f9d54eae-06bd-4a64-f8a1-08dd3e9a5663
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2025 06:17:55.1524
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 7d1c7785-2d8a-437d-b842-1ed5d8fbe00a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: I/P/KrmLfqbd/5yRN/+LyxsqRywbvM/euRg8QeqVVLBwYGgZ2yngnNsEKwtWeuU4qEKcxOMBjh+v/i8qbBgst/5zLxyWJZxEGlr8Rp5pmN1sVOhqieEnpAzb/9KacmLw
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR07MB8792

UmV2aWV3ZWQtYnk6IENsw6ltZW50IE1hdGhpZXUtLURyaWY8Y2xlbWVudC5tYXRoaWV1LS1kcmlm
QGV2aWRlbi5jb20+DQoNCg0KDQoNCk9uIDI1LzAxLzIwMjUgMTk6MTMsIFBoaWxpcHBlIE1hdGhp
ZXUtRGF1ZMOpIHdyb3RlOg0KPiBDYXV0aW9uOiBFeHRlcm5hbCBlbWFpbC4gRG8gbm90IG9wZW4g
YXR0YWNobWVudHMgb3IgY2xpY2sgbGlua3MsIHVubGVzcyB0aGlzIGVtYWlsIGNvbWVzIGZyb20g
YSBrbm93biBzZW5kZXIgYW5kIHlvdSBrbm93IHRoZSBjb250ZW50IGlzIHNhZmUuDQo+DQo+DQo+
IEJlY2F1c2UgdGhlIFJBTSBGQiBkZXZpY2UgY2FuIGJlIG9wdGlvbmFsbHkgcGx1Z2dlZCBvbiB0
aGUNCj4gVFlQRV9QTEFURk9STV9CVVNfREVWSUNFLCBoYXZlIGl0IGluaGVyaXQgVFlQRV9EWU5B
TUlDX1NZU19CVVNfREVWSUNFLg0KPg0KPiBTaWduZWQtb2ZmLWJ5OiBQaGlsaXBwZSBNYXRoaWV1
LURhdWTDqSA8cGhpbG1kQGxpbmFyby5vcmc+DQo+IC0tLQ0KPiAgIGh3L2Rpc3BsYXkvcmFtZmIt
c3RhbmRhbG9uZS5jIHwgMyArLS0NCj4gICAxIGZpbGUgY2hhbmdlZCwgMSBpbnNlcnRpb24oKyks
IDIgZGVsZXRpb25zKC0pDQo+DQo+IGRpZmYgLS1naXQgYS9ody9kaXNwbGF5L3JhbWZiLXN0YW5k
YWxvbmUuYyBiL2h3L2Rpc3BsYXkvcmFtZmItc3RhbmRhbG9uZS5jDQo+IGluZGV4IDZjMzUwMjg5
NjVkLi4xYmUxMDZiNTdmMiAxMDA2NDQNCj4gLS0tIGEvaHcvZGlzcGxheS9yYW1mYi1zdGFuZGFs
b25lLmMNCj4gKysrIGIvaHcvZGlzcGxheS9yYW1mYi1zdGFuZGFsb25lLmMNCj4gQEAgLTcyLDEz
ICs3MiwxMiBAQCBzdGF0aWMgdm9pZCByYW1mYl9jbGFzc19pbml0Zm4oT2JqZWN0Q2xhc3MgKmts
YXNzLCB2b2lkICpkYXRhKQ0KPiAgICAgICBkYy0+dm1zZCA9ICZyYW1mYl9kZXZfdm1zdGF0ZTsN
Cj4gICAgICAgZGMtPnJlYWxpemUgPSByYW1mYl9yZWFsaXplZm47DQo+ICAgICAgIGRjLT5kZXNj
ID0gInJhbSBmcmFtZWJ1ZmZlciBzdGFuZGFsb25lIGRldmljZSI7DQo+IC0gICAgZGMtPnVzZXJf
Y3JlYXRhYmxlID0gdHJ1ZTsNCj4gICAgICAgZGV2aWNlX2NsYXNzX3NldF9wcm9wcyhkYywgcmFt
ZmJfcHJvcGVydGllcyk7DQo+ICAgfQ0KPg0KPiAgIHN0YXRpYyBjb25zdCBUeXBlSW5mbyByYW1m
Yl9pbmZvID0gew0KPiAgICAgICAubmFtZSAgICAgICAgICA9IFRZUEVfUkFNRkJfREVWSUNFLA0K
PiAtICAgIC5wYXJlbnQgICAgICAgID0gVFlQRV9TWVNfQlVTX0RFVklDRSwNCj4gKyAgICAucGFy
ZW50ICAgICAgICA9IFRZUEVfRFlOQU1JQ19TWVNfQlVTX0RFVklDRSwNCj4gICAgICAgLmluc3Rh
bmNlX3NpemUgPSBzaXplb2YoUkFNRkJTdGFuZGFsb25lU3RhdGUpLA0KPiAgICAgICAuY2xhc3Nf
aW5pdCAgICA9IHJhbWZiX2NsYXNzX2luaXRmbiwNCj4gICB9Ow0KPiAtLQ0KPiAyLjQ3LjENCj4N
Cg==


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 06:19:12 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 06:19:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877431.1287570 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcISk-0001RC-Ph; Mon, 27 Jan 2025 06:19:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877431.1287570; Mon, 27 Jan 2025 06:19:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcISk-0001R5-N3; Mon, 27 Jan 2025 06:19:10 +0000
Received: by outflank-mailman (input) for mailman id 877431;
 Mon, 27 Jan 2025 06:19:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=50Ot=UT=eviden.com=clement.mathieu--drif@srs-se1.protection.inumbo.net>)
 id 1tcISj-0001Qv-PJ
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 06:19:09 +0000
Received: from smarthost2.eviden.com (smarthost2.eviden.com [80.78.11.83])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9dfe28a9-dc76-11ef-a0e6-8be0dac302b0;
 Mon, 27 Jan 2025 07:19:08 +0100 (CET)
Received: from mail-norwayeastazlp17013076.outbound.protection.outlook.com
 (HELO OSPPR02CU001.outbound.protection.outlook.com) ([40.93.81.76])
 by smarthost2.eviden.com with ESMTP/TLS/TLS_AES_256_GCM_SHA384;
 27 Jan 2025 07:19:07 +0100
Received: from AM8PR07MB7602.eurprd07.prod.outlook.com (2603:10a6:20b:24b::7)
 by PA4PR07MB8792.eurprd07.prod.outlook.com (2603:10a6:102:266::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.22; Mon, 27 Jan
 2025 06:19:05 +0000
Received: from AM8PR07MB7602.eurprd07.prod.outlook.com
 ([fe80::fbd7:ca71:b636:6f9d]) by AM8PR07MB7602.eurprd07.prod.outlook.com
 ([fe80::fbd7:ca71:b636:6f9d%7]) with mapi id 15.20.8377.021; Mon, 27 Jan 2025
 06:19:05 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9dfe28a9-dc76-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=eviden.com; i=@eviden.com; q=dns/txt; s=mail;
  t=1737958749; x=1769494749;
  h=from:to:cc:subject:date:message-id:references:
   in-reply-to:content-id:content-transfer-encoding:
   mime-version;
  bh=dMoMtMlz3GxWv3/X28rMpuYtMbtTb6eezMZZCUrs0IM=;
  b=vnyADmJkDMlhZy5/4KphcDvh1YucSIHGRPus1rqOq8MKfAGSSswPqWec
   JhQ9W/e85LzKd99gaXQaC79luPf8DMdfssRTL0Rv5L8sJKhC65dDXRKMI
   TuZcJJBuOaE4MLpBlUd+/FgRGOO8CXAe4p9GOKhYGsZ/1ku1uzBog4bAL
   E/i4FWT+ukYDObNpV/1K3JDRaraLnl5a2yP4nbijRLNrvu9zOaXWASq4r
   vZDN/JTv3Bqd5QhRT4m5t3dXXuSLfN0Gz0iS0DREaapKIMLLB9q3zo3Er
   wHO1cUB62nPMAVre7V4G26RTluObKgzuhHtuO8wA/84S7AKBUSJqC2XS1
   A==;
X-CSE-ConnectionGUID: 1j7MsqVgSjySF9o4kFr5oA==
X-CSE-MsgGUID: tLZX6sjSTl2ri1xvGei7bA==
X-IronPort-AV: E=Sophos;i="6.13,237,1732575600"; 
   d="scan'208";a="29555075"
X-MGA-submission: =?us-ascii?q?MDFyddhe/Na/XSsvQcRUD5Q7znYihlPYdc3azK?=
 =?us-ascii?q?68+m0BIfMTf/RZg1WkjDvXPzBGKfmw08EqHxgtLIpPsoVeOa9FR0C8J2?=
 =?us-ascii?q?0ofgSdArny2acC7YtGdJfj7aHCJ1NVYzSBdB6H3HZUMbA+K0r1SQz3fy?=
 =?us-ascii?q?2VgE10wRYoxiGyYy9zgRbhYQ=3D=3D?=
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=pFqBLTAaoNuQLjtOy2HvByo+5bu24OrNWdvapImWsKpOtJA2U++J7lEVgZwItDch/3X0iZfiegYO0P6mCP6Qq8FjAJBrHLJjdE8GOd9UspW/m2AOreqns1ndsOvaO667g53yqGS/J0/i5k2Uyxg6V/ATOFQmL+XTjuMYMVA7EVZXy3dRs86nct/RX1EO8hSP7VVxQtt/uAKulEVFnG+WfOJdswGCmIHAVSfu1QQsHCbADeWJIEt2XFtXdOznGOViK6sPiGt2pTvDqdy4SUWdLj3Y/tD5OiQJXIfRRtbbCFpxQ0wxbCenxfPTbjUxduElW64yxEP0qJUvIOMPerkXxQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=dMoMtMlz3GxWv3/X28rMpuYtMbtTb6eezMZZCUrs0IM=;
 b=q3rlys+4ZLaMkIVPMdUi4HjE4tPadM2c5y4amqGRJzo5hk1xsAF4LMQBIQiHKMs3zJefeqfe8fejAt+RrOGIvt0aU2ZcgniQZpCYOhTaE7HX+jShLuLYTdPLBJnN9HETb1fMYBHb9OnZ6y+20KnTOEJPwgm4qIGSmcx2YTnbWrW/MglPaHj3uZ+Z2af/5xmrAAaWalroXHGI7LjfJjKdzFnoWwiLBzxvZ7Ql0zi9fkNOxLiCH5eWA8rbIMX+rq0dNL9FZLvemGrl9hLvk3W8OB21MOe1wPTmI2+hiUk4LBVSLe6s86WufzbD2wKNPBC3I+1VJADAa0jh2PqZ3hLLjw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=eviden.com; dmarc=pass action=none header.from=eviden.com;
 dkim=pass header.d=eviden.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Eviden.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=dMoMtMlz3GxWv3/X28rMpuYtMbtTb6eezMZZCUrs0IM=;
 b=rzRZP3tbMUspWp6jePS6J4juK45MVVnT2oXQ97HwIt2URmfCv3BHron2tdXI2YHz/g0YSW1zGEKpVvIFK85QPN9dgJFT9b4+Ucmwg6UNCRNq0pqfj2BCnCvytp8LGwhnYxFrP7TjXpB1DHs0gCEke1UJPggWjd6N/RVvaOZ1kLWQ8i6CcxqPS/n79FlxbW3W6HolRLWJ4uhVABuHORejxVGZmWomDL8QWU3nbteyakCkU2eK8oP/N6mwccCw34IzQN6voWrJvbe+A+3oebTL3uT8dBsWMZCPnmP90ZMk/39PfSnRkE+2ntCYNBlwyw6MKpaUeIzA7kFUM+OZGZmiqQ==
From: CLEMENT MATHIEU--DRIF <clement.mathieu--drif@eviden.com>
To: =?utf-8?B?UGhpbGlwcGUgTWF0aGlldS1EYXVkw6k=?= <philmd@linaro.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
CC: Yi Liu <yi.l.liu@intel.com>, Markus Armbruster <armbru@redhat.com>,
	Eduardo Habkost <eduardo@habkost.net>, Anthony PERARD
	<anthony@xenproject.org>, Gustavo Romero <gustavo.romero@linaro.org>, Jason
 Wang <jasowang@redhat.com>, "qemu-ppc@nongnu.org" <qemu-ppc@nongnu.org>,
	"Michael S. Tsirkin" <mst@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>,
	Alexander Graf <graf@amazon.com>, Richard Henderson
	<richard.henderson@linaro.org>, Stefan Berger <stefanb@linux.vnet.ibm.com>,
	Bernhard Beschow <shentey@gmail.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Gerd Hoffmann <kraxel@redhat.com>,
	=?utf-8?B?RGFuaWVsIFAuIEJlcnJhbmfDqQ==?= <berrange@redhat.com>, "Edgar E.
 Iglesias" <edgar.iglesias@gmail.com>, "xen-devel@lists.xenproject.org"
	<xen-devel@lists.xenproject.org>, Marcel Apfelbaum
	<marcel.apfelbaum@gmail.com>, Alex Williamson <alex.williamson@redhat.com>,
	Paul Durrant <paul@xen.org>, =?utf-8?B?Q8OpZHJpYyBMZSBHb2F0ZXI=?=
	<clg@redhat.com>
Subject: Re: [PATCH 3/9] hw/sysbus: Introduce TYPE_DYNAMIC_SYS_BUS_DEVICE
Thread-Topic: [PATCH 3/9] hw/sysbus: Introduce TYPE_DYNAMIC_SYS_BUS_DEVICE
Thread-Index: AQHbb1TqeocQ1Uio5UusvHnGsHg3IrMqJ/wA
Date: Mon, 27 Jan 2025 06:19:05 +0000
Message-ID: <51ae5676-cd6a-4524-a958-0840f6daca06@eviden.com>
References: <20250125181343.59151-1-philmd@linaro.org>
 <20250125181343.59151-4-philmd@linaro.org>
In-Reply-To: <20250125181343.59151-4-philmd@linaro.org>
Accept-Language: en-GB, fr-FR, 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=eviden.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: AM8PR07MB7602:EE_|PA4PR07MB8792:EE_
x-ms-office365-filtering-correlation-id: 55069c99-6789-4479-003c-08dd3e9a806f
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|366016|7416014|376014|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?RWVjVG5vVTU5dUYzTGpmbUlsYlphdnFTL3RlRjhjTVloRWZPdWR3N2d6c3Ni?=
 =?utf-8?B?ZWVBaGY4QXNnTTAvNVF0VmN3VFA1ZFkyTmpRbDFScmRVaVNWQXpUbTRKNnBX?=
 =?utf-8?B?aGQzOGFQZXJ3RzBpUDc2WjNvMDZhTUsvQ0cvbmFRUjNJbEQ3Y1ovejBMM2x5?=
 =?utf-8?B?OTZRK3Z0RXVsTTRURkg2RC9IYzZiZGc0d3J2WU96YVV2b2lJTnNIVncyYzNr?=
 =?utf-8?B?RjRCMWt2alpFRDNaMGFZdlVBMXBZTXZJb0VmTU5tcGdJR3VQcWxqdkFzTjJI?=
 =?utf-8?B?NXNiTFFZbXJiUEE4eUp4MGVJVXJWbUh6NWU2RjROZ1d6UFM1b1BHaHdMSXZQ?=
 =?utf-8?B?UW1PckNycmsyMTVOckZoOHJPVWtIMXMzY25FSWtTa05tMGs0eVJyWVlNVkJi?=
 =?utf-8?B?cWg0TmdVUUZybXUyQ01uMC9EWC9NZ1AvWFplL0tmMVNMbHlFNkFyVGcwUHRa?=
 =?utf-8?B?czN5Uml0R2ZMYmk0YVVoRi9KdnMvSER3M2o3bWFjTE42V3cxTzZHSVJvNUMz?=
 =?utf-8?B?ODVoSmFOZlpOZVNWK0lVNENjTEs0dFFGRElxWWhvcFBEYmRBU0RLeWlHN2Vj?=
 =?utf-8?B?Uk93Y2djYnl0akdnRWhQUTFtRFFmRDZyUFhHMjBMWUIzQWV5L0pSRjlRL0xS?=
 =?utf-8?B?bTExUVAwU2pwZEJUYUlkRkFEejNpWFpJdmluMTdUR1VYTHVpRE5vNlQ4V0wx?=
 =?utf-8?B?Z0ZZMVdCWm5GYkVVTURCenVpUzRaS1NaNXRpSWEvT2d6NUJGcTFnU2xFbHJS?=
 =?utf-8?B?QXdTQXI3NWNKM203bUhUYjdHSmczRWZvR0U4cnA3VUNPc2hydzRhYWFkUXEv?=
 =?utf-8?B?R2JUTWo0aWFQMnAyaVQycHN3Q0l3a0NUTDh1OVo5cFBDSzltWVNDNm01bklR?=
 =?utf-8?B?dTl2K0ZJMTY0UE1GU0Q3SUNxSDBlL1VCNkEzM1I1ODdkRC84akV0WjM5ZzAy?=
 =?utf-8?B?T29CemtRWUpyOHpUWVIxWXd6MG1RQnhCTzFUVDlVUHF3aUYzMERBaDZaRzd0?=
 =?utf-8?B?b0QreEkyOXFuVDYxUkVWVVdycWx0MTNjamViWmtoV0NzTXBvZHJpSzh0MWRw?=
 =?utf-8?B?Qm1icFFKZk9SaEFVNS9ZclZRa1lybEs4b01hMkRIV3gzeWprYkJrYUI4UlZt?=
 =?utf-8?B?VHBsdTdPRGJtSXI0SUtYVkNBclpXZTdmQ3dOV2M4SGkvcTE1cVNyaWhTU2Z0?=
 =?utf-8?B?bWZIcWdyY2g1Nk9xT2lOd3liVndITHUvOExDWklrcy81dlBPMUdCMGs1SFp6?=
 =?utf-8?B?WEN3MGVhTTBhcWpnMTRJMGlIbHZkUmNlUThEdEs0eFlQRUEvWTRJU2VWTmE5?=
 =?utf-8?B?dzRlZ2U4NzN5VWlYbDVPMXFtTUFHK0pEclY4VFJBa2h5M0RSdXA5TUlqalFJ?=
 =?utf-8?B?MkFxWFZhVDBMZ3ZIc00rMUltRkJVR0twRzUySC84TVhWZzZaNW1zVFhxU1du?=
 =?utf-8?B?b2cyR2Z1UEdSbzNYeU1td2hWbFZmSzNCc3hEQjZ1eGVhQ2FScjcrN05PVmoz?=
 =?utf-8?B?MWJtVWFBUGdZRW15S09GOG5ZVWpGMkxjbGhoYTM1VlR0ZGhkemtIaEFZZDlx?=
 =?utf-8?B?WUV0UVJ2TGxCK0F2T1F0bVMzMVlQeDh6WHoyU3Y0L1RKNFhCbVFFcXFXTGlo?=
 =?utf-8?B?Myt6RDFhbXNSVms2VTBTSGdGbW10NFZNVERYdmRxcEVBekNWK00rTjlsVnVz?=
 =?utf-8?B?SUgyR21LdHJpalNxWXRaUlRubjZLTVk2NWFCa1BHN24xdXBBSDZuc1FrU29K?=
 =?utf-8?B?MXprNE1NLzlZOFA3SlpQdXVNTm5xSG44eHh5S3gxQ0NVd2V3eUlFTWYrbWRz?=
 =?utf-8?B?cUJzSkFtMnlIdFoweW9ucVpxV2x1aFg4VDk3cGVtSWlBQVJ0ZUh2a0VWMzlz?=
 =?utf-8?B?M05sZnF5TVRXR3JNcHRmTEVpcWlGN1lEblNidVIwVERqdlBPcU1sWU53SFB5?=
 =?utf-8?Q?LKisISsNUR2FESkxyEnKbj1tf17P0jgu?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM8PR07MB7602.eurprd07.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(7416014)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?N1EzZDhHcXhZMTZuN2xBVGFsbWFJUWs4S3laVlc5NU85NXFjU0VkV0t2eGpy?=
 =?utf-8?B?SXgvYnA4blJUejkwYndSL25VS0FDbnowZWNxc1M0T2pKSG1mNnM0Z1RNSFpJ?=
 =?utf-8?B?WmdqLzZhVGhxbmNMTWJWOG5kQVdEa2RBRDB0N1lkRlIrSnc1ZlM1V0g2NERX?=
 =?utf-8?B?clBTS3M0REFnMTQwM2YyNXZtVzlUYWFML2NIUlZXcndud3VtSktnT1EzTkxq?=
 =?utf-8?B?YzlJcFlvVzNkUkpMbjZ4cy9zcWl4UHk2cS9ybDFIRkdBdGViN1h2cVpWSXRv?=
 =?utf-8?B?N2V2ZjZvZzVOS2RLeHAyZ09wNWd3UTVIcTRqbzg5Zjd4WjlKNWhnZ1l3bXlK?=
 =?utf-8?B?Zm1CTGQyV0VaTG1nZVNXVzN3dkp5VWJvbXdodGdEcUpzOUFEbVBvT3p0eEhK?=
 =?utf-8?B?MUR3bWNrdE45RUdnYTNTZ0JreC8ybm11VkZ6K3B0Y1FCY2M2RDZDSzYxTlFm?=
 =?utf-8?B?U29pQktyeSswNXNiZkFQM1RVTkwrYVczK2FSRWtZNTQycjNmYkQwdUsyeTJ1?=
 =?utf-8?B?NDNLWTZzUDREckJZclVwY0pqR3JTY290eUJMZXZmcmUzSnUvNmpGWHB3aWs1?=
 =?utf-8?B?V25IVlJTemVURERUUkh5RGVTVTZrZ0N5RFQ0eXpiNE5rRTR4cGRWa0NRL2xC?=
 =?utf-8?B?WlF2bm1oMlpzRGhZQU8wdE5ZS0M0RmVyTjVlR1BBaXNtbXRqc3A4VGZabHNn?=
 =?utf-8?B?YnNtVmx5MjdobjZublhDWGYydy82aUF6a3JOV3YybEFmbnVOL3IrSGNnUEF4?=
 =?utf-8?B?aHJCd2kwK1RXL1JLTkx5YTZLTVBMWEdIZDNPdC91Ri9wUTNuWDBVR08wQjZx?=
 =?utf-8?B?MmtNMnA1OTFCSld1UlZwbEtBWTdlcFJLNlR2UFNOaGcrV25sUnBiNFFxSUhK?=
 =?utf-8?B?RlVaUG1wOWpxZVBTSURrTU5zWWpoZWNHWUtrMnUzWWQxZ21aaW1kVEVOWXZZ?=
 =?utf-8?B?L0QyYThMV0h6dkZNU2FRbHVwWGxoWVJVZEFjVnFKQUROMmlydklPSFNjaE5G?=
 =?utf-8?B?SC83UHBpSkdtZ1d5R0NGdjNwMGI3MVRBUDJwSkZHUWl5Rnhyd1lxc0cxSWpz?=
 =?utf-8?B?d0hTMS94ZDYwa1A0elIxeEdJV1NnT1A5Yk01RkVyVmQ0b0greW1tc2hCM0dN?=
 =?utf-8?B?aDlMSDJJbVZCSktkOTdFTjhzWFBPKy9IZEVCejBIQUlDTENYMUVjTHc1Qk9R?=
 =?utf-8?B?TmVNN3gyQjM1U1h0TGxSb0JEdVl6UUZYUUVFY2l1U243a3hoT2pIVjR5a25C?=
 =?utf-8?B?SXF3WFVsWUxYWHNBYTlVMy84MjZqQ2FIU0l3L09LMVE1VnV5YUNzaFNpY29L?=
 =?utf-8?B?aU1KNU0xcjIvYmJOUzk1THNmN0NLSGErVWNDNGhVcWVYLzZrdHhScFpEYy9x?=
 =?utf-8?B?dGxJTkFkRzBRdS9JSVJkU052OWJrRjF3bm1Jcnkrd0EyTGRzMVpGS2lrZlJY?=
 =?utf-8?B?djkzaG1yMHErUzRjYmZIV29EMFpuQ1dhSFVPc0M5M01sY040K0RnOExtZkVu?=
 =?utf-8?B?d0RDQ2JzU25tdnMyLzNhdU1SdGNrd0pNWVRlcFdXbUJkRHhBTm1COFBGWW9m?=
 =?utf-8?B?NStsVktHU3ZNU1pMUmFDaUlXNVdMRGwwTFNxUzlyemFnOWVuc3JsVEc1SStT?=
 =?utf-8?B?eGZLRHE0UTRsZTFaQU1QRjR6c1RvTHhiMmUrT1MwTGh5blBHOXNhS2ZJdnVm?=
 =?utf-8?B?bHNUSDBHUlZJWEtYSjdDRk90MWJFLzJpd1h5U3k5TEJETmFkbDUwOWorMXpR?=
 =?utf-8?B?aGg3Y3lVV0lZQzVDcUQydzRaUHRCTzlmaTFTOFBmSm9aUVNnK1JRUUJwcjkr?=
 =?utf-8?B?SGw4aktwRUdkNkJRZHpWVkN1ZnlOL0oyZDJKOHdsWWNmSWJUWFo5eDJ1ZTNr?=
 =?utf-8?B?c2F4YldiS2RVdzVyRndPMVR4bFMzRUxPSnQzKzV2NWl2VTRKV0RDdXVFU3dq?=
 =?utf-8?B?dGhDK1Fydm9SZ3VPdk92YnJFV2lRYVFwYzZvUEozWEJ4L09EZEhiL1UxVk9k?=
 =?utf-8?B?NFZXTE9LNjhLdEtGVzYrSjJZSDRzdHcvd3hnUEx3WkRZV3oxY2RPRnFqVzlU?=
 =?utf-8?B?a1V3eDllOUVxZ3c2aXoxVnovZVQ5WGhyRWxveXpodE5aN285Zy9VdHhHTHd4?=
 =?utf-8?B?b0xTR0loNGpiOUwwZHRoMlZoWHFVZzJCekFHZ1R2eDN0RVRxTVUvZUhNMnBh?=
 =?utf-8?Q?TPMQ2UF5S1b/30LxTenZnnU=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <1727EF0379D2344D9454C2E7B5BFB77F@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: eviden.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM8PR07MB7602.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 55069c99-6789-4479-003c-08dd3e9a806f
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2025 06:19:05.7076
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 7d1c7785-2d8a-437d-b842-1ed5d8fbe00a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: pngV+PB33VPp0FHdM8ru/fOTF3ykY1HbDTcpyVFj5vZSsWqDI6B7STT9g5sfFM487EJX2T2kfqmoZg27/dw6PRAiuf+H9MTvpiN/r5nG2EDLHHnOZ0AzxKHAf6jKJCF8
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR07MB8792

UmV2aWV3ZWQtYnk6IENsw6ltZW50IE1hdGhpZXUtLURyaWY8Y2xlbWVudC5tYXRoaWV1LS1kcmlm
QGV2aWRlbi5jb20+DQoNCg0KDQoNCk9uIDI1LzAxLzIwMjUgMTk6MTMsIFBoaWxpcHBlIE1hdGhp
ZXUtRGF1ZMOpIHdyb3RlOg0KPiBDYXV0aW9uOiBFeHRlcm5hbCBlbWFpbC4gRG8gbm90IG9wZW4g
YXR0YWNobWVudHMgb3IgY2xpY2sgbGlua3MsIHVubGVzcyB0aGlzIGVtYWlsIGNvbWVzIGZyb20g
YSBrbm93biBzZW5kZXIgYW5kIHlvdSBrbm93IHRoZSBjb250ZW50IGlzIHNhZmUuDQo+DQo+DQo+
IFNvbWUgVFlQRV9TWVNfQlVTX0RFVklDRXMgY2FuIGJlIG9wdGlvbmFsbHkgZHluYW1pY2FsbHkN
Cj4gcGx1Z2dlZCBvbiB0aGUgVFlQRV9QTEFURk9STV9CVVNfREVWSUNFLg0KPiBSYXRoZXIgdGhh
biBzb21ldGltZXMgbm90aW5nIHRoYXQgd2l0aCBjb21tZW50IGFyb3VuZA0KPiB0aGUgJ3VzZXJf
Y3JlYXRhYmxlID0gdHJ1ZScgbGluZSBpbiBlYWNoIERldmljZVJlYWxpemUNCj4gaGFuZGxlciwg
aW50cm9kdWNlIGFuIGFic3RyYWN0IFRZUEVfRFlOQU1JQ19TWVNfQlVTX0RFVklDRQ0KPiBjbGFz
cy4NCj4NCj4gU2lnbmVkLW9mZi1ieTogUGhpbGlwcGUgTWF0aGlldS1EYXVkw6kgPHBoaWxtZEBs
aW5hcm8ub3JnPg0KPiAtLS0NCj4gICBpbmNsdWRlL2h3L3N5c2J1cy5oIHwgIDIgKysNCj4gICBo
dy9jb3JlL3N5c2J1cy5jICAgIHwgMTQgKysrKysrKysrKysrKysNCj4gICAyIGZpbGVzIGNoYW5n
ZWQsIDE2IGluc2VydGlvbnMoKykNCj4NCj4gZGlmZiAtLWdpdCBhL2luY2x1ZGUvaHcvc3lzYnVz
LmggYi9pbmNsdWRlL2h3L3N5c2J1cy5oDQo+IGluZGV4IGM5YjFlMGU5MGUzLi44MWJiZGExMGQz
NyAxMDA2NDQNCj4gLS0tIGEvaW5jbHVkZS9ody9zeXNidXMuaA0KPiArKysgYi9pbmNsdWRlL2h3
L3N5c2J1cy5oDQo+IEBAIC0xOSw2ICsxOSw4IEBAIERFQ0xBUkVfSU5TVEFOQ0VfQ0hFQ0tFUihC
dXNTdGF0ZSwgU1lTVEVNX0JVUywNCj4gICBPQkpFQ1RfREVDTEFSRV9UWVBFKFN5c0J1c0Rldmlj
ZSwgU3lzQnVzRGV2aWNlQ2xhc3MsDQo+ICAgICAgICAgICAgICAgICAgICAgICBTWVNfQlVTX0RF
VklDRSkNCj4NCj4gKyNkZWZpbmUgVFlQRV9EWU5BTUlDX1NZU19CVVNfREVWSUNFICJkeW5hbWlj
LXN5c2J1cy1kZXZpY2UiDQo+ICsNCj4gICAvKioNCj4gICAgKiBTeXNCdXNEZXZpY2VDbGFzczoN
Cj4gICAgKg0KPiBkaWZmIC0tZ2l0IGEvaHcvY29yZS9zeXNidXMuYyBiL2h3L2NvcmUvc3lzYnVz
LmMNCj4gaW5kZXggMzA2Zjk4NDA2YzAuLmU4ZDAzZmQyOGQ5IDEwMDY0NA0KPiAtLS0gYS9ody9j
b3JlL3N5c2J1cy5jDQo+ICsrKyBiL2h3L2NvcmUvc3lzYnVzLmMNCj4gQEAgLTMyMSw2ICszMjEs
MTQgQEAgQnVzU3RhdGUgKnN5c2J1c19nZXRfZGVmYXVsdCh2b2lkKQ0KPiAgICAgICByZXR1cm4g
bWFpbl9zeXN0ZW1fYnVzOw0KPiAgIH0NCj4NCj4gK3N0YXRpYyB2b2lkIGR5bmFtaWNfc3lzYnVz
X2RldmljZV9jbGFzc19pbml0KE9iamVjdENsYXNzICprbGFzcywgdm9pZCAqZGF0YSkNCj4gK3sN
Cj4gKyAgICBEZXZpY2VDbGFzcyAqayA9IERFVklDRV9DTEFTUyhrbGFzcyk7DQo+ICsNCj4gKyAg
ICBrLT51c2VyX2NyZWF0YWJsZSA9IHRydWU7DQo+ICsgICAgay0+aG90cGx1Z2dhYmxlID0gZmFs
c2U7DQo+ICt9DQo+ICsNCj4gICBzdGF0aWMgY29uc3QgVHlwZUluZm8gc3lzYnVzX3R5cGVzW10g
PSB7DQo+ICAgICAgIHsNCj4gICAgICAgICAgIC5uYW1lICAgICAgICAgICA9IFRZUEVfU1lTVEVN
X0JVUywNCj4gQEAgLTMzNiw2ICszNDQsMTIgQEAgc3RhdGljIGNvbnN0IFR5cGVJbmZvIHN5c2J1
c190eXBlc1tdID0gew0KPiAgICAgICAgICAgLmNsYXNzX3NpemUgICAgID0gc2l6ZW9mKFN5c0J1
c0RldmljZUNsYXNzKSwNCj4gICAgICAgICAgIC5jbGFzc19pbml0ICAgICA9IHN5c2J1c19kZXZp
Y2VfY2xhc3NfaW5pdCwNCj4gICAgICAgfSwNCj4gKyAgICB7DQo+ICsgICAgICAgIC5uYW1lICAg
ICAgICAgICA9IFRZUEVfRFlOQU1JQ19TWVNfQlVTX0RFVklDRSwNCj4gKyAgICAgICAgLnBhcmVu
dCAgICAgICAgID0gVFlQRV9TWVNfQlVTX0RFVklDRSwNCj4gKyAgICAgICAgLmNsYXNzX2luaXQg
ICAgID0gZHluYW1pY19zeXNidXNfZGV2aWNlX2NsYXNzX2luaXQsDQo+ICsgICAgICAgIC5hYnN0
cmFjdCAgICAgICA9IHRydWUsDQo+ICsgICAgfQ0KPiAgIH07DQo+DQo+ICAgREVGSU5FX1RZUEVT
KHN5c2J1c190eXBlcykNCj4gLS0NCj4gMi40Ny4xDQo+DQo=


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 06:21:11 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 06:21:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877441.1287580 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcIUe-0003BO-42; Mon, 27 Jan 2025 06:21:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877441.1287580; Mon, 27 Jan 2025 06:21:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcIUe-0003BH-1L; Mon, 27 Jan 2025 06:21:08 +0000
Received: by outflank-mailman (input) for mailman id 877441;
 Mon, 27 Jan 2025 06:21:06 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=50Ot=UT=eviden.com=clement.mathieu--drif@srs-se1.protection.inumbo.net>)
 id 1tcIUc-0003B9-Nj
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 06:21:06 +0000
Received: from smarthost4.eviden.com (smarthost4.eviden.com [80.78.11.85])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e2fe6632-dc76-11ef-99a4-01e77a169b0f;
 Mon, 27 Jan 2025 07:21:04 +0100 (CET)
Received: from mail-db8eur05lp2111.outbound.protection.outlook.com (HELO
 EUR05-DB8-obe.outbound.protection.outlook.com) ([104.47.17.111])
 by smarthost4.eviden.com with ESMTP/TLS/TLS_AES_256_GCM_SHA384;
 27 Jan 2025 07:21:02 +0100
Received: from AM8PR07MB7602.eurprd07.prod.outlook.com (2603:10a6:20b:24b::7)
 by AS1PR07MB8406.eurprd07.prod.outlook.com (2603:10a6:20b:4c6::5)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.22; Mon, 27 Jan
 2025 06:21:00 +0000
Received: from AM8PR07MB7602.eurprd07.prod.outlook.com
 ([fe80::fbd7:ca71:b636:6f9d]) by AM8PR07MB7602.eurprd07.prod.outlook.com
 ([fe80::fbd7:ca71:b636:6f9d%7]) with mapi id 15.20.8377.021; Mon, 27 Jan 2025
 06:21:00 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e2fe6632-dc76-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=eviden.com; i=@eviden.com; q=dns/txt; s=mail;
  t=1737958865; x=1769494865;
  h=from:to:cc:subject:date:message-id:references:
   in-reply-to:content-id:content-transfer-encoding:
   mime-version;
  bh=BBWPPFO0UvFY6u15cvi/CxrwzvN6Ekt0rsISfzh5XrA=;
  b=Xh4Vy0inRTTplAjb2bsXIH3kX3HB8yHSj6RJ1apU4DJDgrveaGk3rMUh
   rJdGJT4eSf5JcrZ+e7UXFw50dJdyGspMHGcneTzHuYcNxElDuabt+qaFv
   uN28umni52jlPlf9JZ1UtQHWmcenK5dYdijgs+Q58+rOy/f0sLiYhkZV4
   P40NN/U4JGDb9MZHXGWKpZWmE33NHPMA7jCFOw8e+M3eUHqSs8JSqSAv3
   lyST4e5ZOT9jljbQ3ff49r5nWW9bCKoPkfCZN6pCp52DhrQOQ5D0jZpc8
   EBFdoRRz5qAqZwOu6A6/CCIO7sWKjcsW+pCXZB2FfLS3PU1Ma6bLukDYg
   g==;
X-CSE-ConnectionGUID: MQcg4tsmRdasLg+8NmCZrA==
X-CSE-MsgGUID: a4yGjDZ0TJ2KukVwJOV1eA==
X-IronPort-AV: E=Sophos;i="6.13,237,1732575600"; 
   d="scan'208";a="30780747"
X-MGA-submission: =?us-ascii?q?MDF9INvXSJtcvfFYDGOg35CcitGa7LyRuAUv3r?=
 =?us-ascii?q?8/h2UcxOEQDEwHmv6KfQFwkEHsp9+yc0nx6bcmhhomMVQWeQEGzRGP/x?=
 =?us-ascii?q?ODjDPMXSC9m/e7YxqJhL44oL4Ix40Qh0sGRZjnRwmU9Xp29/Sm67/Ogr?=
 =?us-ascii?q?UU/b9ru5Y2M4/i+cAfxNiLgQ=3D=3D?=
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ENdvjzBmNm4Ugt3b81/uw8p6HCYIRQcAS8J75S10n+1b1UntpGSn3FksIlROpSuKzca5pRuGmXZsk7RG8BzewUKsJHDOz+fCunnEp9DRGBI+gwK0ifT4763EGlLk7BZfq1GwnMza8TO1kSoNZjg/ZLb5fisDfSkq6I9oRzXFAQpquuycdSVi4dYnwD4ZuVykySUtYq8H6OgQM5Kz+A4JCztVOVnBX5NQ4mw8yPGAPQCTW8IwXnfqBZf81C9HJwalvZ7CYw1jRAXNY/9DVkGnYdHjfThaRt2wH1Qrr+Xh77ea/EyoNpmkiSfJTbAsBdOo80pcnikSKauwsa/82xaY3w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=BBWPPFO0UvFY6u15cvi/CxrwzvN6Ekt0rsISfzh5XrA=;
 b=UOvy8QeJSTuJr5zpPvRIzNjb8SbnH3WyHefoKbn9HqQ2kl70OHbQr9uQREKWpkAg6WcNrkzA1g6v65rfHkhcoBw0gs+G8eqsBkPtc53QSGjq3VZ3BRzSndOnHo3OhFmYvHuHzqTXuwfccvhEML27wW0w8hBI3j93ZhjKoLUvG3ELo9wgzeIyRlpqAmc3+AetX9dZxXizRM5LNTneoIgSIk6+G/qDc5GADUYIj3tN+cozHgN/AE0flGqMXL1kyh5wNM+Q7FOlzfpRNrqoGrZLbbKJBj1XOY+poU7EjWodNfK7Lqd4TsscSvy1Icgw+oF2SgjjmU6czMjVGMIddCyd5A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=eviden.com; dmarc=pass action=none header.from=eviden.com;
 dkim=pass header.d=eviden.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Eviden.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=BBWPPFO0UvFY6u15cvi/CxrwzvN6Ekt0rsISfzh5XrA=;
 b=N2YbzI1KT9FQBO243bnWY/3hHObgwqtFvQB1lYbeMZUKJlLXOwyLFwuZkLbWqKrIrlxwSe1b1bCv48E9r768IHumLaa6uc7C0RNMqqUriiQarLb3MyO/4RrAQRTRCSAgMYjoa1bYaokUCNn7fXHOvkFApVKhCnyvB5XU8nxjP1goWz/uFOOkQSI41brF6aFYygDkYd8PR8V5RsryIUix/keS9V2g0y73yW28dZ+OgVT5mSgYDntVd0zAqKIhMUzUHkXMNOKuLnfAYFK6mq7R9gXt6jxaTSMOul297ezrtjq4oL9KpaI4xXMtHJI2zM2DR1zUoJNd/N8eIz/HO/w4Fw==
From: CLEMENT MATHIEU--DRIF <clement.mathieu--drif@eviden.com>
To: =?utf-8?B?UGhpbGlwcGUgTWF0aGlldS1EYXVkw6k=?= <philmd@linaro.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
CC: Yi Liu <yi.l.liu@intel.com>, Markus Armbruster <armbru@redhat.com>,
	Eduardo Habkost <eduardo@habkost.net>, Anthony PERARD
	<anthony@xenproject.org>, Gustavo Romero <gustavo.romero@linaro.org>, Jason
 Wang <jasowang@redhat.com>, "qemu-ppc@nongnu.org" <qemu-ppc@nongnu.org>,
	"Michael S. Tsirkin" <mst@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>,
	Alexander Graf <graf@amazon.com>, Richard Henderson
	<richard.henderson@linaro.org>, Stefan Berger <stefanb@linux.vnet.ibm.com>,
	Bernhard Beschow <shentey@gmail.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Gerd Hoffmann <kraxel@redhat.com>,
	=?utf-8?B?RGFuaWVsIFAuIEJlcnJhbmfDqQ==?= <berrange@redhat.com>, "Edgar E.
 Iglesias" <edgar.iglesias@gmail.com>, "xen-devel@lists.xenproject.org"
	<xen-devel@lists.xenproject.org>, Marcel Apfelbaum
	<marcel.apfelbaum@gmail.com>, Alex Williamson <alex.williamson@redhat.com>,
	Paul Durrant <paul@xen.org>, =?utf-8?B?Q8OpZHJpYyBMZSBHb2F0ZXI=?=
	<clg@redhat.com>
Subject: Re: [PATCH 1/9] hw/sysbus: Use sizeof(BusState) in
 main_system_bus_create()
Thread-Topic: [PATCH 1/9] hw/sysbus: Use sizeof(BusState) in
 main_system_bus_create()
Thread-Index: AQHbb1TlTWpZ6ZKzUUKEk8GitOblK7MqKIQA
Date: Mon, 27 Jan 2025 06:21:00 +0000
Message-ID: <60e3f83b-86b4-46ed-83e0-aeece041320d@eviden.com>
References: <20250125181343.59151-1-philmd@linaro.org>
 <20250125181343.59151-2-philmd@linaro.org>
In-Reply-To: <20250125181343.59151-2-philmd@linaro.org>
Accept-Language: en-GB, fr-FR, 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=eviden.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: AM8PR07MB7602:EE_|AS1PR07MB8406:EE_
x-ms-office365-filtering-correlation-id: 92b26b1f-7e4a-404f-510c-08dd3e9ac4ad
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|7416014|376014|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?TEpmUnZBaFU4dHJOcFByRkw1bldwcjh1UEZ5R3NPMWVQZXo0WURBR3JBSlVt?=
 =?utf-8?B?SDdGMWhZcXBnS1pQTWpKV2FVMmNxdlVhdHRjZDhucys2RW41T2d4a3B5R3Ex?=
 =?utf-8?B?L1VpdmhsNloyRzgvb1FnbldMbU1hUzNabU8yT1pwMXFIcks4cWJPY0pQcFdO?=
 =?utf-8?B?Si95N25oRm9OdzJYbklQZlVIaG4zR3BFWGxYTXRKMWVBeDlzKzBBTENpZERM?=
 =?utf-8?B?cUlmeWdPSWNTb2R0MmU2SUJZVGlHeVRHalhBajdrS05IcnByWjNYZWZxSVlZ?=
 =?utf-8?B?QVhyM00xcjhTVFdEdUtNZ0UrVTdqUXhkN3M1a3FrYWxicmtBeFBBeHE2YlZM?=
 =?utf-8?B?cVdwTXRDRCt5cVJDU3BPeC8zYXRvd05vL3VHQVl3UVB6eTVOQnhBSHJtaENV?=
 =?utf-8?B?L2k0ZjUvbGR2V3NUR0NVQUNwMXo2M0hKQnBZSzBaT2NNNnBuMWE4aGRLamc4?=
 =?utf-8?B?MzF4VGdXV0pGMXF0bndQOUx2VEpZWXQrejdZSTl2S0ZGa29lSEQwcUNYVWdi?=
 =?utf-8?B?M3pDeEo0R0dVeFF3OTdWUkd0OTg3bG1nR2dWMFFhdTFBYlhaTGJTQzdPSUhp?=
 =?utf-8?B?THRWRE9hM09VNWNGNEF5akZJdDFMaWY3WFliZ296UEt3RUR5dERBaVNxMFFk?=
 =?utf-8?B?ZERiQXRJVEt6Zm5aUTFoQytsQ1NmYWNUQTFrRWNHWURrTy9KT2VUdWF1bDJU?=
 =?utf-8?B?anNSV3BjMlZDRWYyQU05ODZPZitKZGw1a0l4R044MXY2UVNVN3JEQTFKTGtt?=
 =?utf-8?B?M1g3OTlCbEMxNzluaHZhdTBLeUlYWmNucEFLL3NXaHlpT2pFMDJsMi9hVHlU?=
 =?utf-8?B?Uy9FaElnL0IyQy9MSVErOWdMeWNuWHBoaFBSUWtGMSs1ZmwxQ0lsMnlsV1hZ?=
 =?utf-8?B?RzZLYmFqVmZaVlJ0ZnN6SHorN3VEZTNhVUl2cVo1Sy9kcEdETWpMSjMrOFVE?=
 =?utf-8?B?bTJtdG5BSFNKRWJCR0RyOUtUQUlldFZrNmJPTGgvVmhldEMvbk0xOGlSaXVt?=
 =?utf-8?B?czk5N09yLzZ1a1plRnJ1NWRqM3RtQ1VubHJ0VGRFZzRnTFRYUnlacmx0blAv?=
 =?utf-8?B?c0hQZGVMNnpVYTZsQi91NU1oU3B1SWZBMGdIVCtZL1ZkaWl4QVltU3VMZFFp?=
 =?utf-8?B?ekZWeU4vayt2by80QStvaFhRYlJEQ1pWNzFVUjA5V2VQeXlGSUtLY2tHNVRj?=
 =?utf-8?B?MEYwdTFqVGh2QURkUmFQWllDUjF3TmdiVFJhNUxOZ3RKand2UlZobjFvY3Br?=
 =?utf-8?B?eS9meG5yZmZnWEtJUzhGWTFhNkFQZlJETzBqKzlvY2ZuaWJmZ3RUM2NWUzho?=
 =?utf-8?B?WkRxbTM0WlV6YkNpVGU2c0NSVDlGcUpseS94c2NPb2EvK0dmZlY1cWpkSTJW?=
 =?utf-8?B?Mi9xc2Z4YUl4OUhONWtRUzd5NDNRQmZoSTJQQnNSSWVHamtSRUJOeUtMRXFp?=
 =?utf-8?B?UUxlM3J4MXQ2RmhPR09PQzJuZWtlMDlUQ3ZJdmVJRWR0RzFtL1Y0UVo5R3JJ?=
 =?utf-8?B?bnJJbzcyZVFvZlNPNnI2K05Vai8yY2JkQ21YZW5iM2p4NnE3aTNxd2tBYUJ5?=
 =?utf-8?B?VC9LeU5KRThSajR0cjVKdHk2NGN2TVVpNnBycGhRbXhObjN4LzhSclVob2sw?=
 =?utf-8?B?L1c5azBqTkVkOEZHZnBwYm5Cbkl0dEFXUXZNQUhuQVdMaGFsaHR6UmRGMm9Q?=
 =?utf-8?B?QkJXcXZZTlZOdHdsUDNvMlIvK2wvbUcydktYYXQrc1Mwc1JiTmRlR0RHckxk?=
 =?utf-8?B?eEtMa2FSWGxYeXJmd2gvL0FnN0QrSEJhUnVoaXhUdTkrdUdFL3gyQk54aUhT?=
 =?utf-8?B?VGsxVjN5RXNmY3JaY3FWeW5kdkIwWGJOOXlaMnQ4aW90QXlpUDZ6UGpEcjNy?=
 =?utf-8?B?UlJWMEFPMVJnWGJMb1BFbGJ4TUpmT2pTTmZxQWlMUUcyZGFpVTJ5cWxrS01C?=
 =?utf-8?Q?FqpeKG/L8E4ilct7KxFmkESpkpqAx85I?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM8PR07MB7602.eurprd07.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(7416014)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?dUtuT2QvUnUxS3FRWEh0c29sYXAyc1R3azJsZzlHbUs4c0d1Zm1PeFZsWFY2?=
 =?utf-8?B?NDVIK1pUenZUR1pnVTFRNGZJZThFcXdNZGNWb3RIQjJRdmFOVFU1SVEvVzFs?=
 =?utf-8?B?UXFXeGJNRUlwWWViVlNwUWMxZlhPWFlNdVJRZW9FM1ZyU0kzRmVpaWF3NWJH?=
 =?utf-8?B?aGJVYkxudDFhUHE3V0JNcmhpcFFyRjVKQUxaTFZtYi8wS2FyT0ZGYktNN3N4?=
 =?utf-8?B?OUdhY25tbFNMb3RsbENMK1lKZ2hyU2dMTHlZNzkva0hmT2d1dElyT0NST3RR?=
 =?utf-8?B?S1hySWExZHB5NXpiVG9NaTBEOFo1ZUYrNzJhSzhWcDJaRXdWUHJNRVB3alor?=
 =?utf-8?B?Lys3Zm5ScGJ3ZDJNSThyUktmQytlcGZ5QU5SZjB0czluWWlpbnZhOGtNcHND?=
 =?utf-8?B?cVBLeVJyS3VaZFNpemFmd04yYzMyNG9zRDZEZ1pITlRRSGpJUkttcVZYY1Rm?=
 =?utf-8?B?QTB5dE4xWGpLc3BjQzkyY1VQRitrVzdvMmRyeEx5ZWJ5L3BTSzhzQklRTjhk?=
 =?utf-8?B?ako5SEtVaERDNTVkaWZUZ1E1WDd6YVljWmpZSUJjeGMrY2ZOUFZycUU2QmpX?=
 =?utf-8?B?YmdDRTg2Unp4eEZRRHM0T1FPQlgrWGhRdnhOQWJtVTRZUHp0RnIrbkowWlVF?=
 =?utf-8?B?RW43TnkzUytHWWdSY1lkV1UxbC8wemtCY0Y3YTZveE00MHJJUXNnTVlQaXlJ?=
 =?utf-8?B?YjRtVUV4UkNqSTE4TFYzR2JROHVNUnF1YXI0dWIxZCtuMko5Uk0yczloM29j?=
 =?utf-8?B?a2dKZWxvdVJhQm5oOU00TGxkTW9GbDVQUCtaSEdGWjJwcEJ1UUZkR1V2MEhQ?=
 =?utf-8?B?cldmTUp5VmhGRnN4WkIrRTNOZkhKM2IzVXc3Q0l3b1RSdHd6YlVQSXRsTnVM?=
 =?utf-8?B?T2ZwWndCa1FncDdoRmdBbSs2NGJWcnE0RXRlbkdua1lwenhuRTJXYlU0Z1Fh?=
 =?utf-8?B?aGU2WnplVVpCTDVuR29FQmN4STdKaWpRVnBtS1FtOUlyNFNaWUtTazFPMEZS?=
 =?utf-8?B?UlM2QXdtMUR0WkN0MmF6SUxITllSZVRnUUtUVmdpbGVoQTNPRVJ1Tm1QckI2?=
 =?utf-8?B?bGtXRjV0T3FxaXBwazNTa0RrMmlvUWFLbGFsVi9JWmF5RVkrcWhEZjVDaVJG?=
 =?utf-8?B?YkZPcERpL3R3NzR6WE5BTjFLYTlYZllpV0FOZTFOTGhEZW81OFpCSVZvREZx?=
 =?utf-8?B?UDRzcVRQNGpvVTdiRmtlenFNSGpRdXFsakRCbFMrZDZYZjhRSnRBOUgvaW5V?=
 =?utf-8?B?d2REaHY2Y05HdW96Y2JKRFo0blFLVGN4V29NWlpiMmI0OTBzNllXTE5KdDlF?=
 =?utf-8?B?WXFFK1VBZWxaakhZOTZhOEJLd2NDNlZEVUphbmE3Mk1KTEM0QklIT0lCYlBp?=
 =?utf-8?B?bWZaSDRHZzJoN3VESVJ2LzR6VE5LMWdqaXkxRGVuelFmanRiemRPMWNmYkFz?=
 =?utf-8?B?aDZWQldWWFBlYTVxRTMzVGtRbitDZ24rYjZzY04yWlNUazRnRi9Qc2xpRlBI?=
 =?utf-8?B?dy9oOGF6bVgzVUF1Y25VRFY3djFUaVhJY1QwSERyclY4Zm91REU2bElZbncx?=
 =?utf-8?B?OWFKUW9tOE5lSGpYVXN5QVE2WThvSXFiSHdPWVNsRU0wYXhxMEk2bU1lVHlQ?=
 =?utf-8?B?Q28zMEVPOEc3T1NBYzJRZmNyRHJ4T2xmNHJxaFViSkErclZxWXRId0xuRXhK?=
 =?utf-8?B?WW10TENyckxPWUF6TmJGL2ZXS2cxTm1Lb2NjS0N6Wm5WUXFzcHV2YTRPZWtk?=
 =?utf-8?B?b0VLTnBOeGxuRUJmcG45bHJlamdDK1NDM294clJjcXM2bENqdkhWY3dtZzFw?=
 =?utf-8?B?Zk5GbjlwS2hUUmc0SitWbzVHWDhBa3JJTE1XTUczVkJrV2ZZY3RBZjNJYVU2?=
 =?utf-8?B?amc2c3FjNS9WRFd6Q05WNzBqODc0clhGVjRxMytQSU5HZWtWUmJJdHNZR05Y?=
 =?utf-8?B?WU50eU92VWduWDg2Sy9SWm1UOW4zUUV5dHpWUGFkSUJPbllvZTJpSmJGTlZm?=
 =?utf-8?B?cWlOTUVOUkhna0U2Q1VxbEFCY2p5S2ZncDZaT0hFWTY1c3FrSmpqNGppUXlr?=
 =?utf-8?B?ZmJoZTE5MFFBR3VVNVdiaVZsK05SQmd6ZDBUclU0TVRNeHNVVm1Ba3BGMXM0?=
 =?utf-8?B?Y0xpZEpydlU1OHR1NDFZRXdIb0dTTFIzMThQV3E1YlZNeG9sdFVQc2VTb1FG?=
 =?utf-8?Q?zWSnE2rCifM4fd9zmz/CwPQ=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <EAFB3DFC8B738F45815879BF172F61B2@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: eviden.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM8PR07MB7602.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 92b26b1f-7e4a-404f-510c-08dd3e9ac4ad
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2025 06:21:00.1535
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 7d1c7785-2d8a-437d-b842-1ed5d8fbe00a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: BJwor35OEtu/AdmwS+e4eVeFIbmoPVo+oGFnQq62aCZhotU9XNniuiOdfjdewesnFRCM3wwJpA7jbTh2hyDxaseIZollK3tsMFoBfZ/TmiscU3bmtyCaS7Adl5Kvz6lO
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS1PR07MB8406

UmV2aWV3ZWQtYnk6IENsw6ltZW50IE1hdGhpZXUtLURyaWY8Y2xlbWVudC5tYXRoaWV1LS1kcmlm
QGV2aWRlbi5jb20+DQoNCg0KDQpPbiAyNS8wMS8yMDI1IDE5OjEzLCBQaGlsaXBwZSBNYXRoaWV1
LURhdWTDqSB3cm90ZToNCj4gQ2F1dGlvbjogRXh0ZXJuYWwgZW1haWwuIERvIG5vdCBvcGVuIGF0
dGFjaG1lbnRzIG9yIGNsaWNrIGxpbmtzLCB1bmxlc3MgdGhpcyBlbWFpbCBjb21lcyBmcm9tIGEg
a25vd24gc2VuZGVyIGFuZCB5b3Uga25vdyB0aGUgY29udGVudCBpcyBzYWZlLg0KPg0KPg0KPiBS
YXRoZXIgdGhhbiB1c2luZyB0aGUgb2JzY3VyZSBzeXN0ZW1fYnVzX2luZm8uaW5zdGFuY2Vfc2l6
ZSwNCj4gZGlyZWN0bHkgdXNlIHNpemVvZihCdXNTdGF0ZSkuDQo+DQo+IFNpZ25lZC1vZmYtYnk6
IFBoaWxpcHBlIE1hdGhpZXUtRGF1ZMOpIDxwaGlsbWRAbGluYXJvLm9yZz4NCj4gLS0tDQo+ICAg
aHcvY29yZS9zeXNidXMuYyB8IDQgKystLQ0KPiAgIDEgZmlsZSBjaGFuZ2VkLCAyIGluc2VydGlv
bnMoKyksIDIgZGVsZXRpb25zKC0pDQo+DQo+IGRpZmYgLS1naXQgYS9ody9jb3JlL3N5c2J1cy5j
IGIvaHcvY29yZS9zeXNidXMuYw0KPiBpbmRleCA5MzU1ODQ5ZmYwYS4uZjcxM2JiZmUwNGYgMTAw
NjQ0DQo+IC0tLSBhL2h3L2NvcmUvc3lzYnVzLmMNCj4gKysrIGIvaHcvY29yZS9zeXNidXMuYw0K
PiBAQCAtMzIzLDggKzMyMyw4IEBAIHN0YXRpYyB2b2lkIG1haW5fc3lzdGVtX2J1c19jcmVhdGUo
dm9pZCkNCj4gICAgICAgICogYXNzaWduIG1haW5fc3lzdGVtX2J1cyBiZWZvcmUgcWJ1c19pbml0
KCkNCj4gICAgICAgICogaW4gb3JkZXIgdG8gbWFrZSAiaWYgKGJ1cyAhPSBzeXNidXNfZ2V0X2Rl
ZmF1bHQoKSkiIHdvcmsNCj4gICAgICAgICovDQo+IC0gICAgbWFpbl9zeXN0ZW1fYnVzID0gZ19t
YWxsb2MwKHN5c3RlbV9idXNfaW5mby5pbnN0YW5jZV9zaXplKTsNCj4gLSAgICBxYnVzX2luaXQo
bWFpbl9zeXN0ZW1fYnVzLCBzeXN0ZW1fYnVzX2luZm8uaW5zdGFuY2Vfc2l6ZSwNCj4gKyAgICBt
YWluX3N5c3RlbV9idXMgPSBnX25ldzAoQnVzU3RhdGUsIDEpOw0KPiArICAgIHFidXNfaW5pdCht
YWluX3N5c3RlbV9idXMsIHNpemVvZihCdXNTdGF0ZSksDQo+ICAgICAgICAgICAgICAgICBUWVBF
X1NZU1RFTV9CVVMsIE5VTEwsICJtYWluLXN5c3RlbS1idXMiKTsNCj4gICAgICAgT0JKRUNUKG1h
aW5fc3lzdGVtX2J1cyktPmZyZWUgPSBnX2ZyZWU7DQo+ICAgfQ0KPiAtLQ0KPiAyLjQ3LjENCj4N
Cg==


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 06:21:37 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 06:21:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877451.1287591 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcIV7-0003rf-H0; Mon, 27 Jan 2025 06:21:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877451.1287591; Mon, 27 Jan 2025 06:21:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcIV7-0003rY-Ca; Mon, 27 Jan 2025 06:21:37 +0000
Received: by outflank-mailman (input) for mailman id 877451;
 Mon, 27 Jan 2025 06:21:36 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=50Ot=UT=eviden.com=clement.mathieu--drif@srs-se1.protection.inumbo.net>)
 id 1tcIV6-0003B9-8t
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 06:21:36 +0000
Received: from smarthost1.eviden.com (smarthost1.eviden.com [80.78.11.82])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f4f34483-dc76-11ef-99a4-01e77a169b0f;
 Mon, 27 Jan 2025 07:21:34 +0100 (CET)
Received: from mail-vi1eur05lp2177.outbound.protection.outlook.com (HELO
 EUR05-VI1-obe.outbound.protection.outlook.com) ([104.47.17.177])
 by smarthost1.eviden.com with ESMTP/TLS/TLS_AES_256_GCM_SHA384;
 27 Jan 2025 07:21:33 +0100
Received: from AM8PR07MB7602.eurprd07.prod.outlook.com (2603:10a6:20b:24b::7)
 by AS1PR07MB8406.eurprd07.prod.outlook.com (2603:10a6:20b:4c6::5)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.22; Mon, 27 Jan
 2025 06:21:32 +0000
Received: from AM8PR07MB7602.eurprd07.prod.outlook.com
 ([fe80::fbd7:ca71:b636:6f9d]) by AM8PR07MB7602.eurprd07.prod.outlook.com
 ([fe80::fbd7:ca71:b636:6f9d%7]) with mapi id 15.20.8377.021; Mon, 27 Jan 2025
 06:21:32 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f4f34483-dc76-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=eviden.com; i=@eviden.com; q=dns/txt; s=mail;
  t=1737958895; x=1769494895;
  h=from:to:cc:subject:date:message-id:references:
   in-reply-to:content-id:content-transfer-encoding:
   mime-version;
  bh=A7aLgo+KE8CQRIFVKSD9yEnA6yy4B1DvAinfKaDQJGI=;
  b=tsM5qzVqOS5zVLKx1Xm6qRI830Q+wx7OistDFgp3mulrZ8HLXwNJ9y7W
   Xa8gXbe/6bDneMVbynO+8K6BbCVYjVQgTqIicc9IU/hbJoMYA3Z4ykaPs
   zC6Y7fAVIOhTcKCMSMykdJz3jR7RTLHPgIyEGsA8+fMun4CMZHlpVf4rb
   IgV1G1mPZ2ng00wzCj6suw/9DXBvZEmbVhFCmwkgiQi4iVM6v3eBX5k0K
   dAk3gYr7Yvz0VTUZpFuNpKZwZAXo8uLQfAG1K/8dFKi1kOGQvwuFzp+ol
   gQJUi+7RQN4TJPDDmxpwihhCDiqhzkpOTx+HQlI7OHT6inyJzxN/8fzq/
   g==;
X-CSE-ConnectionGUID: y/oOPrwXS2ix9Psz91TS8Q==
X-CSE-MsgGUID: fOwsJOJLRxW1pwS7kcSA+g==
X-IronPort-AV: E=Sophos;i="6.13,237,1732575600"; 
   d="scan'208";a="29567536"
X-MGA-submission: =?us-ascii?q?MDH0KEkmVaHLj+RZVEAn9maRKIMZyQj1GVP4Qp?=
 =?us-ascii?q?rMNxwbfSYJZzrsJjItgVpdykDPs/w5AktptIBFLeIjDwNnyver7CCr3t?=
 =?us-ascii?q?ujuG8RC2X6hwtdUUSy60FuoXE2m6BDKBEosWZZ3NgMdqiNha+t/kck7X?=
 =?us-ascii?q?RmrVs+vRM1BWDEeHrtTosQdw=3D=3D?=
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=FcjwogtPR4nB0hiy2MScdZemD4Cs1toui/ieQJgvmWPcfJm851DhVRmchiHyrWdrhB6jBfjZbTMc7R1xii+yELoyV3HA+CVPYV2PfteGWQR1BpDGDI2trsWe9D4ThRJqNAgvxI5ItkJLvZkC0IJgYm3DYGSPaPwqYBR7hfOnCoEjjqHxYkp2HZg5b5MHyPYEsxXXrK3zWO9krpRHwF2oMSUwchRYl0xRLxH9ZwOetNkDVQZOAZv/gEruZegBdGi696+a75B+RwGU2lmQaN1gCy4WpGMNjk+GoVkQM/rjEmFB8WGgbU6J5Fkp1TX1AJPRNDO5lvtKN/KSjUGaw3uViA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=A7aLgo+KE8CQRIFVKSD9yEnA6yy4B1DvAinfKaDQJGI=;
 b=AaQsdC/Arrw3i/YbJoGAblsUTFGz1DNP8R3S8n2ZqREnrewkxBIHmppNPysXF2oyRnUkzTrW4SKBRChuLQUupGouRPjkjGSyyIWQ4OO7YiY8Ojy5iq950RR2dJSCnyWRvANlEn1jNZuc2hNNhlWsUgz97aGG5H1C8mr/JF2djcoLqWwn2s6LaRwx02TSb6QrAqac3L3lD1bL+KI/YDMCLywCP/Oi+6EXSJnn8EdTR11o8niKBU5NI6U3KItdDp/dHH7170g9OfGGuvT7go9HIn4N4rqYuuGvSpCe2KcDoCRKaj/99GoaOtoeoyEKFPuD3EPcO7gxsrpEgaDXjxzdIQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=eviden.com; dmarc=pass action=none header.from=eviden.com;
 dkim=pass header.d=eviden.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Eviden.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=A7aLgo+KE8CQRIFVKSD9yEnA6yy4B1DvAinfKaDQJGI=;
 b=brMjJoeQKQMvnZGUDTK0Ko4twa9CYCfhRWfVFMpkIaEQpIjnYQYYG8QX6uOSjAkzineH6JyTV+glEDw7af9eUXenWqYbdfMGu/MdW4u8KUeqbEcv6cXJ+fbeV/F14hj5DQqR/xabt6UE11YFbEXSTeBSdGZaiVK8HwrG++le/05iy7YlTF/jQ49y9WxuNz1EEv6TzCQyWMQlvZmtsSxDgmk8Q7w6FtBHEX9GbZZISCnuwxOwmR/VjtTbtFSgf9wDjNEAZoBdalc20J5lgj4D9xoZUZq/+sG1mB97dZU02jEgJm0gQZmpO1y0m49RCqD9UXu94eR/o2qNQYSIOD853A==
From: CLEMENT MATHIEU--DRIF <clement.mathieu--drif@eviden.com>
To: =?utf-8?B?UGhpbGlwcGUgTWF0aGlldS1EYXVkw6k=?= <philmd@linaro.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
CC: Yi Liu <yi.l.liu@intel.com>, Markus Armbruster <armbru@redhat.com>,
	Eduardo Habkost <eduardo@habkost.net>, Anthony PERARD
	<anthony@xenproject.org>, Gustavo Romero <gustavo.romero@linaro.org>, Jason
 Wang <jasowang@redhat.com>, "qemu-ppc@nongnu.org" <qemu-ppc@nongnu.org>,
	"Michael S. Tsirkin" <mst@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>,
	Alexander Graf <graf@amazon.com>, Richard Henderson
	<richard.henderson@linaro.org>, Stefan Berger <stefanb@linux.vnet.ibm.com>,
	Bernhard Beschow <shentey@gmail.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Gerd Hoffmann <kraxel@redhat.com>,
	=?utf-8?B?RGFuaWVsIFAuIEJlcnJhbmfDqQ==?= <berrange@redhat.com>, "Edgar E.
 Iglesias" <edgar.iglesias@gmail.com>, "xen-devel@lists.xenproject.org"
	<xen-devel@lists.xenproject.org>, Marcel Apfelbaum
	<marcel.apfelbaum@gmail.com>, Alex Williamson <alex.williamson@redhat.com>,
	Paul Durrant <paul@xen.org>, =?utf-8?B?Q8OpZHJpYyBMZSBHb2F0ZXI=?=
	<clg@redhat.com>
Subject: Re: [PATCH 7/9] hw/net: Have eTSEC device inherit from
 DYNAMIC_SYS_BUS_DEVICE
Thread-Topic: [PATCH 7/9] hw/net: Have eTSEC device inherit from
 DYNAMIC_SYS_BUS_DEVICE
Thread-Index: AQHbb1T6QlQEzX4gqEaQ2yn6FyHdDbMqKKoA
Date: Mon, 27 Jan 2025 06:21:32 +0000
Message-ID: <27e3a3fa-701f-4852-baf7-7237faa57df5@eviden.com>
References: <20250125181343.59151-1-philmd@linaro.org>
 <20250125181343.59151-8-philmd@linaro.org>
In-Reply-To: <20250125181343.59151-8-philmd@linaro.org>
Accept-Language: en-GB, fr-FR, 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=eviden.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: AM8PR07MB7602:EE_|AS1PR07MB8406:EE_
x-ms-office365-filtering-correlation-id: 7650f0e2-ed63-4a09-b8b0-08dd3e9ad7af
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|7416014|376014|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?dzlSNS8ra2hnbXhKdDgrbnZaWTBsc1VORUVCclBkSWFLL1lpVDhxY3RDNGox?=
 =?utf-8?B?YjJyWDRaVTBXZlFSOGdqMVpwdlFJcjhjQU5FQThyenl0Z01rM0xxL2srRDk2?=
 =?utf-8?B?SUlxT2UzRURWdkFFa2Fmb1pjNGJrcyt4dWhHMXk4VHQ3K3RaSGZ4dkFtMk9F?=
 =?utf-8?B?Njk1aGo0bmNKYjJNZzM3US82ZWxLVVlESVo4bVE2d1VzZmJjeFJDOWYrSEln?=
 =?utf-8?B?QTE2OTRqdENuZDUrZ3ZPajZSK2xyczVJZ2Fyd1d6TlFVdDlVZ3BoU1c1WFlC?=
 =?utf-8?B?YmwyN0NOMFMvYlYra3hjSUlOaXNybE1FUi90MlFyZFBYdW1wYnpENlkzTG1P?=
 =?utf-8?B?a2NkcmRSRkE3bmQ4ZUJUZDB0b1E1NFFSa25MQnFZM1lOU0VFZHg0U1crVUxz?=
 =?utf-8?B?dzY0UzhldTdRQXNRMkJqdERRU3RoamF2ak1HcTZmNWNMZUlzWjRWSURTbllk?=
 =?utf-8?B?MFEvWmNXQnA2T21KaEhSdGRaZG9iUmtOK0cwS3A1SGwzdkNRL0VOYitzMEN3?=
 =?utf-8?B?V0pZekVlYUVkeG4xbEZ3N05jSE1uS2x1NkFReVJpY1pwL0FGRmQ5bjVHdXha?=
 =?utf-8?B?QkJNdEEvZUVnRCtoSEdXNjNsNEthMjBja1VrTlNuZlROQlVQbXFVSDBDUUhr?=
 =?utf-8?B?cXVXNjkzSlBjRzQ4Vlo5VDZhZVEvRlIreUJCUTdqdmVvZjUrWitCOXpxRng1?=
 =?utf-8?B?T09xMk9SczVERElqcmovUUxKRkIzZklVcmFCcEt4UFN1ZzB5RUZ0Z2Rkc0Fx?=
 =?utf-8?B?SmhVT3EyOWsrcWVadXZBK2xIK0UzQkdLTWwzUUE3MHpoZ29nb1hjSEJDVTM0?=
 =?utf-8?B?QWJFd2oxcVo1UjFibS9mcStaTFZIR1ZIZFVZMFRWY2RHd3NhTmhMcG5FRllB?=
 =?utf-8?B?MlhaVlhLUGVHTHQ5RHFlUlhQeFdLdVRmUU9oMllsemhvWDRZREFWOEhvYVJ3?=
 =?utf-8?B?MC9VZC9vaytCMGlRZ1pNZC9uRGdSS1VLZkhzdUtXYnJMUFlTYy9ZMnoySlND?=
 =?utf-8?B?cy9WeHROWG9hVTkzdTVzOXNUaTRsU3JoRlV0c2VQU0F3czYxVHVlS1BkejJh?=
 =?utf-8?B?NER1Mkp3VnV3QnZQM3Y3R3NvdkhQVkRvSWJRZnJIL1Z0WDl0K0djNlV5dzND?=
 =?utf-8?B?NmF4ajBoeExFNGF0bHhLTG1OWkRqWGV6eFNFYWFrcHRxZkRHVGRFd2lkOTVs?=
 =?utf-8?B?U3F4dXVTT3h3aXRZcThhSW0vbS9PUVZhY0RMU0hZdklxNytmMEdMM2tOMWN6?=
 =?utf-8?B?VHJNRm91QTJTTHlsVitoRTRYcW1oeTJqRDhxQ2hZUVcrRGxIWklCOUM0QndG?=
 =?utf-8?B?YTgyelhqeG02SFdHZjB1TmZLWEdaVjlXUXI2TTFURVFueC9BUXpzajF4MXFF?=
 =?utf-8?B?MHBTcW00b3ZqNHlBUytjbjc3UHpzWXhyNFhzdkdmbk54STFIdDRwT0R6VkNO?=
 =?utf-8?B?RWwyOHVGaEl2dktRSXAwOGZMckFKNHZ1MVkwcmRYK1FldldsWkZaa2J0c2tR?=
 =?utf-8?B?eGhBUi9IdFFIN01IU2F6MithUzFGZzRNTzBQcHZBeks3d29FK1ZyREJhaHEy?=
 =?utf-8?B?SnpvZ01EaW5sOGRyZTh6SDFVcC8zcjJiNHk5Y3ZIRVhuMlNPZEZwcGVyZmIw?=
 =?utf-8?B?QWdQLy9xN2tpT05HVnI5U1ViQkQyYVd4LzlDY0lsandBSnZMSy9LaEhaM1du?=
 =?utf-8?B?ZXZNei9tajBHZzlIbnRHbktNTm9IZ3FxaytEOHN0Vzh1S3V4d0lwTk1Cc08z?=
 =?utf-8?B?QXc3NkdlczBZT1VsN2dmcGR5dXJoWXgrVnNObWdlWVNpM2VuL1ZBQnpjWkRi?=
 =?utf-8?B?OHNQdjk4S2Jmc0hDaS9IU09BRGZlK1lHdFBoY0NwOVVtMGxZa0tEY0Nub2sy?=
 =?utf-8?B?eUtiZktubUVRRnJRSlNaUzVESjdGRXVkMXI4Q1RFNExGZTVsSkk4VnVCSmJM?=
 =?utf-8?Q?k0PPuNIFnNFRsnLID4VZcHoyzOuKkG3d?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM8PR07MB7602.eurprd07.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(7416014)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?L1VQZU44b00yY2hIM1pDR2VFUURPaEl6RVVlV2NBY1o2dXNLSGQvS2pITUxR?=
 =?utf-8?B?cTV4UzlraDhxczg0Ny9VMG56VnA5Z2VKMXZSMENQR0luaVdHZkFjdUd3MnVL?=
 =?utf-8?B?RHF3L3BtR1F4ZUxjTU1tYXdLQTRJNzJYbUtLR29HOTRybVRUZEJhYjY0TzEy?=
 =?utf-8?B?Rk9wdHhuM3V6Tk55L3pSM0lNMk5IT0JraGtreTUySFkzazNYbVRHZXBkUExS?=
 =?utf-8?B?QXlOZi9UUjg2TG5oOXZ6K1Vvb2w4dDVkV1liZ21RWE1xMnNycmNUSjF0NFJT?=
 =?utf-8?B?MjlUMlJiTU56RzBqT0FiUFh1OGpxNDNYbk1uYmdWTjQ4UlhKeVVNSG1uWC9Z?=
 =?utf-8?B?TUoySDY1T2dMTmF5bzBlSWErVDR1REM3cFY3OHFETmlPMVNJNTEzVTVuRHZi?=
 =?utf-8?B?U1ovV1c5VWhwQkQzTkcrb01oOXEzUFB2ZEMzREJwUE9PWTcxWHU4cmFnK3BI?=
 =?utf-8?B?aHpuaWhGc2dEQlI3M04zeWVJYnRqekVKamRMMmJtMi9LYVNQdnFuMDFVY2RL?=
 =?utf-8?B?U1duTjl1SVlzTjZqcS85UkNBbzhZZERPTHI3enJmTHN2OVhDekROSXA1L2s1?=
 =?utf-8?B?YTMzUkd3YVFGTEhxYlNGSE50dGNpaDlkanovcS9NUURrSlhBU2lrNk5UcGcx?=
 =?utf-8?B?dldSZ3B5Z1FKWVpPQ1ovR3c2a2JWeHpDZmNFM3NWNE92QzNnSmFUSzlVS1dE?=
 =?utf-8?B?OC92WHRkTE5vMTRYU1dzRW1ZNHdleEIyaVJxYlZJUFQ5WkY3dUVJMktnRFhP?=
 =?utf-8?B?YXhyOGFOTzYrc1FhNHBvaHE2aklTTGxUTHlhQ0E0bFUwdnZNRHVJaE13d2lQ?=
 =?utf-8?B?bHl5dHBUQnErbjRQclFhZDhvNmtOYzR0ZkJJUUp3WmdxZFg3RmYya3lQSjNu?=
 =?utf-8?B?SWE2TTVqTllvNmMrdWhHd0NIRHFXV3l4NHN3ZHdUV1VmTGZLbUxwT1lBenZh?=
 =?utf-8?B?TGtxNC9tWFpDSkFXTk9pMDJzNTB4U2ZidENQMnkyOExqdHUvempLZkFVLytG?=
 =?utf-8?B?Y1UxeThUcEc5cHdsemlvMjQ1b1dKUVEzREVOcHJ5OHF4Q3lmb2tMbXV0dlRG?=
 =?utf-8?B?Wkw0dGwzZFRIdmVwUkNNamhoVmxUTUh3SVJNNGRGdVFkTWhjQkRLaUNSMXpI?=
 =?utf-8?B?cHpOeThzRjhxTDFSektyZ0FMVkNWSFBUVDF1N1dGUmI1SnZTMlpmSklGQ3Bl?=
 =?utf-8?B?M2FMbjBLTFYydlQ5U2dWNlpxN2NXcjY1SzZ6NzIrUW1TMW1RaEtiWHNqbEhs?=
 =?utf-8?B?S0lVWTRJaUdBaWlQajJ1d1BOdmVZb3huVm1XMWpvbytNdkp3bWtHUERWcG9M?=
 =?utf-8?B?OTc3SExLSWJ5TGpER05tbTMyRVRIbThMaDdiVHRjcGZZZUh6ZWhrZlQyS09a?=
 =?utf-8?B?RTltc0pBZm5pSHdWaEFHSVIzQnJnekJzUGpsYTVyWGRBQmUrVHFlczdDT2tT?=
 =?utf-8?B?N0pVQnN2VisybzArUmk5ekxXcExTQUw1elNHNURyTVBsRlFjMzZDZ2w5NWlz?=
 =?utf-8?B?Q2hUQXpvMTFicWlRLzBUU1V3TytLcUdjcjhWeXl0OUxOK3pQQVY4cHB5R2hY?=
 =?utf-8?B?WGtXaE9sbThidDJodmUxNHJGVy9HVitHQTRucHNJeENNdEdKc01GZDZ3QTMy?=
 =?utf-8?B?WmZ6Z25EWW5RMk5LQ1B5a2VoOUlrNkYyZWVyRVFTWWZMWlhoSDYrN3l3dVVi?=
 =?utf-8?B?QytkZUFOWlVycUMvdldFVDRwVkt4VHRldDdLRmVjSStGMGRZN0ZkdGdYenBB?=
 =?utf-8?B?SnpHYU9zMmZHdHNOWmtUcStnaXVabSsxYVlTL2liRWtUTVRiNi9zVExQbnUz?=
 =?utf-8?B?S0U1TEFscWROV203dE5CK2dTZ0FPWTVnN3NiTlNLbU82ZjFlakRUL1Urd3JH?=
 =?utf-8?B?Y2lkWlY3YVptTStqejQwMnVHZzk3VURTa2NtVkxRRFRoU1U2R3BmTGdWSElW?=
 =?utf-8?B?bXZJd1JqTHh3cWxJcDVid0pJZEdTQ2IyaE1xeDBsQ0o5UnFOK21IYkU5SVJM?=
 =?utf-8?B?cEtteW15ZCswTmQzNkhpajNlUUxyZzNMUlI1akJZVnFoYzZaeEZQaG5TUEtw?=
 =?utf-8?B?YWwrZFBrRlFhTlhSS3k1SVRTSktFd3hXTTFMYWk3a2tLNkY5aXN3akhxTUlQ?=
 =?utf-8?B?OWh4WDRyd1pKckVWWlArVzlhcDFxTThtVnlIZGc3bWVFVnVIZ2FWYXRHcjMr?=
 =?utf-8?Q?OGOVTIuSNGg8skwQgjM3OYg=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <B9466E39CA70CF4E84280FEAF6D94478@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: eviden.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM8PR07MB7602.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7650f0e2-ed63-4a09-b8b0-08dd3e9ad7af
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2025 06:21:32.0894
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 7d1c7785-2d8a-437d-b842-1ed5d8fbe00a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: vvtiiNwG5Y419TPTsWhUd3NiJylNuS3FRd/6ZGjWaNOElU0FrRiMsWa7ex5oEhDZcvN/b3ZHUdau8Cx7zfLMTXOs/34lwtLARJhaz9kp0hGYqhLcQdMFhJDqPcGyLj/W
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS1PR07MB8406

UmV2aWV3ZWQtYnk6IENsw6ltZW50IE1hdGhpZXUtLURyaWY8Y2xlbWVudC5tYXRoaWV1LS1kcmlm
QGV2aWRlbi5jb20+DQoNCg0KDQpPbiAyNS8wMS8yMDI1IDE5OjEzLCBQaGlsaXBwZSBNYXRoaWV1
LURhdWTDqSB3cm90ZToNCj4gQ2F1dGlvbjogRXh0ZXJuYWwgZW1haWwuIERvIG5vdCBvcGVuIGF0
dGFjaG1lbnRzIG9yIGNsaWNrIGxpbmtzLCB1bmxlc3MgdGhpcyBlbWFpbCBjb21lcyBmcm9tIGEg
a25vd24gc2VuZGVyIGFuZCB5b3Uga25vdyB0aGUgY29udGVudCBpcyBzYWZlLg0KPg0KPg0KPiBC
ZWNhdXNlIHRoZSBuZXR3b3JrIGVUU0VDIGRldmljZSBjYW4gYmUgb3B0aW9uYWxseSBwbHVnZ2Vk
IG9uIHRoZQ0KPiBUWVBFX1BMQVRGT1JNX0JVU19ERVZJQ0UsIGhhdmUgaXQgaW5oZXJpdCBUWVBF
X0RZTkFNSUNfU1lTX0JVU19ERVZJQ0UuDQo+DQo+IFNpZ25lZC1vZmYtYnk6IFBoaWxpcHBlIE1h
dGhpZXUtRGF1ZMOpIDxwaGlsbWRAbGluYXJvLm9yZz4NCj4gLS0tDQo+ICAgaHcvbmV0L2ZzbF9l
dHNlYy9ldHNlYy5jIHwgNCArLS0tDQo+ICAgMSBmaWxlIGNoYW5nZWQsIDEgaW5zZXJ0aW9uKCsp
LCAzIGRlbGV0aW9ucygtKQ0KPg0KPiBkaWZmIC0tZ2l0IGEvaHcvbmV0L2ZzbF9ldHNlYy9ldHNl
Yy5jIGIvaHcvbmV0L2ZzbF9ldHNlYy9ldHNlYy5jDQo+IGluZGV4IDc4MWI5MDAzOTU0Li4zY2U0
ZmEyNjYyZCAxMDA2NDQNCj4gLS0tIGEvaHcvbmV0L2ZzbF9ldHNlYy9ldHNlYy5jDQo+ICsrKyBi
L2h3L25ldC9mc2xfZXRzZWMvZXRzZWMuYw0KPiBAQCAtNDI1LDE0ICs0MjUsMTIgQEAgc3RhdGlj
IHZvaWQgZXRzZWNfY2xhc3NfaW5pdChPYmplY3RDbGFzcyAqa2xhc3MsIHZvaWQgKmRhdGEpDQo+
ICAgICAgIGRjLT5yZWFsaXplID0gZXRzZWNfcmVhbGl6ZTsNCj4gICAgICAgZGV2aWNlX2NsYXNz
X3NldF9sZWdhY3lfcmVzZXQoZGMsIGV0c2VjX3Jlc2V0KTsNCj4gICAgICAgZGV2aWNlX2NsYXNz
X3NldF9wcm9wcyhkYywgZXRzZWNfcHJvcGVydGllcyk7DQo+IC0gICAgLyogU3VwcG9ydGVkIGJ5
IHBwY2U1MDAgbWFjaGluZSAqLw0KPiAtICAgIGRjLT51c2VyX2NyZWF0YWJsZSA9IHRydWU7DQo+
ICAgfQ0KPg0KPiAgIHN0YXRpYyBjb25zdCBUeXBlSW5mbyBldHNlY190eXBlc1tdID0gew0KPiAg
ICAgICB7DQo+ICAgICAgICAgICAubmFtZSAgICAgICAgICA9IFRZUEVfRVRTRUNfQ09NTU9OLA0K
PiAtICAgICAgICAucGFyZW50ICAgICAgICA9IFRZUEVfU1lTX0JVU19ERVZJQ0UsDQo+ICsgICAg
ICAgIC5wYXJlbnQgICAgICAgID0gVFlQRV9EWU5BTUlDX1NZU19CVVNfREVWSUNFLA0KPiAgICAg
ICAgICAgLmluc3RhbmNlX3NpemUgPSBzaXplb2YoZVRTRUMpLA0KPiAgICAgICAgICAgLmNsYXNz
X2luaXQgICAgPSBldHNlY19jbGFzc19pbml0LA0KPiAgICAgICAgICAgLmluc3RhbmNlX2luaXQg
PSBldHNlY19pbnN0YW5jZV9pbml0LA0KPiAtLQ0KPiAyLjQ3LjENCj4NCg==


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 06:27:00 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 06:27:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877463.1287599 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcIaH-0004hs-1d; Mon, 27 Jan 2025 06:26:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877463.1287599; Mon, 27 Jan 2025 06:26:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcIaG-0004hl-Uz; Mon, 27 Jan 2025 06:26:56 +0000
Received: by outflank-mailman (input) for mailman id 877463;
 Mon, 27 Jan 2025 06:26:55 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=50Ot=UT=eviden.com=clement.mathieu--drif@srs-se1.protection.inumbo.net>)
 id 1tcIaF-0004hd-G3
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 06:26:55 +0000
Received: from smarthost2.eviden.com (smarthost2.eviden.com [80.78.11.83])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b2ec732b-dc77-11ef-99a4-01e77a169b0f;
 Mon, 27 Jan 2025 07:26:53 +0100 (CET)
Received: from mail-westeuropeazlp17010003.outbound.protection.outlook.com
 (HELO AM0PR83CU005.outbound.protection.outlook.com) ([40.93.65.3])
 by smarthost2.eviden.com with ESMTP/TLS/TLS_AES_256_GCM_SHA384;
 27 Jan 2025 07:26:52 +0100
Received: from AM8PR07MB7602.eurprd07.prod.outlook.com (2603:10a6:20b:24b::7)
 by VI1PR07MB9531.eurprd07.prod.outlook.com (2603:10a6:800:1c9::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.22; Mon, 27 Jan
 2025 06:26:45 +0000
Received: from AM8PR07MB7602.eurprd07.prod.outlook.com
 ([fe80::fbd7:ca71:b636:6f9d]) by AM8PR07MB7602.eurprd07.prod.outlook.com
 ([fe80::fbd7:ca71:b636:6f9d%7]) with mapi id 15.20.8377.021; Mon, 27 Jan 2025
 06:26:45 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b2ec732b-dc77-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=eviden.com; i=@eviden.com; q=dns/txt; s=mail;
  t=1737959213; x=1769495213;
  h=from:to:cc:subject:date:message-id:references:
   in-reply-to:content-id:content-transfer-encoding:
   mime-version;
  bh=TuFDbrtAziZN9o0EFxR7KDVfNYFwC3Cyvmq9l7FEOXU=;
  b=SZd4wwlEmCC8L4XgVlju9n88FewRxhxOnh/GLTh3hllSd06y0pWylRoj
   lFN83ShXftdkBDsVq1z5PMdUfW6Lw6AjJYExKZyWg0OYC/eZmIRgGgYBF
   oYaAvCqXnLwK09SbDhTsMJl9qvQ0eBs0Cc7bAqSKU+jAm8F4AlAMEHDcy
   5a/HMwQmxgPLqnMiA/Y/1WcH/GCCyzs4VzR6GpXuvzU4K9XYRcbNBARXc
   ipoTUS0YkLzLo5sEXoJIeEA8BfqAiMtLSS7ciPzERUMCSr+fFhYYXkIg0
   0rGnUrRxHdX1iQwJVcj18tVNi3TZB6MbeTRzdM+gYhzZe9ioRZsKMt64T
   g==;
X-CSE-ConnectionGUID: vgeN1/2VRnOyOOkA3YNW1g==
X-CSE-MsgGUID: 86WSesZ6SNuNiCrB+F1OeA==
X-IronPort-AV: E=Sophos;i="6.13,237,1732575600"; 
   d="scan'208";a="29555522"
X-MGA-submission: =?us-ascii?q?MDHbozXGOCnZ11UkrpyYq42roL+9DgQOsdhcXb?=
 =?us-ascii?q?miR8EIYIi/BbYN2uy1AB1RR0V92OiqP4jELfNMHcsEUbwK1PH7U0kdtw?=
 =?us-ascii?q?fl+z29xSAowYSbu2Ha3rdTiaDflet6udjOBylfPZfzngjSTQ13Z8GtzG?=
 =?us-ascii?q?e6SAGIwqFeS6zM1GYMx/26Fg=3D=3D?=
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=PYUv2LCbqNhChqmt0X12HSA2B27Q+S22v6wu+mdLPu2Xe6FV8O04WzUZgyGTVlPwDw7l9II/PTF3e3g9Vr1AbJk/KCoqaqgJBe9nueGKODBfLPisf6ZO+/gEJno0lchvjEFapt6iIaVxOUG3ufN6QuCN6AEXO0rpJUZ9BV0cAl1rbC4jV84OOhHGOTxCWqWYFB3mxIQ+MFTGU4xIDQnNBuNFUOnCtuNg8Um+TpZntMqs4BDeRfUxBT9/zcZNel2n/3XVki/q6o3qX6IEJSR5xDRVhAN6ttwsVD8/ONRFybPtzTac1XmsMtsTHsWBB0xF4wyHI0B9WR9I2OpSdcGRkQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=TuFDbrtAziZN9o0EFxR7KDVfNYFwC3Cyvmq9l7FEOXU=;
 b=c0aIgnbhCOHSPxiL7y2SN54AvWk81m00SfMZnQqg9yc9uy7TRFmtn7ylzRYQLuBPAbnvAV97b7Po0hJ6vZwgf7z/z3gS32ZNDO4OQ+vW0Cik2hSgrwdhvBrTJezGx7XxHcAAhfuh/MKDjfZuOdE5SxsNh1opiSGCuWwvY9/Y6mkb5QvFmq1C0uXT0fOsjL/+uoxVoKbGD6gdJ2TOgRapMqRU4d1J/VCnUSFit7Pvs7dDkqwFVjmo43VRInZF2u5tHv5jvc4KyOq6Qh5XQO0FuMwv/2eUye3N0TFnGiCbdePMRmVeedMkR4Z3DNnYSDh5YmqlYzr13w00pjN6uF+4DQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=eviden.com; dmarc=pass action=none header.from=eviden.com;
 dkim=pass header.d=eviden.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Eviden.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=TuFDbrtAziZN9o0EFxR7KDVfNYFwC3Cyvmq9l7FEOXU=;
 b=YbXwtUXvlxrCgGP+5p2/8v6neMQhl+sA/GXX/EVy86ah3ZKT1kE4Td4/NvPgZMyhDf0fTlMNC//U/yb3C5iA6IB/g8jxjFRedpuvzOLsC2rmDm7QZaqJKtY+gzABejg42TRBp01izfkTgL6WG4A8rm7Et7j3ETjejJJktU436KSV258SKATOv3fQyFKvh9vTkGMg9hAXzooKlhibObikfIhSDBHfgqXldpLmseX9KhxRT+r64gDRj/rS7nbdfN28fKn4c0PFxeMHynN1siKDX99AgUiAv4ichmGjLO27hOS4RP4iKHQzV4xHhX9nGrqdRNaDdizIdSMGm+7yGRG7nw==
From: CLEMENT MATHIEU--DRIF <clement.mathieu--drif@eviden.com>
To: =?utf-8?B?UGhpbGlwcGUgTWF0aGlldS1EYXVkw6k=?= <philmd@linaro.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
CC: Yi Liu <yi.l.liu@intel.com>, Markus Armbruster <armbru@redhat.com>,
	Eduardo Habkost <eduardo@habkost.net>, Anthony PERARD
	<anthony@xenproject.org>, Gustavo Romero <gustavo.romero@linaro.org>, Jason
 Wang <jasowang@redhat.com>, "qemu-ppc@nongnu.org" <qemu-ppc@nongnu.org>,
	"Michael S. Tsirkin" <mst@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>,
	Alexander Graf <graf@amazon.com>, Richard Henderson
	<richard.henderson@linaro.org>, Stefan Berger <stefanb@linux.vnet.ibm.com>,
	Bernhard Beschow <shentey@gmail.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Gerd Hoffmann <kraxel@redhat.com>,
	=?utf-8?B?RGFuaWVsIFAuIEJlcnJhbmfDqQ==?= <berrange@redhat.com>, "Edgar E.
 Iglesias" <edgar.iglesias@gmail.com>, "xen-devel@lists.xenproject.org"
	<xen-devel@lists.xenproject.org>, Marcel Apfelbaum
	<marcel.apfelbaum@gmail.com>, Alex Williamson <alex.williamson@redhat.com>,
	Paul Durrant <paul@xen.org>, =?utf-8?B?Q8OpZHJpYyBMZSBHb2F0ZXI=?=
	<clg@redhat.com>
Subject: Re: [PATCH 2/9] hw/sysbus: Declare QOM types using DEFINE_TYPES()
 macro
Thread-Topic: [PATCH 2/9] hw/sysbus: Declare QOM types using DEFINE_TYPES()
 macro
Thread-Index: AQHbb1TnAXNqrKSmEEKYIVzklwv71bMqKiEA
Date: Mon, 27 Jan 2025 06:26:45 +0000
Message-ID: <1a8ceb53-706e-49be-9f44-4b73a29613d0@eviden.com>
References: <20250125181343.59151-1-philmd@linaro.org>
 <20250125181343.59151-3-philmd@linaro.org>
In-Reply-To: <20250125181343.59151-3-philmd@linaro.org>
Accept-Language: en-GB, fr-FR, 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=eviden.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: AM8PR07MB7602:EE_|VI1PR07MB9531:EE_
x-ms-office365-filtering-correlation-id: 8adb2fe5-94cf-4d6f-9e81-08dd3e9b927c
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|366016|7416014|376014|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?aEhpK2ZjTnlxNWlsRVp6bk15OXc2RTNQeE92R08zU0FhZHlzNlNWS3FQaFla?=
 =?utf-8?B?RENUbHhVU05uYUQ0blhhREQzeEdxQjBiNG5jbDNUSzArRWsveW15dE8ydWly?=
 =?utf-8?B?eFdsRDhkMmpSR3Z0aHZzbVNVRytvK1NRejkxOE8xNWQycFp5RDc1L1NxYkpr?=
 =?utf-8?B?NVlzQlNXbXArbmRyOHJVbU9GeWdGK1lCa0xFckpDaVRBTjVCcFh4SnowdW8x?=
 =?utf-8?B?WjJlVHdXSTRQOVZHRFRRWEU3UTdoRjdtUExiakkrN2FzWVNWT200c0NYV0pD?=
 =?utf-8?B?aCtlSy9pYmxpa005V3V1djNQQk1EYUNjYU9YS1d0RU9VaXFZSGdQT25rZGZ5?=
 =?utf-8?B?dTN5RXZ3MmIvZXpacEI5MGc0b0toOUJwWkFhdVpwbU0vdCtjVnNvZGc4RGhU?=
 =?utf-8?B?VU9MdnVOYW01a0diWW5RL24zS05Hcnc4TEtPWEtaTHU0Z0RCcXpjZFdDNjdG?=
 =?utf-8?B?TFFOTTl5aWZ2Z09CRThnS29uYjJDVlZxdlB1bTYxSlIySHozY293dFkyZnUz?=
 =?utf-8?B?N2FCM3AwSkxrYXlvNTdDZEoxRnh5R0FlMDlBRVdWdmhpVVFDNXZDQVp3OW11?=
 =?utf-8?B?ejNsY0ZlZjNrcUhvWDVQam5HRkJiekd0K29XS20wZDhaaUJwMFlaZFQ5T0NZ?=
 =?utf-8?B?aWd1OGJyWEtUZm1ZM2NYWFA1cDdlekZacXR2SFpNK1FVSTdodWlSQ0p5WSs5?=
 =?utf-8?B?eFYzZmZXa2tqUGh1TG5kK2pyc3hWRkhNdUxUU2xwakMwMytEL0VDZDhuRElv?=
 =?utf-8?B?akppUDM2RTE0MExWUFpOeTVTZTduRDhtYlpBcTR0eDM0TGdZOHprQ2NCc2o0?=
 =?utf-8?B?V0RNbHovZzhTZFRYQ0JGWGxrWWhMS3djK2hzSEwxUERrVXRPQzdRbFBvZll1?=
 =?utf-8?B?UHdGQjFZOVo0WmpOcDYzQU56VE5OQ05yN3duRTltRVZSMmp2amxHakc5cjZ3?=
 =?utf-8?B?Z1o3WGgvd0I1V1VMVnQyUnprTEVjOEFpTEdsM0dvMFBaRkhVZlo4NHlMRFp0?=
 =?utf-8?B?TUd2ZldUVDlwbDduVGd1T2JzY214aGhzL2ZFbXR6dmZTVjRVLytobWV3WDY2?=
 =?utf-8?B?VUxvMlN5ZDBJME9NajkvWXlqV3MvY1BGc1VTbGtoT0RpcktwMi9OODdHR0lw?=
 =?utf-8?B?MGhFeVRNc21PSnh2UnZKM1hiL0RGQllWZmhxcjZVZ3JPeVRDbFF3RXVzcXo1?=
 =?utf-8?B?OXJKVEI1elRxOWorZFg0ajBHVVplVlp1ejBJQWdhVlk2ZU1BZTBrZ3NpeUpW?=
 =?utf-8?B?UGJNeTh4SE1UdzdJL0REZkQzd3ZEQ24vbG5LSFprVytqQmhGUHZFb2k0M2hF?=
 =?utf-8?B?MkhuVHV0WHgrK1hyY2cxU09MZ3dFVnBhVVROM0ZXSDUxS0h0L0djYjRXbERR?=
 =?utf-8?B?eGJXaEFFSlVmNk0vOW9NMHg1NFlNbE0yV3NUR2szWklCOTU0a3QySFF1ZTVr?=
 =?utf-8?B?OUhjWnB1dGFxdE5RS0xDRlpKTHRxTFgzcXFCMUZjZUFySzA1ejIreTQzR1lj?=
 =?utf-8?B?QUFXblRMWUVQVzFSM25sb3hKZGI1MzhoMXRuQktmRGFUNDRJYVNBSWRpQ1Rm?=
 =?utf-8?B?R1huazQ4ZVMxZmltT3lHQVZBZElOQk9QR1NoUkh5VHkwaDgrd2trRE13bjI2?=
 =?utf-8?B?MHZEM2tkTHRqZHBXNjdIQjVia0RJT2ROSmpjMWZSZnJLZjZlUmhPUlc5TjJS?=
 =?utf-8?B?ME1yb3NvcTZsNGY0V2Ura2ZtSkpkUWRrZHlwQnc5ajJpNU1RV2pCRVN6blNp?=
 =?utf-8?B?WnFaVHF3aHYzYUJlZHFVSjlmVU9sT2tQa1B0TEFrdndDSXVaZ1BKaG9laXRL?=
 =?utf-8?B?UlQyK1djRWtOYXd2QTdXN1R4NHJnVUVWNnhtQ3o5NlpuTSttc0RKUUxManU2?=
 =?utf-8?B?MXFrclFxdXpkR295cEZ3MmxBVS9iamIwYWxmUnZiWStPZDVsT0FHUWwzdUYv?=
 =?utf-8?Q?m86FAmRd2ar45L2s6sh4xY6m40PRIqfd?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM8PR07MB7602.eurprd07.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(7416014)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?WUJ4SVc0OEhLUnJNcVNGbTBaNUczVkp3Vk5HN1psYnY4WUsremh6Q2JhWEdD?=
 =?utf-8?B?UmJ6cURGQW85aHFLRm9PL3lwU29IMnREbEY1b0dLdGxLZ2N3c2pmdmpWYTRt?=
 =?utf-8?B?cjUzVmJsQmpNR0Rlek90S2Z4WGZKTS9vSUdyRGF0RlNxaHA0OW9EWjZ5dHh4?=
 =?utf-8?B?NGpRa1grQkVrbkxLeEVnZ3ZuZE1jK2VHeWgyTkZXRGYxYjI5eDVaVzYzVEQx?=
 =?utf-8?B?c0xSeVN4eWhMYUpJdThxbkgvK0V3Y1BiT2Fnb3k4VXR4RFZoNVpkOWdVNUZH?=
 =?utf-8?B?YnhpcURUbUEvUkticU1qbTNBdFlHZlhBN2hCRkpGYVIrOXF1azlydWdYbGNI?=
 =?utf-8?B?QW44WG41MGFieTA2SEJ3QnkySXdreE9uZ2JIa09aTG5UdktYQitpTGl6Mk04?=
 =?utf-8?B?c29wSFVVRWlRV1BxYUlHbzQ3bWFWRFhxdTJ5cjRzN2xKaW5JRUVnaXhZWXFv?=
 =?utf-8?B?dFF6VUpGY2FxeklNUUtmK1Rhb2NvTmYrSzhOOTdJc2RKSHJ5eDlMb1loMWtx?=
 =?utf-8?B?UDV3T3hja3IyL0JaUXNXNngwTk1ERE5uTWxvOUE3aXNNNjJxbC9MS1o4cTRO?=
 =?utf-8?B?aklKOGVKYzhQQzJhbzN2OXRITHhuUkx6a1dHZjNDRWVBbXQvajRiK29ZMS9v?=
 =?utf-8?B?VzdyZmJGRlFzWUxNNWU0NWdyaUFVRUhOY2g0aUsweHI2bHhtWlVWcVljU2ZJ?=
 =?utf-8?B?dlZUZTJ5OGFDYlo1bUxZUnBQcGpmQjZCZWs4MDFQYlhDNnhkQ3RiOFl4VWZ0?=
 =?utf-8?B?S01tT1UrV202YkU1clRvS0pkVDZPMDhIcWhTM2V6RGMxc3Q1bUI5cjNNY2dR?=
 =?utf-8?B?VTI4UkFEelFTdC8wOC84S1FyR1YzK3BoM3FnWGY4bzlmVVFVSTR6YVF0SGd0?=
 =?utf-8?B?MHJGK3ZONzExWndMWVNEMTFNbkZUL0xrNzJKRG80YlFybHJocHpEdVlaTTYz?=
 =?utf-8?B?Wmk4cGhNZGZwenp4bjVibm84NnRNdlBYbWMxNEpKRVgzTVFMc3NxdUdpTHRr?=
 =?utf-8?B?RHdjN0xYUnhLRnVuUGNZYUcxNFdJdUxwbDBmWkFFb0NxcksyMWdaMWZySWhz?=
 =?utf-8?B?T1NwQ09MT3Q3SzI2R0tvbmZ0WlUvWG1QeFV2ZU9MOGRFaUlUbG1zQS81K3hT?=
 =?utf-8?B?ajBxTGkyaU03OUpxZlpnaW5GTk5CaFgvd2t4em43K3pOUlRrdFV0NHdZWk9Y?=
 =?utf-8?B?UDkweEdGamxNaFM1T01GdllmOEUyVENxdTNETUNmWDNYclRwaTVMeHE5VEZO?=
 =?utf-8?B?YUdZdVRKb2FITGVsRnJMWW1rbWt5UHg4MzlOc2RQbFpDaWFaUHN0VWw5Z2E2?=
 =?utf-8?B?aTJCZEo0cDVWQ0pTOVVwOTV5VUt6QWY3QkorSXRxcXJreFVoQTBuYVFsZHV0?=
 =?utf-8?B?dlRsdEM5TVRseFVWcUN1K0M2cGMwQzZ5alVvOFl1TkU4eVFOblBlVjU4dUJk?=
 =?utf-8?B?K3QvWEtJSW1sTGQ5TWhGTjFqOE5WSS81VlJ4eTUzcGNJOFhxM2c2MFdRMmJH?=
 =?utf-8?B?bXQ3ZUMxdWhFMytrOUhPQ0NGUDVGcUJ0SS9RWEhtOUV0UGlDTjk4ZnZtam56?=
 =?utf-8?B?Mk44bEtHaXV5MUlZWlZhQ3V4UjJCNnZheE0xMWdwK3lTUVNQMzQwZE1wdWVV?=
 =?utf-8?B?TXVBbE95bUo3OGxiWTB2SGVRUkJ0L1BLQTJyRklJR01veFhUZkpKQnpFT0lv?=
 =?utf-8?B?c0w4RExzSGR1cWk2VmUrRkE2elRGUGxtZWI3bmhPRStwMm01OUgxT0MvUFIz?=
 =?utf-8?B?ZDFwdkZ2bk5JNWQzVUFERGlkcnc3bVhtcU83MkM4dmlaaXArOTlxTERYQ1d6?=
 =?utf-8?B?TVV6L2lwN0xoTnBJRUJVRjVoRnQwcXl2a0FFK2hYYmxJMFBqdFBjN2tQajdN?=
 =?utf-8?B?Z2hmdkRJdmx5aWpoeUhhd1RIQW8yNlh5QXdQeFFNR0FtNHNYR2VCYzRyOFRv?=
 =?utf-8?B?eEpGcFVPMHFGVWdHelBGTGxaVnlZTWdZZzYvOE93U3pCcy9hOWJwRE5xZldU?=
 =?utf-8?B?U21SWUcxdDRRZDJueFAvbjdUSEsrMS9VNDl3WFpxai9wVC93M1VwVE4wMUZv?=
 =?utf-8?B?NmxmT0dHallrSkcrL0tPbzQwSnoxa2lQY2dNcHAwY2lzUDR6RC81ZVRKZ3Zm?=
 =?utf-8?B?T0lIN1RuSGFuMTB1b1h1a2U1RGxWSnhSU3FjeVRRdTNCU3MzNlRaYTZ2dC9H?=
 =?utf-8?Q?ibW+dBeoVEdjEMrpMYUqZYA=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <E6592038D60443488BDD6AAF2AE9C835@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: eviden.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM8PR07MB7602.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8adb2fe5-94cf-4d6f-9e81-08dd3e9b927c
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2025 06:26:45.4354
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 7d1c7785-2d8a-437d-b842-1ed5d8fbe00a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ERBgtATSJ34ThOTwYaU4lVW/FPgHZLhYUT7ccY1Da7pUR7YHkQqb6pUhQLU7MF7xlI5bfQzqudT8w7MNPVeE7dRQyF1s5qdSlaJ9x2K+MJ49gyGNgB7mJ2PwvSU4IveN
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB9531

UmV2aWV3ZWQtYnk6IENsw6ltZW50IE1hdGhpZXUtLURyaWY8Y2xlbWVudC5tYXRoaWV1LS1kcmlm
QGV2aWRlbi5jb20+DQoNCg0KDQpPbiAyNS8wMS8yMDI1IDE5OjEzLCBQaGlsaXBwZSBNYXRoaWV1
LURhdWTDqSB3cm90ZToNCj4gQ2F1dGlvbjogRXh0ZXJuYWwgZW1haWwuIERvIG5vdCBvcGVuIGF0
dGFjaG1lbnRzIG9yIGNsaWNrIGxpbmtzLCB1bmxlc3MgdGhpcyBlbWFpbCBjb21lcyBmcm9tIGEg
a25vd24gc2VuZGVyIGFuZCB5b3Uga25vdyB0aGUgY29udGVudCBpcyBzYWZlLg0KPg0KPg0KPiBX
aGVuIG11bHRpcGxlIFFPTSB0eXBlcyBhcmUgcmVnaXN0ZXJlZCBpbiB0aGUgc2FtZSBmaWxlLA0K
PiBpdCBpcyBzaW1wbGVyIHRvIHVzZSB0aGUgdGhlIERFRklORV9UWVBFUygpIG1hY3JvLiBJbg0K
PiBwYXJ0aWN1bGFyIGJlY2F1c2UgdHlwZSBhcnJheSBkZWNsYXJlZCB3aXRoIHN1Y2ggbWFjcm8N
Cj4gYXJlIGVhc2llciB0byByZXZpZXcuDQo+DQo+IFNpZ25lZC1vZmYtYnk6IFBoaWxpcHBlIE1h
dGhpZXUtRGF1ZMOpIDxwaGlsbWRAbGluYXJvLm9yZz4NCj4gLS0tDQo+ICAgaHcvY29yZS9zeXNi
dXMuYyB8IDM5ICsrKysrKysrKysrKysrKysrLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAgIDEg
ZmlsZSBjaGFuZ2VkLCAxNyBpbnNlcnRpb25zKCspLCAyMiBkZWxldGlvbnMoLSkNCj4NCj4gZGlm
ZiAtLWdpdCBhL2h3L2NvcmUvc3lzYnVzLmMgYi9ody9jb3JlL3N5c2J1cy5jDQo+IGluZGV4IGY3
MTNiYmZlMDRmLi4zMDZmOTg0MDZjMCAxMDA2NDQNCj4gLS0tIGEvaHcvY29yZS9zeXNidXMuYw0K
PiArKysgYi9ody9jb3JlL3N5c2J1cy5jDQo+IEBAIC04MCwxMyArODAsNiBAQCBzdGF0aWMgdm9p
ZCBzeXN0ZW1fYnVzX2NsYXNzX2luaXQoT2JqZWN0Q2xhc3MgKmtsYXNzLCB2b2lkICpkYXRhKQ0K
PiAgICAgICBrLT5nZXRfZndfZGV2X3BhdGggPSBzeXNidXNfZ2V0X2Z3X2Rldl9wYXRoOw0KPiAg
IH0NCj4NCj4gLXN0YXRpYyBjb25zdCBUeXBlSW5mbyBzeXN0ZW1fYnVzX2luZm8gPSB7DQo+IC0g
ICAgLm5hbWUgPSBUWVBFX1NZU1RFTV9CVVMsDQo+IC0gICAgLnBhcmVudCA9IFRZUEVfQlVTLA0K
PiAtICAgIC5pbnN0YW5jZV9zaXplID0gc2l6ZW9mKEJ1c1N0YXRlKSwNCj4gLSAgICAuY2xhc3Nf
aW5pdCA9IHN5c3RlbV9idXNfY2xhc3NfaW5pdCwNCj4gLX07DQo+IC0NCj4gICAvKiBDaGVjayB3
aGV0aGVyIGFuIElSUSBzb3VyY2UgZXhpc3RzICovDQo+ICAgYm9vbCBzeXNidXNfaGFzX2lycShT
eXNCdXNEZXZpY2UgKmRldiwgaW50IG4pDQo+ICAgew0KPiBAQCAtMzA2LDE1ICsyOTksNiBAQCBz
dGF0aWMgdm9pZCBzeXNidXNfZGV2aWNlX2NsYXNzX2luaXQoT2JqZWN0Q2xhc3MgKmtsYXNzLCB2
b2lkICpkYXRhKQ0KPiAgICAgICBrLT51c2VyX2NyZWF0YWJsZSA9IGZhbHNlOw0KPiAgIH0NCj4N
Cj4gLXN0YXRpYyBjb25zdCBUeXBlSW5mbyBzeXNidXNfZGV2aWNlX3R5cGVfaW5mbyA9IHsNCj4g
LSAgICAubmFtZSA9IFRZUEVfU1lTX0JVU19ERVZJQ0UsDQo+IC0gICAgLnBhcmVudCA9IFRZUEVf
REVWSUNFLA0KPiAtICAgIC5pbnN0YW5jZV9zaXplID0gc2l6ZW9mKFN5c0J1c0RldmljZSksDQo+
IC0gICAgLmFic3RyYWN0ID0gdHJ1ZSwNCj4gLSAgICAuY2xhc3Nfc2l6ZSA9IHNpemVvZihTeXNC
dXNEZXZpY2VDbGFzcyksDQo+IC0gICAgLmNsYXNzX2luaXQgPSBzeXNidXNfZGV2aWNlX2NsYXNz
X2luaXQsDQo+IC19Ow0KPiAtDQo+ICAgc3RhdGljIEJ1c1N0YXRlICptYWluX3N5c3RlbV9idXM7
DQo+DQo+ICAgc3RhdGljIHZvaWQgbWFpbl9zeXN0ZW1fYnVzX2NyZWF0ZSh2b2lkKQ0KPiBAQCAt
MzM3LDEwICszMjEsMjEgQEAgQnVzU3RhdGUgKnN5c2J1c19nZXRfZGVmYXVsdCh2b2lkKQ0KPiAg
ICAgICByZXR1cm4gbWFpbl9zeXN0ZW1fYnVzOw0KPiAgIH0NCj4NCj4gLXN0YXRpYyB2b2lkIHN5
c2J1c19yZWdpc3Rlcl90eXBlcyh2b2lkKQ0KPiAtew0KPiAtICAgIHR5cGVfcmVnaXN0ZXJfc3Rh
dGljKCZzeXN0ZW1fYnVzX2luZm8pOw0KPiAtICAgIHR5cGVfcmVnaXN0ZXJfc3RhdGljKCZzeXNi
dXNfZGV2aWNlX3R5cGVfaW5mbyk7DQo+IC19DQo+ICtzdGF0aWMgY29uc3QgVHlwZUluZm8gc3lz
YnVzX3R5cGVzW10gPSB7DQo+ICsgICAgew0KPiArICAgICAgICAubmFtZSAgICAgICAgICAgPSBU
WVBFX1NZU1RFTV9CVVMsDQo+ICsgICAgICAgIC5wYXJlbnQgICAgICAgICA9IFRZUEVfQlVTLA0K
PiArICAgICAgICAuaW5zdGFuY2Vfc2l6ZSAgPSBzaXplb2YoQnVzU3RhdGUpLA0KPiArICAgICAg
ICAuY2xhc3NfaW5pdCAgICAgPSBzeXN0ZW1fYnVzX2NsYXNzX2luaXQsDQo+ICsgICAgfSwNCj4g
KyAgICB7DQo+ICsgICAgICAgIC5uYW1lICAgICAgICAgICA9IFRZUEVfU1lTX0JVU19ERVZJQ0Us
DQo+ICsgICAgICAgIC5wYXJlbnQgICAgICAgICA9IFRZUEVfREVWSUNFLA0KPiArICAgICAgICAu
aW5zdGFuY2Vfc2l6ZSAgPSBzaXplb2YoU3lzQnVzRGV2aWNlKSwNCj4gKyAgICAgICAgLmFic3Ry
YWN0ICAgICAgID0gdHJ1ZSwNCj4gKyAgICAgICAgLmNsYXNzX3NpemUgICAgID0gc2l6ZW9mKFN5
c0J1c0RldmljZUNsYXNzKSwNCj4gKyAgICAgICAgLmNsYXNzX2luaXQgICAgID0gc3lzYnVzX2Rl
dmljZV9jbGFzc19pbml0LA0KPiArICAgIH0sDQo+ICt9Ow0KPg0KPiAtdHlwZV9pbml0KHN5c2J1
c19yZWdpc3Rlcl90eXBlcykNCj4gK0RFRklORV9UWVBFUyhzeXNidXNfdHlwZXMpDQo+IC0tDQo+
IDIuNDcuMQ0KPg0K


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 09:22:02 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 09:22:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877482.1287610 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcLJV-0003wJ-7H; Mon, 27 Jan 2025 09:21:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877482.1287610; Mon, 27 Jan 2025 09:21:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcLJV-0003wC-3S; Mon, 27 Jan 2025 09:21:49 +0000
Received: by outflank-mailman (input) for mailman id 877482;
 Mon, 27 Jan 2025 09:21: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 <SRS0=wC6S=UT=gmail.com=shentey@srs-se1.protection.inumbo.net>)
 id 1tcLJU-0003w0-HA
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 09:21:48 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 202752de-dc90-11ef-99a4-01e77a169b0f;
 Mon, 27 Jan 2025 10:21:44 +0100 (CET)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-aaeec07b705so812720166b.2
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 01:21:44 -0800 (PST)
Received: from [127.0.0.1] (dynamic-093-128-047-181.93.128.pool.telefonica.de.
 [93.128.47.181]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab6760b76acsm548940966b.113.2025.01.27.01.21.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 01:21:43 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 202752de-dc90-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1737969704; x=1738574504; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:references
         :in-reply-to:subject:cc:to:from:date:from:to:cc:subject:date
         :message-id:reply-to;
        bh=+UuFjFlXx2cpy2FEWdZ5KX6cphMe20KLc2czhmRa7OM=;
        b=CEvNpAUK17+BX1C3hnd+eQTfCHBXMP3QkyrVsPub85bxJDFhU43CLUa9oIsjWFZjDs
         SEGHGajn1O9UJAWlKe2JhWt5Cbk9f1942BioDJj0VMm9rZJ1ZR/QMmewSi/cQRA3TiXi
         K+gpqbxYYlpqbaEWV7miZcRQV1nUDmuuEdpfuEZH/NcAcOPCns/rg78B+rDPp7/UX0T3
         XuBSCgnkmK2f+OBeriyj9mQcdYGbjlBrgWaPG23jEKDmPq+fhwhw/cdmzGZbDt80jWxA
         so+KTyg850aRLGaT5ibNSclAsEPtEnPF7jp1ZU1v8MtNlgQ6dyErGogXVN321AaN1rFo
         LOPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737969704; x=1738574504;
        h=content-transfer-encoding:mime-version:message-id:references
         :in-reply-to:subject:cc:to:from:date:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=+UuFjFlXx2cpy2FEWdZ5KX6cphMe20KLc2czhmRa7OM=;
        b=Oadre+cMqybODNpyHtcJXi06Fq+okBAH+olETlr6fAV8OC+X0Um7PMqB0ynwxW1OSA
         1Rm+GUmi8gTer4DDX7iQ7w23WTfD+H8XyL5hbv/9QevUfqcn9gO5YnjUb5Pn3Jn/piyp
         Oy40m5oVZgjPVCb2GxVGFVvMYu9VjkcLeisS8eRCJItFAZrF5DRSdEZs8zTxRYU5vidA
         x0IW0vxwuR2FdKlxseHzR+5k2QtAxJSxdHozKjYuochIefM390CDxyONQN0GRpg2uzZW
         qdR1rLoW3ejMRaYafR+XqxiCrhwZShcw3SZMbkAtH2ltGnA+Jxn1ASNR5pALtzQzHXxV
         0i4g==
X-Forwarded-Encrypted: i=1; AJvYcCV05kxYXrtY/wQvJBOP/u2a00Ooe0pIWhRKXOUKlMBjl7zloidREleitAwRTfmCnkC29OQJGF7AG5w=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzBKwznQnkt9zVr5F3SG2SQt5phcSP6Dyq1+BFOP/galI2pm4Ty
	7rbr3fpLgiz4HFBdW2zRWECP4epFUYhPl3SZA1QOFfl470KlpV05
X-Gm-Gg: ASbGncucjkBmg5pfjEbDPqNFB0sc1lkCXxLj1SPWPQ9nscRSd10M+4zsgeJrX1B2+hU
	4xs4OeqoEOcH9u+yaKBaDuOLd/c72uvjbnFrmJ0g8ybSGsxDfNF0psMRzPK6GHVgQvgiZfj83oF
	oy8V6RMykhEInLOuwLMJOLeYM8COmEEl1hIHCgjy5h2W1qWZ57fJpmiyNmFC85a2b5l/Kcywpkb
	hIZnRKs0kwNHfMDjk9rF/UboG7DTdfDRcE0UhMMT5Q2kXV7u4GqNNOXasutlBoS7EnNXa91HTpt
	LM2v3RCrVpkSF5FpTPju96da79mwquC0JoZVu0ks+KcGIJT7HMlYabAvOTszFpyBAZU=
X-Google-Smtp-Source: AGHT+IEkfmy1lj+GPVFBL2FtqWCYO3YjtUx8arnMB2aNAPatwxoDM48FZF5ggzn93a2OlFcmqgnFTQ==
X-Received: by 2002:a17:906:f5a2:b0:aab:c78c:a7ed with SMTP id a640c23a62f3a-ab38b3db4d1mr3880527066b.49.1737969703759;
        Mon, 27 Jan 2025 01:21:43 -0800 (PST)
Date: Mon, 27 Jan 2025 09:21:42 +0000
From: Bernhard Beschow <shentey@gmail.com>
To: =?ISO-8859-1?Q?Philippe_Mathieu-Daud=E9?= <philmd@linaro.org>,
 qemu-devel@nongnu.org
CC: Yi Liu <yi.l.liu@intel.com>, Markus Armbruster <armbru@redhat.com>,
 Eduardo Habkost <eduardo@habkost.net>,
 Anthony PERARD <anthony@xenproject.org>,
 Gustavo Romero <gustavo.romero@linaro.org>, Jason Wang <jasowang@redhat.com>,
 qemu-ppc@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>,
 Paolo Bonzini <pbonzini@redhat.com>, Alexander Graf <graf@amazon.com>,
 Richard Henderson <richard.henderson@linaro.org>,
 Stefan Berger <stefanb@linux.vnet.ibm.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Gerd Hoffmann <kraxel@redhat.com>,
 =?ISO-8859-1?Q?Daniel_P=2E_Berrang=E9?= <berrange@redhat.com>,
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
 xen-devel@lists.xenproject.org,
 Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
 Alex Williamson <alex.williamson@redhat.com>, Paul Durrant <paul@xen.org>,
 =?ISO-8859-1?Q?Cl=E9ment_Mathieu--Drif?= <clement.mathieu--drif@eviden.com>,
 =?ISO-8859-1?Q?C=E9dric_Le_Goater?= <clg@redhat.com>
Subject: =?US-ASCII?Q?Re=3A_=5BPATCH_7/9=5D_hw/net=3A_Have_eTSEC_dev?=
 =?US-ASCII?Q?ice_inherit_from_DYNAMIC=5FSYS=5FBUS=5FDEVICE?=
In-Reply-To: <20250125181343.59151-8-philmd@linaro.org>
References: <20250125181343.59151-1-philmd@linaro.org> <20250125181343.59151-8-philmd@linaro.org>
Message-ID: <0EF260B4-A6E0-47A5-9EA4-7E90F7261F5B@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable



Am 25=2E Januar 2025 18:13:41 UTC schrieb "Philippe Mathieu-Daud=C3=A9" <p=
hilmd@linaro=2Eorg>:
>Because the network eTSEC device can be optionally plugged on the
>TYPE_PLATFORM_BUS_DEVICE, have it inherit TYPE_DYNAMIC_SYS_BUS_DEVICE=2E
>
>Signed-off-by: Philippe Mathieu-Daud=C3=A9 <philmd@linaro=2Eorg>

Tested-by: Bernhard Beschow <shentey@gmail=2Ecom>
Acked-by: Bernhard Beschow <shentey@gmail=2Ecom>

>---
> hw/net/fsl_etsec/etsec=2Ec | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
>diff --git a/hw/net/fsl_etsec/etsec=2Ec b/hw/net/fsl_etsec/etsec=2Ec
>index 781b9003954=2E=2E3ce4fa2662d 100644
>--- a/hw/net/fsl_etsec/etsec=2Ec
>+++ b/hw/net/fsl_etsec/etsec=2Ec
>@@ -425,14 +425,12 @@ static void etsec_class_init(ObjectClass *klass, vo=
id *data)
>     dc->realize =3D etsec_realize;
>     device_class_set_legacy_reset(dc, etsec_reset);
>     device_class_set_props(dc, etsec_properties);
>-    /* Supported by ppce500 machine */
>-    dc->user_creatable =3D true;
> }
>=20
> static const TypeInfo etsec_types[] =3D {
>     {
>         =2Ename          =3D TYPE_ETSEC_COMMON,
>-        =2Eparent        =3D TYPE_SYS_BUS_DEVICE,
>+        =2Eparent        =3D TYPE_DYNAMIC_SYS_BUS_DEVICE,
>         =2Einstance_size =3D sizeof(eTSEC),
>         =2Eclass_init    =3D etsec_class_init,
>         =2Einstance_init =3D etsec_instance_init,


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 09:23:43 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 09:23:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877491.1287619 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcLLK-0004Vv-HL; Mon, 27 Jan 2025 09:23:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877491.1287619; Mon, 27 Jan 2025 09:23:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcLLK-0004Vo-Eg; Mon, 27 Jan 2025 09:23:42 +0000
Received: by outflank-mailman (input) for mailman id 877491;
 Mon, 27 Jan 2025 09:23:41 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=wC6S=UT=gmail.com=shentey@srs-se1.protection.inumbo.net>)
 id 1tcLLJ-0004Vi-Pp
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 09:23:41 +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 64ed1d12-dc90-11ef-99a4-01e77a169b0f;
 Mon, 27 Jan 2025 10:23:40 +0100 (CET)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-aaee0b309adso578109566b.3
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 01:23:39 -0800 (PST)
Received: from [127.0.0.1] (dynamic-093-128-047-181.93.128.pool.telefonica.de.
 [93.128.47.181]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab675e1373esm546856666b.1.2025.01.27.01.23.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 01:23:38 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 64ed1d12-dc90-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1737969819; x=1738574619; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:references
         :in-reply-to:subject:cc:to:from:date:from:to:cc:subject:date
         :message-id:reply-to;
        bh=rdp6qM5HkNGE6pm93Ya34vtciW0eBxcidQ8OmMD0mDI=;
        b=SJX1ksleR7jJSObs1g8YDIPno0rraN3TrOjuGrbblRm9JGQ3qiFhMRyHwGTY6QRx2j
         SarVq+OD7P8d25GCmAxhkiqzo8hzS/Y+BgHWo1h5jJsaIDN9QycwENpcpk+ugCOugYvN
         w1lH6dixBIKSTuLcsfnLnPVg+QnhsyqaR2RCRDJIZIzH7vuIK2ASTK+5AQywzfMW2Vxd
         yWjAKlybFud7EMX0zK6hH8w4LoYc+Mo9vDXarriuGPZsQvfF/XVDRiyWMC/dl3edBpSc
         dt5I5a5csiRUIkAhsukqXExV9657RcJxSYJ4inmMtgFTNGha052LoQSEVI6s5c3aFTIp
         dbZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737969819; x=1738574619;
        h=content-transfer-encoding:mime-version:message-id:references
         :in-reply-to:subject:cc:to:from:date:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=rdp6qM5HkNGE6pm93Ya34vtciW0eBxcidQ8OmMD0mDI=;
        b=qJ2ySMguTulAD7BvIJKZ0VYfnVrmOMqBOl9Bc/2IUYs3oNcMHmkwP16PA+mPUoKQCG
         4wGkctnp4rg1bF6IYCa0JbgCgLje+7cIBXy0pmyfgHH0GRdLQ5UZwoZjsaqcFYZWMmYx
         M9lhUV3kWA0M9NWLrAjTQNY6rqqf679bqqibll+fkVSdE790K+bAU6HDmMpR6ZqHF04T
         S6DNOe+erpuQhIE2GMgJpZ4qy6rPrei/ZxAl5pElXamRL2gjphPXPV4mBeDkwxeQjn4/
         /5A0h77iBwt+oBWejlxlRVP44Q8TnWx0scIMAHGBF3s4v3sp4m+NKnp3TmJWRaFwEG+2
         XRpg==
X-Forwarded-Encrypted: i=1; AJvYcCVxaS+RnEW9djPCNl+nwi88jaC8t2Ogq3NEQu7pjGeH/Tz9//eJ9wUI97txW6TRWoINl/HJpNsRSAg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwTCJvvG1FpPY0BHNZkBI2zfuyf20wHD9ZjPzQaUsVide6EdMNU
	+C2QEZNHol2rLu4tPwqD7J5/htwo5eagQ7HchlxgZ4PGfiGpc+MF
X-Gm-Gg: ASbGncv/W8ByO1IVpchyitO3tslLGdZr0BZC/Y4DNmsii2i6H6zoU/4QhA/vUl7Q/l0
	dNqtONsSIFXVOwHhROLcHq2/eOjWCaKHOGGr68raxZudDCSyQiyn1H3LeM/3wLCUznKoMZ+Cwks
	KFELL57NzcK2o+E6D+r0t7rJKzaNQNbnB7PXoXcK1HtBo/5VyJ9pioKXblbrkBozt8VxhQ/bpJj
	2P9VH8vcwTFj7em1bcHxrKjmUBjsdN8wGZZRQNZJy2vDZnUKEBQ21jStJVxLjuYUSBQ4BJSp8CP
	I7ASBuKZnjgfNfJltn603E1l03vMw9gemJYEbb/+Cc4NRnj7XSaAYyaN
X-Google-Smtp-Source: AGHT+IGGdDiQNlIruAHADHHYWkF49cOK1bT139jWgdCV4iDBjNSzB0gu/pftWQhhkzbn6APXXw+Bbw==
X-Received: by 2002:a17:907:3602:b0:aaf:74b3:80db with SMTP id a640c23a62f3a-ab38b0b90f1mr3823978866b.3.1737969819097;
        Mon, 27 Jan 2025 01:23:39 -0800 (PST)
Date: Mon, 27 Jan 2025 09:23:38 +0000
From: Bernhard Beschow <shentey@gmail.com>
To: =?ISO-8859-1?Q?Philippe_Mathieu-Daud=E9?= <philmd@linaro.org>,
 qemu-devel@nongnu.org
CC: Yi Liu <yi.l.liu@intel.com>, Markus Armbruster <armbru@redhat.com>,
 Eduardo Habkost <eduardo@habkost.net>,
 Anthony PERARD <anthony@xenproject.org>,
 Gustavo Romero <gustavo.romero@linaro.org>, Jason Wang <jasowang@redhat.com>,
 qemu-ppc@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>,
 Paolo Bonzini <pbonzini@redhat.com>, Alexander Graf <graf@amazon.com>,
 Richard Henderson <richard.henderson@linaro.org>,
 Stefan Berger <stefanb@linux.vnet.ibm.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Gerd Hoffmann <kraxel@redhat.com>,
 =?ISO-8859-1?Q?Daniel_P=2E_Berrang=E9?= <berrange@redhat.com>,
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
 xen-devel@lists.xenproject.org,
 Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
 Alex Williamson <alex.williamson@redhat.com>, Paul Durrant <paul@xen.org>,
 =?ISO-8859-1?Q?Cl=E9ment_Mathieu--Drif?= <clement.mathieu--drif@eviden.com>,
 =?ISO-8859-1?Q?C=E9dric_Le_Goater?= <clg@redhat.com>
Subject: =?US-ASCII?Q?Re=3A_=5BPATCH_2/9=5D_hw/sysbus=3A_Declare_?=
 =?US-ASCII?Q?QOM_types_using_DEFINE=5FTYPES=28=29_macro?=
In-Reply-To: <20250125181343.59151-3-philmd@linaro.org>
References: <20250125181343.59151-1-philmd@linaro.org> <20250125181343.59151-3-philmd@linaro.org>
Message-ID: <003404AB-0220-474C-B9DC-4CD88225C420@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable



Am 25=2E Januar 2025 18:13:36 UTC schrieb "Philippe Mathieu-Daud=C3=A9" <p=
hilmd@linaro=2Eorg>:
>When multiple QOM types are registered in the same file,
>it is simpler to use the the DEFINE_TYPES() macro=2E In
>particular because type array declared with such macro
>are easier to review=2E
>
>Signed-off-by: Philippe Mathieu-Daud=C3=A9 <philmd@linaro=2Eorg>
>---
> hw/core/sysbus=2Ec | 39 +++++++++++++++++----------------------
> 1 file changed, 17 insertions(+), 22 deletions(-)
>
>diff --git a/hw/core/sysbus=2Ec b/hw/core/sysbus=2Ec
>index f713bbfe04f=2E=2E306f98406c0 100644
>--- a/hw/core/sysbus=2Ec
>+++ b/hw/core/sysbus=2Ec
>@@ -80,13 +80,6 @@ static void system_bus_class_init(ObjectClass *klass, =
void *data)
>     k->get_fw_dev_path =3D sysbus_get_fw_dev_path;
> }
>=20
>-static const TypeInfo system_bus_info =3D {
>-    =2Ename =3D TYPE_SYSTEM_BUS,
>-    =2Eparent =3D TYPE_BUS,
>-    =2Einstance_size =3D sizeof(BusState),
>-    =2Eclass_init =3D system_bus_class_init,
>-};
>-
> /* Check whether an IRQ source exists */
> bool sysbus_has_irq(SysBusDevice *dev, int n)
> {
>@@ -306,15 +299,6 @@ static void sysbus_device_class_init(ObjectClass *kl=
ass, void *data)
>     k->user_creatable =3D false;
> }
>=20
>-static const TypeInfo sysbus_device_type_info =3D {
>-    =2Ename =3D TYPE_SYS_BUS_DEVICE,
>-    =2Eparent =3D TYPE_DEVICE,
>-    =2Einstance_size =3D sizeof(SysBusDevice),
>-    =2Eabstract =3D true,
>-    =2Eclass_size =3D sizeof(SysBusDeviceClass),
>-    =2Eclass_init =3D sysbus_device_class_init,
>-};
>-
> static BusState *main_system_bus;
>=20
> static void main_system_bus_create(void)
>@@ -337,10 +321,21 @@ BusState *sysbus_get_default(void)
>     return main_system_bus;
> }
>=20
>-static void sysbus_register_types(void)
>-{
>-    type_register_static(&system_bus_info);
>-    type_register_static(&sysbus_device_type_info);
>-}
>+static const TypeInfo sysbus_types[] =3D {
>+    {
>+        =2Ename           =3D TYPE_SYSTEM_BUS,
>+        =2Eparent         =3D TYPE_BUS,
>+        =2Einstance_size  =3D sizeof(BusState),
>+        =2Eclass_init     =3D system_bus_class_init,
>+    },
>+    {
>+        =2Ename           =3D TYPE_SYS_BUS_DEVICE,
>+        =2Eparent         =3D TYPE_DEVICE,
>+        =2Einstance_size  =3D sizeof(SysBusDevice),
>+        =2Eabstract       =3D true,
>+        =2Eclass_size     =3D sizeof(SysBusDeviceClass),
>+        =2Eclass_init     =3D sysbus_device_class_init,
>+    },
>+};
>=20
>-type_init(sysbus_register_types)
>+DEFINE_TYPES(sysbus_types)

Can now omit the "qom/module=2Eh" include=2E With that changed:

Reviewed-by: Bernhard Beschow


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 09:41:52 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 09:41:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877505.1287635 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcLcp-0008Lu-2m; Mon, 27 Jan 2025 09:41:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877505.1287635; Mon, 27 Jan 2025 09:41:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcLco-0008Ln-Vt; Mon, 27 Jan 2025 09:41:46 +0000
Received: by outflank-mailman (input) for mailman id 877505;
 Mon, 27 Jan 2025 09:41: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 <SRS0=wC6S=UT=gmail.com=shentey@srs-se1.protection.inumbo.net>)
 id 1tcLco-0008Lf-2R
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 09:41:46 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ebb1ed3e-dc92-11ef-a0e6-8be0dac302b0;
 Mon, 27 Jan 2025 10:41:45 +0100 (CET)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-5d3d479b1e6so6102930a12.2
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 01:41:45 -0800 (PST)
Received: from Provence.localdomain
 (dynamic-093-128-047-181.93.128.pool.telefonica.de. [93.128.47.181])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5dc18619265sm5140631a12.7.2025.01.27.01.41.43
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 27 Jan 2025 01:41:43 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ebb1ed3e-dc92-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1737970904; x=1738575704; 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=yjPzdHFXd2uRfONBBPJoicdiCvhjmel6wJx9kp25WTk=;
        b=Kx/WanjdicbfIxpC/1M0/Xp9oqO9cvJKQ89MntymSn3NMS1kQckEdfqJu527765dKL
         V2AhvOrD6WrQA56SntujIUhzohqM7/QdXf4XKPVpNtADfMFYTfTw5Q0Kq3N9i664NsmA
         pg7dqLKzcpdfntCzyV1Y7zZwn/FsSZ+5sVhgeAJJG47GHcIP3AHrBesr7GaYKYMM5jNq
         5S3cjOYQdG+wqEi8ClYxdQivbBS0LpxaIU9EtIg0vkkfxfsGVcTeUB3VKsemd+OcoFhh
         bjptWamBmt9UKfRVKl/LEIXkpTvmxkzDwKdL/H42gYQ6ZFbm0uFuURLwCmZ0v3HYxTh8
         OJpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737970904; x=1738575704;
        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=yjPzdHFXd2uRfONBBPJoicdiCvhjmel6wJx9kp25WTk=;
        b=obHw+5DFURygvtvsc3/5Kws5zKiTYT2tcNSfW7EHUshA19UaQWbcitvsVfmN2iFfDY
         Oypr7zjOeIRf9g0KSGTkSn+E26nc8z8+PsUBhhZH8BUu3U1t441kqSapaHC+7iWKv6T0
         /Bw5p6BBfFCvM4yZhpsOFLop9a4M4MKeIzoK5L4jnx2x0zDs78dlV4DE6a5+Mv9ndZr5
         rR4bYj8EYApbJHs74OjIRk+sVAYd52xabP0O8XG4L3w2IBSc0cbNahfihbjGoe7UWPkv
         9qgKsUS0AuUYQRamessDH3mejmY3Uk3rkReiLS9F0ibJJIxOleWxldL9utYYYLoTi5Zk
         h9Lg==
X-Forwarded-Encrypted: i=1; AJvYcCVJBQPibXpk6P0aE68SUisIloYEeGgsXv2lYHijR599zQDfAyziIs5qVvgNOJti8bO/CKR+m6swjgU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxNM1hMB6kcxLTt4KuKHeKNKrRwlpBNL2UTjPMf8LEYalC2wSn7
	LK24FuhPOq3EErniN6TcYk/M59eG8LZLJX8Qc0bxfJFeguUbVAd7
X-Gm-Gg: ASbGnctezdIHcJEUj+8kGvJwPKqdvkLUDJfak2QCvAUJy7z7Pkv26A1jp062s6UGq5l
	KFWcDI9GOCwlonLjr+qlvwmSNLgxnqHXmUUYyOcArLcgFJfm4VviCFzioMX/8slqq8dzq3gng8n
	c9KV00o5RDvSt9zmquooi2IB9c7+BKhwskKc9dArVGj/A5iO1gJH4dT2XUphIekhdeAwk3ALbp6
	BfK9ZdwX17pfkDLMmceKVQU/VwoFD5az/oGZ5Y/LpFvMiBFYq7fQOkP7GgNIhUlKpvmRyM4pPdT
	rxSsnUf332fasckLCt5SXr1zKtFpo091AsOIHQoKqXtTq/ZGnVQIIGdrRUwTZ5DJM2oK3A==
X-Google-Smtp-Source: AGHT+IFkv/KhCLVJUxMspAgUNe0GHT45E89xP1HqZLFbEuM2gS84XOsj/ALx/tTzcGTUQZwwVlsNIQ==
X-Received: by 2002:a05:6402:50d4:b0:5d0:cfad:f71 with SMTP id 4fb4d7f45d1cf-5db7db2bea3mr93510860a12.32.1737970904204;
        Mon, 27 Jan 2025 01:41:44 -0800 (PST)
From: Bernhard Beschow <shentey@gmail.com>
To: qemu-devel@nongnu.org
Cc: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	xen-devel@lists.xenproject.org,
	Paul Durrant <paul@xen.org>,
	Anthony PERARD <anthony@xenproject.org>,
	Bernhard Beschow <shentey@gmail.com>
Subject: [PATCH] hw/*/xen*: Prefer QOM cast for XenLegacyDevice
Date: Mon, 27 Jan 2025 10:41:29 +0100
Message-ID: <20250127094129.15941-1-shentey@gmail.com>
X-Mailer: git-send-email 2.48.1
In-Reply-To: <20250125181343.59151-10-philmd@linaro.org>
References: <20250125181343.59151-10-philmd@linaro.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Makes the code less sensitive regarding changes in the class hierarchy which
will be performed in the next patch.

Signed-off-by: Bernhard Beschow <shentey@gmail.com>
---
 hw/usb/xen-usb.c            | 6 +++---
 hw/xen/xen-legacy-backend.c | 2 +-
 hw/xen/xen_pvdev.c          | 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/hw/usb/xen-usb.c b/hw/usb/xen-usb.c
index 13901625c0..3da30efc44 100644
--- a/hw/usb/xen-usb.c
+++ b/hw/usb/xen-usb.c
@@ -755,10 +755,10 @@ static void usbback_portid_add(struct usbback_info *usbif, unsigned port,
 
     qdict = qdict_new();
     qdict_put_str(qdict, "driver", "usb-host");
-    tmp = g_strdup_printf("%s.0", usbif->xendev.qdev.id);
+    tmp = g_strdup_printf("%s.0", DEVICE(&usbif->xendev)->id);
     qdict_put_str(qdict, "bus", tmp);
     g_free(tmp);
-    tmp = g_strdup_printf("%s-%u", usbif->xendev.qdev.id, port);
+    tmp = g_strdup_printf("%s-%u", DEVICE(&usbif->xendev)->id, port);
     qdict_put_str(qdict, "id", tmp);
     g_free(tmp);
     qdict_put_int(qdict, "port", port);
@@ -1022,7 +1022,7 @@ static void usbback_alloc(struct XenLegacyDevice *xendev)
     usbif = container_of(xendev, struct usbback_info, xendev);
 
     usb_bus_new(&usbif->bus, sizeof(usbif->bus), &xen_usb_bus_ops,
-                DEVICE(&xendev->qdev));
+                DEVICE(xendev));
     for (i = 0; i < USBBACK_MAXPORTS; i++) {
         p = &(usbif->ports[i].port);
         usb_register_port(&usbif->bus, p, usbif, i, &xen_usb_port_ops,
diff --git a/hw/xen/xen-legacy-backend.c b/hw/xen/xen-legacy-backend.c
index 118c571b3a..ca2fe0e6b3 100644
--- a/hw/xen/xen-legacy-backend.c
+++ b/hw/xen/xen-legacy-backend.c
@@ -163,7 +163,7 @@ static struct XenLegacyDevice *xen_be_get_xendev(const char *type, int dom,
 
     /* init new xendev */
     xendev = g_malloc0(ops->size);
-    object_initialize(&xendev->qdev, ops->size, TYPE_XENBACKEND);
+    object_initialize(xendev, ops->size, TYPE_XENBACKEND);
     OBJECT(xendev)->free = g_free;
     qdev_set_id(DEVICE(xendev), g_strdup_printf("xen-%s-%d", type, dev),
                 &error_fatal);
diff --git a/hw/xen/xen_pvdev.c b/hw/xen/xen_pvdev.c
index c9143ba259..fe95b62d13 100644
--- a/hw/xen/xen_pvdev.c
+++ b/hw/xen/xen_pvdev.c
@@ -273,7 +273,7 @@ void xen_pv_del_xendev(struct XenLegacyDevice *xendev)
 
     QTAILQ_REMOVE(&xendevs, xendev, next);
 
-    qdev_unplug(&xendev->qdev, NULL);
+    qdev_unplug(DEVICE(xendev), NULL);
 }
 
 void xen_pv_insert_xendev(struct XenLegacyDevice *xendev)
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Mon Jan 27 09:44:45 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 09:44:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877516.1287644 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcLfg-0000YA-Ey; Mon, 27 Jan 2025 09:44:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877516.1287644; Mon, 27 Jan 2025 09:44:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcLfg-0000Y3-CR; Mon, 27 Jan 2025 09:44:44 +0000
Received: by outflank-mailman (input) for mailman id 877516;
 Mon, 27 Jan 2025 09:44:43 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=jIzP=UT=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tcLff-0000Xv-49
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 09:44:43 +0000
Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com
 [2607:f8b0:4864:20::62c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 540eb926-dc93-11ef-99a4-01e77a169b0f;
 Mon, 27 Jan 2025 10:44:41 +0100 (CET)
Received: by mail-pl1-x62c.google.com with SMTP id
 d9443c01a7336-2165448243fso90485055ad.1
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 01:44:40 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-72f8a76117esm6916617b3a.92.2025.01.27.01.44.37
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 27 Jan 2025 01:44:38 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 540eb926-dc93-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737971079; x=1738575879; 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=kVonSM/Ug3YBLXyCLFjlMi72TEyASV4Yre95V5cNK0M=;
        b=AMqTxs78EMrT45PlyxxikfaQ6gxyjV0UuLL0dajjHBscaSvQbdXcSDwbY8LhJ/oU2a
         hkjtOpFZogLjNoR77/LDqoYl4BfAFdXny9HFdv5E6g7BrBscCR3Jc8FZjUpZ9LHOpjwp
         HqIIZAANcf7ifoPmIWxgb3wGY8fFrzWTamKVc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737971079; x=1738575879;
        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=kVonSM/Ug3YBLXyCLFjlMi72TEyASV4Yre95V5cNK0M=;
        b=wFhxGCdrOTNNs2Hg+Z8HrgN9QFpUZqWmDLP+H1Xq87txhIa3p7DHi/uMjJeBHSOAhm
         Q6zFdvzpqufKCXfwldHgPLSxNFZH9DDT1f3Yf8Tf+2TTPIs80X5r13sosQ3s0MulZK3A
         8z7HsSjiciGdTzZJxQfcrrwVUWuGz549Wl01bCpZxc8RadtlD14oTYCD/e4gBeqRZueS
         Hgc1KCnpAaksiFxY9N/kg+wNVeL3wuaxn6jxmG4R8GTm9muR+3XB4iSlYEW39QsIQY9y
         W9Oqv2d5+f/yb3Posynrpuyd6LOsjOoEQSMUh9MbOgsOzil0cCu9tNm1Oyf7aWggzdmf
         pGLg==
X-Gm-Message-State: AOJu0Yz2CjFzMH/GijRwslbYOVGVzRiu4Q7DkKL+ymIDaDee9+tBvHNJ
	2mFYqjpzBSwlAcGuGKiOYn3GDDqnp4K08z/pwxALEkXZOGB8Adt72rkNLVyDHhA=
X-Gm-Gg: ASbGncuaaoWgi6Jqd8gWjJxORe2MAEVebWQnOIqp+AvD4nffTW5H24T2zTptReaRLdU
	9tCVMr7kdRXVCIW1Voep1fO+DRpV8dzHmeSQb96luRdsJkU891DsoljHeRTCTruycJp43WKjCjA
	YwysglXjm6JAllAG5+vzE0AGw/+e47RfKCCXwHuVsnzslSRWuQlze+DREC8Lh2r3a0gFU4q794f
	OxN+zlrS7Pw/mzQXGxKmjD/8YRrB958Kpegg9PGOaZ2WiKUgcLsWR9DIq7tZCJOrwQJZ90NUbZI
	69yTAhxJxMvYwAg=
X-Google-Smtp-Source: AGHT+IG8uG8XSZ/06Zw1jAP5Y1mbQYeUzLILKBtsWA4evNkgTHFQfBqPQfJh2z8Tw6X26Lop0+LKTQ==
X-Received: by 2002:a05:6a00:3c8a:b0:729:49a:2da6 with SMTP id d2e1a72fcca58-72daf9a6d2dmr61861798b3a.3.1737971079414;
        Mon, 27 Jan 2025 01:44:39 -0800 (PST)
Date: Mon, 27 Jan 2025 10:44:33 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Elliott Mitchell <ehem+xen@m5p.com>
Cc: xen-devel@lists.xenproject.org, Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: Serious AMD-Vi issue
Message-ID: <Z5dVgd3aF_n9Q3hZ@macbook.local>
References: <ZbLDlRi0vctlhsNp@mattapan.m5p.com>
 <Z5OkQgjd4Lt_rtr0@macbook.local>
 <Z5QFf5Ipk3GHd27H@mattapan.m5p.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <Z5QFf5Ipk3GHd27H@mattapan.m5p.com>

On Fri, Jan 24, 2025 at 01:26:23PM -0800, Elliott Mitchell wrote:
> On Fri, Jan 24, 2025 at 03:31:30PM +0100, Roger Pau Monné wrote:
> > On Thu, Jan 25, 2024 at 12:24:53PM -0800, Elliott Mitchell wrote:
> > > Apparently this was first noticed with 4.14, but more recently I've been
> > > able to reproduce the issue:
> > > 
> > > https://bugs.debian.org/988477
> > > 
> > > The original observation features MD-RAID1 using a pair of Samsung
> > > SATA-attached flash devices.  The main line shows up in `xl dmesg`:
> > > 
> > > (XEN) AMD-Vi: IO_PAGE_FAULT: DDDD:bb:dd.f d0 addr ffffff???????000 flags 0x8 I
> > 
> > I think I've figured out the cause for those faults, and posted a fix
> > here:
> > 
> > https://lore.kernel.org/xen-devel/20250124120112.56678-1-roger.pau@citrix.com/
> > 
> > Fix is patch 5/5, but you likely want to take them all to avoid
> > context conflicts.
> 
> I haven't tested yet, but some analysis from looking at the series.
> 
> This seems a plausible explanation for the interrupt IOMMU messages.  As
> such I think there is a good chance the reported messages will disappear.
> 
> Nothing in here looks plausible for solving the real problem, that of
> RAID1 mirrors diverging (almost certainly getting zeroes during DMA, but
> there is a chance stale data is being read).
> 
> Worse, since it removes the observed messages, the next person will
> almost certainly have severe data loss by the time they realize there is
> a problem.  Notably those messages lead me to Debian #988477, so I was
> able to take action before things got too bad.

I think it's the first time I get complains from the reported of a bug
after attempting to fix it.

Maybe my original message wasn't clear enough.  So far I consider the
IOMMU faults and the disk issues different bugs, and hence me asking
specifically whether the posted series make any different for any of
those issues.

I would be surprised if it also fixed the data loss issue, but wanted
to ask regardless.

> 
> 
> I'm not absolutely certain this is a pure Xen bug.  There is a
> possibility the RAID1 driver is reusing DMA buffers in a fashion which
> violates the DMA interface.  Yet there is also a good chance Xen isn't
> implementing its layer properly either.
> 
> 
> 
> There is one pattern emerging at this point.  Samsung hardware is badly
> effected, other vendors are either uneffected or mildly effected.
> Notably the estimated age of the devices meant to be handed off to
> someone able to diagnose the issue is >10 years.  The uneffected
> Crucial/Micron SATA device *should* drastically outperform these, yet
> instead it is uneffected.  The Crucial/Micron NVMe is very mildly
> effected, yet should be more than an order of magnitude faster.
> 
> The simplest explanation is the flash controller on the Samsung devices
> is lower latency than the one used by Micron.
> 
> 
> Both present reproductions feature AMD processors and ASUS motherboards.
> I'm doubtful of this being an ASUS issue.  This seems more likely a case
> of people who use RAID with flash tending to go with a motherboard vendor
> who reliably support ECC on all their motherboards.
> 
> I don't know whether this is confined to AMD processors, or not.  The
> small number of reproductions suggests few people are doing RAID with
> flash storage.  In which case no one may have tried RAID1 with flash on
> Intel processors.  On Intel hardware the referenced message would be
> absent and people might think their problem was distinct from Debian
> #988477.

As said above - my current hypothesis is that the IOMMU fault message
is just a red herring, and has nothing to do with the underlying data
loss issue that you are seeing.

I expect there will be no similar IOMMU fault message on Intel
hardware, as updating of interrupt remapping entries was already done
atomically on VT-d.

> In fact what seems a likely reproduction on Intel hardware is the Intel
> sound card issue.  I notice that issue occurs when sound *starts*
> playing.  When a sound device starts, its buffers would be empty and the
> first DMA request would be turned around with minimal latency.  In such
> case this matches the Samsung SATA devices handling DMA with low
> latency.

Can you reproduce the data loss issue without using RAID in Linux?
You can use fio with verify or similar to stress test it.

Can you reproduce if dom0 is PVH instead of PV?

Can you reproduce with dom0-iommu=strict mode in the Xen command line?

> 
> 
> > Can you give it a try and see if it fixes the fault messages, plus
> > your issues with the disk devices?
> 
> Ick.  I was hoping to avoid reinstalling the known problematic devices
> and simply send them to someone better setup for analyzing x86 problems.
> 
> Looking at the series, it seems likely to remove the fault messages and
> turn this into silent data loss.  I doubt any AMD processors have an
> IOMMU, yet omit cmpxchg16b (older system lacked full IOMMU, yet did have
> cmpxchg16b, newer system has both).  Even guests have cmpxchg16b
> available.

Silent data loss> data loss might or not be there, regardless of whether
IOMMU faults are being reported.  IMO it's unhelpful to make this kind of
comments, as you seem to suggest a preference for leaving the IOMMU
fault bug unfixed, which I'm sure it's not the case.

> If you really want this tested, it will be a while before the next
> potential downtime window.

No worries, I already have confirmation from someone else that was
seeing the same IOMMU faults has tested the fix.  I was mostly
wondering whether it would affect your data loss issues in any way, as
for that I have no one else that can reproduce.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 09:46:16 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 09:46:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877526.1287655 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcLh9-00019h-SS; Mon, 27 Jan 2025 09:46:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877526.1287655; Mon, 27 Jan 2025 09:46:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcLh9-00019a-Os; Mon, 27 Jan 2025 09:46:15 +0000
Received: by outflank-mailman (input) for mailman id 877526;
 Mon, 27 Jan 2025 09:46: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 <SRS0=wC6S=UT=gmail.com=shentey@srs-se1.protection.inumbo.net>)
 id 1tcLh8-00019S-AB
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 09:46:14 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8b991408-dc93-11ef-a0e6-8be0dac302b0;
 Mon, 27 Jan 2025 10:46:13 +0100 (CET)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-ab651f1dd36so841494366b.0
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 01:46:13 -0800 (PST)
Received: from [127.0.0.1] (dynamic-093-128-047-181.93.128.pool.telefonica.de.
 [93.128.47.181]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab675e12505sm564891866b.17.2025.01.27.01.46.11
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 01:46:12 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8b991408-dc93-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1737971173; x=1738575973; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:references
         :in-reply-to:subject:cc:to:from:date:from:to:cc:subject:date
         :message-id:reply-to;
        bh=musWy1n7TogM8KXZsXOnvhQhrXqQAkckhg6RXEq4Bko=;
        b=MLJXYiiBPknbl7u+9JuYpUu3chjWtDswYCfQ+tHjci/W0eccFnTeQZI4IdLT4nPaLo
         8o1MTfsHG4ubGCqSvuPCsrQ3wL25n/xQKyox3JkqD97fl4/6QTa6fi7IQOYYEYAkcBEX
         oUlVt72PJi1u1ye+X3ujrU26FJOIMlh7rUuvIbD6S4ENkKX7qWvnCoSZ4OOvlxmSOQAR
         XGzvjYWqAxLcvwgE6+sJoEuD3RlaUpbk3tbUB/DT8fdqf/yYNaORqQ727h/A9oT3ki7B
         9W61aZgPyjm2GazJCApplCNXlU3CctQAbVd8RXVrtweW7ddg70af1NGqaK2v127aFYKV
         ZlHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737971173; x=1738575973;
        h=content-transfer-encoding:mime-version:message-id:references
         :in-reply-to:subject:cc:to:from:date:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=musWy1n7TogM8KXZsXOnvhQhrXqQAkckhg6RXEq4Bko=;
        b=BAvllIri0qXBQYsX/HuDF8Z4FXrZ25Ocyad+aagcNgAAfcsS6yDRuPiXvxkUKXoVJm
         WOw5pgAAiJElGpH5K1MJEsaV2DBheUHy+RQYn3EYos5C+FSo/wJHkzb7Q08Rx9ZvFbTu
         y2X6zMsLkmC0HyydU3/yTo0dIRWMrvkFcoulnZjoyoFgqGJKHw44juFQlptYMWBltmQZ
         1Dx+ro785Rz8v+ybAWkEG4hKrMu71iKqzxSBGBHbrDYDxYONNX4bAPy7iWMYLZpDu0t0
         Qa1nayw6ttYNVeNYcWClx3gbVUxQdeYX3azIcKWc9cZA1mvscngfjmKtJqRLPwCQW5VT
         Dl8g==
X-Forwarded-Encrypted: i=1; AJvYcCXIoMFA1TaVoXsezjfmzBJaI3MlBp0Sm1umAOQ4Dv/n+jmIsvDGpRepGieG1nAcHMDcERqc9qtjd40=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyMfpU174EFZZN+ZmxHR36uat/EtM5slnKXorfUJT9FTER4ca8e
	29VttGfnPva7g4NmkuE0ha9GBJgEG2DyPki3CUQebOdYeDNu2EOb
X-Gm-Gg: ASbGncs80RjjS2DIysuBqmGt+MqWxjFJ93h8/EM9NT7kDEr3ymmkpKTFkrpfhYDaH/R
	sPi1J+H34DT6EVBLC4fXRP/TQRW70dFqo3pVweZ4HtrkXAeyECppDPoV4ys3+C+9/0eaGttIXP4
	ytTpckfoc97xXHpk5+1vPS2lwJu+F/E94rPVtnVLKW2ad9auHZNsToPzXGsiOo/3K/sOERZFtn4
	xyukvuH8o92fHPxfM/hvIqsKiHFOAKoVCZ8O7+grpKhwjWewhuFK2C4+9KgYry7OM4z3AvtLBIo
	4vO1FATAYaKHytxwkDlUEjoZhiCLoY9EUz1V8YU08Zhp7gwmItjIUuvz
X-Google-Smtp-Source: AGHT+IHG0IaOyPVMUP/MqBB9v9/fX+0a85D1lpF7KinDYCL9eJYDjqGVvqsM8FHH5W5762wb2tK/pA==
X-Received: by 2002:a17:907:6ea4:b0:ab2:bffb:4b5c with SMTP id a640c23a62f3a-ab38b24bd9emr3486146266b.18.1737971172417;
        Mon, 27 Jan 2025 01:46:12 -0800 (PST)
Date: Mon, 27 Jan 2025 09:46:12 +0000
From: Bernhard Beschow <shentey@gmail.com>
To: =?ISO-8859-1?Q?Philippe_Mathieu-Daud=E9?= <philmd@linaro.org>,
 qemu-devel@nongnu.org
CC: Yi Liu <yi.l.liu@intel.com>, Markus Armbruster <armbru@redhat.com>,
 Eduardo Habkost <eduardo@habkost.net>,
 Anthony PERARD <anthony@xenproject.org>,
 Gustavo Romero <gustavo.romero@linaro.org>, Jason Wang <jasowang@redhat.com>,
 qemu-ppc@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>,
 Paolo Bonzini <pbonzini@redhat.com>, Alexander Graf <graf@amazon.com>,
 Richard Henderson <richard.henderson@linaro.org>,
 Stefan Berger <stefanb@linux.vnet.ibm.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Gerd Hoffmann <kraxel@redhat.com>,
 =?ISO-8859-1?Q?Daniel_P=2E_Berrang=E9?= <berrange@redhat.com>,
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
 xen-devel@lists.xenproject.org,
 Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
 Alex Williamson <alex.williamson@redhat.com>, Paul Durrant <paul@xen.org>,
 =?ISO-8859-1?Q?Cl=E9ment_Mathieu--Drif?= <clement.mathieu--drif@eviden.com>,
 =?ISO-8859-1?Q?C=E9dric_Le_Goater?= <clg@redhat.com>
Subject: =?US-ASCII?Q?Re=3A_=5BRFC_PATCH_9/9=5D_hw/xen=3A_Have_legacy_Xen?=
 =?US-ASCII?Q?_backend_inherit_from_DYNAMIC=5FSYS=5FBUS=5FDEVICE?=
In-Reply-To: <20250125181343.59151-10-philmd@linaro.org>
References: <20250125181343.59151-1-philmd@linaro.org> <20250125181343.59151-10-philmd@linaro.org>
Message-ID: <9A2B297A-6270-4482-B1B6-81F518C07C1E@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable



Am 25=2E Januar 2025 18:13:43 UTC schrieb "Philippe Mathieu-Daud=C3=A9" <p=
hilmd@linaro=2Eorg>:
>Because the legacy Xen backend devices can optionally be plugged on the
>TYPE_PLATFORM_BUS_DEVICE, have it inherit TYPE_DYNAMIC_SYS_BUS_DEVICE=2E
>Remove the implicit TYPE_XENSYSDEV instance_size=2E
>
>Untested, but I'm surprised the legacy devices work because they
>had a broken instance size (QDev instead of Sysbus=2E=2E=2E), so accesses
>of XenLegacyDevice fields were overwritting sysbus ones=2E
>
>Signed-off-by: Philippe Mathieu-Daud=C3=A9 <philmd@linaro=2Eorg>
>---
> include/hw/xen/xen_pvdev=2Eh  | 3 ++-
> hw/xen/xen-legacy-backend=2Ec | 7 ++-----
> 2 files changed, 4 insertions(+), 6 deletions(-)
>
>diff --git a/include/hw/xen/xen_pvdev=2Eh b/include/hw/xen/xen_pvdev=2Eh
>index 0c984440476=2E=2E48950dc2b57 100644
>--- a/include/hw/xen/xen_pvdev=2Eh
>+++ b/include/hw/xen/xen_pvdev=2Eh
>@@ -32,7 +32,8 @@ struct XenDevOps {
> };
>=20
> struct XenLegacyDevice {
>-    DeviceState        qdev;
>+    SysBusDevice parent_obj;

This then needs sysbus=2Eh rather than qdev-core=2Eh include=2E

Moreover, the patch in the reply needs to be inserted into the series befo=
re this patch=2E

Both are needed for the patch to compile=2E

Best regards,
Bernhard

>+
>     const char         *type;
>     int                dom;
>     int                dev;
>diff --git a/hw/xen/xen-legacy-backend=2Ec b/hw/xen/xen-legacy-backend=2E=
c
>index 118c571b3a7=2E=2E4d079e35d83 100644
>--- a/hw/xen/xen-legacy-backend=2Ec
>+++ b/hw/xen/xen-legacy-backend=2Ec
>@@ -640,16 +640,14 @@ static void xendev_class_init(ObjectClass *klass, v=
oid *data)
>     DeviceClass *dc =3D DEVICE_CLASS(klass);
>=20
>     set_bit(DEVICE_CATEGORY_MISC, dc->categories);
>-    /* xen-backend devices can be plugged/unplugged dynamically */
>-    dc->user_creatable =3D true;
>     dc->bus_type =3D TYPE_XENSYSBUS;
> }
>=20
> static const TypeInfo xendev_type_info =3D {
>     =2Ename          =3D TYPE_XENBACKEND,
>-    =2Eparent        =3D TYPE_DEVICE,
>+    =2Eparent        =3D TYPE_DYNAMIC_SYS_BUS_DEVICE,
>     =2Eclass_init    =3D xendev_class_init,
>-    =2Einstance_size =3D sizeof(struct XenLegacyDevice),
>+    =2Einstance_size =3D sizeof(XenLegacyDevice),
> };
>=20
> static void xen_sysbus_class_init(ObjectClass *klass, void *data)
>@@ -672,7 +670,6 @@ static const TypeInfo xensysbus_info =3D {
> static const TypeInfo xensysdev_info =3D {
>     =2Ename          =3D TYPE_XENSYSDEV,
>     =2Eparent        =3D TYPE_SYS_BUS_DEVICE,
>-    =2Einstance_size =3D sizeof(SysBusDevice),
> };
>=20
> static void xenbe_register_types(void)


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 09:51:34 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 09:51:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877538.1287664 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcLmE-00031J-Dl; Mon, 27 Jan 2025 09:51:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877538.1287664; Mon, 27 Jan 2025 09:51:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcLmE-00031C-Ay; Mon, 27 Jan 2025 09:51:30 +0000
Received: by outflank-mailman (input) for mailman id 877538;
 Mon, 27 Jan 2025 09:51:29 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=O4xJ=UT=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcLmD-000314-Ob
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 09:51:29 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 46df4ce6-dc94-11ef-99a4-01e77a169b0f;
 Mon, 27 Jan 2025 10:51:27 +0100 (CET)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-aa684b6d9c7so756286366b.2
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 01:51:27 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab675e653d1sm561965966b.68.2025.01.27.01.51.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 01:51:26 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 46df4ce6-dc94-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737971487; x=1738576287; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=lrBbF5qHfbmKyavcLCgu8dtq45YUT36r9UYamUvvmlM=;
        b=F6W5HKtRU11XGyGyWSn35TegbTBZzbfOH16hGrbo+C5Wrx5Un7mIHlMxU1uV4pBdD/
         7Q9/GSU6qXL4u4rXbMOJooujH7o6VS78B81D0ri3u7+EKpJjalkbOeBFeo6amqwGEVDT
         IlXql+ozhEpPopCL1li9YiIghb21vEvSdLAkGETHKeL6Ogu4XexWpNemrgoHri1bq1wh
         DbDeMQaojyXjrw7YZQEEKFhyQFppdwfJNbxje0AuQeZtcyBxm1Hm3RVK63eaevHbDrGd
         sgTgu00t57fKEJ9Nt+8TX+UYxd3+V4jRWRqQ8otFsuo2aBctHzLK162gH5RSX6PqMeJQ
         MceA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737971487; x=1738576287;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=lrBbF5qHfbmKyavcLCgu8dtq45YUT36r9UYamUvvmlM=;
        b=UlgX9xnvvulVZkCNbiiIWuCHARQbDcu0DUvEDzWmXXp1xdB0ZJHxnAm8rGCIi7jjar
         orMM/tuDupJxr2GOKx9tainVIbEyPKwq7UggnDWMb5P9ALKXbYTdgZcNPCQSc2OK2TCW
         egLJseZz7/qVibsnsdgVQB96cI6OeJ4bjN9T5erYxEvFXVnIoVfbEt3YSakdBqejBqs8
         pnZvqCzTTD8J1mkLMt53cc3uwnS2oSbwzbmLZaWKalNH3qxyXz1AmxSXAPg6YiaKHxLo
         Ib4UEycjPoxITuRv4dLd/KqRNB0/CPNyAkzGvtmnc12gYO1s7hCv6z7Fi7MOnFiMmexg
         WOuA==
X-Forwarded-Encrypted: i=1; AJvYcCXeYlcJEiJqk22ea02Ihd0+/fDMog4l8gtHVj2PhOQxL0YrdduKdBuMAC2dyqo3nvbOlfWns2wGMc0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwtfGhnO9ZpbKZJz6C1MvEHymt2e2iemUDkslGSg71Dvh7dC1ao
	9kP+GvfVf2pUIVbZ+MAppxBuEyvUw4gn6XrwqpmUusp6Nxmh61+FnvJUG667dg==
X-Gm-Gg: ASbGncu8s9uSb2f98CW2YQVvjWgWqxtQyaqTZ04h1zUgsEqKxNIJ5jfu0/4kiq4uFX8
	D59SYGtMUwk/eZf3wFhviFx9U+4FKl3prbT4AgLyfbWGuSzXkswuH3fpwxBc0gw+Pr8rHGaWgWp
	Hrn7iegssgeAs4+2Kni75F3wJ3zZbHLGzJpQg/6RCb6mUxJIWj0IplM+MqHfmzxciKOol4a/qio
	Y4sQv0Ef7C7hkPru3FO9vqN6hvWU3k7VcXO2EpswiIgDtwBCKy1B/fJfq9CaRlYkUCpTHdGcou2
	0gMlKxrArxSypdPgCVtIQQ0niqQTQuKonzrUpVYGR2vCnjDwA6XHnIoRyBe7OIftrw==
X-Google-Smtp-Source: AGHT+IH5B+oFKNQRoW8fUPl/+ONhqLRW2+Gvif/SdN9KvVL5/xj+i9PoyogZIsz+6lvmllnjDiajBg==
X-Received: by 2002:a17:906:7314:b0:ab2:f5cb:c039 with SMTP id a640c23a62f3a-ab38b48ae9amr3656137466b.54.1737971486882;
        Mon, 27 Jan 2025 01:51:26 -0800 (PST)
Message-ID: <ef73e2fd-69ae-4cf0-a8d2-785a2b248d63@suse.com>
Date: Mon, 27 Jan 2025 10:51:29 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/5] x86/iommu: check for CMPXCHG16B when enabling
 IOMMU
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: Teddy Astie <teddy.astie@vates.tech>,
 Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xenproject.org
References: <20250124120112.56678-1-roger.pau@citrix.com>
 <20250124120112.56678-2-roger.pau@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250124120112.56678-2-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 24.01.2025 13:01, Roger Pau Monne wrote:
> From: Teddy Astie <teddy.astie@vates.tech>
> 
> All hardware with VT-d/AMD-Vi has CMPXCHG16B support. Check this at
> initialisation time, and remove the effectively-dead logic for the
> non-cx16 case.

Nit: There's nothing being removed here, so I expect the 2nd half of the
sentence wants dropping.

Jan

> If the local APICs support x2APIC mode the IOMMU support for interrupt
> remapping will be checked earlier using a specific helper.  If no support
> for CX16 is detected by that earlier hook disable the IOMMU at that point
> and prevent further poking for CX16 later in the boot process, which would
> also fail.
> 
> There's a possible corner case when running virtualized, and the underlying
> hypervisor exposing an IOMMU but no CMPXCHG16B support.  In which case
> ignoring the IOMMU is fine, albeit the most natural would be for the
> underlying hypervisor to also expose CMPXCHG16B support if an IOMMU is
> available to the VM.
> 
> Note this change only introduces the checks, but doesn't remove the now
> stale checks for CX16 support sprinkled in the IOMMU code.  Further changes
> will take care of that.
> 
> Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> ---
> Changes since pickup:
>  - Unify all CX16 checks into a single patch.
> ---
>  xen/drivers/passthrough/amd/iommu_intr.c    | 13 +++++++++++++
>  xen/drivers/passthrough/amd/pci_amd_iommu.c |  6 ++++++
>  xen/drivers/passthrough/vtd/intremap.c      | 13 +++++++++++++
>  xen/drivers/passthrough/vtd/iommu.c         |  7 +++++++
>  4 files changed, 39 insertions(+)
> 
> diff --git a/xen/drivers/passthrough/amd/iommu_intr.c b/xen/drivers/passthrough/amd/iommu_intr.c
> index 7fc796dec25b..f07fd9e3d970 100644
> --- a/xen/drivers/passthrough/amd/iommu_intr.c
> +++ b/xen/drivers/passthrough/amd/iommu_intr.c
> @@ -649,6 +649,19 @@ bool __init cf_check iov_supports_xt(void)
>      if ( !iommu_enable || !iommu_intremap )
>          return false;
>  
> +    if ( unlikely(!cpu_has_cx16) )
> +    {
> +        AMD_IOMMU_ERROR("no CMPXCHG16B support, disabling IOMMU\n");
> +        /*
> +         * Disable IOMMU support at once: there's no reason to check for CX16
> +         * yet again when attempting to initialize IOMMU DMA remapping
> +         * functionality or interrupt remapping without x2APIC support.
> +         */
> +        iommu_enable = false;
> +        iommu_intremap = iommu_intremap_off;
> +        return false;
> +    }
> +
>      if ( amd_iommu_prepare(true) )
>          return false;
>  
> diff --git a/xen/drivers/passthrough/amd/pci_amd_iommu.c b/xen/drivers/passthrough/amd/pci_amd_iommu.c
> index 73dcc4a2dd0c..f96f59440bcc 100644
> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
> @@ -309,6 +309,12 @@ static int __init cf_check iov_detect(void)
>      if ( !iommu_enable && !iommu_intremap )
>          return 0;
>  
> +    if ( unlikely(!cpu_has_cx16) )
> +    {
> +        AMD_IOMMU_ERROR("no CMPXCHG16B support, disabling IOMMU\n");
> +        return -ENODEV;
> +    }
> +
>      if ( (init_done ? amd_iommu_init_late()
>                      : amd_iommu_init(false)) != 0 )
>      {
> diff --git a/xen/drivers/passthrough/vtd/intremap.c b/xen/drivers/passthrough/vtd/intremap.c
> index c504852eb818..233db5cb64de 100644
> --- a/xen/drivers/passthrough/vtd/intremap.c
> +++ b/xen/drivers/passthrough/vtd/intremap.c
> @@ -150,6 +150,19 @@ bool __init cf_check intel_iommu_supports_eim(void)
>      if ( !iommu_qinval || !iommu_intremap || list_empty(&acpi_drhd_units) )
>          return false;
>  
> +    if ( unlikely(!cpu_has_cx16) )
> +    {
> +        printk(XENLOG_ERR VTDPREFIX "no CMPXCHG16B support, disabling IOMMU\n");
> +        /*
> +         * Disable IOMMU support at once: there's no reason to check for CX16
> +         * yet again when attempting to initialize IOMMU DMA remapping
> +         * functionality or interrupt remapping without x2APIC support.
> +         */
> +        iommu_enable = false;
> +        iommu_intremap = iommu_intremap_off;
> +        return false;
> +    }
> +
>      /* We MUST have a DRHD unit for each IOAPIC. */
>      for ( apic = 0; apic < nr_ioapics; apic++ )
>          if ( !ioapic_to_drhd(IO_APIC_ID(apic)) )
> diff --git a/xen/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/vtd/iommu.c
> index 27a4d1640189..3daedc4f5593 100644
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -2633,6 +2633,13 @@ static int __init cf_check vtd_setup(void)
>      int ret;
>      bool reg_inval_supported = true;
>  
> +    if ( unlikely(!cpu_has_cx16) )
> +    {
> +        printk(XENLOG_ERR VTDPREFIX "no CMPXCHG16B support, disabling IOMMU\n");
> +        ret = -ENODEV;
> +        goto error;
> +    }
> +
>      if ( list_empty(&acpi_drhd_units) )
>      {
>          ret = -ENODEV;



From xen-devel-bounces@lists.xenproject.org Mon Jan 27 09:52:51 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 09:52:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877545.1287676 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcLnU-0003rM-QH; Mon, 27 Jan 2025 09:52:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877545.1287676; Mon, 27 Jan 2025 09:52:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcLnU-0003rF-Kk; Mon, 27 Jan 2025 09:52:48 +0000
Received: by outflank-mailman (input) for mailman id 877545;
 Mon, 27 Jan 2025 09:52: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 <SRS0=O4xJ=UT=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcLnT-0003r5-Ei
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 09:52:47 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 75b981d8-dc94-11ef-a0e6-8be0dac302b0;
 Mon, 27 Jan 2025 10:52:46 +0100 (CET)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-5db689a87cbso8496135a12.3
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 01:52: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
 a640c23a62f3a-ab6760fbc99sm563124866b.145.2025.01.27.01.52.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 01:52:45 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 75b981d8-dc94-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737971565; x=1738576365; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=5M2E1AkkkWgWZtZwdKL1Yi0bCFjwUkgo3HRAIXK7BEQ=;
        b=cWjeG5lgOFfUALrpr//DtF6ru9n5flTtW2R0ad7wDFSm4xbPQ1d7HGLy7kuQvsxPgh
         6y+kll9X1GxdR12Cdo3pDmQJt01N89fTGt/KLQivF7VEfJw6twruWOWoChLZKs8/K8HV
         hwctHAvtzbn//RTPfDuPFUADf3MJ2e6EtDw0QQc11LnP2c2MArtkmYqN2vf7F0AsP97u
         VEAhkIJVhAFCD3CixTaH8JGLG9RM9gg+Vt6dj3Szg6iUXOugOoVn0G00EpH0T+UZp5AP
         +6T7LRnJE4ULaPFY8OiWiPo2n1GSWSSlasZdi2MV1tGwFlAjxa57yEefcYZq2kXwAmb3
         LIqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737971565; x=1738576365;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=5M2E1AkkkWgWZtZwdKL1Yi0bCFjwUkgo3HRAIXK7BEQ=;
        b=Nqm56JpMGmKYudmsvWFlYt6pubu4jSADF5xX5+2BNAj8lIMT0XV+esMjbFL6kVS/6V
         hJeVRYED4gO6dFFQxWqTDvGqhTZocC4lLwMnIm3UNkZgpUbS1vyKQd2vtCJckSKcgxjs
         b/MvnZBMPNfngVxuivBbQFrLiHavEr4dMhOwC0LMHJL0sNvUOd9wi4lySPzRsgG+EXhX
         nd6lsltlUVnPFGGsrfBqUqDBLdb0qpheITnSG4Jzwg5FXNcmDYlxW7Pm741SveqzwwaZ
         uBqm2e01aU+Kj/AU3uwPcJaC/OVDdLCmum7qYZtERcwEmM2nuJ3NwHYdf+aZZYA6FE0k
         eClg==
X-Forwarded-Encrypted: i=1; AJvYcCV6riJ8vXV5gzkhR+Xq/ZGv3T1sibsBqloML/wslEmi6MMXNcPpXSUee1zzPWvzzdfG03NBu9cr1Tk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxKpzAQbP5JAIKp+iB/wO8XdZmlhQyxW4DfVKsAPbkFgnRRwi9M
	0fDiPKHCl1tHwqHgkrAM61eHDkkIgDkRbM0AN196tCCBQe13l57VywbVglb9YQ==
X-Gm-Gg: ASbGncvAIH9MUhnS7CUW2n2oSI4Y/yGDTX+RbJ5OOhy/0PH+XKrP861pnFP3urmf0ZJ
	9CXv5KlpEkBqTyBr+Jwu88jCaDkedQHD6Leqx/hFcFvqQH/nycUYlMtMHZcVxgc19YX7vgoh1Tm
	Rp87xi8XC2Jg+RSA4tEUWL2cDJERkBXlhSQokQFJ0hEtu53CQGNxYEDPPBacI1qhAzQ4oFIPZUF
	torZdIC8RBLVd8TIw1Q5+SyimBeKxKEDJywwE95eukKQdtahSNeHTRRECl0kSF0xIStXQt8jnCu
	z5dAFlVu4WiImyGQA3Mt6w3f+tOkfie2+67kCWVE5UJcUM7CREDNMbLs5GsgwbIxbQ==
X-Google-Smtp-Source: AGHT+IEOS0gkaKPanKwaw5CcR07g8/MqPbS7atMUmzLmH8awyOus7kkmq/Tz18+pIU6XLns+PbJxnw==
X-Received: by 2002:a17:907:7eaa:b0:aac:4324:977e with SMTP id a640c23a62f3a-ab38b163018mr4375245666b.27.1737971565546;
        Mon, 27 Jan 2025 01:52:45 -0800 (PST)
Message-ID: <5395ceb7-60a0-471f-ab23-451ac7937873@suse.com>
Date: Mon, 27 Jan 2025 10:52:47 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/5] iommu/vtd: remove non-CX16 logic from interrupt
 remapping
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: Teddy Astie <teddy.astie@vates.tech>,
 Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xenproject.org
References: <20250124120112.56678-1-roger.pau@citrix.com>
 <20250124120112.56678-3-roger.pau@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250124120112.56678-3-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 24.01.2025 13:01, Roger Pau Monne wrote:
> From: Teddy Astie <teddy.astie@vates.tech>
> 
> As CX16 support is mandatory for IOMMU usage, the checks for CX16 in the
> interrupt remapping code are stale.  Remove them together with the
> associated code introduced in case CX16 was not available.

Perhaps insert "now" before "mandatory" (then also in patch 3)?

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 10:04:07 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 10:04:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877555.1287684 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcLyN-0006TN-Lq; Mon, 27 Jan 2025 10:04:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877555.1287684; Mon, 27 Jan 2025 10:04:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcLyN-0006TG-JL; Mon, 27 Jan 2025 10:04:03 +0000
Received: by outflank-mailman (input) for mailman id 877555;
 Mon, 27 Jan 2025 10:04:02 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=jIzP=UT=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tcLyM-0006T8-Kq
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 10:04:02 +0000
Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com
 [2607:f8b0:4864:20::633])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 07a73085-dc96-11ef-a0e6-8be0dac302b0;
 Mon, 27 Jan 2025 11:04:01 +0100 (CET)
Received: by mail-pl1-x633.google.com with SMTP id
 d9443c01a7336-2162c0f6a39so93284765ad.0
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 02:04:01 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-ac495d5790dsm5995332a12.60.2025.01.27.02.03.58
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 27 Jan 2025 02:03:59 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 07a73085-dc96-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737972239; x=1738577039; 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=RwNshmp+CHvpCBavfOKUzNpKUjOofXHONCaz+lyP0a4=;
        b=iPwd2XbCKLww86PbOVXChd74hQkq/FwV+eFD49ooGaeou4k8v8Kk9+PEhtI88hyJHZ
         8R1JzJWYYFNH8zGpH4cLDPwnvhwcLyvVLKC/ubobtyFp1WgOFpV8uO5aiggfC3gXEOPI
         zA0sqvT3rhfw82/xX+Yb1OzAUxiioTIzd5/78=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737972239; x=1738577039;
        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=RwNshmp+CHvpCBavfOKUzNpKUjOofXHONCaz+lyP0a4=;
        b=dCfRgOZFpB543xsxcCgbh/NHUrO4JmPBME7DF2dNlzqFqIdXOmXdTqfeRANJpT672U
         oSiBo4HvfpxsPIDSmgg5iW9qkVcWOciRXCyg/C540a//jnGYkhlYDRGP8uU0+Xe0u4dg
         DR1sDtlWXgfCnkcbVWPjyOax11GarslzoPjo6yuzUjU/pUqdFc0E5Glbq9uJjeuk4II5
         8100bR7DQwKaKeuaBgZglqCw6vCNahgNkB0EsgMM7oVY6gg8m7sUIW2q+RmiJkM79d/j
         CAkdlw5fN72a9YIEOLcntQ8Zvoo9oyG4Sz+jSr5joBylKMQJBCEDQiSZCrn/yPlHNWTI
         hW9A==
X-Forwarded-Encrypted: i=1; AJvYcCXMFfrBmaRcBTU/Yplzx/gil0PUAjHMa2cD68zbucU8yi2kYDUyEzb7wH0s4wYiUqci1kLTEWy4kcM=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyv3c4aPQgAt3U5SQql/05YX9qpN5Y1194pNMmnMkrVnxIRuhBr
	YlTUjpvJokrBv80mVOjvUxZlE1nAhjSfyOTuIzo2KHwQmgRVs23dFgrhgyC2O0o=
X-Gm-Gg: ASbGncstz1LndFBDq2WVAEnzZjeicIWu43PKro8uIPTy2wbpptUjeKjiqYSb+D0J53C
	pBm4djDc6PWgN8WTgvoK2tIU4Xop2ms/RnB/94fZPO12r0Va1LI/ZHAQ3yiD+C2UNxvSVo/cQik
	F+h9MsHPpYYCe6XERQIT4f4GWFyDzJ+9oCRp/6+R3+02qBh3M7ZsWwzWb4+rT59IoAHCCdURg6h
	WtIZOUch3f/52qPZoyaG+yti7oEIqqdYMsR2zPsq3X5xTXwCcujrQhOzeb8BTL9+B+ncnRjBZJE
	1oqycW3s8/nYOwg=
X-Google-Smtp-Source: AGHT+IELQ3FPsKcgrjAUYcZujAx4M8QxjWZzSaer374cC+eJyajOzfemCBPayPDLRw3ihpaAqbt3VA==
X-Received: by 2002:a05:6a21:8ccc:b0:1e3:c763:74d4 with SMTP id adf61e73a8af0-1eb76a38d2cmr19926285637.0.1737972239674;
        Mon, 27 Jan 2025 02:03:59 -0800 (PST)
Date: Mon, 27 Jan 2025 11:03:53 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Teddy Astie <teddy.astie@vates.tech>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 1/5] x86/iommu: check for CMPXCHG16B when enabling
 IOMMU
Message-ID: <Z5daCYobAizsHyYN@macbook.local>
References: <20250124120112.56678-1-roger.pau@citrix.com>
 <20250124120112.56678-2-roger.pau@citrix.com>
 <ef73e2fd-69ae-4cf0-a8d2-785a2b248d63@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <ef73e2fd-69ae-4cf0-a8d2-785a2b248d63@suse.com>

On Mon, Jan 27, 2025 at 10:51:29AM +0100, Jan Beulich wrote:
> On 24.01.2025 13:01, Roger Pau Monne wrote:
> > From: Teddy Astie <teddy.astie@vates.tech>
> > 
> > All hardware with VT-d/AMD-Vi has CMPXCHG16B support. Check this at
> > initialisation time, and remove the effectively-dead logic for the
> > non-cx16 case.
> 
> Nit: There's nothing being removed here, so I expect the 2nd half of the
> sentence wants dropping.

Yes, that was a copy & paste from the following patch.  Will drop the
last part of the sentence.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 10:04:34 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 10:04:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877564.1287694 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcLys-000715-14; Mon, 27 Jan 2025 10:04:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877564.1287694; Mon, 27 Jan 2025 10:04:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcLyr-00070y-UZ; Mon, 27 Jan 2025 10:04:33 +0000
Received: by outflank-mailman (input) for mailman id 877564;
 Mon, 27 Jan 2025 10:04:32 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=jIzP=UT=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tcLyq-0006T8-3s
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 10:04:32 +0000
Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com
 [2607:f8b0:4864:20::102a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 19c63e17-dc96-11ef-a0e6-8be0dac302b0;
 Mon, 27 Jan 2025 11:04:31 +0100 (CET)
Received: by mail-pj1-x102a.google.com with SMTP id
 98e67ed59e1d1-2eec9b3a1bbso5714349a91.3
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 02:04:31 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-2f7ffa49225sm6705332a91.9.2025.01.27.02.04.28
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 27 Jan 2025 02:04:29 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 19c63e17-dc96-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737972270; x=1738577070; 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=pX0/qUEd7ANo7X6r/6O/NY9oboJ6WoFPfvzM5ggo64s=;
        b=lWZz9j+YQFLQAaVlDVTr/kOhp5VZU+HvHMUBOxLblAUH4HSCchg51hzTl7I8BpcGGq
         xsP3SC9HRDSswxikIWDjcseYF79iNBIukieuK4moq3q/KdofCWNBVydDcT8ThWs4WSGm
         bZjL1f/xhS9ogIaGfVpATP4sEr58PNgjaYCgY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737972270; x=1738577070;
        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=pX0/qUEd7ANo7X6r/6O/NY9oboJ6WoFPfvzM5ggo64s=;
        b=rItlg3/BOBanaGIbiteK+r4nv7uV5DmD+7nOUzQEPi2lCgl/Hq1Y1C4CdJ/49nCerk
         nUqG1GvsFDa/QWcjoTRFLOoPGi5g0hliYKhGJaXKTayKc9IRJEq0xViWM/4deobQnxht
         3Umt6l+UF2TsYEV/4vZVDMKVyxT8WXa0/f2q6v3Ha8SsuTkpBBb4ty/B72qDCmyzg/39
         lkGpjyfqp4wbpqf4mEHWmtER8Cotm39vCHf46FFrEwhwJAQxYvo8PQ7YneEoEKmJqI3R
         1nk+ZGWUfKpgvTzH3tUMvX0vT6Ki1btd7qPWvM/TonGLwABzi2urdow/6C2QyTldRjOp
         WE0g==
X-Forwarded-Encrypted: i=1; AJvYcCXFo24LwmeEl1hk/MAgrna89PPmLSJdCqECOUi2U2Ld7J7kZB38U4iw7Kn/TNjdkVmsEAGAxnU7Qas=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzbTmbe8KkUNFECvRuBXj0XoAD76zsWFUqu5c1G7tPCH0LUi0N7
	ELIgZZdJat5KDk2Jrnc1pDABj36Z2qY35YhVMftAYhaVFCg2ZjzQpERyxPyZiU0=
X-Gm-Gg: ASbGncvd52WS61RIL8PpWGt+cn8URm2Lwvrx1sKmG0pHBdzgz/4zXK8mND+NqtmgFkA
	s4K09wUwNmQRSRHDgciXh/uRh6SBhcfx8g7Be3eIBttEDbGLscE9w9uWIWCltk4ZPHaTNKRhwlz
	6WdCB0W5JgsbJvL1sFclXDUcgxnDhKCE85TarA11nTsBVk7jVikiWRgymL3Cwy+WGs2zjXKdAb7
	JCDbBiDU8H0TO1cmuxvAnbXi17yDkLpHLyiZaE3VEEzUASsQg3oss8XbYtsKocR01upzxzGbEZe
	tU1zTFFk4b7iSQA=
X-Google-Smtp-Source: AGHT+IHj6shJN442tHY2Y15siUQ1oeCIHxCLHUh1aM7+1qc1YxN4mN8KGhr1KhXEkj6zh5mx9MaHXA==
X-Received: by 2002:a17:90b:54ce:b0:2f6:d266:f467 with SMTP id 98e67ed59e1d1-2f782d9eb89mr51815166a91.34.1737972270175;
        Mon, 27 Jan 2025 02:04:30 -0800 (PST)
Date: Mon, 27 Jan 2025 11:04:25 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Teddy Astie <teddy.astie@vates.tech>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 2/5] iommu/vtd: remove non-CX16 logic from interrupt
 remapping
Message-ID: <Z5daKcD2hwIfqC8M@macbook.local>
References: <20250124120112.56678-1-roger.pau@citrix.com>
 <20250124120112.56678-3-roger.pau@citrix.com>
 <5395ceb7-60a0-471f-ab23-451ac7937873@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <5395ceb7-60a0-471f-ab23-451ac7937873@suse.com>

On Mon, Jan 27, 2025 at 10:52:47AM +0100, Jan Beulich wrote:
> On 24.01.2025 13:01, Roger Pau Monne wrote:
> > From: Teddy Astie <teddy.astie@vates.tech>
> > 
> > As CX16 support is mandatory for IOMMU usage, the checks for CX16 in the
> > interrupt remapping code are stale.  Remove them together with the
> > associated code introduced in case CX16 was not available.
> 
> Perhaps insert "now" before "mandatory" (then also in patch 3)?

Sure.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 10:06:28 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 10:06:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877571.1287704 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcM0h-0007cq-Ar; Mon, 27 Jan 2025 10:06:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877571.1287704; Mon, 27 Jan 2025 10:06:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcM0h-0007cj-8F; Mon, 27 Jan 2025 10:06:27 +0000
Received: by outflank-mailman (input) for mailman id 877571;
 Mon, 27 Jan 2025 10:06:25 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=O4xJ=UT=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcM0f-0007cQ-Df
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 10:06:25 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5ceade93-dc96-11ef-99a4-01e77a169b0f;
 Mon, 27 Jan 2025 11:06:23 +0100 (CET)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-5dc10fe4e62so7726841a12.1
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 02:06:23 -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
 4fb4d7f45d1cf-5dc186183eesm5187647a12.10.2025.01.27.02.06.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 02:06:22 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5ceade93-dc96-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737972383; x=1738577183; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ZxEmDsMo+/gBOLwpFJjk0+oatht2X6UlbmkSSleeHPI=;
        b=LCoKVpwE8WecBiA+tNDWNflmxVtKyP4P1My8ZDu35s38iUpVNhJ7nK2Qyha73Eot9X
         tsY/xKp9WVkQRX7CWj0jTGW96muBT+BYDBzI/1iXuqrwrefeLL2TzWpKk1959nWOj5gq
         8p2Db4T4qVXVVe/aWjghyfqB/TTYKqt+ljqhxFFdarOM0oyP6vTGxz5NrhSlxyeK81bv
         TC2Pd1A5aXJRU81sWIm5SS58yPUF8Yn/GMZv/9EgzhU9ZpuK5Y1EfJfSwC7ATJ49vLZn
         x3bYdIrhGgNKot5lzdZe+Tg7U4O1Olwo9ztdpiP7y25M7sa7RsReVh2IZszof/AQIsvx
         1AMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737972383; x=1738577183;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ZxEmDsMo+/gBOLwpFJjk0+oatht2X6UlbmkSSleeHPI=;
        b=uQkUv6u8zk1OxJ6OVEEVaMvmFuHXKNL42nVK7se7bbeAO0MLNHigdLMs4PeFwmiMJ3
         f6q9dQyzDPNPA29ph4UFBeV3uxL6SmErOLueLyMmlkI5wx7C6JyHxrvmk5rGaATB7xTk
         8ODvDrrqhbeV51tFddFo0mRfD6lfRWGW7jxpt1PjIoYHRYZrDV7e07ehrpOd5OE908I/
         q6yq2Sp2yOdOEXwfnXGp8Y8Uk1+tJe8GNq48fMduN9UQpRhYWxzjCAI4PJGo6bvw1idf
         EpntMUcLNJS4h584iVPY3kVZiz8fnJA6iTuokWrJKuvLc1PYZTBy2qsMcPX27qFCnOcn
         RQaA==
X-Forwarded-Encrypted: i=1; AJvYcCVj0z8hfR2GdE5RftjeZbcdCOg84g3f1EEY0CV/FojxueBuJ1Htjon0yjoxu2VqQMAMIVkkJ7lraCA=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxf59+8tk8JWhT7WAjvO83qDT4Lea5tW1fkSf69OPvA2qsMDOVq
	Rzo9A/Xw5BM+G+OxTCmZMTlUIS+IU0WDKn/51vy+V2p5FtQ4HCjD+52CJzvbaQ==
X-Gm-Gg: ASbGncsxKzn1vzUIzdpccA5JKHLWc5SPIBzwe7HriYD+6jeoAVf7qiYEo2TnNxzKvEL
	1ADwGU1OnnXUOLj5HEfgUOm0xum2C9LdlAvJ6FNAbu4jKQY5fo4SOHn+Kl/iB2X88mCVGDPp2fG
	Ylb7Oq76tOMyCAPrzIi84JZ3+YALTusJeZJxcZcWEWXhAmh2/IvLxXHhYYupoWsL4W97iFm1IeT
	7vimG5rnbpwwHM83apPTMIFXJVNywltXQ+9E5WAftzu4UOw116GsYTzeXmc/6uMmrmPql0UXOnB
	mi/Z2r7hum2G8bG+L/Q4JKz0NpiP7SVm6U0DBto2PVHvS6ENcCs1wm3B6LhoB5o8tw==
X-Google-Smtp-Source: AGHT+IEn3B8C3oJOAraoTae1gQ94YDTGMGSsKqimyCZYBtgSVZEtwOjZ9A68F1tu3BvFsqVBSNUwoQ==
X-Received: by 2002:a05:6402:5203:b0:5d3:e766:6143 with SMTP id 4fb4d7f45d1cf-5db7db078a1mr39509010a12.30.1737972382913;
        Mon, 27 Jan 2025 02:06:22 -0800 (PST)
Message-ID: <21bfd2f5-74b8-409e-956c-dd736a3c0be2@suse.com>
Date: Mon, 27 Jan 2025 11:06:24 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 1/3] xen/riscv: implement software page table walking
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Alistair Francis <alistair.francis@wdc.com>,
 Bob Eshleman <bobbyeshleman@gmail.com>, Connor Davis
 <connojdavis@gmail.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1737391102.git.oleksii.kurochko@gmail.com>
 <00dfc71569bc9971b53e29b36a80e9e020ac61ac.1737391102.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <00dfc71569bc9971b53e29b36a80e9e020ac61ac.1737391102.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 20.01.2025 17:54, Oleksii Kurochko wrote:
> RISC-V doesn't have hardware feature to ask MMU to translate
> virtual address to physical address ( like Arm has, for example ),
> so software page table walking in implemented.
> 
> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> ---
>  xen/arch/riscv/include/asm/mm.h |  2 ++
>  xen/arch/riscv/pt.c             | 56 +++++++++++++++++++++++++++++++++
>  2 files changed, 58 insertions(+)
> 
> diff --git a/xen/arch/riscv/include/asm/mm.h b/xen/arch/riscv/include/asm/mm.h
> index 292aa48fc1..d46018c132 100644
> --- a/xen/arch/riscv/include/asm/mm.h
> +++ b/xen/arch/riscv/include/asm/mm.h
> @@ -15,6 +15,8 @@
>  
>  extern vaddr_t directmap_virt_start;
>  
> +paddr_t pt_walk(vaddr_t va);

In the longer run, is returning just the PA really going to be sufficient?
If not, perhaps say a word on the limitation in the description.

> --- a/xen/arch/riscv/pt.c
> +++ b/xen/arch/riscv/pt.c
> @@ -274,6 +274,62 @@ static int pt_update_entry(mfn_t root, vaddr_t virt,
>      return rc;
>  }
>  
> +paddr_t pt_walk(vaddr_t va)
> +{
> +    const mfn_t root = get_root_page();
> +    /*
> +     * In pt_walk() only XEN_TALE_MAP_NONE and XEN_TABLE_SUPER_PAGE are

Nit: s/TALE/TABLE/ ?

> +     * handled ( as they are only possible for page table walking ), so

Nit: Blanks again inside parentheses in a comment.

> +     * initialize `ret` with "impossible" XEN_TABLE_MAP_NOMEM.
> +    */
> +    int ret = XEN_TABLE_MAP_NOMEM;
> +    unsigned int level = HYP_PT_ROOT_LEVEL;
> +    paddr_t pa = 0;

Seeing 0 as initializer here, just to double check: You do prevent MFN 0
to be handed to the page allocator, and you also don't use it "manually"
anywhere?

> +    pte_t *table;
> +
> +    DECLARE_OFFSETS(offsets, va);
> +
> +    table = map_table(root);
> +
> +    /*
> +     * Find `pa` of an entry which corresponds to `va` by iterating for each
> +     * page level and checking if the entry points to a next page table or
> +     * to a page.
> +     *
> +     * Two cases are possible:
> +     * - ret == XEN_TABLE_SUPER_PAGE means that the entry was find;
> +     *   (Despite of the name) XEN_TABLE_SUPER_PAGE covers 4k mapping too.
> +     * - ret == XEN_TABLE_MAP_NONE means that requested `va` wasn't actually
> +     *   mapped.
> +     */
> +    while ( (ret != XEN_TABLE_MAP_NONE) && (ret != XEN_TABLE_SUPER_PAGE) )
> +    {
> +        /*
> +         * This case shouldn't really occur as it will mean that for table
> +         * level 0 a pointer to next page table has been written, but at
> +         * level 0 it could be only a pointer to 4k page.
> +         */
> +        ASSERT(level <= HYP_PT_ROOT_LEVEL);
> +
> +        ret = pt_next_level(false, &table, offsets[level]);
> +        level--;
> +    }
> +
> +    if ( ret == XEN_TABLE_MAP_NONE )
> +        dprintk(XENLOG_WARNING, "Is va(%#lx) really mapped?\n", va);

Even if it's a dprintk(), I'd recommend against adding such.

> +    else if ( ret == XEN_TABLE_SUPER_PAGE )
> +        pa = pte_to_paddr(*(table + offsets[level + 1]));

Missing "else if ( ret == XEN_TABLE_NORMAL )" (or maybe simply "else")?

> +    /*
> +     * There is no need for unmap_table() after each pt_next_level() call as
> +     * pt_next_level() will do unmap_table() for the previous table before
> +     * returning next level table.
> +     */
> +    unmap_table(table);

I don't think the comment is needed. You map once before the loop, so it's
natural that you unmap once after.

> +    return pa;

Don't you want to OR in the low 12 bits of VA here (unless "pa" is still 0)?

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 10:09:11 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 10:09:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877582.1287715 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcM3G-0008FZ-Pg; Mon, 27 Jan 2025 10:09:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877582.1287715; Mon, 27 Jan 2025 10:09:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcM3G-0008FS-LN; Mon, 27 Jan 2025 10:09:06 +0000
Received: by outflank-mailman (input) for mailman id 877582;
 Mon, 27 Jan 2025 10:09:06 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=O4xJ=UT=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcM3G-0008FM-2r
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 10:09:06 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bcbde66c-dc96-11ef-99a4-01e77a169b0f;
 Mon, 27 Jan 2025 11:09:04 +0100 (CET)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-aa689a37dd4so855112966b.3
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 02:09:04 -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
 a640c23a62f3a-ab6760ab26asm554650966b.111.2025.01.27.02.09.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 02:09:03 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: bcbde66c-dc96-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737972544; x=1738577344; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Ei6kV8GCrFpcOMgKNhaAoBHMAESFzzrlx3lF3NeC/CY=;
        b=fL6dBuHWk8o+ZNjNBrL67IUVIkrqnK3RgaTz1jVegoSuHzcCq9+rGLEY+FSHY70zkv
         7l3Ewk2dSHSs7i+gH9upG6sVC1jPTKU/AE4Vox9A72L0sIG9pwiaaod3waGzVgGmcIXx
         e4Qpp3RN+3YxlWeUwzjeMPUSmoABw/sY6e+/09LSGx+wO5LXC6jEzfC8j7yI2K+O2MpI
         eGXkKXjbg2RoRESRFRRxndEWa+IFT7kVUMGncnEXnrmzqaCGlSgH0DijzZh6miLNG0hq
         WfQcGt8kcVvw6pFSMlt7hA2fup+tKDdJR0YyZAoZo2Y61ffljteRIr0BQPP0DciC51kb
         qHcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737972544; x=1738577344;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Ei6kV8GCrFpcOMgKNhaAoBHMAESFzzrlx3lF3NeC/CY=;
        b=rgpFXmwjEkaUVbO4+mLGTroDM6ku93pyrhpiOvi1DDIdMIwQmjb8pC3Xqoaj/ufcgC
         ySXya912dBlkHKhbj9gCXNhXGgfxhyd+lcIqPKJ32LZLMpX22MlUDGB3WXD01LdI960Z
         1zzSrBA/tbU3Vt1v6evexuvR5E8aAJFqatyQyNW+VTdRQk6W0EyUL4wF76LiJ7c7R0GH
         i9RyOcVDD0po+fxXtlmz+VkMA0zhSm9gzwOpq6D8bZ931Wczc7XeKTpqZGDkKFbm3xtG
         cSnCVBYVveauY/xqhOgJ97S/0RfSIWsIqhzD46PNxv86LkRCoiw0aP4EFrKHjV+tXgAa
         K+cw==
X-Forwarded-Encrypted: i=1; AJvYcCXzZfb6Z8OewfUV/+o4XB92/vyD0Ol1Cm3OmvQn4OBSxuycI5RgFmjqfGZ/KedrIgp0xkFslDN53qI=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz+DKmEZnxi0v/Vp7M6zzoPyN5wDvwGE28ck8FNVBvha50XoCVT
	0hVzITdkViKDgi1Ofq64BvNOXFTUHAKuPOmAu/TGVUxm4frvH3qBGfSPooD9qA==
X-Gm-Gg: ASbGncuSCQ7aHu0kLKbla4HqU3wdP7Wl/Lir6zj06bgmgfd7xhToftIlrJ8JM+eA/3E
	uO/FH8e/PVTsXuo0XxlWVlCDnMQ2/gMcYZxyVvgx3x3yQ/ByM0jaRsYdLkD3aFcQHROCsKNIE6l
	qHYWrLBY+lnlAAOfLrY7YeHBUxfTd2UR0htqCSvLSXKqboMjwJVxTjRZ9KzSeMm18/9x65PAWHl
	vpqhp/9w51uZS6OBoKgQ1WKISOtDcFyucsVzoB17zhB/lsEJncjeSKbwxrMC4NdxIePHb07lRSy
	v2fbgAgk7WLGZdcWReH0DJ0pRHkJGF0UQinELLstmu2bgCLFbUhQUMFIkYcRb61Oig==
X-Google-Smtp-Source: AGHT+IFAvxkwOkiLdl1MuXJxKTdGk9iaC2ZqMvxNmlOE3G/tr7LiSglopafw3E2Xyfc0YRUeKAb6TA==
X-Received: by 2002:a17:907:6ea4:b0:ab2:bffb:4b5c with SMTP id a640c23a62f3a-ab38b24bd9emr3492394666b.18.1737972543672;
        Mon, 27 Jan 2025 02:09:03 -0800 (PST)
Message-ID: <2bf6ef11-fb4e-40ef-b258-dd9314cba791@suse.com>
Date: Mon, 27 Jan 2025 11:09:05 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 2/3] xen/riscv: update defintion of vmap_to_mfn()
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Alistair Francis <alistair.francis@wdc.com>,
 Bob Eshleman <bobbyeshleman@gmail.com>, Connor Davis
 <connojdavis@gmail.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1737391102.git.oleksii.kurochko@gmail.com>
 <bf85f6987c2a2f3374ad47fc0bf1513d69372b1f.1737391102.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <bf85f6987c2a2f3374ad47fc0bf1513d69372b1f.1737391102.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 20.01.2025 17:54, Oleksii Kurochko wrote:
> vmap_to_mfn() uses virt_to_maddr(), which is designed to work with VA from
> either the direct map region or Xen's linkage region (XEN_VIRT_START).
> An assertion will occur if it is used with other regions, in particular for
> the VMAP region.
> 
> Since RISC-V lacks a hardware feature to request the MMU to translate a VA to
> a PA (as Arm does, for example), software page table walking (pt_walk()) is
> used for the VMAP region to obtain the PA.
> 
> Fixes: 7db8d2bd9b ("xen/riscv: add minimal stuff to mm.h to build full Xen")
> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

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

> --- a/xen/arch/riscv/include/asm/mm.h
> +++ b/xen/arch/riscv/include/asm/mm.h
> @@ -25,7 +25,7 @@ paddr_t pt_walk(vaddr_t va);
>  #define gaddr_to_gfn(ga)    _gfn(paddr_to_pfn(ga))
>  #define mfn_to_maddr(mfn)   pfn_to_paddr(mfn_x(mfn))
>  #define maddr_to_mfn(ma)    _mfn(paddr_to_pfn(ma))
> -#define vmap_to_mfn(va)     maddr_to_mfn(virt_to_maddr((vaddr_t)(va)))
> +#define vmap_to_mfn(va)     maddr_to_mfn(pt_walk((vaddr_t)(va)))

With this being the first use of pt_walk(), I wonder whether the function might
better return mfn_t (and simply ignore the low 12 bits of Vthe incoming VA; see
my respective comment on the earlier patch). After all it is quite natural for
a page table walk to return a page frame number, not a physical address.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 10:15:27 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 10:15:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877590.1287725 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcM9L-0002Bd-DE; Mon, 27 Jan 2025 10:15:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877590.1287725; Mon, 27 Jan 2025 10:15:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcM9L-0002BW-A8; Mon, 27 Jan 2025 10:15:23 +0000
Received: by outflank-mailman (input) for mailman id 877590;
 Mon, 27 Jan 2025 10:15: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 <SRS0=O4xJ=UT=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcM9J-0002BM-VF
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 10:15:21 +0000
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com
 [2a00:1450:4864:20::52d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9d1f1bd9-dc97-11ef-a0e6-8be0dac302b0;
 Mon, 27 Jan 2025 11:15:20 +0100 (CET)
Received: by mail-ed1-x52d.google.com with SMTP id
 4fb4d7f45d1cf-5dc149e14fcso6181059a12.2
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 02:15:20 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5dc186f1c4bsm5209763a12.81.2025.01.27.02.15.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 02:15:19 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9d1f1bd9-dc97-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737972920; x=1738577720; darn=lists.xenproject.org;
        h=content-transfer-encoding:autocrypt:content-language:cc:to:subject
         :from:user-agent:mime-version:date:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=nGaowH9dYFvSfPuZ8QS4xHL6+BSe9sQpqO6jV1ExWKE=;
        b=Rv2WZNnAK2TuF6rtOqqA/NqlNsciJqLqKHZNUZpPVsZxfN1ziKAny0aj2gLZmeN+iu
         evjkEtdoAv4BhOa5qay+ucwB4BYjVHIS1zGmQnsusMmpj9kwgBXKVKW6b+MavBYlfuFg
         E1o85DF4k3LbyMiDAECpn8wqOYE2sW5L47zb3318Q7KjMleaAHPGbvEh32rZp7JPZYet
         t0tWdpNctVSrrDsQ42TuZnjTrHYJGRTtYj1OX7D3tOKB2AHWlWPlZACu6uA1S7VMtBut
         hhwjxioYQGrHqSFio+l7cQ/q2Vy2nyzCKhkdo7yo7kBKITcPR+Tutyv5NqdK0THPGKU1
         RDMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737972920; x=1738577720;
        h=content-transfer-encoding:autocrypt:content-language:cc:to:subject
         :from:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=nGaowH9dYFvSfPuZ8QS4xHL6+BSe9sQpqO6jV1ExWKE=;
        b=tis3QBRtBwZh2Afz+WzJ0BWNUpgTFMZ1Kb7jdemSPVGfS3fVmayT12Jba4xb1Ia7fI
         xb4yWMLyacJofeHUY/wO7j9+3ySKjg65fhM6wQugs0VPAb9NCvDq9a+lP/KKt1rtkUAV
         9uwRv9/hMztgA9FAzx91SAMZ95sUVtgdPs0weY4YfSM6K+nFvW3OMvjaTNdnEvyHxxqQ
         o0BEWj4RhWNOq14yMFcqyU9Ha1MZU9EXHhlTQ/cOW5OFZVu2UcnoRUhESqMxrByQOO4K
         pGYaCvHJkn+e4Ft9lfcm5DjhACUQJ8tyKR2wrLyA/q/zcQjQjLPx8MKjaLxDcWsPTXTb
         wqIw==
X-Gm-Message-State: AOJu0YwJOh707q06B7TD5nGOojIkmkhize9vMNeK6Wrnc6P0229PGJBe
	Upd3ASBp/Z5G36i/lrLThg/b14Mx7JINfgABEgFWf71F94BoxvkAi8NRHR+gH09+bKjgATmLqRg
	=
X-Gm-Gg: ASbGncvOna8fZxlvZKBeF0WA3d63Re1CDkubdBxyz5tVY22I4hlRldCSryYJagbYXRe
	jeIlP2bT9ZqfMUubtmVsB96xTIqsV+KF4B/qtJmrAbIr+Z8wWx74hMUYnVNthqewb1of2m+Xu9W
	eSEAehhGpHuQVD00AvN0y/VlBk56Mh72wmc5Ads/3bpJ7aDgUFNxjHVVR9ZmVse+lfIM9gnn/xp
	85BCwavdJSI2uM5XlAcsOiQ9otd4KaZhARcMaNeaWuGTtLGK7AOGUa0pi/1zxQKxSW7sTRzgikW
	eKe/eZ2w5xw+RHeh0PzQwi05jNSBkLEQZ1DDdux7hdCbZ1n4HdU3k/G5cBBBXndLMQ==
X-Google-Smtp-Source: AGHT+IHCaFaM2/nTC+OOFqL0d4WI6Cy5oEUGr1f6rlJjVZ9KQM092jO166tod8walMcATMC1mEomYQ==
X-Received: by 2002:a05:6402:278f:b0:5d9:b50e:7008 with SMTP id 4fb4d7f45d1cf-5db7d2f8c49mr33710087a12.8.1737972920162;
        Mon, 27 Jan 2025 02:15:20 -0800 (PST)
Message-ID: <a615a96e-95d2-442f-b57d-0bb51142c977@suse.com>
Date: Mon, 27 Jan 2025 11:15:22 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH for-4.20] x86/PV: further harden guest memory accesses against
 speculative abuse
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

The original implementation has two issues: For one it doesn't preserve
non-canonical-ness of inputs in the range 0x8000000000000000 through
0x80007fffffffffff. Bogus guest pointers in that range would not cause a
(#GP) fault upon access, when they should.

And then there is an AMD-specific aspect, where only the low 48 bits of
an address are used for speculative execution; the architecturally
mandated #GP for non-canonical addresses would be raised at a later
execution stage. Therefore to prevent Xen controlled data to make it
into any of the caches in a guest controllable manner, we need to
additionally ensure that for non-canonical inputs bit 47 would be clear.

See the code comment for how addressing both is being achieved.

Fixes: 4dc181599142 ("x86/PV: harden guest memory accesses against speculative abuse")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
RFC: When scratch2 isn't %r8...%r15, the MOV, CMOVNB, and XOR will have
     unnecessary REX prefixes emitted, as users of the macro pass in 64-
     bit registers. Similar to what was done to be able to use SETcc (in
     the earlier alternative code sequence), we could derive %e.. from
     %r.. to shrink code size some; there are a few dozen instances of
     this code, after all. (An alternative, requiring to touch the use
     sites, would be to constrain the scratch registers to rAX...rDI and
     pass in only the last two characters of the names [e.g. "di", i.e.
     also without the leading %]. That would make it straightforward to
     use both %r.. and %e.. at the same time.)
---
v2: Drop the non-RCR alternative.

--- a/xen/arch/x86/include/asm/asm-defns.h
+++ b/xen/arch/x86/include/asm/asm-defns.h
@@ -1,3 +1,5 @@
+#include <asm/page-bits.h>
+
 #ifndef HAVE_AS_CLAC_STAC
 .macro clac
     .byte 0x0f, 0x01, 0xca
@@ -65,17 +67,36 @@
 .macro guest_access_mask_ptr ptr:req, scratch1:req, scratch2:req
 #if defined(CONFIG_SPECULATIVE_HARDEN_GUEST_ACCESS)
     /*
-     * Here we want
-     *
-     * ptr &= ~0ull >> (ptr < HYPERVISOR_VIRT_END);
-     *
+     * Here we want to adjust \ptr such that
+     * - if it's within Xen range, it becomes non-canonical,
+     * - otherwise if it's (non-)canonical on input, it retains that property,
+     * - if the result is non-canonical, bit 47 is clear (to avoid
+     *   potentially populating the cache with Xen data),
      * but guaranteed without any conditional branches (hence in assembly).
+     *
+     * To achieve this we determine which bit to forcibly clear: Either bit 47
+     * (in case the address is below HYPERVISOR_VIRT_END) or bit 63.  Further
+     * we determine whether for forcably set bit 63: In case we first cleared
+     * it, we'll merely restore the original address.  In case we ended up
+     * clearing bit 47 (i.e. the address was either non-canonical or within Xen
+     * range), setting the bit will yield a guaranteed non-canonical address.
+     * If we didn't clear a bit, we also won't set one: The address was in the
+     * low half of address space in that case with bit 47 already clear.  The
+     * address can thus be left unchanged, whether canonical or not.
      */
     mov $(HYPERVISOR_VIRT_END - 1), \scratch1
-    mov $~0, \scratch2
+    mov $(VADDR_BITS - 1), \scratch2
     cmp \ptr, \scratch1
+    /*
+     * Not needed: The value we have in \scratch1 will be truncated to 6 bits,
+     * thus yielding the value we need.
+    mov $63, \scratch1
+     */
+    cmovnb \scratch2, \scratch1
+    xor \scratch2, \scratch2
+    btr \scratch1, \ptr
     rcr $1, \scratch2
-    and \scratch2, \ptr
+    or \scratch2, \ptr
 #elif defined(CONFIG_DEBUG) && defined(CONFIG_PV)
     xor $~\@, \scratch1
     xor $~\@, \scratch2


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 10:24:36 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 10:24:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877601.1287735 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcMI3-0004gf-9e; Mon, 27 Jan 2025 10:24:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877601.1287735; Mon, 27 Jan 2025 10:24:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcMI3-0004gY-6E; Mon, 27 Jan 2025 10:24:23 +0000
Received: by outflank-mailman (input) for mailman id 877601;
 Mon, 27 Jan 2025 10:24:21 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=O4xJ=UT=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcMI1-0004gO-Ib
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 10:24:21 +0000
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com
 [2a00:1450:4864:20::62e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id de979630-dc98-11ef-a0e6-8be0dac302b0;
 Mon, 27 Jan 2025 11:24:20 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-aa689a37dd4so858228566b.3
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 02:24:20 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab675e124e3sm555067466b.21.2025.01.27.02.24.18
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 02:24:19 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: de979630-dc98-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737973459; x=1738578259; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=RgmuTDj0uAXzjg8zQRTvW2GcIE0H5Jo8YjWaR+itgXU=;
        b=Yxex4Pg5yx0tl2soA+Q5fXtZT3MT1GmEKcsEYaYEh9HSO3HzgHVp54pEf/ObrDFzQH
         +4c2P2+l+cnlikTs1PwUNHGt7R9eqhqUi8gWRj8HKwvRva5XY7YRkj+NVFbzG6LbzrZK
         a0RkB8g5RmjGM4bC2prc0M8f7vLr6hQI1hLU5UqxZ3ePb4lAhzo0NwMlzJRcpirMcVRW
         CO9a6r8xWcym/jWFrpuDhqyKfc30tmz54qApBHzQRZShjlKsmMeIbIWLTROEkhjX6ntJ
         /vcTU6z65fyJk3BwAAxYXBdmya5L15tC/IhPhMM5jfAP48eujf/GSzCBng8ekYk5Xlkg
         OKOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737973459; x=1738578259;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=RgmuTDj0uAXzjg8zQRTvW2GcIE0H5Jo8YjWaR+itgXU=;
        b=Nd9+6ykg8kbH0P/qtV018ML5meXrP4gNayJ0KvGEOFfYztVevXhLnTXuo8lXfsg2Hv
         p5eUrcS79GAsDoUAdv0EFt7V0/L5gPgNk7lq7X3UP3GVa8DglWYE1GA4QF8I1GvheA6o
         9aiVRr1oqlidx3GO04PbS9uYDOLSyi9JwYzj/BlkF9Iph/h0zd9xg5PwzLouYmD05ya1
         7gu7D+S3W3rLp6enWzKZqXsd8JMGdok9YNYanQmR5egzZXwhBXZ9qqUdx9KE1RPc1ZN9
         /1WS1BqkK+SdKXs4dAmAH3cgNSw+VWoAa1pEW0ibRV8NcqFmcwvC95rUaCnpMCAiDXZz
         dVLQ==
X-Forwarded-Encrypted: i=1; AJvYcCWKylWiqxS7a8XUOViaYjxHUwg6MCmlSUQvd6kzZvGe65pWlxQo6EKWsH+zn3uxrcfXW94u51SmGRA=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw7fQtt7QbLAho/OS9jd1uGOlm+b4s7NVnM30L3lS0K1L0lkElv
	UtRiF0ANDo2sxtDphV4tgGno1HnlShquok0fKVAT9H9G928Yvt5unM9YJrHrTA==
X-Gm-Gg: ASbGnctCqf9w1O4zVo84qqXDma3lzqJQscRmwj7FXxEFBhjQD0fVKeigrStTFaaJmTa
	OCXUrKBahObmKBUu8TAlyGIu5wXNh0KcvULtpWexJ0qqUer0YH1UOnBsahLenTHoXR1cm+Sqttt
	bMGT1XOy6Q/SSQo/Bn1WpAiEFNM0NPtmjMQKXzIuMIqyAuhuMl0XUagmEGB2fi7HsW54rRA+Rgj
	sHG+WL0Cei03lby79ePtzjNqmyKzEK8pSVpb1GwdDGjKLsN21YpSnu30XGWqkr9GpkR3sBtwvjv
	/mUHYKFr75e/Fp60JQHT0AyF8Mcklca1BJdwgFFBZolrsUm4SC2CW92s9R7ujOoeFw==
X-Google-Smtp-Source: AGHT+IF8DiyW/DpERaeVfY0KnBz+bUJ6Lt3txnMt06zX1Tj2jv7M9Yqxt/Yr7SiPf0OJH1f6xJ1Xow==
X-Received: by 2002:a17:907:7dab:b0:aa6:a87e:f2df with SMTP id a640c23a62f3a-ab38b2b7842mr3436872566b.25.1737973459399;
        Mon, 27 Jan 2025 02:24:19 -0800 (PST)
Message-ID: <f244ed32-cf27-452f-8c92-206f892f809c@suse.com>
Date: Mon, 27 Jan 2025 11:24:21 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 3/3] xen/riscv: update mfn calculation in
 pt_mapping_level()
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Alistair Francis <alistair.francis@wdc.com>,
 Bob Eshleman <bobbyeshleman@gmail.com>, Connor Davis
 <connojdavis@gmail.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1737391102.git.oleksii.kurochko@gmail.com>
 <a4a970490471035bf49a97257b400da23091fb9a.1737391102.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <a4a970490471035bf49a97257b400da23091fb9a.1737391102.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 20.01.2025 17:54, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/pt.c
> +++ b/xen/arch/riscv/pt.c
> @@ -346,9 +346,33 @@ static int pt_mapping_level(unsigned long vfn, mfn_t mfn, unsigned long nr,
>          return level;
>  
>      /*
> -     * Don't take into account the MFN when removing mapping (i.e
> -     * MFN_INVALID) to calculate the correct target order.
> +     * `mfn` should be set properly in cases when modifying/destroying a
> +     * mapping to ensure the correct page table `level` is received. In the
> +     * case of `mfn` == INVALID_MFN, the `mask` will take into account only
> +     * `vfn` and could accidentally return an incorrect level. For example,
> +     * if `vfn` is page table level 1 aligned, but it was mapped as page table
> +     * level 0, then without the check below it will return `level` = 1
> +     * because only `vfn`, which is page table level 1 aligned, is taken into
> +     * account when `mfn` == INVALID_MFN.
>       *
> +     * POPULATE shouldn't be considered as `va` hasn't been mapped yet.
> +     */
> +    if ( mfn_eq(mfn, INVALID_MFN) && !(flags & PTE_POPULATE) )
> +    {
> +        vaddr_t va = vfn << PAGE_SHIFT;
> +        paddr_t pa;
> +        unsigned long xen_virt_end = (XEN_VIRT_START + XEN_VIRT_SIZE - 1);
> +
> +        if ( ((va >= DIRECTMAP_VIRT_START) && (va <= DIRECTMAP_VIRT_END)) ||
> +             ((va >= XEN_VIRT_START) && (va <= xen_virt_end)) )
> +            pa = virt_to_maddr(va);
> +        else
> +            pa = pt_walk(va);
> +
> +        mfn = _mfn(paddr_to_pfn(pa));
> +    }

Doing a walk here and then another in pt_update() feels wasteful. I
wonder whether the overall approach to page table updating doesn't want
changing. It ought to be possible to tell an "update" operation to walk
down to wherever the leaf entry is, and update there.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 10:37:07 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 10:37:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877614.1287745 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcMUJ-0007Bg-B5; Mon, 27 Jan 2025 10:37:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877614.1287745; Mon, 27 Jan 2025 10:37:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcMUJ-0007BZ-7r; Mon, 27 Jan 2025 10:37:03 +0000
Received: by outflank-mailman (input) for mailman id 877614;
 Mon, 27 Jan 2025 10:37:01 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=+2+I=UT=gmail.com=urezki@srs-se1.protection.inumbo.net>)
 id 1tcMUH-0007BR-HO
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 10:37:01 +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 a3de5d4e-dc9a-11ef-a0e6-8be0dac302b0;
 Mon, 27 Jan 2025 11:37:00 +0100 (CET)
Received: by mail-lf1-x12b.google.com with SMTP id
 2adb3069b0e04-540254357c8so4246814e87.1
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 02:37:00 -0800 (PST)
Received: from pc636 (host-217-213-93-172.mobileonline.telia.com.
 [217.213.93.172]) by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-3076bc1956csm14103761fa.70.2025.01.27.02.36.53
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 27 Jan 2025 02:36:58 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a3de5d4e-dc9a-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1737974220; x=1738579020; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to;
        bh=W4QFE15tzxGQeI7M/zW2nqDheIV1bS+m/FQTTUzpTLk=;
        b=mmAx4/qU2DG7RMX4vlPQN3+syBI0+RvKOyi4eCG27+MeArETVReUD9GX+dX/8PqmJ5
         g5d8UOcSLtBJnN5qJlUHKzTS30Zsqq5X3QMcgtOR9yhZEs+zKwjRvUxk6DP/42/uI8Q7
         5Aiq8FSZAS6UHSwoZPHLYXAE49jDFJ1Y0f6Ax7UfU76yUQms+DYYfpy3TPCCD3yNogTK
         eUxEHsOUjRMbOQaKu8X/8llowfOuft4w4GAstIuKSupVKzg3yCHmTwVmPONtHo8sI8Pv
         OrveDhOMvkD8+jfnEu11ULDHH1KKyAybqrwHsXbTD+LwL5nceJ6BfZhD2vkSITHnUmon
         a6VA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737974220; x=1738579020;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:date:from:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=W4QFE15tzxGQeI7M/zW2nqDheIV1bS+m/FQTTUzpTLk=;
        b=bcssXExDqagpgqgHzGfuKibTKdtpmiqphTnfVMQZCpU4+vbJZeA3KsdQsxkjI9gbfG
         f0Rpm//HRpPEnDS3wyQVO6GfE/BXfsNmBWU7Tk5mXSKrcXuFkbpvOuooS3LUtYTk0RcZ
         mTWIEAWbRndZu+MDgxQxwvPJpTFizZ0J5bRpHynC9vmJf2minAbrK4EZ/ODgBv5iFcYl
         rM35ARX99HFek6scsZiP7wA9/sPBeMnI+R2Ny+N8WhxB7ZGxODa/7v+NBqHud/AmFpcz
         w7Cj1kxzN0SLVSbWo8B/yv0V4ymFHWNXopT5lfKBLUbl6K02HTs+ku6u95HQj8bHeHSr
         A+zw==
X-Forwarded-Encrypted: i=1; AJvYcCXs7viVN/s9paObFX9ylzMtgnLkSNrsmoeKMio5HK7CzKHX2v5reKZdxmytDwapCGW1XMmiO0KPyr8=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzq+7mOE1vwxcKkhaZqBUdHdF9YcMC9x4Y/oXnobsghbGav2Qw6
	DhScEKadMq5HDWBdzXwPb90blKZD6HFcQoXQ1JNskGzJ1q2uO1XP
X-Gm-Gg: ASbGncsPpU2doH5PPtcqJJ8XA/m+6/WOgI0qotCvkrOYc7uvzATJles+5fulllw6BaD
	XTiqtu6tYm1wLCnnnHjnow40n4v8YDLYYQibK7mg2LnRNXEpdX9TvDFZjHg6V+kbvAUSTJG+fDr
	CB7YKD0+9QERVVXfUIIvcr1Yt6m0JcBexVl4uRd8iQAlC1LH5DTxhvVnrc+0W5NF/ZlmlXvP49+
	7E0mGmHXKVBCUgz8dwZO5M+M+oi3vKYO9HMe+RiHIrPeczjstxHA9gPlXPpFD+HBOn5TeXP9im/
	/skaU9nCOFOqSBk6zpt0ozoSV2tuly4RNGs=
X-Google-Smtp-Source: AGHT+IEcn2mDT5d0SWT5jg0poO+BtsvQPwWj5ydN+QiFTcCpstqFwzzlc4zIAZ/gMSqSpGuiyMrqQQ==
X-Received: by 2002:a19:8c1d:0:b0:543:baa9:a48a with SMTP id 2adb3069b0e04-543baa9a4bcmr6967602e87.27.1737974219462;
        Mon, 27 Jan 2025 02:36:59 -0800 (PST)
From: Uladzislau Rezki <urezki@gmail.com>
X-Google-Original-From: Uladzislau Rezki <urezki@pc636>
Date: Mon, 27 Jan 2025 11:36:51 +0100
To: Valentin Schneider <vschneid@redhat.com>
Cc: Uladzislau Rezki <urezki@gmail.com>, Jann Horn <jannh@google.com>,
	linux-kernel@vger.kernel.org, x86@kernel.org,
	virtualization@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev,
	linux-riscv@lists.infradead.org, linux-perf-users@vger.kernel.org,
	xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
	linux-arch@vger.kernel.org, rcu@vger.kernel.org,
	linux-hardening@vger.kernel.org, linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org, bpf@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com,
	Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.amakhalov@broadcom.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andy Lutomirski <luto@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Clark Williams <williams@redhat.com>,
	Yair Podemsky <ypodemsk@redhat.com>,
	Tomas Glozar <tglozar@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
	Kees Cook <kees@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Shuah Khan <shuah@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Miguel Ojeda <ojeda@kernel.org>, Alice Ryhl <aliceryhl@google.com>,
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
	Samuel Holland <samuel.holland@sifive.com>,
	Rong Xu <xur@google.com>,
	Nicolas Saenz Julienne <nsaenzju@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Yosry Ahmed <yosryahmed@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Jinghao Jia <jinghao7@illinois.edu>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: Re: [PATCH v4 29/30] x86/mm, mm/vmalloc: Defer
 flush_tlb_kernel_range() targeting NOHZ_FULL CPUs
Message-ID: <Z5dhw0Ml4KGEfaUv@pc636>
References: <20250114175143.81438-1-vschneid@redhat.com>
 <20250114175143.81438-30-vschneid@redhat.com>
 <CAG48ez1Mh+DOy0ysOo7Qioxh1W7xWQyK9CLGNU9TGOsLXbg=gQ@mail.gmail.com>
 <xhsmh34hhh37q.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
 <Z4qBMqcMg16p57av@pc636>
 <xhsmhwmetfk9d.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
 <Z44wSJTXknQVKWb0@pc636>
 <xhsmhr04xfow1.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
 <Z4_Sl-zu7GprkbaL@pc636>
 <xhsmh8qr0p784.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <xhsmh8qr0p784.mognet@vschneid-thinkpadt14sgen2i.remote.csb>

On Fri, Jan 24, 2025 at 04:22:19PM +0100, Valentin Schneider wrote:
> On 21/01/25 18:00, Uladzislau Rezki wrote:
> >> >
> >> > As noted before, we defer flushing for vmalloc. We have a lazy-threshold
> >> > which can be exposed(if you need it) over sysfs for tuning. So, we can add it.
> >> >
> >>
> >> In a CPU isolation / NOHZ_FULL context, isolated CPUs will be running a
> >> single userspace application that will never enter the kernel, unless
> >> forced to by some interference (e.g. IPI sent from a housekeeping CPU).
> >>
> >> Increasing the lazy threshold would unfortunately only delay the
> >> interference - housekeeping CPUs are free to run whatever, and so they will
> >> eventually cause the lazy threshold to be hit and IPI all the CPUs,
> >> including the isolated/NOHZ_FULL ones.
> >>
> > Do you have any testing results for your workload? I mean how much
> > potentially we can allocate. Again, maybe it is just enough to back
> > and once per-hour offload it.
> >
> 
> Potentially as much as you want... In our Openshift environments, you can
> get any sort of container executing on the housekeeping CPUs and they're
> free to do pretty much whatever they want. Per CPU isolation they're not
> allowed/meant to disturb isolated CPUs, however.
> 
> > Apart of that how critical IPIing CPUs affect your workloads?
> >
> 
> If I'm being pedantic, a single IPI to an isolated CPU breaks the
> isolation. If we can't quiesce IPIs to isolated CPUs, then we can't
> guarantee that whatever is running on the isolated CPUs is actually
> isolated / shielded from third party interference.
> 
I see. I thought you are fixing some issue. I do not see a straight
forward way how to remove such "distortion". Probably we can block the
range which we defer for flushing. But it also can be problematic
because of other constraints.

Thanks!

--
Uladzislau Rezki


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 10:38:36 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 10:38:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877623.1287755 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcMVn-0007le-LJ; Mon, 27 Jan 2025 10:38:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877623.1287755; Mon, 27 Jan 2025 10:38:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcMVn-0007lX-H4; Mon, 27 Jan 2025 10:38:35 +0000
Received: by outflank-mailman (input) for mailman id 877623;
 Mon, 27 Jan 2025 10:38: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
 <SRS0=qVGR=UT=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tcMVl-0007lL-Q6
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 10:38:33 +0000
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com
 [2a00:1450:4864:20::235])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id daf03f41-dc9a-11ef-a0e6-8be0dac302b0;
 Mon, 27 Jan 2025 11:38:32 +0100 (CET)
Received: by mail-lj1-x235.google.com with SMTP id
 38308e7fff4ca-30167f4c1e3so42770691fa.3
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 02:38:32 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-3076bc71c9dsm13890981fa.111.2025.01.27.02.38.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 02:38:31 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: daf03f41-dc9a-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1737974312; x=1738579112; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=QByH+rwABHYUFPrWZeYCi2E9EJOMhWK7UZcxjM0OZgY=;
        b=hwMEUeV1wZssj3aGiwDbLJ6vE4nf1E33bZUZDHsxj21OCd2VSf1m4Ex6YJcJ+qa/iM
         m6K0HQUHCBGt/BzIcRilgAfZYU2HrnM2TyJSiFUF48BR1NZUy85rCGS2qQHz5Lh8UCCG
         kl3Fwqs8qZ1zY3ptjrAQYeRg0yMdxHTTPX/JnT/KGj0A7EfxMo3asNFQJXei/1aiJ7Y9
         Cn6ug36Rkd1Q4yczUvfYxej4XTfd3OkQV7YGESBQQsHaiPFU9MKW9oLkM6xAyN2J/Zta
         JwYR6xFw0Zg55ix2GfOvL/Y0tHo7Za0ON02aT7k7fKrlJhInsJPed6q7TgDV6QbuH49P
         RQYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737974312; x=1738579112;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=QByH+rwABHYUFPrWZeYCi2E9EJOMhWK7UZcxjM0OZgY=;
        b=aINqkDEfqR7SJaFm9wLcCNxA67n3duTR/q8YnJwEwaVcvNq+4PiHaeKt6JAx3Bxk8P
         c+jMU+pVo8/cSHBJWjzB91v3uujpPaTrRI2u//320vEjKs3+JVCwhpS4rK5wy5O9qFUZ
         MXlWQr78MaOxc7SP7Dl50k0CDGj7RxNExhT7bEHerDidhFg0CXJ+A8I0RZraunFfibLQ
         OsE4/20qtSpAUr/1Hk2nc3b164n8BPgKzXT0fkzAqk23j/mIFmsGabbWt4csDrLEQJsa
         mj32+jZ4YWfQhW7YBXgkW9YeEXny+KIt2YsG9adnvYfHP699XotIxP6V9YiitiLDm4tM
         HFYA==
X-Gm-Message-State: AOJu0YxVXBCZStweL5wj9BbX4781mX/pr+Vq/4spdGDXPrm/i0mozi/9
	nh4BtdO31nIBM3/4fNN7C8/kXhZfl8aGY1iEoMJVR9sDUGpdGQP+
X-Gm-Gg: ASbGncuFHTGS4ll7LChnYvD5C4iLMiHzUYK+SBTC7CojO1bRVpEDN8EPMRFWsz9CKUC
	R4hpFK+bmI3Q2HjEZjAq7JBKSm4aPaGYInF4aJL7aB0SikuGHAeAkR3XoGGy0rDvkiEN+9CGA+B
	Yhyz83EuhseE0VHWAUVN96GcuAv09NqMmFdTHBEbydvtGX7dBHChR2zTJvvBiPC2DRPbcv/weDY
	/kQUa6l+/rS66Y1XXXn693dOVYByOxYJkEMSAjlOhL2iUxs0DYbAkzCQSnBr1hjX1p/p30hpfpU
	mVA8c/YD+rdrwNn/cw==
X-Google-Smtp-Source: AGHT+IGRHOpNl6G4OlJfiUNwzaLsOLXBgCApyv340aTG5GSWc7eQNycobEV4KouovXpMT9xI8PdKSw==
X-Received: by 2002:a2e:a449:0:b0:306:1524:4a65 with SMTP id 38308e7fff4ca-3072caf1549mr133340461fa.20.1737974312032;
        Mon, 27 Jan 2025 02:38:32 -0800 (PST)
Message-ID: <2c3caa4c-33d2-45a0-8832-c0407ff02a60@gmail.com>
Date: Mon, 27 Jan 2025 11:38:31 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20 v2 0/5] x86/iommu: make CX16 mandatory for IOMMU
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Cc: xen-devel@lists.xenproject.org, Jan Beulich <jbeulich@suse.com>
References: <20250124120112.56678-1-roger.pau@citrix.com>
 <3204bed4-4f03-405e-b77c-4355803f3a31@citrix.com>
 <Z5OjYhD6nbFYa4ff@macbook.local>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <Z5OjYhD6nbFYa4ff@macbook.local>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


On 1/24/25 3:27 PM, Roger Pau Monné wrote:
> On Fri, Jan 24, 2025 at 02:24:34PM +0000, Andrew Cooper wrote:
>> On 24/01/2025 12:01 pm, Roger Pau Monne wrote:
>>> Hello,
>>>
>>> The following series is the original CX16 series sent by Teddy, with the
>>> CX16 checks split into a separate patch, plus one extra patch to switch
>>> AMD-Vi to use CMPXCHG16B when updating Interrupt Remapping Entries.
>>>
>>> Note that last patch to use CMPXCHG16B fixes a real bug with AMD
>>> hardware.
>>>
>>> Thanks, Roger.
>>>
>>> Roger Pau Monne (1):
>>>    iommu/amd: atomically update IRTE
>>>
>>> Teddy Astie (4):
>>>    x86/iommu: check for CMPXCHG16B when enabling IOMMU
>>>    iommu/vtd: remove non-CX16 logic from interrupt remapping
>>>    x86/iommu: remove non-CX16 logic from DMA remapping
>>>    iommu/vtd: cleanup MAP_SINGLE_DEVICE and related code
>> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

As we disscussed in matrix, with proper review R-Acked-by: Oleksii 
Kurochko <oleksii.kurochko@gmail.com>

~ Oleksii

> Thanks.
>
>> CC Oleksii.  Patch 5 is a real bugfix that needs backporting, and the
>> prior patches have been in an almost-ready state for more than a release
>> now.
> I've split the checks into a pre-patch, and did a bit more cleanup of
> code that was no longer needed (pre/post interrupt mask before IRTE
> update), but overall the code is the same plus the extra fix.
>
> Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 10:45:03 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 10:45:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877634.1287764 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcMbz-0001aw-8w; Mon, 27 Jan 2025 10:44:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877634.1287764; Mon, 27 Jan 2025 10:44:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcMbz-0001ap-6O; Mon, 27 Jan 2025 10:44:59 +0000
Received: by outflank-mailman (input) for mailman id 877634;
 Mon, 27 Jan 2025 10:44: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 <SRS0=O4xJ=UT=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcMbx-0001ah-Vn
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 10:44:57 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bfcd15e5-dc9b-11ef-a0e6-8be0dac302b0;
 Mon, 27 Jan 2025 11:44:56 +0100 (CET)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-5d0d32cd31aso6382048a12.0
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 02:44:56 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab675e66358sm566631266b.69.2025.01.27.02.44.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 02:44:56 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: bfcd15e5-dc9b-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737974696; x=1738579496; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=zDL8kIOek8iWrkwRYQHjtWMr97qlvPEUGJ/CkFtkRGw=;
        b=FQs7clwZwNlarKfryrwJOWYQh5rLn01FHr0pJ9e92w9kVE6SJQrSEGfIDv2s0lY0R7
         CIUXj9g8ibuWU4ABGoKj1iMx54LZiWo+C1vNIqYgyl/LntqgqtEAvrjz7geJt7KhNtjC
         I07zM7fmtMcR/wbXbE59iUzKW08IwDhBIL5nDwged+mLF28LiyPDKKK3j+ajnPDW+llO
         KCABwBZgao7h1Te0slavY7hXsaAQo7U2Lj205gVj+eapKIak8CVICD++C35GbW0qPXz1
         sY7XwuGF1ct1toKARcTHLZwWF1QFlqIsE2ecD0zxIHPdRandYJH2SVGTN/6b3uXt4WR2
         +t3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737974696; x=1738579496;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=zDL8kIOek8iWrkwRYQHjtWMr97qlvPEUGJ/CkFtkRGw=;
        b=jX65v2XVJ+32ek4Qh56lHsuGA10Akc11y9+3mgw3LUDnlnLdRxlnWs5fY/LIBwQs9u
         G/mzb90FsLLkxwnu83rSkbeWArY8HXS1BAk6RLxty6ncA6FjNfjYYOQUpbws7adfuNS0
         W5wRLDTuWqzby95ejH2bNaa2/FQvvSPhQpcNTRB2D8bNui4zh1sZYA8TYhpL2SNJz9Nu
         /tUsrCmD+QxlaFfV6yBsQuU+oqZqkNGXTxU47aeoK/xMen01Q4yM4VX3uv/Yp5k8wOIN
         EWt0BV1dGAwu1PuYc20eKgHXCeP8zzAPLNrEOsMUv7q23HiEjYnnV97OgsseeLo4VIAq
         J2Ww==
X-Forwarded-Encrypted: i=1; AJvYcCUF7xttNkloHe/kkJi/2qo17cDWRMBY+Y4q9hr0vaqh8veRtiD0WS34u+MQvn6cE378mlBE0oWUGYs=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxw1c9nbgx2icbfWd0l2dryvhy6CuQQeTDPzUDdPUZFY1eIX+e1
	wvLfujRqIKhr4d8cw8WqwanUBEY4Tr7nmidPM0kHkkmOhI3xlqI3CCmlVCNwBQ==
X-Gm-Gg: ASbGncsHaOGUabo7WEhMol/pNHb7OJH/Te4SrLkJS9IFS6uQ5ilGjP/R3RSFoLuIa6F
	Icdq14zfK1usElqUKOR5o8FffRuTeX52MeZ0rn1p3LVrRVUrFkgeqJLB9nuHHB7EsO/UZBkFgmi
	b5jw27kizJu9ieG5xHlHgFe1jxyNzbfBL8LoNbwqicyBoWmLRM4DON0QBu4gdEWeNj+vT/qDICN
	xq67BCkXFTFEVwm7pVzQJfcbqo75Cv8nsejuNcGcFeZK4VEZ38mdHAm/ABHcVdJ0l52FOymA8Jv
	KlegZMScPCvZli0pXEtSXEuR9PKPxON5NVehxKVRG55WsDyPcKJ09zidQ6MDm2KKtg==
X-Google-Smtp-Source: AGHT+IFuso5LFYBjCyHHxnfSoiRKKt+NOdKjxS6R5NRIrtTLrx9tq4AhFfetbzWYrWu1y/2Du7f6fA==
X-Received: by 2002:a05:6402:2706:b0:5d4:2ef7:1c with SMTP id 4fb4d7f45d1cf-5db7db078c2mr91872839a12.24.1737974696311;
        Mon, 27 Jan 2025 02:44:56 -0800 (PST)
Message-ID: <74ba0d8b-af2a-4fc7-891c-1a1305e71df7@suse.com>
Date: Mon, 27 Jan 2025 11:44:58 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 01/12] x86/xstate: Create map/unmap primitives for
 xsave areas
To: Alejandro Vallejo <alejandro.vallejo@cloud.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20250110132823.24348-1-alejandro.vallejo@cloud.com>
 <20250110132823.24348-2-alejandro.vallejo@cloud.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250110132823.24348-2-alejandro.vallejo@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.01.2025 14:28, Alejandro Vallejo wrote:
> Add infrastructure to simplify ASI handling. With ASI in the picture
> we'll have several different means of accessing the XSAVE area of a
> given vCPU, depending on whether a domain is covered by ASI or not and
> whether the vCPU is question is scheduled on the current pCPU or not.
> 
> Having these complexities exposed at the call sites becomes unwieldy
> very fast. These wrappers are intended to be used in a similar way to
> map_domain_page() and unmap_domain_page(); The map operation will
> dispatch the appropriate pointer for each case in a future patch, while
> unmap will remain a no-op where no unmap is required (e.g: when there's
> no ASI) and remove the transient maping if one was required.
> 
> Follow-up patches replace all uses of raw v->arch.xsave_area by this
> mechanism in preparation to add the beforementioned dispatch logic to be
> added at a later time.
> 
> Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>

Acked-by: Jan Beulich <jbeulich@suse.com>
with one nit below.

> --- a/xen/arch/x86/include/asm/xstate.h
> +++ b/xen/arch/x86/include/asm/xstate.h
> @@ -143,4 +143,46 @@ static inline bool xstate_all(const struct vcpu *v)
>             (v->arch.xcr0_accum & XSTATE_LAZY & ~XSTATE_FP_SSE);
>  }
>  
> +/*
> + * Fetch a pointer to a vCPU's XSAVE area
> + *
> + * TL;DR: If v == current, the mapping is guaranteed to already exist.
> + *
> + * Despite the name, this macro might not actually map anything. The only case
> + * in which a mutation of page tables is strictly required is when ASI==on &&
> + * v!=current. For everything else the mapping already exists and needs not
> + * be created nor destroyed.
> + *
> + *                         +-----------------+--------------+
> + *                         |   v == current  | v != current |
> + *          +--------------+-----------------+--------------+
> + *          | ASI  enabled | per-vCPU fixmap |  actual map  |
> + *          +--------------+-----------------+--------------+
> + *          | ASI disabled |             directmap          |
> + *          +--------------+--------------------------------+
> + *
> + * There MUST NOT be outstanding maps of XSAVE areas of the non-current vCPU
> + * at the point of context switch. Otherwise, the unmap operation will
> + * misbehave.
> + *
> + * TODO: Expand the macro to the ASI cases after infra to do so is in place.
> + *
> + * @param v Owner of the XSAVE area
> + */
> +#define VCPU_MAP_XSAVE_AREA(v) ((v)->arch.xsave_area)
> +
> +/*
> + * Drops the mapping of a vCPU's XSAVE area and nullifies its pointer on exit
> + *
> + * See VCPU_MAP_XSAVE_AREA() for additional information on the persistence of
> + * these mappings. This macro only tears down the mappings in the ASI=on &&
> + * v!=current case.
> + *
> + * TODO: Expand the macro to the ASI cases after infra to do so is in place.
> + *
> + * @param v Owner of the XSAVE area
> + * @param x XSAVE blob of v
> + */
> +#define VCPU_UNMAP_XSAVE_AREA(v, x) do { (void)(v); (x) = NULL; } while(0)

The "while" still wants to conform to style, despite it being a kind of
degenerate form. The overwhelming majority of instances we've got have at
least a blank before the opening parenthesis. Many also have the ones
inside.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 10:46:03 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 10:46:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877642.1287775 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcMd1-0002Av-Lp; Mon, 27 Jan 2025 10:46:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877642.1287775; Mon, 27 Jan 2025 10:46:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcMd1-0002Ao-Ic; Mon, 27 Jan 2025 10:46:03 +0000
Received: by outflank-mailman (input) for mailman id 877642;
 Mon, 27 Jan 2025 10:46:02 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=O4xJ=UT=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcMd0-0001ah-6w
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 10:46:02 +0000
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [2a00:1450:4864:20::529])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e6728bd3-dc9b-11ef-a0e6-8be0dac302b0;
 Mon, 27 Jan 2025 11:46:01 +0100 (CET)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-5d3f28a4fccso6349759a12.2
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 02:46:01 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5dc186d8ab9sm5162441a12.78.2025.01.27.02.46.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 02:46:00 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e6728bd3-dc9b-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737974761; x=1738579561; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=gVrL5ZnCJNmg+XsCPqZMwMCOIU9fjI8lpvMFD8YiMlk=;
        b=HC0L0gwNapWzI/+ueEA5fncoWZJCh94e0FZxwJmicXNXX7MJOtez5hkx03FvifjKbl
         oIxIl7p68Q6fzJbZ8wtUHnxCi/eviM35JAMnt/x+6MWeIvVwDENldvoB+v7uUL7DU+P6
         QwLpfElQAswTfmIgordrOpTkHa55f5uCKyx3Mlid+x/PmZ1ln71ANb9hkkasMnAkwqI8
         cd1ntkJo6CCz+B93Gjx7Ga0Muv+TqzZSYxTBzp1QhiUIkMSKmyutsIEVzlx7F1maQ9Et
         Kwg2RkCwsgKz+Yz3g7TmDVQHClf8CmbC9Vrcv6XsGbS/ER8NEsRWfFdLmS9/M3TT0SJQ
         FBHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737974761; x=1738579561;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=gVrL5ZnCJNmg+XsCPqZMwMCOIU9fjI8lpvMFD8YiMlk=;
        b=l4nXmJc1fdXZ7+5BBJGKoVtaTHWD1Nu4d04LcS3HeSrtl+Ky/kpHjhdRX9BP3kstIk
         2gAtFFz0aeHZGnrn0B4c1+isP2HC8CPb1MsNhrTS+/dgH2thkslOChhEiysFygvk7Vel
         PwBfCw80mGJUaFhsWBoETBR3TvWA5rygRh3LSNOo+SwYxV7PAbN9gsm3Ij+WrTMfd3Cj
         KotFPa4XR4PD1QGge27ky8mrZdACVQuK15p0mnwTevEBdNDKKvZnYjdqvtjupNoKKAz4
         WMH7roPVIvLiS1sY/hB+29F8xIv1LrJn9DV+gHCee03lp0x4Vt+WKXKlYM86TD6tAcHE
         Su3g==
X-Forwarded-Encrypted: i=1; AJvYcCV+BeYxDcIuGK4V7EOmGqofZypAlyDLTbzQiAPVBpPK/mfQ4Or7g5KEWpkOEd8J+aft+Cy0a9ivx2Y=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzMxeDGcz10uY1oC5OrDcVxe7pB/6OtZs9mi5A1AwWIwwQTUenZ
	R4J3+nhL2JjOiZ/8x418FjL6gZ604H4rWWvBhxAAV1hdgZBz/+X94LMvv0VhYg==
X-Gm-Gg: ASbGncs8n0H0prh7np4MWTHjX04tLLMRPunbRaP8xRLsVMMo7OgMK1cLQ+7tNwKWA6K
	u3DtYRYl6NuhlXlIPlsyZjAmnRy13iAAdjYy7gKIhJOWze/CwUA9xji+6xZS1lzH4bs6b5qp6fa
	7zGT6w0M6Dy/Yxe1vdcPtR93cbsDpbVNd89Qi5/53rar4J09cq+7Jg8vRoeoyRiorFgSXoRKByV
	pG/YQ9ojte1w8qjR2LR45/4GuNFWCvPrZwcZW07W1fArw7AYN4KCmI/h2rOXYVJjQt1FI3gr5n0
	LNAKifmeT7iG+q9ioWdxmSD0XT+44WMtgzkxfEgHkGXd1PkloSu0O0rF/drgsT6PmQ==
X-Google-Smtp-Source: AGHT+IHLOscrQvsmuL5tvNuLJAGZpwGEBLtyyzQeUyH4RIrIwCd7B41Jb1R2sK7nuou5exL9EtKrug==
X-Received: by 2002:a17:906:5617:b0:ab2:b8c3:be3c with SMTP id a640c23a62f3a-ab38b3fb0dcmr3186508166b.51.1737974761231;
        Mon, 27 Jan 2025 02:46:01 -0800 (PST)
Message-ID: <5b897c0e-1102-4bdc-bcb8-8cd8e4a4d6f6@suse.com>
Date: Mon, 27 Jan 2025 11:46:03 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 07/12] x86/xstate: Map/unmap xsave area in
 {compress,expand}_xsave_states()
To: Alejandro Vallejo <alejandro.vallejo@cloud.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20250110132823.24348-1-alejandro.vallejo@cloud.com>
 <20250110132823.24348-8-alejandro.vallejo@cloud.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250110132823.24348-8-alejandro.vallejo@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.01.2025 14:28, Alejandro Vallejo wrote:
> No functional change.
> 
> Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>

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




From xen-devel-bounces@lists.xenproject.org Mon Jan 27 10:46:12 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 10:46:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877645.1287790 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcMdA-0002VA-8S; Mon, 27 Jan 2025 10:46:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877645.1287790; Mon, 27 Jan 2025 10:46:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcMdA-0002Ui-11; Mon, 27 Jan 2025 10:46:12 +0000
Received: by outflank-mailman (input) for mailman id 877645;
 Mon, 27 Jan 2025 10:46:10 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=rEBS=UT=amd.com=Michal.Orzel@srs-se1.protection.inumbo.net>)
 id 1tcMd8-0001ah-TU
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 10:46:10 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on2061f.outbound.protection.outlook.com
 [2a01:111:f403:2412::61f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ea9beccc-dc9b-11ef-a0e6-8be0dac302b0;
 Mon, 27 Jan 2025 11:46:10 +0100 (CET)
Received: from SJ0PR03CA0251.namprd03.prod.outlook.com (2603:10b6:a03:3a0::16)
 by MN0PR12MB6079.namprd12.prod.outlook.com (2603:10b6:208:3c9::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.22; Mon, 27 Jan
 2025 10:46:04 +0000
Received: from MWH0EPF000971E3.namprd02.prod.outlook.com
 (2603:10b6:a03:3a0:cafe::92) by SJ0PR03CA0251.outlook.office365.com
 (2603:10b6:a03:3a0::16) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8377.22 via Frontend Transport; Mon,
 27 Jan 2025 10:46:03 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 MWH0EPF000971E3.mail.protection.outlook.com (10.167.243.70) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8398.14 via Frontend Transport; Mon, 27 Jan 2025 10:46:02 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 27 Jan
 2025 04:46:01 -0600
Received: from XIR-MICHALO-L1.xilinx.com (10.180.168.240) by
 SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39
 via Frontend Transport; Mon, 27 Jan 2025 04:46:00 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ea9beccc-dc9b-11ef-a0e6-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ED4aLuJWT/OrDx7T1wKZVT6NozYck4aZOw727gZ0me8beid5T9DHmuxJA+UuFDDRlMFJjvBbwf7y2ZnDCyR9EO5FnF2r4xq9/6JS7Okqyw61J3o26NmIeRbnNT1Zy9uDHy8lM80VoixDfJvnE2Warsq8j5RObaA6mAohasea3Tu+bXxSHsgoD4x+WC2tnTrQPuSp6e89sIUDm6m4e7vPztkVEylE/rklgEY5P1TsguY7CyBaiYaHzqI4jBnZFn9PqGtGJRRd53Wd+S2Wd8+dk5JHY7x+ljXhEy0gGtW/kT6Zc+h46sg4zvGRIpJryHK+JxSFEWm22zYdTUYitWz3vA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=WNR0ouBbqbHHAoSjXLlBdAQfyyv0rL4tNCyhR0MJ/FQ=;
 b=rRGL45nohGf+G9snm88Aqb/jroYLkCDCWiOld3fFWFxqHA8u3ByT/q/sNWXECgjhnP8n8Wo788sBsP1nqSG6xL+4pR1xr1eP5klU2FDFVHH5CDNI/3eLuc9kEUugIwBuhSgMh28UrFbTG6n977SaybO5k/84tmMn9G4r8Yo2SzOn3MIjElhrbcLgZMcxn7nAjvAsIJwIuArtlfoKuXQOOxWVmSRPoCHWmYJK4MUDTsSooLnWO6h9+7ox5/VI13UcmQoRqc2IDVOf6jptVrI503WqQ2ZkSjQkIrSG65CEaKHZ2NpZjrwkDybabr4MgXM7Nn47MAIC8O5sytl/vHYbbg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=WNR0ouBbqbHHAoSjXLlBdAQfyyv0rL4tNCyhR0MJ/FQ=;
 b=Isngv73SK9qKlKNWxbRH/BQh8PMWcvrKmjWV/1kvQ9K2zgWSmxSSiMfE4xoxK6d2jkj/NO30Dlu4BjzgVWsaY3a+ZVsUxAjnqJ4jwibZIAPmFbs35tQIZwIuiVWXw9uz45L3KOHsxWAvm+3gy+E3m2+mj3nhXgmiN8v+1/gNsQU=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Michal Orzel <michal.orzel@amd.com>
To: <xen-devel@lists.xenproject.org>
CC: Michal Orzel <michal.orzel@amd.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand Marquis
	<bertrand.marquis@arm.com>, <oleksii.kurochko@gmail.com>
Subject: [for-4.20][PATCH 1/2] device-tree: bootfdt: Fix build issue when CONFIG_PHYS_ADDR_T_32=y
Date: Mon, 27 Jan 2025 11:45:55 +0100
Message-ID: <20250127104556.175641-2-michal.orzel@amd.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <20250127104556.175641-1-michal.orzel@amd.com>
References: <20250127104556.175641-1-michal.orzel@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB04.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MWH0EPF000971E3:EE_|MN0PR12MB6079:EE_
X-MS-Office365-Filtering-Correlation-Id: 684b561d-a384-4e91-332b-08dd3ebfcb2e
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|82310400026|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?c7Z5v0fA5X4ppiwAKUcViE2YL2YYadK3VihlFGZoQ+5DauctIFUA01xyvfKK?=
 =?us-ascii?Q?nmCGTYJBgIr8ZUWMRvlRA6ip9tLaNWScTt6OVL7dHfO/8gEnwr1rYS/Jqpfz?=
 =?us-ascii?Q?2L9SRZCghoTPkiDoCLJ3BViOI+5KsMQUY4t2KMF5nJP59Zvj0DS6o1kfM2eg?=
 =?us-ascii?Q?bUD0mAiAejfkU194hwQ7/9eFTvhoaBzkam+1wJCsCvs10sRhXQVOyqhx0qv1?=
 =?us-ascii?Q?aNWgNAYL3D+ZQd4huCNbkyR1jCjT9ljj21TiZCKRL+JubedqF8wbSNHg/Z7u?=
 =?us-ascii?Q?FcKnVAvRndLH0AFGWwawYFMF9vGPXn71wnFmGpgbGygzEtyNOGkHNDwHZ8cA?=
 =?us-ascii?Q?AxURmxd/ltCiprtUXoaeEq5DPjnM0Qoj/hBMLgH5YncVDwuxPfpKTT9Ab1gu?=
 =?us-ascii?Q?Qvy+8JWADbNB6KB7dB9JYk/xYCSyNHeXq95JSHT85DhWePbWQN3fXypMFoUM?=
 =?us-ascii?Q?9lIAiVaIGxSmaiS9sBHMK+s/n4Apf2O+ujQwMts6PrvbfETtl5sFx33rV5jo?=
 =?us-ascii?Q?DvrYznqn3wR3b9hXyIL+KSBMs4l3Z4wzaar5CHMVf1MZqZy7EK1nNYbGWwmG?=
 =?us-ascii?Q?8FlM558TWb430TTJaSs3ckddesDAIc2CmVJPtUIKuCecWb3LIH5DkeIi1zE2?=
 =?us-ascii?Q?WQNGf+YzMvP2zdvbvFUGj5G9tZgz1QylmVCQBJ4wNOmilljLAXtHnk9wxEwg?=
 =?us-ascii?Q?s0YRn/1okubxA5A409MFwSIKDFq1qVAJmwxrKSsH7ZZYK97AZMoknsVsj6Po?=
 =?us-ascii?Q?/OtPuOrU9Yg2kPQl7OduPI4bJpbNJPOtRXaZ+hR0oyLTSRU7CvbK2mNPE/j+?=
 =?us-ascii?Q?I5Ol8H11J8VD+CJpkgwUOC0EYKi+15USXZJjq2cWpMAXDgWCUhcMmz9iGw/Y?=
 =?us-ascii?Q?/6Dp+tfWSUnPrjLeNGN38H/mwUSO0e/r4fim//Jn/83Cf8qlHzTDQYccAbbz?=
 =?us-ascii?Q?U6HXnqJo4iLddPBkAAwycVTcOk9jFjtO9F0LuHOt9Z2BeSP/1QvJFb8fcYd3?=
 =?us-ascii?Q?Cz7T7Nh4ccpfOWQ4aegxh3Expw/TNMRMmIf/xZeqN940+C+s0ho83sZmGdO1?=
 =?us-ascii?Q?dcGllnkVVattdol3qhycNLBjtwFHSJG8KX0yZO2jcacCNCp+KMsEyWPzOp6K?=
 =?us-ascii?Q?TIH/jVJMcwxNMPFkdXoQ6oDw1K5yM5MIk8taYfoLdhjelxHZrrBxQeKT6wnD?=
 =?us-ascii?Q?BUtsDHmb+rGGFXdCncG4tk6SyzVCDQ5RmIpLJFrlrMtsPhZ382pUtUSyKO2e?=
 =?us-ascii?Q?bDFtPja/zWfVQvnKigiNuIIFBgzIeqO/GGWWX7m0FyRCOaTAbZOK0coQLUfv?=
 =?us-ascii?Q?xVkCezldK9qb94eT0VSpeoGK+l/CcgiX6lJYL6p1Cege8rDTr895ft7wlEBx?=
 =?us-ascii?Q?BSzUcMB6mbVS5V/rUTUNsVW24ZkiMHhkYtXSkUnQc+kRi74mNxQWziFHVVpx?=
 =?us-ascii?Q?T4wycRJgetVyWUsiuQmkNazAfcVY7PPhoDo6GzdgptL+hlFtIIWX9QTWPmvb?=
 =?us-ascii?Q?xLAqf6mwzUrMw3k=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(376014)(82310400026)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2025 10:46:02.3237
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 684b561d-a384-4e91-332b-08dd3ebfcb2e
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	MWH0EPF000971E3.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB6079

On Arm32, when CONFIG_PHYS_ADDR_T_32 is set, a build failure is observed:
common/device-tree/bootfdt.c: In function 'build_assertions':
./include/xen/macros.h:47:31: error: static assertion failed: "!(alignof(struct membanks) != 8)"
   47 | #define BUILD_BUG_ON(cond) ({ _Static_assert(!(cond), "!(" #cond ")"); })
      |                               ^~~~~~~~~~~~~~
common/device-tree/bootfdt.c:31:5: note: in expansion of macro 'BUILD_BUG_ON'
   31 |     BUILD_BUG_ON(alignof(struct membanks) != 8);

When CONFIG_PHYS_ADDR_T_32 is set, paddr_t is defined as unsigned long,
therefore the struct membanks alignment is 4B. Fix it.

Fixes: 2209c1e35b47 ("xen/arm: Introduce a generic way to access memory bank structures")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
---
 xen/common/device-tree/bootfdt.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c
index 47386d4fffea..511700ccc2ba 100644
--- a/xen/common/device-tree/bootfdt.c
+++ b/xen/common/device-tree/bootfdt.c
@@ -27,8 +27,8 @@ static void __init __maybe_unused build_assertions(void)
      */
     BUILD_BUG_ON((offsetof(struct membanks, bank) !=
                  offsetof(struct meminfo, bank)));
-    /* Ensure "struct membanks" is 8-byte aligned */
-    BUILD_BUG_ON(alignof(struct membanks) != 8);
+    /* Ensure "struct membanks" is paddr aligned */
+    BUILD_BUG_ON(alignof(struct membanks) != sizeof(paddr_t));
 }
 
 static bool __init device_tree_node_is_available(const void *fdt, int node)
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Mon Jan 27 10:46:12 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 10:46:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877643.1287784 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcMd9-0002Sx-Se; Mon, 27 Jan 2025 10:46:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877643.1287784; Mon, 27 Jan 2025 10:46:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcMd9-0002So-Pi; Mon, 27 Jan 2025 10:46:11 +0000
Received: by outflank-mailman (input) for mailman id 877643;
 Mon, 27 Jan 2025 10:46:10 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=rEBS=UT=amd.com=Michal.Orzel@srs-se1.protection.inumbo.net>)
 id 1tcMd7-0001ah-S8
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 10:46:10 +0000
Received: from NAM04-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam04on20605.outbound.protection.outlook.com
 [2a01:111:f403:2409::605])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e7cda445-dc9b-11ef-a0e6-8be0dac302b0;
 Mon, 27 Jan 2025 11:46:05 +0100 (CET)
Received: from MW3PR05CA0030.namprd05.prod.outlook.com (2603:10b6:303:2b::35)
 by SN7PR12MB7834.namprd12.prod.outlook.com (2603:10b6:806:34d::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8356.21; Mon, 27 Jan
 2025 10:46:01 +0000
Received: from MWH0EPF000971E9.namprd02.prod.outlook.com
 (2603:10b6:303:2b:cafe::69) by MW3PR05CA0030.outlook.office365.com
 (2603:10b6:303:2b::35) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8377.18 via Frontend Transport; Mon,
 27 Jan 2025 10:46:01 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 MWH0EPF000971E9.mail.protection.outlook.com (10.167.243.71) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8398.14 via Frontend Transport; Mon, 27 Jan 2025 10:46:00 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 27 Jan
 2025 04:45:59 -0600
Received: from XIR-MICHALO-L1.xilinx.com (10.180.168.240) by
 SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39
 via Frontend Transport; Mon, 27 Jan 2025 04:45:58 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e7cda445-dc9b-11ef-a0e6-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=pAN0t58IPfWvQAFR4M25oDgKNHnzOva3L65Y6d++ZVPTGc6QRn7TSb6QWaaH/5r9+r+T+XVSGgptjjP/HsLNm5hiOO/YPuPxU/d22q9EDBEMUwaz2wNObXFhH9GR26somtY1OF56mt/d6i5Pw1zUjx2u3Hm2VDctRdXzL7bXh9Zr/Jabszp85ew4oFsq2DCbCq18VvtRPncrpo6JbzsTjMkJVByO4LpLgIv3ZuEb+ZWKOI3bk9eXEsRgzbLXGzCJ/5yJ53BI19UJXlCNZM8PWknWsQFfTQfZMayITrjT8ubYkaghmKqgDNttPtDMtuwMPKwNfVInYVas9V3hfRb+Mg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=6w7NW5Tq9BQ4T5PXnzy3s3SW3uM9h9Kf76VWukGYyXA=;
 b=L4t2+Sz6SdqYGDqA6hFoYzw6yfPZdf5+f3sPtGzsvLPCk0dJlMRLmp6Gw0a+VA/smY9GEcFBaso4nwMFoxx4GW7KJiFKsJV+K2S7L52K7uIRFnvWXim5ChwGGTzogXytQKBJJ8H4y2vqFKrEdgqbFJrXx/k6lkLpTvMW+nTUjWpfOQyuKcJN2f8x8gfEqn1bBEmJH2DWTNqeH9KSAWdEV4aWOavPQ/1ql+vtX0xVhFAxmicr4SVV3sH/8aH18MxPgIGZ9HM6Ti5sMEEmGBXa4JNbLrEQfqHvsHq5MFydP1r22bDR22FO3i0vidMbJkUaxfLCV61jLBv23AjSh9qCfQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=6w7NW5Tq9BQ4T5PXnzy3s3SW3uM9h9Kf76VWukGYyXA=;
 b=qajKZmhqcLmrgoeoW2nm+hsHzljQaKla/07mXwgoccXpEM7sv6rfYEyaUE8ZOtLtQC4jaSM3hfERmCZJXxGQLWqUdRf4skhl2Pddssu2gvH7/MXLXbkgrl8wZ6cfiNDwIq4Ot/+phuRq3k2loZEl62bgeJ0Fb8O4sYh0Yn26DtU=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Michal Orzel <michal.orzel@amd.com>
To: <xen-devel@lists.xenproject.org>
CC: Michal Orzel <michal.orzel@amd.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand Marquis
	<bertrand.marquis@arm.com>, Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	<oleksii.kurochko@gmail.com>
Subject: [for-4.20][PATCH 0/2] xen/arm CONFIG_PHYS_ADDR_T_32=y fixes
Date: Mon, 27 Jan 2025 11:45:54 +0100
Message-ID: <20250127104556.175641-1-michal.orzel@amd.com>
X-Mailer: git-send-email 2.25.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB04.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MWH0EPF000971E9:EE_|SN7PR12MB7834:EE_
X-MS-Office365-Filtering-Correlation-Id: f4e542db-8fc1-49f9-399d-08dd3ebfca3d
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|36860700013|1800799024|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?QtIBy4qMcf8wYuBtMD88bGdIkkTgcDiegWt9iKkPCsGjNbmcitsM+fxRHZoV?=
 =?us-ascii?Q?D/KHdF2YnWDTyZGe+SJlmJnUYCwkeDLkSreg+JMc4HlGN/57BupqneVMpaXc?=
 =?us-ascii?Q?u4CWOE1LPU/HUz3eDZX0WoWwCzzHLM4SK3SyQIR14pqPfD5XyR9mnBI6xc7H?=
 =?us-ascii?Q?hTAvqufzAMCgY3zZiDNdg5Wd2vu0KOEpNYR0hv3ZuFnefZfv16K3E+HwakQ0?=
 =?us-ascii?Q?9h+VFgINLpRm4/MYPDrkEig4xVE6yrH7naqd03VyuBggd3xdHBsw/FV2MzKu?=
 =?us-ascii?Q?zGvwxlKsY7cMO6XhPlu8oaRKER/nnLHVDKQ9b2WhZ6x48oQ5RIg5sAKOcYrk?=
 =?us-ascii?Q?BCjvVTIlcyNdc/D133WGGOum9oq3lV7nGB+N7jXxVQ7TxhdOBna8LIuL7RtJ?=
 =?us-ascii?Q?Qd/nIxKXVts3OOJlMfnltV7j2OWrIH65pdiHRnXdQPKdjSzkmJiBNcKkS7Ie?=
 =?us-ascii?Q?kNOl9FHGkBXwC6ZcK04KFI7SElIJMzEFuVX+1DXb/fZRLytwz2UMInmljkBt?=
 =?us-ascii?Q?lUeXCiRFJhQRkzADVImaHDh6NPaVqfRJC0grtIjHt5ty79yutTKiYqCKLtsA?=
 =?us-ascii?Q?RwLPfUuC7bdN1rlF3bx5/J67pioQ3x1erpD8ewkXeiUpNi185+pKd3L8TnZ5?=
 =?us-ascii?Q?I1tFz9UlFed++4sEdR3o3fX6s+uvJ7GvFfS3bqSiS/0TluTnxjyWAkTrOxKK?=
 =?us-ascii?Q?IxUGhfDNjD/Kc5GMPf37qMwQOXf4ez7vr+sDQdTKxL0FTXVVMCohVE5VOcEb?=
 =?us-ascii?Q?C0lI18bNHw54UYu1Zg47d157x2nQj9G2hYNGm0neJJgKgRIqkQnLSVg8Hqcp?=
 =?us-ascii?Q?xMvyU2t9/F3WUqy+ViRUz0N4UDH0FZQ01hx5B551AH0weoX6iswl2P2PGphJ?=
 =?us-ascii?Q?exLjptnCDd5WCbIrZOUhF0JwPdnFpX75GLbEqMCUt1AR/sX286o4xmyPeo41?=
 =?us-ascii?Q?t3nsXs+RprttsKs3ZOrb1Pg6KivsmFaedX7kYK4a20IfDOXa7EIWCX337bOk?=
 =?us-ascii?Q?pxBgGF+LxvkZ1rC5P0eKigrcN+IEmgY1GH7t4t2E7MpOG6KdpM0P8DGEgbVC?=
 =?us-ascii?Q?9kpjXKrmNqoWQ2HZsMvYu/F4PENs8JXwFT/r/2HODrLjGaX+pO95qemiURzb?=
 =?us-ascii?Q?IWlbSulrLjZ94LJEeWF6FVj/hiNVwCB+fTykyXDBZpcWYVdwEWFNMrEv193l?=
 =?us-ascii?Q?S6K/Vv411fkJQ8vEb2B7StzLl08LqvcxrU2xbIzSO9K2Iy4yT4IfSFGXavLm?=
 =?us-ascii?Q?HOJRxew4kV5QGL2QLIo64ijxIWHvyK1E6knp55CkVahxWdaFuqCtaMpXoTHd?=
 =?us-ascii?Q?wwe53CRjWs79u1UYefaxiaFqZNBXitToz/rulGR301sWVTPlO1Zk15ER6egc?=
 =?us-ascii?Q?CnLE3qJ9yqtbXskPWnTcqY4PgB1/owEFOL8fQ39JZUAhg1XUpCx9bB5z6MEE?=
 =?us-ascii?Q?dA3XobaiMi1XTMm7aWjMNZ8jYYUxoA//CelQdBTanTe6L0Jn8fBn+zLmXgYE?=
 =?us-ascii?Q?EsGV6wzgm5juBFY=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700013)(1800799024)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2025 10:46:00.7601
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: f4e542db-8fc1-49f9-399d-08dd3ebfca3d
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	MWH0EPF000971E9.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB7834

This series contains build fixes when CONFIG_PHYS_ADDR_T_32=y.

@Oleksii:
This is a release blocker.

Michal Orzel (2):
  device-tree: bootfdt: Fix build issue when CONFIG_PHYS_ADDR_T_32=y
  xen/arm: Fix build issue when CONFIG_PHYS_ADDR_T_32=y

 xen/arch/arm/include/asm/mm.h    | 2 +-
 xen/common/device-tree/bootfdt.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Mon Jan 27 10:46:13 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 10:46:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877646.1287805 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcMdB-0002wl-Bz; Mon, 27 Jan 2025 10:46:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877646.1287805; Mon, 27 Jan 2025 10:46:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcMdB-0002vx-8X; Mon, 27 Jan 2025 10:46:13 +0000
Received: by outflank-mailman (input) for mailman id 877646;
 Mon, 27 Jan 2025 10:46:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=rEBS=UT=amd.com=Michal.Orzel@srs-se1.protection.inumbo.net>)
 id 1tcMd9-0001ah-SQ
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 10:46:11 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on2060c.outbound.protection.outlook.com
 [2a01:111:f403:2412::60c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id eaebcf9a-dc9b-11ef-a0e6-8be0dac302b0;
 Mon, 27 Jan 2025 11:46:10 +0100 (CET)
Received: from SJ0PR03CA0264.namprd03.prod.outlook.com (2603:10b6:a03:3a0::29)
 by CY8PR12MB8194.namprd12.prod.outlook.com (2603:10b6:930:76::5) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.20; Mon, 27 Jan
 2025 10:46:05 +0000
Received: from MWH0EPF000971E3.namprd02.prod.outlook.com
 (2603:10b6:a03:3a0:cafe::f9) by SJ0PR03CA0264.outlook.office365.com
 (2603:10b6:a03:3a0::29) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8377.23 via Frontend Transport; Mon,
 27 Jan 2025 10:46:05 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 MWH0EPF000971E3.mail.protection.outlook.com (10.167.243.70) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8398.14 via Frontend Transport; Mon, 27 Jan 2025 10:46:04 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 27 Jan
 2025 04:46:03 -0600
Received: from XIR-MICHALO-L1.xilinx.com (10.180.168.240) by
 SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39
 via Frontend Transport; Mon, 27 Jan 2025 04:46:01 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: eaebcf9a-dc9b-11ef-a0e6-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=QsgZ8r2Dz7Q35lkSz6Z8g1DXwZ/2X86QNaFDbTn4nrzXAPIi1YsZOePzwMdyWU76HU0Bo/QUq3sB3Vc5Ef6o+gFR9Urkw92U68q5yOLBbLQpxtgz36rMowLFKfls+IlGxt9faH9u0xGvghHGVzDrn9ZOj9KBFvkPeTF2wNaOakGPG+q/uiKhn6pxQVt6Z8FF0yQ4pWnG9/hS1IoAHJ70EvufnXhtTwnNxFlZ/MyGXdXtIXBtpG/X/M8HW6CJZSAvdMpxKkKtq83Gu1eTUSmdkWzX/+EutF56K0CcUKkV6N2EeXX4J+Ge7lObJlYn/frE/Msx2Wfb0+XsOvQRSGfdBg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=0FlS5NYMJkshnxGYQIzdg2iyP5nY3U9hAQSCfYUR8ds=;
 b=kgO8clTeM3LzqczldlrZ12+0uGBiwFlHmw7seZX/sPazCUTrzmqzbA6ddLZFMyy2deLIT4WrdvteYnogNb8sbKcxy48/9EtM7DJxl8+AYC2lfij/JQni3EcRjkKSDxVac6RLJh+7pzbleTKvlitZNf2aWer8NzapASb59uDH1MBA4aX/1JS3/17m/ICdY639szVtqWYl7r1ydlOYQQOmSN76HxKXeT0xN0vhkbwmwILoL0RR97caMVjIIFxW65jLzaOfxZfnDF2rWM7R2pwlhtL0f2GUWPEDNdmc1IT8gQwAzTxqCjhpAFvFf5c4K//OlmZN8tysqmoL4lYVb9QuQQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=0FlS5NYMJkshnxGYQIzdg2iyP5nY3U9hAQSCfYUR8ds=;
 b=3Z7mHjc3KjZfh94vEQytbv+evGMcgrR9Rymz0L91Ku29ScYTOOdene3egyMurVH35QGN4Yz+CMmYSaAwgF5gU8fdmYtyapfzy9tS4U1CMIPTopQGfjYJhTgSz2QMBiweAsQI5u2hV1DN+KKdE/rnIiH5/x87IfeMPC5NJ+YVBgg=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Michal Orzel <michal.orzel@amd.com>
To: <xen-devel@lists.xenproject.org>
CC: Michal Orzel <michal.orzel@amd.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand Marquis
	<bertrand.marquis@arm.com>, Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	<oleksii.kurochko@gmail.com>
Subject: [for-4.20][PATCH 2/2] xen/arm: Fix build issue when CONFIG_PHYS_ADDR_T_32=y
Date: Mon, 27 Jan 2025 11:45:56 +0100
Message-ID: <20250127104556.175641-3-michal.orzel@amd.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <20250127104556.175641-1-michal.orzel@amd.com>
References: <20250127104556.175641-1-michal.orzel@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB04.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MWH0EPF000971E3:EE_|CY8PR12MB8194:EE_
X-MS-Office365-Filtering-Correlation-Id: fc186281-1563-42d1-3486-08dd3ebfccb5
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|36860700013|82310400026|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?e0U7RTw0MEZqNp4EiOkfZQlRiY9jY7dsPkbX2lwz7Pdzk8o4+HiNm6itsKCa?=
 =?us-ascii?Q?lPt7C7kqo+qNugRNhQF9k0qYd0dD8EzYgMtYaDcDJEJlAtEA1Uvt46iopz7w?=
 =?us-ascii?Q?4afNOdlDd12gE7V+Z0BKJLJnmw3feSl7eqYLgH6NOWxjt485jmF+FVt8Fjjc?=
 =?us-ascii?Q?/pspQpp+Tor3mAy7n6dlOQjD//HCBR+qMLGvS+jWe/Kg3R2oEvbMw6P5Z77w?=
 =?us-ascii?Q?+aAhAakZYWu/l1IEemS9Zvl2yk7Aw00IBbY5/CXIWk+SufRnR1zht8BgEi+s?=
 =?us-ascii?Q?Ajv3ABcpZp1eyJO8RssMxzVqJsNHwNJygyMtrHlvbPRrnVNJ4a5BwLhrHLMr?=
 =?us-ascii?Q?A0DrJJ26ATEfuw/Dwx2D675OeO53QHqBuwUdwhKxJWZQa6qK4DsF4omm9xTF?=
 =?us-ascii?Q?8Wxi+nRbrdn3RTw56nZhq/Nnsgq5MXOEeTrlX3zhMsvSfIAMSxl3+vwqTzIW?=
 =?us-ascii?Q?E/fd+lc0Vd549Urx1E6l/Q3krezm2twr+WGXEvRV/RxHD8TtaYvYGawJbPTU?=
 =?us-ascii?Q?P+IB3zmSNkls/aik6RGI1ntcfEEooNnEinxkEH56abkD9st+Jod7wuImPTAf?=
 =?us-ascii?Q?5PYBO3J1H65nuVufv+qf1bUEdZVwz85cueMckXI/rqIg07y6yKcUU0iSnuBL?=
 =?us-ascii?Q?z2E0JznlbmD/mkXrEcGLyIwMq53/7/OL+lH1JyoqDaohrRtxWHKd3gj4x7Oj?=
 =?us-ascii?Q?lmaWrzXK3YJNtlWMsOstsY2z9Xgnbs5depiMIUBkP6TzDBwdDISFNZMwiJWn?=
 =?us-ascii?Q?t7DUMMNqYVbGWguvVUlon+ZOY3fSh4zZyLI5d0kMBppq5i8vWE+qg3gxyIAU?=
 =?us-ascii?Q?UrsInUBb9C7jxP9lQIRM0rgde36aPsjr1ROu83v/6bpvz0Rjce30Qg2chICR?=
 =?us-ascii?Q?DJxHLtVRSy1JbkZEzzjz0M/w7ubCd+Dns1KaTYDNQGZZvBDH5aybgCCKbXCn?=
 =?us-ascii?Q?Tgft2iYv+REyT78CIpXtrU5rKArTaTCWmYizxvVSiNl6rPkuY2DJWqPEtLsX?=
 =?us-ascii?Q?/nYZ8oWzbyQzCyqPNMH0PZwcDon12vlIoAcnw61f5fNR+RB69+34DShkLqFx?=
 =?us-ascii?Q?aVqM/Myue0RY3aJ48POIxSBF6VnYY7z2FEycGAWma/eDr+7p2Jg752cT8ZCr?=
 =?us-ascii?Q?WKxGoyOim7vWkrAhLdVRFUQkn/z4U6pLct3BVlKYgh7Yle+pYDLehidnIOqC?=
 =?us-ascii?Q?pgHBp0XZA8bDg6HoPIHuQKA20RERveyPa97lotpA+oS1GcnVpl4AcZM41pjC?=
 =?us-ascii?Q?ElnoERPxbHEbMOHM6CCW3anGiuEq2RNnfIz9P5j6Xt/8cau4yMvRutsrN2ze?=
 =?us-ascii?Q?kcmTY0Bg5e7d8H1Ty5mK/CqY/Gvf3HApX3CTerGLiga9p2yv9PTmbd8QnbZB?=
 =?us-ascii?Q?FScI70ReCtqB4gwke2o09Jd2YLrfC51ArrNUFud7aCucC9JJ368Mdfu3w9K+?=
 =?us-ascii?Q?uXpfmMaCssArM9H5FMehs6fEMBt+6ro1D6vtENoIhU5SN09yP4yhBRKt7KxN?=
 =?us-ascii?Q?NJlLfReDqhLjlzI=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(82310400026)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2025 10:46:04.8862
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: fc186281-1563-42d1-3486-08dd3ebfccb5
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	MWH0EPF000971E3.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB8194

On Arm32, when CONFIG_PHYS_ADDR_T_32 is set, a build failure is observed:
arch/arm/platforms/vexpress.c: In function 'vexpress_smp_init':
arch/arm/platforms/vexpress.c:102:12: error: format '%lx' expects argument of type 'long unsigned int', but argument 2 has type 'long long unsigned int' [-Werror=format=]
  102 |     printk("Set SYS_FLAGS to %"PRIpaddr" (%p)\n",

When CONFIG_PHYS_ADDR_T_32 is set, paddr_t is defined as unsigned long.
Commit 96f35de69e59 dropped __virt_to_maddr() which used paddr_t as a
return type. Without a cast, the expression type is unsigned long long
which causes the issue. Fix it.

Fixes: 96f35de69e59 ("x86+Arm: drop (rename) __virt_to_maddr() / __maddr_to_virt()")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
---
 xen/arch/arm/include/asm/mm.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/include/asm/mm.h b/xen/arch/arm/include/asm/mm.h
index f91ff088f6b1..a0d8e5afe977 100644
--- a/xen/arch/arm/include/asm/mm.h
+++ b/xen/arch/arm/include/asm/mm.h
@@ -263,7 +263,7 @@ static inline void __iomem *ioremap_wc(paddr_t start, size_t len)
 
 #define virt_to_maddr(va) ({                                        \
     vaddr_t va_ = (vaddr_t)(va);                                    \
-    (va_to_par(va_) & PADDR_MASK & PAGE_MASK) | (va_ & ~PAGE_MASK); \
+    (paddr_t)((va_to_par(va_) & PADDR_MASK & PAGE_MASK) | (va_ & ~PAGE_MASK)); \
 })
 
 #ifdef CONFIG_ARM_32
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Mon Jan 27 10:52:14 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 10:52:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877681.1287825 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcMiy-0006OW-CY; Mon, 27 Jan 2025 10:52:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877681.1287825; Mon, 27 Jan 2025 10:52:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcMiy-0006OP-9D; Mon, 27 Jan 2025 10:52:12 +0000
Received: by outflank-mailman (input) for mailman id 877681;
 Mon, 27 Jan 2025 10:52:11 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=O4xJ=UT=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcMix-0006AP-1U
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 10:52:11 +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 c0a614eb-dc9c-11ef-99a4-01e77a169b0f;
 Mon, 27 Jan 2025 11:52:08 +0100 (CET)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-aaec111762bso918280066b.2
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 02:52:07 -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
 a640c23a62f3a-ab6aa40824asm118455866b.134.2025.01.27.02.52.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 02:52:07 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c0a614eb-dc9c-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737975127; x=1738579927; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=IyjeDF8OKBxz6ia6vXzbKX4nJegmuau8imeDrdNM1bU=;
        b=G8bIfIa5fFDY9FXUSwz4jqOT7FhDUwDXTxBUHWWO7+tj87CQAPI7xzgH+EVkVTz8+k
         umww9r5pfg3gxVqN/DHkHjbBT9ydcWLUJW5JSG1nQkYxL8mzlp2s+NNOC3vs1IbhJDfK
         TL2JVUsFYMTCbWpuVesMwxPBbK0gC2X1AIDe/62TKyyVvvQz7qarO2ZaIFd46Jnq3u+5
         Cq5iWq191kAnRkgnQZsme8uNlFvI7cJtBQEiVc4vHUXVcXk7zs8SjDzweCheUZ1mjgNM
         CgeUHWxPDuLy1B7VyTQ23AJQYYU2b1Xj23jx1glRXgy0fGbLbJ6GeAY6CYtdC19aPjev
         6akA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737975127; x=1738579927;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=IyjeDF8OKBxz6ia6vXzbKX4nJegmuau8imeDrdNM1bU=;
        b=mAeRa5MAj0uzGkcyR5240IjUWW2oqTB6/JoRYo1pOtYmFCD/3k9fGNOCs+cVmjEsSs
         sS5PHFWYalZOd3DEZK4C7OAn/Ynm867Zi7ZBr3G1I9jfK46KWdiIy08ZCIWxGGTr4d0o
         FuFUo2u/ZRMi5d0UU7BK1c7EFwwaUeuCDPn6hxD9rL2sNWP/h8UH3u4HtPmqzWzHH8Nw
         MM/DyEUZdPPNZbhAuUhldxYjrgdXBSWUL5/umy//lcrND3nG7+AYGN8zNI8cGPOooGYb
         aHG/wANCXukrsvcXc7Q4UMfkN58fSDa/mRuuECmtXRLVB/74cgRRrel67jeUpJUb3im6
         bVFA==
X-Forwarded-Encrypted: i=1; AJvYcCXY0NUaw6ITO8JvUNY/2BppiJV+Ap8gdMDH26aNMJwCb0kIUx9UakGTGs4+JedmbU6Ri4khteUGtJ0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzE3h460q4qcRN/sFgE2mccVZ0A8dA5Kz0OL6CWHb/bzZubaRRi
	n6QqTP+TwBrP9thl8N4s1/gRJwgphCobAHPwl+tvYt9dGTPw//nhW6pxRxBMRg==
X-Gm-Gg: ASbGnctUKrjTNMGVwirXVPyDKCh54jIYYUS5lKFYnIqmxm3a+qbewJXPv89LbNwquSj
	inytrg6qFvDkqtY0rsKUSnzkonJuLM6xYf3mVyanYrrVu6WxbL/IMfOS+JBVYGhMgaGbChEloSO
	avQF48+Xz93gGeyZ9oiR/zV3HIYzHQ9rpEe+H3cM4J3rzazWXtOvgBnRobkJ3Vc6eBKw1Genh8b
	7tJuXizZPCHyt0Q651j0HRnjIotlvb80Fbjcen/vL82HoLbxQMNRmFdcAP/E9yR5iZJtwqj85jJ
	JpAPTryWS7ygQRrXdVGajrS0496PIpc7HG/N1qo+8ZRf67yqaqT9P+ZeFTRHsm7AEg==
X-Google-Smtp-Source: AGHT+IEbxacT0Rf7glIV5zqQTQpKB3fYs6ygwCctur3iH2OIEYbdv0+TAfSzoLAAPaA0iPTY1QPe+A==
X-Received: by 2002:a17:906:6a26:b0:aa6:b473:ea4c with SMTP id a640c23a62f3a-ab38b0b920fmr3551212766b.10.1737975127295;
        Mon, 27 Jan 2025 02:52:07 -0800 (PST)
Message-ID: <bc5185ca-9001-4699-82d0-88e629ae6503@suse.com>
Date: Mon, 27 Jan 2025 11:52:09 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 08/12] x86/emulator: Refactor FXSAVE_AREA to use
 wrappers
To: Alejandro Vallejo <alejandro.vallejo@cloud.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20250110132823.24348-1-alejandro.vallejo@cloud.com>
 <20250110132823.24348-9-alejandro.vallejo@cloud.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250110132823.24348-9-alejandro.vallejo@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.01.2025 14:28, Alejandro Vallejo wrote:
> Adds an UNMAP primitive to make use of vcpu_unmap_xsave_area() when
> linked into xen. unmap is a no-op during tests.
> 
> Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>

Acked-by: Jan Beulich <jbeulich@suse.com>
despite ...

> --- a/xen/arch/x86/x86_emulate/blk.c
> +++ b/xen/arch/x86/x86_emulate/blk.c
> @@ -11,9 +11,12 @@
>      !defined(X86EMUL_NO_SIMD)
>  # ifdef __XEN__
>  #  include <asm/xstate.h>
> -#  define FXSAVE_AREA ((void *)&current->arch.xsave_area->fpu_sse)
> +/* Has a fastpath for `current`, so there's no actual map */
> +#  define FXSAVE_AREA ((void *)VCPU_MAP_XSAVE_AREA(current))
> +#  define UNMAP_FXSAVE_AREA(x) VCPU_UNMAP_XSAVE_AREA(current, x)

... the comment here kind of suggesting that ...

>  # else
>  #  define FXSAVE_AREA get_fpu_save_area()
> +#  define UNMAP_FXSAVE_AREA(x) ((void)(x))

... use of this new construct is solely decoration, and could hence as
well be omitted.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 10:52:14 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 10:52:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877680.1287815 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcMix-0006Ac-4n; Mon, 27 Jan 2025 10:52:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877680.1287815; Mon, 27 Jan 2025 10:52:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcMix-0006AR-26; Mon, 27 Jan 2025 10:52:11 +0000
Received: by outflank-mailman (input) for mailman id 877680;
 Mon, 27 Jan 2025 10:52:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=qVGR=UT=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tcMdY-0001ah-4o
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 10:46:36 +0000
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com
 [2a00:1450:4864:20::229])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id fa7e16e0-dc9b-11ef-a0e6-8be0dac302b0;
 Mon, 27 Jan 2025 11:46:35 +0100 (CET)
Received: by mail-lj1-x229.google.com with SMTP id
 38308e7fff4ca-30613802a04so44033881fa.2
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 02:46:35 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-3076bc19614sm14251691fa.69.2025.01.27.02.46.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 02:46:34 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: fa7e16e0-dc9b-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1737974795; x=1738579595; darn=lists.xenproject.org;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=k5lEUWzgXvLvxqvn90u0nUXpGS3fDaQopw24r12oRWw=;
        b=bj6+t24hqtODBimktizGlNs3xLRF4Oj4rtGI0hnQ0F4ku/a34MjtjCkbz68YTZGFSI
         x+/Y9XKhGX6fG86UlQiWCK1TTEbVAfWPGkbbShf143xgweRlGVWiJSKP5uknN8Xp4gTB
         nSqrQ+TxiOeTMviWJ6MostWvP1zrzUPyUrulY0JyVYHBNb/MsL885YXYLfAAsvt6KS+k
         SStPBKYBGN8GtbVTUPOsfA3L0CVOkQ3c4S3o7BNyIKd3QuaJIs74FaN1LpeSSnFIC+oC
         lHhcyaYppFyWQR3UE15/a6RWq6DV9Bx/UkYvVfS7REAn4LI4ynfhSbGoJKVGqKFS2BuE
         3tJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737974795; x=1738579595;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=k5lEUWzgXvLvxqvn90u0nUXpGS3fDaQopw24r12oRWw=;
        b=EhUBVbjl7rQWio74Q4bzlgumMT8sxtD4PB0m6CCLuYoR8OUklr3Ypr3Ccv6XUqIR8n
         hrQ9vFE2xa9icl1tKPfhTFNJR5Cju83a13Oyww5Bu1Locz3y2xSA+IguTz1oF7P5CM4w
         GF6awJz9PVYAlFwGEcVI5GMZxqENePLGqRp4CZAFnJqESjXoK0MKTzSJYW0pXV10VBFl
         Rpp9yETuEPPBy2Kq+M6z2LRVHFCexAQnfKe8WknlKgiFeltGxfvD3FQVQ9RbI8nRNkge
         MZjRfp1XZL3h58uUZtEdnWOuTRMaPOGByxFDzEzwfHMDRsPslnXzzQrEXTKJPWPRDJZH
         NbHw==
X-Forwarded-Encrypted: i=1; AJvYcCUQzQIWv+HFtucG3U3LmRTHGQddus2IhYTAD/Q4DvP+NcQWX/DmynqBXE54n/F08w6ehgKs1sSvpog=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywzz7nhS5617HYFTor5mMXolSZyiL2hxqHau4Ox3DyxzBCFimPW
	sd/CbQzycpnMDGJEjwtpAFRR5Obb7gu4+g962FfPSpYABhj2LWdt
X-Gm-Gg: ASbGncsDBCnNTw58OqYqezTBBK0mYpsC5enbUBapn6Hh+/6PfoxeGXATErchOxuJZCR
	rYm6C3TZoZ9hzElcXPNXt2W221c+yIUFL1qfbpR+BU+9mYCLkpC0UYJzu98zYcqiJ2QzTxHqgaO
	gqYYMnTRCGSbDrFH4ReDgG1/S5o1uts45mPqzNOC34E6//5z7n11bsqiIU/QXsTyI9LmBuKGFAn
	IRWDi2vUD1uQmFToM+pIjYIOhIBOvubIUzmr9oI2B0R/QH0ddU/4KgYpKpJBsxTL7PzTyhglsR6
	eOHiq522ykqSedsFcA==
X-Google-Smtp-Source: AGHT+IFjPFW1ByP4+7nnOXYgAfCAVV6ahZA2UqGgf1/6HRADwylGqoyRLFaWpi3ae3WG3+uz0ukhiQ==
X-Received: by 2002:a2e:a54a:0:b0:300:43cd:3b18 with SMTP id 38308e7fff4ca-3072cb3a76dmr144956561fa.36.1737974794518;
        Mon, 27 Jan 2025 02:46:34 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------MeY1ENnMmOw4u2oSx5g6K1Ws"
Message-ID: <b6d21569-c692-4270-ae0f-137246881a8a@gmail.com>
Date: Mon, 27 Jan 2025 11:46:33 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20] x86/PV: further harden guest memory accesses
 against speculative abuse
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
References: <a615a96e-95d2-442f-b57d-0bb51142c977@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <a615a96e-95d2-442f-b57d-0bb51142c977@suse.com>

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


On 1/27/25 11:15 AM, Jan Beulich wrote:
> The original implementation has two issues: For one it doesn't preserve
> non-canonical-ness of inputs in the range 0x8000000000000000 through
> 0x80007fffffffffff. Bogus guest pointers in that range would not cause a
> (#GP) fault upon access, when they should.
>
> And then there is an AMD-specific aspect, where only the low 48 bits of
> an address are used for speculative execution; the architecturally
> mandated #GP for non-canonical addresses would be raised at a later
> execution stage. Therefore to prevent Xen controlled data to make it
> into any of the caches in a guest controllable manner, we need to
> additionally ensure that for non-canonical inputs bit 47 would be clear.
>
> See the code comment for how addressing both is being achieved.
>
> Fixes: 4dc181599142 ("x86/PV: harden guest memory accesses against speculative abuse")
> Signed-off-by: Jan Beulich<jbeulich@suse.com>

With getting proper Acked-by/Reviewed-by:
   R-Acked-by: Oleksii Kurochko<oleksii.kurochko@gmail.com>

Thanks.

~ Oleksii

> ---
> RFC: When scratch2 isn't %r8...%r15, the MOV, CMOVNB, and XOR will have
>       unnecessary REX prefixes emitted, as users of the macro pass in 64-
>       bit registers. Similar to what was done to be able to use SETcc (in
>       the earlier alternative code sequence), we could derive %e.. from
>       %r.. to shrink code size some; there are a few dozen instances of
>       this code, after all. (An alternative, requiring to touch the use
>       sites, would be to constrain the scratch registers to rAX...rDI and
>       pass in only the last two characters of the names [e.g. "di", i.e.
>       also without the leading %]. That would make it straightforward to
>       use both %r.. and %e.. at the same time.)
> ---
> v2: Drop the non-RCR alternative.
>
> --- a/xen/arch/x86/include/asm/asm-defns.h
> +++ b/xen/arch/x86/include/asm/asm-defns.h
> @@ -1,3 +1,5 @@
> +#include <asm/page-bits.h>
> +
>   #ifndef HAVE_AS_CLAC_STAC
>   .macro clac
>       .byte 0x0f, 0x01, 0xca
> @@ -65,17 +67,36 @@
>   .macro guest_access_mask_ptr ptr:req, scratch1:req, scratch2:req
>   #if defined(CONFIG_SPECULATIVE_HARDEN_GUEST_ACCESS)
>       /*
> -     * Here we want
> -     *
> -     * ptr &= ~0ull >> (ptr < HYPERVISOR_VIRT_END);
> -     *
> +     * Here we want to adjust \ptr such that
> +     * - if it's within Xen range, it becomes non-canonical,
> +     * - otherwise if it's (non-)canonical on input, it retains that property,
> +     * - if the result is non-canonical, bit 47 is clear (to avoid
> +     *   potentially populating the cache with Xen data),
>        * but guaranteed without any conditional branches (hence in assembly).
> +     *
> +     * To achieve this we determine which bit to forcibly clear: Either bit 47
> +     * (in case the address is below HYPERVISOR_VIRT_END) or bit 63.  Further
> +     * we determine whether for forcably set bit 63: In case we first cleared
> +     * it, we'll merely restore the original address.  In case we ended up
> +     * clearing bit 47 (i.e. the address was either non-canonical or within Xen
> +     * range), setting the bit will yield a guaranteed non-canonical address.
> +     * If we didn't clear a bit, we also won't set one: The address was in the
> +     * low half of address space in that case with bit 47 already clear.  The
> +     * address can thus be left unchanged, whether canonical or not.
>        */
>       mov $(HYPERVISOR_VIRT_END - 1), \scratch1
> -    mov $~0, \scratch2
> +    mov $(VADDR_BITS - 1), \scratch2
>       cmp \ptr, \scratch1
> +    /*
> +     * Not needed: The value we have in \scratch1 will be truncated to 6 bits,
> +     * thus yielding the value we need.
> +    mov $63, \scratch1
> +     */
> +    cmovnb \scratch2, \scratch1
> +    xor \scratch2, \scratch2
> +    btr \scratch1, \ptr
>       rcr $1, \scratch2
> -    and \scratch2, \ptr
> +    or \scratch2, \ptr
>   #elif defined(CONFIG_DEBUG) && defined(CONFIG_PV)
>       xor $~\@, \scratch1
>       xor $~\@, \scratch2
--------------MeY1ENnMmOw4u2oSx5g6K1Ws
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 1/27/25 11:15 AM, Jan Beulich wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:a615a96e-95d2-442f-b57d-0bb51142c977@suse.com">
      <pre wrap="" class="moz-quote-pre">The original implementation has two issues: For one it doesn't preserve
non-canonical-ness of inputs in the range 0x8000000000000000 through
0x80007fffffffffff. Bogus guest pointers in that range would not cause a
(#GP) fault upon access, when they should.

And then there is an AMD-specific aspect, where only the low 48 bits of
an address are used for speculative execution; the architecturally
mandated #GP for non-canonical addresses would be raised at a later
execution stage. Therefore to prevent Xen controlled data to make it
into any of the caches in a guest controllable manner, we need to
additionally ensure that for non-canonical inputs bit 47 would be clear.

See the code comment for how addressing both is being achieved.

Fixes: 4dc181599142 ("x86/PV: harden guest memory accesses against speculative abuse")
Signed-off-by: Jan Beulich <a class="moz-txt-link-rfc2396E" href="mailto:jbeulich@suse.com">&lt;jbeulich@suse.com&gt;</a></pre>
    </blockquote>
    <pre>With getting proper Acked-by/Reviewed-by:
  R-Acked-by: Oleksii Kurochko<a class="moz-txt-link-rfc2396E" href="mailto:oleksii.kurochko@gmail.com">&lt;oleksii.kurochko@gmail.com&gt;</a></pre>
    <pre>Thanks.</pre>
    <pre>~ Oleksii
</pre>
    <blockquote type="cite"
      cite="mid:a615a96e-95d2-442f-b57d-0bb51142c977@suse.com">
      <pre wrap="" class="moz-quote-pre">
---
RFC: When scratch2 isn't %r8...%r15, the MOV, CMOVNB, and XOR will have
     unnecessary REX prefixes emitted, as users of the macro pass in 64-
     bit registers. Similar to what was done to be able to use SETcc (in
     the earlier alternative code sequence), we could derive %e.. from
     %r.. to shrink code size some; there are a few dozen instances of
     this code, after all. (An alternative, requiring to touch the use
     sites, would be to constrain the scratch registers to rAX...rDI and
     pass in only the last two characters of the names [e.g. "di", i.e.
     also without the leading %]. That would make it straightforward to
     use both %r.. and %e.. at the same time.)
---
v2: Drop the non-RCR alternative.

--- a/xen/arch/x86/include/asm/asm-defns.h
+++ b/xen/arch/x86/include/asm/asm-defns.h
@@ -1,3 +1,5 @@
+#include &lt;asm/page-bits.h&gt;
+
 #ifndef HAVE_AS_CLAC_STAC
 .macro clac
     .byte 0x0f, 0x01, 0xca
@@ -65,17 +67,36 @@
 .macro guest_access_mask_ptr ptr:req, scratch1:req, scratch2:req
 #if defined(CONFIG_SPECULATIVE_HARDEN_GUEST_ACCESS)
     /*
-     * Here we want
-     *
-     * ptr &amp;= ~0ull &gt;&gt; (ptr &lt; HYPERVISOR_VIRT_END);
-     *
+     * Here we want to adjust \ptr such that
+     * - if it's within Xen range, it becomes non-canonical,
+     * - otherwise if it's (non-)canonical on input, it retains that property,
+     * - if the result is non-canonical, bit 47 is clear (to avoid
+     *   potentially populating the cache with Xen data),
      * but guaranteed without any conditional branches (hence in assembly).
+     *
+     * To achieve this we determine which bit to forcibly clear: Either bit 47
+     * (in case the address is below HYPERVISOR_VIRT_END) or bit 63.  Further
+     * we determine whether for forcably set bit 63: In case we first cleared
+     * it, we'll merely restore the original address.  In case we ended up
+     * clearing bit 47 (i.e. the address was either non-canonical or within Xen
+     * range), setting the bit will yield a guaranteed non-canonical address.
+     * If we didn't clear a bit, we also won't set one: The address was in the
+     * low half of address space in that case with bit 47 already clear.  The
+     * address can thus be left unchanged, whether canonical or not.
      */
     mov $(HYPERVISOR_VIRT_END - 1), \scratch1
-    mov $~0, \scratch2
+    mov $(VADDR_BITS - 1), \scratch2
     cmp \ptr, \scratch1
+    /*
+     * Not needed: The value we have in \scratch1 will be truncated to 6 bits,
+     * thus yielding the value we need.
+    mov $63, \scratch1
+     */
+    cmovnb \scratch2, \scratch1
+    xor \scratch2, \scratch2
+    btr \scratch1, \ptr
     rcr $1, \scratch2
-    and \scratch2, \ptr
+    or \scratch2, \ptr
 #elif defined(CONFIG_DEBUG) &amp;&amp; defined(CONFIG_PV)
     xor $~\@, \scratch1
     xor $~\@, \scratch2
</pre>
    </blockquote>
  </body>
</html>

--------------MeY1ENnMmOw4u2oSx5g6K1Ws--


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 10:57:14 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 10:57:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877699.1287835 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcMnn-0007ZI-Th; Mon, 27 Jan 2025 10:57:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877699.1287835; Mon, 27 Jan 2025 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 <xen-devel-bounces@lists.xenproject.org>)
	id 1tcMnn-0007ZB-Qk; Mon, 27 Jan 2025 10:57:11 +0000
Received: by outflank-mailman (input) for mailman id 877699;
 Mon, 27 Jan 2025 10:57:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=O4xJ=UT=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcMnl-0007Z3-Sc
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 10:57:09 +0000
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com
 [2a00:1450:4864:20::62a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 74113671-dc9d-11ef-a0e6-8be0dac302b0;
 Mon, 27 Jan 2025 11:57:08 +0100 (CET)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-aaeef97ff02so711037066b.1
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 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
 a640c23a62f3a-ab6760ab0bcsm569339766b.95.2025.01.27.02.57.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 02:57:08 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 74113671-dc9d-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737975428; x=1738580228; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=J0JWhd+/Gtr38oYfFIiqC5hteKmC0+hQCXF2FGzYW+Q=;
        b=QlsUoNI1uxNYT2rzyjOu78b+Kl6jqQP7GRAa/oXKqH0zj8drx7Ozzxba1VlJkmVenK
         XfRkHtg68lEI4bvXA3dKQItmibJDsvb/SoZKJzmz3hAc1mzAreZRxExMcwkHvsQrVOdE
         A0r+pXgMOyXt3N9dIgGEiLi7Z6yw1mbi4DW/dmQyQj8l3bwSImKWp5XM36/pshN3MAkI
         0gkttDICgTIIiemBhMixAGaltcqBCa+jw+kqCHW7mcIEauycv+CmOseUc2BdzI7MGJN2
         1Z++fcmfd1HjGDwj2hpXNowWA00NRGHu9IzTt+Hbbh4QLvLJMjgtd+5U/hBd+U/t1fOj
         AiIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737975428; x=1738580228;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=J0JWhd+/Gtr38oYfFIiqC5hteKmC0+hQCXF2FGzYW+Q=;
        b=RWedaispxN55VHN1GgAsmzDnrUyYVEsn0aIf/ulR+pxQGTqEvovQE35hxAFXXfQBjg
         /tFkJF1Dpvzn0GOmqjHIwNZaEzmgK8nyA70M/1U8vnUn+Y6izrrxEnpGLV0t73cN6XtQ
         1/SSD/FSo9O/vVStlHMjRCqoBJNIkgsemNSNDeuYLKDj4YcWGCYV1XEZ1SakkLhgH3e6
         KaZBuN5ym9wWDEU2b/cFWiWlMr0ZWrDCGsHlkK5IkotP6irUsZYK02KVmgLQ/wIQJg7m
         Qmx3VI5oeWv0jnwnLUplXgRk66xeZAgb5E2LI+lVe1pw7/fm90UVSh18lclN+sEtQVQ3
         xa2A==
X-Forwarded-Encrypted: i=1; AJvYcCW7FedSBMGicmWkH1m9ZTlb2nfq3DgKRHIhp10j2Ay43qbklXkqLddJO9lfi3MymDhHJFZbzL7J4YQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwOKLSJR7WdE0T8GCnyA/VRcQ0Gcw3gswrOoyh7RZxYgw2ccw37
	PUuETR9/nKnesf2p3imdTsGJ/hwEDFX5nU+N98QtLL+kT88KIA4f5XZlM6+T+w==
X-Gm-Gg: ASbGnctDaIaNLvYIqGeJxhEgPbAcdTfkm1aQZlJNJ2wN3OOq3q6YGFdA7AGZdmcmu8V
	nNlQmrrXF9BZXpZXgMcWFDcttIBmyeUSSVxjSAbXBF8t0TqxmjKO8ZFrckOTzQkD17CA2i2cNoc
	tn/m8ffd2kjFscHDsyagDUGCpVhZTwxk8d6wRQzB7oZESTe6XfLB+siEga0ie99SbNfEVXsrklu
	635P+VnksQ0pQKxVyW2uLOYuQB9QP4kSgqjDSbBaEE1khWjt4jq0UH5xnv7/rQ0XufH5+4orxr5
	ab1GpgqBF6XRd7pP5/C06TeIgHilfYz19xUeSFZU2FxpxJSVL0A95vPA/m3tGE68ww==
X-Google-Smtp-Source: AGHT+IH4EaBBQ022jsYWWDuo1/XXsbjFWkgxKWofNbk4VvIp570pfJs9zy4DFbdZT1PJQb9F6bn00g==
X-Received: by 2002:a17:907:94cb:b0:aa6:423c:850e with SMTP id a640c23a62f3a-ab38b29954bmr3632009466b.27.1737975428276;
        Mon, 27 Jan 2025 02:57:08 -0800 (PST)
Message-ID: <4011a01c-acbd-4ef4-b6f8-d266f6623289@suse.com>
Date: Mon, 27 Jan 2025 11:57:10 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 09/12] x86/mpx: Map/unmap xsave area in in
 read_bndcfgu()
To: Alejandro Vallejo <alejandro.vallejo@cloud.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20250110132823.24348-1-alejandro.vallejo@cloud.com>
 <20250110132823.24348-10-alejandro.vallejo@cloud.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250110132823.24348-10-alejandro.vallejo@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.01.2025 14:28, Alejandro Vallejo wrote:
> --- a/xen/arch/x86/xstate.c
> +++ b/xen/arch/x86/xstate.c
> @@ -1024,9 +1024,10 @@ int handle_xsetbv(u32 index, u64 new_bv)
>  
>  uint64_t read_bndcfgu(void)
>  {
> +    uint64_t bndcfgu = 0;
>      unsigned long cr0 = read_cr0();
> -    struct xsave_struct *xstate
> -        = idle_vcpu[smp_processor_id()]->arch.xsave_area;
> +    struct vcpu *v = idle_vcpu[smp_processor_id()];

Question on this one remains: Can it be pointer-to-const (in the longer
run; certainly in can be right now)?

> +    struct xsave_struct *xstate = VCPU_MAP_XSAVE_AREA(v);

I realize my similar remark on this one was actually wrong; the asm()s
clearly modify what is being pointed top.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 11:01:46 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 11:01:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877706.1287845 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcMs9-00010q-Dn; Mon, 27 Jan 2025 11:01:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877706.1287845; Mon, 27 Jan 2025 11:01:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcMs9-00010j-AX; Mon, 27 Jan 2025 11:01:41 +0000
Received: by outflank-mailman (input) for mailman id 877706;
 Mon, 27 Jan 2025 11:01: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 <SRS0=O4xJ=UT=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcMs7-00010X-V1
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 11:01:39 +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 151b4b52-dc9e-11ef-a0e6-8be0dac302b0;
 Mon, 27 Jan 2025 12:01:39 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-aaf3c3c104fso152253566b.1
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 03:01:39 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab675e631cesm575869566b.52.2025.01.27.03.01.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 03:01:37 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 151b4b52-dc9e-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737975698; x=1738580498; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=0KXnLSIVpK5QQcBSoQQgz9SzN2vucma4NP2Dl3284TY=;
        b=YnUenL+YV03Je6bZuuphzVQSgkJ3Bnt/YvxdcCVFEa876ikrcvvlcVoDJ401PsmPIE
         haYVSEoislm3OndZqxMqUCKulbusQvpZhWgu28bOjx7drMPHpBfU/yqKdzmqLljU4WMy
         P4dwOIvhbimCMLtYjo97rHAFcBdC1Uw5/canNJngC5fDfa0x1rwzMz8bR99NuGtYmZl8
         Z8cLRYoHpk/pG4uJDpNnYbLUSbaFNWirS/MfG9FvMPIPMWvtng+zMRAccxNxvwzpDIFK
         mIDWEX33/YQGd4SF6wkbeIf+lHN+gEgptA/DWNj5zaY9+Aucem23EiGpIWASeu6uds+L
         5WgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737975698; x=1738580498;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=0KXnLSIVpK5QQcBSoQQgz9SzN2vucma4NP2Dl3284TY=;
        b=ee74PEwFoqC6wuTx5SE64a4I6oUqB5Lj3xQmMi5nJTk4C25T8zI2lgxJx7QDgaVYzb
         jGcBtZi+v7+5xxeA0HVVgnLjQynChck02JEUpJ21VdJD8edHaLu1vqDY35ZAJ8X8qCMf
         KXTL2wG827byGvivzm+jcIkvD52BK8I9fGgqTFdRSxUilyplLG4wvdM4qpmotCVguYsd
         09ynaEqhCzP3lv0utACEnCKzGkqBD85OyNWvYroow6NedYaPnEtfjdCtwqTiZqlxw04O
         UMYuH7ONInLFpfkIKDv+IBgIX5pii1q7EcXd6NcfNgWZsU5hEL4p4nSVxeGiBS+UhLiF
         s8dg==
X-Forwarded-Encrypted: i=1; AJvYcCVnJkzHm9Ml3rnelR8uZgMf3vU0VXsnzNwFjcZOPnm3OREq2opJS0l8RaZMQuesjBYQMhXnQIJRETI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwGPY0NcCSs0rGHBeIn12N39v9s55KXdfqCoeooC5+qVyy2GH3W
	m35lAuUaNma+lXiyzyYQFpIHodeAJZ+Y+KjQ52plQgtS6TFtScKm1zNgpT31isF/CVwPx1/Wzr8
	=
X-Gm-Gg: ASbGncuIpduIXt/T7uPL8Ht1ReffxexD0+zjt4N2DzC4rq8t41NWC0zT8+Dl3SCwT3i
	6N21aqVDZsgZExVEPAUxXOiUvhFMKAquw1sBDEx+0ivv3eakY0KTcE4yUAU7n0f0A/vBHPKPdLg
	+QBwXFkNPeLctOpw9kjfdFWQste6DBxCl6ja+8a7zSEfnH+L9JmgD44CQBIQe/ett0j2RpBgv1b
	OvlDbuxRH/K79kJ+ojULWRK+y0UYsnqj9l3rfUgLWdr+xsf14kBh1g60BIqSANod6Rlse2/5pyi
	QNHNTKkclnVdcPA0oo0ufTVAnQKiNwBF38O0HeWtmCCNYwgsEZFhXHBzIOVGK/hzYw==
X-Google-Smtp-Source: AGHT+IGgTKeKiYtC4uiOIAUqAUNpGkzuUzQ0vsKUwh6Rgm1vjn9aq8J50PF6F8K5OFQPAGs2fzI66A==
X-Received: by 2002:a17:907:6d09:b0:aa6:8935:ae71 with SMTP id a640c23a62f3a-ab38b0b7f21mr3753786466b.12.1737975697800;
        Mon, 27 Jan 2025 03:01:37 -0800 (PST)
Message-ID: <5c0f2096-32ec-4d08-83be-6153f4a637e3@suse.com>
Date: Mon, 27 Jan 2025 12:01:40 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 10/12] x86/fpu: Pass explicit xsave areas to
 fpu_(f)xsave()
To: Alejandro Vallejo <alejandro.vallejo@cloud.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20250110132823.24348-1-alejandro.vallejo@cloud.com>
 <20250110132823.24348-11-alejandro.vallejo@cloud.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250110132823.24348-11-alejandro.vallejo@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.01.2025 14:28, Alejandro Vallejo wrote:
> No functional change.
> 
> Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
> ---
> v2->v3:
>   * const-ified v in fpu_fxsave() (missing in v2)

Sadly this has rendered ...

> --- a/xen/arch/x86/i387.c
> +++ b/xen/arch/x86/i387.c
> @@ -129,7 +129,7 @@ static inline uint64_t vcpu_xsave_mask(const struct vcpu *v)
>  }
>  
>  /* Save x87 extended state */
> -static inline void fpu_xsave(struct vcpu *v)
> +static inline void fpu_xsave(const struct vcpu *v, struct xsave_struct *xsave_area)

... this line too long now. With it suitably wrapped (possibly doable while
committing, if no other reason for a v4 appears)
Acked-by: Jan Beulich <jbeulich@suse.com>

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 11:06:03 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 11:06:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877718.1287855 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcMwL-0002RH-1J; Mon, 27 Jan 2025 11:06:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877718.1287855; Mon, 27 Jan 2025 11:06:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcMwK-0002RA-Ur; Mon, 27 Jan 2025 11:06:00 +0000
Received: by outflank-mailman (input) for mailman id 877718;
 Mon, 27 Jan 2025 11:06:00 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=O4xJ=UT=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcMwK-0002R2-5X
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 11:06:00 +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 afa2ec7e-dc9e-11ef-99a4-01e77a169b0f;
 Mon, 27 Jan 2025 12:05:58 +0100 (CET)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-aab925654d9so836683966b.2
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 03:05:58 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab675e12090sm562093066b.29.2025.01.27.03.05.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 03:05:57 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: afa2ec7e-dc9e-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737975958; x=1738580758; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=NNHBCSlOcRiuXlHNRAgql38aYjNqbCAxYmxfI+H8MNE=;
        b=Tso65KdtZlq5qJr/jCcFu5mDaP8ZbJMaq1cI997Vo86M1ZNUkdEkyLS+Hc+AiRhIt2
         8fwPs60Jbf8THKbq/sRPQBMEyd7P/mP8pd4dhUNRS4ngZjx36Blbbdl6NQpFCvYMP27k
         rp1+yKOL5snZlTqWW01Eg9IKyQKrwvUfMbMRGebOsr3+MenK63p56Fj+B9aMeS+hCaXj
         IiCxVQONbZ9OzM0/eFRW/dgRaaa9pTA7gO+1rC15Ie9+f52oq8AZH+5OhOfNYhyiI9+2
         zuC/jIs8Z4nBIcktdLYIIqqexcoZAALt+MUhHAB0UAPxeQ+rjGFiRods3/BAiET0itay
         kElg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737975958; x=1738580758;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=NNHBCSlOcRiuXlHNRAgql38aYjNqbCAxYmxfI+H8MNE=;
        b=kp28ugTPteJTD/8Kdj5BqhuKreAUAZyimqqR21JDV7xUpfNZ2spxEFFlN7mfNQcyr/
         TqNGOL/1QtqjRPMPeBFhw0u06D6c5Sx+0aa27GDscvQv/SlwRp8Bg+lR1mpUDycx6/N6
         uVr8rFKBZGf/ShNJppL5sXMaYoFE1kwleAmpiYqAUDqan+HfgOjLoZT9s9DEZXC4B8sz
         3wTIXV5gaTq2cHtl9YC1ZSmdk7w/6kaCSrGw/BgO52pVdKHaTjy+UsVP1uJnQFCISMv8
         Dqs4c/kTWy6sAR2ryPCl56PV69cj1HtOkoYT2a9tHJXEupM7Dr9Nbf1LwPrvUOAAMYdb
         125g==
X-Forwarded-Encrypted: i=1; AJvYcCVdbRJ72j4Lj0yFTuOdfJUbz9SBEEEtlEBsLh+XaMYOcLVXAoRcrirKIFoq/IXd0MI8i1s9SBQa1Nc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzZ5vXnaqF/TaTeq6Gq69o4QFs7pWcuGkzw556h0DK3KdgJfrUX
	yVw92FLJCslAPC4+1kZ2W9iek1Ay/+LeEpt0sHjVfrON9Xz3onAwBS9sZNkhWg==
X-Gm-Gg: ASbGncv7MZs3/kUWTFhNh0xbmPKv9KPgxoOn+fDmqY/NPQSWdX/J+HCGp9xgUbocmAi
	cAVRyCVLArOL2SHJCCQlJWMg/lsa6e7aQBgnvhlHGA922fpWzBzuKlirTZoQu5Wo30yrObC68AG
	koQ1n60QhCscNVKSY7Spf7Q2VgS7dAwHfH4yFpTroj741u/qHzk7DImzQWlyBJALyF8jR/KqiWY
	YyfHdKVbLCE0UCxEboox/83u/m18eI6iYIE0uqR0k1BbNcBxXqYDzY7UbyTDnSqEzIX3HbXo6LN
	i5wbv8h0KgRLM/G8tt1AWx5qdWcLMCn9xHK4CZbYB0zBHnWCKD3r4aW43XPRY26pzw==
X-Google-Smtp-Source: AGHT+IH8bQdzTmZHSVkjgbBbLgsVKMx9tVeB3fK7uMCAGX6OGMWZfFrPxhY74Ys+0Z78b5yxRrOkiQ==
X-Received: by 2002:a17:907:3e9b:b0:ab2:bd0b:acdf with SMTP id a640c23a62f3a-ab38b43bc08mr3824307366b.36.1737975957663;
        Mon, 27 Jan 2025 03:05:57 -0800 (PST)
Message-ID: <1f1ab2d4-73ad-4562-b3c5-0b423b56aed2@suse.com>
Date: Mon, 27 Jan 2025 12:05:59 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 11/12] x86/fpu: Pass explicit xsave areas to
 fpu_(f)xrstor()
To: Alejandro Vallejo <alejandro.vallejo@cloud.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20250110132823.24348-1-alejandro.vallejo@cloud.com>
 <20250110132823.24348-12-alejandro.vallejo@cloud.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250110132823.24348-12-alejandro.vallejo@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.01.2025 14:28, Alejandro Vallejo wrote:
> No functional change.
> 
> Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>

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

> ---
> v2->v3:
>   * const-ified v in fpu_xrstor()
>   * Removed v in fpu_fxrstor()

On this basis the parameter could also be removed from fpu_fxsave(), by
passing in fip_width instead.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 11:12:17 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 11:12:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877725.1287865 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcN2B-0004Xr-N5; Mon, 27 Jan 2025 11:12:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877725.1287865; Mon, 27 Jan 2025 11:12:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcN2B-0004XT-J3; Mon, 27 Jan 2025 11:12:03 +0000
Received: by outflank-mailman (input) for mailman id 877725;
 Mon, 27 Jan 2025 11:12:02 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=O4xJ=UT=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcN2A-0004W9-0C
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 11:12:02 +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 87470e83-dc9f-11ef-99a4-01e77a169b0f;
 Mon, 27 Jan 2025 12:12:00 +0100 (CET)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-aafc9d75f8bso813399266b.2
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 03:12:00 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab693c63541sm316732166b.67.2025.01.27.03.11.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 03:11:59 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 87470e83-dc9f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737976319; x=1738581119; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=9BLjtbNMLBZ5w8uegTIY6Tfu0zDz5HDRnWszrYj6B6g=;
        b=NqTxZ3KVWAbE/9mCWLNkk9n8vJCrfQzYGa9b467eup++OpUQ502I1gtcu9l3mE8TuQ
         A8pPmdHsG4g0/duH5bPfHAdQ+eKJ8UY+Fd5w35w2WP+1f5SlVIWjUL1YW2stwRxn5hBE
         G5WA9PgaqoFsE4B3YbdWy4smFZ+VcXaviEd48EkzgTcwM9XKMCR2ptBCuvFtueSEI9tS
         2QlvepQTt7OUOb4nYV5FpV1h65ekOD8cGckXFEf62+lJuu3C/FFTALB150pDTpdnIj0a
         01YcUMjAV6zjiiJu+8ZG/bWrISYIr/oMpmU6g/VeEkFUoVT5OILzuMNl6ZMxd2Olm1BM
         GfQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737976319; x=1738581119;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=9BLjtbNMLBZ5w8uegTIY6Tfu0zDz5HDRnWszrYj6B6g=;
        b=EYqvnC+Skjf7OTHAqI2oQkJqHd6KbXoMQSuobm3oZbxWgmUcLwl82uk9sDHGcsDjAO
         R6D4ZyStVTZvpXCn942cGCOyby2+7ZxbN0F+saMjvbJ/6W5pSFm6UH0t408dgRZDWufx
         AgXTFbBP/l+9OAHve971rGf+YEmqR80YSvNUWwhK1M3ZtYnqiFYfWIgJSri42BojaMPx
         Od3v6Urc0DPWRdANur4OjL6ZEh4eM+5SAJhMjCGsUWVmp41xp8vQdLqHQDcXG2iz9p8W
         +X+zbdjkeYljZwYVX53nZI4kekdLnlHLWbr5ZgxWYJ8DMNoAL4gp24+CJbrvminFOgcg
         6WKA==
X-Forwarded-Encrypted: i=1; AJvYcCUYXWAFwnqXe4xJBIi9ro+iXW1Xr9pixdn/6HyykdPbV7yO/85nPk/zLR2jzV/c6ZYh36If3aAZre8=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw4mUgLnUOYn3ANBfZST3RmwXL9pyVDgb3NiS/mJ6Q0Oynn4lwt
	p02fRAPRwUjAXs8BVtW40hLVty7hHb7AWnBWU//0bI7vOy9dyjc9TRQ28JJSEw==
X-Gm-Gg: ASbGncszIW5qsv0WiJaum6MaNM0CaYxL/Ul/OToiBlyF+bT6tThhfRkOvtSc8Zi8EAJ
	pK1HB+p2fThiQb+S+rahZcN1I2nAHAYc51PzSbsY87K2vxNKKVZEWAtv+xropEROLYlWe8jnYX3
	dm4gcw6FjkglZNfrrzOSGIyMkqver7c5Rly2hP9xorGs33qKAtbRffuIto2aKfaGrku2h3rsHM/
	TZ/NnZ1Ts7bWAthu4iRNCPl22X+nqyxqNh5xn/fh9W1LhzgIc5PcLi35oF/C4TSSqaDHY6JJLpb
	XpWldJ5NRco8EsmvzMMVQ95nbvb8aJBcN+y8f/YfM2ZLS1EhY1TINC7oWjJMOPUHEw==
X-Google-Smtp-Source: AGHT+IEAEdk/RqrYYymah7FRX5KJ+Fp7SUGg427RKIRz1nTOIGFLHCiwWjlW3qBBiGVsXFYxy5+X4Q==
X-Received: by 2002:a17:907:60cc:b0:aab:c35e:509b with SMTP id a640c23a62f3a-ab38b4bb44bmr3656920766b.55.1737976319384;
        Mon, 27 Jan 2025 03:11:59 -0800 (PST)
Message-ID: <f8d4a1d4-a332-4dad-ba6e-5a127ae2187e@suse.com>
Date: Mon, 27 Jan 2025 12:12:01 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 1/9] xen/common: dom0less: make some parts of Arm's
 CONFIG_DOM0LESS common
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
 <julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <cover.1736334615.git.oleksii.kurochko@gmail.com>
 <396a60496844c8a86667f4ee57c5bedc9899f5ad.1736334615.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <396a60496844c8a86667f4ee57c5bedc9899f5ad.1736334615.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 08.01.2025 12:13, Oleksii Kurochko wrote:
> Unify the API for creating DomUs and checking for Dom0less mode across
> architectures, including Arm and RISC-V, with potential applicability
> for PPC.

That is you mean to re-use it for RISC-V?

> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -12,6 +12,15 @@ config CORE_PARKING
>  	bool
>  	depends on NR_CPUS > 1
>  
> +config DOM0LESS_BOOT
> +	bool "Dom0less boot support" if EXPERT
> +	depends on ARM
> +	default ARM

This then would better be converted to "depends on HAVE_DOM0LESS", which
for now only Arm would select. With a dependency on XYZ the default also
doesn't need to name XYZ again, i.e. can simply be "default y".

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 11:15:19 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 11:15:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877733.1287875 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcN5B-0005h9-3z; Mon, 27 Jan 2025 11:15:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877733.1287875; Mon, 27 Jan 2025 11:15:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcN5B-0005h2-0R; Mon, 27 Jan 2025 11:15:09 +0000
Received: by outflank-mailman (input) for mailman id 877733;
 Mon, 27 Jan 2025 11:15:07 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=O4xJ=UT=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcN59-0005gu-IZ
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 11:15:07 +0000
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [2a00:1450:4864:20::534])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f67523d5-dc9f-11ef-a0e6-8be0dac302b0;
 Mon, 27 Jan 2025 12:15:06 +0100 (CET)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-5d9b6b034easo8520136a12.3
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 03:15:06 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5dc186183eesm5267645a12.10.2025.01.27.03.15.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 03:15:05 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f67523d5-dc9f-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737976506; x=1738581306; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=UCJ5XuZJ+PJiMDlji/FAG2eL5A9cqn6zQ2h8ERWqJN4=;
        b=dddSMqhFlv/KiQYb6gB63nWMiNZiybe1XcZ1fXKQ0Dw2QfyS6UjrJtt9LBJ9kjHLTF
         LxJHSk14NtXJQ3ckLTkqaLmVkD1TOXm+yZbS6wNZ4B/khUp1T8zlPwj3hm8IRgtM+Lkz
         7pLSRcwqaDSM8P9lvMs4nN8C/h7a8CokkFhSbCS2EsLTOhX2Br77//fU2nxyY84OrZQY
         Tny7MiSWCoBu0ddvB5I0kubGi6vsPNlqvTrUbNfc/hTdkKlBtEukBWpJdABP6xJsaUwE
         tmAwg0jS7jevXq3h98rRIiucpIuSW/9i3mEHY7W2ZA6H0CcjWKLx8gRuHrPTsYOuncgI
         qoWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737976506; x=1738581306;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=UCJ5XuZJ+PJiMDlji/FAG2eL5A9cqn6zQ2h8ERWqJN4=;
        b=MSOFokS8cVd1UgpAhcN08U38DB0xZ8V5Hfk0CaZV7cDg+yDTFs57LOyCIB5wujZJ9U
         Bf+i111wFsFE48TA7Yvg/Bue7yJ3hXa40Z790tp1iteHB6KV7ZC6WsbulY9ssjLUvwqT
         DdKnAlFNfn5cMa2ZrSZFDKb38aF5VimId0R1uOLOTUXH07Afx4Od9i6/igdCUG2P1Yxj
         h7HC//Hh6e4GK0HXpm+5t8u86WJ4KRhsDMXJRDyOeNkl7S3I5XL7LQi888rzvZs5ogLB
         07T//8pE8Fq3QvTb01wD64pbiLAYnpgpLMp7RxyRh9r8h3ArOAc4tXW0r05vC2wCCHIH
         zkCQ==
X-Forwarded-Encrypted: i=1; AJvYcCWmE2ZwVzj0X0oXZ9JApg59DeRVMpH5wpKmQ7hQs4tB/ODdUedTeMa285yYfBqbOzS3RmrUgTvzMew=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy4yPLgfxMEDX7yWT/fYpG3baC1YUWRDRmrW0Hy/8hpHFQnvqjp
	wHN5xAGkapqvF6vZLSI0/cN65Jg7ZvTBFNk6ZoIgbPZ9g7+2DE2Cv8vBhrFu2A==
X-Gm-Gg: ASbGnctHQt6kMQQZuzyUrd3XpdSHpMHyxm0dletP8iZPU+hyN+qsdSDDGMhZUBZp8sQ
	SeuC/gOLkPlNNqU4qSG/n5z0LjQcPxCl0/uShsNxSj7XQ98OcLasTAO4SpJDjnAhsS0AF6iVcWv
	0LHgAuklzaelgZ+0c73KGL0H3PztfKmJ8fVOuBXDQo3kWsD1aPoNxnC2dq0IaUKVqlKw5hUUzlj
	e/x6Lnngd2kgmeSyJ5zBl4ty678uSChB13Q7e8hQ4s1LeLiwju+O4zMCcIEh+5c6Jdfh1D5Wsha
	arBi89iook7I7/smWGgujds/1hyARQjhRfwGF3xdr3ltBELAppUGOyIu8TCta6OEwg==
X-Google-Smtp-Source: AGHT+IGHplv2Hzunxl8A4zXSTgfUnZjSWCkfgGRYjL009Q18yAu88aXaGHX5MYflHizB9bhR7AH4YA==
X-Received: by 2002:a05:6402:1d4e:b0:5db:fcb0:e52b with SMTP id 4fb4d7f45d1cf-5dbfcb0e88amr17490011a12.24.1737976506185;
        Mon, 27 Jan 2025 03:15:06 -0800 (PST)
Message-ID: <2f14762e-d302-483c-8adb-3223e6290de0@suse.com>
Date: Mon, 27 Jan 2025 12:15:08 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 2/9] asm-generic: move parts of Arm's asm/kernel.h to
 asm-generic
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
 <julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <cover.1736334615.git.oleksii.kurochko@gmail.com>
 <6404cb5ae077909cbfdf3860d38c701c65547b56.1736334615.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <6404cb5ae077909cbfdf3860d38c701c65547b56.1736334615.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 08.01.2025 12:13, Oleksii Kurochko wrote:
> Move the following parts to asm-generic with the following changes:
> - struct kernel_info:
>   - Create arch_kernel_info for arch specific kernel information.
>     At the moment, it contains domain_type for Arm.
>   - Rename vpl011 to vuart to have more generic name suitable for other archs.
>   - s/phandle_gic/phandle_intc to have more generic name suitable for other
>     archs.
>   - Make text_offset of zimage structure available for RISCV_64.
> - Wrap by `#ifdef KERNEL_INFO_SHM_MEM_INIT` definition of KERNEL_SHM_MEM_INIT
>   and wrap by `#ifndef KERNEL_INFO_INIT` definition of KERNEL_INFO_INIT to have
>   ability to override KERNEL_INFO_SHM_MEM_INIT for arch in case it doesn't
>   want to use generic one.
> - All other parts are left as is from Arm's asm/kernel.h
> 
> Because of the changes in struct kernel_info the correspondent parts of Arm's
> code are updated.
> 
> As part of this patch the following clean up happens:
> - Drop asm/setup.h from asm/kernel.h as nothing depends from it.
>   Add inclusion of asm/setup.h for a code which uses device_tree_get_reg() to
>   avoid compilation issues for CONFIG_STATIC_MEMORY and CONFIG_STATIC_SHM.
> 
> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

I question that what is being moved qualifies for asm-generic, an in particular
for a header named kernel.h. Some of what you move may make sense to move to
dom0less-build.h instead. But everything that doesn't fit there needs to find
a different home, imo.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 11:17:30 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 11:17:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877741.1287884 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcN7D-0006Gr-Ev; Mon, 27 Jan 2025 11:17:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877741.1287884; Mon, 27 Jan 2025 11:17:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcN7D-0006Gk-CE; Mon, 27 Jan 2025 11:17:15 +0000
Received: by outflank-mailman (input) for mailman id 877741;
 Mon, 27 Jan 2025 11:17: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
 <SRS0=9dXK=UT=redhat.com=vschneid@srs-se1.protection.inumbo.net>)
 id 1tcN7B-0006Ga-Ms
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 11:17:13 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3ff4dc6a-dca0-11ef-99a4-01e77a169b0f;
 Mon, 27 Jan 2025 12:17:10 +0100 (CET)
Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com
 [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-424-6qqBBGn8Ow-TmUI9ZILVYw-1; Mon, 27 Jan 2025 06:17:08 -0500
Received: by mail-wm1-f69.google.com with SMTP id
 5b1f17b1804b1-4388eee7073so25119425e9.0
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 03:17:07 -0800 (PST)
Received: from vschneid-thinkpadt14sgen2i.remote.csb
 (213-44-141-166.abo.bbox.fr. [213.44.141.166])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438bd48a145sm128093025e9.16.2025.01.27.03.17.03
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 27 Jan 2025 03:17:05 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 3ff4dc6a-dca0-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1737976629;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=0llw80E8nAjg6kMfEOzoPei4nanpbue7YefsY9gW++w=;
	b=COsELM3dgMzqvxES3yiE/1iCKTW6mckRJV7B8/AVvEmfEs3SAt58Asoo0IgFILoNYu5k29
	fBFSTjEQXJS4MWwknSPRBkiv8c2Xy/Cc+zdBfzbAHLOzoyM7Z/f6FRWzeb8BFXztoPRlie
	qe9GX2oHEkEnaCuf0iM8NV5Gi4TtJI8=
X-MC-Unique: 6qqBBGn8Ow-TmUI9ZILVYw-1
X-Mimecast-MFC-AGG-ID: 6qqBBGn8Ow-TmUI9ZILVYw
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737976627; x=1738581427;
        h=content-transfer-encoding:mime-version:message-id:date:references
         :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=0llw80E8nAjg6kMfEOzoPei4nanpbue7YefsY9gW++w=;
        b=jzwhF9MzKwzEPGZI2D/tLlSeU0PZelpLnn8vs68+apPz5tmj7fllW5mBmErshj4OvL
         o9SOJAZXiO8h6A0Je42I+9s4WCNKP8TSTHbweRAMDhTEPuXua9m8+Iek29W0sooPHV2O
         lCRFUVtRnz+k+OB7S2jR1ztZCOhr+Qk9qmJJ5YhOYt25McgMh52AJSlNfKRn9kMNHgcX
         HdmSE9MxAklzr3xlt4UbL4P6I8RX8D6FP6i35zazQb22YShPn5bLw1pMsVGdyuTFPJkc
         qr7yJ+eZtkrMynUtwBEjB2tVXPjyKE4klcuXA5nlo1UBXmUcs0HqGshkzmfyDfI+ARSG
         Nftg==
X-Forwarded-Encrypted: i=1; AJvYcCXyNxa2alMeeRo3IGslcgveFarX/Qgo4JF6yNYuBewJlvGMfTL9Mi9x69nZjOFSpnL5cwQlM48Be3k=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzJHrsRrDpNZ7vsR68n32unqrLpAQB254JiSh2XNbbVvZP7g29p
	mO3oSLSiL74Q1ey96DPtXDNp9DU7lYgsNRvXh8ewER4t5Y9dgmyAlQlj03xz5fWQTtzhd+e6VGJ
	5oonGeWP2nUUD+1fBdDBhl1SX7dxiiqPnMPZN3PS7Ph8McuVZO9sXPWlzKMty1NX8
X-Gm-Gg: ASbGncvoi14cX1uqGPKSbYvxUhDOmg7CNWJwPgExUKwFTCg3g5mgti9mfRKFuiqV1Vg
	fRw2CND2EumO2R3veuqbdmjZ5vbXA/FYPCMtjTFnDi5od7T47WGxoUUZLMIHCRujVAMvuYxMCvE
	1OOBzCfCTLUSZYpQNG/G/NAjhgpRJ51vfZuwl/x2nCmfhsE0Oi68FS9qX0pI8rTYkaO2avPeJT6
	84E4Dv/TK/hbaNenAzTaD34cI50fbOZ29RpHjAiv8u+K2ZwihF7fPj7Lr/AVDJ4/AlVT7lx5v5Q
	+po6bITiOK0BXmuHS6f3rlu/TkIqU5oL4sSVrnREP4h8FiSF4U5a20Q7FaeJ1U6lsA==
X-Received: by 2002:a05:600c:6d46:b0:434:92f8:54a8 with SMTP id 5b1f17b1804b1-438bcfd440dmr101053225e9.0.1737976626882;
        Mon, 27 Jan 2025 03:17:06 -0800 (PST)
X-Google-Smtp-Source: AGHT+IE5ZBkhc7Mo57S55YqkWjUaKcE0DvJ7v1EsH72AA8CbL1E0vvN/eQHzrpNG4sI4i71C/vJTUQ==
X-Received: by 2002:a05:600c:6d46:b0:434:92f8:54a8 with SMTP id 5b1f17b1804b1-438bcfd440dmr101052395e9.0.1737976626396;
        Mon, 27 Jan 2025 03:17:06 -0800 (PST)
From: Valentin Schneider <vschneid@redhat.com>
To: Frederic Weisbecker <frederic@kernel.org>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
 virtualization@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
 loongarch@lists.linux.dev, linux-riscv@lists.infradead.org,
 linux-perf-users@vger.kernel.org, xen-devel@lists.xenproject.org,
 kvm@vger.kernel.org, linux-arch@vger.kernel.org, rcu@vger.kernel.org,
 linux-hardening@vger.kernel.org, linux-mm@kvack.org,
 linux-kselftest@vger.kernel.org, bpf@vger.kernel.org,
 bcm-kernel-feedback-list@broadcom.com, Juergen Gross <jgross@suse.com>,
 Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov
 <alexey.amakhalov@broadcom.com>, Russell King <linux@armlinux.org.uk>,
 Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>,
 Huacai Chen <chenhuacai@kernel.org>, WANG Xuerui <kernel@xen0n.name>, Paul
 Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>,
 Albert Ou <aou@eecs.berkeley.edu>, Thomas Gleixner <tglx@linutronix.de>,
 Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Dave
 Hansen <dave.hansen@linux.intel.com>, "H. Peter Anvin" <hpa@zytor.com>,
 Peter Zijlstra <peterz@infradead.org>, Arnaldo Carvalho de Melo
 <acme@kernel.org>, Namhyung Kim <namhyung@kernel.org>, Mark Rutland
 <mark.rutland@arm.com>, Alexander Shishkin
 <alexander.shishkin@linux.intel.com>, Jiri Olsa <jolsa@kernel.org>, Ian
 Rogers <irogers@google.com>, Adrian Hunter <adrian.hunter@intel.com>,
 "Liang, Kan" <kan.liang@linux.intel.com>, Boris Ostrovsky
 <boris.ostrovsky@oracle.com>, Josh Poimboeuf <jpoimboe@kernel.org>, Pawan
 Gupta <pawan.kumar.gupta@linux.intel.com>, Sean Christopherson
 <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, Andy Lutomirski
 <luto@kernel.org>, Arnd Bergmann <arnd@arndb.de>, "Paul E. McKenney"
 <paulmck@kernel.org>, Jason Baron <jbaron@akamai.com>, Steven Rostedt
 <rostedt@goodmis.org>, Ard Biesheuvel <ardb@kernel.org>, Neeraj Upadhyay
 <neeraj.upadhyay@kernel.org>, Joel Fernandes <joel@joelfernandes.org>,
 Josh Triplett <josh@joshtriplett.org>, Boqun Feng <boqun.feng@gmail.com>,
 Uladzislau Rezki <urezki@gmail.com>, Mathieu Desnoyers
 <mathieu.desnoyers@efficios.com>, Lai Jiangshan <jiangshanlai@gmail.com>,
 Zqiang <qiang.zhang1211@gmail.com>, Juri Lelli <juri.lelli@redhat.com>,
 Clark Williams <williams@redhat.com>, Yair Podemsky <ypodemsk@redhat.com>,
 Tomas Glozar <tglozar@redhat.com>, Vincent Guittot
 <vincent.guittot@linaro.org>, Dietmar Eggemann <dietmar.eggemann@arm.com>,
 Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>, Kees Cook
 <kees@kernel.org>, Andrew Morton <akpm@linux-foundation.org>, Christoph
 Hellwig <hch@infradead.org>, Shuah Khan <shuah@kernel.org>, Sami Tolvanen
 <samitolvanen@google.com>, Miguel Ojeda <ojeda@kernel.org>, Alice Ryhl
 <aliceryhl@google.com>, "Mike Rapoport (Microsoft)" <rppt@kernel.org>,
 Samuel Holland <samuel.holland@sifive.com>, Rong Xu <xur@google.com>,
 Nicolas Saenz Julienne <nsaenzju@redhat.com>, Geert Uytterhoeven
 <geert@linux-m68k.org>, Yosry Ahmed <yosryahmed@google.com>, "Kirill A.
 Shutemov" <kirill.shutemov@linux.intel.com>, "Masami Hiramatsu (Google)"
 <mhiramat@kernel.org>, Jinghao Jia <jinghao7@illinois.edu>, Luis
 Chamberlain <mcgrof@kernel.org>, Randy Dunlap <rdunlap@infradead.org>,
 Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: Re: [PATCH v4 22/30] context_tracking: Exit CT_STATE_IDLE upon
 irq/nmi entry
In-Reply-To: <Z5A6NPqVGoZ32YsN@pavilion.home>
References: <20250114175143.81438-1-vschneid@redhat.com>
 <20250114175143.81438-23-vschneid@redhat.com>
 <Z5A6NPqVGoZ32YsN@pavilion.home>
Date: Mon, 27 Jan 2025 12:17:03 +0100
Message-ID: <xhsmh5xm0pkuo.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
MIME-Version: 1.0
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: 9me6uozEWVqStNDV69xWT4h7W4jVdvPAoK3C5jluVxA_1737976627
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 22/01/25 01:22, Frederic Weisbecker wrote:
> Le Tue, Jan 14, 2025 at 06:51:35PM +0100, Valentin Schneider a =C3=A9crit=
 :
>> ct_nmi_{enter, exit}() only touches the RCU watching counter and doesn't
>> modify the actual CT state part context_tracking.state. This means that
>> upon receiving an IRQ when idle, the CT_STATE_IDLE->CT_STATE_KERNEL
>> transition only happens in ct_idle_exit().
>>
>> One can note that ct_nmi_enter() can only ever be entered with the CT st=
ate
>> as either CT_STATE_KERNEL or CT_STATE_IDLE, as an IRQ/NMI happenning in =
the
>> CT_STATE_USER or CT_STATE_GUEST states will be routed down to ct_user_ex=
it().
>
> Are you sure? An NMI can fire between guest_state_enter_irqoff() and
> __svm_vcpu_run().

Urgh, you're quite right.

> And NMIs interrupting userspace don't call
> enter_from_user_mode(). In fact they don't call irqentry_enter_from_user_=
mode()
> like regular IRQs but irqentry_nmi_enter() instead. Well that's for archs
> implementing common entry code, I can't speak for the others.
>

That I didn't realize, so thank you for pointing it out. Having another
look now, I mistook DEFINE_IDTENTRY_RAW(exc_int3) for the general case
when it really isn't :(

> Unifying the behaviour between user and idle such that the IRQs/NMIs exit=
 the
> CT_STATE can be interesting but I fear this may not come for free. You wo=
uld
> need to save the old state on IRQ/NMI entry and restore it on exit.
>

That's what I tried to avoid, but it sounds like there's no nice way around=
 it.

> Do we really need it?
>

Well, my problem with not doing IDLE->KERNEL transitions on IRQ/NMI is that
this leads the IPI deferral logic to observe a technically-out-of-sync sate
for remote CPUs. Consider:

  CPUx            CPUy
                    state :=3D CT_STATE_IDLE
                    ...
                    ~>IRQ
                    ...
                    ct_nmi_enter()
                    [in the kernel proper by now]

  text_poke_bp_batch()
    ct_set_cpu_work(CPUy, CT_WORK_SYNC)
      READ CPUy ct->state
      `-> CT_IDLE_STATE
      `-> defer IPI


I thought this meant I would need to throw out the "defer IPIs if CPU is
idle" part, but AIUI this also affects CT_STATE_USER and CT_STATE_GUEST,
which is a bummer :(



From xen-devel-bounces@lists.xenproject.org Mon Jan 27 11:19:19 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 11:19:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877752.1287895 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcN92-0006uj-Td; Mon, 27 Jan 2025 11:19:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877752.1287895; Mon, 27 Jan 2025 11:19:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcN92-0006uc-Qd; Mon, 27 Jan 2025 11:19:08 +0000
Received: by outflank-mailman (input) for mailman id 877752;
 Mon, 27 Jan 2025 11:19: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 <SRS0=O4xJ=UT=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcN91-0006uU-Kj
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 11:19:07 +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 8576cd20-dca0-11ef-a0e6-8be0dac302b0;
 Mon, 27 Jan 2025 12:19:06 +0100 (CET)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-5d3bdccba49so7967723a12.1
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 03:19:06 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5dc186d8b37sm5235637a12.72.2025.01.27.03.19.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 03:19:05 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8576cd20-dca0-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737976746; x=1738581546; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=DpdqrWBdH+Ai5k3myB9oDK6+53dJhIzny954JTChJI4=;
        b=SEM0Xp+GbYNI+4HqofqhXBhoKZGbTQF0T2bSF/Im6imdrB50t3vzZoNvI68Efrfr3G
         cfJQMy7LgI30abBaNgoh0Xi3SWAZg5uz0XAtcmEythZaq1SK97unYMdCitTUj8sy8NJ+
         rNFsQb/D7wH96RkbW6ftFkKMvsbCUe6VVAis93YtQOIbb79wFEpRJkLcie4DvRuJGKVf
         hoV7dYHaqyNqvvqX7X9V8U/feV7O1WGGegSIkpfE00wBCw+DbN/eBehLNvM2U4PhEV/z
         KGyomoRq6SlUtOGaXV9KYef462I2vh/xRBXA0nkA2Vf5RirWKuI11qaWmXsNV0wl8kZr
         V7EQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737976746; x=1738581546;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=DpdqrWBdH+Ai5k3myB9oDK6+53dJhIzny954JTChJI4=;
        b=kIqE9o7Zluvajc8Pb9hq/YvxOKCrS4lRTWYJ3YOTOb7n3ZevmH+mzpv5L4bVH4WT1W
         q+egtSTv5z4wEei8ggVCbnMKraT2jXVxrx1jCx+3g7qnXGdac8A1BdISY7UOXl0AYF7v
         NFAD61JZ+fY/oUEHM8crW30ivQQIhdL48V5hz+hzxzJRmq/KYGzKoODRWMLKdIPzbqup
         k1huikmp8cG9CxpWvDZ8mkM5X11E8BeRBG1OtdkfILt5IRwlrasjpotieYJTW3BZDaOh
         SJkex20dEAyMTl3XIX9494MyKp7/40XcaeeVt7zI/R3YQmJcDGVwv4ti7fTVghidw3eN
         nEjQ==
X-Forwarded-Encrypted: i=1; AJvYcCWag/V8elqCNbaV2fshkw8zeUIE4yAbmHpbBl05GPywMkQFQKk+OkoAX3rigV1v/n+MHQhUHd5FR1M=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwFYuXx23l9EPV7C6Cl4+o2UJIx4Oy8OyYdLAgMWuX8eeUwv2+o
	DR6qEIb4K6cODyjoWRgF/lNPvXhT5rsCCTQxLFnXEjKFGdW1kDrzv2IbbjxCgg==
X-Gm-Gg: ASbGnctfroQutI/78HgxKlrb8kuiaB/gKrQR6fAZoQHr4l+Xyxc/pz3+vgv5oHWmNUm
	0tJujfCCBnxMZ4gJilS8wSwQcV/+kbIAJe7Qtt7M5gEL7OhS0psvoC9XICZ/v9A9XcZY0fCFniC
	sJGi36SvImHGmlc2BR8ELm84x6qPQAJGm6CGPMRkZW2XXbc2TElz1D5ngvvESt+tlAPIfz/6sz3
	RnLvunQ5x2QoKGAJ6klDB2L/KDF9viHXwQEJLTleLec6cW+ut9lpVB/cNKuAeae422qKubhnTwR
	uprZIJ85CTIWA21GrZ6s6TTqZJZGgxZ18v+5KmJw9s4Ft2dO/KtvB1QeB84AC8Ihww==
X-Google-Smtp-Source: AGHT+IGNdcqW+ubVpSsx+dFwwCfhleBuCZKbk9firtANmIUKOAxyvufJteopB/mSMSDNTEphxQrnOQ==
X-Received: by 2002:a05:6402:2346:b0:5dc:1fab:f63c with SMTP id 4fb4d7f45d1cf-5dc1fabfe0cmr10311190a12.9.1737976746115;
        Mon, 27 Jan 2025 03:19:06 -0800 (PST)
Message-ID: <58f861e2-866d-4c11-9bdb-b4b6c84825af@suse.com>
Date: Mon, 27 Jan 2025 12:19:08 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 4/9] asm-generic: move Arm's static-memory.h to
 asm-generic
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
 <julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <cover.1736334615.git.oleksii.kurochko@gmail.com>
 <3f1f3786ee48b01f1a5c7c7573456da72aa1e1d2.1736334615.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <3f1f3786ee48b01f1a5c7c7573456da72aa1e1d2.1736334615.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 08.01.2025 12:13, Oleksii Kurochko wrote:
> Except moving Arm's static-memory.h to asm-generic #ifdef header guard
> is updated: s/__ASM_STATIC_MEMORY_H_/__ASM_GENERIC_STATIC_MEMORY_H__.
> 
> Update arm/include/asm/Makefile to use asm-generic version of
> static-memory.h for Arm.
> 
> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

Here as well as in patch 5 the "why" is again missing. Moving is fine, as
long as it's clear that this will actually be used by another arch (e.g.
RISC-V). Whether you have such (immediate or at least near term) plans is
unclear though, as both features look like relatively advanced ones, and
hence more basic functionality may want to appear first in RISC-V.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 11:20:16 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 11:20:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877759.1287905 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcN9y-0008G5-6o; Mon, 27 Jan 2025 11:20:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877759.1287905; Mon, 27 Jan 2025 11:20:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcN9y-0008Fy-3O; Mon, 27 Jan 2025 11:20:06 +0000
Received: by outflank-mailman (input) for mailman id 877759;
 Mon, 27 Jan 2025 11:20:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=zo7v=UT=gmail.com=julien.grall.oss@srs-se1.protection.inumbo.net>)
 id 1tcN9w-00080G-SG
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 11:20:04 +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 a71ba185-dca0-11ef-99a4-01e77a169b0f;
 Mon, 27 Jan 2025 12:20:03 +0100 (CET)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-38637614567so2007700f8f.3
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 03:20:03 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a71ba185-dca0-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1737976802; x=1738581602; 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=mXfdOJ+RgG7pJjUQf0zW2Jw1uQOQIvQ/648lA6oQ02Q=;
        b=OsDSyHpl1TXee9HUbEoYgw40rkSCoJq69145oZ32i+YIrSa+8w0IJFPbaWoBV69ire
         0JUZGOsijToFgIyFn51fiYDrz3eAynK7cZle20r/ReJndSMN54CumSzKdBiV6VMkBoE4
         gSyjTRdZK9jX9Hw4l6wzM8OettdMF7pcUm0nLZpxnKJPY6Cf++PyznTXPSf4XEY2mbjT
         XQ24ZIYlLdFt7eEwIRfJ4D9GlJszt6ApEmBhCBSQk2MUmmQQ6oWwXPJ+lcktv5b3twLF
         8M+AV/INfRcv6dJLd9G4g9ag2HzacXA6PnGpp8UAvvdZ0gtOT44zCJN9kWE1h6hgcK65
         7juw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737976802; x=1738581602;
        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=mXfdOJ+RgG7pJjUQf0zW2Jw1uQOQIvQ/648lA6oQ02Q=;
        b=jnTMK1YchX+se5cknM10kgfWP/YwRSVIEGyBmuxtKtuoIBOrqVcWdWMIZF4iIl3UZt
         MVpjX5e/cIPaX6FztkasMSGvp7khox76IzJc6h0+euNp71kXkNQrn61THdya8HN4snm4
         h6NpGnjmICt9KDk5+ZU+QPGZq1c+34+LH7a5xywW/MFLqF2uwZXm867m3hdioGR35qpf
         LRFrMbcOyxdq6cuSDeKNc2WUtAIGUirryS/vrEi2c/RZWYTRFl/Aqgy/uZUZEuh0TRly
         DRCCgjNqJZ8iczZMjd4KdgEX0MpqflzHtY88VDaCJfVKh1PbVSSDy6i/QSc4nieAnTVh
         7Djg==
X-Gm-Message-State: AOJu0YwvViEOBE5jhRPKwp4NL6rL7/jteHw1CzX7Botjs87R61Mf7B+2
	iCQze/t6o8rN6APZ1+ln1ory8U6ZFoj9QLBxDvdOKRNWvJkthVDlif1mBX0uCLnbIyZ2ydU6u0R
	nL9etouw+ne7Oh9Gt9kBztp7DOh4=
X-Gm-Gg: ASbGncsH3YqqZ4dIdM4ZBgKG9aYqE9XSjZtMpbRiIHc7xHRVVBzXtV7Vt2HZJzX/UH+
	1kHMSiNGN8UnnIcN093QNxRCBeSx3BHpQPU1vb1rge9WNR6iTOzq5VtzEerCX
X-Google-Smtp-Source: AGHT+IELobLiQtzkh0ybrp8Oor3ODkT4/kGvZ0dqBC00TYbI3Wvqs+46iBcrT7txNyAc6F+qatiZhDS4sy61VwBSFrc=
X-Received: by 2002:a5d:668b:0:b0:385:ed16:c8b with SMTP id
 ffacd0b85a97d-38bf5674631mr31270954f8f.23.1737976800723; Mon, 27 Jan 2025
 03:20:00 -0800 (PST)
MIME-Version: 1.0
References: <20250127104556.175641-1-michal.orzel@amd.com> <20250127104556.175641-2-michal.orzel@amd.com>
In-Reply-To: <20250127104556.175641-2-michal.orzel@amd.com>
From: Julien Grall <julien.grall.oss@gmail.com>
Date: Mon, 27 Jan 2025 08:19:49 -0300
X-Gm-Features: AWEUYZnba3JVHcFI5c4SopWf8Xa-2oL-auOCpkzkutvXXRI9dDW3mqGn_nbgqPU
Message-ID: <CAJ=z9a24=PE-3bhmZvfTaTgpdCXp9iDTWfoH-9F9-_OdkEf4Tg@mail.gmail.com>
Subject: Re: [for-4.20][PATCH 1/2] device-tree: bootfdt: Fix build issue when CONFIG_PHYS_ADDR_T_32=y
To: Michal Orzel <michal.orzel@amd.com>
Cc: xen-devel@lists.xenproject.org, 
	Stefano Stabellini <sstabellini@kernel.org>, Bertrand Marquis <bertrand.marquis@arm.com>, 
	oleksii.kurochko@gmail.com
Content-Type: multipart/alternative; boundary="000000000000d5c959062cae41d1"

--000000000000d5c959062cae41d1
Content-Type: text/plain; charset="UTF-8"

On Mon, 27 Jan 2025 at 07:46, Michal Orzel <michal.orzel@amd.com> wrote:

> On Arm32, when CONFIG_PHYS_ADDR_T_32 is set, a build failure is observed:
> common/device-tree/bootfdt.c: In function 'build_assertions':
> ./include/xen/macros.h:47:31: error: static assertion failed:
> "!(alignof(struct membanks) != 8)"
>    47 | #define BUILD_BUG_ON(cond) ({ _Static_assert(!(cond), "!(" #cond
> ")"); })
>       |                               ^~~~~~~~~~~~~~
> common/device-tree/bootfdt.c:31:5: note: in expansion of macro
> 'BUILD_BUG_ON'
>    31 |     BUILD_BUG_ON(alignof(struct membanks) != 8);
>
> When CONFIG_PHYS_ADDR_T_32 is set, paddr_t is defined as unsigned long,
> therefore the struct membanks alignment is 4B. Fix it.


Usually, we add a BUILD_BUG_ON when other parts of the code rely on a
specific property (in this case alignment). Can you explain in the commit
message why the new check is still ok?

Cheers,



>
> Fixes: 2209c1e35b47 ("xen/arm: Introduce a generic way to access memory
> bank structures")
> Signed-off-by: Michal Orzel <michal.orzel@amd.com>
> ---
>  xen/common/device-tree/bootfdt.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/xen/common/device-tree/bootfdt.c
> b/xen/common/device-tree/bootfdt.c
> index 47386d4fffea..511700ccc2ba 100644
> --- a/xen/common/device-tree/bootfdt.c
> +++ b/xen/common/device-tree/bootfdt.c
> @@ -27,8 +27,8 @@ static void __init __maybe_unused build_assertions(void)
>       */
>      BUILD_BUG_ON((offsetof(struct membanks, bank) !=
>                   offsetof(struct meminfo, bank)));
> -    /* Ensure "struct membanks" is 8-byte aligned */
> -    BUILD_BUG_ON(alignof(struct membanks) != 8);
> +    /* Ensure "struct membanks" is paddr aligned */
> +    BUILD_BUG_ON(alignof(struct membanks) != sizeof(paddr_t));
>  }
>
>  static bool __init device_tree_node_is_available(const void *fdt, int
> node)
> --
> 2.25.1
>
>

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

<div dir=3D"auto"><br></div><div><br><div class=3D"gmail_quote gmail_quote_=
container"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, 27 Jan 2025 at 07:=
46, Michal Orzel &lt;<a href=3D"mailto:michal.orzel@amd.com">michal.orzel@a=
md.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Arm32, whe=
n CONFIG_PHYS_ADDR_T_32 is set, a build failure is observed:<br>
common/device-tree/bootfdt.c: In function &#39;build_assertions&#39;:<br>
./include/xen/macros.h:47:31: error: static assertion failed: &quot;!(align=
of(struct membanks) !=3D 8)&quot;<br>
=C2=A0 =C2=A047 | #define BUILD_BUG_ON(cond) ({ _Static_assert(!(cond), &qu=
ot;!(&quot; #cond &quot;)&quot;); })<br>
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^~~~~~~~~~~~~~<b=
r>
common/device-tree/bootfdt.c:31:5: note: in expansion of macro &#39;BUILD_B=
UG_ON&#39;<br>
=C2=A0 =C2=A031 |=C2=A0 =C2=A0 =C2=A0BUILD_BUG_ON(alignof(struct membanks) =
!=3D 8);<br>
<br>
When CONFIG_PHYS_ADDR_T_32 is set, paddr_t is defined as unsigned long,<br>
therefore the struct membanks alignment is 4B. Fix it.</blockquote><div dir=
=3D"auto"><br></div><div dir=3D"auto">Usually, we add a BUILD_BUG_ON when o=
ther parts of the code rely on a specific property (in this case alignment)=
. Can you explain in the commit message why the new check is still ok?</div=
><div dir=3D"auto"><br></div><div dir=3D"auto">Cheers,</div><div dir=3D"aut=
o"><br></div><div dir=3D"auto"><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex" dir=
=3D"auto"><br>
<br>
Fixes: 2209c1e35b47 (&quot;xen/arm: Introduce a generic way to access memor=
y bank structures&quot;)<br>
Signed-off-by: Michal Orzel &lt;<a href=3D"mailto:michal.orzel@amd.com" tar=
get=3D"_blank">michal.orzel@amd.com</a>&gt;<br>
---<br>
=C2=A0xen/common/device-tree/bootfdt.c | 4 ++--<br>
=C2=A01 file changed, 2 insertions(+), 2 deletions(-)<br>
<br>
diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/boot=
fdt.c<br>
index 47386d4fffea..511700ccc2ba 100644<br>
--- a/xen/common/device-tree/bootfdt.c<br>
+++ b/xen/common/device-tree/bootfdt.c<br>
@@ -27,8 +27,8 @@ static void __init __maybe_unused build_assertions(void)<=
br>
=C2=A0 =C2=A0 =C2=A0 */<br>
=C2=A0 =C2=A0 =C2=A0BUILD_BUG_ON((offsetof(struct membanks, bank) !=3D<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 offsetof(str=
uct meminfo, bank)));<br>
-=C2=A0 =C2=A0 /* Ensure &quot;struct membanks&quot; is 8-byte aligned */<b=
r>
-=C2=A0 =C2=A0 BUILD_BUG_ON(alignof(struct membanks) !=3D 8);<br>
+=C2=A0 =C2=A0 /* Ensure &quot;struct membanks&quot; is paddr aligned */<br=
>
+=C2=A0 =C2=A0 BUILD_BUG_ON(alignof(struct membanks) !=3D sizeof(paddr_t));=
<br>
=C2=A0}<br>
<br>
=C2=A0static bool __init device_tree_node_is_available(const void *fdt, int=
 node)<br>
-- <br>
2.25.1<br>
<br>
</blockquote></div></div>

--000000000000d5c959062cae41d1--


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 11:23:23 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 11:23:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877769.1287915 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcNCv-0001nW-Iw; Mon, 27 Jan 2025 11:23:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877769.1287915; Mon, 27 Jan 2025 11:23:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcNCv-0001nP-G8; Mon, 27 Jan 2025 11:23:09 +0000
Received: by outflank-mailman (input) for mailman id 877769;
 Mon, 27 Jan 2025 11:23:08 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=O4xJ=UT=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcNCu-0001nF-QT
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 11:23:08 +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 15312bac-dca1-11ef-a0e6-8be0dac302b0;
 Mon, 27 Jan 2025 12:23:07 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-aaf3c3c104fso156352366b.1
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 03:23:07 -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
 a640c23a62f3a-ab675e63177sm575186766b.58.2025.01.27.03.23.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 03:23:06 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 15312bac-dca1-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737976987; x=1738581787; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=lm0QtMrPvnrzQ9lpLNrwgXP6KR8PUuVz+jjFjySMBmg=;
        b=XKOLPfwRwZV0PXJTIYq4Z5eQvPDv9SLbi4JV6dppKoxD/vqoRhkQXrbO6NDmFU/r/v
         onOMpKJnY/CUK9hbQVwYJMiT4WsIJVO6zh/WURI5hJjnD2gwX4XlB8XqSTVreCJFFBly
         amNl9SF271tEK6/A8jWrn3G1ys2Oc4xlT+P5p0SkfgJn2T3CSYuM9ZvDrCjdC4dvBOgD
         nVfpvnwZWVws9bK3hJ4MN/NddIYFmq8WUyEIXr7gBtuFZuYFtHIe4qz1OgtO4YNHCNU8
         bBosCeY/4hWJw44DO119NK0LFEKcZvhzAmtVIeW+N3eqcSrsXjuS2IvwpCB6u1rBniOK
         yL0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737976987; x=1738581787;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=lm0QtMrPvnrzQ9lpLNrwgXP6KR8PUuVz+jjFjySMBmg=;
        b=UIZL2kWpu/Ue7LLdZuSS0GYonsrsJ8gqlC0qxFoCeWc3Hyx4W2VqbSAqZp/bjz+Ckn
         vWZaCmr0t6TJ9TjCCLUxyCZDLsnItU/SND3QdG6M7xZiGGh455JSeP8Hmw8LBg5xWAfZ
         v96r21B7FSmihcMmfzhmaa8mkLpj9RDwR4yJ8GD6YAgzWGK1IwqEiWEbwMsooUKCfX8c
         J8nRgO3eJjck5M1UOTg+/TUt20wTUkLsM9hur3nCK/vPUZNG45cDRLgsNbhXdoIPdI9c
         s6Ic7hnb7JcBlD/2bzbsdw5g6DwVcVy2WgxKXDfmeTg37BC06XtX8V1iZMW8yVjrXWUp
         H8dA==
X-Forwarded-Encrypted: i=1; AJvYcCXrwlu8FOzjf/oDfWsmUmvmgWKc5d7AeJJMhI4UnjoETVaknQYBlIG0XgagMRS2VwgeHZLNWao87tA=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy6JIBeK+9PZI6VyvQfv//wzGfSLL3XMj9MZOl8/yLL3j3Ugilp
	eM72EMJiVRhyIDnKI6Br+iLgmxza1Ig6O3dISGmyOWFH4ufEJKjlp5p0bFE4Ug==
X-Gm-Gg: ASbGncslrDjGcGPhGKSLIjboq6bMZ2kabm4ndd8erIa4gFo7OMnnV6F8ZRhKyAMeBg1
	HzltGPGghMbniiH1/6U9XGSjLoQurg59NVbPlRcgY++UGjeGe+3qBuNGz6MWmmx912dxRGzN1jg
	NyZe716vRG9JMl6ed9sc34/waITkEoDBV0kxFlzTvG55MAWMzq9jgQg9FrSd2IGyeA+In/ej7Hd
	JiFBv7HJNyLPMqgtmTcgl3RIpgWfe9nOammxUU31DTQTGvo6J3cMCp9gHDgQksBdF5ElY7/5xmr
	NaEtr+AYrC+S1FXvAB5ccZwQN2ur/Z33+p6zh+e8DrTGjy07gUWksZzBvUUKo46x3A==
X-Google-Smtp-Source: AGHT+IG78vQ2pIMfNxKeSKP2qAi5ur9DPCG6rSCwv4eYJ+U+0tnJjtFb79bw7udES64VUpdhNMX0Ig==
X-Received: by 2002:a17:907:1c11:b0:ab2:f74f:3f82 with SMTP id a640c23a62f3a-ab38b3da0cemr3587389866b.57.1737976987228;
        Mon, 27 Jan 2025 03:23:07 -0800 (PST)
Message-ID: <347b4bb0-5fd1-439f-9e3b-ef13ac89bbe9@suse.com>
Date: Mon, 27 Jan 2025 12:23:09 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 6/9] asm-generic: move some parts of Arm's
 domain_build.h to asm-generic header
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
 <julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <cover.1736334615.git.oleksii.kurochko@gmail.com>
 <ba3cde730ae072ba1088e396dd7d03482e4c4011.1736334615.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <ba3cde730ae072ba1088e396dd7d03482e4c4011.1736334615.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 08.01.2025 12:13, Oleksii Kurochko wrote:
> Nothing changed. Only some functions declaration are moved to asm-generic
> header as they are expected to be used by common code of domain builing or
> dom0less.
> 
> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> ---
>  xen/arch/arm/include/asm/domain_build.h | 19 ++----------
>  xen/include/asm-generic/domain-build.h  | 41 +++++++++++++++++++++++++
>  2 files changed, 43 insertions(+), 17 deletions(-)
>  create mode 100644 xen/include/asm-generic/domain-build.h

Again I question this movement under this name. "Domain building" is a pretty
generic thing, yes, but what you move would e.g. be entirely inapplicable on
x86 (as it is now). For example ...

> --- /dev/null
> +++ b/xen/include/asm-generic/domain-build.h
> @@ -0,0 +1,41 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef __ASM_GENERIC_DOMAIN_BUILD_H__
> +#define __ASM_GENERIC_DOMAIN_BUILD_H__
> +
> +#include <xen/types.h>
> +
> +struct domain;
> +struct page_info;
> +struct kernel_info;
> +struct membanks;
> +
> +typedef bool (*alloc_domheap_mem_cb)(struct domain *d, struct page_info *pg,
> +                                     unsigned int order, void *extra);
> +bool allocate_domheap_memory(struct domain *d, paddr_t tot_size,
> +                             alloc_domheap_mem_cb cb, void *extra);
> +
> +bool allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn,
> +                          paddr_t tot_size);

... the term "bank" seems pretty closely tied to DT. Other stuff ...

> +void allocate_memory(struct domain *d, struct kernel_info *kinfo);
> +int construct_domain(struct domain *d, struct kernel_info *kinfo);
> +int make_chosen_node(const struct kernel_info *kinfo);
> +int make_cpus_node(const struct domain *d, void *fdt);
> +int make_hypervisor_node(struct domain *d, const struct kernel_info *kinfo,
> +                         int addrcells, int sizecells);
> +int make_memory_node(const struct kernel_info *kinfo, int addrcells,
> +                     int sizecells, const struct membanks *mem);
> +int make_timer_node(const struct kernel_info *kinfo);

... here also falls in this category. Stuff like this may well live
under asm-generic/, but the file name chosen then needs to reflect
constraints.

> +unsigned int get_allocation_size(paddr_t size);
> +
> +

Nit: As before - no double blank lines please.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 11:32:11 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 11:32:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877778.1287925 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcNLT-0003pP-DN; Mon, 27 Jan 2025 11:31:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877778.1287925; Mon, 27 Jan 2025 11:31:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcNLT-0003pI-9N; Mon, 27 Jan 2025 11:31:59 +0000
Received: by outflank-mailman (input) for mailman id 877778;
 Mon, 27 Jan 2025 11:31:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=jIzP=UT=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tcNLR-0003mZ-Ni
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 11:31:57 +0000
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [2a00:1450:4864:20::534])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4ede5422-dca2-11ef-99a4-01e77a169b0f;
 Mon, 27 Jan 2025 12:31:53 +0100 (CET)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-5d3d0205bd5so6416122a12.3
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 03:31:53 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab6760ab0bcsm573733866b.95.2025.01.27.03.31.52
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 27 Jan 2025 03:31:52 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 4ede5422-dca2-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737977513; x=1738582313; 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=5M7Y9nG+rUesM7WKXClVC36ZcYHA9HSWMG/2zhVtSaU=;
        b=rS8pwcJ/l0nNaLn5Pfw1q0SI/BsQHYpi83pg/qbVb6rPCCqHjN82Q3SBTrjRDaJJuY
         hZss1O51B1RLGn8cBgtUdBwYhyZpPU1CBVLn6ISDjwUcNuldxXbZdcfxyEnJI0kYRT43
         wlePfTO5udXbf7DXU6EVY5LkdXNWmzLtVqwkk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737977513; x=1738582313;
        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=5M7Y9nG+rUesM7WKXClVC36ZcYHA9HSWMG/2zhVtSaU=;
        b=UvuLYalKXcYy6WMF76MmmdPYfWt8h2LwAs6h5ZF5TH0pcRouZBH+LhVweXpxnpPFqM
         uu+fqF7iotz9qVESN69BMZboB+D2n+FrgKEElvEDnxHPjUDo49qR3rdKqn6Ph+Nk4K19
         NO4PEIN6a5nKmbTHRehfmjTi+CEPQWL+Z9Rx+elaDBIZc1o9e0MHvbFN7YM6r31KUSFT
         btV2nTfUZOt5rH7YY+2SE6FQa5ToXXyhaRnP6gO/A8C5HhyWtEtbydU7RMRq0AnAnGwn
         d9zwH9BDQDbCdepUoQbqOn6I87SxghhuY63cIYtRMTmMJE38f3DHq3TUHkemKhUG2HX0
         1zeg==
X-Gm-Message-State: AOJu0YyENRiOXS2WKAFosPPSPWRraxcVSekp2ysDcPUddHRdQBuR86dQ
	GaLQEpzYQKVCvxyCDSS0VD35NK0oZRO+X/Zt8KeF8ACLMCtPeVWgrIuimN/RrZw=
X-Gm-Gg: ASbGnctfgt+sjqOJgBqaVICOiRN8ZgrET0bC8pmlEf+WWHLzk3Yhh7yU8ZJIbr4KgUW
	B7TGQMVjr724DSBzYiHxRNAaUxGIrxI+GDTmJYez8QjCw2uGJtPCoXqz18vVzkW/q2DQHcovsMw
	ibCUTrzeSOLqn2tu6HWjBk48pwxWaT/9F7yFhG11KWmyR62bWs96dYkzXENbzQNqKcjGENRdZsP
	9ai3+Hkffai9/jvVx25MFwOrnaPpyK1ZW5Sqv4Uq93GKKsKphH1w6xUQJHWLkZIbSPwfBPQlAOw
	ffZjcH33R2PWW0s=
X-Google-Smtp-Source: AGHT+IF9m5/hwKzsMyRXrvav+B/a1Aixrj5mydbV8I/2bNS6hZ5/5CIlhwjw6cl6RNiTeaaoTXilBg==
X-Received: by 2002:a17:907:6d1e:b0:ab6:6fc1:f602 with SMTP id a640c23a62f3a-ab66fc1f7a4mr1551395566b.15.1737977513190;
        Mon, 27 Jan 2025 03:31:53 -0800 (PST)
Date: Mon, 27 Jan 2025 12:31:51 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>
Subject: Re: [PATCH for-4.20] x86/PV: further harden guest memory accesses
 against speculative abuse
Message-ID: <Z5dupzj0JnC--YQ7@macbook.local>
References: <a615a96e-95d2-442f-b57d-0bb51142c977@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <a615a96e-95d2-442f-b57d-0bb51142c977@suse.com>

On Mon, Jan 27, 2025 at 11:15:22AM +0100, Jan Beulich wrote:
> The original implementation has two issues: For one it doesn't preserve
> non-canonical-ness of inputs in the range 0x8000000000000000 through
> 0x80007fffffffffff. Bogus guest pointers in that range would not cause a
> (#GP) fault upon access, when they should.
> 
> And then there is an AMD-specific aspect, where only the low 48 bits of
> an address are used for speculative execution; the architecturally
> mandated #GP for non-canonical addresses would be raised at a later
> execution stage. Therefore to prevent Xen controlled data to make it
> into any of the caches in a guest controllable manner, we need to
> additionally ensure that for non-canonical inputs bit 47 would be clear.
> 
> See the code comment for how addressing both is being achieved.
> 
> Fixes: 4dc181599142 ("x86/PV: harden guest memory accesses against speculative abuse")
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> RFC: When scratch2 isn't %r8...%r15, the MOV, CMOVNB, and XOR will have
>      unnecessary REX prefixes emitted, as users of the macro pass in 64-
>      bit registers. Similar to what was done to be able to use SETcc (in
>      the earlier alternative code sequence), we could derive %e.. from
>      %r.. to shrink code size some; there are a few dozen instances of
>      this code, after all. (An alternative, requiring to touch the use
>      sites, would be to constrain the scratch registers to rAX...rDI and
>      pass in only the last two characters of the names [e.g. "di", i.e.
>      also without the leading %]. That would make it straightforward to
>      use both %r.. and %e.. at the same time.)
> ---
> v2: Drop the non-RCR alternative.
> 
> --- a/xen/arch/x86/include/asm/asm-defns.h
> +++ b/xen/arch/x86/include/asm/asm-defns.h
> @@ -1,3 +1,5 @@
> +#include <asm/page-bits.h>
> +
>  #ifndef HAVE_AS_CLAC_STAC
>  .macro clac
>      .byte 0x0f, 0x01, 0xca
> @@ -65,17 +67,36 @@
>  .macro guest_access_mask_ptr ptr:req, scratch1:req, scratch2:req
>  #if defined(CONFIG_SPECULATIVE_HARDEN_GUEST_ACCESS)
>      /*
> -     * Here we want
> -     *
> -     * ptr &= ~0ull >> (ptr < HYPERVISOR_VIRT_END);
> -     *
> +     * Here we want to adjust \ptr such that
> +     * - if it's within Xen range, it becomes non-canonical,
> +     * - otherwise if it's (non-)canonical on input, it retains that property,
> +     * - if the result is non-canonical, bit 47 is clear (to avoid
> +     *   potentially populating the cache with Xen data),

It's my understanding from the commit message that this toggling of
bit 47 is only done due to AMD behavior, as speculative execution
there ignores any higher than 47, and hence non-canonical inputs are
no detected when speculatively executing?

It might be worth explicitly mentioning this in the comment.

>       * but guaranteed without any conditional branches (hence in assembly).
> +     *
> +     * To achieve this we determine which bit to forcibly clear: Either bit 47
> +     * (in case the address is below HYPERVISOR_VIRT_END) or bit 63.  Further
> +     * we determine whether for forcably set bit 63: In case we first cleared
> +     * it, we'll merely restore the original address.  In case we ended up
> +     * clearing bit 47 (i.e. the address was either non-canonical or within Xen
> +     * range), setting the bit will yield a guaranteed non-canonical address.
> +     * If we didn't clear a bit, we also won't set one: The address was in the
> +     * low half of address space in that case with bit 47 already clear.  The
> +     * address can thus be left unchanged, whether canonical or not.

Since for AMD we have to do the bit 47 clearing, won't it be enough to
do something like:

ptr &= (ptr < HYPERVISOR_VIRT_END) ? ~(1ULL <<  (VADDR_BITS - 1) : ~0ULL;

So only care to clear bit 47 when ptr is below HYPERVISOR_VIRT_END?
As that would already diverge accesses into the Xen address space
without having to toggle bit 63?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 11:51:35 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 11:51:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877790.1287934 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcNeM-0000Mx-0k; Mon, 27 Jan 2025 11:51:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877790.1287934; Mon, 27 Jan 2025 11:51:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcNeL-0000Mq-Tw; Mon, 27 Jan 2025 11:51:29 +0000
Received: by outflank-mailman (input) for mailman id 877790;
 Mon, 27 Jan 2025 11:51:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=O4xJ=UT=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcNeK-0000MU-5o
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 11:51:28 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0a094958-dca5-11ef-a0e6-8be0dac302b0;
 Mon, 27 Jan 2025 12:51:26 +0100 (CET)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-aaeec07b705so843343266b.2
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 03:51:26 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab676114a73sm565474366b.162.2025.01.27.03.51.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 03:51:26 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 0a094958-dca5-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737978686; x=1738583486; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=S9SfR02if+tlwa9xddtHusCS0O7ly8YKdWsp/8G8oHk=;
        b=Q/xOXGhDcXFC4GGH9OlHNcTh+4QlCxEb/Q2TIM3awD5Z2ZAHDw1InvBM6EWAArutH0
         ABxNyQ+CniNjoZcsHVWbOBoSvx52fEfvlNN4lnlmqwsn4Zvs8N5wkeXqxFP9gHMHuaN2
         PAgO42ynJzrERUZaO6KUEMYAJXmKjP+X0sJPhP290S4ZwJLd7ZNHbG1jmtBNcVkrG88a
         OqXXh9UmZdzA9TgphakJQ8qgvhwk/k7+/MBQbYqHYADWZAQn880myXgUzy6S/qs0SvyS
         41up5p9Zr2eYHjIUlZOotu+mhJQdtSkdxOdSKsIA3VXG2upY9qvAENRxq/8qLTWODBsZ
         +2eQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737978686; x=1738583486;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=S9SfR02if+tlwa9xddtHusCS0O7ly8YKdWsp/8G8oHk=;
        b=B5m8J2SMSmmDXfR7cfUKw4LCT+Eo4t4/XvVT2zqyuV0KV/3rVpUL5orzAP0xC1IpOe
         LZofi3UlOmyjaQA2n24He74j738FdpKsempWqq44xRwznbeMaB8du7uY9fZBbKzmefX3
         4s74vdXWzbY3g7keXCsXXYM6n7UzsND2KV6+9nH+PesULatebv9KsBapDko47A9tyGWY
         2W0HHPMrjS9FOLt/nQ4NCeXisdY76lFQfnZ3B7S+0GpAONKXxuj+/rsWRxCsa0a+QIs1
         8zNrZORgYOdAAwEpXTMGs1DCBmemPGz/FHSEkpH0G6X2zQ5DHP7m1nosTafRcX+uZFN9
         NUOA==
X-Forwarded-Encrypted: i=1; AJvYcCUVTSfh5EPRVfArVi6lhmwqppS78sxvxWXVIfZwp3YRTPEO1/z3hz+G1ytgyESKHtfBWBpylVj75+U=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyxuhCBZrDaIyM8V0cVfqJN+7c4db+3mWf4qLoWCb+2qc1JIdvk
	JKLEUn2CjY13/aH4otHs/IZVPmgfJVZCxs9ts4+9ipE6NLQdh1qENofKcOp1bQ==
X-Gm-Gg: ASbGncsKuIVgL6R3Zed3lOuvm1UfcgqemWftctoQqqtHFLxzJpKYDRN/i1nOpKVD1Ds
	6SBuQyATHUNwmVXT5Z8AQIBsLwsVWFg7uO+yZkpRSk1+jlIIvxdJiL8lRCmX+nKvPueCGqGKACE
	C1iq8nvCBGHNnVVpcAiJchTPfpr6Vza7GlMx4umH83OzddKlBxMNMQB2dFRhnQHBZOkLKWdih8V
	D0v7Bq3VvSyOWwa0FIy9sW73BzT+/f+cVmZHa0mxJghyyRxcaRXHntK/8DPwrxa+vx032/MdHod
	QPnYMInZ6W5ToFPJIPgIKlwdJs55Z4/+y3I7Uduh+/Pmd5dm1G6er14SpD9ML8OtqA==
X-Google-Smtp-Source: AGHT+IFl6VANnJi7IZLoLQLWCaClgPI59s/JxhskYEA+xPGyh13OXrE8twGLDffYBOz9fGJTZG42uQ==
X-Received: by 2002:a17:907:7eaa:b0:ab2:b5f1:567d with SMTP id a640c23a62f3a-ab38b1848ffmr3925918866b.32.1737978686311;
        Mon, 27 Jan 2025 03:51:26 -0800 (PST)
Message-ID: <dc9c0aa5-cb0e-4e3b-9e5d-0f84745ef396@suse.com>
Date: Mon, 27 Jan 2025 12:51:27 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] gnttab: introduce version agnostic macros
To: "Daniel P. Smith" <dpsmith@apertussolutions.com>,
 Christopher Clark <christopher.clark6@baesystems.com>
Cc: openxt@googlegroups.com, Christopher Clark
 <christopher.w.clark@gmail.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <20250110133711.3958202-1-dpsmith@apertussolutions.com>
 <20250110133711.3958202-2-dpsmith@apertussolutions.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250110133711.3958202-2-dpsmith@apertussolutions.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.01.2025 14:37, Daniel P. Smith wrote:
> @@ -310,16 +311,30 @@ nr_maptrack_frames(struct grant_table *t)
>  #define SHGNT_PER_PAGE_V1 (PAGE_SIZE / sizeof(grant_entry_v1_t))
>  #define shared_entry_v1(t, e) \
>      ((t)->shared_v1[(e)/SHGNT_PER_PAGE_V1][(e)%SHGNT_PER_PAGE_V1])
> +
> +/* Operations providing a single interface agnostic to grant table version */
>  #define SHGNT_PER_PAGE_V2 (PAGE_SIZE / sizeof(grant_entry_v2_t))
>  #define shared_entry_v2(t, e) \
>      ((t)->shared_v2[(e)/SHGNT_PER_PAGE_V2][(e)%SHGNT_PER_PAGE_V2])

The comment looks like it was misplaced, and rather wanted to go ahead of ...

> +
> +#define shared_entry_full_frame(gt, ref) \
> +    ( get_gt_version(gt) == 1 ? shared_entry_v1((gt), (ref)).frame : \
> +                                shared_entry_v2((gt), (ref)).full_page.frame )
> +#define set_shared_entry(gt, ref, val) \
> +    ( get_gt_version(gt) == 1 ? (shared_entry_v1((gt), (ref)).frame = (val)) : \
> +                                (shared_entry_v2((gt), (ref)).full_page.frame = (val)) )
> +#define status_addr(gt, ref, flags_addr) \
> +    ( evaluate_nospec(get_gt_version(gt) == 1) ? (flags_addr) : &status_entry((gt), (ref)) )

... this set of new #define-s?

Also a nit: There shouldn't be blanks immediately inside the opening parentheses
here. For readability you further want to omit parentheses around parameters
which are passed on unaltered (i.e. not becoming part of an expression). Plus
some of the lines are pretty obviously too long.

As to the single use of evaluate_nospec(): That looks odd here; on the surface
one would expect all three constructs to use it, or none of them. Deviations
from that likely require a comment, or at least some explanation in the
description.

> +
>  #define STGNT_PER_PAGE (PAGE_SIZE / sizeof(grant_status_t))
>  #define status_entry(t, e) \
>      ((t)->status[(e)/STGNT_PER_PAGE][(e)%STGNT_PER_PAGE])
> +
> +

No double blank lines please.

> @@ -1090,23 +1105,20 @@ map_grant_ref(
>      }
>  
>      /* Make sure we do not access memory speculatively */
> -    status = evaluate_nospec(rgt->gt_version == 1) ? &shah->flags
> -                                                   : &status_entry(rgt, ref);
> +    status = status_addr(rgt, ref, &shah->flags);

I was already wondering at the macro definition: How can it be that a
version-abstracting macro is passed something that's clearly version
1 only? That is, consider the opposite of the goal of this series,
someone wanting to allow building a gnttab-v2-only hypervisor. In that
case grant_entry_header_t would ideally not be defined at all (as a
struct; there may be a placeholder type). It would then be impossible
to de-reference the pointer. Hence I think that de-referencing ought to
live inside the macro.

> @@ -1930,7 +1938,7 @@ gnttab_grow_table(struct domain *d, unsigned int req_nr_frames)
>      }
>  
>      /* Status pages - version 2 */
> -    if ( evaluate_nospec(gt->gt_version > 1) )
> +    if ( evaluate_nospec(get_gt_version(gt) > 1) )

At this example: Assuming in the next patch get_gt_version() can end
up expanding to constant 1, the evaluate_nospec() would still be there,
for no good reason. I expect that wants further abstracting.

> @@ -2267,6 +2275,7 @@ gnttab_transfer(
>      mfn_t mfn;
>      unsigned int max_bitsize;
>      struct active_grant_entry *act;
> +    unsigned long frame;

Just going from indentation, ...

> @@ -2354,7 +2363,7 @@ gnttab_transfer(
>          }
>  
>          max_bitsize = domain_clamp_alloc_bitsize(
> -            e, e->grant_table->gt_version > 1 || paging_mode_translate(e)
> +            e, get_gt_version(e->grant_table) > 1 || paging_mode_translate(e)
>                 ? BITS_PER_LONG + PAGE_SHIFT : 32 + PAGE_SHIFT);
>          if ( max_bitsize < BITS_PER_LONG + PAGE_SHIFT &&
>               (mfn_x(mfn) >> (max_bitsize - PAGE_SHIFT)) )
> @@ -2452,22 +2461,12 @@ gnttab_transfer(
>          grant_read_lock(e->grant_table);
>          act = active_entry_acquire(e->grant_table, gop.ref);
>  
> -        if ( evaluate_nospec(e->grant_table->gt_version == 1) )
> -        {
> -            grant_entry_v1_t *sha = &shared_entry_v1(e->grant_table, gop.ref);
> +        frame = shared_entry_full_frame(e->grant_table, gop.ref);
> +        rc = guest_physmap_add_page(e, _gfn(frame), mfn, 0);
>  
> -            rc = guest_physmap_add_page(e, _gfn(sha->frame), mfn, 0);
> -            if ( !paging_mode_translate(e) )
> -                sha->frame = mfn_x(mfn);
> -        }
> -        else
> -        {
> -            grant_entry_v2_t *sha = &shared_entry_v2(e->grant_table, gop.ref);
> +        if ( !paging_mode_translate(e) )
> +            set_shared_entry(e->grant_table, gop.ref, mfn_x(mfn));
>  
> -            rc = guest_physmap_add_page(e, _gfn(sha->full_page.frame), mfn, 0);
> -            if ( !paging_mode_translate(e) )
> -                sha->full_page.frame = mfn_x(mfn);
> -        }
>          smp_wmb();
>          shared_entry_header(e->grant_table, gop.ref)->flags |=
>              GTF_transfer_completed;

... the variable looks to want declaring in a more narrow scope.

Also, related to an earlier comment: Where did the evaluate_nospec() go?

> @@ -2512,16 +2511,15 @@ release_grant_for_copy(
>      act = active_entry_acquire(rgt, gref);
>      sha = shared_entry_header(rgt, gref);
>      mfn = act->mfn;
> +    status = status_addr(rgt, gref, &sha->flags);
>  
> -    if ( evaluate_nospec(rgt->gt_version == 1) )
> +    if ( evaluate_nospec(get_gt_version(rgt) == 1) )
>      {
> -        status = &sha->flags;
>          td = rd;
>          trans_gref = gref;
>      }
>      else
>      {
> -        status = &status_entry(rgt, gref);
>          td = (act->src_domid == rd->domain_id)
>               ? rd : knownalive_domain_from_domid(act->src_domid);
>          trans_gref = act->trans_gref;

Same here - you're moving code across that speculation barrier.
Anything like this - assuming it is deliberate in the first place -
needs justifying.

> @@ -2573,7 +2571,6 @@ acquire_grant_for_copy(
>      struct active_grant_entry *act;
>      grant_status_t *status;
>      uint32_t old_pin;
> -    domid_t trans_domid;
>      grant_ref_t trans_gref;
>      struct domain *td;
>      mfn_t grant_mfn;

I fear I understand neither the movement of this variable, ...

> @@ -2597,6 +2594,7 @@ acquire_grant_for_copy(
>      /* This call also ensures the above check cannot be passed speculatively */
>      shah = shared_entry_header(rgt, gref);
>      act = active_entry_acquire(rgt, gref);
> +    old_pin = act->pin;

... nor that of this assignment ...

> @@ -2610,7 +2608,7 @@ acquire_grant_for_copy(
>          goto unlock_out;
>      }
>  
> -    if ( evaluate_nospec(rgt->gt_version == 1) )
> +    if ( evaluate_nospec(get_gt_version(rgt) == 1) )
>      {
>          sha2 = NULL;
>          status = &shah->flags;
> @@ -2621,9 +2619,10 @@ acquire_grant_for_copy(
>          status = &status_entry(rgt, gref);
>      }
>  
> -    old_pin = act->pin;

... (from here).

>      if ( sha2 && (shah->flags & GTF_type_mask) == GTF_transitive )
>      {
> +        domid_t trans_domid;

This makes me guess you want to narrow the scope of the variable, yet
then: How's that related to the subject of this patch?

> @@ -3878,10 +3877,7 @@ int gnttab_release_mappings(struct domain *d)
>  
>          act = active_entry_acquire(rgt, ref);
>          sha = shared_entry_header(rgt, ref);
> -        if ( rgt->gt_version == 1 )
> -            status = &sha->flags;
> -        else
> -            status = &status_entry(rgt, ref);
> +        status = status_addr(rgt, ref, &sha->flags);

Again relating to earlier comments, yet this time the other way around:
Suddenly we're gaining evaluate_nospec() here, for no apparent reason.

> @@ -4256,7 +4247,7 @@ int gnttab_map_frame(struct domain *d, unsigned long idx, gfn_t gfn, mfn_t *mfn)
>  
>      grant_write_lock(gt);
>  
> -    if ( evaluate_nospec(gt->gt_version == 2) && (idx & XENMAPIDX_grant_table_status) )
> +    if ( evaluate_nospec(get_gt_version(gt) == 2) && (idx & XENMAPIDX_grant_table_status) )

I realize the line was already too long, but since you touch it you also
want to wrap it.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 12:06:57 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 12:06:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877806.1287945 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcNtF-0003S0-BF; Mon, 27 Jan 2025 12:06:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877806.1287945; Mon, 27 Jan 2025 12:06:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcNtF-0003Rt-8a; Mon, 27 Jan 2025 12:06:53 +0000
Received: by outflank-mailman (input) for mailman id 877806;
 Mon, 27 Jan 2025 12:06:52 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=O4xJ=UT=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcNtE-0003Rl-0J
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 12:06:52 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 300264e4-dca7-11ef-99a4-01e77a169b0f;
 Mon, 27 Jan 2025 13:06:49 +0100 (CET)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-aaee0b309adso601498866b.3
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 04:06:49 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab675e13694sm568130566b.24.2025.01.27.04.06.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 04:06:48 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 300264e4-dca7-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737979609; x=1738584409; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ewLyMHBj2GQTajUyZhFuGS6aq8l0EoSKeIwuuGMQwqM=;
        b=a+QF5J6TiRo/52oLASVyTgCEaiVDk+/wgjkjFbbbbYoEKc1VMD/eeCGnluj2Y0iCMg
         GlH0JUpZ6PGUtQToftZc4gOZfFJVv1IKEkvLL2uov5n5kplaZRZjuHm+BCMgJVFQw2C5
         tzhMiGQwxio6zp/Nkot6hnssgDTVhiLNILU0HpKuv6O3FgDsbEZD1+kXBoxpJg8cZh4c
         lOS1QVvqVC3dxG9hiTEDub4EuQtR1iThf9xLxT97jj8jQDUksesa8TNeeQqZ5R+FHn4z
         /7FXX10YbtcZ8HzST2n34rGMl71CgpcooFcWFERk/X8DbAGuk8WhX7No2g+v4cfCfg9v
         KdxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737979609; x=1738584409;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ewLyMHBj2GQTajUyZhFuGS6aq8l0EoSKeIwuuGMQwqM=;
        b=dgh2pkYgGcOp2MhjXdhVSUyWIArQ1pH9ZzKfFnql/KkzpWrrqkCLf95b1qthsHs6AI
         f6juAmvNsNvmrat0wmWRam1ki8Xr47ffqH4ylOTIfCH/hiAwwXcl6fkaHmAdeB08NdH7
         jkN2Vxk1RtYbSDC/QVOQppNGZEmVAYdbCwJ9r+rt6jo60vrS62ZK/8kNsJVBVpcLkKLc
         OLLHOk0T51QExSWqQayeaLqIqXcGZDBKg26xQsrj9uecFf0zr6DpxBuqnA8XWj3ht8m7
         ok/OwWYT3wXitEKROJHseiJOGz8nkvCTLCUMtmld0Kn6YCy3+ZGQOV5XwpGOIa/7PO5D
         qTsQ==
X-Gm-Message-State: AOJu0YwErFwIySmjz62n8R1DNu9BhW/WbL+xs6DXOgsXx5/AsT5+qPJo
	lIqhulKe0WzBpILf1dxcUvArLts2Zb+6QS1LdfZteGol72JYTWVid0fR8TDcp06mGb1eJhWYzoU
	=
X-Gm-Gg: ASbGncut0BcumVTNKGs+8yHMA4u/jj21VKJBDetiHBLSZ3XLMB7MQ8F0wjbARunl7pl
	WSvLPxJdQJfEFAp13vcLmZle7DMgruhE/7T+htaIEqvNcDiia5/VYbu5e+KgKitWWHsnkQpggqG
	PwvxXi7g91ghSS469Fn7wj7rMaot3hlIGOJ3VpVHAI7hAdmyJCaGarEJaXkgAaqB0MA5GHbzWSZ
	LwqpLUlssiDtldHHG+NXctCJpiwQaKFN5Br+NX1WkyF8X5iTVV2ArF6aO9vMlPdNeaY/c7hNpYE
	dUsqKb4rguanM4Q+xPf333UlllOxxhWLiMx2DJpWNSMNsyqPvJ/iibcxOD7XNFNrDA==
X-Google-Smtp-Source: AGHT+IFiWoj5IBVRs7fRvTxR/LR90rWWJ4gCrsmQdt0m9/z68enbRYqT61MCj+aAeIOpSjNs2dIuXw==
X-Received: by 2002:a17:906:6a20:b0:aac:23f4:f971 with SMTP id a640c23a62f3a-ab38b1b45e1mr3466907366b.33.1737979608971;
        Mon, 27 Jan 2025 04:06:48 -0800 (PST)
Message-ID: <39a582e7-272e-478f-8613-166e51f90f72@suse.com>
Date: Mon, 27 Jan 2025 13:06:51 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20] x86/PV: further harden guest memory accesses
 against speculative abuse
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>
References: <a615a96e-95d2-442f-b57d-0bb51142c977@suse.com>
 <Z5dupzj0JnC--YQ7@macbook.local>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <Z5dupzj0JnC--YQ7@macbook.local>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 27.01.2025 12:31, Roger Pau Monné wrote:
> On Mon, Jan 27, 2025 at 11:15:22AM +0100, Jan Beulich wrote:
>> --- a/xen/arch/x86/include/asm/asm-defns.h
>> +++ b/xen/arch/x86/include/asm/asm-defns.h
>> @@ -1,3 +1,5 @@
>> +#include <asm/page-bits.h>
>> +
>>  #ifndef HAVE_AS_CLAC_STAC
>>  .macro clac
>>      .byte 0x0f, 0x01, 0xca
>> @@ -65,17 +67,36 @@
>>  .macro guest_access_mask_ptr ptr:req, scratch1:req, scratch2:req
>>  #if defined(CONFIG_SPECULATIVE_HARDEN_GUEST_ACCESS)
>>      /*
>> -     * Here we want
>> -     *
>> -     * ptr &= ~0ull >> (ptr < HYPERVISOR_VIRT_END);
>> -     *
>> +     * Here we want to adjust \ptr such that
>> +     * - if it's within Xen range, it becomes non-canonical,
>> +     * - otherwise if it's (non-)canonical on input, it retains that property,
>> +     * - if the result is non-canonical, bit 47 is clear (to avoid
>> +     *   potentially populating the cache with Xen data),
> 
> It's my understanding from the commit message that this toggling of
> bit 47 is only done due to AMD behavior, as speculative execution
> there ignores any higher than 47, and hence non-canonical inputs are
> no detected when speculatively executing?
> 
> It might be worth explicitly mentioning this in the comment.

Hmm, to be honest I'd rather not (and keep mentioning AMD to the
description). First and foremost because if I mention it here, I
strictly also ought to mention Hygon, I think. In the description I
feel a little easier about not specifically saying so. (But yes, if
you strongly think I should mention vendors here, I'd be okay-ish to
add "on AMD-like hardware" before the closing paren on the 2nd
bullet point.)

Further, with such a consideration, would we perhaps also want to
consider simplifying the transformation when AMD=n in .config? (I
could see us doing so, but not as late in a release cycle as we're
now at. Plus I say so without having thought about whether a
simplification is actually possible.)

>>       * but guaranteed without any conditional branches (hence in assembly).
>> +     *
>> +     * To achieve this we determine which bit to forcibly clear: Either bit 47
>> +     * (in case the address is below HYPERVISOR_VIRT_END) or bit 63.  Further
>> +     * we determine whether for forcably set bit 63: In case we first cleared
>> +     * it, we'll merely restore the original address.  In case we ended up
>> +     * clearing bit 47 (i.e. the address was either non-canonical or within Xen
>> +     * range), setting the bit will yield a guaranteed non-canonical address.
>> +     * If we didn't clear a bit, we also won't set one: The address was in the
>> +     * low half of address space in that case with bit 47 already clear.  The
>> +     * address can thus be left unchanged, whether canonical or not.
> 
> Since for AMD we have to do the bit 47 clearing, won't it be enough to
> do something like:
> 
> ptr &= (ptr < HYPERVISOR_VIRT_END) ? ~(1ULL <<  (VADDR_BITS - 1) : ~0ULL;
> 
> So only care to clear bit 47 when ptr is below HYPERVISOR_VIRT_END?
> As that would already diverge accesses into the Xen address space
> without having to toggle bit 63?

No, this may transform a non-canonical input into a canonical address
(accesses through which then won't #GP as expected), just for a different
address range than where we had the same mistake before.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 12:29:49 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 12:29:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877814.1287955 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcOFL-0007PT-1e; Mon, 27 Jan 2025 12:29:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877814.1287955; Mon, 27 Jan 2025 12:29:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcOFK-0007PM-V2; Mon, 27 Jan 2025 12:29:42 +0000
Received: by outflank-mailman (input) for mailman id 877814;
 Mon, 27 Jan 2025 12:29:41 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=qVGR=UT=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tcOFJ-0007PE-L8
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 12:29:41 +0000
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com
 [2a00:1450:4864:20::22c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 60827661-dcaa-11ef-99a4-01e77a169b0f;
 Mon, 27 Jan 2025 13:29:39 +0100 (CET)
Received: by mail-lj1-x22c.google.com with SMTP id
 38308e7fff4ca-30219437e63so55762111fa.1
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 04:29:39 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-3076bc198b7sm14391191fa.81.2025.01.27.04.29.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 04:29:38 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 60827661-dcaa-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1737980979; x=1738585779; darn=lists.xenproject.org;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=PVHbBRjYFnq5W32t9KKnPipbCZD3giM7Ir5EHURE8Bo=;
        b=NXxlrMONvzkZttk/ykrMrrqDK2Hg6JxmafaOHBYLqjhiuGED+PsgSqj8eQp/+xFnWx
         mguxAh7rLiN8idLBj5ExQrxjivKBOxp5lsIyQhod4Vn3z9Hy6zi6ycZpm55DM31vCilq
         VRHpU9W6LV1Sfp4lj7eGSbXh1gpvUxsxGr7EiSSsLaLQG8I4M/V1pWlMPwpclMpexyEI
         964c0mT15I2Oy1XcI+5HTDoi5mC/YsRTJ0BLIXe8nKoiYvrjuqBE/j5qWpeYY0usifue
         CS+E3gyENIXWOLS4kIGYSP9OTB9jtYHFnL6aP7mPE5OSQ6xXfYkqnko0PLjGvblnjH7R
         x+ew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737980979; x=1738585779;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=PVHbBRjYFnq5W32t9KKnPipbCZD3giM7Ir5EHURE8Bo=;
        b=MSLsWgBJXJwn30zCnm8IY22OQGo2vkk4vKhffnFYsArFPnYB5dQ7+nzjyksfUw8q0i
         5BS8T8qe6hDbnE7CY0Z3xeahKAClSCq8X38rh+LuznJyefq9Z5J6Dl6kAv+wyhrT1NfM
         KlHd+AmtKStZnymnHjMRzST2/Gk0wa3wkQTRNSDibGNo0JuO8OYg0deEduqvD2YzRBQ+
         K3/lug+AlOBe0YUsygi/dhECWABgOXvEiMppB/6MqyUaKHn1SOe8D8CTJS5ZMw8Y14NG
         q9RUiebnERvHt5A7UmCAUEmV/ZwEL9rAjvy2xHquOCIox9PLhmVl5sFOLJqq1bYBRTxx
         dw7A==
X-Forwarded-Encrypted: i=1; AJvYcCVaXMUCVYBhVbJce14BIiHPYZctIQVvZXaI5bWzOmOhr0mmxryuEB5md7lzALFtAH6HTXsL9+5q6+0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyVG59dwZQgYS8bUBjhkb60rgyvvEv4e8Q3oIlcr/mMbX6ZHrDA
	7S96q2ec2HJqsO51fZqFzViavUG31a5N15qBhJsM7RKugUy/epG/
X-Gm-Gg: ASbGncudwtsYA1o7ivIC68p09UuKD34KJafyX+sRSqhNyyyUGG6QBA0WOw6OpjxJCJF
	khszuUSXTTn3hQBf6rGnIN+V0jsPFCqQXhM1wTO0JUGTYfGBlzWFv/Htf1SOaK1j+kE5pHT3SrG
	TSdv2FivbGGi6M9iT+992dpgttz1BkJh366XvBGuRUX77PY6QJhqy+ZAtRfLOQ7y4ZEH0ECAy2h
	tbmnJyEeZK2JZzKtiJ1Uvbq9nAutMncgNNsS2fso6K8gwOooMhQ9dRkcbsjBKJQ/f0DtK/KiPzl
	uVIOII5ieswDCOBpug==
X-Google-Smtp-Source: AGHT+IHLixGdbFeOaNLwLmyrWTuYSTo4l1wcFugTYmodY0UhB1ZoBiWvE0oC3Hz2aXrAl7PSjJYv6g==
X-Received: by 2002:a05:651c:b07:b0:2ff:e219:c6d with SMTP id 38308e7fff4ca-30761bd49d0mr57688641fa.10.1737980978351;
        Mon, 27 Jan 2025 04:29:38 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------ssff8jsbxYqFlRtkuDjhwSor"
Message-ID: <e2290a2a-a3c0-4cfe-b9e9-8cfec0b194a8@gmail.com>
Date: Mon, 27 Jan 2025 13:29:37 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 1/3] xen/riscv: implement software page table walking
To: Jan Beulich <jbeulich@suse.com>
Cc: Alistair Francis <alistair.francis@wdc.com>,
 Bob Eshleman <bobbyeshleman@gmail.com>, Connor Davis
 <connojdavis@gmail.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1737391102.git.oleksii.kurochko@gmail.com>
 <00dfc71569bc9971b53e29b36a80e9e020ac61ac.1737391102.git.oleksii.kurochko@gmail.com>
 <21bfd2f5-74b8-409e-956c-dd736a3c0be2@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <21bfd2f5-74b8-409e-956c-dd736a3c0be2@suse.com>

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


On 1/27/25 11:06 AM, Jan Beulich wrote:
> On 20.01.2025 17:54, Oleksii Kurochko wrote:
>> RISC-V doesn't have hardware feature to ask MMU to translate
>> virtual address to physical address ( like Arm has, for example ),
>> so software page table walking in implemented.
>>
>> Signed-off-by: Oleksii Kurochko<oleksii.kurochko@gmail.com>
>> ---
>>   xen/arch/riscv/include/asm/mm.h |  2 ++
>>   xen/arch/riscv/pt.c             | 56 +++++++++++++++++++++++++++++++++
>>   2 files changed, 58 insertions(+)
>>
>> diff --git a/xen/arch/riscv/include/asm/mm.h b/xen/arch/riscv/include/asm/mm.h
>> index 292aa48fc1..d46018c132 100644
>> --- a/xen/arch/riscv/include/asm/mm.h
>> +++ b/xen/arch/riscv/include/asm/mm.h
>> @@ -15,6 +15,8 @@
>>   
>>   extern vaddr_t directmap_virt_start;
>>   
>> +paddr_t pt_walk(vaddr_t va);
> In the longer run, is returning just the PA really going to be sufficient?
> If not, perhaps say a word on the limitation in the description.

In the long run, this function's prototype looks like|paddr_t pt_walk(vaddr_t root, vaddr_t va, bool is_xen)| [1]. However, I'm not sure if it will stay that way,
as I think|is_xen| could be skipped, since using|map_table()| should be sufficient (as it now considers|system_state|) and I'm not really sure if I need root argument
as initial goal was to use this function for debug only purposes and I've never used it for guest page table (stage-1) walking.
Anyway, yes, it is still returning a physical address, and that seems enough to me.

Could you share your thoughts on what I should take into account for returning value, probably, I am missing something really useful?

|[1] 
https://gitlab.com/xen-project/people/olkur/xen/-/blob/latest/xen/arch/riscv/mm.c#L820|

>> +     * initialize `ret` with "impossible" XEN_TABLE_MAP_NOMEM.
>> +    */
>> +    int ret = XEN_TABLE_MAP_NOMEM;
>> +    unsigned int level = HYP_PT_ROOT_LEVEL;
>> +    paddr_t pa = 0;
> Seeing 0 as initializer here, just to double check: You do prevent MFN 0
> to be handed to the page allocator, and you also don't use it "manually"
> anywhere?

MFN 0 could be used when removing the page:https://gitlab.com/xen-project/xen/-/blob/staging/xen/arch/riscv/pt.c?ref_type=heads#L251 <https://gitlab.com/xen-project/xen/-/blob/staging/xen/arch/riscv/pt.c?ref_type=heads#L251>.

In that case, it would be better to initialize|pa| with|(paddr_t)(-1)|, as this value couldn't be mapped and is safe to use as an invalid value.

>
>> +    pte_t *table;
>> +
>> +    DECLARE_OFFSETS(offsets, va);
>> +
>> +    table = map_table(root);
>> +
>> +    /*
>> +     * Find `pa` of an entry which corresponds to `va` by iterating for each
>> +     * page level and checking if the entry points to a next page table or
>> +     * to a page.
>> +     *
>> +     * Two cases are possible:
>> +     * - ret == XEN_TABLE_SUPER_PAGE means that the entry was find;
>> +     *   (Despite of the name) XEN_TABLE_SUPER_PAGE covers 4k mapping too.
>> +     * - ret == XEN_TABLE_MAP_NONE means that requested `va` wasn't actually
>> +     *   mapped.
>> +     */
>> +    while ( (ret != XEN_TABLE_MAP_NONE) && (ret != XEN_TABLE_SUPER_PAGE) )
>> +    {
>> +        /*
>> +         * This case shouldn't really occur as it will mean that for table
>> +         * level 0 a pointer to next page table has been written, but at
>> +         * level 0 it could be only a pointer to 4k page.
>> +         */
>> +        ASSERT(level <= HYP_PT_ROOT_LEVEL);
>> +
>> +        ret = pt_next_level(false, &table, offsets[level]);
>> +        level--;
>> +    }
>> +
>> +    if ( ret == XEN_TABLE_MAP_NONE )
>> +        dprintk(XENLOG_WARNING, "Is va(%#lx) really mapped?\n", va);
> Even if it's a dprintk(), I'd recommend against adding such.
>
>> +    else if ( ret == XEN_TABLE_SUPER_PAGE )
>> +        pa = pte_to_paddr(*(table + offsets[level + 1]));
> Missing "else if ( ret == XEN_TABLE_NORMAL )" (or maybe simply "else")?

If I am not missing something, we can't be here with ret == XEN_TABLE_NORMAL because we iterating
in the while loop above until we don't find a leaf or until reach level = 0. If we find a leaf then
XEN_TABLE_SUPER_PAGE is returned; otherwise sooner or later we should face a case when next table
(in case when `level`=0 and someone put at this level a pointer to next level, what is a bug) should
be allocated in pt_next_level(), but it will fail because `alloc_tbl`=false is passed to pt_next_level()
and thereby ret=XEN_TABLE_MAP_NONE() will be returned.

Based on your previous comment about dprintk this could could be re-written in the following way:
-    if ( ret == XEN_TABLE_MAP_NONE )
-        dprintk(XENLOG_WARNING, "Is va(%#lx) really mapped?\n", va);
-    else if ( ret == XEN_TABLE_SUPER_PAGE )
+    if ( ret != XEN_TABLE_MAP_NONE )
          pa = pte_to_paddr(*(table + offsets[level + 1]));

>> +    return pa;
> Don't you want to OR in the low 12 bits of VA here (unless "pa" is still 0)?

It is a bug, and IIUC if `pa` isn't 0 it is still need to add the low bits of VA to `pa`:
     return pa | (va & ((1 << PAGE_SHIFT) - 1));
(I think that I saw somewhere a macros to generate masks but can't find where)

Thanks.

~ Oleksii

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

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 1/27/25 11:06 AM, Jan Beulich wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:21bfd2f5-74b8-409e-956c-dd736a3c0be2@suse.com">
      <pre wrap="" class="moz-quote-pre">On 20.01.2025 17:54, Oleksii Kurochko wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">RISC-V doesn't have hardware feature to ask MMU to translate
virtual address to physical address ( like Arm has, for example ),
so software page table walking in implemented.

Signed-off-by: Oleksii Kurochko <a class="moz-txt-link-rfc2396E" href="mailto:oleksii.kurochko@gmail.com">&lt;oleksii.kurochko@gmail.com&gt;</a>
---
 xen/arch/riscv/include/asm/mm.h |  2 ++
 xen/arch/riscv/pt.c             | 56 +++++++++++++++++++++++++++++++++
 2 files changed, 58 insertions(+)

diff --git a/xen/arch/riscv/include/asm/mm.h b/xen/arch/riscv/include/asm/mm.h
index 292aa48fc1..d46018c132 100644
--- a/xen/arch/riscv/include/asm/mm.h
+++ b/xen/arch/riscv/include/asm/mm.h
@@ -15,6 +15,8 @@
 
 extern vaddr_t directmap_virt_start;
 
+paddr_t pt_walk(vaddr_t va);
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
In the longer run, is returning just the PA really going to be sufficient?
If not, perhaps say a word on the limitation in the description.</pre>
    </blockquote>
    <pre>In the long run, this function's prototype looks like <code>paddr_t pt_walk(vaddr_t root, vaddr_t va, bool is_xen)</code> [1]. However, I'm not sure if it will stay that way,
as I think <code>is_xen</code> could be skipped, since using <code>map_table()</code> should be sufficient (as it now considers <code>system_state</code>) and I'm not really sure if I need root argument
as initial goal was to use this function for debug only purposes and I've never used it for guest page table (stage-1) walking.
Anyway, yes, it is still returning a physical address, and that seems enough to me.</pre>
    <pre>Could you share your thoughts on what I should take into account for returning value, probably, I am missing something really useful?</pre>
    <pre><code><span class="hljs-params"><span class="hljs-params">[1] <a class="moz-txt-link-freetext" href="https://gitlab.com/xen-project/people/olkur/xen/-/blob/latest/xen/arch/riscv/mm.c#L820">https://gitlab.com/xen-project/people/olkur/xen/-/blob/latest/xen/arch/riscv/mm.c#L820</a></span></span></code></pre>
    <blockquote type="cite"
      cite="mid:21bfd2f5-74b8-409e-956c-dd736a3c0be2@suse.com">
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">+     * initialize `ret` with "impossible" XEN_TABLE_MAP_NOMEM.
+    */
+    int ret = XEN_TABLE_MAP_NOMEM;
+    unsigned int level = HYP_PT_ROOT_LEVEL;
+    paddr_t pa = 0;
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
Seeing 0 as initializer here, just to double check: You do prevent MFN 0
to be handed to the page allocator, and you also don't use it "manually"
anywhere?</pre>
    </blockquote>
    <pre>MFN 0 could be used when removing the page: <a rel="noopener"
    target="_new"
href="https://gitlab.com/xen-project/xen/-/blob/staging/xen/arch/riscv/pt.c?ref_type=heads#L251"><span>https</span><span>://gitlab</span><span>.com</span><span>/xen</span><span>-project</span><span>/xen</span><span>/-/blob</span><span>/staging</span><span>/xen</span><span>/arch</span><span>/riscv</span><span>/pt</span><span>.c</span><span>?ref_type</span><span>=heads</span><span>#L251</span></a>.</pre>
    <pre>In that case, it would be better to initialize <code>pa</code> with <code>(paddr_t)(-1)</code>, as this value couldn't be mapped and is safe to use as an invalid value.</pre>
    <blockquote type="cite"
      cite="mid:21bfd2f5-74b8-409e-956c-dd736a3c0be2@suse.com">
      <pre wrap="" class="moz-quote-pre">

</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">+    pte_t *table;
+
+    DECLARE_OFFSETS(offsets, va);
+
+    table = map_table(root);
+
+    /*
+     * Find `pa` of an entry which corresponds to `va` by iterating for each
+     * page level and checking if the entry points to a next page table or
+     * to a page.
+     *
+     * Two cases are possible:
+     * - ret == XEN_TABLE_SUPER_PAGE means that the entry was find;
+     *   (Despite of the name) XEN_TABLE_SUPER_PAGE covers 4k mapping too.
+     * - ret == XEN_TABLE_MAP_NONE means that requested `va` wasn't actually
+     *   mapped.
+     */
+    while ( (ret != XEN_TABLE_MAP_NONE) &amp;&amp; (ret != XEN_TABLE_SUPER_PAGE) )
+    {
+        /*
+         * This case shouldn't really occur as it will mean that for table
+         * level 0 a pointer to next page table has been written, but at
+         * level 0 it could be only a pointer to 4k page.
+         */
+        ASSERT(level &lt;= HYP_PT_ROOT_LEVEL);
+
+        ret = pt_next_level(false, &amp;table, offsets[level]);
+        level--;
+    }
+
+    if ( ret == XEN_TABLE_MAP_NONE )
+        dprintk(XENLOG_WARNING, "Is va(%#lx) really mapped?\n", va);
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
Even if it's a dprintk(), I'd recommend against adding such.

</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">+    else if ( ret == XEN_TABLE_SUPER_PAGE )
+        pa = pte_to_paddr(*(table + offsets[level + 1]));
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
Missing "else if ( ret == XEN_TABLE_NORMAL )" (or maybe simply "else")?</pre>
    </blockquote>
    <pre>If I am not missing something, we can't be here with ret == XEN_TABLE_NORMAL because we iterating
in the while loop above until we don't find a leaf or until reach level = 0. If we find a leaf then
XEN_TABLE_SUPER_PAGE is returned; otherwise sooner or later we should face a case when next table
(in case when `level`=0 and someone put at this level a pointer to next level, what is a bug) should
be allocated in pt_next_level(), but it will fail because `alloc_tbl`=false is passed to pt_next_level()
and thereby ret=XEN_TABLE_MAP_NONE() will be returned.

Based on your previous comment about dprintk this could could be re-written in the following way:
-    if ( ret == XEN_TABLE_MAP_NONE )
-        dprintk(XENLOG_WARNING, "Is va(%#lx) really mapped?\n", va);
-    else if ( ret == XEN_TABLE_SUPER_PAGE )
+    if ( ret != XEN_TABLE_MAP_NONE )
         pa = pte_to_paddr(*(table + offsets[level + 1]));

</pre>
    <blockquote type="cite"
      cite="mid:21bfd2f5-74b8-409e-956c-dd736a3c0be2@suse.com">
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">+    return pa;
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
Don't you want to OR in the low 12 bits of VA here (unless "pa" is still 0)?</pre>
    </blockquote>
    <pre>It is a bug, and IIUC if `pa` isn't 0 it is still need to add the low bits of VA to `pa`:
    return pa | (va &amp; ((1 &lt;&lt; PAGE_SHIFT) - 1));
(I think that I saw somewhere a macros to generate masks but can't find where)

Thanks.

~ Oleksii
</pre>
  </body>
</html>

--------------ssff8jsbxYqFlRtkuDjhwSor--


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 12:32:57 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 12:32:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877823.1287964 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcOIL-0000wu-Dj; Mon, 27 Jan 2025 12:32:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877823.1287964; Mon, 27 Jan 2025 12: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 <xen-devel-bounces@lists.xenproject.org>)
	id 1tcOIL-0000wn-B7; Mon, 27 Jan 2025 12:32:49 +0000
Received: by outflank-mailman (input) for mailman id 877823;
 Mon, 27 Jan 2025 12:32: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
 <SRS0=qVGR=UT=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tcOIK-0000wb-0i
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 12:32:48 +0000
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com
 [2a00:1450:4864:20::22c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id cf0b9803-dcaa-11ef-99a4-01e77a169b0f;
 Mon, 27 Jan 2025 13:32:44 +0100 (CET)
Received: by mail-lj1-x22c.google.com with SMTP id
 38308e7fff4ca-30616d71bb0so44938811fa.3
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 04:32:44 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-3076bc1959bsm14225921fa.65.2025.01.27.04.32.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 04:32:43 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: cf0b9803-dcaa-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1737981164; x=1738585964; darn=lists.xenproject.org;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=pYsOKgKs6QIh/MzVkzOvySFSRtn/Gg7Yh4FgdM6G/bo=;
        b=SBfXKtH/EdtL7Ij0ehuIt385nkaNlwNv6FsAhceCUmRhE8/hViQT3bHXG7Bb4L8BWw
         7V712LWVpxmSTZuQZhzuxXOcHTNHD55n5TENxJE2LsmPCypc0Wn5jnUetDpeBkXXQ/gr
         f7+Cb4PQ9oS2coQb4yCWwZU0F9+0TFZHWEkQ3ylZOiki2HGZe2cHUvf60lbseNOElcd4
         xMJpxcrpxSeyGe3YjQK50+yZMWIUddqNnfxZfqWJhgVqU1uTZ2TYkvoy9djAKGBSVF1y
         U8xHcPCG4e6KekbGM2tsaO8TKp2mhUR7h772rTyEoMqHo/nrf5BwsqrNfxprJcshq6Pt
         ZUsg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737981164; x=1738585964;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=pYsOKgKs6QIh/MzVkzOvySFSRtn/Gg7Yh4FgdM6G/bo=;
        b=CiJZkkyiy91Z5OOj5qlSN2cxrqW48TMTL7bc5c87wbOnQL5+a0nvkZ4wDPci8fnXnC
         oJXiLCNXk/QMcNxfbRGihhm/y7bETcLoHQgA8WIsKFLMjlt5ws++YuC+qTvt6sgVlUmb
         Thq4AqtwgZWxjLw14bVfVW9280KfIh7g6eQ/0KLU4uSZYsJ4Ea9+yUe8/k9uNeOHT+D5
         +Q8PPuz0K14VOyv3Ick3GGF0O9vlH8AZbbGZyM6hPSfqk127JXAgAizGcRbK/G3Od720
         oAy07JTx7SUt451yvz0xCtled0K8rnWdtKnlPdmrtARusR5YU3rcdZ2+9WLICLdHYMdJ
         /sig==
X-Forwarded-Encrypted: i=1; AJvYcCU5TOwftV75Wr7A0UwU0FXhBWsuFt1UfRCxkfwik+NtdymGgIwRCevm0DlEB+BNUxVndfay7jsiGYs=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw6wVMrSC5ZKwqeEJsBHB+XsY2GRApI6AmUsRJqLbFM/7uIbL0/
	//MGUrn6S2VCZUtk0Y5VG/atkq+oYfo2vxOfNstkut+nBSN/0dAL
X-Gm-Gg: ASbGncuvaTIbai5eLlnoQdtr4b0tNnpNoNcr92dRjnVk1n4tRrbRf5UGOlzet8SHnjc
	WDzunTuQRgPP09SD98HrBqiKlKymV6k5qpumtYXZ3q1jpDRwn75RPZLtBPZduxfXGtAjvpMZwfd
	UjAfiQVcYspDkak+140tUm5OGesOsVGn3h56a6NkmqR/C77/t/EKK6sIJ+NTFUY3GS5q+tAaivi
	LphXKGzHfZXqvllO2jMVTVTP9lUqH7yCntmwmfG9s8O2HlbwhtIJ+3AefmzIwcH2a6tUidVQVI2
	sm28pTDy7hyfERpApA==
X-Google-Smtp-Source: AGHT+IHuVGo9tdCcuqIxSVuClEs7Qk6HrCNSrwiEoacIrgSRFOSX1fptOiSK9hA8caFllnHd4saw8g==
X-Received: by 2002:a2e:b4a9:0:b0:302:1b18:2bfa with SMTP id 38308e7fff4ca-3072cb138a4mr126038691fa.23.1737981163998;
        Mon, 27 Jan 2025 04:32:43 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------8OGWoqas89DZyY0eDNG0dih0"
Message-ID: <b97527b4-b68a-4206-bfb9-27dee3ef8e31@gmail.com>
Date: Mon, 27 Jan 2025 13:32:43 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 2/3] xen/riscv: update defintion of vmap_to_mfn()
To: Jan Beulich <jbeulich@suse.com>
Cc: Alistair Francis <alistair.francis@wdc.com>,
 Bob Eshleman <bobbyeshleman@gmail.com>, Connor Davis
 <connojdavis@gmail.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1737391102.git.oleksii.kurochko@gmail.com>
 <bf85f6987c2a2f3374ad47fc0bf1513d69372b1f.1737391102.git.oleksii.kurochko@gmail.com>
 <2bf6ef11-fb4e-40ef-b258-dd9314cba791@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <2bf6ef11-fb4e-40ef-b258-dd9314cba791@suse.com>

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


On 1/27/25 11:09 AM, Jan Beulich wrote:
> On 20.01.2025 17:54, Oleksii Kurochko wrote:
>> vmap_to_mfn() uses virt_to_maddr(), which is designed to work with VA from
>> either the direct map region or Xen's linkage region (XEN_VIRT_START).
>> An assertion will occur if it is used with other regions, in particular for
>> the VMAP region.
>>
>> Since RISC-V lacks a hardware feature to request the MMU to translate a VA to
>> a PA (as Arm does, for example), software page table walking (pt_walk()) is
>> used for the VMAP region to obtain the PA.
>>
>> Fixes: 7db8d2bd9b ("xen/riscv: add minimal stuff to mm.h to build full Xen")
>> Signed-off-by: Oleksii Kurochko<oleksii.kurochko@gmail.com>
> Reviewed-by: Jan Beulich<jbeulich@suse.com>
>
>> --- a/xen/arch/riscv/include/asm/mm.h
>> +++ b/xen/arch/riscv/include/asm/mm.h
>> @@ -25,7 +25,7 @@ paddr_t pt_walk(vaddr_t va);
>>   #define gaddr_to_gfn(ga)    _gfn(paddr_to_pfn(ga))
>>   #define mfn_to_maddr(mfn)   pfn_to_paddr(mfn_x(mfn))
>>   #define maddr_to_mfn(ma)    _mfn(paddr_to_pfn(ma))
>> -#define vmap_to_mfn(va)     maddr_to_mfn(virt_to_maddr((vaddr_t)(va)))
>> +#define vmap_to_mfn(va)     maddr_to_mfn(pt_walk((vaddr_t)(va)))
> With this being the first use of pt_walk(), I wonder whether the function might
> better return mfn_t (and simply ignore the low 12 bits of Vthe incoming VA; see
> my respective comment on the earlier patch). After all it is quite natural for
> a page table walk to return a page frame number, not a physical address.

I think it would be really better to return mfn_t (now I understand your comment on the earlier
patch better,if only I had read this comment first...)

Thanks.

~ Oleksii

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

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 1/27/25 11:09 AM, Jan Beulich wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:2bf6ef11-fb4e-40ef-b258-dd9314cba791@suse.com">
      <pre wrap="" class="moz-quote-pre">On 20.01.2025 17:54, Oleksii Kurochko wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">vmap_to_mfn() uses virt_to_maddr(), which is designed to work with VA from
either the direct map region or Xen's linkage region (XEN_VIRT_START).
An assertion will occur if it is used with other regions, in particular for
the VMAP region.

Since RISC-V lacks a hardware feature to request the MMU to translate a VA to
a PA (as Arm does, for example), software page table walking (pt_walk()) is
used for the VMAP region to obtain the PA.

Fixes: 7db8d2bd9b ("xen/riscv: add minimal stuff to mm.h to build full Xen")
Signed-off-by: Oleksii Kurochko <a class="moz-txt-link-rfc2396E" href="mailto:oleksii.kurochko@gmail.com">&lt;oleksii.kurochko@gmail.com&gt;</a>
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
Reviewed-by: Jan Beulich <a class="moz-txt-link-rfc2396E" href="mailto:jbeulich@suse.com">&lt;jbeulich@suse.com&gt;</a>

</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">--- a/xen/arch/riscv/include/asm/mm.h
+++ b/xen/arch/riscv/include/asm/mm.h
@@ -25,7 +25,7 @@ paddr_t pt_walk(vaddr_t va);
 #define gaddr_to_gfn(ga)    _gfn(paddr_to_pfn(ga))
 #define mfn_to_maddr(mfn)   pfn_to_paddr(mfn_x(mfn))
 #define maddr_to_mfn(ma)    _mfn(paddr_to_pfn(ma))
-#define vmap_to_mfn(va)     maddr_to_mfn(virt_to_maddr((vaddr_t)(va)))
+#define vmap_to_mfn(va)     maddr_to_mfn(pt_walk((vaddr_t)(va)))
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
With this being the first use of pt_walk(), I wonder whether the function might
better return mfn_t (and simply ignore the low 12 bits of Vthe incoming VA; see
my respective comment on the earlier patch). After all it is quite natural for
a page table walk to return a page frame number, not a physical address.</pre>
    </blockquote>
    <pre>I think it would be really better to return mfn_t (now I understand your comment on the earlier
patch better, <span class="Y2IQFc" lang="en">if only I had read this comment first</span>...)

Thanks.

~ Oleksii
</pre>
  </body>
</html>

--------------8OGWoqas89DZyY0eDNG0dih0--


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 12:42:40 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 12:42:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877842.1287995 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcORm-0003KY-MO; Mon, 27 Jan 2025 12:42:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877842.1287995; Mon, 27 Jan 2025 12:42:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcORm-0003KR-Iy; Mon, 27 Jan 2025 12:42:34 +0000
Received: by outflank-mailman (input) for mailman id 877842;
 Mon, 27 Jan 2025 12:42:33 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=fNoC=UT=cloud.com=andrew.cooper@srs-se1.protection.inumbo.net>)
 id 1tcORl-0003KJ-0P
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 12:42:33 +0000
Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com
 [2a00:1450:4864:20::342])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2c355694-dcac-11ef-99a4-01e77a169b0f;
 Mon, 27 Jan 2025 13:42:30 +0100 (CET)
Received: by mail-wm1-x342.google.com with SMTP id
 5b1f17b1804b1-4361e89b6daso28226015e9.3
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 04:42:30 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438bd507e0csm128614795e9.20.2025.01.27.04.42.29
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 04:42:29 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2c355694-dcac-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737981750; x=1738586550; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=/pxKZ77JVbfvYleZXLL7a6pgQT043Onqu2f8cRAL40g=;
        b=qlUYM0YqFhs7sEO7nWSvhYp+cNbRmtZhesVDmlgSHyjhHrGUqOy5hIExnRKsaC2l8k
         8KjVadg4en1CGBOTnm7OfFrSH37PlnGeGxLfxfLEuAcgwXWj8SgIkJD/8S1ibntC7Kuc
         KIbs/2YOxJYAdfdAiWsgsGovKA82KehNj8EQY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737981750; x=1738586550;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=/pxKZ77JVbfvYleZXLL7a6pgQT043Onqu2f8cRAL40g=;
        b=j6KikINpNcSBm9IemRcmx0Gj8AUm4/KknTBuW+ACz7CqvXHro7J4PSZjJazu/U5gx+
         1IvF0i9epGcn/9AFpXWgk9i3BneSfanACyz6Gd5g55QaFWTvh3Jlg0BlQm7zXxX9XzMN
         fj0bK7rTVVEDIALJ97Dn0YWjT/7gNJGyXXCCxlWLFpjPbL1GdvRRxHpkzNY2HE3QhTlY
         kALoeZQFu3oKsKOFYiSjD3I0tESaU/ECB7ztkRh4Z2nyUaQQ8jfmueFFtDV+LChruqZo
         n9IMiygfhOPSslJaWeZ0JwJVOtvtEaAnXUDBEgYfTXKa6Wm7gsZ7o5ZKGvZG/kbAiz65
         wjeQ==
X-Forwarded-Encrypted: i=1; AJvYcCXxlHr3wrdgmqq+f/Mu8JMAtl1UAAsI7WbI4PTB2+Ud5RLk/TSlBaEQZYw6MIiUHcWmfXsmkyEmSMY=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzci3AvEWs5OkHYSGReCLVRDPUBNKtdzWd30Yod6xPA4bH7rcGw
	YD3+noes4Low42Y6EFZXBcjhTG6g7NpvYGwkzQrNOEIpPI7M4U8Hymer5C9Vbvo=
X-Gm-Gg: ASbGncvIGrqdoqNogIh35U2gTWRVa8T550+PgBv7CYNcuPZTVMW3UMkgNV+up1qFLVd
	QUHJ3ISKec4pOxvc9rDBqwrKzMatUfp0+6geUavrvWABJBdD1Q+Kv7PVktPdzSWssqhfUptLo8a
	7VLVNbZf2pRptJqqW236hoHgPX+3OW6x04lf4oIeODQfZyC5XgAX++ry5b+7nci7nj4jC12uTk3
	L68H1dS5b6/NRMswq5cEu0Xt/xBJZboC0BGm7FO3HKDEPGxI9OhkRKb4KvjlPelRvKUf1iGQ0Ey
	rHKimjmNH5+Ikny7htAwJ3Z5wSZZYUp/CkicLWSTLh7P
X-Google-Smtp-Source: AGHT+IEeRiMpR8xAELPWDu2ekDTtJ4g+uI4WWq4X2t2vJTZ6t2//tcx6nbHMXsArUcan+oD+lsFs/Q==
X-Received: by 2002:a05:600c:4e08:b0:434:a4a6:51f8 with SMTP id 5b1f17b1804b1-438912d4a3bmr400733945e9.0.1737981750167;
        Mon, 27 Jan 2025 04:42:30 -0800 (PST)
Message-ID: <76b3b208-a576-48f2-820b-e213722fe229@citrix.com>
Date: Mon, 27 Jan 2025 12:42:29 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20] x86/intel: Fix PERF_GLOBAL fixup when
 virtualised
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
Cc: Jonathan Katz <jonathan.katz@aptar.com>, Jan Beulich <JBeulich@suse.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
References: <20250121142510.358996-1-andrew.cooper3@citrix.com>
 <eb58ed74-1156-4de5-8392-a546d9afddc3@gmail.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <eb58ed74-1156-4de5-8392-a546d9afddc3@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 21/01/2025 4:57 pm, Oleksii Kurochko wrote:
>
> On 1/21/25 3:25 PM, Andrew Cooper wrote:
>> Logic using performance counters needs to look at
>> MSR_MISC_ENABLE.PERF_AVAILABLE before touching any other resources.
>>
>> When virtualised under ESX, Xen dies with a #GP fault trying to read
>> MSR_CORE_PERF_GLOBAL_CTRL.
>>
>> Factor this logic out into a separate function (it's already too
>> squashed to
>> the RHS), and insert a check of MSR_MISC_ENABLE.PERF_AVAILABLE.
>>
>> This also limits setting X86_FEATURE_ARCH_PERFMON, although oprofile
>> (the only
>> consumer of this flag) cross-checks too.
>>
>> Reported-by: Jonathan Katz <jonathan.katz@aptar.com>
>> Link: https://xcp-ng.org/forum/topic/10286/nesting-xcp-ng-on-esx-8
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> ---
>> CC: Jan Beulich <JBeulich@suse.com>
>> CC: Roger Pau Monné <roger.pau@citrix.com>
>> CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
>>
>> Untested, but this is the same pattern used by oprofile and watchdog
>> setup.
>
> Probably it will make sense to wait for a response on the forum (you
> mentioned in the Link:) that the current one patch works?

It's been a week.  At this point it needs to go in for the release.  As
I said, this is exactly the same pattern as used elsewhere in Xen, so
I'm confident it's a good fix, and Roger agrees too.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 12:51:13 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 12:51:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877851.1288006 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcOa4-000535-Gu; Mon, 27 Jan 2025 12:51:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877851.1288006; Mon, 27 Jan 2025 12:51:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcOa4-00052y-CN; Mon, 27 Jan 2025 12:51:08 +0000
Received: by outflank-mailman (input) for mailman id 877851;
 Mon, 27 Jan 2025 12:51:07 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=qVGR=UT=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tcOa3-00052s-GO
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 12:51:07 +0000
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com
 [2a00:1450:4864:20::136])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5f273fee-dcad-11ef-99a4-01e77a169b0f;
 Mon, 27 Jan 2025 13:51:05 +0100 (CET)
Received: by mail-lf1-x136.google.com with SMTP id
 2adb3069b0e04-53df80eeeedso4875215e87.2
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 04:51:05 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-543c8368537sm1279197e87.108.2025.01.27.04.51.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 04:51:04 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5f273fee-dcad-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1737982265; x=1738587065; darn=lists.xenproject.org;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=nKiWRlgC9unDB3h1nsQGLnmjm3RUS9cr34MuKcNsCBM=;
        b=NaRsG6uKNgbDJoHiJwVxcMqfZbbaKUxuMK+CQhgvyPYlNO4WXfg+Hh4Fg9LxfBRIxQ
         n98Qqwhhkj/wgoq3AC70ytFa67k+ZH6q49BZC/6/VpYNrHQJyWVt+Fye+qY8805hUCgH
         s0O90rwZAQysJDPNH+ekEtKMDjsQEhpbZvdlKIjdcEWJgIHRdC8gorpnL/pg43IhbYFg
         317jQfnt01aJeV80ZBFl8FqVHQtprUSa+sTP/A7OD3s5VhUkenIUNhNAhT3PRxOuqop5
         q1fhzAiN74Uo9+zOBhoTeQpdlYSBlIjbXAv7SSeNPHmaIasZQgt8fhNa11L5+lk5JXj0
         r35w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737982265; x=1738587065;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=nKiWRlgC9unDB3h1nsQGLnmjm3RUS9cr34MuKcNsCBM=;
        b=Joz2eegaCyAFLeU9xv8cP5L57tCfPQMwxeC5mQgEFkw8XZzwrsUX74uW7MJ5MOIsDp
         iTx0p80lfn3p7zs7KeteXCdOxdHKUdTzPJvXr4gTdjEjWK+ZJ4DrrdXbAvSGM3EqN1NT
         vZVFIGIjBwhn5DYiIxGuG6aAbK4FVC8+X1o/p4nUFwAvN0nW4a9tpFqXR22jRC2sZTuf
         EedWv9V+m9o7Byp/B0sGmBgPAWXgEPylICypRUCaxj85/eVfRgZFdMSCvApm5Lj4cNyC
         F7NruuPE2u+OxnQA8+YL37dT1M6xVi95INfm9/dCsqbWMuxVqGCt8/X5/WRVE31HwnPa
         lVJQ==
X-Forwarded-Encrypted: i=1; AJvYcCXZ9nCXYEQhTrSvd8dosF7W5Js4Ej+Xsw/5UOY8mEytVDqFP++i/VX92gE9eRHJWCp49GpMtDyqLPw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YytxAlc373kays9rFpvhugHJ4klRgAXgtN6ccWc58B1B0urTFIq
	6oT2igFA5+wKxU+FB+2YaJ1tSGpp4aUcYaJ1+4OvJW9HLjPd4WJX
X-Gm-Gg: ASbGnctSCgHGzlKcH9d+6GoXXaWoItHVPvWTV4gTnXJv6xMtsMHYEs54x0g0EW/9TfG
	KbSB8432aK6ZLtEppBK6PmhqCd7FoonmBZgNuRljToUkFFiDp7aWLYMS5uFMKlpHARt4GqWHGpH
	aLU718szM7ixK1J9hf1pOBqXK1KhGuDb99g+Gj8oo+815sgALFUdbQUuln6bd/1AYyJ3JJpEZyV
	VCnSRO0CtPBl5sqQOtmRRUJJuGrQv1JXb4le597f3EqMqJHYEutoAj46Z430uRbmLg4DdLw2+Od
	4kKCLF0zgMGQVad+4g==
X-Google-Smtp-Source: AGHT+IGFR6hcTxr6SA1eBVTklRaJznZyQlE2IbX5CpAZphva/b9cshwMG/FycajoeeoKjLCNCQ+qCg==
X-Received: by 2002:ac2:4543:0:b0:542:29e5:731c with SMTP id 2adb3069b0e04-5439c21f202mr12480473e87.11.1737982264826;
        Mon, 27 Jan 2025 04:51:04 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------6jrSlmCvCdxuWNEstkOWV6Gu"
Message-ID: <f3184cac-fbe3-463b-8354-136ff899b6d8@gmail.com>
Date: Mon, 27 Jan 2025 13:51:03 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 3/3] xen/riscv: update mfn calculation in
 pt_mapping_level()
To: Jan Beulich <jbeulich@suse.com>
Cc: Alistair Francis <alistair.francis@wdc.com>,
 Bob Eshleman <bobbyeshleman@gmail.com>, Connor Davis
 <connojdavis@gmail.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1737391102.git.oleksii.kurochko@gmail.com>
 <a4a970490471035bf49a97257b400da23091fb9a.1737391102.git.oleksii.kurochko@gmail.com>
 <f244ed32-cf27-452f-8c92-206f892f809c@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <f244ed32-cf27-452f-8c92-206f892f809c@suse.com>

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


On 1/27/25 11:24 AM, Jan Beulich wrote:
> On 20.01.2025 17:54, Oleksii Kurochko wrote:
>> --- a/xen/arch/riscv/pt.c
>> +++ b/xen/arch/riscv/pt.c
>> @@ -346,9 +346,33 @@ static int pt_mapping_level(unsigned long vfn, mfn_t mfn, unsigned long nr,
>>           return level;
>>   
>>       /*
>> -     * Don't take into account the MFN when removing mapping (i.e
>> -     * MFN_INVALID) to calculate the correct target order.
>> +     * `mfn` should be set properly in cases when modifying/destroying a
>> +     * mapping to ensure the correct page table `level` is received. In the
>> +     * case of `mfn` == INVALID_MFN, the `mask` will take into account only
>> +     * `vfn` and could accidentally return an incorrect level. For example,
>> +     * if `vfn` is page table level 1 aligned, but it was mapped as page table
>> +     * level 0, then without the check below it will return `level` = 1
>> +     * because only `vfn`, which is page table level 1 aligned, is taken into
>> +     * account when `mfn` == INVALID_MFN.
>>        *
>> +     * POPULATE shouldn't be considered as `va` hasn't been mapped yet.
>> +     */
>> +    if ( mfn_eq(mfn, INVALID_MFN) && !(flags & PTE_POPULATE) )
>> +    {
>> +        vaddr_t va = vfn << PAGE_SHIFT;
>> +        paddr_t pa;
>> +        unsigned long xen_virt_end = (XEN_VIRT_START + XEN_VIRT_SIZE - 1);
>> +
>> +        if ( ((va >= DIRECTMAP_VIRT_START) && (va <= DIRECTMAP_VIRT_END)) ||
>> +             ((va >= XEN_VIRT_START) && (va <= xen_virt_end)) )
>> +            pa = virt_to_maddr(va);
>> +        else
>> +            pa = pt_walk(va);
>> +
>> +        mfn = _mfn(paddr_to_pfn(pa));
>> +    }
> Doing a walk here and then another in pt_update() feels wasteful.

I agree that it is wasteful but, at that moment, it seemed to me the faster way to resolve that.

>   I
> wonder whether the overall approach to page table updating doesn't want
> changing. It ought to be possible to tell an "update" operation to walk
> down to wherever the leaf entry is, and update there.

I think I got your idea. I will try to implement that.

Thanks!

~ Oleksii



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

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 1/27/25 11:24 AM, Jan Beulich wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:f244ed32-cf27-452f-8c92-206f892f809c@suse.com">
      <pre wrap="" class="moz-quote-pre">On 20.01.2025 17:54, Oleksii Kurochko wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">--- a/xen/arch/riscv/pt.c
+++ b/xen/arch/riscv/pt.c
@@ -346,9 +346,33 @@ static int pt_mapping_level(unsigned long vfn, mfn_t mfn, unsigned long nr,
         return level;
 
     /*
-     * Don't take into account the MFN when removing mapping (i.e
-     * MFN_INVALID) to calculate the correct target order.
+     * `mfn` should be set properly in cases when modifying/destroying a
+     * mapping to ensure the correct page table `level` is received. In the
+     * case of `mfn` == INVALID_MFN, the `mask` will take into account only
+     * `vfn` and could accidentally return an incorrect level. For example,
+     * if `vfn` is page table level 1 aligned, but it was mapped as page table
+     * level 0, then without the check below it will return `level` = 1
+     * because only `vfn`, which is page table level 1 aligned, is taken into
+     * account when `mfn` == INVALID_MFN.
      *
+     * POPULATE shouldn't be considered as `va` hasn't been mapped yet.
+     */
+    if ( mfn_eq(mfn, INVALID_MFN) &amp;&amp; !(flags &amp; PTE_POPULATE) )
+    {
+        vaddr_t va = vfn &lt;&lt; PAGE_SHIFT;
+        paddr_t pa;
+        unsigned long xen_virt_end = (XEN_VIRT_START + XEN_VIRT_SIZE - 1);
+
+        if ( ((va &gt;= DIRECTMAP_VIRT_START) &amp;&amp; (va &lt;= DIRECTMAP_VIRT_END)) ||
+             ((va &gt;= XEN_VIRT_START) &amp;&amp; (va &lt;= xen_virt_end)) )
+            pa = virt_to_maddr(va);
+        else
+            pa = pt_walk(va);
+
+        mfn = _mfn(paddr_to_pfn(pa));
+    }
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
Doing a walk here and then another in pt_update() feels wasteful.</pre>
    </blockquote>
    <pre>I agree that it is wasteful but, at that moment, it seemed to me the faster way to resolve that.

</pre>
    <blockquote type="cite"
      cite="mid:f244ed32-cf27-452f-8c92-206f892f809c@suse.com">
      <pre wrap="" class="moz-quote-pre"> I
wonder whether the overall approach to page table updating doesn't want
changing. It ought to be possible to tell an "update" operation to walk
down to wherever the leaf entry is, and update there.</pre>
    </blockquote>
    <pre>I think I got your idea. I will try to implement that.

Thanks!

~ Oleksii



</pre>
  </body>
</html>

--------------6jrSlmCvCdxuWNEstkOWV6Gu--


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 12:52:13 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 12:52:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877864.1288016 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcOb6-0005pE-QW; Mon, 27 Jan 2025 12:52:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877864.1288016; Mon, 27 Jan 2025 12:52:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcOb6-0005p7-L3; Mon, 27 Jan 2025 12:52:12 +0000
Received: by outflank-mailman (input) for mailman id 877864;
 Mon, 27 Jan 2025 12:52:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=O4xJ=UT=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcOb5-0005oj-5p
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 12:52:11 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 85574f1f-dcad-11ef-a0e6-8be0dac302b0;
 Mon, 27 Jan 2025 13:52:09 +0100 (CET)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-aa67ac42819so703869166b.0
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 04:52:09 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab6914e56a2sm353398366b.94.2025.01.27.04.52.08
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 04:52:08 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 85574f1f-dcad-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737982329; x=1738587129; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=XkCpdyV8NVkI5a1J2Q3wsVE9S43lR8cz8V/RXeohAQw=;
        b=KTZA2YqIKV+Tg5VwN61/+dR94CY3GVu732aeQADm16fk2MltKXhHy+fEWooGJfFjDY
         zbcoxzhuTBbvObhDqg2NxxSCAEY47L14uXyzDwJYoEIC+SalhwQY8EdQehYgHPnTvBbT
         2qw8qzurcOCP3YgXw5Lc4gbhej/H90+QEVtU7JvgDtRYgWMVXshUCEsZwC4rSYalqYuT
         A+3imbeCf+hFipZbHJBmI42XO2zMMc0cOQxBMn52v+yKEuZgYyhqGJVsZ6vCI3HbUyHR
         cNPkoYbQr7bvc+m4AVvMiVVXv8h9SGRrq+obwqfW2/2VFvONIbrNtnVmlJUUf72oDSyE
         qmVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737982329; x=1738587129;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=XkCpdyV8NVkI5a1J2Q3wsVE9S43lR8cz8V/RXeohAQw=;
        b=E+nnJuW2IO+r4ZC4kK9sBbmkqqzu+8/voMKfc9GtsrGmSwua44tOTugCx++EZ0yUnk
         mbsChdX1k+zb7g/SIkSRWYc6Sn4Whsx7OKVdrJa+ueQKbjSlWJ/EYOSL7Im9LAYwTqBA
         O+ICtQGdjksweXLm1jmsxpAQPjn5AG5pgBQ0Y/oT9xhCo68llDZx2boUchal5lKakpZX
         EnPyov1mKqesQ1ZI1WRLMLb9tUXzAl8yOd7xCmd4dpj87yqe+g+2z8vGhvFvRikkMlmt
         U6AYATs+gpKwbpuMMAUcpDufhXTlWPnkoIMxmtQ5ORrvnOpDivteV2uHzTPM4HF1zmEg
         JMeA==
X-Forwarded-Encrypted: i=1; AJvYcCUNH5z5TXYy5NB6u1Iae+MThLpodIBU88sfn0VZ59DyfXaqi5b/hozG4j2WgPW7XxynvF2nCKgJ5aM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxCXnXRWdb7pYEzJoia8FMkdqAUJN0cenHJXi1VT+4kCssBLwCN
	S8BaYOsPDUjSDFoI86AKh8DaCBjLTnvZCNutpyH/vwu8qjsValBtu1smzMqYJA==
X-Gm-Gg: ASbGncs007rLL/5iELvehBpm+2CPYlLHJxPvfPinP6j9yHrTwy3w0lO6iGBwVMaKiXo
	CljNkKADg2uQRqAhxORR5jdLXlhk/8Be73yB0aEWIuY2KHsXRWjVSbI5m7WkYxHQYorVyHeC4lh
	W5tiIsJ+dGEJlB+L5lYhpqJYOAIVO+rRr2srs/oqTKnLDvINv58/osOLLorzyLu3PlMfjA5TPNu
	Ik4B9wsVUE+WVW1LaECGNMI2IohEOfIRrjQQj745g+yY58tfvuTqcUgKZYAQM45ZA0AL3tJEbIy
	PZLYmtfsoc0ZvbJZRLz3jq7kZpqq4a9V3HPghxrDdH9blynTvMJj7fwYBEXmzvSdAg==
X-Google-Smtp-Source: AGHT+IGQJbPCqTpRCuBhPuDdpu3G9o3PvkpXd6egHoRZJeP74h8BeEHGQx3eQa+XnL5Hl/eXLXlmvQ==
X-Received: by 2002:a17:907:706:b0:aa6:5201:7ae3 with SMTP id a640c23a62f3a-ab38b3b23e1mr4327358266b.40.1737982328994;
        Mon, 27 Jan 2025 04:52:08 -0800 (PST)
Message-ID: <a159353b-cd3c-418b-9102-f00ed2098d64@suse.com>
Date: Mon, 27 Jan 2025 13:52:10 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/2] gnttab: make grant table v2 support configurable
To: "Daniel P. Smith" <dpsmith@apertussolutions.com>,
 Christopher Clark <christopher.w.clark@gmail.com>
Cc: openxt@googlegroups.com, Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <20250110133711.3958202-1-dpsmith@apertussolutions.com>
 <20250110133711.3958202-3-dpsmith@apertussolutions.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250110133711.3958202-3-dpsmith@apertussolutions.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.01.2025 14:37, Daniel P. Smith wrote:
> If the v2 interface support is not required, disabling this option will remove
> substantial amounts of unused code in a critical subsystem.
> 
> Disables the v2-only GNTTABOP_get_status_frames grant table op.

Why's this explicitly mentioned, but not e.g. GNTTABOP_{get,set}_version,
which ought to disappear altogether as well is you mean to truly limit
functionality to a pre-v2 hypervisor? Even a post-v2 addition like
GNTTABOP_swap_grant_ref might arguably need disabling then.

> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -1278,8 +1278,8 @@ does not provide `VM_ENTRY_LOAD_GUEST_PAT`.
>  
>  Control various aspects of the grant table behaviour available to guests.
>  
> -* `max-ver` Select the maximum grant table version to offer to guests.  Valid
> -version are 1 and 2.
> +* `max-ver` Select the maximum grant table version to offer to guests. Only
> +available when CONFIG_GRANT_TABLE_V2 is set. Valid version are 1 and 2.

No, the option ought to still be legitimate to use with value 1.

> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -23,6 +23,24 @@ config GRANT_TABLE
>  
>  	  If unsure, say Y.
>  
> +config GRANT_TABLE_V2
> +	bool "Grant table version 2 support" if EXPERT

While often I'm a proponent of using EXPERT, here I'm uncertain it
really takes an expert to turn this off. Or wait, it's "to turn
this on", as you have no default at all (see also below). This
means a non-expert has no way to configure a hypervisor compatible
with the previous version; that's a no-go imo.

> +	depends on GRANT_TABLE && X86
> +	help
> +	  Grant table interface version 2 is not the default. It has never
> +	  been implemented for ARM.
> +
> +	  The version 2 interface enables support for systems with large amounts
> +	  of memory and some exotic grant primitives that are not in use by the
> +	  supported PV drivers.
> +
> +	  Disabling this option reduces the amount of complex security-critical
> +	  hypervisor code in a subsystem of Xen responsible for approximately
> +	  5% of Xen Security Advisories.
> +
> +	  If you do not require large memory support, say N.
> +	  If you are paranoid, say N. If unsure, say Y.

Should this therefore perhaps have "default BIGMEM"?

> --- a/xen/common/compat/grant_table.c
> +++ b/xen/common/compat/grant_table.c
> @@ -296,6 +296,9 @@ int compat_grant_table_op(
>              break;
>  
>          case GNTTABOP_get_status_frames:
> +#ifndef CONFIG_GRANT_TABLE_V2
> +            rc = -ENOSYS;

I understand ENOSYS is abused elsewhere like this, but can we please not
widen the issue and use EOPNOTSUPP instead?

> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -59,11 +59,13 @@ struct grant_table {
>      /* Lock protecting the maptrack limit */
>      spinlock_t            maptrack_lock;
>      unsigned int          max_version;
> +#ifdef CONFIG_GRANT_TABLE_V2
>      /*
>       * Defaults to v1.  May be changed with GNTTABOP_set_version.  All other
>       * values are invalid.
>       */
>      unsigned int          gt_version;
> +#endif
>      /* Resource limits of the domain. */
>      unsigned int          max_grant_frames;
>      unsigned int          max_maptrack_frames;

Between this and the following hunk there's also nr_status_frames, which
is v2-only too.

> @@ -178,11 +182,20 @@ static int cf_check parse_gnttab_max_maptrack_frames(const char *arg)
>                                opt_max_maptrack_frames_val);
>  }
>  
> +#ifdef CONFIG_GRANT_TABLE_V2
> +
>  #ifndef GNTTAB_MAX_VERSION
>  #define GNTTAB_MAX_VERSION 2
>  #endif
>  #define get_gt_version(gt) ((gt)->gt_version)
>  
> +#else
> +
> +#define GNTTAB_MAX_VERSION 1
> +#define get_gt_version(gt) 1

What about mem_sharing_gref_to_gfn(), which checks for the version not
having been set yet? gnttab_get_shared_frame_mfn() also has an assertion
to this effect.

> @@ -204,12 +217,17 @@ static int __init cf_check parse_gnttab(const char *s)
>          if ( !strncmp(s, "max-ver:", 8) ||
>               !strncmp(s, "max_ver:", 8) ) /* Alias for original XSA-226 patch */
>          {
> +#ifdef CONFIG_GRANT_TABLE_V2
> +            const char *e;
>              long ver = simple_strtol(s + 8, &e, 10);
>  
>              if ( e == ss && ver >= 1 && ver <= 2 )
>                  opt_gnttab_max_version = ver;
>              else
>                  rc = -EINVAL;
> +#else
> +            no_config_param("GRANT_TABLE_V2", "max_ver", s, ss);
> +#endif

See respective comment on the cmdline doc.

> @@ -330,6 +350,14 @@ nr_maptrack_frames(struct grant_table *t)
>  #define status_entry(t, e) \
>      ((t)->status[(e)/STGNT_PER_PAGE][(e)%STGNT_PER_PAGE])
>  
> +#else /* CONFIG_GRANT_TABLE_V2 */
> +
> +#define shared_entry_full_frame(gt, ref) ( shared_entry_v1((gt), (ref)).frame )
> +#define set_shared_entry(gt, ref, val) \
> +    ( shared_entry_v1((gt), (ref)).frame = (val) )
> +#define status_addr(gt, ref, flags_addr) (flags_addr)
> +
> +#endif /* CONFIG_GRANT_TABLE_V2 */

See style related comments on patch 1.

> @@ -734,7 +764,7 @@ static unsigned int nr_grant_entries(struct grant_table *gt)
>          /* Make sure we return a value independently of speculative execution */
>          block_speculation();
>          return f2e(nr_grant_frames(gt), 1);
> -
> +#ifdef CONFIG_GRANT_TABLE_V2
>      case 2:
>          BUILD_BUG_ON(f2e(INITIAL_NR_GRANT_FRAMES, 2) <
>                       GNTTAB_NR_RESERVED_ENTRIES);

Please don't remove blank lines like this.

> @@ -1796,6 +1828,12 @@ static int
>  gnttab_populate_status_frames(struct domain *d, struct grant_table *gt,
>                                unsigned int req_nr_frames)
>  {
> +#ifndef CONFIG_GRANT_TABLE_V2
> +    ASSERT_UNREACHABLE();
> +
> +    return 0;

For a release build you want to return an error here.

> +}

Hmm, the opening figure brace above then has two closing counterparts.
People may find this confusing, and since Misra is almost all about
confusion, I wonder whether they actually permit such (albeit I don't
recall any rule on this matter).

> +#else
>      unsigned int i;
>      unsigned int req_status_frames;
>  
> @@ -1898,6 +1936,7 @@ gnttab_unpopulate_status_frames(struct domain *d, struct grant_table *gt)
>  
>      return 0;
>  }
> +#endif

In fact, to add to the confusion the #else part then even extends across
function boundaries, if the hunk header are to be trusted.

> @@ -2518,12 +2559,14 @@ release_grant_for_copy(
>          td = rd;
>          trans_gref = gref;
>      }
> +#ifdef CONFIG_GRANT_TABLE_V2
>      else
>      {
>          td = (act->src_domid == rd->domain_id)
>               ? rd : knownalive_domain_from_domid(act->src_domid);
>          trans_gref = act->trans_gref;
>      }
> +#endif

Why's this needed? Can't leave it to the compiler's DCE?

> @@ -2748,7 +2792,9 @@ acquire_grant_for_copy(
>              act->is_sub_page = true;
>          }
>      }
> -    else if ( !old_pin ||
> +    else
> +#endif
> +    if ( !old_pin ||
>                (!readonly && !(old_pin & (GNTPIN_devw_mask|GNTPIN_hstw_mask))) )
>      {

Hmm, this #if extending across multiple not really related constructs
looks to be the reason why patch 1 moves the assignment to old_pin.

Below from here is an assignment to act->trans_gref. That's another
field that probably better wouldn't exits in a v1-only build. Much
like is_sub_page and perhaps others.

> @@ -3165,6 +3211,17 @@ static long
>  gnttab_set_version(XEN_GUEST_HANDLE_PARAM(gnttab_set_version_t) uop)
>  {
>      gnttab_set_version_t op;
> +#ifndef CONFIG_GRANT_TABLE_V2
> +
> +    if ( copy_from_guest(&op, uop, 1) )
> +        return -EFAULT;
> +
> +    if ( op.version == 1 )
> +        return 0;
> +
> +    /* Behave as before set_version was introduced. */
> +    return -ENOSYS;

Imo in a case like this one if ( !IS_ENABLED() ) would be preferable
to use, to keep as much code as possible exposed to the compiler,
thus reducing the chance of someone not noticing that it also needs
changing for whatever (perhaps) purely mechanical adjustment. I.e.
use #ifdef / #ifndef only in cases where lexical elements would be
missing, thus breaking the build.

> @@ -4080,6 +4146,9 @@ int mem_sharing_gref_to_gfn(struct grant_table *gt, grant_ref_t ref,
>  static int gnttab_get_status_frame_mfn(struct domain *d,
>                                         unsigned int idx, mfn_t *mfn)
>  {
> +#ifndef CONFIG_GRANT_TABLE_V2
> +    ASSERT_UNREACHABLE();
> +#else
>      const struct grant_table *gt = d->grant_table;
>  
>      ASSERT(gt->gt_version == 2);
> @@ -4113,6 +4182,7 @@ static int gnttab_get_status_frame_mfn(struct domain *d,
>      /* Make sure idx is bounded wrt nr_status_frames */
>      *mfn = _mfn(virt_to_mfn(
>                  gt->status[array_index_nospec(idx, nr_status_frames(gt))]));
> +#endif
>      return 0;
>  }

As in the earlier case - the function ought to return an error in a
release build.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 12:52:54 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 12:52:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877873.1288025 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcObk-0006Sv-46; Mon, 27 Jan 2025 12:52:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877873.1288025; Mon, 27 Jan 2025 12:52:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcObk-0006So-1R; Mon, 27 Jan 2025 12:52:52 +0000
Received: by outflank-mailman (input) for mailman id 877873;
 Mon, 27 Jan 2025 12:52:50 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=rEBS=UT=amd.com=Michal.Orzel@srs-se1.protection.inumbo.net>)
 id 1tcObi-0006Ai-J5
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 12:52:50 +0000
Received: from NAM04-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam04on2060b.outbound.protection.outlook.com
 [2a01:111:f403:240a::60b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9b892487-dcad-11ef-99a4-01e77a169b0f;
 Mon, 27 Jan 2025 13:52:48 +0100 (CET)
Received: from BL1PR13CA0450.namprd13.prod.outlook.com (2603:10b6:208:2c3::35)
 by SA1PR12MB8597.namprd12.prod.outlook.com (2603:10b6:806:251::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.21; Mon, 27 Jan
 2025 12:52:42 +0000
Received: from BN2PEPF000044A7.namprd04.prod.outlook.com
 (2603:10b6:208:2c3:cafe::b) by BL1PR13CA0450.outlook.office365.com
 (2603:10b6:208:2c3::35) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8398.14 via Frontend Transport; Mon,
 27 Jan 2025 12:52:42 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BN2PEPF000044A7.mail.protection.outlook.com (10.167.243.101) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8398.14 via Frontend Transport; Mon, 27 Jan 2025 12:52:42 +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.39; Mon, 27 Jan
 2025 06:52:41 -0600
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Mon, 27 Jan 2025 06:52:40 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9b892487-dcad-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=XHPcj6wifu+2dtKoZJBRuqTGq1BfW5Ese17h+gwVHK20L+DP1wVIlYTYtI5xEL+u1dyZLgnO//aEJW/hgR4fOHn+QExfCLuYdqdYbB5NcaVh6sq3pu4LfZfgZ3BZoxd21bzQuLbWhO14bG36lB8AeHJAMvhyKFNN2zcurL1XzoTR4FjtUZlYwqzECuunsRMmpmHpcTMQhvu87AFF5zaKIK41MlSgv5PYSPg8/BCG5xxGfwBpHSWRKCHB5k6nzN1mvEZkDmyYrv72RJfyPssv1TW0npV4yN9VEJ6Z/iMWLm9m3hCDm2A0oirbe276ApB0KiPTVuh+MM7fKet/icSnbA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=6XFgsxSwQx1KRayDWUBjwuGRg2YMiR5oxVMFrlWouDI=;
 b=GFItp0rBjmIT0bvBnuZZQwqMkOP5LMv2EsqxnS3rT61VBl6Rm6gY89kcEBWXcZXZgijuvoP+BT/4bkUbI2/neLs3U3j5G4WK4iJJ324Xn41ueiaQo8rBSsCk6wV1lzgs4ctPuHnd2RnisR7p8QpwDJXVeuh16lSDPKbgAdtUYVWe0ZuJTtwrU1F6Reulie2qsaeFyYc993RcaKAuX0Xs9R/6FpkmDdMkaGbr33n2PmQBnDRBl9vzi/yrECKzEEg6qLSBzv8wEo3RvFrDcwy8Qi/s95H6R95cYmgro0hPunXK5vfqkyHvQgNZJOl2j9tJ1lEbaoGzdaizZU8JARkNrw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=gmail.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=6XFgsxSwQx1KRayDWUBjwuGRg2YMiR5oxVMFrlWouDI=;
 b=2Fmt9P61o8vDHkvGEbUcbtyHqVN68KyX7v2KNBeXrSDfqm9AaRsvJB7l8RQvKhxpdEHzPHod0ZRVyQXVuuq4/GwWeD80fynHyqad5TmhbH/HIy01X9ZODSow6rdCDyAYrBN4CfTBX9RPQDprbRiamZ7Ij0CSzO7cRZDDDrGiPNc=
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: <32d42df5-08d9-4670-a571-ef315897514b@amd.com>
Date: Mon, 27 Jan 2025 13:52:39 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [for-4.20][PATCH 1/2] device-tree: bootfdt: Fix build issue when
 CONFIG_PHYS_ADDR_T_32=y
To: Julien Grall <julien.grall.oss@gmail.com>
CC: <xen-devel@lists.xenproject.org>, Stefano Stabellini
	<sstabellini@kernel.org>, Bertrand Marquis <bertrand.marquis@arm.com>,
	<oleksii.kurochko@gmail.com>
References: <20250127104556.175641-1-michal.orzel@amd.com>
 <20250127104556.175641-2-michal.orzel@amd.com>
 <CAJ=z9a24=PE-3bhmZvfTaTgpdCXp9iDTWfoH-9F9-_OdkEf4Tg@mail.gmail.com>
Content-Language: en-US
From: Michal Orzel <michal.orzel@amd.com>
In-Reply-To: <CAJ=z9a24=PE-3bhmZvfTaTgpdCXp9iDTWfoH-9F9-_OdkEf4Tg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Received-SPF: None (SATLEXMB03.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN2PEPF000044A7:EE_|SA1PR12MB8597:EE_
X-MS-Office365-Filtering-Correlation-Id: efff4bb7-4be0-434c-6df3-08dd3ed17ce3
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|82310400026|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?cHIzZS9YQ2J2eHEvUG5JU3dlQmhXNnVvT0ZJNWlQZDh2blpybFVDRmJrVUMr?=
 =?utf-8?B?VlhQQ1ByL1FGZ05qMnl3VUtoeWtDSWY0K0JJQUV1Q0cycFhzenhjYTlZZWhB?=
 =?utf-8?B?alh1K0hsVVFiTVVFa3BYOTBjbDk3K3ArR1JndmYvMlVJQXZQRktyeGhHQTc3?=
 =?utf-8?B?dThycmVwSjFTSm10bGJWYVNUL3lIaXpqR2RTOXJLUTBpaEVDMFRudFV4SWV2?=
 =?utf-8?B?V085TGdwNC9vRTFPbUtXNk9VaTA2dmhtakNvTFNlYmpIcVpIL05xSHozNXNq?=
 =?utf-8?B?dUY4Nis5bTNuQWtodUFjQUlqSGVLZ1E5eVR4aWdDdGtkMm5uOTBJMlVHM0tW?=
 =?utf-8?B?b1VyekVOYy9nVlNoQ1pSK3NHSUpLYXZTdU44eXFENHRCU0xUcHJ0VkRNUFJP?=
 =?utf-8?B?RjY2QWQ2UmIvT1M5eG5LT0ZrQ21nRlZtN2Z5VkxLSWNHSy9TMkwwT3M3RHhL?=
 =?utf-8?B?ZGZVYXVRNndobFB3K1Z0dVIwaS94TWNOb2dtalQ0ZVp4dVQ3bzhML0R1Njk0?=
 =?utf-8?B?c0svQUpzS213K21wcWNteFNCOFZJMFptdkFMcG9ORFE2WXRxVTlHNWdoWDBx?=
 =?utf-8?B?YmpFTnlud01iWmQ1YVZsN1NGaWM4UWhVM09wL0l1UUZuTzc5VzJtc0dCNmZz?=
 =?utf-8?B?QTdYZ3dDUmtHUEE3L2t4a1BjeDB6MjJHY3ZkR1VHUXF5T05EZ3NPR2pKUkRI?=
 =?utf-8?B?bTcrS3R5T2t3a25iZTR5cC9aWHhPZGpsSDN6VERFYXNkNU9WZVJYUmtOK2hX?=
 =?utf-8?B?MnlRNDFzYjhrbExraEtjbDBtZ3E4Z3AxaXJITlRGdzhjWm1qejBEZlNKYTZK?=
 =?utf-8?B?bExHT29GSTdsamJOZkR2YlZCOWh4VmJEUDdSdm9vTWdGSzd3aGNrREVxeHdw?=
 =?utf-8?B?ZStJdVF6bEl5RXdlMElmYjMxUzNWSkpiOFFGcmlOV1JWSkRxWFo1UmJOaG05?=
 =?utf-8?B?dlZpYm5ncXdpVVIvWWp1eEFqUnFlOXlvRmZiR3RmQ2J5bGp6NlVSN21MMGJ6?=
 =?utf-8?B?N0hjeWJQclhsSGlVS3BCOEFaRzB2TnhHcHI3a1dJU2V4UmNSUEtHZHUwRnVs?=
 =?utf-8?B?bXQvNllYWEN2YU9rUTBBR2Nhckl4YmtSMWFqYkRLeUlidzhBckJuMHdpaVlw?=
 =?utf-8?B?WDZQSXpzLzlTSTZpM1RsV0krZFRKWVZLUXhSMFpwcGR1eGgzL0paTmJNQ0lO?=
 =?utf-8?B?TzVlZ0p5VUNyaHhhZGxSTE9CME0xWUZuek9EbUhPNzNxdkV5bWdCaUZBN0Jt?=
 =?utf-8?B?Wm9INmhzYmZRY2pWTXJOM2FYcFBtbWJUcjZTbkFaNW4waVE3Qi9OcDl1elNU?=
 =?utf-8?B?MW5zc24yRnZhMklySGNJY2hjVmYwZGo5KzJ2NkdvaHplS3ZOUVMxbnJPMXdB?=
 =?utf-8?B?OUZHOEhxcThZZFRBc3o4OFkvZ0h6dENxaWhtMFVEODBMcW9oREtDUWlXajFs?=
 =?utf-8?B?bnd1Y0lvdFJkc0M4OEs2UXExTDY1S0dnUHZOOElpNXFrVW8yeUhUTndDRWVj?=
 =?utf-8?B?MVVBRUJBSVIxK0ZPUXZ6TytUMGFKT2lXWklwQmo0eUdyaUUxVUVla3pJUlky?=
 =?utf-8?B?OFlhZGFURk5nOHQ5OVQ1R0JKMWhqNUQwbHFUUWlLMmh6V28welg3WFllaGdM?=
 =?utf-8?B?amJObm0vc0lFN1pDTkpmVDJ3ZXc2KzgyajM1NEV1SnVQZEswRzNqZTFFQzdq?=
 =?utf-8?B?WmUzWjl3R3dKTnBEaDJneHIrekZBNWlVMU1HSitKQmV0NXRMWStTLzNDVnl4?=
 =?utf-8?B?eERsRFRxQ0s5L1VjWmk4RXpZc1Yyck9PY0RBcjZOSHFFVlNqbkNad0ZhVHVQ?=
 =?utf-8?B?UktuV1RTdWJGKzVtQlRxVDl4ZmVGSHlHb2FCOUQ4dEhnbzBKNFY4NGk0Q1lx?=
 =?utf-8?B?aElxU2ZtOGJUd2RFQ1JhSUdBS1pLaHB3ekFnMWlHOTNIUTc1YVJ4WW1aclZk?=
 =?utf-8?B?Q1JuZTZacUxqcVo1NExWb014WmYxbWtURzZjZUJ1SnRzOEpPV0VlSFVRSE85?=
 =?utf-8?Q?j/hh6E5CdQzFI6ZKtHiF/j/NLqVnWw=3D?=
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:(13230040)(36860700013)(82310400026)(1800799024)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2025 12:52:42.0220
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: efff4bb7-4be0-434c-6df3-08dd3ed17ce3
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:
	BN2PEPF000044A7.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB8597



On 27/01/2025 12:19, Julien Grall wrote:
> 	
> 
> 
> 
> 
> On Mon, 27 Jan 2025 at 07:46, Michal Orzel <michal.orzel@amd.com <mailto:michal.orzel@amd.com>> wrote:
> 
>     On Arm32, when CONFIG_PHYS_ADDR_T_32 is set, a build failure is observed:
>     common/device-tree/bootfdt.c: In function 'build_assertions':
>     ./include/xen/macros.h:47:31: error: static assertion failed: "!(alignof(struct membanks) != 8)"
>        47 | #define BUILD_BUG_ON(cond) ({ _Static_assert(!(cond), "!(" #cond ")"); })
>           |                               ^~~~~~~~~~~~~~
>     common/device-tree/bootfdt.c:31:5: note: in expansion of macro 'BUILD_BUG_ON'
>        31 |     BUILD_BUG_ON(alignof(struct membanks) != 8);
> 
>     When CONFIG_PHYS_ADDR_T_32 is set, paddr_t is defined as unsigned long,
>     therefore the struct membanks alignment is 4B. Fix it.
> 
> 
> Usually, we add a BUILD_BUG_ON when other parts of the code rely on a specific property (in this case alignment). Can you explain in the commit message why the new check is still ok?
Well, the change itself reflects the change in alignment requirement.
When paddr_t is 64b (Arm64, Arm32 with PA=40b) the alignment is 8B.
On Arm32 with PA=32b, the alignment is 4B because paddr_t is 4B.

AFAICT you requested this check back then, because struct membanks contains flexible array member 'bank' of type struct membank.
The alignment requirement of struct membanks becomes the requirement of struct membank whose largest type is paddr_t.
Let me know how you would like to have this written in commit msg.

~Michal



From xen-devel-bounces@lists.xenproject.org Mon Jan 27 12:57:33 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 12:57:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877886.1288045 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcOgE-0007LP-Rt; Mon, 27 Jan 2025 12:57:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877886.1288045; Mon, 27 Jan 2025 12:57:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcOgE-0007LI-Oo; Mon, 27 Jan 2025 12:57:30 +0000
Received: by outflank-mailman (input) for mailman id 877886;
 Mon, 27 Jan 2025 12:57: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 <SRS0=O4xJ=UT=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcOgD-00076M-UT
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 12:57:29 +0000
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com
 [2a00:1450:4864:20::52d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 43c924ac-dcae-11ef-a0e6-8be0dac302b0;
 Mon, 27 Jan 2025 13:57:29 +0100 (CET)
Received: by mail-ed1-x52d.google.com with SMTP id
 4fb4d7f45d1cf-5da135d3162so7147932a12.3
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 04:57:29 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5dc186d8b2csm5321649a12.76.2025.01.27.04.57.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 04:57:28 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 43c924ac-dcae-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737982649; x=1738587449; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=375YL9UDa11NDi6dH/k8prBNJ3z5vQKoj3LGrcRAB6I=;
        b=WqB8nWp11/IRqFXKwWyg/di67KaM7o733plNybps/+icjJgnEiPxK7Xy+i5Grf3ZH/
         udT9WVet+vwqKfMfEFj1F0mnzN1sXa5eQyVPXALY7DMFGNluUDTMFxlTxGh/pBybARib
         w6/ornuaqYXCCFT2AksvObWJQubW0tNLIRMOL1KO9yq0Q2MtWUtmvfzf5re18Ihs7c9t
         Xb9GRm1e/bwiFLAzzS68NtUUVC6JNE4boZOEnPghQRz9HBofJgeawcxPuIiYgrdvyv8a
         oSwak14itnJ8IasEK3lsKvqElPLog/AW+/EwVlcn345KQblo67IxKCrAc/rNNr5ueDLM
         FnQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737982649; x=1738587449;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=375YL9UDa11NDi6dH/k8prBNJ3z5vQKoj3LGrcRAB6I=;
        b=Z4LiM9yw3TBm9MjU0auhVDlVAs+GILhPtsJP2gErAdLUl0HiljGCY/xXZl63jUntzZ
         RMERq+cQBgyFEGvYrg/hyj2FmELTe6jFOcIaZEojx+C3cXa+IcHFO5joErQQJAIkuIBG
         C9rGiqoURNzpVCVpFO4rBW6LvEKCAX9P2Gi78xRSJI1vij35IDty6EBrwciRe9TEC14q
         Cm/BsFDgU8U9IMAPSk/OCs+T3Wb3WKqfZvVAgJnbUkrIaqg45XxZpaQi/Sd6IojEzXRc
         TPyJkyMjH5zWVknNT5OV1kGOPnYOx5b4uALQYSIaHTP6qY+oCaxyDXhZzZSH21+UMfWc
         CKLw==
X-Forwarded-Encrypted: i=1; AJvYcCUMdtOORqsmP7sWD35slG7lr7LAH/2NSPSqsOPuayvdUmhvowxxwfdnDOmwgk8+DMPvorQ9xRVwJXc=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz4T5LXta0cKuz//RxiVmZ0MIXWx78KqXQpttR4ZQi9q6dFY1nj
	wF+a8tP2thzkmmq4rRbfKrNzjOrCPRXvIttYVu8OYR/vxDZLhsLrLrLOsYQaow==
X-Gm-Gg: ASbGncvV0s+uNLzGTkHtzaB5oa8JpwbjOjzX+SAZvoFr0CitG/ABeBsnb3nadlfmyiF
	4aAfpDPpNrSi2/LuZoBhp6aZ9l1Fp5qJ/I1fbZCNJA0Oljpt7Oet1eus+qqJFdrPw+n/M/50UzA
	6Bz9/lteKhGbJRkcMUrm1BXPNrbNeoq8kitsHiSYG08IGelOolzYEu1jV5k3O5D26NEH7cs0qwW
	suJ9eZxL6leHkW4I0RYyqv+YMLn9XjB5RpGGweuCeXLnWBe4zE2VDV4ohAv0jBIecwJCTTwOXQZ
	XkGClqkyIQWY+QmnRAOWecRNsiqQ4oz7y1ZfAUdQ0e5wIyp6zNUHonGIo6ktX+eZ0w==
X-Google-Smtp-Source: AGHT+IGs4WW77xrtSQWyDnSMLPTZ++Iyhpn/ApqEEdHB34tmygdbPNtiBcma3XhHS5gGF34JE1adqA==
X-Received: by 2002:a05:6402:27cc:b0:5d0:b2c8:8d04 with SMTP id 4fb4d7f45d1cf-5db7d3005b5mr41272885a12.18.1737982648562;
        Mon, 27 Jan 2025 04:57:28 -0800 (PST)
Message-ID: <a304e4f0-709f-4fcd-9847-01fe6ab4b98c@suse.com>
Date: Mon, 27 Jan 2025 13:57:30 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 1/3] xen/riscv: implement software page table walking
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Alistair Francis <alistair.francis@wdc.com>,
 Bob Eshleman <bobbyeshleman@gmail.com>, Connor Davis
 <connojdavis@gmail.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1737391102.git.oleksii.kurochko@gmail.com>
 <00dfc71569bc9971b53e29b36a80e9e020ac61ac.1737391102.git.oleksii.kurochko@gmail.com>
 <21bfd2f5-74b8-409e-956c-dd736a3c0be2@suse.com>
 <e2290a2a-a3c0-4cfe-b9e9-8cfec0b194a8@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <e2290a2a-a3c0-4cfe-b9e9-8cfec0b194a8@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 27.01.2025 13:29, Oleksii Kurochko wrote:
> On 1/27/25 11:06 AM, Jan Beulich wrote:
>> On 20.01.2025 17:54, Oleksii Kurochko wrote:
>>> RISC-V doesn't have hardware feature to ask MMU to translate
>>> virtual address to physical address ( like Arm has, for example ),
>>> so software page table walking in implemented.
>>>
>>> Signed-off-by: Oleksii Kurochko<oleksii.kurochko@gmail.com>
>>> ---
>>>   xen/arch/riscv/include/asm/mm.h |  2 ++
>>>   xen/arch/riscv/pt.c             | 56 +++++++++++++++++++++++++++++++++
>>>   2 files changed, 58 insertions(+)
>>>
>>> diff --git a/xen/arch/riscv/include/asm/mm.h b/xen/arch/riscv/include/asm/mm.h
>>> index 292aa48fc1..d46018c132 100644
>>> --- a/xen/arch/riscv/include/asm/mm.h
>>> +++ b/xen/arch/riscv/include/asm/mm.h
>>> @@ -15,6 +15,8 @@
>>>   
>>>   extern vaddr_t directmap_virt_start;
>>>   
>>> +paddr_t pt_walk(vaddr_t va);
>> In the longer run, is returning just the PA really going to be sufficient?
>> If not, perhaps say a word on the limitation in the description.
> 
> In the long run, this function's prototype looks like|paddr_t pt_walk(vaddr_t root, vaddr_t va, bool is_xen)| [1]. However, I'm not sure if it will stay that way,
> as I think|is_xen| could be skipped, since using|map_table()| should be sufficient (as it now considers|system_state|) and I'm not really sure if I need root argument
> as initial goal was to use this function for debug only purposes and I've never used it for guest page table (stage-1) walking.
> Anyway, yes, it is still returning a physical address, and that seems enough to me.
> 
> Could you share your thoughts on what I should take into account for returning value, probably, I am missing something really useful?

Often you care about the permissions as well. Sometimes it may even be relevant
to know the (super-)page size of the mapping.

> |[1] 
> https://gitlab.com/xen-project/people/olkur/xen/-/blob/latest/xen/arch/riscv/mm.c#L820|
> 
>>> +     * initialize `ret` with "impossible" XEN_TABLE_MAP_NOMEM.
>>> +    */
>>> +    int ret = XEN_TABLE_MAP_NOMEM;
>>> +    unsigned int level = HYP_PT_ROOT_LEVEL;
>>> +    paddr_t pa = 0;
>> Seeing 0 as initializer here, just to double check: You do prevent MFN 0
>> to be handed to the page allocator, and you also don't use it "manually"
>> anywhere?
> 
> MFN 0 could be used when removing the page:https://gitlab.com/xen-project/xen/-/blob/staging/xen/arch/riscv/pt.c?ref_type=heads#L251 <https://gitlab.com/xen-project/xen/-/blob/staging/xen/arch/riscv/pt.c?ref_type=heads#L251>.
> 
> In that case, it would be better to initialize|pa| with|(paddr_t)(-1)|, as this value couldn't be mapped and is safe to use as an invalid value.
> 
>>
>>> +    pte_t *table;
>>> +
>>> +    DECLARE_OFFSETS(offsets, va);
>>> +
>>> +    table = map_table(root);
>>> +
>>> +    /*
>>> +     * Find `pa` of an entry which corresponds to `va` by iterating for each
>>> +     * page level and checking if the entry points to a next page table or
>>> +     * to a page.
>>> +     *
>>> +     * Two cases are possible:
>>> +     * - ret == XEN_TABLE_SUPER_PAGE means that the entry was find;
>>> +     *   (Despite of the name) XEN_TABLE_SUPER_PAGE covers 4k mapping too.
>>> +     * - ret == XEN_TABLE_MAP_NONE means that requested `va` wasn't actually
>>> +     *   mapped.
>>> +     */
>>> +    while ( (ret != XEN_TABLE_MAP_NONE) && (ret != XEN_TABLE_SUPER_PAGE) )
>>> +    {
>>> +        /*
>>> +         * This case shouldn't really occur as it will mean that for table
>>> +         * level 0 a pointer to next page table has been written, but at
>>> +         * level 0 it could be only a pointer to 4k page.
>>> +         */
>>> +        ASSERT(level <= HYP_PT_ROOT_LEVEL);
>>> +
>>> +        ret = pt_next_level(false, &table, offsets[level]);
>>> +        level--;
>>> +    }
>>> +
>>> +    if ( ret == XEN_TABLE_MAP_NONE )
>>> +        dprintk(XENLOG_WARNING, "Is va(%#lx) really mapped?\n", va);
>> Even if it's a dprintk(), I'd recommend against adding such.
>>
>>> +    else if ( ret == XEN_TABLE_SUPER_PAGE )
>>> +        pa = pte_to_paddr(*(table + offsets[level + 1]));
>> Missing "else if ( ret == XEN_TABLE_NORMAL )" (or maybe simply "else")?
> 
> If I am not missing something, we can't be here with ret == XEN_TABLE_NORMAL because we iterating
> in the while loop above until we don't find a leaf or until reach level = 0.

I'll admit that I didn't specifically check whether XEN_TABLE_NORMAL could
be observed here; my point was that non-super-page mappings aren't handled,
as you ...

> If we find a leaf then
> XEN_TABLE_SUPER_PAGE is returned; otherwise sooner or later we should face a case when next table
> (in case when `level`=0 and someone put at this level a pointer to next level, what is a bug) should
> be allocated in pt_next_level(), but it will fail because `alloc_tbl`=false is passed to pt_next_level()
> and thereby ret=XEN_TABLE_MAP_NONE() will be returned.
> 
> Based on your previous comment about dprintk this could could be re-written in the following way:
> -    if ( ret == XEN_TABLE_MAP_NONE )
> -        dprintk(XENLOG_WARNING, "Is va(%#lx) really mapped?\n", va);
> -    else if ( ret == XEN_TABLE_SUPER_PAGE )
> +    if ( ret != XEN_TABLE_MAP_NONE )
>           pa = pte_to_paddr(*(table + offsets[level + 1]));

... appear to confirm here.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 12:57:33 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 12:57:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877885.1288036 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcOgC-00076g-MU; Mon, 27 Jan 2025 12:57:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877885.1288036; Mon, 27 Jan 2025 12:57:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcOgC-00076Z-IM; Mon, 27 Jan 2025 12:57:28 +0000
Received: by outflank-mailman (input) for mailman id 877885;
 Mon, 27 Jan 2025 12:57:26 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=qVGR=UT=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tcOgA-00076M-HJ
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 12:57:26 +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 41b41f53-dcae-11ef-a0e6-8be0dac302b0;
 Mon, 27 Jan 2025 13:57:25 +0100 (CET)
Received: by mail-lf1-x132.google.com with SMTP id
 2adb3069b0e04-53e3a227b82so4016796e87.0
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 04:57:25 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-543c8379be8sm1296968e87.204.2025.01.27.04.57.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 04:57:24 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 41b41f53-dcae-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1737982645; x=1738587445; darn=lists.xenproject.org;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=jWefbBTCeVOk62mw1ZLnk+eLCt1n5rifbFY1laAebzU=;
        b=WaHgmcXfVLYY5g8JvGOFsKgaS4mQBuLI+r6AuiT/Ufb8NCafIx0jFw6YRYY0q09o4O
         iFV8/LqKOnRAzdFz8d0ao/f8+fCZ6aNbZr63q8e32m9HPlKf7Gd9rkxTVYUniRn+QuXq
         4HpLf8tfD6frkiVLftR8Gx/6cXKkLnYADkJMICwFIslreGVO7pVpQ0PHGwCjkKR/h95h
         +IagtJaxAoLQ/KwnA+dNyDgWnK/AxVG/Z681OKDy7yY2YgE2yanpqa3iJAA/adsAHi4a
         vAnlRqE+vqN2Y4ik7L75kZHpuYpEjQqszQB2LOz5WMRSVtr98MOnV2n64zQOyb6+8yVG
         eEZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737982645; x=1738587445;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=jWefbBTCeVOk62mw1ZLnk+eLCt1n5rifbFY1laAebzU=;
        b=mW9sGjb+pVAILDeblTh8TGmI7fLWvfJC0pfkqtAdbcZ5f8+lSKMm9p60XmQFNbNSEV
         lhbEh5DQuus0llWdZr7Dv5OkuzneXfuRd255sBZ1n+2M2Nn8mF5cwjBvqkhAqOgDh+5C
         ISKaRYAASua9iWAnmyoTpx2WGqwypSQsAbx5lcuN6/hMBPK0V6Ecp9wf7DxiW3WhUZLM
         h23ZfgJKwh7Eln1xDICG8YjPQZkj2U4pJgu0T34SNKEpurNO8T63p1nS14AsFKVl/4/9
         AOz8xeM3ZxeQZOwXI8qhKKs1SuaMjUuLoPODfL7BykL7/2cPkBPOQtDBFLoD3W1/jdy3
         VyAw==
X-Forwarded-Encrypted: i=1; AJvYcCVSocrJEjdVqa7V0XBU2usdsqDnn9a1WwaJvF62bNeftg7F2L7AynhszMbOFtIGFJnjobt4ni40pQE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyJ7AUJHQOTj7rFz6Z8/R9lopgUiNC0L6P3jws4Pm/3NTkUy6u0
	rOMWU2X49Ph8RsbBBhNN2pC4gXFNr3Qq7IwRblZlJkthE0kWgtSC
X-Gm-Gg: ASbGncsX0KjIl8MfKt/QBYLyU5iXu9kyDtnJRYB2xujS/rsTMSyYrKC245agT0+PVG4
	j5vMPeq/LQd0Mb/ecpTlQzNvsIe49EQIXDh36ph4RmZvHGbJYRSGEF1joaamsoVY8Zj48zIQxU9
	REPGFtZMM65JVqnu+qf8iXINKoSSigkJvDyCMPgnh+C/NNJ6Oz70WZg/Ighs54OE/G8tIjlEGGw
	2ReOjICTSTnGLVB6MxtDUajmsACQapQKJPwJUlqvrEj+cdBzCeQDNHRwx0VMvk8jtv9ERpd4j2i
	l3CfHiVLVLhfClXVOw==
X-Google-Smtp-Source: AGHT+IGTo+4NTDlsk05yDhdc8NJvuN/hzuvqBVYnlbbV9kfAyx5HQbgBYH3YqWT2/HVoC4MFY9cF3w==
X-Received: by 2002:a19:7618:0:b0:540:3594:aa39 with SMTP id 2adb3069b0e04-5439c218d67mr12071453e87.5.1737982644948;
        Mon, 27 Jan 2025 04:57:24 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------BL6x5PA2XTBJl4e10ja4Dq8l"
Message-ID: <c50c70a6-d408-47a1-a97c-cde9b62108ad@gmail.com>
Date: Mon, 27 Jan 2025 13:57:24 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [for-4.20][PATCH 0/2] xen/arm CONFIG_PHYS_ADDR_T_32=y fixes
To: Michal Orzel <michal.orzel@amd.com>, xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
 <julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
References: <20250127104556.175641-1-michal.orzel@amd.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <20250127104556.175641-1-michal.orzel@amd.com>

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


On 1/27/25 11:45 AM, Michal Orzel wrote:
> This series contains build fixes when CONFIG_PHYS_ADDR_T_32=y.
>
> @Oleksii:
> This is a release blocker.

Agree, we can't proceed with release if we have build issues. So with proper review:

R-Acked-by: Oleksii Kurochko<oleksii.kurochko@gmail.com>

Thanks.

~ Oleksii

>
> Michal Orzel (2):
>    device-tree: bootfdt: Fix build issue when CONFIG_PHYS_ADDR_T_32=y
>    xen/arm: Fix build issue when CONFIG_PHYS_ADDR_T_32=y
>
>   xen/arch/arm/include/asm/mm.h    | 2 +-
>   xen/common/device-tree/bootfdt.c | 4 ++--
>   2 files changed, 3 insertions(+), 3 deletions(-)
>
--------------BL6x5PA2XTBJl4e10ja4Dq8l
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 1/27/25 11:45 AM, Michal Orzel
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:20250127104556.175641-1-michal.orzel@amd.com">
      <pre wrap="" class="moz-quote-pre">This series contains build fixes when CONFIG_PHYS_ADDR_T_32=y.

@Oleksii:
This is a release blocker.</pre>
    </blockquote>
    <pre>Agree, we can't proceed with release if we have build issues. So with proper review:</pre>
    <pre>R-Acked-by: Oleksii Kurochko <a class="moz-txt-link-rfc2396E" href="mailto:oleksii.kurochko@gmail.com">&lt;oleksii.kurochko@gmail.com&gt;</a></pre>
    <pre>Thanks.
</pre>
    <pre>~ Oleksii
</pre>
    <blockquote type="cite"
      cite="mid:20250127104556.175641-1-michal.orzel@amd.com">
      <pre wrap="" class="moz-quote-pre">

Michal Orzel (2):
  device-tree: bootfdt: Fix build issue when CONFIG_PHYS_ADDR_T_32=y
  xen/arm: Fix build issue when CONFIG_PHYS_ADDR_T_32=y

 xen/arch/arm/include/asm/mm.h    | 2 +-
 xen/common/device-tree/bootfdt.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

</pre>
    </blockquote>
  </body>
</html>

--------------BL6x5PA2XTBJl4e10ja4Dq8l--


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 13:50:02 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 13:50:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877910.1288075 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcPUr-0007xN-MM; Mon, 27 Jan 2025 13:49:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877910.1288075; Mon, 27 Jan 2025 13:49:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcPUr-0007xG-JU; Mon, 27 Jan 2025 13:49:49 +0000
Received: by outflank-mailman (input) for mailman id 877910;
 Mon, 27 Jan 2025 13:49: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
 <SRS0=K0bb=UT=arm.com=Luca.Fancellu@srs-se1.protection.inumbo.net>)
 id 1tcPUq-0007x9-6l
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 13:49:48 +0000
Received: from EUR02-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur02on2062e.outbound.protection.outlook.com
 [2a01:111:f403:2607::62e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 919244ad-dcb5-11ef-a0e6-8be0dac302b0;
 Mon, 27 Jan 2025 14:49:46 +0100 (CET)
Received: from DU2PR04CA0080.eurprd04.prod.outlook.com (2603:10a6:10:232::25)
 by DB9PR08MB8292.eurprd08.prod.outlook.com (2603:10a6:10:3dc::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.22; Mon, 27 Jan
 2025 13:49:36 +0000
Received: from DU2PEPF00028D0F.eurprd03.prod.outlook.com
 (2603:10a6:10:232:cafe::2f) by DU2PR04CA0080.outlook.office365.com
 (2603:10a6:10:232::25) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8377.22 via Frontend Transport; Mon,
 27 Jan 2025 13:49:36 +0000
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 DU2PEPF00028D0F.mail.protection.outlook.com (10.167.242.23) with
 Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8377.8
 via Frontend Transport; Mon, 27 Jan 2025 13:49:35 +0000
Received: ("Tessian outbound 3f086efbd534:v554");
 Mon, 27 Jan 2025 13:49:35 +0000
Received: from L5e1b1e800378.2
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 3F76D4DD-30B3-4CB3-B44F-D3BC953EC67C.1; 
 Mon, 27 Jan 2025 13:49:24 +0000
Received: from OSPPR02CU001.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id
 L5e1b1e800378.2 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Mon, 27 Jan 2025 13:49:24 +0000
Received: from DBAPR08MB5798.eurprd08.prod.outlook.com (2603:10a6:10:1a6::21)
 by AM0PR08MB5299.eurprd08.prod.outlook.com (2603:10a6:208:18d::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.22; Mon, 27 Jan
 2025 13:49:21 +0000
Received: from DBAPR08MB5798.eurprd08.prod.outlook.com
 ([fe80::4a66:d3e2:570:9632]) by DBAPR08MB5798.eurprd08.prod.outlook.com
 ([fe80::4a66:d3e2:570:9632%4]) with mapi id 15.20.8377.021; Mon, 27 Jan 2025
 13:49:21 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 919244ad-dcb5-11ef-a0e6-8be0dac302b0
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=ezP/MHPLh0t6+21H+8ewSZbEJVCBfP1J50+kxod5MSKldAsYa5qjfHJpvqClVGewk6XwuP/hL9XpWFalRaoBkdVgyifEhEIxSb3CRmkwD6DrtITEIwwTy/crYyJGbfU5dyCQOtLgmCnCPthCBiaZ7Pj38RNS0kqdA9aUTh01zKXfsKgrOl2+wMX3tE7qpLjytbev9IveUeLDkyEeIiKacEUltw7Nz8WIB+PYXfUmxYWYPkrId49BocYTpgMtaQwcKOoWSRzL7NHbeZMwBcaZufkICS0vi9jnqZg1EmS68/6RHxnc4mmybG0G7YZ/KJbQ5sLTFTKXOBey9LEt1Gn6Vg==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=ZDVONlOaMzAAscepU/LvtBClbG9Ra6Jrow4jwK4hiYk=;
 b=H/w0keL1NPSFkoVD+kMG/9S6mWVILOMcNGFx9jcOTmZSQptZDmiYtS58lAHdFYBxSwKeXZ+f/F0RFTvGrEOyG/5VUpDQOdy0Ju0eIOMrpPe1KyBeix0oIUzhE2LjQxR20uGvt2Fk70VFwv9Y3QuPTL0kWTFC0pbLG9+q74lCU6K2wHfDxnflMGXU69gXsFe6nNsZ1UycCqzehU1pyurPKzvAHN228+HYEftcg/CzJIrFK8dZe0rNWlz2uO86AuV4sOo9wlmp5bTNQhlj/ImPmBoJTcuMIJirPmL4AvX1uqHCBrDyUxBzqR78KEACOk3spSw/wCILLfaTxVN9fjJFPA==
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=arm.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=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=ZDVONlOaMzAAscepU/LvtBClbG9Ra6Jrow4jwK4hiYk=;
 b=l9ZXrGKzjn1QCW5fsoy5d5vpLk68/GRGl8c8uTOG6PjozrbyePTf1ekaqgTP8iBvbYgNqbHJ5uYb16ZX5UJcVwwlxEVqjdegUfZLzIU6lnV7KYTNsggauMAMtLMoffkAIIlXsYhbMnaj6+KFGZlI2oaXSThwsTI7BdzEE52eEmM=
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=arm.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: 105e37ae198f7235
X-TessianGatewayMetadata: UB0iCwI2A+4kZnBGoebtohqdR19MaoYFPOnjXpmtbvvhyKrVfMsCfHE6Zt4a6wEnJk+EvvgjX86jabpzXx/v0udzRgsdL15NQcOqJmdSRj8bB+NVsfrVkjjvfequVw8/SlOmOrx79mJk7/TfM1oO+p0te77ML2EvBYQCknDCQpo=
X-CR-MTA-TID: 64aa7808
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Cou9TVYqDwtqhyP2ZFLhZXVJMRVf27VNTBeElRtd38Dq8DqVQru4hqSWrlx9PLV84Cm7PXVJjqha0Cdrkvg+X6zShtKC2MfflfMORP4jKC4AQWEoN7zrLq8Z/oXyj+iLZ19JJy1vtW9ObL7MooGsAid6nVG9GztBDtVKzzfdD95QsCTOnaG2U8ue85ldxk60psTSgk6u2nscK1nQEDIFjCKDVy1f535wKI3zonwYQ9VcrN9gHjzkScmoFKowhAhmGsfYf0wZQccP7P+IdtuiBaXvG66qALK8s4my5PSNu+scaLiUqLaZ/hagZcVUSk0Y4JgaujYAfnl2IF2l/pYFeg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=ZDVONlOaMzAAscepU/LvtBClbG9Ra6Jrow4jwK4hiYk=;
 b=gcGqOlwylvnlQorEcR+BScvUvfzR3bElsJqm9jaCbt8mv2zJQ5/vqUpo6gVRvqV6ADQwDy+1m6njZXxfjU+ZZRT3Kz7YRf1lY+QMHjcAqy8nwUI5lpLqWW/jcT+g+CNkf3IjrQo1v6OLF/gy9R6aw3s32+qUUDdBibB/u2FihPZLWAANu19ft+lEVT1ciFMNlzRlUg5659F5FkUFs7V3vDoFxrpH/V3E6BaLobW/bXvBHA9STzb6rMQmgGi0s3tB0TUFkOEeNMa1V2kj8Z/ckhPGItfLIL48P9cUrlttGi/GucVqB/imx3h7nTntyaLko5mez/BxJcC8A3ZxaQsYiw==
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=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=ZDVONlOaMzAAscepU/LvtBClbG9Ra6Jrow4jwK4hiYk=;
 b=l9ZXrGKzjn1QCW5fsoy5d5vpLk68/GRGl8c8uTOG6PjozrbyePTf1ekaqgTP8iBvbYgNqbHJ5uYb16ZX5UJcVwwlxEVqjdegUfZLzIU6lnV7KYTNsggauMAMtLMoffkAIIlXsYhbMnaj6+KFGZlI2oaXSThwsTI7BdzEE52eEmM=
From: Luca Fancellu <Luca.Fancellu@arm.com>
To: Michal Orzel <michal.orzel@amd.com>
CC: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Stefano
 Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand
 Marquis <Bertrand.Marquis@arm.com>, "oleksii.kurochko@gmail.com"
	<oleksii.kurochko@gmail.com>
Subject: Re: [for-4.20][PATCH 1/2] device-tree: bootfdt: Fix build issue when
 CONFIG_PHYS_ADDR_T_32=y
Thread-Topic: [for-4.20][PATCH 1/2] device-tree: bootfdt: Fix build issue when
 CONFIG_PHYS_ADDR_T_32=y
Thread-Index: AQHbcKi0NT74rrzyi0qViFqbxBUYTLMqoxIA
Date: Mon, 27 Jan 2025 13:49:21 +0000
Message-ID: <0093AD65-878F-47FE-B7E8-7CD562AD01F8@arm.com>
References: <20250127104556.175641-1-michal.orzel@amd.com>
 <20250127104556.175641-2-michal.orzel@amd.com>
In-Reply-To: <20250127104556.175641-2-michal.orzel@amd.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.300.87.4.3)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DBAPR08MB5798:EE_|AM0PR08MB5299:EE_|DU2PEPF00028D0F:EE_|DB9PR08MB8292:EE_
X-MS-Office365-Filtering-Correlation-Id: b2a904a3-020c-4b0a-23b0-08dd3ed96f85
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|1800799024|366016|376014|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?utf-8?B?WG5qZUxxd0xyN2xtNStFT1hoNldPRDh3WXllTGZnSURFTmdyaWZWZlZzQTBS?=
 =?utf-8?B?UytWMjhNQ1pDa0RwT0doaTFDa2x6MXhKQS9uRStITjhVT3RLTG1nRFdrTExy?=
 =?utf-8?B?MEtZUTZqNXhaL05PbHlVZFdxV1A5dHV5ZEswN0NtSnlCRWpVdjlvR1k4Vjho?=
 =?utf-8?B?TUZqdEZ0b0kyLzhYMWxvVVo2OWV1TW4vMUY5cWNQb3F4djlGQlhmYzcrcE1w?=
 =?utf-8?B?K3dUUW9iQ09NeXdJeDBzbWRzemVxRFhyaVlSZnpOOHU0eFJRdGk2VEVRM1dX?=
 =?utf-8?B?Wlloc3RjYXl6Y0hoRjVEZmNHaGlWTTF5RExTZGc3cjJqcStIMmdYb2pqT3pt?=
 =?utf-8?B?QzNybW1OTE15RVplQ2l5QmtZNVVFWVgvOWoxWlQ3UjhybVZGdFRENVhraGh4?=
 =?utf-8?B?WnpPaFhYWHJPWG4xa2pLUWdzQVhLTmFHUENiK2ZPaWxTNkRzbHE5UFNEd284?=
 =?utf-8?B?by85OEVkbjhpVXp4eWhjLzZ5ZWNoK3JDMDB4ZDFzWm5TcUtSU0VFYzdydjNl?=
 =?utf-8?B?OFB1WE1SNTl0WGkxNHNjdzU0aEFoWWJndCtqc21kVTJLL2NIalZwblJocCs4?=
 =?utf-8?B?cHVMOGV3TGN4OVVvUVNMaURFTVdPRGgvTEZNdUVoc0pmNXVBTUdoK1pOaVZI?=
 =?utf-8?B?WnNjRitmZFlZaDl2NHkwRHMxYzFUZ2JacWtpdXZhamZSSkxFS2tIQ2dnTE9N?=
 =?utf-8?B?WEVSdTlhSEVnT1FLTVlVaklvZ0dzZWpkeE9JY0NyOTQ5TFRENGtBZEV1aHVk?=
 =?utf-8?B?ZHVWbkxQNjRjY0I1MCtWaE9VemdycnJaazFmOW5pQnRoTTR4WkdLd1U4T2wx?=
 =?utf-8?B?S3BkS2VON0VSR0ZkTVArUVNKK09hVUZGQy9KVC8zd2FCM3EycytUYmtCQzUz?=
 =?utf-8?B?aFpiR3pzUE1IUkx3ZlNpemRWN3JJRGNmdEhJaldoOVNiYnZxRE1LKzg1Ykkr?=
 =?utf-8?B?STBRd3VpcldKNW81NExDRXB2QUV4dVY3TVVUOTJBWThYSW1YVitvVGFHRVQ3?=
 =?utf-8?B?Wm8zb2hDVm4xNW0vQXpka2VnTExrdTFBRFVFVFlBYjBia1lpd3hxSWZ3bWkz?=
 =?utf-8?B?cUtBcklRaVhaNnFtRWFsVDUxL2RHSElmNzZPNzFlMHRqaklwUmo1V2ZIV09V?=
 =?utf-8?B?ZnR2b1dRemowYUJKLzlwS2RHTFhzVDdkUFM4YkVOQjV0QUtHMHNZeTlyYWVB?=
 =?utf-8?B?M0gwUU00TDRUNnQ4YnlESk5UK05HTkFsK3QzY3lJZVN2cUpHOFMzeEpJY2ZZ?=
 =?utf-8?B?QnVrbjlNL2pUVzVVMXFKQUJCVG9Ja3BwNUlmNVdVaWVqYk5JbnNOandhNXZY?=
 =?utf-8?B?cDRPWFU0RHRYWkxwU0xKUjlJaDBEWWlKRmNNNy95dzF1N2RFMWZEVHVWWTEz?=
 =?utf-8?B?cGhYK1BvNjF0ZDFuUEhYcERGS2JzcVRvZzA0R2FMTEd5clpjdmJLbUhtZS95?=
 =?utf-8?B?dFYyWnhybE8rd2p4K0FTS3hlS1dJRnh2ZTZjR0VqZlZMZDRtRDV6YjBCTytq?=
 =?utf-8?B?YnYxRGc0MXR2bTVtd3BPbUFmdEJDWlJTSXJnbTIwbnB4bzJkWURIWFNkZmJh?=
 =?utf-8?B?WHNEa3NNNFZhNmJrNFlQUWFZV0FDVW8renF6a1lJWGRHRldRbUdGVjhMVW1C?=
 =?utf-8?B?aDBEamQvU0Q1MjE0M3VnWEtKU09SNzh1VU4yWklhbUVBVmRxTGYvbGFsaHFz?=
 =?utf-8?B?QlN2VGlpVWk5aUtUaUV0WW5SaER0cWJOMnJJbGJmV0RTUzBGWXRWcmllSUhv?=
 =?utf-8?B?ejFTdXRnVldLR0IybFhGUmxhS2p1UVpQU1F6SzVsS3lYZHlYMmd6M09ma3NX?=
 =?utf-8?B?ek8zU3VKb0cweVUxK29vWGNqZnJZU1RoOXYyTVk5bVZOc3ZFTmFSaHNLK3da?=
 =?utf-8?B?Zm04aVhnR1JrVGtIRm5WdE1HWllRUVNCR215TWFWallhOG50MGR0OEJLbDVB?=
 =?utf-8?Q?QQ+5U3oo4ATZL79bDvUo0xrbKmdHuYQm?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DBAPR08MB5798.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="utf-8"
Content-ID: <73CC14FA2788DE42B40E1F85AE8E8607@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB5299
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-SkipListedInternetSender:
 ip=[2603:10a6:10:1a6::21];domain=DBAPR08MB5798.eurprd08.prod.outlook.com
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DU2PEPF00028D0F.eurprd03.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	a496d90b-cfd8-4f5c-623b-08dd3ed9671d
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|35042699022|14060799003|36860700013|82310400026|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?RktDVFJQeUt5TWxGWUY2aWQ0Wnd2d1ZXY1lWeFF0TFNGbU9tNGM0M2FhS0hV?=
 =?utf-8?B?dE5XcVJxQnc5VHRBMHp3YVpxaXU2WTUrc29GUG1LdCtITHgyVUpXUVRTamFY?=
 =?utf-8?B?OVJWemR5NERCVDIzaE1KN210NHZJT1RhY2l6WTZ2MXU2OVhuVGluMElQb1JH?=
 =?utf-8?B?bnYyUE83OUhCUWUrdU5oekw1UkVnMExhcndURjJ0WGFrYkRqd0RMaXFMMXdi?=
 =?utf-8?B?VXBYNkwzcVNCdUxrRU0zd1lOaVo4d00wM1hHWEM5S0MxVWhLVHFMaldFcHl4?=
 =?utf-8?B?VzU2ZUJ6WFpxTmxhbWNhRmE1N1dlTTA2MFo0VjFacXJhaExnNUgvZTVndHhH?=
 =?utf-8?B?bWp3YTdjOXhOVlNLUER5emFLMW9VM2d6V3MrenJtSWJYVHQ1SGpVdFZKMW1M?=
 =?utf-8?B?YllxUkVvYXVpYVB4WHg2bk5FUnhEcFU4ZlFIWTVDQmNSd3liN2E5eXcrZkxO?=
 =?utf-8?B?K3o3UVpPSlh6MEFrOGNLazZ2bExRd25kNFQ3QTdXRVVtMEk3WXJkbGNRR011?=
 =?utf-8?B?NzBkSTVNVTRqM3A2ZHA2R1ZmMU5YVUQ0dHUzNE5BVU01QUpIZjdRME1jdU9a?=
 =?utf-8?B?TWlIdlZDN01TM0h2THZtTDZ3Ni9YN2RyeWlCNS9qT2twQ3R6VHRYTDd5OGNx?=
 =?utf-8?B?UnZUT0NtcmxGeDZZTThtREhLdDVpRytWbFRMTkpqN2g0Q0ttRzk0WTU4R1A2?=
 =?utf-8?B?U21zZ0hwdEZZd2N0dUUyZHJJSjMzS1VHMFlldHZvWSttMURYTjYxQTRTbzVG?=
 =?utf-8?B?eVBacmljSnlIL2ZqZUl1WlFxL1Q1bm1ZTDV3a3crZVE4djZxOHlXVHMwanM1?=
 =?utf-8?B?Qklva2xXYUYyRUVjL2Q1RndWY1MzQWt6NUUybWNuYlBWdUZhemJnZlU4SDhy?=
 =?utf-8?B?WTE5b0didnVjR3d5RDFrWHZkcFNVK1gvUWF0UENwVE1qYmM2YitXQzVlMXRF?=
 =?utf-8?B?SGlqZGNQRy9XZWVQU0FQc1FWdGlnY2pPM3YwWi93S0JRcUt0M0VkQ3EvQ0pu?=
 =?utf-8?B?U2RlOTRDV3p0V3BaOU1MeXZpOVZsbnVGZ1ZZZDhlWHYyT0FONGFRYmJ2ZW5Z?=
 =?utf-8?B?NGFBT2Z0eExydEJubnZIb0N3UlBEdC92anFpdDZLYldHZStqRkRwUkN6SVA5?=
 =?utf-8?B?eG1OS2I0cVhkaSsxLzUzOGxxN01xT2tMaHN1dS80MGNRdG8yQnh2dWxlT3oz?=
 =?utf-8?B?cFlVenl5bmJDbnBNQkdScGppWnk2ck56RTAxYUl5QmRGY0lKRlcvZDVva3FX?=
 =?utf-8?B?NFdrZ0FvZ0dieTZobnNMZlRqamxvU2srT0lRTmJZaTdmTmJDZ3loZFV0V3U4?=
 =?utf-8?B?QXJ1cWFBVlBJZDZaaHRVQVAzVk5BQ2YzTHFVK1ZCWFEwMDNaNVg5SUFZQWpL?=
 =?utf-8?B?ZStXMjFZT2RTNndoR2g3MVBpRHYzeTczMW5HTVdLL0p5T3dVSUJtZ2VieVRv?=
 =?utf-8?B?N3JYWHNuV2VpZ1dCdy9ma1cyUVl6OTZYN0VuSG1jSWpsWUVJWUZEYmRUckJl?=
 =?utf-8?B?emN4aDM1TW9pa05ldjI1MkU3QjFBRDU1ZFBXR2tEYVJ4UkJKNkxJazEza3lO?=
 =?utf-8?B?TWVKNUtiUmNjdDg4dnByUkEwdkZFNkdEUUFPTFMxZ1VCVHc1QzE1MDlhbmNn?=
 =?utf-8?B?Mk5hZkppYUJIVUordE1EY0VTM2FMTUdkaXZMYmFERFhnRy9zMUlVZmM4VDRO?=
 =?utf-8?B?cUZmdTlISHZOa3ZvMW9BYXBmaEUrLzBvNVpLZzkyenN5b2V2UklZaTlsSm9o?=
 =?utf-8?B?clE1ZVJ4UkVJRGxLZlBnUGMxOTJpWEFYTTdNVFhLeCtRekk1VlRnNzE2SDBs?=
 =?utf-8?B?UlVybXFra2VtK2RiekdMd3NUMFR0NUJ4Uy8rcUtzbzJ2UW5ld21JaVZUR2ZB?=
 =?utf-8?B?REVLZHA0dGlVVWg4RHJzVlIrMGZDbUtFQ0xaMkx6WVU5eEZWN3cvQXNEaU1t?=
 =?utf-8?B?dG12THJrUjY1dGp3UUo0YXB4OER4ZnQ5bGxuUFhRY3JlcjdMd24ydkh5YkVR?=
 =?utf-8?Q?35+1mQAJQ1X7cmjNg2qsKftuaAcdQ0=3D?=
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:64aa7808-outbound-1.mta.getcheckrecipient.com;CAT:NONE;SFS:(13230040)(1800799024)(35042699022)(14060799003)(36860700013)(82310400026)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2025 13:49:35.6300
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: b2a904a3-020c-4b0a-23b0-08dd3ed96f85
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:
	DU2PEPF00028D0F.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR08MB8292

SGkgTWljaGFsLA0KDQo+IE9uIDI3IEphbiAyMDI1LCBhdCAxMDo0NSwgTWljaGFsIE9yemVsIDxt
aWNoYWwub3J6ZWxAYW1kLmNvbT4gd3JvdGU6DQo+IA0KPiBPbiBBcm0zMiwgd2hlbiBDT05GSUdf
UEhZU19BRERSX1RfMzIgaXMgc2V0LCBhIGJ1aWxkIGZhaWx1cmUgaXMgb2JzZXJ2ZWQ6DQo+IGNv
bW1vbi9kZXZpY2UtdHJlZS9ib290ZmR0LmM6IEluIGZ1bmN0aW9uICdidWlsZF9hc3NlcnRpb25z
JzoNCj4gLi9pbmNsdWRlL3hlbi9tYWNyb3MuaDo0NzozMTogZXJyb3I6IHN0YXRpYyBhc3NlcnRp
b24gZmFpbGVkOiAiIShhbGlnbm9mKHN0cnVjdCBtZW1iYW5rcykgIT0gOCkiDQo+ICAgNDcgfCAj
ZGVmaW5lIEJVSUxEX0JVR19PTihjb25kKSAoeyBfU3RhdGljX2Fzc2VydCghKGNvbmQpLCAiISgi
ICNjb25kICIpIik7IH0pDQo+ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBe
fn5+fn5+fn5+fn5+fg0KPiBjb21tb24vZGV2aWNlLXRyZWUvYm9vdGZkdC5jOjMxOjU6IG5vdGU6
IGluIGV4cGFuc2lvbiBvZiBtYWNybyAnQlVJTERfQlVHX09OJw0KPiAgIDMxIHwgICAgIEJVSUxE
X0JVR19PTihhbGlnbm9mKHN0cnVjdCBtZW1iYW5rcykgIT0gOCk7DQo+IA0KPiBXaGVuIENPTkZJ
R19QSFlTX0FERFJfVF8zMiBpcyBzZXQsIHBhZGRyX3QgaXMgZGVmaW5lZCBhcyB1bnNpZ25lZCBs
b25nLA0KPiB0aGVyZWZvcmUgdGhlIHN0cnVjdCBtZW1iYW5rcyBhbGlnbm1lbnQgaXMgNEIuIEZp
eCBpdC4NCj4gDQo+IEZpeGVzOiAyMjA5YzFlMzViNDcgKCJ4ZW4vYXJtOiBJbnRyb2R1Y2UgYSBn
ZW5lcmljIHdheSB0byBhY2Nlc3MgbWVtb3J5IGJhbmsgc3RydWN0dXJlcyIpDQo+IFNpZ25lZC1v
ZmYtYnk6IE1pY2hhbCBPcnplbCA8bWljaGFsLm9yemVsQGFtZC5jb20+DQo+IC0tLQ0KDQoNCkFw
YXJ0IGZyb20gSnVsaWVu4oCZcyBjb21tZW50cyBmb3Igd2hpY2ggSeKAmWxsIGxlYXZlIHlvdSBi
b3RoIHRvIGFncmVlIG9uIGEgc29sdXRpb24sIEnigJl2ZSByZXByb2R1Y2VkDQp0aGUgaXNzdWUg
YW5kIHRlc3RlZCB0aGF0IHlvdXIgY2hhbmdlIGlzIGZpeGluZyBpdCBhbmQgaXTigJlzIG5vdCBi
cmVha2luZyBhIGRpZmZlcmVudCBzZXR1cCAoZS5nLiA2NCBiaXQpLg0KDQpSZXZpZXdlZC1ieTog
THVjYSBGYW5jZWxsdSA8bHVjYS5mYW5jZWxsdUBhcm0uY29tPg0KVGVzdGVkLWJ5OiBMdWNhIEZh
bmNlbGx1IDxsdWNhLmZhbmNlbGx1QGFybS5jb20+DQoNCg==


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 13:50:04 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 13:50:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877912.1288085 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcPV6-00009I-3I; Mon, 27 Jan 2025 13:50:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877912.1288085; Mon, 27 Jan 2025 13:50:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcPV5-00008o-VE; Mon, 27 Jan 2025 13:50:03 +0000
Received: by outflank-mailman (input) for mailman id 877912;
 Mon, 27 Jan 2025 13:50:02 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=p0Up=UT=kernel.org=joel.granados@srs-se1.protection.inumbo.net>)
 id 1tcPV4-0007x9-KB
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 13:50:02 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org
 [2604:1380:45d1:ec00::3])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9a7283d8-dcb5-11ef-a0e6-8be0dac302b0;
 Mon, 27 Jan 2025 14:50:01 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 554B0A4154E;
 Mon, 27 Jan 2025 13:48:13 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 881ACC4CED2;
 Mon, 27 Jan 2025 13:49:59 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9a7283d8-dcb5-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1737985800;
	bh=laZX1iWKmTFe6EBXe6dQ6V5dBHky9feUPubV8bbHYy0=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=ITreSYYkYqJo0yzT/NmeCNaU8ylN9fF82uixbVQhbAMNhn/x1ksvsdeN2BZIjx7Av
	 6jRzLOfnz1KOiZ8BN/+a6yzSKjX86nOzP6ewnKK12LbyYoLRgr6MitIVZMs+Q9nRjt
	 1O56sOuQWf9/oW9JBeL1K1Ep9SPnbGRY0gAqf1BfWdrmsV6P6rbrAzrEzJaWATIpCg
	 PxgyGHOSh+1Dp+na/sGNdWcGsgzNCRs4/nnMHS16Kt8UOkwJO9cYsDiIOKruHAZkDs
	 tuJVwo0MPlNeiRHuQkLVgJEWRQ8mSboCfx8PwGZonQ0+bdJkEjI8BLPDWS5oZchNDY
	 iBi9Q4ViZ4cfA==
Date: Mon, 27 Jan 2025 14:49:55 +0100
From: Joel Granados <joel.granados@kernel.org>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>, 
	Thomas =?utf-8?Q?Wei=C3=9Fschuh?= <linux@weissschuh.net>, Kees Cook <kees@kernel.org>, 
	Luis Chamberlain <mcgrof@kernel.org>, linux-arm-kernel@lists.infradead.org, 
	linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, 
	linux-s390@vger.kernel.org, linux-crypto@vger.kernel.org, 
	openipmi-developer@lists.sourceforge.net, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, 
	intel-xe@lists.freedesktop.org, linux-hyperv@vger.kernel.org, linux-rdma@vger.kernel.org, 
	linux-raid@vger.kernel.org, linux-scsi@vger.kernel.org, linux-serial@vger.kernel.org, 
	xen-devel@lists.xenproject.org, linux-aio@kvack.org, linux-fsdevel@vger.kernel.org, 
	netfs@lists.linux.dev, codalist@coda.cs.cmu.edu, linux-mm@kvack.org, 
	linux-nfs@vger.kernel.org, ocfs2-devel@lists.linux.dev, fsverity@lists.linux.dev, 
	linux-xfs@vger.kernel.org, io-uring@vger.kernel.org, bpf@vger.kernel.org, 
	kexec@lists.infradead.org, linux-trace-kernel@vger.kernel.org, 
	linux-hardening@vger.kernel.org, apparmor@lists.ubuntu.com, linux-security-module@vger.kernel.org, 
	keyrings@vger.kernel.org, Song Liu <song@kernel.org>, 
	"Steven Rostedt (Google)" <rostedt@goodmis.org>, "Martin K. Petersen" <martin.petersen@oracle.com>, 
	"Darrick J. Wong" <djwong@kernel.org>, Jani Nikula <jani.nikula@intel.com>, 
	Corey Minyard <cminyard@mvista.com>
Subject: Re: Re: Re: [PATCH v2] treewide: const qualify ctl_tables where
 applicable
Message-ID: <f4lfo2fb7ajogucsvisfd5sg2avykavmkizr6ycsllcrco4mo3@qt2zx4zp57zh>
References: <20250110-jag-ctl_table_const-v2-1-0000e1663144@kernel.org>
 <Z4+jwDBrZNRgu85S@li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com>
 <nslqrapp4v3rknjgtfk4cg64ha7rewrrg24aslo2e5jmxfwce5@t4chrpuk632k>
 <CAMj1kXEZPe8zk7s67SADK9wVH3cfBup-sAZSC6_pJyng9QT7aw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAMj1kXEZPe8zk7s67SADK9wVH3cfBup-sAZSC6_pJyng9QT7aw@mail.gmail.com>

On Wed, Jan 22, 2025 at 01:41:35PM +0100, Ard Biesheuvel wrote:
> On Wed, 22 Jan 2025 at 13:25, Joel Granados <joel.granados@kernel.org> wrote:
> >
> > On Tue, Jan 21, 2025 at 02:40:16PM +0100, Alexander Gordeev wrote:
> > > On Fri, Jan 10, 2025 at 03:16:08PM +0100, Joel Granados wrote:
> > >
> > > Hi Joel,
> > >
> > > > Add the const qualifier to all the ctl_tables in the tree except for
> > > > watchdog_hardlockup_sysctl, memory_allocation_profiling_sysctls,
> > > > loadpin_sysctl_table and the ones calling register_net_sysctl (./net,
> > > > drivers/inifiniband dirs). These are special cases as they use a
> > > > registration function with a non-const qualified ctl_table argument or
> > > > modify the arrays before passing them on to the registration function.
> > > >
> > > > Constifying ctl_table structs will prevent the modification of
> > > > proc_handler function pointers as the arrays would reside in .rodata.
> > > > This is made possible after commit 78eb4ea25cd5 ("sysctl: treewide:
> > > > constify the ctl_table argument of proc_handlers") constified all the
> > > > proc_handlers.
> > >
> > > I could identify at least these occurences in s390 code as well:
> > Hey Alexander
> >
> > Thx for bringing these to my attention. I had completely missed them as
> > the spatch only deals with ctl_tables outside functions.
> >
> > Short answer:
> > These should not be included in the current patch because they are a
> > different pattern from how sysctl tables are usually used. So I will not
> > include them.
> >
> > With that said, I think it might be interesting to look closer at them
> > as they seem to be complicating the proc_handler (I have to look at them
> > closer).
> >
> > I see that they are defining a ctl_table struct within the functions and
> > just using the data (from the incoming ctl_table) to forward things down
> > to proc_do{u,}intvec_* functions. This is very odd and I have only seen
> > it done in order to change the incoming ctl_table (which is not what is
> > being done here).
> >
> > I will take a closer look after the merge window and circle back with
> > more info. Might take me a while as I'm not very familiar with s390
> > code; any additional information on why those are being used inside the
> > functions would be helpfull.
> >
> 
> Using const data on the stack is not as useful, because the stack is
> always mapped writable.
> 
> Global data structures marked 'const' will be moved into an ELF
> section that is typically mapped read-only in its entirely, and so the
> data cannot be modified by writing to it directly. No such protection
> is possible for the stack, and so the constness there is only enforced
> at compile time.
I completely agree with you. No reason to use const within those
functions. But why define those ctl_tables in function to begin with.
Can't you just use the ones that are defined outside the functions?

Best


-- 

Joel Granados


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 13:51:54 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 13:51:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877928.1288096 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcPWr-000252-Eo; Mon, 27 Jan 2025 13:51:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877928.1288096; Mon, 27 Jan 2025 13:51:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcPWr-00024u-9K; Mon, 27 Jan 2025 13:51:53 +0000
Received: by outflank-mailman (input) for mailman id 877928;
 Mon, 27 Jan 2025 13:51: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
 <SRS0=K0bb=UT=arm.com=Luca.Fancellu@srs-se1.protection.inumbo.net>)
 id 1tcPWq-00024k-3g
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 13:51:52 +0000
Received: from EUR03-AM7-obe.outbound.protection.outlook.com
 (mail-am7eur03on20616.outbound.protection.outlook.com
 [2a01:111:f403:260e::616])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id dbe7252f-dcb5-11ef-a0e6-8be0dac302b0;
 Mon, 27 Jan 2025 14:51:51 +0100 (CET)
Received: from DUZPR01CA0085.eurprd01.prod.exchangelabs.com
 (2603:10a6:10:46a::17) by PAVPR08MB8967.eurprd08.prod.outlook.com
 (2603:10a6:102:326::5) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.20; Mon, 27 Jan
 2025 13:51:48 +0000
Received: from DB1PEPF000509F0.eurprd03.prod.outlook.com
 (2603:10a6:10:46a:cafe::bc) by DUZPR01CA0085.outlook.office365.com
 (2603:10a6:10:46a::17) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8377.22 via Frontend Transport; Mon,
 27 Jan 2025 13:51:52 +0000
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 DB1PEPF000509F0.mail.protection.outlook.com (10.167.242.74) with
 Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8398.14
 via Frontend Transport; Mon, 27 Jan 2025 13:51:47 +0000
Received: ("Tessian outbound ad34cb01f105:v554");
 Mon, 27 Jan 2025 13:51:47 +0000
Received: from L882fb65b4a27.2
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 4A91ABE5-8FDC-4F85-93E4-C07970692D85.1; 
 Mon, 27 Jan 2025 13:51:37 +0000
Received: from OSPPR02CU001.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id
 L882fb65b4a27.2 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Mon, 27 Jan 2025 13:51:37 +0000
Received: from DBAPR08MB5798.eurprd08.prod.outlook.com (2603:10a6:10:1a6::21)
 by AM0PR08MB5299.eurprd08.prod.outlook.com (2603:10a6:208:18d::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.22; Mon, 27 Jan
 2025 13:51:34 +0000
Received: from DBAPR08MB5798.eurprd08.prod.outlook.com
 ([fe80::4a66:d3e2:570:9632]) by DBAPR08MB5798.eurprd08.prod.outlook.com
 ([fe80::4a66:d3e2:570:9632%4]) with mapi id 15.20.8377.021; Mon, 27 Jan 2025
 13:51:34 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: dbe7252f-dcb5-11ef-a0e6-8be0dac302b0
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=nPFWPmGyq8HXOqDqr13xvYWCPwoHXiUqWTkmJX0ZVO2a2wzURBik6M8+s8bGtYxRUOJEODiyEjBEyqu6M/0thvjK5PapknOkQgLPYYyBi238dqdKTrkojw75Jy1Q0L0FFmjcNW+BecrUCMFlN9hvQOrZDrdvlDov7F7Biawk7j4XFW6+9MnSiAYB83eU6C+ZmzbeZS8K3u5yTCLdYPxEhTR9p2W8O+tmLb7faRGoYZxm0R6SnRHPY+P2wnPTlyFHYZJODDB5gVgvk1LiJXjjnH6CSJcsFgdU7F+6aX3go66vtvgSEdD3ovyhP3vx1IsOheFBT2EJiF01ymsqTn2jrg==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=w0UngerHxIiVcYKEVBGoiv30EvIV7W3EgfyQ0zkoTZY=;
 b=McxXq6Xcg732FHY17gDH0eyKhjPznI+Nef6YPRzUhGAvQ+JVvJGmBAFxCl/pyloPQ/o8Lppr9TpjR6smGkOJ5NCk3+g5d1zSnR1Y2Ur8DS1dV73h+V7KFqgvyzRIEZkKKe7nGm32GVycFMktUYGIzr0X1XzvlyxTVODS4d+ETQdCQ4DHQC3MiGS+lgoft8zV3qx4wbx3wZQAx6dfHYZfatxvvkB4Yh/I9JYPjUWOTbx5KKl8ZuDVzJTBHMPrVpKZuOkrdknss7B7qrXdQeP9yunBdXXJwhw4pnAbabHDuNyril6R/q+nMaPTe+vViGaSlpnBS/DuO6a7MiCt9JPIIA==
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=arm.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=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=w0UngerHxIiVcYKEVBGoiv30EvIV7W3EgfyQ0zkoTZY=;
 b=IE83fCnild9CWuHJ4uTeyhv2K03BRbs9krNcgTh4KThI1fRKsf6qGe9t98CbXX/h1mOJHIiF1IKG0PwnoJgzVJ4L3ymN5y/aMF9w1T36Jjg00oeEIxdkZAMObU5y9AXNmpugo9Mpa7WheC3LXC0Q+ou1dASXT3UYA7kfauCzivc=
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=arm.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: ef338ff48d46c1a6
X-TessianGatewayMetadata: kenzaENbonGJSaR91deSg6slZv1wsqijL7KvRFxWCqrP4l9AS4Bt2n9mGDZjxXLiYx3l8uJzmU1QUlYCBJAJuI4zlwn2+vxbs1nj4o+1lzamGxlTJqfA+pZOvh+ftO1sZA3cPhhICl0M5IIYyWdR2vIIxVWY48v4/U7cF1IaViI=
X-CR-MTA-TID: 64aa7808
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=FTENZ8D3VQOkXoOQfVHy3lgHP4hglD+bHbXZVhTrTjhdr0w3Gw1TsYvsuLUv6oBfjFwtfW3MfJPiNv9Ic59nqJOjDEyoUD1zokgihD0R2NEwxOqppZLbtA55FjGuf/G8yA4ufgwyeMXjIGYbbXb7FXjHougB9CodqTrsUUuS9+7ljNbZDajRq7uvSsjVdvnkZSWXe1+3UW5/h7Sj7zY3iavXenVrgFK4CW6V0rlGPydXtzf1JaCnNwETHFF+YeQhWD9ASIPQAb+y4RCTv2HCugd3+fs/Z30Rif+o5M3kdzJ0LRuuJ45fH7mHJFghRNEACvxNFi/3I/hxTYsn073uKw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=w0UngerHxIiVcYKEVBGoiv30EvIV7W3EgfyQ0zkoTZY=;
 b=bh2h5VTQrR/DtY4ooqgx4mFC6dCUgO4o52ZNWTSmZAKaEyCbbEMnRmsrpPZvCD+mFnyJWVGQ5UMGWSDHvdqaqo1IVDR19cNoMexUKUZNmCXiwiC1XsygVRPED+buxBvt6Z0K9LlKG6zQhXuj4HPJhFcpX6dh0bW7I3bKfPR4RlUEJ+ZACmwqdKuUpFcI0yLh3acJq6rY+NI0fnKt4pM/ff314qr97xOAw3LwXxxLzyZyyeo0EaYi+Ts1QUflAxFjyKRofNp8JuGc++8V7GNeMk++Bhu/UMnwKoOHxRRvx9swP6QMrWrS04qttqJpazcKh9+yOiFMqrPPIHRDldojog==
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=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=w0UngerHxIiVcYKEVBGoiv30EvIV7W3EgfyQ0zkoTZY=;
 b=IE83fCnild9CWuHJ4uTeyhv2K03BRbs9krNcgTh4KThI1fRKsf6qGe9t98CbXX/h1mOJHIiF1IKG0PwnoJgzVJ4L3ymN5y/aMF9w1T36Jjg00oeEIxdkZAMObU5y9AXNmpugo9Mpa7WheC3LXC0Q+ou1dASXT3UYA7kfauCzivc=
From: Luca Fancellu <Luca.Fancellu@arm.com>
To: Michal Orzel <michal.orzel@amd.com>
CC: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Stefano
 Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand
 Marquis <Bertrand.Marquis@arm.com>, Volodymyr Babchuk
	<Volodymyr_Babchuk@epam.com>, "oleksii.kurochko@gmail.com"
	<oleksii.kurochko@gmail.com>
Subject: Re: [for-4.20][PATCH 2/2] xen/arm: Fix build issue when
 CONFIG_PHYS_ADDR_T_32=y
Thread-Topic: [for-4.20][PATCH 2/2] xen/arm: Fix build issue when
 CONFIG_PHYS_ADDR_T_32=y
Thread-Index: AQHbcKi5BZvZjkd9yUSyaUeahkEn8LMqo7IA
Date: Mon, 27 Jan 2025 13:51:34 +0000
Message-ID: <E2EF4E08-8D6D-4F43-99D1-BDAE3FB76CF4@arm.com>
References: <20250127104556.175641-1-michal.orzel@amd.com>
 <20250127104556.175641-3-michal.orzel@amd.com>
In-Reply-To: <20250127104556.175641-3-michal.orzel@amd.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.300.87.4.3)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DBAPR08MB5798:EE_|AM0PR08MB5299:EE_|DB1PEPF000509F0:EE_|PAVPR08MB8967:EE_
X-MS-Office365-Filtering-Correlation-Id: 2bd62256-320a-4c67-6b82-08dd3ed9be68
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|1800799024|366016|376014|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?utf-8?B?ZEZrNGxUS3lhL0drbTJHSVYwbGVFSXNDTjB1T2tKdndGYVYxNXhyMHZJUFY4?=
 =?utf-8?B?bW9ZT1FyeFRMUjhkWXlMMlNNQVdSNlE5QW5WUUtneC9ZZDA2Y3J6Yk4rR2lS?=
 =?utf-8?B?b1AxRGFKaFZqWUZlMWNjTTRBZVE3VDBXV3R5RmNhazQvQjVoNTRtMS9Rc1pC?=
 =?utf-8?B?MHJlQ3lQSlFwbGlEdXF0eUZEVjhKYU56anNabC9UbDA0OUV6ZkJFa3RYcitz?=
 =?utf-8?B?bVlCTUhyb09FblBBVUw1eS9qODJLVDM4bFpzenRRY1ZtVDVPcTZPSXFudTdW?=
 =?utf-8?B?WWhrUnkraFRlcjdMYkVjc3Z5aXc2OWRJU09XRlJDaG1MMFErcE14RDA5QkxT?=
 =?utf-8?B?MTFpUTJsQmhITXpVZThPWEtTNWNCbU8vTTVhamJrUkxjUi9iM2VXUE52dkc1?=
 =?utf-8?B?cWExVTg4MnVJbEtvVWhHNlpKTU5PdCtqbWQ5dXZuU3Q4cGF5VlpGY2FqdmVK?=
 =?utf-8?B?S0hXZDIxeW5KeUlDS05TdHZ5R2ljOWxRMWYzd3owTG5nNWVVMHdmNU5xYTdV?=
 =?utf-8?B?VlhGUnM4dHp6aWZERkFIUmJmVjVFWkFSUmJGVGZIRUxzUGdMcW01WmErQ3Q2?=
 =?utf-8?B?Mi9Mdm91VUZEa2loVnR3OUJ2d1REeWFBc1lnWEtSV3JYVGF3UUhKc2lpUFE5?=
 =?utf-8?B?c3o4NWFYSDQrYkJ4eWRDaFJ0WVV6dmZ5RGh0Vkp2c1pabEhSZUxlb1FkN0VY?=
 =?utf-8?B?bVI0SWprVkVvcjk5NVJuczhOZGJwRHlEY3NvZzYreUM1TjNXSTV4bjVGRldn?=
 =?utf-8?B?S3JMdm0yTWpCWVMvMjRXaDZlenR6QnBWdXN5aVVocnVmVHdSM2I2MTdEOXRJ?=
 =?utf-8?B?OUd2dnRvb0xSNEtzMmdvdWRWZXppWDcvMHpPMU1GYi9BS0VIWFl1cmgxdFEx?=
 =?utf-8?B?eFpIcWFXQjNNWjYza2tlZXJYMXZKbFozaVNZWVloc3V4bm5iYUhGcC9SOU92?=
 =?utf-8?B?bC9GdW8rd2h0U3FxR0l5SmtvNXphbEN2REJxT2diM25NbnlnTlhLYnVPZGtS?=
 =?utf-8?B?dmFWY05JN0gzUzgweGpNcExrU1p4OTQwMDIvbnpxQTFmMzNzekMyTzdpUC82?=
 =?utf-8?B?ZDBqVVlTSnBmVUVucnM2c1prZjJRVUpRUCtESDFDQ1Fuci8vSUlLanc0TTZt?=
 =?utf-8?B?TjA3S0ppRmcxYWtHd2dwdnNwN3dWZEY4UXNiR0xtaVovRDh6OUlQc3pSRWhz?=
 =?utf-8?B?bEpNNXlDNnVMSTFYUlVrMlhUM2FnUVRETzlQWEt6MnRhQnBoR2hUWE9LTG9s?=
 =?utf-8?B?NkpCQkhwWkdZTmxzeDJGMEQ1YUt3WE1pWWpoWVpmUk1URWs5Ni9aSXB5R2ky?=
 =?utf-8?B?bkl2OGVEdDVuOFVjYXJHNFlWdmxKZS96dzZzWkd2OHVhMVNEOFJvbkovOHNt?=
 =?utf-8?B?REJOUFdaSld6Mkw5NTMrWDBEUEdpekxTYnc2cFRZT3VweWZYL2t5NDQ3Sktj?=
 =?utf-8?B?NExmbHNZc1FHWG5TSkhNdXJoUi9jMTUyZkN0NkQ3MEtzNHF1SStwVFlnRkdL?=
 =?utf-8?B?cXVoS1k1Y0xTREpzT0RpeEFpQkVWaTdXWTQ5U3VjSm5CdzdsTEJwTmRXc0Y1?=
 =?utf-8?B?OEh6M3ZYVkpRZlZ6bVZqeDU4a1dWamdjNGhsMTBTcjZPWlBFYWtGdmNJV3pw?=
 =?utf-8?B?UUhGUjVSRSt2ekx1Y3RFdDBQS2ZGdDdjRVRkOGxwZ1NIZWZkS20vZjJXK2cx?=
 =?utf-8?B?Q081U21uVFVuK044VWFMczRWQkxsRUhlTGdHL3BZVUJRL09CV1ZmdUg5eFNL?=
 =?utf-8?B?QlNiNE90a0RyU0lxZEFPbzE3SFI0cFdRbVYzM2lEKzJlYVU5VzVoU2RrbzRU?=
 =?utf-8?B?Nm94RHJmU3NTaHFqd1c5bGRWNmkwZDZHOFVSVTJPWXBxN200NVhrOXpGcXhz?=
 =?utf-8?B?RDd3ZlFXYWJjQzFadVNzditIK2dmcWpxbFU4Q1dMWTdsVEhhNDNEeCs1UnF2?=
 =?utf-8?Q?sYvHp7jJ24m27DJ+DUkO+tM0kOeO6+wX?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DBAPR08MB5798.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="utf-8"
Content-ID: <AE8EA91EB689F545A7BE70A2DB3030E1@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB5299
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-SkipListedInternetSender:
 ip=[2603:10a6:10:1a6::21];domain=DBAPR08MB5798.eurprd08.prod.outlook.com
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DB1PEPF000509F0.eurprd03.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	906bf5c9-9495-4720-8201-08dd3ed9b692
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|35042699022|1800799024|14060799003|376014|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?MXAwSlFSNXRoNk0yM05tNCtiUDdDazBjOGVkTytaZ2hvTmR0V0RvbXlXVi9W?=
 =?utf-8?B?Qksxamh0UkRvQ09SQzFkNDM4cUJvTTJ0VlBMU3BpUkgrMEF2TnArdmNROWNB?=
 =?utf-8?B?WWxTM2xyK2dKMFJic1NJMndUTk1xanN0WE5hTld3QTg4TTd4RElzdFUvMHFH?=
 =?utf-8?B?dkVITU9DWG9zRWVnTG1GRXNWcHl1ZytwYTR4QzlPaGpETjh1U0RUN3d2RDFi?=
 =?utf-8?B?akFKTmxTRnU3ZDFvQnNIaVhPLzdCTVU1NFZjblFrK2VmL1RBQWtGS1MrdVJp?=
 =?utf-8?B?dEhwa0FKMDRZZ3hKSWZzYWtIcGQxcnYrbEhqSUxoLzFZU2dlbkhsWGt3SG8w?=
 =?utf-8?B?c0RBYllwV0draGl2WXZXd2VBV244VEF6c3B2cnhBYWVuSlBmai9vS0d5UHVj?=
 =?utf-8?B?b0ZEWWlPMSs5UTFoNEs5d1lLeXNXaWd1RnE2U3N4a3lVaUgzVjhuQUhJMEEr?=
 =?utf-8?B?V2NzWFdoeHUxTi9rUDlHWWVKR2JhM3pQOWgzUGVqSnVXOW9FL3YzRXM2RnhO?=
 =?utf-8?B?TUlRcDRFSWk5bjVDVGpNRFkyMXJPQzE3TXBRVU5ucUMrY2tGbFM5UUl4aE42?=
 =?utf-8?B?Wkc2MGtTTlNWV0NFNUM4ODZEQlBJTjl3YWlsc3NWL0R4S0lpU3RNa2JHR3ZP?=
 =?utf-8?B?Rmkrb0VQekVyNG1UWWlINUwxRERveG5ZM1g4V01odzZTVUplTjl5b0VwZGVT?=
 =?utf-8?B?NXJzWi9VVkV2R25HZUMyUllxR2MxanhXcm1DcGh3RjVrc3QyNXlMQ3h4N1Z2?=
 =?utf-8?B?RW1ORHBIL0ppMzhBblJYRmplQ1ZMb3ZjMnNHc3plM2RuTWJsQ2dYcjlaTDFI?=
 =?utf-8?B?NnFUS0xEdWVPelJrakdGc1pOTjlCajJwak5xcW5zSXplZkR3OEU1TnVpTmNS?=
 =?utf-8?B?WnFtTS9FZmI5N1hXZ2NncG5UUXVLUnh5bzJySzlEWDM2aloyeW9IdUFhc0dw?=
 =?utf-8?B?ak1lYXg1ZFJDcm13azBWdmh6MmVEdjhySnBsMXJGUG96MkRZNU9aaHliTlNV?=
 =?utf-8?B?RzhxZG5mZkhCeXo0WXhoc0pCcm4ydzBOeGJISFhRdVRXR2ZPYkM5bUJlNWx4?=
 =?utf-8?B?QWlxbHpUSDMrVzJqbDhoN2VXUnhuTVkvMWVQbW1BY2p1WEdRUnE0bHpKT1N1?=
 =?utf-8?B?czZGMXc5UVFnMUhxQWFKVExOK0YwRUszSktpQUlpSEVvSGh3Sjk3K0ZpU2ZH?=
 =?utf-8?B?QWFEdXJvZS8vaEYvak15N0NVMDlKZmExVUYrZFFqZFpNOGkvMHBWWmYrMkR4?=
 =?utf-8?B?SWx6VzM5amlnYytGR2J5UzlYOHZKcDMyVmRUcWR4aEhOMVN2U0QwWHl5cTlH?=
 =?utf-8?B?aUdxazFxM2dmUDdhV2k5bWN2LzkxK0dMQm94MHFtVklkRURNRHFPS2xFM2V3?=
 =?utf-8?B?cm9XMEFHaWtEaktFYWI5dlFMZENMNVVzdXpxanlDdDcxcEQxbEcwaFNRMVVQ?=
 =?utf-8?B?SjdUNys2Mis2RS84ZkZhTFl1dCtkNGE2NnhPL2puYklpK1M3QjVkblllenRQ?=
 =?utf-8?B?c1lKMEF2QWVOMmV3NGVLLzBuTjBpSjNsMVhLYVN4cXhwaFRYdHo0TkhYWTZE?=
 =?utf-8?B?LzlCMW1oa25TVW1USFJidTRPSlRISW5XeWpPcVBwczQ0ZEw4MXZxQXdvRy9X?=
 =?utf-8?B?bzhPOWRHeXpYcHNVclV0UmNHdWF4Ym52UVBKakx0QXpkYmhiaytNZ25zb3BI?=
 =?utf-8?B?SmJiZkRJTU5xakhycWVrRlFpc2FsWlRwZVFYTGg5c3ArQVovOFViZlVieUhJ?=
 =?utf-8?B?YjFDcWxOd2RiYllWTC9abGFyMWJiVFZzRkZXd1BBQk1BWjQ1NWtUU1lXamRr?=
 =?utf-8?B?SDZBbkFqU1JpaU1YclIvbGpZK2tUL2FDRVNXajU1L2EwMEZHdzVGTm5tZDJq?=
 =?utf-8?B?MlB1WVNFOWZ6YktKcGNpVERPbFZlMkY3dkdtNDhzR0owbWQvNGtpajU0b1E4?=
 =?utf-8?B?enlseVgxT1JDNkhYNnhCeWg2Qm44ZURhaDR2ckxGVDE1QWxxMUZBOERTbjJ4?=
 =?utf-8?Q?jd8VuLPFBeUZP0fdCzH/Bqld1bZ39Q=3D?=
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:64aa7808-outbound-1.mta.getcheckrecipient.com;CAT:NONE;SFS:(13230040)(82310400026)(35042699022)(1800799024)(14060799003)(376014)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2025 13:51:47.9818
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 2bd62256-320a-4c67-6b82-08dd3ed9be68
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:
	DB1PEPF000509F0.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR08MB8967

SGkgTWljaGFsLA0KDQo+IE9uIDI3IEphbiAyMDI1LCBhdCAxMDo0NSwgTWljaGFsIE9yemVsIDxt
aWNoYWwub3J6ZWxAYW1kLmNvbT4gd3JvdGU6DQo+IA0KPiBPbiBBcm0zMiwgd2hlbiBDT05GSUdf
UEhZU19BRERSX1RfMzIgaXMgc2V0LCBhIGJ1aWxkIGZhaWx1cmUgaXMgb2JzZXJ2ZWQ6DQo+IGFy
Y2gvYXJtL3BsYXRmb3Jtcy92ZXhwcmVzcy5jOiBJbiBmdW5jdGlvbiAndmV4cHJlc3Nfc21wX2lu
aXQnOg0KPiBhcmNoL2FybS9wbGF0Zm9ybXMvdmV4cHJlc3MuYzoxMDI6MTI6IGVycm9yOiBmb3Jt
YXQgJyVseCcgZXhwZWN0cyBhcmd1bWVudCBvZiB0eXBlICdsb25nIHVuc2lnbmVkIGludCcsIGJ1
dCBhcmd1bWVudCAyIGhhcyB0eXBlICdsb25nIGxvbmcgdW5zaWduZWQgaW50JyBbLVdlcnJvcj1m
b3JtYXQ9XQ0KPiAgMTAyIHwgICAgIHByaW50aygiU2V0IFNZU19GTEFHUyB0byAlIlBSSXBhZGRy
IiAoJXApXG4iLA0KPiANCj4gV2hlbiBDT05GSUdfUEhZU19BRERSX1RfMzIgaXMgc2V0LCBwYWRk
cl90IGlzIGRlZmluZWQgYXMgdW5zaWduZWQgbG9uZy4NCj4gQ29tbWl0IDk2ZjM1ZGU2OWU1OSBk
cm9wcGVkIF9fdmlydF90b19tYWRkcigpIHdoaWNoIHVzZWQgcGFkZHJfdCBhcyBhDQo+IHJldHVy
biB0eXBlLiBXaXRob3V0IGEgY2FzdCwgdGhlIGV4cHJlc3Npb24gdHlwZSBpcyB1bnNpZ25lZCBs
b25nIGxvbmcNCj4gd2hpY2ggY2F1c2VzIHRoZSBpc3N1ZS4gRml4IGl0Lg0KPiANCj4gRml4ZXM6
IDk2ZjM1ZGU2OWU1OSAoIng4NitBcm06IGRyb3AgKHJlbmFtZSkgX192aXJ0X3RvX21hZGRyKCkg
LyBfX21hZGRyX3RvX3ZpcnQoKSIpDQo+IFNpZ25lZC1vZmYtYnk6IE1pY2hhbCBPcnplbCA8bWlj
aGFsLm9yemVsQGFtZC5jb20+DQo+IC0tLQ0KDQpJ4oCZdmUgdGVzdGVkIHRoaXMgb25lIGFuZCBp
dCBmaXggdGhlIGNvbXBpbGF0aW9uIGlzc3VlIG9uIHRoZSBhYm92ZSBzZXR1cCwgSeKAmXZlIGFs
c28gdGVzdGVkDQp0aGF0IGl0IGRvZXNu4oCZdCBpbnRyb2R1Y2UgaXNzdWVzIG9uIG90aGVyIHNl
dHVwIChlLmcuIGFybTY0KQ0KDQpSZXZpZXdlZC1ieTogTHVjYSBGYW5jZWxsdSA8bHVjYS5mYW5j
ZWxsdUBhcm0uY29tPg0KVGVzdGVkLWJ5OiBMdWNhIEZhbmNlbGx1IDxsdWNhLmZhbmNlbGx1QGFy
bS5jb20+DQoNCg==


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 14:14:42 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 14:14:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877939.1288106 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcPsr-0005u4-5X; Mon, 27 Jan 2025 14:14:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877939.1288106; Mon, 27 Jan 2025 14:14:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcPsr-0005tx-11; Mon, 27 Jan 2025 14:14:37 +0000
Received: by outflank-mailman (input) for mailman id 877939;
 Mon, 27 Jan 2025 14:14: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
 <SRS0=fFPb=UT=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tcPsq-0005tr-7G
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 14:14:36 +0000
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com
 [2a00:1450:4864:20::429])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0839f4a5-dcb9-11ef-99a4-01e77a169b0f;
 Mon, 27 Jan 2025 15:14:34 +0100 (CET)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-385ef8b64b3so3884906f8f.0
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 06:14:34 -0800 (PST)
Received: from localhost (0545937c.skybroadband.com. [5.69.147.124])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38c2a1761ffsm11011960f8f.7.2025.01.27.06.14.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 06:14:32 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 0839f4a5-dcb9-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1737987273; x=1738592073; darn=lists.xenproject.org;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=AdQXRQ9cjL2MNzJTQtVz+T+wXKwp6KP4F0FKbeuCHaA=;
        b=Mhae/AbCx/cwEd6dPqWLvja+gIoGBJbqWUrrz3Qbp0fKyni6mrxrJV6Eey73IKPyp5
         OAYCK4QgaW5PDCme9MVBIFYxI9cXPx5OXPUyk12mitPYVFxzUq15sIVyM2xqmI7Whejq
         YRrCjLrVNkrIlR5KuMIkftvKujwBz2pkvKwYw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737987273; x=1738592073;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=AdQXRQ9cjL2MNzJTQtVz+T+wXKwp6KP4F0FKbeuCHaA=;
        b=CunYDRS3dav0IEk9ns7a+BGVkU4mW+/hxLzfAIwD0FpGZYl/13mDFhCWpcuIOIzPj8
         +MT4dEJFZ26ZoKQxnTOB8WPEsxH+c2/WgAO3zz4UR5HuL3J+r6zpN9TAMNPqMNYCR9k1
         IJDaBkMTWa0Am+ihssqey7r2EmU0rC0M3pywB/qlSRaE/D3ObxgqbMIQuFfGHdDwjcgY
         c/SCvsiUfal/g4gY8YcGf8RCE6/iw9gGF/89+QtLIubsf1dYkQEWOS3FUnbgHi+jglU2
         +feznV6l669b8ewUzXh4P4v9CxRqleTHdQ7XiUdyYIoZt5uXOfsKj/sr9m4leomcE88o
         EOsA==
X-Forwarded-Encrypted: i=1; AJvYcCXkL7eLoI9lKWy6YUXXUZs5Jv+ASp/jypXroyZddbIK/VA53IeNp8apYe4gEyeCQ9uzqj/eDmr66Yk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxAF0teKk+MX0lXEHp9NHZTGGt+FfLFz1ZmIuMQd0jNcsFZ3JAu
	WRyWiQTXQLvGAnli0PJLk5eccMp5kVmXPkSbuPdYDhQI8kOnfR8dG2C/hjplzoKEXH4XuTbrTGM
	G08k=
X-Gm-Gg: ASbGncuFOQ86GdJp4GGpOTsEYn06eeq+lu5650iMVnDqsytNA5OG7dXwlbnLOJm1V+y
	UUd0iV57Kzy8pBCwsjPi8BLOXMLhAzFXtcBs7LzTTp506vCYNDrUaz0JioX3lcXh13ONw6WNm+b
	kLaTVsjmOx418ssRCIpWhdW7uE5EN5xD1CekBMVAfLClzRCOOHvIrAgqicxoAZuQs2NEk+5pzE2
	OVgI1rcpLjfSJhXsKEJ0QncawczQkyGbsv/EU+KXcEPu/YvcNc0J6cC6BGMVDQvaxOPPxSMUMk7
	G1FH8g1QW4mr2ZlUnOCctBIc8kmnv6V+s8o=
X-Google-Smtp-Source: AGHT+IHprSyTzp/bDQaGGYPXdjoC2kp6cprVnHtStF3l/Rbltb2pMj4I86xKw0vkm5WfUwYZGTGfqA==
X-Received: by 2002:adf:f68f:0:b0:38a:4184:1520 with SMTP id ffacd0b85a97d-38bf5673e98mr30865152f8f.27.1737987272904;
        Mon, 27 Jan 2025 06:14:32 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Mon, 27 Jan 2025 14:14:28 +0000
Message-Id: <D7CX2GVZ29ON.3O2A4VFA7NTSC@cloud.com>
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>,
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v3 09/12] x86/mpx: Map/unmap xsave area in in
 read_bndcfgu()
From: "Alejandro Vallejo" <alejandro.vallejo@cloud.com>
To: "Jan Beulich" <jbeulich@suse.com>
X-Mailer: aerc 0.18.2
References: <20250110132823.24348-1-alejandro.vallejo@cloud.com>
 <20250110132823.24348-10-alejandro.vallejo@cloud.com>
 <4011a01c-acbd-4ef4-b6f8-d266f6623289@suse.com>
In-Reply-To: <4011a01c-acbd-4ef4-b6f8-d266f6623289@suse.com>

Hi,

Thanks for reviewing this and the other patches.

On Mon Jan 27, 2025 at 10:57 AM GMT, Jan Beulich wrote:
> On 10.01.2025 14:28, Alejandro Vallejo wrote:
> > --- a/xen/arch/x86/xstate.c
> > +++ b/xen/arch/x86/xstate.c
> > @@ -1024,9 +1024,10 @@ int handle_xsetbv(u32 index, u64 new_bv)
> > =20
> >  uint64_t read_bndcfgu(void)
> >  {
> > +    uint64_t bndcfgu =3D 0;
> >      unsigned long cr0 =3D read_cr0();
> > -    struct xsave_struct *xstate
> > -        =3D idle_vcpu[smp_processor_id()]->arch.xsave_area;
> > +    struct vcpu *v =3D idle_vcpu[smp_processor_id()];
>
> Question on this one remains: Can it be pointer-to-const (in the longer
> run; certainly in can be right now)?

I have no idea where I got the idea the C constness was transitive (quite
likely from Rust, as its illegal to grab a &mut from a &). Const being
non-transitive means I can constify the vcpu as you suggest/ask. The ration=
ale
was that getting a pointer to non-const from a pointer to const seemed wron=
g.

But C is bizarre and its finer details have a way of biting. Oh well.

FWIW, this ought to hold even in the long run. There won't be anything spec=
ial
in the map/unmap macros besides some indirection, so it'll work in a very
similar fashion as it does now.

I'll adjust it as you propose.

>
> > +    struct xsave_struct *xstate =3D VCPU_MAP_XSAVE_AREA(v);
>
> I realize my similar remark on this one was actually wrong; the asm()s
> clearly modify what is being pointed top.

Indeed, xstate can definitely not be const.

> Jan

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 14:14:42 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 14:14:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877940.1288114 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcPsv-000696-Ce; Mon, 27 Jan 2025 14:14:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877940.1288114; Mon, 27 Jan 2025 14:14:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcPsv-00068z-A1; Mon, 27 Jan 2025 14:14:41 +0000
Received: by outflank-mailman (input) for mailman id 877940;
 Mon, 27 Jan 2025 14:14: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
 <SRS0=jIzP=UT=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tcPsu-00068I-5B
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 14:14:40 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0b48b548-dcb9-11ef-a0e6-8be0dac302b0;
 Mon, 27 Jan 2025 15:14:38 +0100 (CET)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-5d3d0205bd5so6684443a12.3
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 06:14:38 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab69dfd3a05sm255167966b.98.2025.01.27.06.14.37
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 27 Jan 2025 06:14:37 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 0b48b548-dcb9-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737987278; x=1738592078; 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=PQp1zjBXGJs8VmJ98XAy83soKlzh5DVrn3YRAYj99I4=;
        b=k7DgcUpxjxm7rltM8U5lQfMJJ2nqX3v/VqtepyV58Q9gxxXqAEdLxl5omvR+dlTiZ9
         k9w/Z0GbPfzHXby1CPv6iZ7Vgl1VaOr/pbaJ3ZpFi3w2KnegMrI8gKIQHKZ8YwxUDWhr
         slq8TIw+Nk7SVGuNLYgp5NRBXrI340Np1vd1U=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737987278; x=1738592078;
        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=PQp1zjBXGJs8VmJ98XAy83soKlzh5DVrn3YRAYj99I4=;
        b=BDasa480P+sNAk0YeUpYgYYShfPWMpmTm7VrAof/Qib9LxO0BMWUeNK1sY6WBv2X9/
         lkNYhe9V10Ricw1Abw6iTdtH8pwq2zHvtT7oPY8ezIASu4JVeOpk63p/ofQLTZNFOgvp
         da8cCByS3pJUBAht1fMfqunx/m1Yqh9r+CinvfK1ZYM24q7RBBiWLEFr+d2Lq9wRrqJt
         UI5w/0H2/F0OfLiLzwmMOXIowDGwU1E92c5fboihAquTkBIm9i62o/Kc+PwcXl+XFwL/
         5zQ1CEu9vie7TWYFfPREuasE+IcluB28E6oP8lOKR+r+kLJPlCT+mD3wTNaSylFwGTRB
         sUzg==
X-Gm-Message-State: AOJu0YzR2dMdZx/0ALLJfZeQ7oW+uLS3f4LDzgbWf0NRz49CMOWLQgye
	H1TthfTOTu+u/bXS3sJZF54n9inqev35z47egFbAc3y1sa0CSJUr+MrcO7+m/wVlJM3HZpjSXRE
	a
X-Gm-Gg: ASbGncszcoyvvZO7tZq5VkJMf6/VMwxHXt4uG/d/LmCxx/SPcJCeXbKNg5iYDi35qEW
	YvCk+S5QUaBJbXhAQXmyfn0CKkQIXmoGVDVzLnpUgAZnflBwwlqfTLCc7ekc31LSaGMfrbHEE6t
	ckKxXS6AzM48b9ABtTfYifXFgUKtx7JLPwoz2kXh/BTbSeCU+JSoZa/L0HNF/J2+YQn59OBSLnT
	iR3kOYj+UMri3gAAUXyVnVd8hEjinhW6ISrEJWa9CMCCYo2OA6pPvtxMYdgVu4PO6sYSSx5/mCY
	aKQ5tTfqPw==
X-Google-Smtp-Source: AGHT+IE/nfkLJkmNWE0T/Gx5mOv2OzTVJbkcP0C8OwRqxQrPmwaLvOrFOviQrMt81qFzK0VB8F0dcQ==
X-Received: by 2002:a17:907:728c:b0:ab2:d96d:6362 with SMTP id a640c23a62f3a-ab38b0b7f16mr4278119266b.1.1737987278214;
        Mon, 27 Jan 2025 06:14:38 -0800 (PST)
Date: Mon, 27 Jan 2025 15:14:36 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>
Subject: Re: [PATCH for-4.20] x86/PV: further harden guest memory accesses
 against speculative abuse
Message-ID: <Z5eUzOmK_ljLSJsu@macbook.local>
References: <a615a96e-95d2-442f-b57d-0bb51142c977@suse.com>
 <Z5dupzj0JnC--YQ7@macbook.local>
 <39a582e7-272e-478f-8613-166e51f90f72@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <39a582e7-272e-478f-8613-166e51f90f72@suse.com>

On Mon, Jan 27, 2025 at 01:06:51PM +0100, Jan Beulich wrote:
> On 27.01.2025 12:31, Roger Pau Monné wrote:
> > On Mon, Jan 27, 2025 at 11:15:22AM +0100, Jan Beulich wrote:
> >> --- a/xen/arch/x86/include/asm/asm-defns.h
> >> +++ b/xen/arch/x86/include/asm/asm-defns.h
> >> @@ -1,3 +1,5 @@
> >> +#include <asm/page-bits.h>
> >> +
> >>  #ifndef HAVE_AS_CLAC_STAC
> >>  .macro clac
> >>      .byte 0x0f, 0x01, 0xca
> >> @@ -65,17 +67,36 @@
> >>  .macro guest_access_mask_ptr ptr:req, scratch1:req, scratch2:req
> >>  #if defined(CONFIG_SPECULATIVE_HARDEN_GUEST_ACCESS)
> >>      /*
> >> -     * Here we want
> >> -     *
> >> -     * ptr &= ~0ull >> (ptr < HYPERVISOR_VIRT_END);
> >> -     *
> >> +     * Here we want to adjust \ptr such that
> >> +     * - if it's within Xen range, it becomes non-canonical,
> >> +     * - otherwise if it's (non-)canonical on input, it retains that property,
> >> +     * - if the result is non-canonical, bit 47 is clear (to avoid
> >> +     *   potentially populating the cache with Xen data),
> > 
> > It's my understanding from the commit message that this toggling of
> > bit 47 is only done due to AMD behavior, as speculative execution
> > there ignores any higher than 47, and hence non-canonical inputs are
> > no detected when speculatively executing?
> > 
> > It might be worth explicitly mentioning this in the comment.
> 
> Hmm, to be honest I'd rather not (and keep mentioning AMD to the
> description). First and foremost because if I mention it here, I
> strictly also ought to mention Hygon, I think. In the description I
> feel a little easier about not specifically saying so. (But yes, if
> you strongly think I should mention vendors here, I'd be okay-ish to
> add "on AMD-like hardware" before the closing paren on the 2nd
> bullet point.)
> 
> Further, with such a consideration, would we perhaps also want to
> consider simplifying the transformation when AMD=n in .config? (I
> could see us doing so, but not as late in a release cycle as we're
> now at. Plus I say so without having thought about whether a
> simplification is actually possible.)
> 
> >>       * but guaranteed without any conditional branches (hence in assembly).
> >> +     *
> >> +     * To achieve this we determine which bit to forcibly clear: Either bit 47
> >> +     * (in case the address is below HYPERVISOR_VIRT_END) or bit 63.  Further
> >> +     * we determine whether for forcably set bit 63: In case we first cleared
> >> +     * it, we'll merely restore the original address.  In case we ended up
> >> +     * clearing bit 47 (i.e. the address was either non-canonical or within Xen
> >> +     * range), setting the bit will yield a guaranteed non-canonical address.
> >> +     * If we didn't clear a bit, we also won't set one: The address was in the
> >> +     * low half of address space in that case with bit 47 already clear.  The
> >> +     * address can thus be left unchanged, whether canonical or not.
> > 
> > Since for AMD we have to do the bit 47 clearing, won't it be enough to
> > do something like:
> > 
> > ptr &= (ptr < HYPERVISOR_VIRT_END) ? ~(1ULL <<  (VADDR_BITS - 1) : ~0ULL;
> > 
> > So only care to clear bit 47 when ptr is below HYPERVISOR_VIRT_END?
> > As that would already diverge accesses into the Xen address space
> > without having to toggle bit 63?
> 
> No, this may transform a non-canonical input into a canonical address
> (accesses through which then won't #GP as expected), just for a different
> address range than where we had the same mistake before.

Indeed, you are right.  With the expanded comment:

Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 14:20:51 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 14:20:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877959.1288125 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcPyn-000827-07; Mon, 27 Jan 2025 14:20:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877959.1288125; Mon, 27 Jan 2025 14:20:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcPym-000820-Tg; Mon, 27 Jan 2025 14:20:44 +0000
Received: by outflank-mailman (input) for mailman id 877959;
 Mon, 27 Jan 2025 14:20: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 <SRS0=O4xJ=UT=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcPyl-00081u-Lp
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 14:20:43 +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 e405e1b2-dcb9-11ef-a0e6-8be0dac302b0;
 Mon, 27 Jan 2025 15:20:42 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-aa679ad4265so1098678866b.0
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 06:20:42 -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
 a640c23a62f3a-ab69fb4e5a0sm236644766b.153.2025.01.27.06.20.41
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 06:20:41 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e405e1b2-dcb9-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737987642; x=1738592442; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Qru1M4fUT7Isr1Z0AlBOKn1jz3c669V53mqt5oK3aNo=;
        b=ZHnpaxAubeaWBSgRLel8N9EZR0U5wZQGOOrNWelSaAIM5yqDtHpKLVtfr9o8yCv/rV
         D+HNCG07e10WnnihNyhQ3Kja5XVnU6JWC6YZ6oNlLRLG2ke16OOSSjfZ6bv+y9kmDxpN
         2RQj9xysQrWr+Yf32bdGXQ+etUpF+DJjThrVb3YwMzhT+UvavdMOU8d90kUAlvM/nXN7
         NMo6bW5akrbewMG7iaa7tWd6Z1O/T1hTHrMXzZUCtkQtkxf5qfGhTSV4V5etGgyfJHMw
         Bqv8XEpP+0CMwy/WX60pDuVni4rQJCD27z1zgQHVx5X9bOd08mJQ17DQDzJEPuo0yWW1
         0OHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737987642; x=1738592442;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Qru1M4fUT7Isr1Z0AlBOKn1jz3c669V53mqt5oK3aNo=;
        b=nDxVTnX4S70Oey2LXvP6JW0OE5wZMDLoblue1Sd4kb5C6rjpdbPW78LEFvKogfHl4i
         1p2GZIG/t+Tx0K+6Dz98NMneWLhXyJU44Oc3Evr1eCDyM+MfJIpLt3RHEnqj9bvtdf6n
         Zz3zRSMHPbjMKzndH26T91k5HBMj8pRDl7dXCKH8PdaG23PBpyBpRXz96WoR93trdgnt
         dBHUS9zZW2TsWmvVX6Jj8447l2zoJkD4STIw+TwYIBYplNaE+5RNTn79BmwaIq9LeA+q
         STkm0MyvJ9xqavfzdtnw10ws1RFgRnXLar6YtLH9pv4PlV9K1cXNcr47Pn8vagEin2M3
         Uj6g==
X-Forwarded-Encrypted: i=1; AJvYcCVfk8s/b1TMgQ5TYR7MZw0+aXN40hmjs/4hn/SDstLngsDOky5zjbDY3k7ZQvZXRPXMckBuzZuZFiM=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yziw9urWsbDGy9YqNf0MlXpLhwDLjukeQEYzSWWxyIPMSBGGJWL
	/J1kDvnnHbH9eDlcq+MLk3k/xWNal2wBgO8OoS0Fa+T4h0tlNo8K0H6g69nKFQ==
X-Gm-Gg: ASbGnct++aQHCNlCWTkgip7YNrzopqr64MiTC//28M1QX+8kWyzrE4FKBd3NWmagdBi
	OBrj7ugnxDAs0U3sbhZucBV2lkLdGFaZ4/zGWdfB0hcp899M7I2EGvU1qty05mN7452S32CsZ8I
	j3Zj8meR1YgbXKor5a3p0jkN7VuRYjWzE7xp/1n+qlRIWihU6ArcD8sGYBxzQcJdPOHAPbrkGPJ
	vcmq77iOqZKtxLpkTmgvb6BB25JlqdKxg/TfAURJ39XUwnyq5iaEjU0yLd+5Kqktoup+j/neOsf
	eesCdBhUKxTE0yeC4JCDlKf7MK9DnhLn9tgs0oprEccEcyIKjkPJOQpUZuqqLpY6gA==
X-Google-Smtp-Source: AGHT+IFHpJxlS2aURhdmhpW1tQVAwNNp5I+gLZhqI05Rfq3i9V4/SNPksZJK/k+63/3N/fKv/a5PUQ==
X-Received: by 2002:a17:907:7e85:b0:ab6:59e0:b756 with SMTP id a640c23a62f3a-ab6629cce1dmr1744839766b.14.1737987641941;
        Mon, 27 Jan 2025 06:20:41 -0800 (PST)
Message-ID: <2f34ba33-070e-4c02-a7e5-71451553a23e@suse.com>
Date: Mon, 27 Jan 2025 15:20:40 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6] vpci: Add resizable bar support
To: Jiqian Chen <Jiqian.Chen@amd.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>, Huang Rui <ray.huang@amd.com>,
 xen-devel@lists.xenproject.org
References: <20250123035003.3797022-1-Jiqian.Chen@amd.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250123035003.3797022-1-Jiqian.Chen@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 23.01.2025 04:50, Jiqian Chen wrote:
> v5->v6 changes:
> * Changed "1UL" to "1ULL" in PCI_REBAR_CTRL_SIZE idefinition for 32 bit architecture.
> * In rebar_ctrl_write used "bar - pdev->vpci->header.bars" to get index instead of reading
>   from register.
> * Added the index of BAR to error messages.
> * Changed to "continue" instead of "return an error" when vpci_add_register failed.

I'm not convinced this was a good change to make. While ...

> +static int cf_check init_rebar(struct pci_dev *pdev)
> +{
> +    uint32_t ctrl;
> +    unsigned int nbars;
> +    unsigned int rebar_offset = pci_find_ext_capability(pdev->sbdf,
> +                                                        PCI_EXT_CAP_ID_REBAR);
> +
> +    if ( !rebar_offset )
> +        return 0;
> +
> +    if ( !is_hardware_domain(pdev->domain) )
> +    {
> +        printk(XENLOG_ERR "%pp: resizable BARs unsupported for unpriv %pd\n",
> +               &pdev->sbdf, pdev->domain);
> +        return -EOPNOTSUPP;
> +    }
> +
> +    ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL(0));
> +    nbars = MASK_EXTR(ctrl, PCI_REBAR_CTRL_NBAR_MASK);
> +    for ( unsigned int i = 0; i < nbars; i++ )
> +    {
> +        int rc;
> +        struct vpci_bar *bar;
> +        unsigned int index;
> +
> +        ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL(i));
> +        index = ctrl & PCI_REBAR_CTRL_BAR_IDX;
> +        if ( index >= PCI_HEADER_NORMAL_NR_BARS )
> +        {
> +            printk(XENLOG_ERR "%pd %pp: too big BAR number %u in REBAR_CTRL\n",
> +                   pdev->domain, &pdev->sbdf, index);
> +            continue;
> +        }
> +
> +        bar = &pdev->vpci->header.bars[index];
> +        if ( bar->type != VPCI_BAR_MEM64_LO && bar->type != VPCI_BAR_MEM32 )
> +        {
> +            printk(XENLOG_ERR "%pd %pp: BAR%u is not in memory space\n",
> +                   pdev->domain, &pdev->sbdf, index);
> +            continue;
> +        }

... for these two cases we can permit Dom0 direct access because the BAR
isn't going to work anyway (as far as we can tell), ...

> +        rc = vpci_add_register(pdev->vpci, vpci_hw_read32, vpci_hw_write32,
> +                               rebar_offset + PCI_REBAR_CAP(i), 4, NULL);
> +        if ( rc )
> +        {
> +            /*
> +             * TODO: for failed pathes, need to hide ReBar capability
> +             * from hardware domain instead of returning an error.
> +             */
> +            printk(XENLOG_ERR "%pd %pp: BAR%u fail to add reg of REBAR_CAP rc=%d\n",
> +                   pdev->domain, &pdev->sbdf, index, rc);
> +            continue;
> +        }
> +
> +        rc = vpci_add_register(pdev->vpci, vpci_hw_read32, rebar_ctrl_write,
> +                               rebar_offset + PCI_REBAR_CTRL(i), 4, bar);
> +        if ( rc )
> +        {
> +            printk(XENLOG_ERR "%pd %pp: BAR%u fail to add reg of REBAR_CTRL rc=%d\n",
> +                   pdev->domain, &pdev->sbdf, index, rc);
> +            continue;
> +        }

... in these two cases we had an issue internally, and would hence wrongly
allow Dom0 direct access (and in case it's the 2nd one that failed, in fact
only partially direct access, with who knows what resulting inconsistencies).

Only with this particular change undone:
Reviewed-by: Jan Beulich <jbeulich@suse.com>

Otherwise you and Roger (who needs to at least ack the change anyway) will
need to sort that out, with me merely watching.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 14:41:39 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 14:41:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877974.1288143 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcQIv-0003iQ-O9; Mon, 27 Jan 2025 14:41:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877974.1288143; Mon, 27 Jan 2025 14:41:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcQIv-0003iJ-Kw; Mon, 27 Jan 2025 14:41:33 +0000
Received: by outflank-mailman (input) for mailman id 877974;
 Mon, 27 Jan 2025 14:41:32 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=jIzP=UT=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tcQIu-0003iB-Gw
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 14:41:32 +0000
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com
 [2a00:1450:4864:20::52f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id cc25779b-dcbc-11ef-a0e6-8be0dac302b0;
 Mon, 27 Jan 2025 15:41:31 +0100 (CET)
Received: by mail-ed1-x52f.google.com with SMTP id
 4fb4d7f45d1cf-5d3ecae02beso6194627a12.0
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 06:41:30 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5dc186d8b37sm5467311a12.72.2025.01.27.06.41.29
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 27 Jan 2025 06:41:29 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: cc25779b-dcbc-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737988890; x=1738593690; 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=DuQVWa3UAj0x1+sC5RPCZtQ/X8NDmzt/StrL5IE96mw=;
        b=upV8hwOQe2k7AxFv7Yjl0dRYyKY2OnAT989U37hpimAzC+t4kONCW8Z9xqtal3vE/a
         8F2qywQ5+WlIiuaNoiNF9t+1/FMHHf4L2BNFidpFq/48icoQrmGJGQ6en9VR+yP7irxr
         O54fA0n52gt+JKX1l9dRBzbjzqmdYwbZVV5Sg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737988890; x=1738593690;
        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=DuQVWa3UAj0x1+sC5RPCZtQ/X8NDmzt/StrL5IE96mw=;
        b=YiqZ+bLMfO4vMPUjF7QwPlz8ZXuBbflVkSDMd1NJifVLGfwqBTpoOfr5Bu/P8HFkln
         NlC4Pmbw5E4lCdRBLF0L5ECXGnvIbiafM9JIs+XuT8C84hEPBGOyA+imXxK3iCP+WX9O
         H1fDhP1LUryQ4js85ic0PQGi/D5bK+XRWF9Bmk0AFS5xO6NOG7Yfm7d7iL0uxkHI+njl
         uY29I4Nmt1i7FhQgxaCQSKsSc3E2wtiyts59ifkhfJIhRHTsWu72ocxCLck2adT0+IbB
         QV2FDXPE84EiQBDdB120ypB1vb48G+X4iWbdcaMu6MIpV+vx3G6ET00Kaeta05Obqb3L
         lxXw==
X-Forwarded-Encrypted: i=1; AJvYcCX9JAdMdXk4mSf7ZB490HLH0i0GTAb38zG+ta+WpK9HTofcPv+929jr/I0jOQNVv+JrdRnYCRXc3FY=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw0T8VbrQshqM3quy+HIYRZVMjKyaa1S4cyZTQaO5IrqBwXbF9D
	YuY4kT8FX0ZkebACWl+L3AOmaaQxOwBkUB8EzTLwNE9VcEdL2sDZEXF7bC3+wYw=
X-Gm-Gg: ASbGncvoSsFGwcI3ZsEC6a3hgRt9tcOyGsleF16xAudA6aSg0FT5U+GUBfnPcq8QBgK
	RDeFGoTbeRC46lcH6ibYmSUm14Re8VjMNDyvqY6sqCaxsy6YyjnSEcTojmfnFY81PK06HbrsKhR
	bxvWOJiPcxgZEl4VugCRW5nMtj4G5/8CyviNqjpYkzMEJPkORKY97/K8Hd0+zfWYgkr9zqcM3zR
	OY9j5pNlEu79Z27VeXAh5JCkDX0rZMyxwzDX5Ik5kNrKLgnVCk9Z0ctpj8abcCeBXjlnhaOyaru
	ca5cSItsOg==
X-Google-Smtp-Source: AGHT+IEkT5y7ZTrLdEEz45DlubyCU0IVulmOTVNa2RieT4MUePILWFs4ZZBYlzdM1XTFNrxLPBbi1Q==
X-Received: by 2002:a05:6402:278f:b0:5d2:7346:3ecb with SMTP id 4fb4d7f45d1cf-5db7d2f8066mr39168584a12.12.1737988890364;
        Mon, 27 Jan 2025 06:41:30 -0800 (PST)
Date: Mon, 27 Jan 2025 15:41:28 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Jiqian Chen <Jiqian.Chen@amd.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Huang Rui <ray.huang@amd.com>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v6] vpci: Add resizable bar support
Message-ID: <Z5ebGImjSz-55Nkj@macbook.local>
References: <20250123035003.3797022-1-Jiqian.Chen@amd.com>
 <2f34ba33-070e-4c02-a7e5-71451553a23e@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <2f34ba33-070e-4c02-a7e5-71451553a23e@suse.com>

On Mon, Jan 27, 2025 at 03:20:40PM +0100, Jan Beulich wrote:
> On 23.01.2025 04:50, Jiqian Chen wrote:
> > v5->v6 changes:
> > * Changed "1UL" to "1ULL" in PCI_REBAR_CTRL_SIZE idefinition for 32 bit architecture.
> > * In rebar_ctrl_write used "bar - pdev->vpci->header.bars" to get index instead of reading
> >   from register.
> > * Added the index of BAR to error messages.
> > * Changed to "continue" instead of "return an error" when vpci_add_register failed.
> 
> I'm not convinced this was a good change to make. While ...
> 
> > +static int cf_check init_rebar(struct pci_dev *pdev)
> > +{
> > +    uint32_t ctrl;
> > +    unsigned int nbars;
> > +    unsigned int rebar_offset = pci_find_ext_capability(pdev->sbdf,
> > +                                                        PCI_EXT_CAP_ID_REBAR);
> > +
> > +    if ( !rebar_offset )
> > +        return 0;
> > +
> > +    if ( !is_hardware_domain(pdev->domain) )
> > +    {
> > +        printk(XENLOG_ERR "%pp: resizable BARs unsupported for unpriv %pd\n",
> > +               &pdev->sbdf, pdev->domain);
> > +        return -EOPNOTSUPP;
> > +    }
> > +
> > +    ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL(0));
> > +    nbars = MASK_EXTR(ctrl, PCI_REBAR_CTRL_NBAR_MASK);
> > +    for ( unsigned int i = 0; i < nbars; i++ )
> > +    {
> > +        int rc;
> > +        struct vpci_bar *bar;
> > +        unsigned int index;
> > +
> > +        ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL(i));
> > +        index = ctrl & PCI_REBAR_CTRL_BAR_IDX;
> > +        if ( index >= PCI_HEADER_NORMAL_NR_BARS )
> > +        {
> > +            printk(XENLOG_ERR "%pd %pp: too big BAR number %u in REBAR_CTRL\n",
> > +                   pdev->domain, &pdev->sbdf, index);
> > +            continue;
> > +        }
> > +
> > +        bar = &pdev->vpci->header.bars[index];
> > +        if ( bar->type != VPCI_BAR_MEM64_LO && bar->type != VPCI_BAR_MEM32 )
> > +        {
> > +            printk(XENLOG_ERR "%pd %pp: BAR%u is not in memory space\n",
> > +                   pdev->domain, &pdev->sbdf, index);
> > +            continue;
> > +        }
> 
> ... for these two cases we can permit Dom0 direct access because the BAR
> isn't going to work anyway (as far as we can tell), ...
> 
> > +        rc = vpci_add_register(pdev->vpci, vpci_hw_read32, vpci_hw_write32,
> > +                               rebar_offset + PCI_REBAR_CAP(i), 4, NULL);
> > +        if ( rc )
> > +        {
> > +            /*
> > +             * TODO: for failed pathes, need to hide ReBar capability
> > +             * from hardware domain instead of returning an error.
> > +             */
> > +            printk(XENLOG_ERR "%pd %pp: BAR%u fail to add reg of REBAR_CAP rc=%d\n",
> > +                   pdev->domain, &pdev->sbdf, index, rc);
> > +            continue;
> > +        }
> > +
> > +        rc = vpci_add_register(pdev->vpci, vpci_hw_read32, rebar_ctrl_write,
> > +                               rebar_offset + PCI_REBAR_CTRL(i), 4, bar);
> > +        if ( rc )
> > +        {
> > +            printk(XENLOG_ERR "%pd %pp: BAR%u fail to add reg of REBAR_CTRL rc=%d\n",
> > +                   pdev->domain, &pdev->sbdf, index, rc);
> > +            continue;
> > +        }
> 
> ... in these two cases we had an issue internally, and would hence wrongly
> allow Dom0 direct access (and in case it's the 2nd one that failed, in fact
> only partially direct access, with who knows what resulting inconsistencies).
> 
> Only with this particular change undone:
R> Reviewed-by: Jan Beulich <jbeulich@suse.com>
> 
> Otherwise you and Roger (who needs to at least ack the change anyway) will
> need to sort that out, with me merely watching.

Ideally errors here should be dealt with by masking the capability.
However Xen doesn't yet have that support.  The usage of continue is
to merely attempt to keep any possible setup hooks working (header,
MSI, MSI-X). Returning failure from init_rebar() will cause all
vPCI hooks to be removed, and thus the hardware domain to have
unmediated access to the device, which is likely worse than just
continuing here.

This already happens in other capability init paths, that are much less
careful about returning errors, so Jan might be right that if nothing
else for consistency we return an error.  With the hope that
initialization error of capabilities in vPCI will eventually lead to
such capabilities being hidden instead of removing all vPCI handlers
from the device.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 14:47:21 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 14:47:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877983.1288153 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcQOT-0004Ii-A1; Mon, 27 Jan 2025 14:47:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877983.1288153; Mon, 27 Jan 2025 14:47:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcQOT-0004Ib-7N; Mon, 27 Jan 2025 14:47:17 +0000
Received: by outflank-mailman (input) for mailman id 877983;
 Mon, 27 Jan 2025 14:47:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=O4xJ=UT=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcQOS-0004IV-2T
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 14:47:16 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 990a370f-dcbd-11ef-a0e6-8be0dac302b0;
 Mon, 27 Jan 2025 15:47:14 +0100 (CET)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-5d3d14336f0so7777323a12.3
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 06:47:14 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab6760fc485sm593270566b.160.2025.01.27.06.47.11
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 06:47:12 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 990a370f-dcbd-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737989234; x=1738594034; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=4dN2Jf2QxKafFsTiL+n5u/HmojnBqzxm8u2EAGTVhJM=;
        b=TZCR1OX78m9WITzyi7hhcrO0Ji85UrDxavhWXHnLEFTWRlza2q+WC9MgP4GQ0z234b
         tkDklmKfeRsowqxir0qw1xm8s0g1D2scjPpGxs5L0FENTOxXnNzVqYuReigoZDW+SODe
         l5iPC2B04B71a7nDTwSBigvNRPY8ptujTWuGH15uyBDz2zU34jLn7ac78FWV+UeEb8E0
         YJhN85OGdWvCTywlYVjzBAyivhbQqzsNvAGmKqOEvu3xDOQy2Yd8kx7smWajG9BsFbcF
         vC9UkuTulngtDByYLNATiqKOllnMBJmBv4eOCQlUKd4FbocKCbHjY68dcRQf9Lwr5b8P
         HdqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737989234; x=1738594034;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=4dN2Jf2QxKafFsTiL+n5u/HmojnBqzxm8u2EAGTVhJM=;
        b=A53dFdLRp+fqrsMVHoyp827rbijOwwUIMote7t/rNwPOCb0lVfVKuL5x/R7RuepXgh
         D5Oa8b97ImMiL3bYpCBRNp3yoLGybgT4VYRIfHMRTGh3toRN/3birXQHjJ0qbasZdGvn
         2AQ1ltQ7Ftl9CMWk99nN2lOY2jIxuM2NuOcnsVbPOrklIH+ifwCdkPOrfFcXBhUzZFaz
         8YupgygrcvZX6DDm5OylhV4SmACpnvsGiSArkLGeXM4Igc/fjM9EeHv/dNj0ckadL5k2
         +iTBA9s0b0fhk0pjFgk/yvLQ8nTQCEOxbQKMFYO+U7NsYsjXYy94gZP1IPnFNgU7rDrL
         qehg==
X-Forwarded-Encrypted: i=1; AJvYcCXfhdt4ZuIN7RDxDomruqZkelEu91Y+mle8sE+G7U8agNY5el0ZAOW3U9fbjgz7Sq3Q7oK+4e+uN6A=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzjI2WxLCTWYoxNto8ziNqOev/5CJukJyYmsjUGGbt9PZ1WpmhQ
	BxhNCOcWoTy6ctF1k3TdfA3pZ3tE1bFixQwejW7l1oV6X8AXdSVCsd9P0hQzxg==
X-Gm-Gg: ASbGnct6c0SWkf5wxpuQC7t0l6LhJHTPusbMbQjItQtYN/CFo85vLjyrc5bjHCNO5WV
	oJRLqWp8mMNKS+9798yBzhEkEBtYz+vj/UUaB2dJNE7FvvkZcqdeRtGWUcV7quHsbIBknxooYQW
	ts4qL519zexogMb7KlUiiXVDfd8pN66wlyEE+mQihensGrvMfygHV3ozYDcyDHIbnmZQRY9wPyR
	BraaZ3jLkldU3Raf35uO8l5XDpSUGdSljozhtrV/9QFt5+FvoU5noAweu8PoQvtZ5e/nG3Vn4F6
	QTmQA7Lbp4/7CEpNo8VM2dJlJnUDqh4N3y0BxAa+/gU5EI7XDi+mpihFWDhK3liBpw==
X-Google-Smtp-Source: AGHT+IGMOeBjqaG+v1rdsY09FQzSkHWHO/l379dsRQ34yaHqbGqhayqzi+WhV6ZqE84b37Wmyw7CCw==
X-Received: by 2002:a17:906:eb18:b0:ab6:9d53:13be with SMTP id a640c23a62f3a-ab69d531682mr486298866b.29.1737989232588;
        Mon, 27 Jan 2025 06:47:12 -0800 (PST)
Message-ID: <e51b0425-568a-4a4b-b240-a5276a017a70@suse.com>
Date: Mon, 27 Jan 2025 15:47:11 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] xen/riscv: identify specific ISA supported by cpu
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Alistair Francis <alistair.francis@wdc.com>,
 Bob Eshleman <bobbyeshleman@gmail.com>, Connor Davis
 <connojdavis@gmail.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <ddf678bb829003b2c4a0a85166a29b61e75bcea9.1737643226.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <ddf678bb829003b2c4a0a85166a29b61e75bcea9.1737643226.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 23.01.2025 15:46, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/arch/riscv/cpufeature.c
> @@ -0,0 +1,482 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Taken for Linux kernel v6.12-rc3.

Nit: s/for/from/ ? Perhaps also add "Originally ...", as it'll otherwise
also go stale as changes are being made.

> + * Copyright (C) 2015 ARM Ltd.
> + * Copyright (C) 2017 SiFive
> + * Copyright (C) 2024 Vates
> + */
> +
> +#include <xen/bitmap.h>
> +#include <xen/ctype.h>
> +#include <xen/device_tree.h>
> +#include <xen/errno.h>
> +#include <xen/init.h>
> +#include <xen/lib.h>
> +#include <xen/sections.h>
> +
> +#include <asm/cpufeature.h>
> +
> +#ifdef CONFIG_ACPI
> +#error "cpufeature.c functions should be updated to support ACPI"
> +#endif
> +
> +struct riscv_isa_ext_data {
> +    unsigned int id;
> +    const char *name;
> +};
> +
> +#define RISCV_ISA_EXT_DATA(ext_name, ext_id)    \
> +{                                               \
> +    .id = ext_id,                               \
> +    .name = #ext_name,                          \
> +}
> +
> +/* Host ISA bitmap */
> +static __ro_after_init DECLARE_BITMAP(riscv_isa, RISCV_ISA_EXT_MAX);
> +
> +static int __init dt_get_cpuid_from_node(const struct dt_device_node *cpu,
> +                                         unsigned long *dt_cpuid)
> +{
> +    const __be32 *prop;
> +    unsigned int reg_len;
> +
> +    /*
> +     * For debug purpose check dt_n_size_cells(cpu) value.
> +     *
> +     * Based on DT's bindings [1] and RISC-V's DTS files in kernel #size-cells
> +     * for cpu node is expected to be 0.
> +     *
> +     * [1] https://www.kernel.org/doc/Documentation/devicetree/bindings/riscv/cpus.txt
> +     */
> +    if ( dt_n_size_cells(cpu) != 0 )
> +        printk("DT's cpu node `%s`: #size-cells %d\n",
> +               dt_node_full_name(cpu), dt_n_size_cells(cpu));
> +
> +    prop = dt_get_property(cpu, "reg", &reg_len);
> +    if ( !prop )
> +    {
> +        printk("cpu node `%s`: has no reg property\n", dt_node_full_name(cpu));
> +        return -EINVAL;
> +    }
> +
> +    if ( reg_len < dt_cells_to_size(dt_n_addr_cells(cpu)) )
> +    {
> +        printk("cpu node `%s`: reg property too short\n",
> +               dt_node_full_name(cpu));
> +        return -EINVAL;
> +    }
> +
> +    /*
> +     * It is safe to convert `paddr_t` to `unsigned long` as dt_read_paddr()
> +     * in the context of this function returns cpuid which according to RISC-V
> +     * specification could be from 0 to ((1ULL << (MXLEN)) - 1), where
> +     * MXLEN=32 for RV32 and MXLEN=64 for RV64.
> +    */

Nit: Indentation.

> +    *dt_cpuid = dt_read_paddr(prop, dt_n_addr_cells(cpu));
> +
> +    return 0;
> +}
> +
> +/*
> + * The canonical order of ISA extension names in the ISA string is defined in
> + * chapter 27 of the unprivileged specification.
> + *
> + * The specification uses vague wording, such as should, when it comes to
> + * ordering, so for our purposes the following rules apply:
> + *
> + * 1. All multi-letter extensions must be separated from other extensions by an
> + *    underscore.
> + *
> + * 2. Additional standard extensions (starting with 'Z') must be sorted after
> + *    single-letter extensions and before any higher-privileged extensions.
> + *
> + * 3. The first letter following the 'Z' conventionally indicates the most
> + *    closely related alphabetical extension category, IMAFDQLCBKJTPVH.
> + *    If multiple 'Z' extensions are named, they must be ordered first by
> + *    category, then alphabetically within a category.
> + *
> + * 4. Standard supervisor-level extensions (starting with 'S') must be listed
> + *    after standard unprivileged extensions.  If multiple supervisor-level
> + *    extensions are listed, they must be ordered alphabetically.
> + *
> + * 5. Standard machine-level extensions (starting with 'Zxm') must be listed
> + *    after any lower-privileged, standard extensions.  If multiple
> + *    machine-level extensions are listed, they must be ordered
> + *    alphabetically.
> + *
> + * 6. Non-standard extensions (starting with 'X') must be listed after all
> + *    standard extensions. If multiple non-standard extensions are listed, they
> + *    must be ordered alphabetically.
> + *
> + * An example string following the order is:
> + *    rv64imadc_zifoo_zigoo_zafoo_sbar_scar_zxmbaz_xqux_xrux
> + *
> + * New entries to this struct should follow the ordering rules described above.
> + *
> + * Extension name must be all lowercase (according to device-tree binding)
> + * and strncmp() is used in match_isa_ext() to compare extension names instead
> + * of strncasecmp().
> + */
> +const struct riscv_isa_ext_data __initconst riscv_isa_ext[] = {
> +    RISCV_ISA_EXT_DATA(i, RISCV_ISA_EXT_i),
> +    RISCV_ISA_EXT_DATA(m, RISCV_ISA_EXT_m),
> +    RISCV_ISA_EXT_DATA(a, RISCV_ISA_EXT_a),
> +    RISCV_ISA_EXT_DATA(f, RISCV_ISA_EXT_f),
> +    RISCV_ISA_EXT_DATA(d, RISCV_ISA_EXT_d),
> +    RISCV_ISA_EXT_DATA(q, RISCV_ISA_EXT_q),
> +    RISCV_ISA_EXT_DATA(h, RISCV_ISA_EXT_h),
> +    RISCV_ISA_EXT_DATA(zicntr, RISCV_ISA_EXT_ZICNTR),
> +    RISCV_ISA_EXT_DATA(zicsr, RISCV_ISA_EXT_ZICSR),
> +    RISCV_ISA_EXT_DATA(zifencei, RISCV_ISA_EXT_ZIFENCEI),
> +    RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE),
> +    RISCV_ISA_EXT_DATA(zihpm, RISCV_ISA_EXT_ZIHPM),
> +    RISCV_ISA_EXT_DATA(zbb, RISCV_ISA_EXT_ZBB),
> +    RISCV_ISA_EXT_DATA(smaia, RISCV_ISA_EXT_SMAIA),
> +    RISCV_ISA_EXT_DATA(ssaia, RISCV_ISA_EXT_SSAIA),
> +};

Just to clarify: There's no particular sorting intended for this table,
while ...

> +static const struct riscv_isa_ext_data __initconst required_extensions[] = {
> +    RISCV_ISA_EXT_DATA(zbb, RISCV_ISA_EXT_ZBB),
> +    RISCV_ISA_EXT_DATA(zicsr, RISCV_ISA_EXT_ZICSR),
> +    RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE),
> +};

... this one looks to mean to be alphabetically sorted?

> +static bool is_lowercase_extension_name(const char *str)
> +{
> +    /*
> +     * `str` could contain full riscv,isa string from device tree so one
> +     * of the stop condionitions is checking for '_' as extensions are
> +     * separated by '_'.
> +     */
> +    for ( unsigned int i = 0; (str[i] != '\0') && (str[i] != '_'); i++ )
> +        if ( !islower(str[i]) )
> +            return false;
> +
> +    return true;
> +}
> +
> +static void __init match_isa_ext(const char *name, const char *name_end,
> +                                 unsigned long *bitmap)
> +{
> +    const size_t riscv_isa_ext_count = ARRAY_SIZE(riscv_isa_ext);
> +
> +    for ( unsigned int i = 0; i < riscv_isa_ext_count; i++ )
> +    {
> +        const struct riscv_isa_ext_data *ext = &riscv_isa_ext[i];
> +
> +        /*
> +         * `name` (according to device tree binding) and
> +         * `ext->name` (according to initialization of riscv_isa_ext[]
> +         * elements) must be all in lowercase.
> +         *
> +         * Just to be sure that it is true, ASSERT() is added.
> +         */
> +        ASSERT(is_lowercase_extension_name(name) &&
> +               is_lowercase_extension_name(ext->name));

More general remark: While asserting on ext->name is okay, for it being
our own data, asserting on data coming from the outside is generally not
correct. For now I'm not going to insist on this being changed, but
sooner or later it will want revisiting.

> +        if ( (name_end - name == strlen(ext->name)) &&
> +             !strncmp(name, ext->name, name_end - name) )
> +        {
> +            __set_bit(ext->id, bitmap);
> +            break;
> +        }
> +    }
> +}
> +
> +static int __init riscv_isa_parse_string(const char *isa,
> +                                         unsigned long *out_bitmap)
> +{
> +    if ( (isa[0] != 'r') && (isa[1] != 'v') )
> +        return -EINVAL;
> +
> +#if defined(CONFIG_RISCV_32)
> +    if ( isa[2] != '3' && isa[3] != '2' )
> +        return -EINVAL;
> +#elif defined(CONFIG_RISCV_64)
> +    if ( isa[2] != '6' && isa[3] != '4' )
> +        return -EINVAL;
> +#else
> +    #error "unsupported RISC-V bitness"

Nit: We generally like to have the # in the first column, and - if
so desired - blank padding afterwards.

> +#endif
> +
> +    isa += 4;
> +
> +    while ( *isa )
> +    {
> +        const char *ext = isa++;
> +        const char *ext_end = isa;
> +        bool ext_err = false;
> +
> +        switch ( *ext )
> +        {
> +        case 'x':
> +        case 'X':
> +            printk_once("Vendor extensions are ignored in riscv,isa\n");
> +            /*
> +             * To skip an extension, we find its end.
> +             * As multi-letter extensions must be split from other multi-letter
> +             * extensions with an "_", the end of a multi-letter extension will
> +             * either be the null character or the "_" at the start of the next
> +             * multi-letter extension.
> +             */
> +            for ( ; *isa && *isa != '_'; ++isa )
> +                ;
> +            ext_err = true;
> +            break;
> +
> +        case 's':
> +            /*
> +             * Workaround for invalid single-letter 's' & 'u' (QEMU):
> +             *   Before QEMU 7.1 it was an issue with misa to ISA string
> +             *   conversion:
> +             *     https://patchwork.kernel.org/project/qemu-devel/patch/dee09d708405075420b29115c1e9e87910b8da55.1648270894.git.research_trasio@irq.a4lg.com/#24792587
> +             *   Additional details of the workaround on Linux kernel side:
> +             *     https://lore.kernel.org/linux-riscv/ae93358e-e117-b43d-faad-772c529f846c@irq.a4lg.com/#t
> +             *
> +             * No need to set the bit in riscv_isa as 's' & 'u' are
> +             * not valid ISA extensions. It works unless the first
> +             * multi-letter extension in the ISA string begins with
> +             * "Su" and is not prefixed with an underscore.
> +             */
> +            if ( ext[-1] != '_' && ext[1] == 'u' )
> +            {
> +                ++isa;
> +                ext_err = true;
> +                break;
> +            }
> +            fallthrough;
> +        case 'S':
> +        case 'z':
> +        case 'Z':

With match_isa_ext() insisting on ISA strings being all lowercase, what's
the point of permitting 'S' and 'Z' here?

> +void __init riscv_fill_hwcap(void)
> +{
> +    unsigned int i;
> +    size_t req_extns_amount = ARRAY_SIZE(required_extensions);
> +    bool all_extns_available = true;
> +
> +    riscv_fill_hwcap_from_isa_string();
> +
> +    if ( bitmap_empty(riscv_isa, RISCV_ISA_EXT_MAX) )
> +    {
> +        const char *failure_msg = has_isa_extensions_property() ?
> +                                    "\"riscv,isa-extension\" isn't supported" :
> +                                    "\"riscv,isa\" parsing failed";

Nit: Indentation (the opening double quotes on the continuation lines
want to line up with the 'h' in has_isa_extensions_property).

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 14:52:50 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 14:52:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.877995.1288162 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcQTd-0006Io-Vk; Mon, 27 Jan 2025 14:52:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 877995.1288162; Mon, 27 Jan 2025 14:52:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcQTd-0006Ih-Sj; Mon, 27 Jan 2025 14:52:37 +0000
Received: by outflank-mailman (input) for mailman id 877995;
 Mon, 27 Jan 2025 14:52:36 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=O4xJ=UT=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcQTc-0006IX-Mo
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 14:52: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 56afbc8c-dcbe-11ef-99a4-01e77a169b0f;
 Mon, 27 Jan 2025 15:52:33 +0100 (CET)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-5dc10fe4e62so8374477a12.1
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 06:52:32 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab675e8b02dsm583160066b.85.2025.01.27.06.52.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 06:52:32 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 56afbc8c-dcbe-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737989552; x=1738594352; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=mJNSyZqIcL05KyotkwRsV9dF1Koazr54M3Gb2q3T28Y=;
        b=GTndCGH092Yb5S5Jg9/Az9JqDcurbNn8aBwiKbPphvbQmYrpUgLM8cfgXswZfxayWv
         79tD+qZt8BVf/v/Ym0dvCxWqfLrLllX/asIgXlXdT2yo2pkxmJukw59kMNyjUyGH9EHm
         WxNN92mTsbGLcVm7TL+0TLnYKaC8sdrd1JfZQxjBFACxby4LnvShMuOYZmY8mnA5xOMR
         U3BnXqf6yielcr2Bwc8n4WumqoWLX6vJhWv/QhVJd2mErrojTk+3vAVYI4QuId28MNPo
         VJUdN3iT79stbqsfugaEwBW8t+34riITcYTKwCS8QRmb+qUPyQe+Hap3O25lCB6sUjek
         M43w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737989552; x=1738594352;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=mJNSyZqIcL05KyotkwRsV9dF1Koazr54M3Gb2q3T28Y=;
        b=mAyliS3bI1rRq6R2it8TzfO6vMNd5XER8xlKRCWYiasTG5+RcNf0kgfOJXC6IpsCEX
         OxHcTIxW1Z6FKoku7WknQx0rLnzqsZw3tKFe1oiMugjhiCxt0P7hFcPWKT6TNoNFexLp
         TvvnMepaNbmeP34MelIOw3QTKLSJY4QzKukbReAVd+girmV8bVHMpeFxYYkXRAs/L75u
         zXn8QXa2Un6xFcMR9v+eH53iY42vCeSrUQfgZiF34aRQ7iuSDNIOqw15TgJkl4I9964n
         dFTGzDcgSFTYmRzZumTsA6dFrWNHpzyR0NrfGoyg3kHhkFTQsVrxm8Xc7W+q0OC9shJQ
         Dr/w==
X-Forwarded-Encrypted: i=1; AJvYcCWXYQxv2+UKjaqmVghu8UveFFgbuMt8tn7FwTcFY5WcaRaPV4sE9Hv04yx8Kf3UvgX3Bg8BvWnI9aQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyJa/Qd+knRLCzpgf5QbmxH5XylABkvUMJk1eH9r6YeuyOJipI2
	SzBFbf4NrdC1MKStzKUz5XrwZRelgplDXiHBa2Sr54jjs7fzdH8Af8SAd9dT7g==
X-Gm-Gg: ASbGncv+AHlwDHL9RNy5zt0AfW9+RCm9NA6xwRhhApZKnuA63Fc1Ur1gpt/Cs2GottE
	lYmVaS/FMGB02yD271l0018FLqvf5S5H+8jK4FudLxONJFfkg/N+RB4YosfKmkMrrdfQs6xZfh2
	8T/SFsj6fJeeHgHzvEuT5d+6rDZ3h7AUzciTe8AFGsd2wRgyvMEglvPVbi8gshr+POKCZWmJwYC
	c9BQI18YGcm/v9lQPuWi5PAYws7m34V7EnmS2OtpVNRcUUVmfSfbfLEk8ipGHNwKa9lmgUnCZzC
	4O8juhi3z3ied3dJlSgHq95t4k2QyW+aXDtJLQlDXHAWmyfAYwdpvAggjdYSpmGDLg==
X-Google-Smtp-Source: AGHT+IE5kNezw1MZFDXf44R7W2J1js8nIja71ZVmoyaX702rxjwruUTkVl92ZeH7Mg+ZaeyO2YPhug==
X-Received: by 2002:a17:906:4fc7:b0:aa6:6c08:dc79 with SMTP id a640c23a62f3a-ab38b42d8f9mr4116281666b.35.1737989552329;
        Mon, 27 Jan 2025 06:52:32 -0800 (PST)
Message-ID: <9a4ed1f8-0cbf-4df5-804e-78cc3ee1d777@suse.com>
Date: Mon, 27 Jan 2025 15:52:31 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6] vpci: Add resizable bar support
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Cc: Jiqian Chen <Jiqian.Chen@amd.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>, Huang Rui <ray.huang@amd.com>,
 xen-devel@lists.xenproject.org
References: <20250123035003.3797022-1-Jiqian.Chen@amd.com>
 <2f34ba33-070e-4c02-a7e5-71451553a23e@suse.com>
 <Z5ebGImjSz-55Nkj@macbook.local>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <Z5ebGImjSz-55Nkj@macbook.local>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 27.01.2025 15:41, Roger Pau Monné wrote:
> On Mon, Jan 27, 2025 at 03:20:40PM +0100, Jan Beulich wrote:
>> On 23.01.2025 04:50, Jiqian Chen wrote:
>>> v5->v6 changes:
>>> * Changed "1UL" to "1ULL" in PCI_REBAR_CTRL_SIZE idefinition for 32 bit architecture.
>>> * In rebar_ctrl_write used "bar - pdev->vpci->header.bars" to get index instead of reading
>>>   from register.
>>> * Added the index of BAR to error messages.
>>> * Changed to "continue" instead of "return an error" when vpci_add_register failed.
>>
>> I'm not convinced this was a good change to make. While ...
>>
>>> +static int cf_check init_rebar(struct pci_dev *pdev)
>>> +{
>>> +    uint32_t ctrl;
>>> +    unsigned int nbars;
>>> +    unsigned int rebar_offset = pci_find_ext_capability(pdev->sbdf,
>>> +                                                        PCI_EXT_CAP_ID_REBAR);
>>> +
>>> +    if ( !rebar_offset )
>>> +        return 0;
>>> +
>>> +    if ( !is_hardware_domain(pdev->domain) )
>>> +    {
>>> +        printk(XENLOG_ERR "%pp: resizable BARs unsupported for unpriv %pd\n",
>>> +               &pdev->sbdf, pdev->domain);
>>> +        return -EOPNOTSUPP;
>>> +    }
>>> +
>>> +    ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL(0));
>>> +    nbars = MASK_EXTR(ctrl, PCI_REBAR_CTRL_NBAR_MASK);
>>> +    for ( unsigned int i = 0; i < nbars; i++ )
>>> +    {
>>> +        int rc;
>>> +        struct vpci_bar *bar;
>>> +        unsigned int index;
>>> +
>>> +        ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL(i));
>>> +        index = ctrl & PCI_REBAR_CTRL_BAR_IDX;
>>> +        if ( index >= PCI_HEADER_NORMAL_NR_BARS )
>>> +        {
>>> +            printk(XENLOG_ERR "%pd %pp: too big BAR number %u in REBAR_CTRL\n",
>>> +                   pdev->domain, &pdev->sbdf, index);
>>> +            continue;
>>> +        }
>>> +
>>> +        bar = &pdev->vpci->header.bars[index];
>>> +        if ( bar->type != VPCI_BAR_MEM64_LO && bar->type != VPCI_BAR_MEM32 )
>>> +        {
>>> +            printk(XENLOG_ERR "%pd %pp: BAR%u is not in memory space\n",
>>> +                   pdev->domain, &pdev->sbdf, index);
>>> +            continue;
>>> +        }
>>
>> ... for these two cases we can permit Dom0 direct access because the BAR
>> isn't going to work anyway (as far as we can tell), ...
>>
>>> +        rc = vpci_add_register(pdev->vpci, vpci_hw_read32, vpci_hw_write32,
>>> +                               rebar_offset + PCI_REBAR_CAP(i), 4, NULL);
>>> +        if ( rc )
>>> +        {
>>> +            /*
>>> +             * TODO: for failed pathes, need to hide ReBar capability
>>> +             * from hardware domain instead of returning an error.
>>> +             */
>>> +            printk(XENLOG_ERR "%pd %pp: BAR%u fail to add reg of REBAR_CAP rc=%d\n",
>>> +                   pdev->domain, &pdev->sbdf, index, rc);
>>> +            continue;
>>> +        }
>>> +
>>> +        rc = vpci_add_register(pdev->vpci, vpci_hw_read32, rebar_ctrl_write,
>>> +                               rebar_offset + PCI_REBAR_CTRL(i), 4, bar);
>>> +        if ( rc )
>>> +        {
>>> +            printk(XENLOG_ERR "%pd %pp: BAR%u fail to add reg of REBAR_CTRL rc=%d\n",
>>> +                   pdev->domain, &pdev->sbdf, index, rc);
>>> +            continue;
>>> +        }
>>
>> ... in these two cases we had an issue internally, and would hence wrongly
>> allow Dom0 direct access (and in case it's the 2nd one that failed, in fact
>> only partially direct access, with who knows what resulting inconsistencies).
>>
>> Only with this particular change undone:
> R> Reviewed-by: Jan Beulich <jbeulich@suse.com>
>>
>> Otherwise you and Roger (who needs to at least ack the change anyway) will
>> need to sort that out, with me merely watching.
> 
> Ideally errors here should be dealt with by masking the capability.
> However Xen doesn't yet have that support.  The usage of continue is
> to merely attempt to keep any possible setup hooks working (header,
> MSI, MSI-X). Returning failure from init_rebar() will cause all
> vPCI hooks to be removed, and thus the hardware domain to have
> unmediated access to the device, which is likely worse than just
> continuing here.

Hmm, true. Maybe with the exception of the case where the first reg
registration works, but the 2nd fails. Since CTRL is writable but
CAP is r/o (and data there is simply being handed through) I wonder
whether we need to intercept CAP at all, and if we do, whether we
wouldn't better try to register CTRL first.

Jan

> This already happens in other capability init paths, that are much less
> careful about returning errors, so Jan might be right that if nothing
> else for consistency we return an error.  With the hope that
> initialization error of capabilities in vPCI will eventually lead to
> such capabilities being hidden instead of removing all vPCI handlers
> from the device.
> 
> Thanks, Roger.



From xen-devel-bounces@lists.xenproject.org Mon Jan 27 14:56:21 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 14:56:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878003.1288173 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcQXE-0006wC-EK; Mon, 27 Jan 2025 14:56:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878003.1288173; Mon, 27 Jan 2025 14:56:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcQXE-0006w5-B8; Mon, 27 Jan 2025 14:56:20 +0000
Received: by outflank-mailman (input) for mailman id 878003;
 Mon, 27 Jan 2025 14:56:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=20UT=UT=intel.com=jani.nikula@srs-se1.protection.inumbo.net>)
 id 1tcQXC-0006vx-O4
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 14:56:18 +0000
Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id da6e4289-dcbe-11ef-99a4-01e77a169b0f;
 Mon, 27 Jan 2025 15:56:15 +0100 (CET)
Received: from orviesa005.jf.intel.com ([10.64.159.145])
 by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 27 Jan 2025 06:56:13 -0800
Received: from bergbenj-mobl1.ger.corp.intel.com (HELO localhost)
 ([10.245.246.14])
 by orviesa005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 27 Jan 2025 06:56:01 -0800
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: da6e4289-dcbe-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=intel.com; i=@intel.com; q=dns/txt; s=Intel;
  t=1737989775; x=1769525775;
  h=from:to:cc:subject:in-reply-to:references:date:
   message-id:mime-version;
  bh=jgZ2GO8S3cXCdWyE6ZvOdFoqm0rhCqZC3ICQKad44uQ=;
  b=WVed1oKVFkzK/oETPO0J8VpsIwi4ypJTg0lX+AcJEgqH+erXdJNaC/zx
   vwuxJ5EvFrKw8crBjfrH3OrZkmYyiIBfNFMF7HidrQkt6uq0J8zqSAp/C
   45ZUNEiKIjk56k4gUxBaq3cmZw4dCPXjJfc0nYZR7zJGhVo2kmA6NEUXR
   0KWBG3Cls9htsZqhlU+aXWYz+V2nSgl8rO7BSXBFLVrHPboFTM4jos7U7
   sXSVvlfFUG6DsyEBbPRooxxmuhyYGXhs3SfVRgtB3m5OhDLEzWHgORxHb
   nG6Ys7jT0v1Ol5wgE5vgBrxk+WOrx/f94U1RMMbUu5Eo/yUWua9d7E6Dh
   w==;
X-CSE-ConnectionGUID: PPON44NnRBuQKp9ydgWp4Q==
X-CSE-MsgGUID: f0RySWx5RBqyp9yR5Sazgw==
X-IronPort-AV: E=McAfee;i="6700,10204,11328"; a="49104678"
X-IronPort-AV: E=Sophos;i="6.13,238,1732608000"; 
   d="scan'208";a="49104678"
X-CSE-ConnectionGUID: Z9Coz29cQ6uqfPwc/L4sHg==
X-CSE-MsgGUID: XE2pskZGQO2Q6A9y4rThjA==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="6.12,224,1728975600"; 
   d="scan'208";a="113598177"
From: Jani Nikula <jani.nikula@intel.com>
To: Joel Granados <joel.granados@kernel.org>, Ard Biesheuvel <ardb@kernel.org>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>, Thomas =?utf-8?Q?Wei=C3=9F?=
 =?utf-8?Q?schuh?=
 <linux@weissschuh.net>, Kees Cook <kees@kernel.org>, Luis Chamberlain
 <mcgrof@kernel.org>, linux-arm-kernel@lists.infradead.org,
 linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
 linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org,
 linux-crypto@vger.kernel.org, openipmi-developer@lists.sourceforge.net,
 intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
 intel-xe@lists.freedesktop.org, linux-hyperv@vger.kernel.org,
 linux-rdma@vger.kernel.org, linux-raid@vger.kernel.org,
 linux-scsi@vger.kernel.org, linux-serial@vger.kernel.org,
 xen-devel@lists.xenproject.org, linux-aio@kvack.org,
 linux-fsdevel@vger.kernel.org, netfs@lists.linux.dev,
 codalist@coda.cs.cmu.edu, linux-mm@kvack.org, linux-nfs@vger.kernel.org,
 ocfs2-devel@lists.linux.dev, fsverity@lists.linux.dev,
 linux-xfs@vger.kernel.org, io-uring@vger.kernel.org, bpf@vger.kernel.org,
 kexec@lists.infradead.org, linux-trace-kernel@vger.kernel.org,
 linux-hardening@vger.kernel.org, apparmor@lists.ubuntu.com,
 linux-security-module@vger.kernel.org, keyrings@vger.kernel.org, Song Liu
 <song@kernel.org>, "Steven Rostedt (Google)" <rostedt@goodmis.org>,
 "Martin K. Petersen" <martin.petersen@oracle.com>, "Darrick J. Wong"
 <djwong@kernel.org>, Corey Minyard <cminyard@mvista.com>
Subject: Re: Re: Re: [PATCH v2] treewide: const qualify ctl_tables where
 applicable
In-Reply-To: <f4lfo2fb7ajogucsvisfd5sg2avykavmkizr6ycsllcrco4mo3@qt2zx4zp57zh>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
References: <20250110-jag-ctl_table_const-v2-1-0000e1663144@kernel.org>
 <Z4+jwDBrZNRgu85S@li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com>
 <nslqrapp4v3rknjgtfk4cg64ha7rewrrg24aslo2e5jmxfwce5@t4chrpuk632k>
 <CAMj1kXEZPe8zk7s67SADK9wVH3cfBup-sAZSC6_pJyng9QT7aw@mail.gmail.com>
 <f4lfo2fb7ajogucsvisfd5sg2avykavmkizr6ycsllcrco4mo3@qt2zx4zp57zh>
Date: Mon, 27 Jan 2025 16:55:58 +0200
Message-ID: <87jzag9ugx.fsf@intel.com>
MIME-Version: 1.0
Content-Type: text/plain

On Mon, 27 Jan 2025, Joel Granados <joel.granados@kernel.org> wrote:
> On Wed, Jan 22, 2025 at 01:41:35PM +0100, Ard Biesheuvel wrote:
>> On Wed, 22 Jan 2025 at 13:25, Joel Granados <joel.granados@kernel.org> wrote:
>> >
>> > On Tue, Jan 21, 2025 at 02:40:16PM +0100, Alexander Gordeev wrote:
>> > > On Fri, Jan 10, 2025 at 03:16:08PM +0100, Joel Granados wrote:
>> > >
>> > > Hi Joel,
>> > >
>> > > > Add the const qualifier to all the ctl_tables in the tree except for
>> > > > watchdog_hardlockup_sysctl, memory_allocation_profiling_sysctls,
>> > > > loadpin_sysctl_table and the ones calling register_net_sysctl (./net,
>> > > > drivers/inifiniband dirs). These are special cases as they use a
>> > > > registration function with a non-const qualified ctl_table argument or
>> > > > modify the arrays before passing them on to the registration function.
>> > > >
>> > > > Constifying ctl_table structs will prevent the modification of
>> > > > proc_handler function pointers as the arrays would reside in .rodata.
>> > > > This is made possible after commit 78eb4ea25cd5 ("sysctl: treewide:
>> > > > constify the ctl_table argument of proc_handlers") constified all the
>> > > > proc_handlers.
>> > >
>> > > I could identify at least these occurences in s390 code as well:
>> > Hey Alexander
>> >
>> > Thx for bringing these to my attention. I had completely missed them as
>> > the spatch only deals with ctl_tables outside functions.
>> >
>> > Short answer:
>> > These should not be included in the current patch because they are a
>> > different pattern from how sysctl tables are usually used. So I will not
>> > include them.
>> >
>> > With that said, I think it might be interesting to look closer at them
>> > as they seem to be complicating the proc_handler (I have to look at them
>> > closer).
>> >
>> > I see that they are defining a ctl_table struct within the functions and
>> > just using the data (from the incoming ctl_table) to forward things down
>> > to proc_do{u,}intvec_* functions. This is very odd and I have only seen
>> > it done in order to change the incoming ctl_table (which is not what is
>> > being done here).
>> >
>> > I will take a closer look after the merge window and circle back with
>> > more info. Might take me a while as I'm not very familiar with s390
>> > code; any additional information on why those are being used inside the
>> > functions would be helpfull.
>> >
>> 
>> Using const data on the stack is not as useful, because the stack is
>> always mapped writable.
>> 
>> Global data structures marked 'const' will be moved into an ELF
>> section that is typically mapped read-only in its entirely, and so the
>> data cannot be modified by writing to it directly. No such protection
>> is possible for the stack, and so the constness there is only enforced
>> at compile time.
> I completely agree with you. No reason to use const within those
> functions. But why define those ctl_tables in function to begin with.
> Can't you just use the ones that are defined outside the functions?

You could have static const within functions too. You get the rodata
protection and function local scope, best of both worlds?

BR,
Jani.


-- 
Jani Nikula, Intel


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 15:09:06 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 15:09:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878012.1288183 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcQjV-0000iN-Em; Mon, 27 Jan 2025 15:09:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878012.1288183; Mon, 27 Jan 2025 15:09:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcQjV-0000iG-Bz; Mon, 27 Jan 2025 15:09:01 +0000
Received: by outflank-mailman (input) for mailman id 878012;
 Mon, 27 Jan 2025 15:08: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
 <SRS0=jIzP=UT=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tcQjT-0000iA-Rx
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 15:08:59 +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 a1b8a6ea-dcc0-11ef-99a4-01e77a169b0f;
 Mon, 27 Jan 2025 16:08:57 +0100 (CET)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-5d3e6274015so8550531a12.0
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 07:08:57 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab69095d6c8sm380218466b.104.2025.01.27.07.08.56
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 27 Jan 2025 07:08:56 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a1b8a6ea-dcc0-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1737990537; x=1738595337; 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=Pqg/8C+rq1Z7I8x8tR8XZfMwe9rEjvF9C4goOoYa7jk=;
        b=Kq097DiZrOuS0hyYDW1iUTSxxWiCkZdfF1uCoWAOek4k/+Phe8y5rYVxv7pdoHmxyE
         wIKvDo8orZwDY/3rpDZ7hejKDy+a51OCIsq51upZ6Zhp+Sjhj9MrRHRclEfYjZ3gzQJp
         6M2kD5zayRi3hbw4DRT+XfE9wLFiJ/SFWXkKM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737990537; x=1738595337;
        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=Pqg/8C+rq1Z7I8x8tR8XZfMwe9rEjvF9C4goOoYa7jk=;
        b=lepJF/cUJTNpqKBRTQiDTH15khoZhYYQdfQt9NXEJsTjm2W8nBp6sO4sFkXnBWZ0Ep
         tqa9t7ODNWW6RdTYkgPjRgTarHH77WZ0zi9GPNQNaAfRizZCx9UyFhv9x7VGSDJyXf5v
         e/y0xHRHRXftZHGwnQXhR5dJRw4cE1DKSFee5KAU/D9u8qBqgY/kyw6ncQixENbbl7Jf
         T4X46pijJ9bB7jco+lvy+fOi0mpX4iA0ziXwb5/NrWciFNpGWM1hgu+kp1sUkLUfwYHB
         EB6nFAkuyvsi+A4iDBPogEEUX7Ish9SocwOOW8isj+l5SVHdAInZUe+GiI362vKKvhLi
         x+Bw==
X-Forwarded-Encrypted: i=1; AJvYcCXkb3nQ6twew95pTOBSJ9wOaPinoXNtga3tC17aPhK+0IyexiNwedFWdza2diP8Mj74XRtAebBwd/w=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyYGCAl68z2igoAhBbKLpqnCHrYPJ4UDh6tWXdOqvKVePENI5nF
	sNekxk/vXj3QSPNOxE8CEUFldw36YQ8+egDrajFdQgsU2ZH+99BAQ4ttvrqfCwg=
X-Gm-Gg: ASbGncsbAZSCtbYMC7HkFMbrxyF1vUCbtkteClAnTehLJz5u0SKIVLGJkygaHf1tUAm
	99DNCkFwKr+nVSuw+l+yse1NCWx8JNoDXXGtH8ZfC4qAlCts71j2NtsWyZhIq1wKobTpif2j6bT
	bvZ5BtYykwMJnWPuo1S/hzasw2AdyActviS1gD9eu6z1rlygsBbIIlARu1MxAiSssM7ND8t61Qz
	EUvCS2a+QYpGTdHAPeNLDip36KF6l+x6RhwrCL0zoc+BKySxx30m0ClgFuxVMoBiAQ3ZWn/Z/kl
	Tt77gohzwQ==
X-Google-Smtp-Source: AGHT+IEcjQPQqADvho5JeuBDBOESkaQg+b+CsH7vZGYyRdvBPkdKfqHB0dYQ800ODIZpn1su0ZrFTw==
X-Received: by 2002:a17:907:7fa3:b0:aa6:707a:af59 with SMTP id a640c23a62f3a-ab38b4c6b1amr4181681866b.50.1737990537115;
        Mon, 27 Jan 2025 07:08:57 -0800 (PST)
Date: Mon, 27 Jan 2025 16:08:55 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Jiqian Chen <Jiqian.Chen@amd.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Huang Rui <ray.huang@amd.com>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v6] vpci: Add resizable bar support
Message-ID: <Z5ehh9IK3W8fLXIl@macbook.local>
References: <20250123035003.3797022-1-Jiqian.Chen@amd.com>
 <2f34ba33-070e-4c02-a7e5-71451553a23e@suse.com>
 <Z5ebGImjSz-55Nkj@macbook.local>
 <9a4ed1f8-0cbf-4df5-804e-78cc3ee1d777@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <9a4ed1f8-0cbf-4df5-804e-78cc3ee1d777@suse.com>

On Mon, Jan 27, 2025 at 03:52:31PM +0100, Jan Beulich wrote:
> On 27.01.2025 15:41, Roger Pau Monné wrote:
> > On Mon, Jan 27, 2025 at 03:20:40PM +0100, Jan Beulich wrote:
> >> On 23.01.2025 04:50, Jiqian Chen wrote:
> >>> v5->v6 changes:
> >>> * Changed "1UL" to "1ULL" in PCI_REBAR_CTRL_SIZE idefinition for 32 bit architecture.
> >>> * In rebar_ctrl_write used "bar - pdev->vpci->header.bars" to get index instead of reading
> >>>   from register.
> >>> * Added the index of BAR to error messages.
> >>> * Changed to "continue" instead of "return an error" when vpci_add_register failed.
> >>
> >> I'm not convinced this was a good change to make. While ...
> >>
> >>> +static int cf_check init_rebar(struct pci_dev *pdev)
> >>> +{
> >>> +    uint32_t ctrl;
> >>> +    unsigned int nbars;
> >>> +    unsigned int rebar_offset = pci_find_ext_capability(pdev->sbdf,
> >>> +                                                        PCI_EXT_CAP_ID_REBAR);
> >>> +
> >>> +    if ( !rebar_offset )
> >>> +        return 0;
> >>> +
> >>> +    if ( !is_hardware_domain(pdev->domain) )
> >>> +    {
> >>> +        printk(XENLOG_ERR "%pp: resizable BARs unsupported for unpriv %pd\n",
> >>> +               &pdev->sbdf, pdev->domain);
> >>> +        return -EOPNOTSUPP;
> >>> +    }
> >>> +
> >>> +    ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL(0));
> >>> +    nbars = MASK_EXTR(ctrl, PCI_REBAR_CTRL_NBAR_MASK);
> >>> +    for ( unsigned int i = 0; i < nbars; i++ )
> >>> +    {
> >>> +        int rc;
> >>> +        struct vpci_bar *bar;
> >>> +        unsigned int index;
> >>> +
> >>> +        ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL(i));
> >>> +        index = ctrl & PCI_REBAR_CTRL_BAR_IDX;
> >>> +        if ( index >= PCI_HEADER_NORMAL_NR_BARS )
> >>> +        {
> >>> +            printk(XENLOG_ERR "%pd %pp: too big BAR number %u in REBAR_CTRL\n",
> >>> +                   pdev->domain, &pdev->sbdf, index);
> >>> +            continue;
> >>> +        }
> >>> +
> >>> +        bar = &pdev->vpci->header.bars[index];
> >>> +        if ( bar->type != VPCI_BAR_MEM64_LO && bar->type != VPCI_BAR_MEM32 )
> >>> +        {
> >>> +            printk(XENLOG_ERR "%pd %pp: BAR%u is not in memory space\n",
> >>> +                   pdev->domain, &pdev->sbdf, index);
> >>> +            continue;
> >>> +        }
> >>
> >> ... for these two cases we can permit Dom0 direct access because the BAR
> >> isn't going to work anyway (as far as we can tell), ...
> >>
> >>> +        rc = vpci_add_register(pdev->vpci, vpci_hw_read32vpci_hw_read32, vpci_hw_write32,
> >>> +                               rebar_offset + PCI_REBAR_CAP(i), 4, NULL);
> >>> +        if ( rc )
> >>> +        {
> >>> +            /*
> >>> +             * TODO: for failed pathes, need to hide ReBar capability
> >>> +             * from hardware domain instead of returning an error.
> >>> +             */
> >>> +            printk(XENLOG_ERR "%pd %pp: BAR%u fail to add reg of REBAR_CAP rc=%d\n",
> >>> +                   pdev->domain, &pdev->sbdf, index, rc);
> >>> +            continue;
> >>> +        }
> >>> +
> >>> +        rc = vpci_add_register(pdev->vpci, vpci_hw_read32, rebar_ctrl_write,
> >>> +                               rebar_offset + PCI_REBAR_CTRL(i), 4, bar);
> >>> +        if ( rc )
> >>> +        {
> >>> +            printk(XENLOG_ERR "%pd %pp: BAR%u fail to add reg of REBAR_CTRL rc=%d\n",
> >>> +                   pdev->domain, &pdev->sbdf, index, rc);
> >>> +            continue;
> >>> +        }
> >>
> >> ... in these two cases we had an issue internally, and would hence wrongly
> >> allow Dom0 direct access (and in case it's the 2nd one that failed, in fact
> >> only partially direct access, with who knows what resulting inconsistencies).
> >>
> >> Only with this particular change undone:
> > R> Reviewed-by: Jan Beulich <jbeulich@suse.com>
> >>
> >> Otherwise you and Roger (who needs to at least ack the change anyway) will
> >> need to sort that out, with me merely watching.
> > 
> > Ideally errors here should be dealt with by masking the capability.
> > However Xen doesn't yet have that support.  The usage of continue is
> > to merely attempt to keep any possible setup hooks working (header,
> > MSI, MSI-X). Returning failure from init_rebar() will cause all
> > vPCI hooks to be removed, and thus the hardware domain to have
> > unmediated access to the device, which is likely worse than just
> > continuing here.
> 
> Hmm, true. Maybe with the exception of the case where the first reg
> registration works, but the 2nd fails. Since CTRL is writable but
> CAP is r/o (and data there is simply being handed through) I wonder
> whether we need to intercept CAP at all, and if we do, whether we
> wouldn't better try to register CTRL first.

Indeed, Jiqian is that a leftover from a previous version when writes
to CAP where ignored for being a read-only register?

The current adding of a handler with vpci_hw_{read,write}32() result
in the exact same behavior for a hardware domain, which is the only
domain where ReBAR will be exposed.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 15:34:07 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 15:34:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878023.1288193 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcR7i-0005oH-BD; Mon, 27 Jan 2025 15:34:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878023.1288193; Mon, 27 Jan 2025 15:34:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcR7i-0005oA-8D; Mon, 27 Jan 2025 15:34:02 +0000
Received: by outflank-mailman (input) for mailman id 878023;
 Mon, 27 Jan 2025 15:34:00 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=fFPb=UT=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tcR7g-0005o4-I7
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 15:34:00 +0000
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com
 [2a00:1450:4864:20::331])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2039834d-dcc4-11ef-a0e6-8be0dac302b0;
 Mon, 27 Jan 2025 16:33:58 +0100 (CET)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-4361b0ec57aso49155395e9.0
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 07:33:58 -0800 (PST)
Received: from localhost (0545937c.skybroadband.com. [5.69.147.124])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438bd4857b8sm134215005e9.15.2025.01.27.07.33.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 07:33:57 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2039834d-dcc4-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1737992038; x=1738596838; darn=lists.xenproject.org;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=g/JG8+dznbyTEKQARA7FgwYkkO81M5MTR4iCeQKqUns=;
        b=IUl7ZwcnaSnwn9Z7ALKgZudCDSYZBR6FjuTd2mJTBP2ehTyUT2L0zb2sS+NVAhBGyf
         zNmNk8pui5oIlfu+JVzV4Pfrdz6xvAQwE9l+hNM65g3YcfF5ahuHfvBWZ9aYrNYL2Lpd
         UOSSJxaTKCSqsTnMK+ViAd1Nzz+m20dgaFkuw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737992038; x=1738596838;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=g/JG8+dznbyTEKQARA7FgwYkkO81M5MTR4iCeQKqUns=;
        b=Ja3jfaLxh1lUHfrSig6jyDf3idJzAzAD7IauxSvcyPF43NGh1G1plbiEpxx/zduhwX
         K9O5Pd6usP29+V99bevcvegQLoQQZiZr9dGLn8/WV3HjRlkRnJzFxLj5cWlUyH31kIR4
         KecqWj0Lryj7J/d5TTp73MBJSiEzgWhWlBg5dvrc64tKjh0dWGqe4BDZIzMrLD/xV3iH
         hi48EY0OqvZLeI2NvoQXBC0FOse9RoADIqh2c+9wKqjXMETOupuK6JjrJIk3PcYhCGNL
         cNVY35tTRtIcI8hfsxJaf6Ao+xXSfGj9w1oYDdfOaBbvKeJDT/5abk42sKH/uhajcQAx
         y7RQ==
X-Forwarded-Encrypted: i=1; AJvYcCU1ouMP1hRr/LWmVo+kYUi8MKALrGalj2CHSZ4s6V4wbH2sJLJ3yhZK3TW9rBchuf/gaqUAuL2D1Qo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxEgZ/e8jY937yeFgXkCEVyBWxkg7eHgG8/s+RelT1dPQg67xPg
	PnTyVCSpip6fKSAz6pyNz9klHer2Zp4Nj6oQVA9+TudyPt+aXxySh/Ilz4fh1Do=
X-Gm-Gg: ASbGnctpPPuk1CUFQWesiO2ViVgnXEbf7CbIappqtzJUd3+qIzEfPHjUgdnQwJQRIco
	YzKOeeX1LF5ZzaG/7bN4wR4QDMxlvWLNuYmuwzxYv7/khlD0Fskc+epKqTSv1zx4kk3KC7wE6eI
	ngEH8D0wqX1+kfGyTa09Lllqj3Jzh+3ZhyRKAhdCS+kuuKh2cGEeOgiqp/d1F3infYtxM6gUDy7
	RTuFr49KhC8wrw0bL3cDP0GZ2y+jPADr+viS4qLPfKXIV2Bl91/m+o9L4USL9zXcgHmkwad5Re5
	laYNyUokXbEvD4CZ2jl9N/DMitSUD35Cphg=
X-Google-Smtp-Source: AGHT+IG4ZiV3i/zZDPIyfTA3JtgqyKJNi0W0OcnJncw/avcdNM6RBK9wHFqD3RT8GipTWru0/SY1rw==
X-Received: by 2002:a05:600c:4f84:b0:434:a90b:94fe with SMTP id 5b1f17b1804b1-438913ca9bamr396332895e9.10.1737992037910;
        Mon, 27 Jan 2025 07:33:57 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Mon, 27 Jan 2025 15:33:53 +0000
Message-Id: <D7CYR9ZNH26A.3596KYC81OTVU@cloud.com>
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>,
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v3 01/12] x86/xstate: Create map/unmap primitives for
 xsave areas
From: "Alejandro Vallejo" <alejandro.vallejo@cloud.com>
To: "Jan Beulich" <jbeulich@suse.com>
X-Mailer: aerc 0.18.2
References: <20250110132823.24348-1-alejandro.vallejo@cloud.com>
 <20250110132823.24348-2-alejandro.vallejo@cloud.com>
 <74ba0d8b-af2a-4fc7-891c-1a1305e71df7@suse.com>
In-Reply-To: <74ba0d8b-af2a-4fc7-891c-1a1305e71df7@suse.com>

Hi,

On Mon Jan 27, 2025 at 10:44 AM GMT, Jan Beulich wrote:
> On 10.01.2025 14:28, Alejandro Vallejo wrote:
> > Add infrastructure to simplify ASI handling. With ASI in the picture
> > we'll have several different means of accessing the XSAVE area of a
> > given vCPU, depending on whether a domain is covered by ASI or not and
> > whether the vCPU is question is scheduled on the current pCPU or not.
> >=20
> > Having these complexities exposed at the call sites becomes unwieldy
> > very fast. These wrappers are intended to be used in a similar way to
> > map_domain_page() and unmap_domain_page(); The map operation will
> > dispatch the appropriate pointer for each case in a future patch, while
> > unmap will remain a no-op where no unmap is required (e.g: when there's
> > no ASI) and remove the transient maping if one was required.
> >=20
> > Follow-up patches replace all uses of raw v->arch.xsave_area by this
> > mechanism in preparation to add the beforementioned dispatch logic to b=
e
> > added at a later time.
> >=20
> > Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
>
> Acked-by: Jan Beulich <jbeulich@suse.com>
> with one nit below.
>
> > --- a/xen/arch/x86/include/asm/xstate.h
> > +++ b/xen/arch/x86/include/asm/xstate.h
> > @@ -143,4 +143,46 @@ static inline bool xstate_all(const struct vcpu *v=
)
> >             (v->arch.xcr0_accum & XSTATE_LAZY & ~XSTATE_FP_SSE);
> >  }
> > =20
> > +/*
> > + * Fetch a pointer to a vCPU's XSAVE area
> > + *
> > + * TL;DR: If v =3D=3D current, the mapping is guaranteed to already ex=
ist.
> > + *
> > + * Despite the name, this macro might not actually map anything. The o=
nly case
> > + * in which a mutation of page tables is strictly required is when ASI=
=3D=3Don &&
> > + * v!=3Dcurrent. For everything else the mapping already exists and ne=
eds not
> > + * be created nor destroyed.
> > + *
> > + *                         +-----------------+--------------+
> > + *                         |   v =3D=3D current  | v !=3D current |
> > + *          +--------------+-----------------+--------------+
> > + *          | ASI  enabled | per-vCPU fixmap |  actual map  |
> > + *          +--------------+-----------------+--------------+
> > + *          | ASI disabled |             directmap          |
> > + *          +--------------+--------------------------------+
> > + *
> > + * There MUST NOT be outstanding maps of XSAVE areas of the non-curren=
t vCPU
> > + * at the point of context switch. Otherwise, the unmap operation will
> > + * misbehave.
> > + *
> > + * TODO: Expand the macro to the ASI cases after infra to do so is in =
place.
> > + *
> > + * @param v Owner of the XSAVE area
> > + */
> > +#define VCPU_MAP_XSAVE_AREA(v) ((v)->arch.xsave_area)
> > +
> > +/*
> > + * Drops the mapping of a vCPU's XSAVE area and nullifies its pointer =
on exit
> > + *
> > + * See VCPU_MAP_XSAVE_AREA() for additional information on the persist=
ence of
> > + * these mappings. This macro only tears down the mappings in the ASI=
=3Don &&
> > + * v!=3Dcurrent case.
> > + *
> > + * TODO: Expand the macro to the ASI cases after infra to do so is in =
place.
> > + *
> > + * @param v Owner of the XSAVE area
> > + * @param x XSAVE blob of v
> > + */
> > + #define VCPU_UNMAP_XSAVE_AREA(v, x) do { (void)(v); (x) =3D NULL; } w=
hile(0)
>
> The "while" still wants to conform to style, despite it being a kind of
> degenerate form. The overwhelming majority of instances we've got have at
> least a blank before the opening parenthesis. Many also have the ones
> inside.
>
> Jan

Sure, makes sense. I'll adjust it.

Cheers
Alejandro


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 15:42:20 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 15:42:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878035.1288202 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcRFg-0007rL-6l; Mon, 27 Jan 2025 15:42:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878035.1288202; Mon, 27 Jan 2025 15:42:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcRFg-0007rE-4I; Mon, 27 Jan 2025 15:42:16 +0000
Received: by outflank-mailman (input) for mailman id 878035;
 Mon, 27 Jan 2025 15:42: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
 <SRS0=fFPb=UT=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tcRFf-0007r8-73
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 15:42:15 +0000
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com
 [2a00:1450:4864:20::333])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 47a5f12b-dcc5-11ef-a0e6-8be0dac302b0;
 Mon, 27 Jan 2025 16:42:14 +0100 (CET)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-438a3216fc2so47604975e9.1
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 07:42:14 -0800 (PST)
Received: from localhost (0545937c.skybroadband.com. [5.69.147.124])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438bd4d29cesm138447475e9.35.2025.01.27.07.42.12
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 07:42:13 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 47a5f12b-dcc5-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1737992533; x=1738597333; darn=lists.xenproject.org;
        h=in-reply-to:references:subject:cc:to:from:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=gSkl1wl1YC4U0b4FAYXFX54TDNI/uy0DhxmaQ2DSBNk=;
        b=i7yyZsY7ARrukaenQejy4E3e3NTIYjh4bfgbNYJvmfvY60qSF2UnHc+D04xpc8gLN5
         wTh96pRqpJwLvCH0YEAaeHLxztSWqXg5jFH578RwSXLubQUIxbi+B/euwECqj7S1WJBL
         LkZMutF18tPvh0M3LcF+L6OBhTClv3nhHoQRQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737992533; x=1738597333;
        h=in-reply-to:references:subject:cc:to:from:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=gSkl1wl1YC4U0b4FAYXFX54TDNI/uy0DhxmaQ2DSBNk=;
        b=PHTO+N4pIrnJbVDWqniT/a4egoFdSlaqXL8hu60naIlj2KJ9fpF5muEp4GuRnMqUhN
         40tPDExSLOZ6oZmPVXcm0Q796nElyGIhJ3VN4hKFSfEqIulPNGPyF1I34seG34QQ1/M3
         aWooKgTrI3w07Aiz9YFP5EXXBG3qOaEFayvyOODQOjMYPMNL27sKs9g3KDo2wExpoNPw
         GO0OBo0OSJcNANTKGoUGiLscYyW64EIO5IkQ4SZ+ePMogMrfJeh/WEOkPIh0sZ/KCl11
         DYwKhuTXMqVqyJnKEfJWGdsMDCwLsZP4/4TUynFPcHRwhlcIcCc8RzcsMxiaTNYXBMdH
         MDVg==
X-Forwarded-Encrypted: i=1; AJvYcCWxXSbvqYa3xNjKo2X1Pik51vfNx/b/eUvxZEnxTmwDBhRlKrsSafAHuOenSAVCHV2P79S12fwA/UM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzjZUmt9Ta7C9S9sALWBCatSju2JdBr+viG3lrs968otmHmuZvo
	UKMnmXsULQ1wDFt+wfWQedwhtcqWxc1THETITswG86+6jCKr3yNLl5H9BnOjGDc=
X-Gm-Gg: ASbGnctCMmxAYnu6RMxbOy1h6lSTBV158Lfcacub1ni4/53fywwzCi0utXeieJX5DP7
	sHHU3CHthdnOmfWa2GSV31l/DuDPX6QnQhSwAkelqmpqdifusCsiRI5qPqVFNoCttW940eK+mhG
	g14Zu0POrbCmA7VIUG/lOagqureVS9CqiBeGk2zwYaCj2xEK8VhcioaODF/GW87D7x38EI9vO54
	vvlfkrWt3rHWD/PE3cavGkAP2UHwSoEpl+t+zJATlOxyXsmOD0lgE1cenLAq+oARAjiVIUsFzhi
	HbbzA0J+3T40uedSlXR6V1ayhvTQsNjBQEE=
X-Google-Smtp-Source: AGHT+IHNLljYHE20Xfl5207+xztZS+SWYcBTVHHouHQ63+TB8V9W/RCROcw8vYT56EwbfQ0UvW+PPA==
X-Received: by 2002:a05:600c:34c9:b0:436:f975:29d with SMTP id 5b1f17b1804b1-438913bffd9mr376568835e9.6.1737992533584;
        Mon, 27 Jan 2025 07:42:13 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Mon, 27 Jan 2025 15:42:09 +0000
Message-Id: <D7CYXLM3PCGY.2DYKXZEIQH1Y2@cloud.com>
From: "Alejandro Vallejo" <alejandro.vallejo@cloud.com>
To: "Jan Beulich" <jbeulich@suse.com>
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>,
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v3 08/12] x86/emulator: Refactor FXSAVE_AREA to use
 wrappers
X-Mailer: aerc 0.18.2
References: <20250110132823.24348-1-alejandro.vallejo@cloud.com>
 <20250110132823.24348-9-alejandro.vallejo@cloud.com>
 <bc5185ca-9001-4699-82d0-88e629ae6503@suse.com>
In-Reply-To: <bc5185ca-9001-4699-82d0-88e629ae6503@suse.com>

On Mon Jan 27, 2025 at 10:52 AM GMT, Jan Beulich wrote:
> On 10.01.2025 14:28, Alejandro Vallejo wrote:
> > Adds an UNMAP primitive to make use of vcpu_unmap_xsave_area() when
> > linked into xen. unmap is a no-op during tests.
> >=20
> > Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
>
> Acked-by: Jan Beulich <jbeulich@suse.com>

Thanks,

> despite ...
>
> > --- a/xen/arch/x86/x86_emulate/blk.c
> > +++ b/xen/arch/x86/x86_emulate/blk.c
> > @@ -11,9 +11,12 @@
> >      !defined(X86EMUL_NO_SIMD)
> >  # ifdef __XEN__
> >  #  include <asm/xstate.h>
> > -#  define FXSAVE_AREA ((void *)&current->arch.xsave_area->fpu_sse)
> > +/* Has a fastpath for `current`, so there's no actual map */
> > +#  define FXSAVE_AREA ((void *)VCPU_MAP_XSAVE_AREA(current))
> > +#  define UNMAP_FXSAVE_AREA(x) VCPU_UNMAP_XSAVE_AREA(current, x)
>
> ... the comment here kind of suggesting that ...
>
> >  # else
> >  #  define FXSAVE_AREA get_fpu_save_area()
> > +#  define UNMAP_FXSAVE_AREA(x) ((void)(x))
>
> ... use of this new construct is solely decoration, and could hence as
> well be omitted.
>
> Jan

It seems like a dangerous proposition to abuse knowledge of an implementati=
on
in order to skip parts of its interface. The fact that no such map is requi=
red
at this point in x86_emulate does not mean it never will be. Predicting the
future is hard, but being consistent today is less so (imo).

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 15:43:01 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 15:43:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878042.1288213 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcRGP-0008Ln-Fv; Mon, 27 Jan 2025 15:43:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878042.1288213; Mon, 27 Jan 2025 15:43:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcRGP-0008Le-DD; Mon, 27 Jan 2025 15:43:01 +0000
Received: by outflank-mailman (input) for mailman id 878042;
 Mon, 27 Jan 2025 15:43:00 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=N5Z6=UT=infradead.org=willy@srs-se1.protection.inumbo.net>)
 id 1tcRGO-0008Km-03
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 15:43:00 +0000
Received: from casper.infradead.org (casper.infradead.org
 [2001:8b0:10b:1236::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 617af748-dcc5-11ef-99a4-01e77a169b0f;
 Mon, 27 Jan 2025 16:42:58 +0100 (CET)
Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat
 Linux)) id 1tcRG3-00000009b8r-2Zcd; Mon, 27 Jan 2025 15:42:39 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 617af748-dcc5-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version:
	References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:
	Content-Transfer-Encoding:Content-ID:Content-Description;
	bh=754tTQ0Xv0FV1pAPiQ7XMzOqvV5Ru3eT2/4MtIxHkKc=; b=Pyozw0tsKLD9gp97o+N6ZbHkTo
	Il8/2Vpa4F0aqTQ5eLNtncdojFavxqC+3hOoMyt2pPZYgpxoa7oSXp+1z19h2FwdJ9ksectEr6L5y
	pdndzuM9IJbuYbMGyY8OnttTeia0ZsfUEQN3vE3Kvu3ywzVzVm7PiaoVN1j+XGx7cGtNMyIWcHM2K
	IHU9EJmiTnsw2atKedPjlIYgnndG3plYffG/psV0clxoDlPsLg9vBJ8MCt7RCyZQNR2Rl4uIk2hOI
	SGpvgckCCBw+KC2Pto4K/lzMPYNt+Lyqoqjs99RL8H5P/AQH7nlJDuMDpJ1IZ/IMsyAIp8YsG+ytq
	PlpOQ/eA==;
Date: Mon, 27 Jan 2025 15:42:39 +0000
From: Matthew Wilcox <willy@infradead.org>
To: Jani Nikula <jani.nikula@intel.com>
Cc: Joel Granados <joel.granados@kernel.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Alexander Gordeev <agordeev@linux.ibm.com>,
	Thomas =?iso-8859-1?Q?Wei=DFschuh?= <linux@weissschuh.net>,
	Kees Cook <kees@kernel.org>, Luis Chamberlain <mcgrof@kernel.org>,
	linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,
	linux-s390@vger.kernel.org, linux-crypto@vger.kernel.org,
	openipmi-developer@lists.sourceforge.net,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	intel-xe@lists.freedesktop.org, linux-hyperv@vger.kernel.org,
	linux-rdma@vger.kernel.org, linux-raid@vger.kernel.org,
	linux-scsi@vger.kernel.org, linux-serial@vger.kernel.org,
	xen-devel@lists.xenproject.org, linux-aio@kvack.org,
	linux-fsdevel@vger.kernel.org, netfs@lists.linux.dev,
	codalist@coda.cs.cmu.edu, linux-mm@kvack.org,
	linux-nfs@vger.kernel.org, ocfs2-devel@lists.linux.dev,
	fsverity@lists.linux.dev, linux-xfs@vger.kernel.org,
	io-uring@vger.kernel.org, bpf@vger.kernel.org,
	kexec@lists.infradead.org, linux-trace-kernel@vger.kernel.org,
	linux-hardening@vger.kernel.org, apparmor@lists.ubuntu.com,
	linux-security-module@vger.kernel.org, keyrings@vger.kernel.org,
	Song Liu <song@kernel.org>,
	"Steven Rostedt (Google)" <rostedt@goodmis.org>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	"Darrick J. Wong" <djwong@kernel.org>,
	Corey Minyard <cminyard@mvista.com>
Subject: Re: Re: Re: [PATCH v2] treewide: const qualify ctl_tables where
 applicable
Message-ID: <Z5epb86xkHQ3BLhp@casper.infradead.org>
References: <20250110-jag-ctl_table_const-v2-1-0000e1663144@kernel.org>
 <Z4+jwDBrZNRgu85S@li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com>
 <nslqrapp4v3rknjgtfk4cg64ha7rewrrg24aslo2e5jmxfwce5@t4chrpuk632k>
 <CAMj1kXEZPe8zk7s67SADK9wVH3cfBup-sAZSC6_pJyng9QT7aw@mail.gmail.com>
 <f4lfo2fb7ajogucsvisfd5sg2avykavmkizr6ycsllcrco4mo3@qt2zx4zp57zh>
 <87jzag9ugx.fsf@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87jzag9ugx.fsf@intel.com>

On Mon, Jan 27, 2025 at 04:55:58PM +0200, Jani Nikula wrote:
> You could have static const within functions too. You get the rodata
> protection and function local scope, best of both worlds?

timer_active is on the stack, so it can't be static const.

Does this really need to be cc'd to such a wide distribution list?


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 15:44:03 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 15:44:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878048.1288223 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcRHN-0000SH-PF; Mon, 27 Jan 2025 15:44:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878048.1288223; Mon, 27 Jan 2025 15:44:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcRHN-0000SA-MD; Mon, 27 Jan 2025 15:44:01 +0000
Received: by outflank-mailman (input) for mailman id 878048;
 Mon, 27 Jan 2025 15:44:00 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=fFPb=UT=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tcRHM-0000S2-8V
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 15:44:00 +0000
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com
 [2a00:1450:4864:20::434])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 863c4ba6-dcc5-11ef-a0e6-8be0dac302b0;
 Mon, 27 Jan 2025 16:43:59 +0100 (CET)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-3862d161947so2377937f8f.3
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 07:43:59 -0800 (PST)
Received: from localhost (0545937c.skybroadband.com. [5.69.147.124])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438bd48574csm137098645e9.9.2025.01.27.07.43.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 07:43:58 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 863c4ba6-dcc5-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1737992639; x=1738597439; darn=lists.xenproject.org;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=AuMOHJudoXPgzPtgSV+ojiBsyso+cl8f7sg2TFlWHh0=;
        b=OkUue7ZhSFRPUzKVBsvlSkMg66Fx4EnNbOAYvARwOChk0JhZ3FKTSbJHXD6pjx6pr2
         JPzcKCeLgzKxSZuOFGTkKZRFJILI9wcrjD055/8PbgwOrr3SqFYWZguFkrse72HwVCML
         mzkpe+1hhD5eNx2qo/RqfiD4C7WgMrXKBho+c=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737992639; x=1738597439;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=AuMOHJudoXPgzPtgSV+ojiBsyso+cl8f7sg2TFlWHh0=;
        b=dF0zXhnijY1auYfgZE6I1dnNAa8pO/emAcwZ/VURE6uQaJTYAC/CJV+NKgAjza798E
         53n6BLwC6XqML8KHKuiFOm+s5MKWDcFAVp4WP2iJDQXg2WSPdx+aWqVNUY47lxfljORz
         rgOJry4wOWSgGJ/UFTTNFXrXM/hNpxGY5nFdWgzc6WmA5Y5uhxRi6WTlZt2f8zi4/iCh
         ticMiJt8Y84r1UierCK9Yy0UmNVlI9mKaqLA+vDDr467PMsYjhINOiphMKt55Y2c9G13
         +izzQxnogmPRq0thqQpAyJB25BcD6jA6JxRL5s219bZx5f9dti16NAOWRGfHRDZC0o9h
         q8ew==
X-Forwarded-Encrypted: i=1; AJvYcCW/Hp4LxEPvyBxc9FrM27EaKfwNi9Ww2pwsWvbcg0w3Y6AZB2qExQZaxd3ueJ3FhAJX30HWE+zLACY=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz50Z9yHZw95xy0EZgN9oGwW58kZteqJ2nnVpAFwwzR1mSLekjf
	CiPthhwK+VJWLZk9/ONyPmzK/A0fxHN4G3kONzcv7UTaMaeUvgbo/XsXtvMDbH0=
X-Gm-Gg: ASbGncu7GOMMK953OGHUK48IOr7jgVqPgdrxM9i5KG4hSEQFtyy7y0kC9JqMCF+d0+4
	TL6It6O43SVQQ3IBN6wAcmTGOKpXGmqSf6sa5h0ZCGSh6tacSyBySGb5Pj19IkNp35jcZp27waJ
	GJOErjjXt/snGeETugkXh+xXQGneyKDIqAivp3EGFAP2oj+Cmk++/rhJZylY1dKw2iyQL/Lu+rS
	bz8axkTAFji7zzXvkeSWXsoX7vBdRDG0KLGIWbF8KRSkxLgjZhDXDl0nlqz+pgl5Ynu7252OLjh
	SerQDbxcvebr67FfpPQI6VLkVN++KE+BJjc=
X-Google-Smtp-Source: AGHT+IE28Ua4x5CtYdEPb/xGIcmnu7/aDKftHQsHftpAeED79woDN2BQ2y+mt59dCALNsoLEIWl3Ow==
X-Received: by 2002:a05:6000:1888:b0:385:fb59:8358 with SMTP id ffacd0b85a97d-38bf57bd745mr33693302f8f.53.1737992638668;
        Mon, 27 Jan 2025 07:43:58 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Mon, 27 Jan 2025 15:43:54 +0000
Message-Id: <D7CYYY32L980.13KVUVEGKDHK@cloud.com>
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>,
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v3 10/12] x86/fpu: Pass explicit xsave areas to
 fpu_(f)xsave()
From: "Alejandro Vallejo" <alejandro.vallejo@cloud.com>
To: "Jan Beulich" <jbeulich@suse.com>
X-Mailer: aerc 0.18.2
References: <20250110132823.24348-1-alejandro.vallejo@cloud.com>
 <20250110132823.24348-11-alejandro.vallejo@cloud.com>
 <5c0f2096-32ec-4d08-83be-6153f4a637e3@suse.com>
In-Reply-To: <5c0f2096-32ec-4d08-83be-6153f4a637e3@suse.com>

On Mon Jan 27, 2025 at 11:01 AM GMT, Jan Beulich wrote:
> On 10.01.2025 14:28, Alejandro Vallejo wrote:
> > No functional change.
> >=20
> > Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
> > ---
> > v2->v3:
> >   * const-ified v in fpu_fxsave() (missing in v2)
>
> Sadly this has rendered ...
>
> > --- a/xen/arch/x86/i387.c
> > +++ b/xen/arch/x86/i387.c
> > @@ -129,7 +129,7 @@ static inline uint64_t vcpu_xsave_mask(const struct=
 vcpu *v)
> >  }
> > =20
> >  /* Save x87 extended state */
> > -static inline void fpu_xsave(struct vcpu *v)
> > +static inline void fpu_xsave(const struct vcpu *v, struct xsave_struct=
 *xsave_area)
>
> ... this line too long now. With it suitably wrapped (possibly doable whi=
le
> committing, if no other reason for a v4 appears)

Bah, yes. You're right. I don't mind it being adjusted on commit.

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

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 15:48:13 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 15:48:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878059.1288232 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcRLN-00013H-8f; Mon, 27 Jan 2025 15:48:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878059.1288232; Mon, 27 Jan 2025 15:48:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcRLN-00013A-5E; Mon, 27 Jan 2025 15:48:09 +0000
Received: by outflank-mailman (input) for mailman id 878059;
 Mon, 27 Jan 2025 15:48:08 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=fFPb=UT=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tcRLM-000134-6K
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 15:48:08 +0000
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com
 [2a00:1450:4864:20::436])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 199566fd-dcc6-11ef-99a4-01e77a169b0f;
 Mon, 27 Jan 2025 16:48:06 +0100 (CET)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-3862b40a6e0so3328333f8f.0
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 07:48:06 -0800 (PST)
Received: from localhost (0545937c.skybroadband.com. [5.69.147.124])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38c2a1c402esm11566456f8f.97.2025.01.27.07.48.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 07:48:05 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 199566fd-dcc6-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1737992886; x=1738597686; darn=lists.xenproject.org;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=3HwOUrFPP3C74s2uL0aHvL48yitbfvYFsp4Fk1YJxfg=;
        b=Xytr+TyzaUYxC8nPo04CYZkh2bYkVETX9oa5rW9unRSryAjsG5OZpDocZx3I5BsXqt
         GVmk+EyDYKocOBH7/hG05zQ3vPMYNPD8DDp5jV1Q+5nibBuQ36SsWGAXjO/wjuv2mvcz
         5tOJl3CN8Rk88i67Flq7oZ64qucWC3GAwjpGc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737992886; x=1738597686;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=3HwOUrFPP3C74s2uL0aHvL48yitbfvYFsp4Fk1YJxfg=;
        b=UNqFNDclW3JS/o4g6p1KKsF5lASILAbpRIdi8T2fYjCL1j3VVcDbHgFTJ8n54tgIE7
         QEgLJ2Aowe+oOZ/izWH5mSDgUQWgb39/oNUJatVayV0YLt+6rxQ0r0szlPmavRQ4SLoq
         KyVh4Nhnvchzql4/0HL3+Nkw8AAm2qzEVb1nTEqqS8lg8l/MsKtQsgh6s628Fjt4h0A6
         QwhrCcS/A9fhKP2uAWxFu2JCB/rS3b7WFk5AoGRypdAzmh2kXzcHSv//xEnFiar4YwnD
         B9e8jZBZjNw7zftXCbBiRC3qQ7yQjNJRVoPdEbAhJ3TDARvP0KJNK3XQdaAsevtwZs5q
         2CoA==
X-Forwarded-Encrypted: i=1; AJvYcCUI6Uw2PPKpOYdzG5YUq/6Jh14En3zzZC6wkYxwIx0DsAKxPuLnrzzxZV2ero8IDQIaYghPU/VoIDY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YylOkJ4bUluqizHdHxw/wnfiMkVK7oJN91F3nqJExy8VXVElAUx
	IUGo061m9SDhX9fY2h+W0aI26BEzE9YRHq080zpFtrCOjEeQQhk9y8vIso3+aaM=
X-Gm-Gg: ASbGncuulCu24kN8lAhrOW5V///f5wtYJ4J18LsNvMGy2loHs9xnrCI4rjbxzM+38sB
	pYHkhRQQybvJOB1Imu0liZBxgimXnAycbCNPmIeJEZqyj54YMqI/ss3ygBNeq8wjQWjN1bIBGdh
	rYeoJ9n0WHZ5XecvgXh44BdFjtFyXWeBqezjFEnIhhW1MWmHYzHgl5WPKnE2bX1Clsly9dCtsij
	5Y1pFhhfFBYaHMEp5bYuCJaSoezejJ5oWx0Oke5hdOo/5he0mUgdOD2BVVAy2aalSsPBMVOGyf+
	yBi45HKkZOj+2uJ7AE+qC+l7NdD1GTbew18=
X-Google-Smtp-Source: AGHT+IH9BRN3AfKnxcDIKp+YtA+mU8O15XvSZ+2w2Llkgmxfmz2yoAu/cYRr5RzCOGrh8la4VDpCjw==
X-Received: by 2002:a05:6000:144b:b0:385:df43:223c with SMTP id ffacd0b85a97d-38bf565c029mr35524706f8f.13.1737992885848;
        Mon, 27 Jan 2025 07:48:05 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Mon, 27 Jan 2025 15:48:01 +0000
Message-Id: <D7CZ23KACJ16.A4EFWQ1X682K@cloud.com>
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>,
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v3 11/12] x86/fpu: Pass explicit xsave areas to
 fpu_(f)xrstor()
From: "Alejandro Vallejo" <alejandro.vallejo@cloud.com>
To: "Jan Beulich" <jbeulich@suse.com>
X-Mailer: aerc 0.18.2
References: <20250110132823.24348-1-alejandro.vallejo@cloud.com>
 <20250110132823.24348-12-alejandro.vallejo@cloud.com>
 <1f1ab2d4-73ad-4562-b3c5-0b423b56aed2@suse.com>
In-Reply-To: <1f1ab2d4-73ad-4562-b3c5-0b423b56aed2@suse.com>

Hi,

On Mon Jan 27, 2025 at 11:05 AM GMT, Jan Beulich wrote:
> On 10.01.2025 14:28, Alejandro Vallejo wrote:
> > No functional change.
> >=20
> > Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
>
> Acked-by: Jan Beulich <jbeulich@suse.com>
>
> > ---
> > v2->v3:
> >   * const-ified v in fpu_xrstor()
> >   * Removed v in fpu_fxrstor()
>
> On this basis the parameter could also be removed from fpu_fxsave(), by
> passing in fip_width instead.
>
> Jan

Could be, but there's not a whole lot of gain to be had? The access must be
done either way before or after the fpu_fxsave() call, and a parameter must=
 be
passed (be it fip_width or v). Passing the vCPU encapsulates the access of
fip_width where its actually used, which seems more desirable, I'd say.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 15:52:12 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 15:52:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878068.1288243 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcRPG-00033a-Oi; Mon, 27 Jan 2025 15:52:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878068.1288243; Mon, 27 Jan 2025 15:52:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcRPG-00033T-Kx; Mon, 27 Jan 2025 15:52:10 +0000
Received: by outflank-mailman (input) for mailman id 878068;
 Mon, 27 Jan 2025 15:52:08 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Hjlm=UT=kernel.org=will@srs-se1.protection.inumbo.net>)
 id 1tcRPE-000329-SE
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 15:52:08 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org
 [2604:1380:45d1:ec00::3])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a825fcfe-dcc6-11ef-99a4-01e77a169b0f;
 Mon, 27 Jan 2025 16:52:06 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id B5CFFA41826;
 Mon, 27 Jan 2025 15:50:17 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 87519C4CED2;
 Mon, 27 Jan 2025 15:51:50 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a825fcfe-dcc6-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1737993124;
	bh=lKShl/TiOp2ZoXo/jImChQXPJ2hMZLXx2pOut7WiptI=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=Opi/ZOMV/zfLovkaRrjcFN22SaJmB+XJGtnDJ/cIoGIjT25SkYRyAorU+UjcclWyd
	 6DePEaUZ/QK4W0yHLc5Kb3ieU/uOi+zRZdhIrfh5zorrG9bSfVDQc9h0dR9gO+3bHq
	 ul1VD9PJ3iJuekF+lfnqBztVCR/WhUeMwXxaqNSwUyFJREhVmoO8Vtntzw4FAiTB00
	 00OvDbjpP1jbVZyUSglO9BK2uxJ3fZYicWL3MsWiS1eDM68OxCFUf3tPPbIQwtET/k
	 cGteI6qIszlohfI51re4Bs3hb3htIsly4LrqymlfAEdhSawB5JdAEcLJmnZm2zRPZn
	 N7W92SLp2WhHA==
Date: Mon, 27 Jan 2025 15:51:47 +0000
From: Will Deacon <will@kernel.org>
To: Jann Horn <jannh@google.com>
Cc: Valentin Schneider <vschneid@redhat.com>, linux-kernel@vger.kernel.org,
	x86@kernel.org, virtualization@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev,
	linux-riscv@lists.infradead.org, linux-perf-users@vger.kernel.org,
	xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
	linux-arch@vger.kernel.org, rcu@vger.kernel.org,
	linux-hardening@vger.kernel.org, linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org, bpf@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com,
	Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.amakhalov@broadcom.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andy Lutomirski <luto@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Clark Williams <williams@redhat.com>,
	Yair Podemsky <ypodemsk@redhat.com>,
	Tomas Glozar <tglozar@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
	Kees Cook <kees@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Shuah Khan <shuah@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Miguel Ojeda <ojeda@kernel.org>, Alice Ryhl <aliceryhl@google.com>,
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
	Samuel Holland <samuel.holland@sifive.com>,
	Rong Xu <xur@google.com>,
	Nicolas Saenz Julienne <nsaenzju@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Yosry Ahmed <yosryahmed@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Jinghao Jia <jinghao7@illinois.edu>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: Re: [PATCH v4 29/30] x86/mm, mm/vmalloc: Defer
 flush_tlb_kernel_range() targeting NOHZ_FULL CPUs
Message-ID: <20250127155146.GB25757@willie-the-truck>
References: <20250114175143.81438-1-vschneid@redhat.com>
 <20250114175143.81438-30-vschneid@redhat.com>
 <CAG48ez1Mh+DOy0ysOo7Qioxh1W7xWQyK9CLGNU9TGOsLXbg=gQ@mail.gmail.com>
 <xhsmh34hhh37q.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
 <CAG48ez3H8OVP1GxBLdmFgusvT1gQhwu2SiXbgi8T9uuCYVK52w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAG48ez3H8OVP1GxBLdmFgusvT1gQhwu2SiXbgi8T9uuCYVK52w@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)

On Fri, Jan 17, 2025 at 04:52:19PM +0100, Jann Horn wrote:
> On Fri, Jan 17, 2025 at 4:25 PM Valentin Schneider <vschneid@redhat.com> wrote:
> > On 14/01/25 19:16, Jann Horn wrote:
> > > On Tue, Jan 14, 2025 at 6:51 PM Valentin Schneider <vschneid@redhat.com> wrote:
> > >> vunmap()'s issued from housekeeping CPUs are a relatively common source of
> > >> interference for isolated NOHZ_FULL CPUs, as they are hit by the
> > >> flush_tlb_kernel_range() IPIs.
> > >>
> > >> Given that CPUs executing in userspace do not access data in the vmalloc
> > >> range, these IPIs could be deferred until their next kernel entry.
> > >>
> > >> Deferral vs early entry danger zone
> > >> ===================================
> > >>
> > >> This requires a guarantee that nothing in the vmalloc range can be vunmap'd
> > >> and then accessed in early entry code.
> > >
> > > In other words, it needs a guarantee that no vmalloc allocations that
> > > have been created in the vmalloc region while the CPU was idle can
> > > then be accessed during early entry, right?
> >
> > I'm not sure if that would be a problem (not an mm expert, please do
> > correct me) - looking at vmap_pages_range(), flush_cache_vmap() isn't
> > deferred anyway.
> 
> flush_cache_vmap() is about stuff like flushing data caches on
> architectures with virtually indexed caches; that doesn't do TLB
> maintenance. When you look for its definition on x86 or arm64, you'll
> see that they use the generic implementation which is simply an empty
> inline function.
> 
> > So after vmapping something, I wouldn't expect isolated CPUs to have
> > invalid TLB entries for the newly vmapped page.
> >
> > However, upon vunmap'ing something, the TLB flush is deferred, and thus
> > stale TLB entries can and will remain on isolated CPUs, up until they
> > execute the deferred flush themselves (IOW for the entire duration of the
> > "danger zone").
> >
> > Does that make sense?
> 
> The design idea wrt TLB flushes in the vmap code is that you don't do
> TLB flushes when you unmap stuff or when you map stuff, because doing
> TLB flushes across the entire system on every vmap/vunmap would be a
> bit costly; instead you just do batched TLB flushes in between, in
> __purge_vmap_area_lazy().
> 
> In other words, the basic idea is that you can keep calling vmap() and
> vunmap() a bunch of times without ever doing TLB flushes until you run
> out of virtual memory in the vmap region; then you do one big TLB
> flush, and afterwards you can reuse the free virtual address space for
> new allocations again.
> 
> So if you "defer" that batched TLB flush for CPUs that are not
> currently running in the kernel, I think the consequence is that those
> CPUs may end up with incoherent TLB state after a reallocation of the
> virtual address space.
> 
> Actually, I think this would mean that your optimization is disallowed
> at least on arm64 - I'm not sure about the exact wording, but arm64
> has a "break before make" rule that forbids conflicting writable
> address translations or something like that.

Yes, that would definitely be a problem. There's also the more obvious
issue that the CnP ("Common not Private") feature of some Arm CPUs means
that TLB entries can be shared between cores, so the whole idea of using
a CPU's exception level to predicate invalidation is flawed on such a
system.

Will


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 16:28:24 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 16:28:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878080.1288254 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcRy8-0000lM-FE; Mon, 27 Jan 2025 16:28:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878080.1288254; Mon, 27 Jan 2025 16:28:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcRy8-0000lF-BH; Mon, 27 Jan 2025 16:28:12 +0000
Received: by outflank-mailman (input) for mailman id 878080;
 Mon, 27 Jan 2025 16:28:11 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=zo7v=UT=gmail.com=julien.grall.oss@srs-se1.protection.inumbo.net>)
 id 1tcRy7-0000l9-Em
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 16:28:11 +0000
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com
 [2a00:1450:4864:20::434])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b13e875b-dccb-11ef-99a4-01e77a169b0f;
 Mon, 27 Jan 2025 17:28:08 +0100 (CET)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-385de9f789cso3720263f8f.2
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 08:28:08 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b13e875b-dccb-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1737995288; x=1738600088; 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=Xxvar//qrbUI6q4rPrdTNpFfIopLXSamQzfZIfBFkDw=;
        b=Y/afrIbK6dVUhTN6FsUSxA1Jy9l49d9fYzYMed4hBVOqc0GJPjNW1mx1+Kh7yVpm4s
         YynPXA/0xgOyUDZ4X6AkSG7LJ87rf35KSwiijyOnckZxjEu04y/zbBY7idpwbyOdDS+k
         jWrrovFokv4u2D07ObEX+bZmNCxbAu80Tx2LTF85UBV+VCcRoz5BPgHWEbtbDVDAggGJ
         gm7o4t5dk1+X1MBLpWL2m6OG7bt2lXyyeeCXIX4uvcZt3BXr73q15HhZt5PdAqw2Izqp
         aZPu/rFirBQ35ZzOfwQfSbBhWu/M51j7Jf12Dy0lpAQDOZw+LlXuOdgLnQhOmdM5GtYy
         cP2Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737995288; x=1738600088;
        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=Xxvar//qrbUI6q4rPrdTNpFfIopLXSamQzfZIfBFkDw=;
        b=UAEOUxpEkIZzfpOkjjACfuhdA2WDMk6w5ELJsu1+KV8dYpJuANdPq690lH6c1ldUEU
         3DkSTVJicBf9EKZe7EU9swcIgTWV5zRMVThqcW5PFi2nBbIytxzRm774WdNmmRQ01NsG
         f2bKgEJxHcmRU7zy4dhI50qnVNXrBh4Rliz++5/ilG1jkR31rAI9uAIhrTXgtuf8cw0y
         gCvtai8a+XMgTK89M+UiQowkx0gA4w4zcElG2JU//GSYGuGvtDZ7v+gVGmes/CMWeGJh
         0eTmI9TJqr4wIu0o4I0A2sjo4IydA8LtJjf8VFCG1oFhYucsXE8bNVZrvbEeYwxjLJmq
         pZfA==
X-Gm-Message-State: AOJu0Yxrhou9hU7RhGtj0vw4xfsBbu+zEWTQqSzqg+K0tWWf7pbEOQnu
	ZoBdQA9eSTrDJiYvBph+d6hO6xi+7av6PwpUBSvv7uavz9ckvutcjGyhiNUgropdJ0v+/XPP/pJ
	e9mhjMWVYPY35boW7LGUwjMXyhUXwASGa
X-Gm-Gg: ASbGnctwnxpRkEPf8/gjuzfhKAM0aflhLJ9vr5uVB4xF1p1XAxApww1QIrm38lLXm7w
	eeNObFq5Zu3ixg3mMiy7h84yMCkgrmD7fWQdcH3lM95mJK/he0qA9PRUcbuOr
X-Google-Smtp-Source: AGHT+IHlQJg9IUyWq5KlgJoUKUSYcgPP3qFoPWnTLjzjGmj666QkddFqrq+b5uyqAp1y5X+kHw3kQZUlw5+VLsR/444=
X-Received: by 2002:a05:6000:1f85:b0:385:e374:be1 with SMTP id
 ffacd0b85a97d-38bf5662b18mr39288527f8f.13.1737995287266; Mon, 27 Jan 2025
 08:28:07 -0800 (PST)
MIME-Version: 1.0
References: <20250127104556.175641-1-michal.orzel@amd.com> <20250127104556.175641-2-michal.orzel@amd.com>
 <CAJ=z9a24=PE-3bhmZvfTaTgpdCXp9iDTWfoH-9F9-_OdkEf4Tg@mail.gmail.com> <32d42df5-08d9-4670-a571-ef315897514b@amd.com>
In-Reply-To: <32d42df5-08d9-4670-a571-ef315897514b@amd.com>
From: Julien Grall <julien.grall.oss@gmail.com>
Date: Mon, 27 Jan 2025 13:27:55 -0300
X-Gm-Features: AWEUYZmP-NHuOkusriDWnQSxy2T953O9I2IZglvnbEdNvhSG2GxYdtYS6Hb2j1o
Message-ID: <CAJ=z9a3gN0NyuvVQfEW2v9H9F5ZUhHB9+LvK4viQhSm6A=hauA@mail.gmail.com>
Subject: Re: [for-4.20][PATCH 1/2] device-tree: bootfdt: Fix build issue when CONFIG_PHYS_ADDR_T_32=y
To: Michal Orzel <michal.orzel@amd.com>
Cc: xen-devel@lists.xenproject.org, 
	Stefano Stabellini <sstabellini@kernel.org>, Bertrand Marquis <bertrand.marquis@arm.com>, 
	oleksii.kurochko@gmail.com
Content-Type: multipart/alternative; boundary="000000000000b80ee6062cb28f53"

--000000000000b80ee6062cb28f53
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 27 Jan 2025 at 09:52, Michal Orzel <michal.orzel@amd.com> wrote:

>
>
> On 27/01/2025 12:19, Julien Grall wrote:
> >
> >
> >
> >
> >
> > On Mon, 27 Jan 2025 at 07:46, Michal Orzel <michal.orzel@amd.com
> <mailto:michal.orzel@amd.com>> wrote:
> >
> >     On Arm32, when CONFIG_PHYS_ADDR_T_32 is set, a build failure is
> observed:
> >     common/device-tree/bootfdt.c: In function 'build_assertions':
> >     ./include/xen/macros.h:47:31: error: static assertion failed:
> "!(alignof(struct membanks) !=3D 8)"
> >        47 | #define BUILD_BUG_ON(cond) ({ _Static_assert(!(cond), "!("
> #cond ")"); })
> >           |                               ^~~~~~~~~~~~~~
> >     common/device-tree/bootfdt.c:31:5: note: in expansion of macro
> 'BUILD_BUG_ON'
> >        31 |     BUILD_BUG_ON(alignof(struct membanks) !=3D 8);
> >
> >     When CONFIG_PHYS_ADDR_T_32 is set, paddr_t is defined as unsigned
> long,
> >     therefore the struct membanks alignment is 4B. Fix it.
> >
> >
> > Usually, we add a BUILD_BUG_ON when other parts of the code rely on a
> specific property (in this case alignment). Can you explain in the commit
> message why the new check is still ok?
> Well, the change itself reflects the change in alignment requirement.
> When paddr_t is 64b (Arm64, Arm32 with PA=3D40b) the alignment is 8B.
> On Arm32 with PA=3D32b, the alignment is 4B because paddr_t is 4B.
>
> AFAICT you requested this check back then, because struct membanks
> contains flexible array member 'bank' of type struct membank.
> The alignment requirement of struct membanks becomes the requirement of
> struct membank whose largest type is paddr_t.


Reading this, it sounds like you want to check against the alignment of =C2=
=AB
struct membank =C2=BB. This is because the structure could gain a 64-bit fi=
eld
in the future and this would not be caught by the BUILD_BUG_ON.


> Let me know how you would like to have this written in commit msg.


I think it needs to be rephrased to make clear the alignment of  struct
membanks should be the same as struct membank.

Cheers,


>
> ~Michal
>
>

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

<div><br></div><div><br><div class=3D"gmail_quote gmail_quote_container"><d=
iv dir=3D"ltr" class=3D"gmail_attr">On Mon, 27 Jan 2025 at 09:52, Michal Or=
zel &lt;<a href=3D"mailto:michal.orzel@amd.com">michal.orzel@amd.com</a>&gt=
; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 27/01/2025 12:19, Julien Grall wrote:<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; On Mon, 27 Jan 2025 at 07:46, Michal Orzel &lt;<a href=3D"mailto:micha=
l.orzel@amd.com" target=3D"_blank">michal.orzel@amd.com</a> &lt;mailto:<a h=
ref=3D"mailto:michal.orzel@amd.com" target=3D"_blank">michal.orzel@amd.com<=
/a>&gt;&gt; wrote:<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0On Arm32, when CONFIG_PHYS_ADDR_T_32 is set, a buil=
d failure is observed:<br>
&gt;=C2=A0 =C2=A0 =C2=A0common/device-tree/bootfdt.c: In function &#39;buil=
d_assertions&#39;:<br>
&gt;=C2=A0 =C2=A0 =C2=A0./include/xen/macros.h:47:31: error: static asserti=
on failed: &quot;!(alignof(struct membanks) !=3D 8)&quot;<br>
&gt;=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A047 | #define BUILD_BUG_ON(cond) ({ _St=
atic_assert(!(cond), &quot;!(&quot; #cond &quot;)&quot;); })<br>
&gt;=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0^~~~~~~~~~~~~~<br>
&gt;=C2=A0 =C2=A0 =C2=A0common/device-tree/bootfdt.c:31:5: note: in expansi=
on of macro &#39;BUILD_BUG_ON&#39;<br>
&gt;=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A031 |=C2=A0 =C2=A0 =C2=A0BUILD_BUG_ON(a=
lignof(struct membanks) !=3D 8);<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0When CONFIG_PHYS_ADDR_T_32 is set, paddr_t is defin=
ed as unsigned long,<br>
&gt;=C2=A0 =C2=A0 =C2=A0therefore the struct membanks alignment is 4B. Fix =
it.<br>
&gt; <br>
&gt; <br>
&gt; Usually, we add a BUILD_BUG_ON when other parts of the code rely on a =
specific property (in this case alignment). Can you explain in the commit m=
essage why the new check is still ok?<br>
Well, the change itself reflects the change in alignment requirement.<br>
When paddr_t is 64b (Arm64, Arm32 with PA=3D40b) the alignment is 8B.<br>
On Arm32 with PA=3D32b, the alignment is 4B because paddr_t is 4B.<br>
<br>
AFAICT you requested this check back then, because struct membanks contains=
 flexible array member &#39;bank&#39; of type struct membank.<br>
The alignment requirement of struct membanks becomes the requirement of str=
uct membank whose largest type is paddr_t.</blockquote><div dir=3D"auto"><b=
r></div><div dir=3D"auto">Reading this, it sounds like you want to check ag=
ainst the alignment of =C2=AB struct membank =C2=BB. This is because the st=
ructure could gain a 64-bit field in the future and this would not be caugh=
t by the BUILD_BUG_ON.</div><div dir=3D"auto"><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex" dir=3D"auto"><br>
Let me know how you would like to have this written in commit msg.</blockqu=
ote><div dir=3D"auto"><br></div><div dir=3D"auto">I think it needs to be re=
phrased to make clear the alignment of =C2=A0struct membanks should be the =
same as struct membank.</div><div dir=3D"auto"><br></div><div dir=3D"auto">=
Cheers,</div><div dir=3D"auto"><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex" dir=
=3D"auto"><br>
<br>
~Michal<br>
<br>
</blockquote></div></div>

--000000000000b80ee6062cb28f53--


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 16:53:12 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 16:53:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878094.1288263 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcSMF-0005pW-Aj; Mon, 27 Jan 2025 16:53:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878094.1288263; Mon, 27 Jan 2025 16:53:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcSMF-0005pP-6U; Mon, 27 Jan 2025 16:53:07 +0000
Received: by outflank-mailman (input) for mailman id 878094;
 Mon, 27 Jan 2025 16:53: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
 <SRS0=8109=UT=linux.ibm.com=stefanb@srs-se1.protection.inumbo.net>)
 id 1tcSME-0005pJ-Kt
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 16:53:06 +0000
Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com
 [148.163.158.5]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2cb02da4-dccf-11ef-a0e6-8be0dac302b0;
 Mon, 27 Jan 2025 17:53:05 +0100 (CET)
Received: from pps.filterd (m0353725.ppops.net [127.0.0.1])
 by mx0a-001b2d01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 50RFuupL017907;
 Mon, 27 Jan 2025 16:52:49 GMT
Received: from pps.reinject (localhost [127.0.0.1])
 by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 44e0yybkpu-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Mon, 27 Jan 2025 16:52:49 +0000 (GMT)
Received: from m0353725.ppops.net (m0353725.ppops.net [127.0.0.1])
 by pps.reinject (8.18.0.8/8.18.0.8) with ESMTP id 50RGqmTQ018563;
 Mon, 27 Jan 2025 16:52:48 GMT
Received: from ppma21.wdc07v.mail.ibm.com
 (5b.69.3da9.ip4.static.sl-reverse.com [169.61.105.91])
 by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 44e0yybkps-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Mon, 27 Jan 2025 16:52:48 +0000 (GMT)
Received: from pps.filterd (ppma21.wdc07v.mail.ibm.com [127.0.0.1])
 by ppma21.wdc07v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 50RGHWxC019445;
 Mon, 27 Jan 2025 16:52:47 GMT
Received: from smtprelay02.dal12v.mail.ibm.com ([172.16.1.4])
 by ppma21.wdc07v.mail.ibm.com (PPS) with ESMTPS id 44db9mq59p-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Mon, 27 Jan 2025 16:52:47 +0000
Received: from smtpav03.wdc07v.mail.ibm.com (smtpav03.wdc07v.mail.ibm.com
 [10.39.53.230])
 by smtprelay02.dal12v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id
 50RGqkcI24248902
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Mon, 27 Jan 2025 16:52:47 GMT
Received: from smtpav03.wdc07v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id B962D5805C;
 Mon, 27 Jan 2025 16:52:46 +0000 (GMT)
Received: from smtpav03.wdc07v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id 4A96D5805D;
 Mon, 27 Jan 2025 16:52:43 +0000 (GMT)
Received: from [9.47.158.152] (unknown [9.47.158.152])
 by smtpav03.wdc07v.mail.ibm.com (Postfix) with ESMTP;
 Mon, 27 Jan 2025 16:52:43 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2cb02da4-dccf-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc
	:content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=pp1; bh=EpGiTx
	OESvwKogndESBTq4vX3ZF2JdGIo7rXHsC3nlc=; b=oyLO/kSgBZUMbLQuT+jemU
	QkjxHOXeJ5cwatS1zrDS89kRtVmsTCStqK0w+PK7tEH8IIAEMfZdGiTLSowWqrP2
	S+5AAGf0bQmPNHs+1nDhzO4oNGSZmLzuHssItO3pzE85LVWl8E1WYjBjAZn3Am+p
	O41ihD36wTt97sJ4i8HDnGEBL4tW2ZAvxByOKrkzUI/gheqPzpeMty+qkFErhF+m
	gkIp7OPcA1N7SEKIZoU0fiAeqEbAHLzCEAAzBTs294pDkfxLlVlloeg3GKxnReEj
	S/Vc9uWZRRBWsuxejQ7QbCP5mDG3dWm2l4shzLrtrhzxziskbvWMJZbHaV3mtuGw
	==
Message-ID: <bb2e0834-6423-4a82-8acd-ab387f2eda6b@linux.ibm.com>
Date: Mon, 27 Jan 2025 11:52:41 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 8/9] hw/tpm: Have TPM TIS sysbus device inherit from
 DYNAMIC_SYS_BUS_DEVICE
To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= <philmd@linaro.org>,
        qemu-devel@nongnu.org
Cc: Yi Liu <yi.l.liu@intel.com>, Markus Armbruster <armbru@redhat.com>,
        Eduardo Habkost <eduardo@habkost.net>,
        Anthony PERARD <anthony@xenproject.org>,
        Gustavo Romero <gustavo.romero@linaro.org>,
        Jason Wang
 <jasowang@redhat.com>, qemu-ppc@nongnu.org,
        "Michael S. Tsirkin" <mst@redhat.com>,
        Paolo Bonzini <pbonzini@redhat.com>, Alexander Graf <graf@amazon.com>,
        Richard Henderson <richard.henderson@linaro.org>,
        Stefan Berger <stefanb@linux.vnet.ibm.com>,
        Bernhard Beschow <shentey@gmail.com>,
        Stefano Stabellini <sstabellini@kernel.org>,
        Gerd Hoffmann <kraxel@redhat.com>,
        =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?=
 <berrange@redhat.com>,
        "Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
        xen-devel@lists.xenproject.org,
        Marcel Apfelbaum
 <marcel.apfelbaum@gmail.com>,
        Alex Williamson <alex.williamson@redhat.com>,
        Paul Durrant <paul@xen.org>,
        =?UTF-8?Q?Cl=C3=A9ment_Mathieu--Drif?= <clement.mathieu--drif@eviden.com>,
        =?UTF-8?Q?C=C3=A9dric_Le_Goater?= <clg@redhat.com>
References: <20250125181343.59151-1-philmd@linaro.org>
 <20250125181343.59151-9-philmd@linaro.org>
Content-Language: en-US
From: Stefan Berger <stefanb@linux.ibm.com>
In-Reply-To: <20250125181343.59151-9-philmd@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-TM-AS-GCONF: 00
X-Proofpoint-GUID: eDIefgyraSxWlHY4Qn6Zz-blAjgw2c7f
X-Proofpoint-ORIG-GUID: 4Iayg5JfcxV1D9ZLu3hYjCXEw3ZkMUOY
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34
 definitions=2025-01-27_08,2025-01-27_01,2024-11-22_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0
 phishscore=0 malwarescore=0 mlxscore=0 impostorscore=0 adultscore=0
 priorityscore=1501 mlxlogscore=999 suspectscore=0 spamscore=0
 clxscore=1011 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.19.0-2411120000 definitions=main-2501270131



On 1/25/25 1:13 PM, Philippe Mathieu-Daudé wrote:
> Because the TPM TIS sysbus device can be optionally plugged on the
> TYPE_PLATFORM_BUS_DEVICE, have it inherit TYPE_DYNAMIC_SYS_BUS_DEVICE.
> 
> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>

Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>

> ---
>   hw/tpm/tpm_tis_sysbus.c | 3 +--
>   1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/hw/tpm/tpm_tis_sysbus.c b/hw/tpm/tpm_tis_sysbus.c
> index ee0bfe9538e..4f187690a28 100644
> --- a/hw/tpm/tpm_tis_sysbus.c
> +++ b/hw/tpm/tpm_tis_sysbus.c
> @@ -133,7 +133,6 @@ static void tpm_tis_sysbus_class_init(ObjectClass *klass, void *data)
>       dc->vmsd  = &vmstate_tpm_tis_sysbus;
>       tc->model = TPM_MODEL_TPM_TIS;
>       dc->realize = tpm_tis_sysbus_realizefn;
> -    dc->user_creatable = true;
>       device_class_set_legacy_reset(dc, tpm_tis_sysbus_reset);
>       tc->request_completed = tpm_tis_sysbus_request_completed;
>       tc->get_version = tpm_tis_sysbus_get_tpm_version;
> @@ -142,7 +141,7 @@ static void tpm_tis_sysbus_class_init(ObjectClass *klass, void *data)
>   
>   static const TypeInfo tpm_tis_sysbus_info = {
>       .name = TYPE_TPM_TIS_SYSBUS,
> -    .parent = TYPE_SYS_BUS_DEVICE,
> +    .parent = TYPE_DYNAMIC_SYS_BUS_DEVICE,
>       .instance_size = sizeof(TPMStateSysBus),
>       .instance_init = tpm_tis_sysbus_initfn,
>       .class_init  = tpm_tis_sysbus_class_init,



From xen-devel-bounces@lists.xenproject.org Mon Jan 27 16:59:41 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 16:59:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878103.1288274 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcSSU-0006SB-Uc; Mon, 27 Jan 2025 16:59:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878103.1288274; Mon, 27 Jan 2025 16:59:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcSSU-0006S4-QI; Mon, 27 Jan 2025 16:59:34 +0000
Received: by outflank-mailman (input) for mailman id 878103;
 Mon, 27 Jan 2025 16:59: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 <SRS0=O4xJ=UT=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcSSU-0006Ry-5G
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 16:59:34 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 144719db-dcd0-11ef-a0e6-8be0dac302b0;
 Mon, 27 Jan 2025 17:59:32 +0100 (CET)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-aaf3c3c104fso233521366b.1
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 08:59:32 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5dc186285c6sm5750349a12.20.2025.01.27.08.59.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 08:59:31 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 144719db-dcd0-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737997172; x=1738601972; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=RxqKwMA9kOjUonsXlqNle56031jlQk8fyLQrE20GJ5w=;
        b=MKRvFF9sKn/bYYka3KZm7PuFeTueoF4UE99+l73PZNCmN14RC+PMOKqg5umZX6zaDV
         IgJQwUP1uohPC9yiGazBBVuqCNTSUITrlqJzDSQvHA4PrGBlj/0SdUCx7p+3WiOyZmmE
         0jCy40p3Q7utD0j6ll2nbZoXTPyE1JWbijm3SNs74LtL227o4BXU+R0Ozmj9daIFCc2L
         eNjhJFTxqfdqIPCz3sDTl+c68Op/GH5ZOk7SEvEYA5+xf4BjyQLTnfUF09MqNYZqZOjh
         ZYJAQ87rPw/QeupIkrJb2uF7iUKxFu/4p/6Kc9M1HKIrJFV6nYH+XCn+EmcQxUFz7PaK
         ssQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737997172; x=1738601972;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=RxqKwMA9kOjUonsXlqNle56031jlQk8fyLQrE20GJ5w=;
        b=BlZwXH9+pee2sU97FiFk0atBbNDQSOhly2mBCTRVFNLfCC6jZHPm5qfQ9+GcbF+PDC
         jaSnodGBfj4MAYXvaYXeVM5sinZn3EnL7Dc3NmDJPR4Cf1Ym/y746a0WV0+OPSyZexNn
         TR3MdBCeqcBfbnMVukUo6s9+c9d1InyzkWT01FBZpeU6qmthfIzARbRWkXEP92vAsXgV
         7RESnapfcC8isV8xdbqh/HcSiBUAWQCtQU4mUaJCi5uhGKD92cClxeP5VGanqFUBqbM/
         byfpWnC/yKaweQI7no28dn2Pss3WGvLe5WRX73hhXUg7unLhtEFBy+guCXL9Qca9bpxc
         m+sQ==
X-Forwarded-Encrypted: i=1; AJvYcCXntw5wiXwVDW7inQlyg4exF/APfsGieM8KAANcUIy/1rvMTYzvq9dOmJn+BBlwu7xflnsfdZMkr4M=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyd/ZjTX+LxZ5s8Z3Uo3P0Q2di6A0be+CzSBRS+g6dv3XJPQ/ci
	BhGPXlT59vLAixFtU5iTTwnchvWS8P5hHpYHNM19r5JGWTDtrU8BKR0PfX8T6g==
X-Gm-Gg: ASbGncvAAUbMcq5Ne9T7Kyh5mRV2kWb8Xs71BfbJDUJCoa5dXjtnS7evsO1B+nbVx+I
	n1C3SRyH2J1QtwIANa6KR+ltmbMdWLyBOZwXeXNXJE5Dxth3qEvCCyhb5KTFSvIFaOxHx87rTCU
	dC5RPzJoJ7aIpH4ibmx9yYZhUvfwY7Lg0z6Zo6G4WmW7httcaCnax7U+4AaGKa15GXmjUsqR7i4
	E6JpCSfpoJPHNq1fmK3TWByFRsOw2yrbDjgCsGu7eTr5Uro7/FoCAVxzF+ggaDw7w88eimrQ3Jd
	TnU+uZPoYlrk7ib1rhJf9ssVGMvAzrI4r5fibvCHqcxeZaI1+5FI53AYpkCaZp/xJQ==
X-Google-Smtp-Source: AGHT+IGYRl8beb/gqSBPL8OMTm64BCoorM3+PdU/77JFmS/Ah9C/+JD6VkmMqonIM1/s6Jl+LXgRPQ==
X-Received: by 2002:a17:907:97c1:b0:ab3:85f2:ff67 with SMTP id a640c23a62f3a-ab38b10d030mr3318681366b.16.1737997171910;
        Mon, 27 Jan 2025 08:59:31 -0800 (PST)
Message-ID: <e723d8a8-204d-4711-8206-df74c94c2ef0@suse.com>
Date: Mon, 27 Jan 2025 17:59:30 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 08/12] x86/emulator: Refactor FXSAVE_AREA to use
 wrappers
To: Alejandro Vallejo <alejandro.vallejo@cloud.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20250110132823.24348-1-alejandro.vallejo@cloud.com>
 <20250110132823.24348-9-alejandro.vallejo@cloud.com>
 <bc5185ca-9001-4699-82d0-88e629ae6503@suse.com>
 <D7CYXLM3PCGY.2DYKXZEIQH1Y2@cloud.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <D7CYXLM3PCGY.2DYKXZEIQH1Y2@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 27.01.2025 16:42, Alejandro Vallejo wrote:
> On Mon Jan 27, 2025 at 10:52 AM GMT, Jan Beulich wrote:
>> On 10.01.2025 14:28, Alejandro Vallejo wrote:
>>> Adds an UNMAP primitive to make use of vcpu_unmap_xsave_area() when
>>> linked into xen. unmap is a no-op during tests.
>>>
>>> Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
>>
>> Acked-by: Jan Beulich <jbeulich@suse.com>
> 
> Thanks,
> 
>> despite ...
>>
>>> --- a/xen/arch/x86/x86_emulate/blk.c
>>> +++ b/xen/arch/x86/x86_emulate/blk.c
>>> @@ -11,9 +11,12 @@
>>>      !defined(X86EMUL_NO_SIMD)
>>>  # ifdef __XEN__
>>>  #  include <asm/xstate.h>
>>> -#  define FXSAVE_AREA ((void *)&current->arch.xsave_area->fpu_sse)
>>> +/* Has a fastpath for `current`, so there's no actual map */
>>> +#  define FXSAVE_AREA ((void *)VCPU_MAP_XSAVE_AREA(current))
>>> +#  define UNMAP_FXSAVE_AREA(x) VCPU_UNMAP_XSAVE_AREA(current, x)
>>
>> ... the comment here kind of suggesting that ...
>>
>>>  # else
>>>  #  define FXSAVE_AREA get_fpu_save_area()
>>> +#  define UNMAP_FXSAVE_AREA(x) ((void)(x))
>>
>> ... use of this new construct is solely decoration, and could hence as
>> well be omitted.
> 
> It seems like a dangerous proposition to abuse knowledge of an implementation
> in order to skip parts of its interface. The fact that no such map is required
> at this point in x86_emulate does not mean it never will be. Predicting the
> future is hard, but being consistent today is less so (imo).

Entirely true. How likely do you consider it though that with a future
change altering that property, the comment above would be left in place
(and hence then be stale)? My take: Very likely, as long as the two
"current" uses wouldn't need altering.

Yet FTAOD: I'm not asking for any adjustment here, I'm merely mentioning
an observation.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 17:01:08 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 17:01:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878110.1288284 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcSU0-00080q-7r; Mon, 27 Jan 2025 17:01:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878110.1288284; Mon, 27 Jan 2025 17:01:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcSU0-00080j-2r; Mon, 27 Jan 2025 17:01:08 +0000
Received: by outflank-mailman (input) for mailman id 878110;
 Mon, 27 Jan 2025 17:01:07 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=O4xJ=UT=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcSTz-00080b-0C
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 17:01:07 +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 4b71eff4-dcd0-11ef-99a4-01e77a169b0f;
 Mon, 27 Jan 2025 18:01:05 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-ab69bba49e2so250952866b.2
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 09:01: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
 a640c23a62f3a-ab675e631a2sm602601766b.48.2025.01.27.09.01.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 09:01:02 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 4b71eff4-dcd0-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737997264; x=1738602064; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=E674n3a+gS5tMIjjNhkIj0q/e8xeaW+qEgcRrq2WvHA=;
        b=I1kCAX8ag3rLv3KBNQIBhi0tmyje/2A05mGqJ905ESzvlXi/Xr6dAZlIgfGEhtesKA
         yPOj6DJgRbRjJwMb9XF6koaFyhumGWl2PdiZsJTuRRkhCCHEWR6aN+ZSm3wQXrmJP1bM
         boDbtfz0LoGFmJK3AS8+hFv1zlOLs0k8e3gKqWdkdR7XPWXpU/v4IWl8aIOR8sPnguOF
         izxc693Eqcg6Kk4xZWKcwJbKPR1SYeEhIf8NAD1JrGwGhSXVQOxiioXQyb1OVPi/bV3B
         pFG2VbLbVnI1bwJCoMyB2GACV5h3QLGjM4abC1oCVD2IAJJLNg9uN63M7Vd/6pzENBHY
         wpUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737997264; x=1738602064;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=E674n3a+gS5tMIjjNhkIj0q/e8xeaW+qEgcRrq2WvHA=;
        b=Qw74wIaQV3SHhL5acj3AZ3zDS9URPmEOft7Y6CmoaA/wPmBuWVkm6Lho1NFRGagqEd
         6Em5NT0e4LWfz0Z6Pq+LNBFgz+05sCtDbVoToSuPbPRZOzMfpWdPyE/FM5mKS+FIFHe0
         2kfprl9lvtOd2rHw+EvwIlXasIFUwQh94WnrgZvxcXc1WcricoqvMwtaf/HjkVWCBpeq
         U1IQc7YytoouHX8FNYsauxKXXVU4hS/SNZkULJKscSyKfFeZJUn+m/Br7odtLGGge3Vw
         YcNsHcW8vHCXP10k2R0RWfi/0aQBb5SvYK/2gBSXzhaBKSyjfcyGcHNgBAUUnCvgpKpP
         zTpQ==
X-Forwarded-Encrypted: i=1; AJvYcCXmaLtXO3ZDGfw4RTQGZ/ch3cQ16sLUQbWavMuCoFFOTzb0QtGWf7lejMYoM0rINHgtlNZP/ekm88w=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzcbREw/pXkVCBwOIbJsUKYC3Daj4Dk1yO5t0B6VPFOxNT9qcR4
	yqZCF0p04Sw6IUrUbKaNbkBzDlv0FZRMzvFNosUHCfcOUjelYRnc2gB4odfpjWqq7frH/Bu4IOU
	=
X-Gm-Gg: ASbGncsEs30vzhRhiWujndV0A+kErufVfp++rO6EWZxB6qKhtVjeiP9P91MB5ZDzzHj
	5+iSxvAMumBzF2rSPV6PZ7SNDMx8LzgS6WtysD9Fy4337I+bRM4MIqQBzdS1dKM51zMVjtQDTB7
	1pWeiSISry+RZEFQo+UkfiNlWHUQrA6VREo5rFJv+6+mgKdY4gOF0xWf9Dn88YAkSoBfbU3Npl0
	LvUWyFe4Sq/MrOR0k9vN5yVJtIt+dUfdff1an7563FneeEnuJ2etTY1D/buDoZx42tle7P7vGEH
	Zp28s+5Baqozg2zVFxrJg9nbPIinUvkYsxbPq6RH8wh7/QJ/FiLA9Psn5vopxCxXqA==
X-Google-Smtp-Source: AGHT+IEVfvO2wIHdHAkS9swpCj5kZI3UsBU/tT8RIxigQ9UdHBQd06po5PnJGBV0kBNP7yr/UbhFBA==
X-Received: by 2002:a05:6402:3587:b0:5dc:100c:1560 with SMTP id 4fb4d7f45d1cf-5dc100c1768mr44550411a12.18.1737997262532;
        Mon, 27 Jan 2025 09:01:02 -0800 (PST)
Message-ID: <c4575574-45b0-4742-a58e-1fb9c5bd03bb@suse.com>
Date: Mon, 27 Jan 2025 18:01:01 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 11/12] x86/fpu: Pass explicit xsave areas to
 fpu_(f)xrstor()
To: Alejandro Vallejo <alejandro.vallejo@cloud.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20250110132823.24348-1-alejandro.vallejo@cloud.com>
 <20250110132823.24348-12-alejandro.vallejo@cloud.com>
 <1f1ab2d4-73ad-4562-b3c5-0b423b56aed2@suse.com>
 <D7CZ23KACJ16.A4EFWQ1X682K@cloud.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <D7CZ23KACJ16.A4EFWQ1X682K@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 27.01.2025 16:48, Alejandro Vallejo wrote:
> On Mon Jan 27, 2025 at 11:05 AM GMT, Jan Beulich wrote:
>> On 10.01.2025 14:28, Alejandro Vallejo wrote:
>>> No functional change.
>>>
>>> Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
>>
>> Acked-by: Jan Beulich <jbeulich@suse.com>
>>
>>> ---
>>> v2->v3:
>>>   * const-ified v in fpu_xrstor()
>>>   * Removed v in fpu_fxrstor()
>>
>> On this basis the parameter could also be removed from fpu_fxsave(), by
>> passing in fip_width instead.
> 
> Could be, but there's not a whole lot of gain to be had? The access must be
> done either way before or after the fpu_fxsave() call, and a parameter must be
> passed (be it fip_width or v). Passing the vCPU encapsulates the access of
> fip_width where its actually used, which seems more desirable, I'd say.

Not much of a gain indeed, largely for symmetry between the two sibling
functions.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 17:03:53 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 17:03:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878122.1288293 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcSWd-0000ZL-M2; Mon, 27 Jan 2025 17:03:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878122.1288293; Mon, 27 Jan 2025 17:03:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcSWd-0000ZE-ID; Mon, 27 Jan 2025 17:03:51 +0000
Received: by outflank-mailman (input) for mailman id 878122;
 Mon, 27 Jan 2025 17:03:50 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=fFPb=UT=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tcSWc-0000Z4-88
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 17:03:50 +0000
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com
 [2a00:1450:4864:20::32e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id acc5dd68-dcd0-11ef-99a4-01e77a169b0f;
 Mon, 27 Jan 2025 18:03:48 +0100 (CET)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-436ce2ab251so30799255e9.1
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 09:03:48 -0800 (PST)
Received: from localhost (0545937c.skybroadband.com. [5.69.147.124])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438bd54c066sm136564885e9.29.2025.01.27.09.03.46
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 09:03:47 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: acc5dd68-dcd0-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1737997428; x=1738602228; darn=lists.xenproject.org;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=StvOyVbjRO81DkbSfus+846CYLHL3edbVEiFZ8lYhz4=;
        b=e9ewXUTVCQmB8SnK7zYwoyM4o+NaHO0BCOfzxFYrLL7pJgzvfy6+zqf5mugPG9j8wp
         9HRESm4wsevInQByhIOwTD6ETawUMEAowF24t19JZGcjUctdHrFOhc9f/xU+w/GewISq
         ZSk/Qde/MI2/PjD3+WpyUD0B7QU2byPT7CUVs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737997428; x=1738602228;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=StvOyVbjRO81DkbSfus+846CYLHL3edbVEiFZ8lYhz4=;
        b=IalC3rnJoVe3fwMR3Xr83oAda3/+ECSlUDTucUGt6J4kirkwthMTdRpRvzWyg8dTbR
         3kSOm0Aao52xaBSK5v1Z17NXwyqhZ3vOSZH44SkRqV4Irw9Dp3lDmHIv4KGPd/YSXvXJ
         zkNBnO5yKMeCMwZlTmmHCyaLMQJFg0zLx+qbmxq2lK9M62ndMs8oyuGG6smpRvFVafuN
         sC3zkjPdqHGHdW2vAIMgrJU6Bp7p0kNPpgm+Gs95Cre0UudRXkQYGZhk5xM7vxuaX6Yx
         Rb7cl6HwhUInnC5UnCk1KoUerINMqpB9IbIRwkbjUcqwZHmDvsM68lM+XBZLcdzX05vf
         Dbpg==
X-Forwarded-Encrypted: i=1; AJvYcCU3sTHoxVZFjCDZ4kh78e0lo+BlbALkK2xnR45byfgyxLr0Eg2TQ0l6gnW+3rCYOXtbnw9IzQ3GXso=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzOb0/KTuEbhIElPzpmXdW8LOthlp6/Ke0gJYSW2q4DxL/zcsHh
	ShITJkKeriMiRNn+KIXVSxpJH2YlZ1I+eoXPOcpuTO8a9qrThkChVCzgxNrTcls=
X-Gm-Gg: ASbGncsjs+JO2oDrQifLg8lnQnkImxUBdKPjzyG9QnO4OzxK5ewWpn9HNTX+aBA3Ygq
	jdJE71s1ZhxwXI6n5GKBLL9JCL/MywfKbrOlIOZ/wNxe68HHNt42QP9j/mcJqMTfcdVibL251WR
	wDKu0qtuzKcMj1F7G6Xcgu4SG9GESxkBZfWvDHhKlTOGxNlnPYeymCYRQWAXMRP0EyP6jQBlKSm
	6iTyRSluSoewg1sJA5OZ7dr/avvMTcSTQOnZ5pPK7gVE15F3m3ChoGcKF40iGI6e4+CCUN8a4og
	pZtJuc7wmgYPcNSDmyWt7isOV5miRxujce0=
X-Google-Smtp-Source: AGHT+IGbWzBUP8ZLk5HFQXpkF7Yhiafl/ggA6sq2RKsfUZSC/36YgfxcCpNNMdObO+QgKr8SryDQ2w==
X-Received: by 2002:a05:600c:3b27:b0:434:a29d:6c71 with SMTP id 5b1f17b1804b1-43891438b58mr341548555e9.27.1737997427683;
        Mon, 27 Jan 2025 09:03:47 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Mon, 27 Jan 2025 17:03:43 +0000
Message-Id: <D7D0O214VJBT.18EFVF7AJACYQ@cloud.com>
Cc: "Stefano Stabellini" <sstabellini@kernel.org>, "Julien Grall"
 <julien@xen.org>, "Bertrand Marquis" <bertrand.marquis@arm.com>, "Volodymyr
 Babchuk" <Volodymyr_Babchuk@epam.com>, <oleksii.kurochko@gmail.com>
Subject: Re: [for-4.20][PATCH 2/2] xen/arm: Fix build issue when
 CONFIG_PHYS_ADDR_T_32=y
From: "Alejandro Vallejo" <alejandro.vallejo@cloud.com>
To: "Michal Orzel" <michal.orzel@amd.com>, <xen-devel@lists.xenproject.org>
X-Mailer: aerc 0.18.2
References: <20250127104556.175641-1-michal.orzel@amd.com>
 <20250127104556.175641-3-michal.orzel@amd.com>
In-Reply-To: <20250127104556.175641-3-michal.orzel@amd.com>

Hi,

On Mon Jan 27, 2025 at 10:45 AM GMT, Michal Orzel wrote:
> On Arm32, when CONFIG_PHYS_ADDR_T_32 is set, a build failure is observed:
> arch/arm/platforms/vexpress.c: In function 'vexpress_smp_init':
> arch/arm/platforms/vexpress.c:102:12: error: format '%lx' expects argumen=
t of type 'long unsigned int', but argument 2 has type 'long long unsigned =
int' [-Werror=3Dformat=3D]
>   102 |     printk("Set SYS_FLAGS to %"PRIpaddr" (%p)\n",
>
> When CONFIG_PHYS_ADDR_T_32 is set, paddr_t is defined as unsigned long.
> Commit 96f35de69e59 dropped __virt_to_maddr() which used paddr_t as a
> return type. Without a cast, the expression type is unsigned long long
> which causes the issue. Fix it.
>
> Fixes: 96f35de69e59 ("x86+Arm: drop (rename) __virt_to_maddr() / __maddr_=
to_virt()")
> Signed-off-by: Michal Orzel <michal.orzel@amd.com>
> ---
>  xen/arch/arm/include/asm/mm.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xen/arch/arm/include/asm/mm.h b/xen/arch/arm/include/asm/mm.=
h
> index f91ff088f6b1..a0d8e5afe977 100644
> --- a/xen/arch/arm/include/asm/mm.h
> +++ b/xen/arch/arm/include/asm/mm.h
> @@ -263,7 +263,7 @@ static inline void __iomem *ioremap_wc(paddr_t start,=
 size_t len)
> =20
>  #define virt_to_maddr(va) ({                                        \
>      vaddr_t va_ =3D (vaddr_t)(va);                                    \
> -    (va_to_par(va_) & PADDR_MASK & PAGE_MASK) | (va_ & ~PAGE_MASK); \
> +    (paddr_t)((va_to_par(va_) & PADDR_MASK & PAGE_MASK) | (va_ & ~PAGE_M=
ASK)); \
>  })
> =20
>  #ifdef CONFIG_ARM_32

Out of curiosity, why not make va_to_par() and __va_to_par() return paddr_t
rather than uint64_t? Then this cast would be unnecessary and the expressio=
n
end up as unsigned long.

That would also cover any other uses outside this macro.

Unless I'm missing something else...

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 17:08:02 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 17:08:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878130.1288304 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcSac-00017P-5r; Mon, 27 Jan 2025 17:07:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878130.1288304; Mon, 27 Jan 2025 17:07:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcSac-00017I-1p; Mon, 27 Jan 2025 17:07:58 +0000
Received: by outflank-mailman (input) for mailman id 878130;
 Mon, 27 Jan 2025 17:07:56 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=O4xJ=UT=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcSaa-00017C-S8
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 17:07:56 +0000
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
 [2a00:1450:4864:20::52e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3fd1e898-dcd1-11ef-99a4-01e77a169b0f;
 Mon, 27 Jan 2025 18:07:55 +0100 (CET)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-5d0d32cd31aso6882306a12.0
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 09:07: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
 a640c23a62f3a-ab6760fbb72sm607883566b.129.2025.01.27.09.07.54
 for <xen-devel@lists.xenproject.org>
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 09:07:54 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 3fd1e898-dcd1-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1737997674; x=1738602474; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:to:subject:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=hkWSPQfFGGALKROvEt8ur9Kvmpc0vvx3Pu+8NgfsJQ8=;
        b=IF1WYxE7DT0DPnqfJB7juhGVU7hBwzuIfgtqdMhgCm9ACQ0wGMaeHJSHgFbB2kIGP5
         AqILL2lEQWn1Tpz3/AhXFRVfKXjMa+BTMSNf3Pr3q5GsDWZoVkcytHX77tLurw6DKvt7
         UoyW5Re3G4QT06CN2e/3oN2lvCXN631F/JjNmK1PQJoXKt0G7DLGxKlZTNB8dQE3Vren
         2ohHGdhbRKaOkaEUC+Q1UFK8wGq8NktDKTcqPzjE6FDkv7loDZPTyGhXWU9gIPShaA8P
         vXNZMlSTwUpbiy47QbsAdN4Um3f8+F0dmz5pcBBHCAKj8T92+22MxASxQpArakIfnw1G
         g38Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737997674; x=1738602474;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=hkWSPQfFGGALKROvEt8ur9Kvmpc0vvx3Pu+8NgfsJQ8=;
        b=XP4+GvmJTXrfPVmqk2AMHHLWgldNMiGq+VreJ8rWYMLOnLZW/bfogjceB5t532cwsh
         eRUgVifcSmrX1HbhNCIzo90wls/whqqDupjNveWOwNPIRcOOvBzCZ9iE4/6KXhs8r2QW
         oMZI3jTe6H1iwA2F47fu4H7WZwFeJcOaUv4jNOQ53uh7Hny1IuEHTwH7FtmSxGPpYRBa
         vXQ+pC1SblWAtYQV1LtrcUpqV+ZnCxw/HDk+F9E1TqYyp45bbG4xbBxgdgU3RiwP0EyW
         d2naiqWJJrhEZFwu68QLmi79L2eDqi9hlCh/8Sz//68e4/MXTVhQcgOrgVqmcMzw9vqz
         iHGQ==
X-Gm-Message-State: AOJu0YwJFWJ5N5o+Ko7LsWJhN2AAmFCI2aARkxOToQwXb6OY30C5p8QN
	s68T0r/z3UdVN4BXS/4ysODLXpoCE6NrzTEn51nuJ1lq/21VXUAtI5lL6HfRsMGRsMxZ16pjYHA
	=
X-Gm-Gg: ASbGncs3KoFFu5yC3+eniMNAMfXF/Da0lq7aaNUSLlCRRvAfJaM7Ci6Oz1dYbpaD/yo
	VuVY510isAUI5/uf/F+AeghXySJZebHWFh3YY4nxZo4EOwwiF+WKHZBA+Xh57tukQ744W6a5fKW
	nQ0xNfoWJt9yBtruEq6+2Abj9T7IgbjvPTxJq8ZuJvERK99oM40MJmXMqdMhs6aAPNcwU7Kxohr
	JriYyyZUHvM/Nlxhl8HbBv7yEh7LeMMbCWoZNlDr64uSfLQ65Semf/eVz0Y/DbQ0paV8uCa39Dg
	U3RQPOevg0LeORhRaqPg/V/2Oj1ZFoIzdUiP42Z9686zG7c9ZCTW7vxHcgvv5qNaEfhQVjgSB/S
	R
X-Google-Smtp-Source: AGHT+IFlDaqcmM36p6m2nT3Q+BG6v9q4+UVWKaD/1m51bXegfjS47j1J1UrrX4U5TA6htHlKbeDPaw==
X-Received: by 2002:a05:6402:1e8e:b0:5dc:1059:6b2 with SMTP id 4fb4d7f45d1cf-5dc105a5ec1mr39324079a12.7.1737997674416;
        Mon, 27 Jan 2025 09:07:54 -0800 (PST)
Message-ID: <a4bd29bb-b0c5-43c6-812d-c4a612eba4d7@suse.com>
Date: Mon, 27 Jan 2025 18:07:53 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: xen | Failed pipeline for staging | 8306d773
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <6797bc1732efe_2ec90a4585b4@gitlab-sidekiq-catchall-v2-55c8c7cfb7-5j44d.mail>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <6797bc1732efe_2ec90a4585b4@gitlab-sidekiq-catchall-v2-55c8c7cfb7-5j44d.mail>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 27.01.2025 18:02, GitLab wrote:
> 
> 
> Pipeline #1642654016 has failed!
> 
> Project: xen ( https://gitlab.com/xen-project/hardware/xen )
> Branch: staging ( https://gitlab.com/xen-project/hardware/xen/-/commits/staging )
> 
> Commit: 8306d773 ( https://gitlab.com/xen-project/hardware/xen/-/commit/8306d773b03acec6062c0547ac05e3dd4a6960f6 )
> Commit Message: x86/PV: further harden guest memory accesses ag...
> Commit Author: Jan Beulich ( https://gitlab.com/jbeulich )
> 
> 
> Pipeline #1642654016 ( https://gitlab.com/xen-project/hardware/xen/-/pipelines/1642654016 ) triggered by Jan Beulich ( https://gitlab.com/jbeulich )
> had 2 failed jobs.
> 
> Job #8960344816 ( https://gitlab.com/xen-project/hardware/xen/-/jobs/8960344816/raw )
> 
> Stage: build
> Name: debian-bookworm-gcc-cppcheck
> Job #8960345099 ( https://gitlab.com/xen-project/hardware/xen/-/jobs/8960345099/raw )
> 
> Stage: test
> Name: adl-pci-pv-x86-64-gcc-debug

Both look to have failed due to testing infra networking issues; I've
restarted them.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 17:14:26 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 17:14:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878139.1288313 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcSgm-0003E6-PU; Mon, 27 Jan 2025 17:14:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878139.1288313; Mon, 27 Jan 2025 17:14:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcSgm-0003Dz-MU; Mon, 27 Jan 2025 17:14:20 +0000
Received: by outflank-mailman (input) for mailman id 878139;
 Mon, 27 Jan 2025 17:14:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=rEBS=UT=amd.com=Michal.Orzel@srs-se1.protection.inumbo.net>)
 id 1tcSgl-0003Dt-OM
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 17:14:19 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20621.outbound.protection.outlook.com
 [2a01:111:f403:2009::621])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 228af298-dcd2-11ef-99a4-01e77a169b0f;
 Mon, 27 Jan 2025 18:14:16 +0100 (CET)
Received: from BY5PR17CA0012.namprd17.prod.outlook.com (2603:10b6:a03:1b8::25)
 by LV3PR12MB9265.namprd12.prod.outlook.com (2603:10b6:408:215::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.22; Mon, 27 Jan
 2025 17:14:10 +0000
Received: from SN1PEPF0002529F.namprd05.prod.outlook.com
 (2603:10b6:a03:1b8:cafe::76) by BY5PR17CA0012.outlook.office365.com
 (2603:10b6:a03:1b8::25) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8377.23 via Frontend Transport; Mon,
 27 Jan 2025 17:14:09 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SN1PEPF0002529F.mail.protection.outlook.com (10.167.242.6) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8398.14 via Frontend Transport; Mon, 27 Jan 2025 17:14:09 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 27 Jan
 2025 11:14:08 -0600
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Mon, 27 Jan 2025 11:14:07 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 228af298-dcd2-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=VjlTPU5Bn0thS9IcsYLUMI6Xv9a9mF6+EY0topdREtc45t4k9V5yx6J2bJGGauwrwzv/uXPvWTSx1LfPyhoXN/hlOWBhEqxnmjURXYgsm15viaEzXhQC9yo5YNVksQz1enDE81E7nHv3bdw2OqGWV/O1LEayuhd8xL5egSCaGtut8SfMdsHHOj62xkGp6AOIJv+HQq+WLJaTCXMbX3nDk8rz2w9e1WsATefc56kcDRhrRcpnv8sC2sPSLsn+miD2zPHtxw6qS0W8sfIXPWkY1cKw3sBJGP5GEWPBi8c9gMQYCvY7fb7YL3Z9GVx5nDSBBjMT5wnJhcxbWS3CqHN1Nw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=EXis3nhLG8AF4MFQxXJYh6zaHOKEM8fpkYY5dwAURtI=;
 b=i/YBB5izRS98UM6hdexl1kzLIsmG7BZk8VTQ+NUhqF03FIwfn+n7Z36MTAcaOTZTGXuMZIljBE7Wd+SoUjR+xf51GF/OxnPjNFQxwHpC/t2So93lCjTi0JCqlXsieAX/4y2C4nZEOFEOponAyzd/UtlbkM+QlYOaedpo3FKUYZOpTA0dEK09xt3cJDN8WOxiJELMKQ5BFyYvtmaLiLO6UemVtwlYkl22ovAUS0Q3c0GvTCdHEIUUyW2k8GFGKN4VKgc8f1G/SHCqti/2cPeZ8sMkf0OnmuDL4f1wCrUc8xoJRf9mZMtoasDzJ18Ntqsc+V2ofNX1AouNu9fv0zfqmQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=cloud.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=EXis3nhLG8AF4MFQxXJYh6zaHOKEM8fpkYY5dwAURtI=;
 b=gn9nvGnWz6oSt5MUG/Z3lDA9fpJNwwJKRT/LOy7TsY4GMtbRt3jLhE72cH/M/vuSqglQEkU7hHILjFtaNtjMj9EpT5SInJfhOmDjqDQT6MEJrtgQbgnVy7ODsQgjwBdKk+VAi8zJuIUrkMTxed+wd+AojQfWvOaVzkOPe/lU9yQ=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <4788ed30-f182-4fd9-aad5-5faca3580e3b@amd.com>
Date: Mon, 27 Jan 2025 18:14:06 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [for-4.20][PATCH 2/2] xen/arm: Fix build issue when
 CONFIG_PHYS_ADDR_T_32=y
To: Alejandro Vallejo <alejandro.vallejo@cloud.com>,
	<xen-devel@lists.xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
	<julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>, Volodymyr
 Babchuk <Volodymyr_Babchuk@epam.com>, <oleksii.kurochko@gmail.com>
References: <20250127104556.175641-1-michal.orzel@amd.com>
 <20250127104556.175641-3-michal.orzel@amd.com>
 <D7D0O214VJBT.18EFVF7AJACYQ@cloud.com>
Content-Language: en-US
From: Michal Orzel <michal.orzel@amd.com>
In-Reply-To: <D7D0O214VJBT.18EFVF7AJACYQ@cloud.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB04.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF0002529F:EE_|LV3PR12MB9265:EE_
X-MS-Office365-Filtering-Correlation-Id: 3bc53cc8-1468-4e53-13ae-08dd3ef60329
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|82310400026|36860700013|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?ODFNV0F6bGlFbERnbDUrbzQ2TFFvSFhOVVlDU2lVRWdDeXg0TVlOUXNpNTBj?=
 =?utf-8?B?ckpsU0p0N044dGU3WlFTRmVrTXpaVjMxc05OZnd3Tmd5blJwOTdNa2tWMXhP?=
 =?utf-8?B?WFJlR0lpODRNMGFnclNscEJFUFViaG1vVDR3NytxWG1YdjlGbm9kY0JscnJw?=
 =?utf-8?B?dTFFTURqVnZFUWVLLyt5U3BvUDRidWlKaWp1YWVINVVqTklnVzgvc1lTdXQw?=
 =?utf-8?B?RWE4ZGltZ201OEY3ZnBPaGFlY2M1ZEV2Q2JPdW15VmtycHhwYk1RQlBpRHl1?=
 =?utf-8?B?WFZ5bW4vQmlONGFTektjb2MxblhrNktGWUxtcW9Fa0Y3YUU3MHl2QTVNamh6?=
 =?utf-8?B?R0tKVjZZaTRRM1FhWVBNSzlmUUpDOThlZmlnZ3VXR3FlZldwRUZRaVpZT0NN?=
 =?utf-8?B?RUkweXBQR2pZZHQ4NEJxT015MmM4R2s0eCttTlF0eUo0L0YvN1Z2UE9tVjJn?=
 =?utf-8?B?c2ZGQldNUEI1cElPK1RYTTlUZnNxcXcrWXc2aENwUkRBa2FkNzQ1RHZad3dG?=
 =?utf-8?B?Z3VHME1vNFl0c3ZrWnZ3dWJyRVRGV08zVllVMForOVdnVzRSNmNzR0xJMzN6?=
 =?utf-8?B?MkRlTkVxdmU1VUFEaVVGdjQxcDUyZk5PaE9BVGFiZ2FpY0hsNldWaEtkaEY2?=
 =?utf-8?B?RDhCWWljSDdrMDRmQkRqWm95enRVaTdGNkxadFcxNlROektkVDBsVVpoNFND?=
 =?utf-8?B?dFIzamphcVF6Y0tOV1k0YXozR3ArMTlFNGdkdWJzYTA3QmpQdmdQT0xpNWcv?=
 =?utf-8?B?dmZBcno0ajlRajgrMHQzUHhKUmRsdjgrTEJNSHNYVk1POFlGNFZNL0c3SnRX?=
 =?utf-8?B?VExsU3JyYXdsNk9kNVd3aXBnZVR0VGdDMmdJU05BTm9BU285ZWYxeGd0SVg1?=
 =?utf-8?B?YVJ1ODF4U0xKRUFEVGIzeXNhQVJpWXlaSzZueDArWDZZQWJZTTZLNG5UVXJW?=
 =?utf-8?B?SXYvVVJ1VVZCNnY1NmpyT2xiQXhWays1ODRtaVJXWjhKc1E2VCtMdVQyRktF?=
 =?utf-8?B?Z2N0bERHVGFTb3phUjZIWVpsQWVRQ3g1RzRTVS9BTGNuMUJNZU9tTEpsVkww?=
 =?utf-8?B?bC9ZazRxK0xaMUxMTDRqZld4NkhkcTVrbzVaUW5QTll6cXhzaCtoKzE5Vk1J?=
 =?utf-8?B?bHhSaGxWUGk0OGc1dHptUW03eXRNOStUWmplS1kwZGE0SnFuS2VhT21oMlAr?=
 =?utf-8?B?OVpobnlwR0lzcERYR1pnZzVWZ2tLMEc0M0o3NE9UYk9rS0gyT0JOb1VYSU90?=
 =?utf-8?B?R2lRTVdiM0VuQnVwZUE2aFp1aU5rOG9tUmJjb2hvaGRIRWVZOXF4U1JTOUlp?=
 =?utf-8?B?MlJpUnBnTjh6dU9IMUhMK0F3MVJKSExsbDhLd0lITkdrZW9uQmJ1VjFWT21T?=
 =?utf-8?B?UVJyVE1GaXBtbDIyZ1gzdG9WRjlNRjA1K0lNckI1cVZldWVud2UrVW9IYXdv?=
 =?utf-8?B?c2tsOUxDVjdIdnVPMmJjbXhYODRTL2dkR09CeU5FU3RSR3pxWHlIa1ZGMUlX?=
 =?utf-8?B?QlBXUkovMGRlWVJuTFh3bFRJMGRaZExWSWp6UjVHSndDSGkxVHhlZURPNU1K?=
 =?utf-8?B?M0lBRnF4RXhPREYvYU1HbGlrN0F2MzhlZ3N0L2I0b3VuVFZKWkhXT3N4amlh?=
 =?utf-8?B?WXFLSWxQTm5ET3owaUkzNHltbVgrdlYybTZvclVwejB2RTk5akUrZFREbmZP?=
 =?utf-8?B?QjJ4c1VEcEdSUC9lYWptWEJIK2lyQ0RieEVIeVBTVWVLN21MY3VIRWtOYnlh?=
 =?utf-8?B?NDlwZ0IwSmVJcC9tNHd3RlhaYUx4a0hKWXdocWtIMzc3TG5GVENuK2NTRElK?=
 =?utf-8?B?T3drb2YxVG1vVFdQUWRDamhXZ3JCR3pyZ1lOaGEvd3lDbFhzeVBqOFp0TVZp?=
 =?utf-8?B?RkNJMWVxQ29WS3lsdEtxTXZzUytNRjhJVi9YdWYvSXRCOVpqZURzT0JqREt4?=
 =?utf-8?B?ZEtEalFzUE05Z1NVVWFGU0MxMHk2cEFXSnRDRVRMeHZ2SjltRVBsUUtKWVF2?=
 =?utf-8?Q?dAL/iAEXAzg5eKYOfVL9AxxtQsaQ0g=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(36860700013)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2025 17:14:09.1597
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 3bc53cc8-1468-4e53-13ae-08dd3ef60329
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF0002529F.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR12MB9265



On 27/01/2025 18:03, Alejandro Vallejo wrote:
> 
> 
> Hi,
> 
> On Mon Jan 27, 2025 at 10:45 AM GMT, Michal Orzel wrote:
>> On Arm32, when CONFIG_PHYS_ADDR_T_32 is set, a build failure is observed:
>> arch/arm/platforms/vexpress.c: In function 'vexpress_smp_init':
>> arch/arm/platforms/vexpress.c:102:12: error: format '%lx' expects argument of type 'long unsigned int', but argument 2 has type 'long long unsigned int' [-Werror=format=]
>>   102 |     printk("Set SYS_FLAGS to %"PRIpaddr" (%p)\n",
>>
>> When CONFIG_PHYS_ADDR_T_32 is set, paddr_t is defined as unsigned long.
>> Commit 96f35de69e59 dropped __virt_to_maddr() which used paddr_t as a
>> return type. Without a cast, the expression type is unsigned long long
>> which causes the issue. Fix it.
>>
>> Fixes: 96f35de69e59 ("x86+Arm: drop (rename) __virt_to_maddr() / __maddr_to_virt()")
>> Signed-off-by: Michal Orzel <michal.orzel@amd.com>
>> ---
>>  xen/arch/arm/include/asm/mm.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/arm/include/asm/mm.h b/xen/arch/arm/include/asm/mm.h
>> index f91ff088f6b1..a0d8e5afe977 100644
>> --- a/xen/arch/arm/include/asm/mm.h
>> +++ b/xen/arch/arm/include/asm/mm.h
>> @@ -263,7 +263,7 @@ static inline void __iomem *ioremap_wc(paddr_t start, size_t len)
>>
>>  #define virt_to_maddr(va) ({                                        \
>>      vaddr_t va_ = (vaddr_t)(va);                                    \
>> -    (va_to_par(va_) & PADDR_MASK & PAGE_MASK) | (va_ & ~PAGE_MASK); \
>> +    (paddr_t)((va_to_par(va_) & PADDR_MASK & PAGE_MASK) | (va_ & ~PAGE_MASK)); \
>>  })
>>
>>  #ifdef CONFIG_ARM_32
> 
> Out of curiosity, why not make va_to_par() and __va_to_par() return paddr_t
> rather than uint64_t? Then this cast would be unnecessary and the expression
> end up as unsigned long.
> 
> That would also cover any other uses outside this macro.
> 
> Unless I'm missing something else...
va_to_par() returns uint64_t because PAR_EL1 on Arm64 or PAR on Arm32 system registers are both 64bit.
So, it would not make sense (also it would be confusing) for va_to_par() to return already casted value.
The function ends with _par so it should reflect the register size as the name suggests. Macro is there
to cast this value as it also takes into account PADDR_MASK and PAGE_MASK.

~Michal



From xen-devel-bounces@lists.xenproject.org Mon Jan 27 17:16:00 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 17:16:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878147.1288322 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcSiN-0003k9-2h; Mon, 27 Jan 2025 17:15:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878147.1288322; Mon, 27 Jan 2025 17:15:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcSiN-0003k2-08; Mon, 27 Jan 2025 17:15:59 +0000
Received: by outflank-mailman (input) for mailman id 878147;
 Mon, 27 Jan 2025 17:15:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=rEBS=UT=amd.com=Michal.Orzel@srs-se1.protection.inumbo.net>)
 id 1tcSiL-0003jt-OY
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 17:15:57 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on2061f.outbound.protection.outlook.com
 [2a01:111:f403:2418::61f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5de0cfd8-dcd2-11ef-99a4-01e77a169b0f;
 Mon, 27 Jan 2025 18:15:55 +0100 (CET)
Received: from CH5PR04CA0005.namprd04.prod.outlook.com (2603:10b6:610:1f4::22)
 by MN2PR12MB4375.namprd12.prod.outlook.com (2603:10b6:208:24f::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.23; Mon, 27 Jan
 2025 17:15:50 +0000
Received: from CH2PEPF00000099.namprd02.prod.outlook.com
 (2603:10b6:610:1f4:cafe::2) by CH5PR04CA0005.outlook.office365.com
 (2603:10b6:610:1f4::22) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8377.22 via Frontend Transport; Mon,
 27 Jan 2025 17:15:50 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CH2PEPF00000099.mail.protection.outlook.com (10.167.244.20) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8398.14 via Frontend Transport; Mon, 27 Jan 2025 17:15:50 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 27 Jan
 2025 11:15:49 -0600
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Mon, 27 Jan 2025 11:15:48 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5de0cfd8-dcd2-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=cRZ7yu2WchctWAq6/z/2GpqhYtrotjrhOo2n6f+p+uudES7+d6KI9uBUZchp6f8oRh/HpHoW5LbwWqfdGSNxWzNGOVChu4J5quRwLUe4tLJLJU54Q0AMuCOyyPw2kSKs9dgH7TGP6gHjgRFAFvXFX3tn8/zMWXASsnQ6Y2/jCjRZnPzHUqVKjI7riztRm5A2ELUN/VRvQYUbmNvtMCm3vrhaiRrBHvG33bBiOJQ5oHn6L/HFNE9j5xJnO5hY+QePuiFIbKyAdRD3150CE2A1gIu572S7OiK1PJCTojhEai3nakETGR9RuqhRAAuLAtXabVruvVtLLGT6gDToR6F1PA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=2694W2IEQGxBUAVjQpa2LCHnNyhkJXWrTNvmVZV6HDo=;
 b=wStzFALxuVx/7s22RTBtW6r9GFwoeAPE/86xWU+NVglw/OVu2LGuggzcMX4S27kF3twvLbz2vnBC5te0a666bMNww0OBPuuupQ2h9jn6fLHW+2UCvtlEaEPs4deIvSxAJkdaD7L+U5PqfU/LsQPHjl8pazvayluguynTfy1cED+PCh4NOQdTGNRoXRvBsclJV7PbrlgShB2p8Ks6qtkwW83NPyiPfrI0TcMiFCEtN4wuNXKBEprHTSzfnnJlTiUSxDFXtha4B99EHmUJIsIdnfDiY5AY+k0cccjfoRV0xDlQvd7p/3fBKTs/ns8NNP1AAQbwQ19gokl/JnJpLIBwUw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=gmail.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=2694W2IEQGxBUAVjQpa2LCHnNyhkJXWrTNvmVZV6HDo=;
 b=CLrPkDsTzB2HBWQjNSzpewL3XP02kOo3BWo0F/Y8uem5H6tcOOlRPJj4LrGoc5csx8v1z3pWjKHaZNpEGQqt4X/5z7yFtCd4DyCYavakAP6mu+obz9jX5jhjILZT36Gk6yShCaljGMpqKsd9Pt8aA7m6G7yck98PmP06X5BxJRY=
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: <7fff37b8-9698-44ef-aa42-f1652ea3498c@amd.com>
Date: Mon, 27 Jan 2025 18:15:47 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [for-4.20][PATCH 1/2] device-tree: bootfdt: Fix build issue when
 CONFIG_PHYS_ADDR_T_32=y
To: Julien Grall <julien.grall.oss@gmail.com>
CC: <xen-devel@lists.xenproject.org>, Stefano Stabellini
	<sstabellini@kernel.org>, Bertrand Marquis <bertrand.marquis@arm.com>,
	<oleksii.kurochko@gmail.com>
References: <20250127104556.175641-1-michal.orzel@amd.com>
 <20250127104556.175641-2-michal.orzel@amd.com>
 <CAJ=z9a24=PE-3bhmZvfTaTgpdCXp9iDTWfoH-9F9-_OdkEf4Tg@mail.gmail.com>
 <32d42df5-08d9-4670-a571-ef315897514b@amd.com>
 <CAJ=z9a3gN0NyuvVQfEW2v9H9F5ZUhHB9+LvK4viQhSm6A=hauA@mail.gmail.com>
Content-Language: en-US
From: Michal Orzel <michal.orzel@amd.com>
In-Reply-To: <CAJ=z9a3gN0NyuvVQfEW2v9H9F5ZUhHB9+LvK4viQhSm6A=hauA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Received-SPF: None (SATLEXMB03.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH2PEPF00000099:EE_|MN2PR12MB4375:EE_
X-MS-Office365-Filtering-Correlation-Id: 36a9b60d-c025-428f-20cc-08dd3ef63f59
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|376014|82310400026|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?cUNGTVJadCtETTJzMFVrdWVsTVZYb05KUkhmdEY4cnU1VjhvR1NORWgyU3pE?=
 =?utf-8?B?Y3BPMmVKN1pla3lTSUVka3ArbTRJRE5HQ1pBTkdURnAxNjNORnBHTkpYSTdP?=
 =?utf-8?B?ZUFmbnBGVkxnVW5pUUJpVlExbzhwMWlOM3duSlJ6d3R0d2JiQXp4ODFlZVhG?=
 =?utf-8?B?eDVEUFdSdm9IRXp5VDRMeGRxdDFnUFpBWFFQOWIzNWxvTnNiT1NORWdwZDdD?=
 =?utf-8?B?RDMxQ1RkSFpPaFFodU05Q3JuQ2lCYUpMQW5RSUsvckwzMmZmVzNqVTk3V1hI?=
 =?utf-8?B?eFlSV1kyeHJFUS93Q1NFeWQ1THFMaGFBV2hFNTVzZXl4NTlSa1M1U3R6azVN?=
 =?utf-8?B?a0VNMXJYTCsrL01ZcHpqVVZpOEQwVFVVMU85V2Y1VktXejdmZTRwVEtHaHc3?=
 =?utf-8?B?bzUvMnF5SXdoRkVyekdzamxONnNqZDlvZTZBL3ZaNTZSRjkzcTFmUlhyL09R?=
 =?utf-8?B?dUpqZnhlZEI4K3I4WHJkOFh4N2txZ2E0cFNFZ0ZaQnA1a21UMEtqdXh2cUpJ?=
 =?utf-8?B?S3VlT0lmTUhOU1JMR1MrU0xnWlgrOVplQThFQURCMGRKeHVJL3lNcWx3ZXRC?=
 =?utf-8?B?cnBPdElqMFRDclArbEN3c3BzU0NQdks1WHZpQVRZV0JVWldWQWM4OXlGOGVt?=
 =?utf-8?B?UTZuYmRTcU9QQ21OekE0YkF3VnZUZkQrUms0bG9FRVFuam9OUFlZTkw3LzFj?=
 =?utf-8?B?b3BLekNidXVVb0xmZEhmMEZJZzJ5OS8zYmt2NmRxSjZrQjhPdEhhREZKbUJr?=
 =?utf-8?B?eVM2NW1UUk82d1hRcTJuTE1uTWNFdnZWTjhxbjNTNG84enlRYmtIWVZDMmNh?=
 =?utf-8?B?L2pBaEFEc3RpU1BDRGtDTUJsbjMzZDcvdHloWXNpdm1xeko0U1dyS0ozczg1?=
 =?utf-8?B?UXhneG5Fa3c4VVZjd095M1pSOTBFZWJyZ2t5dFlpQU5pSUpiUFdiZzE0d2E4?=
 =?utf-8?B?ZmtTc2FpZEFyMlVHY1Y0ZmRJczVNNnBMelRsVndzZUpVUno0NXhML1d1UUZx?=
 =?utf-8?B?dEtLZ3pZcXY5Zkd2d2ZPRkQrZk1IWG00azR1YndodkkwZk4xbkp6UU9PMXdV?=
 =?utf-8?B?N08wR1VNU2dZaG8rcHc5SkRSQ21NamFvbEVTL3cvd1BXem12TlhuM1NodlRa?=
 =?utf-8?B?aXIwVDJXdjRhMStSVnpsZ2VlamJaWXc5VGV4UjJ3bHRQSkZWelRNS0xRNnZX?=
 =?utf-8?B?RlJ3cmNDTzE0dCt1a0YwbjI5ZjFHK0xvc0lXWTFNMnBMRWtDUlEvNnloU1Vh?=
 =?utf-8?B?ZEdPQjBtOFVGejE2cmJMbUpEalMrcGpGc0xITTNBb1B4Y3M4SkMxWkZqdDRS?=
 =?utf-8?B?MW85Y0lpaG92bGgzbDVyaXlzaTNQZVh6dlFvYzZMVG1Wd0VHRWpVcjdmR3B6?=
 =?utf-8?B?U3k1OHJEejAzdnQ4cGFvVUpPQWEwRzhFczlIR0JWMUVSNWJPei91WDlzYXFM?=
 =?utf-8?B?dzd3U1V2Z3cyV0p6QTlwMEQ2bHhCVlZIdG1LWU5GOW9uVlZXajJXUEplcmFm?=
 =?utf-8?B?bjExemY5WGNIS3NYRjBScjhSVFdXVHNsQmI1N0x2ckhPQlFVSG9oRFNCOHBw?=
 =?utf-8?B?bTdOREpGa3BmamdRbmYrdnFwdjBxcXBKU3pWVitEVEFLT0hwQlNZalJrRnVq?=
 =?utf-8?B?UHI2eG90b0hyZzREWTNjZ1Zha1JTcU9XVTE5SFJrc3h0WGtEM0FwTDhhdWsr?=
 =?utf-8?B?OVoyNnIrc3lQU3FwWmUyUDNkS1c4d01hcFlXbXAyTWl4b0VsY3BUYm9WWXRE?=
 =?utf-8?B?cDErZ3o2aEJ1OVZpdEdzTit2VzNHbkYxano4TTZmN2ZLQ2gxVGlndXU4dlJX?=
 =?utf-8?B?TzR1d3BaS2QzdHYvVmhsalFQRC9mWmxmemN4Q2IvT1FTUlVWR2JXN1VKdlc1?=
 =?utf-8?B?eFBIRWU5MklCY28wQzJLMHF5V1B3VHlZTDNvTjBpR09paldzNGI3Z01QSjUv?=
 =?utf-8?B?UVlUa3VQb2N0MDFyU2hUOGgraGZGeUp2bEFYT2dYdEptM09INzRzeXRNcGJZ?=
 =?utf-8?Q?zbbxN4p/UrUQ7OK8tUajfOnod9wINc=3D?=
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:(13230040)(36860700013)(376014)(82310400026)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2025 17:15:50.1223
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 36a9b60d-c025-428f-20cc-08dd3ef63f59
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:
	CH2PEPF00000099.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4375



On 27/01/2025 17:27, Julien Grall wrote:
> 	
> 
> 
> 
> 
> On Mon, 27 Jan 2025 at 09:52, Michal Orzel <michal.orzel@amd.com <mailto:michal.orzel@amd.com>> wrote:
> 
> 
> 
>     On 27/01/2025 12:19, Julien Grall wrote:
>     >       
>     >
>     >
>     >
>     >
>     > On Mon, 27 Jan 2025 at 07:46, Michal Orzel <michal.orzel@amd.com <mailto:michal.orzel@amd.com> <mailto:michal.orzel@amd.com <mailto:michal.orzel@amd.com>>> wrote:
>     >
>     >     On Arm32, when CONFIG_PHYS_ADDR_T_32 is set, a build failure is observed:
>     >     common/device-tree/bootfdt.c: In function 'build_assertions':
>     >     ./include/xen/macros.h:47:31: error: static assertion failed: "!(alignof(struct membanks) != 8)"
>     >        47 | #define BUILD_BUG_ON(cond) ({ _Static_assert(!(cond), "!(" #cond ")"); })
>     >           |                               ^~~~~~~~~~~~~~
>     >     common/device-tree/bootfdt.c:31:5: note: in expansion of macro 'BUILD_BUG_ON'
>     >        31 |     BUILD_BUG_ON(alignof(struct membanks) != 8);
>     >
>     >     When CONFIG_PHYS_ADDR_T_32 is set, paddr_t is defined as unsigned long,
>     >     therefore the struct membanks alignment is 4B. Fix it.
>     >
>     >
>     > Usually, we add a BUILD_BUG_ON when other parts of the code rely on a specific property (in this case alignment). Can you explain in the commit message why the new check is still ok?
>     Well, the change itself reflects the change in alignment requirement.
>     When paddr_t is 64b (Arm64, Arm32 with PA=40b) the alignment is 8B.
>     On Arm32 with PA=32b, the alignment is 4B because paddr_t is 4B.
> 
>     AFAICT you requested this check back then, because struct membanks contains flexible array member 'bank' of type struct membank.
>     The alignment requirement of struct membanks becomes the requirement of struct membank whose largest type is paddr_t.
> 
> 
> Reading this, it sounds like you want to check against the alignment of « struct membank ». This is because the structure could gain a 64-bit field in the future and this would not be caught by the BUILD_BUG_ON.
> 
> 
>     Let me know how you would like to have this written in commit msg.
> 
> 
> I think it needs to be rephrased to make clear the alignment of  struct membanks should be the same as struct membank.
Shouldn't this check therefore be changed to:
BUILD_BUG_ON(alignof(struct membanks) != alignof(struct membank));

~Michal


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 17:22:50 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 17:22:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878158.1288333 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcSow-00062a-Op; Mon, 27 Jan 2025 17:22:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878158.1288333; Mon, 27 Jan 2025 17:22:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcSow-00062T-MF; Mon, 27 Jan 2025 17:22:46 +0000
Received: by outflank-mailman (input) for mailman id 878158;
 Mon, 27 Jan 2025 17:22: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
 <SRS0=qVGR=UT=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tcSov-00062N-G1
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 17:22:45 +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 51557f66-dcd3-11ef-99a4-01e77a169b0f;
 Mon, 27 Jan 2025 18:22:43 +0100 (CET)
Received: by mail-lf1-x134.google.com with SMTP id
 2adb3069b0e04-5401c68b89eso4724951e87.0
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 09:22:43 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-543c837a299sm1385888e87.207.2025.01.27.09.22.41
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 09:22:42 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 51557f66-dcd3-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1737998563; x=1738603363; darn=lists.xenproject.org;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=IiTH7uX9ZoGcNwWgDFE/IqiZgDgoPqLiw4UAFsSFF58=;
        b=Zluwq6/gC/N2P+E+kLVETSYRiX98QM/a/eczGQ77mHC+N5s2oHKujg4dXxhjGVhFHe
         SwBPiRESQO5zyVCdSh6UA7ngLd/8u2YC8DS+XS+VYeNb5+a5RAvgPM632EC1G58D/x4T
         EDfIu8E1cd+VEJnmhRg5UCS3kLoG1mjrS3XM5UNI+CYsv+YBuBz2YC9KLg2XWpIf6DID
         O8yxj63FKypW+XKrAOxzmV0MTG3LDASmmPDi5dOOpVlACAiTYBqrdmuebX5JlG+Bq8rE
         F+E6Bf6Zz115Q7RxI0idyy8iSGXzQAecJLeV4MWOvJWnm8UKumaKz9yqJR7q0a9dlwwo
         97Sw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737998563; x=1738603363;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=IiTH7uX9ZoGcNwWgDFE/IqiZgDgoPqLiw4UAFsSFF58=;
        b=w2R2c2TpIBciA/vH0pE6fFCAietqcwkV7p6ws3QBLYKKFt+xBKaKHnG0+qPSipDFCu
         DVuxEmyvuFknRzlv6GNWNIevC3EfMOjHi2QprgmWMEBTEwg+zsFURRlDCErd+2Bg5mTj
         NhCXaU7mgurWj/o6wXhuAGj2US9jJiKfnbnPTQ3jZsWzSI2F7Mfe6kvdUHHfgkjJTxG/
         Q0XxUM2YZOibPgfRpCKdYBINy429DCBSxOsKLEUJ+ZndKHgYtseTfGGvrY3XMGyW7gox
         KAo8yI4/XJVdvqHU1k/MaMR6ICQb+pNSx2u/J55FG9Kn9RHhHqI5WQBMLzIVWLBxGTfB
         Tmrg==
X-Forwarded-Encrypted: i=1; AJvYcCXK0rclBRVb8DB8DKl/Sdwe7FiZwXisK/k7hWf5J1ypFSqBd9aRd79nTcFKpXIa3iP+wpJTrewfhIU=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy4g2a1hsWIlEnHNZ/74jFrLL6hH5xTlH1wdVxHhIFqC0jFlrRe
	LGBQ4fZGkKGpafv1p5rV8lz0bR1XpRLuzLH8Poz5CfnP2ZRZC0Eu
X-Gm-Gg: ASbGncvBBOP232gZc/6gXZRhl6Gx+hMrGCv1aHAYUuGA0nFl2G1HXmUm7T/3nfBu3HD
	lZSNntkS8YcykPPH9KmocFnBBs1z3P9WytpT6DBkY5vRgbOWwpdO2ZyHS/qP+BJdgpWVtyEbISx
	dkn56Jy+NYC7ng7ZWxq4WK8w/hRY/1spF7h80Lwu9U2p2AbqmLPte7B0F2acN38fcjL4mf7N2vN
	eAqVTc96T3gNx8aKJWp3rirIXe1+GAP4Z6dJF/0PyrRGOrN70P9N20cvAu0FjLWwTJZMsg6YgKl
	DnOV8Exj9S+eNUm5JQ==
X-Google-Smtp-Source: AGHT+IEEuL1KKoYirDmnb1gybHJA74d11LQ9ywuKsQDKWjpFMgdPPRw6+oEYuR2E03TxbigAh2l+Yg==
X-Received: by 2002:a05:6512:3089:b0:542:91a5:4b90 with SMTP id 2adb3069b0e04-543df6e5307mr33317e87.21.1737998562378;
        Mon, 27 Jan 2025 09:22:42 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------60y91bUPPL5GHSd430TXDkF5"
Message-ID: <d9ca4252-1bf0-4257-ad6b-e91240cc5de3@gmail.com>
Date: Mon, 27 Jan 2025 18:22:41 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 1/3] xen/riscv: implement software page table walking
To: Jan Beulich <jbeulich@suse.com>
Cc: Alistair Francis <alistair.francis@wdc.com>,
 Bob Eshleman <bobbyeshleman@gmail.com>, Connor Davis
 <connojdavis@gmail.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1737391102.git.oleksii.kurochko@gmail.com>
 <00dfc71569bc9971b53e29b36a80e9e020ac61ac.1737391102.git.oleksii.kurochko@gmail.com>
 <21bfd2f5-74b8-409e-956c-dd736a3c0be2@suse.com>
 <e2290a2a-a3c0-4cfe-b9e9-8cfec0b194a8@gmail.com>
 <a304e4f0-709f-4fcd-9847-01fe6ab4b98c@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <a304e4f0-709f-4fcd-9847-01fe6ab4b98c@suse.com>

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


On 1/27/25 1:57 PM, Jan Beulich wrote:
> On 27.01.2025 13:29, Oleksii Kurochko wrote:
>> On 1/27/25 11:06 AM, Jan Beulich wrote:
>>> On 20.01.2025 17:54, Oleksii Kurochko wrote:
>>>> RISC-V doesn't have hardware feature to ask MMU to translate
>>>> virtual address to physical address ( like Arm has, for example ),
>>>> so software page table walking in implemented.
>>>>
>>>> Signed-off-by: Oleksii Kurochko<oleksii.kurochko@gmail.com>
>>>> ---
>>>>    xen/arch/riscv/include/asm/mm.h |  2 ++
>>>>    xen/arch/riscv/pt.c             | 56 +++++++++++++++++++++++++++++++++
>>>>    2 files changed, 58 insertions(+)
>>>>
>>>> diff --git a/xen/arch/riscv/include/asm/mm.h b/xen/arch/riscv/include/asm/mm.h
>>>> index 292aa48fc1..d46018c132 100644
>>>> --- a/xen/arch/riscv/include/asm/mm.h
>>>> +++ b/xen/arch/riscv/include/asm/mm.h
>>>> @@ -15,6 +15,8 @@
>>>>    
>>>>    extern vaddr_t directmap_virt_start;
>>>>    
>>>> +paddr_t pt_walk(vaddr_t va);
>>> In the longer run, is returning just the PA really going to be sufficient?
>>> If not, perhaps say a word on the limitation in the description.
>> In the long run, this function's prototype looks like|paddr_t pt_walk(vaddr_t root, vaddr_t va, bool is_xen)| [1]. However, I'm not sure if it will stay that way,
>> as I think|is_xen| could be skipped, since using|map_table()| should be sufficient (as it now considers|system_state|) and I'm not really sure if I need root argument
>> as initial goal was to use this function for debug only purposes and I've never used it for guest page table (stage-1) walking.
>> Anyway, yes, it is still returning a physical address, and that seems enough to me.
>>
>> Could you share your thoughts on what I should take into account for returning value, probably, I am missing something really useful?
> Often you care about the permissions as well. Sometimes it may even be relevant
> to know the (super-)page size of the mapping.

Perhaps it would be better to change the prototype to:
   bool pt_walk(vaddr_t va, mfn_t *ret_pa);
or even
   void pt_walk(vaddr_t va, mfn_t *ret_pa);
   In this case,|ret_pa = INVALID_MFN| could serve as a signal that|pt_walk()| failed.
If there's a need to return permissions or (super-)page size in the future, another argument could be added.

What do you think? Would this approach be better?

I am also considering returning a structure containing the|mfn| (or|paddr_t|) and adding other properties (such as permissions or
page size) as needed in the future. Both solutions seem more or less equivalent.

~ Oleksii

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

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 1/27/25 1:57 PM, Jan Beulich wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:a304e4f0-709f-4fcd-9847-01fe6ab4b98c@suse.com">
      <pre class="moz-quote-pre" wrap=""><pre wrap=""
      class="moz-quote-pre">On 27.01.2025 13:29, Oleksii Kurochko wrote:
</pre><blockquote type="cite" style="color: #007cff;"><pre wrap=""
      class="moz-quote-pre">On 1/27/25 11:06 AM, Jan Beulich wrote:
</pre><blockquote type="cite" style="color: #007cff;"><pre wrap=""
      class="moz-quote-pre">On 20.01.2025 17:54, Oleksii Kurochko wrote:
</pre><blockquote type="cite" style="color: #007cff;"><pre wrap=""
      class="moz-quote-pre">RISC-V doesn't have hardware feature to ask MMU to translate
virtual address to physical address ( like Arm has, for example ),
so software page table walking in implemented.

Signed-off-by: Oleksii Kurochko<a class="moz-txt-link-rfc2396E"
      href="mailto:oleksii.kurochko@gmail.com" moz-do-not-send="true">&lt;oleksii.kurochko@gmail.com&gt;</a>
---
  xen/arch/riscv/include/asm/mm.h |  2 ++
  xen/arch/riscv/pt.c             | 56 +++++++++++++++++++++++++++++++++
  2 files changed, 58 insertions(+)

diff --git a/xen/arch/riscv/include/asm/mm.h b/xen/arch/riscv/include/asm/mm.h
index 292aa48fc1..d46018c132 100644
--- a/xen/arch/riscv/include/asm/mm.h
+++ b/xen/arch/riscv/include/asm/mm.h
@@ -15,6 +15,8 @@
  
  extern vaddr_t directmap_virt_start;
  
+paddr_t pt_walk(vaddr_t va);
</pre></blockquote><pre wrap="" class="moz-quote-pre">In the longer run, is returning just the PA really going to be sufficient?
If not, perhaps say a word on the limitation in the description.
</pre></blockquote><pre wrap="" class="moz-quote-pre">In the long run, this function's prototype looks like|paddr_t pt_walk(vaddr_t root, vaddr_t va, bool is_xen)| [1]. However, I'm not sure if it will stay that way,
as I think|is_xen| could be skipped, since using|map_table()| should be sufficient (as it now considers|system_state|) and I'm not really sure if I need root argument
as initial goal was to use this function for debug only purposes and I've never used it for guest page table (stage-1) walking.
Anyway, yes, it is still returning a physical address, and that seems enough to me.

Could you share your thoughts on what I should take into account for returning value, probably, I am missing something really useful?
</pre></blockquote><pre wrap="" class="moz-quote-pre">Often you care about the permissions as well. Sometimes it may even be relevant
to know the (super-)page size of the mapping.</pre></pre>
    </blockquote>
    <div
class="group/conversation-turn relative flex w-full min-w-0 flex-col agent-turn">
      <div class="flex-col gap-1 md:gap-3">
        <div class="flex max-w-full flex-col flex-grow">
          <div data-message-author-role="assistant"
            data-message-id="452652fc-e319-4d3f-8fe8-e9df6f7b8a45"
            dir="auto"
class="min-h-8 text-message flex w-full flex-col items-end gap-2 whitespace-normal break-words text-start [.text-message+&amp;]:mt-5"
            data-message-model-slug="gpt-4o">
            <div
class="flex w-full flex-col gap-1 empty:hidden first:pt-[3px]">
              <div
class="markdown prose w-full break-words dark:prose-invert light">
                <pre>Perhaps it would be better to change the prototype to:
  bool pt_walk(vaddr_t va, mfn_t *ret_pa);
or even
  void pt_walk(vaddr_t va, mfn_t *ret_pa);
  In this case, <code>ret_pa = INVALID_MFN</code> could serve as a signal that <code>pt_walk()</code> failed.
If there's a need to return permissions or (super-)page size in the future, another argument could be added.</pre>
              </div>
            </div>
          </div>
        </div>
      </div>
    </div>
    <pre>What do you think? Would this approach be better?

I am also considering returning a structure containing the <code>mfn</code> (or <code>paddr_t</code>) and adding other properties (such as permissions or
page size) as needed in the future. Both solutions seem more or less equivalent.

~ Oleksii
</pre>
  </body>
</html>

--------------60y91bUPPL5GHSd430TXDkF5--


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 17:41:31 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 17:41:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878168.1288342 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcT6s-00014y-7M; Mon, 27 Jan 2025 17:41:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878168.1288342; Mon, 27 Jan 2025 17:41:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcT6s-00014r-4f; Mon, 27 Jan 2025 17:41:18 +0000
Received: by outflank-mailman (input) for mailman id 878168;
 Mon, 27 Jan 2025 17:41:16 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=qVGR=UT=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tcT6q-00010f-9X
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 17:41:16 +0000
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com
 [2a00:1450:4864:20::12c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e2e2afdf-dcd5-11ef-99a4-01e77a169b0f;
 Mon, 27 Jan 2025 18:41:06 +0100 (CET)
Received: by mail-lf1-x12c.google.com with SMTP id
 2adb3069b0e04-54024aa9febso5023380e87.1
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 09:41:06 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-543c83684basm1340780e87.109.2025.01.27.09.41.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 27 Jan 2025 09:41:05 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e2e2afdf-dcd5-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1737999666; x=1738604466; darn=lists.xenproject.org;
        h=in-reply-to:content-language:references:cc:to:from:subject
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=zgGt0UWgv/Np04JsWjifwQUIQ9PfPuCBVZ7oSviphrw=;
        b=b9cx0n76VFihzdQeon3OavbZ/KiYSqghvshIzJqYhL4IsLm2xcyj10nvBhc7hunIWd
         MUbevs93YZvCxCJkSk82zkoMMv8X1l6cu52XBFdp9MuVqi8GVaGi/S3QA+9r8Yq8/z4A
         fC9t2/l/eaPIx6nzT+fygQwNO5GWytR9jm9GBW943a7JxJcnaWKtUbJbg7jX71GYTi8Q
         v1UiV8Fc6whyFtTlzLyYZxSM2WPjIWQX9/LEGrK7o+ufyZenw7XhdQv3XIURtewh8/Ql
         7HTXY/C0yJpqnu4c945RFtH8KB5T0/bPfur/hs36rWaSYxBZDJYLbasFT2gRs5yl+pwA
         kuew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737999666; x=1738604466;
        h=in-reply-to:content-language:references:cc:to:from:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=zgGt0UWgv/Np04JsWjifwQUIQ9PfPuCBVZ7oSviphrw=;
        b=Z2IZf7FWS7EGH8WMXcCz9Ww4hjzyJQVrd6KjhEiHik4j+tKKi7/WNv9n3mkvla0AZj
         LOXo2DgXxZnffhX/rZPefnNF17S2wSwtUYJ/0oMa4futKkxAes1utVh68kBrpVxWj/c4
         G1SaY/UxoSBuYeEqdef2Wyvm+Y4ubdi37BWlnNevGCuX+bnSyJRKFrX7O5mj3eHXzljs
         0MS0K2yClPFcv6E62nBH35/XqmHVDnxrlV47GRIghGPxESRNKRKPeSIMvLeyeHbBY1na
         kEsu+wW9NJKko7VUtpE7WMm+5+ANxOcskqfH/UJFcFbiVKtIDpeIHmhj0qlphbdJeKgJ
         0Oww==
X-Forwarded-Encrypted: i=1; AJvYcCVdefueCi8IFdH5BNRKVQYhhXOfRY9vdi8T38A56yvAv2qZ8uI4wyA/PutnTB8+jJxsF+rIYZgIp5Y=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyxDD7dEBU7TvVwKZJYKRh43HempunCL7+7uT6WYR9qfXnCATop
	P5si/ERBmbG6kIxBJ1e3xXMVvSOE2/H+HvoGptDEV/GKe319W0Zm
X-Gm-Gg: ASbGncv6xTMH57II+iT7BWW5GuL7JjRI+WU0VORwruzBj4LIlwTmq9pscNKNqnKVCbL
	2Gvqq5Ag0ROvEhSqnv1qsb1BzpwcXfLCnECqylQNOWD/rxYlIsDygAuvIAqYb3SagueVewirZ/T
	aKhbr7CmYOf5CSuBvpPJ1YN2FbvKDQdeeAO148jCsvqRohzSST9Eps60bOqCwPxCiSAOoIrdTuW
	LTfYdS8QscTsFyeQYkpw6+Rd33ngS27By7Y4iFVT+L8PkTkSImbHYw6V1YgZcSlI+ucnpqAL/SZ
	kF7lcDO3bq0qsk3/sw==
X-Google-Smtp-Source: AGHT+IF0YCjbqvn/5iYJcQNS/PYdLHDRoSCxQuoIvLYVpZYcJCymOz2g7JCsqJHPMsqUvwte4/Nf4w==
X-Received: by 2002:ac2:4acb:0:b0:540:1a0c:9ba6 with SMTP id 2adb3069b0e04-5439c282d2bmr12671485e87.34.1737999665681;
        Mon, 27 Jan 2025 09:41:05 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------NR3E6JH0lAFy9RT57IGkjVGJ"
Message-ID: <67446e8f-71d4-480e-8566-1a464b6f6639@gmail.com>
Date: Mon, 27 Jan 2025 18:41:04 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 1/3] xen/riscv: implement software page table walking
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Alistair Francis <alistair.francis@wdc.com>,
 Bob Eshleman <bobbyeshleman@gmail.com>, Connor Davis
 <connojdavis@gmail.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1737391102.git.oleksii.kurochko@gmail.com>
 <00dfc71569bc9971b53e29b36a80e9e020ac61ac.1737391102.git.oleksii.kurochko@gmail.com>
 <21bfd2f5-74b8-409e-956c-dd736a3c0be2@suse.com>
 <e2290a2a-a3c0-4cfe-b9e9-8cfec0b194a8@gmail.com>
 <a304e4f0-709f-4fcd-9847-01fe6ab4b98c@suse.com>
 <d9ca4252-1bf0-4257-ad6b-e91240cc5de3@gmail.com>
Content-Language: en-US
In-Reply-To: <d9ca4252-1bf0-4257-ad6b-e91240cc5de3@gmail.com>

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


On 1/27/25 6:22 PM, Oleksii Kurochko wrote:
>
>
> On 1/27/25 1:57 PM, Jan Beulich wrote:
>> On 27.01.2025 13:29, Oleksii Kurochko wrote:
>>> On 1/27/25 11:06 AM, Jan Beulich wrote:
>>>> On 20.01.2025 17:54, Oleksii Kurochko wrote:
>>>>> RISC-V doesn't have hardware feature to ask MMU to translate
>>>>> virtual address to physical address ( like Arm has, for example ),
>>>>> so software page table walking in implemented.
>>>>>
>>>>> Signed-off-by: Oleksii Kurochko<oleksii.kurochko@gmail.com>
>>>>> ---
>>>>>    xen/arch/riscv/include/asm/mm.h |  2 ++
>>>>>    xen/arch/riscv/pt.c             | 56 +++++++++++++++++++++++++++++++++
>>>>>    2 files changed, 58 insertions(+)
>>>>>
>>>>> diff --git a/xen/arch/riscv/include/asm/mm.h b/xen/arch/riscv/include/asm/mm.h
>>>>> index 292aa48fc1..d46018c132 100644
>>>>> --- a/xen/arch/riscv/include/asm/mm.h
>>>>> +++ b/xen/arch/riscv/include/asm/mm.h
>>>>> @@ -15,6 +15,8 @@
>>>>>    
>>>>>    extern vaddr_t directmap_virt_start;
>>>>>    
>>>>> +paddr_t pt_walk(vaddr_t va);
>>>> In the longer run, is returning just the PA really going to be sufficient?
>>>> If not, perhaps say a word on the limitation in the description.
>>> In the long run, this function's prototype looks like|paddr_t pt_walk(vaddr_t root, vaddr_t va, bool is_xen)| [1]. However, I'm not sure if it will stay that way,
>>> as I think|is_xen| could be skipped, since using|map_table()| should be sufficient (as it now considers|system_state|) and I'm not really sure if I need root argument
>>> as initial goal was to use this function for debug only purposes and I've never used it for guest page table (stage-1) walking.
>>> Anyway, yes, it is still returning a physical address, and that seems enough to me.
>>>
>>> Could you share your thoughts on what I should take into account for returning value, probably, I am missing something really useful?
>> Often you care about the permissions as well. Sometimes it may even be relevant
>> to know the (super-)page size of the mapping.
> Perhaps it would be better to change the prototype to:
>    bool pt_walk(vaddr_t va, mfn_t *ret_pa);
> or even
>    void pt_walk(vaddr_t va, mfn_t *ret_pa);
>    In this case,|ret_pa = INVALID_MFN| could serve as a signal that|pt_walk()| failed.
> If there's a need to return permissions or (super-)page size in the future, another argument could be added.
> What do you think? Would this approach be better?

We have to return mfn_t or paddr_t as pt_walk() is used invmap_to_mfn().

~ Oleksii

>
> I am also considering returning a structure containing the|mfn| (or|paddr_t|) and adding other properties (such as permissions or
> page size) as needed in the future. Both solutions seem more or less equivalent.
>
> ~ Oleksii
--------------NR3E6JH0lAFy9RT57IGkjVGJ
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 1/27/25 6:22 PM, Oleksii Kurochko
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:d9ca4252-1bf0-4257-ad6b-e91240cc5de3@gmail.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <p><br>
      </p>
      <div class="moz-cite-prefix">On 1/27/25 1:57 PM, Jan Beulich
        wrote:<br>
      </div>
      <blockquote type="cite"
        cite="mid:a304e4f0-709f-4fcd-9847-01fe6ab4b98c@suse.com">
        <pre class="moz-quote-pre" wrap=""><pre wrap=""
        class="moz-quote-pre">On 27.01.2025 13:29, Oleksii Kurochko wrote:
</pre><blockquote type="cite" style="color: #007cff;"><pre wrap=""
        class="moz-quote-pre">On 1/27/25 11:06 AM, Jan Beulich wrote:
</pre><blockquote type="cite" style="color: #007cff;"><pre wrap=""
        class="moz-quote-pre">On 20.01.2025 17:54, Oleksii Kurochko wrote:
</pre><blockquote type="cite" style="color: #007cff;"><pre wrap=""
        class="moz-quote-pre">RISC-V doesn't have hardware feature to ask MMU to translate
virtual address to physical address ( like Arm has, for example ),
so software page table walking in implemented.

Signed-off-by: Oleksii Kurochko<a class="moz-txt-link-rfc2396E"
        href="mailto:oleksii.kurochko@gmail.com" moz-do-not-send="true">&lt;oleksii.kurochko@gmail.com&gt;</a>
---
  xen/arch/riscv/include/asm/mm.h |  2 ++
  xen/arch/riscv/pt.c             | 56 +++++++++++++++++++++++++++++++++
  2 files changed, 58 insertions(+)

diff --git a/xen/arch/riscv/include/asm/mm.h b/xen/arch/riscv/include/asm/mm.h
index 292aa48fc1..d46018c132 100644
--- a/xen/arch/riscv/include/asm/mm.h
+++ b/xen/arch/riscv/include/asm/mm.h
@@ -15,6 +15,8 @@
  
  extern vaddr_t directmap_virt_start;
  
+paddr_t pt_walk(vaddr_t va);
</pre></blockquote><pre wrap="" class="moz-quote-pre">In the longer run, is returning just the PA really going to be sufficient?
If not, perhaps say a word on the limitation in the description.
</pre></blockquote><pre wrap="" class="moz-quote-pre">In the long run, this function's prototype looks like|paddr_t pt_walk(vaddr_t root, vaddr_t va, bool is_xen)| [1]. However, I'm not sure if it will stay that way,
as I think|is_xen| could be skipped, since using|map_table()| should be sufficient (as it now considers|system_state|) and I'm not really sure if I need root argument
as initial goal was to use this function for debug only purposes and I've never used it for guest page table (stage-1) walking.
Anyway, yes, it is still returning a physical address, and that seems enough to me.

Could you share your thoughts on what I should take into account for returning value, probably, I am missing something really useful?
</pre></blockquote><pre wrap="" class="moz-quote-pre">Often you care about the permissions as well. Sometimes it may even be relevant
to know the (super-)page size of the mapping.</pre></pre>
      </blockquote>
      <div
class="group/conversation-turn relative flex w-full min-w-0 flex-col agent-turn">
        <div class="flex-col gap-1 md:gap-3">
          <div class="flex max-w-full flex-col flex-grow">
            <div data-message-author-role="assistant"
              data-message-id="452652fc-e319-4d3f-8fe8-e9df6f7b8a45"
              dir="auto"
class="min-h-8 text-message flex w-full flex-col items-end gap-2 whitespace-normal break-words text-start [.text-message+&amp;]:mt-5"
              data-message-model-slug="gpt-4o">
              <div
class="flex w-full flex-col gap-1 empty:hidden first:pt-[3px]">
                <div
class="markdown prose w-full break-words dark:prose-invert light">
                  <pre>Perhaps it would be better to change the prototype to:
  bool pt_walk(vaddr_t va, mfn_t *ret_pa);
or even
  void pt_walk(vaddr_t va, mfn_t *ret_pa);
  In this case, <code>ret_pa = INVALID_MFN</code> could serve as a signal that <code>pt_walk()</code> failed.
If there's a need to return permissions or (super-)page size in the future, another argument could be added.</pre>
                </div>
              </div>
            </div>
          </div>
        </div>
      </div>
      <pre>What do you think? Would this approach be better?</pre>
    </blockquote>
    <pre>We have to return mfn_t or paddr_t as pt_walk() is used in <span
    style="white-space: pre-wrap">vmap_to_mfn().</span></pre>
    <pre><span style="white-space: pre-wrap">
</span></pre>
    <pre><span style="white-space: pre-wrap">~ Oleksii
</span></pre>
    <blockquote type="cite"
      cite="mid:d9ca4252-1bf0-4257-ad6b-e91240cc5de3@gmail.com">
      <pre>

I am also considering returning a structure containing the <code>mfn</code> (or <code>paddr_t</code>) and adding other properties (such as permissions or
page size) as needed in the future. Both solutions seem more or less equivalent.

~ Oleksii
</pre>
    </blockquote>
  </body>
</html>

--------------NR3E6JH0lAFy9RT57IGkjVGJ--


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 19:00:14 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 19:00:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878182.1288361 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcUL1-0003oT-Ve; Mon, 27 Jan 2025 18:59:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878182.1288361; Mon, 27 Jan 2025 18: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 <xen-devel-bounces@lists.xenproject.org>)
	id 1tcUL1-0003oM-Rq; Mon, 27 Jan 2025 18:59:59 +0000
Received: by outflank-mailman (input) for mailman id 878182;
 Mon, 27 Jan 2025 18:56:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=TuAY=UT=aptar.com=jonathan.katz@srs-se1.protection.inumbo.net>)
 id 1tcUHY-0003kg-At
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 18:56:24 +0000
Received: from CH5PR02CU005.outbound.protection.outlook.com
 (mail-northcentralusazlp170120005.outbound.protection.outlook.com
 [2a01:111:f403:c105::5])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 64d560bd-dce0-11ef-99a4-01e77a169b0f;
 Mon, 27 Jan 2025 19:56:20 +0100 (CET)
Received: from BY3PR05CA0032.namprd05.prod.outlook.com (2603:10b6:a03:39b::7)
 by BY5PR04MB6932.namprd04.prod.outlook.com (2603:10b6:a03:219::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.23; Mon, 27 Jan
 2025 18:56:13 +0000
Received: from CY4PEPF0000FCC0.namprd03.prod.outlook.com
 (2603:10b6:a03:39b:cafe::69) by BY3PR05CA0032.outlook.office365.com
 (2603:10b6:a03:39b::7) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8398.15 via Frontend Transport; Mon,
 27 Jan 2025 18:56:13 +0000
Received: from us1.smtp.exclaimer.net (191.237.4.149) by
 CY4PEPF0000FCC0.mail.protection.outlook.com (10.167.242.102) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8398.14 via Frontend Transport; Mon, 27 Jan 2025 18:56:09 +0000
Received: from BL0PR05CU006.outbound.protection.outlook.com (40.93.2.10) by
 us1.smtp.exclaimer.net (191.237.4.149) with Exclaimer Signature Manager
 ESMTP Proxy us1.smtp.exclaimer.net (tlsversion=TLS12,
 tlscipher=TLS_DIFFIEHELLMAN_WITH_AES256_NONE); Mon, 27 Jan 2025 18:56:10
 +0000
Received: from SJ0PR04MB8343.namprd04.prod.outlook.com (2603:10b6:a03:3d3::6)
 by MN2PR04MB6750.namprd04.prod.outlook.com (2603:10b6:208:19f::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.23; Mon, 27 Jan
 2025 18:56:05 +0000
Received: from SJ0PR04MB8343.namprd04.prod.outlook.com
 ([fe80::979e:f75e:9b90:1052]) by SJ0PR04MB8343.namprd04.prod.outlook.com
 ([fe80::979e:f75e:9b90:1052%4]) with mapi id 15.20.8377.021; Mon, 27 Jan 2025
 18:56:05 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 64d560bd-dce0-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=BqvKTQsHwKIRYSLrNnAlrLVdIeG+sVwoG0m8+CybLK9Idy64ZxD9/YHDUkI4LQAATNAhyj2yoVz9XYXxWXZyGo4SvTFvju5Kesr6ZSgdXQH6uLkx8rMzqj8Bd4okc86v/FLYtRVCYXVBetOt6BWVgdnvm8702XGxNL+HgPkMsMBoEZ8kxb3xYXSW1BJep2XIKxgcdW/tpvDDLsEdC0is+RD9NynHFJp41ZspR7sdBmotlVAUGgZmbtaDP9pgJqzTmefCVJAN/G36ttDfPvIj1P/U3hLTd1iSRHGUjYqs/1sVa3aAoVdFu6mrpmlk2Jk+TnDW/XuKkoDxaVmj4hRVEQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=MtaWsi7QBnTEI4vu3G8gnaRFSj1E4bvDFBEA1/fypsk=;
 b=u1F95YrCn4PZNTW4Rjdd+LTkI6YZA3kD8zoBctplm3bTwcCRVMvf2jpjonHvBYplKPs5gFjjGB8kGqLVs5rY7rZpDYftnJbjmDiVmNF19b3ML45zrecUQzqCwMPPBxDx98L2xLxwGESyhOOtriY5Cv2pPTDmZev6ff/acxrEq6kckZrZKMIyVvxBmajIpotbll6mV5ldSIPmxuipXFH3OA88bF+LyOkepK3UJV09nJGFABIU80KrYVY/YK6lYjItEr7qChaDO+3cteCfyfIuhLsRvXQdkHp8BkBXy77WxQ4qfOZJ/padz7ZEg36QE4Fatp87a2RMR5Wesdq78ADxgg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 191.237.4.149) smtp.rcpttodomain=citrix.com smtp.mailfrom=aptar.com;
 dmarc=pass (p=reject sp=reject pct=100) action=none header.from=aptar.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aptar.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=MtaWsi7QBnTEI4vu3G8gnaRFSj1E4bvDFBEA1/fypsk=;
 b=XQC4044X20+dkxJDVoxUcrj/FGm1u6qqHfH/BHo2GYE3EBsSVGRviEJSrF48wCaSMcnYYyl2UvU3iukFdHW/hKT/ZASJn07+VwYcHWc6QNSltlnkZsPWgnv4pUALeU6DGrURiJgs6JlpkRYZULELuXYvKxTl4HwAMhubSuzBURc=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 191.237.4.149)
 smtp.mailfrom=aptar.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=aptar.com;
Received-SPF: Pass (protection.outlook.com: domain of aptar.com designates
 191.237.4.149 as permitted sender) receiver=protection.outlook.com;
 client-ip=191.237.4.149; helo=us1.smtp.exclaimer.net; pr=C
X-ExclaimerHostedSignatures-MessageProcessed: true
X-ExclaimerProxyLatency: 20661893
X-ExclaimerImprintLatency: 3849405
X-ExclaimerImprintAction: e97ae8a1243143d0b04624149f191e88
From: "Katz, Jonathan" <jonathan.katz@aptar.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>, Oleksii Kurochko
	<oleksii.kurochko@gmail.com>, Xen-devel <xen-devel@lists.xenproject.org>
CC: Jan Beulich <JBeulich@suse.com>, =?iso-8859-1?Q?Roger_Pau_Monn=E9?=
	<roger.pau@citrix.com>
Subject: RE: [PATCH for-4.20] x86/intel: Fix PERF_GLOBAL fixup when
 virtualised
Thread-Topic: [PATCH for-4.20] x86/intel: Fix PERF_GLOBAL fixup when
 virtualised
Thread-Index: AQHbbBBKV+twyfPJT0qgl/gKrH7t/bMhcvcAgAkmwoCAAGb34A==
Date: Mon, 27 Jan 2025 18:56:05 +0000
Message-ID:
 <SJ0PR04MB83435FE711BB6747C6EA9F90F0EC2@SJ0PR04MB8343.namprd04.prod.outlook.com>
References: <20250121142510.358996-1-andrew.cooper3@citrix.com>
 <eb58ed74-1156-4de5-8392-a546d9afddc3@gmail.com>
 <76b3b208-a576-48f2-820b-e213722fe229@citrix.com>
In-Reply-To: <76b3b208-a576-48f2-820b-e213722fe229@citrix.com>
Accept-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=aptar.com;
x-ms-traffictypediagnostic:
	SJ0PR04MB8343:EE_|MN2PR04MB6750:EE_|CY4PEPF0000FCC0:EE_|BY5PR04MB6932:EE_
X-MS-Office365-Filtering-Correlation-Id: 377fd882-1979-4de8-046d-08dd3f0443de
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|1800799024|366016|376014|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?us-ascii?Q?HPv6Y7HsnymqNl4mEjlbZOtffVFP0FTXBJaOMy+fksyeg9yxGyxDdwsn++Pf?=
 =?us-ascii?Q?D5Gqc6Mzx5HEju9jxJo8fuFOgCisbzGWRjPSj8K/062lkU/v4QhelQHdykt4?=
 =?us-ascii?Q?lU5XKt6ljB/HBdewQcAv5HOrDz+W1F1EiD0qM7h9OMX/8LxOHXfr5+mloRbf?=
 =?us-ascii?Q?VYLjptw1x60lgejApi1KagwYC7u9kfYLW9GYtntN93Ybx22TJ2i1NgpVvBRq?=
 =?us-ascii?Q?TVs4XgFSWQC3EUTThnZDqX23gP3hEKDwwOmq7ULiV8DT1WpOhpNIRqk+FMrO?=
 =?us-ascii?Q?oEi4AtRlBULXJA+fOpatNa18AUPC/5n9XTZ5oWxbA79ZxXIKkkGe1ewYyY8C?=
 =?us-ascii?Q?q3t+hJKWoOupnQckrE8LXAJ9xJCI3OAmP/YhixIUkoeMDbCHQZkx9nbWumo2?=
 =?us-ascii?Q?aDdKxzKHMiDnXwxvjeLwp6uzkaBqDz0eiTKF77FCcbOGwyQF5/ld0caM6Jea?=
 =?us-ascii?Q?tVF3Y6dRrnxCZ+VifSaWQ6fnhvW6iJcDEvi8JaHazMMtdD2AWWlv8H0qC8t7?=
 =?us-ascii?Q?KfQBWz2TzS8qIi0MQ2HMK32h+GYQ1pou4Dv9JqoPkCCpHzZMRYl9PbmLtmZd?=
 =?us-ascii?Q?oEkrQesEKMAwn0hSrntWIdcMXLanuw+Hx2QT+qDMMCq0NjKjG2mHMDybEA4c?=
 =?us-ascii?Q?VPEXgmJriysy0vvTOwlcJoGJoHaPPjylZtHjc4D/1VQGLg4vLm7P/JklVfuL?=
 =?us-ascii?Q?gmd2Tme7un52yr5cocECuJ2cO6C23Zo0A+LnYqPrAlSkikb6UDF3o66ytr4m?=
 =?us-ascii?Q?kFn5u67Ing5EJlqodFPpmNAuMKLyA3uiLPaI+sAlJlhd8LytLiwhHx9PK5jN?=
 =?us-ascii?Q?7VcR3TngzHfqe1DBfhZH4iFIoOpp3k3O8evpH/OkVqa++DSUQSsMnBExyXIo?=
 =?us-ascii?Q?mreRHa7iP38U1BKUXnI8cipBfbkCjKrzmiQkW8VLWHxfFdJXIrlVZ1xguXo+?=
 =?us-ascii?Q?57oO/EtNUigJfN+AF6epDNSfT1iiOA4fNe94Z/+A3iROEOGwPQq2oQOMvDER?=
 =?us-ascii?Q?YzoLB8N+M1kbeA5uMBCMI9pr94p5MPlx9MIyWGbjGfEmfsz/Cv1S5DsO0k++?=
 =?us-ascii?Q?6WQTJ+WJpNcBsF0LZS7eBUifG9lwtgRhTIVOqI/yCButlgA/t7I6hRhUXFRt?=
 =?us-ascii?Q?IYW4VCto1Gv7dZNAi07gZt3geg3gfhvWlVbn8Os6M0jXtQ/L53hm34OloLun?=
 =?us-ascii?Q?pl+9/qi3HEV41DcvnOv5fPghGb0s9WrVjA2Ry+1bSsBJFAnHbAI9xWqcfFcl?=
 =?us-ascii?Q?nEg7S3EVFbsn29iwWkPYMWnPPo7VxcVH5b9c/Wf0MOuf3nabi+TOuovOlJTC?=
 =?us-ascii?Q?j3DRtWmFZAIR9vYlbIZADqtledxm7iQqPuxvHA7OKqu9db5q271k5hnJZ6Q9?=
 =?us-ascii?Q?DfaGtyL0eWms0tRDitHgwrrWSuRm6BIJkHt3UeTLFnpCXUw+hUtZmqfY0nYG?=
 =?us-ascii?Q?I/igk+rdxgtxGZ6MldMLIjgofu6vt9BE?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SJ0PR04MB8343.namprd04.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700018);DIR:OUT;SFP:1102;
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR04MB6750
Content-Type: multipart/alternative; boundary="=-zyd2Ueu4pAKVThpU39UFJQ=="
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 CY4PEPF0000FCC0.namprd03.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	a68b26a4-cd5e-4046-1a8a-08dd3f0440c1
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|35042699022|14060799003|36860700013|376014|82310400026|8096899003|13003099007|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?WWF2VnpLVUVXVlQzZVNaUXhYQVJSVCtFUGo1eWM1aHJBcERGbThXQ3Nsa2ZQ?=
 =?utf-8?B?UjVEcnVDTW9XZ1REa3BQQkxiZ2RVdU1aT1U4cWFubmZVQWJvTlAwVWRxSXR4?=
 =?utf-8?B?b3EvQjBYczRDSW42ZWgwbHdXWEtyMjVHalJVblFLdXdvR0tVVEV4SnR3V1hi?=
 =?utf-8?B?UWFIdUhtQk8rWUUwaGpCNzhGbkx1SS8zR3d5MEc1cnVNelNCdWI4TzVYYklW?=
 =?utf-8?B?d1BiY0EyNW5SQTM0TnpLcUhmV2l2bXhiTjJKbmZmRnFpZlp6eTkrbEc5QlVa?=
 =?utf-8?B?OGpDSU9JZitwNTNyZ3hWNkRqUy9oUFQyQTZpWEEzdzFxdzRVSEdYSWU1b0t5?=
 =?utf-8?B?UGNOdXVjUVd0RVVNZ3llenUyREROU3hUb1E2UlIwZ2RTWnFweUlLNWRJdW5F?=
 =?utf-8?B?TTNkKytRZ0J2M3p4S0NoRzNZTTFpcjRYaEcxZDA3bDNGa3N2cGVBaGVZYkpo?=
 =?utf-8?B?OCtvUzFUSzFOTVcxbzlMMUo3d1dVREtuSjhYSjhvaEx4ZlBxNndWeFVucTRF?=
 =?utf-8?B?cVhxS1FTUzY4NG90bG9WY3FTcmkwdkg0bCtDL21tKzRDbUlnNW9qOFVpcHBF?=
 =?utf-8?B?K1pvUnJEMG1sUWNsNllBYmV0REg4Q1pkZmNKR1NYSVVHQjZMSEFWQzZRc2Rj?=
 =?utf-8?B?a3c1LzZ4UktSN2JrT29INEhXMnY3OXBudGpBb05Uako3YmJoU0N0WnVUeHBn?=
 =?utf-8?B?eW84Wmw0Q0RGendVaktaSFIyUVM1dEdzQmFtRTBsWDVFQ3ZwMWQ1QlluTHh2?=
 =?utf-8?B?empYM0o2NlFvNnpiaWdwYVVNNGlYYmlKS2IvRlkxak40VzQ3N0tJVk8vVWRG?=
 =?utf-8?B?ZE5ZK0xhM0pwdnd5bThDYXZqWE9aUjhINS93bXNiVndZSnFRVDg1NnNBc21z?=
 =?utf-8?B?eUhydElHbjRjMUdsY0dBUVpHM1lqZUI3KzNJV2dvSlpYM2tpcmIyTTZqdDBR?=
 =?utf-8?B?dWQxR3hoU2ZYeHptcnluZC9kUlRmc0NSdHkzL0VzV2ptYTJzU1hVcmlMV0Fl?=
 =?utf-8?B?YnNwSk9KT01CMU95czhDODkzTXBXWmlkdXp0bS9BSHl3ODJwdDhzZStyOFBv?=
 =?utf-8?B?Szd0SWVIUk0wR0Y1RGlCd002S2NFcXRSUGlzQk10azViVnkyWDNGV1FvcHZ0?=
 =?utf-8?B?NENNOXBURlJLK2hnSFVhVmJVVkIzbEhyNVc2b2FDc3ZzVEVlbUlESldEbFlD?=
 =?utf-8?B?eG9oVHF5ZHRXUnJEeFU2Tks3RzBmSWgyNkZFSHpxSHpKeWhsdzhzVDU2cE84?=
 =?utf-8?B?aGN2YXZHWkZjbnA5d3F6TFBENVMweUFtS0dpWjNPM2dVd1JDQmNLZVVUWHVZ?=
 =?utf-8?B?QTk5WEdRYVZ4aWpZWUlQdWRwa0o1enJJbVJlSlZmQ1hsSXBYejlHWXNmcFdL?=
 =?utf-8?B?NTFwRmFqWFFQeE5kdC9iTXFBbDMveG93NzZOcmRlODYxZFRCd0Z2SVFKTDU5?=
 =?utf-8?B?Y0ZGMlp2aWNSczBsTG42RmNPd0N2ZmNVaUhUajhvM1BoRzhHZmJwQ1FTQW4y?=
 =?utf-8?B?Kys3ekMyUWxFNDU0aTllUUhFT3Flc2lLNktoRFRDeThrOXBJbEFMRk9IbzZP?=
 =?utf-8?B?TDBUeHNSM28xdjdDenJaR2xVeVUvSGszaWtncEl5SlB6bFQwUVF1NzJOTWo1?=
 =?utf-8?B?SnM0SU9iVE9Qam93N1VGUlQvdzJtVWVQbG1qZ1FuWnQ0QTNkWGVRN09YdVBu?=
 =?utf-8?B?Z0JINVFCOXJENkk1R2VTMS9MelZaV0lmbkd2RENLZmZUelpGVm9VRXBKZTFW?=
 =?utf-8?B?L2ZVdVV0Y2Uxd0U1K1hjbk5zVTkvdysvdFd2K0V5dmVZakFORWtKRXI0MUNt?=
 =?utf-8?B?OHJMKzRGTHVwSmVCSXI1VWNidjNwU3NKUlpqWWQxOUd4UnhRWU5XdmI4YTBG?=
 =?utf-8?B?Z1ZaN25qYUtwMVFMeUJBbjBpYWFsR0ZZNDhNdHZIc21lY0lKK3hzT285ZGdP?=
 =?utf-8?Q?lx30bvazTXg=3D?=
X-Forefront-Antispam-Report:
	CIP:191.237.4.149;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:us1.smtp.exclaimer.net;PTR:us1.smtp.exclaimer.net;CAT:NONE;SFS:(13230040)(1800799024)(35042699022)(14060799003)(36860700013)(376014)(82310400026)(8096899003)(13003099007)(7053199007);DIR:OUT;SFP:1102;
X-OriginatorOrg: aptar.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2025 18:56:09.8614
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 377fd882-1979-4de8-046d-08dd3f0443de
X-MS-Exchange-CrossTenant-Id: 5fd74a3e-d57a-410e-8d7c-02c4df062234
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5fd74a3e-d57a-410e-8d7c-02c4df062234;Ip=[191.237.4.149];Helo=[us1.smtp.exclaimer.net]
X-MS-Exchange-CrossTenant-AuthSource:
	CY4PEPF0000FCC0.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR04MB6932

--=-zyd2Ueu4pAKVThpU39UFJQ==
Content-Language: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Tested on xcp-ng vm on esx 8 that previously failed to boot when performanc=
e counters were not enabled.

- patched host
- rebooted host
- host still came up normally
- shut host down
- turned off performance counters on vm
- booted host
- host still came up normally and no issues running vms

Thanks!
jonathan


Jonathan=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B



Katz



IS Senior Specialist, Infrastructure Operations Engineer

AptarGroup

265 Exchange Drive, Suite 100

,

Crystal Lake

,

Illinois



60014

,

United States

(phone) +1 779 220 4484<tel:+1%20779%20220%204484>

 |

(mobile) +1 847 525 8441<tel:+1%20847%20525%208441>

jonathan.katz@aptar.com<mailto:jonathan.katz@aptar.com>

 |

www.aptar.com<http://www.aptar.com/>

AptarOnlineSignature

-----Original Message-----
From: Andrew Cooper <andrew.cooper3@citrix.com>
Sent: Monday, January 27, 2025 6:42 AM
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>; Xen-devel <xen-devel@lis=
ts.xenproject.org>
Cc: Katz, Jonathan <jonathan.katz@aptar.com>; Jan Beulich <JBeulich@suse.co=
m>; Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
Subject: Re: [PATCH for-4.20] x86/intel: Fix PERF_GLOBAL fixup when virtual=
ised


EXTERNAL MAIL: Do not click any links or open any attachments unless you tr=
ust the sender and know the content is safe.


On 21/01/2025 4:57 pm, Oleksii Kurochko wrote:
>
> On 1/21/25 3:25 PM, Andrew Cooper wrote:
>> Logic using performance counters needs to look at
>> MSR_MISC_ENABLE.PERF_AVAILABLE before touching any other resources.
>>
>> When virtualised under ESX, Xen dies with a #GP fault trying to read
>> MSR_CORE_PERF_GLOBAL_CTRL.
>>
>> Factor this logic out into a separate function (it's already too
>> squashed to the RHS), and insert a check of
>> MSR_MISC_ENABLE.PERF_AVAILABLE.
>>
>> This also limits setting X86_FEATURE_ARCH_PERFMON, although oprofile
>> (the only consumer of this flag) cross-checks too.
>>
>> Reported-by: Jonathan Katz <jonathan.katz@aptar.com>
>> Link:
>> https://nam02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fxcp
>> -ng.org%2Fforum%2Ftopic%2F10286%2Fnesting-xcp-ng-on-esx-8&data=3D05%7C0
>> 2%7Cjonathan.katz%40aptar.com%7Cc036df18462d402eda5608dd3ed01147%7C5f
>> d74a3ed57a410e8d7c02c4df062234%7C0%7C0%7C638735785584484308%7CUnknown
>> %7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW
>> 4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3DjG5dfAjyXvB
>> JRrtNklKp8MjGOUoYGntpD14eRP5GCcI%3D&reserved=3D0
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> ---
>> CC: Jan Beulich <JBeulich@suse.com>
>> CC: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
>> CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
>>
>> Untested, but this is the same pattern used by oprofile and watchdog
>> setup.
>
> Probably it will make sense to wait for a response on the forum (you
> mentioned in the Link:) that the current one patch works?

It's been a week. At this point it needs to go in for the release. As I sai=
d, this is exactly the same pattern as used elsewhere in Xen, so I'm confid=
ent it's a good fix, and Roger agrees too.

~Andrew
This e-mail may contain confidential information. If you are not the intend=
ed recipient, please notify the sender immediately and destroy this e-mail.=
 Any unauthorized copying, disclosure or distribution of the material in th=
is e-mail is strictly forbidden.

Aptar=E2=80=99s Privacy Policy<https://www.aptar.com/en-us/general-terms-an=
d-conditions-use.html> explains how Aptar may use your personal information=
 or data and any personal information or data provided or made available to=
 us.

--=-zyd2Ueu4pAKVThpU39UFJQ==
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8">
</head>
<body>
<div>Tested on xcp-ng vm on esx 8 that previously failed to boot when perfo=
rmance counters were not enabled.<br>
<br>
- patched host<br>
- rebooted host<br>
- host still came up normally<br>
- shut host down<br>
- turned off performance counters on vm<br>
- booted host<br>
- host still came up normally and no issues running vms<br>
<br>
Thanks!<br>
jonathan<br>
<br>
<div dir=3D"ltr" style=3D"mso-line-height-rule:exactly;-webkit-text-size-ad=
just:100%;font-size:1px;direction:ltr;">
<table dir=3D"ltr" cellpadding=3D"0" cellspacing=3D"0" border=3D"0" style=
=3D"width:100%;direction:ltr;border-collapse:collapse;font-size:1px;">
<tbody>
<tr style=3D"font-size:0;">
<td align=3D"left" style=3D"vertical-align:top;">
<table cellpadding=3D"0" cellspacing=3D"0" border=3D"0" style=3D"border-col=
lapse:collapse;font-size:0;">
<tbody>
<tr style=3D"font-size:0;">
<td align=3D"left" style=3D"padding:13px 0;vertical-align:top;">
<table cellpadding=3D"0" cellspacing=3D"0" border=3D"0" style=3D"width:0;bo=
rder-collapse:collapse;font-size:0;color:#FFFFFF;font-style:normal;font-wei=
ght:400;white-space:nowrap;">
<tbody>
<tr style=3D"font-size:0;">
<td align=3D"left" style=3D"padding:0;vertical-align:top;">
<table cellpadding=3D"0" cellspacing=3D"0" border=3D"0" style=3D"border-col=
lapse:collapse;font-size:0;">
<tbody>
<tr style=3D"font-size:0;">
<td align=3D"left" style=3D"padding:0;vertical-align:middle;">
<table cellpadding=3D"0" cellspacing=3D"0" border=3D"0" style=3D"border-col=
lapse:collapse;font-size:0;">
<tbody>
<tr style=3D"font-size:0;">
<td align=3D"left" style=3D"padding:0;vertical-align:top;">
<table cellpadding=3D"0" cellspacing=3D"0" border=3D"0" style=3D"border-col=
lapse:collapse;font-size:0;color:#5F5F5F;font-style:normal;font-weight:400;=
white-space:nowrap;">
<tbody>
<tr style=3D"font-size:14.67px;">
<td align=3D"left" style=3D"vertical-align:top;font-size:17.33px;color:#376=
05E;font-family:Arial;font-weight:700;">
<p style=3D"margin-top:0px;margin-bottom:0px;">Jonathan<span style=3D"font-=
family:remialcxesans;font-size:1px;color:#FFFFFF;line-height:1px;">=E2=80=
=8B<span style=3D"font-family:'template-KDWbeBsYEeiAwgANOhMCUQ';">=E2=80=8B=
</span><span style=3D"font-family:'zone-1';">=E2=80=8B</span><span style=3D=
"font-family:'zones-AQ';">=E2=80=8B</span></span></p>
</td>
<td align=3D"left" style=3D"vertical-align:top;font-family:Arial;">
<p style=3D"margin-top:0px;margin-bottom:0px;">&nbsp;</p>
</td>
<td align=3D"left" style=3D"vertical-align:top;font-size:17.33px;color:#376=
05E;font-family:Arial;font-weight:700;">
<p style=3D"margin-top:0px;margin-bottom:0px;">Katz</p>
</td>
<td align=3D"left" style=3D"vertical-align:top;font-family:Arial;">
<p style=3D"margin-top:0px;margin-bottom:0px;">&nbsp;&nbsp;</p>
</td>
<td align=3D"left" style=3D"vertical-align:middle;font-family:Arial;">
<p style=3D"margin-top:0px;margin-bottom:0px;">IS&nbsp;Senior&nbsp;Speciali=
st,&nbsp;Infrastructure&nbsp;Operations&nbsp;Engineer</p>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr style=3D"font-size:17.33px;color:#37605E;font-style:normal;font-weight:=
700;white-space:nowrap;">
<td align=3D"left" style=3D"padding:0;vertical-align:top;font-family:Arial;=
">
<p style=3D"margin-top:0px;margin-bottom:0px;">AptarGroup</p>
</td>
</tr>
<tr style=3D"font-size:0;">
<td align=3D"left" style=3D"padding:0;vertical-align:bottom;">
<table cellpadding=3D"0" cellspacing=3D"0" border=3D"0" style=3D"border-col=
lapse:collapse;font-size:0;color:#5F5F5F;font-style:normal;font-weight:400;=
white-space:nowrap;">
<tbody>
<tr style=3D"font-size:14.67px;">
<td align=3D"left" style=3D"vertical-align:bottom;font-family:Arial;">
<p style=3D"margin-top:0px;margin-bottom:0px;">265&nbsp;Exchange&nbsp;Drive=
,&nbsp;Suite&nbsp;100</p>
</td>
<td align=3D"left" style=3D"vertical-align:bottom;font-family:Arial;">
<p style=3D"margin-top:0px;margin-bottom:0px;">,&nbsp;</p>
</td>
<td align=3D"left" style=3D"vertical-align:bottom;font-family:Arial;">
<p style=3D"margin-top:0px;margin-bottom:0px;">Crystal&nbsp;Lake</p>
</td>
<td align=3D"left" style=3D"vertical-align:bottom;font-family:Arial;">
<p style=3D"margin-top:0px;margin-bottom:0px;">,&nbsp;</p>
</td>
<td align=3D"left" style=3D"vertical-align:bottom;font-family:Arial;">
<p style=3D"margin-top:0px;margin-bottom:0px;">Illinois</p>
</td>
<td align=3D"left" style=3D"vertical-align:bottom;font-family:Arial;">
<p style=3D"margin-top:0px;margin-bottom:0px;">&nbsp;</p>
</td>
<td align=3D"left" style=3D"vertical-align:bottom;font-family:Arial;">
<p style=3D"margin-top:0px;margin-bottom:0px;">60014</p>
</td>
<td align=3D"left" style=3D"vertical-align:bottom;font-family:Arial;">
<p style=3D"margin-top:0px;margin-bottom:0px;">,&nbsp;</p>
</td>
<td align=3D"left" style=3D"vertical-align:bottom;font-family:Arial;">
<p style=3D"margin-top:0px;margin-bottom:0px;">United&nbsp;States</p>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr style=3D"font-size:0;">
<td align=3D"left" style=3D"padding:0;vertical-align:bottom;">
<table cellpadding=3D"0" cellspacing=3D"0" border=3D"0" style=3D"border-col=
lapse:collapse;font-size:0;color:#000001;font-style:normal;font-weight:400;=
white-space:nowrap;">
<tbody>
<tr style=3D"font-size:14.67px;">
<td align=3D"left" style=3D"vertical-align:bottom;font-family:Arial;">
<p style=3D"margin-top:0px;margin-bottom:0px;">(phone)&nbsp;<a href=3D"tel:=
+1%20779%20220%204484" target=3D"_blank" id=3D"LPlnk689713" style=3D"text-d=
ecoration:none;color:#000001;">+1&nbsp;779&nbsp;220&nbsp;4484</a></p>
</td>
<td align=3D"left" style=3D"vertical-align:middle;font-family:Arial;">
<p style=3D"margin-top:0px;margin-bottom:0px;">&nbsp;<span style=3D"color:#=
37605E;font-size:17.33px;font-weight:700;">|&nbsp;</span></p>
</td>
<td align=3D"left" style=3D"vertical-align:bottom;font-family:Arial;">
<p style=3D"margin-top:0px;margin-bottom:0px;">(mobile)&nbsp;<a href=3D"tel=
:+1%20847%20525%208441" target=3D"_blank" id=3D"LPlnk689713" style=3D"text-=
decoration:none;color:#000001;">+1&nbsp;847&nbsp;525&nbsp;8441</a></p>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr style=3D"font-size:0;">
<td align=3D"left" style=3D"padding:0;vertical-align:top;">
<table cellpadding=3D"0" cellspacing=3D"0" border=3D"0" style=3D"border-col=
lapse:collapse;font-size:0;color:#000001;font-style:normal;font-weight:700;=
white-space:nowrap;">
<tbody>
<tr style=3D"font-size:14.67px;">
<td align=3D"left" style=3D"vertical-align:bottom;font-family:Arial;">
<p style=3D"margin-top:0px;margin-bottom:0px;"><a href=3D"mailto:jonathan.k=
atz@aptar.com" target=3D"_blank" id=3D"LPlnk689713" style=3D"text-decoratio=
n:none;color:#37605E;"><span style=3D"text-decoration:underline;">jonathan.=
katz@aptar.com</span></a></p>
</td>
<td align=3D"left" style=3D"vertical-align:middle;font-family:Arial;font-we=
ight:400;">
<p style=3D"margin-top:0px;margin-bottom:0px;">&nbsp;<span style=3D"font-we=
ight:700;color:#37605E;font-size:17.33px;">|&nbsp;</span></p>
</td>
<td align=3D"left" style=3D"vertical-align:bottom;font-family:Arial;">
<p style=3D"margin-top:0px;margin-bottom:0px;"><a href=3D"http://www.aptar.=
com/" target=3D"_blank" id=3D"LPlnk689713" title=3D"www.aptar.com" style=3D=
"text-decoration:none;color:#37605E;"><span style=3D"text-decoration:underl=
ine;">www.aptar.com</span></a></p>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr style=3D"font-size:1.33px;">
<td align=3D"left" style=3D"padding:13px 0 0;vertical-align:top;font-family=
:Arial;">
<p style=3D"margin-top:0px;margin-bottom:0px;">AptarOnlineSignature</p>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
</div>
-----Original Message-----<br>
From: Andrew Cooper &lt;andrew.cooper3@citrix.com&gt; <br>
Sent: Monday, January 27, 2025 6:42 AM<br>
To: Oleksii Kurochko &lt;oleksii.kurochko@gmail.com&gt;; Xen-devel &lt;xen-=
devel@lists.xenproject.org&gt;<br>
Cc: Katz, Jonathan &lt;jonathan.katz@aptar.com&gt;; Jan Beulich &lt;JBeulic=
h@suse.com&gt;; Roger Pau Monn=C3=A9 &lt;roger.pau@citrix.com&gt;<br>
Subject: Re: [PATCH for-4.20] x86/intel: Fix PERF_GLOBAL fixup when virtual=
ised<br>
<br>
<br>
EXTERNAL MAIL: Do not click any links or open any attachments unless you tr=
ust the sender and know the content is safe.<br>
<br>
<br>
On 21/01/2025 4:57 pm, Oleksii Kurochko wrote:<br>
&gt;<br>
&gt; On 1/21/25 3:25 PM, Andrew Cooper wrote:<br>
&gt;&gt; Logic using performance counters needs to look at <br>
&gt;&gt; MSR_MISC_ENABLE.PERF_AVAILABLE before touching any other resources=
.<br>
&gt;&gt;<br>
&gt;&gt; When virtualised under ESX, Xen dies with a #GP fault trying to re=
ad <br>
&gt;&gt; MSR_CORE_PERF_GLOBAL_CTRL.<br>
&gt;&gt;<br>
&gt;&gt; Factor this logic out into a separate function (it's already too <=
br>
&gt;&gt; squashed to the RHS), and insert a check of <br>
&gt;&gt; MSR_MISC_ENABLE.PERF_AVAILABLE.<br>
&gt;&gt;<br>
&gt;&gt; This also limits setting X86_FEATURE_ARCH_PERFMON, although oprofi=
le <br>
&gt;&gt; (the only consumer of this flag) cross-checks too.<br>
&gt;&gt;<br>
&gt;&gt; Reported-by: Jonathan Katz &lt;jonathan.katz@aptar.com&gt;<br>
&gt;&gt; Link: <br>
&gt;&gt; https://nam02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%=
2Fxcp<br>
&gt;&gt; -ng.org%2Fforum%2Ftopic%2F10286%2Fnesting-xcp-ng-on-esx-8&amp;data=
=3D05%7C0<br>
&gt;&gt; 2%7Cjonathan.katz%40aptar.com%7Cc036df18462d402eda5608dd3ed01147%7=
C5f<br>
&gt;&gt; d74a3ed57a410e8d7c02c4df062234%7C0%7C0%7C638735785584484308%7CUnkn=
own<br>
&gt;&gt; %7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJ=
XaW<br>
&gt;&gt; 4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&amp;sdata=3DjG=
5dfAjyXvB<br>
&gt;&gt; JRrtNklKp8MjGOUoYGntpD14eRP5GCcI%3D&amp;reserved=3D0<br>
&gt;&gt; Signed-off-by: Andrew Cooper &lt;andrew.cooper3@citrix.com&gt;<br>
&gt;&gt; ---<br>
&gt;&gt; CC: Jan Beulich &lt;JBeulich@suse.com&gt;<br>
&gt;&gt; CC: Roger Pau Monn=C3=A9 &lt;roger.pau@citrix.com&gt;<br>
&gt;&gt; CC: Oleksii Kurochko &lt;oleksii.kurochko@gmail.com&gt;<br>
&gt;&gt;<br>
&gt;&gt; Untested, but this is the same pattern used by oprofile and watchd=
og <br>
&gt;&gt; setup.<br>
&gt;<br>
&gt; Probably it will make sense to wait for a response on the forum (you <=
br>
&gt; mentioned in the Link:) that the current one patch works?<br>
<br>
It's been a week. At this point it needs to go in for the release. As I sai=
d, this is exactly the same pattern as used elsewhere in Xen, so I'm confid=
ent it's a good fix, and Roger agrees too.<br>
<br>
~Andrew<br>
</div>
This e-mail may contain confidential information. If you are not the intend=
ed recipient, please notify the sender immediately and destroy this e-mail.=
 Any unauthorized copying, disclosure or distribution of the material in th=
is e-mail is strictly forbidden.
<p><span style=3D"font-size: xx-small;"><span class=3D"SpellE"><em><span la=
ng=3D"EN-US">Aptar=E2=80=99s</span></em></span><em><span lang=3D"EN-US">&nb=
sp;<a href=3D"https://www.aptar.com/en-us/general-terms-and-conditions-use.=
html">Privacy Policy</a>&nbsp;</span></em><em><span lang=3D"EN-US">explains
 how Aptar may use your personal information or data and any personal infor=
mation or data provided or made available to us.</span></em></span></p>
</body>
</html>

--=-zyd2Ueu4pAKVThpU39UFJQ==--


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 21:58:42 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 21:58:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878202.1288371 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcX7j-0000GK-WA; Mon, 27 Jan 2025 21:58:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878202.1288371; Mon, 27 Jan 2025 21:58:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcX7j-0000G6-Ta; Mon, 27 Jan 2025 21:58:27 +0000
Received: by outflank-mailman (input) for mailman id 878202;
 Mon, 27 Jan 2025 21:58:26 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=zo7v=UT=gmail.com=julien.grall.oss@srs-se1.protection.inumbo.net>)
 id 1tcX7i-0000EV-Fh
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 21:58:26 +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 d4ffa7db-dcf9-11ef-a0e6-8be0dac302b0;
 Mon, 27 Jan 2025 22:58:25 +0100 (CET)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-38633b5dbcfso5610264f8f.2
 for <xen-devel@lists.xenproject.org>; Mon, 27 Jan 2025 13:58:25 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: d4ffa7db-dcf9-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1738015104; x=1738619904; 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=CRRhXBF8ZIb57xxdi9/MoA8creev6fLxGDCyaxCqyjk=;
        b=MDqtHQCGXrNvQvPFxXHYA/MvD0XgUPIGijRW8LyoybtIjEcvj3Lc2pRO3HFfnsx0LT
         dSbtKZ3oAMJGx0vJC4p5XoR1PGG2i9nZOm7Z6buXyhyrpu+I192NetJ+lEBTSk2onbjh
         A/93PyfDaIrvM4hRaEG8kdcsbycIEeB21AuSoyZVpFk+AJ3FkI6AnbnYKBfdknULaLs1
         68Dz6iwMUb/IyUkwqLf6ge0na0t3eJyM4SWX5hPhllCNiBQnJA1DuHuHXXv3bUku4FNK
         gUtWjegQX8p1fxMJyTGeTWiOjRXR6OdBPRJwJlEQ9l9Qn85n5IZ4z6rNkcOmOyK0x0+j
         NtgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738015104; x=1738619904;
        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=CRRhXBF8ZIb57xxdi9/MoA8creev6fLxGDCyaxCqyjk=;
        b=hCmqU9gm/aENvQDuRxgtiZwjjJtW0L5VWcKm/XkLswSl++CbuYBlB5lY6q70oPb536
         OCdrA507fOgIhMmWFhkRVC8j+gzbn8ODKlannZwXU9SaKQTtkyCB/5Vcnx7rB4c+/JfN
         4yCGgs1jOSXkmV0cPBZazKoCTn10LdJCjwtWyF8D5eLI7Z5naTVvyjRF0av5n/mVHz2P
         mDLYwxqY6i8q4V6BU6tGvujqGocX12SLEUVk/9onxuE7sp1OEVNAQxDTKQP1dweXbPRa
         dVGdG87rBOakHvuLheIk464rTCmjOlDEGZ8hE17oV3dhmi4tHCivG2+6kYxgswQC9b+u
         Mc3g==
X-Gm-Message-State: AOJu0Yyvm7n+ZTPXlrSxx6HlKMj1NrjCUHw6QE9ksIDkWwNpCjOLUe/S
	OuDtetSgRyXQqvvjgl1MmzXWqB4Pt+6MHFg5TRaomS73/aNKYQ+bhRIAyofeRutIICicIAyOsBH
	wj9WCtAqTZiRs/FyKQA9DITHsung=
X-Gm-Gg: ASbGnctAeiJ+DuaM+bJ4y4xu+ngvBSvHreNyOw3as2IN7F5nb+Yx3Z7SoHJDz9edjaR
	J4bTqQOqP2Lgo29ZcgYkRl+NSwcrypsAInC+Js5wnPodIrIvu0rm7i8mq5/HD
X-Google-Smtp-Source: AGHT+IEqdNrJLbpHoVb5TRNs2QvG9PLt7XaxsPHfDx2lW2idwUYR29a6zWEWhxl02wd8iLxjwvw98X9UD9L2jh5c+Xo=
X-Received: by 2002:a05:6000:188f:b0:385:d143:138b with SMTP id
 ffacd0b85a97d-38bf57be390mr47900353f8f.51.1738015104352; Mon, 27 Jan 2025
 13:58:24 -0800 (PST)
MIME-Version: 1.0
References: <20250127104556.175641-1-michal.orzel@amd.com> <20250127104556.175641-2-michal.orzel@amd.com>
 <CAJ=z9a24=PE-3bhmZvfTaTgpdCXp9iDTWfoH-9F9-_OdkEf4Tg@mail.gmail.com>
 <32d42df5-08d9-4670-a571-ef315897514b@amd.com> <CAJ=z9a3gN0NyuvVQfEW2v9H9F5ZUhHB9+LvK4viQhSm6A=hauA@mail.gmail.com>
 <7fff37b8-9698-44ef-aa42-f1652ea3498c@amd.com>
In-Reply-To: <7fff37b8-9698-44ef-aa42-f1652ea3498c@amd.com>
From: Julien Grall <julien.grall.oss@gmail.com>
Date: Mon, 27 Jan 2025 18:58:12 -0300
X-Gm-Features: AWEUYZlAzu8yvtq5gUtKor8AQO0J64i7OgSVKbnDKGYGBE9Sd93qlt_5D50iCvE
Message-ID: <CAJ=z9a3fFB2tnmm8qp8yx+OmL45YFcv5JKqD8fVHby+of3wn+A@mail.gmail.com>
Subject: Re: [for-4.20][PATCH 1/2] device-tree: bootfdt: Fix build issue when CONFIG_PHYS_ADDR_T_32=y
To: Michal Orzel <michal.orzel@amd.com>
Cc: xen-devel@lists.xenproject.org, 
	Stefano Stabellini <sstabellini@kernel.org>, Bertrand Marquis <bertrand.marquis@arm.com>, 
	oleksii.kurochko@gmail.com
Content-Type: multipart/alternative; boundary="000000000000e8cee1062cb72c04"

--000000000000e8cee1062cb72c04
Content-Type: text/plain; charset="UTF-8"

Hi Michal,

On Mon, 27 Jan 2025 at 14:15, Michal Orzel <michal.orzel@amd.com> wrote:

> > I think it needs to be rephrased to make clear the alignment of  struct
> membanks should be the same as struct membank.
> Shouldn't this check therefore be changed to:
> BUILD_BUG_ON(alignof(struct membanks) != alignof(struct membank));



Yes it should be changed.

Cheers,


>
> ~Michal
>

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

<div dir=3D"auto">Hi Michal,</div><div><br><div class=3D"gmail_quote gmail_=
quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, 27 Jan 2025 =
at 14:15, Michal Orzel &lt;<a href=3D"mailto:michal.orzel@amd.com">michal.o=
rzel@amd.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex" dir=3D"=
auto">&gt; I think it needs to be rephrased to make clear the alignment of =
=C2=A0struct membanks should be the same as struct membank.<br>
Shouldn&#39;t this check therefore be changed to:<br>
BUILD_BUG_ON(alignof(struct membanks) !=3D alignof(struct membank));</block=
quote><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"a=
uto">Yes it should be changed.</div><div dir=3D"auto"><br></div><div dir=3D=
"auto">Cheers,</div><div dir=3D"auto"><br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex" dir=3D"auto"><br>
<br>
~Michal<br>
</blockquote></div></div>

--000000000000e8cee1062cb72c04--


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 23:33:42 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 23:33:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878215.1288380 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcYbg-000368-KK; Mon, 27 Jan 2025 23:33:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878215.1288380; Mon, 27 Jan 2025 23:33:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcYbg-000361-Hi; Mon, 27 Jan 2025 23:33:28 +0000
Received: by outflank-mailman (input) for mailman id 878215;
 Mon, 27 Jan 2025 23:33:27 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=naHB=UT=amd.com=Jason.Andryuk@srs-se1.protection.inumbo.net>)
 id 1tcYbf-00034M-Er
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 23:33:27 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20616.outbound.protection.outlook.com
 [2a01:111:f403:2417::616])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 19d078d7-dd07-11ef-a0e6-8be0dac302b0;
 Tue, 28 Jan 2025 00:33:25 +0100 (CET)
Received: from BN9PR03CA0851.namprd03.prod.outlook.com (2603:10b6:408:13d::16)
 by IA0PR12MB8422.namprd12.prod.outlook.com (2603:10b6:208:3de::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.22; Mon, 27 Jan
 2025 23:33:19 +0000
Received: from BN1PEPF00004686.namprd03.prod.outlook.com
 (2603:10b6:408:13d:cafe::8a) by BN9PR03CA0851.outlook.office365.com
 (2603:10b6:408:13d::16) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8356.21 via Frontend Transport; Mon,
 27 Jan 2025 23:33:19 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BN1PEPF00004686.mail.protection.outlook.com (10.167.243.91) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8398.14 via Frontend Transport; Mon, 27 Jan 2025 23:33:19 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 27 Jan
 2025 17:33:19 -0600
Received: from [172.25.15.116] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Mon, 27 Jan 2025 17:33:18 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 19d078d7-dd07-11ef-a0e6-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=XUuDqzaB0Zi2V6w0DABju2xfmlmuidoLoWkB8w7kqmKSRF2xUkdMe3zdl7KMmqORYFELORdeBhnHMvwtwuzGpt9QwYuxANWIbLJqt0R+QSq4A43ipAfIUtB3eXzHvixaf8LNwoRx9U6hUa2ZccuW+zJp6WsXO3nSv1eyzAJNfJv5X34lSHEsOJPJkiT0wAQ1/1VMSsMRchl9j1vd9R+1F+c6b6vWvaELyeWao+5ws7X5lDXQgUmOEQnaO2O2OFh15m8q+fzCwjpcIOcd4TI8ZixqT7ljm+MLUrNulMe9D3PpZE7oz0yPXY/Me18Vzf6+ednzd/TU3uk6RLSht7UIhQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=6k4DeMismfzkqkCW0o6yQxdPhpIslPeKiYHO5MWffsI=;
 b=h9Jmfy1DoEpBe2/t+MwYHc0cpl0oMs1x2daGxGz7eSRwUjOYS1wQgU6Q2DGkZ8b/UioXQLvaCoY54YduSEb9g/9jKbyEyhVPiIKe1icRE+yI8Tt7LytFOK2GbxTueGwx76YjqKyPbQBlLtJZ5PDmEKcrLe+zm91qPnAruclP+m0i4qyKkPXbnYNizHLes2Shhe7w6tgTYlPSQrLjyQaPXTRHgYSU0MTMM+mRn0TTsyc6ihS0jpVawM6SVmWarHilwhPFXvxdTINvZh3cDhrQUdspL5g5+bKBxmF6Nw1nCB97ip9mG8um8E2WjJXx13TzGVlKqUenV/diN1e1LXlGsA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=ford.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=6k4DeMismfzkqkCW0o6yQxdPhpIslPeKiYHO5MWffsI=;
 b=MFnfslIvw9IC/OrLgaqa/Uh6DJkjmySbwSd37Q0y3ERYtxK9DU1nbBEH+i64bANBtdbInnXhH9tVwUxaR5OnmwaESaPvBuIfnZQEzsPH7idRGOXXLsouGiMy8m4AkoQPW5ZjapCNeB/sfVqDPCQ9cn3eyS8x4FnzY/7x5jARAFA=
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: <228a7d42-682d-4898-be1b-03fdd257ad70@amd.com>
Date: Mon, 27 Jan 2025 17:58:06 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 03/24] arm/vuart: add hwdom prefix to UART emulator
To: <dmukhin@ford.com>, <xen-devel@lists.xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
	<julien@xen.org>, Michal Orzel <michal.orzel@amd.com>, Andrew Cooper
	<andrew.cooper3@citrix.com>, Anthony PERARD <anthony.perard@vates.tech>, "Jan
 Beulich" <jbeulich@suse.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
	<roger.pau@citrix.com>
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
 <20250103-vuart-ns8250-v3-v1-3-c5d36b31d66c@ford.com>
Content-Language: en-US
From: Jason Andryuk <jason.andryuk@amd.com>
In-Reply-To: <20250103-vuart-ns8250-v3-v1-3-c5d36b31d66c@ford.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB03.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN1PEPF00004686:EE_|IA0PR12MB8422:EE_
X-MS-Office365-Filtering-Correlation-Id: 500ef756-189f-4a3f-a717-08dd3f2afb9b
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|36860700013|82310400026|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?NDFuWUpzWVJ4d0pDd2o1OWlGWVFwUUhqeWtVZTkwa0U3elpMZk9kWkFLTDRo?=
 =?utf-8?B?R3AwbjZpQWl3Q1hOREZUNm9XRXhYVCsyME9KZnpZZHJUc040VEsySlJYM2RD?=
 =?utf-8?B?ZTBvVHZnSHFURG1XU0hlcVhDa0NoUDBYQ3hKWWErRVc5MjhaUmE0SkJ0dGYy?=
 =?utf-8?B?VE10SEFDK2loays2SVRhUjcrcGJTRk9SaUxNOC96TTJDL0M1Z2ZoWXdvWnh5?=
 =?utf-8?B?N2RRUjlFY3RYY05OSndHd1VYVncyLzdSb1FKYjFHRW1sOXhwL2Y3cVdlWjJT?=
 =?utf-8?B?TGtMWE0xSFZOcTFadHpRVm4wTTQyQyt6ckl5VUtzNlhNRTF1TkR6MXRTQStF?=
 =?utf-8?B?Q0lCbE1pUVlDSDNSNlhPazFTbnR2SFlNRVJ1Y09MREw4V01PaEg1eG5tTTFt?=
 =?utf-8?B?NVNnRGRHS3I2WHVVdlJvdkYxNElHRVVkT2ZRY2Q2WjZNNUoraGt3M3EvMWZh?=
 =?utf-8?B?QjdRMnlaY0ZZdGNsVzRuVGVzcUtqbVNiU2lORjhEOXhpM0VGMXhaTktuMVM4?=
 =?utf-8?B?UFlRMndCVXdXVkNjb0hjZ3lrZG9wdXFJVWc3RzB6M2tERzJzUndUdFBjcElr?=
 =?utf-8?B?V0MvWEV0K0xZWVRnZXdTdjRUay9QeWRrcUt6Q0ltbTJyc294aG5ZL2djV0F2?=
 =?utf-8?B?RFh2RkdSRis2ZThYS0dTa0lLc0lCMFg0MUVNazNtWCtoM0E0WEQ2UE9pak1p?=
 =?utf-8?B?ZmF3cEtUNHpMQzROQUFJUW4xbDZUUElzMWFxd2JCNkJ0V0N3a2hsdStrcmJN?=
 =?utf-8?B?WUViU28zOHpkTW9xcGFmaHdIV2tkY3dvNytsWGE4cUtVUHA2UVVKM0JQbkFa?=
 =?utf-8?B?WHN6a0NzSTMydUJsYnYweWRDYVFodGp0dEhwSzhLTGlpY3pyc2NWVnpjenZk?=
 =?utf-8?B?c1NvMzdEZ01DQTluS1Z5TDZzMkZiT0FXVVNSb0ZyaVlyaldmRG1FZnRUU3FN?=
 =?utf-8?B?Y3dGdGdVbXdHUm02TmZONXV2azdUbURaRUluaEp4TlpiL29xeGtRR1VhMTJO?=
 =?utf-8?B?NlcxNEdUcGdvdWgwUXJaS0VrQmRRb1h5K2k4azRxTENyUXM4cEd5VFZQUjdx?=
 =?utf-8?B?ZnZyd3NUVW1IOEZ1M0taOGt1ZnB3TC9IYmU4bmZ6bXJGL0F3Z2VjbEx5WE8w?=
 =?utf-8?B?VVYzaCtpWGFCY3N1N251L29ON0ZTaFJwTmdOaWtMTk9MdDJ3UG0zR2Y5eUxW?=
 =?utf-8?B?b1pRRDhTT0w1UlBHRmR0eDVDY3JVUkRCQkp1UEc0MTlxblJCcE5HVktCOWlC?=
 =?utf-8?B?M3hsM1Y4Q08yNzU5elpFdXZKQ0pFV2E4ZG5Cc1V6Ynd5MzFXMEpUZVFDM0RL?=
 =?utf-8?B?UGZyZlVpRHdEYmtLaEZ5clh0MzdCK3BkeWJsQ1gvUHE3cy9TSXU4NTN5eEtY?=
 =?utf-8?B?dS9TN3lTTmh5Y1N2Y2xVU3BoenBQc1VFcisxTmVQbmNsRW1lWG95YnpEOVlN?=
 =?utf-8?B?T21zQVpkbDhrQnhkQlBWYktobkE3SFJVdTZMRURJWVlPOFdzd2NPdVBYUysr?=
 =?utf-8?B?OXBwdEZKeU5BSlk1RXM4WFZOSUtFU1NKSzRHdkovOEpQSDdCQWxBTjlkbnRj?=
 =?utf-8?B?bG52MVdTUkdaVlVUSjBpeVhRMFY2QWxzaWt6OUtEdnpuZXVjQ0FtSmQrKzkw?=
 =?utf-8?B?eHhWeXdYYjNmaWtqclhXSkRTeGxZYWFVVjg1eVpOWlhHTXlrR0pxMFo1R0Vy?=
 =?utf-8?B?RTJhcmliRXlEbDdHL1NDMUpXUDlCa2ZDS1ViMTd1bVRWZnBITWZWYllyR2F4?=
 =?utf-8?B?eXdaRit4M0lCMnAwL2htMTNNdTQrM2M3bzVMYTZDVC9iMkM4Y282VUtDcTlJ?=
 =?utf-8?B?bjdnQjdwTFBCYkNjV0Z4RHJzVzIxZTNsajVpakRuWHgxc0lxcXpFdXRsdXQv?=
 =?utf-8?B?Mkp2S1ovQTJTWWNoR3hiQlEzQW9VUVY2QmJtU2hOYzE3YlYyb1I1V1pJNWlY?=
 =?utf-8?B?MWhrQ1hFZXhCaUQwUjBTVCtZYktYNXlCc0tuRC9ETGc0byt6eVVqVE1OTHFK?=
 =?utf-8?Q?KA4gdC74wgGId5Sxffv4lU2YX+pkEQ=3D?=
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:(13230040)(1800799024)(376014)(36860700013)(82310400026)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2025 23:33:19.8155
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 500ef756-189f-4a3f-a717-08dd3f2afb9b
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:
	BN1PEPF00004686.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB8422

On 2025-01-03 20:58, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin <dmukhin@ford.com>
> 
> Using "vuart" in UART emulator designed for hardware domain debugging
> is confusing in generic Arm code (e.g. vpl011 is also "vuart").
> Fix that by adding hwdom prefix to all symbols in arm/vuart.c.
> 
> Also, remove domain_has_vuart() from arm/vuart.c since it is not needed.
> 
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>

> diff --git a/xen/arch/arm/vuart.c b/xen/arch/arm/vuart.c
> index 98a65b99385a2a119725bab8634ed7cf9d926d68..23e05dba3a5617863f6c08f085c358f2cf32a292 100644
> --- a/xen/arch/arm/vuart.c
> +++ b/xen/arch/arm/vuart.c

> @@ -66,15 +64,12 @@ int domain_vuart_init(struct domain *d)
>       return 0;
>   }
>   
> -void domain_vuart_free(struct domain *d)
> +void hwdom_vuart_free(struct domain *d)
>   {
> -    if ( !domain_has_vuart(d) )
> -        return;
> -
> -    xfree(d->arch.vuart.buf);
> +    XFREE(d->arch.vuart.buf);

I guess the code before and now both relied on struct domain being 
zero-initialized.  You've made the free depend on the actual buffer 
instead of info as a proxy.

Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>

Regards,
Jason



From xen-devel-bounces@lists.xenproject.org Mon Jan 27 23:42:41 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 23:42:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878224.1288391 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcYkW-0004fR-EP; Mon, 27 Jan 2025 23:42:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878224.1288391; Mon, 27 Jan 2025 23:42:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcYkW-0004fK-Bd; Mon, 27 Jan 2025 23:42:36 +0000
Received: by outflank-mailman (input) for mailman id 878224;
 Mon, 27 Jan 2025 23:42:35 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=naHB=UT=amd.com=Jason.Andryuk@srs-se1.protection.inumbo.net>)
 id 1tcYkV-0004fE-5w
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 23:42:35 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on20612.outbound.protection.outlook.com
 [2a01:111:f403:2408::612])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 61bc4cde-dd08-11ef-a0e6-8be0dac302b0;
 Tue, 28 Jan 2025 00:42:34 +0100 (CET)
Received: from PH7P221CA0060.NAMP221.PROD.OUTLOOK.COM (2603:10b6:510:33c::16)
 by MN2PR12MB4376.namprd12.prod.outlook.com (2603:10b6:208:26c::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.23; Mon, 27 Jan
 2025 23:42:28 +0000
Received: from MWH0EPF000A6733.namprd04.prod.outlook.com
 (2603:10b6:510:33c:cafe::fb) by PH7P221CA0060.outlook.office365.com
 (2603:10b6:510:33c::16) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8377.23 via Frontend Transport; Mon,
 27 Jan 2025 23:42:27 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 MWH0EPF000A6733.mail.protection.outlook.com (10.167.249.25) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8398.14 via Frontend Transport; Mon, 27 Jan 2025 23:42:27 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 27 Jan
 2025 17:42:26 -0600
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB06.amd.com
 (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 27 Jan
 2025 17:42:26 -0600
Received: from [172.25.15.116] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Mon, 27 Jan 2025 17:42:25 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 61bc4cde-dd08-11ef-a0e6-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=k0QeBbjtED0/qTvjV3EJc9nEcaHLHUOvNAiltikSz3qhwRqpw8Gg1f40Yf4Q8m20ZF6hof+1qg57g8iq71aE2hCYo3CBNojD42zkds0RdhpTxTjR5PO7IZ14lB2zjpijrTHcE4wDVfSLu3oyw2YG2AMvXXm5HUzAJVX9j20tvQMtvLjkki+VmcovH3EDOIVZ4/R+e7YkffUKQGSKu0Wyqem2QrAHwSDsCdVpE9Pdt8nnnNHJFaqUAexYuTvq88hA55L8vRrNUa9Izze4XbgUF2EvbAT0L/3dDcID7OD0+fGVsDPmkyJBm/jeEdZbUj3u6kW2z9IWOGloYzICwRzx7Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=TirXJZjTRGRvx07tf5vGQzHCNzL4jWXylt3e+EN4K1I=;
 b=I/TvooH3icUXftP8J24Bm07IaAmZ5+KlYCzR6WdelN/P66vjNhOOoAlDUpDAOQd/neSMhev5o0T8pg0G96I4k4kl5MxaK0rppJRE84p4AEnUA3wlcGNnXcyYLoEKq1mF/RyF8bRRocdXJ0dqg8ZnXvsfK/8qL/aYspw0bAmadvDa4nGoE7Qed8KAgJe80uWb1qhuCQr2y1gpknsGu2dbFS/ykn3yIVit2dvY+lxibSrNG7Owh6bvBxfY36MzdzbereutErFIoOr6V9wGgl07h0+gHT8j3k+jtnDbenqN57geqAIC78MtjPpH7f1hO4lHlcVBz/Lg4NCK7jGIInpqAQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=ford.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=TirXJZjTRGRvx07tf5vGQzHCNzL4jWXylt3e+EN4K1I=;
 b=rTyfzsgC9M+GfxiUjDQuWC3T+eOTmX8Ee76DH+GOw73Jj/qCaXVpvTLxXX/VqUiMHxr+36r6UimRPEMdrXkT0OfnLQY+/qGXLEhWrdOBm2GPID+AJMOpfiE8cGy+LitPnEE/+odQATp7vda3mLhzpM8Hg0KJ579HiMLhGZoUnY0=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <2e246050-94db-446f-a6ce-d82c63888cbf@amd.com>
Date: Mon, 27 Jan 2025 18:07:13 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 04/24] xen/console: introduce
 console_{get,put}_domain()
To: <dmukhin@ford.com>, <xen-devel@lists.xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
	<julien@xen.org>, Michal Orzel <michal.orzel@amd.com>, Andrew Cooper
	<andrew.cooper3@citrix.com>, Anthony PERARD <anthony.perard@vates.tech>, "Jan
 Beulich" <jbeulich@suse.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
	<roger.pau@citrix.com>
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
 <20250103-vuart-ns8250-v3-v1-4-c5d36b31d66c@ford.com>
Content-Language: en-US
From: Jason Andryuk <jason.andryuk@amd.com>
In-Reply-To: <20250103-vuart-ns8250-v3-v1-4-c5d36b31d66c@ford.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MWH0EPF000A6733:EE_|MN2PR12MB4376:EE_
X-MS-Office365-Filtering-Correlation-Id: 0059da27-334e-4cb2-5c36-08dd3f2c4212
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|36860700013|82310400026|1800799024|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?OFpVVVlKMVZrZEdUYjVEVjFaTW9nbXJOV3NKMld1MGdheHlWdWFzU2U3Y0xv?=
 =?utf-8?B?YnVhMFJQcnNteG5sTHprYUxUK2x0QnpSS1l0N3IxbENGRTRGTHoyWkI3UDd3?=
 =?utf-8?B?RlMwMGhPSmhzc21lT1IySW42aHd2VGdKVkFRblVKd0YrUTdYZ2pJd3FmczdL?=
 =?utf-8?B?Vzh5TWgraFpXUjhlZUNNcEJnbFNQSGdNcXplazBhZElQeUhKNEZlZFNiZDkr?=
 =?utf-8?B?OEo2bjk4NUkySkJHaDhkVWNNVjBGZEoyN0s1Nm1iRmUwQTIxSUlCVlVKaWtW?=
 =?utf-8?B?WWZhUHJzWTliL1haSDFtOEI3Vkl1NjRaTGxNalBFMmtoRVlSUGxVbG5Nekx1?=
 =?utf-8?B?UVpwcHFwYngrTzkySk43S096a25Vd0Y5QjVmdTloUmxwVjFCalZiT3JFNkhU?=
 =?utf-8?B?OE9WNG5tUGl4YmZrODFmWUwrUExrSW5mN1hPeWl2MzgyZks0WjgwNjdTL3h5?=
 =?utf-8?B?YkxXczFrMnNHSkw1M1R3aGFWamxXbmZYS0I5d0VDVFJnSHhnWGpYaHRSTDJ2?=
 =?utf-8?B?NjJHRm9IblNvZUhBbkkwNmQyUmVzRnVBczlaUUo1VzR1R09EZmk3d0g2YVU3?=
 =?utf-8?B?V2FzRGNpdTljVEx4RDRwMmZVemRvb0EweUoycUlDaGFLRisrT1RJeHlSNkdQ?=
 =?utf-8?B?UzNObHNVWHYrejErN2pRNzJya2d6YmpiOXZJeDQ0dVk1MXEwUUppeU5iWnRJ?=
 =?utf-8?B?K0l5UytNMGZVWXFFSkswSDRkRkxQREZkQVdLWGlhMVJRUDNSNXNleVdiZHJE?=
 =?utf-8?B?U2d3dXRrQWYvTVpydG1iWDhMV2UzTEJ6dmVUdlVZQXZQNjlVN2JnZnVzeWlk?=
 =?utf-8?B?Z0JLcUcraENHNUJzRHVvRmVTNmQzUmFjT29oR0lqeHp2cVBsUEt3d1NnaXBE?=
 =?utf-8?B?RVFhWDBvZ0lSYVBpMGNVNDBPcVhZbVB4OGFoYStXamdORjgreTIyVXhIUitQ?=
 =?utf-8?B?dUYrZjk3ZFpHWm1VNG44empsU3JhWUFpdkpvTTZrTUVEbUMrT2U3OG12QldL?=
 =?utf-8?B?NVN4bEZXbkZUL2R5UkJtSUhvV3c2dkJNNGt4a1pLb0kyT1hYd1dTNmxCeWQ2?=
 =?utf-8?B?Ulg3THQ2cHpFL0hVZ0JzVldjeFVBVGk0V3JuTWhlaWpLT0RQWDIrVlYrOWtU?=
 =?utf-8?B?TGtIaEwrYk00elY0L0VTU1VBVkNoeGxVb0NRcE9GdjQzWUZaOFdNWm9YN2FD?=
 =?utf-8?B?UkZtQnoraW02RmV2ZUNqb3dRVDB6cFU3R0JoMEZwbFFmamR1WDMyMHhDRjFj?=
 =?utf-8?B?dnhHVjB0ZzVnTnNDZXpwbVZRaTh1eG1kci9LcEN2c1R1NXBOanlpZDV2aUdj?=
 =?utf-8?B?YVUvWGpSN0t3YVRnN1Nqc2dYUU5jaTNGdVpuSmFBWkFwamxkN1YyNjZaVFZh?=
 =?utf-8?B?aGdYcTZvOUFubEEyMUVlZDdmUTQyWEJrZnRrazRtY2JUVGpHb09tcURKMlBB?=
 =?utf-8?B?Ync3MmluQVlJK2NCRXhuOW03QUcrcG9EQnNXZmt0bTNrQUNqVWhnSThmd2tl?=
 =?utf-8?B?TEZJT2dMSUtPNnBOYm5yWlBHMzdrOVlIMHMzL2dKaVU4d3ZpWDBRb0Rla29E?=
 =?utf-8?B?SUpxR2FGMTVxSmJpK0Z0aENpenJrbXBkWW55cDdadCtzbFpjaWFxeEdIdTgy?=
 =?utf-8?B?bmQvY1FnSVJqZG5mZFFhdTdJRFJobWZxc3NOaEtXVDVkTXFHM3ZNRVlTU211?=
 =?utf-8?B?OGxWTkFFYnVoYkpVcWZFeElvdVd2OHM4Tmp3RGN0MlFQcGhnbk1OdHhGSjlW?=
 =?utf-8?B?NkhEcUx0Vi9WSmt4OE1hbDBXa2Q1ZWR6ck1sTXcxbDNvZ1NTcVUxODZNR05w?=
 =?utf-8?B?NjhFVzliWWxMcWlSNkZHQzhGTlBLV3VpaHd3UGZBeTdvVnZ4dTZ5d3dZNVBM?=
 =?utf-8?B?aU9Rbm9MUFcwYUo3Um9TditweWl6eWpXejlVa0h3SnpCS3JtcEc2NWRDS3U4?=
 =?utf-8?B?WHFJYWtuUG5CeTNpOVRyVkoyWmtRSjV3Lyt4UXJNaExYM3laOG9OOGppMDRS?=
 =?utf-8?Q?p+Bze7y3G2Xm5CmwHPcEmUdaTBdhCQ=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700013)(82310400026)(1800799024)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2025 23:42:27.4370
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 0059da27-334e-4cb2-5c36-08dd3f2c4212
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	MWH0EPF000A6733.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4376

On 2025-01-03 20:58, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin <dmukhin@ford.com>
> 
> console_input_domain() takes an RCU lock to protect domain structure.
> That implies call to rcu_unlock_domain() after use.
> 
> Introduce a pair of console_get_domain() / console_put_domain() to highlight
> the correct use of the call within the code interacting with Xen console
> driver.
> 
> Also, use new calls in the console driver in __serial_rx(). That prepares
> the code for the follow-on console driver cleanup series.
> 
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>

Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>


From xen-devel-bounces@lists.xenproject.org Mon Jan 27 23:45:20 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Jan 2025 23:45:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878232.1288401 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcYn8-0005El-Qz; Mon, 27 Jan 2025 23:45:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878232.1288401; Mon, 27 Jan 2025 23:45:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcYn8-0005Ee-OC; Mon, 27 Jan 2025 23:45:18 +0000
Received: by outflank-mailman (input) for mailman id 878232;
 Mon, 27 Jan 2025 23:45:17 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=naHB=UT=amd.com=Jason.Andryuk@srs-se1.protection.inumbo.net>)
 id 1tcYn7-0005EW-7N
 for xen-devel@lists.xenproject.org; Mon, 27 Jan 2025 23:45:17 +0000
Received: from NAM02-DM3-obe.outbound.protection.outlook.com
 (mail-dm3nam02on20613.outbound.protection.outlook.com
 [2a01:111:f403:2405::613])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c1542b0b-dd08-11ef-a0e6-8be0dac302b0;
 Tue, 28 Jan 2025 00:45:15 +0100 (CET)
Received: from SA0PR12CA0022.namprd12.prod.outlook.com (2603:10b6:806:6f::27)
 by IA1PR12MB7712.namprd12.prod.outlook.com (2603:10b6:208:420::9)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.18; Mon, 27 Jan
 2025 23:45:10 +0000
Received: from SA2PEPF000015C7.namprd03.prod.outlook.com
 (2603:10b6:806:6f:cafe::99) by SA0PR12CA0022.outlook.office365.com
 (2603:10b6:806:6f::27) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8377.23 via Frontend Transport; Mon,
 27 Jan 2025 23:45:08 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SA2PEPF000015C7.mail.protection.outlook.com (10.167.241.197) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8398.14 via Frontend Transport; Mon, 27 Jan 2025 23:45:08 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 27 Jan
 2025 17:45:07 -0600
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB06.amd.com
 (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 27 Jan
 2025 17:45:07 -0600
Received: from [172.25.15.116] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Mon, 27 Jan 2025 17:45:05 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c1542b0b-dd08-11ef-a0e6-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=dOQKKB8s1UHjWnyw5+SVVWMKpO1xSrq6jx5Zh92l6cJCDbd4yVXd5Y8JxPKECnScBOb/AM1/12c7kmTRcpPPi2eYuhBjJMNBKb5P7ZKWEMXaQ6nKaSiDkoae/xFwt+9ktDi/RdmlO1efxh73Y4MJJIgII0Azd3xAdQH5WC6n4iuhMPobiwa9wLQk7ePRHikHi8WYi1IBzHht5qwyULBVS9vJRMUOP0qZeXMgYKpFgoeD7F6aCwfINZBVEccSieKpp3b5t6e/E77cElKm1HKH7oG5CDSRBrkClgrXhQv6HFUN8Rh6ZpoiHh5i1ox4X36Xv+2M5Q+YYPFiZrgq1aNAzg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=ANoig7FuyQKJCpv8ZJW2tEa1w04hIsAQvmyOh3RHgjg=;
 b=uvzdEfcCGZVIRgduYShssbdiMCpuMYLIRB1cdn90DiZOvbKGF/V64kqaSY+gxgh+LDRKBSVVeNy/e0BNlYhXSdTLUnThl8eWlog+YhXbT6gaCL1ObifGmSazq0m6AuifE41hBkalMATFAyRGVNimjE5aILfnlSHGs587+U0Dp8zyDca35Y7VBOu4fehH4pdolvkDFFkVeO7rTFOiOezqUQG2OlNQwI988j3QpFgKMChWZyVo1smPVYBWi4Q55+7RaWX1JDIGSvrM3Tqi/oVGDro8LgE92nXDdk0y7Nqla09SwtaoCEne45Bl9bMaU/LHFxgGfUuYrU/YPhDIrvIbSg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=ford.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=ANoig7FuyQKJCpv8ZJW2tEa1w04hIsAQvmyOh3RHgjg=;
 b=eI03PkDsuYl25uQBsfEf0rN5kONYjm/zz4wl3thh6JjPQjglypzYF1DhGqATiA1Et3crUaS4xDCyNIM749p83wp6C2TlgDAbAndQaEau7Lh7Lpye4AeMVrnc3b97ODMuiawM+xnZlgHeOdorwf2vd+HscFTjFXjJ+LRILYECGog=
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: <807198f7-37c1-4642-8d92-2a4844fef147@amd.com>
Date: Mon, 27 Jan 2025 18:09:58 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 05/24] xen/console: introduce consoled_is_enabled()
To: <dmukhin@ford.com>, <xen-devel@lists.xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
	<julien@xen.org>, Michal Orzel <michal.orzel@amd.com>, Andrew Cooper
	<andrew.cooper3@citrix.com>, Anthony PERARD <anthony.perard@vates.tech>, "Jan
 Beulich" <jbeulich@suse.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
	<roger.pau@citrix.com>
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
 <20250103-vuart-ns8250-v3-v1-5-c5d36b31d66c@ford.com>
Content-Language: en-US
From: Jason Andryuk <jason.andryuk@amd.com>
In-Reply-To: <20250103-vuart-ns8250-v3-v1-5-c5d36b31d66c@ford.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SA2PEPF000015C7:EE_|IA1PR12MB7712:EE_
X-MS-Office365-Filtering-Correlation-Id: 4586e91c-88bf-45eb-1007-08dd3f2ca209
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|82310400026|376014|36860700013|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?c2ZsNFY1eFlDdGpaTmZsZXY0MytETE4xZEF2WmRuTWdjZWZZKzFUdi9nRDRL?=
 =?utf-8?B?Rm4zQ1gzOTNHZllrVTVnVHRXVVVxZDEwMjltUFZiK0ZiTlBVZk9hbXhKRkZh?=
 =?utf-8?B?dUdnbW9hR01OR0VtcEUyZGlrOWVrMjM1TktmbC9MTStDTW9nTUcwdmpGdndX?=
 =?utf-8?B?KzVKR0ZoM0crNzlXWUh0RjI0L0U2Snh2ZTB3QituTC95ZnNQVEdNZlAxUzlO?=
 =?utf-8?B?TUVYelVDWnVmS01sTHFtS1RpdkJmZFBnU01RQ1B4YnlTRmdjcEJVcDBCVWhi?=
 =?utf-8?B?ZWlYc1dITWFVdUlha3E1aGtLY2NLcDFobitrb1hZUWREdWNxcnAzeDhXbGcx?=
 =?utf-8?B?Z29LTmNaRVIvWDQ5aTlzWUNTcEdidk1jYTExNFpEc2NLYlNyZm5uZEJHS0sv?=
 =?utf-8?B?MHVLMFpXcER1eDdHRmltUnpJbFVBWmdmVlhTYm9qelZsWitpa0xyc05kN0hq?=
 =?utf-8?B?clRVaTY0QjFPdURDbmFLaGNBOEdkQ01GTmxoMis3YllDdE9FYUJIbTdOd1Y2?=
 =?utf-8?B?aldmSWFRSjFlRm84dDFvbUZWK1RpcHJGSDFvTW1YeHE4aERxNzIrUTI1OUhY?=
 =?utf-8?B?RW5FY0h4YjhMT04yQUlmanFsUXBpZ2hWVk1pRW4yODMvMkdsbHJPRHFkbDlF?=
 =?utf-8?B?UW9XcHVkeTA3MXU5OTdYOEFsdkwvK1N3bmU1ZEtDYXBCZFBibVNSQkxkTTY3?=
 =?utf-8?B?cXZSYzAvOUxXSnUzc3FoMFVpZkV0QUUzK1U4endIQ1YyVGxYaEMvd3pFY2w2?=
 =?utf-8?B?cnY0OUluVnJFQ09RV1ZNUU5EMEJiTWlQemYwOU5JTEtQM0R2QndOaXpZOHor?=
 =?utf-8?B?eWQyY3NjVmhzQ0liZ1RKVi9NdDdQVWpxaFRKOERrbDVSbUtJWjUzMkFTbHN0?=
 =?utf-8?B?TnVZUWhpSUpRMlU2QXlXczltZ0U4TldzcGVqRnNqU3dtelpvTHlKVkpqQ1NO?=
 =?utf-8?B?Tm5KOEI4S0xHMmhJNkQ5TnZyNmVjampjYWdPMDc2SzhzeVJNVEdDYWlRR282?=
 =?utf-8?B?a1FGY1NSYVNVUXJUNW51aTFXaGJGV3NEYnFMY0NLemxOai81Nm9PZjF2QTd1?=
 =?utf-8?B?aDRuQllZbzVpZm5GS0NzSmJZNUVMQjRIVnAwUjBWU0k4ZjU3OWE5NlRqSlNS?=
 =?utf-8?B?eDZJNCtxZzdsc2dVYkYrWEF0ZWMxWWdXSEs0b1dJcTFWV3hvY3NvQ3NJUHND?=
 =?utf-8?B?Z0doeFZoMkorY1JYU1Z3QmdyaGJwNmNsb21rZGQzMGtsNTlacURtaCsveUJY?=
 =?utf-8?B?SmQ3RXpHYXU2ci9oVzNSMGQ3U1RQTy9XVDBmZ2VNVGc2U2RFaEVxL2d0bVh5?=
 =?utf-8?B?bGxMa0FUOVFpU3A5akhUdzNEN2hTUklxamVVcEZvbzk2RmQ5Y2t3OGhaMlIz?=
 =?utf-8?B?QnJBNEprN1RMdkxyYXVhTmFPSHIxVTE3U1RSVGVEekdqc2cxM3dkVTZuMmpI?=
 =?utf-8?B?TkdkTTFWalpSZ0gvTlFQZXFNU21ETVRBZ29RdTRIUXMrWFlYMXdDNVBuYnF6?=
 =?utf-8?B?ckJleEVMT0MxR1VyVmxQYkQyYTU5U3Z2V2dTdDNiS0UxWHJLZnpTR0dIZlhC?=
 =?utf-8?B?MHh2NDA3VE12eW1oVVBUck92SUgvb2ZUOE5RNUgvdEpDYnZhNWtuK3pydFZN?=
 =?utf-8?B?TC9vUjR1YW1GTXdSdVFJTzdkQ05BdEg0K1JjbFpkVTJVc1RyaW4rVmxoNjFK?=
 =?utf-8?B?eFcwdlRrRVJ5MmZhZVhYUXhHYjRLMk45SnhRMXlaTlNLNjUwenVMcEtRWHpR?=
 =?utf-8?B?dHlkOUx1M1kzelBwQ3hrSEJBR3N3WFQzNENyK1UxV0dJaFM5L3BIOWlSeDZC?=
 =?utf-8?B?a1RySHpxd2p3L2QxdHpDWXVDbGJma2VaQjVrbUFVLytmakNsK0l0c3ozVG56?=
 =?utf-8?B?eXV4QURzYWhCZSt5ZDE0REFjbm1kbEpaUlNjRC9DTzBUWnpLTlEwYXBKTnpR?=
 =?utf-8?B?dFVtUDZmdnVIR25lVGpYVlNRaDI4ckNSc01acEY2cWdjQ0hDdTNmemwwZ2lK?=
 =?utf-8?B?NjUycmNtdGt3PT0=?=
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:(13230040)(1800799024)(82310400026)(376014)(36860700013)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2025 23:45:08.5154
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 4586e91c-88bf-45eb-1007-08dd3f2ca209
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:
	SA2PEPF000015C7.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB7712

On 2025-01-03 20:58, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin <dmukhin@ford.com>
> 
> There are few places which check pv_shim console under CONFIG_PV_SHIM in xen
> console driver. Instead of #ifdef-ing, use new consoled_is_enabled() to
> customize the logic.
> 
> Header file now can be included w/o CONFIG_X86.
> 
> Signature of consoled_guest_{rx,tx} has changed so the error can be logged.
> 
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>

Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>


From xen-devel-bounces@lists.xenproject.org Tue Jan 28 00:32:38 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 00:32:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878242.1288411 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcZWq-0003ah-20; Tue, 28 Jan 2025 00:32:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878242.1288411; Tue, 28 Jan 2025 00:32:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcZWp-0003aa-VA; Tue, 28 Jan 2025 00:32:31 +0000
Received: by outflank-mailman (input) for mailman id 878242;
 Tue, 28 Jan 2025 00:32:30 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=LT9m=UU=amd.com=Jason.Andryuk@srs-se1.protection.inumbo.net>)
 id 1tcZWo-0003aU-K7
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 00:32:30 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20629.outbound.protection.outlook.com
 [2a01:111:f403:2009::629])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 59b19d04-dd0f-11ef-99a4-01e77a169b0f;
 Tue, 28 Jan 2025 01:32:28 +0100 (CET)
Received: from BY5PR16CA0017.namprd16.prod.outlook.com (2603:10b6:a03:1a0::30)
 by DM4PR12MB7693.namprd12.prod.outlook.com (2603:10b6:8:103::8) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.22; Tue, 28 Jan
 2025 00:32:24 +0000
Received: from SJ5PEPF000001D0.namprd05.prod.outlook.com
 (2603:10b6:a03:1a0:cafe::a4) by BY5PR16CA0017.outlook.office365.com
 (2603:10b6:a03:1a0::30) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8377.22 via Frontend Transport; Tue,
 28 Jan 2025 00:32:23 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ5PEPF000001D0.mail.protection.outlook.com (10.167.242.52) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8398.14 via Frontend Transport; Tue, 28 Jan 2025 00:32:23 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 27 Jan
 2025 18:32:22 -0600
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB06.amd.com
 (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 27 Jan
 2025 18:32:22 -0600
Received: from [172.25.15.116] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Mon, 27 Jan 2025 18:32:21 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 59b19d04-dd0f-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Ppn/jytpHTpsSAr+utwlVpsHb9xOm2Jg3Ooz85LSLVb+6n+ZvxaYzcjaUHoqf6n40eGuCZGQ56WGojDmA/Vts2d4Ry1WfvdeCf6chw72yWCGA8WtlpPQqpe7tYLbdcaCj0eVrhekPyE5VCsKuzEdiiDBf6S4HcaffjLgZ/GFOd8RzeOfzYbut4kOmXPj0rLoaGQI6cMGON6QRol1eP6UocxNI4vPiCv7jmDauMi92DRJIIXxs4fzE5xFULBJwnQWY7yXep/OT5CK7/+O+ZL5HwROH0KaUlNR8V4qcJiLnpSToF0ZHZzwPTFD0iCrSPlpL6FD0YpePEDeAkMhAV7CAg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=51YNYtPACKD20etOArML24Odd1c+C2MmKvdCCVrsVvI=;
 b=HsJ1/3Kp1gZdl2bi6kzm3jcIYjHI1N9/uJYvtTneU4ve8s+Nke3vr8z3xKtHE0Mcz2t7TenwWKfnY2T+rMRcgoVvSUdq+VgYP8watESXpebrJxyQsLwlRBUM7TjBTAidO7VN8xz4rVNN4mN8NQuueWuWmR4EYKJ0s03j1cJ9uiSN587vAD2oNwvhJuPE27sdFA6kqqx00F2dhYwR4TQdPxnXMU79t9uHQbXxx2LkJ3vqaV/QexhfxDav0fK4hIN9/QaXQ4b1UMxuuVhtCAMj/i8VKjVQYkPZHW+ZvX3NN+5y+7J2aQFC51lKZdaQAzNgsDV9g5UtR2cDhXV1xR8m7A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=ford.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=51YNYtPACKD20etOArML24Odd1c+C2MmKvdCCVrsVvI=;
 b=i00qMbnAzvk1b59UfEq55RlNhMbrhQaTEonY2/mhH9mgpPTAF77dFLvOU+lV1ieSvGZ2361sE7spk9TOKgB5xeGxJqcajdEwE6iq53uj7JEQvkcYLWsVw2naGumJ5n9jcU/Z0rbJzNjRFmOlrrcLJnwXv4ydgSwSWfPpogaoEEw=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <3ab581fb-4c7b-43ff-8ac4-6bab65758437@amd.com>
Date: Mon, 27 Jan 2025 18:57:09 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 06/24] xen/domain: introduce hardware emulation flags
To: <dmukhin@ford.com>, <xen-devel@lists.xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
	<julien@xen.org>, Michal Orzel <michal.orzel@amd.com>, Andrew Cooper
	<andrew.cooper3@citrix.com>, Anthony PERARD <anthony.perard@vates.tech>, "Jan
 Beulich" <jbeulich@suse.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
	<roger.pau@citrix.com>
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
 <20250103-vuart-ns8250-v3-v1-6-c5d36b31d66c@ford.com>
Content-Language: en-US
From: Jason Andryuk <jason.andryuk@amd.com>
In-Reply-To: <20250103-vuart-ns8250-v3-v1-6-c5d36b31d66c@ford.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001D0:EE_|DM4PR12MB7693:EE_
X-MS-Office365-Filtering-Correlation-Id: 0d0b5f9a-6952-45c5-ae21-08dd3f333be9
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|36860700013|1800799024|376014|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?ekxNK05kUGRad2RmMTNyMHdkOUpJOExrK2RhYzBndUV5QlUwZWRDVEFiWk5M?=
 =?utf-8?B?UjJ0Y0x6akRwWUhsUUFWTSsrYVRINnJMd3hQUmNBVTNDZjVGQXRsdmNVcVF4?=
 =?utf-8?B?c21jdjlVMXFEanlHelFOUWhRaXowQ0NuWEY5ekJKRTFqanJGd2RteEUwVS82?=
 =?utf-8?B?WFVsOEpuYjd1YVdPWGN6T2lZbkJMRUdQRjMwR1hBd0Z6eExBdlAwOXNNMmZt?=
 =?utf-8?B?RGJEbmhwczdvMlpyMllXY0VCcWJLeVVtV1NFMms0K05YMzJHejQ5WWp1ck1y?=
 =?utf-8?B?bXI4SUVOYXVLK3hWZEZDYXM3T3ZqMjRXVkxWTFpnSU5zSk5EREVkSVR4aVpD?=
 =?utf-8?B?cDVEbEhpM1Y0Ym5KamJLYUJEQnVPa2FvVGNwOG9XTldLTFFMMytKejhvTzJo?=
 =?utf-8?B?cHpuNWZ5NzRNZEE1aWh2YjRhVmMxY1dOcE1BSjB5aUlIbTVNUE5nREJNUnlJ?=
 =?utf-8?B?VWh5T0tOS24yTTRhcFhKeTJpb3JhYUFocXRYY0VzdWFjOGRDY0hwSlZFMFRQ?=
 =?utf-8?B?NzByMklCbWFLSFhXajFibm94bDNvaUpsd1lkZjVCNG1pOUZWbFplV3Uwbmgx?=
 =?utf-8?B?VFlMT0Y2UzQwNkpEeFd4RlJFa1BoOEVOa1Rqcm00U2Z6VDY5LysyM2NvcURk?=
 =?utf-8?B?T1JGcGRuenVGZUpkc3dMaXQyNmNROHRXeW5MMkozeFl3YVBJYytRM25BM0dx?=
 =?utf-8?B?MXY1dTYyNkRMUVlOWmJoRmFmQXFJMDRpVEk0cWVZZTBGdTlxM1hvazhTckhO?=
 =?utf-8?B?STFGVDAyOVNZa1Nnbm9MNWVKMTdpYWhoMGZRT3dvWVNCT3M2VnE0YVBxQXZN?=
 =?utf-8?B?OXhDUGVEQW9rVnJIOUJvSVlDMTdEM1hnMHBGN2pBVWgrMkZZUFdkTjRhd0k0?=
 =?utf-8?B?bG9ESWdITXo4MS8vTWJrWDhORHd1RnEyRTF5VFJldTc1WGdSanZnRmp1Y3Rv?=
 =?utf-8?B?aXgrWFBkZk0xNFliSFZxQk9ZWkFJWTQ2REJnR2JyNEx1WCtEMlZVRTR5WGRQ?=
 =?utf-8?B?OWNDK2JMbDcra3pvNDk5dnVVS05tT0Q5WWlUYXNWVEJySmhnU25FV0lkWUR4?=
 =?utf-8?B?dVByZmx6TjFBNCtoUS9Wc1dHeW5rRDY3YlVteVFkZG15eVJzWW05QzNaZmtP?=
 =?utf-8?B?N2xLNW1YeXBHSHd3TEZ5bG4wODM2b3BvNzhWR2RQZTgxYTg3aWZMdDRYZVRh?=
 =?utf-8?B?a09ZSks0TXZuWFZxbWtldUxtSWpMKzREQVIzWVh6RXptdFJrMkdjOXBybzhP?=
 =?utf-8?B?azFXUC9weVpRdGYwZThEa2VkWUN4TVlEdE56NU5DMHhWdG5UcmtnbDBYUWNy?=
 =?utf-8?B?UTZpeGRRbUlHUVlDWlF3Ympidk9TVm9wUFFmd1NYTkkyV01temM5cmx3ZW9x?=
 =?utf-8?B?SCtqTkIvM1ZiUFFjazMrclovRmxqT1Q4eDVpbHpMV0hCWEZmN1UyTkxuTSs5?=
 =?utf-8?B?WUQyUU5EdElPTkk0TDZqdmlES3B0MzJaZU9BQmxhMzNXUTB3RUxwWWNjNUVa?=
 =?utf-8?B?V1VKWVI5VzN2a0pjdUdDNStYTDNtb2Y2MWl1djRGdzdmM1FJbFEyMDFvWEFY?=
 =?utf-8?B?RHlkdkYrbDF3Um1jeHRIVHJSU3dUOE9iU09UbGpiYkMvSFA1N0FXMUpVNWNU?=
 =?utf-8?B?MlQ0NzlqcDdlNm8yaklnRUlxTnR3MUpuUVRTOVU5REN5RTVKVzE1UFRqb3Ar?=
 =?utf-8?B?ano5WkthczMxck03c05xa29NRFBIejM3aUprUm1HVWloQzJuODdGNHdYV29N?=
 =?utf-8?B?NnM3ZHQvUDNVbmd5UGxoZnA0TWZLODF1b0pGckh6MTJrQ3NQUmF5WXlIVFcx?=
 =?utf-8?B?d0l3ZU4zOGNZMWdFNThhRTRhMTlNZDBrdWNpQlFKMmRRTVExZUwxbHZjaFdo?=
 =?utf-8?B?LzduUG1XeTVzNWdsZTBiQjVrT21yaTM5aGxvWUhiRXVIODNZTW12MFVucUtH?=
 =?utf-8?B?Z2Z2UUU2SzczSVhwaHY2WFMvUTdsU0oveHBqT3kwZWdrTUVQV2FQZGhubU9C?=
 =?utf-8?Q?kLBChtUa4BH99XI75FTAhLUVTNIM2Q=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(1800799024)(376014)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2025 00:32:23.5968
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 0d0b5f9a-6952-45c5-ae21-08dd3f333be9
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF000001D0.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB7693

On 2025-01-03 20:58, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin <dmukhin@ford.com>
> 
> Define an architecture-independent location for describing hardware emulation
> flags for configuring in-hypervisor emulators.

I'm not sure about this.  It's a lot of churn.  The common internal 
handling makes sense, but specifying in a domain architecture-specific 
fashion seems okay.  Letting ARM specify EMU_VPL011 and x86 EMU_UART 
better aligns with the rest of the architecture-specific emulation flags.

> Print d->arch.emulation_flags from 'q' keyhandler for better traceability while
> debugging in-hypervisor hardware emulators.
> 
> Also, expanded the error message in arch_domain_create() in x86 case when
> user-defined domain emulation_flags are incompatible w/ platform supported
> emulation_flags.

These two seem okay, but could be in their own patch.

> Signed-off-by: Denis Mukhin <dmukhin@ford.com>

> diff --git a/xen/include/public/virtdev.h b/xen/include/public/virtdev.h
> new file mode 100644
> index 0000000000000000000000000000000000000000..27434377ecacfe069a91dea3768d14b0c14e08b4
> --- /dev/null
> +++ b/xen/include/public/virtdev.h
> @@ -0,0 +1,61 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef XEN__PUBLIC_VIRTDEV_H
> +#define XEN__PUBLIC_VIRTDEV_H
> +
> +/*
> + * Domain hardware emulation flags.
> + */
> +enum {
> +    VIRTDEV_LAPIC      = 1U << 0,
> +    VIRTDEV_HPET       = 1U << 1,
> +    VIRTDEV_PM         = 1U << 2,
> +    VIRTDEV_RTC        = 1U << 3,
> +    VIRTDEV_IOAPIC     = 1U << 4,
> +    VIRTDEV_PIC        = 1U << 5,
> +    VIRTDEV_VGA        = 1U << 6,
> +    VIRTDEV_IOMMU      = 1U << 7,
> +    VIRTDEV_PIT        = 1U << 8,
> +    VIRTDEV_PIRQ       = 1U << 9,
> +    VIRTDEV_PCI        = 1U << 10,
> +};

If you do create this new header, I think you'll want to leave these as 
just bit numbers and shifts.  IIRC, the headers strive for greatest 
compatibility and, enums are less rigorously defined.

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Tue Jan 28 01:01:30 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 01:01:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878255.1288421 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcZyg-0003TC-6P; Tue, 28 Jan 2025 01:01:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878255.1288421; Tue, 28 Jan 2025 01:01:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcZyg-0003SZ-2K; Tue, 28 Jan 2025 01:01:18 +0000
Received: by outflank-mailman (input) for mailman id 878255;
 Tue, 28 Jan 2025 01:01:17 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=LT9m=UU=amd.com=Jason.Andryuk@srs-se1.protection.inumbo.net>)
 id 1tcZyf-0002vW-9M
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 01:01:17 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20609.outbound.protection.outlook.com
 [2a01:111:f403:2414::609])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5f8f2f52-dd13-11ef-a0e6-8be0dac302b0;
 Tue, 28 Jan 2025 02:01:15 +0100 (CET)
Received: from DS7PR03CA0224.namprd03.prod.outlook.com (2603:10b6:5:3ba::19)
 by DS7PR12MB8292.namprd12.prod.outlook.com (2603:10b6:8:e2::21) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.22; Tue, 28 Jan
 2025 01:01:08 +0000
Received: from DS1PEPF0001709D.namprd05.prod.outlook.com
 (2603:10b6:5:3ba:cafe::10) by DS7PR03CA0224.outlook.office365.com
 (2603:10b6:5:3ba::19) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8377.23 via Frontend Transport; Tue,
 28 Jan 2025 01:01:08 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 DS1PEPF0001709D.mail.protection.outlook.com (10.167.18.107) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8398.14 via Frontend Transport; Tue, 28 Jan 2025 01:01:08 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 27 Jan
 2025 19:01:07 -0600
Received: from [172.25.15.116] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Mon, 27 Jan 2025 19:01:06 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5f8f2f52-dd13-11ef-a0e6-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=KmbF3FlH7x9HNWP3YYHbwDpsSBiNqAhuou51GAztEEePO5GWBztp7Ql+G8tbVvgEg4zL7djFE7/Dd5c71WrzMa+cpS2jWfehYn88ukl2z6obcg6Hmd737zFxegHtY0y2EX7o7W7eS02qihPtD0kRzABFYz7+T6IFhU0rv998Lpn90iFuocJYwhC37geAl1C3ZYIxOQMbQrw79v9I6qu9x8obN7EH20IA2yqOBVTyHFH161GlPQz+WLpU8VQFRke5CH8cnNqpIFFeVIMl7+RRoyobutRk54iz7xy+rEu+u3PoRBWbsa2goHf4fux/DDkXjS8lUMsxGj4rRvcQTC4RlQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=UwRU4nxk5uvPUHcrM/kNF4IzdzGLXo7Ym7SK0HWhYmM=;
 b=yAOsnDqH14NkzcHO4w4994E8kLdIsjyMaMU5X876aD2W/dNkZ6PQ1Cync6hRwGV/SIw6gPcTbpPOSP81gQGRUEAv8ISyCWD0JsUBCwKhzJ3aGtQQ/K0PFKG+olYGe3cfAJepeNs2zCMzHB7LlkqdduAxwuRmonojx6Cf5Gbmnsy7P2h7J6vAwLVEN+AOskt1uY9+mBatHKjaR6UlRCLuNKa5LPHGTlCBAsvgyteO7yyOMhqOKKR89PTENuvsg98KlQOPYZsrRLDzzWmD2Att+wlS8gCdcco09dBs4AfGL6NlqF3spEPO9gOADL25b10f31qo6Yn9J97xre7+6efZsg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=ford.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=UwRU4nxk5uvPUHcrM/kNF4IzdzGLXo7Ym7SK0HWhYmM=;
 b=lOpBJXV2O7VqpRQBnmd5o0fvwNg3qc6/vCJhMmFhdP2CUvlZqBCYD/iav00xrjjGA9vIMU3VBbBj9XxbrSBlEB8qO9t7r3fTNX0UbxvS+/OkzDjoMfW70IBjpD5LQetPYZSSWgKSJIorcgc+HsS/6tx3dOWATkSjjGnwVRFO0rg=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <a49b67b2-87ff-49c6-a319-bb9b33ae8f04@amd.com>
Date: Mon, 27 Jan 2025 19:25:59 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 07/24] xen/console: introduce framework for UART
 emulators
To: <dmukhin@ford.com>, <xen-devel@lists.xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
	<julien@xen.org>, Michal Orzel <michal.orzel@amd.com>, Andrew Cooper
	<andrew.cooper3@citrix.com>, Anthony PERARD <anthony.perard@vates.tech>, "Jan
 Beulich" <jbeulich@suse.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
	<roger.pau@citrix.com>
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
 <20250103-vuart-ns8250-v3-v1-7-c5d36b31d66c@ford.com>
Content-Language: en-US
From: Jason Andryuk <jason.andryuk@amd.com>
In-Reply-To: <20250103-vuart-ns8250-v3-v1-7-c5d36b31d66c@ford.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB04.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS1PEPF0001709D:EE_|DS7PR12MB8292:EE_
X-MS-Office365-Filtering-Correlation-Id: d0718031-caf3-42f6-febb-08dd3f373ff2
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|36860700013|376014|82310400026|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?ekJPcVlheUlGYTVWU1B4ZDhjQ3hPUTlTWTEyTldEbEpFbit0Sy9Lck1SNDly?=
 =?utf-8?B?b2RoalRydzZzemtRNmxjUlRhZDJpVjdZOGQ1OGduZUhCT0ZyZ25mS0ZGRllT?=
 =?utf-8?B?ZzdMaDl0dmRRb2FOcysxaGhHc1NaaE5TR1ZaRHlpTVVURDluSFdVODFLdGMx?=
 =?utf-8?B?ZVI2T1F4S0UzVTZFa0FSYXMvNVNaSTFxTkdkcWoxdEUvMHZrbUVaaXVHczRR?=
 =?utf-8?B?Vmo4aXMrV3l6WjkxZHBsNEhuSG96eGhZSzYveVMyRXlXeCtMc2tqakRlaDJN?=
 =?utf-8?B?NFZpVVkranpCbkxncXBWaDAwQm9hdmdUbVMzTFlUYkI0R1dwNVNDTjZuVllr?=
 =?utf-8?B?dnhtbUJUM3hqYmlXQWp0MmhBcUxaNnNXZ0tWZENXeWdnRnVoN2JUMGQ3NHZK?=
 =?utf-8?B?Wk55SDFGRXMvMURXOENsbnNleWxva2syWm1VQkN0UjV2ejYrZExkQzB2eG1H?=
 =?utf-8?B?cWIyWWtXUnJ3ZmxJZVVhUVlHUFZjTlBlSUhpUlIyeGZ2dEtGd0dCOVhleU12?=
 =?utf-8?B?UUsya0pjdUZBTFF2WGJEWlNpOEFLOEVRZTM2YWxJR1pGK3JTODVDVHZNT2JV?=
 =?utf-8?B?dkxhQ0xVZGJOSFNRckFEdUQwRFFJdmpUV2hFTmV4SHhJTDVrVjdJM045bGEr?=
 =?utf-8?B?cWRhUzZ6Q3VMeFJ1OTJjSUV6M0pkWDlBL2tCTDUyYnJXSmU1cDZlZE1pZEVo?=
 =?utf-8?B?VWUycnU5NWJ5Yno4YUQ1S3JwSmRNMGdZeWRuT2NGQWVlVGxRRit6SHcrckdj?=
 =?utf-8?B?V1VOa05IbFJ1cmF0NHB4eEpoN3VEcS94T0dLaXRUS3dSWVJNZ2c3UWNRWGIz?=
 =?utf-8?B?MTg3YzNwaGhPc3prTFM3OUN4aXVNSlZqLzlGZmdxUDFEbzE0cnRUQmg0cmI1?=
 =?utf-8?B?dHUvL2tUTHVQa3YxYVhicVFaV3liaXNkWU10WEl0by9ZY0FPRnJnVHEralZC?=
 =?utf-8?B?Z01VWTBzazVucmZRcTNGU1BuaHhzOG0yOXlsMHpPQ25GRHpraEhoWnd4aGM1?=
 =?utf-8?B?L0Nuc2JFVTRMY3ppWjhGOXRLUzNseUpqQVFBUEo4Wnp4MXV2SWdRa2puZFdz?=
 =?utf-8?B?MWdGa0k4WFp5MnFEQTZQdGRLd1ppTjRRbmxHNnQ0eGtrUWJZdCthZXEzRWZX?=
 =?utf-8?B?azZvQjhqTUdlSzc4VUR2SForcnVBQU5TdUlZY0wzSzR1OXhEL1lpK1l0cHpy?=
 =?utf-8?B?d0MrUnY3M3pvay9FYUNUbkNlVlkwNjBzbzZCaDNiQjFlNGFjYlVETVJ3RjM5?=
 =?utf-8?B?K1paeFM0cTNNRXkxdS9CVmgyaWVoTlNsWWhrWGp6QlRZeDhWTmd1YmlJTEJW?=
 =?utf-8?B?OXltdUdSYXdkNVZ0Q2RIdkJsU3puVkFvQ0x1bGlXejRwWWkvNThoclZqc1Jv?=
 =?utf-8?B?UUp1V3RRbGZoTlEwVmJNTmF5eGYyd2JKZ1AydFljbUNVOFNjVEFGcFNqUEtm?=
 =?utf-8?B?WEcvQUMrSGFBU0c4OXlyZk8rOUpQaEYvZUZ4S0RzYVN6VjI5U3F1eG15WFo4?=
 =?utf-8?B?MzFvbm5sY04vM1AyZ0hremg3SjloZlE4M1JGc3k2emYvTFZtM1dYVG9KTEdZ?=
 =?utf-8?B?czh3NVo3ZzJ2ZjRoQVZIQzNHRXRGaElMZVA3bDVZcW5zTVJwTnptdEpVZHE1?=
 =?utf-8?B?blVWT2M1QlR6b1dIYmFRUHJZYjM1c0Raem5NbG5uRVZrM2lyNUFwTDFqNzln?=
 =?utf-8?B?TmcvUVBlYkU3L0pqY21FNHp5UnZuZXlqMDRGRlNlbmxvdGQwc1dER0Q0U0sw?=
 =?utf-8?B?YzJjOEJhR0Z5d3VLaGNhSEhRRGlEK01tVHg0dDRQK2VmTUUzZEZFMjljMnk5?=
 =?utf-8?B?bEdGMHQxMUQzQnB6QlJnZzZoZWtkVytaZENyUFAwZklFS29TOHAwUUxhbmlk?=
 =?utf-8?B?N3FVWUxhR2NWOTZGOWlIV0ZqcGxtR1I4ZUxvL0lDOE5hbGF0QWNjZURBMHZP?=
 =?utf-8?B?VEw4Y1dxcmxUWE5pZGk1SVp2aENnWW52Zkc4OUNIS0h4d21CcFV2bnlUNjNi?=
 =?utf-8?Q?rtFr+wI2SI+8yHJG2YgLKVKugH4ynE=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(376014)(82310400026)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2025 01:01:08.4024
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d0718031-caf3-42f6-febb-08dd3f373ff2
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DS1PEPF0001709D.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB8292

On 2025-01-03 20:58, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin <dmukhin@ford.com>
> 
> Introduce a driver framework to abstract UART emulators in the hypervisor.
> 
> That allows for architecture-independent handling of virtual UARTs from Xen
> console driver and simplifies enabling new architecture-dependent UART
> emulators.
> 
> The framework is built under CONFIG_HAS_VUART, which is automatically enabled
> once the user selects a specific UART emulator.
> 
> All domains w/ enabled vUART will have VIRTDEV_UART bit set in
> d->arch.emulation_flags.
> 
> Current implementation supports maximum of one vUART per domain, excluding
> emulators for hardware domains.
> 
> Use domain_has_vuart() in Xen console driver code to check whether the
> domain can own the physical console focus.
> 
> Note, arm/vuart.c emulator is not hooked to virtdev-uart framework because the
> emulator is limited to the hardware domains only and was not designed to own
> the physical console input. Updated arm/vuart.c APIs to have 'hwdom_' prefix
> instead of generic 'domain_' to avoid possible confusion.

It might be good to renmae xen/arch/arm/vuart.c to 
xen/arch/arm/hwdom-vuart.c and then use just the shorter vuart prefix 
instead virtdev_uart.

> Signed-off-by: Denis Mukhin <dmukhin@ford.com>


> diff --git a/xen/drivers/Kconfig b/xen/drivers/Kconfig
> index 20050e9bb8b32bd16c2da76c2c3e0f68dab89394..355719c3af67683c153a4f7a35dad4944992846e 100644
> --- a/xen/drivers/Kconfig
> +++ b/xen/drivers/Kconfig
> @@ -19,4 +19,9 @@ config HAS_VPCI_GUEST_SUPPORT
>   	bool
>   	select HAS_VPCI
>   
> +config HAS_VUART
> +	bool "UART emulation framework"
> +	help
> +	  This selects UART emulation framework.

This can be hidden, so just:

config HAS_VUART
	bool

> +
>   endmenu

> +int virtdev_uart_init(struct domain *d, struct virtdev_uart_params *params)
> +{
> +    int rc;
> +
> +    ASSERT(__start_virtdev_uart);
> +
> +    rc = __start_virtdev_uart->init(d, params);
> +    if ( rc )
> +        return rc;
> +
> +#if !defined(__i386__) && !defined(__x86_64__)
> +    d->arch.emulation_flags |= VIRTDEV_UART;
> +#endif
> +
> +    return 0;
> +}
> +
> +void virtdev_uart_exit(struct domain *d)
> +{
> +    ASSERT(__start_virtdev_uart);
> +
> +    __start_virtdev_uart->exit(d);
> +
> +#if !defined(__i386__) && !defined(__x86_64__)
> +    d->arch.emulation_flags &= ~VIRTDEV_UART;
> +#endif

I think this is only called at domain teardown, so you don't need to 
clear flags.

> +}
> +
> +int virtdev_uart_putchar(struct domain *d, char c)
> +{
> +    ASSERT(__start_virtdev_uart);
> +    ASSERT(d->arch.emulation_flags & VIRTDEV_UART);
> +
> +    return __start_virtdev_uart->putchar(d, c);
> +}
> +
> +void virtdev_uart_dump(struct domain *d)
> +{
> +    ASSERT(__start_virtdev_uart);
> +
> +    __start_virtdev_uart->dump(d);
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */

> diff --git a/xen/include/xen/virtdev-uart.h b/xen/include/xen/virtdev-uart.h
> new file mode 100644
> index 0000000000000000000000000000000000000000..fbe48e513996404d793d011747b3f40c236a6a57
> --- /dev/null
> +++ b/xen/include/xen/virtdev-uart.h
> @@ -0,0 +1,72 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef XEN__VIRTDEV_UART_H
> +#define XEN__VIRTDEV_UART_H
> +
> +#include <public/xen.h>
> +#include <public/event_channel.h>
> +#include <xen/types.h>
> +
> +struct virtdev_uart_params {
> +    domid_t console_domid;
> +    gfn_t gfn;
> +    evtchn_port_t evtchn;
> +};
> +
> +struct virtdev_uart {
> +    int (*putchar)(struct domain *d, char c);
> +    int (*init)(struct domain *d, struct virtdev_uart_params *params);
> +    void (*exit)(struct domain *d);
> +    void (*dump)(struct domain *d);
> +};
> +
> +#define VIRTDEV_UART_REGISTER(x) \
> +    static const struct virtdev_uart *x##_entry \
> +           __used_section(".data.virtdev.uart") = \
> +    &(const struct virtdev_uart){ \
> +        .init    = x ## _init, \
> +        .exit    = x ## _exit, \
> +        .dump    = x ## _dump, \
> +        .putchar = x ## _putchar, \
> +    }

Are multiple types of uarts for a given architecture expected?  If only 
a single implemention is needed per-architecture, using defines or 
wrappers seems simpler to me.

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Tue Jan 28 01:01:30 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 01:01:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878256.1288431 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcZyl-0005Yt-DB; Tue, 28 Jan 2025 01:01:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878256.1288431; Tue, 28 Jan 2025 01:01:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcZyl-0005YC-A2; Tue, 28 Jan 2025 01:01:23 +0000
Received: by outflank-mailman (input) for mailman id 878256;
 Tue, 28 Jan 2025 01:01:21 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=LT9m=UU=amd.com=Jason.Andryuk@srs-se1.protection.inumbo.net>)
 id 1tcZyj-0004sS-NF
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 01:01:21 +0000
Received: from NAM02-BN1-obe.outbound.protection.outlook.com
 (mail-bn1nam02on20620.outbound.protection.outlook.com
 [2a01:111:f403:2407::620])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 626d0743-dd13-11ef-99a4-01e77a169b0f;
 Tue, 28 Jan 2025 02:01:19 +0100 (CET)
Received: from BN9PR03CA0380.namprd03.prod.outlook.com (2603:10b6:408:f7::25)
 by CH3PR12MB8712.namprd12.prod.outlook.com (2603:10b6:610:171::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.18; Tue, 28 Jan
 2025 01:01:14 +0000
Received: from BN1PEPF00006001.namprd05.prod.outlook.com
 (2603:10b6:408:f7:cafe::4d) by BN9PR03CA0380.outlook.office365.com
 (2603:10b6:408:f7::25) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8356.22 via Frontend Transport; Tue,
 28 Jan 2025 01:01:14 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BN1PEPF00006001.mail.protection.outlook.com (10.167.243.233) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8398.14 via Frontend Transport; Tue, 28 Jan 2025 01:01:14 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 27 Jan
 2025 19:01:13 -0600
Received: from [172.25.15.116] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Mon, 27 Jan 2025 19:01:12 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 626d0743-dd13-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=fXsTFzVuYm7xPvxeyrsmGb9MeOskgFfWIQ6FTrEc61RmhgATJVsO5OOVOzXl8IWXavrZbXW0DnIyIUUs8qx3Rqn892I+wZYY84gAjIuH90wBrfUJdH7U1inBWxDIwMOEe/z39dbSZFMMpNeciknabPBgvAPxDdTSGflHrCYEhf3mfUqthaVUwHcLWnkQa7FdzZ4t2R+cpdKNQAZJmu1iUi+lDk4PdMe82reuZzHwW52aQfnCwvyUGOZoha9/O84v6gGrnuPx7Cc8Hg7zrERlliCAFTuRAYDoXvvT5sKZiP9gFlnObobmK0T6KG9h0vLsRu43rDYuDxuoQn0555wfeQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=RU5juYAN8MkcFeZ78u4MDJiUtRyZMgU3YrD1KmNTcy0=;
 b=G+k7Nst0BI6lz72QEchaKgWx4EEs8lSkuvjg4bIhU2SXDe1/voWUF8Bp5CNX8W4BWCn8X9wxnB5iZTUQhgedSK3KaQHatjt0IdFB50OpFMOexzof8vOL7Uyjjnmj7ZpQ9Kmk2XV9SzLY8k2YgX1KZ6mjS2gtf+7zibEYn0xnkGPXSMUm9zQvCK0KvQWUAwwMFNgHhllnuJp6/DORzErQjmQ9OCUsvGXG3fYnlDRwP26XmF5H9Rz9jtpJvQG17Hsx9tJQ3Z2RZ7C1P9hMgWiAQ/l2/YYdcv+4wjuaBX209/DuPNSCAuC36y/n6CAq7v2jaNcpxTPWisHug2IpKiAQ/A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=ford.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=RU5juYAN8MkcFeZ78u4MDJiUtRyZMgU3YrD1KmNTcy0=;
 b=JGqfn+BQpE+8zKd7Plcxikm2kvRSwbLYV8z6oqV4gBHs8qH5qm0pg3lg7J4bddGh6LmB3IuF7LubRLGH5HOpDZxG8dWehz1vAUTsC4ES/v6XQ7oMVxqshHpB9FjVaVY7YcFmLNc0pHP3e5bZo+mPZudKXM2AhtnmkxE2sBl92Ko=
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: <047913a7-134c-4d6a-9db7-69dd3442d7c9@amd.com>
Date: Mon, 27 Jan 2025 19:26:06 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 08/24] xen/console: rename switch_serial_input() to
 console_switch_input()
To: <dmukhin@ford.com>, <xen-devel@lists.xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
	<julien@xen.org>, Michal Orzel <michal.orzel@amd.com>, Andrew Cooper
	<andrew.cooper3@citrix.com>, Anthony PERARD <anthony.perard@vates.tech>, "Jan
 Beulich" <jbeulich@suse.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
	<roger.pau@citrix.com>
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
 <20250103-vuart-ns8250-v3-v1-8-c5d36b31d66c@ford.com>
Content-Language: en-US
From: Jason Andryuk <jason.andryuk@amd.com>
In-Reply-To: <20250103-vuart-ns8250-v3-v1-8-c5d36b31d66c@ford.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB03.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN1PEPF00006001:EE_|CH3PR12MB8712:EE_
X-MS-Office365-Filtering-Correlation-Id: 895e2bf1-411c-4f5c-569e-08dd3f374345
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|36860700013|376014|82310400026|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?bVF2NTIxa2NXL203N2YwQ1RkUGR2VW1VZmxvQVVZMWRITjVvczNTdW1ZY3Nl?=
 =?utf-8?B?anFtWVJSa1h5MHYzanh1QXF4ODRyVmh2aFRQRVpsUmJkR0dDZStZbTRzRzhU?=
 =?utf-8?B?WlVEU1FtNlNLa1pLR3lUUU1WSldLTTVESVMyNDVpaUp0cTNuSVFJeGZoTUht?=
 =?utf-8?B?c3pTMnN6UnJHWWlZQkNyc1dMakdvRlQraE9UZ0dVNjZZNWJkWEZMNW9GUUdy?=
 =?utf-8?B?ZFJveTRPUnpOU0ovUWZEbG03TnptNW1makhHaGRvYW5mQzYwS054RkVIV2tC?=
 =?utf-8?B?NFJsdG5kNlV3ZnlCUS8rYXcwMXBxaktseFY0UW5BcFM1WWFqODVHUDJBR0Ji?=
 =?utf-8?B?M2lQd25QbFNSY0hNTmNaUlNUZTBXeWRWTmxFaWFWbEgrSFk4QlhYZ3NFSmpB?=
 =?utf-8?B?TzFJTmRnMUJ1enFjNml2dFhNTzBaWnlrN2FvWml4R2x2b215S3g0U2U3Rzc1?=
 =?utf-8?B?Z1FJYk5YKzBCMDhVNzgxSXVESWJrOFc0Y1BPSXhFSFB2WjVmZE9zaFZtcEgx?=
 =?utf-8?B?TGEyOGlrcExhVWRTMkpSL0toU3F4MG96SExaREZFK0d3NXVVdlVjQmxQdXdU?=
 =?utf-8?B?VGVqR3p0bHBNMkoxMUV2MlRRU2xZdEJrWTZKT29nR2xsUUt5c3JyU1R2MFND?=
 =?utf-8?B?bFZkdmpkQnJvTm0rVzZxVnAxL2djZ3I4dU1XQlgxYUxwbTRXK1BHaHFURWF2?=
 =?utf-8?B?Z1pwZ08vTnJ4VS9JT3NzMENsSmJ6R212WllDcGtJcXVwczAvYWRZdDhvc0NG?=
 =?utf-8?B?QXRTa1VFblRVV01Ca1k4bEd3Mnl1YXZ1WXFSOWFDcG5ja1R5Q3NNSmt0NmtW?=
 =?utf-8?B?aVpPUXNISVhJVjVTYSsxU2hRRER5eGRoQ3JhdEtSQS9ibG1tSS9KckEvSHhr?=
 =?utf-8?B?RVZIODhaNmZPSEFBUlZmK1VOM3dCVG96am1pTFVLZnkwMjJaOHBnUXZ4ZnRy?=
 =?utf-8?B?WTlaVjFpbmJFTHF5NmtUcThJUDEzVEM2Y1N4eEZiNTFMUy9pWnQzajFidjNa?=
 =?utf-8?B?U0RmeTZnUGJIejMvRi9uSTZjSDJLd3lzZk0zQlZKQ3F1QTM1NzROTFJtV1U5?=
 =?utf-8?B?S3R3dHl2TDRjUVVOamdmWFQyM0lIZWQwV2Z5RzRPWkp5NlI3U2lSK1Vab2xC?=
 =?utf-8?B?Q0FvT2w2MzRZNDVtYzd5R3dyTHpvUDZFNHpjVGt1aHU1cE5lYUVkcGVEUlF3?=
 =?utf-8?B?YVpFR3hLZGdSY3FLL0dVdWdySDJSY0tUNTNDUjZrVjc0ZXFLeVJZL05FYTJx?=
 =?utf-8?B?VWNFeUxqdE5TekxmK0IyMU13SlZ3SytlMHlQVENlSFJCRDQyVUE0dlAwU2dn?=
 =?utf-8?B?Z3FuRStyWkJtWEs5clhuMENXb3BhM2k2MTcrYmt6azZTTjh2RVEyMlYrNVpR?=
 =?utf-8?B?R2pocml3MDgrd2pqNDcvQUVtK0wwaTI5S3RXQUtCbktHTGVncWF4bndteVdV?=
 =?utf-8?B?ZExTcEZCM1NLRmNnZ2Vlc1Y4OWRoK09vazlaSURiaGJXczBFSDdtWVdnQ2NS?=
 =?utf-8?B?OE5HeHdVaUFvNXhrcnFkSWRETHlqUkNFcXlvLytYemd2TUlXQXVDTmowTFhx?=
 =?utf-8?B?cU9jV25yNHNRY0wxdzRDOVd3Y2tJOWVtMTR2cnYzR0ZDdGlzdHJGVWhoa2N0?=
 =?utf-8?B?WVQrdHB5bUdFUGRLYTFITWZ4c2l2aDd0WnR3eFprVC9JdVNxTk1pdW5Gb2NW?=
 =?utf-8?B?bEg5RkdBUzJZUklTQ095RHJJMHBzT3E1R1MyUHF4TWJuZGZ0eTJpRU50a2lI?=
 =?utf-8?B?aEplVVVQUmxuTlgzNTFIYmZsclJIbmhMazBNRFM4enEveUk5N1FFRVVSbm92?=
 =?utf-8?B?Mk5leXFUWWlEQlZDSEdObzl6YXoxVXhVWXJWbG1Da2JUV05ZOEJRNW5wQWov?=
 =?utf-8?B?UWZuZjhTVlR4RjFmUlY4cTZnZ09CZTFlRDZMMFlNYlZ0aGZVOUxDbktWVUdr?=
 =?utf-8?B?Rml1N2o4NE9ZVEZzeFRmaWo4K2tMVXU3Qkg1WS9wRk5pUnUvRFovc3BEZGxo?=
 =?utf-8?Q?sOjrbc8tHdVOUWuoc1NpvVv2nDtfYc=3D?=
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:(13230040)(1800799024)(36860700013)(376014)(82310400026)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2025 01:01:14.0066
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 895e2bf1-411c-4f5c-569e-08dd3f374345
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:
	BN1PEPF00006001.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB8712

On 2025-01-03 20:58, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin <dmukhin@ford.com>
> 
> Updated the name to highlight the physical console input selection logic:
> existing code does not switch only serial console, it also switches debugging
> console (debug I/O port and console hypercall).
> 
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>

Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>


From xen-devel-bounces@lists.xenproject.org Tue Jan 28 01:21:19 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 01:21:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878274.1288440 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcaHx-0001oo-1q; Tue, 28 Jan 2025 01:21:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878274.1288440; Tue, 28 Jan 2025 01:21:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcaHw-0001oh-Vc; Tue, 28 Jan 2025 01:21:12 +0000
Received: by outflank-mailman (input) for mailman id 878274;
 Tue, 28 Jan 2025 01:21:11 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=hG5x=UU=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tcaHv-0001ob-H0
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 01:21:11 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2511a3b1-dd16-11ef-99a4-01e77a169b0f;
 Tue, 28 Jan 2025 02:21:06 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 5A5285C5861;
 Tue, 28 Jan 2025 01:20:24 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id E4548C4CED2;
 Tue, 28 Jan 2025 01:21:02 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2511a3b1-dd16-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1738027264;
	bh=sTxYZq/jdJVkxS5kHUyvBdCxB0yAB1dWDP2A/jGH8VE=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=dvkDchOhbr+XNnS3JoPq6IoJZkjXBfqLI2PnkVQ75sjE9JGxOzeDFmyj8YcdYeyOn
	 sz7fSATmXN/VDM9kKpM6BZdTsYKyqLLQtuSjRk58moOakMT8rgJsEgnfIzr8LF4I1b
	 8MFuDzgemwQd0QUzNiNdgSQ5zhTLrLr/aowyfDoGBuJxQWZilfiQOjG0AcANQkIcP3
	 2ZF6dGT71IY64bOS74buSmsl6/lJzOaS8nMuvd+r4avfE+N5lToBO1ewssjo9R4oUK
	 rxOiSPEq25fqf3WnHsS0N9r4n/L/343ixNSqCDFSld69Zf2cwkof5PmwjzyOsnpA59
	 s4lrbcXvMoLYg==
Date: Mon, 27 Jan 2025 17:21:01 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Luca Fancellu <Luca.Fancellu@arm.com>
cc: Michal Orzel <michal.orzel@amd.com>, 
    "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, 
    Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, 
    Bertrand Marquis <Bertrand.Marquis@arm.com>, 
    Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>, 
    "oleksii.kurochko@gmail.com" <oleksii.kurochko@gmail.com>
Subject: Re: [for-4.20][PATCH 2/2] xen/arm: Fix build issue when
 CONFIG_PHYS_ADDR_T_32=y
In-Reply-To: <E2EF4E08-8D6D-4F43-99D1-BDAE3FB76CF4@arm.com>
Message-ID: <alpine.DEB.2.22.394.2501271720282.11086@ubuntu-linux-20-04-desktop>
References: <20250127104556.175641-1-michal.orzel@amd.com> <20250127104556.175641-3-michal.orzel@amd.com> <E2EF4E08-8D6D-4F43-99D1-BDAE3FB76CF4@arm.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-362762593-1738025722=:11086"
Content-ID: <alpine.DEB.2.22.394.2501271720280.11086@ubuntu-linux-20-04-desktop>

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-362762593-1738025722=:11086
Content-Type: text/plain; CHARSET=UTF-8
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine.DEB.2.22.394.2501271720281.11086@ubuntu-linux-20-04-desktop>

On Mon, 27 Jan 2025, Luca Fancellu wrote:
> Hi Michal,
> 
> > On 27 Jan 2025, at 10:45, Michal Orzel <michal.orzel@amd.com> wrote:
> > 
> > On Arm32, when CONFIG_PHYS_ADDR_T_32 is set, a build failure is observed:
> > arch/arm/platforms/vexpress.c: In function 'vexpress_smp_init':
> > arch/arm/platforms/vexpress.c:102:12: error: format '%lx' expects argument of type 'long unsigned int', but argument 2 has type 'long long unsigned int' [-Werror=format=]
> >  102 |     printk("Set SYS_FLAGS to %"PRIpaddr" (%p)\n",
> > 
> > When CONFIG_PHYS_ADDR_T_32 is set, paddr_t is defined as unsigned long.
> > Commit 96f35de69e59 dropped __virt_to_maddr() which used paddr_t as a
> > return type. Without a cast, the expression type is unsigned long long
> > which causes the issue. Fix it.
> > 
> > Fixes: 96f35de69e59 ("x86+Arm: drop (rename) __virt_to_maddr() / __maddr_to_virt()")
> > Signed-off-by: Michal Orzel <michal.orzel@amd.com>
> > ---
> 
> I’ve tested this one and it fix the compilation issue on the above setup, I’ve also tested
> that it doesn’t introduce issues on other setup (e.g. arm64)
> 
> Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
> Tested-by: Luca Fancellu <luca.fancellu@arm.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
--8323329-362762593-1738025722=:11086--


From xen-devel-bounces@lists.xenproject.org Tue Jan 28 08:07:36 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 08:07:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878291.1288451 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcgcy-0004hH-Hh; Tue, 28 Jan 2025 08:07:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878291.1288451; Tue, 28 Jan 2025 08:07:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcgcy-0004hA-F1; Tue, 28 Jan 2025 08:07:20 +0000
Received: by outflank-mailman (input) for mailman id 878291;
 Tue, 28 Jan 2025 08:07: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 <SRS0=jygh=UU=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcgcw-0004h4-SB
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 08:07:18 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e360ad58-dd4e-11ef-a0e6-8be0dac302b0;
 Tue, 28 Jan 2025 09:07:16 +0100 (CET)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-aaec61d0f65so1159480566b.1
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 00:07:16 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab6760ab363sm734376666b.114.2025.01.28.00.07.15
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 28 Jan 2025 00:07:15 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e360ad58-dd4e-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738051636; x=1738656436; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=SQoNSt0lnND6dkyY2wW+hgZ69iufxKrBF7yRz4FxbLs=;
        b=SOCGvBBXT8CdCag/zf1mzL1bLXoYd0dlF1bcHq6UV8p9LLQLb16gzNHJUHMUsd8i3b
         T/Wqc739xLS2Z6vC351JxDvICr1HCqtjWyCadcEWO2HeUgzCLwRLTWtZVqfhhT6BrdLQ
         etvaV1EkGbL4+I9XgXeVTNLb44SbLDpNBoOts6ILCmsikm/xbGQfBbQNZ/eHUyuaOPqO
         sYQfkbejtk4LeedJQq1ZQO2jai4+FWX01qimqgKdahYZ+tMqxjBtPGZP/9/RaH2cPF2N
         Gto/seIQd6JVAVYsLgYKqIeEOlu23e6a4u2S5CPvaOBGQiwDJDf3yYXpdKU2GhjMsgow
         u7tw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738051636; x=1738656436;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=SQoNSt0lnND6dkyY2wW+hgZ69iufxKrBF7yRz4FxbLs=;
        b=U24TmCUVoxV1Ic01swDKORDhUk0+6ghXiw6YjwyCiqBvss6jOeaGSt3kirdjfVgpMP
         zUuvtwTQAY/w9y7zsfC1WyvH6uu7nkHaWPbFMkcvzcr3l2dBhvMpajDZuAIg4dqY5+0y
         9GAdqtPVRTVMTHhCUNIGqRRGClNWpjVmhPpVzI/4YM9ahvH6odBPHK6xGNzYQQ1lsSyM
         KR1IwQm959wt+v70Gc9p5miQQ+5MgWp1EB6ZX7xaFa+sOvCL1OVZmlYMyC1Bdjw+izI5
         KMyNvxxSqTD38JfdFZZqK0rykWlAi1lipfZ1U7NULI02lhhxNet/Mf40gFCWS7urp9+L
         bqSQ==
X-Forwarded-Encrypted: i=1; AJvYcCUW4V63XQaol+YWQY3ayT5DPgLxS7wb9LystwdqNABPmSVPZDF1SrVNdoigBfFNH700V3A7M3AkhsI=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz9iCAns05uwT3MP2g38UcNoFOZaAFsr3QAaEmPGdK+gn638+IW
	JIL6x+rHOIRH5vMA56rCN4LF3eSd7bhkbQp4wuShLoVgpJnhgwDzl/YlJoH3FA==
X-Gm-Gg: ASbGncsf0brgGArMG1H5WRamJPpSRuZgjKa5nwqood2rzuYkOt+q0yw4mM2S66qVMDV
	9PjMX5W4yY7kgtoV0oUQLBrWiHwoHhkGTgEas8tin2Rr3v/CeFaSctNRSD7v2PTsCtIKxk1I7NX
	qLaRkaYB6gUM9hTU3E64yI3r/oq2yUACN5ecplQeTtSmU0ECeg2pCP5fCr8qd4VGP5Jxg8i5jE0
	THz0dj3Jy2LzsErVW2+beU4Hl/Kk+hHjdno+EiWMZ2KCC0SFI7+iGrNBq0qp7DzQA3R2jhEZCFV
	xFkGm/FvjCm12YkaFA1EJj7w3TQ0TZdtJlyxCv7/QvabTd9965USsaBiSmh5UgmtJpL94+11KC+
	AAQBuDh7kwn4=
X-Google-Smtp-Source: AGHT+IFBgG53KHfbzOEK6+47G4ZE8UmiRXwE3eGohCp3Z2loiHY/kUvdWoaHmdUNS2rqfr7i7pBU8Q==
X-Received: by 2002:a17:907:3e1e:b0:aab:eefd:4ceb with SMTP id a640c23a62f3a-ab38b0a2b92mr4333520966b.10.1738051635876;
        Tue, 28 Jan 2025 00:07:15 -0800 (PST)
Message-ID: <5d2a2c5d-4fa0-44fe-88a8-82a8cf979468@suse.com>
Date: Tue, 28 Jan 2025 09:07:14 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 1/3] xen/riscv: implement software page table walking
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Alistair Francis <alistair.francis@wdc.com>,
 Bob Eshleman <bobbyeshleman@gmail.com>, Connor Davis
 <connojdavis@gmail.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1737391102.git.oleksii.kurochko@gmail.com>
 <00dfc71569bc9971b53e29b36a80e9e020ac61ac.1737391102.git.oleksii.kurochko@gmail.com>
 <21bfd2f5-74b8-409e-956c-dd736a3c0be2@suse.com>
 <e2290a2a-a3c0-4cfe-b9e9-8cfec0b194a8@gmail.com>
 <a304e4f0-709f-4fcd-9847-01fe6ab4b98c@suse.com>
 <d9ca4252-1bf0-4257-ad6b-e91240cc5de3@gmail.com>
 <67446e8f-71d4-480e-8566-1a464b6f6639@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <67446e8f-71d4-480e-8566-1a464b6f6639@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 27.01.2025 18:41, Oleksii Kurochko wrote:
> 
> On 1/27/25 6:22 PM, Oleksii Kurochko wrote:
>>
>>
>> On 1/27/25 1:57 PM, Jan Beulich wrote:
>>> On 27.01.2025 13:29, Oleksii Kurochko wrote:
>>>> On 1/27/25 11:06 AM, Jan Beulich wrote:
>>>>> On 20.01.2025 17:54, Oleksii Kurochko wrote:
>>>>>> RISC-V doesn't have hardware feature to ask MMU to translate
>>>>>> virtual address to physical address ( like Arm has, for example ),
>>>>>> so software page table walking in implemented.
>>>>>>
>>>>>> Signed-off-by: Oleksii Kurochko<oleksii.kurochko@gmail.com>
>>>>>> ---
>>>>>>    xen/arch/riscv/include/asm/mm.h |  2 ++
>>>>>>    xen/arch/riscv/pt.c             | 56 +++++++++++++++++++++++++++++++++
>>>>>>    2 files changed, 58 insertions(+)
>>>>>>
>>>>>> diff --git a/xen/arch/riscv/include/asm/mm.h b/xen/arch/riscv/include/asm/mm.h
>>>>>> index 292aa48fc1..d46018c132 100644
>>>>>> --- a/xen/arch/riscv/include/asm/mm.h
>>>>>> +++ b/xen/arch/riscv/include/asm/mm.h
>>>>>> @@ -15,6 +15,8 @@
>>>>>>    
>>>>>>    extern vaddr_t directmap_virt_start;
>>>>>>    
>>>>>> +paddr_t pt_walk(vaddr_t va);
>>>>> In the longer run, is returning just the PA really going to be sufficient?
>>>>> If not, perhaps say a word on the limitation in the description.
>>>> In the long run, this function's prototype looks like|paddr_t pt_walk(vaddr_t root, vaddr_t va, bool is_xen)| [1]. However, I'm not sure if it will stay that way,
>>>> as I think|is_xen| could be skipped, since using|map_table()| should be sufficient (as it now considers|system_state|) and I'm not really sure if I need root argument
>>>> as initial goal was to use this function for debug only purposes and I've never used it for guest page table (stage-1) walking.
>>>> Anyway, yes, it is still returning a physical address, and that seems enough to me.
>>>>
>>>> Could you share your thoughts on what I should take into account for returning value, probably, I am missing something really useful?
>>> Often you care about the permissions as well. Sometimes it may even be relevant
>>> to know the (super-)page size of the mapping.
>> Perhaps it would be better to change the prototype to:
>>    bool pt_walk(vaddr_t va, mfn_t *ret_pa);
>> or even
>>    void pt_walk(vaddr_t va, mfn_t *ret_pa);
>>    In this case,|ret_pa = INVALID_MFN| could serve as a signal that|pt_walk()| failed.
>> If there's a need to return permissions or (super-)page size in the future, another argument could be added.
>> What do you think? Would this approach be better?
> 
> We have to return mfn_t or paddr_t as pt_walk() is used invmap_to_mfn().

That use doesn't really limit what the function needs to return. It merely
affects how simple (or complicated) the invocation there would be.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 28 08:14:43 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 08:14:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878300.1288460 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcgk4-0006KL-7E; Tue, 28 Jan 2025 08:14:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878300.1288460; Tue, 28 Jan 2025 08:14:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcgk4-0006KE-4j; Tue, 28 Jan 2025 08:14:40 +0000
Received: by outflank-mailman (input) for mailman id 878300;
 Tue, 28 Jan 2025 08:14:38 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=jygh=UU=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcgk2-0006K8-Ig
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 08:14:38 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e98608c4-dd4f-11ef-99a4-01e77a169b0f;
 Tue, 28 Jan 2025 09:14:36 +0100 (CET)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-aaecf50578eso396672366b.2
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 00:14:36 -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
 a640c23a62f3a-ab675e8acb6sm729427166b.76.2025.01.28.00.14.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 28 Jan 2025 00:14:35 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e98608c4-dd4f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738052076; x=1738656876; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=jt+nWAV1QZZp5qIssMiiKcXqaKaLPDo+PVRL+RMiBkM=;
        b=Y6EOeLxPIA/52/Mbx+5ryt0c9D6rKtkj1pvJrQpWq1BZff9kd4h9flMPVFKhjPLvku
         64Ze/tie8itt/jiR28ahwz4aQpU91tJ3uiS7ux6rG8Q/e0d1l+ymbQATlXTT05oAln6K
         EjnT72jbikrTVdNvvl5z+3CKauMMFDwohoo+0gJrXyEdCvDvGMuQ7v7WKMn5PzmTAZSU
         LjrHWHM+fbHHiD08F7WfMRVmKwI3hEXLmiC4fSrkj3dsyD5YEwJe/IVKlLzvpIYcY9Yt
         XXEZeAW5XZ6wQA609YAr8GSDwKBiAciiUtt5NdfpdzPAMdUeKbOeAYikNSGJrs9pQJqu
         Lidg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738052076; x=1738656876;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=jt+nWAV1QZZp5qIssMiiKcXqaKaLPDo+PVRL+RMiBkM=;
        b=GoGvT+9stNGSiJ4y/567MxgCjOaXFM/FzB6V0lo1wHAE4q/h4zKE6s83cinIFwB5R1
         nYv+h5ArfsWidUNo5D2bIeiUy3omFeqq/5bjlZhnfH+nOuZrKL8PsIWJl8BaW0WhIkzm
         x171m+GkJegKvQivcHKUhU8ffxgkHlHVfXwo/zOchTfEeHCNxvWKHA/el8gpdRCtU/HF
         XD3JrxqtYXAtNeVINrcvdbzgWi85UXjMzdQPJ2G7m95EB/V0CNzwbJt7lEOAX88luY/e
         QmJmzJi29cbwVXhSkVKXXC6cMWzg0bPWe1dtYQa0l33wdpycJ2LY2CkXk16gDH4oP/hh
         aA+g==
X-Forwarded-Encrypted: i=1; AJvYcCVtRigucin7lO0ibLAhWrmyTR6VahawoyrRbfarSpvnpbpP/om6GrbADxYq1uHaaVrn2N/JPSJc8V8=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywn4zME8CDl7jTjh0Od2AihSRXM3jQchA0sYOOCA6TsDF+xyHdp
	GOPR1iEiO2po8u24NFuy1it1nuYb2v3BCsImEeNcgk8GVaKJRMV2UxhClvVx9w==
X-Gm-Gg: ASbGncveoy6HRx8J6lAOPPRRcu2wusG/Itg5Jjbxql5WlbT9FbBC6JugoNamBqzBaBy
	47aGhgqcX7+zT0H4Nxw632MvXy3lSdWXQUtAtKymjETtBic98FuAXgHzhZ2CGSSPbZm4XqzftsA
	Dje1RtSPdDy2uvWQ7xnh6WRHFiYdDF691HonAKQaALkWJy0vGzzaCZRe6z0Lpi0f+bw+FVwCKIf
	YnYBa6Vd+X2GbExaXDd0ksQQUsZ897DzqdJY4mAsfRwJWp4THSYUAU/DWm9nFzJ++d1yZ0AYaA9
	iUU9abdU/zmuUhj1nWbRYZ7FdbgzyxxdfRA9iRu9ZWFvTCPvtduWxixyOT5sMbBHsrr3mhVeO6Z
	s
X-Google-Smtp-Source: AGHT+IFQns2SVbOey2WYscX7kXf23MwBEcXmK7GTnLucdRqGrccHBskp9mYlmrt2fsqnPBfWRbVWXA==
X-Received: by 2002:a17:907:1b24:b0:aa6:7b34:c1a8 with SMTP id a640c23a62f3a-ab38b3d664emr3400947366b.55.1738052075832;
        Tue, 28 Jan 2025 00:14:35 -0800 (PST)
Message-ID: <dfe0c6c5-db4a-4e27-9963-fe1b0c2bf629@suse.com>
Date: Tue, 28 Jan 2025 09:14:34 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 1/3] xen/riscv: implement software page table walking
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Alistair Francis <alistair.francis@wdc.com>,
 Bob Eshleman <bobbyeshleman@gmail.com>, Connor Davis
 <connojdavis@gmail.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1737391102.git.oleksii.kurochko@gmail.com>
 <00dfc71569bc9971b53e29b36a80e9e020ac61ac.1737391102.git.oleksii.kurochko@gmail.com>
 <21bfd2f5-74b8-409e-956c-dd736a3c0be2@suse.com>
 <e2290a2a-a3c0-4cfe-b9e9-8cfec0b194a8@gmail.com>
 <a304e4f0-709f-4fcd-9847-01fe6ab4b98c@suse.com>
 <d9ca4252-1bf0-4257-ad6b-e91240cc5de3@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <d9ca4252-1bf0-4257-ad6b-e91240cc5de3@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 27.01.2025 18:22, Oleksii Kurochko wrote:
> On 1/27/25 1:57 PM, Jan Beulich wrote:
>> On 27.01.2025 13:29, Oleksii Kurochko wrote:
>>> On 1/27/25 11:06 AM, Jan Beulich wrote:
>>>> On 20.01.2025 17:54, Oleksii Kurochko wrote:
>>>>> RISC-V doesn't have hardware feature to ask MMU to translate
>>>>> virtual address to physical address ( like Arm has, for example ),
>>>>> so software page table walking in implemented.
>>>>>
>>>>> Signed-off-by: Oleksii Kurochko<oleksii.kurochko@gmail.com>
>>>>> ---
>>>>>    xen/arch/riscv/include/asm/mm.h |  2 ++
>>>>>    xen/arch/riscv/pt.c             | 56 +++++++++++++++++++++++++++++++++
>>>>>    2 files changed, 58 insertions(+)
>>>>>
>>>>> diff --git a/xen/arch/riscv/include/asm/mm.h b/xen/arch/riscv/include/asm/mm.h
>>>>> index 292aa48fc1..d46018c132 100644
>>>>> --- a/xen/arch/riscv/include/asm/mm.h
>>>>> +++ b/xen/arch/riscv/include/asm/mm.h
>>>>> @@ -15,6 +15,8 @@
>>>>>    
>>>>>    extern vaddr_t directmap_virt_start;
>>>>>    
>>>>> +paddr_t pt_walk(vaddr_t va);
>>>> In the longer run, is returning just the PA really going to be sufficient?
>>>> If not, perhaps say a word on the limitation in the description.
>>> In the long run, this function's prototype looks like|paddr_t pt_walk(vaddr_t root, vaddr_t va, bool is_xen)| [1]. However, I'm not sure if it will stay that way,
>>> as I think|is_xen| could be skipped, since using|map_table()| should be sufficient (as it now considers|system_state|) and I'm not really sure if I need root argument
>>> as initial goal was to use this function for debug only purposes and I've never used it for guest page table (stage-1) walking.
>>> Anyway, yes, it is still returning a physical address, and that seems enough to me.
>>>
>>> Could you share your thoughts on what I should take into account for returning value, probably, I am missing something really useful?
>> Often you care about the permissions as well. Sometimes it may even be relevant
>> to know the (super-)page size of the mapping.
> 
> Perhaps it would be better to change the prototype to:
>    bool pt_walk(vaddr_t va, mfn_t *ret_pa);
> or even
>    void pt_walk(vaddr_t va, mfn_t *ret_pa);
>    In this case,|ret_pa = INVALID_MFN| could serve as a signal that|pt_walk()| failed.
> If there's a need to return permissions or (super-)page size in the future, another argument could be added.
> 
> What do you think? Would this approach be better?
> 
> I am also considering returning a structure containing the|mfn| (or|paddr_t|) and adding other properties (such as permissions or
> page size) as needed in the future. Both solutions seem more or less equivalent.

Imo the most natural thing for a page walking function would be to return the
leaf PTE (or the leaf-most not-present [or otherwise "no-access"] one). That
would provide (almost) all possible information to the caller. "Almost"
because depending on how page walk works, permissions may combine across page
table levels. Yet then (see also the "no-access" above) this would also
require further input, to specify the context for which the translation is
being seeked. For example, the intention to write may want to yield no valid
PTE when there are present ones down to the leaf, but effective permissions
say "read-only".

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 28 09:40:25 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 09:40:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878311.1288486 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tci4w-0000i3-TW; Tue, 28 Jan 2025 09:40:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878311.1288486; Tue, 28 Jan 2025 09:40:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tci4w-0000hK-OB; Tue, 28 Jan 2025 09:40:18 +0000
Received: by outflank-mailman (input) for mailman id 878311;
 Tue, 28 Jan 2025 09:40:17 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=WhQb=UU=amd.com=Michal.Orzel@srs-se1.protection.inumbo.net>)
 id 1tci4v-0000QT-RJ
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 09:40:17 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on20631.outbound.protection.outlook.com
 [2a01:111:f403:2416::631])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id dfc1600e-dd5b-11ef-a0e6-8be0dac302b0;
 Tue, 28 Jan 2025 10:40:15 +0100 (CET)
Received: from SA9PR03CA0025.namprd03.prod.outlook.com (2603:10b6:806:20::30)
 by SA1PR12MB5639.namprd12.prod.outlook.com (2603:10b6:806:22b::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.22; Tue, 28 Jan
 2025 09:40:07 +0000
Received: from SN1PEPF0002636A.namprd02.prod.outlook.com
 (2603:10b6:806:20:cafe::bb) by SA9PR03CA0025.outlook.office365.com
 (2603:10b6:806:20::30) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8377.23 via Frontend Transport; Tue,
 28 Jan 2025 09:40:07 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SN1PEPF0002636A.mail.protection.outlook.com (10.167.241.135) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8398.14 via Frontend Transport; Tue, 28 Jan 2025 09:40:07 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 28 Jan
 2025 03:40:06 -0600
Received: from XIR-MICHALO-L1.xilinx.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39
 via Frontend Transport; Tue, 28 Jan 2025 03:40:05 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: dfc1600e-dd5b-11ef-a0e6-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=MByVBeI9/F7YL/5QXHWhPWnbbDH8wAPEkEZo5qV2i7aHrIuuNBSUfXobA93I3AwqU46cryE3bX8gwoGqCfLeQ+yDo8H4ZAvfCx1+VDJN0ihgY0uARELTJgLYgkJgbTiqWkjrD9u0LsyQQ92dzZd3DlhPrHjO5Vhu4bVxZVWLiPyM2JAgE4A5XWBjauHb/K91XCTcn1j5oHwvHRQqUpPrA0jS2e4kQmOepBQATAV1NsskoIDD9SVZehUJ2902aWaMAxTRBLWvEZsnnCUk2kY4dvbvfBY/cs1uBKFjpKYEoD/OfjWBQ9d277EEEC8UZ3E2CUpxxx/TdPvkSL5pz9ZruQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=NdAIrJ/MqjNZfh4vApir3Fhdo53NdRh7/2IUDn+1cts=;
 b=XwHdJq9PY+g5NsAyZP+zPxyB5gPf8hMMWIlaw/S5MSumuz8KJL2m+/W/xO3xOC33d0zQqBhKqyCL+kVE7N7cAIwhVhOcs+LAeM/oWgcqhLueUG5U5FrsmN3/Iq7REm5B26X7kgU5gBSPwi1sVqn11qZ1aZUM9nVOQLgO2stz0iP5AAtjcIuIwDzx/fwro0kuUkgWLV2Tk7lQjYu4LRAA6Jb1FNTvcaAqUES77hdub9m38Quyrk6GSEzwboApBYKDJSFrEUGgvhLnQ84kN/VURJRacOAGsmIE6LmiN10StScK0KZ7TC08I/VnHfub28s2HBJEnZerUZIdj+ZoCikoFQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=NdAIrJ/MqjNZfh4vApir3Fhdo53NdRh7/2IUDn+1cts=;
 b=EmIu05WktGw2vo+LCVswYpsWYcSRLlE3AT8W1ELMc76sKd0WnLZepHHAtbIw0qtm0Sonnih1gkDHa5SUXSo4p8VBO3MGbKasb7KVBOwLxesTsk6ei4yUhvhBx/MM1ixJM2yA9hNlvC+F8ImSN/YVvgICliuSps9zLI29xDp4rwg=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Michal Orzel <michal.orzel@amd.com>
To: <xen-devel@lists.xenproject.org>
CC: Michal Orzel <michal.orzel@amd.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand Marquis
	<bertrand.marquis@arm.com>, <oleksii.kurochko@gmail.com>
Subject: [for-4.20][PATCH v2 1/2] device-tree: bootfdt: Fix build issue when CONFIG_PHYS_ADDR_T_32=y
Date: Tue, 28 Jan 2025 10:40:01 +0100
Message-ID: <20250128094002.145755-2-michal.orzel@amd.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <20250128094002.145755-1-michal.orzel@amd.com>
References: <20250128094002.145755-1-michal.orzel@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB04.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF0002636A:EE_|SA1PR12MB5639:EE_
X-MS-Office365-Filtering-Correlation-Id: 2a5daca5-b10e-4680-3af9-08dd3f7fc061
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|36860700013|376014|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?jLuw5yeT+DLcd05Gr29gO4hAlKcY7oqbLe29HZQIEz1qkp5PfJpz1TW2Gm+Y?=
 =?us-ascii?Q?GX2s3xV5jPvNtbpOfWSAwlcKuEeovBKVxNUptWXISbohhJkuNBYVnINOyIQb?=
 =?us-ascii?Q?chSfvblS83hdj9vkjp2LCuZJB7fD4pys5nJgTPlSVi6QfP14KLiGmQPtqi9U?=
 =?us-ascii?Q?tLHnHjdk1uHCMVqPZfXbzhxdBmO3Fyh9siRNuVOySUky4TIEMxAyw2YIPrzr?=
 =?us-ascii?Q?ughBsvd/mITaS8/rBIPbXAKhL5YJCBwogKngmYEaqpib2cLxkYkEUiV6+65P?=
 =?us-ascii?Q?ZUcUVPjckYMeN+e0k2knKDeHDhcg2UICudu0v6OuPNev47hWh+Zhdfrpp2GR?=
 =?us-ascii?Q?dnzDOqo02YQRh2nHpvUL9hO0ZBBR19+Ov0fqCMTISPmRLnY96nxuDSLQNXAk?=
 =?us-ascii?Q?O9KcxThqs3GxU6mMx3+CZI6WqDbwAZRItK1lJGvQb9beyW4OiNvJg2B5gZKV?=
 =?us-ascii?Q?WCTRyoTRWqXWcN+XfJ3Dk4fPgwbAkjVbLLU0XzwBEnX+CzfBHTU2EiOCPk4C?=
 =?us-ascii?Q?a4Wv0hXkS/yxABSrTzaP7oexzuRyyJHjRrzt2UMG5phDNNyHjN7aLpKkHKmp?=
 =?us-ascii?Q?maCVsXoedR6wELkX8ikVU/UCwn20jm9dapQBbioPMLtSNTNT6WwxPTIe7Dev?=
 =?us-ascii?Q?3umYavmd9Tx1uVNiFUsGaU0OtIU2o2/cTkUjC1Npj0NDplWbyh8gTy3QCY2T?=
 =?us-ascii?Q?D+E1HlxMEtDXF00RWCZHdF6muh4GDJvG6t5BSb/Lp88vp4jn6EKHZlRX/YCJ?=
 =?us-ascii?Q?Dxjp2wREXGmrtnGJtyKWxGd0GyMJg9xSaV2Q6FUFVnnwEuMX002GREG5zz7+?=
 =?us-ascii?Q?cV/jSL7ZJyXSnPc2ErRryQkZU/kABaGP3Sy0QHMNy3soSgmNpKWgtCTBR/Pl?=
 =?us-ascii?Q?ZnZYDLER0S5RQdD1P9lHpBC24ziQPfw0DsF/XsAUcaQYpSXTnDfnvqVyIRfn?=
 =?us-ascii?Q?t7oMK10kkWRZzIKoWn0yos9I1/JeNWEdOnt0F3SutJEbhmlb5I3a0EtkufTD?=
 =?us-ascii?Q?0ovkp2IOX+04ptvvVft0nvOLnzJ1+wsw1e9e3jK8KnXbrYw1hkioGCWUBlOP?=
 =?us-ascii?Q?U5f+Un7n6O+QX7rSzMYgStvWOcettOJutdkTT46MTnyhluH0u3GUZYWS0Cc7?=
 =?us-ascii?Q?IVr7CeZOedqju+DtBoFCGk1eQYJeSSTg4VxBQvLjuqE2IQDlOr0AUOzU5ELo?=
 =?us-ascii?Q?0l7MMjzw4S/KaIfRNN1vdBt1bOS1IMdYbuyDVYd+TF39jKnlVaL5wYTqmiSo?=
 =?us-ascii?Q?5VhtUMs8/UIN0qJbZZRveDW/k90Ae37WkjM1B67V9W3q8JDdCRz6Tf9INAXs?=
 =?us-ascii?Q?gd0E1i414Xfj8F2O5sL40y2TWdqAkNZtaYbaemY0x3ixH7agLJjoCg1YtxoM?=
 =?us-ascii?Q?0bR3RHa84GbyXA7IG8dVhIrFHJSJjQOaiMlj8qtZ53DBpYCMWMcUTEb6fbOw?=
 =?us-ascii?Q?G8gdkJK913dzGjw8Ih1WAGK4CvJVmv2VuOgofrjJJ3+Nem8/Nv3LkQ/Eber8?=
 =?us-ascii?Q?lYN4jKI4FyFzV5A=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(376014)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2025 09:40:07.6691
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 2a5daca5-b10e-4680-3af9-08dd3f7fc061
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF0002636A.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB5639

On Arm32, when CONFIG_PHYS_ADDR_T_32 is set, a build failure is observed:
common/device-tree/bootfdt.c: In function 'build_assertions':
./include/xen/macros.h:47:31: error: static assertion failed: "!(alignof(struct membanks) != 8)"
   47 | #define BUILD_BUG_ON(cond) ({ _Static_assert(!(cond), "!(" #cond ")"); })
      |                               ^~~~~~~~~~~~~~
common/device-tree/bootfdt.c:31:5: note: in expansion of macro 'BUILD_BUG_ON'
   31 |     BUILD_BUG_ON(alignof(struct membanks) != 8);

When CONFIG_PHYS_ADDR_T_32 is set, paddr_t is defined as unsigned long,
therefore the struct membanks alignment is 4B and not 8B. The check is
there to ensure the struct membanks and struct membank, which is a
member of the former, are equally aligned. Therefore modify the check to
compare alignments obtained via alignof not to rely on hardcoded
values.

Fixes: 2209c1e35b47 ("xen/arm: Introduce a generic way to access memory bank structures")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
Changes in v2:
 - modify the check to test against alignment of struct membank
---
 xen/common/device-tree/bootfdt.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c
index 47386d4fffea..529c91e603ab 100644
--- a/xen/common/device-tree/bootfdt.c
+++ b/xen/common/device-tree/bootfdt.c
@@ -27,8 +27,8 @@ static void __init __maybe_unused build_assertions(void)
      */
     BUILD_BUG_ON((offsetof(struct membanks, bank) !=
                  offsetof(struct meminfo, bank)));
-    /* Ensure "struct membanks" is 8-byte aligned */
-    BUILD_BUG_ON(alignof(struct membanks) != 8);
+    /* Ensure "struct membanks" and "struct membank" are equally aligned */
+    BUILD_BUG_ON(alignof(struct membanks) != alignof(struct membank));
 }
 
 static bool __init device_tree_node_is_available(const void *fdt, int node)
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Tue Jan 28 09:40:25 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 09:40:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878309.1288471 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tci4v-0000Qg-8k; Tue, 28 Jan 2025 09:40:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878309.1288471; Tue, 28 Jan 2025 09:40:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tci4v-0000QY-51; Tue, 28 Jan 2025 09:40:17 +0000
Received: by outflank-mailman (input) for mailman id 878309;
 Tue, 28 Jan 2025 09:40:16 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=WhQb=UU=amd.com=Michal.Orzel@srs-se1.protection.inumbo.net>)
 id 1tci4u-0000QN-DX
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 09:40:16 +0000
Received: from NAM02-DM3-obe.outbound.protection.outlook.com
 (mail-dm3nam02on2062f.outbound.protection.outlook.com
 [2a01:111:f403:2405::62f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id de76f5a8-dd5b-11ef-99a4-01e77a169b0f;
 Tue, 28 Jan 2025 10:40:12 +0100 (CET)
Received: from SA9PR03CA0006.namprd03.prod.outlook.com (2603:10b6:806:20::11)
 by SA1PR12MB7409.namprd12.prod.outlook.com (2603:10b6:806:29c::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.22; Tue, 28 Jan
 2025 09:40:06 +0000
Received: from SN1PEPF0002636A.namprd02.prod.outlook.com
 (2603:10b6:806:20:cafe::19) by SA9PR03CA0006.outlook.office365.com
 (2603:10b6:806:20::11) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8377.23 via Frontend Transport; Tue,
 28 Jan 2025 09:40:05 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SN1PEPF0002636A.mail.protection.outlook.com (10.167.241.135) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8398.14 via Frontend Transport; Tue, 28 Jan 2025 09:40:05 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 28 Jan
 2025 03:40:04 -0600
Received: from XIR-MICHALO-L1.xilinx.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39
 via Frontend Transport; Tue, 28 Jan 2025 03:40:03 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: de76f5a8-dd5b-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=M/l9EMMOBzYSolzKXqDsn0hDnZ0AniXT0c74oxtwbeg609Q0kf+Qz119SyXFacohW5NjUL4a+l3F6RPVj2OKtCAu5tEAox5aU72oOzBV7uHf2F2EgmeDman81GXMkuz0IbvLT5iy4Qs2i+KQzq0WWoXL4fYgaaS+DVtbVnRvz1nF8q3k+Lrsvqevvxj3nXBv/BrvvjS0VoEXoXgh7vEkqanaViCHL4jgLTL9MWrd1RXUeir0w66OGCOxpy409C81IT8oClUYTqG5f8CR1b5l9U/1gF/VuqF040G+yB8CUAeCTcz3ohQ3wzGtUirKDJsfpvljMcUpchqu99+nW06iwg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=6w7NW5Tq9BQ4T5PXnzy3s3SW3uM9h9Kf76VWukGYyXA=;
 b=oNgfJShg8XxD9fpIQQkKzwu8V40cSmjmP+KVcIPKorbUQ4HVhtgGuDk8ZpBmIPwDenjTkICdd/EbbiUjphP5CrHS1zJbdlcYSCrGws/DNfj0IulOSKG+rdBsr+82NG0MjuuypzDRwO6F1ejifbS41TSpeQBdIJdYw1OzWy/oabVi16T2yxOmpX0I789Pn3XJ809CLnQSiQT8FV4l+3ZVAcAaa2cGlgPskUdcKRvBUKJgGqkxqWDBg8CPkuwagGZAPIVFghvCK4q4RGXUF7ggPzE2lL0RxWVwQNHFVnPijLHog1QIFZQS/m5yVI4VqKPFJiwZ6igKb/26dKQGKR0eqg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=6w7NW5Tq9BQ4T5PXnzy3s3SW3uM9h9Kf76VWukGYyXA=;
 b=OgrviBkQuzAXlUTUfi2uKRTZ/jommb/SgU4zomRbwrbTuBfqtAV3wsIGmXcEm9TqY4rctNtBprMM2dDllprVrYllezzFJzIy4k4R38Kpw8HIaGEqzSx6lrMz+CRzGtnohv/Xi1QeGB1F4J0BZNpJOaCU0vXZZD4GUJoIIfi0kks=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Michal Orzel <michal.orzel@amd.com>
To: <xen-devel@lists.xenproject.org>
CC: Michal Orzel <michal.orzel@amd.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand Marquis
	<bertrand.marquis@arm.com>, Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	<oleksii.kurochko@gmail.com>
Subject: [for-4.20][PATCH v2 0/2] xen/arm CONFIG_PHYS_ADDR_T_32=y fixes
Date: Tue, 28 Jan 2025 10:40:00 +0100
Message-ID: <20250128094002.145755-1-michal.orzel@amd.com>
X-Mailer: git-send-email 2.25.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB04.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF0002636A:EE_|SA1PR12MB7409:EE_
X-MS-Office365-Filtering-Correlation-Id: d43b8445-3f09-440b-7131-08dd3f7fbf13
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|376014|82310400026|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?gVfC7os4e5q85qXyUoRoxDHNn7IQunBRAGuJRTtN/U0gAnA+tZEUepnD+Oxh?=
 =?us-ascii?Q?gyNoDOVT7bP/YMZ8f9RBtgIFIeCQSN4RQW+b/G+V9UPXtfcgpQFeuoedPBaw?=
 =?us-ascii?Q?F663Tawx98+ms1cifOgj2ZRQyAtM20woUbq8E0j54lc2wO7WyfoX3sNYb9lW?=
 =?us-ascii?Q?WRqhUWeDHvYsHQOb9MVtmX1xeUn3TBJ4JgB0lmVM1dHRlDs2yDaOHSiSJK7c?=
 =?us-ascii?Q?H0T6/QO1/c6YRvJ08zNQ738amV9bSvWwvipvUJxriRYbr/Hscs/j/TE+r6+7?=
 =?us-ascii?Q?+Zdew6WyGtGQ4v3UoIjNVnvw/DaH72skxmKyRIi31eOKilWATCvO/ChB2BQO?=
 =?us-ascii?Q?vrkoaNGmdwLgePwRDDW3IxckZyhEcAgCH2KFCuEgWHpIwGPnwklXS8mPdMa2?=
 =?us-ascii?Q?2AUtIryxv2O4Lhgsii0D7DXRvsNDRLq/wVzUV/BjcOg560nwx695LW5QQl99?=
 =?us-ascii?Q?BxZxB/AYkRwmMPiref4leWaDDOCUUu8h1DKk7x6Jib1lcPslrtWzJ97dkKnx?=
 =?us-ascii?Q?NSoyOlyRZ+gr1n+DDBWw5d86tltdOQAZlh+XorI94+wq8SNMpaj2y5nn8gbg?=
 =?us-ascii?Q?raYfsyERUclOqynJay1sIIeDu7ykejj2w/VrnnbS9Qs4RAdL2jtmHGFtAiux?=
 =?us-ascii?Q?T2TpoWan83CE7hjL4mGKCQ9cFqCHu07QxAISBpQAZ1vyntuMkyDJkZJqbSBF?=
 =?us-ascii?Q?WcVxd6PIipe0khGmBL5HWa8qvmqZ8cWnbZ9UuQ+eXDkk6wbHLTS1l1Fh+USC?=
 =?us-ascii?Q?krMMUKJ5vfI/VWQI2sj1+wxR1Zw/VDWFy0d9vihwyaJBFHfJpEajiwToN9vH?=
 =?us-ascii?Q?O1on5omWaZ/XJwBqfJo6gdUco3pb4GRbA0VN7YTkbKsGnPCr+uy7P/UARug8?=
 =?us-ascii?Q?Zx6lTF8JKVA+FWfUgpDYuq6HIhmlYvA6kc1HbyxsQM3inRQHw0X+of41zItY?=
 =?us-ascii?Q?flPlz24HrKuG7bYPd6L23lLKbIcjmsqkinocAEukzjeRonewzoDFNumi74Ji?=
 =?us-ascii?Q?R/xspEfeE0pP3BB64kfduL6+lEV4sEK2Z/SAgmjJRg+Oxg+yWL+SYm6Rkcmz?=
 =?us-ascii?Q?XCwIVhexfhXDWUcCDgK/ScBNh4i6ruwGCWKSdI+AkQ39ttWqY3JRWtOhBr1f?=
 =?us-ascii?Q?Mv/vj1fgyl3Y5DvktpVhVPPEfvEbU8reEdOXGfUJyKY8LoHEmk5MthyNWVtV?=
 =?us-ascii?Q?S2dyM8Cnca8XVlaciC1lOFtGAjJ3iy5f4NlYN1oDeW06eedOHzI/wWPS3wd0?=
 =?us-ascii?Q?b4hu3RS7LRBFYZ4nhSgU9vYD0lK4z5kDiwp6p3YbpZK2SuuRqJLB03KtQ5t4?=
 =?us-ascii?Q?zkfpAMCDVsLLpHNWjU26PoPR1AKOO1u5JdSdo5sgI6OiELhMdO9dLlaZdTH8?=
 =?us-ascii?Q?YZEyMKdWupun13cCNNmx5Bss4flXxtKtRlcPEIJqVrhcb6J0DXdiQM/Zv7Q7?=
 =?us-ascii?Q?8h19AZ3bhWtc0sIQctHY239dgr0yMn8wugTOZgmZNim7XTE9gi+UWm/UvvUE?=
 =?us-ascii?Q?wuZ+yLmLDZ1G/RI=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(82310400026)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2025 09:40:05.4659
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d43b8445-3f09-440b-7131-08dd3f7fbf13
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF0002636A.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB7409

This series contains build fixes when CONFIG_PHYS_ADDR_T_32=y.

@Oleksii:
This is a release blocker.

Michal Orzel (2):
  device-tree: bootfdt: Fix build issue when CONFIG_PHYS_ADDR_T_32=y
  xen/arm: Fix build issue when CONFIG_PHYS_ADDR_T_32=y

 xen/arch/arm/include/asm/mm.h    | 2 +-
 xen/common/device-tree/bootfdt.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Tue Jan 28 09:40:26 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 09:40:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878310.1288481 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tci4w-0000er-KH; Tue, 28 Jan 2025 09:40:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878310.1288481; Tue, 28 Jan 2025 09:40:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tci4w-0000ek-Gc; Tue, 28 Jan 2025 09:40:18 +0000
Received: by outflank-mailman (input) for mailman id 878310;
 Tue, 28 Jan 2025 09:40: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
 <SRS0=WhQb=UU=amd.com=Michal.Orzel@srs-se1.protection.inumbo.net>)
 id 1tci4v-0000QN-04
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 09:40:17 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20618.outbound.protection.outlook.com
 [2a01:111:f403:2009::618])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e005e2cd-dd5b-11ef-99a4-01e77a169b0f;
 Tue, 28 Jan 2025 10:40:15 +0100 (CET)
Received: from SJ0PR03CA0258.namprd03.prod.outlook.com (2603:10b6:a03:3a0::23)
 by CY5PR12MB6106.namprd12.prod.outlook.com (2603:10b6:930:29::7) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.22; Tue, 28 Jan
 2025 09:40:10 +0000
Received: from SJ1PEPF00002320.namprd03.prod.outlook.com
 (2603:10b6:a03:3a0:cafe::dc) by SJ0PR03CA0258.outlook.office365.com
 (2603:10b6:a03:3a0::23) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8377.23 via Frontend Transport; Tue,
 28 Jan 2025 09:40:10 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SJ1PEPF00002320.mail.protection.outlook.com (10.167.242.86) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8398.14 via Frontend Transport; Tue, 28 Jan 2025 09:40:09 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 28 Jan
 2025 03:40:08 -0600
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB06.amd.com
 (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 28 Jan
 2025 03:40:08 -0600
Received: from XIR-MICHALO-L1.xilinx.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39
 via Frontend Transport; Tue, 28 Jan 2025 03:40:06 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e005e2cd-dd5b-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=YlVU8/zyJz0/QZoEmFgMCxhJ/nrFEHtP75M2w6+PM0uNBu9gcT7qS/5FhJr0+71S9g6a6qecbNmQ6Djh8qphRRjSxkIumXFv3mL30DCt5kELTfeFdRahIXD466vYji2MK63Rz5bnRsoQ3XYHDDxQ9cB5wtp4Tiyl51F3n8JnKNVtepVWAMzeE5yXYybCugsOQXvD+8Lj5GniYSbFgOv6b3MEZlGjiz/QaCbRo/dJSDGCqsEMNdiuG/Yuq5ACWR+uDDMTyOwOn9gyhM4sO816xMJNI018p1Jx4qF9KS2hA0YqxatNLPRnt8Z+shUcoWiMDrjJkQhuYZwPcwxxBUiXOw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=p5PS00aovMc/LXTzX3cWiC6NVUzhB6/IMA3gbnyVqzM=;
 b=D7wN9AMda9m9+7wBgZXIYNwl5b3EeSGrsrJ9goF+DX5EFBWU2xDVkoKR3ZdvPP6XVkt7GWsL7itieM8OmklV4oPt6gxPaBfQ2yPHsWUGK11u1TY8T1zyYre07IW2uXyePSo3pyTgpmL8JczZXo3UyvWa/g3OhGYXD67jNNLICizZ1zgPoQhIkT08IsH/03skzEKVLzhO6XNigo+/M9lqE5n4Jh1OlMH6lq0zpo5lVZMYgijj2XdYDw7QOXGd/3Ug0GuI69ViNZeTmKAQROj5slJh2qaSm82riIs6uEMWAhtrEjx/EofBnAozQ3h5zWpnBQ/0I3MSHT+CfsNfJASBMg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=p5PS00aovMc/LXTzX3cWiC6NVUzhB6/IMA3gbnyVqzM=;
 b=ueVVHoD5wjWM4N047gqpCIGyOkpRA24e+iLsFzDU/S5D0JWkm8CaPi3xh3KLmS055+8lhVtEUskFc3HpqkWhJpOI0fOCIwoCjvBeXlqoSq5fyTEf6QCcTKum2zLy5/T7M6HZ5tD0STpYAFKtChXHpU0zSr8mmQDcmb9J7HJTlpk=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
From: Michal Orzel <michal.orzel@amd.com>
To: <xen-devel@lists.xenproject.org>
CC: Michal Orzel <michal.orzel@amd.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand Marquis
	<bertrand.marquis@arm.com>, Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	<oleksii.kurochko@gmail.com>, Luca Fancellu <luca.fancellu@arm.com>
Subject: [for-4.20][PATCH v2 2/2] xen/arm: Fix build issue when CONFIG_PHYS_ADDR_T_32=y
Date: Tue, 28 Jan 2025 10:40:02 +0100
Message-ID: <20250128094002.145755-3-michal.orzel@amd.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <20250128094002.145755-1-michal.orzel@amd.com>
References: <20250128094002.145755-1-michal.orzel@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF00002320:EE_|CY5PR12MB6106:EE_
X-MS-Office365-Filtering-Correlation-Id: d6df9984-2065-4f39-ceea-08dd3f7fc176
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|36860700013|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?J4JC/3EXPRJp9LbF7KAZWarMl/+Er0MkoTDzfCC/hPZxpH7qlD1c1Uv0ln6o?=
 =?us-ascii?Q?ypcimIOAaEqMsQytF0ui6z+srwY568chCOVrlX50qAx7HcLh2mfD+OXiOcWe?=
 =?us-ascii?Q?q9pZ4J9IXMXIpOSTi9uxLk6dilfe7F8+nb4bW1u4r3VQ2pZIl9F87SOOzGVq?=
 =?us-ascii?Q?bqo6gFY1q31iXf7n29uomreHu3wr+BBsFYwH/BWLHlOnaa7qesh08LzUoz2b?=
 =?us-ascii?Q?PhTuyi3ebXkV6sDd+/qAtDh2Rb2LyIePpSW58SrJN8rnuaKklumBf5NcvnzT?=
 =?us-ascii?Q?Gq6V2Lzs+lSSKODBHpljfh536EJDVAoyxk3rLFDu28MrqiYjAwQz4Ps6/c6j?=
 =?us-ascii?Q?PGuoRkETGB+/y0+ttB538zjy8M8Ax2nezhkG/RRfj+RkXCzoC74PXq2FTl8n?=
 =?us-ascii?Q?oVJGHvIIatLPNk7x0j/7Ld55iLDhOyjOfJMduiFeW6Nglna93LfWd+NQTl3K?=
 =?us-ascii?Q?GZtZq9fg3+/AS41vUgP1jpEUC1jQOEAPB7zQF1615TlB5rMt4VtUOuhwaQKk?=
 =?us-ascii?Q?FQHRFjXkAh2H8ExrmU6VK1YY9ayFVonVTeIDjaArQwuF3uA4AgzPJj1IeGep?=
 =?us-ascii?Q?RwuykkWrhwfsLEMD6VE4Ho6ShJccYKc21P2tOGxr6o+f72zchuvdACsDR+yt?=
 =?us-ascii?Q?zgZ+ApT0W3peobd34EPU3a3Gljo800NAE3NqfRPPmpTYiyXrS8+u2AcjShQ7?=
 =?us-ascii?Q?szYwjPmUE+6gvOZMW8obu/PMy6d2i+FHPG5OQZGvnVWQWLKtyLacvHSpwMSb?=
 =?us-ascii?Q?Zs/I2+l06SWzyeSnGMtQ6o35gTHI2sKpQV89bDk+75I9JSjhY/D2Sx6Zk8k1?=
 =?us-ascii?Q?qHMjLCVMWywJPt6LOyvO5vnBBrvWt19bvhOL2NBAc6YbG4gJRZAQGSfwlmvj?=
 =?us-ascii?Q?2zJAFWVE/IAwctE/boGY2INlbMw6fVWL6DegNSvAnsQkWI+dFWFdiImtccaB?=
 =?us-ascii?Q?8YvHDhz09iuDHRuGiuD9B0GBaWtJ8aO1P9mYVpSX9GxTBYB5AIMmxCGH32qH?=
 =?us-ascii?Q?r/XOk2fwIk+y2XelaMKAgpJ7DGemThMW71l1+91DYk58+GTj23Mbbrkkuo2N?=
 =?us-ascii?Q?qiTKAtO/N8dU7Bii2pOQOTGLFMp9sF6e1dbll+PaF9T95J6ERP+9lj3yXBgk?=
 =?us-ascii?Q?8ZiiQ6wRiCZU49OPBe8ngR0AvjfiH8SfmOneJvVJoun3xVoGhh6pWNElHUJK?=
 =?us-ascii?Q?omltlqLumzU44OioyPYT3FJgJAg691ZGBNyydxFUbeMhRjifrDIjH5W/fFoH?=
 =?us-ascii?Q?haE2aiC2oUxtTwLjq8k30IbmRFftqds88F8/mXRMfKNlKmUuqshOfAnmoZtM?=
 =?us-ascii?Q?2cZiCRJ9o8IVSB/xNjdBh+neu35bGPJY4L9hcIjb+lyakBsGJZQtTVFUyvYb?=
 =?us-ascii?Q?UtdXCggJliNRqdawJOOBq+oYpJ2v3i3pP8FdOz+rksDUJXodbGWMHN+YZduh?=
 =?us-ascii?Q?0MOMLnttyE39SvemWt9JKR6IgGSIOzRWeCDDEhRqjkx8/1oVJVIefuYY9244?=
 =?us-ascii?Q?iQCxmFQIr3prjUs=3D?=
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:(13230040)(1800799024)(376014)(36860700013)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2025 09:40:09.4726
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d6df9984-2065-4f39-ceea-08dd3f7fc176
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:
	SJ1PEPF00002320.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR12MB6106

On Arm32, when CONFIG_PHYS_ADDR_T_32 is set, a build failure is observed:
arch/arm/platforms/vexpress.c: In function 'vexpress_smp_init':
arch/arm/platforms/vexpress.c:102:12: error: format '%lx' expects argument of type 'long unsigned int', but argument 2 has type 'long long unsigned int' [-Werror=format=]
  102 |     printk("Set SYS_FLAGS to %"PRIpaddr" (%p)\n",

When CONFIG_PHYS_ADDR_T_32 is set, paddr_t is defined as unsigned long.
Commit 96f35de69e59 dropped __virt_to_maddr() which used paddr_t as a
return type. Without a cast, the expression type is unsigned long long
which causes the issue. Fix it.

Fixes: 96f35de69e59 ("x86+Arm: drop (rename) __virt_to_maddr() / __maddr_to_virt()")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Tested-by: Luca Fancellu <luca.fancellu@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
---
Changes in v2:
 - none
---
 xen/arch/arm/include/asm/mm.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/include/asm/mm.h b/xen/arch/arm/include/asm/mm.h
index f91ff088f6b1..a0d8e5afe977 100644
--- a/xen/arch/arm/include/asm/mm.h
+++ b/xen/arch/arm/include/asm/mm.h
@@ -263,7 +263,7 @@ static inline void __iomem *ioremap_wc(paddr_t start, size_t len)
 
 #define virt_to_maddr(va) ({                                        \
     vaddr_t va_ = (vaddr_t)(va);                                    \
-    (va_to_par(va_) & PADDR_MASK & PAGE_MASK) | (va_ & ~PAGE_MASK); \
+    (paddr_t)((va_to_par(va_) & PADDR_MASK & PAGE_MASK) | (va_ & ~PAGE_MASK)); \
 })
 
 #ifdef CONFIG_ARM_32
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Tue Jan 28 10:35:05 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 10:35:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878337.1288501 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcivq-0008BA-SQ; Tue, 28 Jan 2025 10:34:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878337.1288501; Tue, 28 Jan 2025 10:34:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcivq-0008B3-Ov; Tue, 28 Jan 2025 10:34:58 +0000
Received: by outflank-mailman (input) for mailman id 878337;
 Tue, 28 Jan 2025 10:34:57 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=ldbH=UU=arm.com=Luca.Fancellu@srs-se1.protection.inumbo.net>)
 id 1tcivo-0008Ax-VM
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 10:34:57 +0000
Received: from EUR03-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur03on20620.outbound.protection.outlook.com
 [2a01:111:f403:260c::620])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8312d426-dd63-11ef-a0e6-8be0dac302b0;
 Tue, 28 Jan 2025 11:34:55 +0100 (CET)
Received: from PAZP264CA0086.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:1fa::16)
 by AS2PR08MB9716.eurprd08.prod.outlook.com (2603:10a6:20b:604::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.22; Tue, 28 Jan
 2025 10:34:51 +0000
Received: from AMS1EPF00000047.eurprd04.prod.outlook.com
 (2603:10a6:102:1fa:cafe::dd) by PAZP264CA0086.outlook.office365.com
 (2603:10a6:102:1fa::16) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8377.23 via Frontend Transport; Tue,
 28 Jan 2025 10:34:51 +0000
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 AMS1EPF00000047.mail.protection.outlook.com (10.167.16.135) with
 Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8398.14
 via Frontend Transport; Tue, 28 Jan 2025 10:34:51 +0000
Received: ("Tessian outbound 671aa0ad34c4:v560");
 Tue, 28 Jan 2025 10:34:50 +0000
Received: from La8f9e7951bec.2
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 B3F27725-9BD2-4229-8C66-1C7036DF596C.1; 
 Tue, 28 Jan 2025 10:34:40 +0000
Received: from EUR05-DB8-obe.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id
 La8f9e7951bec.2 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Tue, 28 Jan 2025 10:34:40 +0000
Received: from DBAPR08MB5798.eurprd08.prod.outlook.com (2603:10a6:10:1a6::21)
 by PA6PR08MB10594.eurprd08.prod.outlook.com (2603:10a6:102:3cd::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.22; Tue, 28 Jan
 2025 10:34:38 +0000
Received: from DBAPR08MB5798.eurprd08.prod.outlook.com
 ([fe80::4a66:d3e2:570:9632]) by DBAPR08MB5798.eurprd08.prod.outlook.com
 ([fe80::4a66:d3e2:570:9632%4]) with mapi id 15.20.8377.021; Tue, 28 Jan 2025
 10:34:38 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8312d426-dd63-11ef-a0e6-8be0dac302b0
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=k3Tjq6GOafm9Wzuav+BmSjzt70+/o77Qii4CsfNLstrXD00LW+43CCRct8zLAynBnjrKpHY1XZtlR6dIl6h6BURG1Uis9qMgver7iv/qo6DuDdyNNrFxumOpVLNQ4tlJd4rWvmZ0GFAVpJQUIEUPiO2XZieKXLp34olSSUQUlKlMmWlr0lHldBoUcAAWANJjban4A5sniQYbNYoV3+xoG0Lw0E8aaKalTuk6blHHR7S1B97YR9cUiIG4P3egXVktBMgpltDQ806eGaK4/TJTropwQds5BxF9rrxoUsV8HtMktb/3K+OX1dwS5SR7vPdMQYPw82AEegAC9rK/I6ambg==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=1xiinY+D8vfdhgdrxMh3iziYTey/5cXJj2erHf0h0zY=;
 b=SnjW1e5tnpe8FAK8rZT40NXPghMxf8ti9vz44KIh+OPirTYlPH8ALUoCaVj11wQs9NDC0rD/mQLwpsPmRrLkAYjlPAizwIk0uM3rFVCQOipQgS+I19NTtWXahja7yurveg3SMc6gNdWxomIPNnFSW8v0czzh416mla0fmScr0OO9BcokPJmV841CmsFmym6nHqoQH9fBQGhQ2cT/g2yNH6mqo5FXl1GCEfD7YMb2VdQFJVqsgFo/jGq0/+yPAKcPRd2pxPzMx8wAfiC90Qvj+m8e2kdqtpo2i8LHeE37E16KCb5Z88cMZLadGpQvlZKM9dgGFecHED/dEQZJAOeEQw==
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=arm.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=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=1xiinY+D8vfdhgdrxMh3iziYTey/5cXJj2erHf0h0zY=;
 b=pWtkFwE+1Y3TwORtf5oZyW9fmAm/6OJ4Px3qgQ6IOoXYSJxy48qsN5gJwi84NiNcDjUIYa0nDvJjFoVapysA69m9OOL2cdyxzfK4Ez748MydRb9XW2WP5+DT0aIuecftXR9E1snxT/qTi3zpK5SnkApkg/XiX76mcqVqiukBrGk=
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=arm.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: 4e366d069cb3207e
X-TessianGatewayMetadata: i7HFIcXRbkAMa8Pt+Hg+tASLMcYgQBP2Dc1w/DagHgTzgJMW2AdrJx27uhfQVpwSb+uHrMF/ScOsahSpqsTgEc92BjfzMjaAyDtGor1SU+ZmTCchjczHMpRAQO4R9pXoboZB29L+Ld1JYoBj+ImlHZy3+6+absZB1mgWeOtHjko=
X-CR-MTA-TID: 64aa7808
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=T0v9qF3+yS0D1bhhuNcBxf/qo6J+RXeEJruxMMPUBagNn3K62XWynD4aeMMd5ohAxSGtZUY2qDLCuCHy22EQ6jOCJ8MkGaLKRvWkBX/g4wwiFE9BZw/L0160LNiuBZJg3zPgBULRxjNp0pXkUFPucevDyaaha2FmLM7XY++eZcnlfAG91nUIz19liZTv37SdfOx/Zlip1kKGQ5MTgq071KiiZcHMFyArKhl5YLkUrZ/5+k8eiCCN7vpyaJ9y7Jb9S8WDRjJKALmFqfwXPaq3gt96moA76scWvXJ8lSa7H9P4uE7YtpTfaT3cAh4s1ENS+nF9vSyo5/p0u3bO2MmD8Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=1xiinY+D8vfdhgdrxMh3iziYTey/5cXJj2erHf0h0zY=;
 b=MuEMrTrGH8ZWpUcampHvdM/FgUvYlyig4NJGgZnfgClOa9ly0MUJ5wl35fnxLP6aGQcZE1OfPYhhUaPn5wqwDiE8BGCYzlAyupMeh1ftufToiTHG+Clw2fYl59y6u4cMklSb6FS6xeuohlMWWDoTujbPLeFikLo/V6LIUy9UiZA8CL/lFwdz0dxhu/scqZX1VQ9t6sSvrytWmRIJ9MvyCP3YpNMjkFwuviWRVW6b27cnfrYHyc2NqlB8VDOiIlUGC0KAFkkiZ3uGgIGvj99hGVQqz+NrZ/zNc9TyRiNR7QtP8fMYPoBaIw0gtwHXBW4uzc6XvVYH9YZhJ0xgX2DcPw==
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=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=1xiinY+D8vfdhgdrxMh3iziYTey/5cXJj2erHf0h0zY=;
 b=pWtkFwE+1Y3TwORtf5oZyW9fmAm/6OJ4Px3qgQ6IOoXYSJxy48qsN5gJwi84NiNcDjUIYa0nDvJjFoVapysA69m9OOL2cdyxzfK4Ez748MydRb9XW2WP5+DT0aIuecftXR9E1snxT/qTi3zpK5SnkApkg/XiX76mcqVqiukBrGk=
From: Luca Fancellu <Luca.Fancellu@arm.com>
To: Julien Grall <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>
CC: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Stefano
 Stabellini <sstabellini@kernel.org>, Bertrand Marquis
	<Bertrand.Marquis@arm.com>, "oleksii.kurochko@gmail.com"
	<oleksii.kurochko@gmail.com>
Subject: Re: [for-4.20][PATCH v2 1/2] device-tree: bootfdt: Fix build issue
 when CONFIG_PHYS_ADDR_T_32=y
Thread-Topic: [for-4.20][PATCH v2 1/2] device-tree: bootfdt: Fix build issue
 when CONFIG_PHYS_ADDR_T_32=y
Thread-Index: AQHbcWiul9cH2IOw7U+mIQTrfYS+Q7Mr/YSA
Date: Tue, 28 Jan 2025 10:34:38 +0000
Message-ID: <4A4FAE76-59FF-4DBD-92A7-5158B0404C7F@arm.com>
References: <20250128094002.145755-1-michal.orzel@amd.com>
 <20250128094002.145755-2-michal.orzel@amd.com>
In-Reply-To: <20250128094002.145755-2-michal.orzel@amd.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.300.87.4.3)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DBAPR08MB5798:EE_|PA6PR08MB10594:EE_|AMS1EPF00000047:EE_|AS2PR08MB9716:EE_
X-MS-Office365-Filtering-Correlation-Id: d82fd8b0-7c38-411c-ae9a-08dd3f876589
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|1800799024|376014|366016|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?utf-8?B?THRVWGc2TG9qWjRiRzNNRHJleElkakd5MXB2VTg4L2RwMFRjOFRVbzhCaUZW?=
 =?utf-8?B?ME1nWjlqQ1FpVVpvZUM2THNSSFIvTUp0M0cyQTZXYzROTWxlTS9DZlZHNTA0?=
 =?utf-8?B?blZqWUNTbkZOR09lR201VjdJTEVsWVgzTkIyd2hDS2hSNUozMy9Vak1xYmNL?=
 =?utf-8?B?b0J1TlFJTTlSdzZYU2VxN0x2VGNPaVQwbUc5a21DTERNcVdFNXUycmoyV0V2?=
 =?utf-8?B?dTRxcVJMRWJlUzkxSzA1Sm9lYU9sQmo2WVVmZXBVM2hiWDZva2REZVV0NHdt?=
 =?utf-8?B?bzJhT2JrcGoxejQ4TmJ0OW84Sk83VUs4TE1jUEsrbHdURlJTVVRYR2J4djNF?=
 =?utf-8?B?RDVPVkZUb05rSnVQeTJNWi9Hb2d5OXIzcUprbCsrZWJYaHczZC9KNWpTYkxI?=
 =?utf-8?B?SVE4cEpLRDhQQW9XVzdSUk5uWHVVWUpVT0RaWlZZZXpaSDQzRWRJTm1YQnpB?=
 =?utf-8?B?Tm5teXp2UW5hdFIvNkY2UjJQdlVlT3dkdFZnSngvZnpWNlJsWlU0dTdoaE1P?=
 =?utf-8?B?UTJJaENmY2hlWVNMcFdTcnA2aVFoSnRsNnU3b3FWYktuV0l4NTlXU3h2NmRU?=
 =?utf-8?B?bHBzUWpNMWFCWkZISG5XdzhBVXdDN3lEbUdQaEtJOWlmcDVIVEZxQUIxUDY3?=
 =?utf-8?B?VlB1V1pmUFpORmQ0em1oRkVya2Z6L0dCNzNhR2RlalVjL0xUVVhQcFU4dXVT?=
 =?utf-8?B?ZU0wSytEYnRWSGIyZE8zYVBSNVhZMWZBTHJZeFN6dVg4bXl5UFY2TUwyWHd1?=
 =?utf-8?B?TWliSkt6MmlxYjIvUS9ZVnU4bUZ2T1VmV05OSXpmYzBZdWVjM2ZZVmhvSmZQ?=
 =?utf-8?B?Tk51c2F3eWJZQkdoa3UvWU4yRHJ5S3RIV1FrcEFTRGdPUjlacHpUTkdrdjcr?=
 =?utf-8?B?MDl0RU1TOEU3UUxhNmVWZDRTRFl4N1pRTXR2azY3Vm5XYXNBRDJldGtpRWpY?=
 =?utf-8?B?cmxLbXd6b3VnZlROLzQreFVtMFJPeElBUkF2aVRBZzlTZ3ZUZTkzb0c4VVU2?=
 =?utf-8?B?TitjN3JaQ284bzFwZU5iblI3cUMzWWdsZFk0TEFreXIvd0s4V0JGd244ZkN5?=
 =?utf-8?B?M3FQYitHdGROejV6eFlIWHJTZlNBWjlkNTc1TXV1blJ0ZFZSdG5qMXhRSFd1?=
 =?utf-8?B?RExEbFdic2ZUakVtcFdSTVVTRkRMOENTQkx1WUY2ZG1aanQ1aTdvc3pVeVNV?=
 =?utf-8?B?SWh1cnlFTXY3NG4rR0NRZ0tYKytrTUJnWEgvWlk5MnhMRk5nWFBlQ2dxcUdB?=
 =?utf-8?B?OGFQekZiZEJiQmx5a3pUVnMvRWNQaENndU10Zld4YlBOU2ZpbTIyeGFnQUts?=
 =?utf-8?B?T0dRV0NNUUhaNGRGbHJyYUc0SFNXR0JhZmlNWmlWZDN2MVptQkZ0Q1laUUxj?=
 =?utf-8?B?aExpb05pZHY5SFArS2dlMWh1TXkwOTljaVNYbm5RUFJGVnp2WkM2UHZqUEhk?=
 =?utf-8?B?dVBtaFQxMWh1dEEySE9yQTFBMmNSOXlDSXVpREUrNUJtdS9hVXB3M2ExSWN3?=
 =?utf-8?B?M1FFZk1rYy9UMDBoNGZVdnJsUU9iQnlRZmNONW1iT2hTMXRncklDU2lJOFB5?=
 =?utf-8?B?MEgvWlhPSlVPZEEySVBlRU9ZLzBCR0FSaDE3c0trR1ZRcFhmWTRCVWR1bHRo?=
 =?utf-8?B?ekUxbThtY1gxRXMrcitaRndDMTQyMGRwY1lmMThJSTNOMGZobVN1VURPU1JF?=
 =?utf-8?B?cDMwM1NPbERNNlJ3TFpleFVIbkZvNWErK2tHTzVNTWJ6REFnWkduWFdJZHBE?=
 =?utf-8?B?Qm9KRDJSWVpzdmxVU2I0cG5YcFloMTM0U3ZZQjdCeTZzeGl1bWdJOHNtdDRH?=
 =?utf-8?B?c2Q3NExLczN5d1V2MDlmOW51SFZuWDVlbjEvSS9tYjNpZGIyMG4vTG1qcWRR?=
 =?utf-8?B?Z1ZPY0IrcVR2NmlnNHlPVW45MUw0R1lzdVJWMTFlNEpNcGt0cDBZQUpEbTAv?=
 =?utf-8?Q?PlTzUH4pR29Ic3yzFHgkV58a8etAb1FU?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DBAPR08MB5798.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="utf-8"
Content-ID: <211A94DB77EA8947935F867A28B4A7BF@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA6PR08MB10594
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-SkipListedInternetSender:
 ip=[2603:10a6:10:1a6::21];domain=DBAPR08MB5798.eurprd08.prod.outlook.com
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AMS1EPF00000047.eurprd04.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	ccdb1552-25c3-4b22-07c0-08dd3f875e09
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|35042699022|14060799003|1800799024|82310400026|36860700013|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?QWxWU05ZSzQ4WStzdW9kb2FQbndVZEpYY3pjZXJTV0JhNVhUSkZzaDNGNVJl?=
 =?utf-8?B?QUtOdkwrVkZyMGttSVM0ZmtwVFJUbSswZHI5SHRnaStrcTd6RlpCekJKbVQ1?=
 =?utf-8?B?aWdVVW1Gdkk1RDY2eGs5Uld1OGdhcEVRMlcyQmVqRTNqY2dHL2JmUnVxKzhJ?=
 =?utf-8?B?ODUxZ3dFTU5tVTBBa1B4VE1ITDNDVGlKRkVyUVhPUlEyUWFMeUtTRjd0MVQr?=
 =?utf-8?B?Z2tkOUNBMWdhL0hpSXdGTUpuRisvc0ltT0JDMWY1UjJIWXAvWGRRMUpmWjhY?=
 =?utf-8?B?RHAreGlxbFpjSkRBY085dFYzd2NsQTUzV1FOWG9EZkJLQzh3YlArUnRwYXYw?=
 =?utf-8?B?czhKWjlWTVhKQlh0bmlUdWRJaFE5ajZCODd4bzZHK2RQT09tY2svVE1hZHpR?=
 =?utf-8?B?WFBYdnZYaVZaZ0g2TGwybWhtTVpRYWtSV1lFR2h5TU5aWFMwSVFLMW5BUzdP?=
 =?utf-8?B?ZmFNVWZEcWVCWnJUUE01aTE4SFdwMGdmQjVmTlp3UlFlN0pscExCRWl2NTBQ?=
 =?utf-8?B?bGg0NDZ1VHB0SlRQR2lCY2gzOXBOejFmUDZ3QndqZDg2U0ZGU1FFZjNQcVhW?=
 =?utf-8?B?TlhmT2dodVl5YUIrSnZVLzZnV09sTUt2NzZKOG05a3RpdjZYMVI2c3Bpc2Fs?=
 =?utf-8?B?QkFIWWh6U1NEL3R3TldYOEpySnpoWDRUQkJVOVdjaFIzMUlCdXE2aG9MMjFi?=
 =?utf-8?B?MmtsM3o0Z0pocGsraWVQb3ZZM1RvK255SXozekZmOHc4YVBWaFFqVTE2V3NN?=
 =?utf-8?B?SENRUmpyVTNGNjlYbzhiNDg5ZzhFR2l5TUZBY2JIbCtQTXFUUzd0NGkzVnVn?=
 =?utf-8?B?aXhuZ3RPY0I2L1pMK2VYZ1gySHRmVnJDK2Fycy84NEY2azZCWkNoakhsYW5n?=
 =?utf-8?B?Q21tcWZURnBpV2lNc3dJdFJJTStHTUh5SElINlBlcnVoYlpYZWJXVk5iWjJ1?=
 =?utf-8?B?Tm5rdmdSV3RxNHoyWTEzdUpNOFNnUUREVTNBWkdCMU13OGs3eS9kRWpnbCt0?=
 =?utf-8?B?USs4M0xsVzJRRWY1aC9IYW0yR2JNSkZWUXdJQUtLck5ZNU1haTVHbEhlRHR5?=
 =?utf-8?B?TTZsWmx1VGdaaFQrMEIzVUhHZm9aWDRVL3c0TXkraU1pSEFpRkpQTzVqWmFF?=
 =?utf-8?B?WktGV09xZDVRcmhFODd1ZzNNUndlakF2aVJDUXZYSVJxQXp1NVZ0cnFyTGFU?=
 =?utf-8?B?UHVGZkpCTTNuK3U4d0FqMUlIMklWSHF5SGIzM2lwaWFrbmxQQUZzckU2VlZm?=
 =?utf-8?B?YnNWdGtRSlhDRkI2UFdKQ2lpREl1OUxCUEZQZWZsbWZGNnZMb0pvV2RMQVhj?=
 =?utf-8?B?alVaanNxeDlNVU90S0RBUUd3ZTNFTmJoL3o1aE1YTFljUmYwbklzR1NQc3c1?=
 =?utf-8?B?NDRlbzBzV0M1QkgyRXRvWDY5OHkwM0tzV2s2N0w4V1E0YmFDSU04Z3BjN0tL?=
 =?utf-8?B?NjNXTUVibXIyZ25nS25mcWFMZ2xiR2o1YzJOKy9UTW1NUkxUdDNIaG1rR1k0?=
 =?utf-8?B?UGdhdjNta1JzWndyeEJwNno2aHFOanJrZ3p6VTQ5ZFN1bGtwakdPUWZreGFX?=
 =?utf-8?B?eWpqbUNrMnVUQkF2U1RSVmpKeU5aaWErb3I1OEovUEI5dmRRT3NtSmpJTWl1?=
 =?utf-8?B?TnJHTERZVTNwbTJJanZFYWJTcWRzOWJnM2lIdkNYNGFDaGJkdDRzTURyVUQv?=
 =?utf-8?B?U3h3L3RJejBLQzVCamRWWXFwVDlDanFRY09MMWJTcHAwYjNVa3FTYUovazA1?=
 =?utf-8?B?TWdocHhnbmRRaHA5aHRUUEFjTE5Va3Z2bk13aUE0MVpDQjBoeUx3eForbTdp?=
 =?utf-8?B?YmNvcDlGdVZIbytEZmlVK1FxVmlHWFRMeGkweldrTUhYTWVNYzlyMEFnRnZR?=
 =?utf-8?B?WExXMFdCbllLNkNhdG9NZ2tRTGJ3THBlSStTU1F4TEFYRlo2cUhxYkpuTkZx?=
 =?utf-8?B?bWRkKzY4VFdKeVIzNXhBTEQvOWcveWk4dm5XK294Z0l1bzNiWm9DZlJNN0p4?=
 =?utf-8?Q?g0WqN2v3rCCk7XIcieKi7sFtKZB1Wk=3D?=
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:64aa7808-outbound-1.mta.getcheckrecipient.com;CAT:NONE;SFS:(13230040)(35042699022)(14060799003)(1800799024)(82310400026)(36860700013)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2025 10:34:51.2510
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d82fd8b0-7c38-411c-ae9a-08dd3f876589
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:
	AMS1EPF00000047.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR08MB9716

SGkgTWljaGFsLCBKdWxpZW4sDQoNCj4gT24gMjggSmFuIDIwMjUsIGF0IDA5OjQwLCBNaWNoYWwg
T3J6ZWwgPG1pY2hhbC5vcnplbEBhbWQuY29tPiB3cm90ZToNCj4gDQo+IE9uIEFybTMyLCB3aGVu
IENPTkZJR19QSFlTX0FERFJfVF8zMiBpcyBzZXQsIGEgYnVpbGQgZmFpbHVyZSBpcyBvYnNlcnZl
ZDoNCj4gY29tbW9uL2RldmljZS10cmVlL2Jvb3RmZHQuYzogSW4gZnVuY3Rpb24gJ2J1aWxkX2Fz
c2VydGlvbnMnOg0KPiAuL2luY2x1ZGUveGVuL21hY3Jvcy5oOjQ3OjMxOiBlcnJvcjogc3RhdGlj
IGFzc2VydGlvbiBmYWlsZWQ6ICIhKGFsaWdub2Yoc3RydWN0IG1lbWJhbmtzKSAhPSA4KSINCj4g
ICA0NyB8ICNkZWZpbmUgQlVJTERfQlVHX09OKGNvbmQpICh7IF9TdGF0aWNfYXNzZXJ0KCEoY29u
ZCksICIhKCIgI2NvbmQgIikiKTsgfSkNCj4gICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIF5+fn5+fn5+fn5+fn5+DQo+IGNvbW1vbi9kZXZpY2UtdHJlZS9ib290ZmR0LmM6MzE6
NTogbm90ZTogaW4gZXhwYW5zaW9uIG9mIG1hY3JvICdCVUlMRF9CVUdfT04nDQo+ICAgMzEgfCAg
ICAgQlVJTERfQlVHX09OKGFsaWdub2Yoc3RydWN0IG1lbWJhbmtzKSAhPSA4KTsNCj4gDQo+IFdo
ZW4gQ09ORklHX1BIWVNfQUREUl9UXzMyIGlzIHNldCwgcGFkZHJfdCBpcyBkZWZpbmVkIGFzIHVu
c2lnbmVkIGxvbmcsDQo+IHRoZXJlZm9yZSB0aGUgc3RydWN0IG1lbWJhbmtzIGFsaWdubWVudCBp
cyA0QiBhbmQgbm90IDhCLiBUaGUgY2hlY2sgaXMNCj4gdGhlcmUgdG8gZW5zdXJlIHRoZSBzdHJ1
Y3QgbWVtYmFua3MgYW5kIHN0cnVjdCBtZW1iYW5rLCB3aGljaCBpcyBhDQo+IG1lbWJlciBvZiB0
aGUgZm9ybWVyLCBhcmUgZXF1YWxseSBhbGlnbmVkLiBUaGVyZWZvcmUgbW9kaWZ5IHRoZSBjaGVj
ayB0bw0KPiBjb21wYXJlIGFsaWdubWVudHMgb2J0YWluZWQgdmlhIGFsaWdub2Ygbm90IHRvIHJl
bHkgb24gaGFyZGNvZGVkDQo+IHZhbHVlcy4NCj4gDQo+IEZpeGVzOiAyMjA5YzFlMzViNDcgKCJ4
ZW4vYXJtOiBJbnRyb2R1Y2UgYSBnZW5lcmljIHdheSB0byBhY2Nlc3MgbWVtb3J5IGJhbmsgc3Ry
dWN0dXJlcyIpDQo+IFNpZ25lZC1vZmYtYnk6IE1pY2hhbCBPcnplbCA8bWljaGFsLm9yemVsQGFt
ZC5jb20+DQo+IFJlbGVhc2UtQWNrZWQtYnk6IE9sZWtzaWkgS3Vyb2Noa28gPG9sZWtzaWkua3Vy
b2Noa29AZ21haWwuY29tPg0KPiAtLS0NCj4gQ2hhbmdlcyBpbiB2MjoNCj4gLSBtb2RpZnkgdGhl
IGNoZWNrIHRvIHRlc3QgYWdhaW5zdCBhbGlnbm1lbnQgb2Ygc3RydWN0IG1lbWJhbmsNCj4gLS0t
DQo+IHhlbi9jb21tb24vZGV2aWNlLXRyZWUvYm9vdGZkdC5jIHwgNCArKy0tDQo+IDEgZmlsZSBj
aGFuZ2VkLCAyIGluc2VydGlvbnMoKyksIDIgZGVsZXRpb25zKC0pDQo+IA0KPiBkaWZmIC0tZ2l0
IGEveGVuL2NvbW1vbi9kZXZpY2UtdHJlZS9ib290ZmR0LmMgYi94ZW4vY29tbW9uL2RldmljZS10
cmVlL2Jvb3RmZHQuYw0KPiBpbmRleCA0NzM4NmQ0ZmZmZWEuLjUyOWM5MWU2MDNhYiAxMDA2NDQN
Cj4gLS0tIGEveGVuL2NvbW1vbi9kZXZpY2UtdHJlZS9ib290ZmR0LmMNCj4gKysrIGIveGVuL2Nv
bW1vbi9kZXZpY2UtdHJlZS9ib290ZmR0LmMNCj4gQEAgLTI3LDggKzI3LDggQEAgc3RhdGljIHZv
aWQgX19pbml0IF9fbWF5YmVfdW51c2VkIGJ1aWxkX2Fzc2VydGlvbnModm9pZCkNCj4gICAgICAq
Lw0KPiAgICAgQlVJTERfQlVHX09OKChvZmZzZXRvZihzdHJ1Y3QgbWVtYmFua3MsIGJhbmspICE9
DQo+ICAgICAgICAgICAgICAgICAgb2Zmc2V0b2Yoc3RydWN0IG1lbWluZm8sIGJhbmspKSk7DQo+
IC0gICAgLyogRW5zdXJlICJzdHJ1Y3QgbWVtYmFua3MiIGlzIDgtYnl0ZSBhbGlnbmVkICovDQo+
IC0gICAgQlVJTERfQlVHX09OKGFsaWdub2Yoc3RydWN0IG1lbWJhbmtzKSAhPSA4KTsNCj4gKyAg
ICAvKiBFbnN1cmUgInN0cnVjdCBtZW1iYW5rcyIgYW5kICJzdHJ1Y3QgbWVtYmFuayIgYXJlIGVx
dWFsbHkgYWxpZ25lZCAqLw0KPiArICAgIEJVSUxEX0JVR19PTihhbGlnbm9mKHN0cnVjdCBtZW1i
YW5rcykgIT0gYWxpZ25vZihzdHJ1Y3QgbWVtYmFuaykpOw0KDQpBcG9sb2dpZXMgZm9yIG5vdCBj
YXRjaGluZyB0aGUgaXNzdWUgZm9yIHlvdXIgdjEsIHByb2JhYmx5IEkgZGlkbid0IHVuZGVyc3Rh
bmQgdmVyeSB3ZWxsIHRoZSB0ZXN0IGl0c2VsZiwNCndoeSBhcmUgd2UgY2hlY2tpbmcgdGhhdCB0
aGUgc3RydWN0dXJlIGhhdmUgdGhlIHNhbWUgYWxpZ25tZW50PyANCkkgc2VlIHdlIGNoZWNrIHRo
ZSBvZmZzZXQgb2YgYChzdHJ1Y3QgbWVtYmFua3MpLmJhbmtgIGFnYWluc3QgYChzdHJ1Y3QgbWVt
aW5mb3xzdHJ1Y3Qgc2hhcmVkX21lbWluZm8pLmJhbmtgLA0KaXNuJ3QgdGhhdCBlbm91Z2g/DQpG
b3Igc3VyZSBJ4oCZbSBtaXNzaW5nIHNvbWV0aGluZy4uLg0KDQpBbnl3YXkgSSB0ZXN0ZWQgdGhp
czoNCg0KVGVzdGVkLWJ5OiBMdWNhIEZhbmNlbGx1IDxsdWNhLmZhbmNlbGx1QGFybS5jb20+DQoN
Cj4gfQ0KPiANCj4gc3RhdGljIGJvb2wgX19pbml0IGRldmljZV90cmVlX25vZGVfaXNfYXZhaWxh
YmxlKGNvbnN0IHZvaWQgKmZkdCwgaW50IG5vZGUpDQo+IC0tIA0KPiAyLjI1LjENCj4gDQo+IA0K
DQo=


From xen-devel-bounces@lists.xenproject.org Tue Jan 28 10:41:52 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 10:41:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878348.1288510 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcj2L-0001Sy-Jx; Tue, 28 Jan 2025 10:41:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878348.1288510; Tue, 28 Jan 2025 10:41:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcj2L-0001Sr-HB; Tue, 28 Jan 2025 10:41:41 +0000
Received: by outflank-mailman (input) for mailman id 878348;
 Tue, 28 Jan 2025 10:41:40 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=5iVi=UU=redhat.com=kraxel@srs-se1.protection.inumbo.net>)
 id 1tcj2K-0001Sg-LU
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 10:41:40 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 71af02cc-dd64-11ef-99a4-01e77a169b0f;
 Tue, 28 Jan 2025 11:41:35 +0100 (CET)
Received: from mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-180-kr_aKd0hPQ-uwOo_sUl5pw-1; Tue,
 28 Jan 2025 05:41:30 -0500
Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id A601C19560A1; Tue, 28 Jan 2025 10:41:26 +0000 (UTC)
Received: from sirius.home.kraxel.org (unknown [10.39.192.226])
 by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 2C17C180035E; Tue, 28 Jan 2025 10:41:22 +0000 (UTC)
Received: by sirius.home.kraxel.org (Postfix, from userid 1000)
 id CEE951800097; Tue, 28 Jan 2025 11:41:19 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 71af02cc-dd64-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1738060894;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=Q5BmEW4DnGq+UdM0tnVbqKqLrMEw80/0eIPX20ASm4I=;
	b=gzn6kWHsTWUMB7E2fJqPWnbAkBwuoAo2ovjzCCx6RKtwM8k1icD0XgSjpdIRivmHkZpGxR
	OKS9hihhdEMTxPtnmMlFYh31+3W3nSCT3rfX1fMSRWd6+ShRxiGzPovqo61TdBuXnykxJS
	7l053QVvdreIpMXJgT+TNR1B6S9mO80=
X-MC-Unique: kr_aKd0hPQ-uwOo_sUl5pw-1
X-Mimecast-MFC-AGG-ID: kr_aKd0hPQ-uwOo_sUl5pw
Date: Tue, 28 Jan 2025 11:41:19 +0100
From: Gerd Hoffmann <kraxel@redhat.com>
To: Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= <philmd@linaro.org>
Cc: qemu-devel@nongnu.org, Yi Liu <yi.l.liu@intel.com>, 
	Markus Armbruster <armbru@redhat.com>, Eduardo Habkost <eduardo@habkost.net>, 
	Anthony PERARD <anthony@xenproject.org>, Gustavo Romero <gustavo.romero@linaro.org>, 
	Jason Wang <jasowang@redhat.com>, qemu-ppc@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>, 
	Paolo Bonzini <pbonzini@redhat.com>, Alexander Graf <graf@amazon.com>, 
	Richard Henderson <richard.henderson@linaro.org>, Stefan Berger <stefanb@linux.vnet.ibm.com>, 
	Bernhard Beschow <shentey@gmail.com>, Stefano Stabellini <sstabellini@kernel.org>, 
	Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= <berrange@redhat.com>, "Edgar E. Iglesias" <edgar.iglesias@gmail.com>, 
	xen-devel@lists.xenproject.org, Marcel Apfelbaum <marcel.apfelbaum@gmail.com>, 
	Alex Williamson <alex.williamson@redhat.com>, Paul Durrant <paul@xen.org>, 
	=?utf-8?Q?Cl=C3=A9ment?= Mathieu--Drif <clement.mathieu--drif@eviden.com>, =?utf-8?Q?C=C3=A9dric?= Le Goater <clg@redhat.com>
Subject: Re: [PATCH 0/9] hw/sysbus/platform-bus: Introduce
 TYPE_DYNAMIC_SYS_BUS_DEVICE
Message-ID: <wkb53fhvfchqa4uvmifgitvcr7t7rfpc3hcohdhzczkzvktetx@yjveswjel3s4>
References: <20250125181343.59151-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250125181343.59151-1-philmd@linaro.org>
X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93

On Sat, Jan 25, 2025 at 07:13:34PM +0100, Philippe Mathieu-Daud� wrote:
> Some SysBus devices can optionally be dynamically plugged onto
> the sysbus-platform-bus (then virtual guests are aware of
> mmio mapping and IRQs via device tree / ACPI rules).

Do we have some sane way to have user-pluggable sysbus devices on arm?

I've played around with that a bit, with the uefi variable service I'm
working on.  Specifically I'd prefer to *not* have a patch wiring things
up in machine type code like this ...

https://lore.kernel.org/qemu-devel/20250107153353.1144978-20-kraxel@redhat.com/

... and just use 'qemu -device uefi-vars-sysbus' instead.

Something like AcpiDevAmlIfClass but for device tree seems to not exist
though.  Also apparently AcpiDevAmlIfClass is not used.

take care,
  Gerd



From xen-devel-bounces@lists.xenproject.org Tue Jan 28 10:44:12 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 10:44:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878354.1288520 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcj4l-00021f-02; Tue, 28 Jan 2025 10:44:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878354.1288520; Tue, 28 Jan 2025 10:44:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcj4k-00021Y-Tl; Tue, 28 Jan 2025 10:44:10 +0000
Received: by outflank-mailman (input) for mailman id 878354;
 Tue, 28 Jan 2025 10:44:10 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=jygh=UU=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcj4k-00021S-5B
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 10:44:10 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id cd25ff65-dd64-11ef-99a4-01e77a169b0f;
 Tue, 28 Jan 2025 11:44:08 +0100 (CET)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-5d932eac638so10591660a12.1
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 02:44: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
 4fb4d7f45d1cf-5dc186d8c3esm6987096a12.80.2025.01.28.02.44.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 28 Jan 2025 02:44:07 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: cd25ff65-dd64-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738061047; x=1738665847; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=gOJU4QZyYul2TIIrDQ4BSIIQc90qZkQ8as5C30Ul9IQ=;
        b=K3fGvncpRf2MJES2O1ALCcos7hJjJjpkMZEzwoTW1Sp1nriHM/9OKn+cQ80IUftZv/
         6SfMZGPOozAAOR4Vmwg8TwgF4K1VLj7YaD4ZsdgVARt9D2tXfyQpVTrX8aand57ofYsc
         ymSXjypObM1HuwjTzsxNtbl0dFZHF3f1vjo5GijwRDfFq6IKOFePV/hC8GKyq6QXbxKz
         Gh/Fm3R9S/SCNHjrzpDpgG6aMF3JQhBkBHnVYcnmO8gt+Km4AgBVR2ObT6r7nkNc2XZc
         aydfF8icGeyUm1rGuoEdKMVEFjWgjzNEEvPJE2Ys7wdj8Yo7TtpoPp7yZ8jYHvOt3pOS
         oFqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738061047; x=1738665847;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=gOJU4QZyYul2TIIrDQ4BSIIQc90qZkQ8as5C30Ul9IQ=;
        b=CWlQyJ0us/CmfbiaZ3tVwzsvAhLPnUx4qCB2XhYPyCNb2XuJ9PknscgXa4dzyqg+4G
         vRuni1rJZJBKHOxJ9xW1llmrFknJF/qK3PXrpvWwa9GF0d1wHhYYZ4G+OM7wPjjBH/Nd
         OQl5thgGBIFvZLniMMZ8uPLbA+4pK15kkpY5rB3RjDiiQef7l2geeWUtEZzlx1okm3Ta
         kO2ihz1w5vG7CgvClHekWE03F/3tZHp5tHnXDhcUxLAuXVOnNDweMUAHgl1BJFnLPIei
         kGsnsd4BFD2AaXmQAHbJn4bJI0OdUO3FefkHaz1HbfJAicoEjJzQfpq0mCPQZIE3KYD8
         v+Fw==
X-Forwarded-Encrypted: i=1; AJvYcCXodRbWHdwI9JGVHM6+okwjxh1k5XVGJnzDu1quW0d8cfXxwvOuMPMlOt3Y557vVXkInuv0mdahrW8=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyzhu92WaFGx9utBfJxSYd17rlwFr1LA8a8w0jL27PhHO5MDduz
	lW5ekyqwCXqoi5oWknQGTSfznncy7CrTzYtNbyuL+VwFAGMohEfWRdZhTh6D3Q==
X-Gm-Gg: ASbGnctYNofvGt7NM75wveGtv8Kg0A8Qb0AQWbttATftxrZ6RjbF76w51uHnWI7TnEI
	v6mQ9iGLUajaKzGXt4Idm2mgybGXyISNc/qm5eXVmsy+ttbZDQ2XgGeGaMWVgTbogNAnTIwacED
	09WG0x72IMDjzenigKLYJy4WhKqQ2j+V3Azhlfj0yUVtcBHbqDUHPfcL1DXnqJaABgRXPebNBVa
	CNjdXIkg9CWSVzwTQyEiHBNecG3xK5nFDKbKdMCuZ8FZ3rpnmwkLR8iV8PXDQJ5IXO63FEdOmNu
	zWgxT3Rk8KCYuuyvx020PfxPcUx7grPHfn9DpW/NCk8ugktnl4XI47ihvxkPOxMGiaLlOaJv5rV
	6
X-Google-Smtp-Source: AGHT+IEx22njiy+fQ/KVPkX1Or5eo6a4frig/PdggWRWRQLGfNmgjVUMAHAgR13LEtKV7lbUCzax0Q==
X-Received: by 2002:a05:6402:4416:b0:5d9:a84:d4b6 with SMTP id 4fb4d7f45d1cf-5db7d0e8a21mr42472361a12.0.1738061047658;
        Tue, 28 Jan 2025 02:44:07 -0800 (PST)
Message-ID: <1a98115d-44b3-4440-b1a4-16e33d95c36a@suse.com>
Date: Tue, 28 Jan 2025 11:44:06 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 06/24] xen/domain: introduce hardware emulation flags
To: Jason Andryuk <jason.andryuk@amd.com>, dmukhin@ford.com
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
 <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
 <20250103-vuart-ns8250-v3-v1-6-c5d36b31d66c@ford.com>
 <3ab581fb-4c7b-43ff-8ac4-6bab65758437@amd.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <3ab581fb-4c7b-43ff-8ac4-6bab65758437@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 28.01.2025 00:57, Jason Andryuk wrote:
> On 2025-01-03 20:58, Denis Mukhin via B4 Relay wrote:
>> --- /dev/null
>> +++ b/xen/include/public/virtdev.h
>> @@ -0,0 +1,61 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +#ifndef XEN__PUBLIC_VIRTDEV_H
>> +#define XEN__PUBLIC_VIRTDEV_H
>> +
>> +/*
>> + * Domain hardware emulation flags.
>> + */
>> +enum {
>> +    VIRTDEV_LAPIC      = 1U << 0,
>> +    VIRTDEV_HPET       = 1U << 1,
>> +    VIRTDEV_PM         = 1U << 2,
>> +    VIRTDEV_RTC        = 1U << 3,
>> +    VIRTDEV_IOAPIC     = 1U << 4,
>> +    VIRTDEV_PIC        = 1U << 5,
>> +    VIRTDEV_VGA        = 1U << 6,
>> +    VIRTDEV_IOMMU      = 1U << 7,
>> +    VIRTDEV_PIT        = 1U << 8,
>> +    VIRTDEV_PIRQ       = 1U << 9,
>> +    VIRTDEV_PCI        = 1U << 10,
>> +};
> 
> If you do create this new header, I think you'll want to leave these as 
> just bit numbers and shifts.  IIRC, the headers strive for greatest 
> compatibility and, enums are less rigorously defined.

+1 - any use of enums we have in the public headers was a mistake. (I'm
yet to figure why we need this new header in the first place.)

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 28 10:50:34 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 10:50:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878364.1288531 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcjAr-0003XY-Ka; Tue, 28 Jan 2025 10:50:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878364.1288531; Tue, 28 Jan 2025 10:50:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcjAr-0003XR-HU; Tue, 28 Jan 2025 10:50:29 +0000
Received: by outflank-mailman (input) for mailman id 878364;
 Tue, 28 Jan 2025 10:50:28 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=b94Q=UU=linaro.org=peter.maydell@srs-se1.protection.inumbo.net>)
 id 1tcjAq-0003XL-Ib
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 10:50:28 +0000
Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com
 [2607:f8b0:4864:20::b2f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ae66ee59-dd65-11ef-99a4-01e77a169b0f;
 Tue, 28 Jan 2025 11:50:26 +0100 (CET)
Received: by mail-yb1-xb2f.google.com with SMTP id
 3f1490d57ef6-e3a1cfeb711so7888660276.0
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 02:50:26 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ae66ee59-dd65-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1738061425; x=1738666225; 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=3v34krr+R/W/GJLfn6JaO0A1nQiepmfIj00rt+nc7XI=;
        b=x8KxCcVXNxt9O3a68yzqITKTOLU1sSnBbYWKhFmNVEb00BRQjbXnrDrhaUPdxVLjzw
         qRiUdorKtUc/PBxjsSWommkeT0ftqtKuU3dVGLAJXEiJ82F3aHZUz0rI3NZ8mPG6dwic
         WnJm3iV5GAy2cKAT/nUZNp7WYGjQ0B4RWQkaU2d4eJ53L8CVyzWL4YnJxIX1em+nhUmf
         OPXiWgzNXpWWXIE7zo7P8GK2YQDxSTz15TSQl514e2/b3wLjUi9kqc0zDFJMMF2zIq8H
         Pso44gtxuYli+0+iPQONMIQGNDcLJkWhkHZgTsZ3FfLaZa6mtqazmdryR8I83cVaMB4T
         06Og==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738061425; x=1738666225;
        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=3v34krr+R/W/GJLfn6JaO0A1nQiepmfIj00rt+nc7XI=;
        b=E/72m7OKWHVTz3w0BzC6wym3hSpcRtLcFGdTzKK/yw+cX0Yyro6nwZY746xu1g2IO1
         gLeE5NCiKabAT+iNc+i31h/EJB7K8vYHpFoQgs0w9txKBPZPT4KFPAVwshAdziZTAZQP
         KXBm5f3i6SCUOGcS/JsdKFasZJpjHUGHnpPgeHDuQeivuOeIPvTqR9l1UzMKb0onlvRF
         DQgBb3y8zDRO2+v97/oJBQLdk1Ht54lsR/F/18YH3xHxsV4b5jnHU3ZlK0IUPOOu6yEB
         IVh2PRlCS9FFNBQmkKIqyXVchorwsBFIUrfxMphAa0WM9hFgbm29Fs6CFTdJrYNpBke8
         RMgA==
X-Forwarded-Encrypted: i=1; AJvYcCWXaM33XN1X+BXCcVTTE8QEmD+x50mwvRsry19E5GJS6BopR0rPQccc+m95eqag6JbEJD532uR1hRQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxq7PxCuaM3OOS26kC4fnXnhVEhGu0iucKflV38DPMpbp8a26YJ
	gzf6V+TV6joqwooYyMuiy+0B9cBBz7fXzVON8jHh1giuOnKAPzXNnN2gEV1oHrsyLMi1d1FiUqb
	ULdIz53CCICoTGyluYUA8o+73ET8BNB41TBsk9w==
X-Gm-Gg: ASbGncvsF961sjhX6QVD246HS2KGUQkTe6MSCYDoBLVrNbp0XdFwc9Z45YP7/IeL6QE
	60HDAe86fke+tIJ3RPsSGl0SL+qI4vVoNYG4jX+Zz0qAJf3mNrvSp1dTcVVHcimQjXA6A+sQyVw
	==
X-Google-Smtp-Source: AGHT+IGf0QlTdyAwJ7XFE9WBWDnIZoVSKqzGdakhyKNC/XpP9riGmVHzhlBgZYEGGXx14ZaPvjqXAQBpwZ1OiMaZNEw=
X-Received: by 2002:a05:6902:12c5:b0:e58:173e:abcf with SMTP id
 3f1490d57ef6-e58173ead2fmr17795541276.8.1738061425452; Tue, 28 Jan 2025
 02:50:25 -0800 (PST)
MIME-Version: 1.0
References: <20250125181343.59151-1-philmd@linaro.org> <wkb53fhvfchqa4uvmifgitvcr7t7rfpc3hcohdhzczkzvktetx@yjveswjel3s4>
In-Reply-To: <wkb53fhvfchqa4uvmifgitvcr7t7rfpc3hcohdhzczkzvktetx@yjveswjel3s4>
From: Peter Maydell <peter.maydell@linaro.org>
Date: Tue, 28 Jan 2025 10:50:14 +0000
X-Gm-Features: AWEUYZml6bfUrxGGjA2uylNFRM6bH2fiw1eM--KZHV8IsWc8hLbPBULX6GMnCq4
Message-ID: <CAFEAcA-QOYcnJi=joKHbRmUCXK1UFOgQRgYP-fDq4h_1SkMGyQ@mail.gmail.com>
Subject: Re: [PATCH 0/9] hw/sysbus/platform-bus: Introduce TYPE_DYNAMIC_SYS_BUS_DEVICE
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: =?UTF-8?Q?Philippe_Mathieu=2DDaud=C3=A9?= <philmd@linaro.org>, 
	qemu-devel@nongnu.org, Yi Liu <yi.l.liu@intel.com>, 
	Markus Armbruster <armbru@redhat.com>, Eduardo Habkost <eduardo@habkost.net>, 
	Anthony PERARD <anthony@xenproject.org>, Gustavo Romero <gustavo.romero@linaro.org>, 
	Jason Wang <jasowang@redhat.com>, qemu-ppc@nongnu.org, 
	"Michael S. Tsirkin" <mst@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>, Alexander Graf <graf@amazon.com>, 
	Richard Henderson <richard.henderson@linaro.org>, Stefan Berger <stefanb@linux.vnet.ibm.com>, 
	Bernhard Beschow <shentey@gmail.com>, Stefano Stabellini <sstabellini@kernel.org>, 
	=?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= <berrange@redhat.com>, 
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>, xen-devel@lists.xenproject.org, 
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>, Alex Williamson <alex.williamson@redhat.com>, 
	Paul Durrant <paul@xen.org>, =?UTF-8?Q?Cl=C3=A9ment_Mathieu=2D=2DDrif?= <clement.mathieu--drif@eviden.com>, 
	=?UTF-8?Q?C=C3=A9dric_Le_Goater?= <clg@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 28 Jan 2025 at 10:42, Gerd Hoffmann <kraxel@redhat.com> wrote:
>
> On Sat, Jan 25, 2025 at 07:13:34PM +0100, Philippe Mathieu-Daud=C3=A9 wro=
te:
> > Some SysBus devices can optionally be dynamically plugged onto
> > the sysbus-platform-bus (then virtual guests are aware of
> > mmio mapping and IRQs via device tree / ACPI rules).
>
> Do we have some sane way to have user-pluggable sysbus devices on arm?

The answer in a general sense is "no, because user pluggable
sysbus is a weird idea". "sysbus" means "it's wired into a
specific bit of the memory map and to specific IRQs, and whoever
does that needs to know what IRQs and bits of memory are usable,
and the guest OS needs to know it's there". "user-pluggable" means
"it's all automatic and the guest can just do some kind of
probing for what is or isn't present". All the platform bus stuff
is a nasty mess that's working around the things people want
to plug in not being clean devices on probeable buses :-(
And the platform bus is only supported on the "virt" board,
because that's the only one where QEMU is generating its
own dtb or ACPI tables where it can tell the guest "hey,
there's some device here".

-- PMM


From xen-devel-bounces@lists.xenproject.org Tue Jan 28 10:51:31 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 10:51:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878372.1288540 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcjBq-0004H7-TT; Tue, 28 Jan 2025 10:51:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878372.1288540; Tue, 28 Jan 2025 10:51:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcjBq-0004H0-QV; Tue, 28 Jan 2025 10:51:30 +0000
Received: by outflank-mailman (input) for mailman id 878372;
 Tue, 28 Jan 2025 10:51:29 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=jygh=UU=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcjBp-0004Gm-7A
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 10:51:29 +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 d390fdce-dd65-11ef-a0e6-8be0dac302b0;
 Tue, 28 Jan 2025 11:51:28 +0100 (CET)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-5da12292b67so9060481a12.3
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 02:51:28 -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
 a640c23a62f3a-ab676116b02sm765105166b.174.2025.01.28.02.51.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 28 Jan 2025 02:51:27 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: d390fdce-dd65-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738061488; x=1738666288; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Woi1AjyI1FT+oY2p5rclMEWbqgTxSC8HyGcRDn0ysiw=;
        b=B+t/fbnhfH9cJuGf0K7nO+sSpX9WbJ+rOtEUJqt+Hazl1zw4QiJzJTrI1lJiA63OMj
         oJygLCLyozIpjoSOgKg2bj7RcCwuFE/UgyaI5Vz050kyOPIPvOvDQbFuTvN9PwpOZbnI
         tH3KTcOBTdFia3ly15n9fZbwAjhwvEHQ7cQ1h1iNiQ6tbQjZoSXdnUA9vhfK4Rf6dDqT
         S0YIYsZopPAuJ34yJlqI0WXXnc/wz6lcDHnbstNnR/ow7+vkfSwE5Ayi6m3vJZ87sGf1
         lhO4Hi7FZE4X514FxBGpz3NgVG85oyeqoW6MSNtIIIzP0Mn+HsfbViHem0RC8LUw2Feh
         z0DQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738061488; x=1738666288;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Woi1AjyI1FT+oY2p5rclMEWbqgTxSC8HyGcRDn0ysiw=;
        b=LvhayTGsk+NzXjq3IUsE4LA7hx3yVgYGen4eDYb010eFeV0nu8qPKePHS8aDPW/17k
         uHqCAoj4cJoB5qtMqqnvXH+OYpWvZFXWMOURRvGrz9iVUeDeb6nR+csRSvPUHESMY2NJ
         UzPbE1jKlBFsslTWoOAhHNjHr9MvK+OOaMmRIXVcF8nni0FlKuRK9jOJq0dJ13SzJErd
         pSgBfO2qgFTDfGZd/AaBKPfW2JI5YJs5xaQrnQ0pxUDiu5Di7q+jV2lY3QT5uenZ2W+l
         5V1LlaB48XhkSPXJaFrgb1tuQkTvpfBRTYZaG75E0cH4zPBLFUplPXumLjx8UMlrpaQJ
         OP+A==
X-Forwarded-Encrypted: i=1; AJvYcCVkom3wtQUsLyO5pSw+K+vBnE+5QgIsdij+c0EqLPV/nneLn02+X5FcFXRMoHnKdValGPYnPZygkmQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzShzOPTCnfcYzrIaB9bzSRxiwzCA3qti1y52/+CweglsxoSD6D
	rt6SWk4aIKvK+qLQDeMC6mvoi3PuFYElXf6Y1z/rdPZsQ4Fa987/ARsGbMa+8g==
X-Gm-Gg: ASbGncu1KENgQxQv25T52HD/NAu0KSvTqTcn0VXKdJAPG5Uf4VV6ofD5dLdrY6rPBth
	gL/8ijKDmLaZLoN+LhbbFy/ovIbHfgeR61FRy5pZ3+thbQ80dC9KH0W1z4PgESV4ogkmOOmtQ4V
	3aiaWwGvMp7n5thZ6mwyWfcK87bbA7sS2MGsxjz/BF2Fbk5c4k/0aC4wERLKywADs8mpf6UvasT
	WU68HjfXrmMBwCppfWC8hkcCj8bOb8eZstgNJjNgpFi0ic6KbfIsZby/hQaa4iLOg4sT0fbdVqS
	uEiuKSEOa885/dKiCyJEPUUcTVkGQQ6sAJioQ9xFk6g8eJIH/bjn48OgY6+ewFfoIisfuPA+Tpx
	J
X-Google-Smtp-Source: AGHT+IGJ+5iNb5HdjBkGfdVwByzn5vpLGB90GB2NxnDJhIajNZcdLjQ67Kkn2/OUzkiKVLb+FidUlw==
X-Received: by 2002:a05:6402:34ca:b0:5d0:81f5:a398 with SMTP id 4fb4d7f45d1cf-5db7d2dc58bmr99058889a12.1.1738061487881;
        Tue, 28 Jan 2025 02:51:27 -0800 (PST)
Message-ID: <fefb7445-cece-4fe6-b475-9acb8f551199@suse.com>
Date: Tue, 28 Jan 2025 11:51:26 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 04/24] xen/console: introduce
 console_{get,put}_domain()
To: dmukhin@ford.com
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
 <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
 <20250103-vuart-ns8250-v3-v1-4-c5d36b31d66c@ford.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250103-vuart-ns8250-v3-v1-4-c5d36b31d66c@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04.01.2025 02:58, Denis Mukhin via B4 Relay wrote:
> @@ -529,14 +532,18 @@ static void switch_serial_input(void)
>  
>  static void __serial_rx(char c)
>  {
> +    struct domain *d;
>      int rc = 0;
>  
> -    switch ( console_rx )
> -    {
> -    case 0:
> +    if ( console_rx == 0 )
>          return handle_keypress(c, false);
>  
> -    case 1:
> +    d = console_get_domain();
> +    if ( !d )
> +        return;
> +
> +    if ( is_hardware_domain(d) )
> +    {
>          /*
>           * Deliver input to the hardware domain buffer, unless it is
>           * already full.

Isn't this a (desirable) functional change for late-hwdom, which runs with
domid different from 0? Such a bug-fix-like change wants calling out in the
description, I think.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 28 10:58:54 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 10:58:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878382.1288557 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcjIw-0004ye-MR; Tue, 28 Jan 2025 10:58:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878382.1288557; Tue, 28 Jan 2025 10:58:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcjIw-0004yX-J1; Tue, 28 Jan 2025 10:58:50 +0000
Received: by outflank-mailman (input) for mailman id 878382;
 Tue, 28 Jan 2025 10:58: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 <SRS0=jygh=UU=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcjIv-0004yR-7f
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 10:58:49 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d8c48e3b-dd66-11ef-99a4-01e77a169b0f;
 Tue, 28 Jan 2025 11:58:47 +0100 (CET)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-aab925654d9so1076333266b.2
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 02:58: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
 a640c23a62f3a-ab675e64dbesm770704666b.57.2025.01.28.02.58.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 28 Jan 2025 02:58:45 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: d8c48e3b-dd66-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738061926; x=1738666726; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=rJj3eidiekjHFdZobMVCVZquWgpQtdsNdOqH5cRtVhw=;
        b=XSV7W3Vz15CAofLO1Q5ST4k+cPygq4uRMDdWFi0KU0Z4r26CrT4NtR66kdgh9fDgh0
         uu7CXXCXZGYM8lahfDMP/LI0uyY6gDpeTTxEelIJWawgv3M7yz5zc4c/fdYyyU7byftb
         lSRJeSolZh/c/Cz6cXLOhJ4Qx8UKWClXwbd78kMVn8/ZRT1Kd9TjgtEp1YZWxN5TIjv3
         yt6fRFwLPom9yTMoIzwdSSyFuFmcryLsFYWCZy8G7Lr0laJ2NvFVxnLFxbn0fKAhNEhs
         any1MdVTpf6jvLdm6lDwuwsK7unH6aXDOTl6Nmg9u04LMFNFBF9Jag1dKIsELzyVihsC
         YNfQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738061926; x=1738666726;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=rJj3eidiekjHFdZobMVCVZquWgpQtdsNdOqH5cRtVhw=;
        b=ACznE8SmZBoaSj6ptU66nlJUsm044xl40du4yLBQSI+rD7ufZ7/Q9VF6gJ/5XJeNL6
         +CAO8S7u5uBCUySEkoF0Xfr/b5GLbY9XchC1fMARP7v2NpqKSukMxwctmxd+BadzTOez
         X4iQkDRmsmTG/AGZu8tE29T1lIIod7iw1sENKE8G7EYdqElgqaRD8eT1MZsSUs4VGR4c
         ZDnExHJ8BsQGFxyLHk8Dr/DcB0DavKuURqTcBFKl2tva/ZoFbW1elHnrZ9hosNohnJrn
         HsaVAcuBeCarfaM5/+1NA3BmUmdqBuCuN3sY0gXBgl8SXb6oh3sq2W1m0MjPzChWVC9d
         64lA==
X-Forwarded-Encrypted: i=1; AJvYcCUdJnxSGjr9KRPFcN8d3QwBZuS3YN7ZbJwEXFOtTY0zNFgYQYdYPHrndCEt6HpM2WulelkRh137iy8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwZIi/FPHdo68DwGEXG1cy65L+qmzLzOKjjhFFPs8kyBDvpXV9G
	G0CUrvbSEbkLERjI9nML6VAUZHMjCFICG5EBk1MXGhzsjYtOD7y/f9plrmCrDw==
X-Gm-Gg: ASbGncvRpoGorp+JSFD0ODfbyiUtx2H+ZHe8xDlcF3NPEToXX8LZFQxkUiUIhpvmshz
	pHr747QYqBKvWTYFeOm9nRBZZVuNh/YciDXxePCBguFQNEGEprflj3AsXg4M7szPiwhNyTojDQN
	8A9lXkZOYTu4pURCKLYJLTyDR10wBiNwtrToaPN/x6UP988WeGBAzXTYOtZc1HN44mEHYbp7dlr
	PUaz5Es+uavFtntNEZS1g2vtsGrqdbWHBsZPBoDovoFsRdv19WIRP/xEcbGtXnnBEmz9zg5XZgV
	UCAhJB0k0nwnaK7H/XGBf4G2w/v+dGmut8N2njViKEo/GknqgyvS/39jvIUgfqmfWU/DEi93sEb
	d
X-Google-Smtp-Source: AGHT+IEfuWflZSaLdRG/nS1r6jWnAs4qCszGzcwGPoUAe7nR8VPv+cXuKMqqlAUdwkjTL9I9MGgzRg==
X-Received: by 2002:a17:907:7f17:b0:ab2:b5f1:5698 with SMTP id a640c23a62f3a-ab38b44e10emr4538752166b.38.1738061926137;
        Tue, 28 Jan 2025 02:58:46 -0800 (PST)
Message-ID: <a3b62c5e-44e7-4592-8075-844b219df216@suse.com>
Date: Tue, 28 Jan 2025 11:58:45 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 05/24] xen/console: introduce consoled_is_enabled()
To: dmukhin@ford.com
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
 <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
 <20250103-vuart-ns8250-v3-v1-5-c5d36b31d66c@ford.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250103-vuart-ns8250-v3-v1-5-c5d36b31d66c@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04.01.2025 02:58, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin <dmukhin@ford.com>
> 
> There are few places which check pv_shim console under CONFIG_PV_SHIM in xen
> console driver. Instead of #ifdef-ing, use new consoled_is_enabled() to
> customize the logic.
> 
> Header file now can be included w/o CONFIG_X86.
> 
> Signature of consoled_guest_{rx,tx} has changed so the error can be logged.

While you use consoled_guest_tx()'es return value, consoled_guest_rx()'es
remains unused. Why change its return type then in the first place, even
more so when these adjustments are pretty much unrelated to the purpose of
the patch anyway?

> @@ -508,11 +508,9 @@ static void switch_serial_input(void)
>              break;
>          }
>  
> -#ifdef CONFIG_PV_SHIM
> -        if ( next_rx == 1 )
> +        if ( consoled_is_enabled() && next_rx == 1 )
>              domid = get_initial_domain_id();

Isn't this again a bug-fix-like change, without this actually being
mentioned anywhere?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 28 11:02:35 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 11:02:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878393.1288566 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcjMY-0006qo-6U; Tue, 28 Jan 2025 11:02:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878393.1288566; Tue, 28 Jan 2025 11:02:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcjMY-0006qh-3w; Tue, 28 Jan 2025 11:02:34 +0000
Received: by outflank-mailman (input) for mailman id 878393;
 Tue, 28 Jan 2025 11:02:32 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=AW3f=UU=cloud.com=frediano.ziglio@srs-se1.protection.inumbo.net>)
 id 1tcjMW-0006qb-Qi
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 11:02:32 +0000
Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com
 [2607:f8b0:4864:20::32d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5dfa34e3-dd67-11ef-99a4-01e77a169b0f;
 Tue, 28 Jan 2025 12:02:30 +0100 (CET)
Received: by mail-ot1-x32d.google.com with SMTP id
 46e09a7af769-71e2bc5b90fso2931789a34.0
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 03:02:30 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5dfa34e3-dd67-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1738062149; x=1738666949; 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=hAPP67iq/fZlFT5QwMZH0FVtr7XinDNZQPhjL/SYDyo=;
        b=QcMM2vqUfcrtLDRw7h/g2QbSj42fCbUXYhXtjP8Mf44alhk3uwrgj8OwJhGJSjRhF1
         gkrpgH9MGvTwShnaGcAgd9UttOH0LKn+Jy/W1fvYmROBkRuXF3COZN+lXdZTw2zQRFXz
         gRMkbfyxKazlSd3x+12SNCvFXE2L2IDdp1+MQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738062149; x=1738666949;
        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=hAPP67iq/fZlFT5QwMZH0FVtr7XinDNZQPhjL/SYDyo=;
        b=OakXMlweBz9Pa0gIa70GO57Q8Mg2cc1NPQOYu7MIJiLmbcf1HNoiMT4eiQUN4dhfOA
         pJqaFVkbuIHYlaVlgji+RCy/kcRSFXfDxIc9hyLkPPyW8IXWj+K41NEi3uQIMFPJ4gIA
         D5ptEr81HX3Pt6H+S3TtV5qO+zygxBjxDdZYWt6Av5lsHZAznJLd+LaGTz6MCIqsty5/
         W9Z0F/rUj5vDhzEoHeusAUMZvUrDMtw3kFjwsk6BX/2+BwRaDU7CwZ28uwA8ExfnMTjN
         Ywbybo8YolDeQBxswKAj03eQyLWt+rGo+V+IdR8EckFf4AX+3SH70ktBth58VCeoyjJO
         b0Lw==
X-Gm-Message-State: AOJu0YxT13cJRl94srumZawdaCFjPPzdZio1CPMMRSYV7FTR98sqKez+
	wGFLodywrx8Aag8jCWkVG6IBRnuRTEFfQFul1YBy61JCi+4P/wnS90Ie7biGXaS3yM9/5Ji0GUy
	rGaSWo+CJ1hCIuybNPe9m/J2Ztj1O/pEDhh8OoSVMlYXoZXfV7gE=
X-Gm-Gg: ASbGnctoEEDkM8LwTqyzbuNNhAdsombZohjcOOpTiPFiWGUaD+C1EZNSX5CnZ7B+muU
	CN41NECVTkPN1MriP7j5c8lq+I/f9Ju0x+1BLN0cWwmsC0WsxqOj+5UJDLLFqbxtmL52IKxgq7U
	8=
X-Google-Smtp-Source: AGHT+IGoGR17LILmDJyAuvFIrE6eoahMphFFs3jrb79H45NTRlP+3t7BPnU6oQtSav491MANOIpfszF2Eykzvcpp1dY=
X-Received: by 2002:a05:6870:7e89:b0:27c:a414:b907 with SMTP id
 586e51a60fabf-2b1c0c7667amr27172377fac.33.1738062149237; Tue, 28 Jan 2025
 03:02:29 -0800 (PST)
MIME-Version: 1.0
References: <20250114115430.104084-1-frediano.ziglio@cloud.com>
In-Reply-To: <20250114115430.104084-1-frediano.ziglio@cloud.com>
From: Frediano Ziglio <frediano.ziglio@cloud.com>
Date: Tue, 28 Jan 2025 11:02:17 +0000
X-Gm-Features: AWEUYZmMzTgbbxw__LmW2sukWOiGlbA7wKpYVfJ0oKMXUJkSbi2BmHkn1V1b5Jo
Message-ID: <CACHz=Zh65aak9T7WQiV9CYDPfJG-KLfJ=rJWFB5y=_XXqNsAaQ@mail.gmail.com>
Subject: Re: [PATCH v2] x86/boot: Handle better alignment for 32 bit code
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich <jbeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>, 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
	Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

ping

On Tue, Jan 14, 2025 at 11:54=E2=80=AFAM Frediano Ziglio
<frediano.ziglio@cloud.com> wrote:
>
> Output file didn't have correct alignment.
> Allows alignment into data or code up to 2mb.
> Intermediate object files are kept in order to copy alignment
> from object produced by the linker and final object (produced
> by combine_two_binaries.py script).
>
> Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
> ---
>  xen/arch/x86/boot/Makefile        | 12 ++++++++----
>  xen/tools/combine_two_binaries.py |  7 ++++++-
>  2 files changed, 14 insertions(+), 5 deletions(-)
>
> Changes since v1:
> - Improve comments and description.
>
> diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
> index 13d4583173..a56d8a7e0f 100644
> --- a/xen/arch/x86/boot/Makefile
> +++ b/xen/arch/x86/boot/Makefile
> @@ -40,8 +40,12 @@ LD32 :=3D $(LD) $(subst x86_64,i386,$(LDFLAGS_DIRECT))
>  # are affected by both text_diff and text_gap.  Ensure the sum of gap an=
d diff
>  # is greater than 2^16 so that any 16bit relocations if present in the o=
bject
>  # file turns into a build-time error.
> -text_gap :=3D 0x010200
> -text_diff :=3D 0x408020
> +# As gap will affect the output section size it should not be huge to av=
oid the
> +# creation of huge files.
> +# The sum of gap and diff will affect the possible alignment so should b=
e a
> +# multiple of the possible alignment.
> +text_gap :=3D 0x01c240
> +text_diff :=3D 0x7e3dc0
>
>  $(obj)/build32.base.lds: AFLAGS-y +=3D -DGAP=3D$(text_gap) -DTEXT_DIFF=
=3D$(text_diff)
>  $(obj)/build32.offset.lds: AFLAGS-y +=3D -DGAP=3D$(text_gap) -DTEXT_DIFF=
=3D$(text_diff) -DAPPLY_OFFSET
> @@ -69,7 +73,6 @@ $(obj)/built-in-32.%.bin: $(obj)/build32.%.lds $(obj)/b=
uilt-in-32.tmp.o
>         $(LD32) $(orphan-handling-y) -N -T $< -o $(@:bin=3Do) $(filter %.=
o,$^)
>         $(NM) -p --format=3Dbsd $(@:bin=3Do) > $(@:bin=3Dmap)
>         $(OBJCOPY) -j .text -O binary $(@:bin=3Do) $@
> -       rm -f $(@:bin=3Do)
>
>  quiet_cmd_combine =3D GEN     $@
>  cmd_combine =3D \
> @@ -80,6 +83,7 @@ cmd_combine =3D \
>                --bin1      $(obj)/built-in-32.base.bin \
>                --bin2      $(obj)/built-in-32.offset.bin \
>                --map       $(obj)/built-in-32.base.map \
> +              --align     $(shell $(OBJDUMP) -h $(obj)/built-in-32.base.=
o|sed '/text.*2\*\*/ {s/.*2\*\*//;p;}; d') \
>                --exports   cmdline_parse_early,reloc,reloc_trampoline32 \
>                --output    $@
>
> @@ -90,4 +94,4 @@ $(obj)/built-in-32.S: $(obj)/built-in-32.base.bin $(obj=
)/built-in-32.offset.bin
>                        $(srctree)/tools/combine_two_binaries.py FORCE
>         $(call if_changed,combine)
>
> -clean-files :=3D built-in-32.*.bin built-in-32.*.map build32.*.lds
> +clean-files :=3D built-in-32.*.bin built-in-32.*.map built-in-32.*.o bui=
ld32.*.lds
> diff --git a/xen/tools/combine_two_binaries.py b/xen/tools/combine_two_bi=
naries.py
> index 581e57cbc0..8e587c24fb 100755
> --- a/xen/tools/combine_two_binaries.py
> +++ b/xen/tools/combine_two_binaries.py
> @@ -26,6 +26,10 @@ parser.add_argument('--text-diff', dest=3D'text_diff',
>                      required=3DTrue,
>                      type=3Dauto_int,
>                      help=3D'Difference between code section start')
> +parser.add_argument('--align', dest=3D'align',
> +                    default=3D2,
> +                    type=3Dauto_int,
> +                    help=3D'Alignment in power of 2')
>  parser.add_argument('--output', dest=3D'output',
>                      help=3D'Output file')
>  parser.add_argument('--map', dest=3D'mapfile',
> @@ -93,7 +97,7 @@ if size1 > size2:
>      file1, file2 =3D file2, file1
>      size1, size2 =3D size2, size1
>  if size2 !=3D size1 + gap:
> -    raise Exception('File sizes do not match')
> +    raise Exception('File sizes do not match %d !=3D %d + %d' % (size2, =
size1, gap))
>  del size2
>
>  file1.seek(0, 0)
> @@ -219,6 +223,7 @@ print('''/*
>   * File autogenerated by combine_two_binaries.py DO NOT EDIT
>   */''', file=3Dout)
>  print('\t' + args.section_header, file=3Dout)
> +print('\t.p2align\t' + str(args.align), file=3Dout)
>  print('obj32_start:', file=3Dout)
>  output(out)
>  print('\n\t.section .note.GNU-stack,"",@progbits', file=3Dout)
> --
> 2.34.1
>


From xen-devel-bounces@lists.xenproject.org Tue Jan 28 11:14:44 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 11:14:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878402.1288577 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcjYF-0000QN-8Z; Tue, 28 Jan 2025 11:14:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878402.1288577; Tue, 28 Jan 2025 11:14:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcjYF-0000QG-5Q; Tue, 28 Jan 2025 11:14:39 +0000
Received: by outflank-mailman (input) for mailman id 878402;
 Tue, 28 Jan 2025 11:14:38 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=jygh=UU=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcjYE-0000QA-2B
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 11:14:38 +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 0e6c33fc-dd69-11ef-99a4-01e77a169b0f;
 Tue, 28 Jan 2025 12:14:35 +0100 (CET)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-ab633d9582aso992149166b.1
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 03:14:36 -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
 a640c23a62f3a-ab675e12d5bsm758746266b.36.2025.01.28.03.14.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 28 Jan 2025 03:14:34 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 0e6c33fc-dd69-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738062875; x=1738667675; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=NyZNG64s9cXy53YmnMSX23SVcQKgzG6tniYUQRcI02M=;
        b=Hc0i2PKWV5PRhy6frnYwbNnsjcKnN+kmEalnCs/pIewe/SnSic3MGaBmORxEgvA6y8
         pCetBDdAPLBeRsHbXxvUp53ERO1gD3NBPCgx/Fe7kKne3xh31mSGDI0PWpANXiwIbt6N
         M/9noVuYoLlfGDt7DkMwIqwoWTP23/NpReU5CnV+sHt7GImmuYequpTXK2v8fyR5KFOW
         MPRDnWYL+lgwWPTUqRyKfFWIPhQxPVxwHsBWexUPsxcJ2MfQtIOF22jwIIquN8yRNBIU
         uZM84AwXsvASHw4Ou7knYMumFT5HKQCI0o0hhKdP3IuWXTBeBniKpIFzxHluA99U2xiF
         w6og==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738062875; x=1738667675;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=NyZNG64s9cXy53YmnMSX23SVcQKgzG6tniYUQRcI02M=;
        b=sxh18Nli/oN8IQZKNDC0qiguSoLN3LtMi0l5jZitpP3BkM50pNW42/Ft0NyayrQ//7
         Yve5OaxYJxm+VI6jxAaS4vwRfmr+LlV4Y+Dl7xEJtflEVluWwMIRmX+w/sMTkAP2X1Tw
         Ky44kjHAHYn36g6REtEi9kDTfvozlOhEfxWNr3cgU3/vj5z3dncZCMmsiNkIo4ZtXHZ3
         ql7d7tbJHd6sMYSHh33ZBcieecjY9wgTwWOkvSVDSvDNjSpe2Qq4SmY3JVXlx24evWJJ
         Yo86oS1Oo8l/sSTk3HjvzZvbqYgWFZfECWMhyslTEBFmWZuAP1jmU5jJOF4AHQqGFa1d
         t3cw==
X-Forwarded-Encrypted: i=1; AJvYcCWnrdXYxLHE4bwBLlTe4ZR/wUzPd+kS9wBRDPX3N/VABLBCI4RvrpV9V64UiDOWw3CBJpab19CJQkk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwY5IvO7Krxn+mDk7dUomx6cRdEZ+XF3WrvF+V8c9giWshK0jgv
	YXbAuR2tAZIdgZv/Q93WWiksKJJhACHUpsb82O0RqeowL5ZBpir+8VOcmMR7HPKNPehUk6AWcMI
	=
X-Gm-Gg: ASbGnctvcnZ59H7IsDiwWWMiAP9RsCcFGVfYLZi4j5focezNLxxz8wN3yHkXumtd9x6
	qXJ03cJpZxmrMHrs55lIk6H/PEBnP0Lea2xe4WvW3MCe003x3aGOmVe4uysX6cHPL3FUay4P0Z3
	GQXJkzBFXU3z0z1t39zilurdEsZC7imd7R8NNIfGPrSArC9tuOVQawDzdaxGrjv1S0L+mIqIkWr
	qmV5DKhjNyMtW8CdmKrUdwKfj+RuKD4yzYSNX58z04L0rX2hAPVHyvj6jUzHpVnnts9DpyP6A4C
	c4oLtcoycsBs6SGwAM30NlQ6Ch6+pe76NgtGRbAInMC7/Yw+xh0jrbVCzM7ZnjCIqOvNoua1T8t
	k
X-Google-Smtp-Source: AGHT+IF7GiwWH8LCsOqA6J6cz6/jexPdH7tHuUfevQc3FNqWDrfFHdTiXDpq4/i8HxiuBuRcm0HDBA==
X-Received: by 2002:a17:907:969f:b0:ab2:b863:b7fa with SMTP id a640c23a62f3a-ab38b43b915mr4243596566b.44.1738062875381;
        Tue, 28 Jan 2025 03:14:35 -0800 (PST)
Message-ID: <ef1e6ff9-e5ae-41ef-9ca1-d4fa7f2e74b8@suse.com>
Date: Tue, 28 Jan 2025 12:14:33 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 06/24] xen/domain: introduce hardware emulation flags
To: dmukhin@ford.com
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
 <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
 <20250103-vuart-ns8250-v3-v1-6-c5d36b31d66c@ford.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250103-vuart-ns8250-v3-v1-6-c5d36b31d66c@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04.01.2025 02:58, Denis Mukhin via B4 Relay wrote:
> @@ -8,7 +9,9 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
>  {
>      switch(d_config->c_info.type) {
>      case LIBXL_DOMAIN_TYPE_HVM:
> -        config->arch.emulation_flags = (XEN_X86_EMU_ALL & ~XEN_X86_EMU_VPCI);
> +        config->arch.emulation_flags = XEN_X86_EMU_ALL;
> +        config->arch.emulation_flags &= ~XEN_X86_EMU_VPCI;
> +
>          if (!libxl_defbool_val(d_config->b_info.u.hvm.pirq))
>              config->arch.emulation_flags &= ~XEN_X86_EMU_USE_PIRQ;
>          break;

You're merely writing the same thing differently here, aren't you? Why
is this needed?

> @@ -159,9 +160,7 @@ static PyObject *pyxc_domain_create(XcObject *self,
>  
>  #if defined (__i386) || defined(__x86_64__)
>      if ( config.flags & XEN_DOMCTL_CDF_hvm )
> -        config.arch.emulation_flags = XEN_X86_EMU_ALL &
> -                                      ~(XEN_X86_EMU_VPCI |
> -                                        XEN_X86_EMU_USE_PIRQ);
> +        config.arch.emulation_flags = XEN_X86_EMU_BASELINE;

While less direct here, same question as above.

> --- a/tools/tests/paging-mempool/test-paging-mempool.c
> +++ b/tools/tests/paging-mempool/test-paging-mempool.c
> @@ -9,6 +9,7 @@
>  #include <xenforeignmemory.h>
>  #include <xengnttab.h>
>  #include <xen-tools/common-macros.h>
> +#include <xen/virtdev.h>
>  
>  static unsigned int nr_failures;
>  #define fail(fmt, ...)                          \
> --- a/tools/tests/resource/test-resource.c
> +++ b/tools/tests/resource/test-resource.c
> @@ -8,6 +8,7 @@
>  #include <xenforeignmemory.h>
>  #include <xengnttab.h>
>  #include <xen-tools/common-macros.h>
> +#include <xen/virtdev.h>
>  
>  static unsigned int nr_failures;
>  #define fail(fmt, ...)                          \
> --- a/tools/tests/tsx/test-tsx.c
> +++ b/tools/tests/tsx/test-tsx.c
> @@ -29,6 +29,7 @@
>  #include <xenctrl.h>
>  #include <xenguest.h>
>  #include <xen-tools/common-macros.h>
> +#include <xen/virtdev.h>
>  
>  #include "xg_private.h"
>  

Throughout these in particular - it's not really nice to require the extra
#include everywhere now.

> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -753,9 +753,7 @@ static bool emulation_flags_ok(const struct domain *d, uint32_t emflags)
>               emflags != (X86_EMU_VPCI | X86_EMU_LAPIC | X86_EMU_IOAPIC) )
>              return false;
>          if ( !is_hardware_domain(d) &&
> -             /* HVM PIRQ feature is user-selectable. */
> -             (emflags & ~X86_EMU_USE_PIRQ) !=
> -             (X86_EMU_ALL & ~(X86_EMU_VPCI | X86_EMU_USE_PIRQ)) &&
> +             xen_emflags_allowable(emflags) != XEN_X86_EMU_BASELINE &&

What is or is not allowable doesn't depend on just the flags. Either the
name needs to be more specific, or the domain needs passing in.

> @@ -456,7 +457,7 @@ struct arch_domain
>      /* Don't unconditionally inject #GP for unhandled MSRs. */
>      bool msr_relaxed;
>  
> -    /* Emulated devices enabled bitmap. */
> +    /* Hardware emulation flags. */
>      uint32_t emulation_flags;
>  } __cacheline_aligned;

The original comment isn't good enough because of what?

> --- a/xen/include/Makefile
> +++ b/xen/include/Makefile
> @@ -15,6 +15,7 @@ headers-y := \
>      compat/sched.h \
>      compat/vcpu.h \
>      compat/version.h \
> +    compat/virtdev.h \
>      compat/xen.h \
>      compat/xlat.h

This shouldn't be needed, as ...

> --- /dev/null
> +++ b/xen/include/public/virtdev.h
> @@ -0,0 +1,61 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef XEN__PUBLIC_VIRTDEV_H
> +#define XEN__PUBLIC_VIRTDEV_H

... this should in no case be generally exposed: You moved the flags
from a tools-only section of arch-x86/xen.h, and hence they should
remain tools-only.

> +/*
> + * Domain hardware emulation flags.
> + */
> +enum {
> +    VIRTDEV_LAPIC      = 1U << 0,
> +    VIRTDEV_HPET       = 1U << 1,
> +    VIRTDEV_PM         = 1U << 2,
> +    VIRTDEV_RTC        = 1U << 3,
> +    VIRTDEV_IOAPIC     = 1U << 4,
> +    VIRTDEV_PIC        = 1U << 5,
> +    VIRTDEV_VGA        = 1U << 6,
> +    VIRTDEV_IOMMU      = 1U << 7,
> +    VIRTDEV_PIT        = 1U << 8,
> +    VIRTDEV_PIRQ       = 1U << 9,
> +    VIRTDEV_PCI        = 1U << 10,
> +};
> +
> +#if defined(__i386__) || defined(__x86_64__)

Why does this conditional live only here? Almost the entire enum above
is x86-specific, too.

Bottom line: I remain yet to be convinced of the need for the new header.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 28 11:18:27 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 11:18:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878410.1288586 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcjbu-0000zA-MI; Tue, 28 Jan 2025 11:18:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878410.1288586; Tue, 28 Jan 2025 11:18:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcjbu-0000z3-JZ; Tue, 28 Jan 2025 11:18:26 +0000
Received: by outflank-mailman (input) for mailman id 878410;
 Tue, 28 Jan 2025 11:18:25 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=p3hs=UU=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tcjbt-0000yw-Fn
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 11:18:25 +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 95fdbe84-dd69-11ef-99a4-01e77a169b0f;
 Tue, 28 Jan 2025 12:18:23 +0100 (CET)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3862ca8e0bbso4802777f8f.0
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 03:18:23 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38c2a1764e9sm14028356f8f.17.2025.01.28.03.18.22
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Tue, 28 Jan 2025 03:18:22 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 95fdbe84-dd69-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1738063103; x=1738667903; 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=fT2SAbuvKPbKd3z1KkDvR/xDsz8I4RjNHLW+g3/uOgc=;
        b=f6nx3FfrGbWpBXuJorKeQpOVxAi3hfHNIR1OpCCZ1iCBskdNxQFKvozk/H6537En8S
         lGNIIhVjlY5Y/tEwVJnRAqyWbAdXLbAKwS7jMRsZf/3GfLh6qZ36TwOOWp5x3KDkv6of
         OGGe3X6PieWFc9RcLbo5vmbE0Dp+UZ4hXzvtCVh9OLVhaRSRCB2XKX/O71yw3FQG3oQf
         ZzSmHlIgs0DaZk5eMzihZqMF3XnJRsK5VYUTP241Ij+HDFPxMVOLqHOfFkFtHxTKfGqY
         V5kOhb0zN5EgOQdRVMSPFYY3Ndy0MrtOA6MORNPENGHByoyou8i4wIl840X6kTIPhJ8r
         z54g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738063103; x=1738667903;
        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=fT2SAbuvKPbKd3z1KkDvR/xDsz8I4RjNHLW+g3/uOgc=;
        b=AcnyTrl6wmDbz4NKP6OG/oAhiCHBlna/MO+PVkKUadaipM5nZyTQxpeObKVO9D1aMZ
         w3fSclelx3pyMy7aBZGsa8YWMztHm8gL7nRS9Zk4wk/ao91KxczUL7OB55qLlfN10hnc
         GBcAk8617EHIdTIeMdcw9gUFjVbznCE/g82Tw0vQ9JIXa12ayi60UhCxETv6TTrjwFNL
         ipWmqHabFkZuWBWJ+xVGaWA2drtQSoPDO2m24lbTPV3D9IxkdaFyiACBfgLTyR4h70xx
         lAFSoC+9yi+YfgqZukJU2JmJrchI21bf1dKr5YPHFig9EG7mt01VM0GH/cwJNE+TQOCH
         rEBg==
X-Gm-Message-State: AOJu0YyTPTLWfeKcX1pDH/Yct4zAGGKTROC0vmOZZ2xF8BADL0ICqcw+
	NGA0m4+IWLWSC/J+w2fwQ2/s2J7yLOym7Y+Nf1wrUJzG1CR0DvV7AEUIj77ik6M=
X-Gm-Gg: ASbGncuv/gg3abJLBTm3DMwPuvTBW5Nant0MbXQ8hQ0v5ED9cL6C9JJLds52Y4btbku
	SOhBaxdUnFe4CYtUosEwdf49HpwEV3HCz8DPiTqPYssPCzSFE7aoTFAhKanKky7zdYKfv54Ji+x
	42Z+oylDC1l+VOP9xhy1t4lS17+zhbZMWNr8HlO/SPfx5fKYVt66cP6mh/2QGN9mQncvWH48NSM
	I3907xe0xvMNnsXkK043pMGCMSi2lLzh0fmpTPZPs2ZyyW7f2MrcJIGf4gqtvCPJ9NF9PvvGkVe
	I7Ubnn55yC8tfhReaKjvNeFViPYKQ23VCrMUKk0g6KCvH7oD1E8LJWUc+IQboDQGUA==
X-Google-Smtp-Source: AGHT+IH+qdHcEoJcFpOtnVud1J3WbJAaKIWKl6fv7LCSJoOys54P6jRa3uzMWf61KKffEYTlHNPhxw==
X-Received: by 2002:a05:6000:2a9:b0:38a:50f7:24fa with SMTP id ffacd0b85a97d-38bf57bed8emr46915786f8f.54.1738063102960;
        Tue, 28 Jan 2025 03:18:22 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: xen-devel@lists.xenproject.org,
	=?UTF-8?q?Daniel=20P=20=2E=20Berrang=C3=A9?= <berrange@redhat.com>,
	Fabiano Rosas <farosas@suse.de>,
	Markus Armbruster <armbru@redhat.com>,
	Thomas Huth <thuth@redhat.com>,
	Laurent Vivier <lvivier@redhat.com>,
	Phil Dennis-Jordan <phil@philjordan.eu>,
	Bernhard Beschow <shentey@gmail.com>,
	Akihiko Odaki <akihiko.odaki@daynix.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
Subject: [PATCH 0/2] tests/qtest: Make qtest_has_accel() generic
Date: Tue, 28 Jan 2025 12:18:19 +0100
Message-ID: <20250128111821.93767-1-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

In preparation of running QTests using HVF on Darwin,
make qtest_has_accel() generic.

Note, this also allow running other accelerators such
Xen, WHPX, ...

Philippe Mathieu-Daudé (2):
  tests/qtest: Extract qtest_qom_has_concrete_type() helper
  tests/qtest: Make qtest_has_accel() generic

 tests/qtest/libqtest.c | 110 +++++++++++++++++++++++------------------
 1 file changed, 61 insertions(+), 49 deletions(-)

-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Tue Jan 28 11:18:30 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 11:18:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878411.1288597 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcjby-0001GE-SS; Tue, 28 Jan 2025 11:18:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878411.1288597; Tue, 28 Jan 2025 11:18:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcjby-0001G6-Ph; Tue, 28 Jan 2025 11:18:30 +0000
Received: by outflank-mailman (input) for mailman id 878411;
 Tue, 28 Jan 2025 11:18:29 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=p3hs=UU=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tcjbx-0001F4-3o
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 11:18:29 +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 99048f01-dd69-11ef-a0e6-8be0dac302b0;
 Tue, 28 Jan 2025 12:18:28 +0100 (CET)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-43618283dedso58131915e9.3
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 03:18:28 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38c2a17630asm13849683f8f.6.2025.01.28.03.18.26
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Tue, 28 Jan 2025 03:18:27 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 99048f01-dd69-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1738063107; x=1738667907; 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=OYrLqiOXcaakZxlAQt7EUmigWAEMqhVrl2IG/lxJyhw=;
        b=TJjpaU8jMle07/7MkT8rtfEM7YglAa79rNtk93PtGP7PTzN+Zylc106GyVo4wlJSYK
         iFnOlxV/zBoTKfVGgJwitCuRMmk8RXK5ugViM+cxk2jfZOeqd4uacyi/ULXyXZDb0LKO
         cNB20cs7jfMs35362PqzuSMIqlU8axSXG2aPCxFCNQgWgE0O7R8nUQ3KI1iFawabk2J0
         A8LMPSbe3BnvN5gMyfX92zfO1G/4wA1JBHWUaAvoZFm4GdwPuhYB/wwSN0MiPvroYuDp
         VDvzL+BHGEyljuc5b/WgzIEjQ8jhP/C4IwdgmhSfBlkZzYqB8WRMDN/6Yb+/y4cPBbo6
         ukPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738063107; x=1738667907;
        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=OYrLqiOXcaakZxlAQt7EUmigWAEMqhVrl2IG/lxJyhw=;
        b=Ko7R0mVQ/d6weUMvAXoZlwi1221/TcwrSUgUNg9zSw4Ry9uGKaoiuXj0rVV5ydKC52
         w7dKbBi0RVS4dFCrSov9YeF8rh6XelNA3fiZNkQ2huWsmS3GyvwD2Zu9suxRHJ32HkVx
         tT2a4ScvBQI28tComRzKBrphFvaLZCjoN3OuKNEjUsjqT3d67hYk6nZCr/Gh5F8/w0Qk
         jojd6GqpgdYNMgh+jWP8ett0H2OeI4/eNYR9UTGcRABy7WMKMWAC2RvITyZOEuEMQ7NN
         +BXFQC2LOk1XekOR4zA3Ky5X+2K7G4XcyhuV7AaBqmF+PqfK0xqusfyHvTW0wyVUyhcS
         RbIA==
X-Gm-Message-State: AOJu0YwCyo0I0yNmV1ieZY/2Xp9j+Pyf3Hg7s2aOMVM5XliA8e5P6fTV
	slYm4qmvSVpNwLbsBwZrM4dYANUY0MybzGShEi3mv7tM3RjN/b2xhxPzJXjvvrU=
X-Gm-Gg: ASbGncuvh2GGtM1b11GkTMLy9/Lh8FnRVW+qzSknYvPgFxymipE6PYr14Ddxl/3tVI+
	NMfO1KKCGluNuMl0dqEQkCIUMkD1yP4uozXt2DODrnaq3tthhYNAX22S0y7PoluSbM5hROi6Btk
	g1EhvQDmpyd76g6zqevxN6z+5jS6A/zUTzfyh25BWfUW3LZUBz1aiSINiCgkBpKC9BFyAsp7NJV
	IATODPwAET9bbPWifGwBrrAMJrV8pA1OfvxdQEz7F03g/mNR0hfJ2li6c1oMWmq0KcSXHP9FtiY
	B0nAIjgo1fsCLl4Iso7eX6MXpzOhypme0HoGZ3KZKH3YfsgFYSH847Yq1BDt+J/6ng==
X-Google-Smtp-Source: AGHT+IHuyptLaRttD9sYQjH4mdAu0F/Xvz8DUVOj+7pYznWKRjFlcYnhiRd7S+GEQeAAPBF5mr0tSg==
X-Received: by 2002:a05:6000:1887:b0:38a:87cc:fb42 with SMTP id ffacd0b85a97d-38bf56639d5mr43298969f8f.21.1738063107562;
        Tue, 28 Jan 2025 03:18:27 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: xen-devel@lists.xenproject.org,
	=?UTF-8?q?Daniel=20P=20=2E=20Berrang=C3=A9?= <berrange@redhat.com>,
	Fabiano Rosas <farosas@suse.de>,
	Markus Armbruster <armbru@redhat.com>,
	Thomas Huth <thuth@redhat.com>,
	Laurent Vivier <lvivier@redhat.com>,
	Phil Dennis-Jordan <phil@philjordan.eu>,
	Bernhard Beschow <shentey@gmail.com>,
	Akihiko Odaki <akihiko.odaki@daynix.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
Subject: [PATCH 1/2] tests/qtest: Extract qtest_qom_has_concrete_type() helper
Date: Tue, 28 Jan 2025 12:18:20 +0100
Message-ID: <20250128111821.93767-2-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250128111821.93767-1-philmd@linaro.org>
References: <20250128111821.93767-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Extract qtest_qom_has_concrete_type() out of qtest_has_device()
in order to re-use it in the following commit.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 tests/qtest/libqtest.c | 89 ++++++++++++++++++++++++------------------
 1 file changed, 51 insertions(+), 38 deletions(-)

diff --git a/tests/qtest/libqtest.c b/tests/qtest/libqtest.c
index a1e105f27f9..7e9366ad6d5 100644
--- a/tests/qtest/libqtest.c
+++ b/tests/qtest/libqtest.c
@@ -978,6 +978,56 @@ const char *qtest_get_arch(void)
     return end + 1;
 }
 
+static bool qtest_qom_has_concrete_type(const char *parent_typename,
+                                        const char *child_typename,
+                                        QList **cached_list)
+{
+    QList *list = cached_list ? *cached_list : NULL;
+    const QListEntry *p;
+    QObject *qobj;
+    QString *qstr;
+    QDict *devinfo;
+    int idx;
+
+    if (!list) {
+        QDict *resp;
+        QDict *args;
+        QTestState *qts = qtest_init("-machine none");
+
+        args = qdict_new();
+        qdict_put_bool(args, "abstract", false);
+        qdict_put_str(args, "implements", parent_typename);
+
+        resp = qtest_qmp(qts, "{'execute': 'qom-list-types', 'arguments': %p }",
+                         args);
+        g_assert(qdict_haskey(resp, "return"));
+        list = qdict_get_qlist(resp, "return");
+        qobject_ref(list);
+        qobject_unref(resp);
+
+        qtest_quit(qts);
+
+        if (cached_list) {
+            *cached_list = list;
+        }
+    }
+
+    for (p = qlist_first(list), idx = 0; p; p = qlist_next(p), idx++) {
+        devinfo = qobject_to(QDict, qlist_entry_obj(p));
+        g_assert(devinfo);
+
+        qobj = qdict_get(devinfo, "name");
+        g_assert(qobj);
+        qstr = qobject_to(QString, qobj);
+        g_assert(qstr);
+        if (g_str_equal(qstring_get_str(qstr), child_typename)) {
+            return true;
+        }
+    }
+
+    return false;
+}
+
 bool qtest_has_accel(const char *accel_name)
 {
     if (g_str_equal(accel_name, "tcg")) {
@@ -1757,45 +1807,8 @@ bool qtest_has_machine(const char *machine)
 bool qtest_has_device(const char *device)
 {
     static QList *list;
-    const QListEntry *p;
-    QObject *qobj;
-    QString *qstr;
-    QDict *devinfo;
-    int idx;
 
-    if (!list) {
-        QDict *resp;
-        QDict *args;
-        QTestState *qts = qtest_init("-machine none");
-
-        args = qdict_new();
-        qdict_put_bool(args, "abstract", false);
-        qdict_put_str(args, "implements", "device");
-
-        resp = qtest_qmp(qts, "{'execute': 'qom-list-types', 'arguments': %p }",
-                         args);
-        g_assert(qdict_haskey(resp, "return"));
-        list = qdict_get_qlist(resp, "return");
-        qobject_ref(list);
-        qobject_unref(resp);
-
-        qtest_quit(qts);
-    }
-
-    for (p = qlist_first(list), idx = 0; p; p = qlist_next(p), idx++) {
-        devinfo = qobject_to(QDict, qlist_entry_obj(p));
-        g_assert(devinfo);
-
-        qobj = qdict_get(devinfo, "name");
-        g_assert(qobj);
-        qstr = qobject_to(QString, qobj);
-        g_assert(qstr);
-        if (g_str_equal(qstring_get_str(qstr), device)) {
-            return true;
-        }
-    }
-
-    return false;
+    return qtest_qom_has_concrete_type("device", device, &list);
 }
 
 /*
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Tue Jan 28 11:18:35 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 11:18:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878412.1288607 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcjc3-0001Yp-8H; Tue, 28 Jan 2025 11:18:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878412.1288607; Tue, 28 Jan 2025 11:18:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcjc3-0001Yg-5b; Tue, 28 Jan 2025 11:18:35 +0000
Received: by outflank-mailman (input) for mailman id 878412;
 Tue, 28 Jan 2025 11:18:34 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=p3hs=UU=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tcjc2-0000yw-Gw
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 11:18:34 +0000
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com
 [2a00:1450:4864:20::434])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9ba03b7c-dd69-11ef-99a4-01e77a169b0f;
 Tue, 28 Jan 2025 12:18:32 +0100 (CET)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-385d7b4da2bso5107134f8f.1
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 03:18:32 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38c2a18931esm14090518f8f.60.2025.01.28.03.18.31
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Tue, 28 Jan 2025 03:18:31 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9ba03b7c-dd69-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1738063112; x=1738667912; 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=PN2sEDLcal0RxGhKQBHLWKpiMjFeqeXkP17+0wDdg70=;
        b=a12zUEniaBT2058n/ao1lzhWP8Q9CwzP4esTbH9jH+89DRcxO9DI/uFNbyhiPtiUXT
         vUZla3RRX5+9FTeuipCkbAEuepRuPOyKsiTFCBfuFuzDkYjwJvTTeQ6W+wzK6ChRgErI
         HhVwRLVz/FU94Da0LT3Kgn1s+S9TB0NCy4G0MgVLy762ZvDl38Ds90KjFX6VG3GTYeHI
         nqqSs7PSxp/0w5sUPkOzpVmxDYA5UK19yghSosf6QBv1jHCIpTozbdLSBVRUl80whlBX
         gHJf57NYI/gxtaYeR6NvTSzOum2qVMqSaO7eL8nFrSnCOQhp2bK26AHEYPKbfau40AlI
         UQvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738063112; x=1738667912;
        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=PN2sEDLcal0RxGhKQBHLWKpiMjFeqeXkP17+0wDdg70=;
        b=NAPHKbL9JIlhXTd0I+dOBvkM3dtEjUl5k1umC8j+VBSgXuwG8kEjn5KNwZ0+MlTy9P
         /TkW+0hJEsmggQmKd6MzHaBgP+eMZ1eD3QRgkv4EOqw4Ep5FQ3Ycmevtt0sKMbr7mY7/
         Wuie1NGSSfgNC8+OkKuB+Weqyn3NBpZMw0H6eJ+w6nB5Nhrfn25zSxaKRNOk+mL9hFKz
         7j3/GeZKRp4ZZ057byswXp0Mf7Z30yuX7uaroR7Hm8ijbnZy70fTJKGKdQI925Et1K6/
         sKlPD0e7b6HU5dpk4yrJzXnPAmkKz0d2QAQUGBTHUgdwCjtShrn3Yv+FEuX040mUDRD8
         R8Fw==
X-Gm-Message-State: AOJu0YyeMKPPuccHWNWJ4LWkTCfT9JpV8booAmLXTjlY/49csLckx8YA
	TKzstk1/W8Atb/7PqOPA48+08RL1ZcdbcCpjaLQ3PVLgsNFXXRIFPLIwpq2F+SS6iMvfS+eQDbu
	QIqw=
X-Gm-Gg: ASbGncvWSO4l4X5/Rr6tiwCEv0DTR2Es2mo849uPDEE58R/SL8xGz6acLxwr4aCnc/x
	Qi0S4qc6s08ExlH0hZJ+LHEEEKOrRSzPyYJqL9rEG16zfqe+nYiI59Zsa1NnX312Dr8KGxJ2YJl
	FtfqLXh1t7TIKcBl0TFEWo/xzdxDJ4neDUzNZ+srp3cNGZmMqpd5EERzWG2kZoUJWlyqSot9xVF
	0BC6ScgInwOTyJWNJxWl00gOZcaQv8JY4m5lGv4FPnGJkVH6gCHAN8RJsKxIlZJGixXLHlgiulp
	/EmirZJudLOYU0UL+tKXXx8WDpmAdF2/65avbgMaeiG8mRShr2OMcvDNOr18ry8kcA==
X-Google-Smtp-Source: AGHT+IFWxgl1VusfEZKSGe4OFJyb0PxvJeiXznINSQNI0S+Gx4FvxU/nsmXT0fp2RgHAmqCcN0ELvw==
X-Received: by 2002:a5d:54ce:0:b0:38a:88ac:ed14 with SMTP id ffacd0b85a97d-38bf5659e26mr28903902f8f.19.1738063112306;
        Tue, 28 Jan 2025 03:18:32 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: xen-devel@lists.xenproject.org,
	=?UTF-8?q?Daniel=20P=20=2E=20Berrang=C3=A9?= <berrange@redhat.com>,
	Fabiano Rosas <farosas@suse.de>,
	Markus Armbruster <armbru@redhat.com>,
	Thomas Huth <thuth@redhat.com>,
	Laurent Vivier <lvivier@redhat.com>,
	Phil Dennis-Jordan <phil@philjordan.eu>,
	Bernhard Beschow <shentey@gmail.com>,
	Akihiko Odaki <akihiko.odaki@daynix.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
Subject: [PATCH 2/2] tests/qtest: Make qtest_has_accel() generic
Date: Tue, 28 Jan 2025 12:18:21 +0100
Message-ID: <20250128111821.93767-3-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250128111821.93767-1-philmd@linaro.org>
References: <20250128111821.93767-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Since commit b14a0b7469f ("accel: Use QOM classes for accel types")
accelerators are registered as QOM objects. Use QOM as a generic
API to query for available accelerators. This is in particular
useful to query hardware accelerators such HFV, Xen or WHPX which
otherwise have their definitions poisoned in "exec/poison.h".

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 tests/qtest/libqtest.c | 21 ++++++++++-----------
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/tests/qtest/libqtest.c b/tests/qtest/libqtest.c
index 7e9366ad6d5..3071dedeff6 100644
--- a/tests/qtest/libqtest.c
+++ b/tests/qtest/libqtest.c
@@ -30,6 +30,7 @@
 
 #include "libqtest.h"
 #include "libqmp.h"
+#include "qemu/accel.h"
 #include "qemu/ctype.h"
 #include "qemu/cutils.h"
 #include "qemu/sockets.h"
@@ -1030,13 +1031,10 @@ static bool qtest_qom_has_concrete_type(const char *parent_typename,
 
 bool qtest_has_accel(const char *accel_name)
 {
-    if (g_str_equal(accel_name, "tcg")) {
-#if defined(CONFIG_TCG)
-        return true;
-#else
-        return false;
-#endif
-    } else if (g_str_equal(accel_name, "kvm")) {
+    static QList *list;
+    g_autofree char *accel_type = NULL;
+
+    if (g_str_equal(accel_name, "kvm")) {
         int i;
         const char *arch = qtest_get_arch();
         const char *targets[] = { CONFIG_KVM_TARGETS };
@@ -1048,11 +1046,12 @@ bool qtest_has_accel(const char *accel_name)
                 }
             }
         }
-    } else {
-        /* not implemented */
-        g_assert_not_reached();
+        return false;
     }
-    return false;
+
+    accel_type = g_strdup_printf("%s%s", accel_name, ACCEL_CLASS_SUFFIX);
+
+    return qtest_qom_has_concrete_type("accel", accel_type, &list);
 }
 
 bool qtest_get_irq(QTestState *s, int num)
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Tue Jan 28 11:23:01 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 11:23:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878440.1288621 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcjg7-00047a-RF; Tue, 28 Jan 2025 11:22:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878440.1288621; Tue, 28 Jan 2025 11:22:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcjg7-00047T-O1; Tue, 28 Jan 2025 11:22:47 +0000
Received: by outflank-mailman (input) for mailman id 878440;
 Tue, 28 Jan 2025 11:22:46 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=mQvE=UU=kernel.org=joel.granados@srs-se1.protection.inumbo.net>)
 id 1tcjg6-00047L-K2
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 11:22:46 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 30cc1af1-dd6a-11ef-99a4-01e77a169b0f;
 Tue, 28 Jan 2025 12:22:43 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 3179E5C5D79;
 Tue, 28 Jan 2025 11:22:02 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 98109C4CEDF;
 Tue, 28 Jan 2025 11:22:41 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 30cc1af1-dd6a-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1738063362;
	bh=AJfDJn9pFkPItjs+l9CjDlC33TdlTCE01Kr4mfJIOJE=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=foTouGKI5Xpt6DiifiySGU1Px4B0JlxynZkL/A+4GJ+F1wUAFkM/N4G83a9sI8N06
	 lsMHA2F0I+BGkV1h4oylhwmSeJznMzbN+UJy9qwbYRK5QlpfqNfv8Msq/ndA/iDm4I
	 JYp3P2GR22dNEIcBnZOOATJGYPU+gMIFK9XfLLma3B24+UKToDLZL/ZLBF6bwp16qy
	 HMKr9svtYad8MrCuOMMF5t2I0WLB8bGS9HGYMu9w94+SD6sanYCztaTmP2cubx4D+F
	 lhSPEntAtoYhJR/j92VqRwE5MifEf7tNzvj9NQnTwv0sbHofELHMou005/QzH1lonP
	 yczCENnq4hKEA==
Date: Tue, 28 Jan 2025 12:22:37 +0100
From: Joel Granados <joel.granados@kernel.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: Jani Nikula <jani.nikula@intel.com>, Ard Biesheuvel <ardb@kernel.org>, 
	Alexander Gordeev <agordeev@linux.ibm.com>, Thomas =?utf-8?Q?Wei=C3=9Fschuh?= <linux@weissschuh.net>, 
	Kees Cook <kees@kernel.org>, Luis Chamberlain <mcgrof@kernel.org>, 
	linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, 
	linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-crypto@vger.kernel.org, 
	openipmi-developer@lists.sourceforge.net, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, 
	intel-xe@lists.freedesktop.org, linux-hyperv@vger.kernel.org, linux-rdma@vger.kernel.org, 
	linux-raid@vger.kernel.org, linux-scsi@vger.kernel.org, linux-serial@vger.kernel.org, 
	xen-devel@lists.xenproject.org, linux-aio@kvack.org, linux-fsdevel@vger.kernel.org, 
	netfs@lists.linux.dev, codalist@coda.cs.cmu.edu, linux-mm@kvack.org, 
	linux-nfs@vger.kernel.org, ocfs2-devel@lists.linux.dev, fsverity@lists.linux.dev, 
	linux-xfs@vger.kernel.org, io-uring@vger.kernel.org, bpf@vger.kernel.org, 
	kexec@lists.infradead.org, linux-trace-kernel@vger.kernel.org, 
	linux-hardening@vger.kernel.org, apparmor@lists.ubuntu.com, linux-security-module@vger.kernel.org, 
	keyrings@vger.kernel.org, Song Liu <song@kernel.org>, 
	"Steven Rostedt (Google)" <rostedt@goodmis.org>, "Martin K. Petersen" <martin.petersen@oracle.com>, 
	"Darrick J. Wong" <djwong@kernel.org>, Corey Minyard <cminyard@mvista.com>
Subject: Re: Re: Re: Re: [PATCH v2] treewide: const qualify ctl_tables where
 applicable
Message-ID: <u2fwibsnbfvulxj6adigla6geiafh2vuve4hcyo4vmeytwjl7p@oz6xonrq5225>
References: <20250110-jag-ctl_table_const-v2-1-0000e1663144@kernel.org>
 <Z4+jwDBrZNRgu85S@li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com>
 <nslqrapp4v3rknjgtfk4cg64ha7rewrrg24aslo2e5jmxfwce5@t4chrpuk632k>
 <CAMj1kXEZPe8zk7s67SADK9wVH3cfBup-sAZSC6_pJyng9QT7aw@mail.gmail.com>
 <f4lfo2fb7ajogucsvisfd5sg2avykavmkizr6ycsllcrco4mo3@qt2zx4zp57zh>
 <87jzag9ugx.fsf@intel.com>
 <Z5epb86xkHQ3BLhp@casper.infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Z5epb86xkHQ3BLhp@casper.infradead.org>

On Mon, Jan 27, 2025 at 03:42:39PM +0000, Matthew Wilcox wrote:
> On Mon, Jan 27, 2025 at 04:55:58PM +0200, Jani Nikula wrote:
> > You could have static const within functions too. You get the rodata
> > protection and function local scope, best of both worlds?
> 
> timer_active is on the stack, so it can't be static const.
> 
> Does this really need to be cc'd to such a wide distribution list?
That is a very good question. I removed 160 people from the original
e-mail and left the ones that where previously involved with this patch
and left all the lists for good measure. But it seems I can reduce it
even more.

How about this: For these treewide efforts I just leave the people that
are/were involved in the series and add two lists: linux-kernel and
linux-hardening.

Unless someone screams, I'll try this out on my next treewide.

Thx for the feedback

Best

-- 

Joel Granados


From xen-devel-bounces@lists.xenproject.org Tue Jan 28 11:26:07 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 11:26:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878449.1288630 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcjjA-0004gn-8b; Tue, 28 Jan 2025 11:25:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878449.1288630; Tue, 28 Jan 2025 11:25:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcjjA-0004gg-64; Tue, 28 Jan 2025 11:25:56 +0000
Received: by outflank-mailman (input) for mailman id 878449;
 Tue, 28 Jan 2025 11:25:54 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=jygh=UU=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcjj8-0004ga-My
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 11:25:54 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a297bd40-dd6a-11ef-a0e6-8be0dac302b0;
 Tue, 28 Jan 2025 12:25:53 +0100 (CET)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-aaf900cc7fbso893716566b.3
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 03:25:53 -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
 a640c23a62f3a-ab675e64dc9sm748993966b.45.2025.01.28.03.25.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 28 Jan 2025 03:25:52 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a297bd40-dd6a-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738063553; x=1738668353; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=y7alizwx7J2QvoqSYm3uLLAgdmTBOrfqVVpc9TAAhGc=;
        b=J1JqM8zFD1Ls+Xx/nFEsjQSOsh39NZVNAQzZQ4wuEA+iuovm85r0fa3NRYvgnJsNud
         MixgOapEN9A/hKZWIjeK0lGwc6oDJH5pYpzquanFW2YeOjtd0Tg0B40MhcXUTY1FDtqP
         oGoDDlhVX86I4tzN3EOevQd+32ritwpOA2+/OFEx9G3GX8d+CKl/T0cuaWKbOPvny7IT
         VELxpgGKvMFh41UJR5Xvd13rjHhv6VZyQGTiCMoNjA9h03W3fs3KJIUjQn1XfZl3XiKW
         i2+bX+NDqJxP/ZzUzn45vJcv72R2gxHitCQVxppNoMyUNsw5bsFdgZZIUPYsUUn4Reqe
         55uA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738063553; x=1738668353;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=y7alizwx7J2QvoqSYm3uLLAgdmTBOrfqVVpc9TAAhGc=;
        b=kA4xbb7Zxfh54VGptyUl+BZ7GD39UuftcdKegzwvqnG8bJhF44K/oenQRWpL73oh18
         OSrQAnhq+AOVZwNRNp+2p9Cidj7aNSCJQ/udPwe0KV0dC71tUB+qmKy8p4XIhvH7HsQ9
         66NHTIWmONdQ8xyICJ38BxiJIDo0Mjej63Qowfn7MNBkRhXpoWzW+Sk/lMaQCReAlKi9
         wm3N8OjGNqlSWRlpQ7+S3jYjWS4M9YG9gmnL9gdFXKrhs+awKCVWYhX/6PUuCqRMrJBB
         Dg43Dgm1jM3urPivjGWlEXRYphQyjlxYY72A/oHhwU9/ZbNnb4v/DWn2tA31rrHI8b3w
         sgYg==
X-Forwarded-Encrypted: i=1; AJvYcCUqakzeS4JoqVZ65zfWSQZYRaRsbqdJ0ag6J5qn1afRYCkqPe5fk+07F3jvOMn9/t7FFUTH0ZuEHC8=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy9Ol02cOoSPCXGGO2BAqTOkBEIrDjyzKO5LHtPg0SXcN0RyxBQ
	X0HGjvEZ6l+1Cv/1M6M64l6HZOGr9t0DkPFLGy813gzauX2NrtwZMNUJH9IjtQ==
X-Gm-Gg: ASbGncuqhZphXVI0MzJ5D1dseYpc8VIyyCIsn9AKsg9iJfT0RwFnxtcXKWb1oR49R9v
	LRq5cOlhDcrvmUqlEND/3rHk4Mwn+OJ+qxDlsTQtva1MaCJgNVm1AX5qYy63bd5SoeBCTzJefym
	3O1t3QyCyhYm/afJwjW2w9GAYN+sdWjCRLwaMilaXf8tFyz3Lg71sloq8iCZdIVaFc4+uOh6x3d
	E3oAIFpYu8yaLc3q9dJi3wBOm/V9zVD9S4zkNEulSRLJCIqQ9CdjOO+D49vynq/BH0sw0nsLhsQ
	GB4zY2s+uzQi7f60huYClzrVT0FgvPzrgkY5YbGf/W2+YlpnNMaWracLIqbWluwzKTzXWhK4hci
	p
X-Google-Smtp-Source: AGHT+IFfXgKhqmR147q665K0a9w0YOd8HjsmQQoybBCfk+lNeyfv5fEX/MEPgFHAzmIQW8KclvJbaA==
X-Received: by 2002:a17:907:7b9d:b0:ab3:2fbc:64d5 with SMTP id a640c23a62f3a-ab38b17b9bamr4193429366b.31.1738063553227;
        Tue, 28 Jan 2025 03:25:53 -0800 (PST)
Message-ID: <5036bb98-4acf-4cc2-80c0-6031742ae14a@suse.com>
Date: Tue, 28 Jan 2025 12:25:51 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 06/24] xen/domain: introduce hardware emulation flags
To: dmukhin@ford.com
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
 <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
 <20250103-vuart-ns8250-v3-v1-6-c5d36b31d66c@ford.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250103-vuart-ns8250-v3-v1-6-c5d36b31d66c@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04.01.2025 02:58, Denis Mukhin via B4 Relay wrote:
> --- /dev/null
> +++ b/xen/include/public/virtdev.h
> @@ -0,0 +1,61 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef XEN__PUBLIC_VIRTDEV_H
> +#define XEN__PUBLIC_VIRTDEV_H
> +
> +/*
> + * Domain hardware emulation flags.
> + */
> +enum {
> +    VIRTDEV_LAPIC      = 1U << 0,
> +    VIRTDEV_HPET       = 1U << 1,
> +    VIRTDEV_PM         = 1U << 2,
> +    VIRTDEV_RTC        = 1U << 3,
> +    VIRTDEV_IOAPIC     = 1U << 4,
> +    VIRTDEV_PIC        = 1U << 5,
> +    VIRTDEV_VGA        = 1U << 6,
> +    VIRTDEV_IOMMU      = 1U << 7,
> +    VIRTDEV_PIT        = 1U << 8,
> +    VIRTDEV_PIRQ       = 1U << 9,
> +    VIRTDEV_PCI        = 1U << 10,
> +};

Oh, also: "virt" both in the file name and in these enumerators doesn't
match the purpose (emulated devices), but could as well include para-
virtual devices then or, maybe, even SR-IOV pass-through ones.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 28 12:18:58 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 12:18:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878459.1288641 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tckYG-0004bm-69; Tue, 28 Jan 2025 12:18:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878459.1288641; Tue, 28 Jan 2025 12:18:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tckYG-0004bf-2q; Tue, 28 Jan 2025 12:18:44 +0000
Received: by outflank-mailman (input) for mailman id 878459;
 Tue, 28 Jan 2025 12:18:42 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Hs5b=UU=redhat.com=thuth@srs-se1.protection.inumbo.net>)
 id 1tckYE-0004bX-0e
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 12:18:42 +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 0098f244-dd72-11ef-99a4-01e77a169b0f;
 Tue, 28 Jan 2025 13:18:38 +0100 (CET)
Received: from mail-ej1-f72.google.com (mail-ej1-f72.google.com
 [209.85.218.72]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-561-xd-wPyHhMfK64Si5KekWaw-1; Tue, 28 Jan 2025 07:18:36 -0500
Received: by mail-ej1-f72.google.com with SMTP id
 a640c23a62f3a-aa689b88293so597960466b.3
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 04:18:35 -0800 (PST)
Received: from [192.168.0.7] (ip-109-42-50-234.web.vodafone.de.
 [109.42.50.234]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab6bd0afb93sm149916966b.128.2025.01.28.04.18.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 28 Jan 2025 04:18:34 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 0098f244-dd72-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1738066717;
	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=5n+WzSjjZga1/5dzHPwJh+sb0Qk6Ca3DIe5tAah4KKk=;
	b=auH9NutCYMGYvEyHx77vv6BPtiT4tAi6Hec3c9JMvK3Yty79FuS+StY6PlCXTjNFBwIJHy
	7XTsODkaONLr1e5NQyt0gtAT9pKobfA8RRYtuXpTjO3XcPcIV18fxILWvZNQtHPhCjYe4Q
	soaxdFroy5rhrjmSmKZu5pWrenqlYvg=
X-MC-Unique: xd-wPyHhMfK64Si5KekWaw-1
X-Mimecast-MFC-AGG-ID: xd-wPyHhMfK64Si5KekWaw
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738066715; x=1738671515;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=5n+WzSjjZga1/5dzHPwJh+sb0Qk6Ca3DIe5tAah4KKk=;
        b=f/7SDM6LKrAlc48wK4VpDWGwlcGaLrhMBpCUpmcIIcDxuJCh5qvvKIQyWNDkWAHO9+
         BR7EoZKYak2JYGAo0ek0N7kkRGUjw8axc/KrmPkPHR7ucSGv1UqwqFVY2HfADLLq52Qf
         h5mPsd3yMvGa7D+wu+d+Jy0eRYsDzGpjEXQ1LINYx0tmw8CV3mxfNtMDtn9l0s5ZJ07f
         1ChW6b/q0PKl2H2i+D63lSk070K/Pym1xYiKEi1I8+HUk7KWkP2zJYy64BuftjPSbMhe
         rYAx4b1esWp/HCNz5VTP/UTCzCpxl6hkUiVtaUtujWEqXfTa5RpQ7GWFPQZkTtHBbPcI
         PnJw==
X-Gm-Message-State: AOJu0YztQeVsIjXioKe2Zaj0K7IPSZvX5himMFi5NbDBTwwZY3/GWLdW
	rlErTi/fUvamfPomVYxMck4IQjeDc3cAceGR7gdylcdKdeMhSrQ+D1G9K/ZhK4VFiN17B05jBiK
	moQa7E/vuUo35n1S40ZL5xLXhLBMabKvD1A5q+Zi4AkRFc+WZ7jZcOWFtQ1Uqvet8
X-Gm-Gg: ASbGncvw2J+g/eVjBSvHqQ2kTuTF/pm/tBgkoe0+3L6NpSBm3WkWbFLan2XTEdKxox5
	KICFwLgK/sdnDrXBix30H0/DHFxAoGF9pJ6Fq0LBPSjAIEPa5Dih3QPVaL3EeIlVCRHtTKI89WM
	WmlF2R+nOoCQ2zX2U6WwLZ0P/baehAtWj0W4qNVU7cew5fjGA4PXpfn8ta0h9EaIqW6fYY9bo7d
	rxLxPqMmxEV1ujQNdhonJB5926yCD9TW5PEWLe1z4KJ3d8pgcsVYCvW7dvjGTLsFPUJZUYSgqt/
	a20kHfTBj5LJKXEZQ7Fk/CfuNOns5HBMENE6
X-Received: by 2002:a17:907:2da3:b0:aa6:83cc:7996 with SMTP id a640c23a62f3a-ab38b37eb86mr4119385266b.42.1738066714901;
        Tue, 28 Jan 2025 04:18:34 -0800 (PST)
X-Google-Smtp-Source: AGHT+IEPV1rzvwtGh/0owwTO1K12pEHLlm4LLq/EKPT+RrOmpKFZmOoxMbTgyLuoVeAf0osD9CBfRA==
X-Received: by 2002:a17:907:2da3:b0:aa6:83cc:7996 with SMTP id a640c23a62f3a-ab38b37eb86mr4119381666b.42.1738066714544;
        Tue, 28 Jan 2025 04:18:34 -0800 (PST)
Message-ID: <a29c4005-dea3-411d-8564-d79739a7befa@redhat.com>
Date: Tue, 28 Jan 2025 13:18:32 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] tests/qtest: Extract qtest_qom_has_concrete_type()
 helper
To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= <philmd@linaro.org>,
 qemu-devel@nongnu.org
Cc: xen-devel@lists.xenproject.org, =?UTF-8?Q?Daniel_P_=2E_Berrang=C3=A9?=
 <berrange@redhat.com>, Fabiano Rosas <farosas@suse.de>,
 Markus Armbruster <armbru@redhat.com>, Laurent Vivier <lvivier@redhat.com>,
 Phil Dennis-Jordan <phil@philjordan.eu>, Bernhard Beschow
 <shentey@gmail.com>, Akihiko Odaki <akihiko.odaki@daynix.com>,
 Paolo Bonzini <pbonzini@redhat.com>
References: <20250128111821.93767-1-philmd@linaro.org>
 <20250128111821.93767-2-philmd@linaro.org>
From: Thomas Huth <thuth@redhat.com>
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: <20250128111821.93767-2-philmd@linaro.org>
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: Jk_XiX7Du_yzbtlxFxT9orkpZWsaCiUMUEfYJM7oCPo_1738066715
X-Mimecast-Originator: redhat.com
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 28/01/2025 12.18, Philippe Mathieu-Daudé wrote:
> Extract qtest_qom_has_concrete_type() out of qtest_has_device()
> in order to re-use it in the following commit.
> 
> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> ---
>   tests/qtest/libqtest.c | 89 ++++++++++++++++++++++++------------------
>   1 file changed, 51 insertions(+), 38 deletions(-)

Reviewed-by: Thomas Huth <thuth@redhat.com>



From xen-devel-bounces@lists.xenproject.org Tue Jan 28 12:30:46 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 12:30:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878467.1288651 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tckjo-0007Sp-4q; Tue, 28 Jan 2025 12:30:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878467.1288651; Tue, 28 Jan 2025 12:30:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tckjo-0007Si-26; Tue, 28 Jan 2025 12:30:40 +0000
Received: by outflank-mailman (input) for mailman id 878467;
 Tue, 28 Jan 2025 12:30:39 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Hs5b=UU=redhat.com=thuth@srs-se1.protection.inumbo.net>)
 id 1tckjn-0007Sc-Dq
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 12:30:39 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.129.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id acb4f76f-dd73-11ef-a0e6-8be0dac302b0;
 Tue, 28 Jan 2025 13:30:37 +0100 (CET)
Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com
 [209.85.208.72]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-563-QhrWZrb3NseI9zkAom9gGA-1; Tue, 28 Jan 2025 07:30:34 -0500
Received: by mail-ed1-f72.google.com with SMTP id
 4fb4d7f45d1cf-5dc0de54194so5284009a12.0
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 04:30:34 -0800 (PST)
Received: from [192.168.0.7] (ip-109-42-50-234.web.vodafone.de.
 [109.42.50.234]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5dc2ea16e7asm4661486a12.42.2025.01.28.04.30.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 28 Jan 2025 04:30:24 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: acb4f76f-dd73-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1738067435;
	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=mwEdGeYwCVEf3va0CRehsDI0IO9aha2vG+WbTqnfbXg=;
	b=JUXFq2BPT8fiAUB/Q52OiusIKcMZH+XR0pIL0Z4h3OCkT95qs19urTu+52K7L6qEwehZIc
	rfH9aV1AOB1surtfzuVNSAIYR2SKCm4MS0RvKqBc4Bi3gZ7d22ygeSgfM+7sxaa0xGNu+5
	dp4bdhy+CZ6BNl6hl4YimDypfRHW9Oc=
X-MC-Unique: QhrWZrb3NseI9zkAom9gGA-1
X-Mimecast-MFC-AGG-ID: QhrWZrb3NseI9zkAom9gGA
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738067433; x=1738672233;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :from:references:cc:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=mwEdGeYwCVEf3va0CRehsDI0IO9aha2vG+WbTqnfbXg=;
        b=vWodI8ZkcMx2Afn0P/+WWog/NFoeEfxuONXTMUg7b18Xm0rDUWk8Xajdi20hCRYEmS
         tQ4j6YzAWfXSpLin+ER4XShd9QFBm7KZfNW3kq63G7N8AHEri/B0ISU32trWUg5FmgPI
         nfwwWLMBCK/RDhLz6JoJJ+OiJZAfXPYXO9RAx/FG+M1eHHjMTpcw+txKv79FBCg7pp0g
         Jx3Eqn48m4Aro8nVF3y2uwvr6kpu1MHclUU2nQsfo8lIvcGxcaX8qGTGQTguM40T1PJl
         6WymS27oAZJA3tJEHQOv2iDNQ/QqyTYaYUR+EsDJAtv8YtNNWcqnQpMVG02ZrE3xZ2Gp
         z6fQ==
X-Gm-Message-State: AOJu0Yz78JPfPNcQw2nUgnWMjGrELZy1ihM94ysBsBXNNulPdGSirjcA
	Qo1frMRm1vn3qIS2yEI1uJq0wuy359x7/56AeQzFGG8G91zRMppdHKqLKl04CrBzGCXnE3i2Z4f
	sc3r7/d+e3Dtr7M3GLClS1sP1NPa68LeNJ4KPvTotPmT51+YxQj9GpXPGP7XEyzUY
X-Gm-Gg: ASbGncuiJrwCjLwQGOX9dT26ZmC2i3h4I+J1oH0cTg8D9gdihjVPfrDqRkYgXQJXNPg
	YgkcqHaALhC8/Vc9ZjlMSfMRQ8wUQVrmUjRPj196JPrw2kMhnhP8phUP9CCOCF7whAI4FL0xzmn
	zSH7T0xj4MP/8OAEeoV0VQy6uoZzSBjwsr/fsk3old9x1TYembQYseBLbJlnfnqCUNOLLdp29Lv
	t2srh4fIk83izcZ8WsXQ1uzrWBzGFtmg9ME2/RBY0I4nCxVICpcEohrye9hYb2OXhL5lfya1JMS
	Q2SXu9AYPnhNMaFSCl7d3r+cf67SRlzVQrYy
X-Received: by 2002:a05:6402:1e8f:b0:5dc:eb2:570d with SMTP id 4fb4d7f45d1cf-5dc4fd1153emr4070528a12.2.1738067430204;
        Tue, 28 Jan 2025 04:30:30 -0800 (PST)
X-Google-Smtp-Source: AGHT+IHE5zcsdFqOnxwXJMHoRt5avby+/62eopuGkbdjyfNCDtaIa+EgX1nN8lJkWB9mowl6EBIMVA==
X-Received: by 2002:a05:6402:1e8f:b0:5dc:eb2:570d with SMTP id 4fb4d7f45d1cf-5dc4fd1153emr4070158a12.2.1738067424760;
        Tue, 28 Jan 2025 04:30:24 -0800 (PST)
Message-ID: <8da6ca8d-9819-4f4c-9131-f9fcf498d86d@redhat.com>
Date: Tue, 28 Jan 2025 13:30:22 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/2] tests/qtest: Make qtest_has_accel() generic
To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= <philmd@linaro.org>,
 qemu-devel@nongnu.org
Cc: xen-devel@lists.xenproject.org, =?UTF-8?Q?Daniel_P_=2E_Berrang=C3=A9?=
 <berrange@redhat.com>, Fabiano Rosas <farosas@suse.de>,
 Markus Armbruster <armbru@redhat.com>, Laurent Vivier <lvivier@redhat.com>,
 Phil Dennis-Jordan <phil@philjordan.eu>, Bernhard Beschow
 <shentey@gmail.com>, Akihiko Odaki <akihiko.odaki@daynix.com>,
 Paolo Bonzini <pbonzini@redhat.com>
References: <20250128111821.93767-1-philmd@linaro.org>
 <20250128111821.93767-3-philmd@linaro.org>
From: Thomas Huth <thuth@redhat.com>
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: <20250128111821.93767-3-philmd@linaro.org>
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: SMHGwCQYYMjSoJOb7wvvpr-WcqXPpeMZkZFNrORyqEY_1738067433
X-Mimecast-Originator: redhat.com
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 28/01/2025 12.18, Philippe Mathieu-Daudé wrote:
> Since commit b14a0b7469f ("accel: Use QOM classes for accel types")
> accelerators are registered as QOM objects. Use QOM as a generic
> API to query for available accelerators. This is in particular
> useful to query hardware accelerators such HFV, Xen or WHPX which
> otherwise have their definitions poisoned in "exec/poison.h".
> 
> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> ---
>   tests/qtest/libqtest.c | 21 ++++++++++-----------
>   1 file changed, 10 insertions(+), 11 deletions(-)
> 
> diff --git a/tests/qtest/libqtest.c b/tests/qtest/libqtest.c
> index 7e9366ad6d5..3071dedeff6 100644
> --- a/tests/qtest/libqtest.c
> +++ b/tests/qtest/libqtest.c
> @@ -30,6 +30,7 @@
>   
>   #include "libqtest.h"
>   #include "libqmp.h"
> +#include "qemu/accel.h"
>   #include "qemu/ctype.h"
>   #include "qemu/cutils.h"
>   #include "qemu/sockets.h"
> @@ -1030,13 +1031,10 @@ static bool qtest_qom_has_concrete_type(const char *parent_typename,
>   
>   bool qtest_has_accel(const char *accel_name)
>   {
> -    if (g_str_equal(accel_name, "tcg")) {
> -#if defined(CONFIG_TCG)
> -        return true;
> -#else
> -        return false;
> -#endif
> -    } else if (g_str_equal(accel_name, "kvm")) {
> +    static QList *list;
> +    g_autofree char *accel_type = NULL;
> +
> +    if (g_str_equal(accel_name, "kvm")) {
>           int i;
>           const char *arch = qtest_get_arch();
>           const char *targets[] = { CONFIG_KVM_TARGETS };
> @@ -1048,11 +1046,12 @@ bool qtest_has_accel(const char *accel_name)
>                   }
>               }
>           }
> -    } else {
> -        /* not implemented */
> -        g_assert_not_reached();
> +        return false;
>       }
> -    return false;
> +
> +    accel_type = g_strdup_printf("%s%s", accel_name, ACCEL_CLASS_SUFFIX);
> +
> +    return qtest_qom_has_concrete_type("accel", accel_type, &list);
>   }

Nice!

Reviewed-by: Thomas Huth <thuth@redhat.com>



From xen-devel-bounces@lists.xenproject.org Tue Jan 28 12:47:42 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 12:47:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878477.1288665 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcl0B-0001EQ-HF; Tue, 28 Jan 2025 12:47:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878477.1288665; Tue, 28 Jan 2025 12:47:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcl0B-0001EJ-EQ; Tue, 28 Jan 2025 12:47:35 +0000
Received: by outflank-mailman (input) for mailman id 878477;
 Tue, 28 Jan 2025 12:47:34 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=WhQb=UU=amd.com=Michal.Orzel@srs-se1.protection.inumbo.net>)
 id 1tcl0A-0001ED-6j
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 12:47:34 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on2061b.outbound.protection.outlook.com
 [2a01:111:f403:2417::61b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0943e6fa-dd76-11ef-99a4-01e77a169b0f;
 Tue, 28 Jan 2025 13:47:31 +0100 (CET)
Received: from BN1PR13CA0002.namprd13.prod.outlook.com (2603:10b6:408:e2::7)
 by MN0PR12MB5787.namprd12.prod.outlook.com (2603:10b6:208:376::9) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.18; Tue, 28 Jan
 2025 12:47:26 +0000
Received: from BN3PEPF0000B371.namprd21.prod.outlook.com
 (2603:10b6:408:e2:cafe::55) by BN1PR13CA0002.outlook.office365.com
 (2603:10b6:408:e2::7) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8398.16 via Frontend Transport; Tue,
 28 Jan 2025 12:47:26 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN3PEPF0000B371.mail.protection.outlook.com (10.167.243.168) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8398.0 via Frontend Transport; Tue, 28 Jan 2025 12:47:25 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 28 Jan
 2025 06:47:23 -0600
Received: from [10.71.192.184] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Tue, 28 Jan 2025 06:47:22 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 0943e6fa-dd76-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=rqID3iwABaaDsz0PXiQ6z2StZqt4xjFneudxCUtVeI3ha69dbht1QenGw311DsChHTXJ+ppJLsnAzZgl+9W86Jn4MCW/4FXLeGywkG7gXk/QO2QlrO7i4ctLMIJVxOusOPg6uRkneR8iUnwQKyIRe7Jw8c8thd9/ai5EQSJxnAG2synf7y6WTo5LuIJGTmNbjkiasqbPMmZvREKQTy857NTylE9vean9InBqNijk8pbCTvyza3xpnV9zvhCHaQ8wzWpiQjB7masBdwkDuSKu1HDlVGU5uvVbQpySX8qEbT01dpFakHNEfmoLZLMxKo8SqMWUmxzpYMRZQ9QFSSsGRA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=DhPMKeECd02T38yDKxfsOGlxSn4aHlbIGrUoYAI3mDg=;
 b=hAKqrsUjNPGxsMMb/wpAG1ddk6T4OiEZK5cYZMC/KOMSZwdf36cmO8RUZckqvt6+eNqkHatOa7+q0lLHYzF1y0jJ/3OMcdW3Wl65KZpVJkF9dpyq1l8cyMoM/8u3Cm2qJAF2szyRw9DRF2AVt+9nbu9VJfGBJZqyMIIe/XHml5bisOQlSjjpodxQCzNg2RERNl7rCShkWyhp14Zn/q7Y4n+paQcgYpVX5rI39LIOKGgFq7vP4RhgIF/bUbHp8sozisn/oHA8T+2ClVemSjCC6Kuyp+fsSsuXZR4OEX9Cbxsh108CozZO8r4hNKgIUQZwxJTFmrjcztIaQbZ3DpKAFA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=DhPMKeECd02T38yDKxfsOGlxSn4aHlbIGrUoYAI3mDg=;
 b=Idoi+F9VSXHWQL16hTV8Iy01HwC4KQfFCjSGiwY3QFbWo+FUJIZyT89/PNCLch8SJNcm/+yJqqdJh8gwVQYEt1wc2tLVg8F3fvQgtVyQs/DlX1YJwlyj85VPETc/DfJuNYJnMw75hTU8tGZkWYS+ie/Qa7zyhxhvZKQxwOEVZ3c=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <18a57617-7ae5-4a7d-a7b6-61cd5643ff22@amd.com>
Date: Tue, 28 Jan 2025 13:47:22 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [for-4.20][PATCH v2 1/2] device-tree: bootfdt: Fix build issue
 when CONFIG_PHYS_ADDR_T_32=y
To: Luca Fancellu <Luca.Fancellu@arm.com>, Julien Grall <julien@xen.org>
CC: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Stefano
 Stabellini <sstabellini@kernel.org>, Bertrand Marquis
	<Bertrand.Marquis@arm.com>, "oleksii.kurochko@gmail.com"
	<oleksii.kurochko@gmail.com>
References: <20250128094002.145755-1-michal.orzel@amd.com>
 <20250128094002.145755-2-michal.orzel@amd.com>
 <4A4FAE76-59FF-4DBD-92A7-5158B0404C7F@arm.com>
Content-Language: en-US
From: Michal Orzel <michal.orzel@amd.com>
In-Reply-To: <4A4FAE76-59FF-4DBD-92A7-5158B0404C7F@arm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Received-SPF: None (SATLEXMB04.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN3PEPF0000B371:EE_|MN0PR12MB5787:EE_
X-MS-Office365-Filtering-Correlation-Id: 8ec32337-8ce1-40b0-6994-08dd3f99eae6
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|36860700013|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?NE5OanpzQzNhSUVBUGEwMnBMamp2QlFhN2QrZnphdlJUWHVIVTl4ZmEyYS95?=
 =?utf-8?B?K2ZxY1FGQm9sdXBrSnpWZGhIRUNia1U2L3EzOHE2YlJCVVVVYldWOG9DNVN2?=
 =?utf-8?B?UFBSWXhaUVRWUC9PZGFrZmlNSHFTUHRadGlEaVRwMjF0Ymg3WUEzWks1Yk5Q?=
 =?utf-8?B?R3N0c1hTcHU2ZnlNTGhVK2t3Q3dMdkRYcW0wQTA5dXV6T0kyWVRUbGNKa3p0?=
 =?utf-8?B?T1Y2czB1RHY3WExzbVhxcklkL2JlUXZhREVXcVgrWWpvNDFCeFM3bVRLeTEr?=
 =?utf-8?B?azBBVjBkVE92MWF3eGw2YndaTGFMRVFjbXVWbE92VUJSNkwzakk4cFdtWWRX?=
 =?utf-8?B?WERkZlBHWGtRemNqYVUxaGorY2luY3ZmOUdzbmlSbzBWVXkvMXNpODdMbEZu?=
 =?utf-8?B?VmZzbG9INUl0TWt2dVlrVDYzTXR3eDZnK0tqaDVtRXNTMndHMFp4dTVtdVhJ?=
 =?utf-8?B?UmFBNFplYUh3QTZPdmtabCtjY3VScndrRG03Z094bzhJcktMenN2ZzM0VzVK?=
 =?utf-8?B?cVl4VHYxdTdUSDZiR2svUHRWZzFmR1dwSTUrcVp6MlFKV2M0ckp5VllhMHZS?=
 =?utf-8?B?eUMyVUc1VFFCbmIyazNiS1FzT2hMNWJUV3ZxbUZXaEFOMzRBbGZMZ0FoL1pB?=
 =?utf-8?B?YmRNWkxQNkhkVldnWDhOcFhQMTllMUxSRzM4eXduY1lWSVJueU5mZGhsMTJq?=
 =?utf-8?B?bFRtWER1NThtUHBoUGI1bEw4MU05OHk4V0lBb0FIUjFhY0VEWlhSY1hGalFM?=
 =?utf-8?B?Uk9LNG5SZm1GVkxIOHU3UnFvc0dDN1R3TTU2cG5NcVJHZWNGa2RES0VOdnRM?=
 =?utf-8?B?V1FUaDdVNUJaZUxpZkNxR0dzdlBsVElSVU9Sc1d4T3FDS25zMHp0bWVDZFRN?=
 =?utf-8?B?WVNMdVBGVXN3b3ZlZ095LzNTTzRKNkxpWCtYTXBoZzVkU3hDMEZ2eXQwdGJa?=
 =?utf-8?B?ZmdXWXhjb3JOVGdFK1ROWE44UWhTYU1tVWJPdkgrZHlPblczeFBvbmpEUHpO?=
 =?utf-8?B?NWFST3I4dDBuYk9POG0waTRJbjYzSFZMcG5lRFlKMVpocHI4a0FOZkNZam9R?=
 =?utf-8?B?V3FpWmFpN3o1bjNKWElOMDhEbkZIekdkVjdVTktaaVhwVm4yd25YdnJqcVNL?=
 =?utf-8?B?WnRpZFZuRHloR0ZvSlNNOWxCYUpXdjdzblZmQnYrc3ZSR3l5M3FWR3BmOEps?=
 =?utf-8?B?VUpVN3gzdTFnbStQejQwWXo5YkI5OG5ubytKWGYrS1c0NWN3SDZrOHFkSVI0?=
 =?utf-8?B?eGxyMUZhTTl0aHV4ejg4ejd6T0YrTzNML3h6OS9NVSs2VDFFdHQwdjlkVFZR?=
 =?utf-8?B?TlVkZFN3cUZUQkIra0x1OHZRUTBaNWQwUGtzRlU5T3lQWitpbjNkNDRYUWJS?=
 =?utf-8?B?eGM0S2lxQW1wdzZsdHd3TUNQbndYWkQySHhmT0lTcFlPL1NEWEZVT1ltS05w?=
 =?utf-8?B?c2t4dllDdEpwRHptcUc4S2RuZWlHbkJKM3VZSjJRdXhGNzhnMlVhbmx6Q1R3?=
 =?utf-8?B?blo4QXNxWjZ5cWI0T1M4K2t6MWpqdzJuWjVhMmpvb2ZnTW9MTUs5L01Hd3pL?=
 =?utf-8?B?SnQrbktPTlhSMzNDZGN2OHFZNVB5YjdLREFFWm51WnlBcmQrQnZhZk5saTZn?=
 =?utf-8?B?RzR1OFpvVzZjRTgrdDZocDFXdDkvdW96d2lZTWJHUTliemVyTTUwaGFha3J3?=
 =?utf-8?B?TkJPRVBUSDZoRVlRd2RjUEVwd1NsdHByQXB3bm9RZTFWUFBJdlhKQlhjckww?=
 =?utf-8?B?M3lsWXpoeExTNHFwTkVsOU5aWkVRQWtsMlhXZHBsNVhyOG1QSzEzamgvWHFF?=
 =?utf-8?B?OGMwWTU3YnNmMHRlTllCbEs0bnhOaEpQcVJ6YU5iYzQyZE1yUHc0S3hLd2ln?=
 =?utf-8?B?QU1RZG5Ed2I5T1ZNaXEyNTRzM1lWTk1ocU05WlY1VzRtU2NqbnRtOXI0QkYy?=
 =?utf-8?B?QlJuM3duWTU4YVI4MHBOQXNyWGVTbUpEWThrMWxRYTU3anhZOEQ4WlpWdGJB?=
 =?utf-8?Q?4oB/NNxb32oGbVTyu42hvnykQmysyk=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(376014)(36860700013)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2025 12:47:25.9212
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 8ec32337-8ce1-40b0-6994-08dd3f99eae6
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN3PEPF0000B371.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB5787



On 28/01/2025 11:34, Luca Fancellu wrote:
> 
> 
> Hi Michal, Julien,
> 
>> On 28 Jan 2025, at 09:40, Michal Orzel <michal.orzel@amd.com> wrote:
>>
>> On Arm32, when CONFIG_PHYS_ADDR_T_32 is set, a build failure is observed:
>> common/device-tree/bootfdt.c: In function 'build_assertions':
>> ./include/xen/macros.h:47:31: error: static assertion failed: "!(alignof(struct membanks) != 8)"
>>   47 | #define BUILD_BUG_ON(cond) ({ _Static_assert(!(cond), "!(" #cond ")"); })
>>      |                               ^~~~~~~~~~~~~~
>> common/device-tree/bootfdt.c:31:5: note: in expansion of macro 'BUILD_BUG_ON'
>>   31 |     BUILD_BUG_ON(alignof(struct membanks) != 8);
>>
>> When CONFIG_PHYS_ADDR_T_32 is set, paddr_t is defined as unsigned long,
>> therefore the struct membanks alignment is 4B and not 8B. The check is
>> there to ensure the struct membanks and struct membank, which is a
>> member of the former, are equally aligned. Therefore modify the check to
>> compare alignments obtained via alignof not to rely on hardcoded
>> values.
>>
>> Fixes: 2209c1e35b47 ("xen/arm: Introduce a generic way to access memory bank structures")
>> Signed-off-by: Michal Orzel <michal.orzel@amd.com>
>> Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
>> ---
>> Changes in v2:
>> - modify the check to test against alignment of struct membank
>> ---
>> xen/common/device-tree/bootfdt.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c
>> index 47386d4fffea..529c91e603ab 100644
>> --- a/xen/common/device-tree/bootfdt.c
>> +++ b/xen/common/device-tree/bootfdt.c
>> @@ -27,8 +27,8 @@ static void __init __maybe_unused build_assertions(void)
>>      */
>>     BUILD_BUG_ON((offsetof(struct membanks, bank) !=
>>                  offsetof(struct meminfo, bank)));
>> -    /* Ensure "struct membanks" is 8-byte aligned */
>> -    BUILD_BUG_ON(alignof(struct membanks) != 8);
>> +    /* Ensure "struct membanks" and "struct membank" are equally aligned */
>> +    BUILD_BUG_ON(alignof(struct membanks) != alignof(struct membank));
> 
> Apologies for not catching the issue for your v1, probably I didn't understand very well the test itself,
> why are we checking that the structure have the same alignment?
> I see we check the offset of `(struct membanks).bank` against `(struct meminfo|struct shared_meminfo).bank`,
> isn't that enough?
> For sure I’m missing something...
In my understanding it's to prevent issues when casting between these structures. It's not that FAM (flexible array member)
requires the same alignment but if you consider casting this member to a type with a stricter alignment requirement you may
encounter alignment issues.

> 
> Anyway I tested this:
> 
> Tested-by: Luca Fancellu <luca.fancellu@arm.com>
> 

~Michal


From xen-devel-bounces@lists.xenproject.org Tue Jan 28 12:57:32 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 12:57:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878488.1288674 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcl9k-00036K-Fu; Tue, 28 Jan 2025 12:57:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878488.1288674; Tue, 28 Jan 2025 12:57:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcl9k-00036D-DM; Tue, 28 Jan 2025 12:57:28 +0000
Received: by outflank-mailman (input) for mailman id 878488;
 Tue, 28 Jan 2025 12:57:27 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=IPSL=UU=eik.bme.hu=balaton@srs-se1.protection.inumbo.net>)
 id 1tcl9j-000367-4e
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 12:57:27 +0000
Received: from zero.eik.bme.hu (zero.eik.bme.hu [2001:738:2001:2001::2001])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6b3218fb-dd77-11ef-a0e6-8be0dac302b0;
 Tue, 28 Jan 2025 13:57:25 +0100 (CET)
Received: from zero.eik.bme.hu (localhost [127.0.0.1])
 by zero.eik.bme.hu (Postfix) with ESMTP id 7D45F4E6029;
 Tue, 28 Jan 2025 13:57:23 +0100 (CET)
Received: from zero.eik.bme.hu ([127.0.0.1])
 by zero.eik.bme.hu (zero.eik.bme.hu [127.0.0.1]) (amavisd-new, port 10028)
 with ESMTP id 3uK6LJmOcV0F; Tue, 28 Jan 2025 13:57:21 +0100 (CET)
Received: by zero.eik.bme.hu (Postfix, from userid 432)
 id 811C44E6027; Tue, 28 Jan 2025 13:57:21 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
 by zero.eik.bme.hu (Postfix) with ESMTP id 7E1B874577C;
 Tue, 28 Jan 2025 13:57:21 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 6b3218fb-dd77-11ef-a0e6-8be0dac302b0
X-Virus-Scanned: amavisd-new at eik.bme.hu
Date: Tue, 28 Jan 2025 13:57:21 +0100 (CET)
From: BALATON Zoltan <balaton@eik.bme.hu>
To: Peter Maydell <peter.maydell@linaro.org>
cc: Gerd Hoffmann <kraxel@redhat.com>, 
    =?ISO-8859-15?Q?Philippe_Mathieu-Daud=E9?= <philmd@linaro.org>, 
    qemu-devel@nongnu.org, Yi Liu <yi.l.liu@intel.com>, 
    Markus Armbruster <armbru@redhat.com>, 
    Eduardo Habkost <eduardo@habkost.net>, 
    Anthony PERARD <anthony@xenproject.org>, 
    Gustavo Romero <gustavo.romero@linaro.org>, 
    Jason Wang <jasowang@redhat.com>, qemu-ppc@nongnu.org, 
    "Michael S. Tsirkin" <mst@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>, 
    Alexander Graf <graf@amazon.com>, 
    Richard Henderson <richard.henderson@linaro.org>, 
    Stefan Berger <stefanb@linux.vnet.ibm.com>, 
    Bernhard Beschow <shentey@gmail.com>, 
    Stefano Stabellini <sstabellini@kernel.org>, 
    =?ISO-8859-15?Q?Daniel_P=2E_Berrang=E9?= <berrange@redhat.com>, 
    "Edgar E. Iglesias" <edgar.iglesias@gmail.com>, 
    xen-devel@lists.xenproject.org, 
    Marcel Apfelbaum <marcel.apfelbaum@gmail.com>, 
    Alex Williamson <alex.williamson@redhat.com>, Paul Durrant <paul@xen.org>, 
    =?ISO-8859-15?Q?Cl=E9ment_Mathieu--Drif?= <clement.mathieu--drif@eviden.com>, 
    =?ISO-8859-15?Q?C=E9dric_Le_Goater?= <clg@redhat.com>
Subject: Re: [PATCH 0/9] hw/sysbus/platform-bus: Introduce
 TYPE_DYNAMIC_SYS_BUS_DEVICE
In-Reply-To: <CAFEAcA-QOYcnJi=joKHbRmUCXK1UFOgQRgYP-fDq4h_1SkMGyQ@mail.gmail.com>
Message-ID: <2893a552-ca6c-01c4-dcc0-6107ccf1c7b5@eik.bme.hu>
References: <20250125181343.59151-1-philmd@linaro.org> <wkb53fhvfchqa4uvmifgitvcr7t7rfpc3hcohdhzczkzvktetx@yjveswjel3s4> <CAFEAcA-QOYcnJi=joKHbRmUCXK1UFOgQRgYP-fDq4h_1SkMGyQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="3866299591-275533675-1738069041=:16171"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--3866299591-275533675-1738069041=:16171
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT

On Tue, 28 Jan 2025, Peter Maydell wrote:
> On Tue, 28 Jan 2025 at 10:42, Gerd Hoffmann <kraxel@redhat.com> wrote:
>>
>> On Sat, Jan 25, 2025 at 07:13:34PM +0100, Philippe Mathieu-Daudé wrote:
>>> Some SysBus devices can optionally be dynamically plugged onto
>>> the sysbus-platform-bus (then virtual guests are aware of
>>> mmio mapping and IRQs via device tree / ACPI rules).
>>
>> Do we have some sane way to have user-pluggable sysbus devices on arm?
>
> The answer in a general sense is "no, because user pluggable
> sysbus is a weird idea". "sysbus" means "it's wired into a
> specific bit of the memory map and to specific IRQs, and whoever
> does that needs to know what IRQs and bits of memory are usable,
> and the guest OS needs to know it's there". "user-pluggable" means
> "it's all automatic and the guest can just do some kind of
> probing for what is or isn't present". All the platform bus stuff
> is a nasty mess that's working around the things people want
> to plug in not being clean devices on probeable buses :-(
> And the platform bus is only supported on the "virt" board,
> because that's the only one where QEMU is generating its
> own dtb or ACPI tables where it can tell the guest "hey,
> there's some device here".

There are some SoCs that have memory mapped devices but different versions 
in the same family have different devices. Either older ones missing some 
devices or have less USB or network ports while newer SoCs have more of 
those or they have PCIe instead of PCI. Modelling these could use 
pluggable sysbus devices so one could add the devices needed for a SoC 
version without having to write or modify a board code. I think Bernhard's 
attempt to try creating e500 SoCs from a device tree goes in that 
direction too. We could also model this by having a SoC that can 
instantiate devices based on some properties but maybe pluggable devices 
could be more generic for this. The issue seems to be how to tell the 
board or SoC where to map it and what IRQ to connect it as this is done by 
the board and not the device so properties on the device to set these does 
not really help unless the board can somehow query it and instantiate the 
devices based on that. Otherwise whatever handles the -device option to 
create the device would need knowledge about the board. (E.g. the e500 
devices are mapped in the CCSR memory region so one can't just use system 
address space for them.)

Regards,
BALATON Zoltan
--3866299591-275533675-1738069041=:16171--


From xen-devel-bounces@lists.xenproject.org Tue Jan 28 14:16:33 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 14:16:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878498.1288684 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcmO4-0004kt-3O; Tue, 28 Jan 2025 14:16:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878498.1288684; Tue, 28 Jan 2025 14:16:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcmO4-0004km-04; Tue, 28 Jan 2025 14:16:20 +0000
Received: by outflank-mailman (input) for mailman id 878498;
 Tue, 28 Jan 2025 14:16:18 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=SSIY=UU=aepfle.de=olaf@srs-se1.protection.inumbo.net>)
 id 1tcmO1-0004kd-Rx
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 14:16:18 +0000
Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de
 [85.215.255.21]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6e01e073-dd82-11ef-99a4-01e77a169b0f;
 Tue, 28 Jan 2025 15:16:13 +0100 (CET)
Received: from sender by smtp.strato.de (RZmta 51.2.17 AUTH)
 with ESMTPSA id D0534410SEFrwAY
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits))
 (Client did not present a certificate);
 Tue, 28 Jan 2025 15:15:53 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 6e01e073-dd82-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; t=1738073753; cv=none;
    d=strato.com; s=strato-dkim-0002;
    b=SOyMQAtIzj+RwSIcSg6QjiBnex3xT1Ok5vYE8Jag6yer446ZEiuZ4BgL5U7zBnAv/X
    GueasaoSUJqeup+3hol84AS4h3VQfaVKyIBusPFY1v9Hk3lbzupHovqfr3g1jathHEQH
    z9KXzncSzZAMiYxk8dtNWF1BmfS03rEs5w8HpukKXMnwzZfypNCVRkyn67Rnf1GY9T1W
    M9xhWMSSVwOqPKKbi/GuN9xkZ0cHzxvxRn7Xvpe0BAjFsD33TExNugCMzErwk7VgoORd
    QNG22PxZAYeD2XG26JwL9jsVlDaF9bjrbp5SyDt2eWDZkVRvNCRi/LG4S7ouPO8IU+HB
    fMGA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1738073753;
    s=strato-dkim-0002; d=strato.com;
    h=Message-ID:Subject:Cc:To:From:Date:Cc:Date:From:Subject:Sender;
    bh=6+FFDMnFMkrA8wSKIFiEbNLT+sTX2ENPHcGK1OU85ZQ=;
    b=GaMGSgR7TgkvNQEH34iKmvWlh3A08beaWVaHay+wwgxNFHSLR9tY9/FVXDc6gI2F5w
    408zIR7x9bTOt5MR/fp/9BUyKgagiXM6VbaIQjaoM7UDYZpm06VztaDmrhOFuMIL+q3I
    qgkjv30wXjCiz1Jfh2AfvTytF2Wcq5Ilz7SVDMHK8JXtg4BxIeOzZZQ/pQYpWHrwnoNe
    XV2VYK6i2Kkg153S33aB2Mfea58mqcbPN7zNMGXZK34gQzyA6bJ7HICcPxWVhhw2p2xR
    iyrli/a9W5QJQ2Cqege7eKZzMqdHqMqVQi3Ehcqymar4yNtjMmJxkWbOdM4TDudMqbn5
    8KRw==
ARC-Authentication-Results: i=1; strato.com;
    arc=none;
    dkim=none
X-RZG-CLASS-ID: mo00
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1738073753;
    s=strato-dkim-0002; d=aepfle.de;
    h=Message-ID:Subject:Cc:To:From:Date:Cc:Date:From:Subject:Sender;
    bh=6+FFDMnFMkrA8wSKIFiEbNLT+sTX2ENPHcGK1OU85ZQ=;
    b=E+Tv7aCOWB1/OhUhrS7xsRQeiH6XduGJG+OuK3jutS/X00zL1caFicCfrlYUWh7WFr
    jOk8eFqiPQiNwIKsL4dNulrHtSI5WWfllInD8bH4A2JYfSc/CDo5EucwGnuM0hzEh4+z
    +dBoibm5+NcCRSVbO7Pn345BHv5O0Fwy+dvQaqdRGZ30hXsyqCS6pproEjy/44AVHjlB
    WiFXCG9PWv3z89OcxU5auFwghC/ZPJYf9Ye20snA7atfgbhbxvXSr0jWdZX+SE9eXV5j
    0ECv6Xa8bksz2qNRXReEpINrt5BXDsORl3CcefL4UKniQlGRVE+78W+CC0Nqj87Zvl0k
    a37w==
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1738073753;
    s=strato-dkim-0003; d=aepfle.de;
    h=Message-ID:Subject:Cc:To:From:Date:Cc:Date:From:Subject:Sender;
    bh=6+FFDMnFMkrA8wSKIFiEbNLT+sTX2ENPHcGK1OU85ZQ=;
    b=DTnr2/AyUXOJF0komU3MnoVlPvFGTpzEJDnPfFNnYS4WnGzIPUdTAiJvSdrNQwZY7p
    3DSVayn8QMVlPaQJk9CA==
X-RZG-AUTH: ":P2EQZWCpfu+qG7CngxMFH1J+3q8wa/QLpd5ylWvMDX3y/OmD4uXd0fmxSoJ8/RK6b07KGriu4yBf+6JptMSdiuOzXC/d"
Date: Tue, 28 Jan 2025 15:15:44 +0100
From: Olaf Hering <olaf@aepfle.de>
To: "Edgar E. Iglesias" <edgar.iglesias@amd.com>
Cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org, jgross@suse.com,
 Anthony PERARD <anthony@xenproject.org>, Paul Durrant <paul@xen.org>
Subject: slow start of Pod HVM domU with qemu 9.1
Message-ID: <20250128151544.26fc827d.olaf@aepfle.de>
X-Mailer: Claws Mail (olh) 20240408T134401.7adfa8f7 hat ein Softwareproblem, kann man nichts machen.
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="Sig_/3_gYOUqZaZS0d84viqP81qM";
 protocol="application/pgp-signature"; micalg=pgp-sha256
Content-Transfer-Encoding: 7bit

--Sig_/3_gYOUqZaZS0d84viqP81qM
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Hello,

starting with qemu 9.1 a PoD HVM domU takes a long time to start.
Depending on the domU kernel, it may trigger a warning, which prompted me
to notice this change in behavior:

[    0.000000] Linux version 4.12.14-120-default (geeko@buildhost) (gcc ver=
sion 4.8.5 (SUSE Linux) ) #1 SMP Thu Nov 7 16:39:09 UTC 2019 (fd9dc36)
...
[    1.096432] HPET: 3 timers in total, 0 timers will be used for per-cpu t=
imer
[    1.101636] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
[    1.104051] hpet0: 3 comparators, 64-bit 62.500000 MHz counter
[   16.136086] random: crng init done
[   31.712052] BUG: workqueue lockup - pool cpus=3D1 node=3D0 flags=3D0x0 n=
ice=3D0 stuck for 30s!
[   31.716029] Showing busy workqueues and worker pools:
[   31.721164] workqueue events: flags=3D0x0
[   31.724054]   pwq 2: cpus=3D1 node=3D0 flags=3D0x0 nice=3D0 active=3D2/2=
56
[   31.728000]     in-flight: 17:balloon_process
[   31.728000]     pending: hpet_work
[   31.728023] workqueue mm_percpu_wq: flags=3D0x8
[   31.732987]   pwq 2: cpus=3D1 node=3D0 flags=3D0x0 nice=3D0 active=3D1/2=
56
[   31.736000]     pending: vmstat_update
[   31.736024] pool 2: cpus=3D1 node=3D0 flags=3D0x0 nice=3D0 hung=3D30s wo=
rkers=3D2 idle: 34
[   50.400102] clocksource: Switched to clocksource xen
[   50.441153] VFS: Disk quotas dquot_6.6.0
...

With qemu 9.0 and older, this domU will start the /init task after 8 second=
s.

The change which caused this commit is qemu.git commit 9ecdd4bf08dfe4a37e16=
b8a8b228575aff641468
Author:     Edgar E. Iglesias <edgar.iglesias@amd.com>
AuthorDate: Tue Apr 30 10:26:45 2024 +0200
Commit:     Edgar E. Iglesias <edgar.iglesias@amd.com>
CommitDate: Sun Jun 9 20:16:14 2024 +0200

    xen: mapcache: Add support for grant mappings

As you can see, v4 instead of v5 was apparently applied.
This was probably unintentional, but would probably not change the result.

With this change the domU starts fast again:

--- a/hw/xen/xen-mapcache.c
+++ b/hw/xen/xen-mapcache.c
@@ -522,6 +522,7 @@ ram_addr_t xen_ram_addr_from_mapcache(void *ptr)
     ram_addr_t addr;
=20
     addr =3D xen_ram_addr_from_mapcache_single(mapcache, ptr);
+    if (1)
     if (addr =3D=3D RAM_ADDR_INVALID) {
         addr =3D xen_ram_addr_from_mapcache_single(mapcache_grants, ptr);
     }
@@ -626,6 +627,7 @@ static void xen_invalidate_map_cache_entry_single(MapCa=
che *mc, uint8_t *buffer)
 static void xen_invalidate_map_cache_entry_all(uint8_t *buffer)
 {
     xen_invalidate_map_cache_entry_single(mapcache, buffer);
+    if (1)
     xen_invalidate_map_cache_entry_single(mapcache_grants, buffer);
 }
=20
@@ -700,6 +702,7 @@ void xen_invalidate_map_cache(void)
     bdrv_drain_all();
=20
     xen_invalidate_map_cache_single(mapcache);
+    if (0)
     xen_invalidate_map_cache_single(mapcache_grants);
 }
=20
I did the testing with libvirt, the domU.cfg equivalent looks like this:
maxmem =3D 4096
memory =3D 2048
maxvcpus =3D 4
vcpus =3D 2
pae =3D 1
acpi =3D 1
apic =3D 1
viridian =3D 0
rtc_timeoffset =3D 0
localtime =3D 0
on_poweroff =3D "destroy"
on_reboot =3D "destroy"
on_crash =3D "destroy"
device_model_override =3D "/usr/lib64/qemu-9.1/bin/qemu-system-i386"
sdl =3D 0
vnc =3D 1
vncunused =3D 1
vnclisten =3D "127.0.0.1"
vif =3D [ "mac=3D52:54:01:23:63:29,bridge=3Dbr0,script=3Dvif-bridge" ]
parallel =3D "none"
serial =3D "pty"
builder =3D "hvm"
kernel =3D "/bug1236329/linux"
ramdisk =3D "/bug1236329/initrd"
cmdline =3D "console=3DttyS0,115200n8 quiet ignore_loglevel""
boot =3D "c"=20
disk =3D [ "format=3Dqcow2,vdev=3Dhda,access=3Drw,backendtype=3Dqdisk,targe=
t=3D/bug1236329/sles12sp5.qcow2" ]
usb =3D 1
usbdevice =3D "tablet"

Any idea what can be done to restore boot times?


Olaf

--Sig_/3_gYOUqZaZS0d84viqP81qM
Content-Type: application/pgp-signature
Content-Description: Digitale Signatur von OpenPGP

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

iQIzBAEBCAAdFiEE97o7Um30LT3B+5b/86SN7mm1DoAFAmeY5pAACgkQ86SN7mm1
DoCFOw//W5Fcozw9uIT8fIzv1P9oQEP/KA/H4M25Z1+GmV9jQE2Teo6ycS7FkL0+
ule3smRYAOS5JOeCuQaomUVMbbMZl8LWOnYKl0cGO6Z+WPWgam6Z0B1Qnkba2KwJ
OWxVewxsDL2LgvBc+B7aw4BYhxtcMQq0DhFqr/9BdFFJmvI7q3iOTyfh8WzoJGXH
uGS53lWtxKf8xS3ZrdlEP0hZJpveFlaMENw1DS9fWvV04TuBQYxnUhQt1uBg0kVg
5ZLlB1W8+gsaHzH9PZuBB0kzmQiYmOQV4KuQw9Yxs5oRvJiiZADvTi2kXmk8ihp3
+DCF1aSk4piqqap1uCgYu7Xow2pd7p8SbpMXh7qjdAN3yqbaJ46hC6cOad/RsMFC
1k8zMSmRuB/zs0Pd0g/ZlPrBk5YMsIth0H9405qYnOcDL2zN+9u614GyZkDhd+JW
POXsphk0ZNPju5ZeVNtQWCRJtGu2LzEVxYziSqoQl9gFT4BYoPzCAKI/Gg5XAQFZ
w9tPJ2mxyiStXStazMIZPcYovMjVxPNB7rPVNUkoHedqIGqHtXJMICLkN3jvub9D
NmrUJvklZp/lMY7qoDL8RZ0H1NYYZ0ycs+LB4LVoILZQk18YrJFT3scyFF3ImpaC
1pYwbfYbh/RBwIu6tQoPRYMy/03XwQubbr77j+NbK9JjjSG0Kv8=
=Duhj
-----END PGP SIGNATURE-----

--Sig_/3_gYOUqZaZS0d84viqP81qM--


From xen-devel-bounces@lists.xenproject.org Tue Jan 28 14:34:18 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 14:34:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878520.1288695 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcmfN-0007TR-HX; Tue, 28 Jan 2025 14:34:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878520.1288695; Tue, 28 Jan 2025 14:34:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcmfN-0007TK-Dg; Tue, 28 Jan 2025 14:34:13 +0000
Received: by outflank-mailman (input) for mailman id 878520;
 Tue, 28 Jan 2025 14:34:12 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=jygh=UU=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcmfM-0007TE-AJ
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 14:34:12 +0000
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com
 [2a00:1450:4864:20::62f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f0335d76-dd84-11ef-a0e6-8be0dac302b0;
 Tue, 28 Jan 2025 15:34:10 +0100 (CET)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-aaedd529ba1so818297366b.1
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 06:34:10 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5dc18619346sm7259833a12.8.2025.01.28.06.34.09
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 28 Jan 2025 06:34:09 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f0335d76-dd84-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738074850; x=1738679650; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=FrOZuR8YN0J8NFphtjvgsh/CUngd3QXSCk7CgN8cugs=;
        b=WmRscV78Ycme0AW2qx2ukEoRBaJN5xOCWJfpUXQgdsDTp2S+PMq3HN6rZ6r6DXFUYP
         BNEmX3NFYh4ADzi/Ak+8YTBxImTvysCWfuyO4T+ykj/xohSe8vYZ7llCspkYlWagMC/Q
         TicaXNCUWVVS6b9ukoxXZ7tP9OuZgrQ7YJpt0tK2i8fVZKr0B596vf1mXplTGNUCbdLu
         dxjjulD18oAPracrPyTdRWJPYDKr9GR2VblbuZs/dS7vd+7aeXyvADtZzoty3gMEgUkN
         ZDKda+z4cvyqSPAlvh/R69qWRNpNl36OUaldsAM3CdjrgjWOrJLv5T5Z444EIDSTHO6a
         WoVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738074850; x=1738679650;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=FrOZuR8YN0J8NFphtjvgsh/CUngd3QXSCk7CgN8cugs=;
        b=OmU9ZxxyUSpEq4QdHeThnRTkk0s8k3szLlpWJDYkKrR5866a6cWKOMA1lrAUJUc58j
         FP0Ow161/8pJ8aonrIeUpVHRTVWDfw42tqVmZG5PuCbGH6zizQYBcNVIwBee9mu6h8DI
         mnUldtjK3srSjP2P6uxJoANBOOqwhq2/2sPUMpZV7/Mm6E2XnoIOQ7qif3kannYSTqON
         KYTyl9Yhs8/A12dzmMvCImXuIrOcs8FRm2WcL4e4nicHFTxeEO8FnARIPSAwzsG+Tyva
         JuSDfN9KtEjWOhxkT79kcAAfSdjpZJP4uV73yXeXuzw4yhwidopU0mdmkJ4SjquSqr4Y
         1UOA==
X-Forwarded-Encrypted: i=1; AJvYcCUNs2oQXfAmar89TpQAQbqsJIQ1+EflAnbRhChlg8eGMHW8TqBQpu8tqlzzy5iooeYWQU/O03qRMR8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YximcJ/KvHSngVexpCQ87XlO6nCN14+5GgsRCr253CljaCx9vtU
	8Sl18wryotE95riaga+NBkuR34Yt8iaUkIfL08h9EPD8CfDcfU8HPi2XOxCb+A==
X-Gm-Gg: ASbGncsPxVzvkDSJmxSoitXX18VvX+dnA7mwRYwqsCQt6O2w4jpSNwp1EoRAkCQZcre
	5fl0dSwS0XmqJesb+Az8RK5FgngFGsWhJadvQ2Hg1ecrzlAbkBaKceY2s2aEsvnd7i7VpQBChAz
	+OcZ3RMSIuSoqHnwOJlK7Ken2xkLKjQmlSMwv2snbtGpoosTU00zzZVgQZ38QXa72uA7vvx/Hke
	eenaiIn24wYw0DtDUS8g409qzaHq94bMsbVqDF1hmoERN6Obt3pCjILlmRK0Ewxoc+Rkgmo470c
	8BDUmPUoHLopSJgPmLB7Y+GPrIMJfEFGX9Vf9OkggAb/w17rQ5+eHtGpLMeic3FoGhEpsjVGhe8
	K
X-Google-Smtp-Source: AGHT+IH2LZ4wexQGoBvT0Bz50LBdt2EJehB9n5V/+aQJuFTdvEdgAazb532fr5rclg/mJhO1NKbQ4g==
X-Received: by 2002:a05:6402:2745:b0:5d0:bf5e:eb8 with SMTP id 4fb4d7f45d1cf-5db7db07846mr100313182a12.23.1738074849867;
        Tue, 28 Jan 2025 06:34:09 -0800 (PST)
Message-ID: <e9a5af87-a80e-464c-bd67-8509dfac1d18@suse.com>
Date: Tue, 28 Jan 2025 15:34:08 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 07/24] xen/console: introduce framework for UART
 emulators
To: dmukhin@ford.com
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
 <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
 <20250103-vuart-ns8250-v3-v1-7-c5d36b31d66c@ford.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250103-vuart-ns8250-v3-v1-7-c5d36b31d66c@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04.01.2025 02:58, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin <dmukhin@ford.com>
> 
> Introduce a driver framework to abstract UART emulators in the hypervisor.
> 
> That allows for architecture-independent handling of virtual UARTs from Xen
> console driver and simplifies enabling new architecture-dependent UART
> emulators.
> 
> The framework is built under CONFIG_HAS_VUART, which is automatically enabled
> once the user selects a specific UART emulator.
> 
> All domains w/ enabled vUART will have VIRTDEV_UART bit set in
> d->arch.emulation_flags.
> 
> Current implementation supports maximum of one vUART per domain, excluding
> emulators for hardware domains.
> 
> Use domain_has_vuart() in Xen console driver code to check whether the
> domain can own the physical console focus.

Purely from how it is spelled out here this looks wrong: A domain having a
vUART may not necessarily imply it may also own console focus. Imo the two
need to be treated separately (perhaps even involving XSM), with it merely
being a prereq to have a vUART in order to possible also own console focus.

> --- a/xen/arch/arm/dom0less-build.c
> +++ b/xen/arch/arm/dom0less-build.c
> @@ -785,7 +785,7 @@ static int __init construct_domU(struct domain *d,
>       */
>      if ( kinfo.vpl011 )
>      {
> -        rc = domain_vpl011_init(d, NULL);
> +        rc = virtdev_uart_init(d, NULL);

Like I said for the public header, "virt" as in "virtdev" is ambiguous.
Is there anything wrong with calling this function vuart_init()? While
you may say that the 'v' in there is then as ambiguous, I think that's
not actually the case.

> @@ -891,7 +891,7 @@ void __init create_domUs(void)
>               * d->arch.vpl011.irq. So the logic to find the vIRQ has to
>               * be hardcoded.
>               * The logic here shall be consistent with the one in
> -             * domain_vpl011_init().
> +             * vpl011_init().
>               */

Since you relaxed the tying to vpl011 in the earlier hunk, why is the
tight connection being retained here?

> @@ -30,10 +31,7 @@ static int handle_vuart_init(struct domain *d,
>                               struct xen_domctl_vuart_op *vuart_op)
>  {
>      int rc;
> -    struct vpl011_init_info info;
> -
> -    info.console_domid = vuart_op->console_domid;
> -    info.gfn = _gfn(vuart_op->gfn);
> +    struct virtdev_uart_params info;
>  
>      if ( d->creation_finished )
>          return -EPERM;
> @@ -41,8 +39,11 @@ static int handle_vuart_init(struct domain *d,
>      if ( vuart_op->type != XEN_DOMCTL_VUART_TYPE_VPL011 )
>          return -EOPNOTSUPP;
>  
> -    rc = domain_vpl011_init(d, &info);
> +    info.console_domid = vuart_op->console_domid;
> +    info.gfn = _gfn(vuart_op->gfn);
> +    info.evtchn = (evtchn_port_t)-1;

Where's the literal -1 coming from? Port 0 being guaranteed invalid, that's
what we normally use as sentinel. (It's also unclear why the field needs
setting now, when it wasn't set before.)

Also: Can't all three fields be set in the variable's initializer?

> @@ -783,6 +788,12 @@ void domain_vpl011_deinit(struct domain *d)
>          XFREE(vpl011->backend.xen);
>  }
>  
> +static void cf_check vpl011_dump(struct domain *d)
> +{
> +}

If at all possible, can we try to avoid having empty handler functions.
Putting NULL there and having the caller check is generally preferable,
at least from cf_check perspective.

> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -30,6 +30,7 @@
>  #include <xen/vpci.h>
>  #include <xen/nospec.h>
>  #include <xen/vm_event.h>
> +#include <xen/virtdev-uart.h>
>  #include <asm/shadow.h>
>  #include <asm/hap.h>
>  #include <asm/current.h>

Why would this be needed at this time?

> --- a/xen/drivers/Makefile
> +++ b/xen/drivers/Makefile
> @@ -5,3 +5,4 @@ obj-$(CONFIG_HAS_VPCI) += vpci/
>  obj-$(CONFIG_HAS_PASSTHROUGH) += passthrough/
>  obj-$(CONFIG_ACPI) += acpi/
>  obj-$(CONFIG_VIDEO) += video/
> +obj-$(CONFIG_HAS_VUART) += virtdev-uart.o

I'm unconvinced we want any C files directly under drivers/.

> --- /dev/null
> +++ b/xen/drivers/virtdev-uart.c
> @@ -0,0 +1,60 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +#include <xen/errno.h>
> +#include <xen/event.h>
> +#include <xen/virtdev-uart.h>
> +#include <public/virtdev.h>
> +
> +extern const struct virtdev_uart *__start_virtdev_uart;

Imo this wants to be an array from the very beginning, no matter that
for now you expect the array to have just (at most) one element.

> +int virtdev_uart_init(struct domain *d, struct virtdev_uart_params *params)
> +{
> +    int rc;
> +
> +    ASSERT(__start_virtdev_uart);

What is this to guard against? If the linker script doesn't define the
symbol, linking will fail (as the symbol isn't weak). If it does define
it, its address will be guaranteed non-NULL. What you instead need to
assure is for ...

> +    rc = __start_virtdev_uart->init(d, params);

... this de-ref to actually be within bounds (i.e. __start_virtdev_uart
< __end_virtdev_uart at the very least).

> +    if ( rc )
> +        return rc;
> +
> +#if !defined(__i386__) && !defined(__x86_64__)
> +    d->arch.emulation_flags |= VIRTDEV_UART;
> +#endif

This isn't how emulation_flags has been used so far: The field is set
once, and then isn't further modified. Question is what you mean to
achieve by setting this conditionally. Depending on that it may be
possible to suggest alternatives.

> --- a/xen/include/xen/domain.h
> +++ b/xen/include/xen/domain.h
> @@ -54,6 +54,9 @@ void arch_get_domain_info(const struct domain *d,
>  
>  #define is_domain_direct_mapped(d) ((d)->cdf & CDF_directmap)
>  #define is_domain_using_staticmem(d) ((d)->cdf & CDF_staticmem)
> +#define domain_has_vuart(d) \
> +    ( IS_ENABLED(CONFIG_HAS_VUART) && \
> +      (d)->arch.emulation_flags & VIRTDEV_UART )

Nit: Parentheses around the & operation, to separate it from the && one.

As to the IS_ENABLED(): If you look at how CDF_staticmem and
CDF_directmap you'll find that we conditionally #define them to zero
when the respective CONFIG_* isn't / aren't enabled. That would be nice
to have here, too.

> --- /dev/null
> +++ b/xen/include/xen/virtdev-uart.h
> @@ -0,0 +1,72 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef XEN__VIRTDEV_UART_H
> +#define XEN__VIRTDEV_UART_H
> +
> +#include <public/xen.h>
> +#include <public/event_channel.h>
> +#include <xen/types.h>
> +
> +struct virtdev_uart_params {
> +    domid_t console_domid;
> +    gfn_t gfn;
> +    evtchn_port_t evtchn;
> +};
> +
> +struct virtdev_uart {
> +    int (*putchar)(struct domain *d, char c);
> +    int (*init)(struct domain *d, struct virtdev_uart_params *params);
> +    void (*exit)(struct domain *d);
> +    void (*dump)(struct domain *d);
> +};
> +
> +#define VIRTDEV_UART_REGISTER(x) \
> +    static const struct virtdev_uart *x##_entry \
> +           __used_section(".data.virtdev.uart") = \
> +    &(const struct virtdev_uart){ \
> +        .init    = x ## _init, \
> +        .exit    = x ## _exit, \
> +        .dump    = x ## _dump, \
> +        .putchar = x ## _putchar, \
> +    }

Why the extra level of indirection? Can't the section consist of instances
of struct virtdev_uart rather than pointers to such?

> +#ifdef CONFIG_HAS_VUART
> +
> +int virtdev_uart_putchar(struct domain *d, char c);
> +int virtdev_uart_init(struct domain *d, struct virtdev_uart_params *params);
> +void virtdev_uart_exit(struct domain *d);
> +void virtdev_uart_dump(struct domain *d);
> +
> +#else
> +
> +static inline int virtdev_uart_putchar(struct domain *d, char c)
> +{
> +    ASSERT_UNREACHABLE();
> +    return -ENODEV;
> +}
> +
> +static inline int virtdev_uart_init(struct domain *d,
> +                                    struct virtdev_uart_params *params)
> +{
> +    return 0;
> +}
> +
> +static inline void virtdev_uart_exit(struct domain *d)
> +{
> +}
> +
> +static inline void virtdev_uart_dump(struct domain *d)
> +{
> +}

Are all of these stubs really needed? The sole putchar call site suggests
the stub isn't needed (as the call will be DCE'd by the compiler). The
dump invocation likely also wants guarding by a domain_has_vuart() check.
Perhaps also the exit one.

At least for the dump hook it would also be quite desirable if it could
have a pointer-to-const parameter.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 28 14:43:33 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 14:43:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878528.1288705 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcmoL-0000iX-DA; Tue, 28 Jan 2025 14:43:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878528.1288705; Tue, 28 Jan 2025 14:43:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcmoL-0000iQ-9S; Tue, 28 Jan 2025 14:43:29 +0000
Received: by outflank-mailman (input) for mailman id 878528;
 Tue, 28 Jan 2025 14:43:28 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=jygh=UU=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcmoK-0000iK-KK
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 14:43:28 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3b80746a-dd86-11ef-99a4-01e77a169b0f;
 Tue, 28 Jan 2025 15:43:26 +0100 (CET)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-aab6fa3e20eso964009966b.2
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 06:43:26 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab676114e78sm788780266b.164.2025.01.28.06.43.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 28 Jan 2025 06:43:25 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 3b80746a-dd86-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738075406; x=1738680206; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=KRuTf83lWyflbO7ZbRjUN4I/48s/hNFs2otmIWnKcJ8=;
        b=B0BlBvanSxn6leOggwWouvgU3cZ17T+QKbtb+1FDF4q280T7zepBQ7tbOujBA5/u5l
         Mzt6sTOUdWv4mi6dP7KSVpzsFMPLkbS3DZ2DS+z2j+2ebz+hRZY+iiyFhmsAiApTrYqK
         gyChAdLnkww6lQKR1aBIYwcdeSeoxvDobltrA1dlnwj5r8pAHoOyQoXIdeeR6D6dEEhG
         70KPLxONhgGFooxwDl4XJ8UGNxEifVUTU/hVCMKJ1taTWYPt8Ej0ujR6+gcPQtsqL+07
         nXWvTydu45FdSBdAYRWmVb3oPXDqIdjQZutTAeVNTCdCKo0f7ef+8V6XIWrgV4I2gC+J
         szqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738075406; x=1738680206;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=KRuTf83lWyflbO7ZbRjUN4I/48s/hNFs2otmIWnKcJ8=;
        b=p/n/GGFU4ytJxjEz033x3cAmGInS2SXSpzRnpzBWvnzclZNMz/fg8mF7/PHtHggWaE
         +Dk7F09MiRCucOFe5cFgGYlNHnkK3qB2jn0IrpMhgApu90rdvN7kKet3O/LTtZEf3yBL
         ASPrTyfXUQHQvfPKO63qX1hB5NB7Bra1o7ECKdnlDbBZlg/CPRbPD3ZVyIBBlp9eHWau
         ug9zbxbZ+a0ksXpbJZLiWq1QKznqwW8TOxOQLRZ/yJsoTfI9DPOjB3y8byIiruaK+Xm7
         WLZO6AE6LR8iGytB93khSkgpTZtxn5xrKJYVh73ZIURa/7W+7jeeZXR8CQKSDgyyjDbH
         YBKA==
X-Forwarded-Encrypted: i=1; AJvYcCXmHeFA8CByUEO7Foemy1ioV9bnGb4K6OuUgpLU9XaTWXwBZpZvda08NwN1LpqaJRbzXCJT4R7slOM=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxdt3R3latoQLexrFuz0YUz1ET3hbE6+XHNM5H06XLznk2NdWP7
	gg2DCtalYp3StexCJrD+vQWkKMVOzRV7Qt2sW097njElD9qs0BTj6abmR7ZHEg==
X-Gm-Gg: ASbGncskXrTbiMceTwWWJoNGMgHCnGs96+GcSEGTIVzMQ0Dbd/dU2IGpXnaEhpzH8i0
	dTv4piabQ4jxbFEVFt1/M9i7t165B8npbqgUqQ/hhCwKCSDR7oQd53YxgSmbP3kFthhQf+uu8si
	QGwRy/77Y/2gsq7ECyyo816anWyXhBt/gIoUe/AVcmQEH9iXIWEwk1QxlUbxFq1Znj8LT3uVomI
	mWwEXKpCjzOhltB3mKH2jySzlMOnS6jv+9V3ZIOFC/VnC6rBc8VDk+SqiTvLxdfalUsOLSE3WzD
	NsUd8LzPckcgWRQVB+gJjSd0XltSmDHQe07YBYSK2qwrI0uCYTKd+Yn6HpMO1b4bjJpMvy45KHF
	H
X-Google-Smtp-Source: AGHT+IFhnAsfkuLWe55KqmE9AW5Sx/IiKWwCH/ze3QabRa12T7xitF+Q1T1h7zCdb6tgygpDh+3fLw==
X-Received: by 2002:a17:907:7296:b0:aab:75f1:e51a with SMTP id a640c23a62f3a-ab38b44e04emr4761171966b.38.1738075406067;
        Tue, 28 Jan 2025 06:43:26 -0800 (PST)
Message-ID: <03de0e24-dd5b-4ca4-a0de-299cd48de58b@suse.com>
Date: Tue, 28 Jan 2025 15:43:24 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 08/24] xen/console: rename switch_serial_input() to
 console_switch_input()
To: dmukhin@ford.com
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
 <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
 <20250103-vuart-ns8250-v3-v1-8-c5d36b31d66c@ford.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250103-vuart-ns8250-v3-v1-8-c5d36b31d66c@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04.01.2025 02:58, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin <dmukhin@ford.com>
> 
> Updated the name to highlight the physical console input selection logic:
> existing code does not switch only serial console, it also switches debugging
> console (debug I/O port and console hypercall).

Would you mind clarify what you refer to by "debug I/O port" here? I can't
spot console_rx (which what the function alters) having any interaction with
that. I'm also having similar trouble with the console hypercall. (The
renaming is likely still okay to do, but I'd like to understand what I'm
presently missing.)

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 28 14:45:26 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 14:45:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878537.1288715 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcmqC-0001Ia-RA; Tue, 28 Jan 2025 14:45:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878537.1288715; Tue, 28 Jan 2025 14:45:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcmqC-0001IT-NY; Tue, 28 Jan 2025 14:45:24 +0000
Received: by outflank-mailman (input) for mailman id 878537;
 Tue, 28 Jan 2025 14:45: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 <SRS0=jygh=UU=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcmqB-0001II-DB
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 14:45:23 +0000
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [2a00:1450:4864:20::529])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 808f7b57-dd86-11ef-a0e6-8be0dac302b0;
 Tue, 28 Jan 2025 15:45:22 +0100 (CET)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-5d0ac27b412so7554707a12.1
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 06:45: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
 a640c23a62f3a-ab675e1251dsm797345366b.23.2025.01.28.06.45.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 28 Jan 2025 06:45:21 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 808f7b57-dd86-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738075522; x=1738680322; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=bAZAoWoHUizWksXgxL/xbbj4bxyh7pa6NvIG5oI9n7k=;
        b=Lp57WfiE3+e5rdJcSO68wY73DEEecAzKgBkgwGjwXAGCkElVmBhUSrZB27Mx0NffqP
         x3vb1CjwMt5Q9Ln6JXPzlK8Ieakb2XU245l7Q3Dg8CPM0boNFQlTBeq0jDpbNeZJmVOS
         EpoRPYlaN6lLnfT+Ho3YiASDRUxjo+A8r4k8+1sir1yk7pCrWF/5ZYCVMeTI+cYIV5oz
         C22A59pr5IBJ6ElKS7cG1bRq/taQtQfmJCQnRAylFyYlCdUeryhVMDB1Y116hM40Ufvt
         PHPqDFKhASLd/QVnbCMG6Ii8mVrL8piwem1PdPch9ev998zhN6/AVj+PrtiRs/HoezVJ
         Ia/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738075522; x=1738680322;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=bAZAoWoHUizWksXgxL/xbbj4bxyh7pa6NvIG5oI9n7k=;
        b=Bw59lNrTn78gqZn1tveZ+ElNaSTZXSGXyShdt7ONcNwaQ1jhAMV+QECEaiNJDUD5cf
         Djuk9pIC5Rfe2L7KF4aou3GQ0bXIx92VujVlqospJXgNUXP1uq41Bl0fseE/6+bvdkrf
         AFhjvgZkirpZpV4YD0ie8ScbyScw2fZW/EAGF0OqLKx/+ekQGJce8yJyuxyoDd7IZH0M
         Vn56YRlfAhzmpOf6GEPnpSiB9Q4k8eQIa1uf3oYsacyzHT6bCKLtp9luiQ4hb0j9PRLc
         nRZbgChj0eb6VxnmFKAsrnAZiQW0gCNBb264unN/jgF90MZMKXLPnSTRx/ZifIqfOVsP
         Uq3Q==
X-Forwarded-Encrypted: i=1; AJvYcCXvleDmO9FBX7FE3oFi0fNnedH7HWLvEpZKD1Lxq4JRppa5j/SmFnYceRRCRMCzA48HUAlFMrg5maE=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw/a0IV7c85BtaWnQH1yNQ7cy1xDxKRdHs0mwEvtF4mwkECyFSG
	+p4zMEB6K01rRI/kiXT+QiDgEp5265UYaplQyh+o7qKtU7Zg/ux0GIJqFIWy1w==
X-Gm-Gg: ASbGncuMqeOvxSl/w/v9FoNhOvsvJbKja+79FrkwaIWQPFynBkL3iRrBMEu8wmu9ile
	P7q05utxZA+7xaOvY83/1f/NYPnER3a+0Vhwho5RSn1Ub0ivgS8I+3HzCl/HGBl/n+XfhDdvBEd
	Pm1xQflGmanxAk/AK6AamwXLsTWrsfNUeEV6jjBEmcg+YWVGHA5EjJ4y8zPzUc7CqiMu+E8nVoB
	za1NJJFoYei/4zUfoS+IBBo0Eze9k5a75Dthv9UZf72r3eq47gkxZ4piedC7HHLiVgiyj+qIy/S
	uqT2lfyI9kImtGAdhopVIItBAzUdBGXt/ZSe4I6DzIsef2xtnoOoZK7odaJhqND15iNyLY3QxHc
	B
X-Google-Smtp-Source: AGHT+IGyH7WQMyjPEDrinSrqIlbC2IvcL+H2+vHfHiWY16s6ot2Vry4cR0ZzyBDQdZohUQRwYwNhEA==
X-Received: by 2002:a17:906:ef05:b0:ab3:4b0c:ea44 with SMTP id a640c23a62f3a-ab38b0b7ef3mr4302166866b.9.1738075521957;
        Tue, 28 Jan 2025 06:45:21 -0800 (PST)
Message-ID: <89074dee-7e54-417f-a164-8b53e0bfead9@suse.com>
Date: Tue, 28 Jan 2025 15:45:20 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 09/24] xen/console: rename console_rx to console_owner
To: dmukhin@ford.com
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
 <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
 <20250103-vuart-ns8250-v3-v1-9-c5d36b31d66c@ford.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250103-vuart-ns8250-v3-v1-9-c5d36b31d66c@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04.01.2025 02:58, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin <dmukhin@ford.com>
> 
> Update the symbol name to prepare for the follow on semantic change of console
> owner identifier.

Again the rename may be okay, but I'm afraid you can't defer to future changes
when it comes to addressing the why aspect(s).

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 28 14:56:01 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 14:56:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878546.1288725 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcn0N-00035V-Os; Tue, 28 Jan 2025 14:55:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878546.1288725; Tue, 28 Jan 2025 14:55:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcn0N-00035O-Ku; Tue, 28 Jan 2025 14:55:55 +0000
Received: by outflank-mailman (input) for mailman id 878546;
 Tue, 28 Jan 2025 14:55:54 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=jygh=UU=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcn0M-00035G-4R
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 14:55:54 +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 f7aded1a-dd87-11ef-99a4-01e77a169b0f;
 Tue, 28 Jan 2025 15:55:51 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-aa66c1345caso271984666b.3
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 06:55:51 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab6760fbe92sm800028866b.131.2025.01.28.06.55.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 28 Jan 2025 06:55:50 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f7aded1a-dd87-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738076151; x=1738680951; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=7DKF9GhoQrHwtEPC7q2CRYlIVUo0o6yRv3V2OPPdXck=;
        b=Q325kpWwvBBVs7lKbGRGZ1WGWpH3GKe5c+Fqzvjd9prNxTWUDJzl8p9GCY6KazYIvX
         zppQvjkBYJ4B2r0OCMXhfFrsMZfX2iZgOnGOTQ2ZfsPia1PWvtqXBlWsN4xnwSggbziD
         1HyPSYJ6pSl4XR9wdTaIcKpGt4kkrP4zei0k+NIqENlxxMYLAtW5rosp+B44vbShPOHQ
         17DWwOtfs7kTazTWyxceZeRebz61j7cdJpVAZeeNnfQD4twwPj+slCYlMgaX/smxcelC
         1dlPYbKGshSARWaUF8+CMcsVhvo1vHEoOGUHBgn3awrZuHdKGDwA8kken62d7UZcs1pR
         LS6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738076151; x=1738680951;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=7DKF9GhoQrHwtEPC7q2CRYlIVUo0o6yRv3V2OPPdXck=;
        b=L20ItEesEP2Kx67mH6S+zSQwaQZiR+I5AxkVIB60rg4nGEfUtTolbasolsLsNqPFh8
         dqPrHR+zt5QpPwEWVTXHhb1IYfR2ZyRK0t2tIJOnYOiyG2Cls7ReliATsbWVhwZMSPnT
         YIaIz7SLYS5AonNcLtuMgbKjq4fujF9nkH+AkrWfkuMQjW2a8a25YsFeR/KCldQQsZmy
         ExODFV8MV0z4T52DRbCso96I8xd8SoPOluBdpIFq8bWdyLNpP0Hitq4IVzp+iCeUY1xK
         tF1H22Aun3uXw6OsxPXvwlQgWOP3vpnRW3drrcEZnhcoAWcULzOhA0K38J84xdEmg0r5
         PTug==
X-Forwarded-Encrypted: i=1; AJvYcCUygvnJT27L4+fKrcIrpa6jigDTv6mQSnBsrJbPYqE2S7TxC5GNHH7HCT35ZBAm0wn2yC5k8eZdoc8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxA3i4hRVF3M9B2FiTpL7l0fimh9g0jcf+WK33JNOagooYEG0eb
	NJHyxh0/juCHCBkSL+AFUX0zzQ6zEMoBG6md7sjVMrTcxM9m05r2yZkMrrzFLA==
X-Gm-Gg: ASbGncsYHKlsho4yDLEtne6kkxaXwQT+RMsJI/5xGM3b0B3+p09zaV74SBsAax6EWFK
	Em4I7NUKOB2AfR7a/cOBfks4926QfpSnToXWIBrTf1JTHSLcabOKSFbPgyWYy1zKHSpKy7ubK+1
	XwTTsp0TFSOPU75KD9hj67nJU0dHhG/uTQgQTP9QVAzCJm+/xOoPEcOqchXL7O3VOesAfhm0+GI
	sCEZ15X4t+gB/ptJwj7DCNu55acfZyD2Te44gnljEqGmyjXliDfSm/r6SEjWfgLUhlpfEzj9T+d
	mfbAL8aoJVAKhGBhZjk+F9nrjOVKVD+RfGSCCZmrPguZK+OJ+tA1mI/ErbAtLRsMQqbdHxCzggU
	r
X-Google-Smtp-Source: AGHT+IFyfu1kscEgbfSZwh3r0b3vQ4Lm/q180GZfN52ySA5lBJqKZPeCFMmF/zcD0kgfg2baN57tDg==
X-Received: by 2002:a17:907:7e92:b0:aab:eefc:92e5 with SMTP id a640c23a62f3a-ab38b1f33e1mr3987559866b.14.1738076151247;
        Tue, 28 Jan 2025 06:55:51 -0800 (PST)
Message-ID: <e899f63b-6182-4b53-9fb4-9a821e75648b@suse.com>
Date: Tue, 28 Jan 2025 15:55:49 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 10/24] xen/console: introduce use of 'is_console' flag
To: dmukhin@ford.com
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
 <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
 <20250103-vuart-ns8250-v3-v1-10-c5d36b31d66c@ford.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250103-vuart-ns8250-v3-v1-10-c5d36b31d66c@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04.01.2025 02:58, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin <dmukhin@ford.com>

First: The title gives the impression that the field is never used (read)
right now. That's not the case.

> The code inspects d->is_console flag to decide whether the console focus
> should move to the domain with console after administrator uses <Ctrl+aaa>
> key combination to switch the console focus.

It's unclear whether this sentence describes what is the situation before
the patch, or what the patch changes things to. (The impression I'm getting
is that it's the latter.)

> --- a/xen/arch/arm/dom0less-build.c
> +++ b/xen/arch/arm/dom0less-build.c
> @@ -985,7 +985,6 @@ void __init create_domUs(void)
>              panic("Error initializing LLC coloring for domain %s (rc = %d)\n",
>                    dt_node_name(node), rc);
>  
> -        d->is_console = true;
>          dt_device_set_used_by(node, d->domain_id);
>  
>          rc = construct_domU(d, node);

The flag having an existing user, what's the replacement of the setting of
it that you drop from here? Same question then goes for the places where
you set the flag anew.

> @@ -562,8 +584,19 @@ static void __serial_rx(char c)
>          /* Deliver input to the PV shim console. */
>          rc = consoled_guest_tx(c);
>  
> -    if ( rc )
> -        printk(KERN_ERR "d%pd: failed to process console input: %d\n", d, rc);
> +    switch ( rc )
> +    {
> +    case 0:
> +        break;
> +    case -EBUSY:    /* Loopback mode */
> +    case -ENOSPC:   /* FIFO is full */
> +        printk(KERN_WARNING "d%pd: failed to process console input: %d\n", d, rc);
> +        break;
> +    default:
> +        d->is_console = false;
> +        printk(KERN_ERR "d%pd: disabled console forwarding: %d\n", d, rc);
> +        break;
> +    }

Nit: Blank lines between non-fall-through case blocks please.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 28 15:10:29 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 15:10:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878556.1288735 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcnEO-0005tK-Tj; Tue, 28 Jan 2025 15:10:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878556.1288735; Tue, 28 Jan 2025 15:10:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcnEO-0005tD-Qr; Tue, 28 Jan 2025 15:10:24 +0000
Received: by outflank-mailman (input) for mailman id 878556;
 Tue, 28 Jan 2025 15:10: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 <SRS0=p3hs=UU=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tcnEM-0005t7-RA
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 15:10:22 +0000
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com
 [2a00:1450:4864:20::42c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id fe0cf39e-dd89-11ef-a0e6-8be0dac302b0;
 Tue, 28 Jan 2025 16:10:21 +0100 (CET)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-385d7f19f20so2959193f8f.1
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 07:10:21 -0800 (PST)
Received: from [192.168.69.151] (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38c2a1c402esm14561306f8f.97.2025.01.28.07.10.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 28 Jan 2025 07:10:20 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: fe0cf39e-dd89-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1738077021; x=1738681821; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=ViM+rjZUgxvbfxwTZxZKl7dD2XoHFDnQHFMIYBVWG2o=;
        b=Jc7LKc7d2evkXQVhtyyua8mXB/9d5D0SHZ6HVDAIciiPe0S0TnJcOVU4O9KBQzNxzr
         zZ7Q5NNFy8cOdLXTs7ouKZgBXriMYBmWs7el8z6vTlfFu+iuUQd5fyZHm/uUiEg0DnDB
         bx9hMrtXlXOSI5h/1c8sWWOh/3sDGDHRkiP7secrt31lD9zi7UmzHn0x15F+jcVpAYXq
         HlhLw64CrhyDL7wJgXf+bd/uJuBAoYexYmt5/Ow0ArgtD2+uwZ6j6t9x5yBQ3RTlzBzO
         Tt+aFfA3yyHw+Pb5dayWku48OMzGXjBBSMv4s1olbHUQooXvbp6A41xKFVQ90MmaodDs
         fZZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738077021; x=1738681821;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=ViM+rjZUgxvbfxwTZxZKl7dD2XoHFDnQHFMIYBVWG2o=;
        b=Qtbe/Ug0YaOWSXs4v7ClXVGBu0kghkDLN7TJMPNnUuKsWx5PZLikHPLEDw28TbJlT2
         OX6Lal/zCPhidtqANgA+zUtOCz2feR6FLNoXMLQwcOT8OibfCLA7mIvtJe1VZnDqdFxV
         I/rDV1E1388Y2sIRV5BaeVPYfY5KqQiljk/qMll0j61FNFkSTg2fNsUFmN92jdbk5HZ6
         vwsPjDDCvLrfh5QDgR19p0wZoBaW47a3zBHzauqGZs1GqIhoxkinxiEJvACX1X3Ihnm5
         1wrBokoAOONqfb/CiP0Jn5+C5pVclUwJt9Ly1PIO1vLBLl2O2WRz3aVU+bVmz045JL5m
         vw1A==
X-Forwarded-Encrypted: i=1; AJvYcCXZZubHtnN8ShXEKtU2j736ZgSzEjwXkijT5+FvSGKf4ZdG6fRsqMAXP12bJ7fERw53+xpztjJdR6g=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzkRf/wy6VicL/faudfxA1i8f2dwIHhVH0MzpTOd8CGyIEvWvzH
	BTjTl2Y3t22s/Zs6i4Qh+tQfHMLCxQWq0KN/7f1ei6utWMEH2C0MKa/+y+o20X4=
X-Gm-Gg: ASbGncvz1jb0G6JfgU/Qf+vMtGcDG7JNE81c157+sVaW8bXGYjjUsEq/bFAlvGfJk1h
	VXtrfVg9Zsudbl1SNy9i8XHSAwf4oQekMIk+/dK0lzppWYb7t5aB77ANpOadFZVNSLwmAR438mS
	caKh1h/vomK/4ehnSEeQ2Gy0AjzgWK3yb9Bu7vwKdMs8xiSDDCn7nYwRD21TRXbBtS5zF0uKecb
	3QlUiXYFFPi/pkXiJSJXcpkJn7Dd0J92p4d4NcAlGau9MzVePN+XMkXfKAXrVN2NiV7BJKLTL1u
	w0uTJ0Mr0vVVGyTke+Lk/UG0f5/UXpZaP6yZ7nbkxu8p3z31s8+89VyVdos=
X-Google-Smtp-Source: AGHT+IGLc4A5clvj21CfoQyBX6F3omCt6bWQLv3EkWi0U+JM0LkNEZMv50192jgozkl7S+UQxS3FRg==
X-Received: by 2002:a05:6000:18a9:b0:38a:86fe:52dc with SMTP id ffacd0b85a97d-38c3b0cbb61mr9689447f8f.13.1738077020863;
        Tue, 28 Jan 2025 07:10:20 -0800 (PST)
Message-ID: <990dacab-6cfd-4a18-944d-ba076a80996c@linaro.org>
Date: Tue, 28 Jan 2025 16:10:18 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/9] hw/sysbus/platform-bus: Introduce
 TYPE_DYNAMIC_SYS_BUS_DEVICE
To: BALATON Zoltan <balaton@eik.bme.hu>,
 Peter Maydell <peter.maydell@linaro.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>, qemu-devel@nongnu.org,
 Yi Liu <yi.l.liu@intel.com>, Markus Armbruster <armbru@redhat.com>,
 Eduardo Habkost <eduardo@habkost.net>,
 Anthony PERARD <anthony@xenproject.org>,
 Gustavo Romero <gustavo.romero@linaro.org>, Jason Wang
 <jasowang@redhat.com>, qemu-ppc@nongnu.org,
 "Michael S. Tsirkin" <mst@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>,
 Alexander Graf <graf@amazon.com>,
 Richard Henderson <richard.henderson@linaro.org>,
 Stefan Berger <stefanb@linux.vnet.ibm.com>,
 Bernhard Beschow <shentey@gmail.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= <berrange@redhat.com>,
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
 xen-devel@lists.xenproject.org, Marcel Apfelbaum
 <marcel.apfelbaum@gmail.com>, Alex Williamson <alex.williamson@redhat.com>,
 Paul Durrant <paul@xen.org>,
 =?UTF-8?Q?Cl=C3=A9ment_Mathieu--Drif?= <clement.mathieu--drif@eviden.com>,
 =?UTF-8?Q?C=C3=A9dric_Le_Goater?= <clg@redhat.com>
References: <20250125181343.59151-1-philmd@linaro.org>
 <wkb53fhvfchqa4uvmifgitvcr7t7rfpc3hcohdhzczkzvktetx@yjveswjel3s4>
 <CAFEAcA-QOYcnJi=joKHbRmUCXK1UFOgQRgYP-fDq4h_1SkMGyQ@mail.gmail.com>
 <2893a552-ca6c-01c4-dcc0-6107ccf1c7b5@eik.bme.hu>
Content-Language: en-US
From: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= <philmd@linaro.org>
In-Reply-To: <2893a552-ca6c-01c4-dcc0-6107ccf1c7b5@eik.bme.hu>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 28/1/25 13:57, BALATON Zoltan wrote:
> On Tue, 28 Jan 2025, Peter Maydell wrote:
>> On Tue, 28 Jan 2025 at 10:42, Gerd Hoffmann <kraxel@redhat.com> wrote:
>>>
>>> On Sat, Jan 25, 2025 at 07:13:34PM +0100, Philippe Mathieu-Daudé wrote:
>>>> Some SysBus devices can optionally be dynamically plugged onto
>>>> the sysbus-platform-bus (then virtual guests are aware of
>>>> mmio mapping and IRQs via device tree / ACPI rules).
>>>
>>> Do we have some sane way to have user-pluggable sysbus devices on arm?
>>
>> The answer in a general sense is "no, because user pluggable
>> sysbus is a weird idea". "sysbus" means "it's wired into a
>> specific bit of the memory map and to specific IRQs, and whoever
>> does that needs to know what IRQs and bits of memory are usable,
>> and the guest OS needs to know it's there". "user-pluggable" means
>> "it's all automatic and the guest can just do some kind of
>> probing for what is or isn't present". All the platform bus stuff
>> is a nasty mess that's working around the things people want
>> to plug in not being clean devices on probeable buses :-(
>> And the platform bus is only supported on the "virt" board,
>> because that's the only one where QEMU is generating its
>> own dtb or ACPI tables where it can tell the guest "hey,
>> there's some device here".
> 
> There are some SoCs that have memory mapped devices but different 
> versions in the same family have different devices. Either older ones 
> missing some devices or have less USB or network ports while newer SoCs 
> have more of those or they have PCIe instead of PCI. Modelling these 
> could use pluggable sysbus devices so one could add the devices needed 
> for a SoC version without having to write or modify a board code. I 
> think Bernhard's attempt to try creating e500 SoCs from a device tree 
> goes in that direction too. We could also model this by having a SoC 
> that can instantiate devices based on some properties but maybe 
> pluggable devices could be more generic for this. The issue seems to be 
> how to tell the board or SoC where to map it and what IRQ to connect it 
> as this is done by the board and not the device so properties on the 
> device to set these does not really help unless the board can somehow 
> query it and instantiate the devices based on that. Otherwise whatever 
> handles the -device option to create the device would need knowledge 
> about the board. (E.g. the e500 devices are mapped in the CCSR memory 
> region so one can't just use system address space for them.)

IIRC Bernard's series takes a DTB as input and create the machine
matching this DTB.

As Peter explained, sysbus-platform-bus fits TYPE_DYNAMIC_SYS_BUS_DEVICE
in free slots, then generates the corresponding ACPI/DTB.

What you describe seems closer to the QEMU Dynamic Machine project,
following Damien's idea:
https://lore.kernel.org/qemu-devel/20220223090706.4888-1-damien.hedde@greensocs.com/
We are not quite there yet...


From xen-devel-bounces@lists.xenproject.org Tue Jan 28 15:25:11 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 15:25:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878565.1288744 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcnSW-0007vo-3g; Tue, 28 Jan 2025 15:25:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878565.1288744; Tue, 28 Jan 2025 15:25:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcnSW-0007vh-0U; Tue, 28 Jan 2025 15:25:00 +0000
Received: by outflank-mailman (input) for mailman id 878565;
 Tue, 28 Jan 2025 15:24:59 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=jygh=UU=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcnSV-0007vb-HN
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 15:24:59 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 089f9b31-dd8c-11ef-a0e6-8be0dac302b0;
 Tue, 28 Jan 2025 16:24:58 +0100 (CET)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-aa689a37dd4so1142176066b.3
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 07:24:58 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab6aa40824asm356119366b.134.2025.01.28.07.24.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 28 Jan 2025 07:24:57 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 089f9b31-dd8c-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738077898; x=1738682698; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=R6+bHWtED+akRsbrsegFrhoUIY65i2DzLq8lI03TP+0=;
        b=KgMxe0LXPDTN8mtv7pkP7GFufGWiIpLSbGu25A8ZszregSEf7QnGgrW371+UaJ+k9y
         PEv4gxFQB2cicgqI7rxuMm4foXpLu2nzGz/91ZAxEmdVkhoenroaQPawHjPy3PTvg7Qn
         0gFItNxyFQjNofILHmoyZUK+p4J7I65cPfiDY25bl5WzuoZnwHPEFJnjz2DNhQC5AQg9
         BHBvrmCr0epI0/hzaBBw5x26cAyOkYgpEIEug3ip3140FJrcpEZ39CWwONum7FKpqNOc
         1K0iP6GVjbDwj4c8yO4eZUo0dIG+tqqjs1GbagFP83GBrHGhETNUeRwNIKo6Cwb+1Pqk
         40qQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738077898; x=1738682698;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=R6+bHWtED+akRsbrsegFrhoUIY65i2DzLq8lI03TP+0=;
        b=xP6HVtYZ/VG3ajmnPrWvsMTD0BjKzRHbGgUoRsobouA6LonxAJ7YxH6u14WiL0YyBh
         kJTuDZqFSib9CNS6lfFR3ig6k0ffs8HZyYE/Ov4u/SAAe9hnjROL21zTl7E4CUuMu+MZ
         ISC+yX8aphbE6A3zvVzBp8WDIAAg3idyu3heFcH3x+krbUc9XIyIXM5ZHH4HQ78ogMGT
         oqjwU3aXXXZMGmgD96XQlPnhcRkLvedljD3PuKTMbXMv2yMn6rEBcMafki6J86jTTjEg
         4RSmQrbPepmh5fv/kvRZqJNyNNuITLunJeeSsy4OG2fSdmoMOrt1Bo4LPXsm0dvTNLME
         91HQ==
X-Forwarded-Encrypted: i=1; AJvYcCVfcXj7bQ6M2l963cXaYnE+YGcJJbtM+pfKhbwS0tjLKh74MNR09xbZUAsiV1y9mw9ZgH2V3JGw7nY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyWmAxsVD4aGpBMIZKn4cxilrRO99MJx5Z3DWOrbSZvP71n2MLg
	s5u1FARZ09iAUZxozQLBDIk2NlvYi7AlSje9a9nDLckbp0sAbykfDrddfqxJtg==
X-Gm-Gg: ASbGncvBrVUOBQ1zBWlNxo/l3ieZB9zdRnu4rXuHtaEFMBEtgAKpXvQ5QV/RAmT6VMH
	CSICCaa4LON2PWLIpN4Urqjy5O3LzLnVlD5g9XXkk8XTrqMpC8twpIot+d2TzqYDex7Q0YoDK/9
	1QWhfzUJENrdG6F8gwxSGtJ6MF6qvT10aSHs3y7ivyJaLfkXaabw2Ewh2DDV4x4i9EAGaYjagnB
	tqYDxfCYOmPTtzEi4/5xogjM1zZDc9BvkdlPWfAOi0xPY6ek4Cm6zHcxuaGE8Rhzh1+zpHbX7U0
	bUom2qVvfSs1WdL1YttWTW9FEoq89H3mo/jR/+enjthrabOuCNAwAZxGdYhvu7dqsMsrpupSeFI
	e
X-Google-Smtp-Source: AGHT+IG7lKKdeOQl2WGGWu5hg3C36ZqNreoUFyU59TmynYr4bsmW/gaxeqTwYMgoo31Rr/nAtgMzcQ==
X-Received: by 2002:a17:906:7955:b0:ab2:f816:c5e1 with SMTP id a640c23a62f3a-ab38b1b4659mr4533584766b.1.1738077897383;
        Tue, 28 Jan 2025 07:24:57 -0800 (PST)
Message-ID: <ebb76855-9ab4-445d-9f43-5554c4743755@suse.com>
Date: Tue, 28 Jan 2025 16:24:56 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 11/24] xen/domain: move get_initial_domain_id() to
 arch-independent header
To: dmukhin@ford.com
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
 <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
 <20250103-vuart-ns8250-v3-v1-11-c5d36b31d66c@ford.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250103-vuart-ns8250-v3-v1-11-c5d36b31d66c@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04.01.2025 02:58, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin <dmukhin@ford.com>
> 
> Honor 'hardware_domid=' parameter across all architectures

In which way is it not honored right now (besides depending on
LATE_HWDOM=y)? It is, for example, not supposed to be the case that
in a late-hwdom configuration all IDs below hardware_domid are
unavailable for new domains to be created.

> and update
> max_init_domid correctly so that toolstack and, subsequently, console driver
> could iterate across known domains more efficiently.
> 
> Also, move max_init_domid to arch-independent location.
> 
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>


> @@ -2387,15 +2388,15 @@ void __init create_dom0(void)
>      if ( !llc_coloring_enabled )
>          flags |= CDF_directmap;
>  
> -    dom0 = domain_create(0, &dom0_cfg, flags);
> +    dom0 = domain_create(domid, &dom0_cfg, CDF_privileged | CDF_directmap);

Why the move from "flags" to "CDF_privileged | CDF_directmap"?

>      if ( IS_ERR(dom0) )
> -        panic("Error creating domain 0 (rc = %ld)\n", PTR_ERR(dom0));
> +        panic("Error creating domain %d (rc = %ld)\n", domid, PTR_ERR(dom0));
>  
>      if ( llc_coloring_enabled && (rc = dom0_set_llc_colors(dom0)) )
>          panic("Error initializing LLC coloring for domain 0 (rc = %d)\n", rc);
>  
>      if ( alloc_dom0_vcpu0(dom0) == NULL )
> -        panic("Error creating domain 0 vcpu0\n");
> +        panic("Error creating domain %d vcpu0\n", domid);

If already you alter this, please switch to %pd.

> @@ -65,6 +68,9 @@ DEFINE_RCU_READ_LOCK(domlist_read_lock);
>  static struct domain *domain_hash[DOMAIN_HASH_SIZE];
>  struct domain *domain_list;
>  
> +/* Last known non-system domain ID. */
> +domid_t __read_mostly max_init_domid;

I'm afraid comment and variable name conflict with one another. And
really with its present purpose it ought to be __ro_after_init, I
think.

> @@ -2261,6 +2267,15 @@ int continue_hypercall_on_cpu(
>      return 0;
>  }
>  
> +domid_t get_initial_domain_id(void)
> +{
> +#ifdef CONFIG_PV_SHIM
> +    if ( pv_shim )
> +        return pv_shim_get_initial_domain_id();
> +#endif

Aiui the #ifdef is necessary for non-x86? Would be nice to avoid that, yet
then I'm not meaning to ask you to do a lot of further rearrangements.

> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -415,10 +415,9 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
>      case XEN_DOMCTL_createdomain:
>      {
>          domid_t        dom;
> -        static domid_t rover = 0;
>  
>          dom = op->domain;
> -        if ( (dom > 0) && (dom < DOMID_FIRST_RESERVED) )
> +        if ( (dom > max_init_domid) && (dom < DOMID_FIRST_RESERVED) )
>          {
>              ret = -EEXIST;
>              if ( !is_free_domid(dom) )
> @@ -426,19 +425,19 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
>          }
>          else
>          {
> -            for ( dom = rover + 1; dom != rover; dom++ )
> +            for ( dom = max_init_domid + 1; dom != max_init_domid; dom++ )

The "dom != max_init_domid" is dead code now if I'm no t mistaken, due to ...

>              {
>                  if ( dom == DOMID_FIRST_RESERVED )
> -                    dom = 1;
> +                    dom = max_init_domid + 1;

... this. Thus the loop will become infinite if all permissible domain IDs
are in use. Yet then ...

>                  if ( is_free_domid(dom) )
>                      break;
>              }
>  
>              ret = -ENOMEM;
> -            if ( dom == rover )
> +            if ( dom == max_init_domid )
>                  break;
>  
> -            rover = dom;
> +            max_init_domid = dom;
>          }

... why would all of this code need changing? (If it does, I think that
wants to be in a separate patch, with appropriate description.)

> --- a/xen/common/kernel.c
> +++ b/xen/common/kernel.c
> @@ -568,6 +568,14 @@ static long xenver_varbuf_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>      return sz;
>  }
>  
> +static int __init cf_check globals_init(void)
> +{
> +    max_init_domid = get_initial_domain_id();
> +
> +    return 0;
> +}
> +__initcall(globals_init);

Imo this wants to live in the CU defining the variable.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 28 15:42:52 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 15:42:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878578.1288754 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcnjj-0002ar-Im; Tue, 28 Jan 2025 15:42:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878578.1288754; Tue, 28 Jan 2025 15:42:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcnjj-0002ak-G3; Tue, 28 Jan 2025 15:42:47 +0000
Received: by outflank-mailman (input) for mailman id 878578;
 Tue, 28 Jan 2025 15:42:46 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=jygh=UU=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcnji-0002ae-1u
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 15:42:46 +0000
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com
 [2a00:1450:4864:20::52f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 83c64039-dd8e-11ef-99a4-01e77a169b0f;
 Tue, 28 Jan 2025 16:42:43 +0100 (CET)
Received: by mail-ed1-x52f.google.com with SMTP id
 4fb4d7f45d1cf-5dc59303334so799624a12.2
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 07:42:43 -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
 a640c23a62f3a-ab675e64da5sm809223366b.60.2025.01.28.07.42.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 28 Jan 2025 07:42:42 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 83c64039-dd8e-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738078963; x=1738683763; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=s5pSSj0wM3yX7/gPtKL4tkphE0jVweOmLAcWGt19sdU=;
        b=Ac/ZevFOth9lC1wuZJsOi/Yrj71IwSlxXdP4kXoaVRc1FL7bJNLSlKdMvbZAACIIsl
         7VVhMEu5rHI7tqTmRvRE4h1wOO+rPXEw3M8tI1jDqIz5S0eJFsTG1Z/nd7jSO9fmXzhb
         FtGX9VZ0dw0vWEDtCPGdxzcRNwxApcy1HwSAmtgN8Iix+fY0pApac9lhOUwa74s23ZHf
         ukHd2DCvnOwpDoElFj22dzhI5chuOeH/smWKrTJ7lBqinQzvi7uMQL+u40JzeNz7Q29T
         sPL8spuxKvescsWr+ocOfqOgTwB8Wc0nle+yCcxoysru+9mLoEGdWRYpAU7GBy/+UqI7
         WU1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738078963; x=1738683763;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=s5pSSj0wM3yX7/gPtKL4tkphE0jVweOmLAcWGt19sdU=;
        b=C8PxBhKmxFJKfsGEfxh3Q9LTnkXsBhl7C9gxvCQWAuo3UvZn/KICovAe+PMo++8JfA
         qw44bR4p7CEOk9pIaFc5DCHNZmXxPTDZsWifLihu352W2yD16eDneut5bpr3EeRh2y1w
         EayyLEiG3r7vS7f4oiwDVLYeA3whUlUKEkflfWZkJNj7hRSspyetudOAbKIRytu2CmWE
         yMfrYFwsUsRFqJ63rny2xBzXbZSBKM6qQSG/lrSkshvZ2J5UUpo17tF92zN5uLDH+ymc
         Eq7SoAPvwi5qK9bjFxLMo8SopDzS1xOpJHQ5seqX7VExLoKRIb1iEhr6xK65Qbhcr0DN
         kobg==
X-Forwarded-Encrypted: i=1; AJvYcCVlDrqW0Z8jcfU0ezBDTqAU1zdDAq8IMusl090c+p96xWb1dG+fhJjJnAZE35PUFBc30r/i1u9cIKQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyjGOp90I1wUorVHAgSHwdkovlH8pdoHDTbBYHlzKRNCBSaTm3V
	y4mG4Q1cFi9eb3x5E50MeNPgto/U0p/wBkG+f/03zUw1HFW45bIRSgeuAuSFFA==
X-Gm-Gg: ASbGnctJYtn2ixVqVh1d1+E/proLlYOJoN1tFKEgqDOIKWO1RuDhzj1Yy29G4Uh6Oqq
	tj6p/5i2vFaSlK4krS3ms6+NnmaxB4rfY1AQ9TYjfXcYu/kDp+UJVvXZTrS1ER8P/WiBK9IUTIb
	4ybZ41ALLmUGncSniBuUbU/S9LszgDjHgQ8OGNJQCPtHOn+XBAHviWCLT7Ml4glq85i3blUL0Kc
	TexRTwo3GpAMh66pRdxzO0Xr9nDgGnPImcrOHb29d0EIjf/pwFYeM3AaBmuQYxe7fnnDBIYhsj8
	8XLS3ESE8XWwrcc1/zgXNk7Idi+YseFt11YuJ9YmpPHOFIVVAZJ4a5fcqo+wCJPD3Tc6Mpc4Wev
	6
X-Google-Smtp-Source: AGHT+IGbos06quQHLqfttwBUEwjQoBT5bq0yr2kUkmyqBiO8znBfOnOkpkdhksSCXmuBfK9zMR33gA==
X-Received: by 2002:a17:906:79a:b0:ab3:a0ad:17a9 with SMTP id a640c23a62f3a-ab3a0ad203cmr3352381366b.24.1738078963301;
        Tue, 28 Jan 2025 07:42:43 -0800 (PST)
Message-ID: <eebf89e0-7df7-4628-8b0f-814531c4e47e@suse.com>
Date: Tue, 28 Jan 2025 16:42:42 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 12/24] xen/console: introduce console_{get,set}_owner()
To: dmukhin@ford.com
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
 <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
 <20250103-vuart-ns8250-v3-v1-12-c5d36b31d66c@ford.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250103-vuart-ns8250-v3-v1-12-c5d36b31d66c@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04.01.2025 02:58, Denis Mukhin via B4 Relay wrote:
> +domid_t console_get_owner(void)
> +{
> +    return console_owner;
> +}
> +
> +/*
> + * Switch console input focus.
> + * Rotates input focus among Xen, dom0 and boot-time created domUs while
> + * skipping switching serial input to non existing domains.
> + */
> +static void console_switch_input(void)

I'm afraid I'm irritated now: In the earlier patch you said you renamed
console_rx to console_owner because that's not just about input. Yet
here you actively _add_ "input" to a comment that you've moved an re-
worded some.

> @@ -1149,8 +1144,8 @@ void __init console_endboot(void)
>      register_irq_keyhandler('G', &do_toggle_guest,
>                              "toggle host/guest log level adjustment", 0);
>  
> -    /* Serial input is directed to DOM0 by default. */
> -    console_switch_input();
> +    if ( opt_conswitch[1] != 'x' )
> +        console_set_owner( get_initial_domain_id() );

Nit: No blanks like this inside the parentheses of a function call,
please.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 28 15:43:27 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 15:43:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878585.1288765 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcnkM-00034F-RU; Tue, 28 Jan 2025 15:43:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878585.1288765; Tue, 28 Jan 2025 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 <xen-devel-bounces@lists.xenproject.org>)
	id 1tcnkM-000348-Nx; Tue, 28 Jan 2025 15:43:26 +0000
Received: by outflank-mailman (input) for mailman id 878585;
 Tue, 28 Jan 2025 15:43:25 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=/wG0=UU=paul-moore.com=paul@srs-se1.protection.inumbo.net>)
 id 1tcnkK-0002ae-Re
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 15:43:25 +0000
Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com
 [2607:f8b0:4864:20::b29])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9a8e03d1-dd8e-11ef-99a4-01e77a169b0f;
 Tue, 28 Jan 2025 16:43:22 +0100 (CET)
Received: by mail-yb1-xb29.google.com with SMTP id
 3f1490d57ef6-e39f43344c5so8249675276.1
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 07:43:22 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9a8e03d1-dd8e-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=paul-moore.com; s=google; t=1738079001; x=1738683801; 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=4CM+Y34LzyqTPbJa964bMKTZoegb6ZCbeVLJYvxkr2Y=;
        b=VrVsTabigcT32TG4OyJwzU3eSuRJu20abiT4E3Tv0o44roLmLzypv6zUGULe1/TEow
         mfo3vmJVIZUqdjCJQxkhoGadf0nZC2V76pCmRCykz0qfzc8rXIcCKBJoMeSrlJuTrpY3
         mk0EE6mmCUTx2auEmXMm2F2Nnbot4+hIO0xzixw8efiNGgfXO2RmGCK2ZtsSW9UI6/dN
         qiq1fcXKqH9BRzFcaHjCaCPgpVQSOw8TVYToREbnr+V9lUj2gZtEt6Vkq2fWZ73phRbv
         bm76fvE1jsAzJP5MGHoiKaT24w2gzeLx2AjQuG1KUc8gSg0sIJWW8WSvMatX8a4/xzMm
         +XAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738079001; x=1738683801;
        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=4CM+Y34LzyqTPbJa964bMKTZoegb6ZCbeVLJYvxkr2Y=;
        b=lrgHJfVr5D+PivwW35fCO4AeLRcpb+gXFVblfg23qX8yec0HWv3JdkINzpbFzsS42J
         LBVhOi6PPMPCXS6hvGIibsQmHekUbPaPEaXvUnpwZ5ROsgEtdVl0RrempuJtMdvQBE+x
         jLSftsJ8c4KkW61jvLgDiqoyVU3NxE3FN1rXxu4q6nBeoiU5LPx8HMYTEmK8bEOLIxeE
         o/TlfEsxgjLUWC92hnPjUPrr2hQlyNSerzYa3zZVMuCy1Rq1QgyYxtOJj4nMSwki2zjT
         hTU3fQUrncORpjG0Lr9bbz1Bvp49buS2bPj2GBl75OEORjpdo1D/HjiTBlUN/YBAc3SJ
         SAuQ==
X-Forwarded-Encrypted: i=1; AJvYcCVC3UIjvXVlhd9dAg4zGncxpLXlEzW1KIVct3uKqPP+ofujkyr/WMbQLGZzYCQKVwlb9XtA7/o+16E=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy8zaHr8AKx3632ADXxyBlWrosDySIR6F2yAo2QewtCCERJpcIe
	lovA7VfU+zUWO4A/uqwxBjbj9KONDi4n1hRxJr894/WtOBwhM76X7YwHZMkwcyaVtyZveax4exI
	AEIrI8nbL7+GSHfzWt0nf+Xx9PQJIbDzlyDWO
X-Gm-Gg: ASbGncuzR+f/6JO+O8XoGicoGzxHVwmyvzBufdo5+vfPEf2aqsjI3gXvBO/ig1Ez6w5
	YhNx2PriZOs2fhMswyj4HCIjg5kCxTOyjK18K7WkPRx9HFIrZfOiIIbEhhi1mMVUoEUZh9/A=
X-Google-Smtp-Source: AGHT+IGuLqrmdoXiE8apV7tzhOJZ5Xm1OF/NxWm8Kjkh7RMoG05FR1MdO9WMx2ebniwyt0o5rEC0Jv+xP432BtVJDY0=
X-Received: by 2002:a05:690c:4d02:b0:6ef:6646:b50a with SMTP id
 00721157ae682-6f6eb6b2881mr361409457b3.20.1738079001445; Tue, 28 Jan 2025
 07:43:21 -0800 (PST)
MIME-Version: 1.0
References: <20250110-jag-ctl_table_const-v2-1-0000e1663144@kernel.org>
 <Z4+jwDBrZNRgu85S@li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com>
 <nslqrapp4v3rknjgtfk4cg64ha7rewrrg24aslo2e5jmxfwce5@t4chrpuk632k>
 <CAMj1kXEZPe8zk7s67SADK9wVH3cfBup-sAZSC6_pJyng9QT7aw@mail.gmail.com>
 <f4lfo2fb7ajogucsvisfd5sg2avykavmkizr6ycsllcrco4mo3@qt2zx4zp57zh>
 <87jzag9ugx.fsf@intel.com> <Z5epb86xkHQ3BLhp@casper.infradead.org> <u2fwibsnbfvulxj6adigla6geiafh2vuve4hcyo4vmeytwjl7p@oz6xonrq5225>
In-Reply-To: <u2fwibsnbfvulxj6adigla6geiafh2vuve4hcyo4vmeytwjl7p@oz6xonrq5225>
From: Paul Moore <paul@paul-moore.com>
Date: Tue, 28 Jan 2025 10:43:10 -0500
X-Gm-Features: AWEUYZkHRaUuCTQsu1U9C5jhigmIE9c2_8OmkE_i2Qv7ILXtAaTfDLC5EcLBZNk
Message-ID: <CAHC9VhQnB_bsQaezBfAcA0bE7Zoc99QXrvO1qjpHA-J8+_doYg@mail.gmail.com>
Subject: Re: Re: Re: Re: [PATCH v2] treewide: const qualify ctl_tables where applicable
To: Joel Granados <joel.granados@kernel.org>
Cc: Matthew Wilcox <willy@infradead.org>, Jani Nikula <jani.nikula@intel.com>, 
	Ard Biesheuvel <ardb@kernel.org>, Alexander Gordeev <agordeev@linux.ibm.com>, 
	=?UTF-8?Q?Thomas_Wei=C3=9Fschuh?= <linux@weissschuh.net>, 
	Kees Cook <kees@kernel.org>, Luis Chamberlain <mcgrof@kernel.org>, 
	linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, 
	linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, 
	linux-s390@vger.kernel.org, linux-crypto@vger.kernel.org, 
	openipmi-developer@lists.sourceforge.net, intel-gfx@lists.freedesktop.org, 
	dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org, 
	linux-hyperv@vger.kernel.org, linux-rdma@vger.kernel.org, 
	linux-raid@vger.kernel.org, linux-scsi@vger.kernel.org, 
	linux-serial@vger.kernel.org, xen-devel@lists.xenproject.org, 
	linux-aio@kvack.org, linux-fsdevel@vger.kernel.org, netfs@lists.linux.dev, 
	codalist@coda.cs.cmu.edu, linux-mm@kvack.org, linux-nfs@vger.kernel.org, 
	ocfs2-devel@lists.linux.dev, fsverity@lists.linux.dev, 
	linux-xfs@vger.kernel.org, io-uring@vger.kernel.org, bpf@vger.kernel.org, 
	kexec@lists.infradead.org, linux-trace-kernel@vger.kernel.org, 
	linux-hardening@vger.kernel.org, apparmor@lists.ubuntu.com, 
	linux-security-module@vger.kernel.org, keyrings@vger.kernel.org, 
	Song Liu <song@kernel.org>, "Steven Rostedt (Google)" <rostedt@goodmis.org>, 
	"Martin K. Petersen" <martin.petersen@oracle.com>, "Darrick J. Wong" <djwong@kernel.org>, 
	Corey Minyard <cminyard@mvista.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 28, 2025 at 6:22=E2=80=AFAM Joel Granados <joel.granados@kernel=
.org> wrote:
> On Mon, Jan 27, 2025 at 03:42:39PM +0000, Matthew Wilcox wrote:
> > On Mon, Jan 27, 2025 at 04:55:58PM +0200, Jani Nikula wrote:
> > > You could have static const within functions too. You get the rodata
> > > protection and function local scope, best of both worlds?
> >
> > timer_active is on the stack, so it can't be static const.
> >
> > Does this really need to be cc'd to such a wide distribution list?
> That is a very good question. I removed 160 people from the original
> e-mail and left the ones that where previously involved with this patch
> and left all the lists for good measure. But it seems I can reduce it
> even more.
>
> How about this: For these treewide efforts I just leave the people that
> are/were involved in the series and add two lists: linux-kernel and
> linux-hardening.
>
> Unless someone screams, I'll try this out on my next treewide.

I'm not screaming about it :) but anything that touches the LSM,
SELinux, or audit code (or matches the regex in MAINTAINERS) I would
prefer to see on the associated mailing list.

--=20
paul-moore.com


From xen-devel-bounces@lists.xenproject.org Tue Jan 28 15:56:51 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 15:56:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878594.1288775 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcnxG-00057v-VP; Tue, 28 Jan 2025 15:56:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878594.1288775; Tue, 28 Jan 2025 15:56:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcnxG-00057o-RQ; Tue, 28 Jan 2025 15:56:46 +0000
Received: by outflank-mailman (input) for mailman id 878594;
 Tue, 28 Jan 2025 15:56: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 <SRS0=jygh=UU=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcnxF-00057g-IK
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 15:56:45 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7824990b-dd90-11ef-99a4-01e77a169b0f;
 Tue, 28 Jan 2025 16:56:43 +0100 (CET)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-5d7e3f1fc01so12082993a12.2
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 07:56:43 -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
 a640c23a62f3a-ab675e63187sm819086466b.54.2025.01.28.07.56.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 28 Jan 2025 07:56:42 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 7824990b-dd90-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738079803; x=1738684603; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=K+Jc7LX022C3BYlmGfVU8QtvBWEmBStKt5P8xHN9Qic=;
        b=OMxQHpD+32FCUJE2EPe5fQlSPX6DR+jvncdZU/LBMMS38wN2hXKWpUPU9EdaPNsJsL
         dIgQynCLAf4MX2VAsfNJzF7htCLdBvsNbaxQKsfvpxzO/xumeVuqInu0E1DDe/89QRsB
         OsjpXrC+DKo3Y9jvy1MspA/i3moA198s4iCRgDEi7r5T8CD3Yc3BaC6RyMf6pqVC9X/U
         yX922I+Vd69tg0rdGucxgS3Zn2u7EBXNhAkLGy5VT1H0jkYuq6AcQ7ATmBU6CzpM2CPh
         AHQ4Tjzf1rVuCsKtsIw/p0kNVM8GdJrohHK/piROqWuXeIYDc98ZguZSaV9ocw/MHxJH
         i7fw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738079803; x=1738684603;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=K+Jc7LX022C3BYlmGfVU8QtvBWEmBStKt5P8xHN9Qic=;
        b=tmjhPwjCLqvlXmEQE/gcOAbIB1rQ/uP6y7QyUm6/F/5bb6K1qFJ0wEgKTtDKukk7mI
         blrjo/wv0OVLfLiThiOxCWNSS6qF6JXDwt5DoahhKxBZ2KDn3j1LZ1T4aUn4bHPndlW0
         nAeLvUuyYV9cZOt78DeJQeWGv1UZIymYj6eOxYR7hXX00RgtEl5DBP6v2TIXD7ZDkZYg
         7RRnrWrBvRN502Dc/32Hd8cXVfMe364QINaEHDEwtaUi8FzQVxfnxMCfNS5GMDTWFesc
         4x1a4+rCDtoJW+aUsOQfG4FViK88oG2DmOnXai5jRUt9EYU/R/hhvyssUdEQ7Y2dFkuo
         w+Mg==
X-Forwarded-Encrypted: i=1; AJvYcCUsnxiuuK1PFDfhxXgCbJceV+BWUsBIIyKRXTD2RXcx3ew/XvxZzZDFUwEHrvASrZsh5usAs9kvg48=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwsR0xbqwH87er7EmTiek97oFgWyhbCbq0EjZ9zruQq07/spj4x
	/kPJ9A2tGy0mZOgvrZgQbiLEe7uk+cD+FGgoMepoBs43gL9Rv1Y2jkyJyrkEnQ==
X-Gm-Gg: ASbGncvZJ7HXjnB0y9RN08mJmh2pr5+6dBgLG4cyOAsLbNMjuhHHpageReI2DVjfc9f
	1LsVkwEHIv6T+ryRuyr2SmPMgHHKZ51mXi33kpn3XztDZtSEtga1kzKSII78Y5SxjTHsvEZwY50
	A3SEt/8ZlyiORJc7NDVhPSNyhKNJYtrSvGMq+6eqtKWE1MVGoEza4ZMJ4Vzs6GSv3BxmI9A66uh
	os4VPI9XbujwLhS1zK2joGMK9yy5MlqP7Nq4uUAA/HxM5CSwnfQHPTgfM9g/hR0SaH98KGGq0YH
	hjRsIZgC53eStDMWDvOSDuh+2p17NMBQZOW9hCmoacDVhEYumYSU8+It4BQIkbnZgQibdIjButO
	J
X-Google-Smtp-Source: AGHT+IHj//euB364E2sx2WN8+ni21ZMA0mHu/ZQYZEb6ibuK+tS/EZIcVdQIwdwECM0OHIdeGo2PdQ==
X-Received: by 2002:a17:907:2cc5:b0:ab2:c78f:e4ae with SMTP id a640c23a62f3a-ab38b12a246mr4463393666b.20.1738079802689;
        Tue, 28 Jan 2025 07:56:42 -0800 (PST)
Message-ID: <1297dd85-631b-45dc-9839-6488744aed34@suse.com>
Date: Tue, 28 Jan 2025 16:56:41 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 13/24] xen/console: introduce hwdom_crashconsole=
To: dmukhin@ford.com
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
 <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
 <20250103-vuart-ns8250-v3-v1-13-c5d36b31d66c@ford.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250103-vuart-ns8250-v3-v1-13-c5d36b31d66c@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04.01.2025 02:58, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin <dmukhin@ford.com>
> 
> The new command line switch `hwdom_crashconsole=BOOL` allows to switch serial
> console input focus to xen for machine state inspection using keyhandler
> mechanism after the hardware domain crashes.
> 
> The new command line switch is aliased via `dom0=...,crashconsole` knob.
> 
> Such functionality can be useful while debugging dom0 bringup.
> 
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>

First, going back to what was said on the earlier version of the series as
a whole: Is this really strictly related (i.e. in preparation of) adding
the vNS16550 driver? As previously indicated, it would help if the series
focused on its main goal, with less tightly related stuff kept for later
(or submitted independently where possible).

> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -822,6 +822,7 @@ Specify the bit width of the DMA heap.
>  
>  ### dom0
>      = List of [ pv | pvh, shadow=<bool>, verbose=<bool>,
> +                crashconsole=<bool>,
>                  cpuid-faulting=<bool>, msr-relaxed=<bool> ] (x86)
>  
>      = List of [ sve=<integer> ] (Arm64)
> @@ -855,6 +856,10 @@ Controls for how dom0 is constructed on x86 systems.
>      information during the dom0 build.  It defaults to the compile time choice
>      of `CONFIG_VERBOSE_DEBUG`.
>  
> +*   The `crashconsole` boolean instructs Xen to switch input console focus to
> +    the hypervisor when dom0 shuts down and avoid performing dom0 domain
> +    destruction.  Should only be used for debugging purposes.
> +
>  *   The `cpuid-faulting` boolean is an interim option, is only applicable to
>      PV dom0, and defaults to true.

With this, ...

> @@ -1491,6 +1496,15 @@ Specify whether guests are to be given access to physical port 80
>  (often used for debugging purposes), to override the DMI based
>  detection of systems known to misbehave upon accesses to that port.
>  
> +### hwdom_crashconsole
> +> `= <boolean>`
> +
> +> Default: `false`
> +
> +The `hwdom_crashconsole` boolean instructs Xen to switch input console focus to
> +the hypervisor when dom0 shuts down and avoid performing dom0 domain
> +destruction.  Should only be used for debugging purposes.

... do we then need this? We're kind of trying to limit the number of new
top-level options.

Then: Please prefer dashes over underscores in new command line options.

> --- a/xen/arch/x86/dom0_build.c
> +++ b/xen/arch/x86/dom0_build.c
> @@ -286,6 +286,8 @@ int __init parse_arch_dom0_param(const char *s, const char *e)
>          opt_dom0_cpuid_faulting = val;
>      else if ( (val = parse_boolean("msr-relaxed", s, e)) >= 0 )
>          opt_dom0_msr_relaxed = val;
> +    else if ( (val = parse_boolean("crashconsole", s, e)) >= 0 )
> +        opt_hwdom_crashconsole = !!val;

No need for !! when the lhs is of type bool (as can be seen in two
examples in context).

> @@ -1162,7 +1169,12 @@ int domain_shutdown(struct domain *d, u8 reason)
>      reason = d->shutdown_code;
>  
>      if ( is_hardware_domain(d) )
> -        hwdom_shutdown(reason);
> +    {
> +        if ( opt_hwdom_crashconsole )
> +            console_set_owner(DOMID_XEN);
> +        else
> +            hwdom_shutdown(reason);
> +    }

And how will the rest of the system be halted? Keeping Xen alive
is one thing; keeping domains alive is another (and imo not
acceptable). You don't need to destroy them, but you want to pause
them all.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 28 15:58:43 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 15:58:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878601.1288785 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcnz8-0005gi-9D; Tue, 28 Jan 2025 15:58:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878601.1288785; Tue, 28 Jan 2025 15:58:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcnz8-0005gb-6D; Tue, 28 Jan 2025 15:58:42 +0000
Received: by outflank-mailman (input) for mailman id 878601;
 Tue, 28 Jan 2025 15:58:41 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=jygh=UU=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcnz7-0005gU-73
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 15:58:41 +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 bdd32946-dd90-11ef-a0e6-8be0dac302b0;
 Tue, 28 Jan 2025 16:58:40 +0100 (CET)
Received: by mail-ed1-x52f.google.com with SMTP id
 4fb4d7f45d1cf-5d3d14336f0so9878456a12.3
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 07:58:40 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab675e124fasm802633766b.22.2025.01.28.07.58.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 28 Jan 2025 07:58:39 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: bdd32946-dd90-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738079920; x=1738684720; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=euMZ8VO56xTjyz+Qq21x3Voc1RfClAZu5uDyO4I8Lac=;
        b=GjF6Z3JxxILCfL6RorWIlyJI+Qufdg1OZ79OoZT71UTiLnlzUgVWtDsZ62kREtNpJx
         f+QPe+JWFZh5lB0YfSNIb1c0mI9ifr+LJA64QMDyA+Bne5fbxEHgNBWvjnODRIVCXnHC
         2CVzJn5ALsTvcWnkVFgE1V/g2fXb/+CCIawRTN3bbu0WmOvr90KMCR24e+urxj3DqRiP
         adtNe8bKV47BFIXupDUEEXnU5zac7FeUpbLjpKJzJmI2cyh9hN3dMqw8H3XCwSNk8CRA
         c3fZeQpgDSyPwxP3PzUTM0etj/f6v+wUJvkXJw2u+ZIf/DAKhaKFuLecwQgtXJ8x43gV
         Tx6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738079920; x=1738684720;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=euMZ8VO56xTjyz+Qq21x3Voc1RfClAZu5uDyO4I8Lac=;
        b=kdGf7bnn34ex0dAcxaqU3v8V+hIVAmMpWmXyDY/u4hes3IX9zl0pqSCL/1L9PR4Ktc
         Owt1EFeu7gd035M4+IQrxszYtxxZ6lg/u9xs2yVXSVqHgLHpLNmIRi0B+R2Dsbs4WcTw
         TA+0fAglm1AVhpEDXeQh3frjB/KEAToOwblz8wyTCGmwhePW7ZvuikmKvkb5AtNHfXse
         W407JhDySw9GFh3OTreRovZn2hT1/9eg0VVV5fJq8jB+3KWFFYE6rZvbd2YcZPyDS6oZ
         JmCCHHFzCiRobeAIMiHnJXOVOuNGdKzBMygz98ZhpdyKmi3WycR48Fk/aPcxHk4Nnu32
         nw5A==
X-Forwarded-Encrypted: i=1; AJvYcCUB3vGMdkAZaNz+ljJgHCCQ40/65KSCdN+lFLnF5qkcZQULluMno+AynSHYm43MhXNIEmVNp2upKoU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyKsnVg3cTSLyyy28VvCoKjlA5FKGZ/msHlCwNA3ICGUh/qTpCt
	SYhtMl8eAnuacZOha7n2+czUQXHRyb7kv2lZYl8rQ3bHQXY3Ql7jh+ODUMbe6w==
X-Gm-Gg: ASbGnctkuSvf7v5mXHchcUBo+jBcgcWzOGA2bGrayPcvAsi+JXhiyROZhKLueUQNDNa
	L9MSxFuJVm2gMAuPFC0wjnzObva8jXnD3WjkHISw1+1eeNJPhP8YcdX23b3rjIUNxSLiM9Ug7B4
	kEeV5jE7amCUE6OD2BcRpFpmPPQ7yGFJrE6xB3cdVgQLuuXS+X+8dM/9XfyRYD7RkPgDVjNsNMz
	RSUcetudjk+WMsxg9Le/zix/L+5LvfBsqJIjRxAWbQIbf4JRxjwOg0pmIP3gAy4TUMaFg39JBJ/
	OwYkMDYNvwbW7AoPlNh7/j2+HCWXqUCeqs9Mz4ecYqDFn4h2D7IkVjW0u1NjkfhoT8YmWeqWcJV
	h
X-Google-Smtp-Source: AGHT+IEzt9CYU0p2BNDPNv/n7KxwShSyq1miGS2BI6UfJ5HHSd3kci2yuINog1ecaBWpgkl1gqk3Gw==
X-Received: by 2002:a17:907:2ce3:b0:aa6:8d51:8fdb with SMTP id a640c23a62f3a-ab38b240a67mr4038528466b.19.1738079919695;
        Tue, 28 Jan 2025 07:58:39 -0800 (PST)
Message-ID: <47503710-f70d-40f3-8d45-cf6f517ec415@suse.com>
Date: Tue, 28 Jan 2025 16:58:38 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 14/24] xen/console: simplify console owner switch hint
To: dmukhin@ford.com
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
 <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
 <20250103-vuart-ns8250-v3-v1-14-c5d36b31d66c@ford.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250103-vuart-ns8250-v3-v1-14-c5d36b31d66c@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04.01.2025 02:58, Denis Mukhin via B4 Relay wrote:
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -518,8 +518,8 @@ int console_set_owner(domid_t domid)
>      console_owner = domid;
>  
>      if ( switch_code )
> -        printk(" (type 'CTRL-%c' three times to switch input)",
> -               opt_conswitch[0]);
> +        printk(" (type 'CTRL-%c%c%c' to switch input)",
> +               opt_conswitch[0], opt_conswitch[0], opt_conswitch[0]);

I view this as ambiguous: It could mean Ctrl-<?> Ctrl-<?> Ctrl-<?> or
Ctrl-<?> <?> <?>. Plus again - how's this related to the goal of the
series?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 28 15:58:57 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 15:58:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878604.1288795 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcnzN-00063p-Jx; Tue, 28 Jan 2025 15:58:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878604.1288795; Tue, 28 Jan 2025 15:58:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcnzN-00063i-GD; Tue, 28 Jan 2025 15:58:57 +0000
Received: by outflank-mailman (input) for mailman id 878604;
 Tue, 28 Jan 2025 15:58:56 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=ZLdl=UU=amd.com=Edgar.Iglesias@srs-se1.protection.inumbo.net>)
 id 1tcnzM-0005yC-J2
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 15:58:56 +0000
Received: from NAM04-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam04on20620.outbound.protection.outlook.com
 [2a01:111:f403:240a::620])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c4fa4fa0-dd90-11ef-99a4-01e77a169b0f;
 Tue, 28 Jan 2025 16:58:54 +0100 (CET)
Received: from BL1PR13CA0211.namprd13.prod.outlook.com (2603:10b6:208:2bf::6)
 by SJ2PR12MB7845.namprd12.prod.outlook.com (2603:10b6:a03:4ce::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.18; Tue, 28 Jan
 2025 15:58:47 +0000
Received: from MN1PEPF0000F0DF.namprd04.prod.outlook.com
 (2603:10b6:208:2bf:cafe::26) by BL1PR13CA0211.outlook.office365.com
 (2603:10b6:208:2bf::6) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8398.14 via Frontend Transport; Tue,
 28 Jan 2025 15:58:46 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 MN1PEPF0000F0DF.mail.protection.outlook.com (10.167.242.37) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8398.14 via Frontend Transport; Tue, 28 Jan 2025 15:58:46 +0000
Received: from localhost (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 28 Jan
 2025 09:58:45 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c4fa4fa0-dd90-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=KWv1uFZTBFxu5/AZ40nmMYQXw4ddSHlMfDhgrHR4TIq6GCHqEUQltDYNAqvHBWElRSPd6GPHnqWF/Pd/MmMOTT/sMR8QzAg92xuwNkXg4ZeAtbwI6CoyKtRe6vacjFsvWSzQ/jnK8XWLq81je8g+CFzinTf/fCrdDadpXvGbvS1PzuTtmoElcv2nOgnkE+qSzP7LitED9IywV4akpfh0NDfwlhyg1NEVVJngDNqoqQRzIhwLJYtBWsfYcdfKKnexwgY00UP5cQxlJatDakwcSl7tOD4RVKHTM5NKocKuUmWENlPoF3HHCjpSGS3ntPs1ID7e6tswMOhG6QarHOvMwQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=LEhsfYBVZQo4xIDSDB11GyqSin8BWPKS2GpjOm8/svY=;
 b=YyNX74QiTekndLn1W2TP2hnEsMM7fj5p9QW4J0tDwpOFqP8cVPQi0FQGankqsKLTobTKCcdINBv5B+BFOAmkSR7vlibMXhDHmM34I8aSc/salWMnL2aPrJfVY74Wy8i3tjJuQt6GmXzhxAO9ZQTRbzIC8yeUe99zs6I8bn49dL7VO8Q4Pwhf+hpdrdiq0Q7Ig/bqjbGSE2mJ3jeK+nI/BPOEbVcvq0CH/lzZUMvufjLS1P9+uNxGwrCMJ2g9RAVuzyAFzaEKRiFhT4y36WedZGl+cA1ZmUOX8zTK8+VY85qRG0ot7YhsZPXz+SHJX7oC2QmPfL+45pej5f19eo4VXA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=aepfle.de 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=LEhsfYBVZQo4xIDSDB11GyqSin8BWPKS2GpjOm8/svY=;
 b=aZQmd0vr2SIZohc/BBbWSBpBwX59pRRshOhERXluPURhWJAJRKC2gW+jlvpTdcvM2nWQjFbxDtiyU9Ys3kDyjvp3eb41lcb8JC+ArY8qfVxpc6+r41xqQZaZJQX7hXA1CPPAoKvJyEZJ8BeJVm4IAgZ1qQoH53P/VvGC/HMOZPs=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Date: Tue, 28 Jan 2025 16:58:42 +0100
From: "Edgar E. Iglesias" <edgar.iglesias@amd.com>
To: Olaf Hering <olaf@aepfle.de>
CC: <xen-devel@lists.xenproject.org>, <sstabellini@kernel.org>,
	<jgross@suse.com>, Anthony PERARD <anthony@xenproject.org>, Paul Durrant
	<paul@xen.org>
Subject: Re: slow start of Pod HVM domU with qemu 9.1
Message-ID: <Z5j-bkdFZ7riavv7@zapote>
References: <20250128151544.26fc827d.olaf@aepfle.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20250128151544.26fc827d.olaf@aepfle.de>
User-Agent: Mutt/2.2.12 (2023-09-09)
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MN1PEPF0000F0DF:EE_|SJ2PR12MB7845:EE_
X-MS-Office365-Filtering-Correlation-Id: f19e9cb2-8b57-4332-c8f8-08dd3fb4a5c6
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|36860700013|376014|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?SeUZOXi3aZal8LBQn2cD4iH6o+DTEQTXqTokBaAYYfaOFvxfnZ5zUs0Cydtw?=
 =?us-ascii?Q?tTg0K67OSNxzSeuIdVLA03EM63b8a1DapTJRDrdUp2WWqsGYVIM3G7m8MFRA?=
 =?us-ascii?Q?a66jMkPihL/aXqK7J0t6HmOGUsFw4+UBSNT+nmhxxPQucAa94zpEOffJJYxJ?=
 =?us-ascii?Q?Dgj1tEfdabpVi2/7rOi9PtTtPB2Pdxcr2mLSfN3n3FP8DI8R3l55XZ6eHsEK?=
 =?us-ascii?Q?SCyK/LEYQ7PIzDvm9VhEu4TE/ztNCm/bw6WxH7cY+e9KTXMLw11MVWOOXYCD?=
 =?us-ascii?Q?YsWhGFpWU8yXSQxJYgpsNzUAOYGfwUJxTgGASATCHcaG/HTiB0hohwJ58I/F?=
 =?us-ascii?Q?XvvwceAPXx/s4o8HWfpy1HWS4GCZiGWuTYWyKTq/jAhoNmcltATVy8vqshgX?=
 =?us-ascii?Q?2XfzVUCAlr1DB0dYFZMrsONIwV21t7KtkPUkuJxsAI9ko2CjDObGlqWllgyN?=
 =?us-ascii?Q?LciFYvjkHob6vgTWvEIzLzriZY1WopzLGmi5tOnoCLWMoFwIBTJgJA3knS/y?=
 =?us-ascii?Q?f5I0LUsrZwrnLgI1uFbWVuhBV6eZRUqs6v5dLoEAzr8WTMvX1je+9GNqffqU?=
 =?us-ascii?Q?OKMUV2z2hnqvcdwv9Keb6+6M2pRBrhbXbt+g8KLb4CFVsIH+MXvGERCTxP7C?=
 =?us-ascii?Q?p3loQJV+EFUPoAcaWk6hux8SD6l0ZNu7iioFhOg1ojCgn1xtN8kBmDu8A4PW?=
 =?us-ascii?Q?jXokHD5tis6CqSe6wiAtWUkKAC5sXKgLuW+duJyTuXsJPKysltlhOmoIm9Bq?=
 =?us-ascii?Q?TlXRaLoogADxJJZHWFRNHVTVebskLsIWiXd5oOnCkh+jKDOlOhP8axzx9esp?=
 =?us-ascii?Q?dx3URFRTSO0gz0w75/TTiYEYAQQpf7prFfVcI4VLLtL2bp6OLJCM/gSHdvRY?=
 =?us-ascii?Q?NQeck5uyhqtZuugLFfXppcOofdN+kRqcb+uMEQgKnYUKTyCoCi9m5I34oEtU?=
 =?us-ascii?Q?ZkLtp242Kyn8Z/5q8t0LtDC1NuP6q5BmTX5oMB0IGzqlvktzRvb1VQNQCQSc?=
 =?us-ascii?Q?+lf7avhmccTysPZfbvh0qg1t4LBe9ZuEhhMBZlw+d54s1+T6CKvAWCT2NYXU?=
 =?us-ascii?Q?7J2GWdz/rnjaD77Rha+qisOZwVjAmB0cVk2xGeBHEGWe7kXuPclwbQ775jq3?=
 =?us-ascii?Q?FrTXRStncJNRzVbTD9B4whdLRNGcr+mGhuB9dsxc6jtAbNpcL6jYDU7InxqP?=
 =?us-ascii?Q?KIQUEFfVFbzDmiK+oHlsXhY9lnZT1MThIZsqohOhBrb/eui4yZq52YXWqEav?=
 =?us-ascii?Q?qpGDkWbwqb6z/LM4Y9ZBXu7dl3QkNSDwEOFidOxZabwzzIIbl8WJWj3NbVby?=
 =?us-ascii?Q?OzTkSUFgVJjBKpuGoQ3DawKa4fgrT4OMEmub9hHPTLmcEaZQqh97Xn5524iL?=
 =?us-ascii?Q?6qBm4BpLbHkAPbkSmD3pgBXIWGTTDnLMBfc2sQfYoqym2NFS/fF8LrSMJdAU?=
 =?us-ascii?Q?+alO67uorUcHXqsSn4fmmlzPyVxA2cKcPb63wMM2vkm8fzW21w7eMIG/CpkM?=
 =?us-ascii?Q?AS+7M7neH0eewso=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(376014)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2025 15:58:46.3628
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: f19e9cb2-8b57-4332-c8f8-08dd3fb4a5c6
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	MN1PEPF0000F0DF.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB7845

On Tue, Jan 28, 2025 at 03:15:44PM +0100, Olaf Hering wrote:
> Hello,
> 
> starting with qemu 9.1 a PoD HVM domU takes a long time to start.
> Depending on the domU kernel, it may trigger a warning, which prompted me
> to notice this change in behavior:
> 
> [    0.000000] Linux version 4.12.14-120-default (geeko@buildhost) (gcc version 4.8.5 (SUSE Linux) ) #1 SMP Thu Nov 7 16:39:09 UTC 2019 (fd9dc36)
> ...
> [    1.096432] HPET: 3 timers in total, 0 timers will be used for per-cpu timer
> [    1.101636] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
> [    1.104051] hpet0: 3 comparators, 64-bit 62.500000 MHz counter
> [   16.136086] random: crng init done
> [   31.712052] BUG: workqueue lockup - pool cpus=1 node=0 flags=0x0 nice=0 stuck for 30s!
> [   31.716029] Showing busy workqueues and worker pools:
> [   31.721164] workqueue events: flags=0x0
> [   31.724054]   pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=2/256
> [   31.728000]     in-flight: 17:balloon_process
> [   31.728000]     pending: hpet_work
> [   31.728023] workqueue mm_percpu_wq: flags=0x8
> [   31.732987]   pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=1/256
> [   31.736000]     pending: vmstat_update
> [   31.736024] pool 2: cpus=1 node=0 flags=0x0 nice=0 hung=30s workers=2 idle: 34
> [   50.400102] clocksource: Switched to clocksource xen
> [   50.441153] VFS: Disk quotas dquot_6.6.0
> ...
> 
> With qemu 9.0 and older, this domU will start the /init task after 8 seconds.
> 
> The change which caused this commit is qemu.git commit 9ecdd4bf08dfe4a37e16b8a8b228575aff641468
> Author:     Edgar E. Iglesias <edgar.iglesias@amd.com>
> AuthorDate: Tue Apr 30 10:26:45 2024 +0200
> Commit:     Edgar E. Iglesias <edgar.iglesias@amd.com>
> CommitDate: Sun Jun 9 20:16:14 2024 +0200
> 
>     xen: mapcache: Add support for grant mappings
> 
> As you can see, v4 instead of v5 was apparently applied.
> This was probably unintentional, but would probably not change the result.

Hi Olaf,

It looks like v8 was applied, or am I missing something?


> 
> With this change the domU starts fast again:
> 
> --- a/hw/xen/xen-mapcache.c
> +++ b/hw/xen/xen-mapcache.c
> @@ -522,6 +522,7 @@ ram_addr_t xen_ram_addr_from_mapcache(void *ptr)
>      ram_addr_t addr;
>  
>      addr = xen_ram_addr_from_mapcache_single(mapcache, ptr);
> +    if (1)
>      if (addr == RAM_ADDR_INVALID) {
>          addr = xen_ram_addr_from_mapcache_single(mapcache_grants, ptr);
>      }
> @@ -626,6 +627,7 @@ static void xen_invalidate_map_cache_entry_single(MapCache *mc, uint8_t *buffer)
>  static void xen_invalidate_map_cache_entry_all(uint8_t *buffer)
>  {
>      xen_invalidate_map_cache_entry_single(mapcache, buffer);
> +    if (1)
>      xen_invalidate_map_cache_entry_single(mapcache_grants, buffer);
>  }
>  
> @@ -700,6 +702,7 @@ void xen_invalidate_map_cache(void)
>      bdrv_drain_all();
>  
>      xen_invalidate_map_cache_single(mapcache);
> +    if (0)
>      xen_invalidate_map_cache_single(mapcache_grants);
>  }
>  
> I did the testing with libvirt, the domU.cfg equivalent looks like this:
> maxmem = 4096
> memory = 2048
> maxvcpus = 4
> vcpus = 2
> pae = 1
> acpi = 1
> apic = 1
> viridian = 0
> rtc_timeoffset = 0
> localtime = 0
> on_poweroff = "destroy"
> on_reboot = "destroy"
> on_crash = "destroy"
> device_model_override = "/usr/lib64/qemu-9.1/bin/qemu-system-i386"
> sdl = 0
> vnc = 1
> vncunused = 1
> vnclisten = "127.0.0.1"
> vif = [ "mac=52:54:01:23:63:29,bridge=br0,script=vif-bridge" ]
> parallel = "none"
> serial = "pty"
> builder = "hvm"
> kernel = "/bug1236329/linux"
> ramdisk = "/bug1236329/initrd"
> cmdline = "console=ttyS0,115200n8 quiet ignore_loglevel""
> boot = "c" 
> disk = [ "format=qcow2,vdev=hda,access=rw,backendtype=qdisk,target=/bug1236329/sles12sp5.qcow2" ]
> usb = 1
> usbdevice = "tablet"
> 
> Any idea what can be done to restore boot times?


A guess is that it's taking a long time to walk the grants mapcache
when invalidating (in QEMU). Despite it being unused and empty. We
could try to find a way to keep track of usage and do nothing when
invalidating an empty/unused cache.

Best regards,
Edgar


From xen-devel-bounces@lists.xenproject.org Tue Jan 28 16:28:25 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 16:28:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878622.1288804 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcoRj-0003O5-Qj; Tue, 28 Jan 2025 16:28:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878622.1288804; Tue, 28 Jan 2025 16:28:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcoRj-0003Ny-OG; Tue, 28 Jan 2025 16:28:15 +0000
Received: by outflank-mailman (input) for mailman id 878622;
 Tue, 28 Jan 2025 16:28: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
 <SRS0=00fH=UU=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tcoRi-0003Nh-9n
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 16:28:14 +0000
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com
 [2a00:1450:4864:20::334])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id dd5dbb0e-dd94-11ef-99a4-01e77a169b0f;
 Tue, 28 Jan 2025 17:28:11 +0100 (CET)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-436326dcb1cso40024185e9.0
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 08:28:11 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438bd4900e2sm174050885e9.24.2025.01.28.08.28.09
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 28 Jan 2025 08:28:09 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: dd5dbb0e-dd94-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1738081690; x=1738686490; 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=bfGHCk6ylqGUI3xZCBhS9XoBD9F0iDbrjpTzeSrCs9k=;
        b=bJNzahERuM9jAcjTLkXwQvIROVaFDnExdDd2gW7jBcgQxHDfSAW+hhIvmU9OUocRoW
         DSqw9gxbqk5pVLWrqrbaw63Ujib9DmGbPajGhZ38Osr3z8m8B1q5Ax3H4k2iAQSGqkfr
         hy60yg+CoXlLiMM08hy7utBw7Y5Y4FGvDXmKY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738081690; x=1738686490;
        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=bfGHCk6ylqGUI3xZCBhS9XoBD9F0iDbrjpTzeSrCs9k=;
        b=QkQCYdZsmcbRv6B92kWL7lY43WlScWqldqRXOSS+pl7JY+0kp+C8ZxYjcFPwTgR+ai
         AQIiHBBilfVJDwpbzFU7o8mDMs/c3Zqj+P46AMe2z+/62UpWI2Kd/VGiSDY1TtAyr79e
         9y20wJYHs/zLg1QirGNzrmOWfHVA6PfnO6F49YG7Tiu0dwObtVpmjjVCT3SoHce3voEA
         btSvyBGTQ8TeVWNqN+bWFFwAy5+L21pJGECQpmRAf4R5cxzKZyUdB/8D2XXnmjBDnPuY
         7ekcu9FkaUNfQPJLNomOB37YZhZu/Noqk+UUNk0PlwYVoH6Im1+RYo91Xp617v9yIt6I
         NptA==
X-Gm-Message-State: AOJu0YxRvWlTN5fbwIpzmbMpvyZjHx9r7MnJ6HVzINb2TAD6o2aEzpe6
	dCwUDyp3gJthiSf8trwXL5i1gQwZXSqLr3y8CTRQHJjjSokq9f+eJ4RdLNO9VNLii1Me4Y8laPW
	d
X-Gm-Gg: ASbGncuhHhrhobSyLMEtpPWmSHlHIcIOpZz7Q361AWGyvEZMO1qmJywlGpB1/hfQnOX
	Oc7Ew4+XMr5wdtpRT6GDSaWXTxzr7E1/UUn8fxneqYZt7ZnVoXk8knG5qsg4s99ei5PaYVMZvKi
	sxZ1qGN7bkR6Y+1DsmMIhsTmhl1rNo9qMHBLlzsrqN66Z6UdPj8/hkr8xYKrY1E8sCnG8mordCE
	uTrhQTfI7lRc12hekgtKrzc1amDf07j3Lbp1uwsEg3OtxePksaC3sHLGLdwLNrkeCpho8r+5bOk
	BPpARh3jA5RIB8l6al/J
X-Google-Smtp-Source: AGHT+IHH2eFbXY53zF4x9LgAzRtPh7a1FZtQWBbb4xMPa3oJK39nsHjbrHVv3z9wiW/gTyKn/ryZ6Q==
X-Received: by 2002:a05:600c:1d07:b0:436:488f:50a with SMTP id 5b1f17b1804b1-438913ef4b7mr431819065e9.17.1738081690282;
        Tue, 28 Jan 2025 08:28:10 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH for-4.20 0/2] x86/shutdown: prevent lapic "Receive accept error" errors on AMD
Date: Tue, 28 Jan 2025 17:27:40 +0100
Message-ID: <20250128162742.90431-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Hello,

The following series aims to fix the issues seeing during shutdown on
AMD boxes related to "Receive accept error" local APIC messages.

Fix patch aims to fix the issue, while second patch adjust fixup_irqs()
given it now has a single caller.

I think at least patch 1 should be considered for 4.20, as it fixes a
real issue on AMD boxes that prevents rebooting them.

Thanks, Roger.

Roger Pau Monne (2):
  x86/shutdown: quiesce devices ahead of AP shutdown
  x86/irq: drop fixup_irqs() parameters

 xen/arch/x86/crash.c           |  1 +
 xen/arch/x86/include/asm/irq.h |  4 ++--
 xen/arch/x86/include/asm/msi.h |  1 +
 xen/arch/x86/irq.c             | 30 +++++++++++++-----------------
 xen/arch/x86/msi.c             | 14 ++++++++++++++
 xen/arch/x86/smp.c             | 10 +++++-----
 xen/arch/x86/smpboot.c         |  2 +-
 xen/drivers/passthrough/pci.c  | 32 ++++++++++++++++++++++++++++++++
 xen/include/xen/pci.h          |  2 ++
 9 files changed, 71 insertions(+), 25 deletions(-)

-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 28 16:28:25 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 16:28:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878623.1288811 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcoRk-0003RF-49; Tue, 28 Jan 2025 16:28:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878623.1288811; Tue, 28 Jan 2025 16:28:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcoRj-0003Qt-VO; Tue, 28 Jan 2025 16:28:15 +0000
Received: by outflank-mailman (input) for mailman id 878623;
 Tue, 28 Jan 2025 16:28: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
 <SRS0=00fH=UU=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tcoRi-0003Ni-HS
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 16:28:14 +0000
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com
 [2a00:1450:4864:20::42e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id de2588e6-dd94-11ef-a0e6-8be0dac302b0;
 Tue, 28 Jan 2025 17:28:12 +0100 (CET)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-3862ca8e0bbso5198478f8f.0
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 08:28:12 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38c2a1bad87sm14559514f8f.74.2025.01.28.08.28.11
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 28 Jan 2025 08:28:11 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: de2588e6-dd94-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1738081692; x=1738686492; 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=CD81beFmPqaU1R9FOQxjBPyp+1ickihRrVRD2fGWEdE=;
        b=Smv+sZb4dNiGdnWum/Nv2lCuU9vVoZkfrzg/j3z7lgsAmtz+Svj6xMoLlRwb7socqW
         +za+Icrq0kmarjmimJBDO+YTa281/RsM8G65WkgEJuINP1MOvBxW779R0kJM8qQEeYaN
         4MlOcxKDGj50AWt6suqMJPT2cPRRa/Vw0sLJE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738081692; x=1738686492;
        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=CD81beFmPqaU1R9FOQxjBPyp+1ickihRrVRD2fGWEdE=;
        b=m07d/dVEf/6jCeETdSu/kwif/gRVFW78pDsJ0L/pw3s/378YKMrGnezbaxagstZKzf
         QKyqKuuyFKyfw7/nwkIeKrXQzUgTfKX6PtQxwxb6xnAkuVx0SojIv/iePU09xZGJWZFP
         lM3cStNF0ZaAUdjxpvuu65WR3GkZ1YE4NRZ7aNS6jXYUHUNpNJRaPv1z1NrHFvnOtKLv
         4Tm9Cmw3rWn1PNEUXNL2sxEckdqltnZwuEzifv0opb42sfpHq4jf+bwyR3wTwfzPDgyL
         tyhK+oUDpbtIhbHiXeKTVPegME7MwT34EbNHr4HC2CLoKAKTZVZliLj9mSBjXzjakoU9
         F1uA==
X-Gm-Message-State: AOJu0YwhXIEAqlkHVxkoC91CaQ2EcCuST/SK2e6uXqMWHYgQhI1SN5uE
	d6x0BFCZrSe6oYcfYQ7uoafHBeUetZklnP7Rp0Z0yQRlXo9o6pXvRf9EGX1/r0E0fYw1YcFyXLE
	Z
X-Gm-Gg: ASbGnctR1utRzzIDkm6+wxKlpxK1V3qA/EWA6DNecok5RgQmh1fWST4viaRXsGEuTJA
	dlb/YEhRhXkN4vDLgPaju0uAJdrjHWN/9INZ1pWFGeAtxTU3LYT2AIu7lvv95Ab66YsjwqNxown
	QE1inMVNGscHsHghtzgZsN7EUokNGWk1o/d/X6t7R2QNEj2R2WLn1qT2hKah+I7FfvjHEzqQmEm
	4fiYWM5tn3MUhgwlWTTL5uTBifElmBQ/AVf77wkGnkhcCdlLbSrj6F/PmKscIOcpJUy1eDrXRbl
	7F/zWh1UAPMtrIxTgAnY4Ga0mZxH1sQ=
X-Google-Smtp-Source: AGHT+IFT1mqzxuzpsPHaj5Q551xZdz3zB9BacWXjyIfD1UFaX6aPFzxddX6WMZwbn1IvIvZtuL0ojQ==
X-Received: by 2002:a05:6000:2a6:b0:385:eb7c:5d0f with SMTP id ffacd0b85a97d-38bf566a239mr42568251f8f.26.1738081691636;
        Tue, 28 Jan 2025 08:28:11 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH for-4.20 1/2] x86/shutdown: quiesce devices ahead of AP shutdown
Date: Tue, 28 Jan 2025 17:27:41 +0100
Message-ID: <20250128162742.90431-2-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250128162742.90431-1-roger.pau@citrix.com>
References: <20250128162742.90431-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The current shutdown logic in smp_send_stop() will first disable the APs,
and then attempt to disable (some) of the interrupt sources.

There are two issues with this approach; the first one being that MSI
interrupt sources are not disabled, the second one is the APs are stopped
before interrupts are disabled.  On AMD systems this can lead to the
triggering of local APIC errors:

APIC error on CPU0: 00(08), Receive accept error

Such error message can be printed in a loop, thus blocking the system from
rebooting.  I assume this loop is created by the error being triggered by
the console interrupt, which is further triggered by the ESR reporting
write to the console.

Intel SDM states:

"Receive Accept Error.

Set when the local APIC detects that the message it received was not
accepted by any APIC on the APIC bus, including itself. Used only on P6
family and Pentium processors."

So the error shouldn't trigger on any Intel CPU supported by Xen.

However AMD doesn't make such claims, and indeed the error is broadcasted
to all local APIC when for example an interrupt targets a CPU that's
offline.

To prevent the error from triggering, move the masking of IO-APIC pins
ahead of stopping the APs.  Also introduce a new function that disables
MSI and MSI-X on all PCI devices.  Remove the call to fixup_irqs() since
there's no point in attempting to move interrupts: all sources will be
either masked or disabled.

For the NMI crash path also call the newly introduced function, with the
hope that disabling MSI and MSI-X will make it easier for the (possible)
crash kernel to boot, as it could otherwise receive the same "Receive
accept error" upon re-enabling interrupts.

Note that this will have the side-effect of preventing further IOMMU
interrupts from being delivered, that's expected and at that point in the
shutdown process no further interaction with the IOMMU should be relevant.
Also note all current callers of smp_send_stop() do so after having called
console_start_sync(), so disabling the console interrupt won't hamper
console output.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/arch/x86/crash.c           |  1 +
 xen/arch/x86/include/asm/msi.h |  1 +
 xen/arch/x86/msi.c             | 14 ++++++++++++++
 xen/arch/x86/smp.c             | 10 +++++-----
 xen/drivers/passthrough/pci.c  | 32 ++++++++++++++++++++++++++++++++
 xen/include/xen/pci.h          |  2 ++
 6 files changed, 55 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/crash.c b/xen/arch/x86/crash.c
index a789416ca3ae..55a96d469f47 100644
--- a/xen/arch/x86/crash.c
+++ b/xen/arch/x86/crash.c
@@ -176,6 +176,7 @@ static void nmi_shootdown_cpus(void)
         x2apic_enabled = (current_local_apic_mode() == APIC_MODE_X2APIC);
 
         disable_IO_APIC();
+        pci_disable_msi_all();
         hpet_disable();
     }
 }
diff --git a/xen/arch/x86/include/asm/msi.h b/xen/arch/x86/include/asm/msi.h
index 63adb19820e8..7f9e531f73e6 100644
--- a/xen/arch/x86/include/asm/msi.h
+++ b/xen/arch/x86/include/asm/msi.h
@@ -86,6 +86,7 @@ extern int pci_enable_msi(struct pci_dev *pdev, struct msi_info *msi,
 extern void pci_disable_msi(struct msi_desc *msi_desc);
 extern int pci_prepare_msix(u16 seg, u8 bus, u8 devfn, bool off);
 extern void pci_cleanup_msi(struct pci_dev *pdev);
+extern void pci_disable_msi_all(void);
 extern int setup_msi_irq(struct irq_desc *desc, struct msi_desc *msidesc);
 extern int __setup_msi_irq(struct irq_desc *desc, struct msi_desc *msidesc,
                            hw_irq_controller *handler);
diff --git a/xen/arch/x86/msi.c b/xen/arch/x86/msi.c
index e2360579deda..f53b50c98f2a 100644
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -1248,6 +1248,20 @@ void pci_cleanup_msi(struct pci_dev *pdev)
     msi_free_irqs(pdev);
 }
 
+static int cf_check disable_msi(struct pci_dev *pdev, void *arg)
+{
+    msi_set_enable(pdev, 0);
+    msix_set_enable(pdev, 0);
+
+    return 0;
+}
+
+void pci_disable_msi_all(void)
+{
+    /* Disable MSI and/or MSI-X on all devices. */
+    pci_iterate_devices(disable_msi, NULL);
+}
+
 int pci_reset_msix_state(struct pci_dev *pdev)
 {
     unsigned int pos = pdev->msix_pos;
diff --git a/xen/arch/x86/smp.c b/xen/arch/x86/smp.c
index 02a6ed7593f3..0cf03660214d 100644
--- a/xen/arch/x86/smp.c
+++ b/xen/arch/x86/smp.c
@@ -358,14 +358,15 @@ void smp_send_stop(void)
 {
     unsigned int cpu = smp_processor_id();
 
+    local_irq_disable();
+    disable_IO_APIC();
+    pci_disable_msi_all();
+    local_irq_enable();
+
     if ( num_online_cpus() > 1 )
     {
         int timeout = 10;
 
-        local_irq_disable();
-        fixup_irqs(cpumask_of(cpu), 0);
-        local_irq_enable();
-
         smp_call_function(stop_this_cpu, NULL, 0);
 
         /* Wait 10ms for all other CPUs to go offline. */
@@ -376,7 +377,6 @@ void smp_send_stop(void)
     if ( cpu_online(cpu) )
     {
         local_irq_disable();
-        disable_IO_APIC();
         hpet_disable();
         __stop_this_cpu();
         x2apic_enabled = (current_local_apic_mode() == APIC_MODE_X2APIC);
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 777c6b1a7fdc..9782750f7902 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -1803,6 +1803,38 @@ int iommu_do_pci_domctl(
     return ret;
 }
 
+struct segment_iter {
+    int (*handler)(struct pci_dev *pdev, void *arg);
+    void *arg;
+};
+
+static int cf_check iterate_all(struct pci_seg *pseg, void *arg)
+{
+    const struct segment_iter *iter = arg;
+    struct pci_dev *pdev;
+
+    list_for_each_entry ( pdev, &pseg->alldevs_list, alldevs_list )
+    {
+        int rc = iter->handler(pdev, iter->arg);
+
+        if ( rc )
+            return rc;
+    }
+
+    return 0;
+}
+
+int pci_iterate_devices(int (*handler)(struct pci_dev *pdev, void *arg),
+                        void *arg)
+{
+    struct segment_iter iter = {
+        .handler = handler,
+        .arg = arg,
+    };
+
+    return pci_segments_iterate(iterate_all, &iter);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
index f784e9116059..d4c9837af722 100644
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -225,6 +225,8 @@ int pci_hide_device(unsigned int seg, unsigned int bus, unsigned int devfn);
 struct pci_dev *pci_get_pdev(const struct domain *d, pci_sbdf_t sbdf);
 struct pci_dev *pci_get_real_pdev(pci_sbdf_t sbdf);
 void pci_check_disable_device(u16 seg, u8 bus, u8 devfn);
+int pci_iterate_devices(int (*handler)(struct pci_dev *pdev, void *arg),
+                        void *arg);
 
 uint8_t pci_conf_read8(pci_sbdf_t sbdf, unsigned int reg);
 uint16_t pci_conf_read16(pci_sbdf_t sbdf, unsigned int reg);
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 28 16:28:25 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 16:28:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878624.1288816 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcoRk-0003Vv-Br; Tue, 28 Jan 2025 16:28:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878624.1288816; Tue, 28 Jan 2025 16:28:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcoRk-0003UB-68; Tue, 28 Jan 2025 16:28:16 +0000
Received: by outflank-mailman (input) for mailman id 878624;
 Tue, 28 Jan 2025 16:28: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
 <SRS0=00fH=UU=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tcoRi-0003Ni-Qd
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 16:28:14 +0000
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com
 [2a00:1450:4864:20::42c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id df285eb8-dd94-11ef-a0e6-8be0dac302b0;
 Tue, 28 Jan 2025 17:28:14 +0100 (CET)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-385d7b4da2bso5507860f8f.1
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 08:28:14 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38c2a1bb0d4sm14883704f8f.69.2025.01.28.08.28.12
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 28 Jan 2025 08:28:12 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: df285eb8-dd94-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1738081693; x=1738686493; 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=hnHpl/m5AWH7KgOy5WgkrsyIBrkq3GKBbJwmITZKh7E=;
        b=vj7zW69retZetKofy0xJHqUuRg88dw8F6kKZwO9jIIvuojG91IjAP1s74Lk0VLE4OJ
         uV5o+e+YS79WDPfHgBo5dUlFBIQcOVQlnUQHg5pnsml6zChu9XGV4EH/iTn4NoAR5ewx
         5g4NxKxs3zqq7fVP+RSY1zld6P2wkQgQJGg7k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738081693; x=1738686493;
        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=hnHpl/m5AWH7KgOy5WgkrsyIBrkq3GKBbJwmITZKh7E=;
        b=B0Jr8HvnXC7NmVDrD2gQ4Aax4XAgYxGOLHAkP/b/Zbt1z4qOB6fayNrRh+71m06FKx
         xfQQgtNlVlbmWYvD1PSWTXI4Py3XtPdQe/+ocb+uXxRuipaYfD6cAHCEpShuZ+T/C2Nt
         m7VVWcNrSHnaVE8Y0PVNegOTOMu9i6/BjlHedF3QXFI6GlD/vAhS37RDD7LfGLJepFuf
         nRtIhF2syvACeXaaQRKRG4bVJk9xgBK2GRCGIKryMynIgc5oziUA5Wt9WByFEWGfKdrz
         JFFzQNoaak7+xk2X30TLshaFP/+KSSdIgVmnA6X2Gyma5AUO5DraiiicJJ/5fzZ1Rzye
         Gqog==
X-Gm-Message-State: AOJu0Yy6Pzzyw3ffrILNnVaux/LGv7E9CdAp00HvM/kX5c1iW2IgPg1y
	qUWvJ734masV0kkwJEyZzBTeeNEhSwrOw8Ocl6Wa3kFuCyf0YlnviOzD+c5RYChnXj0TwmxwgyC
	1
X-Gm-Gg: ASbGncs68mG/4ZZHghWmE+Q/JZo2NDgLxnApg0X+RxY3lksmDel5910QgiQuje1W1p/
	MoYsNuI6PtlCnA3YxmvmeOWzkhc+Ni2jGwJzGS/AhHxO4PRK5dbo0GE7M7ZVzwJODfECp0E8nG/
	9vIIgsNipQaLjFrsiw5MvtZU9SvLclS+yQtd6oHnLNRvqrjOMuV1gifSx06lJDyEbhujY90N83y
	+0E0eTMf56P2tMcLTTl4Jo/1xxci7aDkmCYiC5zkwzLREvDIWSXuTOIX4Xr127TUwvsE6iXF9xr
	HlpwYVr/jtTtScAoT2VMxoZheKE2Dyg=
X-Google-Smtp-Source: AGHT+IHmQZTZKmzSN4EMPA4+MYUogYUFe6ox8dngn7MLh0/Pc/Sz4zd+ZoG+yXc6EgrOT6lW698cUw==
X-Received: by 2002:a05:6000:186f:b0:385:fa26:f0ac with SMTP id ffacd0b85a97d-38bf564926cmr39771375f8f.7.1738081692812;
        Tue, 28 Jan 2025 08:28:12 -0800 (PST)
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: [PATCH for-4.20 2/2] x86/irq: drop fixup_irqs() parameters
Date: Tue, 28 Jan 2025 17:27:42 +0100
Message-ID: <20250128162742.90431-3-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
In-Reply-To: <20250128162742.90431-1-roger.pau@citrix.com>
References: <20250128162742.90431-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The solely remaining caller always passes the same globally available
parameters.  Drop the parameters and modify fixup_irqs() to use
cpu_online_map in place of the input mask parameter, and always be verbose
in its output printing.

While there remove some of the checks given the single context where
fixup_irqs() is now called, which should always be in the CPU offline path,
after the CPU going offline has been removed from cpu_online_map.

No functional change intended.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
There's more cleanup that can likely be done here, but it's best if such
cleanup is done after the cpu_mask and old_cpu_mask irq_desc fields are
converted from cpu masks to integers, as logic delivery mode should never
be used for external interrupts now.
---
 xen/arch/x86/include/asm/irq.h |  4 ++--
 xen/arch/x86/irq.c             | 30 +++++++++++++-----------------
 xen/arch/x86/smpboot.c         |  2 +-
 3 files changed, 16 insertions(+), 20 deletions(-)

diff --git a/xen/arch/x86/include/asm/irq.h b/xen/arch/x86/include/asm/irq.h
index d3bc76806808..354868ba31ab 100644
--- a/xen/arch/x86/include/asm/irq.h
+++ b/xen/arch/x86/include/asm/irq.h
@@ -168,8 +168,8 @@ void free_domain_pirqs(struct domain *d);
 int map_domain_emuirq_pirq(struct domain *d, int pirq, int emuirq);
 int unmap_domain_pirq_emuirq(struct domain *d, int pirq);
 
-/* Evacuate interrupts assigned to CPUs not present in the input CPU mask. */
-void fixup_irqs(const cpumask_t *mask, bool verbose);
+/* Evacuate interrupts assigned to CPUs not present in the CPU online map. */
+void fixup_irqs(void);
 void fixup_eoi(void);
 
 int  init_irq_data(void);
diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index e56bacc88d84..ff3ac832f4b9 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -2590,17 +2590,21 @@ static int __init cf_check setup_dump_irqs(void)
 }
 __initcall(setup_dump_irqs);
 
-/* Evacuate interrupts assigned to CPUs not present in the input CPU mask. */
-void fixup_irqs(const cpumask_t *mask, bool verbose)
+/* Evacuate interrupts assigned to CPUs not present in the CPU online map. */
+void fixup_irqs(void)
 {
+    const unsigned int cpu = smp_processor_id();
     unsigned int irq;
     static int warned;
     struct irq_desc *desc;
 
+    /* Only to be called from the context of a CPU going offline. */
+    ASSERT(!cpu_online(cpu));
+
     for ( irq = 0; irq < nr_irqs; irq++ )
     {
         bool break_affinity = false, set_affinity = true, check_irr = false;
-        unsigned int vector, cpu = smp_processor_id();
+        unsigned int vector;
         cpumask_t *affinity = this_cpu(scratch_cpumask);
 
         if ( irq == 2 )
@@ -2644,12 +2648,6 @@ void fixup_irqs(const cpumask_t *mask, bool verbose)
         }
 
         if ( desc->arch.move_in_progress &&
-             /*
-              * Only attempt to adjust the mask if the current CPU is going
-              * offline, otherwise the whole system is going down and leaving
-              * stale data in the masks is fine.
-              */
-             !cpu_online(cpu) &&
              cpumask_test_cpu(cpu, desc->arch.old_cpu_mask) )
         {
             /*
@@ -2691,16 +2689,17 @@ void fixup_irqs(const cpumask_t *mask, bool verbose)
 
         /*
          * Avoid shuffling the interrupt around as long as current target CPUs
-         * are a subset of the input mask.  What fixup_irqs() cares about is
-         * evacuating interrupts from CPUs not in the input mask.
+         * are a subset of the online mask.  What fixup_irqs() cares about is
+         * evacuating interrupts from CPUs not in the online mask.
          */
-        if ( !desc->action || cpumask_subset(desc->arch.cpu_mask, mask) )
+        if ( !desc->action || cpumask_subset(desc->arch.cpu_mask,
+                                             &cpu_online_map) )
         {
             spin_unlock(&desc->lock);
             continue;
         }
 
-        if ( !cpumask_intersects(mask, desc->affinity) )
+        if ( !cpumask_intersects(&cpu_online_map, desc->affinity) )
         {
             break_affinity = true;
             cpumask_setall(affinity);
@@ -2716,7 +2715,7 @@ void fixup_irqs(const cpumask_t *mask, bool verbose)
          * the interrupt, signal to check whether there are any pending vectors
          * to be handled in the local APIC after the interrupt has been moved.
          */
-        if ( !cpu_online(cpu) && cpumask_test_cpu(cpu, desc->arch.cpu_mask) )
+        if ( cpumask_test_cpu(cpu, desc->arch.cpu_mask) )
             check_irr = true;
 
         if ( desc->handler->set_affinity )
@@ -2743,9 +2742,6 @@ void fixup_irqs(const cpumask_t *mask, bool verbose)
 
         spin_unlock(&desc->lock);
 
-        if ( !verbose )
-            continue;
-
         if ( !set_affinity )
             printk("Cannot set affinity for IRQ%u\n", irq);
         else if ( break_affinity )
diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 79a79c54c304..891a29fca146 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -1282,7 +1282,7 @@ void __cpu_disable(void)
 
     /* It's now safe to remove this processor from the online map */
     cpumask_clear_cpu(cpu, &cpu_online_map);
-    fixup_irqs(&cpu_online_map, 1);
+    fixup_irqs();
     fixup_eoi();
 }
 
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Tue Jan 28 16:32:11 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 16:32:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878649.1288835 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcoVW-0006Q5-TD; Tue, 28 Jan 2025 16:32:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878649.1288835; Tue, 28 Jan 2025 16:32:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcoVW-0006Py-QD; Tue, 28 Jan 2025 16:32:10 +0000
Received: by outflank-mailman (input) for mailman id 878649;
 Tue, 28 Jan 2025 16:32: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 <SRS0=jygh=UU=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcoVV-0006Ps-Uw
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 16:32:10 +0000
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com
 [2a00:1450:4864:20::435])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6a9645a7-dd95-11ef-99a4-01e77a169b0f;
 Tue, 28 Jan 2025 17:32:08 +0100 (CET)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-38633b5dbcfso6639602f8f.2
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 08:32: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
 a640c23a62f3a-ab69179d7c7sm578711566b.112.2025.01.28.08.32.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 28 Jan 2025 08:32:07 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 6a9645a7-dd95-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738081927; x=1738686727; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=UkCd7FMoo0J6NkVeEHdu6xmJCSHgM3opraZr/s1fnRg=;
        b=E27BLiXWCHlcqMhUvIV+l4ICS9P0+OwmLaG1fTM4smBWDdQ1G7cEyaOdml9dP/zCsg
         clWmSWP3fjGRYf6CWjV3WRbtlXUxiPozFHdAoUgS9kP3dR76E7RNSGW68BA75dvyPGR2
         FkNeQKsG/3zTq59kRUf194CP6Sf6r0O9cCpVVkgXPs4EtIYtysaVH1/5SGxAP8nWYAZV
         QV/pl3ncqPBAl7K7CvQ1Gub3E2XhTbbvj9QtCn/Ew9v2XuSRsdGPqHbOYN2pfrk/cVAc
         dS05+kG8zACthkU//btpN8sx/69qIll2RYAxniosjC6O4i+splYwOZsusmgvR9d34k+n
         xjfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738081927; x=1738686727;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=UkCd7FMoo0J6NkVeEHdu6xmJCSHgM3opraZr/s1fnRg=;
        b=vCoL8xWvxwH6eaArSqCVOorBWCPw/8LSxrTB0HtAvG3ukiT/tGFegGWR34Dvc8Eu5I
         Wszu9Nt9MPVor50TC9vT0ylqmYI3pYdyh5+jz+7eoN7Ze1yjUXT2kv0gvjlcXUVWkD2E
         FZgBHMUQ63CfMiGTuWVcOjzG/25KpR1MuSiVYrt1sm76f6YhznZyDZog7vsJw8ap1Nd8
         On0fVZ5JiD7+FJLYtsCGLKBempoEYqLiHgt6wGjaVbZ/81BpOhpCOqU7MnePcn01jvMX
         SSRjgOgqAlFFDU1O9MsjnN1yhe2GnM7RNvlodcC8HiHvoqyARUBt5Cvu5RL1Mrd8I7zf
         Rx3A==
X-Forwarded-Encrypted: i=1; AJvYcCXeURU2EJ463IYRpMDMzs0Tqb8sgWvie/Cxd7dpTgCQxvkRnfeHq0faX5AZ53HFlEQkD3jTcfL67mg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwqIDO1j0NOHFGMcagJ8nSbiV7N0z8KEFaSDwvadVwpq9TvkZ9q
	qw9K+BBw0KdXVit/FJQ2eP4YL+lw2VOSRerPFaOpLuUuaFrUzjqlMGBlEY6kQg==
X-Gm-Gg: ASbGncsD3EMLB8SQhtWf3BD1NQPz1vSUbIeVnOb8tJy8emCjkUBd2+FdJ6NXnnRlWnM
	UwtvCqAhn8noULwxL8jUkQEzC7kcx7hF22mcubJPoFDfz6dps99QyWwV7Wi2lR88r00zmuSbxeX
	gBcvPFVsayIJ1ULLp5+iT+rybftXSmdO5xyoa7kKj6MTxG+lQozuuh/LMP2JC6oU/Lsu87g8QD/
	oEA+3aTa8aaWfwJVed4ypP+76YiZsQCIP03Y9FcYB5/70emypbFm4rK6E68L9Upyx/s76T4r9vZ
	HY+rOyclJvD0MeiKsDMBxsnU6af1NKPVH6JQUBSwsszKLxVds0z3uwBZfGf9w9LN5DqWbscqLy5
	O
X-Google-Smtp-Source: AGHT+IHapNumHUc0+s5PUTlXuSriAJ3SYR0jIwhBcAr6R0GtwfMVnAiIsksKYBNOfHW3E39Il90NCQ==
X-Received: by 2002:a05:6000:186f:b0:385:fa26:f0ac with SMTP id ffacd0b85a97d-38bf564926cmr39788652f8f.7.1738081927522;
        Tue, 28 Jan 2025 08:32:07 -0800 (PST)
Message-ID: <d471f3b0-5638-47b3-927e-318b0575eaa3@suse.com>
Date: Tue, 28 Jan 2025 17:32:06 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 15/24] xen/console: make console buffer size
 configurable
To: dmukhin@ford.com
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
 <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
 <20250103-vuart-ns8250-v3-v1-15-c5d36b31d66c@ford.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250103-vuart-ns8250-v3-v1-15-c5d36b31d66c@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04.01.2025 02:58, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin <dmukhin@ford.com>
> 
> Add new CONRING_SIZE Kconfig parameter to specify the boot console buffer size
> in bytes. The value is rounded to the nearest power of 2 to match existing
> conring_size= behavior.
> 
> The supported range is [16KiB..128MiB].
> 
> Bump default size to 32 KiB.
> 
> Link: https://gitlab.com/xen-project/xen/-/issues/185
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>

As asked elsewhere already: How's this related to the goal of the series?

> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -423,12 +423,15 @@ The following are examples of correct specifications:
>      com1=baud=115200,parity=n,stop-bits=1,io-base=0x3f8,reg-width=4
>  
>  ### conring_size
> -> `= <size>`
> +> `= <size-in-bytes>`

May I direct you to the explanations near the top of the file? <size>
is a uniform term throughout this document, and wants to stay like this.

> --- a/xen/drivers/char/Kconfig
> +++ b/xen/drivers/char/Kconfig
> @@ -96,6 +96,17 @@ config SERIAL_TX_BUFSIZE
>  
>  	  Default value is 32768 (32KiB).
>  
> +config CONRING_SIZE
> +	int "Console buffer size"
> +	default 32768
> +	help
> +	  Select the boot console buffer size (in bytes).
> +	  Note, the value provided will be rounded down to the nearest power of 2.
> +	  Run-time console buffer size is the same as the boot console size,
> +	  unless enforced via 'conring_size=' boot parameter.

Maybe s/enforced/overridden/ ?

> +	  Default value is 32768 (32KiB). The supported range is [16KiB..128MiB].

Yet then there's no "range" directive.

> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -100,12 +100,15 @@ static int cf_check parse_console_timestamps(const char *s);
>  custom_runtime_param("console_timestamps", parse_console_timestamps,
>                       con_timestamp_mode_upd);
>  
> -/* conring_size: allows a large console ring than default (16kB). */
> +/* conring_size: allows a large console ring than default (32 KiB). */

As you touch this, also s/large/larger/ ?

>  static uint32_t __initdata opt_conring_size;
>  size_param("conring_size", opt_conring_size);
>  
> -#define _CONRING_SIZE 16384
> -#define CONRING_IDX_MASK(i) ((i)&(conring_size-1))
> +#define _CONRING_SIZE       (1UL << (31 - __builtin_clz(CONFIG_CONRING_SIZE)))
> +_Static_assert(_CONRING_SIZE >= 4096 && _CONRING_SIZE <= MB(128),
> +    "CONFIG_CONRING_SIZE must be in [4K..128M] range");

Hmm, 4k here as the lower bound, when in description and Kconfig it's
said to be 16k?

Also I fear _Static_assert() can't be used here, for not being supported
by all gcc versions we continue to permit being used on x86. That'll be
unnecessary anyway once you put in place the missing range directive in
Kconfig. (If something like this needed keeping, it would be
BUILD_BUG_ON() that you want to use instead. Which, yes, can only be
used inside a function. Hence why we have a number of build_assertions()
functions throughout the codebase.)

> +#define CONRING_IDX_MASK(i) ( (i) & (conring_size - 1) )

Once again - no blanks immediately inside parentheses, _except_ as
written in ./CODING_STYLE (i.e. in control flow statements).

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 28 16:34:13 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 16:34:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878660.1288872 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcoXU-0007ZK-6Q; Tue, 28 Jan 2025 16:34:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878660.1288872; Tue, 28 Jan 2025 16:34:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcoXU-0007XY-0w; Tue, 28 Jan 2025 16:34:12 +0000
Received: by outflank-mailman (input) for mailman id 878660;
 Tue, 28 Jan 2025 16:34:10 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=C4cq=UU=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tcoXS-00070Z-Rh
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 16:34:10 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b337f96f-dd95-11ef-a0e6-8be0dac302b0;
 Tue, 28 Jan 2025 17:34:10 +0100 (CET)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-aaec61d0f65so1272337166b.1
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 08:34:10 -0800 (PST)
Received: from localhost.localdomain ([217.156.233.154])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab6973090d0sm534810966b.18.2025.01.28.08.34.08
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 28 Jan 2025 08:34:08 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b337f96f-dd95-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1738082049; x=1738686849; 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=+utsPfRRtrSY+xEHr/3Olh5IQcbAme2skyUQu+gyGyU=;
        b=lUV2gTfZ4av3fC7ESoExMVIt7cXCnz3uh5zaRe7SNudIqD8kZbYbFJDSU533rt/MLv
         9XZ4/8fFTSpvAZAu+MbHUr4AY+Z9+I9MUdKyHkFqQtRS/zCFf+X9zoC+mr8f5JcaFmEG
         G3iMOQCTz0Y5CxuTGa05eznRL7rIwjSf5kVtg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738082049; x=1738686849;
        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=+utsPfRRtrSY+xEHr/3Olh5IQcbAme2skyUQu+gyGyU=;
        b=TmfkB30Y8hwAZaiIamgJ4zPxMYteYCYw77zWaE0VdylaGyBQfSmLByDfsJfLF2x+2E
         wzh2DPIF/8Pmd4H33y2r4Eh9r/7BQdjnWg+IPMy5v40W+3onM9xCkX2OMKcpH3vq055c
         SDqXct+HXxI28e9+L8/Aq5FkFQkCiXK2uN+cNn8FlkwlyEtOnK9PZO4fNRwgMdvk1c5y
         SElNfvfo64Tp/movoR8KdYdl1pc2uc566pP81Hk7HDP1KhL9Ii9v0DU/PGnNv8sjGwvi
         bPJjQrqnNzIgX4x0oS3hFLTEtviszOtPvzklXIkCoCDKYl/kZJ0yU1C+Wflh+Se9l+eT
         XfhQ==
X-Gm-Message-State: AOJu0YzvmpcP2sl8b2E11mgIXDxo9i/WvpNtapjOmEO8YfUOv+KUXqq2
	HH+CkH9sK24udjfX4WI9LFkxHKhrMJF6PuIkDCfqGcyt2dJWvXDn8rqtOzmxRPNqhcRtfE7R/1v
	v4KU=
X-Gm-Gg: ASbGnct2IWZ36H0b6msadiCOTW/97Kt+zpH+2CTijTpbGRPQnOl+g1SWMxFYw7UeIm/
	HScrduon7uG8G3o+kZyiuFUK9qa74l01yus4VbNe/ggtdN0SfMvEIGK3Ke2S7xo7ZuO338ktpDr
	7xHLNPF7g+f084MNqZUHumsK/z6Tojc5uAqH+qWT9IfUTvXKSqYMKGNzn6nuNUnhXikZPc1I+L8
	c3CD4QiW9bi6PZvRMHeZj8skiq6TiZSS+x+xvFlVxzYDJe9LmlrMRL/ZnSg6QBpKTo4fehpPisq
	WmIaDKumTQ8dQPRzEdtarqlMCRNpiF20/CLf5IY5
X-Google-Smtp-Source: AGHT+IGxoRvFXq/AMeIRrnMzVWApvagPN96I0pk458DBuIzbtfqHOiMu1ezo4GIdaBfzCaIuXSTNJQ==
X-Received: by 2002:a17:906:f5a3:b0:ab6:8435:20e7 with SMTP id a640c23a62f3a-ab684352150mr1403056366b.15.1738082049108;
        Tue, 28 Jan 2025 08:34:09 -0800 (PST)
From: Alejandro Vallejo <alejandro.vallejo@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Alejandro Vallejo <alejandro.vallejo@cloud.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>
Subject: [PATCH 3/3] tools/hvmloader: Skip writing MP tables if any CPU has an APIC ID >= 255
Date: Tue, 28 Jan 2025 16:33:42 +0000
Message-ID: <20250128163342.1491-4-alejandro.vallejo@cloud.com>
X-Mailer: git-send-email 2.48.1
In-Reply-To: <20250128163342.1491-1-alejandro.vallejo@cloud.com>
References: <20250128163342.1491-1-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

MP Tables have no means of representing APIC IDs wider than 255. At the
moment the effect is wrapping around which would give a corrupted table
with duplicate APIC IDs (some of them possibly the broadcast 255).

Skip writing it altogether. While it would be possible to restrict the
APs shown it's just not worth the work. Any OS that needs such
adjustments should not have been booted with that many vCPUs to begin
with.

Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
---
Changes with respect to v7 in the longer topology series:
  * This patch replaces the previous assert in hvmloader/mp_tables.c
---
 tools/firmware/hvmloader/config.h    | 1 +
 tools/firmware/hvmloader/hvmloader.c | 6 +++++-
 tools/firmware/hvmloader/smp.c       | 4 ++++
 3 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/tools/firmware/hvmloader/config.h b/tools/firmware/hvmloader/config.h
index 6e1da137d779..53be34e48a02 100644
--- a/tools/firmware/hvmloader/config.h
+++ b/tools/firmware/hvmloader/config.h
@@ -49,6 +49,7 @@ extern uint8_t ioapic_version;
 #define IOAPIC_ID           0x01
 
 extern uint32_t *cpu_to_apicid;
+extern uint32_t max_apicid;
 
 #define LAPIC_BASE_ADDRESS  0xfee00000
 
diff --git a/tools/firmware/hvmloader/hvmloader.c b/tools/firmware/hvmloader/hvmloader.c
index 4e330fc1e241..54299e27364d 100644
--- a/tools/firmware/hvmloader/hvmloader.c
+++ b/tools/firmware/hvmloader/hvmloader.c
@@ -389,7 +389,11 @@ int main(void)
 
     if ( (hvm_info->nr_vcpus > 1) || hvm_info->apic_mode )
     {
-        if ( bios->create_mp_tables )
+        /*
+         * Legacy MP tables hold strictly xAPIC IDs. Skip writing
+         * the tables altogether if we have IDs wider than 8bits.
+         */
+        if ( max_apicid < 0xFF && bios->create_mp_tables )
             bios->create_mp_tables();
         if ( bios->create_pir_tables )
             bios->create_pir_tables();
diff --git a/tools/firmware/hvmloader/smp.c b/tools/firmware/hvmloader/smp.c
index c61ed524f947..0a01cdc18caa 100644
--- a/tools/firmware/hvmloader/smp.c
+++ b/tools/firmware/hvmloader/smp.c
@@ -34,6 +34,9 @@ static int ap_callin;
 /** True if x2apic support is exposed to the guest. */
 static bool has_x2apic;
 
+/** Highest entry in `cpu_to_apicid`. */
+uint32_t max_apicid;
+
 /**
  * Lookup table of (x2)APIC IDs.
  *
@@ -61,6 +64,7 @@ static uint32_t read_apic_id(void)
 static void cpu_setup(unsigned int cpu)
 {
     uint32_t apicid = cpu_to_apicid[cpu] = read_apic_id();
+    max_apicid = max(max_apicid, apicid);
 
     printf(" - CPU%u[%u] ... ", cpu, apicid);
     cacheattr_init();
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Tue Jan 28 16:34:13 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 16:34:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878658.1288852 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcoXS-00074A-I1; Tue, 28 Jan 2025 16:34:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878658.1288852; Tue, 28 Jan 2025 16:34:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcoXS-000740-BQ; Tue, 28 Jan 2025 16:34:10 +0000
Received: by outflank-mailman (input) for mailman id 878658;
 Tue, 28 Jan 2025 16:34:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=C4cq=UU=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tcoXR-00070Z-6u
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 16:34:09 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b2371477-dd95-11ef-a0e6-8be0dac302b0;
 Tue, 28 Jan 2025 17:34:08 +0100 (CET)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-aa68b513abcso1177535766b.0
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 08:34:08 -0800 (PST)
Received: from localhost.localdomain ([217.156.233.154])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab6973090d0sm534810966b.18.2025.01.28.08.34.06
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 28 Jan 2025 08:34:06 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b2371477-dd95-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1738082047; x=1738686847; 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=k2wXYm4vj9zHpf4g1hT+h92PgyCXWbc4DWlhdSJr70A=;
        b=X5s30jRmyfQdoWdWUozrK1M0qmMXOTKAnhppKtURGyqvSyzZwA8t7DaeQUHk5OE1LL
         s2ljVLcMoYP8Ju9usGyUb1+tzI6DU+NXsGrRuJiBCGjD3yCCn0xeIJ4B2l4GGmaxaRSb
         8vm4Z8+tDyjZMH4ZuI4Ge7TxQDu4yXY6ZC9zw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738082047; x=1738686847;
        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=k2wXYm4vj9zHpf4g1hT+h92PgyCXWbc4DWlhdSJr70A=;
        b=AAiRs7ioN6fJtnl1g7KqxGuFRXnzwnACU7Yz2x/H/RKPeYifbeobk1oel3yjjvegb4
         a0AuAqlEwGcu5DOiZmpVL25NacaxPgE31Q55HJKjw1iu2rRiwbis9+ehZqGbgRf5LB5x
         uSYE4Dz2zXSeUW1GpxqT/S34yZpN13apC68AgXHfbJzJ2t7G/jlWeIWfYnoB7R0K2wNq
         S+YQDqLML47PNHV4ANHrFkGiSRQLCfPthbCuDXmGz+ySumUBium/0a7bkRBGhT1UenfU
         7ReFDPs/scXVxrTw/IiXLrZAVEf1vB9gM7DSANrEAFY4dnLbp+Fa5FPr7/J+HlvuU0tV
         48Jw==
X-Gm-Message-State: AOJu0Yx56ZlVY4ACB/55IiSI6BCILig0l9FGpn88vfb65u3BeYasTgm4
	DoJT2uCT9kb9WnPH488PJWjU80aqt7IsGwtddgjYWkF2Z8IKO2k7lNheczcogOOzkHJkWJHUWFJ
	6LA4=
X-Gm-Gg: ASbGnctqDrG7/QCg7k9SK9rL8bvn+MoQPwWvoPkSzVqSb2FqylDDZoHZftzQIW67V+k
	hl72fhZloT4+fo8sThWBQP3X5IitKB18O7+jGXuw56yPj1ZJh2iWO3mpFj3ETtQdVsd6Jpyo70I
	eqaoHEmCos6rLHsW0LjT+k8d3eQOysAmyhJHlZM9cIezgZCUP+fOG0l2SFX5ifqDoWZBkYMMWtS
	x5WnVxV2G+Avk9hQMTnIlr0w/QRoBIQ52kONRWECdUWvig/DFQziNJ4fN/R/rk0WfCUd1v90juU
	B40dXOXafFnaYEs0XR5zFLkX7sOENCcy8pTgRG6l
X-Google-Smtp-Source: AGHT+IEwuL9IleBtGqDhzoL9t0Kye8GCON7QSXArcXKY1+gnfx33mdQmIerjEV/aNAHSm8DDJZDfvA==
X-Received: by 2002:a17:907:72c6:b0:ab2:b84b:2dab with SMTP id a640c23a62f3a-ab38b163149mr5052649466b.30.1738082047389;
        Tue, 28 Jan 2025 08:34:07 -0800 (PST)
From: Alejandro Vallejo <alejandro.vallejo@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Alejandro Vallejo <alejandro.vallejo@cloud.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>
Subject: [PATCH 1/3] tools/hvmloader: Retrieve (x2)APIC IDs from the APs themselves
Date: Tue, 28 Jan 2025 16:33:40 +0000
Message-ID: <20250128163342.1491-2-alejandro.vallejo@cloud.com>
X-Mailer: git-send-email 2.48.1
In-Reply-To: <20250128163342.1491-1-alejandro.vallejo@cloud.com>
References: <20250128163342.1491-1-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Make it so the APs expose their own APIC IDs in a lookup table (LUT). We
can use that LUT to populate the MADT, decoupling the algorithm that
relates CPU IDs and APIC IDs from hvmloader.

Modified the printf to also print the APIC ID of each CPU, as well as
fixing a (benign) wrong specifier being used for the vcpu id.

Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
---
Changes from the v7 version of this patch in the longer topology series:
  * s/cpu_to_x2apicid/cpu_to_apicid/
    * Though, as I already stated, I don't think this is a good idea.
  * Dynamically size cpu_to_apicid rather than using HVM_MAX_VCPUS.
  * Got rid of the ap_callin removal. It's not as trivial if we don't
    want to assume cpu0 always has apicid=0. Part of the complaints on
    the previous versions involved the inability to do that.
  * For debugging sanity, I've added the apicid to the CPU boot printf.
      * Later on, toolstack will choose the APIC IDs and it's helpful
        to know the relationship in the logs.
      * While at it, fix the vcpu specifier s/%d/%u/
  * Check for leaf 0xb while probing for x2apic support.
---
 tools/firmware/hvmloader/smp.c | 43 +++++++++++++++++++++++++++++++++-
 1 file changed, 42 insertions(+), 1 deletion(-)

diff --git a/tools/firmware/hvmloader/smp.c b/tools/firmware/hvmloader/smp.c
index 1b940cefd071..c61ed524f947 100644
--- a/tools/firmware/hvmloader/smp.c
+++ b/tools/firmware/hvmloader/smp.c
@@ -31,9 +31,38 @@
 
 static int ap_callin;
 
+/** True if x2apic support is exposed to the guest. */
+static bool has_x2apic;
+
+/**
+ * Lookup table of (x2)APIC IDs.
+ *
+ * Each entry is populated for its respective CPU as they come online. This is
+ * required for generating the MADT with minimal assumptions about ID
+ * relationships.
+ */
+uint32_t *cpu_to_apicid;
+
+static uint32_t read_apic_id(void)
+{
+    uint32_t apic_id;
+
+    if ( has_x2apic )
+        cpuid(0xb, NULL, NULL, NULL, &apic_id);
+    else
+    {
+        cpuid(1, NULL, &apic_id, NULL, NULL);
+        apic_id >>= 24;
+    }
+
+    return apic_id;
+}
+
 static void cpu_setup(unsigned int cpu)
 {
-    printf(" - CPU%d ... ", cpu);
+    uint32_t apicid = cpu_to_apicid[cpu] = read_apic_id();
+
+    printf(" - CPU%u[%u] ... ", cpu, apicid);
     cacheattr_init();
     printf("done.\n");
 
@@ -104,8 +133,20 @@ static void boot_cpu(unsigned int cpu)
 void smp_initialise(void)
 {
     unsigned int i, nr_cpus = hvm_info->nr_vcpus;
+    uint32_t ecx, max_leaf;
+
+    cpuid(0, &max_leaf, NULL, NULL, NULL);
+    if ( max_leaf >= 0xb )
+    {
+        cpuid(1, NULL, NULL, &ecx, NULL);
+        has_x2apic = (ecx >> 21) & 1;
+        if ( has_x2apic )
+            printf("x2APIC supported\n");
+    }
 
     printf("Multiprocessor initialisation:\n");
+    cpu_to_apicid = scratch_alloc(sizeof(*cpu_to_apicid) * nr_cpus,
+                                  sizeof(*cpu_to_apicid));
     cpu_setup(0);
     for ( i = 1; i < nr_cpus; i++ )
         boot_cpu(i);
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Tue Jan 28 16:34:13 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 16:34:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878659.1288865 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcoXT-0007TB-O3; Tue, 28 Jan 2025 16:34:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878659.1288865; Tue, 28 Jan 2025 16:34:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcoXT-0007T4-Iv; Tue, 28 Jan 2025 16:34:11 +0000
Received: by outflank-mailman (input) for mailman id 878659;
 Tue, 28 Jan 2025 16:34:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=C4cq=UU=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tcoXR-00070Z-Rf
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 16:34:09 +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 b2b1284e-dd95-11ef-a0e6-8be0dac302b0;
 Tue, 28 Jan 2025 17:34:09 +0100 (CET)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-5d3d14336f0so9948170a12.3
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 08:34:09 -0800 (PST)
Received: from localhost.localdomain ([217.156.233.154])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab6973090d0sm534810966b.18.2025.01.28.08.34.07
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 28 Jan 2025 08:34:07 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b2b1284e-dd95-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1738082048; x=1738686848; 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=9PocrDZ9hDRaC7DH9mGBlVuageGkmPBew72m1MalZps=;
        b=SeDo6HQD43B9Tg2lusAh3ekHc4vMD/5YNWIknrkayvSjS6oakYijT1hiexy5ryRiLv
         9aJleiuV/nzBFAvFMIwByYA1sYqTlUVgeq4MRJ3DCBOj/En4+MjBSdaVUSzInMZw5HfL
         qMvJdYWwdKuUgoVyJHC0+Cn0T9b7XrsjlCzTE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738082048; x=1738686848;
        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=9PocrDZ9hDRaC7DH9mGBlVuageGkmPBew72m1MalZps=;
        b=jyFdlW1Vpdd3lqVnMOhIBDgsXTMJqiDhxvKrvFa2yGZEtI/cjfE09mZuKvifrpkNFQ
         B90LHUscZenWefrXdo84B8gIKGMEZdAomuvq7UdLAwmtQ1Fx5MmVYfiSVkWd3hcqT9n6
         y22iA8w6/QMZOx8MgpoxPox25uQGjsIdHmsC74exAzGuo65Wh4hgfbXYcQZBUjdqsrf1
         /3FI90nUCLeYKJUATb7Xlo1yqTho/Re+mbzXHru+l4W2IRyQOCgIibYpveapbIgbUxnX
         YzRRnCXMzL9rrcPgHhKI3DiHhps40hrFqT6nteruZSSBfbMA7ms9UcVuy/HomgfCua4J
         po3Q==
X-Gm-Message-State: AOJu0YyXnnDBdiZHS994OaA1epmlN89QKNqd7dQE4Nd/BCg5c6FRmJgX
	GZjOqbVx1s1qXKxX3A5E/FJvtgPu85nmkcwXz/Na8s7K3ncNl/JZySubE7cctQk3y43QsOTP9SP
	CYKQ=
X-Gm-Gg: ASbGncsi1ZeXEZkONS25SIXnDdHYJFMSwZp9R1IQqSgoYAWgEWztohC7MWdeeHw6RTV
	LdBqOa23UA3sF6+DFLoKcVr5eK2ToJ2kBkvU5JBc7BgrKP6nG5jeIDwdxwAHj3OPoeuasA9VbEO
	O5TtsI9es+v0j1bOOVmVVYH4wUE/IiUYOkqdzfJJYw/L7x46YF9RKK5OmPYd+XWoY8yt0tKwmMK
	sG35PwEGraGBZdLJ5Uvv2vvaLtACXuJHSZJJlro4KNM7dxwLD51dEnXX21g7xas+WgwAIvHg7RS
	gMn42nzBR8PJk4UB+oQ/B6wP6Y4rrAX0/SNtZCz7cx0qx7EJ+/o=
X-Google-Smtp-Source: AGHT+IEHvOHZ3rC79zgZtlrliUBcqHcZd/1yasALjI6l+oiiKoATwG1XM4JqoTd0amr0xZiVHwo+Tg==
X-Received: by 2002:a17:906:f598:b0:aa6:7933:8b26 with SMTP id a640c23a62f3a-ab38b1b17ecmr4577230966b.9.1738082048332;
        Tue, 28 Jan 2025 08:34:08 -0800 (PST)
From: Alejandro Vallejo <alejandro.vallejo@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Alejandro Vallejo <alejandro.vallejo@cloud.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>
Subject: [PATCH 2/3] tools/hvmloader: Replace LAPIC_ID() with cpu_to_apicid[]
Date: Tue, 28 Jan 2025 16:33:41 +0000
Message-ID: <20250128163342.1491-3-alejandro.vallejo@cloud.com>
X-Mailer: git-send-email 2.48.1
In-Reply-To: <20250128163342.1491-1-alejandro.vallejo@cloud.com>
References: <20250128163342.1491-1-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Replace uses of the LAPIC_ID() macro with accesses to the
cpu_to_apicid[] lookup table. This table contains the APIC IDs of each
vCPU as probed at runtime rather than assuming a predefined relation.

Moved smp_initialise() ahead of apic_setup() in order to initialise
cpu_to_apicid ASAP and avoid using it uninitialised. Note that bringing
up the APs doesn't need the APIC in hvmloader becasue it always runs
virtualized and uses the PV interface.

Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
---
Changes from v7 of the longer topology series:
  * Removed ASSERT() for the MP tables and merely skipped writing them
    if any vCPU has an APIC ID >=255.
---
 tools/firmware/hvmloader/config.h    | 3 ++-
 tools/firmware/hvmloader/hvmloader.c | 6 +++---
 tools/firmware/hvmloader/mp_tables.c | 2 +-
 tools/firmware/hvmloader/util.c      | 2 +-
 4 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/tools/firmware/hvmloader/config.h b/tools/firmware/hvmloader/config.h
index cd716bf39245..6e1da137d779 100644
--- a/tools/firmware/hvmloader/config.h
+++ b/tools/firmware/hvmloader/config.h
@@ -48,8 +48,9 @@ extern uint8_t ioapic_version;
 
 #define IOAPIC_ID           0x01
 
+extern uint32_t *cpu_to_apicid;
+
 #define LAPIC_BASE_ADDRESS  0xfee00000
-#define LAPIC_ID(vcpu_id)   ((vcpu_id) * 2)
 
 #define PCI_ISA_DEVFN       0x08    /* dev 1, fn 0 */
 #define PCI_ISA_IRQ_MASK    0x0c20U /* ISA IRQs 5,10,11 are PCI connected */
diff --git a/tools/firmware/hvmloader/hvmloader.c b/tools/firmware/hvmloader/hvmloader.c
index f8af88fabf24..4e330fc1e241 100644
--- a/tools/firmware/hvmloader/hvmloader.c
+++ b/tools/firmware/hvmloader/hvmloader.c
@@ -224,7 +224,7 @@ static void apic_setup(void)
 
     /* 8259A ExtInts are delivered through IOAPIC pin 0 (Virtual Wire Mode). */
     ioapic_write(0x10, APIC_DM_EXTINT);
-    ioapic_write(0x11, SET_APIC_ID(LAPIC_ID(0)));
+    ioapic_write(0x11, SET_APIC_ID(cpu_to_apicid[0]));
 }
 
 struct bios_info {
@@ -341,11 +341,11 @@ int main(void)
 
     printf("CPU speed is %u MHz\n", get_cpu_mhz());
 
+    smp_initialise();
+
     apic_setup();
     pci_setup();
 
-    smp_initialise();
-
     perform_tests();
 
     if ( bios->bios_info_setup )
diff --git a/tools/firmware/hvmloader/mp_tables.c b/tools/firmware/hvmloader/mp_tables.c
index 77d3010406d0..3c93a5c947d9 100644
--- a/tools/firmware/hvmloader/mp_tables.c
+++ b/tools/firmware/hvmloader/mp_tables.c
@@ -199,7 +199,7 @@ static void fill_mp_config_table(struct mp_config_table *mpct, int length)
 static void fill_mp_proc_entry(struct mp_proc_entry *mppe, int vcpu_id)
 {
     mppe->type = ENTRY_TYPE_PROCESSOR;
-    mppe->lapic_id = LAPIC_ID(vcpu_id);
+    mppe->lapic_id = cpu_to_apicid[vcpu_id];
     mppe->lapic_version = 0x11;
     mppe->cpu_flags = CPU_FLAG_ENABLED;
     if ( vcpu_id == 0 )
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index d3b3f9038e64..2d07ce129013 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -827,7 +827,7 @@ static void acpi_mem_free(struct acpi_ctxt *ctxt,
 
 static uint32_t acpi_lapic_id(unsigned cpu)
 {
-    return LAPIC_ID(cpu);
+    return cpu_to_apicid[cpu];
 }
 
 void hvmloader_acpi_build_tables(struct acpi_config *config,
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Tue Jan 28 16:34:13 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 16:34:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878657.1288845 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcoXS-00070x-7F; Tue, 28 Jan 2025 16:34:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878657.1288845; Tue, 28 Jan 2025 16:34:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcoXS-00070q-4I; Tue, 28 Jan 2025 16:34:10 +0000
Received: by outflank-mailman (input) for mailman id 878657;
 Tue, 28 Jan 2025 16:34:09 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=C4cq=UU=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tcoXR-00070a-87
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 16:34:09 +0000
Received: from mail-ej1-x643.google.com (mail-ej1-x643.google.com
 [2a00:1450:4864:20::643])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b1b17942-dd95-11ef-99a4-01e77a169b0f;
 Tue, 28 Jan 2025 17:34:07 +0100 (CET)
Received: by mail-ej1-x643.google.com with SMTP id
 a640c23a62f3a-aaf57c2e0beso1173066966b.3
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 08:34:07 -0800 (PST)
Received: from localhost.localdomain ([217.156.233.154])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab6973090d0sm534810966b.18.2025.01.28.08.34.05
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 28 Jan 2025 08:34:06 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b1b17942-dd95-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1738082046; x=1738686846; 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=kxkQhfjKvrf8HHDrNJTtmA9R4L9LSQEslDN3hWnIrF0=;
        b=gsqdnKNKa6hLcd+rz3BS+OCgECHBXNcRexl86HOASokHyDY7hbmSEzeJXH/shNTenW
         tdCxecUlSsPGvEljWoQqGqi3ZkD7sqcyFgKB9VYlg1KB/sIKwrMml1vQdHwsxDJ+85dt
         J5/jAC/f1ZtY7zv2j5YHG/lDhZlM4id3ZF4q4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738082046; x=1738686846;
        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=kxkQhfjKvrf8HHDrNJTtmA9R4L9LSQEslDN3hWnIrF0=;
        b=eJmU+WUvVHzt4W4wMBNV7yaXVtrWaJjRNJYXToLB1nkjcOTFndY46192WREOacmzv+
         n0jXJ52sbQhCWEHJx4fcQF1cQoZM+l24yTi8/BTPYGkF/V4ZWaRkuWa/M/Gb2macOh4R
         zhEAviE5fmucN5rl2AhXA3UWgu1uAS6OFQI+vCgs3HMV8r2GGgM0nrAFxhj8UApcS7aM
         ne9hRcjbu929BSGtJxH8RMdXOP5PLgg8RbXZKfEpWUNQM2yBL/Lf9f1GPdtMvgxea968
         YQ3quLKmcVWLke5kFVfN4uCbmOx7dNqGK9DP49P2sdFnN9PPM+ji/Kl4oTsf6BJ/Eopw
         W8eA==
X-Gm-Message-State: AOJu0YxLr+57ZQk2YOiUBHT6t1qQwgaxS6x3G/7JyQdJg1AtpwN4bX4K
	wN5KTaOQtDqGMps8717cB14+xjgPZES1REikBDrVm8rQyF0fuOHF2+Ev/c7Jx0XJmyv0pckd11M
	jyuIePQ==
X-Gm-Gg: ASbGncs/6+gF64xC/wKZxTVMQ0vnwi6ZeB1Nu9YXVjDFc8A1SkaFuaVXFfkiVUwGdfP
	8PQqNSQ0L1sCgFtm/lQlWY6ib9A6lrRMvqAHg5UyTKpMEmrAc9++YsbBBTdcJQhueUKueLRJdFu
	0HMJjsFSufL2ZUCA7lf7wvZ97zjPoVnn+kOurMHN5H/TToD32cN8md/DVIIfmr7RWneMu6o2RGD
	h9L6MRJa3zInjwxyXPMskgetUqqXuPUPrUVPMpc/e94VwT4CdRojr8nDN/zVz2DHQphMwsc2MUg
	jVLB/eMmB6EWklSA+E88Mf6963fW3oW5GUQuJENG
X-Google-Smtp-Source: AGHT+IEK6szVFEF/wz7XSVOj9YqpHityyfgkfOrDcP3vfyGQmfgp0qRqWAJBhw8l4b3iKbD8wOm51A==
X-Received: by 2002:a17:907:969f:b0:ab2:b863:b7fa with SMTP id a640c23a62f3a-ab38b43b915mr4376791066b.44.1738082046581;
        Tue, 28 Jan 2025 08:34:06 -0800 (PST)
From: Alejandro Vallejo <alejandro.vallejo@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: Alejandro Vallejo <alejandro.vallejo@cloud.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>
Subject: [PATCH 0/3] tools/hvmloader: Decouple APIC IDs from vCPU IDs
Date: Tue, 28 Jan 2025 16:33:39 +0000
Message-ID: <20250128163342.1491-1-alejandro.vallejo@cloud.com>
X-Mailer: git-send-email 2.48.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The hypervisor, hvmloader and the toolstack currently engage in a shared
assumption that for every vCPU apicid == 2 * vcpuid. This series removes such
assumption from hvmloader, by making it read the APIC ID of each vCPU and
storing it for later use.

The last patch prevents writing an MP Tables should we have vCPUs that can not
be represented there. That's at the moment dead code because all vCPUs are
currently representable in 8 bits. This will inavitably stop being true in the
future after we increase the maximum number of guest vCPUs.

This short series is extracted from v7 of the much longer "Expose consistent
topology to guests".

  https://lore.kernel.org/xen-devel/20241021154600.11745-5-alejandro.vallejo@cloud.com/

Changes with respect to the original patch on each individual patch.

Alejandro Vallejo (3):
  tools/hvmloader: Retrieve (x2)APIC IDs from the APs themselves
  tools/hvmloader: Replace LAPIC_ID() with cpu_to_apicid[]
  tools/hvmloader: Skip writing MP tables if any CPU has an APIC ID >=
    255

 tools/firmware/hvmloader/config.h    |  4 ++-
 tools/firmware/hvmloader/hvmloader.c | 12 ++++---
 tools/firmware/hvmloader/mp_tables.c |  2 +-
 tools/firmware/hvmloader/smp.c       | 47 +++++++++++++++++++++++++++-
 tools/firmware/hvmloader/util.c      |  2 +-
 5 files changed, 59 insertions(+), 8 deletions(-)

-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Tue Jan 28 16:48:30 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 16:48:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878695.1288884 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcolG-0002T1-6v; Tue, 28 Jan 2025 16:48:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878695.1288884; Tue, 28 Jan 2025 16:48:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcolG-0002Su-4D; Tue, 28 Jan 2025 16:48:26 +0000
Received: by outflank-mailman (input) for mailman id 878695;
 Tue, 28 Jan 2025 16:48: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 <SRS0=jygh=UU=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcolF-0002So-DD
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 16:48:25 +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 b06cc1d0-dd97-11ef-a0e6-8be0dac302b0;
 Tue, 28 Jan 2025 17:48:24 +0100 (CET)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-aab925654d9so1147973666b.2
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 08:48:24 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab6760fc4aasm811547266b.159.2025.01.28.08.48.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 28 Jan 2025 08:48:23 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b06cc1d0-dd97-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738082904; x=1738687704; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=K5WdeAugfw1zLhTjqfKX13AAha5zDWO0+XALTcJYz8g=;
        b=bW3p3LpaTnzItH68XuW6Mt+Sddmzn7f/eAMc+TQstTuMnf/WD4Q/yZAncLWoLRGYko
         e+hi75tK3JijM9C9DuSIIkzosRrsWAn1nBT4KGO8Z9YguWEdJsQjQoFVHwQ71qDPbULJ
         oEGSigDmdjAUOq7dvQEnaRz1Ka3fyeGjqdcF2g/nbicia3A2paBC7HjpyValb/BxKxIS
         ND8Ni2+/b9rdMl5Jr33Xo7Rc8HOwlQK1mgilDwmqhfxrLB+Uzx9ZN8DK0l/0RcS5hZii
         dSWlSXdV4p0wWSENYEeQPQcMoGTIHr61CNAkiwtyixy0T7kHXORw/5q11fK357jWyoCm
         2nCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738082904; x=1738687704;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=K5WdeAugfw1zLhTjqfKX13AAha5zDWO0+XALTcJYz8g=;
        b=D/0GYAfKZ50neDvcjcxGcc9Klotpl7pNJcDpih2dkhwDrkBnrGVNwQSc6J54en/hDK
         ZyEbjcO1HwPgNTxxmj3or35LQKu4jKDLn0ZXRG+a5nvdmW6Dgt/t6HSlluJYr8Y62X6z
         4FY16dQHoAE85ToDdMzc/+4jpxHk0KD3WRPW2+Q4yyOcqUCl4m5V5qvY/Isp3+qnXSSx
         oOdN4NBQV/vmHeubveZlmGKdI3lnkpHTYA/Dkg05EGuQJXLkf2VwOIp9INALSMZflvep
         2w8ezk6/hwIEWTH8q1m5jS2q87rQQ7gRH81pWwA6RiWRMxLnby6IqH+yIb3tHvlWGBJY
         nTJA==
X-Forwarded-Encrypted: i=1; AJvYcCX3wn9yYRuUU1HKAPDtNuwk9YnsDAxqAy4neDeWWkOYKr/mCMhX31x1f6cOqeqV6LHXPAS5xcnguRo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwghSz3drn+nFahA6SxZW4UciWoKwfO033PnZ2dgp3bCEUKTbw5
	DnTQvh4Y51bKv8iC1aNbvatWRalgEnG5aQV/w+J0PzNXXToXo715U9X1wOP0Ew==
X-Gm-Gg: ASbGncuQuUp9haWbu1pST9TQN9prwTmXOWA+utEhO1V4ZyH8anYuQcEqLRN4bHpiPc1
	DKH0QP5RaIrIQPc1C8Uba5VMxEI5cDnKmFhLA+pUjUwcVA+idLDMMQIGKCBjSg+KcE/PGrmI6eo
	+4QmhGCRvhmFmjCv3s8jvS+4OV8JGBUSP3p9lIR+pAHjN7kG4a2GCyJcxcRxZG8CkrgoSToCrX6
	LaVAWSj1tPIjN5hayXPWjaND0D0n8v/70YmaEiZOyWWQhFDpS+kli9/TwhVbWUIoJjMnj5QAQfy
	jMRQcfZZnr33Ub7y1rKD5QNT+azfpAaUUmGMV139Ya7qkToiczffAwL1aKXuda7SZKjzLYUqvL+
	NeMQouExkqdk=
X-Google-Smtp-Source: AGHT+IFKcoSrZF/TOHLWTTIGAqV+4mH4gauL+MSjCK70Hg7n7K38mI3aiRuclcGFw1PMkg3oilCeMg==
X-Received: by 2002:a17:907:72d0:b0:aa6:7cae:dba7 with SMTP id a640c23a62f3a-ab38b1e1dfcmr4683129366b.4.1738082903675;
        Tue, 28 Jan 2025 08:48:23 -0800 (PST)
Message-ID: <be8e6ec3-30d1-4d20-88a8-07698cc630fe@suse.com>
Date: Tue, 28 Jan 2025 17:48:22 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 16/24] xen/console: introduce console_write()
To: dmukhin@ford.com
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
 <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
 <20250103-vuart-ns8250-v3-v1-16-c5d36b31d66c@ford.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250103-vuart-ns8250-v3-v1-16-c5d36b31d66c@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04.01.2025 02:58, Denis Mukhin via B4 Relay wrote:
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -40,6 +40,11 @@
>  #include <asm/guest.h>
>  #endif
>  
> +/* Console flags. */
> +enum {
> +    CONSOLE_RING    = BIT(0, U),
> +};

These aren't console flags, but flags passed to the new console_write().
The comment wants adjusting accordingly, and I guess the enum would also
best move immediately ahead of the function.

> @@ -636,6 +641,16 @@ static void cf_check notify_dom0_con_ring(void *unused)
>  static DECLARE_SOFTIRQ_TASKLET(notify_dom0_con_ring_tasklet,
>                                 notify_dom0_con_ring, NULL);
>  
> +static bool console_locks_busted;
> +
> +static void conring_write(const char *str, size_t len)
> +{
> +    conring_puts(str, len);
> +
> +    if ( !console_locks_busted )
> +        tasklet_schedule(&notify_dom0_con_ring_tasklet);
> +}

This doesn't really need to be a separate function, does it?

> @@ -644,8 +659,47 @@ static inline void xen_console_write_debug_port(const char *buf, size_t len)
>                     : "=&S" (tmp), "=&c" (tmp)
>                     : "0" (buf), "1" (len), "d" (XEN_HVM_DEBUGCONS_IOPORT) );
>  }
> +
> +static void xen_console_write(const char *str, size_t len)
> +{
> +    if ( xen_guest )
> +        xen_hypercall_console_write(str, len);
> +    else
> +        xen_console_write_debug_port(str, len);
> +}

Nor does this, I suppose. The more that the sole call to here ...

>  #endif
>  
> +/*
> + * Write characters to console.
> + *
> + * That will handle all possible scenarios working w/ console
> + * - serial console;
> + * - VGA console (x86 only);
> + * - __HYPERVISOR_console_io hypercall (x86 only);
> + * - debug I/O port (x86 only);
> + * - PV console.
> + */
> +static void console_write(const char *str, size_t len, unsigned int flags)
> +{
> +    ASSERT(rspin_is_locked(&console_lock));
> +
> +    console_serial_puts(str, len);
> +    video_puts(str, len);
> +
> +#ifdef CONFIG_X86
> +    if ( opt_console_xen )
> +        xen_console_write(str, len);
> +#endif

... continues to sit in an #ifdef.

> @@ -666,28 +720,8 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer,
>  
>          if ( is_hardware_domain(cd) )
>          {
> -            /* Use direct console output as it could be interactive */

This comment looks like being removed with no replacement? Why?

>              nrspin_lock_irq(&console_lock);
> -
> -            console_serial_puts(kbuf, kcount);
> -            video_puts(kbuf, kcount);
> -
> -#ifdef CONFIG_X86
> -            if ( opt_console_xen )
> -            {
> -                if ( xen_guest )
> -                    xen_hypercall_console_write(kbuf, kcount);
> -                else
> -                    xen_console_write_debug_port(kbuf, kcount);
> -            }
> -#endif
> -
> -            if ( opt_console_to_ring )
> -            {
> -                conring_puts(kbuf, kcount);
> -                tasklet_schedule(&notify_dom0_con_ring_tasklet);
> -            }
> -
> +            console_write(kbuf, kcount, !!opt_console_to_ring);

Here you assume CONSOLE_RING is bit 0. Please don't create such (then
also un-annotated) implicit dependencies.

> @@ -788,33 +822,6 @@ long do_console_io(
>   * *****************************************************
>   */
>  
> -static bool console_locks_busted;
> -
> -static void __putstr(const char *str)
> -{

Please note the comment up from here, the tail of which is visible in
context. I wonder whether the new function wouldn't better live here,
then also reducing the diff quite a bit. Requiring a forward decl
for this to work isn't very nice, but a reasonable price to pay, I
think.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 28 16:56:59 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 16:56:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878704.1288895 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcotR-0004fP-Vu; Tue, 28 Jan 2025 16:56:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878704.1288895; Tue, 28 Jan 2025 16:56:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcotR-0004fI-TB; Tue, 28 Jan 2025 16:56:53 +0000
Received: by outflank-mailman (input) for mailman id 878704;
 Tue, 28 Jan 2025 16:56: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 <SRS0=jygh=UU=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcotQ-0004fA-Na
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 16:56:52 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id def4de09-dd98-11ef-a0e6-8be0dac302b0;
 Tue, 28 Jan 2025 17:56:51 +0100 (CET)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-aab6fa3e20eso992542866b.2
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 08:56:51 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab6760fbe92sm818784166b.131.2025.01.28.08.56.49
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 28 Jan 2025 08:56:50 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: def4de09-dd98-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738083411; x=1738688211; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=txK94ENtdQMm8AuKPokoFbuC4y9QJF+mwyg+VQoY2UM=;
        b=Xx8DIHvgamwIMe/eMEoM63QqlPIEAkCk1wiMWvpUpvKz+/KHAISNmRwvivIMx8FFPw
         o80mmS9VJxuNtgAJrttryps4kNhPY7dU702M2AV124mmECmKzGdmNktAfuYtMCUpYIKe
         5MhPXfXH3yzPG8hr3XkOyClYel/Kvdyo780Ee+UH0UiAD4kJGDhrwIcdbo8ttEsumwvv
         Rw47g/o6bBawi8BIEz99hSAosA7+R8pE0eDM75xkO/8HjBbAgexvq27yaoAGrKvpl9gx
         P5sdG+TfVeI6yl9OkVVTMjHm1u/l93tuhyZ3oD5yS1JvNk6NvD/keOsbpr8zspKt0iqs
         BM9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738083411; x=1738688211;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=txK94ENtdQMm8AuKPokoFbuC4y9QJF+mwyg+VQoY2UM=;
        b=ptNNfYQNsyw/aFSaFjK/hrqSZI//WdXtv6/BTYf70Etfh/jUBeSGf0btXeYwZCju+a
         +Js3cwctwgCoAcPQ4bzL3ugNVpfJAtKoE7ELkRGbNyGP6bA4B4sz1Gku2Fa9AGr1r7Kw
         YOxSFBmbv3WfU2RDhBLaxe1b+f5jF5eIGGU24QLpl8zPFwj7wJgrqPeiZwt1AaFLEvEj
         AyUBAKkULp+DIn33nWQf2dlb33qYR3p0q0j3CVbptrVS2+/qHnygw/V0YA5B+zZZR6b4
         qGNS1WBCLdPC5dRHwIgvUE1o1boWiVZlaO6gQRgdjkstqmgMhU7a154NpBtTLdekgSIo
         YNRg==
X-Forwarded-Encrypted: i=1; AJvYcCW9pZPfrEADK0y0yEqSrYuTqJhBwhOji75YXj5QXfbYKNsxevE+LDzXVmuqLzEuH9/4v5j9kvqekjE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwbuOiIpUQd+sAwcNpUcVBgRr4Gkvwhwt/AtYliKWQzFMZwfOaB
	8dPyaoL+es2S4xTuw+Yd2t9aKhGNaycDjM4ND8/KEDI0t+Oq78n6O9E9KmyloA==
X-Gm-Gg: ASbGncsmO8f/xgsF1ZYkTlYYy+l3mhRH8RzQf089/jcQf3rZP2hRpEBvNG/a9ApDwiz
	L5wxuNFYOG6iNrtqLo1BNq0yPhd1QtZUa0/aKyQ4K6iNvDMSUCCuzTGZiXgg9VeBMehGxnWTXUB
	FEUTxRa76HLDoUytIjC3rc7UOlAoC6+Ebl9gw2LEvwg5YCRvDN1BjgnQb9dMf2lW9uaLyXkeD+4
	hhW6bh+O32pFNr2KKmV/wxEltiZLkpwOTk+Icu5hGLGOHX7YzRfRIBjHcRBZvApFjZyYR54FvsN
	IhQEUq7wSFqK1wS2XxFN1JBKpn+XBGeLlWPfLLHNt7Un6gJDsU46R0DmRH/Emb1t6vKH5ina7tO
	D
X-Google-Smtp-Source: AGHT+IHHJOw76BjLXqGBnvw43my2VkhquZuadp84pDPIp2kf2AYFivbcZrggsA+azVQI8HRL2Yy1ZQ==
X-Received: by 2002:a17:906:d54d:b0:aae:bac6:6659 with SMTP id a640c23a62f3a-ab38b190d52mr3936652666b.7.1738083411199;
        Tue, 28 Jan 2025 08:56:51 -0800 (PST)
Message-ID: <58d99a7b-4f16-424e-bcbb-c2bc475bce82@suse.com>
Date: Tue, 28 Jan 2025 17:56:49 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 17/24] xen/console: flush console ring to physical
 console
To: dmukhin@ford.com
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
 <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
 <20250103-vuart-ns8250-v3-v1-17-c5d36b31d66c@ford.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250103-vuart-ns8250-v3-v1-17-c5d36b31d66c@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04.01.2025 02:58, Denis Mukhin via B4 Relay wrote:
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -430,23 +430,36 @@ void console_serial_puts(const char *s, size_t nr)
>      pv_console_puts(s, nr);
>  }
>  
> -static void cf_check dump_console_ring_key(unsigned char key)
> +/*
> + * Write characters to physical console(s).
> + * That covers:
> + * - serial console;
> + * - video output.
> + */
> +static void console_puts(const char *str, size_t len)
> +{
> +    ASSERT(rspin_is_locked(&console_lock));
> +
> +    console_serial_puts(str, len);
> +    video_puts(str, len);
> +}
> +
> +/*
> + * Flush contents of the conring to the physical console devices.
> + */
> +static int console_flush(void)
>  {
>      uint32_t idx, len, sofar, c;
>      unsigned int order;
>      char *buf;
>  
> -    printk("'%c' pressed -> dumping console ring buffer (dmesg)\n", key);
> -
> -    /* create a buffer in which we'll copy the ring in the correct
> -       order and NUL terminate */
>      order = get_order_from_bytes(conring_size + 1);
>      buf = alloc_xenheap_pages(order, 0);
>      if ( buf == NULL )
> -    {
> -        printk("unable to allocate memory!\n");
> -        return;
> -    }
> +        return -ENOMEM;
> +
> +
> +    nrspin_lock(&console_lock);

Nit: No double blank lines please.

> @@ -681,10 +707,7 @@ static void xen_console_write(const char *str, size_t len)
>   */
>  static void console_write(const char *str, size_t len, unsigned int flags)
>  {
> -    ASSERT(rspin_is_locked(&console_lock));

Why is this being dropped? Hmm, I see, it moves into console_puts().

> @@ -1061,6 +1084,9 @@ void __init console_init_preirq(void)
>      serial_set_rx_handler(sercon_handle, serial_rx);
>      pv_console_set_rx_handler(serial_rx);
>  
> +    /* NB: send conring contents to all enabled physical consoles, if any */
> +    console_flush();

Aren't you potentially emitting messages a 2nd time this way? Imo
such flushing needs to come immediately after any particular console
is ready.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 28 17:06:32 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 17:06:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878713.1288904 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcp2f-0006vn-Rk; Tue, 28 Jan 2025 17:06:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878713.1288904; Tue, 28 Jan 2025 17:06:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcp2f-0006vg-P8; Tue, 28 Jan 2025 17:06:25 +0000
Received: by outflank-mailman (input) for mailman id 878713;
 Tue, 28 Jan 2025 17:06:24 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=jygh=UU=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tcp2e-0006va-QQ
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 17:06:24 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 32ea7681-dd9a-11ef-a0e6-8be0dac302b0;
 Tue, 28 Jan 2025 18:06:22 +0100 (CET)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-aa689a37dd4so1165245566b.3
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 09:06: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
 4fb4d7f45d1cf-5dc186d8b2csm7405936a12.76.2025.01.28.09.06.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 28 Jan 2025 09:06:19 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 32ea7681-dd9a-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738083982; x=1738688782; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=e5X663P4en3YR5ZbXxt+29IcazmwoosY2ySdVtlKhQU=;
        b=J9CbkG1p9sfQzl33eDAybybTp06BoKo2+ZWPTvrS5NlReudLuMOaSw5WSYOJI7uPe0
         vjpKD71JpMmDZQc/Qgx8qVV0raQ4oOtn6XZl4J7tGmZpKouj+YelHOXjMqr5or0ZgS7J
         oA4kHQozAISvDoN0TITGe4PHx+Asa8NIzEZCdfEQ9IFrSXXs9LrMPZeHqK4lR7ey/4nw
         ieVgknUduxBa0XFUCplFI6OgsBkJ2cerLVlZzW+LkjJxHgpDJQPCg+z4V1IpgaqRBZMU
         JrZimCstcPPxd/LQLlty9Caj3VIFZBysp/pdR0seAVls31FeNuq+C7nXeIjtHCCtUtOY
         Jn8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738083982; x=1738688782;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=e5X663P4en3YR5ZbXxt+29IcazmwoosY2ySdVtlKhQU=;
        b=etz3emeJ8ojRWg4J58+WMEXeRRaJAaqLxHtfb7Ka0ZNDSmvPOiIvggD/ASWPjfvbm4
         avLt3VZcaES9qz19l5SJmhGKlJdqnoOTzIHaJVUPWfO/rv08/TQIpy2IshpLdd+zyX/u
         rAz+DVpO9QiNY5quBTERKisltgx518JzAg51/FszHxS5pAbgoqd8KYdiWksmc0kTVkZI
         mcHRwSzbJ/YaXJxP4jcayImTxPP2+C4KlE5va8onlXPXXrmeDXajdpr/csU5kMrzbCwz
         OPTDUc6I9U+geiQr0ht0CjmaatdMM7EBLMpLgf98KUMcFnMBOSnVfo4op/z/UIzwY+ml
         B9IQ==
X-Forwarded-Encrypted: i=1; AJvYcCU03chWnc1gMBSzGLy8hpF18kjyMIZzac9o5iLR4Azt3c2x7PskQH18o/XJcAuZSSlPJJAyvgMlObI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwcqUTsjZ2kH1tqW4ypBpinz0HFFJKmd9OLhaXzqwN9FENrvPC0
	1Pw7lRyHdgBsDzV+YjSs1HWFLui+knK2Ba45cqfeFacypbB5zM7mX1x9hUcnbg==
X-Gm-Gg: ASbGncukwUjklVxzacFeQNm/ab1xpS348BbFFUR2EaseLrZ6SceYYr9EDKcEu4rsbJB
	ydz3TozZ88CaVNfkjj9f3iYN6dNJYLbupeRU5HXS7uSdAkWDhmSITNnXfi/WoD1Fw6jVdEM0vIc
	KNQDWV+fevzh9GHUourndR9l8zMVdSJQr/+F1S5u7QeP+uwgRIAlMrmtwAIflFJ4VkFkR8RTe/r
	LeZfWMPxN7F1R5NhVnoOtj1cvblAMis1jcUyBxele+OjYTiSjwJSGOD1M41GSj28xFilzVI0k+v
	tqlBJ26PqRQ+buNFKPrXmTf8klkGLOb539jMDBDystUFtxcmdBg7o5dN4/RhRtPSKXOYW0cOfas
	uhd1dmGXUtDY=
X-Google-Smtp-Source: AGHT+IHfiCDvIODhw0y4B5tZznVO2YVbxwwgWs4Q8B+oXLHrj3lADlrGJQgimmmiVFkWRE2RdzUdRw==
X-Received: by 2002:a17:907:1c0a:b0:aa6:5eae:7ece with SMTP id a640c23a62f3a-ab38b42e649mr4046044466b.43.1738083980265;
        Tue, 28 Jan 2025 09:06:20 -0800 (PST)
Message-ID: <475cd06a-f659-4921-8910-4b6033a4c95b@suse.com>
Date: Tue, 28 Jan 2025 18:06:18 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 19/24] xen/8250-uart: add missing definitions
To: dmukhin@ford.com
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
 <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
 <20250103-vuart-ns8250-v3-v1-19-c5d36b31d66c@ford.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250103-vuart-ns8250-v3-v1-19-c5d36b31d66c@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04.01.2025 02:58, Denis Mukhin via B4 Relay wrote:
> @@ -51,12 +54,19 @@
>  #define UART_IIR_THR      0x02    /*  - tx reg. empty     */
>  #define UART_IIR_MSI      0x00    /*  - MODEM status      */
>  #define UART_IIR_BSY      0x07    /*  - busy detect (DW) */
> +#define UART_IIR_FE       0xC0    /* FIFO enabled (2 bits) */

Please can you use lower case hex digits?

> @@ -64,17 +74,17 @@
>  
>  /*
>   * Note: The FIFO trigger levels are chip specific:
> - *	RX:76 = 00  01  10  11	TX:54 = 00  01  10  11
> - * PC16550D:	 1   4   8  14		xx  xx  xx  xx
> - * TI16C550A:	 1   4   8  14          xx  xx  xx  xx
> - * TI16C550C:	 1   4   8  14          xx  xx  xx  xx
> - * ST16C550:	 1   4   8  14		xx  xx  xx  xx
> - * ST16C650:	 8  16  24  28		16   8  24  30	PORT_16650V2
> - * NS16C552:	 1   4   8  14		xx  xx  xx  xx
> - * ST16C654:	 8  16  56  60		 8  16  32  56	PORT_16654
> - * TI16C750:	 1  16  32  56		xx  xx  xx  xx	PORT_16750
> - * TI16C752:	 8  16  56  60		 8  16  32  56
> - * Tegra:	 1   4   8  14		16   8   4   1	PORT_TEGRA
> + *  RX:76 = 00  01  10  11  TX:54 = 00  01  10  11
> + * PC16550D:     1   4   8  14      xx  xx  xx  xx
> + * TI16C550A:    1   4   8  14      xx  xx  xx  xx
> + * TI16C550C:    1   4   8  14      xx  xx  xx  xx
> + * ST16C550:     1   4   8  14      xx  xx  xx  xx
> + * ST16C650:     8  16  24  28      16   8  24  30  PORT_16650V2
> + * NS16C552:     1   4   8  14      xx  xx  xx  xx
> + * ST16C654:     8  16  56  60       8  16  32  56  PORT_16654
> + * TI16C750:     1  16  32  56      xx  xx  xx  xx  PORT_16750
> + * TI16C752:     8  16  56  60       8  16  32  56
> + * Tegra:        1   4   8  14      16   8   4   1  PORT_TEGRA
>   */

What is this change about? All I can see is that the table heading no
longer aligns with table contents.

> @@ -96,11 +106,33 @@
>  #define UART_LCR_CONF_MODE_B	0xBF		/* Configuration mode B */
>  
>  /* Modem Control Register */
> -#define UART_MCR_DTR      0x01    /* Data Terminal Ready  */
> -#define UART_MCR_RTS      0x02    /* Request to Send      */
> -#define UART_MCR_OUT2     0x08    /* OUT2: interrupt mask */
> -#define UART_MCR_LOOP     0x10    /* Enable loopback test mode */
> -#define UART_MCR_TCRTLR   0x40    /* Access TCR/TLR (TI16C752, EFR[4]=1) */
> +#define UART_MCR_DTR            BIT(0, U)   /* Data Terminal Ready  */
> +#define UART_MCR_RTS            BIT(1, U)   /* Request to Send      */
> +#define UART_MCR_OUT1           BIT(2, U)   /* OUT1: interrupt mask */
> +#define UART_MCR_OUT2           BIT(3, U)   /* OUT2: interrupt mask */
> +#define UART_MCR_LOOP           BIT(4, U)   /* Enable loopback test mode */
> +#define UART_MCR_RESERVED0      BIT(5, U)   /* Reserved #0 */
> +#define UART_MCR_RESERVED1      BIT(6, U)   /* Reserved #1 */
> +#define UART_MCR_TCRTLR         BIT(6, U)   /* Access TCR/TLR (TI16C752, EFR[4]=1) */

I find it odd for a bit to be reserved and also not reserved.

> +#define UART_MCR_RESERVED2      BIT(7, U)   /* Reserved #2 */
> +#define UART_MCR_MASK \
> +    (UART_MCR_DTR | UART_MCR_RTS | \
> +     UART_MCR_OUT1 | UART_MCR_OUT2 | \
> +     UART_MCR_LOOP)

Yet then not including UART_MCR_TCRTLR?

> @@ -111,6 +143,7 @@
>  #define UART_LSR_THRE     0x20    /* Xmit hold reg empty  */
>  #define UART_LSR_TEMT     0x40    /* Xmitter empty        */
>  #define UART_LSR_ERR      0x80    /* Error                */
> +#define UART_LSR_MASK     (UART_LSR_OE | UART_LSR_BI)

On what basis were these two bits chose and the others left out?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jan 28 17:45:34 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 17:45:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878726.1288914 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcpeL-0004lJ-QY; Tue, 28 Jan 2025 17:45:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878726.1288914; Tue, 28 Jan 2025 17:45:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcpeL-0004lC-Nk; Tue, 28 Jan 2025 17:45:21 +0000
Received: by outflank-mailman (input) for mailman id 878726;
 Tue, 28 Jan 2025 17:45:19 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=00fH=UU=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tcpeJ-0004l2-RF
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 17:45:19 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a2e8957b-dd9f-11ef-a0e6-8be0dac302b0;
 Tue, 28 Jan 2025 18:45:17 +0100 (CET)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-aaec61d0f65so1289681766b.1
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 09:45:17 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab675e8acb6sm818432766b.76.2025.01.28.09.45.16
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 28 Jan 2025 09:45:16 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a2e8957b-dd9f-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1738086317; x=1738691117; 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=kuDjnyy8QNCE5nXbBr2E5MtFQXBnd4rgNbbc7bDNldI=;
        b=KIdGjLiTDdTzn47Fv4HxisQYuT7SjSunH9+UvjvSk7RTN3XHjse6ki9TVPE1ySEqcA
         sW2pSmjZsrrpU7tE3YpEAPHKp7AEQ1SEiAbUYqdtEkLYJTFjWykB3V0NP2uwLc6uVAp6
         ycNPHcFI6tIs2D2I1BXFEFp6nENxio7T6LSeU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738086317; x=1738691117;
        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=kuDjnyy8QNCE5nXbBr2E5MtFQXBnd4rgNbbc7bDNldI=;
        b=U8pPnf/y3xfgyPwgdxpoAOldp51czT6lLX+zk00sG//wdChc4JyOxRyzJ9qkIKGQ8N
         JxX2rr+J8DBjXjv0R/7SNHGJcudsrjtOh8zle2ECh3djpOkF9rQUtdwWq6bhs59Bz9A7
         0oa6KH5ZO2H2w0c/SEyOe9ezfle41Xe6iPmUVUGohVviKNoZXkUXQS66as/ajZ2YkNon
         YNjN7X9S0Km/Emtull8uY/zgt5IFz5R0DGRbgdYa5KE1n3C4K9JgX6f+wIsnnw/IcbDT
         GR90Z5YjwtVF6SYibY4qNlqZVQDgA2ImJ6EKkSmm+BVeibqtf9OldIK5x2Rdk89EbZ74
         Yzpg==
X-Gm-Message-State: AOJu0Yx5UqS6ig9kZHlQ3shUFyXazGUUA8l5404zeNCRADWJf0imLLxK
	KSZcE3p8tYLZJGt4GNoDkA4pNMRzvZe72jwoUdgVw1z8laK7VCxi/lPok9fdS74=
X-Gm-Gg: ASbGncvlv6OJV9pTxVYrtwdIk9n3BzOuYpOCT3CVN9tOpTugLoxqqxRFzbhx7Pezh9C
	yyyDNvEToPtQ6e6VGsge5/aWVw1EQD1TK8zBXYUUdUFBRMzTBWGc3EcaSHPnp4gPjVskisoZDDv
	dTsGY7w7Uw5VKMaQieiKWvrbFOjLBVIltZX1KXSvDcmyQ2dphLTEmDnU4eLkQm7E+JlomngPMsf
	RJuPW2toyeErPiaJZCiCtn/OSiJ//LCXmtfvR/pEqs2qgbpne/BFFauMgLK46aBhvun9xWIyyyL
	nMV/HfAbttjab6rX6vSf
X-Google-Smtp-Source: AGHT+IGWnlP7bmYFK5wcedpA6oHCWe0jnq4OZAWhqcU5F2KRq/rub7Q9HZhgpCahoKaLrnBzR5Am4g==
X-Received: by 2002:a17:907:7fa8:b0:aa6:2704:4840 with SMTP id a640c23a62f3a-ab6cfe401d5mr492066b.51.1738086317045;
        Tue, 28 Jan 2025 09:45:17 -0800 (PST)
Date: Tue, 28 Jan 2025 18:45:15 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Alejandro Vallejo <alejandro.vallejo@cloud.com>
Cc: xen-devel@lists.xenproject.org, Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>
Subject: Re: [PATCH 0/3] tools/hvmloader: Decouple APIC IDs from vCPU IDs
Message-ID: <Z5kXq2RehzyFEYqA@macbook.local>
References: <20250128163342.1491-1-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20250128163342.1491-1-alejandro.vallejo@cloud.com>

On Tue, Jan 28, 2025 at 04:33:39PM +0000, Alejandro Vallejo wrote:
> The hypervisor, hvmloader and the toolstack currently engage in a shared
> assumption that for every vCPU apicid == 2 * vcpuid. This series removes such
> assumption from hvmloader, by making it read the APIC ID of each vCPU and
> storing it for later use.
> 
> The last patch prevents writing an MP Tables should we have vCPUs that can not
> be represented there. That's at the moment dead code because all vCPUs are
> currently representable in 8 bits. This will inavitably stop being true in the
> future after we increase the maximum number of guest vCPUs.

While I'm fine with the MP Table change, should it also come together
with a patch that introduces the code to create x2APIC entries in
libacpi construct_madt() helper? (and bumping the MADT revision, as
I'm quite sure version 2 didn't have x2APIC entries in the
specification).

Otherwise the MP Table change seems like a red herring, because the
MADT created by libacpi will also be incorrect and APIC IDs will wrap in
local APIC entries, just like it would on MP Tables.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Jan 28 17:59:51 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 17:59:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878734.1288925 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcpsJ-0006kD-09; Tue, 28 Jan 2025 17:59:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878734.1288925; Tue, 28 Jan 2025 17:59:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcpsI-0006k5-Tf; Tue, 28 Jan 2025 17:59:46 +0000
Received: by outflank-mailman (input) for mailman id 878734;
 Tue, 28 Jan 2025 17:59:46 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=00fH=UU=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tcpsI-0006jw-JH
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 17:59:46 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a825a812-dda1-11ef-a0e6-8be0dac302b0;
 Tue, 28 Jan 2025 18:59:45 +0100 (CET)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-aaf57c2e0beso1191709266b.3
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 09:59:45 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab675e124fasm820827466b.22.2025.01.28.09.59.44
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 28 Jan 2025 09:59:44 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a825a812-dda1-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1738087185; x=1738691985; 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=+bT13YwSCmbqd57Ai80c9Ct3aDWgaPvXeyrjPEKM4U8=;
        b=dlcvq0tmSk2NChQyRIrn72YZQjtR50jLqp1uD6kC14ZjNgrGBa5MZgVFuqRAhwDf4V
         xdlmaogduOpR4nXcaDbnXM/DmE1r3Io13Ps+pYwWW6uizFxD5YSSR+jeALPSeGGLr2KI
         FClk5BW9e2TGt4fvm3FMcC1EJ1jEtiwZ5o6YU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738087185; x=1738691985;
        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=+bT13YwSCmbqd57Ai80c9Ct3aDWgaPvXeyrjPEKM4U8=;
        b=iAFQlJE4Vyb4djUJUC78lxuWekF3UP4ZOTOXNDPbYklIsoodubs0BQ2R3/1loqauOS
         B9oOul3FuyeNosYDAetgaNzH9DvjCnL7HZFgIEFCFGscPxZpuxWSscCBXzrQsOlrsjQF
         pfUb7bXDHe4ijFSSjmvemn2xgGd4MP9dEnzJ3fjPytNXEcDtn3dhDLb4HVAFF8u1jPRP
         wM46rF39UbQy1Iwz7gVdV0OeK/EtXMFiOUQ2CozfdZeAzCcnZ/cgo++hkcISNWfjGCRx
         4FdYFQrJGcMrENyy/7y2bUL0JawQH5cq0GevvhwOcJwr25LXsmT7FDIwcJG4hXJjnFhq
         i5HA==
X-Gm-Message-State: AOJu0Yzs1sGafZzcnWno918duFOWBrNgb9JmicctUGUiQo/mN3DOfz0O
	S8FWjw8Tw1rxHZXjA7iUz3gn/VhGtU5WqDNZV/vvKUcuM87aANLOnvXPSGrzG9k=
X-Gm-Gg: ASbGncviwZSQiEZ8E+hZ0KoDumM67LtW0mhdYdo5kX+zz5VRlxAzIDZp+nwqElI+36H
	Usu7+AF45jv5lDafpWKBy9lnAkpo39nsPW8FsHC8HbyWL4sb4mKSVphrhR7VE0D24kjmtHQutl2
	1WxnDszBxAimQ9r7alMhsGjyXxiXK8yVxDZJQkwqsdQV2hf2z4Jcspe1dlc9w1xFexwtEH61dc2
	sKPab5FGcRDrZGhCoWX+iQuQBWK7WX9maiBfOPddzM1xAtXCe2OssJaFufCr1baOPnx8YdyOJEw
	TA3qV1ZZNjGjXLt3SBrv
X-Google-Smtp-Source: AGHT+IEQUCFPNNnXoO2yaDC0IClurJDA6SchU18icLWmn9JLnYSTfKaJb4eIO+uMO6gq46LcImil0w==
X-Received: by 2002:a17:907:961a:b0:aac:619:7ed8 with SMTP id a640c23a62f3a-ab6cfc86accmr8975366b.7.1738087184793;
        Tue, 28 Jan 2025 09:59:44 -0800 (PST)
Date: Tue, 28 Jan 2025 18:59:43 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Alejandro Vallejo <alejandro.vallejo@cloud.com>
Cc: xen-devel@lists.xenproject.org, Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>
Subject: Re: [PATCH 1/3] tools/hvmloader: Retrieve (x2)APIC IDs from the APs
 themselves
Message-ID: <Z5kbD08TFyH0hwwF@macbook.local>
References: <20250128163342.1491-1-alejandro.vallejo@cloud.com>
 <20250128163342.1491-2-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20250128163342.1491-2-alejandro.vallejo@cloud.com>

On Tue, Jan 28, 2025 at 04:33:40PM +0000, Alejandro Vallejo wrote:
> Make it so the APs expose their own APIC IDs in a lookup table (LUT). We
> can use that LUT to populate the MADT, decoupling the algorithm that
> relates CPU IDs and APIC IDs from hvmloader.
> 
> Modified the printf to also print the APIC ID of each CPU, as well as
> fixing a (benign) wrong specifier being used for the vcpu id.
> 
> Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
> ---
> Changes from the v7 version of this patch in the longer topology series:
>   * s/cpu_to_x2apicid/cpu_to_apicid/
>     * Though, as I already stated, I don't think this is a good idea.
>   * Dynamically size cpu_to_apicid rather than using HVM_MAX_VCPUS.
>   * Got rid of the ap_callin removal. It's not as trivial if we don't
>     want to assume cpu0 always has apicid=0. Part of the complaints on
>     the previous versions involved the inability to do that.
>   * For debugging sanity, I've added the apicid to the CPU boot printf.
>       * Later on, toolstack will choose the APIC IDs and it's helpful
>         to know the relationship in the logs.
>       * While at it, fix the vcpu specifier s/%d/%u/
>   * Check for leaf 0xb while probing for x2apic support.
> ---
>  tools/firmware/hvmloader/smp.c | 43 +++++++++++++++++++++++++++++++++-
>  1 file changed, 42 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/firmware/hvmloader/smp.c b/tools/firmware/hvmloader/smp.c
> index 1b940cefd071..c61ed524f947 100644
> --- a/tools/firmware/hvmloader/smp.c
> +++ b/tools/firmware/hvmloader/smp.c
> @@ -31,9 +31,38 @@
>  
>  static int ap_callin;
>  
> +/** True if x2apic support is exposed to the guest. */
> +static bool has_x2apic;
> +
> +/**
> + * Lookup table of (x2)APIC IDs.

Not sure you need to explicitly mention (x2) in the comment?  It will
either be xAPIC or x2APIC IDs, but just using "APIC IDs" should cover
both unambiguously?

> + *
> + * Each entry is populated for its respective CPU as they come online. This is
> + * required for generating the MADT with minimal assumptions about ID
> + * relationships.
> + */
> +uint32_t *cpu_to_apicid;
> +
> +static uint32_t read_apic_id(void)
> +{
> +    uint32_t apic_id;
> +
> +    if ( has_x2apic )
> +        cpuid(0xb, NULL, NULL, NULL, &apic_id);
> +    else
> +    {
> +        cpuid(1, NULL, &apic_id, NULL, NULL);
> +        apic_id >>= 24;
> +    }
> +
> +    return apic_id;
> +}
> +
>  static void cpu_setup(unsigned int cpu)
>  {
> -    printf(" - CPU%d ... ", cpu);
> +    uint32_t apicid = cpu_to_apicid[cpu] = read_apic_id();
> +
> +    printf(" - CPU%u[%u] ... ", cpu, apicid);

I would explicitly name the field in the print:

" - CPU%u APIC ID %u ... "

As otherwise it's not obvious what the value in the braces is (and you
have to go look at the code).

>      cacheattr_init();
>      printf("done.\n");
>  
> @@ -104,8 +133,20 @@ static void boot_cpu(unsigned int cpu)
>  void smp_initialise(void)
>  {
>      unsigned int i, nr_cpus = hvm_info->nr_vcpus;
> +    uint32_t ecx, max_leaf;

Noticed you could narrow the scope of ecx, but at the price of
introducing the definition line inside of the if condition.  I don't
have a strong opinion, and I assume you prefer it this way, which is
fine IMO.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Jan 28 18:42:48 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 18:42:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878745.1288934 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcqXr-0004kv-0e; Tue, 28 Jan 2025 18:42:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878745.1288934; Tue, 28 Jan 2025 18:42:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcqXq-0004ko-U6; Tue, 28 Jan 2025 18:42:42 +0000
Received: by outflank-mailman (input) for mailman id 878745;
 Tue, 28 Jan 2025 18:42:41 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=C4cq=UU=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tcqXp-0004ki-P5
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 18:42:41 +0000
Received: from mail-ed1-x543.google.com (mail-ed1-x543.google.com
 [2a00:1450:4864:20::543])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a70c8864-dda7-11ef-a0e6-8be0dac302b0;
 Tue, 28 Jan 2025 19:42:40 +0100 (CET)
Received: by mail-ed1-x543.google.com with SMTP id
 4fb4d7f45d1cf-5d7e3f1fdafso11424191a12.0
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 10:42:40 -0800 (PST)
Received: from localhost ([217.156.233.154]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab6761172e2sm841486766b.177.2025.01.28.10.42.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 28 Jan 2025 10:42:39 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a70c8864-dda7-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1738089760; x=1738694560; darn=lists.xenproject.org;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=HOrUMY9nkj1EjHcRw20m35r29xoiXkEnufHRAN35Zas=;
        b=K2syxno6YaCiXZO+fuwf+p0ed3rt5MU/xVCdqAaPX9nJZYhWxgOIcwtUbw5Ma4F+Ja
         YxihZxql5fBiOfhdU1/zmxDDUsHR4pond1WqxTp5/Z091asqqph2Kt6WswoXSkd2DZhG
         P+dSIpkoQkFKs+cJ0TBQ44kXRgXf+pI4NtFn4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738089760; x=1738694560;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=HOrUMY9nkj1EjHcRw20m35r29xoiXkEnufHRAN35Zas=;
        b=YTASYFu4WuxxkyWQhE9sAVSWsMmtpwuPPUpcSRlMRmCbT6j8g47sRXcOViULTbO6H/
         0kWPyv3QX1Gp/py+Mgs6uK9lnInLbh9meuZPAqu9sxahXeNL1ds1odGIFBo4E39wX3lM
         PJxcMqhisVquLE3LlnuuIeW2gezXrmZcSiMiIpiyGy3cKgAshbEXuAIHdooCEEBVxkwl
         2KrZsU/SwXww14er/lL6eIVfX9XYaruk0nwv6P5CCpueUnM5FLtlA+6B0peEzx/FDSf1
         VMtRp+C4xsMQ4Yc2JbwGr54Q1TBsnqFnY4aDTB2pooXDlwKaE3XQ1VMxtRHSOszIPqY4
         S57g==
X-Gm-Message-State: AOJu0YyL4VHqF0mGePblmpzDnxzpaVGiwTLGjdjnCyFUyj9wcBvZrNzd
	1GDMgeCgKrUslhgeJ+WF+n2hLb4ZL0fKPb+924HgR0am4DCkwnIrvBeXoxLX6wI=
X-Gm-Gg: ASbGncuOcFLKgzPijQ0Etm+j2t+XCFfLaBRVPdG6AFAfuaVs8jdOzf278/yxroltl6x
	SpyCwiDthuGdFj1SqvA9Y69PpENyx1VWDdwEujbqfvwfu5gv7ZkCCwQwoLb0RRSq4TM0oGim+5s
	WjLM7D5MeyehpjXyiKAcj5Rq9SHsU0Pdmt+zC4b5vWtPM02tg8KQncSyksnGHyKk8bvKPQ8lVlo
	L30TO8RQrfAH3G34AFMVe5q22lcavj7lDeptRZpcAfSzYh4C6f3Ovo16Z9QLVpqS1ZGcH2vNK2U
	EVcoY1bVaeCDSjqLXjC4gS95
X-Google-Smtp-Source: AGHT+IGGxavokiZXpj/SGrMZv+nxTfcl0Bk3JzHFo4VdAKx+EwJemsYIVDht+oofWCIMhrbKCn9h+A==
X-Received: by 2002:a17:906:730d:b0:aa6:7737:1991 with SMTP id a640c23a62f3a-ab6cfcc72ccmr19631066b.2.1738089759834;
        Tue, 28 Jan 2025 10:42:39 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Tue, 28 Jan 2025 18:42:38 +0000
Message-Id: <D7DXEC0N45CT.2JHUHP1XAVB5F@cloud.com>
Cc: <xen-devel@lists.xenproject.org>, "Jan Beulich" <jbeulich@suse.com>,
 "Andrew Cooper" <andrew.cooper3@citrix.com>, "Anthony PERARD"
 <anthony.perard@vates.tech>
Subject: Re: [PATCH 0/3] tools/hvmloader: Decouple APIC IDs from vCPU IDs
From: "Alejandro Vallejo" <alejandro.vallejo@cloud.com>
To: =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
X-Mailer: aerc 0.18.2
References: <20250128163342.1491-1-alejandro.vallejo@cloud.com>
 <Z5kXq2RehzyFEYqA@macbook.local>
In-Reply-To: <Z5kXq2RehzyFEYqA@macbook.local>

On Tue Jan 28, 2025 at 5:45 PM GMT, Roger Pau Monn=C3=A9 wrote:
> On Tue, Jan 28, 2025 at 04:33:39PM +0000, Alejandro Vallejo wrote:
> > The hypervisor, hvmloader and the toolstack currently engage in a share=
d
> > assumption that for every vCPU apicid =3D=3D 2 * vcpuid. This series re=
moves such
> > assumption from hvmloader, by making it read the APIC ID of each vCPU a=
nd
> > storing it for later use.
> >=20
> > The last patch prevents writing an MP Tables should we have vCPUs that =
can not
> > be represented there. That's at the moment dead code because all vCPUs =
are
> > currently representable in 8 bits. This will inavitably stop being true=
 in the
> > future after we increase the maximum number of guest vCPUs.
>
> While I'm fine with the MP Table change, should it also come together
> with a patch that introduces the code to create x2APIC entries in
> libacpi construct_madt() helper? (and bumping the MADT revision, as
> I'm quite sure version 2 didn't have x2APIC entries in the
> specification).

That's a lot more involved though. Matt started something in that direction
last year, but testing it was (and still is) effectively impossible until
HVM_MAX_VCPUS increases.

  https://lore.kernel.org/xen-devel/cd1a3ce14790af8c1bb4372ef0be5a6cbbb50b1=
c.1710338145.git.matthew.barnes@cloud.com/

The rest of the topo series can be used to test that (with a hack to
artificially bump the width of thread_id space), I'd rather not test a patc=
h
with a long and still uncommitted series.

>
> Otherwise the MP Table change seems like a red herring, because the
> MADT created by libacpi will also be incorrect and APIC IDs will wrap in
> local APIC entries, just like it would on MP Tables.
>
> Thanks, Roger.

My take is that this is strictly better than what we have today by virtue o=
f
going down from 2 latent bugs to just 1. That said, I don't strictly need i=
t
for the topo series to advance, so it is (in a sense) optional.

A second approach is to gate things differently by preventing legacy BIOS
domains from having APs with APIC IDs >=3D 255 at all. OVMF already has MP =
and
$PIR tables disabled, from what I can see in hvmloader.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Tue Jan 28 18:46:05 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 18:46:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878754.1288944 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcqaz-0005KH-DR; Tue, 28 Jan 2025 18:45:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878754.1288944; Tue, 28 Jan 2025 18:45:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcqaz-0005KA-Ag; Tue, 28 Jan 2025 18:45:57 +0000
Received: by outflank-mailman (input) for mailman id 878754;
 Tue, 28 Jan 2025 18:45: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
 <SRS0=C4cq=UU=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tcqay-0005K4-Hc
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 18:45:56 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1aede02a-dda8-11ef-a0e6-8be0dac302b0;
 Tue, 28 Jan 2025 19:45:54 +0100 (CET)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-ab2aea81cd8so1099021866b.2
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 10:45:54 -0800 (PST)
Received: from localhost ([217.156.233.154]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab6914e56a2sm608223866b.94.2025.01.28.10.45.53
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 28 Jan 2025 10:45:53 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1aede02a-dda8-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1738089954; x=1738694754; darn=lists.xenproject.org;
        h=in-reply-to:references:cc:to:from:subject:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=bD4eyHKxLm4mD8wo182CvRVC4pDKYF0hvlY36UdSX2E=;
        b=FYZFAZDof+usyAnelOoBCID6mhBLVE1MeZDgRRzw8WulSDF/NrXWFOQTTK/rgaBu/Z
         756iG4+CD2hwDlBrPnSqniRw0nuPNf0VwsdHoT+uk5MaL8G+brInkUf7KWt59cNagthl
         S4RpcmBUSX8uTNM030Cyg33dqSKrIBxHetfMA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738089954; x=1738694754;
        h=in-reply-to:references:cc:to:from:subject:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=bD4eyHKxLm4mD8wo182CvRVC4pDKYF0hvlY36UdSX2E=;
        b=bYlfABK2YNcCiWJaYoNHQ+TA2vOpSrJwfVk5rs1/qp++q//MS0yGT2/tR/Xy6rh2x+
         MM1lOYOQdW2V6knAYIwaAWS+Za2YG0DDgNc8KVcROdz/CVfKyr83GoJdkwT5oQcKozcg
         Xu1mfuS4tOeFpGjqDGZgf5FzAiXhtWD56TPzYkDPs+Kq0qnodMA9ttI40/c6w0ErwqM6
         +bS0F7oU3aOTWBemdzzO4KaHnDnvVkKszTApaioABLsa6pThyieH5ZBTeUhDc9PhIBNS
         IDFqsVbC/SXLW/W8pcevwmJ+mP6uklh8+igD7ynXaAPjz8GNCJr3U8uhPZ65p8T3o6UU
         DZPQ==
X-Gm-Message-State: AOJu0YwohympYqX+DO0faqJuLVZmhd+O0aTQ5ocKuxvSPXcJOsqt5ErG
	CNsf1X9KpKI9y1/ZF2V5lRWSmfFAtec9iHnVwe8jM3hc0W7Q1vAmHZVgNDqbkQY=
X-Gm-Gg: ASbGncshEskDN6NoxlHtt/oZNKKoYvA9OYKEctHM+wNK+bex1pVcmc7h5iFf3YLqgHL
	8KLsFfP5V0UwQX9me2Tu0JYn38Uh+edsFWje8T1pqfDdzLQAcGbkoZbDsQs7FUrQNDRqoJg2C/6
	m2ul+opPPqKpdCuzCLiwBNGVwTQ/TbmEZ73Kn2/XmJL8amHad+2TmTa1rw8UkPYdVS3dEyW8D+C
	9ibgF/d6+axp1UWw/NbhecSPveJnqpP9CIEPXsFtXbEXtJSyAzBetWtC3CD5Ab0RjFzb3Aq+gGu
	zb1truzhZRfyYXWLVcK8jJRq
X-Google-Smtp-Source: AGHT+IGU5hQdzHGpzfaGJZ5weXmUKRNOT80dDpS4HUDTU1IFi4Isd9gHx9MNcveqxm+ZH6A6973MrQ==
X-Received: by 2002:a17:907:2cc5:b0:aaf:74d6:6467 with SMTP id a640c23a62f3a-ab6cfe11f0cmr19701066b.42.1738089954372;
        Tue, 28 Jan 2025 10:45:54 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Tue, 28 Jan 2025 18:45:53 +0000
Message-Id: <D7DXGTJ8OZYN.1W70NDFFJW4B@cloud.com>
Subject: Re: [PATCH 1/3] tools/hvmloader: Retrieve (x2)APIC IDs from the APs
 themselves
From: "Alejandro Vallejo" <alejandro.vallejo@cloud.com>
To: =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Cc: <xen-devel@lists.xenproject.org>, "Jan Beulich" <jbeulich@suse.com>,
 "Andrew Cooper" <andrew.cooper3@citrix.com>, "Anthony PERARD"
 <anthony.perard@vates.tech>
X-Mailer: aerc 0.18.2
References: <20250128163342.1491-1-alejandro.vallejo@cloud.com>
 <20250128163342.1491-2-alejandro.vallejo@cloud.com>
 <Z5kbD08TFyH0hwwF@macbook.local>
In-Reply-To: <Z5kbD08TFyH0hwwF@macbook.local>

On Tue Jan 28, 2025 at 5:59 PM GMT, Roger Pau Monn=C3=A9 wrote:
> On Tue, Jan 28, 2025 at 04:33:40PM +0000, Alejandro Vallejo wrote:
> > Make it so the APs expose their own APIC IDs in a lookup table (LUT). W=
e
> > can use that LUT to populate the MADT, decoupling the algorithm that
> > relates CPU IDs and APIC IDs from hvmloader.
> >=20
> > Modified the printf to also print the APIC ID of each CPU, as well as
> > fixing a (benign) wrong specifier being used for the vcpu id.
> >=20
> > Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
> > ---
> > Changes from the v7 version of this patch in the longer topology series=
:
> >   * s/cpu_to_x2apicid/cpu_to_apicid/
> >     * Though, as I already stated, I don't think this is a good idea.
> >   * Dynamically size cpu_to_apicid rather than using HVM_MAX_VCPUS.
> >   * Got rid of the ap_callin removal. It's not as trivial if we don't
> >     want to assume cpu0 always has apicid=3D0. Part of the complaints o=
n
> >     the previous versions involved the inability to do that.
> >   * For debugging sanity, I've added the apicid to the CPU boot printf.
> >       * Later on, toolstack will choose the APIC IDs and it's helpful
> >         to know the relationship in the logs.
> >       * While at it, fix the vcpu specifier s/%d/%u/
> >   * Check for leaf 0xb while probing for x2apic support.
> > ---
> >  tools/firmware/hvmloader/smp.c | 43 +++++++++++++++++++++++++++++++++-
> >  1 file changed, 42 insertions(+), 1 deletion(-)
> >=20
> > diff --git a/tools/firmware/hvmloader/smp.c b/tools/firmware/hvmloader/=
smp.c
> > index 1b940cefd071..c61ed524f947 100644
> > --- a/tools/firmware/hvmloader/smp.c
> > +++ b/tools/firmware/hvmloader/smp.c
> > @@ -31,9 +31,38 @@
> > =20
> >  static int ap_callin;
> > =20
> > +/** True if x2apic support is exposed to the guest. */
> > +static bool has_x2apic;
> > +
> > +/**
> > + * Lookup table of (x2)APIC IDs.
>
> Not sure you need to explicitly mention (x2) in the comment?  It will
> either be xAPIC or x2APIC IDs, but just using "APIC IDs" should cover
> both unambiguously?

Sure.

>
> > + *
> > + * Each entry is populated for its respective CPU as they come online.=
 This is
> > + * required for generating the MADT with minimal assumptions about ID
> > + * relationships.
> > + */
> > +uint32_t *cpu_to_apicid;
> > +
> > +static uint32_t read_apic_id(void)
> > +{
> > +    uint32_t apic_id;
> > +
> > +    if ( has_x2apic )
> > +        cpuid(0xb, NULL, NULL, NULL, &apic_id);
> > +    else
> > +    {
> > +        cpuid(1, NULL, &apic_id, NULL, NULL);
> > +        apic_id >>=3D 24;
> > +    }
> > +
> > +    return apic_id;
> > +}
> > +
> >  static void cpu_setup(unsigned int cpu)
> >  {
> > -    printf(" - CPU%d ... ", cpu);
> > +    uint32_t apicid =3D cpu_to_apicid[cpu] =3D read_apic_id();
> > +
> > +    printf(" - CPU%u[%u] ... ", cpu, apicid);
>
> I would explicitly name the field in the print:
>
> " - CPU%u APIC ID %u ... "
>
> As otherwise it's not obvious what the value in the braces is (and you
> have to go look at the code).

Sure.

>
> >      cacheattr_init();
> >      printf("done.\n");
> > =20
> > @@ -104,8 +133,20 @@ static void boot_cpu(unsigned int cpu)
> >  void smp_initialise(void)
> >  {
> >      unsigned int i, nr_cpus =3D hvm_info->nr_vcpus;
> > +    uint32_t ecx, max_leaf;
>
> Noticed you could narrow the scope of ecx, but at the price of
> introducing the definition line inside of the if condition.  I don't
> have a strong opinion, and I assume you prefer it this way, which is
> fine IMO.
>
> Thanks, Roger.

I marginally prefer it this way, but I don't particularly care. I wanted to
avoid one more line in a hunk that's already quite high for a single CPUID
check.=20

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Tue Jan 28 18:48:47 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 18:48:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878762.1288954 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcqde-0005t3-Pp; Tue, 28 Jan 2025 18:48:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878762.1288954; Tue, 28 Jan 2025 18:48:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcqde-0005sw-NF; Tue, 28 Jan 2025 18:48:42 +0000
Received: by outflank-mailman (input) for mailman id 878762;
 Tue, 28 Jan 2025 18:48:41 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=C4cq=UU=cloud.com=alejandro.vallejo@srs-se1.protection.inumbo.net>)
 id 1tcqdd-0005sq-KS
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 18:48:41 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7dc7ea79-dda8-11ef-a0e6-8be0dac302b0;
 Tue, 28 Jan 2025 19:48:40 +0100 (CET)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-ab68d900c01so647175766b.0
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 10:48:40 -0800 (PST)
Received: from localhost ([217.156.233.154]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5dc1861939asm7582917a12.12.2025.01.28.10.48.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 28 Jan 2025 10:48:39 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 7dc7ea79-dda8-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1738090120; x=1738694920; darn=lists.xenproject.org;
        h=in-reply-to:references:subject:cc:to:from:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ZN5Yun5WykiYr20jfdAR3DBUumqD/eSRuq1mIK3T6o8=;
        b=YxviCEXnOsNvjZVJHemvVudw/RVZKt0LqlGMXHv1yQba7ruqFB9tNZcQbeGxYuXh0x
         VB2BbMYHEPrmOfpOFgULRhUuSrDYJBthdrFMLzfqjuTf1irlqVbVZSImStKjJGgovqFh
         ukwcuNzOB+qZUKgEykEKpInzRfQAkwzCTncJU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738090120; x=1738694920;
        h=in-reply-to:references:subject:cc:to:from:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=ZN5Yun5WykiYr20jfdAR3DBUumqD/eSRuq1mIK3T6o8=;
        b=iyOcTpgdlIJ6y8ZWx+OLGQ6+Yhwq/KKRQ/raCoJ3dn323x+/KVdepX303cw6I6hVnA
         zjP9n/nUE+sGepEAfWO53DT33nRnvgKYCNOVZUQ8xqW0TTTwMxfjXsjuil11jtph/FGI
         RDmd/xOLg/qM3DrI0ZCN4pnzmtClCHQG4wGH5fDG5P802pNQKqIe3jPBpkGNvxERtdaQ
         NWZs7ga48am5T7nd0P7tEjBPwKGTVRNFcQs7M3+o7pl6HfSna0Uas//hAD3gIjkknol3
         DcE9ikciy2AFrMJjoKGiB5dAKY1wxU58eYHOP4y2sosnybqEDVwNUlaPwGaBMpgVBEGn
         V8EA==
X-Forwarded-Encrypted: i=1; AJvYcCVC6wERAaw2efpcCPM7+EtHpAkm7P3sAtWV9l5bKKWIRRjfn96Q90jPd7L9hclgjkXgGVi6if0i9q0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxpgaYIVH3yizPlGC7OHOa/nFOP+HMaNSGBi0RIuiUbJSw0Zpun
	pSnfVzDp+UoEutHXbNh792OP80fNYNXnw7EfG1bLqDsP9hLX9VVA3PJkeYYrw40=
X-Gm-Gg: ASbGncu4eWsZgJUgKdZNTkoSlif5/dAaO+0kEEheKc8Jp6GollJHBC0CFXpsCkwJfAe
	BXP6s9f524rP8PWs8T57DlS6+RALjhDiqA6FOiURREIGJ1sd3vYYNx5O/OMRNJBJXyt+M8hMr/m
	5bsKf2GgwTwzGfzltm4qI3u66bdvX67pq9R69kmNTmKnfHV0m8FC6SkdslD0sTIWJ1+A4RK/59n
	Ek0RwkJ+db/D+H2iMxLjkTkTVw+6+AvS27HlMqGPSGLpxHTqnXshc0GnB+x1n3jGSM++EoX0S0o
	FmUh/rFMZ7lIA7X6g78CrbIJCvLxfe3c2mU=
X-Google-Smtp-Source: AGHT+IEbDcBGxWNgg6DhCEa6hExrGkeKCy0PLVyCNMEp9l7A62uxlYPvJ/XTmOzdW2AV8OK1G2K5zg==
X-Received: by 2002:a17:906:7310:b0:ab2:c0b0:3109 with SMTP id a640c23a62f3a-ab6bbbcd478mr484408466b.21.1738090120236;
        Tue, 28 Jan 2025 10:48:40 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Tue, 28 Jan 2025 18:48:38 +0000
Message-Id: <D7DXIXNODNSU.B17NMD5C6WNW@cloud.com>
From: "Alejandro Vallejo" <alejandro.vallejo@cloud.com>
To: "Michal Orzel" <michal.orzel@amd.com>, <xen-devel@lists.xenproject.org>
Cc: "Stefano Stabellini" <sstabellini@kernel.org>, "Julien Grall"
 <julien@xen.org>, "Bertrand Marquis" <bertrand.marquis@arm.com>, "Volodymyr
 Babchuk" <Volodymyr_Babchuk@epam.com>, <oleksii.kurochko@gmail.com>
Subject: Re: [for-4.20][PATCH 2/2] xen/arm: Fix build issue when
 CONFIG_PHYS_ADDR_T_32=y
X-Mailer: aerc 0.18.2
References: <20250127104556.175641-1-michal.orzel@amd.com>
 <20250127104556.175641-3-michal.orzel@amd.com>
 <D7D0O214VJBT.18EFVF7AJACYQ@cloud.com>
 <4788ed30-f182-4fd9-aad5-5faca3580e3b@amd.com>
In-Reply-To: <4788ed30-f182-4fd9-aad5-5faca3580e3b@amd.com>

On Mon Jan 27, 2025 at 5:14 PM GMT, Michal Orzel wrote:
>
>
> On 27/01/2025 18:03, Alejandro Vallejo wrote:
> >=20
> >=20
> > Hi,
> >=20
> > On Mon Jan 27, 2025 at 10:45 AM GMT, Michal Orzel wrote:
> >> On Arm32, when CONFIG_PHYS_ADDR_T_32 is set, a build failure is observ=
ed:
> >> arch/arm/platforms/vexpress.c: In function 'vexpress_smp_init':
> >> arch/arm/platforms/vexpress.c:102:12: error: format '%lx' expects argu=
ment of type 'long unsigned int', but argument 2 has type 'long long unsign=
ed int' [-Werror=3Dformat=3D]
> >>   102 |     printk("Set SYS_FLAGS to %"PRIpaddr" (%p)\n",
> >>
> >> When CONFIG_PHYS_ADDR_T_32 is set, paddr_t is defined as unsigned long=
.
> >> Commit 96f35de69e59 dropped __virt_to_maddr() which used paddr_t as a
> >> return type. Without a cast, the expression type is unsigned long long
> >> which causes the issue. Fix it.
> >>
> >> Fixes: 96f35de69e59 ("x86+Arm: drop (rename) __virt_to_maddr() / __mad=
dr_to_virt()")
> >> Signed-off-by: Michal Orzel <michal.orzel@amd.com>
> >> ---
> >>  xen/arch/arm/include/asm/mm.h | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/xen/arch/arm/include/asm/mm.h b/xen/arch/arm/include/asm/=
mm.h
> >> index f91ff088f6b1..a0d8e5afe977 100644
> >> --- a/xen/arch/arm/include/asm/mm.h
> >> +++ b/xen/arch/arm/include/asm/mm.h
> >> @@ -263,7 +263,7 @@ static inline void __iomem *ioremap_wc(paddr_t sta=
rt, size_t len)
> >>
> >>  #define virt_to_maddr(va) ({                                        \
> >>      vaddr_t va_ =3D (vaddr_t)(va);                                   =
 \
> >> -    (va_to_par(va_) & PADDR_MASK & PAGE_MASK) | (va_ & ~PAGE_MASK); \
> >> +    (paddr_t)((va_to_par(va_) & PADDR_MASK & PAGE_MASK) | (va_ & ~PAG=
E_MASK)); \
> >>  })
> >>
> >>  #ifdef CONFIG_ARM_32
> >=20
> > Out of curiosity, why not make va_to_par() and __va_to_par() return pad=
dr_t
> > rather than uint64_t? Then this cast would be unnecessary and the expre=
ssion
> > end up as unsigned long.
> >=20
> > That would also cover any other uses outside this macro.
> >=20
> > Unless I'm missing something else...
> va_to_par() returns uint64_t because PAR_EL1 on Arm64 or PAR on Arm32 sys=
tem registers are both 64bit.
> So, it would not make sense (also it would be confusing) for va_to_par() =
to return already casted value.
> The function ends with _par so it should reflect the register size as the=
 name suggests. Macro is there
> to cast this value as it also takes into account PADDR_MASK and PAGE_MASK=
.
>
> ~Michal

I see. The point is to keep va_to_par() in sync with PAR's width then.

Fair enough then.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Tue Jan 28 19:04:05 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 19:04:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878778.1288965 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcqsS-0000cM-4j; Tue, 28 Jan 2025 19:04:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878778.1288965; Tue, 28 Jan 2025 19:04:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcqsS-0000cF-1D; Tue, 28 Jan 2025 19:04:00 +0000
Received: by outflank-mailman (input) for mailman id 878778;
 Tue, 28 Jan 2025 19:03: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
 <SRS0=O8nr=UU=gmail.com=julien.grall.oss@srs-se1.protection.inumbo.net>)
 id 1tcqsQ-0000c9-NS
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 19:03:58 +0000
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com
 [2a00:1450:4864:20::434])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a04477da-ddaa-11ef-a0e6-8be0dac302b0;
 Tue, 28 Jan 2025 20:03:57 +0100 (CET)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-385e3621518so3175340f8f.1
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 11:03:57 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a04477da-ddaa-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1738091037; x=1738695837; 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=E9des8+uKNTqFkgwRy/Jni2WaoGo4jFNwW33xKg+mEE=;
        b=IX/hIOqwuzsabmshsdrtxEzc5YZ1PeM4NNSEVS98ywApJRLFhQA6fELampIkd5XYO0
         jfj8PM0cAC9fax32/TrQeb3nG6mQadxi5B7AhqMogw1BZPM3BBBPPzKhprEebevrAB0E
         9atzehRNJwtojNM/fr+f5wJ5bmuSLt8watZy1L2nxwgnHLLeRF3oRcAp1G+YpRgdbD0Z
         24oYr72Npu3nO+G5Q8Wk6wRsR0bYYEBHtJb3LcX7c5+ogAE6FcVclxfTofI9Oy6mA6Ba
         IEe8UMoSVHRXzUguSa8uR92HwTgURDpd/D528zMfSq/OZKYAYVj5hPrJy36PSou/GU0D
         IlYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738091037; x=1738695837;
        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=E9des8+uKNTqFkgwRy/Jni2WaoGo4jFNwW33xKg+mEE=;
        b=S3H6ZC2hKgUDBsap2oUJAF11WHzdkcdPNfIPK3e+e4NO8rKk/RKN3FX5avAHunZLSJ
         iYfvX8rs7Efr7/qXNoht5PRyeMqMsrGL6WNgJlftO0BRmLelKVvbvfWXWs9F2VzrA5GV
         u3Z3VKBObjzxK3QXTpB0a7BvDNDwQ/27bcbXXP5+6yvOfQ4I8EkozAkOWqIzu8TznfM0
         46j8mthrfty9e/IPkmYb0XtZupHQYnhe9qQr2gr7OFfndS9HTI0VGtIbkam6F/CaAkc1
         Rqcwz2Q2ESNaDkL+jk8V1BVMiOl/EbYa5kYA6aiXexfVyMLKLdhOugDe+7Y5xx8s4rzL
         7HrQ==
X-Gm-Message-State: AOJu0YyuWG5mbMzmdT/PZvGbPPHc1cb4N9m3YyP8/gSp7bJD4GVaBdR6
	cX7wSW1lRSb2SmQKlKSfD3AVHAvul7n+bh6KeUBpY2dq6k62tzA9tpzbyEJEq75MKjSOsYpcMTJ
	WIWzyqjpe+bNxJCnbctQ/6vOBNdo=
X-Gm-Gg: ASbGncszfTAY7YfaEV/aN0oxoraWvd3B5Arf28JckH5M1soZw7oJKjyKlT7zWyH8J+W
	I2iiehcDFcweM8jrB/xYl3ND9QHNe0CR6l4/wX+VTgV/R1pUF+fFInkO04y4XQpkVaMzQTx0=
X-Google-Smtp-Source: AGHT+IES9C0uxBhBvZlHAAssZ3d3a3KnNV+hSY6mN2zNVjcftfXEN76umZ0Rd35GYh42V0hQqG+fVrpgPQuk42c6kkQ=
X-Received: by 2002:adf:f504:0:b0:38b:e109:1e0d with SMTP id
 ffacd0b85a97d-38c520b6629mr135714f8f.49.1738091036665; Tue, 28 Jan 2025
 11:03:56 -0800 (PST)
MIME-Version: 1.0
References: <20250128094002.145755-1-michal.orzel@amd.com> <20250128094002.145755-2-michal.orzel@amd.com>
In-Reply-To: <20250128094002.145755-2-michal.orzel@amd.com>
From: Julien Grall <julien.grall.oss@gmail.com>
Date: Tue, 28 Jan 2025 16:03:44 -0300
X-Gm-Features: AWEUYZmzu1Y8pm78xYAsiHyAQFMIxdPHdWeKJYrZed6AHoIunNplOtPsugDKDMc
Message-ID: <CAJ=z9a2m3UY=asS6zMtVu0sxSGZdK2vEk4if69DndGzsVcM8wg@mail.gmail.com>
Subject: Re: [for-4.20][PATCH v2 1/2] device-tree: bootfdt: Fix build issue
 when CONFIG_PHYS_ADDR_T_32=y
To: Michal Orzel <michal.orzel@amd.com>
Cc: xen-devel@lists.xenproject.org, 
	Stefano Stabellini <sstabellini@kernel.org>, Bertrand Marquis <bertrand.marquis@arm.com>, 
	oleksii.kurochko@gmail.com
Content-Type: multipart/alternative; boundary="000000000000d3eea1062cc8da35"

--000000000000d3eea1062cc8da35
Content-Type: text/plain; charset="UTF-8"

On Tue, 28 Jan 2025 at 06:40, Michal Orzel <michal.orzel@amd.com> wrote:

> On Arm32, when CONFIG_PHYS_ADDR_T_32 is set, a build failure is observed:
> common/device-tree/bootfdt.c: In function 'build_assertions':
> ./include/xen/macros.h:47:31: error: static assertion failed:
> "!(alignof(struct membanks) != 8)"
>    47 | #define BUILD_BUG_ON(cond) ({ _Static_assert(!(cond), "!(" #cond
> ")"); })
>       |                               ^~~~~~~~~~~~~~
> common/device-tree/bootfdt.c:31:5: note: in expansion of macro
> 'BUILD_BUG_ON'
>    31 |     BUILD_BUG_ON(alignof(struct membanks) != 8);
>
> When CONFIG_PHYS_ADDR_T_32 is set, paddr_t is defined as unsigned long,
> therefore the struct membanks alignment is 4B and not 8B. The check is
> there to ensure the struct membanks and struct membank, which is a
> member of the former, are equally aligned. Therefore modify the check to
> compare alignments obtained via alignof not to rely on hardcoded
> values.
>
> Fixes: 2209c1e35b47 ("xen/arm: Introduce a generic way to access memory
> bank structures")
> Signed-off-by: Michal Orzel <michal.orzel@amd.com>
> Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>


Reviewed-by: Julien Grall <julien@xen.org>

Cheers,



> ---
> Changes in v2:
>  - modify the check to test against alignment of struct membank
> ---
>  xen/common/device-tree/bootfdt.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/xen/common/device-tree/bootfdt.c
> b/xen/common/device-tree/bootfdt.c
> index 47386d4fffea..529c91e603ab 100644
> --- a/xen/common/device-tree/bootfdt.c
> +++ b/xen/common/device-tree/bootfdt.c
> @@ -27,8 +27,8 @@ static void __init __maybe_unused build_assertions(void)
>       */
>      BUILD_BUG_ON((offsetof(struct membanks, bank) !=
>                   offsetof(struct meminfo, bank)));
> -    /* Ensure "struct membanks" is 8-byte aligned */
> -    BUILD_BUG_ON(alignof(struct membanks) != 8);
> +    /* Ensure "struct membanks" and "struct membank" are equally aligned
> */
> +    BUILD_BUG_ON(alignof(struct membanks) != alignof(struct membank));
>  }
>
>  static bool __init device_tree_node_is_available(const void *fdt, int
> node)
> --
> 2.25.1
>
>

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

<div><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" =
class=3D"gmail_attr">On Tue, 28 Jan 2025 at 06:40, Michal Orzel &lt;<a href=
=3D"mailto:michal.orzel@amd.com">michal.orzel@amd.com</a>&gt; wrote:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">On Arm32, when CONFIG_PHYS_ADDR_T_32 is s=
et, a build failure is observed:<br>
common/device-tree/bootfdt.c: In function &#39;build_assertions&#39;:<br>
./include/xen/macros.h:47:31: error: static assertion failed: &quot;!(align=
of(struct membanks) !=3D 8)&quot;<br>
=C2=A0 =C2=A047 | #define BUILD_BUG_ON(cond) ({ _Static_assert(!(cond), &qu=
ot;!(&quot; #cond &quot;)&quot;); })<br>
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^~~~~~~~~~~~~~<b=
r>
common/device-tree/bootfdt.c:31:5: note: in expansion of macro &#39;BUILD_B=
UG_ON&#39;<br>
=C2=A0 =C2=A031 |=C2=A0 =C2=A0 =C2=A0BUILD_BUG_ON(alignof(struct membanks) =
!=3D 8);<br>
<br>
When CONFIG_PHYS_ADDR_T_32 is set, paddr_t is defined as unsigned long,<br>
therefore the struct membanks alignment is 4B and not 8B. The check is<br>
there to ensure the struct membanks and struct membank, which is a<br>
member of the former, are equally aligned. Therefore modify the check to<br=
>
compare alignments obtained via alignof not to rely on hardcoded<br>
values.<br>
<br>
Fixes: 2209c1e35b47 (&quot;xen/arm: Introduce a generic way to access memor=
y bank structures&quot;)<br>
Signed-off-by: Michal Orzel &lt;<a href=3D"mailto:michal.orzel@amd.com" tar=
get=3D"_blank">michal.orzel@amd.com</a>&gt;<br>
Release-Acked-by: Oleksii Kurochko &lt;<a href=3D"mailto:oleksii.kurochko@g=
mail.com" target=3D"_blank">oleksii.kurochko@gmail.com</a>&gt;</blockquote>=
<div dir=3D"auto"><br></div><div dir=3D"auto">Reviewed-by: Julien Grall &lt=
;<a href=3D"mailto:julien@xen.org">julien@xen.org</a>&gt;</div><div dir=3D"=
auto"><br></div><div dir=3D"auto">Cheers,</div><div dir=3D"auto"><br></div>=
<div dir=3D"auto"><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex" dir=3D"auto"><br=
>
---<br>
Changes in v2:<br>
=C2=A0- modify the check to test against alignment of struct membank<br>
---<br>
=C2=A0xen/common/device-tree/bootfdt.c | 4 ++--<br>
=C2=A01 file changed, 2 insertions(+), 2 deletions(-)<br>
<br>
diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/boot=
fdt.c<br>
index 47386d4fffea..529c91e603ab 100644<br>
--- a/xen/common/device-tree/bootfdt.c<br>
+++ b/xen/common/device-tree/bootfdt.c<br>
@@ -27,8 +27,8 @@ static void __init __maybe_unused build_assertions(void)<=
br>
=C2=A0 =C2=A0 =C2=A0 */<br>
=C2=A0 =C2=A0 =C2=A0BUILD_BUG_ON((offsetof(struct membanks, bank) !=3D<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 offsetof(str=
uct meminfo, bank)));<br>
-=C2=A0 =C2=A0 /* Ensure &quot;struct membanks&quot; is 8-byte aligned */<b=
r>
-=C2=A0 =C2=A0 BUILD_BUG_ON(alignof(struct membanks) !=3D 8);<br>
+=C2=A0 =C2=A0 /* Ensure &quot;struct membanks&quot; and &quot;struct memba=
nk&quot; are equally aligned */<br>
+=C2=A0 =C2=A0 BUILD_BUG_ON(alignof(struct membanks) !=3D alignof(struct me=
mbank));<br>
=C2=A0}<br>
<br>
=C2=A0static bool __init device_tree_node_is_available(const void *fdt, int=
 node)<br>
-- <br>
2.25.1<br>
<br>
</blockquote></div></div>

--000000000000d3eea1062cc8da35--


From xen-devel-bounces@lists.xenproject.org Tue Jan 28 21:01:25 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 21:01:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878787.1288975 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcsht-0006Mi-Vt; Tue, 28 Jan 2025 21:01:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878787.1288975; Tue, 28 Jan 2025 21:01:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcsht-0006Mb-Sw; Tue, 28 Jan 2025 21:01:13 +0000
Received: by outflank-mailman (input) for mailman id 878787;
 Tue, 28 Jan 2025 21:01:12 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=ZS2U=UU=gmail.com=shentey@srs-se1.protection.inumbo.net>)
 id 1tcshs-0006MV-8q
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 21:01:12 +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 ff999f3e-ddba-11ef-a0e6-8be0dac302b0;
 Tue, 28 Jan 2025 22:01:09 +0100 (CET)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-5d3f57582a2so128677a12.1
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 13:01:09 -0800 (PST)
Received: from [127.0.0.1] (dynamic-089-012-042-254.89.12.pool.telefonica.de.
 [89.12.42.254]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab6760ab311sm860147666b.97.2025.01.28.13.01.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 28 Jan 2025 13:01:08 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ff999f3e-ddba-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1738098069; x=1738702869; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:references
         :in-reply-to:subject:cc:to:from:date:from:to:cc:subject:date
         :message-id:reply-to;
        bh=NTNqOQ4RwVUWCgn6HX+Oj/bHeQslJwkndeT4/tSVYlU=;
        b=CvITPvJWlKRKHO3aWOqYPbYsyrLWZa+m2l9nB8JM+4EPxdyqez2Dr1pkI8Hjz4IcuY
         044Wsjkwb9kIlSFcNNmDlF7Wt85BhIz6MM8fllRNcn9TzNztlBUAW2ID1z6xF41xUJMU
         Mqcew/vD0VO42tdjQ3cNAQBrihPcw/KUwvYwiXcaxLr4QWAm3Bidj+CNg1Ld5iv8G0F4
         j8lPyfrM5ZHxGge8IVylmn0/mSLq5uROg4UOvSwDx1RF/62buL+O+5b0ySrl+++vCiG+
         S4bbIRahntpMwjLIMIq9RoCj9Te5GWZfBTP/s7PbAlNXeJCcyYpkdUKy5VVtWKYEPp4a
         lKPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738098069; x=1738702869;
        h=content-transfer-encoding:mime-version:message-id:references
         :in-reply-to:subject:cc:to:from:date:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=NTNqOQ4RwVUWCgn6HX+Oj/bHeQslJwkndeT4/tSVYlU=;
        b=jYfP9deA7qelb6JaMIjBFIR1hrr/hBXxA30nksNKFZK63OAUAdrddQ040ZilFB678E
         22KdzO3hRvJF3gD7Q1ug5M2NPvSCkcDgONwu9pJ3DuwqSgnrAVyxZL0YOlh0ybDzfWaP
         xMuyHioVhVZjStiCeSQ4BeIhtTJMXrHpO4337O8edi1qg0KK2/LcIfNP7oVdrpWMeToh
         a8Ab4KS4fsx+J+ctP+ue1c0Xdc7Mcpng4sgxP5wGdOZrgRvPnTNS+ssrPus1Nz9Oc9Ss
         h4aZtxY5iVL9oa/7VAoFWvJK3yaaE9EBRtlGB02EMGNUMy+Y967nodQ2IaTn5EbO/OYi
         OSDQ==
X-Forwarded-Encrypted: i=1; AJvYcCWvihNWySOG77iAiCBQeLWhUYXBnB5YfuVJxBsRsN1d2R7s/JOk4XuVqasVCE7ij15HXc9J33RhpU0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwpKT97AN0XM27n7I1wy5YcwSsukutmE2YGDzGNvOM0MoL5mGQy
	W+T9b3ALNXZhqcyh0GOPx4iFYA79CqRkv66vdP46nNT9tROdjCe5
X-Gm-Gg: ASbGncvX3iRke9hcvnn+PvEKswluP3NzSseiS7xjUd79zdVGUkq6vN+a4v4SV9lkrAu
	kqY6XXIuvaB1u3xdmiaK/tcPi8qLQ+De7NROijRdWD3hvkXNxDWiBLQZlp7QkPQc4HoiVTL7I6U
	sqzRMln4yKlA+MRT5tH/ZWUMETXlZwb9i95/RkrAbs45Wejx3EjulUdn+imp/mW5aWgmy5zDTXu
	w6FSJCukfs7r4RKoN5mjha8tjdoMjDpth6tdrB/fETAj7t+F7ufd3mllhUE2iTqdezfkiSqRNw3
	riO9K6XixkPzQwLBLvUSBMQtshr5QQ85JwUDYLThCTOv/Rn3Ku/86PXTd10rdJhM
X-Google-Smtp-Source: AGHT+IEUH1MqAsTKouPAgO63mx87B7XD+KP2maJkZHlUr1Y668zI87sZ/y2pdGu6scR74+6RcErjsQ==
X-Received: by 2002:a17:907:3f25:b0:aa4:cd1e:c91b with SMTP id a640c23a62f3a-ab6bbaa8a32mr417503766b.7.1738098068537;
        Tue, 28 Jan 2025 13:01:08 -0800 (PST)
Date: Tue, 28 Jan 2025 19:13:56 +0000
From: Bernhard Beschow <shentey@gmail.com>
To: =?ISO-8859-1?Q?Philippe_Mathieu-Daud=E9?= <philmd@linaro.org>,
 BALATON Zoltan <balaton@eik.bme.hu>,
 Peter Maydell <peter.maydell@linaro.org>
CC: Gerd Hoffmann <kraxel@redhat.com>, qemu-devel@nongnu.org,
 Yi Liu <yi.l.liu@intel.com>, Markus Armbruster <armbru@redhat.com>,
 Eduardo Habkost <eduardo@habkost.net>,
 Anthony PERARD <anthony@xenproject.org>,
 Gustavo Romero <gustavo.romero@linaro.org>, Jason Wang <jasowang@redhat.com>,
 qemu-ppc@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>,
 Paolo Bonzini <pbonzini@redhat.com>, Alexander Graf <graf@amazon.com>,
 Richard Henderson <richard.henderson@linaro.org>,
 Stefan Berger <stefanb@linux.vnet.ibm.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 =?ISO-8859-1?Q?Daniel_P=2E_Berrang=E9?= <berrange@redhat.com>,
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
 xen-devel@lists.xenproject.org,
 Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
 Alex Williamson <alex.williamson@redhat.com>, Paul Durrant <paul@xen.org>,
 =?ISO-8859-1?Q?Cl=E9ment_Mathieu--Drif?= <clement.mathieu--drif@eviden.com>,
 =?ISO-8859-1?Q?C=E9dric_Le_Goater?= <clg@redhat.com>
Subject: =?US-ASCII?Q?Re=3A_=5BPATCH_0/9=5D_hw/sysbus/platform-bus?=
 =?US-ASCII?Q?=3A_Introduce_TYPE=5FDYNAMIC=5FSYS=5FBUS=5FDEVICE?=
In-Reply-To: <990dacab-6cfd-4a18-944d-ba076a80996c@linaro.org>
References: <20250125181343.59151-1-philmd@linaro.org> <wkb53fhvfchqa4uvmifgitvcr7t7rfpc3hcohdhzczkzvktetx@yjveswjel3s4> <CAFEAcA-QOYcnJi=joKHbRmUCXK1UFOgQRgYP-fDq4h_1SkMGyQ@mail.gmail.com> <2893a552-ca6c-01c4-dcc0-6107ccf1c7b5@eik.bme.hu> <990dacab-6cfd-4a18-944d-ba076a80996c@linaro.org>
Message-ID: <291CA1E7-6220-4F8E-90E1-D38723E7FDBE@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable



Am 28=2E Januar 2025 15:10:18 UTC schrieb "Philippe Mathieu-Daud=C3=A9" <p=
hilmd@linaro=2Eorg>:
>On 28/1/25 13:57, BALATON Zoltan wrote:
>> On Tue, 28 Jan 2025, Peter Maydell wrote:
>>> On Tue, 28 Jan 2025 at 10:42, Gerd Hoffmann <kraxel@redhat=2Ecom> wrot=
e:
>>>>=20
>>>> On Sat, Jan 25, 2025 at 07:13:34PM +0100, Philippe Mathieu-Daud=C3=A9=
 wrote:
>>>>> Some SysBus devices can optionally be dynamically plugged onto
>>>>> the sysbus-platform-bus (then virtual guests are aware of
>>>>> mmio mapping and IRQs via device tree / ACPI rules)=2E
>>>>=20
>>>> Do we have some sane way to have user-pluggable sysbus devices on arm=
?
>>>=20
>>> The answer in a general sense is "no, because user pluggable
>>> sysbus is a weird idea"=2E "sysbus" means "it's wired into a
>>> specific bit of the memory map and to specific IRQs, and whoever
>>> does that needs to know what IRQs and bits of memory are usable,
>>> and the guest OS needs to know it's there"=2E "user-pluggable" means
>>> "it's all automatic and the guest can just do some kind of
>>> probing for what is or isn't present"=2E All the platform bus stuff
>>> is a nasty mess that's working around the things people want
>>> to plug in not being clean devices on probeable buses :-(
>>> And the platform bus is only supported on the "virt" board,
>>> because that's the only one where QEMU is generating its
>>> own dtb or ACPI tables where it can tell the guest "hey,
>>> there's some device here"=2E
>>=20
>> There are some SoCs that have memory mapped devices but different versi=
ons in the same family have different devices=2E Either older ones missing =
some devices or have less USB or network ports while newer SoCs have more o=
f those or they have PCIe instead of PCI=2E Modelling these could use plugg=
able sysbus devices so one could add the devices needed for a SoC version w=
ithout having to write or modify a board code=2E I think Bernhard's attempt=
 to try creating e500 SoCs from a device tree goes in that direction too=2E=
 We could also model this by having a SoC that can instantiate devices base=
d on some properties but maybe pluggable devices could be more generic for =
this=2E The issue seems to be how to tell the board or SoC where to map it =
and what IRQ to connect it as this is done by the board and not the device =
so properties on the device to set these does not really help unless the bo=
ard can somehow query it and instantiate the devices based on that=2E Other=
wise whatever handles the -device option to create the device would need kn=
owledge about the board=2E (E=2Eg=2E the e500 devices are mapped in the CCS=
R memory region so one can't just use system address space for them=2E)
>
>IIRC Bernard's series takes a DTB as input and create the machine
>matching this DTB=2E

That's correct=2E It's still on my todo list to send an RFC=2E I first wan=
ted to gain some experience implementing a machine in the classic way which=
 I've now done by means of the imx8mp-evk series=2E Once I clean up the e50=
0-fdt branch I'd send an RFC=2E

Best regards,
Bernhard

>
>As Peter explained, sysbus-platform-bus fits TYPE_DYNAMIC_SYS_BUS_DEVICE
>in free slots, then generates the corresponding ACPI/DTB=2E
>
>What you describe seems closer to the QEMU Dynamic Machine project,
>following Damien's idea:
>https://lore=2Ekernel=2Eorg/qemu-devel/20220223090706=2E4888-1-damien=2Eh=
edde@greensocs=2Ecom/
>We are not quite there yet=2E=2E=2E


From xen-devel-bounces@lists.xenproject.org Tue Jan 28 22:33:32 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 22:33:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878796.1288985 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcu8z-0008Px-8w; Tue, 28 Jan 2025 22:33:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878796.1288985; Tue, 28 Jan 2025 22:33:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcu8z-0008Pq-50; Tue, 28 Jan 2025 22:33:17 +0000
Received: by outflank-mailman (input) for mailman id 878796;
 Tue, 28 Jan 2025 22:33: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 <SRS0=JyBM=UU=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tcu8w-0008Pk-5K
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 22:33:15 +0000
Received: from mail-10631.protonmail.ch (mail-10631.protonmail.ch
 [79.135.106.31]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id dab53a59-ddc7-11ef-a0e6-8be0dac302b0;
 Tue, 28 Jan 2025 23:33:11 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: dab53a59-ddc7-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1738103589; x=1738362789;
	bh=zLx8nL/IwzbdH+g2HkXwZc+1rt/lRU8lkTfIUq74OLM=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=c5lIao5knnCpDG5ponZJb7ClM9blXnu6bClGfqrNVIjDfaou1ygMIstzaWGZdk59t
	 uNOjHhxxZvgdvbqDrYOvU+p5PIeiGIAns1M4kfdKCdo1YqegozTTqJmc1u+tCsQSSG
	 fJO3aZiaZ4ByAEOfHilCEB6Ds0m0uF2sY3aDPAuNxL70aEcy8KohEUxdq4QT2XRPjf
	 b9G6eNUaybUzL1GeJioUJdv/7rnHGXU4tC1wJOj2b6GdMF6UP6lmkU96Tlj+9iuLFy
	 iG6L6PzJP43mw1cICSquKVXSUPAhzlMyjuZ8mrDFtG+eQULC1ChTj3C3aPGljNGve+
	 7dXxHrRuvnwRQ==
Date: Tue, 28 Jan 2025 22:33:06 +0000
To: Jason Andryuk <jason.andryuk@amd.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org, Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>, Andrew Cooper <andrew.cooper3@citrix.com>, Anthony PERARD <anthony.perard@vates.tech>, Jan Beulich <jbeulich@suse.com>, =?utf-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Subject: Re: [PATCH v3 03/24] arm/vuart: add hwdom prefix to UART emulator
Message-ID: <3AuUpd0Cc-g1yFVxMbkH8S4BQcUVr5VIbP3vRXZfXrrfLNDPxpOkRyP4PzMOrLxcY7vcKQ0xuWDuYU_A4XReYUA5VH6VOBBhdPZSOksawVU=@proton.me>
In-Reply-To: <228a7d42-682d-4898-be1b-03fdd257ad70@amd.com>
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com> <20250103-vuart-ns8250-v3-v1-3-c5d36b31d66c@ford.com> <228a7d42-682d-4898-be1b-03fdd257ad70@amd.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 262bd474f9d324a960dfc11d1678f76fea0a773e
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


On Monday, January 27th, 2025 at 2:58 PM, Jason Andryuk <jason.andryuk@amd.=
com> wrote:

>=20
>=20
> On 2025-01-03 20:58, Denis Mukhin via B4 Relay wrote:
>=20
> > From: Denis Mukhin dmukhin@ford.com
> >=20
> > Using "vuart" in UART emulator designed for hardware domain debugging
> > is confusing in generic Arm code (e.g. vpl011 is also "vuart").
> > Fix that by adding hwdom prefix to all symbols in arm/vuart.c.
> >=20
> > Also, remove domain_has_vuart() from arm/vuart.c since it is not needed=
.
> >=20
> > Signed-off-by: Denis Mukhin dmukhin@ford.com
>=20
> > diff --git a/xen/arch/arm/vuart.c b/xen/arch/arm/vuart.c
> > index 98a65b99385a2a119725bab8634ed7cf9d926d68..23e05dba3a5617863f6c08f=
085c358f2cf32a292 100644
> > --- a/xen/arch/arm/vuart.c
> > +++ b/xen/arch/arm/vuart.c
>=20
> > @@ -66,15 +64,12 @@ int domain_vuart_init(struct domain *d)
> > return 0;
> > }
> >=20
> > -void domain_vuart_free(struct domain *d)
> > +void hwdom_vuart_free(struct domain *d)
> > {
> > - if ( !domain_has_vuart(d) )
> > - return;
> > -
> > - xfree(d->arch.vuart.buf);
> > + XFREE(d->arch.vuart.buf);
>=20
>=20
> I guess the code before and now both relied on struct domain being
> zero-initialized. You've made the free depend on the actual buffer
> instead of info as a proxy.
>=20
> Reviewed-by: Jason Andryuk jason.andryuk@amd.com

Thank you.

>=20
>=20
> Regards,
> Jason


From xen-devel-bounces@lists.xenproject.org Tue Jan 28 22:35:05 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 22:35:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878804.1288994 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcuAi-0000WW-JJ; Tue, 28 Jan 2025 22:35:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878804.1288994; Tue, 28 Jan 2025 22:35:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcuAi-0000WP-Ft; Tue, 28 Jan 2025 22:35:04 +0000
Received: by outflank-mailman (input) for mailman id 878804;
 Tue, 28 Jan 2025 22:35:03 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=LT9m=UU=amd.com=Jason.Andryuk@srs-se1.protection.inumbo.net>)
 id 1tcuAh-0000WH-MS
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 22:35:03 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20609.outbound.protection.outlook.com
 [2a01:111:f403:2418::609])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1c72f579-ddc8-11ef-99a4-01e77a169b0f;
 Tue, 28 Jan 2025 23:35:01 +0100 (CET)
Received: from MN0PR03CA0021.namprd03.prod.outlook.com (2603:10b6:208:52f::35)
 by CH3PR12MB9316.namprd12.prod.outlook.com (2603:10b6:610:1ce::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.22; Tue, 28 Jan
 2025 22:34:56 +0000
Received: from BN1PEPF0000468D.namprd05.prod.outlook.com
 (2603:10b6:208:52f:cafe::b6) by MN0PR03CA0021.outlook.office365.com
 (2603:10b6:208:52f::35) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8377.24 via Frontend Transport; Tue,
 28 Jan 2025 22:34:56 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN1PEPF0000468D.mail.protection.outlook.com (10.167.243.138) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8398.14 via Frontend Transport; Tue, 28 Jan 2025 22:34:56 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 28 Jan
 2025 16:34:55 -0600
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 28 Jan
 2025 16:34:55 -0600
Received: from [172.25.15.116] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Tue, 28 Jan 2025 16:34:54 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1c72f579-ddc8-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=NxdgHDd4R3LzGBjfVMj6KguK+og0kLJp2h0ym5ZcyrzzmHT4HHKCUOiU9g2IpqfDMaLdXY31eHsQjsP8uGj5cl8T9KT8Hbhx2+w80XxuG+Q2jF9A+ANvUQxub9JZu9Ut3Rt8lTWZsyaE8KtBmb7Go53WZBi22n8ZAGQkTmaYZn37i90KcR2IhyNL864T3RFZ4lhxZo+PrlFES4jza/Nx7hkDrevz8IyryhHRP57bt9qEs7GYrfD91Z7uBdiZdoACmhqp54cETzTOVTlM+TYZ12Z9MZ09OsBZKzLALrNin3ZHhHBiJ/nrT2JtCvXMai8vzx7IHFYqFy1/8tFekEzfAQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=kjREZM+WkORLLCFukDoPY3JgX+OtpvlTGAO9r4XIFo0=;
 b=keWZ7KOqni0HIMBBN09LhzWmWL9m6nNr8f7PEZuKPFM/uOiFzVqtTwrIw5GQ8BGkWB34kxsmW+DCsgW5Ceim9/WU1JrnHTl+t9x1hGrMT8wk0hMTgzpdqhCJwplhBH0yM//PUrIEu3qorsuJ5mCzwiKaHrTxxIrILbXd0MJguYigqOLz+j1hUkRyqOeQURqy2JFmzO5yfLX5r2hJgwBsZBQeaaD2KNp7IDh8m9N1qsWCAplpFNeRVf/PRtk0QWcQUwOQRktMLWJ7NkdNcp0vQhwzEVFIZs0krwjfi+pzyERgpTmM5aoh0ZaMtGUDEWIPjQQkgibYJse6BgH8JKR+WA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=ford.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=kjREZM+WkORLLCFukDoPY3JgX+OtpvlTGAO9r4XIFo0=;
 b=xduY/EfC10DVvQE+Z5KjauCv6J6UlFikF83uW0+P9pyTtMyg5Jcfgp8HQvZtlrli63zpeay83+j2WQama/40oKc12TmVjhXpuZ+XhZnngsYNFHvoiPUT6seG5oj56uH6qRAOfEnG0mqSM1mjAvbuFijjx3dc7pm0893FEnStEAI=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <d58cfd92-cd73-4a7f-8660-6a235ae887e5@amd.com>
Date: Tue, 28 Jan 2025 17:34:56 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 19/24] xen/8250-uart: add missing definitions
To: <dmukhin@ford.com>, <xen-devel@lists.xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
	<julien@xen.org>, Michal Orzel <michal.orzel@amd.com>, Andrew Cooper
	<andrew.cooper3@citrix.com>, Anthony PERARD <anthony.perard@vates.tech>, "Jan
 Beulich" <jbeulich@suse.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
	<roger.pau@citrix.com>
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
 <20250103-vuart-ns8250-v3-v1-19-c5d36b31d66c@ford.com>
Content-Language: en-US
From: Jason Andryuk <jason.andryuk@amd.com>
In-Reply-To: <20250103-vuart-ns8250-v3-v1-19-c5d36b31d66c@ford.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB05.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN1PEPF0000468D:EE_|CH3PR12MB9316:EE_
X-MS-Office365-Filtering-Correlation-Id: 5219ca82-bd43-4aab-fb65-08dd3febfd97
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|376014|82310400026|1800799024|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?OUtSUnFXdEhldDF1SzFiQWtMa1dWODYzd2Y5dC9UVHljcE9YQmwrNCszSU5V?=
 =?utf-8?B?NUplSjd4K05OSnY1MXRrb29ab2V0NG1FalhKOG10NzlsSDVFeFNJdjRlV3JB?=
 =?utf-8?B?c2VDaEp4dmY5N1lPYmlVZjRmM3JiOVhaMFc2U21IOXJWYmRsWnhqa0txS1p6?=
 =?utf-8?B?TWFRZ2UrZDdJZ1JTb1BtR2RsVXl0dW1ES0pWYnJ3M1JyVTVyRGh1WWd4a2pm?=
 =?utf-8?B?TStlbjR0RytZN21lZ1JQR2JrbkxTdnF5ZThJeDdRMDE1TVdLNytkR0llVXZL?=
 =?utf-8?B?Q2owWkNzS2h1bWc1bnIxZmEvdVhVbmlLaWNLZTRJNEVEZWUvYTJwNnJWaW1S?=
 =?utf-8?B?UXRpd0lCY0JFWnRMa0NKWEk5cHVKcVRMdVJ1VjFrT1hzb2tvTkJVU05oWDJ6?=
 =?utf-8?B?bUNkMWhmZVM3N0tlWWJmZFN5YkFUUTBGbnJpcUV1ZFpYb1I1cXBhZGJaVmhI?=
 =?utf-8?B?YU5OZkF4RDVBZnZsWTg0Y0hwRkNHbWVQOWVEZFk2dWYyMmpHNWFxeE5tSU96?=
 =?utf-8?B?cjZoa3l1WThDZytCWnYrQnRPQUYvWnFaSkg3MTA0aERhWms0SG1nb3NUN2xl?=
 =?utf-8?B?Rm5wMUYza0d2QytiUjM1dnJFRWdlS3pMYVNkSFhiQlQ4WDR3VStiWGJpZG1y?=
 =?utf-8?B?UWJobkpuWitDdUhWVmxnNzJvRnJCbmYrMURBNXF5Y3I2T3ZyM0F3aU0xd2RV?=
 =?utf-8?B?bGpRZFAycCtTQTRuaHVrVm92QVB3d2hWNjdMY1dmbE9LZWhZcWxadjYvRjJk?=
 =?utf-8?B?cERUd0pINFZxN1pHbjBaSmhkTFkzSkFOWGJOeUJpY1lab3dwcERleVZXWXFD?=
 =?utf-8?B?T011Y0I2dzl2ckNLVHR6VXZ5YmdQY1hselhqSlp5Vlhodk5iUTNITWU5Mk5Y?=
 =?utf-8?B?UUh4eStzRTUzaUt4amo2TFRyNnc5UmdGMlozbFZFZEJ2M2JrRjAvTEFId0g1?=
 =?utf-8?B?eDlkUU9mS29DMFltWW1DeWtPV1ZIR0JjYXZ2UkJlMlFnR0xGSDRiNzQvbzQr?=
 =?utf-8?B?WnFSdzR4QUpiOHdkNkVFczRtQU5rb2x0enQzTm5sV0VMZUxZZi9oK2Q2V3I3?=
 =?utf-8?B?MGtRcWlpTEQ5ZXRYb0VlL2x6SzZkMnRBemh5My9yYmYyTkI5R0kzaU4yNXpE?=
 =?utf-8?B?dkhVb3Z2QU40TC9LcTJQc1BsOG5DOXp5NXNvVUtRSUhheldEbXBESXJkNm5o?=
 =?utf-8?B?bDZ3c1FxMUdNcUVMWHdIQ04rby9CaXkrTW82eXhaYTNrY1J0b2w3ZU8vdHZJ?=
 =?utf-8?B?bnd2WXlYK2RDSFMwUXhGQk4xcjFGZUVKTDhnUWlydVdJSkR0R1Z5WWJvemR0?=
 =?utf-8?B?ckpUMlZFaHlxeEgxZHZtTkRxYW5FcTZrcFdQN0tpMDN4RGVxRzZJaXcwWEJ4?=
 =?utf-8?B?QmpscDdCTlJDUk13TmsrYnYrQTAzNVJDTzYzYlRGM05uaFM3ZlpEOGhQbDU5?=
 =?utf-8?B?M1BRMFZ2ZmhaTGgxblNoTVYrR2YvTTVvVDU0dFJiTDA1d3VZNm5XU1RDdzBa?=
 =?utf-8?B?eXRXSUh5STk2Mlh3M2VUbU9BWmsyODZBaC9nSGFtOWJRVXdsMkRUYXhkbS9L?=
 =?utf-8?B?RTBqdFBxdmZlUEZxZnJha1FZY2E1NkpoUDBSU1lVZGZpNFBlVjFGSitWSlNW?=
 =?utf-8?B?NDJzNXpIdjFmQzJpMzkvK3dmY2pRc1pteWs5YTBsVzZOeFBUTS9KdTFGUXdl?=
 =?utf-8?B?ajBFVG5QaGRSNlFEWU1qSHVQNCtjUjE2bVZ4MjJqNHhsMWdJdFhUT2VYWHJs?=
 =?utf-8?B?Sy82cWpqbU1pdjBseWRwNFZLQ2V4TEI5ZWVWblM3Q051aXFpd3owdlZ2WEx6?=
 =?utf-8?B?Z3NDMXM2dmlLMVhFUGQvZ2piaDYrNnpKdC9jZ001MVJzbVVOWXdhTlNtMzhH?=
 =?utf-8?B?dllBU3FRUEZ3NGp5Vjh6Qk9tU2FmTVY2aFlVbGg5ekw1dGJJcWJGS3BQM3pV?=
 =?utf-8?B?UDVYUktRb21PNVlGdmF4WForcFZ0NHIxcnNsNVJ6dnhGV2o3VnF4a1h2Wk1E?=
 =?utf-8?Q?jpcCgLMlyM/S95cg5P6KRsLvNPDtU4=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(82310400026)(1800799024)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2025 22:34:56.0313
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 5219ca82-bd43-4aab-fb65-08dd3febfd97
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN1PEPF0000468D.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB9316

On 2025-01-03 20:58, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin <dmukhin@ford.com>
> 
> Added missing definitions needed for NS8250 UART emulator.
> 
> Re-used newly introduced MSR definitions in the existing ns16550 driver.
> 
> Also, fixed indentation in a comment for FCR register.
> 
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>
> ---
>   xen/drivers/char/ns16550.c  |  6 ++--
>   xen/include/xen/8250-uart.h | 78 +++++++++++++++++++++++++++++++++------------
>   2 files changed, 60 insertions(+), 24 deletions(-)
> 

> diff --git a/xen/include/xen/8250-uart.h b/xen/include/xen/8250-uart.h
> index d13352940c13c50bac17d4cdf2f3bf584380776a..6d1af31d582a3dd674a401d7f649e28c889cdc3e 100644
> --- a/xen/include/xen/8250-uart.h
> +++ b/xen/include/xen/8250-uart.h

> @@ -51,12 +54,19 @@
>   #define UART_IIR_THR      0x02    /*  - tx reg. empty     */
>   #define UART_IIR_MSI      0x00    /*  - MODEM status      */
>   #define UART_IIR_BSY      0x07    /*  - busy detect (DW) */
> +#define UART_IIR_FE       0xC0    /* FIFO enabled (2 bits) */
>   
>   /* FIFO Control Register */
> -#define UART_FCR_ENABLE   0x01    /* enable FIFO          */
> -#define UART_FCR_CLRX     0x02    /* clear Rx FIFO        */
> -#define UART_FCR_CLTX     0x04    /* clear Tx FIFO        */
> -#define UART_FCR_DMA      0x10    /* enter DMA mode       */

0x10 is bit 4...

> +#define UART_FCR_ENABLE     BIT(0, U)   /* enable FIFO          */
> +#define UART_FCR_CLRX       BIT(1, U)   /* clear Rx FIFO        */
> +#define UART_FCR_CLTX       BIT(2, U)   /* clear Tx FIFO        */
> +#define UART_FCR_DMA        BIT(3, U)   /* enter DMA mode       */

Now it's 0x08.  Is this a bug fix?  Looks like UART_FCR_DMA is unused.

Regards,
Jason

> +#define UART_FCR_RESERVED0  BIT(4, U)   /* reserved; always 0   */
> +#define UART_FCR_RESERVED1  BIT(5, U)   /* reserved; always 0   */
> +#define UART_FCR_RTB0       BIT(6, U)   /* receiver trigger bit #0 */
> +#define UART_FCR_RTB1       BIT(7, U)   /* receiver trigger bit #1 */
> +#define UART_FCR_TRG_MASK   (UART_FCR_RTB0 | UART_FCR_RTB1)
> +
>   #define UART_FCR_TRG1     0x00    /* Rx FIFO trig lev 1   */
>   #define UART_FCR_TRG4     0x40    /* Rx FIFO trig lev 4   */
>   #define UART_FCR_TRG8     0x80    /* Rx FIFO trig lev 8   */



From xen-devel-bounces@lists.xenproject.org Tue Jan 28 23:58:38 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Jan 2025 23:58:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878815.1289005 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcvTO-0001lB-63; Tue, 28 Jan 2025 23:58:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878815.1289005; Tue, 28 Jan 2025 23:58:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcvTO-0001l4-2q; Tue, 28 Jan 2025 23:58:26 +0000
Received: by outflank-mailman (input) for mailman id 878815;
 Tue, 28 Jan 2025 23:58: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
 <SRS0=hG5x=UU=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tcvTN-0001ky-HD
 for xen-devel@lists.xenproject.org; Tue, 28 Jan 2025 23:58:25 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c15f592f-ddd3-11ef-a0e6-8be0dac302b0;
 Wed, 29 Jan 2025 00:58:23 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 90AA85C61F3;
 Tue, 28 Jan 2025 23:57:41 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id EEE92C4CED3;
 Tue, 28 Jan 2025 23:58:19 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c15f592f-ddd3-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1738108701;
	bh=WDIVgVXSZ73AxmTdh3o1mK6CERItzEu65S4Nz9OpFa4=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=T/d4+n1QaAdHRw4QQ5sRgj/vhtBhy4T6EUP4Wq2AVzgPlmLy7jXTf+UP8hfNHni6p
	 A3jVKyutIKqBmDg36X7jNZtIn2Et4Wb+c99yEDGLDcasTJhspUomwMt0EOOwrJx/Vl
	 Qu/8pGMceoM9DmmHsGpDVerUd8eoUfZ/O/cxy9VSUyTD2lOF6mK2C4aDwYvaR8+Pk/
	 yK3zfeA7qyysrjBa4sM6XQhfuR69ER1xXASGVHdn5ZoG5qQXXhkK3MEQgp9ujLf3++
	 0LTDTukJBkH08EHB8iV4QtdQxdbdVJ5T9sub9N9NL7wKzZq+NJ8kXtGOSeZVeNGkFb
	 Y0U0gjLczRDeg==
Date: Tue, 28 Jan 2025 15:58:14 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: "Edgar E. Iglesias" <edgar.iglesias@amd.com>
cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xenproject.org, 
    sstabellini@kernel.org, jgross@suse.com, 
    Anthony PERARD <anthony@xenproject.org>, Paul Durrant <paul@xen.org>, 
    jbeulich@suse.com, andrew.cooper3@citrix.com, roger.pau@citrix.com
Subject: Re: slow start of Pod HVM domU with qemu 9.1
In-Reply-To: <Z5j-bkdFZ7riavv7@zapote>
Message-ID: <alpine.DEB.2.22.394.2501281543580.3264561@ubuntu-linux-20-04-desktop>
References: <20250128151544.26fc827d.olaf@aepfle.de> <Z5j-bkdFZ7riavv7@zapote>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Tue, 28 Jan 2025, Edgar E. Iglesias wrote:
> On Tue, Jan 28, 2025 at 03:15:44PM +0100, Olaf Hering wrote:
> > Hello,
> > 
> > starting with qemu 9.1 a PoD HVM domU takes a long time to start.
> > Depending on the domU kernel, it may trigger a warning, which prompted me
> > to notice this change in behavior:
> > 
> > [    0.000000] Linux version 4.12.14-120-default (geeko@buildhost) (gcc version 4.8.5 (SUSE Linux) ) #1 SMP Thu Nov 7 16:39:09 UTC 2019 (fd9dc36)
> > ...
> > [    1.096432] HPET: 3 timers in total, 0 timers will be used for per-cpu timer
> > [    1.101636] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
> > [    1.104051] hpet0: 3 comparators, 64-bit 62.500000 MHz counter
> > [   16.136086] random: crng init done
> > [   31.712052] BUG: workqueue lockup - pool cpus=1 node=0 flags=0x0 nice=0 stuck for 30s!
> > [   31.716029] Showing busy workqueues and worker pools:
> > [   31.721164] workqueue events: flags=0x0
> > [   31.724054]   pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=2/256
> > [   31.728000]     in-flight: 17:balloon_process
> > [   31.728000]     pending: hpet_work
> > [   31.728023] workqueue mm_percpu_wq: flags=0x8
> > [   31.732987]   pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=1/256
> > [   31.736000]     pending: vmstat_update
> > [   31.736024] pool 2: cpus=1 node=0 flags=0x0 nice=0 hung=30s workers=2 idle: 34
> > [   50.400102] clocksource: Switched to clocksource xen
> > [   50.441153] VFS: Disk quotas dquot_6.6.0
> > ...
> > 
> > With qemu 9.0 and older, this domU will start the /init task after 8 seconds.
> > 
> > The change which caused this commit is qemu.git commit 9ecdd4bf08dfe4a37e16b8a8b228575aff641468
> > Author:     Edgar E. Iglesias <edgar.iglesias@amd.com>
> > AuthorDate: Tue Apr 30 10:26:45 2024 +0200
> > Commit:     Edgar E. Iglesias <edgar.iglesias@amd.com>
> > CommitDate: Sun Jun 9 20:16:14 2024 +0200
> > 
> >     xen: mapcache: Add support for grant mappings
> > 
> > As you can see, v4 instead of v5 was apparently applied.
> > This was probably unintentional, but would probably not change the result.
> 
> Hi Olaf,
> 
> It looks like v8 was applied, or am I missing something?
> 
> 
> > 
> > With this change the domU starts fast again:
> > 
> > --- a/hw/xen/xen-mapcache.c
> > +++ b/hw/xen/xen-mapcache.c
> > @@ -522,6 +522,7 @@ ram_addr_t xen_ram_addr_from_mapcache(void *ptr)
> >      ram_addr_t addr;
> >  
> >      addr = xen_ram_addr_from_mapcache_single(mapcache, ptr);
> > +    if (1)
> >      if (addr == RAM_ADDR_INVALID) {
> >          addr = xen_ram_addr_from_mapcache_single(mapcache_grants, ptr);
> >      }
> > @@ -626,6 +627,7 @@ static void xen_invalidate_map_cache_entry_single(MapCache *mc, uint8_t *buffer)
> >  static void xen_invalidate_map_cache_entry_all(uint8_t *buffer)
> >  {
> >      xen_invalidate_map_cache_entry_single(mapcache, buffer);
> > +    if (1)
> >      xen_invalidate_map_cache_entry_single(mapcache_grants, buffer);
> >  }
> >  
> > @@ -700,6 +702,7 @@ void xen_invalidate_map_cache(void)
> >      bdrv_drain_all();
> >  
> >      xen_invalidate_map_cache_single(mapcache);
> > +    if (0)
> >      xen_invalidate_map_cache_single(mapcache_grants);
> >  }
> >  
> > I did the testing with libvirt, the domU.cfg equivalent looks like this:
> > maxmem = 4096
> > memory = 2048
> > maxvcpus = 4
> > vcpus = 2
> > pae = 1
> > acpi = 1
> > apic = 1
> > viridian = 0
> > rtc_timeoffset = 0
> > localtime = 0
> > on_poweroff = "destroy"
> > on_reboot = "destroy"
> > on_crash = "destroy"
> > device_model_override = "/usr/lib64/qemu-9.1/bin/qemu-system-i386"
> > sdl = 0
> > vnc = 1
> > vncunused = 1
> > vnclisten = "127.0.0.1"
> > vif = [ "mac=52:54:01:23:63:29,bridge=br0,script=vif-bridge" ]
> > parallel = "none"
> > serial = "pty"
> > builder = "hvm"
> > kernel = "/bug1236329/linux"
> > ramdisk = "/bug1236329/initrd"
> > cmdline = "console=ttyS0,115200n8 quiet ignore_loglevel""
> > boot = "c" 
> > disk = [ "format=qcow2,vdev=hda,access=rw,backendtype=qdisk,target=/bug1236329/sles12sp5.qcow2" ]
> > usb = 1
> > usbdevice = "tablet"
> > 
> > Any idea what can be done to restore boot times?
> 
> 
> A guess is that it's taking a long time to walk the grants mapcache
> when invalidating (in QEMU). Despite it being unused and empty. We
> could try to find a way to keep track of usage and do nothing when
> invalidating an empty/unused cache.

If mapcache_grants is unused and empty, the call to
xen_invalidate_map_cache_single(mapcache_grants) should be really fast?

I think probably it might be the opposite: mapcache_grants is utilized,
so going through all the mappings in xen_invalidate_map_cache_single
takes time.

However, I wonder if it is really needed. At least in the PoD case, the
reason for the IOREQ_TYPE_INVALIDATE request is that the underlying DomU
memory has changed. But that doesn't affect the grant mappings, because
those are mappings of other domains' memory.

So I am thinking whether we should remove the call to
xen_invalidate_map_cache_single(mapcache_grants) ?

Adding x86 maintainers: do we need to flush grant table mappings for the
PV backends running in QEMU when Xen issues a IOREQ_TYPE_INVALIDATE
request to QEMU?


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 01:15:53 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 01:15:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878823.1289014 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcwg4-0002tf-Fc; Wed, 29 Jan 2025 01:15:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878823.1289014; Wed, 29 Jan 2025 01:15:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcwg4-0002tY-Ct; Wed, 29 Jan 2025 01:15:36 +0000
Received: by outflank-mailman (input) for mailman id 878823;
 Wed, 29 Jan 2025 01:15: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
 <SRS0=CGF7=UV=kernel.org=helgaas@srs-se1.protection.inumbo.net>)
 id 1tcwg2-0002tR-Mo
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 01:15:34 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 881df907-ddde-11ef-a0e6-8be0dac302b0;
 Wed, 29 Jan 2025 02:15:31 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 6AB14A4165D;
 Wed, 29 Jan 2025 01:13:43 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id B1D51C4CED3;
 Wed, 29 Jan 2025 01:15:29 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 881df907-ddde-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1738113329;
	bh=LPH+rFFvj0cEdutC7LtIU0vNsmeZQG7HJPWEn8vdN3Q=;
	h=Date:From:To:Cc:Subject:In-Reply-To:From;
	b=iV9OlV/aXWEEdLHO2uvdr6xaCFhmHutsN2xpsLTRCNq2ST+c6gCBo6fi6NBvY/82X
	 RqfudEpz9SDziEyepzeBi/dwX51b7VPEjIu2iEdjwsJ/qv6KrjptJohHIQJH1rYeKn
	 G2md0z7KlR0jvwPODLzLE1jexGtQXpw2qeHFEtG/l+Lz7oGBvQgOA1lFEjMnpWJdnr
	 V/gUaKp2W66i76UxCCRSkIl+3+XZb4utYI+NC3GHw6XOvsXwtUZ4c8/bYubYizdFMZ
	 6S/4D8RImB6QC5xpgk8TPVKMevaOwjiXqVBZL2jtzjif7CueSC6RkTXr44ZLEEthad
	 s2vGUM3FxWKJA==
Date: Tue, 28 Jan 2025 19:15:26 -0600
From: Bjorn Helgaas <helgaas@kernel.org>
To: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	=?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	linux-kernel@vger.kernel.org, regressions@lists.linux.dev,
	Felix Fietkau <nbd@nbd.name>, Lorenzo Bianconi <lorenzo@kernel.org>,
	Ryder Lee <ryder.lee@mediatek.com>
Subject: Re: Config space access to Mediatek MT7922 doesn't work after device
 reset in Xen PV dom0 (regression, Linux 6.12)
Message-ID: <20250129011526.GA184585@bhelgaas>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <Z4pHll_6GX7OUBzQ@mail-itl>

On Fri, Jan 17, 2025 at 01:05:30PM +0100, Marek Marczykowski-Górecki wrote:
> After updating PV dom0 to Linux 6.12, The Mediatek MT7922 device reports
> all 0xff when accessing its config space. This happens only after device
> reset (which is also triggered when binding the device to the
> xen-pciback driver).

Thanks for the report and for all the debugging you've already done!

> Reproducer:
> 
>     # lspci -xs 01:00.0
>     01:00.0 Network controller: MEDIATEK Corp. MT7922 802.11ax PCI Express Wireless Network Adapter
>     00: c3 14 16 06 00 00 10 00 00 00 80 02 10 00 00 00
>     ...
>     # echo 1 > /sys/bus/pci/devices/0000:01:00.0/reset
>     # lspci -xs 01:00.0
>     01:00.0 Network controller: MEDIATEK Corp. MT7922 802.11ax PCI Express Wireless Network Adapter
>     00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>
> The same operation done on Linux 6.12 running without Xen works fine.
> 
> git bisect points at:
> 
>     commit d591f6804e7e1310881c9224d72247a2b65039af
>     Author: Bjorn Helgaas <bhelgaas@google.com>
>     Date:   Tue Aug 27 18:48:46 2024 -0500
> 
>     PCI: Wait for device readiness with Configuration RRS
> 
> part of that commit:
> @@ -1311,9 +1320,15 @@ static int pci_dev_wait(struct pci_dev *dev, char *reset_type, int timeout)
>                         return -ENOTTY;
>                 }
>  
> -               pci_read_config_dword(dev, PCI_COMMAND, &id);
> -               if (!PCI_POSSIBLE_ERROR(id))
> -                       break;
> +               if (root && root->config_crs_sv) {
> +                       pci_read_config_dword(dev, PCI_VENDOR_ID, &id);
> +                       if (!pci_bus_crs_vendor_id(id))
> +                               break;
> +               } else {
> +                       pci_read_config_dword(dev, PCI_COMMAND, &id);
> +                       if (!PCI_POSSIBLE_ERROR(id))
> +                               break;
> +               }
>  
>     
> Adding some debugging, the PCI_VENDOR_ID read in pci_dev_wait() returns
> initially 0xffffffff. If I extend the condition with
> "&& !PCI_POSSIBLE_ERROR(id)", then the issue disappear. But reading the
> patch description, it would break VF.
> I'm not sure where the issue is, but given it breaks only when running
> with Xen, I guess something is wrong with "Configuration RRS Software
> Visibility" in that case.

I'm missing something.  If you get 0xffffffff, that is not the 0x0001
Vendor ID, so pci_dev_wait() should exit immediately.  But the log at
https://github.com/QubesOS/qubes-issues/issues/9689#issuecomment-2582927149
says it *doesn't* exit and eventually times out.

And the lspci above shows ~0 data for much of the header, even though
the device must be ready by then.

I don't have any good ideas, but since the problem only happens with
Xen, and it seems to affect more than just the Vendor ID, maybe you
could instrument xen_pcibk_config_read() and see if there's something
wonky going on there?

> BTW, shouldn't PCI_VENDOR_ID be accessed via pci_read_config_word()
> instead of pci_read_config_dword()?

Per PCIe r6.0, sec 2.3.2:

  If Configuration RRS Software Visibility is enabled (see below):

    For a Configuration Read Request that includes both bytes of the
    Vendor ID field of a device Function's Configuration Space Header,
    the Root Complex must complete the Request to the host by
    returning a read-data value of 0001h for the Vendor ID field and
    all ‘1’s for any additional bytes included in the request.

Since either a word (16 bit) or dword (32 bit) read includes both
bytes of Vendor ID, I think either should work.  We use a 32-bit read
in the enumeration path, where we need both Vendor ID and Device ID,
but we don't care about the Device ID here, so it probably doesn't
really matter here.


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 01:16:45 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 01:16:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878830.1289024 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcwhB-0003Oq-P9; Wed, 29 Jan 2025 01:16:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878830.1289024; Wed, 29 Jan 2025 01:16:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcwhB-0003Oj-MV; Wed, 29 Jan 2025 01:16:45 +0000
Received: by outflank-mailman (input) for mailman id 878830;
 Wed, 29 Jan 2025 01:16: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 <SRS0=Wz9u=UV=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tcwh9-0003OX-RI
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 01:16:44 +0000
Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch
 [185.70.40.133]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b211e3cb-ddde-11ef-99a4-01e77a169b0f;
 Wed, 29 Jan 2025 02:16:41 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b211e3cb-ddde-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1738113400; x=1738372600;
	bh=JdWJmHQbmjZeiqwUM39FyhLa0jEhfsyR5FX5P4UOsjk=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=K1MCrKKojTfksrtf406ona7lDmZjSKw5kQfU9geiDHMCqcCbE4UF1o8oi34K8x4QO
	 7ohOaAlgV2wK7CSGs1kBch31Tgg7nNzrcxDvXvadiSO3D2RTI2rawbRmbB+W0ezVJx
	 E0yWY5WgueYLkvgJEhDzkmYFxWs0JBt42JtS5BT61gtqRdYjpuTMTmdFPELdypBrY/
	 tgqtZsQqz8obvwsuylCU5b6jQRiysMHp/sEC5Hy92v0vpuPBSEBmRpwqrE2frcBncD
	 basmYuI9m7jj4cR+l/HpouRTOxV0FYnoqpvHq2qRIvzLSXkT0a1kSeR5w5f3Mqob0W
	 JfgZyjBZQhJcw==
Date: Wed, 29 Jan 2025 01:16:34 +0000
To: Jason Andryuk <jason.andryuk@amd.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org, Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>, Andrew Cooper <andrew.cooper3@citrix.com>, Anthony PERARD <anthony.perard@vates.tech>, Jan Beulich <jbeulich@suse.com>, =?utf-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Subject: Re: [PATCH v3 19/24] xen/8250-uart: add missing definitions
Message-ID: <_2QXLWvBsyAVvLYs1e9CcyCX4s4MXM4YyIrs-lqVvpVUzZTdO6qkqnwJzHV_EEQnWkUhn2nhazgADEnsEM4kf8ciUYTrsjSJll57wFcW4nM=@proton.me>
In-Reply-To: <d58cfd92-cd73-4a7f-8660-6a235ae887e5@amd.com>
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com> <20250103-vuart-ns8250-v3-v1-19-c5d36b31d66c@ford.com> <d58cfd92-cd73-4a7f-8660-6a235ae887e5@amd.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 66400b03a27ad5d1f6a74964080aec0ede54e61e
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tuesday, January 28th, 2025 at 2:34 PM, Jason Andryuk <jason.andryuk@amd=
.com> wrote:

>=20
>=20
> On 2025-01-03 20:58, Denis Mukhin via B4 Relay wrote:
>=20
> > From: Denis Mukhin dmukhin@ford.com
> >=20
> > Added missing definitions needed for NS8250 UART emulator.
> >=20
> > Re-used newly introduced MSR definitions in the existing ns16550 driver=
.
> >=20
> > Also, fixed indentation in a comment for FCR register.
> >=20
> > Signed-off-by: Denis Mukhin dmukhin@ford.com
> > ---
> > xen/drivers/char/ns16550.c | 6 ++--
> > xen/include/xen/8250-uart.h | 78 +++++++++++++++++++++++++++++++++-----=
-------
> > 2 files changed, 60 insertions(+), 24 deletions(-)
>=20
> > diff --git a/xen/include/xen/8250-uart.h b/xen/include/xen/8250-uart.h
> > index d13352940c13c50bac17d4cdf2f3bf584380776a..6d1af31d582a3dd674a401d=
7f649e28c889cdc3e 100644
> > --- a/xen/include/xen/8250-uart.h
> > +++ b/xen/include/xen/8250-uart.h
>=20
> > @@ -51,12 +54,19 @@
> > #define UART_IIR_THR 0x02 /* - tx reg. empty /
> > #define UART_IIR_MSI 0x00 / - MODEM status /
> > #define UART_IIR_BSY 0x07 / - busy detect (DW) /
> > +#define UART_IIR_FE 0xC0 / FIFO enabled (2 bits) */
> >=20
> > /* FIFO Control Register /
> > -#define UART_FCR_ENABLE 0x01 / enable FIFO /
> > -#define UART_FCR_CLRX 0x02 / clear Rx FIFO /
> > -#define UART_FCR_CLTX 0x04 / clear Tx FIFO /
> > -#define UART_FCR_DMA 0x10 / enter DMA mode */
>=20
>=20
> 0x10 is bit 4...
>=20
> > +#define UART_FCR_ENABLE BIT(0, U) /* enable FIFO /
> > +#define UART_FCR_CLRX BIT(1, U) / clear Rx FIFO /
> > +#define UART_FCR_CLTX BIT(2, U) / clear Tx FIFO /
> > +#define UART_FCR_DMA BIT(3, U) / enter DMA mode */
>=20
>=20
> Now it's 0x08. Is this a bug fix? Looks like UART_FCR_DMA is unused.

Correct, NS16550 defines FCR DMA as bit#3 (0x08):
  https://www.ti.com/lit/ds/symlink/tl16c550c.pdf

  Table 7-3. Summary of Accessible Registers
  7.7.2 FIFO Control Register (FCR)

>=20
> Regards,
> Jason
>=20
> > +#define UART_FCR_RESERVED0 BIT(4, U) /* reserved; always 0 /
> > +#define UART_FCR_RESERVED1 BIT(5, U) / reserved; always 0 /
> > +#define UART_FCR_RTB0 BIT(6, U) / receiver trigger bit #0 /
> > +#define UART_FCR_RTB1 BIT(7, U) / receiver trigger bit #1 /
> > +#define UART_FCR_TRG_MASK (UART_FCR_RTB0 | UART_FCR_RTB1)
> > +
> > #define UART_FCR_TRG1 0x00 / Rx FIFO trig lev 1 /
> > #define UART_FCR_TRG4 0x40 / Rx FIFO trig lev 4 /
> > #define UART_FCR_TRG8 0x80 / Rx FIFO trig lev 8 */
>=20
> 


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 02:11:06 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 02:11:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878839.1289035 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcxXg-0002Vs-Lb; Wed, 29 Jan 2025 02:11:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878839.1289035; Wed, 29 Jan 2025 02:11:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcxXg-0002Vl-Hw; Wed, 29 Jan 2025 02:11:00 +0000
Received: by outflank-mailman (input) for mailman id 878839;
 Wed, 29 Jan 2025 02:10: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
 <SRS0=ri1h=UV=invisiblethingslab.com=marmarek@srs-se1.protection.inumbo.net>)
 id 1tcxXf-0002Ve-FX
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 02:10:59 +0000
Received: from fhigh-a8-smtp.messagingengine.com
 (fhigh-a8-smtp.messagingengine.com [103.168.172.159])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 457bcbea-dde6-11ef-99a4-01e77a169b0f;
 Wed, 29 Jan 2025 03:10:55 +0100 (CET)
Received: from phl-compute-04.internal (phl-compute-04.phl.internal
 [10.202.2.44])
 by mailfhigh.phl.internal (Postfix) with ESMTP id 61FB7114020C;
 Tue, 28 Jan 2025 21:10:54 -0500 (EST)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-04.internal (MEProxy); Tue, 28 Jan 2025 21:10:54 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 28 Jan 2025 21:10:51 -0500 (EST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 457bcbea-dde6-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm3; t=1738116654;
	 x=1738203054; bh=UDmOJyg+nL9Ca/RFMJDJEHp0m/pv9KGep56/AvkHabk=; b=
	AHI8iyx2AWznrww/J+SAe0RvMYDPbKYZJVaZYgL/4cs6XZeOmBRJ9FruEWMXQ/7W
	B2ulpXoq2JGNaYzHuLpq1UULLWVoXMn/81e1ANKHDZbKwqQV4rrXwJJvd6lG5wxz
	emK1vGP0LIp75KKKefblSxt774t6sl80S5r7JwLTEWz61T5jAEFEGpoetf4pSwzo
	bjV3CgCC7jQ4sc/mxnR5SYAVcV5F9mhNW8c5DzhmcrnZOtuZoD2ELZtKXAa8maqs
	n/EayzFCAUwmhX4X8xQlKSgEWgU0fJC1Y6yh6vR1OZpFsv+kJAqmQoKnG3u99G/8
	ESrxLfA2AHX+sPr1ItFItg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:subject:subject:to
	:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=
	1738116654; x=1738203054; bh=UDmOJyg+nL9Ca/RFMJDJEHp0m/pv9KGep56
	/AvkHabk=; b=LjCkuUNxymlnQ4xsQXdzIPIs7D0NORJbqALtjk8EmvDuqD/H/Bc
	GmvEpfeZmMjvWzrb5r77pVYZ7FouRIihJRdQnwfdLdv2vibfdzA+C3vj+Mthd8xW
	dyv/DBS5chI0IONUm1uHC05MwnTgGqvSvGMvoyQrLHxTXDIC7giOfHslJzJL5ChO
	CNgqxtYXXtEWm/jMrVoKpO3MgQIKkQw1mQqgXpUGTaDGlcmBIO+PzJUcEzc620Jc
	b8EKAomEV7fmiEgqvlmz0R6xvY7uNGJE8pica/0KNo9eyJQM0PwOnQF5ubnGud2o
	OnaHhk0OWnIHB4jTJ0YG5rac+Ad4AEUe8nw==
X-ME-Sender: <xms:LY6ZZxCgUZGLz1x3xDkyotEexAnfnWLi_TKxVEwQh2bUaLFb2dSYxA>
    <xme:LY6ZZ_iiReyzZqJGQ1WoBwMOlQlCty7Mu-YSWXu7fYLEv5ZIlUJ-4Qe2p286T6Q6P
    EcK4yHY3hLY5Q>
X-ME-Received: <xmr:LY6ZZ8mLEW5emnrpwsc3g3w6eNNFD_KXwcyWoMSo0WDG9roI650oR0f6RCp76QC2-NtxUe0ROKTA4fqi5ibpHOHtvPE5t4UnVQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddujeehucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
    rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
    htshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtjeen
    ucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomh
    grrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggft
    rfgrthhtvghrnhepueekteetgefggfekudehteegieeljeejieeihfejgeevhfetgffgte
    euteetueetnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucevlhhushhtvghrufhi
    iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvhhish
    hisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopeduuddpmhhouggv
    pehsmhhtphhouhhtpdhrtghpthhtohephhgvlhhgrggrsheskhgvrhhnvghlrdhorhhgpd
    hrtghpthhtohepsghhvghlghgrrghssehgohhoghhlvgdrtghomhdprhgtphhtthhopehj
    ghhrohhsshesshhushgvrdgtohhmpdhrtghpthhtoheprhhoghgvrhdrphgruhestghith
    hrihigrdgtohhmpdhrtghpthhtohepsghorhhishdrohhsthhrohhvshhkhiesohhrrggt
    lhgvrdgtohhmpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprh
    hojhgvtghtrdhorhhgpdhrtghpthhtoheplhhinhhugidqkhgvrhhnvghlsehvghgvrhdr
    khgvrhhnvghlrdhorhhgpdhrtghpthhtoheprhgvghhrvghsshhiohhnsheslhhishhtsh
    drlhhinhhugidruggvvhdprhgtphhtthhopehnsggusehnsggurdhnrghmvg
X-ME-Proxy: <xmx:LY6ZZ7yGPhExS5Ev7OuQAXEfkGBAA7LKI5TSAjBrYa6lVDpQgYQ_Lw>
    <xmx:LY6ZZ2QKQP6XjMrpgJVjjJ14xzk8cpvhYSCIENpibCMUF5redAREKg>
    <xmx:LY6ZZ-bgsJc5rtqllxai9aR6w7W4ajdyugpt7N-grba-VDXvtw26lg>
    <xmx:LY6ZZ3T3A7stPPAunUzU0wljatnHj3rsdVts71XlAAHioPYaeVGACA>
    <xmx:Lo6ZZyb5eEwAl4IeYVLlgxl9eFZ6lFr8FY5AjDe_kCkwfUN5a0sm_YAI>
Feedback-ID: i1568416f:Fastmail
Date: Wed, 29 Jan 2025 03:10:49 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	=?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	linux-kernel@vger.kernel.org, regressions@lists.linux.dev,
	Felix Fietkau <nbd@nbd.name>, Lorenzo Bianconi <lorenzo@kernel.org>,
	Ryder Lee <ryder.lee@mediatek.com>
Subject: Re: Config space access to Mediatek MT7922 doesn't work after device
 reset in Xen PV dom0 (regression, Linux 6.12)
Message-ID: <Z5mOKQUrgeF_r6te@mail-itl>
References: <Z4pHll_6GX7OUBzQ@mail-itl>
 <20250129011526.GA184585@bhelgaas>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="6QJZaJl0dNJK9bmo"
Content-Disposition: inline
In-Reply-To: <20250129011526.GA184585@bhelgaas>


--6QJZaJl0dNJK9bmo
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Wed, 29 Jan 2025 03:10:49 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	=?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	linux-kernel@vger.kernel.org, regressions@lists.linux.dev,
	Felix Fietkau <nbd@nbd.name>, Lorenzo Bianconi <lorenzo@kernel.org>,
	Ryder Lee <ryder.lee@mediatek.com>
Subject: Re: Config space access to Mediatek MT7922 doesn't work after device
 reset in Xen PV dom0 (regression, Linux 6.12)

On Tue, Jan 28, 2025 at 07:15:26PM -0600, Bjorn Helgaas wrote:
> On Fri, Jan 17, 2025 at 01:05:30PM +0100, Marek Marczykowski-G=C3=B3recki=
 wrote:
> > After updating PV dom0 to Linux 6.12, The Mediatek MT7922 device reports
> > all 0xff when accessing its config space. This happens only after device
> > reset (which is also triggered when binding the device to the
> > xen-pciback driver).
>=20
> Thanks for the report and for all the debugging you've already done!
>=20
> > Reproducer:
> >=20
> >     # lspci -xs 01:00.0
> >     01:00.0 Network controller: MEDIATEK Corp. MT7922 802.11ax PCI Expr=
ess Wireless Network Adapter
> >     00: c3 14 16 06 00 00 10 00 00 00 80 02 10 00 00 00
> >     ...
> >     # echo 1 > /sys/bus/pci/devices/0000:01:00.0/reset
> >     # lspci -xs 01:00.0
> >     01:00.0 Network controller: MEDIATEK Corp. MT7922 802.11ax PCI Expr=
ess Wireless Network Adapter
> >     00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >
> > The same operation done on Linux 6.12 running without Xen works fine.
> >=20
> > git bisect points at:
> >=20
> >     commit d591f6804e7e1310881c9224d72247a2b65039af
> >     Author: Bjorn Helgaas <bhelgaas@google.com>
> >     Date:   Tue Aug 27 18:48:46 2024 -0500
> >=20
> >     PCI: Wait for device readiness with Configuration RRS
> >=20
> > part of that commit:
> > @@ -1311,9 +1320,15 @@ static int pci_dev_wait(struct pci_dev *dev, cha=
r *reset_type, int timeout)
> >                         return -ENOTTY;
> >                 }
> > =20
> > -               pci_read_config_dword(dev, PCI_COMMAND, &id);
> > -               if (!PCI_POSSIBLE_ERROR(id))
> > -                       break;
> > +               if (root && root->config_crs_sv) {
> > +                       pci_read_config_dword(dev, PCI_VENDOR_ID, &id);
> > +                       if (!pci_bus_crs_vendor_id(id))
> > +                               break;
> > +               } else {
> > +                       pci_read_config_dword(dev, PCI_COMMAND, &id);
> > +                       if (!PCI_POSSIBLE_ERROR(id))
> > +                               break;
> > +               }
> > =20
> >    =20
> > Adding some debugging, the PCI_VENDOR_ID read in pci_dev_wait() returns
> > initially 0xffffffff. If I extend the condition with
> > "&& !PCI_POSSIBLE_ERROR(id)", then the issue disappear. But reading the
> > patch description, it would break VF.
> > I'm not sure where the issue is, but given it breaks only when running
> > with Xen, I guess something is wrong with "Configuration RRS Software
> > Visibility" in that case.
>=20
> I'm missing something.  If you get 0xffffffff, that is not the 0x0001
> Vendor ID, so pci_dev_wait() should exit immediately. =20

I'm not sure what is going on there either, but my _guess_ is that the
loop exits too early due to the above. And it makes some further actions
to fail.

> But the log at
> https://github.com/QubesOS/qubes-issues/issues/9689#issuecomment-25829271=
49
> says it *doesn't* exit and eventually times out.

Note this log is from "working" kernel, so that timeout must be
something else.

> And the lspci above shows ~0 data for much of the header, even though
> the device must be ready by then.
>=20
> I don't have any good ideas, but since the problem only happens with
> Xen, and it seems to affect more than just the Vendor ID, maybe you
> could instrument xen_pcibk_config_read() and see if there's something
> wonky going on there?

This one is used when pcifront (from a different PV VM) is asking pciback
to read something. I see the issue even before starting any other VM and
not even attaching the device to the xen-pciback driver...

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

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

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmeZjikACgkQ24/THMrX
1yxAJgf+NiqMfF+ZZtj2paTgrsdwIeiDCWn9FCSBOq8E/MXmGaks7bDMFDMHmvos
Djuv7l+ToHkUmUmVGp0Qzl7DmBHawouf9wzy93WF6tm6PsaxrAxDgGPF3lLjYiDf
j2rlkqLK9Uykbl/SluEW8TRh4+nXLuVlmyWdzTEQ1EdehXNG7/2ZV1HLaq+GFgGC
ZGdQZLHE1QapVphEcazlc3y+vp+wRkWLVXeJ1w6FibzO9fWAZjbkaQsUsvkFNnr5
vrsZutGko4ZKD0FJTHw0RsnzhI/WlKIm1ScuR6TPZXvdCVFFtRMMr2rNWAzuU6MG
s5lMTZ/0jY3sDyoz7PwXqXGXVe7/yw==
=qrsQ
-----END PGP SIGNATURE-----

--6QJZaJl0dNJK9bmo--


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 03:03:37 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 03:03:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878850.1289044 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcyMO-0000CT-GN; Wed, 29 Jan 2025 03:03:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878850.1289044; Wed, 29 Jan 2025 03:03:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcyMO-0000CM-Do; Wed, 29 Jan 2025 03:03:24 +0000
Received: by outflank-mailman (input) for mailman id 878850;
 Wed, 29 Jan 2025 03:03:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=CGF7=UV=kernel.org=helgaas@srs-se1.protection.inumbo.net>)
 id 1tcyMN-0000CG-34
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 03:03:23 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org
 [2604:1380:4641:c500::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 972e6e8d-dded-11ef-99a4-01e77a169b0f;
 Wed, 29 Jan 2025 04:03:19 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id B04365C06BD;
 Wed, 29 Jan 2025 03:02:37 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 12191C4CED3;
 Wed, 29 Jan 2025 03:03:16 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 972e6e8d-dded-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1738119797;
	bh=HJAkZQawc1EkKVLluBErityMpfGIYGnetk7FRxtmY+w=;
	h=Date:From:To:Cc:Subject:In-Reply-To:From;
	b=a3ItYUWK/QZsO/64Gq2SoWwAqVGPgzrZFcUO2mgDWaDQYT90x3yiNuX1MxSyyyGnV
	 lvl8wgBzARdtYLF/3AnPj2+tTeMDKkw4NBPPZMfeB81qcq1w7KcMyY/ECH2k61CRJH
	 bmG8OCttIRBVcsLBGfoGSFxjr0l/CWTzllj9QfVZ9xsCILOoMWrdoECYrTsOx1I4xh
	 y6XS1hN1wvgryiL3UyKs7RmSjvnjARXjSX7qcM7Wst0THzLfLUJcmmRmwhzKNrOUwq
	 v0Mo3aZ6nEG1qVZxfNr4eAAdweR6jbyM99k+YUCFYq1jEL3nzNuX+YIPqwFgst4HGD
	 Jkwi26iWZvC9A==
Date: Tue, 28 Jan 2025 21:03:15 -0600
From: Bjorn Helgaas <helgaas@kernel.org>
To: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	=?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	linux-kernel@vger.kernel.org, regressions@lists.linux.dev,
	Felix Fietkau <nbd@nbd.name>, Lorenzo Bianconi <lorenzo@kernel.org>,
	Ryder Lee <ryder.lee@mediatek.com>, linux-pci@vger.kernel.org
Subject: Re: Config space access to Mediatek MT7922 doesn't work after device
 reset in Xen PV dom0 (regression, Linux 6.12)
Message-ID: <20250129030315.GA392478@bhelgaas>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <Z5mOKQUrgeF_r6te@mail-itl>

[+cc linux-pci]

On Wed, Jan 29, 2025 at 03:10:49AM +0100, Marek Marczykowski-Górecki wrote:
> On Tue, Jan 28, 2025 at 07:15:26PM -0600, Bjorn Helgaas wrote:
> > On Fri, Jan 17, 2025 at 01:05:30PM +0100, Marek Marczykowski-Górecki wrote:
> > > After updating PV dom0 to Linux 6.12, The Mediatek MT7922 device reports
> > > all 0xff when accessing its config space. This happens only after device
> > > reset (which is also triggered when binding the device to the
> > > xen-pciback driver).
> > 
> > Thanks for the report and for all the debugging you've already done!
> > 
> > > Reproducer:
> > > 
> > >     # lspci -xs 01:00.0
> > >     01:00.0 Network controller: MEDIATEK Corp. MT7922 802.11ax PCI Express Wireless Network Adapter
> > >     00: c3 14 16 06 00 00 10 00 00 00 80 02 10 00 00 00
> > >     ...
> > >     # echo 1 > /sys/bus/pci/devices/0000:01:00.0/reset
> > >     # lspci -xs 01:00.0
> > >     01:00.0 Network controller: MEDIATEK Corp. MT7922 802.11ax PCI Express Wireless Network Adapter
> > >     00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > >
> > > The same operation done on Linux 6.12 running without Xen works fine.
> > > 
> > > git bisect points at:
> > > 
> > >     commit d591f6804e7e1310881c9224d72247a2b65039af
> > >     Author: Bjorn Helgaas <bhelgaas@google.com>
> > >     Date:   Tue Aug 27 18:48:46 2024 -0500
> > > 
> > >     PCI: Wait for device readiness with Configuration RRS
> > > 
> > > part of that commit:
> > > @@ -1311,9 +1320,15 @@ static int pci_dev_wait(struct pci_dev *dev, char *reset_type, int timeout)
> > >                         return -ENOTTY;
> > >                 }
> > >  
> > > -               pci_read_config_dword(dev, PCI_COMMAND, &id);
> > > -               if (!PCI_POSSIBLE_ERROR(id))
> > > -                       break;
> > > +               if (root && root->config_crs_sv) {
> > > +                       pci_read_config_dword(dev, PCI_VENDOR_ID, &id);
> > > +                       if (!pci_bus_crs_vendor_id(id))
> > > +                               break;
> > > +               } else {
> > > +                       pci_read_config_dword(dev, PCI_COMMAND, &id);
> > > +                       if (!PCI_POSSIBLE_ERROR(id))
> > > +                               break;
> > > +               }
> > >  
> > >     
> > > Adding some debugging, the PCI_VENDOR_ID read in pci_dev_wait() returns
> > > initially 0xffffffff. If I extend the condition with
> > > "&& !PCI_POSSIBLE_ERROR(id)", then the issue disappear. But reading the
> > > patch description, it would break VF.
> > > I'm not sure where the issue is, but given it breaks only when running
> > > with Xen, I guess something is wrong with "Configuration RRS Software
> > > Visibility" in that case.
> > 
> > I'm missing something.  If you get 0xffffffff, that is not the 0x0001
> > Vendor ID, so pci_dev_wait() should exit immediately.  
> 
> I'm not sure what is going on there either, but my _guess_ is that the
> loop exits too early due to the above. And it makes some further actions
> to fail.

When RRS SV is enabled, reading PCI_VENDOR_ID should always return
0x0001 (if the device isn't ready and responds with RRS status) or the
valid Vendor ID.  I don't think it should ever return 0xffff (unless
the device is powered off, unplugged, or broken, of course).

> > But the log at
> > https://github.com/QubesOS/qubes-issues/issues/9689#issuecomment-2582927149
> > says it *doesn't* exit and eventually times out.
> 
> Note this log is from "working" kernel, so that timeout must be
> something else.

I saw it was labeled "NO BUG" but I'm not sure it's labeled correctly
since there are no interesting messages from the "BUG PRESENT" part.
Awfully funny coincidence if it's unrelated.

> > And the lspci above shows ~0 data for much of the header, even though
> > the device must be ready by then.
> > 
> > I don't have any good ideas, but since the problem only happens with
> > Xen, and it seems to affect more than just the Vendor ID, maybe you
> > could instrument xen_pcibk_config_read() and see if there's something
> > wonky going on there?
> 
> This one is used when pcifront (from a different PV VM) is asking pciback
> to read something. I see the issue even before starting any other VM and
> not even attaching the device to the xen-pciback driver...

The report claims the problem only happens with Xen.  I'm not a Xen
person, and I don't know how to find the relevant config accessors.
The snippets of kernel messages I see at [1] all mention pciback, so
that's my only clue of where to look.  Bottom line, I have no idea
what the config accessor path is, and maybe we could learn something
by looking at whatever it is.

[1] https://github.com/QubesOS/qubes-issues/issues/9689#issuecomment-2582927149


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 03:05:06 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 03:05:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878858.1289054 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcyO1-0000kV-QK; Wed, 29 Jan 2025 03:05:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878858.1289054; Wed, 29 Jan 2025 03:05:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcyO1-0000kO-ND; Wed, 29 Jan 2025 03:05:05 +0000
Received: by outflank-mailman (input) for mailman id 878858;
 Wed, 29 Jan 2025 03:05:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Wz9u=UV=proton.me=dmkhn@srs-se1.protection.inumbo.net>)
 id 1tcyNz-0000kG-AQ
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 03:05:04 +0000
Received: from mail-40131.protonmail.ch (mail-40131.protonmail.ch
 [185.70.40.131]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d414c793-dded-11ef-99a4-01e77a169b0f;
 Wed, 29 Jan 2025 04:05:01 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: d414c793-dded-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1738119899; x=1738379099;
	bh=PyFNH2W17lpXsSxCoKNfmr4ag+ROC15HYWFDAc6sbcA=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=THwOldtQxsh0qQl/YF+sO8qcqVLJE36v+ygoPGSar7cJwPOYowgHSeY+nqlgvuoU7
	 IQoLC2nf7OrZL/K3H5fcvwxWUhUZakLgvEQR+1/ifC0vHKGWVtDzhHPSwELgdFEDbN
	 /Al7XpLflWRxHUwVnt8UXEIzDre9Or4wVrN6Ibi/clpvgaNzyW4N0I+IApZDst3QKd
	 xkuv78WD+1jd1ju+cz3h+BHxfwNtYk0zefWfFqISruTnYtxH0yRTzRkKI5BKk1PCJU
	 zuxc6OEaoXec7RcDtSIkWaIqUjzSAx7bKdY1pMRO2U8hKALqoQiB3pYiKh9VqqJ6v1
	 v8zq5k9l8huYg==
Date: Wed, 29 Jan 2025 03:04:53 +0000
To: Jan Beulich <jbeulich@suse.com>
From: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>, Andrew Cooper <andrew.cooper3@citrix.com>, Anthony PERARD <anthony.perard@vates.tech>, =?utf-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, xen-devel@lists.xenproject.org, Denis Mukhin <dmkhn@proton.me>
Subject: Re: [PATCH v3 15/24] xen/console: make console buffer size configurable
Message-ID: <RKwzueYurWHDxryD0KUwTcZHRfprlyr4H0fIq4w-yV2i5uK4XfDGrWsUBgt8FnW4R-28hIjbclYcGVP62eLjfFAIwNjXzP0Qj2sajURd-8s=@proton.me>
In-Reply-To: <d471f3b0-5638-47b3-927e-318b0575eaa3@suse.com>
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com> <20250103-vuart-ns8250-v3-v1-15-c5d36b31d66c@ford.com> <d471f3b0-5638-47b3-927e-318b0575eaa3@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 2c63239978f09058f3816328b8ccca303c9a2959
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tuesday, January 28th, 2025 at 8:32 AM, Jan Beulich <jbeulich@suse.com> =
wrote:

>=20
>=20
> On 04.01.2025 02:58, Denis Mukhin via B4 Relay wrote:
>=20
> > From: Denis Mukhin dmukhin@ford.com
> >=20
> > Add new CONRING_SIZE Kconfig parameter to specify the boot console buff=
er size
> > in bytes. The value is rounded to the nearest power of 2 to match exist=
ing
> > conring_size=3D behavior.
> >=20
> > The supported range is [16KiB..128MiB].
> >=20
> > Bump default size to 32 KiB.
> >=20
> > Link: https://gitlab.com/xen-project/xen/-/issues/185
> > Signed-off-by: Denis Mukhin dmukhin@ford.com
>=20
>=20
> As asked elsewhere already: How's this related to the goal of the series?

I mentioned in the cover letter that there are two group of patches - conso=
le
driver cleanups/fixes and the follow on UART emulator (and up until v3 it w=
as OK
to have this patch bundled into the series).

Yes, I acknowledge that the first group of patches for console driver grew =
big
and probably should have been posted in its own thread.

I can move "console" part to its own series if it makes sense now.

What do you think?

>=20
> > --- a/docs/misc/xen-command-line.pandoc
> > +++ b/docs/misc/xen-command-line.pandoc
> > @@ -423,12 +423,15 @@ The following are examples of correct specificati=
ons:
> > com1=3Dbaud=3D115200,parity=3Dn,stop-bits=3D1,io-base=3D0x3f8,reg-width=
=3D4
> >=20
> > ### conring_size
> > -> `=3D <size>`
> > +> `=3D <size-in-bytes>`
>=20
>=20
> May I direct you to the explanations near the top of the file? <size>
>=20
> is a uniform term throughout this document, and wants to stay like this.
>=20
> > --- a/xen/drivers/char/Kconfig
> > +++ b/xen/drivers/char/Kconfig
> > @@ -96,6 +96,17 @@ config SERIAL_TX_BUFSIZE
> >=20
> > Default value is 32768 (32KiB).
> >=20
> > +config CONRING_SIZE
> > + int "Console buffer size"
> > + default 32768
> > + help
> > + Select the boot console buffer size (in bytes).
> > + Note, the value provided will be rounded down to the nearest power of=
 2.
> > + Run-time console buffer size is the same as the boot console size,
> > + unless enforced via 'conring_size=3D' boot parameter.
>=20
>=20
> Maybe s/enforced/overridden/ ?
>=20
> > + Default value is 32768 (32KiB). The supported range is [16KiB..128MiB=
].
>=20
>=20
> Yet then there's no "range" directive.
>=20
> > --- a/xen/drivers/char/console.c
> > +++ b/xen/drivers/char/console.c
> > @@ -100,12 +100,15 @@ static int cf_check parse_console_timestamps(cons=
t char *s);
> > custom_runtime_param("console_timestamps", parse_console_timestamps,
> > con_timestamp_mode_upd);
> >=20
> > -/* conring_size: allows a large console ring than default (16kB). /
> > +/ conring_size: allows a large console ring than default (32 KiB). */
>=20
>=20
> As you touch this, also s/large/larger/ ?
>=20
> > static uint32_t __initdata opt_conring_size;
> > size_param("conring_size", opt_conring_size);
> >=20
> > -#define _CONRING_SIZE 16384
> > -#define CONRING_IDX_MASK(i) ((i)&(conring_size-1))
> > +#define _CONRING_SIZE (1UL << (31 - __builtin_clz(CONFIG_CONRING_SIZE)=
))
> > +_Static_assert(_CONRING_SIZE >=3D 4096 && _CONRING_SIZE <=3D MB(128),
> > + "CONFIG_CONRING_SIZE must be in [4K..128M] range");
>=20
>=20
> Hmm, 4k here as the lower bound, when in description and Kconfig it's
> said to be 16k?
>=20
> Also I fear _Static_assert() can't be used here, for not being supported
> by all gcc versions we continue to permit being used on x86. That'll be
> unnecessary anyway once you put in place the missing range directive in
> Kconfig. (If something like this needed keeping, it would be
> BUILD_BUG_ON() that you want to use instead. Which, yes, can only be
> used inside a function. Hence why we have a number of build_assertions()
> functions throughout the codebase.)
>=20
> > +#define CONRING_IDX_MASK(i) ( (i) & (conring_size - 1) )
>=20
>=20
> Once again - no blanks immediately inside parentheses, except as
> written in ./CODING_STYLE (i.e. in control flow statements).
>=20
> Jan


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 03:23:01 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 03:23:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878868.1289065 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcyfH-0003Yw-8O; Wed, 29 Jan 2025 03:22:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878868.1289065; Wed, 29 Jan 2025 03:22:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcyfH-0003Yp-4l; Wed, 29 Jan 2025 03:22:55 +0000
Received: by outflank-mailman (input) for mailman id 878868;
 Wed, 29 Jan 2025 03:22:53 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=ri1h=UV=invisiblethingslab.com=marmarek@srs-se1.protection.inumbo.net>)
 id 1tcyfE-0003Yj-PH
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 03:22:53 +0000
Received: from fhigh-a8-smtp.messagingengine.com
 (fhigh-a8-smtp.messagingengine.com [103.168.172.159])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5078404d-ddf0-11ef-a0e6-8be0dac302b0;
 Wed, 29 Jan 2025 04:22:49 +0100 (CET)
Received: from phl-compute-06.internal (phl-compute-06.phl.internal
 [10.202.2.46])
 by mailfhigh.phl.internal (Postfix) with ESMTP id AECCD1140117;
 Tue, 28 Jan 2025 22:22:47 -0500 (EST)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-06.internal (MEProxy); Tue, 28 Jan 2025 22:22:47 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 28 Jan 2025 22:22:45 -0500 (EST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5078404d-ddf0-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm3; t=1738120967;
	 x=1738207367; bh=S7YOKlMbFES7C1wJ58+2rQQqMC0Rhv4K2F0BUr6oSnw=; b=
	n5lqyQm93dkFYPyIRmzqEFFJVBkj6tf/CHb4DN4ebxKT4KkqrtNYKBRf8pjH7f46
	q3HIb/K8BVHLw0oqN2C6M/3inVlPVQkqmDOcC4wlFIlP6lkNFWMy6alEidFq41aG
	nRhEUZY2scxwS3xMVHt1ed/LHN8kb/V06rROl4KQsCxPbMjKluPr6HXfdrPWT1Fh
	1f5ylg1Ei0wvLVWuSQKQOHnxSA74imKPpdAZ9xpqnaNZEErnP6+jhfE5546p+Ef4
	G2WDpa4ePDXy9k5Cf/CrsEbZIPVkgaPHrya6huXrTCRTanDPt0dR/Vgd9637bFyh
	dqv9ppWKNm6OkZLh373ptA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:subject:subject:to
	:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=
	1738120967; x=1738207367; bh=S7YOKlMbFES7C1wJ58+2rQQqMC0Rhv4K2F0
	BUr6oSnw=; b=l7QlGe/J/1xn8gg8+q7y5m0O3dvVLy44o4oM3fdUPw1WN+s8fTc
	Zsu6Wpwzm6TDWnAwRf0EgMvQ28ClnDAlnGPKyGF/fg8TAp+RIaR63tPeul8PBSkb
	+pABvy5U8H4z8u1C1I/NxXAe+xi/UVwA1av6HLJuAHJ31Q80zjk0cKtzbkW4zglz
	KDkJvz/0HWAoEDqwUBGWR6gMjRnAcdj4sgroSZb2Jy2YUBNPDbFhBDCikemzc1X4
	5UMLoml/bGzmIERJyNfOTLD9VhBprTCIkUSlUMXE2ovOZcjFR49qp2LZ9Iq1YIg2
	rzfj0jjCh8WXbS6mUkRxrav47JzuikmkorA==
X-ME-Sender: <xms:B5-ZZ2B3FkerFGiAb5rzKUieMrqRQTdeZYN8BM0YkxmCBIOp-gNfMg>
    <xme:B5-ZZwgwRwjeIGmV2yqBnvqrsV7F8zkz-qNPE_Fd5MKvdER7H1Q3b5i8duEd-wYpK
    gU8DyLxUj_e9g>
X-ME-Received: <xmr:B5-ZZ5n7NqqsTzdcFFA_-UQAI0iT3f8muIX6dpB0OTSJ7XhQw-tBNGHz4WdPcyvBLe9S1vp_Kcjqye5MbArFZq2onMOyKsiqHw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdduledtucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
    rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
    htshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtjeen
    ucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomh
    grrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggft
    rfgrthhtvghrnhepjeffleekjefhffffvdevgeehkeeitddtieelgeejffevheduheefff
    ekvedtjeevnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpgigvnhdrohhrghenucev
    lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrh
    gvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthho
    peduvddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohephhgvlhhgrggrsheskhgvrh
    hnvghlrdhorhhgpdhrtghpthhtohepsghhvghlghgrrghssehgohhoghhlvgdrtghomhdp
    rhgtphhtthhopehjghhrohhsshesshhushgvrdgtohhmpdhrtghpthhtoheprhhoghgvrh
    drphgruhestghithhrihigrdgtohhmpdhrtghpthhtohepsghorhhishdrohhsthhrohhv
    shhkhiesohhrrggtlhgvrdgtohhmpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhish
    htshdrgigvnhhprhhojhgvtghtrdhorhhgpdhrtghpthhtoheplhhinhhugidqkhgvrhhn
    vghlsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheprhgvghhrvghsshhioh
    hnsheslhhishhtshdrlhhinhhugidruggvvhdprhgtphhtthhopehnsggusehnsggurdhn
    rghmvg
X-ME-Proxy: <xmx:B5-ZZ0wCZMN_56wC7NNkj2GybruKCXcX-Ev0i7B4aGWIWKB5e_0j2Q>
    <xmx:B5-ZZ7QG-U3yF0FanDEGvLVczbmdkqJznYAMvEY0SKS1mMMnhMVj_w>
    <xmx:B5-ZZ_Yu5LVZKUOJVzsyEfEHMsS6yAwquKOvUB07cQ_GHveWA_FGUQ>
    <xmx:B5-ZZ0SUvoUlFcXygdAZmxlLFGMqCpaFaarw2fEcAgt2bl1nWu1dUg>
    <xmx:B5-ZZ6ItCMh6-qcEVMcgt4SJjgrFWDFI_VsRGRnqMJCkmdSMON3vh3NJ>
Feedback-ID: i1568416f:Fastmail
Date: Wed, 29 Jan 2025 04:22:43 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	=?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	linux-kernel@vger.kernel.org, regressions@lists.linux.dev,
	Felix Fietkau <nbd@nbd.name>, Lorenzo Bianconi <lorenzo@kernel.org>,
	Ryder Lee <ryder.lee@mediatek.com>, linux-pci@vger.kernel.org
Subject: Re: Config space access to Mediatek MT7922 doesn't work after device
 reset in Xen PV dom0 (regression, Linux 6.12)
Message-ID: <Z5mfA32bvEn6yD-C@mail-itl>
References: <Z5mOKQUrgeF_r6te@mail-itl>
 <20250129030315.GA392478@bhelgaas>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="Ffsn6E5EvKfIOHmn"
Content-Disposition: inline
In-Reply-To: <20250129030315.GA392478@bhelgaas>


--Ffsn6E5EvKfIOHmn
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Wed, 29 Jan 2025 04:22:43 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	=?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	linux-kernel@vger.kernel.org, regressions@lists.linux.dev,
	Felix Fietkau <nbd@nbd.name>, Lorenzo Bianconi <lorenzo@kernel.org>,
	Ryder Lee <ryder.lee@mediatek.com>, linux-pci@vger.kernel.org
Subject: Re: Config space access to Mediatek MT7922 doesn't work after device
 reset in Xen PV dom0 (regression, Linux 6.12)

On Tue, Jan 28, 2025 at 09:03:15PM -0600, Bjorn Helgaas wrote:
> [+cc linux-pci]
>=20
> On Wed, Jan 29, 2025 at 03:10:49AM +0100, Marek Marczykowski-G=C3=B3recki=
 wrote:
> > On Tue, Jan 28, 2025 at 07:15:26PM -0600, Bjorn Helgaas wrote:
> > > On Fri, Jan 17, 2025 at 01:05:30PM +0100, Marek Marczykowski-G=C3=B3r=
ecki wrote:
> > > > After updating PV dom0 to Linux 6.12, The Mediatek MT7922 device re=
ports
> > > > all 0xff when accessing its config space. This happens only after d=
evice
> > > > reset (which is also triggered when binding the device to the
> > > > xen-pciback driver).
> > >=20
> > > Thanks for the report and for all the debugging you've already done!
> > >=20
> > > > Reproducer:
> > > >=20
> > > >     # lspci -xs 01:00.0
> > > >     01:00.0 Network controller: MEDIATEK Corp. MT7922 802.11ax PCI =
Express Wireless Network Adapter
> > > >     00: c3 14 16 06 00 00 10 00 00 00 80 02 10 00 00 00
> > > >     ...
> > > >     # echo 1 > /sys/bus/pci/devices/0000:01:00.0/reset
> > > >     # lspci -xs 01:00.0
> > > >     01:00.0 Network controller: MEDIATEK Corp. MT7922 802.11ax PCI =
Express Wireless Network Adapter
> > > >     00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > > >
> > > > The same operation done on Linux 6.12 running without Xen works fin=
e.
> > > >=20
> > > > git bisect points at:
> > > >=20
> > > >     commit d591f6804e7e1310881c9224d72247a2b65039af
> > > >     Author: Bjorn Helgaas <bhelgaas@google.com>
> > > >     Date:   Tue Aug 27 18:48:46 2024 -0500
> > > >=20
> > > >     PCI: Wait for device readiness with Configuration RRS
> > > >=20
> > > > part of that commit:
> > > > @@ -1311,9 +1320,15 @@ static int pci_dev_wait(struct pci_dev *dev,=
 char *reset_type, int timeout)
> > > >                         return -ENOTTY;
> > > >                 }
> > > > =20
> > > > -               pci_read_config_dword(dev, PCI_COMMAND, &id);
> > > > -               if (!PCI_POSSIBLE_ERROR(id))
> > > > -                       break;
> > > > +               if (root && root->config_crs_sv) {
> > > > +                       pci_read_config_dword(dev, PCI_VENDOR_ID, &=
id);
> > > > +                       if (!pci_bus_crs_vendor_id(id))
> > > > +                               break;
> > > > +               } else {
> > > > +                       pci_read_config_dword(dev, PCI_COMMAND, &id=
);
> > > > +                       if (!PCI_POSSIBLE_ERROR(id))
> > > > +                               break;
> > > > +               }
> > > > =20
> > > >    =20
> > > > Adding some debugging, the PCI_VENDOR_ID read in pci_dev_wait() ret=
urns
> > > > initially 0xffffffff. If I extend the condition with
> > > > "&& !PCI_POSSIBLE_ERROR(id)", then the issue disappear. But reading=
 the
> > > > patch description, it would break VF.
> > > > I'm not sure where the issue is, but given it breaks only when runn=
ing
> > > > with Xen, I guess something is wrong with "Configuration RRS Softwa=
re
> > > > Visibility" in that case.
> > >=20
> > > I'm missing something.  If you get 0xffffffff, that is not the 0x0001
> > > Vendor ID, so pci_dev_wait() should exit immediately. =20
> >=20
> > I'm not sure what is going on there either, but my _guess_ is that the
> > loop exits too early due to the above. And it makes some further actions
> > to fail.
>=20
> When RRS SV is enabled, reading PCI_VENDOR_ID should always return
> 0x0001 (if the device isn't ready and responds with RRS status) or the
> valid Vendor ID.  I don't think it should ever return 0xffff (unless
> the device is powered off, unplugged, or broken, of course).

Maybe it isn't really enabled when Xen is involved?
By looking at lspci of the bridge for this device, I do see RootCtl: ...
CRSVisible+, but maybe there is something else needed too?

Just in case, full lspci -vvvs 2.2 (the bridge):


00:02.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Phoenix GPP Bridge (=
prog-if 00 [Normal decode])
	Subsystem: Advanced Micro Devices, Inc. [AMD] Device 1453
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Steppi=
ng- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast >TAbort- <TAbort- =
<MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin ? routed to IRQ 102
	Bus: primary=3D00, secondary=3D01, subordinate=3D01, sec-latency=3D0
	I/O behind bridge: 0000f000-00000fff [disabled] [32-bit]
	Memory behind bridge: 90b00000-90bfffff [size=3D1M] [32-bit]
	Prefetchable memory behind bridge: 8010900000-80109fffff [size=3D1M] [32-b=
it]
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=3Dfast >TAbort- <TAbort- =
<MAbort+ <SERR- <PERR-
	BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [50] Power Management version 3
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=3D0mA PME(D0+,D1-,D2-,D3hot+,D3col=
d+)
		Status: D0 NoSoftRst- PME-Enable- DSel=3D0 DScale=3D0 PME-
	Capabilities: [58] Express (v2) Root Port (Slot+), IntMsgNum 0
		DevCap:	MaxPayload 256 bytes, PhantFunc 0
			ExtTag+ RBE+ TEE-IO-
		DevCtl:	CorrErr- NonFatalErr- FatalErr- UnsupReq-
			RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 512 bytes
		DevSta:	CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend-
		LnkCap:	Port #4, Speed 16GT/s, Width x1, ASPM L1, Exit Latency L1 <64us
			ClockPM- Surprise- LLActRep+ BwNot+ ASPMOptComp+
		LnkCtl:	ASPM L1 Enabled; RCB 64 bytes, LnkDisable- CommClk+
			ExtSynch+ ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 5GT/s, Width x1
			TrErr- Train- SlotClk+ DLActive+ BWMgmt- ABWMgmt-
		SltCap:	AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
			Slot #0, PowerLimit 75W; Interlock- NoCompl+
		SltCtl:	Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
			Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
		SltSta:	Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
			Changed: MRL- PresDet- LinkState+
		RootCap: CRSVisible+
		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible+
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
		DevCap2: Completion Timeout: Range ABCD, TimeoutDis+ NROPrPrP- LTR+
			 10BitTagComp+ 10BitTagReq+ OBFF Not Supported, ExtFmt+ EETLPPrefix+, Ma=
xEETLPPrefixes 1
			 EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit-
			 FRS- LN System CLS Not Supported, TPHComp+ ExtTPHComp- ARIFwd+
			 AtomicOpsCap: Routing+ 32bit+ 64bit+ 128bitCAS-
		DevCtl2: Completion Timeout: 65ms to 210ms, TimeoutDis- ARIFwd-
			 AtomicOpsCtl: ReqEn- EgressBlck-
			 IDOReq- IDOCompl- LTR+ EmergencyPowerReductionReq-
			 10BitTagReq- OBFF Disabled, EETLPPrefixBlk-
		LnkCap2: Supported Link Speeds: 2.5-16GT/s, Crosslink- Retimer+ 2Retimers=
+ DRS-
		LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
			 Transmit Margin: Normal Operating Range, EnterModifiedCompliance- Compl=
ianceSOS-
			 Compliance Preset/De-emphasis: -6dB de-emphasis, 0dB preshoot
		LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete- Equaliz=
ationPhase1-
			 EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest-
			 Retimer- 2Retimers- CrosslinkRes: unsupported
	Capabilities: [a0] MSI: Enable+ Count=3D1/1 Maskable- 64bit+
		Address: 00000000fee08000  Data: 4000
	Capabilities: [c0] Subsystem: Advanced Micro Devices, Inc. [AMD] Device 14=
53
	Capabilities: [c8] HyperTransport: MSI Mapping Enable+ Fixed+
	Capabilities: [100 v1] Vendor Specific Information: ID=3D0001 Rev=3D1 Len=
=3D010 <?>
	Capabilities: [270 v1] Secondary PCI Express
		LnkCtl3: LnkEquIntrruptEn- PerformEqu-
		LaneErrStat: 0
	Capabilities: [2a0 v1] Access Control Services
		ACSCap:	SrcValid+ TransBlk+ ReqRedir+ CmpltRedir+ UpstreamFwd+ EgressCtrl=
- DirectTrans+
		ACSCtl:	SrcValid+ TransBlk- ReqRedir+ CmpltRedir+ UpstreamFwd+ EgressCtrl=
- DirectTrans-
	Capabilities: [370 v1] L1 PM Substates
		L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+
			  PortCommonModeRestoreTime=3D10us PortTPowerOnTime=3D150us
		L1SubCtl1: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+
			   T_CommonMode=3D10us LTR1.2_Threshold=3D166912ns
		L1SubCtl2: T_PwrOn=3D150us
	Capabilities: [400 v1] Data Link Feature <?>
	Capabilities: [410 v1] Physical Layer 16.0 GT/s <?>
	Capabilities: [440 v1] Lane Margining at the Receiver
		PortCap: Uses Driver-
		PortSta: MargReady- MargSoftReady-
	Kernel driver in use: pcieport

>=20
> > > But the log at
> > > https://github.com/QubesOS/qubes-issues/issues/9689#issuecomment-2582=
927149
> > > says it *doesn't* exit and eventually times out.
> >=20
> > Note this log is from "working" kernel, so that timeout must be
> > something else.
>=20
> I saw it was labeled "NO BUG" but I'm not sure it's labeled correctly
> since there are no interesting messages from the "BUG PRESENT" part.
> Awfully funny coincidence if it's unrelated.

The timeout thing I have seen before, possibly also on a different
hardware (although I'm not 100% sure), I think it's a different issue.

> > > And the lspci above shows ~0 data for much of the header, even though
> > > the device must be ready by then.
> > >=20
> > > I don't have any good ideas, but since the problem only happens with
> > > Xen, and it seems to affect more than just the Vendor ID, maybe you
> > > could instrument xen_pcibk_config_read() and see if there's something
> > > wonky going on there?
> >=20
> > This one is used when pcifront (from a different PV VM) is asking pciba=
ck
> > to read something. I see the issue even before starting any other VM and
> > not even attaching the device to the xen-pciback driver...
>=20
> The report claims the problem only happens with Xen.  I'm not a Xen
> person, and I don't know how to find the relevant config accessors.
> The snippets of kernel messages I see at [1] all mention pciback, so
> that's my only clue of where to look.  Bottom line, I have no idea
> what the config accessor path is, and maybe we could learn something
> by looking at whatever it is.

AFAIK there are no separate config accessors under Xen dom0, the default
ones are used. xen-pcifront takes over PCI config space access (and few
more) only in a domU (and only for PV), when PCI passthrough is used.
Here, it didn't went that far...

But then, Xen may intercept such access [2]. If I read it right, it
should allow all access (is_hardware_domain(dom0)=3D=3Dtrue, and also the
device is not on ro_map - otherwise reset wouldn't work at all).


>=20
> [1] https://github.com/QubesOS/qubes-issues/issues/9689#issuecomment-2582=
927149

[2] https://xenbits.xen.org/gitweb/?p=3Dxen.git;a=3Dblob;f=3Dxen/arch/x86/p=
v/emul-priv-op.c;h=3D70150c27227661baa253af8693ff00f2ab640a98;hb=3DHEAD#l295

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

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

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmeZnwMACgkQ24/THMrX
1yyR7Af+KIY4PA0PjnpQt79utqv7p+f3M9SfesSkZTufAXPuwmhGuJtB58kwYfuu
YUM1w3BqfkhSKpyaFyKHtDPjvZEcFzX25swvrcYe+wMM5kdqJBp/WXWR0cROxdan
Qws8s/JUvQFd5byOtfV+rggzfNVGE/cwwTAP49MwyQe8JFoFwUN/srj94rU8Oqm+
Z8IYGmVYlEV5zvcFMZ+Gmxgy6U3SVpkivxMxUIClGwCEAAjqmCNoK9ZAfVN0fgOZ
0aruISde8KcTjNpH4bUjN1EZGyqobDwlp3N8cEAcg/ULYWGYNQ8cZpLeX/1ldoTW
Hbz0lXlbgV3Y4uege+mBuOSk4DYLmA==
=oexv
-----END PGP SIGNATURE-----

--Ffsn6E5EvKfIOHmn--


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 03:40:32 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 03:40:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878880.1289074 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcywE-0006YG-OP; Wed, 29 Jan 2025 03:40:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878880.1289074; Wed, 29 Jan 2025 03:40:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcywE-0006Y9-Lr; Wed, 29 Jan 2025 03:40:26 +0000
Received: by outflank-mailman (input) for mailman id 878880;
 Wed, 29 Jan 2025 03:40:25 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=CGF7=UV=kernel.org=helgaas@srs-se1.protection.inumbo.net>)
 id 1tcywD-0006Y3-AO
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 03:40:25 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c4531f58-ddf2-11ef-99a4-01e77a169b0f;
 Wed, 29 Jan 2025 04:40:22 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id D4A1A5C4859;
 Wed, 29 Jan 2025 03:39:40 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 63ACCC4CED3;
 Wed, 29 Jan 2025 03:40:20 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c4531f58-ddf2-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1738122020;
	bh=5d8804j0o3ySdiylmnNX/pA/dOJhQjobKfs3r6Bxw70=;
	h=Date:From:To:Cc:Subject:In-Reply-To:From;
	b=OrOacMf4/D6xxSdp0G5CnRa90uhokTFLhS9ygSLwGXD+so8gzamRTrZa0NpAIQkZ3
	 Gx02dJC3EAGg2kDNs3kyY7wCL+wZSiLFsmnBZdbh5yUOxgLFbDjz+vzX4I3l8IdQCz
	 nn1Qw3Jq/S1tu9X8GOJ3llfYeG4EnM3feFU5vM+oURdOznIyBVZfmAyUZ+koOD0HeR
	 XMJ7eAHNM3N4AHL0ai52U4To2ZjkXFJh5WM/2gY6YQFkv5aRJmlCpFhbkG0s1OAeUK
	 +rZvmLT4mq+tsGUsyVTPRr0rchFe1GJX/JXPJt3LCjjJ1KxlXCKxg+IoF2e2yOBgdg
	 5lEG0GwFE0lUQ==
Date: Tue, 28 Jan 2025 21:40:18 -0600
From: Bjorn Helgaas <helgaas@kernel.org>
To: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	=?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	linux-kernel@vger.kernel.org, regressions@lists.linux.dev,
	Felix Fietkau <nbd@nbd.name>, Lorenzo Bianconi <lorenzo@kernel.org>,
	Ryder Lee <ryder.lee@mediatek.com>, linux-pci@vger.kernel.org
Subject: Re: Config space access to Mediatek MT7922 doesn't work after device
 reset in Xen PV dom0 (regression, Linux 6.12)
Message-ID: <20250129034018.GA398969@bhelgaas>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <Z5mfA32bvEn6yD-C@mail-itl>

On Wed, Jan 29, 2025 at 04:22:43AM +0100, Marek Marczykowski-Górecki wrote:
> On Tue, Jan 28, 2025 at 09:03:15PM -0600, Bjorn Helgaas wrote:
> > On Wed, Jan 29, 2025 at 03:10:49AM +0100, Marek Marczykowski-Górecki wrote:
> > > On Tue, Jan 28, 2025 at 07:15:26PM -0600, Bjorn Helgaas wrote:
> > > > On Fri, Jan 17, 2025 at 01:05:30PM +0100, Marek Marczykowski-Górecki wrote:
> > > > > After updating PV dom0 to Linux 6.12, The Mediatek MT7922 device reports
> > > > > all 0xff when accessing its config space. This happens only after device
> > > > > reset (which is also triggered when binding the device to the
> > > > > xen-pciback driver).
> > > > 
> > > > Thanks for the report and for all the debugging you've already done!
> > > > 
> > > > > Reproducer:
> > > > > 
> > > > >     # lspci -xs 01:00.0
> > > > >     01:00.0 Network controller: MEDIATEK Corp. MT7922 802.11ax PCI Express Wireless Network Adapter
> > > > >     00: c3 14 16 06 00 00 10 00 00 00 80 02 10 00 00 00
> > > > >     ...
> > > > >     # echo 1 > /sys/bus/pci/devices/0000:01:00.0/reset
> > > > >     # lspci -xs 01:00.0
> > > > >     01:00.0 Network controller: MEDIATEK Corp. MT7922 802.11ax PCI Express Wireless Network Adapter
> > > > >     00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > > > >
> > > > > The same operation done on Linux 6.12 running without Xen works fine.
> > > > > 
> > > > > git bisect points at:
> > > > > 
> > > > >     commit d591f6804e7e1310881c9224d72247a2b65039af
> > > > >     Author: Bjorn Helgaas <bhelgaas@google.com>
> > > > >     Date:   Tue Aug 27 18:48:46 2024 -0500
> > > > > 
> > > > >     PCI: Wait for device readiness with Configuration RRS
> > > > > 
> > > > > part of that commit:
> > > > > @@ -1311,9 +1320,15 @@ static int pci_dev_wait(struct pci_dev *dev, char *reset_type, int timeout)
> > > > >                         return -ENOTTY;
> > > > >                 }
> > > > >  
> > > > > -               pci_read_config_dword(dev, PCI_COMMAND, &id);
> > > > > -               if (!PCI_POSSIBLE_ERROR(id))
> > > > > -                       break;
> > > > > +               if (root && root->config_crs_sv) {
> > > > > +                       pci_read_config_dword(dev, PCI_VENDOR_ID, &id);
> > > > > +                       if (!pci_bus_crs_vendor_id(id))
> > > > > +                               break;
> > > > > +               } else {
> > > > > +                       pci_read_config_dword(dev, PCI_COMMAND, &id);
> > > > > +                       if (!PCI_POSSIBLE_ERROR(id))
> > > > > +                               break;
> > > > > +               }
> > > > >  
> > > > >     
> > > > > Adding some debugging, the PCI_VENDOR_ID read in pci_dev_wait() returns
> > > > > initially 0xffffffff. If I extend the condition with
> > > > > "&& !PCI_POSSIBLE_ERROR(id)", then the issue disappear. But reading the
> > > > > patch description, it would break VF.
> > > > > I'm not sure where the issue is, but given it breaks only when running
> > > > > with Xen, I guess something is wrong with "Configuration RRS Software
> > > > > Visibility" in that case.
> > > > 
> > > > I'm missing something.  If you get 0xffffffff, that is not the 0x0001
> > > > Vendor ID, so pci_dev_wait() should exit immediately.  
> > > 
> > > I'm not sure what is going on there either, but my _guess_ is that the
> > > loop exits too early due to the above. And it makes some further actions
> > > to fail.
> > 
> > When RRS SV is enabled, reading PCI_VENDOR_ID should always return
> > 0x0001 (if the device isn't ready and responds with RRS status) or the
> > valid Vendor ID.  I don't think it should ever return 0xffff (unless
> > the device is powered off, unplugged, or broken, of course).
> 
> Maybe it isn't really enabled when Xen is involved?
> By looking at lspci of the bridge for this device, I do see RootCtl: ...
> CRSVisible+, but maybe there is something else needed too?

As far as I know, CRSVisible+ is all that's needed to enable this, and
Linux always enables it if it's supported [3]

> Just in case, full lspci -vvvs 2.2 (the bridge):
> 
> 
> 00:02.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Phoenix GPP Bridge (prog-if 00 [Normal decode])
> 	Subsystem: Advanced Micro Devices, Inc. [AMD] Device 1453
> 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
> 	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> 	Latency: 0, Cache Line Size: 64 bytes
> 	Interrupt: pin ? routed to IRQ 102
> 	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
> 	I/O behind bridge: 0000f000-00000fff [disabled] [32-bit]
> 	Memory behind bridge: 90b00000-90bfffff [size=1M] [32-bit]
> 	Prefetchable memory behind bridge: 8010900000-80109fffff [size=1M] [32-bit]
> 	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
> 	BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16- MAbort- >Reset- FastB2B-
> 		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
> 	Capabilities: [50] Power Management version 3
> 		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
> 		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
> 	Capabilities: [58] Express (v2) Root Port (Slot+), IntMsgNum 0
> 		DevCap:	MaxPayload 256 bytes, PhantFunc 0
> 			ExtTag+ RBE+ TEE-IO-
> 		DevCtl:	CorrErr- NonFatalErr- FatalErr- UnsupReq-
> 			RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+
> 			MaxPayload 128 bytes, MaxReadReq 512 bytes
> 		DevSta:	CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend-
> 		LnkCap:	Port #4, Speed 16GT/s, Width x1, ASPM L1, Exit Latency L1 <64us
> 			ClockPM- Surprise- LLActRep+ BwNot+ ASPMOptComp+
> 		LnkCtl:	ASPM L1 Enabled; RCB 64 bytes, LnkDisable- CommClk+
> 			ExtSynch+ ClockPM- AutWidDis- BWInt- AutBWInt-
> 		LnkSta:	Speed 5GT/s, Width x1
> 			TrErr- Train- SlotClk+ DLActive+ BWMgmt- ABWMgmt-
> 		SltCap:	AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
> 			Slot #0, PowerLimit 75W; Interlock- NoCompl+
> 		SltCtl:	Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
> 			Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
> 		SltSta:	Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
> 			Changed: MRL- PresDet- LinkState+
> 		RootCap: CRSVisible+
> 		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible+
> 		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
> 		DevCap2: Completion Timeout: Range ABCD, TimeoutDis+ NROPrPrP- LTR+
> 			 10BitTagComp+ 10BitTagReq+ OBFF Not Supported, ExtFmt+ EETLPPrefix+, MaxEETLPPrefixes 1
> 			 EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit-
> 			 FRS- LN System CLS Not Supported, TPHComp+ ExtTPHComp- ARIFwd+
> 			 AtomicOpsCap: Routing+ 32bit+ 64bit+ 128bitCAS-
> 		DevCtl2: Completion Timeout: 65ms to 210ms, TimeoutDis- ARIFwd-
> 			 AtomicOpsCtl: ReqEn- EgressBlck-
> 			 IDOReq- IDOCompl- LTR+ EmergencyPowerReductionReq-
> 			 10BitTagReq- OBFF Disabled, EETLPPrefixBlk-
> 		LnkCap2: Supported Link Speeds: 2.5-16GT/s, Crosslink- Retimer+ 2Retimers+ DRS-
> 		LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
> 			 Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
> 			 Compliance Preset/De-emphasis: -6dB de-emphasis, 0dB preshoot
> 		LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete- EqualizationPhase1-
> 			 EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest-
> 			 Retimer- 2Retimers- CrosslinkRes: unsupported
> 	Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
> 		Address: 00000000fee08000  Data: 4000
> 	Capabilities: [c0] Subsystem: Advanced Micro Devices, Inc. [AMD] Device 1453
> 	Capabilities: [c8] HyperTransport: MSI Mapping Enable+ Fixed+
> 	Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
> 	Capabilities: [270 v1] Secondary PCI Express
> 		LnkCtl3: LnkEquIntrruptEn- PerformEqu-
> 		LaneErrStat: 0
> 	Capabilities: [2a0 v1] Access Control Services
> 		ACSCap:	SrcValid+ TransBlk+ ReqRedir+ CmpltRedir+ UpstreamFwd+ EgressCtrl- DirectTrans+
> 		ACSCtl:	SrcValid+ TransBlk- ReqRedir+ CmpltRedir+ UpstreamFwd+ EgressCtrl- DirectTrans-
> 	Capabilities: [370 v1] L1 PM Substates
> 		L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+
> 			  PortCommonModeRestoreTime=10us PortTPowerOnTime=150us
> 		L1SubCtl1: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+
> 			   T_CommonMode=10us LTR1.2_Threshold=166912ns
> 		L1SubCtl2: T_PwrOn=150us
> 	Capabilities: [400 v1] Data Link Feature <?>
> 	Capabilities: [410 v1] Physical Layer 16.0 GT/s <?>
> 	Capabilities: [440 v1] Lane Margining at the Receiver
> 		PortCap: Uses Driver-
> 		PortSta: MargReady- MargSoftReady-
> 	Kernel driver in use: pcieport
> 
> > > > But the log at
> > > > https://github.com/QubesOS/qubes-issues/issues/9689#issuecomment-2582927149
> > > > says it *doesn't* exit and eventually times out.
> > > 
> > > Note this log is from "working" kernel, so that timeout must be
> > > something else.
> > 
> > I saw it was labeled "NO BUG" but I'm not sure it's labeled correctly
> > since there are no interesting messages from the "BUG PRESENT" part.
> > Awfully funny coincidence if it's unrelated.
> 
> The timeout thing I have seen before, possibly also on a different
> hardware (although I'm not 100% sure), I think it's a different issue.
> 
> > > > And the lspci above shows ~0 data for much of the header, even though
> > > > the device must be ready by then.
> > > > 
> > > > I don't have any good ideas, but since the problem only happens with
> > > > Xen, and it seems to affect more than just the Vendor ID, maybe you
> > > > could instrument xen_pcibk_config_read() and see if there's something
> > > > wonky going on there?
> > > 
> > > This one is used when pcifront (from a different PV VM) is asking pciback
> > > to read something. I see the issue even before starting any other VM and
> > > not even attaching the device to the xen-pciback driver...
> > 
> > The report claims the problem only happens with Xen.  I'm not a Xen
> > person, and I don't know how to find the relevant config accessors.
> > The snippets of kernel messages I see at [1] all mention pciback, so
> > that's my only clue of where to look.  Bottom line, I have no idea
> > what the config accessor path is, and maybe we could learn something
> > by looking at whatever it is.
> 
> AFAIK there are no separate config accessors under Xen dom0, the default
> ones are used. xen-pcifront takes over PCI config space access (and few
> more) only in a domU (and only for PV), when PCI passthrough is used.
> Here, it didn't went that far...
> 
> But then, Xen may intercept such access [2]. If I read it right, it
> should allow all access (is_hardware_domain(dom0)==true, and also the
> device is not on ro_map - otherwise reset wouldn't work at all).

I guess the code at [2] is running in user mode and uses Linux
syscalls for config access?  Is it straceable?

Can you reproduce this without Xen at all?  If so, can you post a
complete dmesg and complete lspci -vv somewhere?

> > [1] https://github.com/QubesOS/qubes-issues/issues/9689#issuecomment-2582927149
> 
> [2] https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/pv/emul-priv-op.c;h=70150c27227661baa253af8693ff00f2ab640a98;hb=HEAD#l295

[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/probe.c?id=v6.13#n1208


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 03:47:44 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 03:47:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878889.1289084 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcz3C-0007I0-Fd; Wed, 29 Jan 2025 03:47:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878889.1289084; Wed, 29 Jan 2025 03:47:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tcz3C-0007Ht-D7; Wed, 29 Jan 2025 03:47:38 +0000
Received: by outflank-mailman (input) for mailman id 878889;
 Wed, 29 Jan 2025 03:47: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
 <SRS0=ri1h=UV=invisiblethingslab.com=marmarek@srs-se1.protection.inumbo.net>)
 id 1tcz3A-0007Hn-Py
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 03:47:36 +0000
Received: from fout-a5-smtp.messagingengine.com
 (fout-a5-smtp.messagingengine.com [103.168.172.148])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c5ca9ce7-ddf3-11ef-99a4-01e77a169b0f;
 Wed, 29 Jan 2025 04:47:34 +0100 (CET)
Received: from phl-compute-08.internal (phl-compute-08.phl.internal
 [10.202.2.48])
 by mailfout.phl.internal (Postfix) with ESMTP id 42D0713810B0;
 Tue, 28 Jan 2025 22:47:33 -0500 (EST)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-08.internal (MEProxy); Tue, 28 Jan 2025 22:47:33 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 28 Jan 2025 22:47:30 -0500 (EST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c5ca9ce7-ddf3-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm3; t=1738122453;
	 x=1738208853; bh=o/1Pq66neLKeF3uzOf3AklSlktzoEb7gsLHB0A1fQMc=; b=
	NONUYCTT3uKA5H2Dy+HXhrloi+CdBqOUY4ukgbmSpaQ0OfU/14Wdx/FuxOc24wPl
	6yscww1n2JwGz4Cy/hJ8bD06HacU75RfKY4nWswSGZ+LgQ4k4pU/H5yGbb4aIZuI
	gk08bFpstHGW4gDDFyO0okI/Aw/4BsLIxL8O1wBEUp8DCdg7CZ67EHxALiR6ZgeB
	QmKG/eT0+IX+csth6TnAJvJAzXBTDfYtTiZfS1g5dqtOO9Hy/N0bDS3HN1aNAXXy
	O8u2TKVo5Y13EeB1EZDUTfkR0gWg+YteQVMOTWBfmwtIRRQAFy3VBQzLTbjMY6qZ
	24CRQbsDVh8V42JZQhi4GQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:subject:subject:to
	:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=
	1738122453; x=1738208853; bh=o/1Pq66neLKeF3uzOf3AklSlktzoEb7gsLH
	B0A1fQMc=; b=TM4pHChTAekVyb75Y9zF2M4yGbrVgX19HcjTRtwgZ7wW3RXudb+
	Qfpi8XB4or0NN8+p8Zj4OMTyEqO8BUYyRZiNXQskN4sg2GuKwt0ujgIEFzn49uXU
	g1HLQ7YBdcqA4F0VatOTv56fbv52XaciRcrJFTiu+XQ5JktUyZunf7+rQw+Lkx0C
	9S4urxLmUkBDwLiRT/VVchGdQdUDmMF3hp+3Y4FlIe5w80hT303OiXL40NWsFGYG
	DZ8g4pKCCWR9Zvj7Z4H7h0u2OlHxC8O+rFYEZ0jPZpZYVnItr2G8H8hHbb8ZfQXa
	z8TecXg/hw0C5TZvXxGQljtjM621D+ox94g==
X-ME-Sender: <xms:1KSZZ13ZfgNkun5W8b0ONvIUFymvnsahaUwx4glxJ2OPdbD0EO_tFg>
    <xme:1KSZZ8E2_sONjGRDobSD_NxvDFczQn1qPfFtXGOM_jN8wD-PSNA6Ct7LqkDPg3mNg
    Ku15XST0my7Qw>
X-ME-Received: <xmr:1KSZZ14Ou6evhyt-4rWHBegMBpedxfwmb6ykxv5G46BgAd7loHUsLj-WrvOmpVeyWci-l8zi4MevsQhjymWxtrktKunzbq5Ajg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdduleehucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
    rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
    htshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtjeen
    ucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomh
    grrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggft
    rfgrthhtvghrnhepvedthedtheekhfeiudelfffgheegfedttdeiudevudejfeelgeekhf
    dvfedvvddunecuffhomhgrihhnpehgihhthhhusgdrtghomhdpgigvnhdrohhrghdpkhgv
    rhhnvghlrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh
    hfrhhomhepmhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtgho
    mhdpnhgspghrtghpthhtohepuddvpdhmohguvgepshhmthhpohhuthdprhgtphhtthhope
    hhvghlghgrrghssehkvghrnhgvlhdrohhrghdprhgtphhtthhopegshhgvlhhgrggrshes
    ghhoohhglhgvrdgtohhmpdhrtghpthhtohepjhhgrhhoshhssehsuhhsvgdrtghomhdprh
    gtphhtthhopehrohhgvghrrdhprghusegtihhtrhhigidrtghomhdprhgtphhtthhopegs
    ohhrihhsrdhoshhtrhhovhhskhihsehorhgrtghlvgdrtghomhdprhgtphhtthhopeigvg
    hnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdprhgtphhtthho
    pehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtth
    hopehrvghgrhgvshhsihhonhhssehlihhsthhsrdhlihhnuhigrdguvghvpdhrtghpthht
    ohepnhgsugesnhgsugdrnhgrmhgv
X-ME-Proxy: <xmx:1KSZZy3-GIEB8tFjmJxoGuB_Zyoh3IqiGxIPQB5_fs4PiU0ggnBnbg>
    <xmx:1KSZZ4FrwP-qMVaOMGwp3Tck6D-MWkOrTKO5BRCKH-NTdHIQk_r3NQ>
    <xmx:1KSZZz9IVj_Gfzl0usFjFH3GRbCZMhKyBmMLqAL31NOqn1vKKDVvDQ>
    <xmx:1KSZZ1nuVis6_sETM3Anf092AdCvJYU3cwdr9r98xGCQzC9a2tUTYA>
    <xmx:1aSZZ_c277VQrGGvpBzr7TdTQFiyvNw4in-oJDuQR1mZ-N5TxHISn-Id>
Feedback-ID: i1568416f:Fastmail
Date: Wed, 29 Jan 2025 04:47:28 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	=?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	linux-kernel@vger.kernel.org, regressions@lists.linux.dev,
	Felix Fietkau <nbd@nbd.name>, Lorenzo Bianconi <lorenzo@kernel.org>,
	Ryder Lee <ryder.lee@mediatek.com>, linux-pci@vger.kernel.org
Subject: Re: Config space access to Mediatek MT7922 doesn't work after device
 reset in Xen PV dom0 (regression, Linux 6.12)
Message-ID: <Z5mk0K5xltK6iZXN@mail-itl>
References: <Z5mfA32bvEn6yD-C@mail-itl>
 <20250129034018.GA398969@bhelgaas>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="7HtAp5iYbaAmPKI3"
Content-Disposition: inline
In-Reply-To: <20250129034018.GA398969@bhelgaas>


--7HtAp5iYbaAmPKI3
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Wed, 29 Jan 2025 04:47:28 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	=?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	linux-kernel@vger.kernel.org, regressions@lists.linux.dev,
	Felix Fietkau <nbd@nbd.name>, Lorenzo Bianconi <lorenzo@kernel.org>,
	Ryder Lee <ryder.lee@mediatek.com>, linux-pci@vger.kernel.org
Subject: Re: Config space access to Mediatek MT7922 doesn't work after device
 reset in Xen PV dom0 (regression, Linux 6.12)

On Tue, Jan 28, 2025 at 09:40:18PM -0600, Bjorn Helgaas wrote:
> I guess the code at [2] is running in user mode and uses Linux
> syscalls for config access?  Is it straceable?

Nope, it's running as the hypervisor and mediates Linux's access to the
hardware. In fact, Linux PV kernel (which dom0 is by default under Xen)
is running in ring 3...

But I can add some more logging there.

> Can you reproduce this without Xen at all?  If so, can you post a
> complete dmesg and complete lspci -vv somewhere?

I haven't managed to reproduce it without Xen so far. But I can't
exclude it's some race condition that is simply unlikely to hit when
Linux runs natively.=20

> > > [1] https://github.com/QubesOS/qubes-issues/issues/9689#issuecomment-=
2582927149
> >=20
> > [2] https://xenbits.xen.org/gitweb/?p=3Dxen.git;a=3Dblob;f=3Dxen/arch/x=
86/pv/emul-priv-op.c;h=3D70150c27227661baa253af8693ff00f2ab640a98;hb=3DHEAD=
#l295
>=20
> [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tr=
ee/drivers/pci/probe.c?id=3Dv6.13#n1208

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

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

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmeZpNAACgkQ24/THMrX
1yyzZgf+NFIFR+LpsTBUlwEyR+b9DhblSPdvomnx7u3lNOlRGrdkrFsdqTkMnOE/
mAgHDjmiK5Dfz+8IiAtKNjvz78klTW2+VCwHAwZi7vu1x9YgJL5Yn6hejG3JOgEQ
knJaEarUmzkdmYZrrseSV5n+/SGKRflXKm0VG8M0dDCm8c//GieJIhc5q9TJdAlh
efkH3E54iieRcvlae6NmmKZUZmhUnsHJxmUgurjgoL8BWN1rqZgaP4tIzFPDyV2g
nGu3aK2D4oFu6aQTclHqkoPqUWw29ywLOnXNH4Uf9rBeTw17vsxSJAWy8JEtmA+X
UPDcdOmnHXWyeUqQCweCD6Q9u6OFLQ==
=FIrq
-----END PGP SIGNATURE-----

--7HtAp5iYbaAmPKI3--


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 04:55:38 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 04:55:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878897.1289094 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td06p-00087A-Ac; Wed, 29 Jan 2025 04:55:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878897.1289094; Wed, 29 Jan 2025 04:55:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td06p-000873-7x; Wed, 29 Jan 2025 04:55:27 +0000
Received: by outflank-mailman (input) for mailman id 878897;
 Wed, 29 Jan 2025 04:55: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
 <SRS0=Hvc5=UV=daynix.com=akihiko.odaki@srs-se1.protection.inumbo.net>)
 id 1td06n-00086x-J0
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 04:55:25 +0000
Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com
 [2607:f8b0:4864:20::633])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3efa7006-ddfd-11ef-a0e6-8be0dac302b0;
 Wed, 29 Jan 2025 05:55:23 +0100 (CET)
Received: by mail-pl1-x633.google.com with SMTP id
 d9443c01a7336-2156e078563so90949225ad.2
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 20:55:23 -0800 (PST)
Received: from [157.82.205.237] ([157.82.205.237])
 by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-72f8a7609b5sm10625337b3a.107.2025.01.28.20.55.18
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 28 Jan 2025 20:55:21 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 3efa7006-ddfd-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=daynix-com.20230601.gappssmtp.com; s=20230601; t=1738126522; x=1738731322; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=/IFeUQjMu1pqweZZ2zI+5/tYS9SLCsGUkfUbrwEx0iA=;
        b=FKkyqpU8RqzC7la9XWaAtylMIGivplUQdlARD/H7Hg/sWmCmmzKf7FN1RNmHUROX5Z
         dICEns/2gdRKzqyQTnaEiwtkIaP6R1/e9rRme1Db01sdBqn7/vzqV97U4Ll30VaKtzw7
         g4ne/XwVcVBf9B/23Bq3ryppbGG15BZiYiQW5VBbgzMBG4XHzdtZbf2y3BfBxHd4P3El
         rYrDW4ZCRXs5JVew7rwQJQTv2tZ8EPCXDuAv4TOtjYFmTCf0QwM2O6PpYc/Wp4InjgNo
         NxW9hyeoDwsoaRBxuOxNU/MgwYLtAf7fVk8XPb4pr/nkFhHxsTiaFZmgtV24CU4zwOpA
         xMoA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738126522; x=1738731322;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=/IFeUQjMu1pqweZZ2zI+5/tYS9SLCsGUkfUbrwEx0iA=;
        b=RFAgq7zTG+9V775dFNPEepLBDtQbiRCd2rj9/+ESpPtxLaF/2F/tS+6UVTd4TW8AdR
         CwY5SYFuVDGY6jEwDkBZqutkDL81KKECbW+iNuzNiDFTRE3M+yYLqc9EG1JNKMJ1chPf
         zr1TgBZtaDGqmp0DQ5KKP+dCll/BkDNNcvQKn51Avt1P4BQGvInyWTz29vPfIVqhP8tP
         m/Ook0IrevwWVBNO++rWAroe9BDMGkt4oJqJDuOtRThMC9nYILsW6YSEnY8wG1tYys+2
         y8++m303O7oXcM5DxMgDNecFza0mt9KelDg/h+UaKdJo5DhJN0K7O9v7BveZGxlXWz4T
         gqmQ==
X-Gm-Message-State: AOJu0Yx5n9ESHFhcnchh4zFBti8ybykdZwPkCfYduOW7PqqG48Tsc3P8
	y97sTHlbIP0iFB2XT5nE2eDtj791HZ7/lYdvu+KFPbi/uiWocqASiYhgcjP93wg=
X-Gm-Gg: ASbGncsmOLscx+zn/aJj2lTugBkirt1GtS1t97zgEd6DTaujjkdaFzxCLfVF2fHs/+n
	lN8U1IcgY1A+4tksmKb9+lFP/UPR1hXy9+XUZLpaJ/qAKqUINfntC0P3nCZGACNLuX/HWynH7wY
	Zcoibrbk5zbfxtTc3k30eZeLykfpMrQl76Gn7ixZzByazYhMN8z0C0OyOJRf5dnS+BTXi/Pk/eH
	elTENUmMH08YWq6jMZ6BH9N3UMJndI01hOx4BXoo9lVOAcxRGEvDovuHxCArWX9s3h52m81fkCD
	ViH/WmfVp4tJCQfPzUTHH+m1gAGE
X-Google-Smtp-Source: AGHT+IE/ZkJCXSSPk6z1jArpZ1Lcz87un7Bm147NNNCD173L++5cdH5qki30oCucXAEB8021oAu+eQ==
X-Received: by 2002:a05:6a20:12d6:b0:1e1:ab51:f53e with SMTP id adf61e73a8af0-1ed7a5b66e1mr3007763637.5.1738126521875;
        Tue, 28 Jan 2025 20:55:21 -0800 (PST)
Message-ID: <ddbacd27-d978-409b-be12-060f27cea9d6@daynix.com>
Date: Wed, 29 Jan 2025 13:55:17 +0900
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/2] tests/qtest: Make qtest_has_accel() generic
To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= <philmd@linaro.org>,
 qemu-devel@nongnu.org
Cc: xen-devel@lists.xenproject.org, =?UTF-8?Q?Daniel_P_=2E_Berrang=C3=A9?=
 <berrange@redhat.com>, Fabiano Rosas <farosas@suse.de>,
 Markus Armbruster <armbru@redhat.com>, Thomas Huth <thuth@redhat.com>,
 Laurent Vivier <lvivier@redhat.com>, Phil Dennis-Jordan
 <phil@philjordan.eu>, Bernhard Beschow <shentey@gmail.com>,
 Paolo Bonzini <pbonzini@redhat.com>
References: <20250128111821.93767-1-philmd@linaro.org>
 <20250128111821.93767-3-philmd@linaro.org>
Content-Language: en-US
From: Akihiko Odaki <akihiko.odaki@daynix.com>
In-Reply-To: <20250128111821.93767-3-philmd@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 2025/01/28 20:18, Philippe Mathieu-Daudé wrote:
> Since commit b14a0b7469f ("accel: Use QOM classes for accel types")
> accelerators are registered as QOM objects. Use QOM as a generic
> API to query for available accelerators. This is in particular
> useful to query hardware accelerators such HFV, Xen or WHPX which
> otherwise have their definitions poisoned in "exec/poison.h".
> 
> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> ---
>   tests/qtest/libqtest.c | 21 ++++++++++-----------
>   1 file changed, 10 insertions(+), 11 deletions(-)
> 
> diff --git a/tests/qtest/libqtest.c b/tests/qtest/libqtest.c
> index 7e9366ad6d5..3071dedeff6 100644
> --- a/tests/qtest/libqtest.c
> +++ b/tests/qtest/libqtest.c
> @@ -30,6 +30,7 @@
>   
>   #include "libqtest.h"
>   #include "libqmp.h"
> +#include "qemu/accel.h"
>   #include "qemu/ctype.h"
>   #include "qemu/cutils.h"
>   #include "qemu/sockets.h"
> @@ -1030,13 +1031,10 @@ static bool qtest_qom_has_concrete_type(const char *parent_typename,
>   
>   bool qtest_has_accel(const char *accel_name)
>   {
> -    if (g_str_equal(accel_name, "tcg")) {
> -#if defined(CONFIG_TCG)
> -        return true;
> -#else
> -        return false;
> -#endif
> -    } else if (g_str_equal(accel_name, "kvm")) {
> +    static QList *list;
> +    g_autofree char *accel_type = NULL;
> +
> +    if (g_str_equal(accel_name, "kvm")) {
>           int i;
>           const char *arch = qtest_get_arch();
>           const char *targets[] = { CONFIG_KVM_TARGETS };
> @@ -1048,11 +1046,12 @@ bool qtest_has_accel(const char *accel_name)
>                   }
>               }
>           }
> -    } else {
> -        /* not implemented */
> -        g_assert_not_reached();
> +        return false;
>       }
> -    return false;
> +
> +    accel_type = g_strdup_printf("%s%s", accel_name, ACCEL_CLASS_SUFFIX);

g_strconcat() will make this a bit shorter.

> +
> +    return qtest_qom_has_concrete_type("accel", accel_type, &list);
>   }
>   
>   bool qtest_get_irq(QTestState *s, int num)



From xen-devel-bounces@lists.xenproject.org Wed Jan 29 07:53:31 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 07:53:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878908.1289114 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td2sw-0004TK-GC; Wed, 29 Jan 2025 07:53:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878908.1289114; Wed, 29 Jan 2025 07:53:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td2sw-0004TD-Bp; Wed, 29 Jan 2025 07:53:18 +0000
Received: by outflank-mailman (input) for mailman id 878908;
 Wed, 29 Jan 2025 07:53:17 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=1peA=UV=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1td2sv-0004T7-GB
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 07:53:17 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1873f577-de16-11ef-a0e6-8be0dac302b0;
 Wed, 29 Jan 2025 08:53:15 +0100 (CET)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-5d0d32cd31aso9325732a12.0
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 23:53:15 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab6760ab171sm928129766b.107.2025.01.28.23.53.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 28 Jan 2025 23:53:14 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1873f577-de16-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738137195; x=1738741995; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=mcgoQ4RQ/+msiATfSS3LRvmHZ1tq/ucOrokkG5BuK4c=;
        b=W0GJg/8i22SViP5VHhWme4DHiP6ckCEc1W9hzm28fBveH7AautTYUcX+yT1Df/Rh1S
         n2FeCaXPD34tEWixxZRPjNKY+nLFP3Dez33/66bnfdVyZfRTLC8s1fZFy+T6q2r4anVc
         GODf8+IR6WTHuj58Ms9vvYogwnrt1JSSKUebQCleKRv/WwDKg0AXJ4vtPfFuW/l+OLb+
         BtoLexwV4RSE2htpFZ7bEzXbmKOF8HhRP2gZIcCLQoSgw+pwa2g5AlzAsaOqzwdAgCvW
         JS4mhpxCXFLg7rEm0vsUTjVwlK+DmymqUU/bU/Sf53M/xskZ83mrXSGQaClZaTAUNJEs
         VIeA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738137195; x=1738741995;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=mcgoQ4RQ/+msiATfSS3LRvmHZ1tq/ucOrokkG5BuK4c=;
        b=fXRWM05KLxG8LGuqOdIvztkaZw4NLzJ0KDmQIED1Y9lT1YM4ZMeJDSKBQ28RNVwiaB
         uEQD1dSNMOj1wOU+hQzEbMYaiG3TxyF560kgV/0+o9yNZcWg4mjEY9ecQ6+REs7D7ljT
         NMxaCpq2xRbvVAslANWufhjoLQQ9YxDALJoWXDANdCOPbLVSWvTl6EWI4K2wfacxQ4nQ
         u/jH3iB3tXWwGw2JK5+X+/C3BJFt8SPu+9sYpFiEZCUM1HetvGC4A4nUhsSMgQD+Jp7+
         crVfV6ateOyH+f4F2+OAVTiwLTbDe3uNZVu3jdwLsB2F8B5oWi4DQesEB1ImmTdcjfUH
         BDxg==
X-Forwarded-Encrypted: i=1; AJvYcCWq7tqVj9DJRPsbmjjJ0XHmHgJLGIvTYCYqxx/Ua/DlVBlNMQbY5QGNn6KZFKPSvq6r7flFdczvvS8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyumzLBRDTyx5BeEjoLZOeWPq0iSaRGbausta6GMPQByTZnmgnO
	VnUxTPe4/3p7qBt0tE77FzFqhaLfaDkT9TxiUojS5RjvACTKPiToEr9tW310ug==
X-Gm-Gg: ASbGncvnLVhUrP84icdAURptE1OMVd0LdLFqLRFNAzroVDEr+RqDZRWJuHBxLcOy2jV
	FUI3YkLLDrPWKbq7dwL/Dr2dfZtiIps30N78Msp0tsmdj4l58OOIeVSVBA8tGRNvM26vGE6IBJJ
	cxhW/sCFbq9KbIJHXrbcwMvrpmv4uDEuWEEowelX0tgm0PUYAuagRK3zfjQuDdb4SDvYlNdgQKz
	F3YddoMWi2w4mrZD942ebOhtyPhk7gtAGc1/lSVI7qiMq05S068KZmm5M2GnMfm64T9jM2+Hvti
	J8k+yITECEkMvl6Nh0m0ljqgEwmvhgGn8UYr+hf+ajPfGz+YKaDaqC0RAdg2dWc2n45/F7vkGrG
	A
X-Google-Smtp-Source: AGHT+IHN7Yw+nj0laTMFMqxkFW6y877jCTQNKW7apzEZ1xKv8k1Ooc3D0fbPkXvLOo0EadNg8+2Guw==
X-Received: by 2002:a05:6402:4309:b0:5d0:fb56:3f with SMTP id 4fb4d7f45d1cf-5dc5efbf5d8mr4587300a12.12.1738137194507;
        Tue, 28 Jan 2025 23:53:14 -0800 (PST)
Message-ID: <b4426452-16cc-4a85-84b1-8e27152796d4@suse.com>
Date: Wed, 29 Jan 2025 08:53:12 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 15/24] xen/console: make console buffer size
 configurable
To: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, Stefano Stabellini <sstabellini@kernel.org>,
 Julien Grall <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
 <20250103-vuart-ns8250-v3-v1-15-c5d36b31d66c@ford.com>
 <d471f3b0-5638-47b3-927e-318b0575eaa3@suse.com>
 <RKwzueYurWHDxryD0KUwTcZHRfprlyr4H0fIq4w-yV2i5uK4XfDGrWsUBgt8FnW4R-28hIjbclYcGVP62eLjfFAIwNjXzP0Qj2sajURd-8s=@proton.me>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <RKwzueYurWHDxryD0KUwTcZHRfprlyr4H0fIq4w-yV2i5uK4XfDGrWsUBgt8FnW4R-28hIjbclYcGVP62eLjfFAIwNjXzP0Qj2sajURd-8s=@proton.me>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 29.01.2025 04:04, Denis Mukhin wrote:
> On Tuesday, January 28th, 2025 at 8:32 AM, Jan Beulich <jbeulich@suse.com> wrote:
>> On 04.01.2025 02:58, Denis Mukhin via B4 Relay wrote:
>>
>>> From: Denis Mukhin dmukhin@ford.com
>>>
>>> Add new CONRING_SIZE Kconfig parameter to specify the boot console buffer size
>>> in bytes. The value is rounded to the nearest power of 2 to match existing
>>> conring_size= behavior.
>>>
>>> The supported range is [16KiB..128MiB].
>>>
>>> Bump default size to 32 KiB.
>>>
>>> Link: https://gitlab.com/xen-project/xen/-/issues/185
>>> Signed-off-by: Denis Mukhin dmukhin@ford.com
>>
>>
>> As asked elsewhere already: How's this related to the goal of the series?
> 
> I mentioned in the cover letter that there are two group of patches - console
> driver cleanups/fixes and the follow on UART emulator (and up until v3 it was OK
> to have this patch bundled into the series).
> 
> Yes, I acknowledge that the first group of patches for console driver grew big
> and probably should have been posted in its own thread.
> 
> I can move "console" part to its own series if it makes sense now.
> 
> What do you think?

I for one would appreciate you doing so. Where patches are independent, you
may even want to consider posting them individually. That way it'll be clear
they're isolated, and hence any one of them that is fully reviewed/acked can
go in (once the tree is fully open again).

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 07:56:08 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 07:56:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878918.1289123 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td2vf-00055p-UD; Wed, 29 Jan 2025 07:56:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878918.1289123; Wed, 29 Jan 2025 07:56:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td2vf-00055i-RY; Wed, 29 Jan 2025 07:56:07 +0000
Received: by outflank-mailman (input) for mailman id 878918;
 Wed, 29 Jan 2025 07:56:07 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=1peA=UV=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1td2vf-00055c-62
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 07:56:07 +0000
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [2a00:1450:4864:20::534])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7da685ed-de16-11ef-99a4-01e77a169b0f;
 Wed, 29 Jan 2025 08:56:05 +0100 (CET)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-5d96944401dso10813762a12.0
 for <xen-devel@lists.xenproject.org>; Tue, 28 Jan 2025 23:56: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
 a640c23a62f3a-ab6a2fbcca0sm549817566b.101.2025.01.28.23.56.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 28 Jan 2025 23:56:04 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 7da685ed-de16-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738137365; x=1738742165; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=K/Okr+Pagtqjv6CJ8CoRIdA57yq3DXtsNYEeGfdN0ko=;
        b=CZ9V60SsZCbgKx0dDyIdbFcy4qQfhIDCtabmqouc/ojR2FERc39b/oAzmvMfnITy3E
         kRj7dydmHgb6eFEHKzvCddllz5Wn7PkJZpAkR3vVs30CRsmg6wYsmBqL8wFtnrVB17wi
         EtzxXLkplBjXQhsU4ep4pzH/f7blte0x+VsPxOL8ySYeucBfNBKqqaERswNowix16F2D
         4a8DtINLKvwN4qXUBLx15PLKKaOVDVXCPBDDkWpIW7AcOknigqIYvj+ui2xjVeh/sxrJ
         w5vuEubo7ZC2GQSfDZyFHl1/FV91PkIHAai0fgROIELyflZffHjzeqqKSITYlIxKurbT
         QV0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738137365; x=1738742165;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=K/Okr+Pagtqjv6CJ8CoRIdA57yq3DXtsNYEeGfdN0ko=;
        b=MEooW2s0YolX+IgRe+ywA9aEmgCawOeFIxNAn1IStTIGqeR/SNBCVrnYQT+9PUHV8k
         G/IJuEzIjSo3AEtc3Ptvk/RWC3nCMjUVM8S9a9/pjnS8AnSmWUydw2Mz+SmUO12KMCPg
         P2Rr6/hnIJDGapXXG5uskHiM0hVj36p27GAlNIt0uMs3dqJKb9yaAnAObajAT9fy6J2n
         rc6YFnq3ehxj+Mi1a2AZKl3NuKtNOVJROgHU2mUG3IU5LXh4tiT6FuXJfFwyuK0GgJ7P
         F7qIfEv+/2GL95dEka+2Wc68jLOW3ON1hzoxN01HQWZdJQSU+SMtSPggwyJTp5UMgKPm
         S3Zg==
X-Forwarded-Encrypted: i=1; AJvYcCWjBIqJMBnCS3F3umtr8rZrEjmv7Wlhcr64RdKWtYx7iq3HnHQY/eEJr1deMwmVZ7aznaes2JJcfR4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxZsxuLMrK5xHMSrhHleV1Kb4Okqe8zAX0Lz0uPIhdoL9PaS41l
	RXq58JvGwMA7e+uBIlgYzv7bfRC+xw6J+DARnBdCQosx88qc6oStneM8cCng5A==
X-Gm-Gg: ASbGncv+QijBSZxq/iERodkt7Z5TG8FZrj5XQ1j8GBpuzWPiqV7/vXqvEXnLiwJ3CK8
	xuNkFZzwuW//v6yrC1rDS47wBBit82z0vEqVVL38iMszKwpaRpFYOzggtw1lVYCsqNVRmk4Nld1
	Lm5CfpaUmvleGCNK84Z9NNcDtEhq59BAXIB6aKqg4H6GO0mLiGJNptAWt2LX3MWHKV24I2oXaTk
	1wSXxWrLRa//nF/iTGsc3NuZaqhlrYtjO6A1Zgwct3aar6xYD//ClYiETTXvJ48O8AL3vHZ1388
	WopJFSNTtEwiPOghuW8D2yJJtkXuZMll0E9CRYjkVGglotNHHepIa4o91dInzCVHGRFpYA0z9bR
	Fq9Zde+nDoKM=
X-Google-Smtp-Source: AGHT+IHK8WQ/g/1ERnSQ33elHTcROz3RTpGGcRz5+xoMnnSAS2iU1lH5gv0yRU3hP6aX4dUvKQua3w==
X-Received: by 2002:a17:907:724c:b0:ab2:b5f1:567d with SMTP id a640c23a62f3a-ab6cfd0a17amr168419666b.32.1738137364712;
        Tue, 28 Jan 2025 23:56:04 -0800 (PST)
Message-ID: <f57b6e29-c0c8-4166-9567-53ac01225b26@suse.com>
Date: Wed, 29 Jan 2025 08:56:03 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 19/24] xen/8250-uart: add missing definitions
To: Denis Mukhin <dmkhn@proton.me>
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Michal Orzel <michal.orzel@amd.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Jason Andryuk <jason.andryuk@amd.com>
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
 <20250103-vuart-ns8250-v3-v1-19-c5d36b31d66c@ford.com>
 <d58cfd92-cd73-4a7f-8660-6a235ae887e5@amd.com>
 <_2QXLWvBsyAVvLYs1e9CcyCX4s4MXM4YyIrs-lqVvpVUzZTdO6qkqnwJzHV_EEQnWkUhn2nhazgADEnsEM4kf8ciUYTrsjSJll57wFcW4nM=@proton.me>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <_2QXLWvBsyAVvLYs1e9CcyCX4s4MXM4YyIrs-lqVvpVUzZTdO6qkqnwJzHV_EEQnWkUhn2nhazgADEnsEM4kf8ciUYTrsjSJll57wFcW4nM=@proton.me>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 29.01.2025 02:16, Denis Mukhin wrote:
> On Tuesday, January 28th, 2025 at 2:34 PM, Jason Andryuk <jason.andryuk@amd.com> wrote:
> 
>>
>>
>> On 2025-01-03 20:58, Denis Mukhin via B4 Relay wrote:
>>
>>> From: Denis Mukhin dmukhin@ford.com
>>>
>>> Added missing definitions needed for NS8250 UART emulator.
>>>
>>> Re-used newly introduced MSR definitions in the existing ns16550 driver.
>>>
>>> Also, fixed indentation in a comment for FCR register.
>>>
>>> Signed-off-by: Denis Mukhin dmukhin@ford.com
>>> ---
>>> xen/drivers/char/ns16550.c | 6 ++--
>>> xen/include/xen/8250-uart.h | 78 +++++++++++++++++++++++++++++++++------------
>>> 2 files changed, 60 insertions(+), 24 deletions(-)
>>
>>> diff --git a/xen/include/xen/8250-uart.h b/xen/include/xen/8250-uart.h
>>> index d13352940c13c50bac17d4cdf2f3bf584380776a..6d1af31d582a3dd674a401d7f649e28c889cdc3e 100644
>>> --- a/xen/include/xen/8250-uart.h
>>> +++ b/xen/include/xen/8250-uart.h
>>
>>> @@ -51,12 +54,19 @@
>>> #define UART_IIR_THR 0x02 /* - tx reg. empty /
>>> #define UART_IIR_MSI 0x00 / - MODEM status /
>>> #define UART_IIR_BSY 0x07 / - busy detect (DW) /
>>> +#define UART_IIR_FE 0xC0 / FIFO enabled (2 bits) */
>>>
>>> /* FIFO Control Register /
>>> -#define UART_FCR_ENABLE 0x01 / enable FIFO /
>>> -#define UART_FCR_CLRX 0x02 / clear Rx FIFO /
>>> -#define UART_FCR_CLTX 0x04 / clear Tx FIFO /
>>> -#define UART_FCR_DMA 0x10 / enter DMA mode */
>>
>>
>> 0x10 is bit 4...
>>
>>> +#define UART_FCR_ENABLE BIT(0, U) /* enable FIFO /
>>> +#define UART_FCR_CLRX BIT(1, U) / clear Rx FIFO /
>>> +#define UART_FCR_CLTX BIT(2, U) / clear Tx FIFO /
>>> +#define UART_FCR_DMA BIT(3, U) / enter DMA mode */
>>
>>
>> Now it's 0x08. Is this a bug fix? Looks like UART_FCR_DMA is unused.
> 
> Correct, NS16550 defines FCR DMA as bit#3 (0x08):
>   https://www.ti.com/lit/ds/symlink/tl16c550c.pdf
> 
>   Table 7-3. Summary of Accessible Registers
>   7.7.2 FIFO Control Register (FCR)

Any actual corrections you make need mentioning in the description.
I'm glad Jason spotted this; I did overlook it.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 08:28:07 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 08:28:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878930.1289141 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td3QY-0001Rd-ET; Wed, 29 Jan 2025 08:28:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878930.1289141; Wed, 29 Jan 2025 08:28:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td3QY-0001RW-Bi; Wed, 29 Jan 2025 08:28:02 +0000
Received: by outflank-mailman (input) for mailman id 878930;
 Wed, 29 Jan 2025 08:28:00 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=/Ogr=UV=arm.com=Bertrand.Marquis@srs-se1.protection.inumbo.net>)
 id 1td3QW-0001RQ-F7
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 08:28:00 +0000
Received: from EUR03-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur03on2062e.outbound.protection.outlook.com
 [2a01:111:f403:260c::62e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f1ffe28d-de1a-11ef-a0e6-8be0dac302b0;
 Wed, 29 Jan 2025 09:27:58 +0100 (CET)
Received: from AM0PR10CA0123.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:e6::40)
 by GV1PR08MB7801.eurprd08.prod.outlook.com (2603:10a6:150:58::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.22; Wed, 29 Jan
 2025 08:27:49 +0000
Received: from AM4PEPF00025F95.EURPRD83.prod.outlook.com
 (2603:10a6:208:e6:cafe::3c) by AM0PR10CA0123.outlook.office365.com
 (2603:10a6:208:e6::40) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8398.17 via Frontend Transport; Wed,
 29 Jan 2025 08:27:49 +0000
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 AM4PEPF00025F95.mail.protection.outlook.com (10.167.16.4) with
 Microsoft SMTP
 Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8398.0 via
 Frontend Transport; Wed, 29 Jan 2025 08:27:48 +0000
Received: ("Tessian outbound f30a9786ee22:v560");
 Wed, 29 Jan 2025 08:27:48 +0000
Received: from Le9b63c57896d.1
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 BBE4AC25-AAA5-43F4-B425-32619D748A37.1; 
 Wed, 29 Jan 2025 08:27:41 +0000
Received: from DU2PR03CU002.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id
 Le9b63c57896d.1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Wed, 29 Jan 2025 08:27:41 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by DB9PR08MB7793.eurprd08.prod.outlook.com (2603:10a6:10:398::8) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.22; Wed, 29 Jan
 2025 08:27:37 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a%6]) with mapi id 15.20.8377.021; Wed, 29 Jan 2025
 08:27:37 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f1ffe28d-de1a-11ef-a0e6-8be0dac302b0
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=Q4gqCdJqigNrXH0Nz3MtDTWiyKwqJR5eRm2xcjs3pDYmPjfqwfP90/3VTba2MWONY3+n1OAHeUR0fgqCsUtWFv2XvkC98kjhIqbGEjnLzS8vPEvrw/vskIIA7XM4hX+qETMj20/TSBNxc9UdexRS8jgbvFcyUysTKLUUL9NcvaxwzK5EpT20w9Z9oU7pEeuhcR4qzaVBOVcJp26qVj+eribB/PPZWNa7MiKnsGq+l7dMebHFFCYa1qHVYRRROF4DaQ6mvJheM1fkzb06BW20OU8yY1nAB+OcqQ6+24eM2qs/zlPjiUsX77ApgBhBvaQfrE74PD9iTn+C7ZBBw3kkVg==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=3gDjSK+QZ2iHDrHwxLIug8xIREgHyKTYFrw68Erz10Y=;
 b=EOYLZxie4sNIXp1rCCOh5CmjonsbGR1mV+C8gX91JBHQ09gGKnv0msyXwPQ93/kDw70uAaD15w+tvWz7UpGv/61BNpuIB+BkrPK5w5NKYXatJRh/Yc/7DoraovZG0z+a/+FbvA1AEPY0QBpY/sR2bZ7I7r4gDNYxaBRNpFIkZ8ZCbp4u5YiQgGbdaVd7apCHOrp0Y7fHjgSITOyssqGf+caawISE3Cj7ePQxXtnQbqRmoRKm/rIdrLCFQrOE4HQpeHggAzEKCxPflJbk1mdChNUH765KUrSk2XCfVMMUYuV8SOg76MRUeBqVIFKpMeLyMXNhbmsFFNy9csVH0GKJEw==
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=arm.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=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=3gDjSK+QZ2iHDrHwxLIug8xIREgHyKTYFrw68Erz10Y=;
 b=iGNqoBvosup4mMa/zKlyhlTUXsbX+qFCkSSZwoZ1ce78CeEL4s4flTXeoQdxv4qBM7w2B/CSJehTqTGx/96MoMwfmnR6i6CZ7Eg+oHQPG4SDZdijCsbxIrxR6Whg9TWN3bDsYyT5vszrKrmBNDBWCU55Tj7k0EoXXHiGHCdbR4Q=
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=arm.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: 012863e28c7184e3
X-TessianGatewayMetadata: 4lZKxrn2R84eN6nI/yH/JrjvySLvSrtjduVfPY7C0uTobrYlsQKG5NKsSQMNa/V64vLIv3kokyJhql3P4jyq+FZUSoMBwuXO9tQgb1OUNSWQJM7/o3oDj2DiNGEBKDrVgwxiVBDK2wsIa2S5wBtXic4bZda8bZM5KEvFH6OMc2Q=
X-CR-MTA-TID: 64aa7808
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=FSPLhA4XwJ4w9tmroUWPBhMYrUvJH0lSgK5sm8x0Q8PIQbmBjLzNEjcpDbr4n5pzhmpRy4ajwA+W++pg1YxnFZ0HyUFGABGg00cmJCR87EL4gxVbYfHmQJcxFmrEf9MU6IjeJiLcO9Criv5T+meFQ+OVKbyKV7TEg2m3jgqqXvkV3OQD0VIzV9eALbTasvSFmf1pOAEEDmAVEyDIE5SJ9s3VJ+nONwcb5MnvzU/s22yioc5KQMrPqLeyn7gYSgrQBuXqv89YVzwiXooO5ui93DFftzLyG4r4kV48MSHqLnekgXd/QxwwPnJbUE3rv7BH2+fWxMYumeSIB2x4tIpXjQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=3gDjSK+QZ2iHDrHwxLIug8xIREgHyKTYFrw68Erz10Y=;
 b=odVzmIVXUUDDfzVlB6/a9ZfNg1Ut5X6zqajx96cqW7ycZDOu0IOQegp93STSXKsPJLX1u03/uUT00IfTqYtzPVsOrytDg3bqXHyR5p4QdCHAEiof5KmQvhH7FTrykTVhD2+2oPgfzqEKk5gVnfcEVBARN20kc0vd65TnlbIXAYIN2AVDtbqeEiEdHh4CSk8KEHP4PGoTx5XiDcofi/5l2hJs0Yau0eRnLKEiSbaUVOaneLfrFVNUW+udy8UjWPoDbBUPmODnYXymRNhz5ytaT8NWJ8hhqQF/Kh9Z9KJ/+V4iSUg7AZK0/2GQJzG+Vybp5DoajgIz0xOYjmkTLJyAaQ==
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=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=3gDjSK+QZ2iHDrHwxLIug8xIREgHyKTYFrw68Erz10Y=;
 b=iGNqoBvosup4mMa/zKlyhlTUXsbX+qFCkSSZwoZ1ce78CeEL4s4flTXeoQdxv4qBM7w2B/CSJehTqTGx/96MoMwfmnR6i6CZ7Eg+oHQPG4SDZdijCsbxIrxR6Whg9TWN3bDsYyT5vszrKrmBNDBWCU55Tj7k0EoXXHiGHCdbR4Q=
From: Bertrand Marquis <Bertrand.Marquis@arm.com>
To: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
CC: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Stefano
 Stabellini <sstabellini@kernel.org>, Michal Orzel <michal.orzel@amd.com>,
	Artem Mygaiev <artem_mygaiev@epam.com>
Subject: Re: [PATCH v1 1/2] docs: fusa: Define the requirements for
 XEN_VERSION hypercall.
Thread-Topic: [PATCH v1 1/2] docs: fusa: Define the requirements for
 XEN_VERSION hypercall.
Thread-Index: AQHbZr2N0lH4GhPB/kOpvRdBJn3PXLMtgcUA
Date: Wed, 29 Jan 2025 08:27:37 +0000
Message-ID: <65584EA7-9B46-40E9-AFD8-B7C8F77A5DA0@arm.com>
References: <20250114195010.3409094-1-ayan.kumar.halder@amd.com>
In-Reply-To: <20250114195010.3409094-1-ayan.kumar.halder@amd.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.300.87.4.3)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB9PR08MB6588:EE_|DB9PR08MB7793:EE_|AM4PEPF00025F95:EE_|GV1PR08MB7801:EE_
X-MS-Office365-Filtering-Correlation-Id: f8640c48-11a5-4630-11a9-08dd403ed0a4
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|1800799024|10070799003|366016|376014|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?us-ascii?Q?+vOEy2LR7oLldaChIGthoUIMCEsT+8hOrCHOzL79pDxdBkckokX7DtBjzRck?=
 =?us-ascii?Q?OYa81a7E1VucbUqytrDm3uNQS4rghCd5vzTGajKSZWBE8CbRDtJVHz4DFpy4?=
 =?us-ascii?Q?7ir65e/p5/E/+UOJrO5z/of71nhy+S6bTbIAo+bmFyvoldPeWt9rSTXclM44?=
 =?us-ascii?Q?2vlE2iv/qcCy873xlZb8BLYHYjdlyNK7FcRcLnpWZRsuWVgzAOS49VXAIp2N?=
 =?us-ascii?Q?LUs41mYimt0BprtughHm7Fa1J2yTsK9sp12gq/Rjh3bQo9Cj09a/KiI7cYp4?=
 =?us-ascii?Q?DdzsV4vpcIhQQuNLGQMRddo4nlp1nvVmssOVga8UXcSfyQq1waKCOcMwWB3D?=
 =?us-ascii?Q?Qwc2mYdW5Qc8WNt66wiuZGvo414KE+GWnD57khIDrYiGYXbYxkYP5Ce7InTn?=
 =?us-ascii?Q?9YGqnpqhfP2OUTkRJqL3eQUA84QiBud68OKeYw1t2O1yUAylBtg/WF11LbmG?=
 =?us-ascii?Q?z3z+/R/0aC941oHQ+W8Zjxt3/0zvLDfwNPJhMyDpeajNlEyl7wEcSP6X+tOb?=
 =?us-ascii?Q?qzBSibBURQOaTGXjP5k+mdARZ3EeOCqm3A/ZETQsbUNff5JxGbksmSFP48xz?=
 =?us-ascii?Q?R03RlVhESWjHMuoENniVi/hIzViFGUgrdExQxDXdXV+Tm52KcnMGP/M4TUl/?=
 =?us-ascii?Q?H1P7YTdA7FV/ii3EpA9pAGWB8ivhhHUSwg3ntHOvM66HHnW5DWIhJ7/yCALP?=
 =?us-ascii?Q?nmCH79JgR0jjHOXbAq5bQgAXUAzG4fqJXQFu986y6kJiUtfc8UEuGbgZBhZj?=
 =?us-ascii?Q?p3xZmfy93QY68brL5yfkcFfcCq3xLxtkrnntMURhzqJL3YdJAHOflfe0ZJOt?=
 =?us-ascii?Q?gPPkIA5YoWFvjdvKNU1dy8YIA9JesaE9IlpmLjbjwRauerAfF3j0l6w/mJ0U?=
 =?us-ascii?Q?1r5lU38/YWSNx83tzTy6gNQXX38c6jiaaW8XRitMVkEnr9eqpvSv7pMF9Nrr?=
 =?us-ascii?Q?pHQ+c54iWEaWopPf6u4y8sUMYv+K9h1NXBvKfQbkpCdoQo01I74KegtJ7mx/?=
 =?us-ascii?Q?+kyO4iEDD+kQsVrWHFHtvdyny7JajXsvhN7WRMfPEwON2b+JlYMRl7xRi8Kc?=
 =?us-ascii?Q?wd6MwfHUJBlRaX7+mYOVy4Ea1WHPQQvnV0/sjeaFyWctHKqu1gu7FyffNuBJ?=
 =?us-ascii?Q?wZtDpX+uI6cR0dt9nY/6/zlXsPKK2R+OhVQfjGy99LhXbm/0lPOlahYal1xD?=
 =?us-ascii?Q?Skhi/UNcbG/WHz+Slz1I52mI1//ETl6Njy8/fjCWJPyax3BYyFIEwstVDsGq?=
 =?us-ascii?Q?6eMFTB1ctu/qH2c/l8G2xNVF/UJQuWWiTBrIzC7tH8AhAjdFrvzqSfKFEidK?=
 =?us-ascii?Q?YIWzGDNBX1KUFpZvM+rlHwJnpglLwGa+FzcBArJJOwY/gLMLvWwKqkE8A17O?=
 =?us-ascii?Q?QRAPF+jPIwdPmkZc6V7VxicKXhto?=
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:(13230040)(1800799024)(10070799003)(366016)(376014)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="us-ascii"
Content-ID: <F630C92E0356F64DA487A145CA00141C@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR08MB7793
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-SkipListedInternetSender:
 ip=[2603:10a6:10:25a::24];domain=DB9PR08MB6588.eurprd08.prod.outlook.com
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AM4PEPF00025F95.EURPRD83.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	9df8f33d-4eaa-47d7-c32a-08dd403ec9d6
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|14060799003|1800799024|376014|82310400026|36860700013|35042699022|13003099007;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?4SYwzfrq+Z4BlYUEoaX2texBHunjYOfD3j3+7FMIlMMdZlCXzZx+FodfjCnQ?=
 =?us-ascii?Q?Y/8i7dIlrS3ITYynDe+QPM/L54XRK+z9vANqr6fbvl5bbdfLiER2ZKJdYn5j?=
 =?us-ascii?Q?90jfhYRejsVajRfiZ2ZuOkxWsxohAtE8bA8KUw9EUGIuZ8xq2xrPp8FK4mla?=
 =?us-ascii?Q?lPQoKXwr4p50X9Ap67hiuPUnj+s0IWJyPDngWjLCRcsopfgQnGwHio6hX9IN?=
 =?us-ascii?Q?dmPCcBOx6oYh0sZep/w8jFTA3fmUl3734G3vvTPwB+Eg+bXRoPehbzZBRxn5?=
 =?us-ascii?Q?GJfc0VHWge9voRDLdbLYuMVxi+uGWe7HJkfR0hTpkHDnAuv+YnCG5l4dwXky?=
 =?us-ascii?Q?+mlu2er4Y7ZBjbIHzSzPKxlnpqKdhrxdWVnHN3K7SBm0GPFKX/dPH8qtXjK+?=
 =?us-ascii?Q?b9MbeMi2WHRtT16ywENLZCCFOuBsYXottRgbdHrRB0L+1ZvfFtPCVAG4CBAg?=
 =?us-ascii?Q?hZsZzLPz1JDQvn0KbvSm2W6iR7eFt0/whbrTVEyMnyocXEgP3Ku2rRPEC253?=
 =?us-ascii?Q?7X8dsAbFu4iuQib9W/d+gaAdViuRvDUA9HKOWKSGqo6np1SIoE8J4cQdAkcf?=
 =?us-ascii?Q?oefuGV5+JXEHJYMapDigZrxFb5XGw+wlLpp95q1afGAIb5+PV4QRuR5DPpnX?=
 =?us-ascii?Q?tKP+i8i3LoRZhn40LxvriefcCMGtoHTRDZlCWtZvpQ/H/RObwzo74LLZJJki?=
 =?us-ascii?Q?Io/eAC3LWsuQH6RC2h1SzsgP1YzTa4vIFXShbgDIPwv+gnutysQfSgjhuZPv?=
 =?us-ascii?Q?kgpIPCY3hFMJBtesXEYC9+KlYDcCIbdBO1Z9nyDifx939crOtt9iaC4tM69R?=
 =?us-ascii?Q?fw7JAwlOpaWcSLjL3As1gPloR8wZj+sBU/BmTJjzIMV+BarNkB5SA1eJIuTp?=
 =?us-ascii?Q?lfDYkd8wXd8oEc0iOuaHOsyTPCkmmFSeAcHgilISUkQZidq3EFCKJQQlM5uE?=
 =?us-ascii?Q?C16urqFETNZ9A25JLCGN0yM6wStX0FmPoZw04b1XbNyWh+gQD0jM3+xoGApX?=
 =?us-ascii?Q?O8SrEX+gp+wziCrZusHMa0obcNclZZESjAEo14ccnGFwiMRPsWjmBBPUooCv?=
 =?us-ascii?Q?QBmUHatSymY640qckDvfWCjDwezINuqOW+feFk7pQuGc2wNlfKwLEV2ijzMC?=
 =?us-ascii?Q?CWRDcD457zKjrT8Fz2DU/aEozJsLIpFzc2shbHMRIXX1ylMTno71CJ2vDBuK?=
 =?us-ascii?Q?xe6TNJcfiecdFxXpqvMFuW+jc4+eAb+Ysn86kuP6NW529LqWBMil514Ho6mC?=
 =?us-ascii?Q?Gjp5MAkgBO5j5IlzFH7ylHOC65uBpwPybpZVsld2SjBo2LSePgPaAghYDD/f?=
 =?us-ascii?Q?moJBkb7CqRbjDlyHSzFgbEgYM7WZyXAN91wKY6FOCmTosEG12XcQBI6MeXbW?=
 =?us-ascii?Q?bmjYApsiSlrtCTYEqVr7Xc0uGgJjGpGzfbK6GjkoPFMrQ7/5koVSxq1ExJoY?=
 =?us-ascii?Q?LWEYSBbqAe4=3D?=
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:64aa7808-outbound-1.mta.getcheckrecipient.com;CAT:NONE;SFS:(13230040)(14060799003)(1800799024)(376014)(82310400026)(36860700013)(35042699022)(13003099007);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2025 08:27:48.8260
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: f8640c48-11a5-4630-11a9-08dd403ed0a4
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:
	AM4PEPF00025F95.EURPRD83.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR08MB7801

Hi Ayan,

> On 14 Jan 2025, at 20:50, Ayan Kumar Halder <ayan.kumar.halder@amd.com> w=
rote:
>=20
> In the current patch, we have defined the requirements which are common f=
or
> all the commands.
>=20
> Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
> ---
> .../fusa/reqs/design-reqs/arm64/hypercall.rst | 52 ++++++++++++++++
> docs/fusa/reqs/index.rst                      |  2 +
> docs/fusa/reqs/market-reqs/reqs.rst           | 16 +++++
> .../reqs/product-reqs/version_hypercall.rst   | 61 +++++++++++++++++++
> 4 files changed, 131 insertions(+)
> create mode 100644 docs/fusa/reqs/design-reqs/arm64/hypercall.rst
> create mode 100644 docs/fusa/reqs/product-reqs/version_hypercall.rst
>=20
> diff --git a/docs/fusa/reqs/design-reqs/arm64/hypercall.rst b/docs/fusa/r=
eqs/design-reqs/arm64/hypercall.rst
> new file mode 100644
> index 0000000000..66dbcc3026
> --- /dev/null
> +++ b/docs/fusa/reqs/design-reqs/arm64/hypercall.rst
> @@ -0,0 +1,52 @@
> +.. SPDX-License-Identifier: CC-BY-4.0
> +
> +Hypercall
> +=3D=3D=3D=3D=3D=3D=3D=3D=3D
> +
> +Instruction
> +-----------
> +
> +`XenSwdgn~arm64_hyp_instr~1`
> +
> +Description:
> +Domains shall use the Arm instruction 'hvc' to interact with Xen.

Why are those requirements defining what "Domains" should do ?
Shouldn't we define them as what Xen shall do ?
Something around:
Xen shall treat Domain hypercall exceptions and hypercall requests from Dom=
ains.

Or something around this idea.

> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenProd~version_hyp_first_param~1`
> + - `XenProd~version_hyp_second_param~1`
> +
> +Parameters
> +----------
> +
> +`XenSwdgn~arm64_hyp_param~1`
> +
> +Description:
> +Domains shall use register x0 to pass first parameter, x1 to pass second
> +parameter and so on.

Same

> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenProd~version_hyp_first_param~1`
> + - `XenProd~version_hyp_second_param~1`
> +
> +Return value
> +------------
> +
> +`XenSwdgn~arm64_ret_val~1`
> +
> +Description:
> +Xen shall store the return value in x0 register.
> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenProd~version_hyp_ret_val~1`
> diff --git a/docs/fusa/reqs/index.rst b/docs/fusa/reqs/index.rst
> index 1088a51d52..d8683edce7 100644
> --- a/docs/fusa/reqs/index.rst
> +++ b/docs/fusa/reqs/index.rst
> @@ -10,5 +10,7 @@ Requirements documentation
>    market-reqs/reqs
>    product-reqs/reqs
>    product-reqs/arm64/reqs
> +   product-reqs/version_hypercall
>    design-reqs/arm64/generic-timer
>    design-reqs/arm64/sbsa-uart
> +   design-reqs/arm64/hypercall
> diff --git a/docs/fusa/reqs/market-reqs/reqs.rst b/docs/fusa/reqs/market-=
reqs/reqs.rst
> index 2d297ecc13..0e29fe5362 100644
> --- a/docs/fusa/reqs/market-reqs/reqs.rst
> +++ b/docs/fusa/reqs/market-reqs/reqs.rst
> @@ -79,3 +79,19 @@ Comments:
>=20
> Needs:
>  - XenProd
> +
> +Version hypercall
> +-----------------
> +
> +`XenMkt~version_hypercall~1`
> +
> +Description:
> +Xen shall provide an interface for the domains to retrieve Xen's version=
, type
> +and compilation information.
> +
> +Rationale:
> +
> +Comments:
> +
> +Needs:
> + - XenProd
> diff --git a/docs/fusa/reqs/product-reqs/version_hypercall.rst b/docs/fus=
a/reqs/product-reqs/version_hypercall.rst
> new file mode 100644
> index 0000000000..fdb8da04e1
> --- /dev/null
> +++ b/docs/fusa/reqs/product-reqs/version_hypercall.rst
> @@ -0,0 +1,61 @@
> +.. SPDX-License-Identifier: CC-BY-4.0
> +
> +Version hypercall
> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> +
> +First Parameter
> +---------------
> +
> +`XenProd~version_hyp_first_param~1`
> +
> +Description:
> +Domain shall pass the first argument (as an integer) to denote the comma=
nd
> +number for the hypercall.

Same here should be turned as Xen shall.

> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenMkt~version_hypercall~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +Second Parameter
> +----------------
> +
> +`XenProd~version_hyp_second_param~1`
> +
> +Description:
> +Domain shall pass the second argument as a pointer to buffer in guest me=
mory.
> +

Ditto

> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenMkt~version_hypercall~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +Return Value
> +------------
> +
> +`XenProd~version_hyp_ret_val~1`
> +
> +Description:
> +Xen shall return 0 in case of success or one of the error codes as defin=
ed in
> +https://man7.org/linux/man-pages/man3/errno.3.html.
> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenMkt~version_hypercall~1`
> +
> +Needs:
> + - XenSwdgn
> +
> --=20
> 2.25.1
>=20

Cheers
Bertrand




From xen-devel-bounces@lists.xenproject.org Wed Jan 29 08:33:37 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 08:33:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878941.1289151 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td3Vs-00036Q-4P; Wed, 29 Jan 2025 08:33:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878941.1289151; Wed, 29 Jan 2025 08:33:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td3Vs-00036J-1I; Wed, 29 Jan 2025 08:33:32 +0000
Received: by outflank-mailman (input) for mailman id 878941;
 Wed, 29 Jan 2025 08:33:30 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=/Ogr=UV=arm.com=Bertrand.Marquis@srs-se1.protection.inumbo.net>)
 id 1td3Vq-00036D-PG
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 08:33:30 +0000
Received: from EUR05-DB8-obe.outbound.protection.outlook.com
 (mail-db8eur05on20613.outbound.protection.outlook.com
 [2a01:111:f403:2614::613])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b6aaff4d-de1b-11ef-99a4-01e77a169b0f;
 Wed, 29 Jan 2025 09:33:28 +0100 (CET)
Received: from DB7PR05CA0053.eurprd05.prod.outlook.com (2603:10a6:10:2e::30)
 by AS8PR08MB10269.eurprd08.prod.outlook.com (2603:10a6:20b:63c::15) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.23; Wed, 29 Jan
 2025 08:33:23 +0000
Received: from DB1PEPF000509F3.eurprd02.prod.outlook.com
 (2603:10a6:10:2e:cafe::f6) by DB7PR05CA0053.outlook.office365.com
 (2603:10a6:10:2e::30) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8356.21 via Frontend Transport; Wed,
 29 Jan 2025 08:33:22 +0000
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 DB1PEPF000509F3.mail.protection.outlook.com (10.167.242.149) with
 Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8398.14
 via Frontend Transport; Wed, 29 Jan 2025 08:33:21 +0000
Received: ("Tessian outbound 5438980c8758:v560");
 Wed, 29 Jan 2025 08:33:21 +0000
Received: from L93bdccdab809.1
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 53BE5880-9130-4362-B76B-CE7ABDF3B472.1; 
 Wed, 29 Jan 2025 08:33:14 +0000
Received: from EUR03-AM7-obe.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id
 L93bdccdab809.1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Wed, 29 Jan 2025 08:33:14 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by DB3PR08MB9011.eurprd08.prod.outlook.com (2603:10a6:10:431::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.23; Wed, 29 Jan
 2025 08:33:10 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a%6]) with mapi id 15.20.8377.021; Wed, 29 Jan 2025
 08:33:10 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b6aaff4d-de1b-11ef-99a4-01e77a169b0f
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=BgZ1A4Yz3sCY5gLcQEsjQbLe1cGl+Ro5Zy2pa0SUpsALf+453wfdFDkSHuwTXRvnKaV2GgtygO/sSVfWCQp9f+/F562oILm3DhZHx6LyfYHnBk3f7nNwuvKtOLtMTLFGwSWI0mKk3Z1fw9/DfII5pnhccxmhYLyqNpmor3+/8t+XBeXfvnLLv05Y/o+o+iJaj9EJkfVCjp+yZBdEEXrg8UZS0QiUVj5wLtQbwmvijH+WzvAh6jD6LcMWBezFop/T9ae0aW67tfpAdYjgCEoVjAHhXf8j+ougJcgYL09uBfc9uMTrVVBkq0AWxyxIN31xTugWaj7KWxhwaohsDArjdg==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=SUGPsp/HPncD2Me3IzexOzyyKMaKje3Ik7MFSJyl5Jw=;
 b=FXphxdtWG3HmwrErfkuKmxuXc3lD0RD+sXSpfPAZRyLLQaGBB/zhUWxihWTXzBenqX2JGp5tf40v90d0orcZMovm1shGCAyFzILGt8NjcW5yWEowZqJeHFVXIX9psnz6/pjEhl9YKuPfJRx8q1ZnFyeYbiIGLB76xo6UkFYWbGRIMxT6ru/7oVRMrOX/azIGWvaO5u9NzijZgrVVng+tUgT5SPZ+Jz8Do/OXXw2cK5uFxSW0mKJvmT0MoF/GtUjbWWWnzHfriJu106Y1H1P0hupq//sW1YyK9geXv9FEobEAn+E3+AxV0DoAYGISGX1pnSd68NneAK/tvR7jpxM52w==
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=arm.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=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=SUGPsp/HPncD2Me3IzexOzyyKMaKje3Ik7MFSJyl5Jw=;
 b=rhxRu04ndEMy0oYoiGA8/vwvUuSIKEzqlinTOZ0365ZRwVZC9Ku5u8rrK5QAnzoZ7qHHhJ4QNjDpNW6a3I3xKBLCMMBxW9AUGMkOwnhD9JgKygsCTPePcgAcwx5lMrduFKJ/5/nfUY0GWwj7PjkLvF8APZne5vCHM+GW3aLBe4w=
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=arm.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: 9985bb8269ac43cc
X-TessianGatewayMetadata: uNHoVc5anDsmRhPgy7kdyTS9W+FQmXbKjWFZgImbsFRpf53IgnK1VrAsWtRbtyswiKXYhn5pG9f4hxB80XsF0pIY/h1eCtKGkUNBACF28/5+C9chgdi+2AcSdWw0Ot2YEodt826mdUnKmFcHI4YR6g4d4IPyf7eF3qd3l8zOU+4=
X-CR-MTA-TID: 64aa7808
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=yE09Ib7+wX9gNzA2Gbumc4qAJXd2PMATVwZPgoCagcuBu+YpzgOgAg+mqWaPihx+uldt5sFnPGBeltHVdqdJzeXCdrLjEoDzkKX3dfUCsCqiDSGmC1OHrbtl9VHJIoKp9V/ovx+YZ5TZpXfdcuQEraM6ovCSo4lM/jwGILOPWkYZezMv/Z3sxRjrQDWgCzLk8ZyArV9xbLVV+ZOYvxBLnHnmxRRx6Ie2v3M8QK5q34a157HgRhTupSzbGkQ0VJXo+A3RnAqy/kM6si+qXnxrR2Hqc6SBIna4h/QpS++rUZGXYwRbHYx4kLcJva/g/qYCDmMbcQYGfK9aY+vstWuskw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=SUGPsp/HPncD2Me3IzexOzyyKMaKje3Ik7MFSJyl5Jw=;
 b=eT/buyRKUKe42lrYAQ6ZfpKltIPMpetNqvhiTytKdm+g1A2Cy7sRFxU7Ty+GvgR56YKdNkDDhOwyEvwf0KxPpdVQL4MILDtcZbzfDW6Q7faVh8fUTZXbm99XwnaudF0JE0zW7f3fmBDbgXGr1lQrgG9qTLWZVT5JitN56miRzPmoIefXds7w3s8f+3rDRKMkm+kGzslh2d2SOqHBbkd7alfsAo9n7btuTDmNsyptC1SiyAo42PA3geZ3AyG10K/fjGnIJB4AFGk1qgZF/2ZdOTkpNFgOQ8Rv4wuLwpbfIsqvzUjuiOuBik5S0uK9CFCayKWEA0ZtrAlxrtvTbJ0Ulg==
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=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=SUGPsp/HPncD2Me3IzexOzyyKMaKje3Ik7MFSJyl5Jw=;
 b=rhxRu04ndEMy0oYoiGA8/vwvUuSIKEzqlinTOZ0365ZRwVZC9Ku5u8rrK5QAnzoZ7qHHhJ4QNjDpNW6a3I3xKBLCMMBxW9AUGMkOwnhD9JgKygsCTPePcgAcwx5lMrduFKJ/5/nfUY0GWwj7PjkLvF8APZne5vCHM+GW3aLBe4w=
From: Bertrand Marquis <Bertrand.Marquis@arm.com>
To: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
CC: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Stefano
 Stabellini <sstabellini@kernel.org>, Michal Orzel <michal.orzel@amd.com>,
	Artem Mygaiev <artem_mygaiev@epam.com>
Subject: Re: [PATCH v1 2/2] docs: fusa: Add the requirements for some of the
 commands of XEN_VERSION
Thread-Topic: [PATCH v1 2/2] docs: fusa: Add the requirements for some of the
 commands of XEN_VERSION
Thread-Index: AQHbZr2QpA/avZzDqk6Vb2qnMvbcCbMtg1KA
Date: Wed, 29 Jan 2025 08:33:10 +0000
Message-ID: <ACD22224-C61D-40F1-8235-67F18E633019@arm.com>
References: <20250114195010.3409094-1-ayan.kumar.halder@amd.com>
 <20250114195010.3409094-2-ayan.kumar.halder@amd.com>
In-Reply-To: <20250114195010.3409094-2-ayan.kumar.halder@amd.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.300.87.4.3)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB9PR08MB6588:EE_|DB3PR08MB9011:EE_|DB1PEPF000509F3:EE_|AS8PR08MB10269:EE_
X-MS-Office365-Filtering-Correlation-Id: 8082e965-9efd-48e2-9835-08dd403f9707
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|1800799024|10070799003|366016|376014|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?us-ascii?Q?DEzJmSSH6cCXhMQWx64h793Y3nKCaupCk0EAwoTx9KWvVea7TL9xAV5YF0Nk?=
 =?us-ascii?Q?TL7Qz3EZqcYcPAN5qoB12/zk50kZ4DOevtTUhxHYpD+hBT6G/GbsG2kTIZUq?=
 =?us-ascii?Q?G67fNmX14IMs6G7VwsN/JRQTXE8LO/0w895V9IIEQfPgeVvL1TcT06AuIEy+?=
 =?us-ascii?Q?CjPXJTxlaAsoM2NeUCadZvx6sKKRCnD3I85zygnkqRpSvuwZoCl6obAVc9C6?=
 =?us-ascii?Q?mJC53CXL5hUfPSJLUmHQZYTgVv1yeM54z1L3iNSud509UhGRCW6qe+2K2+nN?=
 =?us-ascii?Q?yYhShAeJEZxFTci9NNpRN6b8ZpsdQAD5EY+MJmytJ1mabXTL2qxVnx+LoW9L?=
 =?us-ascii?Q?t8P04FdIJxp9AjsVmtw7Vx2eADRHC3WrdG1CcpaRvKG7I13jDkPKlybFFyES?=
 =?us-ascii?Q?FZA6FlgyP4IZOHth01Xz1YtlcnNUkq/X7E+2R7k0XZl4fNm3IdFa79zLFkk8?=
 =?us-ascii?Q?VMg96zkSk9UwsBrQagXFwGQZFvEzMPIrdQZRIohy+mc/4XDl7t/pSsyjicWJ?=
 =?us-ascii?Q?Lt6OaI72GofdJMVZFeLO7j5AoFEZLu6b6wQzdN9oGze7U9RPkhkW5n+/sNN2?=
 =?us-ascii?Q?Jn4zlCQg04zEwQ61Iw+2ufBtZV0WEFpbs+oatat3S9mSE9NBqLybFxhe5qxS?=
 =?us-ascii?Q?5ppSGEiF6agY7E9t/DUQwTo4BcHVgrQhAAQks+DZ2ngL/GR7u6zYLD+Px4wk?=
 =?us-ascii?Q?yt6LslbvS6d3iqT9+nlJQ/o9gz6W5FwBO+1lbMuTrkLMXDCNcIM++gZU0Gun?=
 =?us-ascii?Q?kAdRFdrrQtMeRR9Yq29f3JfOO5tGwENMgQPmFe4KJMndYz+wFXMOkNHEfr3X?=
 =?us-ascii?Q?gOnrvdtC5wAjHsIJfhlXN1hVGf4IqyNbCbGjhMcwo4pVwhWQgxR5mi7CvNUa?=
 =?us-ascii?Q?IVhjeNGSnr0OLSR0FZS7wA412gkCR9A9feHKMNg450GF6CXSw39wqaWdw6JA?=
 =?us-ascii?Q?b6IDf/22CQ+efAD89TTlcpoSO+geOxQtpbCf1CtZ0cziOXM8phuIlQLdfbOV?=
 =?us-ascii?Q?ZHBD311Uq8V3Yuwa2Hsb1uncKLCybM9TRmLGCArgmMYj6IwLkdI/2ttEDEGT?=
 =?us-ascii?Q?ec70YGF4a2RCY9UA2ae6xC69VEY5YDCBLTZLZIH5D4lMMCykCBDwO4SW0S8s?=
 =?us-ascii?Q?YK1bmnn+IDzLsnB9fzmuzs4bViXsk7SyovZXcOugBQcu7vdVGfjBlUZeqJPv?=
 =?us-ascii?Q?yeeSRmPHLrHMDXmYIfnjYndrnC9kCPF3kIBzS/WxQGJjAt45Fzk2SaRqr7Ky?=
 =?us-ascii?Q?Awx/v1s9ZUt+h5xseOVJyQFnQOnAdYBPyqYlQZA2UT06fZCgM0N7eohRZvP8?=
 =?us-ascii?Q?cBoVaRqg21b5r5pU+WC0CY3vWU/Aa6p4VuWhiiosRxKitV/uJ4pNIsCbGEoE?=
 =?us-ascii?Q?G0nt1gAWLFZ5Tn6hMPBVX8H1G6tskPO+yi1PEFQbMSEHQRNt16KGwKbJbYr+?=
 =?us-ascii?Q?OrOWGUErZ5ol7QBxFPxA/3omnRV21XUw?=
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:(13230040)(1800799024)(10070799003)(366016)(376014)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3283CEDE47A9F749BC9F4DEFC6C5F97F@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR08MB9011
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-SkipListedInternetSender:
 ip=[2603:10a6:10:25a::24];domain=DB9PR08MB6588.eurprd08.prod.outlook.com
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DB1PEPF000509F3.eurprd02.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	91e89d54-27a7-4913-6add-08dd403f901b
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|35042699022|14060799003|36860700013|376014|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?8GcwQXW3CmitcUs0i0Ro6hUHKnSANMM3yctQgODOIokgApXEPQnXlGt6FHk3?=
 =?us-ascii?Q?JagLLlLj4m8dMs3Id3OSyVr8jqWqqY//SifUX9jKJHpYBLb3cCuyYOSA421g?=
 =?us-ascii?Q?ZZsnFocJh0z11ea76tCE5YK1X1EeDk5Y8MmRPPLFK+mNifRvFANprBNwS+lj?=
 =?us-ascii?Q?1SknWCzL58AEQ+Lcmys8zrXCv0LMJooCGwxEKG0TaHMkz32H9V+RTAC3WSWC?=
 =?us-ascii?Q?fLUSEmWQokqg54hrPGRFSgfk/FOhTEGJ8Hr4wpFHP++Zx4msZyN8z5oZzKAS?=
 =?us-ascii?Q?CibNgGvsdTo0naFdeX5RKcUQQLtdIejMYba4yLd4iIEWhlcv+YLwp4dP3zoD?=
 =?us-ascii?Q?GZOHNWiYtedKGtkXhjrhH8prJGHb6627WTvifuouMJ9ERaKo7/OA/aMlGe5P?=
 =?us-ascii?Q?sy/VZ7qA6nmU0N86r5vSscjt48fds5rjkmcqMewGD15TBuU36U+8GGzdaAM7?=
 =?us-ascii?Q?QJ83glWC0gUYeKmwd+NyogR1PiR64oIYKUGd4pTKyiM71qyZnaXXcU0cWpH6?=
 =?us-ascii?Q?Yv0PFac/6DMPjZGQbPe+dd9AhC0JzHd6I6VYEzuP7s6h2MKTkYdWv6NGyDHK?=
 =?us-ascii?Q?w+8BYKl2bhtottGcvuffISutCw8NcFg18vpYVfi6TRYU8o3e4nNx2F1SFp1j?=
 =?us-ascii?Q?18e+Mdz1a0YNolQgGRKR9jI5NTHWAC95W0v6dX0UhjIdqD9mmChuyi5qjd8K?=
 =?us-ascii?Q?NdeH93uO4lznlEvgYUwhQ8snsxrqcAu33mi0tI8tMUfy2W0+ZsUIY2t5zyaA?=
 =?us-ascii?Q?h0wN9Y+kwylif95wjWmTO6/ILdmNl+6+A+CcmbXSaIRgOLJj2I5zOOIJypHD?=
 =?us-ascii?Q?xIbwQCO7IDeFZUgag3cm9RZbw1/26onprZjqrN4DNjrHthx4kmWn04FeThd4?=
 =?us-ascii?Q?tS5bvIVnBbrh0B30tfyKRfZaGXuhwunvrZwgP5VzQHw6AHxnrU9gpbeiFGzO?=
 =?us-ascii?Q?RkB86cfw1EhtdxDL6HEKvK9aTJAI/3au/NxWai5NyhtCSF6GcEqmI/PDiENj?=
 =?us-ascii?Q?eug/t7uLNNPlDBllCEirIYc+8G33CSnKWwcqnRG4pqVKKDjNrqVqwjZmUOmD?=
 =?us-ascii?Q?0HYS2yByikLw1r7VFM0C9+rpWBC1CJ+VUqWXBjZYOModswctKCEIJmSJXBTI?=
 =?us-ascii?Q?KfLNxDbG1h5AKjWFTLC2bSWSe2xhSy1rsjT1Zy0M3qsbjL64hZBaf05sjKZN?=
 =?us-ascii?Q?kusAiE7GFbBbgpWh6fncQuecoi82rijWmbXn4VxAejM92v6BEVboQ+c86IYS?=
 =?us-ascii?Q?GD7PRBU/JA5W8s0R9xvhJHuSdPp0b4FM79lXbijwYfG9qpzvxadOREDqEtfV?=
 =?us-ascii?Q?BJgl+MJmpguQz3FI+gpIfuIVZoFTRo53G6Kau7Z9C5xjTFgmnNOP7YCa+lhb?=
 =?us-ascii?Q?p4ywj4/RPJg9h0CrB2uEQYcOrrrw9pbZtO6c/E3I1vXgOsERqV+lUuRvPXtr?=
 =?us-ascii?Q?YC/J4DUOWexsrroJqfpsFdwTKpsNfYBu6cKbJPb/wkveK5xGO7rBT/bASQhM?=
 =?us-ascii?Q?+kTI3OJDpe8yJVc=3D?=
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:64aa7808-outbound-1.mta.getcheckrecipient.com;CAT:NONE;SFS:(13230040)(1800799024)(35042699022)(14060799003)(36860700013)(376014)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2025 08:33:21.7453
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 8082e965-9efd-48e2-9835-08dd403f9707
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:
	DB1PEPF000509F3.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB10269

Hi Ayan,

> On 14 Jan 2025, at 20:50, Ayan Kumar Halder <ayan.kumar.halder@amd.com> w=
rote:
>=20
> We have written the requirements for some of the commands of the XEN_VERS=
ION
> hypercall.
>=20
> Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
> ---
> .../design-reqs/arm64/version_hypercall.rst   | 33 ++++++++
> .../reqs/design-reqs/version_hypercall.rst    | 65 +++++++++++++++
> docs/fusa/reqs/index.rst                      |  2 +
> .../reqs/product-reqs/version_hypercall.rst   | 82 +++++++++++++++++++
> 4 files changed, 182 insertions(+)
> create mode 100644 docs/fusa/reqs/design-reqs/arm64/version_hypercall.rst
> create mode 100644 docs/fusa/reqs/design-reqs/version_hypercall.rst
>=20
> diff --git a/docs/fusa/reqs/design-reqs/arm64/version_hypercall.rst b/doc=
s/fusa/reqs/design-reqs/arm64/version_hypercall.rst
> new file mode 100644
> index 0000000000..1dad2b84c2
> --- /dev/null
> +++ b/docs/fusa/reqs/design-reqs/arm64/version_hypercall.rst
> @@ -0,0 +1,33 @@
> +.. SPDX-License-Identifier: CC-BY-4.0
> +
> +Capabilities
> +------------
> +
> +`XenSwdgn~arm64_capabilities~1`
> +
> +Description:
> +Xen shall have a internal constant string storing "xen-3.0-aarch64".

I would rather not have a requirement that will need changing every time.
Could we turn this into a description and link this to where we store the v=
ersion ?

> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenProd~version_hyp_capabilities_cmd~1`
> +
> +Capabilities AArch32
> +--------------------
> +
> +`XenSwdgn~arm64_capabilities_aarch32~1`
> +
> +Description:
> +Xen shall have a internal constant string storing "xen-3.0-armv7l" when =
it
> +detects that the cpu is running in AArch32 mode.
> +

Same here and also you have a "when" here and not in previous one.

> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenProd~version_hyp_capabilities_cmd~1`
> +
> diff --git a/docs/fusa/reqs/design-reqs/version_hypercall.rst b/docs/fusa=
/reqs/design-reqs/version_hypercall.rst
> new file mode 100644
> index 0000000000..8bb7a66576
> --- /dev/null
> +++ b/docs/fusa/reqs/design-reqs/version_hypercall.rst
> @@ -0,0 +1,65 @@
> +.. SPDX-License-Identifier: CC-BY-4.0
> +
> +Version
> +-------
> +
> +`XenSwdgn~version~1`
> +
> +Description:
> +Xen shall have a internal constant storing the version number coming fro=
m the
> +Makefile.

If you go this far i think you should give the name of the constant.

> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenProd~version_hyp_version_cmd~1`
> +
> +Subversion
> +----------
> +
> +`XenSwdgn~subversion~1`
> +
> +Description:
> +Xen shall have a internal constant storing the sub version number coming=
 from
> +the Makefile.

Same here, please name it.

> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenProd~version_hyp_version_cmd~1`
> +
> +Extraversion
> +------------
> +
> +`XenSwdgn~extraversion~1`
> +
> +Description:
> +Xen shall have a internal constant string storing the extraversion comin=
g from
> +the build environment.

Same here.

> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenProd~version_hyp_extraversion_cmd~1`
> +
> +Changeset
> +---------
> +
> +`XenSwdgn~changeset~1`
> +
> +Description:
> +Xen shall have a internal constant string storing the date, time and git=
 hash
> +of the last change made to Xen's codebase.

Same here.
Also i would use the comment here and in previous reqs to give an example.

> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenProd~version_hyp_changeset_cmd~1`
> diff --git a/docs/fusa/reqs/index.rst b/docs/fusa/reqs/index.rst
> index d8683edce7..b85af19d19 100644
> --- a/docs/fusa/reqs/index.rst
> +++ b/docs/fusa/reqs/index.rst
> @@ -14,3 +14,5 @@ Requirements documentation
>    design-reqs/arm64/generic-timer
>    design-reqs/arm64/sbsa-uart
>    design-reqs/arm64/hypercall
> +   design-reqs/arm64/version_hypercall
> +   design-reqs/version_hypercall
> diff --git a/docs/fusa/reqs/product-reqs/version_hypercall.rst b/docs/fus=
a/reqs/product-reqs/version_hypercall.rst
> index fdb8da04e1..10bc7b6e87 100644
> --- a/docs/fusa/reqs/product-reqs/version_hypercall.rst
> +++ b/docs/fusa/reqs/product-reqs/version_hypercall.rst
> @@ -59,3 +59,85 @@ Covers:
> Needs:
>  - XenSwdgn
>=20
> +Version command
> +---------------
> +
> +`XenProd~version_hyp_version_cmd~1`
> +
> +Description:
> +Xen shall provide a command (num 0) for  hypercall (num 17) to retrieve =
Xen's
> +version in the domain's x0 register.

Somehow you will need a req saying that how and hypercall is specified in g=
eneral
and then one req per hypercall:
Xen hypercall number 0  shall return the Xen version in register 0.
I would also prevent saying x0 which would make this aarch64 specific.

> +
> +Rationale:
> +
> +Comments:
> +Xen version is composed of major and minor number.

Can't we link to the requirement defining where the version is stored ?

> +
> +Covers:
> + - `XenMkt~version_hypercall~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +Extraversion command
> +--------------------
> +
> +`XenProd~version_hyp_extraversion_cmd~1`
> +
> +Description:
> +Xen shall provide a command (num 1) for hypercall (num 17) to copy its
> +extraversion in the domain's buffer.
> +
> +Rationale:
> +
> +Comments:
> +Xen's extra version consists of a string passed with 'XEN_VENDORVERSION'=
 command
> +line parameter while building Xen.
> +
> +Covers:
> + - `XenMkt~version_hypercall~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +Capabilities command
> +--------------------
> +
> +`XenProd~version_hyp_capabilities_cmd~1`
> +
> +Description:
> +Xen shall provide a command (num 3) for hypercall (num 17) to copy its
> +capabilities to the domain's buffer.
> +
> +Rationale:
> +
> +Comments:
> +Capabilities related information is represented by char[1024].
> +For Arm64, the capabilities should contain "xen-3.0-aarch64" string.
> +
> +Covers:
> + - `XenMkt~version_hypercall~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +Changeset command
> +-----------------
> +
> +`XenProd~version_hyp_changeset_cmd~1`
> +
> +Description:
> +Xen shall provide a command (num 4) for hypercall (num 17) to copy chang=
eset
> +to the domain's buffer.
> +
> +Rationale:
> +
> +Comments:
> +Changeset is string denoting the date, time and git hash of the last cha=
nge
> +made to Xen's codebase.
> +
> +Covers:
> + - `XenMkt~version_hypercall~1`
> +
> +Needs:
> + - XenSwdgn
> --=20
> 2.25.1
>=20

Cheers
Bertrand




From xen-devel-bounces@lists.xenproject.org Wed Jan 29 08:36:50 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 08:36:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878954.1289161 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td3Z3-0003iv-Ms; Wed, 29 Jan 2025 08:36:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878954.1289161; Wed, 29 Jan 2025 08:36:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td3Z3-0003io-KH; Wed, 29 Jan 2025 08:36:49 +0000
Received: by outflank-mailman (input) for mailman id 878954;
 Wed, 29 Jan 2025 08:36: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
 <SRS0=StUP=UV=linuxfoundation.org=gregkh@srs-se1.protection.inumbo.net>)
 id 1td3Z2-0003ii-Bs
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 08:36:48 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2c655b58-de1c-11ef-a0e6-8be0dac302b0;
 Wed, 29 Jan 2025 09:36:46 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 65540A4162B;
 Wed, 29 Jan 2025 08:34:58 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 61FABC4CED3;
 Wed, 29 Jan 2025 08:36:44 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2c655b58-de1c-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org;
	s=korg; t=1738139804;
	bh=VW2r6/JfcXBwlJAM+bj3qoZydV8ADfVuANDZWaGlq1k=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=L0Szo1OP12RiVurJQJGyYYgqz6jPTKmhBt+YSI0rGbppuJQsW0C73y5fq1TtdVjv/
	 2/Jiy69mXaiswLMODjxzA/Ztcwsldv26K2UY920wT3S6CPdVh7lu21ptcTlJrqdeqt
	 b1rezmUmtUpPfyx6LBojtI0hxPdT+u8aG50sNHXU=
Date: Wed, 29 Jan 2025 09:35:44 +0100
From: Greg KH <gregkh@linuxfoundation.org>
To: Harshvardhan Jha <harshvardhan.j.jha@oracle.com>
Cc: Konrad Wilk <konrad.wilk@oracle.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	"jgross@suse.com" <jgross@suse.com>,
	"sstabellini@kernel.org" <sstabellini@kernel.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>,
	stable@vger.kernel.org
Subject: Re: v5.4.289 failed to boot with error megasas_build_io_fusion 3219
 sge_count (-12) is out of range
Message-ID: <2025012919-series-chaps-856e@gregkh>
References: <7dc143fa-4a48-440b-b624-ac57a361ac74@oracle.com>
 <9dd91f6e-1c66-4961-994e-dbda87d69dad@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9dd91f6e-1c66-4961-994e-dbda87d69dad@oracle.com>

On Wed, Jan 29, 2025 at 02:03:51PM +0530, Harshvardhan Jha wrote:
> Hi All,
> 
> +stable
> 
> There seems to be some formatting issues in my log output. I have
> attached it as a file.

Confused, what are you wanting us to do here in the stable tree?

thanks,

greg k-h


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 08:49:32 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 08:49:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878963.1289172 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td3lD-0005Xd-RX; Wed, 29 Jan 2025 08:49:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878963.1289172; Wed, 29 Jan 2025 08:49:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td3lD-0005XW-N5; Wed, 29 Jan 2025 08:49:23 +0000
Received: by outflank-mailman (input) for mailman id 878963;
 Wed, 29 Jan 2025 08:49: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
 <SRS0=vr49=UV=kernel.org=joel.granados@srs-se1.protection.inumbo.net>)
 id 1td3lC-0005XQ-Qv
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 08:49:22 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ed8f5395-de1d-11ef-99a4-01e77a169b0f;
 Wed, 29 Jan 2025 09:49:20 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 631165C027D;
 Wed, 29 Jan 2025 08:48:38 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id AAFA1C4CED3;
 Wed, 29 Jan 2025 08:49:17 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ed8f5395-de1d-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1738140558;
	bh=bkecGghn49Q0kcBr4/Q4RAYEqTU2lzStxg+kMBkUviM=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=D+6QRnebTmdCsTn/fBIyawZ8F2h5FOi1VkBceKjrJE9gQqYhsE4MpI+DUnmOyvn9r
	 jy2STn2XFJrPEPFrh+vO/ZWYbctxdvY6UR3Ry6YZK+y8a1MhcK6ynlBs1p1BMMkJ1P
	 w6gLTDQPv35AYJJgnh4TzBlS6e9ascDPFne+p1YDjEpGVHG5PR2AxRH9J1o9Q9BPKi
	 anvTB+Oa86UvplOCcaBDT4qhHCCSJO/P11ip4o+2DBjUNcnkNIz/KxsEnezLq+wofc
	 pmlKCTkKHhEdUE5jBQ13DTAnVV4ZlV/QW5dr1RzqeBZB57C+fkYnuuFh6jqnxMpijz
	 QxNX1fm0X2YKQ==
Date: Wed, 29 Jan 2025 09:49:13 +0100
From: Joel Granados <joel.granados@kernel.org>
To: Paul Moore <paul@paul-moore.com>
Cc: Matthew Wilcox <willy@infradead.org>, 
	Jani Nikula <jani.nikula@intel.com>, Ard Biesheuvel <ardb@kernel.org>, 
	Alexander Gordeev <agordeev@linux.ibm.com>, Thomas =?utf-8?Q?Wei=C3=9Fschuh?= <linux@weissschuh.net>, 
	Kees Cook <kees@kernel.org>, Luis Chamberlain <mcgrof@kernel.org>, 
	linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, 
	linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-crypto@vger.kernel.org, 
	openipmi-developer@lists.sourceforge.net, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, 
	intel-xe@lists.freedesktop.org, linux-hyperv@vger.kernel.org, linux-rdma@vger.kernel.org, 
	linux-raid@vger.kernel.org, linux-scsi@vger.kernel.org, linux-serial@vger.kernel.org, 
	xen-devel@lists.xenproject.org, linux-aio@kvack.org, linux-fsdevel@vger.kernel.org, 
	netfs@lists.linux.dev, codalist@coda.cs.cmu.edu, linux-mm@kvack.org, 
	linux-nfs@vger.kernel.org, ocfs2-devel@lists.linux.dev, fsverity@lists.linux.dev, 
	linux-xfs@vger.kernel.org, io-uring@vger.kernel.org, bpf@vger.kernel.org, 
	kexec@lists.infradead.org, linux-trace-kernel@vger.kernel.org, 
	linux-hardening@vger.kernel.org, apparmor@lists.ubuntu.com, linux-security-module@vger.kernel.org, 
	keyrings@vger.kernel.org, Song Liu <song@kernel.org>, 
	"Steven Rostedt (Google)" <rostedt@goodmis.org>, "Martin K. Petersen" <martin.petersen@oracle.com>, 
	"Darrick J. Wong" <djwong@kernel.org>, Corey Minyard <cminyard@mvista.com>
Subject: Re: Re: Re: Re: Re: [PATCH v2] treewide: const qualify ctl_tables
 where applicable
Message-ID: <umk5gfo7iq7krppvqsal57hlzds26bdqd3g7kccjzuudjikdws@k2oknd6zx6g7>
References: <20250110-jag-ctl_table_const-v2-1-0000e1663144@kernel.org>
 <Z4+jwDBrZNRgu85S@li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com>
 <nslqrapp4v3rknjgtfk4cg64ha7rewrrg24aslo2e5jmxfwce5@t4chrpuk632k>
 <CAMj1kXEZPe8zk7s67SADK9wVH3cfBup-sAZSC6_pJyng9QT7aw@mail.gmail.com>
 <f4lfo2fb7ajogucsvisfd5sg2avykavmkizr6ycsllcrco4mo3@qt2zx4zp57zh>
 <87jzag9ugx.fsf@intel.com>
 <Z5epb86xkHQ3BLhp@casper.infradead.org>
 <u2fwibsnbfvulxj6adigla6geiafh2vuve4hcyo4vmeytwjl7p@oz6xonrq5225>
 <CAHC9VhQnB_bsQaezBfAcA0bE7Zoc99QXrvO1qjpHA-J8+_doYg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAHC9VhQnB_bsQaezBfAcA0bE7Zoc99QXrvO1qjpHA-J8+_doYg@mail.gmail.com>

On Tue, Jan 28, 2025 at 10:43:10AM -0500, Paul Moore wrote:
> On Tue, Jan 28, 2025 at 6:22 AM Joel Granados <joel.granados@kernel.org> wrote:
> > On Mon, Jan 27, 2025 at 03:42:39PM +0000, Matthew Wilcox wrote:
> > > On Mon, Jan 27, 2025 at 04:55:58PM +0200, Jani Nikula wrote:
> > > > You could have static const within functions too. You get the rodata
> > > > protection and function local scope, best of both worlds?
> > >
> > > timer_active is on the stack, so it can't be static const.
> > >
> > > Does this really need to be cc'd to such a wide distribution list?
> > That is a very good question. I removed 160 people from the original
> > e-mail and left the ones that where previously involved with this patch
> > and left all the lists for good measure. But it seems I can reduce it
> > even more.
> >
> > How about this: For these treewide efforts I just leave the people that
> > are/were involved in the series and add two lists: linux-kernel and
> > linux-hardening.
> >
> > Unless someone screams, I'll try this out on my next treewide.
> 
> I'm not screaming about it :) but anything that touches the LSM,
I'll consider it as a scream :) So I'll keep my previous approach of
leaving only personal mails that are involved, but leaving all the lists
that b4 suggests.

> SELinux, or audit code (or matches the regex in MAINTAINERS) I would
> prefer to see on the associated mailing list.

General comment sent to the void:
It is tricky to know exactly who wants to be informed of all this and
who thinks its useless. I think that if we want more focus it should
come from automated tools like b4. Maybe some string in MAINTAINERS
stating that the list should not be used in cases of tree-wide commits?

Best

-- 

Joel Granados


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 08:50:03 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 08:50:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878971.1289180 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td3lr-0006M5-2N; Wed, 29 Jan 2025 08:50:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878971.1289180; Wed, 29 Jan 2025 08:50:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td3lq-0006Lb-Ve; Wed, 29 Jan 2025 08:50:02 +0000
Received: by outflank-mailman (input) for mailman id 878971;
 Wed, 29 Jan 2025 08:50:02 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=StUP=UV=linuxfoundation.org=gregkh@srs-se1.protection.inumbo.net>)
 id 1td3lp-0005XQ-UN
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 08:50:01 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org
 [2604:1380:4641:c500::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0559ed26-de1e-11ef-99a4-01e77a169b0f;
 Wed, 29 Jan 2025 09:50:00 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id CAE685C42ED;
 Wed, 29 Jan 2025 08:49:18 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2D271C4CED3;
 Wed, 29 Jan 2025 08:49:57 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 0559ed26-de1e-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org;
	s=korg; t=1738140598;
	bh=GhtbiGXAup2zSnK0rTNOp5a0088ODKNAXoLr5CdWgrA=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=QZgZiXRb8ap7vkF6yA3fGyQ+a/CORYegw0QExaxrp3QikHRLBEFtCRYB4a3SwePop
	 nWbU5xcupYn/XEUHd7N67uhsd58DvR6ngNJ/RJJZuRGJSoAdqUT8vFzsZxA8mkHGnq
	 HJ1tu7EgMVeJwWwF8qYF/7LqnjjzJ+toAcKVtnIw=
Date: Wed, 29 Jan 2025 09:48:58 +0100
From: Greg KH <gregkh@linuxfoundation.org>
To: Harshvardhan Jha <harshvardhan.j.jha@oracle.com>
Cc: Konrad Wilk <konrad.wilk@oracle.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	"jgross@suse.com" <jgross@suse.com>,
	"sstabellini@kernel.org" <sstabellini@kernel.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>,
	stable@vger.kernel.org
Subject: Re: v5.4.289 failed to boot with error megasas_build_io_fusion 3219
 sge_count (-12) is out of range
Message-ID: <2025012936-finalize-ducktail-c524@gregkh>
References: <7dc143fa-4a48-440b-b624-ac57a361ac74@oracle.com>
 <9dd91f6e-1c66-4961-994e-dbda87d69dad@oracle.com>
 <2025012919-series-chaps-856e@gregkh>
 <8eb33b38-23e1-4e43-8952-3f2b05660236@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8eb33b38-23e1-4e43-8952-3f2b05660236@oracle.com>

On Wed, Jan 29, 2025 at 02:13:34PM +0530, Harshvardhan Jha wrote:
> Hi there,
> 
> On 29/01/25 2:05 PM, Greg KH wrote:
> > On Wed, Jan 29, 2025 at 02:03:51PM +0530, Harshvardhan Jha wrote:
> >> Hi All,
> >>
> >> +stable
> >>
> >> There seems to be some formatting issues in my log output. I have
> >> attached it as a file.
> > Confused, what are you wanting us to do here in the stable tree?
> >
> > thanks,
> >
> > greg k-h
> 
> Since, this is reproducible on 5.4.y I have added stable. The culprit
> commit which upon getting reverted fixes this issue is also present in
> 5.4.y stable.

What culprit commit?  I see no information here :(

Remember, top-posting is evil...


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 08:52:26 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 08:52:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878980.1289190 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td3o9-0007tV-ED; Wed, 29 Jan 2025 08:52:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878980.1289190; Wed, 29 Jan 2025 08:52:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td3o9-0007tO-Ba; Wed, 29 Jan 2025 08:52:25 +0000
Received: by outflank-mailman (input) for mailman id 878980;
 Wed, 29 Jan 2025 08:52:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=1peA=UV=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1td3o7-0007tI-Mv
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 08:52:23 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5a36e3f7-de1e-11ef-99a4-01e77a169b0f;
 Wed, 29 Jan 2025 09:52:21 +0100 (CET)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-aaef00ab172so1027677066b.3
 for <xen-devel@lists.xenproject.org>; Wed, 29 Jan 2025 00:52: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
 4fb4d7f45d1cf-5dc1862a17fsm8250164a12.32.2025.01.29.00.52.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 29 Jan 2025 00:52:20 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5a36e3f7-de1e-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738140741; x=1738745541; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=1FjJv8LxnyC91YV2RXnmbiwBUqJEBc/JvrKRu50A8S8=;
        b=Sn6Y0J0euGuw6wS1udDdNVRXOGsWaEBsJn+xh/HBbrOro7fFHmoanPIhApyygKHmRQ
         efOxQqdGgPE87C8zQLGZTTOVsLXdVAej1gHBR9WlHZomfw4y30QFyOYZ2DYk37fMN4I9
         EVc/Lo7Syxm+EsftP4rSFesljZn5m9dstLOHxyGiB7PcOxWaww81zigZnIPZ4cS3SykK
         0JEFGy9wAMRsZCn7zoFjZ/FrqJ8WYe6NXMg+UO/9wKLL5dENt2gNmg7Z2TKG8/4Cnh/x
         xxrq82Uexe8PTNq6TmaZO2xOHyZBKUUh73S8mD7k4VPRgkijK6Z83IRHVn78fIazpX64
         Pppw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738140741; x=1738745541;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=1FjJv8LxnyC91YV2RXnmbiwBUqJEBc/JvrKRu50A8S8=;
        b=BnJAUCSAqpVCQtiHWxYLidjia4BQac2y7G6nQqaOXMNRWqWTLbu5LWV9pPLyyq2/o3
         FkU7H2T6HIaVIiKHLO2dlgQaNeJx+isDqT7of3trliIWfvFlAyhemVRvhM31/b2v0Lt9
         vABakyLQWDpH4UGUm09t3lawLwT0adPObei2cdVyQ7Pmc5tbF9lzrAMDsy/Z4mZN1+oT
         +ZSnaO/lfGRTU2HO6iXE/cWQgXAlvga/Yqqp/LvlTjiPWW+ai7ZGIj86XjdkVXkT1VoL
         09D7GnrZ84oOXm3k8wp6BZcItzZjp6W9I/Va98iyxA6lDaEdM//ASBXKBvxV8z1F2BXi
         E+6w==
X-Forwarded-Encrypted: i=1; AJvYcCW6S+wzYYmiQLLJxNxtVcjp179+TDy6gQvgJ23Mr7F/vRxkq7PwQSAva7djAryYlTFSMf8Y8vfMMhs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyVgeg6CkussoDZB07e6dRudlF+2R+v7PbFdjU7+CqrnbZch8yL
	Je3OKpisyPMaFU7jiptDP1mmrlNyaKGPIUHBgJ/HLRyUJLjZx8qxjfQhcXYO5g==
X-Gm-Gg: ASbGnctJy/QFD+5fSjtQxq/SqSXqy5idOfWqoPnBMW+oC8U2fcHhfrMvbjNv7xgQmHL
	29EwyDImVrNnNfDanY223JP/maXiRiDCUYnOqAjog2VOMCpoVejMl/FoqlGpaBAKjaYZXI+NfPl
	Kj7WFyCDeaA57bmu2FQZzk57X/2vt9rou9o3COf5RZgYKiPT60ukeLuA3knFHsW+8nGruSeKISQ
	yqnwUS4rCZxfT3zYQzj0py27AlgS8mxyexqAmLi8Bp3/kW+WdvqV+Pm1QeqJy3OdNYM/+x6ivFX
	Xg+tX8paEWoXclGbe+PZYphzcgIFFYEN+N1lRxjtlel49L9ryx5qRxAurdpoASjivjpa3T5cCdF
	C
X-Google-Smtp-Source: AGHT+IHqmcQIv8Oj2TLFZzf88JzYvO2YhukeD3JjUobhf7Rp9YDnQ9fmLYcs5B2IAHLODMHQQV6D8A==
X-Received: by 2002:a05:6402:90d:b0:5dc:58c8:3154 with SMTP id 4fb4d7f45d1cf-5dc5effe4bfmr5817441a12.28.1738140740988;
        Wed, 29 Jan 2025 00:52:20 -0800 (PST)
Message-ID: <b4ccccbb-f3ee-44fe-a5e2-780195cbbc0e@suse.com>
Date: Wed, 29 Jan 2025 09:52:19 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: slow start of Pod HVM domU with qemu 9.1
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xenproject.org,
 jgross@suse.com, Anthony PERARD <anthony@xenproject.org>,
 Paul Durrant <paul@xen.org>, andrew.cooper3@citrix.com,
 roger.pau@citrix.com, "Edgar E. Iglesias" <edgar.iglesias@amd.com>
References: <20250128151544.26fc827d.olaf@aepfle.de> <Z5j-bkdFZ7riavv7@zapote>
 <alpine.DEB.2.22.394.2501281543580.3264561@ubuntu-linux-20-04-desktop>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <alpine.DEB.2.22.394.2501281543580.3264561@ubuntu-linux-20-04-desktop>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 29.01.2025 00:58, Stefano Stabellini wrote:
> On Tue, 28 Jan 2025, Edgar E. Iglesias wrote:
>> On Tue, Jan 28, 2025 at 03:15:44PM +0100, Olaf Hering wrote:
>>> With this change the domU starts fast again:
>>>
>>> --- a/hw/xen/xen-mapcache.c
>>> +++ b/hw/xen/xen-mapcache.c
>>> @@ -522,6 +522,7 @@ ram_addr_t xen_ram_addr_from_mapcache(void *ptr)
>>>      ram_addr_t addr;
>>>  
>>>      addr = xen_ram_addr_from_mapcache_single(mapcache, ptr);
>>> +    if (1)
>>>      if (addr == RAM_ADDR_INVALID) {
>>>          addr = xen_ram_addr_from_mapcache_single(mapcache_grants, ptr);
>>>      }
>>> @@ -626,6 +627,7 @@ static void xen_invalidate_map_cache_entry_single(MapCache *mc, uint8_t *buffer)
>>>  static void xen_invalidate_map_cache_entry_all(uint8_t *buffer)
>>>  {
>>>      xen_invalidate_map_cache_entry_single(mapcache, buffer);
>>> +    if (1)
>>>      xen_invalidate_map_cache_entry_single(mapcache_grants, buffer);
>>>  }
>>>  
>>> @@ -700,6 +702,7 @@ void xen_invalidate_map_cache(void)
>>>      bdrv_drain_all();
>>>  
>>>      xen_invalidate_map_cache_single(mapcache);
>>> +    if (0)
>>>      xen_invalidate_map_cache_single(mapcache_grants);
>>>  }
>>>  
>>> I did the testing with libvirt, the domU.cfg equivalent looks like this:
>>> maxmem = 4096
>>> memory = 2048
>>> maxvcpus = 4
>>> vcpus = 2
>>> pae = 1
>>> acpi = 1
>>> apic = 1
>>> viridian = 0
>>> rtc_timeoffset = 0
>>> localtime = 0
>>> on_poweroff = "destroy"
>>> on_reboot = "destroy"
>>> on_crash = "destroy"
>>> device_model_override = "/usr/lib64/qemu-9.1/bin/qemu-system-i386"
>>> sdl = 0
>>> vnc = 1
>>> vncunused = 1
>>> vnclisten = "127.0.0.1"
>>> vif = [ "mac=52:54:01:23:63:29,bridge=br0,script=vif-bridge" ]
>>> parallel = "none"
>>> serial = "pty"
>>> builder = "hvm"
>>> kernel = "/bug1236329/linux"
>>> ramdisk = "/bug1236329/initrd"
>>> cmdline = "console=ttyS0,115200n8 quiet ignore_loglevel""
>>> boot = "c" 
>>> disk = [ "format=qcow2,vdev=hda,access=rw,backendtype=qdisk,target=/bug1236329/sles12sp5.qcow2" ]
>>> usb = 1
>>> usbdevice = "tablet"
>>>
>>> Any idea what can be done to restore boot times?
>>
>>
>> A guess is that it's taking a long time to walk the grants mapcache
>> when invalidating (in QEMU). Despite it being unused and empty. We
>> could try to find a way to keep track of usage and do nothing when
>> invalidating an empty/unused cache.
> 
> If mapcache_grants is unused and empty, the call to
> xen_invalidate_map_cache_single(mapcache_grants) should be really fast?
> 
> I think probably it might be the opposite: mapcache_grants is utilized,
> so going through all the mappings in xen_invalidate_map_cache_single
> takes time.
> 
> However, I wonder if it is really needed. At least in the PoD case, the
> reason for the IOREQ_TYPE_INVALIDATE request is that the underlying DomU
> memory has changed. But that doesn't affect the grant mappings, because
> those are mappings of other domains' memory.
> 
> So I am thinking whether we should remove the call to
> xen_invalidate_map_cache_single(mapcache_grants) ?
> 
> Adding x86 maintainers: do we need to flush grant table mappings for the
> PV backends running in QEMU when Xen issues a IOREQ_TYPE_INVALIDATE
> request to QEMU?

Judging from two of the three uses of ioreq_request_mapcache_invalidate()
in x86'es p2m.c, I'd say no. The 3rd use there is unconditional, but
maybe wrongly so.

However, the answer also depends on what qemu does when encountering a
granted page. Would it enter it into its mapcache? Can it even access it?
(If it can't, how does emulated I/O work to such pages? If it can, isn't
this a violation of the grant's permissions, as it's targeted at solely
the actual HVM domain named in the grant?)

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 09:05:59 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 09:05:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878991.1289200 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td416-0001Z2-If; Wed, 29 Jan 2025 09:05:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878991.1289200; Wed, 29 Jan 2025 09:05:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td416-0001Yv-G8; Wed, 29 Jan 2025 09:05:48 +0000
Received: by outflank-mailman (input) for mailman id 878991;
 Wed, 29 Jan 2025 09:05: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
 <SRS0=StUP=UV=linuxfoundation.org=gregkh@srs-se1.protection.inumbo.net>)
 id 1td414-0001Yp-U7
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 09:05:46 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org
 [2604:1380:4641:c500::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 389dfc98-de20-11ef-a0e6-8be0dac302b0;
 Wed, 29 Jan 2025 10:05:45 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 742495C48A3;
 Wed, 29 Jan 2025 09:05:03 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id C399BC4CED3;
 Wed, 29 Jan 2025 09:05:42 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 389dfc98-de20-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org;
	s=korg; t=1738141543;
	bh=Q8NTuhBVqnZu5kUxXuIu5wikBIqX+rWJ1J0b9mlGgGE=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=HwSqS6pTrgoxlJiBbX+fZakG7xzd9gx26HZ1WYoFZl0HN9I4vywpeEAPemr5T9CRk
	 xcFmQEONNIsrn5jdlXSd2TuDLk/uWYa8kIk/YbltsUB89XKqggvF7zXXaYQNc6DF8M
	 jR1nYuZ6v3XIEFgLvAHZsy0W0MvyoLlkN4+Aa9Vo=
Date: Wed, 29 Jan 2025 10:04:34 +0100
From: Greg KH <gregkh@linuxfoundation.org>
To: Harshvardhan Jha <harshvardhan.j.jha@oracle.com>
Cc: Konrad Wilk <konrad.wilk@oracle.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	"jgross@suse.com" <jgross@suse.com>,
	"sstabellini@kernel.org" <sstabellini@kernel.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>,
	stable@vger.kernel.org
Subject: Re: v5.4.289 failed to boot with error megasas_build_io_fusion 3219
 sge_count (-12) is out of range
Message-ID: <2025012956-jiffy-condone-3137@gregkh>
References: <7dc143fa-4a48-440b-b624-ac57a361ac74@oracle.com>
 <9dd91f6e-1c66-4961-994e-dbda87d69dad@oracle.com>
 <2025012919-series-chaps-856e@gregkh>
 <8eb33b38-23e1-4e43-8952-3f2b05660236@oracle.com>
 <2025012936-finalize-ducktail-c524@gregkh>
 <1f017284-1a29-49d8-b0d9-92409561990e@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1f017284-1a29-49d8-b0d9-92409561990e@oracle.com>

On Wed, Jan 29, 2025 at 02:29:48PM +0530, Harshvardhan Jha wrote:
> Hi Greg,
> 
> On 29/01/25 2:18 PM, Greg KH wrote:
> > On Wed, Jan 29, 2025 at 02:13:34PM +0530, Harshvardhan Jha wrote:
> >> Hi there,
> >>
> >> On 29/01/25 2:05 PM, Greg KH wrote:
> >>> On Wed, Jan 29, 2025 at 02:03:51PM +0530, Harshvardhan Jha wrote:
> >>>> Hi All,
> >>>>
> >>>> +stable
> >>>>
> >>>> There seems to be some formatting issues in my log output. I have
> >>>> attached it as a file.
> >>> Confused, what are you wanting us to do here in the stable tree?
> >>>
> >>> thanks,
> >>>
> >>> greg k-h
> >> Since, this is reproducible on 5.4.y I have added stable. The culprit
> >> commit which upon getting reverted fixes this issue is also present in
> >> 5.4.y stable.
> > What culprit commit?  I see no information here :(
> >
> > Remember, top-posting is evil...
> 
> My apologies,
> 
> The stable tag v5.4.289 seems to fail to boot with the following prompt in an infinite loop:
> [   24.427217] megaraid_sas 0000:65:00.0: megasas_build_io_fusion 3273 sge_count (-12) is out of range. Range is:  0-256
> 
> Reverting the following patch seems to fix the issue:
> 
> stable-5.4����� : v5.4.285������������ - 5df29a445f3a xen/swiotlb: add
> alignment check for dma buffers
> 
> I tried changing swiotlb grub command line arguments but that didn't
> seem to help much unfortunately and the error was seen again.
> 

Ok, can you submit this revert with the information about why it should
not be included in the 5.4.y tree and cc: everyone involved and then we
will be glad to queue it up.

thanks,

greg k-h


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 09:17:32 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 09:17:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879003.1289210 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td4CK-0003i2-Kt; Wed, 29 Jan 2025 09:17:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879003.1289210; Wed, 29 Jan 2025 09:17:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td4CK-0003hv-ID; Wed, 29 Jan 2025 09:17:24 +0000
Received: by outflank-mailman (input) for mailman id 879003;
 Wed, 29 Jan 2025 09:17: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 <SRS0=1peA=UV=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1td4CJ-0003hp-KJ
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 09:17:23 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d8e2ecf1-de21-11ef-a0e6-8be0dac302b0;
 Wed, 29 Jan 2025 10:17:22 +0100 (CET)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-aaf0f1adef8so1150401766b.3
 for <xen-devel@lists.xenproject.org>; Wed, 29 Jan 2025 01:17: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
 a640c23a62f3a-ab6924486dbsm692004966b.161.2025.01.29.01.17.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 29 Jan 2025 01:17:21 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: d8e2ecf1-de21-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738142242; x=1738747042; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=jY3VwszcUmlCwbph4D/VlW+dI7fVI6uIXSglAodg90E=;
        b=dOW9zKvTFdHogDvKgJCXu0LTDXuCYS0sbStx+C1Ou1s3xXPw+lrdc30bBtir/R1CwT
         Uh5oCKTNo0BqThEHH0VXjTODj6Na2mMrWAHVR8ZocbMz++nS7TV//hk+ZO6zHF2tfwJ7
         vZBi1/8cRW3lAsJmiIeDl2tZc+0XeLFa1YLv1/I5xY9Fn47y+fYHmC9RpIYJJGw1JmZG
         UcHkkU1MR0bwwNhzfMtkSyGlVk/yzh5lEGH+YQdj+l66qMO8dKd7sXZ2efduIoRG9yem
         IkV0K81fZzfvaW2DhcgwktC3Ocf/4JeMxTuFFHog2NF5olZhGBI72S7pANLp//RgdeVY
         y2OA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738142242; x=1738747042;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=jY3VwszcUmlCwbph4D/VlW+dI7fVI6uIXSglAodg90E=;
        b=wn8RuQMilIlymKKp0l8GXTEvnhhmiJqsxmKTHDvHQ7IoR9zraTYH6wlqrEICGx4M/o
         yv6sWTtEm2iBonWYTYOh4VnypNym5fHAnn2WQAxDtR0Bljy+xCsVG/spUXIhqmj3rrhB
         8MOhJnhks9kDi29a0GWVFO3UWKh06IncTOyrHnMyGpULRmc0p9mFJ1QPRWNKGGIp1VsP
         g6eNodTK8kg3LwqgDIJqoPQUx+qj7Nh1D6KkV1CViP2V9xGnZtYZBevGTv06P6O1h3UA
         68O19ii/ingMf78PzyJsRVcCSz/uhXTelAe0XVgr1lw9bztdIELHJtY/t6ikVBEDw8A9
         zYBA==
X-Forwarded-Encrypted: i=1; AJvYcCVGXQHCJv0t1JgJsZh4EcDpZozOdywmZwFqlzgc+GovP5aWBA7QSohnaeToNIrUEQPf5PZgmsNydOs=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy+ogiZy4XDW5+bkuBC+YGF7ltygJYIb/Sn0nAV2L4kFKOhCQxP
	cMmu8nVzuEXsH6FfRZ2eDXNLBRTdcOHqDnQxN2gb9HEKl8RpxM/5FgGaoJHcgg==
X-Gm-Gg: ASbGnculiuvNK3D8EXHGRIpz3lCB+iMOIU2aBwlzCBuJbfP5/vB5y7w3dwsy1gHXtsj
	gOTDxXbppD2xD7cazOiSBLjvaKXdRGQt/kp3VcM5RWaIOIyWHBlOQopRbCP/TAxOinKcQJtNAcO
	c/ABu0DEZ313tGl7UWJGooqP3OorQfxZ7hfOFkutaUA9NS9Oqppw3tB+I4ooRgT4fo5rbdY6lu0
	ZirSLHmuo3mM4Hm5UhT5FMOEZS4P9pipBIqMHzFFPn0PsF7Y4NUhaiPz706GAS5a1OvZQFFlNyk
	MEps3fuZH+44PvMbqD0P2bLmUFRXi4KsawavVFNJ0kcSxCqMuW/PstXenDbZzHhJduYajmTDRN9
	T
X-Google-Smtp-Source: AGHT+IEptWmgc2PdXVVMpz3zp4lAqX67/4R5WHHT7DJzrvchdkCI70dr1F0VPJ8pj8HJuAcJBfIasw==
X-Received: by 2002:a17:907:1c16:b0:ab6:330c:7af0 with SMTP id a640c23a62f3a-ab6cfcdf591mr214805266b.20.1738142242113;
        Wed, 29 Jan 2025 01:17:22 -0800 (PST)
Message-ID: <22ad7276-624d-49fb-a2bb-1b7908318a4e@suse.com>
Date: Wed, 29 Jan 2025 10:17:20 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Config space access to Mediatek MT7922 doesn't work after device
 reset in Xen PV dom0 (regression, Linux 6.12)
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>, =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?=
 <jgross@suse.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 xen-devel <xen-devel@lists.xenproject.org>, linux-kernel@vger.kernel.org,
 regressions@lists.linux.dev, Felix Fietkau <nbd@nbd.name>,
 Lorenzo Bianconi <lorenzo@kernel.org>, Ryder Lee <ryder.lee@mediatek.com>,
 linux-pci@vger.kernel.org, Bjorn Helgaas <helgaas@kernel.org>
References: <Z5mOKQUrgeF_r6te@mail-itl> <20250129030315.GA392478@bhelgaas>
 <Z5mfA32bvEn6yD-C@mail-itl>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <Z5mfA32bvEn6yD-C@mail-itl>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 29.01.2025 04:22, Marek Marczykowski-Górecki wrote:
> On Tue, Jan 28, 2025 at 09:03:15PM -0600, Bjorn Helgaas wrote:
>> The report claims the problem only happens with Xen.  I'm not a Xen
>> person, and I don't know how to find the relevant config accessors.
>> The snippets of kernel messages I see at [1] all mention pciback, so
>> that's my only clue of where to look.  Bottom line, I have no idea
>> what the config accessor path is, and maybe we could learn something
>> by looking at whatever it is.
> 
> AFAIK there are no separate config accessors under Xen dom0, the default
> ones are used. xen-pcifront takes over PCI config space access (and few
> more) only in a domU (and only for PV), when PCI passthrough is used.
> Here, it didn't went that far...
> 
> But then, Xen may intercept such access [2]. If I read it right, it
> should allow all access (is_hardware_domain(dom0)==true, and also the
> device is not on ro_map - otherwise reset wouldn't work at all).

The other day you mentioned (on Matrix I think) that you observe mmcfg
not being used on that system. Am I misremembering? (Since the capability
where the control bit lives is an extended one, that capability would
neither be read nor modified when mmcfg is unavailable.)

Jan



From xen-devel-bounces@lists.xenproject.org Wed Jan 29 10:13:27 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 10:13:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879014.1289220 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td54N-0004PH-Nf; Wed, 29 Jan 2025 10:13:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879014.1289220; Wed, 29 Jan 2025 10:13:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td54N-0004PA-L8; Wed, 29 Jan 2025 10:13:15 +0000
Received: by outflank-mailman (input) for mailman id 879014;
 Wed, 29 Jan 2025 10:13:13 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=1peA=UV=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1td54L-0004P4-Lk
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 10:13:13 +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 a4d6a173-de29-11ef-a0e6-8be0dac302b0;
 Wed, 29 Jan 2025 11:13:11 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-ab2bb0822a4so1283575466b.3
 for <xen-devel@lists.xenproject.org>; Wed, 29 Jan 2025 02:13:11 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab6d9bfe8afsm11264766b.170.2025.01.29.02.13.09
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 29 Jan 2025 02:13:10 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a4d6a173-de29-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738145591; x=1738750391; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=dilwzZLmL6ENvq+ua7V+MRhIZ8PixkwHoP0NVF7nR1Y=;
        b=VCaeQZpMYsH6fagukdzqZ585i11cg0d67ISk+Qgaz8BcH79EZ+5IKxXaB2HRk0TCG8
         UCjV0/1f07tqIRAW+5oDFIhfAo8ZAOzo3+DBRYrf5G8Z0Uu/YNIy1jpkHET1v3QuxLqx
         uPberGyxrKFHoBA3l3RgLUfQ87hezJi+/3AebPyQsD4+XjnnqKSjW8KOGLOmfZD2qBtE
         319ylQqM4E2z2qKsU6dlD4v03hwxAkCb0lXUYx4P7g/oSMl5AHfxEgFBPNsqMH2kl2UR
         DJdZspYrqLIM28of3Bs0Y8zmRQjftI3XnZreMmYigEuKpfTdf68XyHsiOYeugRGafv2R
         i9uA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738145591; x=1738750391;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=dilwzZLmL6ENvq+ua7V+MRhIZ8PixkwHoP0NVF7nR1Y=;
        b=b0kkcZmBhAhB0l5Q+0RtBENp4R2yFphkdflWt9s5AWbz90B49v1H1gdKfYdwf/8Q/B
         o7ZeeJre7soeemTGJd/GqbXimq+zrTkVKLFYn7ZVGwaa2xsxfpzzf8UOrB7MrsBF+DFq
         fbeZ9MyJ1yYXoXZobwfEJV/qRuMzWlpxRgjG5XhE8gLkAD40MB1rXwTHIiWTYR7f6mOj
         3jJbSiRNDfXR+bY9ZbSNu6hp8DtyJ/goya+n13yS3NcEsnqqVCwWjlb8mkZNHQzbky/W
         Dc+PVKerI4XPaxjWJaiKkgbDpsfWgpobgswl53/eO0zVeTF7FfyFxgIPNJFx38szw8a2
         9XaQ==
X-Forwarded-Encrypted: i=1; AJvYcCX/mYB2KLd1pqUHEB9xIVnjy8Q6EkYZtTb2VyDEC7/XdP8/NAyoP801Xe145W6a5iSQnfgzLANr0ns=@lists.xenproject.org
X-Gm-Message-State: AOJu0YySz/W1SBtxeOI5x0E6iyIa5vmmZdRO4C0nwBCGHHD76Eb5mVA5
	7Dk5IaRPsI++RsgvEhlfygkHt8zOf+jg0/MNCJ33XXjQCQdlEC8CjnZSZaG2Mg==
X-Gm-Gg: ASbGncv8WiXI3yCNCkQ3w9RBBFXlCt01BqETdQ+Sybg2mDkAjyF5q4fZNKz9/FoEva0
	3s08M1BuWf8OaxDZY2jrypO7aQQnAXGwJZ5RmatVzbhY/RlXnthqm1Id1QG7/soxbOLXuziwBcT
	/4X6WbbcPZVTahcPCm9E76wzha+ZkOdhWVycP1f+VyamYOa0kzGyqCFJQePKszLtEvDb4Aucex8
	G00weukdxH/MC5X8ZyeO9hq7opCXgpeXwH1yw3fF2M8gz9m+WdKzJk5NRUV0Tvhw6eNtK2NbZ+p
	Qn0OE3r419L0v5XQYtXsdkfH9opGjfUt/zewUr1Is64WS6yaOoHjOeqGAaR3CqmqxaXfbJBkigs
	4
X-Google-Smtp-Source: AGHT+IF4QIe+XNr/oYfnDUlpfDxewrC3a2lA6mEh6XMvW0iWkkdeY84eTQd6eTRDZucJVtDyhjfARQ==
X-Received: by 2002:a17:907:1c07:b0:aa6:834b:d136 with SMTP id a640c23a62f3a-ab6cfd10a0dmr269337866b.33.1738145590691;
        Wed, 29 Jan 2025 02:13:10 -0800 (PST)
Message-ID: <9673c95f-7ee6-461c-8678-46aeab55735a@suse.com>
Date: Wed, 29 Jan 2025 11:13:09 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20 1/2] x86/shutdown: quiesce devices ahead of AP
 shutdown
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <20250128162742.90431-1-roger.pau@citrix.com>
 <20250128162742.90431-2-roger.pau@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250128162742.90431-2-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 28.01.2025 17:27, Roger Pau Monne wrote:
> The current shutdown logic in smp_send_stop() will first disable the APs,
> and then attempt to disable (some) of the interrupt sources.
> 
> There are two issues with this approach; the first one being that MSI
> interrupt sources are not disabled, the second one is the APs are stopped
> before interrupts are disabled.  On AMD systems this can lead to the
> triggering of local APIC errors:
> 
> APIC error on CPU0: 00(08), Receive accept error
> 
> Such error message can be printed in a loop, thus blocking the system from
> rebooting.  I assume this loop is created by the error being triggered by
> the console interrupt, which is further triggered by the ESR reporting
> write to the console.
> 
> Intel SDM states:
> 
> "Receive Accept Error.
> 
> Set when the local APIC detects that the message it received was not
> accepted by any APIC on the APIC bus, including itself. Used only on P6
> family and Pentium processors."
> 
> So the error shouldn't trigger on any Intel CPU supported by Xen.
> 
> However AMD doesn't make such claims, and indeed the error is broadcasted
> to all local APIC when for example an interrupt targets a CPU that's
> offline.
> 
> To prevent the error from triggering, move the masking of IO-APIC pins
> ahead of stopping the APs.  Also introduce a new function that disables
> MSI and MSI-X on all PCI devices.  Remove the call to fixup_irqs() since
> there's no point in attempting to move interrupts: all sources will be
> either masked or disabled.
> 
> For the NMI crash path also call the newly introduced function, with the
> hope that disabling MSI and MSI-X will make it easier for the (possible)
> crash kernel to boot, as it could otherwise receive the same "Receive
> accept error" upon re-enabling interrupts.
> 
> Note that this will have the side-effect of preventing further IOMMU
> interrupts from being delivered, that's expected and at that point in the
> shutdown process no further interaction with the IOMMU should be relevant.

This is at most for AMD only. Shouldn't we similarly disable VT-d's
interrupt(s)? (It's only one right now, as we still don't use the QI
completion one.) Even for AMD I'm uncertain: It has separate
hw_irq_controller instances, and its set_iommu_interrupt_handler() is
custom as well. Will pci_disable_msi_all() really affect it? (Hmm,
yes, from amd_iommu_msi_enable() it looks like it will.)

> --- a/xen/arch/x86/msi.c
> +++ b/xen/arch/x86/msi.c
> @@ -1248,6 +1248,20 @@ void pci_cleanup_msi(struct pci_dev *pdev)
>      msi_free_irqs(pdev);
>  }
>  
> +static int cf_check disable_msi(struct pci_dev *pdev, void *arg)
> +{
> +    msi_set_enable(pdev, 0);
> +    msix_set_enable(pdev, 0);
> +
> +    return 0;
> +}
> +
> +void pci_disable_msi_all(void)
> +{
> +    /* Disable MSI and/or MSI-X on all devices. */
> +    pci_iterate_devices(disable_msi, NULL);
> +}

That's going to be all devices we know of. I.e. best effort only. Maybe
the comment should be adjusted to this effect.

> --- a/xen/arch/x86/smp.c
> +++ b/xen/arch/x86/smp.c
> @@ -358,14 +358,15 @@ void smp_send_stop(void)
>  {
>      unsigned int cpu = smp_processor_id();
>  
> +    local_irq_disable();
> +    disable_IO_APIC();
> +    pci_disable_msi_all();
> +    local_irq_enable();
> +
>      if ( num_online_cpus() > 1 )
>      {
>          int timeout = 10;
>  
> -        local_irq_disable();
> -        fixup_irqs(cpumask_of(cpu), 0);
> -        local_irq_enable();
> -
>          smp_call_function(stop_this_cpu, NULL, 0);
>  
>          /* Wait 10ms for all other CPUs to go offline. */
> @@ -376,7 +377,6 @@ void smp_send_stop(void)
>      if ( cpu_online(cpu) )
>      {
>          local_irq_disable();
> -        disable_IO_APIC();
>          hpet_disable();

Like IOMMUs, HPET also has custom interrupt management. I think this
call needs pulling up, too (much like it is also there in
nmi_shootdown_cpus()).

> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -1803,6 +1803,38 @@ int iommu_do_pci_domctl(
>      return ret;
>  }
>  
> +struct segment_iter {
> +    int (*handler)(struct pci_dev *pdev, void *arg);
> +    void *arg;
> +};
> +
> +static int cf_check iterate_all(struct pci_seg *pseg, void *arg)
> +{
> +    const struct segment_iter *iter = arg;
> +    struct pci_dev *pdev;
> +
> +    list_for_each_entry ( pdev, &pseg->alldevs_list, alldevs_list )
> +    {
> +        int rc = iter->handler(pdev, iter->arg);
> +
> +        if ( rc )
> +            return rc;
> +    }
> +
> +    return 0;
> +}
> +
> +int pci_iterate_devices(int (*handler)(struct pci_dev *pdev, void *arg),
> +                        void *arg)
> +{
> +    struct segment_iter iter = {
> +        .handler = handler,
> +        .arg = arg,
> +    };
> +
> +    return pci_segments_iterate(iterate_all, &iter);
> +}

For the specific purpose during shutdown it may be okay to do all of this
without locking (but see below) and without preemption checks. Yet then a
warning will want putting here to indicate that from other environments
this isn't okay to use as-is.

This use then also requires that msi{,x}_set_enable() paths never gain
lock-related assertions.

Talking of the lack of locking: Since you invoke the disabling before
bringing down APs, we're ending up in kind of a chicken and egg problem
here: Without APs quiesced, there may be operations in progress there
which conflict with the disabling done here. Hence why so far we brought
down APs first.

With this special-purpose use I further wonder whether iterate_all()
wouldn't better continue despite an error coming back from a callback
(and also arrange for pci_segments_iterate() to continue, by merely
recording any possible error in struct segment_iter), and only accumulate
the error code to eventually return. The more devices we manage to
quiesce, the better our chances of rebooting cleanly.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 10:16:45 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 10:16:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878989.1289251 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td57l-0005Fd-8C; Wed, 29 Jan 2025 10:16:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878989.1289251; Wed, 29 Jan 2025 10:16:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td57l-0005EV-0v; Wed, 29 Jan 2025 10:16:45 +0000
Received: by outflank-mailman (input) for mailman id 878989;
 Wed, 29 Jan 2025 09:00: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
 <SRS0=XMr0=UV=oracle.com=harshvardhan.j.jha@srs-se1.protection.inumbo.net>)
 id 1td3va-0000fa-4s
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 09:00:06 +0000
Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com
 [205.220.177.32]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6cf90dc2-de1f-11ef-a0e6-8be0dac302b0;
 Wed, 29 Jan 2025 10:00:03 +0100 (CET)
Received: from pps.filterd (m0246631.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 50T8uddw030249;
 Wed, 29 Jan 2025 08:59:59 GMT
Received: from phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com
 (phxpaimrmta01.appoci.oracle.com [138.1.114.2])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 44fh6m80gd-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 29 Jan 2025 08:59:58 +0000 (GMT)
Received: from pps.filterd
 (phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1])
 by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (8.18.1.2/8.18.1.2)
 with ESMTP id 50T8r43D034283; Wed, 29 Jan 2025 08:59:57 GMT
Received: from nam02-sn1-obe.outbound.protection.outlook.com
 (mail-sn1nam02lp2049.outbound.protection.outlook.com [104.47.57.49])
 by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id
 44cpd9e2fx-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 29 Jan 2025 08:59:57 +0000
Received: from PH7PR10MB6505.namprd10.prod.outlook.com (2603:10b6:510:200::11)
 by CH0PR10MB7498.namprd10.prod.outlook.com (2603:10b6:610:18e::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.23; Wed, 29 Jan
 2025 08:59:55 +0000
Received: from PH7PR10MB6505.namprd10.prod.outlook.com
 ([fe80::83d9:1bf1:52cf:df54]) by PH7PR10MB6505.namprd10.prod.outlook.com
 ([fe80::83d9:1bf1:52cf:df54%6]) with mapi id 15.20.8377.021; Wed, 29 Jan 2025
 08:59:55 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 6cf90dc2-de1f-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=
	corp-2023-11-20; bh=jnRnB4R71o9W8TbpaaT5QduCVy1nvEhpgN2aAj3f2ts=; b=
	hRP0TywA1RzQtk3yjfvD1Ir2kJEWsnnxYaaszWNMdTNe8EUVJ9/gsgjh+dINqgZm
	089lTwHdw58cZLf3NUqfhrnKKVmIh0PA71S40HOxbotDIdPXW/mcP4EavuNJhL6q
	XRtefDg/MlJH/iSjEfEObzk9YyymCg0C/HFfK1XCD2znkbCShSfmedAKeJARUcnh
	YbxAoroNiM85AFxo6TWcsy9tlDVvdkdf02KmQDblIAB1RI6WNfW3xWAQg9nF7Oy7
	cBhHWdDgw583eqyqeCrn8JF/YcB0J3rVlUPeGGr1knecufkU4NGSY/B+dV9eR0oO
	ZGdeo+ya5VgLOZG8hSSUtQ==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=HEYHeACutJEoHFfaJuW7PCVRNHhTmQEnt4AdIPnct+7SaspK1AkG54j7EinWn4ONlFSzkv6KATz2Schdj3/TySpMysEY9FVrQ7t9SWTopMfm45grf9FEJophzz9v84tP0brxM5CNrbW33PHHQ5PCaOQ7f5KNJnn3rj2ayKOkosBpa89rPfUtwQoB8BIPDphOd+M4WN3Th6Qx5e6CBhIdMck/LjWf/VNa/f/KDz6BJbe3uuOcljwsOpe5bEaorYOKHMnWVhJYSoDkfY+wWJuiKa2r/KHVHgvlKniHgNMTRey7dp0mVSS4/hOY1vz17XPCUWkZ43konwJk7ISU+3KdtQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=jnRnB4R71o9W8TbpaaT5QduCVy1nvEhpgN2aAj3f2ts=;
 b=Kkz0KQmvcdkU6cO7kRC6h4f5O1fXlNPC9d1/J2X/TKXXcB5EZ/OzLA6oFs6b2gCqvBfrabtw8FqZ/jc8aH7AKq5cISIiN2FrcZQcCyx8+aEHTH4MjPvUJPavPTIcmm5WyVfyOmW4YEYGEO0dGfGsGqETatccFQHHaHVyBPMYT9W3FGeOvYiGCDJ52kL1jhLPtY0nU1w7nMe/YUVXw9N1Fr+5iDIcbt6al6HWYqn5Ks8iQy0VldctR5XgtpJTb+/xkqjdIC4UPNKgjDi3Td2SepzTkIuyZNgHAPJNsusxUvyoL6F+P4fAgZRvcjKqj418Cu6XtbNwuZn+yStVFH8SBQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
 dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=jnRnB4R71o9W8TbpaaT5QduCVy1nvEhpgN2aAj3f2ts=;
 b=K+h45fRXW2/u6lnaUIuiiOGTMQ00HA2sa6mnJoByq6sSfh2JPA5OsBj9XmmrDxyH8oOrwHM1HsXfNwr5TM2buBi02mJUKLcmAh2JkOYWOqhtuv7BtHZhcwN4DCiWMI3El7edZn0jbF6cMoSBREKS90x5x3ZElBMnQqzRlIhm2TE=
Message-ID: <1f017284-1a29-49d8-b0d9-92409561990e@oracle.com>
Date: Wed, 29 Jan 2025 14:29:48 +0530
User-Agent: Mozilla Thunderbird
Subject: Re: v5.4.289 failed to boot with error megasas_build_io_fusion 3219
 sge_count (-12) is out of range
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Konrad Wilk <konrad.wilk@oracle.com>,
        Boris Ostrovsky <boris.ostrovsky@oracle.com>,
        "jgross@suse.com" <jgross@suse.com>,
        "sstabellini@kernel.org" <sstabellini@kernel.org>,
        "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>,
        stable@vger.kernel.org
References: <7dc143fa-4a48-440b-b624-ac57a361ac74@oracle.com>
 <9dd91f6e-1c66-4961-994e-dbda87d69dad@oracle.com>
 <2025012919-series-chaps-856e@gregkh>
 <8eb33b38-23e1-4e43-8952-3f2b05660236@oracle.com>
 <2025012936-finalize-ducktail-c524@gregkh>
Content-Language: en-US
From: Harshvardhan Jha <harshvardhan.j.jha@oracle.com>
In-Reply-To: <2025012936-finalize-ducktail-c524@gregkh>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: SI2PR02CA0046.apcprd02.prod.outlook.com
 (2603:1096:4:196::15) To PH7PR10MB6505.namprd10.prod.outlook.com
 (2603:10b6:510:200::11)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH7PR10MB6505:EE_|CH0PR10MB7498:EE_
X-MS-Office365-Filtering-Correlation-Id: 817da161-9503-4313-975b-08dd40434ce2
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?QllEQkhLWDFod3pjaXhSNjFlQkErQXA2dDdVdGNSamlpK0hsa0xRUTBUNC9F?=
 =?utf-8?B?aEllUDB5YkxzQ0lMd1hGdUtKUU1DcmExU09qVGlXSHFpRlRhWmhwQW1Bano0?=
 =?utf-8?B?OWhNSWhEaHZ2ZjlKT29iQ016VmFOTE5rK1VGN2QvTy9IKzZlQ3FmNVo4Q2NH?=
 =?utf-8?B?YUd3aHRpSmEvQndOVmpSbkdDN2pTd0dIT1RlZTFMbEVrOWFMS1pIR3poZktX?=
 =?utf-8?B?c2lZRWxTUnRCQ1FNZDAvSlhrYUNqUlgrMFFEN1RrU1J3WUEwNnNrMURCMW96?=
 =?utf-8?B?LytqZG9RaVJpM29zajVHTUNDQ3U5MGtnOGtvS25weFF5dUJKcVAzK2RnMGxG?=
 =?utf-8?B?U1kwdGJDd1BiRHljQmdPSTIxZURVTkpKRDFHSlRvcmRMcW9OMUREZ2IyRy9m?=
 =?utf-8?B?THg3RU9kKzZmL29iZVdzQW1jUEhYYjArSThFc0hUcW1WOTMvdTU0eHNrRi9Y?=
 =?utf-8?B?TXNnQ0hDcitpK3NqMVFPdzYzWks0S3ZtZlU3YldYZTd4UWJYUVBiWWU5Ukhk?=
 =?utf-8?B?K1JObGkrbUVKaFB5bk5ZVUFoT2pPQXI5OXlMVWZXN3NWMlRZS3FPQ2UrbHA1?=
 =?utf-8?B?VkZhdnM2bi8yeUdqUHIzZUluZ2tqVVk0cHNUemMyTGxUQVlNbG13UmE3emxi?=
 =?utf-8?B?bTQxemUzZ29rK1JpaUgwbnlXZ3NCcllNamthWHVueS9uYTRyZEdYZXhqNmVt?=
 =?utf-8?B?cWFDd1pmS2l1T3pYYW1yMmFFOWgzeTRPTU13OVNHZ1pVUFZoT1ZWemcxclM1?=
 =?utf-8?B?VE5kREQyOFpZMFBwS2xwQm9NYi9LUUJmcktPK1M5UzJWZGlEZ0FvcTM5NjJs?=
 =?utf-8?B?clMrbm5xWXhwNmdlQVZhakVtRksvUlI5VE1BUzVDdzBwRWhWc3VYZFE1cG9P?=
 =?utf-8?B?aktnUSs5V0orbThyZHl4YXNUd0ZxVk5xcFdQVlJtR21USnp0VkVsblh6MjJn?=
 =?utf-8?B?OXpnZThBcDgwZkhMUVg0ZFl0ZFNaNnNPb216NFQrYUxkNTgraTFianRtcjBK?=
 =?utf-8?B?SWp0QmRieXZTcVN4RXRlSlU4aVdsMHpYVHZ2a1loZmtuaWtXTnFXYkpGTkMv?=
 =?utf-8?B?VDJLSjl4S2p1S05IbFZWL0M1NHJTRFA0OVB5L2ZXbG5ITjJIMUpEMGs3VDZG?=
 =?utf-8?B?RW9HL21Bc1FaNVlXcHZxd2hQMlVQSXcybnVNanU1NVlnaHVIcnZqcjdvSWdY?=
 =?utf-8?B?bmRKQlIwR0lFZUlweGJNcTNEVldoVWZxWUFGVFZ3UjcramViK2NzQ1B6M0Ey?=
 =?utf-8?B?Uk95NzFsR2trWS91VmdOakFKN3pwL3NKc0Z4bXR2WlljcW4zZEJsczR0ZHBh?=
 =?utf-8?B?OE9Gc3pSbE85cXowUDNWSUxwRXBheFpsNyt6bXNVaDA1Z1lFcVh5ZkZra3cw?=
 =?utf-8?B?UjVTK2UvOE41U3pqNk9HV2VFNGpMb0c2RzZHM3RGQzE4L0FIQmVpNUExSjU3?=
 =?utf-8?B?dVlWVmpPSmltRUFod3hQcTZCNWxYcWp6U0RQR3hmYWZyU0hnaHUzSkdmVEVZ?=
 =?utf-8?B?aWg2S0JVTWFTeTkzVG5IMUNuYkd2Z3ZuZDJQYzBCS0Ewa3pFalJOSlBTNWNY?=
 =?utf-8?B?L2tBYmY0OHp0UWlvdzF1NmVTNmlLNWpwOWlhbFg3VHRiUU0vbms3a3UzdU5v?=
 =?utf-8?B?TU4zM0tuV1IyajRBZ3NxekRGTElUZHFjS2FvQkpCNDRPZmFxeGk4R0VjVmx1?=
 =?utf-8?B?c0xCQUF6aDFGdW40ZTV6UHdLdTVoWCtiMnNoQytzSEIwYTEvS2FvWWVFaTBS?=
 =?utf-8?B?TTBHVnR2VnRZWjJ6NU9saFF2K0JoVzVpeHV6UWpoaDZVdE5tUHZOMDErcGc0?=
 =?utf-8?B?QXhKRjVqdUVOaFA5dkl4MWR4cHlSUGRCaGN1bVBhcWcwblBmUjRmWU5FSEU5?=
 =?utf-8?Q?bDBKnb6+sNdCy?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH7PR10MB6505.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?ZCt3ejRPRkpYc2h2TFd3enNLMkx6T1VGSzhqdndEalVUN1NQZWFRTGVVQXdM?=
 =?utf-8?B?b0Y0YjFzUXVMT3owL3BGZit2SDVYZmRNbmIxeHAvUFU5N05PMGtGMVVIRy9r?=
 =?utf-8?B?KzF5Uk13MWpsZWp3czJtZFdWZTlHbENKVEtrRW1KSWw5MUZrQmVYZ0xZSlRx?=
 =?utf-8?B?RHV3aXlSOGMzY0JzV3hXZVBCTzd5K2h1dmsvZkN6VjhkVnFJZ0M3cExla0Nu?=
 =?utf-8?B?S2JXRmFIaGh4S2pBQ0VRWXc5MUxQRmZpMjRUaFMwbXM0S2JscDlvei8rS1Mx?=
 =?utf-8?B?QkcyQ1BzVlZmczIyQVVFS3NNakdVZWtIQy92Q2dRNko1TDJRa25LTFZuSWw2?=
 =?utf-8?B?R3ltb0lLR2ZlcFhiQlh6dUo4ME1kZHBNSXFyVGtqNytaNXNILzQ4cnhJZE1L?=
 =?utf-8?B?NzRmempnUThtVGhyVzYvdmZnVmFQYk1CUFNqa21RTWJkd1lJTng5SXhVbjdC?=
 =?utf-8?B?WnNYRFVJcllPUzRSVlVxRXNTbUZQaU1YZ2Rmdkl6b0VraTJVM3RIamFtOXlX?=
 =?utf-8?B?WEZNbWxnWGpnQkRwVHpsa1dMKy9ZSGhucHdOTDFrYlVDMnN2MkZzSWtQd0hT?=
 =?utf-8?B?Sk1yU1BjUmpYVlZJaGhLaWZqdWI1ZEdPdkl0YlFSclZBM08yUEh1VThvUlI0?=
 =?utf-8?B?RldUTEgvNTJRNXRPQTk3L3BhUEpJSnZ4VzgxdCtkaWNiVzlTdnNCUEhLU0I5?=
 =?utf-8?B?VjgzYmlZVjRTQ2dzakRSUnlYbXRpMEdhT1dwM3N6WTdheVRCVVg4cUZjZFJx?=
 =?utf-8?B?NlNCSXJUcm5KK2RoYXArMzRhRHI4eXcyeVRYa0FIL05lSzlFV0VtRmlXMjV5?=
 =?utf-8?B?UlJTTVJwMGtwOUR1cFdYMDRoUTZQejlZVldSMUIrendxUzMyRDBZR3laUVRM?=
 =?utf-8?B?Vy9QV3VkZjZlUmNJOGtsdHoreWlpTHpsNEQ2QXRHSnZsR1NLTndvMUw3NGht?=
 =?utf-8?B?bHhKYUhycW12SW11TVJNVjN1aEhyek5hTlFiVC9sb0pUVUZnVlZoRFd3K012?=
 =?utf-8?B?aHdDWHYrek1kcDVtWjk4Qjd2cnVsVmFwTGpnK2VmZ1doSDJPRTM2TnFvNHdu?=
 =?utf-8?B?eStZQVNFVTlHWU1oSGJaZEJyNWhaMDUrcjBsb0dEWDUrdGo0Z3QvbzZyMWZQ?=
 =?utf-8?B?dm9NbW94emlCeE9TR1drY2RMZDUxcUVvNXFNUmU3NTN5L0x3N2cwNmtudU05?=
 =?utf-8?B?R2Q3YiszWlo5SzNaSkpwOXpNRGQ0bXJuZm1BbVdQNXFmSDBOaWtGbEJPSTFU?=
 =?utf-8?B?enNLc3I0Z3JKaGZxdExuM3diOG1waVdpeXc3elNmQ2I2Nnl4bFN1S3FkMFhk?=
 =?utf-8?B?QWp3OW1EMWlVUFQ1TFE0bkY2TCtDK2ZhSlRtbitIWkVCT2xUUUs3TG9uNTkv?=
 =?utf-8?B?eUpHeG01ekp4WFY1bHkrT2duVnlpMmNicTlVTkNZUU44TkoxVGtaVCtUWjJ4?=
 =?utf-8?B?anhwTDNzUlA2ZHhYMUR6SXNUSTErdHNtcnpEUlZFbndQN3pxU2ZDL2NBL2Zx?=
 =?utf-8?B?cXliK3hlK1Y2Ymo5S0tqTkl6L2FzeFlJOW01V2hjdEVUK1VRdHRVdFVsUHha?=
 =?utf-8?B?amlqay9MWVc2VDZUa3lzT3cvV3IwQmphR1hKell3UTIxUERsS3hybDJtVHAw?=
 =?utf-8?B?TUFFMXdBbjBXQWo5VXVVbmE3VW1YZUFJTFprdGhHeXdoUjdNVE9MNExBUm1L?=
 =?utf-8?B?ZFp0Tk9hb0lWeEFPK0YvVW84UzN2YlVMOWlkQ1dQNnQrRHpqOVZEeHhWMzA2?=
 =?utf-8?B?YkNETXVJbC8rRk1CTVRaV1grR2pZOUQzaTdQYzhnaEhKa21Ienh6T08vTW1n?=
 =?utf-8?B?ZW13clpKeFdjcE5rZTB0UXdCUGgzZjV6bm5mOHRXeHQxQ2JLaWtUQkMyL2h0?=
 =?utf-8?B?VmlpckNkK0VtcG9MUjczOHl6WjNweFdxeStmVUxkMmx2UmJuaHd5R3hkd0tP?=
 =?utf-8?B?NytvcnFkd3UwcStleXNySmc2LzhHckVtbWFmRFQ3aEQydU51a1lLWVk1bzJm?=
 =?utf-8?B?Z2hvN0FqcEQ3Sk1WSW1jU3REUXFDcmhQQUMyLyt6UUNWNkdqOUk5UG5OZ0lT?=
 =?utf-8?B?bkNtVzFqbXF5NE5VZ3hzSFB6UUZYSWJiekVuMzIrM2xMeWs2dE52N3hXVlNF?=
 =?utf-8?B?RlhLRG82NmMvVURQRlJvTklJL2Z2bUo2bkp3STJOV3dMZFlZczc4ckpaUkNK?=
 =?utf-8?B?RXc9PQ==?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	KA+dSQXAQyxYyoDoBNNxGpkCrDuBnJZIX6pI9pU3m2auX9mW+09YRllnGWY2Ow8Fw76koPz9/sMjWzfOhXLk5ObDiVK4nHwxfks11/NQst+/rBnyCinEvab/9T1Ox4vzE/2vcQONFQh+GMda+Z9qSz44GP6LCAQt8nKop0gPo5WUlRlZzIa72cXBpww+yJouIAY1O8M+PsIGX3Yx8M76Nbh3GOVIlP6ORXfdyHwJ8n0Kqk3e3mClhUo/emHL5Mtxuk45wYtAQ0Ozdsx7aZ2CEFEGR5rkE5z8U7oWq2d2R1zbzRCUmKb5VApWWF2YJySWsPjz2KmaiQXItrDvgkzbjJtls+KOAcazfqqz62S4/+9P/Uup0FNk8tCd0Nb6l/Vhj6AIXZpb26OXtroThAio8DYRhBgQsmsUAe1F6dJOUlzmx924uJ5v65SVUgBcZehfUgyXF44l+nM6P0RC4Gl/oVWZnY1y9mn9wyckyi02ycSKD2IWNIIkIi8/IyYvU7qAeQEOB0v4mqLNj6H78+x7BpkyOoitaBmgSm73PMbC24dDbJQDOwaLDOlIWEelN9AzoQgz18wPTNJnA1OgU2p4Qq9j/TIs24A9+5L1Lbdga3k=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 817da161-9503-4313-975b-08dd40434ce2
X-MS-Exchange-CrossTenant-AuthSource: PH7PR10MB6505.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2025 08:59:55.6417
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: lmIFBnpbShBjVR0qknsiF0v7MqaeQ1XrC5omCr9eggKYr8VmsHgcMDFYfQLssYKEO/ryCrfYrWVexOwXeVIu+LwtGlkuA15nc2rBkR16ePQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR10MB7498
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34
 definitions=2025-01-28_04,2025-01-27_01,2024-11-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 bulkscore=0 malwarescore=0
 mlxlogscore=999 suspectscore=0 spamscore=0 mlxscore=0 adultscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2411120000
 definitions=main-2501290072
X-Proofpoint-ORIG-GUID: CIwwMTlWXn8W7HnFMh8B7XgaIad0a2G-
X-Proofpoint-GUID: CIwwMTlWXn8W7HnFMh8B7XgaIad0a2G-

Hi Greg,

On 29/01/25 2:18 PM, Greg KH wrote:
> On Wed, Jan 29, 2025 at 02:13:34PM +0530, Harshvardhan Jha wrote:
>> Hi there,
>>
>> On 29/01/25 2:05 PM, Greg KH wrote:
>>> On Wed, Jan 29, 2025 at 02:03:51PM +0530, Harshvardhan Jha wrote:
>>>> Hi All,
>>>>
>>>> +stable
>>>>
>>>> There seems to be some formatting issues in my log output. I have
>>>> attached it as a file.
>>> Confused, what are you wanting us to do here in the stable tree?
>>>
>>> thanks,
>>>
>>> greg k-h
>> Since, this is reproducible on 5.4.y I have added stable. The culprit
>> commit which upon getting reverted fixes this issue is also present in
>> 5.4.y stable.
> What culprit commit?  I see no information here :(
>
> Remember, top-posting is evil...

My apologies,

The stable tag v5.4.289 seems to fail to boot with the following prompt in an infinite loop:
[   24.427217] megaraid_sas 0000:65:00.0: megasas_build_io_fusion 3273 sge_count (-12) is out of range. Range is:  0-256

Reverting the following patch seems to fix the issue:

stable-5.4      : v5.4.285             - 5df29a445f3a xen/swiotlb: add
alignment check for dma buffers

I tried changing swiotlb grub command line arguments but that didn't
seem to help much unfortunately and the error was seen again.

Thanks & Regards,
Harshvardhan



From xen-devel-bounces@lists.xenproject.org Wed Jan 29 10:16:45 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 10:16:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878937.1289230 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td57k-0004ww-6t; Wed, 29 Jan 2025 10:16:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878937.1289230; Wed, 29 Jan 2025 10:16:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td57k-0004wp-3m; Wed, 29 Jan 2025 10:16:44 +0000
Received: by outflank-mailman (input) for mailman id 878937;
 Wed, 29 Jan 2025 08:28: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
 <SRS0=XMr0=UV=oracle.com=harshvardhan.j.jha@srs-se1.protection.inumbo.net>)
 id 1td3RD-0001v1-Ef
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 08:28:43 +0000
Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com
 [205.220.177.32]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0a6bc5bd-de1b-11ef-99a4-01e77a169b0f;
 Wed, 29 Jan 2025 09:28:40 +0100 (CET)
Received: from pps.filterd (m0333520.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 50T7txCG015486;
 Wed, 29 Jan 2025 08:28:34 GMT
Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com
 (iadpaimrmta02.appoci.oracle.com [147.154.18.20])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 44ffve0445-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 29 Jan 2025 08:28:34 +0000 (GMT)
Received: from pps.filterd
 (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.2/8.18.1.2)
 with ESMTP id 50T7WdEP005314; Wed, 29 Jan 2025 08:28:34 GMT
Received: from nam11-co1-obe.outbound.protection.outlook.com
 (mail-co1nam11lp2174.outbound.protection.outlook.com [104.47.56.174])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id
 44cpd9gvy3-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 29 Jan 2025 08:28:09 +0000
Received: from PH7PR10MB6505.namprd10.prod.outlook.com (2603:10b6:510:200::11)
 by MN6PR10MB8045.namprd10.prod.outlook.com (2603:10b6:208:4fb::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8398.18; Wed, 29 Jan
 2025 08:28:06 +0000
Received: from PH7PR10MB6505.namprd10.prod.outlook.com
 ([fe80::83d9:1bf1:52cf:df54]) by PH7PR10MB6505.namprd10.prod.outlook.com
 ([fe80::83d9:1bf1:52cf:df54%6]) with mapi id 15.20.8377.021; Wed, 29 Jan 2025
 08:28:06 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 0a6bc5bd-de1b-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-transfer-encoding:content-type:date:from:message-id
	:mime-version:subject:to; s=corp-2023-11-20; bh=sx6WvSTDPY0O6Hbb
	hwfY5GBuY2MohoBL1aomhDbhz0Y=; b=O2l65cSmzku9RUYy8WTJbrPWvYntnhJ7
	CBAex5JnbuXBKpiY7/Xrz0IC7cjJcCtHqj3uygIij3haiWXheV0LCGXOf8OQo+Te
	sCUIkFwVkF62DhLFsL9Oay+HzCZRWonI8dygJNYI/y8ivmezGU5Ctu1iWGHsvQN7
	5XTk9mJ/YgExwymZ2ev0EWsWlZQz2fn03ua0XXamHm439FHozah6h4rYRppGxS/I
	5UG6fjwOPefEQ9ixGr64jhdu7+hNTx0OnefOeR8q/ltdXGAkz2EE8V103QJuRzvF
	s3kJJ9Yw9PMdIP4OywjyHmKu6RQyO2eKUFGLWZefGeMY2KqSAq73Cg==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=EWFbJ7E1kgJ66gJ+n1QCeIhiHtWNLMLChWq0Gx2iH7wP6d+kNDRYn6AGDeZ8vv1DOFVy/cH36bENzPeWfi5m3AY4HAaNlrGWNDOplGaP+52igfsqDLcWUJ6YQFsBK8fdRkBjQc6PhueMG6Xh8wlYVCSwSQluei9SfYlZ+QWEyXBV2VPyGiZNRogWXTLlbd4Tl6boU23jwGo7V2cljJbOIT5HbVNeAIoCZwvVXw/nEULc5hr5iVrmQPMtNQr3A/CcUfrxvQsYKRTD/+JjwslBowyVQ6xGOHThawgwV1bqoeNx8tI/EqabNM3k+ntkCDqES4vuUSv2qE4/LkShv6Ci3Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=sx6WvSTDPY0O6HbbhwfY5GBuY2MohoBL1aomhDbhz0Y=;
 b=Vy1OXAu3LvzkM1ecMLsQTfdxERcvysaLWr7hEtrw2Giq8XgXI7sEN82c/USgui2EPH3T6FnQlb0IcvMZDq5VptMDRblYC9d/AMkYrzFBRVxB7uLHV4BZj65Y7JCEQp/smb71D1mY0xNK/N1lf/uBFBuNSlcLrn/QPBmq8/Z3AHM3emFtl7ui2roMXp52fjplrog3l1yDk7GaUYC3xkQduyZtTfBNYsrfXXrJifJ+F4HRMQ3xlHrdCCPUX+Z5DUj6wtoXcDNFuWTPuDcFL4HFHXGcGHOu6Jfraq1oCQvEfsX3I8sEoLGuRESp2zsvITZ8llwEOyxcmuER5dksfPHPuA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
 dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=sx6WvSTDPY0O6HbbhwfY5GBuY2MohoBL1aomhDbhz0Y=;
 b=orW1JV9cBuHsj9GrYuFaINcgGVh7ysQyg4F8jxwo+ZAnLctthMqXauBHQvZF8b4VWJ4LwUALLJytJTL/AQhWt9ekgXiyucvDE7aSbCRiQPFyptnKdSjx1EdEMivhaDZ06KHmY/gyYHk8X/5mHcsHCLucqSo2zB9jVNeGiR+/23o=
Message-ID: <7dc143fa-4a48-440b-b624-ac57a361ac74@oracle.com>
Date: Wed, 29 Jan 2025 13:57:59 +0530
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: Konrad Wilk <konrad.wilk@oracle.com>,
        Boris Ostrovsky <boris.ostrovsky@oracle.com>,
        "jgross@suse.com" <jgross@suse.com>
Cc: "sstabellini@kernel.org" <sstabellini@kernel.org>,
        "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
        "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
From: Harshvardhan Jha <harshvardhan.j.jha@oracle.com>
Subject: v5.4.289 failed to boot with error megasas_build_io_fusion 3219
 sge_count (-12) is out of range
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: SG2PR04CA0200.apcprd04.prod.outlook.com
 (2603:1096:4:187::15) To PH7PR10MB6505.namprd10.prod.outlook.com
 (2603:10b6:510:200::11)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH7PR10MB6505:EE_|MN6PR10MB8045:EE_
X-MS-Office365-Filtering-Correlation-Id: 4b50e43a-06d6-48ee-7b8a-08dd403edaf3
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?RFJERTJoSWRsc253dnNnMmUzMTE1MFk5WEV5cTZUdUo5UmV4KzJtMzFrUDhD?=
 =?utf-8?B?TTlRY3BBeG1LK29QZWNSNmlvRDhnTVhlc0NiclFwOHJhU1dlVytpYWcvU3lX?=
 =?utf-8?B?NHNJdWkxMmh1eUM1QnhuYURpWUR1U3RxRDNCYyszOGlLK1JyWjN2TTlUU1di?=
 =?utf-8?B?UkVxME04bU11NllEUkJaMndldDAxbUR6QXdSY08vVkhpNnZiTEZoZWRWOUgy?=
 =?utf-8?B?NnFTL2J3QTZWU0dlSDZwYjUvY3JUTDlnL1RqWXRpcUliMFVyeS9SOVF3TDFG?=
 =?utf-8?B?MWxUdXJBcXcvZ0FHVzJCdkhOZzZTUCtTVWFSemxQWmVwTENTUUMycStVVEUz?=
 =?utf-8?B?dlNJNWFlVU1sQ3VPcyt4c0hHT3gzYWlsdnVNRWtZWDB5WDBSNlpoR0pjNVVY?=
 =?utf-8?B?YXR3dUFySWRqNHhGMTlWSWkrM1FoU3kvbVlidlhFenhKWjJBd21VTm82ajd3?=
 =?utf-8?B?QUxsY0JDelQ4NlRRa1QzL1ZRbERRWk5yRHhHeDZXWWNQY05LQ05qcUd4aXdM?=
 =?utf-8?B?OHRKYWVOaElsV1BJR1FKVElXQmIvbjJOYmd3U2hTTTZJbkF6YktXdloxTlJo?=
 =?utf-8?B?RW5rcE43NGVxSE1leWVQSjFIS1F3K2Ruam5XM2ZBWXppYVBPS0Jwazk2MENa?=
 =?utf-8?B?aGhnUEFTTzR2ZEhxbmlrNDUybVhMU1F5VldiYUpMOE9VV1lVcHFkdDh5K2xU?=
 =?utf-8?B?RS9VdWtWcDlsWUxzYXdoQmMzTkR6dFpVM1M0cXVDQXphMkxLVUxoSWhBTVpn?=
 =?utf-8?B?UzlaVUtINjhKR3J4WXQrZEppYkN2dkw1Q3E5NzBIeXJ2bjlJL2tBUmZCMkUw?=
 =?utf-8?B?SmhMV0wxR3lPaVRyTEFXTjF1YkgwVFNRUytUdlZ2YTFXaGpLQnlmMm81eFJs?=
 =?utf-8?B?RXVBQldreTJYdE5CdTJJOW1jV2h6S0xhVWJSSStXNlVlNHhkRGpzWSthdmpK?=
 =?utf-8?B?VjdYaklGV29jMWZLU2hXY0JvUzVFWkp1cE9xQ2JTUVZoUTJOSGZCNWUrUVNG?=
 =?utf-8?B?dWF4aHU3YkRvQ0VUQjMrcytWMmlZVjJkejFuV2FTd3BEbzJ4ZVJUeElIUWRp?=
 =?utf-8?B?N0x2ZGh3Ly8wVUM0Mys2dnhLQzViSkpqVzFmWHgwbTU1U3pkNkIrR3R2SEpx?=
 =?utf-8?B?cTBvcDAvRHZlbVltNzJES3hxN1Yzc1RTUmZqajMzMlRqS3U4Mm5jRUJQR2VU?=
 =?utf-8?B?MEM3UzgrS3o0TW4vemd2M1BNeDQ0VFYreVU5Z0lWSkFpSjY5V1RuUEU1ZERB?=
 =?utf-8?B?TmZGZ0xwQ2ZTbk1zVFg4OXVBUXphMFVTL1liNHBBK3pSRFVmS0RJV0RaK0hX?=
 =?utf-8?B?OXBld2FSSHlITk1NendXWm5jNG5TRVBjYVYvRjZ4T3pYaWE3czkybjZUNXhl?=
 =?utf-8?B?RkJma3pnNnhDUnpyeTI3RlA5S1pPVnQzMm00VG4xL2crSTVGSGEyNDRlYXdi?=
 =?utf-8?B?MXl0Z2x3eHVYRmQwTGtXM3NoWFgxeGxKR3NQQ0VleHF5NHJXOG9mWEtPUlZz?=
 =?utf-8?B?QXprL3RJd1oxcktWMUdBak9UUVVJcE0za0d1U0JEdGR2dVBDck1FVUxCOUZV?=
 =?utf-8?B?RURSS2QzUHB3Yy92elhYbklkQzAzblZEZzRFL2ZkYkZ3cDN1eUpXQ2U2cmZa?=
 =?utf-8?B?Mkt4WWdWYUozNWN5UzFxVkFVc2pvY0RqRVBEaFVNMjE4MnR5YlJkNnI3T3NO?=
 =?utf-8?B?RjZwREZWMUt2aEJLTkVUMHg2NTJEUW50SWk0ZG9HYUpNT0xrbEdyb2gzbnVB?=
 =?utf-8?B?MHFuQkk5eFV5TC9GSlRxTEl6QUNDSG5kbENlOTlQU0VVWnFXaUJ3OUtLTFRU?=
 =?utf-8?B?ZXltd3Z0cFcyQVpOalhRN0V5VnBoQklvbG5vWC9LZ3FuRGtYclJsUU1ZRDBY?=
 =?utf-8?Q?sy1g0kzi8v1PT?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH7PR10MB6505.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?Rmx4RVBRVzFIZzBsU0w1MCtEakIxenlHT0k4aWhHUExMcm5uMjZjbUhPbXNG?=
 =?utf-8?B?NnpLRHlSTS9lZ3lLSHRQZ2w2VkJGL0w3K0ZCWnhCcjdSc3p3YnRqNkdRejhB?=
 =?utf-8?B?Vk92S25mb0ozNnJHc2UxbGUwOGQzSWQyTmNEYW5MQTk5eGlVWWNVSHdtODFq?=
 =?utf-8?B?cnlQT0NVUUllci8yaS8rQUhjVys3NHhSb0luc29qaWpMWkV6a0c1eDE4ZVRT?=
 =?utf-8?B?K0IwcjRpTmdENUNyemp3cjk5azVoUGZkOUMxYVlIem9TSGQ4M2lPSEFqV2pt?=
 =?utf-8?B?bnMzSThBTWMwSmtxK25HVTV0Mmswdk4yeXFrc0wyK201Qi8yN1gwWGlYOVI1?=
 =?utf-8?B?OHVaeWZQRUJOU2pBZmpzNXdyMERtcjFGRWxTdGIwL2JEaGV6N3YySUhUMEl4?=
 =?utf-8?B?eUplR0F6RkFGRWZ3clNsSWprdmFTVlZOMjNzUFdKem5XUGpDZ1U4cnZFcHpD?=
 =?utf-8?B?eGdhRVlUQ2Q4S0p6SDJobW5IQTRNWUpHZUdxdVNLejdkN2wzKzcxTE1kQzFn?=
 =?utf-8?B?QWFxcFkxU1dNdmRBbk9FRnBDblZDREhJenEveW9mc2pENS9SRUhWdUs4UWpS?=
 =?utf-8?B?aEFMZklyaWd6VUtrbzFPZEFsUk8wRmtMWFU4ZTdmTndNVkZIUDErZjhpaGMr?=
 =?utf-8?B?UmtqT0tlTEIvN3lUbzVtRldNTzY0TUcxQ1hET1VUcVBwTldKL3l6ZTNIdm12?=
 =?utf-8?B?Ny95UXY4eS9TU09LbmdyaThrbnFDeEY2bGtLcUhNRW1ibjNqL085UHR0Sksv?=
 =?utf-8?B?RmNMZzB6dTJHNHAwaCtLdkRiSmsyNDhPUDBSNEdvc3ZhWU13MzRtRWpiVjRq?=
 =?utf-8?B?TTdPNmxVRUI3bVlSbldNNGhrRzJBRE9BSEI1VktYc2VaVVBwck5MWWNITVMv?=
 =?utf-8?B?RFQvWS9XL1dwRlVvQnhaWXRaYmIzLzl3NkNNVmRPZ25kZjIvK3dtcmt6bVZn?=
 =?utf-8?B?bDR1RHdjdmhhRGVTbTdDZTUwR0pRQkVpMVhOREJFeHU0Nk9Gc3Z5bUlDMlRr?=
 =?utf-8?B?ZDZiaVZQSlArYm9vU2RFS3l1bldXdWlUUkl6OE5LQzZKK3VCVXdIMkdJNkVo?=
 =?utf-8?B?c21WWHdHZFBEaFo4WVFaWTVoN0lTUnRERkVpN28vb1NiV0xrS2tEam1ZV08r?=
 =?utf-8?B?SUdhZm05T29LUnRkQzh2eWQzSVlvL1QyRGR3QjNVZW1MSmEyaDN0S3h6K3d4?=
 =?utf-8?B?Vm9LajFFSEpkdEQwWTY0WEhrbkd4ZHd3R0JhMEx1VVU3RmZ0TDNZdE8zT2Y0?=
 =?utf-8?B?QVpEdlNZbjhvT01wcFh4VEkvR2VtUE9TbW45OTNNUmdBeE0yUWc3czFNVXZv?=
 =?utf-8?B?NTgvYTlTMkk4UFJNNXpkemZ3R2gvdEl4bm5XQXRsMkY0VWlCNCtzN2M5V3kv?=
 =?utf-8?B?Y3UvSGo5dUI2OWFkc0VsdUJ4eWZtSGtFMDU1VzVVeUh6dXJJSXBlcE5SRDQ1?=
 =?utf-8?B?bUdkR3RWSEpLb2FTcG1TZnVHQzZmNEtaQnJjcXRXNU1NMUlGVDN5dE1hOHdC?=
 =?utf-8?B?MDhNQlBUeWtsUU5jNjRTTHdiSGVNdUQ2YXoyK2NXbUwrR3pRQ3llWGNKQ3Zh?=
 =?utf-8?B?MUtPSXlPb0QrNTBzRjgra1ltZzNNYnpUQ0dPREd5cWpSM0dNV3dEZDZmYlBL?=
 =?utf-8?B?dVJpK3MySjRMbkxhZUU4SWxuWm1DejZ0SlBCdWFuYzQ1L2s1MzNkK1hVazhj?=
 =?utf-8?B?M09YZ3NsdnZ0NGdSbnpQcmdCQ25rUGtFR2RqTnNIMndocUJyQ1lSbTV2bmxz?=
 =?utf-8?B?djA3Wnc1Y2xROWhyTTlPTGRoNTBjQkRQOURUSmdYYXdQOVZjYVl1SXlGL3pC?=
 =?utf-8?B?SmZwcXlzL1BhVHF4S093cUFaOFJVRjlHek53dTBOSG8rZk1WUWpYV3NLOVVl?=
 =?utf-8?B?WkVWNUp4MmhwVkI2L2hsOHViUnJ2b2thV2lHL2JMbXVHc3crUXJraHpoSndY?=
 =?utf-8?B?d0xuTGlRdzQyUEhjOVBtTEZGRGZpaFh4SzFob1RYY0Y2VXhFdjN1R1dmK2ho?=
 =?utf-8?B?Wm1pNEV2ekFqb1FOM2trN0ZTaWlqQzUzQlFlVXRPcW5uSlJ2SjAwaE9wamdZ?=
 =?utf-8?B?MWdPMnN5TnArbkFjS2ZPc3Qza2xFdDkxOFhFSDIxOGF5bDhoSVdwRjJFSURI?=
 =?utf-8?B?VlluTldYQ3pDdU90N3JsM3BybXU2V0E1RUoxYkNWOUZBYnRkOFBFVFZLNmJt?=
 =?utf-8?B?MWc9PQ==?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	1UqMbLA4s8V349nfO41WhUtdjHuALEnmPhAxj0NZnW0o91PgaDvK6krL0Rtm8F55w6l5RRauKzyhYPSCVn4+YRiNzLtu/N+8EDN/zZr8ziZ1yZctwvWVG4gelZVZwTVPDIIHm2Y6JWqCvo2OhxfUQMX+JOY2oo2Jf1rLlU1oyknG5nM+Zr0dKafseifGtLeWyqlEkRKfql5P9/Psx69lDj86Td9CY5O+udTvukH2wCRTJxPOvoxTebFU2s6yXWKjmndFgvh3cTUMxAv133hgzf9FqRUVJJSyMJqEJcmsadktl+y/h0RxiA+RoW6doW2IQ9NYVTZdabeR3CBNtpWtjbjqKgoe0BZTAhIPAWZ5srRGBHOamLrgYG5VVtlzSWgEW0EPmbGoWCBPQHPzvuBPX5hrIxwHAaxGgrvUPsqqJPfyVbtGINCTri5ZOzxjzeHCtpneDWmjHkhyVAr+fQED/iWv5DwX0ZJomes8apnsZkKIREhfEnRuwsdiW6H95JnCF46hHHCctKUk9tM62XNC+ym5qVgXXUhitUb7JZIcrLnfdFACTzB78v3KIXBbaZ1f4VXvCz84iHgYG17MWqBZd6MogJdDgABuKILYlx+igjI=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4b50e43a-06d6-48ee-7b8a-08dd403edaf3
X-MS-Exchange-CrossTenant-AuthSource: PH7PR10MB6505.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2025 08:28:06.5091
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: bktS6O5bsKk52fUyg6288Rl9lPUwf8vTMXyre7sOKEhHkRxl5F+2SEZHrhbnK6hqwAeJkfpVZWLG8JLZyNLPg5sGl74+A/EyP5mz2VPRWnI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN6PR10MB8045
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34
 definitions=2025-01-28_04,2025-01-27_01,2024-11-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 mlxscore=0 adultscore=0
 malwarescore=0 spamscore=0 bulkscore=0 mlxlogscore=999 suspectscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2411120000
 definitions=main-2501290068
X-Proofpoint-GUID: ALR5CpneA_GqVTdXeCkkRQhvyeLiSY-h
X-Proofpoint-ORIG-GUID: ALR5CpneA_GqVTdXeCkkRQhvyeLiSY-h

Hello there,

The stable tag v5.4.289 seems to fail to boot with following trace:

[ OK ] Created slice system-serial\x2dgetty.slice. [ OK ] Listening on
udev Control Socket. [ OK ] Reached target Local Encrypted Volumes. [ OK
] Listening on /dev/initctl Compatibility Named Pipe. [ OK ] Listening
on Delayed Shutdown Socket. [ OK ] Created slice
system-selinux\x2dpol...grate\x2dlocal\x2dchanges.slice. [ OK ] Stopped
target Initrd File Systems. [ OK ] Listening on LVM2 metadata daemon
socket. Mounting Debug File System... [ OK ] Listening on networkd
rtnetlink socket. [ OK ] Listening on Device-mapper event daemon FIFOs.
Starting Monitoring of LVM2 mirrors... dmeventd or progress polling... [
OK ] Created slice User and Session Slice. Starting Read and set NIS
domainname from /etc/sysconfig/network... Starting Load legacy module
configuration... [ OK ] Set up automount Arbitrary Executab...ats File
System Automount Point. [ OK ] Created slice
system-rdma\x2dload\x2dmodules.slice. [ OK ] Started Forward Password
Requests to Wall Directory Watch. [ OK ] Reached target Paths. Starting
Remount Root and Kernel File Systems... [ OK ] Created slice
system-getty.slice. Starting Create list of required st... nodes for the
current kernel... Starting Set Up Additional Binary Formats... [ OK ]
Stopped target Initrd Root File System. [ OK ] Reached target Slices. [
OK ] Created slice system-systemd\x2dfsck.slice. [ OK ] Mounted POSIX
Message Queue File System. [ OK ] Mounted Debug File System. [ OK ]
Started Read and set NIS domainname from /etc/sysconfig/network.
Mounting Arbitrary Executable File Formats File System... [ OK ] Started
Journal Service. [ OK ] Started Create list of required sta...ce nodes
for the current kernel. Starting Create Static Device Nodes in /dev... [
OK ] Started LVM2 metadata daemon. [ OK ] Started Remount Root and
Kernel File Systems. Starting Load/Save Random Seed... Starting udev
Coldplug all Devices... Starting Flush Journal to Persistent Storage...
[FAILED] Failed to start Load Kernel Modules. See 'systemctl status
systemd-modules-load.service' for details. Starting Apply Kernel
Variables... [ OK ] Started Load/Save Random Seed. [ OK ] Mounted
Arbitrary Executable File Formats File System. [ OK ] Started Set Up
Additional Binary Formats. [ OK ] Started Create Static Device Nodes in
/dev. Starting udev Kernel Device Manager... [ OK ] Started Apply Kernel
Variables. [ OK ] Started Load legacy module configuration. [ OK ]
Started udev Coldplug all Devices. Starting udev Wait for Complete
Device Initialization... [ 24.427217] megaraid_sas 0000:65:00.0:
megasas_build_io_fusion 3273 sge_count (-12) is out of range. Range is:
0-256

[   24.427217] megaraid_sas 0000:65:00.0: megasas_build_io_fusion 3273
sge_count (-12) is out of range. Range is:  0-256 kept showing
infinitely. It kept popping until I reset the system.

Reverting the following patch seems to fix the issue:

commit 07c9cccc4c3fecba175a7e5aafba6370758f5ce2
Author: Juergen Gross <jgross@suse.com>
Date:   Fri Sep 13 12:05:02 2024 +0200

    xen/swiotlb: add alignment check for dma buffers

    [ Upstream commit 9f40ec84a7976d95c34e7cc070939deb103652b0 ]

    When checking a memory buffer to be consecutive in machine memory,
    the alignment needs to be checked, too. Failing to do so might result
    in DMA memory not being aligned according to its requested size,
    leading to error messages like:

      4xxx 0000:2b:00.0: enabling device (0140 -> 0142)
      4xxx 0000:2b:00.0: Ring address not aligned
      4xxx 0000:2b:00.0: Failed to initialise service qat_crypto
      4xxx 0000:2b:00.0: Resetting device qat_dev0
      4xxx: probe of 0000:2b:00.0 failed with error -14

    Fixes: 9435cce87950 ("xen/swiotlb: Add support for 64KB page
granularity")
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

I tried changing swiotlb grub command line arguments but that didn't
seem to help much unfortunately and the error was seen again.

Thanks & Regards,
Harshvardhan



From xen-devel-bounces@lists.xenproject.org Wed Jan 29 10:16:45 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 10:16:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878961.1289242 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td57k-00057h-QT; Wed, 29 Jan 2025 10:16:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878961.1289242; Wed, 29 Jan 2025 10:16:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td57k-00056Z-LS; Wed, 29 Jan 2025 10:16:44 +0000
Received: by outflank-mailman (input) for mailman id 878961;
 Wed, 29 Jan 2025 08:44:00 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=XMr0=UV=oracle.com=harshvardhan.j.jha@srs-se1.protection.inumbo.net>)
 id 1td3g0-0005T2-Tc
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 08:44:00 +0000
Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com
 [205.220.165.32]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2dbc6788-de1d-11ef-a0e6-8be0dac302b0;
 Wed, 29 Jan 2025 09:43:59 +0100 (CET)
Received: from pps.filterd (m0246627.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 50T8WmsL022053;
 Wed, 29 Jan 2025 08:43:48 GMT
Received: from phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com
 (phxpaimrmta02.appoci.oracle.com [147.154.114.232])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 44fgw9g0pr-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 29 Jan 2025 08:43:48 +0000 (GMT)
Received: from pps.filterd
 (phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1])
 by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (8.18.1.2/8.18.1.2)
 with ESMTP id 50T85Vnx011648; Wed, 29 Jan 2025 08:43:47 GMT
Received: from nam04-bn8-obe.outbound.protection.outlook.com
 (mail-bn8nam04lp2043.outbound.protection.outlook.com [104.47.74.43])
 by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id
 44cpd969j1-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 29 Jan 2025 08:43:47 +0000
Received: from PH7PR10MB6505.namprd10.prod.outlook.com (2603:10b6:510:200::11)
 by CH3PR10MB7931.namprd10.prod.outlook.com (2603:10b6:610:1cf::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.23; Wed, 29 Jan
 2025 08:43:45 +0000
Received: from PH7PR10MB6505.namprd10.prod.outlook.com
 ([fe80::83d9:1bf1:52cf:df54]) by PH7PR10MB6505.namprd10.prod.outlook.com
 ([fe80::83d9:1bf1:52cf:df54%6]) with mapi id 15.20.8377.021; Wed, 29 Jan 2025
 08:43:44 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2dbc6788-de1d-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=
	corp-2023-11-20; bh=1C9X2ThXQrZM3UQDIQxzqE/trsk815QmfEuZn0iiLCs=; b=
	H5ybkT+UgIXfxoP8vw7HVkpYxpiqYO+PdXkHPyOrUoFpv3uBkxIkYnQ5jlBuiusn
	SSfr5VAM0XqJuDW7EWJc6qhNgF5uswEClwJCXpqqTaw6ZgarAk1v5fpOi/9qJDdj
	+8KFwjHVnpjG2hZGHuNIw3ylHNh/RViUIwNIpOpa1SA2kr/+ALt2Yowc7mM+8ZwL
	c420RAMjltp3EGHmA4F/leagfZ5ljBQYHsgUw4BcNHsqBOsDpPzDyqYgPRdxmSVX
	euZoevCCnpInj9B0sO5zW7pAVOYfzW84SXX32pmacrqURSy/scQ2SkyZ1FqB1dIk
	xMb3FyP9kLS6hC5nzm4WeQ==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=lyUErxRd7xuIoudjErBivqYdpm++r4zbKQmEPSfRmg7mWQgLlxOthGeqpXTASSxuLmThfr+X4qVYfR0ODtF5lpWvMHHNOOVhCQYDmai1lUpwLIqyNQj94s6SyqDcwU6TYFdI1h+7hbvWRUXn0CzSCu6kSSoETNB2OUDXvjGNa6nZOp0LzsUp0/qgPPJNMXyFns8ra6UGOYZiikgVT6WkEfqYbmTu0PkUgKVnjI3V/PJOUm1KAfYEGKduq5zx0flZUH+Zz7Asq+j3f6uEZPAMIEnmymX5RWQo5dQQ0OYnK1DSuihJwWhNHl3WtIYu6fxpG/wZaGFSOorh51dU04DAsA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=1C9X2ThXQrZM3UQDIQxzqE/trsk815QmfEuZn0iiLCs=;
 b=xlChpykt8c8zBdYyJk8c9TJeyXIDa9AvkDDU+c7GVKq1wzaXFag3zTijqUEhpc1BmDOjb5nnmBm2Mhe58ctHlP6rfjoMmVBSMCQe4/NA3KVK8i8gxOn6CT0YuRw085IPiiaRbxoS080sS8xmXct08RIP0qQHyzzW6IaEbGkLLXTjKd6TVLBNlZT1hgu1BaHCpXcrQl4A3EyebdI+pG5LK8INqYLrDQi5sXcZ1jO/37kZjS19cWf8VvpUQF2WqDQC/dhq8YcFAhcOxNk7lUiJnzhbA8d2dc8pmo9f8bNHqRGDIc6d4MrBqkM6JLCjPVLIZOGYbfwf4L0tXvlmS5s7jg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
 dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=1C9X2ThXQrZM3UQDIQxzqE/trsk815QmfEuZn0iiLCs=;
 b=zr0mH2heGUXElhKasELmEE2a2jh6BuOyvbjG5fx3Jg6S5POonax+32ILxQym4DNuG0iUHeQrkAWy8YZlES+mU8tR6oLTf2bPZjPW4EehUyIhiDEZW5gfWX2gm1dEVHAuv3lbV/HHocgoNXtGLTznNpGp3KGh7hjYy/G6drIaQjk=
Message-ID: <8eb33b38-23e1-4e43-8952-3f2b05660236@oracle.com>
Date: Wed, 29 Jan 2025 14:13:34 +0530
User-Agent: Mozilla Thunderbird
Subject: Re: v5.4.289 failed to boot with error megasas_build_io_fusion 3219
 sge_count (-12) is out of range
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Konrad Wilk <konrad.wilk@oracle.com>,
        Boris Ostrovsky <boris.ostrovsky@oracle.com>,
        "jgross@suse.com" <jgross@suse.com>,
        "sstabellini@kernel.org" <sstabellini@kernel.org>,
        "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
        "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>,
        stable@vger.kernel.org
References: <7dc143fa-4a48-440b-b624-ac57a361ac74@oracle.com>
 <9dd91f6e-1c66-4961-994e-dbda87d69dad@oracle.com>
 <2025012919-series-chaps-856e@gregkh>
Content-Language: en-US
From: Harshvardhan Jha <harshvardhan.j.jha@oracle.com>
In-Reply-To: <2025012919-series-chaps-856e@gregkh>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: SG2PR01CA0136.apcprd01.prod.exchangelabs.com
 (2603:1096:4:8f::16) To PH7PR10MB6505.namprd10.prod.outlook.com
 (2603:10b6:510:200::11)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH7PR10MB6505:EE_|CH3PR10MB7931:EE_
X-MS-Office365-Filtering-Correlation-Id: 21a6212e-f625-4a92-6a44-08dd404109cc
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?TnU3UC9uVlVmUmlKM1R3RWZPWjV2RGkwSmlJRlpoa20zUlNKcW1VQ0pTVWNs?=
 =?utf-8?B?Ump2MjNRUUhtRVRIWHpESXlQdjU2ZmQxUllmb2UxOVhLazUwZGpacU56STI0?=
 =?utf-8?B?UlVZSFh4ME1DN01sYVFEdkwveU9BcElXbDFDcHRMcHFMckdUUnBQRnJ5eUkz?=
 =?utf-8?B?dGQ5RFgzSjlWR1gyc0VHWTFqYVJPelZBV3pSQWZaRzR3UVlqSWpmOXkxZzN1?=
 =?utf-8?B?UFROSUN6Z2ptUFlFTkhMU0pJclhUeERFQ2FJalBDMHFEL3FYcG4xQzRPaVk4?=
 =?utf-8?B?L2lDTHVXMm9YRm00TTdZYWZ1STRpNXRzTnJLQ2k2Z2dOUkRYYkN1UCtRZGVH?=
 =?utf-8?B?VFZWS3RzQ2NCQ3ZlRlgyS3lWeXRxd2xEU0tPeFFvalphMm1ZQmtRN2Y5SXFt?=
 =?utf-8?B?OXdjTzZLaEdsS0J0emFRZjc0c0xJQkpsODRnZytDOUQ5aWFMQ2x0Q1BwN2xQ?=
 =?utf-8?B?dGFaNGZldDZYYUExR3Viekp6elg5d2NGVW8xT3dtc2EwbEJDeTc1VUlZMTMw?=
 =?utf-8?B?Rm1Za3dyZ3BzODBEM3NqR1JmUXozRVFLNkZhcEZKc0hJZFNRV08wMFgreGln?=
 =?utf-8?B?ZGtCd3VmTTBhRUdPb0NlUWpjWVNjR2dlQ29wZHJETVlsRVNDQ05mQkxka1ZN?=
 =?utf-8?B?Yk1xR0EyNi82ejYxcFRHb3FUOWRzWEtRbW9iMkg5YjkyWjRNSzdwL2NoLzZT?=
 =?utf-8?B?RFJlSGU0VWkwRXdPOTRBbXArS21vakRkR21iN1F3SVgrazFUSnJZbzJjZkdI?=
 =?utf-8?B?TzlXSzdFcnhqY0JldnVtUG0rTnJtRVl4eWpGOEY2UDNLSytGQ2ZJeHJ2N2pD?=
 =?utf-8?B?dUFEOHRib2k5K2Z2L0Q3UTZoMC9BaDI2RDcyT0JMY053YjVNcVdyUmQ5MjE4?=
 =?utf-8?B?ZmFvUlJ6K2J4Vy91QnN0ZGVDeXluN0tQUEF6ZG1URWl4Z2Fodkhud2FYZ05s?=
 =?utf-8?B?Z1F1MnU1Z1hUck5oWXZGNlVkQTdVTm9YYk90d21Fc015TEdsdVJnem53WFhO?=
 =?utf-8?B?Z0xXMTU3ODlDSW85RW5CaWxyR1NjVFN3ZmpiMlRodXFiWENTYlEzb2xSeEdh?=
 =?utf-8?B?WmtpdjNTbktmclhqTFo5V09KR2FJY3hqRXFzaUNBZ1A4aUI1TG1IenNLenEv?=
 =?utf-8?B?cmhZVEkzNGhUS2xlUCtZcGM3Nk1hak5qTEd4T1RGak1rMUR4Ky83ZVNJY0hY?=
 =?utf-8?B?cTEzN2NPWCtwQzh5ZGdJVy9UUXlkZ1hEcTM3eWpxOWJWcUk3Mml3UTlSbFdo?=
 =?utf-8?B?ek4zMTdXa1ZsSUNkTjg1U3pqVHJOR2p3Q0JUY0d4MGNTMnR6ZEhobUFKTE0y?=
 =?utf-8?B?aTNSUUVwTEpVWVZtQnZXWnhyaXVUNXZNeXdiWFJUVDV1Y3pIeDl0Z0c4a3hY?=
 =?utf-8?B?VlVOa2NZNkJ1RnlaVFRVMnJmT2xPaHRsdWFFS3kxVS9yY0VDTFYwZTVPaXNy?=
 =?utf-8?B?M0ZKOEVwZ1U3ejlUdUt2REw3V21ZUjl0TWZra2MwUCt3WW1ZVUNPMUJ5M0s0?=
 =?utf-8?B?dVFqNEFRL3BoVnFXRDVLeGxSZ1FWZlZFR1RkMllSUWFuakVLYkNna096VFMw?=
 =?utf-8?B?WG03alVySFU2czNQM1BtajJIUjJNY3o0eURPSnphbGpDZG5INTEzdmJZS21x?=
 =?utf-8?B?Ri8rWXRnaThIeDgvK0ZmOFVRMHZrN0xDbk1wWi9jNkxtaEsyTXVRSGhNd0o2?=
 =?utf-8?B?RDkxT3VtMlJBQ2YzODMxL0RVM1BLWkdzYk1lajROUDNhMEVZaGV6ckV2b20v?=
 =?utf-8?B?ZktWeUd5TVkvL204OWd3RCtvUVdldHBMMkFxVXhIZkd4NmdKODY5bGhCcTBZ?=
 =?utf-8?B?ZU5remFrN0loeXNualZSWjJ0UlFUbGFKaU5ZalFMamhrd1psSk9BS3lLV1Vv?=
 =?utf-8?Q?uyzsa6vHajCfe?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH7PR10MB6505.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?clJYT29WTGROWllrZUlKSnY2N2dmUXIwUnJKckFuR0NMeDFvdjhVL0ZOcnRX?=
 =?utf-8?B?YzR6THBHUk0zWmdYbDlMZmcwVHZUdHlJQ3ZKaDRYT2xxaHJhem56T1REaUtv?=
 =?utf-8?B?eXl4dy9wNUxVMHNyb1dlaDlHTEg2VWUzV3FFaVh0Y3pQQ2g1NVY4Q042RXpa?=
 =?utf-8?B?V25wYnpjTHU5MGt2bXJXNEo2L2RxUFc5R2xpRC9zNGdTNGFPYmhrcVlhNTd6?=
 =?utf-8?B?eHVoMHNBY1dsN01NaTBwN0tMWjNIN01SWnNqeFNDVWpveHJkaXNDeWNnUWgx?=
 =?utf-8?B?RUJqWi9FVGxodWNOak02Q2pIUWlUWEZMSWRYbjdxVzkwbnZheDJyQVJvUWVC?=
 =?utf-8?B?eUtibGcvTUZXWkhPbjN2b3lrNGlEc1dsbUF6Q20rWVJsVTg4Zngrb2JJU1hx?=
 =?utf-8?B?bkZIVDZpVVZPV1V6djJJckRwdFkzT0UvcU9Mc0xMZzFlejZ4T3NnVC9CMnVy?=
 =?utf-8?B?NW9JSlNHT0lVQUpndXhEdU8yYjc4a2dHK1BWa0NIQXg4NTdLdlBFT3c3NlJS?=
 =?utf-8?B?MGxuSkF3YVNFREJXSVZRaHlkdHQya0ttcytIcGlxQVpSVlhyb1hjV3NhdVov?=
 =?utf-8?B?MDlMY21xN2VGM21wMlErVUY3WnltUTJBQUVabFZIZ0hLVGwzMG1VNkFSaU9B?=
 =?utf-8?B?T3NVU1J5TEhqT3NmSEFzRjllU01Lb0JTWWV6bDk5aUd0Uzh2NURjZGtNTi9M?=
 =?utf-8?B?b1ZiOWVxRGpOckJIS1c2SFBYWVIwTzcrNkxNREtpM1JRYm9VMWpQNXFOaVRm?=
 =?utf-8?B?WGhLT0ZYOU0xSXJYQ3Jpa3MvMXVHRCtUMDltUXVXaUVBOS9SWUlpelBHRE14?=
 =?utf-8?B?ZituK1JLYzhFTDlLdDFPS2QyRVV1Y1loZFpYU1FqUG5xdlNGaytUdVNGeUI0?=
 =?utf-8?B?R1FpcjVscTJEcGtNaS9OTnhJNktTbWVoOWhKSDFPT2x6YWt4NFE3bW1wNlpu?=
 =?utf-8?B?dWppcDJISVc5T2ovL1gvVWR1b3YvVHFUeWhPZ01vSHd4V2lnU2E4NUZRU09V?=
 =?utf-8?B?VENBQVhoK3J4QldSWDEwWTVKdXQ3OWQ5UTFOSlZ5TVA1NjdKOGlqcFNOcGkz?=
 =?utf-8?B?N2NwaGNxb3gwYm1XMXVoVE0xVjFFV2pkZUN5MC8vMTlpUFRWWXZncTkwZHhr?=
 =?utf-8?B?L1RaQm1oMUJWZG9IQWRBUGhxajYrMXlPVTNsNzdIVi9ubTVHc2ZhckJUVjVV?=
 =?utf-8?B?WEl5YXFoZ0hwMDZZUzRSVmZvZDU2a3FrNjNMNVduY1lwZzJ1V0hicUhDKzVB?=
 =?utf-8?B?SmI0OC84ak1KTm1sTE55Q0dXMkRGNEdzcWtGQXBDSFVNU2xFVmNEQ3ozTTNU?=
 =?utf-8?B?SG43dEh4ZHZoSFo0YXhJS3ZuZ3hiVUVuUlhrbWZmZFJydFhsaDdQZnp4L1Nl?=
 =?utf-8?B?T2tQOVpKYThZOVgwR043WUkxcjYzYjNMY0ZZaGxFQzQrWVBZNmVsSHUxdnVL?=
 =?utf-8?B?RDloWndqeDRtOFpMTnRFU3BUNXdNUThaU29mU3phSFdIR0FtV0VqblNuU0Yy?=
 =?utf-8?B?T0QyTjlQVUtoTlBZcmtDbzdHUzAwa1lqcVQ4eTA1d0lVNitTa0RueGhneS9s?=
 =?utf-8?B?TVk0cC9WMG9scTVWRWVwVWV1NFJYYWMyVW5RMUhYTEhRZTM4V1FIVVlUZWZV?=
 =?utf-8?B?RG9wK2dtVVdqT3VTQ1RQTVdBNUlodXJwaXNhMzdrSnJDM2RPdHhFdjAyZDN1?=
 =?utf-8?B?SHVqUFZpZHI5Yk9zUVFlZWNwRm42SlRMTHlJenFCODZBL084MmYzRHBtd0Zs?=
 =?utf-8?B?WmpQdUpMUGdpeTZYREhXQUdQM2tUMUgwb0ZiTjZRQ20vdVZRN3hvZ3BCZnVC?=
 =?utf-8?B?U0RydGZlaWRoRStyUmZObkR0TFFoL3FrMW9kWnNXTFFkODQyUUgzeDJJdFAw?=
 =?utf-8?B?ZmU0cXNJcjlpdTA5Y3FGdzJXeEROZmRrZFBkdUwrZUFRdkFaQlhwQ3JhdnRt?=
 =?utf-8?B?RWF5M2Y1OWtRQzJlRXdsRkRGcGZ1cXIySWNmTmptb2hKYkg0dERmYXdIdnpy?=
 =?utf-8?B?VDd6aTNVWTJ0bHZ4ZTlXVHZMYmoyT2dXQ2lXbC92WVVwaTE1VG0wMHdsT2No?=
 =?utf-8?B?YmcrNko4Ty9ZMENlTEVkYkZ1Q0cwQ0JtYjl6am0wcFd3M1FHTWtGaXBlMGNZ?=
 =?utf-8?B?b0hJYUlMYUd6ZnljeUlRZFJJZ0JRQi95a2k4OGtKbjN3eUV4UDJPVWM5aW9t?=
 =?utf-8?B?aXc9PQ==?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	kSoHC9c63aoYQbKD8jfJFo8RfBun3IGn0N5adNa484R5FrD7a8eNvtd++yJZawgJuawg3LQF6OGrfN08Gc4CVLjsMAfvC0DgHlpQ4iPIdjLF+WyVq9GqAIQFCubCeqkSaPFVbzAb5TYrqKpXaHhTKIUx20BWRHsp/BrFQzE+tykuxY5quY5cUkPNrAUkSAcXkpqF4ufAnEOv60Ku5ilojhUyckFfjB2U/QXFYcwqR1UX1euFehMJW5k3/AQZ90aCdbSeLXvnB3+/1q5J6S1FK8VFG7xnoSVmTAySCfH0iwZrG8BgAAl9fOFuTXlgwmQdb5uw75kkQ6r1X/dc/VAqijqqS8h8A0Zo+IGdCFrc793GXVLdh5ohoFCnwrw3Y7gZ2Yk29ghs9cdW5SDNAENHnzkaAA0u8nGVuH5GqLI9nMvXhTLra8e0O3nHuUTeWr52TpTKcLxSun8UoxV7BZFRQSfiakcZxC2Z8zFI/ZR4OPmThCaqqsgHZpFpJKp9oq3lQMq7UnVZboGHrAcq5mVezPAfPLHZ1i3twX9Qig/4AhCHir11n/DU0vIsjyhDmdvqSkPZbIOEI4LrUcKHfSQQYDMShLEDH87oKmqYTM/Y3RQ=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 21a6212e-f625-4a92-6a44-08dd404109cc
X-MS-Exchange-CrossTenant-AuthSource: PH7PR10MB6505.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2025 08:43:44.0881
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 7f577pG5TU/fLI4WZX80gFBq8hrWDqKUgFQaB3zQTxI16kyc7AxHTKiu9PCP0lbMWgW7PM04F84XTsCy84UW/RS48AHsPqx0wJXAVc6/R8s=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR10MB7931
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34
 definitions=2025-01-28_04,2025-01-27_01,2024-11-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxscore=0 spamscore=0
 malwarescore=0 mlxlogscore=999 bulkscore=0 phishscore=0 adultscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2411120000
 definitions=main-2501290070
X-Proofpoint-ORIG-GUID: fg1b5FolzACU0QYtbLXLghcN4iEzFhY9
X-Proofpoint-GUID: fg1b5FolzACU0QYtbLXLghcN4iEzFhY9

Hi there,

On 29/01/25 2:05 PM, Greg KH wrote:
> On Wed, Jan 29, 2025 at 02:03:51PM +0530, Harshvardhan Jha wrote:
>> Hi All,
>>
>> +stable
>>
>> There seems to be some formatting issues in my log output. I have
>> attached it as a file.
> Confused, what are you wanting us to do here in the stable tree?
>
> thanks,
>
> greg k-h

Since, this is reproducible on 5.4.y I have added stable. The culprit
commit which upon getting reverted fixes this issue is also present in
5.4.y stable.

Thanks & Regards,
Harshvardhan



From xen-devel-bounces@lists.xenproject.org Wed Jan 29 10:16:45 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 10:16:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.878948.1289235 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td57k-0004zh-Eo; Wed, 29 Jan 2025 10:16:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 878948.1289235; Wed, 29 Jan 2025 10:16:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td57k-0004yh-Ao; Wed, 29 Jan 2025 10:16:44 +0000
Received: by outflank-mailman (input) for mailman id 878948;
 Wed, 29 Jan 2025 08:34:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=XMr0=UV=oracle.com=harshvardhan.j.jha@srs-se1.protection.inumbo.net>)
 id 1td3WT-0003Q4-Ia
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 08:34:09 +0000
Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com
 [205.220.177.32]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id cd81b93a-de1b-11ef-a0e6-8be0dac302b0;
 Wed, 29 Jan 2025 09:34:07 +0100 (CET)
Received: from pps.filterd (m0246630.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 50T7thEW015196;
 Wed, 29 Jan 2025 08:34:02 GMT
Received: from phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com
 (phxpaimrmta01.appoci.oracle.com [138.1.114.2])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 44ff7c87dc-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 29 Jan 2025 08:34:01 +0000 (GMT)
Received: from pps.filterd
 (phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1])
 by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (8.18.1.2/8.18.1.2)
 with ESMTP id 50T7ABRm034289; Wed, 29 Jan 2025 08:34:00 GMT
Received: from nam10-mw2-obe.outbound.protection.outlook.com
 (mail-mw2nam10lp2046.outbound.protection.outlook.com [104.47.55.46])
 by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id
 44cpd9ddcr-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 29 Jan 2025 08:34:00 +0000
Received: from PH7PR10MB6505.namprd10.prod.outlook.com (2603:10b6:510:200::11)
 by DS0PR10MB7344.namprd10.prod.outlook.com (2603:10b6:8:fe::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.22; Wed, 29 Jan
 2025 08:33:58 +0000
Received: from PH7PR10MB6505.namprd10.prod.outlook.com
 ([fe80::83d9:1bf1:52cf:df54]) by PH7PR10MB6505.namprd10.prod.outlook.com
 ([fe80::83d9:1bf1:52cf:df54%6]) with mapi id 15.20.8377.021; Wed, 29 Jan 2025
 08:33:58 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: cd81b93a-de1b-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-type:date:from:in-reply-to:message-id:mime-version
	:references:subject:to; s=corp-2023-11-20; bh=hskzXJhH+9QsGBaXJ+
	qwrpYPYCD/JMlDNEtD4vgt/ZU=; b=AzOudf6rLU13ZMVOueKoVyLB8K6BIQulNB
	sTgbUXhxQLhyiX/50/WJOna0bWBOeXDpm8Wp4eJW4T2XC7ShY67SCUhSsujxn7P2
	I+c+xeLYQZgZNigXs4k/uEcePTG7HIoyhO/DA0yatcViLaE8v4Iuzy3STGeiAbAH
	6v3eI7qP8Uns8N/3rNjuxC/aGgJ3plFoOtWOXzoclTOleMBOZ4KUJqmd7Cn6RYQ1
	4+x9VLKMiWiIK5TfmG5p+TKvcQdjP0VDjoXtND1HpxjBCIS7MZycRLZ7nX0SGezk
	EsdtbNIxJgm3FIjJlBseDkINihlnFKu46+ogUSEseY3FrVel2n5w==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=HLVoadxzTE5Crub5H3AINfTZD/t6sy53wnNYsQVNtCWiPZyObbhIBn3W57NRWfNPvPg9zW/2DhqTC1Y/d7Yv1SSo7fpsW7u/Ncn9EiCt89JaprHsdnr9DKxYV4E4BwMErTbt9XVJma59wB21K9oo5rgQRrCRFXKmvmUVitIt+6ydF8k6qblyWsmOYI3O16GfSaDmyq2nCaL+rpNSIsXm0WxgywGpELhxyjA1Z43FdXHwhYvj2TeZ2ax87npyExYR7vd7EYeOVrlOn44qzDUheAgoJQNaIz3TI/qZRhkNl8x0+VnuYKz56EdPrPP60lErWoH2VznsEHcYty8m40cqaw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=hskzXJhH+9QsGBaXJ+qwrpYPYCD/JMlDNEtD4vgt/ZU=;
 b=VVZ4j64HR55hoPhVMeT8yHPuq7PysYi8Yp0TgiOpPzFbwsnQlyJItUh12WMeDE7hL2cBfSAsoYHyyR7PCK258PLvTJrj3YbnjTw2Yo50hRK9pVKXpYZoM7ZgcvFwm5bomuEvCSfjIrzYN9Hh0cSv64iS/eT8kATDuJ85VkcZ7hZ/V3UzdnQ+VG4iCWEQ5GCiIXRmQv2EfY+P1Lvs9yp5IPQicA9yZe6mDjwOVhfF6OxnhDzllt56hn2C0taJUkp2CaCw6cvZv1X/0g1z/N2skMcNu2wvnW3YD13ItfivRcEqIi78ogLDJUqK98Dh+3zVceTMeQqXry1e7yoXY5frww==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
 dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=hskzXJhH+9QsGBaXJ+qwrpYPYCD/JMlDNEtD4vgt/ZU=;
 b=SuoH/5f2/H0vDg+Nc5lYKt5OUTARZEXWTdw1tUsFhTQxmnv3PU/iO0QFu3kVuCqHbxDw+ZHsqfPZMQHXxzp3+9k3ks+W6kroHUPWU0Ju5Pi0pW9gdVRg2a0jUGwZAjMni4CBLBx5Q7R9/+voX8PfFSo6RAdBZ8mbz96QL8o4A+4=
Content-Type: multipart/mixed; boundary="------------wonoJ16T7QXkai8nxcHszemM"
Message-ID: <9dd91f6e-1c66-4961-994e-dbda87d69dad@oracle.com>
Date: Wed, 29 Jan 2025 14:03:51 +0530
User-Agent: Mozilla Thunderbird
Subject: Re: v5.4.289 failed to boot with error megasas_build_io_fusion 3219
 sge_count (-12) is out of range
From: Harshvardhan Jha <harshvardhan.j.jha@oracle.com>
To: Konrad Wilk <konrad.wilk@oracle.com>,
        Boris Ostrovsky <boris.ostrovsky@oracle.com>,
        "jgross@suse.com" <jgross@suse.com>
Cc: "sstabellini@kernel.org" <sstabellini@kernel.org>,
        "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
        "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>,
        stable@vger.kernel.org
References: <7dc143fa-4a48-440b-b624-ac57a361ac74@oracle.com>
Content-Language: en-US
In-Reply-To: <7dc143fa-4a48-440b-b624-ac57a361ac74@oracle.com>
X-ClientProxiedBy: SI2PR01CA0037.apcprd01.prod.exchangelabs.com
 (2603:1096:4:193::9) To PH7PR10MB6505.namprd10.prod.outlook.com
 (2603:10b6:510:200::11)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH7PR10MB6505:EE_|DS0PR10MB7344:EE_
X-MS-Office365-Filtering-Correlation-Id: 590728d1-68bb-408a-5f62-08dd403facc3
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?ZHcvS3ByR1FrT0ZXb3Zob2l1dzg1REg2a2lQeDB6WU41dXk1L3JiOHNBdWN1?=
 =?utf-8?B?YmJZaG9lc2hMb3VxQkVsZ2xwOEJCQzRncVk3RFJjN3UyRnRkbzFRNkpyRHov?=
 =?utf-8?B?cG9LY3d1MFl6MzZESnE0TUcrQ3N2Q3dWaVdqQklTcTZvbU9aLzZQQUFEdzdZ?=
 =?utf-8?B?TDREUnZSL2FOSUk4aXVQQnE1Ymh5OFR6WUJKODVNQXFRa0xubVVvaGpxK09w?=
 =?utf-8?B?QkQrS3JuYmNXZGwxYklhQ1V2VGpTcS9jMGo0MEh3bCs2bUk1Y2pEMHViSkhh?=
 =?utf-8?B?b1pIK0ptOTA4WXNadG1HV1RiaTBReWEzV2hLMzFVdWh5bHhrYnQwM3pwNXp5?=
 =?utf-8?B?ZTFPa2svT2gxQmFoQlRiNDU2SWdCeW9GUXJlbmFId1JwbnZUQS9sZ25CMXI1?=
 =?utf-8?B?QTI2d3hlWDBESlVrWlkwUE50bktrN3I4ZUFTWHNIMWZNYjV0M3ZCYkRGRjI1?=
 =?utf-8?B?TzJjdGVGWFlUeE5hODQyRDJlMzZaVWlLRlJob0NMMjFKVVFVa3ZmZmdnMEVi?=
 =?utf-8?B?ejkvUzRYWnJFbGJlU3RSN3JSYVJUcGJ0cTc2U0dpYlZSUmZNaW8rMUp4VkxD?=
 =?utf-8?B?b0xpSStSdU9DVDV2RzE3dmNzc1ZiampGcEx3Y3d4SEJvbEM5TStUdnFUb2FQ?=
 =?utf-8?B?c25xS1h1N1VaUC84VGJEblZRWURHaFBpVjV1VU9pa0RiOU9aRmxHcURZL21t?=
 =?utf-8?B?MVYzNGF3OGM5bXN1RXRGUnF5ayt6bWFrVUtFcit0K3g5UWhGaVZZVmoveUV1?=
 =?utf-8?B?eTl1VHZvdFZnNjdpM0RkcDFsYlZ4dlZsanFobVJkUENtZ2hKSDBYV29CdWRk?=
 =?utf-8?B?VFRPQURTME9HOVhlNkIrbmJ3SldUVSthNllndDJVbmdVVHkrNU1lZTRxQWVh?=
 =?utf-8?B?M2RLVVNIQngwckRpUEdvN1FrWHUxbzIyZ1lTZDI1NVRMaXJHVTVTa3R3ZCtu?=
 =?utf-8?B?bGpMUGdzNUp2NkMrNmZvTHZxQzQ4bkxCa3lUYjJSektWTlhXQlBCLzFtVENl?=
 =?utf-8?B?SXpsV0s0NFgzUnYzQUowT2xzZ0paTWxTNGhuZkJaNW9yek9JbG05V1F3VzJF?=
 =?utf-8?B?d2R6ZmtQTmNSZTgxUGc3b1VnbEh4OHArYks4dnFid0xnTVNlOEw3SU0zOXlW?=
 =?utf-8?B?WjVOdFYvd01aTDVaMXlPb0w4QkpwdDdPL25zK1RwUG0xcnRpandqUWJUeWRS?=
 =?utf-8?B?MGt1NDRvZmttSnViK3dyWURQVWovaEtJNTErSTVxQUhvS2RhTzZoUFhvS0dR?=
 =?utf-8?B?VTNsQXJVRzVxbm1QWG1WamRPbzg2TVVSa24zYktMa3paajMvb3o3aUJXL25O?=
 =?utf-8?B?YkhNZ003aS8rTFVjRGRKMTJNa29Nb1NZMHl6SHVoSzBra3VBdWdOYVlneit6?=
 =?utf-8?B?OVR3QU1CWlhWT3pnSktsNG02V3pscGVtWXR1cWlNS0NkM2lIWWJ5bWthZzI4?=
 =?utf-8?B?cXRJNXphSGFzSzJ5dFNhTjhrZWxkR1pSdlJ3TXNxNGlwaWU2ZXNBUVQxRnZ6?=
 =?utf-8?B?TzBnQnROVU9aV2paNmkzTnhMbE11RWtvVzVjUnhkdTRndmx3aEFyRTBWZHBi?=
 =?utf-8?B?M1RNS0xwUkFMQUJkNVVDSk9kS0lPclEyMUhncGZnTnpVOHBkNUdmVkVPMDQy?=
 =?utf-8?B?RnAxb29SUzdKWm55b09qV2czaDd3cUkra3JRamg1Z3NISzBJZldjNDU1Smhy?=
 =?utf-8?B?V3FWeUErRmYzTkt5b3crcm9ETDBCT29aSXRCZ1oxTU5sSEdLTENTdURnWFhk?=
 =?utf-8?B?STlVWGFtMWZPcUFFUEZuNHRmdHZCaGJQd29VYldZbVplNzV6bWFxMVZobkhH?=
 =?utf-8?B?NVcweXh6NXRFRlJlU2tqZTFRbGlINWZiMUVFZTFCZlcyMnlJODBKU0R0bVJy?=
 =?utf-8?Q?XPM3UMn+3Jwma?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH7PR10MB6505.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?NzBRSGMrQ0JJY0tJWE9la3dmTE5ScVd6WUJjaTB3SXhPWC9iYlhvVXhkaUMz?=
 =?utf-8?B?THNxTW5GNnp6akNuTFhNWFBFR2VvWE5LeW9hNkh1c3A1MnJSd082UTN6VmF4?=
 =?utf-8?B?QnhwREw1ZnI3N3VwUmlsWE5YNE9XOWdBSXQvNnFaRVpBcmRSdU4wakdVVnUv?=
 =?utf-8?B?OEZZSEIzM3QvRWs1RnlHcDdRTEZiamhhK3A1NTlERTZKT1pPRWZNcGtsa0FK?=
 =?utf-8?B?ejJGbzQzSkQraHFzcWpWclUxbGtlanYySVJMUXNYZGhnRVZXbE10WGFNS2lR?=
 =?utf-8?B?QVlsVEdCZ1IyditrbnFuMXUrT29RL3VVRTlsUWM3eExNS05pV1Rxb3pwTzNw?=
 =?utf-8?B?TXFJaXA5SzZ5a3g3Wm1iOHJTZ3MzUkNiSzBsQVZpekVQZmtWT2xuVmxuNEE3?=
 =?utf-8?B?YVhnZWNVWXNmUXFoZDMwczJYbWRvdWxlL2ZSeFZZSytDR0txYzhwYTVvYklh?=
 =?utf-8?B?bnByWit0YVVzNkt5VHpuN2JpWDN3V3Z6L25VSVJqdjg2TlJQRGRsSHZyNWFE?=
 =?utf-8?B?b3NjRlVxNVJPRFYzYkVmK09UeFBieTJ4YXBNblJkOFppYmlSL29IOUh3UHJ6?=
 =?utf-8?B?bEVKUmRDZURZOUU5UHpTYmRLMFJrekVWYlRDckpzaVZrNTUrV2RjZ3lsekZs?=
 =?utf-8?B?aFEvVVUyTG9YeWpBQ01QcXlpRUZlSW1qcUVqb2VpaUpidURBME8raGJZdkZQ?=
 =?utf-8?B?UGtnOTV6UUJFdUVxSDRvOVl4b3hiL3FQRUExc3VpdVVkRG9LZzdacGJQUXd4?=
 =?utf-8?B?aE5wU0VpaTFKd1RkSjNmeVBNb1ZxUlVFRTh5cE00dVdlcW93RGNhTGVXd3V2?=
 =?utf-8?B?K0RlMm5MRVhGV0k3MDV3RnA0SVhoVHZoOGk4ZTc0ZHNNdFhFM1ZCWXZUcFdB?=
 =?utf-8?B?R3VpK2JYMVMwb002c3k3NzdFMjRVZ2tTdjRTakFXdnJ4RmRnNklFRlVzamtE?=
 =?utf-8?B?QTVaeHdBU25hbkRybkhiemVHS2NJeWE4UFhtKzhZZ2ZMTzIzNW5pdVJkUm9R?=
 =?utf-8?B?eDBRUnVDeTF4WXAwbU5HZW00V1NjM3hZaHhCcXY0SkxmclVKdkl1RXA4TmJm?=
 =?utf-8?B?UUc3SEhpN3V6T0xMdDQ1SU1EQ0NHNUxHa042WEtkY3ljM25MNTJLTUJTMDEx?=
 =?utf-8?B?NElkVFRCOXVzUEpEMzh0cGZVYkI4WEdXL1E1ckVUNndTNUpnZ25Kcm10VTBB?=
 =?utf-8?B?TDNELzdnUkVtRUhmaHZJSGFsanFPaVhPaHVVMDBUUUZBY3VWem1BRDNwVHVV?=
 =?utf-8?B?bDg2VXNGZHJyYlNndGhONzlJVFkzUmRFdDFUTUdUZDQ5dTRWTDd6R2lwV0hO?=
 =?utf-8?B?ZU9KRnQ4dks0ai9VODRPekhaSGNENTJ4dmxzYlFJQjZLYTNTSFYrWlMrYUFj?=
 =?utf-8?B?R09xVUlsVzIraU84dmxkTWx0V3hURUtpenVKbzFjeGpzRHluV2NPOVpHaGJM?=
 =?utf-8?B?M0ZnM0hqb1FvSGcrT0xxUHVGNjBnbmg5anZEZXZXWGt2WTBOYW5tdkVGTi9B?=
 =?utf-8?B?N0t2RkpWdFpBQ2ZTcmpJSlgxNUQ5eWs2WGpDS09JbXBySCs5Z0NJR2hlZmJP?=
 =?utf-8?B?OHEvWHdwSldsTExjSHc3M2lNZy9uRy9rVE9WdFVuOUl6cE5rN0lyVUlBbXNp?=
 =?utf-8?B?WU5IeDBEZU5FQ0lyYktZbklvMUVLOVBTVnNaSFBxM3JnVmpXbFUrWDBPbzRq?=
 =?utf-8?B?NER0YnYzNzlZNVRJQWZMV0R5SllSYWlJbG1uOFV1bW1jRk12Qk5tdXcyejR5?=
 =?utf-8?B?SlRtZjhzc2xPN012dkNGbExzRU9KNTV3V0NRMzcxSlptRG1hTzNWMFBmS0RJ?=
 =?utf-8?B?SXVXR1dsb1o3d3U5TlVJQzcvK1REOWtDQWRablBCNzZFVmZjcEJHUytJL1Ex?=
 =?utf-8?B?K1NQVFh6N2dXaVVGRG1aekgwYkNOb3d2UElaTld6ZXgzZHh2V3pHZ1Y0c25v?=
 =?utf-8?B?WHBLTmFoS2c1RlFMd1cwUlZrNWpCZUJJQ2sxMjl4SFFROWEvc1RnMXk5eWNJ?=
 =?utf-8?B?bWtsOUQxR3JKVk00dUYrQzJ0U1BIUFNma1I5U1EvcHFpWnRsVDZxSG1Nd0lk?=
 =?utf-8?B?OWI2VW4rZmtIaEdVd0s0VkI0SVZ2d29XZklaOWpFMXF2blk3KzRWdm1lMm5F?=
 =?utf-8?B?UitjSGYwbWR5VWJvTXhmb1BraTF0YWVlSEM4SnUvUzIzdklpUDAzMXNyVnhx?=
 =?utf-8?B?Wnc9PQ==?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	5tsyDWgUzNDRn9eiqSmv0hKjOim8ZxSED+B1hJrI5slkRXFniqjJnlQA+N2jtPh0fli83wMZSkDgkNiB4bNJR2BHD+3yimcZ8hhTU6M4Ibr8p292w6gSzR4m7DdLMMV546GQ2/irZZjut0rSEMzDIDZmNea477Cm04O55J43R9yvKeFLznPI5I61P32ZableLrkPgdyrfQx2og26/pMxPQZK6FGwjD4xLR9iDWW3AP5y8WEtmTM1Ax1HC5HE6uTQj0RbISEy64ocMM2KytKJAs4tfd0jSbukzRoqgm19Mw8RPGwMIRMQijVVshGYUjv8rYte4uhQijwo3K0h2THz3HzXy+AqwPDaOp/ufC4M0CDVa8EioCaQKPVNJL7159GV5wJVcd5dJhBmzmUensDq7qmAPtEGUzDx+Dq528yFsyLNvNL4x6pfVSuxUttVTluhu3+xI4OCnj0+FHjco2q7xUI1y7FSnd/pl/IIy4kCCIx+4PnCZ4VUvXYgL2r0DCrLLcygI1e7b4YRlIDQh9uNH+6tgj7fG5//Eyl2RycAyumKeyXE432eZh4CBwLO2AFHr43f/RYpJlthnWVENdiFLM6SBbtJvmsdTEZ1zv7JdzU=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 590728d1-68bb-408a-5f62-08dd403facc3
X-MS-Exchange-CrossTenant-AuthSource: PH7PR10MB6505.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2025 08:33:58.5003
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: RhaPP6BWSCzcMQ4St3U5Sve14BHzsyGPBZqwSp/UGZzGRsDK1x1NkDBEuld5KKV24gBx3+kyGtEk6KfEFUV+nXSwwiZqsMnTFQ8w4eoIetE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR10MB7344
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34
 definitions=2025-01-28_04,2025-01-27_01,2024-11-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 bulkscore=0 malwarescore=0
 mlxlogscore=999 suspectscore=0 spamscore=0 mlxscore=0 adultscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2411120000
 definitions=main-2501290069
X-Proofpoint-GUID: jOSxukBeqx8pGhOhHuoK3ssz4HyOcPSo
X-Proofpoint-ORIG-GUID: jOSxukBeqx8pGhOhHuoK3ssz4HyOcPSo

--------------wonoJ16T7QXkai8nxcHszemM
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Hi All,

+stable

There seems to be some formatting issues in my log output. I have
attached it as a file.

Thanks & Regards,
Harshvardhan

On 29/01/25 1:57 PM, Harshvardhan Jha wrote:
> Hello there,
>
> The stable tag v5.4.289 seems to fail to boot with following trace:
>
> [ OK ] Created slice system-serial\x2dgetty.slice. [ OK ] Listening on
> udev Control Socket. [ OK ] Reached target Local Encrypted Volumes. [ OK
> ] Listening on /dev/initctl Compatibility Named Pipe. [ OK ] Listening
> on Delayed Shutdown Socket. [ OK ] Created slice
> system-selinux\x2dpol...grate\x2dlocal\x2dchanges.slice. [ OK ] Stopped
> target Initrd File Systems. [ OK ] Listening on LVM2 metadata daemon
> socket. Mounting Debug File System... [ OK ] Listening on networkd
> rtnetlink socket. [ OK ] Listening on Device-mapper event daemon FIFOs.
> Starting Monitoring of LVM2 mirrors... dmeventd or progress polling... [
> OK ] Created slice User and Session Slice. Starting Read and set NIS
> domainname from /etc/sysconfig/network... Starting Load legacy module
> configuration... [ OK ] Set up automount Arbitrary Executab...ats File
> System Automount Point. [ OK ] Created slice
> system-rdma\x2dload\x2dmodules.slice. [ OK ] Started Forward Password
> Requests to Wall Directory Watch. [ OK ] Reached target Paths. Starting
> Remount Root and Kernel File Systems... [ OK ] Created slice
> system-getty.slice. Starting Create list of required st... nodes for the
> current kernel... Starting Set Up Additional Binary Formats... [ OK ]
> Stopped target Initrd Root File System. [ OK ] Reached target Slices. [
> OK ] Created slice system-systemd\x2dfsck.slice. [ OK ] Mounted POSIX
> Message Queue File System. [ OK ] Mounted Debug File System. [ OK ]
> Started Read and set NIS domainname from /etc/sysconfig/network.
> Mounting Arbitrary Executable File Formats File System... [ OK ] Started
> Journal Service. [ OK ] Started Create list of required sta...ce nodes
> for the current kernel. Starting Create Static Device Nodes in /dev... [
> OK ] Started LVM2 metadata daemon. [ OK ] Started Remount Root and
> Kernel File Systems. Starting Load/Save Random Seed... Starting udev
> Coldplug all Devices... Starting Flush Journal to Persistent Storage...
> [FAILED] Failed to start Load Kernel Modules. See 'systemctl status
> systemd-modules-load.service' for details. Starting Apply Kernel
> Variables... [ OK ] Started Load/Save Random Seed. [ OK ] Mounted
> Arbitrary Executable File Formats File System. [ OK ] Started Set Up
> Additional Binary Formats. [ OK ] Started Create Static Device Nodes in
> /dev. Starting udev Kernel Device Manager... [ OK ] Started Apply Kernel
> Variables. [ OK ] Started Load legacy module configuration. [ OK ]
> Started udev Coldplug all Devices. Starting udev Wait for Complete
> Device Initialization... [ 24.427217] megaraid_sas 0000:65:00.0:
> megasas_build_io_fusion 3273 sge_count (-12) is out of range. Range is:
> 0-256
>
> [   24.427217] megaraid_sas 0000:65:00.0: megasas_build_io_fusion 3273
> sge_count (-12) is out of range. Range is:  0-256 kept showing
> infinitely. It kept popping until I reset the system.
>
> Reverting the following patch seems to fix the issue:
>
> commit 07c9cccc4c3fecba175a7e5aafba6370758f5ce2
> Author: Juergen Gross <jgross@suse.com>
> Date:   Fri Sep 13 12:05:02 2024 +0200
>
>     xen/swiotlb: add alignment check for dma buffers
>
>     [ Upstream commit 9f40ec84a7976d95c34e7cc070939deb103652b0 ]
>
>     When checking a memory buffer to be consecutive in machine memory,
>     the alignment needs to be checked, too. Failing to do so might result
>     in DMA memory not being aligned according to its requested size,
>     leading to error messages like:
>
>       4xxx 0000:2b:00.0: enabling device (0140 -> 0142)
>       4xxx 0000:2b:00.0: Ring address not aligned
>       4xxx 0000:2b:00.0: Failed to initialise service qat_crypto
>       4xxx 0000:2b:00.0: Resetting device qat_dev0
>       4xxx: probe of 0000:2b:00.0 failed with error -14
>
>     Fixes: 9435cce87950 ("xen/swiotlb: Add support for 64KB page
> granularity")
>     Signed-off-by: Juergen Gross <jgross@suse.com>
>     Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
>     Signed-off-by: Juergen Gross <jgross@suse.com>
>     Signed-off-by: Sasha Levin <sashal@kernel.org>
>
> I tried changing swiotlb grub command line arguments but that didn't
> seem to help much unfortunately and the error was seen again.
>
> Thanks & Regards,
> Harshvardhan
>
--------------wonoJ16T7QXkai8nxcHszemM
Content-Type: text/plain; charset=UTF-8; name="history.txt"
Content-Disposition: attachment; filename="history.txt"
Content-Transfer-Encoding: base64

WyAgT0sgIF0gQ3JlYXRlZCBzbGljZSBzeXN0ZW0tc2VyaWFsXHgyZGdldHR5LnNsaWNlLgpbICBP
SyAgXSBMaXN0ZW5pbmcgb24gdWRldiBDb250cm9sIFNvY2tldC4KWyAgT0sgIF0gUmVhY2hlZCB0
YXJnZXQgTG9jYWwgRW5jcnlwdGVkIFZvbHVtZXMuClsgIE9LICBdIExpc3RlbmluZyBvbiAvZGV2
L2luaXRjdGwgQ29tcGF0aWJpbGl0eSBOYW1lZCBQaXBlLgpbICBPSyAgXSBMaXN0ZW5pbmcgb24g
RGVsYXllZCBTaHV0ZG93biBTb2NrZXQuClsgIE9LICBdIENyZWF0ZWQgc2xpY2Ugc3lzdGVtLXNl
bGludXhceDJkcG9sLi4uZ3JhdGVceDJkbG9jYWxceDJkY2hhbmdlcy5zbGljZS4KWyAgT0sgIF0g
U3RvcHBlZCB0YXJnZXQgSW5pdHJkIEZpbGUgU3lzdGVtcy4KWyAgT0sgIF0gTGlzdGVuaW5nIG9u
IExWTTIgbWV0YWRhdGEgZGFlbW9uIHNvY2tldC4KICAgICAgICAgTW91bnRpbmcgRGVidWcgRmls
ZSBTeXN0ZW0uLi4KWyAgT0sgIF0gTGlzdGVuaW5nIG9uIG5ldHdvcmtkIHJ0bmV0bGluayBzb2Nr
ZXQuClsgIE9LICBdIExpc3RlbmluZyBvbiBEZXZpY2UtbWFwcGVyIGV2ZW50IGRhZW1vbiBGSUZP
cy4KICAgICAgICAgU3RhcnRpbmcgTW9uaXRvcmluZyBvZiBMVk0yIG1pcnJvcnMuLi4gZG1ldmVu
dGQgb3IgcHJvZ3Jlc3MgcG9sbGluZy4uLgpbICBPSyAgXSBDcmVhdGVkIHNsaWNlIFVzZXIgYW5k
IFNlc3Npb24gU2xpY2UuCiAgICAgICAgIFN0YXJ0aW5nIFJlYWQgYW5kIHNldCBOSVMgZG9tYWlu
bmFtZSBmcm9tIC9ldGMvc3lzY29uZmlnL25ldHdvcmsuLi4KICAgICAgICAgU3RhcnRpbmcgTG9h
ZCBsZWdhY3kgbW9kdWxlIGNvbmZpZ3VyYXRpb24uLi4KWyAgT0sgIF0gU2V0IHVwIGF1dG9tb3Vu
dCBBcmJpdHJhcnkgRXhlY3V0YWIuLi5hdHMgRmlsZSBTeXN0ZW0gQXV0b21vdW50IFBvaW50Lgpb
ICBPSyAgXSBDcmVhdGVkIHNsaWNlIHN5c3RlbS1yZG1hXHgyZGxvYWRceDJkbW9kdWxlcy5zbGlj
ZS4KWyAgT0sgIF0gU3RhcnRlZCBGb3J3YXJkIFBhc3N3b3JkIFJlcXVlc3RzIHRvIFdhbGwgRGly
ZWN0b3J5IFdhdGNoLgpbICBPSyAgXSBSZWFjaGVkIHRhcmdldCBQYXRocy4KICAgICAgICAgU3Rh
cnRpbmcgUmVtb3VudCBSb290IGFuZCBLZXJuZWwgRmlsZSBTeXN0ZW1zLi4uClsgIE9LICBdIENy
ZWF0ZWQgc2xpY2Ugc3lzdGVtLWdldHR5LnNsaWNlLgogICAgICAgICBTdGFydGluZyBDcmVhdGUg
bGlzdCBvZiByZXF1aXJlZCBzdC4uLiBub2RlcyBmb3IgdGhlIGN1cnJlbnQga2VybmVsLi4uCiAg
ICAgICAgIFN0YXJ0aW5nIFNldCBVcCBBZGRpdGlvbmFsIEJpbmFyeSBGb3JtYXRzLi4uClsgIE9L
ICBdIFN0b3BwZWQgdGFyZ2V0IEluaXRyZCBSb290IEZpbGUgU3lzdGVtLgpbICBPSyAgXSBSZWFj
aGVkIHRhcmdldCBTbGljZXMuClsgIE9LICBdIENyZWF0ZWQgc2xpY2Ugc3lzdGVtLXN5c3RlbWRc
eDJkZnNjay5zbGljZS4KWyAgT0sgIF0gTW91bnRlZCBQT1NJWCBNZXNzYWdlIFF1ZXVlIEZpbGUg
U3lzdGVtLgpbICBPSyAgXSBNb3VudGVkIERlYnVnIEZpbGUgU3lzdGVtLgpbICBPSyAgXSBTdGFy
dGVkIFJlYWQgYW5kIHNldCBOSVMgZG9tYWlubmFtZSBmcm9tIC9ldGMvc3lzY29uZmlnL25ldHdv
cmsuCiAgICAgICAgIE1vdW50aW5nIEFyYml0cmFyeSBFeGVjdXRhYmxlIEZpbGUgRm9ybWF0cyBG
aWxlIFN5c3RlbS4uLgpbICBPSyAgXSBTdGFydGVkIEpvdXJuYWwgU2VydmljZS4KWyAgT0sgIF0g
U3RhcnRlZCBDcmVhdGUgbGlzdCBvZiByZXF1aXJlZCBzdGEuLi5jZSBub2RlcyBmb3IgdGhlIGN1
cnJlbnQga2VybmVsLgogICAgICAgICBTdGFydGluZyBDcmVhdGUgU3RhdGljIERldmljZSBOb2Rl
cyBpbiAvZGV2Li4uClsgIE9LICBdIFN0YXJ0ZWQgTFZNMiBtZXRhZGF0YSBkYWVtb24uClsgIE9L
ICBdIFN0YXJ0ZWQgUmVtb3VudCBSb290IGFuZCBLZXJuZWwgRmlsZSBTeXN0ZW1zLgogICAgICAg
ICBTdGFydGluZyBMb2FkL1NhdmUgUmFuZG9tIFNlZWQuLi4KICAgICAgICAgU3RhcnRpbmcgdWRl
diBDb2xkcGx1ZyBhbGwgRGV2aWNlcy4uLgogICAgICAgICBTdGFydGluZyBGbHVzaCBKb3VybmFs
IHRvIFBlcnNpc3RlbnQgU3RvcmFnZS4uLgpbRkFJTEVEXSBGYWlsZWQgdG8gc3RhcnQgTG9hZCBL
ZXJuZWwgTW9kdWxlcy4KU2VlICdzeXN0ZW1jdGwgc3RhdHVzIHN5c3RlbWQtbW9kdWxlcy1sb2Fk
LnNlcnZpY2UnIGZvciBkZXRhaWxzLgogICAgICAgICBTdGFydGluZyBBcHBseSBLZXJuZWwgVmFy
aWFibGVzLi4uClsgIE9LICBdIFN0YXJ0ZWQgTG9hZC9TYXZlIFJhbmRvbSBTZWVkLgpbICBPSyAg
XSBNb3VudGVkIEFyYml0cmFyeSBFeGVjdXRhYmxlIEZpbGUgRm9ybWF0cyBGaWxlIFN5c3RlbS4K
WyAgT0sgIF0gU3RhcnRlZCBTZXQgVXAgQWRkaXRpb25hbCBCaW5hcnkgRm9ybWF0cy4KWyAgT0sg
IF0gU3RhcnRlZCBDcmVhdGUgU3RhdGljIERldmljZSBOb2RlcyBpbiAvZGV2LgogICAgICAgICBT
dGFydGluZyB1ZGV2IEtlcm5lbCBEZXZpY2UgTWFuYWdlci4uLgpbICBPSyAgXSBTdGFydGVkIEFw
cGx5IEtlcm5lbCBWYXJpYWJsZXMuClsgIE9LICBdIFN0YXJ0ZWQgTG9hZCBsZWdhY3kgbW9kdWxl
IGNvbmZpZ3VyYXRpb24uClsgIE9LICBdIFN0YXJ0ZWQgdWRldiBDb2xkcGx1ZyBhbGwgRGV2aWNl
cy4KICAgICAgICAgU3RhcnRpbmcgdWRldiBXYWl0IGZvciBDb21wbGV0ZSBEZXZpY2UgSW5pdGlh
bGl6YXRpb24uLi4KWyAgIDI0LjQyNzIxN10gbWVnYXJhaWRfc2FzIDAwMDA6NjU6MDAuMDogbWVn
YXNhc19idWlsZF9pb19mdXNpb24gMzI3MyBzZ2VfY291bnQgKC0xMikgaXMgb3V0IG9mIHJhbmdl
LiBSYW5nZSBpczogIDAtMjU2Cg==

--------------wonoJ16T7QXkai8nxcHszemM--


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 10:16:45 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 10:16:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879001.1289257 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td57l-0005Kp-JJ; Wed, 29 Jan 2025 10:16:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879001.1289257; Wed, 29 Jan 2025 10:16:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td57l-0005Iu-BA; Wed, 29 Jan 2025 10:16:45 +0000
Received: by outflank-mailman (input) for mailman id 879001;
 Wed, 29 Jan 2025 09:15:41 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=XMr0=UV=oracle.com=harshvardhan.j.jha@srs-se1.protection.inumbo.net>)
 id 1td4Af-0003fq-RA
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 09:15:41 +0000
Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com
 [205.220.165.32]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9afad465-de21-11ef-a0e6-8be0dac302b0;
 Wed, 29 Jan 2025 10:15:40 +0100 (CET)
Received: from pps.filterd (m0246617.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 50T8tk1h001773;
 Wed, 29 Jan 2025 09:15:35 GMT
Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com
 (iadpaimrmta02.appoci.oracle.com [147.154.18.20])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 44fgfg05px-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 29 Jan 2025 09:15:34 +0000 (GMT)
Received: from pps.filterd
 (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.2/8.18.1.2)
 with ESMTP id 50T95mCK005511; Wed, 29 Jan 2025 09:15:33 GMT
Received: from nam10-dm6-obe.outbound.protection.outlook.com
 (mail-dm6nam10lp2040.outbound.protection.outlook.com [104.47.58.40])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id
 44cpd9jbcp-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 29 Jan 2025 09:15:33 +0000
Received: from PH7PR10MB6505.namprd10.prod.outlook.com (2603:10b6:510:200::11)
 by SJ2PR10MB7038.namprd10.prod.outlook.com (2603:10b6:a03:4c5::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.24; Wed, 29 Jan
 2025 09:15:30 +0000
Received: from PH7PR10MB6505.namprd10.prod.outlook.com
 ([fe80::83d9:1bf1:52cf:df54]) by PH7PR10MB6505.namprd10.prod.outlook.com
 ([fe80::83d9:1bf1:52cf:df54%6]) with mapi id 15.20.8377.021; Wed, 29 Jan 2025
 09:15:30 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9afad465-de21-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=
	corp-2023-11-20; bh=CKLGZdSLz6tuXwUQv0VUqJTcBmS6840dX+A4C6UHwME=; b=
	dTfH+GMyms4lVZCuPpHzenZN4OpJ6iL7J7hIxJPCtniAmtyydq9TuduL+xj8KIrY
	/9qglvit+psmNc0QaVfq3hc8PAdrOZAzJA7Vf4LpeaEZT+8qWF7zhfb3V6Pb6es0
	tpSOSf+cZiKtyGfhzm+TgAt/EV9ZcI725E1YucZo6Eg9kdVPamoxtkQ7EW7o5njw
	3blNthMy4t+a/F/ECjd3uHIOlsjEe7Ra+ETH5OSWmgIH1Z5PHdPgTL9QIWIv/duD
	6kFkkCrbVKwXtC7mRmmdfRsEeyXF3o8gLzU1HvSxtdXFHM3dRFkfK7nEjgSQRcLZ
	Rpwa6YlUzTjPVgz80uyKdw==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=EjVS0SJS6z+st4MQD8X2ovzUuDY93SC/RTanen6b9kKb+KTMtMXCdEf08eAMHiHV9ERhbIUvPUhiz7pjIoyfHwQJM4wH0lO8LziE+0gAQsvvyqaBXNkTFUk33fsfe8r/7pdlGObnTDmPhOv8rOIh79zQt7P9T+HLTqp5g+/uPx/MdJGrAPSTKJyZHqWXg2v3K/RnBEEsH0lAZ3QCYyjaQ/vLNl7wHD1J+2la9Opof8/hGmUzJBykQrAB2Ry/wUh8shA13GM+J3u4Sivrgwbyxx8BdEtegO+ZwLZNLEibtbm3ZEtB20oaYpLafGLKjtVDZDBRFPxe9Y9G+/UsGsBXNw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=CKLGZdSLz6tuXwUQv0VUqJTcBmS6840dX+A4C6UHwME=;
 b=KXv/5YV7U3rKH9a4VYKJfawaZc2DF9uoGTycwwJTnMtebxe3dCn+ayDZTY8OKXWqLkaoBdnAMDX9zuA0KF7baOzqHLxeP2okR4lNFjm3/L6/oZ7tgpH57/VWWP8mHLOe2hRStGkvojhItqKeD0Dbdd2ayDzYyp5GPT27YuvC3RTVLc+s1pFQLmkux078ZxV4ioLJ6am4XZ9XTwKykcfN40mXmx9IiuSDtPOfjL+N/YXlJ+OLn8xgehJZ1ZZ3xpWsmYrOf0t+IMHVaPHBnBkIMizlX3rwpLnYmnXBNFhjdnvLDLPxpYSN0p6E8aBreGOhtQwb0dbkdtrHrpTaXKh23Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
 dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=CKLGZdSLz6tuXwUQv0VUqJTcBmS6840dX+A4C6UHwME=;
 b=iBDsTzSWLjZPTIiCm0R6qCXH89maM60nPNyN/XjpVCxb5AzDPVgXXl9q0sSiPOqxe78qqiPfncG+dIYQOAiCaNfwMrSj8NrJlPID2VeiXRaxXmqd8/al9KUpF9OYQ2QDVevuePy07iNp1299d++7biNs9SOLS9M3o8u334CF3Lw=
Message-ID: <1f225b8d-d958-4304-829e-8798884d9b6b@oracle.com>
Date: Wed, 29 Jan 2025 14:45:22 +0530
User-Agent: Mozilla Thunderbird
Subject: Re: v5.4.289 failed to boot with error megasas_build_io_fusion 3219
 sge_count (-12) is out of range
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Konrad Wilk <konrad.wilk@oracle.com>,
        Boris Ostrovsky <boris.ostrovsky@oracle.com>,
        "jgross@suse.com" <jgross@suse.com>,
        "sstabellini@kernel.org" <sstabellini@kernel.org>,
        "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>,
        stable@vger.kernel.org
References: <7dc143fa-4a48-440b-b624-ac57a361ac74@oracle.com>
 <9dd91f6e-1c66-4961-994e-dbda87d69dad@oracle.com>
 <2025012919-series-chaps-856e@gregkh>
 <8eb33b38-23e1-4e43-8952-3f2b05660236@oracle.com>
 <2025012936-finalize-ducktail-c524@gregkh>
 <1f017284-1a29-49d8-b0d9-92409561990e@oracle.com>
 <2025012956-jiffy-condone-3137@gregkh>
Content-Language: en-US
From: Harshvardhan Jha <harshvardhan.j.jha@oracle.com>
In-Reply-To: <2025012956-jiffy-condone-3137@gregkh>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: KL1PR02CA0025.apcprd02.prod.outlook.com
 (2603:1096:820:d::12) To PH7PR10MB6505.namprd10.prod.outlook.com
 (2603:10b6:510:200::11)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH7PR10MB6505:EE_|SJ2PR10MB7038:EE_
X-MS-Office365-Filtering-Correlation-Id: 19094e95-81d2-41d0-8b51-08dd40457a34
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?eHdrdGYyaERhUHExUitvZkV5S0xTWU5TZUY4ZWtYa0VnUTI0aWt6VFRtMS9p?=
 =?utf-8?B?bkF2NTRBbHlkbEFYMGh2SDdvamVzSExoNVRDQkNEdnpBbi9UeTkrcTgxbWMw?=
 =?utf-8?B?aGFFaFo1WjNQTk44Z1kxTnJZclM3V3pTVHJzSGJDRnZ1OVBRQkhHeDVyakNj?=
 =?utf-8?B?RlJPL20vSWxEWSs1S2dzRzFBUzBJTm0wTy9ncWNKL2VKRGRpVEM1QmMzYWta?=
 =?utf-8?B?NkpTakZ6OEcvUkprRDVrRzNpRytBWlVFOUhBZEYwZTlvcmQySUE4a0ZUVjB0?=
 =?utf-8?B?UWRaeFJtb0pPSHVaM0NPbzd5N1JrUjNJWnNMM1EvMmhFMFlZNFZNcmRLR2VK?=
 =?utf-8?B?S0V5ZlBKQXBqZXBESE1LT01XQThRMVovZXdkUUZaWUtCdDk4L3Q2cVlTRVVE?=
 =?utf-8?B?aWlJcjhwZHpXMXpUWjFkU2tsU0IyVEpHWk55dGk2RkVUSFdVMFM2cjZTcDJo?=
 =?utf-8?B?SXJMQjdXRFRlT1I1S0tsTXpWU09TTkRxUk5ORkI1MVBjUlQreTZEZkZ0cDFJ?=
 =?utf-8?B?MFFNR3VHTUFCZzRNWGgvcXdtZ1QxK0dpMktmRDBEOG1panlvUlhCZkpRZzlZ?=
 =?utf-8?B?bnMwVUVKY1lITDFpSFpDeC95TG8vMFVzNzdlVURhTXdPdDFkTmpkN3pYbFJ0?=
 =?utf-8?B?N09ZL0J6YW1LRHpGUFFKNkN5STJDeG01YW1XSDFiOGxxOW45ZzVwMUN2NDNz?=
 =?utf-8?B?aGVVWEhtdEdHSjQzcTZ2ZmRqK2FOK01xWVozalg0VGxZZkNHV1IzWituY2s0?=
 =?utf-8?B?empoYmszNzBpbGR2eXdqV2d0ekZuaGZGZVo4SSt6cEsyOW1qZlhCZWUxNnI5?=
 =?utf-8?B?Z0FxS2hoZjJScGUvQkxRYzFydjV2enBZSjNrMnFSRHFRZnNFQ2VMQnY1NGpr?=
 =?utf-8?B?a3dRVEpEU0lteHVZaXRyRXVHVE04WjYxYTk4VHlyQnF2aElwZ2NORTN5aytY?=
 =?utf-8?B?Z1B6SVg4S3NFeFVzZGt0c0h3YmhiNFdhSzhIeXdoWWxOQThOUEp2eGZzSm96?=
 =?utf-8?B?bzAwdzJVLzI4NEdQOEdrWkxjRVZSQ3hhL29iWWVHUW5XaHJxQ21qK0d3d2tv?=
 =?utf-8?B?YkFGWHFJRG5xeUU1M0o2WW13NjBxS21raGd3R20rU3VmdElrbGcyS2UwV09U?=
 =?utf-8?B?dG1tVmNNM0tUb2hFS09JdzJOZ2t6NkJFcklWUWg1KzdFRHNjZVU1SlBlbXhn?=
 =?utf-8?B?N1dTNEhodHFwUHFzaVhOTkNMQ211TklZUUFjdHlmeWxZUEdnZTNlYk1TS2Ja?=
 =?utf-8?B?NmpreFJ5TXBLaWE1eHExMk83UVlFZlVuY0tkRGJ5aDRTR2RlYmVPUFlsUml4?=
 =?utf-8?B?eldFc0VGRnpYZzNqY3hpMW9RckFpUVZVSGNFVHZwbmNiWGhpOFZVUEpGb1cz?=
 =?utf-8?B?SUY5d3hPK01yRmhVRThnVDRERDBTYTh4MHd3aFpsN3lZRlRkNGNPaGY1U0Iw?=
 =?utf-8?B?T2dlSlQyTXJjN3k4c3ZDOGRDRlNtOUMxVjNQRzNvWisrVzQ2amIxYW1UNHZv?=
 =?utf-8?B?SFM5MStrdWE0WjRMdXBNN1RvUm0wTzhiUzJ5Z3RjTkVjYmRTZ1N1ZWd5TnJu?=
 =?utf-8?B?endPQ242NDJ1bXhzUTE5eGpvODNCWGlSd1NxdzM5WEtvaDUrb0dmOGJGNGxw?=
 =?utf-8?B?OWNqN3ZIWWgrTmgvZnBaa3JCYW12TFV0NjMzcW9IKzhpNW1XaDBwd0hTQmc5?=
 =?utf-8?B?YlBUWWFlUDBOMTlhUzNibUxta1RvdTdYaEpVWEJPU0UyQUNXZmVkYlYzeXAw?=
 =?utf-8?B?bHRicWlFQ3dSdXpkZVNGMWxUMzlsLzFzdzN2K055ZmF1QnJNTEpIYjl3WldD?=
 =?utf-8?B?ZkE0VVJzNytuRSs2c2pKR3l2Q1RtMzdsTyt5UEovMjZQWGxONk45OHBrYTY1?=
 =?utf-8?Q?2t6kox9ZMnunh?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH7PR10MB6505.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?T1BMelFSMElvQnlENlJaV1h4RlBxbUxWOEsvT2k0c01yWGZDQkxJYWNhVnJ2?=
 =?utf-8?B?QVdqRWY2d1U3ZTlvVTF3ZmhSZnBlSE91Vm53SXVTSE56MjZnY1ZRQmY0c3dy?=
 =?utf-8?B?dVI3ME5NRjN3d0kycU91cWREYVNsNldjYzV2ajVUc2VFNHpNRnorT054TE5L?=
 =?utf-8?B?QW5kcDkwa2xvMUk0NzRReXdpS25RaEFqZVFHZjUwYWNUNUpGdm43ZjIyWnFS?=
 =?utf-8?B?U1d4SUdLNVdxNGxxUzhMcVVwRzZxNlNBVnRVSEI5ZFFMQkZFaGRjbVkyc2xq?=
 =?utf-8?B?L3lJQ0NHQXp3RWFuL2Y4cVoxQVpmb2praTZjeFY4NGdueS9sQ28xVlZWSHF3?=
 =?utf-8?B?THh0eDlNL0FwV1Q1a3U3TjVHRm9tV1BDdVA5bXBCd3hwd2tWaklJUlBiVUph?=
 =?utf-8?B?dDdjaUlKRUU4c3duVjUwYkczeUxxczVmV2NyNlZnZzJFMUE5VnBUR0o5QzBL?=
 =?utf-8?B?K2czTmVzcEMrNTRLT2haNy8rSmdkODJVdmF4MHQxVmp5NkNJUTY1R2MyUzda?=
 =?utf-8?B?NFR4eUx3ZGNGNFpLV2V0a3IwZzdlbGFLWkl0bHh4elpIK1FmZklyTSswRk5w?=
 =?utf-8?B?aC9vbmRNR292azYwQ3hWVGRNMElJeVRuZG9hTVc5U29XSE1WVHBpdFVqMmxy?=
 =?utf-8?B?Z0d3ZDZiRnpiZnlUakdmWVFBWmNXNXMzTVZBdEdFOExiVUpMVDNPM2UwMEFV?=
 =?utf-8?B?bkxBNkhjcVk2dSs0TmJueFVyOVBMajYxdkxJR0oyRWJHVmFKbVNOMnRIdkIx?=
 =?utf-8?B?bjRLcmxiSFIvejgwMTVUdStXYlBrU0tuMEw4MG43YlZtUnJQQmtQM0gzeWdW?=
 =?utf-8?B?RmlzQk9PYzUzd2ZlQ2JFZlVDVEtDN0FSVTlWY0U2a1dPK2RGZkZXcjJpU3hT?=
 =?utf-8?B?cGQvYm1KVklibGJXK3RVcitNeXJtd2ZNT2RIelRZMXJQYjRnZ0pYZHhSUXRH?=
 =?utf-8?B?anpSY3RZZWlMajJ4SjRVcm10OW12cnpuaTRVZnZPNGVxMkdBTFFDanFwQWdt?=
 =?utf-8?B?dHJRVnYxUFVnblVMcjd3NlpmczFhVVVSVzVZYXUzdDV1L0RUaWt6VFdFZDB1?=
 =?utf-8?B?MWtJK1gvT0NQN1MxY0NtbE15Q3ZXU1FBanpEZmtXeS8ya1prdHdCYURhd3c0?=
 =?utf-8?B?Z0syZVpEUlNkSkczMk1DV1hOUThVbnk3enJjYjRNY2toWS9ycnFvc0xQU1E1?=
 =?utf-8?B?dWh4NWNMeEJzT0lFak53VjV1UWh6ZzNaMHNVVFVxQzJCRzM0blNiNnNJYXpW?=
 =?utf-8?B?dnZPRkhMR09ZYktUTmRxU0RBOFROVkNYTmtqZHlLMkJTWUZuajdPM05UOWlY?=
 =?utf-8?B?Qk5xL2tOZjQvbHJjMkFObUN6c3FZMlJhM2tBT2w2NjZtSVBaOW9oajRKY1I0?=
 =?utf-8?B?UnRQMHhnQ1oxVEdSLzdSMWNkTUtQVi93QnN2dXJFMDJTY2lwRGoyZDhNSm5T?=
 =?utf-8?B?Y2ZQRHZ4R1ltQzh3RjdzWE5YYXZiRWZ5QzcwOG9UMnptTHV1aXJIVlA0QjJx?=
 =?utf-8?B?Njc4ZTdlb3FKM2Nnc1A5Rzl6UWdDSmtoc3hmaGNpUDU3WWhmK2x5cTZYU1U4?=
 =?utf-8?B?ZWRqOHBWUWNxQ2NsZzBFUEluY29oY21EUWxzY251ZGI4d2NNb2ZJOW5pNnha?=
 =?utf-8?B?VGhQZkVodnZtZExmTEpqM0dPY1hOTDROM2oyRUl4TTBhSjQxdklNVTczc3d1?=
 =?utf-8?B?eHlTdlBzMkhmandrdkNOVlM5dHpzUVBjQkljNVBoYUJhU2poVVVGMUwwWTd5?=
 =?utf-8?B?R1JPNnRWb2hidGlvYUR5Z3pDc0krTGtJR29hNm5jRllaOU4rY1VJWDRWaXNM?=
 =?utf-8?B?LzhkbVhyY3lUY2dVSjFKNThzeStZQmFDd216Q0tyRWNISm5lU0dJWVdST1Jm?=
 =?utf-8?B?b1UwaDl3cFAwMDJybEVTMnF6dTU4MHlRNURNY0JQRDBxbEFxUG5QQUw1b3gz?=
 =?utf-8?B?eE5JMFdlWng0TzN5eVN6U2lVNis4ZkRWNitQcFFMT0NtbVlnVnA5eEZHbm1l?=
 =?utf-8?B?bFMxeU1DelA2UEx2NHdWMVNPMlQ3Y1Q4c1BCZWVPQUo5c1BoWWI5WGMxbUpD?=
 =?utf-8?B?UWhoTGQvVWZHa1lPTys3OVM3U2xCaVU4Nm5vYjRmcXhHT1VGK2FFczN1V1NM?=
 =?utf-8?B?Y05oUlpXOW1KOHZlN0lsZEdPSldhTXRncDhrMm1mQURZOVJua0sxR2g1bDFj?=
 =?utf-8?B?cEE9PQ==?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	NKcfm4dO2OKTw7urKvlU+abja3kQ288sePWdz1VUw2cM+itbRG/mjLrlAQmhYEaw6aFW/Yzz64EOo0yNMEarKrmGau4GdXXbt+YccLdNZFDtrvWq8Z2Id2JCTpPA73qZNuFZ/VJp+o4yVweKxdZ603yMTo9YRqkyhHrZW1zWPYB5gAGqh6AC/f3EG78cNvevNMsmy/+Ia5AZzcHWYGojOpZtvqLrH55adNM4XQC0cpMHJpXcVl/M3zovIs2xw1MSAbfMjqJ2BVbieCNuD9s/8meSInNcSjcun3MLic22bh1SFZ7QYQGln5vmtZfqYgdH3QI7148OWZaFf+dgr6zGcAT49yYYu2DAXLegrNEkcIONcRmPfUjF73bY9MI0hGwMXB5PTngR+PZxJEfQ43JmGC6wuE9Ac2spiKicOqUlhtg4M4zmqnIcYVxxUuMIcPh2pHf5mpsXBlLjqN7+O5CTmT2SO33u3mdKo/FyFcuYsrUbX4fFoe2YKSKnzPtltZMtPPqq8MOdpNVezx1PxCRy5X3QkT8qnYOg3FMjxkq0W7SWDmHB/So1ZBRWPmyjXBVH/QmyG4Iw6bbJVOjgE6XLj0EJ2a8UFQljhAhuaflxaM8=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 19094e95-81d2-41d0-8b51-08dd40457a34
X-MS-Exchange-CrossTenant-AuthSource: PH7PR10MB6505.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2025 09:15:30.6698
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: UcXRUJK/n+L3DTUNTlU+Pu5u8XDnyo1kP0u2H4XJWg41WiDktOBXtHmC6ngiVoTgySDT/bi7CIE3CPSechGRfzkUQhfk3gKNvJu6J/GXUQk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR10MB7038
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34
 definitions=2025-01-28_04,2025-01-27_01,2024-11-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 mlxscore=0 adultscore=0
 malwarescore=0 spamscore=0 bulkscore=0 mlxlogscore=999 suspectscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2411120000
 definitions=main-2501290074
X-Proofpoint-ORIG-GUID: pkcXCaaMgwHFS6DieylSjzAUWhL-HUfR
X-Proofpoint-GUID: pkcXCaaMgwHFS6DieylSjzAUWhL-HUfR


On 29/01/25 2:34 PM, Greg KH wrote:
> On Wed, Jan 29, 2025 at 02:29:48PM +0530, Harshvardhan Jha wrote:
>> Hi Greg,
>>
>> On 29/01/25 2:18 PM, Greg KH wrote:
>>> On Wed, Jan 29, 2025 at 02:13:34PM +0530, Harshvardhan Jha wrote:
>>>> Hi there,
>>>>
>>>> On 29/01/25 2:05 PM, Greg KH wrote:
>>>>> On Wed, Jan 29, 2025 at 02:03:51PM +0530, Harshvardhan Jha wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> +stable
>>>>>>
>>>>>> There seems to be some formatting issues in my log output. I have
>>>>>> attached it as a file.
>>>>> Confused, what are you wanting us to do here in the stable tree?
>>>>>
>>>>> thanks,
>>>>>
>>>>> greg k-h
>>>> Since, this is reproducible on 5.4.y I have added stable. The culprit
>>>> commit which upon getting reverted fixes this issue is also present in
>>>> 5.4.y stable.
>>> What culprit commit?  I see no information here :(
>>>
>>> Remember, top-posting is evil...
>> My apologies,
>>
>> The stable tag v5.4.289 seems to fail to boot with the following prompt in an infinite loop:
>> [   24.427217] megaraid_sas 0000:65:00.0: megasas_build_io_fusion 3273 sge_count (-12) is out of range. Range is:  0-256
>>
>> Reverting the following patch seems to fix the issue:
>>
>> stable-5.4      : v5.4.285             - 5df29a445f3a xen/swiotlb: add
>> alignment check for dma buffers
>>
>> I tried changing swiotlb grub command line arguments but that didn't
>> seem to help much unfortunately and the error was seen again.
>>
> Ok, can you submit this revert with the information about why it should
> not be included in the 5.4.y tree and cc: everyone involved and then we
> will be glad to queue it up.
>
> thanks,
>
> greg k-h

This might be reproducible on other stable trees and mainline as well so
we will get it fixed there and I will submit the necessary fix to stable
when everything is sorted out on mainline.

Thanks & Regards,
Harshvardhan



From xen-devel-bounces@lists.xenproject.org Wed Jan 29 10:19:44 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 10:19:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879060.1289281 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td5Aa-0007eI-FC; Wed, 29 Jan 2025 10:19:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879060.1289281; Wed, 29 Jan 2025 10:19:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td5Aa-0007eB-BM; Wed, 29 Jan 2025 10:19:40 +0000
Received: by outflank-mailman (input) for mailman id 879060;
 Wed, 29 Jan 2025 10:19: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 <SRS0=1peA=UV=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1td5AY-0007dl-CD
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 10:19:38 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8af72121-de2a-11ef-a0e6-8be0dac302b0;
 Wed, 29 Jan 2025 11:19:37 +0100 (CET)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-aaeec07b705so1266044066b.2
 for <xen-devel@lists.xenproject.org>; Wed, 29 Jan 2025 02:19:37 -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
 a640c23a62f3a-ab6d5a96facsm54436366b.31.2025.01.29.02.19.36
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 29 Jan 2025 02:19:36 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8af72121-de2a-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738145977; x=1738750777; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=QMJU9QiZfM5FbBD6tvghID4dwSX6anz6xsYv85IsPME=;
        b=DbFu169wX+a3R8hG9DvUtEZCeBR3O2Md64MqDb1DFeUvqrw7udMMUgr7OBVSIEv1IY
         F0GrVY3EMBxYGy+hOOfJyZvTTGNS11huFK7PJ+j+cZIWkTG5D3RRf4NB6XIPGrny8MV3
         1zFrwNXYZ0QzNWCCG4riEYS6HjR2+gZHSfIw2uZrng+egckMKN73kORv+VlI2za3Gcev
         n3k5sejEPXKqO62rhAmS7Zy3sn15WRvzcxobuEFepqduNPqMx+1jI0N7+owk1XjEyo+B
         wQgsnvzuPUYuftjMmJQzo32DtELWyG2v5bOhiDM8u5byv7LRazcVuP4UE+tsGlnCz0yE
         BzmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738145977; x=1738750777;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=QMJU9QiZfM5FbBD6tvghID4dwSX6anz6xsYv85IsPME=;
        b=Z+puGKOLwRBsw+Wap8tXOW6cVTgc25vuZdr08v25SjhTmGLEx8brcuTprJnv2ZOGWJ
         VwINGWhVSUXByRj/whZlJBLdv4PotDY5mq+rRpNc2TkUluprQbiyJLPHLFUUQOzn091n
         NE1TfAB4c94p1w4aU3LgYFYKlvFXbrCNAz2DN/hWsDy4KoBohR0kJ+vOpaDycpugDsXZ
         tUaCPaQGscDSrbzceSFZX79Vn5OmUUAbiUv9BXV5UUROzsIblzfchpHmeFT/NaVwQjqV
         CGemqWx3kwrJqoMUF6RfRi3ZOoSNkDSm3UNv9wjXCZIs0ULh9kWyEMenwc7WDZ3Crb9x
         cQCA==
X-Forwarded-Encrypted: i=1; AJvYcCX955gUZZdLhuxKIAzE2lcRrcS8+LGfms/Vxvvl6dY9MqicKb7ueF9mmEszEgCwsnEFbcQjFrx3aPM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyBepu1JIETAdJ5XokH3VvjQgzNiY9SAtVdDWPE1WHYSznqyp46
	ENVlmOdRcKowvkIYLJNDDAgVuoXo95eCdBGLZZNeVeURKKW/S3bhakqVO/MTSw==
X-Gm-Gg: ASbGncu53YLoqbgKqwifKeFrLSDDk5217Mo76Bpg8wKbMjw1T5FC5J/s72HMOX+4yEL
	8TNCnWHZvcn5oCR/q787sKn9+ucgIt+ZTmD8ZVWEyHS4rTztkX6TY7gOlk0vFLtGrBQlz2xrqRA
	ODFLf5p8Uj1DddYMIgz2mPO/fE9U76vZOF5jHVAqV58VGuBwNxbvYSFmnfj8dpy84EyyZ9M4LjB
	SJ7orlc/iq45tt51pG0+MuPDZ/2ixM+X4AsncUeNab1E/A0IY0dActJoKGrjdGBcpPtUzpCeAlb
	I9VYmIvLHxcFYC4qqCszc+rON8ZJWhMFMDlZ6W8r8LPkwTVbHUUGCwqB0Mfq2Gngcu1eat7oLac
	Q
X-Google-Smtp-Source: AGHT+IEtkMQC2Crq+mFhZr8KGiTe9KDD74F9/bFoihkOqF9ZOuA01HzLdnpI3rsxpUSNG476UhfkDg==
X-Received: by 2002:a17:907:9482:b0:aae:83c6:c67e with SMTP id a640c23a62f3a-ab6cfe12fdbmr245531466b.55.1738145976868;
        Wed, 29 Jan 2025 02:19:36 -0800 (PST)
Message-ID: <db0bf01f-9162-40e1-9baa-8519e53a46d3@suse.com>
Date: Wed, 29 Jan 2025 11:19:35 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20 1/2] x86/shutdown: quiesce devices ahead of AP
 shutdown
From: Jan Beulich <jbeulich@suse.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <20250128162742.90431-1-roger.pau@citrix.com>
 <20250128162742.90431-2-roger.pau@citrix.com>
 <9673c95f-7ee6-461c-8678-46aeab55735a@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <9673c95f-7ee6-461c-8678-46aeab55735a@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 29.01.2025 11:13, Jan Beulich wrote:
> On 28.01.2025 17:27, Roger Pau Monne wrote:
>> The current shutdown logic in smp_send_stop() will first disable the APs,
>> and then attempt to disable (some) of the interrupt sources.
>>
>> There are two issues with this approach; the first one being that MSI
>> interrupt sources are not disabled, the second one is the APs are stopped
>> before interrupts are disabled.  On AMD systems this can lead to the
>> triggering of local APIC errors:
>>
>> APIC error on CPU0: 00(08), Receive accept error
>>
>> Such error message can be printed in a loop, thus blocking the system from
>> rebooting.  I assume this loop is created by the error being triggered by
>> the console interrupt, which is further triggered by the ESR reporting
>> write to the console.
>>
>> Intel SDM states:
>>
>> "Receive Accept Error.
>>
>> Set when the local APIC detects that the message it received was not
>> accepted by any APIC on the APIC bus, including itself. Used only on P6
>> family and Pentium processors."
>>
>> So the error shouldn't trigger on any Intel CPU supported by Xen.
>>
>> However AMD doesn't make such claims, and indeed the error is broadcasted
>> to all local APIC when for example an interrupt targets a CPU that's
>> offline.
>>
>> To prevent the error from triggering, move the masking of IO-APIC pins
>> ahead of stopping the APs.  Also introduce a new function that disables
>> MSI and MSI-X on all PCI devices.  Remove the call to fixup_irqs() since
>> there's no point in attempting to move interrupts: all sources will be
>> either masked or disabled.
>>
>> For the NMI crash path also call the newly introduced function, with the
>> hope that disabling MSI and MSI-X will make it easier for the (possible)
>> crash kernel to boot, as it could otherwise receive the same "Receive
>> accept error" upon re-enabling interrupts.
>>
>> Note that this will have the side-effect of preventing further IOMMU
>> interrupts from being delivered, that's expected and at that point in the
>> shutdown process no further interaction with the IOMMU should be relevant.
> 
> This is at most for AMD only. Shouldn't we similarly disable VT-d's
> interrupt(s)? (It's only one right now, as we still don't use the QI
> completion one.) Even for AMD I'm uncertain: It has separate
> hw_irq_controller instances, and its set_iommu_interrupt_handler() is
> custom as well. Will pci_disable_msi_all() really affect it? (Hmm,
> yes, from amd_iommu_msi_enable() it looks like it will.)

Oh, no - not for the x2APIC case. There it's solely iommu->ctrl.int_cap_xt_en
which controls whether the interrupt is enabled, iirc. Btw, one of the two
calls from enable_iommu() to amd_iommu_msi_enable() is actually wrong (commit
d9e49d1afe2e should have moved it instead of adding another call); I'll make
a patch for that.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 10:35:42 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 10:35:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879074.1289291 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td5Q1-0003MK-O5; Wed, 29 Jan 2025 10:35:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879074.1289291; Wed, 29 Jan 2025 10:35:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td5Q1-0003MD-K0; Wed, 29 Jan 2025 10:35:37 +0000
Received: by outflank-mailman (input) for mailman id 879074;
 Wed, 29 Jan 2025 10:35:36 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=1peA=UV=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1td5Q0-0003M7-Ew
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 10:35:36 +0000
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com
 [2a00:1450:4864:20::62f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c5f74484-de2c-11ef-a0e6-8be0dac302b0;
 Wed, 29 Jan 2025 11:35:35 +0100 (CET)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-aaec111762bso1481603066b.2
 for <xen-devel@lists.xenproject.org>; Wed, 29 Jan 2025 02:35:35 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab675e64e9bsm941498266b.46.2025.01.29.02.35.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 29 Jan 2025 02:35:34 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c5f74484-de2c-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738146935; x=1738751735; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=RoTlPrcejTMYiWEgo7o/fjzNWCKkB5CCcbRa1OHeGw8=;
        b=RpbFKtvOF5giaD8vXYXr4Lhz6lsxlsKGqKqN6rKc7CW5J+a/vsNzwQqm1EfDV5xpKk
         8RnSpzK8fWBfiTmW1Wc/aCoSDfx9BTTOXQI8NBHewmcw/iNuGbgx63uzQC+deCOx+kNm
         AY6/RsmR2VSDLOPXyU1X0mr+H/CIOhxOV4e0XpTR1Rdmpf9nt7M3v4tcfDvbkWdHSHHP
         izMasTw1YCvnFQVV0laDGQwiBKpKjL/R7u7fKrEEBTrqjIWB2t9yQQz2DNV1XS1JkmFq
         LuyYlS3847XOZObJmNioLU8kX+Or3k3smJs5fao3G3ynjZt1bofPpbCIzMpImdvkHAUU
         G0Vw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738146935; x=1738751735;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=RoTlPrcejTMYiWEgo7o/fjzNWCKkB5CCcbRa1OHeGw8=;
        b=J7IFcBG1xNl70l/SHDY+xbTNujosvWQ1XDK0SilANCFCmvbFkBHJaUKGogzQh5fGud
         Zc132npLhou/AKjP8mN2JQd0y0xKhvFrxRVqZofidWxIaZpAMUOwBs/MnCSz/u4N7m1P
         LyDK4d9lr3PKFYIqOcDzk0jcmA/SwzYz11TITo+mlcb/J0f9V5Tbl5AaAnneGf5PDfyW
         pjSLkpj2MZ8SFQvxROsOiF4PXSbwlzZ3D++CcTqdtCTX5oM57LWlqu2GiRPRWGePDUIh
         4ghsU7PQkPtMaUcA/akPHR+WYAi7BvvPtlzEUzWbs12Djo2atPl6GoCDOR6ReM++aegK
         6dNw==
X-Forwarded-Encrypted: i=1; AJvYcCUAhMBtmdeMuZa8K9HFv0JL3UkYQblCo78Y0Fcg1BIuNzJAhwIFJEUnoLs44v85ZeVOu5JiGZxCa00=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxMIE/5O+8PmHLGlpJ5vhUXaZEwPA9Vm/Tkn6Ej9r/RbJBlXJ0U
	K2d1y2AJgOkKdCXAOrJXrL9fsxM9Dz+aAxUaED9WFNxqm2FiaAJZwueQeE3pMg==
X-Gm-Gg: ASbGncvH0zwIc3nFWKzU8rrdrQ5hREm4kq4jxVI+Ab7suabzGYfXMvLZ3Tu2h6m9KXJ
	ik/7fr/sZ3Wmx9kQpWlCV4nBOUA3RIDD5q8pa9TYD0p87bbmqe9aOqlXcOBPvenKbocY1tAcc/n
	euGCkg/VJmbqvOtpIicrrv6VmT11KciS06DyXBhRn3o9JYQR5CZV5iFIQFrij4vjQAvRabyW6Rq
	gHYxytaq/gZvOk9+P6NZvdVgRne0JeesL3kRjdZAmjUbQsbzYxB+YP8XIj50YoS1U47iU5DznbG
	HQVhM7ZHTeqEQGGEz3QxjrkxGtBinwloigA/Y734yo/K1GA+dbM9RjjTiYB1evFqm2mhT+P70ns
	9
X-Google-Smtp-Source: AGHT+IF64SIYk4L+r+RtUsfHytYP5VYEOb6Vn6LX4ohfnhfHVva2SBXj1SG2RedLpN5Y3s3i5mKaLw==
X-Received: by 2002:a17:906:730a:b0:aaf:c259:7f6 with SMTP id a640c23a62f3a-ab6cfdbdd07mr302067266b.45.1738146934869;
        Wed, 29 Jan 2025 02:35:34 -0800 (PST)
Message-ID: <c4a0a92e-2814-4a5b-abd6-746727c10584@suse.com>
Date: Wed, 29 Jan 2025 11:35:33 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20 2/2] x86/irq: drop fixup_irqs() parameters
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xenproject.org
References: <20250128162742.90431-1-roger.pau@citrix.com>
 <20250128162742.90431-3-roger.pau@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250128162742.90431-3-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 28.01.2025 17:27, Roger Pau Monne wrote:
> The solely remaining caller always passes the same globally available
> parameters.  Drop the parameters and modify fixup_irqs() to use
> cpu_online_map in place of the input mask parameter, and always be verbose
> in its output printing.
> 
> While there remove some of the checks given the single context where
> fixup_irqs() is now called, which should always be in the CPU offline path,
> after the CPU going offline has been removed from cpu_online_map.
> 
> No functional change intended.
> 
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>

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




From xen-devel-bounces@lists.xenproject.org Wed Jan 29 10:54:10 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 10:54:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879082.1289301 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td5ht-0007DG-5j; Wed, 29 Jan 2025 10:54:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879082.1289301; Wed, 29 Jan 2025 10:54:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td5ht-0007D9-2o; Wed, 29 Jan 2025 10:54:05 +0000
Received: by outflank-mailman (input) for mailman id 879082;
 Wed, 29 Jan 2025 10:54:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=AXM0=UV=amd.com=Edgar.Iglesias@srs-se1.protection.inumbo.net>)
 id 1td5hr-0007D3-Sd
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 10:54:04 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20606.outbound.protection.outlook.com
 [2a01:111:f403:2412::606])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5893bb2a-de2f-11ef-99a4-01e77a169b0f;
 Wed, 29 Jan 2025 11:54:01 +0100 (CET)
Received: from BLAP220CA0004.NAMP220.PROD.OUTLOOK.COM (2603:10b6:208:32c::9)
 by CYYPR12MB8891.namprd12.prod.outlook.com (2603:10b6:930:c0::7) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8398.17; Wed, 29 Jan
 2025 10:53:55 +0000
Received: from BN2PEPF0000449E.namprd02.prod.outlook.com
 (2603:10b6:208:32c:cafe::8e) by BLAP220CA0004.outlook.office365.com
 (2603:10b6:208:32c::9) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8377.22 via Frontend Transport; Wed,
 29 Jan 2025 10:53:55 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN2PEPF0000449E.mail.protection.outlook.com (10.167.243.149) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8398.14 via Frontend Transport; Wed, 29 Jan 2025 10:53:55 +0000
Received: from localhost (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 29 Jan
 2025 04:53:54 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5893bb2a-de2f-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Dob1yXzAGPcEHr4VACS79SW6iDMoCT+9o18ZPOWXMiS77xq0CdIED1Iad1GWHQmCL36js0GPmpFGtNvWdvZWLSGMfSVD46uX5ljZG77sEpmn/iPghcGZUy5jnpZe3AXY6SfRcPV1MmYswF5flN7hUcOrNDYlwT61jKM2Fa/43SrrcvLrKUCvsAX0g/t/vhjvQkmIVmm8rEZ/c05NYi1lqRz3f+536Q6LQjSEcd7V8KThIZTtbFSdWVyiD/YN59D7iDKNIeoR0W7Jd6CpfDbEwT1UaFzCfjGkxuCzGeqHlCOTUvomUJWcM1aGtFpCTiYI5i6s2xbV+iCQM8HhliaDeA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=Vz8mutcAwbkjWFcYhZiURoRr/ACP7Y1DWywHwfkv+lo=;
 b=d40i/gvLuyyFwDbJqnKqlARBeCMp7fUJ5jfJuI3RCgpzSfKb/OpM9vpS0CBFLV4wr6KFXSSwD3LZ5nQn4imhEnaYpaDS4EBwoNYtaBeFSLEADvVXjg/htWJVivLDldBouk/2wqH9Yfk6RfH+SYJvNwRu65O+0xGBJm6GU8Czva9EmjxprXZjpcHA670Nm6xFuxHx07FWAK6HnAhjDisB6ofdmPxrzV94sSW8PEcKAHZTslFXQq2rCMKnmOqQGy3WbO3bLHT8+Pt5iPdypiO6onpu3ZJwKxNEF0wKXBFpbzPzzE99CN5C98lJBjFheztGOKc4jWx/VlzepeqXnypc2g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=kernel.org smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Vz8mutcAwbkjWFcYhZiURoRr/ACP7Y1DWywHwfkv+lo=;
 b=xY0ejVBMXmAOksc7nhMxstnb+pkS+M64H4LV1t4NIap0OZD5c3V84I9HsNKGS0/AAKDIoDsvWMmRtmYRrjrfMB4+C5R+91rxpi9E95bH5ES6MVFH0vY2lTtBVHerkjgjmyYaL4WoNE1ReZx0jnY9cgQ6NGDlOResvzU2nHxxFPQ=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Date: Wed, 29 Jan 2025 11:53:49 +0100
From: "Edgar E. Iglesias" <edgar.iglesias@amd.com>
To: Stefano Stabellini <sstabellini@kernel.org>
CC: Olaf Hering <olaf@aepfle.de>, <xen-devel@lists.xenproject.org>,
	<jgross@suse.com>, Anthony PERARD <anthony@xenproject.org>, Paul Durrant
	<paul@xen.org>, <jbeulich@suse.com>, <andrew.cooper3@citrix.com>,
	<roger.pau@citrix.com>
Subject: Re: slow start of Pod HVM domU with qemu 9.1
Message-ID: <Z5oIvUINVDfrrVla@zapote>
References: <20250128151544.26fc827d.olaf@aepfle.de>
 <Z5j-bkdFZ7riavv7@zapote>
 <alpine.DEB.2.22.394.2501281543580.3264561@ubuntu-linux-20-04-desktop>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.22.394.2501281543580.3264561@ubuntu-linux-20-04-desktop>
User-Agent: Mutt/2.2.12 (2023-09-09)
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN2PEPF0000449E:EE_|CYYPR12MB8891:EE_
X-MS-Office365-Filtering-Correlation-Id: d342580a-2b02-4149-62a0-08dd405339dc
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|82310400026|376014|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?PGEsJdTlGVlNbj1Hr9o52Mkq5Vu10Mv5GzCpWdbQA6o3TL1+7mWpAvFsQZKY?=
 =?us-ascii?Q?z5POg9E9+NLr0FbszvA/A1or7FRis8ZsLFT78/LSdOZqn5TAvW4O3hOr/B2q?=
 =?us-ascii?Q?Gp9GftgCQztWTCToDSI5rSjF1eohkrXT6AdkeAZNumvefDKeOp9Iog2GevBG?=
 =?us-ascii?Q?Zjz7nh2DBpGAfpxtbBWMZVOhzzvVXWtK18HVCEe14iQIMJL35Bu1vxfUNjoT?=
 =?us-ascii?Q?UQJRP1iMdK4WpJdECioeru+p9YzDKjS7bJwCX9IKqkmq7yZRQk+YpOlyvPyQ?=
 =?us-ascii?Q?Rwd5Lys0OWhhlA3uHeZii+Hw8gNUacLDalJJs0dhVdalq8unj4KsU0huZS2/?=
 =?us-ascii?Q?5/qjY4RPu4AGjMnDAq3wO3zwWWfdYoz6mmpOoLz9ToMSPU7E94vGTelgJXes?=
 =?us-ascii?Q?g+uUduKhPWO7CZZniuW2imNzR6RpgIH3LQwKNDeQLuQ62q+Me1CdFzTpo87H?=
 =?us-ascii?Q?EunTUiblmqU0xxZHwbPfJAZopqV2eftUEff3rjDCajuWApt1yB+yq3WC0Nox?=
 =?us-ascii?Q?mufm4vlRFtSV0JSjqBXh7Ar0vwxcDz3ZeHpcgqZJk+S42vF04Vw32TpfQu2J?=
 =?us-ascii?Q?SKL635M/qaJmuiIaivNG7qJsNf2WiWLhFGCcFULrLjtXg4zE6FD8PI2sRTx0?=
 =?us-ascii?Q?SElfyg2DC68R49KAvv1Td30c9SX+K/ETGOZ5E/w0Xc6nhnPcrrMPaa9jBW0a?=
 =?us-ascii?Q?S2xEuxiZZm16MJzNc2MD+6G4EoHUn6g3MglTObkZmBgom/lXt4R+3hcBorco?=
 =?us-ascii?Q?Sj3VKBBQuxYfd1/nDKy2O/bl82gITugOC06sanECtXFr8UbN1rjRJHfUPIsF?=
 =?us-ascii?Q?ZFufJ/5srB2/HIbqZ/Yb/tqQez/BoKK7orrapYLvaaz6WXLajcALZMcUY/yf?=
 =?us-ascii?Q?zH7XtLKTyTJ9N4v7WmQBbU7/RTr92lEbpN3mhhhxwGjQVBEA5zb88YTVjW/K?=
 =?us-ascii?Q?zO9d0tqKHXgRbtL1cSGLNNBAUPj1SFH0Dy8sYl1gDOAGI9xrAflRkV0tlurt?=
 =?us-ascii?Q?oJksfEig34LUUN8St3vpFJA0KPBR3AuUFyUezQ0VY4l/7Ad2I4Gp07Ko0IPp?=
 =?us-ascii?Q?AL5yANlE4MP6Q/37CzGfFqQ9h1mwtZmo95NKx858/9ifgmUxrMGxk5jDhCXu?=
 =?us-ascii?Q?28BGNmoUAf5P+DD7V0vG7pFfupplFQawePd2nSQfMzVE8VEh0tz7BqD/y/XI?=
 =?us-ascii?Q?EjGOP5v011J1rzWle8LVzkfwxVWEtVh5t96VIMnV+iUNpQnw9ZmptGor2Rbr?=
 =?us-ascii?Q?TC7BLRCiA8jLEu3Xd+qUoqglQwt0eF5tuMgqDR5q+zrIMfhGOsu9BrSmBjPF?=
 =?us-ascii?Q?aSL3kacLPjvBgbgPJVNSYAQtUF1Q6u0hL0cu+mwjju+OO0eUVYHy69ty/UeH?=
 =?us-ascii?Q?Fl167/O7Do8WHVxM1AJp9MJnJFvmR0HXFgqPuvVLR+BDqCvP5M9Gqx9kgQ6M?=
 =?us-ascii?Q?dKMnd0vcv/aiuKxMNYdQaWSpWpAtftnSfDMMT/KZrX660+93PxOLXahhBVeX?=
 =?us-ascii?Q?HPoogpIaUc4ij5E=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(376014)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2025 10:53:55.3061
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d342580a-2b02-4149-62a0-08dd405339dc
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN2PEPF0000449E.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CYYPR12MB8891

On Tue, Jan 28, 2025 at 03:58:14PM -0800, Stefano Stabellini wrote:
> On Tue, 28 Jan 2025, Edgar E. Iglesias wrote:
> > On Tue, Jan 28, 2025 at 03:15:44PM +0100, Olaf Hering wrote:
> > > Hello,
> > > 
> > > starting with qemu 9.1 a PoD HVM domU takes a long time to start.
> > > Depending on the domU kernel, it may trigger a warning, which prompted me
> > > to notice this change in behavior:
> > > 
> > > [    0.000000] Linux version 4.12.14-120-default (geeko@buildhost) (gcc version 4.8.5 (SUSE Linux) ) #1 SMP Thu Nov 7 16:39:09 UTC 2019 (fd9dc36)
> > > ...
> > > [    1.096432] HPET: 3 timers in total, 0 timers will be used for per-cpu timer
> > > [    1.101636] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
> > > [    1.104051] hpet0: 3 comparators, 64-bit 62.500000 MHz counter
> > > [   16.136086] random: crng init done
> > > [   31.712052] BUG: workqueue lockup - pool cpus=1 node=0 flags=0x0 nice=0 stuck for 30s!
> > > [   31.716029] Showing busy workqueues and worker pools:
> > > [   31.721164] workqueue events: flags=0x0
> > > [   31.724054]   pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=2/256
> > > [   31.728000]     in-flight: 17:balloon_process
> > > [   31.728000]     pending: hpet_work
> > > [   31.728023] workqueue mm_percpu_wq: flags=0x8
> > > [   31.732987]   pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=1/256
> > > [   31.736000]     pending: vmstat_update
> > > [   31.736024] pool 2: cpus=1 node=0 flags=0x0 nice=0 hung=30s workers=2 idle: 34
> > > [   50.400102] clocksource: Switched to clocksource xen
> > > [   50.441153] VFS: Disk quotas dquot_6.6.0
> > > ...
> > > 
> > > With qemu 9.0 and older, this domU will start the /init task after 8 seconds.
> > > 
> > > The change which caused this commit is qemu.git commit 9ecdd4bf08dfe4a37e16b8a8b228575aff641468
> > > Author:     Edgar E. Iglesias <edgar.iglesias@amd.com>
> > > AuthorDate: Tue Apr 30 10:26:45 2024 +0200
> > > Commit:     Edgar E. Iglesias <edgar.iglesias@amd.com>
> > > CommitDate: Sun Jun 9 20:16:14 2024 +0200
> > > 
> > >     xen: mapcache: Add support for grant mappings
> > > 
> > > As you can see, v4 instead of v5 was apparently applied.
> > > This was probably unintentional, but would probably not change the result.
> > 
> > Hi Olaf,
> > 
> > It looks like v8 was applied, or am I missing something?
> > 
> > 
> > > 
> > > With this change the domU starts fast again:
> > > 
> > > --- a/hw/xen/xen-mapcache.c
> > > +++ b/hw/xen/xen-mapcache.c
> > > @@ -522,6 +522,7 @@ ram_addr_t xen_ram_addr_from_mapcache(void *ptr)
> > >      ram_addr_t addr;
> > >  
> > >      addr = xen_ram_addr_from_mapcache_single(mapcache, ptr);
> > > +    if (1)
> > >      if (addr == RAM_ADDR_INVALID) {
> > >          addr = xen_ram_addr_from_mapcache_single(mapcache_grants, ptr);
> > >      }
> > > @@ -626,6 +627,7 @@ static void xen_invalidate_map_cache_entry_single(MapCache *mc, uint8_t *buffer)
> > >  static void xen_invalidate_map_cache_entry_all(uint8_t *buffer)
> > >  {
> > >      xen_invalidate_map_cache_entry_single(mapcache, buffer);
> > > +    if (1)
> > >      xen_invalidate_map_cache_entry_single(mapcache_grants, buffer);
> > >  }
> > >  
> > > @@ -700,6 +702,7 @@ void xen_invalidate_map_cache(void)
> > >      bdrv_drain_all();
> > >  
> > >      xen_invalidate_map_cache_single(mapcache);
> > > +    if (0)
> > >      xen_invalidate_map_cache_single(mapcache_grants);
> > >  }
> > >  
> > > I did the testing with libvirt, the domU.cfg equivalent looks like this:
> > > maxmem = 4096
> > > memory = 2048
> > > maxvcpus = 4
> > > vcpus = 2
> > > pae = 1
> > > acpi = 1
> > > apic = 1
> > > viridian = 0
> > > rtc_timeoffset = 0
> > > localtime = 0
> > > on_poweroff = "destroy"
> > > on_reboot = "destroy"
> > > on_crash = "destroy"
> > > device_model_override = "/usr/lib64/qemu-9.1/bin/qemu-system-i386"
> > > sdl = 0
> > > vnc = 1
> > > vncunused = 1
> > > vnclisten = "127.0.0.1"
> > > vif = [ "mac=52:54:01:23:63:29,bridge=br0,script=vif-bridge" ]
> > > parallel = "none"
> > > serial = "pty"
> > > builder = "hvm"
> > > kernel = "/bug1236329/linux"
> > > ramdisk = "/bug1236329/initrd"
> > > cmdline = "console=ttyS0,115200n8 quiet ignore_loglevel""
> > > boot = "c" 
> > > disk = [ "format=qcow2,vdev=hda,access=rw,backendtype=qdisk,target=/bug1236329/sles12sp5.qcow2" ]
> > > usb = 1
> > > usbdevice = "tablet"
> > > 
> > > Any idea what can be done to restore boot times?
> > 
> > 
> > A guess is that it's taking a long time to walk the grants mapcache
> > when invalidating (in QEMU). Despite it being unused and empty. We
> > could try to find a way to keep track of usage and do nothing when
> > invalidating an empty/unused cache.
> 
> If mapcache_grants is unused and empty, the call to
> xen_invalidate_map_cache_single(mapcache_grants) should be really fast?

Yes, I agree but looking at the invalidation code it looks like if we're
unconditionally walking all the buckets in the hash-table...


> 
> I think probably it might be the opposite: mapcache_grants is utilized,
> so going through all the mappings in xen_invalidate_map_cache_single
> takes time.

The reason I don't think it's being used is because we've only enabled
grants for PVH machines and Olaf runs HVM machines, so QEMU would never
end up mapping grants for DMA.


> 
> However, I wonder if it is really needed. At least in the PoD case, the
> reason for the IOREQ_TYPE_INVALIDATE request is that the underlying DomU
> memory has changed. But that doesn't affect the grant mappings, because
> those are mappings of other domains' memory.
> 
> So I am thinking whether we should remove the call to
> xen_invalidate_map_cache_single(mapcache_grants) ?

Good point!

> 
> Adding x86 maintainers: do we need to flush grant table mappings for the
> PV backends running in QEMU when Xen issues a IOREQ_TYPE_INVALIDATE
> request to QEMU?

Cheers,
Edgar


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 11:23:05 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 11:23:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879094.1289310 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td69l-0003Xc-DO; Wed, 29 Jan 2025 11:22:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879094.1289310; Wed, 29 Jan 2025 11:22:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td69l-0003XV-Ae; Wed, 29 Jan 2025 11:22:53 +0000
Received: by outflank-mailman (input) for mailman id 879094;
 Wed, 29 Jan 2025 11:22: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 <SRS0=PyJd=UV=suse.com=jgross@srs-se1.protection.inumbo.net>)
 id 1td69j-0003XP-Ue
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 11:22:52 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de
 [2a07:de40:b251:101:10:150:64:2])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5f9a134c-de33-11ef-a0e6-8be0dac302b0;
 Wed, 29 Jan 2025 12:22:50 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id AFE231F365;
 Wed, 29 Jan 2025 11:22:49 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 5DC99137DB;
 Wed, 29 Jan 2025 11:22:49 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id RAg8FYkPmmf4PQAAD6G6ig
 (envelope-from <jgross@suse.com>); Wed, 29 Jan 2025 11:22:49 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5f9a134c-de33-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1738149769; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=kJ+sVjc09SMmCjC36y3BSChpyhgwQ/u/jQHMHdFN9Nc=;
	b=f7vc5PDhDRqWblW/GZdLTykMmWWjLklpvDwps0adPsGref8qZhZb3sW1yy4cxwQ99Fu5h8
	ls8SyILmsY1GTfjutMcTrzJ/mDSUK0xRS2R96L7Pfjbf8tMf3BctFsGxR8RSgIPqrZf7TY
	2YKH1FV2x48ldHUoU1sjVCNoCIRjuM4=
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1738149769; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=kJ+sVjc09SMmCjC36y3BSChpyhgwQ/u/jQHMHdFN9Nc=;
	b=f7vc5PDhDRqWblW/GZdLTykMmWWjLklpvDwps0adPsGref8qZhZb3sW1yy4cxwQ99Fu5h8
	ls8SyILmsY1GTfjutMcTrzJ/mDSUK0xRS2R96L7Pfjbf8tMf3BctFsGxR8RSgIPqrZf7TY
	2YKH1FV2x48ldHUoU1sjVCNoCIRjuM4=
Message-ID: <83bd90c7-8879-4462-9548-bb5b69cac39e@suse.com>
Date: Wed, 29 Jan 2025 12:22:48 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: v5.4.289 failed to boot with error megasas_build_io_fusion 3219
 sge_count (-12) is out of range
To: Harshvardhan Jha <harshvardhan.j.jha@oracle.com>,
 Greg KH <gregkh@linuxfoundation.org>
Cc: Konrad Wilk <konrad.wilk@oracle.com>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 "sstabellini@kernel.org" <sstabellini@kernel.org>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
 Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>,
 stable@vger.kernel.org
References: <7dc143fa-4a48-440b-b624-ac57a361ac74@oracle.com>
 <9dd91f6e-1c66-4961-994e-dbda87d69dad@oracle.com>
 <2025012919-series-chaps-856e@gregkh>
 <8eb33b38-23e1-4e43-8952-3f2b05660236@oracle.com>
 <2025012936-finalize-ducktail-c524@gregkh>
 <1f017284-1a29-49d8-b0d9-92409561990e@oracle.com>
 <2025012956-jiffy-condone-3137@gregkh>
 <1f225b8d-d958-4304-829e-8798884d9b6b@oracle.com>
Content-Language: en-US
From: Juergen Gross <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <1f225b8d-d958-4304-829e-8798884d9b6b@oracle.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------ATVvY1dA3DXYncI2xe3rxfCi"
X-Spam-Score: -6.20
X-Spamd-Result: default: False [-6.20 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SIGNED_PGP(-2.00)[];
	NEURAL_HAM_LONG(-1.00)[-0.998];
	MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain];
	NEURAL_HAM_SHORT(-0.20)[-0.999];
	MIME_UNKNOWN(0.10)[application/pgp-keys];
	MIME_BASE64_TEXT(0.10)[];
	RCVD_TLS_ALL(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	TO_DN_SOME(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_SEVEN(0.00)[9];
	RCVD_COUNT_TWO(0.00)[2];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	HAS_ATTACHMENT(0.00)[]
X-Spam-Flag: NO
X-Spam-Level: 

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------ATVvY1dA3DXYncI2xe3rxfCi
Content-Type: multipart/mixed; boundary="------------Vp4XYrfeinVwEvuNrWn450MA";
 protected-headers="v1"
From: Juergen Gross <jgross@suse.com>
To: Harshvardhan Jha <harshvardhan.j.jha@oracle.com>,
 Greg KH <gregkh@linuxfoundation.org>
Cc: Konrad Wilk <konrad.wilk@oracle.com>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 "sstabellini@kernel.org" <sstabellini@kernel.org>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
 Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>,
 stable@vger.kernel.org
Message-ID: <83bd90c7-8879-4462-9548-bb5b69cac39e@suse.com>
Subject: Re: v5.4.289 failed to boot with error megasas_build_io_fusion 3219
 sge_count (-12) is out of range
References: <7dc143fa-4a48-440b-b624-ac57a361ac74@oracle.com>
 <9dd91f6e-1c66-4961-994e-dbda87d69dad@oracle.com>
 <2025012919-series-chaps-856e@gregkh>
 <8eb33b38-23e1-4e43-8952-3f2b05660236@oracle.com>
 <2025012936-finalize-ducktail-c524@gregkh>
 <1f017284-1a29-49d8-b0d9-92409561990e@oracle.com>
 <2025012956-jiffy-condone-3137@gregkh>
 <1f225b8d-d958-4304-829e-8798884d9b6b@oracle.com>
In-Reply-To: <1f225b8d-d958-4304-829e-8798884d9b6b@oracle.com>

--------------Vp4XYrfeinVwEvuNrWn450MA
Content-Type: multipart/mixed; boundary="------------cRXte0Sy5h7PSMais8nDyUqr"

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

T24gMjkuMDEuMjUgMTA6MTUsIEhhcnNodmFyZGhhbiBKaGEgd3JvdGU6DQo+IA0KPiBPbiAy
OS8wMS8yNSAyOjM0IFBNLCBHcmVnIEtIIHdyb3RlOg0KPj4gT24gV2VkLCBKYW4gMjksIDIw
MjUgYXQgMDI6Mjk6NDhQTSArMDUzMCwgSGFyc2h2YXJkaGFuIEpoYSB3cm90ZToNCj4+PiBI
aSBHcmVnLA0KPj4+DQo+Pj4gT24gMjkvMDEvMjUgMjoxOCBQTSwgR3JlZyBLSCB3cm90ZToN
Cj4+Pj4gT24gV2VkLCBKYW4gMjksIDIwMjUgYXQgMDI6MTM6MzRQTSArMDUzMCwgSGFyc2h2
YXJkaGFuIEpoYSB3cm90ZToNCj4+Pj4+IEhpIHRoZXJlLA0KPj4+Pj4NCj4+Pj4+IE9uIDI5
LzAxLzI1IDI6MDUgUE0sIEdyZWcgS0ggd3JvdGU6DQo+Pj4+Pj4gT24gV2VkLCBKYW4gMjks
IDIwMjUgYXQgMDI6MDM6NTFQTSArMDUzMCwgSGFyc2h2YXJkaGFuIEpoYSB3cm90ZToNCj4+
Pj4+Pj4gSGkgQWxsLA0KPj4+Pj4+Pg0KPj4+Pj4+PiArc3RhYmxlDQo+Pj4+Pj4+DQo+Pj4+
Pj4+IFRoZXJlIHNlZW1zIHRvIGJlIHNvbWUgZm9ybWF0dGluZyBpc3N1ZXMgaW4gbXkgbG9n
IG91dHB1dC4gSSBoYXZlDQo+Pj4+Pj4+IGF0dGFjaGVkIGl0IGFzIGEgZmlsZS4NCj4+Pj4+
PiBDb25mdXNlZCwgd2hhdCBhcmUgeW91IHdhbnRpbmcgdXMgdG8gZG8gaGVyZSBpbiB0aGUg
c3RhYmxlIHRyZWU/DQo+Pj4+Pj4NCj4+Pj4+PiB0aGFua3MsDQo+Pj4+Pj4NCj4+Pj4+PiBn
cmVnIGstaA0KPj4+Pj4gU2luY2UsIHRoaXMgaXMgcmVwcm9kdWNpYmxlIG9uIDUuNC55IEkg
aGF2ZSBhZGRlZCBzdGFibGUuIFRoZSBjdWxwcml0DQo+Pj4+PiBjb21taXQgd2hpY2ggdXBv
biBnZXR0aW5nIHJldmVydGVkIGZpeGVzIHRoaXMgaXNzdWUgaXMgYWxzbyBwcmVzZW50IGlu
DQo+Pj4+PiA1LjQueSBzdGFibGUuDQo+Pj4+IFdoYXQgY3VscHJpdCBjb21taXQ/ICBJIHNl
ZSBubyBpbmZvcm1hdGlvbiBoZXJlIDooDQo+Pj4+DQo+Pj4+IFJlbWVtYmVyLCB0b3AtcG9z
dGluZyBpcyBldmlsLi4uDQo+Pj4gTXkgYXBvbG9naWVzLA0KPj4+DQo+Pj4gVGhlIHN0YWJs
ZSB0YWcgdjUuNC4yODkgc2VlbXMgdG8gZmFpbCB0byBib290IHdpdGggdGhlIGZvbGxvd2lu
ZyBwcm9tcHQgaW4gYW4gaW5maW5pdGUgbG9vcDoNCj4+PiBbICAgMjQuNDI3MjE3XSBtZWdh
cmFpZF9zYXMgMDAwMDo2NTowMC4wOiBtZWdhc2FzX2J1aWxkX2lvX2Z1c2lvbiAzMjczIHNn
ZV9jb3VudCAoLTEyKSBpcyBvdXQgb2YgcmFuZ2UuIFJhbmdlIGlzOiAgMC0yNTYNCj4+Pg0K
Pj4+IFJldmVydGluZyB0aGUgZm9sbG93aW5nIHBhdGNoIHNlZW1zIHRvIGZpeCB0aGUgaXNz
dWU6DQo+Pj4NCj4+PiBzdGFibGUtNS40wqDCoMKgwqDCoCA6IHY1LjQuMjg1wqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgIC0gNWRmMjlhNDQ1ZjNhIHhlbi9zd2lvdGxiOiBhZGQNCj4+PiBh
bGlnbm1lbnQgY2hlY2sgZm9yIGRtYSBidWZmZXJzDQo+Pj4NCj4+PiBJIHRyaWVkIGNoYW5n
aW5nIHN3aW90bGIgZ3J1YiBjb21tYW5kIGxpbmUgYXJndW1lbnRzIGJ1dCB0aGF0IGRpZG4n
dA0KPj4+IHNlZW0gdG8gaGVscCBtdWNoIHVuZm9ydHVuYXRlbHkgYW5kIHRoZSBlcnJvciB3
YXMgc2VlbiBhZ2Fpbi4NCj4+Pg0KPj4gT2ssIGNhbiB5b3Ugc3VibWl0IHRoaXMgcmV2ZXJ0
IHdpdGggdGhlIGluZm9ybWF0aW9uIGFib3V0IHdoeSBpdCBzaG91bGQNCj4+IG5vdCBiZSBp
bmNsdWRlZCBpbiB0aGUgNS40LnkgdHJlZSBhbmQgY2M6IGV2ZXJ5b25lIGludm9sdmVkIGFu
ZCB0aGVuIHdlDQo+PiB3aWxsIGJlIGdsYWQgdG8gcXVldWUgaXQgdXAuDQo+Pg0KPj4gdGhh
bmtzLA0KPj4NCj4+IGdyZWcgay1oDQo+IA0KPiBUaGlzIG1pZ2h0IGJlIHJlcHJvZHVjaWJs
ZSBvbiBvdGhlciBzdGFibGUgdHJlZXMgYW5kIG1haW5saW5lIGFzIHdlbGwgc28NCj4gd2Ug
d2lsbCBnZXQgaXQgZml4ZWQgdGhlcmUgYW5kIEkgd2lsbCBzdWJtaXQgdGhlIG5lY2Vzc2Fy
eSBmaXggdG8gc3RhYmxlDQo+IHdoZW4gZXZlcnl0aGluZyBpcyBzb3J0ZWQgb3V0IG9uIG1h
aW5saW5lLg0KDQpSaWdodC4gSnVzdCByZXZlcnRpbmcgbXkgcGF0Y2ggd2lsbCB0cmFkZSBv
bmUgZXJyb3Igd2l0aCBhbm90aGVyIG9uZSAodGhlDQpvbmUgd2hpY2ggdHJpZ2dlcmVkIG1l
IHRvIHdyaXRlIHRoZSBwYXRjaCkuDQoNClRoZXJlIGFyZSB0d28gcG9zc2libGUgd2F5cyB0
byBmaXggdGhlIGlzc3VlOg0KDQotIGFsbG93IGxhcmdlciBETUEgYnVmZmVycyBpbiB4ZW4v
c3dpb3RsYiAodG9kYXkgMk1CIGFyZSB0aGUgbWF4LiBzdXBwb3J0ZWQNCiAgIHNpemUsIHRo
ZSBtZWdhcmFpZF9zYXMgZHJpdmVyIHNlZW1zIHRvIGVmZmVjdGl2ZWx5IHJlcXVlc3QgNE1C
KQ0KDQotIGZpeCB0aGUgbWVnYXJhaWRfc2FzIGRyaXZlciBieSBzcGxpdHRpbmcgdXAgdGhl
IGFsbG9jYXRlZCBETUEgYnVmZmVyIChpdCBpcw0KICAgcmVxdWVzdGluZyAyLjNNQiwgd2hp
Y2ggd2lsbCBiZSByb3VuZGVkIHVwIHRvIDRNQiAtIGl0IGlzIHByb2JhYmx5IG5vdCBuZWVk
ZWQNCiAgIHRvIGJlIGluIG9uZSBjaHVuaywgc28gYSBzcGxpdCB3b3VsZCByZXN1bHQgaW4g
bWF4LiAyTUIgY2h1bmsgc2l6ZSkNCg0KQm90aCB2YXJpYW50cyBoYXZlIHRoZWlyIHByb3Mg
YW5kIGNvbnMsIHRob3VnaC4NCg0KDQpKdWVyZ2VuDQo=
--------------cRXte0Sy5h7PSMais8nDyUqr
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

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

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

--------------cRXte0Sy5h7PSMais8nDyUqr--

--------------Vp4XYrfeinVwEvuNrWn450MA--

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

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

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmeaD4gFAwAAAAAACgkQsN6d1ii/Ey/e
QAf/b0DOiXqpS126jdS6Narc1sI8VN+8jDIFFn9YcdLpcys5SSyrhT1I/zwX+8wyDP3m2i/41Mq+
VoGjfmMGL2+Be9hvUmrHVBgoHXuj+Sj2A4Vcsx0w4fm8vUfxVkYZLWlhh42OJYpq0PT/6sP6haAT
lVulWT3Jpyx2K0UrTS3+5C55jyZkdCWAKTisAd/Wfp5rn3NUNzk7LjFAfXJFHxuPKEoLE51KT5RC
XjANN0XT3KyslLpCLwwUGT1wkX1MxXhTHBbqK4uCxVWXsOY7OkVBrypedqFU6wqu3OIG29/6rSg8
zSdLdLtS+Kfl7dMDEl+goVmoAUtRY3i3jqfmIhyPDQ==
=Zw5T
-----END PGP SIGNATURE-----

--------------ATVvY1dA3DXYncI2xe3rxfCi--


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 11:24:00 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 11:24:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879102.1289321 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td6Aq-00043i-My; Wed, 29 Jan 2025 11:24:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879102.1289321; Wed, 29 Jan 2025 11:24:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td6Aq-00043N-K5; Wed, 29 Jan 2025 11:24:00 +0000
Received: by outflank-mailman (input) for mailman id 879102;
 Wed, 29 Jan 2025 11:23: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
 <SRS0=AXM0=UV=amd.com=Edgar.Iglesias@srs-se1.protection.inumbo.net>)
 id 1td6Ao-000439-TJ
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 11:23:58 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20617.outbound.protection.outlook.com
 [2a01:111:f403:2417::617])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 87144ceb-de33-11ef-a0e6-8be0dac302b0;
 Wed, 29 Jan 2025 12:23:57 +0100 (CET)
Received: from BN0PR02CA0046.namprd02.prod.outlook.com (2603:10b6:408:e5::21)
 by IA1PR12MB8465.namprd12.prod.outlook.com (2603:10b6:208:457::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.24; Wed, 29 Jan
 2025 11:23:53 +0000
Received: from BN2PEPF000044A4.namprd02.prod.outlook.com
 (2603:10b6:408:e5:cafe::39) by BN0PR02CA0046.outlook.office365.com
 (2603:10b6:408:e5::21) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8398.18 via Frontend Transport; Wed,
 29 Jan 2025 11:23:53 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN2PEPF000044A4.mail.protection.outlook.com (10.167.243.155) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8398.14 via Frontend Transport; Wed, 29 Jan 2025 11:23:52 +0000
Received: from localhost (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 29 Jan
 2025 05:23:51 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 87144ceb-de33-11ef-a0e6-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=CjeEViTWqyglQUSVBd/x0vRrAGzi7Hf+dhPTvOUybrsB7Em/pctcyDHvCuttkaVGpLLtlE7Nfmk+ocbV5GPglisrbvXJgO89AoaXUR5/IJ8HozJ/Td4gT05/qpvYSSYcnYEjkAEaJwWgbqrJl/30q7c82WW7ThbiNSfSBuKycY5ah16TCq9WdgNK4xmvHANsCy299yKIRmf+MpbkLTESzgUHw5h5JkMbmgbbcqE8JEWsxy316QBOxT9phs659NQbuQz2pz1k6X5M8nnbhYyNFppUaRA9OLKm4fuWCkZrZ3avsARGxBSgnM34WDH42TvQrjqylWsgZo5MsF3iIUDeQQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=dI9yDiljzJ+q6XSv4LqL9UWFdllKHvicSiPtw0OJEDc=;
 b=IPht/4RheLWbWHWwySgZKFKzPRXcnQ5g+uzLNsb7sjU07rxwKmUQYJpIXKmDDJq5iuTwidk1wTiVoSI+X1cYc8Fl3HCnO3fz2A5Kdwe6/Y9RgOIiO+LJfrSII/xG7jhGkd1yg8vOnyUCAPJn+NLiLx2e8oyleJVJfPMAqnK3dzC9QHJ87KzwKXX6cXkIUx6BekbIZtowL3qTKE+KRrVDpKYlq8za9Gx2SnfUpEK8IqIGh19dxU2Q81MWew8cPrjaFDP+FnHyhiEAeSwiwI5o1gatNgxpExLCYkF2XqtUg5ASOkIsjaOJjo+BaHdCR74UDukGEVHbUt6nTa05VwSvJQ==
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=dI9yDiljzJ+q6XSv4LqL9UWFdllKHvicSiPtw0OJEDc=;
 b=4AFHrcN1dsp+KX6qY+bTHq3qc23CFCEq2N/nf+Bjk59++fL1fmQLKvq1/cn6ToFHu9Q26KyFf9+GdWCWfZEh3c8/FHW2me0mb3pMzNL0XLbV8Epys/L8dlakCiB8n6I7AwMcvKI5yZ276hnx0zYi5sbaIQDZQ9j0OmoMVE5Qw5Y=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Date: Wed, 29 Jan 2025 12:23:46 +0100
From: "Edgar E. Iglesias" <edgar.iglesias@amd.com>
To: Jan Beulich <jbeulich@suse.com>
CC: Stefano Stabellini <sstabellini@kernel.org>, Olaf Hering <olaf@aepfle.de>,
	<xen-devel@lists.xenproject.org>, <jgross@suse.com>, Anthony PERARD
	<anthony@xenproject.org>, Paul Durrant <paul@xen.org>,
	<andrew.cooper3@citrix.com>, <roger.pau@citrix.com>
Subject: Re: slow start of Pod HVM domU with qemu 9.1
Message-ID: <Z5oPwthxmLfIbjSE@zapote>
References: <20250128151544.26fc827d.olaf@aepfle.de>
 <Z5j-bkdFZ7riavv7@zapote>
 <alpine.DEB.2.22.394.2501281543580.3264561@ubuntu-linux-20-04-desktop>
 <b4ccccbb-f3ee-44fe-a5e2-780195cbbc0e@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <b4ccccbb-f3ee-44fe-a5e2-780195cbbc0e@suse.com>
User-Agent: Mutt/2.2.12 (2023-09-09)
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN2PEPF000044A4:EE_|IA1PR12MB8465:EE_
X-MS-Office365-Filtering-Correlation-Id: a3d63df6-0f35-45a1-d049-08dd40576940
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|36860700013|1800799024|376014|13003099007;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?LIEWNCLXSi4MEEt/57DuEfhGERtryREiVSKyGK+bppFmCh9kJ4kbum9Wj4Jr?=
 =?us-ascii?Q?L44PAhyWlsjdyUTOPZwhNzOq84OFdV5CaoQOX8W/QQ9o4qWZEhQOHEF8CANs?=
 =?us-ascii?Q?ms6KnuWuta2GaYd6/EzSgtX29ips9dk5YeF4Y6nBNA4IsT9TndxaxI+QGoAq?=
 =?us-ascii?Q?8eyRu9UuOVpa24zCccMvk/244sDbg0CLTr8EyXigPDdigIliFQrfMqvygUIt?=
 =?us-ascii?Q?Mcu1JH5TOk4Dt+5kyTYlB63ZI3vPnJrALJ0OwintG+YZwTn1XH6B4e8qqJOe?=
 =?us-ascii?Q?C2IXIJI/TsINGxHxWxytD0ktsnoqAL4qgMuQuQl+OpDWcetn2CJj9Pqz4ahF?=
 =?us-ascii?Q?EILAaiL73Q9jUhKipkj2mpIvcPwihJnmDZYEPN4H9I82K892V4wcLYROjnpo?=
 =?us-ascii?Q?2javnpPPWPYvmJzGh3gycnDEu8pHV6imBE/iTlKY3z58kCkGqoY1z7wgtnG+?=
 =?us-ascii?Q?pieAjZh1WftmLd4KSica2do2AzRB4qjVB17HBQ4NeZvgsLuRdC6Dbxq6H1dp?=
 =?us-ascii?Q?yK8yUGifLD2mauoqVpvgbsucfI1h1BM3HfWsLbU4RzgpbfBcmKg8cmNITymq?=
 =?us-ascii?Q?kviHKG5KQmCbpjzDSIAUDR/tcVbNnVqUcxI3YK9AiRUFXGFRm5+dtSX3GXWk?=
 =?us-ascii?Q?qNPpcjvWqBcsLLJrZWDfDRr+MxU09ujJy7rcXoVNYDTQderOaYnWDsYSlXSw?=
 =?us-ascii?Q?gz2kpFoiM3wIgYXn4OlUELJc/1fVSJGYLdz4i8fZRA8JqnB9YcUv3W+TjBn9?=
 =?us-ascii?Q?aAKEUIPWlRSSw1y2COywi3HVs9RAPUjsMezYXvwWI7TbtySX4CLWQH+sGGQb?=
 =?us-ascii?Q?gy/0CZ9qiLNp15fvMt+V3KOC6HJxMXyazxlg/SyyxWsbBt71eHb637ZDf0LX?=
 =?us-ascii?Q?xRWqC5RgpYIiFexFIpV9bmn0fWwz06iHmU0fYSVrgYcyDCjl3KM9zykxvMhI?=
 =?us-ascii?Q?phHkE8OaOyXmQAw88bfjNkxV5L8QRApFi/hI8aao+poMYcDrguLzWITdSZrt?=
 =?us-ascii?Q?BkyTKbkXuH582Str6KIuuMn7R1wVXwZdR63FdLHoqlTCI9sDVe8Emv/sSLYG?=
 =?us-ascii?Q?8zcuXfK4cIc+7+VSmkI4mg8eYwT/Y8AcEhuYrdyMSch6HoY2OKgkM+K7xA4b?=
 =?us-ascii?Q?O7GM3hCZeNLx7AMZDnjUjWP8OQ7JqWVgfUOWngHGrvYAH7fr31sAcegobKqa?=
 =?us-ascii?Q?jIKnbwiosG1sPxTzEaQ1CFiNOGabFyholQK2AO2wiVqY0kNzHVmSYIvgIRwC?=
 =?us-ascii?Q?dmaF4cr7LojDXuIzGDTSgl0Nfi9S1vgGhnVbQ/GA6pemRE7oDYkT1ywtxe+z?=
 =?us-ascii?Q?bWngMUa/2r86o/3NUPAZQpG6dG+SkVyx52GkbNpH4LMdCI19AYWmq7n0DSZr?=
 =?us-ascii?Q?KD3z1KLpTdl2BLx9rG0inkbeGW6pmb+Kj0eDbEJj/+gIVTXeWFAjahzZyeRI?=
 =?us-ascii?Q?GQgRNeYwcnR2w0Si7vl9xyYmr78pOCX6CcCb3VQPOeAT79mmsHLj+5khMjtW?=
 =?us-ascii?Q?p/8MRdzpqUjBfSU=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(1800799024)(376014)(13003099007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2025 11:23:52.8041
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: a3d63df6-0f35-45a1-d049-08dd40576940
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN2PEPF000044A4.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB8465

On Wed, Jan 29, 2025 at 09:52:19AM +0100, Jan Beulich wrote:
> On 29.01.2025 00:58, Stefano Stabellini wrote:
> > On Tue, 28 Jan 2025, Edgar E. Iglesias wrote:
> >> On Tue, Jan 28, 2025 at 03:15:44PM +0100, Olaf Hering wrote:
> >>> With this change the domU starts fast again:
> >>>
> >>> --- a/hw/xen/xen-mapcache.c
> >>> +++ b/hw/xen/xen-mapcache.c
> >>> @@ -522,6 +522,7 @@ ram_addr_t xen_ram_addr_from_mapcache(void *ptr)
> >>>      ram_addr_t addr;
> >>>  
> >>>      addr = xen_ram_addr_from_mapcache_single(mapcache, ptr);
> >>> +    if (1)
> >>>      if (addr == RAM_ADDR_INVALID) {
> >>>          addr = xen_ram_addr_from_mapcache_single(mapcache_grants, ptr);
> >>>      }
> >>> @@ -626,6 +627,7 @@ static void xen_invalidate_map_cache_entry_single(MapCache *mc, uint8_t *buffer)
> >>>  static void xen_invalidate_map_cache_entry_all(uint8_t *buffer)
> >>>  {
> >>>      xen_invalidate_map_cache_entry_single(mapcache, buffer);
> >>> +    if (1)
> >>>      xen_invalidate_map_cache_entry_single(mapcache_grants, buffer);
> >>>  }
> >>>  
> >>> @@ -700,6 +702,7 @@ void xen_invalidate_map_cache(void)
> >>>      bdrv_drain_all();
> >>>  
> >>>      xen_invalidate_map_cache_single(mapcache);
> >>> +    if (0)
> >>>      xen_invalidate_map_cache_single(mapcache_grants);
> >>>  }
> >>>  
> >>> I did the testing with libvirt, the domU.cfg equivalent looks like this:
> >>> maxmem = 4096
> >>> memory = 2048
> >>> maxvcpus = 4
> >>> vcpus = 2
> >>> pae = 1
> >>> acpi = 1
> >>> apic = 1
> >>> viridian = 0
> >>> rtc_timeoffset = 0
> >>> localtime = 0
> >>> on_poweroff = "destroy"
> >>> on_reboot = "destroy"
> >>> on_crash = "destroy"
> >>> device_model_override = "/usr/lib64/qemu-9.1/bin/qemu-system-i386"
> >>> sdl = 0
> >>> vnc = 1
> >>> vncunused = 1
> >>> vnclisten = "127.0.0.1"
> >>> vif = [ "mac=52:54:01:23:63:29,bridge=br0,script=vif-bridge" ]
> >>> parallel = "none"
> >>> serial = "pty"
> >>> builder = "hvm"
> >>> kernel = "/bug1236329/linux"
> >>> ramdisk = "/bug1236329/initrd"
> >>> cmdline = "console=ttyS0,115200n8 quiet ignore_loglevel""
> >>> boot = "c" 
> >>> disk = [ "format=qcow2,vdev=hda,access=rw,backendtype=qdisk,target=/bug1236329/sles12sp5.qcow2" ]
> >>> usb = 1
> >>> usbdevice = "tablet"
> >>>
> >>> Any idea what can be done to restore boot times?
> >>
> >>
> >> A guess is that it's taking a long time to walk the grants mapcache
> >> when invalidating (in QEMU). Despite it being unused and empty. We
> >> could try to find a way to keep track of usage and do nothing when
> >> invalidating an empty/unused cache.
> > 
> > If mapcache_grants is unused and empty, the call to
> > xen_invalidate_map_cache_single(mapcache_grants) should be really fast?
> > 
> > I think probably it might be the opposite: mapcache_grants is utilized,
> > so going through all the mappings in xen_invalidate_map_cache_single
> > takes time.
> > 
> > However, I wonder if it is really needed. At least in the PoD case, the
> > reason for the IOREQ_TYPE_INVALIDATE request is that the underlying DomU
> > memory has changed. But that doesn't affect the grant mappings, because
> > those are mappings of other domains' memory.
> > 
> > So I am thinking whether we should remove the call to
> > xen_invalidate_map_cache_single(mapcache_grants) ?
> > 
> > Adding x86 maintainers: do we need to flush grant table mappings for the
> > PV backends running in QEMU when Xen issues a IOREQ_TYPE_INVALIDATE
> > request to QEMU?
> 
> Judging from two of the three uses of ioreq_request_mapcache_invalidate()
> in x86'es p2m.c, I'd say no. The 3rd use there is unconditional, but
> maybe wrongly so.
> 
> However, the answer also depends on what qemu does when encountering a
> granted page. Would it enter it into its mapcache? Can it even access it?
> (If it can't, how does emulated I/O work to such pages? If it can, isn't
> this a violation of the grant's permissions, as it's targeted at solely
> the actual HVM domain named in the grant?)
>

QEMU will only map granted pages if the guest explicitly asks QEMU to
DMA into granted pages. Guests first need to grant pages to the domain
running QEMU, then pass a cookie/address to QEMU with the grant id. QEMU
will then map the granted memory, enter it into a dedicated mapcache
(mapcache_grants) and then emulate device DMA to/from the grant.

So QEMU will only map grants intended for QEMU DMA devices, not any grant
to any domain.

Details:
https://github.com/torvalds/linux/blob/master/drivers/xen/grant-dma-ops.c

Cheers,
Edgar


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 11:53:33 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 11:53:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879118.1289335 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td6dK-0000LH-V8; Wed, 29 Jan 2025 11:53:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879118.1289335; Wed, 29 Jan 2025 11:53:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td6dK-0000LA-SZ; Wed, 29 Jan 2025 11:53:26 +0000
Received: by outflank-mailman (input) for mailman id 879118;
 Wed, 29 Jan 2025 11:53: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
 <SRS0=ri1h=UV=invisiblethingslab.com=marmarek@srs-se1.protection.inumbo.net>)
 id 1td6dI-0000KD-RB
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 11:53:25 +0000
Received: from fout-b6-smtp.messagingengine.com
 (fout-b6-smtp.messagingengine.com [202.12.124.149])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a3258f06-de37-11ef-a0e6-8be0dac302b0;
 Wed, 29 Jan 2025 12:53:22 +0100 (CET)
Received: from phl-compute-01.internal (phl-compute-01.phl.internal
 [10.202.2.41])
 by mailfout.stl.internal (Postfix) with ESMTP id 923C31140142;
 Wed, 29 Jan 2025 06:53:20 -0500 (EST)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-01.internal (MEProxy); Wed, 29 Jan 2025 06:53:20 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 29 Jan 2025 06:53:17 -0500 (EST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a3258f06-de37-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm3; t=1738151600;
	 x=1738238000; bh=5kVjsOjJ1lV0xf8PMGyEsjXHM5+QwpgL4ePKOXTO7Gw=; b=
	NB+xIyjGD2gE9KRKrDaxud6TIUdIG1QSObSAQ9M3vAtucwPxhjGblTtuQSJvGVWy
	ndVPifH5YN1yhfBT+2lPAk1PQQdhCfpOJX5FeaU7oFust2aNlAk5MEpYe8uUvm/y
	KvjdAklO5cUcMzhF3VfkFnJcryeOg5ChWKfSv/tvdZIl89P8IbOMoZVB3zClWsby
	q6yCVtxGqOrufdW5mYdLVc5V80Z8z0A/uu3ysZvc2IKEmB5b5FHoD/+lhojZOlNq
	vZH9U9ruW0il/Dg8YbkhzwU7Dsp1B1C3dEdaHdxjOYJ11QxS4yUMlMcRuPoUp+Y/
	lBAlAOLzwlaCTF7/o0rZAA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:subject:subject:to
	:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=
	1738151600; x=1738238000; bh=5kVjsOjJ1lV0xf8PMGyEsjXHM5+QwpgL4eP
	KOXTO7Gw=; b=IjVVgQeYtvf6xJclgFgzYn4q4xdff5x8LH0/x3m/Ks+X6mzqUy8
	Spn0KawrTC1u6+JuRsSyeuMjX2mFJIpI7BRvhL/MY6zle5kyDzBIy0WsPbbn5we/
	d82fXF/dBmEbzXPmzZAoXVdYlv8J9D+3FfUuLwDPApXb9ENm7PvQcZu3FmSUOTn9
	rtVoF3ayXZ+SyhDDYdxoUafO1B2M0AozfCSLBUd3+fRtDiREwgu/yJ8En2WdBZTY
	yHDMZwjXBUVSY63tZq+4YgEKP1BDW+ORHHw1x3I1NbGflRkrDfg+JSCQ1W/29/1+
	uODGXGjFnBuuZMHJeXXbE51LfNu5zbn7afQ==
X-ME-Sender: <xms:rxaaZxZHIhPNfz9J7puVjg0g-XbQhGEV4mw8LhRtIO2uUmuGbkOdUg>
    <xme:rxaaZ4YktNWiCg_5XxfU_9Mx8-UQyqULE9inctYc1Qs2AD7rkbpxkjYNimRKTHLSC
    BdpnWGXM7geEQ>
X-ME-Received: <xmr:rxaaZz9JbK0JxP83b6LWLXBxVtmvSThIFhiKHeZqFTwKg7X87NikVRWKKA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddvledvucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
    rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
    htshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtjeen
    ucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomh
    grrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggft
    rfgrthhtvghrnhepgfduleetfeevhfefheeiteeliefhjefhleduveetteekveettddvge
    euteefjedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhho
    mhepmhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnh
    gspghrtghpthhtohepudefpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehjsggv
    uhhlihgthhesshhushgvrdgtohhmpdhrtghpthhtohepsghhvghlghgrrghssehgohhogh
    hlvgdrtghomhdprhgtphhtthhopehjghhrohhsshesshhushgvrdgtohhmpdhrtghpthht
    oheprhhoghgvrhdrphgruhestghithhrihigrdgtohhmpdhrtghpthhtohepsghorhhish
    drohhsthhrohhvshhkhiesohhrrggtlhgvrdgtohhmpdhrtghpthhtohepgigvnhdquggv
    vhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdhrtghpthhtoheplhhinh
    hugidqkhgvrhhnvghlsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheprhgv
    ghhrvghsshhiohhnsheslhhishhtshdrlhhinhhugidruggvvhdprhgtphhtthhopehnsg
    gusehnsggurdhnrghmvg
X-ME-Proxy: <xmx:rxaaZ_o14Y1yYSHINJ9lVdCij1hHDGJS00znShf0NjFe1WjVNb3HYA>
    <xmx:rxaaZ8pbHoprt6ZkjabWHGfbHbJso-CoBM7yp-91YaBaM_QWI6OsCg>
    <xmx:rxaaZ1Qtg2BTUuYw-qyH0eOUvmvmW0h5Z75JtwutuAbyEhG7skIiRA>
    <xmx:rxaaZ0pWoQYrxpW1Qkjonw9uwntE0msRt4vCjY7Z27VW-S7GDqWGzQ>
    <xmx:sBaaZ561c46PVu3fMc4UG3ul1Y9PryvVUZgBzi3sKqsBcp5BAgtaD89n>
Feedback-ID: i1568416f:Fastmail
Date: Wed, 29 Jan 2025 12:53:15 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	=?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	linux-kernel@vger.kernel.org, regressions@lists.linux.dev,
	Felix Fietkau <nbd@nbd.name>, Lorenzo Bianconi <lorenzo@kernel.org>,
	Ryder Lee <ryder.lee@mediatek.com>, linux-pci@vger.kernel.org,
	Bjorn Helgaas <helgaas@kernel.org>
Subject: Re: Config space access to Mediatek MT7922 doesn't work after device
 reset in Xen PV dom0 (regression, Linux 6.12)
Message-ID: <Z5oWq4YgMgwWvl2G@mail-itl>
References: <Z5mOKQUrgeF_r6te@mail-itl>
 <20250129030315.GA392478@bhelgaas>
 <Z5mfA32bvEn6yD-C@mail-itl>
 <22ad7276-624d-49fb-a2bb-1b7908318a4e@suse.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="a+GZJj6pK/SHY+Cv"
Content-Disposition: inline
In-Reply-To: <22ad7276-624d-49fb-a2bb-1b7908318a4e@suse.com>


--a+GZJj6pK/SHY+Cv
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Wed, 29 Jan 2025 12:53:15 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	=?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	linux-kernel@vger.kernel.org, regressions@lists.linux.dev,
	Felix Fietkau <nbd@nbd.name>, Lorenzo Bianconi <lorenzo@kernel.org>,
	Ryder Lee <ryder.lee@mediatek.com>, linux-pci@vger.kernel.org,
	Bjorn Helgaas <helgaas@kernel.org>
Subject: Re: Config space access to Mediatek MT7922 doesn't work after device
 reset in Xen PV dom0 (regression, Linux 6.12)

On Wed, Jan 29, 2025 at 10:17:20AM +0100, Jan Beulich wrote:
> On 29.01.2025 04:22, Marek Marczykowski-G=C3=B3recki wrote:
> > On Tue, Jan 28, 2025 at 09:03:15PM -0600, Bjorn Helgaas wrote:
> >> The report claims the problem only happens with Xen.  I'm not a Xen
> >> person, and I don't know how to find the relevant config accessors.
> >> The snippets of kernel messages I see at [1] all mention pciback, so
> >> that's my only clue of where to look.  Bottom line, I have no idea
> >> what the config accessor path is, and maybe we could learn something
> >> by looking at whatever it is.
> >=20
> > AFAIK there are no separate config accessors under Xen dom0, the default
> > ones are used. xen-pcifront takes over PCI config space access (and few
> > more) only in a domU (and only for PV), when PCI passthrough is used.
> > Here, it didn't went that far...
> >=20
> > But then, Xen may intercept such access [2]. If I read it right, it
> > should allow all access (is_hardware_domain(dom0)=3D=3Dtrue, and also t=
he
> > device is not on ro_map - otherwise reset wouldn't work at all).
>=20
> The other day you mentioned (on Matrix I think) that you observe mmcfg
> not being used on that system. Am I misremembering? (Since the capability
> where the control bit lives is an extended one, that capability would
> neither be read nor modified when mmcfg is unavailable.)

Yes, but later (once dom0 starts) it switched back to mmcfg. Now I see
this:
(XEN) PCI: MCFG configuration 0: base e0000000 segment 0000 buses 00 - ff
(XEN) PCI: Using MCFG for segment 0000 bus 00-ff

Another thing I noticed in the bug report - the reporter says warm
reboot from 6.11 (where it works) to 6.12 avoids the issue (not sure
about further reboots). Cold boot directly to 6.12 results in this buggy
behavior.

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

--a+GZJj6pK/SHY+Cv
Content-Type: application/pgp-signature; name="signature.asc"

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmeaFqsACgkQ24/THMrX
1ywvTQf/YYurxRaUAGuLjE9v/1EfWAM03m/V7lXiOvaN91b2+QkGZhFeQjEnpgwC
1y+Qyhfyd/CYfTs5pX/3OJ2PvGHDOMBaRKHrPer+C31qBYf2025xPK/M345aLiHp
XMjaIaI6JCVvVO718jleh/+mqtCGCPW4VB4liMmyHGquUrs72mBacofGKYEgh149
sL3UEpSrAoFmy9mxVkNdGJLSZp6oW6zuXpkAJx4QeW5TzgY0F26BZUCDi5Py1R0m
DvDmauAZRPKJH6/7lpw4aacRrLk9Y/dIbX51ELBxP1n3BcDmyHLEw1TECE+NPTGX
HOfpgyyvw+YPtsG6sbXgLqYOoyZsaQ==
=uRq/
-----END PGP SIGNATURE-----

--a+GZJj6pK/SHY+Cv--


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 12:49:42 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 12:49:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879132.1289345 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td7VZ-0007LU-3O; Wed, 29 Jan 2025 12:49:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879132.1289345; Wed, 29 Jan 2025 12:49:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td7VZ-0007LN-0x; Wed, 29 Jan 2025 12:49:29 +0000
Received: by outflank-mailman (input) for mailman id 879132;
 Wed, 29 Jan 2025 12:49:28 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=1peA=UV=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1td7VY-0007LF-Dq
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 12:49:28 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 76c434f0-de3f-11ef-99a4-01e77a169b0f;
 Wed, 29 Jan 2025 13:49:23 +0100 (CET)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-ab2bb0822a4so1311669366b.3
 for <xen-devel@lists.xenproject.org>; Wed, 29 Jan 2025 04:49:23 -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
 a640c23a62f3a-ab6963743d7sm706321566b.91.2025.01.29.04.49.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 29 Jan 2025 04:49:22 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 76c434f0-de3f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738154962; x=1738759762; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=P13nDXn0ksUze1YCLpPOQ4mzqk36RMO0+DPY/3Rbc7I=;
        b=VsE+nihzm59nR67Vsk7DxX+Ofwj/RE5SxLCirXsMrTh+yffXV36RA+Qg1PaKCF/IMk
         S2sFkdE/DnNqIHf9xj4wiCxKOR13ghw3gcih4tPB+/3ltu2zdp9vGf8IofhcnIICs3Cq
         E9rMpM3KLLm0hLDjfFJsmSXRc2ZnHES+/Cw335UfwNrdPsAG4NU3uyVD1RwfzE7+4RwP
         7u+hwiFn79JRJ1CKgrS/xgjAbJhQfltg32XkIfHrzE1mGZ1aiyHFXYBy6yJdFIFOU6UN
         Lx8i2p6lSBSIDhFQi8sIHvrnXbkSLvKfXU+exGRlRew3Fn1ZN9FmXIbLZdu1a8fRxI36
         t9aA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738154962; x=1738759762;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=P13nDXn0ksUze1YCLpPOQ4mzqk36RMO0+DPY/3Rbc7I=;
        b=vx7Vwdaw7+bAms22HC47AyJPzWFJh6k7HnZP63LW4mIwfd/Y6CO4nU2zCM8FjPEViK
         bMJa7dxNHe2O1/LqT50ydepxqftqpkH5ICoVLgjFW9UsRcKAXP1l92nahwRoXdcUPJEB
         mlVEZxivAPPcUtbpGaLZ+o4d37DMYkvPIQOXwAxgKB1roPIwGYAZVlT8N/tjb50DeZxi
         oJv/5Ctsze+cJMBygOqdjuS43sEVaq+R6qOSHdNMqv8NSsyw1KBATycGKtz5Z8cyK8NA
         ttP+Y2GcH3LCdBSTCF18gALXppZhJwMLjUQVcS7vvL5Ql+iEyA02Z3zv6ikVKFwnMR0z
         qFBw==
X-Forwarded-Encrypted: i=1; AJvYcCWUz3cVFyVkaL+Fzxd0+Kk5CwVUYJdNB+l3YV9FmXHcVefxx8Uh3jS4FoDJGe9QvbBOS6airZf6ewE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzpUu7LZBySCplQmMUrQSSHjh15lm1qXmZ6XS5Uez4YJXyQYW8/
	BahgAM1BejyfK2COzanZmGEGabtMOWdSCsH7lysQlmMdlk16D39hYpPRnxraeA==
X-Gm-Gg: ASbGncvP9/UduDd8fUZRw1TANr+p5J8YqXDH5MP6Rl6evsEXzypRcnGdgV5wWvxsy9w
	rlOtJ/vKXF7yhV/k0TVnDMig/ZPHjZfPcyYo2h9BQT6UJmdVAEEPjQP/MtZZ6jZJ6XrkWUgFsy3
	Kb7Xg/2T9yHW3c0dVhNitqVBXCCgVAS6r0i2uIKBcPHnudkTCCteszuskr3+mIK60ASLADYqPhp
	gl6XKPHWaYZHn4H8moU/Yq9ReIokYkIaqb63+V/Hxp07fVWOXNfYRFfdor6eAKFvnNwouTKeuZl
	6v24HP+lr5FThu63inXyw4EqtgXSXfTh73Ro8p8i+sZVaLLYE4s1CHLQkuFfb0Ejt1JzH6vlLqH
	J
X-Google-Smtp-Source: AGHT+IFbOOXBWI8FB+7yf4hzIic7jBHj46Y0AzXKI74CLRhnwt0JFJ60eK4jgC+pdzwi6Ic0HcyRYQ==
X-Received: by 2002:a17:907:7fa1:b0:ab2:ea29:b6 with SMTP id a640c23a62f3a-ab6cfdd851amr290915766b.35.1738154962327;
        Wed, 29 Jan 2025 04:49:22 -0800 (PST)
Message-ID: <4d7ed713-68b5-4e9c-8952-002d21d662d6@suse.com>
Date: Wed, 29 Jan 2025 13:49:20 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Config space access to Mediatek MT7922 doesn't work after device
 reset in Xen PV dom0 (regression, Linux 6.12)
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>, =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?=
 <jgross@suse.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 xen-devel <xen-devel@lists.xenproject.org>, linux-kernel@vger.kernel.org,
 regressions@lists.linux.dev, Felix Fietkau <nbd@nbd.name>,
 Lorenzo Bianconi <lorenzo@kernel.org>, Ryder Lee <ryder.lee@mediatek.com>,
 linux-pci@vger.kernel.org, Bjorn Helgaas <helgaas@kernel.org>
References: <Z5mOKQUrgeF_r6te@mail-itl> <20250129030315.GA392478@bhelgaas>
 <Z5mfA32bvEn6yD-C@mail-itl> <22ad7276-624d-49fb-a2bb-1b7908318a4e@suse.com>
 <Z5oWq4YgMgwWvl2G@mail-itl>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <Z5oWq4YgMgwWvl2G@mail-itl>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 29.01.2025 12:53, Marek Marczykowski-Górecki wrote:
> On Wed, Jan 29, 2025 at 10:17:20AM +0100, Jan Beulich wrote:
>> On 29.01.2025 04:22, Marek Marczykowski-Górecki wrote:
>>> On Tue, Jan 28, 2025 at 09:03:15PM -0600, Bjorn Helgaas wrote:
>>>> The report claims the problem only happens with Xen.  I'm not a Xen
>>>> person, and I don't know how to find the relevant config accessors.
>>>> The snippets of kernel messages I see at [1] all mention pciback, so
>>>> that's my only clue of where to look.  Bottom line, I have no idea
>>>> what the config accessor path is, and maybe we could learn something
>>>> by looking at whatever it is.
>>>
>>> AFAIK there are no separate config accessors under Xen dom0, the default
>>> ones are used. xen-pcifront takes over PCI config space access (and few
>>> more) only in a domU (and only for PV), when PCI passthrough is used.
>>> Here, it didn't went that far...
>>>
>>> But then, Xen may intercept such access [2]. If I read it right, it
>>> should allow all access (is_hardware_domain(dom0)==true, and also the
>>> device is not on ro_map - otherwise reset wouldn't work at all).
>>
>> The other day you mentioned (on Matrix I think) that you observe mmcfg
>> not being used on that system. Am I misremembering? (Since the capability
>> where the control bit lives is an extended one, that capability would
>> neither be read nor modified when mmcfg is unavailable.)
> 
> Yes, but later (once dom0 starts) it switched back to mmcfg. Now I see
> this:
> (XEN) PCI: MCFG configuration 0: base e0000000 segment 0000 buses 00 - ff
> (XEN) PCI: Using MCFG for segment 0000 bus 00-ff
> 
> Another thing I noticed in the bug report - the reporter says warm
> reboot from 6.11 (where it works) to 6.12 avoids the issue (not sure
> about further reboots). Cold boot directly to 6.12 results in this buggy
> behavior.

Makes things yet more odd, imo.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 13:12:13 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 13:12:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879140.1289356 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td7rU-0002p1-SU; Wed, 29 Jan 2025 13:12:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879140.1289356; Wed, 29 Jan 2025 13:12:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td7rU-0002ou-PY; Wed, 29 Jan 2025 13:12:08 +0000
Received: by outflank-mailman (input) for mailman id 879140;
 Wed, 29 Jan 2025 13:12:07 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=2GOy=UV=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1td7rT-0002oo-8w
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 13:12:07 +0000
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com
 [2a00:1450:4864:20::434])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a29e5dfa-de42-11ef-99a4-01e77a169b0f;
 Wed, 29 Jan 2025 14:12:05 +0100 (CET)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-38a25d4b9d4so3711868f8f.0
 for <xen-devel@lists.xenproject.org>; Wed, 29 Jan 2025 05:12:05 -0800 (PST)
Received: from [192.168.100.192] (lfbn-gre-1-190-108.w90-112.abo.wanadoo.fr.
 [90.112.153.108]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38c2a188c28sm17400228f8f.54.2025.01.29.05.12.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 29 Jan 2025 05:12:03 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a29e5dfa-de42-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1738156324; x=1738761124; darn=lists.xenproject.org;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=trLx6JwfJllUuS8P0EqTYKZd77YfKPSeHak/5lAU2Ws=;
        b=YpIVd/vdHOUznzj8npzXSB1lNTVGjkNrQdTki/voRT+MySAyOM9ly7Hy52rXYTsOeE
         AtxzBxtJkkywJChl0yEpkWnA7kEgNpl7YFkmulFruOmT+kGhX4DaixezVcxu0guTI8bt
         +wBHkExEKyFc1/ujVSzPKc04DDxThPA+JIou6ZBkT+fqFGyn1oXomwSGHjPB2s4bUoep
         DutTep4waHbbnlMoLXRVrOyjlEn8rV4wAnH1y+DIH5KZ18rFpGn6SXCj1V/4w4c7VSRZ
         qJ9WcQD/E2WGXwdHp7MXW56x/sOYvH2+y49ITtSJscmctkqKD5/PYeJsslutvNo2g2Zx
         AVNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738156324; x=1738761124;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=trLx6JwfJllUuS8P0EqTYKZd77YfKPSeHak/5lAU2Ws=;
        b=oE1Rs2xyJBrZTs8Lc6IttWYOwCR+oNTLPk2r5U8kT9DYQJW51bQDxR5NIRtmS4R6VK
         4veMzBrEMg3w6BzaHWsQrRWxmbK7YNu3E5TDmNUqtz3Z8oLCwpno9O+rnUN1l8PtwJxn
         z968pUfd1d/g9Yw4fAfHxf6uCqZPz1mqg3SnF3Tsf7joeqPsbfemPjSumNfvwCtVHHPA
         WN1vlXCFeJkqR6HxVC3usbaUxmKola1ReNMkyIfYiEA1Z2tl4YvNvq0O53e+wFee9x/P
         pxUZV0qw37l0Kk74WL0phaamRnXFHkhUVzh0UL3gZKemSe0UUo1hpgvW/o7x4q3+MaM5
         GYsQ==
X-Forwarded-Encrypted: i=1; AJvYcCV01MXm3kIEp9obl1Qil7O9HZd8PUSkFB412rSJLhuc6s2lzrfkHIKRBCUWWSHcvk8A93BDI39CKP8=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyfco/5qFp/+OoH+OxbcycGm1x/kP35IjuGlmd+wMRfeqsCI9Es
	fihYDRVuq6l4byrSr62/TqD1bLR8cmCL2ZQNyXGeqCNEYHiYrclU
X-Gm-Gg: ASbGnctVP8SfyEvVS2XCKRjDGWl34JSj53FhBfwwgCSbBMr631A6Anoz/vxkoJKFLSw
	q5LqqdQjT86zdeuVXA7UgsPw5XPOROdiohjv7rtAvzEhRHTnuI/HuVXcrCoo5jH93q5GyZJ0ND4
	LLRUFt9h6c7z7hxlL7PqJgTJVNhXd5Hig5iO9TzuGeBjkCNFtsrArBEWlHTUtCRisfvRj6cxPA2
	CRUcWWu5gWd0unkQhpCRAPnSG0om1GtnxNbYvEJZRGDUIcc77OaYb1W14//UQHbW7Ng3VU2ryn+
	fplLcGqVYxUuQTDElaHlqoAXLWF0xOx3v8PMPtic/sF0KUjHyk+cEF06/UJwscwkRTCg55UFdSs
	QHwg=
X-Google-Smtp-Source: AGHT+IEHubvAsDZ74swSz5SL8CjeMUqbYGgB1C02KK746+NkISr7fYrOoudFEMRA7WqPTzVvzldgBw==
X-Received: by 2002:a5d:5906:0:b0:388:caf4:e909 with SMTP id ffacd0b85a97d-38c51b5d858mr2472232f8f.25.1738156324167;
        Wed, 29 Jan 2025 05:12:04 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------ypomjzEAl5vSfD0OKh9jNtFl"
Message-ID: <c602d580-8d62-4fa9-9aa4-37fbd6201fa3@gmail.com>
Date: Wed, 29 Jan 2025 14:12:03 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 1/3] xen/riscv: implement software page table walking
To: Jan Beulich <jbeulich@suse.com>
Cc: Alistair Francis <alistair.francis@wdc.com>,
 Bob Eshleman <bobbyeshleman@gmail.com>, Connor Davis
 <connojdavis@gmail.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1737391102.git.oleksii.kurochko@gmail.com>
 <00dfc71569bc9971b53e29b36a80e9e020ac61ac.1737391102.git.oleksii.kurochko@gmail.com>
 <21bfd2f5-74b8-409e-956c-dd736a3c0be2@suse.com>
 <e2290a2a-a3c0-4cfe-b9e9-8cfec0b194a8@gmail.com>
 <a304e4f0-709f-4fcd-9847-01fe6ab4b98c@suse.com>
 <d9ca4252-1bf0-4257-ad6b-e91240cc5de3@gmail.com>
 <dfe0c6c5-db4a-4e27-9963-fe1b0c2bf629@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <dfe0c6c5-db4a-4e27-9963-fe1b0c2bf629@suse.com>

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


On 1/28/25 9:14 AM, Jan Beulich wrote:
> On 27.01.2025 18:22, Oleksii Kurochko wrote:
>> On 1/27/25 1:57 PM, Jan Beulich wrote:
>>> On 27.01.2025 13:29, Oleksii Kurochko wrote:
>>>> On 1/27/25 11:06 AM, Jan Beulich wrote:
>>>>> On 20.01.2025 17:54, Oleksii Kurochko wrote:
>>>>>> RISC-V doesn't have hardware feature to ask MMU to translate
>>>>>> virtual address to physical address ( like Arm has, for example ),
>>>>>> so software page table walking in implemented.
>>>>>>
>>>>>> Signed-off-by: Oleksii Kurochko<oleksii.kurochko@gmail.com>
>>>>>> ---
>>>>>>     xen/arch/riscv/include/asm/mm.h |  2 ++
>>>>>>     xen/arch/riscv/pt.c             | 56 +++++++++++++++++++++++++++++++++
>>>>>>     2 files changed, 58 insertions(+)
>>>>>>
>>>>>> diff --git a/xen/arch/riscv/include/asm/mm.h b/xen/arch/riscv/include/asm/mm.h
>>>>>> index 292aa48fc1..d46018c132 100644
>>>>>> --- a/xen/arch/riscv/include/asm/mm.h
>>>>>> +++ b/xen/arch/riscv/include/asm/mm.h
>>>>>> @@ -15,6 +15,8 @@
>>>>>>     
>>>>>>     extern vaddr_t directmap_virt_start;
>>>>>>     
>>>>>> +paddr_t pt_walk(vaddr_t va);
>>>>> In the longer run, is returning just the PA really going to be sufficient?
>>>>> If not, perhaps say a word on the limitation in the description.
>>>> In the long run, this function's prototype looks like|paddr_t pt_walk(vaddr_t root, vaddr_t va, bool is_xen)| [1]. However, I'm not sure if it will stay that way,
>>>> as I think|is_xen| could be skipped, since using|map_table()| should be sufficient (as it now considers|system_state|) and I'm not really sure if I need root argument
>>>> as initial goal was to use this function for debug only purposes and I've never used it for guest page table (stage-1) walking.
>>>> Anyway, yes, it is still returning a physical address, and that seems enough to me.
>>>>
>>>> Could you share your thoughts on what I should take into account for returning value, probably, I am missing something really useful?
>>> Often you care about the permissions as well. Sometimes it may even be relevant
>>> to know the (super-)page size of the mapping.
>> Perhaps it would be better to change the prototype to:
>>     bool pt_walk(vaddr_t va, mfn_t *ret_pa);
>> or even
>>     void pt_walk(vaddr_t va, mfn_t *ret_pa);
>>     In this case,|ret_pa = INVALID_MFN| could serve as a signal that|pt_walk()| failed.
>> If there's a need to return permissions or (super-)page size in the future, another argument could be added.
>>
>> What do you think? Would this approach be better?
>>
>> I am also considering returning a structure containing the|mfn| (or|paddr_t|) and adding other properties (such as permissions or
>> page size) as needed in the future. Both solutions seem more or less equivalent.
> Imo the most natural thing for a page walking function would be to return the
> leaf PTE (or the leaf-most not-present [or otherwise "no-access"] one). That
> would provide (almost) all possible information to the caller. "Almost"
> because depending on how page walk works, permissions may combine across page
> table levels. Yet then (see also the "no-access" above) this would also
> require further input, to specify the context for which the translation is
> being seeked. For example, the intention to write may want to yield no valid
> PTE when there are present ones down to the leaf, but effective permissions
> say "read-only".

Perhaps returning the leaf PTE could be a really good option.

I'm not entirely sure I understand what you mean by "leaf-most not-present". Could you please try to explain this moment one more time?
My expectation was that the function should return an existing leaf PTE (from which "access" rights could be determined)
or|NULL| to indicate that no leaf PTE was found.

Another thing I'm curious about is whether this would be sufficient for determining the level.
It seems clear that, given a PTE and a virtual address, we could compute:
|mask = VA | paddr_from_pte(pte)|
Then, iterating through each level, we could apply and understand on which one level it was mapped:
|mask & (BIT(XEN_PT_LEVEL_ORDER(i), UL) - 1)|.

If I haven't overlooked any other way to calculate the page table level, would it be better to simply add another argument
to|pt_walk()| to return the level.

Thanks.


~ Oleksii

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

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 1/28/25 9:14 AM, Jan Beulich wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:dfe0c6c5-db4a-4e27-9963-fe1b0c2bf629@suse.com">
      <pre wrap="" class="moz-quote-pre">On 27.01.2025 18:22, Oleksii Kurochko wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">On 1/27/25 1:57 PM, Jan Beulich wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="" class="moz-quote-pre">On 27.01.2025 13:29, Oleksii Kurochko wrote:
</pre>
          <blockquote type="cite">
            <pre wrap="" class="moz-quote-pre">On 1/27/25 11:06 AM, Jan Beulich wrote:
</pre>
            <blockquote type="cite">
              <pre wrap="" class="moz-quote-pre">On 20.01.2025 17:54, Oleksii Kurochko wrote:
</pre>
              <blockquote type="cite">
                <pre wrap="" class="moz-quote-pre">RISC-V doesn't have hardware feature to ask MMU to translate
virtual address to physical address ( like Arm has, for example ),
so software page table walking in implemented.

Signed-off-by: Oleksii Kurochko<a class="moz-txt-link-rfc2396E" href="mailto:oleksii.kurochko@gmail.com">&lt;oleksii.kurochko@gmail.com&gt;</a>
---
   xen/arch/riscv/include/asm/mm.h |  2 ++
   xen/arch/riscv/pt.c             | 56 +++++++++++++++++++++++++++++++++
   2 files changed, 58 insertions(+)

diff --git a/xen/arch/riscv/include/asm/mm.h b/xen/arch/riscv/include/asm/mm.h
index 292aa48fc1..d46018c132 100644
--- a/xen/arch/riscv/include/asm/mm.h
+++ b/xen/arch/riscv/include/asm/mm.h
@@ -15,6 +15,8 @@
   
   extern vaddr_t directmap_virt_start;
   
+paddr_t pt_walk(vaddr_t va);
</pre>
              </blockquote>
              <pre wrap="" class="moz-quote-pre">In the longer run, is returning just the PA really going to be sufficient?
If not, perhaps say a word on the limitation in the description.
</pre>
            </blockquote>
            <pre wrap="" class="moz-quote-pre">In the long run, this function's prototype looks like|paddr_t pt_walk(vaddr_t root, vaddr_t va, bool is_xen)| [1]. However, I'm not sure if it will stay that way,
as I think|is_xen| could be skipped, since using|map_table()| should be sufficient (as it now considers|system_state|) and I'm not really sure if I need root argument
as initial goal was to use this function for debug only purposes and I've never used it for guest page table (stage-1) walking.
Anyway, yes, it is still returning a physical address, and that seems enough to me.

Could you share your thoughts on what I should take into account for returning value, probably, I am missing something really useful?
</pre>
          </blockquote>
          <pre wrap="" class="moz-quote-pre">Often you care about the permissions as well. Sometimes it may even be relevant
to know the (super-)page size of the mapping.
</pre>
        </blockquote>
        <pre wrap="" class="moz-quote-pre">
Perhaps it would be better to change the prototype to:
   bool pt_walk(vaddr_t va, mfn_t *ret_pa);
or even
   void pt_walk(vaddr_t va, mfn_t *ret_pa);
   In this case,|ret_pa = INVALID_MFN| could serve as a signal that|pt_walk()| failed.
If there's a need to return permissions or (super-)page size in the future, another argument could be added.

What do you think? Would this approach be better?

I am also considering returning a structure containing the|mfn| (or|paddr_t|) and adding other properties (such as permissions or
page size) as needed in the future. Both solutions seem more or less equivalent.
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
Imo the most natural thing for a page walking function would be to return the
leaf PTE (or the leaf-most not-present [or otherwise "no-access"] one). That
would provide (almost) all possible information to the caller. "Almost"
because depending on how page walk works, permissions may combine across page
table levels. Yet then (see also the "no-access" above) this would also
require further input, to specify the context for which the translation is
being seeked. For example, the intention to write may want to yield no valid
PTE when there are present ones down to the leaf, but effective permissions
say "read-only".</pre>
    </blockquote>
    <div class="flex max-w-full flex-col flex-grow">
      <div data-message-author-role="assistant"
        data-message-id="1bca5013-9c80-49e2-b761-5a57d8de95d0"
        dir="auto"
class="min-h-8 text-message flex w-full flex-col items-end gap-2 whitespace-normal break-words text-start [.text-message+&amp;]:mt-5"
        data-message-model-slug="gpt-4o">
        <div
          class="flex w-full flex-col gap-1 empty:hidden first:pt-[3px]">
          <div
class="markdown prose w-full break-words dark:prose-invert light">
            <pre>Perhaps returning the leaf PTE could be a really good option.</pre>
            <pre>I'm not entirely sure I understand what you mean by "leaf-most not-present". Could you please try to explain this moment one more time?
My expectation was that the function should return an existing leaf PTE (from which "access" rights could be determined)
or <code>NULL</code> to indicate that no leaf PTE was found.</pre>
            <pre>Another thing I'm curious about is whether this would be sufficient for determining the level.
It seems clear that, given a PTE and a virtual address, we could compute:
<code>  mask = VA | paddr_from_pte(pte)</code>
Then, iterating through each level, we could apply and understand on which one level it was mapped:
<code>  mask &amp; (BIT(XEN_PT_LEVEL_ORDER(i), UL) - 1)</code>.</pre>
            <pre>If I haven't overlooked any other way to calculate the page table level, would it be better to simply add another argument
to <code>pt_walk()</code> to return the level.</pre>
          </div>
        </div>
      </div>
    </div>
    <pre>
Thanks.


~ Oleksii
</pre>
    <blockquote type="cite"
      cite="mid:dfe0c6c5-db4a-4e27-9963-fe1b0c2bf629@suse.com">
      <pre wrap="" class="moz-quote-pre">

Jan
</pre>
    </blockquote>
  </body>
</html>

--------------ypomjzEAl5vSfD0OKh9jNtFl--


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 13:28:57 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 13:28:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879150.1289366 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td87f-0004bk-93; Wed, 29 Jan 2025 13:28:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879150.1289366; Wed, 29 Jan 2025 13:28:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td87f-0004bd-4v; Wed, 29 Jan 2025 13:28:51 +0000
Received: by outflank-mailman (input) for mailman id 879150;
 Wed, 29 Jan 2025 13:28:49 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=CGF7=UV=kernel.org=helgaas@srs-se1.protection.inumbo.net>)
 id 1td87d-0004bX-52
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 13:28:49 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org
 [2604:1380:45d1:ec00::3])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f7530e31-de44-11ef-99a4-01e77a169b0f;
 Wed, 29 Jan 2025 14:28:46 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id C8E33A41998;
 Wed, 29 Jan 2025 13:26:58 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0FE94C4CED3;
 Wed, 29 Jan 2025 13:28:44 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f7530e31-de44-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1738157325;
	bh=dE0lsgSjq4wk0o7MP8rz5Jo7m5fcmyVktKNkz3zHsZc=;
	h=Date:From:To:Cc:Subject:In-Reply-To:From;
	b=hqZWOMa6ZL1bscQx1L8m6C56jziOWBnJArDsY11+mhGnyX5uXmGC0E80eJst57Hbx
	 r4qSCNBkneQ4tYvtNB4Ewcw3TEjRMIV3amFJd7RiebPbTq+CNsC2xPa1M0JSexNDBN
	 YEYRKsY8OAWvjbYuXz7TxaMnpnrayTBjS01sw2J0BZUzW4q3z/KH6goEWuO+LV6XyS
	 VC/NPUQ+iTcQZSb52f8voS3dHNjq0KPFLNl+xU3/BofWCK9mAPUoBGHlGHbAzd6jq1
	 ipliraRXQHamGVvYpM6PQ1ozCRK+SoK3BMIguJymRwxoH70yHAHxw5WqJxg3sLJJPK
	 hJ4yVWsecHVlg==
Date: Wed, 29 Jan 2025 07:28:43 -0600
From: Bjorn Helgaas <helgaas@kernel.org>
To: Jan Beulich <jbeulich@suse.com>
Cc: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	=?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	linux-kernel@vger.kernel.org, regressions@lists.linux.dev,
	Felix Fietkau <nbd@nbd.name>, Lorenzo Bianconi <lorenzo@kernel.org>,
	Ryder Lee <ryder.lee@mediatek.com>, linux-pci@vger.kernel.org
Subject: Re: Config space access to Mediatek MT7922 doesn't work after device
 reset in Xen PV dom0 (regression, Linux 6.12)
Message-ID: <20250129132843.GA451331@bhelgaas>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <22ad7276-624d-49fb-a2bb-1b7908318a4e@suse.com>

On Wed, Jan 29, 2025 at 10:17:20AM +0100, Jan Beulich wrote:
> On 29.01.2025 04:22, Marek Marczykowski-Górecki wrote:
> > On Tue, Jan 28, 2025 at 09:03:15PM -0600, Bjorn Helgaas wrote:
> >> The report claims the problem only happens with Xen.  I'm not a Xen
> >> person, and I don't know how to find the relevant config accessors.
> >> The snippets of kernel messages I see at [1] all mention pciback, so
> >> that's my only clue of where to look.  Bottom line, I have no idea
> >> what the config accessor path is, and maybe we could learn something
> >> by looking at whatever it is.
> > 
> > AFAIK there are no separate config accessors under Xen dom0, the default
> > ones are used. xen-pcifront takes over PCI config space access (and few
> > more) only in a domU (and only for PV), when PCI passthrough is used.
> > Here, it didn't went that far...
> > 
> > But then, Xen may intercept such access [2]. If I read it right, it
> > should allow all access (is_hardware_domain(dom0)==true, and also the
> > device is not on ro_map - otherwise reset wouldn't work at all).
> 
> The other day you mentioned (on Matrix I think) that you observe mmcfg
> not being used on that system. Am I misremembering? (Since the capability
> where the control bit lives is an extended one, that capability would
> neither be read nor modified when mmcfg is unavailable.)

If you're referring to the Configuration RRS Software Visibility
Enable bit, that's in the PCIe Capability Root Control register, which
is in the PCI-compatible config space (the first 256 bytes), not the
extended config space.


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 13:33:02 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 13:33:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879159.1289375 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td8Bf-0006Ei-Ms; Wed, 29 Jan 2025 13:32:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879159.1289375; Wed, 29 Jan 2025 13:32:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td8Bf-0006Eb-KD; Wed, 29 Jan 2025 13:32:59 +0000
Received: by outflank-mailman (input) for mailman id 879159;
 Wed, 29 Jan 2025 13:32:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=CGF7=UV=kernel.org=helgaas@srs-se1.protection.inumbo.net>)
 id 1td8Bd-0006EV-JD
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 13:32:57 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8bcd1b84-de45-11ef-99a4-01e77a169b0f;
 Wed, 29 Jan 2025 14:32:55 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 0BFBEA4199A;
 Wed, 29 Jan 2025 13:31:08 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 52D71C4CED3;
 Wed, 29 Jan 2025 13:32:54 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8bcd1b84-de45-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1738157574;
	bh=Oj1ZVJfnXAYooWc8hOhsJbc/6YWDuBpD07JCgUIgQDI=;
	h=Date:From:To:Cc:Subject:In-Reply-To:From;
	b=ER6EE5lEstGLOFLOhrOEHtH6rntIFrgDIMN1DNORpww68H/ycR4TEz1rI7+79XuIo
	 aHC+ivPaam3BB+Jvaan3QqFydC9knTEJmIUqUbNaHSVvmwe2sdaJ8ySeTyGoWCSsKr
	 SY2LA5gghaI61hwBPoxbHbLbYl1L05Azl+6gom1EZO5+fkinCspr2cO0MR6r3LspIX
	 Q/3e1uqmM1P4t82Og8dij20d3qLF7dEaTSyrxN9B5ql5cuOS22SJvLUR4wsjoMKBhW
	 EqJU97GBj9KeW4UUo6yPiEahGWtwkL2P5/L9fkMwE1/ph2nSooJKL8NMHJbTcUI5Kf
	 V2g2Cc46V6YVg==
Date: Wed, 29 Jan 2025 07:32:52 -0600
From: Bjorn Helgaas <helgaas@kernel.org>
To: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	=?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	linux-kernel@vger.kernel.org, regressions@lists.linux.dev,
	Felix Fietkau <nbd@nbd.name>, Lorenzo Bianconi <lorenzo@kernel.org>,
	Ryder Lee <ryder.lee@mediatek.com>, linux-pci@vger.kernel.org,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: Config space access to Mediatek MT7922 doesn't work after device
 reset in Xen PV dom0 (regression, Linux 6.12)
Message-ID: <20250129133252.GA451735@bhelgaas>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <Z5mk0K5xltK6iZXN@mail-itl>

On Wed, Jan 29, 2025 at 04:47:28AM +0100, Marek Marczykowski-Górecki wrote:
> On Tue, Jan 28, 2025 at 09:40:18PM -0600, Bjorn Helgaas wrote:
> > I guess the code at [2] is running in user mode and uses Linux
> > syscalls for config access?  Is it straceable?
> 
> Nope, it's running as the hypervisor and mediates Linux's access to the
> hardware. In fact, Linux PV kernel (which dom0 is by default under Xen)
> is running in ring 3...
> 
> But I can add some more logging there.

So I guess the hypervisor performs the config access on behalf of the
Linux PV kernel?  Obviously Linux thinks CRS/RRS SV is enabled, but I
suppose all the lspci output is similarly based on whatever the
hypervisor does, so how do we know the actual hardware config?

> > > [2] https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/pv/emul-priv-op.c;h=70150c27227661baa253af8693ff00f2ab640a98;hb=HEAD#l295


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 13:52:51 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 13:52:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879169.1289387 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td8Uh-0000z9-CU; Wed, 29 Jan 2025 13:52:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879169.1289387; Wed, 29 Jan 2025 13:52:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td8Uh-0000z2-8O; Wed, 29 Jan 2025 13:52:39 +0000
Received: by outflank-mailman (input) for mailman id 879169;
 Wed, 29 Jan 2025 13:52: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 <SRS0=1peA=UV=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1td8Uf-0000yw-Un
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 13:52:37 +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 4b6375e7-de48-11ef-a0e6-8be0dac302b0;
 Wed, 29 Jan 2025 14:52:36 +0100 (CET)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-5db689a87cbso13474134a12.3
 for <xen-devel@lists.xenproject.org>; Wed, 29 Jan 2025 05:52:35 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab6760b76acsm975243866b.113.2025.01.29.05.52.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 29 Jan 2025 05:52:34 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 4b6375e7-de48-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738158755; x=1738763555; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=8eKaDXN8nT3fRF/O7B9dAo9AcUGAfO6x7aOxDrfogQM=;
        b=N2MS66/eNBF25Gwc3el3bDG+dWwUyjrKZ96QnOlQxEMAyvi94BdFkDePqI7s8vbKTP
         KUNMXdgEsz4a9sCe3cpz8NUeUZ3vMYvjSX7SLx0AmhziToTNXIlr4AtGPIu45Dzr7LeO
         me5J8qP2bGc6uak54/xrwDxe6eaU5UCum3wiS3O4DpXHQbMSX0ILyiHOf3Z2W/chdY/o
         klCY/QwegoLTRocBoL6FLAN12sX8a6vRNKQ5t2+7+vq1X/Zspix5QZNp5vpLgbqNnz6s
         mg/tvPAkVY0ufhsQx03UKgz2Zm/V2R6TEmbVoVR5MrN9fkxAyP/4k+oDpfN7yKCZcwh7
         4fMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738158755; x=1738763555;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=8eKaDXN8nT3fRF/O7B9dAo9AcUGAfO6x7aOxDrfogQM=;
        b=UqycMrmSKtqSU/67FTchi+j0wPwKVdZtHUgaaYwsvJoJNt9QVv46CvVAqbWFU/crae
         uymgzzzEptWKejyPMl4BiN2DvgjXodKAuLBVPmtTrcrTU1G7yDakqvQRKFYPq0Ynfoq6
         B2fjLHhd6btlWin1gMbz0VYhYoUt2eDgZlC7dvlpOZHyaqadezHZLzEKnHe2j4s+i3jE
         s/l8FG3fdOcq81V2R0MvgIjeBr2/jR2q7UitQ/HF9p5P6VgYNEY8TTwVbEE7TOGu5MF8
         1E2xNxnSD2KUa4KGWJgDifEMvRK+q1B/DWQ/f3OHSJiDoBiWfD9hKcZazJkMlVvW06wc
         JT+A==
X-Forwarded-Encrypted: i=1; AJvYcCVL2Pq6VXU0FbYLHZzxk3Fc3P7Ht3CDRp6/66zAIqPf0oFj3BSisFVFJKzp8g+JPcTZh7RtqkQPVfc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxBhsC12dlM8uanZl1/OLrHywDY+dL5KNyW867233iLysghFmHS
	M6XTOdpfmnHMJyYP7FXhw392VeVpwwB/Yu5A5ePE8BUH+OwleEC6w/Lx72VoAGIwWjoavAJmuyU
	=
X-Gm-Gg: ASbGncskPUykFAHEQFaQRCuLVqE8LsWx7wYmkcn9yRlOPCidkjF+CgMYSSfsXmY0wTk
	32+j1DiBso4puiB9RGs0ghXZhhHhp2VYWQnPHo47SDtHI7pj8BSntP+QAOc4cT1eX5VgkCWKld5
	mPlIEZ1bJzU/6CC9cBgKwev6meJcLPvod8bdSUQRLW5+UEsCE04oXkqniP42/G7pXb9HzpkvuB1
	hIX7/aHHCC3h2cXNyCLsug+Qs5FNnmxa7SBINc2+ahOr6Btc4SDtGv2SnCXTS2S4hlMYUF4/634
	jah2jFMC3Ewx6DKemmciIlXonFLIdNSNOWMwTuB/3keT/+YMPk0LIHUBBqOFM4y8gZEAtHpTqIh
	L
X-Google-Smtp-Source: AGHT+IHcgMv7g287Jp7sQNzuwSuVOp0aN6zu3mmbpSWX1c3/xC3MYcqnhyGJQi8cda92/TBxiW4uDQ==
X-Received: by 2002:a17:907:2d0c:b0:aa6:995d:9ef1 with SMTP id a640c23a62f3a-ab6cfcb39e9mr349160266b.12.1738158754501;
        Wed, 29 Jan 2025 05:52:34 -0800 (PST)
Message-ID: <841e1793-4635-4f06-b0c9-37530215c08b@suse.com>
Date: Wed, 29 Jan 2025 14:52:33 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Config space access to Mediatek MT7922 doesn't work after device
 reset in Xen PV dom0 (regression, Linux 6.12)
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>, =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?=
 <jgross@suse.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 xen-devel <xen-devel@lists.xenproject.org>, linux-kernel@vger.kernel.org,
 regressions@lists.linux.dev, Felix Fietkau <nbd@nbd.name>,
 Lorenzo Bianconi <lorenzo@kernel.org>, Ryder Lee <ryder.lee@mediatek.com>,
 linux-pci@vger.kernel.org,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
References: <20250129133252.GA451735@bhelgaas>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250129133252.GA451735@bhelgaas>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 29.01.2025 14:32, Bjorn Helgaas wrote:
> On Wed, Jan 29, 2025 at 04:47:28AM +0100, Marek Marczykowski-Górecki wrote:
>> On Tue, Jan 28, 2025 at 09:40:18PM -0600, Bjorn Helgaas wrote:
>>> I guess the code at [2] is running in user mode and uses Linux
>>> syscalls for config access?  Is it straceable?
>>
>> Nope, it's running as the hypervisor and mediates Linux's access to the
>> hardware. In fact, Linux PV kernel (which dom0 is by default under Xen)
>> is running in ring 3...
>>
>> But I can add some more logging there.
> 
> So I guess the hypervisor performs the config access on behalf of the
> Linux PV kernel?  Obviously Linux thinks CRS/RRS SV is enabled, but I
> suppose all the lspci output is similarly based on whatever the
> hypervisor does, so how do we know the actual hardware config?

The hypervisor only intercepts config space writes; reads, particularly
when going via mmcfg, ought to be unaffected, and hence what lspci shows
should be "the actual hardware config".

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 13:54:46 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 13:54:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879176.1289396 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td8Wj-0001Wx-MI; Wed, 29 Jan 2025 13:54:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879176.1289396; Wed, 29 Jan 2025 13:54:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td8Wj-0001Wq-JN; Wed, 29 Jan 2025 13:54:45 +0000
Received: by outflank-mailman (input) for mailman id 879176;
 Wed, 29 Jan 2025 13:54:44 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=1peA=UV=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1td8Wi-0001Wi-36
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 13:54:44 +0000
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com
 [2a00:1450:4864:20::62a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 97357279-de48-11ef-a0e6-8be0dac302b0;
 Wed, 29 Jan 2025 14:54:43 +0100 (CET)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-aab925654d9so1327152766b.2
 for <xen-devel@lists.xenproject.org>; Wed, 29 Jan 2025 05:54:43 -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
 a640c23a62f3a-ab6760fbb2esm985639866b.140.2025.01.29.05.54.41
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 29 Jan 2025 05:54:42 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 97357279-de48-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738158882; x=1738763682; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=OAzk2HvSci2RB9DJCTTtog02Zihvy8J06+hb0uPWlXE=;
        b=CVbVVw8ArfsSUBiWg1+DUyM4KQdasExtnUs3gpyyTMgWcLoo2XgcCFoRd70ozeUU6O
         Wm6UthNLpFvrZVUNxlYpI0h9X7gkmeHJraLZ6BlMebhOIRiL6I/0xGkVZowW23Uy4Yfo
         jNSYjtf5HF1K8kLzpu8P6MlB4/IrNFKR08SewOHJNJGoZxWRFyHternt8ri43iajWp6n
         yH5Gwpa8JniqOGFuIcWtFTH+wnUW+N+40T0WDmziaESc0cWcinjIHzmwycRqRvjVW49T
         ArAYfv90DLyYSbB9opcBrD8fCeKzCWcAf60CsUpb3NVFZrEofQ9u0dqww2A9C5vzPpzK
         RyPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738158882; x=1738763682;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=OAzk2HvSci2RB9DJCTTtog02Zihvy8J06+hb0uPWlXE=;
        b=il0Se66qE4Te2Amqc1hBKM38oZoOUaSoGXf9ocAx1YBpDberbP3ziCoKf6mgSPfFnr
         ZfWmi5Lm09miO3HHT6UpRurxmyjXEGo2JQXJ63QXJ67InnBRCctjCb+luZ7eDRbIVnKv
         HudlUV0GcpY9858aI9TgUWwa5QZCeC4J6IoqJqQGXvL95uGj2WaOWKOuhDOsdK4WjVxv
         mgOxbilrsi5kRfALC3UOX266TXjntWmXsDDQaNyDGDiXtWjSdi/Q7GQgFoQ4rZanKIWO
         ZG2R9utAI+bHOBoeaqPq7I34NQtDModjVyREVxMNiQK7tylWPWGiDgPbskO6Ps5ifuuS
         mauw==
X-Forwarded-Encrypted: i=1; AJvYcCVQlY7c4Onjty81Goa1jjxxowfaZIAICsoq2ZdWq9UlXkuLXNYuIdjVZfdlUUADb0o5x8o8xefv0/E=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy7T6YXtNkhMobHOYjVOQw7gOcaID1ujESL3C7NN+R7FMD/+QE2
	6+D37UBAC4K1qhhDBA5BemqTIVyVpyyOBpCwSfaov89ist3wfdPkoUg2JcxDOQ==
X-Gm-Gg: ASbGnct3pCOaybED/q+rtty4Gnp/UvJ3hvkgf0qoMuVv3gH4yOTBSfDMbwMI2nnBw+9
	JUl3FDAK7fbWYayXldhAFmHAyRBJO+/HrVfqnEO9ynICC+jnAoUyYXIw4pUAES9JzZbE6gvnCf6
	Dcp3YxQyVtnfYzfrQ1r35gz3StWClKCHWfD9+otfv1IN2EmAX9wfEIGnDVUYLcH9VWQPkvCiY9Y
	8t9EEiciHLV16CjTVxJQh9fI40Ob6EtlcUATiuHsQq/xFHUZNQxhZstl/09rWvTR7aak3cdgn7S
	RNsTqRe1f+EpU5GLky9TICE9uVIgetYt4YD/r2rT37LXeX0xEJCafOyuUr8y+ocPlxqo1SvYR7Z
	OX3c3LTWrnPA=
X-Google-Smtp-Source: AGHT+IFyfwTg1PMxVWwmOGjd5ZetF6IndRyOwzliuiWStKYzttmQsbLKfxXAr/xuK9TPm1p1YNzOiA==
X-Received: by 2002:a17:907:7b85:b0:aa6:81dc:6638 with SMTP id a640c23a62f3a-ab6cfcbb881mr280647966b.16.1738158882265;
        Wed, 29 Jan 2025 05:54:42 -0800 (PST)
Message-ID: <8acfd9b2-caae-4fe7-8d37-19e2d9be23a8@suse.com>
Date: Wed, 29 Jan 2025 14:54:41 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Config space access to Mediatek MT7922 doesn't work after device
 reset in Xen PV dom0 (regression, Linux 6.12)
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, Bjorn Helgaas <bhelgaas@google.com>,
 =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 xen-devel <xen-devel@lists.xenproject.org>, linux-kernel@vger.kernel.org,
 regressions@lists.linux.dev, Felix Fietkau <nbd@nbd.name>,
 Lorenzo Bianconi <lorenzo@kernel.org>, Ryder Lee <ryder.lee@mediatek.com>,
 linux-pci@vger.kernel.org
References: <20250129132843.GA451331@bhelgaas>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250129132843.GA451331@bhelgaas>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 29.01.2025 14:28, Bjorn Helgaas wrote:
> On Wed, Jan 29, 2025 at 10:17:20AM +0100, Jan Beulich wrote:
>> On 29.01.2025 04:22, Marek Marczykowski-Górecki wrote:
>>> On Tue, Jan 28, 2025 at 09:03:15PM -0600, Bjorn Helgaas wrote:
>>>> The report claims the problem only happens with Xen.  I'm not a Xen
>>>> person, and I don't know how to find the relevant config accessors.
>>>> The snippets of kernel messages I see at [1] all mention pciback, so
>>>> that's my only clue of where to look.  Bottom line, I have no idea
>>>> what the config accessor path is, and maybe we could learn something
>>>> by looking at whatever it is.
>>>
>>> AFAIK there are no separate config accessors under Xen dom0, the default
>>> ones are used. xen-pcifront takes over PCI config space access (and few
>>> more) only in a domU (and only for PV), when PCI passthrough is used.
>>> Here, it didn't went that far...
>>>
>>> But then, Xen may intercept such access [2]. If I read it right, it
>>> should allow all access (is_hardware_domain(dom0)==true, and also the
>>> device is not on ro_map - otherwise reset wouldn't work at all).
>>
>> The other day you mentioned (on Matrix I think) that you observe mmcfg
>> not being used on that system. Am I misremembering? (Since the capability
>> where the control bit lives is an extended one, that capability would
>> neither be read nor modified when mmcfg is unavailable.)
> 
> If you're referring to the Configuration RRS Software Visibility
> Enable bit, that's in the PCIe Capability Root Control register, which
> is in the PCI-compatible config space (the first 256 bytes), not the
> extended config space.

Oh, I clearly didn't read Marek's earlier mail correctly. I'm sorry for that.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 14:01:46 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 14:01:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879185.1289405 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td8dS-0003CL-BL; Wed, 29 Jan 2025 14:01:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879185.1289405; Wed, 29 Jan 2025 14:01:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td8dS-0003CE-8L; Wed, 29 Jan 2025 14:01:42 +0000
Received: by outflank-mailman (input) for mailman id 879185;
 Wed, 29 Jan 2025 14:01:41 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=1peA=UV=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1td8dR-0003C8-7G
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 14:01:41 +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 8fe23039-de49-11ef-a0e6-8be0dac302b0;
 Wed, 29 Jan 2025 15:01:40 +0100 (CET)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-aaecf50578eso704098566b.2
 for <xen-devel@lists.xenproject.org>; Wed, 29 Jan 2025 06:01:40 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab6760b76acsm976540766b.113.2025.01.29.06.01.36
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 29 Jan 2025 06:01:37 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8fe23039-de49-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738159299; x=1738764099; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=bWmxuIdDcUoGMoSCDd043vF/xmOKbmsmzZnKmZep0yE=;
        b=S2VXqnC4bm5k3psKG77Dpq4P8X/HeV7MKB2SVss2qAmI6yjgIe1rGJFLyFzP/rTcyF
         F7V7NF+ydWtJq8MYHa/coMdmy4YCslVNKn260tred+kPDrq5X6GCnR1Z/ivryAUszUGx
         AN2wIZuJLkFWViepn6D0IxzVgieS/6LaoOOjLLdQFKGBDULeiGasS/yjcjW0QtHjHDVk
         5DyfsYNyNIvDtdcWos2Iiv99bpcySR7Bj7JVrgUWSt8lpta5eMjtt7OTCj7LxyVD3nPd
         ZH4upO2rYoAphfhtOtzRUHoOPjCQVErHtCTCtMdZoJDit/8v8HIKILHNH+rm86Xhdry6
         Cj9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738159299; x=1738764099;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=bWmxuIdDcUoGMoSCDd043vF/xmOKbmsmzZnKmZep0yE=;
        b=COJwVNzQ16eM6oYzFGdBP18IPrCq03nlCQCvNtbU9xt1v9WNyzyAauGOncenILfMTm
         5Iw92DvL7BRvG72UDC8buXgxwzD0sB7xSRxfZLaRZxDO1NzpP/1S9Wv2ZHpW7vqvv+/5
         faV6DiQP+ZbRKSvb1F79ThrYtl3aXZnHLkFNn+o2tnygWjejXQoPtbdp42NtudsqkYAP
         /QKwz4gHGVtsmHTo/Al/y2qygSNUjyecRVnZwSH8t/sH3RZU93sPuJcTQqDOAqkZUTaA
         BfGJIlfhh4FiPlP9fPibMPbHyTgIsbjpL0yRjCMbZbP1LzpC/Qp2T0HIZl2AW8YPZF+y
         cCuw==
X-Forwarded-Encrypted: i=1; AJvYcCXR8Dkd38oymcAzlOqscftoQLp0WgL85RLZXa7QigChYB5/o351eqEvociXMK9dev77JUfcfGkucvc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyMXJUtghcYAAduU0L5EW9siWx3CbekNzxkO8AbHc54qeJybFfj
	T/xBbviKt7CCGtKbJKq8I03NB2SlbiSlbSUA7rmbMQZcEFZm0H7n/UW6bXI5Bw==
X-Gm-Gg: ASbGncsXgMclAU0l2eZBaNAj+s3ITbKKzgr2V9zRTS7ywzTvm5vlCRRP+OhnAVZRpQk
	m2b5L/YqbpR9jaV++/5/tuzQf98SpisrfCtOJ3llv4bSNonpoW4NNPYcAok1zU3COQ0Nar5LOzc
	CHn8cA6fv5CyFcSHtCBaTa7s7XoZnY8P5BLP9LHInfEHrtVwiFzdDfvsydDcFGIjFXaYj2nvdEU
	o3J3+6ikoRfDpygkdH0Ecb35kmzt3vQ4YHx9A+47Jv2eJWv+1qbpfqmyMcQb3eSi+06R50UILle
	75PzpRh9G5sDxeN8u8NjRGH0AQdlqoxecKZc5YvISbCLeMQkLjtzSOlQ4JiGXkPF9VV5t1glWAN
	w7ovSOyIhsrQ=
X-Google-Smtp-Source: AGHT+IFb++oHrFIUDn02dTnsu3LizHnJ8Dcflz/4Dogd8gpQS68rYNA0+sKcikF1jg7eoti8SClVsA==
X-Received: by 2002:a17:907:9719:b0:aae:85a9:e2d with SMTP id a640c23a62f3a-ab6cfdd6dccmr302769466b.45.1738159297862;
        Wed, 29 Jan 2025 06:01:37 -0800 (PST)
Message-ID: <47fb2f0f-fb75-4343-8f7c-cf8b27857d67@suse.com>
Date: Wed, 29 Jan 2025 15:01:36 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 1/3] xen/riscv: implement software page table walking
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Alistair Francis <alistair.francis@wdc.com>,
 Bob Eshleman <bobbyeshleman@gmail.com>, Connor Davis
 <connojdavis@gmail.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1737391102.git.oleksii.kurochko@gmail.com>
 <00dfc71569bc9971b53e29b36a80e9e020ac61ac.1737391102.git.oleksii.kurochko@gmail.com>
 <21bfd2f5-74b8-409e-956c-dd736a3c0be2@suse.com>
 <e2290a2a-a3c0-4cfe-b9e9-8cfec0b194a8@gmail.com>
 <a304e4f0-709f-4fcd-9847-01fe6ab4b98c@suse.com>
 <d9ca4252-1bf0-4257-ad6b-e91240cc5de3@gmail.com>
 <dfe0c6c5-db4a-4e27-9963-fe1b0c2bf629@suse.com>
 <c602d580-8d62-4fa9-9aa4-37fbd6201fa3@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <c602d580-8d62-4fa9-9aa4-37fbd6201fa3@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 29.01.2025 14:12, Oleksii Kurochko wrote:
> 
> On 1/28/25 9:14 AM, Jan Beulich wrote:
>> On 27.01.2025 18:22, Oleksii Kurochko wrote:
>>> On 1/27/25 1:57 PM, Jan Beulich wrote:
>>>> On 27.01.2025 13:29, Oleksii Kurochko wrote:
>>>>> On 1/27/25 11:06 AM, Jan Beulich wrote:
>>>>>> On 20.01.2025 17:54, Oleksii Kurochko wrote:
>>>>>>> RISC-V doesn't have hardware feature to ask MMU to translate
>>>>>>> virtual address to physical address ( like Arm has, for example ),
>>>>>>> so software page table walking in implemented.
>>>>>>>
>>>>>>> Signed-off-by: Oleksii Kurochko<oleksii.kurochko@gmail.com>
>>>>>>> ---
>>>>>>>     xen/arch/riscv/include/asm/mm.h |  2 ++
>>>>>>>     xen/arch/riscv/pt.c             | 56 +++++++++++++++++++++++++++++++++
>>>>>>>     2 files changed, 58 insertions(+)
>>>>>>>
>>>>>>> diff --git a/xen/arch/riscv/include/asm/mm.h b/xen/arch/riscv/include/asm/mm.h
>>>>>>> index 292aa48fc1..d46018c132 100644
>>>>>>> --- a/xen/arch/riscv/include/asm/mm.h
>>>>>>> +++ b/xen/arch/riscv/include/asm/mm.h
>>>>>>> @@ -15,6 +15,8 @@
>>>>>>>     
>>>>>>>     extern vaddr_t directmap_virt_start;
>>>>>>>     
>>>>>>> +paddr_t pt_walk(vaddr_t va);
>>>>>> In the longer run, is returning just the PA really going to be sufficient?
>>>>>> If not, perhaps say a word on the limitation in the description.
>>>>> In the long run, this function's prototype looks like|paddr_t pt_walk(vaddr_t root, vaddr_t va, bool is_xen)| [1]. However, I'm not sure if it will stay that way,
>>>>> as I think|is_xen| could be skipped, since using|map_table()| should be sufficient (as it now considers|system_state|) and I'm not really sure if I need root argument
>>>>> as initial goal was to use this function for debug only purposes and I've never used it for guest page table (stage-1) walking.
>>>>> Anyway, yes, it is still returning a physical address, and that seems enough to me.
>>>>>
>>>>> Could you share your thoughts on what I should take into account for returning value, probably, I am missing something really useful?
>>>> Often you care about the permissions as well. Sometimes it may even be relevant
>>>> to know the (super-)page size of the mapping.
>>> Perhaps it would be better to change the prototype to:
>>>     bool pt_walk(vaddr_t va, mfn_t *ret_pa);
>>> or even
>>>     void pt_walk(vaddr_t va, mfn_t *ret_pa);
>>>     In this case,|ret_pa = INVALID_MFN| could serve as a signal that|pt_walk()| failed.
>>> If there's a need to return permissions or (super-)page size in the future, another argument could be added.
>>>
>>> What do you think? Would this approach be better?
>>>
>>> I am also considering returning a structure containing the|mfn| (or|paddr_t|) and adding other properties (such as permissions or
>>> page size) as needed in the future. Both solutions seem more or less equivalent.
>> Imo the most natural thing for a page walking function would be to return the
>> leaf PTE (or the leaf-most not-present [or otherwise "no-access"] one). That
>> would provide (almost) all possible information to the caller. "Almost"
>> because depending on how page walk works, permissions may combine across page
>> table levels. Yet then (see also the "no-access" above) this would also
>> require further input, to specify the context for which the translation is
>> being seeked. For example, the intention to write may want to yield no valid
>> PTE when there are present ones down to the leaf, but effective permissions
>> say "read-only".
> 
> Perhaps returning the leaf PTE could be a really good option.
> 
> I'm not entirely sure I understand what you mean by "leaf-most not-present". Could you please try to explain this moment one more time?
> My expectation was that the function should return an existing leaf PTE (from which "access" rights could be determined)
> or|NULL| to indicate that no leaf PTE was found.

"no leaf PTE" may be for a variety of reasons. Hence why I think returning
the PTE at which the walk stopped (leaf or leaf-most not-present) is likely
best. Such a not-present PTE may, after all, still contain valuable
information; it's not like it has to be all zero.

> Another thing I'm curious about is whether this would be sufficient for determining the level.
> It seems clear that, given a PTE and a virtual address, we could compute:
> |mask = VA | paddr_from_pte(pte)|

What would this value represent? No, from holding a PTE in your hands you
can't determine the level it came from. So yes, ...

> Then, iterating through each level, we could apply and understand on which one level it was mapped:
> |mask & (BIT(XEN_PT_LEVEL_ORDER(i), UL) - 1)|.
> 
> If I haven't overlooked any other way to calculate the page table level, would it be better to simply add another argument
> to|pt_walk()| to return the level.

... for callers who care doing this might then be necessary (this would be
a pointer parameter, and since I expect many callers wouldn't care about
the level, it likely wants to be permissible to pass in NULL).

Question then is whether it's better to hand back the level or the page
order of the mapping. On x86 we return the latter from P2M lookups, for
example.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 14:50:35 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 14:50:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879195.1289417 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td9Oe-0001G6-SM; Wed, 29 Jan 2025 14:50:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879195.1289417; Wed, 29 Jan 2025 14:50:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1td9Oe-0001Fz-Nn; Wed, 29 Jan 2025 14:50:28 +0000
Received: by outflank-mailman (input) for mailman id 879195;
 Wed, 29 Jan 2025 14:50:26 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=CGF7=UV=kernel.org=helgaas@srs-se1.protection.inumbo.net>)
 id 1td9Oc-0001Fr-Nz
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 14:50:26 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5e811a94-de50-11ef-99a4-01e77a169b0f;
 Wed, 29 Jan 2025 15:50:24 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id C77AC5C5D56;
 Wed, 29 Jan 2025 14:49:42 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6AA68C4CED1;
 Wed, 29 Jan 2025 14:50:22 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 5e811a94-de50-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1738162222;
	bh=Yulc6gJaTzGVoS9ctTWsVTmw0HAG9Y+R9cKgd4fepeQ=;
	h=Date:From:To:Cc:Subject:In-Reply-To:From;
	b=OjJriJO65H3ftNFlkfAjt2ManhpLdvdPy3FlOlQ4vyK0XIdBe47wDizeToGtuHSiF
	 7LFWxyVWq9wGi/VsxMyoaZXkRTPtsXlcE8V0HrM7S9709NJM07bP6/aOtBBclwwBr3
	 FGnSwDrNI4TW7cFrnVH5gImtdBKqXdVkQaJXEcjNOyftS4Mjh4kCY9qy2yFv+zYq6u
	 DFqUwR3UBBFzu9ZLwhmFlMAzdCe8MOi//Amfhhkn/2uOJ9OPpl+GrFqyflBRjnURLb
	 7BBxtn4QMCUHmrOvgO/zBA8bGyf0SgzhC94Qm3rDdlHK86R6ExitPGSEsRqsa10Sa9
	 sgX1jF/eyk0kQ==
Date: Wed, 29 Jan 2025 08:50:19 -0600
From: Bjorn Helgaas <helgaas@kernel.org>
To: Jan Beulich <jbeulich@suse.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	=?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	linux-kernel@vger.kernel.org, regressions@lists.linux.dev,
	Felix Fietkau <nbd@nbd.name>, Lorenzo Bianconi <lorenzo@kernel.org>,
	Ryder Lee <ryder.lee@mediatek.com>, linux-pci@vger.kernel.org,
	Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
Subject: Re: Config space access to Mediatek MT7922 doesn't work after device
 reset in Xen PV dom0 (regression, Linux 6.12)
Message-ID: <20250129145019.GA459546@bhelgaas>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <841e1793-4635-4f06-b0c9-37530215c08b@suse.com>

On Wed, Jan 29, 2025 at 02:52:33PM +0100, Jan Beulich wrote:
> On 29.01.2025 14:32, Bjorn Helgaas wrote:
> > On Wed, Jan 29, 2025 at 04:47:28AM +0100, Marek Marczykowski-Górecki wrote:
> >> On Tue, Jan 28, 2025 at 09:40:18PM -0600, Bjorn Helgaas wrote:
> >>> I guess the code at [2] is running in user mode and uses Linux
> >>> syscalls for config access?  Is it straceable?
> >>
> >> Nope, it's running as the hypervisor and mediates Linux's access to the
> >> hardware. In fact, Linux PV kernel (which dom0 is by default under Xen)
> >> is running in ring 3...
> >>
> >> But I can add some more logging there.
> > 
> > So I guess the hypervisor performs the config access on behalf of the
> > Linux PV kernel?  Obviously Linux thinks CRS/RRS SV is enabled, but I
> > suppose all the lspci output is similarly based on whatever the
> > hypervisor does, so how do we know the actual hardware config?
> 
> The hypervisor only intercepts config space writes; reads, particularly
> when going via mmcfg, ought to be unaffected, and hence what lspci shows
> should be "the actual hardware config".

FWIW, on x86, the first 256 bytes of config space for domain 0 uses
raw_pci_ops even when mmcfg is available (see raw_pci_read()).  This
normally means IO ports 0xcf8/0xcfc.


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 15:33:41 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 15:33:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879207.1289426 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdA4F-0006pO-46; Wed, 29 Jan 2025 15:33:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879207.1289426; Wed, 29 Jan 2025 15:33:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdA4F-0006pH-0J; Wed, 29 Jan 2025 15:33:27 +0000
Received: by outflank-mailman (input) for mailman id 879207;
 Wed, 29 Jan 2025 15:33:26 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=lGVs=UV=gmail.com=julien.grall.oss@srs-se1.protection.inumbo.net>)
 id 1tdA4E-0006oQ-2Y
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 15:33:26 +0000
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com
 [2a00:1450:4864:20::332])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 60582cfb-de56-11ef-a0e6-8be0dac302b0;
 Wed, 29 Jan 2025 16:33:24 +0100 (CET)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-436345cc17bso50738805e9.0
 for <xen-devel@lists.xenproject.org>; Wed, 29 Jan 2025 07:33:23 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 60582cfb-de56-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1738164803; x=1738769603; 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=7ozyR5rYO3UM8Xpf+WbwbVauvZHmYNlQD8ZmfWR8sTI=;
        b=O2MKuBhvJJGBDszeKziDRXeQSk2229bASF1gopxMFpC7T65cREZl+sv8xU6Z35S6IL
         qC7x4fRfXg28kNOSCnyYnzr/4IOutrprX6Mgmj94+QSggTZ1FF+F5ROEdY+6qjqNJJNt
         OIrH3w3ng+iI7shDSUpm9aabSghI3U/xvDksN//L5Na2KP3/jwB2Cs9EJ4BGzpp2eGTc
         77ulRu1IMtjJQhCPm8i3h+IvgXSS3LIEvkq2gX5YeebZz+Vt4dtirpDZN0N8N28aZ/7U
         3z1cKIiGw8+JH38aTNBD287S/vjxFR0phL8Cj3rBSNkcbukd/ZV9k7xOEJDbMeJqtZFN
         n87w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738164803; x=1738769603;
        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=7ozyR5rYO3UM8Xpf+WbwbVauvZHmYNlQD8ZmfWR8sTI=;
        b=VVsLZul7i8GxDbwgbxzb2INPaybGyi0zG+XXnQgBboabLI1wavp0HlnIrbpOQ93M+u
         HsunhYEyAW8hoVRYWQpPTTVVshEO3sKxTQEMyb8W9w3nwELQQFXHRkIto/nIbIpLtJMo
         M4YwW7llayzxASUe2zuMyrooFGt7MfEOnJ685DryqKf2qNiIEt0FB0DbvtIQPriUaKCR
         4ZAmGiN39Trt6wQ9RqPs6gLnX3sgmi6RK+d7MdG+6vLeqON+c/zYr0L5P0Rno4PC4Kov
         iPHFGXlB2+hU6ZO/6jQNHqJygDJkbrQpXQCSI1BEpkMaCCf2H0upUwJjvco4S5Drl82R
         u5Cg==
X-Gm-Message-State: AOJu0YwG2urPALYf1HiYYYeTyGPty5ykVXrsubxS1Gcjyl2GFSzd4Vww
	XJCeibx7evYTysXTs7sZ+PwAJJCmjbqDHdhf0eLiwsG3GvgMaQmNKJt6RUR6POiGd02wAxeA5JK
	Rs0zYXDDHtkBL/iUjTZ83alH+cF8=
X-Gm-Gg: ASbGnctNYqudsKO9uSCtlO2ZWmf5MbB3VzD3omybp2PkCRPXbA9COITP4X1E/KR19sK
	FI2xWouKgNVE+y54+tc5+6CY4RyThrkbUi63e76JU7iRDVUf2U94NDOu1gynxR3OyQ/FMuMA=
X-Google-Smtp-Source: AGHT+IHrduHzLf7wTGckZY9XGvGJmoOUtCQJn4bhhJkNXz3tKE2FYgEhvoAhzFcnHqP8ONEGY0N9uW3FfskG328/UMM=
X-Received: by 2002:a05:600c:1d1e:b0:434:f623:9ff3 with SMTP id
 5b1f17b1804b1-438dc3caaf4mr34666605e9.15.1738164802940; Wed, 29 Jan 2025
 07:33:22 -0800 (PST)
MIME-Version: 1.0
References: <20250114195010.3409094-1-ayan.kumar.halder@amd.com> <20250114195010.3409094-2-ayan.kumar.halder@amd.com>
In-Reply-To: <20250114195010.3409094-2-ayan.kumar.halder@amd.com>
From: Julien Grall <julien.grall.oss@gmail.com>
Date: Wed, 29 Jan 2025 12:33:10 -0300
X-Gm-Features: AWEUYZl8Xk5mXk0DVTE9PVwKqnuaqc6dOqIgefWuLRmiNQgsPapxHFF2HsqIRNE
Message-ID: <CAJ=z9a1ynFU86ac=1Q7i=xSNh2bjnZJ3+tPjsjWvfw7294n_NA@mail.gmail.com>
Subject: Re: [PATCH v1 2/2] docs: fusa: Add the requirements for some of the
 commands of XEN_VERSION
To: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Cc: xen-devel@lists.xenproject.org, 
	Stefano Stabellini <sstabellini@kernel.org>, Bertrand Marquis <bertrand.marquis@arm.com>, 
	Michal Orzel <michal.orzel@amd.com>, Artem Mygaiev <artem_mygaiev@epam.com>
Content-Type: multipart/alternative; boundary="000000000000a3f754062cda0721"

--000000000000a3f754062cda0721
Content-Type: text/plain; charset="UTF-8"

Hi,

On Tue, 14 Jan 2025 at 16:50, Ayan Kumar Halder <ayan.kumar.halder@amd.com>
wrote:

> We have written the requirements for some of the commands of the
> XEN_VERSION
> hypercall.
>
> Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
> ---
>  .../design-reqs/arm64/version_hypercall.rst   | 33 ++++++++
>  .../reqs/design-reqs/version_hypercall.rst    | 65 +++++++++++++++
>  docs/fusa/reqs/index.rst                      |  2 +
>  .../reqs/product-reqs/version_hypercall.rst   | 82 +++++++++++++++++++
>  4 files changed, 182 insertions(+)
>  create mode 100644 docs/fusa/reqs/design-reqs/arm64/version_hypercall.rst
>  create mode 100644 docs/fusa/reqs/design-reqs/version_hypercall.rst
>
> diff --git a/docs/fusa/reqs/design-reqs/arm64/version_hypercall.rst
> b/docs/fusa/reqs/design-reqs/arm64/version_hypercall.rst
> new file mode 100644
> index 0000000000..1dad2b84c2
> --- /dev/null
> +++ b/docs/fusa/reqs/design-reqs/arm64/version_hypercall.rst
> @@ -0,0 +1,33 @@
> +.. SPDX-License-Identifier: CC-BY-4.0
> +
> +Capabilities
> +------------
> +
> +`XenSwdgn~arm64_capabilities~1`
> +
> +Description:
> +Xen shall have a internal constant string storing "xen-3.0-aarch64".


Can you explain why we need to specify how Xen is storing the string? At
least to me this feels a bit overkill. What matters is what/how the VM is
seen.


> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenProd~version_hyp_capabilities_cmd~1`
> +
> +Capabilities AArch32
> +--------------------
> +
> +`XenSwdgn~arm64_capabilities_aarch32~1`
> +
> +Description:
> +Xen shall have a internal constant string storing "xen-3.0-armv7l" when it
> +detects that the cpu is running in AArch32 mode.
> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenProd~version_hyp_capabilities_cmd~1`
> +
> diff --git a/docs/fusa/reqs/design-reqs/version_hypercall.rst
> b/docs/fusa/reqs/design-reqs/version_hypercall.rst
> new file mode 100644
> index 0000000000..8bb7a66576
> --- /dev/null
> +++ b/docs/fusa/reqs/design-reqs/version_hypercall.rst
> @@ -0,0 +1,65 @@
> +.. SPDX-License-Identifier: CC-BY-4.0
> +
> +Version
> +-------
> +
> +`XenSwdgn~version~1`
> +
> +Description:
> +Xen shall have a internal constant storing the version number coming from
> the
> +Makefile.
> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenProd~version_hyp_version_cmd~1`
> +
> +Subversion
> +----------
> +
> +`XenSwdgn~subversion~1`
> +
> +Description:
> +Xen shall have a internal constant storing the sub version number coming
> from
> +the Makefile.
> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenProd~version_hyp_version_cmd~1`
> +
> +Extraversion
> +------------
> +
> +`XenSwdgn~extraversion~1`
> +
> +Description:
> +Xen shall have a internal constant string storing the extraversion coming
> from
> +the build environment.
> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenProd~version_hyp_extraversion_cmd~1`
> +
> +Changeset
> +---------
> +
> +`XenSwdgn~changeset~1`
> +
> +Description:
> +Xen shall have a internal constant string storing the date, time and git
> hash
> +of the last change made to Xen's codebase.
> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenProd~version_hyp_changeset_cmd~1`
> diff --git a/docs/fusa/reqs/index.rst b/docs/fusa/reqs/index.rst
> index d8683edce7..b85af19d19 100644
> --- a/docs/fusa/reqs/index.rst
> +++ b/docs/fusa/reqs/index.rst
> @@ -14,3 +14,5 @@ Requirements documentation
>     design-reqs/arm64/generic-timer
>     design-reqs/arm64/sbsa-uart
>     design-reqs/arm64/hypercall
> +   design-reqs/arm64/version_hypercall
> +   design-reqs/version_hypercall
> diff --git a/docs/fusa/reqs/product-reqs/version_hypercall.rst
> b/docs/fusa/reqs/product-reqs/version_hypercall.rst
> index fdb8da04e1..10bc7b6e87 100644
> --- a/docs/fusa/reqs/product-reqs/version_hypercall.rst
> +++ b/docs/fusa/reqs/product-reqs/version_hypercall.rst
> @@ -59,3 +59,85 @@ Covers:
>  Needs:
>   - XenSwdgn
>
> +Version command
> +---------------
> +
> +`XenProd~version_hyp_version_cmd~1`
> +
> +Description:
> +Xen shall provide a command (num 0) for  hypercall (num 17) to retrieve
> Xen's
> +version in the domain's x0 register.


> +
> +Rationale:
> +
> +Comments:
> +Xen version is composed of major and minor number.
> +
> +Covers:
> + - `XenMkt~version_hypercall~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +Extraversion command
> +--------------------
> +
> +`XenProd~version_hyp_extraversion_cmd~1`
> +
> +Description:
> +Xen shall provide a command (num 1) for hypercall (num 17) to copy its
> +extraversion in the domain's buffer.


> +
> +Rationale:
> +
> +Comments:
> +Xen's extra version consists of a string passed with 'XEN_VENDORVERSION'
> command
> +line parameter while building Xen.


Not really. It returns a truncated version if it is too large. You likely
want to describe command 11.



> +
> +Covers:
> + - `XenMkt~version_hypercall~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +Capabilities command
> +--------------------
> +
> +`XenProd~version_hyp_capabilities_cmd~1`
> +
> +Description:
> +Xen shall provide a command (num 3) for hypercall (num 17) to copy its
> +capabilities to the domain's buffer.
> +
> +Rationale:
> +
> +Comments:
> +Capabilities related information is represented by char[1024].
> +For Arm64, the capabilities should contain "xen-3.0-aarch64" string.
> +
> +Covers:
> + - `XenMkt~version_hypercall~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +Changeset command
> +-----------------
> +
> +`XenProd~version_hyp_changeset_cmd~1`
> +
> +Description:
> +Xen shall provide a command (num 4) for hypercall (num 17) to copy
> changeset
> +to the domain's buffer.
> +
> +Rationale:
> +
> +Comments:
> +Changeset is string denoting the date, time and git hash of the last
> change
> +made to Xen's codebase.
> +
> +Covers:
> + - `XenMkt~version_hypercall~1`
> +
> +Needs:
> + - XenSwdgn
> --
> 2.25.1
>
>
>

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

<div dir=3D"auto">Hi,</div><div dir=3D"auto"><br></div><div dir=3D"auto"><d=
iv class=3D"gmail_quote gmail_quote_container" dir=3D"auto"><div dir=3D"ltr=
" class=3D"gmail_attr">On Tue, 14 Jan 2025 at 16:50, Ayan Kumar Halder &lt;=
<a href=3D"mailto:ayan.kumar.halder@amd.com">ayan.kumar.halder@amd.com</a>&=
gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex=
;border-left-color:rgb(204,204,204)">We have written the requirements for s=
ome of the commands of the XEN_VERSION<br>
hypercall.<br>
<br>
Signed-off-by: Ayan Kumar Halder &lt;<a href=3D"mailto:ayan.kumar.halder@am=
d.com" target=3D"_blank">ayan.kumar.halder@amd.com</a>&gt;<br>
---<br>
=C2=A0.../design-reqs/arm64/version_hypercall.rst=C2=A0 =C2=A0| 33 ++++++++=
<br>
=C2=A0.../reqs/design-reqs/version_hypercall.rst=C2=A0 =C2=A0 | 65 ++++++++=
+++++++<br>
=C2=A0docs/fusa/reqs/index.rst=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 2 +<br>
=C2=A0.../reqs/product-reqs/version_hypercall.rst=C2=A0 =C2=A0| 82 ++++++++=
+++++++++++<br>
=C2=A04 files changed, 182 insertions(+)<br>
=C2=A0create mode 100644 docs/fusa/reqs/design-reqs/arm64/version_hypercall=
.rst<br>
=C2=A0create mode 100644 docs/fusa/reqs/design-reqs/version_hypercall.rst<b=
r>
<br>
diff --git a/docs/fusa/reqs/design-reqs/arm64/version_hypercall.rst b/docs/=
fusa/reqs/design-reqs/arm64/version_hypercall.rst<br>
new file mode 100644<br>
index 0000000000..1dad2b84c2<br>
--- /dev/null<br>
+++ b/docs/fusa/reqs/design-reqs/arm64/version_hypercall.rst<br>
@@ -0,0 +1,33 @@<br>
+.. SPDX-License-Identifier: CC-BY-4.0<br>
+<br>
+Capabilities<br>
+------------<br>
+<br>
+`XenSwdgn~arm64_capabilities~1`<br>
+<br>
+Description:<br>
+Xen shall have a internal constant string storing &quot;xen-3.0-aarch64&qu=
ot;.</blockquote><div dir=3D"auto"><br></div><div dir=3D"auto">Can you expl=
ain why we need to specify how Xen is storing the string? At least to me th=
is feels a bit overkill. What matters is what/how the VM is seen.</div><div=
 dir=3D"auto"><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left=
:1ex;border-left-color:rgb(204,204,204)" dir=3D"auto"><br>
+<br>
+Rationale:<br>
+<br>
+Comments:<br>
+<br>
+Covers:<br>
+ - `XenProd~version_hyp_capabilities_cmd~1`<br>
+<br>
+Capabilities AArch32<br>
+--------------------<br>
+<br>
+`XenSwdgn~arm64_capabilities_aarch32~1`<br>
+<br>
+Description:<br>
+Xen shall have a internal constant string storing &quot;xen-3.0-armv7l&quo=
t; when it<br>
+detects that the cpu is running in AArch32 mode.<br>
+<br>
+Rationale:<br>
+<br>
+Comments:<br>
+<br>
+Covers:<br>
+ - `XenProd~version_hyp_capabilities_cmd~1`<br>
+<br>
diff --git a/docs/fusa/reqs/design-reqs/version_hypercall.rst b/docs/fusa/r=
eqs/design-reqs/version_hypercall.rst<br>
new file mode 100644<br>
index 0000000000..8bb7a66576<br>
--- /dev/null<br>
+++ b/docs/fusa/reqs/design-reqs/version_hypercall.rst<br>
@@ -0,0 +1,65 @@<br>
+.. SPDX-License-Identifier: CC-BY-4.0<br>
+<br>
+Version<br>
+-------<br>
+<br>
+`XenSwdgn~version~1`<br>
+<br>
+Description:<br>
+Xen shall have a internal constant storing the version number coming from =
the<br>
+Makefile.<br>
+<br>
+Rationale:<br>
+<br>
+Comments:<br>
+<br>
+Covers:<br>
+ - `XenProd~version_hyp_version_cmd~1`<br>
+<br>
+Subversion<br>
+----------<br>
+<br>
+`XenSwdgn~subversion~1`<br>
+<br>
+Description:<br>
+Xen shall have a internal constant storing the sub version number coming f=
rom<br>
+the Makefile.<br>
+<br>
+Rationale:<br>
+<br>
+Comments:<br>
+<br>
+Covers:<br>
+ - `XenProd~version_hyp_version_cmd~1`<br>
+<br>
+Extraversion<br>
+------------<br>
+<br>
+`XenSwdgn~extraversion~1`<br>
+<br>
+Description:<br>
+Xen shall have a internal constant string storing the extraversion coming =
from<br>
+the build environment.<br>
+<br>
+Rationale:<br>
+<br>
+Comments:<br>
+<br>
+Covers:<br>
+ - `XenProd~version_hyp_extraversion_cmd~1`<br>
+<br>
+Changeset<br>
+---------<br>
+<br>
+`XenSwdgn~changeset~1`<br>
+<br>
+Description:<br>
+Xen shall have a internal constant string storing the date, time and git h=
ash<br>
+of the last change made to Xen&#39;s codebase.<br>
+<br>
+Rationale:<br>
+<br>
+Comments:<br>
+<br>
+Covers:<br>
+ - `XenProd~version_hyp_changeset_cmd~1`<br>
diff --git a/docs/fusa/reqs/index.rst b/docs/fusa/reqs/index.rst<br>
index d8683edce7..b85af19d19 100644<br>
--- a/docs/fusa/reqs/index.rst<br>
+++ b/docs/fusa/reqs/index.rst<br>
@@ -14,3 +14,5 @@ Requirements documentation<br>
=C2=A0 =C2=A0 design-reqs/arm64/generic-timer<br>
=C2=A0 =C2=A0 design-reqs/arm64/sbsa-uart<br>
=C2=A0 =C2=A0 design-reqs/arm64/hypercall<br>
+=C2=A0 =C2=A0design-reqs/arm64/version_hypercall<br>
+=C2=A0 =C2=A0design-reqs/version_hypercall<br>
diff --git a/docs/fusa/reqs/product-reqs/version_hypercall.rst b/docs/fusa/=
reqs/product-reqs/version_hypercall.rst<br>
index fdb8da04e1..10bc7b6e87 100644<br>
--- a/docs/fusa/reqs/product-reqs/version_hypercall.rst<br>
+++ b/docs/fusa/reqs/product-reqs/version_hypercall.rst<br>
@@ -59,3 +59,85 @@ Covers:<br>
=C2=A0Needs:<br>
=C2=A0 - XenSwdgn<br>
<br>
+Version command<br>
+---------------<br>
+<br>
+`XenProd~version_hyp_version_cmd~1`<br>
+<br>
+Description:<br>
+Xen shall provide a command (num 0) for=C2=A0 hypercall (num 17) to retrie=
ve Xen&#39;s<br>
+version in the domain&#39;s x0 register.</blockquote><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border=
-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)" dir=
=3D"auto"><br>
+<br>
+Rationale:<br>
+<br>
+Comments:<br>
+Xen version is composed of major and minor number.<br>
+<br>
+Covers:<br>
+ - `XenMkt~version_hypercall~1`<br>
+<br>
+Needs:<br>
+ - XenSwdgn<br>
+<br>
+Extraversion command<br>
+--------------------<br>
+<br>
+`XenProd~version_hyp_extraversion_cmd~1`<br>
+<br>
+Description:<br>
+Xen shall provide a command (num 1) for hypercall (num 17) to copy its<br>
+extraversion in the domain&#39;s buffer.</blockquote><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border=
-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)" dir=
=3D"auto"><br>
+<br>
+Rationale:<br>
+<br>
+Comments:<br>
+Xen&#39;s extra version consists of a string passed with &#39;XEN_VENDORVE=
RSION&#39; command<br>
+line parameter while building Xen.</blockquote><div dir=3D"auto"><br></div=
><div dir=3D"auto">Not really. It returns a truncated version if it is too =
large. You likely want to describe command 11.</div><div dir=3D"auto"><br><=
/div><div dir=3D"auto"><br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;pad=
ding-left:1ex;border-left-color:rgb(204,204,204)" dir=3D"auto"><br>
+<br>
+Covers:<br>
+ - `XenMkt~version_hypercall~1`<br>
+<br>
+Needs:<br>
+ - XenSwdgn<br>
+<br>
+Capabilities command<br>
+--------------------<br>
+<br>
+`XenProd~version_hyp_capabilities_cmd~1`<br>
+<br>
+Description:<br>
+Xen shall provide a command (num 3) for hypercall (num 17) to copy its<br>
+capabilities to the domain&#39;s buffer.<br>
+<br>
+Rationale:<br>
+<br>
+Comments:<br>
+Capabilities related information is represented by char[1024].<br>
+For Arm64, the capabilities should contain &quot;xen-3.0-aarch64&quot; str=
ing.<br>
+<br>
+Covers:<br>
+ - `XenMkt~version_hypercall~1`<br>
+<br>
+Needs:<br>
+ - XenSwdgn<br>
+<br>
+Changeset command<br>
+-----------------<br>
+<br>
+`XenProd~version_hyp_changeset_cmd~1`<br>
+<br>
+Description:<br>
+Xen shall provide a command (num 4) for hypercall (num 17) to copy changes=
et<br>
+to the domain&#39;s buffer.<br>
+<br>
+Rationale:<br>
+<br>
+Comments:<br>
+Changeset is string denoting the date, time and git hash of the last chang=
e<br>
+made to Xen&#39;s codebase.<br>
+<br>
+Covers:<br>
+ - `XenMkt~version_hypercall~1`<br>
+<br>
+Needs:<br>
+ - XenSwdgn<br>
-- <br>
2.25.1<br>
<br>
<br>
</blockquote></div></div>

--000000000000a3f754062cda0721--


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 15:34:05 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 15:34:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879214.1289436 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdA4r-0007Hb-C2; Wed, 29 Jan 2025 15:34:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879214.1289436; Wed, 29 Jan 2025 15:34:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdA4r-0007HU-7r; Wed, 29 Jan 2025 15:34:05 +0000
Received: by outflank-mailman (input) for mailman id 879214;
 Wed, 29 Jan 2025 15:34:04 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=2GOy=UV=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tdA4q-0007HB-8k
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 15:34:04 +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 77bc2c67-de56-11ef-a0e6-8be0dac302b0;
 Wed, 29 Jan 2025 16:34:03 +0100 (CET)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-385de59c1a0so4085751f8f.2
 for <xen-devel@lists.xenproject.org>; Wed, 29 Jan 2025 07:34:03 -0800 (PST)
Received: from [192.168.100.192] (lfbn-gre-1-190-108.w90-112.abo.wanadoo.fr.
 [90.112.153.108]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38c2a17d315sm17378568f8f.22.2025.01.29.07.34.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 29 Jan 2025 07:34:01 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 77bc2c67-de56-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1738164842; x=1738769642; darn=lists.xenproject.org;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=JMMXwf5LB+65rQn3YABm35hGxlU9ABoLUYEYjVc4PtY=;
        b=Ra1JXkkfISlJJFGATQ2rzP6tl2ekQsMFnDa3/eWRNVk8abHRSt2917xcZPhdqbLxnS
         Hqa2ig2GXeOdXKphCfWtUpsXSxVLNk7rSegsZYOx5cEGfXOgAPzcDAvKMRE+FGfCClFO
         vbjuQOvNAKB3+NUlgmaJQ0DMA3v6VZUNbMyhfKxpDhxJ6KGws8lfk3XuVknup5UGH/Eq
         4U3dKHOhSUBb1yW0NFX6Poxd9m//n9P2xj9FkbAqVPRRw82+HLQvi18PbDHi+bXxY+wI
         1KcZwpUIBYMgLygkoTkSMZZDYeHmjAo81AolTXNtT1D1viwXePXYCJAX75XbB7eLZLoB
         dmXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738164842; x=1738769642;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=JMMXwf5LB+65rQn3YABm35hGxlU9ABoLUYEYjVc4PtY=;
        b=ODwoJUtwhnWUByNdNIniUpPDp3oGBI35euZva3VrZ1syp/csmQL0YrhfF+BerBojGm
         39T4FbxiFxQ/R6F7+MPt4cm5iIyKZlWQ/FskhoK3ZAZnNkZ7rT6cxd/KscYBypeY/v5/
         q9nfawEusxpvgfSgSP5bVxhI3ePEH6BWc8tRAgBFMlnUXxSXBsgREVFajUxftRBc9i1z
         9GIMR760lG3NHpWZ53mf4eMSKibzXjGC015sNqE73xyYXwkJDglSChiPI73muQvLUIep
         BYPLYg0NOOXggkuCuX68J7ypA8rT3WmI4TWAyaXA+UxMvU07OG1XLRVn/i3SsdTzO86m
         5OQg==
X-Forwarded-Encrypted: i=1; AJvYcCWnJjIf7Fu+VNFkBupKITvo28mIyeCNZDvjwGOy/RERlVbhrNZB8kGKNE46LZS3BQ7Fv3OkHDUu2iA=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzm+Os+rsHckaQoDIeHx6rPgCouZIsC3f0L+IbeMV/gJxzSNNFH
	FxKRXg1+LidaacmbQjIKLpd7pV+oRML+M/fT9cQ1acvsz9JfURry
X-Gm-Gg: ASbGnctnMB2bBhys56WZ9pyBizhIWkcNM32uHOPm5MdWqcIqoYNbQvu2xZM2bQj2UFV
	qjKFZvWw5/+wxhjypUCp32FwtVxTkUEjAnatLd2a9afFWVhf4mAIlTwUxmrvP989SzJWpAU9kqH
	AtlVSLwXib8XMU0cBhIogb3h2AvdnWMcGeW3tYlfUk05z04klNvO5oqKHSi1FDlaI6kd8dGQpkA
	aU49pTL7ZsDLUdz99UoRL2oXaC3npHMzpx8DiQaIOSf8SdDOJP4w17404p6JiK4Yf76Hc+9j2on
	ds5o1kFRgDsjDCsQ4sVfUKDevhUTM1nSw9JxhEfjA+VQpzw44bgMRH+/MkwcT+Da/yeJkd+nmOP
	LA2s=
X-Google-Smtp-Source: AGHT+IGwoLuvwtPb228WZXqSqrIZiLthpNeSvlJM+QD8fe4VuyXUocnnuWgpXgjB6/5mcKdGi/AgFg==
X-Received: by 2002:adf:e441:0:b0:385:fd07:85f4 with SMTP id ffacd0b85a97d-38c51960e78mr2821983f8f.31.1738164841958;
        Wed, 29 Jan 2025 07:34:01 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------l9FIo2gVAAD0dO9rebsI1lM9"
Message-ID: <b468ef6e-0745-4962-a555-216406257602@gmail.com>
Date: Wed, 29 Jan 2025 16:34:00 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 1/3] xen/riscv: implement software page table walking
To: Jan Beulich <jbeulich@suse.com>
Cc: Alistair Francis <alistair.francis@wdc.com>,
 Bob Eshleman <bobbyeshleman@gmail.com>, Connor Davis
 <connojdavis@gmail.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1737391102.git.oleksii.kurochko@gmail.com>
 <00dfc71569bc9971b53e29b36a80e9e020ac61ac.1737391102.git.oleksii.kurochko@gmail.com>
 <21bfd2f5-74b8-409e-956c-dd736a3c0be2@suse.com>
 <e2290a2a-a3c0-4cfe-b9e9-8cfec0b194a8@gmail.com>
 <a304e4f0-709f-4fcd-9847-01fe6ab4b98c@suse.com>
 <d9ca4252-1bf0-4257-ad6b-e91240cc5de3@gmail.com>
 <dfe0c6c5-db4a-4e27-9963-fe1b0c2bf629@suse.com>
 <c602d580-8d62-4fa9-9aa4-37fbd6201fa3@gmail.com>
 <47fb2f0f-fb75-4343-8f7c-cf8b27857d67@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <47fb2f0f-fb75-4343-8f7c-cf8b27857d67@suse.com>

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


On 1/29/25 3:01 PM, Jan Beulich wrote:
> On 29.01.2025 14:12, Oleksii Kurochko wrote:
>> On 1/28/25 9:14 AM, Jan Beulich wrote:
>>> On 27.01.2025 18:22, Oleksii Kurochko wrote:
>>>> On 1/27/25 1:57 PM, Jan Beulich wrote:
>>>>> On 27.01.2025 13:29, Oleksii Kurochko wrote:
>>>>>> On 1/27/25 11:06 AM, Jan Beulich wrote:
>>>>>>> On 20.01.2025 17:54, Oleksii Kurochko wrote:
>>>>>>>> RISC-V doesn't have hardware feature to ask MMU to translate
>>>>>>>> virtual address to physical address ( like Arm has, for example ),
>>>>>>>> so software page table walking in implemented.
>>>>>>>>
>>>>>>>> Signed-off-by: Oleksii Kurochko<oleksii.kurochko@gmail.com>
>>>>>>>> ---
>>>>>>>>      xen/arch/riscv/include/asm/mm.h |  2 ++
>>>>>>>>      xen/arch/riscv/pt.c             | 56 +++++++++++++++++++++++++++++++++
>>>>>>>>      2 files changed, 58 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/xen/arch/riscv/include/asm/mm.h b/xen/arch/riscv/include/asm/mm.h
>>>>>>>> index 292aa48fc1..d46018c132 100644
>>>>>>>> --- a/xen/arch/riscv/include/asm/mm.h
>>>>>>>> +++ b/xen/arch/riscv/include/asm/mm.h
>>>>>>>> @@ -15,6 +15,8 @@
>>>>>>>>      
>>>>>>>>      extern vaddr_t directmap_virt_start;
>>>>>>>>      
>>>>>>>> +paddr_t pt_walk(vaddr_t va);
>>>>>>> In the longer run, is returning just the PA really going to be sufficient?
>>>>>>> If not, perhaps say a word on the limitation in the description.
>>>>>> In the long run, this function's prototype looks like|paddr_t pt_walk(vaddr_t root, vaddr_t va, bool is_xen)| [1]. However, I'm not sure if it will stay that way,
>>>>>> as I think|is_xen| could be skipped, since using|map_table()| should be sufficient (as it now considers|system_state|) and I'm not really sure if I need root argument
>>>>>> as initial goal was to use this function for debug only purposes and I've never used it for guest page table (stage-1) walking.
>>>>>> Anyway, yes, it is still returning a physical address, and that seems enough to me.
>>>>>>
>>>>>> Could you share your thoughts on what I should take into account for returning value, probably, I am missing something really useful?
>>>>> Often you care about the permissions as well. Sometimes it may even be relevant
>>>>> to know the (super-)page size of the mapping.
>>>> Perhaps it would be better to change the prototype to:
>>>>      bool pt_walk(vaddr_t va, mfn_t *ret_pa);
>>>> or even
>>>>      void pt_walk(vaddr_t va, mfn_t *ret_pa);
>>>>      In this case,|ret_pa = INVALID_MFN| could serve as a signal that|pt_walk()| failed.
>>>> If there's a need to return permissions or (super-)page size in the future, another argument could be added.
>>>>
>>>> What do you think? Would this approach be better?
>>>>
>>>> I am also considering returning a structure containing the|mfn| (or|paddr_t|) and adding other properties (such as permissions or
>>>> page size) as needed in the future. Both solutions seem more or less equivalent.
>>> Imo the most natural thing for a page walking function would be to return the
>>> leaf PTE (or the leaf-most not-present [or otherwise "no-access"] one). That
>>> would provide (almost) all possible information to the caller. "Almost"
>>> because depending on how page walk works, permissions may combine across page
>>> table levels. Yet then (see also the "no-access" above) this would also
>>> require further input, to specify the context for which the translation is
>>> being seeked. For example, the intention to write may want to yield no valid
>>> PTE when there are present ones down to the leaf, but effective permissions
>>> say "read-only".
>> Perhaps returning the leaf PTE could be a really good option.
>>
>> I'm not entirely sure I understand what you mean by "leaf-most not-present". Could you please try to explain this moment one more time?
>> My expectation was that the function should return an existing leaf PTE (from which "access" rights could be determined)
>> or|NULL| to indicate that no leaf PTE was found.
> "no leaf PTE" may be for a variety of reasons. Hence why I think returning
> the PTE at which the walk stopped (leaf or leaf-most not-present) is likely
> best. Such a not-present PTE may, after all, still contain valuable
> information; it's not like it has to be all zero.

Thanks, it is clearer now.

It will complicate a little bit vmap_to_mfn() (as we should to check that pt_walk()
returns a leaf; otherwise something wrong happens), but I think it is not really
critical as you mentioned before, and for convenience it would be better to implement
it as a static inline function:

   static inline mfn_t vmap_to_mfn(vaddr_t va)
   {
       pte_t *entry = pt_walk(va, NULL);

       BUG_ON(!pte_is_mapping(*entry));

       return mfn_from_pte(*entry);
   }

>> Another thing I'm curious about is whether this would be sufficient for determining the level.
>> It seems clear that, given a PTE and a virtual address, we could compute:
>> |mask = VA | paddr_from_pte(pte)|
> What would this value represent? No, from holding a PTE in your hands you
> can't determine the level it came from. So yes, ...
>
>> Then, iterating through each level, we could apply and understand on which one level it was mapped:
>> |mask & (BIT(XEN_PT_LEVEL_ORDER(i), UL) - 1)|.
>>
>> If I haven't overlooked any other way to calculate the page table level, would it be better to simply add another argument
>> to|pt_walk()| to return the level.
> ... for callers who care doing this might then be necessary (this would be
> a pointer parameter, and since I expect many callers wouldn't care about
> the level, it likely wants to be permissible to pass in NULL).
>
> Question then is whether it's better to hand back the level or the page
> order of the mapping. On x86 we return the latter from P2M lookups, for
> example.

Actually, I think for proper calculation of order in pt_update().

Thanks.

~ Oleksii


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

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 1/29/25 3:01 PM, Jan Beulich wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:47fb2f0f-fb75-4343-8f7c-cf8b27857d67@suse.com">
      <pre wrap="" class="moz-quote-pre">On 29.01.2025 14:12, Oleksii Kurochko wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">
On 1/28/25 9:14 AM, Jan Beulich wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="" class="moz-quote-pre">On 27.01.2025 18:22, Oleksii Kurochko wrote:
</pre>
          <blockquote type="cite">
            <pre wrap="" class="moz-quote-pre">On 1/27/25 1:57 PM, Jan Beulich wrote:
</pre>
            <blockquote type="cite">
              <pre wrap="" class="moz-quote-pre">On 27.01.2025 13:29, Oleksii Kurochko wrote:
</pre>
              <blockquote type="cite">
                <pre wrap="" class="moz-quote-pre">On 1/27/25 11:06 AM, Jan Beulich wrote:
</pre>
                <blockquote type="cite">
                  <pre wrap="" class="moz-quote-pre">On 20.01.2025 17:54, Oleksii Kurochko wrote:
</pre>
                  <blockquote type="cite">
                    <pre wrap="" class="moz-quote-pre">RISC-V doesn't have hardware feature to ask MMU to translate
virtual address to physical address ( like Arm has, for example ),
so software page table walking in implemented.

Signed-off-by: Oleksii Kurochko<a class="moz-txt-link-rfc2396E" href="mailto:oleksii.kurochko@gmail.com">&lt;oleksii.kurochko@gmail.com&gt;</a>
---
    xen/arch/riscv/include/asm/mm.h |  2 ++
    xen/arch/riscv/pt.c             | 56 +++++++++++++++++++++++++++++++++
    2 files changed, 58 insertions(+)

diff --git a/xen/arch/riscv/include/asm/mm.h b/xen/arch/riscv/include/asm/mm.h
index 292aa48fc1..d46018c132 100644
--- a/xen/arch/riscv/include/asm/mm.h
+++ b/xen/arch/riscv/include/asm/mm.h
@@ -15,6 +15,8 @@
    
    extern vaddr_t directmap_virt_start;
    
+paddr_t pt_walk(vaddr_t va);
</pre>
                  </blockquote>
                  <pre wrap="" class="moz-quote-pre">In the longer run, is returning just the PA really going to be sufficient?
If not, perhaps say a word on the limitation in the description.
</pre>
                </blockquote>
                <pre wrap="" class="moz-quote-pre">In the long run, this function's prototype looks like|paddr_t pt_walk(vaddr_t root, vaddr_t va, bool is_xen)| [1]. However, I'm not sure if it will stay that way,
as I think|is_xen| could be skipped, since using|map_table()| should be sufficient (as it now considers|system_state|) and I'm not really sure if I need root argument
as initial goal was to use this function for debug only purposes and I've never used it for guest page table (stage-1) walking.
Anyway, yes, it is still returning a physical address, and that seems enough to me.

Could you share your thoughts on what I should take into account for returning value, probably, I am missing something really useful?
</pre>
              </blockquote>
              <pre wrap="" class="moz-quote-pre">Often you care about the permissions as well. Sometimes it may even be relevant
to know the (super-)page size of the mapping.
</pre>
            </blockquote>
            <pre wrap="" class="moz-quote-pre">Perhaps it would be better to change the prototype to:
    bool pt_walk(vaddr_t va, mfn_t *ret_pa);
or even
    void pt_walk(vaddr_t va, mfn_t *ret_pa);
    In this case,|ret_pa = INVALID_MFN| could serve as a signal that|pt_walk()| failed.
If there's a need to return permissions or (super-)page size in the future, another argument could be added.

What do you think? Would this approach be better?

I am also considering returning a structure containing the|mfn| (or|paddr_t|) and adding other properties (such as permissions or
page size) as needed in the future. Both solutions seem more or less equivalent.
</pre>
          </blockquote>
          <pre wrap="" class="moz-quote-pre">Imo the most natural thing for a page walking function would be to return the
leaf PTE (or the leaf-most not-present [or otherwise "no-access"] one). That
would provide (almost) all possible information to the caller. "Almost"
because depending on how page walk works, permissions may combine across page
table levels. Yet then (see also the "no-access" above) this would also
require further input, to specify the context for which the translation is
being seeked. For example, the intention to write may want to yield no valid
PTE when there are present ones down to the leaf, but effective permissions
say "read-only".
</pre>
        </blockquote>
        <pre wrap="" class="moz-quote-pre">
Perhaps returning the leaf PTE could be a really good option.

I'm not entirely sure I understand what you mean by "leaf-most not-present". Could you please try to explain this moment one more time?
My expectation was that the function should return an existing leaf PTE (from which "access" rights could be determined)
or|NULL| to indicate that no leaf PTE was found.
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
"no leaf PTE" may be for a variety of reasons. Hence why I think returning
the PTE at which the walk stopped (leaf or leaf-most not-present) is likely
best. Such a not-present PTE may, after all, still contain valuable
information; it's not like it has to be all zero.</pre>
    </blockquote>
    <pre>Thanks, it is clearer now.

It will complicate a little bit vmap_to_mfn() (as we should to check that pt_walk()
returns a leaf; otherwise something wrong happens), but I think it is not really
critical as you mentioned before, and for convenience it would be better to implement
it as a static inline function:

  static inline mfn_t vmap_to_mfn(vaddr_t va)
  {
      pte_t *entry = pt_walk(va, NULL);

      BUG_ON(!pte_is_mapping(*entry));

      return mfn_from_pte(*entry);
  }
</pre>
    <blockquote type="cite"
      cite="mid:47fb2f0f-fb75-4343-8f7c-cf8b27857d67@suse.com">
      <pre wrap="" class="moz-quote-pre">
</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">Another thing I'm curious about is whether this would be sufficient for determining the level.
It seems clear that, given a PTE and a virtual address, we could compute:
|mask = VA | paddr_from_pte(pte)|
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
What would this value represent? No, from holding a PTE in your hands you
can't determine the level it came from. So yes, ...

</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">Then, iterating through each level, we could apply and understand on which one level it was mapped:
|mask &amp; (BIT(XEN_PT_LEVEL_ORDER(i), UL) - 1)|.

If I haven't overlooked any other way to calculate the page table level, would it be better to simply add another argument
to|pt_walk()| to return the level.
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
... for callers who care doing this might then be necessary (this would be
a pointer parameter, and since I expect many callers wouldn't care about
the level, it likely wants to be permissible to pass in NULL).

Question then is whether it's better to hand back the level or the page
order of the mapping. On x86 we return the latter from P2M lookups, for
example.</pre>
    </blockquote>
    <pre>Actually, I think for proper calculation of order in pt_update().

Thanks.

~ Oleksii
</pre>
    <p><br>
    </p>
  </body>
</html>

--------------l9FIo2gVAAD0dO9rebsI1lM9--


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 15:49:26 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 15:49:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879227.1289445 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdAJa-0000tG-Ly; Wed, 29 Jan 2025 15:49:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879227.1289445; Wed, 29 Jan 2025 15:49:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdAJa-0000t9-J7; Wed, 29 Jan 2025 15:49:18 +0000
Received: by outflank-mailman (input) for mailman id 879227;
 Wed, 29 Jan 2025 15:49:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=/Ogr=UV=arm.com=Bertrand.Marquis@srs-se1.protection.inumbo.net>)
 id 1tdAJY-0000t2-Hw
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 15:49:16 +0000
Received: from EUR05-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur05on20628.outbound.protection.outlook.com
 [2a01:111:f403:2613::628])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9729d633-de58-11ef-a0e6-8be0dac302b0;
 Wed, 29 Jan 2025 16:49:15 +0100 (CET)
Received: from DU6P191CA0059.EURP191.PROD.OUTLOOK.COM (2603:10a6:10:53e::16)
 by PAWPR08MB10923.eurprd08.prod.outlook.com (2603:10a6:102:470::13) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.22; Wed, 29 Jan
 2025 15:49:11 +0000
Received: from DB1PEPF000509EB.eurprd03.prod.outlook.com
 (2603:10a6:10:53e:cafe::b6) by DU6P191CA0059.outlook.office365.com
 (2603:10a6:10:53e::16) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8398.17 via Frontend Transport; Wed,
 29 Jan 2025 15:49:10 +0000
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 DB1PEPF000509EB.mail.protection.outlook.com (10.167.242.69) with
 Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8398.14
 via Frontend Transport; Wed, 29 Jan 2025 15:49:10 +0000
Received: ("Tessian outbound 7a81a5980674:v560");
 Wed, 29 Jan 2025 15:49:10 +0000
Received: from Ld9bf03250bcb.1
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 1756614B-F63B-4733-BE26-C352A8EEFCF5.1; 
 Wed, 29 Jan 2025 15:49:04 +0000
Received: from DU2PR03CU002.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id
 Ld9bf03250bcb.1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Wed, 29 Jan 2025 15:49:04 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by PAVPR08MB9353.eurprd08.prod.outlook.com (2603:10a6:102:302::5)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.22; Wed, 29 Jan
 2025 15:49:02 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a%6]) with mapi id 15.20.8377.021; Wed, 29 Jan 2025
 15:49:02 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9729d633-de58-11ef-a0e6-8be0dac302b0
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=snS/l2/0zd7Ix6qeqnD2ADtX8x0Vo7WYquU8qfHvW+dE3U+upK/PLeKFkO0kNQYfF8RcI3UP0FxCMF8UgQo4fJ0lsQRa+Rke74/i48Bl1NWBr2ATl5854KMVj309dBbrT/TMknhzfVs4ajVzJB0nMJ5AWAkq+IFiIFm3bEbf4pD/SrRjRGwHrV9MPtymVsKkDLFEw4wKUBi3e1yrtwNkL6l0Sq9WelGdWLvlKiAEgi5hO31RKxJliBVLvbfIHjDjNcC683jrhDQ33lIr7gspGFIZp4pU8LnFxEw570DYrdu5Rvta1BTUiKTVCrh8oEvdNhYkcpEeV7fWyK7vslPiVQ==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=zio1Ob2iOtULBNc7H/FdduLNVGHP14O1EMaJZwRvXJo=;
 b=ApZN0zp/o/PZcWX/0KMI641onaacFjyltJMkh/EUuYMm5peY/zqXzjZ4iwaiMyngEoc28O9ZD1FvsFMlA40eArx5yU2flrkXoHO1HVdH63p9Zs5nP5XiPannoeRjCH4ENC5vUFh34BFkfzmOOPxVpqVMTfpOTRZW/aWnpp6yWBtLK2Ro1WD3Ra/puImzYx+/cAJFBTbgE3OsBWrMfycbkGIu5Wxl4GZLoOwWFSegmbRpQADHl/zDafhTQ66oem7hLb+vF7FgKsU1MUAvrpNzRedVptbpS5MjqNZgr9MSSRRw/PaoZM6vYYSEdcJstvD4hSc9IVIM23hliWdpI0PPNA==
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=arm.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=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=zio1Ob2iOtULBNc7H/FdduLNVGHP14O1EMaJZwRvXJo=;
 b=LLuM/35pKCZ1B3qJdNOmWgFtC2VL6DMofjL95qO8fTWc/xcG1mZlcGKjmPeXXhxrHuV2mBh40jfHcexgudPM6qVCV+9mFf6KyrDaopT7dHF5ZL/tgemEKA9/HJDYUl+lIs+QJhLYCSf6mPD6rh/eyYe1psmTUErEge3aFRcGWGo=
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=arm.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: b592fee4e6f6e6cb
X-TessianGatewayMetadata: UTD8kXsM+Ha14pOPiGndl41VaC7f7v4NmGZpxuw4hM6ukedXrKaCqasRjdYrlxkqPrHYrZd97BChFgaLlamRKroSKh8EYz5ysaSxX0xOBElE3Z8S3UosWckRPvWhXjFy6trk8CMur7g96XZVnWuMrwPtc0umYPz1PeOEVnfVmxs=
X-CR-MTA-TID: 64aa7808
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=QLY+PPtsaLG/em6OUlXJdsgPPQKrptlWgx7XXy9qHdWmdGhbubsgufjHsFPNBcIOpbYlg15/FwMIB4XjK5f5CmQ9oj0hrmJgN9AMCtb9FI3g5bDm2HJfYq0xVFQ95eQViHoQ9oYUrm5z6I6Z90qPwM7AcJ54zKFBTc+NQGSOe9b/u8CaD4xn833Wuc8oTTappaBJpNQ5mL8I+q06NeuNQYUWP1fe0W72nDTwgArVeWTzCCFNKsxz6nm1Ug3uXnbzsamPn3DeLVDKVkk4jb9m/01mmJY1KKcJayN2/NJE+S6w4KNoZ6VFSPCU8c6cl8/cHH1q1scpanek3qMqjIRxYA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=zio1Ob2iOtULBNc7H/FdduLNVGHP14O1EMaJZwRvXJo=;
 b=o2l60IjsY/efWOa308SYogTmSzHqTCr5oCRb/Oo3o2XCInmmS3Fi9JNNN4TVrkS8Ruu1xfDw4BJ3Z5bcTwoneSUwS+jd+xAq+d3m4TQ6CblTlNeLdyfbB5OuWhmQI3NboyPhDLgmCeAarZkSX2opARGxZufV50ex/yrh4UVqn/qknQJ/Wzgb3mfUswz9jfAN8ICh5qY4Auu35D8AplgYBVASYYuhd9BdnbCYYH48p2t7qPe1eW8WhkFgYMQ+FLRvzuIv7P+E0v3xwkKH92SvPZEiSKc9USqff1spFX+XfTd6Rw3SoNHpflzhV/EVKykgPr/Tk5qguINO8Dq1fOix1Q==
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=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=zio1Ob2iOtULBNc7H/FdduLNVGHP14O1EMaJZwRvXJo=;
 b=LLuM/35pKCZ1B3qJdNOmWgFtC2VL6DMofjL95qO8fTWc/xcG1mZlcGKjmPeXXhxrHuV2mBh40jfHcexgudPM6qVCV+9mFf6KyrDaopT7dHF5ZL/tgemEKA9/HJDYUl+lIs+QJhLYCSf6mPD6rh/eyYe1psmTUErEge3aFRcGWGo=
From: Bertrand Marquis <Bertrand.Marquis@arm.com>
To: Julien Grall <julien.grall.oss@gmail.com>
CC: Ayan Kumar Halder <ayan.kumar.halder@amd.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Stefano
 Stabellini <sstabellini@kernel.org>, Michal Orzel <michal.orzel@amd.com>,
	Artem Mygaiev <artem_mygaiev@epam.com>
Subject: Re: [PATCH v1 2/2] docs: fusa: Add the requirements for some of the
 commands of XEN_VERSION
Thread-Topic: [PATCH v1 2/2] docs: fusa: Add the requirements for some of the
 commands of XEN_VERSION
Thread-Index: AQHbZr2QpA/avZzDqk6Vb2qnMvbcCbMt+LgAgAAEYwA=
Date: Wed, 29 Jan 2025 15:49:02 +0000
Message-ID: <E930B9A0-6C32-476C-8829-7FD4C991F4A9@arm.com>
References: <20250114195010.3409094-1-ayan.kumar.halder@amd.com>
 <20250114195010.3409094-2-ayan.kumar.halder@amd.com>
 <CAJ=z9a1ynFU86ac=1Q7i=xSNh2bjnZJ3+tPjsjWvfw7294n_NA@mail.gmail.com>
In-Reply-To:
 <CAJ=z9a1ynFU86ac=1Q7i=xSNh2bjnZJ3+tPjsjWvfw7294n_NA@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.300.87.4.3)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB9PR08MB6588:EE_|PAVPR08MB9353:EE_|DB1PEPF000509EB:EE_|PAWPR08MB10923:EE_
X-MS-Office365-Filtering-Correlation-Id: e168b4c4-f9e3-44c7-9329-08dd407c7917
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|1800799024|376014|366016|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?us-ascii?Q?oq8DbMpGpfmKorYANWkKjIJlF8S+UA5MZ+Na9V6kXM5J6UhNCCOt1AhQGCXM?=
 =?us-ascii?Q?TcxCl5Pxfn92OTssJZKJZF0S8RfxdRiautEaG4cAWdqOC95P1PyJ6MmyHw6p?=
 =?us-ascii?Q?vMPwoFO7nWqALTgV7M8GKcBG0MZxt9h4DlXdLHmC+/ow2C1mkHyVbUH6Hyyo?=
 =?us-ascii?Q?/tGDip5yLEMAJ+YciKVYjt7qZZyuDSoX2/hYTRAlxt+2JiqTdzNzdABtaMvz?=
 =?us-ascii?Q?Q8h2uZUXpoT/zgWorsUKgPskkU8VXH/P2tqiNolgLsAG/kih79c4t2j68KP1?=
 =?us-ascii?Q?FOKKN0Xi+VOPQRIH+nKmhvAo1cOZ9B9aAWlOJdyvmxLMQvkVvvdxvsXBrMUf?=
 =?us-ascii?Q?TaTmB/a5XDjh/tF30FijMXU8VbF2OLsggzTepNQZ66Nz4Q1bVmNDYvlzJke1?=
 =?us-ascii?Q?07dYmvY7rQ1+CsGyULFqZ8HBGaXw1NcNoTxPbbT+pLHV38odLiD+MkjMlGRi?=
 =?us-ascii?Q?sxhorTmmnawMyMmSQELMfQi0cRy9n8Aw3uQgcBYCq7mhhe0xPbt0K5uq6G9+?=
 =?us-ascii?Q?U3gV7eCxYGoeYNh5d5HcVskH/x1+tqUgUKPP8KMs61kYni07JFeZX1EeaF6/?=
 =?us-ascii?Q?7vvJrvxYpI1hi9LV42XVi7Rm1VGTELaiqcFv5enVjy/TRBlAb0lnF9bp9eP4?=
 =?us-ascii?Q?vZzULvN0jCLCwZS1UYCO86f9Lr9ro81kvOJlGf4fHnTlmbeI3EFkHbppiaHc?=
 =?us-ascii?Q?VHnG7ztNO5UwBmRdPVtn/gjA6lgUyrfYoEmQ9QQUQ4Vw7055L45Om9hajhth?=
 =?us-ascii?Q?TPXXyMnIjgeY9fvLFc5QK0SXJTk4xmZiJ5it54FYLlzqVWpCZpG9Vc2mP0Vp?=
 =?us-ascii?Q?TLKWwNI4NjUsU0Rcq9u4PG/6p0Yy5Pv6R+cBCzpyy1xf2iaWdYrQvIXYFkeL?=
 =?us-ascii?Q?upgNEmX2KmhNrCIKvT0p1JikSsL/alRRUViHD4MlvHwRG1fMgDz/FbrEj+QF?=
 =?us-ascii?Q?5v2nydppADbohA5fZIq3fkhbZWrmWgEvIhqaHNBrds13pB2h3PswW9O90Ono?=
 =?us-ascii?Q?4a149GMCDPgoFwWgaTFdTMUfu0d8AtvrDrqkA9jSpFyIe/WlpLRjalDb9coR?=
 =?us-ascii?Q?lJfbNYtokTWhsfJUVBgm1VawVp6E72fJSOHjfLi1M1CF/ztTLHKv2P0M/k/p?=
 =?us-ascii?Q?2uABPnFAYCS7bn4ixEQ5Va3nzYohsAvecrR72WZ1sFJyWEAadWdPINXRnapw?=
 =?us-ascii?Q?c3jZKb440lQ6rTcUXaNAmx7FWNrjHb9PEDbo6GWrfncrCYe7YI61J5Js2C3l?=
 =?us-ascii?Q?z+BmB47GA7Jo8SA2bZ6CGchTZpwfQstZ/CqgPpe+PPaPSnopO3UlXT30OX1w?=
 =?us-ascii?Q?7jrp7e+LmPbqXZ1R5fixLVLEyIo8wmCgQzuWOQ13fCutL6BeTbpFHGp/kwTb?=
 =?us-ascii?Q?IX4YUaekR0qQZu6ntQloz49txcF4q6capC65UEMZOSHlM80wPhjXTkCyfF9b?=
 =?us-ascii?Q?qbOggNoCvsfnj+xS7jcO70F2vsnw5lD6?=
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:(13230040)(1800799024)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3429C3DC1010E245A0D22D2A49F82C59@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR08MB9353
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-SkipListedInternetSender:
 ip=[2603:10a6:10:25a::24];domain=DB9PR08MB6588.eurprd08.prod.outlook.com
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DB1PEPF000509EB.eurprd03.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	1cea7836-eaf6-48bf-5126-08dd407c7424
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|1800799024|35042699022|14060799003|36860700013|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?AIMVRPC1NljhIAQm5trCqPhkxR2dCAoDtX+KWpCzZ3jRPsTvABEWEKz04Ya+?=
 =?us-ascii?Q?Bh6bxjWa1ldgUK2QkJu12+yYZaaarWGw69g+lm8av0v+wbzx3S7UnaHyA1vr?=
 =?us-ascii?Q?rDkPR3pUkjXLpCk2KKSMT4baEvuuzvW/d1+o82muiMIg89z8ologTe+A+K2U?=
 =?us-ascii?Q?3K6d/cSgqpfoc99FsijwgLXSgrHafNp0CaEFYbC+i3/p296l2dQGP/Po34kj?=
 =?us-ascii?Q?hxj02FPO45Qr83L7dz5+0Fz9aI74Nr6DqNYJi9jSojroXHpijB5V+5szonWz?=
 =?us-ascii?Q?EElZoapcXAqvXo0rebKH8dW8WzLHvNps/9zpU3M/J47RS966m5a9vvPoFayl?=
 =?us-ascii?Q?ijRDxMO4USROD8Gn2VuIwYIUQ2For1OHk45zNFgjL62ZD99vlyAMKE/OX0gp?=
 =?us-ascii?Q?006l4egnw/RGQQIRnE8C8zJ31xVNYkvePSLSW0jA8ToP0lWw2U3lh5F7nmom?=
 =?us-ascii?Q?IdaovNTz+sTjpE2NtH/Kx0zFcqFCKvx1VNkbdu65q3x8/akyueO2WvezizC0?=
 =?us-ascii?Q?Mcoj4MbyEYktaEwDkWnZQxDJHeUZtyWGRuLNo1PuNyv/qkH++s4CDRuRi2D3?=
 =?us-ascii?Q?hgzzZdK8kSqe1sBG/p/MhaAdBauO3LVEHx7HL81O3Jcw2Y7XkNkdUHWSRTIS?=
 =?us-ascii?Q?krnzkXUlxOO2AB5V0pRV7aMMfTE9Rz/X/1zgar/rGymj6zZTzPzM52cKmvuH?=
 =?us-ascii?Q?hE3/mQpfyaltKyIHJbEy23iqZMQJDJBeAsxIUctAmWu0h2gnx6zS21Q7ZLEA?=
 =?us-ascii?Q?sPToRJiqQYFpq+yTrMBFo9kDLG06zznSqSHBUEUQamcE3tHk6nvtZskJkuLA?=
 =?us-ascii?Q?+yTg6k58314rTvELEecIMPDwHmjx+bKG/H+Tnqp5CrInA2JvzuAMNjdYezeH?=
 =?us-ascii?Q?C84XFk6qQ8KY5AkdHz0RROneXQiT7cPeUAB1hx63J6uErejev/iAqA72QfC5?=
 =?us-ascii?Q?X4qFATDjkyfgSdEB8XeqleEZjbwS6ndX10gSky6aSnb2f+uGolj9C8vm6FDm?=
 =?us-ascii?Q?Sy7iFMdpzK/ty3Fb9FIv0zwPAtkJglM3EjKPoLOr0I2Pby8p30zCHtt66l6D?=
 =?us-ascii?Q?7EkEmIOe0VQbspD4tW9Zbu86zW+UBQRKSAj/edCHfq/KOtd+5tvTZz3LfKqC?=
 =?us-ascii?Q?eyGa3++46eh7+s4yXufcGnk2bo0yBBM+bFvX0SwMmT8s0qQ3ZFYmtNBBxGaQ?=
 =?us-ascii?Q?yvP4kNRSNRuGUAvRbg7vtzlUCKkQ07tNbbHexGpBLVfNJg5tmRxIjMxBmwkH?=
 =?us-ascii?Q?IttuinbMfp6p94dny+VlMbrdZmS82W3DSSVB7gC3TY5RwkhHSK7o/usF3EOB?=
 =?us-ascii?Q?5a68MHVHChFsW/2T4MxLyrTmWya+c3gWlp7hEvi7rl1K399pUsEQf6GRNWi6?=
 =?us-ascii?Q?x6drHxoUFaeVstUxUT2WF8/ImwvaiE071F3Fx2QcZKOofCOJubTOZb41Mkc7?=
 =?us-ascii?Q?Mc+3AF3bpIHKKvUxnrS+e0NxWnVtWOmUig3xZ4xa7yMnQxDo59LMl6JaqJWC?=
 =?us-ascii?Q?UIkskuUSLbqwfeI=3D?=
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:64aa7808-outbound-1.mta.getcheckrecipient.com;CAT:NONE;SFS:(13230040)(376014)(1800799024)(35042699022)(14060799003)(36860700013)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2025 15:49:10.8032
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e168b4c4-f9e3-44c7-9329-08dd407c7917
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:
	DB1PEPF000509EB.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR08MB10923

Hi Julien,

Welcome back :-)

> On 29 Jan 2025, at 16:33, Julien Grall <julien.grall.oss@gmail.com> wrote=
:
>=20
> Hi,
>=20
> On Tue, 14 Jan 2025 at 16:50, Ayan Kumar Halder <ayan.kumar.halder@amd.co=
m> wrote:
> We have written the requirements for some of the commands of the XEN_VERS=
ION
> hypercall.
>=20
> Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
> ---
>  .../design-reqs/arm64/version_hypercall.rst   | 33 ++++++++
>  .../reqs/design-reqs/version_hypercall.rst    | 65 +++++++++++++++
>  docs/fusa/reqs/index.rst                      |  2 +
>  .../reqs/product-reqs/version_hypercall.rst   | 82 +++++++++++++++++++
>  4 files changed, 182 insertions(+)
>  create mode 100644 docs/fusa/reqs/design-reqs/arm64/version_hypercall.rs=
t
>  create mode 100644 docs/fusa/reqs/design-reqs/version_hypercall.rst
>=20
> diff --git a/docs/fusa/reqs/design-reqs/arm64/version_hypercall.rst b/doc=
s/fusa/reqs/design-reqs/arm64/version_hypercall.rst
> new file mode 100644
> index 0000000000..1dad2b84c2
> --- /dev/null
> +++ b/docs/fusa/reqs/design-reqs/arm64/version_hypercall.rst
> @@ -0,0 +1,33 @@
> +.. SPDX-License-Identifier: CC-BY-4.0
> +
> +Capabilities
> +------------
> +
> +`XenSwdgn~arm64_capabilities~1`
> +
> +Description:
> +Xen shall have a internal constant string storing "xen-3.0-aarch64".
>=20
> Can you explain why we need to specify how Xen is storing the string? At =
least to me this feels a bit overkill. What matters is what/how the VM is s=
een.

This is a design requirement and as such it should be testable so it would =
be easier to have something saying:
Xen shall have a constant named XXX storing YYY.

Just saying "an internal constant" seem a bit limited here and not saying m=
uch that could be tested easily.

Why do you think this would be an overkill ? do you expect the constant nam=
e to change a lot ?
I would see more as an overkill the fact that the value is stored in a requ=
irement.

Cheers
Bertrand



From xen-devel-bounces@lists.xenproject.org Wed Jan 29 16:25:56 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 16:25:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879238.1289455 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdAsx-0006xv-CN; Wed, 29 Jan 2025 16:25:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879238.1289455; Wed, 29 Jan 2025 16:25:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdAsx-0006xo-8y; Wed, 29 Jan 2025 16:25:51 +0000
Received: by outflank-mailman (input) for mailman id 879238;
 Wed, 29 Jan 2025 16:25:50 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=gkQ8=UV=cloud.com=roger.pau@srs-se1.protection.inumbo.net>)
 id 1tdAsv-0006xe-Tv
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 16:25:49 +0000
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com
 [2a00:1450:4864:20::336])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b2473062-de5d-11ef-99a4-01e77a169b0f;
 Wed, 29 Jan 2025 17:25:47 +0100 (CET)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-43634b570c1so50854095e9.0
 for <xen-devel@lists.xenproject.org>; Wed, 29 Jan 2025 08:25:47 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38c2a188a77sm17883774f8f.51.2025.01.29.08.25.46
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 29 Jan 2025 08:25:46 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b2473062-de5d-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1738167947; x=1738772747; 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=qjT+0jckemTXzJdoR+iMpmVRJLq/FksSY7pr1cNa0wc=;
        b=JFgFax/9Hw564/LElFGFseHQwyhm5Fn56oh5OyY1TMqZuPPfpF9RYIkYsFKr9JS3uB
         R51rv2R5/Vd8oBoeK2FLpLHzL15bg7eDCZbxiMdqK6DbNX846d+HYN7S2BvlfeoKoblT
         Gh5ylcy6W+6AVxlgd9xZhjETN1pTnYmVJ0DPg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738167947; x=1738772747;
        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=qjT+0jckemTXzJdoR+iMpmVRJLq/FksSY7pr1cNa0wc=;
        b=P9E4/A8f6XV0sxMJ6LKXKpx7qTsHbEpxrDalcEy9xHOUcoecBIZ3McZf+9oEx8arIX
         vpE90WIfuK3IOv+EOHwzKk5hmP4evu+bQL1EPuMCS2BPmMLmJ1CI5ZbhOrSnZQwQ2PPC
         4r+PxRay9OsFMUbbi3M7AQ9WcF4J8k2MVqF0iDtve3lmwFC6tDT0C7DP2mCdBM6OWMtV
         r7JkvVYr4oMBP44cZ30Y9kkHPp9MGPsUsfLwENzIJci3cDTQb04bZZtITJXioL9sTUAZ
         4Ftg/mSojoYQYjGvGOxxZ40EbVsYJQL/9h6d2Dsj2kxvTKowRlJ96kfyrlcMH2l8KvVe
         Qmjg==
X-Gm-Message-State: AOJu0YzUU7lF7TwZFRaaTCT36p2HZnmA1w1mnp9Knt7hmjNE5JrSedl+
	i/TTV6qR7KxqDul3/8bqWTuMZzajXQdjjBU1TP+uH0BqP+HxmRb6MaMbtvJ/EWA=
X-Gm-Gg: ASbGnctFZR22FbdUHAJAvZu16eZpzBqnsJ6BhybpQ0RLKhkTDxdCT1iXcF9Ov0PNkvS
	kIJ3WR+6jTDBeu3xZUrKhqHT08/86CpG6peo9ZbowrI+OLivwKQn0WZx0HunABC5DO7pRkX+Jmy
	9vTcizrflu4xaZYCVS38BdqQvJaGjzoZL3JH9mwD+i1BaogxdUNTiesJ7v0IiJ+qE24UP2IYwCs
	6fIUIAGbAeJIvqYm9G1qK588B/MubPncvVusXLjtSRwikS/7ZMwkG5Q2amcAthJs1jO7zQJsCXV
	ufXp8qvxGpB73/3WTcsR6Ju23Q==
X-Google-Smtp-Source: AGHT+IFBmnBZrhTVH1bxgtsnZoaWS57PM07z7AE+mbqa5yZ9Ej7ZO4qcwnahrgTMsjpMBhmFW1is+Q==
X-Received: by 2002:a05:600c:4e01:b0:434:f3d8:62d0 with SMTP id 5b1f17b1804b1-438dc3a3e77mr32458195e9.3.1738167947168;
        Wed, 29 Jan 2025 08:25:47 -0800 (PST)
Date: Wed, 29 Jan 2025 17:25:45 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Alejandro Vallejo <alejandro.vallejo@cloud.com>
Cc: xen-devel@lists.xenproject.org, Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>
Subject: Re: [PATCH 0/3] tools/hvmloader: Decouple APIC IDs from vCPU IDs
Message-ID: <Z5pWiYWGv66uXpAm@macbook.local>
References: <20250128163342.1491-1-alejandro.vallejo@cloud.com>
 <Z5kXq2RehzyFEYqA@macbook.local>
 <D7DXEC0N45CT.2JHUHP1XAVB5F@cloud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <D7DXEC0N45CT.2JHUHP1XAVB5F@cloud.com>

On Tue, Jan 28, 2025 at 06:42:38PM +0000, Alejandro Vallejo wrote:
> On Tue Jan 28, 2025 at 5:45 PM GMT, Roger Pau Monné wrote:
> > On Tue, Jan 28, 2025 at 04:33:39PM +0000, Alejandro Vallejo wrote:
> > > The hypervisor, hvmloader and the toolstack currently engage in a shared
> > > assumption that for every vCPU apicid == 2 * vcpuid. This series removes such
> > > assumption from hvmloader, by making it read the APIC ID of each vCPU and
> > > storing it for later use.
> > > 
> > > The last patch prevents writing an MP Tables should we have vCPUs that can not
> > > be represented there. That's at the moment dead code because all vCPUs are
> > > currently representable in 8 bits. This will inavitably stop being true in the
> > > future after we increase the maximum number of guest vCPUs.
> >
> > While I'm fine with the MP Table change, should it also come together
> > with a patch that introduces the code to create x2APIC entries in
> > libacpi construct_madt() helper? (and bumping the MADT revision, as
> > I'm quite sure version 2 didn't have x2APIC entries in the
> > specification).
> 
> That's a lot more involved though. Matt started something in that direction
> last year, but testing it was (and still is) effectively impossible until
> HVM_MAX_VCPUS increases.
> 
>   https://lore.kernel.org/xen-devel/cd1a3ce14790af8c1bb4372ef0be5a6cbbb50b1c.1710338145.git.matthew.barnes@cloud.com/
> 
> The rest of the topo series can be used to test that (with a hack to
> artificially bump the width of thread_id space), I'd rather not test a patch
> with a long and still uncommitted series.
> 
> >
> > Otherwise the MP Table change seems like a red herring, because the
> > MADT created by libacpi will also be incorrect and APIC IDs will wrap in
> > local APIC entries, just like it would on MP Tables.
> >
> > Thanks, Roger.
> 
> My take is that this is strictly better than what we have today by virtue of
> going down from 2 latent bugs to just 1. That said, I don't strictly need it
> for the topo series to advance, so it is (in a sense) optional.

I'm fine with the patch, but it probably wants to mention in the
commit message that MADT tables will still wrap when using APIC IDs >
255, as otherwise it seems MADT is not taken into consideration.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 18:36:17 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 18:36:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879253.1289466 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdCuu-00053Q-DL; Wed, 29 Jan 2025 18:36:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879253.1289466; Wed, 29 Jan 2025 18:36:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdCuu-00053J-9I; Wed, 29 Jan 2025 18:36:00 +0000
Received: by outflank-mailman (input) for mailman id 879253;
 Wed, 29 Jan 2025 18:35:59 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=XMr0=UV=oracle.com=harshvardhan.j.jha@srs-se1.protection.inumbo.net>)
 id 1tdCus-000539-NB
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 18:35:58 +0000
Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com
 [205.220.165.32]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id dfec467b-de6f-11ef-a0e6-8be0dac302b0;
 Wed, 29 Jan 2025 19:35:56 +0100 (CET)
Received: from pps.filterd (m0246617.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 50THYxGV016136;
 Wed, 29 Jan 2025 18:35:52 GMT
Received: from phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com
 (phxpaimrmta01.appoci.oracle.com [138.1.114.2])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 44frus05n3-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 29 Jan 2025 18:35:51 +0000 (GMT)
Received: from pps.filterd
 (phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1])
 by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (8.18.1.2/8.18.1.2)
 with ESMTP id 50THUDKk034375; Wed, 29 Jan 2025 18:35:51 GMT
Received: from nam04-mw2-obe.outbound.protection.outlook.com
 (mail-mw2nam04lp2172.outbound.protection.outlook.com [104.47.73.172])
 by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id
 44cpda337y-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 29 Jan 2025 18:35:50 +0000
Received: from PH7PR10MB6505.namprd10.prod.outlook.com (2603:10b6:510:200::11)
 by SA1PR10MB6494.namprd10.prod.outlook.com (2603:10b6:806:2b4::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8398.18; Wed, 29 Jan
 2025 18:35:48 +0000
Received: from PH7PR10MB6505.namprd10.prod.outlook.com
 ([fe80::83d9:1bf1:52cf:df54]) by PH7PR10MB6505.namprd10.prod.outlook.com
 ([fe80::83d9:1bf1:52cf:df54%6]) with mapi id 15.20.8377.021; Wed, 29 Jan 2025
 18:35:48 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: dfec467b-de6f-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=
	corp-2023-11-20; bh=/L0xt7Uxd0hRTo4eK6IeIZXmUxkd0w7/SWH6iBlniYA=; b=
	a+HnJi2YlJasbG40P49ochtObrCVjPw3Vs51OVqIYvDAQAKr5opDzoX6ruFVCKFi
	tsOzipkVRj4AgHv19Ek1+RLaOmwbfqCHBnf+xJtXKTZkHWDGCW4ShXRVaR/UARZ8
	9XqKNKf8GA9vgGxH6TIkfWitgqxFos7M9ZuAywgk2tZUVZvOmsND1wFeejrP/akj
	aTukxwJkUTzS0D6QpEH92t1OMzgdGggatLUwcDrV62aYTZWWs6X248wbxmCUZqC/
	Q0OXCRIjTBrzgHT05Bjlfr49y8oRJFDv1lby1bGtxo5//7Xj2ERss3cEkaPF1CvE
	bEFqHtb8vYsmBTRE+Mu6VQ==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=kc8JeK8V0hW6+C/0VS7fc/RsK8YsQ56O7ubIisE+MU3TyHYY9P56jqc7Gcwlt4pfXiHLqvAnk9ZRG2kePcth/4QpxTO05yWhSZIVwIU4yW3lSuhgtt+q9U8KsvWuApSf02UPdaS3lCQTRr7z9d90n2DwjLPvOEMY0rZrqjmgc1CULKjlUJR/1rm9NdVrXzfExmlf1sOUVcGgNBeHDWTAiGK4IFAFYv/s60G7xowsShtzwIxTIDKmHTceBzfVuPcGxEnnsajV5ECMfF0HhlimyeaIN4nrlr26n9259M/nOa/zKR4CGFRXx2KlaIElOwoBjUnymQGP5boJzDL/DnYvGw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=/L0xt7Uxd0hRTo4eK6IeIZXmUxkd0w7/SWH6iBlniYA=;
 b=RRLoC4xZrZsjI/wlsU0KNTnSx7WPicVZkQXsU3UXkdT3+cKt2RQDvAP1FzUO2FmpZup7w/3ABJyBHnWWo1L5R6RomXV6e9oK0qr6QBOSTsqb+msn6z+iyel8jqo+l11ap0KnU02b7zBuw/V9jWcuteIXSCeBawppsMjFfwyzoXxWgm/XQcd8GYwxJBLbujEGbnJMoWVLMHRdmdCR8TwgjjYeN1D8Gv4n6Xid98TjfmmCOyJF7AwPeTVkN+WZCVbacf3AzThyKYxxr4q328RbrPsO7v3xaRUWBBssuO/a17CL6SuKjBZuhCWbP5l/vBiV8f+sFed/35oBRG6qoxAdJw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
 dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=/L0xt7Uxd0hRTo4eK6IeIZXmUxkd0w7/SWH6iBlniYA=;
 b=y1K1HokE09iKWc3EHAuZPigZdbCTVbwFPT6ZLyLKA64XruGLsTrVB5QdDxSJMzoJ9rdTWT2rownCssAzP28qnngVD7T6AAXpS1ctiby49eLZ4mX+nOmsueH1kKvZCkg76K+qICacWO2HqUPZEI/y9M8n7l7+IiYDjxUToUuuBeQ=
Message-ID: <b4ab0246-3846-41d1-8e84-64bd7fefc089@oracle.com>
Date: Thu, 30 Jan 2025 00:05:41 +0530
User-Agent: Mozilla Thunderbird
Subject: Re: v5.4.289 failed to boot with error megasas_build_io_fusion 3219
 sge_count (-12) is out of range
To: Juergen Gross <jgross@suse.com>, Greg KH <gregkh@linuxfoundation.org>
Cc: Konrad Wilk <konrad.wilk@oracle.com>,
        Boris Ostrovsky <boris.ostrovsky@oracle.com>,
        "sstabellini@kernel.org" <sstabellini@kernel.org>,
        "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>,
        stable@vger.kernel.org
References: <7dc143fa-4a48-440b-b624-ac57a361ac74@oracle.com>
 <9dd91f6e-1c66-4961-994e-dbda87d69dad@oracle.com>
 <2025012919-series-chaps-856e@gregkh>
 <8eb33b38-23e1-4e43-8952-3f2b05660236@oracle.com>
 <2025012936-finalize-ducktail-c524@gregkh>
 <1f017284-1a29-49d8-b0d9-92409561990e@oracle.com>
 <2025012956-jiffy-condone-3137@gregkh>
 <1f225b8d-d958-4304-829e-8798884d9b6b@oracle.com>
 <83bd90c7-8879-4462-9548-bb5b69cac39e@suse.com>
Content-Language: en-US
From: Harshvardhan Jha <harshvardhan.j.jha@oracle.com>
In-Reply-To: <83bd90c7-8879-4462-9548-bb5b69cac39e@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: SI2PR06CA0001.apcprd06.prod.outlook.com
 (2603:1096:4:186::21) To PH7PR10MB6505.namprd10.prod.outlook.com
 (2603:10b6:510:200::11)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH7PR10MB6505:EE_|SA1PR10MB6494:EE_
X-MS-Office365-Filtering-Correlation-Id: 364ca0e1-e8ba-47f3-0687-08dd4093bfc7
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?aWdvYnFXTm9RZ3NOc3NSalloSndxK09qS0x0WFNRL09MYUZpK2g4SjdhK3Rz?=
 =?utf-8?B?SkY1T0RhOXAvYTV2V291WXRyMWtnSkk1SnR1VFRWVGtkaC8ySWRKYStMQzNZ?=
 =?utf-8?B?c1ZPbDZLbk5heHRra3Z3MkM0MUY0c2dTVkRadW8rNWlUVzBYbXE4ZnMyZ3I4?=
 =?utf-8?B?bnVoZ25ya3RCMjUrejY4WjE3UW9PemlNYVRDRWp6Zm9oUzRnR3haV1l5cnlk?=
 =?utf-8?B?bDBkdldISVYrZnpTL2x0NEVwNUJkL3FWTlhEMWVZR3dWSW9iZTNHWjRTZkFw?=
 =?utf-8?B?TE90N1pPUDMxWXFaSzZUbFN2bUhSaHNUWFNoa2RqbGNKYmY2MkNpQy8yZ2Ns?=
 =?utf-8?B?SGN4Mkk4R0o3ME9TSDMwWFdjRnI2bk9Jc0ZkY3lEL3cwZnBMUHlNOUh2SHIy?=
 =?utf-8?B?aWJOWXU5SzlHbURwV2oxUHNHV3o2WXUzZjhJR0tGdEpHVHgybitLa2tLT3hT?=
 =?utf-8?B?ZS9wZDNpOTVHdjBIZUc5b01jTDNDSXBZQkJ0MEdWUFpUdDVRdFpnKzByWVZX?=
 =?utf-8?B?SVJZTzRhckJHcmdFRzcySWJFWjByWkhIMjRuOXJERGZFSkxDb1FkNjFRWnJ6?=
 =?utf-8?B?bEs0NENvM2tGY0RWZncycXlWazhsSFk3eks3bWU5aHV0bnRYK1ZPbnViWHIy?=
 =?utf-8?B?bUZmUm1OVG5aTjl5eWlUV25LMXZVSzhoRm5wUnFmbU4raGdsd2JkZ1UxclpN?=
 =?utf-8?B?dm9MUkROK3l5eEM2M2xSeXBmUlZ1UTMzN2Y2akxoY1kyMXkzMENQbCttMGpT?=
 =?utf-8?B?NE0vRkljeFJoUlV0U1VMbEpucWppL2J0MWtJZG5WUXk4aGdnYTFYQzBra05u?=
 =?utf-8?B?UGpmdVVHdks0cHowdHFDSk1RRUlTTkplUGxCay9ieUpEeHllS1J1YTQwWjBq?=
 =?utf-8?B?NmE5cjROVUhJYkZzUG1YMk5QS0JmWmYvMUR4SlhJTGZua0JGMGt4SXg3aXZG?=
 =?utf-8?B?RkppSnErYjNSY0EvbmFhd21pRkllK09qSkZuWDNHMUlJQ3F6YWYvdjlWQlM0?=
 =?utf-8?B?SnNMajhlVzlKbzJQTmQyazZGa0tiOXE4d0g5OHRkVU9Oa1dVeXM0bjJkMkVh?=
 =?utf-8?B?cTlNOWZ0VTQ0RVZsNk5WdGYzclVrQlhRTkYwM3g3dzNyRUhlb2F3U3BUZGNJ?=
 =?utf-8?B?aENZajUrZWN2ZmlFWDJSeHVmWVFTVEphOTFaODBtcjFmRTJIZDhiY2NhTjk4?=
 =?utf-8?B?MThGS3E3Q3BGck1WRlBicjJDU0YwTStRR3BQZlJYbjhGeW4vdHZTQnpMdi9w?=
 =?utf-8?B?eS9YNmJ2ZHRqMG1hUUlZUTVndEpsWFBwbnZzSHhITWpkZ2hCTm9TUFRtdmFX?=
 =?utf-8?B?eEtMVmpLSDFocytDYU45YTVrTmM0Y2tBMmRVeTFZc1F0NzlHdXc4WUwyWDJt?=
 =?utf-8?B?ZUg4RWVJUFdSOUpsWDllMHd5eGdBaUViajVyTjNRL0t1ZWh6SEhOd3ZZcnZu?=
 =?utf-8?B?M290aWFJbkpUdTM0djNsYkMyQUY1aElMOTNMZXFmRUttYmtEN3ZqYXkzZWRk?=
 =?utf-8?B?OU00Q29OeEVzOTVDbE13NE84ZFcvODFVRm9zM09nM2NSanZVV0NMR2ZUNk0x?=
 =?utf-8?B?TUJwRGpvNzZ5NzRCYnJuL2lzdy92MGRPb2hHOXltYm45eWJXZVZzTWY2eEtw?=
 =?utf-8?B?Qkk5dDNzZHI0c0tOMkJOK1JnUzMxZHo5dFJWdDJ2Nm8ySmFscWFyRXIyYlVL?=
 =?utf-8?B?QUcwc2Uwams2RlVDS3gvVE5TMEJqZVVYSTN3MzJOTStQdk9WU0ZHdTcyQ2lL?=
 =?utf-8?B?SlRxOHJJSnNwUldpc2RwRGMvUW15ajlqSWowNEhLd3ExTmZwSWNkZFFpLzhw?=
 =?utf-8?B?MkZRdkptTjNMWnRVdFZRdE83Mi93NG9KZGJLcmJYMk1xWGo3MGVqc0l4R0VQ?=
 =?utf-8?Q?nCylZYKdI/YV2?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH7PR10MB6505.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?Tk4weXpwVWU5eWp3OTRBTG9raHQrSmpMdU9yZmh0aVdhYjdEeGN5SUd1RVlZ?=
 =?utf-8?B?TDMzc1RCNEk0K2VLZnFZMjdKNjdDZGd2MHF0VHNQRGI3UUFINDhuZzg0d3lj?=
 =?utf-8?B?dDVqUGhZMVpjV3poTHJBbXd5UitLSVhTRFk4RUxxbCtSUW90Sk9nbndDdFI3?=
 =?utf-8?B?QmRvWVpaeHVJNWx3R0lsOGZPU2Q2OVZjUTE2TGJmM0lJOVZ4YXdzcVpWSGNW?=
 =?utf-8?B?K3RQVEFLVFpnamlrbk93LzlzZHZvZng5bXRzUDQ3dlgxT2ozZmFUcnFteGtL?=
 =?utf-8?B?b0RONlhXc3BwS1duSEhwajZBUzBvOE9qWVFLWWFmMTVKRVg0QjVqYnp5SHkx?=
 =?utf-8?B?TmdsaVdLa2JFQnlzVzNtamo1RWcxOGphVlN3amkwS1FOYVlHZjhjWnlCcjVY?=
 =?utf-8?B?VVhtUFR6anR1dWlzVy9Ba0tjQkc3eXBqNDVaK3VYWXhhd0FIb0ROWnhRdCs5?=
 =?utf-8?B?TzJoWEl2V3FmaWtrb2lndFJDSW1DdUw4SFdWa3A4d2Q5WG1GaG51L3k5dzZK?=
 =?utf-8?B?WDJaM0Y3ZjA0TUFJVDNnVGhwd3p5TXpZZ09zcUtrakl1aXAwcTR5dyt2S3hF?=
 =?utf-8?B?MHhNclRSeExJb2x5Uk91djk3aGhvMkl0SG80OXdQZW94cXhFYnczNmV0V3pV?=
 =?utf-8?B?eVYxUi93L2p2Vit3eUxlK0dpSTFsNTJZdDdOa01MV2ZzNXRCK1BJWDZjTUZm?=
 =?utf-8?B?Wk5xVjN6Q09kSW51dW1IQXJHeWRZMXc3Z2w5UTFXZnRiN09EV0QxU1VXSFpU?=
 =?utf-8?B?K2sxUlpZYytnUTNxQTZqelNmM2N0b3VYMXlVY1pDUlJJRG53VmhGMVYzbFVm?=
 =?utf-8?B?YUQ2d3pqLzFlTXhqYm9OT2JiazMvRDA2ODErYUkzemVkMWtET0piV1Jlb2pQ?=
 =?utf-8?B?LzJrMjdCQVpwOVg2eEVOS0t3WDBKMzg1UWY2cFRIRFpGdVNqb3ZlU2ZER25V?=
 =?utf-8?B?N1QwSVdSSFFpTGNTNG05TWxxNnJOZFhZQnkvRGx4N0FML3VRbFhLMDBzekp6?=
 =?utf-8?B?eWdWd2JzcnFjU2NONCswSFNmL3ZLUzZrWDJTeGVaMEFLdHF1YVh2UzBySGpH?=
 =?utf-8?B?Rk5wcUxzbHAvdzQwK1NvdHVqd3hSZjg3aUd2OUxvZzFUd1k3YWorOHNSS2c4?=
 =?utf-8?B?YUR2Rlc3L1UrVGQxMXV2WE9TZlpnRUZVVkJzK1NyS2ZXaG95QVJTOE4xYXJZ?=
 =?utf-8?B?Vkp3TFM0dm5hdzkzMGhZemV4cm9vYjFmbFdNUkhxSzUvN0dnL3k0c3hKVUVG?=
 =?utf-8?B?QWpmcWxsOFFxNkhUbk9zd2I0aEwvNkhpRUhLc0NGSWk3bko5QkY3bVV3SkYx?=
 =?utf-8?B?ZHZwWjJWejBwQlBpd2pNNHlrWkxBWVptalU4VTdwQmNxQ3BBWER3Mk40cHky?=
 =?utf-8?B?cGtPUFNDanJvVFBTTXdKdHl5a2NiN0xSby93aUdZMHlIU1RWdWE4aStGRGs0?=
 =?utf-8?B?ZjVqZDNOd2tOR1hEaVZCOUM1ZnNjcHllMTk2NWFDVmpSY2daSWdRVlgyNVlN?=
 =?utf-8?B?RUJaRTJPeHE4Z1hhY1krclJDczk2dWltNmZZRG44REtFQkM1bTZUbUhuc1dD?=
 =?utf-8?B?b0FxclNyM0RKNHZseHlpTlVPMGFRQ0VkWWdLVGhtclZxSjNLdTRBbDlRc0ti?=
 =?utf-8?B?NnlJUktkZGtPL0tiYmdJbXpCQU5sZUJEalIwdnBEWm1ZakVMb0J3Vkd2TnZD?=
 =?utf-8?B?M3Q4OXU0OFl2UzQxemJSWUNMVmt1aHZrYmIxeWRFaHhWWkwySUx6OEFQNWh5?=
 =?utf-8?B?aHg5eUFWbU81NnJjRjZtL1EwdDh1MDlPN01hNXZORHBWU2pNUTJObWRRY2hN?=
 =?utf-8?B?NDBrZ1dFb0RhbFlVWGhIYStDU2VyNkdDeGRZaHk0WDlWR3hSTnRVNEZVKzJm?=
 =?utf-8?B?elV3Q1RuZ3lNdTF3SG1CWkYyMWNiYklNNFJSK3cwMXhMRHpiREU1YXc1YXk1?=
 =?utf-8?B?QXRaN3MzMGJrZTFFNEp1ZmVRNTZDcXJqK05mSEpWQVVraEovNkhIM2k2WlJn?=
 =?utf-8?B?NmhQcVpRVDMwbnJpaTRJajJseVFWOGd1NCtwaklDcHNTVlpuQSt4M2NESGdG?=
 =?utf-8?B?aG1DUFZLcVNWWlE1MDV4cVZ2UmxUWTNLeExDdmY0cnZ5ZzVaQzRLejNDWlhl?=
 =?utf-8?B?eG5zalBjd1lkbTBBM2lMeUVISnFpeGUvd1lMSkgrTW8rT1pMdFpBQ290OU9R?=
 =?utf-8?B?Z1E9PQ==?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	he5S/1ykgtEJicMhQ1Ei4sBYTp3PBFpmfiHf0A36TGj8ZxB8D2g5wCTW+BFZtBkVx4lxFK/uvc71PjH2n406WK2+cn3LcCPHfAjHkJuvRAznTMd7GQNevMie//I86O4JDegT6ui+LaHi7cJqsLCW5BJkbXrHtDtKml+z6vJtuy9CrPm38bye/wDuM+A1++rrw8z0q44ZKQkfMRq+JHzBuJRBZbpjlasxaun/jGB49Z02eZrgh+Z2p8AwcQNm8Mr/lNpA28vVpFJkOcGHDEe7qDxCBbHdYps7SuaJaBaz/wt+FYlB0fujio90eWU7DV0x6pIxJEwp7NfCYe+sydd85AmMbGmc8QxCRm6YaavpecN782Qmy27I8bsWoYOpkJiRLoo1KwQP4GbT6OivwTowPEjTsBkE4scxFnsq3GF2T1Th+c0zg0BiyFp3SkBHCnNU3dnxMeupsc+mkdzRv4pkKq3i//LzjrcmW/6r68tRYQGMzqWqoYutRuceKt25bEfQoQTOBFoxXXnLjyGyXwunyX71YdeKZf+qfE4Zf++MqIhiEi0P2t4oayQI97HVxsrqTywJ9citcBYERqi4oVqQiC0OOTyYYA5MrtP6EenXow8=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 364ca0e1-e8ba-47f3-0687-08dd4093bfc7
X-MS-Exchange-CrossTenant-AuthSource: PH7PR10MB6505.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2025 18:35:48.2055
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: ivTVu1P2zFUW66tXQhOb9+wFMZSOYMfpC/40+bmgf17g+bbq102B3dndqmQVhYyI7n3zLuR425QEPqb8+8qD5D9TJeEqeLQvdSO60Z447hY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR10MB6494
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34
 definitions=2025-01-29_04,2025-01-29_01,2024-11-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 bulkscore=0 malwarescore=0
 mlxlogscore=999 suspectscore=0 spamscore=0 mlxscore=0 adultscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2411120000
 definitions=main-2501290146
X-Proofpoint-GUID: 8IBpkIuwoRALM08gG3r7TzxiouYY4wnl
X-Proofpoint-ORIG-GUID: 8IBpkIuwoRALM08gG3r7TzxiouYY4wnl


On 29/01/25 4:52 PM, Juergen Gross wrote:
> On 29.01.25 10:15, Harshvardhan Jha wrote:
>>
>> On 29/01/25 2:34 PM, Greg KH wrote:
>>> On Wed, Jan 29, 2025 at 02:29:48PM +0530, Harshvardhan Jha wrote:
>>>> Hi Greg,
>>>>
>>>> On 29/01/25 2:18 PM, Greg KH wrote:
>>>>> On Wed, Jan 29, 2025 at 02:13:34PM +0530, Harshvardhan Jha wrote:
>>>>>> Hi there,
>>>>>>
>>>>>> On 29/01/25 2:05 PM, Greg KH wrote:
>>>>>>> On Wed, Jan 29, 2025 at 02:03:51PM +0530, Harshvardhan Jha wrote:
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> +stable
>>>>>>>>
>>>>>>>> There seems to be some formatting issues in my log output. I have
>>>>>>>> attached it as a file.
>>>>>>> Confused, what are you wanting us to do here in the stable tree?
>>>>>>>
>>>>>>> thanks,
>>>>>>>
>>>>>>> greg k-h
>>>>>> Since, this is reproducible on 5.4.y I have added stable. The
>>>>>> culprit
>>>>>> commit which upon getting reverted fixes this issue is also
>>>>>> present in
>>>>>> 5.4.y stable.
>>>>> What culprit commit?  I see no information here :(
>>>>>
>>>>> Remember, top-posting is evil...
>>>> My apologies,
>>>>
>>>> The stable tag v5.4.289 seems to fail to boot with the following
>>>> prompt in an infinite loop:
>>>> [   24.427217] megaraid_sas 0000:65:00.0: megasas_build_io_fusion
>>>> 3273 sge_count (-12) is out of range. Range is:  0-256
>>>>
>>>> Reverting the following patch seems to fix the issue:
>>>>
>>>> stable-5.4      : v5.4.285             - 5df29a445f3a xen/swiotlb: add
>>>> alignment check for dma buffers
>>>>
>>>> I tried changing swiotlb grub command line arguments but that didn't
>>>> seem to help much unfortunately and the error was seen again.
>>>>
>>> Ok, can you submit this revert with the information about why it should
>>> not be included in the 5.4.y tree and cc: everyone involved and then we
>>> will be glad to queue it up.
>>>
>>> thanks,
>>>
>>> greg k-h
>>
>> This might be reproducible on other stable trees and mainline as well so
>> we will get it fixed there and I will submit the necessary fix to stable
>> when everything is sorted out on mainline.
>
> Right. Just reverting my patch will trade one error with another one (the
> one which triggered me to write the patch).
>
> There are two possible ways to fix the issue:
>
> - allow larger DMA buffers in xen/swiotlb (today 2MB are the max.
> supported
>   size, the megaraid_sas driver seems to effectively request 4MB)

This seems relatively simpler to implement but I'm not sure whether it's
the most optimal approach

>
> - fix the megaraid_sas driver by splitting up the allocated DMA buffer
> (it is
>   requesting 2.3MB, which will be rounded up to 4MB - it is probably
> not needed
>   to be in one chunk, so a split would result in max. 2MB chunk size)
>
> Both variants have their pros and cons, though.
>
>
> Juergen
Harshvardhan


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 18:36:20 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 18:36:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879255.1289476 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdCvE-0005O8-NF; Wed, 29 Jan 2025 18:36:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879255.1289476; Wed, 29 Jan 2025 18: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 <xen-devel-bounces@lists.xenproject.org>)
	id 1tdCvE-0005O1-JW; Wed, 29 Jan 2025 18:36:20 +0000
Received: by outflank-mailman (input) for mailman id 879255;
 Wed, 29 Jan 2025 18:36:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=PyJd=UV=suse.com=jgross@srs-se1.protection.inumbo.net>)
 id 1tdCvD-0005La-35
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 18:36:19 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ed064e11-de6f-11ef-99a4-01e77a169b0f;
 Wed, 29 Jan 2025 19:36:17 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id B64371F365;
 Wed, 29 Jan 2025 18:36:15 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 6B4BA132FD;
 Wed, 29 Jan 2025 18:36:15 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id R+gCGB91mmfSHQAAD6G6ig
 (envelope-from <jgross@suse.com>); Wed, 29 Jan 2025 18:36:15 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ed064e11-de6f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1738175775; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding;
	bh=jnHLzl4ahT1f8TokqXt7gY58Me4tFxLyl6IKuli4OVE=;
	b=UtbVQtLTrevtYtFwCc6VmFUv5eg9YUi6HBqL490psORPdvQTtZjCfSVrP6alxs/oa0t2Ln
	ZM3x6FlNnCDwYkuiRtAw3IAFjeiucyIEvLJxxedixvzx+HDgmPt57ht3tgAgI21RckCo6+
	YUUuLhgkp6DxApdQ9AsrSy7318Dxa1s=
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=UtbVQtLT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1738175775; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding;
	bh=jnHLzl4ahT1f8TokqXt7gY58Me4tFxLyl6IKuli4OVE=;
	b=UtbVQtLTrevtYtFwCc6VmFUv5eg9YUi6HBqL490psORPdvQTtZjCfSVrP6alxs/oa0t2Ln
	ZM3x6FlNnCDwYkuiRtAw3IAFjeiucyIEvLJxxedixvzx+HDgmPt57ht3tgAgI21RckCo6+
	YUUuLhgkp6DxApdQ9AsrSy7318Dxa1s=
From: Juergen Gross <jgross@suse.com>
To: torvalds@linux-foundation.org
Cc: linux-kernel@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	sstabellini@kernel.org
Subject: [GIT PULL] xen: branch for v6.14-rc1
Date: Wed, 29 Jan 2025 19:36:12 +0100
Message-ID: <20250129183614.2601-1-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: B64371F365
X-Spam-Level: 
X-Spamd-Result: default: False [-3.51 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	RCVD_TLS_ALL(0.00)[];
	ASN(0.00)[asn:25478, ipnet:::/0, country:RU];
	ARC_NA(0.00)[];
	SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	MIME_TRACE(0.00)[0:+];
	RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns,suse.com:dkim,suse.com:mid];
	RCPT_COUNT_THREE(0.00)[4];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_NONE(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	DKIM_TRACE(0.00)[suse.com:+]
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Rspamd-Action: no action
X-Spam-Score: -3.51
X-Spam-Flag: NO

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-6.14-rc1-tag

xen: branch for v6.14-rc1

It contains 3 minor fixes.


Thanks.

Juergen

 arch/x86/xen/mmu_pv.c       |  4 ++++
 drivers/xen/pcpu.c          |  2 +-
 drivers/xen/pvcalls-front.c | 14 ++++++++++++--
 drivers/xen/pvcalls-front.h |  2 +-
 4 files changed, 18 insertions(+), 4 deletions(-)

Maksym Planeta (1):
      Grab mm lock before grabbing pt lock

Sergio Miguéns Iglesias (1):
      xen: pcpu: remove unnecessary __ref annotation

Stefano Stabellini (1):
      xen: update pvcalls_front_accept prototype


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 18:43:57 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 18:43:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879272.1289486 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdD2W-0007HW-Dl; Wed, 29 Jan 2025 18:43:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879272.1289486; Wed, 29 Jan 2025 18:43:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdD2W-0007HP-9u; Wed, 29 Jan 2025 18:43:52 +0000
Received: by outflank-mailman (input) for mailman id 879272;
 Wed, 29 Jan 2025 18:43: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 <SRS0=PyJd=UV=suse.com=jgross@srs-se1.protection.inumbo.net>)
 id 1tdD2U-0007HG-Pf
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 18:43:50 +0000
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com
 [2a00:1450:4864:20::334])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id fa94118d-de70-11ef-a0e6-8be0dac302b0;
 Wed, 29 Jan 2025 19:43:49 +0100 (CET)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-43625c4a50dso48957425e9.0
 for <xen-devel@lists.xenproject.org>; Wed, 29 Jan 2025 10:43:49 -0800 (PST)
Received: from ?IPV6:2003:e5:8731:2800:842d:42a0:5992:3595?
 (p200300e587312800842d42a059923595.dip0.t-ipconnect.de.
 [2003:e5:8731:2800:842d:42a0:5992:3595])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38c2a1bb057sm18043945f8f.62.2025.01.29.10.43.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 29 Jan 2025 10:43:48 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: fa94118d-de70-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738176229; x=1738781029; darn=lists.xenproject.org;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=vujb+9AK4crOXTLq1PEpcebpri0tORkVUFtuFQHx3JA=;
        b=Br6uUCPP5N8C8mXEi0z3lFXrh2Q4w2TmLIVspfeaEFJLN86/d5zNikK6ZrW71ng9mp
         5qleNqlbEemEY2Qd4R/cgkgx86Shkz0WtMby2Ij+Khdb3TDbpT6gzcTj6jMVvFZdQe1N
         1+4aSlzRH7EM9fSesOTbKl6fc6oxlgwyH6xr0d78URWkCUay2MJDdOiMtlj9np4FI1SR
         OKZATe6ztP6ocw8pKyhFMz8z8Syjnl7eFYqURZLd0WmY8lCEiI7Hd3WzWeTwTZpEQqYr
         vf4kPaLENwBDavoQqom3o9vvqK3XtxfX9Otz08BOglJPtkA+9z1SXpbSdskp50eY+vBP
         krUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738176229; x=1738781029;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=vujb+9AK4crOXTLq1PEpcebpri0tORkVUFtuFQHx3JA=;
        b=hAkIkMzOIF+dZ/Kr2yvieGH3sSXNlMZDhqP+a5VT6iIMs6IHtXRd7tfZVEhMrPEjvz
         OUEIfQuwallIl9BzfUIJF8uvKRttkEec6n5c7TFuRYfNuwTMT6eri2zcJc2E2yLnnME/
         nnvLR4ahjILRsFKrfvI8EEMlVWjhgWx5DjmSP3B25ElJWeI/f6QeVHImjgP5MsCkxfel
         um6DeLfGGrjlvJgNP/ZV/vLp2KRNBCm/ZKCJkv6YqyYB2KWwBTlEUtmh4lYILDpR880Q
         cejk2nLynwE+fLP8Bmirkx7ESDIE1InZzGzKU6hbSkW4nbz/h1icaS0zW2ULQlknwU9G
         TlhQ==
X-Forwarded-Encrypted: i=1; AJvYcCVjkM8QaPfUAAk/MfMlvzAoQmYNyVwxWAHcHrUhWV+A4Wj0e68vpZjZyCv0pWhtE3mJxlpbfhh0ocQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwUZ+uRiroweG0sip8WHYXJyaW8JH/Kqy77iGfnz6WVMvmpTuYs
	6z7NEUR+y8QnLTSN2ASscZjn5cygEQl+0AUP+CerPHHTZvPt9KW3VAu8pkDPaY4=
X-Gm-Gg: ASbGncvLcxm33zjx9jW+sGSJTdg58d23vHhEF1pMA1frhQVlPAiiqEOIB3nhuMcgqUv
	h5LuPEnefJbBeowjX1jy1RiUyrXFuAXLj/wiGG/wML29Wip2wrEJuz8SaqbHgA1d5VTLZYchzbi
	0y0xFN51AE2ukoPzwTzyV0ngCqGnAcCDtQzgeELk+gXtiqYUo4q+rG9dfNdVc8LsAnroxnmUamA
	wj42TZIktyDHkIq9+FT9/P2jFy5qMI2ZWTmmw8wpqXlXvZe6DKsZFvk7vOdssiw6ar65iyIG6HJ
	hitJS8dB0Y8yl92jmn8BL5uPhAhOUEfc9Ajm2WCr8YOEtS03Edo59BUH2xdcavcK92eeYTHwm7e
	h7+lL3l1GuP2eMmgQjOPWfkglTYuUWZiAEjPeyEIm
X-Google-Smtp-Source: AGHT+IHgD8Ep2OArSU5wrkaW+rK7D6rY81vY58fc9DyqNv+GloKfGvmf3h6C32qiwSQh6RhcsjvvJA==
X-Received: by 2002:a05:6000:144d:b0:386:380d:2cac with SMTP id ffacd0b85a97d-38c5195f9afmr3689253f8f.26.1738176228778;
        Wed, 29 Jan 2025 10:43:48 -0800 (PST)
Message-ID: <de6912ad-3dba-4d66-8ca2-71a0aa09172c@suse.com>
Date: Wed, 29 Jan 2025 19:43:46 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: v5.4.289 failed to boot with error megasas_build_io_fusion 3219
 sge_count (-12) is out of range
To: Harshvardhan Jha <harshvardhan.j.jha@oracle.com>,
 Greg KH <gregkh@linuxfoundation.org>
Cc: Konrad Wilk <konrad.wilk@oracle.com>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 "sstabellini@kernel.org" <sstabellini@kernel.org>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
 Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>,
 stable@vger.kernel.org
References: <7dc143fa-4a48-440b-b624-ac57a361ac74@oracle.com>
 <9dd91f6e-1c66-4961-994e-dbda87d69dad@oracle.com>
 <2025012919-series-chaps-856e@gregkh>
 <8eb33b38-23e1-4e43-8952-3f2b05660236@oracle.com>
 <2025012936-finalize-ducktail-c524@gregkh>
 <1f017284-1a29-49d8-b0d9-92409561990e@oracle.com>
 <2025012956-jiffy-condone-3137@gregkh>
 <1f225b8d-d958-4304-829e-8798884d9b6b@oracle.com>
 <83bd90c7-8879-4462-9548-bb5b69cac39e@suse.com>
 <b4ab0246-3846-41d1-8e84-64bd7fefc089@oracle.com>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <b4ab0246-3846-41d1-8e84-64bd7fefc089@oracle.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------hxwhKIYd1pkGoQAV7kXHVMQ2"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------hxwhKIYd1pkGoQAV7kXHVMQ2
Content-Type: multipart/mixed; boundary="------------80lROOcx70M4JuOF53eX5CJm";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: Harshvardhan Jha <harshvardhan.j.jha@oracle.com>,
 Greg KH <gregkh@linuxfoundation.org>
Cc: Konrad Wilk <konrad.wilk@oracle.com>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 "sstabellini@kernel.org" <sstabellini@kernel.org>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
 Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>,
 stable@vger.kernel.org
Message-ID: <de6912ad-3dba-4d66-8ca2-71a0aa09172c@suse.com>
Subject: Re: v5.4.289 failed to boot with error megasas_build_io_fusion 3219
 sge_count (-12) is out of range
References: <7dc143fa-4a48-440b-b624-ac57a361ac74@oracle.com>
 <9dd91f6e-1c66-4961-994e-dbda87d69dad@oracle.com>
 <2025012919-series-chaps-856e@gregkh>
 <8eb33b38-23e1-4e43-8952-3f2b05660236@oracle.com>
 <2025012936-finalize-ducktail-c524@gregkh>
 <1f017284-1a29-49d8-b0d9-92409561990e@oracle.com>
 <2025012956-jiffy-condone-3137@gregkh>
 <1f225b8d-d958-4304-829e-8798884d9b6b@oracle.com>
 <83bd90c7-8879-4462-9548-bb5b69cac39e@suse.com>
 <b4ab0246-3846-41d1-8e84-64bd7fefc089@oracle.com>
In-Reply-To: <b4ab0246-3846-41d1-8e84-64bd7fefc089@oracle.com>

--------------80lROOcx70M4JuOF53eX5CJm
Content-Type: multipart/mixed; boundary="------------fbrRPcU8KCB0bqfRa42nAMbp"

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

T24gMjkuMDEuMjUgMTk6MzUsIEhhcnNodmFyZGhhbiBKaGEgd3JvdGU6DQo+IA0KPiBPbiAy
OS8wMS8yNSA0OjUyIFBNLCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0KPj4gT24gMjkuMDEuMjUg
MTA6MTUsIEhhcnNodmFyZGhhbiBKaGEgd3JvdGU6DQo+Pj4NCj4+PiBPbiAyOS8wMS8yNSAy
OjM0IFBNLCBHcmVnIEtIIHdyb3RlOg0KPj4+PiBPbiBXZWQsIEphbiAyOSwgMjAyNSBhdCAw
MjoyOTo0OFBNICswNTMwLCBIYXJzaHZhcmRoYW4gSmhhIHdyb3RlOg0KPj4+Pj4gSGkgR3Jl
ZywNCj4+Pj4+DQo+Pj4+PiBPbiAyOS8wMS8yNSAyOjE4IFBNLCBHcmVnIEtIIHdyb3RlOg0K
Pj4+Pj4+IE9uIFdlZCwgSmFuIDI5LCAyMDI1IGF0IDAyOjEzOjM0UE0gKzA1MzAsIEhhcnNo
dmFyZGhhbiBKaGEgd3JvdGU6DQo+Pj4+Pj4+IEhpIHRoZXJlLA0KPj4+Pj4+Pg0KPj4+Pj4+
PiBPbiAyOS8wMS8yNSAyOjA1IFBNLCBHcmVnIEtIIHdyb3RlOg0KPj4+Pj4+Pj4gT24gV2Vk
LCBKYW4gMjksIDIwMjUgYXQgMDI6MDM6NTFQTSArMDUzMCwgSGFyc2h2YXJkaGFuIEpoYSB3
cm90ZToNCj4+Pj4+Pj4+PiBIaSBBbGwsDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiArc3RhYmxl
DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBUaGVyZSBzZWVtcyB0byBiZSBzb21lIGZvcm1hdHRp
bmcgaXNzdWVzIGluIG15IGxvZyBvdXRwdXQuIEkgaGF2ZQ0KPj4+Pj4+Pj4+IGF0dGFjaGVk
IGl0IGFzIGEgZmlsZS4NCj4+Pj4+Pj4+IENvbmZ1c2VkLCB3aGF0IGFyZSB5b3Ugd2FudGlu
ZyB1cyB0byBkbyBoZXJlIGluIHRoZSBzdGFibGUgdHJlZT8NCj4+Pj4+Pj4+DQo+Pj4+Pj4+
PiB0aGFua3MsDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gZ3JlZyBrLWgNCj4+Pj4+Pj4gU2luY2Us
IHRoaXMgaXMgcmVwcm9kdWNpYmxlIG9uIDUuNC55IEkgaGF2ZSBhZGRlZCBzdGFibGUuIFRo
ZQ0KPj4+Pj4+PiBjdWxwcml0DQo+Pj4+Pj4+IGNvbW1pdCB3aGljaCB1cG9uIGdldHRpbmcg
cmV2ZXJ0ZWQgZml4ZXMgdGhpcyBpc3N1ZSBpcyBhbHNvDQo+Pj4+Pj4+IHByZXNlbnQgaW4N
Cj4+Pj4+Pj4gNS40Lnkgc3RhYmxlLg0KPj4+Pj4+IFdoYXQgY3VscHJpdCBjb21taXQ/wqAg
SSBzZWUgbm8gaW5mb3JtYXRpb24gaGVyZSA6KA0KPj4+Pj4+DQo+Pj4+Pj4gUmVtZW1iZXIs
IHRvcC1wb3N0aW5nIGlzIGV2aWwuLi4NCj4+Pj4+IE15IGFwb2xvZ2llcywNCj4+Pj4+DQo+
Pj4+PiBUaGUgc3RhYmxlIHRhZyB2NS40LjI4OSBzZWVtcyB0byBmYWlsIHRvIGJvb3Qgd2l0
aCB0aGUgZm9sbG93aW5nDQo+Pj4+PiBwcm9tcHQgaW4gYW4gaW5maW5pdGUgbG9vcDoNCj4+
Pj4+IFvCoMKgIDI0LjQyNzIxN10gbWVnYXJhaWRfc2FzIDAwMDA6NjU6MDAuMDogbWVnYXNh
c19idWlsZF9pb19mdXNpb24NCj4+Pj4+IDMyNzMgc2dlX2NvdW50ICgtMTIpIGlzIG91dCBv
ZiByYW5nZS4gUmFuZ2UgaXM6wqAgMC0yNTYNCj4+Pj4+DQo+Pj4+PiBSZXZlcnRpbmcgdGhl
IGZvbGxvd2luZyBwYXRjaCBzZWVtcyB0byBmaXggdGhlIGlzc3VlOg0KPj4+Pj4NCj4+Pj4+
IHN0YWJsZS01LjTCoMKgwqDCoMKgIDogdjUuNC4yODXCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqAgLSA1ZGYyOWE0NDVmM2EgeGVuL3N3aW90bGI6IGFkZA0KPj4+Pj4gYWxpZ25tZW50IGNo
ZWNrIGZvciBkbWEgYnVmZmVycw0KPj4+Pj4NCj4+Pj4+IEkgdHJpZWQgY2hhbmdpbmcgc3dp
b3RsYiBncnViIGNvbW1hbmQgbGluZSBhcmd1bWVudHMgYnV0IHRoYXQgZGlkbid0DQo+Pj4+
PiBzZWVtIHRvIGhlbHAgbXVjaCB1bmZvcnR1bmF0ZWx5IGFuZCB0aGUgZXJyb3Igd2FzIHNl
ZW4gYWdhaW4uDQo+Pj4+Pg0KPj4+PiBPaywgY2FuIHlvdSBzdWJtaXQgdGhpcyByZXZlcnQg
d2l0aCB0aGUgaW5mb3JtYXRpb24gYWJvdXQgd2h5IGl0IHNob3VsZA0KPj4+PiBub3QgYmUg
aW5jbHVkZWQgaW4gdGhlIDUuNC55IHRyZWUgYW5kIGNjOiBldmVyeW9uZSBpbnZvbHZlZCBh
bmQgdGhlbiB3ZQ0KPj4+PiB3aWxsIGJlIGdsYWQgdG8gcXVldWUgaXQgdXAuDQo+Pj4+DQo+
Pj4+IHRoYW5rcywNCj4+Pj4NCj4+Pj4gZ3JlZyBrLWgNCj4+Pg0KPj4+IFRoaXMgbWlnaHQg
YmUgcmVwcm9kdWNpYmxlIG9uIG90aGVyIHN0YWJsZSB0cmVlcyBhbmQgbWFpbmxpbmUgYXMg
d2VsbCBzbw0KPj4+IHdlIHdpbGwgZ2V0IGl0IGZpeGVkIHRoZXJlIGFuZCBJIHdpbGwgc3Vi
bWl0IHRoZSBuZWNlc3NhcnkgZml4IHRvIHN0YWJsZQ0KPj4+IHdoZW4gZXZlcnl0aGluZyBp
cyBzb3J0ZWQgb3V0IG9uIG1haW5saW5lLg0KPj4NCj4+IFJpZ2h0LiBKdXN0IHJldmVydGlu
ZyBteSBwYXRjaCB3aWxsIHRyYWRlIG9uZSBlcnJvciB3aXRoIGFub3RoZXIgb25lICh0aGUN
Cj4+IG9uZSB3aGljaCB0cmlnZ2VyZWQgbWUgdG8gd3JpdGUgdGhlIHBhdGNoKS4NCj4+DQo+
PiBUaGVyZSBhcmUgdHdvIHBvc3NpYmxlIHdheXMgdG8gZml4IHRoZSBpc3N1ZToNCj4+DQo+
PiAtIGFsbG93IGxhcmdlciBETUEgYnVmZmVycyBpbiB4ZW4vc3dpb3RsYiAodG9kYXkgMk1C
IGFyZSB0aGUgbWF4Lg0KPj4gc3VwcG9ydGVkDQo+PiAgwqAgc2l6ZSwgdGhlIG1lZ2FyYWlk
X3NhcyBkcml2ZXIgc2VlbXMgdG8gZWZmZWN0aXZlbHkgcmVxdWVzdCA0TUIpDQo+IA0KPiBU
aGlzIHNlZW1zIHJlbGF0aXZlbHkgc2ltcGxlciB0byBpbXBsZW1lbnQgYnV0IEknbSBub3Qg
c3VyZSB3aGV0aGVyIGl0J3MNCj4gdGhlIG1vc3Qgb3B0aW1hbCBhcHByb2FjaA0KDQpKdXN0
IG1ha2luZyB0aGUgc3RhdGljIGFycmF5IGxhcmdlciB1c2VkIHRvIGhvbGQgdGhlIGZyYW1l
IG51bWJlcnMgZm9yIHRoZQ0KYnVmZmVyIHNlZW1zIHRvIGJlIGEgd2FzdGUgb2YgbWVtb3J5
IGZvciBtb3N0IGNvbmZpZ3VyYXRpb25zLg0KDQpJJ20gdGhpbmtpbmcgb2YgYW4gYWxsb2Nh
dGVkIGFycmF5IHVzaW5nIHRoZSBtYXggbmVlZGVkIHNpemUgKHJlcGxhY2UgYQ0KZm9ybWVy
IGJ1ZmZlciB3aXRoIGEgbGFyZ2VyIG9uZSBpZiBuZWVkZWQpLg0KDQoNCkp1ZXJnZW4NCg0K
SnVlcmdlbg0K
--------------fbrRPcU8KCB0bqfRa42nAMbp
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

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

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

--------------fbrRPcU8KCB0bqfRa42nAMbp--

--------------80lROOcx70M4JuOF53eX5CJm--

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

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

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmeaduMFAwAAAAAACgkQsN6d1ii/Ey+P
mQf/aC4bQU+adCDHWz6U4lrd09wekr6XsxNQaxZaunJ7qs4fj6FUwEk0mNv2mR5mJI1tbfGCu1j3
YyYihiDYzWbOdu8raVpF+rP7lOswGqqumpgkTaj6Y4z4TEy6zVWK7xGwDzVaMQB1ogLxv5rVUx+R
XnNaAI5SteZpFDfzyWwmE6/t0Ahn0juC544A8X4EY/DPVmmcpdIOeek8Sfz4kMeJSdYUlsRFoNH3
BleJDVvgmObfwjI+LKyVwm1qSkIvv9587D3lD30p6XHOyS3XKFtSWkDhRPSNhFXoIE4DFk+I1elw
2YCEPbWAlSVfg18hFa9bJt8XzC2i4nA9INpYatVaWA==
=KLOL
-----END PGP SIGNATURE-----

--------------hxwhKIYd1pkGoQAV7kXHVMQ2--


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 18:47:16 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 18:47:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879280.1289495 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdD5m-0007pO-QU; Wed, 29 Jan 2025 18:47:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879280.1289495; Wed, 29 Jan 2025 18:47:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdD5m-0007pH-Nv; Wed, 29 Jan 2025 18:47:14 +0000
Received: by outflank-mailman (input) for mailman id 879280;
 Wed, 29 Jan 2025 18:47: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
 <SRS0=XMr0=UV=oracle.com=harshvardhan.j.jha@srs-se1.protection.inumbo.net>)
 id 1tdD5k-0007oi-Pn
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 18:47:12 +0000
Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com
 [205.220.177.32]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7217e110-de71-11ef-99a4-01e77a169b0f;
 Wed, 29 Jan 2025 19:47:10 +0100 (CET)
Received: from pps.filterd (m0246632.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 50TIBnvs020264;
 Wed, 29 Jan 2025 18:47:06 GMT
Received: from iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com
 (iadpaimrmta03.appoci.oracle.com [130.35.103.27])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 44fsd50294-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 29 Jan 2025 18:47:05 +0000 (GMT)
Received: from pps.filterd
 (iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
 by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.2/8.18.1.2)
 with ESMTP id 50TIW8s5035807; Wed, 29 Jan 2025 18:47:05 GMT
Received: from nam02-dm3-obe.outbound.protection.outlook.com
 (mail-dm3nam02lp2048.outbound.protection.outlook.com [104.47.56.48])
 by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id
 44cpdg62jh-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 29 Jan 2025 18:47:05 +0000
Received: from PH7PR10MB6505.namprd10.prod.outlook.com (2603:10b6:510:200::11)
 by CY8PR10MB6441.namprd10.prod.outlook.com (2603:10b6:930:63::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8398.17; Wed, 29 Jan
 2025 18:47:03 +0000
Received: from PH7PR10MB6505.namprd10.prod.outlook.com
 ([fe80::83d9:1bf1:52cf:df54]) by PH7PR10MB6505.namprd10.prod.outlook.com
 ([fe80::83d9:1bf1:52cf:df54%6]) with mapi id 15.20.8377.021; Wed, 29 Jan 2025
 18:47:03 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 7217e110-de71-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=
	corp-2023-11-20; bh=fXihcpqS+x95zAr1jBDbDMai1Oe69FEkg4pc+6YQS9k=; b=
	WcQ1osbDZmzV8M7xHnLirHxVdS741qNzT0CwH3wkiJlRaikKZuHbACvnKPW+7PbR
	kKgGkN2SVUnWX/cwQf21PUrurUPaLeKkjJaIZ02A6ReGGjRzt8tt1pm9oaSrUr2L
	gW+ODEcMYu65/MK3gANCrBF5/i9G9iq8FPucGGJ8nRC0yVV0o5VFj/W5+cy7y9VP
	HG/9T4ggnn0Iv0xIReV/LQtwMrTjCk22MJkDWIciG4zGp+ee2INGcXq4aodXFPkO
	1KnB4HG/DZunUZzO55bkObWfnfZUkAEubbnLq33DVC+FIhod9t5Y5TLfDC3u4V+O
	mIndhecrbG2E2XGmCVtjOQ==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=R/CfoE8zxXowtKYgUUVbn9dbtE6eqrbkHBvxmfU5VfDzVWiCbk/qis71MP1Npe8Nba56Wg55YUaLqV4GGSFa3RZLboCqRzi5FPYbuCCB3EH0wdxo6M4YZ634V+6xPTIw8D5f5dwm/btju1/g2PSMBBl94Bh/r4celdgF6DF/tmVcwbnQ+eGkR1NP0XkYUWlf+uxKohGrY2bd1aH+pmQt6RljnSlzft1zI/wS+m+Bg4iTL6FM8wzA2/7MoTlAOJ0ORdckTtBVz7m+B5UHpZtCcvLqZ8gHIINDlyxon8xrywn7htSFHVN9TVfHLZ2p8NT3fhq3zn6CZe/LhzgPlqwdFQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=fXihcpqS+x95zAr1jBDbDMai1Oe69FEkg4pc+6YQS9k=;
 b=v+rGPbsK1aZABIpGjbyIKDgKEoJsTe2o2STiF3/sByl1st2ee3qjGRqqibWWijA5fMOINFajpacLVjlm9fwbendno+NbsIZX2faar4DpZtbQATaz6L6h+h4xZyPL86sZv21hUY9Iqqo0eCZCUvKBMT6Fhhp3eNAhyrgZc5sAhoFSTcBI9HvGjiiyLSLVNEN8ghF0FfUXRdrRF6cX/5fZHSwqQ+1TqQi0jQafTLfJDfdGrjmkm9LLmCuQEEoEnzbE1j0wf2lQs4tfucoWLfWbjUMscER2UVzwR+GGWOb8QPybhtlyhyWcPE0367PAxG57QG2kehB/xXEOWwZ2/pA9wg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
 dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=fXihcpqS+x95zAr1jBDbDMai1Oe69FEkg4pc+6YQS9k=;
 b=OOBmonYVpUPCn6HEJfDe+hKK/YUglpXkga35h68fi/MQmhqmuXzKGNNdPSRn2pWmDxt/9w7sw3qBo4Mxps5f9awc1USPmUHza/WkSqikb+6+OtVefrTCY8Fseg8toSjGs6AX2Re2mLCeKirvPV+evkMwR3PKLjR2AFOUeed2/70=
Message-ID: <686986a0-c981-4aa3-ae88-92a34368129e@oracle.com>
Date: Thu, 30 Jan 2025 00:16:56 +0530
User-Agent: Mozilla Thunderbird
Subject: Re: v5.4.289 failed to boot with error megasas_build_io_fusion 3219
 sge_count (-12) is out of range
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
        Greg KH <gregkh@linuxfoundation.org>
Cc: Konrad Wilk <konrad.wilk@oracle.com>,
        Boris Ostrovsky <boris.ostrovsky@oracle.com>,
        "sstabellini@kernel.org" <sstabellini@kernel.org>,
        "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>,
        stable@vger.kernel.org
References: <7dc143fa-4a48-440b-b624-ac57a361ac74@oracle.com>
 <9dd91f6e-1c66-4961-994e-dbda87d69dad@oracle.com>
 <2025012919-series-chaps-856e@gregkh>
 <8eb33b38-23e1-4e43-8952-3f2b05660236@oracle.com>
 <2025012936-finalize-ducktail-c524@gregkh>
 <1f017284-1a29-49d8-b0d9-92409561990e@oracle.com>
 <2025012956-jiffy-condone-3137@gregkh>
 <1f225b8d-d958-4304-829e-8798884d9b6b@oracle.com>
 <83bd90c7-8879-4462-9548-bb5b69cac39e@suse.com>
 <b4ab0246-3846-41d1-8e84-64bd7fefc089@oracle.com>
 <de6912ad-3dba-4d66-8ca2-71a0aa09172c@suse.com>
Content-Language: en-US
From: Harshvardhan Jha <harshvardhan.j.jha@oracle.com>
In-Reply-To: <de6912ad-3dba-4d66-8ca2-71a0aa09172c@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: SI2PR01CA0035.apcprd01.prod.exchangelabs.com
 (2603:1096:4:192::13) To PH7PR10MB6505.namprd10.prod.outlook.com
 (2603:10b6:510:200::11)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH7PR10MB6505:EE_|CY8PR10MB6441:EE_
X-MS-Office365-Filtering-Correlation-Id: d9c6b9c9-7ff1-4705-046c-08dd40955218
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?OFFzRExrT1k1SlF0RGcvZDhKcnFZQTJDcU1DQnV4Wmp6R3M3M2NsMitBTTZG?=
 =?utf-8?B?SXVhVTRWdmtPWE92ajNwWDNRelRuTW5Oc21xOXk3YXhBREhyOURueHNHaHJs?=
 =?utf-8?B?THdSeE8xdUFwdjZuS2VBQ2dZVFVSalQvYUN4bG52QW9Sb3pwSmgvQkltMWdT?=
 =?utf-8?B?N0lvWnRMSnJnN0V1ZXdYM080RzBxZFppZjVMWU95V3VxYmppVlpSY0YrcTZD?=
 =?utf-8?B?dWVYbmI5ZmpHN1FEaWprcC9tZTVaWTNlQXhMVEFmekQ5b3JjWmJNZGtOZ2lp?=
 =?utf-8?B?SGVMTk53K1RWZm1YMUQ0U05NK3FNVm9KaG9GaE1aMFFybXNFNnVnK05RRVpj?=
 =?utf-8?B?MXFUbFcwdXFZK09SSWQyWUIvRnJ6eVdrYVUwRzJISkxQOXZFaVVRc0VVUk9j?=
 =?utf-8?B?ZGU3MHQrYUdWeG9DaGlRV3UzWTNTYTlvWDZLdVRpMkpvS0R1dlpJakFCVTZD?=
 =?utf-8?B?eHdXbXphZVlzVEd5M0ZteHJEbTRadnd6bXdFVllmYzRnSjV5bUdzY05qYVlu?=
 =?utf-8?B?SFNuRzJNenpZNXNxcHJkUURSeEt1bHR4Vld1LzlRSWRlNU1Vd1pUNm5LL0l3?=
 =?utf-8?B?NWlkdk10WkhvUjdpVmVwNFV1aUJ1VjFZZFFEcFZ1ajZsNkd1RHA3TFRCcGg1?=
 =?utf-8?B?cGp5bEM1VWVlYTlsWWwwUjUzYWp1RjcyNHlhNzRlQXNHVUc3eitlS2xFL3ZE?=
 =?utf-8?B?MDl0L1pZZGRxTWdRM09LL0FsY21OOVZiSk9rQTdpd2UrcDJmL3ZTUnd6Umcz?=
 =?utf-8?B?Z09XR2R6RFNZaVhZTFdlcGZzM2JRMzZ0TVJBdC91UmhBWmorbzhuaVRtemR0?=
 =?utf-8?B?Y3NjQTVrZVhKcmpUMzBnV0VwYTlnNWZnblMySWcrN2QrUHdEUW91ZnRHSXg3?=
 =?utf-8?B?Qm96RDhIUDFNMy9aNFFzSzBLdVZNTzhsOUVlQld2Qkg5Y3ZnN3Aya3kvcGVr?=
 =?utf-8?B?T0ZrWHYva0xPU0RKSEQ5azBwNVBhMytnekJhQUdYeHVqWTM3M01Ja0szVnk1?=
 =?utf-8?B?OG5waERDQlpQZDNsVEVVdUxVTVZKdUkxcmhPdDN4cG15TzZVRVhwQmQ5cEhT?=
 =?utf-8?B?aVd2NTFMMHBWUmJOVWpoVGJqbzB4R1NCQnlQd2sxNVlXc214N09NZWNRcGli?=
 =?utf-8?B?REh2UHJPQ3MxZWpDYzRIc0VjT2ZIUlRqa0VTM1NCbDBvMTVLK3ZGeVJocC83?=
 =?utf-8?B?YS92cFkzbjVtUmJwU2IxcnVncmtVZUc3V1B2b3p0WHJBdGlxTU1oVHUrcmJt?=
 =?utf-8?B?SEloQ0JjM0kxcHNkdzlUS2dWYnJYL0tqMXp1RER0Q0JQNFFZbDR5QVdGd2JL?=
 =?utf-8?B?L1Mzc1ZqMVc4LzBmQ2t6NWRZcmQ1cnIvM3lPZWV0b3Z6c1c4SDdNRzRmam5t?=
 =?utf-8?B?RHdFMGVidzEvaWhqbWl4M1YxbE1JbmZuOTNGNlI3S05qazFlNnRIOGNManZS?=
 =?utf-8?B?VzhOYWN2eWJmeU02WE5TcTV2UmY3cExJRmgvOUVSR0JJK05pT2tGcmlDejMy?=
 =?utf-8?B?b1hjaXFSSGRHSXMvQnpGSjdMeUpvenZHNzgxUVRrWjVCalpqMVR1STBTMVJ6?=
 =?utf-8?B?UlJHUmlOUUdCT1RtUlJLQ2s1cytNdSthRXFNTVNUNXg4Tk5WWXBROGFZbm1w?=
 =?utf-8?B?TFhxcm9CSUY1L0J4L0NxeTluY0I3Ym9HMGFRdzNLTnI3Q2VUU2RJQXIxSDZz?=
 =?utf-8?B?K2ZqUmhFaXJ1STVWd1I3R2tTUE5aOGpDb0hESDdlRWFKa21ISHJCWU51OXE0?=
 =?utf-8?B?YzFtd0ROeUtUOWZGNkFoMnlYdG92TkpxdUIxV1FkN3R6YlBvNTg1Mjg0TEU0?=
 =?utf-8?B?bkdHR1EwL3JNQmFyVFJidHFPaWtUSThPK0VMRmJLVEtlQmk4NldnbEJvNENa?=
 =?utf-8?Q?JJz1QohbKhRXm?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH7PR10MB6505.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?QXRrRkNQSGM5VVBmU0pXQzNqQlZsdXYyRVFwZU1ETHVRdU5iekV1Y3R6MHVF?=
 =?utf-8?B?VU5MbklCR1dGZDRka3RkWC9LNXpvRHV0TlVEN2NaODl3ampidVp5YU5hdmRo?=
 =?utf-8?B?eE9QeUIyZFlabjFMUnREeFFVcVZ6WXNTbDNQakxJZmtkNnNLa1J4OWQzb1h4?=
 =?utf-8?B?L2g3SklnVlV1dkloVVBtTDhKZHdmRTlmMk9VOHpsS21RYjgvdk03V3BJNTl2?=
 =?utf-8?B?cmxNZmpQQXg5UWZVOUhHcmZROGFJRnQ2aGdaU3pSdmlibm1rY1F6QlBMM25R?=
 =?utf-8?B?Y2pwRDh2OGhSRzg0dS9remp6Q2ZEM0pnTWJlb2Vub2NCUDJYRjJ2VjhmZlF2?=
 =?utf-8?B?ZHV2dUlyNmxwek8zVnJIcGMyL1loWmpvL1ZpYU1kZHNsekxLSWFUNC9WZDk0?=
 =?utf-8?B?bHBMK2oxdEZzb1dHWi9oVncvcngzSGlMbkJmTVErZzdEN0oyUVc4TElBcnBC?=
 =?utf-8?B?emJRTHM3WUJzajJqNGQ0OHJzbjhOK3Z6TnNvaVkrMUM1U093WXFLMXNvQUsx?=
 =?utf-8?B?MTl6YjBqT3dsNGQwWXZ0eTdqU3FoQjhRdllGMFBsd3RRYWo4cGtxeWlJNDRP?=
 =?utf-8?B?ZVI1cjRGeStaejhzRnE2ejJtcFJ0d202TTN0UkFSS3ZnWjY4OExQS2FoMGxV?=
 =?utf-8?B?TDJ5MGRlVlg2U0tDVzFlZFAwdnBTZm16RUpURDlQblZ0ZjFRUVhmZ2ppZWdC?=
 =?utf-8?B?MXJzQnBMQUlhUGtpUzFnSko1Vjk2R3piSmNVZXQzQUEwcHFtNkNFOVUycFFY?=
 =?utf-8?B?cTMzdHpUcFZPMTFvM1Q0SU42bE40blpiTDc1T043V3BIaThNSit4Q05jNDMy?=
 =?utf-8?B?YzBpdzNMZHlIZHYwMDkxVkVBZHVOc3RmaHJKUGE0QlppU0dvTWZiQ3ZsM25J?=
 =?utf-8?B?RWZLdUp1VCtQVUdXUGtkNldxT1hocDhWbGNIOXhwb0RMc1ZNMjd1cGsrY0dY?=
 =?utf-8?B?M2tjeGRLanRSODdJenlXODJzd1VtUGZRS2Vxci9LR2dETkd4L1RXTUQ2d3d1?=
 =?utf-8?B?bEFzVjRhQ210Q1diYmpReTJzb0dnSmJrcXc2RE5iKzVrZUlpdmhHdWJWajFZ?=
 =?utf-8?B?VWcxL1hUc2k5WEs4ZW9LSzBXMVFva1A0QjZwWFpOVlBPOXlrRWVuQ1AwdlRV?=
 =?utf-8?B?SEErN0VIbHZmT0QvUG9oYWNSWEQxWFh6a2hBeW1SSFYvZnFDLzlJVkprLzc1?=
 =?utf-8?B?Mkp6bFQydTR1N2xvVDFoYWJnV21WNnhaeWFkTkg0QU9PTGRTdC9SQzhwS0ZY?=
 =?utf-8?B?MXRUZ3Brdk5mVnN1cEJPd3RPMllzUi95UGZOWFBMWkdlb1F1M1c1UUNJWXVF?=
 =?utf-8?B?Y054QURtOXIrUDJIaDRTTjU3aEo1Q1U3dDNjcHhXcGw0TmF6bTdGaThlZ0tu?=
 =?utf-8?B?dGhhTWNIL1pYMFFZR21tSjlQNkhyNGY2UnoyV1lWV1ZvbmRLTFBKUVhkVmE0?=
 =?utf-8?B?S0xUYlY5bURNdzhGeEdUMHdoL1FkcW1Zb0I2bnJHeE5SZlFjM3BKR3BwQ3BB?=
 =?utf-8?B?RXRQTTZQV0k1TndYUTk4VEVJMWxZd2pKVWxqK0RPV09GeVp1WmZSNUorejZu?=
 =?utf-8?B?bU1TTDZTSmtOVGtGMWN1R2RtZnNnMXFFcThWaVliNzZ1SFBqd3F5dmlaSG8v?=
 =?utf-8?B?b3RuWW8rM2dtRzVmUDZZUFFaZWthbTN3L0x2d3lzSVNCdmJtSzVaOFZNMFdZ?=
 =?utf-8?B?U2d0SGdzTGhHV2p0UXZWRjV2dWRtN1FFb3NYb3Awci9aUVhyNHBwZlhieEZa?=
 =?utf-8?B?YkNsSk92RmJ1RHJ4T3RjTk5PSDZNVGtEdzlBakdGU1dHUWFPcWR5bm92Q2tx?=
 =?utf-8?B?dWZ5U3hYVFRobmtYUzdSNUhHeTVTNFZTVlE5QnpCRnV1NmlGanR5R1BEUWxs?=
 =?utf-8?B?WGduUm1jaUEzcTJ2eXRVWmNaWDlOZm9WNXRML2V2QkwxMjJCNktsMjVqZURi?=
 =?utf-8?B?SExJV0NRcnpoOWk5amRldEFLUzQ0UHlOK3pZellvQnFvL3hIWHN6VHo0NGl4?=
 =?utf-8?B?NHdBZk5hN0RYb2s0cUpsenNubm5tWSsrUUJhaCt1QnlFQm1SWE5zbVo5ZWJW?=
 =?utf-8?B?M1hEYjVLazgxaXNlcDVySUNWV2d1NG5mVEZSdWJ5T3JOVndXR1NvUkpCRjFY?=
 =?utf-8?B?L1FyaklFNWZpeDlMQjRSNlF0bjIxN25Db0loQzJnVE04eGpmbUVjZllTdlpn?=
 =?utf-8?B?YlE9PQ==?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	hmejXcWhuZO3KUlqgsvk5LlcR6Fco5U4uu1fw1qI1n702AcimWmhShaQXepCaOtg68H+Ah8D4lgqxXniWxU1L5kjO55tr0Ang28GeKRxYFeRn/PjYLfYbMo49e/MQpjx43PM3AKbQfs8sRK+5pRryT/Z/Q5NGqxRTsvUV4f2mkYRpPHNTkd4RhbCqyFFOAYeOxYFwKvO+kvFjroaSPKxlrSD9xg0opWggcK/s54VO+etUPI870WtvzaaVALiuVYugPebx1Ro8dFMd+nFw3ni6UtA5aMpZ7BFSnjDU/ss2UoQMlQuQDWD0TimIIhNERWXSQstS7XRucRY3pYWzJJn6RmH0Lclmu5rnhI6E/AybmwAEK1swKra/P+FjQJ6uJMUW0OMFSxmE6EBVmrj0/kC6viYZYh2c9MLXq7rLsezrPCQ6ZgnEmPHLdRGceG7E0DRl7w+i4yqAFbeebGngKnd2/5ubEDtvIV2v8HJ2QIHSZmYqj3U6BnzThLL8TcO3+VzaiGkygqFEtY1Vbp9MUH7sibsfdBtZxbuY4EXaFyGA9ulR117fPoAojXShoUHmVNuzH7YSsu1iFMxbjywMTpOXBrVTeedYGmGM1k/hDe0ZLw=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d9c6b9c9-7ff1-4705-046c-08dd40955218
X-MS-Exchange-CrossTenant-AuthSource: PH7PR10MB6505.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2025 18:47:03.1467
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: KEdWw/XFC1C6dInRQPBRdmM+g4w/lPj8FVj0iVoYExkQ6hp0yvCbFd+nH2AY4T3rXX3RxmimB/CwNNPjwn86yoZ28X/aSqrmjtSb5cPzVmI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR10MB6441
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34
 definitions=2025-01-29_04,2025-01-29_01,2024-11-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 mlxscore=0 bulkscore=0
 phishscore=0 suspectscore=0 adultscore=0 spamscore=0 mlxlogscore=999
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2411120000
 definitions=main-2501290146
X-Proofpoint-GUID: S9x-jyZuWRyTvBuzcp4L6aNDSp2xGnaa
X-Proofpoint-ORIG-GUID: S9x-jyZuWRyTvBuzcp4L6aNDSp2xGnaa


On 30/01/25 12:13 AM, Jürgen Groß wrote:
> On 29.01.25 19:35, Harshvardhan Jha wrote:
>>
>> On 29/01/25 4:52 PM, Juergen Gross wrote:
>>> On 29.01.25 10:15, Harshvardhan Jha wrote:
>>>>
>>>> On 29/01/25 2:34 PM, Greg KH wrote:
>>>>> On Wed, Jan 29, 2025 at 02:29:48PM +0530, Harshvardhan Jha wrote:
>>>>>> Hi Greg,
>>>>>>
>>>>>> On 29/01/25 2:18 PM, Greg KH wrote:
>>>>>>> On Wed, Jan 29, 2025 at 02:13:34PM +0530, Harshvardhan Jha wrote:
>>>>>>>> Hi there,
>>>>>>>>
>>>>>>>> On 29/01/25 2:05 PM, Greg KH wrote:
>>>>>>>>> On Wed, Jan 29, 2025 at 02:03:51PM +0530, Harshvardhan Jha wrote:
>>>>>>>>>> Hi All,
>>>>>>>>>>
>>>>>>>>>> +stable
>>>>>>>>>>
>>>>>>>>>> There seems to be some formatting issues in my log output. I
>>>>>>>>>> have
>>>>>>>>>> attached it as a file.
>>>>>>>>> Confused, what are you wanting us to do here in the stable tree?
>>>>>>>>>
>>>>>>>>> thanks,
>>>>>>>>>
>>>>>>>>> greg k-h
>>>>>>>> Since, this is reproducible on 5.4.y I have added stable. The
>>>>>>>> culprit
>>>>>>>> commit which upon getting reverted fixes this issue is also
>>>>>>>> present in
>>>>>>>> 5.4.y stable.
>>>>>>> What culprit commit?  I see no information here :(
>>>>>>>
>>>>>>> Remember, top-posting is evil...
>>>>>> My apologies,
>>>>>>
>>>>>> The stable tag v5.4.289 seems to fail to boot with the following
>>>>>> prompt in an infinite loop:
>>>>>> [   24.427217] megaraid_sas 0000:65:00.0: megasas_build_io_fusion
>>>>>> 3273 sge_count (-12) is out of range. Range is:  0-256
>>>>>>
>>>>>> Reverting the following patch seems to fix the issue:
>>>>>>
>>>>>> stable-5.4      : v5.4.285             - 5df29a445f3a
>>>>>> xen/swiotlb: add
>>>>>> alignment check for dma buffers
>>>>>>
>>>>>> I tried changing swiotlb grub command line arguments but that didn't
>>>>>> seem to help much unfortunately and the error was seen again.
>>>>>>
>>>>> Ok, can you submit this revert with the information about why it
>>>>> should
>>>>> not be included in the 5.4.y tree and cc: everyone involved and
>>>>> then we
>>>>> will be glad to queue it up.
>>>>>
>>>>> thanks,
>>>>>
>>>>> greg k-h
>>>>
>>>> This might be reproducible on other stable trees and mainline as
>>>> well so
>>>> we will get it fixed there and I will submit the necessary fix to
>>>> stable
>>>> when everything is sorted out on mainline.
>>>
>>> Right. Just reverting my patch will trade one error with another one
>>> (the
>>> one which triggered me to write the patch).
>>>
>>> There are two possible ways to fix the issue:
>>>
>>> - allow larger DMA buffers in xen/swiotlb (today 2MB are the max.
>>> supported
>>>    size, the megaraid_sas driver seems to effectively request 4MB)
>>
>> This seems relatively simpler to implement but I'm not sure whether it's
>> the most optimal approach
>
> Just making the static array larger used to hold the frame numbers for
> the
> buffer seems to be a waste of memory for most configurations.
Yep definitely not required in most cases.
>
> I'm thinking of an allocated array using the max needed size (replace a
> former buffer with a larger one if needed).

This seems like the right way to go.

Harshvardhan

>
>
> Juergen
>
> Juergen


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 18:48:32 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 18:48:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879290.1289505 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdD72-0008Q1-7r; Wed, 29 Jan 2025 18:48:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879290.1289505; Wed, 29 Jan 2025 18:48:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdD72-0008Pu-5K; Wed, 29 Jan 2025 18:48:32 +0000
Received: by outflank-mailman (input) for mailman id 879290;
 Wed, 29 Jan 2025 18:48:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=CGF7=UV=kernel.org=helgaas@srs-se1.protection.inumbo.net>)
 id 1tdD71-0008Po-Ep
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 18:48:31 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a102a445-de71-11ef-99a4-01e77a169b0f;
 Wed, 29 Jan 2025 19:48:29 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 59D0AA41B5A;
 Wed, 29 Jan 2025 18:46:41 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id A1B5BC4CED1;
 Wed, 29 Jan 2025 18:48:27 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a102a445-de71-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1738176507;
	bh=5x5C3oXKgTMBkuDA8TFCAbx9AmZk4D3MjTvrIrifUXk=;
	h=Date:From:To:Cc:Subject:In-Reply-To:From;
	b=DvX932J5IFZQf2YexIlDBTZ5Df9aWNzivuNpCN5l7X4KAeZwbG0RZ0NyHVY8Hoi3x
	 4HvDF7qV+6rNmC84cpQZE22mdmEfWpz1LtheIrgOA4lWfW7gGfCDe2afYg4yMGcGE+
	 ecyPV2je07PaXbi8BzPgoPNTwFNg4V6myMKgUiCEwJ3Sogm9GtaJDhCNMYegeAvWqb
	 /nxRHnPUyJJPdIi5+qliYETKlYoBWLt8HNvGgKrfobvjvOKX3KkYkRy8esy6Fse3vl
	 k1TVeaVbk1Qk7dkdv7GAuLkFDJyLE1cjyi2D3+iO/S3SXLPFvKRfnaGvAVGaNtmmIt
	 5oGFcJOGrkdLw==
Date: Wed, 29 Jan 2025 12:48:25 -0600
From: Bjorn Helgaas <helgaas@kernel.org>
To: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	=?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	linux-kernel@vger.kernel.org, regressions@lists.linux.dev,
	Felix Fietkau <nbd@nbd.name>, Lorenzo Bianconi <lorenzo@kernel.org>,
	Ryder Lee <ryder.lee@mediatek.com>
Subject: Re: Config space access to Mediatek MT7922 doesn't work after device
 reset in Xen PV dom0 (regression, Linux 6.12)
Message-ID: <20250129184825.GA484760@bhelgaas>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <Z5mOKQUrgeF_r6te@mail-itl>

On Wed, Jan 29, 2025 at 03:10:49AM +0100, Marek Marczykowski-Górecki wrote:
> On Tue, Jan 28, 2025 at 07:15:26PM -0600, Bjorn Helgaas wrote:
> > On Fri, Jan 17, 2025 at 01:05:30PM +0100, Marek Marczykowski-Górecki wrote:
> > > After updating PV dom0 to Linux 6.12, The Mediatek MT7922 device reports
> > > all 0xff when accessing its config space. This happens only after device
> > > reset (which is also triggered when binding the device to the
> > > xen-pciback driver).
> > 
> > Thanks for the report and for all the debugging you've already done!
> > 
> > > Reproducer:
> > > 
> > >     # lspci -xs 01:00.0
> > >     01:00.0 Network controller: MEDIATEK Corp. MT7922 802.11ax PCI Express Wireless Network Adapter
> > >     00: c3 14 16 06 00 00 10 00 00 00 80 02 10 00 00 00
> > >     ...
> > >     # echo 1 > /sys/bus/pci/devices/0000:01:00.0/reset
> > >     # lspci -xs 01:00.0
> > >     01:00.0 Network controller: MEDIATEK Corp. MT7922 802.11ax PCI Express Wireless Network Adapter
> > >     00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > >
> > > The same operation done on Linux 6.12 running without Xen works fine.
> > > 
> > > git bisect points at:
> > > 
> > >     commit d591f6804e7e1310881c9224d72247a2b65039af
> > >     Author: Bjorn Helgaas <bhelgaas@google.com>
> > >     Date:   Tue Aug 27 18:48:46 2024 -0500
> > > 
> > >     PCI: Wait for device readiness with Configuration RRS
> > > 
> > > part of that commit:
> > > @@ -1311,9 +1320,15 @@ static int pci_dev_wait(struct pci_dev *dev, char *reset_type, int timeout)
> > >                         return -ENOTTY;
> > >                 }
> > >  
> > > -               pci_read_config_dword(dev, PCI_COMMAND, &id);
> > > -               if (!PCI_POSSIBLE_ERROR(id))
> > > -                       break;
> > > +               if (root && root->config_crs_sv) {
> > > +                       pci_read_config_dword(dev, PCI_VENDOR_ID, &id);
> > > +                       if (!pci_bus_crs_vendor_id(id))
> > > +                               break;
> > > +               } else {
> > > +                       pci_read_config_dword(dev, PCI_COMMAND, &id);
> > > +                       if (!PCI_POSSIBLE_ERROR(id))
> > > +                               break;
> > > +               }
> > >  
> > >     
> > > Adding some debugging, the PCI_VENDOR_ID read in pci_dev_wait() returns
> > > initially 0xffffffff. If I extend the condition with
> > > "&& !PCI_POSSIBLE_ERROR(id)", then the issue disappear. But reading the
> > > patch description, it would break VF.
> > > I'm not sure where the issue is, but given it breaks only when running
> > > with Xen, I guess something is wrong with "Configuration RRS Software
> > > Visibility" in that case.
> > 
> > I'm missing something.  If you get 0xffffffff, that is not the 0x0001
> > Vendor ID, so pci_dev_wait() should exit immediately.  
> 
> I'm not sure what is going on there either, but my _guess_ is that the
> loop exits too early due to the above. And it makes some further actions
> to fail.

Seems like a good guess worth investigating.  Maybe log all config
accesses to this device after the FLR and see what we're doing?


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 19:41:10 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 19:41:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879300.1289516 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdDvl-0007ok-TB; Wed, 29 Jan 2025 19:40:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879300.1289516; Wed, 29 Jan 2025 19:40:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdDvl-0007od-Pv; Wed, 29 Jan 2025 19:40:57 +0000
Received: by outflank-mailman (input) for mailman id 879300;
 Wed, 29 Jan 2025 19:40:56 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=y68Q=UV=gmail.com=demiobenour@srs-se1.protection.inumbo.net>)
 id 1tdDvk-0007oX-8Y
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 19:40:56 +0000
Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com
 [2607:f8b0:4864:20::b36])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f31417ec-de78-11ef-99a4-01e77a169b0f;
 Wed, 29 Jan 2025 20:40:53 +0100 (CET)
Received: by mail-yb1-xb36.google.com with SMTP id
 3f1490d57ef6-e58a99f493bso124324276.2
 for <xen-devel@lists.xenproject.org>; Wed, 29 Jan 2025 11:40:53 -0800 (PST)
Received: from [10.138.7.94] ([45.134.140.51])
 by smtp.gmail.com with ESMTPSA id
 00721157ae682-6f757a2ac24sm23937107b3.103.2025.01.29.11.40.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 29 Jan 2025 11:40:51 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: f31417ec-de78-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1738179652; x=1738784452; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:to:from:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=YiAwe4ZwCv8Im80AYWWU2ZRBnO1Np7+D1TolCE4p/M0=;
        b=Gf0QMZbBaEqVdqPy/YMppp7062NZ3wpqTIC8Mh5dOJy8wMGQ4DPYdkU9rRwlN2amSP
         zaxCsrBdlqstB95ZLLGH2Urrl8DVW+CYjmNE1Fb0zcZ4JOUFSgTzExTmlp0CyuiWJjlL
         rGPKVasQyF1xgWLe8UyGGRvYLasvhEiHSpc+OXY2yleWWKoZ4CljYOo+SeJl6tJFCOuZ
         tS0twdipD7W9EYJbLXkn/LM85wnCo4+bqTZCY452HxihZzlYmLFeXhMnzWLcqoFxlQgP
         2XThZZ/VGPVyAum22yOvva+B/dRzQg7XTRkVhZA1uAl451SX/RQmFf7+F3To2Oj25fzL
         q9SQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738179652; x=1738784452;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:to:from:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=YiAwe4ZwCv8Im80AYWWU2ZRBnO1Np7+D1TolCE4p/M0=;
        b=tUNVWMtymArvIp7R/a5P2MLNdDZTgHya9zV/Ahn+loMOzOa3iqUuVTb8ekSxcGrq1W
         io+HDs8DuMf9LpfmliaQRuqG5YQbPVmvOtu+RCLTDpGExU0ikkDfMkm5qsbJ37iuII4N
         5AcbLxY4/eNSXORJF02AEt9o3Zb8e7+RWSbDpcNYeic5Lx/AiLm5zoXdEvgTvF2GLT22
         stKk8PxmsPexiVfT9lHN5KxUjiWNJWBAs2bDaQJiYmLI3hmcnBG6iLZ7d/NHwgVc+FDP
         33O8IxsqbUI+V4UnWFdAp4Nwpm9hfrYhz6RMhFfJa8Xkg11p8Sc97Hren6rVXBC7XUTr
         hZNQ==
X-Forwarded-Encrypted: i=1; AJvYcCWr6flD9g3iWBpp7o80t3FqS9MNyvjMy1CSZ5oGCRIqDJfgIKuzkjv4bdDF0niKomdZLqg87dyGMjo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzD5N9oEObU9NBNLUFpP/jgTKjVqOkofdl2eFxOs30n2KAYaemV
	pjF8M9NTjaFOBFyR3MTWagWSQMkYe2xrLmr/1+LduzvX81HCZG+V
X-Gm-Gg: ASbGncvWM8f/RtwtxOWJS0ndoQJqG+nO4Y12WJ7qZQcW4EeO016acLs4ceKV2yQJoXp
	kUWMZmwF0Ou3We9Qz0PcXrFqTMm3FvDFqqJ6c5L82I0kMt3lB1GO/1yQjg81/TdARkhIPJPuxX4
	EK+TONfbTE5DA8GAuzhidmcvlHv6TSDGgnj8CksQFunjRZ0nnPtn9hw4jHB6HhYobwxsyRv4wRd
	k5N6kRdgMGqFjKuyREnddpwJxz78Zhh2ibZJGo27W0m1Kw1WE8QYiTTKQZ4W7mA/kgcq+gYeyvz
	1OPqxSKBBou0b28YPuM=
X-Google-Smtp-Source: AGHT+IFcm70cBzxdaG4YIpPTJqjr1mlkmvf4KaftoD5a2PQ8bLHewaoEFQM7aAbm4+WTw3yFJ6O+gg==
X-Received: by 2002:a05:690c:4912:b0:6ef:805c:ea15 with SMTP id 00721157ae682-6f7a83fd04bmr32763617b3.23.1738179652005;
        Wed, 29 Jan 2025 11:40:52 -0800 (PST)
Message-ID: <a0165511-b7c7-442a-84cc-15fef7ea53b9@gmail.com>
Date: Wed, 29 Jan 2025 14:40:50 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH 3/3] drm/virtio: implement blob userptr resource
 object
From: Demi Marie Obenour <demiobenour@gmail.com>
To: "Huang, Honglei1" <Honglei1.Huang@amd.com>, Huang Rui
 <ray.huang@amd.com>, virtualization@lists.linux-foundation.org,
 linux-kernel@vger.kernel.org, Dmitry Osipenko
 <dmitry.osipenko@collabora.com>, dri-devel@lists.freedesktop.org,
 David Airlie <airlied@redhat.com>, Gerd Hoffmann <kraxel@redhat.com>,
 Gurchetan Singh <gurchetansingh@chromium.org>, Chia-I Wu
 <olvaffe@gmail.com>, Akihiko Odaki <akihiko.odaki@daynix.com>,
 Lingshan Zhu <Lingshan.Zhu@amd.com>, Simona Vetter <simona.vetter@ffwll.ch>,
 Xen developer discussion <xen-devel@lists.xenproject.org>,
 Kernel KVM virtualization development <kvm@vger.kernel.org>,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
References: <20241220100409.4007346-1-honglei1.huang@amd.com>
 <20241220100409.4007346-3-honglei1.huang@amd.com>
 <Z2WO2udH2zAEr6ln@phenom.ffwll.local>
 <2fb36b50-4de2-4060-a4b7-54d221db8647@gmail.com>
 <de8ade34-eb67-4bff-a1c9-27cb51798843@amd.com>
 <Z36wV07M8B_wgWPl@phenom.ffwll.local>
 <9572ba57-5552-4543-a3b0-6097520a12a3@gmail.com>
Content-Language: en-US
Autocrypt: addr=demiobenour@gmail.com; keydata=
 xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49yB+l2nipd
 aq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYfbWpr/si88QKgyGSV
 Z7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/UorR+FaSuVwT7rqzGrTlscnT
 DlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7MMPCJwI8JpPlBedRpe9tfVyfu3euTPLPx
 wcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9Hzx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR
 6h3nBc3eyuZ+q62HS1pJ5EvUT1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl
 5FMWo8TCniHynNXsBtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2
 Bkg1b//r6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
 9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nSm9BBff0N
 m0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQABzTxEZW1pIE1hcmll
 IE9iZW5vdXIgKGxvdmVyIG9mIGNvZGluZykgPGRlbWlvYmVub3VyQGdtYWlsLmNvbT7CwXgE
 EwECACIFAlp+A0oCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJELKItV//nCLBhr8Q
 AK/xrb4wyi71xII2hkFBpT59ObLN+32FQT7R3lbZRjVFjc6yMUjOb1H/hJVxx+yo5gsSj5LS
 9AwggioUSrcUKldfA/PKKai2mzTlUDxTcF3vKx6iMXKA6AqwAw4B57ZEJoMM6egm57TV19kz
 PMc879NV2nc6+elaKl+/kbVeD3qvBuEwsTe2Do3HAAdrfUG/j9erwIk6gha/Hp9yZlCnPTX+
 VK+xifQqt8RtMqS5R/S8z0msJMI/ajNU03kFjOpqrYziv6OZLJ5cuKb3bZU5aoaRQRDzkFIR
 6aqtFLTohTo20QywXwRa39uFaOT/0YMpNyel0kdOszFOykTEGI2u+kja35g9TkH90kkBTG+a
 EWttIht0Hy6YFmwjcAxisSakBuHnHuMSOiyRQLu43ej2+mDWgItLZ48Mu0C3IG1seeQDjEYP
 tqvyZ6bGkf2Vj+L6wLoLLIhRZxQOedqArIk/Sb2SzQYuxN44IDRt+3ZcDqsPppoKcxSyd1Ny
 2tpvjYJXlfKmOYLhTWs8nwlAlSHX/c/jz/ywwf7eSvGknToo1Y0VpRtoxMaKW1nvH0OeCSVJ
 itfRP7YbiRVc2aNqWPCSgtqHAuVraBRbAFLKh9d2rKFB3BmynTUpc1BQLJP8+D5oNyb8Ts4x
 Xd3iV/uD8JLGJfYZIR7oGWFLP4uZ3tkneDfYzsFNBFp+A0oBEAC9ynZI9LU+uJkMeEJeJyQ/
 8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd8xD57ue0eB47bcJv
 VqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPpI4gfUbVEIEQuqdqQyO4GAe+M
 kD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalql1/iSyv1WYeC1OAs+2BLOAT2NEggSiVO
 txEfgewsQtCWi8H1SoirakIfo45Hz0tk/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJ
 riwoaRIS8N2C8/nEM53jb1sH0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcN
 fRAIUrNlatj9TxwivQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6
 dCxN0GNAORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
 rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog2LNtcyCj
 kTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZAgrrnNz0iZG2DVx46
 x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJELKItV//nCLBwNIP/AiIHE8b
 oIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwjjVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGj
 gn0TPtsGzelyQHipaUzEyrsceUGWYoKXYyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8fr
 RHnJdBcjf112PzQSdKC6kqU0Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2
 E0rW4tBtDAn2HkT9uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHM
 OBvy3EhzfAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
 Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVssZ/rYZ9+5
 1yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aWemLLszcYz/u3XnbO
 vUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPthZlDnTnOT+C+OTsh8+m5tos8
 HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E
 +MYSfkEjBz0E8CLOcAw7JIwAaeBT
In-Reply-To: <9572ba57-5552-4543-a3b0-6097520a12a3@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 1/24/25 7:42 PM, Demi Marie Obenour wrote:
> On 1/8/25 12:05 PM, Simona Vetter wrote:
>> On Fri, Dec 27, 2024 at 10:24:29AM +0800, Huang, Honglei1 wrote:
>>>
>>> On 2024/12/22 9:59, Demi Marie Obenour wrote:
>>>> On 12/20/24 10:35 AM, Simona Vetter wrote:
>>>>> On Fri, Dec 20, 2024 at 06:04:09PM +0800, Honglei Huang wrote:
>>>>>> From: Honglei Huang <Honglei1.Huang@amd.com>
>>>>>>
>>>>>> A virtio-gpu userptr is based on HMM notifier.
>>>>>> Used for let host access guest userspace memory and
>>>>>> notice the change of userspace memory.
>>>>>> This series patches are in very beginning state,
>>>>>> User space are pinned currently to ensure the host
>>>>>> device memory operations are correct.
>>>>>> The free and unmap operations for userspace can be
>>>>>> handled by MMU notifier this is a simple and basice
>>>>>> SVM feature for this series patches.
>>>>>> The physical PFNS update operations is splited into
>>>>>> two OPs in here. The evicted memories won't be used
>>>>>> anymore but remap into host again to achieve same
>>>>>> effect with hmm_rang_fault.
>>>>>
>>>>> So in my opinion there are two ways to implement userptr that make sense:
>>>>>
>>>>> - pinned userptr with pin_user_pages(FOLL_LONGTERM). there is not mmu
>>>>>    notifier
>>>>>
>>>>> - unpinnned userptr where you entirely rely on userptr and do not hold any
>>>>>    page references or page pins at all, for full SVM integration. This
>>>>>    should use hmm_range_fault ideally, since that's the version that
>>>>>    doesn't ever grab any page reference pins.
>>>>>
>>>>> All the in-between variants are imo really bad hacks, whether they hold a
>>>>> page reference or a temporary page pin (which seems to be what you're
>>>>> doing here). In much older kernels there was some justification for them,
>>>>> because strange stuff happened over fork(), but with FOLL_LONGTERM this is
>>>>> now all sorted out. So there's really only fully pinned, or true svm left
>>>>> as clean design choices imo.
>>>>>
>>>>> With that background, why does pin_user_pages(FOLL_LONGTERM) not work for
>>>>> you?
>>>>
>>>> +1 on using FOLL_LONGTERM.  Fully dynamic memory management has a huge cost
>>>> in complexity that pinning everything avoids.  Furthermore, this avoids the
>>>> host having to take action in response to guest memory reclaim requests.
>>>> This avoids additional complexity (and thus attack surface) on the host side.
>>>> Furthermore, since this is for ROCm and not for graphics, I am less concerned
>>>> about supporting systems that require swappable GPU VRAM.
>>>
>>> Hi Sima and Demi,
>>>
>>> I totally agree the flag FOLL_LONGTERM is needed, I will add it in next
>>> version.
>>>
>>> And for the first pin variants implementation, the MMU notifier is also
>>> needed I think.Cause the userptr feature in UMD generally used like this:
>>> the registering of userptr always is explicitly invoked by user code like
>>> "registerMemoryToGPU(userptrAddr, ...)", but for the userptr release/free,
>>> there is no explicit API for it, at least in hsakmt/KFD stack. User just
>>> need call system call "free(userptrAddr)", then kernel driver will release
>>> the userptr by MMU notifier callback.Virtio-GPU has no other way to know if
>>> user has been free the userptr except for MMU notifior.And in UMD theres is
>>> no way to get the free() operation is invoked by user.The only way is use
>>> MMU notifier in virtio-GPU driver and free the corresponding data in host by
>>> some virtio CMDs as far as I can see.
>>>
>>> And for the second way that is use hmm_range_fault, there is a predictable
>>> issues as far as I can see, at least in hsakmt/KFD stack. That is the memory
>>> may migrate when GPU/device is working. In bare metal, when memory is
>>> migrating KFD driver will pause the compute work of the device in
>>> mmap_wirte_lock then use hmm_range_fault to remap the migrated/evicted
>>> memories to GPU then restore the compute work of device to ensure the
>>> correction of the data. But in virtio-GPU driver the migration happen in
>>> guest kernel, the evict mmu notifier callback happens in guest, a virtio CMD
>>> can be used for notify host but as lack of mmap_write_lock protection in
>>> host kernel, host will hold invalid data for a short period of time, this
>>> may lead to some issues. And it is hard to fix as far as I can see.
>>>
>>> I will extract some APIs into helper according to your request, and I will
>>> refactor the whole userptr implementation, use some callbacks in page
>>> getting path, let the pin method and hmm_range_fault can be choiced
>>> in this series patches.
>>
>> Ok, so if this is for svm, then you need full blast hmm, or the semantics
>> are buggy. You cannot fake svm with pin(FOLL_LONGTERM) userptr, this does
>> not work.
> 
> Is this still broken in the virtualized case?  Page migration between host
> and device memory is completely transparent to the guest kernel, so pinning
> guest memory doesn't interfere with the host KMD at all.  In fact, the host
> KMD is not even aware of it.

To elaborate further:

Memory in a KVM guest is *not* host physical memory, or even host kernel
memory.  It is host *userspace* memory, and in particular, *it is fully pageable*.
There *might* be a few exceptions involving structures that are accessed by
the (physical) CPU, but none of these are relevant here.

This means that memory management works very differently than in the
non-virtualized case.  The host KMD can migrate pages between host memory
and device memory without either the guest kernel or host userspace being
aware that such migration has happened.  This means that pin(FOLL_LONGTERM)
in the guest doesn't pin memory on the host.  Instead, it pins memory in the
*guest*.  The host will continue to migrate pages between host and device
as needed.  I’m no expert on SVM, but I suspect this is the desired behavior.

Xen is significantly trickier, because most guest memory is provided by
the Xen toolstack via the hypervisor and is _not_ pageable.  Therefore,
it cannot be mapped into the GPU without using Xen grant tables.  Since
Xen grants do not support non-cooperative revocation, this requires a
FOLL_LONGTERM pin *anyway*.  Furthermore, granted pages _cannot_ be
migrated from host to device, so unless the GPU is an iGPU all of its
accesses will need to cross the PCI bus.  This will obviously be slow.

The guest can avoid this problem by migrating userptr memory to virtio-GPU
blob objects _before_ pinning it.  Virtio-GPU blob objects are backed by
host userspace memory, so the host can migrate them between device and host
memory just like in the KVM case.  Under KVM, such migration would be be
slightly wasteful but otherwise harmless in the common case.  In the case
where PCI passthrough is also in use, however, it might be necessary even
for KVM guests.  This is because PCI passthrough requires pinned memory,
and pinned memory cannot be migrated to the device.

Since AMD’s automotive use-case uses Xen, and since KVM might also need
page migration, I recommend that the initial implementation _always_
migrate pages to blob objects no matter what the hypervisor is.  Direct
GPU access to guest memory can be implemented as a KVM-specific optimization
later.

Also worth noting is that only pages that have been written need to be
migrated.  If a page hasn't been written, it should not be migrated, because
unwritten pages of a blob objects will read as zero.  However, the migration
should almost certainly be done in 2M chunks, rather than 4K ones.  This is
because the TLBs of at least AMD GPU are optimized for 2M pages, and GPU access
to 4K pages takes a 30% performance penalty.  This nicely matches the penalty
that AMD observed.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 20:00:34 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 20:00:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879310.1289526 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdEEe-0002GQ-DW; Wed, 29 Jan 2025 20:00:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879310.1289526; Wed, 29 Jan 2025 20:00:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdEEe-0002GJ-AZ; Wed, 29 Jan 2025 20:00:28 +0000
Received: by outflank-mailman (input) for mailman id 879310;
 Wed, 29 Jan 2025 20:00:26 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=cG3g=UV=kernel.org=pr-tracker-bot@srs-se1.protection.inumbo.net>)
 id 1tdEEc-0002GD-Im
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 20:00:26 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id accd311a-de7b-11ef-99a4-01e77a169b0f;
 Wed, 29 Jan 2025 21:00:24 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 0C9FAA41BD9;
 Wed, 29 Jan 2025 19:58:36 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9D33BC4CED1;
 Wed, 29 Jan 2025 20:00:22 +0000 (UTC)
Received: from [10.30.226.235] (localhost [IPv6:::1])
 by aws-us-west-2-korg-oddjob-rhel9-1.codeaurora.org (Postfix) with ESMTP id
 EC238380AA66; Wed, 29 Jan 2025 20:00:49 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: accd311a-de7b-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1738180822;
	bh=iVfZkLVruIbbdzsnZUjYzyiyWIqjBGQkh7u7/V1Jtwg=;
	h=Subject:From:In-Reply-To:References:Date:To:Cc:From;
	b=UwRQ+iFUxtV8g1OM6HbfW7XBiTOdcc/n32bE6o0YauK6Yubvs+bPxASqrw+klc3Kx
	 hf/kBWMvjhuSdv8XLNlYEle//ixLcuE1b5auG6ohvQvkb/eAAiT7pkknr+wXSaXit9
	 DEn8Pe1AdadAVCSMpc8ecCdkZPjCYfpdyh+JXhkzAcMtPhOS/GEzkM0SZoxb/xkKtr
	 8YDmdn2GaTbee1y41bSMYs6ZUNdy/EwDpKCQx8r47+XuUI+jAERfU4cZ16nkfex8C3
	 t/B3IV4sizKP6opgOb9MMx4yohcN1/1bd1cx3SOSv8Xl7xNBxELvZrI505mOj5vOrm
	 fIrmDChy72NcA==
Subject: Re: [GIT PULL] xen: branch for v6.14-rc1
From: pr-tracker-bot@kernel.org
In-Reply-To: <20250129183614.2601-1-jgross@suse.com>
References: <20250129183614.2601-1-jgross@suse.com>
X-PR-Tracked-List-Id: <linux-kernel.vger.kernel.org>
X-PR-Tracked-Message-Id: <20250129183614.2601-1-jgross@suse.com>
X-PR-Tracked-Remote: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-6.14-rc1-tag
X-PR-Tracked-Commit-Id: bda50f7770e5b8e730745e119eb6ca78570f7abf
X-PR-Merge-Tree: torvalds/linux.git
X-PR-Merge-Refname: refs/heads/master
X-PR-Merge-Commit-Id: b2091a64820f068dd19b7dd5351d8095adb3e5f6
Message-Id: <173818084837.411204.4406262662728868525.pr-tracker-bot@kernel.org>
Date: Wed, 29 Jan 2025 20:00:48 +0000
To: Juergen Gross <jgross@suse.com>
Cc: torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, sstabellini@kernel.org

The pull request you sent on Wed, 29 Jan 2025 19:36:12 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-6.14-rc1-tag

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/b2091a64820f068dd19b7dd5351d8095adb3e5f6

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 20:21:10 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 20:21:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879317.1289536 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdEYa-0005Gs-01; Wed, 29 Jan 2025 20:21:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879317.1289536; Wed, 29 Jan 2025 20:21:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdEYZ-0005Gl-Sh; Wed, 29 Jan 2025 20:21:03 +0000
Received: by outflank-mailman (input) for mailman id 879317;
 Wed, 29 Jan 2025 20:21:02 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=lGVs=UV=gmail.com=julien.grall.oss@srs-se1.protection.inumbo.net>)
 id 1tdEYY-0005Gf-Cd
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 20:21:02 +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 8e04aa00-de7e-11ef-a0e6-8be0dac302b0;
 Wed, 29 Jan 2025 21:21:00 +0100 (CET)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-38a8b17d7a7so34091f8f.2
 for <xen-devel@lists.xenproject.org>; Wed, 29 Jan 2025 12:21:00 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8e04aa00-de7e-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1738182060; x=1738786860; 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=/Kf0EGJPK46ugt4tD3iaXD+lziBwDACFREctfvQbJEI=;
        b=Bi+aa9gfCSgBKnERGrhgt8Qvbors77deg8BzQeGuZC9bVduvJ5ViTBOmUyTLb4CcS2
         lmnpUUCN1X9nsmv91bgs68K1ecyLqlD4Tf+BENF3p3Ve8jigbFGmzqnKGa+I33OXGuIQ
         +ah4igwmkPau8nVfDHVV/M5NH2c/BqTv5V5LRhOP1D17GKvPs599GF5yqaZB2pjyrdIn
         bSMZByqiemWTuacUI7vOTfrpWh8QwwBovUtUXNt8n+oj6xsIC4BQBMkuk0wN6ScYgvvz
         nUmUR8NuWsXdXRW6yh8ArySm3+cpINRDnz85KhS4Zmv2Y0UnpFX6BvTU/GVZ1EZPew8Q
         cLvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738182060; x=1738786860;
        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=/Kf0EGJPK46ugt4tD3iaXD+lziBwDACFREctfvQbJEI=;
        b=iiXIG5Loo3mrzT+ontVIn2pQFKsRIzm5t0YT3ONFPZQvJiNR/dDD7/cvnXGYauLzGn
         gv8smj7ZcWu3HcMDyg85w+vcTo8WJgj3gVrrBUy2g6VICmjARPS/2muWIU5W3MX3yeDT
         ubK4GhZQAIAniQHHOxI7xqmFI8cIVoXKqrid+M3rsxUla2vB5PAE1kYpd5kTUpThjyJZ
         JxT11u9iZsK8xETyBPBqxCgH63sj3PiskFVLrSR0swJNP4davOiGPo2FiOg7NDzBq4xc
         rSZlJRZePoYseOCqhyCqvfB7r+MM2bvKT9OEN6crIeBIwny+gqMGVOxS1mLOdLS+IlhE
         Og8w==
X-Forwarded-Encrypted: i=1; AJvYcCVvb9CjGy0mMSBgwE0hrWB8tGzk4K7dIrvaDwYUOm8xUdeLiU4J7YHu0ZaM6H+QrVLiqDgqy5189aM=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzyd35Po7g/Rmv1Cq9SoprbRE+ZMs8KoYOsrq/ZcthK7vjQquva
	PN9WvEHRkrOkPIbDCfRtnUnH+uJrocH+fHj0obppxbitAfHkRW5wAOs12G4k02KsgBVosBSjdrB
	qh8bozhsZ1HKVq7iOXammiXXRDqY=
X-Gm-Gg: ASbGnctkmG+QyT2Zsj7aQn7AAeuJEaigDFaJgmNbt/nSywg/fssc4okNoydaWQ8nLot
	2k6scrnKmCUiU3/d4E3bWBM1S3FT9889NYrVtVhWjK29I9VFHnEH83BG57xVzw/es7wfqHa6Fkq
	8=
X-Google-Smtp-Source: AGHT+IFJik1XjuEld/u9mraiLpO7C4xGvEHTZEmkFxNkgHvb/La9ni7s3ZvFanJUAQSORI8GF3nR3LakvyfaSUMVRzY=
X-Received: by 2002:a05:6000:1fac:b0:38a:614b:8632 with SMTP id
 ffacd0b85a97d-38c52093f16mr4928254f8f.39.1738182059535; Wed, 29 Jan 2025
 12:20:59 -0800 (PST)
MIME-Version: 1.0
References: <20250114195010.3409094-1-ayan.kumar.halder@amd.com>
 <20250114195010.3409094-2-ayan.kumar.halder@amd.com> <CAJ=z9a1ynFU86ac=1Q7i=xSNh2bjnZJ3+tPjsjWvfw7294n_NA@mail.gmail.com>
 <E930B9A0-6C32-476C-8829-7FD4C991F4A9@arm.com>
In-Reply-To: <E930B9A0-6C32-476C-8829-7FD4C991F4A9@arm.com>
From: Julien Grall <julien.grall.oss@gmail.com>
Date: Wed, 29 Jan 2025 17:20:46 -0300
X-Gm-Features: AWEUYZm1PfxBgVBQgrZVOnkLuZiJ-7DfP6viWcXVDrva-9R95ubC2FTEL645fQs
Message-ID: <CAJ=z9a3dqKDzPN9w_b5EnA+zOdezvBg0SQL+3aiNt9GhyU40bw@mail.gmail.com>
Subject: Re: [PATCH v1 2/2] docs: fusa: Add the requirements for some of the
 commands of XEN_VERSION
To: Bertrand Marquis <Bertrand.Marquis@arm.com>
Cc: Ayan Kumar Halder <ayan.kumar.halder@amd.com>, 
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, 
	Stefano Stabellini <sstabellini@kernel.org>, Michal Orzel <michal.orzel@amd.com>, 
	Artem Mygaiev <artem_mygaiev@epam.com>
Content-Type: multipart/alternative; boundary="00000000000036b3fe062cde0c76"

--00000000000036b3fe062cde0c76
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 29 Jan 2025 at 12:49, Bertrand Marquis <Bertrand.Marquis@arm.com>
wrote:

> Hi Julien,
>
> Welcome back :-)


I am not fully back yet but I have a bit of spare time to go through
xen-devel :).


>
> > On 29 Jan 2025, at 16:33, Julien Grall <julien.grall.oss@gmail.com>
> wrote:
> >
> > Hi,
> >
> > On Tue, 14 Jan 2025 at 16:50, Ayan Kumar Halder <
> ayan.kumar.halder@amd.com> wrote:
> > We have written the requirements for some of the commands of the
> XEN_VERSION
> > hypercall.
> >
> > Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
> > ---
> >  .../design-reqs/arm64/version_hypercall.rst   | 33 ++++++++
> >  .../reqs/design-reqs/version_hypercall.rst    | 65 +++++++++++++++
> >  docs/fusa/reqs/index.rst                      |  2 +
> >  .../reqs/product-reqs/version_hypercall.rst   | 82 +++++++++++++++++++
> >  4 files changed, 182 insertions(+)
> >  create mode 100644
> docs/fusa/reqs/design-reqs/arm64/version_hypercall.rst
> >  create mode 100644 docs/fusa/reqs/design-reqs/version_hypercall.rst
> >
> > diff --git a/docs/fusa/reqs/design-reqs/arm64/version_hypercall.rst
> b/docs/fusa/reqs/design-reqs/arm64/version_hypercall.rst
> > new file mode 100644
> > index 0000000000..1dad2b84c2
> > --- /dev/null
> > +++ b/docs/fusa/reqs/design-reqs/arm64/version_hypercall.rst
> > @@ -0,0 +1,33 @@
> > +.. SPDX-License-Identifier: CC-BY-4.0
> > +
> > +Capabilities
> > +------------
> > +
> > +`XenSwdgn~arm64_capabilities~1`
> > +
> > +Description:
> > +Xen shall have a internal constant string storing "xen-3.0-aarch64".
> >
> > Can you explain why we need to specify how Xen is storing the string? A=
t
> least to me this feels a bit overkill. What matters is what/how the VM is
> seen.
>
> This is a design requirement and as such it should be testable so it woul=
d
> be easier to have something saying:
> Xen shall have a constant named XXX storing YYY.


Reading this, would it be better to tie to the variable in the makefile?
This would be closer to how a user would set it and how one would test it.



>
> Just saying "an internal constant" seem a bit limited here and not saying
> much that could be tested easily.
>
> Why do you think this would be an overkill ? do you expect the constant
> name to change a lot ?


I don=E2=80=99t expect the constant name to change. It is more that this is=
 an
internal implementation quite far to how the user would set it (see above).

Cheers,


> I would see more as an overkill the fact that the value is stored in a
> requirement.
>
> Cheers
> Bertrand
>
>

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

<div><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" =
class=3D"gmail_attr">On Wed, 29 Jan 2025 at 12:49, Bertrand Marquis &lt;<a =
href=3D"mailto:Bertrand.Marquis@arm.com">Bertrand.Marquis@arm.com</a>&gt; w=
rote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;bord=
er-left-color:rgb(204,204,204)">Hi Julien,<br>
<br>
Welcome back :-)</blockquote><div dir=3D"auto"><br></div><div dir=3D"auto">=
I am not fully back yet but I have a bit of spare time to go through xen-de=
vel :).</div><div dir=3D"auto"><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:s=
olid;padding-left:1ex;border-left-color:rgb(204,204,204)" dir=3D"auto"><br>
<br>
&gt; On 29 Jan 2025, at 16:33, Julien Grall &lt;<a href=3D"mailto:julien.gr=
all.oss@gmail.com" target=3D"_blank">julien.grall.oss@gmail.com</a>&gt; wro=
te:<br>
&gt; <br>
&gt; Hi,<br>
&gt; <br>
&gt; On Tue, 14 Jan 2025 at 16:50, Ayan Kumar Halder &lt;<a href=3D"mailto:=
ayan.kumar.halder@amd.com" target=3D"_blank">ayan.kumar.halder@amd.com</a>&=
gt; wrote:<br>
&gt; We have written the requirements for some of the commands of the XEN_V=
ERSION<br>
&gt; hypercall.<br>
&gt; <br>
&gt; Signed-off-by: Ayan Kumar Halder &lt;<a href=3D"mailto:ayan.kumar.hald=
er@amd.com" target=3D"_blank">ayan.kumar.halder@amd.com</a>&gt;<br>
&gt; ---<br>
&gt;=C2=A0 .../design-reqs/arm64/version_hypercall.rst=C2=A0 =C2=A0| 33 +++=
+++++<br>
&gt;=C2=A0 .../reqs/design-reqs/version_hypercall.rst=C2=A0 =C2=A0 | 65 +++=
++++++++++++<br>
&gt;=C2=A0 docs/fusa/reqs/index.rst=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 2 +<br>
&gt;=C2=A0 .../reqs/product-reqs/version_hypercall.rst=C2=A0 =C2=A0| 82 +++=
++++++++++++++++<br>
&gt;=C2=A0 4 files changed, 182 insertions(+)<br>
&gt;=C2=A0 create mode 100644 docs/fusa/reqs/design-reqs/arm64/version_hype=
rcall.rst<br>
&gt;=C2=A0 create mode 100644 docs/fusa/reqs/design-reqs/version_hypercall.=
rst<br>
&gt; <br>
&gt; diff --git a/docs/fusa/reqs/design-reqs/arm64/version_hypercall.rst b/=
docs/fusa/reqs/design-reqs/arm64/version_hypercall.rst<br>
&gt; new file mode 100644<br>
&gt; index 0000000000..1dad2b84c2<br>
&gt; --- /dev/null<br>
&gt; +++ b/docs/fusa/reqs/design-reqs/arm64/version_hypercall.rst<br>
&gt; @@ -0,0 +1,33 @@<br>
&gt; +.. SPDX-License-Identifier: CC-BY-4.0<br>
&gt; +<br>
&gt; +Capabilities<br>
&gt; +------------<br>
&gt; +<br>
&gt; +`XenSwdgn~arm64_capabilities~1`<br>
&gt; +<br>
&gt; +Description:<br>
&gt; +Xen shall have a internal constant string storing &quot;xen-3.0-aarch=
64&quot;.<br>
&gt; <br>
&gt; Can you explain why we need to specify how Xen is storing the string? =
At least to me this feels a bit overkill. What matters is what/how the VM i=
s seen.<br>
<br>
This is a design requirement and as such it should be testable so it would =
be easier to have something saying:<br>
Xen shall have a constant named XXX storing YYY.</blockquote><div dir=3D"au=
to"><br></div><div dir=3D"auto">Reading this, would it be better to tie to =
the variable in the makefile? This would be closer to how a user would set =
it and how one would test it.</div><div dir=3D"auto"><br></div><div dir=3D"=
auto"><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;bor=
der-left-color:rgb(204,204,204)" dir=3D"auto"><br>
<br>
Just saying &quot;an internal constant&quot; seem a bit limited here and no=
t saying much that could be tested easily.<br>
<br>
Why do you think this would be an overkill ? do you expect the constant nam=
e to change a lot ?</blockquote><div dir=3D"auto"><br></div><div dir=3D"aut=
o">I don=E2=80=99t expect the constant name to change. It is more that this=
 is an internal implementation quite far to how the user would set it (see =
above).</div><div dir=3D"auto"><br></div><div dir=3D"auto">Cheers,</div><di=
v dir=3D"auto"><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-lef=
t:1ex;border-left-color:rgb(204,204,204)" dir=3D"auto"><br>
I would see more as an overkill the fact that the value is stored in a requ=
irement.<br>
<br>
Cheers<br>
Bertrand<br>
<br>
</blockquote></div></div>

--00000000000036b3fe062cde0c76--


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 20:55:16 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 20:55:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879331.1289546 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdF5U-0000y8-IL; Wed, 29 Jan 2025 20:55:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879331.1289546; Wed, 29 Jan 2025 20:55:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdF5U-0000y1-Fe; Wed, 29 Jan 2025 20:55:04 +0000
Received: by outflank-mailman (input) for mailman id 879331;
 Wed, 29 Jan 2025 20:55:03 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=y68Q=UV=gmail.com=demiobenour@srs-se1.protection.inumbo.net>)
 id 1tdF5T-0000xv-1n
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 20:55:03 +0000
Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com
 [2607:f8b0:4864:20::b30])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4e69a957-de83-11ef-a0e6-8be0dac302b0;
 Wed, 29 Jan 2025 21:55:01 +0100 (CET)
Received: by mail-yb1-xb30.google.com with SMTP id
 3f1490d57ef6-e53ef7462b6so259898276.3
 for <xen-devel@lists.xenproject.org>; Wed, 29 Jan 2025 12:55:01 -0800 (PST)
Received: from [10.138.7.94] ([45.134.140.51])
 by smtp.gmail.com with ESMTPSA id
 00721157ae682-6f757876fe8sm24376507b3.5.2025.01.29.12.54.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 29 Jan 2025 12:54:59 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 4e69a957-de83-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1738184100; x=1738788900; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=ueZk4UbNoQ80hfj8dpqw2VgMTf7ByqVqHJz79+NLnU0=;
        b=Ri6YLqj6rUh2n84QB3Pw+PLxd6CczL79GUFdFxStnUkXqGqksRuxbVwOLA3x54D8nY
         yOezGrqBYJ+G84ob4yvz/+9iWsFmWW3rsY01maO6laxW5Rqi2E+7uTIBjDFhg/1G/k8j
         Y/eM5E+ITQF+5VMb0t48SmcDg+rRKYy3LJLswxlfTPuHBnA6ApvjrxA5MVIc/Fx989Ub
         jx2fqaImVeMove3oLN53lBsyWc7S5XYID27zlx9h0fcaZE6lkIMTHYpoF2KA5zZOvEQ2
         btbyxqBrAANfTCwcX/pFYZu6Aiq1+chyLLvJFOLngqmnJIEa43gxee7+xyQjgkQfP6mF
         1drQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738184100; x=1738788900;
        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=ueZk4UbNoQ80hfj8dpqw2VgMTf7ByqVqHJz79+NLnU0=;
        b=mKbbk5yAJBGwchJh2kCvG/qJi73qaUTBDUV+JqyHxVB+Ou0HOZbui53e2bJiRCP976
         IDLNl0m9VWa7iddJPe4JHJ97E8/NrKEEIEs9k9lARIQrxEpU2QS9MwY7fFD6KarnW9jt
         h0OcbTrheIXcVtYroEjwbE/KmZmohiIspXEohnQblLXwy9cAYhQbNwXgz6wyQuvZ8OBM
         S3As10t3JAqUCGhKf/+3jCjlMlWE1FK3aUXUHaGPCF7Shsa3jELpllhgDAY6G1lmBsEE
         CnMlRu+5GVVIifdkeUNKxubuwQgHUPPTVRlGoTcK3JCK8YAUCTjvS6x7aELQItwhaVis
         Cr3Q==
X-Forwarded-Encrypted: i=1; AJvYcCW+KQDowGfOpo+Fh8wcUhqIok2xbLukJ7SzEkpTkXCpBDQReCwClOt7cECZ8fMcbOADrrMJXfXi1ko=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy5rh8jMEGenIlDUYVcmyc5MQvP2uv5hNkphjQ3SxgY/kqmHa9p
	VdGGI95bsp/PjcVT20Oa347c2bmgdVMU6AQB/xjeEtUDzs+Y79t3
X-Gm-Gg: ASbGncsY40pcptJxImei45nwgx3gqMYFRC/zfODFoEZ8LOvqk2RF8t2GKHPjCKJWCpV
	4sMvQT8rPdMZewHHFvQV4rRL6fY+VjZcnakNv7QOaFmYJjm/0t4XxiFczD5FXOBDxSiZqBGEjNc
	eBbpbDzCr2fWRCJsYTVTt8y/53hjeqDafQvaEGtT+rB9bULuxqdcFxwxIsnPVE7FCqSj2qcSrr6
	ULCp3DUo6AFox2/B0T1Sae9kEnQswtARWERFDtjDvyF6mhu9y1m8cmLrf0uPbZUgMSvy8N/5ctW
	PlIVdwfFVG5e6w/X+cI=
X-Google-Smtp-Source: AGHT+IEWmX2x1u7n/vc0UVcEoX4V7EHvc3YO4LXHl+8qKvZBYQDsROpwgWkMjeON3KdFCpXBNEgtTQ==
X-Received: by 2002:a05:690c:4808:b0:6ef:4fba:8143 with SMTP id 00721157ae682-6f7a836fbafmr43773547b3.18.1738184100325;
        Wed, 29 Jan 2025 12:55:00 -0800 (PST)
Message-ID: <c42ae4f7-f5f4-4906-85aa-b049ed44d7e9@gmail.com>
Date: Wed, 29 Jan 2025 15:54:59 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH 3/3] drm/virtio: implement blob userptr resource
 object
Content-Language: en-US
To: "Huang, Honglei1" <Honglei1.Huang@amd.com>, Huang Rui
 <ray.huang@amd.com>, virtualization@lists.linux-foundation.org,
 linux-kernel@vger.kernel.org, Dmitry Osipenko
 <dmitry.osipenko@collabora.com>, dri-devel@lists.freedesktop.org,
 David Airlie <airlied@redhat.com>, Gerd Hoffmann <kraxel@redhat.com>,
 Gurchetan Singh <gurchetansingh@chromium.org>, Chia-I Wu
 <olvaffe@gmail.com>, Akihiko Odaki <akihiko.odaki@daynix.com>,
 Lingshan Zhu <Lingshan.Zhu@amd.com>,
 Xen developer discussion <xen-devel@lists.xenproject.org>,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>,
 Kernel KVM virtualization development <kvm@vger.kernel.org>
References: <20241220100409.4007346-1-honglei1.huang@amd.com>
 <20241220100409.4007346-3-honglei1.huang@amd.com>
 <Z2WO2udH2zAEr6ln@phenom.ffwll.local>
 <2fb36b50-4de2-4060-a4b7-54d221db8647@gmail.com>
 <de8ade34-eb67-4bff-a1c9-27cb51798843@amd.com>
 <Z36wV07M8B_wgWPl@phenom.ffwll.local>
From: Demi Marie Obenour <demiobenour@gmail.com>
Autocrypt: addr=demiobenour@gmail.com; keydata=
 xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49yB+l2nipd
 aq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYfbWpr/si88QKgyGSV
 Z7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/UorR+FaSuVwT7rqzGrTlscnT
 DlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7MMPCJwI8JpPlBedRpe9tfVyfu3euTPLPx
 wcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9Hzx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR
 6h3nBc3eyuZ+q62HS1pJ5EvUT1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl
 5FMWo8TCniHynNXsBtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2
 Bkg1b//r6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
 9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nSm9BBff0N
 m0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQABzTxEZW1pIE1hcmll
 IE9iZW5vdXIgKGxvdmVyIG9mIGNvZGluZykgPGRlbWlvYmVub3VyQGdtYWlsLmNvbT7CwXgE
 EwECACIFAlp+A0oCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJELKItV//nCLBhr8Q
 AK/xrb4wyi71xII2hkFBpT59ObLN+32FQT7R3lbZRjVFjc6yMUjOb1H/hJVxx+yo5gsSj5LS
 9AwggioUSrcUKldfA/PKKai2mzTlUDxTcF3vKx6iMXKA6AqwAw4B57ZEJoMM6egm57TV19kz
 PMc879NV2nc6+elaKl+/kbVeD3qvBuEwsTe2Do3HAAdrfUG/j9erwIk6gha/Hp9yZlCnPTX+
 VK+xifQqt8RtMqS5R/S8z0msJMI/ajNU03kFjOpqrYziv6OZLJ5cuKb3bZU5aoaRQRDzkFIR
 6aqtFLTohTo20QywXwRa39uFaOT/0YMpNyel0kdOszFOykTEGI2u+kja35g9TkH90kkBTG+a
 EWttIht0Hy6YFmwjcAxisSakBuHnHuMSOiyRQLu43ej2+mDWgItLZ48Mu0C3IG1seeQDjEYP
 tqvyZ6bGkf2Vj+L6wLoLLIhRZxQOedqArIk/Sb2SzQYuxN44IDRt+3ZcDqsPppoKcxSyd1Ny
 2tpvjYJXlfKmOYLhTWs8nwlAlSHX/c/jz/ywwf7eSvGknToo1Y0VpRtoxMaKW1nvH0OeCSVJ
 itfRP7YbiRVc2aNqWPCSgtqHAuVraBRbAFLKh9d2rKFB3BmynTUpc1BQLJP8+D5oNyb8Ts4x
 Xd3iV/uD8JLGJfYZIR7oGWFLP4uZ3tkneDfYzsFNBFp+A0oBEAC9ynZI9LU+uJkMeEJeJyQ/
 8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd8xD57ue0eB47bcJv
 VqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPpI4gfUbVEIEQuqdqQyO4GAe+M
 kD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalql1/iSyv1WYeC1OAs+2BLOAT2NEggSiVO
 txEfgewsQtCWi8H1SoirakIfo45Hz0tk/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJ
 riwoaRIS8N2C8/nEM53jb1sH0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcN
 fRAIUrNlatj9TxwivQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6
 dCxN0GNAORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
 rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog2LNtcyCj
 kTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZAgrrnNz0iZG2DVx46
 x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJELKItV//nCLBwNIP/AiIHE8b
 oIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwjjVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGj
 gn0TPtsGzelyQHipaUzEyrsceUGWYoKXYyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8fr
 RHnJdBcjf112PzQSdKC6kqU0Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2
 E0rW4tBtDAn2HkT9uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHM
 OBvy3EhzfAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
 Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVssZ/rYZ9+5
 1yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aWemLLszcYz/u3XnbO
 vUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPthZlDnTnOT+C+OTsh8+m5tos8
 HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E
 +MYSfkEjBz0E8CLOcAw7JIwAaeBT
In-Reply-To: <Z36wV07M8B_wgWPl@phenom.ffwll.local>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 1/8/25 12:05 PM, Simona Vetter wrote:
> On Fri, Dec 27, 2024 at 10:24:29AM +0800, Huang, Honglei1 wrote:
>>
>> On 2024/12/22 9:59, Demi Marie Obenour wrote:
>>> On 12/20/24 10:35 AM, Simona Vetter wrote:
>>>> On Fri, Dec 20, 2024 at 06:04:09PM +0800, Honglei Huang wrote:
>>>>> From: Honglei Huang <Honglei1.Huang@amd.com>
>>>>>
>>>>> A virtio-gpu userptr is based on HMM notifier.
>>>>> Used for let host access guest userspace memory and
>>>>> notice the change of userspace memory.
>>>>> This series patches are in very beginning state,
>>>>> User space are pinned currently to ensure the host
>>>>> device memory operations are correct.
>>>>> The free and unmap operations for userspace can be
>>>>> handled by MMU notifier this is a simple and basice
>>>>> SVM feature for this series patches.
>>>>> The physical PFNS update operations is splited into
>>>>> two OPs in here. The evicted memories won't be used
>>>>> anymore but remap into host again to achieve same
>>>>> effect with hmm_rang_fault.
>>>>
>>>> So in my opinion there are two ways to implement userptr that make sense:
>>>>
>>>> - pinned userptr with pin_user_pages(FOLL_LONGTERM). there is not mmu
>>>>    notifier
>>>>
>>>> - unpinnned userptr where you entirely rely on userptr and do not hold any
>>>>    page references or page pins at all, for full SVM integration. This
>>>>    should use hmm_range_fault ideally, since that's the version that
>>>>    doesn't ever grab any page reference pins.
>>>>
>>>> All the in-between variants are imo really bad hacks, whether they hold a
>>>> page reference or a temporary page pin (which seems to be what you're
>>>> doing here). In much older kernels there was some justification for them,
>>>> because strange stuff happened over fork(), but with FOLL_LONGTERM this is
>>>> now all sorted out. So there's really only fully pinned, or true svm left
>>>> as clean design choices imo.
>>>>
>>>> With that background, why does pin_user_pages(FOLL_LONGTERM) not work for
>>>> you?
>>>
>>> +1 on using FOLL_LONGTERM.  Fully dynamic memory management has a huge cost
>>> in complexity that pinning everything avoids.  Furthermore, this avoids the
>>> host having to take action in response to guest memory reclaim requests.
>>> This avoids additional complexity (and thus attack surface) on the host side.
>>> Furthermore, since this is for ROCm and not for graphics, I am less concerned
>>> about supporting systems that require swappable GPU VRAM.
>>
>> Hi Sima and Demi,
>>
>> I totally agree the flag FOLL_LONGTERM is needed, I will add it in next
>> version.
>>
>> And for the first pin variants implementation, the MMU notifier is also
>> needed I think.Cause the userptr feature in UMD generally used like this:
>> the registering of userptr always is explicitly invoked by user code like
>> "registerMemoryToGPU(userptrAddr, ...)", but for the userptr release/free,
>> there is no explicit API for it, at least in hsakmt/KFD stack. User just
>> need call system call "free(userptrAddr)", then kernel driver will release
>> the userptr by MMU notifier callback.Virtio-GPU has no other way to know if
>> user has been free the userptr except for MMU notifior.And in UMD theres is
>> no way to get the free() operation is invoked by user.The only way is use
>> MMU notifier in virtio-GPU driver and free the corresponding data in host by
>> some virtio CMDs as far as I can see.
>>
>> And for the second way that is use hmm_range_fault, there is a predictable
>> issues as far as I can see, at least in hsakmt/KFD stack. That is the memory
>> may migrate when GPU/device is working. In bare metal, when memory is
>> migrating KFD driver will pause the compute work of the device in
>> mmap_wirte_lock then use hmm_range_fault to remap the migrated/evicted
>> memories to GPU then restore the compute work of device to ensure the
>> correction of the data. But in virtio-GPU driver the migration happen in
>> guest kernel, the evict mmu notifier callback happens in guest, a virtio CMD
>> can be used for notify host but as lack of mmap_write_lock protection in
>> host kernel, host will hold invalid data for a short period of time, this
>> may lead to some issues. And it is hard to fix as far as I can see.
>>
>> I will extract some APIs into helper according to your request, and I will
>> refactor the whole userptr implementation, use some callbacks in page
>> getting path, let the pin method and hmm_range_fault can be choiced
>> in this series patches.
> 
> Ok, so if this is for svm, then you need full blast hmm, or the semantics
> are buggy. You cannot fake svm with pin(FOLL_LONGTERM) userptr, this does
> not work.
> 
> The other option is that hsakmt/kfd api is completely busted, and that's
> kinda not a kernel problem.
> -Sima

On further thought, I believe the driver needs to migrate the pages to
device memory (really a virtio-GPU blob object) *and* take a FOLL_LONGTERM
pin on them.  The reason is that it isn’t possible to migrate these pages
back to "host" memory without unmapping them from the GPU.  For the reasons
I mention in [1], I believe that temporarily revoking access to virtio-GPU
blob objects is not feasible.  Instead, the pages must be treated as if
they are permanently in device memory until guest userspace unmaps them
from the GPU, after which they must be migrated back to host memory.

The problems with other approaches are most obvious if one considers a Xen
guest using a virtio-GPU backend that is not all-powerful.  Normal guest
memory is not accessible to the GPU, and Xen uses the IOMMU to enforce this
restriction.  Therefore, the guest must migrate pages to virtio-GPU blob
objects before the GPU can access them.  From Xen’s perspective, virtio-GPU
blob objects belong to the backend domain, so Xen allows the GPU to access
them.  However, the pages in blob objects _cannot_ be used in Xen grant table
operations, because Xen doesn’t consider them to belong to the guest!
Similarly, if the guest has an assigned PCI device, that device will not
be able to access the blob object’s pages.

I’m no expert on Linux memory management, so I’m not sure how to implement
this behavior.  What I _can_ say is that a blob object is I/O memory, and
behaves somewhat similar to a PCI BAR in a system with no P2PDMA support:
CPU access works, but DMA from other devices does not.  Furthermore, the
memory can’t be used for page tables or granted to other Xen guests, and it
will go away if the device is hot-unplugged.  In fact, if the PCI transport
is used, the blob object is located in the BAR of an (emulated) device.
There are non-PCI transports, though, so assuming that blob objects are
located in a PCI BAR is not a good idea.

The reason that pinning the objects in "device" memory is a reasonable
approach is that the host (or backend, in the Xen case) can still migrate
pages between device and host memory and not allocate backing store for
pages that are never accessed.  Therefore, it is not necessary for every
CPU access to go across the PCIe bus even for dGPUs.  Instead, if guest
CPU accesses are much more frequent than device accesses, the memory will
be migrated to the host side.  It’s up to the virtio-GPU backend
implementation to make sure that this happens.  For KVM, this should be
automatic, but for Xen, this might need additional Xen patches so that
the backend domain is notified when pages are accessed or dirtied.

[1]: https://lore.kernel.org/dri-devel/9572ba57-5552-4543-a3b0-6097520a12a3@gmail.com
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 22:02:04 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 22:02:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879341.1289556 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdG88-0000uG-Al; Wed, 29 Jan 2025 22:01:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879341.1289556; Wed, 29 Jan 2025 22:01:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdG88-0000u9-7M; Wed, 29 Jan 2025 22:01:52 +0000
Received: by outflank-mailman (input) for mailman id 879341;
 Wed, 29 Jan 2025 22:01:51 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=oGWA=UV=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tdG87-0000ty-9R
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 22:01:51 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org
 [2604:1380:4641:c500::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a209abf0-de8c-11ef-99a4-01e77a169b0f;
 Wed, 29 Jan 2025 23:01:47 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 144185C6172;
 Wed, 29 Jan 2025 22:01:06 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8AC67C4CED1;
 Wed, 29 Jan 2025 22:01:44 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a209abf0-de8c-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1738188105;
	bh=2Fp+uQjCLRYwrOD0BSfZrFoIEtJ6UcOoCawTUl51tD4=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=M1Bibcts0FNJcnusFPjMrEJ5gQxIzgQPHrO+EUT7BpuoxONsXjElEICLQqUPo9xNV
	 ckUoU2CvH+RQ3ejer5U4meHn2AnViAnLmEq122K8wOr3tCiV+j/zpjpF2rrPbmQS0w
	 BCtA0EUiG3vorW1tvp2czdQcAPFIPLZLeUI5HMX9W6/gUoVFmaHHxSh8WR+2Pd91Tg
	 CHdtqgqxB5xDmWGnqi1Dm9RO4FbztV2U5SogwdAJd+gvcu3sY5rVfcjM7dmxNxagza
	 Fr1H9/FqUGSkUTNf37YktvvkxJFEF0MlodCAFmHt1li22/uMA4mGzkTsbl47J4Crsv
	 nhX/Ziy5oujlg==
Date: Wed, 29 Jan 2025 14:01:35 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: =?UTF-8?Q?J=C3=BCrgen_Gro=C3=9F?= <jgross@suse.com>
cc: Harshvardhan Jha <harshvardhan.j.jha@oracle.com>, 
    Greg KH <gregkh@linuxfoundation.org>, Konrad Wilk <konrad.wilk@oracle.com>, 
    Boris Ostrovsky <boris.ostrovsky@oracle.com>, 
    "sstabellini@kernel.org" <sstabellini@kernel.org>, 
    "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, 
    "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, 
    Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>, 
    stable@vger.kernel.org
Subject: Re: v5.4.289 failed to boot with error megasas_build_io_fusion 3219
 sge_count (-12) is out of range
In-Reply-To: <de6912ad-3dba-4d66-8ca2-71a0aa09172c@suse.com>
Message-ID: <alpine.DEB.2.22.394.2501291401290.11632@ubuntu-linux-20-04-desktop>
References: <7dc143fa-4a48-440b-b624-ac57a361ac74@oracle.com> <9dd91f6e-1c66-4961-994e-dbda87d69dad@oracle.com> <2025012919-series-chaps-856e@gregkh> <8eb33b38-23e1-4e43-8952-3f2b05660236@oracle.com> <2025012936-finalize-ducktail-c524@gregkh>
 <1f017284-1a29-49d8-b0d9-92409561990e@oracle.com> <2025012956-jiffy-condone-3137@gregkh> <1f225b8d-d958-4304-829e-8798884d9b6b@oracle.com> <83bd90c7-8879-4462-9548-bb5b69cac39e@suse.com> <b4ab0246-3846-41d1-8e84-64bd7fefc089@oracle.com>
 <de6912ad-3dba-4d66-8ca2-71a0aa09172c@suse.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-408514709-1738188105=:11632"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-408514709-1738188105=:11632
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Wed, 29 Jan 2025, Jürgen Groß wrote:
> On 29.01.25 19:35, Harshvardhan Jha wrote:
> > 
> > On 29/01/25 4:52 PM, Juergen Gross wrote:
> > > On 29.01.25 10:15, Harshvardhan Jha wrote:
> > > > 
> > > > On 29/01/25 2:34 PM, Greg KH wrote:
> > > > > On Wed, Jan 29, 2025 at 02:29:48PM +0530, Harshvardhan Jha wrote:
> > > > > > Hi Greg,
> > > > > > 
> > > > > > On 29/01/25 2:18 PM, Greg KH wrote:
> > > > > > > On Wed, Jan 29, 2025 at 02:13:34PM +0530, Harshvardhan Jha wrote:
> > > > > > > > Hi there,
> > > > > > > > 
> > > > > > > > On 29/01/25 2:05 PM, Greg KH wrote:
> > > > > > > > > On Wed, Jan 29, 2025 at 02:03:51PM +0530, Harshvardhan Jha
> > > > > > > > > wrote:
> > > > > > > > > > Hi All,
> > > > > > > > > > 
> > > > > > > > > > +stable
> > > > > > > > > > 
> > > > > > > > > > There seems to be some formatting issues in my log output. I
> > > > > > > > > > have
> > > > > > > > > > attached it as a file.
> > > > > > > > > Confused, what are you wanting us to do here in the stable
> > > > > > > > > tree?
> > > > > > > > > 
> > > > > > > > > thanks,
> > > > > > > > > 
> > > > > > > > > greg k-h
> > > > > > > > Since, this is reproducible on 5.4.y I have added stable. The
> > > > > > > > culprit
> > > > > > > > commit which upon getting reverted fixes this issue is also
> > > > > > > > present in
> > > > > > > > 5.4.y stable.
> > > > > > > What culprit commit?  I see no information here :(
> > > > > > > 
> > > > > > > Remember, top-posting is evil...
> > > > > > My apologies,
> > > > > > 
> > > > > > The stable tag v5.4.289 seems to fail to boot with the following
> > > > > > prompt in an infinite loop:
> > > > > > [   24.427217] megaraid_sas 0000:65:00.0: megasas_build_io_fusion
> > > > > > 3273 sge_count (-12) is out of range. Range is:  0-256
> > > > > > 
> > > > > > Reverting the following patch seems to fix the issue:
> > > > > > 
> > > > > > stable-5.4      : v5.4.285             - 5df29a445f3a xen/swiotlb:
> > > > > > add
> > > > > > alignment check for dma buffers
> > > > > > 
> > > > > > I tried changing swiotlb grub command line arguments but that didn't
> > > > > > seem to help much unfortunately and the error was seen again.
> > > > > > 
> > > > > Ok, can you submit this revert with the information about why it
> > > > > should
> > > > > not be included in the 5.4.y tree and cc: everyone involved and then
> > > > > we
> > > > > will be glad to queue it up.
> > > > > 
> > > > > thanks,
> > > > > 
> > > > > greg k-h
> > > > 
> > > > This might be reproducible on other stable trees and mainline as well so
> > > > we will get it fixed there and I will submit the necessary fix to stable
> > > > when everything is sorted out on mainline.
> > > 
> > > Right. Just reverting my patch will trade one error with another one (the
> > > one which triggered me to write the patch).
> > > 
> > > There are two possible ways to fix the issue:
> > > 
> > > - allow larger DMA buffers in xen/swiotlb (today 2MB are the max.
> > > supported
> > >    size, the megaraid_sas driver seems to effectively request 4MB)
> > 
> > This seems relatively simpler to implement but I'm not sure whether it's
> > the most optimal approach
> 
> Just making the static array larger used to hold the frame numbers for the
> buffer seems to be a waste of memory for most configurations.
> 
> I'm thinking of an allocated array using the max needed size (replace a
> former buffer with a larger one if needed).

You are referring to discontig_frames and MAX_CONTIG_ORDER in
arch/x86/xen/mmu_pv.c, right? I am not super familiar with that code but
it looks like a good way to go.
--8323329-408514709-1738188105=:11632--


From xen-devel-bounces@lists.xenproject.org Wed Jan 29 22:50:26 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Jan 2025 22:50:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879351.1289566 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdGsu-0006sf-Q7; Wed, 29 Jan 2025 22:50:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879351.1289566; Wed, 29 Jan 2025 22:50:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdGsu-0006sY-M9; Wed, 29 Jan 2025 22:50:12 +0000
Received: by outflank-mailman (input) for mailman id 879351;
 Wed, 29 Jan 2025 22:50:11 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=oGWA=UV=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tdGst-0006sS-KQ
 for xen-devel@lists.xenproject.org; Wed, 29 Jan 2025 22:50:11 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org
 [2604:1380:45d1:ec00::3])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 63d0bd1c-de93-11ef-99a4-01e77a169b0f;
 Wed, 29 Jan 2025 23:50:09 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id ABB29A41D01;
 Wed, 29 Jan 2025 22:48:21 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id D3741C4CED1;
 Wed, 29 Jan 2025 22:50:06 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 63d0bd1c-de93-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1738191008;
	bh=66OpnIMI2bZ84gH/Y5a/Tu4k/aDihV/D5asgB5ZLf7c=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=Ru53OkaLQfOZI7t20VIy6DSrA6Y4tsD20PXwmANaKPGMR3/ECuoOXg+g4AJsW9Vcz
	 KMh1yU26umFjVRyqcD7ci3r8WzvBfBkU3cYOPtTY7ALxEJyCOjWFm8XKXB4v962oXx
	 yU0dOFriBg4ajwn9Rd1vy0Qx+avvHCVg95BDg1u7pnklKCS0jZ9pSdLRjk3/q6EnNY
	 RgCqLvySaojoQbVE9bGi4+MOKbQtBHyum0QslJuWeTAfv4DxCrPEyRgvCwBYnSf7rc
	 nOaNy+Eg87C9CXUrPTXL4yspYb2tmshIm4MN/TtedvX0ux5JeSnekI93rHhjRjMJiv
	 bo5BloijxETww==
Date: Wed, 29 Jan 2025 14:50:05 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: "Edgar E. Iglesias" <edgar.iglesias@amd.com>
cc: Stefano Stabellini <sstabellini@kernel.org>, Olaf Hering <olaf@aepfle.de>, 
    xen-devel@lists.xenproject.org, jgross@suse.com, 
    Anthony PERARD <anthony@xenproject.org>, Paul Durrant <paul@xen.org>, 
    jbeulich@suse.com, andrew.cooper3@citrix.com, roger.pau@citrix.com
Subject: Re: slow start of Pod HVM domU with qemu 9.1
In-Reply-To: <Z5oIvUINVDfrrVla@zapote>
Message-ID: <alpine.DEB.2.22.394.2501291429040.11632@ubuntu-linux-20-04-desktop>
References: <20250128151544.26fc827d.olaf@aepfle.de> <Z5j-bkdFZ7riavv7@zapote> <alpine.DEB.2.22.394.2501281543580.3264561@ubuntu-linux-20-04-desktop> <Z5oIvUINVDfrrVla@zapote>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Wed, 29 Jan 2025, Edgar E. Iglesias wrote:
> On Tue, Jan 28, 2025 at 03:58:14PM -0800, Stefano Stabellini wrote:
> > On Tue, 28 Jan 2025, Edgar E. Iglesias wrote:
> > > On Tue, Jan 28, 2025 at 03:15:44PM +0100, Olaf Hering wrote:
> > > > Hello,
> > > > 
> > > > starting with qemu 9.1 a PoD HVM domU takes a long time to start.
> > > > Depending on the domU kernel, it may trigger a warning, which prompted me
> > > > to notice this change in behavior:
> > > > 
> > > > [    0.000000] Linux version 4.12.14-120-default (geeko@buildhost) (gcc version 4.8.5 (SUSE Linux) ) #1 SMP Thu Nov 7 16:39:09 UTC 2019 (fd9dc36)
> > > > ...
> > > > [    1.096432] HPET: 3 timers in total, 0 timers will be used for per-cpu timer
> > > > [    1.101636] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
> > > > [    1.104051] hpet0: 3 comparators, 64-bit 62.500000 MHz counter
> > > > [   16.136086] random: crng init done
> > > > [   31.712052] BUG: workqueue lockup - pool cpus=1 node=0 flags=0x0 nice=0 stuck for 30s!
> > > > [   31.716029] Showing busy workqueues and worker pools:
> > > > [   31.721164] workqueue events: flags=0x0
> > > > [   31.724054]   pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=2/256
> > > > [   31.728000]     in-flight: 17:balloon_process
> > > > [   31.728000]     pending: hpet_work
> > > > [   31.728023] workqueue mm_percpu_wq: flags=0x8
> > > > [   31.732987]   pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=1/256
> > > > [   31.736000]     pending: vmstat_update
> > > > [   31.736024] pool 2: cpus=1 node=0 flags=0x0 nice=0 hung=30s workers=2 idle: 34
> > > > [   50.400102] clocksource: Switched to clocksource xen
> > > > [   50.441153] VFS: Disk quotas dquot_6.6.0
> > > > ...
> > > > 
> > > > With qemu 9.0 and older, this domU will start the /init task after 8 seconds.
> > > > 
> > > > The change which caused this commit is qemu.git commit 9ecdd4bf08dfe4a37e16b8a8b228575aff641468
> > > > Author:     Edgar E. Iglesias <edgar.iglesias@amd.com>
> > > > AuthorDate: Tue Apr 30 10:26:45 2024 +0200
> > > > Commit:     Edgar E. Iglesias <edgar.iglesias@amd.com>
> > > > CommitDate: Sun Jun 9 20:16:14 2024 +0200
> > > > 
> > > >     xen: mapcache: Add support for grant mappings
> > > > 
> > > > As you can see, v4 instead of v5 was apparently applied.
> > > > This was probably unintentional, but would probably not change the result.
> > > 
> > > Hi Olaf,
> > > 
> > > It looks like v8 was applied, or am I missing something?
> > > 
> > > 
> > > > 
> > > > With this change the domU starts fast again:
> > > > 
> > > > --- a/hw/xen/xen-mapcache.c
> > > > +++ b/hw/xen/xen-mapcache.c
> > > > @@ -522,6 +522,7 @@ ram_addr_t xen_ram_addr_from_mapcache(void *ptr)
> > > >      ram_addr_t addr;
> > > >  
> > > >      addr = xen_ram_addr_from_mapcache_single(mapcache, ptr);
> > > > +    if (1)
> > > >      if (addr == RAM_ADDR_INVALID) {
> > > >          addr = xen_ram_addr_from_mapcache_single(mapcache_grants, ptr);
> > > >      }
> > > > @@ -626,6 +627,7 @@ static void xen_invalidate_map_cache_entry_single(MapCache *mc, uint8_t *buffer)
> > > >  static void xen_invalidate_map_cache_entry_all(uint8_t *buffer)
> > > >  {
> > > >      xen_invalidate_map_cache_entry_single(mapcache, buffer);
> > > > +    if (1)
> > > >      xen_invalidate_map_cache_entry_single(mapcache_grants, buffer);
> > > >  }
> > > >  
> > > > @@ -700,6 +702,7 @@ void xen_invalidate_map_cache(void)
> > > >      bdrv_drain_all();
> > > >  
> > > >      xen_invalidate_map_cache_single(mapcache);
> > > > +    if (0)
> > > >      xen_invalidate_map_cache_single(mapcache_grants);
> > > >  }
> > > >  
> > > > I did the testing with libvirt, the domU.cfg equivalent looks like this:
> > > > maxmem = 4096
> > > > memory = 2048
> > > > maxvcpus = 4
> > > > vcpus = 2
> > > > pae = 1
> > > > acpi = 1
> > > > apic = 1
> > > > viridian = 0
> > > > rtc_timeoffset = 0
> > > > localtime = 0
> > > > on_poweroff = "destroy"
> > > > on_reboot = "destroy"
> > > > on_crash = "destroy"
> > > > device_model_override = "/usr/lib64/qemu-9.1/bin/qemu-system-i386"
> > > > sdl = 0
> > > > vnc = 1
> > > > vncunused = 1
> > > > vnclisten = "127.0.0.1"
> > > > vif = [ "mac=52:54:01:23:63:29,bridge=br0,script=vif-bridge" ]
> > > > parallel = "none"
> > > > serial = "pty"
> > > > builder = "hvm"
> > > > kernel = "/bug1236329/linux"
> > > > ramdisk = "/bug1236329/initrd"
> > > > cmdline = "console=ttyS0,115200n8 quiet ignore_loglevel""
> > > > boot = "c" 
> > > > disk = [ "format=qcow2,vdev=hda,access=rw,backendtype=qdisk,target=/bug1236329/sles12sp5.qcow2" ]
> > > > usb = 1
> > > > usbdevice = "tablet"
> > > > 
> > > > Any idea what can be done to restore boot times?
> > > 
> > > 
> > > A guess is that it's taking a long time to walk the grants mapcache
> > > when invalidating (in QEMU). Despite it being unused and empty. We
> > > could try to find a way to keep track of usage and do nothing when
> > > invalidating an empty/unused cache.
> > 
> > If mapcache_grants is unused and empty, the call to
> > xen_invalidate_map_cache_single(mapcache_grants) should be really fast?
> 
> Yes, I agree but looking at the invalidation code it looks like if we're
> unconditionally walking all the buckets in the hash-table...
> 
> 
> > 
> > I think probably it might be the opposite: mapcache_grants is utilized,
> > so going through all the mappings in xen_invalidate_map_cache_single
> > takes time.
> 
> The reason I don't think it's being used is because we've only enabled
> grants for PVH machines and Olaf runs HVM machines, so QEMU would never
> end up mapping grants for DMA.
 
Oh, I see! In that case we could have a trivial check on mc->last_entry
== NULL as fast path, something like:

if ( mc->last_entry == NULL )
    return;

at the beginning of xen_invalidate_map_cache_single?
 
 
> > However, I wonder if it is really needed. At least in the PoD case, the
> > reason for the IOREQ_TYPE_INVALIDATE request is that the underlying DomU
> > memory has changed. But that doesn't affect the grant mappings, because
> > those are mappings of other domains' memory.
> > 
> > So I am thinking whether we should remove the call to
> > xen_invalidate_map_cache_single(mapcache_grants) ?
> 
> Good point!
 
Let's see how the discussion evolves on that point

 
> > Adding x86 maintainers: do we need to flush grant table mappings for the
> > PV backends running in QEMU when Xen issues a IOREQ_TYPE_INVALIDATE
> > request to QEMU?



From xen-devel-bounces@lists.xenproject.org Thu Jan 30 04:56:26 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Jan 2025 04:56:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879370.1289576 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdMb3-0004sk-Pa; Thu, 30 Jan 2025 04:56:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879370.1289576; Thu, 30 Jan 2025 04:56:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdMb3-0004sd-Ml; Thu, 30 Jan 2025 04:56:09 +0000
Received: by outflank-mailman (input) for mailman id 879370;
 Thu, 30 Jan 2025 04:56:08 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=WYlJ=UW=invisiblethingslab.com=marmarek@srs-se1.protection.inumbo.net>)
 id 1tdMb2-0004sU-Eh
 for xen-devel@lists.xenproject.org; Thu, 30 Jan 2025 04:56:08 +0000
Received: from fhigh-b8-smtp.messagingengine.com
 (fhigh-b8-smtp.messagingengine.com [202.12.124.159])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7fde40bc-dec6-11ef-99a4-01e77a169b0f;
 Thu, 30 Jan 2025 05:56:01 +0100 (CET)
Received: from phl-compute-10.internal (phl-compute-10.phl.internal
 [10.202.2.50])
 by mailfhigh.stl.internal (Postfix) with ESMTP id 6C032254015B;
 Wed, 29 Jan 2025 23:55:59 -0500 (EST)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-10.internal (MEProxy); Wed, 29 Jan 2025 23:55:59 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 29 Jan 2025 23:55:56 -0500 (EST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 7fde40bc-dec6-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm3; t=1738212959;
	 x=1738299359; bh=WcWEhE8zpmeG9E46SMEpHiqP+tJawc+Geu7OtXAUW+s=; b=
	Fv1sqzjAA3y2QqTzLmcwn0ZV/hZXeiILMJ2jRhgy+NfQoq+98A9q+8sX8mV2amEe
	ufbxtoVlpvv5Oy7jrSHqyRYvm0xbpjSj2XG9DBCtOsdZ4BOCCM7J2F5Q951nyG2Z
	SrHKMP5PGtzdF2WheJP/oTD3aJwCKLvVA2xs1KGY6o1F6k8r5fKW085luN/6mRR+
	GC8cyDm12tkwp28YsKFZ+bvoBHArOJaYJ9DFt45Sd0iAu3WBhoznnXUTd9dV26We
	I4U3W7X82Pw1bS4k0MyMKh9NfZMU6Pnp9nn6EcFVSQJSdfrlH27MxPa4gFqD6IIc
	RARaKan1EVl1ohOP9M52aw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:subject:subject:to
	:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=
	1738212959; x=1738299359; bh=WcWEhE8zpmeG9E46SMEpHiqP+tJawc+Geu7
	OtXAUW+s=; b=a2pEFFSbVnK71YCxy8suDB0XaatF027xIOnZl0EqQOpsBMB1hZG
	6P0MgfiZ2HmnqeWMz2d7JvGht38XV3lYpSd1hvVPwy54EztpFf1xWsvEkxuYSlcC
	emZSeDYSqk0ya/jywiyCKd+P1S7HO0cskJVxnU9SWzkxkhTKTlm1OJzyeYSMueOM
	bCSrw4IY0bITyICu0iwb3c3pm0mhmpCaO3rFfDNTMb4OeisC0oneGEkPuGsgpgQl
	IX4tsYP9jfK8fTrZs38un1dNfFV23+72+d8lqrFe9mrr3G+UuDIcysdqYZDucrIO
	DiTtTAKJP80pI0RVqbhCk0sokSSlSlRkPjg==
X-ME-Sender: <xms:XgabZ09sH-wC86UC0nxZnJgvrD2akNsfY-SM2vF8CSfKTXUUf__mvg>
    <xme:XgabZ8szemd9P9hLTSx0xIvf81lkAS8rmgir-UcoVu5ir0iViaUb_kF6yt0BassAa
    pad5lwd47rJ8g>
X-ME-Received: <xmr:XgabZ6DHFJqtlKsOGc3eNO1of70hOnKQLbA90kugaGJUh54cpaskb-akK_m7AnskS1XVuRBywKFFKym2Rw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdegledtucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
    rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
    htshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtjeen
    ucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomh
    grrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggft
    rfgrthhtvghrnhepuddufedvieeiteeivedvfeelfedvudegveffledvleegudeiveffle
    eitefhfeejnecuffhomhgrihhnpeigvghnrdhorhhgpdhgihhthhhusgdrtghomhenucev
    lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrh
    gvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthho
    peduuddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohephhgvlhhgrggrsheskhgvrh
    hnvghlrdhorhhgpdhrtghpthhtohepsghhvghlghgrrghssehgohhoghhlvgdrtghomhdp
    rhgtphhtthhopehjghhrohhsshesshhushgvrdgtohhmpdhrtghpthhtoheprhhoghgvrh
    drphgruhestghithhrihigrdgtohhmpdhrtghpthhtohepsghorhhishdrohhsthhrohhv
    shhkhiesohhrrggtlhgvrdgtohhmpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhish
    htshdrgigvnhhprhhojhgvtghtrdhorhhgpdhrtghpthhtoheplhhinhhugidqkhgvrhhn
    vghlsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheprhgvghhrvghsshhioh
    hnsheslhhishhtshdrlhhinhhugidruggvvhdprhgtphhtthhopehnsggusehnsggurdhn
    rghmvg
X-ME-Proxy: <xmx:XgabZ0crllJAlgvCGhF2V_oLwcdrgd3Vy_rLNOzQ18bjfflXca1iow>
    <xmx:XgabZ5P7icjw1tz-tKm4hnfvCTXIUAJjZFyY_JjBRxvgRuDEdvrKgg>
    <xmx:XgabZ-nLMEGsyUP-LmXCSMCblZQQ5NS0gamuVDfMeennnnGAVeUxYQ>
    <xmx:XgabZ7u5YxT4Z9kWRpmmvebwyy_KIBYnJggJz4jhdOfesY8ahA5EVA>
    <xmx:XwabZ-mqJfPjcyQ-_mB7ksK07xwyBhfw4VnhkFG8wB2FzVC41Y0-mR2Q>
Feedback-ID: i1568416f:Fastmail
Date: Thu, 30 Jan 2025 05:55:55 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	=?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	linux-kernel@vger.kernel.org, regressions@lists.linux.dev,
	Felix Fietkau <nbd@nbd.name>, Lorenzo Bianconi <lorenzo@kernel.org>,
	Ryder Lee <ryder.lee@mediatek.com>
Subject: Re: Config space access to Mediatek MT7922 doesn't work after device
 reset in Xen PV dom0 (regression, Linux 6.12)
Message-ID: <Z5sGW4b0pMtm38Y-@mail-itl>
References: <Z5mOKQUrgeF_r6te@mail-itl>
 <20250129184825.GA484760@bhelgaas>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="J/cW/5xtZf/8V1JK"
Content-Disposition: inline
In-Reply-To: <20250129184825.GA484760@bhelgaas>


--J/cW/5xtZf/8V1JK
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Thu, 30 Jan 2025 05:55:55 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	=?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	linux-kernel@vger.kernel.org, regressions@lists.linux.dev,
	Felix Fietkau <nbd@nbd.name>, Lorenzo Bianconi <lorenzo@kernel.org>,
	Ryder Lee <ryder.lee@mediatek.com>
Subject: Re: Config space access to Mediatek MT7922 doesn't work after device
 reset in Xen PV dom0 (regression, Linux 6.12)

On Wed, Jan 29, 2025 at 12:48:25PM -0600, Bjorn Helgaas wrote:
> On Wed, Jan 29, 2025 at 03:10:49AM +0100, Marek Marczykowski-G=C3=B3recki=
 wrote:
> > On Tue, Jan 28, 2025 at 07:15:26PM -0600, Bjorn Helgaas wrote:
> > > On Fri, Jan 17, 2025 at 01:05:30PM +0100, Marek Marczykowski-G=C3=B3r=
ecki wrote:
> > > > After updating PV dom0 to Linux 6.12, The Mediatek MT7922 device re=
ports
> > > > all 0xff when accessing its config space. This happens only after d=
evice
> > > > reset (which is also triggered when binding the device to the
> > > > xen-pciback driver).
> > >=20
> > > Thanks for the report and for all the debugging you've already done!
> > >=20
> > > > Reproducer:
> > > >=20
> > > >     # lspci -xs 01:00.0
> > > >     01:00.0 Network controller: MEDIATEK Corp. MT7922 802.11ax PCI =
Express Wireless Network Adapter
> > > >     00: c3 14 16 06 00 00 10 00 00 00 80 02 10 00 00 00
> > > >     ...
> > > >     # echo 1 > /sys/bus/pci/devices/0000:01:00.0/reset
> > > >     # lspci -xs 01:00.0
> > > >     01:00.0 Network controller: MEDIATEK Corp. MT7922 802.11ax PCI =
Express Wireless Network Adapter
> > > >     00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > > >
> > > > The same operation done on Linux 6.12 running without Xen works fin=
e.
> > > >=20
> > > > git bisect points at:
> > > >=20
> > > >     commit d591f6804e7e1310881c9224d72247a2b65039af
> > > >     Author: Bjorn Helgaas <bhelgaas@google.com>
> > > >     Date:   Tue Aug 27 18:48:46 2024 -0500
> > > >=20
> > > >     PCI: Wait for device readiness with Configuration RRS
> > > >=20
> > > > part of that commit:
> > > > @@ -1311,9 +1320,15 @@ static int pci_dev_wait(struct pci_dev *dev,=
 char *reset_type, int timeout)
> > > >                         return -ENOTTY;
> > > >                 }
> > > > =20
> > > > -               pci_read_config_dword(dev, PCI_COMMAND, &id);
> > > > -               if (!PCI_POSSIBLE_ERROR(id))
> > > > -                       break;
> > > > +               if (root && root->config_crs_sv) {
> > > > +                       pci_read_config_dword(dev, PCI_VENDOR_ID, &=
id);
> > > > +                       if (!pci_bus_crs_vendor_id(id))
> > > > +                               break;
> > > > +               } else {
> > > > +                       pci_read_config_dword(dev, PCI_COMMAND, &id=
);
> > > > +                       if (!PCI_POSSIBLE_ERROR(id))
> > > > +                               break;
> > > > +               }
> > > > =20
> > > >    =20
> > > > Adding some debugging, the PCI_VENDOR_ID read in pci_dev_wait() ret=
urns
> > > > initially 0xffffffff. If I extend the condition with
> > > > "&& !PCI_POSSIBLE_ERROR(id)", then the issue disappear. But reading=
 the
> > > > patch description, it would break VF.
> > > > I'm not sure where the issue is, but given it breaks only when runn=
ing
> > > > with Xen, I guess something is wrong with "Configuration RRS Softwa=
re
> > > > Visibility" in that case.
> > >=20
> > > I'm missing something.  If you get 0xffffffff, that is not the 0x0001
> > > Vendor ID, so pci_dev_wait() should exit immediately. =20
> >=20
> > I'm not sure what is going on there either, but my _guess_ is that the
> > loop exits too early due to the above. And it makes some further actions
> > to fail.
>=20
> Seems like a good guess worth investigating.  Maybe log all config
> accesses to this device after the FLR and see what we're doing?

I've added logging of all config read/write to this device. Full log at
[1].

A little explanation:
- it's done in pci_conf_read/pci_conf_write in https://xenbits.xen.org/gitw=
eb/?p=3Dxen.git;a=3Dblob;f=3Dxen/arch/x86/pci.c;h=3D97b792e578f109319446608=
1ad3651ade21cae7d;hb=3DHEAD
- cf8 means cf8 port value (BDF + register)
- bytes is read/write size (1/2/4)
- offset is the offset in the register (on top of cf8), but not in data
- data is either retrieved value, or written value, depending on
  function
- it's logging only accesses to 01:00.0

interesting part:

lspci before reset:
(XEN) d0v3 conf read cf8 0x80010000 bytes 4 offset 0 data 0x61614c3
(XEN) d0v3 conf read cf8 0x80010004 bytes 4 offset 0 data 0x100000
(XEN) d0v3 conf read cf8 0x80010008 bytes 4 offset 0 data 0x2800000
(XEN) d0v3 conf read cf8 0x8001000c bytes 4 offset 0 data 0x10
(XEN) d0v3 conf read cf8 0x80010010 bytes 4 offset 0 data 0x1090000c
(XEN) d0v3 conf read cf8 0x80010014 bytes 4 offset 0 data 0x80
(XEN) d0v3 conf read cf8 0x80010018 bytes 4 offset 0 data 0x90b00004
(XEN) d0v3 conf read cf8 0x8001001c bytes 4 offset 0 data 0
(XEN) d0v3 conf read cf8 0x80010020 bytes 4 offset 0 data 0
(XEN) d0v3 conf read cf8 0x80010024 bytes 4 offset 0 data 0
(XEN) d0v3 conf read cf8 0x80010028 bytes 4 offset 0 data 0
(XEN) d0v3 conf read cf8 0x8001002c bytes 4 offset 0 data 0xe61614c3
(XEN) d0v3 conf read cf8 0x80010030 bytes 4 offset 0 data 0
(XEN) d0v3 conf read cf8 0x80010034 bytes 4 offset 0 data 0x80
(XEN) d0v3 conf read cf8 0x80010038 bytes 4 offset 0 data 0
(XEN) d0v3 conf read cf8 0x8001003c bytes 4 offset 0 data 0x1ff
(XEN) d0v3 conf read cf8 0x80010080 bytes 4 offset 0 data 0x2e010
(XEN) d0v3 conf read cf8 0x800100e0 bytes 4 offset 0 data 0x18af805
(XEN) d0v3 conf read cf8 0x800100f8 bytes 4 offset 0 data 0xc8030001

reset:
(XEN) d0v1 conf read cf8 0x800100fc bytes 2 offset 0 data 0x8
(XEN) d0v1 conf read cf8 0x800100fc bytes 2 offset 0 data 0x8
(XEN) d0v1 conf read cf8 0x8001008c bytes 4 offset 0 data 0x145dc12
(XEN) d0v1 conf read cf8 0x80010000 bytes 4 offset 0 data 0x61614c3
(XEN) d0v1 conf read cf8 0x80010004 bytes 4 offset 0 data 0x100000
(XEN) d0v1 conf read cf8 0x80010008 bytes 4 offset 0 data 0x2800000
(XEN) d0v1 conf read cf8 0x8001000c bytes 4 offset 0 data 0x10
(XEN) d0v1 conf read cf8 0x80010010 bytes 4 offset 0 data 0x1090000c
(XEN) d0v1 conf read cf8 0x80010014 bytes 4 offset 0 data 0x80
(XEN) d0v1 conf read cf8 0x80010018 bytes 4 offset 0 data 0x90b00004
(XEN) d0v1 conf read cf8 0x8001001c bytes 4 offset 0 data 0
(XEN) d0v1 conf read cf8 0x80010020 bytes 4 offset 0 data 0
(XEN) d0v1 conf read cf8 0x80010024 bytes 4 offset 0 data 0
(XEN) d0v1 conf read cf8 0x80010028 bytes 4 offset 0 data 0
(XEN) d0v1 conf read cf8 0x8001002c bytes 4 offset 0 data 0xe61614c3
(XEN) d0v1 conf read cf8 0x80010030 bytes 4 offset 0 data 0
(XEN) d0v1 conf read cf8 0x80010034 bytes 4 offset 0 data 0x80
(XEN) d0v1 conf read cf8 0x80010038 bytes 4 offset 0 data 0
(XEN) d0v1 conf read cf8 0x8001003c bytes 4 offset 0 data 0x1ff
(XEN) d0v1 conf read cf8 0x80010088 bytes 2 offset 0 data 0x2910
(XEN) d0v1 conf read cf8 0x80010090 bytes 2 offset 0 data 0x1c2
(XEN) d0v1 conf read cf8 0x800100a8 bytes 2 offset 0 data 0x400
(XEN) d0v1 conf read cf8 0x800100b0 bytes 2 offset 0 data 0x2
(XEN) d0v1 conf read cf8 0x80010004 bytes 2 offset 2 data 0x10
(XEN) d0v1 conf read cf8 0x80010034 bytes 1 offset 0 data 0x80
(XEN) d0v1 conf read cf8 0x80010080 bytes 2 offset 0 data 0xe010
(XEN) d0v1 conf read cf8 0x800100e0 bytes 2 offset 0 data 0xf805
(XEN) d0v1 conf read cf8 0x800100f8 bytes 2 offset 0 data 0x1
(XEN) d0v1 conf write cf8 0x80010004 bytes 2 offset 0 data 0x400
(XEN) d0v1 conf read cf8 0x80010088 bytes 2 offset 2 data 0x9
(XEN) d0v1 conf read cf8 0x80010088 bytes 2 offset 0 data 0x2910
(XEN) d0v1 conf write cf8 0x80010088 bytes 2 offset 0 data 0xa910
(XEN) d0v2 conf read cf8 0x80010000 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf read cf8 0x80010090 bytes 2 offset 0 data 0xffff
(XEN) d0v2 conf write cf8 0x80010090 bytes 2 offset 0 data 0xfffc
(XEN) d0v2 conf write cf8 0x80010090 bytes 2 offset 0 data 0xffff
(XEN) d0v2 conf write cf8 0x80010088 bytes 2 offset 0 data 0x2910
(XEN) d0v2 conf write cf8 0x80010090 bytes 2 offset 0 data 0x1c2
(XEN) d0v2 conf write cf8 0x800100a8 bytes 2 offset 0 data 0x400
(XEN) d0v2 conf write cf8 0x800100b0 bytes 2 offset 0 data 0x2
(XEN) d0v2 conf read cf8 0x8001003c bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x8001003c bytes 4 offset 0 data 0x1ff
(XEN) d0v2 conf read cf8 0x80010038 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010038 bytes 4 offset 0 data 0
(XEN) d0v2 conf read cf8 0x80010034 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010034 bytes 4 offset 0 data 0x80
(XEN) d0v2 conf read cf8 0x80010030 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010030 bytes 4 offset 0 data 0
(XEN) d0v2 conf read cf8 0x8001002c bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x8001002c bytes 4 offset 0 data 0xe61614c3
(XEN) d0v2 conf read cf8 0x80010028 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010028 bytes 4 offset 0 data 0
(XEN) d0v2 conf read cf8 0x80010024 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010024 bytes 4 offset 0 data 0
(XEN) d0v2 conf read cf8 0x80010024 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010024 bytes 4 offset 0 data 0
(XEN) d0v2 conf read cf8 0x80010024 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010024 bytes 4 offset 0 data 0
(XEN) d0v2 conf read cf8 0x80010024 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010024 bytes 4 offset 0 data 0
(XEN) d0v2 conf read cf8 0x80010024 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010024 bytes 4 offset 0 data 0
(XEN) d0v2 conf read cf8 0x80010024 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010024 bytes 4 offset 0 data 0
(XEN) d0v2 conf read cf8 0x80010024 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010024 bytes 4 offset 0 data 0
(XEN) d0v2 conf read cf8 0x80010024 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010024 bytes 4 offset 0 data 0
(XEN) d0v2 conf read cf8 0x80010024 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010024 bytes 4 offset 0 data 0
(XEN) d0v2 conf read cf8 0x80010024 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010024 bytes 4 offset 0 data 0
(XEN) d0v2 conf read cf8 0x80010024 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010024 bytes 4 offset 0 data 0
(XEN) d0v2 conf read cf8 0x80010020 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010020 bytes 4 offset 0 data 0
(XEN) d0v2 conf read cf8 0x80010020 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010020 bytes 4 offset 0 data 0
(XEN) d0v2 conf read cf8 0x80010020 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010020 bytes 4 offset 0 data 0
(XEN) d0v2 conf read cf8 0x80010020 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010020 bytes 4 offset 0 data 0
(XEN) d0v2 conf read cf8 0x80010020 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010020 bytes 4 offset 0 data 0
(XEN) d0v2 conf read cf8 0x80010020 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010020 bytes 4 offset 0 data 0
(XEN) d0v2 conf read cf8 0x80010020 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010020 bytes 4 offset 0 data 0
(XEN) d0v2 conf read cf8 0x80010020 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010020 bytes 4 offset 0 data 0
(XEN) d0v2 conf read cf8 0x80010020 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010020 bytes 4 offset 0 data 0
(XEN) d0v2 conf read cf8 0x80010020 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010020 bytes 4 offset 0 data 0
(XEN) d0v2 conf read cf8 0x80010020 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010020 bytes 4 offset 0 data 0
(XEN) d0v2 conf read cf8 0x8001001c bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x8001001c bytes 4 offset 0 data 0
(XEN) d0v2 conf read cf8 0x8001001c bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x8001001c bytes 4 offset 0 data 0
(XEN) d0v2 conf read cf8 0x8001001c bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x8001001c bytes 4 offset 0 data 0
(XEN) d0v2 conf read cf8 0x8001001c bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x8001001c bytes 4 offset 0 data 0
(XEN) d0v2 conf read cf8 0x8001001c bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x8001001c bytes 4 offset 0 data 0
(XEN) d0v2 conf read cf8 0x8001001c bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x8001001c bytes 4 offset 0 data 0
(XEN) d0v2 conf read cf8 0x8001001c bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x8001001c bytes 4 offset 0 data 0
(XEN) d0v2 conf read cf8 0x8001001c bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x8001001c bytes 4 offset 0 data 0
(XEN) d0v2 conf read cf8 0x8001001c bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x8001001c bytes 4 offset 0 data 0
(XEN) d0v2 conf read cf8 0x8001001c bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x8001001c bytes 4 offset 0 data 0
(XEN) d0v2 conf read cf8 0x8001001c bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x8001001c bytes 4 offset 0 data 0
(XEN) d0v2 conf read cf8 0x80010018 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010018 bytes 4 offset 0 data 0x90b00004
(XEN) d0v2 conf read cf8 0x80010018 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010018 bytes 4 offset 0 data 0x90b00004
(XEN) d0v2 conf read cf8 0x80010018 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010018 bytes 4 offset 0 data 0x90b00004
(XEN) d0v2 conf read cf8 0x80010018 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010018 bytes 4 offset 0 data 0x90b00004
(XEN) d0v2 conf read cf8 0x80010018 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010018 bytes 4 offset 0 data 0x90b00004
(XEN) d0v2 conf read cf8 0x80010018 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010018 bytes 4 offset 0 data 0x90b00004
(XEN) d0v2 conf read cf8 0x80010018 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010018 bytes 4 offset 0 data 0x90b00004
(XEN) d0v2 conf read cf8 0x80010018 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010018 bytes 4 offset 0 data 0x90b00004
(XEN) d0v2 conf read cf8 0x80010018 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010018 bytes 4 offset 0 data 0x90b00004
(XEN) d0v2 conf read cf8 0x80010018 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010018 bytes 4 offset 0 data 0x90b00004
(XEN) d0v2 conf read cf8 0x80010018 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010018 bytes 4 offset 0 data 0x90b00004
(XEN) d0v2 conf read cf8 0x80010014 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010014 bytes 4 offset 0 data 0x80
(XEN) d0v2 conf read cf8 0x80010014 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010014 bytes 4 offset 0 data 0x80
(XEN) d0v2 conf read cf8 0x80010014 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010014 bytes 4 offset 0 data 0x80
(XEN) d0v2 conf read cf8 0x80010014 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010014 bytes 4 offset 0 data 0x80
(XEN) d0v2 conf read cf8 0x80010014 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010014 bytes 4 offset 0 data 0x80
(XEN) d0v2 conf read cf8 0x80010014 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010014 bytes 4 offset 0 data 0x80
(XEN) d0v2 conf read cf8 0x80010014 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010014 bytes 4 offset 0 data 0x80
(XEN) d0v2 conf read cf8 0x80010014 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010014 bytes 4 offset 0 data 0x80
(XEN) d0v2 conf read cf8 0x80010014 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010014 bytes 4 offset 0 data 0x80
(XEN) d0v2 conf read cf8 0x80010014 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010014 bytes 4 offset 0 data 0x80
(XEN) d0v2 conf read cf8 0x80010014 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010014 bytes 4 offset 0 data 0x80
(XEN) d0v2 conf read cf8 0x80010010 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010010 bytes 4 offset 0 data 0x1090000c
(XEN) d0v2 conf read cf8 0x80010010 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010010 bytes 4 offset 0 data 0x1090000c
(XEN) d0v2 conf read cf8 0x80010010 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010010 bytes 4 offset 0 data 0x1090000c
(XEN) d0v2 conf read cf8 0x80010010 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010010 bytes 4 offset 0 data 0x1090000c
(XEN) d0v2 conf read cf8 0x80010010 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010010 bytes 4 offset 0 data 0x1090000c
(XEN) d0v2 conf read cf8 0x80010010 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010010 bytes 4 offset 0 data 0x1090000c
(XEN) d0v2 conf read cf8 0x80010010 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010010 bytes 4 offset 0 data 0x1090000c
(XEN) d0v2 conf read cf8 0x80010010 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010010 bytes 4 offset 0 data 0x1090000c
(XEN) d0v2 conf read cf8 0x80010010 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010010 bytes 4 offset 0 data 0x1090000c
(XEN) d0v2 conf read cf8 0x80010010 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010010 bytes 4 offset 0 data 0x1090000c
(XEN) d0v2 conf read cf8 0x80010010 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010010 bytes 4 offset 0 data 0x1090000c
(XEN) d0v2 conf read cf8 0x8001000c bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x8001000c bytes 4 offset 0 data 0x10
(XEN) d0v2 conf read cf8 0x80010008 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010008 bytes 4 offset 0 data 0x2800000
(XEN) d0v2 conf read cf8 0x80010004 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010004 bytes 4 offset 0 data 0x100000
(XEN) d0v2 conf read cf8 0x80010000 bytes 4 offset 0 data 0xffffffff
(XEN) d0v2 conf write cf8 0x80010000 bytes 4 offset 0 data 0x61614c3
(XEN) d0v2 conf read cf8 0x80010004 bytes 2 offset 2 data 0xffff
(XEN) d0v2 conf read cf8 0x80010034 bytes 1 offset 0 data 0xff
(XEN) d0v2 conf read cf8 0x800100fc bytes 2 offset 0 data 0xffff


[1] https://gist.github.com/marmarek/b4391c71801145e52590e877c559c5e0

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

--J/cW/5xtZf/8V1JK
Content-Type: application/pgp-signature; name="signature.asc"

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmebBlsACgkQ24/THMrX
1yyn3Af7BrI+9JP20AopXgQiUzuBTfGkVg1dJCDcGt5VcGlj2MKaWKDWz/5RHlmZ
lokPGFHb/IVaLk7VQVTmFEtjoVuL65KUFS7yfLsnPGwTIQ708p0P9KG8LJM0jQF7
QbQ7kGmkUsXcemvw+RGgxpbT6s7UggPMGD+xguJlKw4TiMbo+sdxcIHE1iMX7zeD
val/Cc3Z8brc08I+l8cn6Hl7T1dJhXrCnHXH+a2NHijzCslYcP2YGnR2j0R8+rl2
5agqXNGhRvakDUDcodasD2VdEzb/f2YW4YmERn5AsVFWABek46o2LoFBS5PWgqbY
dQAI1RYFaeSGyny5q3djqSAeZCAL5Q==
=uBH5
-----END PGP SIGNATURE-----

--J/cW/5xtZf/8V1JK--


From xen-devel-bounces@lists.xenproject.org Thu Jan 30 05:27:45 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Jan 2025 05:27:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879378.1289586 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdN5Y-0000dA-5R; Thu, 30 Jan 2025 05:27:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879378.1289586; Thu, 30 Jan 2025 05:27:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdN5Y-0000d3-1u; Thu, 30 Jan 2025 05:27:40 +0000
Received: by outflank-mailman (input) for mailman id 879378;
 Thu, 30 Jan 2025 05:27:38 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=J50r=UW=oracle.com=harshvardhan.j.jha@srs-se1.protection.inumbo.net>)
 id 1tdN5W-0000cx-I0
 for xen-devel@lists.xenproject.org; Thu, 30 Jan 2025 05:27:38 +0000
Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com
 [205.220.165.32]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e8596f09-deca-11ef-99a4-01e77a169b0f;
 Thu, 30 Jan 2025 06:27:35 +0100 (CET)
Received: from pps.filterd (m0333521.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 50U27Gfk017331;
 Thu, 30 Jan 2025 05:27:30 GMT
Received: from phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com
 (phxpaimrmta01.appoci.oracle.com [138.1.114.2])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 44g0bw0kfu-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Thu, 30 Jan 2025 05:27:29 +0000 (GMT)
Received: from pps.filterd
 (phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1])
 by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (8.18.1.2/8.18.1.2)
 with ESMTP id 50U52fLb036973; Thu, 30 Jan 2025 05:27:29 GMT
Received: from nam10-mw2-obe.outbound.protection.outlook.com
 (mail-mw2nam10lp2046.outbound.protection.outlook.com [104.47.55.46])
 by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id
 44cpdamsew-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Thu, 30 Jan 2025 05:27:29 +0000
Received: from PH7PR10MB6505.namprd10.prod.outlook.com (2603:10b6:510:200::11)
 by CH0PR10MB4875.namprd10.prod.outlook.com (2603:10b6:610:de::7) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8398.18; Thu, 30 Jan
 2025 05:27:26 +0000
Received: from PH7PR10MB6505.namprd10.prod.outlook.com
 ([fe80::83d9:1bf1:52cf:df54]) by PH7PR10MB6505.namprd10.prod.outlook.com
 ([fe80::83d9:1bf1:52cf:df54%6]) with mapi id 15.20.8398.017; Thu, 30 Jan 2025
 05:27:26 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e8596f09-deca-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=
	corp-2023-11-20; bh=B48FXnNjVoTmGaIivTnb6qANYjJR4exf89gkaEt+BJ4=; b=
	dvAiJuebzKIqjn36D0bnrPOZsIYr4Rhbf5HUOi44OfGsqzJKizjWNloPufsZmCPS
	9PHSb3zU8+7+JkBnfjlMn3BpPXsevzL1OBH9qLgTK+ns0W8YyxczbaxS+/ZwbWWV
	XVBcRac7p1znqtVDG+F6ONRYSoJqTgfjEKnsqj+4vlP4uUSGXRR3t93ZUqBi8BMI
	cm86VsDX8f55SfJd2VTERbQ9qhs6diouTFHUMXnmgkMvlkahhTyf3E28XmFnYDOW
	UExUFImwGbJstdBe2wPFElGugZVRpmuY7QwYVix8FN39FhKqHSYTDZb1dHJGRxsJ
	a+e1P+Dw92ZS++GUQgkgJQ==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=I0KWyX1B6JXWLh87aNHd7aIlITdAITFndN6hqZUNZqyYEBH0AetIVEYz1bB7BYcQ9uipHtehldANIyRaQpl55Lkf2MkYh1pcCgIcwQgJSpEcCH5ey6q2y1AuwwaPPG3xbpDldGMiruss72VLM6v3XEtywpqmt5dLr76xfpvKIoyrQp/pS3pwA1OuTT7oh4l37TVhr1IJX7mKpSmBWnr1g/Uz1DmWTPV9ifcrHJdosuWcv7NXeGnX/abFPOjm+nQyO6fBOnqEXKFO+Sf4emopNvaYFWABKD4n3lzqO9xWm9Gw2njweIKQpNiXqfUuBjHI1PLPy6WBYK9kvaEerEHXbg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=B48FXnNjVoTmGaIivTnb6qANYjJR4exf89gkaEt+BJ4=;
 b=AugLG9B4ZU6jn+xwJi7OuoM6l7F0vtKSTIJJxtrpOAEeJZy0v1WlOFQk2YaYz516pVLDsEajc+8ZZBLor+YxaQfheDEmAYpCUYpeppLg5yhUMzHYjVf7q3jA9PdCLqnt/v37ekR9SUCTSO4blmmsE12H3RVqVo9pE16eChzK0NIqnr7uZ9VCTMHg97NWbttlFvd87ftJjAspEMrCQVi8143moSZuJeqi6ymyfHw/zK3lwJjBt/up6jiBJoqk5oKOkbV+SNSgE/emDgTBUlhJWPuDFSmbnzcDWu1ECwop5mXwcPQzIPr0VPICr9LuQEDsXnpWspa7DulWRDGM0q9bLw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
 dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=B48FXnNjVoTmGaIivTnb6qANYjJR4exf89gkaEt+BJ4=;
 b=OZA+VIxi6IG5HtjnUdfDDM5N57yvDgD07P+pNe144ruZbH1XPPwDJAhgro52eUI1n3fBO2mvajEM/bw/abFAxdQIgOCnHBWajmjUxz5/HrDzQlNRBKgaqlu8zhAeRN5cB0J/jpGRkSsc9AY5GQGfxAO6rcn+RFjRQTAXajr+7RE=
Message-ID: <827aceff-28ed-4922-b841-b7dd06c082b1@oracle.com>
Date: Thu, 30 Jan 2025 10:57:17 +0530
User-Agent: Mozilla Thunderbird
Subject: Re: v5.4.289 failed to boot with error megasas_build_io_fusion 3219
 sge_count (-12) is out of range
To: Stefano Stabellini <sstabellini@kernel.org>,
        =?UTF-8?B?SsO8cmdlbiBHcm8=?=
 =?UTF-8?B?w58=?= <jgross@suse.com>
Cc: Greg KH <gregkh@linuxfoundation.org>,
        Konrad Wilk
 <konrad.wilk@oracle.com>,
        Boris Ostrovsky <boris.ostrovsky@oracle.com>,
        "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>,
        stable@vger.kernel.org
References: <7dc143fa-4a48-440b-b624-ac57a361ac74@oracle.com>
 <9dd91f6e-1c66-4961-994e-dbda87d69dad@oracle.com>
 <2025012919-series-chaps-856e@gregkh>
 <8eb33b38-23e1-4e43-8952-3f2b05660236@oracle.com>
 <2025012936-finalize-ducktail-c524@gregkh>
 <1f017284-1a29-49d8-b0d9-92409561990e@oracle.com>
 <2025012956-jiffy-condone-3137@gregkh>
 <1f225b8d-d958-4304-829e-8798884d9b6b@oracle.com>
 <83bd90c7-8879-4462-9548-bb5b69cac39e@suse.com>
 <b4ab0246-3846-41d1-8e84-64bd7fefc089@oracle.com>
 <de6912ad-3dba-4d66-8ca2-71a0aa09172c@suse.com>
 <alpine.DEB.2.22.394.2501291401290.11632@ubuntu-linux-20-04-desktop>
Content-Language: en-US
From: Harshvardhan Jha <harshvardhan.j.jha@oracle.com>
In-Reply-To: <alpine.DEB.2.22.394.2501291401290.11632@ubuntu-linux-20-04-desktop>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: SI2PR02CA0043.apcprd02.prod.outlook.com
 (2603:1096:4:196::12) To PH7PR10MB6505.namprd10.prod.outlook.com
 (2603:10b6:510:200::11)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH7PR10MB6505:EE_|CH0PR10MB4875:EE_
X-MS-Office365-Filtering-Correlation-Id: 73553d1a-e7b6-4162-d9bc-08dd40eec7cc
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?QmhrRUNjMklBbU53TnVtVU1ZY2JhY2hjVFNLYytHWjZJQVFCaVh0aks4UmZJ?=
 =?utf-8?B?cGcyY3NVYWZJVXBvZldFQkdpUVJGOVdYWmh6UmRnM1FOTUFrNUt4d3JvS3NI?=
 =?utf-8?B?Mm9Xa2VES25IQkVkK0NOUHBteDVNa1ZpWEgwSjBJTW9KQzd5RDRpcnphVlQ2?=
 =?utf-8?B?Nkl2czlqbVpFKzA5c09mMndFaHRjNERLUVhuL0lWdDFzaXVkQ1VIK0RaLzJC?=
 =?utf-8?B?MloyakNVeWNnb1ZYRjdkOEkxUkRFYUx0L0MvWk9sZmVjZVhMbzJ5a09ITmRO?=
 =?utf-8?B?SU01TXBEZUVXbXVNVENlRjdIQVVjaXRmR0VudWdGZ0JpVkRkbzcvNlIyS0Yx?=
 =?utf-8?B?dWx6UVIxNnlxellkVUc5RjI0TUhTM24wbnFXbTZsa000amUweXRVbjZaUm41?=
 =?utf-8?B?UGZaN3oxTDdJcU1raW05RVBCR2Fock1NNG1xS20zS1RLQlQ1ZGFUQjc1K1ZO?=
 =?utf-8?B?a3h6QVAyKzRid3B5UDdxaW1CaHcxaUZHL014am9ucmMxUU9lRzJRcUhEMDd0?=
 =?utf-8?B?V1lIVFFoVWRYRFltM0ZYUTJFMU1lR1pJZHdiMTY4M2Y0R3g5dTY2NXdzQTZ4?=
 =?utf-8?B?VTF2VG5zcHAvTFk0TlN6UndKbTJSdjllalUvZlpzUzRtWk5mQkpXQndHeUEx?=
 =?utf-8?B?K0ZkSENhMXp1YmRNV2FXRGpGTGgyZVFZWWNmRDVsUkhxVFE5ZW51Y040U2xZ?=
 =?utf-8?B?TnVKemVXdUQ3eDI3RWZOY0c5VlhwaDl2c1NnK2lQZ2dxN2RTbEJqcEZMYm5Z?=
 =?utf-8?B?dDJQdVhpQ25KVnFsaHdXVzNkVUpDQ2pHYW9PYWF1MVpQL3NHM0dPWFJXTGVz?=
 =?utf-8?B?T3lrYkoxN3VORmF2VHJ3SVMyTHY0MjlEb0ZJdnpCVWV3czI0MEtpRDR4dlpJ?=
 =?utf-8?B?aXIvaXJ3RGlkMnVDdVI5bE15RUZJWnRBZE9hMWszRkwrcy9OVENvZ0JoMHhV?=
 =?utf-8?B?SkROKzZETFNWTkZZTFgwcUdXbXNKTEJkTWgvMjl4WTNObXBsbnRuMXNqaWZk?=
 =?utf-8?B?RjMyNGVYQ1ZuaHJxMnRTbUZmSUU1NC9tMTg4b0NUOG4yejBDQUpmSTYyQzY0?=
 =?utf-8?B?OGkwZUlHcE5qT1F4bzlvWm1mdVlKajR6OVJ1WFNKbWxJdk9tdkczb0E4Z3lq?=
 =?utf-8?B?dEkrRS9ubW1ObjNPejA3NFRJd0Y4NFRNbXR3ellJNm1NazFORGtFUVUzdnhM?=
 =?utf-8?B?WEpLOUJSKytTZmI2UitZcVZCd3ZxMmVxUzFEQ3FUNDBkUUYxb1FXa3p4WmNP?=
 =?utf-8?B?a1JMNEw5aUk1RGFtWThZUUR2cXVNV3MzU3g3UkNDOG9OTDdyd0xqR3V5MXlB?=
 =?utf-8?B?VFJRZlgxNVBpZWxZQThOZyt0V0tTUWJ5TU9acEFRL2Q4SWx5a01JbXpBaWhI?=
 =?utf-8?B?bWpvb2IrY2NCVGpXTGVJa1cxbmU0T3VuTGJ6MFZuN1I3ZmQ1U1ZFa3hUTG1N?=
 =?utf-8?B?NHNQSDZURnpLdkhNY2l1Q3ZzTGdHWktuOExxMVhUdEU2T1MreS9tbWdPWjN2?=
 =?utf-8?B?WnRNVCtqaHpMZlNRNXRqbDJDRE5uR2hHTWtiREw2T2praDRoU3JBNVlWY2VV?=
 =?utf-8?B?ZEdubW9IMTV0TVRYTHVURGVQTzBTZXVqVzBWa0NXVjFBV0o0dk5VNDg2Wmt0?=
 =?utf-8?B?U3hvL0dwcmlMVXJKdnhrZVRwSlpWMm1ubERBT3hSODk0NFRQVXpOK05BZGpP?=
 =?utf-8?B?Zkxlc1VqakIyL3NWVXV6Q204NTgyYXJVVHd1MnRQYUkzci9xN2FEdHRJb242?=
 =?utf-8?B?bWJqLytyZkpuTVJiUGNFOXNSVHVwakxQaE42WUcyVWprYjdUVGE2SWp0WUVz?=
 =?utf-8?B?VXI1MzlyMGhqS212R3grQT09?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH7PR10MB6505.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?NUxza0Z4eDlFaUtpck90aUxmbEN1VGtia1owSkNEWDdRbW9lTytjcmJaQk1J?=
 =?utf-8?B?YTBpcVVKK2pTRGhzREZjcUNDMGFET1lFTnV0dXUreVFaUW1oczVTRFZidmxo?=
 =?utf-8?B?cXp0SkhyM3l6S3ZsLzRJTDhOMDM3cEtBaktyRGdxQTZhRnZnSlExcWFud0JR?=
 =?utf-8?B?Y2hqM3YxMjM5WlEzMmM3Wm9kcGlsSTBjU2FXNTdIWlFDdmlVekdoY1RGVzBq?=
 =?utf-8?B?bFIrNzFjYzlqdGk5L0tzc29UaStQeE9EM1dYU0tYcUFnaG5vaFJzSFVZa0Rm?=
 =?utf-8?B?a0JvQ1YvVGNTR2RsN1dzMGVPQWNMNUtvcXdjMGhnTjBXL1oySEJoQmNzVURE?=
 =?utf-8?B?bm56Qy9yQTl4empIQ0dqSHB0ajQvRnpSNFR1cWkwZHc2djF5YUsyWVo0NmR2?=
 =?utf-8?B?QmFTZEdwdzJ6YWxpdGtoWXA5S3VGNk5BRG1FL01nNzdTZ3ZHL2JHNnNnQWhl?=
 =?utf-8?B?dUdtTVhmQXE1TFJKNU9GYmtibEVaQmhOQUVDZ3lmcEZHKzZWTUxMRUFuSVZB?=
 =?utf-8?B?RjM5NUkwQVVmY1gvYTY5M0ExbUpmUk1yUXdyc0t4dkI3bVhnQktYS0xXbGJN?=
 =?utf-8?B?T3BGZVE0TVhobXFJWjVqNXZOMkFwMkNsK0dvbndWTmpVYjJ3Z1NpMUNjOWZU?=
 =?utf-8?B?NGRsdTBWckNHUXRodzZGL2RRQU80SnBmemRqYXNqTENpTVZUbWJldVFUZ1BW?=
 =?utf-8?B?WXkvK3U2eW01cXFtTDR1b0NpL0JQUkVMdEczV2RzV2p5anNjQ250bXZ2QzNz?=
 =?utf-8?B?dHZCNXRkWldjcjZ1RzNRRFVMNWJnczY4dXZMVkRYcU9RMlZQbytpNEZCazg3?=
 =?utf-8?B?UC9IeThQeFJuRHNlUEZXc1cvaXhpV2ZTQVgxMlRWTWZmWmRLSFhGM0xWeVJO?=
 =?utf-8?B?OTdySWZSRktLVXBCaDY0WFdqL2FLUDJwaWhNUVl6b0d3aXFwb2pTLzJuRVI5?=
 =?utf-8?B?Q0JlcjZQbDdrRXNrSGJkSm52Q0RXY2VEQ3MzaGtRRDVsSUN3aW1kOCt2ZElG?=
 =?utf-8?B?MnNiK1RkUUJmWURQTnVRY3R0MjBocExEcnFJa0YzN3RFMWRlWkRhcWVTK2U5?=
 =?utf-8?B?akVqTlpCVzNrY2RwZGNVWXZSQk44ZjJwMklsZ05YNnFwcTc0cUx3UEVwbzFE?=
 =?utf-8?B?NndUaEVxbnlBNmVFOWZKQmxzZWI4ckdiVUF0cy81VktLUE5KRG9uSFBaWkNa?=
 =?utf-8?B?Uk5xc0FndG1qWWtPNW9EaEFWOXJNeEd2UktaV2FvQUhXY1hOWGhIbjVXTFZm?=
 =?utf-8?B?ajdkQjlIS2F0RHFyRWxDWS9aK01HTHRsUlVud2NuS0Z0aUNnY2x3aDA2L3Zx?=
 =?utf-8?B?OXc3Z1d3Z2o5VDVYbVVUZnEzMHpvRElZa2svZWdadS9qUzkxbzd2Wm1JTzJ1?=
 =?utf-8?B?bnVTRWV2aWZDVklTK3Z5Vjk3dVJMdUZ4QWtYNkRCMnBGTmUxMURRTXRTdW12?=
 =?utf-8?B?dUpobWlzVmdNT0RjNll3SGlzR3pTdGVSVVZQWmVYeUJQMEw1YWxkdWN2NHd3?=
 =?utf-8?B?VnA0QmRSSVhjTEd3clNITVN6ak9UVUR1L3E5YXROV1VUZ2t5aTdwY3U1Rjkr?=
 =?utf-8?B?U1JsUGxkbWJha1lkeUJ0U0NHbVhRR0RDV1F5N0ZRc0FsUDd4a1IwRkwwTmdF?=
 =?utf-8?B?QmFSOFhyS2ZUZk4ycnM5d2J3UUYrdnBUWlhRejdaaGc2SElKZmFCaTN5WitZ?=
 =?utf-8?B?T01TMTNiZmczQ2pUdThrUUpiUHNPbktiKzd3U2hjaytJZ3BISE1CVUZSQU52?=
 =?utf-8?B?WDhzcmFGS2lSM1ZsMGQvSm1lUmNoYlY2b1VMeStZZnhIVkhnOTVwVUI1Wk9P?=
 =?utf-8?B?MnNBcGRHU0hYTWlaYXJldTk5d0NocmNXVEZFeTlKY0tJMGxqWUtSTlVQa0k3?=
 =?utf-8?B?SGQzVWhwa1IrMTJXcHNiVE1nQUNUMTRFa2FuUU9GZS9TSjU1Q3h3TlNuc3FF?=
 =?utf-8?B?REc2clVNQWpXTFlUUVMzZy9QcStEdFNZZjNqNmVQREYxWENzeTc3S1NTLzlN?=
 =?utf-8?B?R0c5UllvTW5FZ3lacHFwQjI1WnRsNzhYWjJmZWRMeVlqb3cySDB1R0hJZFJI?=
 =?utf-8?B?S0grZTVKeG5sZlNaL3lKRXJTTXVoQWYvMVVnL3lRSnp3ZjQvWFJ6ak9OR3F4?=
 =?utf-8?B?RHdCckpHRFYyLzFRUlpmNUN5VEVleDEyUmxOeFJmM2FnT1RqUGl0NVRxaHho?=
 =?utf-8?B?aGc9PQ==?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	6XMqzzSXbTigILxQi8dUJTs+2wd3BQMx51RlkYaPPoazKYGT6sosXdw/J1ZFnuA3+9kmDLYsWi0+ni8rc9RMu/va+JbwBtG2EFSKVZpp6zvgdm1kVZLluXNLQr9xX/8UecBzop64c15gofn2KK0n8/8ojKpuMBOUP9ttgOGtXfbEsa1YVinUAYGZoCdDkITNKTQC3kwRBW+Nn9FHF9UM0duBIlfqWqamVYw1GOHJRJC/MkSOgSbdsj23ig/v5vknYtef7Po0LFDJb/hGsWjvl/NGTaPJkO5nLkKjFigx4oMdkoSzQiLWuDqFyh1iZC0U7AlawlGbfdOU12u4kJKHQI0Onm7x5l8lj8ZeA3OJhUEWJNP+9TewvtjE4oqQ+7Kqw0vtRZUvJNV/GXRMwdsayqNxvhn3kovbq9t32qpaCVT32ffOoYvZMS0Jjb0G5n7/FPOY9Sh/0cLWCyTH7b3lU4m/MLsPdLx302ZMuig1VWPgdyxoVhO0CJB0+QyL9cRQKFxZMwDWOhXx2M4kubo2Eo8GVKKkaOufWgfxr3P+LX5ftnzVIbDpcsDruQ7wDPAA+bHqtWaP2zH/UhTU3eIqPvdLuus0B3Kpjj2Dxqvtabs=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 73553d1a-e7b6-4162-d9bc-08dd40eec7cc
X-MS-Exchange-CrossTenant-AuthSource: PH7PR10MB6505.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jan 2025 05:27:25.9373
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: pzzVrIGtUX+v2X9zaHKjxowIjfmImpf+fEyMM8QEZsuYmj2vFsUHtQdCScqCdjmVwLgz0YB4CSGntHd3NpLh0QDVJ5bDZEfm8KixZ8R9zmM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR10MB4875
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34
 definitions=2025-01-30_02,2025-01-29_01,2024-11-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 bulkscore=0 malwarescore=0
 mlxlogscore=999 suspectscore=0 spamscore=0 mlxscore=0 adultscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2411120000
 definitions=main-2501300039
X-Proofpoint-ORIG-GUID: DvTJ6oBnUbmGh8n7aYSsPJoQ7smWrmzh
X-Proofpoint-GUID: DvTJ6oBnUbmGh8n7aYSsPJoQ7smWrmzh


On 30/01/25 3:31 AM, Stefano Stabellini wrote:
> On Wed, 29 Jan 2025, Jürgen Groß wrote:
>> On 29.01.25 19:35, Harshvardhan Jha wrote:
>>> On 29/01/25 4:52 PM, Juergen Gross wrote:
>>>> On 29.01.25 10:15, Harshvardhan Jha wrote:
>>>>> On 29/01/25 2:34 PM, Greg KH wrote:
>>>>>> On Wed, Jan 29, 2025 at 02:29:48PM +0530, Harshvardhan Jha wrote:
>>>>>>> Hi Greg,
>>>>>>>
>>>>>>> On 29/01/25 2:18 PM, Greg KH wrote:
>>>>>>>> On Wed, Jan 29, 2025 at 02:13:34PM +0530, Harshvardhan Jha wrote:
>>>>>>>>> Hi there,
>>>>>>>>>
>>>>>>>>> On 29/01/25 2:05 PM, Greg KH wrote:
>>>>>>>>>> On Wed, Jan 29, 2025 at 02:03:51PM +0530, Harshvardhan Jha
>>>>>>>>>> wrote:
>>>>>>>>>>> Hi All,
>>>>>>>>>>>
>>>>>>>>>>> +stable
>>>>>>>>>>>
>>>>>>>>>>> There seems to be some formatting issues in my log output. I
>>>>>>>>>>> have
>>>>>>>>>>> attached it as a file.
>>>>>>>>>> Confused, what are you wanting us to do here in the stable
>>>>>>>>>> tree?
>>>>>>>>>>
>>>>>>>>>> thanks,
>>>>>>>>>>
>>>>>>>>>> greg k-h
>>>>>>>>> Since, this is reproducible on 5.4.y I have added stable. The
>>>>>>>>> culprit
>>>>>>>>> commit which upon getting reverted fixes this issue is also
>>>>>>>>> present in
>>>>>>>>> 5.4.y stable.
>>>>>>>> What culprit commit?  I see no information here :(
>>>>>>>>
>>>>>>>> Remember, top-posting is evil...
>>>>>>> My apologies,
>>>>>>>
>>>>>>> The stable tag v5.4.289 seems to fail to boot with the following
>>>>>>> prompt in an infinite loop:
>>>>>>> [   24.427217] megaraid_sas 0000:65:00.0: megasas_build_io_fusion
>>>>>>> 3273 sge_count (-12) is out of range. Range is:  0-256
>>>>>>>
>>>>>>> Reverting the following patch seems to fix the issue:
>>>>>>>
>>>>>>> stable-5.4      : v5.4.285             - 5df29a445f3a xen/swiotlb:
>>>>>>> add
>>>>>>> alignment check for dma buffers
>>>>>>>
>>>>>>> I tried changing swiotlb grub command line arguments but that didn't
>>>>>>> seem to help much unfortunately and the error was seen again.
>>>>>>>
>>>>>> Ok, can you submit this revert with the information about why it
>>>>>> should
>>>>>> not be included in the 5.4.y tree and cc: everyone involved and then
>>>>>> we
>>>>>> will be glad to queue it up.
>>>>>>
>>>>>> thanks,
>>>>>>
>>>>>> greg k-h
>>>>> This might be reproducible on other stable trees and mainline as well so
>>>>> we will get it fixed there and I will submit the necessary fix to stable
>>>>> when everything is sorted out on mainline.
>>>> Right. Just reverting my patch will trade one error with another one (the
>>>> one which triggered me to write the patch).
>>>>
>>>> There are two possible ways to fix the issue:
>>>>
>>>> - allow larger DMA buffers in xen/swiotlb (today 2MB are the max.
>>>> supported
>>>>    size, the megaraid_sas driver seems to effectively request 4MB)
>>> This seems relatively simpler to implement but I'm not sure whether it's
>>> the most optimal approach
>> Just making the static array larger used to hold the frame numbers for the
>> buffer seems to be a waste of memory for most configurations.
>>
>> I'm thinking of an allocated array using the max needed size (replace a
>> former buffer with a larger one if needed).
> You are referring to discontig_frames and MAX_CONTIG_ORDER in
> arch/x86/xen/mmu_pv.c, right? I am not super familiar with that code but
> it looks like a good way to go.

This rejected patch works on MAX_CONTIG_ORDER and doubles the buffer
size but that is undesirable in most situations:

https://lore.kernel.org/lkml/28947d4f-ab32-4a57-8dbb-e37fa4183a69@suse.com/t/

What needs to be done is the buffer size will only be doubled when needed.


Harshvardhan



From xen-devel-bounces@lists.xenproject.org Thu Jan 30 06:59:36 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Jan 2025 06:59:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879390.1289596 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdOWJ-0002rr-Ix; Thu, 30 Jan 2025 06:59:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879390.1289596; Thu, 30 Jan 2025 06:59:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdOWJ-0002rk-G1; Thu, 30 Jan 2025 06:59:23 +0000
Received: by outflank-mailman (input) for mailman id 879390;
 Thu, 30 Jan 2025 06:59:22 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=l+oB=UW=suse.com=jgross@srs-se1.protection.inumbo.net>)
 id 1tdOWI-0002re-A2
 for xen-devel@lists.xenproject.org; Thu, 30 Jan 2025 06:59:22 +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 ba8e917a-ded7-11ef-a0e6-8be0dac302b0;
 Thu, 30 Jan 2025 07:59:20 +0100 (CET)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-38789e5b6a7so232261f8f.1
 for <xen-devel@lists.xenproject.org>; Wed, 29 Jan 2025 22:59:20 -0800 (PST)
Received: from ?IPV6:2003:e5:8731:2800:842d:42a0:5992:3595?
 (p200300e587312800842d42a059923595.dip0.t-ipconnect.de.
 [2003:e5:8731:2800:842d:42a0:5992:3595])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438e244ecd6sm12030725e9.28.2025.01.29.22.59.18
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 29 Jan 2025 22:59:19 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ba8e917a-ded7-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738220360; x=1738825160; darn=lists.xenproject.org;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=3vUZSw8zKtk8bflc7Hn4PYmWr1l5R9zJUD1wFwtUDP4=;
        b=bwWhZH9waP690z9B4AIJGXRNQKWLkvCBX4Q+GDE5d6/M8KrvgzZkBG6NjCx7WGHlpt
         1gEVOoaEGAEbD67du2ZHYHze16CwgBAdEc0vAYvDP5YV/jKtyuYbgfBKopA/vOLtmNOM
         EdAVcBqO2EL7P2qygYgiQfUNpMqlTRPaeBeSNhkzLg7NZ2dwDv29/MkasKxzeCfJWnGV
         8+Q9pOogaAJ4zGfwOBHT1CV5PERWl8haE/KB5p8rSYhyr22HfKPzb7QJA/CZt7Q9K7cp
         JIckYKg+ZYBSSo2gDwug4pMH9uIViva4Egvi/JVJaseP56O1FY8DpiRKwi2030pSLjon
         fl/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738220360; x=1738825160;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=3vUZSw8zKtk8bflc7Hn4PYmWr1l5R9zJUD1wFwtUDP4=;
        b=vzgvknH5rKJ4uQ3nCcJ+4CihOn6W0xyfqA/8+Mipkn6OBJwIB+M7duueoIJg+MW4r+
         j6GNmw2fdcuiW3KD75M7SrYJc3a55uxH6+F9PmQjAI/1X+LYIJm/uEPsHyNsqL1r/Ydq
         aJPglRTKuuHpDOqWifVni+Paf9LiJJWvoQhtBcfR6ja3+OU6qGSQP381MvnNQMp6JoOo
         fy3bHHrXPU8eBgwWvB+CddTg4H43zC3KR2M38jNGmK1UeTfMLULwn0AKaJJEIrU4y/gd
         67rxUrCrZWcU14R/zqS3qFGfhNicgszU0uxXVFx8m7JB2QR5BDdRjb9OnPSbJVvhrK40
         DcAA==
X-Forwarded-Encrypted: i=1; AJvYcCVcCfjVu/fNSWiHoYRpqsQ5HaAYhfppy56ecAmhQ47Qu1oVIaA5hzaNqeAjqFqnNUUzZ8F7DYGS7YI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyAjbRHjTjWu+trwgQrM5+j/hq0Kbb5xznN1tWCH7xduUnNyNBm
	cgsrMMEkKhE5aaVzZA7kFbY3D+7jWBPdVZrkQaLGsSEBh9IWg9lLA9zRfZNHUgc=
X-Gm-Gg: ASbGncso95/8QwYUxI63X8aGJxOGRbXIZY3v2g1/G4aB7lhNlO2rczS7P5fzR56ieCh
	9kvSSFHROriGjgfW6kfj7gaQfoQ5i9zsRIxn0+X4C39DyrfHIEiqzB76XS1+RqSTivbDeArIDY9
	QSJKT0Lt2bmndP8iCw2GC4A9fDlxx2zjOpODDpj1LnUeR+0bj461RlQpacne2boUn97wl+gyq3/
	cYClPOCYqD+L2tlhj9AMsOWjz7nTTH74UQ1TRl5lRBu4v4V7JNEsfsUMjohNQvWEcvysamUDbtT
	aGSLHZnISVjHVoMVjmTQ7L1duz7BrC2XCpoAlRIwM3owKvTUsxLDoxek7lMoGGx1UUFOvDJLR4t
	32lq5m9fwA8vb5kiI6b6n7CwKFoEseqDEsyGRYfXl
X-Google-Smtp-Source: AGHT+IHclpz0w0BdhFnnJJQiTZ6ZuPVAz4nSrLm/cqjyr4pJ+MB3dOMhMEDwHs5k3NHTbryrf7ZwIw==
X-Received: by 2002:a5d:648b:0:b0:38a:5ce8:df51 with SMTP id ffacd0b85a97d-38c51931b2cmr4609634f8f.2.1738220359569;
        Wed, 29 Jan 2025 22:59:19 -0800 (PST)
Message-ID: <ec1a28a9-cef1-45e3-9b71-30de5bf07d7f@suse.com>
Date: Thu, 30 Jan 2025 07:59:18 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: v5.4.289 failed to boot with error megasas_build_io_fusion 3219
 sge_count (-12) is out of range
To: Harshvardhan Jha <harshvardhan.j.jha@oracle.com>,
 Stefano Stabellini <sstabellini@kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>, Konrad Wilk
 <konrad.wilk@oracle.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
 Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>,
 stable@vger.kernel.org
References: <7dc143fa-4a48-440b-b624-ac57a361ac74@oracle.com>
 <9dd91f6e-1c66-4961-994e-dbda87d69dad@oracle.com>
 <2025012919-series-chaps-856e@gregkh>
 <8eb33b38-23e1-4e43-8952-3f2b05660236@oracle.com>
 <2025012936-finalize-ducktail-c524@gregkh>
 <1f017284-1a29-49d8-b0d9-92409561990e@oracle.com>
 <2025012956-jiffy-condone-3137@gregkh>
 <1f225b8d-d958-4304-829e-8798884d9b6b@oracle.com>
 <83bd90c7-8879-4462-9548-bb5b69cac39e@suse.com>
 <b4ab0246-3846-41d1-8e84-64bd7fefc089@oracle.com>
 <de6912ad-3dba-4d66-8ca2-71a0aa09172c@suse.com>
 <alpine.DEB.2.22.394.2501291401290.11632@ubuntu-linux-20-04-desktop>
 <827aceff-28ed-4922-b841-b7dd06c082b1@oracle.com>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <827aceff-28ed-4922-b841-b7dd06c082b1@oracle.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------R9pSUZP1L7Z0s9E5YDFcGXjz"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------R9pSUZP1L7Z0s9E5YDFcGXjz
Content-Type: multipart/mixed; boundary="------------xDA2CyasAnQcwjbl1oDfweUl";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: Harshvardhan Jha <harshvardhan.j.jha@oracle.com>,
 Stefano Stabellini <sstabellini@kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>, Konrad Wilk
 <konrad.wilk@oracle.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
 Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>,
 stable@vger.kernel.org
Message-ID: <ec1a28a9-cef1-45e3-9b71-30de5bf07d7f@suse.com>
Subject: Re: v5.4.289 failed to boot with error megasas_build_io_fusion 3219
 sge_count (-12) is out of range
References: <7dc143fa-4a48-440b-b624-ac57a361ac74@oracle.com>
 <9dd91f6e-1c66-4961-994e-dbda87d69dad@oracle.com>
 <2025012919-series-chaps-856e@gregkh>
 <8eb33b38-23e1-4e43-8952-3f2b05660236@oracle.com>
 <2025012936-finalize-ducktail-c524@gregkh>
 <1f017284-1a29-49d8-b0d9-92409561990e@oracle.com>
 <2025012956-jiffy-condone-3137@gregkh>
 <1f225b8d-d958-4304-829e-8798884d9b6b@oracle.com>
 <83bd90c7-8879-4462-9548-bb5b69cac39e@suse.com>
 <b4ab0246-3846-41d1-8e84-64bd7fefc089@oracle.com>
 <de6912ad-3dba-4d66-8ca2-71a0aa09172c@suse.com>
 <alpine.DEB.2.22.394.2501291401290.11632@ubuntu-linux-20-04-desktop>
 <827aceff-28ed-4922-b841-b7dd06c082b1@oracle.com>
In-Reply-To: <827aceff-28ed-4922-b841-b7dd06c082b1@oracle.com>

--------------xDA2CyasAnQcwjbl1oDfweUl
Content-Type: multipart/mixed; boundary="------------Kd30efzWJ5zAtpSsZKNw3Zjw"

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

T24gMzAuMDEuMjUgMDY6MjcsIEhhcnNodmFyZGhhbiBKaGEgd3JvdGU6DQo+IA0KPiBPbiAz
MC8wMS8yNSAzOjMxIEFNLCBTdGVmYW5vIFN0YWJlbGxpbmkgd3JvdGU6DQo+PiBPbiBXZWQs
IDI5IEphbiAyMDI1LCBKw7xyZ2VuIEdyb8OfIHdyb3RlOg0KPj4+IE9uIDI5LjAxLjI1IDE5
OjM1LCBIYXJzaHZhcmRoYW4gSmhhIHdyb3RlOg0KPj4+PiBPbiAyOS8wMS8yNSA0OjUyIFBN
LCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0KPj4+Pj4gT24gMjkuMDEuMjUgMTA6MTUsIEhhcnNo
dmFyZGhhbiBKaGEgd3JvdGU6DQo+Pj4+Pj4gT24gMjkvMDEvMjUgMjozNCBQTSwgR3JlZyBL
SCB3cm90ZToNCj4+Pj4+Pj4gT24gV2VkLCBKYW4gMjksIDIwMjUgYXQgMDI6Mjk6NDhQTSAr
MDUzMCwgSGFyc2h2YXJkaGFuIEpoYSB3cm90ZToNCj4+Pj4+Pj4+IEhpIEdyZWcsDQo+Pj4+
Pj4+Pg0KPj4+Pj4+Pj4gT24gMjkvMDEvMjUgMjoxOCBQTSwgR3JlZyBLSCB3cm90ZToNCj4+
Pj4+Pj4+PiBPbiBXZWQsIEphbiAyOSwgMjAyNSBhdCAwMjoxMzozNFBNICswNTMwLCBIYXJz
aHZhcmRoYW4gSmhhIHdyb3RlOg0KPj4+Pj4+Pj4+PiBIaSB0aGVyZSwNCj4+Pj4+Pj4+Pj4N
Cj4+Pj4+Pj4+Pj4gT24gMjkvMDEvMjUgMjowNSBQTSwgR3JlZyBLSCB3cm90ZToNCj4+Pj4+
Pj4+Pj4+IE9uIFdlZCwgSmFuIDI5LCAyMDI1IGF0IDAyOjAzOjUxUE0gKzA1MzAsIEhhcnNo
dmFyZGhhbiBKaGENCj4+Pj4+Pj4+Pj4+IHdyb3RlOg0KPj4+Pj4+Pj4+Pj4+IEhpIEFsbCwN
Cj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+ICtzdGFibGUNCj4+Pj4+Pj4+Pj4+Pg0KPj4+
Pj4+Pj4+Pj4+IFRoZXJlIHNlZW1zIHRvIGJlIHNvbWUgZm9ybWF0dGluZyBpc3N1ZXMgaW4g
bXkgbG9nIG91dHB1dC4gSQ0KPj4+Pj4+Pj4+Pj4+IGhhdmUNCj4+Pj4+Pj4+Pj4+PiBhdHRh
Y2hlZCBpdCBhcyBhIGZpbGUuDQo+Pj4+Pj4+Pj4+PiBDb25mdXNlZCwgd2hhdCBhcmUgeW91
IHdhbnRpbmcgdXMgdG8gZG8gaGVyZSBpbiB0aGUgc3RhYmxlDQo+Pj4+Pj4+Pj4+PiB0cmVl
Pw0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IHRoYW5rcywNCj4+Pj4+Pj4+Pj4+DQo+Pj4+
Pj4+Pj4+PiBncmVnIGstaA0KPj4+Pj4+Pj4+PiBTaW5jZSwgdGhpcyBpcyByZXByb2R1Y2li
bGUgb24gNS40LnkgSSBoYXZlIGFkZGVkIHN0YWJsZS4gVGhlDQo+Pj4+Pj4+Pj4+IGN1bHBy
aXQNCj4+Pj4+Pj4+Pj4gY29tbWl0IHdoaWNoIHVwb24gZ2V0dGluZyByZXZlcnRlZCBmaXhl
cyB0aGlzIGlzc3VlIGlzIGFsc28NCj4+Pj4+Pj4+Pj4gcHJlc2VudCBpbg0KPj4+Pj4+Pj4+
PiA1LjQueSBzdGFibGUuDQo+Pj4+Pj4+Pj4gV2hhdCBjdWxwcml0IGNvbW1pdD/CoCBJIHNl
ZSBubyBpbmZvcm1hdGlvbiBoZXJlIDooDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBSZW1lbWJl
ciwgdG9wLXBvc3RpbmcgaXMgZXZpbC4uLg0KPj4+Pj4+Pj4gTXkgYXBvbG9naWVzLA0KPj4+
Pj4+Pj4NCj4+Pj4+Pj4+IFRoZSBzdGFibGUgdGFnIHY1LjQuMjg5IHNlZW1zIHRvIGZhaWwg
dG8gYm9vdCB3aXRoIHRoZSBmb2xsb3dpbmcNCj4+Pj4+Pj4+IHByb21wdCBpbiBhbiBpbmZp
bml0ZSBsb29wOg0KPj4+Pj4+Pj4gW8KgwqAgMjQuNDI3MjE3XSBtZWdhcmFpZF9zYXMgMDAw
MDo2NTowMC4wOiBtZWdhc2FzX2J1aWxkX2lvX2Z1c2lvbg0KPj4+Pj4+Pj4gMzI3MyBzZ2Vf
Y291bnQgKC0xMikgaXMgb3V0IG9mIHJhbmdlLiBSYW5nZSBpczrCoCAwLTI1Ng0KPj4+Pj4+
Pj4NCj4+Pj4+Pj4+IFJldmVydGluZyB0aGUgZm9sbG93aW5nIHBhdGNoIHNlZW1zIHRvIGZp
eCB0aGUgaXNzdWU6DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gc3RhYmxlLTUuNMKgwqDCoMKgwqAg
OiB2NS40LjI4NcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAtIDVkZjI5YTQ0NWYzYSB4ZW4v
c3dpb3RsYjoNCj4+Pj4+Pj4+IGFkZA0KPj4+Pj4+Pj4gYWxpZ25tZW50IGNoZWNrIGZvciBk
bWEgYnVmZmVycw0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IEkgdHJpZWQgY2hhbmdpbmcgc3dpb3Rs
YiBncnViIGNvbW1hbmQgbGluZSBhcmd1bWVudHMgYnV0IHRoYXQgZGlkbid0DQo+Pj4+Pj4+
PiBzZWVtIHRvIGhlbHAgbXVjaCB1bmZvcnR1bmF0ZWx5IGFuZCB0aGUgZXJyb3Igd2FzIHNl
ZW4gYWdhaW4uDQo+Pj4+Pj4+Pg0KPj4+Pj4+PiBPaywgY2FuIHlvdSBzdWJtaXQgdGhpcyBy
ZXZlcnQgd2l0aCB0aGUgaW5mb3JtYXRpb24gYWJvdXQgd2h5IGl0DQo+Pj4+Pj4+IHNob3Vs
ZA0KPj4+Pj4+PiBub3QgYmUgaW5jbHVkZWQgaW4gdGhlIDUuNC55IHRyZWUgYW5kIGNjOiBl
dmVyeW9uZSBpbnZvbHZlZCBhbmQgdGhlbg0KPj4+Pj4+PiB3ZQ0KPj4+Pj4+PiB3aWxsIGJl
IGdsYWQgdG8gcXVldWUgaXQgdXAuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IHRoYW5rcywNCj4+Pj4+
Pj4NCj4+Pj4+Pj4gZ3JlZyBrLWgNCj4+Pj4+PiBUaGlzIG1pZ2h0IGJlIHJlcHJvZHVjaWJs
ZSBvbiBvdGhlciBzdGFibGUgdHJlZXMgYW5kIG1haW5saW5lIGFzIHdlbGwgc28NCj4+Pj4+
PiB3ZSB3aWxsIGdldCBpdCBmaXhlZCB0aGVyZSBhbmQgSSB3aWxsIHN1Ym1pdCB0aGUgbmVj
ZXNzYXJ5IGZpeCB0byBzdGFibGUNCj4+Pj4+PiB3aGVuIGV2ZXJ5dGhpbmcgaXMgc29ydGVk
IG91dCBvbiBtYWlubGluZS4NCj4+Pj4+IFJpZ2h0LiBKdXN0IHJldmVydGluZyBteSBwYXRj
aCB3aWxsIHRyYWRlIG9uZSBlcnJvciB3aXRoIGFub3RoZXIgb25lICh0aGUNCj4+Pj4+IG9u
ZSB3aGljaCB0cmlnZ2VyZWQgbWUgdG8gd3JpdGUgdGhlIHBhdGNoKS4NCj4+Pj4+DQo+Pj4+
PiBUaGVyZSBhcmUgdHdvIHBvc3NpYmxlIHdheXMgdG8gZml4IHRoZSBpc3N1ZToNCj4+Pj4+
DQo+Pj4+PiAtIGFsbG93IGxhcmdlciBETUEgYnVmZmVycyBpbiB4ZW4vc3dpb3RsYiAodG9k
YXkgMk1CIGFyZSB0aGUgbWF4Lg0KPj4+Pj4gc3VwcG9ydGVkDQo+Pj4+PiAgIMKgIHNpemUs
IHRoZSBtZWdhcmFpZF9zYXMgZHJpdmVyIHNlZW1zIHRvIGVmZmVjdGl2ZWx5IHJlcXVlc3Qg
NE1CKQ0KPj4+PiBUaGlzIHNlZW1zIHJlbGF0aXZlbHkgc2ltcGxlciB0byBpbXBsZW1lbnQg
YnV0IEknbSBub3Qgc3VyZSB3aGV0aGVyIGl0J3MNCj4+Pj4gdGhlIG1vc3Qgb3B0aW1hbCBh
cHByb2FjaA0KPj4+IEp1c3QgbWFraW5nIHRoZSBzdGF0aWMgYXJyYXkgbGFyZ2VyIHVzZWQg
dG8gaG9sZCB0aGUgZnJhbWUgbnVtYmVycyBmb3IgdGhlDQo+Pj4gYnVmZmVyIHNlZW1zIHRv
IGJlIGEgd2FzdGUgb2YgbWVtb3J5IGZvciBtb3N0IGNvbmZpZ3VyYXRpb25zLg0KPj4+DQo+
Pj4gSSdtIHRoaW5raW5nIG9mIGFuIGFsbG9jYXRlZCBhcnJheSB1c2luZyB0aGUgbWF4IG5l
ZWRlZCBzaXplIChyZXBsYWNlIGENCj4+PiBmb3JtZXIgYnVmZmVyIHdpdGggYSBsYXJnZXIg
b25lIGlmIG5lZWRlZCkuDQo+PiBZb3UgYXJlIHJlZmVycmluZyB0byBkaXNjb250aWdfZnJh
bWVzIGFuZCBNQVhfQ09OVElHX09SREVSIGluDQo+PiBhcmNoL3g4Ni94ZW4vbW11X3B2LmMs
IHJpZ2h0PyBJIGFtIG5vdCBzdXBlciBmYW1pbGlhciB3aXRoIHRoYXQgY29kZSBidXQNCj4+
IGl0IGxvb2tzIGxpa2UgYSBnb29kIHdheSB0byBnby4NCj4gDQo+IFRoaXMgcmVqZWN0ZWQg
cGF0Y2ggd29ya3Mgb24gTUFYX0NPTlRJR19PUkRFUiBhbmQgZG91YmxlcyB0aGUgYnVmZmVy
DQo+IHNpemUgYnV0IHRoYXQgaXMgdW5kZXNpcmFibGUgaW4gbW9zdCBzaXR1YXRpb25zOg0K
PiANCj4gaHR0cHM6Ly9sb3JlLmtlcm5lbC5vcmcvbGttbC8yODk0N2Q0Zi1hYjMyLTRhNTct
OGRiYi1lMzdmYTQxODNhNjlAc3VzZS5jb20vdC8NCj4gDQo+IFdoYXQgbmVlZHMgdG8gYmUg
ZG9uZSBpcyB0aGUgYnVmZmVyIHNpemUgd2lsbCBvbmx5IGJlIGRvdWJsZWQgd2hlbiBuZWVk
ZWQuDQoNCkknbGwgd3JpdGUgYSBwYXRjaC4NCg0KDQpKdWVyZ2VuDQo=
--------------Kd30efzWJ5zAtpSsZKNw3Zjw
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

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

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

--------------Kd30efzWJ5zAtpSsZKNw3Zjw--

--------------xDA2CyasAnQcwjbl1oDfweUl--

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

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

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmebI0YFAwAAAAAACgkQsN6d1ii/Ey9Q
7Qf+LWTnMYryvXfc4ZSxFaTHA/vVKwR7FlXapp5udMLr+N8+5naPL+r2+ehDFNFZxFTOa4YQJKrB
1+orHe8yNAeiJa1GxnKzAZCFKWErO4NMKob/u1UVfgktlth5/NU86mXs8tsBVhdgaE5oQpfKhboU
NFBXY3eFm7if2UZixmDxoMeeWQf8RCL31jGP56LhQx4HkAHx8myIsuW97wenlp1AqOW24WHkVjbq
u7y8HT+zagviFZ99iufjBc3dlrVz6tca36YwgLXbzzlAz0H8DqSkc5N2iUBnd6UiA+9nFmmINjXc
GliP7bzEZInw4m1q7ZUtS2oQW/OWYlISQ4gOCwY5rw==
=GzUk
-----END PGP SIGNATURE-----

--------------R9pSUZP1L7Z0s9E5YDFcGXjz--


From xen-devel-bounces@lists.xenproject.org Thu Jan 30 07:22:05 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Jan 2025 07:22:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879398.1289606 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdOsD-0006fD-Av; Thu, 30 Jan 2025 07:22:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879398.1289606; Thu, 30 Jan 2025 07:22:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdOsD-0006f6-8E; Thu, 30 Jan 2025 07:22:01 +0000
Received: by outflank-mailman (input) for mailman id 879398;
 Thu, 30 Jan 2025 07:22:00 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=Fmxx=UW=arm.com=Bertrand.Marquis@srs-se1.protection.inumbo.net>)
 id 1tdOsC-0006f0-7q
 for xen-devel@lists.xenproject.org; Thu, 30 Jan 2025 07:22:00 +0000
Received: from DUZPR83CU001.outbound.protection.outlook.com
 (mail-northeuropeazlp170130004.outbound.protection.outlook.com
 [2a01:111:f403:c200::4])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e3525158-deda-11ef-99a4-01e77a169b0f;
 Thu, 30 Jan 2025 08:21:57 +0100 (CET)
Received: from AS4PR09CA0019.eurprd09.prod.outlook.com (2603:10a6:20b:5d4::10)
 by AM9PR08MB6100.eurprd08.prod.outlook.com (2603:10a6:20b:287::9)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8398.20; Thu, 30 Jan
 2025 07:21:53 +0000
Received: from AMS0EPF000001AC.eurprd05.prod.outlook.com
 (2603:10a6:20b:5d4:cafe::2f) by AS4PR09CA0019.outlook.office365.com
 (2603:10a6:20b:5d4::10) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8398.20 via Frontend Transport; Thu,
 30 Jan 2025 07:21:53 +0000
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 AMS0EPF000001AC.mail.protection.outlook.com (10.167.16.152) with
 Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8398.14
 via Frontend Transport; Thu, 30 Jan 2025 07:21:52 +0000
Received: ("Tessian outbound d1e0abd198b0:v560");
 Thu, 30 Jan 2025 07:21:52 +0000
Received: from Lc2d2530b70a8.1
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 A605E5F4-1768-4DA7-9C73-DE231B23CABF.1; 
 Thu, 30 Jan 2025 07:21:45 +0000
Received: from EUR02-AM0-obe.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id
 Lc2d2530b70a8.1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Thu, 30 Jan 2025 07:21:45 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by AS4PR08MB7604.eurprd08.prod.outlook.com (2603:10a6:20b:4ce::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8398.17; Thu, 30 Jan
 2025 07:21:43 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a%6]) with mapi id 15.20.8398.017; Thu, 30 Jan 2025
 07:21:43 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e3525158-deda-11ef-99a4-01e77a169b0f
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=XAehReU5zPkvJF11KJxjomRskAONyayaFNR78QSkOOTxDU9AfF0V9Zdc8iubL4SDUDvWz2z6Q/85ADBjza3onbBLSduXCOYbpwnrgAKPtH7tg/EgVPY+9s3hLLkQjoTsXkDSU8NEvj02xQ/8QNiYjeEH7/KPfWFd/GXxmW47oXwHBjsz9WI4EY26qC5gcJNHCB0slctl5aO9LsK0cioVnXeEVljj7IEwaeBjuMoggqomW8bYIVik1tAfe7YgsSF6VgLPnjoKUwdZAe+cCxd/CW3/xQRhgL1CAKO9nT/bGyN0dzpIge/Y9TsD9zhnK0OWz6ehXCf7cx9cFCSJnKkl2Q==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=6S0BMp9txL7FjgpkTkifbncfjx2WDu67UFdOFlgTyhg=;
 b=e2/xzxGQtoI0RLUaMMW/BpU6uFfYsAq0dwoB+j83hT7ighgclXYvcRbQOt1FMPUoi0cAs9wxa3PU8ihj5EoORPu9VvWyo+jgGogS8QLSoku2znB9TGISUi1DCOmz6Tr+2qV3hSC2dFuhRqHa2FCQemEI8ux5zKc/hzCroLkLx7MAtJR9bn37zpRLm3HxhtJfs+Kgu1Mx9IHzyaBhQTjNCvEFL2L2GZvsZzBKosqqDGajQde0uikREEtqgk2tnY4kjfjfk6OuNZtpLwF+ym7bHrA36WIeAz19EuxD4nOpgVZpP0Hyh3LQLW5/e/aQJJYEuxJVURTygoYdd3WYO2fLAg==
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=arm.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=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=6S0BMp9txL7FjgpkTkifbncfjx2WDu67UFdOFlgTyhg=;
 b=ROU1sJnNj9rGxbimOF7iAu3MlD3JISmejluUAJ03CmHHGwg9DhdH2MGWdZW7DQmFDVouyV+SGkRKZBzTsr8RR6Xm3Ghl+TAdngHCJzT6V6eqpyk7afEYzsZ10hZJUMRU+/Vb9kbdTI4g6jCxfAOpXIQX6agRwVFOTtEKhJgnlEg=
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=arm.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: 516b003a20912349
X-TessianGatewayMetadata: m1Z7JWFBwBo68xFQxy79LtN+SX4hDlUj1zwKMTKCIy1zFHp85hfoPIER80nTWcYueIQBpPio1ruhr8i5YdF6dc9Ks4ppC2gcCTcgdxHfGdzrxrTIJp0d/lx8yUJPl3sZDbL5YVcialf0nhjZ5ZUjKkwuRwxI92aTxH0WPtozQ78=
X-CR-MTA-TID: 64aa7808
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Ye/k+/2gQTLU8IzSFCJBdDAHeUamfc/P7gwfCjNFaI7/BeHIwFhPNhEdllrwtXxwFbvgOPoAfuvIigfuplNshkGNdpgflGs+TRrOtBJL1vHFhDAyQSVZE/G79XKIfJrbLyq163K8Tde9PXl8CgNzuh4YJ/Qt9cQOUzrpdE5rQUaUx2lWRl5aPiHWLNGcwZzlxv5+R2yOrC+5z626kCbH+Bzf1wsC+6p+toPwqxykol1ISZfo8bHv0La8kOsSygymJ7qaj2G7AEWGJ+BAj4Bslv0RiNG25G7+xYLitesAEd9JsGFm9m546i2Gegubfz0btaP7xD0y8YzC1j6Z9YTGkA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=6S0BMp9txL7FjgpkTkifbncfjx2WDu67UFdOFlgTyhg=;
 b=NGOVlTglHmEkwo/WFXz0nj+HkZgsOLNrtmzuua/o9U5DgqI0s4gYlG+I/yhC+vPNafcvwgr5tkNWIFXZbI6dwqmV7g6mDCd/CanOhVvp67TegQV/x/PSB0HZUxijFlsbWYJEAhVJdL+La8z3rpknzNsZp+POac4xbZdn3YuAIYIo+dDZgXMRNalYczJ9cPdhuN1EXU5hj5xEqu3KXsozH7B3uGrmPm/uzyt/8k0BJKpp1PeK65tQ15j+MzpUFMiD+1ZLAcJCGemPcqhgg1wgNPlw9Bcz3loDIVDT183aybK3GSLBLj8S1UfOQBjp62bUkf/1AzdO6bZlZzspBCdFvQ==
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=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=6S0BMp9txL7FjgpkTkifbncfjx2WDu67UFdOFlgTyhg=;
 b=ROU1sJnNj9rGxbimOF7iAu3MlD3JISmejluUAJ03CmHHGwg9DhdH2MGWdZW7DQmFDVouyV+SGkRKZBzTsr8RR6Xm3Ghl+TAdngHCJzT6V6eqpyk7afEYzsZ10hZJUMRU+/Vb9kbdTI4g6jCxfAOpXIQX6agRwVFOTtEKhJgnlEg=
From: Bertrand Marquis <Bertrand.Marquis@arm.com>
To: Julien Grall <julien.grall.oss@gmail.com>
CC: Ayan Kumar Halder <ayan.kumar.halder@amd.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Stefano
 Stabellini <sstabellini@kernel.org>, Michal Orzel <michal.orzel@amd.com>,
	Artem Mygaiev <artem_mygaiev@epam.com>
Subject: Re: [PATCH v1 2/2] docs: fusa: Add the requirements for some of the
 commands of XEN_VERSION
Thread-Topic: [PATCH v1 2/2] docs: fusa: Add the requirements for some of the
 commands of XEN_VERSION
Thread-Index: AQHbZr2QpA/avZzDqk6Vb2qnMvbcCbMt+LgAgAAEYwCAAEv4AIAAuJ4A
Date: Thu, 30 Jan 2025 07:21:43 +0000
Message-ID: <E622E957-FAB8-4A09-8994-074A30CFE42B@arm.com>
References: <20250114195010.3409094-1-ayan.kumar.halder@amd.com>
 <20250114195010.3409094-2-ayan.kumar.halder@amd.com>
 <CAJ=z9a1ynFU86ac=1Q7i=xSNh2bjnZJ3+tPjsjWvfw7294n_NA@mail.gmail.com>
 <E930B9A0-6C32-476C-8829-7FD4C991F4A9@arm.com>
 <CAJ=z9a3dqKDzPN9w_b5EnA+zOdezvBg0SQL+3aiNt9GhyU40bw@mail.gmail.com>
In-Reply-To:
 <CAJ=z9a3dqKDzPN9w_b5EnA+zOdezvBg0SQL+3aiNt9GhyU40bw@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.300.87.4.3)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB9PR08MB6588:EE_|AS4PR08MB7604:EE_|AMS0EPF000001AC:EE_|AM9PR08MB6100:EE_
X-MS-Office365-Filtering-Correlation-Id: cbca83ec-5541-49f7-7c86-08dd40fec51d
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|1800799024|366016|10070799003|376014|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?utf-8?B?KzlVbVptN0g2cmFILy9DditqWUxhRmdDZkJPUWk2bC9xdHBxNm94YzRwNE1i?=
 =?utf-8?B?bTRLbkNaanQyUm5mZE9ZczQwMjV1UjY5N0FLOGI0amNuR1JvWEc1bzFlM05w?=
 =?utf-8?B?ZnZlL1BPSFcrQUZ2Sy9OMCtoL3BJK1FUSnN5dUk3eDI5TkY5bGJYZUJmZkVh?=
 =?utf-8?B?R3dmd0NrS05kdldsbTZyRlhvckQ2TEo2U1ZOTnpmdWE5MGl3MVBWVnJENGxr?=
 =?utf-8?B?S0VacUo1N2RGV3RmWnN3OGF6K01UYTRQZXIrZGZnZVNhb20wMEZtaHNSODV1?=
 =?utf-8?B?R1RWTVZ1RktreGRTQmxRMVdrb0E1RjVtQ29Kb3NMMTVHcnZnN2M0cWk2Rlpn?=
 =?utf-8?B?UUplaHoyWTlkVmZJa24wNGJmTzV3Ukh6YW5SMmJyNXhvVDI5NXZ6WHdERHZX?=
 =?utf-8?B?VDhCUjVLOFQ5L01kakJQd3o4QlovYlJDZm1ZVWdHY0wrRk9IMFgyMUVRcHha?=
 =?utf-8?B?djI3RFVrNkZuUmdQdnRCNzVQaU9uOVRabGR1U1paK3NURDJ6SHp5SkpjRmVq?=
 =?utf-8?B?ay9tZXZCaXZ0Z201TXR2S3BQTHpkYVM1OUo1bFZ1TXM5ZGh0cm9pbXFpc0VJ?=
 =?utf-8?B?TTRHOWNNR05tNVZvdi8zaDJaTWpjMkRDM3o3bmI5blBjVFlROG1lU0l6Yml2?=
 =?utf-8?B?MjhsaXVGQTJqVXNxamZ5T08zNlhTTU9MZStnM083RmJyVVlvUFcxbGMyN2pJ?=
 =?utf-8?B?ck95SEhrRFhQYStrQUxycVorYUx2dWErOXI3Wlo2M2dPZm8yalFzckh0QXdo?=
 =?utf-8?B?dkJxdFpDanl1KzJ2aDh2cnhFeWpNd3VtVUVoSm4wMy9CSjlWdmtXd1JaYnNo?=
 =?utf-8?B?TkZRZld5WWZyT3E0clN3UEU0L0dmVk1FWnNqRDFCREs0OGRSSjd3ekRZQ2xX?=
 =?utf-8?B?SWFTcVJFYjV1VHpjcDE5VTZjQTRlT1phbkxxZVpWc3h6ZTlYOVQxVFJxMUR4?=
 =?utf-8?B?UFovNTJ4c3JtMTlMVmYrSVlJVEFUS05XMloySDBzdXhKWHNYMzBnZnNscW5J?=
 =?utf-8?B?NTFuenNJejBpeHFVdXNqUDc2UUhocHBxM1pUWGlvOXFjTE1KNlNTZlpycWJT?=
 =?utf-8?B?aEJ5TjM0ZE1vcHI1NkgxeWVNc1Z1M1Q1ZyswbW1aVll5OFdTMzB6Sk91NVFU?=
 =?utf-8?B?VTJDc0VzNnRVQzI3TUdIQnpoYm1qdW1DU1FEVGo0aDF4Ujl3R0RwdTZnK3Yz?=
 =?utf-8?B?Y0thR1lOY3FINGNVV3M2THZZSjRsbkNuWHVZTmE1OCttT2R5SmlVUkJFYlVK?=
 =?utf-8?B?YnlwcmNpYUlta29BSHliNTVpbFY5Ny9vc1diOTlHbWdSa0ZqMWc4b3FWOHhx?=
 =?utf-8?B?YjNhU3g0RXlydkVRMGZvenlCUld0YlBsWko3bVpPZXJ2azFMcWo4MndEUG51?=
 =?utf-8?B?aEI4UG83KzlLWUZVenUvK25FM0xhdlVQRVhHVnJzOVFKTmltcG1RbGZ3K0cy?=
 =?utf-8?B?OUx0aDErYWJIMmJaaWR4ZldicVFSWG5jUEpaa2hoV2l6R0wyVkp1NE54eEwy?=
 =?utf-8?B?Sk5PTTJKL2RBVEs2dFEyYkd3U3VZeG9EeFVKd2dSRndaT1lheWNKanpGM2dK?=
 =?utf-8?B?cWNDQVBhMFBzWCs1dGtSZVp3RDdCVHFhbkxlM3VKYm1qZWVpck4wL3YvWlFM?=
 =?utf-8?B?eDJwaERyUG5VKzJWMWY5azZMai9XZE1OU2hpd1dTM3hDaWd6eFV5alNnQ2VN?=
 =?utf-8?B?MHJTT0VNQmhZM2ptR2Z0TmpEd0hjQ1NXeUI5aEkzZnB2U3JtMW1WaS8zWVBr?=
 =?utf-8?B?a3lQSnFZU0dlRkdJaXpXL1paRWRlSytBUGEvdFFoN203VUJHRHJkS28rWkNZ?=
 =?utf-8?B?b2lDTHlJWk9nRUl6YzljeFhCYjhIeExBaHRpVkFFQ1JJVHAxSXYzRUI0eGxL?=
 =?utf-8?B?K1Z5Rm8yNksrWEswRnRmWlB1d0J6bUMrTVM1blRRS05TcFFUREZhN0ptbDdJ?=
 =?utf-8?Q?6VEpXzm9FHLDaKkjObjygR0Qq8mIRuJd?=
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:(13230040)(1800799024)(366016)(10070799003)(376014)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="utf-8"
Content-ID: <C4ECC5C69D914446944F917A4B930277@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR08MB7604
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-SkipListedInternetSender:
 ip=[2603:10a6:10:25a::24];domain=DB9PR08MB6588.eurprd08.prod.outlook.com
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AMS0EPF000001AC.eurprd05.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	5a01584a-b448-4c66-93f7-08dd40febf49
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|14060799003|1800799024|376014|30052699003|36860700013|82310400026|35042699022;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?K0VtUVBmdWtYN212WDNSZG8wdmdsNzh4Y3QxcGhTSEJ0MVBXQ1VCOHhvZ3NR?=
 =?utf-8?B?dHl6U3Q1ZlloTUFiQmpUeEIxWEFtQ3hpTStOc1hOVERBMmsxVlpZclZKSytZ?=
 =?utf-8?B?NUY5QXhITFUrMFRqRFFwclZPNnloTmcvVHNGOXVsK3hhT2NHSnRjSHdVOS96?=
 =?utf-8?B?Z2tLa1V0cGxRUi9QRnZzdjZQMUhDeVlmaEZ2NmlsUzIzcU5IaVZLTnRLWnNP?=
 =?utf-8?B?NWZKN3M3L2VWaDE3YkNGN0pXVHltT2x6ZWtuK2NjbWtlS1JsSnIxbzN4K0tW?=
 =?utf-8?B?a21pS0hNNzdPclNrMFpzZUZOU2FTN2dPNW9zUVZNMzB5bEFIcjN2Z3dPT2xF?=
 =?utf-8?B?WVhmbkdqamUvZm56bE05dGRRZjZxVUFhbXlyZDZrRTVRLzlZMy96ejJGS1hU?=
 =?utf-8?B?M2RKbmxsQW43ZjVuRmwwcGVLQnZSL0pZM1VBODdjTG5XK0hkYkxTL3l3Rysr?=
 =?utf-8?B?NlZJYktNRzNtc0RqR093OEVpMG1IaS9GMzRjSEdBTnVrYUxqQTY0ZnBLOGor?=
 =?utf-8?B?RkF6cWQvRlhZVC8wWk5jTXlBYnY4WGRoT2FKcTgxaXRFUk9pWTAwdU9wTWJP?=
 =?utf-8?B?a3B3bVR1Tjh6eEVxMlZ3blpDUkk3cW1JcmlkYmVCRElBbXdkb2U2Y0ZqanBs?=
 =?utf-8?B?ZC8vOVZDUWNVcmROTUtYYTgvTk41TXJIMVhSaEtYbEc4a1RTdWw5VUR0UWpl?=
 =?utf-8?B?KzJrbVoxREZCRGhyWVZLejdDajFvdXEyZFB5UWRxTUlRWHptZFp5Z3Z6bk1X?=
 =?utf-8?B?eXJLTjhLUFRnSkRjZjhnQVhiZW5OTG5Ib3hKbjZlaHh3WFRHR3VkMWhTdHVu?=
 =?utf-8?B?VC9Jdm5tckNXNk1GaDFBMWkyS2FvUzV0ck0xTS9ZWjRHK1NuOVMzZm1DTm5s?=
 =?utf-8?B?WEU5VDUwWU9kK2lVWnRhUmtRc2tVZ0tlNCtjSEIzdHdMUndRUTNnMkVtN0tz?=
 =?utf-8?B?c1VsRzl2d2YxN2J3MGhFaG4zelJreVdwNFcyZzZWa0RLc3g2WERzRU83UjBh?=
 =?utf-8?B?Tm5nVk9WRjJKV2t5ODBsTlczOTlzb2l1czVkdm1SNzJXNG1zR0V4dEdXcXBU?=
 =?utf-8?B?VzRyTW1vSGwzSkp1VDFOSnJyalZyZ3dIUzBwYll3UzdFbUh5clIyc1pFdC9Q?=
 =?utf-8?B?Tyt5eUdnN28zcUdBcmVxNWRJVDZzNnhyVlc4OStteEJ6K2RSNHA0eEhmaWh3?=
 =?utf-8?B?SGk1eWN1L29JalJzTER6cExSTGVHRitqVjBoak1IdDBLQ2llMG9RUkppSXJv?=
 =?utf-8?B?OXg4ZTBzQXlwWmpSQjFsWUppQWIzeWdlZmR0VU1pTmJqODd0RndCMEdWYkFQ?=
 =?utf-8?B?RXUxaWh1Q1lEaE5MQnlsTnRKbXNTWnB4QWk3UlF0d2huSlZSV29CbW5nMUdX?=
 =?utf-8?B?bmY3UGFkNElUYXpDcjlvQ3BUUExDMmZkRnRwSkxnaHQ2a0tTai9HRUF1Zm0z?=
 =?utf-8?B?RVhxZVAxTysxTlNGODlqZVpXTGxCeWxZMllVMXhiMkJMQ1pBNzBEY2VCSEFu?=
 =?utf-8?B?LzlmZkFMMy91elp2SVRyWDZ1TTFxMjRuR0dNdW43eWk0WEdvT0hWT01LNHhF?=
 =?utf-8?B?NWs2N29EMTdlVGtmejZvb2IrTVZhQ0kzdWd5dHdCTUR6Z1pUUG9MZlVDRVJt?=
 =?utf-8?B?djdGY2dRYU9KdCtBSU1NN0RVeHZkUXMrK0NsOFY5enR3V2MxVktPeHpGY1Jy?=
 =?utf-8?B?UC9yd3FEVU0vRTZoRkMwOFlmVUdIajhnOEtWT3M0b1dNOTZSSUpTQUprY29v?=
 =?utf-8?B?dTZLeEt2bnRaTWthT3VTTTVwR0VXWktHa0VKT1BYSllWY09MYWxvd1IzdlZ2?=
 =?utf-8?B?K0xjWkJTUjZWRW5tNkI0S2o3eU5Zcy9BV2FsM2x0eGhUMjZDTWlteW9ULzlm?=
 =?utf-8?B?cU9tZm5hUHdyeU1UWDZjNXAvUC83WmE1VFRHZFNIV091bEN4V0lZcWx2ZXN3?=
 =?utf-8?B?blZkL3Y1USt0RkZnajF1RDFYNnJhYUNmaUE1a0lFdFJocThRUjNZaXVWY29F?=
 =?utf-8?Q?FotkiatdWpXC0+haZMGTqD3oHKUyH0=3D?=
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:64aa7808-outbound-1.mta.getcheckrecipient.com;CAT:NONE;SFS:(13230040)(14060799003)(1800799024)(376014)(30052699003)(36860700013)(82310400026)(35042699022);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jan 2025 07:21:52.8611
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: cbca83ec-5541-49f7-7c86-08dd40fec51d
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:
	AMS0EPF000001AC.eurprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR08MB6100

SGkgSnVsaWVuLA0KDQo+IE9uIDI5IEphbiAyMDI1LCBhdCAyMToyMCwgSnVsaWVuIEdyYWxsIDxq
dWxpZW4uZ3JhbGwub3NzQGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiANCj4gT24gV2VkLCAyOSBK
YW4gMjAyNSBhdCAxMjo0OSwgQmVydHJhbmQgTWFycXVpcyA8QmVydHJhbmQuTWFycXVpc0Bhcm0u
Y29tPiB3cm90ZToNCj4gSGkgSnVsaWVuLA0KPiANCj4gV2VsY29tZSBiYWNrIDotKQ0KPiANCj4g
SSBhbSBub3QgZnVsbHkgYmFjayB5ZXQgYnV0IEkgaGF2ZSBhIGJpdCBvZiBzcGFyZSB0aW1lIHRv
IGdvIHRocm91Z2ggeGVuLWRldmVsIDopLg0KDQpUaGVuIGVuam95IHlvdXIgcmVtYWluaW5nIGZy
ZWUgdGltZSB0bywgbm90aGluZyB1cmdlbnQgb24gdGhlIE1MIDstKQ0KDQo+IA0KPiANCj4gDQo+
ID4gT24gMjkgSmFuIDIwMjUsIGF0IDE2OjMzLCBKdWxpZW4gR3JhbGwgPGp1bGllbi5ncmFsbC5v
c3NAZ21haWwuY29tPiB3cm90ZToNCj4gPiANCj4gPiBIaSwNCj4gPiANCj4gPiBPbiBUdWUsIDE0
IEphbiAyMDI1IGF0IDE2OjUwLCBBeWFuIEt1bWFyIEhhbGRlciA8YXlhbi5rdW1hci5oYWxkZXJA
YW1kLmNvbT4gd3JvdGU6DQo+ID4gV2UgaGF2ZSB3cml0dGVuIHRoZSByZXF1aXJlbWVudHMgZm9y
IHNvbWUgb2YgdGhlIGNvbW1hbmRzIG9mIHRoZSBYRU5fVkVSU0lPTg0KPiA+IGh5cGVyY2FsbC4N
Cj4gPiANCj4gPiBTaWduZWQtb2ZmLWJ5OiBBeWFuIEt1bWFyIEhhbGRlciA8YXlhbi5rdW1hci5o
YWxkZXJAYW1kLmNvbT4NCj4gPiAtLS0NCj4gPiAgLi4uL2Rlc2lnbi1yZXFzL2FybTY0L3ZlcnNp
b25faHlwZXJjYWxsLnJzdCAgIHwgMzMgKysrKysrKysNCj4gPiAgLi4uL3JlcXMvZGVzaWduLXJl
cXMvdmVyc2lvbl9oeXBlcmNhbGwucnN0ICAgIHwgNjUgKysrKysrKysrKysrKysrDQo+ID4gIGRv
Y3MvZnVzYS9yZXFzL2luZGV4LnJzdCAgICAgICAgICAgICAgICAgICAgICB8ICAyICsNCj4gPiAg
Li4uL3JlcXMvcHJvZHVjdC1yZXFzL3ZlcnNpb25faHlwZXJjYWxsLnJzdCAgIHwgODIgKysrKysr
KysrKysrKysrKysrKw0KPiA+ICA0IGZpbGVzIGNoYW5nZWQsIDE4MiBpbnNlcnRpb25zKCspDQo+
ID4gIGNyZWF0ZSBtb2RlIDEwMDY0NCBkb2NzL2Z1c2EvcmVxcy9kZXNpZ24tcmVxcy9hcm02NC92
ZXJzaW9uX2h5cGVyY2FsbC5yc3QNCj4gPiAgY3JlYXRlIG1vZGUgMTAwNjQ0IGRvY3MvZnVzYS9y
ZXFzL2Rlc2lnbi1yZXFzL3ZlcnNpb25faHlwZXJjYWxsLnJzdA0KPiA+IA0KPiA+IGRpZmYgLS1n
aXQgYS9kb2NzL2Z1c2EvcmVxcy9kZXNpZ24tcmVxcy9hcm02NC92ZXJzaW9uX2h5cGVyY2FsbC5y
c3QgYi9kb2NzL2Z1c2EvcmVxcy9kZXNpZ24tcmVxcy9hcm02NC92ZXJzaW9uX2h5cGVyY2FsbC5y
c3QNCj4gPiBuZXcgZmlsZSBtb2RlIDEwMDY0NA0KPiA+IGluZGV4IDAwMDAwMDAwMDAuLjFkYWQy
Yjg0YzINCj4gPiAtLS0gL2Rldi9udWxsDQo+ID4gKysrIGIvZG9jcy9mdXNhL3JlcXMvZGVzaWdu
LXJlcXMvYXJtNjQvdmVyc2lvbl9oeXBlcmNhbGwucnN0DQo+ID4gQEAgLTAsMCArMSwzMyBAQA0K
PiA+ICsuLiBTUERYLUxpY2Vuc2UtSWRlbnRpZmllcjogQ0MtQlktNC4wDQo+ID4gKw0KPiA+ICtD
YXBhYmlsaXRpZXMNCj4gPiArLS0tLS0tLS0tLS0tDQo+ID4gKw0KPiA+ICtgWGVuU3dkZ25+YXJt
NjRfY2FwYWJpbGl0aWVzfjFgDQo+ID4gKw0KPiA+ICtEZXNjcmlwdGlvbjoNCj4gPiArWGVuIHNo
YWxsIGhhdmUgYSBpbnRlcm5hbCBjb25zdGFudCBzdHJpbmcgc3RvcmluZyAieGVuLTMuMC1hYXJj
aDY0Ii4NCj4gPiANCj4gPiBDYW4geW91IGV4cGxhaW4gd2h5IHdlIG5lZWQgdG8gc3BlY2lmeSBo
b3cgWGVuIGlzIHN0b3JpbmcgdGhlIHN0cmluZz8gQXQgbGVhc3QgdG8gbWUgdGhpcyBmZWVscyBh
IGJpdCBvdmVya2lsbC4gV2hhdCBtYXR0ZXJzIGlzIHdoYXQvaG93IHRoZSBWTSBpcyBzZWVuLg0K
PiANCj4gVGhpcyBpcyBhIGRlc2lnbiByZXF1aXJlbWVudCBhbmQgYXMgc3VjaCBpdCBzaG91bGQg
YmUgdGVzdGFibGUgc28gaXQgd291bGQgYmUgZWFzaWVyIHRvIGhhdmUgc29tZXRoaW5nIHNheWlu
ZzoNCj4gWGVuIHNoYWxsIGhhdmUgYSBjb25zdGFudCBuYW1lZCBYWFggc3RvcmluZyBZWVkuDQo+
IA0KPiBSZWFkaW5nIHRoaXMsIHdvdWxkIGl0IGJlIGJldHRlciB0byB0aWUgdG8gdGhlIHZhcmlh
YmxlIGluIHRoZSBtYWtlZmlsZT8gVGhpcyB3b3VsZCBiZSBjbG9zZXIgdG8gaG93IGEgdXNlciB3
b3VsZCBzZXQgaXQgYW5kIGhvdyBvbmUgd291bGQgdGVzdCBpdC4NCg0KRGVmaW5pdGVseSB5ZXMu
IFRoZSBtb3JlIGRpcmVjdCB0aGUgdmFyaWFibGUsIHRoZSBiZXR0ZXIgaXQgaXMuDQpBcyB0aGUg
TWFrZWZpbGUgdmFyaWFibGUgaXMgd2hhdCB3ZSBtb2RpZnksIEkgYWdyZWUgdGhhdCB0aGlzIHNo
b3VsZCBwb2ludCB0byBpdC4NCg0KPiANCj4gDQo+IA0KPiANCj4gSnVzdCBzYXlpbmcgImFuIGlu
dGVybmFsIGNvbnN0YW50IiBzZWVtIGEgYml0IGxpbWl0ZWQgaGVyZSBhbmQgbm90IHNheWluZyBt
dWNoIHRoYXQgY291bGQgYmUgdGVzdGVkIGVhc2lseS4NCj4gDQo+IFdoeSBkbyB5b3UgdGhpbmsg
dGhpcyB3b3VsZCBiZSBhbiBvdmVya2lsbCA/IGRvIHlvdSBleHBlY3QgdGhlIGNvbnN0YW50IG5h
bWUgdG8gY2hhbmdlIGEgbG90ID8NCj4gDQo+IEkgZG9u4oCZdCBleHBlY3QgdGhlIGNvbnN0YW50
IG5hbWUgdG8gY2hhbmdlLiBJdCBpcyBtb3JlIHRoYXQgdGhpcyBpcyBhbiBpbnRlcm5hbCBpbXBs
ZW1lbnRhdGlvbiBxdWl0ZSBmYXIgdG8gaG93IHRoZSB1c2VyIHdvdWxkIHNldCBpdCAoc2VlIGFi
b3ZlKS4NCg0KQWdyZWUgYW5kIHRoZSBNYWtlZmlsZSB2YXJpYWJsZSBzZWVtcyB0aGUgYmVzdCB3
YXkuDQpBbGwgaW4gYWxsLCB0aGUgZGVzaWduIGp1c3QgbmVlZCB0byBzYXkgdGhhdCBpdCBtdXN0
IGJlIHN0b3JlZCBzb21ld2hlcmUgImJvdW5kZWQiIHRvIHRoZSBzb3VyY2UgY29kZSBzbyB0aGF0
IGEgdGVzdGVyIGNhbiBjaGVjayBpdC4NCg0KQ2hlZXJzDQpCZXJ0cmFuZA0KDQo+IA0KPiBDaGVl
cnMsDQo+IA0KPiANCj4gSSB3b3VsZCBzZWUgbW9yZSBhcyBhbiBvdmVya2lsbCB0aGUgZmFjdCB0
aGF0IHRoZSB2YWx1ZSBpcyBzdG9yZWQgaW4gYSByZXF1aXJlbWVudC4NCj4gDQo+IENoZWVycw0K
PiBCZXJ0cmFuZA0KDQoNCg==


From xen-devel-bounces@lists.xenproject.org Thu Jan 30 09:17:23 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Jan 2025 09:17:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879413.1289615 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdQfe-0003Li-Ek; Thu, 30 Jan 2025 09:17:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879413.1289615; Thu, 30 Jan 2025 09:17:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdQfe-0003Lb-By; Thu, 30 Jan 2025 09:17:10 +0000
Received: by outflank-mailman (input) for mailman id 879413;
 Thu, 30 Jan 2025 09:17:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=zr8Z=UW=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tdQfd-0003LV-4W
 for xen-devel@lists.xenproject.org; Thu, 30 Jan 2025 09:17:09 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id fa8d9ae5-deea-11ef-a0e6-8be0dac302b0;
 Thu, 30 Jan 2025 10:17:08 +0100 (CET)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-aaee0b309adso106111166b.3
 for <xen-devel@lists.xenproject.org>; Thu, 30 Jan 2025 01:17: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
 a640c23a62f3a-ab6e47d10f6sm89464066b.53.2025.01.30.01.17.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 30 Jan 2025 01:17:07 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: fa8d9ae5-deea-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738228627; x=1738833427; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=N+g4gCTnbnhhfgvYhGTL+/Yp1nEM39RrsmrhZl/ykKs=;
        b=GA5+mADB0dp/80N9qHvx2amFwq257edlKM5legVfOAsGrrN5xaZVaWdXV2F0HJPDrV
         cJZZjx961sJ4KT1oz/tHZ7RWkhQoJ7OFA9FkS2vI7H4jvRcKpjNh5O1BMgXh02VX0dYI
         X/pFpyLBzazxQG4JQs0EIuNUEh20vYtoOTdz3wFwLF3BxK9uosE9cz0Wf3BgbznduHf2
         LWipqRuQRfSh9ogXeNa2D/bHWounpEk2cBZEta9Q4QKb0AiblGmx8ScQeAhKY4DmE8Ll
         IvKXWIFfB2m3iU8kZ7ccVoijxYmI73YdMOFd4WbnP13a4x7kzw59qf3GX4FKZ7ErOarQ
         3wMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738228627; x=1738833427;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=N+g4gCTnbnhhfgvYhGTL+/Yp1nEM39RrsmrhZl/ykKs=;
        b=jPm93NzwM4HAHx4E8fyVtUj0MQ7+TZRPZcwuoAGDDAOY2no+z4CJQaynY5jc1abovV
         yA6fQ9Hh1ZbS6OGyaySJJRO+JNfRn9zDTqlBLnCqftIt0Z0pVn4I5MOILGju8xs+2ljY
         INQBMeIT1fkIBo2Wx1hO+hxsoVtC/ZSvhgH7MgXVCP09HxqOqexdI4c/e2yDC/y9tRLb
         RNwQ7gEegrI81KU75/UhyvQVh1atnO9/K+u+SUGf5IV33mE5H5ZxF9Nn3z/7ScJgUtWP
         KhS6chCh6j4nBC/ZnVRDZ7FbXmepRRPSYgsTzqPhRs+SbVX1Bjc5G7XWAvNepMODcEyh
         PmIA==
X-Gm-Message-State: AOJu0YxuHlfTIP+RuvTwNmrocc6pWXOHE6dAJzaGs7VJQsQHSapZGNc5
	vR/KrMlja5AKp9I4KnRo++/f49vbEeAjx7uAW3IPuNP9Ze/PGqQ6kSltPf+8EQ==
X-Gm-Gg: ASbGncvzz8zUfJxNyc1k1EHbhQ77f63kGC1s750RzUmUM5UPm0Hg530GmwC+iJl8Zet
	jV1NV51kaUEwKGMBxotjIVoSCkl2SaZ2PGpLj8/i6varcCLaMoh4PgOAQmjTVYQMWVV68iZqxjZ
	P5aZCILAvueM2grmWKxrRdPlzcf4OWqKzTUvr2Ff6PwOq+aVuXCHROKBAnCWMss1yA3vLv+em5p
	bj0ka9uloRhUeSlu/z6HnjYdcu0UzR3b4ub8q7OMVPB8JicxXxkBF8p9T4guaubVxcZyBcAbr/1
	tSLnhstafKSlGTT5lBJP2KCEd4KcUxtZruS4+7VxvM5PSAiskGQFt+Evw5Cct3gaG/IY/H4DHMs
	i
X-Google-Smtp-Source: AGHT+IFapaUvMXR8MmQeJG006G48MOPuma+mappyfMRkLgTghNLs2cmyAW0wXt3rMDasi3jsgrcaRA==
X-Received: by 2002:a17:907:7f0b:b0:aae:eb0b:f39a with SMTP id a640c23a62f3a-ab6cfdbe551mr629529366b.42.1738228627394;
        Thu, 30 Jan 2025 01:17:07 -0800 (PST)
Message-ID: <cb108460-b3df-4d59-8cad-696981660bc2@suse.com>
Date: Thu, 30 Jan 2025 10:17:06 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/3] tools/hvmloader: Decouple APIC IDs from vCPU IDs
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Alejandro Vallejo <alejandro.vallejo@cloud.com>
Cc: xen-devel@lists.xenproject.org, Andrew Cooper
 <andrew.cooper3@citrix.com>, Anthony PERARD <anthony.perard@vates.tech>
References: <20250128163342.1491-1-alejandro.vallejo@cloud.com>
 <Z5kXq2RehzyFEYqA@macbook.local> <D7DXEC0N45CT.2JHUHP1XAVB5F@cloud.com>
 <Z5pWiYWGv66uXpAm@macbook.local>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <Z5pWiYWGv66uXpAm@macbook.local>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 29.01.2025 17:25, Roger Pau Monné wrote:
> On Tue, Jan 28, 2025 at 06:42:38PM +0000, Alejandro Vallejo wrote:
>> On Tue Jan 28, 2025 at 5:45 PM GMT, Roger Pau Monné wrote:
>>> On Tue, Jan 28, 2025 at 04:33:39PM +0000, Alejandro Vallejo wrote:
>>>> The hypervisor, hvmloader and the toolstack currently engage in a shared
>>>> assumption that for every vCPU apicid == 2 * vcpuid. This series removes such
>>>> assumption from hvmloader, by making it read the APIC ID of each vCPU and
>>>> storing it for later use.
>>>>
>>>> The last patch prevents writing an MP Tables should we have vCPUs that can not
>>>> be represented there. That's at the moment dead code because all vCPUs are
>>>> currently representable in 8 bits. This will inavitably stop being true in the
>>>> future after we increase the maximum number of guest vCPUs.
>>>
>>> While I'm fine with the MP Table change, should it also come together
>>> with a patch that introduces the code to create x2APIC entries in
>>> libacpi construct_madt() helper? (and bumping the MADT revision, as
>>> I'm quite sure version 2 didn't have x2APIC entries in the
>>> specification).
>>
>> That's a lot more involved though. Matt started something in that direction
>> last year, but testing it was (and still is) effectively impossible until
>> HVM_MAX_VCPUS increases.
>>
>>   https://lore.kernel.org/xen-devel/cd1a3ce14790af8c1bb4372ef0be5a6cbbb50b1c.1710338145.git.matthew.barnes@cloud.com/
>>
>> The rest of the topo series can be used to test that (with a hack to
>> artificially bump the width of thread_id space), I'd rather not test a patch
>> with a long and still uncommitted series.
>>
>>>
>>> Otherwise the MP Table change seems like a red herring, because the
>>> MADT created by libacpi will also be incorrect and APIC IDs will wrap in
>>> local APIC entries, just like it would on MP Tables.
>>>
>>> Thanks, Roger.
>>
>> My take is that this is strictly better than what we have today by virtue of
>> going down from 2 latent bugs to just 1. That said, I don't strictly need it
>> for the topo series to advance, so it is (in a sense) optional.
> 
> I'm fine with the patch, but it probably wants to mention in the
> commit message that MADT tables will still wrap when using APIC IDs >
> 255, as otherwise it seems MADT is not taken into consideration.

I think we simply should not add MADT entries with wrapped (truncated)
APIC IDs. Which can be done when they truly are at risk of wrapping, or
right here.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 30 09:30:43 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Jan 2025 09:30:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879421.1289626 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdQsh-0005wV-KJ; Thu, 30 Jan 2025 09:30:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879421.1289626; Thu, 30 Jan 2025 09: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 <xen-devel-bounces@lists.xenproject.org>)
	id 1tdQsh-0005wO-HF; Thu, 30 Jan 2025 09:30:39 +0000
Received: by outflank-mailman (input) for mailman id 879421;
 Thu, 30 Jan 2025 09:30:38 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=zr8Z=UW=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tdQsg-0005wH-G4
 for xen-devel@lists.xenproject.org; Thu, 30 Jan 2025 09:30:38 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id dbd21b19-deec-11ef-99a4-01e77a169b0f;
 Thu, 30 Jan 2025 10:30:35 +0100 (CET)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-aaedd529ba1so86575066b.1
 for <xen-devel@lists.xenproject.org>; Thu, 30 Jan 2025 01:30:35 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5dc7204517csm775702a12.0.2025.01.30.01.30.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 30 Jan 2025 01:30:34 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: dbd21b19-deec-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738229435; x=1738834235; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=DWNKTu1xMedq7YoRUSSpTvvZsiNpq+yhrTRNnSA0368=;
        b=IwZbhSEJ2T0+V4jk2Q+o+prupbgRxdkNDHpJu3KdaHy7DruyDQQXXb+3OfcBs04obe
         ZgBeeMZpzA6IWynDDt6A5ZVbtb5fVq4PQ7SGX1NZEoAjMOcoI7Vei5TAtgX2e1+Nzg++
         dNu0Vv/MJlunrPPyYb/52JcdXq9IasX+eydKpvhMsGGubnpbb/USBKadg40+F5uMNR+9
         FkZNw+TlFQ394zrHzC4LJyjIj8nxLP0Mq+Evcyj79ecaX7/Q96u5W0MtEGU5sgDMohyJ
         9N4RRQBUl0Wi14Xk6gwKq+/FkmuwUNDMA+1HpwtvcbcC1h6/DECkdKK7ay9gE02Dg6hb
         yogg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738229435; x=1738834235;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=DWNKTu1xMedq7YoRUSSpTvvZsiNpq+yhrTRNnSA0368=;
        b=IQCQDnsgqFyTTiVPBseAqHlV/HVa+HFdGU21Nw/fYYHwW2gW3Bt9dRj1jEQQeR8iep
         yWul5fCrQfU74wjo66lZBv3HpYFPIq5pamtHgQv/YwjfjXPsQHZBHK7OA1sUdzM7smrt
         O3iTHYPFnUAxs2AtI2cvqHo1vrU7XjmTIKo3ffefqOVFNhyok4zF7ONDmnYi9PsrwLmM
         ip1rulnu6qym9FuT5dfEeZjluvje+/bsrzT4iBf3E0QC+Vlmsr4VruG/2VwkRmEF007H
         FKuK2ksDKUruGoYoHpJ4PN7zxQcg+NmI5Yn0z6p9a4NSoDl3bENnUeM2DlDajkm8ePjJ
         K/HQ==
X-Forwarded-Encrypted: i=1; AJvYcCX1iZllHanoeocXIl8tH5gUHd3LJBepFtqBFdmo5oxY7jsrKWQnbil3wiWbgXfWfL8g51CNxRN3fwg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzbEkkfO6InyHQqN3Kro+sTSFls6gcI1TyPK1GjZ3U98ziTLT3a
	xr7GjWihdd+zHxF0VBguhYbcuRdr9csvUDrX85l5xe5ojHsC48UZd2LUIBynfg==
X-Gm-Gg: ASbGncu26x8nLr+SBDn4SC4cE/wxBlXFKL9FCirEZ5cq7Qa0LaWNt8A2x2OKOKGwo1n
	EXOctemlhGSfypiT6oRLE9TMCZn/26ulo7rZ2kaPs0G4YQfeGOXOaK2147UMEjPgN6WGA96ZXT9
	EizCdQKNldtb5oAlgJv2wqwBjyQA2y1HWhvItkdT0e4vF3RnOgzsE/aUTlosF9dzgrZSj0ihab4
	CJDzrwJ6GzJ0pXK0owLc/PrHyOAO5CGTCWg+PEI1w1CNkDxutDxtT6rrblDm89n4uZK4HH8tzWN
	VYoX/J4rgarzyDpH+40w3L/glQy4CWUGOETe/YjKfy5jyZizMQART1/KPv22+FlwTEEZvvGx/AJ
	G
X-Google-Smtp-Source: AGHT+IF0gyawJlcEkylXCscP5ByYoAc8DNLoaGkczxxW7yrMEL0xgpxHngznG1VR9QUPt+Fv9sC/Rw==
X-Received: by 2002:a05:6402:34c8:b0:5d9:84ee:ff31 with SMTP id 4fb4d7f45d1cf-5dc5efa8c21mr15653014a12.3.1738229434702;
        Thu, 30 Jan 2025 01:30:34 -0800 (PST)
Message-ID: <cfe0af0e-132b-4390-a3b0-dde0e6326e19@suse.com>
Date: Thu, 30 Jan 2025 10:30:33 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Config space access to Mediatek MT7922 doesn't work after device
 reset in Xen PV dom0 (regression, Linux 6.12)
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>, =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?=
 <jgross@suse.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 xen-devel <xen-devel@lists.xenproject.org>, linux-kernel@vger.kernel.org,
 regressions@lists.linux.dev, Felix Fietkau <nbd@nbd.name>,
 Lorenzo Bianconi <lorenzo@kernel.org>, Ryder Lee <ryder.lee@mediatek.com>,
 Bjorn Helgaas <helgaas@kernel.org>
References: <Z5mOKQUrgeF_r6te@mail-itl> <20250129184825.GA484760@bhelgaas>
 <Z5sGW4b0pMtm38Y-@mail-itl>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <Z5sGW4b0pMtm38Y-@mail-itl>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 30.01.2025 05:55, Marek Marczykowski-Górecki wrote:
> I've added logging of all config read/write to this device. Full log at
> [1].
> 
> A little explanation:
> - it's done in pci_conf_read/pci_conf_write in https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/pci.c;h=97b792e578f1093194466081ad3651ade21cae7d;hb=HEAD
> - cf8 means cf8 port value (BDF + register)
> - bytes is read/write size (1/2/4)
> - offset is the offset in the register (on top of cf8), but not in data
> - data is either retrieved value, or written value, depending on
>   function
> - it's logging only accesses to 01:00.0
> 
> interesting part:
> 
> lspci before reset:
> (XEN) d0v3 conf read cf8 0x80010000 bytes 4 offset 0 data 0x61614c3
> (XEN) d0v3 conf read cf8 0x80010004 bytes 4 offset 0 data 0x100000
> (XEN) d0v3 conf read cf8 0x80010008 bytes 4 offset 0 data 0x2800000
> (XEN) d0v3 conf read cf8 0x8001000c bytes 4 offset 0 data 0x10
> (XEN) d0v3 conf read cf8 0x80010010 bytes 4 offset 0 data 0x1090000c
> (XEN) d0v3 conf read cf8 0x80010014 bytes 4 offset 0 data 0x80
> (XEN) d0v3 conf read cf8 0x80010018 bytes 4 offset 0 data 0x90b00004
> (XEN) d0v3 conf read cf8 0x8001001c bytes 4 offset 0 data 0
> (XEN) d0v3 conf read cf8 0x80010020 bytes 4 offset 0 data 0
> (XEN) d0v3 conf read cf8 0x80010024 bytes 4 offset 0 data 0
> (XEN) d0v3 conf read cf8 0x80010028 bytes 4 offset 0 data 0
> (XEN) d0v3 conf read cf8 0x8001002c bytes 4 offset 0 data 0xe61614c3
> (XEN) d0v3 conf read cf8 0x80010030 bytes 4 offset 0 data 0
> (XEN) d0v3 conf read cf8 0x80010034 bytes 4 offset 0 data 0x80
> (XEN) d0v3 conf read cf8 0x80010038 bytes 4 offset 0 data 0
> (XEN) d0v3 conf read cf8 0x8001003c bytes 4 offset 0 data 0x1ff
> (XEN) d0v3 conf read cf8 0x80010080 bytes 4 offset 0 data 0x2e010
> (XEN) d0v3 conf read cf8 0x800100e0 bytes 4 offset 0 data 0x18af805
> (XEN) d0v3 conf read cf8 0x800100f8 bytes 4 offset 0 data 0xc8030001
> 
> reset:
> (XEN) d0v1 conf read cf8 0x800100fc bytes 2 offset 0 data 0x8
> (XEN) d0v1 conf read cf8 0x800100fc bytes 2 offset 0 data 0x8
> (XEN) d0v1 conf read cf8 0x8001008c bytes 4 offset 0 data 0x145dc12
> (XEN) d0v1 conf read cf8 0x80010000 bytes 4 offset 0 data 0x61614c3
> (XEN) d0v1 conf read cf8 0x80010004 bytes 4 offset 0 data 0x100000
> (XEN) d0v1 conf read cf8 0x80010008 bytes 4 offset 0 data 0x2800000
> (XEN) d0v1 conf read cf8 0x8001000c bytes 4 offset 0 data 0x10
> (XEN) d0v1 conf read cf8 0x80010010 bytes 4 offset 0 data 0x1090000c
> (XEN) d0v1 conf read cf8 0x80010014 bytes 4 offset 0 data 0x80
> (XEN) d0v1 conf read cf8 0x80010018 bytes 4 offset 0 data 0x90b00004
> (XEN) d0v1 conf read cf8 0x8001001c bytes 4 offset 0 data 0
> (XEN) d0v1 conf read cf8 0x80010020 bytes 4 offset 0 data 0
> (XEN) d0v1 conf read cf8 0x80010024 bytes 4 offset 0 data 0
> (XEN) d0v1 conf read cf8 0x80010028 bytes 4 offset 0 data 0
> (XEN) d0v1 conf read cf8 0x8001002c bytes 4 offset 0 data 0xe61614c3
> (XEN) d0v1 conf read cf8 0x80010030 bytes 4 offset 0 data 0
> (XEN) d0v1 conf read cf8 0x80010034 bytes 4 offset 0 data 0x80
> (XEN) d0v1 conf read cf8 0x80010038 bytes 4 offset 0 data 0
> (XEN) d0v1 conf read cf8 0x8001003c bytes 4 offset 0 data 0x1ff
> (XEN) d0v1 conf read cf8 0x80010088 bytes 2 offset 0 data 0x2910
> (XEN) d0v1 conf read cf8 0x80010090 bytes 2 offset 0 data 0x1c2
> (XEN) d0v1 conf read cf8 0x800100a8 bytes 2 offset 0 data 0x400
> (XEN) d0v1 conf read cf8 0x800100b0 bytes 2 offset 0 data 0x2
> (XEN) d0v1 conf read cf8 0x80010004 bytes 2 offset 2 data 0x10
> (XEN) d0v1 conf read cf8 0x80010034 bytes 1 offset 0 data 0x80
> (XEN) d0v1 conf read cf8 0x80010080 bytes 2 offset 0 data 0xe010
> (XEN) d0v1 conf read cf8 0x800100e0 bytes 2 offset 0 data 0xf805
> (XEN) d0v1 conf read cf8 0x800100f8 bytes 2 offset 0 data 0x1
> (XEN) d0v1 conf write cf8 0x80010004 bytes 2 offset 0 data 0x400
> (XEN) d0v1 conf read cf8 0x80010088 bytes 2 offset 2 data 0x9
> (XEN) d0v1 conf read cf8 0x80010088 bytes 2 offset 0 data 0x2910
> (XEN) d0v1 conf write cf8 0x80010088 bytes 2 offset 0 data 0xa910

This is the express capability's Link Control 2 Register afaict. As per
the copy of the 6.0 spec that I have the top 4 bits have only two
defined encodings - 0b0000 and 0b0001. 0b1000, as is being set here, is
not defined.

Yet then the earlier questions remain: Why has this suddenly become a
problem? And why would this depend on how the present session was
started, and what was running in the previous session? Is this write
perhaps conditional upon something that has changed?

Jan

> (XEN) d0v2 conf read cf8 0x80010000 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf read cf8 0x80010090 bytes 2 offset 0 data 0xffff
> (XEN) d0v2 conf write cf8 0x80010090 bytes 2 offset 0 data 0xfffc
> (XEN) d0v2 conf write cf8 0x80010090 bytes 2 offset 0 data 0xffff
> (XEN) d0v2 conf write cf8 0x80010088 bytes 2 offset 0 data 0x2910
> (XEN) d0v2 conf write cf8 0x80010090 bytes 2 offset 0 data 0x1c2
> (XEN) d0v2 conf write cf8 0x800100a8 bytes 2 offset 0 data 0x400
> (XEN) d0v2 conf write cf8 0x800100b0 bytes 2 offset 0 data 0x2
> (XEN) d0v2 conf read cf8 0x8001003c bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x8001003c bytes 4 offset 0 data 0x1ff
> (XEN) d0v2 conf read cf8 0x80010038 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010038 bytes 4 offset 0 data 0
> (XEN) d0v2 conf read cf8 0x80010034 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010034 bytes 4 offset 0 data 0x80
> (XEN) d0v2 conf read cf8 0x80010030 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010030 bytes 4 offset 0 data 0
> (XEN) d0v2 conf read cf8 0x8001002c bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x8001002c bytes 4 offset 0 data 0xe61614c3
> (XEN) d0v2 conf read cf8 0x80010028 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010028 bytes 4 offset 0 data 0
> (XEN) d0v2 conf read cf8 0x80010024 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010024 bytes 4 offset 0 data 0
> (XEN) d0v2 conf read cf8 0x80010024 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010024 bytes 4 offset 0 data 0
> (XEN) d0v2 conf read cf8 0x80010024 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010024 bytes 4 offset 0 data 0
> (XEN) d0v2 conf read cf8 0x80010024 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010024 bytes 4 offset 0 data 0
> (XEN) d0v2 conf read cf8 0x80010024 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010024 bytes 4 offset 0 data 0
> (XEN) d0v2 conf read cf8 0x80010024 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010024 bytes 4 offset 0 data 0
> (XEN) d0v2 conf read cf8 0x80010024 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010024 bytes 4 offset 0 data 0
> (XEN) d0v2 conf read cf8 0x80010024 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010024 bytes 4 offset 0 data 0
> (XEN) d0v2 conf read cf8 0x80010024 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010024 bytes 4 offset 0 data 0
> (XEN) d0v2 conf read cf8 0x80010024 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010024 bytes 4 offset 0 data 0
> (XEN) d0v2 conf read cf8 0x80010024 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010024 bytes 4 offset 0 data 0
> (XEN) d0v2 conf read cf8 0x80010020 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010020 bytes 4 offset 0 data 0
> (XEN) d0v2 conf read cf8 0x80010020 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010020 bytes 4 offset 0 data 0
> (XEN) d0v2 conf read cf8 0x80010020 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010020 bytes 4 offset 0 data 0
> (XEN) d0v2 conf read cf8 0x80010020 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010020 bytes 4 offset 0 data 0
> (XEN) d0v2 conf read cf8 0x80010020 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010020 bytes 4 offset 0 data 0
> (XEN) d0v2 conf read cf8 0x80010020 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010020 bytes 4 offset 0 data 0
> (XEN) d0v2 conf read cf8 0x80010020 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010020 bytes 4 offset 0 data 0
> (XEN) d0v2 conf read cf8 0x80010020 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010020 bytes 4 offset 0 data 0
> (XEN) d0v2 conf read cf8 0x80010020 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010020 bytes 4 offset 0 data 0
> (XEN) d0v2 conf read cf8 0x80010020 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010020 bytes 4 offset 0 data 0
> (XEN) d0v2 conf read cf8 0x80010020 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010020 bytes 4 offset 0 data 0
> (XEN) d0v2 conf read cf8 0x8001001c bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x8001001c bytes 4 offset 0 data 0
> (XEN) d0v2 conf read cf8 0x8001001c bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x8001001c bytes 4 offset 0 data 0
> (XEN) d0v2 conf read cf8 0x8001001c bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x8001001c bytes 4 offset 0 data 0
> (XEN) d0v2 conf read cf8 0x8001001c bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x8001001c bytes 4 offset 0 data 0
> (XEN) d0v2 conf read cf8 0x8001001c bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x8001001c bytes 4 offset 0 data 0
> (XEN) d0v2 conf read cf8 0x8001001c bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x8001001c bytes 4 offset 0 data 0
> (XEN) d0v2 conf read cf8 0x8001001c bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x8001001c bytes 4 offset 0 data 0
> (XEN) d0v2 conf read cf8 0x8001001c bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x8001001c bytes 4 offset 0 data 0
> (XEN) d0v2 conf read cf8 0x8001001c bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x8001001c bytes 4 offset 0 data 0
> (XEN) d0v2 conf read cf8 0x8001001c bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x8001001c bytes 4 offset 0 data 0
> (XEN) d0v2 conf read cf8 0x8001001c bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x8001001c bytes 4 offset 0 data 0
> (XEN) d0v2 conf read cf8 0x80010018 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010018 bytes 4 offset 0 data 0x90b00004
> (XEN) d0v2 conf read cf8 0x80010018 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010018 bytes 4 offset 0 data 0x90b00004
> (XEN) d0v2 conf read cf8 0x80010018 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010018 bytes 4 offset 0 data 0x90b00004
> (XEN) d0v2 conf read cf8 0x80010018 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010018 bytes 4 offset 0 data 0x90b00004
> (XEN) d0v2 conf read cf8 0x80010018 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010018 bytes 4 offset 0 data 0x90b00004
> (XEN) d0v2 conf read cf8 0x80010018 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010018 bytes 4 offset 0 data 0x90b00004
> (XEN) d0v2 conf read cf8 0x80010018 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010018 bytes 4 offset 0 data 0x90b00004
> (XEN) d0v2 conf read cf8 0x80010018 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010018 bytes 4 offset 0 data 0x90b00004
> (XEN) d0v2 conf read cf8 0x80010018 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010018 bytes 4 offset 0 data 0x90b00004
> (XEN) d0v2 conf read cf8 0x80010018 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010018 bytes 4 offset 0 data 0x90b00004
> (XEN) d0v2 conf read cf8 0x80010018 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010018 bytes 4 offset 0 data 0x90b00004
> (XEN) d0v2 conf read cf8 0x80010014 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010014 bytes 4 offset 0 data 0x80
> (XEN) d0v2 conf read cf8 0x80010014 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010014 bytes 4 offset 0 data 0x80
> (XEN) d0v2 conf read cf8 0x80010014 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010014 bytes 4 offset 0 data 0x80
> (XEN) d0v2 conf read cf8 0x80010014 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010014 bytes 4 offset 0 data 0x80
> (XEN) d0v2 conf read cf8 0x80010014 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010014 bytes 4 offset 0 data 0x80
> (XEN) d0v2 conf read cf8 0x80010014 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010014 bytes 4 offset 0 data 0x80
> (XEN) d0v2 conf read cf8 0x80010014 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010014 bytes 4 offset 0 data 0x80
> (XEN) d0v2 conf read cf8 0x80010014 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010014 bytes 4 offset 0 data 0x80
> (XEN) d0v2 conf read cf8 0x80010014 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010014 bytes 4 offset 0 data 0x80
> (XEN) d0v2 conf read cf8 0x80010014 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010014 bytes 4 offset 0 data 0x80
> (XEN) d0v2 conf read cf8 0x80010014 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010014 bytes 4 offset 0 data 0x80
> (XEN) d0v2 conf read cf8 0x80010010 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010010 bytes 4 offset 0 data 0x1090000c
> (XEN) d0v2 conf read cf8 0x80010010 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010010 bytes 4 offset 0 data 0x1090000c
> (XEN) d0v2 conf read cf8 0x80010010 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010010 bytes 4 offset 0 data 0x1090000c
> (XEN) d0v2 conf read cf8 0x80010010 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010010 bytes 4 offset 0 data 0x1090000c
> (XEN) d0v2 conf read cf8 0x80010010 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010010 bytes 4 offset 0 data 0x1090000c
> (XEN) d0v2 conf read cf8 0x80010010 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010010 bytes 4 offset 0 data 0x1090000c
> (XEN) d0v2 conf read cf8 0x80010010 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010010 bytes 4 offset 0 data 0x1090000c
> (XEN) d0v2 conf read cf8 0x80010010 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010010 bytes 4 offset 0 data 0x1090000c
> (XEN) d0v2 conf read cf8 0x80010010 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010010 bytes 4 offset 0 data 0x1090000c
> (XEN) d0v2 conf read cf8 0x80010010 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010010 bytes 4 offset 0 data 0x1090000c
> (XEN) d0v2 conf read cf8 0x80010010 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010010 bytes 4 offset 0 data 0x1090000c
> (XEN) d0v2 conf read cf8 0x8001000c bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x8001000c bytes 4 offset 0 data 0x10
> (XEN) d0v2 conf read cf8 0x80010008 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010008 bytes 4 offset 0 data 0x2800000
> (XEN) d0v2 conf read cf8 0x80010004 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010004 bytes 4 offset 0 data 0x100000
> (XEN) d0v2 conf read cf8 0x80010000 bytes 4 offset 0 data 0xffffffff
> (XEN) d0v2 conf write cf8 0x80010000 bytes 4 offset 0 data 0x61614c3
> (XEN) d0v2 conf read cf8 0x80010004 bytes 2 offset 2 data 0xffff
> (XEN) d0v2 conf read cf8 0x80010034 bytes 1 offset 0 data 0xff
> (XEN) d0v2 conf read cf8 0x800100fc bytes 2 offset 0 data 0xffff
> 
> 
> [1] https://gist.github.com/marmarek/b4391c71801145e52590e877c559c5e0
> 



From xen-devel-bounces@lists.xenproject.org Thu Jan 30 10:37:44 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Jan 2025 10:37:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879443.1289650 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdRvW-0005P7-Oe; Thu, 30 Jan 2025 10:37:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879443.1289650; Thu, 30 Jan 2025 10:37:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdRvW-0005P0-LS; Thu, 30 Jan 2025 10:37:38 +0000
Received: by outflank-mailman (input) for mailman id 879443;
 Thu, 30 Jan 2025 10:37:37 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=j2sA=UW=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tdRvV-0005An-Be
 for xen-devel@lists.xenproject.org; Thu, 30 Jan 2025 10:37:37 +0000
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com
 [2a00:1450:4864:20::32b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 35f1d38a-def6-11ef-99a4-01e77a169b0f;
 Thu, 30 Jan 2025 11:37:32 +0100 (CET)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-436a39e4891so3968455e9.1
 for <xen-devel@lists.xenproject.org>; Thu, 30 Jan 2025 02:37:35 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38c5c1cf831sm1596604f8f.90.2025.01.30.02.37.34
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 30 Jan 2025 02:37:34 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 35f1d38a-def6-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1738233455; x=1738838255; 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=Pg5MaFKnNzop8+TLP/dVC/2mW49fQZIVVDSrPsECg1A=;
        b=jVZ+eM9ci4wkv++lO41pp/yenRzKhVnGQ+IZlBEVACuTzr4nxTqtI7cX9JG7eaLGDy
         CjIYmBEwGUEVVYEFvPZ16XvYJQ/U3BelR3NHszDPnvKqfNs+IKNJkrJAgPg3qTwEDI2R
         DEwAz7b9SMEW77gH0FKmiGc6+3KEmw/OzXbCy+i/+B6RwUeUQzuQLxDDDdsNfpF6ZH3l
         02NRhByO5dTY0i7lcK4Jcfy/2ygYi/E9AjR0glx2+GbHzeRZoojTf/JNXWu8j0V5W44N
         FGqWYgSrxVVjHnRoObHJyPdX2sa14o2rGkclQocYgaRVmoiH+PjOByQUUtjchVe056lX
         YEJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738233455; x=1738838255;
        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=Pg5MaFKnNzop8+TLP/dVC/2mW49fQZIVVDSrPsECg1A=;
        b=OUPgIqyHuTeza0eCc2l1KgN9JJeUrLv2Inu2n4pjMIGhudxwNBJg/1g6KVwWylV/9K
         qF1aDnNM7PFSilL3nJymCcmsvIwuCeN+as/KjVbzrlk/NPHsujDTD2D+eHXQH0WXs0bf
         HSedLhJGf8iT3X5Utwty5ZsZOpLYmzcMj4lXo+uKBkyiRybjrPZAKILByJkOWVDQsXGB
         XDbK7xVz8T9uad/s8digmyKR+JTqW5Xsmmo8/b3XWPb9ACKKMe64fNmxHHjD9EvfV+6c
         9wB9mBBIdvS6tONy051xlxnuX6CcAfZV/h9IavrYsvHBuzM2nraX3u4eHM9xjrmebowq
         om+A==
X-Forwarded-Encrypted: i=1; AJvYcCXuh2WdiY+e6sjj6a882oheUW4e6JkIQGDpHplGTgqpTJ5f5V7Pghxfq8wRCf7BJhCzrfX73AAnjX4=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw1oIsKEfsNc5J8ioQWZK12x+Yg3fl561mqWVDQFo/bLhtEF7S3
	Vii4eh/E4LHctMJACege9ZiBV+8AbfYZ1piGXfXzYABDbpQxYd7gYC0bEt880LlO/5790QKxySm
	SFUg=
X-Gm-Gg: ASbGncsDQ8AgdZStDVKIGKUQLFG9DeQqZcRA1JBj6g/Zfvnkc45gM06I2d2rC8Gs0TG
	l8O2G4sesfop8ULhP4ErqUQJFMcDzmfbcoQHInzHr61+vXPbhcX7Q/9jJFjGVljwxPjDZVtM+rL
	nHmeM7WoYm5xzfu7XlQKtRnoejxONYKDmrxqL5L1fXb0Kf/EyuF8nJObIFO4w9LaRclDfbVXkdB
	4OpyXpm9P0645vm3+kKeO8Rb9pqy3UUsjOSBVT0ZX1zM0QKqjAcWe8C1GJoWuaSM4qvp2X4sMdi
	5ZgA44mkaO7zIe8du2H2IVwb5z1LRB4t1FVTg1hJBtWHmGM/qwfkg1+/I1OKzBRJTQ==
X-Google-Smtp-Source: AGHT+IG+nd03K6bXfTItyDPlrQaxlloknSN7c9PECZGXc3Uso0wTuNV9xeI8f/uUiqaWMOWrrWjoWg==
X-Received: by 2002:a05:600c:3d9b:b0:434:f297:8e85 with SMTP id 5b1f17b1804b1-438dc3c39d6mr65674835e9.10.1738233455104;
        Thu, 30 Jan 2025 02:37:35 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: =?UTF-8?q?Daniel=20P=20=2E=20Berrang=C3=A9?= <berrange@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Bernhard Beschow <shentey@gmail.com>,
	Thomas Huth <thuth@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	Akihiko Odaki <akihiko.odaki@daynix.com>,
	Fabiano Rosas <farosas@suse.de>,
	Phil Dennis-Jordan <phil@philjordan.eu>,
	xen-devel@lists.xenproject.org,
	Laurent Vivier <lvivier@redhat.com>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
Subject: [PATCH v2 1/2] tests/qtest: Extract qtest_qom_has_concrete_type() helper
Date: Thu, 30 Jan 2025 11:37:27 +0100
Message-ID: <20250130103728.536-2-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250130103728.536-1-philmd@linaro.org>
References: <20250130103728.536-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Extract qtest_qom_has_concrete_type() out of qtest_has_device()
in order to re-use it in the following commit.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
---
 tests/qtest/libqtest.c | 89 ++++++++++++++++++++++++------------------
 1 file changed, 51 insertions(+), 38 deletions(-)

diff --git a/tests/qtest/libqtest.c b/tests/qtest/libqtest.c
index a1e105f27f9..7e9366ad6d5 100644
--- a/tests/qtest/libqtest.c
+++ b/tests/qtest/libqtest.c
@@ -978,6 +978,56 @@ const char *qtest_get_arch(void)
     return end + 1;
 }
 
+static bool qtest_qom_has_concrete_type(const char *parent_typename,
+                                        const char *child_typename,
+                                        QList **cached_list)
+{
+    QList *list = cached_list ? *cached_list : NULL;
+    const QListEntry *p;
+    QObject *qobj;
+    QString *qstr;
+    QDict *devinfo;
+    int idx;
+
+    if (!list) {
+        QDict *resp;
+        QDict *args;
+        QTestState *qts = qtest_init("-machine none");
+
+        args = qdict_new();
+        qdict_put_bool(args, "abstract", false);
+        qdict_put_str(args, "implements", parent_typename);
+
+        resp = qtest_qmp(qts, "{'execute': 'qom-list-types', 'arguments': %p }",
+                         args);
+        g_assert(qdict_haskey(resp, "return"));
+        list = qdict_get_qlist(resp, "return");
+        qobject_ref(list);
+        qobject_unref(resp);
+
+        qtest_quit(qts);
+
+        if (cached_list) {
+            *cached_list = list;
+        }
+    }
+
+    for (p = qlist_first(list), idx = 0; p; p = qlist_next(p), idx++) {
+        devinfo = qobject_to(QDict, qlist_entry_obj(p));
+        g_assert(devinfo);
+
+        qobj = qdict_get(devinfo, "name");
+        g_assert(qobj);
+        qstr = qobject_to(QString, qobj);
+        g_assert(qstr);
+        if (g_str_equal(qstring_get_str(qstr), child_typename)) {
+            return true;
+        }
+    }
+
+    return false;
+}
+
 bool qtest_has_accel(const char *accel_name)
 {
     if (g_str_equal(accel_name, "tcg")) {
@@ -1757,45 +1807,8 @@ bool qtest_has_machine(const char *machine)
 bool qtest_has_device(const char *device)
 {
     static QList *list;
-    const QListEntry *p;
-    QObject *qobj;
-    QString *qstr;
-    QDict *devinfo;
-    int idx;
 
-    if (!list) {
-        QDict *resp;
-        QDict *args;
-        QTestState *qts = qtest_init("-machine none");
-
-        args = qdict_new();
-        qdict_put_bool(args, "abstract", false);
-        qdict_put_str(args, "implements", "device");
-
-        resp = qtest_qmp(qts, "{'execute': 'qom-list-types', 'arguments': %p }",
-                         args);
-        g_assert(qdict_haskey(resp, "return"));
-        list = qdict_get_qlist(resp, "return");
-        qobject_ref(list);
-        qobject_unref(resp);
-
-        qtest_quit(qts);
-    }
-
-    for (p = qlist_first(list), idx = 0; p; p = qlist_next(p), idx++) {
-        devinfo = qobject_to(QDict, qlist_entry_obj(p));
-        g_assert(devinfo);
-
-        qobj = qdict_get(devinfo, "name");
-        g_assert(qobj);
-        qstr = qobject_to(QString, qobj);
-        g_assert(qstr);
-        if (g_str_equal(qstring_get_str(qstr), device)) {
-            return true;
-        }
-    }
-
-    return false;
+    return qtest_qom_has_concrete_type("device", device, &list);
 }
 
 /*
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 30 10:37:44 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Jan 2025 10:37:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879442.1289641 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdRvS-0005B0-Hv; Thu, 30 Jan 2025 10:37:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879442.1289641; Thu, 30 Jan 2025 10:37:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdRvS-0005At-Ez; Thu, 30 Jan 2025 10:37:34 +0000
Received: by outflank-mailman (input) for mailman id 879442;
 Thu, 30 Jan 2025 10:37:33 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=j2sA=UW=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tdRvR-0005An-49
 for xen-devel@lists.xenproject.org; Thu, 30 Jan 2025 10:37:33 +0000
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com
 [2a00:1450:4864:20::32e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 332011ac-def6-11ef-99a4-01e77a169b0f;
 Thu, 30 Jan 2025 11:37:27 +0100 (CET)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-43635796b48so3581915e9.0
 for <xen-devel@lists.xenproject.org>; Thu, 30 Jan 2025 02:37:30 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438e23dea58sm18398835e9.15.2025.01.30.02.37.29
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 30 Jan 2025 02:37:29 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 332011ac-def6-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1738233450; x=1738838250; 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=vJAhgdvuaUzoP5rhYvCoy1R4+PFzIiikeM9bnH6e+vE=;
        b=YEfZengSZCFcZL1qrkZRN+gJoN4pTU29mOKUZesOJ7VAK6C4CnioO5xPRH+wMCcadL
         ooLal/sDy0iciJuv00/t74a3i4inw1FMmLyEdluxvV6MUu6fnkjTwp189y7Q2qKm5jSL
         Fnfp4Fuz9bypRCNcIrQ9bRW891ISPRQCOXVTnqkloIHDvRM5+SYWAslxBEfVlr3IVERa
         bFwJCmpgro62gvTCauD186/F0U2TggiJ5QkK67dyEnyIIwLviaY0nQuDRCHIcWV+FyoZ
         1xW7zPDJGcWEPFiqSc9gTKbFuADDkgw0t1SttJ11O9vEgYu28H6AEiwjc6unz8RSu2Fs
         vISw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738233450; x=1738838250;
        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=vJAhgdvuaUzoP5rhYvCoy1R4+PFzIiikeM9bnH6e+vE=;
        b=D2RnSgSm+we1irzAayliciPc7en+WLJq1Y86o2SQurd8WCHlooix8swKZmimFE//1Y
         NTU5mR8jHKRa9Wf2KFEvnINStSeg+KjbkYULSbUjbNP+X+dEiFZcjH+kNy4Xn198xGxj
         dl10p2BkDcE6jDRHqji3HUttBneDA0LygXHmVEoV6OnlfM51hfZ2CxcLfNbrf1LAvvym
         v3W2jrD3/cN9Z05uDw9M7S9KOKn8svXS4IpeZCOdKzkEkJgHwufgaAM9Ui2Pb40Czp7i
         H9WpJWGEs/HIL4+X7duyLHojtM36Ztk+qU4QiPHiI4ogPWu064tq/x1WrcOADjCc4t8/
         z4Vw==
X-Forwarded-Encrypted: i=1; AJvYcCXvCH9VeQGdEax3gaWOqvValZ1YlDaHywT+muAoRjqQ+1gN7N5cXbn5Riis2u9FfTMQpuzQq8f3P+w=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw3x1fxQcMRIm2rnG51ym5gpAkKJTRYoUy8rPTFHPOaO/w+GTPV
	mthiHEev+ajubeGxwOdN4XKYhboH9NyQ/E6QXExOOxCJYxvewYn7QZCYLINjaI8=
X-Gm-Gg: ASbGncuhXXbzHFwRyifW24v8gzyt9G8Qs/7kaAHgTaFiJlukRxyKnLJvTLpHVHOOj0r
	2JBRCM8IvgtYli+pNaXhJkwu0b/Ougtjtaz+mJisZDZUWyEaYWOQDsFvMmTUM7k8AlnqPJ262qi
	Zr6iMWGFj8hSETPqMWMNI8VeubNpgQKF7wZvFbOmliOTNHX22VtEZ5w4JL8npjqFv+zImsBk24/
	mD6cMSSxGEpaYuILXQwrgBAs3lXE6CwF92Gdnp6YD/xDAjohgr7t3hA7lhewlb3x5iDR9wc+VBa
	G2gu5tyVVqgrnxPin1BRpLOOk8c5SFw8aYQ+d02oI7WDtqXqL1LiHQQq2cHCiodT0w==
X-Google-Smtp-Source: AGHT+IGK3HLzliP+MhxUr7psmyi6DTayWfInVMx+k7v2EncKNgyMI2rVs1CJKECTEksKE3IWOylWxA==
X-Received: by 2002:a05:600c:3d0d:b0:434:ff08:202e with SMTP id 5b1f17b1804b1-438e15ee1cemr21636335e9.8.1738233450329;
        Thu, 30 Jan 2025 02:37:30 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: =?UTF-8?q?Daniel=20P=20=2E=20Berrang=C3=A9?= <berrange@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Bernhard Beschow <shentey@gmail.com>,
	Thomas Huth <thuth@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	Akihiko Odaki <akihiko.odaki@daynix.com>,
	Fabiano Rosas <farosas@suse.de>,
	Phil Dennis-Jordan <phil@philjordan.eu>,
	xen-devel@lists.xenproject.org,
	Laurent Vivier <lvivier@redhat.com>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
Subject: [PATCH v2 0/2] tests/qtest: Make qtest_has_accel() generic
Date: Thu, 30 Jan 2025 11:37:26 +0100
Message-ID: <20250130103728.536-1-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

(Series fully reviewed)

Since v1:
- Use g_strconcat (Akihiko)

In preparation of running QTests using HVF on Darwin,
make qtest_has_accel() generic.

Note, this also allow running other accelerators such
Xen, WHPX, ...

Philippe Mathieu-Daudé (2):
  tests/qtest: Extract qtest_qom_has_concrete_type() helper
  tests/qtest: Make qtest_has_accel() generic

 tests/qtest/libqtest.c | 110 +++++++++++++++++++++++------------------
 1 file changed, 61 insertions(+), 49 deletions(-)

-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 30 10:37:44 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Jan 2025 10:37:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879444.1289660 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdRvb-0005g0-VE; Thu, 30 Jan 2025 10:37:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879444.1289660; Thu, 30 Jan 2025 10:37:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdRvb-0005ft-Rm; Thu, 30 Jan 2025 10:37:43 +0000
Received: by outflank-mailman (input) for mailman id 879444;
 Thu, 30 Jan 2025 10:37: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 <SRS0=j2sA=UW=linaro.org=philmd@srs-se1.protection.inumbo.net>)
 id 1tdRva-0005ei-Na
 for xen-devel@lists.xenproject.org; Thu, 30 Jan 2025 10:37:42 +0000
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com
 [2a00:1450:4864:20::333])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3ad0cb19-def6-11ef-a0e6-8be0dac302b0;
 Thu, 30 Jan 2025 11:37:41 +0100 (CET)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-4364a37a1d7so6050245e9.3
 for <xen-devel@lists.xenproject.org>; Thu, 30 Jan 2025 02:37:41 -0800 (PST)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438d7aa296esm56173275e9.1.2025.01.30.02.37.38
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Thu, 30 Jan 2025 02:37:39 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 3ad0cb19-def6-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1738233460; x=1738838260; 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=crB/f7vCa5hLa4LpwRk/HholuVWafRL1UUnQ0YPYia4=;
        b=VqOm0gzhr3quEpr4WnAjq4/GloRgP63zeXrker0ksaWuVyu6KiNcuNVr+4hen4kKa5
         k2fVtHNW2UgN/Bnz01POHaP+0SXcAG430xg9eckUfVYxgEHuFzXNK6Rs3PU3Vi5eZhgw
         1wKXHKrM+4ycSU2ijdCs5fgSw6XqqFXRrWXaevdef3M3BFzWW68TtGNYJvbSGh9EHkv4
         qYiXFMfkTN7lNQ33ighMpjfO8GduvrMTytRDF4sYU4Rhg0WPmAuTqhmX3zL/y2DqG7HV
         uxOMDufadSZbS55AyKy2CoLWuxkktkpHOG4AGpXaUd1bkp4E+qzqijEZOQHpqAQ8WjtZ
         lZOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738233460; x=1738838260;
        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=crB/f7vCa5hLa4LpwRk/HholuVWafRL1UUnQ0YPYia4=;
        b=flxQk5A87/8Y4IfD6ikVzZTlyUpI87hrD3Vh3OcPKdphso7pK9UyULvCipJemKaGcR
         v/7L0i7yeFheG41/y91GqF/ZMgT6+7K4ZtNDvHvwIly85d7n26hFfnqVIHt3o2DWUFvN
         3JbW0LTq9RjmnNEHRgPhONEJci+kIVLXfoPD9HjqJsGcNtbO2+cEyr854iyjEe9kgr4Z
         /EmW9jo7uU/YjvazOC30E3O5Vp0fyto/RKHrc+x5KW6Vy64fPUbapp3KOL7mqM6X3UYF
         4N3FGss+Mq1lqaT4lt9M4RGiWx5J9LuafxBLPm7MOspBOBue6MvdIcThufNWhRMlRYxS
         q7Sw==
X-Forwarded-Encrypted: i=1; AJvYcCUtME4wwEVFzxvT99/J23ltIP05RBzSxANI/PG0eP9y/W6M+dPUpVdNNmmlMubZM1ucso+ikpSpFxw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzcDYOxeNcdd2PA4Cejsdc/rOhb/6sefOsZr3lE1SfHQSOCOm8P
	24MtYooUc3wSAiqnqzg058R+afZEXkMcUzlKxC/pSM/gKW49yf4jeWMM4HRnRYc=
X-Gm-Gg: ASbGncuSOfcz3YcTlXaqNcCEfkdVzyxqImAgPPdfQvF5bWXryzEBQlHe4qwtO1sgT/j
	T7CGgyUF8NEJJ6mOZFkxZfJvwRPKqGYKFU0z/EfFbLcfxAb3bjIYhEO0Mu2HTT4wz3m/nBVS+UD
	lg9bsvdOVuNMfzkWqnPDzSVhX/S/ERTtya+QFDvMroP0Se1Rn/Lp6nWM9K7ECJS8KwhiTnX/TOw
	nA31vZLVD+GDVOx3Ln332jt41lM3RMRSF5jH6Dt4969kXc19CDLCy7a1FZ0xcfu+ymnhWBwQ9BG
	/bSYvLTsnvYOvkKMc6Qr3IRVAoiTZueya1vNuWf49UYuEUC2itpBlGuhAZXjxHwVlw==
X-Google-Smtp-Source: AGHT+IF1gLQHPAIuuIgyNdXKa7cL163sNFjn/3xyiZz/AIADfj2BGfFziESdqjtD8ZX3WUVzbzP+cQ==
X-Received: by 2002:a05:600c:190e:b0:438:d9ae:337b with SMTP id 5b1f17b1804b1-438dc3ca414mr59396625e9.17.1738233459802;
        Thu, 30 Jan 2025 02:37:39 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
To: qemu-devel@nongnu.org
Cc: =?UTF-8?q?Daniel=20P=20=2E=20Berrang=C3=A9?= <berrange@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Bernhard Beschow <shentey@gmail.com>,
	Thomas Huth <thuth@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	Akihiko Odaki <akihiko.odaki@daynix.com>,
	Fabiano Rosas <farosas@suse.de>,
	Phil Dennis-Jordan <phil@philjordan.eu>,
	xen-devel@lists.xenproject.org,
	Laurent Vivier <lvivier@redhat.com>,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>
Subject: [PATCH v2 2/2] tests/qtest: Make qtest_has_accel() generic
Date: Thu, 30 Jan 2025 11:37:28 +0100
Message-ID: <20250130103728.536-3-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250130103728.536-1-philmd@linaro.org>
References: <20250130103728.536-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Since commit b14a0b7469f ("accel: Use QOM classes for accel types")
accelerators are registered as QOM objects. Use QOM as a generic
API to query for available accelerators. This is in particular
useful to query hardware accelerators such HFV, Xen or WHPX which
otherwise have their definitions poisoned in "exec/poison.h".

Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 tests/qtest/libqtest.c | 21 ++++++++++-----------
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/tests/qtest/libqtest.c b/tests/qtest/libqtest.c
index 7e9366ad6d5..a55ac57ff7e 100644
--- a/tests/qtest/libqtest.c
+++ b/tests/qtest/libqtest.c
@@ -30,6 +30,7 @@
 
 #include "libqtest.h"
 #include "libqmp.h"
+#include "qemu/accel.h"
 #include "qemu/ctype.h"
 #include "qemu/cutils.h"
 #include "qemu/sockets.h"
@@ -1030,13 +1031,10 @@ static bool qtest_qom_has_concrete_type(const char *parent_typename,
 
 bool qtest_has_accel(const char *accel_name)
 {
-    if (g_str_equal(accel_name, "tcg")) {
-#if defined(CONFIG_TCG)
-        return true;
-#else
-        return false;
-#endif
-    } else if (g_str_equal(accel_name, "kvm")) {
+    static QList *list;
+    g_autofree char *accel_type = NULL;
+
+    if (g_str_equal(accel_name, "kvm")) {
         int i;
         const char *arch = qtest_get_arch();
         const char *targets[] = { CONFIG_KVM_TARGETS };
@@ -1048,11 +1046,12 @@ bool qtest_has_accel(const char *accel_name)
                 }
             }
         }
-    } else {
-        /* not implemented */
-        g_assert_not_reached();
+        return false;
     }
-    return false;
+
+    accel_type = g_strconcat(accel_name, ACCEL_CLASS_SUFFIX, NULL);
+
+    return qtest_qom_has_concrete_type("accel", accel_type, &list);
 }
 
 bool qtest_get_irq(QTestState *s, int num)
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Jan 30 11:11:08 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Jan 2025 11:11:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879468.1289671 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdSRq-0003JU-Do; Thu, 30 Jan 2025 11:11:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879468.1289671; Thu, 30 Jan 2025 11:11:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdSRq-0003JN-AK; Thu, 30 Jan 2025 11:11:02 +0000
Received: by outflank-mailman (input) for mailman id 879468;
 Thu, 30 Jan 2025 11:11:00 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=zr8Z=UW=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tdSRo-0003JH-9g
 for xen-devel@lists.xenproject.org; Thu, 30 Jan 2025 11:11:00 +0000
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com
 [2a00:1450:4864:20::42e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e1d0a5b7-defa-11ef-a0e6-8be0dac302b0;
 Thu, 30 Jan 2025 12:10:58 +0100 (CET)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-385d7b4da2bso548920f8f.1
 for <xen-devel@lists.xenproject.org>; Thu, 30 Jan 2025 03:10:58 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab6e4a314casm101767166b.127.2025.01.30.03.10.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 30 Jan 2025 03:10:57 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e1d0a5b7-defa-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738235458; x=1738840258; 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=0OM4H9pDpv5LRHGy5Rqwia44600X1pQwXwqcypJCuXM=;
        b=LPxde9yW3jPI37uOeDPDIekICR5BsgFBN1+6LZItAwpeIV/8k9lQ/F5oTMIjIT5iFQ
         SUVJXbkLQFlkYkuR4xwvYq89CX0QC1ZSoPus3kSXr0XLRLOO83QvEN6qkRcfWDpiLoCl
         qx0laVaT4P02rs1/K7FCtaPSkQQUFyfzQNDfqVSczuw7SQZHIO7EJKALPWi1Q19AWEcv
         eND1aYKX/+q6aMjyTFfHzcTkjxnzlZoPYsNrIAsGKx27FkI2lvLE6IEY08W/X+2IFVTE
         AeIy/vEDxyLsHg2q8HZN8/Yn+X7jXCGhZb94uHhtIje7ZF5y8JGfDqq4POdIS3DL8RWx
         kvsg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738235458; x=1738840258;
        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=0OM4H9pDpv5LRHGy5Rqwia44600X1pQwXwqcypJCuXM=;
        b=elAVo02rXpk0bFKJrCzhLw+oUhNRJVRvYJv/Hbz7UKEPF6OYHaTQY4MOnbbFh7QxJk
         dE0t/mLNFwEqc4mDvxizEE9F6LbRvEzgvnP2eSpfVl1JS+zqWtFJ0eQYk38/pJpzU5M7
         0Nz5YyJBl+LVxEr1enzvl4IzYRovouko8x0vHUi9LNig8Hb4dPNtddKaIOEKjgjavvcZ
         DG4m0d4wI+P2A1fwmVPUTvXRRIq4cC6KhOr51DVJzhJs0FZGvokamcLA1Q2eRzKf7do6
         0O34biCG6G9BnrpcZkyq8nrc6z1a+E4SE7E4mNZz9hKjXT+YK4kGtIa9Rh3w+ude/MR9
         kfkg==
X-Gm-Message-State: AOJu0Yxat6WyPWsJYbHVbVF3EybCZkcQsWbaNe/puqfmPQv2Sw+Gi6oW
	KQfYdQfIuBJ8/GXhYdgcUMvppdISYxy52ieiDf7sEsCawIv3AmENUs/Xa5/eI7TYD+Ys47nFbW8
	=
X-Gm-Gg: ASbGncseN02td5nwQW+kXBwNps8kCJwcoTgF4Hah/C8XBLWPPNwVjJwjxWPxIPDQZLB
	wli3jqLaHZdsI7PizMJLVLMIXhOo25YBtc1PJYVUcp691TJvwmF7gH6lBI4K0YwRv+Z+pLBbZOb
	8xseOFLV1ohOa8lOtk/mT/zJF6FYlLuBr8T8pZY43oly29Zq//61qOEy57vBvhSAHVSrsAZq5uz
	5q5vjglu5vS9p85QbMCnD8YyEiXS+y+LlECJIJpuJCPvGiToHf/JFwYD7Grob+ACzQtYn67WTKw
	1Dilj8IOvWyTD7yWUlolBlv60zw/VswoJlWkkI/vOSvbWXmSDLq77sJJ/yK9rLtqUXLC5NvDgNN
	6
X-Google-Smtp-Source: AGHT+IFCG5tD7yUrr26NxGcMatlETXNcnqLZJagxnU9S24I1BDBG3Pc42/YZNqX5jA0RGOJ/kedTAw==
X-Received: by 2002:a5d:5256:0:b0:386:3a8e:64bd with SMTP id ffacd0b85a97d-38c51952738mr5274559f8f.22.1738235457830;
        Thu, 30 Jan 2025 03:10:57 -0800 (PST)
Message-ID: <2bb9d3c4-0761-4d63-8193-29293e35eb04@suse.com>
Date: Thu, 30 Jan 2025 12:10:56 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH for-4.20 0/3] AMD/IOMMU: assorted corrections
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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

The three patches are functionally independent, and they're presented
here merely in the order I came to notice the respective issues. At least
patch 2 wants seriously considering for 4.20.

1: AMD/IOMMU: drop stray MSI enabling
2: x86/PCI: init segments earlier
3: AMD/IOMMU: log IVHD contents

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 30 11:11:57 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Jan 2025 11:11:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879475.1289681 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdSSj-0003o9-Le; Thu, 30 Jan 2025 11:11:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879475.1289681; Thu, 30 Jan 2025 11:11:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdSSj-0003o2-Ij; Thu, 30 Jan 2025 11:11:57 +0000
Received: by outflank-mailman (input) for mailman id 879475;
 Thu, 30 Jan 2025 11:11:56 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=zr8Z=UW=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tdSSi-0003ns-Bq
 for xen-devel@lists.xenproject.org; Thu, 30 Jan 2025 11:11:56 +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 0315f54e-defb-11ef-99a4-01e77a169b0f;
 Thu, 30 Jan 2025 12:11:54 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-aaef00ab172so131566366b.3
 for <xen-devel@lists.xenproject.org>; Thu, 30 Jan 2025 03:11: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
 a640c23a62f3a-ab6e4a31624sm101957666b.142.2025.01.30.03.11.53
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 30 Jan 2025 03:11:53 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 0315f54e-defb-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738235514; x=1738840314; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=0w1JF4p7h94nIJk2NabC//AHND+3+d+3/7CjsRj7Sxo=;
        b=TKCaCnyrZnQuGXW3jpNTl1R6z2WyIMkXHhgZd1uxxj5Bnoa1swBMZwJccqwW45ua3O
         fUekULt+rN3HHIIuPrT8ot2JaJU4q9E0Qxcap690XaHY+NY1UWBnFyHI8XFSTzbvSie5
         6zMSnOYHkJpuBmeKH0BjnD+Jc7NNsZMqJG7bv6eUo7pEy0xB+FbJ+JesHdX2UQaxUD+A
         zPvAO1895EW5UvWh8ajMVUTdPt0yuUcho91dZD5mix4rlLgHYfsEYiBs13TA27nOM3Uj
         KmaHY3YDuU3k4qB/WJqXrN4Gml44dRM31FlsuXV0M8Yz4IdVnhwQLEP4e4qv0ptS18Lv
         Riwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738235514; x=1738840314;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=0w1JF4p7h94nIJk2NabC//AHND+3+d+3/7CjsRj7Sxo=;
        b=LgwRtRxPzwFklWYeKcapCSOfT2Y9VpC/bVdVUNR95Q9asR9uW4nBTgimmebNvXy0VK
         OAokZN3s899Z0VjJlKDHKYC+gY+RFG/U37BzT42hTyJ9GBU1PeIWnkdTd+4dq4+XQw7X
         z6YNX5dWTXqBwQXmHkY84LKHJ78btnULuTwVBuZbfmgrdfjnDaJx4S+7HGARfQdG6mzs
         PF1e8AYHlJGjZQNfFGPi+N3beF3gItb0XUdGW9N0mXiVG5Fn/LKsGqVP+5yR3FgoPXkO
         bCrD3yt2mRk1J9BYtaWE3vTOBQjeJlXQ8qMlsjcsfwHWXLRAjS5bR0oGpLy+YH49/4iX
         ByWA==
X-Gm-Message-State: AOJu0YwotOgXoZnkC2C7IdVsCjjt8sJCe1nVXQcm4sucKsAbs/d4XR10
	twhES9lw9Tzv1HGPLID+V2MXogjJ8s2zhhex2x9W3+lL1XeJzfXIQ5Hps9/4pjknLVtL6POOrIQ
	=
X-Gm-Gg: ASbGncsqqte87PH2fyfnBYrl7tXaYNKQ8tHJ8LB5mzOcZro3aOJTTC2n4ClUrDhuepj
	aFbw0mjAz6ezcFNO0Tc71OHYowSj6BfHJB+NMWcJjcPwHqDx6pIFoPV5AE5uALAP2p7Z1l7lC5N
	ZZuAE+zlXIe69IfhmU1JrhIkFVdwg9gthVT6OCKlN5qUFnhRwGayoNVRtnqmXEcbeVQfCo2dFgK
	PoSiv7HB6nxkFuPwcZYmbIiwePzLdfWcgZ+5g0mJphJMn8kNdd383N6WQwDq6/4fXEjcLRcztzl
	WBc/5iicok13slLp5kOQwNNpCTlK5ospN+acmzVkBGFDwMB50ebagOJnjCluq19KcCHmOnBa2kN
	h
X-Google-Smtp-Source: AGHT+IFBDvZ66DWdAAmAmk4KyfLL2Qa8+TPR1j79CGG4gE3r/O6ytBYMUTFeyVJc1LdUiHU255s6SQ==
X-Received: by 2002:a05:6402:2399:b0:5dc:735a:f0a1 with SMTP id 4fb4d7f45d1cf-5dc735af29fmr2823976a12.8.1738235513679;
        Thu, 30 Jan 2025 03:11:53 -0800 (PST)
Message-ID: <ea0fea03-6002-4fc6-86ac-19598c9d9ef6@suse.com>
Date: Thu, 30 Jan 2025 12:11:52 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH for-4.20? 1/3] AMD/IOMMU: drop stray MSI enabling
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>
References: <2bb9d3c4-0761-4d63-8193-29293e35eb04@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <2bb9d3c4-0761-4d63-8193-29293e35eb04@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

While the 2nd of the commits referenced below should have moved the call
to amd_iommu_msi_enable() instead of adding another one, the situation
wasn't quite right even before: It can't have done any good to enable
MSI when no IRQ was allocated for it, yet.

Fixes: 5f569f1ac50e ("AMD/IOMMU: allow enabling with IRQ not yet set up")
Fixes: d9e49d1afe2e ("AMD/IOMMU: adjust setup of internal interrupt for x2APIC mode")
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/iommu_init.c
@@ -902,8 +902,6 @@ static void enable_iommu(struct amd_iomm
         }
     }
 
-    amd_iommu_msi_enable(iommu, IOMMU_CONTROL_ENABLED);
-
     set_iommu_ht_flags(iommu);
     set_iommu_command_buffer_control(iommu, IOMMU_CONTROL_ENABLED);
 



From xen-devel-bounces@lists.xenproject.org Thu Jan 30 11:12:35 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Jan 2025 11:12:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879484.1289690 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdSTL-0004MO-0M; Thu, 30 Jan 2025 11:12:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879484.1289690; Thu, 30 Jan 2025 11:12:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdSTK-0004MH-U0; Thu, 30 Jan 2025 11:12:34 +0000
Received: by outflank-mailman (input) for mailman id 879484;
 Thu, 30 Jan 2025 11:12: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 <SRS0=zr8Z=UW=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tdSTJ-0004Eh-BP
 for xen-devel@lists.xenproject.org; Thu, 30 Jan 2025 11:12:33 +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 1a06b5c8-defb-11ef-a0e6-8be0dac302b0;
 Thu, 30 Jan 2025 12:12:32 +0100 (CET)
Received: by mail-ed1-x52f.google.com with SMTP id
 4fb4d7f45d1cf-5dbfab8a2b0so1292027a12.3
 for <xen-devel@lists.xenproject.org>; Thu, 30 Jan 2025 03:12:32 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5dc723efc45sm889777a12.32.2025.01.30.03.12.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 30 Jan 2025 03:12:31 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1a06b5c8-defb-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738235552; x=1738840352; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=203/lJVcbBuSiBOTZslr+MFpCzEbnnZrAdk7fuxdPb4=;
        b=OFRAeVTNsraLQIm+bh5zg0AIJY9e/e2fmIk8EQH0q43YrtVrH2uOcya/WPSsQzV4Ze
         gL52OATTt7gFrC9Fprcwc65MwKBo+hBeV/5H/6rTxfuBso+rj6/VlP+qDQZ66Y5CcCAE
         hsvOXrCkEMChHvNhjI14NpaAZo2BgXY5tiwtbbU2KH5PI6B35GhzGoydm24mX20q4Moh
         3gYN10FL1ZAxf1atGA2fn+zW5QCAnOBQObtwUmo3Fiw6iU+uqyVs6N0hLUBMLV1CSq/o
         eqMtpZxsRgAvPfbxTJZOtkcyMQW1IPTqxi7EMYBG3Hk1xiHRi6fJ37LENC9+u0a2iPSD
         Bz7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738235552; x=1738840352;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=203/lJVcbBuSiBOTZslr+MFpCzEbnnZrAdk7fuxdPb4=;
        b=Zks/y7fL5H9Zf6hmqQPdG+mDLDlDZ2SMvLzTGCTvDzlkyA6Ok6GReFOjeG8y9HM6+p
         +cH1/FBVflbr9vFMWqFdQF2i5vxWrtEQlveQqEUhVcJPK0BmYDKjVixXFMc0a8sRoYv/
         8QZQjIpa26APYsparv98fYeGzE16k13EYEO0mO7Vgj3K6qPWenZ2hM/jYHIeifM8e++Q
         hDGRVpE2lkKD5ks8HoAu/Xkf8eiYNgW/ihhHEyeV8dS07zbYHpOIZXsm5Smw7nBVrQKv
         eN/7nD1dqGgoB2MSYUVZZATnqZ0Rz8WqKuyc3KA+zdxg8JgKRplwz74Cx8pFRHp40Bd9
         S4uw==
X-Gm-Message-State: AOJu0YxNH17Gp8/nCusUf6Fxdj0tzppNC4EAXNzWfMSjCYyeL/8iU0YK
	bNviCrIwJWIdwbL19rkfsiBoum+K+XqLEfFrDwp6Ezl21QkR3Q8r6o2lqRv8q4WytOELUP/DT+U
	=
X-Gm-Gg: ASbGncuhjGuGdZx1aloXAhxzQV+WO4Bf8guKlTXvtk9U7cMAuiQrbaK6E+bsEojyz3I
	YW6jeDjOkZrA80KZhv3G/nvwjPpQVJhS1odJ0fDCvpE8ShTM6871yfIQoeuVZgH1oowqYhjHWBY
	OXCf4O6pRM7QKLsrW8cuLySEvfPQE5RgSZygfvI9KM4Y9xkJfY8txbBQQPn//M+gbnXpWhYqxMe
	PTyeIoLGTTI+jsfhJAquVjJIwVUk1Ipr6uU6Lpt9Tp2noHsJRdFLo/elcV9hdY+QXSa/AGqt4hJ
	xnN0Ydn3coNbs2cZ5ZHrfPs8hOae1fDRC2pBztn/WFbx6HdznS9ZVbymOsVvfjxDfWQiKPBbsf/
	V
X-Google-Smtp-Source: AGHT+IGudiXusSP2uHk+VdJeM7vMvtwwfZHKTitaJdmZMgsqHjKiyq6vHxtlyr40vNZ9sUkp2r6mNg==
X-Received: by 2002:a05:6402:5109:b0:5dc:5a34:1296 with SMTP id 4fb4d7f45d1cf-5dc5efc5e1amr5442094a12.16.1738235552204;
        Thu, 30 Jan 2025 03:12:32 -0800 (PST)
Message-ID: <940ccd1b-9ad8-4b68-a035-36f45326872b@suse.com>
Date: Thu, 30 Jan 2025 12:12:31 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH for-4.20 2/3] x86/PCI: init segments earlier
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>
References: <2bb9d3c4-0761-4d63-8193-29293e35eb04@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <2bb9d3c4-0761-4d63-8193-29293e35eb04@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

In order for amd_iommu_detect_one_acpi()'s call to pci_ro_device() to
have permanent effect, pci_segments_init() needs to be called ahead of
making it there. Without this we're losing segment 0's r/o map, and thus
we're losing write-protection of the PCI devices representing IOMMUs.
Which in turn means that half-way recent Linux Dom0 will, as it boots,
turn off MSI on these devices, thus preventing any IOMMU events (faults
in particular) from being reported on pre-x2APIC hardware.

As the acpi_iommu_init() invocation was moved ahead of
acpi_mmcfg_init()'s by the offending commit, move the call to
pci_segments_init() accordingly.

Fixes: 3950f2485bbc ("x86/x2APIC: defer probe until after IOMMU ACPI table parsing")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
Of course it would have been quite a bit easier to notice this issue if
radix_tree_insert() wouldn't work fine ahead of radix_tree_init() being
invoked for a given radix tree, when the index inserted at is 0.

While hunting down various other dead paths to actually find the root
cause, it occurred to me that it's probably not a good idea to fully
disallow config space writes for r/o devices: Dom0 won't be able to size
their BARs (luckily the IOMMU "devices" don't have any, but e.g. serial
ones generally will have at least one), for example. Without being able
to size BARs it also will likely be unable to correctly account for the
address space taken by these BARs. However, outside of vPCI it's not
really clear to me how we could reasonably emulate such BAR sizing
writes - we can't, after all, allow Dom0 to actually write to the
underlying physical registers, yet we don't intercept reads (i.e. we
can't mimic expected behavior then).

--- a/xen/arch/x86/x86_64/mmconfig-shared.c
+++ b/xen/arch/x86/x86_64/mmconfig-shared.c
@@ -402,8 +402,6 @@ void __init acpi_mmcfg_init(void)
 {
     bool valid = true;
 
-    pci_segments_init();
-
     /* MMCONFIG disabled */
     if ((pci_probe & PCI_PROBE_MMCONF) == 0)
         return;
--- a/xen/drivers/passthrough/x86/iommu.c
+++ b/xen/drivers/passthrough/x86/iommu.c
@@ -55,6 +55,8 @@ void __init acpi_iommu_init(void)
 {
     int ret = -ENODEV;
 
+    pci_segments_init();
+
     if ( !iommu_enable && !iommu_intremap )
         return;
 



From xen-devel-bounces@lists.xenproject.org Thu Jan 30 11:13:10 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Jan 2025 11:13:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879491.1289701 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdSTu-0004qp-7s; Thu, 30 Jan 2025 11:13:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879491.1289701; Thu, 30 Jan 2025 11:13:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdSTu-0004qi-54; Thu, 30 Jan 2025 11:13:10 +0000
Received: by outflank-mailman (input) for mailman id 879491;
 Thu, 30 Jan 2025 11:13:09 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=zr8Z=UW=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tdSTs-0003ns-W5
 for xen-devel@lists.xenproject.org; Thu, 30 Jan 2025 11:13:08 +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 2ea500ff-defb-11ef-99a4-01e77a169b0f;
 Thu, 30 Jan 2025 12:13:07 +0100 (CET)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-5dc149e14fcso1138692a12.2
 for <xen-devel@lists.xenproject.org>; Thu, 30 Jan 2025 03:13:07 -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
 4fb4d7f45d1cf-5dc724c94b1sm901543a12.66.2025.01.30.03.13.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 30 Jan 2025 03:13:06 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2ea500ff-defb-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738235587; x=1738840387; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=V9vwx/V7mW1SrRmfY7WrHmeRj0Uzde1i3C5utHUovTg=;
        b=Eyp0Fb3hTiOioLBxZbHEea6mCoN7cCQW51s4KY1cBmK78jjwcZMvP6Zo5+vcdghnJG
         CU9k4l7j+saxS5i8oZQcfq16GXwqs//ohtHYNQCKwKE9BAgsEF3k5Xr3gQcW0pkTjU7j
         zVr99dZ5Xr/1lHqHLYEAqyuQ4gFLHrAfPfjgDiNhfIhdmKl9WwQ5yeq2ztLnalP74IvR
         9xPFtQ3NpByDpCfCtVtMCgAEzj9A9Dl40PLIYe8LpUqk7/D1kN7dVejbt/JxfiBA+t71
         X97mrU50Pv3sLxweCOQarVKRj/YQGnFB+88AzUiktURG4RPRfwM6CBlXZnxQcdN+vy9A
         wCUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738235587; x=1738840387;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=V9vwx/V7mW1SrRmfY7WrHmeRj0Uzde1i3C5utHUovTg=;
        b=kYA6AcBeyxgkkyS5HC6hD1nx7NW8c2+dhShIJlxXTel+ubJfXKkSarIH0v30igtWqv
         eP+ktYep3R2t9gSmteFaxdmZ/5w77DaZ87Uf8MzMNivjgejiOLhMQmU9yfVzBWvQSOLc
         rM5mStFTvcGU/gsoPtsPZbk4rFEKkEf+zy3mhbt4da6XM4kzA1ljakwsia93dwy6W98v
         Ml1elj8b1viLNe+Pwe0QbvhezoIFWlPrLYfsiCEhSc75QqRUPG7y6MjG5sdpvB9PEDfT
         MFAwHS0qZTtJIcexhqE2gVTGlCPkpL26fZizh7TTko6OMmVr9g5pyckKEjVK2izIgI3s
         PnjA==
X-Gm-Message-State: AOJu0YzmnW6ZVQeZNmrSca80hp2A04IG59uyH4LYf3TRKWFy5q9PkNwu
	oGMz8WIiArnJz5T99MedPxtSeSeCaAC2P68P6p+EbN8ymM+121j6d3Op72i2RMxwhwcM4/aaO88
	=
X-Gm-Gg: ASbGncuN2UpZFqroMrLQBMMrzzS2/IJmuxXF4Jw3aEWIq5crzojLo4R8zS7T6vQMYAZ
	tYpBejDKIrXe0TVPGUI4WIgDgmDiTiCb1n+7mush/U2TrwCdG/zHjVwKmdmNyrIiYioF/uS0qsW
	B1ZbPgEg4G4lum8iRAkuLGu1KoG7jRLn4JSwkI6yZVseQrHZv9kUMA7SGo0vJQMWuJR5q1ELj4D
	ea2HZ2Yf9F+Ivt0y1ZA0xa0myTiqkZoEyjZxXg+pNonixhVq6QMgnefNcEXlZRFnIM7JUGVJlGL
	+HjW7oSSTbxcIFR9o9Wck2MqrGAFMi/f83zsP94Y0a43mfQFb2x+p5DPcfV1I80CPMRQpJ4khw/
	x
X-Google-Smtp-Source: AGHT+IG6xC4jEPXW9L0hQq67LWsRj+B/KKoOd3P3KbafdpL1VtRAKMBlkhbx8oVSD7X2vc8QSlCJTQ==
X-Received: by 2002:a05:6402:51cf:b0:5d9:f042:dab with SMTP id 4fb4d7f45d1cf-5dc5efc4d4cmr7316347a12.18.1738235586818;
        Thu, 30 Jan 2025 03:13:06 -0800 (PST)
Message-ID: <b0b8c35f-5c88-46bb-a882-9ff737683367@suse.com>
Date: Thu, 30 Jan 2025 12:13:05 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH for-4.20? 3/3] AMD/IOMMU: log IVHD contents
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>
References: <2bb9d3c4-0761-4d63-8193-29293e35eb04@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <2bb9d3c4-0761-4d63-8193-29293e35eb04@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Despite all the verbosity with "iommu=debug", information on the IOMMUs
themselves was missing.

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

--- a/xen/drivers/passthrough/amd/iommu_acpi.c
+++ b/xen/drivers/passthrough/amd/iommu_acpi.c
@@ -911,6 +911,11 @@ static int __init parse_ivhd_block(const
         return -ENODEV;
     }
 
+    AMD_IOMMU_DEBUG("IVHD: IOMMU @ %#lx cap @ %#x seg 0x%04x info %#x attr %#x\n",
+                    ivhd_block->base_address, ivhd_block->capability_offset,
+                    ivhd_block->pci_segment_group, ivhd_block->info,
+                    ivhd_block->iommu_attr);
+
     iommu = find_iommu_from_bdf_cap(ivhd_block->pci_segment_group,
                                     ivhd_block->header.device_id,
                                     ivhd_block->capability_offset);



From xen-devel-bounces@lists.xenproject.org Thu Jan 30 12:35:33 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Jan 2025 12:35:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879511.1289711 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdTlQ-0007bF-Sv; Thu, 30 Jan 2025 12:35:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879511.1289711; Thu, 30 Jan 2025 12:35:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdTlQ-0007b8-QA; Thu, 30 Jan 2025 12:35:20 +0000
Received: by outflank-mailman (input) for mailman id 879511;
 Thu, 30 Jan 2025 12:35:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=l+oB=UW=suse.com=jgross@srs-se1.protection.inumbo.net>)
 id 1tdTlO-0007b2-Vh
 for xen-devel@lists.xenproject.org; Thu, 30 Jan 2025 12:35:19 +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 a7e2d40c-df06-11ef-99a4-01e77a169b0f;
 Thu, 30 Jan 2025 13:35:16 +0100 (CET)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3862d16b4f5so455415f8f.0
 for <xen-devel@lists.xenproject.org>; Thu, 30 Jan 2025 04:35:15 -0800 (PST)
Received: from ?IPV6:2003:e5:8731:2800:842d:42a0:5992:3595?
 (p200300e587312800842d42a059923595.dip0.t-ipconnect.de.
 [2003:e5:8731:2800:842d:42a0:5992:3595])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38c5c1cfccasm1865411f8f.92.2025.01.30.04.35.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 30 Jan 2025 04:35:14 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a7e2d40c-df06-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738240515; x=1738845315; darn=lists.xenproject.org;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=I927JtoZY1ZGIy4oBzZTc+NSe8DiCFpBKKs3zPkD0hc=;
        b=geIXiLHWENtZ5h3N1kEbHYYWQI0ltYMH6+rNvQSwpb+gB06BDE12sE2tOCwcHPASzj
         EIu5nsolA9IhofIzOei4PR6F6ww00WpWOiAm/+CPG6ZH8i0T73VACIUz2/MiYg/7tCdi
         leWNpBAGOXBdLBzn9wVC9TfIVFbeg/Z29b6o7FfNJ1ufkG6JNa8RmD4myxMpqCcd8ec/
         DNOKxSC9nembcbOOxdSDfEaIundMu/08tDmjjLCpP+YZTp0Q0gwmyxd/+FVorEGDrw9J
         vBSeGTacCwhjgzoTckcl4Pi4ul7Zm0RkwjVxaevV1vYbVGP6Uzzk4hkk2ez/tHVhNtM9
         wE4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738240515; x=1738845315;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=I927JtoZY1ZGIy4oBzZTc+NSe8DiCFpBKKs3zPkD0hc=;
        b=XdTBDzBuiGO+SP1BzcM75fIifR2aaNibpcSKTtccA18jIJiaHaZPZOL1dBN7O/LGzU
         fSlm4y55eGxzS/vED2Fg7FON/S73WIgs4a1OR7cb9BW+7ovLWXompmWNykRkuxq6aerL
         Ff55hMpvYhRbTqJAG9EO3rawCbZ3oG7uc9tHnuLi1yz4xvGaja8nBJzoUyF96jTruQcL
         XQlgzJAepBNZI8pjULcGFdKngw8ZOzoQ88ueHfjkxuRi6V7WNSk1GxIvIIXH9sd47jXR
         Hap7psVrgsdJiYeJ21keOavDf5QDX7JvC22L8QSpdYgKr2qp3N5BoVSVqgsa5ryv0tEw
         eTPg==
X-Forwarded-Encrypted: i=1; AJvYcCW2cjCUs+ddrWarmVtT/2WUnP+++UtzqDfpbL5BIs9YaUvrf2jmgYZ44N17xHgyrHOepPNXXBKPgp4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyErkhXg3SlJSIsjpoAb7hh2DnVanxRbhh094BKPDkq4FZ7Nmh/
	0cHf3RuJZZE6n4NE8YkFqIV1HrzLwQPB6UFKVkeUT/KaXvxoqeEEurUVOAFCKVs=
X-Gm-Gg: ASbGncvBESb6vGyEtvdZ3JUImMIzHvF5iS/iAyHaIZySedffzAJR+g2024X1aSz0VZI
	o7xMdH79SHhlI5MTUsqqqZ536H5iUWWQ0K3KsY0eLZgjVtX82wroUAN723AblxpLlHpNupJexfI
	QAJQ8CJY1NCHc5qGSUcpcIsaVWjYT/pY6WflEc/15qAH07+AhoxTy8YM0EGjR9USCZppOAfg6AN
	tW+uCu1zxMbROiIuPc3/yEA3QWmpYqaqfa+lSDgE8KyB/2TN0oOEkS+VeGTx4hvHy4MjsWQI2tf
	B9Q7cj329sTCaEqN6pqRWPiWpG8SCGDiW8kR/GRn9weePL/NgRuRvXL+r/QMf3WuZ3YdwXEDUop
	9hHl1RgPIFDqztC41z/yjxomc4pOOWIBCtxHM2W32
X-Google-Smtp-Source: AGHT+IHvv88m4Iy886HAnkleAo7jlkX11/5fps0cYyXOR1kTjfxaxzK9MHAnaxyWcVmrWAe0DAkNYQ==
X-Received: by 2002:a5d:47c3:0:b0:386:3327:4f21 with SMTP id ffacd0b85a97d-38c5a9bf70dmr2988462f8f.27.1738240514513;
        Thu, 30 Jan 2025 04:35:14 -0800 (PST)
Message-ID: <5a7d969b-b2ab-4fac-b95e-4a536e2c8d5c@suse.com>
Date: Thu, 30 Jan 2025 13:35:12 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: v5.4.289 failed to boot with error megasas_build_io_fusion 3219
 sge_count (-12) is out of range
To: Harshvardhan Jha <harshvardhan.j.jha@oracle.com>,
 Greg KH <gregkh@linuxfoundation.org>
Cc: Konrad Wilk <konrad.wilk@oracle.com>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 "sstabellini@kernel.org" <sstabellini@kernel.org>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
 Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>,
 stable@vger.kernel.org
References: <7dc143fa-4a48-440b-b624-ac57a361ac74@oracle.com>
 <9dd91f6e-1c66-4961-994e-dbda87d69dad@oracle.com>
 <2025012919-series-chaps-856e@gregkh>
 <8eb33b38-23e1-4e43-8952-3f2b05660236@oracle.com>
 <2025012936-finalize-ducktail-c524@gregkh>
 <1f017284-1a29-49d8-b0d9-92409561990e@oracle.com>
 <2025012956-jiffy-condone-3137@gregkh>
 <1f225b8d-d958-4304-829e-8798884d9b6b@oracle.com>
 <83bd90c7-8879-4462-9548-bb5b69cac39e@suse.com>
 <b4ab0246-3846-41d1-8e84-64bd7fefc089@oracle.com>
 <de6912ad-3dba-4d66-8ca2-71a0aa09172c@suse.com>
 <686986a0-c981-4aa3-ae88-92a34368129e@oracle.com>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <686986a0-c981-4aa3-ae88-92a34368129e@oracle.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------t5hcqb4cuk82BpuLqVi2z6GT"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------t5hcqb4cuk82BpuLqVi2z6GT
Content-Type: multipart/mixed; boundary="------------DOOB4yTA8AXW81Ct04V23JIP";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: Harshvardhan Jha <harshvardhan.j.jha@oracle.com>,
 Greg KH <gregkh@linuxfoundation.org>
Cc: Konrad Wilk <konrad.wilk@oracle.com>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 "sstabellini@kernel.org" <sstabellini@kernel.org>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
 Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>,
 stable@vger.kernel.org
Message-ID: <5a7d969b-b2ab-4fac-b95e-4a536e2c8d5c@suse.com>
Subject: Re: v5.4.289 failed to boot with error megasas_build_io_fusion 3219
 sge_count (-12) is out of range
References: <7dc143fa-4a48-440b-b624-ac57a361ac74@oracle.com>
 <9dd91f6e-1c66-4961-994e-dbda87d69dad@oracle.com>
 <2025012919-series-chaps-856e@gregkh>
 <8eb33b38-23e1-4e43-8952-3f2b05660236@oracle.com>
 <2025012936-finalize-ducktail-c524@gregkh>
 <1f017284-1a29-49d8-b0d9-92409561990e@oracle.com>
 <2025012956-jiffy-condone-3137@gregkh>
 <1f225b8d-d958-4304-829e-8798884d9b6b@oracle.com>
 <83bd90c7-8879-4462-9548-bb5b69cac39e@suse.com>
 <b4ab0246-3846-41d1-8e84-64bd7fefc089@oracle.com>
 <de6912ad-3dba-4d66-8ca2-71a0aa09172c@suse.com>
 <686986a0-c981-4aa3-ae88-92a34368129e@oracle.com>
In-Reply-To: <686986a0-c981-4aa3-ae88-92a34368129e@oracle.com>

--------------DOOB4yTA8AXW81Ct04V23JIP
Content-Type: multipart/mixed; boundary="------------KM7UcZ5u8nA4LipWLXgJ5FBE"

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

T24gMjkuMDEuMjUgMTk6NDYsIEhhcnNodmFyZGhhbiBKaGEgd3JvdGU6DQo+IA0KPiBPbiAz
MC8wMS8yNSAxMjoxMyBBTSwgSsO8cmdlbiBHcm/DnyB3cm90ZToNCj4+IE9uIDI5LjAxLjI1
IDE5OjM1LCBIYXJzaHZhcmRoYW4gSmhhIHdyb3RlOg0KPj4+DQo+Pj4gT24gMjkvMDEvMjUg
NDo1MiBQTSwgSnVlcmdlbiBHcm9zcyB3cm90ZToNCj4+Pj4gT24gMjkuMDEuMjUgMTA6MTUs
IEhhcnNodmFyZGhhbiBKaGEgd3JvdGU6DQo+Pj4+Pg0KPj4+Pj4gT24gMjkvMDEvMjUgMjoz
NCBQTSwgR3JlZyBLSCB3cm90ZToNCj4+Pj4+PiBPbiBXZWQsIEphbiAyOSwgMjAyNSBhdCAw
MjoyOTo0OFBNICswNTMwLCBIYXJzaHZhcmRoYW4gSmhhIHdyb3RlOg0KPj4+Pj4+PiBIaSBH
cmVnLA0KPj4+Pj4+Pg0KPj4+Pj4+PiBPbiAyOS8wMS8yNSAyOjE4IFBNLCBHcmVnIEtIIHdy
b3RlOg0KPj4+Pj4+Pj4gT24gV2VkLCBKYW4gMjksIDIwMjUgYXQgMDI6MTM6MzRQTSArMDUz
MCwgSGFyc2h2YXJkaGFuIEpoYSB3cm90ZToNCj4+Pj4+Pj4+PiBIaSB0aGVyZSwNCj4+Pj4+
Pj4+Pg0KPj4+Pj4+Pj4+IE9uIDI5LzAxLzI1IDI6MDUgUE0sIEdyZWcgS0ggd3JvdGU6DQo+
Pj4+Pj4+Pj4+IE9uIFdlZCwgSmFuIDI5LCAyMDI1IGF0IDAyOjAzOjUxUE0gKzA1MzAsIEhh
cnNodmFyZGhhbiBKaGEgd3JvdGU6DQo+Pj4+Pj4+Pj4+PiBIaSBBbGwsDQo+Pj4+Pj4+Pj4+
Pg0KPj4+Pj4+Pj4+Pj4gK3N0YWJsZQ0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IFRoZXJl
IHNlZW1zIHRvIGJlIHNvbWUgZm9ybWF0dGluZyBpc3N1ZXMgaW4gbXkgbG9nIG91dHB1dC4g
SQ0KPj4+Pj4+Pj4+Pj4gaGF2ZQ0KPj4+Pj4+Pj4+Pj4gYXR0YWNoZWQgaXQgYXMgYSBmaWxl
Lg0KPj4+Pj4+Pj4+PiBDb25mdXNlZCwgd2hhdCBhcmUgeW91IHdhbnRpbmcgdXMgdG8gZG8g
aGVyZSBpbiB0aGUgc3RhYmxlIHRyZWU/DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IHRoYW5r
cywNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gZ3JlZyBrLWgNCj4+Pj4+Pj4+PiBTaW5jZSwg
dGhpcyBpcyByZXByb2R1Y2libGUgb24gNS40LnkgSSBoYXZlIGFkZGVkIHN0YWJsZS4gVGhl
DQo+Pj4+Pj4+Pj4gY3VscHJpdA0KPj4+Pj4+Pj4+IGNvbW1pdCB3aGljaCB1cG9uIGdldHRp
bmcgcmV2ZXJ0ZWQgZml4ZXMgdGhpcyBpc3N1ZSBpcyBhbHNvDQo+Pj4+Pj4+Pj4gcHJlc2Vu
dCBpbg0KPj4+Pj4+Pj4+IDUuNC55IHN0YWJsZS4NCj4+Pj4+Pj4+IFdoYXQgY3VscHJpdCBj
b21taXQ/wqAgSSBzZWUgbm8gaW5mb3JtYXRpb24gaGVyZSA6KA0KPj4+Pj4+Pj4NCj4+Pj4+
Pj4+IFJlbWVtYmVyLCB0b3AtcG9zdGluZyBpcyBldmlsLi4uDQo+Pj4+Pj4+IE15IGFwb2xv
Z2llcywNCj4+Pj4+Pj4NCj4+Pj4+Pj4gVGhlIHN0YWJsZSB0YWcgdjUuNC4yODkgc2VlbXMg
dG8gZmFpbCB0byBib290IHdpdGggdGhlIGZvbGxvd2luZw0KPj4+Pj4+PiBwcm9tcHQgaW4g
YW4gaW5maW5pdGUgbG9vcDoNCj4+Pj4+Pj4gW8KgwqAgMjQuNDI3MjE3XSBtZWdhcmFpZF9z
YXMgMDAwMDo2NTowMC4wOiBtZWdhc2FzX2J1aWxkX2lvX2Z1c2lvbg0KPj4+Pj4+PiAzMjcz
IHNnZV9jb3VudCAoLTEyKSBpcyBvdXQgb2YgcmFuZ2UuIFJhbmdlIGlzOsKgIDAtMjU2DQo+
Pj4+Pj4+DQo+Pj4+Pj4+IFJldmVydGluZyB0aGUgZm9sbG93aW5nIHBhdGNoIHNlZW1zIHRv
IGZpeCB0aGUgaXNzdWU6DQo+Pj4+Pj4+DQo+Pj4+Pj4+IHN0YWJsZS01LjTCoMKgwqDCoMKg
IDogdjUuNC4yODXCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgLSA1ZGYyOWE0NDVmM2ENCj4+
Pj4+Pj4geGVuL3N3aW90bGI6IGFkZA0KPj4+Pj4+PiBhbGlnbm1lbnQgY2hlY2sgZm9yIGRt
YSBidWZmZXJzDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEkgdHJpZWQgY2hhbmdpbmcgc3dpb3RsYiBn
cnViIGNvbW1hbmQgbGluZSBhcmd1bWVudHMgYnV0IHRoYXQgZGlkbid0DQo+Pj4+Pj4+IHNl
ZW0gdG8gaGVscCBtdWNoIHVuZm9ydHVuYXRlbHkgYW5kIHRoZSBlcnJvciB3YXMgc2VlbiBh
Z2Fpbi4NCj4+Pj4+Pj4NCj4+Pj4+PiBPaywgY2FuIHlvdSBzdWJtaXQgdGhpcyByZXZlcnQg
d2l0aCB0aGUgaW5mb3JtYXRpb24gYWJvdXQgd2h5IGl0DQo+Pj4+Pj4gc2hvdWxkDQo+Pj4+
Pj4gbm90IGJlIGluY2x1ZGVkIGluIHRoZSA1LjQueSB0cmVlIGFuZCBjYzogZXZlcnlvbmUg
aW52b2x2ZWQgYW5kDQo+Pj4+Pj4gdGhlbiB3ZQ0KPj4+Pj4+IHdpbGwgYmUgZ2xhZCB0byBx
dWV1ZSBpdCB1cC4NCj4+Pj4+Pg0KPj4+Pj4+IHRoYW5rcywNCj4+Pj4+Pg0KPj4+Pj4+IGdy
ZWcgay1oDQo+Pj4+Pg0KPj4+Pj4gVGhpcyBtaWdodCBiZSByZXByb2R1Y2libGUgb24gb3Ro
ZXIgc3RhYmxlIHRyZWVzIGFuZCBtYWlubGluZSBhcw0KPj4+Pj4gd2VsbCBzbw0KPj4+Pj4g
d2Ugd2lsbCBnZXQgaXQgZml4ZWQgdGhlcmUgYW5kIEkgd2lsbCBzdWJtaXQgdGhlIG5lY2Vz
c2FyeSBmaXggdG8NCj4+Pj4+IHN0YWJsZQ0KPj4+Pj4gd2hlbiBldmVyeXRoaW5nIGlzIHNv
cnRlZCBvdXQgb24gbWFpbmxpbmUuDQo+Pj4+DQo+Pj4+IFJpZ2h0LiBKdXN0IHJldmVydGlu
ZyBteSBwYXRjaCB3aWxsIHRyYWRlIG9uZSBlcnJvciB3aXRoIGFub3RoZXIgb25lDQo+Pj4+
ICh0aGUNCj4+Pj4gb25lIHdoaWNoIHRyaWdnZXJlZCBtZSB0byB3cml0ZSB0aGUgcGF0Y2gp
Lg0KPj4+Pg0KPj4+PiBUaGVyZSBhcmUgdHdvIHBvc3NpYmxlIHdheXMgdG8gZml4IHRoZSBp
c3N1ZToNCj4+Pj4NCj4+Pj4gLSBhbGxvdyBsYXJnZXIgRE1BIGJ1ZmZlcnMgaW4geGVuL3N3
aW90bGIgKHRvZGF5IDJNQiBhcmUgdGhlIG1heC4NCj4+Pj4gc3VwcG9ydGVkDQo+Pj4+ICDC
oMKgIHNpemUsIHRoZSBtZWdhcmFpZF9zYXMgZHJpdmVyIHNlZW1zIHRvIGVmZmVjdGl2ZWx5
IHJlcXVlc3QgNE1CKQ0KPj4+DQo+Pj4gVGhpcyBzZWVtcyByZWxhdGl2ZWx5IHNpbXBsZXIg
dG8gaW1wbGVtZW50IGJ1dCBJJ20gbm90IHN1cmUgd2hldGhlciBpdCdzDQo+Pj4gdGhlIG1v
c3Qgb3B0aW1hbCBhcHByb2FjaA0KPj4NCj4+IEp1c3QgbWFraW5nIHRoZSBzdGF0aWMgYXJy
YXkgbGFyZ2VyIHVzZWQgdG8gaG9sZCB0aGUgZnJhbWUgbnVtYmVycyBmb3INCj4+IHRoZQ0K
Pj4gYnVmZmVyIHNlZW1zIHRvIGJlIGEgd2FzdGUgb2YgbWVtb3J5IGZvciBtb3N0IGNvbmZp
Z3VyYXRpb25zLg0KPiBZZXAgZGVmaW5pdGVseSBub3QgcmVxdWlyZWQgaW4gbW9zdCBjYXNl
cy4NCj4+DQo+PiBJJ20gdGhpbmtpbmcgb2YgYW4gYWxsb2NhdGVkIGFycmF5IHVzaW5nIHRo
ZSBtYXggbmVlZGVkIHNpemUgKHJlcGxhY2UgYQ0KPj4gZm9ybWVyIGJ1ZmZlciB3aXRoIGEg
bGFyZ2VyIG9uZSBpZiBuZWVkZWQpLg0KPiANCj4gVGhpcyBzZWVtcyBsaWtlIHRoZSByaWdo
dCB3YXkgdG8gZ28uDQoNCkNhbiB5b3UgdHJ5IHRoZSBhdHRhY2hlZCBwYXRjaCwgcGxlYXNl
PyBJIGRvbid0IGhhdmUgYSBzeXN0ZW0gYXQgaGFuZA0Kc2hvd2luZyB0aGUgcHJvYmxlbS4N
Cg0KDQpKdWVyZ2VuDQo=
--------------KM7UcZ5u8nA4LipWLXgJ5FBE
Content-Type: text/x-patch; charset=UTF-8;
 name="0001-x86-xen-allow-larger-contiguous-memory-regions-in-PV.patch"
Content-Disposition: attachment;
 filename*0="0001-x86-xen-allow-larger-contiguous-memory-regions-in-PV.pa";
 filename*1="tch"
Content-Transfer-Encoding: base64

RnJvbSBjZmY0M2U5OTdmNzlhOTVkYzQ0ZTAyZGViYWVhZmU1ZjEyN2Y0MGJiIE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBKdWVyZ2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+
CkRhdGU6IFRodSwgMzAgSmFuIDIwMjUgMDk6NTY6NTcgKzAxMDAKU3ViamVjdDogW1BBVENI
XSB4ODYveGVuOiBhbGxvdyBsYXJnZXIgY29udGlndW91cyBtZW1vcnkgcmVnaW9ucyBpbiBQ
ViBndWVzdHMKClRvZGF5IGEgUFYgZ3Vlc3QgKGluY2x1ZGluZyBkb20wKSBjYW4gY3JlYXRl
IDJNQiBjb250aWd1b3VzIG1lbW9yeQpyZWdpb25zIGZvciBETUEgYnVmZmVycyBhdCBtYXgu
IFRoaXMgaGFzIGxlZCB0byBwcm9ibGVtcyBhdCBsZWFzdAp3aXRoIHRoZSBtZWdhcmFpZF9z
YXMgZHJpdmVyLCB3aGljaCB3YW50cyB0byBhbGxvY2F0ZSBhIDIuM01CIERNQQpidWZmZXIu
CgpUaGUgbGltaXRpbmcgZmFjdG9yIGlzIHRoZSBmcmFtZSBhcnJheSB1c2VkIHRvIGRvIHRo
ZSBoeXBlcmNhbGwgZm9yCm1ha2luZyB0aGUgbWVtb3J5IGNvbnRpZ3VvdXMsIHdoaWNoIGhh
cyA1MTIgZW50cmllcyBhbmQgaXMganVzdCBhCnN0YXRpYyBhcnJheSBpbiBtbXVfcHYuYy4K
CkluIGNhc2UgYSBjb250aWd1b3VzIG1lbW9yeSBhcmVhIGxhcmdlciB0aGFuIHRoZSBpbml0
aWFsbHkgc3VwcG9ydGVkCjJNQiBpcyByZXF1ZXN0ZWQsIGFsbG9jYXRlIGEgbGFyZ2VyIGJ1
ZmZlciBmb3IgdGhlIGZyYW1lIGxpc3QuIE5vdGUKdGhhdCBzdWNoIGFuIGFsbG9jYXRpb24g
aXMgdHJpZWQgb25seSBhZnRlciBtZW1vcnkgbWFuYWdlbWVudCBoYXMgYmVlbgppbml0aWFs
aXplZCBwcm9wZXJseSwgd2hpY2ggaXMgdGVzdGVkIHZpYSB0aGUgZWFybHlfYm9vdF9pcnFz
X2Rpc2FibGVkCmZsYWcuCgpGaXhlczogOWY0MGVjODRhNzk3ICgieGVuL3N3aW90bGI6IGFk
ZCBhbGlnbm1lbnQgY2hlY2sgZm9yIGRtYSBidWZmZXJzIikKU2lnbmVkLW9mZi1ieTogSnVl
cmdlbiBHcm9zcyA8amdyb3NzQHN1c2UuY29tPgotLS0KTm90ZSB0aGF0IHRoZSAiRml4ZXM6
IiB0YWcgaXMgbm90IHJlYWxseSBjb3JyZWN0LCBhcyB0aGF0IHBhdGNoIGRpZG4ndAppbnRy
b2R1Y2UgdGhlIHByb2JsZW0sIGJ1dCByYXRoZXIgbWFkZSBpdCB2aXNpYmxlLiBPVE9IIGl0
IGlzIHRoZSBiZXN0CmluZGljYXRvciB3ZSBoYXZlIHRvIGlkZW50aWZ5IGtlcm5lbCB2ZXJz
aW9ucyB0aGlzIHBhdGNoIHNob3VsZCBiZQpiYWNrcG9ydGVkIHRvLgotLS0KIGFyY2gveDg2
L3hlbi9tbXVfcHYuYyB8IDQ0ICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
Ky0tLS0tLS0KIDEgZmlsZSBjaGFuZ2VkLCAzNyBpbnNlcnRpb25zKCspLCA3IGRlbGV0aW9u
cygtKQoKZGlmZiAtLWdpdCBhL2FyY2gveDg2L3hlbi9tbXVfcHYuYyBiL2FyY2gveDg2L3hl
bi9tbXVfcHYuYwppbmRleCA1NWE0OTk2ZDBjMDQuLjYyYWVjMjliODE3NCAxMDA2NDQKLS0t
IGEvYXJjaC94ODYveGVuL21tdV9wdi5jCisrKyBiL2FyY2gveDg2L3hlbi9tbXVfcHYuYwpA
QCAtMjIwMCw4ICsyMjAwLDEwIEBAIHZvaWQgX19pbml0IHhlbl9pbml0X21tdV9vcHModm9p
ZCkKIH0KIAogLyogUHJvdGVjdGVkIGJ5IHhlbl9yZXNlcnZhdGlvbl9sb2NrLiAqLwotI2Rl
ZmluZSBNQVhfQ09OVElHX09SREVSIDkgLyogMk1CICovCi1zdGF0aWMgdW5zaWduZWQgbG9u
ZyBkaXNjb250aWdfZnJhbWVzWzE8PE1BWF9DT05USUdfT1JERVJdOworI2RlZmluZSBNSU5f
Q09OVElHX09SREVSIDkgLyogMk1CICovCitzdGF0aWMgdW5zaWduZWQgaW50IGRpc2NvbnRp
Z19mcmFtZXNfb3JkZXIgPSBNSU5fQ09OVElHX09SREVSOworc3RhdGljIHVuc2lnbmVkIGxv
bmcgZGlzY29udGlnX2ZyYW1lc19lYXJseVsxVUwgPDwgTUlOX0NPTlRJR19PUkRFUl07Citz
dGF0aWMgdW5zaWduZWQgbG9uZyAqZGlzY29udGlnX2ZyYW1lcyA9IGRpc2NvbnRpZ19mcmFt
ZXNfZWFybHk7CiAKICNkZWZpbmUgVk9JRF9QVEUgKG1mbl9wdGUoMCwgX19wZ3Byb3QoMCkp
KQogc3RhdGljIHZvaWQgeGVuX3phcF9wZm5fcmFuZ2UodW5zaWduZWQgbG9uZyB2YWRkciwg
dW5zaWduZWQgaW50IG9yZGVyLApAQCAtMjMxOSwxOCArMjMyMSw0NCBAQCBpbnQgeGVuX2Ny
ZWF0ZV9jb250aWd1b3VzX3JlZ2lvbihwaHlzX2FkZHJfdCBwc3RhcnQsIHVuc2lnbmVkIGlu
dCBvcmRlciwKIAkJCQkgdW5zaWduZWQgaW50IGFkZHJlc3NfYml0cywKIAkJCQkgZG1hX2Fk
ZHJfdCAqZG1hX2hhbmRsZSkKIHsKLQl1bnNpZ25lZCBsb25nICppbl9mcmFtZXMgPSBkaXNj
b250aWdfZnJhbWVzLCBvdXRfZnJhbWU7CisJdW5zaWduZWQgbG9uZyAqaW5fZnJhbWVzLCBv
dXRfZnJhbWU7CisJdW5zaWduZWQgbG9uZyAqbmV3X2FycmF5LCAqb2xkX2FycmF5OwogCXVu
c2lnbmVkIGxvbmcgIGZsYWdzOwogCWludCAgICAgICAgICAgIHN1Y2Nlc3M7CiAJdW5zaWdu
ZWQgbG9uZyB2c3RhcnQgPSAodW5zaWduZWQgbG9uZylwaHlzX3RvX3ZpcnQocHN0YXJ0KTsK
IAotCWlmICh1bmxpa2VseShvcmRlciA+IE1BWF9DT05USUdfT1JERVIpKQotCQlyZXR1cm4g
LUVOT01FTTsKKwlpZiAodW5saWtlbHkob3JkZXIgPiBkaXNjb250aWdfZnJhbWVzX29yZGVy
KSkgeworCQlpZiAoZWFybHlfYm9vdF9pcnFzX2Rpc2FibGVkKQorCQkJcmV0dXJuIC1FTk9N
RU07CisKKwkJbmV3X2FycmF5ID0gdm1hbGxvYyhzaXplb2YodW5zaWduZWQgbG9uZykgKiAo
MVVMIDw8IG9yZGVyKSk7CisKKwkJaWYgKCFuZXdfYXJyYXkpCisJCQlyZXR1cm4gLUVOT01F
TTsKKworCQlzcGluX2xvY2tfaXJxc2F2ZSgmeGVuX3Jlc2VydmF0aW9uX2xvY2ssIGZsYWdz
KTsKKworCQlpZiAob3JkZXIgPiBkaXNjb250aWdfZnJhbWVzX29yZGVyKSB7CisJCQlpZiAo
ZGlzY29udGlnX2ZyYW1lcyA9PSBkaXNjb250aWdfZnJhbWVzX2Vhcmx5KQorCQkJCW9sZF9h
cnJheSA9IE5VTEw7CisJCQllbHNlCisJCQkJb2xkX2FycmF5ID0gZGlzY29udGlnX2ZyYW1l
czsKKwkJCWRpc2NvbnRpZ19mcmFtZXMgPSBuZXdfYXJyYXk7CisJCQlkaXNjb250aWdfZnJh
bWVzX29yZGVyID0gb3JkZXI7CisJCX0gZWxzZQorCQkJb2xkX2FycmF5ID0gbmV3X2FycmF5
OworCisJCXNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJnhlbl9yZXNlcnZhdGlvbl9sb2NrLCBm
bGFncyk7CisKKwkJdmZyZWUob2xkX2FycmF5KTsKKwl9CiAKIAltZW1zZXQoKHZvaWQgKikg
dnN0YXJ0LCAwLCBQQUdFX1NJWkUgPDwgb3JkZXIpOwogCiAJc3Bpbl9sb2NrX2lycXNhdmUo
Jnhlbl9yZXNlcnZhdGlvbl9sb2NrLCBmbGFncyk7CiAKKwlpbl9mcmFtZXMgPSBkaXNjb250
aWdfZnJhbWVzOworCiAJLyogMS4gWmFwIGN1cnJlbnQgUFRFcywgcmVtZW1iZXJpbmcgTUZO
cy4gKi8KIAl4ZW5femFwX3Bmbl9yYW5nZSh2c3RhcnQsIG9yZGVyLCBpbl9mcmFtZXMsIE5V
TEwpOwogCkBAIC0yMzU0LDEyICsyMzgyLDEyIEBAIGludCB4ZW5fY3JlYXRlX2NvbnRpZ3Vv
dXNfcmVnaW9uKHBoeXNfYWRkcl90IHBzdGFydCwgdW5zaWduZWQgaW50IG9yZGVyLAogCiB2
b2lkIHhlbl9kZXN0cm95X2NvbnRpZ3VvdXNfcmVnaW9uKHBoeXNfYWRkcl90IHBzdGFydCwg
dW5zaWduZWQgaW50IG9yZGVyKQogewotCXVuc2lnbmVkIGxvbmcgKm91dF9mcmFtZXMgPSBk
aXNjb250aWdfZnJhbWVzLCBpbl9mcmFtZTsKKwl1bnNpZ25lZCBsb25nICpvdXRfZnJhbWVz
LCBpbl9mcmFtZTsKIAl1bnNpZ25lZCBsb25nICBmbGFnczsKIAlpbnQgc3VjY2VzczsKIAl1
bnNpZ25lZCBsb25nIHZzdGFydDsKIAotCWlmICh1bmxpa2VseShvcmRlciA+IE1BWF9DT05U
SUdfT1JERVIpKQorCWlmICh1bmxpa2VseShvcmRlciA+IGRpc2NvbnRpZ19mcmFtZXNfb3Jk
ZXIpKQogCQlyZXR1cm47CiAKIAl2c3RhcnQgPSAodW5zaWduZWQgbG9uZylwaHlzX3RvX3Zp
cnQocHN0YXJ0KTsKQEAgLTIzNjcsNiArMjM5NSw4IEBAIHZvaWQgeGVuX2Rlc3Ryb3lfY29u
dGlndW91c19yZWdpb24ocGh5c19hZGRyX3QgcHN0YXJ0LCB1bnNpZ25lZCBpbnQgb3JkZXIp
CiAKIAlzcGluX2xvY2tfaXJxc2F2ZSgmeGVuX3Jlc2VydmF0aW9uX2xvY2ssIGZsYWdzKTsK
IAorCW91dF9mcmFtZXMgPSBkaXNjb250aWdfZnJhbWVzOworCiAJLyogMS4gRmluZCBzdGFy
dCBNRk4gb2YgY29udGlndW91cyBleHRlbnQuICovCiAJaW5fZnJhbWUgPSB2aXJ0X3RvX21m
bigodm9pZCAqKXZzdGFydCk7CiAKLS0gCjIuNDMuMAoK
--------------KM7UcZ5u8nA4LipWLXgJ5FBE
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

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

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

--------------KM7UcZ5u8nA4LipWLXgJ5FBE--

--------------DOOB4yTA8AXW81Ct04V23JIP--

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

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

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmebcgEFAwAAAAAACgkQsN6d1ii/Ey8O
2wf+KYF/+CGuTKb6asqmgU1uxGGhH8Dp53bAr5yPSpBU+7WPJdshtWLweZZdhk06j64ROxAkHemZ
ElulKH8aaLY9BJ5xwomAt21tA8PCYSRF5a0ZTzTu55jkGMCt3tjMEqj96wX92ggBvBK3+uLltH9x
mBlWofnoSAAtGLTBvufe0rlM18L3US8YRUgYCtuFxdE95uutw9uC/81zzzT3adKp4zvV1CDiJ4h6
6mmJDUTGPoyX2xYBEwnqQ6k87n/HXcFKUPZcmQD5e7Uo5y+VL3otOHf2HqNZ2pLjBdR8k7ZwAL12
LmU2XDBY6L8GYvb+OrGDHL8Ih782DMjHdil56H3DnA==
=7EMz
-----END PGP SIGNATURE-----

--------------t5hcqb4cuk82BpuLqVi2z6GT--


From xen-devel-bounces@lists.xenproject.org Thu Jan 30 12:59:57 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Jan 2025 12:59:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879520.1289720 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdU99-00025m-P3; Thu, 30 Jan 2025 12:59:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879520.1289720; Thu, 30 Jan 2025 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 <xen-devel-bounces@lists.xenproject.org>)
	id 1tdU99-00025f-MY; Thu, 30 Jan 2025 12:59:51 +0000
Received: by outflank-mailman (input) for mailman id 879520;
 Thu, 30 Jan 2025 12:59:49 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=zr8Z=UW=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tdU97-00025X-JX
 for xen-devel@lists.xenproject.org; Thu, 30 Jan 2025 12:59:49 +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 15798fbe-df0a-11ef-a0e6-8be0dac302b0;
 Thu, 30 Jan 2025 13:59:47 +0100 (CET)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-5d3f28881d6so982498a12.1
 for <xen-devel@lists.xenproject.org>; Thu, 30 Jan 2025 04:59:47 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5dc7240487csm1034743a12.34.2025.01.30.04.59.46
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 30 Jan 2025 04:59:46 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 15798fbe-df0a-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738241987; x=1738846787; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=wwVeJj4CxR7oTo3eqhOfTKhj7jWcIGyhA+/cpoWWkXY=;
        b=LDEiM1Vo6NM/urnyExr+Cxk0TkxmfYwSrBoJAYbWm8Zx2g18KM+OrsodfqoHCqiMQu
         I9E3cQW74LZvKP1HjIvSYzP6TUa454UqpkhbFzP8LxVYDdsSTF39EO2et7KUPKRnUK6h
         NDtj9KgdC+CB8rOV2OknljPt9h5LOZFECHK8bHeVQ+uer/chT0eTxVDTd33vRtSgm5Ul
         mHx+wlIEJTEEGPJcupaTMUosQTuyO4JUWiQXdFMiNCrtLVo/SWPVyVRbENipwS9VZ/8M
         hCdGf0CXM/kk+fvEMSoyRpJs965hVoTo2w7h0D9xca98Ew9PVHBDpkdkJOgDrW1Y6YA6
         /fww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738241987; x=1738846787;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=wwVeJj4CxR7oTo3eqhOfTKhj7jWcIGyhA+/cpoWWkXY=;
        b=TyseVTdRJLGxfR919uFV/nFrMcnmssw9TV4EZ22Vx1J2sEUIrJPXzMhDPgOUBxrBuj
         KolBYN899TcM+m/eTk4SBAnxxbaMyUZkNQQXGZoHL6oJ1/WbVOA29z9IW66Rf3YeOV2B
         oh3GPn20tEyDyx3dw+axY1JCKt6G0bzL3mpGyKhsDdTasEPxCcd0IAfWpeSEEfGuhMK7
         jpP6mGTvCBb5Zq0L5e8z3v8gqJGGmLImqjas4JGsWLiyvzYi4FmB5UnYInK7pnu4XvxK
         /qdHSkacGurRT2bFbSh844Pr6sgJpF08ElqjwqywnvEM1q1RMQXy5e8WFFvHFBNTem85
         OUOg==
X-Forwarded-Encrypted: i=1; AJvYcCUdQtRDJDLODTPw7VbDvUjyAf+3VnaS5Mn82ZCtrnmKYNtzaM9vkbXp4984jXWdTFUGxf5WvkfL5S4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwnjsmVgOJV59+WL3PXogInKWmnCTdyiddgPKIK5oJtsqLbtZr2
	nk0I8P5IvuUth28UBXtaM4k8uH6O9pYsINENZFJ0m7Yd7U2VP1MRpjS3hw6fMpo3HU6Ov9YD+y8
	=
X-Gm-Gg: ASbGncs/3naOVUsM/ofEnxMfmW8KVARX63bSvxkW0LjxsGKrFTxM3UhcvSoztfhwZVB
	jW7eKEHCpfYLtcBYuFuo5UpuJcmKYpYrphbZTIksAovDWSTt+0FdGoPk15OzHCgTHkz1nJCMhoj
	V8t0BWy6abyJnkCg5nGsmsLTS0RvHemkAZwAxisVpMQDCAofsk0RI+NATDy9+GlgH4uoHMDPbZI
	x+E2POhsR5YAAFWq2gbSBmZ3n44qW5nEfw/P8kiW8/VG4q/NREvIYPcbkRZEDoW5XY+tcM9S3k0
	WuTx0egxUb5xyNW65I+32uD4BCzyETHi6eldx/A9Xz3XtjusrG4D2W0oytEj0aR/41ae627+zHB
	T
X-Google-Smtp-Source: AGHT+IHLqJ78fXRkDAONZaCq2vBnZbryfWrBDathI8Gg2BbCXrEtWn5wkGhghg36F8nnywiiut2HYw==
X-Received: by 2002:a05:6402:278f:b0:5d3:ba42:e9e3 with SMTP id 4fb4d7f45d1cf-5dc5efbf53dmr17741131a12.13.1738241986825;
        Thu, 30 Jan 2025 04:59:46 -0800 (PST)
Message-ID: <86fba4ae-5a54-4fc0-bdaa-290332462cbf@suse.com>
Date: Thu, 30 Jan 2025 13:59:45 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/3] tools/hvmloader: Replace LAPIC_ID() with
 cpu_to_apicid[]
To: Alejandro Vallejo <alejandro.vallejo@cloud.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>, xen-devel@lists.xenproject.org
References: <20250128163342.1491-1-alejandro.vallejo@cloud.com>
 <20250128163342.1491-3-alejandro.vallejo@cloud.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250128163342.1491-3-alejandro.vallejo@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 28.01.2025 17:33, Alejandro Vallejo wrote:
> Replace uses of the LAPIC_ID() macro with accesses to the
> cpu_to_apicid[] lookup table. This table contains the APIC IDs of each
> vCPU as probed at runtime rather than assuming a predefined relation.
> 
> Moved smp_initialise() ahead of apic_setup() in order to initialise
> cpu_to_apicid ASAP and avoid using it uninitialised. Note that bringing
> up the APs doesn't need the APIC in hvmloader becasue it always runs
> virtualized and uses the PV interface.
> 
> Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
> ---
> Changes from v7 of the longer topology series:
>   * Removed ASSERT() for the MP tables and merely skipped writing them
>     if any vCPU has an APIC ID >=255.

Throughout the patch I can't anything matching this; ...

> --- a/tools/firmware/hvmloader/config.h
> +++ b/tools/firmware/hvmloader/config.h
> @@ -48,8 +48,9 @@ extern uint8_t ioapic_version;
>  
>  #define IOAPIC_ID           0x01
>  
> +extern uint32_t *cpu_to_apicid;
> +
>  #define LAPIC_BASE_ADDRESS  0xfee00000
> -#define LAPIC_ID(vcpu_id)   ((vcpu_id) * 2)
>  
>  #define PCI_ISA_DEVFN       0x08    /* dev 1, fn 0 */
>  #define PCI_ISA_IRQ_MASK    0x0c20U /* ISA IRQs 5,10,11 are PCI connected */
> --- a/tools/firmware/hvmloader/hvmloader.c
> +++ b/tools/firmware/hvmloader/hvmloader.c
> @@ -224,7 +224,7 @@ static void apic_setup(void)
>  
>      /* 8259A ExtInts are delivered through IOAPIC pin 0 (Virtual Wire Mode). */
>      ioapic_write(0x10, APIC_DM_EXTINT);
> -    ioapic_write(0x11, SET_APIC_ID(LAPIC_ID(0)));
> +    ioapic_write(0x11, SET_APIC_ID(cpu_to_apicid[0]));
>  }
>  
>  struct bios_info {
> @@ -341,11 +341,11 @@ int main(void)
>  
>      printf("CPU speed is %u MHz\n", get_cpu_mhz());
>  
> +    smp_initialise();
> +
>      apic_setup();
>      pci_setup();
>  
> -    smp_initialise();
> -
>      perform_tests();
>  
>      if ( bios->bios_info_setup )
> --- a/tools/firmware/hvmloader/mp_tables.c
> +++ b/tools/firmware/hvmloader/mp_tables.c
> @@ -199,7 +199,7 @@ static void fill_mp_config_table(struct mp_config_table *mpct, int length)
>  static void fill_mp_proc_entry(struct mp_proc_entry *mppe, int vcpu_id)
>  {
>      mppe->type = ENTRY_TYPE_PROCESSOR;
> -    mppe->lapic_id = LAPIC_ID(vcpu_id);
> +    mppe->lapic_id = cpu_to_apicid[vcpu_id];
>      mppe->lapic_version = 0x11;
>      mppe->cpu_flags = CPU_FLAG_ENABLED;
>      if ( vcpu_id == 0 )
> --- a/tools/firmware/hvmloader/util.c
> +++ b/tools/firmware/hvmloader/util.c
> @@ -827,7 +827,7 @@ static void acpi_mem_free(struct acpi_ctxt *ctxt,
>  
>  static uint32_t acpi_lapic_id(unsigned cpu)
>  {
> -    return LAPIC_ID(cpu);
> +    return cpu_to_apicid[cpu];
>  }
>  
>  void hvmloader_acpi_build_tables(struct acpi_config *config,

... no conditional is being added anywhere. What am I missing?

Thing is - this way I'm uncertain whether the wording above is
imprecise, or whether I should really ask that we continue to write all
entries with at most 8-bit-wide APIC IDs, omitting just those with
wider ones.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 30 13:02:24 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Jan 2025 13:02:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879531.1289731 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdUBb-0003il-8s; Thu, 30 Jan 2025 13:02:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879531.1289731; Thu, 30 Jan 2025 13:02:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdUBb-0003ie-5h; Thu, 30 Jan 2025 13:02:23 +0000
Received: by outflank-mailman (input) for mailman id 879531;
 Thu, 30 Jan 2025 13:02: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 <SRS0=zr8Z=UW=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tdUBa-0003iY-Ee
 for xen-devel@lists.xenproject.org; Thu, 30 Jan 2025 13:02:22 +0000
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com
 [2a00:1450:4864:20::52d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 713f2f72-df0a-11ef-a0e6-8be0dac302b0;
 Thu, 30 Jan 2025 14:02:21 +0100 (CET)
Received: by mail-ed1-x52d.google.com with SMTP id
 4fb4d7f45d1cf-5d3e6274015so1244200a12.0
 for <xen-devel@lists.xenproject.org>; Thu, 30 Jan 2025 05:02: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
 4fb4d7f45d1cf-5dc723d0021sm1050516a12.5.2025.01.30.05.02.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 30 Jan 2025 05:02:20 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 713f2f72-df0a-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738242141; x=1738846941; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=dhBKkyMKFLQGFgRqtZx5QzBR67KbmMu+gZvn6LeSaQs=;
        b=ENGN6sINC3rkGcShThB/Z8R1i/tFTFRRzMv5bVDIlayZqKcD4Cr83YBAQOuo9daEe7
         Z8uLRRaxAt0tE+ADDUhJgtFYAV3UfeQdJbPXLh1W9XrTR0VlwcvqklHxdeSbIIEnkhf+
         DE76HPUSv7zvH5sk/G0BUXXzYxxpIcIhE5AYFJfPzz8DwDmcuU57JNEZDaCHmXQJH1rI
         Nhnc20+SQyqFOvEfKZmVkdZKzvOLpVik0nP67cpbGaO2k7jWqTbccXXYK8Hjn8qn+Nz+
         H6Cp5oP7wAPFVTNWbnarURTewbNOA30vsUCOTYXZe5BpMRemyOAyIURicr89jC6As1BL
         dfjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738242141; x=1738846941;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=dhBKkyMKFLQGFgRqtZx5QzBR67KbmMu+gZvn6LeSaQs=;
        b=aFu93QvyugPe5STxaFPArT557sJCq4lGmSWZtsepmY7zNm7G/k8WLYW8XatyYloDu6
         9f7Y81FJtE2San9HPXauZ+M5n7GqQUyzNWyDGn+lZgUGaOc5XwYnXDk2qQa6i1guZn4W
         GPxGf+EFDleRoPAKGdZBSbsB69g/cKAxVNnHFFZ2Iz9+irGb1+u03xW4x/lCiUkv7REx
         q50rKYDbUqc0fJzEdYLEV0fxkMoNVQTBhX0hkwj1vv/+UWFNblQC23dxfDjgjCtg6LpS
         5E/sjghTu6nK/clX50a3HqbWr7DJaIDF9RYFd2jXEiEzPlQ1KSPeGiibRqHTjEQo0taY
         MRaw==
X-Forwarded-Encrypted: i=1; AJvYcCUJiZHTIE8AE0PtfnIR8E71UyAAWQL4QezdzfheH6D1Bsm8gBpVly8tgdyDVCiJ/ko5VfgBrGVmnIM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyfljeARM7moluizhoUvQjloUyliNRG/SkfTLicJx8noNCdJeva
	xa+Y+YjtuM6IUbG5UsqLwp0mvZwI9XKNhyRUsKUFkbuREoJI4OBUyq5teRMuhg==
X-Gm-Gg: ASbGnct9TQ6wvCoUGwz03x35ubK59Csbm4+7h30QObqMhrUoVWe29xGDQDjAAYUbD2R
	1oy6zXh3gFChbLeXp4Hl65J+7vAXXf020wqCtuTK1r2OBgADQisJqKH80klY8ZhHGVuqy1/RsWD
	bZJ9xRceouXAmCyQrPuNhfMOac30lZWTRVh4oeud26wprlewbjRt+h3GSyH1a8k7UBaCYHf0Dpp
	QUGN9qdF4eQrqtm+JXQzezLbrKwhPtDpPIDNw3Fi+5MTm5Kvjl7r815wpWsWtFMVsFRIlXPMgIl
	0BSySRFONQ4RScleiLf2tPkSgb4/O1W8kPXGSPb8poYmgH4+bPF3tzAiswBsX6ln1aFTUbBKdSw
	N
X-Google-Smtp-Source: AGHT+IEjPEi8l0joPn9UY3tVYZvSwXubrQApCCPiEn93vgRY/Rf3MtHBT/hEmyok1pNhpOFcyLlYVg==
X-Received: by 2002:a05:6402:84c:b0:5d3:e9fd:9a15 with SMTP id 4fb4d7f45d1cf-5dc5f0084abmr6591395a12.32.1738242140968;
        Thu, 30 Jan 2025 05:02:20 -0800 (PST)
Message-ID: <e0ab6920-86bd-4a0c-a5ff-4129b314bfd6@suse.com>
Date: Thu, 30 Jan 2025 14:02:19 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/3] tools/hvmloader: Skip writing MP tables if any CPU
 has an APIC ID >= 255
To: Alejandro Vallejo <alejandro.vallejo@cloud.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>, xen-devel@lists.xenproject.org
References: <20250128163342.1491-1-alejandro.vallejo@cloud.com>
 <20250128163342.1491-4-alejandro.vallejo@cloud.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250128163342.1491-4-alejandro.vallejo@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 28.01.2025 17:33, Alejandro Vallejo wrote:
> MP Tables have no means of representing APIC IDs wider than 255. At the
> moment the effect is wrapping around which would give a corrupted table
> with duplicate APIC IDs (some of them possibly the broadcast 255).
> 
> Skip writing it altogether. While it would be possible to restrict the
> APs shown it's just not worth the work. Any OS that needs such
> adjustments should not have been booted with that many vCPUs to begin
> with.
> 
> Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>

Oh, here we go. Yet then indeed ...

> --- a/tools/firmware/hvmloader/config.h
> +++ b/tools/firmware/hvmloader/config.h
> @@ -49,6 +49,7 @@ extern uint8_t ioapic_version;
>  #define IOAPIC_ID           0x01
>  
>  extern uint32_t *cpu_to_apicid;
> +extern uint32_t max_apicid;

.. I don't think we need this, as ...

> --- a/tools/firmware/hvmloader/hvmloader.c
> +++ b/tools/firmware/hvmloader/hvmloader.c
> @@ -389,7 +389,11 @@ int main(void)
>  
>      if ( (hvm_info->nr_vcpus > 1) || hvm_info->apic_mode )
>      {
> -        if ( bios->create_mp_tables )
> +        /*
> +         * Legacy MP tables hold strictly xAPIC IDs. Skip writing
> +         * the tables altogether if we have IDs wider than 8bits.
> +         */
> +        if ( max_apicid < 0xFF && bios->create_mp_tables )
>              bios->create_mp_tables();

I think we ought to continue to write MP tables in this case, merely
omitting processor entries with APIC IDs that don't fit.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 30 13:12:15 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Jan 2025 13:12:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879540.1289740 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdUL3-0005R2-3E; Thu, 30 Jan 2025 13:12:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879540.1289740; Thu, 30 Jan 2025 13:12:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdUL3-0005Qv-0i; Thu, 30 Jan 2025 13:12:09 +0000
Received: by outflank-mailman (input) for mailman id 879540;
 Thu, 30 Jan 2025 13:12:08 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=zr8Z=UW=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tdUL2-0005Qp-AR
 for xen-devel@lists.xenproject.org; Thu, 30 Jan 2025 13:12:08 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ce057ddb-df0b-11ef-a0e6-8be0dac302b0;
 Thu, 30 Jan 2025 14:12:07 +0100 (CET)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-5d7e3f1fc01so1521857a12.2
 for <xen-devel@lists.xenproject.org>; Thu, 30 Jan 2025 05:12:06 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab6e4a5635bsm115677866b.164.2025.01.30.05.12.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 30 Jan 2025 05:12:05 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ce057ddb-df0b-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738242726; x=1738847526; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=hR3mxz4iO59pz8lIUOtj6Jo/T8UDytMT+govV4YAs08=;
        b=LmPhTg22UqeCeF9em9WQlEvTckkIBuD1xfRCBaHzDpIPSHCaLhAx+CyiS0/uwz7yxm
         /W0vJg4GFJVc3PJx533xyrjd4F3TKyaZ2k3TLEBow/qBvdljOHRgklkUmniB7yLbmKN9
         vYgRDs4K5Bh+svNpdJzthJ9Pjn8b5SRdqn+8AOCjrYssXmolF1xP7eGZsf8k0+4jOAcZ
         0ig+QUE6j6fjRvwQ0VByP6HsZl9g0xcRjh6EVlFMVBMqzDg9uTBcS+MhJdNeudLoo72p
         V846uCRQ1HvSXjyQJ9+JqK3rtvD8fe8G0HMqv48x9kRxgIwUVyi8SuEWneC2oUB4jJH8
         zVBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738242726; x=1738847526;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=hR3mxz4iO59pz8lIUOtj6Jo/T8UDytMT+govV4YAs08=;
        b=XVAT4uutz8Pi7bC2yw6WVhmf+EyY+uGGKbM8CZun3l5CrLikYBMLbCl7lpanMNrNax
         N0wiLpsvFy74gVdnnEIPQqe/RrPC8X6ijFz2c4LzsO6+DLJy3Z2OkCPRzFUX6QAbMgQf
         vAUvXwqtgUlSKf34V4Y1l/pl8CjVPsznE1kLpKH94K00JGPSb/VMknHK+1xzRO4+DAju
         ZcOh16+Zq9H6zvDusfXDfdkF0+jGXlQ2d+rzm0lykoTcabY/DzMmhOYmiwwGZilD5AHd
         4KXQQzmwClArZIEQEBejwS5e4x4miyoNWe5TOPKFDebOZcbuXEwPEy+tIM5s5HPc7ab1
         5Tag==
X-Forwarded-Encrypted: i=1; AJvYcCVTkromfIFymatPXovxTSuzj4p+p4+wC9BUdImEgfz4CJ1k4hFo/FMQ1/SPgk1TIqEcmG5hgXqqIQw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy5bvDQlGXYAEsH+iBKh8BkoiSbETh5bogcaSerjfVr4baG64xZ
	oRd+lrZcKykj1Y0sGbGMH6TMFlId1tfuv9rphE2W4doeVvLBgofCxzc70bE2NA==
X-Gm-Gg: ASbGnctK8bFgK4ci4BRdZxRjadWpSXm1IA3ou8O8c9E+HvOMI1HOD1syzLshQNZWFb8
	CE1bLFFaAGvdI9X5ZFtkGEWCGWXHI93FvHUN1xK6uOiRErF35Fjj6M8WmYkFL7BHSTIJ4H+Top6
	RbfLt17trUOGfqJpWRP7XRkCsKVMNfdOgJK/2IuxrCy/HFT/abd6P9FM6DMVPd1tRD2ANnrYdSa
	SqxgPIEvcjU1fVIXeZFn7DyAQknkGbUtTxu8jeMk8u8y4XRT2jE8JyYeO3CE0MvDOfhsaW2F3Q6
	sIC75X6l0oQXQak9FPWXeUwBJ04jRMF6/lMeY9YDjZxEUDT65NxDGoGbKkgS31K70a9dlVdMABf
	U
X-Google-Smtp-Source: AGHT+IHIhWViDrziAW9ZWgePOKMwZianzDwA+AHPvcOJDJYDIElq/gkeSsMlF+uN5Cjs2xcmtxj+vQ==
X-Received: by 2002:a17:907:3dab:b0:aa6:7091:1e91 with SMTP id a640c23a62f3a-ab6cfcc6f11mr731449866b.11.1738242726072;
        Thu, 30 Jan 2025 05:12:06 -0800 (PST)
Message-ID: <f28c0573-8ded-431d-a6ba-b814755b3380@suse.com>
Date: Thu, 30 Jan 2025 14:12:04 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 20/24] x86/hvm: add HVM-specific Kconfig
To: dmukhin@ford.com
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
 <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com>
 <20250103-vuart-ns8250-v3-v1-20-c5d36b31d66c@ford.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250103-vuart-ns8250-v3-v1-20-c5d36b31d66c@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04.01.2025 02:58, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin <dmukhin@ford.com>
> 
> Add separate menu for configuring HVM build-time settings to help organizing
> HVM-specific options.
> 
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>

Largely: Why not. Question is whether what is being moved now may
eventually require moving back, if support was extended to PV (MEM_PAGING
and MEM_SHARING). That doesn't look very likely though.

> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -30,7 +30,6 @@ config X86
>  	select HAS_SCHED_GRANULARITY
>  	select HAS_UBSAN
>  	select HAS_VMAP
> -	select HAS_VPCI if HVM
>  	select NEEDS_LIBELF

I don't mind the movement of this line, but I'd like to point out that it
may be beneficial to have all selects of HAS_* in a central place. Views
of other maintainers (or of course anyone else) appreciated.

> --- /dev/null
> +++ b/xen/arch/x86/hvm/Kconfig
> @@ -0,0 +1,74 @@
> +menuconfig HVM
> +	bool "HVM support"
> +	depends on !PV_SHIM_EXCLUSIVE
> +	default !PV_SHIM
> +	select COMPAT
> +	select IOREQ_SERVER
> +	select MEM_ACCESS_ALWAYS_ON
> +	select HAS_VPCI

We strive to have such lists of selects sorted alphabetically, preventing
everyone to add to the end of the list (in turn reducing the risk of
patches conflicting).

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 30 13:15:03 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Jan 2025 13:15:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879548.1289750 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdUNq-000608-Fc; Thu, 30 Jan 2025 13:15:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879548.1289750; Thu, 30 Jan 2025 13:15:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdUNq-000601-Cu; Thu, 30 Jan 2025 13:15:02 +0000
Received: by outflank-mailman (input) for mailman id 879548;
 Thu, 30 Jan 2025 13:15:01 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=zr8Z=UW=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tdUNp-0005zt-0W
 for xen-devel@lists.xenproject.org; Thu, 30 Jan 2025 13:15:01 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3565db6f-df0c-11ef-a0e6-8be0dac302b0;
 Thu, 30 Jan 2025 14:15:00 +0100 (CET)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-ab6ed8a3f6aso59384966b.2
 for <xen-devel@lists.xenproject.org>; Thu, 30 Jan 2025 05:15:00 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab6e47a7fc2sm119308866b.37.2025.01.30.05.14.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 30 Jan 2025 05:14:59 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 3565db6f-df0c-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738242899; x=1738847699; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=KwpFGvRRs+3NF+GLon9isEJU2HhAwCR7pDMivKby9zY=;
        b=P3Mx6Jq3/0Nzv4WHsmS1Sm6cBmvREf4C9QHvWP2ruUo5+zJt6vIbPYHiKdWsHFtlIT
         CTtnQHiqtpBQ3TrUrq1HR34sTxg2QU+rRA2YGTNQ695Kxz9cgc53qGgBt51Ds5zNCDO3
         3V/q405ttRgQSOIz8UI2+FRbyOZJLH0uRA2wYhRnzDc/BCIXayVlq4KCz3/emYJMTk87
         2Vi47i5dvmSn7DTOCMMJ7q6yYRgBpF4wSvA3MgAzDgQAWKH36ZYqYmUevGh8CPkKbtUA
         gwpV7JzNq019FWH5yFDSZ6Y2qD1c30Dx1hYwMyyjos4BC6H/wYWjLLXBYFOQcHKlgKP8
         BoYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738242899; x=1738847699;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=KwpFGvRRs+3NF+GLon9isEJU2HhAwCR7pDMivKby9zY=;
        b=YKry49nIsspY27F5nK6SvMM75bn1Hs1CKbgphsLfl7o2upP80vUK7Rz6Q2gxAmjV8V
         9de1S4tN6oeXmywtuo3IJI1Cs/KgMJqOdf9JauhzbR2LYIw2afa1UOl4W0cOAfPiucLz
         KFbHtr+lvnZbG4fqYbnxr3/HIfYQ+vOwqX+IObRhQzKX5GBiSlzXFAEJyp9fhI/eHN14
         Dm/XfusX2nFaspXAvHNFYJ2GRAheEUOpOWI6S10Ns5okSVFWvi3+zvISRZRM+jVo/Ggh
         A6M0Q1aiSrIUaFl0FNuuT561D29JZwuvKTaFXZUVcUSRi7f94ZjYMIIHSaMn6rCtQ+ef
         yoLQ==
X-Forwarded-Encrypted: i=1; AJvYcCVEfkRwzdQfSgfNnIeYOtgsH+2535phSXpG44TLxhlj5/rLoBZQntXq1sFux2/8fkKcduvyEC0HcO4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxcEFmUSDI5RIu9TemZApkBnECP8WL4qBEwzAfMy2m0PCpNCOKN
	sv/VYCDDa9lVpxLOg1z0FWS3UYHZiivV68FjsYtaHISrQdsmsyO+Q9LTQBGhKQ==
X-Gm-Gg: ASbGnctp/46XoZqzEqgqnhFnH3wSWH4Tb2XHi5A3iIMk2Xbnsxe4KhAmubzTtxz7Jdc
	FoUzrDmOZcCY2VOygtYMI/PKKRFeGJgxHYjFJIZZ/3tXCfqsglU3yuAdtRGgHlDHTCRsJhffLGu
	QgauA7L6SGIeGGAodTmvnVUMXur6rXkZqj7DE07U7wJ/kwNr9+AkZifkvlV6KHPGN9gsoftJ5OF
	sZiabZFZ6jT/BTZJhz8IEZvZkSnAvHxv0LU7Uiii73HxXXBB57NVhyfB0Q6VtmM+EQ7PksvxmjX
	Bg9CTa2goEGoEK7DpzpY8mrrKiUNGkjVjnAwKWErsTHJTeTqLu7WBibJt4wGNNzmwK9wbGev5SX
	D
X-Google-Smtp-Source: AGHT+IGNz1W7lX07gSEzFb/LwnSiee3zZpyw3i0PptaHZkUhHff4bsW65lsdMGFkxSqy/fAr5q1wjA==
X-Received: by 2002:a17:907:94d1:b0:ab6:eec9:5c08 with SMTP id a640c23a62f3a-ab6eec95d8emr113153666b.10.1738242899577;
        Thu, 30 Jan 2025 05:14:59 -0800 (PST)
Message-ID: <99b26eb1-eed7-4eb0-8be5-d1e971eede8a@suse.com>
Date: Thu, 30 Jan 2025 14:14:58 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/4] automation: rename CONFIG_MEM_ACCESS ->
 CONFIG_VM_EVENT
To: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
Cc: Nicola Vetrini <nicola.vetrini@bugseng.com>,
 Doug Goldstein <cardoe@cardoe.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1737452864.git.Sergiy_Kibrik@epam.com>
 <e43444e0cd04bf08edf47ee4c56d0aa675d19534.1737452864.git.Sergiy_Kibrik@epam.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <e43444e0cd04bf08edf47ee4c56d0aa675d19534.1737452864.git.Sergiy_Kibrik@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 21.01.2025 11:23, Sergiy Kibrik wrote:
> Following the renaming of Xen build option.
> 
> Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
> ---
>  automation/eclair_analysis/xen_arm_config | 2 +-
>  automation/eclair_analysis/xen_x86_config | 2 +-
>  automation/gitlab-ci/build.yaml           | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)

This can't really be separated from the changes doing the actual rename,
can it? Aiui the build (randconfig ones in particular) may break between
the two patches, or what is being tested may end up being different.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 30 13:24:30 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Jan 2025 13:24:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879556.1289762 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdUWv-0007qQ-Ca; Thu, 30 Jan 2025 13:24:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879556.1289762; Thu, 30 Jan 2025 13:24:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdUWv-0007qJ-6z; Thu, 30 Jan 2025 13:24:25 +0000
Received: by outflank-mailman (input) for mailman id 879556;
 Thu, 30 Jan 2025 13:24:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=zr8Z=UW=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tdUWu-0007qD-3X
 for xen-devel@lists.xenproject.org; Thu, 30 Jan 2025 13:24:24 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 84526289-df0d-11ef-99a4-01e77a169b0f;
 Thu, 30 Jan 2025 14:24:22 +0100 (CET)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-5d3bdccba49so1241448a12.1
 for <xen-devel@lists.xenproject.org>; Thu, 30 Jan 2025 05:24: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
 4fb4d7f45d1cf-5dc723d0c1csm1071079a12.8.2025.01.30.05.24.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 30 Jan 2025 05:24:21 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 84526289-df0d-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738243461; x=1738848261; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Vf5QowOgE0E3B/jKk8i3RWRVtqetY2O6THo3Hensm0I=;
        b=LYinb8F0022EV7maD7qhLqfKy84bqis6Hir44ebsuUk6BXYzvhCmmpLy1TN6AE9KkB
         Pyt0BmAuV0QJFi25rSdabSOkkJPS/+IYxSxXZ4kle17rLaDc+sv7QwQajyesugEJfsME
         w2LeJHZK6W243Ga8nqY8hI2z993jQRj77ZoAwYtWsPQ/ApjxODCnvLasuNrVu6Z85tGj
         Q7husEZ/CS0BV+GfyQpYZaEOSTcNqZ191Ehwt0vFTrgYlyqge2w+HlZNYXk0K8xcx0nG
         WRwRVWv5jGhL7LvUTJrL4OJMjNVQGlhgoiCZ//p/sAY/9eylpu3us24XpxJCdIwUu42n
         uFpw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738243461; x=1738848261;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Vf5QowOgE0E3B/jKk8i3RWRVtqetY2O6THo3Hensm0I=;
        b=EcHzrGhIFB0WZf74fKQdFxpYw8FL1Z6LPRydOts0eVeZ6mA21HaFodniKpprlAtPsK
         d8UkaY2H+gGfoE2J+PC9zVxvLgfxw5DQSpCyCa6d1XyzqW/5lmb/icol2ERiHlSi0DbV
         ebU+WeXrsGFLPg3f2ufqkUgXExhrvZ2YW7PGdoRg/fRGqneFynoXWrhtkUoTGFboggQa
         pHcJwiZXTNULIJGFl4ZrjP4uW4N4N2XMHx8wnI+baWCUPO+u/S9giZ1PAjMsID7nHvbk
         M8VP0D+rnLPjZZ4iI2sQH0lJaMIiUqVCRmz3awlySqGda2qoAOZFQC7VpyJpQxpzZ761
         zIFQ==
X-Forwarded-Encrypted: i=1; AJvYcCUBcxwFzOpBwjDrG0bSCeoekbB+5CVvya1KYzI1Q2lYMCZScuDNAJLaqemE57cikE/ce7cUyv3hEx4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzIqMG4YNt1L007PV9y/I+oMdnBKwzPKxSX0GiFAH8uPb4XMEfu
	I/B2+8FVoIkq+/smrssPm8Tvf1Mf+BX1RqxDOAKshgjELktVkzhfmW+EWHQeVA==
X-Gm-Gg: ASbGnctl2S6R3YV0aBU3+9qZcItWnw4RKnPfFaBl+tD+wBJ6PXaYH+FIxetlL1jowDE
	SVcCkgNGHXDDijx2tOlShwurBpfobZT19su37KWAz8k4qVA8BwwWhIOpCSE73q/cqf+C86SGKTb
	s9XhBpjQi/jrf6AoGPtZ2omX+ZTiWUI5a+rKLhjpHpGhTvc75Gy+rXUuWRYeeZFla6mXbmQlVg3
	gqzJqQkvg3OWSLvB4fx5y5w1WezB7gyzUkG5IKOxYUh9BlsgOURJEDj0eudcf1B3U0bPzkIF2bq
	avQHJvZIjS9vxOepEO2VB9zD/Cqj5zNDxt445KNByNPsshgd7icLD0jVk6B9g0WIxSp3Y1yljog
	t
X-Google-Smtp-Source: AGHT+IFHavudSc7NX3QVay8UspMjCts8HZ3DrR5/IWfa3s284RXeHWhRn3rt+NmJy++jlBHEJxfopA==
X-Received: by 2002:a05:6402:42cc:b0:5dc:1273:63fd with SMTP id 4fb4d7f45d1cf-5dc5efec154mr6507887a12.20.1738243461437;
        Thu, 30 Jan 2025 05:24:21 -0800 (PST)
Message-ID: <c74d334e-6e33-4a58-bf94-936249244cb0@suse.com>
Date: Thu, 30 Jan 2025 14:24:19 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/4] xen: kconfig: rename MEM_ACCESS -> VM_EVENT
To: Sergiy Kibrik <Sergiy_Kibrik@epam.com>,
 Tamas K Lengyel <tamas@tklengyel.com>
Cc: Julien Grall <julien@xen.org>, Bertrand Marquis
 <bertrand.marquis@arm.com>, Michal Orzel <michal.orzel@amd.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Alexandru Isaila <aisaila@bitdefender.com>,
 Petre Pircalabu <ppircalabu@bitdefender.com>,
 Shawn Anastasio <sanastasio@raptorengineering.com>,
 Alistair Francis <alistair.francis@wdc.com>,
 Bob Eshleman <bobbyeshleman@gmail.com>, Connor Davis
 <connojdavis@gmail.com>, Oleksii Kurochko <oleksii.kurochko@gmail.com>,
 "Daniel P. Smith" <dpsmith@apertussolutions.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1737452864.git.Sergiy_Kibrik@epam.com>
 <ff22f35dafd04b16165e1caec038e5a5fcf2aeee.1737452864.git.Sergiy_Kibrik@epam.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <ff22f35dafd04b16165e1caec038e5a5fcf2aeee.1737452864.git.Sergiy_Kibrik@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 21.01.2025 11:19, Sergiy Kibrik wrote:
> Use more generic CONFIG_VM_EVENT name throughout Xen code instead of
> CONFIG_MEM_ACCESS. This reflects the fact that vm_event is a higher level
> feature, with mem_access & monitor depending on it.
> 
> Suggested-by: Jan Beulich <jbeulich@suse.com>

I don't think this is applicable; my suggestion went in a different direction.

> Suggested-by: Tamas K Lengyel <tamas@tklengyel.com>
> Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>

Before considering to ack this, I'd like you, Tamas, to confirm this is really
what you had thought of. In particular ...

> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -37,7 +37,7 @@ obj-y += irq.o
>  obj-y += kernel.init.o
>  obj-$(CONFIG_LIVEPATCH) += livepatch.o
>  obj-$(CONFIG_LLC_COLORING) += llc-coloring.o
> -obj-$(CONFIG_MEM_ACCESS) += mem_access.o
> +obj-$(CONFIG_VM_EVENT) += mem_access.o

... changes like this one look somewhat odd to me.

> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -92,7 +92,7 @@ config HAS_VMAP
>  config MEM_ACCESS_ALWAYS_ON
>  	bool
>  
> -config MEM_ACCESS
> +config VM_EVENT
>  	def_bool MEM_ACCESS_ALWAYS_ON
>  	prompt "Memory Access and VM events" if !MEM_ACCESS_ALWAYS_ON
>  	depends on HVM

What about MEM_ACCESS_ALWAYS_ON (visible in patch context)? Shouldn't that
become VM_EVENT_ALWAYS_ON then, too?

Further, what about MEM_PAGING and MEM_SHARING? Shouldn't those, at least
documentation purposes, then also gain a dependency on VM_EVENT?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 30 13:27:00 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Jan 2025 13:27:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879566.1289772 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdUZO-0008RX-Qg; Thu, 30 Jan 2025 13:26:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879566.1289772; Thu, 30 Jan 2025 13:26:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdUZO-0008RQ-M3; Thu, 30 Jan 2025 13:26:58 +0000
Received: by outflank-mailman (input) for mailman id 879566;
 Thu, 30 Jan 2025 13:26:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=zr8Z=UW=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tdUZN-0008RK-Dm
 for xen-devel@lists.xenproject.org; Thu, 30 Jan 2025 13:26:57 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id dfcf1d43-df0d-11ef-99a4-01e77a169b0f;
 Thu, 30 Jan 2025 14:26:55 +0100 (CET)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-ab68d900c01so149425166b.0
 for <xen-devel@lists.xenproject.org>; Thu, 30 Jan 2025 05:26: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
 a640c23a62f3a-ab6e47f1d82sm118391166b.84.2025.01.30.05.26.53
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 30 Jan 2025 05:26:54 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: dfcf1d43-df0d-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738243615; x=1738848415; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=6aCxvRY+6Ki+8WSIgd9W/FxeozYzgX8mNfdrBuzYoUI=;
        b=YWyvLi9+fVqh9TJu0DlZ904PlAnWU1JgVYoSVMWS0+AGh9P1uI3p0i1AhkfJWLNO6Z
         39q92h9PrIZJbjk575pNnQCcrM+SjXU5BdF121brsHDu49orfpkBw+H4ZMlPpyohlp3o
         ujzCHQxJF2hEwIBH9fHFKvo5JHzKWFtPZ1aTqVcuYjfNuvizk2nUWmjkhkJ2JE3SX7cI
         bq2a8x7ZZeRUdvEiXxn5aOPBkSy1nn4wgJ8cuUzlpRtBeITHerneRu+hFRMU/PJ7puTD
         oS/jdFrEeXARoiLtv2czA30tlkFtzWiAbgS8KAy6BGNX9+W4Kh1FUp6d3OpXuzrfNf0W
         2A0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738243615; x=1738848415;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=6aCxvRY+6Ki+8WSIgd9W/FxeozYzgX8mNfdrBuzYoUI=;
        b=P/i4wz9hqHjLNVKePfceOvDJc8d3gaG5cB9X1nhaCvCztp0gnpkhq3PqVFMEKjMXyu
         FLpnOBlclpV2DrdACiS/8I7nNObSRU0Z+fd3AqJWiq5cKDpbD0CmFChKd+UWgKcX7B6T
         6EUhu7dKOMaCfR5mdr/lGwrkK2gzBvbWqiH6V2sCIWhVaECSts6IiKlJKMPVXN3tLTAs
         EntQyV4lpw7QOh8f/7GR7uyE2eY161zIttaFldmbp8c7vwcXC44h4rf1GGhKEu3Ic6I0
         /6DLTKaL8xeum1F1y/JJyRj2iJ1zMBPK2rbMB2xA4uzJLgnmBmhuzJ07GV9RW0BL2G4f
         BI0w==
X-Forwarded-Encrypted: i=1; AJvYcCU92kBjQyC504KbuYbSRqXIA7ozNmpm+K6LHKmeFwGrV7jinSw34kg85Qbto7a2LbIyUYzBW9HRgHc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzmLUsnP5rSoQrXx70b6gv2t0v0fd1vUnNu+t9THBNqZeu6Mfmz
	l5Lrcl/P/8h2KejaGpvWt2u/SPMAyUTFjPbQ0gW6rQBC5IKSpwljI95sd3kXjA==
X-Gm-Gg: ASbGnctR/JN6BdUWRFXM40A/1BcXBcaWGRqv8k9UOxp2eYBsepa7AQU0gdMlEUA9Y5V
	xT6Y3HApG2cHl1C4aVpkhSJ2ihgoVPdZQSeF6i+R+9lPx4YF8WpLmSCarskVhXOQ8lcKotzIEkl
	R83mZJTdldLDHk47osdPL/AwPPxaAZ53EhKNdL77eOLsfniOoKPsEn3PkrCF6fQ7FmsevAFxY7g
	fOtPsZoTlWhHLE9pkTC7R8wn2BJ/umg2oHNCFv0fUL/D2sDy1EcNMRrqN4K9BGaHsVHZw5H04TF
	XXgTP65YSK6bjNZfeulJqAjF7Kh8IwJVlV+VOUJvb8HJFyEVvskRhpg5YBgV+LH5qIkKMQB7AzZ
	9
X-Google-Smtp-Source: AGHT+IFDK8QoP1TAn8CfLD3B13Q2irPlmZB+HW3FlA0YH8kNsQJNv1dU5kriIUUiBZo/qhbo/tx7iw==
X-Received: by 2002:a17:907:1c0b:b0:ab6:e04e:b29 with SMTP id a640c23a62f3a-ab6e0bb4a12mr266541166b.3.1738243614988;
        Thu, 30 Jan 2025 05:26:54 -0800 (PST)
Message-ID: <e3be3cb3-4a2e-4a39-8c83-f23e56cc7b75@suse.com>
Date: Thu, 30 Jan 2025 14:26:53 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/4] xen: kconfig: rename MEM_ACCESS -> VM_EVENT
To: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
Cc: Julien Grall <julien@xen.org>, Bertrand Marquis
 <bertrand.marquis@arm.com>, Michal Orzel <michal.orzel@amd.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Tamas K Lengyel <tamas@tklengyel.com>,
 Alexandru Isaila <aisaila@bitdefender.com>,
 Petre Pircalabu <ppircalabu@bitdefender.com>,
 Shawn Anastasio <sanastasio@raptorengineering.com>,
 Alistair Francis <alistair.francis@wdc.com>,
 Bob Eshleman <bobbyeshleman@gmail.com>, Connor Davis
 <connojdavis@gmail.com>, Oleksii Kurochko <oleksii.kurochko@gmail.com>,
 "Daniel P. Smith" <dpsmith@apertussolutions.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1737452864.git.Sergiy_Kibrik@epam.com>
 <ff22f35dafd04b16165e1caec038e5a5fcf2aeee.1737452864.git.Sergiy_Kibrik@epam.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <ff22f35dafd04b16165e1caec038e5a5fcf2aeee.1737452864.git.Sergiy_Kibrik@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 21.01.2025 11:19, Sergiy Kibrik wrote:
> @@ -58,7 +58,7 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned long flag,
>      return NULL;
>  }
>  
> -#endif /*CONFIG_MEM_ACCESS*/
> +#endif /*CONFIG_VM_EVENT*/

Oh, also - as you touch this anyway: Would you mind adding the mising blanks,
just like we have them ...

>  #endif /* _ASM_ARM_MEM_ACCESS_H */

... on the immediately following line?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 30 13:27:51 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Jan 2025 13:27:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879573.1289780 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdUaF-0000Ur-14; Thu, 30 Jan 2025 13:27:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879573.1289780; Thu, 30 Jan 2025 13:27:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdUaE-0000Uk-Ul; Thu, 30 Jan 2025 13:27:50 +0000
Received: by outflank-mailman (input) for mailman id 879573;
 Thu, 30 Jan 2025 13:27: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 <SRS0=zr8Z=UW=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tdUaE-0000Ua-3U
 for xen-devel@lists.xenproject.org; Thu, 30 Jan 2025 13:27:50 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ffdbfbf5-df0d-11ef-a0e6-8be0dac302b0;
 Thu, 30 Jan 2025 14:27:49 +0100 (CET)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-aa684b6d9c7so144421066b.2
 for <xen-devel@lists.xenproject.org>; Thu, 30 Jan 2025 05:27:49 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab6ee76b8fcsm54222266b.137.2025.01.30.05.27.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 30 Jan 2025 05:27:48 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ffdbfbf5-df0d-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738243669; x=1738848469; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=1uxPaAwc9ZrWb1DbjPqvZUMoPMtg0HkW/cwKFCiK668=;
        b=gLuUwYoaG8MePauCzk3wVmU9uIeAy7Amx9YhcLxAUBNOcEj+q9BxOoOOvm0GEH0ZIp
         S+kN4VHOU4ltXXV5e6RSMj/E0KKNU6fQy7Lbaza3WAZ2o1mQ3W1TkVAXRsGVzv3rxVM3
         FAzogxNh/Ez8M6fhOc1E8NQu4VsUr54LCE7gG8PkqP988WGA+vKy0mVpE5wGwAJ10qE+
         SAVMh/+c1KGjfUZq+hOI8zJvJLLCYIhLYOVDLwzVroDj1FLnjtSPc32WFfBaLb/tzee5
         vE5cH020VuaOq9OnX8Z0dt2U5fT19Uq48QVnX8cnk3lIoxOh0WHk2SdcNYb7WbAUlA6t
         8BaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738243669; x=1738848469;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=1uxPaAwc9ZrWb1DbjPqvZUMoPMtg0HkW/cwKFCiK668=;
        b=cOz+RAEvLzN/cZ0Rh4eNsBra2OyXFeOqWDQj4Kl7OpInPfh+cJJSALsiPcak1UyKfC
         lpDdkRp7PyzawIZZb5pFSCejA5PjPaUHLUfdBSWwNUtChZA69VYMy4qt4qtxODoL9KmR
         rfzLFmXhppitR9ZyMDKHZ4MAWjX/bnm8ivhOQRQVm+2P7z0cNMYPglikb4W3DSq+aZQA
         3a13M5utOsn4ZLeMtVTeNOznZlr3sw0ZvsVtZKH9KU2REOa4GKyaORPTzeYl/1QHKZ77
         fYuV/hKK5eiMtC4OPkP2xDGP9P7NFgCaubgvYO8ej762DqKAlRcCCmzCyW+0CoY1TNhv
         b1ew==
X-Forwarded-Encrypted: i=1; AJvYcCUepUIMglu0tmNroSAO3JOagj72Dg/Bacy3ZjaZAHe1GswJPev/n94SIdXVRXG/gJBWA/4yvw0Vm/Q=@lists.xenproject.org
X-Gm-Message-State: AOJu0YygtrdxpWA/n8dm++Uk9XZogioA7WBXHchf52rxZAI5A0vJnh4U
	eJ1W3W0rdQkRQJ81syZkDvm4EMAzcTHkxNChRUrEGohkDYH7cl7ghxjW57fU1Q==
X-Gm-Gg: ASbGncvyCBcq9BNgxFhBfB1r22IJMAu5WZsflxSYIdRJMq8piFutqhW1f5tdJHp9Rbp
	YTgJD5DYvPjjJpiR5CSYoB9gctuSNYJrMeAZW9m8pnYz7HOUID2e98lFJUe1dZPSbVW3JT4qVCb
	KM2qY948ypiESWhfK0vZX+wbGZkHq+/2ZMzYlgCwJQg3md0g3rw+RiOfyN9sHIz9HlqmLl1sZAP
	aJIUsVuBKAKjbB/+zxFzNrKtP35uyWE5h3KFLbri4h0lVKEqTuVwzpXTZGbe8gDxokkPdkjpJWR
	JrmqEag9aJfcn1L9CfcBFfUfLLMk/xVZlX0a2jD8urORUQj2YCfcwv2pYk0yhSiN+Eq/oej1CXE
	C
X-Google-Smtp-Source: AGHT+IFhBW831LnaAmp1wPj9V9YfM7/Y6hS9iFB03C08+7Z/6Ha7QD5UiGKJEw7+2eBZnomgTvCHfg==
X-Received: by 2002:a17:906:4fc7:b0:aab:92bd:1a8f with SMTP id a640c23a62f3a-ab6cfd0839fmr625811966b.26.1738243668792;
        Thu, 30 Jan 2025 05:27:48 -0800 (PST)
Message-ID: <c0a9c3fa-1812-4a7f-9508-aa109c3221d7@suse.com>
Date: Thu, 30 Jan 2025 14:27:47 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/4] x86:monitor: control monitor.c build with
 CONFIG_VM_EVENT option
To: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1737452864.git.Sergiy_Kibrik@epam.com>
 <6fe254034570e1443a41c7dc5e3e3767b9c77f79.1737452864.git.Sergiy_Kibrik@epam.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <6fe254034570e1443a41c7dc5e3e3767b9c77f79.1737452864.git.Sergiy_Kibrik@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 21.01.2025 11:21, Sergiy Kibrik wrote:
> Replace more general CONFIG_HVM option with CONFIG_VM_EVENT which is more
> relevant and specific to monitoring. This is only to clarify at build level
> to which subsystem this file belongs.
> 
> No functional change here, as VM_EVENT depends on HVM.
> 
> Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>

As long as patch 1 stays roughly as it is right now:
Acked-by: Jan Beulich <jbeulich@suse.com>

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 30 13:32:25 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Jan 2025 13:32:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879583.1289790 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdUeb-0002SO-HV; Thu, 30 Jan 2025 13:32:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879583.1289790; Thu, 30 Jan 2025 13:32:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdUeb-0002SH-Ei; Thu, 30 Jan 2025 13:32:21 +0000
Received: by outflank-mailman (input) for mailman id 879583;
 Thu, 30 Jan 2025 13:32:20 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=zr8Z=UW=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tdUea-0002S9-BR
 for xen-devel@lists.xenproject.org; Thu, 30 Jan 2025 13:32:20 +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 a0c0dfb6-df0e-11ef-a0e6-8be0dac302b0;
 Thu, 30 Jan 2025 14:32:19 +0100 (CET)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-5d3e6274015so1298551a12.0
 for <xen-devel@lists.xenproject.org>; Thu, 30 Jan 2025 05:32:19 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab6e47a7be3sm120263666b.20.2025.01.30.05.32.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 30 Jan 2025 05:32:18 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a0c0dfb6-df0e-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738243939; x=1738848739; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ruyuqJjalDkjl6hlRXlmkNz29+c8c580J8tI4J9c7z4=;
        b=DdYs9vjoDdXthh0uePoT+DszpLK1Sif+6poDzGpOx2nxbm4pFXfoy/DnuG6+azx1IB
         lgUDNnK0qnWfqZSI5WsVLXKh7164nyu0gXFqOrqLD0EWvmrodRBCiztD/RQJYjdQ1iPc
         tIeezdIlkmRgzGW7m7BlD+kWwY80AsIf8MVLRJsOyrcNrOWCz2ekHvm7L4UCdA1BDmGH
         6TMmJ2SF6mRgui5O15XOSt++q2W8HuoTMLnN4/Z6xNj5OkzF/VT0/k8j6N6azBocSZiV
         uByn75B+fk+r4CEpdWiZI7EvCERA2Q/5Q3K8M7c9gYWluiteWRom2I/7UfL1CXAOb+fX
         /Dng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738243939; x=1738848739;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ruyuqJjalDkjl6hlRXlmkNz29+c8c580J8tI4J9c7z4=;
        b=MF/NP7HqkhvOFEitHe3goDqVMmETDaI0M0G6sb3mTNFmi+ao1QyR7KL25i2nbsY1X1
         x/UIfwa8Wsno933y3fMtTWqWAII1Qnl+P/RV0UQWGqCKmy4ZXHk6B/9l4Yl77N7GpXyu
         lsgeA/BK5aSn3RrD8DqmnhjtgWPV4Og5obIuFzHolK3ruXt+UIvTwF8YCF9tcZ/WMvdb
         67J/bE3wTDEkTrpQW5qvw/DASjnz5tV2kQJAXGLqj+vXrdWLEF9zmUdJdzux846ArYQH
         cSYK2thdlIDiQetZa4wXlsGUZbauRHgzYEVfwQO6evQ31+0F6+4HOHeWGQ4t85SZfJyB
         ADKw==
X-Forwarded-Encrypted: i=1; AJvYcCUiP3rvGKyNOjh1fb7OxDxTRN1J2d18daOFii5B/ZU7h3+03Gqc/PPZRDKShmz1ixNZlEdfetDhxrU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzaZnYJJvaJiyLl/GshrH6TzFZ6J0JJn+9NQ+cFdrdMzJi40y9j
	p7iHhRTjpVG1sIY7TSa1y1QZPDy8X6ZFvB8fOoDOKZqms9qGeFq4JKEjBGYxkQ==
X-Gm-Gg: ASbGncv4IJtOJRA5kZ4X1q3O44ozACEzZAGpQWs/zWJTFws4fonKyId3JoEJU4B4wgA
	+Mbm+CBwe2pGbC6VrQXWxdbgeEfXJuIDtd4GRfPQ1aQ0TATgW2f4JpMLrlCqysBLBz8ObKdO6NJ
	4PLN4G+f9rth4djI9hxWL6UulbKJqp8NiM3QM0SK50GJqfuui/OhCRg/QqCmEkVjfOGhoeZO6xg
	dp363U8dLBrzTfzX53EnSnCJtSJ0lMpxSt6t9KiqFgeRndPBuPOqJkA3WKXH7gAj6hHaVdEH+qK
	gN6JdPfXwWuMh8+GmRP/fYbYij3w8Ts/sd6IjUYq9FejX9HthX4D2HnnOIQbetXuPzP4cVBVyeG
	z
X-Google-Smtp-Source: AGHT+IE8hObwgNh2m8R9dhRmSvp3BkfubjzlkN4r8VjjmS46oOXPOSursUkLwnY7nIav0K9KrFUzqQ==
X-Received: by 2002:a17:906:9c85:b0:ab6:60b5:eaa2 with SMTP id a640c23a62f3a-ab6cfcc6ee9mr505425266b.22.1738243938677;
        Thu, 30 Jan 2025 05:32:18 -0800 (PST)
Message-ID: <56231f2c-d57e-423c-b4bd-19d06aeda6ec@suse.com>
Date: Thu, 30 Jan 2025 14:32:17 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 4/4] xen: mem_access: conditionally compile vm_event.c
 & monitor.c
To: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
Cc: Stefano Stabellini <stefano.stabellini@amd.com>,
 Julien Grall <julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Alexandru Isaila <aisaila@bitdefender.com>,
 Petre Pircalabu <ppircalabu@bitdefender.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Tamas K Lengyel <tamas@tklengyel.com>,
 Ayan Kumar Halder <ayan.kumar.halder@amd.com>, xen-devel@lists.xenproject.org
References: <cover.1737452864.git.Sergiy_Kibrik@epam.com>
 <2e8b9c5390019ef66610a21d9a8744282e2badeb.1737452864.git.Sergiy_Kibrik@epam.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <2e8b9c5390019ef66610a21d9a8744282e2badeb.1737452864.git.Sergiy_Kibrik@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 21.01.2025 11:25, Sergiy Kibrik wrote:
> --- a/xen/include/xen/monitor.h
> +++ b/xen/include/xen/monitor.h
> @@ -27,8 +27,17 @@
>  struct domain;
>  struct xen_domctl_monitor_op;
>  
> +#ifdef CONFIG_VM_EVENT
>  int monitor_domctl(struct domain *d, struct xen_domctl_monitor_op *mop);
>  void monitor_guest_request(void);
> +#else
> +static inline int monitor_domctl(struct domain *d,
> +                                 struct xen_domctl_monitor_op *mop)
> +{
> +    return -EINVAL;

EOPNOTSUPP perhaps?

Otherwise looks okay to me, but first and foremost requires Arm side approval.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 30 13:45:39 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Jan 2025 13:45:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879590.1289800 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdUrH-0004UJ-L5; Thu, 30 Jan 2025 13:45:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879590.1289800; Thu, 30 Jan 2025 13:45:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdUrH-0004UC-IE; Thu, 30 Jan 2025 13:45:27 +0000
Received: by outflank-mailman (input) for mailman id 879590;
 Thu, 30 Jan 2025 13:45:26 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=zr8Z=UW=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tdUrG-0004U6-Q2
 for xen-devel@lists.xenproject.org; Thu, 30 Jan 2025 13:45:26 +0000
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
 [2a00:1450:4864:20::531])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 757d8da6-df10-11ef-a0e6-8be0dac302b0;
 Thu, 30 Jan 2025 14:45:25 +0100 (CET)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-5d96944401dso1371204a12.0
 for <xen-devel@lists.xenproject.org>; Thu, 30 Jan 2025 05:45:25 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5dc724045e5sm1100802a12.37.2025.01.30.05.45.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 30 Jan 2025 05:45:24 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 757d8da6-df10-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738244725; x=1738849525; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=dDs+c5r+1qJQcbILWROriYzFnh4iRG1G/YVXdd/RsZA=;
        b=hEViOhYHV531DuG1PvFlp9oVQgzU+BoR4PayEfWfej4KmlNcvgMU95f9LXKzdRGzAr
         L1SBh5P/GQ2eVyedB/yCIMsIrwfLdtelsOalaMRbGGyn9628yUqnA1Rcs1nYUQzVhp4m
         2AvrGYqt9t6OlGseh8A2p5n094Bu6erWQAzZUwre09FY/3LucDG9tiVsunzZ355G1PZM
         Au2u+Os0cQZc1hB/sZLg2XWle43prKpZ+dUALTSJhN1YqGwqnGfk9aB/gM+RTXChcac4
         VyXZnlr43nfgdfqFinbJTpb63BNwW7+29va2Y1x0r4DbavUqeq7KgldktqO309s4ySum
         03Fw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738244725; x=1738849525;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=dDs+c5r+1qJQcbILWROriYzFnh4iRG1G/YVXdd/RsZA=;
        b=OoPKj9vrRoXPlh4CZG0f1Ep016gduV3ibaakddxbof2V98jlaEtbpwOycfH+EFQBaq
         Ibv5tu0XpMs3uis6aEknmJHSifJxPi8e4p7VHQl51bMf3IY567DXb/i4Zonq28KAPXX1
         Nfb4fZo3FGri6BVcHlG+yk8fDctxBuKFvyOzwGBf9gSvMGIS9ugDBjEGK7SG3UGR6e9X
         JAHpgGfFYst6Vb4DCREwIO+5Pwm/kgqDzhOtR2+r+yypzuLRqYBONPikuP/YRzeKZZdO
         jIA8lJfM+aCWp5ThXbAHEexh+DDyXw2SuoiqsCJzgt/Nr3655GwKu+PiSkNanw23yCNr
         U1zA==
X-Forwarded-Encrypted: i=1; AJvYcCU5JOmanFXvVV8Jo74yUsUulxKvTtJhYv7xObUKLzndlBPQ6OM+5fzhcRea12/goa9CD3nJmFKJunY=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw/OcuRlU2F3depvOMdw7WqIYNYBA2k8y5X6QVMt7qq09TohDNY
	KVPrUMbTukcND1qFqghJMAYmPi8TY3h9vOnzNDX2buo1qVa5jvVvcCLUpWWYfg==
X-Gm-Gg: ASbGncu+MetbCc9LUVYHTbv8QWgJf61LIA5QGNMko0s7PnaVqsii80vQQEStXGICjh4
	r/eZwwg7dLfVEiKFj9rSOhqc8IHPm0T/ZxYSZ/hxo+a5TkJmQFiaaBiH8o9SjC2OrhO8OSfl3Lo
	yn6cAoNwp+KqeJ4duFOsD+MBtYMLxbQMiV+i+Kg9bKZoKbAs2CW75qvmQ+PUxqNjD7Y3NdfxIRA
	LHf+PUy64Q73YJ/OGxcIKQNEiJrn1V0XNYZROJ265Teeo7KSuT4pm5CEGiKDnu93+Yw2hwFdQTK
	CtUPq86XRvTp11dCADcya+BQ7rkOR+n3w5LGxNi8hsKxJuTWgpQhC62Zs0j4X1PVm5UIZHNtpSX
	b
X-Google-Smtp-Source: AGHT+IGptZ5pGgjW8lLTJvqpZ+K8U4xsJHcPkZ+zmOvXk4Fmf2l6+/tLA41IxZATvgot7gU5CYQe9A==
X-Received: by 2002:a05:6402:1ec9:b0:5d0:e410:468b with SMTP id 4fb4d7f45d1cf-5dc5efa8adamr6274258a12.2.1738244725159;
        Thu, 30 Jan 2025 05:45:25 -0800 (PST)
Message-ID: <2e02b7d6-fe71-4ed8-a09d-5bde7438718c@suse.com>
Date: Thu, 30 Jan 2025 14:45:24 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 01/15] x86/boot: introduce boot domain
To: "Daniel P. Smith" <dpsmith@apertussolutions.com>
Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com,
 stefano.stabellini@amd.com, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
 <20241226165740.29812-2-dpsmith@apertussolutions.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20241226165740.29812-2-dpsmith@apertussolutions.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 26.12.2024 17:57, Daniel P. Smith wrote:
> @@ -596,9 +597,10 @@ int __init dom0_setup_permissions(struct domain *d)
>      return rc;
>  }
>  
> -int __init construct_dom0(struct boot_info *bi, struct domain *d)
> +int __init construct_dom0(struct boot_domain *bd)

Pointer-to-const? Domain construction should only be consuming data
supplied, I expect.

> --- /dev/null
> +++ b/xen/arch/x86/include/asm/bootdomain.h

Maybe boot-domain.h? Or was that suggested before and discarded for
whatever reason?

> @@ -0,0 +1,28 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * Copyright (c) 2024 Apertus Solutions, LLC
> + * Author: Daniel P. Smith <dpsmith@apertussolutions.com>
> + * Copyright (c) 2024 Christopher Clark <christopher.w.clark@gmail.com>
> + */
> +
> +#ifndef __XEN_X86_BOOTDOMAIN_H__
> +#define __XEN_X86_BOOTDOMAIN_H__
> +
> +struct boot_domain {
> +    struct boot_module *kernel;
> +    struct boot_module *ramdisk;

"ramdisk" is Linux-centric, I think. Can we name this more generically?
"module" perhaps, despite it then being the same name as we use for the
modules Xen is passed?

Also, are consumers of this struct supposed to be able to modify what
the pointers point to? I'd expect they aren't, in which case const will
want adding here, too.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 30 13:51:53 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Jan 2025 13:51:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879600.1289816 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdUxR-0006UR-AL; Thu, 30 Jan 2025 13:51:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879600.1289816; Thu, 30 Jan 2025 13:51:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdUxR-0006UK-7U; Thu, 30 Jan 2025 13:51:49 +0000
Received: by outflank-mailman (input) for mailman id 879600;
 Thu, 30 Jan 2025 13:51: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 <SRS0=zr8Z=UW=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tdUxQ-0006UE-36
 for xen-devel@lists.xenproject.org; Thu, 30 Jan 2025 13:51:48 +0000
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com
 [2a00:1450:4864:20::636])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 58eab81e-df11-11ef-a0e6-8be0dac302b0;
 Thu, 30 Jan 2025 14:51:47 +0100 (CET)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-aaecf50578eso172796266b.2
 for <xen-devel@lists.xenproject.org>; Thu, 30 Jan 2025 05:51:47 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5dc723e4c8esm1112425a12.23.2025.01.30.05.51.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 30 Jan 2025 05:51:46 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 58eab81e-df11-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738245107; x=1738849907; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=4j26GBKFhejBkGSKMpktjiN6fvhII4e5qr1SdkqYS14=;
        b=VdQbXuc39uTbq7kTGOO75jbM0P+ylU23HXE+OxMKAgY1T+ugD7H1ntIs/Jv6GKHqMN
         cttCUB4heZxbdCk9Sai0S743Uv31ZnEr/NFFASwBYiV0ZNJKbTG+89KzengCwPFMe0lW
         NmgnKLfyqvGq0yusIvqAtbyiTCbH1c1CFo/AtIQ7X+66cIy06ysTfky0cwGvU8R3aXmt
         sLlJitkZUViQqCsxKGjLGvPrl8Y/mc9znyhELsGt6XyWfJooXAgU72iCHQk22XyVS5oF
         wd6vsbTtogvpGfziXce0baBeMH0r+uAEc11IoiE1ngyBdA5GCKRxhqLQJJVrbRRqAxZE
         1egg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738245107; x=1738849907;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=4j26GBKFhejBkGSKMpktjiN6fvhII4e5qr1SdkqYS14=;
        b=FYtjj9/oTSuKAZotTrkfHn1GuEZV+NlZQaOgnxFOrAxoDZ0VUWujXjkbgQghUC2tFZ
         WyLyfiNXY/oZsTHLMWVrUdJafgZY5JjbhGz2K9JUPWSvAx98LiQJu1piO8loutqEbk2x
         gUO7VZ1dBgrwKshmlqjvk4xYNpHR1glNMTthKhNYsA+EX5LURryRJZNI8VY4EXXb1fna
         6uzKEGn8lQVSqKk/ciMarqrzdl+VOa42oy2BW1vpI86FJVNaCV/EPjUAKrdK4Ev9cyUN
         xwkFmGoWQJgdaP+/GjauheXq0Jq0C43sJmLQ7KgUav4mRZJ3YQGYYkGN8LlveL+5rxNl
         Y9zg==
X-Forwarded-Encrypted: i=1; AJvYcCW7ORt/Lj/ALrHSgN4+72fupcL9wgwE63+E/RHSQdKtzPhkWET06rWlQUui1zXKWfp2NsY4Lwf7wnk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwSJYoVi8bm/+H1TTWV1ArN5vEtNsf2T8syjzu3qOzlfYCw4CaW
	pdoEJ9Qp76u1rJam3LssaDUiuGaX+9cedtU4ZKe22jQwpjDZxxvpGhyjj4UY3w==
X-Gm-Gg: ASbGncsAr4WpolQftyCORasTvqME83dJDEhys1y2scHOeTPjSij7bi/S6iQxEz/MW90
	azYtnnq1PI7Ta5vtj08BbyiUahU8MS1OwHI/tqDE5S6/QWo+UxTK6oXCVAdzMNS4Xlq774k7Dhp
	E/hwK0y6qb1VVWFSrxnZxoObkWqh/KYC3DZR5LtcGeUVhoRpkz8vOq3W2vdAqGt/6Q8eemsu86j
	yChzbJZB7Q6w82UifJr4tG9VUt3iwEOupkEv8jZN4XL2vbX9rBf/25rWwtXGrtcmxvK1WgDsgxs
	yS3O6tWjcjiygc5wBUaZoNUdZvtnB9Uy6ilhzl4cX4HmuZKawPtNCxqzuKrENumQPh2hXM2VnVf
	x
X-Google-Smtp-Source: AGHT+IH6BqAuOJC1JhLDNCYwrZmwZadAiKHJGi/qqAKYlFCcCybNd5FVV6NSx6mGMMW9h5o/JcMeBA==
X-Received: by 2002:a17:907:7d93:b0:aae:c3c1:1361 with SMTP id a640c23a62f3a-ab6cfdd6b4fmr725392966b.44.1738245106645;
        Thu, 30 Jan 2025 05:51:46 -0800 (PST)
Message-ID: <61d5986f-bd52-4b00-87e1-49f9e6f7ed44@suse.com>
Date: Thu, 30 Jan 2025 14:51:45 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 02/15] x86/boot: introduce domid field to struct
 boot_domain
To: "Daniel P. Smith" <dpsmith@apertussolutions.com>
Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com,
 stefano.stabellini@amd.com, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
 <20241226165740.29812-3-dpsmith@apertussolutions.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20241226165740.29812-3-dpsmith@apertussolutions.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 26.12.2024 17:57, Daniel P. Smith wrote:
> Add a domid field to struct boot_domain to hold the assigned domain id for the
> domain. During initialization, ensure all instances of struct boot_domain have
> the invalid domid to ensure that the domid must be set either by convention or
> configuration.

I'm still missing justification for the duplication between the struct domain *
that's already in struct boot_domain and this new member. Iirc you responded to
this earlier question of mine, but nothing was put here.

> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -292,6 +292,7 @@ static const char *cmdline_cook(const char *p, const char *loader_name);
>  struct boot_info __initdata xen_boot_info = {
>      .loader = "unknown",
>      .cmdline = "",
> +    .domains = { {.domid = DOMID_INVALID} },

Please can you fully use designated initializers here, thus also protecting
against MAX_NR_BOOTDOMS increasing without and update being done here (and
the compiler still being happy)?

    .domains = { [0 ... MAX_NR_BOOTDOMS - 1] = { .domid = DOMID_INVALID } },

Nit: Note also the blanks I added.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 30 14:15:24 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Jan 2025 14:15:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879611.1289825 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdVKC-0001iB-2x; Thu, 30 Jan 2025 14:15:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879611.1289825; Thu, 30 Jan 2025 14:15:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdVKC-0001i4-05; Thu, 30 Jan 2025 14:15:20 +0000
Received: by outflank-mailman (input) for mailman id 879611;
 Thu, 30 Jan 2025 14:15: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 <SRS0=zr8Z=UW=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tdVKA-0001hc-1M
 for xen-devel@lists.xenproject.org; Thu, 30 Jan 2025 14:15:18 +0000
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com
 [2a00:1450:4864:20::333])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a07391d6-df14-11ef-99a4-01e77a169b0f;
 Thu, 30 Jan 2025 15:15:15 +0100 (CET)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-436341f575fso9647165e9.1
 for <xen-devel@lists.xenproject.org>; Thu, 30 Jan 2025 06:15:15 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab6e47a7fd9sm127608866b.34.2025.01.30.06.15.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 30 Jan 2025 06:15:14 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: a07391d6-df14-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738246515; x=1738851315; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=727D/DkoH5Aywyiyi7Z0Y6u9UAsi8e29CsiZ5+y2AQQ=;
        b=Gj0nsLeA0+ti0W2dHduj4w8WJemwgzBTKHfHAh9SeSS3rm4kRuSbo2ler43cHGrVQV
         hxUCtxsCLDUN5QAkm571ZBmiQoDXwAoakbRKqnROAAFX07TD1ixdSQQEBQQHq6dyGsoG
         FpG7ODZQIpFTlw+8+ARSKaT93nexDFhwCHxUAHiu5s2BEV6E9joDOuXcmYx5SuJqbdr+
         sEJ1iSQY3yXHlcpI0w9bRNiLLR/NQetHOs+oJaHx1Kuooe4Mf06//3pt5B34VMtwljsg
         ZbkGiOtvR3FdAshFvPhtBdAK0ReGZ+qFo7BqrZ3pFUWbw0OZvXfvxnoNOotNXepHJq+a
         7mPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738246515; x=1738851315;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=727D/DkoH5Aywyiyi7Z0Y6u9UAsi8e29CsiZ5+y2AQQ=;
        b=Bs79TLkfNzjf7Mu+hOIWLNHj5ti16LPthHBP2iLJc4+cAod/Qn4H2mzM5HAksdBBA7
         AxEBkUlOCTqMFjo/PA98Ufrf8GLouwyOVieNovkYXV5XX6c3Fcmbw1Ayb8EpvhErWKxd
         /6KOV3ci4B8FDeNByLb6rNQyKfcvMQ/WGQdnmrqrWFXiZ9/+wK4QUXuojx9JwP8BwOTI
         jl9Oamr5r6lDYj00dhN4zB1nS8fB5f+BAzlGjW6UiV2XrskWJbHMhvY+n8TVbhD6S+Wh
         E8gmSYz/xgUduH+L/aI8NiFIgAC11HGU0lyDkYwgI2w5i9PvC6bVfgVHoNWAQ5lgAm05
         YgvA==
X-Forwarded-Encrypted: i=1; AJvYcCWxOKQwBPdE3sT4HSpnZgTtfvufd7kwU6v8tvD2QNQZxQw0rB1ghFLIwRiXzXjiWVtt5HPjbHGDHpM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YytT9W28ZP9t+4Zss4c3VdilUclUTDgWaQBfZkDeFy2hp7H35bl
	oe4WE95ZNXrjj7mapBIjeU06K2QjgZJZ6KDNsyHG0saFoHgTY5+GrMyyk7O/YQw5ewbcSwwkxUs
	=
X-Gm-Gg: ASbGncuVxaBK2mrIjN8opji5VXL6kHbMtlQl/iq4X1n4eBpIQAjOEqQPOwwFPtNn54W
	CJwK+kzffLRrWMJIEEvK0udcuq/M5hEaOK9Qr6Hmq+9DtvBOz1VU6q7LKGNqugNcp7OGg9b9oSi
	wWi6oQySfK5VthC09hnzgCwbU49IPUoeRNY8vC0KuET6QKufGstCsMYgSOvEc63qMzeqrO7z3f1
	Jp4Xbbww1BE/qWeqWcyhqW/iCzfDhifJV7e2/mostfWjrkBGjmmz+gqbBJ+S3VjUVbCjiTzEkN+
	fj832ens18/GbCp2XwBfRGU+RlZzZQqaO1RKdQq3eosWcvUSY18W6cBv4oXGJpl/Lc3X6fNtmZN
	V
X-Google-Smtp-Source: AGHT+IF3MDcjEx6HDfRoFPJ8fmeSpma+3suW0DJBdxl7Px92egDROwe7Wd8ZxZ4pszkBfsk9mQ0cVQ==
X-Received: by 2002:a05:6000:1548:b0:38c:3f12:64be with SMTP id ffacd0b85a97d-38c51f8a3camr8768835f8f.35.1738246515108;
        Thu, 30 Jan 2025 06:15:15 -0800 (PST)
Message-ID: <791f9f14-e329-4cc4-9065-cdb84b6907ce@suse.com>
Date: Thu, 30 Jan 2025 15:15:13 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 03/15] x86/boot: add cmdline to struct boot_domain
To: "Daniel P. Smith" <dpsmith@apertussolutions.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com,
 stefano.stabellini@amd.com, Andrew Cooper <andrew.cooper3@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
 <20241226165740.29812-4-dpsmith@apertussolutions.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20241226165740.29812-4-dpsmith@apertussolutions.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 26.12.2024 17:57, Daniel P. Smith wrote:
> @@ -759,9 +758,10 @@ static int __init pvh_load_kernel(
>      /* Free temporary buffers. */
>      free_boot_modules();
>  
> -    if ( cmdline != NULL )
> +    if ( bd->cmdline != NULL )
>      {
> -        rc = hvm_copy_to_guest_phys(last_addr, cmdline, strlen(cmdline) + 1, v);
> +        rc = hvm_copy_to_guest_phys(
> +                last_addr, bd->cmdline, strlen(bd->cmdline) + 1, v);

Nit: Indentation. The anchor point for this kind of increased indentation
is the function name being called, so you want to add one more blank. (It
is not N times the usual indentation of 4, until "it looks okay".)

> --- a/xen/arch/x86/include/asm/bootdomain.h
> +++ b/xen/arch/x86/include/asm/bootdomain.h
> @@ -11,6 +11,8 @@
>  #define __XEN_X86_BOOTDOMAIN_H__
>  
>  struct boot_domain {
> +    const char *cmdline;
> +
>      domid_t domid;
>  
>      struct boot_module *kernel;

I can see why in the earlier patch you added domid at the top. But cmdline?

> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -975,10 +975,29 @@ static unsigned int __init copy_bios_e820(struct e820entry *map, unsigned int li
>      return n;
>  }
>  
> -static struct domain *__init create_dom0(struct boot_info *bi)
> +static size_t __init domain_cmdline_size(
> +    struct boot_info *bi, struct boot_domain *bd)
>  {
> -    static char __initdata cmdline[MAX_GUEST_CMDLINE];
> +    size_t s = bi->kextra ? strlen(bi->kextra) : 0;
> +
> +    s += bd->kernel->cmdline_pa ? strlen(__va(bd->kernel->cmdline_pa)) : 0;
> +
> +    if ( s == 0 )
> +        return s;
> +
> +    /*
> +     * Certain parameters from the Xen command line may be added to the dom0
> +     * command line. Add additional space for the possible cases along with one
> +     * extra char to hold \0.
> +     */
> +    s += strlen(" noapic") + strlen(" acpi=") + sizeof(acpi_param) + 1;

See below; I question this all being necessary for PVH Dom0.

> @@ -1018,39 +1037,52 @@ static struct domain *__init create_dom0(struct boot_info *bi)
>          panic("Error creating d%uv0\n", bd->domid);
>  
>      /* Grab the DOM0 command line. */
> -    if ( bd->kernel->cmdline_pa || bi->kextra )
> +    if ( (bd->kernel->cmdline_pa &&
> +          ((char *)__va(bd->kernel->cmdline_pa))[0]) ||
> +         bi->kextra )
>      {
> -        if ( bd->kernel->cmdline_pa )
> -            safe_strcpy(cmdline,
> -                        cmdline_cook(__va(bd->kernel->cmdline_pa), bi->loader));
> +        size_t cmdline_size = domain_cmdline_size(bi, bd);
> +
> +        if ( cmdline_size )
> +        {
> +            if ( !(cmdline = xzalloc_array(char, cmdline_size)) )
> +                panic("Error allocating cmdline buffer for %pd\n", d);
>  
> -        if ( bi->kextra )
> -            /* kextra always includes exactly one leading space. */
> -            safe_strcat(cmdline, bi->kextra);
> +            if ( bd->kernel->cmdline_pa )
> +                strlcpy(cmdline,
> +                        cmdline_cook(__va(bd->kernel->cmdline_pa), bi->loader),
> +                        cmdline_size);
>  
> -        /* Append any extra parameters. */
> -        if ( skip_ioapic_setup && !strstr(cmdline, "noapic") )
> -            safe_strcat(cmdline, " noapic");
> +            if ( bi->kextra )
> +                /* kextra always includes exactly one leading space. */
> +                strlcat(cmdline, bi->kextra, cmdline_size);
>  
> -        if ( (strlen(acpi_param) == 0) && acpi_disabled )
> -        {
> -            printk("ACPI is disabled, notifying Domain 0 (acpi=off)\n");
> -            safe_strcpy(acpi_param, "off");
> -        }
> +            /* Append any extra parameters. */
> +            if ( skip_ioapic_setup && !strstr(cmdline, "noapic") )
> +                strlcat(cmdline, " noapic", cmdline_size);

Roger - this isn't going to work very well with PVH Dom0, is it?

> -        if ( (strlen(acpi_param) != 0) && !strstr(cmdline, "acpi=") )
> -        {
> -            safe_strcat(cmdline, " acpi=");
> -            safe_strcat(cmdline, acpi_param);
> -        }
> +            if ( (strlen(acpi_param) == 0) && acpi_disabled )

Not sure whether the compiler will do that transformation anyway, but this
check looks odd to me. Why not simply check whether the first char is the
nul one?

> +            {
> +                printk("ACPI is disabled, notifying Domain 0 (acpi=off)\n");
> +                safe_strcpy(acpi_param, "off");
> +            }

Here I'm doubtful, too, when it comes to PVH Dom0. If Xen's even works in
this mode anymore at all, I don't think we can sensibly start a PVH Dom0
then.

(This is leaving aside that all of this is Linux-centric anyway.)

> -        bd->kernel->cmdline_pa = __pa(cmdline);
> +            if ( (strlen(acpi_param) != 0) && !strstr(cmdline, "acpi=") )
> +            {
> +                strlcat(cmdline, " acpi=", cmdline_size);
> +                strlcat(cmdline, acpi_param, cmdline_size);
> +            }

(This, btw, won't work quite well when acpi= is specified more than once
on the command line.)

> +            bd->kernel->cmdline_pa = 0;
> +            bd->cmdline = cmdline;
> +        }
>      }
>  
>      bd->d = d;
>      if ( construct_dom0(bd) != 0 )
>          panic("Could not construct domain 0\n");
>  
> +    xfree(cmdline);

Leaving bd->cmdline dangling?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 30 14:19:32 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Jan 2025 14:19:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879619.1289835 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdVOE-0002Jh-Hu; Thu, 30 Jan 2025 14:19:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879619.1289835; Thu, 30 Jan 2025 14:19:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdVOE-0002Ja-FO; Thu, 30 Jan 2025 14:19:30 +0000
Received: by outflank-mailman (input) for mailman id 879619;
 Thu, 30 Jan 2025 14:19:29 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=zr8Z=UW=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tdVOD-0002JU-DO
 for xen-devel@lists.xenproject.org; Thu, 30 Jan 2025 14:19:29 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 36833314-df15-11ef-99a4-01e77a169b0f;
 Thu, 30 Jan 2025 15:19:27 +0100 (CET)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-aaf3c3c104fso188797166b.1
 for <xen-devel@lists.xenproject.org>; Thu, 30 Jan 2025 06:19:27 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab6e4a320c6sm125875866b.155.2025.01.30.06.19.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 30 Jan 2025 06:19:26 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 36833314-df15-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738246767; x=1738851567; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=7bh7LiGDhOhVo2P+f/nlI0xgHAPklGXZuw12L1qJ208=;
        b=Ct9Bm7JzFuyy54CdxWes8w7CkRBC/a3cgAn1bB3NoCQEN+D677umdzZV9kcSDSmHm1
         +pTroHdO5z1nId3tVaoDp580hHxzljD3RUe9X1/jXi5t0fkqx43nBG9fnX+g3X9AjTQj
         4Fv+XzsAWZuA4C937G8o4/oZ0WhlKWhsmtLvEFj0lzdsiMOu+S0PSJSvUDXB7ASoei18
         8HIsVl589PhfJRHQOykvBTWrvi7Rit2FtHLFWgWSLQVkw6cSRi97Jm68+0iLFxNullDy
         SqbhFlH2NIVD2Uvxu6sJqJnQGOtZy7+fN2Qh7olrHkixXPOipItfFK0DTczBGOflGhla
         G0Ww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738246767; x=1738851567;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=7bh7LiGDhOhVo2P+f/nlI0xgHAPklGXZuw12L1qJ208=;
        b=qgOammmz/P/82N95jpd2tDLDu96uOy2f+ZBZvH9eeOUBWe/g0E0tvtxaRhnAyDPGZG
         Zma5ntrj3kvLXrKZ027d4fWpMB74EjmWCnml82lJwjwUVBt6ynagi1ht/ncU/5+w9gjQ
         B/qfy21INZVCYVeS8JCyXBcBq2yrwphFHwE6B1CW0yK5tAn0iiPeOkbFdWooVGGAAcOy
         aIc2hXPykDMIPQ6z5jaM5fBqw7uj1pdTTVRDEB4vJRU/MJ07TkNHeMnyzKmB2d/+Mpc6
         yYdhg8P5BMbSDmnR5cVRPl8Wf7vvsT4ddc41Wk2lEuhDcsJ4wZpuHbxCNC4SJNLUny7v
         gUCw==
X-Forwarded-Encrypted: i=1; AJvYcCWfmhOCJY/U+xjbOXYgIg2HFdoXlmceb42QrvK/exVBvbjMn8x6/mHyL9XXsEZlBzxdwEBHYMKuhz4=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw7d3ZTy9/Tbeg+gBXxWb2CR9j+U5UgVvmjTh1K0lVvXq312eUe
	XXRvSdrBHEDpXTgA9QYe1sLWXbqknBwF2PVKVsddOvDeHjSiW3Xt49jHmSxwuQ==
X-Gm-Gg: ASbGncsAT/IHHV2YOXGLT2aBfhJf/6R3/H2G7oIik+wH7ZOv7uktBHsfgRtjeg+y6Bp
	PgVlhJofJNHXuT0T3HLw961jfcFowR4tTW8glEPuOdhuxLPEfoe86rGb2sQvvKGYgy+DfZEq8dd
	A8ejzM3IhBLnXfu2R5xp2cnzTPOBsJfr5UPmjC//TEiSFjrU2V73YCnKdHQ/avMFsmIM+5Je0p1
	7m76xF38gtgSKdxrEpwPY3WFHKC9coFMnbLY3fDSQBr0YlWrVGGjDuznKYlzLl9ABVjtMc7w4Jk
	TR/8eSPYblD+QzMEvJj/czsrTKWLDuz+lsHYQm3vf0E2mdNNf7Wa5+4hbvmn7SP/ZM/KzDyoL9l
	k
X-Google-Smtp-Source: AGHT+IE1eDqG4Q1FgN8Z7Oua76qGWxTX2F1e6Zw/V42Wr2aC+Po6k9l9x64DhdSj1PUUPY1sunN/nw==
X-Received: by 2002:a17:907:c319:b0:aaf:4008:5e2d with SMTP id a640c23a62f3a-ab6cfbb95e4mr674264666b.0.1738246766926;
        Thu, 30 Jan 2025 06:19:26 -0800 (PST)
Message-ID: <10e34547-08f1-46dd-8c87-115cf4f6ba4a@suse.com>
Date: Thu, 30 Jan 2025 15:19:25 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 04/15] kconfig: introduce option to independently
 enable libfdt
To: "Daniel P. Smith" <dpsmith@apertussolutions.com>
Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com,
 stefano.stabellini@amd.com, Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
 <20241226165740.29812-5-dpsmith@apertussolutions.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20241226165740.29812-5-dpsmith@apertussolutions.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 26.12.2024 17:57, Daniel P. Smith wrote:
> Currently, the inclusion of libfdt is controlled by the CONFIG_HAS_DEVICE_TREE
> kconfig flag. This flag also changes behavior in a few places, such as boot
> module processing for XSM. To support the ability to include libfdt without
> changing these behaviors, introduce CONFIG_LIB_DEVICE_TREE. The inclusion of
> libfdt is then moved under CONFIG_LIB_DEVICE_TREE.

Hmm. I'm not a DT maintainer (imo approval here needs to come from one of
its maintainers, despite the files being touched not saying so; I notice
you have the larger Cc list already), but to me the 'f' in libfdt is lost
with CONFIG_LIB_DEVICE_TREE. What's wrong with CONFIG_LIBFDT when that's
the code that you want to cover?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 30 14:31:12 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Jan 2025 14:31:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879627.1289846 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdVZT-0005Jm-IQ; Thu, 30 Jan 2025 14:31:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879627.1289846; Thu, 30 Jan 2025 14:31:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdVZT-0005Jf-FV; Thu, 30 Jan 2025 14:31:07 +0000
Received: by outflank-mailman (input) for mailman id 879627;
 Thu, 30 Jan 2025 14:31:06 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=zr8Z=UW=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tdVZS-0005JX-9p
 for xen-devel@lists.xenproject.org; Thu, 30 Jan 2025 14:31:06 +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 d456424f-df16-11ef-99a4-01e77a169b0f;
 Thu, 30 Jan 2025 15:31:01 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-aaedd529ba1so126144966b.1
 for <xen-devel@lists.xenproject.org>; Thu, 30 Jan 2025 06:31:01 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab6e4a562e7sm126380366b.167.2025.01.30.06.30.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 30 Jan 2025 06:30:59 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: d456424f-df16-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738247461; x=1738852261; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=zH4SExfP15QqnigMMMw/hrCvxM6oyFaSmBIhN4cUHVM=;
        b=bjMFQdVkycotjYjoThysr5t+dKt3Tn+hD/4MrJa6mWje7aJWS3eBW0Y9RzAzTAM06R
         7ILCeQoF4g+gpF6e+5ctp4jqM+7zQHd1epfccQt3sQWy+Tvani5PMIcLjHxT3JBxIb39
         lHe0eDkxI7jOr7a+EfYl5YDDEfLxphrCZa0njaB67auaK2YbGJshvdkggfGqflsfIL5+
         OyLB/1hWP61klyurw+/24l/wSGocZ12TG6844H3lEzqlaWjcRSvA5rYKp3m0nH3fEhBP
         ai5hv5T1KmKnCH1pC02FTN76z2JS6Z9IaFzLVKHd/F0g59k+RwfXQ/fmTe1VCG9vskKU
         Q4ZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738247461; x=1738852261;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=zH4SExfP15QqnigMMMw/hrCvxM6oyFaSmBIhN4cUHVM=;
        b=ByrxfzYOIF2T2ZW7IUU/7cKHfwg7esUpe36pG0whg6NycFZc9kofyHGbMzmLxst+n2
         LzozntrJgx4X9/1CGZHqa+FebvQqbBw6ISY3E9ITcNFuEDLPcPTwKXIXqDwTnCgJ8Ukk
         2uahaCuIFv01gPBJpK8+9vulzJTaMrGgMfsN+0Nskc1C2U9lnvhJkOsxB3O3G4ViqVdr
         CIiRevtPMPNSQcomknrLwHjm0VvaVGq6fWQHTWA1uc1Si3cz80uBzwefJBlWWfwi37Ym
         zgI0lhPpdczQUAAxEvgge/nTkSQlGh238eOcz24IxzpRDOZcynHUKQiHMNPS8yc0QjTf
         wsow==
X-Forwarded-Encrypted: i=1; AJvYcCUDl3rFXbjaCJH5GGezT3g9SS0JgQTTMa2bCLSk60W8ejWMCch48sy2UPTKJD1XePCH7CJ3tNYABGQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwKgU+3MornQYT4lujEwMHTD4bmsbPaDrVaHGDBlNN4urBHXkoO
	DGJkbqweSxX+Dl1IaRhVAvICMq0nxlrvPI64HyfiqZHzxN8Q6IsC6oT2e7+mIQ==
X-Gm-Gg: ASbGncsKCeqPYe2c2aYGeXmN0uhvfp2735F4oDty1KxOe58mieDT2xlR2j4BNifVoeZ
	fCsgoCmOnoLMIF7KJbxp55d9wdy/GKr7hs5jc87+foFiPYkGjXdd+cInWaphfykBjYpZXW3hCNL
	UvYfeAfF8J04Lu0j4YTLyzh3kVwTHAk2zdw9qz1qRTyn03qEbnxVn/vhSpLsIeAzRF1dmYl5Ubk
	KltbZWl7Kw0TAoBlkSm9gj7x93XCDsxDCU4ak2gJHUFFpk/R5avwTsj8gG/0/DC6mXarNEenx2R
	+eubn1ULwQ0AD9oevw9rpHswDLoKmTVoBtnn7W+xjIYdzncVps/f7JUL11WJMcCm2q48Qvgnqjq
	s
X-Google-Smtp-Source: AGHT+IGROh7kfe458AtiDEkMD3Nr/FRXa88sn/COUJiJ4F0TFQ00aGFXM8KW9ok7E7t/48E2yXxyxg==
X-Received: by 2002:a05:6402:a001:b0:5dc:7374:261d with SMTP id 4fb4d7f45d1cf-5dc737427bfmr3798282a12.7.1738247459830;
        Thu, 30 Jan 2025 06:30:59 -0800 (PST)
Message-ID: <df094ad3-810a-46c1-8bb0-d240a8d80744@suse.com>
Date: Thu, 30 Jan 2025 15:30:58 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 05/15] kconfig: introduce domain builder config option
To: "Daniel P. Smith" <dpsmith@apertussolutions.com>
Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com,
 stefano.stabellini@amd.com, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
 <20241226165740.29812-6-dpsmith@apertussolutions.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20241226165740.29812-6-dpsmith@apertussolutions.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 26.12.2024 17:57, Daniel P. Smith wrote:
> Hyperlaunch domain builder will be the consolidated boot time domain building
> logic framework. Introduces the config option to enable this domain builder to
> and turn on the ability to load the domain configuration via a flattened device
> tree.

s/and/eventually/? Else I fear I'm not getting what is being said here. There's
no turning on of anything just yet, afaics.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 30 14:52:17 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Jan 2025 14:52:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879636.1289856 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdVtn-0000Jf-6O; Thu, 30 Jan 2025 14:52:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879636.1289856; Thu, 30 Jan 2025 14:52:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdVtn-0000JY-3V; Thu, 30 Jan 2025 14:52:07 +0000
Received: by outflank-mailman (input) for mailman id 879636;
 Thu, 30 Jan 2025 14:52: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 <SRS0=zr8Z=UW=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tdVtl-0000JS-K6
 for xen-devel@lists.xenproject.org; Thu, 30 Jan 2025 14:52:05 +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 c395e909-df19-11ef-99a4-01e77a169b0f;
 Thu, 30 Jan 2025 15:52:02 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-aaf900cc7fbso195258566b.3
 for <xen-devel@lists.xenproject.org>; Thu, 30 Jan 2025 06:52:02 -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
 a640c23a62f3a-ab6e49ffe2csm132946366b.97.2025.01.30.06.52.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 30 Jan 2025 06:52:01 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c395e909-df19-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738248721; x=1738853521; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=85SvtHqP8cX49Ac7xOWKCkFBVDAoKOjQb6SChB5iD08=;
        b=gB9oQB3TDK0oigKG24gx8i0xQxomM5wPduMpOJrHsi8bLc3kcIenGRBeaI6/9OgnSi
         01yq4cv7Q1Aak4McLgCLjv4cjVcyMxkV16HW0gW5XdDgbDsUXisUIt141+z7q4eEyg2m
         kL3Qn7VCxgzqbjXlXjiNDfc5y19mRThrycDdnHENrVgsOCWRKuBiDjL80rTve4xuc9+N
         1hZK9w9mcyiZqnLAkgO2EhPAeMsCJE2HmUCmXafW1AGpaL4ghJYIBex8Qvm0zEnsvwQm
         HjAj54Aiy9XqBPA/14rH3I0hyUEFZCX+twih7d+aKE02tf8Ecqtoe7GJK88HBDPpPUpH
         Zc4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738248721; x=1738853521;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=85SvtHqP8cX49Ac7xOWKCkFBVDAoKOjQb6SChB5iD08=;
        b=GvdoGrYLMgW4ceRLA1rO4EhinlZ/4csYf39hN3D7PZuMqnxkSpNyJQ5UqmDCi7Fsoz
         Qh6aP59bBu8jdEzmh12cN6ZyL5zGAQNCri0B/MKiBe7qkC/2A2uuA9QfXoTMnleJjlT7
         UFPqLQX2nxwdFYde+dbEgKU78xe2ahL4bmG1NOXEqUdbaRb/fq1xQ2gQxz1oeSGksXpX
         NMc2yWibJxQk6GXbpLnm+nwr2adRLTXAr2wce13XilUcrbRKwkkWQDHFb+EAyHymksVD
         1SlFtBmgw0vggjSRp+SIlsYi2FnOo72OE420yybSo++/Dfp2TEfF+hN0R3ZQKhtLgajr
         WuwA==
X-Forwarded-Encrypted: i=1; AJvYcCWiw23jZm3ANzJdC0DyIaSJhuJlx3qIzF/OB3OeGK4+lYshUtImglRlGDtLq0Uc7onRYsTJ34jM2Z8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyESm9+LriFyrpKxgfYAaSDDjBvULCQmiYGeD+fIgBA1i7vUL0+
	ueqYdR9qcYEx4h7j0P8x35d3s4ZFg9YSYsB4cJF8yxNLc/B68yZ6uqjFhhcVqQ==
X-Gm-Gg: ASbGncsqceOAqIGcyLdl9jB9qAuFH6n3zW+aNcuKQ1zssZCaKUYCFVFpGPqa0jRRWAx
	N6FKv/uptWv20x69/FQLQPQuXT41gIsNVXGXQ7QcqoKR+9yflcblyvkCxbeIOb4eBYfAhUt9Z+s
	gHYRWdFTd0FuStE7VWBRnaUc4mBXkWJo/zgIaRTI7kLkBbr9sRipkMXQGY45OX6eDchY05x8ylT
	XyuUcFaJpwAijvEL3VdMr5z+QNA2ILVidk210Eq/vr76WCrKDNkYc23qhXT3qYtiloa5hr9TOCg
	CBYLM9FTlvTzJki52vnXOgqoNja8aDasDU3Ra27PfuVqKa36BxHApuAFpBIYazwky1YFgj1xNhd
	m
X-Google-Smtp-Source: AGHT+IHT+NilzeX2bT7xRutSVMoOBdrgFJhNwKe1b3EBqFrlblmVBGuiHgyy1lQkvIpk5D6lRHyWFQ==
X-Received: by 2002:a17:907:94cd:b0:ab6:3633:13e with SMTP id a640c23a62f3a-ab6cfdbd071mr878900966b.41.1738248721523;
        Thu, 30 Jan 2025 06:52:01 -0800 (PST)
Message-ID: <004b066a-b26f-44bd-994f-5c573f6511e6@suse.com>
Date: Thu, 30 Jan 2025 15:52:00 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 06/15] x86/hyperlaunch: introduce the domain builder
To: "Daniel P. Smith" <dpsmith@apertussolutions.com>
Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com,
 stefano.stabellini@amd.com, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
 <20241226165740.29812-7-dpsmith@apertussolutions.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20241226165740.29812-7-dpsmith@apertussolutions.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 26.12.2024 17:57, Daniel P. Smith wrote:
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -81,6 +81,8 @@ obj-$(CONFIG_COMPAT) += x86_64/platform_hypercall.o
>  obj-y += sysctl.o
>  endif
>  
> +obj-y += domain-builder/

The set of subdirs needed in $(obj-y) is specified at the top of the file.
Also shouldn't this be obj-$(CONFIG_DOMAIN_BUILDER)?

> --- /dev/null
> +++ b/xen/arch/x86/domain-builder/core.c
> @@ -0,0 +1,57 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (C) 2024, Apertus Solutions, LLC
> + */
> +#include <xen/err.h>
> +#include <xen/init.h>
> +#include <xen/kconfig.h>
> +#include <xen/lib.h>
> +
> +#include <asm/bootinfo.h>
> +
> +#include "fdt.h"
> +
> +void __init builder_init(struct boot_info *bi)
> +{
> +    if ( IS_ENABLED(CONFIG_DOMAIN_BUILDER) )
> +    {
> +        int ret;
> +
> +        switch ( ret = has_hyperlaunch_fdt(bi) )
> +        {
> +        case 0:
> +            printk("Hyperlaunch device tree detected\n");
> +            bi->hyperlaunch_enabled = true;
> +            bi->mods[0].type = BOOTMOD_FDT;
> +            break;
> +
> +        case -EINVAL:
> +            printk("Hyperlaunch device tree was not detected\n");
> +            bi->hyperlaunch_enabled = false;
> +            break;
> +
> +        case -ENOENT:
> +        case -ENODATA:
> +            printk("Device tree found, but not hyperlaunch (%d)\n", ret);
> +            bi->hyperlaunch_enabled = false;
> +            bi->mods[0].type = BOOTMOD_FDT;
> +            break;
> +
> +        default:
> +            printk("Unknown error (%d) occured checking for hyperlaunch device tree\n",
> +                   ret);
> +            bi->hyperlaunch_enabled = false;
> +            break;
> +        }
> +    }
> +}

What is it that's x86-specific in here?

> --- /dev/null
> +++ b/xen/arch/x86/domain-builder/fdt.c
> @@ -0,0 +1,37 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (C) 2024, Apertus Solutions, LLC
> + */
> +#include <xen/err.h>
> +#include <xen/init.h>
> +#include <xen/lib.h>
> +#include <xen/libfdt/libfdt.h>
> +
> +#include <asm/bootinfo.h>
> +#include <asm/page.h>
> +#include <asm/setup.h>
> +
> +#include "fdt.h"
> +
> +int __init has_hyperlaunch_fdt(struct boot_info *bi)

Pointer-to-const?

> +{
> +    int ret = 0;
> +    const void *fdt = bootstrap_map_bm(&bi->mods[HYPERLAUNCH_MODULE_IDX]);
> +
> +    if ( fdt_check_header(fdt) < 0 )
> +        ret = -EINVAL;
> +
> +    bootstrap_unmap();
> +
> +    return ret;
> +}

Is this function intended to later be extended? Aiui anything fitting
the hyperlaunch-agnostic fdt_check_header() will do here, despite the
name of the function.

And again - what is it that's x86-specific in here?

> --- /dev/null
> +++ b/xen/arch/x86/domain-builder/fdt.h
> @@ -0,0 +1,21 @@
> +/* SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause) */
> +#ifndef __XEN_X86_FDT_H__
> +#define __XEN_X86_FDT_H__
> +
> +#include <xen/init.h>
> +
> +#include <asm/bootinfo.h>

This isn't needed here, nor ...

> --- /dev/null
> +++ b/xen/arch/x86/include/asm/domainbuilder.h
> @@ -0,0 +1,8 @@
> +#ifndef __XEN_X86_DOMBUILDER_H__
> +#define __XEN_X86_DOMBUILDER_H__
> +
> +#include <asm/bootinfo.h>

... here, is it? Forward decls of struct boot_info are going to do.

> @@ -1285,9 +1286,12 @@ void asmlinkage __init noreturn __start_xen(void)
>                 bi->nr_modules);
>      }
>  
> -    /* Dom0 kernel is always first */
> -    bi->mods[0].type = BOOTMOD_KERNEL;
> -    bi->domains[0].kernel = &bi->mods[0];
> +    builder_init(bi);
> +
> +    /* Find first unknown boot module to use as Dom0 kernel */
> +    i = first_boot_module_index(bi, BOOTMOD_UNKNOWN);
> +    bi->mods[i].type = BOOTMOD_KERNEL;
> +    bi->domains[0].kernel = &bi->mods[i];

This is going to change again later? Or else what about there already
being a module marked BOOTMOD_KERNEL?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 30 15:01:23 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Jan 2025 15:01:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879651.1289865 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdW2i-00024P-40; Thu, 30 Jan 2025 15:01:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879651.1289865; Thu, 30 Jan 2025 15:01:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdW2i-00024I-1S; Thu, 30 Jan 2025 15:01:20 +0000
Received: by outflank-mailman (input) for mailman id 879651;
 Thu, 30 Jan 2025 15:01:18 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=zr8Z=UW=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tdW2g-00023o-Bk
 for xen-devel@lists.xenproject.org; Thu, 30 Jan 2025 15:01:18 +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 0deefdc2-df1b-11ef-99a4-01e77a169b0f;
 Thu, 30 Jan 2025 16:01:16 +0100 (CET)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-ab6da1bb1a8so14671266b.0
 for <xen-devel@lists.xenproject.org>; Thu, 30 Jan 2025 07:01:16 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab6e47a7be3sm132767666b.20.2025.01.30.07.01.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 30 Jan 2025 07:01:14 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 0deefdc2-df1b-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738249276; x=1738854076; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=toZgCuzt7GCQoVpVrSpNaSw3cbETjFUKeVCvGGIxgzs=;
        b=HOBXdSwiRnue6Dhpto21eFUKrAxRBhj8aL/s7W4FsU//DMvScyDGtuOU1yG9coxfsy
         c2xgLc2kr+UgYEYb+4OtCfptSIhVgK6bypMjjzHufElsk3vQo9Cn4yEcRmfzDjW2sQe8
         rSPhNXR/3SNxrYLTbpEA/I5xqGc936ZezsfYFcVuvtYZM7yfVKEuCUf1CrA1vYzilFtW
         +Ag4AiSfLFNplKdqfIC012UAvzbz7LbRPPc78ZCsbL+sYa4AkYwKXmpQ29TInLMdVWFC
         DUm3x3MDP2/k6WDGmYLRtelYGSjm2BELy2D5rqu6U2nHuqA4WpPD71SZaK6d9lLtiazT
         QU/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738249276; x=1738854076;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=toZgCuzt7GCQoVpVrSpNaSw3cbETjFUKeVCvGGIxgzs=;
        b=i5vnLW7QnMGRRgTecG89Hj02V4lffYo7Pol/VRDgIF1TH2S9+Hnrlw1JZ7ffJ1U8wP
         WXN58bSwCLjrMKRJx9i06CG7ec6vg70dq0u6gNdAzt0PtSaQVnfh+Du9A7ro50nt+Wlg
         6s5u+UUJEsFjNou4lnargeU4VVmfa39XBvfZbjTh5WfrZQPYlMyoP89cdMCuLqXyJVuM
         x/JbybUW+rf1+W39LdUbb8EVHSKXjmRFUQnBt3y37tnaYTDtHWtsMFAF2w8NtrQfq8OR
         0gLF3mV/nq4xZkU9qD+P2bsBfR1Re32QgYS65C9QJULlMWVbzmhYEKzQq+KqIuyBXHIz
         q5bg==
X-Forwarded-Encrypted: i=1; AJvYcCVpZcKVNWEnj4T/Vd1E1ySaeYBlympz3aowz8e5aUAwC6QgMU7DU66yRmsgkWBioaj18XcaLsRpAKo=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz4fjxERLdsCWUBaltSCvFfpYvjD+yHEx1gUi5YgMQROVLA65GL
	5C5mFUjBugtURCJvZbm7D4m/PUTwfYSP6vDmHXxJLrGb1NuXgoibuo7dAx3+Wg==
X-Gm-Gg: ASbGnctRdZ0s7Cw5VyffY36P83YSRIJ7iwL1idafYQWq9MtVOAhzIEu+5dVMtMwDzdP
	LPnfFOkjceN3P6TZAgGPOZFUqAi1Gu+mT9NVKhKaJwzIq9lszeP7HG2dQrsIqi7V+3IMGI3Y69K
	xTneEgUoWtQvP6OoEwHDqLO4Sa1W2WQ+3gjsH9f8X2cWpEm/+SjucZwws+nB1hm/gGpDfxZNLBX
	9f+qd3bkFFNisXPFaCDXI0SfxH07VydBrQ+AtgxGDOEHC/KNpp8c1/j+qXo/uQC9Cin3Jod8yRK
	F1mCpwvTwbialTnLGnMZ3ntgDppUJ9xQ7srOPsJdzvlQ8IyGVDivr2D880fwsJ6qqGPrL7EVRaA
	H
X-Google-Smtp-Source: AGHT+IFnG8Bc2cXaR2m+qMQnE1vy55ehxO1J76HfZaQqD56qSY6Ap1+4v5E0uxkxFhQPmXmqXvAtUg==
X-Received: by 2002:a17:907:7fa8:b0:aa6:2704:4840 with SMTP id a640c23a62f3a-ab6cfe401d5mr770487366b.51.1738249274760;
        Thu, 30 Jan 2025 07:01:14 -0800 (PST)
Message-ID: <cbc3b3a2-60bd-4fdc-a4ac-dfa77420e454@suse.com>
Date: Thu, 30 Jan 2025 16:01:13 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 07/15] x86/hyperlaunch: initial support for hyperlaunch
 device tree
To: "Daniel P. Smith" <dpsmith@apertussolutions.com>
Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com,
 stefano.stabellini@amd.com, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
 <20241226165740.29812-8-dpsmith@apertussolutions.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20241226165740.29812-8-dpsmith@apertussolutions.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 26.12.2024 17:57, Daniel P. Smith wrote:
> --- a/xen/arch/x86/domain-builder/fdt.c
> +++ b/xen/arch/x86/domain-builder/fdt.c
> @@ -13,14 +13,77 @@
>  
>  #include "fdt.h"
>  
> +static int __init find_hyperlaunch_node(const void *fdt)
> +{
> +    int hv_node = fdt_path_offset(fdt, "/chosen/hypervisor");
> +
> +    if ( hv_node >= 0 )
> +    {
> +        /* Anything other than zero indicates no match */
> +        if ( fdt_node_check_compatible(fdt, hv_node, "hypervisor,xen") )
> +            return -ENODATA;
> +        else
> +            return hv_node;
> +    }
> +    else
> +    {
> +        /* Lood for dom0less config */
> +        int node, chosen_node = fdt_path_offset(fdt, "/chosen");
> +        if ( chosen_node < 0 )

Nit: Blank line between declaration(s) and statement(s) please. I'd also
question "node" being plain int, if libfdt didn't have it like this.

> +            return -ENOENT;
> +
> +        fdt_for_each_subnode(node, fdt, chosen_node)
> +        {
> +            if ( fdt_node_check_compatible(fdt, node, "xen,domain") == 0 )
> +                return chosen_node;
> +        }
> +    }
> +
> +    return -ENODATA;
> +}
> +
>  int __init has_hyperlaunch_fdt(struct boot_info *bi)
>  {
>      int ret = 0;
>      const void *fdt = bootstrap_map_bm(&bi->mods[HYPERLAUNCH_MODULE_IDX]);
>  
> -    if ( fdt_check_header(fdt) < 0 )
> +    if ( !fdt || fdt_check_header(fdt) < 0 )
>          ret = -EINVAL;
> +    else
> +        ret = find_hyperlaunch_node(fdt);
> +
> +    bootstrap_unmap();
> +
> +    return ret < 0 ? ret : 0;
> +}
> +
> +int __init walk_hyperlaunch_fdt(struct boot_info *bi)

const?

> +{
> +    int ret = 0, hv_node, node;
> +    void *fdt = bootstrap_map_bm(&bi->mods[HYPERLAUNCH_MODULE_IDX]);

const?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 30 15:43:06 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Jan 2025 15:43:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879663.1289876 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdWh3-0007TO-4U; Thu, 30 Jan 2025 15:43:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879663.1289876; Thu, 30 Jan 2025 15:43:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdWh3-0007TH-1D; Thu, 30 Jan 2025 15:43:01 +0000
Received: by outflank-mailman (input) for mailman id 879663;
 Thu, 30 Jan 2025 15:42: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 <SRS0=zr8Z=UW=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tdWh1-0007TB-Ny
 for xen-devel@lists.xenproject.org; Thu, 30 Jan 2025 15:42:59 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e090115f-df20-11ef-99a4-01e77a169b0f;
 Thu, 30 Jan 2025 16:42:57 +0100 (CET)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-ab39f84cbf1so174782566b.3
 for <xen-devel@lists.xenproject.org>; Thu, 30 Jan 2025 07:42: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
 a640c23a62f3a-ab6e47a7df0sm138691366b.2.2025.01.30.07.42.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 30 Jan 2025 07:42:56 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e090115f-df20-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738251777; x=1738856577; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=mDEsX/r4PjaofjZR6OM6P7CS3MJ+XACOGaPvZN+UEjY=;
        b=M0ZNrSWUA5Cs8zek192ReAlDEZifsDre7J6zFZkW4lW5Szeze9najwkwr4QSRX4WHV
         pqBQS/JZeaSQOaEm7wOmo1lvGxSB68YF5SaqULQJjdOzp461De+zwFxEqJyhiIDwikya
         abKYK9XG5f+fgyLQ0RlZA3dyCelGhvR76KtZ5lPu9tfo3Ee4fwPr3ltVkJ+Ur2L9NGLZ
         Xl5fUYwIrfQkjZl8IwStXDWkq1gOcALRuuV4/ot6OnfHv/1/OVlwpmM5VrRRLiNAijGS
         NcEbBc3ZX5PppV/h2cpQmiVZ5ie9XuG1oyZeSO1Y5HJI104WBDOogMMAbVf/U0zFbrfl
         i0gw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738251777; x=1738856577;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=mDEsX/r4PjaofjZR6OM6P7CS3MJ+XACOGaPvZN+UEjY=;
        b=okOox+ElCWyBeKzdaTHGr9jOX7VUR/RuFsDgYYJAaSNP2cZbLf4EzmKZ8KirDUElLk
         /78y35a4ObIQzkHGHBg4p57gqdAmQe46uiv0WwnRf3K85UIR09IJQq/UVlFlqu7Tqxy2
         Jlg49xf3fY4sgeqBALRGpwpXnm5FU1OWIUK9mWAPVcVC+lVfRJaPhOmHq458KeFq99R3
         foUEF5rCInVXpPV+emzVV7xKooPOYeieYhM+Esa0LaHiLGTnpw2y0fgtamIsVGdv8QeN
         BvoCKFLHo/rOVLgfCuNH5/X9tcmDZrtKOyyBk0bRNkBRyxp5AnpI5I4YIH7UQ9zAN873
         UCqQ==
X-Forwarded-Encrypted: i=1; AJvYcCVP48qAzDVD5IiGsYInuiYSixKeivAW47uvNQlomHhLCQTZKeoDLbnEjd0kUW0mp1pvuId2f7jj5nU=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywud3jTsilXQfvPE/8Mz0st21AV1RLZFJqxrmlgy8g/Ukt/e/RB
	dB1qkJ4mTMT1e3mFALatAii3A1v8rPpG5VOk8VrkduB9ZTo6HQ+d+3Zrfp6Pew==
X-Gm-Gg: ASbGnctTVcGYlcwpPNXE4FJe83tuB6lHwihJOEDnNm5i/CUtvJqDfmHBzgY+Vfptvph
	OtnXXp7tzxFxLjC+a8IOPPa42hgNpFu/b7YSQP0Ju4u+UHnJNLQy8VXlnODhAYhURFEw/bT5fo/
	0Q7qQJQ3Yrurj9pkFe0kR5sOU4wC3S345yadwNO85iId1s8Hw59ZdTrB73fUlIFbOsEdPGZfQp+
	IeSDHn8FMSAFTW+6dphDP9Lp5jHOM+3/2uDPuh1vaK9X0MLsrGIJ1/gi0DmcRxld1hrxHeN4eku
	QqayP7+ABH7TiZ671yLtejiqGea3+uWyrRXsE291FY2+aQOL9EsK1c/lkD6J4MOAbU5L9oi6WWe
	h
X-Google-Smtp-Source: AGHT+IErACVG7aGX1AMY5fQ9Z2IhJW4EPg/SVOFLqMHcPNWzr3e9zDEhQqWmsmzmpKmJHUqUU/ueMw==
X-Received: by 2002:a17:907:6ea3:b0:ab6:f4e0:c06 with SMTP id a640c23a62f3a-ab6f4e00fe4mr51521066b.21.1738251776509;
        Thu, 30 Jan 2025 07:42:56 -0800 (PST)
Message-ID: <efc352d6-e686-435c-98b3-2333b6dee6a3@suse.com>
Date: Thu, 30 Jan 2025 16:42:55 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 08/15] x86/hyperlaunch: locate dom0 kernel with
 hyperlaunch
To: "Daniel P. Smith" <dpsmith@apertussolutions.com>
Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com,
 stefano.stabellini@amd.com, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>, xen-devel@lists.xenproject.org
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
 <20241226165740.29812-9-dpsmith@apertussolutions.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20241226165740.29812-9-dpsmith@apertussolutions.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 26.12.2024 17:57, Daniel P. Smith wrote:
> Look for a subnode of type `multiboot,kernel` within a domain node. If found,
> process the reg property for the MB1 module index. If the bootargs property is
> present and there was not an MB1 string, then use the command line from the
> device tree definition.

While multiboot is apparently the first x86-specific part (as far as Xen goes)
to be put under domain-builder/, I wonder:
- Wouldn't looking for "multiboot,kernel" simply yield nothing on non-x86,
  so having the code under common/ would still be okay?
- What's "multiboot" describing here? The origin of the module? (What other
  origins would then be possible? How would MB1 and MB2 be distinguished?
  What about a native xen.efi boot?) A property of the kernel (when Linux
  doesn't use MB)?

> --- a/xen/arch/x86/domain-builder/core.c
> +++ b/xen/arch/x86/domain-builder/core.c
> @@ -59,6 +59,17 @@ void __init builder_init(struct boot_info *bi)
>  
>          printk(XENLOG_INFO "  Number of domains: %d\n", bi->nr_domains);
>      }
> +    else
> +    {
> +        unsigned int i;
> +
> +        /* Find first unknown boot module to use as Dom0 kernel */
> +        printk("Falling back to using first boot module as dom0\n");

Nit (personal taste?): Why Dom0 in the comment and dom0 in the log
message. I think the former is to be preferred, but at the very least
I see no reason to spell it differently on two adjacent lines.

> +        i = first_boot_module_index(bi, BOOTMOD_UNKNOWN);
> +        bi->mods[i].type = BOOTMOD_KERNEL;
> +        bi->domains[0].kernel = &bi->mods[i];
> +        bi->nr_domains = 1;
> +    }

Relating to a question on an earlier patch: The assumption here is
that nothing could have marked another module as BOOTMOD_KERNEL?

> --- a/xen/arch/x86/domain-builder/fdt.c
> +++ b/xen/arch/x86/domain-builder/fdt.c
> @@ -13,6 +13,114 @@
>  
>  #include "fdt.h"
>  
> +static int __init hl_module_index(void *fdt, int node, uint32_t *idx)

const void *?

> +{
> +    int ret = 0;
> +    const struct fdt_property *prop =
> +        fdt_get_property(fdt, node, "module-index", &ret);
> +
> +    /* FDT error or bad idx pointer, translate to -EINVAL */
> +    if ( ret < 0 || idx == NULL )

This is a static helper - why check the parameter for being NULL?

> +        return -EINVAL;
> +
> +    fdt_cell_as_u32((fdt32_t *)prop->data, idx);

While I'm aware libfdt has quite a few of such casts, they're problematic.
First and foremost this is a Misra violation, for casting away const-ness.
And then how do you know there are 4 bytes of data to legitimately access?
Hence why such casts would better be avoided altogether (or at least be
suitably abstracted away).

(There's at least one other instance further down.)

> +    if ( *idx > MAX_NR_BOOTMODS )

>= ?

> +        return -ERANGE;
> +
> +    return 0;
> +}
> +
> +static int __init dom0less_module_index(
> +    void *fdt, int node, int size_size, int address_size, uint32_t *idx)
> +{
> +    uint64_t size = ~0UL, addr = ~0UL;
> +    int ret =
> +        fdt_get_reg_prop(fdt, node, address_size, size_size, &addr, &size, 1);

    int ret = fdt_get_reg_prop(
                  fdt, node, address_size, size_size, &addr, &size, 1);

> +    /* FDT error or bad idx pointer, translate to -EINVAL */
> +    if ( ret < 0 || idx == NULL )

See above as to the NULL check.

> +        return -EINVAL;
> +
> +    /* Convention is that zero size indicates address is an index */
> +    if ( size != 0 )
> +        return -EOPNOTSUPP;
> +
> +    if ( addr > MAX_NR_BOOTMODS )

>= again?

> +        return -ERANGE;
> +
> +    /*
> +     * MAX_NR_BOOTMODS cannot exceed the max for MB1, represented by a u32,
> +     * thus the cast down to a u32 will be safe due to the prior check.
> +     */

Instead of (or in addition to) the comment, put in a BUILD_BUG_ON()?

Also please can you avoid using u32 even in comments? It'll only yield
needless grep matches once we go about fully purging it.

> +    *idx = (uint32_t)addr;
> +
> +    return 0;
> +}
> +
> +static int __init process_domain_node(
> +    struct boot_info *bi, void *fdt, int dom_node)

const twice? (I guess I won't mention such any further. I think I
previously asked that you make things as const-correct as possible.)

> +{
> +    int node;
> +    struct boot_domain *bd = &bi->domains[bi->nr_domains];
> +    const char *name = fdt_get_name(fdt, dom_node, NULL) ?: "unknown";
> +
> +    fdt_for_each_subnode(node, fdt, dom_node)
> +    {
> +        if ( fdt_node_check_compatible(fdt, node, "multiboot,kernel") == 0 )
> +        {
> +            unsigned int idx;
> +            int ret = 0;
> +
> +            if ( bd->kernel )
> +            {
> +                printk(XENLOG_ERR "Duplicate kernel module for domain %s)\n",
> +                       name);

It's XENLOG_ERR here (but a seemingly stray closing parenthesis at the end),
yet ...

> +                continue;
> +            }
> +
> +            /* Try hyperlaunch property, fall back to dom0less property. */
> +            if ( hl_module_index(fdt, node, &idx) < 0 )
> +            {
> +                int address_size = fdt_address_cells(fdt, dom_node);
> +                int size_size = fdt_size_cells(fdt, dom_node);
> +
> +                if ( address_size < 0 || size_size < 0 )
> +                    ret = -EINVAL;
> +                else
> +                    ret = dom0less_module_index(
> +                            fdt, node, size_size, address_size, &idx);
> +            }
> +
> +            if ( ret < 0 )
> +            {
> +                printk("  failed processing kernel module for domain %s)\n",

... two blanks (and the same odd parenthesis) here and ...

> +                       name);
> +                return ret;
> +            }
> +
> +            if ( idx > bi->nr_modules )

>= again?

> +            {
> +                printk("  invalid kernel module index for domain node (%d)\n",

... again two blanks here. What's the deal?

> +                       bi->nr_domains);
> +                return -EINVAL;
> +            }
> +
> +            printk("  kernel: boot module %d\n", idx);

This I expect has two leading blanks to somehow align (normal) output.

> +            bi->mods[idx].type = BOOTMOD_KERNEL;
> +            bd->kernel = &bi->mods[idx];
> +        }
> +    }
> +
> +    if ( !bd->kernel )
> +    {
> +        printk(XENLOG_ERR "ERR: no kernel assigned to domain\n");
> +        return -EFAULT;

EFAULT? Maybe ENODATA or some such?

> +    }
> +
> +    return 0;
> +}
> +
>  static int __init find_hyperlaunch_node(const void *fdt)
>  {
>      int hv_node = fdt_path_offset(fdt, "/chosen/hypervisor");
> @@ -74,9 +182,19 @@ int __init walk_hyperlaunch_fdt(struct boot_info *bi)
>  
>      fdt_for_each_subnode(node, fdt, hv_node)
>      {
> +        if ( bi->nr_domains >= MAX_NR_BOOTDOMS )
> +        {
> +            printk(XENLOG_WARNING "WARN: more domains defined than max allowed");

Missing \n. Also would all HL-related diagnostics perhaps better have a
respective prefix (for disambiguation and grep-ability)?

> --- a/xen/arch/x86/domain-builder/fdt.h
> +++ b/xen/arch/x86/domain-builder/fdt.h
> @@ -3,6 +3,8 @@
>  #define __XEN_X86_FDT_H__
>  
>  #include <xen/init.h>
> +#include <xen/libfdt/libfdt.h>
> +#include <xen/libfdt/libfdt-xen.h>
>  
>  #include <asm/bootinfo.h>
>  
> @@ -10,6 +12,7 @@
>  #define HYPERLAUNCH_MODULE_IDX 0
>  
>  #ifdef CONFIG_DOMAIN_BUILDER
> +
>  int has_hyperlaunch_fdt(struct boot_info *bi);
>  int walk_hyperlaunch_fdt(struct boot_info *bi);
>  #else

I can't explain the need for either of these two hunks.

> --- a/xen/include/xen/libfdt/libfdt-xen.h
> +++ b/xen/include/xen/libfdt/libfdt-xen.h
> @@ -13,6 +13,82 @@
>  
>  #include <xen/libfdt/libfdt.h>
>  
> +static inline int __init fdt_cell_as_u32(const fdt32_t *cell, uint32_t *val)
> +{
> +    *val = fdt32_to_cpu(*cell);
> +
> +    return 0;
> +}
> +
> +static inline int __init fdt_cell_as_u64(const fdt32_t *cell, uint64_t *val)
> +{
> +    *val = ((uint64_t)fdt32_to_cpu(cell[0]) << 32) |
> +           (uint64_t)fdt32_to_cpu(cell[1]);

As we try to conserve on the number of casts: There's no need for the
latter one, is there?

I'll leave it to DT folks to confirm (or otherwise) that the cell indexes
are invariant no matter what the endian-ness.

> +    return 0;

What's the point of this return value for both of the functions? Wouldn't
they better return the value if no error can occur anyway? Afaics none of
the callers checks the return value right now.

> +}
> +
> +/*
> + * Property: reg
> + *
> + * Defined in Section 2.3.6 of the Device Tree Specification is the "reg"
> + * standard property. The property is a prop-encoded-array that is encoded as
> + * an arbitrary number of (address, length) pairs.
> + */
> +static inline int __init fdt_get_reg_prop(
> +    const void *fdt, int node, unsigned int asize, unsigned int ssize,
> +    uint64_t *addr, uint64_t *size, unsigned int pairs)
> +{
> +    int ret;
> +    unsigned int i, count;
> +    const struct fdt_property *prop;
> +    fdt32_t *cell;
> +
> +    /* FDT spec max size is 4 (128bit int), but largest arch int size is 64 */
> +    if ( ssize > 2 || asize > 2 )
> +        return -EINVAL;

Hmm, so asize and ssize are already 32-bit granular. Slightly odd.

> +    prop = fdt_get_property(fdt, node, "reg", &ret);
> +    if ( !prop || ret < sizeof(u32) )
> +        return ret < 0 ? ret : -EINVAL;
> +
> +    /* Get the number of (addr, size) pairs and clamp down. */
> +    count = fdt32_to_cpu(prop->len) / (ssize + asize);

What if there's a remainder?

> +    count = count < pairs ? count : pairs;

Use min()?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 30 15:59:13 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Jan 2025 15:59:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879671.1289885 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdWwY-0000ps-DQ; Thu, 30 Jan 2025 15:59:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879671.1289885; Thu, 30 Jan 2025 15:59:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdWwY-0000pl-AP; Thu, 30 Jan 2025 15:59:02 +0000
Received: by outflank-mailman (input) for mailman id 879671;
 Thu, 30 Jan 2025 15:59:02 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=zr8Z=UW=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tdWwY-0000pf-1R
 for xen-devel@lists.xenproject.org; Thu, 30 Jan 2025 15:59:02 +0000
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com
 [2a00:1450:4864:20::62e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1d8c3927-df23-11ef-99a4-01e77a169b0f;
 Thu, 30 Jan 2025 16:58:58 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-ab6f636d821so16541266b.1
 for <xen-devel@lists.xenproject.org>; Thu, 30 Jan 2025 07:58:58 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab6e47ceadfsm142424966b.51.2025.01.30.07.58.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 30 Jan 2025 07:58:57 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1d8c3927-df23-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738252738; x=1738857538; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=yaxGEw7wpqNZOTN7D5/W+8kGCGRnKxfa7pbUT/Ov1ZM=;
        b=QjaW1m9jBY2tdBYhZ69uSaQrnAgxHIqzjiTIIbEnThTJPPuzl2fIGrk2rJsFXDcwcV
         XapZyxjIN5yqALVh28OekJRkyVXYL61ZaVfPDcfU/AjOaA0TTkaUzCD3RHmc3C6jsGdD
         JvJhpsEAqxMsQLDRAAXgovXQ8b/P5Z9nRrjs1lCe+ONuSrYQ3vsBFztK3D7bLD3d1FYF
         FtxBKGXdLPdExYv2+ky8KssofbEQQv/j0TvD98M/SPEDbf0tKhe9WklmmAQHBF8HZVU1
         VYh3rvfS2ooh6AQTfu5K6lBwiedXPi1cAhEbbkhTSWLoojlgoPDFOBpJrxYzqs+JToLh
         cc+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738252738; x=1738857538;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=yaxGEw7wpqNZOTN7D5/W+8kGCGRnKxfa7pbUT/Ov1ZM=;
        b=fX9lDLCrCSlj2uyJlqdeTQylM+9cjyNbEzYz6NQgealSyjev13bRM4xLofQX26DARx
         FJLzrTWraU0a/ITI2F7O9vzyOxlMKOXXO2ICRhzgV5HJLPXhrBicc4y1YBicISrkGQPC
         eA5xze0ltzvPgA5zex4k4lzf9qYVJNX2jfG0LKUdlIsc3X8IGAD5/1kVWQWdo46D0u20
         0N7lXPJ0op6/oklnA+DAiGWIKvszBBNaKnRVD4n92sKM1SVh53BjRtKWFNNwj7NdteqJ
         QuN6XNCGetAB7d1A7/zXwCV9r0NTW58mRs3ARW8zfuZj1pAFrBGUAL+OUR4TAts9ssHq
         wA8g==
X-Forwarded-Encrypted: i=1; AJvYcCVz7QWerXPd37kKZ4BOdEVcG9BjabFWisegrHmO9/D+l+pnJmHQ+z9YnHAKOfNdxgQj+BUyeaTysDg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwAniPMcfA5Mn39gG427h2ON+aybcmpsELOE3p7gJ+qu7erHxtF
	imskbBSaChaBEpgYDMfT/ch9KHOE2rRQM/Y8ot/QncpWYuLsNSUf5n4PqA9oDQ==
X-Gm-Gg: ASbGncsUV45OqMqQI9IMMtgxoxgZBScZmA8MM0yJcpCQN5BdkDt4otzaHCrb1SF61c4
	VEvOvNDuKEvQC3QvCsInazcnhiagk9plJbEJiTlLiGY1xkxwzAzJn4+Xp9kbkf0hsGOVThs7aYw
	/7n5PZHFJ03PViWC7VZ++Dw9OcUEHXSw3VoSPwUhnbi+XDy8ncCJpTC6YWvbL8paA1IGqslGRLA
	hzyso4XSqJmZB7APCyCId9KmC14BWfEzzYJtv18BCkBCrHgsDu2KXvy9BoxZoJ75OJJqgteJyi/
	Ea8aaEtgaqee8asZh9KYnwvlPvmL4BLt+19GPbiSFlKRAWcXPM0qYmF7OgI5siIuGzWCKuldgUF
	L
X-Google-Smtp-Source: AGHT+IF3KDDv/K7Nr7OwVDml9tGrY8ql2DaxyfQz8TvjMhk6/t8ZygHb4yqjxoe2kVERCgzijx51jw==
X-Received: by 2002:a17:907:9622:b0:ab3:3184:6890 with SMTP id a640c23a62f3a-ab6cfceb881mr849455066b.33.1738252737890;
        Thu, 30 Jan 2025 07:58:57 -0800 (PST)
Message-ID: <d062ed3e-0ded-49c2-a4ff-04ba1ae3244a@suse.com>
Date: Thu, 30 Jan 2025 16:58:56 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 09/15] x86/hyperlaunch: obtain cmdline from device tree
To: "Daniel P. Smith" <dpsmith@apertussolutions.com>
Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com,
 stefano.stabellini@amd.com, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>, xen-devel@lists.xenproject.org
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
 <20241226165740.29812-10-dpsmith@apertussolutions.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20241226165740.29812-10-dpsmith@apertussolutions.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 26.12.2024 17:57, Daniel P. Smith wrote:
> If a command line is not provided through the bootloader's mechanism, e.g.
> muiltboot module string field, then use one from the device tree if present.
> The device tree command line is located in the bootargs property of the
> `multiboot,kernel` node.

This reads as if it can be mix-and-match (and the code looks to confirm
this), which doesn't sound quite right. If you deem it right, please add
justification here.

> --- a/xen/arch/x86/domain-builder/core.c
> +++ b/xen/arch/x86/domain-builder/core.c
> @@ -8,9 +8,37 @@
>  #include <xen/lib.h>
>  
>  #include <asm/bootinfo.h>
> +#include <asm/setup.h>
>  
>  #include "fdt.h"
>  
> +size_t __init builder_get_cmdline_size(struct boot_info *bi, int offset)
> +{
> +#ifdef CONFIG_DOMAIN_BUILDER
> +    const void *fdt = bootstrap_map_bm(&bi->mods[HYPERLAUNCH_MODULE_IDX]);
> +    int size = fdt_cmdline_prop_size(fdt, offset);
> +
> +    bootstrap_unmap();
> +    return size < 0 ? 0 : (size_t) size;

Nit: While I wouldn't insist, we don't normally put blanks after casts.
(The cast also isn't really needed here anyway.)

> +#else
> +    return 0;
> +#endif
> +}
> +
> +int __init builder_get_cmdline(
> +    struct boot_info *bi, int offset, char *cmdline, size_t size)
> +{
> +#ifdef CONFIG_DOMAIN_BUILDER
> +    const void *fdt = bootstrap_map_bm(&bi->mods[HYPERLAUNCH_MODULE_IDX]);
> +    int ret = fdt_cmdline_prop_copy(fdt, offset, cmdline, size);
> +
> +    bootstrap_unmap();
> +    return ret;
> +#else
> +    return 0;
> +#endif
> +}

Such #ifdef-ary is better to be avoided by providing stubs in the header.
Which then also works towards not needing to build in domain-builder/ when
COMFIG_DOMAIN_BUILDER=n.

> --- a/xen/arch/x86/domain-builder/fdt.c
> +++ b/xen/arch/x86/domain-builder/fdt.c
> @@ -109,6 +109,16 @@ static int __init process_domain_node(
>              printk("  kernel: boot module %d\n", idx);
>              bi->mods[idx].type = BOOTMOD_KERNEL;
>              bd->kernel = &bi->mods[idx];
> +
> +            /* If bootloader didn't set cmdline, see if FDT provides one. */
> +            if ( bd->kernel->cmdline_pa &&
> +                 !((char *)__va(bd->kernel->cmdline_pa))[0] )
> +            {
> +                int ret = fdt_get_prop_by_offset(
> +                    fdt, node, "bootargs", &bd->kernel->cmdline_pa);
> +                if ( ret > 0 )
> +                    bd->kernel->fdt_cmdline = true;

Is there a guarantee that fdt_get_prop_by_offset() won't alter its output
(passed in by indirection) in case of failure? Otherwise ...

> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -981,7 +981,10 @@ static size_t __init domain_cmdline_size(
>  {
>      size_t s = bi->kextra ? strlen(bi->kextra) : 0;
>  
> -    s += bd->kernel->cmdline_pa ? strlen(__va(bd->kernel->cmdline_pa)) : 0;
> +    if ( bd->kernel->fdt_cmdline )
> +        s += builder_get_cmdline_size(bi, bd->kernel->cmdline_pa);
> +    else
> +        s += strlen(__va(bd->kernel->cmdline_pa));

... you'll be hosed here (and elsewhere).

> --- a/xen/include/xen/libfdt/libfdt-xen.h
> +++ b/xen/include/xen/libfdt/libfdt-xen.h
> @@ -28,6 +28,30 @@ static inline int __init fdt_cell_as_u64(const fdt32_t *cell, uint64_t *val)
>      return 0;
>  }
>  
> +static inline int __init fdt_get_prop_by_offset(
> +    const void *fdt, int node, const char *name, unsigned long *offset)
> +{
> +    int ret, poffset;
> +    const char *pname;
> +    size_t nsize = strlen(name);
> +
> +    fdt_for_each_property_offset(poffset, fdt, node)
> +    {
> +        fdt_getprop_by_offset(fdt, poffset, &pname, &ret);
> +
> +        if ( ret < 0 || strlen(pname) != nsize )
> +            continue;
> +
> +        if ( !strncmp(pname, name, nsize) )

I find this slightly odd: By now we know strlen(name) == strlen(pname) == nsize.
You could then use the usually more efficient memcmp() or the easier to invoke
strcmp().

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 30 16:39:58 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Jan 2025 16:39:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879683.1289895 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdXa5-0006fl-FY; Thu, 30 Jan 2025 16:39:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879683.1289895; Thu, 30 Jan 2025 16:39:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdXa5-0006fe-Cs; Thu, 30 Jan 2025 16:39:53 +0000
Received: by outflank-mailman (input) for mailman id 879683;
 Thu, 30 Jan 2025 16:39: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 <SRS0=zr8Z=UW=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tdXa4-0006fX-Ke
 for xen-devel@lists.xenproject.org; Thu, 30 Jan 2025 16:39:52 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d2ee3edc-df28-11ef-a0e6-8be0dac302b0;
 Thu, 30 Jan 2025 17:39:50 +0100 (CET)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-5d3f28a4fccso1435376a12.2
 for <xen-devel@lists.xenproject.org>; Thu, 30 Jan 2025 08:39:50 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5dc724a9ed8sm1281791a12.61.2025.01.30.08.39.49
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 30 Jan 2025 08:39:49 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: d2ee3edc-df28-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738255190; x=1738859990; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=LfVdGnCKooI0r7ZU/Sgs4X0u3U37H50hq3ZAceHbRug=;
        b=MkhefnmCLMzirWTVhqZ9lBeW0pIgo7m7OpQgao2ih8ZLvOhm7otlvq/S5q31QAW8gw
         G5UWD7wwxOe+qHyY8H7NnufAFdyjJ0LhyZYMQtLFD4CuLDUzEftLFxAJU9JNLg4Yg9I3
         N4PMfbKWztvzuu+Tk161cdKuI1VboEIMHKYM4lF5ZhYKxJt+AQeLQz94eWXcYEYkFs9y
         HgPUMAZGGo/6sZFxHpDhE6R7Vjp+rP3GA17AImXZPvTH6kEcMAOtwwycRSWCmgq5mGbX
         8HIt0077Rfl47iMO8JMG/0Z/7ZQRIZkSeLzBsrA5C+I+3P6mf4506u/ymC+XjqKtyrCc
         eXIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738255190; x=1738859990;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=LfVdGnCKooI0r7ZU/Sgs4X0u3U37H50hq3ZAceHbRug=;
        b=M12KZAwp1L+o0vc994jQy5rtWQHR83d6kiSmFeyyTHi0lfMcNbcKocosMee083NIGO
         ZpPEgVJ4gQWOLCca4y/+iYOJac6CeFzBihANC7ZPbAdD4LgKXwyH71hAfOhqKH8EZNJ3
         9zwheNZPoJTI/0FsgyHRrxsV3jeyX2BVqIs1rzRxOYRNfjKPxhDRpSwDeTaRQkCiWtXr
         ulCUQ9D4WfM7T40J72oRA4JNtA/hlN2Hc3a4lPBbUnkfwrl0Q46vAioMDDeWKmGNnCkh
         oY6djHAE8hmAAB57PiWOyR5+/dd6jIhRRD7bBQ/PS84AHIIhjWaDqbh/YW4xe5soYSXY
         bJ0g==
X-Forwarded-Encrypted: i=1; AJvYcCVFXUxcCI0LgZbUpMQQKGhGP8jij+jJlyCkrndHOmm70QWqOWVPRvTm0BPcqO/hJeRMZiNP28fBoNU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxFjbtoi+3jeBvVkDDPAPlN0/VJeKh8k5hAuqrFf05DgMY3kwFk
	cuJf3BkmMckaq110NiG/xB8clbFkFgxhWF9gtacB6ArOh5i10FVwp6L3vkCdrg==
X-Gm-Gg: ASbGnctvxQkryXEs6Y6AJJ84hCYWGEfqThBzpbAjkFFsgwhDnc5uBiBTBwymmnR7jnn
	xDHJarxTZKoI4Mh68S8JpDr5kzT9QeayzQC3gO2N+Dgu15rFBmcO3qys5hfcFi8QZIIzEyD8kk5
	JUfwJYeWomWbE6OFsSO9Qv7ACtlvmpRv1N90940TZP+3/anMT68eSd/msza+u1Z+/LdeeoEWkez
	sonNA7/cRvWkuBbISxVqLi2VRoXRyGmdGc9ztqaLgkMS6S4MRSP+zgdoygI+iEJ/FAeXwcriXzy
	/q/KysRUSJSEZeY21wglTFgN8qknPFxc51GvjR89qYLg1N29RmHnhvJlKqdZ67+6QltAlXXyhzC
	l
X-Google-Smtp-Source: AGHT+IEhHJnNgw3Kfo6p3KPXsn4zgmoil0ZrwEVPcYHdF0Y+P37d13EaPnt0nZqrum//feCdB7zOHg==
X-Received: by 2002:a05:6402:354a:b0:5d9:8877:895a with SMTP id 4fb4d7f45d1cf-5dc5efc7608mr7790671a12.17.1738255189771;
        Thu, 30 Jan 2025 08:39:49 -0800 (PST)
Message-ID: <0e36634f-3854-4e64-8514-5c7bdc78c43c@suse.com>
Date: Thu, 30 Jan 2025 17:39:48 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 10/15] x86/hyperlaunch: locate dom0 initrd with
 hyperlaunch
To: "Daniel P. Smith" <dpsmith@apertussolutions.com>
Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com,
 stefano.stabellini@amd.com, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
 <20241226165740.29812-11-dpsmith@apertussolutions.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20241226165740.29812-11-dpsmith@apertussolutions.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 26.12.2024 17:57, Daniel P. Smith wrote:
> Look for a subnode of type `multiboot,ramdisk` within a domain node. If
> found, process the reg property for the MB1 module index.

Unlike for cmdline it doesn't look to be mix-and-match here.

> --- a/xen/arch/x86/domain-builder/fdt.c
> +++ b/xen/arch/x86/domain-builder/fdt.c
> @@ -119,6 +119,32 @@ static int __init process_domain_node(
>                  if ( ret > 0 )
>                      bd->kernel->fdt_cmdline = true;
>              }
> +
> +            continue;
> +        }
> +        else if (
> +            fdt_node_check_compatible(fdt, node, "multiboot,ramdisk") == 0 )

I'm sorry, but this isn't style we use. Perhaps

        else if ( fdt_node_check_compatible(
                      fdt, node, "multiboot,ramdisk") == 0 )

if you dislike

        else if ( fdt_node_check_compatible(fdt, node,
                                            "multiboot,ramdisk") == 0 )

> +        {
> +            int idx = dom0less_module_node(fdt, node, size_size, address_size);
> +            if ( idx < 0 )

Nit: Blank line between declaration(s) and statement(s) please. (Again
at least once elsewhere in this patch.)

> +            {
> +                printk("  failed processing ramdisk module for domain %s\n",
> +                       name);
> +                return -EINVAL;
> +            }
> +
> +            if ( idx > bi->nr_modules )
> +            {
> +                printk("  invalid ramdisk module index for domain node (%d)\n",
> +                       bi->nr_domains);
> +                return -EINVAL;
> +            }

See comments on similar printk()s in an earlier patch.

> @@ -2141,22 +2141,25 @@ void asmlinkage __init noreturn __start_xen(void)
>             cpu_has_nx ? XENLOG_INFO : XENLOG_WARNING "Warning: ",
>             cpu_has_nx ? "" : "not ");
>  
> -    /*
> -     * At this point all capabilities that consume boot modules should have
> -     * claimed their boot modules. Find the first unclaimed boot module and
> -     * claim it as the initrd ramdisk. Do a second search to see if there are
> -     * any remaining unclaimed boot modules, and report them as unusued initrd
> -     * candidates.
> -     */
> -    initrdidx = first_boot_module_index(bi, BOOTMOD_UNKNOWN);
> -    if ( initrdidx < MAX_NR_BOOTMODS )
> +    if ( !bi->hyperlaunch_enabled )

Can't this be "if ( !bi->hyperlaunch_enabled && initrdidx < MAX_NR_BOOTMODS )"
and then all of the churn here can be avoided? An unnecessary call to
first_boot_module_index() is unlikely to be the end of the world. Otherwise ...

>      {
> -        bi->mods[initrdidx].type = BOOTMOD_RAMDISK;
> -        bi->domains[0].ramdisk = &bi->mods[initrdidx];
> -        if ( first_boot_module_index(bi, BOOTMOD_UNKNOWN) < MAX_NR_BOOTMODS )
> -            printk(XENLOG_WARNING
> -                   "Multiple initrd candidates, picking module #%u\n",
> -                   initrdidx);
> +        /*
> +         * At this point all capabilities that consume boot modules should have
> +         * claimed their boot modules. Find the first unclaimed boot module and
> +         * claim it as the initrd ramdisk. Do a second search to see if there are
> +         * any remaining unclaimed boot modules, and report them as unusued initrd
> +         * candidates.
> +         */
> +        unsigned int initrdidx = first_boot_module_index(bi, BOOTMOD_UNKNOWN);
> +        if ( initrdidx < MAX_NR_BOOTMODS )
> +        {
> +            bi->mods[initrdidx].type = BOOTMOD_RAMDISK;
> +            bi->domains[0].ramdisk = &bi->mods[initrdidx];
> +            if ( first_boot_module_index(bi, BOOTMOD_UNKNOWN) < MAX_NR_BOOTMODS )
> +                printk(XENLOG_WARNING
> +                       "Multiple initrd candidates, picking module #%u\n",
> +                       initrdidx);
> +        }

... please pay attention to line length when re-indenting. (If you still need
to re-indent, perhaps also s/unusued/unused/ in the comment, while you touch
it.)

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 30 16:49:53 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Jan 2025 16:49:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879693.1289906 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdXjh-0008OE-6r; Thu, 30 Jan 2025 16:49:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879693.1289906; Thu, 30 Jan 2025 16:49:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdXjh-0008O7-2h; Thu, 30 Jan 2025 16:49:49 +0000
Received: by outflank-mailman (input) for mailman id 879693;
 Thu, 30 Jan 2025 16:49: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 <SRS0=zr8Z=UW=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tdXjg-0008O1-34
 for xen-devel@lists.xenproject.org; Thu, 30 Jan 2025 16:49:48 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 368d8ab4-df2a-11ef-a0e6-8be0dac302b0;
 Thu, 30 Jan 2025 17:49:47 +0100 (CET)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-5d0d32cd31aso1395938a12.0
 for <xen-devel@lists.xenproject.org>; Thu, 30 Jan 2025 08:49: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
 a640c23a62f3a-ab6e4a5ada4sm145011666b.184.2025.01.30.08.49.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 30 Jan 2025 08:49:46 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 368d8ab4-df2a-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738255786; x=1738860586; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=uV1oRjfWeNJ+hcG6a/H7qJp9pizg0klJ3xuXIMWx4Ug=;
        b=GVVZ1XVtm+Tpy4jwsNen5CqM42uTuCwXXJvPFciIW3zvRgeooMB/c7YRncqJI1Z/gn
         F69CkWHZX8jOu+Ig1pLGkKG6/dhOjKVAF6iaTo1Cv3dJBRv0+EBrE5U/PtiilypfaLFu
         VHapoAlYhpQdfEgMmL3QPA2xTwddiEHSC1OFGmbbUIXtmvxk6wz5CuEsisogoJpAKaMI
         KjUv87GUvUW91ICYjxFnAMy1z3xAXxM10gPuE+tkVDFmcMR+U3w72gvQIl42WtshAcXi
         QkYlrnaBx93JnkHMGQOK0bfKSiod2uU/TDz/Lb5y8fBC5Ojc0WlQfHDY23jtCEgwsyvg
         l4bA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738255786; x=1738860586;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=uV1oRjfWeNJ+hcG6a/H7qJp9pizg0klJ3xuXIMWx4Ug=;
        b=KnbTYtiGZkTPrgDaHRqVTrlchwKG86c7CIhbvF8PfDm5dfqA8TB/qQcHjn2r3k4YTC
         2Ph0X0PVhVJzaFCOD5QWCq48Sv0D1cgCajfGKq1vCBWOEE1uhWiSXZwqC0qwMiGxL5nu
         v3PXKXs9PFl1fRBl8C0egFaUKGY7Ge4qKH4Z/aQaALMASJ0VMdS3GamcxOHtBb5YJglK
         XDitNChXTRKyYyrxaPm6ffVPgr2/jhMr4TFoSeiY3RmBxMuXdRDfwaVXkqC4xUr+mijg
         AY/iAO7li6O6sHYqyd8rbD9n7s96oXiIjuH19noqaBCh7d/+jJtnu/YTkt87m04SxGJt
         OBGQ==
X-Forwarded-Encrypted: i=1; AJvYcCWujozEWDFtu0oWbTZx2V3VnCaZy8QWCP6uzzeHP6lJXlcWMZCLY2hEAoekYfyuE8P2IF+juMvdU1M=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwO0S0xztK/1za0g9JdnC0KkzGv8urcy/eMWOFPWueuB4Cz1+0i
	aY/FXz7t5fAJR+iNQriXgBkvI5vTtk5/E0oMmOA6Pq7JfrescMzDtDokuKU3tA==
X-Gm-Gg: ASbGnctWzCly8tW7UCEXrofHzvrEGjz/SVdH6IuVS4wuUv7MXm4EhZYjgf/303sa5vm
	0E1DArdnkpI8hrlc6HQcQvgJQ1xrAX/k70WlJR7k5AyhkyzMBDhqtfnNbuTMEOmcLViz1cED3H4
	dz46cdLnkf2sFEFBQZ/zc5S85/6BBaiHc8ICJ0BwBbEqkkHJtnrMdW6YZdVBDxSoFk+DQb3zJMf
	7Hf1ax8BsnrEs3dFP6El8Bv7hvzQVBuaGQtEpGHkRj5a5L6QWrnbcgJ9O50pKDCoPqJ6Mehlz2E
	/a6zZNBZw5A1ERInnqRsyEwEk3fww8tmcGgnD8LfdZnUqMtIYnmyhiXN0W7auC5zX5KlVNSBNFx
	o
X-Google-Smtp-Source: AGHT+IH6a+b16sacKqOcL3iI6Im174Uqx9gUU94HhX8lN71aD1iw7pjxrH8XsLsx1zo1enGyxyagTQ==
X-Received: by 2002:a05:6402:360f:b0:5dc:7fbe:7305 with SMTP id 4fb4d7f45d1cf-5dc7fbe738amr489877a12.13.1738255786425;
        Thu, 30 Jan 2025 08:49:46 -0800 (PST)
Message-ID: <0c4e53ef-3771-49d8-b63d-4e4439798c32@suse.com>
Date: Thu, 30 Jan 2025 17:49:44 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 11/15] x86/hyperlaunch: add domain id parsing to domain
 config
To: "Daniel P. Smith" <dpsmith@apertussolutions.com>
Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com,
 stefano.stabellini@amd.com, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>, xen-devel@lists.xenproject.org
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
 <20241226165740.29812-12-dpsmith@apertussolutions.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20241226165740.29812-12-dpsmith@apertussolutions.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 26.12.2024 17:57, Daniel P. Smith wrote:
> Introduce the ability to specify the desired domain id for the domain
> definition. The domain id will be populated in the domid property of the domain
> node in the device tree configuration.
> 
> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>

(Not going to repeat style remarks already made on earlier patches. Please
apply throughout the series.)

> @@ -61,10 +62,40 @@ static int __init dom0less_module_index(
>  static int __init process_domain_node(
>      struct boot_info *bi, void *fdt, int dom_node)
>  {
> -    int node;
> +    int node, property;
>      struct boot_domain *bd = &bi->domains[bi->nr_domains];
>      const char *name = fdt_get_name(fdt, dom_node, NULL) ?: "unknown";
>  
> +    fdt_for_each_property_offset(property, fdt, dom_node)
> +    {
> +        const struct fdt_property *prop;
> +        const char *prop_name;
> +        int name_len;
> +
> +        prop = fdt_get_property_by_offset(fdt, property, NULL);
> +        if ( !prop )
> +            continue; /* silently skip */
> +
> +        prop_name = fdt_get_string(fdt, fdt32_to_cpu(prop->nameoff), &name_len);
> +
> +        if ( strncmp(prop_name, "domid", name_len) == 0 )

Isn't this going to (wrongly) match when e.g. the property has just "d" (and
hence name_len is 1).

> +        {
> +            uint32_t val = DOMID_INVALID;
> +            if ( fdt_prop_as_u32(prop, &val) != 0 )
> +            {
> +                printk("  failed processing domain id for domain %s\n", name);
> +                return -EINVAL;
> +            }
> +            if ( val >= DOMID_FIRST_RESERVED )
> +            {
> +                printk("  invalid domain id for domain %s\n", name);
> +                return -EINVAL;
> +            }
> +            bd->domid = (domid_t)val;
> +            printk("  domid: %d\n", bd->domid);
> +        }
> +    }

Perhaps the question comes too early (will be taken care of in later
patches), but still: What if multiple domains have the same ID specified?

> @@ -125,7 +156,29 @@ static int __init process_domain_node(
>          else if (
>              fdt_node_check_compatible(fdt, node, "multiboot,ramdisk") == 0 )
>          {
> -            int idx = dom0less_module_node(fdt, node, size_size, address_size);
> +            unsigned int idx;
> +            int ret = 0;
> +
> +            if ( bd->ramdisk )
> +            {
> +                printk(XENLOG_ERR "Duplicate ramdisk module for domain %s)\n",
> +                       name);
> +                continue;
> +            }
> +
> +            /* Try hyperlaunch property, fall back to dom0less property. */
> +            if ( hl_module_index(fdt, node, &idx) < 0 )
> +            {
> +                int address_size = fdt_address_cells(fdt, dom_node);
> +                int size_size = fdt_size_cells(fdt, dom_node);
> +
> +                if ( address_size < 0 || size_size < 0 )
> +                    ret = -EINVAL;
> +                else
> +                    ret = dom0less_module_index(
> +                            fdt, node, size_size, address_size, &idx);
> +            }

Doesn't this belong into the earlier patch?

> @@ -154,6 +207,12 @@ static int __init process_domain_node(
>          return -EFAULT;
>      }
>  
> +    if ( bd->domid == DOMID_INVALID )
> +        bd->domid = get_initial_domain_id();

Isn't this redundant with ...

> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -1029,8 +1029,9 @@ static struct domain *__init create_dom0(struct boot_info *bi)
>      if ( iommu_enabled )
>          dom0_cfg.flags |= XEN_DOMCTL_CDF_iommu;
>  
> -    /* Create initial domain.  Not d0 for pvshim. */
> -    bd->domid = get_initial_domain_id();
> +    if ( bd->domid == DOMID_INVALID )
> +        /* Create initial domain.  Not d0 for pvshim. */
> +        bd->domid = get_initial_domain_id();

... this?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 30 16:55:35 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Jan 2025 16:55:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879702.1289916 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdXpB-0001bO-Pc; Thu, 30 Jan 2025 16:55:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879702.1289916; Thu, 30 Jan 2025 16:55:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdXpB-0001bH-Mn; Thu, 30 Jan 2025 16:55:29 +0000
Received: by outflank-mailman (input) for mailman id 879702;
 Thu, 30 Jan 2025 16:55:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=zr8Z=UW=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tdXpA-0001bB-CB
 for xen-devel@lists.xenproject.org; Thu, 30 Jan 2025 16:55:28 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 016ae8df-df2b-11ef-a0e6-8be0dac302b0;
 Thu, 30 Jan 2025 17:55:27 +0100 (CET)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-5d3d0205bd5so1487997a12.3
 for <xen-devel@lists.xenproject.org>; Thu, 30 Jan 2025 08:55:27 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab6e4a31f86sm149876566b.145.2025.01.30.08.55.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 30 Jan 2025 08:55:26 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 016ae8df-df2b-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738256127; x=1738860927; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=UL6m9jSOYiRqbqeYE4HaooWlMMzqsQ2C4luuKoEqRTg=;
        b=XXJObWqcQyHOZpRzTewsEz/Yg++sKLd0bi8K6lBp109pgj66pPZnqWyS2MuLOzBmxq
         3pDlqV8zteSACDa0cnYQtUSOCV66knbNV59r+iIwhE/Qzgkzixz6UAylIxTq4zu9AOeJ
         sF/IvMfpFei/xmSmELF4YqxRwvBFPSb73eG+9EMMXaEoWa1pATMxp+NNzvBfuPQW70cl
         91GmhCFkR+V6PQz3USKKX+KX8PIAyd4ESmeMq0dP98RVxe2EyQ9+akWsjvRJaDdTGR7K
         IMLUAVqH13y49Lz8mxWIKqIUwrldz8UzXN1tAM9b9dX0jPc7bcvzUwdw6MbGdcBirbDv
         u8WA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738256127; x=1738860927;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=UL6m9jSOYiRqbqeYE4HaooWlMMzqsQ2C4luuKoEqRTg=;
        b=ZRdP+/CZJssxtzjHsTAQS9eA0xbgq+44VqfgO8ltOvyTVBGSMHGcb460kP0z3ZiN3+
         5qeKGgoC3qo3nmi3vnpkVkkcnDqKsBX6JJsO+DiJNtmDyazbdRzdgdLdmGypBcb1gXz6
         4c4Vn7arLF19+HTI/CAM+gPQuEqWt/Z140HgRpjUDuZIjkUwi6TF6N9CMswg/jDPCNBS
         EG+OYkl/XJaMdjqHdlHPLrpzVAJ/I+wO8IGX/30zdvjpceCHpNl00Xahbr/JK5nzNjpD
         61US0VM+rfyqHL2AudndOpK+QnEJ0aUgasFZB0tY/uD7vnT7GLBqh/dFCu2aPp3GLn62
         sgSg==
X-Forwarded-Encrypted: i=1; AJvYcCVGRchJuSfW9V/OrXrUoRLJeS7xG5+SaHB79OuIJrks9fQJ6EI+tAa0wckucBmY23YvrOAvPVPMshc=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yydems7fg1opqVEZn1BuL5kRYiQcoERrbDFX3H9niHbhXYb/qX4
	cfhx3I1YZMIXYpG28I2cl5NxxMjBeIJ3MEg/o2Qlm7x8o84hlsenMOjCpnXxZQ==
X-Gm-Gg: ASbGnctODDSwLebbokK/glP+X2Akh1bUE+xB/qZ1kcgs1VItIyv4J6cnOvOFU+RfsJ2
	yoSZGLMsG8i8ukXvm4xNrRm9rxmbJK7wr3Am74HdgNtOYsH9wYbWoS2qqpkokmUU6O27EaTjs/r
	yg/NSviWyycL1k9cJT7S2eD8Ex9A7RQZc+yfBCfZO6rqaMJ6Ml6CSDUk/sn831zifTmA1iPQmhu
	hDwrSCz3Kna+C2TpWN3ss/M9j5kudu7v6ZLKsGaVBHYbOseOoBGJQk3zLe2vWlpGjMEjD6glXGm
	DO9JD07D4wfqrk2ZzlqUSMNcB7blNxpACwOUrFSo9FHYT+HPROrTd0F+ejtyZgJBkWDEMVM7+aE
	F
X-Google-Smtp-Source: AGHT+IEgaT4ArUWMiuHdtsbLSX0cyvXhQ5kJIO27/SNuGu0IFB4hRQGWSSHONx2PFzWE6k62kWE+6Q==
X-Received: by 2002:a17:906:794f:b0:ab3:3eea:1ccc with SMTP id a640c23a62f3a-ab6cfd07ca4mr766463966b.27.1738256126790;
        Thu, 30 Jan 2025 08:55:26 -0800 (PST)
Message-ID: <0aadddb9-ee7f-41b5-b271-4716d66330f8@suse.com>
Date: Thu, 30 Jan 2025 17:55:25 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 12/15] x86/hyperlaunch: specify dom0 mode with device
 tree
To: "Daniel P. Smith" <dpsmith@apertussolutions.com>
Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com,
 stefano.stabellini@amd.com, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
 <20241226165740.29812-13-dpsmith@apertussolutions.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20241226165740.29812-13-dpsmith@apertussolutions.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 26.12.2024 17:57, Daniel P. Smith wrote:
> Enable selecting the mode in which the domain will be built and ran. This
> includes:
> 
> - whether it will be either a 32/64 bit domain

I can't spot anything like this in the code changes.

> --- a/xen/arch/x86/domain-builder/fdt.c
> +++ b/xen/arch/x86/domain-builder/fdt.c
> @@ -94,6 +94,25 @@ static int __init process_domain_node(
>              bd->domid = (domid_t)val;
>              printk("  domid: %d\n", bd->domid);
>          }
> +        else if ( strncmp(prop_name, "mode", name_len) == 0 )
> +        {
> +            if ( fdt_prop_as_u32(prop, &bd->mode) != 0 )
> +            {
> +                printk("  failed processing mode for domain %s\n", name);
> +                return -EINVAL;
> +            }
> +
> +            printk("  mode: ");
> +            if ( !(bd->mode & BUILD_MODE_PARAVIRT) )
> +            {
> +                if ( bd->mode & BUILD_MODE_ENABLE_DM )
> +                    printk("HVM\n");
> +                else
> +                    printk("PVH\n");
> +            }
> +            else
> +                printk("PV\n");

Shorter and less indentation as

            if ( bd->mode & BUILD_MODE_PARAVIRT )
                printk("PV\n");
            else if ( bd->mode & BUILD_MODE_ENABLE_DM )
                printk("HVM\n");
            else
                printk("PVH\n");

> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -1016,7 +1016,8 @@ static struct domain *__init create_dom0(struct boot_info *bi)
>      struct boot_domain *bd = &bi->domains[0];
>      struct domain *d;
>  
> -    if ( opt_dom0_pvh )
> +    if ( opt_dom0_pvh ||
> +         (bi->hyperlaunch_enabled && !(bd->mode & BUILD_MODE_PARAVIRT)) )

And then dropping BUILD_MODE_ENABLE_DM on the floor?

Also shouldn't this be

    if ( bi->hyperlaunch_enabled
         ? bd->mode & BUILD_MODE_PARAVIRT
         : opt_dom0_pvh )

as it can't do any good to honor a conflicting command line option.
Command line doc then will want amending to clarify that the option
will be ignored in certain cases.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 30 17:01:27 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Jan 2025 17:01:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879713.1289926 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdXuk-0003DP-By; Thu, 30 Jan 2025 17:01:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879713.1289926; Thu, 30 Jan 2025 17:01:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdXuk-0003DI-9D; Thu, 30 Jan 2025 17:01:14 +0000
Received: by outflank-mailman (input) for mailman id 879713;
 Thu, 30 Jan 2025 17:01:13 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=zr8Z=UW=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tdXuj-0003DC-9z
 for xen-devel@lists.xenproject.org; Thu, 30 Jan 2025 17:01:13 +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 cf0b3c29-df2b-11ef-a0e6-8be0dac302b0;
 Thu, 30 Jan 2025 18:01:12 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-a9e44654ae3so172978066b.1
 for <xen-devel@lists.xenproject.org>; Thu, 30 Jan 2025 09:01:12 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab6e47a7ebdsm151171066b.19.2025.01.30.09.01.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 30 Jan 2025 09:01:06 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: cf0b3c29-df2b-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738256472; x=1738861272; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=H/qZZhv7zDkl6dxtuVktJfjHqNt+FWfiYLykCxjLw8E=;
        b=M5odwVHP21Gelb90mGVyvkn2/vq653+B0kcRuwgKwaRY9sJoPP4ox99JkGhEeOe46U
         Mgh/I8Pc0Ur0ktum2yaArwiVn0HWfzVAVHCIPSkHAlGTRPMbgjt1i5/R6EOuiLpYeC3E
         27Zl8QQNvvptSZgbxoP9shKM8SRmpXW6ai4IDk6D04b2kQL43T7NcQ7EXefmbjVowUkD
         Mi3HEUxmvT0JAm8kpVyKmm/XeedfRSW1G1DFyx67me5lDUbNkfYaERQ11EDsVstORN6K
         8sfg9wmIHWWDGMymmAbGqE7zNGM9dH0lruDYuc+wW2r0AXROx698sNPHqfjvq8UwsV5W
         2c2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738256472; x=1738861272;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=H/qZZhv7zDkl6dxtuVktJfjHqNt+FWfiYLykCxjLw8E=;
        b=T7nyoXTeIEqO0xLhUHT7VguIHrOyo3sXFTKJajr2koqUB4wxbVquf+peF3glufDST4
         0rLA4ZbtxleGth+AmYG2Lw+xLTw9qp4r/rkd5u0yNq+if0iX8wrt18aBD0Ndt0SvET1i
         qm5vDvlj9Z2ci1wnVmxmALkwBES26dyQ7LAcSfHQvf3DCqA2UfIa1jIG6YZ4izcbOn5D
         4YF+UFTnyFEK5nrmTf7UJQ7b/C9VDTOLK10l7eSuIqLJrhZYrskiOE9LxOiiMhVP9sqf
         jHR4dIx692pqVapBhf22zdIXgsyat+7cXUneItRapeh/GjPH/f4tAFuw5nZhZeabRwQP
         ISdA==
X-Forwarded-Encrypted: i=1; AJvYcCVrniZc3/L0gFmfXWj5URzbrYszlVipQH4OmyXH7trw8hm62uc1tcRv/vgMXAv5Ii8pXDU2/k5zOd8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxWHgJOAW21UQelqbGYRbp4dFVRjvu1rG4x9mLdFltV/t1dIb+t
	ztN81bNw87Q/BVgwXXgxkkontV0Mf/1kERdbU6azCTW3eAEsY8cp+/M7inC/BQ==
X-Gm-Gg: ASbGncukKEOwg6ZhOiov/lzaBjRuxC7sZ3ElX7jVzogPm5OUz2u8KwfLRojz56rC8b5
	+KGFSuVNKGBT5Tx8+xhiY4BaXXIaumbsn8AD8pQxHc5qcgbPiF8gGzD5w5qiZnNSZtqj26RobaR
	DItD8h4ALkRslH/Qv/U4agmAqUSsFQTNKDsozvV6G3Gw5UGLJmLnMPIylcD6dEb1wLfHwLgPKsC
	0r4zpV3ylVCkJnuKXjw3rKGen/qIlTcworE4mRKS10EQVtsMdTnmKduGq0JvnsVB335+S7aUgqY
	D4BQftlcbmkGkCt/wulFsS8H2c7Hws/+HSiKNWYbP7+7IrJ7r/eXInGXk7JtEMz4QFLVcdRwGqJ
	x
X-Google-Smtp-Source: AGHT+IGhfuAItdSHr2MvZhq+UICA5QmfbL77u6Bzy9o9QGkgc7O2vmchyiShAsWBvacRT3kjV1Q8ag==
X-Received: by 2002:a17:907:c24c:b0:ab6:e10e:2f5 with SMTP id a640c23a62f3a-ab6e10e06e6mr426508966b.37.1738256466723;
        Thu, 30 Jan 2025 09:01:06 -0800 (PST)
Message-ID: <6806b3cd-aebd-4c18-ba34-783d6faa9529@suse.com>
Date: Thu, 30 Jan 2025 18:01:04 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 13/15] x86/hyperlaunch: add memory parsing to domain
 config
To: "Daniel P. Smith" <dpsmith@apertussolutions.com>
Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com,
 stefano.stabellini@amd.com, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>, xen-devel@lists.xenproject.org
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
 <20241226165740.29812-14-dpsmith@apertussolutions.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20241226165740.29812-14-dpsmith@apertussolutions.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 26.12.2024 17:57, Daniel P. Smith wrote:
> --- a/xen/arch/x86/dom0_build.c
> +++ b/xen/arch/x86/dom0_build.c
> @@ -609,6 +609,14 @@ int __init construct_dom0(struct boot_domain *bd)
>  
>      process_pending_softirqs();
>  
> +    /* If param dom0_size was not set and HL config provided memory size */
> +    if ( !get_memsize(&dom0_size, LONG_MAX) && bd->mem_pages )
> +        dom0_size.nr_pages = bd->mem_pages;
> +    if ( !get_memsize(&dom0_min_size, LONG_MAX) && bd->min_pages )
> +        dom0_size.nr_pages = bd->min_pages;
> +    if ( !get_memsize(&dom0_max_size, LONG_MAX) && bd->max_pages )
> +        dom0_size.nr_pages = bd->max_pages;

Again I don't think it should be mix-and-match: Either everything is
taken from DT, or everything is taken from the command line. Yet I'm
open to be convinced otherwise.

> --- a/xen/include/xen/libfdt/libfdt-xen.h
> +++ b/xen/include/xen/libfdt/libfdt-xen.h
> @@ -37,6 +37,15 @@ static inline int __init fdt_prop_as_u32(
>      return fdt_cell_as_u32((fdt32_t *)prop->data, val);
>  }
>  
> +static inline int __init fdt_prop_as_u64(
> +    const struct fdt_property *prop, uint64_t *val)
> +{
> +    if ( !prop || fdt32_to_cpu(prop->len) < sizeof(u64) )

No new uses of u64 (and alike) please.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 30 17:04:25 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Jan 2025 17:04:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879724.1289935 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdXxn-0003wc-RT; Thu, 30 Jan 2025 17:04:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879724.1289935; Thu, 30 Jan 2025 17:04:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdXxn-0003wV-Os; Thu, 30 Jan 2025 17:04:23 +0000
Received: by outflank-mailman (input) for mailman id 879724;
 Thu, 30 Jan 2025 17:04:21 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=zr8Z=UW=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tdXxl-0003wP-Ln
 for xen-devel@lists.xenproject.org; Thu, 30 Jan 2025 17:04:21 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3eb98a5e-df2c-11ef-99a4-01e77a169b0f;
 Thu, 30 Jan 2025 18:04:19 +0100 (CET)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-5d414b8af7bso2009121a12.0
 for <xen-devel@lists.xenproject.org>; Thu, 30 Jan 2025 09:04:19 -0800 (PST)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5dc72404537sm1351473a12.35.2025.01.30.09.04.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 30 Jan 2025 09:04:18 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 3eb98a5e-df2c-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738256659; x=1738861459; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=PC47WVyukDJfXb7iaySshoMITKzOO/itxgUqAubfeXc=;
        b=IarxStwS/XIoBMGgNPbWTiMrKIZ+8jzelX7aO7FGUT3ivsTfdK+2AffVrFgCl8nw3J
         a9k134QdZT0j2yLdkPamAnp0OdriUuwcw7JlGLzRhVfGfK9z891bGXZmm2QWWy8BlVKP
         XeFhiBMEXDwf+eM+ogUvq3Zwr/3KV6GIOS0RuBI8hUv7oNhlaszB5CJ/jiJL+LSStZpK
         QHg/QYiK6xZ1P4jok2wSvX/JFdQCECD674/B9VNuqqbyBZgfHUEIq9vj2q+GON/BqJ82
         wNl/i6B7zELSysfRoPwZt67JBvh1MjYYMRrOxdDhzi53//tFSJHsAMMcE+oR9YJE53dA
         WcPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738256659; x=1738861459;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=PC47WVyukDJfXb7iaySshoMITKzOO/itxgUqAubfeXc=;
        b=b5YEsizEe+5GUUcFbrgzkvwd7OFQn5Tz69uDh6Yxjloqx/rGM7s/VJzjvk9nl4LxAU
         mxYOQc2c9Et/rK/UPg4+SKl0Np2VfuCox2pzoXLkhBU9QsA5EUZUm41NIH7LADAdBZuj
         urfwJhp7/kZLLbWYnlqq3mekZTFC6zzbIZ90aQwevcNpiyplyBrE6MaR0Mky3F1GGaMh
         CxdpR29Oa1hT7m11a4GNVH5gL9rJZDgMevEZy/z602m6ctgRpmMNhk6zQmFqdrItoh+G
         yOBMfNnpTg9ppudTALSO2sxVVXPCXu8tNa4kedBjIW1WeV+1IlIJ7AmIx2kHT6uwWZB0
         tu1g==
X-Forwarded-Encrypted: i=1; AJvYcCUK5+ci0qZg7qjuS6zCepCuhFCopAkCCMJHLc/39naZKmCuukaKje758eE3vz0KOhBUM52awc7kB1s=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxOzYH7mlX4s/Uy4fbmuw5wH2oxfeeFwgHoAqSzVGqq990HQ29f
	QLZiLTTjmg+Ph30IQHUgqPccbnJBGsD74iLyqfEoIDj0bNGvDvlBlhCl+oOqFw==
X-Gm-Gg: ASbGncubzjtFqYlavkaHLmYsZy20YyLG8ILlPB2b7gZIfEYl4Kjpk24az9hN7lbfSdy
	rmesQcJWvkeWTOaL1vT3qq2hsxTaQZ42Yusz9H+/Mbx4vcq6xt3+WC7uEJqScrlf+oIWuYQEI2T
	y8qn11khbCSqln1p+Yhj91dBvANsFZ6uCACdRGf6VBwlbpIZjFdwW3t+thJmqbQHlJuH0WwBzfV
	DMaITFtG2txi/riIk3ZMTBKemsnDE3y8gq+3GWTbmBD1d2V9NSTsXh5MIE5JIAkAKbZKe+gWW6r
	8rOh6/FC7ZO8S3c+qIz9aLs/qmkE+C554f8qiRiIyvE449Hyyj7abLkm+iUplhtlma3hSlWUHLM
	h
X-Google-Smtp-Source: AGHT+IHX4RrZ/YQf7/2vnz5JmKaTw6yyPmnpPjqbCFDKmTkPhVVt1Lh4C62dX9pGdoxrNh6ix4W7xQ==
X-Received: by 2002:a05:6402:2812:b0:5d3:ba42:e9f4 with SMTP id 4fb4d7f45d1cf-5dc5f00850fmr8323957a12.23.1738256659124;
        Thu, 30 Jan 2025 09:04:19 -0800 (PST)
Message-ID: <9282f971-a500-4c05-b99b-c7bae72709ff@suse.com>
Date: Thu, 30 Jan 2025 18:04:17 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 14/15] x86/hyperlaunch: add max vcpu parsing of
 hyperlaunch device tree
To: "Daniel P. Smith" <dpsmith@apertussolutions.com>
Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com,
 stefano.stabellini@amd.com, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 xen-devel@lists.xenproject.org
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
 <20241226165740.29812-15-dpsmith@apertussolutions.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20241226165740.29812-15-dpsmith@apertussolutions.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 26.12.2024 17:57, Daniel P. Smith wrote:
> --- a/xen/arch/x86/domain-builder/fdt.c
> +++ b/xen/arch/x86/domain-builder/fdt.c
> @@ -147,6 +147,17 @@ static int __init process_domain_node(
>              bd->max_pages = PFN_DOWN(kb * SZ_1K);
>              printk("  max memory: %ld kb\n", kb);
>          }
> +        else if ( strncmp(prop_name, "cpus", name_len) == 0 )
> +        {
> +            uint32_t val = UINT_MAX;

It's not the first time I see such an initializer, yet it's even more
pronounced here, as the call ...

> +            if ( fdt_prop_as_u32(prop, &val) != 0 )

... is coming right next. If that function succeeds, it surely should
set its output? And if it didn't, you're as hosed with initializer as
you're without.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jan 30 18:15:09 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Jan 2025 18:15:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879734.1289945 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdZ42-0004OH-SK; Thu, 30 Jan 2025 18:14:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879734.1289945; Thu, 30 Jan 2025 18:14:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdZ42-0004OA-Ov; Thu, 30 Jan 2025 18:14:54 +0000
Received: by outflank-mailman (input) for mailman id 879734;
 Thu, 30 Jan 2025 18: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
 <SRS0=URkf=UW=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tdZ41-0004O3-P6
 for xen-devel@lists.xenproject.org; Thu, 30 Jan 2025 18:14:53 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 179f310a-df36-11ef-99a4-01e77a169b0f;
 Thu, 30 Jan 2025 19:14:50 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 3F8305C61AB;
 Thu, 30 Jan 2025 18:14:08 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 89246C4CEE2;
 Thu, 30 Jan 2025 18:14:46 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 179f310a-df36-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1738260888;
	bh=0UcRcKHAoImktBj185XdlHn+UMI2y8OBYg2X+QmV7Pg=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=i1Fi7V2RcFfGMeMTuGd8eC2nw2FscSeX13lRojr76AEzeR9/ZEURXa+iqK6MdYi8H
	 lvSpblkvispW6sIUU30f5S+uUDu3q/q+jDRIDlJLrGbiv/NKnedn7zuZi0FmaU3Rmi
	 46ZRhUgvP7B3p4dkIg5JmuKehF3wh6QraHEKlbXuhfg3v1dcnkGOn5mv0C76xkYB01
	 HevwYPct2Rh+UecoBZVfL9s6L6/q9Un8WJfbxlFgeJ/fQ2pGs5vR8Tsxu8NJiqExyc
	 m3DQzdD5j7wcJ0PQ51htLPlUWxsvI3nKpgvc6JakT6TtuQXIsejwDhpEVQuJJFTHtc
	 jUWeNBU73o1bQ==
Date: Thu, 30 Jan 2025 10:14:44 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Stefano Stabellini <sstabellini@kernel.org>
cc: "Edgar E. Iglesias" <edgar.iglesias@amd.com>, Olaf Hering <olaf@aepfle.de>, 
    xen-devel@lists.xenproject.org, jgross@suse.com, 
    Anthony PERARD <anthony@xenproject.org>, Paul Durrant <paul@xen.org>, 
    jbeulich@suse.com, andrew.cooper3@citrix.com, roger.pau@citrix.com
Subject: Re: slow start of Pod HVM domU with qemu 9.1
In-Reply-To: <alpine.DEB.2.22.394.2501291429040.11632@ubuntu-linux-20-04-desktop>
Message-ID: <alpine.DEB.2.22.394.2501301014400.11632@ubuntu-linux-20-04-desktop>
References: <20250128151544.26fc827d.olaf@aepfle.de> <Z5j-bkdFZ7riavv7@zapote> <alpine.DEB.2.22.394.2501281543580.3264561@ubuntu-linux-20-04-desktop> <Z5oIvUINVDfrrVla@zapote> <alpine.DEB.2.22.394.2501291429040.11632@ubuntu-linux-20-04-desktop>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Wed, 29 Jan 2025, Stefano Stabellini wrote:
> On Wed, 29 Jan 2025, Edgar E. Iglesias wrote:
> > On Tue, Jan 28, 2025 at 03:58:14PM -0800, Stefano Stabellini wrote:
> > > On Tue, 28 Jan 2025, Edgar E. Iglesias wrote:
> > > > On Tue, Jan 28, 2025 at 03:15:44PM +0100, Olaf Hering wrote:
> > > > > Hello,
> > > > > 
> > > > > starting with qemu 9.1 a PoD HVM domU takes a long time to start.
> > > > > Depending on the domU kernel, it may trigger a warning, which prompted me
> > > > > to notice this change in behavior:
> > > > > 
> > > > > [    0.000000] Linux version 4.12.14-120-default (geeko@buildhost) (gcc version 4.8.5 (SUSE Linux) ) #1 SMP Thu Nov 7 16:39:09 UTC 2019 (fd9dc36)
> > > > > ...
> > > > > [    1.096432] HPET: 3 timers in total, 0 timers will be used for per-cpu timer
> > > > > [    1.101636] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
> > > > > [    1.104051] hpet0: 3 comparators, 64-bit 62.500000 MHz counter
> > > > > [   16.136086] random: crng init done
> > > > > [   31.712052] BUG: workqueue lockup - pool cpus=1 node=0 flags=0x0 nice=0 stuck for 30s!
> > > > > [   31.716029] Showing busy workqueues and worker pools:
> > > > > [   31.721164] workqueue events: flags=0x0
> > > > > [   31.724054]   pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=2/256
> > > > > [   31.728000]     in-flight: 17:balloon_process
> > > > > [   31.728000]     pending: hpet_work
> > > > > [   31.728023] workqueue mm_percpu_wq: flags=0x8
> > > > > [   31.732987]   pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=1/256
> > > > > [   31.736000]     pending: vmstat_update
> > > > > [   31.736024] pool 2: cpus=1 node=0 flags=0x0 nice=0 hung=30s workers=2 idle: 34
> > > > > [   50.400102] clocksource: Switched to clocksource xen
> > > > > [   50.441153] VFS: Disk quotas dquot_6.6.0
> > > > > ...
> > > > > 
> > > > > With qemu 9.0 and older, this domU will start the /init task after 8 seconds.
> > > > > 
> > > > > The change which caused this commit is qemu.git commit 9ecdd4bf08dfe4a37e16b8a8b228575aff641468
> > > > > Author:     Edgar E. Iglesias <edgar.iglesias@amd.com>
> > > > > AuthorDate: Tue Apr 30 10:26:45 2024 +0200
> > > > > Commit:     Edgar E. Iglesias <edgar.iglesias@amd.com>
> > > > > CommitDate: Sun Jun 9 20:16:14 2024 +0200
> > > > > 
> > > > >     xen: mapcache: Add support for grant mappings
> > > > > 
> > > > > As you can see, v4 instead of v5 was apparently applied.
> > > > > This was probably unintentional, but would probably not change the result.
> > > > 
> > > > Hi Olaf,
> > > > 
> > > > It looks like v8 was applied, or am I missing something?
> > > > 
> > > > 
> > > > > 
> > > > > With this change the domU starts fast again:
> > > > > 
> > > > > --- a/hw/xen/xen-mapcache.c
> > > > > +++ b/hw/xen/xen-mapcache.c
> > > > > @@ -522,6 +522,7 @@ ram_addr_t xen_ram_addr_from_mapcache(void *ptr)
> > > > >      ram_addr_t addr;
> > > > >  
> > > > >      addr = xen_ram_addr_from_mapcache_single(mapcache, ptr);
> > > > > +    if (1)
> > > > >      if (addr == RAM_ADDR_INVALID) {
> > > > >          addr = xen_ram_addr_from_mapcache_single(mapcache_grants, ptr);
> > > > >      }
> > > > > @@ -626,6 +627,7 @@ static void xen_invalidate_map_cache_entry_single(MapCache *mc, uint8_t *buffer)
> > > > >  static void xen_invalidate_map_cache_entry_all(uint8_t *buffer)
> > > > >  {
> > > > >      xen_invalidate_map_cache_entry_single(mapcache, buffer);
> > > > > +    if (1)
> > > > >      xen_invalidate_map_cache_entry_single(mapcache_grants, buffer);
> > > > >  }
> > > > >  
> > > > > @@ -700,6 +702,7 @@ void xen_invalidate_map_cache(void)
> > > > >      bdrv_drain_all();
> > > > >  
> > > > >      xen_invalidate_map_cache_single(mapcache);
> > > > > +    if (0)
> > > > >      xen_invalidate_map_cache_single(mapcache_grants);
> > > > >  }
> > > > >  
> > > > > I did the testing with libvirt, the domU.cfg equivalent looks like this:
> > > > > maxmem = 4096
> > > > > memory = 2048
> > > > > maxvcpus = 4
> > > > > vcpus = 2
> > > > > pae = 1
> > > > > acpi = 1
> > > > > apic = 1
> > > > > viridian = 0
> > > > > rtc_timeoffset = 0
> > > > > localtime = 0
> > > > > on_poweroff = "destroy"
> > > > > on_reboot = "destroy"
> > > > > on_crash = "destroy"
> > > > > device_model_override = "/usr/lib64/qemu-9.1/bin/qemu-system-i386"
> > > > > sdl = 0
> > > > > vnc = 1
> > > > > vncunused = 1
> > > > > vnclisten = "127.0.0.1"
> > > > > vif = [ "mac=52:54:01:23:63:29,bridge=br0,script=vif-bridge" ]
> > > > > parallel = "none"
> > > > > serial = "pty"
> > > > > builder = "hvm"
> > > > > kernel = "/bug1236329/linux"
> > > > > ramdisk = "/bug1236329/initrd"
> > > > > cmdline = "console=ttyS0,115200n8 quiet ignore_loglevel""
> > > > > boot = "c" 
> > > > > disk = [ "format=qcow2,vdev=hda,access=rw,backendtype=qdisk,target=/bug1236329/sles12sp5.qcow2" ]
> > > > > usb = 1
> > > > > usbdevice = "tablet"
> > > > > 
> > > > > Any idea what can be done to restore boot times?
> > > > 
> > > > 
> > > > A guess is that it's taking a long time to walk the grants mapcache
> > > > when invalidating (in QEMU). Despite it being unused and empty. We
> > > > could try to find a way to keep track of usage and do nothing when
> > > > invalidating an empty/unused cache.
> > > 
> > > If mapcache_grants is unused and empty, the call to
> > > xen_invalidate_map_cache_single(mapcache_grants) should be really fast?
> > 
> > Yes, I agree but looking at the invalidation code it looks like if we're
> > unconditionally walking all the buckets in the hash-table...
> > 
> > 
> > > 
> > > I think probably it might be the opposite: mapcache_grants is utilized,
> > > so going through all the mappings in xen_invalidate_map_cache_single
> > > takes time.
> > 
> > The reason I don't think it's being used is because we've only enabled
> > grants for PVH machines and Olaf runs HVM machines, so QEMU would never
> > end up mapping grants for DMA.
>  
> Oh, I see! In that case we could have a trivial check on mc->last_entry
> == NULL as fast path, something like:
> 
> if ( mc->last_entry == NULL )
>     return;
> 
> at the beginning of xen_invalidate_map_cache_single?
>  
>  
> > > However, I wonder if it is really needed. At least in the PoD case, the
> > > reason for the IOREQ_TYPE_INVALIDATE request is that the underlying DomU
> > > memory has changed. But that doesn't affect the grant mappings, because
> > > those are mappings of other domains' memory.
> > > 
> > > So I am thinking whether we should remove the call to
> > > xen_invalidate_map_cache_single(mapcache_grants) ?
> > 
> > Good point!
>  
> Let's see how the discussion evolves on that point

Jan and Juergen clarified that there is no need to call
xen_invalidate_map_cache_single for grants on IOREQ_TYPE_INVALIDATE
requests.

---
xen: no need to flush the mapcache for grants

On IOREQ_TYPE_INVALIDATE we need to invalidate the mapcache for regular
mappings. Since recently we started reusing the mapcache also to keep
track of grants mappings. However, there is no need to remove grant
mappings on IOREQ_TYPE_INVALIDATE requests, we shouldn't do that. So
remove the function call.

Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>

diff --git a/hw/xen/xen-mapcache.c b/hw/xen/xen-mapcache.c
index 00bfbcc6fb..698b5c53ed 100644
--- a/hw/xen/xen-mapcache.c
+++ b/hw/xen/xen-mapcache.c
@@ -700,7 +700,6 @@ void xen_invalidate_map_cache(void)
     bdrv_drain_all();
 
     xen_invalidate_map_cache_single(mapcache);
-    xen_invalidate_map_cache_single(mapcache_grants);
 }
 
 static uint8_t *xen_replace_cache_entry_unlocked(MapCache *mc,


From xen-devel-bounces@lists.xenproject.org Thu Jan 30 20:17:23 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Jan 2025 20:17:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879745.1289955 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdayN-0001Ey-BP; Thu, 30 Jan 2025 20:17:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879745.1289955; Thu, 30 Jan 2025 20:17:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdayN-0001Er-8e; Thu, 30 Jan 2025 20:17:11 +0000
Received: by outflank-mailman (input) for mailman id 879745;
 Thu, 30 Jan 2025 20:17:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=5/JT=UW=amd.com=Jason.Andryuk@srs-se1.protection.inumbo.net>)
 id 1tdayL-0001El-Cl
 for xen-devel@lists.xenproject.org; Thu, 30 Jan 2025 20:17:09 +0000
Received: from NAM02-DM3-obe.outbound.protection.outlook.com
 (mail-dm3nam02on20607.outbound.protection.outlook.com
 [2a01:111:f403:2405::607])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2c182ab4-df47-11ef-a0e6-8be0dac302b0;
 Thu, 30 Jan 2025 21:17:06 +0100 (CET)
Received: from BY5PR17CA0063.namprd17.prod.outlook.com (2603:10b6:a03:167::40)
 by CY5PR12MB6624.namprd12.prod.outlook.com (2603:10b6:930:40::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8398.20; Thu, 30 Jan
 2025 20:17:02 +0000
Received: from CO1PEPF000042AA.namprd03.prod.outlook.com
 (2603:10b6:a03:167:cafe::98) by BY5PR17CA0063.outlook.office365.com
 (2603:10b6:a03:167::40) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8398.18 via Frontend Transport; Thu,
 30 Jan 2025 20:17:01 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CO1PEPF000042AA.mail.protection.outlook.com (10.167.243.39) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8398.14 via Frontend Transport; Thu, 30 Jan 2025 20:17:01 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 30 Jan
 2025 14:17:01 -0600
Received: from [192.168.195.178] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Thu, 30 Jan 2025 14:17:00 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 2c182ab4-df47-11ef-a0e6-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=KUvNDmS+ZMJDhVixfEGTmG3GnO2oitsCjqbZqOnxlCYbQFTXEHnPcx1D4uJJVvNAKypAb9uNe6oJvfajaPFRHr5HMpAQ9GAMZwX5jRpAGidblO2qEDXLHjVmiS/Ryal0YCM+j2dqNlYUkZYPhVQT8SOg9MgNdaraQbEm5Pf+MTh+G6cyoJwFNeNnZF0htERmqSgcGB4OOkDgD69d6XMtmOGEmk+7YA9OAArFU2y6ai5m5e7iw2/myJsMuXblfVFO2JhJeCDbxQIODNlpkWWo5bCJlNCtX0P9vm+0Lraz4e1nRp3qT5ZIklir6n6wfWFU22e6YT2IxPPP/+9EWgabxg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=O99zEQuAGJEov1QDHpiKvSyQOqTcgqLzoiZX6jyfpfI=;
 b=X5ufYE/2ODjhxbKlJDGaEjEWVi9m5Nkevd3kiZDXmRkjk5zMJYSXwM9wsKCA1koINO3OIcXB1m2ZOo8BwTV7ZcAjtFtLcya9xmMOsRkWyELd/AbDuwAYcS3Zxdwwytk/UPohACkrb3b58XmaL3fQfV3GqLOryMlj++1tXGyu1UBIMb7ry2V6Bg3XwUTcSbtb8frVAW6wppP22e4zNKw1NrXfA3U7S8wOyOZ1/0SITdtIkc83VqlZzfTqvd2WlSQraPVxRiEncNvRSH5DpiQ/84+DwYwo+U2EN1iwLhK2NoWjchwTdlC6oow7UgMLqCHSMqKkt5sH/HVUHsmpMT3Eyw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=vates.tech smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=O99zEQuAGJEov1QDHpiKvSyQOqTcgqLzoiZX6jyfpfI=;
 b=y1fwI2ePkgPnvUkeyh6WXJ8f6EP8bT9oq4Hf3zS8qoRweh7D6E86xsm8My1ATsEBFWEbrGKkKRlU3E4rPsDMoaNtpdg2PKVc8Y/L6TCM3Glg1TKfe0DzYJi3DZDvMC7x/MEB+bWh6spyjTdd/wgUJDdJaDw+sT+Xct2zRq0gnhg=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <1ea6447c-3451-4aca-8a17-2848acd0868f@amd.com>
Date: Thu, 30 Jan 2025 15:17:01 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN RFC PATCH v5 3/5] xen/public: Introduce PV-IOMMU hypercall
 interface
To: Teddy Astie <teddy.astie@vates.tech>, <xen-devel@lists.xenproject.org>
CC: Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich
	<jbeulich@suse.com>, Julien Grall <julien@xen.org>, Stefano Stabellini
	<sstabellini@kernel.org>, =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
	<marmarek@invisiblethingslab.com>
References: <cover.1737470269.git.teddy.astie@vates.tech>
 <29f3e87532573bfc4196083ab0291326adae5100.1737470269.git.teddy.astie@vates.tech>
Content-Language: en-US
From: Jason Andryuk <jason.andryuk@amd.com>
In-Reply-To: <29f3e87532573bfc4196083ab0291326adae5100.1737470269.git.teddy.astie@vates.tech>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB04.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CO1PEPF000042AA:EE_|CY5PR12MB6624:EE_
X-MS-Office365-Filtering-Correlation-Id: 561c6b4c-64e6-4cb0-c035-08dd416b0e6d
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|376014|1800799024|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?emJnNVBMQ0tBQnZETTFjZ0NRT293WUlzSEhyNHNGVXRDTWdPbzNxMElqeWxa?=
 =?utf-8?B?ZThVRGVRVGFaR1ByZnUrL1B1QThkT3htMUxpL05LODlTZlp6Y1NsWnpqbW9G?=
 =?utf-8?B?Zi9YLzVCblZtamJZMHBhTXQ5dG13QWpuZmtJU0hLbkVvbGduRVlPZW9oMUMy?=
 =?utf-8?B?aU1KNkF3ZGFBWlZsNk9WMnhTSTlwZnhpTExxemZQb2xOTHRQZWtjQk5zU1B4?=
 =?utf-8?B?a2I1SGxmdE15YVpYODVIb29JbG1lQk8yMXRLZXg0V1dhWXZpMjMxR3prWCtQ?=
 =?utf-8?B?Z2dOdWFBTm9XT3MrZjNMM2hJRXNONHk5WG4zSHJEb2dxRGZGS3V4SFozYVZX?=
 =?utf-8?B?VmtycGZLVHNCTTRFeUExdEJiSHpNWUIxYllGdDZuVHY4aG9Cd1dwUXhXbDBD?=
 =?utf-8?B?eCtDMDdRV29PQjRhMFFyTmJxbzVFaStDcGxNeHNPVmJDMVZFR1MvMVpNSC9E?=
 =?utf-8?B?WVY1TzlLVVVXRWwvV2xWZ3l3SzlndnQ5VUZLekU2N0dsVzIxY3VtUk9XU3cx?=
 =?utf-8?B?MDllUEc5dHR6MURHWXpXQ2xnUm9sZ0RlRnFUOXlnMVYvNU5FekhzN1JnU2NS?=
 =?utf-8?B?WmE0SGd5K21PaWd1QzZjUFdSWi9zSDV0b3d1V2ozODdUc001Zjh3NmtVWmxD?=
 =?utf-8?B?VXhkdlBjSGUvZnc0UUltUzY1c21ZcG0ya3lrWHM0RDBUNzgvQS82VU5zd2xQ?=
 =?utf-8?B?ZmEvb1ozNG41M0paUmdtaGlza0FnTW9FRlFRbzNsTWYxaWl2VEpVWE9UaDBX?=
 =?utf-8?B?OE1KRGNWUUJCajJnV1lxQ3NmbnFtOTZiUVZYRUhTeGR1L0kydEl1VklyajBD?=
 =?utf-8?B?R2RRdkZ4WldaeGRsR2libU0wSnY3UTV3aVhYQ1d3dytMSGwxWG1oakl3dTRy?=
 =?utf-8?B?RzF4TXRPN3dpNGUrTzNBb0s4N3JWU2tDQWR2VFVsWnhsRHl2V2tzS0VraHFh?=
 =?utf-8?B?OVZoTGtuaHF4Unc1MUpoWGE1ait5bUxqNlVkS3l5OHpyNFZTd04rZ2VTRGVI?=
 =?utf-8?B?dGc2cEh1bUcxdlBSSFBNQmwzWGFJR0J0RlNvdzRjUzB6Y1hJY0NzZWZ4OE1o?=
 =?utf-8?B?K3JjR2lrMVZyL3N0aSt1WmJzYnZEbXYyV2lJRE8vV1N5bnlmQjJlN3JsRkpD?=
 =?utf-8?B?MGpFZDhoZzlLRE9LaDZ1eFpWdUUvSVRQRW15TkUrNUJRS0I1a0hPY1pQeUU1?=
 =?utf-8?B?dlBWYnB3dFR5YmFsc0lxMXhndEN2cmZPV2dPaFRIVDhkRld6d1lIOURSRHMx?=
 =?utf-8?B?N2ZSSnJnTlBEYU1xbmVlNjNyWHE0MWtOYTVENVFnb0Q3ZnZCYUdNQjVLa1hG?=
 =?utf-8?B?amN2c0NEZGNlQzgxRVEzcWNJQm9oTWpUNitSVnR5VVc0djQ0bW5CMHlDSWhE?=
 =?utf-8?B?WlFaWC9UUGpQMDZJQW8zR1c1TGdhYzBmWlh6RDhjY1lBZ1liOWhJdys5L25V?=
 =?utf-8?B?OG5HaXFIRlZFRC8zMXVhR2RUN0JSbHIwMEEySjVwaERyTDF5UUVXQk4wRnUw?=
 =?utf-8?B?QmtzYTNmRmI4VHc4bnZwNFRaWnBTTUcybGtqM2JQMlRQek9iSUtIdFdZZTB5?=
 =?utf-8?B?SHJFT3N3VGEvVkMrRmVFeVpvcXB0RCtkbUVRTGtac3lXcVZFZlJhZFBJaW5E?=
 =?utf-8?B?Y1lTMXYvZ3Zick5YZnJKSWxpVk91ZnJiK3dVL0dSUFd0VGNSMnQvU0lxekJS?=
 =?utf-8?B?eXg2ZEJKc21MT1lwTU9WUmYrdWZtTEx5cFBrTTFLSE5jMFJoV2hmL2FBS2hR?=
 =?utf-8?B?WHM1M0J0M1hDeHRCcHdOSTBkbnR4cGxma3N2NFh4RlNiSklQSkUyN0cvcFNk?=
 =?utf-8?B?T2oxamNuMzM3cGZneUJkUWVOQ1h1Ym1oU21ZcnhRVjhYU1A5WE54QWZkLzZk?=
 =?utf-8?B?TXZtSGN4bWhrYUk3Ly9IQXhRcmRyU3VFOUVCaXExQ3FBT2x6QWxxeVFHOCtD?=
 =?utf-8?B?Nkx3QW8vUUh5M0FVT2dNcDZXbWgrcDRpbG1kc0NTZk4wWm5KaTJPVWdGRVZG?=
 =?utf-8?B?ZG5za1JtNWJ3PT0=?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(1800799024)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jan 2025 20:17:01.4139
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 561c6b4c-64e6-4cb0-c035-08dd416b0e6d
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CO1PEPF000042AA.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR12MB6624

Hi Teddy,

Thanks for working on this.  I'm curious about your plans for this:

On 2025-01-21 11:13, Teddy Astie wrote:
> +/**
> + * IOMMU_alloc_nested
> + * Create a nested IOMMU context (needs IOMMUCAP_nested).
> + *
> + * This context uses a platform-specific page table from domain address space
> + * specified in pgtable_gfn and use it for nested translations.
> + *
> + * Explicit flushes needs to be submited with IOMMU_flush_nested on
> + * modification of the nested pagetable to ensure coherency between IOTLB and
> + * nested page table.
> + *
> + * This context can be destroyed using IOMMU_free_context.
> + * This context cannot be modified using map_pages, unmap_pages.
> + */
> +struct pv_iommu_alloc_nested {
> +    /* OUT: allocated IOMMU context number */
> +    uint16_t ctx_no;
> +
> +    /* IN: guest frame number of the nested page table */
> +    uint64_aligned_t pgtable_gfn;
> +
> +    /* IN: nested mode flags */
> +    uint64_aligned_t nested_flags;
> +};
> +typedef struct pv_iommu_alloc_nested pv_iommu_alloc_nested_t;
> +DEFINE_XEN_GUEST_HANDLE(pv_iommu_alloc_nested_t);

Is this command intended to be used for GVA -> GPA translation?  Would 
you need some way to associate with another iommu context for GPA -> HPA 
translation?

Maybe more broadly, what are your goals for enabling PV-IOMMU?  The 
examples on your blog post cover a domain restrict device access to 
specific portions of the the GPA space.  Are you also interested in GVA 
-> GPA?  Does VFIO required GVA -> GPA?

And, sorry to bike shed, but ctx_no reads like "Context No" to me.  I 
think ctxid/ctx_id might be clearer.  Others probably have their own 
opinions :)

Thanks,
Jason


From xen-devel-bounces@lists.xenproject.org Thu Jan 30 20:28:12 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Jan 2025 20:28:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879753.1289965 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdb8y-0002sH-Ab; Thu, 30 Jan 2025 20:28:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879753.1289965; Thu, 30 Jan 2025 20:28:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdb8y-0002sA-81; Thu, 30 Jan 2025 20:28:08 +0000
Received: by outflank-mailman (input) for mailman id 879753;
 Thu, 30 Jan 2025 20:28: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
 <SRS0=URkf=UW=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tdb8w-0002s4-Lv
 for xen-devel@lists.xenproject.org; Thu, 30 Jan 2025 20:28:06 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org
 [2604:1380:4641:c500::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b5331243-df48-11ef-a0e6-8be0dac302b0;
 Thu, 30 Jan 2025 21:28:05 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 76A905C501F;
 Thu, 30 Jan 2025 20:27:23 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id C64CCC4CEE4;
 Thu, 30 Jan 2025 20:28:01 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b5331243-df48-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1738268883;
	bh=p9nVrigsDYKicwkfzbW1Xes5NHnGUH3hN9svLzouh8Q=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=HWZH8ahgB9vx8+j2xBmxLOgm/lRsFpULHlwwbuM3e7CmaCIy6OtCK9mfeiRlax8p0
	 fw0S/FZLbB6ohnL9+Yvw/7Ib9hEq6T2dT07pBk6yBFfZ9JerJ1AapMsYmswZqYJ1Td
	 8LBPM30TI7oU059pdPqOwq3pQKPbtjojjD78VNoQsKbs0WTf6LNsS8I42R5CSAulpf
	 RRSihr6ry39uarymYt9lNPj0OimRKczyTUqUuhYoBL17i5gTyFN4+MszolUtxw/cnx
	 jj94tHlLOGcpaIIuGpIz2MeQvZYbjlnBz40SnmVZZK1kLyFmdKCrn4iZeTg/G4Hv3z
	 CNrbsI1C57kew==
Date: Thu, 30 Jan 2025 12:28:00 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: =?UTF-8?Q?J=C3=BCrgen_Gro=C3=9F?= <jgross@suse.com>
cc: Harshvardhan Jha <harshvardhan.j.jha@oracle.com>, 
    Greg KH <gregkh@linuxfoundation.org>, Konrad Wilk <konrad.wilk@oracle.com>, 
    Boris Ostrovsky <boris.ostrovsky@oracle.com>, 
    "sstabellini@kernel.org" <sstabellini@kernel.org>, 
    "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, 
    "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, 
    Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>, 
    stable@vger.kernel.org
Subject: Re: v5.4.289 failed to boot with error megasas_build_io_fusion 3219
 sge_count (-12) is out of range
In-Reply-To: <5a7d969b-b2ab-4fac-b95e-4a536e2c8d5c@suse.com>
Message-ID: <alpine.DEB.2.22.394.2501301226330.11632@ubuntu-linux-20-04-desktop>
References: <7dc143fa-4a48-440b-b624-ac57a361ac74@oracle.com> <9dd91f6e-1c66-4961-994e-dbda87d69dad@oracle.com> <2025012919-series-chaps-856e@gregkh> <8eb33b38-23e1-4e43-8952-3f2b05660236@oracle.com> <2025012936-finalize-ducktail-c524@gregkh>
 <1f017284-1a29-49d8-b0d9-92409561990e@oracle.com> <2025012956-jiffy-condone-3137@gregkh> <1f225b8d-d958-4304-829e-8798884d9b6b@oracle.com> <83bd90c7-8879-4462-9548-bb5b69cac39e@suse.com> <b4ab0246-3846-41d1-8e84-64bd7fefc089@oracle.com>
 <de6912ad-3dba-4d66-8ca2-71a0aa09172c@suse.com> <686986a0-c981-4aa3-ae88-92a34368129e@oracle.com> <5a7d969b-b2ab-4fac-b95e-4a536e2c8d5c@suse.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-717441065-1738268883=:11632"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-717441065-1738268883=:11632
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Thu, 30 Jan 2025, Jürgen Groß wrote:
> Can you try the attached patch, please? I don't have a system at hand
> showing the problem.
>
> From cff43e997f79a95dc44e02debaeafe5f127f40bb Mon Sep 17 00:00:00 2001
> From: Juergen Gross <jgross@suse.com>
> Date: Thu, 30 Jan 2025 09:56:57 +0100
> Subject: [PATCH] x86/xen: allow larger contiguous memory regions in PV guests
> 
> Today a PV guest (including dom0) can create 2MB contiguous memory
> regions for DMA buffers at max. This has led to problems at least
> with the megaraid_sas driver, which wants to allocate a 2.3MB DMA
> buffer.
> 
> The limiting factor is the frame array used to do the hypercall for
> making the memory contiguous, which has 512 entries and is just a
> static array in mmu_pv.c.
> 
> In case a contiguous memory area larger than the initially supported
> 2MB is requested, allocate a larger buffer for the frame list. Note
> that such an allocation is tried only after memory management has been
> initialized properly, which is tested via the early_boot_irqs_disabled
> flag.
> 
> Fixes: 9f40ec84a797 ("xen/swiotlb: add alignment check for dma buffers")
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
> Note that the "Fixes:" tag is not really correct, as that patch didn't
> introduce the problem, but rather made it visible. OTOH it is the best
> indicator we have to identify kernel versions this patch should be
> backported to.
> ---
>  arch/x86/xen/mmu_pv.c | 44 ++++++++++++++++++++++++++++++++++++-------
>  1 file changed, 37 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
> index 55a4996d0c04..62aec29b8174 100644
> --- a/arch/x86/xen/mmu_pv.c
> +++ b/arch/x86/xen/mmu_pv.c
> @@ -2200,8 +2200,10 @@ void __init xen_init_mmu_ops(void)
>  }
>  
>  /* Protected by xen_reservation_lock. */
> -#define MAX_CONTIG_ORDER 9 /* 2MB */
> -static unsigned long discontig_frames[1<<MAX_CONTIG_ORDER];
> +#define MIN_CONTIG_ORDER 9 /* 2MB */
> +static unsigned int discontig_frames_order = MIN_CONTIG_ORDER;
> +static unsigned long discontig_frames_early[1UL << MIN_CONTIG_ORDER];
> +static unsigned long *discontig_frames = discontig_frames_early;
>  
>  #define VOID_PTE (mfn_pte(0, __pgprot(0)))
>  static void xen_zap_pfn_range(unsigned long vaddr, unsigned int order,
> @@ -2319,18 +2321,44 @@ int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
>  				 unsigned int address_bits,
>  				 dma_addr_t *dma_handle)
>  {
> -	unsigned long *in_frames = discontig_frames, out_frame;
> +	unsigned long *in_frames, out_frame;
> +	unsigned long *new_array, *old_array;
>  	unsigned long  flags;
>  	int            success;
>  	unsigned long vstart = (unsigned long)phys_to_virt(pstart);
>  
> -	if (unlikely(order > MAX_CONTIG_ORDER))
> -		return -ENOMEM;
> +	if (unlikely(order > discontig_frames_order)) {
> +		if (early_boot_irqs_disabled)
> +			return -ENOMEM;
> +
> +		new_array = vmalloc(sizeof(unsigned long) * (1UL << order));
> +
> +		if (!new_array)
> +			return -ENOMEM;
> +
> +		spin_lock_irqsave(&xen_reservation_lock, flags);
> +
> +		if (order > discontig_frames_order) {


This second if check should not be needed because it is the same as the
outer if check.



> +			if (discontig_frames == discontig_frames_early)
> +				old_array = NULL;
> +			else
> +				old_array = discontig_frames;
> +			discontig_frames = new_array;
> +			discontig_frames_order = order;
> +		} else
> +			old_array = new_array;
> +
> +		spin_unlock_irqrestore(&xen_reservation_lock, flags);
> +
> +		vfree(old_array);
> +	}
>  
>  	memset((void *) vstart, 0, PAGE_SIZE << order);
>  
>  	spin_lock_irqsave(&xen_reservation_lock, flags);
>  
> +	in_frames = discontig_frames;
> +
>  	/* 1. Zap current PTEs, remembering MFNs. */
>  	xen_zap_pfn_range(vstart, order, in_frames, NULL);
>  
> @@ -2354,12 +2382,12 @@ int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
>  
>  void xen_destroy_contiguous_region(phys_addr_t pstart, unsigned int order)
>  {
> -	unsigned long *out_frames = discontig_frames, in_frame;
> +	unsigned long *out_frames, in_frame;
>  	unsigned long  flags;
>  	int success;
>  	unsigned long vstart;
>  
> -	if (unlikely(order > MAX_CONTIG_ORDER))
> +	if (unlikely(order > discontig_frames_order))
>  		return;
>  
>  	vstart = (unsigned long)phys_to_virt(pstart);
> @@ -2367,6 +2395,8 @@ void xen_destroy_contiguous_region(phys_addr_t pstart, unsigned int order)
>  
>  	spin_lock_irqsave(&xen_reservation_lock, flags);
>  
> +	out_frames = discontig_frames;
> +
>  	/* 1. Find start MFN of contiguous extent. */
>  	in_frame = virt_to_mfn((void *)vstart);
>  
> -- 
> 2.43.0
> 
--8323329-717441065-1738268883=:11632--


From xen-devel-bounces@lists.xenproject.org Thu Jan 30 21:14:18 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Jan 2025 21:14:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879771.1289975 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdbrX-0000sJ-HT; Thu, 30 Jan 2025 21:14:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879771.1289975; Thu, 30 Jan 2025 21:14:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdbrX-0000sC-F1; Thu, 30 Jan 2025 21:14:11 +0000
Received: by outflank-mailman (input) for mailman id 879771;
 Thu, 30 Jan 2025 21:14: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
 <SRS0=URkf=UW=kernel.org=sstabellini@srs-se1.protection.inumbo.net>)
 id 1tdbrW-0000s6-L2
 for xen-devel@lists.xenproject.org; Thu, 30 Jan 2025 21:14:10 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 244e7c12-df4f-11ef-99a4-01e77a169b0f;
 Thu, 30 Jan 2025 22:14:08 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 81594A4252D;
 Thu, 30 Jan 2025 21:12:20 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4038CC4CED2;
 Thu, 30 Jan 2025 21:14:05 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 244e7c12-df4f-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1738271646;
	bh=PeQxpJiFJJfVnOrZDjcv8XKQguXVUUIzW+NyAJvnnP4=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=NB1K4AW+goFqcl1V5r8kTv08pXGIVSd+VJ9vcxrfT6A6fjNeR1mglNChyFJwILpMS
	 SZOnbGFLTa+pg4yyjPiFRO/FgsZdWLRe8qoiI8XsPMCFA669TuQ60ZYmcOiKgRx4hu
	 XnodUz5c/vX/o+V0+GECLZfSUyOjRVkPg9zzNLmydB/pC8NkMUrkZckQYqA0JaDVyn
	 GF86NSLkGpvFU3JCXC0i+hZq1JxidxAUfTaKWsRQgQTRWyqa73B/0JCC+O1nOC+njV
	 rVAqmjRU4Ey7RUk9KsxMI13zJKq8huT5rAU+RuS0CspuUeDjz9nG3TovxaZHKoZ72H
	 8wSmGp34AGtkA==
Date: Thu, 30 Jan 2025 13:14:03 -0800 (PST)
From: Stefano Stabellini <sstabellini@kernel.org>
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich <jbeulich@suse.com>
cc: "Daniel P. Smith" <dpsmith@apertussolutions.com>, jason.andryuk@amd.com, 
    christopher.w.clark@gmail.com, stefano.stabellini@amd.com, 
    Andrew Cooper <andrew.cooper3@citrix.com>, 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
    Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, 
    Bertrand Marquis <bertrand.marquis@arm.com>, 
    Michal Orzel <michal.orzel@amd.com>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 08/15] x86/hyperlaunch: locate dom0 kernel with
 hyperlaunch
In-Reply-To: <efc352d6-e686-435c-98b3-2333b6dee6a3@suse.com>
Message-ID: <alpine.DEB.2.22.394.2501301250410.11632@ubuntu-linux-20-04-desktop>
References: <20241226165740.29812-1-dpsmith@apertussolutions.com> <20241226165740.29812-9-dpsmith@apertussolutions.com> <efc352d6-e686-435c-98b3-2333b6dee6a3@suse.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Thu, 30 Jan 2025, Jan Beulich wrote:
> On 26.12.2024 17:57, Daniel P. Smith wrote:
> > Look for a subnode of type `multiboot,kernel` within a domain node. If found,
> > process the reg property for the MB1 module index. If the bootargs property is
> > present and there was not an MB1 string, then use the command line from the
> > device tree definition.
> 
> While multiboot is apparently the first x86-specific part (as far as Xen goes)
> to be put under domain-builder/, I wonder:
> - Wouldn't looking for "multiboot,kernel" simply yield nothing on non-x86,
>   so having the code under common/ would still be okay?

One small clarification: multiboot,kernel is actually common between
both ARM and x86. It is "module-index" which is x86-specific and would
"simply yield nothing on non-x86", as you wrote.

I'll let Dan address your point that "having the code under common/
would still be okay".


> - What's "multiboot" describing here? The origin of the module? (What other
>   origins would then be possible? How would MB1 and MB2 be distinguished?
>   What about a native xen.efi boot?) A property of the kernel (when Linux
>   doesn't use MB)?

Each device tree node has a compatible string to qualify what kind of
information the node is describing. The compatible string for device
tree nodes describing a kernel binary or a ramdisk previously loaded
into memory by a bootloader have a "multiboot," prefix. See
docs/misc/arm/device-tree/booting.txt. This is unrelated to the binary
multiboot protocol Grub uses on x86 to boot Xen.

A distinction between MB1 and MB2 is not needed in device tree, that
information is retrieved via the Grub multiboot protocol as usual. The
only thing needed here in device tree is the location of the kernel,
either by RAM address, or by Grub multiboot module index. This last
option (Grub multiboot module index) is the "module-index" property I
mentioned above.


From xen-devel-bounces@lists.xenproject.org Thu Jan 30 21:31:45 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 30 Jan 2025 21:31:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879784.1289986 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdc8K-0003d5-T9; Thu, 30 Jan 2025 21:31:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879784.1289986; Thu, 30 Jan 2025 21:31:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdc8K-0003cy-Q5; Thu, 30 Jan 2025 21:31:32 +0000
Received: by outflank-mailman (input) for mailman id 879784;
 Thu, 30 Jan 2025 21:31:32 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=bMfo=UW=kernel.org=helgaas@srs-se1.protection.inumbo.net>)
 id 1tdc8J-0003cs-Tp
 for xen-devel@lists.xenproject.org; Thu, 30 Jan 2025 21:31:31 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9027741d-df51-11ef-99a4-01e77a169b0f;
 Thu, 30 Jan 2025 22:31:28 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id D34A75C5907;
 Thu, 30 Jan 2025 21:30:46 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 56FE9C4CED2;
 Thu, 30 Jan 2025 21:31:26 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 9027741d-df51-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1738272686;
	bh=/VPTNf6kv2G1qLnaa7PZxmpgicixURiI5N/N0YxT8Qg=;
	h=Date:From:To:Cc:Subject:In-Reply-To:From;
	b=ReNjQK5ofR+danry2PSj58WLHyoCBOBn6MTWxBLdCn0E52DaEZ0FGNcMJ8WpiowW0
	 TvBvTxD6gZVI7uQC8RNoJCVAfaxTf0YX3DyV79eupdJezctz/M+1RS++/TEhckq+AF
	 jLRoItDft8LUGYLznwD45iVKeTK5uTZtaeTH4zyyBD3mR3pvDt3UZaMAn01TRKTJyp
	 nrkZk5/jvTY2TVGJjAvaoawQ3i5QHQfQ4hYpjuFQFIh75akmjxeDR7sWeHgvCXFXDo
	 n/coqTkDmcxYb981tPQBajlC06YbcVHA1Qz9Dcj/YMgVld90zDpMzVVdJcCkfZA5cl
	 T5PmI1XdPzpxA==
Date: Thu, 30 Jan 2025 15:31:23 -0600
From: Bjorn Helgaas <helgaas@kernel.org>
To: Jan Beulich <jbeulich@suse.com>
Cc: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	=?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	linux-kernel@vger.kernel.org, regressions@lists.linux.dev,
	Felix Fietkau <nbd@nbd.name>, Lorenzo Bianconi <lorenzo@kernel.org>,
	Ryder Lee <ryder.lee@mediatek.com>
Subject: Re: Config space access to Mediatek MT7922 doesn't work after device
 reset in Xen PV dom0 (regression, Linux 6.12)
Message-ID: <20250130213123.GA633869@bhelgaas>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <cfe0af0e-132b-4390-a3b0-dde0e6326e19@suse.com>

On Thu, Jan 30, 2025 at 10:30:33AM +0100, Jan Beulich wrote:
> On 30.01.2025 05:55, Marek Marczykowski-Górecki wrote:
> > I've added logging of all config read/write to this device. Full log at
> > [1].
> ...

I suspect there's something wrong with the Root Port RRS SV
configuration.

Can you add the two patches below?

I don't *think* either should make a difference.  The first enables
RRS SV earlier and maybe in a cleaner place; the second should avoid
some pointless capability searches that clutter the logs.

What does d0v1/d0v2/d0v3 mean?

Can you add 00:02.2, the Root Port leading to bus 01, so we can see
the RRS SV configuration?  Maybe also lspci -vv for both 00:02.2 and
01:00.0?

Maybe include timestamps and try an FLR without Xen (which I assume
works correctly) so we can see how long the device typically takes to
become ready?

Notes below on the snippet that you commented on, Jan.  I think it
makes sense until the read after FLR returns 0xffffffff.

> > (XEN) d0v1 conf read cf8 0x80010034 bytes 1 offset 0 data 0x80

PCI_CAPABILITY_LIST, first cap at 0x80

> > (XEN) d0v1 conf read cf8 0x80010080 bytes 2 offset 0 data 0xe010

PCI_CAP_ID_EXP (0x10) at 0x80, next cap at 0xe0

> > (XEN) d0v1 conf read cf8 0x800100e0 bytes 2 offset 0 data 0xf805

PCI_CAP_ID_MSI (0x05) at 0xe0, next cap at 0xf8

> > (XEN) d0v1 conf read cf8 0x800100f8 bytes 2 offset 0 data 0x1

PCI_CAP_ID_PM (0x01) at 0xf8, end of cap list

These caps match the offsets from the lspci output in the full log:

  1:00.0 Network controller: MEDIATEK Corp. MT7922 802.11ax PCI Express Wireless Network Adapter
	  Subsystem: MEDIATEK Corp. Device e616
	  Flags: fast devsel, IRQ 255
	  Memory at 8010900000 (64-bit, prefetchable) [disabled] [size=1M]
	  Memory at 90b00000 (64-bit, non-prefetchable) [disabled] [size=32K]
	  Capabilities: [80] Express Endpoint, IntMsgNum 0
	  Capabilities: [e0] MSI: Enable- Count=1/32 Maskable+ 64bit+
	  Capabilities: [f8] Power Management version 3

> > (XEN) d0v1 conf write cf8 0x80010004 bytes 2 offset 0 data 0x400

Set PCI_COMMAND_INTX_DISABLE, disable BARs, Bus Master.  Looks like
the end of pci_dev_save_and_disable().

> > (XEN) d0v1 conf read cf8 0x80010088 bytes 2 offset 2 data 0x9

PCIe Cap at 0x80, PCI_EXP_DEVCTL is 0x08, PCI_EXP_DEVSTA is 0x0a.

0x80010088 would be PCI_EXP_DEVCTL (a 2-byte register), maybe offset 2
gets us to PCI_EXP_DEVSTA?  Not sure.

  0x0001 PCI_EXP_DEVSTA_CED /* Correctable Error Detected */
  0x0008 PCI_EXP_DEVSTA_URD /* Unsupported Request Detected */

Not impossible that these would be set.  Lots of URs happen during
enumeration and we're not very good about cleaning these up.
Correctable errors are common for some devices.  lspci -vv would
decode the PCIe cap registers, including this.

> > (XEN) d0v1 conf read cf8 0x80010088 bytes 2 offset 0 data 0x2910

PCI_EXP_DEVCTL:
  0x2000 PCI_EXP_DEVCTL_READRQ_512B
  0x0800 PCI_EXP_DEVCTL_NOSNOOP_EN
  0x0100 PCI_EXP_DEVCTL_EXT_TAG
  0x0010 PCI_EXP_DEVCTL_RELAX_EN

> > (XEN) d0v1 conf write cf8 0x80010088 bytes 2 offset 0 data 0xa910

PCI_EXP_DEVCTL:
  set 0x8000 PCI_EXP_DEVCTL_BCR_FLR

This looks like the actual FLR being initiated.

> This is the express capability's Link Control 2 Register afaict.

Unless I'm missing something this is actually Device Control.  So far
I think this all looks OK.  The next part:

> > (XEN) d0v2 conf read cf8 0x80010000 bytes 4 offset 0 data 0xffffffff

looks like a problem.  The normal successful read gets 0x061614c3.
After the FLR, if RRS SV is enabled, we should get either 0x0001ffff
or 0x061614c3.

Here we would exit the loop in pci_dev_wait() because we didn't see
0x0001 and we expect that the device is ready and we got a valid
Vendor ID.

So we proceed to restoring config space via pci_restore_state(), where
we restore some PCIe registers and the header (first 64 bytes).  My
*guess* is the device isn't ready (or at least not responding) since
all the reads return ~0.

> > [1] https://gist.github.com/marmarek/b4391c71801145e52590e877c559c5e0



commit c2fd12204dcb ("PCI: Enable Configuration RRS SV early")
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Thu Jan 30 15:16:40 2025 -0600

    PCI: Enable Configuration RRS SV early

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index b6536ed599c3..0b013b196d00 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1373,8 +1373,6 @@ static int pci_scan_bridge_extend(struct pci_bus *bus, struct pci_dev *dev,
 	pci_write_config_word(dev, PCI_BRIDGE_CONTROL,
 			      bctl & ~PCI_BRIDGE_CTL_MASTER_ABORT);
 
-	pci_enable_rrs_sv(dev);
-
 	if ((secondary || subordinate) && !pcibios_assign_all_busses() &&
 	    !is_cardbus && !broken) {
 		unsigned int cmax, buses;
@@ -1615,6 +1613,11 @@ void set_pcie_port_type(struct pci_dev *pdev)
 	pdev->pcie_cap = pos;
 	pci_read_config_word(pdev, pos + PCI_EXP_FLAGS, &reg16);
 	pdev->pcie_flags_reg = reg16;
+
+	type = pci_pcie_type(pdev);
+	if (type == PCI_EXP_TYPE_ROOT_PORT)
+		pci_enable_rrs_sv(pdev);
+
 	pci_read_config_dword(pdev, pos + PCI_EXP_DEVCAP, &pdev->devcap);
 	pdev->pcie_mpss = FIELD_GET(PCI_EXP_DEVCAP_PAYLOAD, pdev->devcap);
 
@@ -1631,7 +1634,6 @@ void set_pcie_port_type(struct pci_dev *pdev)
 	 * correctly so detect impossible configurations here and correct
 	 * the port type accordingly.
 	 */
-	type = pci_pcie_type(pdev);
 	if (type == PCI_EXP_TYPE_DOWNSTREAM) {
 		/*
 		 * If pdev claims to be downstream port but the parent



commit 4ea25d50c7c1 ("PCI: Avoid needless capability searches")
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Thu Jan 30 14:33:00 2025 -0600

    PCI: Avoid needless capability searches
    
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 869d204a70a3..02d592b81bc6 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1742,19 +1742,17 @@ static void pci_restore_pcie_state(struct pci_dev *dev)
 
 static int pci_save_pcix_state(struct pci_dev *dev)
 {
-	int pos;
 	struct pci_cap_saved_state *save_state;
+	u8 pos;
+
+	save_state = pci_find_saved_cap(dev, PCI_CAP_ID_PCIX);
+	if (!save_state)
+		return -ENOMEM;
 
 	pos = pci_find_capability(dev, PCI_CAP_ID_PCIX);
 	if (!pos)
 		return 0;
 
-	save_state = pci_find_saved_cap(dev, PCI_CAP_ID_PCIX);
-	if (!save_state) {
-		pci_err(dev, "buffer not found in %s\n", __func__);
-		return -ENOMEM;
-	}
-
 	pci_read_config_word(dev, pos + PCI_X_CMD,
 			     (u16 *)save_state->cap.data);
 
@@ -1763,14 +1761,19 @@ static int pci_save_pcix_state(struct pci_dev *dev)
 
 static void pci_restore_pcix_state(struct pci_dev *dev)
 {
-	int i = 0, pos;
 	struct pci_cap_saved_state *save_state;
+	u8 pos;
+	int i = 0;
 	u16 *cap;
 
 	save_state = pci_find_saved_cap(dev, PCI_CAP_ID_PCIX);
-	pos = pci_find_capability(dev, PCI_CAP_ID_PCIX);
-	if (!save_state || !pos)
+	if (!save_state)
 		return;
+
+	pos = pci_find_capability(dev, PCI_CAP_ID_PCIX);
+	if (!pos)
+		return;
+
 	cap = (u16 *)&save_state->cap.data[0];
 
 	pci_write_config_word(dev, pos + PCI_X_CMD, cap[i++]);
diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
index e0bc90597dca..007e4a082e6f 100644
--- a/drivers/pci/pcie/aspm.c
+++ b/drivers/pci/pcie/aspm.c
@@ -35,16 +35,14 @@ void pci_save_ltr_state(struct pci_dev *dev)
 	if (!pci_is_pcie(dev))
 		return;
 
+	save_state = pci_find_saved_ext_cap(dev, PCI_EXT_CAP_ID_LTR);
+	if (!save_state)
+		return;
+
 	ltr = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_LTR);
 	if (!ltr)
 		return;
 
-	save_state = pci_find_saved_ext_cap(dev, PCI_EXT_CAP_ID_LTR);
-	if (!save_state) {
-		pci_err(dev, "no suspend buffer for LTR; ASPM issues possible after resume\n");
-		return;
-	}
-
 	/* Some broken devices only support dword access to LTR */
 	cap = &save_state->cap.data[0];
 	pci_read_config_dword(dev, ltr + PCI_LTR_MAX_SNOOP_LAT, cap);
@@ -57,8 +55,11 @@ void pci_restore_ltr_state(struct pci_dev *dev)
 	u32 *cap;
 
 	save_state = pci_find_saved_ext_cap(dev, PCI_EXT_CAP_ID_LTR);
+	if (!save_state)
+		return;
+
 	ltr = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_LTR);
-	if (!save_state || !ltr)
+	if (!ltr)
 		return;
 
 	/* Some broken devices only support dword access to LTR */
diff --git a/drivers/pci/vc.c b/drivers/pci/vc.c
index a4ff7f5f66dd..c39f3be518d4 100644
--- a/drivers/pci/vc.c
+++ b/drivers/pci/vc.c
@@ -355,20 +355,17 @@ int pci_save_vc_state(struct pci_dev *dev)
 	int i;
 
 	for (i = 0; i < ARRAY_SIZE(vc_caps); i++) {
-		int pos, ret;
 		struct pci_cap_saved_state *save_state;
+		int pos, ret;
+
+		save_state = pci_find_saved_ext_cap(dev, vc_caps[i].id);
+		if (!save_state)
+			return -ENOMEM;
 
 		pos = pci_find_ext_capability(dev, vc_caps[i].id);
 		if (!pos)
 			continue;
 
-		save_state = pci_find_saved_ext_cap(dev, vc_caps[i].id);
-		if (!save_state) {
-			pci_err(dev, "%s buffer not found in %s\n",
-				vc_caps[i].name, __func__);
-			return -ENOMEM;
-		}
-
 		ret = pci_vc_do_save_buffer(dev, pos, save_state, true);
 		if (ret) {
 			pci_err(dev, "%s save unsuccessful %s\n",
@@ -392,12 +389,15 @@ void pci_restore_vc_state(struct pci_dev *dev)
 	int i;
 
 	for (i = 0; i < ARRAY_SIZE(vc_caps); i++) {
-		int pos;
 		struct pci_cap_saved_state *save_state;
+		int pos;
+
+		save_state = pci_find_saved_ext_cap(dev, vc_caps[i].id);
+		if (!save_state)
+			continue;
 
 		pos = pci_find_ext_capability(dev, vc_caps[i].id);
-		save_state = pci_find_saved_ext_cap(dev, vc_caps[i].id);
-		if (!save_state || !pos)
+		if (!pos)
 			continue;
 
 		pci_vc_do_save_buffer(dev, pos, save_state, false);


From xen-devel-bounces@lists.xenproject.org Fri Jan 31 00:27:34 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 31 Jan 2025 00:27:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879796.1289995 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdesQ-00068f-5z; Fri, 31 Jan 2025 00:27:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879796.1289995; Fri, 31 Jan 2025 00:27:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdesQ-00068Y-3S; Fri, 31 Jan 2025 00:27:18 +0000
Received: by outflank-mailman (input) for mailman id 879796;
 Fri, 31 Jan 2025 00:27:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=HyPN=UX=tklengyel.com=tamas@srs-se1.protection.inumbo.net>)
 id 1tdesO-00068Q-LR
 for xen-devel@lists.xenproject.org; Fri, 31 Jan 2025 00:27:16 +0000
Received: from sender3-op-o12.zoho.com (sender3-op-o12.zoho.com
 [136.143.184.12]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1d40b42d-df6a-11ef-a0e6-8be0dac302b0;
 Fri, 31 Jan 2025 01:27:13 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1738283224179155.63362297888295;
 Thu, 30 Jan 2025 16:27:04 -0800 (PST)
Received: by mail-yw1-f172.google.com with SMTP id
 00721157ae682-6efe4324f96so4503067b3.1
 for <xen-devel@lists.xenproject.org>; Thu, 30 Jan 2025 16:27:04 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1d40b42d-df6a-11ef-a0e6-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1738283228; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=TTdMD/kIzhNy6AKIEDWq8wa1PElp9X7OWA80Y4xQY1/B559E58YkquDlNMbGM4+3pARRkmmgaHbQyJpT03BjGfibSfKLpTDCOi7GWIL9CS8rS37ghQvr8E/11+SDA5RqExiLKMb81XySMKON5vxJHxYL+mygemsk6wEtyCsFDBk=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1738283228; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=5FamLrRiItq5K95TJ90P8rmA78dEGWW0HVOj4wgqlmw=; 
	b=lGKQCRvvoet3ua1uzg6QV0H67ZI7YF9majuH4zyiVkg0eXPwNgrmov0Ppgt+dhM8bfmubngLzhj3hGnCQ0htAuG7AEJ+LoArU5vP30ygbQkURI/SGMlkNwu+WXRiv7RSwlz4fK3cL9es65fikzxB6qM/38/2ffJcBzbCZLTkN2I=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=tklengyel.com;
	spf=pass  smtp.mailfrom=tamas@tklengyel.com;
	dmarc=pass header.from=<tamas@tklengyel.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1738283228;
	s=zmail; d=tklengyel.com; i=tamas@tklengyel.com;
	h=MIME-Version:References:In-Reply-To:From:From:Date:Date:Message-ID:Subject:Subject:To:To:Cc:Cc:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=5FamLrRiItq5K95TJ90P8rmA78dEGWW0HVOj4wgqlmw=;
	b=NdVD+ALnKZtsd5dk6DZmzsnpW+26HoqAuI8s7cYskN302sauhkMkCMky9khs9xSk
	N/tIHgFlDBKwlzIUrJ08V68P0vYe5xFaKFjcfHO3ZTA8gh9/8UJhuJ98PkxL6FNXmsp
	7XNeC2kvcknfhH55Mu/Arb7y0jB7KkVqvx8xef64=
X-Forwarded-Encrypted: i=1; AJvYcCVoB/seDfHjqZjKv3Gw6rLuV2YrSxIuoB/3D1mK10NnuJuCdHEVlajaNPxFVaFhq0yBfg7B1mjKar8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxHsLCXuVJW3WPTYWfyrc5HVNO7lPQo7+9NUvzLRG8wrF1u/Rxc
	FL299FPS5bhuOXNP8wDAPRVSYnYpHK6GlmEa13EaWErBuOC+gaUed7i0jf5DiwT0ritMI7Ow60Y
	zp+Go07q05lKu0mBFEZ203H2+sjk=
X-Google-Smtp-Source: AGHT+IFnvH3XL+lXqbE5VDGJ9t+h6u81NVebRWM8gaNZvzYlC9jFDJ/U+AHvyZmssNw3fSz6dENk2Fy3z2Z9G4S4Bqg=
X-Received: by 2002:a05:690c:360e:b0:6e5:9cb7:853c with SMTP id
 00721157ae682-6f7a8423317mr83440477b3.31.1738283223389; Thu, 30 Jan 2025
 16:27:03 -0800 (PST)
MIME-Version: 1.0
References: <cover.1737452864.git.Sergiy_Kibrik@epam.com> <ff22f35dafd04b16165e1caec038e5a5fcf2aeee.1737452864.git.Sergiy_Kibrik@epam.com>
 <c74d334e-6e33-4a58-bf94-936249244cb0@suse.com>
In-Reply-To: <c74d334e-6e33-4a58-bf94-936249244cb0@suse.com>
From: Tamas K Lengyel <tamas@tklengyel.com>
Date: Thu, 30 Jan 2025 19:26:27 -0500
X-Gmail-Original-Message-ID: <CABfawhm8Cb3xz8Fv=YhA1TSKtvA3ThWHMcqJCFDarwSuYKQ5ZA@mail.gmail.com>
X-Gm-Features: AWEUYZno4HdvG_T6sY44FsuyluQ9JfFu3x1waZbMD0R8Cwc37Uosd31qTc-SSh0
Message-ID: <CABfawhm8Cb3xz8Fv=YhA1TSKtvA3ThWHMcqJCFDarwSuYKQ5ZA@mail.gmail.com>
Subject: Re: [PATCH v2 1/4] xen: kconfig: rename MEM_ACCESS -> VM_EVENT
To: Jan Beulich <jbeulich@suse.com>
Cc: Sergiy Kibrik <Sergiy_Kibrik@epam.com>, Julien Grall <julien@xen.org>, 
	Bertrand Marquis <bertrand.marquis@arm.com>, Michal Orzel <michal.orzel@amd.com>, 
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>, Andrew Cooper <andrew.cooper3@citrix.com>, 
	Anthony PERARD <anthony.perard@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
	Alexandru Isaila <aisaila@bitdefender.com>, Petre Pircalabu <ppircalabu@bitdefender.com>, 
	Shawn Anastasio <sanastasio@raptorengineering.com>, 
	Alistair Francis <alistair.francis@wdc.com>, Bob Eshleman <bobbyeshleman@gmail.com>, 
	Connor Davis <connojdavis@gmail.com>, Oleksii Kurochko <oleksii.kurochko@gmail.com>, 
	"Daniel P. Smith" <dpsmith@apertussolutions.com>, Stefano Stabellini <sstabellini@kernel.org>, 
	xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 30, 2025 at 8:24=E2=80=AFAM Jan Beulich <jbeulich@suse.com> wro=
te:
>
> On 21.01.2025 11:19, Sergiy Kibrik wrote:
> > Use more generic CONFIG_VM_EVENT name throughout Xen code instead of
> > CONFIG_MEM_ACCESS. This reflects the fact that vm_event is a higher lev=
el
> > feature, with mem_access & monitor depending on it.
> >
> > Suggested-by: Jan Beulich <jbeulich@suse.com>
>
> I don't think this is applicable; my suggestion went in a different direc=
tion.
>
> > Suggested-by: Tamas K Lengyel <tamas@tklengyel.com>
> > Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
>
> Before considering to ack this, I'd like you, Tamas, to confirm this is r=
eally
> what you had thought of. In particular ...
>
> > --- a/xen/arch/arm/Makefile
> > +++ b/xen/arch/arm/Makefile
> > @@ -37,7 +37,7 @@ obj-y +=3D irq.o
> >  obj-y +=3D kernel.init.o
> >  obj-$(CONFIG_LIVEPATCH) +=3D livepatch.o
> >  obj-$(CONFIG_LLC_COLORING) +=3D llc-coloring.o
> > -obj-$(CONFIG_MEM_ACCESS) +=3D mem_access.o
> > +obj-$(CONFIG_VM_EVENT) +=3D mem_access.o
>
> ... changes like this one look somewhat odd to me.
>
> > --- a/xen/common/Kconfig
> > +++ b/xen/common/Kconfig
> > @@ -92,7 +92,7 @@ config HAS_VMAP
> >  config MEM_ACCESS_ALWAYS_ON
> >       bool
> >
> > -config MEM_ACCESS
> > +config VM_EVENT
> >       def_bool MEM_ACCESS_ALWAYS_ON
> >       prompt "Memory Access and VM events" if !MEM_ACCESS_ALWAYS_ON
> >       depends on HVM
>
> What about MEM_ACCESS_ALWAYS_ON (visible in patch context)? Shouldn't tha=
t
> become VM_EVENT_ALWAYS_ON then, too?
>
> Further, what about MEM_PAGING and MEM_SHARING? Shouldn't those, at least
> documentation purposes, then also gain a dependency on VM_EVENT?

MEM_PAGING, yes. MEM_SHARING, definitely not. MEM_SHARING is perfectly
functional without vm_event.

Tamas


From xen-devel-bounces@lists.xenproject.org Fri Jan 31 00:30:21 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 31 Jan 2025 00:30:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879803.1290006 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdevM-0007ZB-Ja; Fri, 31 Jan 2025 00:30:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879803.1290006; Fri, 31 Jan 2025 00:30:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdevM-0007Z4-GP; Fri, 31 Jan 2025 00:30:20 +0000
Received: by outflank-mailman (input) for mailman id 879803;
 Fri, 31 Jan 2025 00:30:20 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=HyPN=UX=tklengyel.com=tamas@srs-se1.protection.inumbo.net>)
 id 1tdevM-0007Yy-2T
 for xen-devel@lists.xenproject.org; Fri, 31 Jan 2025 00:30:20 +0000
Received: from sender4-op-o16.zoho.com (sender4-op-o16.zoho.com
 [136.143.188.16]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8b91a15a-df6a-11ef-a0e6-8be0dac302b0;
 Fri, 31 Jan 2025 01:30:18 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1738283414209491.3141769924324;
 Thu, 30 Jan 2025 16:30:14 -0800 (PST)
Received: by mail-yw1-f170.google.com with SMTP id
 00721157ae682-6f7440444efso4576617b3.2
 for <xen-devel@lists.xenproject.org>; Thu, 30 Jan 2025 16:30:14 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 8b91a15a-df6a-11ef-a0e6-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1738283416; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=UlT+3aEZ1pgeYjyWgkDet5yyInOGXbEZt20PXcRr36dTn/bV2dqMwzZ3E5yKSPiMr2rBb9dUw7Q+B5cOy8XsfQSgc8KFQkoxbdxkWN1nV0eICcQvECdM+++PVVcBzNtL3xmNGXcMFOD4GpUaH8W/siTFMXzTfx64I+53M5UFjX0=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1738283416; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=PM5oirnBZ86E/0kDDfKgrWEpKXkiKmWIpyKteR6QFic=; 
	b=QDk0YuKCyFrERnLG+SA/NLfo7/K0NiAgtwk+l9rP0FhHreelTcBiDSD7WJmFPbcMUslxpMVraZ4DJOUdKYd50f0veKkk/V5jGjVybC2W6lF8jKi51GpzsnyEMOS8V0GjgkFGRgZKHTxrnhrYr6EK6cF4LF1uvio7LUqR6tNTMFs=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=tklengyel.com;
	spf=pass  smtp.mailfrom=tamas@tklengyel.com;
	dmarc=pass header.from=<tamas@tklengyel.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1738283416;
	s=zmail; d=tklengyel.com; i=tamas@tklengyel.com;
	h=MIME-Version:References:In-Reply-To:From:From:Date:Date:Message-ID:Subject:Subject:To:To:Cc:Cc:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=PM5oirnBZ86E/0kDDfKgrWEpKXkiKmWIpyKteR6QFic=;
	b=I4oWfyFD1RX9IXfYBayZFgUhBF3TFdPQutsEXwTRQbXu9pUNCcU7Jg0KVx9lU7CD
	hHarAJvzC72hTp6WNNsPMoGm8R4EgyfRxMtpjadOCXqsuca4cteStiiik0M6HAaeTpK
	f/hYo8c7I3u0FEL4fnArEzH5YcrNvlW10YqLpyE0=
X-Gm-Message-State: AOJu0YzEuEqMn+kJvDeTFASP0G7q9OLQHEqmuJRnsp3z062GC4MhfboO
	H5+VlXhqP8Kc6ekEHo6bVH3L2xFLb9zBNtR+MbBJ1oAo3RKsGcCljCZtrJwRekPSB27wZBJ12au
	uqEyLZm1wzEjEzYAYLqivNW4fbkM=
X-Google-Smtp-Source: AGHT+IFVc1Iqxp9i6disdaV7tQYe+tkP3CyFafjslPNEiYSYebSditbS6mJUfIHpoSJZFhStUzxzDAsjrPwyn7uuHgA=
X-Received: by 2002:a05:690c:4d0a:b0:6ef:e39f:bbd with SMTP id
 00721157ae682-6f7a848ea13mr77436107b3.33.1738283413859; Thu, 30 Jan 2025
 16:30:13 -0800 (PST)
MIME-Version: 1.0
References: <cover.1737452864.git.Sergiy_Kibrik@epam.com> <ff22f35dafd04b16165e1caec038e5a5fcf2aeee.1737452864.git.Sergiy_Kibrik@epam.com>
In-Reply-To: <ff22f35dafd04b16165e1caec038e5a5fcf2aeee.1737452864.git.Sergiy_Kibrik@epam.com>
From: Tamas K Lengyel <tamas@tklengyel.com>
Date: Thu, 30 Jan 2025 19:29:38 -0500
X-Gmail-Original-Message-ID: <CABfawhkZZtM7HRi8XqVoWjsmutv1s_49J3=oVNoTjGh-anYiaQ@mail.gmail.com>
X-Gm-Features: AWEUYZmSLPBf8xY7FE-WyEXmNQyII_SZbND8Lb5w_Ld3MZcaAxnxWjOFdofLyHI
Message-ID: <CABfawhkZZtM7HRi8XqVoWjsmutv1s_49J3=oVNoTjGh-anYiaQ@mail.gmail.com>
Subject: Re: [PATCH v2 1/4] xen: kconfig: rename MEM_ACCESS -> VM_EVENT
To: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
Cc: xen-devel@lists.xenproject.org, Julien Grall <julien@xen.org>, 
	Bertrand Marquis <bertrand.marquis@arm.com>, Michal Orzel <michal.orzel@amd.com>, 
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>, Andrew Cooper <andrew.cooper3@citrix.com>, 
	Anthony PERARD <anthony.perard@vates.tech>, Jan Beulich <jbeulich@suse.com>, 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
	Alexandru Isaila <aisaila@bitdefender.com>, Petre Pircalabu <ppircalabu@bitdefender.com>, 
	Shawn Anastasio <sanastasio@raptorengineering.com>, 
	Alistair Francis <alistair.francis@wdc.com>, Bob Eshleman <bobbyeshleman@gmail.com>, 
	Connor Davis <connojdavis@gmail.com>, Oleksii Kurochko <oleksii.kurochko@gmail.com>, 
	"Daniel P. Smith" <dpsmith@apertussolutions.com>, Stefano Stabellini <sstabellini@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 21, 2025 at 5:19=E2=80=AFAM Sergiy Kibrik <Sergiy_Kibrik@epam.c=
om> wrote:
>
> Use more generic CONFIG_VM_EVENT name throughout Xen code instead of
> CONFIG_MEM_ACCESS. This reflects the fact that vm_event is a higher level
> feature, with mem_access & monitor depending on it.
>
> Suggested-by: Jan Beulich <jbeulich@suse.com>
> Suggested-by: Tamas K Lengyel <tamas@tklengyel.com>
> Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>

Acked-by: Tamas K Lengyel <tamas@tklengyel.com>


From xen-devel-bounces@lists.xenproject.org Fri Jan 31 00:33:57 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 31 Jan 2025 00:33:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879809.1290016 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdeyn-0008Ey-1H; Fri, 31 Jan 2025 00:33:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879809.1290016; Fri, 31 Jan 2025 00:33:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdeym-0008Er-Un; Fri, 31 Jan 2025 00:33:52 +0000
Received: by outflank-mailman (input) for mailman id 879809;
 Fri, 31 Jan 2025 00:33:51 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=H6fZ=UX=invisiblethingslab.com=demi@srs-se1.protection.inumbo.net>)
 id 1tdeyl-0008Ee-FI
 for xen-devel@lists.xenproject.org; Fri, 31 Jan 2025 00:33:51 +0000
Received: from fout-b4-smtp.messagingengine.com
 (fout-b4-smtp.messagingengine.com [202.12.124.147])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 08bdfc54-df6b-11ef-99a4-01e77a169b0f;
 Fri, 31 Jan 2025 01:33:48 +0100 (CET)
Received: from phl-compute-09.internal (phl-compute-09.phl.internal
 [10.202.2.49])
 by mailfout.stl.internal (Postfix) with ESMTP id 63355114015D;
 Thu, 30 Jan 2025 19:33:46 -0500 (EST)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-09.internal (MEProxy); Thu, 30 Jan 2025 19:33:46 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 30 Jan 2025 19:33:44 -0500 (EST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 08bdfc54-df6b-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:content-type:content-type:date:date
	:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm3; t=1738283626;
	 x=1738370026; bh=j99SJx9+IyZ7/r4OezmfhlavbnB02Ja7JSF+YJce3E0=; b=
	fBvWEqNn3MrBQ97NnULtQxdiecq+Gb+3/PQbbJgjGP9Oj/2spdqMC6rYQ9hsgMRv
	0Iwxxd/VZqqzzuaIadQ49dTCeyGCYAqNhUqBoDPiyelqNqQJYQx0s3bwD8GyNqVb
	PjVUn+QUcBuBA54Lr6lwo1h63+6m2nCb2KvoqG2JUnD72Q+wkAVXRfIcOUn53sIZ
	LAAIRYVZewWomimIxPCBviSXVSIHNwurPGnov/9NvX9bgj4jcIMyeN3BZ7+gUJDl
	/fHS397ubeg0cjOj07jeuw9HFX0zG9ZhuLn6H4QtPLttdFmtWIbRN7Vr+knDXejq
	uClXpbh7hcxYeP/liBmpBg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:subject:subject:to
	:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=
	1738283626; x=1738370026; bh=j99SJx9+IyZ7/r4OezmfhlavbnB02Ja7JSF
	+YJce3E0=; b=ukhYcM462h0Yyo5L/vjDR4BlFkf23xJOmGi6reGlSAdN6WQdCFm
	ve6k9AiPziSvn7UwjoaP4ZuTjc4ZsQc7jvH3uTCVX+Jz5+l7cVloKyzG1HGiP52f
	GhF0hjQhpRWV/WzIx8IXmVBagnRpxoc2GP7XgTIm3ZEe9Zboewn7QOgJo0AIPWms
	tVPHBqn+dKkiHMCHuf0oUkF08OS/pAe4lcvekPB6MJ3IFN1Dl+/yhDA7gAYD7MqD
	jHm4Rds3hp7uCESVeAElD8GAlwjlsH9oUWI1jETAGuuzEEei9MAPqjfehyR4w+e0
	0ham+c9HxyMKMM/TloJLuhjLgHdDWSRcCUQ==
X-ME-Sender: <xms:aRqcZ0MVWJjDOhA6w8yXek5zvl-ORa3WWrUa4XsxZc36yXrKNfAkUg>
    <xme:aRqcZ69bVfwEKpRuUMAqCEBWm0bs4c3rlNc_n2xvzHH4sgD8j-YPsxUxjeEzsn-08
    dEHQzlG1vkCwvg>
X-ME-Received: <xmr:aRqcZ7Sba18NnKiQVem16eIihmKJrMzbK_cGsO374AImA2UpJ3sl5hLcr_Q>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdejfedtucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
    rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
    htshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjsehgtderredttdejnecu
    hfhrohhmpeffvghmihcuofgrrhhivgcuqfgsvghnohhurhcuoeguvghmihesihhnvhhish
    hisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpedttedtueei
    vdefiedugfejtdeutdelfedvueekledtudegjedviedukeefhfeuteenucevlhhushhtvg
    hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpeguvghmihesihhnvhhishhi
    sghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopedukedpmhhouggvpe
    hsmhhtphhouhhtpdhrtghpthhtohepuggvmhhiohgsvghnohhurhesghhmrghilhdrtgho
    mhdprhgtphhtthhopehhohhnghhlvghiuddrhhhurghnghesrghmugdrtghomhdprhgtph
    htthhopehrrgihrdhhuhgrnhhgsegrmhgurdgtohhmpdhrtghpthhtohepvhhirhhtuhgr
    lhhiiigrthhiohhnsehlihhsthhsrdhlihhnuhigqdhfohhunhgurghtihhonhdrohhrgh
    dprhgtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhr
    ghdprhgtphhtthhopegumhhithhrhidrohhsihhpvghnkhhosegtohhllhgrsghorhgrrd
    gtohhmpdhrtghpthhtohepughrihdquggvvhgvlheslhhishhtshdrfhhrvggvuggvshhk
    thhophdrohhrghdprhgtphhtthhopegrihhrlhhivggusehrvgguhhgrthdrtghomhdprh
    gtphhtthhopehkrhgrgigvlhesrhgvughhrghtrdgtohhm
X-ME-Proxy: <xmx:aRqcZ8tviDV2fH_Fig7gZuvUTO-Q2ol4AzOWoGY6D7TyyDHDWINsPQ>
    <xmx:aRqcZ8e_77SMnr4hQcFkljV16wDIKgv2sZp6rruj-cfLrMVFShP_6w>
    <xmx:aRqcZw0OvE4Bz0ERm413AjBj7Mxs2Yjx4z57hqQB8DctU261M1TGrg>
    <xmx:aRqcZw87SycT_jcUZzUq_ZJ3fHdctwdGyN8z3rV_RtJajO_jZOXOYw>
    <xmx:ahqcZ_VIDfYVUxJV9L-zEswUlE7cRIvQCdphyjywN14hUKE26-B8UQea>
Feedback-ID: iac594737:Fastmail
Date: Thu, 30 Jan 2025 19:33:37 -0500
From: Demi Marie Obenour <demi@invisiblethingslab.com>
To: Demi Marie Obenour <demiobenour@gmail.com>,
	"Huang, Honglei1" <Honglei1.Huang@amd.com>,
	Huang Rui <ray.huang@amd.com>,
	virtualization@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org,
	Dmitry Osipenko <dmitry.osipenko@collabora.com>,
	dri-devel@lists.freedesktop.org, David Airlie <airlied@redhat.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Gurchetan Singh <gurchetansingh@chromium.org>,
	Chia-I Wu <olvaffe@gmail.com>,
	Akihiko Odaki <akihiko.odaki@daynix.com>,
	Lingshan Zhu <Lingshan.Zhu@amd.com>,
	Xen developer discussion <xen-devel@lists.xenproject.org>,
	Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>,
	Kernel KVM virtualization development <kvm@vger.kernel.org>,
	Xenia Ragiadakou <burzalodowa@gmail.com>,
	Stefano Stabellini <stefano.stabellini@amd.com>
Subject: Re: [RFC PATCH 3/3] drm/virtio: implement blob userptr resource
 object
Message-ID: <Z5waZsddenagCYtl@itl-email>
References: <20241220100409.4007346-1-honglei1.huang@amd.com>
 <20241220100409.4007346-3-honglei1.huang@amd.com>
 <Z2WO2udH2zAEr6ln@phenom.ffwll.local>
 <2fb36b50-4de2-4060-a4b7-54d221db8647@gmail.com>
 <de8ade34-eb67-4bff-a1c9-27cb51798843@amd.com>
 <Z36wV07M8B_wgWPl@phenom.ffwll.local>
 <c42ae4f7-f5f4-4906-85aa-b049ed44d7e9@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="9QyKV9EEhg0eMfJA"
Content-Disposition: inline
In-Reply-To: <c42ae4f7-f5f4-4906-85aa-b049ed44d7e9@gmail.com>


--9QyKV9EEhg0eMfJA
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Thu, 30 Jan 2025 19:33:37 -0500
From: Demi Marie Obenour <demi@invisiblethingslab.com>
To: Demi Marie Obenour <demiobenour@gmail.com>,
	"Huang, Honglei1" <Honglei1.Huang@amd.com>,
	Huang Rui <ray.huang@amd.com>,
	virtualization@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org,
	Dmitry Osipenko <dmitry.osipenko@collabora.com>,
	dri-devel@lists.freedesktop.org, David Airlie <airlied@redhat.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Gurchetan Singh <gurchetansingh@chromium.org>,
	Chia-I Wu <olvaffe@gmail.com>,
	Akihiko Odaki <akihiko.odaki@daynix.com>,
	Lingshan Zhu <Lingshan.Zhu@amd.com>,
	Xen developer discussion <xen-devel@lists.xenproject.org>,
	Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>,
	Kernel KVM virtualization development <kvm@vger.kernel.org>,
	Xenia Ragiadakou <burzalodowa@gmail.com>,
	Stefano Stabellini <stefano.stabellini@amd.com>
Subject: Re: [RFC PATCH 3/3] drm/virtio: implement blob userptr resource
 object

On Wed, Jan 29, 2025 at 03:54:59PM -0500, Demi Marie Obenour wrote:
> On 1/8/25 12:05 PM, Simona Vetter wrote:
> > On Fri, Dec 27, 2024 at 10:24:29AM +0800, Huang, Honglei1 wrote:
> >>
> >> On 2024/12/22 9:59, Demi Marie Obenour wrote:
> >>> On 12/20/24 10:35 AM, Simona Vetter wrote:
> >>>> On Fri, Dec 20, 2024 at 06:04:09PM +0800, Honglei Huang wrote:
> >>>>> From: Honglei Huang <Honglei1.Huang@amd.com>
> >>>>>
> >>>>> A virtio-gpu userptr is based on HMM notifier.
> >>>>> Used for let host access guest userspace memory and
> >>>>> notice the change of userspace memory.
> >>>>> This series patches are in very beginning state,
> >>>>> User space are pinned currently to ensure the host
> >>>>> device memory operations are correct.
> >>>>> The free and unmap operations for userspace can be
> >>>>> handled by MMU notifier this is a simple and basice
> >>>>> SVM feature for this series patches.
> >>>>> The physical PFNS update operations is splited into
> >>>>> two OPs in here. The evicted memories won't be used
> >>>>> anymore but remap into host again to achieve same
> >>>>> effect with hmm_rang_fault.
> >>>>
> >>>> So in my opinion there are two ways to implement userptr that make s=
ense:
> >>>>
> >>>> - pinned userptr with pin_user_pages(FOLL_LONGTERM). there is not mmu
> >>>>    notifier
> >>>>
> >>>> - unpinnned userptr where you entirely rely on userptr and do not ho=
ld any
> >>>>    page references or page pins at all, for full SVM integration. Th=
is
> >>>>    should use hmm_range_fault ideally, since that's the version that
> >>>>    doesn't ever grab any page reference pins.
> >>>>
> >>>> All the in-between variants are imo really bad hacks, whether they h=
old a
> >>>> page reference or a temporary page pin (which seems to be what you're
> >>>> doing here). In much older kernels there was some justification for =
them,
> >>>> because strange stuff happened over fork(), but with FOLL_LONGTERM t=
his is
> >>>> now all sorted out. So there's really only fully pinned, or true svm=
 left
> >>>> as clean design choices imo.
> >>>>
> >>>> With that background, why does pin_user_pages(FOLL_LONGTERM) not wor=
k for
> >>>> you?
> >>>
> >>> +1 on using FOLL_LONGTERM.  Fully dynamic memory management has a hug=
e cost
> >>> in complexity that pinning everything avoids.  Furthermore, this avoi=
ds the
> >>> host having to take action in response to guest memory reclaim reques=
ts.
> >>> This avoids additional complexity (and thus attack surface) on the ho=
st side.
> >>> Furthermore, since this is for ROCm and not for graphics, I am less c=
oncerned
> >>> about supporting systems that require swappable GPU VRAM.
> >>
> >> Hi Sima and Demi,
> >>
> >> I totally agree the flag FOLL_LONGTERM is needed, I will add it in next
> >> version.
> >>
> >> And for the first pin variants implementation, the MMU notifier is also
> >> needed I think.Cause the userptr feature in UMD generally used like th=
is:
> >> the registering of userptr always is explicitly invoked by user code l=
ike
> >> "registerMemoryToGPU(userptrAddr, ...)", but for the userptr release/f=
ree,
> >> there is no explicit API for it, at least in hsakmt/KFD stack. User ju=
st
> >> need call system call "free(userptrAddr)", then kernel driver will rel=
ease
> >> the userptr by MMU notifier callback.Virtio-GPU has no other way to kn=
ow if
> >> user has been free the userptr except for MMU notifior.And in UMD ther=
es is
> >> no way to get the free() operation is invoked by user.The only way is =
use
> >> MMU notifier in virtio-GPU driver and free the corresponding data in h=
ost by
> >> some virtio CMDs as far as I can see.
> >>
> >> And for the second way that is use hmm_range_fault, there is a predict=
able
> >> issues as far as I can see, at least in hsakmt/KFD stack. That is the =
memory
> >> may migrate when GPU/device is working. In bare metal, when memory is
> >> migrating KFD driver will pause the compute work of the device in
> >> mmap_wirte_lock then use hmm_range_fault to remap the migrated/evicted
> >> memories to GPU then restore the compute work of device to ensure the
> >> correction of the data. But in virtio-GPU driver the migration happen =
in
> >> guest kernel, the evict mmu notifier callback happens in guest, a virt=
io CMD
> >> can be used for notify host but as lack of mmap_write_lock protection =
in
> >> host kernel, host will hold invalid data for a short period of time, t=
his
> >> may lead to some issues. And it is hard to fix as far as I can see.
> >>
> >> I will extract some APIs into helper according to your request, and I =
will
> >> refactor the whole userptr implementation, use some callbacks in page
> >> getting path, let the pin method and hmm_range_fault can be choiced
> >> in this series patches.
> >=20
> > Ok, so if this is for svm, then you need full blast hmm, or the semanti=
cs
> > are buggy. You cannot fake svm with pin(FOLL_LONGTERM) userptr, this do=
es
> > not work.
> >=20
> > The other option is that hsakmt/kfd api is completely busted, and that's
> > kinda not a kernel problem.
> > -Sima
>=20
> On further thought, I believe the driver needs to migrate the pages to
> device memory (really a virtio-GPU blob object) *and* take a FOLL_LONGTERM
> pin on them.  The reason is that it isn=E2=80=99t possible to migrate the=
se pages
> back to "host" memory without unmapping them from the GPU.  For the reaso=
ns
> I mention in [1], I believe that temporarily revoking access to virtio-GPU
> blob objects is not feasible.  Instead, the pages must be treated as if
> they are permanently in device memory until guest userspace unmaps them
> from the GPU, after which they must be migrated back to host memory.

Discussion on IRC indicates that migration isn't reliable.  This is
because Linux core memory management is largely lock-free for
performance reasons, so there is no way to prevent temporary elevation
of a page's reference count.  A page with an elevated reference count
cannot be migrated.

The only alternative I can think of is for the hypervisor to perform the
migration.  The hypervisor can revoke the guest's access to the page
without the guest's consent or involvement.  The host can then replace
the page with one of its own pages, which might be on the CPU or GPU.
Further migration between the CPU and GPU is controlled by the host
kernel-mode driver (KMD) and host kernel memory management.  The guest
kernel driver must take a FOLL_LONGTERM pin before telling the host to
use the pages, but that is all.

On KVM, this should be essentially automatic, as guest memory really is
just host userspace memory.  On Xen, this requires that the backend
domain can revoke fronted access to _any_ frontend page, or at least
frontend pages that have been granted to the backend.  The backend will
then need to be able to handle page faults for the frontend pages, and
replace the frontend pages with its own pages at will.  Furthermore,
revoking pages that the backend has installed into the frontend must
never fail, because the backend will panic if it does fail.

Sima, is putting guest pages under host kernel control the only option?
I thought that this could be avoided by leaving the pages on the CPU if
migration fails, but that won't work because there will be no way to
migrate them to the GPU later, causing performance problems that would
be impossible to debug.  Is waiting (possibly forever) on migration to
finish an option?  Otherwise, this might mean extra complexity in the
Xen hypervisor, as I do not believe the primitives needed are currently
available.  Specifically, in addition to the primitives discussed at Xen
Project Summit 2024, the backend also needs to intercept access to, and
replace the contents of, arbitrary frontend-controlled pages.
--=20
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

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

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

iQIzBAEBCAAdFiEEopQtqVJW1aeuo9/sszaHOrMp8lMFAmecGmEACgkQszaHOrMp
8lMt/w/9EultembzZOpL8oYFzpDKH4QFhJkkcONDqVqYYE5kH122Mqj5GsprGGW0
FqvHAgK5Qk/W+zz9LQrk+P6WEwJhP0XIo/TKJfSCOXqK6pEqwyZ8OPk1nHAiPli/
D7bm3ocsg69tYGoLsCylZehwUe87ATZZ43KVsh+bf1h+lRHONd8yOs46nSzJuxzl
zEOI373RpZVKzpRx3HQfyzS9oALVzvdyGzeX+1n3AmQyDbZtjs4ZInyyng4ruArL
viZtevqVe6boeeemKkZaGtGOzaiVZAmwX3PjTNXbIygsogzscCrMUfL3ZOYbg9D/
P18aWdQEu5f7+Vt5PL4sOfY6AsmArvlwAKWVQdmpk8eTTuW6fDk0651ogKcNFiV9
cgCJhv5SBa/hoas8i4nj2pl58AdfjaZFGtdXsEuKzQ2D7N6LivWZGOsbwfK+NVdT
AdzfuyH0M41tQw0Oy57NmnnbnC7clqk1wn8UTTSfxmtFWCVhBoMx25WgIK/fGUvp
JOHj+9q/MfD0A+dY0jng45Y8Kf7saNMMWmpmT0NNoAAnNWZzSJgO7+2IHjjd6DTn
K07huXex3wpOxtBnd42TWMb5fxiwtU48XhGRz7ZNyhPlakaK/ZKjJX8bE2WrLOrA
bAwm93etZnI91f08VSApkuYCYUCAh8nk/k6GDDdAkvWTWfsJ09w=
=U2FS
-----END PGP SIGNATURE-----

--9QyKV9EEhg0eMfJA--


From xen-devel-bounces@lists.xenproject.org Fri Jan 31 00:34:03 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 31 Jan 2025 00:34:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879811.1290025 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdeyx-00005p-B9; Fri, 31 Jan 2025 00:34:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879811.1290025; Fri, 31 Jan 2025 00:34:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdeyx-00005i-8S; Fri, 31 Jan 2025 00:34:03 +0000
Received: by outflank-mailman (input) for mailman id 879811;
 Fri, 31 Jan 2025 00:34: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
 <SRS0=HyPN=UX=tklengyel.com=tamas@srs-se1.protection.inumbo.net>)
 id 1tdeyv-0008Ee-QS
 for xen-devel@lists.xenproject.org; Fri, 31 Jan 2025 00:34:01 +0000
Received: from sender3-op-o16.zoho.com (sender3-op-o16.zoho.com
 [136.143.184.16]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0f916847-df6b-11ef-99a4-01e77a169b0f;
 Fri, 31 Jan 2025 01:34:00 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1738283632693270.94448674437433;
 Thu, 30 Jan 2025 16:33:52 -0800 (PST)
Received: by mail-yw1-f179.google.com with SMTP id
 00721157ae682-6efea3c9e6eso3652527b3.0
 for <xen-devel@lists.xenproject.org>; Thu, 30 Jan 2025 16:33:52 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 0f916847-df6b-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; t=1738283636; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=EDZQTcgoFoCK55+dBNDQLVclL/4tcCA06TPxq0KyzhgiSpTKVzR/fYwtFt6V4rb2ZXjZfGVs2ejzRAEOlcz7tRiFZZi834p//QEDjMUsK6pi2KXngCHS4t/Da1JPP56HF1QjgMA14BfjKitxxRwvFzNZVeerDKYV0G80ih1oCJg=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1738283636; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=DGwOUai/U6rjKQW0Y8Iz7PQi4zjz0YJNw64ucG7bSRc=; 
	b=TRIHoQUHoUehI5nF3B+FS/xe8xzUVg3z+Al2vvQEOH6LyhkMzl1H47ck2xs22m0c7awrZdk61S5TuHwACyZai/yxAefKOWZc/Ab/yj596KUWYBgOHiwFY/Hk2K3kXKfGJy9Ym2pA+T33zmYRTn6KZRfH0VgZ1SP/ac0UgzFLUfI=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=tklengyel.com;
	spf=pass  smtp.mailfrom=tamas@tklengyel.com;
	dmarc=pass header.from=<tamas@tklengyel.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1738283636;
	s=zmail; d=tklengyel.com; i=tamas@tklengyel.com;
	h=MIME-Version:References:In-Reply-To:From:From:Date:Date:Message-ID:Subject:Subject:To:To:Cc:Cc:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=DGwOUai/U6rjKQW0Y8Iz7PQi4zjz0YJNw64ucG7bSRc=;
	b=M/+L4wZbczLGOg07bJZfCu+peMyfg6L+OoZbs3dJt05oS/xoZdwpQKzZBriNUf7E
	UrzqEEeGGdtlZsFzzYYef3nzpSV5qxw8Rlvk9A6jzGI3LTxWTB9RNnnlD+vob92T9qW
	scHu1F/dDkTFtlvEnaKipRNi1LVLCsiLhcO5lV0w=
X-Gm-Message-State: AOJu0Ywhj/NBrgDxmQaUIta/wFfSN/1YU5I8KdxjCsMuUl5DrLA5zu6W
	ir4LOEu4cY8XAEUybMzIe4+q4TxBLVLV+4DpnfC/gj+nkFNDwpmsPfJbfUdiZQbDgKMvG95OQpz
	U/0FQkusKB0riVzUwJmfNvHwShaU=
X-Google-Smtp-Source: AGHT+IFiESrzHXvdxSl+eZgwHrVF87qZTJs+7fx/bknQTXtcM7CItYeo4pF086kcd2fOYV6vg3VldDtg27BS7PyQILw=
X-Received: by 2002:a05:690c:1c:b0:6f5:3bb1:7b7f with SMTP id
 00721157ae682-6f7a83fcecdmr74947787b3.26.1738283631942; Thu, 30 Jan 2025
 16:33:51 -0800 (PST)
MIME-Version: 1.0
References: <cover.1737452864.git.Sergiy_Kibrik@epam.com> <2e8b9c5390019ef66610a21d9a8744282e2badeb.1737452864.git.Sergiy_Kibrik@epam.com>
In-Reply-To: <2e8b9c5390019ef66610a21d9a8744282e2badeb.1737452864.git.Sergiy_Kibrik@epam.com>
From: Tamas K Lengyel <tamas@tklengyel.com>
Date: Thu, 30 Jan 2025 19:33:16 -0500
X-Gmail-Original-Message-ID: <CABfawhkw-MDvVnfgTi44YHA9JYSkzFS6VkdtLdH33big9BcHdA@mail.gmail.com>
X-Gm-Features: AWEUYZkccRk1IKZk8pr4WIqF3sRseIK9Q36IU3s36578TlFvgUBYgcpYQ9I6zNU
Message-ID: <CABfawhkw-MDvVnfgTi44YHA9JYSkzFS6VkdtLdH33big9BcHdA@mail.gmail.com>
Subject: Re: [PATCH v2 4/4] xen: mem_access: conditionally compile vm_event.c
 & monitor.c
To: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
Cc: xen-devel@lists.xenproject.org, 
	Stefano Stabellini <stefano.stabellini@amd.com>, Julien Grall <julien@xen.org>, 
	Bertrand Marquis <bertrand.marquis@arm.com>, Michal Orzel <michal.orzel@amd.com>, 
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>, Andrew Cooper <andrew.cooper3@citrix.com>, 
	Anthony PERARD <anthony.perard@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
	Alexandru Isaila <aisaila@bitdefender.com>, Petre Pircalabu <ppircalabu@bitdefender.com>, 
	Stefano Stabellini <sstabellini@kernel.org>, Jan Beulich <jbeulich@suse.com>, 
	Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 21, 2025 at 5:25=E2=80=AFAM Sergiy Kibrik <Sergiy_Kibrik@epam.c=
om> wrote:
>
> From: Stefano Stabellini <stefano.stabellini@amd.com>
>
> Extend coverage of CONFIG_VM_EVENT option and make the build of VM events
> and monitoring support optional.
> This is to reduce code size on Arm when this option isn't enabled.
>
> CC: Jan Beulich <jbeulich@suse.com>
> CC: Tamas K Lengyel <tamas@tklengyel.com>
> Reviewed-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
> Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
> ---
> changes in v2:
>  - rename CONFIG_MEM_ACCESS -> CONFIG_VM_EVENT
>  - tags
> ---
>  xen/arch/arm/Makefile      |  4 ++--
>  xen/arch/arm/vsmc.c        |  3 ++-
>  xen/common/Makefile        |  4 ++--
>  xen/include/xen/monitor.h  |  9 +++++++++
>  xen/include/xen/vm_event.h | 14 +++++++++++---
>  5 files changed, 26 insertions(+), 8 deletions(-)
>
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index ad29316df1..e61238c4d0 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -39,7 +39,7 @@ obj-$(CONFIG_LIVEPATCH) +=3D livepatch.o
>  obj-$(CONFIG_LLC_COLORING) +=3D llc-coloring.o
>  obj-$(CONFIG_VM_EVENT) +=3D mem_access.o
>  obj-y +=3D mm.o
> -obj-y +=3D monitor.o
> +obj-$(CONFIG_VM_EVENT) +=3D monitor.o
>  obj-y +=3D p2m.o
>  obj-y +=3D platform.o
>  obj-y +=3D platform_hypercall.o
> @@ -65,7 +65,7 @@ obj-$(CONFIG_VGICV2) +=3D vgic-v2.o
>  obj-$(CONFIG_GICV3) +=3D vgic-v3.o
>  obj-$(CONFIG_HAS_ITS) +=3D vgic-v3-its.o
>  endif
> -obj-y +=3D vm_event.o
> +obj-$(CONFIG_VM_EVENT) +=3D vm_event.o
>  obj-y +=3D vtimer.o
>  obj-$(CONFIG_SBSA_VUART_CONSOLE) +=3D vpl011.o
>  obj-y +=3D vsmc.o
> diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
> index 62d8117a12..1ea75cd7f1 100644
> --- a/xen/arch/arm/vsmc.c
> +++ b/xen/arch/arm/vsmc.c
> @@ -330,7 +330,8 @@ void do_trap_smc(struct cpu_user_regs *regs, const un=
ion hsr hsr)
>      }
>
>      /* If monitor is enabled, let it handle the call. */
> -    if ( current->domain->arch.monitor.privileged_call_enabled )
> +    if ( IS_ENABLED(CONFIG_VM_EVENT) &&
> +         current->domain->arch.monitor.privileged_call_enabled )
>          rc =3D monitor_smc();

Why not wrap this entire if block above in an #ifdef CONFIG_VM_EVENT?
I think it would be more explicit what code is being compiled that way
instead of just relying on the compiler optimization to take care of
removing it. The rest of the patch looks fine to me.

Tamas


From xen-devel-bounces@lists.xenproject.org Fri Jan 31 05:10:54 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 31 Jan 2025 05:10:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879832.1290036 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdjIe-0006YR-3V; Fri, 31 Jan 2025 05:10:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879832.1290036; Fri, 31 Jan 2025 05:10:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdjId-0006YF-V0; Fri, 31 Jan 2025 05:10:39 +0000
Received: by outflank-mailman (input) for mailman id 879832;
 Fri, 31 Jan 2025 05:10: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
 <SRS0=KoDZ=UX=daynix.com=akihiko.odaki@srs-se1.protection.inumbo.net>)
 id 1tdjIc-0006Y6-M6
 for xen-devel@lists.xenproject.org; Fri, 31 Jan 2025 05:10:39 +0000
Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com
 [2607:f8b0:4864:20::632])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b2bbedae-df91-11ef-a0e6-8be0dac302b0;
 Fri, 31 Jan 2025 06:10:34 +0100 (CET)
Received: by mail-pl1-x632.google.com with SMTP id
 d9443c01a7336-216634dd574so18537165ad.2
 for <xen-devel@lists.xenproject.org>; Thu, 30 Jan 2025 21:10:34 -0800 (PST)
Received: from [157.82.205.237] ([157.82.205.237])
 by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-72fe6a1ab2fsm2394763b3a.170.2025.01.30.21.10.29
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 30 Jan 2025 21:10:32 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b2bbedae-df91-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=daynix-com.20230601.gappssmtp.com; s=20230601; t=1738300233; x=1738905033; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=5AEuIBL2MpqAbCSETjlQmOC2W7ELmv7LgDjDwZVJiAM=;
        b=GHyJ84wrd1iLkmILIeTuYXsw9btkrBjhtTbGIyNwAoQ3ggin0wDesWI55rv63dsEWE
         dPbxjeGQQu4ZSyd6G8/cGQNe1/T/0kE7Gaoky8cm7jn/qd9ymP71Wgv/M8uHkhboSSXO
         2OyJzv6oc3AB371/LxDbgOBUTiUMwt0f4u15OaWbEJWUMiiPz1w0AXMSgAujZc6At5A9
         bJATmNwyOEJ8wFoDwOLZdbYRKCg5TVkeCwTCXTTohaej/V8zNDR/9CPvYCOGgfynsRY9
         YpBtKzO3/Imkfzt3Aiz5G2E5yw/ESwBIYqF1jcBJlwWu4O+Gm8P1Y4kK+QPT/kXM87la
         GZ2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738300233; x=1738905033;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=5AEuIBL2MpqAbCSETjlQmOC2W7ELmv7LgDjDwZVJiAM=;
        b=wmEgTX8S9tSdHZOG9QNOeDhs5JKww2skUmtMcOw503tFB1qS2T5jXJP1cYfaRLCus4
         3DgST067+AFzCbxymjmf2cRj2On56z0LKvJWGvV15dfUeEg71JIucwUHD9wsdT6Uan/u
         9dX7S+nYvCAde2NrSvLMAYWgT8hJVKnsyzntCYLzrfcheDsxuDnEeOxSBGYuIyBMCmO8
         M49cNqaS/ucykr32VB4/p54eGmTSdlni5JoW8eTGW/PbEa9g2+3UgYOFVDAoH1QfBkII
         51pY6cQKytG+CDwUtE1hoq1v7+9y0LfHVoRldkseb5p5R3JdIOzwuvhpm4KUGCW5FNa1
         NDOg==
X-Forwarded-Encrypted: i=1; AJvYcCVQ9DoEy6PXkMYRqpW06YfzKYTB8v8RurUUrRCnpzV67xa2VSHjvibmTOEcPWJTtujMJ84pOPCnlp4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxTsk1bWwSG9KHw0mx6c4rFp6yLlj2kEvZyp/IsXPIWhDtNXcYG
	VbOmeloFr+mAbPfWNLohOR7iKxffSBlfZEN3rRwh21UlJ+EWdhXyOtW+DoYN8hQ=
X-Gm-Gg: ASbGnct5azNQQynWhorY6X4f7Zft3+zKrsucks3r3o489CmjYOvsB2iXU1haUNUrlk9
	uzQHmw6/1fg4vv8hfh5uEvyM/Ad7gFwd1krtQ7XbVRUdOQrCJPvSmzdFET4Mc5OSrOy2Wx394gs
	m/8aqQqvs/6GUxn4kRu/DRM53U5KJOhT+XXDaN9Xk2C0sRu8DmIirnOsHQ8GDD48IIIywPYWSMW
	W1fQ8iXOry4napSj9ftOiTA1uSXXu3h31qm2K7j8QIC2cOxHku4Z7/q2XZKTQ9Hno69rWFCydgK
	8OapgPbywT02ELUVHs8SdV51tkUQ
X-Google-Smtp-Source: AGHT+IEERU4Y46yPMbU8raM379YD/b5udqcqVEsnknx9lXHDT/ie/0QIeIU/54YQkQtrxoQmIg9iVw==
X-Received: by 2002:a05:6a21:458a:b0:1e6:8f10:8ba2 with SMTP id adf61e73a8af0-1ed7a462f12mr15978249637.9.1738300232735;
        Thu, 30 Jan 2025 21:10:32 -0800 (PST)
Message-ID: <bc74db8a-2970-47ab-b0ba-ede783299abc@daynix.com>
Date: Fri, 31 Jan 2025 14:10:28 +0900
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 0/2] tests/qtest: Make qtest_has_accel() generic
To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= <philmd@linaro.org>,
 qemu-devel@nongnu.org
Cc: =?UTF-8?Q?Daniel_P_=2E_Berrang=C3=A9?= <berrange@redhat.com>,
 Paolo Bonzini <pbonzini@redhat.com>, Bernhard Beschow <shentey@gmail.com>,
 Thomas Huth <thuth@redhat.com>, Markus Armbruster <armbru@redhat.com>,
 Fabiano Rosas <farosas@suse.de>, Phil Dennis-Jordan <phil@philjordan.eu>,
 xen-devel@lists.xenproject.org, Laurent Vivier <lvivier@redhat.com>
References: <20250130103728.536-1-philmd@linaro.org>
Content-Language: en-US
From: Akihiko Odaki <akihiko.odaki@daynix.com>
In-Reply-To: <20250130103728.536-1-philmd@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 2025/01/30 19:37, Philippe Mathieu-Daudé wrote:
> (Series fully reviewed)
> 
> Since v1:
> - Use g_strconcat (Akihiko)
> 
> In preparation of running QTests using HVF on Darwin,
> make qtest_has_accel() generic.
> 
> Note, this also allow running other accelerators such
> Xen, WHPX, ...
> 
> Philippe Mathieu-Daudé (2):
>    tests/qtest: Extract qtest_qom_has_concrete_type() helper
>    tests/qtest: Make qtest_has_accel() generic
> 
>   tests/qtest/libqtest.c | 110 +++++++++++++++++++++++------------------
>   1 file changed, 61 insertions(+), 49 deletions(-)
> 

Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>


From xen-devel-bounces@lists.xenproject.org Fri Jan 31 06:30:51 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 31 Jan 2025 06:30:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879840.1290046 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdkY1-0007Yl-HD; Fri, 31 Jan 2025 06:30:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879840.1290046; Fri, 31 Jan 2025 06:30:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdkY1-0007Ye-DU; Fri, 31 Jan 2025 06:30:37 +0000
Received: by outflank-mailman (input) for mailman id 879840;
 Fri, 31 Jan 2025 06:30:36 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=aogm=UX=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tdkY0-0007YY-NH
 for xen-devel@lists.xenproject.org; Fri, 31 Jan 2025 06:30:36 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e07f1871-df9c-11ef-a0e6-8be0dac302b0;
 Fri, 31 Jan 2025 07:30:35 +0100 (CET)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-aaec61d0f65so171295866b.1
 for <xen-devel@lists.xenproject.org>; Thu, 30 Jan 2025 22:30:35 -0800 (PST)
Received: from ?IPV6:2003:ca:b741:f10a:3123:f9e9:b484:6874?
 (p200300cab741f10a3123f9e9b4846874.dip0.t-ipconnect.de.
 [2003:ca:b741:f10a:3123:f9e9:b484:6874])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab6e47a7e90sm242505266b.11.2025.01.30.22.30.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 30 Jan 2025 22:30:33 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e07f1871-df9c-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738305034; x=1738909834; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=1W4c8uBbuL7vMjIiA9qV8VqjX57zd2oaWcyYJ5Ma2m4=;
        b=PxB2EPhvPSsMtYqy8TQHFE7t8CvXDL+YurmcOkxExu7Z/+huHMbG7vSTXQezNzIICS
         +lBIZaNd9bCWE3MuJ8r32wSMKsldSnSndN2auAJekeld/v+P9h/SfsZkOY2VZIwB6E6h
         w+yIYIbaEZIVeiA8MpXuZrxZfgp0uvNN1ztqb5C/T79gsA0A9RrMaCEC/SuSzsiD+VNn
         yXGCQdglKY3lKPiloO0wK1jVR605OCpFCvHJyiEBLIqPcNxQPmliElUixDcyQYyCvmrU
         f4cRZ6BqfdNh3I80SPLffyOMOhWAMtNPMy9qxECJ0uVCM3yQZb5Q7NtrYt0m/MISYImQ
         UB/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738305034; x=1738909834;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=1W4c8uBbuL7vMjIiA9qV8VqjX57zd2oaWcyYJ5Ma2m4=;
        b=SuOKANPXaXSk1Uz+hG9Kh4ua1Lpi1RWYC81P+uL4v1jTakvoarcWaO5WfvCf2M+gRM
         5fec2PhxzJmz7qWlRCESE8oqX4BitInGYmw5WSeXWZCXDb3tO+jDRjtvn3vUIEe+FYEm
         BpJ7aiW5/qE1e2ROh30O3YJsF+qTBRbPsm+Vb2ewS/7XtXR+bqZW89708M41pli4yWMV
         JymP7fGeq0ppS0ClR+Y3UErGX7vddPIbDWdZjSsdJuYX7+sPYrBeSuZWG4jK7A5/JkB0
         iNexxvEwrM0udDJfCCmiOK5av40tpq6gLi1jNmFGzYGTBawDBr+nqFae7I4iYk3uqrpM
         cl3w==
X-Forwarded-Encrypted: i=1; AJvYcCWoIQjnUa7wyrBGxV8E1xVm16/KEYoTRLIlRJCyXKU6CuWf/mVDOoGZQ+3jc6w/kfo7hPnUkkePA/g=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzawmNLVEhZEqFLEouW0hUDlUKmzTxwku+pdvsB8kyEEe1LXnW3
	NrL3lc3KJnilJSHeKzpmSSZ/280KYTKPxZeAsVbfHO51ELYmJRvuQ3/zl+EtWA==
X-Gm-Gg: ASbGncu+kJvH0Js1+7TLa2hNrW7C08iiEmJ/qFIauLiyMoIgayT9rcX1u4eus8FI3pE
	ovnbViO1BtUP/0pnUb9+YV73z3ZinZwCeXd6lPlS5XIaTnjgam1PZeFrPZccXLnNplziajv3Wvs
	UcOXsE0nHLYbKORYHowLgS6HbyLwfEgIV1rPc5q6nmEk8aXb1xy6fyvUzI7cev4cJc0jnwBY2D5
	kYSLSUGgWVcL2dg6MLHO6OQsWOgNd5Dhq9k+J3NWn/ZO3wQ/sNrhew8lcEpuU65Vb8gkFATzwfV
	d8JvoQ0FNKotuw3sD+E7JHZsdTuUs+uUuQn/662Kw5Lhr/xuGrTFx2LXRQI+0VqIEBxA9Ig5bpe
	nce3CdTu8ckPJKYk1KZOEEkNy0etCej+WLH8VlYfb5AkuJNKtOw==
X-Google-Smtp-Source: AGHT+IHw9EWsQunkJ67ku6vDrhG0u3Mp0tYaedwIIlSK7KBhJp6NuCZsWpP2wbG5QG2Q3z8h3vh92Q==
X-Received: by 2002:a17:907:7da2:b0:aae:fd36:f511 with SMTP id a640c23a62f3a-ab6cfe4003amr1086413066b.47.1738305034144;
        Thu, 30 Jan 2025 22:30:34 -0800 (PST)
Message-ID: <b850c2b1-5aa9-4e64-9161-ba55028b43a7@suse.com>
Date: Fri, 31 Jan 2025 07:30:29 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/4] xen: kconfig: rename MEM_ACCESS -> VM_EVENT
To: Tamas K Lengyel <tamas@tklengyel.com>
Cc: Sergiy Kibrik <Sergiy_Kibrik@epam.com>, Julien Grall <julien@xen.org>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Alexandru Isaila <aisaila@bitdefender.com>,
 Petre Pircalabu <ppircalabu@bitdefender.com>,
 Shawn Anastasio <sanastasio@raptorengineering.com>,
 Alistair Francis <alistair.francis@wdc.com>,
 Bob Eshleman <bobbyeshleman@gmail.com>, Connor Davis
 <connojdavis@gmail.com>, Oleksii Kurochko <oleksii.kurochko@gmail.com>,
 "Daniel P. Smith" <dpsmith@apertussolutions.com>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1737452864.git.Sergiy_Kibrik@epam.com>
 <ff22f35dafd04b16165e1caec038e5a5fcf2aeee.1737452864.git.Sergiy_Kibrik@epam.com>
 <c74d334e-6e33-4a58-bf94-936249244cb0@suse.com>
 <CABfawhm8Cb3xz8Fv=YhA1TSKtvA3ThWHMcqJCFDarwSuYKQ5ZA@mail.gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <CABfawhm8Cb3xz8Fv=YhA1TSKtvA3ThWHMcqJCFDarwSuYKQ5ZA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 31.01.2025 01:26, Tamas K Lengyel wrote:
> On Thu, Jan 30, 2025 at 8:24 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 21.01.2025 11:19, Sergiy Kibrik wrote:
>>> Use more generic CONFIG_VM_EVENT name throughout Xen code instead of
>>> CONFIG_MEM_ACCESS. This reflects the fact that vm_event is a higher level
>>> feature, with mem_access & monitor depending on it.
>>>
>>> Suggested-by: Jan Beulich <jbeulich@suse.com>
>>
>> I don't think this is applicable; my suggestion went in a different direction.
>>
>>> Suggested-by: Tamas K Lengyel <tamas@tklengyel.com>
>>> Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
>>
>> Before considering to ack this, I'd like you, Tamas, to confirm this is really
>> what you had thought of. In particular ...
>>
>>> --- a/xen/arch/arm/Makefile
>>> +++ b/xen/arch/arm/Makefile
>>> @@ -37,7 +37,7 @@ obj-y += irq.o
>>>  obj-y += kernel.init.o
>>>  obj-$(CONFIG_LIVEPATCH) += livepatch.o
>>>  obj-$(CONFIG_LLC_COLORING) += llc-coloring.o
>>> -obj-$(CONFIG_MEM_ACCESS) += mem_access.o
>>> +obj-$(CONFIG_VM_EVENT) += mem_access.o
>>
>> ... changes like this one look somewhat odd to me.
>>
>>> --- a/xen/common/Kconfig
>>> +++ b/xen/common/Kconfig
>>> @@ -92,7 +92,7 @@ config HAS_VMAP
>>>  config MEM_ACCESS_ALWAYS_ON
>>>       bool
>>>
>>> -config MEM_ACCESS
>>> +config VM_EVENT
>>>       def_bool MEM_ACCESS_ALWAYS_ON
>>>       prompt "Memory Access and VM events" if !MEM_ACCESS_ALWAYS_ON
>>>       depends on HVM
>>
>> What about MEM_ACCESS_ALWAYS_ON (visible in patch context)? Shouldn't that
>> become VM_EVENT_ALWAYS_ON then, too?
>>
>> Further, what about MEM_PAGING and MEM_SHARING? Shouldn't those, at least
>> documentation purposes, then also gain a dependency on VM_EVENT?
> 
> MEM_PAGING, yes. MEM_SHARING, definitely not. MEM_SHARING is perfectly
> functional without vm_event.

Is it? I see e.g.

    if ( sharing_enomem )
    {
#ifdef CONFIG_MEM_SHARING
        if ( !vm_event_check_ring(currd->vm_event_share) )
        {
            gprintk(XENLOG_ERR, "Domain %pd attempt to unshare "
                    "gfn %lx, ENOMEM and no helper\n",
                    currd, gfn);
            /* Crash the domain */
            rc = 0;
        }
#endif
    }

in hvm_hap_nested_page_fault().

Also - you responded only to a secondary remark here. What about the
more basic points further up?

Jan


From xen-devel-bounces@lists.xenproject.org Fri Jan 31 06:36:46 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 31 Jan 2025 06:36:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879848.1290056 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdkdv-0008Bv-4y; Fri, 31 Jan 2025 06:36:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879848.1290056; Fri, 31 Jan 2025 06:36:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdkdv-0008Bo-2M; Fri, 31 Jan 2025 06:36:43 +0000
Received: by outflank-mailman (input) for mailman id 879848;
 Fri, 31 Jan 2025 06:36:41 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=aogm=UX=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tdkdt-0008Bi-TZ
 for xen-devel@lists.xenproject.org; Fri, 31 Jan 2025 06:36:41 +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 bad1f507-df9d-11ef-a0e6-8be0dac302b0;
 Fri, 31 Jan 2025 07:36:41 +0100 (CET)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-437a92d7b96so15848065e9.2
 for <xen-devel@lists.xenproject.org>; Thu, 30 Jan 2025 22:36:41 -0800 (PST)
Received: from ?IPV6:2003:ca:b741:f10a:3123:f9e9:b484:6874?
 (p200300cab741f10a3123f9e9b4846874.dip0.t-ipconnect.de.
 [2003:ca:b741:f10a:3123:f9e9:b484:6874])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38c5c1cfa2fsm3900170f8f.91.2025.01.30.22.36.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 30 Jan 2025 22:36:40 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: bad1f507-df9d-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738305400; x=1738910200; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=A+1DnVEFLzfE5r0bS0gsVg8+jdgAAOBfGlCLm8njAgQ=;
        b=cmWA3QA9Vi6ERqhDJRyEP5A0dSyhfGJ0JA4LOM4DtqnxVciC4D4MDPVtmcR+LR5PxH
         wrzcLFFRIhQc7z5njisa233BXCc6UPbSGEQHO4hnGNMTuvENPsXyslKDMYG/D429ZOva
         A2M4xV1o5keE+rVQBpAN68F+dNtJx79yd+ExQkYQPqo0bRq+KUVMWD7tzeJZfyQFJ/cW
         bTVlU6E0T8SMXooYHxi3SWLKNkvjhmkY+md9KOkByWfQTXFBu5OMiK8d+1juBl6oq7Qi
         2CEMm7v8b59UUgRXCY9k3BMviXRS6Gu17s2Tb0cmQoxUADm4pYZl00/6/xiIpfvsTZV8
         Nf3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738305400; x=1738910200;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=A+1DnVEFLzfE5r0bS0gsVg8+jdgAAOBfGlCLm8njAgQ=;
        b=fyUI55AgCC3pQdvXdOOHm6A92NdQoC4Rh2RATeUH2/Sv0tSeAy6gcFq0jN7dEICIqB
         YOUmROLx0OLaGRmWTKIz17Fuiyk8oQODfE8WW3q7doiStKchTViKlGRDcaV3DjVZv+5J
         0nPRVPjt/2R3f9lt86Bl7bD75eFCpReO/cWrmOHTHlQNezzDgLBmd4lP98oV47rC88Zv
         h+j3APAHHX5DM6aU4J3x2fIbnqjd4r+bJTFGspWoWcpvgD5OTnukrpDNRYF5wxmzVDzd
         FhHl6ak0eRwI54Xolz1Ij1jIikFFajw5XoEUEE42xkLU5wnf+/GUpvBOo1Dwz3RljZ2b
         eP4A==
X-Forwarded-Encrypted: i=1; AJvYcCXQZXpMnmNdWIE1iAdDeHasq/P/Fx/yhad99/V2S5EUOT83LfIH0zfOxdZEbQTpI37ZUdjLBoEnyro=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzJC2U4Xbwq+Na07FMvs0UjVtqdKfyfC+pFBSo46FMblGlbxyeZ
	htG3uVf5bKDrFsgv015U///fuUtuNnjr6RgDi83CbzQIlgvVoD6Ykkh1UqcC0A==
X-Gm-Gg: ASbGncufu9cdBeIDs5gwCrexfR7W3FYnRy2DewNVNOu4wN3z7LCbQ6X6GZi6te3wW45
	wgXAZaqIsoPNIIapyZ4a2/F0K4eghlyO2rcyb3OV09A02EGQmgK8tMdv/Hia4vdVpWGGQWEAf4n
	S1BWH1XLBjJSwEgnDJWd31XpnCCqF+Xz+fSutBxlVuxmqjmOlFhFGM3f+ig/yRImd2U0WNotrqg
	wNCmNMrgt3dkyyePHF7E/N6bzgKEZFdwwsAg1gGwGivTgTwkUN6Ff5eZfmxSqpUyazVdpDIeCLW
	NR7S4W07miUEGQ7Zs6QBDzUDUlQy+qKG1BKqk8hqApLsYZZmz/xnqn0xJaBIBbPD+f0k8TKigot
	vrTrIVBwccDtcVgZDMZ99VvcN+N4xqpuqvgXjaIpL3A0AnXqeCA==
X-Google-Smtp-Source: AGHT+IEuCPzRmhlKb94RcqQsTE/JvZBQ1e+nFfrmO/b/Z6P5A5t5+xi7IxRJYx5hbw93KD9lsQLemg==
X-Received: by 2002:a05:6000:4008:b0:386:37f5:99f6 with SMTP id ffacd0b85a97d-38c520bc551mr8972429f8f.53.1738305400475;
        Thu, 30 Jan 2025 22:36:40 -0800 (PST)
Message-ID: <eb927472-5399-4a82-aefd-7ffd28e09788@suse.com>
Date: Fri, 31 Jan 2025 07:36:36 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 08/15] x86/hyperlaunch: locate dom0 kernel with
 hyperlaunch
To: Stefano Stabellini <sstabellini@kernel.org>,
 "Daniel P. Smith" <dpsmith@apertussolutions.com>
Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com,
 stefano.stabellini@amd.com, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Julien Grall <julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>, xen-devel@lists.xenproject.org
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
 <20241226165740.29812-9-dpsmith@apertussolutions.com>
 <efc352d6-e686-435c-98b3-2333b6dee6a3@suse.com>
 <alpine.DEB.2.22.394.2501301250410.11632@ubuntu-linux-20-04-desktop>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <alpine.DEB.2.22.394.2501301250410.11632@ubuntu-linux-20-04-desktop>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 30.01.2025 22:14, Stefano Stabellini wrote:
> On Thu, 30 Jan 2025, Jan Beulich wrote:
>> On 26.12.2024 17:57, Daniel P. Smith wrote:
>>> Look for a subnode of type `multiboot,kernel` within a domain node. If found,
>>> process the reg property for the MB1 module index. If the bootargs property is
>>> present and there was not an MB1 string, then use the command line from the
>>> device tree definition.
>>
>> While multiboot is apparently the first x86-specific part (as far as Xen goes)
>> to be put under domain-builder/, I wonder:
>> - Wouldn't looking for "multiboot,kernel" simply yield nothing on non-x86,
>>   so having the code under common/ would still be okay?
> 
> One small clarification: multiboot,kernel is actually common between
> both ARM and x86. It is "module-index" which is x86-specific and would
> "simply yield nothing on non-x86", as you wrote.
> 
> I'll let Dan address your point that "having the code under common/
> would still be okay".
> 
> 
>> - What's "multiboot" describing here? The origin of the module? (What other
>>   origins would then be possible? How would MB1 and MB2 be distinguished?
>>   What about a native xen.efi boot?) A property of the kernel (when Linux
>>   doesn't use MB)?
> 
> Each device tree node has a compatible string to qualify what kind of
> information the node is describing. The compatible string for device
> tree nodes describing a kernel binary or a ramdisk previously loaded
> into memory by a bootloader have a "multiboot," prefix. See
> docs/misc/arm/device-tree/booting.txt. This is unrelated to the binary
> multiboot protocol Grub uses on x86 to boot Xen.
> 
> A distinction between MB1 and MB2 is not needed in device tree, that
> information is retrieved via the Grub multiboot protocol as usual. The
> only thing needed here in device tree is the location of the kernel,
> either by RAM address, or by Grub multiboot module index. This last
> option (Grub multiboot module index) is the "module-index" property I
> mentioned above.

Hmm, then I'm afraid I can't make sense of the mentioning of MB1 in the
description. Yet that's a point more towards Daniel than you.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Jan 31 06:39:00 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 31 Jan 2025 06:39:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879858.1290065 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdkg6-0000MZ-KW; Fri, 31 Jan 2025 06:38:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879858.1290065; Fri, 31 Jan 2025 06:38:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdkg6-0000MS-I1; Fri, 31 Jan 2025 06:38:58 +0000
Received: by outflank-mailman (input) for mailman id 879858;
 Fri, 31 Jan 2025 06:38:57 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=Snzw=UX=suse.com=jgross@srs-se1.protection.inumbo.net>)
 id 1tdkg4-0000MK-RK
 for xen-devel@lists.xenproject.org; Fri, 31 Jan 2025 06:38:56 +0000
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com
 [2a00:1450:4864:20::331])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0b350e99-df9e-11ef-a0e6-8be0dac302b0;
 Fri, 31 Jan 2025 07:38:55 +0100 (CET)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-43624b2d453so17607665e9.2
 for <xen-devel@lists.xenproject.org>; Thu, 30 Jan 2025 22:38:55 -0800 (PST)
Received: from ?IPV6:2003:e5:8731:2800:842d:42a0:5992:3595?
 (p200300e587312800842d42a059923595.dip0.t-ipconnect.de.
 [2003:e5:8731:2800:842d:42a0:5992:3595])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438e245f49dsm44795305e9.35.2025.01.30.22.38.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 30 Jan 2025 22:38:54 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 0b350e99-df9e-11ef-a0e6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738305535; x=1738910335; darn=lists.xenproject.org;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=eA6vRW07J0P2LGVdUIhL5k3oNhbtfPasDGkSr4Lw8Nc=;
        b=FLObjua52EVgW28MQN0hXHJEDtXplVd/KMdJy+MIANVGuzb60mcBfAFVfiX33OpLBg
         c1qxobra4B1vB+Ry55cUm15QOgJWf3umlSUxvfRTDw5A/e/DHDw0yoCQI94fErip6vy4
         XAIlV9X/pJL1b9vfmoJI6b4lr2y+BY8FJxGQ21r8WSL19QKKPukVQ3gxhdqYRKPU0TZW
         1bHdqk2DqZgXPm35UPqZPYYdfvw7EkaLMM3ltltYuCHEiOPGzXNj2CdikHWvew78BsJw
         tS3j1cuvro3Rh71ABH0MS6UdONy4gKczYn3u++qzARGAWu1lr29cn8iFqvpSt6rEOUMo
         UKog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738305535; x=1738910335;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=eA6vRW07J0P2LGVdUIhL5k3oNhbtfPasDGkSr4Lw8Nc=;
        b=qwUPzpCHIOfFmspNuNcfFxtUTGJoIc/f1N+0oaitjcS5Lo36fNVJLI4o2U/bCDxcfc
         t/aHcTIHzeF5Phu/pDGJpCGtnex/bcuj/5smTYRqtWUhwQ2NxIi33C/VBf9CtJbQQCEk
         f8REUJPNc/uMuObmEvCuzo7nac5Z9morJMXliFhgOyqxxrX30YaA+J71ImG7glLxjvZg
         xi46xH7vvjkfsCLVs6yA3kCxCMFAqESLWw4swTuccw4ekTu9PxE3ZoNeBcsfm7O8yiji
         rehdUu4O5jefHwzeGSfIBs2++QR5CYmL5Q0lPTJEpGcWSQ7GwxSQKWv2t0lkLrmISALD
         XWog==
X-Forwarded-Encrypted: i=1; AJvYcCWTsQE9+NkxCETk8UtDfpx2bnbUK96IWDKAHeLxctBtQsdU6qKkyhYQmebQoyQg6j5o1Ov4HmWTPMY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxjlLQEAUtAimUSOAgcm/jxBO55/dLIdLP4X9Ii+kLjW9b8B8Jw
	BeHaFi4NHjLYG5xNpSKToIPFxLnogjdZpOhbZDia690sVwtSMuXtSKnULlStyoA=
X-Gm-Gg: ASbGncv6IDUxbMuch+7x79UnF1vbTJz2n4dP26iioP4kY+Jpgyg0Xbfg33UB3TQHdyh
	hXSUPof111NiX4TQ7FgcZbVnFE3FdkZI8fVWXvnyBFMkJoRubBi1d3l853cYZKqC3Oxx/qk4tDa
	+j59aZwdZK9iSkfqu04ME/uGrmCYDODQDgfex57/DTy+17zMojqS319vvdgEW/wn3Sa5UKM3xct
	j5Gq6MBr0VuZI+ebk4s0OAHSSHmb9Bk18D+3mXoiLsaf7oWqIaFgPiJqV3PBV3C0v9eBTrEFhhB
	1xhZRr71x6evnq5JXVPP3Xndsv9msY2tKPMCMiP514/WIvXdCtDWA4HOgslFc4ZJibbWgHPqNNa
	WnqoDSgfvPjVKUKBbynpNqZXqJdoemleLU3ku3aNy
X-Google-Smtp-Source: AGHT+IEEn+FHcAe/JT+VUko98QB86zRnMg/SibtguW3HIvwnvCESdwF1M4oZ9B5MKY1MBcHhIiD7kw==
X-Received: by 2002:a05:600c:19cc:b0:434:fddf:5c0c with SMTP id 5b1f17b1804b1-438e298fea7mr47974095e9.4.1738305535279;
        Thu, 30 Jan 2025 22:38:55 -0800 (PST)
Message-ID: <9316269c-dbc4-45e4-a580-082edcf3a65d@suse.com>
Date: Fri, 31 Jan 2025 07:38:53 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: v5.4.289 failed to boot with error megasas_build_io_fusion 3219
 sge_count (-12) is out of range
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: Harshvardhan Jha <harshvardhan.j.jha@oracle.com>,
 Greg KH <gregkh@linuxfoundation.org>, Konrad Wilk <konrad.wilk@oracle.com>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
 Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>,
 stable@vger.kernel.org
References: <7dc143fa-4a48-440b-b624-ac57a361ac74@oracle.com>
 <9dd91f6e-1c66-4961-994e-dbda87d69dad@oracle.com>
 <2025012919-series-chaps-856e@gregkh>
 <8eb33b38-23e1-4e43-8952-3f2b05660236@oracle.com>
 <2025012936-finalize-ducktail-c524@gregkh>
 <1f017284-1a29-49d8-b0d9-92409561990e@oracle.com>
 <2025012956-jiffy-condone-3137@gregkh>
 <1f225b8d-d958-4304-829e-8798884d9b6b@oracle.com>
 <83bd90c7-8879-4462-9548-bb5b69cac39e@suse.com>
 <b4ab0246-3846-41d1-8e84-64bd7fefc089@oracle.com>
 <de6912ad-3dba-4d66-8ca2-71a0aa09172c@suse.com>
 <686986a0-c981-4aa3-ae88-92a34368129e@oracle.com>
 <5a7d969b-b2ab-4fac-b95e-4a536e2c8d5c@suse.com>
 <alpine.DEB.2.22.394.2501301226330.11632@ubuntu-linux-20-04-desktop>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <alpine.DEB.2.22.394.2501301226330.11632@ubuntu-linux-20-04-desktop>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------gBR1om3a0aT0VEghtIh1tEBw"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------gBR1om3a0aT0VEghtIh1tEBw
Content-Type: multipart/mixed; boundary="------------tBXvzTgiiczaSsTA0JKdPJqT";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: Harshvardhan Jha <harshvardhan.j.jha@oracle.com>,
 Greg KH <gregkh@linuxfoundation.org>, Konrad Wilk <konrad.wilk@oracle.com>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
 Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>,
 stable@vger.kernel.org
Message-ID: <9316269c-dbc4-45e4-a580-082edcf3a65d@suse.com>
Subject: Re: v5.4.289 failed to boot with error megasas_build_io_fusion 3219
 sge_count (-12) is out of range
References: <7dc143fa-4a48-440b-b624-ac57a361ac74@oracle.com>
 <9dd91f6e-1c66-4961-994e-dbda87d69dad@oracle.com>
 <2025012919-series-chaps-856e@gregkh>
 <8eb33b38-23e1-4e43-8952-3f2b05660236@oracle.com>
 <2025012936-finalize-ducktail-c524@gregkh>
 <1f017284-1a29-49d8-b0d9-92409561990e@oracle.com>
 <2025012956-jiffy-condone-3137@gregkh>
 <1f225b8d-d958-4304-829e-8798884d9b6b@oracle.com>
 <83bd90c7-8879-4462-9548-bb5b69cac39e@suse.com>
 <b4ab0246-3846-41d1-8e84-64bd7fefc089@oracle.com>
 <de6912ad-3dba-4d66-8ca2-71a0aa09172c@suse.com>
 <686986a0-c981-4aa3-ae88-92a34368129e@oracle.com>
 <5a7d969b-b2ab-4fac-b95e-4a536e2c8d5c@suse.com>
 <alpine.DEB.2.22.394.2501301226330.11632@ubuntu-linux-20-04-desktop>
In-Reply-To: <alpine.DEB.2.22.394.2501301226330.11632@ubuntu-linux-20-04-desktop>

--------------tBXvzTgiiczaSsTA0JKdPJqT
Content-Type: multipart/mixed; boundary="------------QBBmk1MGxChaWIAqHSG78WQf"

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

T24gMzAuMDEuMjUgMjE6MjgsIFN0ZWZhbm8gU3RhYmVsbGluaSB3cm90ZToNCj4gT24gVGh1
LCAzMCBKYW4gMjAyNSwgSsO8cmdlbiBHcm/DnyB3cm90ZToNCj4+IENhbiB5b3UgdHJ5IHRo
ZSBhdHRhY2hlZCBwYXRjaCwgcGxlYXNlPyBJIGRvbid0IGhhdmUgYSBzeXN0ZW0gYXQgaGFu
ZA0KPj4gc2hvd2luZyB0aGUgcHJvYmxlbS4NCj4+DQo+PiAgRnJvbSBjZmY0M2U5OTdmNzlh
OTVkYzQ0ZTAyZGViYWVhZmU1ZjEyN2Y0MGJiIE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQ0K
Pj4gRnJvbTogSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1c2UuY29tPg0KPj4gRGF0ZTogVGh1
LCAzMCBKYW4gMjAyNSAwOTo1Njo1NyArMDEwMA0KPj4gU3ViamVjdDogW1BBVENIXSB4ODYv
eGVuOiBhbGxvdyBsYXJnZXIgY29udGlndW91cyBtZW1vcnkgcmVnaW9ucyBpbiBQViBndWVz
dHMNCj4+DQo+PiBUb2RheSBhIFBWIGd1ZXN0IChpbmNsdWRpbmcgZG9tMCkgY2FuIGNyZWF0
ZSAyTUIgY29udGlndW91cyBtZW1vcnkNCj4+IHJlZ2lvbnMgZm9yIERNQSBidWZmZXJzIGF0
IG1heC4gVGhpcyBoYXMgbGVkIHRvIHByb2JsZW1zIGF0IGxlYXN0DQo+PiB3aXRoIHRoZSBt
ZWdhcmFpZF9zYXMgZHJpdmVyLCB3aGljaCB3YW50cyB0byBhbGxvY2F0ZSBhIDIuM01CIERN
QQ0KPj4gYnVmZmVyLg0KPj4NCj4+IFRoZSBsaW1pdGluZyBmYWN0b3IgaXMgdGhlIGZyYW1l
IGFycmF5IHVzZWQgdG8gZG8gdGhlIGh5cGVyY2FsbCBmb3INCj4+IG1ha2luZyB0aGUgbWVt
b3J5IGNvbnRpZ3VvdXMsIHdoaWNoIGhhcyA1MTIgZW50cmllcyBhbmQgaXMganVzdCBhDQo+
PiBzdGF0aWMgYXJyYXkgaW4gbW11X3B2LmMuDQo+Pg0KPj4gSW4gY2FzZSBhIGNvbnRpZ3Vv
dXMgbWVtb3J5IGFyZWEgbGFyZ2VyIHRoYW4gdGhlIGluaXRpYWxseSBzdXBwb3J0ZWQNCj4+
IDJNQiBpcyByZXF1ZXN0ZWQsIGFsbG9jYXRlIGEgbGFyZ2VyIGJ1ZmZlciBmb3IgdGhlIGZy
YW1lIGxpc3QuIE5vdGUNCj4+IHRoYXQgc3VjaCBhbiBhbGxvY2F0aW9uIGlzIHRyaWVkIG9u
bHkgYWZ0ZXIgbWVtb3J5IG1hbmFnZW1lbnQgaGFzIGJlZW4NCj4+IGluaXRpYWxpemVkIHBy
b3Blcmx5LCB3aGljaCBpcyB0ZXN0ZWQgdmlhIHRoZSBlYXJseV9ib290X2lycXNfZGlzYWJs
ZWQNCj4+IGZsYWcuDQo+Pg0KPj4gRml4ZXM6IDlmNDBlYzg0YTc5NyAoInhlbi9zd2lvdGxi
OiBhZGQgYWxpZ25tZW50IGNoZWNrIGZvciBkbWEgYnVmZmVycyIpDQo+PiBTaWduZWQtb2Zm
LWJ5OiBKdWVyZ2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+DQo+PiAtLS0NCj4+IE5vdGUg
dGhhdCB0aGUgIkZpeGVzOiIgdGFnIGlzIG5vdCByZWFsbHkgY29ycmVjdCwgYXMgdGhhdCBw
YXRjaCBkaWRuJ3QNCj4+IGludHJvZHVjZSB0aGUgcHJvYmxlbSwgYnV0IHJhdGhlciBtYWRl
IGl0IHZpc2libGUuIE9UT0ggaXQgaXMgdGhlIGJlc3QNCj4+IGluZGljYXRvciB3ZSBoYXZl
IHRvIGlkZW50aWZ5IGtlcm5lbCB2ZXJzaW9ucyB0aGlzIHBhdGNoIHNob3VsZCBiZQ0KPj4g
YmFja3BvcnRlZCB0by4NCj4+IC0tLQ0KPj4gICBhcmNoL3g4Ni94ZW4vbW11X3B2LmMgfCA0
NCArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKystLS0tLS0tDQo+PiAgIDEg
ZmlsZSBjaGFuZ2VkLCAzNyBpbnNlcnRpb25zKCspLCA3IGRlbGV0aW9ucygtKQ0KPj4NCj4+
IGRpZmYgLS1naXQgYS9hcmNoL3g4Ni94ZW4vbW11X3B2LmMgYi9hcmNoL3g4Ni94ZW4vbW11
X3B2LmMNCj4+IGluZGV4IDU1YTQ5OTZkMGMwNC4uNjJhZWMyOWI4MTc0IDEwMDY0NA0KPj4g
LS0tIGEvYXJjaC94ODYveGVuL21tdV9wdi5jDQo+PiArKysgYi9hcmNoL3g4Ni94ZW4vbW11
X3B2LmMNCj4+IEBAIC0yMjAwLDggKzIyMDAsMTAgQEAgdm9pZCBfX2luaXQgeGVuX2luaXRf
bW11X29wcyh2b2lkKQ0KPj4gICB9DQo+PiAgIA0KPj4gICAvKiBQcm90ZWN0ZWQgYnkgeGVu
X3Jlc2VydmF0aW9uX2xvY2suICovDQo+PiAtI2RlZmluZSBNQVhfQ09OVElHX09SREVSIDkg
LyogMk1CICovDQo+PiAtc3RhdGljIHVuc2lnbmVkIGxvbmcgZGlzY29udGlnX2ZyYW1lc1sx
PDxNQVhfQ09OVElHX09SREVSXTsNCj4+ICsjZGVmaW5lIE1JTl9DT05USUdfT1JERVIgOSAv
KiAyTUIgKi8NCj4+ICtzdGF0aWMgdW5zaWduZWQgaW50IGRpc2NvbnRpZ19mcmFtZXNfb3Jk
ZXIgPSBNSU5fQ09OVElHX09SREVSOw0KPj4gK3N0YXRpYyB1bnNpZ25lZCBsb25nIGRpc2Nv
bnRpZ19mcmFtZXNfZWFybHlbMVVMIDw8IE1JTl9DT05USUdfT1JERVJdOw0KPj4gK3N0YXRp
YyB1bnNpZ25lZCBsb25nICpkaXNjb250aWdfZnJhbWVzID0gZGlzY29udGlnX2ZyYW1lc19l
YXJseTsNCj4+ICAgDQo+PiAgICNkZWZpbmUgVk9JRF9QVEUgKG1mbl9wdGUoMCwgX19wZ3By
b3QoMCkpKQ0KPj4gICBzdGF0aWMgdm9pZCB4ZW5femFwX3Bmbl9yYW5nZSh1bnNpZ25lZCBs
b25nIHZhZGRyLCB1bnNpZ25lZCBpbnQgb3JkZXIsDQo+PiBAQCAtMjMxOSwxOCArMjMyMSw0
NCBAQCBpbnQgeGVuX2NyZWF0ZV9jb250aWd1b3VzX3JlZ2lvbihwaHlzX2FkZHJfdCBwc3Rh
cnQsIHVuc2lnbmVkIGludCBvcmRlciwNCj4+ICAgCQkJCSB1bnNpZ25lZCBpbnQgYWRkcmVz
c19iaXRzLA0KPj4gICAJCQkJIGRtYV9hZGRyX3QgKmRtYV9oYW5kbGUpDQo+PiAgIHsNCj4+
IC0JdW5zaWduZWQgbG9uZyAqaW5fZnJhbWVzID0gZGlzY29udGlnX2ZyYW1lcywgb3V0X2Zy
YW1lOw0KPj4gKwl1bnNpZ25lZCBsb25nICppbl9mcmFtZXMsIG91dF9mcmFtZTsNCj4+ICsJ
dW5zaWduZWQgbG9uZyAqbmV3X2FycmF5LCAqb2xkX2FycmF5Ow0KPj4gICAJdW5zaWduZWQg
bG9uZyAgZmxhZ3M7DQo+PiAgIAlpbnQgICAgICAgICAgICBzdWNjZXNzOw0KPj4gICAJdW5z
aWduZWQgbG9uZyB2c3RhcnQgPSAodW5zaWduZWQgbG9uZylwaHlzX3RvX3ZpcnQocHN0YXJ0
KTsNCj4+ICAgDQo+PiAtCWlmICh1bmxpa2VseShvcmRlciA+IE1BWF9DT05USUdfT1JERVIp
KQ0KPj4gLQkJcmV0dXJuIC1FTk9NRU07DQo+PiArCWlmICh1bmxpa2VseShvcmRlciA+IGRp
c2NvbnRpZ19mcmFtZXNfb3JkZXIpKSB7DQo+PiArCQlpZiAoZWFybHlfYm9vdF9pcnFzX2Rp
c2FibGVkKQ0KPj4gKwkJCXJldHVybiAtRU5PTUVNOw0KPj4gKw0KPj4gKwkJbmV3X2FycmF5
ID0gdm1hbGxvYyhzaXplb2YodW5zaWduZWQgbG9uZykgKiAoMVVMIDw8IG9yZGVyKSk7DQo+
PiArDQo+PiArCQlpZiAoIW5ld19hcnJheSkNCj4+ICsJCQlyZXR1cm4gLUVOT01FTTsNCj4+
ICsNCj4+ICsJCXNwaW5fbG9ja19pcnFzYXZlKCZ4ZW5fcmVzZXJ2YXRpb25fbG9jaywgZmxh
Z3MpOw0KPj4gKw0KPj4gKwkJaWYgKG9yZGVyID4gZGlzY29udGlnX2ZyYW1lc19vcmRlcikg
ew0KPiANCj4gDQo+IFRoaXMgc2Vjb25kIGlmIGNoZWNrIHNob3VsZCBub3QgYmUgbmVlZGVk
IGJlY2F1c2UgaXQgaXMgdGhlIHNhbWUgYXMgdGhlDQo+IG91dGVyIGlmIGNoZWNrLg0KDQpJ
dCBpcyBuZWVkZWQsIGFzIGluc2lkZSB0aGUgbG9ja2VkIHJlZ2lvbiBJIG5lZWQgdG8gdmVy
aWZ5IHRoYXQgbm8NCmNvbmN1cnJlbnQgY2FsbCBkaWQgYWxyZWFkeSB1cGRhdGUgdGhlIGJ1
ZmZlciwgbWF5YmUgd2l0aCBhbiBldmVuDQpsYXJnZXIgc2l6ZS4NCg0KDQpKdWVyZ2VuDQo=

--------------QBBmk1MGxChaWIAqHSG78WQf
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

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

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

--------------QBBmk1MGxChaWIAqHSG78WQf--

--------------tBXvzTgiiczaSsTA0JKdPJqT--

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

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

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmecb/0FAwAAAAAACgkQsN6d1ii/Ey/e
wwgAmKFq0zc/HtH2xmd/vkNJVx7IeIINZUxnmHRrllzFjO4AKfjZ3wnT8HZGmodlE7cifdCajkAl
vXvlmEeL0YAW7XSrk/wj5Hq0cvARfM+Z78Mo7pJRgldndIBecks4c4dwXuDi5LRRHePgqGIlDS6T
nOnXyqf9F+c7c8uBU4FDwBVfNm2J+LNkNlLgNPBao6QKD8Wpv4kcPJtRxRRcCW7efD+pU6axqYU6
ZwYY6W8RTTqdZBeIiSfbIMqQeC6l3LG8+AP8+UVYIxduopspUKbiubGGHQh4Z61Mgz86lCd1wChc
11hxxbFRwz9h9Fe5p3UKrcO5VQDdo0ImkCB+gMyQoA==
=46NW
-----END PGP SIGNATURE-----

--------------gBR1om3a0aT0VEghtIh1tEBw--


From xen-devel-bounces@lists.xenproject.org Fri Jan 31 06:42:49 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 31 Jan 2025 06:42:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879867.1290075 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdkjl-00023S-3U; Fri, 31 Jan 2025 06:42:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879867.1290075; Fri, 31 Jan 2025 06:42:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdkjl-00023L-0h; Fri, 31 Jan 2025 06:42:45 +0000
Received: by outflank-mailman (input) for mailman id 879867;
 Fri, 31 Jan 2025 06:42:43 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=aogm=UX=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tdkjj-00023F-22
 for xen-devel@lists.xenproject.org; Fri, 31 Jan 2025 06:42:43 +0000
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com
 [2a00:1450:4864:20::336])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 916ee933-df9e-11ef-99a4-01e77a169b0f;
 Fri, 31 Jan 2025 07:42:41 +0100 (CET)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-438a3216fc2so15946335e9.1
 for <xen-devel@lists.xenproject.org>; Thu, 30 Jan 2025 22:42:41 -0800 (PST)
Received: from ?IPV6:2003:ca:b741:f10a:3123:f9e9:b484:6874?
 (p200300cab741f10a3123f9e9b4846874.dip0.t-ipconnect.de.
 [2003:ca:b741:f10a:3123:f9e9:b484:6874])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438dcc13139sm80415345e9.3.2025.01.30.22.42.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 30 Jan 2025 22:42:40 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 916ee933-df9e-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738305760; x=1738910560; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=UBqOVcMx4Rdr9/LDw3ArS6B/3yoE9+MIImqGwur+LN4=;
        b=O0BdLQXgHvWG3h/whO6bpmcPn+Qd8eoSwE8yE4Gfw7k8LSsiPoz/gdcPZjODeOhRfA
         wiZgc5tUrkAm4QsxpvGurNWEb17PCXfSrq+DEkpJMmvUEH2qdnkjMeU/f9p6WH+V9WkB
         Bln0KH9Sa/kS+1XEM8E7L0YNObzdYYA8bjn/lq9yaBwGK+4ar/PlXfXX0aVOFi23E5II
         /JHX6bU058rCGhTD2302+qXIcTv0+jm2JJiNQ8OxNLFOI/zfqlQBV5NcJmB+OtTmrUb5
         0Z4tYqp+se5K1umXgCw9K0CHk0yH9rYyZQYMOTav2E2+1tjlReG1ZL345r2+yd59C8cJ
         9lrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738305760; x=1738910560;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=UBqOVcMx4Rdr9/LDw3ArS6B/3yoE9+MIImqGwur+LN4=;
        b=ETCMMF7BtA7E1vhafbOZFN77GyAt60ntyRjaEo9ZnjgHhBRbzjNLApvvpGGpJQ3RA1
         0AKbEdxkDA9TPXo05L8UmJkFYor0Gp07EdbygCjvIKEIoOxYBAz+ea+2NscgkkJtZ8p2
         /iOyGAxSXLD4V2ywpt1UldwBUofMhUnTnoJOAEWIN9Wj3VqIrmIe1EqHYq9W4Yz2QorZ
         cxV/G0PZ6ESTw5rSEntq5h/R/ZAwoVQ0TVrMYq6e6O4rk9K4koSP3sL6Zuzmmj7yMXg/
         +LBJk/XQidXrzLDD9WflKpLnoE3EB6aRmDoVxsASkA0XWHA9CJj7Z5jZFBw893QpxQhM
         bH9A==
X-Gm-Message-State: AOJu0YxXOC2E8c19XHHFKfDJy/nBZggUgEC4DPA9ijgWQuYglxv2aqSb
	0mdxqIYkRTd33TxJ9WqctpNqCO5VwSZmyvk16dBA7NZyxYKi2dmUjYrPao8W6A==
X-Gm-Gg: ASbGncuE/UbAxolSvdwVH98XAuvTNY5RqcpJUEy8MfKDqG6fRJbQJAWPLDZJePt4Epe
	H5+SC3KDlTVyfkTXXbiIWw5BbG10+hJ0CBPwa/ij1kvoM/08Hg+3dth3lXAaHPuA9CX+V0GegtK
	26ezA1VbeJ0prmY0ktTTl8GPOpOWq59Nyzh/GIbIPi63EE8m5YVOGCk8vYeYM+VXl71i+zjvleQ
	s9xsj/4FYXUuOGqgT748Ly7amEpR/etFqqANRlove0zKeQaBKVtVdJ93Sn3G8GOvO3tCDGQ4erJ
	nYHDFH7k8cVb+OjgZWx8ulYnRwpivBKoUXphImoj4r1ViLSbrfw0lJlvqOMbKB59ksZ09XJLayq
	Uz7JD0XaIe3RA9Jp1EBVsIaCQuCzVOQsnxjIc8Bzo/D8spm/vlA==
X-Google-Smtp-Source: AGHT+IHrk0BokgmR76KgxthvytDivGsyKqRqKTEDwL5BoGyF1r1DM7RAhjCSe0J+F4KVo1cyjFhyaw==
X-Received: by 2002:a5d:64cb:0:b0:386:1cf9:b96e with SMTP id ffacd0b85a97d-38c520bcb9cmr8097108f8f.55.1738305760553;
        Thu, 30 Jan 2025 22:42:40 -0800 (PST)
Message-ID: <36708a3f-2664-4b04-9f5d-f115d362d100@suse.com>
Date: Fri, 31 Jan 2025 07:42:36 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 4/4] xen: mem_access: conditionally compile vm_event.c
 & monitor.c
To: Tamas K Lengyel <tamas@tklengyel.com>
Cc: xen-devel@lists.xenproject.org,
 Stefano Stabellini <stefano.stabellini@amd.com>,
 Julien Grall <julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Alexandru Isaila <aisaila@bitdefender.com>,
 Petre Pircalabu <ppircalabu@bitdefender.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Ayan Kumar Halder <ayan.kumar.halder@amd.com>,
 Sergiy Kibrik <Sergiy_Kibrik@epam.com>
References: <cover.1737452864.git.Sergiy_Kibrik@epam.com>
 <2e8b9c5390019ef66610a21d9a8744282e2badeb.1737452864.git.Sergiy_Kibrik@epam.com>
 <CABfawhkw-MDvVnfgTi44YHA9JYSkzFS6VkdtLdH33big9BcHdA@mail.gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <CABfawhkw-MDvVnfgTi44YHA9JYSkzFS6VkdtLdH33big9BcHdA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 31.01.2025 01:33, Tamas K Lengyel wrote:
> On Tue, Jan 21, 2025 at 5:25 AM Sergiy Kibrik <Sergiy_Kibrik@epam.com> wrote:
>> --- a/xen/arch/arm/vsmc.c
>> +++ b/xen/arch/arm/vsmc.c
>> @@ -330,7 +330,8 @@ void do_trap_smc(struct cpu_user_regs *regs, const union hsr hsr)
>>      }
>>
>>      /* If monitor is enabled, let it handle the call. */
>> -    if ( current->domain->arch.monitor.privileged_call_enabled )
>> +    if ( IS_ENABLED(CONFIG_VM_EVENT) &&
>> +         current->domain->arch.monitor.privileged_call_enabled )
>>          rc = monitor_smc();
> 
> Why not wrap this entire if block above in an #ifdef CONFIG_VM_EVENT?
> I think it would be more explicit what code is being compiled that way
> instead of just relying on the compiler optimization to take care of
> removing it.

Well - we generally prefer things being written this way, where possible.
This is to keep as much code as possible exposed to the compiler no
matter what configuration. This way the risk of bit-rotting is a little
lower (e.g. when making changes affecting such a piece of code, but not
noticing the need for a change because things compile fine in whatever
configuration(s) the person tests).

Jan

> The rest of the patch looks fine to me.
> 
> Tamas



From xen-devel-bounces@lists.xenproject.org Fri Jan 31 06:45:21 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 31 Jan 2025 06:45:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879875.1290085 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdkmF-0002bd-FW; Fri, 31 Jan 2025 06:45:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879875.1290085; Fri, 31 Jan 2025 06:45:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdkmF-0002bW-D1; Fri, 31 Jan 2025 06:45:19 +0000
Received: by outflank-mailman (input) for mailman id 879875;
 Fri, 31 Jan 2025 06:45: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 <SRS0=aogm=UX=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tdkmE-0002bM-7j
 for xen-devel@lists.xenproject.org; Fri, 31 Jan 2025 06:45:18 +0000
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com
 [2a00:1450:4864:20::333])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ede311c2-df9e-11ef-99a4-01e77a169b0f;
 Fri, 31 Jan 2025 07:45:16 +0100 (CET)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-4368a293339so18478625e9.3
 for <xen-devel@lists.xenproject.org>; Thu, 30 Jan 2025 22:45:16 -0800 (PST)
Received: from ?IPV6:2003:ca:b741:f10a:3123:f9e9:b484:6874?
 (p200300cab741f10a3123f9e9b4846874.dip0.t-ipconnect.de.
 [2003:ca:b741:f10a:3123:f9e9:b484:6874])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438dcc6de7csm82055135e9.32.2025.01.30.22.45.15
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 30 Jan 2025 22:45:15 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ede311c2-df9e-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738305916; x=1738910716; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Rdy9hpk9tsBVrjdRzdbz+KMxN2ReEZwG1nTb+ZTJCM0=;
        b=KDQqq0cYQCNxveibKuw1OZo02SoK5dHq9oPjX6Ro1GaOHQXpTUkQDLYiTY8gvNh4sc
         gmQwiQcAI0Xi5FGnwRS3Xc77xkVBTKWjbspkfiM1jraofbRT1dmFNzdr+2g5kYbEzIvY
         3ucA8zL0gcuy3krrFISkSFFXWp8HmjFQVOzcS0mR8bVpbRaDqpqr9QHyJJmsd4eRYvzX
         OwCXtXd5ibNySofoU/IYKaBLtNgjP2a7eYENpQF2a27VJ6+RKFUhN1+FrVkzBzhTwKsw
         AL/wF2/epIoUIPcsPgV43ZT7gupuV52pRWPJO6/5FmgpHcvLFvqSyBEDxyB4kCGb3l1w
         JhLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738305916; x=1738910716;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Rdy9hpk9tsBVrjdRzdbz+KMxN2ReEZwG1nTb+ZTJCM0=;
        b=doUr4Anmm1gxLB00HBVRauJFGnrlnq62GtAGh1h2z0v9ULRU7k4Jiv68E40uQR3yQH
         4BcQcVObqecH9YVmcpUGo9c8i7S4Pa3H31ErHDiDT8sVzf+8mr1MnLE2bOaRnnISzNhh
         6aV9WfqsAMRKRWyq4tQfD3+3+DUv3DxMuieAskdg4fmSFKOh2opEVrUjhV+L1if4SYuX
         8WqKJQPeOHo1+YNj8QSbVJgdGCLtUKig14loLFi9UldafSJ6UMAy5XnsvqsFjdKHdq+U
         2XRYRQD0Hew2ZA6umOYqj3K1v8STYxug1ytc+MfSb2Mnj/ITWiGXEfqPX6XPv7Dt8HK0
         8j6g==
X-Forwarded-Encrypted: i=1; AJvYcCWsvwvB7mT1GgYvkEVpUYPlIS+qvJspGnxM1HZu/OdmPVTlDT63ospOFocUnnhSlWyQ9yHRZy0o6KM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxxBLHBdPUOlVdww0jXlf8IiHAyH8UJQMq9NbphQt8LYVLD9nAX
	SmmtO8gaKYYbjG6Pc3Qce97B58byQtcY+sL8IjN2pY14eelXUlNlTkRDW7k/TA==
X-Gm-Gg: ASbGncuvGS2JLQ/riUbqjTeE+jqPiqYKl5U807NSelPb3aO0KIrEMSZ763wXOis+0+N
	+ewHzJUVA9AWGpe+zRg/ORLRrchLe2cZcK6zAA4Af3sCx/8FgnFaZfAY8r/yiHvyWN+aIkKzdwl
	p79fwS6pbqxr7VcoKprVAAuqHDCiq2nEXjFlDualnXmb70qvumJAepQiw5EczXxP+D/BY5bXOGB
	z8UIi6QucmyXciJR4x+X6QTKk92VQ0bnC0gTQmXTM0Dvbp9KnP0eBBTnCOuERKHoasrcipmNQ69
	No1CwZBwx/zQ/JH6zvjPi1YTzVQFFlMpVpe8fwBgoZRAfnGo0cg7OwQ52l3Ds+1aWnmsosPzyGR
	9t9sh75ngXq36ihqWJ7B2tYpwLbz0B37B3e0DwfhUoul0fvJhsQ==
X-Google-Smtp-Source: AGHT+IFUZVX2yvUG6xKfolHun82jZacA7WBDYJljKJ19gYWCLFet02/4J580+lHsigSb4UjthVu3jg==
X-Received: by 2002:a05:600c:1e20:b0:438:a1f4:3e9d with SMTP id 5b1f17b1804b1-438dc3c405dmr79314435e9.9.1738305915620;
        Thu, 30 Jan 2025 22:45:15 -0800 (PST)
Message-ID: <b9411efc-27fa-447e-b9b3-061a46286233@suse.com>
Date: Fri, 31 Jan 2025 07:45:11 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN RFC PATCH v5 3/5] xen/public: Introduce PV-IOMMU hypercall
 interface
To: Jason Andryuk <jason.andryuk@amd.com>,
 Teddy Astie <teddy.astie@vates.tech>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, xen-devel@lists.xenproject.org
References: <cover.1737470269.git.teddy.astie@vates.tech>
 <29f3e87532573bfc4196083ab0291326adae5100.1737470269.git.teddy.astie@vates.tech>
 <1ea6447c-3451-4aca-8a17-2848acd0868f@amd.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <1ea6447c-3451-4aca-8a17-2848acd0868f@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 30.01.2025 21:17, Jason Andryuk wrote:
> On 2025-01-21 11:13, Teddy Astie wrote:
>> +/**
>> + * IOMMU_alloc_nested
>> + * Create a nested IOMMU context (needs IOMMUCAP_nested).
>> + *
>> + * This context uses a platform-specific page table from domain address space
>> + * specified in pgtable_gfn and use it for nested translations.
>> + *
>> + * Explicit flushes needs to be submited with IOMMU_flush_nested on
>> + * modification of the nested pagetable to ensure coherency between IOTLB and
>> + * nested page table.
>> + *
>> + * This context can be destroyed using IOMMU_free_context.
>> + * This context cannot be modified using map_pages, unmap_pages.
>> + */
>> +struct pv_iommu_alloc_nested {
>> +    /* OUT: allocated IOMMU context number */
>> +    uint16_t ctx_no;
>> +
>> +    /* IN: guest frame number of the nested page table */
>> +    uint64_aligned_t pgtable_gfn;
>> +
>> +    /* IN: nested mode flags */
>> +    uint64_aligned_t nested_flags;
>> +};
>> +typedef struct pv_iommu_alloc_nested pv_iommu_alloc_nested_t;
>> +DEFINE_XEN_GUEST_HANDLE(pv_iommu_alloc_nested_t);
> 
> Is this command intended to be used for GVA -> GPA translation?  Would you need some way to associate with another iommu context for GPA -> HPA translation?
> 
> Maybe more broadly, what are your goals for enabling PV-IOMMU?  The examples on your blog post cover a domain restrict device access to specific portions of the the GPA space.  Are you also interested in GVA -> GPA?  Does VFIO required GVA -> GPA?
> 
> And, sorry to bike shed, but ctx_no reads like "Context No" to me.  I think ctxid/ctx_id might be clearer.  Others probably have their own opinions :)

Or, if it absolutely is to derive from "number", ctx_nr. That said, I
agree "id" is a better term to use here.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Jan 31 07:13:48 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 31 Jan 2025 07:13:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879888.1290095 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdlDi-00079v-OB; Fri, 31 Jan 2025 07:13:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879888.1290095; Fri, 31 Jan 2025 07:13:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdlDi-00079o-LV; Fri, 31 Jan 2025 07:13:42 +0000
Received: by outflank-mailman (input) for mailman id 879888;
 Fri, 31 Jan 2025 07:13:42 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=aogm=UX=suse.com=jbeulich@srs-se1.protection.inumbo.net>)
 id 1tdlDi-00079i-67
 for xen-devel@lists.xenproject.org; Fri, 31 Jan 2025 07:13:42 +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 e55e3abc-dfa2-11ef-99a4-01e77a169b0f;
 Fri, 31 Jan 2025 08:13:39 +0100 (CET)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-4363ae65100so18021275e9.0
 for <xen-devel@lists.xenproject.org>; Thu, 30 Jan 2025 23:13:39 -0800 (PST)
Received: from ?IPV6:2003:ca:b741:f1d0:3123:f9e9:b484:6874?
 (p200300cab741f1d03123f9e9b4846874.dip0.t-ipconnect.de.
 [2003:ca:b741:f1d0:3123:f9e9:b484:6874])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-438dcc263f0sm81274495e9.9.2025.01.30.23.13.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 30 Jan 2025 23:13:39 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e55e3abc-dfa2-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1738307619; x=1738912419; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ttm6v3FBTzieJ8SUVLl/gOL9EjbKAxhp9vbmf+0aYqQ=;
        b=D8oeB0EJSiKeqinfA9guplHjSNQM9Fc1aT2CV6LJHOSf6r+fpsaE78frpAWkuZNoV8
         IEBvHpSatNEkU3R65jK9WBTVfuIiqbwM5R4IRYKIDbWExvf+EaP9GnZknIrFXjumjQVF
         CW/4hfKLeKpJE9zLn9osY3Gun3H1hvJ086IGpR9VzxM7jmWNtgeFQcJLXG3EobWl5XNW
         uHcwMYOb+6dshMfaKHLGIg9mKOzuBpI9/KW+i+XiGrsTM47CGqL7kahq0T78ejyqLD5m
         GdvDdGbgAW4f+ai04Qbv9vf8/KzeQjtTgB4F7raqxAeXbqY8nMGqmPiwxnA8cf/j6J13
         TW1w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738307619; x=1738912419;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ttm6v3FBTzieJ8SUVLl/gOL9EjbKAxhp9vbmf+0aYqQ=;
        b=o9sTdYZFp9tTdP2WbheinwKQ4qNDX4kKdyXVjLOhgXqpNrqQMPa1ACj5q+Hf1+MVq/
         siIoYJ3nRXPzF0mgJcGESDIdipVl+M7zg7v0eHRBVI3u30xQ8BPvBEWTu2sixVDrkJQ2
         7tsZgho44Xrz6e/GKyFFaK6WyZUXO5hQwte6KRMvydeHZGDY1rD8yTu2WL58yRLqC+pz
         M4taKizS7wGsuFbqZ03npPQCEuP0nEGPk2eMsoBjDkHWXXTLdtG3hokxf216A5Z8W6HO
         KaEwH/5xS1cxWOfUEYcV3/Sdtc1YTysmVeJzQpE32KKBs34Jmy68IPTTlsTR7uy686wP
         LyZg==
X-Forwarded-Encrypted: i=1; AJvYcCWYbdbqO/JnLhHPRuW2qHNEKfSPu6JOBsvY9a336s1FjsOv6E25/pVXbveOluovIvvuWKgUQaOc2HY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwsUKpEYECSpujajkBVfwmD9FlmnrydOhT1YNAhdzbp8GZ1eii5
	be6UVOCcgYncHrCCY+zlWvkxGn7PGGtg1KCVHUKZUd1vZ5BxTH2qa5JxKhEphg==
X-Gm-Gg: ASbGncsV0Bcyue+5k9vA4SYigWks2m//n6ncglAH5ke4nJLCBkA7DsrvqdTesZkmbMo
	AXOc7KSagK692DncExpiztpYZxgn5SPth1MGSjztQnvVb2BrbxcGx661ntfiwARP8lNb44PR9Kx
	e+zp1SYkHAxZXcWAm3L3QJ6y9Qg+JXL/suwt/9ZkKHjHrCdBopqOyiVtJoCztu3C1HFe3as77w6
	T/JBKgme7NoZAMWA2bT34dzRteO49eWkL4zh6qxYJUTPujvzSLiAY1VNpyL+hC/rrzzNMuNSwfu
	UZfT1gmCGYTxWhjSLRJDGez6jjpY/fbp1THF+fCMDH94/eCnwj5uj+0MnhiriZQBCrVZkqQqOZy
	SisnFhtERFbs1VmhZAmAz4HUNlPmjGXNy4Oy2uU6PtIwB5BEnCw==
X-Google-Smtp-Source: AGHT+IEoTJGWaLKWkydMGgIgEhmfdAzAaGkqn+yNFFfgssg8dqdbKs4HRrJ/OFxj8N4UVjVlH1OMEA==
X-Received: by 2002:a05:600c:1e21:b0:434:a781:f5d9 with SMTP id 5b1f17b1804b1-438dc3c31ccmr126782315e9.11.1738307619291;
        Thu, 30 Jan 2025 23:13:39 -0800 (PST)
Message-ID: <2d5b51e9-db32-4e46-97c8-2644081b7e33@suse.com>
Date: Fri, 31 Jan 2025 08:13:37 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Config space access to Mediatek MT7922 doesn't work after device
 reset in Xen PV dom0 (regression, Linux 6.12)
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, Bjorn Helgaas <bhelgaas@google.com>,
 =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 xen-devel <xen-devel@lists.xenproject.org>, linux-kernel@vger.kernel.org,
 regressions@lists.linux.dev, Felix Fietkau <nbd@nbd.name>,
 Lorenzo Bianconi <lorenzo@kernel.org>, Ryder Lee <ryder.lee@mediatek.com>
References: <20250130213123.GA633869@bhelgaas>
Content-Language: en-US
From: Jan Beulich <jbeulich@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: <20250130213123.GA633869@bhelgaas>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 30.01.2025 22:31, Bjorn Helgaas wrote:
> On Thu, Jan 30, 2025 at 10:30:33AM +0100, Jan Beulich wrote:
>> On 30.01.2025 05:55, Marek Marczykowski-Górecki wrote:
>>> (XEN) d0v1 conf read cf8 0x80010088 bytes 2 offset 2 data 0x9
> 
> PCIe Cap at 0x80, PCI_EXP_DEVCTL is 0x08, PCI_EXP_DEVSTA is 0x0a.
> 
> 0x80010088 would be PCI_EXP_DEVCTL (a 2-byte register), maybe offset 2
> gets us to PCI_EXP_DEVSTA?  Not sure.
> 
>   0x0001 PCI_EXP_DEVSTA_CED /* Correctable Error Detected */
>   0x0008 PCI_EXP_DEVSTA_URD /* Unsupported Request Detected */
> 
> Not impossible that these would be set.  Lots of URs happen during
> enumeration and we're not very good about cleaning these up.
> Correctable errors are common for some devices.  lspci -vv would
> decode the PCIe cap registers, including this.
> 
>>> (XEN) d0v1 conf read cf8 0x80010088 bytes 2 offset 0 data 0x2910
> 
> PCI_EXP_DEVCTL:
>   0x2000 PCI_EXP_DEVCTL_READRQ_512B
>   0x0800 PCI_EXP_DEVCTL_NOSNOOP_EN
>   0x0100 PCI_EXP_DEVCTL_EXT_TAG
>   0x0010 PCI_EXP_DEVCTL_RELAX_EN
> 
>>> (XEN) d0v1 conf write cf8 0x80010088 bytes 2 offset 0 data 0xa910
> 
> PCI_EXP_DEVCTL:
>   set 0x8000 PCI_EXP_DEVCTL_BCR_FLR
> 
> This looks like the actual FLR being initiated.
> 
>> This is the express capability's Link Control 2 Register afaict.
> 
> Unless I'm missing something this is actually Device Control.  So far
> I think this all looks OK.  The next part:

What you say is very plausible as far as the observed behavior goes,
but: According to the lspci output provided earlier the express
capability is at 58 (hex). Hence here we're 30 (hex) into the
capability, which according to the spec I'm looking at is Link
Control 2. Yet as said - with what you say being plausible, likely
I'm simply getting something very wrong.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Jan 31 08:37:10 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 31 Jan 2025 08:37:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879901.1290105 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdmWH-0000Z4-Gh; Fri, 31 Jan 2025 08:36:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879901.1290105; Fri, 31 Jan 2025 08:36:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdmWH-0000Yx-E4; Fri, 31 Jan 2025 08:36:57 +0000
Received: by outflank-mailman (input) for mailman id 879901;
 Fri, 31 Jan 2025 08:36:55 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=L32n=UX=invisiblethingslab.com=marmarek@srs-se1.protection.inumbo.net>)
 id 1tdmWF-0000Yr-Fz
 for xen-devel@lists.xenproject.org; Fri, 31 Jan 2025 08:36:55 +0000
Received: from fhigh-a1-smtp.messagingengine.com
 (fhigh-a1-smtp.messagingengine.com [103.168.172.152])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 83ab6c21-dfae-11ef-99a4-01e77a169b0f;
 Fri, 31 Jan 2025 09:36:50 +0100 (CET)
Received: from phl-compute-11.internal (phl-compute-11.phl.internal
 [10.202.2.51])
 by mailfhigh.phl.internal (Postfix) with ESMTP id 148251140138;
 Fri, 31 Jan 2025 03:36:49 -0500 (EST)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-11.internal (MEProxy); Fri, 31 Jan 2025 03:36:49 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri,
 31 Jan 2025 03:36:45 -0500 (EST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 83ab6c21-dfae-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm3; t=1738312609;
	 x=1738399009; bh=IXMGftBReYlennIOdFwHheoasdqI9W1hfK9JoMJAxBc=; b=
	jPSjDeXMdjddM8jyfVc/mz628wN/KYTraQZBncPWHBNqHtjRXbl/d9jdJKomV/sf
	W7DNZ8iCGkMEs9NXOLXRd/ITfVywB+wlqbr1VgwysQM/CWI6ui4VRz0aFUzoZAwU
	mXbsGJzdgIjM2f2CBih+z3fUBv2WKLmQ3gV8T3B/nJc4L2zuQP6c2tnZ7vU9fNLn
	hFoiyy7xbGXqCj3gG95e1nZDtOf0xM3Oo2/4UrqKWm/E0X564kaSPX4pwWuEkmrw
	mFGc682s4MSgqyjPawtUCSzMrHwAXcLDNIzoX6hR2Nac/C2bZkOOTKlFZ+TG9KD/
	ofTo/b0IulLDApYaWyEabA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:subject:subject:to
	:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=
	1738312609; x=1738399009; bh=IXMGftBReYlennIOdFwHheoasdqI9W1hfK9
	JoMJAxBc=; b=m1LMjXWYBb2qKKU6o6OqPUApcZdXdSUzwF7Zn71rs+CXCwPi746
	O9tkkJUPxMXbFP5YUejQr3a4g4mqYpqqQS1U0Rwqc0Ko4guxBrp+/j0+TSHCJhMs
	OltQrloe4rsuPOCTSCleVa5QzZ1WciDvF0QyWSruxnmKZsZ7mCpoDtEJvSdj3AQQ
	pUcfKwqywwRKf7BpD9s1KnqBC0qzQaFcItRYCLdsu1GK0LXrZnjTkszT/YAASMYL
	bsW5eR3OXdRy5866Si+rkUZXHjGiLiqzh/cEhWLgcE3xTc8vX9PDRCuEzNxhlSWi
	HWyaegnJ3r0JI8G9OBiwp5Dv0WsX62TIc1A==
X-ME-Sender: <xms:n4ucZ4dWMO5ArQ3TFhlTeEkKvkyOKtbCRcvweMJVkL-spsdMAT_7uQ>
    <xme:n4ucZ6M9vPZcGeU2xrKH7-cqL7Shx_045ATYVCPjW1cLKoJgWfxMz0avs-qHwgdqq
    SyBmt-0M0xn_A>
X-ME-Received: <xmr:n4ucZ5gIK1Et3EV5sOikibyBGqii6LcgGJAWw_re2n8WepCTLgP4HyvB8g>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdekvdekucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
    rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
    htshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtjeen
    ucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomh
    grrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggft
    rfgrthhtvghrnhepgfduleetfeevhfefheeiteeliefhjefhleduveetteekveettddvge
    euteefjedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhho
    mhepmhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnh
    gspghrtghpthhtohepuddvpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehjsggv
    uhhlihgthhesshhushgvrdgtohhmpdhrtghpthhtohephhgvlhhgrggrsheskhgvrhhnvg
    hlrdhorhhgpdhrtghpthhtohepsghhvghlghgrrghssehgohhoghhlvgdrtghomhdprhgt
    phhtthhopehjghhrohhsshesshhushgvrdgtohhmpdhrtghpthhtoheprhhoghgvrhdrph
    gruhestghithhrihigrdgtohhmpdhrtghpthhtohepsghorhhishdrohhsthhrohhvshhk
    hiesohhrrggtlhgvrdgtohhmpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtsh
    drgigvnhhprhhojhgvtghtrdhorhhgpdhrtghpthhtoheplhhinhhugidqkhgvrhhnvghl
    sehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheprhgvghhrvghsshhiohhnsh
    eslhhishhtshdrlhhinhhugidruggvvh
X-ME-Proxy: <xmx:n4ucZ9-kDjrvLy4XSWC6YxNHOnJeTQusj9aUPiRq4UHiL6FpqdQnWA>
    <xmx:n4ucZ0tRNHy61VTPvk15LC4dSblYDSVv9A-iXibWOzwo-wpZAHoJgw>
    <xmx:n4ucZ0GbWl_TAjbXQ5xJrk381pDv6IVw0ZIroS-OdNPvS7_p_QvBPw>
    <xmx:n4ucZzMSmvEEHujJsJHKaYPnQyOaU-RXPRDzYDVihnIlNdPJAjXWRQ>
    <xmx:oYucZ1EFC5Km1LRUmWVSp2Pqb4FKH5Fq0sQS_qSR1tXuhYhxgc0QNqYJ>
Feedback-ID: i1568416f:Fastmail
Date: Fri, 31 Jan 2025 09:36:43 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>, Bjorn Helgaas <bhelgaas@google.com>,
	=?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	linux-kernel@vger.kernel.org, regressions@lists.linux.dev,
	Felix Fietkau <nbd@nbd.name>, Lorenzo Bianconi <lorenzo@kernel.org>,
	Ryder Lee <ryder.lee@mediatek.com>
Subject: Re: Config space access to Mediatek MT7922 doesn't work after device
 reset in Xen PV dom0 (regression, Linux 6.12)
Message-ID: <Z5yLnDGeu7SVSLUU@mail-itl>
References: <20250130213123.GA633869@bhelgaas>
 <2d5b51e9-db32-4e46-97c8-2644081b7e33@suse.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="CZ5ZWPgOMlBg8Z2R"
Content-Disposition: inline
In-Reply-To: <2d5b51e9-db32-4e46-97c8-2644081b7e33@suse.com>


--CZ5ZWPgOMlBg8Z2R
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Fri, 31 Jan 2025 09:36:43 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>, Bjorn Helgaas <bhelgaas@google.com>,
	=?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	linux-kernel@vger.kernel.org, regressions@lists.linux.dev,
	Felix Fietkau <nbd@nbd.name>, Lorenzo Bianconi <lorenzo@kernel.org>,
	Ryder Lee <ryder.lee@mediatek.com>
Subject: Re: Config space access to Mediatek MT7922 doesn't work after device
 reset in Xen PV dom0 (regression, Linux 6.12)

On Fri, Jan 31, 2025 at 08:13:37AM +0100, Jan Beulich wrote:
> On 30.01.2025 22:31, Bjorn Helgaas wrote:
> > On Thu, Jan 30, 2025 at 10:30:33AM +0100, Jan Beulich wrote:
> >> On 30.01.2025 05:55, Marek Marczykowski-G=C3=B3recki wrote:
> >>> (XEN) d0v1 conf read cf8 0x80010088 bytes 2 offset 2 data 0x9
> >=20
> > PCIe Cap at 0x80, PCI_EXP_DEVCTL is 0x08, PCI_EXP_DEVSTA is 0x0a.
> >=20
> > 0x80010088 would be PCI_EXP_DEVCTL (a 2-byte register), maybe offset 2
> > gets us to PCI_EXP_DEVSTA?  Not sure.
> >=20
> >   0x0001 PCI_EXP_DEVSTA_CED /* Correctable Error Detected */
> >   0x0008 PCI_EXP_DEVSTA_URD /* Unsupported Request Detected */
> >=20
> > Not impossible that these would be set.  Lots of URs happen during
> > enumeration and we're not very good about cleaning these up.
> > Correctable errors are common for some devices.  lspci -vv would
> > decode the PCIe cap registers, including this.
> >=20
> >>> (XEN) d0v1 conf read cf8 0x80010088 bytes 2 offset 0 data 0x2910
> >=20
> > PCI_EXP_DEVCTL:
> >   0x2000 PCI_EXP_DEVCTL_READRQ_512B
> >   0x0800 PCI_EXP_DEVCTL_NOSNOOP_EN
> >   0x0100 PCI_EXP_DEVCTL_EXT_TAG
> >   0x0010 PCI_EXP_DEVCTL_RELAX_EN
> >=20
> >>> (XEN) d0v1 conf write cf8 0x80010088 bytes 2 offset 0 data 0xa910
> >=20
> > PCI_EXP_DEVCTL:
> >   set 0x8000 PCI_EXP_DEVCTL_BCR_FLR
> >=20
> > This looks like the actual FLR being initiated.
> >=20
> >> This is the express capability's Link Control 2 Register afaict.
> >=20
> > Unless I'm missing something this is actually Device Control.  So far
> > I think this all looks OK.  The next part:
>=20
> What you say is very plausible as far as the observed behavior goes,
> but: According to the lspci output provided earlier the express
> capability is at 58 (hex).=20

lspci in the log says:

	Capabilities: [80] Express Endpoint, IntMsgNum 0

I think you confused device config space with bridge config space.

> Hence here we're 30 (hex) into the
> capability, which according to the spec I'm looking at is Link
> Control 2. Yet as said - with what you say being plausible, likely
> I'm simply getting something very wrong.
>=20
> Jan

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

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

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmeci5wACgkQ24/THMrX
1ywToQgAjl2ykesXsSyhdpCEZErEHrUfXs09F4dPnDURMtJ3dYVmesYZLAznN/9q
ZhfyCkcWSAzXpxmoMcpxWkmqR5Szm6Ez2tiP2Z/vh1+/AYx4PhHhrK90Taio7SHU
hmn7nyQWi1lkNk9VtKTx7HdST7YZwZRBphuVF42W/4o7XRE9tGImB93JmfVe7TY4
rtT5dAOlCXNg4zRkH/M3XeHpwvCmX8WkYM8gWQqJXfMnXMxXoG3DujG0OBXHh968
WqvL860okPTnNR35c2TqBpdki1y4wqJnyT0oEZB7LIaARqXv2+6AcjGT82rQ5wCr
wuF0A+gT7Geq0b/tNzrgz4IH824HgA==
=+Iav
-----END PGP SIGNATURE-----

--CZ5ZWPgOMlBg8Z2R--


From xen-devel-bounces@lists.xenproject.org Fri Jan 31 11:18:34 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 31 Jan 2025 11:18:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879913.1290116 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdp2T-0001mf-8E; Fri, 31 Jan 2025 11:18:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879913.1290116; Fri, 31 Jan 2025 11:18:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdp2T-0001mY-5Z; Fri, 31 Jan 2025 11:18:21 +0000
Received: by outflank-mailman (input) for mailman id 879913;
 Fri, 31 Jan 2025 11:18:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=a7eC=UX=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tdp2R-0001mS-L5
 for xen-devel@lists.xenproject.org; Fri, 31 Jan 2025 11:18:19 +0000
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com
 [2a00:1450:4864:20::333])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 111a6969-dfc5-11ef-99a4-01e77a169b0f;
 Fri, 31 Jan 2025 12:18:16 +0100 (CET)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-43625c4a50dso13099735e9.0
 for <xen-devel@lists.xenproject.org>; Fri, 31 Jan 2025 03:18:16 -0800 (PST)
Received: from [130.190.75.105] (wificampus-075105.grenet.fr. [130.190.75.105])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38c5c102ee0sm4453159f8f.37.2025.01.31.03.18.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 31 Jan 2025 03:18:14 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 111a6969-dfc5-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1738322295; x=1738927095; darn=lists.xenproject.org;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=jHfByAdV8A6fu7yMamCu/dnF6oizcEA2sQW109vUEEM=;
        b=GSxe5jb5vMSpZ+3NJFxVej7wdU8JMW05O+jF6w4q5AjzbszGyauaYF2PiuHFgPOtAo
         mUg6hvgNRF7Ls82m7baloNlW/CZ9LC7wVKe1XxHEic7i84mS1vOZG3tbxeC4fO72CiED
         iG6K0zwy4bO8DKWbiDRGFmWTPOk2jR/HPq6q4tI5wurflHEII331vHYWyyQJ6m4JWt/r
         iUiM5LSOFRSPc0By5yD4avg24hKNfFiTeNqw+9cav9igghHpptd70Nj7U8roG7IFJD7+
         SFdxzo3YUWw0L7HASM9JUtFwv23eSHJ9A949jurQ009TM35xDRKAWPkMtLLaa/DT07/s
         vySw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738322295; x=1738927095;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=jHfByAdV8A6fu7yMamCu/dnF6oizcEA2sQW109vUEEM=;
        b=vVMZ66gy9gXCBtpK0PMCGVJGZEDev0ZmIwdW43pCnvm7OOuXIz3loq8+jVf+4tNRe7
         2WVHcn2rhqkVcdLowEdEOqRaiA20nKnzh72AzvqVhrd3ZLqao2JmOOaPHI5NVAq+2I1A
         ng0HhC68jWGXW2/HQyXUminxyC8PlpXYhZyUTv0MtVcLGKVzsSploD+3uO1y8sC7cPN8
         3TWLaz/ZI4oGeW57d4/Y6AgwIsHiuQfxhQG501KWe1zRT+Q8WoveNPX5yUv6CJEc3JkO
         b47gacxW+qjQMDAZhtAVpJhHBczEDYIZEqx8omueEDQI/sdr0ZYUnIHG+RPLsCNdssul
         lECQ==
X-Forwarded-Encrypted: i=1; AJvYcCUVt5/hPs2qdmq3oqnUQkKMcAMFtoTVzwyfRL39b0s64XYndubFS4EP7q7yn0xOlz8xn9tDy2rohp0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxRQq9UuCrgjAaoAknh6neFN2sjnemYaR+GgBxjuhvl4Yc9zQaj
	GrHMKVrhGS+BWmyOZSx033Q45S8ZOX10AWys4j9/vwskwHVYbrns
X-Gm-Gg: ASbGncv56Yi3jzEmUBRgZejVIZ4pthBlCtktxQSV/r3h5+QyyL10ETOhTFi9nKQW5kI
	ZEE30c12B+laFK7dBDExI0GUMKoiBaqgCRlEGUUujxle7u5y9qnhb6TrxFX+P+Upiw2hr1gIdOQ
	QwVLDwvxFp1GsRL5QgVhDUqQeuRg9xN0MMtJ0uNm/Kx66nQCWYHG5upYDQ7l6WGenBXymKMuY/+
	RwtRRKcmgm0+alx5NY+pQMVnfZVxdERbXMPZmAGD9+CqfaJOUHGR1QYFO9lGMnMmwlm/ZZ9W1X6
	Fs+x6btylF2iNN5QhqOWHAavDj4/Snvwm6zUUYE6nS6dhxX+EnDRFT96NQU=
X-Google-Smtp-Source: AGHT+IEZU+i9NM9gL4lDu9rrho7ftx3XorMt3TA5odPPV2tpWxSwYufwZ3dwEpFXhUOPxXalEmzhXQ==
X-Received: by 2002:a05:600c:8711:b0:434:fd01:2e5f with SMTP id 5b1f17b1804b1-438ea3c1ceemr16858705e9.29.1738322295256;
        Fri, 31 Jan 2025 03:18:15 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------mkN6u23kiz0sY0SZ9Wm6est0"
Message-ID: <3002677f-f786-4a79-9073-7a5af1bbab9f@gmail.com>
Date: Fri, 31 Jan 2025 12:18:13 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20 0/3] AMD/IOMMU: assorted corrections
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
References: <2bb9d3c4-0761-4d63-8193-29293e35eb04@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <2bb9d3c4-0761-4d63-8193-29293e35eb04@suse.com>

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


On 1/30/25 12:10 PM, Jan Beulich wrote:
> The three patches are functionally independent, and they're presented
> here merely in the order I came to notice the respective issues. At least
> patch 2 wants seriously considering for 4.20.

Based on the commit message for patch 2 should be merged to 4.20, patch 1 could be merged too as it is pretty straightforward
and I don't really mind to merge some additional logs. With proper review:
R-Acked-by: Oleksii Kurochko<oleksii.kurochko@gmail.com>

Thanks.

~ Oleksii

>
> 1: AMD/IOMMU: drop stray MSI enabling
> 2: x86/PCI: init segments earlier
> 3: AMD/IOMMU: log IVHD contents
>
> Jan
--------------mkN6u23kiz0sY0SZ9Wm6est0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 1/30/25 12:10 PM, Jan Beulich wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:2bb9d3c4-0761-4d63-8193-29293e35eb04@suse.com">
      <pre wrap="" class="moz-quote-pre">The three patches are functionally independent, and they're presented
here merely in the order I came to notice the respective issues. At least
patch 2 wants seriously considering for 4.20.</pre>
    </blockquote>
    <pre>Based on the commit message for patch 2 should be merged to 4.20, patch 1 could be merged too as it is pretty straightforward
and I don't really mind to merge some additional logs. With proper review:
R-Acked-by: Oleksii Kurochko <a class="moz-txt-link-rfc2396E" href="mailto:oleksii.kurochko@gmail.com">&lt;oleksii.kurochko@gmail.com&gt;</a>

Thanks.

~ Oleksii

</pre>
    <blockquote type="cite"
      cite="mid:2bb9d3c4-0761-4d63-8193-29293e35eb04@suse.com">
      <pre wrap="" class="moz-quote-pre">

1: AMD/IOMMU: drop stray MSI enabling
2: x86/PCI: init segments earlier
3: AMD/IOMMU: log IVHD contents

Jan
</pre>
    </blockquote>
  </body>
</html>

--------------mkN6u23kiz0sY0SZ9Wm6est0--


From xen-devel-bounces@lists.xenproject.org Fri Jan 31 12:06:19 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 31 Jan 2025 12:06:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879931.1290125 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdpmo-0007jz-J9; Fri, 31 Jan 2025 12:06:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879931.1290125; Fri, 31 Jan 2025 12:06:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdpmo-0007js-Gd; Fri, 31 Jan 2025 12:06:14 +0000
Received: by outflank-mailman (input) for mailman id 879931;
 Fri, 31 Jan 2025 12:06: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
 <SRS0=sR5g=UX=oracle.com=harshvardhan.j.jha@srs-se1.protection.inumbo.net>)
 id 1tdpmn-0007jm-0G
 for xen-devel@lists.xenproject.org; Fri, 31 Jan 2025 12:06:13 +0000
Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com
 [205.220.177.32]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c191a0df-dfcb-11ef-99a4-01e77a169b0f;
 Fri, 31 Jan 2025 13:06:10 +0100 (CET)
Received: from pps.filterd (m0246630.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 50VAps0j030380;
 Fri, 31 Jan 2025 12:06:03 GMT
Received: from iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com
 (iadpaimrmta03.appoci.oracle.com [130.35.103.27])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 44gw4w03d0-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Fri, 31 Jan 2025 12:06:03 +0000 (GMT)
Received: from pps.filterd
 (iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
 by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.2/8.18.1.2)
 with ESMTP id 50V9p1BL004348; Fri, 31 Jan 2025 12:06:02 GMT
Received: from nam12-bn8-obe.outbound.protection.outlook.com
 (mail-bn8nam12lp2168.outbound.protection.outlook.com [104.47.55.168])
 by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id
 44gfe4v1g8-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Fri, 31 Jan 2025 12:06:02 +0000
Received: from PH7PR10MB6505.namprd10.prod.outlook.com (2603:10b6:510:200::11)
 by DS0PR10MB6126.namprd10.prod.outlook.com (2603:10b6:8:c6::20) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8398.18; Fri, 31 Jan
 2025 12:06:00 +0000
Received: from PH7PR10MB6505.namprd10.prod.outlook.com
 ([fe80::83d9:1bf1:52cf:df54]) by PH7PR10MB6505.namprd10.prod.outlook.com
 ([fe80::83d9:1bf1:52cf:df54%6]) with mapi id 15.20.8398.017; Fri, 31 Jan 2025
 12:06:00 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: c191a0df-dfcb-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=
	corp-2023-11-20; bh=zOWS532+MAEoMToqzEcaiGv9smLFDsXnuZHrC0ch6pY=; b=
	aLLAu21Egk+FMmDalcyCoyoBaXy73VHn7H5O/uvWUw78sWInNbV8BHntny2efnid
	ca9fyIw7oErhWVcg+TESkCSbCXrptfUqYB310mzKcPf6ksv3Mse961BC2kEnNr51
	V+L03MhfAsiWgWtGRug8SwRudHc4uiC0W/Ek+QkBUxbCBmR5KFUiSVE5hl072UmG
	QrgTRldEBIkTlUMGcpKLCwJRUtXVIrWRMcjFSaSKusYO8qmH8qzJ+nN8+QJnHb2c
	kR7W7bG7A1oU1yZfhLH800uOrHrnzdWhozVePOlxnynEmXCkBtsqVFe8PNDAobIh
	n+Dre+YvIlixnttPBQknXw==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=yKDvyEYOSf0Ur7fucuvvqqu8i3JZnqdxY8En7voL1f6qyhOQCL+uBb56alZAbOcsmuzl4zkMWJMHm1SMHD2CuVptdxoB61HuKloH/T2dt92e4lhXSj7yFaeJ0+Zst5FPrGNjsQJ+HLENZXH8/ZaRoGjUgBt46wJ/LE0v9bijkMpj/pDFOdod++ZH4lwYQnZEYoluq1dszw3n8TA06wQtUxWMFMnM7xjNCZxVgRqS0DBvn9DPrJXJlC2Cy5tNWbj0SuYeoaKZ6oRTKsQ+W7d+zWDCqAKES7rbVbeXUmI0k4feWZFf45dM6mCHuRy3z6lfI8hGNL3znMXHGM+taXD9xQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=zOWS532+MAEoMToqzEcaiGv9smLFDsXnuZHrC0ch6pY=;
 b=WVAQP8QRZ1SVuqDZJdbEDqmbSHyCTZfDzc6kEuBtNk5Qv36vS9pZcznv9y00XzszoqxpwVRTn5Jjr8YGyhIv4yCUsRXCzvBt7AKy7WwLDDKU9Rpn+5/u5t8bi1iOJtye3+M2VQHgP2hvl9KM3uACIjPJ2OohlCzA78PPGEXsbA8KAtu8EtSrOOIb/bWQbSia1ZqPxFq82pRXoAUWLpmgOuS1J2bvhaeunxo3c5xmXFHemID7vxy1OTrbSAemmszy1z7V3WUCwh2JwVzoQhOECBFZ/UuE62jRvLF2ywDC6vY3b4Hum3ttAD0xhSkhHwB19BhEOSocW97DhepaaAV7Zg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
 dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=zOWS532+MAEoMToqzEcaiGv9smLFDsXnuZHrC0ch6pY=;
 b=WQEwSZeCOiqCNHQl+RL69Y3p3XOBCqmWEIEWNMVAdJwBdaCmkEDV5+V65+VECW2JmLtl1xS6gYjdaGHQdG5E2ZbuCfzFbvU6RrwZAb+/TJvT1yqFBQLVSZ10/bQS7u6nX3tIxFQPsBf8uuipSwtld2sftjKmxMzoIYKB44v4vgs=
Message-ID: <17ed9a71-227c-4e7f-8fcf-402dd00f3837@oracle.com>
Date: Fri, 31 Jan 2025 17:35:52 +0530
User-Agent: Mozilla Thunderbird
Subject: Re: v5.4.289 failed to boot with error megasas_build_io_fusion 3219
 sge_count (-12) is out of range
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
        Greg KH <gregkh@linuxfoundation.org>
Cc: Konrad Wilk <konrad.wilk@oracle.com>,
        Boris Ostrovsky <boris.ostrovsky@oracle.com>,
        "sstabellini@kernel.org" <sstabellini@kernel.org>,
        "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>,
        stable@vger.kernel.org
References: <7dc143fa-4a48-440b-b624-ac57a361ac74@oracle.com>
 <9dd91f6e-1c66-4961-994e-dbda87d69dad@oracle.com>
 <2025012919-series-chaps-856e@gregkh>
 <8eb33b38-23e1-4e43-8952-3f2b05660236@oracle.com>
 <2025012936-finalize-ducktail-c524@gregkh>
 <1f017284-1a29-49d8-b0d9-92409561990e@oracle.com>
 <2025012956-jiffy-condone-3137@gregkh>
 <1f225b8d-d958-4304-829e-8798884d9b6b@oracle.com>
 <83bd90c7-8879-4462-9548-bb5b69cac39e@suse.com>
 <b4ab0246-3846-41d1-8e84-64bd7fefc089@oracle.com>
 <de6912ad-3dba-4d66-8ca2-71a0aa09172c@suse.com>
 <686986a0-c981-4aa3-ae88-92a34368129e@oracle.com>
 <5a7d969b-b2ab-4fac-b95e-4a536e2c8d5c@suse.com>
Content-Language: en-US
From: Harshvardhan Jha <harshvardhan.j.jha@oracle.com>
In-Reply-To: <5a7d969b-b2ab-4fac-b95e-4a536e2c8d5c@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: KL1P15301CA0047.APCP153.PROD.OUTLOOK.COM
 (2603:1096:820:6::35) To PH7PR10MB6505.namprd10.prod.outlook.com
 (2603:10b6:510:200::11)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH7PR10MB6505:EE_|DS0PR10MB6126:EE_
X-MS-Office365-Filtering-Correlation-Id: af34f866-1afd-450b-b360-08dd41efa05a
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?eEFDNW5vcnJHY3lBcHI1T2xXTTlSWi9jNTNlb2VPcDlGeUg2YXAwaDlUQlA1?=
 =?utf-8?B?YklLODNNczRnMTNrZGNFMjI3N011RmtBRGtuLzFoWEErTDJuSS91ZnNNT1RB?=
 =?utf-8?B?L0tKb2lCd1RubjdHeXZNUlAvdkZscXlUank3WHB3RTlMY2RFRnB3UlJadk96?=
 =?utf-8?B?Ujllbkt5bElHdTF2SFZ5Rk5lSEEvVFIyYVlRZ2h5SWtPZy9LZDBHaGFwcDJT?=
 =?utf-8?B?QTBqT3hsNHF5WktZZzlweGpMMmowVHhUeVZrMHVrZklucHBIM2xSanRHUnZR?=
 =?utf-8?B?MHRZSUwybFlZMm5VNTRVbVFkZXdES3VyaEhiMTk4aEl0R3ZQZHJuWm1RamZX?=
 =?utf-8?B?b3VqeW5NVEhzMTF0YkNxTlBEcmVYWUVLWlBGN2hmNzJ3TFJieThyWXdhRnh0?=
 =?utf-8?B?SSt5UkZ0OStCSnNVdE5CUFZvMktrSnkreWQrT1c3ME1HSm1oT3ZuSjY1OVdT?=
 =?utf-8?B?NjhCWnN1QVRIN0YxSmNvSVFSamV1RjQyTjQwM293c0c5cEhHNktiV1dFRXFV?=
 =?utf-8?B?eWdLVGtzYzAzZ0VxQzlTS21KbkZtNGdGcXFnMU1taDVyUi9KV0lNUU5LQ1NI?=
 =?utf-8?B?WTQ3RVZocXQzeGladWRnUHdiK3Mvc0hldWxUdDhxS1hZaXVkL21JQ2tvZERt?=
 =?utf-8?B?MVZFZHJkYWFiSis3TUNTWXNZd1Y2c2o0RXU1SytoSFJQVzBSczFSWUpyQXQ2?=
 =?utf-8?B?N3Q4cGs2K2liUHo5MnJrM244TWRGNGlTdURFY0FtMnhtalFQQllwZSs5RTdY?=
 =?utf-8?B?MUZPaDBHQUVqN1RVUkpJaHQ2OWVPc0IvTzNXNjh3c2pvenNyYjI5WjRtWGg0?=
 =?utf-8?B?V1Z3QjBPanVndDZvbTlQRVNpcU9LM0FJdlY1dEFzNjQ2U0lFa3B5ZjUyZm5Z?=
 =?utf-8?B?SnlLSHU3NGw2MktvTmthcVNLeFMzVmhJQzFqRklydjhWRVNYUW9mKzJoVVg3?=
 =?utf-8?B?b0ZpY2RQWDh2UmVFRUIwUkJNaUZKVGRpZHVxWDRuWUFGeVNlUmhpM2lSQURw?=
 =?utf-8?B?NEt4Z2ZtR2d6REQrbURMcVVobEZTalJWaUQvVUppdHUyMzRzZklZVWlYVDl2?=
 =?utf-8?B?MjN5Mk96VFpKYlU0M0dkdXRRMUFKU0o1c0VvSjVGdnNWTHVtTXp1eExKZlFI?=
 =?utf-8?B?alJOYWcvZ2ZzYnFic3d0c1FBU1ZUMjY4N3p5U3hRMFJZS3NpTVZZT3VNaS94?=
 =?utf-8?B?TVVYSVlqQXpuZHJFaVJGVW9oa1dhdFo0UTlWM0tsc2NHaStOOE5KVkFEL2Y4?=
 =?utf-8?B?SE9WZFBVK2paZmV2ODZ5Q2NEcFA4Y0VvSXB5ZmRCTTE4aStXL0s4R0Z3NjRn?=
 =?utf-8?B?YXVwbStPaXJSTkNJazNKSWVGaFd2Qndxc0c1OVMybUdFTllKRkk5K1BERXcw?=
 =?utf-8?B?Qy9aa0Z0aE95N3BmcUpCZHhpNzc0WWJiZXZiNFdXclcxd0RZZXJlZ2xVa1VS?=
 =?utf-8?B?RnJXa2dqK2ZCejJBemllQ2lMMHFuZXQxRU1WSDZRcWx6UW93S2Z4c3l0Tncr?=
 =?utf-8?B?QjFoNVR1UGlqT0c2N2dtbS9MdzhoOTRuRzBWUWtoc0xBS1hnQ0RVNENLMGZs?=
 =?utf-8?B?enNVSi8zNjl5elA4ckNjNXJXQUZUODl1QlU4c0EyMU41YVAvOGxPMDBSblpG?=
 =?utf-8?B?VXVsR2dMRXlqeHFncUhNc2ZLZ0dpS3ROQU0zWUt5TlJjRlRuc2FhY2tQZnhz?=
 =?utf-8?B?MXRmeXVFbnRnTjhxOS9TZkp1UzhtbW8zTC9UcGtwLzdOblIxL1Aya2NWN2oy?=
 =?utf-8?B?ai9YeUFHVmVIb091SVF5a2lZVVA5cEFwKy9Ra0tSQjdvSk4ybFRkSmFpY0F0?=
 =?utf-8?B?WS95MDd5NHJXMVJRSGdLR0ZNb2tNazJrQTZmWDJWa1NLajRUSnI0NmE3Tjgx?=
 =?utf-8?Q?Cp5Rz95Hocrpn?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH7PR10MB6505.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?KzgzNnFIOUFUWG41UjJJOW1CQTRFMi9taFB1TmFQQlEvVWJhT1d0VVhFMjF6?=
 =?utf-8?B?cWdTRUNxYUplR1BjbkUyRjU4c25WbTJobjZvYzlHaWZMeDcwQ3VkNXhna0tC?=
 =?utf-8?B?RnBWbUVheExHNjIxYXVwejVrK0R4QVErcCtoWndZaGVoMHFvTUFGanlESWYv?=
 =?utf-8?B?UXVmR1hHVFVOSFNWSzk5OFFLdzNYcTA1amRMeDdXbDBRZ2JHaW5CY0xhNzdF?=
 =?utf-8?B?RDh4bW9ZdlN5RjhZNDBta0t2dUpKZ05Iakl0dW5nWEprNFlBZXh5MUw1Yk9D?=
 =?utf-8?B?cDIvSUJVd0FNVWNiNnJBM200c0VhckdSUzE0ZklkRTYzd1pkOGlhckJwZDhx?=
 =?utf-8?B?Q1ViMFlRS1JMSUk5WEVTRUZmVi92eWhrR3lMUnltcjlhbUc1QVhmOGs0b3lT?=
 =?utf-8?B?YmQ5VityZ1R3cmRyVnUwZzJsQUtlV2dEY0gvM3lZR2NrdC9QQ2ZzbzVTYTlF?=
 =?utf-8?B?TDBuK1FDcmpBZlZQUjI2clZMcWpvNkZ2Mk5ZcVdRbzVXMVNxSHRhRCttajkv?=
 =?utf-8?B?UGxRb05aYk1oZDZYWlBqcTZnRkFTNXdwT3hjQnk0VU03ZVZaSHlmNEhmT2hN?=
 =?utf-8?B?YVEvYTNjZitYQW5GNUNJdTYwSnhPMmlDbEx4bDE3ejhjTnROYTdzeGt4eEZG?=
 =?utf-8?B?M2xjenQ5Z3FlUURjenhzT3phblcvZnFJU0N1TmZDc3FjSDYyWVovM3ZGQnJQ?=
 =?utf-8?B?WmFTT2JJV3FmTUNlVThvb2dmSUR0SVNjWWdBNkowMTMwUUpyam1JclJNQ2tO?=
 =?utf-8?B?N3c2ZjMzQ0lwMjFMZ28zOGc2RkxiN2gvaTNwNG5wWTRZTmtGVFZINnprRjJ1?=
 =?utf-8?B?YkM4SHIwd2JzZ0tySGxKRVFzenRNTjZyN2VVaTR6eTJhVFpqalpheDJLbHoy?=
 =?utf-8?B?cXgxbEcyTld2c0JVSnFMK0VMNFlwN1Rmb05GaHlxL3ZPRlF2L2JndmtYNThQ?=
 =?utf-8?B?MTZxcTBwekI3a0dxcDhzRGVya2VQeFZvdGVpTC9FSThvQUZ0Z3dWcG4wSDFa?=
 =?utf-8?B?MWQyeEo2eGZxNWVSbFlzQUpLTjVmMlgwM3RCd25LNU4xemRlUUlpKzdubkoy?=
 =?utf-8?B?Z0NLeHRqQ1J6b280Q1pVWDkrbmcvcjJGd05Xd3dsWldnSThiZ1FOdjQwNTAx?=
 =?utf-8?B?aElZR0tlN3kzSisyNFNjcnBqTUx1UlNsSktpa0RmZ2JIVVlsVll2UnRBc2ky?=
 =?utf-8?B?MFRYbXRYTG5DYllRRFM0RGxUSnU2N01YNDRxdHA3SUlKTkRYQ3FrQ3JEa2c5?=
 =?utf-8?B?RnRicCs2eHdLdzlRM2RMVEZ4aVZuZXpBVEdhK0NXWCtrZEpVc29EVXFNMlVw?=
 =?utf-8?B?VXYxWWZuUFZvOFRXSThTeGRXemRXMzRaQVZENUN1NTZtUnhtTUFuelIrTGJC?=
 =?utf-8?B?c2hKdStUdk5IN0ZURXVtbGE0eTdnNndrdU5mM0RKUXZuRGk3cGgyVDhxUDF5?=
 =?utf-8?B?SmlybGN0MVFsZDIrTUNhY0p3REh1Y2xRUlJCNGNrTmpkdjlkcXVNLzRVa1A5?=
 =?utf-8?B?bzd5c3VZd09ISUFxRitrMHcwc3FyV0pLSUNaZmFvQ0ViM29xaW03aTRKZkYy?=
 =?utf-8?B?cWhmeSswQWRrVnVTSitMRXJTQVhSMzNVWk9EUklXK3JuVHpseEJRclI1aG5V?=
 =?utf-8?B?RW1FZm1YaG9Ia2d2RjRYcHZPRS84WU4vTTdSbmxHbTZzbTBsZTNiZVg0cFpL?=
 =?utf-8?B?c1NZdU5YaE4xdkdVcFczQTgycUlkZlRQMnhtMmZIL1dFTWFWUHRPNGNmT3Nv?=
 =?utf-8?B?allabTJneWREVEQ3SjBQMm1kV3JWKzVFRkpHc3F3T1lRRVhCWGk4aHNjekZD?=
 =?utf-8?B?QW5CK2dyTzRFTjhFM3BDbDNqYWVkQ0d6bk4yYXExSmZvcGh2YjEzdDF4Qlhw?=
 =?utf-8?B?ek1INWRLdFpzb0xtRHNjRTVUNlhZQ20xalNtR2hKMEgrbjFQS3hUd2ozajRX?=
 =?utf-8?B?VklVblRIUFo1dzRxT3BrTXpzZ0NZeUg1ejZMdzFUWDFTcnpyUHdOOU1XNDFC?=
 =?utf-8?B?SnVpU0lCb3R5VHVobzBSK0xua2NDdjhaWUxqTjdOZ3hqVU9jRlZYSU00WTZ5?=
 =?utf-8?B?L1ZJOWtzeFRzc2huRWdFaUJGSUNveW4zV1VzRHM3WU9iLzZobDRhVW9DdFdu?=
 =?utf-8?B?WnFkYkNqbk93QWs1ODA4RFVzeDBwQi85YU5ZQW9jQ1BtQVlDWUc2R09qZGZi?=
 =?utf-8?B?QkE9PQ==?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	NsUtxYOgkC4Zif7ikn/qggygC7PBunaF1vRgI4YqmTzJ6hk5GH9tsmzF5/7LZ49YrpEflp2vZDklOJZdtm2l2wBeIsi3aNXDkVskF25s3Wpv4rieaAlO17fs6IJMHpJptQekWlLcIsb4+ppZMvq9oohmCIRSkecnQfSEId+xrUGYAzRI8K76LqOoX8y09kxGAd6lKt+LSVderAGG1ZlRmbdgUFmCnPsvFVx4s4h0jjQ1WJnZ6tgYSw8UzC0R36FFb8pTHrB/nwt/QyBDTMYK6YDyakTi67YW4vzXfa96ej8uR7296edZinimRd/f++CE1i3dpibmOOYo4YVAcG6kRAgYoJepRj+ZqGoCaoh88acx/rjJT62m0GEpNcqA5mOVVsSd/0ffnjqJNpz5H85YJkgyUH7LwMwrSeTg7ZXVMAY3Q5Z/r2t7lBijB5jU+bW3oUujTlanIUtKOTzh/XbiiU0tZKex3BFhtwmiCuNRb1tz8C5hNc2sJNimAilbCm2mFk8TuAZyW3xdfirSSV2SGzjCBvvunkCClcrcZea64nlCBqTZeHmuj8uCLgNqHgnxsWtFdBNtNIDgqGelesi2AAhJBjVlpYJBancp3WWGfB4=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: af34f866-1afd-450b-b360-08dd41efa05a
X-MS-Exchange-CrossTenant-AuthSource: PH7PR10MB6505.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Jan 2025 12:06:00.3708
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: fbvI8minBtQx8nN39u+M48dFXl5Qjp2S/MfvaFo3Dp+JfNn5rrNqp/AQsuAWAKermlMTycWMp82vRbsUBh6xLUEwNCGH1i4Bm1R1NPqX2qg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR10MB6126
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34
 definitions=2025-01-31_04,2025-01-31_02,2024-11-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 malwarescore=0 spamscore=0
 phishscore=0 suspectscore=0 mlxscore=0 mlxlogscore=999 bulkscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2501170000
 definitions=main-2501310092
X-Proofpoint-ORIG-GUID: fJRy3y3cRbMWy6Gud5vx7Cj_ipm5wUk_
X-Proofpoint-GUID: fJRy3y3cRbMWy6Gud5vx7Cj_ipm5wUk_


On 30/01/25 6:05 PM, Jürgen Groß wrote:
> On 29.01.25 19:46, Harshvardhan Jha wrote:
>>
>> On 30/01/25 12:13 AM, Jürgen Groß wrote:
>>> On 29.01.25 19:35, Harshvardhan Jha wrote:
>>>>
>>>> On 29/01/25 4:52 PM, Juergen Gross wrote:
>>>>> On 29.01.25 10:15, Harshvardhan Jha wrote:
>>>>>>
>>>>>> On 29/01/25 2:34 PM, Greg KH wrote:
>>>>>>> On Wed, Jan 29, 2025 at 02:29:48PM +0530, Harshvardhan Jha wrote:
>>>>>>>> Hi Greg,
>>>>>>>>
>>>>>>>> On 29/01/25 2:18 PM, Greg KH wrote:
>>>>>>>>> On Wed, Jan 29, 2025 at 02:13:34PM +0530, Harshvardhan Jha wrote:
>>>>>>>>>> Hi there,
>>>>>>>>>>
>>>>>>>>>> On 29/01/25 2:05 PM, Greg KH wrote:
>>>>>>>>>>> On Wed, Jan 29, 2025 at 02:03:51PM +0530, Harshvardhan Jha
>>>>>>>>>>> wrote:
>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>
>>>>>>>>>>>> +stable
>>>>>>>>>>>>
>>>>>>>>>>>> There seems to be some formatting issues in my log output. I
>>>>>>>>>>>> have
>>>>>>>>>>>> attached it as a file.
>>>>>>>>>>> Confused, what are you wanting us to do here in the stable
>>>>>>>>>>> tree?
>>>>>>>>>>>
>>>>>>>>>>> thanks,
>>>>>>>>>>>
>>>>>>>>>>> greg k-h
>>>>>>>>>> Since, this is reproducible on 5.4.y I have added stable. The
>>>>>>>>>> culprit
>>>>>>>>>> commit which upon getting reverted fixes this issue is also
>>>>>>>>>> present in
>>>>>>>>>> 5.4.y stable.
>>>>>>>>> What culprit commit?  I see no information here :(
>>>>>>>>>
>>>>>>>>> Remember, top-posting is evil...
>>>>>>>> My apologies,
>>>>>>>>
>>>>>>>> The stable tag v5.4.289 seems to fail to boot with the following
>>>>>>>> prompt in an infinite loop:
>>>>>>>> [   24.427217] megaraid_sas 0000:65:00.0: megasas_build_io_fusion
>>>>>>>> 3273 sge_count (-12) is out of range. Range is:  0-256
>>>>>>>>
>>>>>>>> Reverting the following patch seems to fix the issue:
>>>>>>>>
>>>>>>>> stable-5.4      : v5.4.285             - 5df29a445f3a
>>>>>>>> xen/swiotlb: add
>>>>>>>> alignment check for dma buffers
>>>>>>>>
>>>>>>>> I tried changing swiotlb grub command line arguments but that
>>>>>>>> didn't
>>>>>>>> seem to help much unfortunately and the error was seen again.
>>>>>>>>
>>>>>>> Ok, can you submit this revert with the information about why it
>>>>>>> should
>>>>>>> not be included in the 5.4.y tree and cc: everyone involved and
>>>>>>> then we
>>>>>>> will be glad to queue it up.
>>>>>>>
>>>>>>> thanks,
>>>>>>>
>>>>>>> greg k-h
>>>>>>
>>>>>> This might be reproducible on other stable trees and mainline as
>>>>>> well so
>>>>>> we will get it fixed there and I will submit the necessary fix to
>>>>>> stable
>>>>>> when everything is sorted out on mainline.
>>>>>
>>>>> Right. Just reverting my patch will trade one error with another one
>>>>> (the
>>>>> one which triggered me to write the patch).
>>>>>
>>>>> There are two possible ways to fix the issue:
>>>>>
>>>>> - allow larger DMA buffers in xen/swiotlb (today 2MB are the max.
>>>>> supported
>>>>>     size, the megaraid_sas driver seems to effectively request 4MB)
>>>>
>>>> This seems relatively simpler to implement but I'm not sure whether
>>>> it's
>>>> the most optimal approach
>>>
>>> Just making the static array larger used to hold the frame numbers for
>>> the
>>> buffer seems to be a waste of memory for most configurations.
>> Yep definitely not required in most cases.
>>>
>>> I'm thinking of an allocated array using the max needed size (replace a
>>> former buffer with a larger one if needed).
>>
>> This seems like the right way to go.
>
> Can you try the attached patch, please? I don't have a system at hand
> showing the problem.
I tried this and got this error in an infinite loop again:
[   25.827922] megaraid_sas 0000:65:00.0: megasas_build_io_fusion 3273
sge_count (-12) is out of range. Range is:  0-256
[   25.828447] megaraid_sas 0000:65:00.0: Error building command
>
>
> Juergen


From xen-devel-bounces@lists.xenproject.org Fri Jan 31 12:37:35 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 31 Jan 2025 12:37:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879939.1290136 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdqGv-000385-Ss; Fri, 31 Jan 2025 12:37:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879939.1290136; Fri, 31 Jan 2025 12:37:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdqGv-00037y-Q7; Fri, 31 Jan 2025 12:37:21 +0000
Received: by outflank-mailman (input) for mailman id 879939;
 Fri, 31 Jan 2025 12:37:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=ME7v=UX=suse.de=farosas@srs-se1.protection.inumbo.net>)
 id 1tdqGt-00037q-Lp
 for xen-devel@lists.xenproject.org; Fri, 31 Jan 2025 12:37:19 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1a4b428a-dfd0-11ef-99a4-01e77a169b0f;
 Fri, 31 Jan 2025 13:37:16 +0100 (CET)
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id 5EBB51F38F;
 Fri, 31 Jan 2025 12:37:15 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id B7D5C133A6;
 Fri, 31 Jan 2025 12:37:14 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id pl5HHfrDnGcMVwAAD6G6ig
 (envelope-from <farosas@suse.de>); Fri, 31 Jan 2025 12:37:14 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 1a4b428a-dfd0-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1738327035; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=5/Y+l3I+LWiIyHZ0d4aDhx/MttQxBZszSFtZwXlxrho=;
	b=F70snUjqpyk8KV+m/V81VqXP61b0lR558gm+ZeHuC2LkGVpi5Np3j/p/RWuW2nh4ikvST6
	lvBbUqgohkaVDqR+xvWe5Z2cIvVUB7GXUTQEjUA5DSEysjR/gSSBHSym9OhMa1sD970cHk
	SOSG3TEX3oJUpD3xizABEqOi10FHgpw=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1738327035;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=5/Y+l3I+LWiIyHZ0d4aDhx/MttQxBZszSFtZwXlxrho=;
	b=eU8nAYHd5WnDpnMtx+l07PyNTyMXXCyljKidBabmdTg3VhLf68tgPDmzFYK8hDH+dV6HK4
	QodoQAGvgYtatqBg==
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.de header.s=susede2_rsa header.b=F70snUjq;
	dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=eU8nAYHd
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1738327035; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=5/Y+l3I+LWiIyHZ0d4aDhx/MttQxBZszSFtZwXlxrho=;
	b=F70snUjqpyk8KV+m/V81VqXP61b0lR558gm+ZeHuC2LkGVpi5Np3j/p/RWuW2nh4ikvST6
	lvBbUqgohkaVDqR+xvWe5Z2cIvVUB7GXUTQEjUA5DSEysjR/gSSBHSym9OhMa1sD970cHk
	SOSG3TEX3oJUpD3xizABEqOi10FHgpw=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1738327035;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=5/Y+l3I+LWiIyHZ0d4aDhx/MttQxBZszSFtZwXlxrho=;
	b=eU8nAYHd5WnDpnMtx+l07PyNTyMXXCyljKidBabmdTg3VhLf68tgPDmzFYK8hDH+dV6HK4
	QodoQAGvgYtatqBg==
From: Fabiano Rosas <farosas@suse.de>
To: Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= <philmd@linaro.org>,
 qemu-devel@nongnu.org
Cc: =?utf-8?Q?Daniel_P_=2E_Berrang=C3=A9?= <berrange@redhat.com>, Paolo
 Bonzini
 <pbonzini@redhat.com>, Bernhard Beschow <shentey@gmail.com>, Thomas Huth
 <thuth@redhat.com>, Markus Armbruster <armbru@redhat.com>, Akihiko Odaki
 <akihiko.odaki@daynix.com>, Phil Dennis-Jordan <phil@philjordan.eu>,
 xen-devel@lists.xenproject.org, Laurent Vivier <lvivier@redhat.com>,
 Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= <philmd@linaro.org>
Subject: Re: [PATCH v2 0/2] tests/qtest: Make qtest_has_accel() generic
In-Reply-To: <20250130103728.536-1-philmd@linaro.org>
References: <20250130103728.536-1-philmd@linaro.org>
Date: Fri, 31 Jan 2025 09:37:11 -0300
Message-ID: <87cyg3gnwo.fsf@suse.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Rspamd-Queue-Id: 5EBB51F38F
X-Spam-Level: 
X-Spamd-Result: default: False [-4.50 / 50.00];
	BAYES_HAM(-2.99)[99.96%];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_DKIM_ALLOW(-0.20)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	RCVD_TLS_ALL(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MISSING_XM_UA(0.00)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[12];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_ENVRCPT(0.00)[gmail.com];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	TO_DN_SOME(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	FREEMAIL_CC(0.00)[redhat.com,gmail.com,daynix.com,philjordan.eu,lists.xenproject.org,linaro.org];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[linaro.org:email];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	DKIM_TRACE(0.00)[suse.de:+]
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Rspamd-Action: no action
X-Spam-Score: -4.50
X-Spam-Flag: NO

Philippe Mathieu-Daud=C3=A9 <philmd@linaro.org> writes:

> (Series fully reviewed)
>
> Since v1:
> - Use g_strconcat (Akihiko)
>
> In preparation of running QTests using HVF on Darwin,
> make qtest_has_accel() generic.
>
> Note, this also allow running other accelerators such
> Xen, WHPX, ...
>
> Philippe Mathieu-Daud=C3=A9 (2):
>   tests/qtest: Extract qtest_qom_has_concrete_type() helper
>   tests/qtest: Make qtest_has_accel() generic
>
>  tests/qtest/libqtest.c | 110 +++++++++++++++++++++++------------------
>  1 file changed, 61 insertions(+), 49 deletions(-)

Queued, thanks!


From xen-devel-bounces@lists.xenproject.org Fri Jan 31 14:44:54 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 31 Jan 2025 14:44:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879953.1290147 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdsG8-0000p7-KN; Fri, 31 Jan 2025 14:44:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879953.1290147; Fri, 31 Jan 2025 14:44:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdsG8-0000p0-FS; Fri, 31 Jan 2025 14:44:40 +0000
Received: by outflank-mailman (input) for mailman id 879953;
 Fri, 31 Jan 2025 14:44:39 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=a7eC=UX=gmail.com=oleksii.kurochko@srs-se1.protection.inumbo.net>)
 id 1tdsG7-0000op-Cs
 for xen-devel@lists.xenproject.org; Fri, 31 Jan 2025 14:44:39 +0000
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com
 [2a00:1450:4864:20::32c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e112cdea-dfe1-11ef-99a4-01e77a169b0f;
 Fri, 31 Jan 2025 15:44:35 +0100 (CET)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-4361f796586so24120885e9.3; 
 Fri, 31 Jan 2025 06:44:31 -0800 (PST)
Received: from [130.190.73.38] (wificampus-073038.grenet.fr. [130.190.73.38])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38c5c1b5a03sm4802060f8f.71.2025.01.31.06.44.29
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 31 Jan 2025 06:44:29 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e112cdea-dfe1-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1738334670; x=1738939470; darn=lists.xenproject.org;
        h=subject:from:cc:to:content-language:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=lCyOsl5i9oW6/jLPFFZPQrzigEMcJssDy0WWAdSun5k=;
        b=kU2YF69z5tnGkyDxjPV4vaei5boAkViiXTpchSytPnxJ6Jxx27YMDP2vSk1rBVc0jo
         8S0+1RP+WkIYtJUyDcB3WY1oY+gB8sPX3vzy1fM27GbNJzIC7zEoiHhRgBi8jzmitp99
         vwdoyjvF3mbbnh8IspWxyfBglJhFW0km8WhJXBft0dNRuuXBW3CpzzfW7y0b2CtxVxru
         t5KklaKQ6WyMvaouOdoMSO5jhrBlNkJ+/T7nR4K2bzfOk/dUsLRD1ueu7IZ0o0weKBvn
         au9nDnjoso7PVNvn8xUbXVqcK3VBykTT6txsWJ0rdTCeSJb+IZzaOz+ZQv/LJ7Zx5Rh4
         KmXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1738334670; x=1738939470;
        h=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=lCyOsl5i9oW6/jLPFFZPQrzigEMcJssDy0WWAdSun5k=;
        b=DHomlGsd4n9+pP/LtC7Y3PxXg2eBmDEqqACf0DIwh0rP+EgOfHs3jUbHZ5W+FGLD42
         BCUOhTd64e5k9CEBMsTJiwMWcVntwJMynTLw1RQTEbilVmgXKqQkbj33UDsCxJ1Wj0FL
         amJqb6uu9owEZ7AugzhfcnoJvMQT12deZh96Ag+qVZnh9I6NfLYwsRy2FjIog//BaXi6
         OhdmU9ipX9MJwSao/ST6w9RveABGYacwoGroPV4tx/rEg0rq3aZxuUsaLPI03J8n+862
         UJYPZbuKhSykZoZIsqGnwSxkBbyonjXAYWGX9N3KkWye9NZdvSVu2QHZQ/4Cp+/9MUXm
         Gk8g==
X-Forwarded-Encrypted: i=1; AJvYcCXMBCEjaXeuY/+Cg1Yq7UjHhLNHKJE76uIB0dNGP8/OA7wcyPcyNnTRrnDdCNkXha124LYXpcorZ5j31BA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwirL4UXuXWqLJI+MICuuOoSPbXBDabwPOELY1hAhIpR6XisYuU
	sEkeUxOYpkzWh2yOGmd2LUF49BHloG5NUk1SWR9FQItVvbBYAOFA/l+Ut2V4
X-Gm-Gg: ASbGnctrndErP+OTE6AVeluzQ5eOZd5Q9yUE68iIcHO6siKRYrHGC24zfC59AtlrmJ6
	01aS8RRADjXdkOk0N5/lEueSrE4xay+Wz+VDWQ22LGa9KbbUtystMb3PvaUQ6RZnGPL6RZIz6sE
	kM2+a9mV2uBCh6Pmqn/ob68bEB5CCdhlemaVMIfb7XRgDhFbODRGK3SVZ8ftiYBgCeGlc8EdC3Z
	CBGbAyvyzooeFjAVkhMBFY3C4viGRQPYxYEmkPlc4ML6L6fMJCSGnEPTlNXYC8UW3IEjjF4DByl
	Ib5oglI1FyaxmbePhVSpX3DbBcUBDEmBBoasOLmvzpWFN/Yyb1b2kZi9
X-Google-Smtp-Source: AGHT+IEnJaSDBPuMCaFspjL8x93hQ5t1uDZ7LNIKzexxAJ7Tt6bOBIYazAn6WZqOyydu7mhEKeKIdg==
X-Received: by 2002:a5d:6d86:0:b0:38b:e32a:109f with SMTP id ffacd0b85a97d-38c519504a4mr10565201f8f.12.1738334669763;
        Fri, 31 Jan 2025 06:44:29 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------UbUlkkAwyI5ShSe4dsue4nBa"
Message-ID: <93212889-7393-4fbb-9cc8-fb08f6ebeeab@gmail.com>
Date: Fri, 31 Jan 2025 15:44:28 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: xen-users@lists.xenproject.org, xen-announce@lists.xenproject.org,
 Community Manager <community.manager@xenproject.org>,
 committers@xenproject.org
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Subject: [ANNOUNCEMENT] Xen 4.20.0-rc3 is tagged

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

Hi all,

Xen 4.20 rc3 is tagged. You can check that out from xen.git:

git://xenbits.xen.org/xen.git 4.20.0-rc3

For your convenience there is also a tarball and the signature at:
https://downloads.xenproject.org/release/xen/4.20.0-rc3/xen-4.20.0-rc3.tar.gz

And the signature is at:
https://downloads.xenproject.org/release/xen/4.20.0-rc3/xen-4.20.0-rc3.tar.gz.sig

Please send bug reports and test reports to
xen-devel@lists.xenproject.org<mailto:xen-devel@lists.xenproject.org>.
When sending bug reports, please CC relevant maintainers and me
(oleskii.kurochko@gmail.com<mailto:oleskii.kurochko@gmail.com).

Thanks Andrew to do rc3 during Xen Winter Meetup!

Have a good weekends.

Best regards,
  Oleksii

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

<!DOCTYPE html>
<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <pre>Hi all,

Xen 4.20 rc3 is tagged. You can check that out from xen.git:

git://xenbits.xen.org/xen.git 4.20.0-rc3

For your convenience there is also a tarball and the signature at:
<a class="moz-txt-link-freetext" href="https://downloads.xenproject.org/release/xen/4.20.0-rc3/xen-4.20.0-rc3.tar.gz">https://downloads.xenproject.org/release/xen/4.20.0-rc3/xen-4.20.0-rc3.tar.gz</a>

And the signature is at:
<a class="moz-txt-link-freetext" href="https://downloads.xenproject.org/release/xen/4.20.0-rc3/xen-4.20.0-rc3.tar.gz.sig">https://downloads.xenproject.org/release/xen/4.20.0-rc3/xen-4.20.0-rc3.tar.gz.sig</a>

Please send bug reports and test reports to
<a class="moz-txt-link-abbreviated" href="mailto:xen-devel@lists.xenproject.org">xen-devel@lists.xenproject.org</a><a class="moz-txt-link-rfc2396E" href="mailto:xen-devel@lists.xenproject.org">&lt;mailto:xen-devel@lists.xenproject.org&gt;</a>.
When sending bug reports, please CC relevant maintainers and me
(<a class="moz-txt-link-abbreviated" href="mailto:oleskii.kurochko@gmail.com">oleskii.kurochko@gmail.com</a>&lt;<a class="moz-txt-link-freetext" href="mailto:oleskii.kurochko@gmail.com">mailto:oleskii.kurochko@gmail.com</a>).

Thanks Andrew to do rc3 during Xen Winter Meetup!

Have a good weekends.

Best regards,
 Oleksii

</pre>
  </body>
</html>

--------------UbUlkkAwyI5ShSe4dsue4nBa--


From xen-devel-bounces@lists.xenproject.org Fri Jan 31 18:46:52 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 31 Jan 2025 18:46:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879980.1290156 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdw2J-0003JP-Du; Fri, 31 Jan 2025 18:46:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879980.1290156; Fri, 31 Jan 2025 18:46:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdw2J-0003JI-Ad; Fri, 31 Jan 2025 18:46:39 +0000
Received: by outflank-mailman (input) for mailman id 879980;
 Fri, 31 Jan 2025 18:46:37 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=EkmC=UX=amd.com=Jason.Andryuk@srs-se1.protection.inumbo.net>)
 id 1tdw2H-0003Iw-Ho
 for xen-devel@lists.xenproject.org; Fri, 31 Jan 2025 18:46:37 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on2060f.outbound.protection.outlook.com
 [2a01:111:f403:2416::60f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b05af9e0-e003-11ef-99a4-01e77a169b0f;
 Fri, 31 Jan 2025 19:46:33 +0100 (CET)
Received: from MW4PR04CA0321.namprd04.prod.outlook.com (2603:10b6:303:82::26)
 by CH3PR12MB7570.namprd12.prod.outlook.com (2603:10b6:610:149::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8398.18; Fri, 31 Jan
 2025 18:46:27 +0000
Received: from SJ5PEPF000001F6.namprd05.prod.outlook.com
 (2603:10b6:303:82:cafe::31) by MW4PR04CA0321.outlook.office365.com
 (2603:10b6:303:82::26) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8398.21 via Frontend Transport; Fri,
 31 Jan 2025 18:46:27 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SJ5PEPF000001F6.mail.protection.outlook.com (10.167.242.74) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8398.14 via Frontend Transport; Fri, 31 Jan 2025 18:46:27 +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.39; Fri, 31 Jan
 2025 12:46:26 -0600
Received: from [192.168.195.178] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Fri, 31 Jan 2025 12:46:25 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: b05af9e0-e003-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=rL3du09rngXkUfki9OYOwX4p8LSgqJiquRLXnuk3oZNLXM4LdqPFzvTrm72yoCvbG0CR0vpaW465vtlP6eP+ww5G8J7DUBRNusXw2Jzjz7C4RPF8h94k2u8P0KxDRMgirrfhdeVVpnccfDoTu+MInLEdttllNWuri9pdNISL/acNcDCgYoWG6V1xNwZJqIRyr9bNWQWxREzxL6dGH3hFKwAi6AYcFA63FMcfBals1ipRqYRC5m/5LGRgT8BY0WIU6o2CSZUz5S2PK1EFC+xuu2p0RNCMAhfWk63rVULgx3PJXYnFb4Gs5RGg3t0t+92yyYORPsKtF4kVX2MlZpSYGQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=RS8pnDL1dA37YFpaS6K65r43e2EqQjnBbYBrBpOrdzI=;
 b=eRXqJpwPsJCY3oHH1ABGR6hi5isGqyzp7MJB6uZ2SQiIk3nJHjPe6Yd1YL1R5WM5sVoWj7XQKe+kAqSpMYCBYfTcHYw9DuJhrDOHs78j4i2s9p6h5CTYyGf4DxNlj0zFaQdZZPGe6P489ofekdTVElamB2CSPAVXruJ3L/KllyRLGQnMBU54Eq7zHxKlnOFkW5A+h38bIGWmj8BxNNlzvU+vZlh1ShEysbHqUBPtIlsGMVfW1k3c0oDPiGL5ZM0Yqg9JQCJt8pLfILGGp29m61SU3npuBxh/6gasIS4S0/sseot6Rnv+dqZH9C3AW9DilO+sGdZorq1vygYG3VcnsA==
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=RS8pnDL1dA37YFpaS6K65r43e2EqQjnBbYBrBpOrdzI=;
 b=YQ1gGRn8Jll0jTUGfOHYHZYoy2iygeRVB6rh4EsQIZm7/ZkDRxpEfJKEutqvF/JFQo0J9qXELkdVcbUyUzl9BhXWThPQo9m+MEayLA6KYsBM0h5/ce/jTLSs9yeu7OK1m+BkwHlBVsPZ0iFKJKQfMxqgsHLrX5MuSjYkhYOkQsw=
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: <34b2949b-5a3f-4659-a83a-f7e0dd4a9e0f@amd.com>
Date: Fri, 31 Jan 2025 13:46:25 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20? 1/3] AMD/IOMMU: drop stray MSI enabling
To: Jan Beulich <jbeulich@suse.com>, "xen-devel@lists.xenproject.org"
	<xen-devel@lists.xenproject.org>
CC: Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, Oleksii Kurochko
	<oleksii.kurochko@gmail.com>
References: <2bb9d3c4-0761-4d63-8193-29293e35eb04@suse.com>
 <ea0fea03-6002-4fc6-86ac-19598c9d9ef6@suse.com>
Content-Language: en-US
From: Jason Andryuk <jason.andryuk@amd.com>
In-Reply-To: <ea0fea03-6002-4fc6-86ac-19598c9d9ef6@suse.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB03.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001F6:EE_|CH3PR12MB7570:EE_
X-MS-Office365-Filtering-Correlation-Id: 427143ea-c8fd-4b38-2731-08dd422791e1
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|36860700013|1800799024|82310400026|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?ZWdhbi9LZE5kaFhBRWxGcFo2WCtSTmRuQ1BwVHgxd25GRDN5VUluaVJHUzJS?=
 =?utf-8?B?UE5zMFBjWVREZWM5blRpQXNTY3dkK2tzRkR4N0NPNWFtRDBpdENJOEJSdUYy?=
 =?utf-8?B?MGJSTkI5aHY1UjNKU2JOcnhsZTVLN01pMEVXWWZOWW16K2J3U1N6TFVCeER4?=
 =?utf-8?B?WkFvM290UmU5a0MrejJmNnZRb1kva21nZWhKejJEWnhDQ0JPRUVHZ3o2cHpq?=
 =?utf-8?B?d1NGUEFhK2N2VVhUZHEvd1R3dWJIM2JwdkEzN25HMWd2eXV5YmVqano5SGth?=
 =?utf-8?B?QnJaak5FM0doQ3VFUUQwcVZKUHVqcDlWakRiWFlpeDFJeE9HeU1BOFVzUWNP?=
 =?utf-8?B?TGhEeDJ0R3UzV0orSkZTemQyczFrTklLOHpwc0Jxd0dMeE1EMGRtd2o0QW5F?=
 =?utf-8?B?Um5XSUtSZkRCU2xqZUV3ODlJdGVHZzJyR3pwblVrQS9FYVRTSjdSNXcyR1Nt?=
 =?utf-8?B?cGZoaFo1U051SWRVeXowbE9LZGJ0NDZHL1RKQkQzc3ZQMWgzUHNlWjIxdlp2?=
 =?utf-8?B?d2gzZkVrNVlNdGg2SURoNnZpUS9pNFlvMnRZMHRLTjM1RjIvRDMvQzczSDg2?=
 =?utf-8?B?Z3VzcUFwYmczZG1pU1drSVFJM2hvUVFiTTVvNDgwcnJldmloNitDekk5RUxa?=
 =?utf-8?B?SitHM25kVUR0aFZHakY2d0hBSWc3VDNicWE1cnhHajFraEZLUHN5N0pTSDg5?=
 =?utf-8?B?RWhUUnZGTlh2ZVVTMmxCWEZIN3BHcGVINXA4Z0l0WHd5ZHYzYStjNkgrTm91?=
 =?utf-8?B?OHVDc1hHcUNhaU9JcmVJUlg3aDMxc3J5THR0WmpjR2xBVnRCeHpQTENjL1J6?=
 =?utf-8?B?ZjMwVUJtNTVqczVwczhtNmh0Qzd2T0VCY011Ry9sK01jQjExYzNZdXJ4a3FP?=
 =?utf-8?B?NWYvL0lWSVVEL1Nhd3dldUxKQUFpY0ZTZWw1bmd3U1NnSTJ4ZnFYbUJQRHEv?=
 =?utf-8?B?NHJOd2k2L3YwZi9oNk1RTWRtM0N0NXhrK1pNSTdDYzRoNnpSYU44RkZwZlhT?=
 =?utf-8?B?QWVwU1ZoWjdHMWJwM01OTzF6dlRLWWg5elBJbFFhd245TXU5VGM3NHZjUFlx?=
 =?utf-8?B?ZVNkVlpUY01iNUd0eWkvNS8vNWRkMFdXRS9qcE1WNFlTM1VMZ1U5QkszTkFh?=
 =?utf-8?B?TGxXeUFXR1J5akt0bm5mSGRQK3dHanlwTWNYMGJRV0N3VXRiSVJEU1gvd0Zq?=
 =?utf-8?B?UVUyQi9UL1lqR3ZrS3QzTEd5SjdhR2xsdzJzZGFISHRiUUhXS044U2phZFh4?=
 =?utf-8?B?STRLTnpvaHpsYlR6M3ZTa01ycVlsY3p0bkExUnpxWUdkVzVldk9pZHk1T2lR?=
 =?utf-8?B?Y0NCZUVHMVdPK3pYUC9RWVpiZko4dWtsa0Q2K3FsRVd1VEdNdjNjcFgvWk5S?=
 =?utf-8?B?dWc5TVZCY2tkK1hNaHN4V3pPclZVMnB5TEZCRGl6N2Y3aXNWWS9GcVVXOGpF?=
 =?utf-8?B?ZHZiTS9vbDZwTkFBSDhKWTdjbUZHT1BOeVArbTdpd0JwdGZTSmZvSUQ4bGxJ?=
 =?utf-8?B?V05CSFlGeFRIRklUelVOa3owVlhXdkFEUlljVE9XRDl5emd5TUFQbVpjVzBa?=
 =?utf-8?B?RGJSRGlsRUtWcW56eExIZ0pJUGdVaGNYa25idjdSNzdtcGFneEJhdnhwMFFx?=
 =?utf-8?B?OFcwUXhhWUxZb1NwQkswVWlacE9wWTFsbzI4V1RLUUkrSVErU21WV0xGY2ph?=
 =?utf-8?B?azZ5ai81dk9GZ2sycm91Nkh5SXd3NDY3V0w0OFg3N2tqc2pUYXEwSkQxSUw5?=
 =?utf-8?B?MDlKQlY4TXJzTnp5U1NzWTZPUndLSXgrVWVkYXM3TDZDZGhnTnZ3d0hTOWRx?=
 =?utf-8?B?RlhSWGxzM0ZiSFNiaU9IbjVjcHIxMWR5bG5nNGpCajZkUjRTV3ppclI2WUJo?=
 =?utf-8?B?REpQL0wzWXdlN3JvYlFyQ1pNbWcwR0tQWlNhOGxqVFhENHREUkhQQ0Z5VWFD?=
 =?utf-8?B?eU1kQXI1WmtyMnNabm9tV2E5NHBmUnpFUGFhMmNsd0s0U1N3b0xTM0hiWGcv?=
 =?utf-8?Q?MTNFxsrYu6LLVmWx0fWyhohd3RvU8o=3D?=
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:(13230040)(376014)(36860700013)(1800799024)(82310400026)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Jan 2025 18:46:27.3525
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 427143ea-c8fd-4b38-2731-08dd422791e1
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:
	SJ5PEPF000001F6.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB7570

On 2025-01-30 06:11, Jan Beulich wrote:
> While the 2nd of the commits referenced below should have moved the call
> to amd_iommu_msi_enable() instead of adding another one, the situation
> wasn't quite right even before: It can't have done any good to enable
> MSI when no IRQ was allocated for it, yet.
> 
> Fixes: 5f569f1ac50e ("AMD/IOMMU: allow enabling with IRQ not yet set up")
> Fixes: d9e49d1afe2e ("AMD/IOMMU: adjust setup of internal interrupt for x2APIC mode")
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Tested-by: Jason Andryuk <jason.andryuk@amd.com>

dom0=pvh on CPU *without* x2apic support.

Thanks,
Jason


From xen-devel-bounces@lists.xenproject.org Fri Jan 31 18:47:26 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 31 Jan 2025 18:47:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879986.1290166 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdw34-0003m0-LO; Fri, 31 Jan 2025 18:47:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879986.1290166; Fri, 31 Jan 2025 18:47:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdw34-0003lt-IJ; Fri, 31 Jan 2025 18:47:26 +0000
Received: by outflank-mailman (input) for mailman id 879986;
 Fri, 31 Jan 2025 18:47: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
 <SRS0=EkmC=UX=amd.com=Jason.Andryuk@srs-se1.protection.inumbo.net>)
 id 1tdw33-0003fO-1W
 for xen-devel@lists.xenproject.org; Fri, 31 Jan 2025 18:47:25 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20621.outbound.protection.outlook.com
 [2a01:111:f403:200a::621])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ce433335-e003-11ef-a0e6-8be0dac302b0;
 Fri, 31 Jan 2025 19:47:23 +0100 (CET)
Received: from PH0PR07CA0041.namprd07.prod.outlook.com (2603:10b6:510:e::16)
 by IA0PR12MB8647.namprd12.prod.outlook.com (2603:10b6:208:480::8) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8398.18; Fri, 31 Jan
 2025 18:47:17 +0000
Received: from CY4PEPF0000FCBF.namprd03.prod.outlook.com
 (2603:10b6:510:e:cafe::63) by PH0PR07CA0041.outlook.office365.com
 (2603:10b6:510:e::16) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8398.21 via Frontend Transport; Fri,
 31 Jan 2025 18:47:17 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CY4PEPF0000FCBF.mail.protection.outlook.com (10.167.242.101) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8398.14 via Frontend Transport; Fri, 31 Jan 2025 18:47:16 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 31 Jan
 2025 12:47:15 -0600
Received: from [192.168.195.178] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Fri, 31 Jan 2025 12:47:14 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: ce433335-e003-11ef-a0e6-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=DH/6HXrp8MZigRIBImkEq3boo9c1T14t9fsXIo5QVFvpX+E7MJvRdCPslXj5kdwbNFtmUj9VazMej46KqflLX4fdR9uigTBkfKPD/ECQiqJF6gkv7W90Y5ZC1G1XsFgPURC9EUquDXAsPn7G1cvs3oPTy2Li5PSlXdN3jUgblRdbWYVyB3H1iwC2WtC4dQNu05csANOsljsc8TPUjykidXqaI9lZQ0Onzc2rtaB+8q4vDMBteteUw9XlXmz485jzspSM55OlGrBrGydSWlCndscvT0nTDZzIjIUodH25ZXhuvvkSpPdgZ7Ymr571abfivhdf9lJ0CKApipGu39xeWA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=jTFrcf6uapok3OVJO2hb0V0lbMc6AmfUzcGf5bxoiRE=;
 b=THDNjRlqKvZyzqvkF/UZfeK3WgWBduWYSWb5bneJyYdOq33Hr8uqVHWl2RTpO62K/64fEZatwSqzW0L1sHK/217GIpQRHFK/kgaFH03sf62PCGwBVoO+iOVASJaSa7NvVwXje5AcGBTXxBSan3alaXPo3OwbRfy1Sbw6tZNeBiz/h81/ounsC0Tf37qCdTB15goI3/uG7cJ9FyyJjUifbbKWYB5zcy4uLHqJBdFVjmn0rofTwe90hvU2W4Bc3iD1E+N/iMhVKfLmVz3hwLWskdRuCdW/VV+bdDEO1XwTwTga4Z0LkfHGVSPYXSsZ/RPGjtgJSGMeJKbzDGzaJYmjnw==
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=jTFrcf6uapok3OVJO2hb0V0lbMc6AmfUzcGf5bxoiRE=;
 b=fIsYPAesCDUDGJQp0vAgP3svMPhp8ob1oAPovXLxvz5Cg3+LCKB+p0MUe/8KTBICziNdqGlx27SsT6jWOvFwPfdx8ia7SkKu5xvM+u1CnVGWEyxZcsMQV8/9JRnTZ9kfQtklXzB8no55zsnh8l0+4zWU7L8/5GgY1p2BXQljqMw=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <490192cd-958d-4592-b827-e1fff7b2067a@amd.com>
Date: Fri, 31 Jan 2025 13:47:14 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20 2/3] x86/PCI: init segments earlier
To: Jan Beulich <jbeulich@suse.com>, "xen-devel@lists.xenproject.org"
	<xen-devel@lists.xenproject.org>
CC: Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, Oleksii Kurochko
	<oleksii.kurochko@gmail.com>
References: <2bb9d3c4-0761-4d63-8193-29293e35eb04@suse.com>
 <940ccd1b-9ad8-4b68-a035-36f45326872b@suse.com>
Content-Language: en-US
From: Jason Andryuk <jason.andryuk@amd.com>
In-Reply-To: <940ccd1b-9ad8-4b68-a035-36f45326872b@suse.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB04.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000FCBF:EE_|IA0PR12MB8647:EE_
X-MS-Office365-Filtering-Correlation-Id: 8e8cb90d-ecc8-4a8d-52b8-08dd4227af56
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|82310400026|1800799024|376014|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?YVBpR0NGZURxQ2ozeU1XZis1UWozL2tMcjBqSVNVdjh3aXZ2cHhzcUc2SlV6?=
 =?utf-8?B?L3NxSUtNeFNRY09iVjA3WWtBVDVUbzhwNkswSHY1Q3FVWkFMY05mdnV3bklR?=
 =?utf-8?B?OHBER25aM3RIamR2Qy9TcnFPeFN6dTJyZUg4QVcrTklxNEdvVnlNajZIa2JC?=
 =?utf-8?B?NHN4ME9PS0c3dWNWSU5yMWJRZWFOcUIzTFUwOUdWVW9UWHVxQ0lyZG5EVVA0?=
 =?utf-8?B?T2ZSSE5QVm1VWVdick02dmh1eDR0N1R4NXNWQ2t3eG83RkFKRmJlVC9hYlJC?=
 =?utf-8?B?WHpFaFFGdDY5eWNxd0FvYUpyT01aN0x2OWNyVU91UVZjdDltbmM5c1lzbDE0?=
 =?utf-8?B?L3d2TjVWa3RseE5qSlpvL1B1YWRBWXlrY3I4U3BodkUyZmtxK2VMYnpOWktD?=
 =?utf-8?B?Y1lyMGxMR2NhMm0veUxTcHlHZGZ3ekVoTUxTd2Eya0JOTS9Hbk5XYUE5NFRr?=
 =?utf-8?B?c2UrTGkxUTRTbEMySU9INGxkQkNkSWhjbldGN3NFeEdHUWsyVWpQOTZBVmQ1?=
 =?utf-8?B?NU5Da0VablR0OS8vaXBMWTkxMlp3ek54b2VLL3E3NTltcHM3c24vNElaOVU1?=
 =?utf-8?B?UUdqWHlZR0xBWjFCYkVVVGVBUC9DSlIyYmpFQkMzbW1JamZ2SVViYzlub3p0?=
 =?utf-8?B?ZmJia1dxN2hSbjJxa1FHVCtHeEpCMDlOT25iOXRCRFo3Zy9EcXhMYVFleWph?=
 =?utf-8?B?cnQ3K1NsMEVXTlcvbHFYSExxV3BkV0pFWkRWNUNxM2NlVWFwOFZpcTlVSmhw?=
 =?utf-8?B?Qk55S1h0a0g4VmttZUF4R3FXb08xeHNtTGZiRTZua1hhNkxoYlVvRkI3UEpj?=
 =?utf-8?B?SnJvUExhYVo2SUVDdDBYS2VhSU9KcFFWeGQ3aWVlNlZubVJXNzlqWFFKQWRu?=
 =?utf-8?B?a2dGcDc2QnUvWkJwQjBkUXU4eHQxblp4eE4vOWl2Z1kwMXRYUWdYeFdhN2h5?=
 =?utf-8?B?UnVPWjZQVkU4YktVSVJmVk9IVHROOGJmc2NQU0MwVXUzeXBxZGd0RFYxcDRC?=
 =?utf-8?B?dnRqVXU2WmJuT1JTMitJMlRPNndNRDJtck9zb2VsUWR1N1M4M1crWklxZ3JW?=
 =?utf-8?B?bkpOWnMyUkRKUzhPRWZqTzR3THZ6T1hsVXlFcUZ0R0E1UnR6b0Jub0wvREJU?=
 =?utf-8?B?NmlHUVV2VmpYOUhRTXN1UjUyRkdCNVFkTndRVWg5eWpEMnVNWWwwSFo5bW9t?=
 =?utf-8?B?TjZweFUyaTNPSGkzVnBsK2ZpYXRWeGtDaWNzYXFLVjc0aFFVMTZnK0JEZWFI?=
 =?utf-8?B?cFNQSWZxMUtmamJlMUU0SkRrUjRuUDlhMTQ1S1NYejFHZlpUZzQ4NU5WT3BH?=
 =?utf-8?B?T1lOZEpxWExkSTJUeFp4alNxZngyMk9UcElvb1BBN2VsQUh0UTZqQSt1eWhw?=
 =?utf-8?B?V29SbTBZdmJQeWd3ZXhLbEpMRkRCNDlWUklsNXpZMisxbGlpU1hrR0REU1Nl?=
 =?utf-8?B?bmVpdzFXZzZkaUFEU3RyZ2ZneVd3TG9EYXlDbHJUc0l5aDB2RDN4bzRyaEFM?=
 =?utf-8?B?WjdmdEt4dWNnUm5lZGh4eGNrN0VTUlBRTHR1bjhPUEI4aVlGVWsrS3B5TnFz?=
 =?utf-8?B?em5TRE5mblZQZDNkaFdsdlV2dVkvV3JlN3NqbVZYYXk1M25JeXhTZU82QjR6?=
 =?utf-8?B?aVJUcUR3bEpCUzNvdnJ3clJOY05md2RCR2hZellBd2c1bDBGVnp4RXhwRmNB?=
 =?utf-8?B?NFF0a2Jva0N4SnY5dEE5MzRpS1ZIbVlvdjlKU2xMTzZwaCtjb0RvUk1NVm1V?=
 =?utf-8?B?ZThudXlCMG9ZMkVKMlNVTTlQT0g0UDI1TkgrMWovYmUzRVVUbHVzT0FMZEx0?=
 =?utf-8?B?NldwWGY2TlFhVEw5RFlEK0pCd0dZemJQSHA0aUNDazM5dVpwY21nQkNIa2lp?=
 =?utf-8?B?alZCOGVFQzNmQUFKZE83ZklKaloydjluOUJUU2NKTFllUEIzZEp3S2x0d0pV?=
 =?utf-8?B?OW5YRkZ4V2QrcEZ3T1VqZGNGVWM0bzFySnQ0ZnRCSXV1am0wbzhtVnA1N1FB?=
 =?utf-8?Q?29qZIBPn0SbODFWsPJozn5EIHhPghQ=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(82310400026)(1800799024)(376014)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Jan 2025 18:47:16.7587
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 8e8cb90d-ecc8-4a8d-52b8-08dd4227af56
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CY4PEPF0000FCBF.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB8647

On 2025-01-30 06:12, Jan Beulich wrote:
> In order for amd_iommu_detect_one_acpi()'s call to pci_ro_device() to
> have permanent effect, pci_segments_init() needs to be called ahead of
> making it there. Without this we're losing segment 0's r/o map, and thus
> we're losing write-protection of the PCI devices representing IOMMUs.
> Which in turn means that half-way recent Linux Dom0 will, as it boots,
> turn off MSI on these devices, thus preventing any IOMMU events (faults
> in particular) from being reported on pre-x2APIC hardware.
> 
> As the acpi_iommu_init() invocation was moved ahead of
> acpi_mmcfg_init()'s by the offending commit, move the call to
> pci_segments_init() accordingly.
> 
> Fixes: 3950f2485bbc ("x86/x2APIC: defer probe until after IOMMU ACPI table parsing")
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Tested-by: Jason Andryuk <jason.andryuk@amd.com>

Thanks,
Jason


From xen-devel-bounces@lists.xenproject.org Fri Jan 31 18:47:56 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 31 Jan 2025 18:47:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.879991.1290176 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdw3W-0004EX-Uf; Fri, 31 Jan 2025 18:47:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 879991.1290176; Fri, 31 Jan 2025 18:47:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdw3W-0004EQ-R8; Fri, 31 Jan 2025 18:47:54 +0000
Received: by outflank-mailman (input) for mailman id 879991;
 Fri, 31 Jan 2025 18:47:53 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=EkmC=UX=amd.com=Jason.Andryuk@srs-se1.protection.inumbo.net>)
 id 1tdw3V-0003fO-UA
 for xen-devel@lists.xenproject.org; Fri, 31 Jan 2025 18:47:53 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on2060d.outbound.protection.outlook.com
 [2a01:111:f403:2414::60d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e03c3859-e003-11ef-a0e6-8be0dac302b0;
 Fri, 31 Jan 2025 19:47:53 +0100 (CET)
Received: from PH8PR22CA0007.namprd22.prod.outlook.com (2603:10b6:510:2d1::12)
 by CH3PR12MB7571.namprd12.prod.outlook.com (2603:10b6:610:147::9)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8398.18; Fri, 31 Jan
 2025 18:47:50 +0000
Received: from CY4PEPF0000FCC5.namprd03.prod.outlook.com
 (2603:10b6:510:2d1:cafe::17) by PH8PR22CA0007.outlook.office365.com
 (2603:10b6:510:2d1::12) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8398.20 via Frontend Transport; Fri,
 31 Jan 2025 18:47:49 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CY4PEPF0000FCC5.mail.protection.outlook.com (10.167.242.107) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8398.14 via Frontend Transport; Fri, 31 Jan 2025 18:47:49 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 31 Jan
 2025 12:47:48 -0600
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 31 Jan
 2025 12:47:48 -0600
Received: from [192.168.195.178] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Fri, 31 Jan 2025 12:47:47 -0600
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: e03c3859-e003-11ef-a0e6-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=CkOTi/NZAqsfqVZ/cTvJNmkaFHLjyLECLN6nPrO/z66+LTclOHT91/KESy+oYr05iv+zhqK2kT5Z1yxohLi/+JEoStpNCYDK0W0ej03S763XV5GfsEoPKQHJY/Sh/JOlwefXnEOchXhHiBH10JzajYAjEijnALmN14m0MEcBOdeJYRO++8xOFNl6we5kcaWoB6VZ9ZT0nY9sUZC1ngPcTaZfVqzeryVRWD6WNaLUUiGnTR09SiN1jzJX0gysgyA+YEZ6XL6MsMxOo2eSsdFh9E4gWlT/Oh0sIVyG499SSDsoxgq6s2EDUUZ82jnCs7c84NYsgY0VlhS4HWZvAKvs3w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 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=vdW9BHmbZIuzIXj8SzYB/3tDcdqiTyB1q2jcwLykmxU=;
 b=A5wL/BJc3jNUkkhc8SZQ/92r5nEJJ8XP2cP+rtXxq5uIAAZylKKHHBEUZEG56csAL+GixHhGKJmayzJA7jqEcysAD2nBtUnlD4TVPtldX3gHcvLSSsyPd0YAy/QqiV6COvfCz7Rf6LBxDbDc5yKuWtSbaRBaaqzEzpsf1dDmbTw3oYJ4XLojGw4TClR2yx8blDpcKf0cBMPa+HpYCoFiO4neivbYms4wOPV8WCDRZK+gVmWGCjO2MX+ZCoPt8oIc1Xmg63Tx8eu2dKMNVawZ7Kr1zwh1wjpWsoHgEjOPsYgNiD1Vs389KXv9CBvnBbImNSvYj5zzh1IOclSJNm0IpQ==
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=vdW9BHmbZIuzIXj8SzYB/3tDcdqiTyB1q2jcwLykmxU=;
 b=bPteVIqNe3MGtg10eCwfXVtQ3dVO3TTiHwgUt5dFrRWLlG1Sc/rFu3uhOcsIyQ31Nv5aDiWpK2yw7NqwJzZ4FD10/vUEiX7XjXvfGCh0dFGz095L4ebNgeGWjno8fnMRWD0IPtgf4aOj/TLyPPeVrDLeVFU0zMRathOgpu/A/Jk=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <9cc2c848-583b-4c08-a886-ffe3c7ca09c1@amd.com>
Date: Fri, 31 Jan 2025 13:47:41 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20? 3/3] AMD/IOMMU: log IVHD contents
To: Jan Beulich <jbeulich@suse.com>, "xen-devel@lists.xenproject.org"
	<xen-devel@lists.xenproject.org>
CC: Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, Oleksii Kurochko
	<oleksii.kurochko@gmail.com>
References: <2bb9d3c4-0761-4d63-8193-29293e35eb04@suse.com>
 <b0b8c35f-5c88-46bb-a882-9ff737683367@suse.com>
Content-Language: en-US
From: Jason Andryuk <jason.andryuk@amd.com>
In-Reply-To: <b0b8c35f-5c88-46bb-a882-9ff737683367@suse.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB05.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000FCC5:EE_|CH3PR12MB7571:EE_
X-MS-Office365-Filtering-Correlation-Id: cd17cb9f-da9e-40e3-4b8c-08dd4227c2af
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|82310400026|36860700013|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?SDlsMldHWk5DS3l2TjEvN1dSak5oQUJVTzZqc0pFYk0vS1M3d2x5cTdjNmsv?=
 =?utf-8?B?aWJnVWxlSGFVWmVKbEUxK1YydWRkMVFhZVZQRXNVeVo4WkRLam5ZRVRUdXRS?=
 =?utf-8?B?YXNIcHIyMnRpeFFvVmlDUVovZ2xVQklOYjNHQytyQlM0eEk0VEpxS1RQRUVn?=
 =?utf-8?B?M0pVVHRBcDJkbUR5cTFxazZNM29jTGlwcGdZNVMvWEh5WTNaL0lmNkxFbUln?=
 =?utf-8?B?bG85NXBNcmc4cno3MTJKdklYWnhMTEdCK0hZdVJxYlROem5SNHB5NEpFRHhL?=
 =?utf-8?B?TXIxbW9NNzFIY2U5ck84NjcvdjNSbDlwWHVxRDlHVVNnVUNVaFVLTW5lazYx?=
 =?utf-8?B?RW9HWVQ5RXZZVFM5YmxTVFoxVFFOOG51WW5GQWg3OGcraVRPYnZ4N1ord0ZQ?=
 =?utf-8?B?WEdKWWMwOUQzVGd2SDQzOGlWZzFvVHF6M1ZJWkpNdC9rc2syamVMUE5iaERJ?=
 =?utf-8?B?ZW1rTVBxK21YeHN4QXNmWnE3WndhdzRyNGpaVW43MzlsVW13d0VqSTlOb2Vt?=
 =?utf-8?B?aGNtRDdHZTJaaFRUWG01TDcwZTZqUk5qZXp0bjJMS0xNWVB1ZU9BVm9HMXN2?=
 =?utf-8?B?amljYWFqQ0FLcTh4d3JaK2FaTGpKL2R3d1ZBdFo0S2FCQUNSR3RUSG5MZXNE?=
 =?utf-8?B?N0ZRVmJkMmVac1BpbXpvN3RqQ2hFa1F6bEFJOVJGbm5nRWxGbGVTL0hxRUdO?=
 =?utf-8?B?WVM1RTBoMldFc2NzQVA5cHl4aWcyM3VNVStFZ1dVbmhzUWpqb0NoVEprSDhy?=
 =?utf-8?B?R3p4U2xCdE5udHk3Y2Y0SitWOHl2ZDJ6TmoxM3NuWHN2SFkzcVMrVlpiK2dC?=
 =?utf-8?B?ZWpLcXlFMGtwamtycVNCSDdiaHh2T3BSUVY2c0FlZm5jZERKSHRGeXBEYVUw?=
 =?utf-8?B?WFJibVh3Rkt0WFR5dHZuWVlJc1ZRajBRZk9DUyt3a2pOTGx6ZEtLVEs0bWx6?=
 =?utf-8?B?S0cxSzlITzdJRUg2a2hOVVNyWmFrSG8wYWwvcTZjalpXVkszNEZVbmxmT2hH?=
 =?utf-8?B?ODgwSnpxekxPTmR4aUE2SzcyelhyRTFYNTNzUlFEdjJrbEtzRkZ6Rmw3UE5Q?=
 =?utf-8?B?KzBpeCtnK3FNdHE4WGI4OWFSSlRvSnZBOHN3M3V3NmRjTnNGTjVyMDF6cDhY?=
 =?utf-8?B?NDdTN3ZSRVVsb25KVzh5L3haOFhkZE5vODhKaWxJR2ZLanpxVFI2YVlXZlhU?=
 =?utf-8?B?LzVEenI3RkdYTzNtbUpmcVRqQjJEd2hJSTYxenFJdGp2SENSOXZSZEpsbTI2?=
 =?utf-8?B?VjE0b3J3UUFhbFZyVUFXOEVTazhSd0ttVmxpRmI4WDJQQ0RDcDBLamVoV0ll?=
 =?utf-8?B?eGdnYXNKLzVMNU9wUUUrRmtIS2RwT1FXbUlSQnEzeE5OR2ZMbGs4V0xzL0RK?=
 =?utf-8?B?R3pMY3lHUW90bGpRVEVwUk9jbzQ3eHpOY1h1eUdKNjQwaHUrbk5sTzQrcjB6?=
 =?utf-8?B?Vkl4ZHVsRlZ2Z0hiUWpFelpQYkFLdEVDUW9LSzQ1VTByeHYxNjB1WjlzVUk5?=
 =?utf-8?B?VDcvYm8zZmRIVlVFMXRGbTg2QjFLb29adFlycTA1RDBsT0JJMkVWcTBaMG5w?=
 =?utf-8?B?dGJtYm5LdjUwaHNMamd4UWhNYmMrOFpLSUY1S1ovYmU2ZW9nY0tTZlBhRnpS?=
 =?utf-8?B?bHlSS3lzZFFZSjNRdDZtcnk1QWYwc0pmT3loSGU2TXNteUNWTlpKQllOVitv?=
 =?utf-8?B?RlZONUJLSDZmTHJpNW1PUzhsT0NJaFQvbENTcjVZaEtTVklsZXBYY1JKeDE3?=
 =?utf-8?B?MmFTdk95N21HK0ZZWDJLSXdKb3g2K0ZkWitHY05Lek1lcFRFN2txb2ptT2tN?=
 =?utf-8?B?R0Z6ZElET2tVcjB1M3ZNMUQ3NnNOckZ4NkpNOW9SaUl6Wng0ZXhneTZIaTVm?=
 =?utf-8?B?UGlLNk1tY01lZDlyYU5NclZlWnJSSm9NVEd6dDRtMW1mb1dENVlndkErbnQv?=
 =?utf-8?B?QVA1dkFYVTRreGVvVUQydVdGcXU5akdzWW5rekxQeU15YzB1V01xUVZzU2R1?=
 =?utf-8?Q?/4xD56P6rJihNYcXas8J2Fw7/VU4G8=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(376014)(82310400026)(36860700013)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Jan 2025 18:47:49.2185
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: cd17cb9f-da9e-40e3-4b8c-08dd4227c2af
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CY4PEPF0000FCC5.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB7571

On 2025-01-30 06:13, Jan Beulich wrote:
> Despite all the verbosity with "iommu=debug", information on the IOMMUs
> themselves was missing.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Tested-by: Jason Andryuk <jason.andryuk@amd.com>

Thanks,
Jason


From xen-devel-bounces@lists.xenproject.org Fri Jan 31 21:24:44 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 31 Jan 2025 21:24:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.880012.1290186 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdyV5-0005Zx-Tq; Fri, 31 Jan 2025 21:24:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 880012.1290186; Fri, 31 Jan 2025 21:24:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1tdyV5-0005Zq-Pu; Fri, 31 Jan 2025 21:24:31 +0000
Received: by outflank-mailman (input) for mailman id 880012;
 Fri, 31 Jan 2025 21:24:30 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <SRS0=lLw4=UX=aepfle.de=olaf@srs-se1.protection.inumbo.net>)
 id 1tdyV3-0005Ze-UY
 for xen-devel@lists.xenproject.org; Fri, 31 Jan 2025 21:24:30 +0000
Received: from mo4-p01-ob.smtp.rzone.de (mo4-p01-ob.smtp.rzone.de
 [81.169.146.166]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bedbc2eb-e019-11ef-99a4-01e77a169b0f;
 Fri, 31 Jan 2025 22:24:25 +0100 (CET)
Received: from sender by smtp.strato.de (RZmta 51.2.17 AUTH)
 with ESMTPSA id D0534410VLOHAOw
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits))
 (Client did not present a certificate);
 Fri, 31 Jan 2025 22:24:17 +0100 (CET)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: bedbc2eb-e019-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; t=1738358657; cv=none;
    d=strato.com; s=strato-dkim-0002;
    b=lfphfiXeuy0k/s97y0djYuxDTau+R/kiKz+T/uVqh5mKKkZIwUIX21RaeL9BVAq07b
    d/GSdRND0AtbZCY2pSBDEiqfe20pBatTVRQEia2AW0qGB7iAXqZu5bzG7HadfLYZ677+
    BVHtjkhAZja5zLIMmtbflJMPJfXCfAj0Akucqe3+RjF6osDHOp2wXAyWZErJ+1OrYVMI
    vaysNVBe2rZTtF97jezi5aGcKD3CjCcNkZZh3md9C/qtnziKWavKRxG1Wnb1ex1j569j
    1L0Qgo7tVlQml92/vYHzg7pjE3tidTn5Zyfjo0QkfIYKFsCqH5ASoiMMRmuefx6IuLfz
    6ypw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1738358657;
    s=strato-dkim-0002; d=strato.com;
    h=References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date:Cc:Date:
    From:Subject:Sender;
    bh=eAzSJqEFrsaXJMf7ew9eXFDvspe9PnDh9NWZ6ZjZidc=;
    b=UaUj//LZQrE3as9Ldk8CqG4m0h/rpMYomJ92g5X0BPLpKX9itJoK3ot8/mwd8nVBup
    n3KGxNqQ8P67AsOASpANR6z4Go6NccDNbXE+qvVt8hafkkBgB4mN9P0sPLKLqCRzh1/+
    Kb4TEknvVeTI34Idk3oWq/E5tfy3MGDSRo8jE1jdqRUKfwIQq6dmMkutQtwdOAsSC0Pj
    P4iDM4VinOp277INUOOv75d8vrlP8V4xnHNN81TjVcM8ZW8JwrZy/CkopscCRENdDgh+
    6n68/+H7MFPOSMVw+owAYNQpyOgfK6+qg9NtsnM0aZ0TeZf2EPlVcrhxt5sDq7fUZhqZ
    Cfng==
ARC-Authentication-Results: i=1; strato.com;
    arc=none;
    dkim=none
X-RZG-CLASS-ID: mo01
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1738358657;
    s=strato-dkim-0002; d=aepfle.de;
    h=References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date:Cc:Date:
    From:Subject:Sender;
    bh=eAzSJqEFrsaXJMf7ew9eXFDvspe9PnDh9NWZ6ZjZidc=;
    b=mokYCtLz2mt4/GXCUCxgAS4YJ4FNk7GRnjGWHyjW3WpFch5yzMPYMcBver6AzrVY8W
    mZK8Cmsy0KboLeBWYRdlyKEOT98/DmZ3ekjz4jZwY1S/z8YXjFAzblbMFColjKfX+lq6
    zBZxRrvGHOYKecqJgLFVLi2l1zL00x2+6gp2qLvwy00SFSo+89G8YXW+uPNg/bfT3prr
    I10+suPyWIe2zcBKxFz9Rmf3W0X1LoOrGq+DhNVMNy2Mz9aiIrT2ux4/ys5dgxcnGoxE
    ns/LkJ4xR2U/e/vHNn9XsWZDVC9HlA1Cv6UkC0r/nTWk01Fqkb/LbzK/OtW620h6xM2u
    11mA==
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1738358657;
    s=strato-dkim-0003; d=aepfle.de;
    h=References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date:Cc:Date:
    From:Subject:Sender;
    bh=eAzSJqEFrsaXJMf7ew9eXFDvspe9PnDh9NWZ6ZjZidc=;
    b=7a7mNv5H5TiwFgmVCgErzrH2ni1u40nI3yMAvvZIEcAC4d3l7HaGfZ+jdYlm63KLGw
    z8JKMIbap3oiqO3IZIDg==
X-RZG-AUTH: ":P2EQZWCpfu+qG7CngxMFH1J+3q8wa/QLpd5ylWvMDX3y/OmD4uXd0fmxSoJ8/RK6b07KGriu4yBf+6JptMSdiuOzXC/d"
Date: Fri, 31 Jan 2025 22:24:10 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: "Edgar E. Iglesias" <edgar.iglesias@amd.com>,
 xen-devel@lists.xenproject.org, jgross@suse.com, Anthony PERARD
 <anthony@xenproject.org>, Paul Durrant <paul@xen.org>, jbeulich@suse.com,
 andrew.cooper3@citrix.com, roger.pau@citrix.com
Subject: Re: slow start of Pod HVM domU with qemu 9.1
Message-ID: <20250131222410.2472f04a.olaf@aepfle.de>
In-Reply-To: <alpine.DEB.2.22.394.2501301014400.11632@ubuntu-linux-20-04-desktop>
References: <20250128151544.26fc827d.olaf@aepfle.de>
	<Z5j-bkdFZ7riavv7@zapote>
	<alpine.DEB.2.22.394.2501281543580.3264561@ubuntu-linux-20-04-desktop>
	<Z5oIvUINVDfrrVla@zapote>
	<alpine.DEB.2.22.394.2501291429040.11632@ubuntu-linux-20-04-desktop>
	<alpine.DEB.2.22.394.2501301014400.11632@ubuntu-linux-20-04-desktop>
X-Mailer: Claws Mail (olh) 20240408T134401.7adfa8f7 hat ein Softwareproblem, kann man nichts machen.
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="Sig_/q/z7tz6BsSY.gMaQe05PQEW";
 protocol="application/pgp-signature"; micalg=pgp-sha256
Content-Transfer-Encoding: 7bit

--Sig_/q/z7tz6BsSY.gMaQe05PQEW
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Thu, 30 Jan 2025 10:14:44 -0800 (PST) Stefano Stabellini <sstabellini@kerne=
l.org>:

> xen: no need to flush the mapcache for grants

This change may need a Fixes: tag for 9ecdd4bf08df.


Olaf

--Sig_/q/z7tz6BsSY.gMaQe05PQEW
Content-Type: application/pgp-signature
Content-Description: Digitale Signatur von OpenPGP

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

iQIzBAEBCAAdFiEE97o7Um30LT3B+5b/86SN7mm1DoAFAmedP3oACgkQ86SN7mm1
DoATkw//bBX4uT+wnWPsyITMazSWi6fBTI/fWmlyfAkEnBmRV/37rcOSKnEp0+8C
7bjXRJtrYr+ivMKn5ZVUNyRSoT8BSSa4gOU2Gjf8IqHwVur1C0whVc017LGvBdSB
02sz3P+KgdEHipi4VfYJgNNaTG9KrMSVQ8E1ZQePYdUOn/dKfpnbNIpIbRuzmLiY
l4fFj5vMjm2kGXRRQC0wwXkJZ8JNHOkhsVbiaSIO/nwh/COHjNWVNKjEo67XXsya
4OrbBEzzE0X7v2HRbINmlLBuimRt8kMQvFBf1dZwkuGMT9HfDs9Oowm8J/vsj6h/
8B+T2tlrQrKDp39iT7LbJGzD4mwre9P9jeh54P/68QUWlCd/Um/4MTAYrLUXCTJt
TZIqV8z2ThQIsX9dULZqJysTmRAB0qOYIc3jjzs3znFsWLTQnaWgX5yFja2piOa4
bQUDRhhD+SGTDSIiOh0NcvAeT+QPASl7maBAKjAvd7V31O5aeOmsSseXxiCUBKze
6WNBH/1y38+qxcYAIiFgYrnM9ZAF61VAAZigLsukZgmXuFg0LMYZr2q1zyo/7G+a
fv0RBxHaeH+u/5Cg1hg3c+Bz0xpFmmj1izB7qLFM2wIbk0P7U7S9AuavUuqZ9hv+
2ph9UHptal/WiDz6zuIOf/281YgWURbAZjifakJHkhkwzci5rtY=
=qRyL
-----END PGP SIGNATURE-----

--Sig_/q/z7tz6BsSY.gMaQe05PQEW--


From xen-devel-bounces@lists.xenproject.org Fri Jan 31 23:37:36 2025
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 31 Jan 2025 23:37:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.880035.1290195 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1te0Zc-00032g-QW; Fri, 31 Jan 2025 23:37:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 880035.1290195; Fri, 31 Jan 2025 23:37:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1te0Zc-00032Z-O2; Fri, 31 Jan 2025 23:37:20 +0000
Received: by outflank-mailman (input) for mailman id 880035;
 Fri, 31 Jan 2025 23:37:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=HyPN=UX=tklengyel.com=tamas@srs-se1.protection.inumbo.net>)
 id 1te0Zb-00032T-Nc
 for xen-devel@lists.xenproject.org; Fri, 31 Jan 2025 23:37:19 +0000
Received: from sender4-op-o12.zoho.com (sender4-op-o12.zoho.com
 [136.143.188.12]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4cf2c0a0-e02c-11ef-99a4-01e77a169b0f;
 Sat, 01 Feb 2025 00:37:16 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1738366630199446.59530756690776;
 Fri, 31 Jan 2025 15:37:10 -0800 (PST)
Received: by mail-yb1-f176.google.com with SMTP id
 3f1490d57ef6-e58a90c6059so4418384276.1
 for <xen-devel@lists.xenproject.org>; Fri, 31 Jan 2025 15:37:10 -0800 (PST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
X-Inumbo-ID: 4cf2c0a0-e02c-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; t=1738366633; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=n6SDlibQEZsUdYsWGSRsGCSug8Dh6DzgidXfvQ66BlKkd8CRBEKx3dLUHTYSOkzmu6AivD1je6RWMvBfEb+ZcgnABaPatO898VFcSbznx93RB/WMs6jrz1HjOzG+x2iXbfqGdet+7KYrwVeirEIkld89jolm8LkXp4dSaIFf1Nk=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1738366633; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=/F1F7S9JW3z+rec15MLaBGQV6OMlNjewyhuLpVQbeVM=; 
	b=lL+VTb5jwOEXT4usodH7rX4nEZ+o+C+c2w0gbSR6fGRLb5fOZNNeV1eMr+TDbUW6XtRi0XxvQMWKEt1fw4IkT3KTZBdV+SP/Bwu+0KWKXulXYf44sMzqwqAX/osGoX5V2iB+2s6RxCDIXCce7hXtNOGfl/sqVp66NDDKtEpDjW0=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=tklengyel.com;
	spf=pass  smtp.mailfrom=tamas@tklengyel.com;
	dmarc=pass header.from=<tamas@tklengyel.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1738366633;
	s=zmail; d=tklengyel.com; i=tamas@tklengyel.com;
	h=MIME-Version:References:In-Reply-To:From:From:Date:Date:Message-ID:Subject:Subject:To:To:Cc:Cc:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=/F1F7S9JW3z+rec15MLaBGQV6OMlNjewyhuLpVQbeVM=;
	b=iOdzAhKPOQEXvx3/3jHLK1fBwjx94oo64w8OCm0HaMx41QsyRbJ7yVK5X+JKa7Jx
	URcpqIslaJaRDDc9QA/KgLs4tre13B5TYxpOVzXGCqLc8xyx7y9SjNV/JxwIQ5I/OaP
	Qx7L5YEAH+bO+PmBVPaDHi9JggiBxk3gCmO55XE0=
X-Forwarded-Encrypted: i=1; AJvYcCX4xv4JtWLkDOaowI0EX+Jqmbt9+ZuTcpecYmzutpE7QoY5hNH0I9qQ0IfVRU5YWyApJxeHbDA7iCI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzIeD9xh6sTv0sF0e96ptXs8QgtkJCNRjdsIvQFLboAAoddiTZS
	dvmLG/a8/yHl9JJbLyp4zcD6tJw79CsSBlvpJ5e9wqCQFCilMe7rwII0pvxGKE49jTpXttuyJZx
	RUOn16R1bsMuNIMWnSMjD00Ehz60=
X-Google-Smtp-Source: AGHT+IEgWmwUuJOM8vimqGVJ6KGYtJ2xn9+Zofc643JIAkDgbaH8coTHWRn04BPMS95MfPEpr9CGpEvLtM9Dk7o+BAM=
X-Received: by 2002:a25:b006:0:b0:e5a:cc48:847d with SMTP id
 3f1490d57ef6-e5acc4884d8mr6030063276.20.1738366629403; Fri, 31 Jan 2025
 15:37:09 -0800 (PST)
MIME-Version: 1.0
References: <cover.1737452864.git.Sergiy_Kibrik@epam.com> <ff22f35dafd04b16165e1caec038e5a5fcf2aeee.1737452864.git.Sergiy_Kibrik@epam.com>
 <c74d334e-6e33-4a58-bf94-936249244cb0@suse.com> <CABfawhm8Cb3xz8Fv=YhA1TSKtvA3ThWHMcqJCFDarwSuYKQ5ZA@mail.gmail.com>
 <b850c2b1-5aa9-4e64-9161-ba55028b43a7@suse.com>
In-Reply-To: <b850c2b1-5aa9-4e64-9161-ba55028b43a7@suse.com>
From: Tamas K Lengyel <tamas@tklengyel.com>
Date: Fri, 31 Jan 2025 18:36:33 -0500
X-Gmail-Original-Message-ID: <CABfawhn8uhUbr4yRcSb=_Jw3y2Cgsh_ozXotTFkrDt12K8Cyog@mail.gmail.com>
X-Gm-Features: AWEUYZnFVlVSHAzmLOPA9B2OMZh_tGh9yJEsax242NIz3ZYe_YdecPGVr1K5L1A
Message-ID: <CABfawhn8uhUbr4yRcSb=_Jw3y2Cgsh_ozXotTFkrDt12K8Cyog@mail.gmail.com>
Subject: Re: [PATCH v2 1/4] xen: kconfig: rename MEM_ACCESS -> VM_EVENT
To: Jan Beulich <jbeulich@suse.com>
Cc: Sergiy Kibrik <Sergiy_Kibrik@epam.com>, Julien Grall <julien@xen.org>, 
	Bertrand Marquis <bertrand.marquis@arm.com>, Michal Orzel <michal.orzel@amd.com>, 
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>, Andrew Cooper <andrew.cooper3@citrix.com>, 
	Anthony PERARD <anthony.perard@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
	Alexandru Isaila <aisaila@bitdefender.com>, Petre Pircalabu <ppircalabu@bitdefender.com>, 
	Shawn Anastasio <sanastasio@raptorengineering.com>, 
	Alistair Francis <alistair.francis@wdc.com>, Bob Eshleman <bobbyeshleman@gmail.com>, 
	Connor Davis <connojdavis@gmail.com>, Oleksii Kurochko <oleksii.kurochko@gmail.com>, 
	"Daniel P. Smith" <dpsmith@apertussolutions.com>, Stefano Stabellini <sstabellini@kernel.org>, 
	xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 31, 2025 at 1:30=E2=80=AFAM Jan Beulich <jbeulich@suse.com> wro=
te:
>
> On 31.01.2025 01:26, Tamas K Lengyel wrote:
> > On Thu, Jan 30, 2025 at 8:24=E2=80=AFAM Jan Beulich <jbeulich@suse.com>=
 wrote:
> >>
> >> On 21.01.2025 11:19, Sergiy Kibrik wrote:
> >>> Use more generic CONFIG_VM_EVENT name throughout Xen code instead of
> >>> CONFIG_MEM_ACCESS. This reflects the fact that vm_event is a higher l=
evel
> >>> feature, with mem_access & monitor depending on it.
> >>>
> >>> Suggested-by: Jan Beulich <jbeulich@suse.com>
> >>
> >> I don't think this is applicable; my suggestion went in a different di=
rection.
> >>
> >>> Suggested-by: Tamas K Lengyel <tamas@tklengyel.com>
> >>> Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
> >>
> >> Before considering to ack this, I'd like you, Tamas, to confirm this i=
s really
> >> what you had thought of. In particular ...
> >>
> >>> --- a/xen/arch/arm/Makefile
> >>> +++ b/xen/arch/arm/Makefile
> >>> @@ -37,7 +37,7 @@ obj-y +=3D irq.o
> >>>  obj-y +=3D kernel.init.o
> >>>  obj-$(CONFIG_LIVEPATCH) +=3D livepatch.o
> >>>  obj-$(CONFIG_LLC_COLORING) +=3D llc-coloring.o
> >>> -obj-$(CONFIG_MEM_ACCESS) +=3D mem_access.o
> >>> +obj-$(CONFIG_VM_EVENT) +=3D mem_access.o
> >>
> >> ... changes like this one look somewhat odd to me.
> >>
> >>> --- a/xen/common/Kconfig
> >>> +++ b/xen/common/Kconfig
> >>> @@ -92,7 +92,7 @@ config HAS_VMAP
> >>>  config MEM_ACCESS_ALWAYS_ON
> >>>       bool
> >>>
> >>> -config MEM_ACCESS
> >>> +config VM_EVENT
> >>>       def_bool MEM_ACCESS_ALWAYS_ON
> >>>       prompt "Memory Access and VM events" if !MEM_ACCESS_ALWAYS_ON
> >>>       depends on HVM
> >>
> >> What about MEM_ACCESS_ALWAYS_ON (visible in patch context)? Shouldn't =
that
> >> become VM_EVENT_ALWAYS_ON then, too?
> >>
> >> Further, what about MEM_PAGING and MEM_SHARING? Shouldn't those, at le=
ast
> >> documentation purposes, then also gain a dependency on VM_EVENT?
> >
> > MEM_PAGING, yes. MEM_SHARING, definitely not. MEM_SHARING is perfectly
> > functional without vm_event.
>
> Is it? I see e.g.
>
>     if ( sharing_enomem )
>     {
> #ifdef CONFIG_MEM_SHARING
>         if ( !vm_event_check_ring(currd->vm_event_share) )
>         {
>             gprintk(XENLOG_ERR, "Domain %pd attempt to unshare "
>                     "gfn %lx, ENOMEM and no helper\n",
>                     currd, gfn);
>             /* Crash the domain */
>             rc =3D 0;
>         }
> #endif
>     }

On x86 vm_event is always compiled in as per current setup. If we were
to make that dependent on the now renamed config option this here
should be converted to CONFIG_MEM_SHARING && CONFIG_VM_EVENT. The rest
of the mem_sharing codebase does not require vm_event to function,
this here is used only if there is a subscriber to the enomem
corner-case. It isn't normally used.

> in hvm_hap_nested_page_fault().
>
> Also - you responded only to a secondary remark here. What about the
> more basic points further up?

My recommendation to use CONFIG_VM_EVENT for the
vm_event/mem_access/monitor subsystems strictly only applies to ARM
where these three subsystems have a 1:1:1 dependency. On x86 the
dependency between the three can be more complex, I would not change
the x86 side of things unless we want to get the three subsystems
their own kconfig options.


Tamas